LLMに時刻を渡す方法でキャッシュ効率が激変する理由 ─ プロンプトキャッシュ最適化の実践テクニック

LLM（大規模言語モデル）は学習時点でパラメータが固定される静的なシステムです。そのため、「今が2026年7月なのか、それとも2025年1月なのか」を自力で判断する手段を持ちません。

この問題を解決するため、多くのAIプロダクトは会話の冒頭でシステムプロンプトに現在日時を注入しています。一見シンプルな解決策ですが、**実装方法によってプロンプトキャッシュの効率が劇的に変わる**という重要な事実が見過ごされがちです。

問題のある実装パターン

多くの開発者が無意識に採用している実装がこれです：

import datetime

system_prompt = f"現在時刻: {datetime.datetime.now()}"

このコードは一見正しく動作しますが、**リクエストごとに秒単位で異なる文字列を生成**します。プロンプトキャッシュは入力テキストの完全一致を前提とするため、わずか1秒の差でもキャッシュミスが発生し、毎回フルプライスのAPI料金が請求されます。

Claude vs Gemini：キャッシュ挙動の違い

ClaudeとGeminiでは、プロンプトキャッシュの仕組みに微妙な違いがあります：

いずれのモデルでも、**時刻情報の粒度を下げる**ことがキャッシュ効率向上の鍵となります。

時刻粒度とキャッシュ効率のトレードオフ分析

時刻情報の実装には、精度とコストの間に明確なトレードオフが存在します。

**秒単位の時刻**を渡す場合、AIは最も正確な時間感覚を持ちますが、キャッシュヒット率はほぼ0%です。1日86,400秒すべてで異なるプロンプトが生成されるため、実質的にキャッシュは機能しません。

**分単位の時刻**では、1日1,440パターンに減少します。5分刻みなら288パターン、15分刻みなら96パターンです。多くのユースケースでは、15分程度の精度があれば実用上問題ありません。

**時間単位の時刻**まで粒度を下げると、1日24パターンのみとなり、キャッシュヒット率は劇的に向上します。「午前中」「午後」程度の時間感覚で十分なアプリケーションも多いでしょう。

「日付のみ」実装の落とし穴

一見合理的に思える「日付のみ」（年月日）の実装にも注意が必要です。この方法では1日1パターンとなり、キャッシュ効率は最高になります。

しかし、**タイムゾーンをまたぐグローバルサービスでは問題が発生**します。日本時間の午前0時とアメリカ東海岸時間の午前0時では、実際には13時間のずれがあります。すべてのユーザーに同じ「日付」を渡すと、一部のユーザーにとって時間認識が最大半日ずれる可能性があります。

時刻情報の配置戦略

Claudeの場合、システムプロンプトは前方からキャッシュされます。そのため、以下のような構造が最適です：

[静的な指示・ルール（数千トークン）]
---
[動的な時刻情報（数十トークン）]

これにより、時刻部分のみがキャッシュミスとなり、大部分の静的コンテンツはキャッシュから再利用されます。数千トークンのシステムプロンプトを持つ複雑なAIエージェントでは、この配置だけで**コストを50〜70%削減**できます。

エージェントシステムでの時間誤認事例

実際のAIエージェント運用では、時間認識の誤りが深刻な問題を引き起こします。

これらは単なるUX問題ではなく、**ビジネスクリティカルなエラー**となり得ます。時刻精度とキャッシュ効率のバランスは、アプリケーションの要件に応じて慎重に設計する必要があります。

1. 現在の実装を監査する

まず、あなたのシステムプロンプト生成コードを確認してください：

# 改善前
system_prompt = f"現在: {datetime.now()}"

# 改善後（15分刻み）
now = datetime.now()
rounded = now.replace(minute=now.minute // 15 * 15, second=0, microsecond=0)
system_prompt = f"現在: {rounded.strftime('%Y-%m-%d %H:%M')}"

15分刻みに丸めるだけで、キャッシュヒット率は理論上15倍になります。

2. 時刻情報をシステムプロンプトの末尾に移動

大規模な静的指示がある場合、時刻情報を後方に配置します：

static_instructions = """あなたは...（数千文字の指示）"""
timestamp = f"\n---\n現在時刻: {rounded_time}"
system_prompt = static_instructions + timestamp

これだけで、Claudeの場合は静的部分のキャッシュが有効になります。

3. ユースケース別に精度を設定する

**高精度が必要**（リアルタイム取引、緊急対応）: 1〜5分刻み

**標準的な業務アプリ**（スケジューリング、タスク管理）: 15分〜1時間刻み

**情報提供・コンテンツ生成**（記事執筆、要約）: 日付のみまたは時間単位

あなたのアプリケーションがどのカテゴリに属するか判断し、過剰な精度でコストを無駄にしていないか確認しましょう。プロンプトキャッシュの効率化は、APIコストの大幅削減だけでなく、レスポンス速度の向上にもつながります。

この情報は @MotimotiNotch さんの投稿を参考にしています。