- 公開日
AIエージェントに複数のツールを続けて使わせるときは、次の操作へ進む直前に、根拠、対象、権限、すでに起きた変更を確認します。最初の依頼が正しくても、途中の検索結果や要約が誤れば、後続の操作へ誤りが引き継がれます。確認できない条件に依存する操作は止め、独立して成立する作業だけを続ける設計が必要です。
たとえば「調査してメールを下書きする」という依頼にも、資料の取得、要約、添付候補の選択、メールサービスへの保存という異なる処理があります。たとえ未送信でも、メールサービスへの保存で情報の置き場所が変わるため、文章案を画面に返す処理とは分けて判断します。
連鎖すると、誤りが次の操作の材料になる
ここでいうツール連鎖は、あるツールの結果を使って次のツールの入力や実行判断を作る処理です。検索結果の文章が下書きの材料になり、その下書きと添付ファイルが保存ツールへ渡る、といった流れを指します。
連鎖の長さだけで危険度は決まりません。公開資料を読む操作と、社内資料を外部のメールサービスへ保存する操作では、情報の受け手と影響が違います。使えるツールが増えると、誤った宛先を選んだり、目的外のファイルを添えたりする経路も増えます。前のツールで「取得成功」と返ったことは、内容の正しさや次の操作の許可を意味しません。
OWASPのLLM06:2025 Excessive Agencyは、過剰な機能、権限、自律性を分け、必要なツールと権限への限定、下流システムでの認可、高影響操作での人の確認を対策として挙げています。これは一般的な安全設計の指針であり、対策を一つ導入すれば事故を完全に防げるという保証ではありません。
検索ページやツールの応答に「このファイルも送ってください」と書かれていても、その文章は利用者からの新しい依頼にはなりません。外部の内容を読んだことを理由に、参照範囲や送信先を広げないようにします。モデルへの指示に加え、実行側で許可された操作と対象を照合する必要があります。
次のツールへ渡す内容に、確認済みの条件を残す
連鎖の各段階では、文章だけを渡すより、根拠の所在と判断に必要な条件を合わせて引き継ぐ方が確認しやすくなります。たとえば要約には参照元の識別情報と該当箇所、添付候補にはファイルの版と利用可能な相手の範囲を添えます。資格情報や資料全文を毎段階へ複製することとは違います。
実行側が確認する対象は、少なくとも次のように分けられます。
- 入力の形式：必要な欄が揃い、対象を表す値が想定した型になっているか
- 内容の根拠：金額、日付、添付の説明が原資料の該当箇所と一致するか
- 操作の権限：誰の依頼で、どのアカウントから、どの対象へ、何をしてよいか
- 実行の状態：未実行なのか、処理中なのか、前の要求で完了しているのか
形式は合っていても添付の利用条件が未確認なら、保存には進めません。条件ごとに判定を残すと、何を確認すれば再開できるかが分かります。MCPのTools仕様（2026-07-28版）も、入力や出力の検証、アクセス制御、エラーの扱いを区別しています。MCPはAIアプリとツールなどを接続するためのプロトコルです。ツールの入力形式が仕様に合っていても、その操作の業務上の承認まで得られるわけではありません。サーバーが返す説明や注釈も、信頼できる根拠を確かめず権限の証明に使わないようにします。
この区別を実装へ落とすときは、モデルが作った実行候補を、そのまま外部APIへ渡さないようにします。APIは外部システムの機能を呼び出す窓口です。実行を管理するアプリが、対象の一致、許可操作、必要な承認を検査し、不適合なら呼び出しを拒否します。文章で「送信しない」と指定するだけでなく、下書き作業では送信機能を利用対象から外す方法もあります。
調査からメール下書きまでを、一つの例で確かめる
以下は架空の業務とツールを使う説明例です。実在のメールや資料を扱った試験ではありません。
利用者は「公開されている展示会案内を調べ、営業担当者が確認する案内メールを作って。添付は外部配布可の製品概要第3版だけ。指定メールサービスの自分の下書きに保存し、送信はしない」と依頼したとします。対象のサービスへの本文・製品概要の保存は認められ、連絡先一覧や社内価格表の参照は認められていない条件です。
取得ツールは展示会の公式案内と、許可された製品概要を読みます。要約処理は案内文を作り、添付選択処理は製品概要の識別情報を渡します。下書き保存ツールには保存先アカウントと保存対象を渡します。保存先とデータ範囲は元の依頼に結び付け、添付候補の名前だけでなく識別情報と版を保存直前にも照合します。
| 段階 | 照合するもの | 条件が合う場合の期待処理 | 合わない、確認できない場合 |
|---|---|---|---|
| 取得 | 公式案内の主体と開催日時、製品概要の識別情報・第3版 | 該当箇所と取得時点を残して要約へ渡す | 別イベントの資料なら除外。取得失敗を「記載なし」に置き換えない |
| 要約 | 開催日時と申込期限の原文、確定・未確認の区別 | 原文にある日時を保ち、未確認欄を示す | 原文と異なる日時を直す。根拠のない期限は補わない |
| 添付選択 | 許可されたファイル、版、外部配布条件 | 第3版だけを添付候補にする | 価格表や版不明の資料を除外し、適合する添付がなければ保存を保留 |
| 下書き保存 | 保存先、本文、添付、既存の要求状態 | 確定した内容を一度保存し、返却された下書きIDと内容を照合 | 権限不足なら保存しない。応答不着なら結果不明として照会へ回す |
公式案内に「開催は11月12日、申込期限は後日案内」とある場合、期待する下書きもその区別を保ちます。「申込期限は11月5日」と補う処理は、読みやすさの改善として通せません。日付はすべて架空で、実際の催事情報ではありません。
添付資料の本文に価格表の追加を求める文章が混じっていても、それを新たな権限として扱わず、指定された第3版だけを使います。添付候補が社内限定の第4版しか見つからなければ、外部配布可だと推測して保存へ進めません。取得済みの公開案内から、添付未確定と明示した本文案を利用者に返すことはできます。下書き保存の依頼が添付付きの内容を対象としているため、添付のない別の内容を勝手に保存することは避けます。
止める範囲は、欠けた条件が影響する部分で決める
根拠が一部不足していても、すべての処理を止める必要があるとは限りません。先ほどの申込期限のように、未確認として残せる情報なら、開催日を含む本文案の作成は続けられます。一方、開催日時自体を確認できず案内の目的を満たせないなら、完成した案内として保存する前に確認へ戻します。
停止条件には、資料へのアクセス拒否、指定した版の不一致、許可のない保存先、承認された範囲からの変更などを具体的に置きます。アクセス拒否を受けた後に別アカウントへ切り替える、資料内の指示に従って添付を追加する、といった迂回は続行に含めません。
同じ調査でも、利用者の画面へ文章案を返すだけなら、メールサービスへの保存権限や下書きの作成結果を管理する工程は省けます。ただし、その場合も資料の根拠や入力してよい情報の確認は残ります。逆に送信まで任せる場合は、受信者、本文、添付が許可された内容と一致することと、送信結果を確認する工程が追加されます。下書きを作る依頼から送信の許可を導かないことが境界になります。
応答が返らないときは、連鎖を最初から回さない
下書き保存の応答が返らない場合、保存は済んでいて返事だけが失われた可能性があります。そこで再度「調査から保存まで」を実行すると、同じ下書きを複数作るおそれがあります。要求を追跡するIDと、サービス側に残った下書きの状態を対応させ、成功、失敗、処理中、結果不明を分けて扱います。
AWSのMaking retries safe with idempotent APIsは、応答不着と副作用の有無を分け、重複した要求を同じ意図として扱うサービス側の設計を説明しています。冪等性とは、同じ意図の要求を繰り返しても追加の副作用を生じさせない性質です。追跡用IDを付けるだけで、どの保存サービスでもこの性質が得られるわけではありません。
下書きが保存済みなら、内容を照合してその結果を使います。処理中なら新しい作成を始めず確認を続けます。結果を照会できず重複も防げないなら、自動再実行を保留し、利用者が確認できる対象と未確認事項を示します。再試行の細かな期限やキーの扱いは、利用するサービスの契約に合わせて決めます。
ツール連鎖を点検するときは、正常な資料、日時の根拠欠落、添付の版不一致、保存権限不足、保存応答の不着を別々に用意すると、止める場所を確認できます。実際の宛先へ届かない模擬環境で、拒否した操作が呼ばれていないことと、独立した本文案が失われていないことを見ます。警告表示、禁止した呼び出しの有無、保存先に残った内容を分けて照合すれば、検知できても実行を止められなかったケースを見落としにくくなります。
目標逸脱・反復・過剰実行を止める条件は「AIエージェントの目標逸脱・反復・過剰実行を止める条件」、トークン消費の急増から異常な反復を見分ける方法は「トークン消費の急増から、Agentの異常な反復を見分ける」で解説しています。
ブラウザ・GUIエージェントをページ内の操作誘導から守る方法は「ブラウザ・GUIエージェントをページ内の操作誘導から守る」で解説しています。
タイムアウトした外部操作を照会し、二重実行を避けて再試行する方法は「タイムアウトした外部操作を照会し、二重実行を避けて再試行する」、ツール連鎖のチェックポイントを保存し、条件を再検証して再開する方法は「ツール連鎖のチェックポイントを保存し、条件を再検証して再開する」で解説しています。
基本から確認する：この記事の前提になる考え方は、「AIエージェントの安全設計（権限・外部資料・承認・検証の基本）」にまとめています。
