AI応答のキャッシュでコストと速度を改善｜効かせ所の見極め
月末、AI機能の請求額を見て、少し息を止めたことはありませんか。
使われているのはいいことのはずなのに、金額だけがじわじわ伸びていく。ログをたどると、似たような問い合わせが何度も同じように飛んでいる。しかも利用者からは「返ってくるのが遅い」と言われている——コストと体感速度の両方で押されている状態は、なかなかしんどいものです。
そこで効くのがキャッシュ、つまり「一度聞いた答えを手元にしまっておいて、次に同じことを聞かれたら、それを出す」やり方です。考え方は昔からあるものですが、AI機能では効き方が少し違います。1回あたりが高くて遅い呼び出しを丸ごと省けるので、当たったときの効果が大きい。そのかわり、当ててはいけないところに当てると事故になる——ここの見極めが全部です。
結論：AI応答のキャッシュは、難しいものから入れない。まず①完全一致キャッシュ——同じ入力にはしまってある答えを返す、いちばん素直な形から始めます。鍵（キャッシュキー）には入力そのものだけでなく、モデル名・プロンプトの版・パラメータ・そして「誰のものか」を必ず含める。ここを落とすと、他の利用者の回答が出てしまいます。次に②プロンプトキャッシュ——長い共通の前置き（システムプロンプトや仕様書）を毎回送っている場合、提供元の仕組みで入力側の負担を減らせます。変わらない部分を前に、変わる部分を後ろに置くのが条件。③意味が近い問い合わせに過去の答えを返す（セマンティックキャッシュ）は最後。効きますが、誤って別の答えを返す危険があるので、範囲を絞ってから。そして入れる前に、ログで「同じ入力が何割あるか」を数える。数えずに作ると、効かないキャッシュを保守することになります。
全部を一度にやらなくて大丈夫です。 今日は「同じ入力がどれくらい来ているか」を数えるだけでも、判断の材料はそろいます。
何が起きているのか——AI機能は「同じ質問」が集まりやすい
まず、いま起きていることを整理させてください。AIを組み込んだ機能では、次のような重なりが自然に生まれます。
- 社内向けの問い合わせは、同じ質問に集中する：FAQ、規程の確認、手順の問い合わせ。人が変わっても聞くことは似ています。
- 画面から呼ぶAIは、入力の選択肢が限られている：分類・要約・タグづけなど、決まった型の入力が繰り返し流れます。
- バッチ処理は、同じデータを何度も通す：再実行のたびに、前回と同じレコードにも同じ処理が走ります。
- 開発中の試行錯誤も、同じ呼び出しの繰り返し：これは本番のコストではありませんが、地味に効いています。
つまり、AI機能は構造的に「同じ入力」が集まりやすい。にもかかわらず、毎回律儀に問い合わせているのが今の状態です。ここに気づけたなら、それはもう改善の入口に立っています。
そしてもうひとつ。キャッシュを入れると効くのは、お金だけではありません。
- 速度：呼び出しを丸ごと省けるので、待ち時間が大きく減ります。体感の改善は、利用者にいちばん伝わります。
- レート制限（一定時間に投げられる回数の上限）に余裕ができる：呼び出し回数が減れば、混み合う時間帯に弾かれにくくなります。見積もり方はAI APIの料金とレート制限を見積もる｜本番前の型に整理しています。
- 安定する：同じ問い合わせに毎回わずかに違う答えが返るのは、業務では扱いにくいものです。キャッシュが当たっている間は、答えがぶれません（この揺れそのものについてはAIの回答が日によって変わる｜再現性のなさと付き合う型で分解しています）。
ここで焦らずにいきましょう。効くと分かっていても、当てどころを間違えると事故になるのがキャッシュです。順番に見ていきます。
① 完全一致キャッシュ——まずここから
いちばん素直で、いちばん安全なのがこれです。入力から鍵を作り、同じ鍵の答えがしまってあればそれを返す。無ければAIに聞いて、返ってきた答えをしまう。 それだけです。
鍵に何を入れるか
ここが実質すべてです。入力の本文だけを鍵にすると、後で必ず困ります。最低限、次を混ぜてください。
- 入力の本文（正規化してから）：前後の空白、改行コード、全角半角の揺れをそろえてからハッシュにします。そろえるほど当たりますが、意味が変わる正規化（数字や記号を落とすなど）はしないこと。
- モデル名とバージョン：モデルを差し替えたのに古い答えが出続ける、を防ぎます。
- プロンプトの版：プロンプトを直したら鍵が変わるようにします。ここを入れておかないと、改善したのに前の答えが返ってくるという、いちばん気づきにくい不具合になります。プロンプトに版をつける運用は本番プロンプトのバージョン管理｜変更で壊さない運用の始め方にまとめました。
- 主なパラメータ：temperature（出力のばらつき具合の設定）や出力形式の指定など、答えが変わる設定は鍵に含めます。
- 「誰のものか」＝権限の範囲：ここが最重要です。次で詳しく書きます。
他人の回答を返さないために
キャッシュ事故でいちばん怖いのが、別の利用者の答えが出てしまう型です。原因はたいてい一つで、鍵に権限の情報が入っていないこと。
- 利用者ごと・テナントごとに答えが変わる問い合わせなら、鍵にその識別子を入れる。「Aさんの契約内容は」に対する答えを、Bさんに返してはいけません。
- 参照できる資料の範囲が人によって違うなら、その範囲も鍵に入れる。社内文書を検索して答える作りだと、ここが特に効きます。
- 逆に、誰が聞いても同じ答えでいい問い合わせは、共有していい。「経費精算の締め日は」のような全社共通の質問は、全員で1つの答えを使い回せます。共有していいものと、してはいけないものを最初に分ける——これが設計の第一歩です。
どこまでを共有可としてよいかの線引きは、社内データをAIに渡す前の線引き｜情報漏えいを防ぐ型の考え方がそのまま使えます。迷ったら共有しない側（利用者ごとに分ける）に倒す。効きは落ちますが、事故は起きません。
いつ捨てるか
しまいっぱなしにすると、今度は古い答えが残り続けます。捨て方は3つ用意しておくと安心です。
- 期限（TTL）で自然に消す：問い合わせの性質に合わせます。制度や規程に関わるものは短め、変わらない事実は長めに。迷ったら短めから始めて、効きを見ながら延ばすほうが安全です。
- 元データが変わったら消す：参照している文書やマスタが更新されたら、関係する分をまとめて捨てます。更新の通知が拾える作りにしておくと楽です。
- 手で全部捨てられるようにしておく：おかしな答えがしまわれてしまったとき、その場で全消しできるボタンや手順があるかどうかで、夜の落ち着き方がまるで違います。これは必ず先に作っておきたいところです。
そして、しまう前に一度だけ確かめるのも効きます。形式が壊れた出力や、明らかにエラーめいた応答をキャッシュしてしまうと、その間ずっと同じ壊れた答えを配り続けることになります。出力の確かめ方はAI出力を業務データに書き戻す前のバリデーション設計｜守る順番と、形式まわりならAIの構造化出力（JSON）を安定させる｜崩れたときの復旧までが下敷きになります。
② プロンプトキャッシュ——長い前置きを毎回送っているなら
完全一致が当たらない場合でも、効かせられる余地があります。入力の前半が毎回ほとんど同じケースです。
長いシステムプロンプト、社内ルールの説明、コードや仕様書の丸ごと添付。こうした「変わらない前置き」を毎回送っていると、入力側の負担が積み上がります。多くの提供元が、この共通部分を使い回す仕組み（プロンプトキャッシュ）を用意しています。
現場で押さえておきたいのは、次の点です。
- 変わらない部分を前に、変わる部分を後ろに置く：先頭から見て一致している範囲が対象になるため、前置きの途中に日時やユーザー名など毎回変わるものを混ぜると、そこから先が効かなくなります。「毎回変わるものは後ろへ」——この並べ替えだけで効くことがあります。
- 前置きが短いと効かないことがある：一定の長さを超えないと対象にならない仕組みが多いため、短いプロンプトでは期待しないほうがいいです。
- 料金の扱いと保持時間は提供元ごとに違う：割引率、保持される時間、対象モデルはサービスによって異なり、更新も入ります。必ず利用中のサービスの公式ドキュメントで、いまの条件を確認してください。 ここは伝聞で決めないほうがいい部分です。
- 機密の扱いも一度確認する：共通部分をサービス側に保持させる仕組みなので、社内の取り決めに照らして問題ないかを見ておくと安心です。
完全一致キャッシュが「呼び出しごと省く」のに対し、プロンプトキャッシュは「呼び出しは行うが入力側を軽くする」もの。役割が違うので、両方入れても構いません。
③ 意味が近い問い合わせに当てる——最後に、範囲を絞って
「送料はいくらですか」と「配送料っていくらかかりますか」は、文字は違いますが同じ質問です。これを同じものとみなして過去の答えを返すのが、意味の近さで当てるキャッシュ（セマンティックキャッシュ）です。文章の意味をベクトル（数値の並び）に変換して、近いものを探す仕組みを使います。
効きます。社内FAQのように言い回しが揺れる用途では、完全一致では当たらなかった分がまとめて当たるようになります。ただし、近いだけで同じではない問い合わせに、別の答えを返してしまう危険があります。
- 「似ている」の閾値は、必ず実データで決める：過去の問い合わせログを使って、どこまで近ければ同じ質問と言えるかを目で確かめます。厳しめから始めるのが鉄則です。
- 適用する範囲を絞る：全機能に一律で効かせず、まずは「答えが1つに定まる、影響の小さい問い合わせ」だけに。金額・契約・個人に関わるものは外しておきます。
- 当たった根拠を残す：どの過去問い合わせに当てたかをログに残しておくと、「なぜこの答えが出たのか」を後から説明できます。
- 利用者が「これじゃない」と言える出口を作る：聞き直せるボタンひとつで、誤配の被害はかなり小さくなります。
近さの測り方や埋め込みの詰め方は、RAGの精度が出ないときの見直し所｜チャンク分割と埋め込みの詰め方と地続きです。すでにRAGを組んでいるなら、その仕組みを流用できます。
効かせ所の見極め——この4つで判断する
どこに入れるかで悩んだら、対象の問い合わせを次の4つで見てください。4つとも「はい」なら、迷わず入れていい場所です。
- 同じ入力が繰り返し来るか：これが無いと、そもそも当たりません。まずログで数える。 ここを飛ばさないでください。
- 答えが少しの間、古くても許されるか：在庫数や進行中の案件の状態など、鮮度が命のものは向きません。
- 利用者をまたいで共有していいか／分ければ済むか：分ければ済むなら鍵に識別子を足すだけです。分けても意味がある（同じ人が繰り返す）かも一緒に見ます。
- 答えが揺れないほうが嬉しいか：業務処理なら、たいてい嬉しいです。逆にアイデア出しのように毎回違う案が欲しい用途では、キャッシュは邪魔になります。
向かない場所に入れないことも、立派な設計判断です。 全部の呼び出しにキャッシュを敷こうとすると、鍵の設計が複雑になり、事故の芽だけが増えます。
具体例——社内FAQに完全一致キャッシュを入れてみる
イメージが湧きやすいように、よくある形で追ってみます。
社内の問い合わせに答えるAI機能があるとします。月の呼び出しログを取り出して、入力を正規化したうえで重複を数えてみたら、上位20種類の質問だけで全体の3割を占めていた——こういう分布は珍しくありません。締め日、申請の出し方、パスワードの直し方。人が変わっても、聞くことは似ています。
ここで入れるのは、次の形です。
- 全社共通で答えが変わらない質問は、鍵に利用者IDを入れず、全員で共有する。
- 自分の申請状況を聞くような質問は、鍵に利用者IDを入れて分ける。そもそも繰り返しが少ないので、当たらなくても構いません。
- 期限は、まず短めに設定して様子を見る。規程が改定されたら、その分野の鍵をまとめて捨てる。
- ログに、当たったか外れたかを1行だけ残す。
これだけで、当たった分の呼び出しはそのまま消え、その分は待ち時間もほぼゼロになります。派手な作り込みではありませんが、こういう地味な一手がいちばん効きます。
効いているかを測る——入れて終わりにしない
キャッシュは、入れた瞬間がいちばん効いていて、そこから静かに劣化していくものです。プロンプトを直せば鍵が変わり、問い合わせの傾向が変われば当たらなくなる。だから、最低限これだけは見えるようにしておきます。
- ヒット率（当たった割合）：機能ごと・画面ごとに見ます。下がったら、たいていプロンプトかモデルを変えた直後です。
- 減った呼び出し回数と、その分のコスト：上に報告するときの材料にもなります。数字の見せ方は「で、効果あったの？」AI活用の成果を数字で報告するコツが使えます。
- 応答時間：当たったときと外れたときを分けて見ると、効果がはっきり分かります。
- 捨てた回数と理由：期限切れなのか、元データの更新なのか。ここが見えると、期限の設定を調整できます。
何をログに残すかの考え方はAI機能の効果測定｜導入後に見るログと指標の設計に整理しています。測っていないキャッシュは、効いているかどうか誰にも分かりません。 1行のログでいいので、最初から入れておきましょう。
つまずきやすいところ
先に知っておくと、避けられるものを挙げます。責める意図はまったくありません。どれも普通に踏むところです。
- プロンプトを直したのに、古い答えが出続ける：鍵にプロンプトの版が入っていないとき。入れ忘れがいちばん多いのがここです。
- 他人向けの答えが返ってしまう：鍵に権限の情報が無いとき。設計時に「これは共有していいか」を1問だけ自分に聞く習慣が効きます。
- 壊れた出力をしまってしまった：しまう前の確認と、全消しの手順で守れます。
- エラーや空の応答までキャッシュしてしまう：失敗した応答は原則しまわない。ここは明示的に分岐を書いておきます。
- 正規化をやりすぎて、違う質問が同じ鍵になる：空白や改行をそろえるところまでにとどめ、意味を変える加工はしないこと。
- ヒット率を測っていない：効いていないキャッシュを、保守だけし続けることになります。
キャッシュが外れたときの振る舞い（AIが混み合って返らないときにどうするか）は、AI出力が不安定なときのフォールバックとリトライ設計と合わせて決めておくと、全体が落ち着きます。
明日からやること（まずこの3つ）
大がかりな改修は要りません。順番はこれで大丈夫です。
- ログで「同じ入力の割合」を数える（30分）：入力を正規化して重複を数えるだけ。割合が低ければ、キャッシュは入れないという判断ができます。それも立派な成果です。
- いちばん多い問い合わせが通る1画面だけに、完全一致キャッシュを入れる：鍵には入力・モデル名・プロンプトの版・パラメータ・権限の範囲を混ぜる。期限は短めから。全消しの手順も同時に用意します。
- ヒット率のログを1行だけ足す：当たったか外れたかが分かれば十分です。1週間見れば、次にどこへ広げるかが自分で決められます。
一度で全部そろえなくて大丈夫です。 今日ログを数えて「思ったより重複が多い」と分かったなら、それだけで打ち手はもう見えています。
AI応答キャッシュのチェックリスト
入れる前と、入れた後にさっと確認します。全部に○が要るわけではなく、気になる所だけで十分です。
入れる前の見極め
- ログで「同じ入力の割合」を数えたか
- 答えが少し古くても許される用途か
- 利用者をまたいで共有していい問い合わせか、分ける必要があるかを整理したか
- 答えが揺れないほうが嬉しい用途か（毎回違う案が欲しい用途ではないか）
鍵（キャッシュキー）の設計
- 入力の本文を正規化しているか（意味を変える加工をしていないか）
- モデル名・バージョンを含めているか
- プロンプトの版を含めているか
- 答えが変わるパラメータを含めているか
- 権限の範囲（利用者・テナント・参照できる資料）を含めているか
しまい方・捨て方
- 期限（TTL）を決めたか（迷ったら短めにできているか）
- 元データが更新されたときに捨てられるか
- 手で全部捨てる手順・ボタンを用意したか
- エラー・空の応答・形式が壊れた出力をしまわない分岐があるか
測る
- ヒット率をログに出しているか
- 減った呼び出し回数とコストを見られるか
- 当たったとき・外れたときの応答時間を分けて見られるか
広げるとき
- 長い前置きがあるなら、変わらない部分を前に寄せたか（プロンプトキャッシュ）
- 利用中サービスの料金・保持時間の条件を公式ドキュメントで確認したか
- 意味の近さで当てる場合、閾値を実データで決め、範囲を絞ったか
- 誤配に気づいたとき、利用者が聞き直せる出口があるか
この記事のまとめ
請求額が伸びているのも、応答が遅いのも、あなたの設計が悪かったからではありません。AI機能は、放っておくと同じ問い合わせを律儀に何度も投げてしまう——その性質に、まだ手当てをしていなかっただけです。
やることは、意外と地味です。ログを数えて、いちばん多いところに完全一致キャッシュを入れて、鍵に権限とプロンプトの版を混ぜて、ヒット率を1行残す。 難しい仕組みは、それが効くと分かってからで十分間に合います。
そして、キャッシュは「AIに聞かなくて済む場面を見つける仕事」でもあります。全部をAIに投げるのではなく、投げなくていいものを見分ける。それは、AIに追われるのではなく、AIの使いどころを自分の手に取り戻す作業だと思います。
「AIを活用しろ」と言われる側にいると、足すことばかり求められがちです。でも現場を実際に楽にするのは、こういう引く工夫だったりします。
今日ログを1回数えたなら、それはもう改善の始まりです。数字が思ったほどでなくても、「ここにキャッシュは効かない」と分かったこと自体が前進です。次の一手を選ぶときの材料が、ひとつ増えました。