AIと外部サービスをつなぐ規格（MCP）とは？主要9企業・1プロジェクトと事業機会

Model Context Protocol（MCP）とは、AIと外部ツールをつなぐ共通規格

MCPはツールやデータへの接続方式です。業務を自動化する範囲と実行権限は別に設計します。

Model Context Protocolは、生成AIやAIエージェントが外部のデータや機能を使うための共通規格です。略してMCPと呼ばれます。

実際、AIエージェントの新規事業を考えるうえでも、外部システムとの接続は欠かせません。

たとえば、AIに「今月の売上を集計し、異常値があれば担当者へ知らせて」と頼む場面を考えます。その場合、AIは、会計システムから数字を取り、基準と比べ、通知ツールを動かす必要があります。

ところが従来は、使うAIと業務システムの組み合わせごとに接続を作っていました。

MCPの基本構成では、データや機能を提供するプログラムをMCPサーバーと呼びます。AIアプリはホストとなり、その内部のMCPクライアントが各サーバーへ接続します。

サーバーは実行機能（Tools）、参照情報（Resources）、再利用する指示のひな型（Prompts）などを公開します。

Anthropicは2024年11月、MCPをオープンな規格として公開しました。同社は、AIとデータソースの接続を個別開発から共通方式へ変えることを狙っています。

MCPが定めるのは、機能の発見や呼び出し、情報のやり取りを共通化する方法です。どのツールを選び、何を自動実行してよいかは、AIアプリと利用企業が設計します。

MCPに対応すれば、どのAIからも安全に使えるわけではありません。接続先、権限、確認、記録、停止方法は、導入する会社が別に設計します。

MCPとA2Aは、つなぐ相手が違う

MCPはツール・データとの接続、A2Aはエージェント同士の協働を担います。長い処理かどうかだけでは区別しません。

MCPと一緒に語られる規格が、Agent2Agent Protocolです。略してA2Aと呼ばれます。

ただし、二つは競合ではなく、役割が違います。

MCPは、AIエージェントと道具をつなぎます。道具には、社内データベース、顧客管理、決済、検索、ファイル、開発環境などが含まれます。

A2Aは、AIエージェント同士をつなぎます。営業エージェントが見積もりエージェントへ依頼し、その結果を法務エージェントが確認するような連携です。

Googleは2025年4月、A2Aを発表しました。同社はA2AをMCPを補う規格と説明しています。

実際、公式のA2A解説でも、MCPは道具との接続、A2Aはエージェント間の協働と整理されています。

実際の業務では、片方だけを選ぶとは限りません。たとえば、一つのエージェントがMCPで社内データを取り、A2Aで別の専門エージェントへ依頼する構成があります。

そのため、導入側は、どの境界で権限と責任が移るのかを見ます。

MCPが急速に広がった理由は、個別接続の負担を減らせるから

月間約5億回のSDK取得は普及の指標です。導入企業数や有償需要として売上計画へ置き換えません。

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月28日の仕様発表では、通信ごとの処理を独立させる方式、経路制御、認可の強化、拡張機能の仕組みを整えています。同発表の主要SDKのダウンロード数は月間約5億回です。

これは取得回数であり、開発者数、導入企業数、有償契約数とは分けて読みます。

SDKの取得回数や公開サーバー数は、対応するソフトウェアが広がっていることを示す指標です。顧客がいくら払うかは別に検証する必要があります。

事業計画では、対象企業数、管理する接続数、運用範囲、契約単価から売上を見積もります。

AIエージェントはMCPでどう外部システムを動かすのか

読む、下書きを作る、送信するという操作を分け、権限と承認を段階ごとに決めます。 MCPの仕組みは、依頼、ツールの選択、承認、実行、結果確認に分けると理解しやすくなります。

利用者が業務を依頼すると、AIアプリはMCPクライアントを通じて利用可能なツールを取得し、目的に合う機能と入力を選びます。必要な承認と権限確認を経てMCPサーバーが処理を実行し、結果をアプリへ返します。

外部の業務APIを呼ぶ場合は、そのAPI側でも対象データと操作権限を確認します。

重要なのは、AIがツールを選んだ後です。たとえば、顧客情報を読む操作と、請求を確定する操作では危険度が違います。

そのため、閲覧は自動化しても、送信、削除、支払いは人の承認を必須にする設計があります。RAGで情報を探す処理と、外部システムを書き換える処理も分けて考えます。

