AI検索・RAG

Query Rewriting vs Query Decomposition、検索クエリはどう変えるべきでしょうか？

Query Rewritingは、1つの情報要求を検索システムが理解しやすい表現に言い換える方法であり、Query Decompositionは、複数の事実やステップが絡み合った質問を回答可能な下位質問に分解する方法です。

3行要約

Query Rewritingは元の質問の目的を保ちながら、検索語・エンティティ・文脈をより明確にし、Query Decompositionは複数段階の根拠が必要な質問を下位質問に分けます。
短く曖昧な質問には書き換えが、比較・計算・時間順のように根拠が相互依存する質問には分解がより適している場合があります。
元の質問、変更後のクエリ、取得文書、最終回答を一緒に保存し、正解根拠の取得・意味の保持・遅延・コストで両方式を比較する必要があります。

この2つの方式は何を変えるのでしょうか？

Query Rewritingはユーザーの情報要求を1つに保ちます。誤字を修正し、代名詞を実際のエンティティに置き換えたり、会話の文脈を短い独立したクエリに圧縮したりできます。検索エンジンがよく理解する表現を加えて、クエリと文書の間の単語の差を減らすことも書き換えに含まれます。

Query Decompositionは質問の中にある複数の問題を分けます。AとBの最近の価格と返金条件を比較してなら、各製品の最新価格、それぞれの返金条件と適用国を別々の下位質問として作れます。答えを統合するときは、どの根拠がどの下位質問に使われたのかを残しておく必要があります。

区分	Query Rewriting	Query Decomposition
目的	同じ情報要求をよりよく検索する	複合的な要求を答えられる単位に分ける
出力	通常は1つ、または複数の代替クエリ	順序・依存関係のある下位質問
適した問題	曖昧な表現・誤字・会話の文脈	比較・多段階検索・計算・条件の結合
主なリスク	元の意味が変わる	不足したステップ・誤った順序・エラーの伝播
必要なログ	原文・再作成文・選択理由	下位質問・依存関係・合成根拠

複合性比較基準

ユーザーがそれ、返金できる？と尋ね、会話に製品名と国がすでにあるなら、独立した質問として整理するだけで十分な場合があります。略語を正式名称に展開したり、文書で使われる用語を追加したりすることも検索結果の改善につながります。Ma らの Rewrite-Retrieve-Read 研究は、検索器と読み取りモデルの間のギャップを質問再作成の観点から扱っています。

再作成モデルがもっともらしい詳細条件を作り出さないようにしなければなりません。ユーザーが国や日付を述べていないのに勝手に入れると、より正確に見える誤答になります。不足している条件は質問に戻して聞き返すか、複数の候補で検索し、仮定であることを回答に残します。

まず4つを確認します。

人名・製品・組織を会話文脈の中で正確に解消できているか見ます。
否定表現、日付・国・バージョンと数値が原文どおり保持されているか確認します。
追加した同義語が実際の文書で同じ意味で使われているか検査します。
原文検索よりも、正答の根拠が上位候補により頻繁に入るか比較します。

Query Decomposition はいつ必要でしょうか？

1回の検索では答えられない多段階質問が対象です。Press らの Self-Ask 研究は、モデルが後続質問を明示的に作成し、検索エンジンを接続する構成を扱いました。IRCoT 研究は、これまでに取得し推論した内容によって次に何を検索するかが変わる多段階質問で、検索と推論を交互に実行します。

すべての長文を分解する必要はありません。ユーザーの要求が複数あっても、それぞれが独立していれば並列検索で十分です。一方、最初の回答で見つけた会社名や日付が次の質問の条件になるなら、依存関係と実行順序を残しておく必要があります。

Query Rewriting と Query Decomposition の違い

最初の下位質問の誤った答えを次の質問に入れると、誤りが連鎖的に大きくなります。質問を細かく分けすぎると、各断片から本来の比較基準と対象範囲が失われます。答えのない下位質問をモデルが推測で埋め、最終文を自然に統合してしまう危険もあります。

失敗場面	原因	制御方法	確認ログ
原文条件の欠落	分解プロンプトが範囲を省略	共通制約をすべての下位質問に伝達する	条件保持の検査
最初の誤答が後続に伝播する	逐次依存性	根拠を確認してから次のステップを実行する	ステップごとの文書・回答
下位質問の過剰	中断ルールがない	最大件数・時間・トークン上限	実行ステップ数
異なるバージョンの混在	時間フィルタの欠落	適用日・バージョンフィールドの固定	文書メタデータ
合成回答と根拠の不一致	出典連結の断絶	主張ごとの下位回答・引用の連結	最終引用マップ

