← すべての記事

AIシステムの構築：RAGからエージェントへ

14分で読めます

多くのチームはRAGから始め、その限界に気づき、次にファインチューニングを追加します。どちらも検索と推論の問題を解決します。しかし、どちらもオーケストレーションは解決しません。いつ行動するか、何体のエージェントを生成するか、いつ停止するか、コンセンサスとは何を意味するか——これらの判断です。私はマルチエージェント審議システム（Python 3,500行、86フック、141テスト）を構築し、これら3つすべてに対応しました。

TL;DR

RAGはクエリ時にドキュメントを検索します。ファインチューニングはドメインデータでモデルの重みを修正します。どちらも検索と推論のツールです。しかし、どちらもオーケストレーションには対応していません。複数のエージェントの調整、コンセンサスの検証、あるタスクに1回のモデル呼び出しが必要か12回必要かの判断——これらは別の問題です。私はブログ品質システムを構築する中でこの壁にぶつかりました。33記事にわたって並列リンティング、深度スコアリング、引用検証、LLM評価が必要でした。解決策は、信頼度トリガー付きの審議、スポーンバジェット管理、4段階コンセンサス検証を備えたエージェントオーケストレーション層でした。この記事ではRAGとファインチューニングの選択について解説し、その後、多くのガイドが触れないところまで踏み込みます——エージェントが必要になったとき何が起こるかです。

Part 1：RAGとファインチューニングの比較

2024年のDatabricksの調査によると、企業AIチームの78%がまずRAGを選択しましたが、34%が後にファインチューニングの方がより良いアプローチだったと気づき、平均3.2ヶ月の実装時間を浪費していました。1

この判断は二者択一ではありません。手法を問題に合わせることが重要です。

RAGが優れるケース

頻繁に変更される知識。 RAGはクエリ時に最新のドキュメントを検索します。ナレッジベースが毎日更新される場合（製品ドキュメント、サポート記事、規制関連書類）、RAGは再学習なしに最新情報を提供できます。2

出典の明示が必要な場合。 RAGは検索が明示的なソースリストを生成するため、特定のドキュメントを引用できます。規制産業（医療、金融、法律）では、出典の明示はコンプライアンス要件であることが多いです。3

大規模なナレッジベース。 1,000万件のドキュメントに対するRAGシステムは、検索品質が一定であれば100万件のものと同等のパフォーマンスを発揮します。ファインチューニングされたモデルはモデルサイズによって決まる容量の限界があります。4

ファインチューニングが優れるケース

ドメイン固有の推論パターン。 RAGは情報を提供します。ファインチューニングは能力を提供します。医療診断の会話でファインチューニングされたモデルは鑑別診断のパターンを学習します——症状の重み付け方法、まれな疾患を考慮すべきタイミング、フォローアップの質問の組み立て方です。RAGは医学知識を供給できますが、推論パターンには重みの調整が必要です。5

厳密な出力フォーマット要件。 ファインチューニングは構造化出力（JSON、XML、特定のスキーマ）をプロンプトエンジニアリングよりも確実に強制できます。フォーマットの失敗が下流でエラーを引き起こすシステムでは、ファインチューニングの方が高い信頼性を提供します。6

レイテンシが重要なアプリケーション。 RAGは検索レイテンシを追加します——クエリの埋め込み、ベクトルデータベースの検索、ドキュメントの取得、プロンプトへの注入です。200ミリ秒未満の応答目標があるアプリケーションでは、ファインチューニングによる検索の排除が必要になる場合があります。7

比較マトリクス

次元 RAG ファインチューニング 両方の併用
知識の鮮度 数時間 数週間〜数ヶ月 数時間
セットアップコスト 低〜中 中〜高 高
クエリあたりのコスト 高い（検索＋生成） 低い（生成のみ） 最も高い
出典の明示 ネイティブ対応 困難 部分的
出力フォーマット制御 中程度 高い 高い
ドメイン推論 弱い 強い 強い
ナレッジベースサイズ 無制限 モデルに依存 無制限
レイテンシ 高い 低い 最も高い
ハルシネーション制御 良い（ドキュメントに基づく） ケースによる 最良

