ai-docs

Prompting Claude Sonnet 5

Properties1
tagsprompting, effort, thinking, tools, frontend, claude-sonnet-5

11 min read

一行要約

移行時に最も事故りやすいのは API パラメータの3つの破壊的変更 — adaptive thinking が既定でオン、temperature / top_p / top_k が 400 エラー、新しいトークナイザで同じテキストが約30%多いトークンになる。

要点

移行時の破壊的変更

  • adaptive thinking が既定でオン。 thinking フィールドなしのリクエストは adaptive thinking で走る（Sonnet 4.6 では thinking なしで走っていた）。切るには thinking: {type: "disabled"}
  • manual extended thinking（{type: "enabled", budget_tokens: N}）は 400 エラー。 Sonnet 4.6 で deprecated だったものが削除された
  • temperature / top_p / top_k を既定以外にすると 400 エラー。 これは Sonnet クラスでは新しい制約。トーンや多様性は system prompt の指示で誘導する
  • 新トークナイザ: 同じテキストで約30%多いトークンが出る。Sonnet 4.6 向けに調整した max_tokens は等価な出力を切り詰めうる

応答長

タスクの複雑さに応じて長さを較正する — 単純な照会は短く、開放的な分析は長く。

Positive examples showing how Claude can communicate with the appropriate level of concision tend to be more effective than negative examples or instructions that tell the model what not to do. 適切な簡潔さで伝える方法を示す肯定的な例のほうが、否定的な例や「してはいけないこと」を伝える指示より効果的な傾向がある。

effort の較正

既定は high（Sonnet 4.6 と同じ）。最難のコーディング / agentic タスクでは xhigh。

移行時のおおまかな対応:

  • Sonnet 5 の medium ≒ Sonnet 4.6 の high
  • Sonnet 5 の high ≒ Sonnet 4.6 の max
  • ベンチマークするときは effort の名前ではなく、観測される thinking の長さで揃える

Claude Sonnet 5 respects effort levels strictly, especially at the low end. At low and medium, the model scopes its work to what was asked rather than going above and beyond. On moderately complex tasks running at low effort there is some risk of under-thinking. Claude Sonnet 5 は effort レベルを厳密に尊重する。特に低い側でそうである。low と medium では、モデルは求められた以上のことをせず、依頼された範囲に作業を限定する。low の effort で中程度に複雑なタスクを走らせると、思考不足に陥る危険がいくらかある。

推論が浅いときは prompt で回避せず effort を上げる。

If you are running at high, xhigh, or max effort, leave headroom in max_tokens. If the budget is tight, you may see a response that is almost entirely thinking followed by a truncated answer and stop_reason: "max_tokens". high、xhigh、max の effort で走らせるなら、max_tokens に余裕を持たせよ。予算が切り詰められていると、応答のほとんどが thinking で占められ、答えが途中で切れて stop_reason: "max_tokens" になることがある。

ツール使用の発火

Sonnet 4.6 より agentic で、ツールに手を伸ばし自己検証ループを回す傾向が強い。

With thinking disabled, the model is less likely to reach for tools or consider searching; if you rely on tool calls with thinking off, add an explicit nudge in the system prompt. thinking を無効にすると、モデルはツールに手を伸ばしたり検索を検討したりしにくくなる。thinking を切ったままツール呼び出しに依存するなら、system prompt に明示的な促しを加えよ。

high / xhigh では agentic 検索とコーディングでツール使用が大幅に増える。

進捗報告

長い agentic トレースを通じて定期的で質の高い更新を出す。

If you’ve added scaffolding to force interim status messages (“After every 3 tool calls, summarize progress”), try removing it. 途中経過のメッセージを強制する scaffolding（「ツール呼び出し3回ごとに進捗を要約せよ」など）を足しているなら、外してみよ。

より字義通りの指示追従

Claude Sonnet 5 interprets prompts literally and explicitly, particularly at lower effort levels. It does not silently generalize an instruction from one item to another, and it does not infer requests you didn’t make. Claude Sonnet 5 はプロンプトを文字通り、明示的に解釈する。特に低い effort でそうである。ある項目への指示を、黙って別の項目へ一般化することはなく、していない依頼を推測することもない。

