RAG + Agent：次世代 AI アプリケーションアーキテクチャ

先週、ある友人から相談を受けました。彼の会社では3ヶ月かけて構築した RAG システムが、リリース初週に上司から厳しい評価を受けたそうです。「こんな単純な出張精算の質問にさえ正しく答えられないのか？」

正直なところ、こういうケースは珍しくありません。従来の RAG は、辞書を引くだけの学生のようなものです。質問されたことだけを検索し、その背後にある意図を考えることはありません。「先月の出張精算が却下された理由を知りたい」という質問に対して、従来の RAG は出張ポリシーに関するドキュメントを大量に検索するかもしれません。しかし、まずユーザーの精算記録を確認することは思いつきません。

これこそが Agentic RAG が解決しようとしている問題です。

この記事では、企業の AI アプリケーションを変革しつつある RAG + Agent の統合アーキテクチャについて解説します。アーキテクチャの進化から、フレームワークの選定、そして具体的な実装ロードマップまで詳しく見ていきます。さらに、スマートカスタマーサポートの実践事例も紹介します。

従来の RAG から Agentic RAG へ：アーキテクチャの進化

従来の RAG の動作原理は非常にシンプルです。ユーザーの質問 → ベクトル検索 → 関連ドキュメントを取得 → LLM に投げて回答を生成。この3ステップで完了です。

このアーキテクチャの利点は明確です。高速で、低コスト、実装が容易。しかし、問題もすぐに現れます。

検索精度が低い。ユーザーが曖昧な質問をすると、ベクトル類似度検索は「似ているが実際には無関係」なドキュメントを大量に返してしまいます。「データベース接続の設定方法」という質問に対して、MySQL と PostgreSQL のドキュメントが混ざった検索結果が返ってくるかもしれません。ユーザーが自分で判断しなければなりません。

推論ができない。従来の RAG は「検索・生成」というアクションしか実行できません。複数ステップが必要な問題に直面すると、手詰まりになります。「案Aと案Bのメリット・デメリットを比較して」と質問すると、片方の案のドキュメントしか検索せず、もっともらしいウソをついてしまうかもしれません。

"McKinsey の調査によると、GenAI ユーザーの 47% がネガティブな結果を経験し、27% のみが出力結果をすべて検証している"

Agentic RAG がもたらす変革

Agentic RAG の核心は、AI に「どうやって問題を解決するか」を能動的に考えさせることです。機械的に検索・生成を実行するのではありません。

そのコアサイクルは次のようになります：

Plan → Retrieve → Act → Reflect → Answer

順を追って解説します：

Plan（計画）：まずユーザーの質問を分析し、サブタスクに分解します。「先月の出張精算が却下された」という質問は、以下のように分解できます：ユーザーの精算記録を確認、出張ポリシーを確認、却下理由を照合して分析。

Retrieve（検索）：計画に基づいて、どこで何を検索するかを決定します。ナレッジベース、データベース、さらに外部 API の呼び出しが必要かもしれません。

Act（実行）：検索を実行し、ツールを呼び出し、情報を取得します。この段階で新たな問題が見つかることもあり、再計画が必要になるかもしれません。

Reflect（振り返り）：検索結果が十分か、回答が妥当かを評価します。不十分な場合は Plan 段階に戻ることもあります。

Answer（回答）：最終的な回答を生成し、参照元を添付します。

つまり、従来の RAG は辞書を引くようなもので、Agentic RAG はリサーチアシスタントのようなものです。問題を分析し、資料を調べ、情報を照合し、信頼できる回答を提供してくれます。

この数字の背景には、企業の AI 能力に対する期待が「使える」から「使いやすい」へとレベルアップしていることが見えてきます。Agentic RAG は、まさにこのアップグレードの重要な一歩なのです。

10種類の RAG アーキテクチャパターン詳解

この分野は情報量が多いため、要点を絞って解説します。完全なアーキテクチャ比較表は後ほど掲載しますので、まずは全体像をつかんでください。

Naive RAG：入門レベルの選択

最もシンプルなアーキテクチャです。ユーザーの質問 → ベクトル検索 → 回答生成。アイデアを素早く検証するには適していますが、本番環境では基本的に不足します。

