こんにちは、Lena です。AI のそばに長く座り、その振る舞いを見てきただけの人間です。
私の文章を読んでくれる人は、たいてい答えだけを求めてここに来るわけではありません。エージェントをつくり、同じ場所で何度も壊れるワークフローを直し、ずっと付き添わなくてももう少し信頼できるシステムにしたい。そういう人たちです。能力が足りないわけではなく、ただ誰かと一緒に、丁寧に考えたいだけなのだと思います。
この記事は、ひとつの言葉について書きます。MCP です。
最近、どこにでも顔を出すようになりました。開発者フォーラム、ツールのドキュメント、AI エージェントが外の世界につながる話——どこにも MCP が出てきます。それでも、ずっと気になっていることがあります。言葉としては使われているのに、実際に何をしているのかを腰を据えて説明してくれる場面は、意外なほど少ないのです。
では。それは何なのか。どんな問題を解いたのか。そして、どこまでが射程なのか。
このプロトコルが発表されてからずっと追いかけてきました。今はだいぶ見えてきた部分もあれば、まだ手探りの部分もあります。ただ、かなり確信を持てることがひとつあります。AI エージェントに何かしら関わるなら、MCP は「読み飛ばしていい話」ではありません。
最初からいきましょう。
この記事で扱うのは、MCP が何か、どう動くか、誰がサポートしているか、エコシステムに何があるか、そして本当の限界がどこにあるか、です。専門知識は前提にしませんが、雑に単純化することもしません。
MCP とは？
MCP — Model Context Protocol は Anthropic によって提案されたプロトコルで、AI システムが外部ツールとどうやりとりするかを標準化しようとするものです。実務では、開発者が MCP サーバーを立て、ファイルアクセスや API などの能力を Claude のようなエージェントに公開します。これが技術的な答えです。では、現場ではどういう意味になるのか。
MCP がなかったころ、開発者は AI アシスタントを何か——データベース、カレンダー、GitHub のリポジトリ、ウェブ検索エンジン——につなぐたびに、毎回ゼロからカスタムコネクタを書いていました。ツールごとに、プラットフォームごとにです。Claude の上でつくりながら GPT-4 も使うなら、実質ふた通り書くことになります。
MCP が解こうとした問題
USB-C が普及する前の充電ケーブルを思い浮かべてください。機器ごとに独自コネクタがあり、三台持っていれば三本必要でした。一本一本は動く。でも、システム全体として見ると混沌でした。
MCP 以前は、データソースやツールのたびにカスタムコネクタを組むことが多く、Anthropic が言う「N×M」のデータ連携問題——AI システムが N、ツールが M なら、最悪 N×M 種類の統合が要る——に陥りがちでした。複製される作業があまりに多かったのです。
MCP は 2024 年 11 月に Anthropic から発表され、コンテンツリポジトリ、業務管理ツール、開発環境などのデータシステムへ AI アシスタントをつなぐためのオープン標準として位置づけられました。最初の日からオープンソースでした。そのことが、後の広がり方にとても効きました。
MCP の仕組み——基本アーキテクチャ
核になるのは、共通言語を決めることです。MCP は、アプリケーションがファイルを読み、関数を実行し、文脈に沿った prompts を扱うための、標準化されたやり方を与えます。
プロトコルの土台は JSON-RPC 2.0 です。軽量で、すでに広く使われているリモート手続き呼び出しの規格です。MCP は Language Server Protocol（LSP）のメッセージフローの考え方も再利用しています。VS Code や Vim など、エディタ横断でコードインテリジェンスを一貫させたのと同じ系譜です。その設計に聞き覚えがあるなら、それはうまくいっているからです。ひとつの標準、多数の実装。
頭に置いておきたいモデルはこうです。MCP が変えるのは、モデルが 何を考えられるか ではなく、何に手が届くか です。
altexsoft による MCP アーキテクチャ図
MCP サーバーと MCP クライアント
MCP の両側が腹落ちすると、あとはだいたいつながります。
MCP サーバーがすること
MCP サーバー は、ツール・データ・リソースといった能力を、標準化された形で外に出すソフトウェアです。その能力の持ち主がサーバーをつくります。GitHub は GitHub 用に、Stripe は決済用に、Figma はデザインファイル用に。
何を公開するかはサーバーが決めます。 AI が呼べるツール、読めるデータ、取っていいアクションを定義します。アクセス制御は、ここにあります。
MCP クライアントがすること
MCP クライアント は、AI アプリケーションそのもの——実際に話しかける側です。Claude.ai は MCP クライアントです。ChatGPT のデスクトップアプリも、Cursor（AI コードエディタ）もそうです。「GitHub の issue を調べて」「データベースに何があるか見て」と頼むと、適切なサーバーを呼ぶのが、このクライアント層です。
ここでの分離がきれいなのは重要な点です。クライアントは、GitHub の API が内部でどう動いているかを知る必要はありません。MCP で話せればよく、実システムへの翻訳はサーバーが引き受けます。
ディスカバリと接続はどう起きるのか
いまだ成熟の途中にあるのがこのあたりです。現時点では、MCP サーバーが何をできるか知るには、まず接続する必要があります。そのため、クライアントが利用可能なサーバーを一覧したり、レジストリのような仕組みが能力を自動で目録化したりするのは簡単ではありません。
MCP チームはここに手を入れています。ロードマップには、.well-known URL を通じてサーバーが自己紹介できるようにする案もあります。接続前にクライアントが読める、表向きの「名刺」のようなものです。検索エンジンがフルロードなしで読める metadata をサイトが出すのに少し似ています。
現状のディスカバリは、だいたい手作業です。クライアントにサーバーの URL を設定し、認証し、接続したタイミングで利用可能なツールを学びます。MCP は OAuth 2.1 認証を使うため、AI に何をさせてよいかは明示的に許可します。あなたの許可なしにアカウント上で動くことはありません。
誰が MCP をサポートし、何が手に入るのか
モデルプロバイダー（確認済み）
採用曲線は、どの基準で見ても速い部類です。発表のあと、OpenAI や Google DeepMind をはじめとする主要プロバイダーがプロトコルを採用しました。
Anthropic は 2024 年 11 月に MCP を紹介し、すぐにオープンソース化しました。2025 年 1 月には Cursor や Windsurf のような AI 開発ツールがすでに対応していました。2025 年 3 月には OpenAI が正式採用。Google DeepMind が続き、Microsoft は Windows レベルでの MCP サポートを表明し、Azure や Semantic Kernel にも組み込みました。
2025 年 12 月、ガバナンスは大きく動きました。Anthropic は MCP を Agentic AI Foundation に寄贈しました。Linux Foundation 傘下のディレクテッド・ファンドで、Anthropic、Block、OpenAI が共同発起した組織です。MCP は「Anthropic のプロトコル」から「業界全体のプロトコル」へ移った——その意味は小さくありません。
2026 年初頭の時点では、2025 年 11 月に出た現行仕様が、主要プロバイダーが実装の基準に据えている安定版です。SDK は Python、TypeScript、C#、Java があります。
コミュニティの MCP サーバーエコシステム
ここが一気に面白くなったところです。2026 年 3 月までに、MCP の SDK は月間 9,700 万ダウンロードに達し、コミュニティ製サーバーは 5,800 件を超えました。
公式の MCP サーバー・レジストリ を眺めると幅が実感できます。GitHub（リポジトリ管理、issue、PR）、Stripe（決済と顧客）、Figma（デザイン文脈）、PostgreSQL（データベースクエリ）、Slack（チームコミュニケーション）、AWS サービス、Kubernetes 管理、Elasticsearch、それに加えてもっとたくさんあります。
MCP の steering group が保守する reference server 用のリポジトリは、MCP の機能と SDK の使い方を示す少数のリファレンス実装を置く場所です。自前のサーバーを書く開発者向けの教材であって、そのまま本番に載せる完成品の倉庫ではありません。実際に本番で熱を帯びているのは、コミュニティ製サーバーと、大手プラットフォームの公式統合のほうです。
セキュリティについて、かなり実務的な注意です。MCP の仕様はツール実行前にユーザー承認を要求しますが、初期実装のなかには、その承認ステップをきちんと組み込めていない host もありました。悪意あるサーバー応答を通じた prompt injection は現実の懸念です——侵害された MCP サーバーは、出力経由で AI の振る舞いを操ろうとするかもしれません。新しい MCP サーバー、とくにコミュニティ製に接続するときは、どんな権限を渡すのか必ず確認してください。
MCP が解くこと、解かないこと
ここは、たいていさらっと流されがちです。正直、いちばん面白い問いが溜まっているのもここです。
接続と能力の永続化は別の話です
MCP が解くのは 接続 です。きれいに、スケールする形で、しかも業界の広い合意を伴って。それだけでも十分に大きい話です。
MCP が解かないのは、接続が成功した あと に何が起きるかです。典型的なエージェントワークフローを思い浮かべてください。AI がツールにつながり、呼び出し、結果を得て、それを使って出力をつくる。そして会話が終わる——あるいはコンテキストウィンドウが一杯になり、セッションが切れる。
ツール呼び出しは起きた。結果も使われた。それでも、そのやりとりが永続的で再利用可能な形で残ったわけではありません。
次のセッションを始めたとき、同じエージェントは前回うまくいったこと、失敗したこと、どの呼び出しの連鎖がいちばん良かったかを覚えていません。ゼロからです。同じ間違いを繰り返すかもしれない。同じ検索の踏み方をやり直すかもしれない。これは MCP 固有の欠陥というより、単に MCP の射程の外にあります。
なぜ成功したツール呼び出しが再利用可能な知識にならないのか
具体例をひとつ。コードベースで繰り返し出る不具合を、AI エージェントにデバッグさせたとします。エージェントは GitHub の MCP サーバーにつながり、いくつかファイルを読み、検索を回し、数試行のあと根本原因にたどり着き、修正案を出す。うまくいきました。
ふた週後、似ているけれど別の症状が出ます。エージェントは再び MCP 経由で GitHub につながります。同じプロトコル、同じ標準、同じ信頼できる接続。それでも、前に何を理解したかの記憶はありません。成功したデバッグの経路は、構造化された場所に保存されていません。関連する別の問題に取り組む別のエージェントがそれを継承することもできません。解決は、閉じた会話のなかに閉じ込められたままです。
これは MCP を貶めたいわけではありません。設計どおりのことをしています。AI システムと外部ツールのあいだに、標準化され信頼できるインターフェースを与える——それが MCP です。ローカルツールを配線する手段からはるかに進み、大小の企業の本番でエージェントワークフローを動かしています。それは確かな前進です。
ただ、接続のインフラと能力の永続化は、別問題です。前者は MCP が担い、後者は次世代のエージェント基盤が焦点を当てているところです。
限界とトレードオフ
このプロトコルが育つのを見てきて、率直に感じたことをいくつか書いておきます。
ステートフルなサーバーのスケールは、まだ難しい。 現行実装はリクエスト間で状態を覚える必要があることが多く、複数インスタンスへの水平スケールはつらいです。Streamable HTTP transport がステートレス寄りの道を一部開きますが、サーバー起動や session まわりの痛みは残ります。2026 年の roadmap がこの問題を正面から扱っていますが、本番を大規模に載せるなら知っておく価値があります。
エンタープライズ認証は、まだ追いついている途中です。 仕様は OAuth ベースの認可を支え、OAuth 2.1 のエンタープライズ統合は 2026 年 roadmap に載っています。厳格な IdP 要件の規制産業では、まだ穴もあります。MCP を載せた企業は、監査証跡、SSO 連携認証、gateway の振る舞い、設定の持ち運びといった、予想どおりの課題にぶつかっています。
セキュリティの重みは実装側に乗ります。 MCP 自体がプロトコル層でセキュリティ原則を強制することはできません。実装者が、堅牢な同意と認可の流れを組み、セキュリティ上の含意を明瞭に文書化し、適切な access control を入れる必要があります。プロトコルを軽く保つという設計としては筋が通っていますが、エコシステム全体でセキュリティの質にばらつきが出ます。
ディスカバリは、いまだほぼ手作業です。
先に書いたとおり、つなぎたいサーバーを、たいてい自分で知っておく必要があります。レジストリのプレビューや .well-known URL の仕事は助けになるでしょうが、いまは新しいユーザーがエコシステムを探るときの摩擦になっています。
コミュニティサーバーの品質は幅が大きい。 5,800 件を超えれば、分布はかなり極端です。GitHub や Stripe のように、企業自身が保守しセキュリティを優先しているものもあれば、コミュニティの実験もあります。未知のサーバーは、第三者のコードと同じ目で見てください——何にアクセスを許すか、レビューが要ります。
FAQ
MCP は開発者向けだけですか？
厳密には違いますが、今日触れるのはだいたい開発者ツール経由です——Cursor や Windsurf のようなコードエディタ、AI IDE、エージェント向けフレームワークです。アプリが内部に MCP サポート を埋め込めば、エンドユーザーはその存在を意識せずに使うことになります。
MCP を使うと、AI は私のパソコンやアカウントで何でもできるようになるのですか？
いいえ。各 MCP サーバーは、開発者が公開したものだけを出し、あなたが明示的にアクセスを許可します。接続は広い権限ではなく、そのサーバーが定義した具体的な能力を渡すだけです。とはいえ、新しいサーバーに接続するときは、何を許可するか確認するに越したことはありません。
MCP と普通の API 呼び出しの違いは何ですか？
普通の API 呼び出しでは、その API と話すよう AI システムを個別にプログラムする必要があります——専用コード、固定エンドポイント、独自の認証処理です。MCP はそれを標準化し、準拠した AI クライアントなら、両端にカスタムコードなしで準拠したサーバーと話せます。USB 機器ごとにドライバを書くか、標準の USB プロトコルがあるか、の違いに近いです。
MCP は異なる AI モデル間でも動きますか？
はい。これは重要な性質のひとつです。MCP は普遍的なインターフェースです——企業が MCP サーバーをひとつつくれば、MCP を話せる Claude、ChatGPT、そのほかのいずれのアシスタントからもつながれます。
MCP は function calling とどう違いますか？
function calling（ツール利用とも呼ばれます）は、特定のモデルがツールを起動するメカニズムです。MCP はその 上 にある標準化されたプロトコル層で、ツールがどう発見され、記述され、システム間でやりとりされるかを定めます。function calling はひとつの AI の内側の仕組み、MCP はエコシステム全体の共通語、と考えると分かりやすいです。
MCP は公式に安定しているのですか？
現行の仕様リリースは 2025 年 11 月です。公式仕様 は、実装の基準として安定していると見なされています。2026 年 roadmap は、エンタープライズ対応、スケール、ディスカバリ改善に焦点があり、プロトコルの根本変更が主眼ではありません。多くの用途では、いま手に入るものは本番に耐えうる段階にあります。
利用できる MCP サーバーはどこで見つかりますか？
MCP Registry が公式のカタログです。コミュニティ管理の awesome-mcp-servers も網羅的です。リファレンス実装については、Anthropic が GitHub で modelcontextprotocol/servers を保守しています。
この先どう変わっていくのか、まだ見ています。接続の問題は本当に解けつつある気がします——その次に、能力のレイヤで何が起きるのかが、おもしろい問いです。
