Tool Calling vs MCP：違いと使い分け

Tool Callingは、モデルが関数呼び出しを要求し、アプリケーションがコードを実行する言語モデルAPIの機能です。Model Context Protocol (MCP)は、AIアプリケーションが外部サーバーの公開するツールを検出して呼び出せるようにする、オープンなJSON-RPC標準です。MCPはTool Callingに代わるものではなく、その仕組みを土台として使います。

AIエージェントやLLMを使ったバックエンドを開発していると、各社のドキュメントで両方の用語によく出会います。Tool CallingとMCPを理解するには、モデルが関数の実行をどう判断するかと、アプリケーションがその関数のあるシステムにどう接続するかを分けて考える必要があります。

LLM APIのTool Callingとは？

Tool Calling（function callingとも呼ばれます）は、自然言語のプロンプトを構造化された関数呼び出しに変換するモデルAPIの機能です。APIリクエストで名前、説明、JSON Schemaのパラメーターを使って関数定義を渡すと、モデルは関数名と引数を含む構造化された呼び出しを返すかどうかを判断します。

モデル自体は関数を実行しません。Tool Callingは、アプリケーションとモデルの間の複数ステップのやり取りとして動作します。

ツール宣言を送信する： アプリケーションはモデルにリクエストし、モデルが呼び出せるツールのJSON Schema定義を含めます。
構造化されたツール呼び出しを受け取る： モデルは選択した関数名とJSON引数を含むツール呼び出しを返します（たとえばAnthropicはtool_useの停止理由とブロックを返します）。
アプリケーション側でコードを実行する： バックエンドが引数を検証し、ローカル関数または内部APIリクエストを実行します。
ツールの結果を返す： アプリケーションは結果（tool_resultブロックなど）を含む2回目のリクエストをモデルに送ります。
最終回答を受け取る： モデルは結果を使ってユーザーに回答するか、追加のツール呼び出しを要求します。

OpenAIの関数定義はJSON Schemaのparametersを使用し、スキーマへの準拠を徹底するためにstrict: trueをサポートしています。

{
  "type": "function",
  "name": "get_weather",
  "description": "Get the current weather for a given location.",
  "strict": true,
  "parameters": {
    "type": "object",
    "properties": {
      "location": {
        "type": "string"
      }
    },
    "required": ["location"],
    "additionalProperties": false
  }
}

主要なモデルAPIでは、モデルによる関数選択を細かく制御できます。OpenAIとGoogle GeminiのAPIでは、tool_choiceを使って選択をauto（デフォルト）のままにする、1つ以上の呼び出しを強制する（OpenAIではrequired、Geminiではany）、ツールを無効にする（none）、allowed_toolsでモデルを一部のツールに制限する、またはGeminiのvalidatedモードで関数スキーマへの準拠を保証することができます。OpenAIとGeminiはいずれも並列関数呼び出しに対応し、モデルは1ターンで複数の関数を呼び出せます。OpenAIでは、1ターンにつき最大1回の呼び出しにしたい場合、parallel_tool_callsをfalseに設定できます。Geminiは、複数ステップを順次実行するための合成呼び出しにも対応しています。

Anthropicはコードの実行場所によってツール使用を区別します。クライアントツール（独自の関数や、bash、text_editorなどAnthropicのスキーマに従うツール）はアプリケーション内で実行されます。サーバーツール（web_search、web_fetch、code_execution、tool_searchなど）はAnthropicのインフラ上で直接実行されます。

Model Context Protocol (MCP)とは？

Model Context Protocol (MCP)は、JSON-RPC 2.0を介してAIアプリケーションを外部システムに接続するオープンソース標準です。Language Server Protocolに着想を得たMCP仕様（バージョン2026-07-28）は、AIアプリケーションにとってUSB-Cポートのように機能し、一つのサーバー統合をChatGPT、Claude、Visual Studio Code、Cursor、独自のエージェントで利用できます。

MCPは責任を3つの役割に分けます。

ホスト（Hosts）： 接続を開始するLLMアプリケーション（IDEやチャット画面など）。
クライアント（Clients）： ホストアプリケーション内で動作するプロトコル接続部分。
サーバー（Servers）： クライアントに機能とコンテキストを公開する外部サービス。

2026-07-28の仕様では、基本プロトコルはステートレスで自己完結したJSON-RPC 2.0リクエストを使い、リクエストごとに機能をネゴシエーションします。MCPは2つの標準トランスポートを定義しています。stdioは、クライアントが起動したサブプロセスの標準入力と標準出力を介して改行区切りのメッセージを渡します。Streamable HTTPでは、各メッセージが単一のMCPエンドポイントへのHTTP POSTになります。開発者は独自のトランスポートも実装できます。

