3つの用語は層が違う

Function Calling、MCP、プラグインは、どれも「LLMに外部の機能を使わせる仕組み」として語られます。ただし、同じ層で並ぶ選択肢ではありません。Function Callingは、モデルのAPIとアプリの間の約束事です。MCPは、ツールを提供するプログラムとAIアプリの間の通信規格です。プラグインは、特定の製品に機能を足すための配布と導入の単位です。この区別がないと、「MCPとFunction Callingのどちらを使うべきか」という、そもそも比べられない問いに時間を使ってしまいます。

Function Calling(Tool Use):モデルAPIが持つ機能

Function Callingでは、LLMのAPIに使える関数の名前、説明、引数の形式を渡します。するとモデルは必要なときに「この関数をこの引数で呼んでほしい」という構造化データを返します。OpenAIとGoogle Geminiはこれを「Function Calling」、Anthropicは「Tool Use」と呼びますが、考え方は同じです。引数の形式は、JSONデータの構造を記述する規格であるJSON Schemaで書くのが一般的です。

仕様を決めるのは各モデルベンダーで、リクエストの書き方はベンダーごとに少しずつ違います。最も重要なのは、モデル自身は関数を実行しないという点です。モデルが返すのは呼び出しの依頼だけです。実際に関数を動かし、結果をモデルに返すのは、開発者が書いたアプリのコードです。

MCP:ツールとAIアプリをつなぐ共通規格

MCP(Model Context Protocol)は、2024年11月にAnthropicが公開したオープンな通信プロトコルです。その後、OpenAI、Google、Microsoftなどの製品も対応し、ベンダーをまたいで使える規格として広がっています。仕様は公式サイトで公開されています。

MCPには3つの役割があります。Claude DesktopやCursorのようなAIアプリ本体が「ホスト」です。ホストの中でサーバーと通信する部品が「クライアント」です。ツールやデータを提供するプログラムが「サーバー」です。サーバーの動かし方は2通りあります。1つはローカルの子プロセスとして起動して標準入出力(stdio)でやり取りする方法、もう1つはHTTPでネットワーク越しに接続する方法です。

MCPはFunction Callingを置き換えるものではありません。ホストは、MCPサーバーから受け取ったツール一覧を、使っているモデルのFunction Calling形式に変換して渡しています。MCPが標準化したのはアプリとツールの間の部分です。モデルとの間は、これまでどおりFunction Callingが担っています。

プラグイン/拡張機能:製品ごとの導入の仕組み

プラグインや拡張機能は、共通の技術規格の名前ではありません。各製品が「自社製品に機能を追加する方法」として個別に決めたものの総称です。2023年に登場したChatGPTプラグインは、Web APIの仕様を記述する形式であるOpenAPIでAPIを登録する方式でした。これはすでに提供を終え、GPTsのActionsに移行しています。Claude Codeのプラグインは、スラッシュコマンドやMCPサーバーなどをまとめて配布するための単位です。Claude DesktopのDesktop Extensionsは、MCPサーバーを簡単にインストールできるようにパッケージ化する形式です。

このように、中身がMCPサーバーであるプラグインも多くあります。プラグインは「何の技術で動くか」よりも「どう配布し、どう導入するか」を指す言葉だと考えると、混乱しにくくなります。

定義する主体動く場所他の製品への持ち運び
Function Calling各モデルベンダー開発者のアプリ(関数の実行)書式の差を吸収すれば可能
MCPオープンな仕様MCPサーバー(ローカルまたはリモート)対応ホストならそのまま使える
プラグイン各製品の提供元その製品の中基本的にできない

同じ「天気を調べる機能」を3つの方式で作る

Function Callingの場合

自分のアプリからモデルのAPIを呼ぶ構成です。ツール定義はリクエストに含めます。

{
  "name": "get_weather",
  "description": "指定した都市の天気予報を取得する",
  "input_schema": {
    "type": "object",
    "properties": {"city": {"type": "string"}},
    "required": ["city"]
  }
}

上の例はAnthropicの書式です。OpenAIでは引数の定義を parameters というキーで書くなど、細部が異なります。ユーザーが「明日の大阪の天気は?」と聞くと、モデルは get_weather を {"city": "大阪"} で呼ぶよう返します。次にアプリが天気APIを呼び、その結果を次のリクエストに付けてモデルへ送ります。モデルはその結果をもとに回答文を作ります。この往復を書くのは開発者の仕事です。

