Claude Haiku 5.5の検索に今日の日付を渡す方法と追加の一文

検索ツールを渡しても古い知識で答えるとき

Web検索ツールをClaude Haiku 5.5に渡したのに、「最新のバージョンは?」と聞くと検索せずに答えてしまう。答えは自信ありげで、中身は学習時点のものです。この症状に対して、Prompting Claude Haiku 5.5のガイドが用意している対処は2段になっています。

1. 検索ツールを渡すなら、今日の日付も一緒に渡す
2. それでも検索が足りないときだけ、日付の直後に「学習データは古い」旨の段落を足す

日付は、Anthropicのテストで回答が最近の検索結果に根拠を置くようになった、と説明されています。置き場所はシステムプロンプトでも、検索ツールの説明文(description)でも構いません。

The current date is {{current_date}}.

この1行が出発点です。ここから先は、日付をいつ・どこで描画するかと、追加の一文をいつ入れるかの2点が実装上の分かれ目になります。

日付の置き方: 会話の開始時に1回だけ描画する

日付は会話の開始時に1回だけ展開し、その会話の以降のリクエストでは同じ system と tools を送ります。リクエストのたびに日付を作り直してシステムプロンプトに差し込む実装は、避ける側です。

理由はHaiku 5.5のthinkingブロックにあります。thinkingブロックは、それより前に送った内容が変わらない間だけ有効です。system、tools、過去の messages のどれかが変わった状態でthinkingブロックを送り返すと、400エラーになります。毎リクエストで日付を書き換えるシステムプロンプトは、まさにこの「変わる system」にあたります。移行ガイドも、会話は追記だけにするよう求めています。

エラーが出る条件には、アカウントの作成時期による差があります。

• 2026年8月31日00:00 UTC以降に作られたアカウントでは、既定でこの検査が効く
• それより前のアカウントでは、リクエストに thinking.block_binding.prefix_mismatch_behavior を指定したときだけエラーになる

つまり古いアカウントで試して何も起きなくても、安全とは言えません。他の人が自分のAPIキーでツールを動かす場合、新しいアカウントの人が先に400を受けます。

最小の実装は、会話オブジェクトを作る瞬間にだけ日付を描画する形です。次は例示で、公式のコードではありません。

from datetime import date
 
def new_conversation() -> dict:
    # 日付は作成時に1回だけ描画し、以後は同じ文字列を送り続ける
    system = f"The current date is {date.today().isoformat()}."
    return {"system": system, "messages": []}

保存した会話を翌日に再開するときも、system を作り直さず、保存してあった文字列をそのまま送ります。

日をまたいだ会話: 最新のターンに新しい日付を書く

会話が翌日以降に続く場合、システムプロンプトの日付は前日のままです。ここで system を書き換えると、先ほどの400エラーの条件に当たります。ガイドの答えは、新しい日付を最新のターンに書くことです。

最新のユーザーターンに、日付を知らせるテキストブロックを足す形になります。preserved thinkingのドキュメントが示す「変わった値は最新のターンに書く」パターンの応用です。

{
  "role": "user",
  "content": [
    { "type": "text", "text": "Today's date is now 2026-10-12." },
    { "type": "text", "text": "Claude Haiku 5.5の最新の料金を調べて" }
  ]
}

これも例示です。ユーザーターンに足す代わりに、会話の途中に role: "system" のメッセージを追記する方法もあります。運営側からの変更はこちらが向き、Haiku 5.5でも使えます。ただし、ツール実行の途中では置き場所に決まりがあり、tool_use とその tool_result の間には入れられません。日付程度の更新なら、次のユーザーターンにテキストを足す方が単純です。

一度送ったターンの日付は、後から書き換えません。昨日のターンに入れた日付を今日の日付に直すのも、前のメッセージを編集するのと同じ扱いで、以降のthinkingブロックを無効にします。

追加の一文を入れるのは、検索が足りないときだけ

日付だけでは検索が起きにくい構成があります。ガイドは、検索を促す一文が特に必要になるのは、low のeffortと、長いシステムプロンプトの組み合わせだと書いています。このときは日付の直後に次の段落を足します。

Your training data ends well before today's date. Records, office holders, prices, versions, rules and anything "latest" may have changed since then, so search for those before you answer, even when you feel sure. Facts that can't change need no search. When the answer depends on where the user is, put the user's country or region in the search query.

英文の意味は、次の4点です。

• 学習データは今日よりかなり前で終わっている
• 記録、役職者、価格、バージョン、規則、「最新」にあたるものは変わっているかもしれない
• だから確信があっても、回答の前に検索する
• 変わりようのない事実は検索しなくてよい。回答が利用者の所在地で変わるなら、クエリに国や地域を入れる

この段落は英語のまま使う前提で書かれています。日本語に訳して入れるなら、「変わりようのない事実は検索不要」の1文が落ちていないかを特に見てください。この除外がないと、後述の一括指示と同じ問題が起きます。

Anthropicの検証値