LLMのTool Callingが関数のみを扱うのに対し、MCPサーバーは3つの主要機能を公開できます。

Tools： AIモデルが実行する関数。
Resources： アプリケーションが読み取れるコンテキストとデータ。
Prompts： ユーザー向けのメッセージテンプレートとワークフロー。

クライアント側では、MCPはサーバーがユーザーに追加情報を要求できるElicitationをサポートします。2026-07-28の仕様には、Tasks（非同期の長時間実行操作）、Skills over MCP、MCP Apps（インラインで表示されるインタラクティブなUI要素）向けの、オプトインでネゴシエーションする拡張も含まれます。

ツールの実行にあたり、MCPクライアントはページネーションとキャッシュに対応するtools/listを呼び出して利用可能なツールを検出します。listChanged機能を宣言するサーバーは、利用可能なツールが変わるたびにクライアントに通知できます。各MCPツール定義には、大文字と小文字を区別するname（推奨は1〜128文字）、任意のtitle、description、任意のicons、inputSchema（デフォルトはJSON Schema 2020-12）、任意のoutputSchema、任意のアノテーションが含まれます。

モデルがMCPツールの使用を決めると、クライアントはtools/callのJSON-RPCリクエストをサーバーに送ります。

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {
      "location": "San Francisco, CA"
    }
  }
}

サーバーでのツール実行が失敗した場合、MCPは結果内にisError: trueとともにエラーを返します。これにより言語モデルは失敗を読み取り、自ら修正できます。

Tool CallingとMCPの比較

LLMのTool CallingとMCPを直接比較すると、両者がスタックの異なる層で動作することがわかります。2026年11月時点で、ネイティブのTool CallingとModel Context Protocolは、アーキテクチャの7つの観点で次のように異なります。

観点	Tool Calling (Function Calling)	Model Context Protocol (MCP)
概要	LLMが構造化された関数引数を出力するモデルAPI機能	AIのホストとクライアントを外部サーバーに接続するオープンなJSON-RPC 2.0プロトコル
ツールの定義者	モデルAPIリクエスト内のアプリケーションコード（またはプロバイダーのサーバーツール）	Tools、Resources、Promptsを公開するMCPサーバー
コードの実行場所	アプリケーションのバックエンド（サーバーツールの場合はLLMプロバイダーのクラウド）	ローカルのサブプロセス（`stdio`）またはリモートサービス（Streamable HTTP）
検出	APIリクエストごとに静的。コードがモデル呼び出し前にスキーマを固定または選択	`tools/list`と`listChanged`通知により実行時に動的に検出
トランスポート	プロバイダーのHTTPS API（OpenAI、Anthropic、Google Gemini）	`stdio`、Streamable HTTP、または独自のトランスポート
クライアント間の移植性	アプリと特定のLLMプロバイダーのスキーマ形式に依存	MCP対応のあらゆるホスト間で移植可能（Claude、ChatGPT、VS Code、Cursor、独自アプリ）
コスト	ツール定義の入力トークン、呼び出しの出力トークン、プロバイダーのサーバーツールの追加料金	読み込んだ各ツールスキーマの入力トークンと、MCPサーバーのホストまたは実行に必要なインフラ

MCPはFunction Callingに取って代わる？

MCPはFunction Callingに取って代わりません。言語モデルは引き続きTool Callingを使って各MCPツールを選択し、呼び出すからです。Tool CallingとMCPは、同じリクエストのライフサイクルにおける相補的な層です。

AIアプリケーションがMCPサーバーに接続すると、ワークフローは両方の仕組みを組み合わせます。

MCPによる検出： ホストアプリケーションのMCPクライアントがMCPサーバーにtools/listリクエストを送り、サーバーのツール名、説明、JSON SchemaのinputSchemaオブジェクトを受け取ります。
LLM向けの整形： ホストはMCPツール定義をLLMプロバイダー固有のtools配列に変換し、ユーザーのプロンプトとともに送ります。
Tool Callingによる選択： 言語モデルはプロンプトを評価し、選択したツール名と引数を含む標準的なツール呼び出しを出力します。
MCPによる実行： ホストはモデルのツール呼び出しを受け取り、MCPのtools/callリクエストに対応付け、stdioまたはStreamable HTTP経由でMCPサーバーに送ります。
完了： MCPサーバーが結果を返し（実行失敗時はisError: true付き）、ホストがその出力をツール結果としてモデルに渡すと、モデルは最終回答を生成します。

モデルAPI内にTool Callingがなければ、LLMにはMCPツールを起動する仕組みがありません。MCPがなければ、アプリケーションは各ツールのスキーマと実行ハンドラーを手動で結び付ける必要があります。

