AIエージェントに「明日の天気を調べて」「打ち合わせを予定表に入れて」と頼むと、エージェントは天気のサービスや予定表のサービスを呼び出して作業を進めます。利用者が確認するのは「天気を調べる」「予定を入れる」という操作の名前までで、その呼び出しに実際にどんなデータが添えられて外部に送られたのかまでは、ほとんど見ていないのではないでしょうか。
もうひとつの心配は、作業の途中でエージェントの行動が変わってしまうことです。読み込んだWebページやメールに紛れ込んだ指示に引きずられ、頼んでいない送信や削除をしていたとしても、長い作業の記録から「どこで、何が起きたのか」を後から突き止めるのは簡単ではありません。いざというときに、その記録自体が正しいと言い切れるかどうかも気になるところです。
当ブログ独自の arXiv 急上昇ワード集計では、「tool call（ツール呼び出し）」がセキュリティ分野（cs.CR）で伸びています。論文全体に占める割合は2026年1〜6月の0.9%から7〜9月は2.2%になり、平滑化した伸びは2.2倍です。ソフトウェア工学の分野でも同じく2.2倍でした。この記事では、個人情報保護委員会や OWASP などの資料で考え方を整理したうえで、論文4本から「承認した操作が裏で広がっていないか」を確かめる方法を読み解きます。結論を先に言うと、送る前にデータを削り、送った後は記録を読み返して変化点を探し、その記録を改ざんに気づける形で残すのが基本です！
ツール呼び出しで「裏で広がる」もの
ツール呼び出しとは、エージェントが外部のサービスや社内のシステムを使うときに、宛先の機能と、そこに渡す値（引数）をまとめて送る仕組みです。どのツールを使わせるか、どの権限を持たせるかの設計は、近日公開予定の記事「AIエージェントとMCPの権限設計」で扱います。この記事では、権限の範囲内で許可した操作であっても、次の3つが知らないうちに広がりうる点に注目します。
- 渡すデータ: 操作に必要な分を超えて、個人情報などが外部のサービスに送られる
- 行動: 途中で読んだデータに紛れ込んだ指示により、依頼と違う操作に切り替わる
- 記録: 後から確かめるための記録が欠けたり、書き換えられたりする
公的な資料が求めていること
個人情報保護委員会は2023年6月の注意喚起で、事業者が生成AIサービスに個人情報を含む指示を入力する場合は、利用目的の達成に必要な範囲内であることを十分に確認するよう求めています（個人情報保護委員会「生成AIサービスの利用に関する注意喚起等」）。この注意喚起は生成AIサービスへの入力を対象にしたものですが、エージェントが自動で組み立てるツール呼び出しにも同じ考え方を当てはめる、というのがこの記事の立場です。
OWASP の「Top 10 for LLM Applications 2025」は、エージェントに過大な機能や権限を与えるリスクを「過剰な自律性（Excessive Agency）」としてまとめ、防ぐ策として拡張機能とその権限を必要最小限に絞ることを挙げています。あわせて、それ自体では防げないものの被害を抑える策として、拡張機能と連携先のシステムの動きを記録・監視し、望ましくない操作が起きている場所を突き止めることも挙げています（OWASP「LLM06:2025 Excessive Agency」）。
経済産業省と総務省の「AI事業者ガイドライン（第1.2版）」も、検証可能性を確保するため、データの量や内容に照らして合理的な範囲で、開発過程、利用時の入出力、推論過程、判断根拠などのログを記録・保存し、事故の原因究明や再発防止に照らして記録の方法・頻度・保存期間を検討するよう求めています（経済産業省・総務省「AI事業者ガイドライン（第1.2版）」）。
渡すデータの広がりを、送る前に削る
📄 論文: ツールに渡す個人情報を「必要な分だけ」に書き換える
ToolMinimize: Auditing and Rewriting LLM Agent Tool Calls to Minimize Privacy Exposure（Wenbiao Li ほか、2026年8月、arXiv:2608.24957）は、査読前の論文（プレプリント）です。
著者らはまず、天気の確認や予定の登録といった日常的な20の作業を GPT-4o、Claude 3.5 Sonnet、Llama-3.3-70B に実行させ、ツールに渡された値を調べました。この実験では、通常の設定でツール呼び出しの81〜88%に、そのツールには不要な個人情報が含まれていました。「個人情報は必要な分だけ渡すように」と明示的に指示しても、36〜76%は過剰なままで、指示がほとんど効かないモデルもありました。たとえば天気を調べるのに番地までの住所を送ってしまう、病院名のように病気を推測させる情報を添えてしまう、といった形です。
そこで論文は、エージェントとツールの間に入って呼び出しを止め、各ツールの入力項目の定義をもとに「この項目は本当に必要か」を判断し、不要な項目を消す、住所を市の単位に丸める、といった書き換えをしてから送る仕組みを提案しています。可否の判断で止めてしまうのではなく、作業を続けられる形に直して送るのが特徴です。著者らが作った90の模擬シナリオ、外部の50シナリオ、実在する25の MCP サーバーの入力定義をそれぞれ評価し、送られる個人情報を大きく減らせたと報告しています。ただし論文の「作業を損なわない」という評価は、送る値の形式が正しく必要な項目が残っているかを見たもので、作業を最後までやり遂げられたかは別に確かめています。
効果は、個人情報をどれだけ見逃さずに見つけられるかに左右されます。著者ら自身、見つけられなかった情報は書き換えられずにそのまま送られること、模擬の宛先で実際に動かした確認では、地図の作業で必要な住所まで削ってしまい、元と同じ結果にならない例があったことを限界として挙げています。運営者にとっての意味は、「指示で気をつけさせる」だけでは足りず、送る直前に機械的に削る層が有効だということです。
行動の広がりを、記録から後で突き止める
📄 論文: 乗っ取られた作業記録に「一手ずつ」印をつけたデータ集
AgentDrift: A Step-Labeled Benchmark of Injection-Hijacked LLM Agent Trajectories（Asif Pinjari ほか、2026年9月、arXiv:2609.06972）は、査読前の論文（プレプリント）です。
エージェントが読んだデータに指示が紛れ込み（間接プロンプトインジェクション）、乗っ取られたときの作業記録は、正常な手順がしばらく続いたあと、攻撃者のための操作に切り替わる形になります。著者らは、メール、銀行、Web、コーディング、医療の5分野で、1つのモデルを使って合成した12,536件の作業記録を作り、すべての手順に「正常」「指示が入り込んだ地点」「乗っ取られた操作」「入り込んだが従わなかった」のいずれかの印をつけました。攻撃に見えるが正当な内容を含む紛らわしい記録も入れてあります。
表面的な特徴だけで判定する単純な分類器を試すと、見つけられた攻撃は55.4%にとどまり、途中から一部だけ乗っ取られた型に限ると8.2%しか見つけられませんでした。記録全体の雰囲気ではなく、手順の並びを追わないと分からない攻撃が多いということです。
📄 論文: どこから入り込み、どこまで汚れたかを一度に示す
DriftNet: A Dual-Head Trajectory Transformer for Detecting and Localizing Prompt Injection in LLM Agents（Asif Pinjari ほか、2026年9月、arXiv:2609.10892）は、査読前の論文（プレプリント）で、同じ著者らによる上のデータ集の続編です。
保存されたツール呼び出しの記録だけを読み、「この作業は乗っ取られたか」と「どの手順で入り込み、どの手順が汚れたか」を同時に答える小さなモデルを作りました。エージェント本体のモデルの中身にも、実行のやり直しにも頼らない、記録だけを使う方式です。
AgentDrift のデータで評価したところ、攻撃が成功した記録の98.7%で入り込んだ地点を正確に言い当て、指示が入り込んだが従わなかった218件はひとつも誤って警告しませんでした。ただし、学習も評価も1つのモデルで合成した記録で行っており、実際のエージェントの記録で同じ精度が出るかは確かめていないと、著者ら自身が明記しています。データ集の側でも、同じ架空の環境から作られた記録は同じ分類に偏るという性質が測られており、その影響を除いた評価は今後の課題とされています。
2本から言えるのは、「乗っ取られたかどうか」だけでなく、「どこから変わったか」と「攻撃が来たが防げたか」を分けて記録を読むことが、調査と再発防止の役に立つということです。プロンプトインジェクションそのものの仕組みと対策は、LLMエージェントのセキュリティの記事で解説しています。
記録そのものを守る
📄 論文: エージェントの作業に「フライトレコーダー」をつける
A Black Box for Agentic Processes: Blockchain-Anchored Evidence for AI Agent Communication, Human Oversight, and GRC Audits（Arslan Brömme、2026年9月、arXiv:2609.04017）は、単著の査読前の論文（プレプリント）です。設計の考え方を示す立場表明の論文で、性能や安全性を実験で確かめたものではありません。
エージェント同士のやり取り、人による承認、ツール呼び出しの引数と結果といった記録から、内容を表す短い指紋（ハッシュ値）を作り、改ざんしにくい外部の台帳に時刻とともに固定しておく設計です。記録の中身は社内に置いたままにし、外に出すのは指紋だけにします。後から記録の指紋を計算し直して照らし合わせれば、固定した時点から書き換えられていないかを確かめられます（記録の取り漏れや出来事の順番までは、これだけでは分かりません）。たとえば「人の承認は、実行より前に得られていたか」「実行された引数は、承認された内容と一致するか」を検証できるようになります。
一方で著者は、この仕組みが証明できるのは「その時点からこの記録が変わっていないこと」までで、記録の内容が正しいことや、記録を取る段階で漏れやすり替えがなかったことは証明できないと強調しています。出来事の順番を確かめるには別の仕組みが必要で、すべてを固定するのではなく、外部への送信や権限の変更、承認といった影響の大きい出来事を優先して選ぶよう勧めています。
現場でやること
ツールごとに「本当に必要な項目」を決め、送る前に削る
つないでいるツールの入力項目を一覧にし、それぞれ「必ず要る」「あれば便利」「不要」を決めます。住所や日時の細かさなど、丸めてよい項目も決めておきます。そのうえで、エージェントの指示に頼らず、呼び出しの直前に不要な項目を削る処理を挟みます。
呼び出しの記録は「読み返せる形」で残す
ツールの名前だけでなく、渡した引数、読み込んだデータ、返ってきた結果、人が承認した内容を、作業ごとに順番どおり残します。ただし記録自体が個人情報の置き場所になるので、保存先の権限と保存期間を決めておきます。
読み返すときは「どこから変わったか」を探す
定期的な見直しや問題が起きたときは、承認した内容と実際に実行された引数を突き合わせ、依頼と関係のない宛先への送信や削除が、どの手順の後から始まったかを探します。直前に読み込んだデータが入り口の候補です。自動で判定する仕組みは研究段階なので、人が読む前提で記録を整えておきます。
大事な記録は、改ざんに気づける形で残す
承認、外部への送信、権限の変更といった影響の大きい記録は、エージェントが書き換えられない別の保存先にも送り、ハッシュ値を残しておきます。ブロックチェーンを使わなくても、追記しかできない保存先を分けるだけで、後から書き換えに気づきやすくなります。
ツール呼び出しを監査する鍵は次の3点です
- 送るデータは、指示でなく仕組みで減らす
ツールごとに必要な項目を決め、呼び出しの直前に不要な個人情報を削ったり丸めたりします。 - 記録は「どこから変わったか」を追える形で残す
引数・読んだデータ・結果・承認を順番どおりに残し、承認した内容と実行された内容を突き合わせます。 - 大事な記録ほど、改ざんに気づける場所に置く
影響の大きい出来事を選び、エージェントが書き換えられない保存先とハッシュ値で守ります。
まとめ：「承認した」で終わらせず、送る前と送った後を確かめよう！
ツール呼び出しの承認は、操作の名前に対して行われがちです。9月の論文からは、その裏で不要な個人情報が送られていることが珍しくないこと、乗っ取りは記録の手順を順に追わないと見落としやすいこと、そして記録そのものも守る対象であることが見えてきました。
権限を絞って「できること」を決めたら、次は「実際に何が送られ、何が起きたか」を確かめる番です。送る前にデータを削り、送った後は記録を読み返し、その記録を改ざんに気づける形で残す。この3つを押さえれば、「承認したはずの操作が裏で広がっていないか」に、記録をもとに答えられるようになるはずです！
参考文献
- Wenbiao Li ほか「ToolMinimize: Auditing and Rewriting LLM Agent Tool Calls to Minimize Privacy Exposure」arXiv:2608.24957（https://arxiv.org/abs/2608.24957）2026-10-02 確認
- Asif Pinjari ほか「AgentDrift: A Step-Labeled Benchmark of Injection-Hijacked LLM Agent Trajectories」arXiv:2609.06972（https://arxiv.org/abs/2609.06972）2026-10-02 確認
- Asif Pinjari ほか「DriftNet: A Dual-Head Trajectory Transformer for Detecting and Localizing Prompt Injection in LLM Agents」arXiv:2609.10892（https://arxiv.org/abs/2609.10892）2026-10-02 確認
- Arslan Brömme「A Black Box for Agentic Processes: Blockchain-Anchored Evidence for AI Agent Communication, Human Oversight, and GRC Audits」arXiv:2609.04017（https://arxiv.org/abs/2609.04017）2026-10-02 確認
- 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等」（https://www.ppc.go.jp/files/pdf/230602_alert_generative_AI_service.pdf）2026-10-02 確認
- OWASP「LLM06:2025 Excessive Agency」（https://genai.owasp.org/llmrisk/llm062025-excessive-agency/）2026-10-02 確認
- 経済産業省・総務省「AI事業者ガイドライン（第1.2版）」（https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/20260331_report.html）2026-10-02 確認
