投稿者 投稿日: カテゴリー ChatGPT
プロンプトキャッシュとは、繰り返し送る指示文の課金を9割引にする仕組みのことです。
商品3,000点に同じ生成指示を流すとき、指示文の部分は3,000回とも同じ内容を送ることになります。この重複部分をキャッシュ扱いにすると、入力単価が10分の1になります。GPT-5.6では、どこまでをキャッシュするかを明示的に指定できる「キャッシュブレークポイント」が導入され、この節約が設計で狙えるようになりました。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル（うるチカラ運営）の現場知見にもとづき、商品データ処理での組み方を4手順で整理します。
キャッシュの課金構造を先に押さえる
節約幅は課金構造で決まります。OpenAIのプロンプトキャッシュ解説によると、GPT-5.6以降のモデルでは、キャッシュへの書き込みが通常の入力単価の1.25倍、キャッシュからの読み出しが90%割引で課金されます。キャッシュの最短保持時間は30分です。
具体的な金額に落とします。GPT-5.6 Solの入力単価は100万トークンあたり5.00米ドルですが、キャッシュ読み出しなら0.50米ドルになります。書き込み時は1.25倍の6.25米ドル。つまり、同じ前置きを2回以上使うなら得、1回きりなら損という構造です。25%多く払って書き込み、2回目以降は90%引きで読む。損益分岐点は、単純計算で1.3回目あたりに来ます。商品数千点にバッチ処理をかける用途では、圧倒的に得になる領域です。
2026年7月30日には、下位2モデルの値下げも実施されました。Lunaは入力1.00米ドル・出力6.00米ドルから、入力0.20米ドル・出力1.20米ドルへ。Terraは入力2.50米ドル・出力15.00米ドルから、入力2.00米ドル・出力12.00米ドルへ改定されています。詳細はGPT-5.6 Lunaの値下げとEC運用への影響にまとめました。キャッシュの割引率は単価に対して掛かるため、値下げとキャッシュは重ねて効きます。
もう一つ、見落とされやすい項目があります。長いコンテキストを使うときの別料金です。Solには長文脈用のメーターが用意されており、入力5米ドル・出力30米ドルが、入力10米ドル・出力45米ドルへ上がります。全商品CSVを丸ごと読ませるような使い方では、この単価で計算する必要があります。キャッシュで節約したつもりが長文脈料金で相殺される、という事態を避けるため、試算の段階でどちらの単価が適用されるかを確認してください。
急がない処理にはBatchまたはFlexという選択肢もあり、こちらは50%引きになります。夜間に回す商品説明文の一括生成のような用途では、キャッシュとBatchの併用が最も安くなる組み合わせです。
日本のEC事業者の文脈で、この仕組みがなぜ効くのかを整理しておきます。楽天市場でもAmazonでもShopifyでも、商品ページに載せる文章の書き方には店舗ごとのルールがあります。文字数の上限、使ってはいけない表現、型番の書き方、送料の案内文。これらは商品が変わっても変わりません。つまり、EC運営でAIに投げる指示の大半は「変わらない部分」でできています。この構造は、キャッシュの恩恵を受けやすい典型例です。逆に、1件ずつ内容の異なる問い合わせ返信のような処理では、共通部分が短いため効果は限定的になります。どの業務にキャッシュ設計の手間をかけるかは、この共通部分の比率で決めてください。
4手順：ECの商品データ処理をキャッシュ前提で組む
第1手順は、プロンプトの前後分離です。キャッシュは前方一致で効くため、変わらない部分を必ず先頭に置きます。多くの店舗のプロンプトは、この順序が逆になっています。「以下の商品について説明文を書いてください。商品名は〇〇、価格は〇〇。条件は次の通りです」という書き方だと、商品ごとに変わる情報が前に来るため、後ろの長い条件文がキャッシュされません。
正しい順序は、役割定義・出力条件・禁止事項・出力フォーマットをすべて前に置き、商品固有の情報を最後に置く形です。この並べ替えだけで、キャッシュの効き方が変わります。
プロンプト1：キャッシュ前提のプロンプト再構成
以下は当社が商品説明文の生成に使っているプロンプトです。
プロンプトキャッシュが効くように、構造を再設計してください。
要件：
1. 商品ごとに変化しない部分（役割定義・条件・禁止事項・出力形式）をすべて前半にまとめる
2. 商品ごとに変わる変数だけを末尾に置き、{商品名}{価格}のような形で明示する
3. 前半部分の文字数と、おおよそのトークン数の目安を報告する
4. 元のプロンプトから意味が変わっていないことを、変更点の一覧で示す
現行プロンプト：{貼り付け}
第2手順は、共通前置きの厚みを意図的に増やすことです。キャッシュの効果は前置きが長いほど大きくなります。従来は「プロンプトは短く」が定石でしたが、キャッシュ前提では逆になります。自社のブランドトーン、禁止表現の一覧、過去の良い出力例を3つほど、すべて前置きに含める。前置きが2,000トークンあっても、2回目以降は0.2トークン相当の課金しか発生しない計算です。
現場で繰り返し見るのは、品質を上げるための指示を「長くなるから」と削っているケースです。キャッシュ構造を理解していれば、削る必要はありません。むしろ厚くしたほうが、品質と費用の両方で有利になります。
プロンプト2：共通前置きの拡充
以下の商品説明文生成プロンプトの前置き部分を、品質向上のために拡充してください。
追加する要素：
1. 当社のブランドトーンの定義（提供する情報から抽出）
2. 使用禁止の表現一覧（薬機法・景品表示法の観点で）
3. 良い出力例を3つ（提供する既存の商品説明文から選定）
4. 悪い出力例を2つと、なぜ悪いかの説明
条件：
- 前置きは2,000〜3,000トークンを目安とする
- 商品ごとに変わる情報は一切含めない
- 各要素の目的を1行のコメントで添える
現行の前置き：{貼り付け}
既存の商品説明文サンプル：{5点分を貼り付け}
第3手順が、ブレークポイントの配置です。GPT-5.6では、どのプレフィックスをキャッシュするかを明示的に指定できます。前置きの末尾、つまり商品固有情報が始まる直前に置くのが基本形です。
複数の商品カテゴリを扱う場合は、2段構えにします。全カテゴリ共通の指示を第1ブロック、カテゴリ固有の指示を第2ブロックとし、それぞれの末尾にブレークポイントを置く。こうすると、カテゴリが切り替わっても第1ブロックのキャッシュは生き続けます。食品と雑貨を交互に処理するような運用で効いてきます。
プロンプト3：ブレークポイント配置の設計
当社は以下のカテゴリの商品を扱っており、それぞれ説明文の書き方が異なります。
プロンプトキャッシュのブレークポイントをどこに置くべきか設計してください。
出力してほしいもの：
1. 全カテゴリ共通で使える指示の内容と、その概算トークン数
2. カテゴリ別に分ける必要がある指示の内容
3. ブレークポイントを置く位置（第1・第2の2段構えを前提）
4. 処理順序の推奨（カテゴリをまとめて処理するか、混在させるか）
カテゴリ一覧と各カテゴリの商品点数：{貼り付け}
現行のプロンプト：{貼り付け}
第4手順は、実測と検算です。設計どおりにキャッシュが効いているかは、実際の請求内訳を見ないと分かりません。OpenAIの利用ダッシュボードでキャッシュ読み出しトークン数が確認できるので、処理件数と照らし合わせます。想定より読み出し比率が低い場合、前置きに変動要素が混ざっているのが典型的な原因です。日付や時刻を前置きに入れていると、毎回別のプロンプト扱いになります。
プロンプト4：キャッシュ効率の診断
以下はAPI利用の内訳データです。プロンプトキャッシュが想定どおり効いているか診断してください。
診断項目：
1. 全入力トークンに占めるキャッシュ読み出しの比率
2. 想定される理論値との差
3. 差が生じている場合、考えられる原因を可能性の高い順に3つ
4. 30分の保持時間を踏まえ、処理の実行間隔に問題がないか
条件：
- データから読み取れない事項は「判定不可」とし、推測で埋めない
- 改善提案は、実装コストの低い順に並べる
利用内訳：{処理件数／入力トークン合計／キャッシュ読み出しトークン／実行時間帯}
前置きの内容：{貼り付け}
設計を壊す3つのパターン
最も多いのが、前置きへの変動要素の混入です。「本日は2026年7月31日です」「担当者は〇〇です」といった1行が入るだけで、キャッシュは無効になります。前置きに動的な値を入れない。この原則を守るだけで、キャッシュ効率は大きく変わります。日付が必要なら、商品固有情報のブロック側に置いてください。
次が、処理の間隔です。キャッシュの最短保持時間は30分なので、1時間おきに10件ずつ処理するような運用では、毎回キャッシュが切れています。同じ前置きを使う処理は、まとめて連続実行する。夜間バッチとして一気に流す設計が、キャッシュとは相性が良い形です。
3つ目は、前置きの頻繁な改訂です。品質改善のためにプロンプトを毎日いじると、そのたびにキャッシュが作り直されます。書き込みは1.25倍の単価なので、改訂の頻度が高いと逆に高くつきます。改訂は週次でまとめる、といった運用ルールを決めておくのが実務的です。
この3つに共通するのは、いずれも「効いていないことに気づかない」種類の失敗だという点です。処理そのものは正常に完了し、出力の品質も変わりません。変わるのは請求額だけで、それも月末にまとめて見るまで分かりません。だからこそ、第4手順の実測を運用に組み込む必要があります。月次でキャッシュ読み出し比率を1つの数字として記録しておけば、比率が落ちた月にすぐ気づけます。逆に、この数字を追わない運用では、半年後に「思ったより高い」と気づいて原因を探すことになります。
もう一つ、社内での説明のしかたにも触れておきます。キャッシュの話は仕組みが分かりにくく、経営層への説明で止まりがちです。伝えるべきは仕組みではなく、「同じ指示を繰り返し送る部分の料金が10分の1になる」という一点で足ります。技術的な詳細は担当者が押さえておけばよく、投資判断に必要なのは削減額の見込みです。
いくら下がるかの試算
商品3,000点、前置き2,500トークン、商品固有情報300トークン、出力800トークンという条件で、GPT-5.6 Solを使う場合を計算します。
キャッシュなしなら、入力は3,000点×2,800トークン＝840万トークンで42.00米ドル。キャッシュありなら、書き込み1回分が2,500トークン×6.25米ドル相当で0.016米ドル、読み出しが2,999回×2,500トークン＝約750万トークンで3.75米ドル、キャッシュ対象外の商品固有情報が90万トークンで4.50米ドル。入力の合計は約8.27米ドルになります。42.00米ドルが8.27米ドルへ、およそ8割の削減です。
出力側は240万トークンで72.00米ドルとなり、こちらはキャッシュの対象外です。全体では114.00米ドルが80.27米ドルへ、3割程度の削減になります。入力の比率が高い処理ほど効果が大きく、出力が長い処理では効果が薄まる。この関係を理解しておくと、どの処理から着手すべきかの判断がつきます。
出力が長い処理には、Batchの50%割引を重ねます。夜間バッチとして流せば、出力側も36.00米ドルに下がる計算です。急ぐ必要のない一括生成は、Batchに寄せるのが定石になります。
なお、下位モデルで足りる処理なら、モデルを落とすほうが効果は大きくなります。Lunaの入力単価はSolの25分の1です。キャッシュ設計に手をかける前に、まずモデル選定が適正かを確認してください。他社を含めた比較は主要モデルのコストと使い分け、軽量モデルでの大量処理はGemini 3.5 Flash-Liteでの商品データ処理にまとめてあります。
キャッシュ前提の設計が標準になる流れ
明示的なブレークポイントが提供されたことの意味は、コスト最適化が利用者側の設計責任になったという点にあります。従来は自動判定に任せるしかなく、効いているかどうかも分かりにくい状態でした。制御できるようになったぶん、設計しない事業者との差が開きます。
この流れは、プロンプトの位置づけも変えます。前置きが厚いほど有利という構造は、社内のノウハウをプロンプトに書き込むことを経済的に正当化します。ブランドトーン、禁止表現、良い例と悪い例。これまで担当者の頭の中にあった判断基準を、前置きとして明文化する。副産物として、担当者が変わっても同じ品質が出る体制になります。
AIエージェントが継続的にタスクを回す用途では、キャッシュの重要性はさらに上がります。エージェントは同じ文脈を何度も参照しながら動くため、キャッシュが効かない設計では費用が跳ね上がります。エージェント活用を視野に入れているなら、いまのうちにプロンプトの構造を整えておく価値があります。
一方で、キャッシュに最適化しすぎるリスクも指摘しておきます。前置きを厚くすると、モデルを乗り換えるときの移植コストが上がります。ベンダー固有の書式に依存した前置きを作り込むと、乗り換えの自由度が下がる。前置きの中身は汎用的な日本語で書き、ベンダー固有の指定はブレークポイントの設定など最小限にとどめるのが、長期的には安全な設計です。
よくある質問
プロンプトキャッシュは追加料金がかかりますか
はい、書き込み時のみ通常の入力単価の1.25倍がかかります。読み出しは90%割引になるため、同じ前置きを2回以上使う処理であれば全体では安くなります。1回きりの処理では割高になります。
キャッシュはどれくらい保持されますか
最短30分です。この時間内に同じ前置きで再度リクエストすれば、キャッシュが再利用されます。処理を1時間おきに分散させると毎回キャッシュが切れるため、まとめて連続実行する設計にしてください。
前置きは何トークンくらいが適切ですか
2,000〜3,000トークンを一つの目安としています。キャッシュが効く前提では長いほど有利ですが、モデルの応答が前置きに引きずられすぎると出力が硬くなることがあります。自社の商材で品質を確認しながら調整してください。
商品ごとに違う指示がある場合はどうしますか
カテゴリ単位で2段構えにします。全カテゴリ共通の指示を第1ブロック、カテゴリ固有の指示を第2ブロックとし、それぞれの末尾にブレークポイントを置きます。処理はカテゴリごとにまとめて流すと効率が上がります。
効果が出ているかどうやって確認しますか
OpenAIの利用ダッシュボードで、キャッシュ読み出しトークン数を確認します。全入力トークンに占める比率が想定より低ければ、前置きに動的な値が混ざっている可能性が高いです。日付や担当者名が典型的な原因になります。
Batchとキャッシュは併用できますか
併用の可否と割引の重ね方は、利用時点の料金体系を公式ドキュメントで確認してください。本記事執筆時点の情報では、Batchは50%引き、キャッシュ読み出しは90%引きとそれぞれ規定されていますが、併用時の計算方法までは確認できていないため要確認とします。
導入の最初の一歩は何ですか
現在使っているプロンプトの並べ替えです。変わらない部分を前に、商品固有の情報を後ろに移すだけで効果が出始めます。ここまでは実装コストがほぼゼロなので、ブレークポイントの設計より先に着手してください。
著者：齋藤竹紘（株式会社オルセル 編集長／5,000社以上のEC支援実績／書籍3冊）
参考文献
- OpenAI｜Prompt caching
- OpenAI｜Advancing the price-performance frontier with GPT-5.6
- The Decoder｜OpenAI goes full China pricing mode with an 80 percent cut to its most affordable GPT-5.6 model
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
【監修】齋藤竹紘（株式会社オルセル代表 / 19年・5,000社のEC支援実績）
株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
