7月10日、Search Engine Journalが「The Agentic Web Is Splitting Into Two Bets: Identity And Capability」と題した記事を公開した。Cloudflareのデータによれば、2026年6月時点で自動トラフィックが初めて人間のトラフィックを上回り、57.3% 対 42.7%という逆転が起きている。この事実を前提にすると、「AIにサイトの素性を伝えるファイルを置く」だけの戦略が十分かどうか、根本から問い直す必要が出てくる。記事が示す答えは明快だ——エージェントがウェブサイトに到着したとき、知りたいことは「ここはどんな場所か（アイデンティティ）」と「このタスクをどう完了させるか（ケイパビリティ）」の2つであり、それぞれに別の賭けが存在する。
核心：「パンフレット」と「レジ」の違い
- アイデンティティの賭け：
llms.txt——ドメインのルートに置くマークダウンファイル。自分が何者で、どんなコンテンツを持つかをモデルに伝える。 - ケイパビリティの賭け：
WebMCP——エージェントがサイト上で実際に「何かをする」ための、ブラウザ標準のAPI。
記事ではこの対比を明快に言い切っている。「アイデンティティはパンフレット。ケイパビリティはレジだ」と。パンフレットは読まれるのを待つ。レジは鳴る。Cloudflareの逆転データが示すとおり、リクエストの過半数がエージェントになった今、「このサイトが何者か」より「このタスクを完了できるか」が勝負を決めるフェーズに入っている。
llms.txt：採用は進んでいるが、機能しているかは不明
llms.txtは2024年9月3日、Answer.AIの共同創業者Jeremy Howardが提案したファイルだ。HTMLのノイズ（広告、ナビゲーション、スクリプト）を排除し、言語モデルに整理されたコンテンツの索引を渡す意図で設計された。
問題は証拠が薄いことだ。2026年6月のRedditへの回答で、GoogleのJohn Muellerは「現時点では純粋に投機的（このファイルは数年前から存在しているが、AIシステムのどれも使っていない）」と発言している（Search Engine Journal報道）。
にもかかわらず、採用は爆発的に広がっている。300万以上のWordPressサイトで使われているプラグインAIOSEOが、デフォルトでllms.txtを生成するからだ。サイトオーナーの多くは、自分でも読んだことのないファイルを公開している。Ahrefsのデータによれば、llms.txtファイルの97%はリクエストをまったく受けていない。
「ファイルを書いたのはプラグイン。どのAIも読んでいない。内容はサイトの実態と乖離していく」——これが現状の多くのウェブサイトの姿だ。
著者は、もし主要なAIシステムがllms.txtを正式に読むと発表すれば計算は変わると認めており、そのシグナルを注視しているとしながらも、まだそのような動きは見ていないと述べている。
WebMCP：エージェントが「実際に仕事をする」ための標準
WebMCP（Web Model Context Protocol）は、navigator.modelContext APIを通じてウェブサイトが呼び出し可能なツールをエージェントに公開できるブラウザ標準だ。GoogleとMicrosoftのエンジニアがW3C Web Machine Learning Community Groupを通じて策定し、2026年2月10日にドラフトが公開された。
現在、Chrome 149〜156でオリジントライアルが実施中だ（Chromiumメーリングリスト）。オリジントライアルとは、実験的機能を開発者フラグではなくトークン登録によって実際のユーザーに提供する仕組みで、本番トラフィックで今すぐ試せる。現時点でこれらのツールを消費するエージェントはChrome上のGeminiだ。
エージェントはページをスクリーンショットしてクリック先を推測する代わりに、サイトが宣言したツールを呼び出す。「検索」「在庫確認」「価格照会」「予約開始」——これらをHTMLのリバースエンジニアリングなしに実行できる。アイデンティティだけでは、エージェントは看板を読んで開かないドアの前に立つだけだ。WebMCPはそのドアを開く仕組みにあたる。
実装例：著者自身のサイトでの対比
記事の著者は自分のサイト「No Hacks」で両方を実装しており、そのコスト差が論点を如実に示している。
llms.txt：サイト更新のたびに自分のコンテンツから自動生成。プラグインに任せず、ドリフト（内容の乖離）を防ぐ。「ヘッジとして保持しているが、戦略とは思っていない」。
WebMCP：navigator.modelContextを通じて4つのツールを登録している。
- 用語集の全項目一覧を返すツール
- 特定用語の定義とソースリンクを返すツール
- 追跡中のエージェント製品の一覧をカテゴリ別に返すツール
- 製品名で単一製品の詳細を返すツール
重要な点は、各ツールが人間向けページと同じデータソースを参照していることだ。エージェントへの回答と人間への表示が食い違う可能性がなく、別途コピーを維持するコストも生じない。この実装が示すのは、WebMCPの導入が必ずしも大規模な追加開発を意味しないということだ。既存のデータ層をエージェントに向けて「宣言」する形をとれば、二重管理のコストをかけずに対応できる。
未解決の問題
WebMCPにも不確実性はある。現状はW3C Community Groupのドラフトであり、W3C勧告として批准された標準ではない。W3CにおけるCommunity Group段階のドラフトが正式勧告（Recommendation）になるには、Working Groupへの移管、複数の実装による相互運用性の証明、広範なレビュープロセスを経る必要があり、数年単位の時間軸になることも珍しくない。
ブラウザ対応の観点では、MicrosoftはWebMCPを共同起草しているが、Edge 147時点でのネイティブ対応は確認されていない。SafariやFirefoxの動向も現時点では明らかになっていない。現在ツールを消費するエージェントはChrome上のGeminiのみであり、エコシステムとしてはまだ黎明期にある。
llms.txtについても、主要なAIシステムが正式に読み始めるというシグナルが出れば、アイデンティティ側の賭けの価値は大きく変わる。著者はそのシグナルをまだ確認していないと述べているが、状況は流動的だ。
今すぐ確認すること
- ブラウザで
yourdomain.com/llms.txtを開く。何かが表示されたら、プラグインが勝手に書いた可能性が高い。内容を読み、自分のサイトを正確に描写しているか確認する。不正確なファイルは存在しないより悪い。 - WebMCPが必要かを判断する。エージェントがサイト上で何か「する」（検索、価格確認、予約）理由があるなら、オリジントライアルで本番環境に導入できる。コンテンツを読まれるだけのサイトであれば、まずクリーンなサーバーレンダリングに注力する方が先だ。
詳細はThe Agentic Web Is Splitting Into Two Bets: Identity And Capabilityを参照していただきたい。
