CAG（Cache-Augmented Generation）とは？RAG との使い分けを 62 万トークンまで実測

CAG（Cache-Augmented Generation）とは、資料を検索で絞り込まずに全文をプロンプトの前置きに入れ、その部分をキャッシュして質問ごとに使い回す方式です。RAG で起きる検索の取りこぼしを無くせる一方、資料が大きいほど 1 回の処理は重くなります。当社は、試験用に作った架空の社内規程の 24 問を、約 1 万から 62 万トークンまで 5 段階の規模で Amazon Bedrock の Claude に答えさせ、検索の 3 通りと Self-Route（検索で答え、足りなければ全文へ回す方式）と比べました。3.6 万トークンでは CAG が正答率・費用・待ち時間のすべてで検索と同等以上で、10.8 万トークンで費用と待ち時間がほぼ並びました。30 万トークンを超えると、正答率は保てたものの、最初の文字が出るまでの時間と 1 問の費用が検索の 2〜7 倍に膨らみました。

社内規程や FAQ に答える AI チャットを検討している情報システム・DX の担当者向けに、方式の選び方を数字でまとめます。

CAG は、探してから渡す RAG とは逆に、全部を渡して、渡した部分をキャッシュしておく方式です。

仕組みと、よく引用される原論文の数字の読み方を先に整理します。

RAG は、資料を数百字ずつの断片（チャンク）に分けて埋め込みや BM25 で索引を作り、質問のたびに関係の深い数件だけをモデルに渡します。CAG は索引を作りません。資料の全文を毎回同じ順番でプロンプトの先頭に置き、末尾にキャッシュの区切りを付けて、後ろに質問だけを足します。コンテキストウィンドウが広がったことで成り立つ方式で、今回使った Claude の Sonnet と Haiku は、62 万トークンの資料もそのまま受け付けました。

最初の 1 回は全文を読み込んでキャッシュに書き込み、2 回目からはそれを読み出して、質問の部分だけを新たに処理します。原論文の KV キャッシュ（注意の計算の途中結果）の保存に当たるのが、API ではプロンプトキャッシュです。

キャッシュが効くのは、区切りまでの前置きが 1 バイトも違わないときだけです。寿命は既定で 5 分で、読まれるたびに延び、1 時間の設定もあります。Bedrock のバンコクリージョンでの Claude Sonnet の単価は、100 万トークンあたり通常の入力が 2.00 USD、キャッシュの書き込みが 2.50 USD（寿命 5 分）、読み込みが 0.10 USD でした（執筆時点の参考値です。最新の料金は AWS の料金ページで確かめてください）。読み込みは通常の入力の 20 分の 1 なので、同じ前置きを 2 回使えば書き込みの割増を取り戻せます。キャッシュの設計はマルチテナントでのプロンプトキャッシュの記事でも扱っています。

CAG という名前は、論文「Don't Do RAG: When Cache-Augmented Generation is All You Need for Knowledge Tasks」（arXiv:2412.15605、WWW '25 の short paper）から広まりました。8B 規模のオープンモデル（Llama）で、SQuAD と HotpotQA の文書を 2 万〜8.5 万トークンにまとめ、BM25 とベクトル検索の RAG と比べています。

よく引用される「約 40 倍速い」は、HotpotQA の最大の設定（約 8.5 万トークン）で、キャッシュなしで全文を渡した場合の 92.08 秒と、CAG の 2.26 秒の比です。RAG との比ではありません。同じ設定の正確さ（BERTScore）は、CAG の 0.7407 が、BM25 で上位 5 件を渡す RAG の 0.7535 をわずかに下回りました。SQuAD の最大の設定（約 5 万トークン）では、CAG の 0.7734 が RAG の最高値 0.7658 を上回っています。

原論文が示したのは、資料が小さければ全文を渡しても RAG と同程度に正確で、キャッシュで全文の遅さを避けられる、ということです。今回は、この「資料が小さければ」がどこまでかを確かめました。

実在の会社の資料は使わず、試験用に書いた架空の社内規程と、規模を増やすための法令の本文で測りました。

資料と問い、比べた方式は次のとおりです。

