AIエージェントのToolとは？
Function Calling・MCPとの違い

AIエージェントが、LLMとの会話だけで仕事を完結できるケースはそれほど多くありません。ここでいうLLM（大規模言語モデル）とは、文章生成や判断を担うAIモデル本体です。Agentとは、そのModelにToolなどを組み合わせ、目的に向かって複数ステップの仕事を進めるシステムです。

最新情報を調べる。

ファイルを読む。

データベースを検索する。

コードを実行する。

GitHubにIssueを作る。

社内システムから情報を取得する。

こうした「外の世界」へアクセスするために必要になるのが、Tool（ツール）です。

ただしAgent開発を学び始めると、

• Tool
• Function Calling
• MCP
• Built-in Tool
• API

と似た言葉が一気に出てきます。

これらは競合する技術ではありません。

それぞれ役割のレイヤーが違います。

Agent
 ↓
Tool
 ├ Platform提供Tool（Built-in / Hosted Tool）
 ├ Application Function（Function Calling）
 └ MCP Serverから提供されるTool（MCP）
 ↓
API / Database / Files / Search / SaaS / Code

1. そもそもAgentにToolはなぜ必要なのか

LLMが得意なのは、入力された情報をもとに、

• 理解する
• 推論する
• 分類する
• 文章を生成する
• 次の行動を考える

ことです。

しかし、モデル単体では必ずしも、

• 今日の情報を検索する
• 自分のPCのファイルを見る
• データベースを書き換える
• コードを実行する
• メールを送る

といった処理はできません。

そこでAgentへ、

必要なときに使える能力

としてToolを与えます。

たとえば旅行予約Agentなら、

Agent
 ├ 検索Tool
 ├ フライト検索Tool
 ├ ホテル検索Tool
 └ カレンダーTool

Coding Agentなら、

Agent
 ├ File Read
 ├ File Write
 ├ Search
 ├ Shell
 ├ Git
 └ Test

という構成が考えられます。

Toolを持つことで、LLMの判断を現実の処理へ接続できるようになります。

2. ToolとAPIは何が違う？

ここも混同しやすい部分です。

APIは、

ソフトウェア同士が機能やデータをやり取りするためのインターフェース

です。

一方Toolは、

Agentから見た「利用できる能力」

です。

たとえば天気APIがあったとします。

開発者から見ると、

GET /weather

というAPIです。

しかしAgentへは、

get_weather(city)

というToolとして見せることができます。

つまり、

Agent
↓
get_weather Tool
↓
アプリケーション
↓
Weather API

です。

APIをそのままAgentへ渡しているわけではありません。

間に、

Agentが理解しやすいToolとしての定義

があります。

この違いは重要です。

3. Function Callingとは？

Function Callingは、モデルがアプリケーション側へ、

「この関数を、この引数で呼んでほしい」

と要求する仕組みです。

OpenAIではFunction Callingを、モデルを外部システムやデータへ接続するための仕組みとして提供しています。

大まかな流れは、

ユーザー
↓
「東京の天気を調べて」
↓
Model
↓
get_weather(city="Tokyo")
↓
Application
↓
Weather API
↓
結果
↓
Model
↓
「東京の天気は……」

となります。

ここで重要なのは、

通常、モデル自身がその関数を直接実行しているわけではない

ということです。

OpenAIのFunction Callingでは、

1. 利用可能なToolをモデルへ渡す

2. モデルがTool Callを返す

3. アプリケーション側がコードを実行する

4. Toolの結果をモデルへ戻す

5. モデルが次の応答または次のTool Callを決める

という流れになります。

4. Toolは「名前」だけでは足りない

AgentへToolを渡すときは、

単に、

「検索できます」

と伝えるだけでは十分ではありません。

一般にToolには、

• Tool名
• 説明
• 入力
• 引数
• 型
• 必須項目

などの定義があります。

たとえば、

search_products

というToolがあったとしても、

「何を検索するToolなのか」

「価格帯を渡せるのか」

「カテゴリ指定が必要なのか」

が分からなければ、モデルは正しく使えません。

そのためTool設計では、

モデルが正しく選び、正しく引数を組み立てられるインターフェースになっているか

が重要です。

OpenAIでは、対応するFunction Callingでstrict: trueを使用することで、生成される引数を定義したJSON Schemaへ準拠させる仕組みも提供されています。

