← すべての記事

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

2分で読めます

多くのチームは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回必要かの判断、並列ワーカーをいつ生成するか、その出力をどう検証するか、いつ人間にエスカレーションするかの決定です。

私はブログ品質インフラを構築する中でこの壁にぶつかりました。評価、修正、検証が必要なブログ記事が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やファインチューニングとは異なるエンジニアリング課題です

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

参考文献

  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. ↩