Works
Blog Recruit Contact 無料でAI診断する
エージェンティックWeb 2026.03.23

エージェンティックWebの完全スタック — MCP・WebMCP・NLWeb・llms.txtの統合戦略

MCP、WebMCP、NLWeb、llms.txt、Schema.org。乱立するプロトコルを5層スタックとして統合し、不動産サイトの具体的シナリオで「発見→対話→実行」の全フローを図解。段階的導入ロードマップも提示します。

エージェンティックWebの完全スタック — MCP・WebMCP・NLWeb・llms.txtの統合戦略

はじめに

2つの連載を書き上げました。

WebMCP:Webサイトがアクションを話す時代」(全5回)では、GoogleとMicrosoftが共同で策定するブラウザネイティブプロトコルを通じて、Webサイトの「操作」をAIエージェントに公開する方法を解説しました。

NLWeb:Webサイトと会話する時代」(全5回)では、MicrosoftのR.V. Guhaが構想したオープンプロジェクトを通じて、Webサイトの「コンテンツ」に自然言語で問い合わせ可能にする方法を解説しました。

本記事は、この2つのシリーズと、弊社のllms.txt記事、そしてMCP/A2Aプロトコルを統合し、エージェンティックWebの完全スタックを一枚の地図として描きます。

なぜ「統合」が必要なのか

2026年3月時点で、AIエージェントとWebサイトの間のインタラクションに関わるプロトコルや仕組みが、複数のベンダーから相次いで発表されています。MCP、WebMCP、NLWeb、A2A、llms.txt——それぞれの役割は異なりますが、個別に見ているだけでは全体像が見えません。

Ivan Turkovicの分析が明快です。MCPがバックエンド、NLWebがコンテンツクエリ、WebMCPがフロントエンド、A2Aがエージェント間通信を担い、これらが集合的にエージェンティックWebの動作方法を定義するプロトコルスタックを形成している、と。

MicrosoftのKyle Pflug(Edge担当グループプロダクトマネージャー)はThe New Stackのインタビューで、WebMCPとNLWebの関係について次のように述べています。「どのような会話体験を実現したいかによって、一方を選ぶか、もう一方を選ぶか、あるいは両方を使うこともできる。NLWebは会話インターフェースとMCPサーバー機能を含むフルスタックフレームワーク。WebMCPは、ブラウジングコンテキスト内でWebサイトがJavaScriptツールをエージェントに公開する方法を標準化する軽量なクライアントサイドの拡張」だと。

つまり、これらは競合ではなく、スタックの異なるレイヤーを担う補完的な仕組みです。

エージェンティックWebの5層スタック

両シリーズの内容と最新の業界動向を統合し、以下の5層モデルを提案します。これらの5層は大きく2つのグループに分かれます。基盤インフラ(第1層・第2層)はすべてのやり取りを下支えする常時稼働のレイヤーであり、エージェントフロー(第3層〜第5層)はAIエージェントがWebサイトを訪れた際に実際にたどる「発見→対話→実行」の経路です。

名称仕組み担当者役割
第1層基盤層Schema.orgGoogle + Microsoft + Yahoo! + Yandexすべての層を支える構造化データ標準
第2層通信層MCP / A2AAnthropic / Google → Linux FoundationAIとツール・エージェント間の標準接続
第3層案内層llms.txtコミュニティサイトの全体像をAIに伝える「地図」
第4層対話層NLWebMicrosoft(R.V. Guha)コンテンツに自然言語で問い合わせる「コンシェルジュ」
第5層実行層WebMCPGoogle + Microsoft(W3C)アクションを公開する「サービスカウンター」

図:エージェンティックWebの完全スタック。Webサイト内部は2つのグループで構成される。上段はAIエージェントが実際にたどるフロー(①発見 → ②対話 → ③実行)、下段はそのすべてを支える基盤インフラ(MCP/A2AとSchema.org)。

基盤インフラ:すべてのフローを支える2層

第1層:基盤層(Schema.org)

Schema.orgは、すべての層を支える構造化データ標準です。NLWebの燃料となるデータソースであり、WebMCPのtool descriptionの品質を支えるコンテキストでもあります。NLWebシリーズ第4回で解説した5つの最適化原則(エンティティの相互接続、sameAsリンク、プロパティの充実、@idによる安定識別、動的更新)は、スタック全体の性能を左右する基盤的な投資です。

第2層:通信層(MCP / A2A)

MCP(Model Context Protocol)はAnthropicが2024年11月に発表したプロトコルで、その後OpenAI(2025年3月)、Google DeepMind(2025年4月)、Microsoft(2025年5月)が相次いで採用を表明し、AIとツール・データソースを接続するための業界標準となりました。AIモデルと外部ツール・データソースを接続する「USB-C」の役割を果たします。

