MCPとFunction Callingの違い——ツール呼び出しアーキテクチャを整理する

AIエージェントが外部のツールやサービスと連携するとき、その橋渡しをする技術として「Function Calling」と「MCP（Model Context Protocol）」が広く使われている。どちらも「LLMにツールを呼び出させる」という目的のためにあるが、設計思想と適用場面が異なる。

Function Callingの仕組み

Function Calling（OpenAIではToolsとも呼ばれる）は、特定のLLMプロバイダーが提供するAPIの機能として実装されたツール呼び出しの仕組みだ。

基本的な動作は以下の通りだ。開発者はツールをJSON Schema形式で定義し、APIリクエストに含める。LLMはユーザーの要求を分析し、ツールを呼び出すべきと判断した場合、ツール名と引数を構造化されたJSON形式で返す。アプリケーション側でそのJSONを解析し、実際の関数を呼び出す。実行結果をLLMにフィードバックし、最終回答を生成させる。

// ツール定義の例
{
  "type": "function",
  "function": {
    "name": "get_weather",
    "description": "指定した都市の天気を取得する",
    "parameters": {
      "type": "object",
      "properties": {
        "city": {
          "type": "string",
          "description": "都市名"
        }
      },
      "required": ["city"]
    }
  }
}

Function Callingの特徴は、アプリケーション固有のツールを柔軟に定義できることだ。開発者が必要なツールをその都度設計・実装する。特定のデータベース操作、社内システムとの連携、ビジネスロジックの実行など、完全にカスタマイズされたツール群を持てる。

MCPの設計思想

MCP（Model Context Protocol）はAnthropicが策定したオープン標準プロトコルで、LLMとツール・データソースを接続するための汎用インタフェースだ。

Function Callingが「アプリケーション内でツールを定義・実装する」のに対して、MCPは「ツールをサーバーとして独立させ、標準プロトコルでLLMと通信する」アーキテクチャを採用している。

MCPの構成は3要素だ。MCPクライアント（LLMアプリケーション）、MCPサーバー（ツールを提供するサービス）、MCPプロトコル（両者の通信規格）。

MCPサーバーはツールの定義と実装を持ち、MCPクライアントからの要求に応じてツールを実行する。重要なのは、一度MCPサーバーを実装すれば、MCPに対応するすべてのクライアント（LLMアプリケーション）から利用できる点だ。

MCPクライアント(Claude等)
    ↕ MCPプロトコル
MCPサーバー(ファイルシステム)
MCPサーバー(データベース)
MCPサーバー(GitHub)

設計思想の違い

Function CallingとMCPの根本的な違いは「誰が何を管理するか」という設計思想にある。

Function Callingは「アプリケーション中心」の設計だ。アプリケーション（LLMクライアント）がツールを所有し管理する。ツールはアプリケーションのコードの一部として実装される。アプリケーションが変われば、ツールの実装も再度行う必要がある。

MCPは「ツール中心」の設計だ。ツールが独立したサーバーとして存在し、複数のアプリケーションから再利用できる。たとえばGitHubのMCPサーバーを一度実装すれば、Claude、その他のMCP対応LLMのすべてから同じサーバーを使えるインフラになる。

もう一つの違いは「リアルタイム性」だ。MCPはサーバーとのステートフルなセッションを維持でき、ツールが長時間実行するタスクや、非同期の更新通知（サーバーからクライアントへのプッシュ）をサポートする設計だ。Function Callingは基本的にステートレスなリクエスト・レスポンス型だ。

適用場面の違い

両者の使い分けは、ユースケースによって明確になる。

Function Callingが適している場面：特定のアプリケーションのロジックに密結合したツール（ビジネスルールの実行、専用データベースへのアクセス等）、迅速なプロトタイピング、シンプルなツール連携、特定のLLMプロバイダーのエコシステム内での開発。

MCPが適している場面：複数のLLMアプリケーション・エージェントから共通して使いたいツール（ファイルシステム・バージョン管理ツール・コミュニケーションツールのアクセス等）、ツールのエコシステムを構築したい場合（誰でも接続できるMCPサーバーとして公開したい）、ステートフルなセッションや非同期通知が必要な場合。

共存と補完の関係

Function CallingとMCPは競合関係ではなく、補完的な技術だ。

実際のシステムでは、MCPクライアントがFunction Callingをツール呼び出しの内部実装として使うことがある。あるいは、MCP対応LLMがFunction Callingも別途サポートすることもある。

MCPが目指す「ツールの標準プロトコル化」は、AIエージェントのエコシステムを拡張する可能性を持つ。異なる会社が作ったLLMと異なる会社が作ったツールサーバーが、標準プロトコルで接続できれば、組み合わせの爆発的な拡張が可能になる。

まとめ

Function Callingは「アプリケーションがツールを所有する」設計であり、特定のアプリケーションに密結合したツール連携に適している。

MCPは「ツールが独立したサーバーとして存在する」設計であり、複数のLLMアプリケーション間でのツール再利用と標準化を目指したプロトコルだ。

どちらを使うかは「ツールを誰が管理し、誰が再利用するか」という設計上の決定による。局所的なツール連携にはFunction Calling、エコシステムとしてのツール共有にはMCPが適している。