5. Built-in / Hosted Toolとは？

Toolには、開発者が自分で実装するものだけでなく、AIプラットフォーム側が用意しているものもあります。

OpenAIでは、たとえば、

• Web Search
• File Search
• Shell
• Computer Use

など、プラットフォーム側が提供するToolを利用できます。

一方、

• Function Calling
• Remote MCP

は、こうしたBuilt-in Toolそのものではなく、別の方法でAgentへ外部能力を接続する仕組みです。

Google Cloudでも、ADK Agentから利用できるAgent Runtime Code Execution Toolが提供されており、Sandbox環境でAI生成コードを実行できます。

整理すると、Agentが利用できるToolの提供元は以下の3つに分かれます：

Agent
 ├ Platform提供Tool（Built-in / Hosted Tool）
 ├ Application Function（Function Calling）
 └ MCP Serverから提供されるTool（MCP）

6. MCPとは？

MCPはModel Context Protocolの略です。

MCP自体はToolだけでなくResourcesやPromptsなども扱いますが、この記事では「AgentへToolを提供する仕組み」という側面に絞って説明します。

AgentのToolという視点から見ると、

外部のシステムやサービスが持つToolを、共通の方式でAgentへ公開するための仕組み

として理解すると分かりやすくなります。

たとえば、

Agent / Host Application
  ↓
MCP Client
  ↓
MCP Server
  ├ search_projects
  ├ create_issue
  ├ read_document
  └ update_database

という構成です。

MCP Server側が利用可能なToolを公開し、Agent側が必要なToolを利用します。

OpenAIでもMCP Serverを通じてモデルへ新しい機能を提供でき、Tool Callごとに自動許可または明示的な承認を要求する設計ができます。

AnthropicのClaude Platformでも、接続されたMCP ServerのToolをClaudeが状況に応じて選択・呼び出せる仕組みが提供されています。

7. Function CallingとMCPは何が違う？

ここがこの記事の中心です。

簡単に整理すると、

重要なのは最後です。

Agentから見ると、どちらも「使えるTool」です。

したがって、

Function CallingとMCPはどちらを選ぶべきか

という二択にする必要はありません。

たとえば、

Agent
├ Function Calling → 自社API
├ MCP → GitHub
├ Built-in Tool → Web Search
└ Built-in Tool → Shell

という混在も自然です。

8. MCPがあるならFunction Callingは不要になる？

なりません。

たとえば、自社アプリケーション内の小さな関数をAgentから呼びたいだけなら、

Function Callingで十分な場合があります。

一方、

• 複数のAgent Clientから使いたい
• 外部サービスがTool群を提供する
• Tool Discovery（利用可能なToolを検索・発見する仕組み）を標準化したい
• 接続方式を共通化したい

といった場合には、MCPの価値が大きくなります。

つまり、

Function Callingは実行インターフェースの一つ。MCPはTool提供・接続を標準化するための仕組み。

と考えます。

MCPそのものを学ぶ意味や、API・CLI・Gitとの違いについては、「MCPは学ぶべき？AIエージェント時代に必要なAPI・Git・CLIとの違い」で詳しく整理しています。

9. AntigravityやClaude CodeでもToolは重要なのか？

重要です。

Coding Agentが実際にコードを変更できるのは、モデル性能だけが理由ではありません。

Agentが、

• ファイルを読む
• ファイルを書き換える
• リポジトリを検索する
• コマンドを実行する
• テストする
• ドキュメントを調べる

といったToolを使えるからです。

Googleでは、Agents CLIを使って、AntigravityやClaude Code、CursorなどのCoding AgentへADK開発のSkillsを追加できます。また、ADK Docs MCP Serverを接続すれば、Coding AgentからADKの公式Documentationを検索・参照できます。

Anthropicも、高度なAgentが多数のToolを扱うにつれ、Tool DiscoveryやTool Callingの信頼性が重要になると説明しています。

つまりCoding Agentの性能を見るときも、

どのモデルを使っているか

だけでは不十分です。

同時に、

どのToolを、どのような条件で、どの程度正確に使えるか

を見る必要があります。

10. Toolが増えればAgentは強くなるのか？

必ずしもそうではありません。

Toolを大量に、あるいは役割の似たToolを多数与えると、

