【GenU完全攻略 #5】GenUのRAGとAgentCore Runtimeの違い——検索と行動を使い分ける

GenUでは「RAG」と「AgentCore Runtime」という2つのパターンでAIを活用できる。見た目は似ているが、できることが根本的に違う。

この記事ではその違いを整理して、ユースケースに応じてどちらを選べばいいかの判断基準を明確にする。

1分でわかる違い

一言で言うと：

RAG：「社内ドキュメントを検索して、それをもとに答える」
AgentCore Runtime：「ツールや外部APIを呼び出して処理を実行することができる」

ユーザーからの質問に対してどう動くかが違う。

RAG の動き:
質問「有給休暇の取得方法は？」
  → 就業規則PDFを検索
  → 該当箇所を取得
  → 「就業規則に基づくと…」と回答

AgentCore Runtime の動き:
指示「来週の月曜日に有給休暇を申請して」
  → 勤怠システムのAPIを呼び出す
  → 申請処理を実行
  → 「申請が完了しました」と返す

詳細な比較

観点	RAG	AgentCore Runtime
何をするか	ドキュメントを検索して回答	ツール・APIを呼び出して実行
データの流れ	ベクトルDB → LLM	LLM → Lambda / 外部API
状態管理	ステートレス	ステートフル可
向いている質問	「〇〇とは？」「〇〇を教えて」	「〇〇して」「〇〇を実行して」
外部連携	読み取り専用	読み書き・操作が可能
コスト感	比較的安価	Lambdaやツール実行、推論回数の増加によりコストが上がりやすい
実装の複雑さ	シンプル	ツール設計が必要

GenU上での実装位置の違い

GenUのアーキテクチャ上、2つは異なる経路で動く。

RAGの経路

ユーザー → GenU UI
  → Bedrock Knowledge Base（ベクトル検索）
  → 関連チャンクを取得
  → Claude（回答生成）
  → ユーザーへ返答

Knowledge Baseにドキュメントを登録しておくだけで動く。コードを書かなくても使えるのがRAGの特徴。

AgentCore Runtimeの経路

ユーザー → GenU UI
  → Claude（タスク分解）
  → AgentCore Runtime
  → Lambda関数（ツール実行）
  → 外部API / DB / SaaS
  → 結果をClaudeが集約
  → ユーザーへ返答

Lambda関数でツールを定義して、AgentCore Runtimeに登録する必要がある。実装コストはRAGより高いが、できることの幅が広い。

どちらを選ぶかの判断フロー

以下の問いに答えていくと判断できる。

① ユーザーは「答えを知りたい」のか「何かを実行させたい」のか？
    ↓
    答えを知りたい → RAGを使う
    実行させたい → ②へ

② 既存のシステム・APIに対して操作が必要か？
    ↓
    不要（テキスト生成だけ） → RAGで十分
    必要（DB更新・API呼び出し等） → AgentCore Runtimeを使う

③ リアルタイムのデータが必要か？
    ↓
    不要（静的なドキュメント） → RAG
    必要（最新在庫・予約状況等） → AgentCore Runtime

RAGに向いているユースケース

社内規程・マニュアルの検索
製品仕様書への問い合わせ
過去の議事録・報告書の参照
FAQの自動回答

AgentCore Runtimeに向いているユースケース

勤怠申請・承認の自動化
Salesforceへの商談登録
SlackやTeamsへの通知送信
データベースへの問い合わせ・更新
複数システムをまたぐ業務フロー自動化

両方を組み合わせるパターン

RAGとAgentCore Runtimeは排他ではなく、組み合わせて使えるのが強み。

例：「〇〇の申請書テンプレートを検索して、入力済みの状態で申請して」

  ① RAG：申請書テンプレートをKnowledge Baseから取得
       ↓
  ② AgentCore Runtime：取得したテンプレートに値を埋めて申請システムに送信

「情報を探す」フェーズをRAGが担い、「操作する」フェーズをAgentCore Runtimeが担う構成。次回の第07回ではこの組み合わせを実装する。

実はこの組み合わせパターンの実例はすでに紹介している。第05回のGenUのRAGに部署別アクセス制御を追加した——メタデータフィルタリングがそれで、AgentCore RuntimeのStrands Agentsを使ってCognitoの部署情報を取得し、Knowledge Baseへのクエリにフィルター条件を付与する構成がまさに両方の組み合わせになっている。

GenUでの設定上の違い

実際にGenUを使う上での設定の差は以下のとおり。

RAGの設定

Bedrock Knowledge Baseを作成
S3などにドキュメントを配置
Knowledge BaseのIDを cdk.json に設定
GenUのRAGチャットを有効化

AgentCore Runtimeの設定

Lambdaツール関数を実装
AgentCore Runtimeを作成してツールを登録
RuntimeのIDを cdk.json に設定
GenUのAgentチャットを有効化

どちらも cdk.json のパラメータを設定するだけで有効化できる仕組みになっている。

なぜ混同されやすいのか

RAGとAgentCore Runtimeはどちらも「ユーザーの質問に対して自然な回答を返す」ため、
見た目上は同じように見える。

しかし内部では、

RAGは「情報検索＋生成」
AgentCoreは「推論＋ツール実行」
という全く異なる処理を行っている。

まとめ

RAGは「検索して答える」、AgentCore Runtimeは「操作して実行する」
ユーザーが「知りたい」なら RAG、「やらせたい」なら AgentCore Runtime
リアルタイムデータや外部システム連携が必要ならAgentCore Runtime一択
両方を組み合わせることで、より高度なユースケースに対応できる

次回はAgentCore RuntimeでLambdaツールを実装する具体的な手順を扱う。

← 第4回：GenU × RAG 基礎編——ナレッジベース構築と検索の仕組み｜第6回：GenU標準メタデータフィルタリング——rag-knowledge-base.tsでアクセス制御を設定する →