Claude Sonnet 5は指示を文字通り解釈し、範囲を広げない
Claude Sonnet 5は指示を一般化せず文字通り実行します。effortとの関係、範囲を明示する書き方とコードレビューでの影響をまとめます。
Sonnet 5は指示を一般化しない — 何が変わったか
Claude Sonnet 5は、プロンプトを文字通り、そして明示的に解釈します。とくにlowやmediumのような低いeffort設定で顕著です。1件の項目に書いた書式指示を他の項目へ黙って広げたり、頼まれていない作業を推測で追加したりしません。
利点は精度です。厳密に調整したプロンプトでのAPI利用、構造化抽出、予測可能な挙動が欲しいパイプラインでは、Sonnet 5のほうが成果を出しやすくなります。逆に、察してもらう前提で省略していた条件は、そのまま抜け落ちます。
この性質はSonnet 5に固有ではありません。Anthropicの横断ガイドは、モデルごとの差分を一覧表にしています。Sonnet 5の行には、「response length」「effort and thinking-depth calibration」「tool use triggering」が並びます。その中にliteral instruction following(文字通りの指示追従)があります。Opus 4.8の行にも同じ項目があり、Opus 4.8のガイドは同じ段落を「精度とやり直しの少なさ」という利点つきで載せています。
一方、同じ表のOpus 5の行にはこの項目がありません。Opus 5の差分は「task scope and over-verification」(作業範囲と過剰な検証)で、向きが逆です。「文字通り」は新しいモデルほど強まる一方向の変化ではなく、世代ごとに調整される性質だと読めます。
一部だけ直ったように見える症状
複数項目にまたがる作業では、この性質が「最初の1件だけ直っている」という形で出ます。英文の例を日本語に直すと、範囲を書いた指示は次の一文です。
この書式を、最初のセクションだけでなくすべてのセクションに適用してください。同じ書式指示で、範囲を書いたかどうか
範囲を書いていない
「この書式にして」とだけ頼むと、最初のセクションに適用して終わることがあります。以前のモデルが「他のセクションにも当てはめるはずだ」と補っていた部分が、補われません。
範囲を書いた
「全セクションに適用」と文にしておけば、同じプロンプトで最後まで進みます。直すのは基準ではなく、頭の中にあった範囲を文字にすることだけです。
コードレビューで報告件数だけが減るとき
実害が大きいのは、旧モデル向けに調整したレビュー用のハーネスです。プロンプトに「high-severityの問題のみ報告して」「conservativeに」「nitpickはしないで」と書いてあると、Sonnet 5はその基準を以前のモデルより忠実に守ることがあります。調査の深さは変えず、基準を下回ると判断した発見を報告に載せません。
公式ガイドは、これを「ハーネス側の効果であって、能力の退行ではない可能性が高い」と述べています。precisionは上がり、測定上のrecallだけが下がります。原因の切り分けはOpus 5/Sonnet 5のコードレビューでrecallが下がる原因に詳しく書いています。ここでは、ハーネスの形ごとに、2通りの直し方を並べます。
| ハーネスの形 | 公式の方針 | プロンプトの核(要約) |
|---|---|---|
| 検証・重複排除・順位付けの段が別にある | 公式の方針発見の段では絞らず、網羅を役目にする | プロンプトの核(要約)確信度が低いものも低severityのものも全部報告し、各件に確信度と推定severityを付ける |
| 1回の呼び出しで自己選別させたい | 公式の方針基準を「重要なもの」のような質的な語でなく具体的に書く | プロンプトの核(要約)誤動作・テスト失敗・誤解を招く結果につながるバグは報告し、純粋なスタイルや命名の好みだけ省く |
前者は、実際に2段目を用意していなくても使えるとされています。ただし、確信度で絞る作業を発見の段から外したほうが、多くの場合うまくいきます。どちらの場合も、評価用のサブセットで再現率かF1を測り直すことが前提です。
effortが低いほど範囲を厳密に守る
Sonnet 5の既定のeffortはhighで、Sonnet 4.6と同じです。公式ガイドが範囲の扱いを明記しているのはlowとmediumで、この2段階では「頼まれた範囲だけをやる」ことを優先し、期待を超える作業を自発的には足しません。lowの用途として挙がっているのは、短く範囲の決まった、レイテンシ重視の作業です。
代償もあります。中程度に複雑な作業をlowで流すと、考え込みが浅くなるおそれがあります。浅い推論が目立つなら、プロンプトで補うより先にhighかxhighへ上げるのが第一選択です。lowのまま遅延を守りたいときは、次のような一文を足す方法も挙げられています。
この作業は複数段階の推論を含みます。回答する前に、問題を注意深く考え抜いてください。Sonnet 4.6から移すときは、effortの名前を同じにしても思考の量が同じとは限りません。大まかな対応では、Sonnet 5のmediumはSonnet 4.6のhighに、Sonnet 5のhighはSonnet 4.6のmaxに近い知性です。比較するときは、effortの名前でなく、観測した思考の長さで合わせます。effortの基本はClaude effortとはにあります。切り替え方はClaude Code effortレベルの使い方と設定にまとめています。
Claude Codeでは、起動時にeffortを指定するフラグがあります。v2.1.289のclaude --helpには、次の行が出ます。
claude --help | grep -A1 -- "--effort" --effort <level> Effort level for the current session
(low, medium, high, xhigh, max)Claude Codeの設定ページでも、Sonnet 5が受け付けるレベルはlowからmaxの5段階です。lowで動かして範囲の取りこぼしが出たら、プロンプトを直す前に--effort highで同じ指示を流して、effortの影響かどうかを切り分けられます。
範囲を文にする書き方
対処は一つで、一般化してほしい範囲を指示の中に文として書きます。Anthropicの横断ガイドも、モデルを問わない原則として同じ考え方を挙げています。
Claudeは明確で直接的な指示に良く応答します。「期待を超えた」動きをしてほしいなら、モデルが曖昧なプロンプトから推測することに頼らず、明示的にそう頼んでください。
ガイドは、文脈を持たない優秀な新入社員にプロンプトを見せるつもりで書く、という比較を添えています。「アナリティクスダッシュボードを作って」だけより、「関連する機能とインタラクションを可能な限り含め、基本を超えてフル機能の実装にしてください」と書いたほうが結果が変わる、という例です。範囲、網羅性、上乗せの度合いのどれかを期待しているなら、言葉にする必要があります。
| 書き方 | 範囲を明示した書き方 |
|---|---|
| この書式にして | 範囲を明示した書き方この書式を全セクションに適用してください |
| バグを報告して | 範囲を明示した書き方確信度が低いものや低severityのものも含め、見つけた問題はすべて報告してください |
| この命名規則で | 範囲を明示した書き方新規ファイルだけでなく、既存の同種のファイルにも同じ命名規則を適用してください |
範囲だけでなく、指示の向きにも同じ傾向があります。Sonnet 5の公式ガイドには、禁止の指示より、望ましい形を具体的に示すほうが効く例が2つ載っています。
- 冗長さを減らしたいとき: 「〜するな」を並べるより、「簡潔で要点を絞った回答にし、補足の文脈は省き、例は最小限にしてください」と、望む姿を書く。簡潔さの見本を肯定形で示すほうが、否定形の指示より効きやすいとされています
- フロントエンドの見た目を変えたいとき: 「この色は使わない」「すっきりと」のような一般的な指示は、別の決まった配色に寄るだけです。配色、角丸、余白、文字組みを具体的に指定すると、そのとおりに作ります
Sonnet 5.5のガイドにも、同じ発想の一文があります。アイデアや計画を求められたときは、それを渡して止まり、着手の合図が出るまで作らない、という趣旨のシステムプロンプトです。「どこで止まるか」も範囲の一部なので、文にしておく対象になります。
エージェント運用での影響
この性質は、単発の応答だけでなくエージェント的なワークフローにも及びます。thinkingを無効にした状態では、ツールに手を伸ばしにくくなります。thinkingをオフにしたままツール呼び出しに頼る構成では、システムプロンプトに明示的な促しを足します。highかxhighのeffortでは、エージェント的な検索やコーディングでツール使用が大きく増えるとされています。
進捗報告にも同じ見方が当てはまります。「ツール呼び出し3回ごとに進捗を要約して」のような、途中経過を強制する足場は、Sonnet 5では外して試す案内があります。Sonnet 5が長い作業の途中で、質の高い報告を定期的に出すためです。報告の長さや中身が合わないときだけ、望む形を例つきで書きます。
もう一つの点は、会話の進め方です。1回のユーザーターンで完結する非同期のエージェントと、複数ターンで進める同期的なエージェントでは、トークン消費や挙動が違います。人との対話回数を減らしたいなら、タスク、意図、制約を最初のターンで書き切るよう案内しています。曖昧な要求を何ターンかに分けて少しずつ渡す進め方は、トークン効率が下がり、ときに性能も下がる傾向があるとされています。
移行にはもう一つ、トークナイザーの違いがあります。Sonnet 5は同じ文章で約30%多くトークンを使うため、Sonnet 4.6向けのmax_tokensでは出力が途中で切れることがあります。thinkingが既定で有効になったことも重なります。対処はClaude Sonnet 5でmax_tokensが途中で切れる問題の対処法にまとめています。
Sonnet 5.5に移すときに変わる点
Sonnet 5はいまも使えますが、モデルの概要ページはSonnet 5.5への移行を勧めています。Sonnet 5.5の公式ガイドは、既存のSonnet 5向けプロンプトは変更なしでも動くはずだとしつつ、次の点が変わると述べています。
| 観点 | Sonnet 5 | Sonnet 5.5 |
|---|---|---|
| 低いeffortでの範囲 | Sonnet 5頼まれた範囲だけをやる | Sonnet 5.5lowとmediumの長い作業で、完了前に確認を求めて止まることがある |
| 頼まれていない追加 | Sonnet 5推測で作業を足さない | Sonnet 5.5テスト、ドキュメント、小さな補助ファイルを足す傾向(effortが高いほど多い) |
| effortの水準 | Sonnet 5Sonnet 4.6との対応が示されている | Sonnet 5.5再較正されており、Sonnet 5の設定を持ち越さず測り直す |
Sonnet 5.5の公式ガイドには、追加を抑えるプロンプトも載っています。範囲を絞りたい場合に使うのは、次の趣旨の後半の段落だけです。
ユーザーに頼まれた作業が終わって確認も済んだら、止まって報告してください。頼まれていない機能、テスト、ファイル、ドキュメント、リファクタは足さず、有益だと思うなら最後に提案として書いてください。つまり、Sonnet 5は「書かれていない範囲に広げない」ため範囲を足す側の指示が要り、Sonnet 5.5は逆に「広げすぎる」ため範囲を絞る側の指示が要ります。どちらのモデルでも、プロンプトの範囲は文で決めます。
Sonnet 5向けプロンプトを移すときの順序
- 1
範囲の前提を洗い出す
「1つの項目の指示は似た項目にも広がる」「曖昧な基準語で足りる」という前提で書いた箇所を探します。レビュー、分類、抽出のプロンプトに残った「conservativeに」「重要なものだけ」が最初の候補です。
- 2
範囲を文にして測り直す
見つけた前提を、「全セクションに」「見つけたものはすべて」のような一文にします。評価用のサブセットで、報告件数と再現率を前後で比べます。
- 3
effortを同じ名前で持ち越さない
Sonnet 5.5へ移すなら、effortの水準が再較正されているため、自分の評価データで
mediumとhighを測り直します。
まとめ
書かれていない範囲は、Sonnet 5が補ってくれる前提から外します。移行前に見るのは、レビュー系プロンプトの曖昧な基準語と、ツール呼び出しへの暗黙の期待の2点です。Sonnet 5.5へ進むなら、範囲を足す指示から範囲を絞る指示へ向きが変わるので、プロンプトごと測り直す必要があります。
参照した一次ソース
この記事の記述は、次の一次ソースと照合しています。更新時に参照先が変わった場合は一覧も更新します。
- platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-cla…
- platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompt…
- platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-cla…
- platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-cla…
- platform.claude.com/docs/en/models/sonnet-5/overview
- code.claude.com/docs/en/model-config