MCPとは？AI連携の仕組みと主要クライアントでの接続方法を解説

生成AIを業務に組み込む動きが進むなかで、MCPという言葉を目にする機会が急速に増えています。社内のデータをAIに読ませたい、問い合わせ内容からチケットを起票させたい、自社の情報をAIに正確に説明させたい。そうした要望に共通して立ちはだかるのが、AIと外部システムをどうつなぐかという問題であり、その答えとして広く採用されつつあるのがMCPです。検索経由の流入を見てきたSEOの担当者にとっても、AIが自社をどう説明するかを左右する仕組みとして、無関係ではいられなくなってきた話題です。

MCPとは何かをあらためて整理する

MCP（Model Context Protocol）は、AIアプリケーションを外部のシステムと接続するためのオープンな標準規格です。公式ドキュメントでは、ローカルファイルやデータベースといったデータソース、検索エンジンや計算機といったツール、特定の作業に特化したプロンプトといったワークフローに、ClaudeやChatGPTのようなAIアプリケーションが接続するための仕組みだと説明されています。重要なのは、MCPが定めているのはあくまで文脈情報を受け渡すための手順だけであり、AIがその情報をどう使うか、どのモデルで処理するかには一切関与しないという点です。つまりMCPは、AIの賢さを競う技術ではなく、AIが外の世界とやり取りするための共通の作法を決めた規格だと理解するのが正確です。

Anthropicが公開し標準化団体へ移管されるまでの経緯

MCPは、2024年11月25日にAnthropicがオープンソースとして公開しました。同社の発表では、どれほど高度なモデルであってもデータから切り離されていれば能力を発揮できず、新しいデータソースごとに個別の実装が必要になる状況が、真に接続されたシステムの実現を難しくしていると指摘されています。この課題に対して、断片化した個別連携を単一のプロトコルで置き換えることを狙ったのがMCPでした。

公開当初はAnthropicが主導する形で開発が進みましたが、2025年12月9日、MCPはLinux Foundation傘下のAgentic AI Foundationへ移管されることが発表されました。この財団はAnthropic、Block、OpenAIが共同で設立し、Google、Microsoft、AWS、Cloudflare、Bloombergが支援に名を連ねています。特定の企業に属さない中立的な統治体制へ移ったことは、MCPが一社の製品仕様ではなく業界共通の標準として扱われるようになったことを意味します。同発表では、月間9,700万回を超えるSDKのダウンロードと1万を数える稼働中のサーバーがあり、ChatGPT、Claude、Cursor、Gemini、Microsoft Copilot、Visual Studio Codeといった主要クライアントで正式対応が進んでいることも示されました。

AIのUSB-Cポートと呼ばれる理由

MCPを説明する際によく引用されるのが、公式ドキュメントに書かれている「AIアプリケーションにとってのUSB-Cポートのようなもの」という比喩です。USB-Cが機器同士の接続方法を統一したように、MCPはAIアプリケーションと外部システムの接続方法を統一する、という意味合いになります。

この比喩が的を射ているのは、USB-Cが解決した問題とMCPが解決しようとしている問題の構造が同じだからです。かつては機器ごとに専用のケーブルとコネクタが必要で、増えるほど管理が煩雑になりました。AIと外部システムの連携も同じ状態にありました。AIツールごとに、接続先のサービスごとに、専用の連携コードを書く必要があったのです。接続の形状を先に決めてしまえば、あとは規格に合わせて作るだけで済むという発想は、両者に共通しています。企業のWEB担当者にとっては、自社のシステムやコンテンツにこの共通のコネクタを一つ用意しておけば、どのAIツールからでも同じように使えるようになる、と捉えると理解しやすいでしょう。

AIエージェントがMCPを必要とする理由

生成AIを業務で使うこと自体は、すでに特別な取り組みではなくなりました。総務省の令和8年版情報通信白書によると、自社の何らかの業務で生成AIを利用していると回答した企業の割合は、中国が98.1%、ドイツが91.6%、米国が90.9%、日本が86.4%でした。白書は日本について、2024年度の調査に比べて大幅に上昇し、他の三か国との差も縮まる結果になったと述べています。

出典: 総務省 令和8年版情報通信白書 図表Ⅰ-2-1-6（2026年）

一方、組織としての方針づくりはまだ追いついていません。同じ白書によると、生成AIを積極的に活用する、あるいは領域を限定して利用すると回答した企業の割合は、日本が68.9%でした。前年度の49.7%から大きく上昇したものの、他の三か国と比べると引き続き低い水準にとどまっています。業務で使うこと自体は当たり前になり、次はどう位置づけて管理するかが課題になっている段階だといえます。

