Elasticsearchにおける決定論的なガードレールを備えたエージェント型AI検索による安全なクエリ実行

このシリーズのパート1から7では、eコマース検索のための管理された制御プレーンを説明しました。ユーザーがクエリを入力します。商品カタログへのクエリ実行前に、意図の分類、制約の適用、ポリシーの競合の解決、適切な検索戦略へのルーティングを行う制御プレーンが意図を分類し、ビジネス制約を適用し、ポリシーの競合を解決し、適切な検索戦略にルーティングします。このアーキテクチャー全体は、入力が人間の購入者によって入力された検索文字列であることを前提としています。

この最後の投稿では、入力がAIエージェントから来る場合、何が変わるのかを問いかけます。

その答えは、アーキテクチャーは変わらなくとも、重要性は変わるということです。人間が作成したクエリにとって重要であるガバナンスを備えた制御プレーンのすべてのプロパティは、上流の意思決定者が大規模言語モデル（LLM）である場合、さらに重要になります。入力を生成するシステムが本質的に確率的であるため、決定論、監査可能性、競合の解決、制約の強制は、運用上の利便性ではなく、重要な安全策となります。

エージェント型検索の問題

AIを活用した検索の最も一般的なアプローチは単純明快です。LLMにデータベーススキーマを与え、プロンプトにビジネスルールを指定すれば、エージェントがクエリを直接生成します。

eコマースチャットボットの場合、これはElasticsearchのインデックスマッピング、フィールドタイプ、カテゴリー分類、価格設定ロジック、ビジネス制約をエージェントのコンテキストウィンドウに挿入し、LLMに自然言語を有効なElasticsearchクエリDSLに変換するように要求することを意味します。LLMがクエリ作成者となります。

このアプローチはデモでは有効です。本番環境で失敗する理由は4つあります。

コンテキストの肥大化

エンタープライズeコマースインデックスのマッピングは簡単な文書ではありません。フィールド定義、ネストされたオブジェクト、マルチフィールド設定、アナライザー設定は、ビジネスロジックを追加する前に何千ものトークンに実行される可能性があります。マッピングに加えて、エージェントにはカテゴリータクソノミー（エンタープライズeコマースでは数万の値を含む可能性がある）、価格設定ルール、ブランド階層、適格性制約、キャンペーンロジックが必要です。

その結果、コンテキストウィンドウはユーザーの実際の意図よりも、構造的なメタデータによって支配されることになります。これにより、待ち時間が長くなり、トークンのコストが増加し、コンテキストが大きくなるにつれてLLMの指示に従う能力が低下します。これはよく知られた現象で、文脈の劣化と呼ばれることもあります。つまり、プロンプトが長くなるにつれて、モデルが特定の指示に注意を払う能力が弱まるのです。

確率的なハルシネーション

LLMは、トレーニングデータのパターンと提供されたコンテキストに基づいてクエリを生成します。ElasticsearchクエリDSLを生成するように求められた場合、モデルは存在しないフィールド名を誤って生成したり、構文的に無効なクエリ句を構築したり、フィルタータイプを間違ったフィールドタイプに誤って適用したり、構文的には有効であるものの意味的に間違ったクエリを生成して、ユーザーの意図と一致しない結果を返したりする可能性があります。

Google CloudのテキストからSQLへの変換に関するBIRDベンチマークはこのアプローチの限界を示しています。Googleの最先端の単一モデルによる検索結果は70%から80%の精度を達成しましたが、これは生成されたクエリのほぼ4分の1が間違っていたことを意味します。これはSQL用で、ElasticsearchのクエリDSLよりもはるかに標準化されています。複雑なマッピングとビジネス固有のセマンティクスを含む実際の本番環境でのLLMで生成されたElasticsearchクエリのエラー率は、おそらくもっと高いでしょう。

収益に直結するeコマースシステムにとって、クエリエラー率が4回に1回というのは、反復的に解決できるようなチューニングの問題ではなく、このアプローチにおけるアーキテクチャー上の制約です。

セキュリティギャップ

LLMがデータベーススキーマにアクセスし、クエリ作成者として動作する場合、システムは間接的なプロンプトインジェクションに対して脆弱になります。eコマースチャットボットと対話するユーザーは、エージェントを操作して意図しないクエリを生成するように設計されたインプットを作成できます。

これは理論上のリスクではありません。プロンプトインジェクションは、デプロイされたLLMシステムにおいて最も活発に研究されている攻撃面の1つです。根本的な問題は、エージェントがクエリを作成する際に、ユーザーの意図とクエリ実行の間に構造的な境界がないことです。LLMは、ユーザーの要求を解釈すると同時に、データベース操作を構築します。前者への操作は後者に直接影響します。