OpenAI、Anthropic、GoogleはMCPをどう直接サポートしている？

OpenAI、Anthropic、Googleでは、リモートMCPサーバーを組み込みのツール型としてモデルAPIに直接渡せるようになりました。tools/listとtools/callをつなぐ独自のMCPクライアントループを書く代わりに、モデルプロバイダーのAPIが利用者に代わってMCPサーバーに接続します。

2026年11月時点で、各社はそれぞれ固有の機能と文書化された制限を伴う直接MCPサーバー接続を実装しています。

OpenAI Responses API

OpenAI Responses APIでは、ツール配列に"type": "mcp"をserver_labelおよびserver_urlとともに指定してMCPサーバーを接続できます。OpenAIは本番環境向けに2つの重要な制御を用意しています。

allowed_tools： MCPサーバーから特定の一部のツールだけをインポートし、モデルのコンテキストが過負荷になるのを防ぎます。
require_approval： ツール呼び出しを自動実行するか、明示的な人間の承認を待つかを設定します。

ローカルまたはプライベートなサービス向けに、OpenAIはSecure MCP Tunnelを提供しています。これにより内部MCPサーバーをインターネット上に公開せずに接続できます。

Anthropic MCP Connector

AnthropicはMessages APIでベータ版のMCP connector（mcp_serversとmcp_toolset）を提供しており、別途クライアントを実装せずにリモートMCPサーバーに接続できます。文書化された4つの制限に注意してください。

ツールのみ： コネクターはMCP仕様のツール呼び出しのみをサポートします（MCPのResourcesやPromptsは対象外です）。
公開HTTPが必要： MCPサーバーはHTTPで一般公開されている必要があります（Streamable HTTPとSSEをサポート）。
ローカルのstdioへの直接接続不可： ローカルのstdioサーバーはMessages APIに直接接続できませんが、AnthropicのSDKはローカルサーバー向けのクライアント側ヘルパーを提供します。
コンプライアンス上の対象外： ベータ版MCP connectorはZero Data Retention (ZDR)やHIPAAのワークロードには適用できません。

Google Gemini Interactions API

GoogleのGemini Interactions APIは、"type": "mcp_server"宣言を使って外部MCPサーバーを受け入れ、name、url、headers、allowed_toolsで設定します。Googleはこの統合に2つの厳格なルールを設けています。

Streamable HTTPのみ： Gemini Interactions APIはStreamable HTTPサーバーをサポートし、SSEトランスポートはサポートしません。
名前の構文： サーバー名にはsnake_caseを使用し、ハイフンを含めることはできません。

Tool CallingとMCPはいつ使い分ける？

MCPとTool Callingの使い分けは、誰が統合を管理し、いくつのアプリケーションで共有する必要があるかによって決まります。よくある3つのパターンに照らして、プロジェクトの制約を確認しましょう。

単純なTool Callingで十分な場合

ツールが単一のアプリケーションバックエンド内にあり、外部クライアントが呼び出す必要がない場合は、ネイティブのLLM Tool Callingを使い続けましょう。私が5つの内部データベースクエリとStripeのチェックアウト処理を備えたウェブアプリを作るなら、MCPサーバーを作ると不要なネットワーク経由やサブプロセスが増えます。

単純なTool Callingが適しているのは、次の場合です。

自社のデータベースや内部マイクロサービスを照会する少数の関数しかない。
コードベース全体を管理しており、低いレイテンシーとプロセス内での直接検証を求めている。
他のAIアシスタント、IDE、チームがそれらの関数を検出したり再利用したりする必要がない。

MCPサーバーが役立つ場合

同じツールを複数のAIクライアントで使う必要がある場合や、基盤となるシステムを別のチームが管理している場合は、MCPサーバーを構築または採用しましょう。開発プラットフォームが課題追跡やデプロイログをMCP経由で公開していれば、開発者はスキーマを書き直さずに、まったく同じサーバーをClaude、ChatGPT、Visual Studio Code、Cursor、社内エージェントに接続できます。

MCPが役立つのは、次の場合です。

一度作成したものを複数のAIホストや開発者向けIDEで利用できるようにしたい。
サードパーティのベンダーや別の社内チームが統合を管理している。
実行時の機能変更に合わせ、エージェントが動的なツール検出（tools/listとlistChanged）に依存している。
ワークフローで関数実行に加え、MCPのResources、ユーザー向けプロンプトテンプレート、ユーザーへの情報要求が必要である。

ハイブリッド構成

