Claude Sonnet 5は指示を文字通り解釈し、範囲を広げない

Sonnet 5は指示を一般化しない — 何が変わったか

Claude Sonnet 5は、プロンプトを文字通り、そして明示的に解釈します。とくにlowやmediumのような低いeffort設定で顕著です。1件の項目に書いた書式指示を他の項目へ黙って広げたり、頼まれていない作業を推測で追加したりしません。この性質は、暗黙の一般化をしないこと、言われていないリクエストを推測しないこと、という言葉で言い表されています。

この文字通りさの利点は精度です。厳密に調整したプロンプトでのAPI利用、構造化抽出、予測可能な挙動が欲しいパイプラインでは、Sonnet 5のほうが成果を出しやすくなります。逆に「ある程度は察してほしい」前提で書いていたプロンプトは、Sonnet 4.6までと同じ結果にならないことがあります。

Anthropicの横断ガイドは、モデルごとの差分を一覧表にまとめています。Sonnet 5の行には、Sonnet 4.6との違いが複数並んでいます。「response length」「effort and thinking-depth calibration」「tool use triggering」に加え、literal instruction following(文字通りの指示追従)が明記されています。同じ表のOpus 4.8の行にも同じ項目があり、この傾向はSonnet 5だけの個別のクセではないとわかります。

「一部だけ直った」ように見える具体例

一般化しない性質は、複数項目にまたがる作業でわかりやすく表れます。よく挙げられる典型例は書式の指定です。

Apply this formatting to every section, not just the first one.

このような範囲の明示がないまま「この書式にして」とだけ頼むと、Sonnet 5は最初のセクションだけに適用して止まることがあります。以前のモデルなら「他のセクションにも当然当てはめるはずだ」と一般化して先まで進めていた作業が、Sonnet 5では止まります。

より実害の大きい例は、コードレビューのハーネスです。旧モデル向けに「high-severityの問題のみ報告して」「conservativeに」「nitpickはしないで」と書かれたレビュープロンプトを、そのままSonnet 5に使うケースです。Sonnet 5は調査そのものは同じ深さで行いながら、指示された基準を下回ると判断した発見を報告しません。結果として、バグを見つける能力は落ちていないのに、報告件数(recall)だけが下がって見えます。この現象の仕組みと直し方はOpus 5/Sonnet 5のコードレビューでrecallが下がる原因に詳しくまとめています。

effortが低いほど範囲を厳密に守る

一般化しない傾向は、effortパラメーターの設定次第で強さが変わります。effortはSonnet 5の知性とトークン消費のバランスを調整する仕組みで、既定値はhighです。Sonnet 5は、とくに低い側のeffortで、この厳密さが強く出ます。

一次ソースが範囲の厳密さを明記しているのはlowとmediumだけです。この2段階では、モデルは「頼まれた範囲だけをやる」ことを優先し、期待を超えた提案や確認を自発的にはしません。レイテンシとコストには有利ですが、中程度に複雑なタスクをloweffortで流すと考え込み不足のリスクがあります。複雑な問題で浅い推論が目立つなら、プロンプトを工夫するより先にeffortをhighやxhighへ上げるほうが効果的です。high以上での範囲の扱いは明記されていません。effortの基本的な使い分けはClaude effortとは、Claude Code上での切り替え方はClaude Code effortレベルの使い方と設定にまとめています。

意図した動きにするには範囲を明示する

対処の方向は一つです。一般化してほしい範囲を、指示の中に文として書く。例文は先述の「Apply this formatting to every section, not just the first one.」で、これをそのまま日本語のプロンプトに置き換えるなら「この書式を全セクションに、最初のセクションだけでなく適用してください」のような一文になります。

Anthropicの横断的なプロンプトガイドも、モデルを問わない原則として同じ考え方を挙げています。

Claudeは明確で直接的な指示に良く応答します。「期待を超えた」動きをしてほしいなら、モデルが曖昧なプロンプトから推測することに頼らず、明示的にそう頼んでください。

このガイドは「経験の浅い、しかし優秀な新入社員」にプロンプトを見せるつもりで書く、という比較を挙げています。「アナリティクスダッシュボードを作って」だけでは効果が薄く、「関連する機能とインタラクションを可能な限り含め、基本を超えてフル機能の実装にしてください」まで書き込むと結果が変わる、という具体例です。Sonnet 5固有の「一般化しない」挙動も、この原則の延長線上にあります。範囲・網羅性・上乗せの度合いのどれかを期待しているなら、それを言葉にする必要があります。

