1. 個別のリクエストではなくプリセットから始める
次の項目を固定する場合はプリセットを作成します。- 対象モデル
- プロバイダーの優先設定
- temperature などの生成パラメーター
- 推論の設定
- システムプロンプト
2. プリセットでレスポンスキャッシュを有効にする
次を設定します。response_caching.enabled = true- 適切な
ttl_seconds
- 変化の速い事実確認プロンプトには短い TTL
- 安定した構造化出力には長めの TTL
3. リクエストを決定的に保つ
不要なリクエストの変化を避けると、レスポンスキャッシュの効果が高まります。 次の変更は避けます。- システムプロンプトの文言
- temperature
- プロバイダーの上書き設定
- 推論設定
- ツール一覧
4. リクエスト詳細でキャッシュの動作を確認する
キャッシュ経由のリクエスト詳細には、キャッシュに関する情報が表示されます。 次を確認します。- キャッシュヒットまたはミス
- TTL の動作
- キャッシュ済みレスポンスが返された場合のプロバイダー情報
5. キャッシュとルーティングを意図的に組み合わせる
推奨パターン：- 決定的な構造化出力向けに、キャッシュを有効にしたプリセットを使います。
- 探索的なリクエストや temperature が高いリクエスト向けに、キャッシュを無効にした別のプリセットを使います。
6. TTL を延ばす前にキャッシュミスの原因を調べる
ヒットするはずなのにミスが続く場合は、次を比較します。- プロンプトのテキスト
- モデル ID
- プロバイダーオプション
- レスポンス形式
- ツールとツール選択
- プリセットの slug と設定
7. キャッシュを避ける場面
次のリクエストでは、レスポンスキャッシュを既定で有効にしないでください。- 常に変化する外部情報に依存するプロンプト
- コンテキストが急速に変わるユーザー固有の回答
- 出力が変動するツールを使うリクエスト
- 正確な再現が望ましくない、高い確率性を持つ生成