典型的な問題：検索精度が低い、コンテキストウィンドウの無駄遣い、ハルシネーションが深刻。個人的には、POC や社内ツールでのみ使用することをお勧めします。

Hybrid RAG：エンタープライズ環境の標準構成

このパターンは現在、エンタープライズ環境のベースラインとなっています。核心は、2種類の検索方法を組み合わせることです。語彙検索（キーワードマッチング）と意味検索（ベクトル類似度）です。

なぜでしょうか？ 2つの検索方法にはそれぞれ利点があるからです。語彙検索は正確なマッチングに優れ、意味検索は意図の理解に優れています。組み合わせれば、当然効果は上がります。

実装面では、BM25 で語彙検索を行い、ベクトルデータベース（Pinecone、Weaviate、Milvus など）で意味検索を行い、Reciprocal Rank Fusion（RRF）で結果をマージします。

Graph RAG：マルチホップ推論の強力なツール

「なぜ」「どう関連しているか」といった質問に答える必要があるビジネスシナリオでは、Graph RAG を検討する価値があります。

ドキュメントからエンティティを抽出してナレッジグラフを構築し、マルチホップ推論をサポートします。「どの製品がこのサプライヤーの部品を使用しているか」という質問に対して、Graph RAG はグラフの関係チェーンに沿って答えを見つけることができます。

その代償は、コストがベーシックな RAG の 3-5 倍になることです。ナレッジグラフの構築と維持には、かなりのコストがかかります。

Agentic RAG：能動的思考型

核心的なサイクルは既に説明しました。ここで補足しておきます。Agentic RAG の柔軟性は諸刃の剣です。

メリットは複雑な問題を処理できること、デメリットはレイテンシーが高く、コストを制御しにくいことです。単純な質問が複数回の検索とツール呼び出しをトリガーし、API 呼び出し費用が急増する可能性があります。そのため、実際のデプロイでは、ルーティング戦略と組み合わせることが一般的です。単純な質問は従来の RAG で処理し、複雑な質問だけが Agentic フローに入ります。

Self-RAG：自己修正型

このパターンの核心は、モデルに自分の出力を評価させることです。検索したドキュメントは十分に関連しているか？ 生成した回答にハルシネーションはないか？

評価が通らなければ、モデルは能動的に再検索したり、回答を修正したりします。素晴らしいアイデアですが、推論コストが増え、評価自体も間違う可能性があります。

Agentic Graph RAG：最高峰

現在最も先進的なパターンです。Agent の編成能力をナレッジグラフ検索に埋め込み、マルチホップ推論能力と能動的な計画能力の両方を備えています。

もちろん、コストも最高峰レベルです。コアビジネスシナリオでのみ使用することをお勧めします。

アーキテクチャパターン比較表

アーキテクチャパターン	複雑度	適用シナリオ	相対コスト	レイテンシー
Naive RAG	低	迅速な検証、社内ツール	1x	<1s
Hybrid RAG	中	エンタープライズ環境の標準	1.5x	1-2s
Graph RAG	高	マルチホップ推論、ナレッジ集約型	3-5x	2-4s
Agentic RAG	高	複雑な意思決定、マルチステップタスク	3-8x	3-10s
Self-RAG	中高	高精度が要求されるシナリオ	2-3x	2-4s
Agentic Graph RAG	極高	コアビジネス、複雑な推論	5-10x	5-15s

Hybrid RAG から始め、実際のニーズに応じて徐々にアップグレードすることをお勧めします。最初から最先端のアーキテクチャを目指すと、失敗する可能性が高いです。

フレームワーク選定：LangChain vs LlamaIndex vs CrewAI vs AutoGen

この分野では苦い経験があります。以前のプロジェクトで、最初はあるフレームワークを選択しましたが、途中でエコシステムが不十分だと気づき、作り直さなければなりませんでした。時間の無駄だけでなく、チームの士気にも影響しました。

フレームワーク選定は本当に重要です。主要なフレームワークの特徴と使用シナリオを整理しました。皆さんの失敗を減らす一助になれば幸いです。

LangChain / LangGraph：最も充実したエコシステム

どれを選べばいいか迷ったら、LangChain を選べばまず間違いありません。現在、最もエコシステムが充実したフレームワークです。ドキュメントも完備、コミュニティも活発、GitHub スター数は 25K を超えています（LangGraph）。

