MCPとFunction Callingの違い|OpenAI APIでの使い分け

MCPとFunction Callingの違い・選び方・安全設計 LLM

OpenAI APIで外部ツールを使う方法として、よく比較されるのが「Function Calling」と「MCP」です。

どちらもモデルに外部データや操作手段を与える仕組みですが、役割は同じではありません。

  • Function Calling:自分のアプリ内にある関数を、モデルから呼び出すための仕組み
  • MCP:外部サービスやツール群を、共通プロトコルでAIへ接続する仕組み

結論から言うと、アプリ固有の処理にはFunction Calling、複数のAIクライアントから再利用したい外部連携にはMCPが向いています。両者を組み合わせる設計も可能です。

この記事では、Responses APIを前提に、違い・選び方・安全設計を整理します。

MCPとFunction Callingの構成と責任範囲の違い

スポンサーリンク

MCPとFunction Callingの違いを比較

最初に、実装時に迷いやすいポイントを一覧で比較します。

比較項目 Function Calling MCP
主な役割 アプリ内の関数をモデルへ公開する 外部ツール群を共通形式で接続する
ツール定義 リクエスト内でJSON Schemaを定義 MCPサーバーがツール一覧とスキーマを公開
実処理の場所 自分のPythonやバックエンド 接続先のMCPサーバー
再利用範囲 基本的にそのアプリ内 対応する複数のAIクライアントで再利用可能
認証 アプリ側でAPIキーなどを管理 MCP接続用のOAuthや認証情報を管理
承認フロー アプリ側で実装する require_approvalで制御できる
向いている例 DB照会、社内ロジック、料金計算 Google Workspace、Dropbox、共通開発ツール

「どちらが新しいか」ではなく、「どこにツールを置き、誰が管理するか」で選ぶのがポイントです。

スポンサーリンク

Function Callingとは

Function Callingは、モデルへ関数名・説明・引数のJSON Schemaを渡し、必要なときにfunction_callを返してもらう仕組みです。

モデルがPython関数を直接実行するわけではありません。アプリ側が次の処理を担当します。

  1. モデルが返した関数名と引数を確認する
  2. 許可した関数だけを実行する
  3. 実行結果を同じcall_idfunction_call_outputとして返す
  4. モデルから最終回答を受け取る

最小のツール定義は次のようになります。

TOOLS = [
    {
        "type": "function",
        "name": "get_order_status",
        "description": "注文IDから現在の配送状況を取得する。",
        "parameters": {
            "type": "object",
            "properties": {
                "order_id": {"type": "string"},
            },
            "required": ["order_id"],
            "additionalProperties": False,
        },
        "strict": True,
    }
]

Function Callingの実装全体は「Function Calling入門|Pythonで複数ツールを呼ぶ」で詳しく解説しています。

Function Callingが向いているケース

  • 自社DBの検索や在庫確認
  • アプリ固有の料金・スコア計算
  • 既存バックエンドの関数をAIから呼びたい
  • 入出力やエラー処理を細かく管理したい
  • ツール数が少なく、1つのアプリで完結する

MCPとは

MCPはModel Context Protocolの略で、AIアプリと外部ツールやデータソースをつなぐ共通プロトコルです。

OpenAIのResponses APIでは、リモートMCPサーバーやコネクタをtype: "mcp"の組み込みツールとして指定できます。

from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-5.6",
    tools=[
        {
            "type": "mcp",
            "server_label": "knowledge_base",
            "server_description": "社内ナレッジを検索するMCPサーバー",
            "server_url": "https://your-mcp.example.com/mcp",
            "allowed_tools": ["search_documents", "read_document"],
            "require_approval": "always",
        }
    ],
    input="返品手続きの社内ルールを調べてください。",
)

print(response.output_text)

実際には、接続するMCPサーバーの仕様に合わせてserver_urlや認証情報を設定します。OpenAIが管理するコネクタを使う場合は、connector_idとOAuthアクセストークンを指定します。

MCPが向いているケース

  • すでに利用したいMCPサーバーがある
  • Google Workspaceなどの外部サービスへ接続したい
  • 同じツール群を複数のAIアプリから再利用したい
  • ツールの追加・更新をクライアントから分離したい
  • 標準化された接続方式を採用したい

迷ったときの選び方

MCPとFunction Callingを選ぶ判断フロー