資料の中心は、試験用に書いた架空の在タイ日系製造業の社内規程です。就業規則、出張旅費規程の旧版と改定版、経費精算の FAQ、情報セキュリティ規程、休暇の申請手順、組織と連絡先の 7 文書・41 節で、旧版と改定版で金額や期限が違う箇所と、改定前のまま直されていない FAQ を、わざと入れました。

問いは 24 問で、4 つに分けています。1 か所を読めば答えられる問いが 8 問、2 つの資料を組み合わせる問いが 6 問、旧版や FAQ と改定版が食い違う問いが 5 問、資料に答えの無い問い（育児休業の期間、定年など）が 5 問です。組み合わせる問いには、たとえば「6 万バーツの経費精算は誰が承認し、その人の名前は」があります。承認者の決まりは手順書に、名前は組織表にしか書いていません。

規模を増やすために、e-Gov 法令検索の API から、特許法・著作権法・建築基準法など、社内規程と関係の無い分野の法令の本文を足し、社内規程の 7 文書を法令の間に等間隔に散らしました。資料の量は、社内規程だけの約 1.1 万トークンから、3.6 万、10.8 万、31 万、62 万トークンまでの 5 段階で、答えは常に社内規程の側にあります。

採点は別の Claude（Sonnet）に正解と社内規程の全文を渡して行い、正解を 1 点、要点の一部が欠けたものを 0.5 点、誤りを 0 点としました。古い値の案内と資料に無い決まりの作話も別に記録し、正解以外の判定は理由を 1 件ずつ確かめました。

回答には、Amazon Bedrock のバンコクリージョン（ap-southeast-7）から global の推論プロファイルで Claude Sonnet と Claude Haiku を呼び、考える処理（thinking）は Sonnet ではツールの合間だけ（今回はツールを使わない）、Haiku では無効にしました。資料は Claude の search_result の形で渡して出典を付けさせ、指示文（食い違えば新しい方を優先、資料に無ければ無いと伝える）はどの方式も同じです。

比べた方式は 6 つです。CAG は全文を渡し、末尾にキャッシュの区切りを付けました。検索の 3 通りは、どれも Sonnet が答えます。1 つ目はベクトル検索だけ（Cohere の埋め込みモデル、上位 6 件）、2 つ目はベクトル検索と BM25 の順位を混ぜるハイブリッド検索（上位 6 件）です。3 つ目は Anthropic が公開した Contextual Retrieval（各チャンクに文書の中での位置づけを Claude Haiku で 50〜100 字書き足してから索引を作る方法）に Cohere の並べ替えモデルを重ね、上位 30 件を並べ替えて 6 件または 12 件を渡します。Anthropic の測定では、この組み合わせで上位 20 件の取りこぼしの率が 5.7% から 1.9% に下がっています。最後の Self-Route は、3 つ目の検索で答えさせ、資料が足りないとモデルが判断したときだけ CAG に回します。検索と Self-Route は、3.6 万と 62 万トークンの 2 段階で測りました。

待ち時間は、手元の端末から質問を送って回答の最初の文字が届くまでで、検索の方式は埋め込み（シンガポール）と並べ替え（東京）の往復を含みます。CAG の 2 問目以降はキャッシュを読む回で、別に先頭へ毎回違う 1 行を足してキャッシュを効かせない回も規模ごとに 2〜3 回測りました。費用は、返ってきたトークン数に価格 API の単価を掛けた計算値です。

CAG は 5 段階のどの規模でも 24 問中 23.5〜24 点で、検索は 21.0〜23.5 点でした。

差はほとんど、資料をまたぐ問いと、古い値の混入から来ています。

3.6 万トークンでは、CAG が正答率・待ち時間・費用のすべてで検索と同等以上でした。62 万トークンでも正答率は最も高かったものの、最初の文字まで中央値で 15 秒かかっています。

CAG の費用はキャッシュを読む回の平均です（最初の書き込みの費用は後述）。

検索の 3 通りの差は、主に資料をまたぐ問いで出ました。文脈の説明を足して並べ替えを重ねると、必要な節が上位 6 件に全部入った問いが、答えのある 19 問のうち 16 問（ベクトル検索だけ）から 18 問に増え、正答率も上がっています。法令を足して 62 万トークンにしても、検索の正答率はほとんど変わりませんでした。