MCPが短期間でこれほど広く受け入れられた背景には、AIの使われ方が「質問に答えるもの」から「作業を代行するもの」へ移り変わったという変化があります。文章を書くだけなら外部との接続は不要ですが、社内の情報を調べて資料をまとめる、在庫を確認して発注する、といった作業を任せようとした瞬間に、AIは外の世界に触れる必要が生じます。この接続部分を場当たり的に作ると何が起きるのかを、順に見ていきます。

従来のAI連携が抱えていたN×M問題

MCPが登場する以前、AIツールと外部サービスの連携は一対一で個別に実装するのが当たり前でした。この方式には、組み合わせの数が掛け算で増えていくという構造的な弱点があります。仮にAIアプリケーションがM種類あり、つなぎたい外部サービスがN種類あるとすると、必要な実装はM×N通りになります。この掛け算の爆発は、しばしばN×M問題と呼ばれてきました。

具体的に考えると深刻さがわかります。社内でチャットボット、営業支援AI、ドキュメント生成AIの三つを使っているとして、それぞれから顧客管理システム、勤怠システム、ファイルサーバー、分析ツールの四つにつなぎたいとします。この時点で必要な連携は十二通りです。AIツールが一つ増えれば四つ、接続先が一つ増えれば三つの実装が追加で必要になります。しかも、それぞれの実装は接続先の仕様変更に追随して保守し続けなければなりません。連携が増えるほど開発コストと技術的負債が積み上がり、新しいツールを試すことすら難しくなっていくという状態に陥ります。

MCPが実現する一対多の標準接続

MCPはこの掛け算を足し算に変えます。AIアプリケーション側はMCPクライアントとしての実装を一度だけ行い、外部サービス側はMCPサーバーとしての実装を一度だけ行えば、あとは両者が自動的に噛み合います。必要な実装はM×N通りからM+N通りに減るということです。先ほどの例であれば、十二通りの個別実装が七つの標準実装に置き換わります。

この効果は、実装の総量が減ること以上に、変化への強さとして現れます。新しいAIツールを導入したくなったとき、そのツールがMCPに対応していれば、既存のMCPサーバーはそのまま流用できます。逆に新しい社内システムをAIから使えるようにしたいときは、MCPサーバーを一つ用意すれば、社内で使っているすべてのAIツールから同時に使えるようになります。AI分野は移り変わりが激しく、数か月単位で主力ツールが入れ替わることも珍しくありません。接続部分を規格化しておくことは、そうした変化に振り回されずに済むための備えでもあります。

MCPの仕組みとアーキテクチャ

MCPの内部構造は、役割の分担と層の分離という二つの軸で整理すると理解しやすくなります。技術的な詳細まで踏み込む必要はありませんが、どこで何が起きているのかを把握しておくと、後述するセキュリティ上の注意点や導入時の判断がしやすくなります。

ホストとクライアントとサーバーという三つの役割

MCPはクライアントとサーバーによる構成を取り、そこにホストという概念が加わります。公式ドキュメントでは、それぞれの役割が次のように定義されています。

• MCPホスト
  一つ以上のMCPクライアントを調整し管理するAIアプリケーション
• MCPクライアント
  MCPサーバーとの接続を維持し、ホストが使うための文脈情報を取得する構成要素
• MCPサーバー
  MCPクライアントに文脈情報を提供するプログラム

具体例で言えば、Visual Studio CodeやClaude Codeがホストにあたります。ホストが一つのMCPサーバーに接続すると、そのサーバー専用のクライアントが一つ生成され、別のサーバーにもつなげばもう一つ生成されます。接続先ごとに専用の窓口を立てる構造のため、あるサーバーの不調が他の接続に波及しにくいという利点があります。なおMCPサーバーという呼び名は文脈データを提供するプログラム自体を指すもので、動作場所は問いません。手元のパソコンで動く場合もあれば、事業者が運用する遠隔のサーバーとして動く場合もあります。

MCPサーバーが提供する三つの機能

MCPで最も重要な概念とされているのがプリミティブです。クライアントとサーバーが互いに提供できる機能の型を定めたもので、サーバー側が公開できるプリミティブは三種類あります。

• ツール
  AIアプリケーションが呼び出して実際に何かを実行する関数。ファイル操作、API呼び出し、データベースへの問い合わせなどがこれにあたる
