MCP vs Function Calling：AI Agentのツール呼び出しの違いとは？JSON Schema、API、Tool Callingを徹底比較

MCPとFunction Callingは通常どちらか一方を選ぶものではなく、単一アプリケーションならFunction Calling、多数のクライアントでツールを共有するならMCPを組み合わせる設計が適切です。Function Callingはモデルが「どのツールを、どの引数で呼ぶか」を表現し、MCPはアプリケーションが標準化された方法でツールを発見・接続する役割を担います。

この記事は、少数のAPIを組み込む単一アプリケーションの開発者、複数モデルを扱うプラットフォームチーム、既存のFunction Calling実装をMCPへ移行する責任者を対象にしています。過剰なプロトコル化を避けながら、将来の共有・監査・権限管理まで見据えた境界を整理します。

最初に押さえるべき層の違い

Function Callingでは、アプリケーションがモデルへ関数名、説明、引数のスキーマを渡します。モデルは関数を直接実行せず、呼び出し名と引数を返し、実際のAPI実行と結果の再送はアプリケーション側が担当します。これは複数のモデルAPIで共通する基本的な流れです。(ai.google.dev)

一方、Model Context Protocolは、ホスト、クライアント、サーバーの構成で外部ツールやリソースを接続するプロトコルです。MCPのメッセージはJSON-RPC 2.0を基盤とし、サーバーはツール一覧や入力スキーマをクライアントへ返します。(modelcontextprotocol.io)

MCPとTool Callingはそれぞれどの層にありますか。
Tool Callingは、モデルがツールを選び、構造化された引数を返すモデル連携の層です。MCPは、そのツールをどこから発見し、どの接続経路で呼び出し、どのサーバー境界で管理するかを定める接続層です。

JSON Schemaは共通言語ですが、責任範囲は同じではありません

両者でJSON Schemaが登場するため、同じ仕組みに見えやすい点が設計上の混乱を招きます。Function Callingでは、モデルに渡す関数引数を構造化し、アプリケーションが受け取った値を検証するために使います。MCPでは、ツールの入力仕様をクライアントへ伝える契約として使われ、仕様によっては出力形式も定義できます。(modelcontextprotocol.io)

ただし、Schemaに適合したJSONが返ったからといって、操作が安全とは限りません。例えば「請求書を発行する」という引数が正しい型であっても、対象アカウント、金額上限、操作者の権限、二重実行防止は業務APIや実行層で判定する必要があります。

MCPの仕様でも、ツールは任意のコード実行やデータアクセスにつながるため、ユーザーの同意、認証、権限管理を実装側で設ける必要があるとされています。プロトコルだけで安全性が自動的に成立するわけではありません。(modelcontextprotocol.io)

注意：入力Schemaの検証、MCPサーバーの認証、業務APIの最終認可は別々に実装します。どれか1つを追加しただけで、ユーザー確認や監査が不要になるわけではありません。

単一アプリケーションではFunction Callingを先に選ぶ

Agentが1つで、接続するツールも社内APIや検索APIなど少数に限られる場合、アプリケーションからモデルへ直接ツール定義を渡す構成が扱いやすいです。呼び出し、リトライ、タイムアウト、APIエラーの変換を同じコードベースで追跡できるため、MCPサーバーを別に運用する負担を増やさずに済みます。

Agentが1つだけでもMCPは必要ですか。
必須ではありません。将来的に複数のAgentや開発環境へ同じツールを公開する計画がなければ、まずFunction Callingで実装し、内部のツールインターフェースとSchemaにバージョンを持たせる方が移行しやすいです。

この表のスコアは機能の優劣ではなく、各構成が想定シナリオに適合する度合いです。ツール数だけでMCP導入を決めるのではなく、クライアント数と運用境界を優先して判定します。

複数モデルを扱うチームには内部適応層が必要です

複数モデルを切り替える場合、Function Callingの名称、引数表現、ツール結果の返し方、強制呼び出しの指定方法が完全には一致しません。そこで、モデル固有のリクエスト形式を業務コードへ直接流し込まず、内部イベントへ変換します。

例えば内部形式を次のように固定します。

{
  "event": "tool_call_requested",
  "tool": "create_invoice",
  "arguments": {
    "customer_id": "customer_123",
    "amount": 10000
  },
  "request_id": "req_001"
}

モデル側のレスポンスをこの形式へ変換し、実行結果もtool_resultとして統一してから各モデルへ戻します。こうすると、モデルを切り替えるたびにAPI実行、監査、リトライのロジックを書き直す必要がありません。

MCPはモデル間の差異も消しますか。
消しません。MCPはツールの接続と発見を標準化しますが、モデルがどのようにツールを選択し、並列呼び出しや強制呼び出しを扱うかは、利用するモデルAPIとクライアント実装に依存します。MCPの前段には、必要に応じて内部適応層を残します。

多数のクライアントで共有するならMCPの効果が大きくなります

同じ社内検索、チケット管理、Git操作、Mac上のビルド処理を複数のAgentやIDEから利用する場合、各アプリケーションに接続コードを重複して持たせると、認証更新やSchema変更のたびに修正範囲が広がります。