2026年7月版の認可仕様は、HTTPを使うMCP接続の認可を定め、OAuth 2.1の草案などを土台にしています。誰が接続しているかを確かめる認証と、何を許すかを決める認可は別です。

同じ仕様をローカルのstdio接続へそのまま当てはめず、実際の通信方式と利用権限を確認します。

つまり、導入の成果は「つながった数」では測れません。正しい相手だけが、必要な範囲だけを、確認可能な状態で使えることが成果です。

見積もり作成を例に、読む・下書き・送るを分ける

架空の見積もり作成業務を考えます。AIはMCP経由で商品価格と在庫を読み、見積書の下書きを作ります。

顧客への送信は別の権限にし、担当者が宛先、金額、値引き、納期を承認してから実行します。読み取りツールが使えることを、そのまま送信の許可にしない設計です。

テストには、権限のない顧客情報を求める依頼、在庫情報の更新遅れ、承認前の送信要求、送信直後の通信切断を含めます。正常に作れるかだけでなく、止めるべき操作を止め、処理済みかを照合してから再開できるかを確かめます。

AI連携市場は「標準」と「運用」に分かれる

共通規格の上に、接続、認証、評価、業界ごとの運用を組み合わせて事業を設計します。 MCPとA2Aの業界構造は、六つの層に分けられます。

第一層はモデルとAIアプリです。Claude、ChatGPT、Geminiなどが該当し、利用者の指示を受けてツールを選びます。

第二層は共通規格です。具体的には、MCPがツール接続、A2Aがエージェント間連携を担います。

なお、規格自体は開かれており、一社がすべてを囲い込む構造ではありません。

第三層はMCPサーバーとコネクターです。これは、業務サービスやデータを、AIから使える形に変えます。

そのため、GitHub、Salesforce、決済、顧客管理など、対象業務ごとに接続が増えます。

第四層はゲートウェイと認証です。ここでは、どのAIがどのツールを使えるかを管理し、利用量を制限し、記録を残します。

実際、AWS、Microsoft、Cloudflare、agentgatewayなどがこの領域へ入っています。

第五層はツール選択と実行環境です。ここでは、多数のツールから必要なものだけをAIへ見せます。

また、コード実行やブラウザ操作を隔離された環境で動かす機能も含まれます。

第六層は業界別の運用です。製造、金融、医療、公共などの仕事へ組み込みます。

ここでは、規格への対応より、権限表、評価データ、例外処理、監査が価値になります。コンテキスト・エンジニアリングで扱う指示や情報の設計も、この運用品質を左右します。

規格への対応だけでは、顧客固有の業務ルールは決まりません。後発企業は、接続する顧客や業務を絞り、権限、評価、障害対応まで提供できる領域を探すと、開発すべき機能を具体化できます。

主要9企業・1プロジェクトのMCP活用と提供状況

提供機能だけでなく、正式提供か試験提供か、誰が更新と保守を担うかを比べます。 次の表は主要9企業とagentgatewayという一つのオープンソースプロジェクトの比較です。

公開機能、提供形態、検討時の確認点を並べており、売上や導入効果によるランキングではありません。

この表で注目したいのは、価値の中心が接続本数だけではないことです。企業利用では、誰に何を見せるか、危険な操作を止められるか、障害時に追跡できるかが選定条件になります。

Anthropic・OpenAI・GoogleはAIの入口を押さえる

規格や対応製品の普及と、個社で得られた業務成果は別々に確認します。 モデルやAIアプリを提供する三社は、共通規格と開発基盤の整備を進めています。

Anthropicは接続方式を公開し、共通基盤へ移した

AnthropicはMCPの起点となった会社です。同社は、最初から仕様、開発キット、参考サーバーを公開し、Google Drive、Slack、GitHubなどへの接続例も示しました。

つまり、開発者がすぐに試せる状態を作ったのです。

2025年12月9日の寄贈発表で、Anthropicは公開MCPサーバー1万件超、Claudeのコネクター75件超と説明しました。いずれも発表時点の対応範囲です。

利用企業は、掲載の有無に加え、提供者、更新方針、権限、障害時の連絡先を確認します。

OpenAIはMCPをAIエージェントの標準部品として扱う

OpenAIは、Responses APIからリモートMCPサーバーを呼び出せるようにしました。AI開発者は、外部のMCPサーバーをツールとして指定できます。

同社はMCPの運営にも参加しています。このことは、モデル会社が接続先をすべて自前で作るのではなく、外部サービスが公開する共通接続を使う方向を示します。

