Model Context Protocol（MCP、通常はこの略称で呼ばれます）は、標準化されたインターフェースを通じて、AIアプリケーションを外部ツール、データソース、ワークフローに接続するためのオープンプロトコルです。Anthropicは2024年11月に、仕様、SDK、オープンなサーバーリポジトリを伴うオープン標準として、MCPを公開しました。それ以来、この話は特定のベンダーの発表をはるかに超えて広がっています。OpenAIは現在、APIプラットフォームにおけるリモートMCPサーバー対応をドキュメント化しており、GitHubはCopilotにおけるMCP対応をドキュメント化し、公式のGitHub MCPサーバーも維持しています。さらにMicrosoftは、エージェントやWindowsの各種サーフェスにまたがるMCP対応をドキュメント化しています。ここで重要なのは、MCPの実際の価値が単一のプロダクト機能ではないことです。価値は、AIシステムのための共有された統合レイヤーが出現することにあります。
多くのチームは、場当たり的な統合の限界をすでに学んでいます。最初のAIプロトタイプは、たいてい見通しが立つように思えます。いくつかの関数を定義し、社内APIをラップし、モデルに呼び出させるのです。これはシステムが成長するまで機能します。サポートのコパイロットにはCRMアクセスが必要です。IDEアシスタントにはリポジトリのコンテキストや課題（イシュー）追跡が必要です。プロダクトアシスタントには読み取り専用のコンテキストと、ガードされた書き込みアクションが必要です。すると、アプリケーションには、個別対応のラッパーの山、承認ロジック、認証ルール、壊れやすいツール説明が、あっという間に積み上がっていきます。
MCPが役に立つのは、そうした統合に共有された契約（コントラクト）を与えるからです。ホストはサーバーに接続できます。サーバーはツール、リソース、プロンプトを公開できます。チームは、モデルに向けたアプリケーションと、実際に業務データや運用能力を保持しているシステムを分離できます。
この記事は実務者向けの深掘りであり、煽りのまとめ記事ではありません。Model Context ProtocolがAIスタックのどこに位置づくのか、主要な概念が平易な言葉で何を意味するのか、MCPを導入する価値があるのはどんなときか、そしてそれでもなお実際のエンジニアリング作業がどこに残るのかを見ていきます。
AIスタックにおけるMCPの位置づけ
MCPを理解するいちばん簡単な方法は、モデルの機能として考えるのをやめて、モデルを有用にする外部システムとAIホストの間のインターフェースレイヤーとして考えることです。
大まかに言うと、スタックは次のようになります:
Model: 推論、計画、応答の生成を行うLLM。
Host: IDE、チャットプロダクト、デスクトップアプリ、あるいはエージェント実行環境など、ユーザーがやり取りするAIアプリケーション。
MCP client: そのホスト内にあり、特定のMCPサーバーへの接続を維持するコンポーネント。
MCP server: モデルから利用可能な機能を公開するプログラム。
External system: そのサーバーの背後にあるデータベース、SaaSアプリケーション、リポジトリ、キュー、API、または社内サービス。
平易な言葉で言えば、流れはこうです:
ユーザーがAIホストに何かを実行するよう依頼する。
ホストは会話とコンテキストをモデルに送る。
モデル、またはオーケストレーション層が、追加のコンテキストや外部アクションが必要だと判断する。
ホストは1つ以上のMCPサーバーと通信するために、MCP clientを使う。
それらのサーバーは、実際のシステムに裏付けられたリソース、プロンプト、またはツールを公開する。
結果がホストに返り、作業用コンテキストの一部になって、次のモデルの応答またはアクションを形作る。
これは関数呼び出しの近くにありますが、抽象化の境界は異なります。場当たり的な関数呼び出しでは、アプリケーションの開発者が、ツールのスキーマをその1つのアプリやバックエンド内で直接定義します。それでも狭いユースケースならまったく問題ありません。あなたのプロダクトが searchTickets()、getCustomer()、draftReply() だけを必要とするのであれば、Plainな関数呼び出しが最も単純なアーキテクチャになり得ます。
MCPは、統合の“接点（integration surface）”が大きくなるほど面白くなります。ホストは複数のサーバーに接続できます。サーバーは複数のホストで再利用できます。発見（ディスカバリー）と呼び出し（インボケーション）は、ターゲットごとの専用アダプタではなく、共通のパターンに従います。そのため、実際の比較は「MCPか関数呼び出しか」ではありません。「プロトコルに裏打ちされた統合レイヤーか、場当たり的な統合の増殖か」です。
ローカルサーバーとリモートサーバー
公式のMCPアーキテクチャドキュメントでは、ローカルサーバーは多くの場合stdioを使います。これは、ホストがサーバーをサブプロセスとして起動し、標準入力と標準出力でJSON-RPCメッセージをやり取りするというモデルです。この方式は、デスクトップツール、ローカルファイルアクセス、リポジトリのコンテキスト、開発時のアシスタントにうまく合います。
リモートサーバーは通常、MCP transportドキュメントで説明されている現在のネットワークトランスポートであるStreamable HTTPを使います。このセットアップでは、サーバーは独立して動作し、複数のクライアントに提供でき、他のプロダクションサービスと同様に運用上の統制（ガバナンス）を行えます。
この分割が実務で重要になるのは、そこに役割の違いが生まれるからです。ローカルのMCPサーバーは、IDEのワークフローやローカル自動化にとって理想的であることが多いです。リモートのMCPサーバーは、プラットフォームチームが、プロダクト横断で統合された認証、監査可能性（オーディタビリティ）、共有ガバナンスが必要になるときに頼りにするものです。
エージェントやツールが、現代のワークフローのどこにどう収まるのかをより広いシステムの視点で捉えたいなら、「How to Automate Your Workflows Using AI Agents and Tools」は、ワークフロー側から見たこのアーキテクチャ視点を補完します。
主要な概念
公式のMCPドキュメントは通して読む価値がありますが、実務で特に重要になる概念がいくつかあります。
ホスト、クライアント、サーバー
MCPはクライアントサーバー型のアーキテクチャを使いますが、多くの人は“ホスト”の役割を飛ばしてしまいがちです。
Host: ユーザーに向けたAIアプリケーションで、モデルのふるまい、承認、そして1つ以上のMCP接続を調整します。
Client: 1つのMCPサーバーへの接続管理を行います。
Server: ホストが発見して利用できる機能（ケイパビリティ）を提供します。
この分離は有用です。ホストがユーザー体験とポリシーを持ち、クライアントがプロトコル接続を持ち、サーバーが外部システムへの機能境界（ケイパビリティ境界）を持つためです。
リソース
リソースは、ホストがサーバーから取得できるデータ成果物です。アクションというより、読み取り指向のコンテキストだと考えてください。例としては、リポジトリツリー、ドキュメントページ、設定ファイル、またはデータベースのスキーマなどがあります。
リソースが重要なのは、多くのシステムがより多くのアクションを必要とする前に、まずはクリーンな読み取り専用の表面（サーフェス）を必要とするからです。リソースは、すべてをツールとして公開するよりも安全で、統制しやすいことが多いです。
プロンプト
プロンプトは、サーバーによって公開される再利用可能なテンプレート、または構造化された対話ヘルパーです。価値があるのは、バックエンドやプラットフォームチームがドメイン固有のワークフローを一度だけエンコードし、複数のホストがそれを再利用できるようにできるためです。これにより、その知識を1つのアプリケーション固有のプロンプトファイルの中に埋め込む必要がなくなります。
ツール
ツールは、モデルがサーバー経由でホストに対して呼び出しを依頼できる実行可能な機能です。たとえば、社内ナレッジベースの検索、チケット作成、デプロイのワークフロー実行、人間の承認を伴うトランザクション的なアクションの実行などが考えられます。
OpenAIの関数呼び出しや、これに類するエージェントのフレームワークを使ったことがあれば、ツールは見慣れたものに感じるはずです。MCPの利点は、発見と呼び出しが、各ホストに埋め込まれた自前のラッパーではなく、共有されたプロトコルを通じて行える点にあります。
トランスポート
MCPは単なる命名規則ではありません。クライアントとサーバーがどのように通信するかを定義します。プロトコルはJSON-RPC 2.0のセマンティクスを使いますが、トランスポートはそれらのメッセージが参加者間でどう移動するかを定義します。
現在の標準的なトランスポートは以下です:
ローカルのサブプロセス通信のためのstdio。
ネットワーク通信のためのStreamable HTTP。
これは、アドホックなRESTラッパーからの最も鋭い違いの1つです。RESTラッパーは「あるバックエンドに対してどう呼び出すか」を教えてくれます。MCPは、ライフサイクル、機能（ケイパビリティ）のネゴシエーション、ディスカバリーパターン、そしてホストとサーバーのための一貫した相互作用モデルを定義します。
なぜエコシステムの変化が重要なのか
MCPが重要であることを示す最も強い根拠は、エコシステムのスクリーンショットではありません。複数の大手ベンダーが、これを「実際の統合のための道筋」として今やドキュメント化していることです。
AnthropicはMCPを導入し、AIシステムをデータソースやツールに接続するためのオープン標準として、引き続きドキュメント化しています。
OpenAIはResponses APIにリモートMCPサーバーを文書化し、モデルの機能を拡張するための組み込みツールタイプとしてMCPを扱っています。
GitHubはCopilotにおけるMCP対応を文書化し、ローカルと成長中のリモート双方のサポートについて説明し、公式のGitHub MCPサーバーも提供しています。
Microsoftはエージェント・フレームワークとWindowsの各領域にわたってMCPを文書化しており、発見可能性（ディスカバラビリティ）、封じ込め（コンテインメント）、ガバナンスに強い重点を置いています。
だからといって、すべての製品が現時点でMCPを必要とするという意味ではありません。とはいえ、エンジニアはそれを、スタック全体で信頼に足る統合標準へと育っていくものとして扱えるようになった、ということです。
MCPはいつ価値があるか
MCPは、すべてのAI機能に対して自動的に正しい選択になるわけではありません。ホストが1つで、社内ツールが少数あり、そしてそれらの統合が他の場所で再利用されることを期待していないなら、シンプルなファンクション呼び出しが今でも正しい判断かもしれません。
MCPを採用する価値が出るのは、複雑さの焦点が「モデルはこの関数を呼べるか？」から「統合をチーム、製品、環境をまたいで一貫させるにはどうするか？」へと移ったときです。
MCPを検討する価値があるという製品シグナル
以下のいくつかが当てはまるなら、あなたはMCP領域にいる可能性が高いです：
複数のシステムが重要：AI機能が複数のバックエンドやSaaSプラットフォームにまたがって影響する必要がある。
複数のホストが存在：Webアプリ、社内アシスタント、CLI、IDEなどで、同様の機能が必要になる。
文脈とアクションの両方が重要：モデルが読み取り専用の文脈と、ガードされた書き込み操作の両方を必要とする。
統合が長寿命：コネクタはプロトタイプのつなぎではなく、製品インフラの一部である。
チームにとってMCPが報われる可能性を示すシグナル
プラットフォームチームが標準を所有できる：命名、認証、バージョニング、テストのための慣習を誰かが定義できる。
ガバナンスが重要：ユーザーの承認、監査可能性（オーディタビリティ）、またはロールベースのアクセス制御が必要である。
再利用が重要：複数のチームが同様のツールアダプタを作り直し続けている。
ベンダーのポータビリティが重要：統合ロジックを、特定の独自ツール形式にすべて結びつけたくない。
これは、エンジニアリングチームが単一エージェントでの実験から、社内のAIプラットフォームを構築する方向へ切り替えることが多い局面でもあります。
MCPを後回しにすべきとき
先送りが賢い判断になることもあります。AIユースケースがまだ検証段階である、ツール数が少なく安定している、ホスト間での再利用が期待できない、またはチームがセキュリティやガバナンスの所有に割くだけの余力をまだ持っていない、という場合には、プロダクトチームはおそらく待つべきです。
標準化にはコストがあります。問題が本当にまだそれを必要としていない段階でMCPを採用すると、長期的な複雑さを減らさずに、単に形式（儀式）だけが増えることがあります。
実践的な採用への道筋
強力なMCPのロールアウトは、通常段階的に行われます。一度にすべてを公開しようとするチームは、騒がしいツールの表面と弱いセキュリティ境界に行き着きがちです。
フェーズ1：狭い範囲のサーバーから始める
読み取り・書き込みの境界が明確な、高い価値のある1つのドメインを選びます。良い出発点には、社内ドキュメント検索、リポジトリやイシューのワークフロー、インシデントの文脈、またはCRMの照会などが含まれます。
読み取り中心の機能を最初に優先するのがよいでしょう。テストしやすく、権限付与もしやすく、書き込み中心の自動化よりもリスクが低いためです。
フェーズ2：スケール前にガバナンスを定義する
ここが、多くのチームが作業量を過小評価するポイントです。OpenAI自身のリモートMCPサーバーに関するガイダンスは、悪意のあるサーバーがモデル文脈に入った機密データを持ち出す可能性があるため、開発者はリモートサーバーを慎重に信頼すべきだと警告しています。GitHubは、パフォーマンスとセキュリティの両方を改善するためのツールセットのカスタマイズを強調しています。Microsoftは、封じ込め（コンテインメント）、ユーザーの制御、ログ記録を強調しています。
共有される教訓はシンプルです：MCPはガバナンスを置き換えません。ガバナンスをより見えるものにします。
最低限、次を定義します：
認証：ホストがリモートサーバーに対してどう認証するか。
認可：それぞれのロール、テナント、または環境がアクセスできるツールとリソースはどれか。
承認ルール：どのアクションが明示的なユーザー確認を必要とするか。
ログ：何がリストされ、何が読み取られ、何が呼び出され、何が承認され、何がブロックされたか。
サーバー所有：各サーバーを誰が維持し、どのような変更プロセスをとるか。
フェーズ3：ラッパーとしてだけでなく、インターフェースとしてテストする
MCPサーバーは、それ自体がプロダクトであるかのようにテストされるべきです。有用なレイヤには、コントラクトテスト、権限テスト、代表的なエンドツーエンドのタスク、レイテンシチェック、リスクの高いアクションに対する人の承認テストなどがあります。
ツールは技術的には正しくても、説明が曖昧だったり、名前が紛らわしかったり、引数が誤用を促すような形だったりすると、運用上失敗することがあります。
これは、ワークフロー自動化全般で重要になるのと同種のガードレールの考え方です。MCP仕様自体の外側でAIの安全性とインターフェースの規律について考えたいなら、AI-Generated n8n WorkflowsからProductionへ：本当に機能するガードレール is a useful parallel（実用的な並行の例）です。
フェーズ4：パターンが安定した後に拡張する
1つのサーバーがうまく動いたら、学んだことを標準化します：命名規約、共有の認証ミドルウェア、説明スタイルのガイドライン、観測（オブザーバビリティ）のパターン、そしてバージョニングのルールなどです。
ここでMCPは価値が複利のように積み上がり始めます。この前の段階では、余分なプロトコル作業に感じられるかもしれません。しかしこの後になると、実際のプラットフォーム活用（レバレッジ）に見え始めます。
落とし穴と誤解
MCPは重要な問題を解決しますが、実際以上に解決してくれると期待しやすいのも事実です。
MCPはあなたのセキュリティ・アーキテクチャではない
このプロトコルはアクセスを構造化するのに役立ちます。しかし、そのアクセスを誰に与えるべきかは決めません。アイデンティティ、シークレットの取り扱い、レート制限、テナント分離、承認UXは、あなたの責任として残ります。
MCPはエージェントのオーケストレーションの代替ではない
MCPは、ホストとサーバーがどのように接続し、機能（ケイパビリティ）をどのようにやり取りするかを示します。しかし、アプリケーションがどう計画し、どうリトライし、失敗からどう回復し、長い複数ステップのワークフローをどう調整するかについては指示しません。これらの懸念は、ホストまたはエージェントの実行環境に属したままです。
MCPは良いツール設計の代わりにはならない
良いプロトコルで公開されたとしても、悪いツールは悪いツールです。ツールが広すぎる、名前が不適切である、あるいは副作用について不明確だと、モデルの挙動は悪化します。
MCPはベンダー固有の挙動を排除しない
標準プロトコルは相互運用性を改善しますが、ポータビリティは、異なるクライアントやサーバーがどれだけ忠実に仕様を実装するかにも依存します。認証フロー、承認メカニズム、トランスポートの選択、そして製品UXは、依然として変わり得ます。
MCPが常に最初の一手として最良とは限らない
チームがまだ「その機能にユーザー価値があるか」を証明している最中なら、最初によりシンプルなファンクション呼び出しのアーキテクチャを出荷しても問題はありません。インフラの成熟度は、製品の現実に後から追随すべきです。
Model Context Protocol（モデル・コンテキスト・プロトコル）は、近代的なAIシステムにおける現実のボトルネック——モデルを有用なツール、信頼できるデータ、そしてエンタープライズのワークフローに、整合的な形で接続するコスト——に対処しているため、信頼に足る標準として出てきています。最も重要な変化は、ある会社がプロトコルを発表したことではありません。エコシステムの複数の領域が今や、MCPを真剣な統合レイヤとして扱っていることです。
エンジニアリングチームにとっての実務的な結論は明快です。統合、再利用、ガバナンス、そしてプラットフォームとしての一貫性が、生の短期スピードよりも重要ならMCPを採用してください。製品がまだシンプルで、オーダーメイドのツールの方が安く、かつ明確であるならMCPは先送りにしてください。いずれにせよ、流行（ハイプ）としてではなく、アーキテクチャとして評価してください。
要点：
レイヤーで考える：Model Context Protocol（MCP）は、AIホストと、文脈や機能を提供する外部システムの間に位置します。
再利用が重要なときに使う：MCPは、複数のホスト、複数のシステム、または複数のチームが共有された統合の契約を必要とする場合に最も価値があります。
セキュリティは明示的に：このプロトコルはアクセスを整理するのに役立ちますが、認証（auth）、承認（approvals）、監査可能性（auditability）は、依然として慎重なエンジニアリングを要します。
範囲を絞って始める：適切に設計された1つのMCPサーバーは、契約が弱いままの大規模な展開よりも多くを学べます。
プラットフォーム作業として扱う：長期的な成果は、プロトコルの採用だけでなく、慣習（conventions）、テスト（testing）、ガバナンス（governance）から得られます。
次の実践的なステップは、1つの領域を選び、狭いサーバーの表面（surface）を定義し、より広いMCP戦略を展開する前に、実際のユーザーのタスクでそれをテストすることです。
MCPが、次世代のAIを活用したアプリケーションをどのように形作っているのかを発見してください。
続きを読む： https://fakharkhan.com/
