MCPはなぜ必要なのか：AIの知能ではなくソフトウェア接続の標準

1. 既にできていたことなのに、なぜわざわざプロトコルなのか？

CodexやCursorなどの最新AIコーディングツールを日常的に活用しているエンジニアにとって、「MCP（Model Context Protocol）」という言葉はかえって曖昧で掴みどころのない概念に思える。

私たちは既にAIに膨大な作業を委ねている。AIは手元のリポジトリのソースコードを読み込み、ターミナルでテストを実行し、Gitのコミット履歴を遡り、ブラウザで公式ドキュメントを検索する。既に手足が生えたかのように外界と連携できているのに、ある日AnthropicがMCPを発表し、これぞエージェント時代の革命的標準だと喧伝し始めた。

当然ながら素朴な疑問が湧き上がる。「そんなことは従来のAPIやFunction Callingでとっくにできていたはずだ。なぜわざわざ新しいプロトコルを立ち上げて騒ぎ立てるのか？ 単なるマーケティングの虚飾か、それとも不可欠な標準なのか？」

結論から言えば、ユーザーから見た「AIがツールを使う体験」自体は、これまでと何ら劇的に変わるものではない。MCPを導入したからといってLLMの推論能力が突然飛躍するわけでも、これまで原理的に不可能だった魔法のような能力が発現するわけでもない。

MCPの本質はAIの「知能」にあるのではなく、異なるAIツールと外部ソフトウェアを結びつける「相互運用性（Interoperability）の標準化」にある。

2. N × Mの悪夢：かつてエディタが辿った道をAIが辿る

ソフトウェアの歴史を紐解けば、全く新しい機能の発明ではなく「接続規約の標準化」だけでエコシステム全体の景色を一変させた決定的瞬間が存在する。その代表例がMicrosoftの主導したLSP（Language Server Protocol）である。

かつてはVS Code、IntelliJ、Sublime Text、VimといったN種類のエディタが存在し、Python、Rust、Go、TypeScriptといったM種類の言語が存在した。エディタごとに自動補完や定義ジャンプ、シンタックスエラー検出を提供するためには、エディタの開発元が各言語向けの専用プラグインを一つひとつ個別に開発・保守しなければならなかった。

その帰結はN × M個の断片化であった。5つのエディタが10の言語を完全にサポートするには、実に50個もの個別プラグインを作り続けねばならなかった。

LSPはこの悪夢を一撃で解消した。エディタと言語解析器の間に共通の対話プロトコル（LSP）を打ち立てたのだ。言語開発チームは単一のLSPサーバーを用意するだけでよく、エディタ側は単一のLSPクライアントを実装すれば済むようになった。50回もの個別開発が、（5 ＋ 10 ＝ 15）回へと激減したのである。

今日、AIエージェントの世界が直面している混迷は、まさに10年前のエディタ業界と全く同じ構図である。一方にはCodex、Claude Code、Cursor、Windsurf、ChatGPTといった無数のAIホストが存在する。他方にはGitHub、Sentry、Notion、PostgreSQL、Slackといった無数の外部サービスやデータベースが存在する。

MCPがなければ何が起きるか。GitHubの機能をCursorで使うために専用連携を書き、同じ機能をClaude Codeで使うために別の連携を書き、Codexのためにまた最初から実装し直さねばならない。100の外部サービスと10のAIツールがあれば、世界中のエンジニアが1,000通りもの接続コードを保守する徒労に追われることになる。

MCPとは、AIエコシステムにUSB-C端子を差し込むという宣言に他ならない。サービス事業者は自社のAPIをラップした単一のMCPサーバーを公開し、AIツール側はMCPクライアント規格をサポートする。双方が規約を守るだけで、ユーザーはどのAIツールを使っていようとも、ワンクリックで世界中の外部サービスを接続できるようになる。

확대

3. 3つの層を峻別する：API、Function Calling、そしてMCP

実務現場で最も頻繁に生じる混乱は、API、Function Calling、そしてMCPを同一線上の競合技術として混同することから生まれる。これら3つは競合するのではなく、完全に役割が分担された3つの階層である。

第1に、API（Application Programming Interface）はサービスが提供する固有の機能とデータの源泉である。GitHubのREST APIがなければ、GitHubからイシューを取得することは物理的に不可能である。APIは現実のビジネスロジックとデータベースの保管庫である。

第2に、Function Calling（ツール呼び出し）は、LLMが自然言語のプロンプトを読み解き、「いまはsearch_issuesという関数をこの引数で呼び出すべきだ」と判断して整然たるJSONを出力する、モデル自身の認知的選択機構である。モデルは道具を選ぶだけであり、コードを実際に実行するのはモデルの外側にいる実行ランタイムである。

第3に、MCP（Model Context Protocol）は、そのツールの定義や引数、そして実行結果のデータを、AIホストと外部サーバーの間でいかに標準化して授受するかを定めた通信規約である。

生のFunction Callingでは、開発者がプロンプト内に利用可能な関数のJSONスキーマを直接ハードコードして埋め込まねばならなかった。これに対しMCP環境では、AIホストがMCPサーバーに対してtools/listという標準メッセージを送り、提供可能なツール一覧とスキーマを動的に取得する。モデルがツール選択を行った後は、tools/callメッセージによって外部サーバーへ安全に実行が委任される。