どの検索でも落としたのが、「6 万バーツの経費精算は誰が承認し、その人の名前は」という問いです。承認者が管理本部長であることは手順書にあり、どの検索も正しく答えました。ところが名前は組織表にしかなく、その節には「経費」も「承認」も出てきません。質問と言葉が重ならないため、文脈の説明を足しても、並べ替えを重ねても上位 12 件に入りませんでした。検索の回答は「承認者の個人名については、渡された資料に記載がないため、お答えできません」で、資料の側には答えがあるのに、無いと答えています。

CAG は 62 万トークンの規模でも「管理本部長の名前は、組織と連絡先（2026年4月1日現在）によると佐藤です」と答えました。全文が見えているので、1 つ目の答え（管理本部長）を手がかりに 2 つ目（名前）を探せます。Self-Route の論文（Li ほか、EMNLP 2024）も、RAG が失敗する主な理由の 1 つに、前の答えが次に探すものを決める多段の問いを挙げています。

日当と宿泊費を足す問い（一般社員がチェンマイへ 2 泊 3 日）でも、ベクトル検索とハイブリッド検索は改定版の節を取りこぼしました。ベクトル検索の回答は旧版の日当と宿泊費で 4,200 バーツと計算し、ハイブリッド検索の回答は「2026年改定版の第5条（日当）は資料に含まれていません」と書いて、改定後の合計を出せていません。正しくは改定版で 5,900 バーツです。検索が必要な節を落とすと、モデルは手元の古い資料で答えを組み立ててしまいます。

食い違いを仕込んだ 5 問は、意外にも検索でもほぼ正しく答えました。旧版と改定版は見出しが同じで文面もよく似ているため、両方が一緒に取り出され、モデルが新しい方を選べたからです。

検索で問題になったのは、食い違いとは関係の無い問いのほうでした。「立て替えた経費はいつ振り込まれますか」に、文脈付き＋並べ替え（上位 6 件）の回答は、振込日（毎月 20 日締め、当月 25 日振込）を正しく答えたあとで、「なお、出張の精算については、帰着後14日以内に経費精算システムから申請することになっています」と付け加えました。14 日は FAQ に残っていた古い値で、改定版では 10 営業日以内です。FAQ の節だけが取り出され、改定版がモデルに見えていなかったため、古い値を現行の決まりとして案内しています。

こうした古い値の混入は、検索の方式で 1 条件あたり 0〜3 件、CAG では Sonnet・Haiku ともに 0 件でした。古い FAQ を消すか、改定のたびに直すのが根本の対策ですが、資料の全体が見える CAG は、こうした直し漏れの影響を受けにくい方式です。

正答率は 62 万トークンでも落ちませんでしたが、最初の文字までの時間と 1 問の費用は、資料の量に応じて増えました。

キャッシュが下げるのは主に費用で、大きな規模では待ち時間はあまり縮みません。

Sonnet でキャッシュを読む回の中央値は、10.8 万トークンまでは 2.5 秒未満でしたが、31 万トークンで 5.2 秒、62 万トークンで 15.0 秒になりました。

キャッシュありは 2 問目以降の 23 回、キャッシュなしは 2〜3 回の範囲です（1.1 万の Sonnet は 52.9 秒の外れ値 1 回を除く）。

Sonnet の 31 万トークンでは、キャッシュなしの 13.5〜16.2 秒が中央値 5.2 秒に縮みましたが、62 万トークンでは 19.3〜22.5 秒が 15.0 秒になっただけです。読み込みを省いても、長い前置きを参照しながら答えを作る処理は残るためとみられます（未確認）。

Haiku は小さな規模でも中央値で 3〜4 秒かかり、どの規模でも Sonnet より速くはなりませんでした。1.1 万トークンの回では、回答の長さは Sonnet と大差ないのに出力のトークン数が約 2 倍あり、原因は確かめていません。

キャッシュを読む回の費用は、Sonnet で 3.6 万トークンのとき 1 問 0.007 USD、62 万トークンのとき 0.066 USD でした。

