投稿日:2026.09.09 最終更新日:2026.09.20
AIと外部サービスをつなぐ規格(MCP)とは?主要10社と事業機会
AIと外部ツールをつなぐ共通規格(MCP)に対応すれば、AI連携は完成するのか。
A2Aとの違いと、企業の参入余地はどこにあるのか。
結論は、接続後の権限・評価・監査を運用できるかです。主要10社と4つの参入方法から、MCPの現在地と事業機会を整理します。
この記事の結論
Model Context Protocolは、AIと外部ツールの接続を共通化する規格です。
- A2Aは異なるエージェント同士の協働を支え、MCPを補います。
- 主要企業の競争は、接続から認証、権限、監査、ツール選択へ広がっています。
- 参入余地は、業界特化接続、管理ゲートウェイ、評価、企業間運用にあります。
目次
Model Context Protocol(MCP)とは、AIと外部ツールをつなぐ共通規格
Model Context Protocolは、生成AIやAIエージェントが外部のデータや機能を使うための共通規格です。略してMCPと呼ばれます。AIエージェントの新規事業を考えるうえでも、外部システムとの接続は欠かせません。
たとえば、AIに「今月の売上を集計し、異常値があれば担当者へ知らせて」と頼む場面を考えます。AIは、会計システムから数字を取り、基準と比べ、通知ツールを動かす必要があります。従来は、使うAIと業務システムの組み合わせごとに接続を作っていました。
MCPでは、データや機能を提供する側をMCPサーバー、利用するAIアプリ側をMCPクライアントとして分けます。サーバーは「何ができるか」「どの入力が必要か」を決まった形式で示します。クライアントは、その一覧を読み、必要な機能を呼び出します。
Anthropicは2024年11月、MCPをオープンな規格として公開しました。同社は、AIとデータソースの接続を個別開発から共通方式へ変えることを狙っています。
ただし、MCPはAIそのものではありません。良い回答を考えるモデルでも、業務を自動化する完成品でもありません。AIと外部システムの間にある接続方法です。
MCPに対応すれば、どのAIからも安全に使えるわけではありません。接続先、権限、確認、記録、停止方法は、導入する会社が別に設計します。
MCPとA2Aは、つなぐ相手が違う
MCPと一緒に語られる規格が、Agent2Agent Protocolです。略してA2Aと呼ばれます。二つは競合ではなく、役割が違います。
MCPは、AIエージェントと道具をつなぎます。道具には、社内データベース、顧客管理、決済、検索、ファイル、開発環境などが含まれます。
A2Aは、AIエージェント同士をつなぎます。営業エージェントが見積もりエージェントへ依頼し、その結果を法務エージェントが確認するような連携です。
| 比較項目 | MCP | A2A |
|---|---|---|
| 主な役割 | AIとツール・データを接続する | 異なるAIエージェント同士を接続する |
| 相手の見せ方 | ツール、情報資源、指示を公開する | 能力、作業、成果物、進行状況を公開する |
| 得意な場面 | CRM検索、ファイル取得、API実行 | 複数会社・複数製品をまたぐ仕事の分担 |
| 作業時間 | 短い呼び出しを中心に扱う | 長時間の仕事や途中経過も扱う |
| 導入時の論点 | 権限、入力、出力、ツール実行の確認 | 相手の発見、委任範囲、成果物、失敗時の引き継ぎ |
| 関係 | A2Aエージェントの内側で道具を使う | MCPで道具を使うエージェント同士を連携できる |
Googleは2025年4月、A2Aを発表しました。同社はA2AをMCPを補う規格と説明しています。公式のA2A解説でも、MCPは道具との接続、A2Aはエージェント間の協働と整理されています。