LangGraph は LangChain チームがリリースしたグラフ状態マシンフレームワークで、ステートフルな Agent ワークフローの構築に特化しています。最大の利点は本番環境での永続化サポートです。Agent の状態をデータベースに保存でき、チェックポイントからの再開やタイムトラベルデバッグが可能です。

適用シナリオ：本番環境のワークフロー、状態の永続化が必要、複雑な Agent 編成。

# LangGraph 簡略例：クエリ計画エージェント
from langgraph.graph import StateGraph

def plan_query(state):
    """ユーザーの質問を分析し、検索ステップを計画"""
    query = state["query"]
    # 質問を分解、サブクエリを生成
    sub_queries = decompose(query)
    return {"sub_queries": sub_queries}

def retrieve(state):
    """検索を実行"""
    results = []
    for q in state["sub_queries"]:
        docs = retriever.invoke(q)
        results.extend(docs)
    return {"context": results}

# ワークフローを構築
workflow = StateGraph(AgentState)
workflow.add_node("plan", plan_query)
workflow.add_node("retrieve", retrieve)
workflow.add_edge("plan", "retrieve")

LlamaIndex：データ集約型の最適解

ビジネスシナリオが大量の非構造化データ（ドキュメント、データベース、API）を扱う場合、LlamaIndex がより良い選択です。

クエリエンジンの設計が優れており、多様な検索戦略をサポートしています。ベクトル検索、キーワード検索、ハイブリッド検索、ナレッジグラフ検索。また、様々なデータソースへのコネクタサポートも充実しています。

適用シナリオ：データ集約型 RAG アプリケーション、多様なデータソースとの連携、検索品質重視。

CrewAI：プロトタイプ迅速作成の強力なツール

CrewAI の売りは「役割主導のマルチエージェントチーム」です。複数の Agent ロールを定義し、協力してタスクを完了させることができます。

例えば、コンテンツ制作チームを設計する場合：リサーチャーが資料収集を担当、ライターが執筆を担当、エディターが校正を担当。各ロールには独自の目標とツールがあります。

適用シナリオ：プロトタイプの迅速な検証、ビジネスプロセスの自動化、役割分担が明確なタスク。

現在 CrewAI の開発者コミュニティは 10 万人を超え、GitHub スター数は 20K を超えています。エコシステムの発展は急速です。

AutoGen：Microsoft 支持のマルチエージェントフレームワーク

AutoGen は Microsoft Research がオープンソース化したマルチエージェントフレームワークで、対話型協力を特徴としています。複数の Agent が対話を通じてタスクを完了し、多段階のやり取りが必要なシナリオに適しています。

特徴は人間と AI の協力をサポートしていることです。実在の人間がいつでも対話に介入し、Agent の方向性を修正できます。

適用シナリオ：研究プロジェクト、人間と AI の協力が必要な複雑なタスク、対話型インタラクション。

GitHub スター数は 50K を超え、現在最もスター数の多い Agent フレームワークです。

選定デシジョンツリー

シンプルな判断ロジックを描きました：

あなたのプロジェクトはどのタイプ？
├── 本番環境の永続化ワークフロー → LangGraph
├── データ集約型 RAG → LlamaIndex
├── プロトタイプ/ビジネスプロセス → CrewAI
├── 研究/対話型マルチエージェント → AutoGen
└── 不明/最大の柔軟性が必要 → LangChain + LangGraph

とはいえ、フレームワーク選定に標準的な答えはありません。チームの技術スタックとプロジェクトの要件に基づいて選択し、フレームワークの更新頻度とコミュニティの活発さを確認することをお勧めします。これが後のメンテナンスコストに直接影響します。

エンタープライズ実装ロードマップ

複数企業の実践経験に基づき、90 日間の実装テンプレートを整理しました。もちろん、各企業のペースは異なりますので、実情に合わせて調整してください。

フェーズ1：Day 0-15、問題と KPI の定義

多くの人が最初から技術選定に取り組みますが、これは間違いです。まず明確にすべきは：何を解決したいのか？

以下の重要な問いに答える必要があります：

1. ユーザーは誰か？ 社内従業員か、外部顧客か？
2. コアシナリオは何か？ Q&A、検索、それとも複雑な推論か？
3. 成功指標をどう設定するか？ 精度、レスポンスタイム、ユーザー満足度？

