MCPサーバー vs Function Calling：どちらを選ぶ？

魅力的だ。本当にそう思う。

今やすべてのLLMプロバイダーがfunction callingを持っている。OpenAIも。Anthropicも。Googleも。お気に入りを選んで、20分ドキュメントを読んで、JSONスキーマで関数を定義して、リリースする。動く。デモは見栄えがいい。投資家も感心する。

問題は、「動く」と「複数ベンダーで大規模に動く」がまったく別の話だということだ。前者は火曜の午後で済む。後者はフルタイムの仕事になる。

function callingを一つのプロバイダーに直結させたとき、ベンダーを選んでいるだけではない。そのスキーマ形式、パラメータの慣例、エラーハンドリングの意味論、リリーススケジュールを丸ごと選んでいるのだ。定義上ポータブルではないグルーコードを書いている。しかもそれをポータビリティが最も重要な層で — アプリケーションと、それが依存するインテリジェンスの境界でやっている。

ほとんどの人が気づくのは、2つ目のLLMをサポートする必要が出てきたときだ。そのときにはグルーコードはすでに転移している。

こんな実験をしてみてほしい。コードベースに行って、内部のツール定義と特定のLLMプロバイダーのfunction calling形式を変換するためだけに存在する行数を数えてみてくれ。

1つの統合？100行くらいか。管理できる。2つの統合？OpenAIとAnthropicがオプショナルパラメータの表現方法について微妙に違う意見を持っていることに気づき始める。3つ？互換性マトリックスを保守している。5つ？うっかりフレームワークを作ってしまっている。

フレームワークは成長を止めない。各ベンダーは四半期ごとにAPIの形を変える。機能を追加することもある。非推奨にすることもある。土曜の午前2時に本番環境の既存定義を壊すような方法でスキーマ形式を「改善」することもある。

マルチベンダーのfunction callingにかかるメンテナンス税は線形ではない。組み合わせ的だ。新しいベンダーが増えるたびに表面積が倍増する。APIの変更がすべての統合に波及する。「シンプル」だったfunction calling層がスタックの最も脆い部分になる — 誰もが触るのを恐れるあのファイルに。

誰もこのコストをアーキテクチャドキュメントに書かない。スプリント計画で見積もらない。ただ静かに蓄積していき、ある日、エンジニアリング時間の半分が機能を作ることではなく統合を生かし続けることに使われていると気づく。

MCPはプロダクトではない。スタートアップのAPIでもない。プロトコルだ。この区別は人々が思う以上に重要だ。

MCPサーバーを書くとき、ツールを一度だけ記述する。一つのスキーマ。一つの説明セット。一つのエラー形式。以上。MCPを話すすべてのLLMが、ベンダー固有のコードを一行も書かずにツールを発見し使える。

アダプターなし。バージョンマトリックスなし。「if openai then フォーマットA, elif anthropic then フォーマットB」の分岐なし。プロトコルが契約であり、プロトコルを実装するすべてのクライアントがツールを無料で手に入れる。

これはHTTPを成功させたのと同じパターンだ。Chrome、Firefox、Safariで別々のAPIを書く人はいない。プロトコルを実装すれば、準拠するすべてのクライアントが動く。MCPはAIツール統合に対して、HTTPがWebコンテンツ配信に対してやったことと同じことをする — トランスポート層を退屈なものにして、アプリケーション層に集中できるようにする。

実用的な結果として、ツール定義は負債ではなく資産になる。一度書いて、一度テストして、一度ドキュメント化する。新しいLLMプロバイダーが現れても、何も書き直さない。MCPサーバーに向けるだけで動く。

これを認めないのは不誠実だろう：function callingが正しい選択である場合もある。

一つのLLMだけを使うアプリケーションを作っていて、どのLLMかわかっていて、それについて自分を騙していないなら — 直接的なfunction callingの方がシンプルだ。抽象化が少ない。動く部品が少ない。ポータビリティと引き換えに直接性を得る。そのトレードが価値あるときもある。

MCPにまだ対応するものがないベンダー固有の機能が必要なら — 構造化出力モード、コンピューターユースAPI、プロバイダー固有のストリーミング動作など — 直接統合は理にかなう。プロトコルが公開していないものにはアクセスできない。

そしてプロトタイプ中なら、「とにかく動かす」フェーズにいるなら、function callingの方が速くたどり着ける。MCPにはセットアップのオーバーヘッドがある。週末のハッカソンでは、そのオーバーヘッドは無視できない。

だが正直に答えなければならない問いがある：「一つのベンダーを永遠に」は、本当にあなたの未来を表しているか？ 私の経験では、「OpenAIしか使わない」と言う企業は、6ヶ月後にユーザーが求め始めてClaude対応を慌てて追加する企業と同じだ。「プロトタイプだけ」と言う企業は、2年後もそのプロトタイプを本番で動かしている企業と同じだ。

function callingからMCPへの移行コストは、待つ日ごとに上がる。MCPから始めるコストは、ほぼ一定のままだ。

ほとんどの人が見落としていると思うこと：MCPとfunction callingは敵ではない。同じスタックの異なるレイヤーだ。

MCPツールは、function callingをサポートするあらゆるLLMに関数として公開できる。プロトコルが真実の源 — ツールが何をし、何を受け取り、何を返すかの正規の記述だ。function callingアダプターは手書きではなく生成される。MCPサーバーが唯一のソースであり、ベンダー固有のフォーマットは投影にすぎない。

つまり、選ぶ必要はない。MCPをツール定義層として持ちながら、各LLMへの配信メカニズムとしてfunction callingを使い続けられる。違いは、MCPを使えば関数定義がベンダーごとに独立して保守されるのではなく、単一のソースから導出されることだ。

業界がそれを自覚しているかどうかに関わらず、これが向かう先だ。「一つの正規記述、多くの派生フォーマット」というパターンは他のあらゆるドメインで勝利してきた — データベーススキーマ、API仕様、型システム。AIツール統合も同じパターンに収束する。代替案は、どのエンジニアリングチームよりも速く成長するメンテナンス負荷だからだ。

今これを理解する企業は、より良いツールを作ることに時間を使う。後で理解する企業は、グルーコードを書き直すことに時間を使う。どちらのグループも同じ場所にたどり着く。唯一の問いは、そこに着くまでにどれだけの時間を無駄にするかだ。