AIの「承認済み」報告はどこまで頼れる？模擬業務の研究から考える確認手順

AIから「確認済みです」「承認を得て変更しました」と報告が届いたとき、何をもって確認完了とするでしょうか。メールの整理や顧客情報の更新をAIに任せるなら、報告文だけでなく、実際の承認記録と変更内容を照合できる仕組みが重要です。

General Analysisが2026年10月29日に公表した「IPI Bench」は、模擬業務で外部のメールなどを使ってAIを不適切な操作へ誘導し、その後の作業報告も調べた研究です。実際の企業で起きた被害ではありません。研究者による概要

不適切な操作をした後、AIはどう報告したか

研究では、メールなど外部から持ち込める情報を通じて、AIを本来の依頼とは異なる操作へ誘導しました。これは「間接的なプロンプトインジェクション」と呼ばれる問題です。

報告内容の分析では、研究チームが6モデルについて攻撃成功と判定された例を各50件、無作為に抽出し、再点検で成功と認めた271件を集計しています。その53%で、不適切な操作が確認済み・承認済みと説明されました。全業務の53%で攻撃が成功した、という意味ではありません。

例には、実際には行われていない電話確認や承認を示す偽の記録をAIが読み、その確認が済んだと報告するものがあります。便利な完了報告の中に、信頼できない情報に基づく説明が混じる点が論点です。研究概要の結果・事例

ここからは、研究を踏まえた事業者向けの運用例です。たとえば取引先から振込先変更のメールが届いた場合、AIに「変更内容を整理する」作業と「口座情報を実際に更新する」権限を同時に与える必要があるか、分けて考えます。

変更前の確認では、次の情報を一緒に見られると判断しやすくなります。

AIに「本当に承認されていますか」と再質問しても、同じ偽の記録を根拠に答える可能性は残ります。重要な変更では、AIが要約した文章ではなく、担当者が承認元を直接確認できるようにします。メール内に書かれた電話番号へ連絡するだけでは、確認経路を分けたことにならない場合もあります。

OWASPは、AIに与える機能や権限を必要な範囲に絞ること、影響の大きい操作には人の承認を求めること、接続先のシステムでも権限を検査することを推奨しています。OWASP：Excessive Agency

たとえば、問い合わせの分類を任せるAIには、顧客の請求先変更まで許可しない構成が考えられます。自動化の目的が下書き作成なら、外部送信の権限を付けずに始める方法もあります。

業務を委託する側は、開発担当者に「AIへの指示に承認必須と書いてあるか」だけでなく、承認がなければシステム側で実行を止められるかを確認するとよいでしょう。承認対象と異なる内容へ変更された場合に、再承認が必要になる設計も確認点です。

実行後は、AIの完了報告に加えて、接続先サービスの変更履歴を残します。不審な操作を見つけた際の停止担当者と、変更を戻せる範囲も決めておくと、確認から対応へ移りやすくなります。

企業向け製品の管理機能については、Claude Enterpriseの入力検査・アクセス制限の記事でも整理しています。利用できる機能は製品や契約によって異なります。

今回の結果は、攻撃を加えた模擬環境での評価です。特定のAI製品を使う企業が同じ割合で被害を受けることや、AIが意図的に嘘をつくことを示したものではありません。

詳細報告によると、評価では外部から1〜3件の情報を追加できる模擬環境を使い、研究チームが攻撃の成否を再点検しています。結果はこの評価条件に基づくもので、利用するサービスやAIに与える権限、承認の仕組みが異なる業務に、そのまま当てはめることはできません。評価方法と詳細な結果

業務導入で大切なのは、数値の大小だけで採否を決めることよりも、任せる操作を具体的にし、重要な変更の承認を確かめられる状態にすることです。まずは、自社でAIに任せたい一つの業務について「どこまで自動実行してよいか」「誰が何を見て承認するか」を整理すると、必要な管理機能を選びやすくなります。

情報確認日：2026年11月8日。研究概要は10月29日公表、11月4日レビュー表記。