高カーディナリティスケーリングの失敗

特定のeコマースフィールドは非常に高カーディナリティです。商品タログには、17,000のカテゴリ値、数千のブランド名、そして数百の属性の組み合わせが含まれている可能性があります。標準的なエージェントワークフローでは、LLMがクエリを構築する際に正しい値を選択できるように、これらの値をコンテキストに注入する必要があります。

これは不可能ともいえるトレードオフを生み出します。具体的には、すべての可能な値を注入する（膨大なコンテキストを消費し、パフォーマンスを低下させる）、サブセットを注入する（そして、エージェントがそのサブセット外の値を参照できないことを受け入れる）、または管理されていない検索にフォールバックすることのいずれかです。これはパート1の核心的な問題に直接つながります。LLMが「オレンジ」を検索し、Elasticsearchがオレンジソーダを返すようであれば、検索エクスペリエンスと同様にチャットエクスペリエンスが低下します。ガバナンスがないため、システムは顧客の意図した解決を強制できません。

クエリに基づいて関連値を動的に取得する方法は既知の代替手段ですが、取得自体が関連値を見落とす可能性があるという、非決定論的なステップが追加されます。さらに、これはすべてのクエリに遅延と複雑さを加えることになります。

アーキテクチャー上の代替案：意図と実行の切り離し

パート1から7で説明されているガバナンスを備えた制御プレーンは、根本的に異なるアプローチを提供します。LLMが最後のクエリを作成する代わりに、LLMの役割は、ユーザーの自然言語インプットから検索する意図文字列を抽出するという1つの明確なタスクに限定されます。

ユーザーは「安い茶色の靴を探しています」と言っています。エージェントの役割はElasticsearchクエリを生成することではなく、検索意図（この場合は「安い茶色の靴」のようなもの）を抽出して制御プレーンに渡すことです。コントロールプレーンは、これまでと同様に、意図文字列を保存済みのポリシーと照合し、カスケード変換によって一致するポリシーを構成、競合を決定論的に解決し、ガバナンスを備えたElasticsearchクエリを生成します。

LLMはインデックスマッピングを一切認識せず、フィールドタイプ、カテゴリ分類、価格設定のしきい値などについては一切認識しません。クエリ句は構築されません。これは、メタデータエアギャップと呼ばれるアーキテクチャ境界の自然言語側で動作し、確率的コンポーネント（LLM）と構造化データレイヤー（スキーマ、ポリシー、クエリ構築）との厳密な分離を意味します。

メタデータのエアギャップが提供するもの

• スキーマの盲点。LLMはデータベーススキーマにアクセスできないため、無効なクエリを生成したり、フィールド名を誤認したり、構造情報を公開するように操作されたりすることはありません。このスキーマはエアギャップの決定論的な側面にのみ存在します。
• 最小限の文脈。何千ものマッピングデータ、ビジネスルール、カテゴリータクソノミーの代わりに、LLMのプロンプトにはペルソナとインテント抽出の指示のみが含まれています。これによりトークンコスト、遅延、コンテキストのロットが劇的に削減されます。
• 決定論的な実行。Elasticsearchに届くすべてのクエリは、LLMによって確率的に生成されたものではなく、人間が精査したポリシーテンプレートを使用して制御プレーンによって構築されます。構文の妥当性は保証されています。意味論的正しさは、パート1から6までで説明された同じ政策フレームワークによって強制されます。
• アーキテクチャーによるセキュリティ。迅速な注入は構造的に効果的でなくなります。ユーザーがエージェントを操作して異常な意図文字列を生成しても、その文字列は保存されたポリシーに照合されます。ポリシーが一致しなければ、クエリは生成されません。エージェントはクエリを作成しないため、ユーザーはエージェントにクエリを作成するように指示することはできません。制御プレーンは指示できるため、決定論的です。

各部分がどのように繋がるか

以下のウォークスルーでは、ガバナンスを備えた制御プレーンがエージェント媒介クエリをどのように処理するかを示します。

ステップ1：ユーザーがエージェントに話しかける

ある購入者がECサイトのチャットボットに「ピーナッツが入っていない安いチョコレートを探しています」と言います。

ステップ2：エージェントが意図を抽出する

LLMの役割は意図の抽出であり、クエリ生成ではありません。最小限のプロンプトで製品の意図を識別するように指示された場合、エージェントは検索意図文字列「ピーナッツなしの安いチョコレート」を生成します。