• リソース
  AIアプリケーションに文脈情報を与えるデータソース。ファイルの中身やデータベースのレコード、API応答などが該当する
• プロンプト
  モデルとのやり取りを構造化する、再利用可能なテンプレート

それぞれに一覧取得と実行のためのメソッドがあり、クライアントは接続後にまず一覧を取得してそのサーバーが何を提供しているかを把握します。一覧は動的に変わりうる設計のため、サーバー側の機能追加は接続先にそのまま反映されます。

通信の流れとトランスポートの選び方

MCPは、データ層とトランスポート層という二つの層で構成されています。データ層はJSON-RPC 2.0に基づく交換プロトコルを定義し、機能や版の確認、そしてツールやリソースといったプリミティブのやり取りを担います。トランスポート層は、実際の通信路と接続の確立、メッセージの区切り方、そして認可を担当します。

通信方式は二つあります。標準入出力を使うstdioトランスポートは、同じマシン上のプロセス同士が直接やり取りするもので、ネットワークを経由しないぶん高速です。もう一つのStreamable HTTPトランスポートは、クライアントからサーバーへのメッセージにHTTP POSTを使い、必要に応じてServer-Sent Eventsで応答を流します。遠隔のサーバーにはこちらを使い、認証はベアラートークンやAPIキー、カスタムヘッダーといった標準的なHTTPの方式に対応し、公式にはOAuthによるトークン取得が推奨されています。

なお現行の仕様リビジョン2026-07-28では、MCPはステートレスなプロトコルとして定義されています。すべてのリクエストがプロトコル版と必要な機能情報を自ら持つため、サーバーは過去のやり取りを覚えていなくても各リクエストを単独で処理できます。対応する版と機能はserver/discoverという要求で確認します。

MCPとAPIは何が違うのか

MCPを説明すると必ず出てくるのが、それはAPIと何が違うのかという疑問です。どちらもシステム同士をつなぐ仕組みである以上、当然の問いだと思います。結論から言えば、両者は置き換え合う関係ではなく、役割の異なる層として重なり合う関係にあります。

役割の違いを整理する

APIは、システムがシステムを呼び出すための取り決めです。呼び出す側は、あらかじめ仕様書を読み、どのエンドポイントにどんな形式で要求を送れば何が返ってくるかを理解したうえで、その手順を実装します。仕様は提供者ごとにばらばらで、認証方式もエラーの返し方も統一されていません。人間の開発者が個別に読み解くことを前提にした設計だからです。

一方MCPは、AIモデルが自分で使い方を理解できることを前提に設計されています。MCPサーバーは、自分が持つツールの名前、人間が読める表示名、何をするツールなのかの説明、そして入力パラメータを定義したJSON Schemaを、決まった形式で返します。AIはこの情報を読むだけで、そのツールをいつ使えばよいか、どんな値を渡せばよいかを判断できます。仕様書を読んでコードを書くという工程を挟まずに済むことが、APIとの最大の違いです。加えて、接続や認証、通知といった周辺の作法もすべて規格として統一されています。

実務での見え方も異なります。API連携では、どの機能を使うかを人が事前に決めて実装するため、想定した使い方の外へは出られません。MCPでは、AIが接続後にツールの一覧を取得し、その場の目的に合うものを自分で選んで呼び出します。同じ社内システムをつないでも、依頼の内容次第で使われる機能が変わるということです。この柔軟さは利点であると同時に、何が呼び出されうるかを提供側が把握しにくいという性質でもあり、後述する権限設計の重要性につながります。

両者の違いを観点ごとに整理すると、次のようになります。

観点	API	MCP
想定している利用者	仕様書を読む人間の開発者	接続先を自分で解釈するAIモデル
仕様の統一度	提供者ごとに個別。認証方式もエラーの返し方もばらばら	プロトコルとして統一。接続・認証・通知の作法も共通
使い方の把握	事前に仕様書を読んで実装する	接続後に一覧を取得し、説明とJSON Schemaから判断する
呼び出す機能の決定	実装時に人があらかじめ決める	依頼内容に応じてAIがその場で選ぶ
通信の方式	HTTPやgRPCなど提供者が選ぶ	stdioまたはStreamable HTTP（JSON-RPC 2.0）
相手との関係	MCPサーバーの内部から呼ばれる側になる	既存のAPIをAIが扱える形に翻訳する層になる

MCPとAPIは競合せず重なり合う

誤解されやすい点ですが、MCPはAPIを不要にするものではありません。多くのMCPサーバーは、内部で既存のAPIを呼び出しています。MCPサーバーは、既存のAPIをAIが理解できる形に翻訳して差し出す層として機能しているわけです。