実際の業務では、片方だけを選ぶとは限りません。一つのエージェントがMCPで社内データを取り、A2Aで別の専門エージェントへ依頼する構成があります。導入側は、どの境界で権限と責任が移るのかを見ます。
MCPが急速に広がった理由は、個別接続の負担を減らせるから
AIエージェントは、会話だけでは仕事を完了できません。最新情報を読み、業務システムへ書き込み、結果を確認する必要があります。接続先が増えるほど、個別の開発と保守が重くなります。
MCPが広がった第一の理由は、この組み合わせ問題を小さくできることです。ツール提供会社が一度MCPサーバーを用意すれば、複数の対応AIから使える可能性が生まれます。AIアプリ側も、接続方式をそろえやすくなります。
第二の理由は、大手AI・クラウド企業が対応したことです。OpenAIは2025年5月、Responses APIでリモートMCPサーバーへの対応を発表しました。Google、Microsoft、AWSも開発基盤へMCPを組み込みました。CloudflareとGitHubも対応しています。
第三の理由は、中立的な運営へ移ったことです。2025年12月、AnthropicはMCPを寄贈しました。寄贈先は、Linux Foundation傘下のAgentic AI Foundationです。Linux Foundationは、三つのプロジェクトを基盤に運営を始めました。Anthropic、Block、OpenAIが提供したものです。
2026年7月のMCP仕様では、サーバーを増やしやすい方式が加わりました。経路制御に使う情報、認証の強化、拡張機能の枠組みも整えています。公式発表によると、主要SDKは月間で約5億回ダウンロードされる規模です。これは売上ではなく、開発者による利用の広がりを示す数字です。

MCP市場の金額だけを示す調査には注意が必要です。AIエージェント市場、連携ソフト市場、API管理市場を同じものとして扱う資料があるためです。事業計画では、MCP全体の予測額へ頼らない方が安全です。対象顧客数、接続数、管理対象のツール数、月間呼び出し数から売上を積み上げます。
AIエージェントはMCPでどう外部システムを動かすのか
MCPの流れは、五つに分けると理解しやすくなります。
最初に、利用者がAIへ仕事を頼みます。次に、AIアプリが接続済みのMCPサーバーから、使えるツールの一覧を受け取ります。AIは目的に合うツールと入力を選びます。その後、必要に応じて利用者の確認を取り、MCPサーバーが業務システムを実行します。最後に、結果をAIが読み、利用者へ返します。

重要なのは、AIがツールを選んだ後です。顧客情報を読む操作と、請求を確定する操作では危険度が違います。閲覧は自動化しても、送信、削除、支払いは人の承認を必須にする設計があります。RAGで情報を探す処理と、外部システムを書き換える処理も分けて考えます。
認証も、MCPが自動で解決するわけではありません。MCPの認可仕様はOAuth 2.1を土台にしています。アクセストークンは対象となるMCPサーバー向けであることを確認し、別の接続先へそのまま渡さないことを求めています。
つまり、導入の成果は「つながった数」では測れません。正しい相手だけが、必要な範囲だけを、確認可能な状態で使えることが成果です。
AI連携市場は「標準」と「運用」に分かれる
MCPとA2Aの業界構造は、六つの層に分けられます。
第一層はモデルとAIアプリです。Claude、ChatGPT、Geminiなどが該当します。利用者の指示を受けてツールを選びます。
第二層は共通規格です。MCPがツール接続、A2Aがエージェント間連携を担います。規格自体は開かれており、一社がすべてを囲い込む構造ではありません。
第三層はMCPサーバーとコネクターです。業務サービスやデータを、AIから使える形に変えます。GitHub、Salesforce、決済、顧客管理など、対象業務ごとに接続が増えます。
第四層はゲートウェイと認証です。どのAIがどのツールを使えるかを管理し、利用量を制限し、記録を残します。AWS、Microsoft、Cloudflare、agentgatewayなどがこの領域へ入っています。
第五層はツール選択と実行環境です。多数のツールから必要なものだけをAIへ見せます。コード実行やブラウザ操作を隔離された環境で動かす機能も含まれます。
第六層は業界別の運用です。製造、金融、医療、公共などの仕事へ組み込みます。ここでは、規格への対応より、権限表、評価データ、例外処理、監査が価値になります。コンテキスト・エンジニアリングで扱う指示や情報の設計も、この運用品質を左右します。