組み合わせアプローチ

多くの本番システムは両方の手法を組み合わせています。ドメインの推論パターンと出力フォーマットでモデルをファインチューニングし、RAGでクエリ時に最新かつ出典を追跡可能な知識を提供します。ファインチューニングされたモデルはドメインについてどのように推論するかを知っています。RAGシステムは何について推論するかを提供します。8 これはシステムレベルでの複合コンテキストです。検索のたびに推論層が豊かになり、その推論層が次の検索を改善します。

Part 2：エージェントが必要になるとき

RAGとファインチューニングは検索と推論を処理します。しかし、どちらもオーケストレーションには対応していません。あるタスクに1回のモデル呼び出しが必要か12回必要かの判断、並列ワーカーをいつ生成するか、その出力をどう検証するか、いつ人間にエスカレーションするかの決定です。その基礎となる考え方——コンテキストはアーキテクチャである——は別の記事で掘り下げており、AGENTS.mdのパターンの記事では、オーケストレーションのルールをエージェント設定にどう落とし込むかを扱っています。

私はブログ品質インフラを構築する中でこの壁にぶつかりました。評価、修正、検証が必要なブログ記事が33本ありました。1記事あたり1回のモデル呼び出しでは不十分でした。各記事にリンティング（12モジュール）、深度スコアリング（5シグナル）、可読性分析、引用検証、LLM評価が必要でした。これらを順次実行すると時間がかかりすぎ、調整なしに並列実行すると競合や不整合な結果が生じました。

解決策はRAGの追加でもファインチューニングの改善でもありませんでした。エージェントオーケストレーション層でした。

エージェントオーケストレーションに必要なもの

従来のMLパイプラインは線形フローを前提としています——データ、前処理、モデル、評価、デプロイ。9 エージェントシステムは非線形です。エージェントは以下のような動作をする可能性があります：

  1. 自身の信頼度を評価し、助けが必要だと判断する
  2. 異なる専門性を持つ5つの並列サブエージェントを生成する
  3. それらの出力を収集しランク付けする
  4. エージェントが早すぎる収束をしていないか（集団思考）を検出する
  5. 品質閾値に対してコンセンサスを検証する
  6. 最終的な推奨を生成する

各ステップには、RAGやファインチューニングでは提供されないインフラが必要です。

Part 3：私が構築したもの

アーキテクチャ

私の審議システムは12モジュールにわたるPython 3,500行で構成されています：

Deliberation System
├── confidence.py       Triggers deliberation based on ambiguity/complexity/stakes
├── state_machine.py    Workflow: idle → research → ranking → consensus
├── agents.py           5+ persona templates (Architect, Security, Performance...)
├── context_isolation.py  RLM L0-L3 layers prevent context contamination
├── ranking.py          Stack ranking with weighted consensus calculation
├── spawner.py          Parallel agent spawning via Task API
├── conformity.py       Detects groupthink and premature convergence
├── mailbox.py          Multi-round debate protocol
├── memory.py           Cross-session learning and persona tracking
├── scaling.py          Dynamic agent count based on complexity
├── prd_generator.py    Converts decisions into product requirements
└── observability.py    Session metrics and audit replay

このシステムは86のフックの上に構築されており、6つのライフサイクルポイント（PreToolUse、PostToolUse、Stop、その他3つ）で操作をインターセプトします。すべてのエージェント生成、ファイル書き込み、gitコマンドが検証を通過します。

信頼度トリガー

すべてのタスクに5つのエージェントの議論が必要なわけではありません。4つの次元を評価する信頼度スコアリングアルゴリズムを構築しました（ナレッジのトリアージで使っているのと同じ加重合成のパターンです）：

  1. 曖昧性 — クエリに複数の妥当な解釈があるか？（パターンマッチ：「最善の方法」「〜すべきか」「比較」「メリットとデメリット」）
  2. ドメインの複雑性 — 専門知識が必要か？（パターンマッチ：「アーキテクチャ」「セキュリティ」「パフォーマンス」「データベーススキーマ」）
  3. リスク — その決定は可逆か？（パターンマッチ：「本番」「破壊的変更」「削除」「セキュリティ脆弱性」）
  4. コンテキスト依存性 — より広範なシステムの理解が必要か？