• どのToolを使えばよいか迷う
• 類似Toolを取り違える
• 間違った引数を渡す
• 必要のないToolを呼ぶ
• Contextを圧迫する

といった問題も起こります。現在はこうした問題に対応するため、すべてのToolを常にContextへ載せるのではなく、必要なToolだけを動的に発見・読み込むTool Search / Tool Discoveryの仕組みも登場しています。

したがってAgent設計では、

Toolの数を増やすことより、必要なToolを分かりやすく定義すること

が重要です。

Tool名や説明も、人間だけが理解できればよいわけではありません。

モデルが正しく意味を理解できる設計である必要があります。

11. Toolは「能力」であると同時に「権限」でもある

ここは非常に重要です。

Agentへ、

delete_file()

というToolを与えれば、

Agentはファイルを削除できる可能性があります。

send_email()

を与えれば、外部へメールを送れる可能性があります。

execute_shell()

なら、コマンドを実行できます。

つまりToolを追加するということは、

Agentへ新しい能力を与える

だけではなく、

Agentへ新しい権限を渡す

ことでもあります。

だから、

使えるTool
≠
自由に実行してよいTool

と考える必要があります。

重要な操作では、

Agentが操作を提案
↓
人間が承認
↓
Tool実行

というHuman-in-the-loop（重要な操作に人間の確認・承認を挟む設計）も考えられます。OpenAIのRemote MCPや各種Agent基盤でも、Tool Call前にApproval（承認）を要求する設計が可能です。

Toolの安全な実行環境や権限設計については、シリーズ第6回「AIエージェントのSandboxとは？コード実行・ファイル・権限の安全設計」で詳しく扱います。

12. Toolを使えばAgentになるのか？

ここも注意が必要です。

Function Callingができるシステムが、すべてAgentとは限りません。

たとえば、

という一度だけのTool CallでもFunction Callingは成立します。

一方Agentでは、

Goal
↓
状況判断
↓
Tool選択
↓
結果確認
↓
次の行動判断
↓
別Tool
↓
結果確認
↓
完了判断

という複数ステップのループを持つ場合があります。

したがって、

Tool CallingはAgentを構成する重要な能力だが、Tool CallingそのものがAgentではない

と整理します。

13. Agent設計では「何をToolにするか」が重要になる

APIが100個あるからといって、

100個すべてをそのままAgentへToolとして公開する必要はありません。

むしろ重要なのは、

Agentが仕事を完了するために必要な単位でToolを設計すること

です。

OpenAIのTool設計ガイドでも、内部APIをそのままToolとして公開するのではなく、ユーザーが達成したい結果からToolを考えることが推奨されています。

たとえばECサイト内部に、

get_customer
get_orders
get_inventory
update_order
create_shipping_label
send_notification

というAPIがあったとしても、

Agentへどの粒度で見せるかは別問題です。

Agent設計では、

API設計

だけではなく、

Agentに何を一つの「行動」として認識させるか

を考える必要があります。

14. Tool設計から、Agent Architectureへ

Toolが一つ、二つならSingle Agentでも扱いやすいでしょう。

しかし仕事が大きくなると、

• 調査担当
• コーディング担当
• レビュー担当
• データ分析担当

のように役割を分けた方が良いケースも出てきます。

そこで次の問題が生まれます。

一つのAgentにすべてのToolを持たせるべきなのか。

それとも、

役割ごとにAgentを分け、それぞれ必要なToolだけ持たせるべきなのか。

これはToolの問題から、Agent Architecture（Agentの役割分担やTool配置を含む設計構成）の問題へ変わります。

この判断については、シリーズ第4回「Single vs Multi-Agentの違い」で詳しく整理します。

まとめ

AIエージェントにおけるToolとは、

Agentが外部の情報やシステムへ働きかけるための能力

です。

そして、

Function Calling

＝モデルからアプリケーション側の機能を呼ぶ仕組み

MCP

＝外部Toolを標準化して公開・接続する仕組み

Built-in Tool

＝Agent基盤側があらかじめ提供する機能

と整理できます。

最も重要なのは、

Agent
↓
Tool
↓
外部世界

という関係です。

モデルがどれだけ賢くても、Toolがなければできない仕事があります。

一方でToolを与えるほど、

できることだけでなく、与える権限も増えます。

Agent設計では、

何をToolにするか

どのAgentへ渡すか

どこまで自動実行させるか

まで考える必要があります。