Least-to-Most研究は、複雑な問題をより単純な下位問題に分解し、順序立てて解く戦略を示していますが、特定のデータセットの結果をすべての検索サービス性能に一般化することはできません。実際の社内文書と顧客質問で、基準線を再構築する必要があります。

2つの方式を併用してもよいですか？

複合質問を先に分解し、各下位質問を検索用に再作成できます。逆に、会話の文脈を1つの独立した質問に再作成してから、複合性が確認された場合にのみ分解することもできます。どちらの順序でもモデル呼び出し回数と失敗箇所が増えるため、単純な質問は高速経路に迂回させます。

運用では、質問分類ルールを先に設けます。エンティティが1つで根拠も1つなら再作成までにとどめ、2つ以上の独立した根拠と比較・計算が必要なら分解候補に送ります。答えを見つけられない質問は、より多くの検索ではなく根拠なしで終了できるようにすべきです。

Query RewritingとQuery Decompositionの違い

再書き換えは、元の文の意味を保ちつつ、正解ドキュメントの回収率を改善できているかを見ます。分解は、必要な下位質問を漏れなく作れているか、順序と共通条件が合っているか、最終回答が各根拠と一致しているかを見ます。1つの回答スコアだけで評価すると、検索は改善していても合成が誤っているケースを見落とします。

単純RAG、再書き換え、分解、結合の4条件を同じ質問セットで試します。正解根拠が上位候補に含まれる比率、根拠のない主張、P95遅延、トークン数と検索呼び出し数をあわせて記録します。複雑な方式は、複合質問グループでのみ効果が確認できた場合に適用します。

公開ウェブサイトでは、何を先に整えるべきでしょうか？

SEO記録には、Query RewritingとQuery Decompositionの品質評価が、露出・クリックに与えた影響を残します。GEO記録には、クエリ出力がAI回答の言及・引用と結びついた場面を別途残し、2つの結果を無理に統合しません。

クエリをうまく変えても、元ページの製品名・日付・適用範囲と例外が曖昧なら、回答は改善しません。公開HTMLに重要情報があり、代表URLとcanonicalが明確で、関連ページが内部リンクでつながっている必要があります。そうして初めて、検索段階が安定します。

この運用方法は、既存のウェブサイトを維持したまま、実際の顧客質問と公開ページの間にあるギャップを見つけます。どの質問なら既存の代表URLで答えられるか、どこでドキュメントとエンティティの関係が切れるか、AI回答がどの公開根拠を引用しているかを診断します。Query Rewriting・Decompositionエンジンの構築そのものを先行条件にはしません。

Query RewritingとQuery Decompositionの並行運用における実際の判断

Query RewritingとQuery Decompositionのどちらかを先に選ぶのではなく、情報要求、クエリ出力、複合性項目の基準値を作ります。この値がなければ、修正前後を比較できず、担当者が変わるたびに同じ診断を繰り返すことになります。影響の大きいURLと質問を少数選び、誰がどの値をいつ修正したかを残します。

Query RewritingとQuery Decompositionの条件保持項目も、全体平均だけでは見ません。新しく修正したページ、そのまま残したページ、季節性の影響を受けるページを分けてこそ、差が見えてきます。結果が予想と異なる場合は、新規ページを増やす前に、原文不足、技術的ブロック、外部情報との測定ギャップを確認します。

参考資料

検索・RAG構造を続けて見るなら

Query RewritingとQuery Decomposition比較後のSearch OS運用

Search OS導入の出発点は、サイトの入れ替えではありません。Query RewritingとQuery Decompositionの比較で確認すべき品質評価、情報要求項目を、現在のウェブサイト上で測定し、コンテンツ・技術・外部情報のうち詰まっている部分だけを改善します。

内部成果集計基準では、Search OSを適用した顧客企業はSEOとAI検索露出が平均88%以上増加しました。その後は、Query RewritingとQuery Decompositionの比較に使った検索とAI回答を同じ周期で読み直します。改善した状態をベースラインにし、逸脱が生じたURLを先に修正して、最良の露出状態が継続するよう管理します。