利点は精度 — API 用途、構造化抽出、予測可能な挙動が欲しいパイプラインで良く効く。広く適用してほしいならスコープを明示する（“Apply this formatting to every section, not just the first one”）。

デザインとフロントエンドの既定

開放的なフロント/デザインのブリーフで一貫した既定の視覚スタイルに落ち着くことがある。

Generic instructions (“don’t use that color,” “make it clean and minimal”) tend to shift the model to a different fixed palette rather than producing variety. 漠然とした指示（「その色は使うな」「清潔でミニマルに」）は、多様性を生むのではなく、モデルを別の固定パレットへ移すだけになりがちである。

効くのは2つ:

  1. 具体的な代替を指定する（色コード、タイポグラフィ、角丸の px、セクション構成まで書く）
  2. 作る前に選択肢を提案させる — temperature が使えないので、実行ごとに意味のある差を出すにはこれが推奨手段

コードレビュー harness（重要な落とし穴）

If your code-review harness was tuned for an earlier model, you may initially see lower recall. This is likely a harness effect, not a capability regression. コードレビューの harness を以前のモデル向けに調整していた場合、当初は再現率の低下が見えるかもしれない。これはおそらく harness による効果であって、能力の後退ではない。

「重大な問題だけ報告せよ」「保守的に」「細かいことは指摘するな」と書いていると、Sonnet 5 はそれを従来より忠実に守る — 同じ深さで調査した上で、基準以下と判断した発見を報告しない。結果として precision は上がるが recall が下がって見える。

対処: 発見段階ではカバレッジを目的だと明示し、フィルタリングを別段階に移す。

対話的コーディング製品

To maximize both performance and token efficiency in coding products, use xhigh or high effort, add autonomous features like an auto mode, and reduce the number of human interactions required. コーディング製品で性能とトークン効率の両方を最大化するには、xhigh か high の effort を使い、auto モードのような自律的な機能を加えて、必要となる人間の介入回数を減らせ。

曖昧で不十分な指示を複数ターンにわたって段階的に伝えると、トークン効率が下がり、性能も落ちることがある。

computer use

computer_20251124 に対応。最大解像度 2576px / 3.75MP。1080p が性能とコストのバランスが良い（社内テスト）。コスト重視なら 720p や 1366×768。

そのまま使える具体例

冗長さを減らす:

Provide concise, focused responses. Skip non-essential context, and keep examples minimal.

低い effort で推論の浅さが問題になったとき:

This task involves multistep reasoning. Think carefully through the problem before responding.

thinking の発火を抑える:

Thinking adds latency and should only be used when it will meaningfully improve answer quality, typically for problems that require multistep reasoning. When in doubt, respond directly.

トーンを指定する（temperature が使えないため）:

Use a warm, collaborative tone. Acknowledge the user's framing before answering.

コードレビューの recall を戻す:

Report every issue you find, including ones you are uncertain about or consider low-severity. Do not filter for importance or confidence at this stage - a separate verification step will do that. Your goal here is coverage: it is better to surface a finding that later gets filtered out than to silently drop a real bug. For each finding, include your confidence level and an estimated severity so a downstream filter can rank them.

1パスで自己フィルタさせたいなら基準を具体的に書く:

report any bugs that could cause incorrect behavior, a test failure, or a misleading result; only omit nits like pure style or naming preferences.

デザインの既定を破る方法2 — 選択肢を提案させる（推奨）:

Before building, propose 4 distinct visual directions tailored to this brief (each as: bg hex / accent hex / typeface, plus a one-line rationale). Ask the user to pick one, then implement only that direction.

“AI slop” 美学を避ける:

<frontend_aesthetics>
NEVER use generic AI-generated aesthetics like overused font families (Inter, Roboto, Arial, system fonts), cliched color schemes (particularly purple gradients on white or dark backgrounds), predictable layouts and component patterns, and cookie-cutter design that lacks context-specific character. Use unique fonts, cohesive colors and themes, and animations for effects and micro-interactions.
</frontend_aesthetics>

原典で言及されている関連文書

未取得の派生リンク

グラフビュー

バックリンク