単位は USD（出力を含む 1 回の平均）です。検索（文脈付き＋並べ替え、上位 6 件）は 3.6 万でも 62 万でも 1 問 0.012 USD 前後で、資料の量に左右されません。CAG の Sonnet は 10.8 万トークンで 0.014 USD とほぼ並び、31 万で約 3 倍、62 万で約 5.5 倍になります。問い合わせが 1 日 1,000 件なら、62 万トークンの CAG は 1 日 66 USD、検索は 12 USD です。

キャッシュの寿命は 5 分なので、問い合わせが 5 分以上途切れると、次の 1 問が書き込みの回になります。62 万トークンでは書き込みが 1 回 1.55 USD かかるため、問い合わせがまばらな時間帯ほど 1 問あたりの費用が膨らみます。寿命を 1 時間にすると、書き込みの単価は 100 万トークンあたり 2.50 USD から 4.00 USD（Sonnet）に上がります。

Haiku は 10 万トークン以下なら 1 問 0.001 USD 未満と桁違いに安く、正答率も 23〜24 点で Sonnet と大きな差はありませんでした。ただし入力が 10 万トークンを超える回は、入力・キャッシュ・出力の単価がすべて 5 倍の区分になり、表の 10.8 万トークン以上はこの単価で計算しています。

10.8 万トークンの全文で同じ前置きをもう 1 回送ると、107,510 トークンがキャッシュから読まれ、最初の文字まで 1.20 秒、費用は 0.013 USD でした。次に、先頭の資料に読点を 1 つ足しただけで送ると、キャッシュからの読み込みは 0 になり、107,511 トークンを書き込み直して 3.33 秒、0.270 USD かかりました。キャッシュは区切りまでの前置き全体が一致したときだけ使われるので、区切りが末尾の 1 か所だけなら、資料のどこを直しても全文を書き込み直すことになります。

運用では、資料の並び順を固定し、更新日時や利用者の名前のように毎回変わるものを区切りより前に入れないことが前提です。変わりにくい規程を前に、更新の多い FAQ やお知らせを後ろに置き、その境にも区切りを置けば（区切りは 1 回の呼び出しに 4 か所まで）、資料を直したときに作り直すのは後ろの部分だけで済みます。

また、出典を付けさせる search_result の形はブロック 1 つにつき約 110 トークン増え、社内規程の 41 節では 5,721 トークンが 10,386 トークンになりました。CAG では節を細かく分けすぎない方が安く済みます。

Self-Route は、資料に答えの無い質問ほど遅く高くなり、検索が半分だけ答えた問いは救えませんでした。

Self-Route は、まず検索で答えさせ、資料が足りないとモデルが判断したときだけ全文の CAG に回す方式です。論文（Li ほか）では、問いの 57〜82% を検索の側で答え、全文を渡すより費用を 39〜65% 下げながら、正確さをほぼ保てたと報告しています。

今回、全文に回ったのは 24 問中 5 問で、資料に答えの無い 5 問がそのまま回りました。62 万トークンでは、答えが無いことを確かめるために全文を読むので、この 5 問は最初の文字まで 9.2〜16.0 秒かかり、1 問の平均の費用も検索だけの約 2 倍（0.026 USD）になりました。一方、名前を答えられなかった承認者の問いは、検索の段で「資料に記載がない」と答えて終わり、全文には回っていません。渡された資料で一応の答えが書けると、モデルは資料が足りないとは判断しませんでした。

規程に無いことを聞かれる割合が高いほど、Self-Route の利点は薄れます。回すかどうかをモデルだけに任せず、「承認者」「担当者」のように別の資料が要りそうな問いは決まりで全文に回すなど、仕組みで補う必要があります。

今回の数字からは、資料が 10 万トークン前後までなら CAG、それを超えたら文脈付きのハイブリッド検索に並べ替えを重ねる形が目安になります。

今回の資料では、10 万トークンは約 10 万字に当たります。

資料が 10 万トークン前後までは CAG、30 万トークンを超えたら検索を選ぶのが、今回の測定から言える線です。