スコアは3つのレベルに対応します：

  • HIGH（0.85以上）： 審議なしで続行
  • MEDIUM（0.70〜0.84）： 信頼度メモを記録して続行
  • LOW（0.70未満）： フルのマルチエージェント審議をトリガー

閾値はタスクの種類に応じて適応します。セキュリティの判断には85%のコンセンサスが必要です。ドキュメントの変更には50%で十分です。これにより、単純なタスクの過剰設計を防ぎつつ、リスクの高い決定には適切な精査を確保します。

スポーンバジェットの問題

最初の実装では深さベースの再帰制限を使用していました——深さ0のエージェントが深さ1を生成し、深さ1が深さ2を生成し、深さ3でブロック。これはすぐに失敗しました。審議エージェントは直列ではなく並列で実行する必要があります。深さ1の5つのエージェントは深い再帰ではありません。幅広いコラボレーションです。

修正策はスポーンバジェットモデルです。ルートエージェントがバジェット（最大12エージェント）を受け取ります。そのバジェットを使って並列ワーカーを生成します。ワーカーは残りのバジェットを継承しますが、それを超えることはできません。これにより暴走するチェーンを防ぎつつ、審議に必要な並列実行を可能にします。

実際のテストは、翻訳されたブログ記事に対して10のレビューエージェントを実行したときに訪れました。再帰ガードはスポーンを深さの増加としてカウントしたため、エージェント4から10をブロックしました。バジェットモデルに切り替えた後、10体すべてが正常に実行されました。深さは1を超えることはありませんでした。幅がタスクに合わせて拡張されたのです。10

コンセンサス検証

エージェントの完了後、審議後フックが4つのチェックを実行します：

  1. フェーズの準備状況 — 審議がリサーチからランキングに進んでいるか？
  2. エージェントの定足数 — 少なくとも2つのエージェントが完了したか？（タスクの種類ごとに設定可能）
  3. コンセンサス閾値 — 合意が要求されるレベルに達しているか？（基準70%、セキュリティは85%）
  4. 反対意見の文書化 — エージェントが同意しない場合、懸念事項が記録されているか？

チェック4は予想外の気づきでした。初期の実行では、エージェントが最初の回答に単に同意するだけの「コンセンサス」が生成されていました。適合性検出器は現在、早すぎる収束にフラグを立てます——すべてのエージェントが最初のラウンドで高い類似度スコアで合意した場合、システムは2回目の敵対的分析ラウンドを強制します。

苦い経験から学んだこと

アトミックなファイル書き込みが重要。 複数のエージェントが同じ状態ファイルに同時に書き込むとJSONが破損しました。修正策：.tmpファイルに書き込み、その後mvでアトミックに移動します。OSは同一ファイルシステム上でのmvがアトミックであることを保証します。この1行の変更で、競合状態のカテゴリ全体が排除されました。

コンテキストの分離が集団思考を防ぐ。 各エージェントは4つの層（L0：基礎知識、L1：タスク固有、L2：ペルソナ固有、L3：ラウンド固有）を通じて独立したコンテキストを受け取ります。分離がなければ、エージェントは解決空間を探索するのではなく、最初のもっともらしい回答に収束します。分離があれば、セキュリティエージェントとパフォーマンスエージェントは異なる前提から出発するため、本当に異なる結論に到達します。

エージェントインフラのテストはアプリケーションコードより難しい。 このシステムには141のテストがあります——フックの動作に関する48のbash統合テスト、ライブラリモジュールに関する81のPythonユニットテスト、12のエンドツーエンドパイプラインシミュレーションです。プロジェクトメモリ内のすべての障害事例（スポーンバジェットのブロッキング、引用検出の誤検知、ブログプランファイルが誤って記事として配信される問題）は、修正後にテストケースになりました。エージェントのバグはタイミング、順序、並行状態に依存するため、アプリケーションのバグより再現が難しいです。

人間とエージェントの役割分担

