Microsoft Copilot Studio でカスタムのエージェントを最近作り始めた方は、システムとの連携にMCPを利用したり、APIも利用することもあると思います。ありがちな勘違いが、APIをそのままMCPにすればいいじゃないか？という考えを持つこともありますが、MCPの本質を理解し、何が違うのかを理解することで、より良いエージェントを作れるようになります。そこで今回はMCPとAPIの違いについて、触れたいと思います。

MCP ってそもそも何？

MCP（Model Context Protocol）は、Anthropic が 2024 年末に公開したオープンプロトコルです。狙いは、大規模言語モデル（LLM）が外部サービスをもっと自然に扱えるようにすることです。

基本的には 3 つの要素があります。

  1. ツール― LLM が実行できる“アクション”。
  2. リソース― ツールが扱う対象物や ID。
  3. プロンプト― モデルに渡す追加指示。

実質的にこの中でも主役なのはツールであり、LLM が「目的を達成するための一手」を選びやすい設計にすることが MCP サーバーの骨格になります。

Claude をはじめとする各種 LLM クライアントが続々と対応を表明し、OpenAI、Windows Copilot、Google Gemini も実装を進めています。従来の REST や GraphQL API が「リソース操作」を前提にしているのに対し、MCP サーバーは LLM が使いやすい「ツール」を提供する存在だという点が最大の違いです。

「APIの変換結果をそのまま公開 ≠ MCP サーバー」なワケ

OpenAPI スキーマを自動変換して「とりあえず MCP にしました」では、ほぼ確実に失敗します。その理由は大きく四つあります。

ツールが多いのが苦手

まず、API 由来のエンドポイントは数が多過ぎるため、LLM は最適ツールを選び切れずに迷走しがちです。 LLM は「大量の選択肢」から最適ツールを選ぶのが苦手。OpenAPI を丸ごと MCP にするとツールが 100 個単位で増え、迷走するのです。マルチエージェントという概念が出てきたのも、より小分けに利用できるツールの範囲を狭めることで、迷わないようにさせることが背景にあります。

APIの説明は人が使う前提でLLＭに向いていない

次に、既存 API のエンドポイント説明は人間が利用することを前提に書かれているため、曖昧さや前提知識を含み、モデルが誤解釈しやすいという問題があります。人間が「いい感じに」解釈できるものでも、モデルはそういうわけにはいきません。OpenAI Evalsでも「ツール説明の質が呼び出し精度を大きく左右する」と指摘されています。

抽象レベルが違う

三つ目のポイントは粒度の相違です。典型的な API はリソースの CRUD 操作を列挙しますが、LLM が求めるのは「タスクを完了するための高レベルなアクション」であり、レイヤーがかみ合いません。例えば、REST はリソース操作（POST /users など）が主眼ですが、LLM は「請求書を送りたい」「シナリオを生成したい」といったタスク完遂を望むため、抽象レベルが食い違います。

LLM特有のニーズに対応していない

そして最後に、API を機械的にコピーしただけでは「複数呼び出しをまとめたワークフロー」や「安全確認フロー」といった、LLM 特有のニーズを満たす拡張を設計する発想に至りにくいという点が挙げられます。

自動生成ツールだけでは足りない

最近は OpenAPI から MCP をワンクリックで生成できる SaaS が登場していますが、ハイブリッドな形で作り上げるのが、実際にMCPを利用するにあたって必要になると思います。まず自動生成で叩き台を作り、そこから LLM に不要なツールを大胆に削除 します。そして残したツール一つひとつに対して LLM 目線で説明を全面的に書き直し、具体的な入力例や失敗例も添えます。

その後、自動評価（Evals）を組み、モデルが誤ったツールを選ばないか数千回規模でテストします。Microsoft Copilot Studio の場合は、私の姉妹チームが作った Copilot Studio Kitに含まれるテスト機能を用いるのが良いと思います。

そしてモデルが苦手な手順を補完する LLM 専用ツール を新規実装して完成です。こうして「数は少ないが質の高い」ツールセットに絞り込むことで、モデルの性能を最大限に引き出せるのです。

まとめ

LLM 時代におけるインターフェースは、従来の API だけでは十分と言えません。MCP が提示するのは、モデルが本当に扱いやすい操作体系であり、それを生かすには自動生成に頼り切らず、人間が「どんなツールがあればモデルは迷わずゴールにたどり着けるか」を考え抜く必要があります。

API を MCP に単に「変換」するのではなく、API と MCP を別レイヤーとして設計し直すことが重要だと思います。もし皆さんが作ったサービスを展開させるのであれば、LLM エコシステムへ最適化するためにも、MCP サーバーをゼロから「作り込む」価値は大きいと言えると思います。