「似た文書は見つかったが、適用条件が判断できない」——基本RAGだけでは、こうした壁にぶつかります。
この記事では、Oracle AI Database 26ai上でGraphRAGを組む考え方と、ベクトル検索・SQLプロパティグラフ・リレーショナル/JSONデータを同一基盤で扱う理由を整理します。
この記事でわかること
- 基本RAGとGraphRAGの違い
- Oracle AI Database 26aiが提供する5つの検索要素
- エビデンス束をLLMへ渡す実務ワークフロー
- 最小構成のナレッジグラフの始め方
基本RAGでは足りない理由
RAG（Retrieval-Augmented Generation）は、外部データを検索してLLMの回答根拠にする仕組みです。質問文をベクトル化し、意味が近い文書チャンクを取り出してプロンプトに載せる流れが一般的です。
Oracle Developersが2026年6月27日に投稿した解説では、基本RAGは「探している内容を見つける」段階までは有効でも、それだけでは不十分な場面があると指摘しています。たとえば「この顧客の設置資産に、どの交換ポリシーが適用されるか」という問いでは、ポリシー文書自体は見つかっても、契約・権利・地域例外・有効期限といった関係情報が欠けると、適用可否を判断できません。
GraphRAGは、この関係性の欠落を補うアーキテクチャパターンです。Oracle公式ブログ（2026年6月11日）でも、GraphRAG with Oracle AI Database 26aiは単体製品名ではなく、ベクトル検索とグラフ由来の関係コンテキストを組み合わせる設計パターンとして定義されています。
Oracle AI Database 26aiで何ができるか
Oracle AI Database 26aiは、Oracle Database 23aiを置き換える長期サポート版です。2025年10月のリリースアップデートで移行でき、AI Vector Searchなどの高度なAI機能は追加料金なしで利用できます。GraphRAGの実装基盤として、次の5要素を同一データベース環境で扱えます。
Oracle AI Vector Searchは、文書チャンクやエンティティ要約の埋め込みベクトルを保存し、意味的類似度で検索します。SQLプロパティグラフは、CREATE PROPERTY GRAPHで既存テーブルを頂点・辺として定義し、GRAPH_TABLEでパターンマッチングをSQLから実行します。グラフ定義はメタデータのみで、実データは元テーブルを参照するため、二重管理を避けられます。
加えて、リレーショナルデータで契約状態や有効日を絞り込み、JSONデータで文書属性やワークフロー状態を保持し、SQLフィルタで地域・権限・ステータスを適用します。Python側でベクトル結果とグラフ結果を後から結合するのではなく、SQL内で結合できる点が実務上の利点です。
GraphRAGの検索ワークフロー
Oracle公式が示す典型的な流れは次のとおりです。
- ユーザー質問を埋め込み化する
- ベクトル検索で関連文書・チャンク・エンティティ要約を取得する
- 上位結果をグラフの頂点に解決する
- SQLプロパティグラフをたどり、契約・製品・ポリシーなどの関係パスを取得する
- 認可・有効期限・地域などのSQL述語で結果を絞る
- 取得パッセージ、グラフパス、構造化ファクト、出典情報を「エビデンス束」として組み立てる
- LLM、AIアシスタント、検索ワークフロー、レコメンド、エージェントへ渡す
最終的な自然言語生成はLLMが担いますが、入力されるのは「似たチャンクの羅列」ではなく、なぜその根拠が適用候補になるかを説明できる構造化コンテキストです。
基本RAGとの違い
| 観点 | 基本RAG | GraphRAG（Oracle 26ai） |
|---|---|---|
| 主な検索軸 | 意味的類似度 | 類似度＋エンティティ関係 |
| 向く質問 | 単一文書内で完結する内容 | 顧客・契約・資産・ポリシーが絡む内容 |
| 根拠の形 | テキスト断片 | 断片＋関係パス＋構造化ファクト |
| データ配置 | 外部ベクトルDBに分離しがち | 運用DBと同一環境に集約可能 |
ベクトル検索だけでも、キーワードとベクトルを組み合わせるハイブリッド検索はOracle AI Vector Searchの公式ドキュメントでサポートされています。GraphRAGは、その上に「誰と何がどう結びついているか」を明示的に取り込む層です。サポート、コンプライアンス、サプライヤーリスク、意思決定支援、エンタープライズエージェントなど、関係性が回答品質を左右する領域で効果が出やすいとOracleは位置づけています。
最小構成のナレッジグラフから始める
Oracleは、最初から全社オントロジーを作るのではなく、最小構成のナレッジグラフ（MVKG）から始めることを推奨しています。たとえば製品サポート領域なら、顧客・契約・権利・資産・製品・ポリシー・サポート文書の7エンティティと、「顧客が契約を持つ」「資産が製品のインスタンスである」「製品がポリシーに従う」など少数の関係から着手します。
最初の検証では、既知のサポート質問に対してグラフコンテキストが回答精度を上げるかを測り、改善が確認できた関係だけを追加します。GraphRAGは「グラフがあれば何でも良くなる」手法ではなく、関係性が検索結果を変えるユースケースに絞るのが前提です。
セキュリティ設計は必須
GraphRAGでは、ベクトル結果・グラフ走査・プロンプト組み立てのすべてを認可境界として扱う必要があります。意味的に近い、またはグラフ上で接続されているからといって、ユーザーが閲覧権限を持たない文書や契約情報をLLMに渡してはいけません。Oracle AI Databaseのセキュリティ機能に加え、アプリケーション側でユーザーコンテキストを渡し、ベクトル・グラフ・JSONの各段階でフィルタリングする設計が公式ブログでも強調されています。
向いているチーム
Oracle AI Database 26ai上のGraphRAGは、顧客・注文・契約・資産・サービス記録がすでにOracle Database上にある組織に特に適しています。検索基盤を別システムに切り出すほど、AI用コンテキストと業務データの意味がズレやすくなります。SQLに慣れたチームであれば、GRAPH_TABLEの結果を通常のSQLと結合できるため、既存のデータパイプラインへの組み込みも現実的です。
一方、単純な社内FAQ検索のように文書の意味一致だけで足りる用途では、GraphRAGまで導入する必要はありません。基本RAGやハイブリッド検索で十分なケースも多く、GraphRAGは関係性が回答の正否を左右するときに選ぶパターンです。
企業AIをデモから本番システムへ移すうえで、GraphRAGは「似ている」だけでなく「なぜ適用されるか」を根拠付きで渡すための次の一手です。Oracle AI Database 26aiは、その検索層をデータベース中心に置くための基盤として、2026年6月時点で公式に解説が進んでいます。