範囲を明示する書き方は、次のような言い換えパターンに落とし込めます。

• 「この書式にして」→「この書式を全セクションに適用してください」
• 「バグを報告して」→「確信度が低いものや低severityのものも含め、見つけた問題はすべて報告してください」
• 「この命名規則で」→「新規に追加するファイルだけでなく、既存の同種のファイルにも同じ命名規則を適用してください」

範囲を明示した一文を含めると、実際にAPIへ投げたリクエストは次のようになります。

# 範囲を明示した指示の例(全セクションに適用する一文を含む)
curl -s https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-sonnet-5",
    "max_tokens": 4000,
    "messages": [{
      "role": "user",
      "content": "3つのセクションがある文書の見出しを太字にして。全セクションに、最初のセクションだけでなく適用してください。"
    }]
  }' | jq -r '.content[].text'

Claude Codeやエージェント運用での影響

一般化しない性質は、単発の応答だけでなくエージェント的なワークフローにも及びます。ツール呼び出しのトリガーにも同じ傾向が及び、thinkingを無効にした状態ではツールに手を伸ばしにくくなります。thinkingをオフにしたままツール呼び出しに依存する構成では、システムプロンプト側に明示的な指示を足す必要があります。

コーディング用途では、1回のユーザーターンで完結する自律的な非同期エージェントと、複数ターンにわたって対話しながら進める同期的なエージェントとで、トークン消費や挙動が異なります。前者のような自律度の高いコーディング用途では、effortをxhighやhighに設定し、auto modeのような自律機能を足したうえで、人間との対話回数そのものを減らすことが性能とトークン効率の両方を最大化すると位置付けられています。

自律的に複数ターンを進めるコーディング用途では、この点の影響がさらに直接的です。人間との対話ターン数を減らしたいなら、タスク・意図・制約条件を最初の1ターンで明示するのが重要になります。曖昧な指示を複数ターンにわたって少しずつ渡す進め方は、トークン効率や成果を相対的に落とす傾向があるとされています。Sonnet 5が指示から先を推測して埋めない以上、CLAUDE.mdやサブエージェントへの指示も、最初の1回でスコープを書き切る設計のほうが噛み合います。

Sonnet 5への移行では、この一般化しない性質と同時に、max_tokensが途中で切れる不具合に遭遇するチームもあります。原因は別ですが、Sonnet 4.6時代のプロンプト設計をそのまま持ち越すと起きやすい点は共通しています。詳細はClaude Sonnet 5でmax_tokensが途中で切れる問題の対処法にまとめています。

移行時に見落としやすい落とし穴

Sonnet 4.6からSonnet 5へ移行するときは、次の前提が効かなくなっている可能性を確認しておくと手戻りが減ります。

• 「1つの項目に書いた指示は、他の似た項目にも当然広がる」という前提でプロンプトを書いていないか
• レビュー・分類・抽出系のプロンプトに「conservativeに」「重要なものだけ」のような曖昧な基準語が残っていないか
• thinkingを無効にした構成で、ツール呼び出しをモデルの自発的な判断に依存していないか
• 複数ターンにわたって少しずつ要件を追加する進め方を、そのままSonnet 5にも当てはめていないか

いずれも、Sonnet 5が範囲を自分で広げてくれないことに起因します。プロンプトの書き換えは、基準や意図そのものを変えるのではなく、すでに持っている前提を文章として明示するだけで足りるケースがほとんどです。

まとめ

Claude Sonnet 5は、指示を文字通り受け取り、書かれていない範囲までは一般化しません。低いeffortほどこの傾向が強く出て、レビュー系プロンプトの曖昧な基準語やツール呼び出しの暗黙の期待が、狙った結果からずれる原因になります。対処はプロンプト自体を大きく変えることではなく、「全セクションに」「見つけたものはすべて」のように、期待している範囲を一文で書き加えることです。Sonnet 4.6向けに調整したプロンプトをそのまま使っているチームは、範囲を明示する一文が抜けていないかを確認してから移行すると、報告件数の急な変化に驚かずに済みます。