後発企業が共通規格そのものを作って支配するのは難しくなっています。一方、顧客の業務とデータを知り、接続後の安全な運用を作れる会社には余地があります。
主要10社は、MCPサーバーより管理と運用へ広げている
主要企業の取り組みを見ると、単にMCPへ対応する段階から、認証、管理、選択、監視へ競争が移っています。
| 企業・団体 | 主な取り組み | 狙う位置 | 導入側が確認する点 |
|---|---|---|---|
| Anthropic | MCPの公開、Claudeのコネクター | 規格とAIアプリ | 接続先の信頼性、確認画面 |
| OpenAI | Responses API、Agents SDKのMCP対応 | モデルと開発基盤 | 承認設定、外部サーバーの扱い |
| A2A、AI Agent開発基盤 | エージェント間連携 | MCPとの役割分担、長時間作業 | |
| Microsoft | FoundryのMCP接続、社内カタログ | 企業向け統合管理 | 登録、認証、可視化、利用制限 |
| AWS | AgentCore Gateway | MCP・A2Aゲートウェイ | 入口と出口の認証、API変換 |
| GitHub | 公式リモートMCPサーバー | 開発業務の接続 | OAuth、組織の利用方針、操作範囲 |
| Cloudflare | WorkersでのリモートMCP運用 | 配信、認証、実行基盤 | ステートレス運用、OAuth、監視 |
| Salesforce | Agentforce向けMCPサーバー管理 | 顧客業務とAPIカタログ | 試験提供の範囲、権限とデータ境界 |
| Composio | 必要なツールを動的に選ぶTool Router | 接続とツール選択 | 表示ツール数、認証、失敗時の処理 |
| agentgateway | MCP・A2A対応のオープンなゲートウェイ | 経路制御とセキュリティ | OIDC、mTLS、監査、運用責任 |
この表で注目したいのは、価値の中心が接続本数だけではないことです。企業利用では、誰に何を見せるか、危険な操作を止められるか、障害時に追跡できるかが選定条件になります。
Anthropic・OpenAI・GoogleはAIの入口を押さえる
Anthropicは接続方式を公開し、共通基盤へ移した
AnthropicはMCPの起点となった会社です。最初から仕様、開発キット、参考サーバーを公開しました。Google Drive、Slack、GitHubなどへの接続例も示しました。開発者がすぐに試せる状態を作ったのです。
2025年12月には、MCPをLinux Foundation傘下へ寄贈しました。同社の発表時点で、公開MCPサーバーは1万件を超え、Claudeのコネクターは75件を超えていました。自社だけの仕様にせず、ほかのAI製品でも採用される共通基盤にしたことが大きな戦い方です。
OpenAIはMCPをAIエージェントの標準部品として扱う
OpenAIは、Responses APIからリモートMCPサーバーを呼び出せるようにしました。AI開発者は、外部のMCPサーバーをツールとして指定できます。
同社はMCPの運営にも参加しています。これは、モデル会社が接続先をすべて自前で作るのではなく、外部サービスが公開する共通接続を使う方向を示します。導入側は、便利なサーバーがあるかだけでなく、どの外部事業者へ入力が渡るかを確認する必要があります。
GoogleはA2Aで複数エージェントの協働を狙う
Googleは、MCPと競う接続規格を作るのではなく、異なるエージェント同士の協働に焦点を当てました。A2Aの公開時には、50社を超える技術パートナーとサービス企業が参加しました。
たとえば採用業務では、採用担当エージェントが候補者検索エージェントへ依頼し、面接調整エージェントが日程を整えます。それぞれの内側ではMCPで人事システムやカレンダーを使えます。2025年6月、GoogleはA2AをLinux Foundationへ寄贈しました。規格を広げるには、中立性が重要だと判断した動きです。
Microsoft・AWS・GitHubは企業の管理点を押さえる
Microsoftは社内用MCPサーバーをカタログで管理する
Microsoft Foundryでは、Azure Functionsなどで作ったリモートMCPサーバーを登録できます。組織向けには、Azure API Centerを使った社内カタログの考え方を示しています。
大企業では、各部門が自由に接続を増やすと、何が動いているか分からなくなります。Microsoftは、開発者が作る接続と、会社が管理する認証・登録・可視化を同じ基盤へ寄せています。
AWSは既存APIをMCPへ変換し、入口と出口を管理する
Amazon Bedrock AgentCore Gatewayは、既存の機能をMCP対応ツールとして見せます。対象はAPI、AWS Lambda、各種サービスです。A2Aへの中継にも対応しています。
導入企業は、既存システムをすべて作り直す必要がありません。ゲートウェイで形式を変え、入口と出口の認証を管理できます。AWSは、接続規格より、その前後にある企業向けの運用基盤を商品にしています。
GitHubは開発作業をAIへ開く一方、組織の制御を加える
GitHubは、公式のリモートMCPサーバーを提供しています。OAuth 2.1とPKCEを使い、利用者の権限でリポジトリや課題へ接続します。企業向けには、組織全体でMCPの利用方針を管理する機能も用意しています。
コードを読むだけなら影響は限られますが、課題の更新、ブランチ作成、変更の反映では危険度が上がります。AIコーディングでも、生成後のレビューと反映権限が重要です。GitHubの例は、ツールごとに権限と承認を分ける必要性を示しています。
Cloudflare・Salesforce・Composio・agentgatewayは運用の隙間を埋める
CloudflareはリモートMCPサーバーを配信と認証の近くへ置く
Cloudflareは、Workers上でリモートMCPサーバーを構築できます。OAuthによる認証を付ける方法も提供しています。2026年仕様のステートレス方式にも対応しました。
遠隔から多くの利用者が使うサーバーでは、接続を保ち続ける仕組みが運用負担になります。ステートレス化により、一般的なWebサービスに近い方法で増減させやすくなりました。Cloudflareは、規格対応を配信、認証、監視と結び付けています。
Salesforceは顧客業務のAPIをAIから使う入口を作る
Salesforceは、MCPサーバーの管理機能を試験提供しています。対象はSalesforce、Heroku、MuleSoftなどです。Agentforceの開発環境から扱い、社内のAPIカタログから接続候補を探せます。
CRMには、顧客、商談、契約など重要な情報があります。AIに広く見せると利便性は上がりますが、部門や役職による権限を崩せません。正式導入では、試験提供の範囲、データ境界、書き込み権限を確認します。
Composioは多数のツールを必要なときだけAIへ見せる
Composioは、Tool Routerで必要なツールをその場で選ぶ仕組みを提供しています。AIへ常に多数のツールを見せると、入力が長くなり、選び間違いも増えます。
同社の文書では、事前に読み込むツールが25件を超える場合に注意を促しています。接続数が増えるほど価値が出るのではなく、仕事ごとに見せる範囲を狭くすることが重要です。
agentgatewayはMCPとA2Aを同じ管理面で扱う
agentgatewayは、MCPとA2Aに対応するオープンソースのゲートウェイです。OIDC、mTLS、経路制御、利用制限、可視化などを提供します。
特定のAIやクラウドに閉じず、複数のエージェントとツールを共通に管理したい会社が対象です。この領域では、規格への追従だけでなく、障害対応、監査ログ、既存の認証基盤との統合が収益になります。
自社はMCPのどこへ入れるか
業界知識、管理基盤、運用ログ、企業間ネットワークから入口を確認します。
NEXT STEP
次のステップ
AI連携を、現場で管理できる事業へ。
対象業務、接続先、権限、承認、監査、復旧、提携先を整理し、自社の参入余地を設計します。
MCPで考えられる4つの新規事業
MCPの事業機会は、サーバーを一本作ることだけではありません。顧客の業務、権限、運用まで含めると、四つの入り方があります。