導入側は、便利なサーバーがあるかだけでなく、どの外部事業者へ入力が渡るかを確認する必要があります。

GoogleはA2Aで複数エージェントの協働を狙う

Googleは、MCPと競う接続規格を作るのではなく、異なるエージェント同士の協働に焦点を当てました。A2Aの公開時には、50社を超える技術パートナーとサービス企業が参加しました。

Googleは採用業務を例に、候補者を探すエージェントと、面接調整などを担うエージェントの連携を示しました。これは使い方の説明で、特定企業の採用工数削減の実績ではありません。

2025年6月23日の発表では、A2Aの仕様や開発キットをLinux Foundationへ移し、中立的な運営のもとで普及させる方針を示しています。

Microsoft・AWS・GitHubは企業の管理点を押さえる

登録カタログ、接続先のネットワーク、下流APIの権限を分けて管理します。 企業内で接続を増やす際には、認証・権限と管理方法が選定条件になります。

Microsoftは社内用MCPサーバーをカタログで管理する

Microsoft Foundryの公式案内（2026年9月更新）は、Azure Functionsなどで作ったMCPサーバーをAzure API Centerの組織内カタログに登録し、Agent Serviceへ接続する手順を説明しています。カタログが非公開であることと、接続先のネットワークが非公開であることは別です。

この手順のFunctions例は公開エンドポイントを使い、プライベート接続は別構成として案内されています。

大企業では、各部門が自由に接続を増やすと、何が動いているか分からなくなります。Microsoftは、開発者が作る接続と、会社が管理する認証・登録・可視化を同じ基盤へ寄せています。

AWSは既存APIをMCPへ変換し、入口と出口を管理する

Amazon Bedrock AgentCore Gatewayは、既存の機能をMCP対応ツールとして見せます。その対象はAPI、AWS Lambda、各種サービスで、A2Aへの中継にも対応しています。

APIやLambda関数がある業務では、それらをMCPから使える形にする選択肢が増えます。ただし、APIがない業務の実装、入力の検証、業務上の承認、二重登録の防止まで自動で完成するわけではありません。

ゲートウェイで提供される機能と、自社で作る処理を分けて見積もります。

GitHubは開発作業をAIへ開く一方、組織の制御を加える

GitHubは、公式のリモートMCPサーバーを提供しています。具体的には、OAuth 2.1とPKCEを使い、利用者の権限でリポジトリや課題へ接続します。

また、企業向けには、組織全体でMCPの利用方針を管理する機能も用意しています。

読み取り専用でも、非公開コードや認証情報の漏洩に注意が必要です。更新や変更の反映では、情報へのアクセスに加えて変更権限と承認を管理します。

AIコーディングでも、接続できることと、変更を反映してよいことを分けて設計します。

Cloudflare・Salesforce・Composio・agentgatewayは運用の隙間を埋める

共通基盤を使っても、機能の提供段階、使用版、更新・障害対応は自社で確認します。 次の四つは、配信基盤、業務APIの管理、ツール検索、ゲートウェイという異なる役割を担います。

CloudflareはリモートMCPサーバーを配信と認証の近くへ置く

CloudflareのリモートMCP提供は、Workers上での実行とOAuthによる認可を組み合わせています。また、2026年7月のMCP公式発表に掲載された同社の説明では、Agents SDKが新しいステートレス方式へ対応しています。

通信のたびに処理できる方式は、サーバー台数を増減させる設計に役立ちます。一方、注文や作業途中の状態を業務側で保存する必要は残ります。

通信方式が変わることと、業務の状態管理が不要になることを分けて考えます。

Salesforceは顧客業務のAPIをAIから使う入口を作る

SalesforceのCLIによるMCPサーバー管理機能は、確認時点でDeveloper Preview（開発者向けの試験提供）です。API Catalogの登録や、公開するツールなどを管理するコマンドが説明されています。

これは対象コマンドの提供段階であり、SalesforceのMCP関連機能すべてが試験提供という意味ではありません。

同資料は、対象コマンドが一般提供前で、変更・廃止される可能性があり、それらで開発した機能を本番実装しないよう明記しています。検証環境で確認し、本番導入では利用する機能ごとの提供段階、契約、データ権限を確認します。

Composioは多数のツールを必要なときだけAIへ見せる

Composioの現行API資料は、従来Tool Routerと呼んでいた仕組みをSessionsとして説明しています。利用者ごとの接続アカウント、ツール範囲、認可、実行状態を管理し、ツールの検索と実行を行う構成です。

