MCPの上位レイヤー——Anthropicが書いたわけではないエージェント標準に、11社が名を連ねた

誰も「戦い」だと宣言しなかった標準化戦争

この2日間で最も重大なAIのニュースは、モデルのローンチではありません。1つのJSONファイルです。

7月13日、The Informationは、Google、Microsoft、Salesforce、Snowflake、ServiceNowが、AIエージェントを業務ソフトウェアに接続するための共通技術標準を支持することで合意した、と報じました。アグリゲーターはこれを即座に、AnthropicのModel Context Protocol(MCP)に対する反撃だと位置づけました。(The Informationの記事はペイウォールの内側にあります。ここでの枠組みは二次的な報道に基づくものであり、私は元の記事そのものを読めていません。)ただし、問題の標準は実在し、公開されています。名前もあります——Agentic Resource Discovery、略してARDです。

ARDは今週になって突然現れたものではありません。2026年6月17日にv0.9のドラフトとして公開され、Apache 2.0でライセンスされ、エンジニアのJunjie BuとSrinivas KrishnanによってGoogle Developers Blogで発表されました。新しいのは、いまその背後に積み上がった政治的な重みのほうです。Search Engine Journalによれば、11の組織が名を連ねています——Google、Microsoft、GitHub、Hugging Face、Cisco、Databricks、GoDaddy、NVIDIA、Salesforce、ServiceNow、Snowflakeです。

そのリストを、「誰がいないか」という視点でもう一度読んでみてください。OpenAIの名前はありません。MCPを書いた当のAnthropicも、そこにはいません。

この仕様が実際にやっていること

技術的なアイデアそのものは狭く、そして正直に言えば、理にかなっています。

現在、エージェントは事前に誰かが組み込んでおいたツールしか使えません。MCPサーバーをインストールし、接続を設定すると、ツールの定義がモデルのコンテキストウィンドウに詰め込まれます。ツールが10個ならそれで動きます。1万個になると破綻します。カタログがプロンプトに収まらなくなるからです。

ARDの答えは、ツールの選択をコンテキストウィンドウの外に出し、検索サービスへ移すことです。仕組みは2つのプリミティブに支えられています。第一に、パブリッシャーが自ドメインのwell-knownなパスに、機械可読なマニフェスト——通常はai-catalog.json——をホストし、そのドメインが提供する能力を列挙します。第二に、レジストリがそれらのカタログをクロールしてインデックス化し、ランク付けされたライブな結果を返すREST のPOST /searchエンドポイントを公開します。エージェントは自分が達成しようとしていることを自然言語で記述し、レジストリがどのツールを呼ぶべきかを教えてくれる、という流れです。ドメイン所有権の検証は、そのツールが名乗っているとおりのものであることを担保するために置かれています。Googleの投稿は、この全体を、エージェントが現状では標準的な方法で答えられない3つの問いへの回答として位置づけています。「適切な能力はどこに存在するのか? 実際にどの能力を使うべきなのか? そして、それが接続して安全なものだとどう検証するのか?」

Hugging Faceのローンチ投稿は、この転換をもっと率直に表現しています。「手動でインストールする静的なカタログから、意図ベースの検索へ」。HFはすでにリファレンス実装を出荷済みで、数千のSkills、MLアプリケーション、MCPサーバーを検索インターフェース越しに公開するDiscover Toolを提供しています。

「反撃」という筋書きを複雑にする部分

ここで、その日の枠組みと、その日の文書とが食い違います。そしてこのギャップには、腰を据えて向き合う価値があります。

私が読んだ一次情報はどれも、ARDをMCPの上に載るレイヤーとして記述しており、置き換えとしては扱っていません。Googleの発表は、この仕様がプロトコル非依存であること、そしてMCPサーバーやA2Aエージェントはカタログ内に公開する能力タイプの一例であることを明示しています。発見(discovery)のあとは、エージェントはそのツールのネイティブなプロトコルで対話します。仕様はapplication/mcp-server-card+jsonというメディアタイプまで定義しており、その存在意義はまるごと、MCPサーバーをARD検索で見つけられるようにすることにあります。Hugging Faceは、ARDを3つのプロトコルからなるスタック——ツール呼び出しのMCP、指示のためのSkills、エージェント間通信のA2A——の上に載るものとして位置づけ、こう強調します。「これは製品でもマーケットプレイスでもありません。どの企業でも独立して実装できる共通標準です」。

Snowflakeの投稿が描く課題は、政治ではなく純然たる配管の話です。「今日、あるAIクライアント向けにMCP接続を設定しても、それだけで次のクライアントでそのエージェントが使えるようになるわけではありません」。彼らの主張は、データチームが出荷したエージェントが、Snowflake CoWork、Claude、Copilot、あるいは自社製アプリのいずれからも、そのつど登録し直すことなく発見可能になる、というものです。そのリストにClaudeが入っていることに注目してください。これはAnthropicを迂回するために設計された仕様ではありません。額面どおりに読めば、むしろAnthropicのプロトコルをより見つけやすくするものです。

