導入
「高価なベクトルデータベースを導入し、最新のEmbeddingモデルを採用したのに、思ったような回答が返ってこない」
実務の現場では、このような課題に直面するケースが多く見られます。エンジニアたちはRAG（Retrieval-Augmented Generation）システムの精度向上を目指して、チャンクサイズの調整やメタデータの付与、さらにはリランキング（Re-ranking）の実装など、あらゆる技術的なチューニングを試みています。それでも、ユーザーからの「なんか違う」というフィードバックはなくなりません。
なぜでしょうか？
実は、問題の所在は「検索される側（データベース）」ではなく、「検索する側（ユーザーの入力）」にあることが大半です。システム開発者は、ユーザーが常に論理的で、検索エンジンが理解しやすい完全な質問をしてくれると期待しすぎています。しかし現実のユーザーは、曖昧で、文脈依存で、時には不正確な言葉を使います。
ここで必要になるのが、Query Transformation（クエリ変換）という考え方です。
これは、ユーザーの生の声をそのままデータベースに投げるのではなく、AI（LLM）を介して「検索エンジンが理解できる言葉」に翻訳してから検索を行うアプローチです。いわば、人間とシステムの間に「優秀な通訳」を配置するようなものです。
この記事では、単なるPythonコードの解説ではなく、なぜQuery TransformationがRAGの精度を劇的に変えるのか、そのロジックと設計思想について解説します。表面的なチューニングにとどまらず、システムの本質的な「対話力」を上げるための現実的な設計論を見ていきましょう。
なぜ「ベクトル検索」だけではRAGの精度が頭打ちになるのか
多くのプロジェクトが直面する課題があります。それは「ベクトル検索（Semantic Search）を導入すれば、どんな曖昧な質問にも的確に答えられる」という過度な期待です。確かに、従来のキーワード検索（Lexical Search）と比較すれば、類義語の吸収や表記ゆれへの対応力は飛躍的に向上します。しかし、それだけではどうしても越えられない精度の壁が存在します。
ユーザーの質問は常に「不完全」である
日常的な業務コミュニケーションを想像してみてください。「あの件、どうなった？」「例の資料どこだっけ？」といった、主語や目的語が大きく欠落した会話が当たり前のように交わされています。人間同士であれば、これまでの経緯や共有している文脈があるため、問題なく意思疎通が成立します。
しかし、検索エンジンにはこの「文脈を察する能力」がデフォルトでは備わっていません。ベクトル検索の仕組みは、入力されたテキストを多次元のベクトルに変換し、データベース内のドキュメントベクトルとの類似度（距離）を計算するものです。「あの件」という短いフレーズをベクトル化して検索にかけても、システム側からすれば何を探すべきか判然とせず、ノイズばかりがヒットするのは必然と言えます。
また、ユーザーが自身の知りたい情報を正確な言語で表現できていないケースも珍しくありません。専門的な用語を知らないために抽象的な言葉で検索したり、複数の意図が絡み合った複雑な質問を一つの文に詰め込んだりします。入力されるクエリ（質問）そのものの質が低ければ、裏側でどれだけ高性能な検索エンジンを稼働させても、出力される検索結果の質は向上しません。「Garbage In, Garbage Out（ゴミを入れればゴミが出る）」というデータ処理の基本原則は、RAGにおいても例外ではないのです。
意味検索（Semantic Search）が陥る「類似性の罠」
ベクトル検索の構造的な弱点として、「意味的な類似度が高いこと」と「回答として適切であること」が必ずしも一致しないという現象が挙げられます。
例えば、「2024年の売上報告書はどこ？」という質問を入力したとします。この時、ベクトル検索は「2023年の売上報告書」や「2022年の売上報告書」といった過去の年度のドキュメントを、非常に高い類似度として上位に提示する可能性が高いです。なぜなら、文章の構造や使われている単語が極めて似通っているからです。しかし、ユーザーが求めているのは「特定年度（2024年）」のピンポイントな情報であり、過去の類似情報は正解ではありません。
このように、質問文とドキュメントの「見た目や意味の類似性」が高いものが優先されてしまい、本当に必要な「答えを含んでいるドキュメント」が検索結果の下位に埋もれてしまう事態が頻発します。この課題を根本から解消するためには、検索を実行する前に、質問文そのものを「答えを的確に引き出せる形」へと整形するプロセスが不可欠になります。
インデックスの改善よりもクエリの改善が効く理由
RAGの精度を向上させるアプローチとして、ドキュメント側の前処理（チャンク分割の最適化やクリーニング）を強化したり、より高度なインデックス手法を導入したりすることは確かに有効な選択肢です。最近では、Amazon Bedrock Knowledge BasesにおいてAmazon Neptune Analyticsを活用したGraphRAGのサポート（プレビュー段階）が追加されるなど、知識をグラフ構造で表現して検索精度を高める技術への関心も高まっています。
しかし、こうしたインデックス側の高度化には課題も伴います。一度構築したベクトルデータベースや複雑なグラフ構造を維持・管理し、ドキュメントの更新に合わせて再構築を続けるには、多大な計算コストと運用リソースが必要です。数十万、数百万件のドキュメントに対して高度な前処理をかけ直すのは、決して容易な作業ではありません。また、GraphRAGのような技術は発展途上であり、本番環境での安定運用には最新の公式ドキュメント等で仕様変更を継続的に追跡する体制が求められます。
一方で、クエリ側の処理に目を向けるとどうでしょうか。ユーザーの入力に対して、検索パイプラインを実行する前にLLMで一度推論を挟み、質問の意図を補完・拡張するだけです。この処理にかかるAPIコストやレイテンシ（遅延）の増加はごくわずかであり、システム全体のアーキテクチャや既存のデータベース構造を大きく改修する必要がありません。
技術戦略を策定する際、最も重視すべきは「ROI（投資対効果）」です。大規模なインデックスの再構築という重いアプローチに踏み切る前に、入力パイプラインに「前処理（クエリの正規化や拡張）」を追加するQuery Transformation（クエリ変換）を実装することは、多くのプロジェクトにおいて極めてコストパフォーマンスが高く、即効性のある解決策となります。
AIに「問い直させる」新常識：Query Transformationとは
では、具体的にQuery Transformationとは何をするものなのでしょうか。技術的な定義としては「ユーザーの生のクエリ（Raw Query）を、LLMを用いて検索システムの特性に最適化されたクエリ（Optimized Query）に書き換えるプロセス」となりますが、これは「AIを通訳として使う」というメタファーで考えると非常に分かりやすい概念です。
検索の前にもう一度LLMを挟む逆転の発想
従来の検索システムは、「ユーザー入力 → 検索エンジン」という直接的なパスが一般的でした。これに対し、Query Transformationを導入すると「ユーザー入力 → LLM（通訳） → 検索エンジン」という流れになります。
「検索のためにLLMを使う（RAG）のに、その検索の前段階でもLLMを使うのか？」と驚かれることも珍しくありません。確かに、LLMの呼び出し回数が増えるため、レイテンシー（応答速度）とコストへの懸念はもっともな指摘です。
しかし、現在ではOpenAIの「GPT-5.2 Instant」やMetaの「Llama 3.3」、あるいは日本語処理に優れた「Qwen3」系モデルのような、高速かつ低コストなLLMが登場しています。特に2026年以降、旧世代のモデル（GPT-4oなど）が廃止され、GPT-5.2のような応答速度と推論能力に優れた最新モデルが主流となったことで、このアプローチはより現実的になりました。これらを「通訳」専用に配置することで、オーバーヘッドを最小限に抑えつつ、検索精度を劇的に向上させることが可能です。ここで得られるリターンは、わずかな追加コストを補って余りあるものと言えます。
この「前段のLLM」に求められるのは、複雑な計算や膨大な知識ではありません。ユーザーの乱雑な言葉を整理し、意図を汲み取り、検索エンジン（ベクトルデータベースやキーワード検索エンジン）が最も理解しやすい言葉に翻訳する「言語処理能力」です。
「直訳」ではなく「意訳」して検索エンジンに渡す
優れた通訳者は、話し手の言葉を単語ごとに直訳するのではなく、その意図やニュアンスを汲み取って、聞き手の文化や背景に合わせて「意訳」します。
Query Transformationも同様のプロセスをたどります。例えば、ユーザーが「iPhoneの電池持ちが悪いんだけど、どうすればいい？」と曖昧に質問したと仮定します。これをそのまま検索するのではなく、AIは検索エンジンの特性に合わせて次のようにクエリを変換します。
- キーワード検索用: 「iPhone バッテリー節約 設定方法 手順」
- ベクトル検索用: 「iPhoneのバッテリー消費が早い原因と、設定変更による具体的な改善策を含むトラブルシューティングガイド」
このように、ユーザーの「悩み（Problem）」を、ドキュメントに書かれているであろう「解決策（Solution）のタイトルや見出し」に近い形に変換することで、ベクトル空間でのマッチング率を劇的に高めることができます。
RAGにおける「翻訳者」としてのAIの役割
効果的なRAGシステムにおいて、LLMは明確に異なる二つの役割を持つことになります。
- 前段の翻訳者（Query Transformer）:
ユーザーの曖昧な言葉を、システムが理解可能な検索クエリに翻訳する役割。ここでは「質問の意図」を正確に捉えることが求められます。高速な「GPT-5.2 Instant」や「Llama 3.3」などがこのタスクに最適です。 - 後段の回答者（Response Generator）:
検索結果として得られた事実情報を読み込み、ユーザーへの最終回答を生成する役割。ここでは「情報の統合と要約」が求められます。複雑な推論が必要な場合は「GPT-5.2 Thinking」などの上位モデルが活躍します。
多くのプロジェクトでは、2の「回答者」としてのプロンプトエンジニアリングに注力しがちですが、実は1の「翻訳者」としての設計が、RAGシステムの最終的な品質（回答の的確さ）を大きく左右します。ユーザーとデータベースの間にある「言葉のギャップ」を埋めるのは、ルールベースのプログラムではなく、文脈を深く理解できるAIにしかできない重要な仕事だからです。
実装すべき3つの主要パターンとそのロジック
Query Transformationにはいくつかの定石とも呼べるパターンがあります。ここでは、特に効果が高く、実装の価値がある3つのアプローチについて、そのロジックを解説します。コードを書く前に、まずはこの「思考のアルゴリズム」を理解してください。
曖昧性排除：代名詞の復元と文脈の補完 (Rewrite)
チャットボット形式のRAGで最も頻発するのが、文脈依存の質問です。
ユーザー: 「社内規定について教えて」
AI: 「社内規定のどの部分について知りたいですか？就業規則、経費精算、セキュリティなどがあります。」
ユーザー: 「経費精算のやつ」
この時、2回目の質問「経費精算のやつ」だけをベクトル検索にかけても、まともな結果は得られません。「やつ」が何を指すのか、検索エンジンには分からないからです。
Rewrite（書き換え）ロジックでは、直近の会話履歴（Chat History）と最新の質問をLLMに入力し、「文脈を補完した独立した質問文」を生成させます。
- 入力: 履歴=[...], 質問=「経費精算のやつ」
- 思考: 履歴から「社内規定」の話をしていることが分かる。
- 出力: 「社内規定における経費精算の手順とルールについて教えてください」
このように書き換えられたクエリであれば、単体で検索エンジンに投げても正確にヒットします。これは「Coreference Resolution（共参照解析）」と呼ばれるタスクの応用ですが、LLMを使えば複雑なルールなしで実現可能です。
複雑性分解：Multi-step Queryによる「分けて考える」アプローチ (Decomposition)
「Llamaの最新モデルとChatGPTのアーキテクチャの違いと、それぞれの商用利用の可否を教えて」
このような複合的な質問（Complex Query）は、検索にとって悪夢です。一つのドキュメントにこれら全ての情報がまとまっているとは限らないからです。特にAIモデルの進化は速く、かつてのLlama 2やChatGPTといった旧世代モデルの情報と、最新モデルの情報が混在している場合、検索精度はさらに落ちます。
Decomposition（分解）ロジックでは、複雑な質問を、単純なサブクエリ（Sub-queries）に分解します。
- サブクエリ1: 「Llamaの最新アーキテクチャの特徴は？」
- サブクエリ2: 「ChatGPTのアーキテクチャの特徴は？」
- サブクエリ3: 「Llamaの商用利用ライセンス条件は？」
- サブクエリ4: 「ChatGPTの商用利用規約は？」
これらのサブクエリを個別に検索し、得られた情報を統合して最終的な回答を生成します。人間が難しい問題を解く時に、問題を小さく分割して一つずつ片付けるのと同じアプローチです。「分けて統べる（Divide and Conquer）」は、アルゴリズムの基本にして奥義です。
仮説生成（HyDE）：答えを先に想像してから探す技術
技術的に非常に興味深いアプローチとして挙げられるのが、HyDE (Hypothetical Document Embeddings) という手法です。
通常は「質問」と「ドキュメント」の類似度を見ますが、質問文は短く、ドキュメントは長いため、ベクトル空間上での距離が遠くなることがあります。
HyDEのアプローチは独創的です。検索する前に、LLMに「仮にその質問に対する理想的な回答を作成するとしたらどうなるか」と指示し、仮想のドキュメント（Hypothetical Document）を生成させます。
- 質問: 「パスワードを忘れた場合の手順は？」
- 仮想回答（LLM生成）: 「パスワードを忘れた場合は、ログイン画面の『パスワードをお忘れの方』リンクをクリックし、登録メールアドレスを入力してください。再設定用URLが送信されます...（※これはLLMが学習データから推測した内容）」
そして、この「仮想回答」をベクトル化して検索に使います。実際にヒットさせたいのは「社内マニュアルのパスワードリセット手順」というドキュメントです。質問文よりも、この仮想回答の方が、実際のドキュメントと用語や文体が似ている（ベクトルが近い）可能性が高いため、検索精度が向上します。
「ハルシネーション（事実に基づかない生成）を検索に使うのか？」と思われるかもしれませんが、ここで重要なのは事実の正確さではなく、「どのような単語や文脈が含まれているか」というベクトルの方向性です。HyDEは、質問から答えへの「意味のジャンプ」をAIに補完させる強力な手法です。
自社システムへの適用：導入に向けた設計のステップ
これらの手法は強力ですが、全てを一度に実装する必要はありません。また、すべてのケースで有効なわけでもありません。自社のシステムに最適な手法を選ぶための設計ステップを紹介します。
ユーザーの質問パターンを分析する
まずは現状把握です。検索ログを見て、ユーザーがどのような問いかけをして、どこで失敗しているかを分類してください。
- 代名詞が多い、会話形式が多い: Rewriteが必須です。チャットボット形式なら必須の実装と言えます。
- 比較や分析を求める質問が多い: Decompositionが効果的です。特に、複数の製品や規定を比較するユースケースで威力を発揮します。
- 抽象的な質問や、「〜はどうすればいい？」といったHow-toが多い: HyDEが適しています。解決策が記述されたドキュメントを探すのに役立ちます。
どの変換ロジックが自社の課題に効くか見極める
各手法にはトレードオフがあります。
- Rewrite: 追加のレイテンシーは小。会話の継続性に必須。
- Decomposition: 検索回数が倍増するため、レイテンシーとコストが大。本当に必要な場合のみ適用するか、並列処理で高速化する工夫が必要。
- HyDE: ドキュメント生成に時間がかかる。即答性が求められる場面には不向きかもしれません。
これらを考慮し、「まずはRewriteだけ導入する」「特定のキーワードが含まれる時だけDecompositionを発動させる」といったルーティングの設計を行います。これを「RouterChain」や「Agent」として実装するのが一般的です。
プロンプトエンジニアリングによる「変換指示」のコツ
Query Transformationの核となるのは、LLMへの指示（プロンプト）です。ここでの指示出しが甘いと、変換後のクエリも低品質になります。最新のLLM活用トレンドを踏まえ、以下の3点を意識してください。
- 役割の明確化: 「あなたは検索エンジンのためのクエリ最適化アシスタントです」と定義し、タスクの範囲を限定します。
- Few-Shot + CoT（思考の連鎖）: 単に入力と出力の例を示す（Few-Shot）だけでなく、なぜそのように変換したのかという「思考プロセス」も例示するChain-of-Thought（CoT）を組み合わせるのが、現在のベストプラクティスです。これにより、複雑な意図の解釈精度が向上します。
- 構造化出力（JSON Mode）の活用: 以前は「余計な説明を省いて」と指示していましたが、現在は多くのモデルがJSON形式などの構造化出力に対応しています。出力をJSON形式で指定することで、システム側でのパースエラーを防ぎ、安定した動作を実現できます。
例えばDecompositionなら、「この質問を検索可能な最小単位に分解しなさい」という指示と共に、JSONフォーマットでの出力スキーマを定義することで、LLMはタスクを正確かつシステム的に扱いやすい形で実行します。
検索体験の未来：AIがユーザーの「言わんとすること」を汲み取る時代へ
Query Transformationの実装は、単なる検索精度の向上にとどまりません。それはユーザー体験（UX）の根本的な変革を意味します。
検索窓への入力スキルが不要になる
これまでのシステムは、ユーザーに「検索スキル」を求めていました。適切なキーワードを選び、論理的に構成しなければ、欲しい情報は手に入りませんでした。しかし、Query Transformationを備えたAIシステムは、ユーザーの不器用な言葉、曖昧な表現、断片的な情報を優しく受け止め、裏側で適切に処理してくれます。
「なんか調子悪いんだけど」と呟くだけで、システムが「どのような症状ですか？エラーメッセージは出ていますか？」と聞き返し（あるいは推測し）、適切なトラブルシューティングガイドを提示してくれる。これこそが、私たちが目指すべき次世代のインターフェースです。
対話型検索システムの理想形
私たちは今、静的な「検索」から、動的な「対話」へとパラダイムシフトの渦中にいます。ユーザーは答えを探すために検索するのではなく、課題を解決するために対話します。その対話の中で、AIがユーザーの意図（Intent）を深く理解し、先回りして情報を提供する。
この世界観を実現するためには、データベースのチューニングだけでは不十分です。「問い」そのものをデザインし、最適化するQuery Transformationの視点が不可欠なのです。
次のステップ：実装に向けた準備
ここまで概念とロジックについて解説してきましたが、「実際にどうコードを書けばいいのか」「LangChainやLlamaIndexでどう実装するのか」という疑問が生じるかもしれません。
理論を理解した次は、実践です。しかし、実装を始める前に、具体的なアーキテクチャのパターンや、失敗しないための勘所を把握しておくことで、開発の手戻りを防ぎ、費用対効果の高いシステム構築が可能になります。現場の課題に即した現実的なソリューションを設計するためにも、まずはこの「問いの変換」というアプローチを検討してみてください。
コメント