MCPとは何か。なぜ今、あらゆるAIツールが突然それを話し始めたのか

この10年の大半、AIモデルを自社のツールにつなぐには、組み合わせごとに個別の連携を作る必要があった。Anthropicが2024年11月に公開したオープン標準、Model Context Protocolは、それをどこにでも刺さるひとつのプラグに置き換えた。OpenAI、Google、Microsoftもその後、これを採用している。実際にどう動くのか、そしてチームのデータにつなぐ前に確認すべき本当のチェックリストをまとめる。

Claudeのデスクトップアプリを開き、チームの未解決のプルリクエストを確認して、と頼むと、それはそのままできる。AnthropicがClaudeにGitHub連携を組み込んだからではない。どこかで——社内のIT、ベンダー、GitHub上の開発者——誰かがMCPというプロトコルを話す小さなプログラムを書き、Claudeはすでに、それを話す相手なら何とでも話せるようになっているからだ。同じことが今、ChatGPT、GoogleのGemini、Microsoft Copilotにも当てはまる。個別の機能リリースよりも、この収束こそが、ほぼすべてのAIベンダーがこの1年、MCP対応の構築に時間を費やした理由である。

MCPが実際に何であるか

MCPはModel Context Protocolの略だ。Anthropicが設計し、2024年11月25日に仕様と最初のSDKをオープンソースとして公開した。発表資料は、残るたとえでこの考えを説明している。MCPをAIアプリケーションのためのUSB-Cポートだと考えてほしい——アクセサリごとに違うケーブルではなく、物理コネクタの標準がひとつ、という話だ。発表時点でAnthropicは、自社製品にMCP対応を組み込み始めていた初期採用者として、エンタープライズソフトウェア企業のBlockとApollo、開発者向けツールのZed、Replit、Codeium、Sourcegraphを名指しした。Claudeのデスクトップアプリは同じ日に、本人のマシン上でMCPサーバーをローカル実行できる状態で出荷された。

それが解く問題：N個のツール × M個のデータ源

MCPが解く問題には、エンジニアが気軽に使う名前がある。N×Mの連携問題だ。ある会社が、社内データに作用する必要があるAIツールを5つ使っているとする——Claude、ChatGPT、GitHub Copilot、Cursor、社内サポートボット。そのデータは8か所にある。Slack、GitHub、Postgresデータベース、Salesforce、Notion、Google Drive、Jira、社内API。共通のプロトコルがなければ、すべてのツールをすべてのデータ源に実用的につなぐには、最大40本の個別連携が要る。5×8だ。それぞれに独自の認証方式、独自のエラー処理、そしていずれかのAPIの形が変わるたびにかかる独自の保守コストがある。6つ目のAIツールを足せば、数は48に跳ねる。実際には、誰も40本すべてを作らなかった。各AIベンダーは工数に見合うと判断した一握りだけを作り、それ以外は手作業のままだった。コピーして、貼り付けて、説明し直して、また繰り返す。

MCPは掛け算を足し算に変える。Claudeに自社のPostgresを読ませたい会社は、Claude専用のPostgresコネクタを作らない。Postgresを公開するMCPサーバーをひとつ作る——あるいは、誰かがすでに公開したものを再利用する。そのサーバーは、追加のコードなしでClaude、ChatGPT、Gemini、その他のMCP対応エージェントで動く。Anthropic自身のリストは、発表時点でGoogle Drive、Slack、GitHub、Git、Postgres、そしてPuppeteerと呼ばれるブラウザ自動化ツール向けの既製サーバーを挙げていた。要点は、Anthropicが全部を作ることではなかった。誰でも作れる、ということだ。利用可能なサーバーのカタログは、一社の人員では賄いきれない規模まで広がっている。

プロトコルが実際にどう動くか

枠組みを外せば、MCPはかなり素朴なクライアント・サーバー・プロトコルで、わざと華やかさがない。役割は3つだ。Hostは、人が実際に開くアプリケーション——Claude Desktop、CursorのようなIDE、ChatGPTアプリ。HostはMCP Clientを内蔵し、それがMCP Serverへの直接のステートフル接続を開く。MCP Serverは、特定のひとつのシステムを公開する小さなプログラムだ。データベース、チケットツール、ファイルシステム、社内API。クライアントとサーバーはJSON-RPC 2.0形式のメッセージをやり取りする。既存のインフラでもよく使われる、軽いリモート手続き呼び出しの形式だ。トランスポートは2つのうちどちらか。stdioは、サーバーが同じマシン上でローカルに動くプログラムのとき。Streamable HTTPは、別の場所で動くホストされたサービスのとき。