この重なり方を理解すると、導入の判断がしやすくなります。すでに整備されたAPIを持っている企業であれば、それを捨てる必要はなく、その上にMCPサーバーという薄い層を一枚かぶせればよいということになります。実装済みの認証や権限制御、レート制限といった仕組みも、MCPサーバー側で適切に扱えばそのまま活かせます。逆に言えば、MCPサーバーを用意したからといって、元のAPIが持っていた制約や権限設計が自動的に安全になるわけではありません。あくまで接続の作法を統一する層であって、その下にある設計の良し悪しは変わらないという点は押さえておく必要があります。

MCPを導入するメリットと活用事例

ここまでの内容を踏まえて、MCPを導入することで実際に何が変わるのかを、事業上の効果と具体的な活用場面の両面から見ていきます。

開発と保守のコストを下げガバナンスを一元化できる

最も直接的な効果は、連携の実装量が掛け算から足し算に減ることによる開発コストの削減です。ただし企業のWEB担当者にとってより見過ごせないのは、保守と統制の面での効果でしょう。接続先ごとにばらばらの連携コードが散在している状態では、どのAIツールがどのデータに触れられるのかを把握することすら困難です。

MCPサーバーという単一の窓口に接続を集約すれば、どのデータをどこまで公開するかをその一箇所で決められます。認証や認可、アクセスログの取得も窓口側で統一して実装できます。社内規程で扱いを制限すべき情報があるなら、そもそもMCPサーバーの提供対象に含めないという判断を一度下せば、接続するすべてのAIツールに対してその方針が適用されます。連携が増えても管理対象が増えないという点は、統制の観点で大きな意味を持ちます。

開発ツールでの活用

MCPが最初に広く使われたのは開発現場でした。Visual Studio Codeはワークスペース直下の.vscode/mcp.jsonにサーバーを記述する方式で対応しており、公式ドキュメントの例ではGitHub向けのサーバーとしてhttps://api.githubcopilot.com/mcpというURLが示されています。サーバーを追加するとVS Codeがそのツールを検出してチャットから使えるようになり、どのツールを有効にするかは画面上で個別に切り替えられます。

# .vscode/mcp.json （ワークスペース直下に置く）
{
  "servers": {
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp"
    },
    "playwright": {
      "command": "npx",
      "args": ["-y", "@microsoft/mcp-server-playwright"]
    }
  }
}

この書き方は、公式ドキュメントにも同じ形で示されています。

Cursorをはじめとする他のAI搭載エディタも同様に対応しており、設計ファイルからコードを生成する、エラー監視サービスから障害情報を取得する、課題管理システムのチケットを読んで修正方針を立てるといった作業が、エディタから離れずに完結するようになります。

生成AIプラットフォームでの活用

主要な生成AIプラットフォームの多くが、MCPクライアントとしての機能を備えています。Claudeではコネクタとして遠隔のMCPサーバーを登録でき、ChatGPT、Microsoft Copilot、Geminiもそれぞれ対応しています。財団への移管を伝える発表でも、これらの主要クライアントで正式な対応が実現していることが挙げられていました。

企業側にとって意味があるのは、一度MCPサーバーを用意すればどのプラットフォームの利用者にも同じ機能を届けられる点です。従業員が使うAIがClaudeであれChatGPTであれGeminiであれ、社内システムへの接続口は一つで済みます。プラットフォームの選定と社内データの公開設計を、切り離して考えられるようになるということです。

業務ツールとの連携

業務系のSaaSでも、事業者自身が運用する遠隔MCPサーバーの提供が広がっています。SlackはSlack MCPサーバーを公開しており、公式ヘルプによれば、パートナーアプリを選んでインストールし、そのアプリをMCPサーバーに接続すると、ClaudeやChatGPTといったサードパーティのAIエージェントがワークスペース全体の検索、チャンネル履歴の取得、メッセージの送信、canvasの作成などを行えるようになります。AtlassianもRovo MCPサーバーを提供しており、JiraやConfluenceの情報を各種のAIツールから扱えます。同社はこのサーバーについて、利用者のコンテンツを保存もキャッシュもせず安全なプロキシとして動作すると説明しています。このほかNotion、Stripe、Sentry、Asana、HubSpotなども、接続先のURLを公開しています。