要するに、APIは現実に製品を作る工場であり、Function Callingは作戦を命じる司令官の判断であり、MCPはその指令を迅速かつ規格通りに輸送するコンテナ網である。

4. MCPアーキテクチャの3大基柱：Tools、Resources、Prompts

MCPの公式仕様（Specification）を紐解くと、サーバーがクライアントに対して公開しうる原初的な構成要素は大きく3つに分類されている。

1. Tools（ツール）：モデルが直接呼び出すことのできる実行可能な関数である。create_issueやexecute_sql_queryのように、モデルの自律的判断によって起動され、外界に具体的な副作用（Side-effect）を及ぼす。

2. Resources（リソース）：ファイル内容やデータベーススキーマ、システムログのように、モデルへ事実的文脈（Context）として読み込ませるべき静的データである。URI（file:///, postgres://）で一意に識別され、ホストアプリケーションが必要に応じてフェッチしコンテキストに注入する。

3. Prompts（プロンプト）：障害分析やコードレビューといった定型ワークフローのために、サーバー側が事前定義した再利用可能なテンプレートである。ユーザーがスラッシュコマンドなどを通じて意図的に呼び出す。

flowchart TD
  User["ユーザーの自然言語要求"] --> Host["AI Hostアプリケーション: Codex / Cursor / Claude Code"]

  subgraph MCP_Boundary["MCPプロトコル通信境界"]
    Host <-->|tools/list: ツール一覧の動的発見| MCPServer["外部サービス専用MCP Server"]
    Host <-->|resources/read: 背景文脈の注入| MCPServer
  end

  Host -->|ツール定義 + 文脈注入| LLM{"大規模言語モデル: 推論エンジン"}
  LLM -->|Function Calling判断: ツールと引数の選択| Host

  Host -->|tools/call: 実行の標準委任| MCPServer
  MCPServer -->|認証済みAPIリクエスト| ExternalAPI["外部サービスとDB: GitHub / DB / Sentry"]
  ExternalAPI -->|実行結果の返却| MCPServer
  MCPServer -->|標準JSON結果| Host
  Host --> LLM
  LLM --> FinalAnswer["最終的な回答の出力"]

5. 光の裏に潜む影：コンテキスト肥大化とセキュリティの防壁

標準化がもたらす優雅な設計の一方で、実務的な観点から見ればMCPは決して無謬の銀の弾丸ではない。無批判な導入は深刻なボトルネックと脆弱性を引き起こす。

第1の問題はコンテキスト窓の浪費とプロンプト汚染（Context Bloat）である。5つや6つのMCPサーバーを安易に接続するだけで、各サーバーが公開する無数のツール説明文とJSONスキーマがシステムプロンプトを一瞬で埋め尽くす。ツール定義だけで数千から数万トークンを浪費し、推論コストと応答遅延を悪化させる。さらに深刻なのは推論精度の低下である。過剰なツールが目の前に散らばっていると、単純なコード修正の局面でもモデルが誤ったツールを呼び出そうとしたり、判断を誤るリスクが跳ね上がる。

第2の、そしてより致命的な懸念は攻撃対象領域（Attack Surface）の拡大である。ローカル環境で動くMCPサーバーは、往々にしてnpxやネイティブバイナリを通じて開発者自身のターミナル権限をそのまま引き継いで実行される。出所不明のサードパーティ製MCPサーバーを不用意にインストールすることは、検証されていない外部プログラムをローカルマシンで直に走らせることに等しい。

さらに、外部から取得したイシューの本文やWebドキュメントに悪意ある指示が潜んでいる場合（間接的プロンプトインジェクション）、モデルがそれを正当な指示と誤認し、接続されたMCPサーバーを介して機密の環境変数やローカルファイルを外部へ不正送信してしまう危険がある。成熟した開発環境においては、読み取り専用（Read-only）のサンドボックス化、実行前の人間承認（Human-in-the-loop）、そして最小権限の原則が厳格に課されねばならない。

확대

6. なぜこれまで知らなくても何一つ困らなかったのか？

冒頭の率直な疑問に立ち返ろう。「私はこれまでMCPの存在など一切意識せずとも、AIを使いこなして優れた成果を出してきた。なぜ知らなくても問題なかったのか？」

その答えは、真に優れたインフラストラクチャほど、普段はユーザーの意識から透明に隠れるように設計されているからである。

私たちがWebサイトを閲覧するとき、TCPの3ウェイハンドシェイクやTLS暗号化証明書の交換手順を意識せずとも通信が成立するのと同じだ。CodexやCursorなどの洗練されたエディタは、手元のファイルを読み書きするための独自の内部機構をあらかじめ組み込んでいる。単一のリポジトリの中で完結するローカル作業であれば、外部のMCPサーバーを介在させる必要性自体が存在しない。

しかし組織が拡大し、Sentryのエラーログ、GitHubのイシュー、社内データベースのスキーマを単一のAI作業空間にシームレスに束ねる必要が生じたとき、そしてその接続資産を特定のエディタに囲い込まず社内の多様な開発環境で再利用可能にしたいと願ったとき、MCPは代替不可能な真価を発揮する。

MCPはAIの思考様式を根本から塗り替える知能の革命ではない。AIが既に備えていた判断力を、私たちが過去数十年にわたって築き上げてきた堅固なソフトウェア資産へと最も摩擦なく接続する、極めて実直で静かなる「配管（Plumbing）」の標準化なのである。