ガイドに載っている検証結果は次の3つです。

追加の一文は、答えが変わっていた質問での検索率を上げました。一方で、検索の要らないプロンプトに足しても、余計な検索は0〜3%の試行にとどまっています。「変わりようのない事実は不要」と明記していることが、この低さに効いていると読めます。

短いシステムプロンプトで medium なら、日付だけで検索が増えるため、一文は省けます。入れる前に日付だけを試し、足りない質問が残ったときに足す順が、長さの面でも無駄がありません。

避ける指示: 確信の度合いを問わず必ず検索する

逆効果になる書き方も、ガイドが明示しています。

Search for any present-day factual question, regardless of how confident you are.

のような一括の命令です。Anthropicのテストでは、この指示で検索が不要なプロンプトの半数に検索が走りました。しかも、正答は増えませんでした。検索コストとレイテンシが増えるだけ、という結果です。

追加の一文との違いは、検索の対象を絞っているかどうかです。追加の一文は「変わりうる種類の事実」(価格、バージョン、役職者など)に限り、不変の事実を除外しています。一括の命令は、この区別を持ちません。検索を増やしたいときは、対象の種類を書くのが筋です。

日付をツールの説明文に置く場合

自前の検索ツールを定義しているなら、日付をツールの description に入れる手もあります。システムプロンプトを触れない構成(他チームが管理している、固定の文面を使い回しているなど)で効きます。

{
  "name": "search_web",
  "description": "Search the web. The current date is 2026-10-10.",
  "input_schema": {
    "type": "object",
    "properties": { "query": { "type": "string" } },
    "required": ["query"]
  }
}

これは例示で、ツール名やスキーマは任意です。注意するのは、tools もシステムプロンプトと同じく、会話の途中で書き換えられない点です。日付を含む description を翌日に作り直して送ると、tools が変わったことになります。置き場所がどちらでも、描画は会話の開始時の1回だけです。

利用者の所在地で答えが変わる質問

追加の一文の最後の1文は、見落とされやすい部分です。「回答が利用者の所在地に左右されるときは、検索クエリに利用者の国か地域を入れる」。

料金、提供状況、適用される規則は、国によって答えが違います。地域を入れずに検索すると、利用者の国と違う国の情報が混ざる余地が残ります。日本向けのサービスで使うなら、国や地域をシステムプロンプトに書いておくと、この一文が効きやすくなります。この使い方は筆者の補足で、ガイドは国か地域をクエリに入れるよう書いているだけです。

症状別の切り分け

検索が出ないとき、何を足すかは構成で変わります。次の表は上の内容を状況別に並べ直したものです。

effortの面では、low は最も安く速いレベルで、チャットや短いツール作業、単純で大量のリクエスト向けです。同時に、長いエージェント用プロンプトでは、検索を飛ばしやすくなるレベルでもあります。Haiku 5.5の既定は medium なので、effort を指定していなければ、この症状が出やすい側にはいません。

low を保ったまま検索が要る質問だけ深く考えさせたいなら、会話の途中でeffortを変える方法もあります。手順は会話の途中でeffortを切り替える方法にあります。Claude APIとGoogle Cloudでは、Haiku 5.5も対象です。

変更を入れるときの順序

システムプロンプトに日付や追加の一文を足すときは、新しい会話にだけ入れます。Haiku 5.5のガイドは、ページ上のプロンプト追加の提案はすべて新しい会話向けだと断っています。保存済みの会話に新しいシステムプロンプトで再開すると、thinkingブロックを送り返した時点で400になりえるからです。

既存の会話を動かしたまま挙動だけ直したいなら、システムプロンプトを触らず、最新のターンに指示を書きます。段落を足す対象が新しい会話か、動いている会話かを、先に分けておくと混乱しません。

確認は、感覚ではなくログで行います。検索が要る質問(新しいモデル名、直近のリリース、料金)と、要らない質問(文章の言い換え、手元のコードの説明)を並べ、検索ツールが呼ばれた割合を、変更の前後で比べます。要らない質問側の検索率が上がっていないかを見るのは、追加の一文が余計な検索を生んでいないかの確認になります。このログの取り方は筆者の例で、ガイドが指定する方法ではありません。

同じ症状は他のモデルにもある

Fable 5.1の low でも、検索や取得のツールが呼ばれず記憶で答える症状があります。そちらの直し方はFable 5.1のlow effortで検索が減るときの直し方にまとまっています。Fable 5.1では「名前そのものを検索して確かめる」指示を足す形で、Haiku 5.5は日付と「学習データは古い」段落、という違いがあります。

Haiku 5.5のほかの症状(早期停止、検証漏れ、JSON出力でのツール呼び出し漏れなど)はHaiku 5.5のプロンプトガイドに症状別で並んでいます。モデルを切り替える前後に確認する項目はHaiku 5.5への移行チェックリストです。claude.aiやClaude Code側の検索の挙動は、Claude Web検索の使い方で扱っています。