AI・LLMO実践コラム ／ 標準対応編
llms.txt、NLWeb、WebMCP——AI向けにWeb情報を扱いやすくする仕様案やオープンプロジェクトが次々と登場し、「結局どれをやればいいの？」という声をよく聞きます。今回は、乱立しているように見えるこれらを、役割ごとに3つの層へ整理して、着手の順番を示します。
仕様案が乱立しているのは事実。でも層で見れば整理できる
AI向けにWeb情報を扱いやすくするための仕様案やオープンプロジェクトは、たしかに増えています。llms.txt、NLWeb、WebMCPなど、正式な標準・提案・実装実験が混在しているため、同じもののように見えやすい状況です。
混乱の正体は「全部が同じ土俵のものに見えてしまう」ことにあります。けれど、それぞれが担う役割は違います。役割で3つの層に分けると、自社が今どこに手を付けるべきかが見えてきます。キーワードは「読まれる → 問い合わせられる → 使われる」です。
第1層：読まれる（llms.txt）
llms.txtは、サイトのトップ階層に置く“AI向けの案内ファイル”です。
「このサイトで重要なのは、このページとこのページです」とAIに伝える、シンプルな道しるべ。テキストファイルを1枚置くだけなので、着手のハードルが低く、まず最初に取り組む層です。
具体的には、`llms.txt` という名前のテキストファイルを1枚つくり、サイトの最上位（例：`https://example.com/llms.txt`）に置きます。中身は、AIに読んでほしいページの一覧と、その短い説明を箇条書きで書くだけ。たとえば、次のようなイメージです。
# 株式会社ノース・ヒル
> AI・LLMOの最新動向を、非エンジニア向けにやさしく解説するメディア
## 重要なページ
- [会社概要](https://ai-northhill.com/about/): 運営者・事業内容
- [コラム一覧](https://ai-northhill.com/columns/): AI・LLMO実践コラム
- [お問い合わせ](https://ai-northhill.com/contact/): ご相談・取材のご依頼見てのとおり、特別なプログラミングは不要で、メモ帳でも作れる簡単なものです。「サイトの地図を、AI向けに1枚の案内状にまとめる」——そんな作業だと考えてください。
ただし、ひとつ注意点があります。llms.txtを設置したからといって、AIの引用が増えると確認されているわけではありません。普及は進みつつあるものの、効果については慎重な見方もあります。あくまで「AIに読まれる前提を整える」ものと捉えるのが適切です。
第2層：問い合わせられる（NLWeb）
NLWebは、Microsoftが提唱している“会話できる窓口”の仕組みです。
AIが自然な言葉で質問を投げると、サイト側が構造化されたデータで答える。「AIがサイトを読む」から「AIがサイトに問い合わせる」への転換点といえます。
具体例で考えてみましょう。商品データや記事を schema.org の形式で整理しているサイトに NLWeb を組み込むと、AIが「5,000円以下で、赤いビジネスバッグはある？」と日本語で尋ねたとき、サイト側がその条件に合う商品を構造化データの中から探して返す——そんな“会話できる窓口”ができあがります。
実際の実装イメージ
NLWebは、Microsoftが公開しているオープンソースのプロジェクトです。導入を大きく見ると、「①商品・記事データを整える → ②NLWebに取り込む → ③LLMや検索基盤（ベクトルDBなど）と接続する → ④問い合わせ用の入口を用意する」という流れになります。
まず①として、自社の商品や記事を schema.org（JSON-LD）やRSS、JSONLなどの形で整えます。たとえば商品1つは、次のようなデータです。
{
"@context": "https://schema.org",
"@type": "Product",
"name": "ビジネスバッグ ABC",
"color": "レッド",
"offers": { "@type": "Offer", "price": "4800", "priceCurrency": "JPY" }
}②③では、このデータをNLWebに取り込み、検索しやすい形（ベクトルDB）に変換したうえで、回答を組み立てるLLMと接続します。設定ファイルに「データの場所」「ベクトルDBや検索の設定」「必要に応じて OpenAI・Gemini・Anthropic などのLLM APIキー」を記入するイメージです。ここで大事なのは、NLWebはschema.orgのデータをそのまま読み上げるのではなく、検索・ランキング処理やLLMを組み合わせて回答を生成するという点。「JSON-LDを置けば自動で答える」わけではありません。
④まで済むと、AIが問い合わせできる入口（例：`https://自社サイト/ask`）が1つでき、「5,000円以下の赤いバッグは？」という問いに、①のデータをもとに「ビジネスバッグ ABC（4,800円）」と答えられるようになります。
実務上は、エンジニアやベンダーに「NLWebを、うちの商品データ（schema.org等）につないで設置してほしい」と依頼する形が現実的です（あくまで導入イメージで、具体的な構成はベンダー確認が必要です）。発注時にいちばん効くのは、きれいな構造化・半構造化データが用意できているか。ここが弱いと、窓口を作っても良い答えは返りません。だからこそ、第2層に進むには、まず schema.org・RSS・JSONL などで一次情報を整理しておくことが重要です。llms.txt のような周辺整備も有効ですが、NLWebの必須前提というわけではありません。
第3層：使われる（WebMCP）
WebMCPは、サイトが「在庫を調べる」「予約する」といった“できること”をAIエージェントに宣言し、実際に操作させるための仕組みです。
具体的には、サイト側で「AIが呼び出せる操作」を、決まった形式であらかじめ宣言しておきます。たとえば飲食店なら「`予約する（日付, 人数）`」、ECサイトなら「`在庫を確認する（商品ID）`」といった“AI用のボタン”を用意するイメージです。すると、ユーザーが「来週の金曜、4人で予約しておいて」とAIに頼んだとき、AIエージェントがその「予約する」操作を自分で呼び出し、予約まで完了させる——という動きが可能になります。人間が画面をポチポチとクリックする代わりに、AIが裏側の操作を直接呼び出す、と考えるとイメージしやすいでしょう。ここでの「入れる」とは、AIに使わせたい操作を、機械が呼べる形で一覧にして公開することを指します。
実際の実装イメージ
WebMCP対応とは、Webページに少しのプログラム（JavaScript）を足して、「AIが呼び出せる操作」を宣言することです。たとえば「席を予約する」操作は、次のように登録します。
// ページに「予約する」操作をAI向けに登録する
document.modelContext.registerTool({
name: "reserve_table",
description: "レストランの席を予約する",
inputSchema: { date: "予約日", people: "人数" },
async execute({ date, people }) {
return await 予約処理(date, people); // ← 既存の予約システムを呼ぶ
}
});この宣言が「AIに呼び出せる操作がある」と伝える入口になります。`name`（操作名）・`description`（何をする操作か）・`inputSchema`（必要な情報）を示し、`execute` の中で“実際の処理”——多くの場合、すでに自社にある予約APIやカート機能——を呼び出します。AIエージェントは、この宣言を読み取って「来週の金曜、4人で予約して」という依頼を `reserve_table` の呼び出しに変換します。ただし、これだけで予約が完了するわけではありません。実際には、認証・権限確認・予約APIとの接続・決済・確認画面・エラー処理などを別途用意する必要があります。
つまりWebMCP対応とは、ゼロから何かを作ることではなく、すでにある自社機能（予約・検索・在庫照会など）に“AIから呼べる入口”を付け足す作業です。まずは主要な操作を1〜2個だけ登録して試す、というのが現実的な第一歩になります。（※コードはイメージです。WebMCPは策定の途上で、記法は変わり得ます。実装時は最新の公式ドキュメントとベンダー確認を。）
標準化に向けた議論が進められており、現時点では Chrome がローカル開発用フラグで試せる段階です（Chrome 149 での Origin Trial も予定されています）。広範なブラウザ対応や正式な標準化には至っておらず、仕様は今後変わる可能性があります。それでも、予約・購入・在庫照会など“操作”を伴う事業にとっては、将来とくに有望な層といえます。AIが単に情報を読むだけでなく、ユーザーの代わりに行動する未来を見据えたものです。
優先順位の目安
多くの企業にとって、2026年の現実的な順番はこうなります。
- まず第1層（読まれる準備）：sitemap・robots.txtの整備、llms.txtの設置
- コンテンツ中心の事業：第1層と構造化（schema）で、当面は十分に効果が出る
- 予約・取引のある事業：その先の第3層（WebMCP）が効いてくる
- 第2層（NLWeb）：両者をつなぐ橋として、構造化データが整ってから検討する
いきなり全部に手を出す必要はありません。自社の事業形態に照らして、効く層から着手するのが賢明です。
個別仕様に賭けない、という構え
最後に、いちばん大事な構えをお伝えします。
正直に言えば、これらの標準のどれが最終的に主流になるかは、まだ誰にもわかりません。だからこそ、特定の仕様そのものに全部を賭けるのは危険です。
賭けるべきは、もっと根っこにある力——「構造化された一次情報を、信頼できる主体として、機械が読める形で公開する」こと。これは、どの標準が勝っても無駄になりません。標準は手段であって、目的ではない。この視点を持っておくと、新しい規格が登場するたびに振り回されずに済みます。
よくある疑問
Q. llms.txtは今すぐ設置すべきですか？
設置のコストは低いので、やっておいて損はありません。ただし「設置すれば引用が増える」と過度に期待せず、土台整備の一環と位置づけてください。
Q. うちは小さな会社です。WebMCPまで必要？
予約・購入・在庫照会のような“操作”を伴う事業でなければ、当面は不要なことが多いです。まずは第1層と構造化を優先しましょう。
Q. 標準が変わったら、やり直しになりませんか？
個別仕様に依存した作り込みは、変更の影響を受けます。だからこそ「構造化された一次情報を機械可読に公開する」という本質に投資しておくと、仕様が変わっても資産が生き続けます。
まとめ
AI向けの新しい仕様は、「読まれる→問い合わせられる→使われる」の3層で整理できます。多くの事業は、まず第1層と構造化から。取引のある事業はその先のWebMCPへ。そして、個別仕様ではなく「機械可読な一次情報を公開する力」という本質に賭ける——この構えが、変化に強い土台をつくります。
次回のコラムでは、流入が減る前提で「何を測るか」を組み直す、ゼロクリック時代のKPI設計を解説します。
参考にした情報源
- llms.txt / NLWeb / WebMCP 各仕様・プロジェクトの公開ドキュメントおよび解説（2026年）
- Microsoft による NLWeb 関連の発表・解説（GitHub ドキュメント等、2026年）
- WebMCP の標準化動向、Chrome の実装状況（開発用フラグ／Origin Trial）に関する報道（2026年）
※ 本記事の事実関係は2026年6月時点の公開情報に基づいています。各標準は策定・実装の途上にあり、状況は変動します。