ツール数だけで一律に合否を決めるのではなく、必要な機能を見つけられるか、誤った機能を選ばないか、検索も含む応答時間を測ります。候補を絞りすぎて必要なツールが見えなくなる場合もあるため、実際の業務テストで表示範囲を調整します。

agentgatewayはMCPとA2Aを同じ管理面で扱う

agentgatewayは企業名ではなく、MCP・A2A・通常のHTTP通信などを扱うオープンソースプロジェクトです。認証、権限、経路制御、利用制限、ログや処理の追跡をまとめる機能を提供しています。

複数のエージェントやツールを共通管理する基盤の候補になります。ただし、自社運用のオープンソースを採用する場合は、導入・更新・監視・障害対応を誰が担うかを決めます。

MCPの仕様改定に対する対応状況も、使用する版ごとに確認します。

自社はMCPのどこへ入れるか

業界知識、管理基盤、運用ログ、企業間ネットワークから入口を確認します。

01　業界SaaSと顧客基盤がある

業界特化MCPの入口があります。

• 一つの業務を狭く定義できる
• 権限と承認のひな型を持てる
• 公式に保守するSaaS会社と組める

02　ID・API・SOCを運用している

管理ゲートウェイへ入れます。

• 接続先を登録・停止できる
• 読み取りと書き込みを分けられる
• 操作を既存の監査へつなげられる

03　AIの実行ログを持っている

ツール選択と評価へ入れます。

• 成功と失敗を判定できる
• 仕事ごとに見せるツールを絞れる
• 完了率と費用を同時に測れる

04　企業間の取引基盤がある

A2A業務運用へ入れます。

• 参加条件と本人確認を定められる
• 料金と成果物を管理できる
• 失敗時の引き継ぎ責任を持てる

MCPで考えられる4つの新規事業

事業の候補は、業界特化接続、管理ゲートウェイ、ツール評価、企業間運用の四つです。 MCPの事業機会は、サーバーを一本作ることだけではありません。

顧客の業務、権限、運用まで含めると、四つの入り方があります。

次の表は、最初の顧客、提供範囲、参入前に確かめる成果を並べています。自社が保守まで担える行から検討します。

どの参入方法でも、接続できた段階と顧客が継続利用する段階を分けます。導入後の例外対応と保守費まで含めて、提供価格が成立するかを確認します。

業界特化接続は、API変換より業務ルールが資産になる

金融、医療、製造、物流、公共では、同じ「検索」でも見せてよい範囲が違います。業界特化MCPパッケージは、既存APIをMCPに変えるだけでなく、役職、目的、操作、確認者をひな型にします。

顧客への提案では、接続コードの本数よりも、導入期間、設定ミス、現場の確認・修正時間がどれだけ減るかを示します。業界SaaSの提供者と、API変更時の対応や公式保守の範囲を決めておくと、継続提供の費用を見積もれます。

管理ゲートウェイは、接続が増えるほど必要になる

部門ごとにMCPサーバーを導入すると、認証方式と記録場所がばらばらになります。管理ゲートウェイは、接続先の登録、許可、利用量、停止を一か所にまとめます。

既存のAPI管理、ID管理、SOC運用を持つ企業には入りやすい領域です。新しい規格を売るより、顧客がすでに使う認証と監査へつなぐことが価値になります。

ツール選択と評価は、接続後の失敗データを資産にする

ツールが増えると、AIは似た名前の機能を選び間違えます。しかも、説明文が長くなり、AIへ渡す情報量も増えます。

そのため、仕事に必要な候補だけを見せ、実行後に成功を判定する基盤が必要です。

参入企業が持つべき資産は、MCPサーバーの本数ではなく、失敗した呼び出しを直す運用データです。どの指示で、どのツールを選び、何が不足したかを残します。

A2A業務運用は、会社をまたぐ責任を商品にする

A2Aで複数エージェントをつなぐと、発注、採用、旅行、物流など会社をまたぐ仕事を自動化できます。ただし、相手の能力を信じてよいか、料金はいつ確定するか、失敗時に誰が戻すかを決める必要があります。

この領域は技術だけでは成立しません。業界ネットワーク、契約、本人確認、決済、紛争対応を持つ企業に機会があります。

自社の参入方法は、持っている資産から逆算する

一つの業務から始め、接続数ではなく、業務完了と修正時間、総費用を測ります。 参入方法は、技術の新しさではなく、自社がすでに持つ資産から選びます。