| 参入方法 | 最初の顧客 | 提供する価値 | 必要な資産・提携先 | 最初に確かめる証拠 |
|---|---|---|---|---|
| 業界特化MCPパッケージ | 業界固有のSaaSや基幹システムを持つ会社 | 用語、権限、手順を含む接続を短く導入する | 業務知識、顧客データ、SaaS会社、専門家 | 一つの業務で接続時間と手戻りが減るか |
| MCP管理ゲートウェイ | 複数部門でAIを使う企業 | 認証、利用制限、監査、停止をまとめる | ID基盤、API管理、セキュリティ運用 | 無許可接続を止め、操作を追跡できるか |
| ツール選択・評価基盤 | 多数の接続を持つAIサービス | 必要なツールだけを見せ、成功率と費用を管理する | 実行ログ、評価データ、モデル会社 | 完了率を保ち、誤実行と入力長を減らせるか |
| A2A業務運用基盤 | 複数会社・複数エージェントをつなぐ事業者 | 依頼、進行、成果物、引き継ぎを共通化する | 業界ネットワーク、契約、本人確認、決済 | 相手が失敗したときも仕事を回収できるか |
業界特化接続は、API変換より業務ルールが資産になる
金融、医療、製造、物流、公共では、同じ「検索」でも見せてよい範囲が違います。業界特化MCPパッケージは、既存APIをMCPに変えるだけでなく、役職、目的、操作、確認者をひな型にします。
顧客はコードの本数ではなく、安全に使い始めるまでの時間へ支払います。業界SaaS会社と組み、公式に保守できる関係を作れると強くなります。
管理ゲートウェイは、接続が増えるほど必要になる
部門ごとにMCPサーバーを導入すると、認証方式と記録場所がばらばらになります。管理ゲートウェイは、接続先の登録、許可、利用量、停止を一か所にまとめます。
既存のAPI管理、ID管理、SOC運用を持つ企業には入りやすい領域です。新しい規格を売るより、顧客がすでに使う認証と監査へつなぐことが価値になります。
ツール選択と評価は、接続後の失敗データを資産にする
ツールが増えると、AIは似た名前の機能を選び間違えます。説明文が長くなり、AIへ渡す情報量も増えます。仕事に必要な候補だけを見せ、実行後に成功を判定する基盤が必要です。
参入企業が持つべき資産は、MCPサーバーの本数ではなく、失敗した呼び出しを直す運用データです。どの指示で、どのツールを選び、何が不足したかを残します。
A2A業務運用は、会社をまたぐ責任を商品にする
A2Aで複数エージェントをつなぐと、発注、採用、旅行、物流など会社をまたぐ仕事を自動化できます。ただし、相手の能力を信じてよいか、料金はいつ確定するか、失敗時に誰が戻すかを決める必要があります。
この領域は技術だけでは成立しません。業界ネットワーク、契約、本人確認、決済、紛争対応を持つ企業に機会があります。
自社の参入方法は、持っている資産から逆算する
参入方法は、技術の新しさではなく、自社がすでに持つ資産から選びます。
業界SaaSと顧客基盤がある会社は、業界特化接続が候補です。顧客が毎日使う業務を一つ選び、読み取り、下書き、承認、実行のどこまでを任せるか決めます。
ID管理、ネットワーク、セキュリティ運用を持つ会社は、ゲートウェイが候補です。新しいMCP製品を別に売るより、既存契約へ監査と制御を追加する方が導入されやすくなります。
AIアプリや開発支援を持つ会社は、ツール選択と評価が候補です。顧客の実行ログを使い、完了率、誤操作、確認回数、1件当たり費用を改善します。
商社、業界団体、決済、物流など企業間の関係を持つ会社は、A2A業務運用が候補です。技術規格より、参加条件と責任分界を整える力が重要です。
最初に作るのは、全社向けの接続基盤ではありません。一つの部署、一つの業務、一つの接続先へ絞ります。読み取りだけから始め、成功と失敗を記録します。証拠が集まってから、書き込みや複数エージェントへ広げます。
MCP導入の懸念は、権限とツール説明に集まる
一つ目の懸念は、権限の広げすぎです。AIへ顧客管理を使わせるために、全顧客の閲覧や更新を許すと、誤操作の影響が大きくなります。利用者の権限を引き継ぎ、業務に必要な操作だけを許します。
二つ目は、ツールの説明文を信じすぎることです。AIは、ツール名と説明から使い方を判断します。悪意のある説明や、更新で変わった説明が、意図しない操作を誘う可能性があります。接続先を審査し、説明と実際の動作を別に試します。
三つ目は、アクセストークンの扱いです。あるMCPサーバー向けの認証情報を、別のサービスへそのまま渡してはいけません。対象、期限、権限を確認し、秘密情報をログへ残さない設計が必要です。
四つ目は、ツールが多すぎることです。候補が増えるほど、AIが選び間違えやすくなります。部署と仕事ごとに、表示するツールを絞ります。
五つ目は、障害の連鎖です。AI、MCPサーバー、業務システムのどこかが止まると、仕事が途中で残ります。再実行すると二重請求や二重登録になる操作もあります。操作番号を付け、同じ依頼を二度実行しない仕組みを持ちます。
六つ目は、仕様変更です。2026年仕様では通信方式や認証が変わりました。古いクライアントやサーバーを放置せず、対応版、廃止日、更新責任を台帳にします。
七つ目は、成果を接続数で測ることです。サーバーを増やしても、業務時間が減らなければ価値は出ません。業務完了率、手戻り、承認回数、事故、1件当たり費用を見ます。
導入前に責任分界と見送り条件を決める
MCP導入では、AIアプリ会社、MCPサーバー提供会社、業務システム会社、利用企業の四者が関わります。障害が起きたときに、どこまで調べ、誰が止め、誰が顧客へ説明するかを先に決めます。

