# AIエージェント開発の意思決定ポイント 🎯 ポイント LLMにドメイン知識を与えたい。RAG？ファインチューニング？ロングコンテキスト？ 「とりあえずRAGで」と思考停止していませんか？この三択、実は知識の性質によって最適解がまったく異なります。選び間違えると、古い情報で回答し続けたり、出典を示せなかったり、トークンコストが爆発したり。正しく選ぶための判断軸を整理しましょう。 📋 概要 AIエージェントにドメイン固有の知識を持たせる方法は大きく3つあります。RAG（検索拡張生成）はベクトルDBなどから関連情報を検索してプロンプトに注入する方式。ファインチューニング（FT）はモデルの重みを追加学習で調整して知識を焼き込む方式。ロングコンテキストは大きなコンテキスト窓にドキュメントをそのまま投入する方式です。それぞれ知識の格納場所・更新サイクル・コスト構造が根本的に異なるため、ユースケースに応じて主軸を1つ選ぶ必要があります。 🔍 意思決定のポイント 判断の核心は「知識がどのくらいの頻度で変わるか」と「出典の明示が必要か」です。 📌 知識の鮮度が命なら → RAG一択。FAQや価格、在庫情報など頻繁に変わるデータは、インデックスを更新するだけで即座に反映されます。FTでは再学習に日〜週単位かかり、現実的ではありません。 📌 出典を示す必要があるなら → これもRAG。「この回答の根拠はどのドキュメントの何ページか」を提示できるのはRAGだけです。FTで焼き込んだ知識は「モデルがそう知っている」状態であり、事後に追跡不可能。説明責任が求められる環境では致命的です。 📌 出力の様式・口調を統一したいなら → FT。「常に法務文書の形式で出力する」のようなスタイルの一貫性は、RAGで例を注入しても安定しません。FTでモデルレベルに染み込ませることで、推論時の例示注入が不要になり、コンテキスト窓の節約にもなります。 📌 少数の文書を丸ごと理解させたいなら → ロングコンテキスト。契約書全体の解釈のように文書構造が重要な場合、チャンク分割で文脈が断絶するRAGよりも、全文をそのまま投入する方が精度が高くなります。 💡 要点と詳細 🔹 RAGの本質的な強みは「知識とモデルの分離」です。知識はインデックスに、推論能力はモデルに。この分離により、知識の更新がモデルの再学習を必要としません。ただし検索品質に依存するため、チャンク分割・埋め込みモデル・リランキング戦略のチューニングが品質を左右します。 🔹 FTの本質的な強みは「行動様式の安定的な変容」です。繰り返し同じ形式で出力する場面では、推論コストがRAGより低くなりえます。ただし知識の更新にはデータセット準備→学習→検証のサイクルが必要で、機動力に欠けます。 🔹 ロングコンテキストの本質的な強みは「実装の単純さ」です。ベクトルDB、検索パイプライン、チャンク分割、FTのインフラがすべて不要。ただしトークン課金がそのままコストに直結し、"Lost in the Middle"問題（窓の中盤の情報に注意が薄れる）もあるため、大量の文書には向きません。 ⚖️ トレードオフ RAGは鮮度と出典追跡に優れるが、検索パイプラインの構築・運用が必要。FTは様式の一貫性に優れるが、知識の更新が遅く出典が不透明。ロングコンテキストは実装が最も簡単だが、コストとスケーラビリティに制約あり。 🏆 実務での定石は「様式はFT、事実はRAG」のハイブリッド。FTで出力形式・口調・専門用語をモデルに染み込ませ、RAGで最新の事実情報を注入する。ロングコンテキストは、RAGのチャンク分割では失われる文脈が重要な場面で補完的に使います。 🛠️ ユースケース 🏢 社内ナレッジベースQ&A → RAG。ドキュメントは日々更新され、回答には出典の提示が求められる。 ⚖️ 法務文書レビュー → FT＋RAG。法務特有の口調と形式はFTで統一し、最新の判例や規制はRAGで注入。 📄 契約書の全体解釈 → ロングコンテキスト。契約書1通を丸ごと投入し、条項間の関係を把握させる。 🏥 医療情報提供 → RAG必須。出典の明示が絶対要件であり、情報の鮮度も重要。FTで焼き込んだ医療知識はハルシネーションと区別できず危険。 迷ったらRAGから始めてください。ほとんどの業務システムでは知識は更新されるものであり、出典を示す能力は信頼性の基盤です。 #AIエージェント# #ソフトウェアアーキテクチャ#