業界SaaSと顧客基盤がある会社は、業界特化接続が候補です。顧客が毎日使う業務を一つ選び、読み取り、下書き、承認、実行のどこまでを任せるか決めます。

ID管理、ネットワーク、セキュリティ運用を持つ会社は、ゲートウェイが候補です。既存契約へ監査と制御を追加する案と、新たな製品を導入する案を比較し、顧客の管理負担と自社の保守費がどう変わるかを確かめます。

AIアプリや開発支援を持つ会社は、ツール選択と評価が候補です。顧客の実行ログを使い、完了率、誤操作、確認回数、1件当たり費用を改善します。

商社、業界団体、決済、物流など企業間の関係を持つ会社は、A2A業務運用が候補です。技術規格より、参加条件と責任分界を整える力が重要です。

最初に作るのは、全社向けの接続基盤ではありません。むしろ、一つの部署、一つの業務、一つの接続先へ絞り、読み取りだけから始めて成功と失敗を記録します。

そして、証拠が集まってから、書き込みや複数エージェントへ広げます。

通信成功率90％でも、無修正で完了した業務は70％という架空例

例えば1,000件の業務依頼でAPIを合計2,000回呼び、そのうち1,800回が成功しても、業務が完了した割合とは一致しません。依頼単位で確認した結果が次のようになったと仮定します。

数値は計算方法を示す架空例で、特定製品の導入実績ではありません。

通信成功率は1,800÷2,000＝90％、無修正の業務完了率は700÷1,000＝70％です。人が修正した分を含む完了率も90％になりますが、指標の意味と分母は異なります。

導入効果は、修正時間、承認の待ち時間、API・基盤の費用を含め、従来業務と同じ対象で比較します。

承認が必要な業務では、正しく承認を求めたことを失敗に数えません。「通常の承認」と「誤りの修正」を分け、成功の定義を先に決めます。

未完了の100件も分母に残し、原因と復旧時間を記録することが改善につながります。

MCP導入の懸念は、権限とツール説明に集まる

権限の逸脱、誤操作、途中停止を試し、止める・照合する・再開する手順を設けます。 一つ目の懸念は、権限の広げすぎです。

たとえば、AIへ顧客管理を使わせるために、全顧客の閲覧や更新を許すと、誤操作の影響が大きくなります。利用者の権限を引き継ぎ、業務に必要な操作だけを許します。

二つ目は、説明文や取得した情報に含まれる指示を信じすぎることです。接続先の情報に業務と無関係な操作を促す内容があっても、それを実行権限として扱いません。

許可する操作をあらかじめ絞り、サーバーの更新後も説明と実際の動作を試します。

三つ目は、アクセストークンの扱いです。MCPの認可仕様は、対象サーバー向けに発行された有効なトークンであることを確認するよう求めています。

MCP用と下流API用の認証情報を適切に分け、期限・権限を確認し、秘密情報をログへ残さないようにします。

四つ目は、不要なツールまで見せることです。類似機能の選択ミスを減らすため、部署と仕事ごとに候補を絞り、必要な機能の検索漏れも測ります。

五つ目は、処理途中の障害です。通信が切れても、業務システムへの登録だけは済んでいる場合があります。

再実行前に結果を照合し、同じ操作番号の依頼を二重登録しない仕組みを設けます。番号を付けるだけでなく、受け側で重複を防ぐことが必要です。

六つ目は、仕様変更です。実際、2026年仕様では通信方式や認証が変わりました。

そのため、古いクライアントやサーバーを放置せず、対応版、廃止日、更新責任を台帳にします。

七つ目は、成果を接続数や通信の成功回数だけで測ることです。請求先、金額、送信先が誤っていても通信自体は成功し得ます。

業務完了、手直し、事故、承認の待ち時間、一件当たり費用を分けて記録します。

導入前に責任分界と見送り条件を決める

機能の境界ごとに担当者を決め、障害の調査、停止、復旧の責任を契約で合わせます。 MCP導入では、AIアプリ会社、MCPサーバー提供会社、業務システム会社、利用企業の四者が関わります。

障害が起きたときに、どこまで調べ、誰が止め、誰が顧客へ説明するかを先に決めます。

責任分担の例として、AIアプリ側にはツール選択・承認画面・停止、MCPサーバー側には入力検証・権限・互換性、業務システム側には処理結果・重複防止・API変更通知を割り当てます。利用企業は対象業務と最終承認を決めます。

