RAG（Retrieval-Augmented Generation）は単なる検索拡張ではなく、設計パターンによって性能も用途も大きく変わります。
現在整理されている主要なRAGパターンは7種類です。
RAGの7つの設計パターン
Advanced RAG
基本の拡張（ハイブリッド検索 + リランク）
検索精度の向上
RAG Fusion
多角的視点（マルチクエリ）
質問の曖昧さの解消
HyDE
逆転の発想（回答から検索）
クエリとドキュメントのベクトル不一致
Router / Adaptive RAG
最適経路の選択
不要な検索コストの削減
GraphRAG
関係性の理解（ナレッジグラフ）
網羅的な要約や複雑な関係性の抽出
Self-RAG / CRAG
自己省察（検索結果の評価・修正）
ハルシネーション（嘘）の低減
Agentic RAG
自律エージェント（ツールの使用）
複数ステップを要する複雑なタスク
進化の流れは、
検索補助
→ 再ランキング
→ 構造理解（Graph）
→ ハイブリッド化
→ エージェント化
→ 自律協調
へと進んでいます。
本質的な差は「構造データ」にある
RAGの高度化を左右する最大の要因はLLMではありません。
どれだけ業務データが構造化されているか にかかります。
AtlassianではTeamworkgraphというgraphのフレームワークがあります。
このフレームワークは、Atlassian製品だけでなく、接続する各社製品の情報をマッピングすることでデータを構造化しています。
構造データが強いケース
チケット形式（Jira、ServiceNow）
ステータス管理
依存関係リンク
親子構造
構成管理（CMDB）
状態遷移ログ
→ 自然に業務グラフが形成される
→ Graph RAGが成立する
構造が弱いケース
自由記述中心
任意タグ
単純リンク
→ 検索は強化できるが、因果推論は弱い
Graph RAGの強さは、AIの性能ではなく「データモデル設計」に依存します。
各社比較（構造データ × RAG適性）
汎用的な業務用途でのRAGの能力
項目 | Atlassian | Microsoft | ServiceNow | Notion | Google Gemini | Google NotebookLM |
主用途 | 開発・プロダクト | 企業横断 | IT運用 | 個人/SMB | 横断AI | 資料理解 |
構造データ | ◎ 業務グラフ | ○ 組織中心 | ◎ IT構成 | △ 疑似 | ○ | × なし |
Graph RAG適性 | ◎ 非常に強い | ○ 中程度 | ◎ IT特化 | △ 限定的 | ○ | × |
Agent実行 | ○ 発展中 | ○ | ◎ | △ | ○ | × |
強み | 構造×履歴×開発 | 統合基盤 | IT影響分析 | UX | マルチモーダル | 出典付き理解 |
弱み | 汎用知識 | 構造密度 | 開発領域 | 統制 | 業務構造浅い | 業務統合なし |
各社の強み
Atlassian
Jiraの課題リンク
Confluence階層
Assets / Compass依存関係
詳細な履歴データ
→ 開発・プロダクト構造グラフが非常に濃い
→ Graph RAGとの相性が高い 強みは「構造×履歴」
Atlassian Teamwork Graph
ServiceNow
CMDBによる構成管理
インシデントと変更管理の連動
影響範囲分析
→ IT運用領域では最強クラスのGraph RAG
Microsoft
M365横断データ
CopilotによるHybrid RAG
Router型設計
→ 横断性は強いが、業務構造の密度は限定的。
Google Gemini
Web検索統合
マルチモーダル
Router設計
→ 汎用理解は強いが、業務グラフは浅い。
Google NotebookLM
アップロード資料限定RAG
出典明示
要約特化
→ 業務構造AIではなく「資料理解AI」。
サマリ
RAGの進化は7段階に整理できますが、実際の競争軸はどれだけ構造化された業務データを持っているかに向かっています。
構造が濃い → Graph RAGが強い
履歴が詳細 → 予測やAgent化が可能
自由文中心 → 検索止まり
AIのトレンドはGraph × Agent × Time（履歴）に進んでいます。
実際、Atlassianはここ1年で製品のRovo Agentの強化・Audit logの機能向上が進んでいます。
RAGは単純な検索技術ではなく業務構造の可視化技術 に進化しています。