AIエージェントに「社内知識を参照しながら回答させたい」と考えるとき、設計者は必ずRAGとツール使用のどちらを使うかという判断に直面する。両者は「外部情報を取り込む」という表面上の目的が似ているが、実装コスト・予測可能性・対応できるタスクの性質がまったく異なる。この選択ミスは後から修正するほど工数がかかるため、設計初期に正しく判断できるかどうかが重要だ。
RAGとツール使用——2つのアプローチの本質的な違い
RAGは文書検索で静的知識を補完する手法、ツール使用はAPI・計算・書き込みを含む外部能力全体への汎用拡張です。
RAG（検索拡張生成）は、ユーザーのクエリに関連するドキュメントをベクトルストアや全文検索で取得し、その内容をコンテキストとしてLLMに渡して回答を生成する手法だ。情報の取得と生成が分離しており、「取得→読む→答える」という決まったパイプラインを持つ。
ツール使用（Function Calling）は、LLMがAPIを呼び出し、コードを実行し、データベースに書き込み、外部サービスと通信するなど、計算や副作用を伴う任意の外部能力を利用できるようにする手法だ。RAGの文書検索もツールとして実装できる——つまりツール使用はRAGを内包する上位概念として捉えることができる。
本記事はAIエージェントガバナンスの情報取得設計レイヤーを扱う。コンテキスト全体の管理についてはコンテキストエンジニアリング設計、マルチエージェントの委譲設計についてはサブエージェント・オーケストレーションも合わせて参照してほしい。
設計判断の3つの軸——予測可能性・コスト・タスク複雑性
RAGかツール使用かは予測可能性・コスト・タスク複雑性の3軸で判断します。単純な知識検索ならRAGを先に評価するのが原則です。
設計判断の起点となる3軸を整理する。
| 判断軸 | RAG | ツール使用 |
|---|---|---|
| 予測可能性 | 高い（単一パスで制御可能） | 低い（ループ・分岐で動作が複雑化） |
| レイテンシ | 低い（1回の検索＋生成） | 高い（複数ツール呼び出しが積み上がる） |
| コスト | 低い（トークン消費が制御しやすい） | 高い（ステップが増えるほど複利で増加） |
| タスク複雑性 | 低〜中（静的知識の参照） | 中〜高（計算・副作用・マルチステップ） |
| デバッグ容易性 | 高い（パイプラインが単純） | 低い（失敗箇所の特定が難しい） |
Weaviateのアーキテクチャガイドが指摘するとおり、エージェントはRAGの「適応性のなさ」を解決するが、新たな「予測不可能性」を導入する。どちらを先に選ぶかではなく、タスクの性質に応じてどちらが適切かを判断することが設計の出発点だ。
RAGが最適なケース——静的知識の高速補完
静的な知識ベースを単一パスで参照するタスクにはRAGが最適です。予測可能なコストとレイテンシを保てます。
RAGを選ぶ判断基準は「回答に必要なすべての情報がすでに知識ベースに存在し、検索して読むだけで十分か」という問いだ。以下のようなタスクはRAGが有効だ。
- 製品マニュアル・仕様書・FAQへの問い合わせ
- 社内規程・ポリシー文書の参照
- 固定されたドキュメントセットを対象とする意味検索
- 回答の根拠をユーザーに提示したい場面（引用可能性が重要なケース）
Anthropicは「Contextual Retrieval」で検索精度の改善手法を公開している。各チャンクに文書全体の文脈を付加してからエンベディングする手法で、検索失敗率を49%削減でき、リランキングと組み合わせると67%削減できることが実証されている。RAGの精度が不足していると感じる場合は、まずアーキテクチャの変更ではなくContextual Retrievalのような手法で検索精度を上げることを検討すべきだ。
RAGの主なトレードオフは「取得できた情報の範囲でしか答えられない」という制約にある。ドキュメントに記載のない最新情報・動的に変化するデータ・計算が必要な回答には対応できない。
ツール使用が最適なケース——動的処理とアクション実行
外部API呼び出し・コード実行・データ書き込みが必要なタスクはツール使用が適切です。RAGでは構造的に対応できません。
ツール使用を選ぶ判断基準は「タスクの完了に、読む以外の操作（計算・書き込み・API呼び出し）が必要か」という問いだ。以下のタスクにはツール使用が必要になる。
- 外部APIからリアルタイムデータを取得する（株価・天気・在庫）
- データベースのレコードを参照・更新・削除する
- コードを実行して計算結果・グラフ・ファイルを生成する
- 複数の情報源を横断して統合的な分析を行う
- メール送信・スケジュール登録などの副作用を伴うアクション
ツール設計ではAIエージェントの権限管理設計と組み合わせて、各ツールの権限スコープを最小化することが安全設計の前提になる。Anthropicのガイドラインでは「ツール間の機能の重複を最小化し、各ツールに単一責任を持たせる」ことが推奨されている——ツールが重複するとモデルの選択精度が落ち、不必要な呼び出しでトークンを浪費する。
ツール使用の主なトレードオフは「デバッグと可観測性の難易度が上がる」点だ。どのステップで何が失敗したかを追跡するには、エージェントの可観測性設計が不可欠になる。
Agentic RAG——RAGをエージェントで拡張する
Agentic RAGはエージェントがRAGプロセスを動的に制御する設計で、従来RAGの「単一パス」制約を超えます。
従来のRAGが「クエリ→検索→回答」の固定パイプラインであるのに対し、Agentic RAGはエージェントが検索戦略を動的に決定し、不十分な検索結果を自己評価して追加検索を行い、複数の検索結果を統合する自己修正ループを持つ。
Agentic RAGが有効な場面は以下のような場合だ。
- ユーザーの意図が曖昧で、単一クエリでは必要な情報を特定できない場合
- 複数の異なるデータソース（非構造化文書＋構造化DB＋リアルタイムAPI）を横断する必要がある場合
- 「最初の検索結果で足りなければ再検索する」という自己修正が精度に直結する場合
ただし単純なドキュメント参照タスクに対してAgentic RAGを適用すると、コストとレイテンシが増大するだけで精度改善が得られない。Agentic RAGへの移行は「従来のRAGパイプラインが限界に達したとき」に行うものであり、設計の初期段階から採用するものではない。
エージェントハーネスの視点からは、RAG・ツール使用・Agentic RAGのいずれを選んでも、ログ・権限管理・監視アラートの3要素は不変の設計要件として残る。情報取得手法の選択はこの基盤の上で行う設計判断だ。
規模別の留意点（SMB / エンタープライズ）
SMB向け: 最初から複雑なAgentic RAGを構築する必要はない。FAQへの問い合わせ・マニュアル参照・規程確認など、大半の業務は標準的なRAGで解決できる。Contextual Retrievalで検索精度を上げながらシンプルな構成を維持し、「RAGで解決できない」タスクが明確になった段階でツール使用を追加するアプローチが現実的だ。Kuuの運用管理サービスではRAGからツール使用への段階的な移行支援を提供している。
エンタープライズ向け: 複数チームが異なるデータソース（社内DB・外部API・文書管理システム）を使うマルチエージェント環境では、情報取得戦略を統一するプラットフォーム設計が重要になる。LLMゲートウェイでRAGとツール使用それぞれのコストを計装し、部門別に配賦できる体制を整えることで、コスト管理と統制の両立が可能になる。大規模なRAG基盤・Agentic RAG統合の設計についてはKuuの大規模AI基盤支援（RDE）で対応している。
参考
- Contextual Retrieval — Anthropic News
- What Is Agentic RAG? From LLM RAG to AI Agents — Weaviate Blog
まとめ
RAGとツール使用の選択は、「外部情報を使いたい」というニーズの背後にあるタスクの性質によって決まる。静的な知識参照・予測可能なコスト・単純なパイプラインが求められるならRAGを選び、Contextual Retrievalで精度を高める。副作用・計算・マルチソース統合が必要になったときにツール使用を追加し、従来のRAGでは対応できない複雑な検索戦略が求められるときにAgentic RAGへ移行するという段階的なアプローチが設計の基本だ。
どの段階でも、権限管理・可観測性・エラーハンドリングは情報取得手法に依存しない共通要件として設計する必要がある。エージェントの情報取得設計の見直しや実装支援が必要な場合は、Kuuへお問い合わせください。