はじめに ― もう一つの「意味の分節化」
第1回・第2回では、コンピュータビジョンにおけるセマンティックセグメンテーション、つまり「画像を意味ごとにピクセル単位で分ける」技術を解説してきました。Google Meetの背景ぼかしからMetaのSAM 3まで、AIが物理世界を「見る」ための進化をたどりました。
第3回では、視点を大きく転換します。
実は、Web上でもまったく同じ構造の問題が起きています。AIエージェントがWebサイトを「見て」「理解して」「操作する」ためには、Webページの要素を「意味で分節」する必要があるのです。
画像のピクセルを「人」「背景」「空」に分けるのと、Webページの要素を「ナビゲーション」「メインコンテンツ」「問い合わせフォーム」に分けるのは、本質的に同じ営みです。どちらも「機械が世界を意味で理解できるようにする」ための構造化です。
本稿では、このWeb版「セマンティックセグメンテーション」を3つのレイヤーに分けて解説します。セマンティックHTML、llms.txt、そして2026年2月に発表されたばかりのWebMCPです。
レイヤー1：セマンティックHTML ― 25年前のWeb標準が復権した理由
<div>の海に沈んだ「意味」
Webの歴史を少し振り返ります。
HTML（HyperText Markup Language）は、もともと文書の意味構造を記述するための言語でした。<h1>は「大見出し」、<p>は「段落」、<nav>は「ナビゲーション」、<article>は「記事本文」。これらのタグは、ページのどの部分がどんな役割を持つかを、人間にも機械にも伝えるものです。
ところが、2010年代にReactやAngularなどのJavaScriptフレームワークが主流になると、状況が変わりました。多くのWebサイトが、意味を持たない<div>タグと<span>タグの入れ子で構築されるようになったのです。見た目はCSSで整えられるので、ブラウザで開けばきれいに表示される。しかし、HTMLのソースコードを見ても、どこがナビゲーションで、どこがメインコンテンツなのか、機械には判別できない。
さらに深刻な問題があります。多くのモダンWebサイトは、初期HTMLが空の<div id="root"></div>だけで、JavaScriptが実行されて初めてコンテンツが表示される、いわゆるSPA（Single Page Application）構造です。人間がブラウザで見る分には問題ありませんが、AIクローラーの多くはJavaScriptを実行しません。つまり、これらのサイトはAIから見ると「白紙のページ」なのです。
なぜ今、セマンティックHTMLが急に重要になったのか
セマンティックHTMLの重要性自体は目新しい話ではありません。しかし2025年から2026年にかけて、その重要性が質的に変わりました。理由は明確です。Webを「読む」主体が、人間からAIに広がったからです。
ChatGPT、Gemini、Claude、Perplexityなどのaiサービスは、それぞれ専用のクローラー（GPTBot、Google-Extended、ClaudeBot、PerplexityBot等）を使ってWebコンテンツを取得し、ユーザーの質問に対する回答の情報源として活用しています。あなたのWebサイトのコンテンツが、AIの回答に引用されるかどうか ―― いわゆるGEO（Generative Engine Optimization）における可視性は、サイトのHTMLがどれだけ「意味的に構造化」されているかに大きく左右されます。
Web SEOの専門家であるBarry Adams氏は、セマンティックHTMLがSEOとAIの両方に重要な理由を解説する中で、こう指摘しています：<div>の入れ子構造ではAIエージェントがページの目的を誤認する可能性が高いが、<nav>や<main>、<article>などのセマンティック要素を使えば、エージェントが「どこに行くべきか、何をすべきか」を正しく理解できる、と。
さらに注目すべきデータがあります。2026年時点で、Googleの検索クエリの約60%がゼロクリック検索 ―― つまりユーザーが検索結果のリンクをクリックせずに、AI Overviewなどで直接回答を得るケースになっています。AIが内容を読めないサイトは、文字通り「存在しないサイト」になりつつあるのです。
実務的な対応：スクリーンリーダーテストがAIテストになる
興味深いことに、セマンティックHTMLへの対応品質を確認するもっとも実用的な方法は、スクリーンリーダーのテストです。macOSのVoiceOverやWindowsのNVDAでサイトを操作してみて、意味のある情報が伝わるなら、AIエージェントにも同様に伝わる可能性が高い。
2025年10月、OpenAIがChatGPT内蔵ブラウザ「Atlas」を発表した際、サイトオーナーにARIA属性の追加を推奨しました。これに対し、Webアクセシビリティの専門家Adrian Roselli氏は「OpenAI, ARIA, and SEO: Making the Web Worse」と題した記事で鋭い批判を展開しました。Roselli氏の主張の核心は、ARIAはあくまでセマンティックHTMLのフォールバック（補助手段）であり、先にセマンティックHTMLを正しく使うべきだということです。HTMLの構造が不適切な状態でARIA属性を上から被せると、かえってアクセシビリティを損ねる危険がある。さらに、SEO業者がARIAをキーワード詰め込みに悪用する危険性も指摘しています。
アクセシビリティ対応が、そのままAIエージェント対応になる。これは、「人間のための配慮」と「機械のための設計」が一致する稀有なケースです。
レイヤー2：llms.txt ― Webサイトを「AI向けに要約する」ファイル
robots.txtのAI版
2つ目のレイヤーは、llms.txtです。
Webサイトのルートディレクトリに設置するテキストファイルで、fast.ai共同創設者でありAnswer.AIの創設者でもあるJeremy Howard氏が2024年9月に提案しました。既存のrobots.txt（検索エンジンにクロールの許可・不許可を伝える）やsitemap.xml（サイト構造を伝える）に似た概念ですが、LLM（大規模言語モデル）に最適化されたサイト概要をMarkdown形式で提供するものです。
llmstxt.orgの仕様説明によると、llms.txtは「サイトの全ページを網羅するもの」ではなく、もっとも価値のある、AIに理解してほしいコンテンツを厳選して提示するためのものです。XMLサイトマップがすべてのURLを列挙するのに対し、llms.txtは「うちのサイトで一番重要なのはこれです」とAIに伝えるキュレーションの役割を果たします。
率直な現状評価
llms.txtに対しては、率直に現状を伝える必要があります。
2025年8月、AdobeのSEO/GEOストラテジストFlavio Longato氏が1,000のAdobe Experience Managerドメインの30日間のCDNログを分析した結果、主要なAIクローラー（GPTBot、ClaudeBot、PerplexityBot等）からllms.txtファイルへのアクセスはゼロでした。アクセスしていたのはGooglebotやBingbotといった従来の検索エンジンクローラーのみです。
興味深いのは、Anthropic自身は自社のAPIドキュメントサイトにllms.txtを設置しており、エンジニアリングブログでもツール開発時にllms.txtを活用することを推奨しているという点です。つまりllms.txtを「情報発信側」としては積極的に活用しつつも、ClaudeBotが他サイトのllms.txtを参照しているという証拠はまだ確認されていない、という状況です。OpenAI、Googleについても同様で、2026年3月現在、llms.txtの公式クローラーサポートを表明したプロバイダーはありません。
とはいえ、llms.txtの設置コストは非常に低いものです。Markdownファイル1つを作成してルートディレクトリに置くだけ。Anthropicが自社サイトに設置しているという事実自体が、将来的な標準化への期待を裏付けるものです。いくつかのCMSプラットフォーム（WordPressのWebsite LLMsプラグイン等）では、サイトのコンテンツからllms.txtを自動生成する機能もすでに提供されています。
レイヤー3：WebMCP ― Webサイトが「AIの手」になる
「ピクセルを推測する」から「ツールを呼び出す」へ
3つ目のレイヤーは、本連載でもっとも注目すべき技術です。
2026年2月10日、GoogleのChrome開発チームがWebMCP（Web Model Context Protocol）のアーリープレビューを発表しました。MicrosoftのエンジニアとGoogleのエンジニアが共同で仕様を策定し、W3CのWeb Machine Learning Community Groupで標準化が進められています。
WebMCPを理解するには、まず現在のAIエージェントがWebサイトをどう扱っているかを知る必要があります。
現在のブラウザベースのAIエージェント（ChatGPT Atlas、Perplexity Comet、Claude in Chrome等）は、Webサイトを操作するとき、画面のスクリーンショットを撮影してビジョンモデルで解析したり、HTMLのDOMを解析して「このボタンをクリックすれば購入できるはず」と推測しています。しかし、サイトのデザインが少し変わっただけで操作に失敗したり、JavaScriptの動的UIをうまく処理できなかったりと、この方法は本質的に不安定です。
WebMCPは、この問題を根本から解決します。Webサイト側が「うちのサイトではこういう操作ができます」というツール契約（Tool Contract）をAIエージェントに直接伝える仕組みです。WebMCPの本質は、エージェントが「ピクセルを推測する」代わりに「ツールを呼び出す」ことにあります。
2つのAPI ― 宣言的と命令的
WebMCPは、2種類のAPIを提供します。
宣言的API（Declarative API）は、既存のHTMLフォームに属性を追加するだけでAIエージェントから呼び出し可能にするものです。すでに構造化されたフォームを持つWebサイトであれば、ツール名と説明を追加するだけで対応できます。VentureBeatの報道では「HTMLフォームがすでにきれいに構造化されていれば、80%は完了している」と表現されています。
命令的API（Imperative API）は、JavaScriptのnavigator.modelContext.registerTool()メソッドを使って、より複雑な操作をツールとして登録するものです。たとえばsearchProducts(query, filters)やbookFlight(origin, destination, date)のような関数を、パラメータのスキーマ定義付きでAIエージェントに公開できます。
重要なのは、WebMCPがブラウザ内で完結する設計であることです。AnthropicのMCPがバックエンドのサーバーサイドプロトコルであるのに対し、WebMCPはフロントエンドのブラウザ内で動作します。両者は競合ではなく補完関係にあります。たとえば旅行会社は、バックエンドではMCPサーバーを通じてChatGPTやClaudeと連携し、フロントエンドではWebMCPを通じてブラウザベースのAIエージェントと連携する、というアーキテクチャが考えられます。
Schema.orgとの対比で理解する
WebMCPの本質を一文で言い表すなら、こうなります：
Schema.orgが「このページは何であるか」を伝えるなら、WebMCPは「このページは何ができるか」を伝える。
2011年にGoogle、Bing、Yahoo!が共同でSchema.orgを立ち上げ（同年11月にYandexも参加）、Webページは自分が「レシピ」なのか「商品」なのか「イベント」なのかを構造化データで機械に伝えられるようになりました。これがリッチスニペットやナレッジグラフの基盤になった。
WebMCPは、その次のステップです。ページが何であるかだけでなく、ページ上でどんなアクションが実行可能かを構造的に伝える。検索からアクション（行動）へ。これは、Webの歴史における構造的な転換点です。
現状と展望
WebMCPは現在、Chrome 146のCanaryチャネルで「WebMCP for testing」フラグの裏側に実装されています。仕様はまだ初期ドラフトの段階で、セキュリティ（プロンプトインジェクション、ツールチェーンを通じたデータ流出等）や、複数のAIエージェントが同じページを同時操作する場合の競合制御など、未解決の課題も多く残っています。
なお、Bright Dataが2025年8月にリリースした同名の製品「The Web MCP」（サーバーサイドのスクレイピングプロキシ）とは別物です。ここで取り上げているWebMCPは、GoogleとMicrosoftが共同策定しW3Cで標準化が進むブラウザネイティブのプロトコルです。
GoogleとMicrosoftの両ブラウザベンダーが共同で仕様を策定しているという事実は、この技術が「実験的なアイデア」に留まらない可能性を強く示唆しています。業界関係者の多くは、2026年後半のGoogle Cloud NextやGoogle I/Oで、より広範なロールアウトが発表されると予想しています。
現時点での実務的なアドバイスとしては、WebMCPの本格実装を待つのではなく、その基盤となるHTMLフォームの構造化、安定したUXフロー、クリーンなサイト構造を先に整備しておくことです。これらはWebMCPの有無にかかわらず、SEO・アクセシビリティ・ユーザー体験のすべてに効く普遍的な改善です。
三層構造の全体像 ― AIエージェント対応サイトの設計
ここまで見てきた3つのレイヤーを整理すると、Webサイトの「AIエージェント対応」には明確な構造があることが分かります。
セマンティックHTML = AIが「読める」ようにする
Webページの要素を意味的に構造化し、AIクローラーやエージェントがコンテンツの構造と意味を正しく理解できるようにする。もっとも基礎的なレイヤーであり、コストも低い。しかし多くのWebサイトで、ここがすでに崩れている。
llms.txt = AIに「概要を伝える」
サイト全体の中から、AIに特に理解してほしいコンテンツを厳選し、Markdown形式で提供する。現時点でのAIクローラー対応状況は限定的だが、設置コストが極めて低いためリスクヘッジとして有効。
WebMCP = AIが「操作できる」ようにする
サイト上で実行可能なアクションを構造化されたツールとしてAIエージェントに公開する。もっとも先進的なレイヤーであり、現在はアーリープレビュー段階。しかし、GoogleとMicrosoftの共同策定という事実が、将来のWeb標準化を強く示唆している。
この三層が揃って初めて、Webサイトは「人間のためのインターフェース」と「機械のためのサービスレイヤー」の二重構造を持つことになります。これはまさに、NxCodeが指摘する「Web 2.0が人間の認知のために構築されたなら、Web 4.0は機械の認知のために構築される」という構造的変化です。
そして、ここに大きな補助線があります。この変化は、第1回・第2回で解説したコンピュータビジョンのセマンティックセグメンテーションと本質的に同じことをしているのです。画像のピクセルを意味で分類する。Webページの要素を意味で構造化する。どちらも「機械が世界を理解できるようにする」ための意味の分節化です。
まとめ ― Webの「セマンティックセグメンテーション」が始まった
AIエージェント時代のWebは、人間のための視覚的なインターフェースであると同時に、機械のための意味的なサービスレイヤーになっていきます。
セマンティックHTMLで構造を伝え、llms.txtで概要を伝え、WebMCPでアクションを伝える。この三層構造は、WebMCPの成熟とともに今後数年で急速に普及していくでしょう。GoogleとMicrosoftが共同で仕様を策定し、W3Cで標準化が進行しているという事実は、この方向性が一過性のトレンドではなくWebの構造的進化であることを示しています。
Web制作者やEC事業者にとって、今もっとも確実で効果的なアクションは以下の3つです：
- セマンティックHTMLの見直し。
<div>の海になっているページを、<nav>,<main>,<article>,<section>で適切に構造化する。スクリーンリーダーでテストする。 - サーバーサイドレンダリングの確保。 SPAであっても、初期HTMLにコンテンツが含まれる状態を担保する。AIクローラーはJavaScriptを実行しない。
- HTMLフォームの構造化。 ラベル、入力フィールド、バリデーションを明確に設計する。これがWebMCP対応の直接的な土台になる。
次回の最終回（第4回）では、コンピュータビジョン領域のセマンティックセグメンテーション（第1-2回）とWeb領域のセマンティック構造化（今回）が合流する未来像を描きます。ECサイトの商品画像をAIが解析し、WebMCP経由で購入を実行する。アクセシビリティ対応がそのままAIエージェント対応になる。物理世界とデジタル世界の「意味」がAPIで繋がる。そうした交差点と、unTypeが考えるこれからのWeb制作の姿をお伝えします。
参考情報
Chrome for Developers「WebMCP is available for early preview」（2026年2月10日）
VentureBeat「Google Chrome ships WebMCP in early preview」（2026年2月）
Search Engine Land「WebMCP explained: Inside Chrome 146's agent-ready web preview」（2026年3月）
MarkTechPost「Google AI Introduces the WebMCP」（2026年2月14日）
Bug0「WebMCP just landed in Chrome 146」（2026年2月）
Barry Adams「Why Semantic HTML matters for SEO and AI」（2025年8月）
Adrian Roselli「OpenAI, ARIA, and SEO: Making the Web Worse」（2025年10月）
No Hacks Podcast「How AI Agents See Your Website」（2026年2月）
DEV Community「Semantic HTML in 2025」（2025年5月）
Flavio Longato「LLMs.txt - Why Almost Every AI Crawler Ignores it」（2025年8月）
llmstxt.org「The /llms.txt file」
Search Engine Land「Meet llms.txt, a proposed standard for AI website content crawling」（2025年7月）
Anthropic「Writing tools for agents」
NxCode「The Agentic Web Explained」（2026年2月）
Wikipedia「Model Context Protocol」
Wikipedia「Schema.org」
この記事は「AIエージェント時代の『セマンティックセグメンテーション』」シリーズの第3回です。
WebサイトのAIエージェント対応診断、セマンティックHTML改善、構造化データの実装について、具体的なご相談はunTypeまでお気軽にお問い合わせください。
この記事をシェアする