A2A(Agent-to-Agent Protocol)はGoogleが2025年4月に発表した、AIエージェント同士が通信するためのプロトコルです。2025年6月にLinux Foundationに移管され、ベンダー中立なガバナンスの下で標準化が進んでいます。

両プロトコルは、エージェンティックWebの「通信インフラ」です。Webサイトが何を提供するか(コンテンツ、アクション)とは独立して、その提供をどう運ぶかを定義します。

エージェントフロー:発見→対話→実行

第3層:案内層(llms.txt)— ① 発見

llms.txtは、サイトの最も重要なコンテンツをMarkdownで一覧化する静的ファイルです。AIクローラーがサイトを初めて訪問した際の「入口」として機能します。

正式なWeb標準ではなくコミュニティが推進するベストプラクティスですが、導入コストが極めて低く(テキストファイル1つを配置するだけ)、即座に効果が出るため、スタックの入口として最適です。

第4層:対話層(NLWeb)— ② 対話

NLWebは、Schema.orgデータをベクトルDBに格納し、自然言語での問い合わせに対してSchema.org JSON形式で回答を返す動的エンドポイントです。すべてのインスタンスがMCPサーバーとして機能し、AIアシスタントから直接クエリ可能です。

Kyle Pflugの言葉を借りれば、NLWebは「会話インターフェースとMCPサーバー機能を含むフルスタックフレームワーク」です。

第5層:実行層(WebMCP)— ③ 実行

WebMCPは、Webサイトの操作可能な機能(検索、予約、購入など)をTool Contractとしてブラウザ内で公開するプロトコルです。Declarative API(HTML属性追加)とImperative API(JavaScript)の2つのパスがあり、permission-firstのセキュリティ設計を特徴とします。2026年2月にChrome 146のEarly Previewとして公開されましたが、2026年3月時点ではまだ正式な安定版サポートには至っていません。

Pflugは、WebMCPは「特にインタラクティブな体験——エージェントが複雑なUIやマルチステップUIをナイーブにナビゲートすると非効率的で脆弱になりがちな場面——に適している」と述べています。

統合シナリオ:不動産サイト

5層スタックがすべて揃った不動産サイトで、ユーザーがClaude(AIアシスタント)に「渋谷区で5,000万円以下の3LDKを探して、良さそうなのがあったら内覧予約して」と依頼した場合の処理フローを描きます。

Phase 1:発見(llms.txt → MCP)

ClaudeがサイトのURLを受け取ると、まず/llms.txtを取得し、サイトの構造を把握します。「物件検索」「物件詳細」「内覧予約」「会社概要」などのセクションが存在すること、NLWebエンドポイント(/ask/mcp)とWebMCPツールが利用可能であることを理解します。

Phase 2:対話(NLWeb)

ClaudeはNLWebのMCPエンドポイントに接続し、「渋谷区、5,000万円以下、3LDK」というクエリを送信します。NLWebが第2回で解説した8ステップのクエリパイプライン(受信→デコンテキスト化→メモリ→ベクトル検索→LLMランキング→Schema.org JSON生成→ストリーミング→配信)を経て、条件に合う物件のリストをSchema.org RealEstateListing形式で返します。

Claudeはユーザーに結果を提示し、「この中で駅に近いのは?」とユーザーが続ければ、NLWebのマルチターン会話機能で文脈を保持したまま絞り込みます。

Phase 3:実行(WebMCP)

ユーザーが「この物件の内覧を予約したい」と選択すると、ClaudeはWebMCPのbookPropertyViewingツールを呼び出します。WebMCPシリーズ第3回で解説したDeclarative APIにより、内覧予約フォームの各フィールド(物件ID、希望日、連絡先)が構造化されたTool Contractとして公開されており、Claudeは正確にフォームを入力します。

toolautosubmitが設定されていないため、ユーザーが画面上で内容を確認し、「内覧を予約する」ボタンを自分でクリックして送信——human-in-the-loopの完了です。

Phase 4:品質保証(Schema.org)

このフロー全体の品質を支えているのが、第4回で最適化したSchema.orgです。RealEstateListingに価格、間取り、面積、最寄り駅、築年数が充実していればNLWebの検索精度が上がり、bookPropertyViewingのtool descriptionにSchema.orgのプロパティ名と一致する用語が使われていればWebMCPのツール選択精度が上がる。Schema.orgの品質は、スタック全体の体験品質に直結します。

「どちらか一方」ではなく「組み合わせ」

Kyle Pflugの発言で最も重要なのは、NLWebとWebMCPは排他的な選択肢ではないということです。

NLWebが得意な場面: コンテンツリッチなサイトで、ユーザーが「探す」「比較する」「理解する」ことが主目的。レシピサイト、技術ドキュメント、旅行レビュー、Eコマースのカタログ検索。

