GPT-6 Astraのプロンプトキャッシュ：ヒットしない理由を調べる

キャッシュミスの原因を切り分ける

後の呼び出しが一度速くなっただけで「修正済み」と判断しないでください。通信状況、キュー、出力の長さ、ツールの実行も所要時間に影響します。

プロンプトを変える前に使用量を読む

リクエストのテンプレート、モデル、ツール群、会話履歴のバージョンを特定できる安全な診断記録を残します。アクセス制限のないログに秘密情報や非公開のユーザー内容を入れないでください。ハッシュや管理された比較なら、全値を公開せずに変更を見つけられます。

usage.input_tokens_details.cached_tokensを、cache_write_tokensと総input_tokensと一緒に確認します。キャッシュトークンは再利用した入力であり、キャッシュ書き込みトークンは別の課金要素です。初回のキャッシュトークンが0でも、それだけで不具合ではありません。再利用条件を満たす後続リクエストと比較してから診断します。応答が速いだけで再利用を推測しないでください。

次に、既知のリクエストと、そのキャッシュを利用するはずだった次のリクエストを比較し、予想外の最初の違いを探します。最初からすべての指示を動かすと、元の失敗を説明できないまま別の実験になります。

確認候補には、冒頭付近の変動する時刻、順序が変わったツール一覧、書き直された要約、変更された指示ブロックがあります。調査すべき候補であり、それぞれがあなたのアカウントのミスを起こしたという主張ではありません。

同じ質問でも接頭部分が一致するとは限らない

公式プロンプトキャッシュガイドは、一致するプロンプトの接頭部分について中間的なキーと値の状態を再利用すると説明しています。回答のキャッシュではないため、後続リクエストでも新しい入力の処理と応答生成が必要です。

そのため、異なる質問でも共通の冒頭を活用できる一方、ほぼ同じ質問でも期待した部分を再利用できない場合があります。変化する内容の前に何があるかが重要です。

診断では、リクエストをアプリケーションが組み立てる版管理された文書として考えます。指示、ツール、履歴もその一部です。最後のユーザーメッセージだけでは重要な根拠が見えません。

接頭部分の条件を統制して試す

基準となるリクエストと、狭く定義した変更から始めます。タスク、出力要件、使用できるツールを固定し、使用量を解釈する前に意図した接頭部分が同じか記録します。

次に疑わしい変更要因を一つ試します。固定領域に不要な動的フィールドがあるなら、移動してもタスクの意味が保たれることを確認してから動かします。キャッシュ指標のために必要な文脈を削らないでください。

再現する傾向と単発の観察を区別できる件数で繰り返します。実験するまでは、その変更を修正案と呼びましょう。

この方法なら元に戻すことも容易です。品質が低下した場合、同時に行った複数の最適化を解きほぐさず、原因となるリクエスト構造の変更を特定できます。

三つのリクエストの記録表を使います。Aを基準とし、Bは同じ固定資料に新しい項目を加え、Cは疑わしいフィールドだけを変えます。各版、時間間隔、キャッシュトークン数、出力の合否を残します。これは実験設計であってAPI出力例ではなく、架空のヒット率は示していません。

固定した文体ガイドとスキーマに照らしてアイテム説明案を評価するチームを考えます。ガイドとスキーマは変わらず、個々のアイテムデータだけが変わります。再利用可能な文脈を調べるのに適した状況です。

ここで毎回ガイドの前に新しい実行IDを挿入するとします。モデルを原因と決める前に、最終リクエストの組み立て方を調べます。並べ替えた後もアイテムデータと指示が明確に分かれることを確かめる必要があります。

アイテム説明の依頼書を作るなら、RPGで所持品のラベルが用途や制約をどう伝えるか、自分で観察して記録しましょう。文体ガイドの材料になりますが、ゲームの文言をコピーしたり、リンク先をAstraのキャッシュ事例として紹介したりしないでください。

推論設定の変更は別に確認する

推論ドキュメントは、元のプロンプトの接頭部分を保ちながら応答間で推論の強度を変えるGPT-6 Astraの設定更新を説明しています。標準のシングルエージェントモードが対応条件に含まれます。

リクエストのどこかで設定を書き換えれば同じ効果が出るとは考えないでください。利用する連携で文書化された方法に従い、結果の挙動を確かめます。

難しい分析と定型的な後続作業を交互に行う会話で、特に重要です。目的は設定を永久に固定することではなく、関係のない文脈を意図せず作り直さずに、必要な設定を変更することです。

キャッシュの節約とタスク全体の費用を分ける

GPT-6 Astraのモデルページでは、入力、キャッシュ入力、出力の料金が分けられています。実装時に最新料金を確認してください。本稿では一定割合の削減を約束していません。

割引される一要素だけでなく、採用できる結果に至るタスク全体を見ます。最適化で出力が長くなり、再試行が増え、形式が壊れるなら、入力の一部を再利用できても全体は悪化する可能性があります。

キャッシュの挙動と品質を併せて報告します。最低限、合否、所要時間、報告された使用量を一緒に保存します。ヒット率の上昇だけを示す画面は、ユーザー体験の悪化を隠しかねません。

文体ガイドの評価には、ラベルが操作の理解に役立つかというプレイヤー視点の確認も必要です。Elseland AIのブラウザゲームを参考にし、自分でテスト例を書いてみましょう。ここはゲームを遊ぶ場所であり、キャッシュ性能や使用モデルの証拠ではありません。

再利用の最適化より先に正しさを守る

キャッシュしやすいリクエストが良いリクエストとは限りません。アプリ変更に伴うツール定義の更新は正確に保ち、ユーザーが訂正した要件も残してください。古い文脈の再利用は有用な最適化ではありません。

構造を変える前に合格基準を決めます。必須フィールドが残り、出力が現在のタスクに合い、古い指示が最新要件に優先しないことを確認します。

観察した効率改善が合格チェックも通過した場合だけ変更を採用します。指標が改善しても古い指示に従う出力になったら元に戻します。目的は何を犠牲にしてもヒット率を上げることではなく、入力の重複処理を減らしながら正しい結果を得ることです。