こうした事業者提供のサーバーが増えたことで、自社で開発しなくても連携を始められるようになりました。接続先のURLを登録しOAuthで認可を与えるだけで使い始められるため、まずは既製のサーバーで効果を確かめてから自社向けの開発に進むという段階的な進め方が可能です。

MCPを利用する際の注意点とセキュリティリスク

MCPは便利な反面、AIに実際の操作権限を渡す仕組みでもあります。公式の仕様書自体が、MCPは任意のデータアクセスとコード実行の経路を持つ強力な機能を可能にするものであり、それに伴う重要なセキュリティと信頼の考慮事項があると明記しています。導入を検討する際は、利便性と同じ熱量でリスクを見ておく必要があります。

第三者が公開するMCPサーバーに潜むリスク

最も注意すべきは、外部から入手したMCPサーバーを手元で動かす場合です。公式のセキュリティ指針では、ローカルMCPサーバーの侵害という項目でこの危険が具体的に説明されています。ローカルサーバーは利用者のマシン上でMCPクライアントと同じ権限で動く実行ファイルであり、悪意ある起動コマンドを設定に紛れ込ませる、サーバー本体に不正な処理を仕込むといった攻撃が成立しうるとされています。認証情報を外部に送信するコマンドが起動時に紛れ込んでいても、利用者からは見えません。

もう一つ見落とされやすいのが、ツールの説明文そのものが攻撃経路になりうるという点です。仕様書は、ツールの挙動に関する説明や注釈は、信頼できるサーバーから得たものでない限り信頼できないものとして扱うべきだと述べています。AIはツールの説明文を読んで使い方を判断するため、そこに指示のような文言が仕込まれていれば、AIの振る舞いを外部から操作される余地が生まれます。このほか公式指針では、混乱した代理人問題やトークンの素通し、状態ハンドルの乗っ取り、認可URLを悪用したコード実行など、複数の攻撃手法と対策が具体的に挙げられています。

安全に運用するためのポイント

まず徹底すべきは、提供元がはっきりしているサーバーだけを使うことです。事業者自身が公開している公式のサーバーと、出所の確認できない第三者製のサーバーとでは、負うリスクがまったく違います。ローカルで動かす場合は、起動コマンドの中身を実行前に必ず目で確認します。公式指針も、ワンクリックでローカルサーバーを設定できるクライアントは、実行されるコマンドを省略せずに表示し、明示的な承認を得なければならないとしています。

権限は最小限から始めるのが原則です。公式指針はスコープの最小化を項目として立てており、すべての権限をまとめて要求するような設計を避け、低リスクな読み取り操作から始めて必要になった時点で段階的に引き上げる方式を推奨しています。書き込みや削除を伴うツールについては、AIに自動実行させず、人の承認を挟む運用にしておくのが安全です。自社でMCPサーバーを公開する側に回る場合は、読み取り専用に限定する、公開ページの情報しか扱わないといった線引きを設計段階で決めておくと、事故の余地そのものを減らせます。

運用時に最低限そろえておきたい規律は次のとおりです。

• 提供元が明示された公式のサーバーだけを使い、出所の確認できない第三者製は避ける
• ローカルで動かすサーバーは、起動コマンドの中身を実行前に必ず目で確認する
• 権限は低リスクな読み取り操作から始め、必要になった時点で段階的に引き上げる
• 書き込みや削除を伴うツールは自動実行させず、人の承認を挟む
• 自社でサーバーを公開する場合は、扱う範囲を設計段階で読み取り専用や公開情報に限定する

MCPの使い方と今後の展望

最後に、実際に使い始めるための手順と、これから押さえておきたい動きを整理します。難しい準備は必要なく、多くのクライアントはコマンド一行、あるいは設定画面での登録だけで接続できます。

導入の基本的な流れ

手順は三段階で、難しい作業はありません。

1. 接続したいMCPサーバーを決める
2. 利用するクライアントに登録する
3. 接続状況と実際の動作を確認する

このうち手が止まりやすいのは2の登録で、クライアントごとに書き方が違うためです。よく使われる三つのコマンドラインツールについて、順に見ていきます。

Claude Codeで遠隔サーバーを追加する場合は、claude mcp add --transport http という形式で名前とURLを指定します。認証が必要なサーバーには --header でトークンを渡すか、対話中に /mcp と入力してブラウザ経由のOAuth認証を行います。設定の適用範囲はスコープで決まり、既定は実行したディレクトリ限定のlocal、どのプロジェクトからも使いたい場合は --scope user、チームで共有したい場合は --scope project を指定してプロジェクト直下の.mcp.jsonに記録します。

