AI AgentのToolとは — 外部操作を安全に渡すための設計

AI AgentのToolは、モデルが必要に応じて利用を要求できる外部の機能や操作です。検索・データ取得・計算・ファイル更新・チケット作成・メール送信といった処理を、名前・説明・入力Schemaとともにモデルへ提示します。

Toolは、Agentにできることを増やします。同時に、Agentが外部へ与えられる影響も増やします。

ただし、モデルがToolを選ぶことと、実際に処理を実行することは別です。多くのFunction Callingでは、モデルは「このToolを、この引数で呼びたい」というStructured Outputを返します。アプリケーションが入力と権限を確認し、処理を実行して、その結果をモデルへ戻します。

Toolは、モデルと外部システムの実行契約

OpenAIのFunction Callingでは、ToolをJSON Schemaで定義し、モデルが返したFunction callをアプリケーション側で実行して結果を返す流れが示されています。

ClaudeのTool Useも、Tool名、説明、Input Schemaをモデルへ渡し、Tool UseとTool Resultを会話へ組み込む構成です。

この境界が非常に重要です。

LLMはTool呼び出しの候補を生成できますが、利用者のIdentity、現在の権限、在庫や契約状態までは保証しません。実行してよいかどうかは、IdentityとAuthorizationを確認し、アプリケーションとTool側で強制します。

似た用語を分けると、実行責任が見えてくる

既存のHTTP APIをToolの内側から呼ぶ構成は一般的です。Function CallingはモデルAPI上の呼び出し表現で、Toolの業務ロジックそのものではありません。

MCPのTools仕様は、ServerがTool一覧とInput Schemaを公開し、Clientから呼び出しを受けるProtocolを定義しています。MCPはToolだけでなく、接続、Capability、Resources、Prompts、Transportも扱います。

Toolは、既存APIより狭い単位から始める

既存APIをそのまま一つの万能Toolへすると、モデルへ広すぎる操作面を渡すことになります。これは避けたいです。

たとえば、次のToolは避けたい構成です。

call_api(method, path, body)

任意のEndpointとRequest bodyを渡せるため、Tool名とSchemaから業務上の目的や権限を判断できません。

一つずつ、業務操作へ絞ります。

get_order_status(order_id)
create_support_ticket_draft(customer_id, summary)
approve_refund(refund_request_id, approval_token)

読み取り・下書き・承認済み更新を分けると、モデルが選びやすくなります。Toolごとの権限・監査・評価も、だいぶ整理しやすくなると思います。

名前と説明

Tool名は、一つの操作を動詞から表します。説明には、いつ使うか、使ってはいけない条件、返す情報を具体的に書きます。

ただし、説明へ「管理者だけ」と書いても認可にはなりません。Tool選択を助ける説明と、実行を拒否するPolicyは別。ここは混ぜたくないところです。

Input Schema

必須項目、型、Enum、文字数、許容形式をSchemaで制約します。モデルがSchemaに合う引数を返しても、業務上正しい値とは限りません。IDの存在、利用者との関係、現在状態は実行時に検証します。

ResultとError

Tool結果は、モデルが次の判断に使える形で返します。成功、Validation error、Permission denied、Rate limit、再試行可能な一時エラーを区別します。

内部Stack traceや秘密情報を、そのままモデルへ返す必要はありません。利用者へ見せてよい情報と、運用ログへ残す情報も分けます。

更新するToolには、止められる境界を置く

検索や参照と、返金・削除・送信では、失敗時の影響が違います。

更新系Toolでは、少なくとも次を確認します。

• 利用者とAgentのIdentityを区別できる
• Toolごとの最小Scopeを設定できる
• 入力をSchemaと業務ルールの両方で検証する
• Idempotency keyや重複実行防止を持つ
• Timeoutと再試行可否を決める
• 実行前に承認が必要な操作を分ける
• 実行者、引数、結果を監査できる
• 失敗時の取消または補償処理を決める

「モデルが一度だけ呼ぶはず」という前提には置けません。ネットワークTimeout後に再試行され、最初の処理だけ成功している場合もあります。

通常の分散システムと同じく、重複と部分失敗を扱う必要があります。AI Agentだから特別というより、これまでのWebシステムで向き合ってきた問題が、Toolの境界にも出てくるイメージです。

よくある誤解

Toolを登録すれば、モデルが正しく使い分ける

似たTool名、曖昧な説明、重なる責務があると誤選択しやすくなります。正常な依頼だけでなく、誤った呼び出しも含む評価セットで、Tool選択と引数を確認します。

JSON Schemaがあれば入力は安全になる

Schemaは構造を検証します。利用者がその顧客情報を見てよいか、その注文を更新できるかは、認可と業務ルールで別に検証します。

Promptへ禁止事項を書けば危険なToolを止められる

Promptはモデルの判断材料です。強制力のあるアクセス制御ではありません。外部コンテンツ経由のプロンプトインジェクションも同じ理由でPrompt層では止まりません。実行前のPolicy、承認、Tool側の認可で止めます。

Tool数が多いほどAgentは高機能になる

候補が増えると、選択の曖昧さと評価範囲も広がります。役割や処理段階に応じて見せるToolを絞り、不要な管理操作は常時公開しません。

MCP ToolならFunction Callingは不要になる

MCPはHostとServerの接続を標準化します。Host内部でLLMがToolを選ぶ仕組みとして、モデルAPIのFunction Callingを利用する構成もあります。置き換え関係ではありません。

EastBraver Labsの判断基準

EastBraver Labsでは、ToolをAI Agentの機能一覧ではなく、Agentへ許可する業務操作の境界として扱います。

最初に渡すのは、読み取り専用で、結果を人間が確認できるToolです。更新操作は、業務上の一操作へ分割し、最小権限・Idempotency・監査を先に用意します。取り消せない操作には承認を置きます。

Toolを追加するときは、正常系のデモだけでは判断しません。誤ったTool・欠けた引数・権限不足・Timeout・重複実行を評価し、どこで止まるかを確認します。

LLMが賢くなっても、Toolの実行責任はシステム側に残ります。

モデルの判断と、業務上の強制条件を分けられること。Toolを本番へ出す前に、まずここを確認します。

関連記事

• AI Agent 時代に、エンジニアは何を設計する人になるのか
• エージェント基盤は非同期運用へ
• エージェント運用の境界が具体化