次の順番で判断すると整理しやすくなります。

1. アプリ内部の処理か

自社DBの検索、計算、既存Python関数など、アプリ内部で完結する処理ならFunction Callingが第一候補です。

MCPサーバーを新設することもできますが、1つのアプリでしか使わない小さな関数なら、接続層を増やすメリットが小さい場合があります。

2. 複数のAIから再利用するか

同じツールを複数のAIクライアントやプロジェクトから使うなら、MCPにまとめる価値があります。

ツール定義や認証処理をサーバー側へ集約でき、クライアントごとの重複実装を減らせます。

3. 外部サービスへの接続が中心か

ファイルストレージ、カレンダー、開発ツールなど、外部サービスとの接続が中心ならMCPやコネクタが向いています。

一方、外部APIを1本だけ呼ぶ小規模な機能なら、Function Callingから既存APIクライアントを呼ぶ方が単純です。

4. セキュリティ境界をどこへ置くか

Function Callingでは、関数の許可リスト、引数検証、承認画面をアプリ側で設計します。

MCPでは、接続先サーバーの信頼性に加えて、allowed_toolsrequire_approvalを設定します。どちらを使う場合も、モデルの判断だけで購入・削除・公開などを実行させないことが重要です。

MCPとFunction Callingは併用できる

MCPとFunction Callingは二者択一ではありません。

例えば、次のように役割を分けられます。

  • Function Calling:社内の商品価格や在庫を取得する
  • MCP:Google Driveから提案書テンプレートを取得する
  • アプリ側:両方の結果を検証し、ユーザー承認後に文書を保存する

アプリ固有の業務ロジックはFunction Calling、汎用的な外部連携はMCPへ分けると、責任範囲が明確になります。

Responses APIの基本から確認したい場合は「OpenAI Responses API入門|Pythonで使い方を解説」も参考にしてください。

セキュリティで注意すること

MCPは便利ですが、外部サーバーへモデルの文脈やデータを送る可能性があります。信頼できないMCPサーバーへ機密情報を渡してはいけません。

MCPで確認する項目

  • 運営者とサーバーURLを確認する
  • 必要なツールだけをallowed_toolsで許可する
  • 読み取りと更新・削除を分離する
  • 機密操作ではrequire_approvalを有効にする
  • 外部へ共有される引数をログで確認できるようにする
  • OAuthトークンをコードやログへ出さない
  • ユーザー入力によるプロンプトインジェクションを想定する

Function Callingで確認する項目

  • 関数名を許可リストで照合する
  • strict: trueとJSON Schemaを使う
  • Python側でも引数の値を検証する
  • ツール結果から機密情報を除く
  • 購入・削除・公開の前に人間の承認を入れる
  • 最大ターン数と再試行回数を設定する

出力形式を固定したいだけなら、ツール連携ではなくStructured Outputsが適しています。「Structured OutputsとFunction Callingの違い」で使い分けを整理しています。

よくある質問

MCPはFunction Callingの代わりになりますか

すべてを置き換えるものではありません。MCPはツールやデータソースを共通方式で接続する仕組みで、Function Callingはアプリが用意した関数をモデルと受け渡す仕組みです。用途によって使い分けます。

小規模なアプリでもMCPを使うべきですか

利用したいMCPサーバーがすでにあるなら有力です。アプリ固有の関数が数個だけなら、Function Callingの方が構成を小さく保てます。

MCPなら承認処理は不要ですか

不要にはなりません。特に外部送信、更新、削除、購入などは承認対象にします。Responses APIではMCPツールにrequire_approvalを設定できます。

ツールが多いほど便利ですか

必ずしもそうではありません。MCPサーバーのツールが多いと、選択に使うトークンや待ち時間が増える可能性があります。必要なツールだけをallowed_toolsで絞ります。

まとめ

MCPとFunction Callingの違いは、ツールの置き場所と再利用範囲にあります。

選択 判断の目安
Function Calling アプリ固有の関数や業務ロジックを細かく管理したい
MCP 外部サービスや共通ツールを複数のAIから再利用したい
併用 内部ロジックと外部連携を明確に分離したい

最初は必要最小限のツールだけを接続し、読み取り処理から始めます。更新や削除を追加するときは、権限・承認・監査ログを一緒に設計してください。

参考資料

コメント

タイトルとURLをコピーしました