イントロダクション：RAG開発の「80%の壁」とは
「PoC（概念実証）では素晴らしい回答精度が出たのに、本番データを投入した途端、AIがもっともらしい嘘をつくようになった」
これは、多くの企業がAI導入を行う際に直面する典型的な課題です。初期段階では限られたドキュメントでテストを行い、RAG（検索拡張生成）の効果を実感できます。しかし、ドキュメント数が数千、数万と増え、社内の複雑な規定集や技術仕様書が混在し始めたとき、多くのプロジェクトが「回答精度80%の壁」にぶつかります。
残りの20%を埋めるために、プロンプトを調整したり、LLM（大規模言語モデル）を最新のものに切り替えたりする試みがなされますが、それだけでは構造的な課題解決に至らないケースが少なくありません。
本日は、ITソリューション企業の技術ディレクターとして、システム受託開発やAI導入コンサルティングの現場で培った視点から、この問題の現実的な解決策について解説します。鍵を握るのは「LlamaIndex」を単なるデータローダーとしてではなく、高度な「データ構造の設計フレームワーク」として使いこなすことです。
多くのエンジニアが「とりあえずベクトル検索（Vector Store）に入れておけばいい」と考えがちですが、データの特性に合わせてインデックス構造を設計し、検索戦略（Retrieval Strategy）を最適化することが重要です。これこそが、実用的なAIシステムを構築し、費用対効果を高めるための確実な道と言えます。
今回は、具体的な実践アプローチを交えながら、LlamaIndexを用いたインデックス構造の最適化について深掘りしていきます。
Q1: なぜ「VectorStoreIndex一択」では失敗するのか？
インタビュアー（以下、I）： まず単刀直入にお伺いします。現在、RAG構築といえば「ドキュメントをチャンク分割して、ベクトル化して、Vector DBに入れる」というのが定石になっています。LlamaIndexでも VectorStoreIndex がデフォルトのような扱いですが、これだけでは不十分なのでしょうか？
田中健太（以下、田中）： 不十分どころか、特定のユースケースでは逆効果になることすらあります。VectorStoreIndexは「雰囲気で探す」のは得意ですが、「正確に特定する」のは苦手な傾向があるためです。
I： 「雰囲気」ですか？ ベクトル検索は意味を理解する技術だと思っていましたが。
田中： ええ、確かに「意味（Semantic）」を捉えます。OpenAIなどの最新の埋め込みモデル（Embeddings）を使えば、「美味しい果物」と検索して「リンゴ」や「ミカン」のドキュメントを見つけるのは得意です。しかし、ビジネス文書の世界ではどうでしょう？
例えば、製造業の現場で「製品Aのバージョン2.1の仕様」と「製品Aのバージョン2.2の仕様」があったと仮定します。これらはベクトル空間上では極めて近い位置に存在する可能性があります。単語の並びも意味も酷似しているためです。しかし、エンジニアが知りたいのはその「僅かな差異」です。VectorStoreIndexだけに頼ると、AIはバージョン2.1のデータを拾ってきて、「バージョン2.2の仕様です」と回答してしまうリスクがあります。これがハルシネーション（幻覚）の原因の一つです。
I： なるほど。数値や固有名詞の厳密な区別が苦手なんですね。
田中： その通りです。それに、情報の「文脈（Context）」が失われる問題も深刻です。一般的なベクトル検索では、ドキュメントを細切れのチャンク（断片）にしますよね。例えば一定のトークン数ごとに区切るとします。すると、そのチャンクが「前提条件」なのか「例外事項」なのか、「A案」なのか「B案」なのかという、ドキュメント全体の中での位置付けが消失してしまいます。
結果として、AIは断片的な情報のつぎはぎで回答を作る羽目になります。これでは、人間が読んでも理解できない、あるいは誤解を招くような回答が生成される可能性があります。特に、最近のトレンドであるエージェント的な自律動作をAIに期待する場合、この「文脈の欠如」は致命的です。AIが正しい推論を行うための「地図」がない状態ですから。
I： 確かに、マニュアルの「注意書き」だけが検索にヒットして、それがメインの手順のように回答された経験があります。
田中： まさにそれです。「VectorStoreIndex一択」というのは、図書館に行って本の中身を全部バラバラに切り刻み、床にぶちまけてから、「さあ、ここから探してくれ」と言っているようなものです。LlamaIndexの本質的な価値は、そうやって散らばった情報に、もう一度「構造」という背骨を通す点にあります。
Q2: LlamaIndexの多彩なインデックスをどう使い分けるべきか
I： VectorStoreIndexの限界は理解できました。では、具体的にどうすればいいのでしょうか？ LlamaIndexには他にも SummaryIndex (旧 ListIndex) や TreeIndex、KeywordTableIndex などがありますが、これらはどう使い分けるべきですか？
田中： 良い質問ですね。ここがシステム設計の腕の見せ所です。「データの性質」と「クエリの目的」の2軸で判断することが推奨されます。
1. 網羅性が必要な場合の SummaryIndex
まず、SummaryIndex (旧 ListIndex) ですが、これは「全体像を把握したい」ときに有効です。例えば、「この会議の議事録全体を要約して」とか「取引先との過去3年間の契約内容の変遷を教えて」といった、複数のチャンクにまたがる情報を統合する必要がある場合です。
I： ベクトル検索だと、関連度が高い上位数件（Top-k）しか取ってきませんからね。
田中： そうなんです。Top-k検索では、情報の一部が欠落するリスクが高い。対してSummaryIndexは、リスト構造で連結されているため、LLMに順次データを流し込んで処理させることができます。LlamaIndexの機能を使えば、ドキュメント全体を処理して回答を生成するアプローチが可能です。
2. 精密検索のための KeywordTableIndex
次に KeywordTableIndex。これは、品番、型番、専門用語、人名など、「ピンポイントなキーワード」で検索したい場合に有効です。先ほどの「バージョン2.2の仕様」のようなケースですね。これはキーワード検索（転置インデックス）のアプローチですが、現代のRAGにおいても極めて重要です。
I： 最新のAI技術を使っているのに、古い技術に戻るようで不思議な感覚です。
田中： 技術は螺旋階段のように進化するんです。現在は「ハイブリッド検索」がデファクトスタンダードになりつつありますが、これは「ベクトル検索（意味）」と「キーワード検索（語句）」の組み合わせです。LlamaIndexを使えば、例えば「意味的にはこれに近いけど、必ずこのキーワードを含んでいるもの」というフィルタリングが実装できます。
3. 階層的な問いに答える TreeIndex
そして、TreeIndex は情報を階層構造で管理します。要約の要約を作っていくようなイメージです。大規模なドキュメント群から、抽象度の高い質問（例：「当社のセキュリティポリシーの基本理念は？」）に答える際に、トップダウンで情報を探索できるので効率的です。
I： なるほど。すべてをベクトルにするのではなく、適材適所でインデックスを選ぶ必要があるんですね。
田中： その通りです。高度なRAGシステムの実装において、これらを単独で使うケースは限られます。LlamaIndexの Composable Graph や Router の機能を使い、VectorStoreIndexの上にSummaryIndexを組み合わせたり、クエリに応じて最適なインデックスを動的に選択させたりする複合的な構造が一般的です。これが「80%の壁」を突破する現実的で有効な手段となります。
Q3: 精度を左右する「チャンク戦略」と「階層構造」の設計論
I： インデックスの話が出ましたが、その前段階である「データの切り分け方」、つまりチャンク戦略についても悩んでいるエンジニアが多いです。単純に500文字や1000文字で切るだけではダメなのでしょうか？
田中： それでは「運任せ」になる可能性があります。文章の区切りが、ちょうど意味の区切りと一致するとは限りませんから。文の途中で切れてしまえば、そのチャンクの意味は失われます。
推奨されるのは、「Small-to-Big Retrieval（親子チャンク）」 という戦略です。これは非常に効果的な場合があります。
I： Small-to-Big... 具体的にはどのような仕組みですか？
田中： 検索用には「小さなチャンク（Small Chunk）」を使い、LLMに回答生成用として渡すのは、その周囲を含む「大きなチャンク（Big Chunk）」、あるいは元のドキュメント全体を使うという手法です。
例えば、検索用のチャンクは1文や2文単位（Sentence Window）にします。こうすると、ノイズが減り、ベクトル検索でのヒット率（Recall）が高まります。細かいトピックにフォーカスしているので、クエリとの類似度が高くなりやすいんです。
しかし、それだけだとLLMにとっては文脈が不足します。そこで、検索がヒットしたら、その親（Parent）にあたる大きなテキストブロックを引っ張ってくるんです。
I： なるほど！ 「見つけるためのデータ」と「答えるためのデータ」を分けるわけですね。
田中： その通りです。LlamaIndexでは ParentDocumentRetriever や AutoMergingRetriever といった機能でこれが実装できます。これを入れるだけで、回答の「文脈理解度」が向上する可能性があります。実務の現場では、条文単体ではなく「条文＋解説＋判例」をセットで取得できるようにしたことで、回答精度が向上するケースが多く見られます。
もう一つ重要なのが 「メタデータ」 の活用です。チャンク分割する際に、単にテキストを切るだけでなく、そのチャンクが「どの章にあるか」「発行日はいつか」「対象読者は誰か」といったメタデータを付与します。
LlamaIndexの MetadataReplacementPostProcessor などを使えば、検索時にはメタデータを考慮し、LLMに渡す際にはテキスト本文だけにする、といった制御も可能です。メタデータは、ベクトル空間における「羅針盤」のようなものです。これ無しで航海するのは難しいでしょう。
I： データの「切り方」と「タグ付け」に、もっと注意を払う必要があるということですね。
Q4: 今後のRAGはどう進化するか？自律的エージェントへの布石
I： ここまでインデックス構造とチャンク戦略について伺ってきましたが、これらを組み合わせるとシステムが複雑になりそうです。管理しきれるのでしょうか？
田中： 確かに複雑になります。人間が「この質問にはこのインデックスを使って...」とコードですべて制御するのは限界があります。そこで重要になるのが、「Router Query Engine」 や 「Agentic RAG（エージェント型RAG）」 という概念です。
I： エージェント型RAG、最近よく聞くキーワードですね。
田中： これは必然の進化と言えます。RouterQueryEngine を活用すれば、ユーザーの質問をAIが分析し、「これは要約タスクだからSummaryIndexを使おう」「これは特定の仕様確認だからVectorStoreIndexを使おう」と、動的にツール（インデックス）を選択してくれます。
さらに、最新のLlamaIndexではエージェント機能やワークフロー構築のサポートが強化されており、AIが自分で検索クエリを分解し、複数のインデックスから情報を集め、推論し、情報が不足していれば再検索する、といった自律的な動きが可能になっています。
I： まさにAIが「自分で考え、自分で調べる」ようになるわけですね。
田中： おっしゃる通りです。これからのAIエンジニアに求められるスキルは、単にPythonのコードを書く力よりも、「AIが理解しやすい知識表現（ナレッジグラフや構造化データ）をどう設計するか」 というデータモデリングの領域にシフトしていくと考えられます。
インデックス構造を最適化することは、将来的にAIエージェントが高度な推論を行うための基盤を作る作業でもあります。今のうちにしっかりとしたデータ構造を設計しておけば、モデルやフレームワークが進化すればするほど、その資産価値は高まっていくでしょう。
編集後記：ツールに使われるな、構造を支配せよ
LlamaIndexのようなフレームワークは日々進化を続けており、単なるRAG（検索拡張生成）の構築ツールから、自律的なエージェントや複雑なワークフローを制御するための包括的なデータフレームワークへと役割を広げています。便利な機能が増える一方で、私たちは「数行のコードで実装できること」に満足してしまいがちです。しかし、ビジネスの現場で求められるのは、デモで動くシステムではなく、複雑な現実世界の課題を解決し続ける堅牢なシステムです。
インデックス選定の本質は、常に「ビジネス要件」と「データ特性」の最適な組み合わせにあります。
- 対象データはフロー型（ニュースやチャットログ）か、ストック型（マニュアルや法規制）か？
- ユーザーが求めているのは「全体像の要約」か、「特定の事実の抽出」か？
- 情報の鮮度や更新頻度はどの程度重要か？
- エージェントとして振る舞う際、どのようなツールやデータソースにアクセスさせるべきか？
これらの問いに向き合い、評価（Evaluation）と改善を繰り返すプロセスそのものが、AI活用の強固な基盤となります。LlamaIndexは、その試行錯誤を高速化するための強力な武器です。ツールに使われるのではなく、ツールの特性を深く理解し、データの構造とフローを支配するエンジニアこそが、これからのAI開発をリードしていくでしょう。
もし、RAGシステムの精度が「80%の壁」で停滞しているなら、一度コードから離れ、「データの構造」と「検索戦略」を見直してみてください。そこに、次なるブレイクスルーのヒントがあるはずです。
コメント