一社が複数を担う場合もあり、実際の担当、連絡先、復旧範囲は契約で確定させます。

次の条件に当てはまる場合は、本番導入を急がない方が安全です。

• 対象業務を一つに絞れない
• 読み取りと書き込みの権限を分けられない
• 実行前に確認すべき操作を決められない
• 失敗を判定できる担当者とテストデータがない
• 接続先の提供者、更新方針、停止方法が分からない
• 二重実行や途中停止から戻す方法がない
• 完了率、事故、費用を記録できない

MCPは個別接続の開発を減らします。一方、業務上の責任まで共通化するものではありません。

参入判断の中心は、MCPサーバーを作れるかではありません。接続後の失敗を見つけ、止め、直せるかです。

Model Context Protocolのよくある質問

接続の役割と、安全に導入するための基本条件を確認します。

Q. MCPとは何の略ですか？

A. Model Context Protocolの略です。生成AIやAIエージェントが、外部のデータ、ファイル、業務システム、各種ツールを共通の方法で使うための規格です。

Q. MCPサーバーとは何ですか？

A. AIから使える機能やデータを公開する側です。検索、取得、登録、計算などをツールとして示します。一般的なWebサーバーと同じ名前ですが、AI向けの接続方法を実装している点が違います。

Q. MCPとAPIは何が違いますか？

A. APIはシステム同士が機能を呼ぶ仕組みです。MCPは、そのAPIなどをAIが見つけて使いやすい形にそろえます。MCPサーバーの内側で既存APIを呼ぶ構成が多く、APIを不要にするものではありません。

Q. MCPとA2Aのどちらを導入すべきですか？

A. AIとツール・データをつなぐならMCP、異なるAIエージェント同士に仕事を分担させるならA2Aが中心です。複雑な業務では、両方を組み合わせます。

Q. MCPに対応すれば安全ですか？

A. 対応だけでは安全になりません。接続先の審査、最小権限、操作前の確認、認証情報の管理、監査ログ、停止と復旧を別に設計します。

Q. 日本企業はMCPへどう参入できますか？

A. 業界特化の接続、認証と監査を担うゲートウェイ、ツール選択と評価、企業間のA2A運用が候補です。自社が持つ業務知識、顧客基盤、ID管理、実行ログ、業界ネットワークから入口を選びます。

まとめ：MCPは接続を共通化し、競争を運用へ移す

MCP対応は出発点です。顧客の仕事を安全に完了し、運用費を含めて価値が残るかで判断します。

Model Context Protocolは、AIと外部ツール・データの接続を共通化します。A2Aは、そのAIエージェント同士の協働を支えます。

Anthropic、OpenAI、Googleに加え、多くの企業が対応しました。Microsoft、AWS、GitHub、Cloudflareなどです。

規格は一社の機能から共通インフラへ近づきました。競争は、接続できるかから、認証、権限、ツール選択、評価、監査をどう運用するかへ移っています。

新規参入では、業界特化MCP、管理ゲートウェイ、ツール選択・評価、A2A業務運用が候補です。自社に業務データ、顧客基盤、ID管理、実行ログ、業界ネットワークのどれがあるかを確認します。

MCPで共通化できる接続と、顧客固有の業務設計を分けることが大切です。まず一つの仕事で、人が直さず完了できた割合、例外対応、運用費を確かめ、その結果から対象業務と接続先を広げます。

参考文献

公式仕様と各社の公表情報を確認しています。提供状況は2026年9月28日時点です。

事業上の示唆と架空例は当研究所による整理です。

• Anthropic：MCP公開（2024年11月）
• Anthropic：AAIFへの寄贈と普及状況（2025年12月）
• MCP：2026年7月28日版の発表
• MCP：基本構成と通信方式
• MCP：HTTP接続の認可仕様
• MCP：セキュリティ上の注意点
• A2A Project：MCPとの役割の比較
• Google：A2A公開（2025年4月）
• Google：Linux FoundationへのA2A寄贈（2025年6月）
• OpenAI：Responses APIのリモートMCP対応（2025年5月）
• Linux Foundation：AAIF設立（2025年12月）
• Microsoft：MCPサーバーの構築・登録
• AWS：AgentCore Gateway
• GitHub：リモートMCPサーバーの一般提供（2025年9月）
• Cloudflare：リモートMCPの構築・配信
• Salesforce：CLI管理機能のDeveloper Preview
• Composio：Sessions（旧Tool Router）
• agentgateway：オープンソース基盤の機能