コンテキストウィンドウ vs RAG vs ファインチューニング：何を選ぶか

LLM に自社データとタスクを扱わせる方法は三つ - すべてをコンテキストウィンドウに入れる、RAG（Retrieval-Augmented Generation）を接続する、モデルをファインチューニングする。各アプローチにはコスト、知識の更新速度、精度の上限が異なる。以下では仕組み、違い、チャットボット・サポートアシスタント・社内 copilot 向けの戦略選びを説明する。

一つの課題に対する三つのアプローチ

目的は同じ：自社の製品、ドキュメント、ポリシー、ドメインについて答えさせる - pre-training だけではない。コンテキスト、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 した回答を生成。

仕組み

典型的パイプライン：

1. Ingestion - ドキュメントを chunk（300-1000 トークン）に分割、embedding 生成。
2. Index - ベクトル DB（Pinecone、Qdrant、pgvector、Chroma）+ 任意で keyword index。
3. Query - ユーザー質問 -> embedding -> top-k chunks。
4. 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 - 嗜好への整合（トーン、安全、形式）。

仕組み

1. データセット構築：Q&A、サポート対話、コード例、JSON 回答。
2. GPU でアダプタまたはフルモデルを学習（数時間〜数日）。
3. fine-tuned endpoint または merged weights をデプロイ。
4. 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 不要な単一ローカルモデル。

主要基準での比較

実践的な決定マトリクス

コンテキストから始める場合：

• 少数ドキュメントが 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 ハイブリッドより劣ることが多い。

RAG やファインチューニングを急がなくてよいケース

• データも質問も少ない。 数件のドキュメントとまれな質問なら、長めの context を prompt に入れれば十分 - RAG インフラやファインチューニングは元が取れるまで時間がかかる。
• プロセスの責任者がいない。 RAG は index の鮮度を、ファインチューニングは dataset の品質を見る担当者が必要 - 専任者がいないと回答品質は気づかないうちに劣化する。
• プロダクトとデータがまだ不安定。 価格・プロセス・文言が頻繁に変わる間は、ファインチューニングは特にリスクが高い - 変更のたびに再学習サイクルが必要になる；この段階では短い context と prompt の調整の方が有利。
• 品質評価の時間がない。 recall、回答精度、実際の質問でのテストには反復が必要 - 「1 週間で、追加調整なし」の結果が必要なら、最もシンプルな選択肢である context window から始め、負荷の増加に応じて RAG とファインチューニングを追加する。

まとめ

コンテキストウィンドウ - 小容量向けの迅速スタートと完全制御。RAG - スケールするナレッジベース、最新事実、citation の標準。ファインチューニング - 安定した振る舞いと形式への投資であり、事実百科ではない。

多くの corporate アシスタントでは RAG + 短い system prompt が最適；品質またはリクエストコストの measurable 改善が学習を正当化するときに fine-tuning を追加。長い context は「1 shot で doc 全文」向けの定点利用であり、組織全体検索の代替ではない。

開発、AI導入、サイト保守など、ご案件に合わせたサポートが必要な場合 - お問い合わせください。

よくある質問

非常に長いコンテキストで 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 - 同じテキストを全層で重複させないこと。

この記事の用語

LLM — Large Language Model — 大規模言語モデル

RAG — Retrieval-Augmented Generation — 検索拡張生成

pre-training — large-scale training of a model before task fine-tuning — タスク微調整の前に行う大規模事前学習

system prompt — hidden instructions that steer the model for a task — モデルの振る舞いを決める非表示の指示

few-shot — prompting with a few examples — 少数例を入れたプロンプト手法

embedding — numeric vector that captures text meaning — 文の意味を数値化したベクトル

long-context — model that can take a very large prompt in one go — 一度に非常に長いプロンプトを扱えるモデル

code review — peer check of a change before it is merged — マージ前に同僚が変更を確認すること

MVP — Minimum Viable Product — 実用最小限の製品

Pinecone — managed vector database for similarity search — 類似検索向けマネージドベクトルDB

pgvector — PostgreSQL extension for vector search — PostgreSQL向けベクトル検索拡張

Qdrant — vector database for similarity search — 類似検索向けベクトルデータベース

chunking — splitting documents into retrieval-friendly pieces — 検索しやすい単位への文書分割

chunks — small text pieces indexed for retrieval — 検索用に切った短いテキスト片

Chroma — open-source embedding database for RAG apps — RAG向けオープンソース埋め込みDB

reranking — reordering search results by relevance — 検索結果を関連度順に並べ替えること

retrieval — finding relevant context before generation — 生成前に関連文脈を取り出すこと

top-k — keep only the k most likely next tokens when sampling — サンプリングで上位k個のトークンだけ残す方式

Confluence — Atlassian wiki for team documentation — チーム文書向けAtlassian Wiki

fine-tuning — additional training of a model on domain data — 業務データでモデルを追加学習すること

inference — running a trained model to get predictions — 学習済みモデルを実行して結果を得ること

endpoint — specific API URL that accepts requests — リクエストを受け付ける具体的なAPIのURL

air-gapped — network fully isolated from the public internet — 公衆インターネットから完全に隔離された網

QLoRA — Quantized Low-Rank Adaptation — 量子化低ランク適応

LoRA — Low-Rank Adaptation — 低ランク適応

RLHF — Reinforcement Learning from Human Feedback — 人間フィードバックによる強化学習

GPU — Graphics Processing Unit — グラフィックス処理装置

on-prem — software hosted in your own infrastructure — ベンダー雲ではなく自前インフラで動かす方式

production — live environment serving real users — 実ユーザー向け本番環境

ML — Machine Learning — 機械学習

PoC — proof of concept / pilot

faithfulness — how well an answer sticks to the retrieved sources — 回答が取得ソースにどれだけ忠実か

fine-tune — train a model further on domain data — 業務データでモデルを追加学習する

cross-encoder — rerank model that scores query and document together — クエリと文書をまとめて採点する再順位付けモデル

chunk — small text piece indexed for retrieval — 検索用に切った短いテキスト片

context window — maximum text a model can process at once — モデルが一度に処理できる最大文量

baseline — reference measurement before changes

CRM — Customer Relationship Management — 顧客関係管理

TCO — Total Cost of Ownership — 総所有コスト