NLWeb：Webサイトと会話する時代 第2回：NLWebのアーキテクチャ — Schema.orgからベクトルDBへの変換パイプライン

はじめに

第1回では、NLWebの「なぜ」を解説しました。R.V. Guhaの系譜（RSS → RDF → Schema.org → NLWeb）、Microsoftの「NLWebは新しいHTML」というビジョン、MCPサーバーとしての自動機能、そしてllms.txtとの根本的な違い。

第2回の今回は、NLWebの「中身」に踏み込みます。ユーザーが「ローマの家族向けホテルで朝食無料のところは？」と入力してから、構造化されたSchema.org JSONレスポンスが返るまでに、内部で何が起きているのか。データインジェスション（取り込み）パイプライン、クエリ（問い合わせ）パイプライン、マルチターン会話の仕組み、そしてNLWebを構成する4つのモジュールを解説します。

NLWebの処理パイプライン全体像

NLWebのアーキテクチャは、大きく2つのパイプラインで構成されています。

データインジェスションパイプラインは、Webサイトの構造化データを取り込み、ベクトルデータベースに格納するまでのプロセスです。これはNLWebのセットアップ時に一度（そして、データ更新時に随時）実行されます。

クエリパイプラインは、ユーザーやAIエージェントからの自然言語の質問を受け取り、ベクトルDB検索、LLMによるランキング・整形を経て、Schema.org JSON形式のレスポンスを返すまでのプロセスです。これはリクエストごとにリアルタイムで実行されます。

Schema Appは、この構造を「郵便配達」に例えています。梱包箱がMCPの標準フォーマット、中身がSchema.org構造化データ、届け先がLLM。NLWebは郵便局のように、荷物が正しく宛名書きされ、配達され、正しい情報とともに返送されるよう管理する、と。

データインジェスション — Schema.orgからベクトルDBへ

NLWebが動作するためには、まずWebサイトのコンテンツをベクトルデータベースに格納する必要があります。このプロセスがデータインジェスションです。

Step 1：構造化データの抽出

NLWebはWebサイトをクロールし、ページ内のSchema.org構造化データを抽出します。NLWebの公式ドキュメントによれば、JSON-LD形式のSchema.orgマークアップが推奨される入力フォーマットです。NLWebはスキーマ内のすべてのプロパティと関係性——商品タイプ、組織エンティティ、レビュー情報など——を消費します。

JSON-LD以外のフォーマットにも対応しています。RSSフィードはSchema.orgタイプに変換して取り込むことができ、JSONL（JSON Lines）形式の直接入力にも対応しています。第1回で触れたとおり、Schema.orgとRSSは1億以上のWebサイトで使われている既存のセマンティックレイヤーであり、NLWebはこの巨大な既存資産を再利用できる設計になっています。

Step 2：ベクトル化（エンベディング）

抽出されたSchema.orgデータは、エンベディングモデルによって数学的ベクトルに変換されます。テキストをベクトル空間上の点として表現することで、「意味の近さ」を数値的に計算できるようにするプロセスです。

たとえば、「朝食無料のホテル」と「complimentary breakfast included」は、キーワードとしては全く異なりますが、ベクトル空間上では非常に近い位置に配置されます。これにより、言語や表現の違いを超えたセマンティック検索が可能になります。

NLWebのリファレンス実装では、OpenAIのtext-embedding-3-smallなどのエンベディングモデルが使用されていますが、プラットフォーム非依存の設計のため、他のモデルに差し替えることも可能です。

Step 3：ベクトルDBへの格納

ベクトル化されたデータは、ベクトルデータベースに格納されます。NLWebは複数のベクトルDBに対応しており、サイトの規模やインフラ要件に応じて選択できます（対応DBの詳細は後述します）。

このデータインジェスションが完了した時点で、NLWebはクエリを受け付ける準備が整います。

クエリパイプライン — 自然言語からSchema.org JSONレスポンスへ

iuneraによる詳細な技術分析とDEV Communityの解説をもとに、NLWebのクエリ処理パイプラインを8つのステップで整理します。ここでは「ディワリ（インドの祝祭）向けのベジタリアンレシピを探して」というクエリを例に使います。

Step 1：クエリの受信と解析

ユーザーまたはAIエージェントからのクエリは、REST APIの/askエンドポイントまたはMCPのaskメソッドで受け付けられます。NLWebはJSONリクエストを解析し、クエリテキスト、対象サイト、会話履歴（prev）、表示モード（list、summarizeなど）、ストリーミング設定を抽出します。

同時に、サイト設定ファイル（site_type.xml）を参照し、対象サイトのSchema.orgタイプ（例：Recipe、Product、Hotel）を特定します。

