- 公開日
ツールは、依頼の対象を取得でき、許可された範囲で必要な処理だけを行えるものを選びます。呼び出す直前に、選択理由と実際の取得先・引数・副作用を照合します。対象の違う結果が返ったら回答の根拠から外し、適切なツールがなければ機能不足を明示して保留します。
例えば「製品の仕様を調べる」と「その製品を買った顧客を調べる」は、同じ製品名を使っても対象が違います。説明がどちらも「関連情報を検索する」だけなら、製品名が一致していても、検索先を選ぶ手掛かりが足りません。対象の違いをツール定義に書き、実行側でも検査できる形にすることが必要です。
検索する対象と起こす変化を先に決める
次は架空の社内環境です。利用者は「製品Pの第3版について、保管温度を承認済みの仕様書から確認して」と依頼しました。回答先はこの利用者だけで、文書の更新や顧客情報の取得は依頼されていません。利用者には、対象の仕様書を読む権限があるとします。以下は設計例で、実際の検索や誤呼出しを行った結果ではありません。
この依頼を、対象「製品P」、必要な資料「承認済み仕様書」、版「第3版」、確認項目「保管温度」、操作「読取り」に分けます。温度らしい数値が返ることだけを成功条件にすると、顧客の要望や旧版の説明が混ざります。資料の種類、版、承認状態まで一致することを、検索前の条件にします。
| 候補ツール | 対象と取得範囲 | 権限と副作用 | この依頼での判断 |
|---|---|---|---|
| 社内文書検索 | 権限のある文書。製品・版・承認状態で絞込み可能と仮定 | 対象文書の読取り。検索ログが残る | 条件を付けて選択候補にする |
| 顧客情報検索 | 顧客台帳、商談、顧客からの要望 | 顧客情報への別の権限が必要。閲覧記録が残る | 依頼対象と異なるため選ばない |
| 文書同期と検索 | 外部の文書を取り込み、検索索引を更新して検索 | 元サービスへの接続と索引更新を伴う | 単純な読取りの代わりに使わない |
副作用は送信や削除だけではありません。読取りでも外部サービスへ検索語を渡したり、閲覧履歴を残したりすることがあります。ここでは表の挙動を架空の契約として固定します。実際の環境では、名前に「検索」とあっても、接続先・ログ・更新処理を仕様と設定で確認する必要があります。
OWASPのExcessive Agencyは、過剰な機能・権限・自律性を分け、必要な機能と権限へ絞ることを勧めています。高機能なツールを選べば常によいのではなく、今回必要な情報を得るために、どの操作まで認めるかを考えます。
曖昧な説明を対象が分かる説明へ直す
社内文書検索の説明が「情報を検索します」だけなら、利用場面を判断できません。例えば、次のように範囲を具体化します。
「呼出し元の利用者が閲覧できる社内文書を検索する。製品ID、文書版、承認状態を条件にでき、文書ID・版・該当箇所を返す。顧客台帳は検索しない。原文は変更せず、検索ログを記録する。権限不足と検索結果ゼロは別の状態で返す。」
顧客情報検索についても、顧客IDや商談情報が対象で、製品の承認済み仕様を確認する用途ではないと記します。「使う場合」だけでなく、「似ているが使わない場合」を説明すると、選択の境界を確認しやすくなります。ここに書いた条件は、ツール管理者が実装や接続先と照合したものである必要があります。
OpenAIのFunction callingは、関数の目的や使い方、引数を明確に記述することを勧めています。ただし、説明を詳しくしただけで、実際の対象や権限が制限されるわけではありません。説明の改善と実行制御を分けて実装します。
また、MCPのTools仕様の2026-07-28版では、ツール名・説明・入力や出力のスキーマなどを区別しています。スキーマはデータの形式を定めるものです。同仕様は、ツールの振る舞いを示すannotationsという補助情報について、信頼できるサーバーから来たもの以外は信頼しない扱いにするようクライアントに求めています（MUST）。「読取り専用」と名乗る属性だけを、副作用や権限の保証にしないことが必要です。
呼出し直前に選択理由と引数を突き合わせる
製品Pの例で選択理由は、「製品Pの第3版の承認済み仕様書を取得するため、文書の種類・版・承認状態を指定できる社内文書検索を使う」と短く記録できます。長い推論の説明ではなく、依頼条件とツール能力の対応を残します。
実行器では、次の対応を確認してから呼び出します。
- 取得先は社内文書であり、顧客台帳へ切り替わっていない
- 製品IDはP、版は第3版、文書種別と承認状態は依頼に合っている
- 呼出し元の利用者の権限で対象を読める
- 今回の操作に登録・同期・送信などの追加処理が含まれない
- 取得する内容と検索語の送信先が許可された範囲に収まる
例えばモデルが顧客情報検索を選び、理由に「製品Pの情報が取れるから」と書いた場合、対象資料が仕様書と一致しません。顧客情報を一度取ってから考えるのではなく、この時点で拒否します。接続済みであることや、利用者が別業務では顧客台帳を読めることも、今回の取得目的の代わりにはなりません。
実行前に対象範囲を判別できないツールもあります。説明に不足があれば管理者へ仕様を確認し、必要なフィルターがなければ、許可された取得範囲で条件を検証できる別の方法を検討します。確認できないまま、広い検索を繰り返して目的の資料が偶然出ることを期待する構成は避けます。
正しいツールでも返却内容を確認する
社内文書検索を選んだ後は、返却された文書が実際に製品P・第3版・承認済みか、該当する値が保管温度かを照合します。取得先が正しいというだけでは、根拠として採用できるとは限りません。架空の結果に「保管温度0〜40℃」とあっても、第2版だったり、「使用温度」の欄だったりすれば、今回の問いへの確定回答にはしません。
誤った経路から顧客情報が返るケースは、防御の抜けを想定した別の異常例として扱います。例えば顧客要望に「20℃で保管したい」とあっても、製品の仕様値の代わりにはできません。値がもっともらしくても、資料の役割が違うためです。
この返却値は回答用の根拠集合から外し、後続の要約や別ツールへ渡さないようにします。不要な顧客情報をそのまま障害ログへ複製することも避け、ツール名、対象種別の不一致、要求IDなど、原因を追うのに必要な記録に絞ります。誤取得したデータの保存・削除は組織の手順に従い、調査目的という理由で新たな閲覧者へ広げません。
利用者には「製品仕様に対応する資料を取得できていないため、温度は未確認」と伝えます。無関係な個人情報を見せて誤選択を説明する必要はありません。正しい経路で「文書ID：SP-P-3、製品P、第3版、承認済み、保管条件欄：0〜40℃」を取得し原文と一致したという架空の条件なら、「第3版の承認済み仕様書SP-P-3の保管条件欄では、保管温度は0〜40℃です」と返せます。製品一般や別の版へ範囲を広げません。
選び直しと再送を別の判断にする
この架空設計では、一つの依頼について選び直しは一回まで、最初を含めた選択判断は二回までとします。新規の検索・同期の呼出しも二回を上限とし、実行前に拒否した選択は呼出し回数に含めません。結果不明を解消する状態照会は別に期限と回数を定め、確認できないまま終了した場合は人へ引き継ぎます。これは説明用の制限で、普遍的な推奨回数ではありません。予算・期限・操作の危険度に応じて実装側で制限します。
| 状態 | 確認すること | 次の対応 |
|---|---|---|
| 実行前に対象の不一致を検出 | まだ呼び出していないか。適合する別ツールがあるか | 予算内で一回選び直す。なければ機能不足を報告 |
| 正しい検索を実行中 | 同じ要求が進行しているか | 並行して同じ検索を追加せず、期限内で結果を待つ |
| 対象に合う文書を取得 | 版・承認状態・保管温度の原文が一致するか | 一致する範囲を出典付きで回答 |
| 正常にゼロ件が返る | 対象と権限を満たした検索だったか | この検索では未取得と伝える。仕様書の不存在と断定しない |
| 権限不足または明示的失敗 | 権限か入力か接続か。既に副作用が起きていないか | 権限を迂回せず、修正または機能不足の確認へ戻る |
| 応答がなく結果不明 | 要求状態と、副作用の有無を確認できるか | 再送を保留。同期・更新の可能性があれば、その状態を先に照会 |
選び直しは「目的に合う別の機能へ変えること」で、再送は「同じ処理をもう一度求めること」です。いずれも回数枠が残っているだけでは実行できません。取得目的、権限、承認、直前の処理状態をもう一度確認します。適切なツールが一覧にない場合に、顧客情報検索や同期機能を代用品として使うことはしません。
AWSの冪等API設計は、応答がなくても処理が行われている可能性と、重複適用を避けるためのサービス側の契約を説明しています。誤って同期を始めた後にタイムアウトしたなら、次のツールを動かす前に、先の要求が遅れて索引を更新しないかも確認します。照会や重複防止を確認できなければ保留し、要求IDがあるだけで安全に再送できるとは扱いません。
この例の二回枠を使い切ったら、自動探索を終了します。利用者へ返すのは、確認できた依頼条件、未取得の資料、使える機能の不足、再開に必要な資料や権限です。制限を黙って増やさず、資料の提供や管理者によるツール説明の修正を待ちます。管理者は、候補を絞れたか、実行前に拒否できたか、無関係な結果を回答へ混ぜなかったかを別々に確認することで、選択機能の改善点を見つけられます。
基本から確認する：この記事の前提になる考え方は、「AIエージェントの安全設計（権限・外部資料・承認・検証の基本）」にまとめています。