AIアプリ会社は、ツール選択、確認画面、誤り時の停止を担当します。MCPサーバー提供会社は、入力の検証、権限、結果、版の互換性を担当します。業務システム会社は、APIの正しさ、重複防止、変更通知を担当します。利用企業は、利用者の権限、対象業務、最終判断、監査を担当します。
次の条件に当てはまる場合は、本番導入を急がない方が安全です。
- 対象業務を一つに絞れない
- 読み取りと書き込みの権限を分けられない
- 実行前に確認すべき操作を決められない
- 失敗を判定できる担当者とテストデータがない
- 接続先の提供者、更新方針、停止方法が分からない
- 二重実行や途中停止から戻す方法がない
- 完了率、事故、費用を記録できない
MCPは個別接続の開発を減らします。一方、業務上の責任まで共通化するものではありません。参入判断の中心は、MCPサーバーを作れるかではありません。接続後の失敗を見つけ、止め、直せるかです。
Model Context Protocolのよくある質問
まとめ:MCPは接続を共通化し、競争を運用へ移す
Model Context Protocolは、AIと外部ツール・データの接続を共通化します。A2Aは、そのAIエージェント同士の協働を支えます。
Anthropic、OpenAI、Googleに加え、多くの企業が対応しました。Microsoft、AWS、GitHub、Cloudflareなどです。規格は一社の機能から共通インフラへ近づきました。競争は、接続できるかから、認証、権限、ツール選択、評価、監査をどう運用するかへ移っています。
新規参入では、業界特化MCP、管理ゲートウェイ、ツール選択・評価、A2A業務運用が候補です。自社に業務データ、顧客基盤、ID管理、実行ログ、業界ネットワークのどれがあるかを確認します。
標準化されるのは通信方法です。顧客固有の仕事、責任、失敗への対応は残ります。そこを設計し、運用データで改善できる会社に、長く残る事業機会があります。
参考文献
- Anthropic「Introducing the Model Context Protocol」
- Model Context Protocol「The 2026-07-28 Specification」
- Model Context Protocol「Authorization」
- OpenAI「New tools and features in the Responses API」
- Google「Announcing the Agent2Agent Protocol」
- Linux Foundation「Agentic AI Foundation」
- Microsoft Foundry「Build and register an MCP server」
- AWS「Amazon Bedrock AgentCore Gateway」
- GitHub「Remote GitHub MCP Server is now generally available」
- Cloudflare「Build and deploy Remote MCP servers」
- Salesforce「Manage MCP Servers」
- Composio「Introducing Tool Router」
- agentgateway「Standalone documentation」
CONTACT
お問い合わせ
MCP対応を、運用で選ばれる事業へ。
接続、権限、評価、監査、例外処理、責任分界を一つの事業構造にし、参入・提携・待機・見送りを判断します。