MCPでは、クライアントがtools/listで利用可能なツールを発見し、サーバーがツール名、説明、入力Schemaを公開できます。ツール一覧は認証スコープによって変えられるため、全ユーザーへ同じ権限を配る必要もありません。(modelcontextprotocol.io)

ただし、共有化には新しい管理対象が増えます。

1. MCP Serverごとに所有チームと責任範囲を決めます。
2. ツール名、入力Schema、出力Schemaに互換性ルールを設けます。
3. 認証情報をクライアント設定へ直接埋め込まず、実行サーバー側で管理します。
4. tools/listで公開される一覧を環境ごとに確認します。
5. 失敗、拒否、タイムアウト、再実行を監査ログへ記録します。
6. 破壊的操作にはユーザー確認と業務API側の認可を重ねます。

リモートMCPではプロトコルより運用設計が難しくなります

ローカルのstdio接続では、クライアントがMCP Serverを子プロセスとして起動できます。チームで共有するリモート構成では、Streamable HTTPなどの通信経路、認証、接続監視、障害時の切り戻しが必要になります。公式仕様でも、HTTP接続ではOrigin検証や適切な認証が推奨されています。(modelcontextprotocol.io)

MCPは業務APIを直接実行できますか。
MCP Serverに業務APIを呼び出す実装を持たせることはできますが、MCP自体が業務APIの認可を代行するわけではありません。MCP ServerはAPIの前段にあるツール接続口であり、最終的な認可、監査、トランザクション制御は業務システム側で継続して実施します。

macOS固有のビルド、署名、Xcode操作、専用アプリ連携などをツール化する場合は、MCPの規格上Macが必要になるのではなく、実行環境がmacOSを要求するためMacを選びます。検証用のMacを短期間だけ確保したい場合は、Macクラウドレンタルの利用方法を確認し、常駐Serverとして使うのか、必要時だけ起動するのかを分けて考えます。

高リスク操作は二層ではなく三層で止めます

削除、送金、公開、署名、顧客情報の変更などは、モデルの判断だけに任せません。モデル側ではツール選択を制限し、MCPまたは実行ゲートウェイでは接続先と権限を制御し、業務APIでは最終認可を実行します。

MCPのツール仕様では、人間が呼び出しを拒否できる確認経路を設ける考え方が示されています。したがって、自動化率を上げる場合でも、操作の種類ごとに確認を省略できる条件を明文化します。(modelcontextprotocol.io)

第1段階：移行前に境界を固定します

既存コードをそのままMCP Serverへ移植するのではなく、まず次の順序で分離します。

1. モデルAPI固有のツール定義をアダプターへ移します。
2. 内部イベントとSchemaを固定します。
3. 実行関数を認証、入力検証、業務API呼び出しに分けます。
4. 同じツールを直接Function Callingで呼ぶ最小サンプルを作ります。
5. 同じ実行関数をMCP Serverから公開する最小サンプルを作ります。
6. 正常系だけでなく、権限拒否、Schema不一致、タイムアウト、重複実行を比較します。
7. MCP仕様またはモデルAPIを更新したときに、両方のサンプルを再実行します。

この比較では、単純な応答速度だけでなく、コードの所有範囲、秘密情報の流れ、エラーの責任者、監査ログの粒度を確認します。MCP導入の成否は、ツール呼び出しが一度成功することより、失敗時にどの層が止められるかで決まります。

最終判断は「ツール数」ではなく「共有と治理」で決めます

MCPはFunction Callingを置き換えますか。
通常は置き換えません。Function Callingはモデルに呼び出し意図を出させる仕組みであり、MCPはアプリケーションとツールの接続を標準化する仕組みです。両者を同じ層の競合製品として比較すると、設計判断を誤ります。

MCPとFunction Callingはどのように組み合わせますか。
MCPクライアントがサーバーからツール定義を取得し、Agentが利用するモデル形式へ変換します。モデルが返したFunction Callingの要求をクライアントがMCPのツール呼び出しへ変換し、結果を再びモデルへ返す流れが基本形です。

既存の単一AgentならFunction Callingのみで始め、複数モデル対応が必要になった時点で内部適応層を追加し、複数クライアントで同じツールを共有する段階でMCPを加えるのが移行リスクを抑えやすい順序です。逆に、最初から複数の開発環境やチームが同じmacOSツールを使うなら、MCP Serverと権限境界を先に設計した方が重複実装を避けられます。

macOS固有の処理を常駐MCP Serverとして運用する場合、手元の環境では端末の占有、権限のばらつき、再現性の不足が問題になりやすく、一般的なクラウド実行環境ではmacOS依存のツールをそのまま扱えません。必要な期間だけ分離されたMacを確保し、処理後に回収できる構成を検討するなら、リモートMac環境の構成やMac VPSの料金と運用条件を比較材料にできます。

共有macOSツールや常駐リモートMCP Serverが必要だと判断できた段階で、固定端末を買い増すより、用途ごとに隔離・回収できるMac環境を試す方が、検証期間と権限範囲を管理しやすい場合があります。ZilmacのMac環境を候補に入れる場合も、長期の安定した高負荷運用、物理インターフェースが必須の処理、常時占有が前提の業務では自社所有環境と比較し、短期検証やチーム共有のMCP実行基盤に向くかを条件付きで判断してください。