2026 MCP vs Function Calling：プロジェクトはどのツール層を選ぶべきか？

2026年7月28日、MCPの仕様リリースが公式に告知されています（公式リリースノート）。ただし、これはFunction Callingが不要になったという意味ではありません。2026 MCP vs Function Callingの結論は、Function Callingをモデルとアプリケーション間の呼び出し機構、MCPをクライアントがツール・リソース・プロンプトを発見して接続するプロトコル層として分け、通常は組み合わせることです。 単一アプリで少数の内部関数だけを扱うならFunction Callingから始め、複数のAgentクライアントが同じツール群を共有する段階でMCPを追加してください。

この判断は、数個の社内関数を持つ小規模プロジェクト、複数モデル対応を進めるプラットフォームチーム、既存の関数呼び出しコードを移行するアーキテクトを対象にしています。まだ実行器や権限管理が安定していない場合は、先に内部契約と監査ログを固める方が安全です。

最終更新：2026年8月18日。MCPの仕様変更は公式のTypeScript SDKドキュメント、モデル側の挙動はGeminiのFunction Calling公式資料、OpenAIのAPIリファレンス、ClaudeのTool Use公式資料を確認しています。

責務の境界

AIエージェントの処理を、モデル、アプリケーション、MCPクライアント、MCP Server、実行器、外部APIに分けると混同しにくくなります。モデルはツールを使うべきか判断し、アプリケーションはモデルの要求を受けて実行器を呼び出し、実行器が認証・入力検証・業務処理を担当します。

MCPは、クライアントがMCP Serverへ接続し、利用可能なツールやリソースの情報を取得する接続ルールです。一方、Function Callingはモデルが「この関数をこの引数で呼びたい」という構造化された要求をアプリケーションへ返す仕組みです。

典型的なデータの流れは、次のようになります。

ユーザー
  ↓
AIモデル ── Function Calling ── アプリケーション
                                  ↓
                         MCPクライアント ── MCP ── MCP Server
                                  ↓
                              実行器 ── 外部API・社内システム

この構成では、アプリケーションがツール実行と安全制御の主体です。MCPの説明文やツール一覧を信頼するだけでは、権限昇格、過剰な引数、危険な操作を防げません。MCPの認可に関する公式資料でも、接続時の認証・認可を別途設計する必要があります。

MCPとFunction Callingは同じものですか。
同じものではありません。Function Callingはモデルの出力形式とアプリケーションの呼び出し処理に近く、MCPはツールやリソースを接続・発見するための標準化層です。MCPを採用しても、モデルにツール実行を選ばせる部分ではFunction Calling、または各モデルのTool Calling機能を使う構成が一般的です。

接続方式の比較

最初に、どこへ複雑さを置くかを比較してください。Function Callingはアプリケーション内に処理を閉じ込めやすく、MCPは接続先を分離しやすい反面、プロトコル、セッション、認証、バージョン管理が増えます。

両者はJSON Schemaを使って引数を表現できますが、スキーマが同じ文字列のまま転送されるとは限りません。JSON Schemaの仕様解説が示すのはデータ構造の記述方法であり、Function CallingやMCPの通信形式、エラー表現、実行権限まで決めるものではありません。

MCPツール定義でJSON Schemaが必要なのはなぜですか。
モデルやクライアントが、引数の型、必須項目、列挙値、入れ子構造を機械的に理解するためです。しかし、スキーマを公開しただけで入力が安全になるわけではありません。実行器側でも同じ契約を検証し、業務上の上限、対象ユーザー、操作可能なリソースを再確認してください。

複雑さと再利用性の判定

少数のローカルツールなら、アプリケーションから実行器を直接呼ぶFunction Callingの方がコード経路を短くできます。MCPを先に導入すると、プロトコル処理、接続の再確立、Serverのライフサイクル、認証情報の保管、ログ相関IDの設計まで必要になり、将来の共有メリットが発生する前に運用負荷だけが増える可能性があります。

反対に、複数のAgentクライアント、複数のモデル、開発環境と本番環境などが同じツールを使うなら、MCPの標準化価値が上がります。各アプリに同じ関数定義や認証処理を複製するより、MCP Serverを境界として更新・監査する方が、変更箇所を管理しやすくなります。ただし、モデルがMCPを直接理解するとは限らないため、アプリケーション側にMCPクライアントとFunction Callingの橋渡しが必要です。

Tool Callingを使っているなら、MCPは必要ですか。
必要性は、モデルの数ではなくツールの共有範囲で決まります。単一アプリが一つのモデル群へツールを渡すだけなら、Tool Callingの実装を整理するだけで足ります。別々のクライアントが同じツール・リソース・プロンプトを発見し、同じ認証境界で利用するならMCPを追加する理由があります。

セキュリティと運用管理

MCPでは、公開するツール一覧そのものが情報になります。管理者向け操作、顧客データの検索、ファイル書き込みなどを同じServerから無差別に見せると、モデルの誤判断だけでなく、クライアント設定の誤りも攻撃面になります。環境別にServerやツールを分け、読み取り専用と変更操作を区別してください。