MCPの場合

まず、get_weather ツールを持つMCPサーバーを書きます。公式SDKはPythonやTypeScriptなどで提供されています。

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("weather")

@mcp.tool()
def get_weather(city: str) -> str:
    """指定した都市の天気予報を取得する"""
    return fetch_forecast(city)  # 天気APIを呼ぶ自作関数

mcp.run()

次に、ホストの設定ファイルにこのサーバーの起動方法を登録します。ホストは起動時にサーバーへ tools/list を送ってツール一覧を受け取り、モデルに渡します。モデルが呼び出しを返すと、ホストがサーバーへ tools/call を送り、その結果をモデルに返します。往復の処理はホストが受け持つため、サーバー側で書くのは関数の中身だけです。ツール定義は関数の型注釈とdocstringから自動で作られます。同じサーバーは、MCPに対応したどのホストでも再利用できます。

プラグイン/拡張機能の場合

利用者は、マーケットプレイスやファイルから天気プラグインを導入し、権限を許可するだけで使えます。作る側は、製品が決めた形式で機能をパッケージ化します。多くの場合、マニフェストファイル(名前や権限を記述する設定ファイル)を書き、MCPサーバーやAPI定義を同梱します。内部ではMCPか製品独自の方式でツールが公開され、最終的にはFunction Callingでモデルに渡ります。

自分の環境でどれを選ぶか

自社のWebサービスや社内botなど、自分のコードからLLMを呼んでいる場合の基本はFunction Callingです。ツールが数個で、そのアプリ専用なら、MCPのサーバーとクライアントを間に挟むのは手間が増えるだけです。

同じツールを複数のアプリで使いたい場合や、社内システムへの接続をチームのAIツールと共有したい場合は、MCPサーバーとして作る価値があります。一度作れば、自作アプリからもClaude CodeやCursorなどの既製ツールからも使えます。執筆時点では、AnthropicやOpenAIのAPIのように、リモートのMCPサーバーをリクエストで直接指定できるものもあります。対応状況は各社の公式ドキュメントで確認してください。

Claude CodeやCursorなどの既製ツールを自分で使うだけなら、コードを書く必要はほとんどありません。既存のMCPサーバーを登録するか、プラグインを導入すれば済みます。特定製品の利用者に機能を配りたい場合は、その製品のプラグイン形式に合わせます。中身をMCPサーバーにしておけば、他の製品へも移しやすくなります。

混同するとつまずく場所

モデルが関数を実行すると思い込む

Function Callingを初めて使うと、モデルがツール呼び出しを返した時点で処理が止まり、戸惑うことがよくあります。これは不具合ではなく仕様です。関数を実行して結果を返すループを書かない限り、天気は取得されません。

MCPサーバーを作れば自分のアプリで使えると考える

MCPサーバーを呼び出すのはホストです。自作アプリで使うには、アプリ側にMCPクライアントを実装するか、リモートMCPに対応したAPIの機能を使う必要があります。また、ホストによってローカルのサーバーだけに対応していたり、リモートのサーバーだけに対応していたりと、接続できる形が異なる点にも注意が必要です。

プラグインがどこでも動くと期待する

Claude Code用のプラグインはCursorでは動きません。プラグインは製品ごとの形式だからです。ただし、中に含まれるMCPサーバーは別のホストでも流用できることがあります。

権限の範囲を見落とす

ローカルで動くMCPサーバーやプラグインは、利用者と同じ権限で動くため、ファイルや認証情報にもアクセスできます。ツールの結果に紛れ込んだ悪意ある指示(プロンプトインジェクション)によって、モデルが意図しない操作をすることもあります。導入する前に、提供元とコードを確認してください。

判断は「誰のコードがLLMを呼ぶか」から始める

最初に確認するのは、LLMを呼んでいるのが自分のコードか、既製のAIアプリかです。自分のコードならFunction Calling、既製アプリならMCPかプラグインが出発点になります。次に、同じツールを他のアプリでも使うかを考えます。使う予定があるならMCPサーバーとして作ります。各方式の仕様は今も更新が続いているため、実装を始める前に、利用するモデルベンダーの公式ドキュメントとMCPの仕様で最新の書式を確認してください。