境目は Sonnet を Bedrock で使った場合の値です。Anthropic は Contextual Retrieval の記事で、資料が 20 万トークン未満なら全文をプロンプトに入れてよいと書いています。ただ、最初の文字までを中央値で 3 秒以内に収めたい問い合わせの用途では、今回の測定では 10 万トークン前後が上限でした。

更新の頻度と見せてよい範囲も判断に効きます。毎日更新される資料はその都度書き込みが要り、部署ごとに見せる資料が違えば組み合わせごとにキャッシュが分かれます。どちらも検索の方が扱いやすい条件です。検索を組む場合の作り方はハイブリッド検索の記事にまとめています。

問いは 24 問で、1 問の取りこぼしが 0.5〜1 点の差になります。点差の小さい条件どうしの優劣は言えません。足した法令は社内規程と分野の違う文章でした。部署ごとに少しずつ違う規程が並ぶような、似た内容の文書が多い環境では、検索の取りこぼしは増えると考えられ、CAG の正答率も下がる可能性があります。

CAG でも誤りは出ました。Haiku は 3.6 万トークンの回で、資料に無い取り次ぎの案内と存在しない項番を書き足し、62 万トークンの回では冒頭の一文と本文の結論が食い違う回答を 1 件返しています。

測ったのは Claude の Sonnet と Haiku の 2 つで、日本語の問いだけです。時間は手元の端末から Bedrock のバンコクリージョンを 1 問ずつ呼んだときの値で、同時に多くの問い合わせが来たときの待ち時間は測っていません。GraphRAG や、モデルが検索を繰り返す Agentic RAG も比べていません。

CAG と RAG の使い分けで、よく聞かれる 3 つの質問に答えます。

資料が 10 万トークン（今回の資料で約 10 万字）前後までで、更新の頻度が低ければ、CAG から始めるのが手軽です。索引も検索の仕組みも要らず、今回の測定では正答率も検索と同等以上でした。それを超える量か、利用者ごとに見せる資料が違うなら、文脈付きのハイブリッド検索と並べ替えを選びます。

起きます。CAG が減らすのは、検索で必要な資料が抜けたことによる誤りです。資料を読み違える誤りや、資料に無いことを作るハルシネーションは残ります。出典の付かない答えを止めるといった点検は、どちらの方式でも必要です。

区切りが末尾の 1 か所だけなら、資料のどこを直しても、次の 1 問で全文の書き込み直しになります。10.8 万トークンの資料では、読点 1 つの違いで 1 問の費用が 0.013 USD から 0.270 USD に上がりました。更新の多い資料を後ろにまとめてその手前にも区切りを置き、更新は時刻を決めてまとめて反映すると、作り直しの量と回数を減らせます。

CAG は資料の全文をキャッシュして使い回す方式で、検索の取りこぼしが起きません。架空の社内規程の 24 問では、どの規模でも 23.5〜24 点と、検索（21.0〜23.5 点）と同等以上でした。差が出たのは、別の資料を引かないと答えられない問いと、古い FAQ の値が紛れ込む問いです。

ただし 30 万トークンを超えると、キャッシュを使っても最初の文字まで中央値で 5〜15 秒、費用は検索の約 3〜5.5 倍になりました。10 万トークン前後までは CAG、それを超えたら文脈付きのハイブリッド検索に並べ替えを重ねるのが目安です。どちらでも、資料の並び順と更新の仕方、出典の点検は設計の段階で決めておく必要があります。

当社では、タイの拠点の社内規程や FAQ に答える AI チャットについて、資料の量と更新の頻度を測るところから、方式の選定と構築までを支援しています。詳しくは AI・DX 支援のご案内をご覧ください。

参考文献（2026 年 11 月 8 日に参照）

• Brian J. Chan ほか「Don't Do RAG: When Cache-Augmented Generation is All You Need for Knowledge Tasks」 https://arxiv.org/abs/2412.15605
• Anthropic「Introducing Contextual Retrieval」 https://www.anthropic.com/engineering/contextual-retrieval
• Zhuowan Li ほか「Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach」 https://arxiv.org/abs/2407.16833
• e-Gov 法令検索 https://laws.e-gov.go.jp/