この段階では、シンプルなユーザー調査を行い、50-100 の実際の質問を収集することをお勧めします。これらの質問は後でテストセットと評価基準になります。

フェーズ2：Day 16-45、データ準備と検索レイヤー

データ準備は地道な作業ですが、システムの上限を決定します。

データクレンジング：重複、古い、機密情報を除去。このステップは見落とされがちですが、汚いデータは検索品質に深刻な影響を与えます。

チャンキング戦略：ドキュメントタイプに応じて適切なチャンクサイズを選択。技術ドキュメントは 500-1000 文字程度、法律条文は条項単位で分割する必要があるかもしれません。

Embedding 選定：OpenAI の text-embedding-3 シリーズ、Cohere、BGE などがおすすめです。まず小規模なデータセットで比較テストすることをお勧めします。

検索レイヤー構築：Hybrid RAG から始め、BM25 とベクトル検索を組み合わせます。

フェーズ3：Day 46-75、Agent 編成とツール統合

この段階で Agent 機能を導入します。

ルーティング戦略：すべての質問に Agent が必要なわけではありません。単純な FAQ は従来の RAG で処理し、複雑な質問だけが Agent フローに入ります。これでコストとレイテンシーを制御できます。

ツール統合：MCP プロトコルを通じて社内システムに接続します。データベースクエリ、API 呼び出し、ドキュメント検索などが含まれます。

編成設計：LangGraph や類似のツールを使ってワークフローを設計します。シンプルな ReAct パターンから始め、徐々に複雑さを増やすことをお勧めします。

フェーズ4：Day 76-90、評価、テスト、強化

評価に関しては、RAGAS フレームワークの使用をお勧めします。主に3つの指標に注目します：

• Faithfulness（忠実度）：生成された回答が検索ドキュメントに忠実か、目標 >= 0.8
• Answer Relevance（回答関連性）：回答がユーザーの質問に答えているか
• Context Relevance（コンテキスト関連性）：検索されたドキュメントが十分に関連しているか

さらに、いくつかの技術指標があります：

• Recall@K >= 0.85：上位 K 件の検索結果の再現率
• P95 レイテンシー <= 2.5s：95% のリクエストのレスポンスタイム
• コスト管理：リクエストごとの API 呼び出し回数とトークン消費

よくある落とし穴

最後に、陥りやすい罠をいくつか警告します：

1. アクセス制御のバイパス：Agent がツール呼び出しを通じて権限制御をバイパスする可能性がある。セキュリティテストを十分に実施する
2. コンテキストの期限切れ：長い会話では、早期の情報が失われる可能性がある。コンテキスト管理戦略を設計する必要がある
3. コストの暴走：Agent が複数回の検索をトリガーする可能性があり、API 呼び出し費用が急速に蓄積する

実践事例：スマートカスタマーサポートのアーキテクチャ設計

この事例は、以前ある企業のために構築したものです。結果は良好でした。

シナリオ：企業のカスタマーサポートは、製品、注文、アフターサービス、ポリシーなど多方面の質問に答える必要があります。これらの情報はナレッジベース、CRM システム、注文システム、ERP システムに分散しています。

問題：従来の RAG はナレッジベースしか検索できず、ユーザーの注文状況や履歴記録などの個別情報を照会できません。

アーキテクチャ設計

3層の Agent アーキテクチャを設計しました：

第1層：Routing Agent（ルーティングエージェント）

ユーザーの質問を分析し、次のステップを決定します。例えば：

• 「製品の使い方」 → ナレッジベース検索へ
• 「注文の配送状況」 → 注文システム照会へ
• 「返金ポリシー」 → ポリシードキュメント検索へ

第2層：Query Planning Agent（クエリ計画エージェント）

複雑な質問に対して、複数のサブクエリに分解します。例えば「先月買ったスマホは返品できるか」という質問には：

1. ユーザーの注文記録を照会
2. 返品ポリシーを検索
3. 注文日とポリシー有効期限を照合

第3層：ReAct Agent（推論行動エージェント）

具体的な検索とツール呼び出しを実行し、マルチステップ反復をサポートします。

ツール統合

MCP プロトコルを通じて社内システムに接続：