# 遠隔サーバーを user スコープで追加する
claude mcp add --transport http --scope user contencial https://mcp.contencial.co.jp/

# 認証が必要なサーバーはヘッダーでトークンを渡す
claude mcp add --transport http secure-api https://api.example.com/mcp \
  --header "Authorization: Bearer your-token"

# ローカルの stdio サーバーは -- で区切って起動コマンドを書く
claude mcp add my-server -- npx -y my-mcp-server

# project スコープで追加するとプロジェクト直下の .mcp.json に記録される
{
  "mcpServers": {
    "contencial": {
      "type": "http",
      "url": "https://mcp.contencial.co.jp/"
    }
  }
}

Codexでは codex mcp add にサーバー名を渡し、Streamable HTTPのサーバーなら --url でURLを指定します。ローカルで動くstdioのサーバーなら、– で区切ってから起動コマンドを書きます。設定は~/.codex/config.tomlに[mcp_servers.名前]という形式で保存され、直接編集もできます。登録済みのサーバーは codex mcp list で確認できます。

# コマンドで追加する（Streamable HTTP は --url、stdio は -- で区切る）
codex mcp add contencial --url https://mcp.contencial.co.jp/
codex mcp add my-server -- npx -y my-mcp-server

# ~/.codex/config.toml に直接書く場合
[mcp_servers.contencial]
url = "https://mcp.contencial.co.jp/"

[mcp_servers.my-server]
command = "npx"
args = ["-y", "my-mcp-server"]

Gemini CLIでは gemini mcp add に名前とコマンドまたはURLを渡します。通信方式は -t でstdio、sse、httpから選び、適用範囲は -s でuserかprojectを指定します。設定はsettings.jsonのmcpServersに記録され、遠隔サーバーへのOAuth 2.0認証にも対応しています。いずれのツールでも接続状況は /mcp で確認でき、スコープを指定しないと実行したディレクトリの中だけの設定になる点は共通の注意点です。

# コマンドで追加する（-t で通信方式、-s で適用範囲を指定）
gemini mcp add -t http -s user contencial https://mcp.contencial.co.jp/

# settings.json に直接書く場合（httpUrl は Streamable HTTP、command は stdio）
{
  "mcpServers": {
    "contencial": {
      "httpUrl": "https://mcp.contencial.co.jp/"
    },
    "my-server": {
      "command": "npx",
      "args": ["-y", "my-mcp-server"]
    }
  }
}

三つのクライアントの指定方法を並べると、違いは次のとおりです。書き方は違っても、やっていることはどれも「名前とURLを登録する」だけです。

項目	Claude Code	Codex	Gemini CLI
追加コマンド	claude mcp add	codex mcp add	gemini mcp add
遠隔サーバーの指定	–transport http のあとに名前とURL	–url にURL	-t http のあとに名前とURL
ローカルサーバーの指定	— で区切って起動コマンド	— で区切って起動コマンド	-t stdio のあとに起動コマンド
適用範囲の指定	–scope local / user / project	~/.codex/config.toml か .codex/config.toml	-s user / project
設定ファイル	~/.claude.json と .mcp.json	~/.codex/config.toml	settings.json
一覧の確認	claude mcp list または /mcp	codex mcp list または /mcp	/mcp

自社の情報をAIへ直接届けるという使い方

MCPは、外部の機能をAIに取り込むためだけの仕組みではありません。自社の情報を発信する側の手段としても使えます。私たちの運営元である株式会社コンテンシャルは、公開情報をAIから直接取得できるMCPサーバーをhttps://mcp.contencial.co.jp/で公開しています。仕様リビジョン2026-07-28に準拠し、Streamable HTTPで接続でき、認証は不要、読み取り専用という構成です。

提供しているのは、公式情報の横断検索、個別コンテンツの全文取得、テーマ別の見解調査、企業プロフィール、サービス一覧、新着一覧という六つの機能です。公開サイトと同じサーバー上で動きデータベースを直接参照しているため、記事を公開・更新すればその直後のリクエストから新しい内容が返ります。各結果には公式性の分類が付き、会社の公式方針と編集部の解説記事を混同させない設計です。根拠が見つからない場合は確認できないと返し、推測で見解を作らない方針も定めています。接続手順は https://seo.contencial.co.jp/mcp/ で公開しています。

生成AIが答えを組み立てるときに自社の情報が正しく使われる状態を目指す取り組みは、LLMO（Large Language Model Optimization、大規模言語モデル最適化）やGEO（Generative Engine Optimization、生成エンジン最適化）と呼ばれます。検索結果の順位を上げるのではなく、AIが自社を説明するときの精度そのものに手を入れる取り組みで、MCPサーバーの公開はその具体的な手段の一つです。