サーバーが公開できるものは、3つのプリミティブに尽きる。Toolsは、モデルが行動するために呼べる関数だ——create_task、run_query、send_message。いつ呼ぶかは、会話に応じてモデルが決める。Resourcesは、モデルが頼まなくてもHostが取り込み、モデルに渡せる読み取り専用の文脈だ。ファイルの中身、データベースのスキーマ、サポートチケット。Promptsは、人が明示的に起動する再利用可能なテンプレートだ。「このスレッドを要約して」「ステータス更新を下書きして」といった定型を、モデルが勝手にやるのではなく、人が呼び出す。よくできたサーバーは、ある能力について3つのどれを出しているかを明示する。その区別こそが、接続されたAIツールが何かを見るだけなのか、変えることもできるのかを決めるからだ。

ほかに誰が、いつ採用したか

MCPの最初の数か月は、Anthropicだけのプロジェクトだった。それはすぐに変わった。しかもAIでは本当に珍しい変わり方だった。直接の競合が、自前のプロトコルを出すのではなく、一社のプロトコルに収束したのだ。OpenAIは2025年3月、Agents SDKにMCP対応を加え、開発者がOpenAI専用の個別ツール連携を作る代わりに、任意のMCPサーバーへエージェントのワークフローをつなげられるようにした。翌月、Google DeepMindは、Geminiと自社のエージェント開発キットもMCPをサポートすると確認した。Googleはこの動きを、補完的な自社プロトコルAgent2Agentと組にしている。狙いは、独立したエージェント同士が、ツールとではなく互いと協調できるようにすることだ。2025年5月までにMicrosoftは、Windows AI Foundryと呼ぶ仕組みを通じてWindows 11にネイティブのMCP対応を入れ、GitHub CopilotとCopilot Studioにもサポートが入った。

この4社は、モデルのアーキテクチャ、価格、プラットフォーム戦略については、ほとんど同意していない。それでも4社とも今、エージェントをツールにつなぐために同じプロトコルを話す製品を出荷している。この業界では、それ自体が十分に珍しく、個々の機能よりもこちらが本題だ。

なぜこれは配管の話ではなく、信頼の話なのか

この収束は確かに役に立つ。そしてまさにそのために、MCPは盲目的な信頼ではなく検証に値する。エージェントが会社のシステムにつながることをごく簡単にするプロトコルは、作りの悪い、あるいは設定の悪い接続が同じシステムに届くことも、同じくらい簡単にする。MCP自体はそれを防がない。仕様が定めているのは、クライアントとサーバーがどう話すかだ。誰が接続を許可できるか、その接続が何に触れてよいか、何かがおかしくなったときに誰かが気づくかについては、何も言わない。その選択は、目の前の特定のサーバーやクライアントを作った、あるいは設定した側に完全に委ねられている。丁寧に全部作るベンダーもいる。まったく作らないベンダーもいる。プロトコルは後者を止めない。

ひとつつなぐ前のチェックリスト

チームがMCPサーバーをつなぐ前に——ベンダーの製品でも、GitHubで見つけたオープンソースでも、社内で作ったものでも——6つの問いが、統制された接続と開いた扉を分ける。どれも仕様書を読む必要はない。承認をクリックする前に誰かが問い、接続画面が返す答えを実際に読むことだけが要る。

よくできた接続は実際にどう見えるか

FabricLoop自身のMCPの組み方は、このチェックリストへの具体的な答えだ。珍しいからではなく、各部品が上の6つの問いに直接対応していて、マーケティング版ではなく実際の仕組みを名指しする価値があるからだ。FabricLoopは両方の役割を同時に担う。外のツールが接続してくるMCPサーバーであり、Cursor、Claude、ChatGPTが、特定の人自身のFabricLoop権限でタスクを作り、コメントを足し、ノートを読める。同時に外へつながるMCPクライアントでもあり、チャンネルがGitHubやLinearのようなベンダーのMCPアプリを取り込み、チームメイトのように@メンションできる。

これは特別なエンジニアリングではない。小さく、わざと地味な決定の集まりを、一貫して繰り返しているだけだ。範囲を絞る。人に結びつける。記録する。巻き添えなく取り消せるようにする。これは、このサイトがLegibilityについてより広く述べているのと同じ主張だ。名前を付け、記録し、取り消せるアクセスは、誰も考えなくてよいアクセスに勝る。MCPがそれを届けるのは、誰かがそのように作ったときだけだ。プロトコルは配管を標準にする。ガバナンスを自動にはしない。

本当に大事な決定

MCPは消えない。今さら反対するのは、USBに反対するのと少し似ている。主要なモデル提供者はすべてこれを出荷し、使えるサーバーの一覧は増え続けている。ツールに届かないエージェントは、実際の仕事の大半では、あまり何もできないエージェントだ。面白い決定は、AIツールを自社システムにつなぐかどうかではない。その決定のある版は、すでにあなたに代わって下されつつある。チームがすでに使っているツールが、細則を読まずにクリックした機能の下で、静かにMCP対応を足していく。ひとつずつの連携として。まだ本当に自分のものである決定は、承認をクリックする前に何を確認するかだ。