tools:
  - name: knowledge_search
    type: vector_retrieval
    source: product_docs

  - name: order_query
    type: api_call
    endpoint: /api/orders/{user_id}

  - name: policy_search
    type: hybrid_retrieval
    sources: [policy_docs, faq]

効果比較

リリース後、従来の RAG と Agentic RAG の効果を比較しました：

指標	従来の RAG	Agentic RAG
問題解決率	45%	78%
平均レスポンスタイム	1.2s	3.5s
ユーザー満足度	3.2/5	4.1/5
人間の介入率	55%	22%

問題解決率は 33 ポイント向上し、人間の介入率は半分以上減少しました。代償はレスポンスタイムの増加です。これは Agent アーキテクチャの避けられない代償であり、体験と効率のバランスを取る必要があります。

まとめ

RAG + Agent は企業の AI アプリケーションの標準アーキテクチャになりつつあります。受動的な検索から能動的な推論への移行により、このアーキテクチャは AI が真に複雑な問題を処理できるようにします。

いくつかのアドバイス：

1. シンプルに始める。最初から Agentic Graph RAG を追求せず、Hybrid RAG から始め、価値を検証してからアップグレードする。

2. コスト管理に注力する。Agent の柔軟性には代償がある。API 呼び出し費用は簡単に制御不能になる。ルーティング戦略とキャッシュメカニズムは必須。

3. 評価体系を重視する。定量的指標がなければ、システムが良いか悪いか永遠にわからない。RAGAS フレームワーク + 自前のテストセット、これが基本。

4. オープンプロトコルに注目する。MCP はツール接続の標準になりつつあり、A2A プロトコルもクロスフレームワーク協力の問題を解決している。これらのプロトコルは Agent エコシステムの発展に深刻な影響を与える。

以上です。RAG システムを構築中の方々に、この記事が何らかの参考になれば幸いです。質問があればコメント欄で議論しましょう。

FAQ

Agentic RAG と従来の RAG の核心的な違いは何ですか？

従来の RAG は受動的な検索モードです：ユーザーの質問 → ベクトル検索 → 回答生成。Agentic RAG は能動的な推論能力を導入し、コアサイクルは Plan → Retrieve → Act → Reflect → Answer です。複雑な問題を分解、マルチステップ検索、自己修正が可能です。

企業はどの RAG アーキテクチャを選択すべきですか？

Hybrid RAG から始めることをお勧めします。これはエンタープライズ環境の標準構成であり、コストを管理でき効果も良好です。ビジネスニーズに応じて徐々にアップグレード：マルチホップ推論が必要なら Graph RAG、複雑な意思決定が必要なら Agentic RAG、コアビジネスシナリオなら Agentic Graph RAG を検討。

LangChain、LlamaIndex、CrewAI はどう選べばいいですか？

プロジェクトタイプに応じて選択：

• 本番環境の永続化ワークフロー → LangGraph
• データ集約型 RAG → LlamaIndex
• プロトタイプ/ビジネスプロセス → CrewAI
• 研究/対話型マルチエージェント → AutoGen

Agentic RAG のコストとレイテンシーはどう制御しますか？

主要な戦略：1）ルーティング戦略——単純な質問は従来の RAG、複雑な質問だけ Agent フローへ；2）キャッシュメカニズム——高頻度クエリの結果をキャッシュ；3）反復回数の制限——Agent が無限ループしないように；4）API 呼び出しの監視——コストアラートの閾値を設定。

RAG + Agent プロジェクトの実装にはどのくらいかかりますか？

4つのフェーズに分けることをお勧めします：Day 0-15 問題と KPI の定義；Day 16-45 データ準備と検索レイヤー；Day 46-75 Agent 編成とツール統合；Day 76-90 評価・テスト・強化。合計約 90 日、チーム規模とプロジェクトの複雑さに応じて調整可能。

RAG システムの効果をどう評価しますか？

RAGAS フレームワークの使用をお勧めします。3つのコア指標に注目：

• Faithfulness（忠実度）&gt;= 0.8
• Answer Relevance（回答関連性）
• Context Relevance（コンテキスト関連性）

技術指標：Recall@K &gt;= 0.85、P95 レイテンシー &lt;= 2.5s

9 min read · 公開日: 2026年3月22日 · 更新日: 2026年3月22日