では、どちらなのでしょう——待ち伏せなのか、それとも付属品なのか。

「補完的」と「戦略的」は対義語ではない

正直な答えは、両方の読みが同時に成り立ちうるということです。そして、その緊張関係こそが本題です。

MCPは呼び出し(invocation)レイヤーを制しました。The Informationの報道を伝える記事によれば、MCPはおよそ過去18か月で静かにデファクトになりました。しかもそれは、競合他社が保有する基盤の上で起きたことです。Microsoft、Google、Salesforceにとって、これは居心地の悪い立ち位置であり、Apache 2.0ライセンスをいくら重ねても居心地はよくなりません。発見(discovery)は、呼び出しの上にあるレイヤーです——エージェントがそもそもどのツールを検討対象にするかを決めるレイヤーです。レジストリを運営する者が、エージェントの見る世界を形づくります。検索エンジンが人間の見る世界を形づくってきたのと同じようにです。歴史的に、インデックスを所有することはパイプを所有することよりも価値がありました。

そして、署名した顔ぶれを見てください。Crypto Briefingが指摘するとおり、この連合は企業データが実際に置かれているシステムを運営しています——顧客はSalesforce、データはSnowflake、ワークフローはServiceNow、そこに二大クラウドが加わり、さらにNVIDIAとGitHubが並びます。彼らがai-catalog.jsonを公開し、OpenAIとAnthropicがそれに対応しなければ、モデル企業はソフトウェアの既存勢力が所有する発見グラフの「店子」になります。MCPに対しては補完的で、Anthropicに対しては戦略的に隣接している。その両方です。

陰謀論的な読みに水を差す要素がもう一つあります。基盤となるAI Catalogのデータモデルは、Linux Foundationのワーキンググループが管理しており、報道によれば、OpenAIとAnthropicはより広範なLinux Foundationのエージェント標準の取り組みにメンバーとして参加しています。これは、ほぼ全編が同じ部屋の中で戦われている争いなのです。

誇張と実体

実体があるもの:仕様は存在し、公開され、バージョン管理され、動くコードがあります。GitHubのCopilotエージェントファインダーは、MCPサービス横断の発見をサポートしていると報じられています。Hugging Faceのレジストリは稼働中です。実際の流通力を持つ11社が名前を出しています。

まだ実体がないもの:普及です。これはv0.9のドラフトです。その価値は、レジストリのエコシステムが実際に立ち上がるかどうかに完全に依存しており、Search Engine Journalは、そのエコシステムがまだ初期段階にとどまっていると述べています。クローラーもカタログもない発見標準は、インフラではなく単なるスキーマです。ウェブには、よく設計されたのに誰も公開しなかったマニフェストファイルの墓場が長く連なっています——Google自身のJohn Muellerは、LLMシステムはllms.txtのような機械可読ファイルを出しているサイトを実質的に見分けられない、と公に主張してきました。この種のアイデアについてGoogleの社員が述べた言葉としては、なかなか含みのあるものです。

同じく未確認なのは、ARDに関するAnthropicとOpenAIからの何らかの声明です。支持企業リストに彼らがいないことは事実です。しかし、その不在が何を意味するのか——拒絶なのか、無関心なのか、それともまだ進行中の対話なのか——は、情報源からは確定できません。そこを分かったふりをするつもりはありません。

まとめ

見出しの枠組みは疑ってかかり、その下にある動きには敬意を払うべきです。11社がMCPを潰すために結束した、という主張は、仕様そのものと突き合わせれば生き残りません。仕様はMCPサーバーを見つけやすくするために作られているからです。しかし、これは単なる技術的な利便性にすぎない、という主張もまた、参加企業の顔ぶれと突き合わせれば生き残りません。

注視すべきパターンは、ARDがMCPに「勝つ」かどうかではありません。エージェンティックAIにおけるレバレッジが実際に蓄積する場所として、発見(discovery)がそのレイヤーになるかどうかです。そしてもしそうなるなら、企業データの領地を所有する企業群が、ClaudeやChatGPTを含むあらゆるエージェントが道を探すために問い合わせざるを得ないインデックスまでも所有することになるのか、という点です。それはMCPの敗北ではありません。降格です——誰もが上に築く標準から、他社のカタログの中に収まる単なるペイロード形式へ、という降格です。

6か月後にもう一度、ai-catalog.jsonが世の中に何本存在するかを問うてみてください。今週のプレス報道ではなく、その数字こそが物語のすべてです。