はじめに
第3回で、NLWebの実装手順を一気通貫で体験しました。リポジトリのクローンからデータ取り込み、サーバー起動、Claude DesktopからのMCP接続まで。
実装してみて気づくことがあります。NLWebの回答品質は、取り込んだSchema.orgデータの品質にダイレクトに左右されるということです。
Search Engine Landの分析が端的に表現しています。NLWebはプロトコルの複雑さに対処してくれるが、データの品質までは修復してくれない。構造化データが不十分であれば、ベクトルデータベースには欠陥のあるセマンティック情報が格納され、AIの回答が不正確になるか、「ハルシネーション」を引き起こす可能性がある、と。
第4回の今回は、NLWebの性能を最大化するためのSchema.org最適化を、ビフォー/アフターのJSON-LDコード例とともに解説します。
なぜSchema.orgの品質がNLWebの性能を決めるのか
NLWebのデータインジェスションパイプラインは、第2回で解説したとおり、サイトのSchema.orgマークアップをクロール・抽出し、ベクトルDBに格納します。NLWebはJSON-LD内のすべてのプロパティと関係性——商品タイプ、組織エンティティ、レビュー情報など——を消費します。
これは、Schema.orgの設計品質がNLWebの回答品質に直結することを意味します。
Webstuffの分析では、NLWebにおけるSchema.orgの典型的な問題点として4つが挙げられています。エンティティの断絶(Author、Publisher、Organizationが相互参照していない)、属性の不足(nameとdescriptionだけで他のフィールドがない)、不適切なネスト(OfferやReviewが親オブジェクトに正しくリンクされていない)、静的なデータ(更新されない構造化データが鮮度を失っている)。
これらの問題は、従来のSEO(リッチスニペット獲得)では「あっても減点にはならない」程度の軽微な課題でした。しかしNLWebの文脈では、AIがデータをセマンティック検索とLLMランキングに使うため、データの欠落や断絶が回答品質に直接反映されるのです。
原則1:エンティティの相互接続 — 「島」ではなく「大陸」を作る
Schema.orgの最も重要な最適化は、エンティティ間の関係性を明示的に構築することです。
ビフォー:断絶したエンティティ
多くのサイトでは、各ページに独立したSchema.orgブロックが置かれていますが、エンティティ間の接続が欠けています。
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "AIエージェント時代のWeb制作",
"author": "山下太郎"
}
この記述では、「山下太郎」はただの文字列です。AIにとって、この著者が誰なのか、どの組織に所属しているのか、他にどんな記事を書いているのかを推論する手がかりがありません。
アフター:接続されたエンティティ
{
"@context": "https://schema.org",
"@type": "Article",
"@id": "https://untype.jp/blog/ai-web-production#article",
"headline": "AIエージェント時代のWeb制作",
"datePublished": "2026-03-15",
"dateModified": "2026-03-16",
"author": {
"@type": "Person",
"@id": "https://untype.jp/#taro-yamashita",
"name": "山下太郎",
"jobTitle": "Chief Architect",
"worksFor": {
"@type": "Organization",
"@id": "https://untype.jp/#organization"
},
"sameAs": [
"https://www.linkedin.com/in/taro-yamashita/",
"https://twitter.com/taro_yamashita"
]
},
"publisher": {
"@type": "Organization",
"@id": "https://untype.jp/#organization",
"name": "株式会社アンタイプ",
"url": "https://untype.jp",
"logo": {
"@type": "ImageObject",
"url": "https://untype.jp/logo.png"
},
"sameAs": [
"https://twitter.com/untype_jp"
]
},
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://untype.jp/blog/ai-web-production"
}
}
このアフター例では、以下の関係性が明示されています。
- Article → Person(author) — 記事の著者が特定の人物エンティティ
- Person → Organization(worksFor) — 著者が特定の組織に所属
- Article → Organization(publisher) — 記事を公開した組織
- Person / Organization → 外部プロファイル(sameAs) — エンティティの同一性を外部で裏付け
- 各エンティティに安定した
@id— サイト内の他のページからも同一エンティティを参照可能
NLWebはこの関係性のネットワーク全体を取り込み、ベクトルDBに格納します。「アンタイプのCTO が書いたAI関連の記事は?」という自然言語クエリに対し、著者→組織→記事の関係を辿って正確な回答を返せるようになるのです。
原則2:sameAsリンクの活用 — 外部参照による信頼性強化
sameAsプロパティは、エンティティの同一性を外部の権威あるソースで裏付けるための仕組みです。12AM Agencyの解説によれば、sameAsはデジタルの「等号」として機能し、Webサイト上のエンティティが他のプラットフォーム上の同じエンティティと同一であることを明示します。
効果的なsameAsリンク先
組織(Organization)の場合:
- LinkedIn企業ページ
- Crunchbase
- Wikipedia / Wikidata
- 業界団体の会員ページ
- 公式SNSアカウント
人物(Person)の場合:
- LinkedIn個人プロファイル
- GitHub
- 学術出版物のプロファイル(Google Scholar等)
- 公式SNSアカウント
商品(Product)の場合:
- 製造元の公式ページ
- 業界データベースのエントリ
NLWebの文脈では、sameAsリンクはベクトル化されたエンティティの「信頼性スコア」を間接的に強化します。外部参照が豊富なエンティティは、LLMランキングの段階でより信頼性の高い情報源として扱われやすくなります。
原則3:プロパティの充実度 — nameとdescriptionだけでは不十分
Webstuffが指摘するとおり、nameとdescriptionだけの最小限のSchema.orgは、NLWebの文脈では「不十分」です。
ビフォー:最小限のProduct
{
"@context": "https://schema.org",
"@type": "Product",
"name": "エコボトル500",
"description": "ステンレス製のエコボトル"
}
この記述では、NLWebが「5,000円以下のボトルは?」「保冷機能付きのものは?」といった具体的な質問に答えることができません。
アフター:充実したProduct
{
"@context": "https://schema.org",
"@type": "Product",
"@id": "https://example.com/products/eco-bottle-500#product",
"name": "エコボトル500",
"description": "12時間保冷対応のステンレス製リユーザブルボトル。500ml容量。",
"brand": {
"@type": "Brand",
"name": "EcoHydrate"
},
"offers": {
"@type": "Offer",
"price": "3980",
"priceCurrency": "JPY",
"availability": "https://schema.org/InStock",
"url": "https://example.com/products/eco-bottle-500"
},
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.5",
"reviewCount": "128"
},
"material": "ステンレス鋼(18/8)",
"weight": {
"@type": "QuantitativeValue",
"value": "350",
"unitCode": "GRM"
},
"additionalProperty": [
{
"@type": "PropertyValue",
"name": "容量",
"value": "500ml"
},
{
"@type": "PropertyValue",
"name": "保冷時間",
"value": "12時間"
}
]
}
このアフター例では、価格、在庫状況、評価、素材、重量、容量、保冷時間まで構造化されています。NLWebはこれらすべてのプロパティをベクトル化するため、「5,000円以下で保冷機能付きのボトル」「評価4以上の軽量ボトル」といった複合条件の自然言語クエリにも正確に応答できます。
原則4:@idによる安定したエンティティ識別
@idは、サイト内でエンティティを一意に識別するためのIRI(Internationalized Resource Identifier)です。geneo.appのベストプラクティスガイドでは、エンティティファーストのスキーマ設計において、各エンティティに安定した@idを付与し、関連エンティティ間を@id参照でつなぐことが推奨されています。
// ページAのJSON-LD
{
"@type": "Article",
"author": { "@id": "https://untype.jp/#taro-yamashita" }
}
// ページBのJSON-LD
{
"@type": "Article",
"author": { "@id": "https://untype.jp/#taro-yamashita" }
}
// 著者ページのJSON-LD
{
"@type": "Person",
"@id": "https://untype.jp/#taro-yamashita",
"name": "山下太郎",
"worksFor": { "@id": "https://untype.jp/#organization" }
}
複数ページにまたがって同じ@idを参照することで、NLWebはサイト全体で「山下太郎」が同一人物であることを認識し、この人物に関連するすべてのコンテンツを統合的にクエリできます。
原則5:動的更新の重要性 — 古いデータはAI可視性を損なう
構造化データは「一度設置したら終わり」ではありません。
価格が変わった商品のOfferが古い価格のまま、終了したイベントのEventが「開催中」のまま、退職した社員のPersonが在籍中のまま——これらの「陳腐化した構造化データ」は、NLWebを通じてAIに誤情報を提供することになります。
Webstuffは「構造化データをコードのようにバージョン管理すべき」と提言しています。具体的には、datePublishedとdateModifiedを正確に維持し、Schema.orgの変更履歴を追跡し、定期的な監査サイクルを設けることが重要です。
NLWebのデータインジェスションは繰り返し実行できるため、Schema.orgを更新した後にインジェスションを再実行すれば、ベクトルDBの内容も最新の状態に更新されます。Cloudflare AutoRAGを使用している場合は、継続的な再クロールにより自動で反映されます。
実務チェックリスト:NLWeb対応Schema.org監査
自社サイトのSchema.orgがNLWebに適しているかを評価するためのチェックリストです。
構造の品質
- 主要エンティティ(Organization、Person、Product/Service)に
@idが付与されている - エンティティ間の関係(author↔Organization、Product↔Offer↔Brand)が明示的にリンクされている
sameAsリンクが主要エンティティに設定されている(LinkedIn、Wikipedia等)- JSON-LDに構文エラーがない(Google Rich Results Testで検証済み)
プロパティの充実度
- Productに価格(Offer)、在庫状況、評価(AggregateRating)が含まれている
- Articleに著者(Person)、公開日、更新日、出版者(Organization)が含まれている
- Personにジョブタイトル、所属組織、sameAsリンクが含まれている
- Organizationにロゴ、連絡先、sameAsリンクが含まれている
鮮度の維持
dateModifiedがコンテンツの実際の更新日を反映している- 終了したイベント、販売終了した商品の構造化データが更新されている
- 定期的なSchema.org監査サイクル(四半期ごと等)が設定されている
WebMCPシリーズとの接続 — 「記述」と「実行」の二重レイヤー
並行連載中のWebMCPシリーズ第4回では、Schema.orgとWebMCPの関係を「名詞(何であるか)× 動詞(何ができるか)」と整理しました。NLWebの文脈でも、この二重レイヤーの考え方はそのまま適用されます。
Schema.orgが充実しているサイトは、NLWebによる自然言語クエリに正確に応答できる(名詞が豊か)だけでなく、WebMCPによるアクション公開とも連携しやすい(動詞と名詞が接続される)のです。
たとえば不動産サイトの場合、Schema.orgのRealEstateListingが物件の詳細情報を構造化し(NLWeb向け)、WebMCPのbookPropertyViewingツールが内覧予約アクションを公開する(WebMCP向け)。AIエージェントは「渋谷区で5,000万円以下の3LDKは?」とNLWebに問い合わせ、結果を確認した上で「この物件の内覧を予約して」とWebMCPでアクションを実行する。
Schema.orgの品質が高ければ高いほど、このワンストップ体験の精度が向上します。
まとめ — Schema.orgは「SEO資産」から「AI基盤」へ
NLWebの登場により、Schema.orgの位置づけは根本的に変わりました。
従来のSchema.orgは「リッチスニペット獲得のためのSEO施策」でした。NLWebの文脈では、Schema.orgは「AIがサイトのコンテンツを正しく理解するための基盤データ」です。
Search Engine Landが述べるとおり、堅牢なエンティティファーストのSchema.org最適化は、もはやリッチリザルトを獲得するための手段ではなく、エージェンティックWebへの参入障壁そのものです。
これまでSEO対策として投資してきたSchema.orgは、NLWeb時代に大きなリターンをもたらす資産です。本記事で解説した5つの原則——エンティティの相互接続、sameAsリンク、プロパティの充実、@idによる安定識別、動的更新——を適用することで、その資産の価値を最大化できます。
次回のシリーズ最終回・第5回では、NLWebのエンタープライズ戦略を取り上げます。早期採用企業の事例、ROI試算のフレームワーク、セキュリティ上の注意点、そしてWebMCP + NLWeb + MCP + llms.txtの統合戦略を提示します。
参考情報
Search Engine Land「The agentic web is here: Why NLWeb makes schema your greatest SEO asset」(2025年10月)
Webstuff「NLWeb: How Microsoft's Open Protocol Turns Schema into the Engine of AI Visibility」(2025年10月)
12AM Agency「Structured Data to Improve Knowledge Panel: The 2026 Technical Guide」(2026年3月)
geneo.app「Schema Markup Best Practices 2026: JSON-LD & Audit」(2026年)
ALM Corp「Schema Markup in 2026: Why It's Now Critical for SERP Visibility」(2025年12月)
iunera「How Markdown & JSON-LD improves NLWeb Vectorsearch RAG」(2025年6月)
Interrupt Media「Master Schema JSON-LD: Elevate Your SEO Strategy」(2025年9月)
Breakline Agency「The Ultimate Guide to All Schema.org Types」(2026年1月)
Schema App「What is NLWeb? Consuming Schema Markup for AI Applications」(2025年12月)
GitHub「nlweb-ai/NLWeb(リファレンス実装)」
この記事は「NLWeb:Webサイトと会話する時代」シリーズの第4回です。
AI技術のビジネス活用やWebサイトのAIエージェント対応について、具体的なご相談はunTypeまでお気軽にお問い合わせください。
この記事をシェアする