WebMCPが得意な場面: インタラクティブなサイトで、ユーザーが「予約する」「購入する」「申し込む」ことが主目的。Pflugの言葉では「エージェントが複雑なUIやマルチステップUIをナイーブにナビゲートすると非効率的で脆弱になりがちな場面」。

両方が必要な場面: ほとんどのビジネスサイト。コンテンツの検索(NLWeb)→ アクションの実行(WebMCP)というフローは、Eコマース、不動産、旅行、教育など多くの業界で自然に発生するユーザージャーニーです。

段階的導入のロードマップ

5層すべてを一度に導入する必要はありません。コストと効果のバランスを考慮した段階的なロードマップを提案します。

Phase 1:今すぐ(導入コスト:低)

llms.txt設置 + Schema.org監査

最も低コストで即効性のある施策です。llms.txtは静的ファイル1つの配置、Schema.org監査はNLWebシリーズ第4回のチェックリストに沿って実施できます。この段階で、エージェンティックWebの「基盤層」と「案内層」が整います。

Phase 2:2026年前半(導入コスト:中)

NLWeb導入

NLWebシリーズ第3回の手順でセットアップ。サイト内検索を自然言語対応にし、MCPサーバーとしてAIアシスタントからの問い合わせに応答できる状態にします。Cloudflare AutoRAGを使えば、自前のPython環境構築なしに導入可能です。

Phase 3:2026年後半(導入コスト:中)

WebMCP導入

WebMCPシリーズ第3回の手順で、既存のHTMLフォームにDeclarative APIの属性を追加。2026年3月時点ではWebMCPはChrome 146のEarly Preview段階ですが、安定版での正式サポートは2026年後半が見込まれており、ステージング環境での先行検証を推奨します。

Phase 4:2027年〜(運用コスト:継続)

本格運用と最適化

5層スタックが稼働した状態で、エージェント経由のコンバージョンを定量的に計測。tooldescriptionの品質、Schema.orgのプロパティ充実度、NLWebの回答精度を継続的に改善します。

Web制作の未来 — 「三重のインターフェース設計」

エージェンティックWebの完全スタックが示すのは、Webサイトに求められるインターフェースが三重になるということです。

第1のインターフェース:人間向けUI。 HTMLとCSSで構築される、従来のビジュアルインターフェース。ユーザーが目で見て手で操作する。

第2のインターフェース:AI問い合わせ対応。 NLWebによる自然言語エンドポイント。AIがコンテンツに問い合わせ、Schema.org JSONで回答を受け取る。

第3のインターフェース:AIアクション対応。 WebMCPによるTool Contract。AIがサイトの機能を発見し、構造化されたパラメータで操作を実行する。

この三重のインターフェースを一つのサイト内で統合的に設計すること——それが、エージェンティックWeb時代のWeb制作に求められる新しい専門性です。

弊社unTypeが「Web制作」から「コミュニケーションデザイン」へリポジショニングを進めているのは、まさにこの変化を見据えてのことです。人間との対話、AIとの対話、AIによる操作——すべてが「コミュニケーション」であり、その全体を設計する仕事が、これからのWebプロフェッショナルに求められています。

まとめ — スタックは揃った

llms.txtが「地図」を、NLWebが「コンシェルジュ」を、WebMCPが「サービスカウンター」を、MCPが「通信回線」を、Schema.orgが「すべての基盤」を担う。エージェンティックWebの完全スタックは、もはや概念図ではなく、実装可能な技術の集合体です。

どの層から始めるかは、サイトの性質と事業の優先順位で決まります。コンテンツリッチなサイトならNLWebから、トランザクション重視のサイトならWebMCPから、いずれにせよSchema.orgの品質強化とllms.txtの設置は今日からできる投資です。

「早すぎる」ことはありません。Schema.orgとレスポンシブデザインの歴史が教えてくれるように、「遅すぎた」方がはるかにコストが高いのです。

参考情報

本記事は、「WebMCP:Webサイトがアクションを話す時代」(全5回)と「NLWeb:Webサイトと会話する時代」(全5回)の統合記事です。

AI技術のビジネス活用やWebサイトのAIエージェント対応について、具体的なご相談はunTypeまでお気軽にお問い合わせください。

山下 太郎

山下 太郎

代表取締役 / CEO

2000年、Webデザイナーとしてこの世界に飛び込み、フリーランスを経て2007年に株式会社アンタイプを創業。AI時代の到来とともに、効率だけを追うAI活用に違和感を覚えながら、それでも最前線でツールを使い続ける。企業のWebとコミュニケーションを設計する仕事を通じて、「人間らしさとは何か」を問い直す視点を発信し続けている。

View Profile arrow_outward

Related

あわせて読みたい