AIエージェントを試験運用から本番環境へ移行するチームでは、両方のアプローチを組み合わせるパターンが一般的です。典型的なアプリケーションは、レイテンシーの影響を受けやすい少数のネイティブ関数ツールをコードで定義すると同時に、サードパーティのSaaS統合用に1つか2つの外部MCPサーバーを接続し、allowed_toolsで不要なエンドポイントを除外します。

セキュリティ、レイテンシー、トークンコストのトレードオフ

ネイティブ宣言またはMCPサーバーを通じてLLMアプリケーションにツールを追加すると、トークンコスト、キャッシュに関する考慮事項、セキュリティ上の境界が生じ、慎重な管理が必要になります。

入力トークンのコストとプロンプトキャッシュ

モデルAPIに渡すすべてのツール定義は入力トークンに計上されます。Anthropicは、toolsパラメーター内のツール定義が入力トークンに計上されると明記しています。OpenAIは、一部のMCPサーバーが一度に数十のツールを公開しており、多数のツールを公開するとコストとレイテンシーの両方が増える可能性があると指摘しています。

トークン費用を予測しやすくするには、次の対策を取ります。

インポートするツールを絞り込みます。OpenAIとGoogleはallowed_toolsを使い、AnthropicのMCP connectorではmcp_toolset内の個々のツールの許可、拒否、設定ができます。
ツールリストの順序を決定的に保ちます。MCP仕様によると、tools/listの順序が決定的であれば、クライアントがツールリストをキャッシュしやすくなり、ツール定義がモデルのコンテキストに置かれる場合にLLMのプロンプトキャッシュのヒット率も向上します。

信頼境界と人間による承認

ツールは任意のコード実行を伴います。これは、オペレーティングシステム全体を操作するコンピューター操作AIエージェントも導入する場合、さらに重要な懸念となります。サードパーティのMCPサーバーに接続すると信頼境界を越えることになり、信頼できないツールの説明やサーバーの応答がプロンプトインジェクションの経路になり得ます。

MCP仕様は、信頼できるサーバーからのものでない限り、ツールのアノテーションを信頼できないものとして扱うよう明示的に警告しています。MCPは通信プロトコルのレベルで安全性を強制できないため、仕様ではホストアプリケーションがツールを呼び出す前に必ずユーザーの明示的な同意を得る必要があり、呼び出しを拒否できる人間を常に介在させるべきだとしています。OpenAIのResponses APIのような直接API統合を使う場合は、機密性の高いツールでrequire_approvalを有効にし、実行前に人間が引数を確認できるようにします。

FAQ

MCPはFunction Callingと同じですか？

いいえ。Function Calling（Tool Calling）は、LLMが名前付き関数を実行するための構造化されたJSONリクエストを出力するモデルAPIの仕組みです。Model Context Protocol (MCP)は、AIアプリケーションが外部サーバー上のTools、Resources、Promptsを検出して呼び出せるようにするオープンな通信標準です。

Tool CallingなしでMCPを使えますか？

MCPのResourcesやプロンプトテンプレートは、ホストアプリケーションまたはユーザーが読み取るか起動するため、モデルのTool Callingなしで使えます。ただし、AIモデルがtools/callを介して自律的にMCPツールを呼び出す場合は、そのツールを選ぶために基盤となるネイティブのTool Calling機能を使います。

MCPはネイティブのTool Callingより多くのトークンを消費しますか？

個々のツール定義の入力トークン数は、アプリがローカルコードとMCPサーバーのどちらから読み込んでも同じです。ただし、単一のMCPサーバーが一度に数十のツールを公開することがあるため、allowed_toolsでリストを絞り込まない限り、実際にはMCP構成の方が多くのトークンを消費することがよくあります。

APIでMCPサーバーをネイティブにサポートするLLMプロバイダーは？

2026年11月時点で、OpenAI、Anthropic、GoogleはいずれもAPIでリモートMCPサーバーを直接受け入れます。OpenAIはResponses APIで"type": "mcp"をサポートし、AnthropicはMessages APIでベータ版MCP connector（mcp_serversとmcp_toolset）を提供し、GoogleはGemini Interactions APIで"type": "mcp_server"をサポートします。

AnthropicのAPIはローカルのstdio MCPサーバーに直接接続できますか？

いいえ。AnthropicのMessages APIのベータ版MCP connectorは、HTTPで一般公開されたリモートMCPサーバー（Streamable HTTPとSSE）にのみ接続します。ローカルのstdio MCPサーバーをClaudeで使用するには、AnthropicのSDKヘルパーを使ってクライアント側で接続を実行する必要があります。

Tool Calling vs MCP：違いと使い分け

LLM APIのTool Callingとは？

Model Context Protocol (MCP)とは？

Tool CallingとMCPの比較

MCPはFunction Callingに取って代わる？