これは軽量な分類タスクです。LLMは、インデックスマッピング、カテゴリ分類、価格設定ルールなどを必要としません。自然言語を理解する必要がありますが、まさにLLMが得意なことです。

ステップ3：制御プレーンがクエリを制御する

「ピーナッツなしの安いチョコレート」という意図文字列は制御プレーンに渡され、そこでポリシーインデックスと照合されます。3つのポリシーが一致します。

• 「安い」ポリシー（「安い」というキーワードを抽出し、商品カテゴリーに基づいて価格フィルターを適用します）。
• 「チョコレート」ポリシー（検索結果をチョコレートのカテゴリーに限定します）。
• 「なし」否定ポリシー（排除ターゲットを抽出し、must_notフィルターを適用します）。

制御プレーンは、パート3とパート4で説明されているものと同じカスケード変換（優先順位付け、フィールドごとの競合解決、消費されたフレーズの追跡）を通じて、これらのポリシーを適用します。「クリスマスキャンペーン」ポリシーも有効な場合、商品ポリシーと正確に同じように構成されます。これはパート3で説明されている通りで、エージェントの関与はガバナンスモデルを全く変更しません。

ステップ4：管理されたクエリが実行される

制御プレーンは、適切なカテゴリーに制限された「チョコレート」の検索、「安い」ポリシーから導出された価格上限、ピーナッツを含む製品の除外フィルター、適用されるアクティブなキャンペーンブーストなどの面で完全にガバナンスされたElasticsearchクエリを生成します。「チョコレート」ポリシーに経済的最適化の重みも含まれている場合（パート7）、それらも適用されます。マージンブーストは3.0倍に設定されています。これは、「チョコレート」が、小売業者が高利益率の商品を宣伝することで利益を得られる検索クエリであるためです。買い物客に購入履歴がある場合（パート6 ）、パーソナライゼーションシグナルがその上に重ねられます。このクエリは構造上は構文的に妥当であり、ポリシー設計上は意味的に正しいです。

ステップ5：結果はエージェントを通じて返送される

検索結果はエージェントに返され、エージェントはそれをユーザーに会話形式で提示します。返答パスにおけるエージェントの役割は、結果の提示、フォローアップの質問への回答、製品の詳細の提供などです。検索自体は、統制され、決定論的で、説明可能でした。

エージェントが得意なこと（そして得意でないこと）

このアーキテクチャーは、LLMの得意な部分を最大限に活用し、LLMの苦手な部分からシステムを保護します。

LLMは自然言語の意図を理解するのに優れています。「ピーナッツが入っていない安いチョコレートを探しています」は、意図の解析、製品参照の特定、否定の認識などを行う自然言語理解タスクです。LLMはこれを確実に処理できます。なぜなら、これは生成問題ではなく分類問題だからです。出力は短い意図文字列であり、複雑な構造化クエリではありません。

LLMは、複雑な制約の下で正確で構造化された出力を提供することに苦労しています。有効なElasticsearchクエリDSLを生成するには、正確なフィールド名、正しい句のネスト、各フィールドに適したフィルタータイプ、そして数千もの例外的なケースにわたるビジネスルールの一貫した適用が必要です。これらはまさに、決定論的システムが自明に保証する特性であり、確率論的システムが信頼性に欠ける形で保証する特性です。

ガバナンスを備えた制御プレーンは、各コンポーネントを適切な場所、つまり、自然言語側のLLM、クエリ構築側の決定論的ポリシーエンジン、そしてそれらの間のアーキテクチャ境界に配置します。

ガバナンスによる爆発半径の制約

これはパート3と同じ洞察を、エージェントのコンテキストに拡張したものです。パート3では、ガバナンスが検索開始前に候補を絞り込むことでセマンティック検索が安全性が高まることが観察されました。管理対象カテゴリー内の500製品に対するセマンティック検索は、50万SKUに対するセマンティック検索とは根本的に異なる提案です。

同じ原理はエージェントが媒介したクエリにも当てはまります。ガバナンスがなければ、「安いチョコレート」を誤って解釈したエージェントは、価格制約、カテゴリーフィルター、除外条件を一切設けずにカタログ全体を検索するクエリを生成してしまう可能性があります。ガバナンスがあれば、エージェントが不完全な意図文字列を生成した場合でも、制御プレーンはクエリを一致するポリシーに限定します。最悪の場合でも実行されるポリシーの数が減るだけで、無制限のクエリが商品カタログにヒットするわけではありません。