ただしこの経路が届くのは、MCPに対応したクライアントからの呼び出しに限られます。ツールを呼ばずにページを読むだけの相手には、別の手段を用意しておく必要があります。

ブラウザの中でツールを公開するCloudflareのWebMCP

これから注目しておきたいのが、CloudflareがWebMCPとして2026年8月6日に発表した仕組みです。WebMCPは、ページの中にdocument.modelContextとして現れる新しいブラウザ標準です。Chromeでは既定で有効になっているわけではなく、Chrome 149から始まったオリジントライアルとして、参加登録したサイトでのみ動く試験提供の段階にあります。従来、AIエージェントがWebサイトを扱うには人間向けの画面を読み解くか、内容をサーバーへ複製するクローラーに頼るしかありませんでした。WebMCPはサイト側が構造化されたツールとして機能を公開し、エージェントが画面の推測ではなく本来のタスクにリソースを使えるようにします。

Cloudflareの実装では、ダッシュボードのAgent Readinessからスイッチを入れるだけで導入でき、オリジン側への配置も変更も不要とされています。すべてのツールは訪問者のブラウザ内で完結し、サーバーへの往復が発生しません。前述のコンテンシャルのサイトもこの経路に対応しており、Chrome 149以降で同サイトを開いている間はクライアントを設定しなくても同じ六つのツールを呼び出せるとしています。ただしChromeの試験段階の機能を用いたもので有効期限は2026年11月17日までと明示されており、人がブラウザでページを開いているときにしか動作しません。標準機能として定着するかは今後の動向を見ていく必要があります。

なおこの経路をクローラーが通ることはないため、クローラー向けの情報提供は、これまでどおり公開ページそのものが担います。

A2Aなど関連プロトコルとの使い分け

MCPと並んで語られることが増えているのが、A2A（Agent2Agent）プロトコルです。もともとGoogleが開発し、その後Linux Foundationへ寄贈された標準で、現在はAWS、Cisco、Google、IBM Research、Microsoft、Salesforce、SAP、ServiceNowの代表者からなる技術運営委員会によって維持されています。

両者の関係は公式ドキュメントで明快に整理されています。MCPはエージェントとツールの間の通信のためのもので、A2Aはエージェントとエージェントの間の通信のためのものである、という切り分けです。そのうえで両者は競合せず高度に補完的であり、互いに連携して動作するよう設計されていると明記されています。当面の実務で必要になるのはMCPのほうですが、複数のAIエージェントを組み合わせる構想があるなら、A2Aという層の存在を知っておくと設計の見通しが立てやすくなります。なおMCP自体にも中核仕様の外側に拡張という枠組みがあり、非同期処理を扱うTasksや対話的なUIを表示するMCP Appsなどが、双方が対応した場合にのみ有効になる任意機能として定義されています。

MCPによってWEBサイトやSEOはなくなるのか

MCPが広がると、AIが必要なデータを直接取りに来るのだから、WEBサイトも検索も要らなくなるのではないか。そう受け取られることがあります。ここまで見てきた仕組みを踏まえると、その見方は正確ではありません。MCPと検索は置き換え合う関係ではなく、担う役割が分かれて併存する関係にあります。どこが分かれているのかを順に見ていきます。

MCPは見つけてもらうための経路ではない

MCPサーバーは、対応するクライアントに接続先として登録されてはじめて呼ばれます。利用者かその管理者がURLを登録するという明示的な操作が前提であり、検索エンジンのクローラーのように、誰かが探して回ってくれる仕組みではありません。

ブラウザの中で動くWebMCPにも同じ制約があります。Cloudflareの発表にあるとおりツールは訪問者のブラウザ内で完結して動くため、ページを開いている人がいなければ、そもそも呼び出されないからです。

したがって、まだ自社を知らない人に見つけてもらう経路としては、公開されたウェブページと、それを読む検索エンジンや生成AIが引き続き必要です。MCPサーバーを用意しても、それだけで新しい接点が生まれるわけではありません。この点を取り違えると、やるべきことの順番を間違えます。

知っている相手に正確に答えさせる経路としては強い

一方でMCPは、すでに自社を知っている相手に正確な情報を返す経路としては強く働きます。AIがウェブを検索して情報を拾い集めるのではなく、提供者側が用意したデータを直接取得するためです。

