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

> AI AgentにおけるToolの定義、Function CallingやAPI、MCPとの違い、Schema・認可・副作用を含む実装判断を整理します。

Canonical URL: https://labs.eastbraver.com/guides/tool
Published: 2026-07-01
Updated: 2026-07-24
Category: field-guide
Tags: ai-agent, software-engineering, safety

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

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

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

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

[OpenAIのFunction Calling](https://developers.openai.com/api/docs/guides/function-calling)では、ToolをJSON Schemaで定義し、モデルが返したFunction callをアプリケーション側で実行して結果を返す流れが示されています。

[ClaudeのTool Use](https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview)も、Tool名、説明、Input Schemaをモデルへ渡し、Tool UseとTool Resultを会話へ組み込む構成です。

### LLM Tool callの実行sequence

LLMはToolを直接実行せず、ApplicationへTool callとargumentsを返します。Applicationが検証と認可を行い、実行結果をLLMへ戻した後にResponseを確定します。

- ApplicationがUser requestとTool definitionsをLLMへ送ります。
- LLMがTool callを返し、Applicationがargumentsを検証して認可します。
- ApplicationがToolを実行し、結果またはerrorをLLMへ返します。
- LLMが処理を継続または回答し、ApplicationがUserへResponseを返します。

*User requestからTool実行と最終Responseまでのsequence*

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

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

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

| 用語 | 主な役割 | 実行主体 |
| --- | --- | --- |
| Tool | モデルへ提供する機能の単位 | アプリケーションまたは提供基盤 |
| Function Calling | モデルがTool名と引数を構造化して返す仕組み | モデルAPIとアプリケーション |
| HTTP API | システムが機能やデータを提供するInterface | API Server |
| MCP Tool | MCP ServerがProtocol経由で公開するTool | MCP Serverと接続Host |
| [Skill](/guides/skill) | 手順・知識・Tool利用方法をまとめた実行ガイド | Agentや実行環境によって異なる |

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

[MCPのTools仕様](https://modelcontextprotocol.io/specification/2025-11-25/server/tools)は、ServerがTool一覧とInput Schemaを公開し、Clientから呼び出しを受けるProtocolを定義しています。[MCP](/guides/mcp)はToolだけでなく、接続、Capability、Resources、Prompts、Transportも扱います。

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

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

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

```text
call_api(method, path, body)
```

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

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

```text
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と再試行可否を決める
- 実行前に[承認](/guides/human-in-the-loop)が必要な操作を分ける
- 実行者、引数、結果を監査できる
- 失敗時の取消または補償処理を決める

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

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

## よくある誤解

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

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

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

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

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

Promptはモデルの判断材料です。強制力のあるアクセス制御ではありません。外部コンテンツ経由の[プロンプトインジェクション](/guides/prompt-injection)も同じ理由で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](/guides/llm)が賢くなっても、Toolの実行責任はシステム側に残ります。

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

## 関連記事

- [AI Agent 時代に、エンジニアは何を設計する人になるのか](/blog/ai-development-20260706)
- [エージェント基盤は非同期運用へ](/digest/ai-digest-20260708)
- [エージェント運用の境界が具体化](/digest/ai-digest-20260709)

## 検証範囲

- 一次情報: 公式ドキュメント / 仕様書 / 設計面からの分析
- ローカル検証: 手元で再現しています
- 実運用: 本番運用の実績については、このGuideでは触れていません

## 変更履歴

- 2026-07-24: Mermaid図にテキスト等価物を追加
- 2026-07-15: 検証範囲と根拠区分を明示
- 2026-07-01: 初版公開