人間の責任 エージェントの責任
問題の定義 パイプラインの実行
信頼度の閾値設定 閾値内での実行
コンセンサスの要件定義 コンセンサスの計算
品質ゲートの基準策定 品質ゲートの適用
エラー分析 エラー検出
アーキテクチャの決定 アーキテクチャの選択肢提示
ドメインコンテキストの注入 ドキュメント生成

パターンは明確です。人間は組織的コンテキスト、倫理的判断、戦略的方向性を必要とする決定を担います。エージェントは大規模な可能性空間にわたる計算的探索を必要とする決定を担います。11 この役割分担については、エージェントアーキテクチャ分析でさらに詳しく探求しています。

エージェント型MLエンジニアはパイプラインを手書きしません。エージェント型MLエンジニアは目標、制約、評価基準を定義します。エージェントが実装ループを処理します——提案、実行、評価、反復。人間の役割はビルダーからアーキテクトへとシフトします——ガードレールの設定、出力のレビュー、エージェントが持たないドメインコンテキストを必要とする判断の実行です。12

重要なポイント

AIシステムを始めるエンジニアへ： - 頻繁に変更される知識や出典の明示が必要なユースケースにはRAGから始めましょう。RAGは数日で機能するベースラインを提供しますが、ファインチューニングはデータ準備に数週間かかります - ドメイン推論と最新の知識の両方が必要な場合は、RAGとファインチューニングを組み合わせましょう - 1タスクあたり複数のモデル呼び出しが必要な場合、エージェントオーケストレーションが必要です。これはRAGやファインチューニングとは異なるエンジニアリング課題です（オーケストレーション手法の直接比較はClaude CodeとCodexの比較をご覧ください）

エージェントシステムを構築するチームへ： - エージェントを構築する前に信頼度スコアリングを構築しましょう。ほとんどのタスクには審議は不要であり、エージェントをいつ使うかを知るシステムは、エージェントそのものよりも価値があります - 並列エージェントアーキテクチャには深さ制限ではなくスポーンバジェットを使いましょう。深さ制限はエージェント審議に必要な幅広いコラボレーションパターンをブロックします - コンセンサスの存在だけでなく、コンセンサスの品質をテストしましょう。早すぎる合意は合意がないことよりも悪いです。なぜなら、偽りの確信を生み出すからです

よくある質問

検索拡張生成（RAG）とは何ですか？

RAGは、クエリ時にナレッジベースから関連ドキュメントを検索し、ユーザーの質問と一緒にLLMのコンテキストへ注入する手法です。これにより、モデルの応答は学習データだけに頼るのではなく、具体的で最新の情報に基づいたものとなります。知識が頻繁に変わる場合、出典の明示が求められる場合、ナレッジベースが大規模な場合にRAGは特に有効です。2024年のDatabricksの調査では、企業AIチームの78%が最初のAIアーキテクチャとしてまずRAGを選んでいました。

AIエージェントはRAGシステムとどう違うのですか？

RAGは検索とグラウンディングを担当します——モデルが推論するための適切な情報を与える役割です。エージェントはオーケストレーションを担当します——いつ行動するか、タスクに何回のモデル呼び出しが必要か、いつ並列ワーカーを生成するか、その出力をどう検証するかを決めます。RAGシステムは質問に答えます。エージェントシステムは複数のモデル呼び出しを調整し、コンセンサス検証を管理し、そのタスクに1回の推論が必要か12回必要かを判断します。両者は補完関係にあり、エージェントはRAGを数あるツールの1つとして使うことがよくあります。

RAGとファインチューニングはどちらを使うべきですか？

知識が頻繁に（毎日）更新される場合、出典の明示が必要な場合（規制産業）、ナレッジベースが非常に大きい場合はRAGを使いましょう。ドメイン固有の推論パターン（医療診断、法務分析）、厳密な出力フォーマットの遵守、200ミリ秒未満のレイテンシが求められる場合はファインチューニングを使います。多くの本番システムは両方を組み合わせています——ドメイン推論と出力フォーマットのためにファインチューニングし、最新かつ出典を追跡可能な知識はクエリ時にRAGで提供するのです。詳しい内訳は上記の比較マトリクスをご覧ください。