ここで効いてくるのは、何をどの粒度で返すかを提供者側が決められることです。どこまでを公式の見解として返し、根拠が見つからないときにどう答えるか。その線引きを、文章の書き方ではなくサーバーの設計として持てます。提供者がサーバーの方針を自分で決めて明示できるという点は、先に挙げた私たちの例のほか、Atlassianが自社のサーバーについて利用者のコンテンツを保存もキャッシュもしないと宣言していることにも共通します。いずれもLLMOやGEOが目指すものを、接続の設計として実装したものだと言えます。

WEB担当者が今から手をつけられること

やることは二つに分かれます。

一つは、公開ページ側を機械に読み取れる形に整えることです。構造化データで内容の種類を明示する、執筆者と出典をページ上ではっきり示すといった作業がこれにあたります。人にも検索エンジンにも生成AIにも同じように効くうえ、MCPサーバーを用意しなくても今日から始められます。

もう一つは、能動的に届ける経路を用意することです。自社のMCPサーバーの公開がこれにあたります。ただしこちらは、接続してもらってはじめて働く経路です。順序としては、公開ページ側を先に整え、そのうえでMCPサーバーを足す、と考えるのが無理がありません。どちらか一方に賭ける必要はない、というのがいまの実情です。

MCPは生成AIと外部システムをつなぐ新しい共通基盤である

ここまで見てきたとおり、MCPはAIアプリケーションと外部システムをつなぐための共通規格です。AIの賢さを高める技術ではなく、AIが外の世界と関わるための接続の作法を統一する技術であり、だからこそ特定の企業やモデルに依存しない標準として広がりました。Anthropicが2024年11月に公開した仕組みが、一年余りでLinux Foundation傘下の中立的な財団へ移管され、主要な生成AIプラットフォームが相次いで対応するに至った経緯は、この規格が業界共通の土台として受け入れられたことを示しています。

MCPの理解に必要な要点は、それほど多くありません。ホストとクライアントとサーバーという三つの役割があり、サーバーはツールとリソースとプロンプトという三種類の機能を提供し、通信は手元ならstdio、遠隔ならStreamable HTTPで行う。この骨格さえ押さえておけば、個別のツールの設定画面で迷うことはほとんどないはずです。

企業のWEB担当者にとって、MCPは二つの意味を持ちます。一つは、社内システムやSaaSをAIから使えるようにするための接続手段としての意味です。連携をMCPサーバーという一つの窓口に集約すれば、実装量が減るだけでなく、どのデータを誰にどこまで開くかという判断を一箇所で管理できるようになります。もう一つは、自社の情報をAIへ届けるための発信手段としての意味です。検索してサイトを訪れてもらう流れから、AIに尋ねてその場で答えを得る流れへの移行が進むなかで、AIが自社を正確に説明できる状態を保つことの重要性は増しています。先に触れた私たちの取り組みも、この認識から始めたものです。

一方で、MCPはAIに実際の操作権限を渡す仕組みでもあります。先に挙げた運用規律を欠いたまま導入を急げば、利便性と引き換えに深刻なリスクを抱え込むことになります。仕様書そのものがセキュリティ上の考慮事項を丁寧に列挙していることの意味は、便利さの裏側にある危うさを標準を作る側も認識しているという点にあります。導入を速く進めることよりも、どこまで開いてよいかを決める作業を先に終えることのほうが、結果として全体の歩みを左右します。

整理すると、見つけてもらう経路は引き続き公開ページと検索が担い、見つけたあとに正確に答えさせる経路をMCPが担います。どちらかに寄せるのではなく、両輪として考えるのが今のところ現実的です。そのうえで、まずは公式に提供されているMCPサーバーを一つ選び、手元のツールに登録して動きを確かめてみることをおすすめします。コマンド一行で始められる手軽さと、そこから見えてくる可能性の広さは、実際に触れてみて初めて実感できるものです。私たちSEO Note! Teamも、仕様の更新と各クライアントの対応状況を追いながら、実務に落とし込める情報を継続してお届けしていきます。

よくある質問

SEO Note! Team (SEO施策スタッフ)

SEOエンジニア、マーケター、ライター、編集担当からなる専門チームです。技術的なサイト最適化からコンテンツ戦略の立案、記事の執筆・編集まで、SEO施策を一気通貫で対応できる体制を整えています。10万パターン以上のキーワード対策と3万を超えるドメインの運用で培った実践的なノウハウをもとに、机上の理論だけでは得られない現場視点のSEO支援を提供しています。

執筆者