Step 2：デコンテキスト化（文脈の解消）

マルチターン会話の場合、現在のクエリは前の会話の文脈に依存していることがあります。たとえば、最初に「インドのお祭りのレシピは？」と聞き、次に「ベジタリアンのものは？」と続けた場合、2番目のクエリだけでは意味が通じません。

NLWebはLLMを使って、会話履歴（prev配列）と現在のクエリを統合し、文脈から独立した自己完結的なクエリ——「ディワリ向けのベジタリアンレシピを探して」——に書き換えます。これが「デコンテキスト化（decontextualization）」と呼ばれるプロセスです。

DEV Communityの分析は、このステップを「ステートレスなコンポーネントの上にステートフルな体験を構築するための強力なパターン」と評しています。会話履歴の複雑さを1つの予測可能なステップに隔離することで、パイプライン全体のモジュール性を維持しているのです。

Step 3：メモリの検出と読み込み

NLWebには、セッションをまたいで保持される長期的な指示を管理するmemory.pyモジュールがあります。たとえば、ユーザーが以前「今後はグルテンフリーのものだけ表示して」と指示していた場合、その制約がメモリとして保存され、以降のクエリに自動的に適用されます。

Step 4：ベクトル検索

デコンテキスト化されたクエリをエンベディングモデルでベクトル化し、ベクトルDBに対してセマンティック検索を実行します。ここで返されるのは、クエリの「意味」に最も近いSchema.orgエンティティの候補群です。

メモリに保存された制約（例：「グルテンフリーのみ」）がある場合、検索結果はその制約でフィルタリングされます。

Step 5：LLMによるランキングと整形

ベクトル検索の結果候補をLLMに渡し、クエリとの関連性でランキングします。単純なベクトル類似度だけでは捉えきれない文脈的な関連性——たとえば「家族向け」と「子供に安全な」の関係——をLLMが判断します。

NLWebのリファレンス実装では、事前定義されたプロンプトテンプレート（list、summarize、generateなど）が用意されており、複雑なプロンプトエンジニアリングなしに高品質なレスポンスを生成できます。

Step 6：Schema.org JSONレスポンスの生成

ランキングされた結果は、Schema.org形式のJSON-LDとしてレスポンスに整形されます。これにより、レスポンスは人間にとっても機械にとっても構造化された、予測可能なフォーマットで提供されます。

DEV Communityの分析が指摘するとおり、Schema.orgを活用することで「LLMに出力を整形させてからテキストをパースする」よりもはるかに信頼性の高い構造化出力が得られます。

Step 7：ストリーミングレスポンス（オプション）

streaming: trueが指定されている場合、レスポンスは一括ではなく段階的にストリーミングされます。ユーザーはクエリ送信直後から結果を確認でき、体感的なレイテンシーが大幅に削減されます。

Step 8：レスポンスの配信

最終的なレスポンスは、REST APIの場合はHTTPレスポンスとして、MCPの場合はMCPプロトコルのレスポンスとして返されます。どちらの場合もSchema.org JSON形式が共通フォーマットです。

パフォーマンス

iuneraの分析によれば、NLWebは複数のステップを並列処理することで、レイテンシーを約0.5〜0.7秒に抑えています。逐次処理の場合の1.2〜2秒と比較すると、約半分以下の応答時間を実現しています。

4つのモジュール — NLWebの構成要素

NLWebは単一のモノリスではなく、4つのモジュールで構成されています。GitHubリポジトリの公式説明に基づいて整理します。

AskAgent

NLWebの中核モジュールです。上で解説したクエリパイプラインの全体——自然言語クエリの受信、デコンテキスト化、ベクトル検索、LLMランキング、Schema.org JSONレスポンスの生成——を担当します。LLM、ベクトルDB、データインジェスションツール、サンプルWeb UIのコネクタを含むオールインワンのモジュールです。

AgentFinder

NLWeb対応エージェントのディスカバリー（発見）サービスです。Web上に存在する複数のNLWebインスタンスの中から、ユーザーのクエリに最適なエージェントを発見し、ルーティングする機能を提供します。たとえば、「ローマのホテルと航空券を同時に探して」というクエリが来た場合、ホテル専門のNLWebインスタンスと航空券専門のインスタンスをそれぞれ発見し、両方にクエリをルーティングする、という使い方が想定されています。

DataFinder

企業データソース向けの自然言語→SQL変換モジュールです。HubSpot、Dynamics 365、Jiraなどのエンタープライズデータソースに対し、Schema.orgベースのオントロジーマッピングを使って自然言語クエリをSQLに変換し、データを取得します。AskAgentがWebコンテンツを対象とするのに対し、DataFinderは企業の業務データを対象とする「社内版NLWeb」と捉えることができます。