エージェントオーケストレーションとは何で、いつ必要になりますか？

エージェントオーケストレーションとは、1つのタスクのために複数のAIモデル呼び出しを調整するインフラ層です——いつ並列ワーカーを生成するか、その出力をどう検証するか、いつコンセンサスに達したとみなすか、いつ人間にエスカレーションするかを決めます。1回を超えるモデル呼び出しが必要なタスク——異なる観点からの並列分析、信頼度をトリガーとする審議、品質ゲートを伴う多段階パイプライン——ではオーケストレーションが必要になります。私の審議システムは、スポーンバジェット、適合性の検出、4段階のコンセンサス検証によって、1タスクあたり最大12エージェントを調整します。

AIエージェントによる質の低いコンセンサスをどう防ぐのですか？

浅い合意を防ぐ仕組みは3つあります。第1に、コンテキストの分離により各エージェントが独立したコンテキスト（基礎知識、タスク固有、ペルソナ固有、ラウンド固有の層）を受け取るため、エージェントは本当に異なる結論に到達します。第2に、適合性検出器が早すぎる収束にフラグを立てます——すべてのエージェントが最初のラウンドで高い類似度スコアで合意した場合、システムは敵対的な分析を強制します。第3に、コンセンサス閾値はタスクの種類に応じて適応し、セキュリティの判断には85%の合意が必要な一方、ドキュメントの変更には50%で十分です。Ralph Loopアーキテクチャは、あらゆるライフサイクルポイントで発火するフックを通じてこれらの制約を適用します。

参考文献

  1. Databricks, “State of Enterprise AI Architecture,” Databricks Research, 2024. ↩

  2. Lewis, Patrick et al., “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks,” NeurIPS 2020. ↩

  3. Gao, Luyu et al., “Precise Zero-Shot Dense Retrieval without Relevance Labels,” ACL 2023. ↩

  4. Borgeaud, Sebastian et al., “Improving Language Models by Retrieving from Trillions of Tokens,” ICML 2022. ↩

  5. Singhal, Karan et al., “Large Language Models Encode Clinical Knowledge,” Nature, 620, 172-180, 2023. ↩

  6. Hu, Edward J. et al., “LoRA: Low-Rank Adaptation of Large Language Models,” ICLR 2022. ↩

  7. Miao, Xupeng et al., “Towards Efficient Generative LLM Serving: A Survey from Algorithms to Systems,” arXiv:2312.15234, 2023. ↩

  8. Anthropic, “RAG + Fine-Tuning: A Practical Architecture Guide,” Anthropic Cookbook, 2024. ↩

  9. Sculley, D. et al., “Hidden Technical Debt in Machine Learning Systems,” NeurIPS 2015. ↩

  10. Author’s experience building multi-agent deliberation infrastructure, documented in project MEMORY.md. 86 hooks, 141 tests, 12 Python modules. ↩

  11. Sambasivan, Nithya et al., “‘Everyone Wants to Do the Model Work, Not the Data Work’: Data Cascades in High-Stakes AI,” CHI 2021, ACM. ↩

  12. Hollmann, Noah et al., “Large Language Models for Automated Machine Learning,” arXiv:2402.08355, 2024. ↩

関連記事

エージェント検索は実行環境の問題です

新しいarXiv論文が、Chronos、Claude Code、Codex、Gemini CLIでgrepとベクトル検索を比較しました。エージェント検索の品質は実行環境の層にあります。

13 分で読める

クリーンアップレイヤーこそが本当のAIエージェント市場である

Charlie Labsはエージェント構築から、エージェントの後始末をする側へとピボットしました。AIエージェント市場は生成から証明へと移行しています。クリーンアップこそが永続的なレイヤーなのです。

17 分で読める

Ralphループ：自律型AIエージェントを一晩中稼働させる方法

ストップフック、スポーンバジェット、ファイルシステムメモリを備えた自律エージェントシステムを構築しました。失敗から学んだことと、実際にコードをシップする仕組みを紹介します。

11 分で読める