Function Callingでも安全性は自動的に確保されません。アプリケーションは、モデルが返した関数名と引数を許可リストに照合し、ユーザー権限、対象リソース、承認状態を検証してから実行します。高リスク操作には人間の承認を挟み、失敗時には再試行で二重実行されないよう冪等性キーを用意すると、決済・削除・デプロイ系の事故を抑えられます。

モデルごとの違いも確認が必要です。GeminiのFunction Calling資料、OpenAIのAPI仕様、ClaudeのTool Use資料を比較し、ツール定義の包装、並列呼び出し、拒否やエラーの返し方を検証してください。MCPを導入しても、これらのモデル固有差分が消えるわけではありません。

導入判断の分岐

次の条件分岐を、設計レビューでそのまま使えます。

• 単一アプリで、利用するツールが内部関数中心なら、Function Callingを選びます。MCPは導入せず、実行器、入力検証、監査ログを先に安定させます。
• 複数のモデルを使うが、ツールの利用範囲が一つのアプリ内に閉じるなら、内部ツール契約とモデル別アダプターを分けます。MCPを前提にした共有基盤はまだ作りません。
• 複数のAgentクライアントが同一のツール群を発見・利用するなら、MCP Serverを追加します。ただし、アプリケーションを実行と権限の主体として残します。
• リモートの外部APIや社内システムを複数チームへ公開するなら、MCPの接続境界、認証、監査方式を先に決めます。ツールの説明文だけでアクセス制御を済ませてはいけません。
• 既存のFunction Callingコードが不安定なら、MCPへの移行を止めます。まず関数名、JSON Schema、戻り値、エラー、タイムアウト、冪等性を内部契約として固定します。
• 共有クライアントが増えず、Serverの更新や認証運用を担当するチームも置けないなら、Function Callingへ戻します。標準化の利益が維持費を上回らないためです。

既存の関数呼び出しをMCPへ移行するには、何から始めればよいですか。
いきなり関数定義をMCP形式へ置き換えないでください。まず実行器をアプリケーションから分離し、ツールの入力・出力・失敗条件をテストで固定します。その後、既存のJSON Schemaを内部契約として保管し、MCPの入力定義へ変換するアダプターを作ります。最後に、認証、接続切断、再接続、監査ログ、高リスク操作の承認を検証し、旧経路と結果を比較してから切り替えます。

段階的な実装手順

• [ ] 使うツールを読み取り、書き込み、管理操作に分類し、各ツールの所有者と許可ユーザーを記録します。
• [ ] Function Callingでモデルの要求を受けるアプリケーションと、実際に外部APIを呼ぶ実行器を分離します。
• [ ] ツールごとにJSON Schema、戻り値、エラー、タイムアウト、再試行条件を定義し、プロトコルに依存しない契約として保存します。
• [ ] ツールの呼び出し元、引数、承認者、実行結果、失敗理由、相関IDをログへ記録します。
• [ ] 利用クライアントが単一か複数か、ツールを共有するモデルがあるかを確認し、共有要件がなければMCP導入を保留します。
• [ ] 共有要件が確定した場合だけMCP Serverを追加し、MCPクライアントからの発見結果を許可リストと照合します。
• [ ] 接続切断、認証期限切れ、スキーマ不一致、重複実行、権限拒否をテストし、失敗時にFunction Callingへ安全に戻せる経路を残します。
• [ ] 運用開始後は、利用されないツール、拒否された操作、スキーマ変更、Serverのバージョン差分を定期的に整理します。

MCPの公式Server開発資料も参照できますが、掲載されている構成をそのまま採用するのではなく、あなたのアプリケーションが実行・認可・監査を担う境界を先に図にしてください。設計資料を作る段階では、AIエージェント向けの実行環境も、接続方式だけでなくログ取得と権限管理まで確認できる環境として検討対象になります。

Function CallingとMCPの選択

この比較で避けたいのは、機能数や新しさだけで勝敗を決めることです。Function Callingは低い層の呼び出し機構、MCPは上位の接続・発見プロトコルとして分ければ、単一アプリでは軽量に始め、共有範囲が広がった時だけ標準化できます。

現在の開発環境をローカル端末や汎用クラウドへ寄せたまま運用すると、ツール実行用の環境差分、常時稼働の管理、接続先の権限設定が分散しやすく、再現性の確認にも手間がかかります。物理的なMac環境が必要なAgent検証やApple系の自動化では、環境を都度用意する負担も無視できません。

そのため、短期の検証、複数クライアントの接続試験、チームで共有するMac上の実行環境が必要なら、ZavCloudのMacレンタル環境を使って、まずツール契約と実行器の検証を分離する方法が現実的です。長期の固定負荷、専用の物理インターフェース、常時同一構成が必須なら自社保有のMacが向いていますが、試験環境や一時的な算力が目的なら、不要な機器管理を抱えずに済むレンタルの方が設計判断を進めやすいでしょう。