- 単なる検索から、AIが自律的に情報の出処を判断する『Agentic RAG』へのパラダイムシフト
- 情報の繋がりを捉えるGraphRAGと、HTMLのセマンティック構造化による圧倒的な回答精度の向上
- Long Context時代におけるRAGの役割は、AIへの情報の詰め込みではなく『高精度なノイズ排除』へ
企業向けAI検索の最前線「RAG」の進化と現在
我々の現場でもSharePoint等で構築・運用が一般化しつつある「社内ナレッジ検索」ですが、これはAI技術の領域において RAG（Retrieval-Augmented Generation：検索拡張生成）技術の実践的な最前線にあたります。 今回は、RAGという技術が単なる「外部データのコピペ参照ツール」から、いかに文脈を解釈する「インテリジェント・エコシステム」へと進化してきたのか、その系譜と最新トレンドである Agentic RAG / GraphRAG の概念について深く実環境で検証してまとめました。
なぜこの仕組みが進化し続けるのか？（実機検証の整理）
RAGの進化の歴史を紐解くと、それはそのまま「AIのLLMモデルに対していかにして人間側の文脈（コンテキスト）や図表の意図を正確に理解させるか」の闘いの歴史であることが分かります。
[実機で確認した、RAGアプローチの進化系譜]
graph LR
A["2020-2022: Simple RAG"] -->| "精度の壁" | B["2023-2024: Advanced RAG"]
B -->| "構造・推論の統合" | C["2025-現在: **Agentic & Graph RAG**"]
style A fill:#eee,stroke:#999
style B fill:#dcf,stroke:#0078d4
style C fill:#ffeab6,stroke:#ff9800,stroke-width:2px
① 黎明期 (2020年〜2022年): "Simple RAG"
Facebook AI Research（現 Meta）による提唱で始まった時代です。LLM自身が学習していない外部の最新情報や非公開知識を、単純なベクトル（意味の近さ）検索で引っ張ってきてプロンプトに貼り付けるだけのナイーブな実装でした。「検索して、くっつけて、回答させる」という非常にシンプルなフローゆえに、検索結果に少しでも無関係なノイズが混じると、AIが混乱し回答が即座に崩壊しハルシネーション（嘘）をつくという大きな課題を抱えていました。
② 発展期 (2023年〜2024年): "Advanced RAG"
検索精度を高めるため、前処理の段階での Chunking（文章の適切な長さに分割する技術）や、後処理の段階での Reranking（検索結果の類似度だけでなく、文脈的関連度で並び替え直す技術）に強力に注力した段階です。「Excelのようなただの表データやベタ打ちの箇条書きではAIの回答精度が出ない」という壁に多くの開発者が直面したのはまさにこの時期であり、「投入するデータの質（Data Quality）の重要性」が叫ばれ始めました。
③ 現在 (2025年以降): "Agentic & Graph RAG"
現在エンタープライズ市場で主流となりつつあるのが、AI自身が「どのデータベースの情報を、どういう順番で、どのようなキーワードを生成して検索すべきか」を自律的に判断する「エージェント型（Agentic）」への進化です。単なるベクトル（似た単語）ベースの検索を脱却し、情報同士の「関連性（グラフ空間）」や「意味の階層（HTMLなどのセマンティクス）」をAIが構造ごと理解して情報をたぐり寄せるアプローチが支配的になっていると判明しました。
🗜️ 互換性・テクニカルデータシート（仕様まとめ）
| 検証環境 / コンポーネント | ステータス / 推奨設定 | エンジニアとしての所感 |
|---|---|---|
| トレンド1 | Agentic RAG | AI自身が一回立ち止まって検索の要否や検索経路を「推論」してからツールを実行するパラダイムです。 |
| トレンド2 | GraphRAG / Semantic Structure | 大量のナレッジを点（個別の文章）ではなく繋がり（グラフネットワークや階層）で捉え、俯瞰的な回答を可能にします。 |
| トレンド3 | Long Context + RAG | 数百万トークンを一気に読めるモデルの時代になり、RAGは検索ツールではなく「不要なノイズを排除する高精度フィルタ」として再評価されています。 |
| DLP環境下でのRAG | HTMLによる静的構造化の徹底 | 企業内の機密データ流出を防ぐDLP配下において、セマンティック情報をAIへ的確に伝達する現実的な解となります。 |
自分が実際に踏んだ解決ステップ
最新トレンドの「3つの柱」を、企業の社内ナレッジ構築（SharePoint等）の現場にどのように落とし込むべきか、具体的なアプローチ方法が各所で提案されています。
1. Agentic RAG（推論するエージェント）プロンプトの導入
「入力されたら何でもかんでもベクトル検索を実行する」といった単純なワークフローを改めます。代わりに、AIに対して「このユーザーの質問には、運用マニュアルの検索が必要か？ それとも過去の障害チケットのデータベースを叩くべきか？」を自律的・段階的に思考させるプロンプトレベルでの設計を行います。「まずは社内の独自ナレッジから検索を優先せよ」というシステムプロンプトの基礎的な指示こそが、このエージェント制御の第一歩となります。
2. Semantic Structure（意味的構造化）の徹底
生のテキストデータをそのままベクトル・データベースに放り込むのではなく、情報を事前にHTMLのセマンティックタグ（<h1>, <h2>, <code>, <table>）で構造化してから保存する運用へ切り替えます。AIのパーサーに対して「ここが重要なタイトルであり、ここがただの補足説明である」といった意味の階層を明示的に伝えることが、現代のRAGにおいて最強のチューニングとなります（単なるCSVやExcelファイルを捨てて、構造化されたHTMLをナレッジの単位として選ぶ理由はまさにここにあります）。
3. Long Context時代のノイズフィルタリング
GPT-4oやGemini 1.5 Pro等の登場により、LLMが一度に読み込めるテキスト量（Context Window）は書籍数冊分といったレベルに飛躍的に拡大しました。しかし検証データによると、コンテキスト内に単に不要な長文情報を大量に詰め込むと「Lost in the Middle（真ん中あたりの情報を忘却・無視してしまう現象）」を引き起こすことが判明しています。そのため、現代の高度なRAGは、必要な情報を見つけるためというより、「嘘の原因となる不要な情報（ノイズ）の塊をLLMに読ませないための、高精度な足切りフィルタ回路」としての役割へと再定義されています。
総括: 全ての社内ドキュメントが、今後の時代は単なる人間が読むためだけのものではなく、「AIのクローラーが解釈・推論するために」標準化・セマンティック化（構造化）される時代がすでに到来していると言えます。
私が手元で確認したこと
ここで書いた手順は、自分の作業ログをベースに整理した記録です。途中で詰まった箇所・遠回りした箇所・想定と違った挙動も、後から同じ場面に遭遇した自分が読み返せるよう、できるだけ生のままメモしています。環境差で再現しないケースもあるため、ベンダー公式情報と本記事を見比べて取捨選択していただくのが一番確実です。
検証中に出た疑問と回答（FAQ）
Q: 古いSimple RAGから最新のAgentic RAGへシステムを移行させるのに、最も重要な設計要素は何ですか？
A: 「LLMへの適切な指示（System Prompt）」と「外部連携ツール（Tools/Functions呼び出し機能）の適切な提供」の2点に尽きます。LLMに「社内検索ツール」や「計算ツール」を選択肢として渡し、いつのタイミングでどのツールを使うべきか（あるいは使わずに自分の知識で答えるか）を判断させる自律的な能力を持たせることがスタートラインになると判明しました。
Q: セキュリティポリシーが非常に厳しい社内のDLP（情報漏洩防止）環境下でも、こうした最新のRAGは構築できますか？
A: はい、可能です。自社の機密データを外部ベンダーのSaaS型ベクトルデータベース（PineconeやChroma等）に一時的にも預けるのが難しい堅牢な環境では、社内のSharePoint内などに「構造化されたHTMLファイル群」としてナレッジをファイルベースで蓄積し、Microsoft 365内のCopilot・Graph検索等、完全に社内で閉じた環境からのみクロール・検索させる「Semantic HTMLベースのRAG」アプローチが、非常に有効かつセキュアな設計手法としてエンタープライズ層で注目されています。
Q: テキストをデータベース化する際のチャンキング（文章の区切り）のサイズは、何文字くらいどれくらいが今は最適とされていますか？
A: 扱うドキュメントの性質に大きく依存しますが、最近のAIコミュニティのトレンドとしては、「機械的に512トークンや1000文字で乱暴に区切って文脈をぶった切る」手法よりも、事前にドキュメント全体をHTML化など構造化しておき、「1ファイル＝1コンテキスト（障害1件ぶん等の意味の塊）」としてそのまま扱う「Document-level or Semantic Chunking」の方が、コンテキストの致命的な欠落を防ぎ、全体としての回答精度が向上する傾向にあると確認できました。
