RAG とコンテキスト設計はどう違う？使い分けの判断軸

「RAG（Retrieval-Augmented Generation）」と「コンテキスト設計」はどちらも AI に外部情報を渡して回答精度を上げる技術です。ただし、目的・実装・運用が異なります。プロジェクトの初期段階で「どちらを使うべきか」を見誤ると、過剰投資や低精度に繋がります。

RAG の本質

RAG は、ユーザーの質問に応じて 外部データベースから関連情報を検索し、それを AI に渡して回答させる仕組みです。

• 動的選択: 質問ごとに必要な情報を取り出す
• 大規模対応: 数百 GB のドキュメントでも扱える
• 更新容易: ドキュメントを追加すれば新情報に対応
• 実装コスト: ベクトル DB・検索インフラ・チャンク戦略が必要

コンテキスト設計の本質

コンテキスト設計は、プロンプトと一緒に AI に渡す前提情報・参考資料の設計です。

• 静的提示: 毎回同じ情報を渡す（or 限られた組み合わせ）
• 小〜中規模: モデルの context window 内に収まる量
• 即時対応: 構造を整えるだけで運用開始
• 実装コスト: プロンプト整理のみ

4 つの判断軸

両者の選択は次の 4 軸で考えると分かりやすいです。

軸	RAG が向く	コンテキスト設計が向く
情報量	100 万トークン超	100 万トークン以内
更新頻度	毎日〜毎週	月次〜半年
精度要求	検索精度に依存（中〜高）	文書構造で安定（高）
運用コスト	インフラ + 継続運用必要	プロンプト管理のみ

特に Claude Opus 4.7 の 1M context が登場したことで、「中規模ナレッジは RAG なしで全部入れる」選択肢が現実的になりました。社内マニュアル 30 〜 50 ページ程度なら、RAG を組まずに全部コンテキストに入れる方がシンプルかつ高精度です。

併用パターン

RAG とコンテキスト設計は 併用 が有効な場合もあります。

パターン 1: RAG + 静的システムプロンプト

• システム: 役割定義、トーン、ブランドガイドライン（変わらない）
• RAG: 質問に応じて関連 FAQ を取り出して渡す

カスタマーサポート Bot で典型的な構成です。

パターン 2: 静的コンテキスト + 動的補完

• 基本情報は毎回コンテキストとして渡す
• 不足時のみ RAG で追加情報を取得

社内ナレッジ Bot で、コアな情報は常に渡し、専門的な質問の時だけ RAG が動く構成。

パターン 3: RAG の前段にコンテキスト設計

RAG 自体の精度を上げるために、検索クエリ生成プロンプト や 取得後の整形プロンプト をコンテキスト設計する。

どちらを使うべきか、簡易判定

• 「社内マニュアル 1 冊を使いたい」 → コンテキスト設計
• 「過去 5 年の議事録 + 全社員の知見」 → RAG
• 「顧客ごとに変わる契約書を見せたい」 → コンテキスト設計（顧客別にプロンプト切替）
• 「毎日数百件のサポート問い合わせを Bot で対応」 → RAG + 静的システム

迷ったら まずコンテキスト設計で MVP を作り、限界が来たら RAG に進化させる、が現実的です。

PrompTune で運用する

PrompTune の コンテキスト診断モード では、AI に渡す前提情報の品質を 5 軸でスコアリングします。RAG を導入する前にコンテキスト設計を見直すと、不要な投資を避けられます。