「RAG（検索拡張生成）を導入したのに、ユーザーからの『〇〇と△△の違いは？』というような複合的な質問にうまく答えられない」という課題に直面するケースは珍しくありません。社内ドキュメントやベクトル検索の仕組みが十分に揃っていても、複雑な質問になるとAIがうまく情報を抽出できず、もっともらしい嘘（ハルシネーション）をついたり、「情報が見つかりません」と回答したりすることがあります。
これは、RAG自体の精度というよりは、「質問の解像度」と「検索の粒度」のミスマッチが原因であることが多いと考えられます。人間であれば無意識に行う「複雑な質問を複数の要素に噛み砕いて、それぞれの情報を突き合わせる」というプロセスを、従来の単純なRAGシステムは非常に苦手としています。
本記事では、プロジェクトマネジメントの観点から、この課題を解決するための実践的なアプローチを解説します。複雑な質問を処理する仕組みとして、以前はLlamaIndexの「Sub Question Query Engine（サブ質問クエリエンジン）」のような専用機能が広く用いられてきました。しかし、AI技術の急速な進化に伴い、現在ではより柔軟な「エージェント型チャンキング」や、汎用的なエージェント機能を用いた推論の自動分解へとアプローチが移行しつつあります。旧来の機能に依存した実装は非推奨となる可能性があるため、最新の実装方法や移行手順については、LlamaIndexの公式ドキュメントで最新情報を確認することが推奨されます。
単なる概念の解説にとどまらず、実際の開発プロジェクトで多くのエンジニアが直面する「推論の暴走」や「APIコストの増大」といったよくある課題と、それらを最新のエンジニアリング手法でどう乗り越えていくべきか、具体的なステップを共有します。この記事が、既存のRAGシステムをより「賢く、実用的なアシスタント」へと進化させ、ROI（投資対効果）を最大化するための実践的なヒントになれば幸いです。
プロジェクト背景：CS部門が直面した「単純検索」の限界
多くのB2B SaaS企業において、カスタマーサポート（CS）の効率化は喫緊の課題です。社内マニュアルや過去の問い合わせ履歴を検索できるRAG（検索拡張生成）システムの導入は有効な解決策ですが、単純な実装では現場の要求を満たせないケースが後を絶ちません。ここでは、多くの組織が直面する構造的な課題と、なぜ従来の「単純検索」では限界があるのかを論理的に解説します。
組織が抱える課題：マニュアル分散問題
急速なM&Aや事業拡大を経た組織では、製品ごとにドキュメントの形式も保管場所もバラバラになっていることが珍しくありません。
例えば、特定の製品の仕様書は最新の多機能ワークスペースツール（Notion等）で管理され、別の製品はPDFマニュアル、古い製品はレガシーなHTMLサイトで管理されているといった状況です。Notionなどの最新ツールは、情報アクセスの動線を整理するUIの改善や、Claude、Geminiといった強力なAIモデルの統合、さらには外部アプリケーションとの連携強化により、ツール単体での検索性や利便性を飛躍的に高めています。しかし、組織全体という広い視野で見ると、依然として各システム間に壁が存在し、情報がサイロ化しているため、横断的な検索が困難なケースが多く見られます。
オペレーターは顧客から「製品Aと製品B、どちらがセキュリティ機能に優れていますか？」と聞かれるたびに、複数のツールを行き来し、それぞれのドキュメントを目視で確認し、脳内で比較して回答を作成する必要があります。これには製品仕様に対する深い理解と熟練の技が必要であり、新人教育における大きなボトルネックとなりがちです。
こうした属人的な負荷を下げるためにRAGシステムが導入されますが、初期段階では現場の期待と実際の精度に大きな乖離が生まれるという課題に直面します。
初期の導入時によくある失敗：回答精度の停滞
「特定の製品のパスワード設定方法は？」といった単一の情報源で完結する質問（Single Hop Query）に対しては、AIは高い精度で素早く回答できます。しかし、CSの現場で本当に求められているのは、「比較」や「複合条件」を含む複雑な質問への対応です。
従来のRAG（Naive RAG）のアプローチは、一般的に以下のようなプロセスをたどります。
ユーザーの質問文をベクトル化し、システム内からそれに近い意味を持つドキュメントの断片（チャンク）を上位数件取得してLLMに渡す、というものです。
このシンプルな仕組みで「製品Aと製品Bのセキュリティ比較」と検索した場合、運良く「比較表」のようなドキュメントが存在しない限り、システムは「製品Aのセキュリティ」か「製品Bのセキュリティ」のどちらか一方、あるいは関連性の低い「一般的なセキュリティポリシー」の文書ばかりを取得してしまう傾向があります。結果として、AIは片方の情報だけで偏った回答を生成し、不完全な、あるいは誤った情報を自信満々に語る「ハルシネーション」を引き起こしてしまうのです。
ユーザーの質問は常に「複合的」である
実際のCS現場における問い合わせログを分析すると、実務的な質問の多くが、複数の情報源をまたぐ「Multi Hop Query（多段階推論が必要なクエリ）」であることが分かります。
- 「スタンダードプランでAPI連携機能を使う場合の制限事項は？」
- 「先月のアップデートで変更された仕様と、旧仕様の互換性は？」
これらは、単一のドキュメントチャンクには直接的な答えが書かれていません。正確に回答するためには、「プラン仕様書」と「機能解説書」、あるいは「新旧のリリースノート」の両方を読み込み、情報を突き合わせるという作業が不可欠です。
近年、Amazon Bedrockなどの主要なクラウド基盤において、知識グラフを活用したGraphRAGのサポートがプレビュー段階で進められるなど、より高度な情報検索と推論を実現する技術への注目が高まっています。こうした最新のRAGトレンドやエージェント型アプローチへの移行が示唆するように、複雑な問い合わせを解決するために必要なのは、単なる検索アルゴリズムの微調整（リランク手法の追加や埋め込みモデルの変更）だけではありません。「推論プロセスそのもの」を体系的に再設計し、AIが自律的に複数の情報を収集・統合・比較できる仕組みが求められているのです。
解決策の検討：なぜ「Sub Question Query Engine」だったのか
複合質問に対する課題解決において、多くのプロジェクトではいくつかの技術的アプローチが比較検討されます。最適なアーキテクチャを選定する過程でよく議論される3つの主要なアプローチと、それぞれの判断理由を整理します。
比較検討した3つのアプローチ
コンテキストウィンドウの拡大と全ドキュメント投入
LLMのコンテキスト長（一度に処理できる情報量）が拡大していることを利用し、関連しそうなドキュメントを大量にプロンプトに詰め込む方法です。- 課題と限界: 昨今のAIモデルの進化は著しく、例えばOpenAI APIではGPT-4o等のレガシーモデルが2026年2月に廃止され、長い文脈理解や汎用知能が大幅に向上したGPT-5.2（InstantやThinking）が新たな標準モデルへ移行しています。こうした最新モデルでは長大なコンテキストを容易に扱えますが、API呼び出し時のトークン消費によるコストが膨大になる点は無視できません。さらに、どれほどモデルが進化しても「Lost in the Middle」現象（長い文章の中間にある情報を忘れたり見落としたりする傾向）のリスクは依然として残り、業務利用に求められる精度の安定性に欠けるという課題があります。旧モデルの廃止に伴い、より高度な推論が可能になった新モデルへ移行したとしても、全ドキュメントを単純に投入するアプローチにはコストと精度の両面で限界が存在します。
Chain of Thought (CoT) プロンプトによる誘導
プロンプトで「ステップバイステップで考えて」と指示し、AIに自律的に検索を行わせるアプローチです。現在では自律型エージェントの基礎として一般的になっています。- 懸念点: 柔軟性は非常に高いものの、完全に制御することが難しく、回答までの時間が予測できない（レイテンシーの問題）という課題があります。特に業務マニュアルのような正確性が求められるシーンでは、AIの「思考」による揺らぎはビジネス上の大きなリスクとなります。
LlamaIndexのSub Question Query Engine
複雑な質問を、事前に定義されたデータソースに対して具体的な「サブ質問」に分解し、それぞれの回答を得てから最終回答を合成する手法です。- 有効な理由: 構造的でデバッグがしやすく、並列処理による高速化が見込める点が挙げられます。そして何より、「どのドキュメントを見て何を調べたか」というプロセスが明確になる点が、実務導入における大きな利点となります。
LlamaIndex採用の決め手となった「分解力」
Sub Question Query Engineの最大の魅力は、その名の通り「問いを分解する（Decompose）」能力にあります。
例えば、「製品XとYの料金体系の違いを教えて」という質問に対し、このエンジンは内部で以下のように動作します。
- 分解:
- サブ質問1: 「製品Xの料金体系は？」（対象ツール: 製品Xドキュメント）
- サブ質問2: 「製品Yの料金体系は？」（対象ツール: 製品Yドキュメント）
- 実行: それぞれの検索エンジンに対してクエリを発行し、個別の回答を得る。
- 統合: 「Xは月額固定、Yは従量課金です。したがって違いは…」と最終的な回答を合成する。
このプロセスは、優秀なオペレーターが脳内で行っている作業そのものです。この「思考の型」をシステムに実装することが、精度の高いRAG構築の鍵となります。最新のAIモデルが持つ強力な推論能力を、自由なテキスト生成ではなく「構造的な分解」に集中させることで、ハルシネーション（もっともらしい嘘）のリスクを最小限に抑え、信頼性の高いシステムを実現できます。
参考リンク
実装の軌跡：複雑な問いを「解ける単位」にバラす技術
採用が決まれば、次は実装です。しかし、単に導入して終わりというわけにはいきません。実用的なシステムを構築するための具体的なステップを見ていきましょう。
データ構造の再設計：メタデータの重要性
まず着手すべきは、インデックス（索引）の再構築です。Sub Question Query Engineを機能させるには、AIが「どの質問にはどのデータソースを使うべきか」を判断できるようにする必要があります。
LlamaIndexの QueryEngineTool を使用し、各製品のドキュメントセットを独立した「ツール」として定義することが一般的です。ここで最も重要なのが、各ツールに付与する description（説明文）です。
# 悪い例
description="製品Xのドキュメント"
# 良い例
description="製品Xの仕様、料金、セットアップ方法、トラブルシューティングに関する詳細情報が含まれています。製品Xに関する具体的な質問に答える際に使用します。"
この説明文がAIにとっての「マニュアル」になります。ここが曖昧だと、AIは適切な分解ができません。現場の担当者と協力し、各ドキュメント群に何が含まれているかを正確に言語化する作業に時間を割くことが、プロジェクト成功の鍵となります。
質問分解ロジックのチューニング
実装当初、AIは過剰に質問を分解する傾向が見られることがあります。「製品Xについて教えて」という漠然とした質問に対し、「製品Xの機能は？」「価格は？」「歴史は？」「社長は？」…と、無数のサブ質問を生成してしまうケースです。
これでは応答時間が長引くだけです。プロンプトテンプレートをカスタマイズし、「ユーザーの質問に答えるために必要最小限のサブ質問のみを生成すること」という制約を加えるアプローチが有効です。
「見当違いなサブ質問」をどう防ぐか
また、文脈を無視した分解が発生することもあります。例えば「製品Xの解約方法」を聞かれているのに、「製品Xの入会方法」まで調べてしまうようなケースです。
これに対しては、LlamaIndexの QuestionGenerator クラスの設定を見直し、生成されたサブ質問が元の質問の意図から逸脱していないかをチェックする簡易的な検証ロジックを挟むことで対処できます。こうした地道な調整が、実用化に向けた重要なステップとなります。
直面した壁と克服：推論の暴走とコスト管理
プロトタイプが動き出しても、実運用に向けたテストフェーズでは、「コスト」と「レイテンシー（応答速度）」という2つの大きな壁にぶつかることがよくあります。
サブ質問が多すぎてトークン課金が急増
Sub Question Query Engineは、1つの質問に対して複数のサブ質問を生成し、それぞれでLLMを呼び出します。単純計算で、APIコールの回数が数倍に膨れ上がるのです。
運用中にAPI利用料が急増する事態が発生するケースがあります。ログを確認すると、1つの質問に対して10個以上のサブ質問が生成され、それぞれが長文のドキュメントを読み込んでいることがあります。
対策：
生成プロンプト自体に (最大3つまで) という強い制約を加えることが効果的です。また、明らかに回答が不要なサブ質問（例えば挨拶や相槌に対する分解）を行わないよう、前段に「質問の複雑度判定」を行う軽量な分類器（小型モデル）を配置するアーキテクチャも推奨されます。
回答生成までのレイテンシー問題
ユーザーが質問してから回答が表示されるまで、平均で15秒以上かかってしまうことがあります。CSの現場で15秒の沈黙は致命的です。
対策1：並列処理（Async）
Pythonの asyncio を活用し、分解されたサブ質問を直列ではなく並列で実行するように最適化します。これにより、サブ質問がいくつあっても、最も遅いクエリの処理時間＋統合処理時間まで短縮することが可能です。
対策2：ストリーミングとUXの工夫
それでも数秒の待ちは発生します。そこで技術的な解決だけでなく、UX（ユーザー体験）での解決を図ることも重要です。
回答を待つ間、「製品Xのデータを検索中...」「製品Yと比較しています...」といった思考プロセス（Thought Process）をリアルタイムで画面に表示する仕組みを取り入れます。
これにより、ユーザーは「待たされている」のではなく「AIが調べてくれている」と感じるようになり、体感的な待ち時間のストレスが激減します。さらに、この表示は「AIが意図を理解して調べている」という信頼感の醸成にも繋がります。
導入成果：回答精度90%超えとCSチームの変化
適切なチューニングを経てシステムが本番稼働を迎えると、その成果は数字にも現場の声にもはっきりと表れます。
定量的成果：解決率とエスカレーション率の推移
適切に導入されたケースでは、複雑な質問に対する一次解決率が大幅に向上し、90%を超える成果を上げることもあります。特に「比較質問」や「仕様の組み合わせ」に関する正答率は劇的に改善する傾向にあります。
また、新人オペレーターからシニアメンバーへのエスカレーション（質問・相談）の件数が大幅に削減される事例も多く報告されています。これは、新人がAIを使って自己解決できる範囲が広がったことを意味します。
定性的変化：オペレーターの安心感
現場からは以下のような声が聞かれることが多くあります。
「以前のAIは、答えが合っているかどうかわからなくて不安だった。でも今のAIは『〇〇のマニュアルの第3章を参照しました』と根拠を出してくれるし、AとBを調べて比較したという過程が見えるので、自信を持ってお客様に回答できる。」
Sub Question Query Engineの副次的な効果として、「回答の透明性（Explainability）」が高まることが挙げられます。AIがブラックボックスではなくなり、オペレーターの頼れる相棒としての地位を確立できるのです。
テックリードからの提言：RAGを「賢く」するために必要なこと
「精度の高いRAG」を構築するためには、単なるツールの導入にとどまらない本質的な要件を満たす必要があります。もし複合的な質問への対応という課題に直面しているなら、プロジェクトマネジメントの視点から以下の3点を意識してみてください。
1. ツール導入の前にデータを整理せよ
Sub Question Query Engineは強力ですが、魔法の杖ではありません。元となるデータのメタデータ（説明文）が不正確であれば、どんなに高度な推論エンジンも機能しません。ディレクトリ構造、ファイル名、そして各データソースが「何について書かれたものか」を定義する作業こそが、エンジニアリングの第一歩です。最近ではエージェント型チャンキングや非構造化データ接続といった高度な手法も注目されていますが、その基盤となるのはやはり整理されたクリーンなデータです。
2. 「銀の弾丸」はない：ユースケースの見極め
全ての質問にこの推論エンジンを使う必要はありません。単純なFAQ検索にこれを使うと、遅くてコストがかさむだけのシステムになってしまいます。多くのケースで有効なのは、ルーター（Router）を導入し、質問の難易度に応じて「単純なベクトル検索」と「Sub Question Query Engine」を適切に使い分けるアーキテクチャです。LlamaIndexなどのフレームワークを活用する際は、公式ドキュメントで最新のルーティング手法や推奨構成を定期的に確認することをおすすめします。ROIを意識した適切な技術選定が不可欠です。
3. 今後の展望：自律型エージェントへの布石
質問を分解して答えを導き出すプロセスは、まさに今注目されている「Agentic RAG（自律型RAG）」の第一歩と言えます。今後は、単に静的なドキュメントを検索するだけでなく、APIを叩いてリアルタイムのサーバー稼働状況を確認したり、ユーザーの契約情報をデータベースから引いてきたりといった、より動的なアクションを含む推論へと進化していくでしょう。
まとめ
「AとBの違いは？」という一見シンプルな問い。それに答えるために、人間は瞬時に複雑な情報処理を行っています。AIに同じことをさせるには、その思考プロセスを論理的かつ体系的に設計し、技術に落とし込む必要があります。
Sub Question Query Engineは、そのための強力なフレームワークです。しかし、それを真に使いこなすのは、人間の「設計力」と、現場の課題に向き合う実践的なアプローチに他なりません。
RAGシステムが単なる検索窓から、真に頼れるパートナーへと進化し、ビジネス上の価値を最大化するためには、こうした推論プロセスの最適化が不可欠です。本記事の解説が、より高度なAIシステム構築の一助となれば幸いです。
コメント