ガバナンスは確率的エラーの爆発範囲を狭めます。これは確率的要素がセマンティック検索モデルであれLLMエージェントであれ、すべて当てはまります。

LLMが提案するポリシー：適用範囲の拡大

第2部では、LLMが人間が作成したポリシーと同じ「作成 → テスト → 昇格」のパイプラインに入る新しいポリシーを提案できるという考え方を紹介しました。主体的な文脈においては、これは強力なフィードバックループとなります。

LLMはクエリログを分析し、制御プレーンに一致するポリシーがないパターン（変更されずに取得されるクエリ）を特定し、それらのギャップを埋めるための新しいポリシーを提案することができます。マーチャンダイザーは、各提案を検討し、テストし、期待される行動を生み出すものであれば、それを昇格します。このガバナンスモデルにより、LLMが提案するポリシーが人間の検証なしに本番環境に移行することは決してありません。

時間が経つにつれて、これは好循環を生み出します。制御プレーンのポリシーの対象範囲が拡大し、変更されていない取得を必要とするクエリの割合が減少し、システムの管理が次第に強化され、すべてのポリシーが監査、バージョン管理され、個別に元に戻せるようになります。

より広範なパターン：確率的システムのための決定論的ガードレール

このシリーズで説明されているアーキテクチャーは、確率的な入力ソースとデータ検索システムの間にある決定論的制御プレーンですが、これはeコマース検索に特化したものではありません。同じパターンは、AIエージェントが構造化データとやり取りする必要があるすべての場所に当てはまります。

SQLデータベースにクエリを実行するエージェントも、スキーマインジェクションによるコンテキストの肥大化、誤った列名、プロンプトインジェクションのリスク、高カーディナリティ値の選択といった同様の課題に直面します。Jiraのようなチケットシステム、Salesforceのような顧客関係管理（CRM）システム、またはGitHubのようなコードリポジトリとやり取りするエージェントも同様の問題に直面しています。いずれの場合も、アーキテクチャー上の根本的な問題は同じです。LLMがクエリを作成すべきか、それともLLMが意図を抽出し、それをクエリを作成する決定論的なレイヤーに渡すべきか、ということです。

制御プレーンは、その問いに対して再現性のある答えを提供します。ポリシーはデータであり、意図の抽出はLLMの仕事です。クエリの構築は制御プレーンの役割です。メタデータのエアギャップによって、それらは分離されたままとなります。また、ガバナンスフレームワーク（優先順位付け、競合の解決、段階的な変換、監査可能性）により、ポリシーの数が増加しても、決定論的レイヤーが運用上管理可能であることが保証されます。

まとめ

本シリーズで説明するeコマース検索ガバナンスパターン（データとしてのポリシー、作成 → テスト → 昇格のワークフロー、カスケード変換、フィールドごとの競合解決、パーコレーターベースの逆マッチング、マルチティアフォールバック）は、マーチャンダイザーがポリシーを作成し、購入者がクエリを入力する世界を想定して設計されています。しかし、このアーキテクチャーは、当初のユースケース以上のことを可能にします。

入力ソースが人間の購入者ではなくAIエージェントである場合、ガバナンスを備えた制御プレーンは、確率論的システムと本番環境のデータ格納レイヤーの間の重要な安全レイヤーとなります。これは、エンタープライズシステムが要求する決定論的な保証（構文の妥当性、意味の正しさ、監査可能性、セキュリティ）を提供するものであり、LLM単独では提供できないものです。

決定論的な制御プレーンはAIエージェントの代わりにはなりません。これにより、AIエージェントを安全に展開できるようになります。

ガバナンスを備えたeコマース検索を実践

このシリーズで説明されているガバナンスを備えた制御プレーンアーキテクチャーは、「データとしてのポリシー」パラダイムからパーコレーターベースのルックアップ、パーソナライゼーション、経済的最適化、そしてエージェンティックエアギャップに至るまで、Elastic Services Engineeringによって設計および構築されました。このシリーズで説明されているすべてのパターンは、企業規模の商品カタログに対して構築され、検証済みの実際のシステムから得られたものです。

チームがAIを利用した検索体験を構築し、エージェントが仲介するクエリに対して決定論的なガードレールが必要な場合、またはElasticsearch上で管理された、ビジネスで編集可能な検索アーキテクチャを実装したい場合は、Elastic Professional Servicesが実装を加速できます。Elastic Professional Servicesにお問い合わせください。

議論に参加

検索ガバナンス、検索戦略、またはeコマース検索アーキテクチャについてご質問がありますか？より広範なElasticコミュニティの議論に参加しましょう。