読んだ文書がAIへの指示に変わる — AgentDojoの97タスク・629テストから考える導入前チェック

サマリ

取引先から届いた資料を読み、返信案を作る。生成AIにその先の送信まで任せるとき、確認したいのは文章の質だけではありません。資料に紛れ込んだ指示を、利用者の依頼として実行してしまわないかという問いが加わります。

AgentDojo論文は、外部ツールから受け取る情報を介した攻撃と防御を評価する研究です。NeurIPS 2024で報告された初期構成は、97の利用者タスクと629のセキュリティテストケース。企業の被害件数でも、97×629回の攻撃でもありません。

本レポートでは、この評価の考え方を導入前の確認に使います。論文の実験条件を自社の事故確率へ置き換えず、業務が進むことと、許可していない操作を防ぐことを別々に確かめます。

論文の整理：何を測っているのか

97と629は、異なる単位の数字

Debenedettiら（ETH Zurich、Invariant Labs）のAgentDojoは、メールや予定表、Slack、旅行予約、銀行取引などを模した環境を用います。論文§3では、各環境内の利用者タスクと攻撃者の目的を組み合わせ、合計629のテストケースを構成しています。97は利用者タスクの総数です。

攻撃者が狙う操作と、利用者が本来依頼した仕事は別です。論文§3.4は、攻撃のない状態での業務達成、攻撃下で不正な副作用なく業務を達成できるか、攻撃者の目的が実現したかを分けて評価します。攻撃成功率の低さだけでは、仕事を任せられるとは判断できません。

この研究は模擬データを使う評価環境です。論文§4.3・§5には、単純な攻撃・防御を中心とすることや、文脈を保持したまま複数の依頼を続ける状況を十分に扱っていないことなど、適用上の限界があります。本稿は2024年の研究設計を読み解くもので、2026年時点のモデル比較ではありません。

外部の文章が命令として扱われる問題

OWASPの「LLM01:2025 Prompt Injection」は、Webページやファイルなど外部情報を通じてモデルの振る舞いを変えてしまう問題を、間接的なプロンプトインジェクションとして説明しています。情報の漏えいや、不適切な操作につながる可能性があります。

同資料が挙げる対策には、必要最小限の権限、高リスク操作での人の承認、攻撃を想定したテストがあります。これらは対策の指針であり、「採用企業の何割が安全になる」と示す効果測定ではありません。

岡崎の分析

「読ませてよい」と「実行させてよい」を別々に決める

私たちは、AIエージェントの導入判断では、参照できる情報と、実行できる操作を同じ表に並べることが有効だと見ています。以下は研究の実験結果ではなく、フィールフロウが提案する業務設計です。

例えば、取引先の資料から返信案を作る業務を考えます。これは説明用の仮例です。資料の内容を参照する必要があっても、連絡先を変更したり、別の顧客の情報を取得したりする権限まで必要とは限りません。業務の目的から必要な操作を絞り込みます。

点検する対象	導入前に決めること	確認する証拠
参照する情報	取引先資料、社内資料など、読ませる範囲	実際に取得した資料と取得経路
実行できる操作	下書き保存、送信など、許可する範囲	接続先で設定された権限と操作記録
人が承認する内容	宛先、送信本文、添付資料	承認した内容と実行内容の一致
停止する条件	許可外の取得・送信要求など	停止理由、通知先、再開の判断者

「外部文書の指示は無視する」とAIに伝えることに加え、接続先の権限設定も確認します。禁止した操作をAIが要求したときに、アプリケーション側で拒否できるかを試すためです。

情報漏えいだけを合否にしない

評価担当者が「不正な送信は起きなかった」と報告しても、すべての処理が止まっていたなら、業務として使えるかは未確認です。逆に返信案が完成していても、その途中で許可外の情報を参照していれば、期待する動作とはいえません。

そこで私たちは、業務の成否と許可外操作の有無を別の欄に記録することを提案します。停止した場合も、危険な要求を正しく拒否したのか、通常の依頼まで処理できなくなったのかを区別します。

これはベンチマークの点数を合格基準として借りる方法ではありません。自社で実行する業務を材料にして、成果と制約が両立するかを確認する方法です。試験に通った範囲、未検証の範囲、残るリスクを業務責任者が把握できるようにします。

提言 — どう付き合っていくか

最初の対象には、取引先資料を使った返信案の作成を提案します。実際の顧客情報を含まない試験用資料と宛先を用意し、下書きから送信承認までの流れを点検します。以下は当社の提案であり、安全性を保証する手順ではありません。

読む情報・実行権限・承認をつなげて点検する

フィールフロウの提案。対象は試験環境での返信案作成です。図中の番号は着手順であり、論文の測定値ではありません。

通常の仕事を確かめる試験用資料で返信案を作り、内容・参照先・下書き保存を確認する。
許可外の要求を試す資料経由で宛先変更などを要求する条件を加え、拒否と業務への影響を記録する。
承認と停止を確かめる人が宛先・本文・添付を確認し、承認内容だけが実行されるかを点検する。

AIは返信案を作成し、人が送信を承認する。許可外操作はアプリケーション側でも制限し、問題があれば停止できる状態にします。

承認画面では、AIによる「安全です」という要約だけで判断しないようにします。送付先と送信内容を確認でき、承認後にそれらが変更された場合は再確認が必要になる設計を検討します。何を承認したか分からないまま押すボタンでは、判断の証拠が残りません。

利用開始後も、モデル、接続ツール、参照資料、権限設定を変更したら、影響する試験をやり直します。担当者の交代時には、停止方法と再開を決める責任者も引き継ぎます。

岡崎の分析：導入判断を具体的な業務に戻す

経営が確かめたいのは、「AIは危険か安全か」という大きな問いへの一言の答えではありません。この業務で、何を読ませ、どこまで実行させ、誰が承認するのか。その条件を満たす証拠があるかです。

フィールフロウでは、生成AIを使う業務の切り分けや、導入前の確認項目の整理についてご相談いただけます。現在検討している業務と、AIに任せたい操作をお持ちください。生成AIの業務設計について相談する