長いAI指示を速くする4つの確認

結論は、キャッシュを有効にする設定を探すより、長い共通指示を先頭へ固定し、`cached_tokens`を実測することです。Prompt Cachingは長いプロンプトの共通接頭辞を再利用しますが、文章の順序や版が毎回変われば効果を確認できません。

今回はAPIへ実データを送らず、8件の架空リクエストで「長さ」「固定接頭辞」「版」「計測」の事前ゲートを試しました。期待結果との不一致は0件でした。これは速度や料金の実測ではなく、本番計測へ進める入力かを先に分けるローカル試験です。

先に結論

運用開始前に次の4点を固定します。

1. キャッシュ対象になり得る長さを満たしているか

2. 再利用する指示、例、ツール定義を先頭に置いているか

3. プロンプト版を識別し、変更時に別版として扱えるか

4. 応答のusageにある`cached_tokens`を記録できるか

キャッシュ命中を期待値で扱わず、同じ版の反復リクエストで入力トークン、キャッシュ済みトークン、待ち時間を並べて判断します。

一次情報で確認したこと

OpenAIのPrompt Caching公式ガイドでは、キャッシュはプロンプトの先頭から一致する部分を再利用し、対象モデルでは自動的に働くと説明しています。静的な指示や例を先頭へ置き、利用者ごとに変わる内容を後ろへ置く構造が基本です。

同ガイドでは、GPT-5.6以降の最小キャッシュ対象長は1,024トークン、旧モデルは原則2,048トークンと案内しています。モデルによって条件が異なるため、固定値を全モデルへ流用せず、利用モデルの表を確認します。

命中状況はレスポンスの`usage.prompt_tokens_details.cached_tokens`で確認できます。料金や速度が下がるはずだと推測するのではなく、リクエスト単位の値を保存して比較します。また、保持時間はモデルと保持設定に依存し、再利用を永続キャッシュとして設計しません。

Latency optimization guideは、出力トークン削減やリクエスト数の削減も重要だと説明しています。Prompt Cachingだけで全体の待ち時間が解決するとは限りません。

Production best practicesに沿い、利用量、遅延、失敗を継続監視し、効果が見えない場合に入力構造を戻せる状態を保ちます。

実際に試したこと

8件の架空リクエストへ次の事前ゲートを適用しました。

| ケース | 入力条件 | 判定 |

|—|—|—|

| 1 | 全体900、固定部分800トークン | 長さ不足で停止 |

| 2 | 全体1,400、固定部分1,100 | 計測へ進む |

| 3 | 全体1,800、固定部分1,300 | 計測へ進む |

| 4 | 全体1,800、固定部分700 | 固定部分不足で停止 |

| 5 | 版をv1からv2へ変更 | 新版として初回計測 |

| 6 | v2を同じ順序で再利用 | 反復計測へ進む |

| 7 | 可変質問だけを末尾で変更 | 反復計測へ進む |

| 8 | 版をv3へ変更 | 新版として初回計測 |

結果は、計測へ進む4件、新版として分ける2件、停止2件で、不一致は0件でした。重要なのは、全体が長くても固定接頭辞が短いケースを弾いたことです。会話履歴や日時を先頭へ追加すると、後ろに同じ指示があっても共通接頭辞を崩します。

4つの確認を運用へ落とす

1. 長さ

推測ではなく、実際のトークン数を記録します。対象モデルの最小長に届かない短い処理は、キャッシュ前提の最適化対象から外します。

2. 順序

システム指示、長い例、共通ツール定義を先頭へ固定します。ユーザー入力、検索結果、日時など変化する値は後ろへ置きます。JSONのキー順や空白も無秩序に変えません。

3. 版管理

共通指示へ`support-v2`のような版を付けます。本文を変更したのに同じ版として集計すると、命中率低下と内容変更を切り分けられません。

4. 計測

`prompt_tokens`、`cached_tokens`、モデル、プロンプト版、待ち時間、エラーを同じ行へ保存します。最低でも同一版を複数回流し、初回と反復を分けて比較します。

今日から行う3つのアクション

1. 最も長い定型指示を1本選び、固定部分と可変部分へ分ける

2. 固定部分を先頭へ移し、版名を付けたテストを最低3回行う

3. `cached_tokens`と待ち時間を記録し、効果がない処理は元の単純な構造へ戻す

保存条件を確認する手順はAPI保存ゼロを誤解しない5確認、AI資産の版と担当を揃える方法はAI資産台帳で固定する5項目で整理しています。

判断基準

事前ゲートで長さ不足と接頭辞不足を止め、同一版の反復で`cached_tokens`が増えることを確認できた処理だけを最適化対象にします。速度や費用の改善率はモデル、入力、保持状態で変わるため、公式の一般説明を自分の処理の実測値として扱いません。

出典

著者情報

執筆・検証: しろのあ。OpenAI公式文書と2026年9月3日の架空8ケースによるローカル事前判定を確認しました。実APIのキャッシュ命中率、速度、料金は未計測として分けて記載しています。