コンテキストウィンドウ vs RAG vs ファインチューニング：何を選ぶか
LLM に自社データとタスクを扱わせる方法は三つ - すべてをコンテキストウィンドウに入れる、RAG（Retrieval-Augmented Generation）を接続する、モデルをファインチューニングする。各アプローチにはコスト、知識の更新速度、精度の上限が異なる。以下では仕組み、違い、チャットボット・サポートアシスタント・社内 copilot 向けの戦略選びを説明する。
一つの課題に対する三つのアプローチ
目的は同じ：自社の製品、ドキュメント、ポリシー、ドメインについて答えさせる - pre-training だけではない。コンテキスト、RAG、ファインチューニングの選択肢がある。
| アプローチ | 概要 | 知識の所在 |
|---|---|---|
| コンテキストウィンドウ | 必要なテキストをすべて prompt に | 各リクエスト |
| RAG | 関連断片を検索 + 生成 | インデックス / ナレッジベース |
| ファインチューニング | モデル重みを追加学習 | モデル重み |
多くの場合「どれか一つ」ではなく組み合わせる：RAG で事実、ファインチューニングでスタイルと形式、長いコンテキストで少数ドキュメントを一リクエストに。
コンテキストウィンドウ：すべて prompt に
コンテキストウィンドウは、1 リクエストでモデルが「見る」テキスト量（トークン）：system prompt、会話履歴、添付ファイル、指示。
仕組み
prompt に入れるもの：
- システム指示（「X 社の法務として答えよ」）；
- 関連ドキュメント全文または大きな塊；
- few-shot 例（「良い回答のサンプル」）。
現行モデル（GPT-5.6、Claude Fable 5、Gemini 3.5 Flash）は 100-200 万トークンのコンテキスト - 数百ページ。多くのシナリオでは別インフラ不要で足りる。
メリット
- インフラ最小 - ベクトルインデックスや embedding 更新パイプライン不要。
- 即時更新 - prompt テキストを変えれば知識も即更新。
- 透明性 - このリクエストでモデルが「見ている」内容が明確。
- 学習不要の few-shot - prompt 内の例で回答形式を指定。
デメリット
- 長さに比例してコスト増 - long-context 料金はベースの 1.5-2 倍が一般的。
- 容量上限 - 200 万トークンでも enterprise 全体のナレッジベースは入らない。
- needle in haystack - 非常に長いコンテキストの中間情報の利用が弱い（lost-in-the-middle）。
- レイテンシ - input トークンが多いほど初 token が遅い。
コンテキストを選ぶとき
- 小さく安定したコーパス：5-50 ドキュメント、単一製品、単一 FAQ。
- プロトタイプ / MVP - RAG スタックなしで 1 日で仮説検証。
- 全文が 1 リクエストに必要：契約 2 件の比較、PR 全体の code review。
- prompt 内容の完全制御（監査、コンプライアンス）。
RAG：検索 + 生成
RAG - 回答前にシステムがベースから関連断片を検索（ベクトル検索、BM25、ハイbrid）、prompt に挿入し、モデルが検索結果に grounded した回答を生成。
仕組み
典型的パイプライン：
- Ingestion - ドキュメントを chunk（300-1000 トークン）に分割、embedding 生成。
- Index - ベクトル DB（Pinecone、Qdrant、pgvector、Chroma）+ 任意で keyword index。
- Query - ユーザー質問 -> embedding -> top-k chunks。
- Generation - chunks + 質問 -> LLM -> 回答（ ideally 出典 citation 付き）。
知識更新：変更ドキュメントを reindex - モデル再学習不要。
メリット
- スケール - インデックスと chunking が適切なら数百万ページ。
- 鮮度 - 新ドキュメントは数分でインデックス、数週間ではない。
- 幻覚低減 - 提供断片に基づく；citation で信頼性向上。
- input 節約 - 関連 chunk のみ prompt に、全库ではない。
デメリット
- 複雑さ - chunking、embedding、reranking、評価、drift 監視。
- retrieval 品質 = 回答品質 - 検索が悪いと「完璧な」モデルでも回答が悪い。
- レイテンシ - 検索 + 生成の 2 段 + rerank。
- 重複と矛盾 - インデックス内のドキュメント版違いが混乱を招く。
RAG を選ぶとき
- 大きい / 頻繁に変わるベース：docs、wiki、チケット、Confluence、PDF アーカイブ。
- 回答に出典リンクが必要（サポート、法務、医療は注記付き）。
- ユーザー・リクエスト多数 - 500 ページを context に入れるより 5 chunk を引く方が安い。
- データを重みに焼き込めない（機密、テナント分離）。
ファインチューニング：知識を重みに
ファインチューニング - 自社データでベースモデルを追加学習：instruction/response ペア、対話、ドメインテキスト。重みがずれ、長い prompt なしでスタイル・用語・典型タスクをより良く扱える。
バリエーション：
- Full fine-tuning - 全パラメータ（高コスト、稀）。
- LoRA / QLoRA - frozen base 上のアダプタ（カスタムモデルの標準）。
- DPO / RLHF - 嗜好への整合（トーン、安全、形式）。
仕組み
- データセット構築：Q&A、サポート対話、コード例、JSON 回答。
- GPU でアダプタまたはフルモデルを学習（数時間〜数日）。
- fine-tuned endpoint または merged weights をデプロイ。
- inference 時 - 短い system prompt、モデルは既にパターンを「知っている」。
ファインチューニングは最新事実の代替にならない：価格、API 版、製品ニュースは RAG や fresh context なしでは reliably 「記憶」されない。
メリット
- スタイルと形式 - 統一トーン、JSON schema、回答テンプレート。
- prompt トークン削減 - 長い指示や大量 few-shot 不要。
- リクエストあたりのレイテンシとコスト - 同タスクで prompt が短い。
- 専門用語 - 医療、法律、社内 jargon。
デメリット
- 高コスト・時間 - データ、GPU、反復、eval；ML スキル必要。
- 陳腐化 - 新製品 = 再学習サイクルまたは RAG ハイbrid。
- 過学習リスク - training set を「暗記」し汎化が弱い。
- 稀な事実に弱い - 「policy v3 の 4.2 節を探せ」は RAG の方が良い。
ファインチューニングを選ぶとき
- 形式が反復的な安定タスク：分類、抽出、テンプレート要約。
- 短い prompt と数百万リクエストでの低レイテンシ。
- 高品質ラベル付き対話の大量（数千+ 例）。
- on-prem / air-gapped - chunk ごとに外部 API 不要な単一ローカルモデル。
主要基準での比較
| 基準 | コンテキスト | RAG | ファインチューニング |
|---|---|---|---|
| 知識量 | ウィンドウ上限まで | 実質無制限 | training set で限定 |
| 鮮度 | 即時（新 prompt） | 速い（reindex） | 遅い（retrain） |
| 初期コスト | 低 | 中 | 高 |
| リクエストコスト | context 長に比例 | 検索 + 短 context | prompt 低 |
| 幻覚 | 中リスク | retrieval 良ければ低 | 中、「自信ある」誤り |
| 出典 citation | prompt に手動 | 自然 | 難しい |
| インフラ | モデル API | ベクトル DB、パイプライン | GPU、MLOps |
| コンプライアンス / 監査 | prompt 完全制御 | retrieval ログ | 重みブラックボックス |
実践的な決定マトリクス
コンテキストから始める場合：
- 少数ドキュメントが 10-20 万トークンに収まる；
- 1 スプリントで POC が必要；
- 各リクエストが独特で「ファイル全体」が必要（diff、契約）。
RAG を追加する場合：
- ベースが成長または週次更新；
- 数千ページからの具体的事実への質問；
- citation と低い幻覚率が必要。
ファインチューニングを追加する場合：
- 95% のリクエストで回答形式が厳密に同一；
- RAG は動くが prompt が指示と例で膨張；
- データセットと eval 反復の予算あり。
2026 年 typical production スタック：
ファインチューニング済みモデル（スタイル + routing）
+ RAG（ナレッジベースからの事実）
+ 適度な context（system prompt、直近 N メッセージ、必要時 1-2 完全 doc）
よくある失敗
- 「100 万 context に全部入れる」 - 高コスト・遅い；同予算では retrieval 品質の方が良いことが多い。
- FAQ を RAG の代わりに fine-tune - モデルが古い価格を「記憶」；RAG か context の方が簡単。
- eval なし RAG - recall@k、faithfulness、人間レビューなしでは静かに劣化。
- chunk が小さすぎ - 段落の意味が失われる；大きすぎ - prompt ノイズ。
- reranking 無視 - cross-encoder なし vector top-5 は BM25 + rerank ハイbrid より劣ることが多い。
まとめ
コンテキストウィンドウ - 小容量向けの迅速スタートと完全制御。RAG - スケールするナレッジベース、最新事実、citation の標準。ファインチューニング - 安定した振る舞いと形式への投資であり、事実百科ではない。
多くの corporate アシスタントでは RAG + 短い system prompt が最適；品質またはリクエストコストの measurable 改善が学習を正当化するときに fine-tuning を追加。長い context は「1 shot で doc 全文」向けの定点利用であり、組織全体検索の代替ではない。
よくある質問
非常に長いコンテキストで RAG を置き換えられるか？
理論上 - 小コーパスなら可能。実務では ** rarely 得策**：コストとレイテンシは prompt 長に線形、長 context 中間の情報利用は弱い。RAG は関連部分のみ引き、大アーカイブにスケール。例外 - 「ファイル全文を読め」：code review、契約 2 版の比較、200 ページ PDF 分析。
corporate チャットボットに fine-tuning は必須か？
開始時は必須ではない。多くの internal copilot とサポート bot は RAG + 良い system prompt で足りる。fine-tuning は参照対話が数千件、統一形式（JSON、チケット、CRM フィールド）、リクエストあたり token 節約が critical なときに意味がある。まず RAG で baseline を測る - メトリクスなし fine-tuning は often ペイしない。
RAG と fine-tuning どちらが安いか？
RAG は upfront が安い：ベクトル DB、embedding API、GPU クラスタ不要。fine-tuning は開始が高い（データ、学習、deploy）が、高トラフィックで各 prompt から長い指示と few-shot を除けるなら リクエストコストを下げられる。6-12 ヶ月 TCO を比較：RAG infra + embedding refresh vs retrain コストと fine-tuned inference。
各アプローチで知識はどのくらいの頻度で更新するか？
コンテキスト - 各リクエスト（現行 prompt）または新テンプレート版デプロイ時。RAG - ドキュメント変更に応じて：incremental reindex は数分〜数時間；full rebuild は schedule または embedding モデル変更時。ファインチューニング - 振る舞いやドメイン変更時：リリース間隔は数週間〜数ヶ月；事実（価格、リリース）は依然 RAG または tool calls。
三つすべてを組み合わせられるか？
はい。優れた production システムはそうしている。 fine-tuned モデルがスタイルと routing（「ベース検索が必要か」）を決める。RAG が最新断片を持ってくる。context に system ルール、会話履歴、時に「全文読む」タスク用の 1 完全 doc。重要なのは役割分担 - 事実は RAG、振る舞いは fine-tuning、制約と few-shot は prompt - 同じテキストを全層で重複させないこと。