ModelRouter

LLMのルーティングとスコアリングを担当するモジュールです。品質閾値を満たすモデルの中から最もコスト効率の良いモデルを選択します。たとえば、単純な検索クエリにはGPT-4.1-miniを、複雑な推論が必要なクエリにはGPT-4.1を使う、といった動的なモデル選択を自動化します。

対応ベクトルDBとLLM — 技術中立な設計

NLWebの大きな特徴の一つが、特定のベンダーやプラットフォームに依存しない技術中立な設計です。

ベクトルDB

Microsoftの公式解説によれば、PostgreSQL + pgvectorは「外部のベクトルデータベースを必要とせず、既存のデータベース上でNLWebインスタンスを立ち上げられる」メリットがあります。既存のPostgreSQLインフラを持つ企業にとっては、追加の運用負荷なしにNLWebを導入できる現実的な選択肢です。

LLM

ModelRouterモジュールにより、クエリの複雑さに応じて最適なモデルを自動選択する仕組みが組み込まれています。単純な一覧検索には低コストのモデルを、複雑な推論には高性能モデルを使うことで、品質とコストを両立できます。

Cloudflareとの統合 — 「ワンクリック」への道

NLWebの自前運用はサーバー構築とベクトルDB管理が必要ですが、CloudflareのAutoRAGとの統合により、マネージドな形でのNLWeb導入も現実的になっています。

Cloudflare AutoRAGを使うと、ドメインを指定するだけで自動的にサイトをクロール・インデックスし、Cloudflare WorkerがNLWebプロトコルの/askエンドポイント（人間向け会話UI）と/mcpエンドポイント（AIエージェント向けMCPサーバー）を提供します。継続的な再クロールと再インデックスにも対応しており、コンテンツの鮮度が自動で保たれます。

自前構築とマネージドサービスの選択肢が両方存在することは、NLWebの普及にとって重要です。技術力のあるチームは自前構築でフルカスタマイズを、そうでないチームはマネージドサービスで手軽にNLWebを導入できます。

設計原則 — なぜこのアーキテクチャなのか

NLWebの技術的な構成を一通り見たところで、その設計から読み取れる原則を整理しておきます。

モジュール性。 DEV Communityの分析が指摘するとおり、NLWebのパイプラインの各ステップは独立したコンポーネントです。LLMをOpenAIからClaudeに、ベクトルDBをQdrantからPostgreSQLに、ドメインをレシピからEコマースに差し替えることが、設定ファイルの変更だけで可能です。

構造の活用。 Schema.orgという既存の構造化データ標準をフルに活用することで、「ゼロからデータを準備する」コストを排除しています。LLMに自由形式の出力を求めるのではなく、Schema.org JSONという予測可能な構造で返すことで、下流のシステム（AIエージェント、UI）での利用が容易になります。

文脈の隔離。 デコンテキスト化ステップは、会話履歴の複雑さをパイプラインの残りから隔離する設計です。マルチターン会話を「ステートフルに見えるが実際にはステートレスなシステム」として実現するための技巧であり、スケーラビリティに寄与しています。

次回の第3回では、このアーキテクチャを実際にセットアップするハンズオンに進みます。GitHubリポジトリのクローンから、Schema.orgデータの取り込み、ベクトルDBの構築、NLWebサーバーの起動、Claude DesktopからのMCP接続までを、一気通貫で解説します。

参考情報

• GitHub「nlweb-ai/NLWeb（リファレンス実装）」

• GitHub「NLWeb: Life of a Chat Query」

• Schema App「What is NLWeb? Consuming Schema Markup for AI Applications」（2025年12月）

• iunera「NLWeb's AI Demystified: How an Example Query is Processed in NLWeb」（2025年6月）

• DEV Community「Under the Hood of Conversational AI Search: A Deep Dive into the NLWeb Prototype」（2025年10月）

• Microsoft Tech Community「Fueling the Agentic Web Revolution with NLWeb and PostgreSQL」（2025年7月）

• Cloudflare「Make Your Website Conversational for People and Agents with NLWeb and AutoRAG」（2025年8月）

• Qdrant「Microsoft NLWeb Integration」

• Search Engine Land「The agentic web is here: Why NLWeb makes schema your greatest SEO asset」（2025年10月）

• DigitrendZ「Unlock SEO Power: How NLWeb Makes Schema Your Top Asset」（2025年10月）

• Microsoft「Introducing NLWeb: Bringing conversational interfaces directly to the web」（2025年5月）

• Sketchweb「NLWeb Explained: Natural Language Search for Your Website」（2026年2月）

この記事は「NLWeb：Webサイトと会話する時代」シリーズの第2回です。

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