「深く考えて」と指示する前にエフォートを変える。Claude Sonnet 5のプロンプト設計

Claude Sonnet 5の回答が浅い。

そんなときも、すぐにプロンプトに「もっと深く考えてください」と書き足す必要はありません。

Sonnet 5には、回答にかける思考量とトークン消費のバランスを調整するeffortがあります。問題の難しさに応じてモデル自身が思考量を決めるadaptive thinkingは標準で有効になり、手動でthinkingの予算を決める方法は使えなくなりました。つまり、モデル名だけを変え、出力が変わるたびに指示を継ぎ足していると、調整する順番を間違えます。

先に決めるべきなのは、今回の仕事にどれだけの知能、待ち時間、ツール、自律性を割り当てるかです。effortはモデルの振る舞いを調整する目安で、厳密なトークン予算ではありません。

分類や抽出は軽く、通常の実装は標準設定で、複雑なデバッグは深く考えさせる。検索が必要な仕事にはツールを渡し、定型処理では余計な探索をさせない。

Sonnet 5のベストプラクティスは、万能なプロンプトを一本作ることではありません。仕事を分け、それぞれに合う設定を用意します。

※本記事は2026年7月19日時点のAnthropic公式情報をもとにしています。主にClaude API、Claude Code、AIエージェントなど、effortやthinkingを設定できる環境を対象にしています。

Fable 5が「大仕事」なら、Sonnet 5は「日常業務の配分」を考える

Sonnet 5とFable 5は、速さだけを基準に選ぶモデルではありません。

Fable 5のベストプラクティスでは、人間なら数時間から数日かかる仕事について、調査から報告まで通して任せる設計を扱いました。長期自律、サブエージェント、メモリ、進捗を証拠で示す仕組みが中心です。

この記事では、もっと日常的な仕事に絞ります。

AnthropicはSonnet 5を、速度と知能のバランスに優れ、特にコーディングとエージェントタスクに強いモデルと位置づけています。実務での使い分けを、あえて単純化すると次のようになります。

これは、運用を考えやすくするために置いた本記事独自の分類です。Anthropicの正式な分類ではありません。

どちらが優れているかを比べたいわけではありません。一件あたりの失敗コスト、必要な判断量、処理件数、待てる時間から選びます。Sonnet 5を選んだあとも、仕事ごとにeffortを変えます。

まず、仕事を4つの運用プロファイルに分ける

Sonnet 5で使えるeffortは、low、medium、high、xhigh、maxの5段階です。

ただ、「普段は全部high」「難しそうならmax」と決めるだけでは粗すぎます。僕なら、先に仕事を4種類に分けます。

maxは、日常向けプロファイルの5つ目には入れません。トークン消費を抑えず、絶対的な能力を優先する設定だからです。失敗コストが非常に高く、xhighとの差を評価できる仕事で試します。

顧客データを一行ずつ分類する処理と、認証基盤の移行計画をレビューする処理に同じ設定を使う理由はありません。

簡単な仕事に高いeffortを使えば、コストと待ち時間が増えます。難しい仕事をlowで動かせば、プロンプトの文章は立派でも、検討が浅い結果になりやすい。

万能プロンプトを一本練るより先に、4つの運用プロファイルを作る。ここがSonnet 5を使い始めるときの基本です。

回答が浅いなら、プロンプトより先にeffortを上げる

effortを低くすると、Sonnet 5は指示をかなり文字どおりに受け取ります。

特にlowとmediumでは、頼まれた範囲に収まり、必要以上に仕事を広げません。速度とコストを優先したい処理では長所です。ただ、少し複雑な仕事をlowで実行すると、考察が足りなくなることがあります。

そこで、次のような指示を重ねたくなります。

コードを深く調査してください。
表面的な原因だけで判断しないでください。
複数の可能性を慎重に検討してください。
十分に考えてから回答してください。

設定がlowのままなら、「少ない計算量で深く考えて」と頼んでいる状態です。

複雑な仕事で推論が浅いなら、最初にhighまたはxhighへ上げます。

{
  "model": "claude-sonnet-5",
  "max_tokens": 16000,
  "output_config": {
    "effort": "high"
  },
  "messages": [
    {
      "role": "user",
      "content": "この障害の原因を調査し、修正してテストまで実行してください。"
    }
  ]
}

標準設定はhighです。難しいコーディングやエージェント処理にはxhighが推奨されています。

移行時の大まかな比較では、Sonnet 5のmediumがSonnet 4.6のhigh、Sonnet 5のhighがSonnet 4.6のmaxに近い知能と説明されています。ただし、設定名だけを横に並べて性能を決めるのは危険です。

移行時は、実際のthinking量、完了率、誤り、トークン数、待ち時間で比べます。lowを維持しなければならない理由がある場合だけ、プロンプトに「この仕事には複数段階の検討が必要」と対象を絞って補足します。

プロンプトは、設定の代用品ではありません。

Claude Codeの設定方法は、API用のJSONと異なります。セッション中に/effort highと指定するか、起動時にclaude --effort highを使います。継続して使う設定はeffortLevel、環境変数はCLAUDE_CODE_EFFORT_LEVELです。

adaptive thinkingが標準になり、max_tokensの設定がより重要になった

Sonnet 5では、thinkingフィールドを省略してもadaptive thinkingが動きます。Sonnet 4.6では、同じリクエストを送るとthinkingなしで実行されていました。

thinkingを完全に止めたい場合は、明示的に無効化します。

{
  "thinking": {
    "type": "disabled"
  }
}

反対に、以前のような手動予算は使えません。

{
  "thinking": {
    "type": "enabled",
    "budget_tokens": 32000
  }
}

この指定はSonnet 5では400エラーになります。thinkingの深さはadaptive thinkingとeffortで調整します。

もう一つ見落としやすいのがmax_tokensです。

max_tokensは最終回答だけの上限ではありません。thinking、ツール呼び出し、回答本文を含む出力全体の上限です。high、xhigh、maxではthinkingが大きな割合を使う場合があり、上限が小さいと、十分に考えたあとで肝心の回答が途中で切れます。

文章をトークンに分割するTokenizerも新しくなりました。同じ文章でもSonnet 4.6よりトークン数が約30%増える可能性があるため、以前のmax_tokensをそのまま流用するのは危険です。

モデル移行後に出力が変わっても、プロンプトだけが原因とは限りません。effort、thinking、max_tokensをセットで見ます。

ツールを使わない原因は、ツール説明だけとは限らない

Sonnet 4.6と比べると、Sonnet 5は自律的にツールを使い、その結果を自分で検証する傾向があります。

ただ、thinkingを無効にすると、検索やツール利用を検討する頻度も下がります。highやxhighでは、エージェント検索やコーディングにおけるツール利用が増えます。

ツールを使わないからといって、ツールの説明文だけを長くするのは早計です。まず、次の4点を確認します。

1. thinkingを無効にしていないか
2. effortが仕事に対して低すぎないか
3. ツールを使う条件が書かれているか
4. ツールを使ったあとの完了条件があるか

ウェブ検索、コード読み取り、テストを使うエージェントなら、次の程度で構いません。

現在の情報、外部サービスの状態、既存コードの実装を確認する必要がある場合は、
記憶だけで回答せず、対応する検索または読み取りツールを使う。

コードを変更した場合は、完了を報告する前に、
関連するテスト、Lint、型チェックのうち実行可能なものを実行する。

実行していない検証は、実行済みとして報告しない。

「ツールを積極的に使って」だけでは、いつ使うべきかが分かりません。「現在の情報を確認するとき」「既存実装を読むとき」「変更結果を検証するとき」など、ツールを使う条件を具体的に書きます。

細かな運用ルールを増やす前に、thinking、effort、利用条件、完了条件の組み合わせを見直します。長期タスクの進捗報告や検証設計は、Fable 5の記事で詳しく扱っています。

計算量とツールの配分を決めたら、次は仕事の種類に合わせて、指示の粒度と評価方法を変えます。

「察して」ではなく、適用範囲まで書く

effortが低いほど、Sonnet 5は指示を文字どおりに解釈します。

最初の項目に指定した形式を、残りの項目へ勝手に広げません。依頼していない変更も、以前より推測して実行しにくくなります。

構造化抽出や定型処理では、むしろ長所です。モデルが余計な一般化をしないため、入力と出力の対応を予測しやすくなります。

問題は、指示する側が適用範囲を省略したときです。

曖昧な指示

見出しの下に要約を付けてください。

範囲を明示した指示

すべてのH2見出しの直下に、50〜80文字の要約を1つ付けてください。
最初のH2だけでなく、本文中の全H2へ適用します。
H3には要約を付けません。

これはマイクロマネジメントではありません。手順を細かく固定せず、ルールがどこに適用されるかを明確にしています。

「必要に応じて」「いい感じに」「適切に」と書く前に、対象と除外対象、どこまで繰り返し適用するかを確かめます。

文体はtemperatureではなく、編集ルールと正例で作る

回答量は、仕事の複雑さに合わせて変わります。簡単な質問には短く、正解が一つではない分析には長く答えるので、通常は合理的です。

ただ、記事、カスタマーサポート、レポートのように、文体と長さが製品要件になっている場合は調整が要ります。

ここで注意したいのが、出力のばらつきを調整するtemperature、top_p、top_kです。Sonnet 5では、非デフォルト値を設定すると400エラーになります。これまで文章の揺らぎや多様性をtemperatureで作っていたなら、システムプロンプトと正例へ移します。

「親しみやすく」「プロらしく」だけでは、再現性が足りません。具体的な編集ルールに分解します。

# 文体

- 冒頭で読者の疑問または失敗例を具体的に示す
- 結論を先に書き、そのあとに理由と実例を続ける
- 1段落には一つの論点だけを置く
- 専門用語は最初の一度だけ説明する
- 一般的な称賛や、内容のない励ましは入れない
- 注意点は、読者の行動が変わるものだけを書く
- 最後は要点を言い換えず、次に取れる行動へつなげる

さらに、望ましい出力例を一つか二つ見せます。Anthropicも、適切な簡潔さを示す正例は、「長くしないで」「説明しすぎないで」といった否定指示より効きやすいと説明しています。

文体を作るのは、こうした編集判断の積み重ねです。

コーディングでは、最初の1ターンに仕様を集約する

コーディングエージェントは、ユーザーとのやり取りを増やせば必ず品質が上がるわけではありません。

Anthropicは、Sonnet 5をコーディングに使う際はhighまたはxhighを選び、人間との不要な往復を減らすことを勧めています。

質問を禁止する必要はありません。最初の依頼に、目的、意図、制約をまとめます。

曖昧な依頼を数ターンかけて少しずつ足すと、そのたびに文脈を読み直し、方針を修正し、同じコードを再調査します。トークン効率が下がり、性能も落ちる場合があります。

最初のメッセージには、次の項目をまとめます。

# 目的
何を実現するか。

# 背景
なぜ必要なのか。誰が、どの場面で使うのか。

# 対象範囲
変更してよい機能、ファイル、システム。

# 制約
使用技術、互換性、変更してはいけない部分。

# 完了条件
必要な画面、出力、テスト、受け入れ条件。

「ログイン画面を直して」だけでは、エージェントは不足している情報を推測で補います。ログインできない条件、対象ブラウザ、認証方式、変更可能な範囲、再現手順、成功条件まで渡せば、調査と実装を一つの流れで進められます。

ここでの狙いは、再読と再調査を減らすことです。自律性の最大化ではありません。長期タスクの権限や停止条件には、Fable 5の記事で扱った設計を使います。

コードレビューは「発見」と「選別」を分ける

Sonnet 5への移行後に、コードレビューの指摘数が減る場合があります。それだけで能力が下がったと判断するのは早いです。

以前のレビュー用プロンプトに、「重大な問題だけ報告する」「保守的に判断する」「確信度が高いものだけ出す」といった指示が入っていないでしょうか。

Sonnet 5は、こうした条件に以前より忠実に従います。コードを調査して問題候補を見つけても、「重大ではない」「確信度が足りない」と判断し、最終報告から落とす可能性があります。

この場合、報告した指摘が正しい割合である適合率は上がっても、実在する問題を拾えた割合である再現率は下がります。そこで、レビューを「発見」と「選別」の2工程に分けます。

第1段階は網羅性を優先する

この段階の目的は、指摘の精度ではなく網羅性です。

発見した問題候補は、重大度や確信度が低いものも含めて報告してください。
重要性を理由に除外しません。

各項目に次を付けてください。

- 問題の内容
- 発生条件
- 推定される影響
- 根拠となるコード
- 確信度
- 重大度

誤検知の除外、重複排除、優先順位付けは後続工程で行います。

第2段階で検証し、絞り込む

後続工程では、再現確認、重複排除、重大度の再評価を行います。

1回で完結させたい場合でも、「重要な問題」という曖昧な基準は避けます。たとえば、「誤った動作、テスト失敗、誤解を招く出力につながる問題は報告する。命名や純粋な書式だけの指摘は省く」と線を引きます。

コードレビューの品質を、報告件数だけで測ってはいけません。適合率、再現率、その両方のバランスを見るF1、実際に再現した不具合の数を、同じ評価セットで比べます。

フロントエンドでは「きれいでミニマル」と指示しない

フロントエンドの制作をSonnet 5に自由に任せると、一定のデフォルトスタイルに寄ることがあります。

画面として破綻しているわけではありません。ただ、ダッシュボード、開発者向けツール、金融、医療、企業向けサービスまで、似た色、似た角丸、似たカード構成になると、プロダクト固有の印象が消えます。

そこで「紫を使わない」「AIっぽくしない」「きれいでミニマルに」と頼んでも、別の固定パターンへ移るだけです。

色、書体、余白、角丸、情報密度、レイアウト、モーションまで具体的に指定する方法があります。あるいは、実装前に複数のデザイン方向を提案させ、選んだ一案だけを作らせます。

実装前に、この業務SaaSに合うビジュアル方向を4案提案してください。
まだコードは書きません。

各案に次を含めてください。

- 背景色とアクセント色のHEX
- 見出し用書体と本文用書体
- 角丸の大きさ
- 情報密度
- レイアウトの特徴
- 1行のデザイン意図

4案は、色だけでなく、書体、密度、構成も明確に変えてください。
選択された一案だけを実装します。

Sonnet 5では、temperatureで出力に多様性を持たせられません。そこで、最初に異なる方向を作り、人間が選ぶ工程が効きます。

「一発で正解を出す」より、「方向を分ける」「選ぶ」「実装する」です。

Sonnet 4.6からの移行は、モデル名だけで終わらない

AnthropicはSonnet 5を、モデルIDの差し替えだけで基本的に移行できる「drop-in upgrade」と案内しています。ただ、コード変更が小さいことと、挙動が同じことは別です。

移行時には、少なくとも次を確認します。

最後のrefusalは見落としやすい点です。

背景にあるのは、Sonnetクラスでは初となるリアルタイムのサイバーセキュリティ保護です。高リスクまたは禁止対象のサイバーセキュリティ依頼は、通信エラーにならず、HTTP 200の成功レスポンスでstop_reason: "refusal"を返す場合があります。

アプリケーション側では、この応答を通常の回答として表示しないように処理します。

新しいTokenizerでは、同じ文章でもトークン数が約30%増える可能性があります。1トークンあたりの価格が同じでも、同等の処理にかかる費用は変わり得ます。

モデル名を変えたら、代表的なタスクで成功率、必須項目の欠落、ツール利用、不要な停止、総トークン数、完了時間、一件あたりの費用を測ります。プロンプトを直すのは、その差が見えてからです。

Computer useでは、まず1080pを基準にする

画面を画像で見ながらマウスやキーボードを操作するComputer useを使う場合、Anthropicの内部テストでは1080pが性能とコストのバランスに優れています。コストを優先するなら720pまたは1366×768も候補です。

ツール環境も仕事ごとに評価します。最適な解像度は操作対象によって変わるため、effortと同じように、自分の画面と作業で測ります。

4つのSonnet 5運用プロファイル設定例

ここまでの内容を、4つの運用プロファイルにまとめます。以下はmessagesなどを省いた設定部分の例です。

1. 短い分類・抽出

{
  "model": "claude-sonnet-5",
  "max_tokens": 2000,
  "thinking": {
    "type": "disabled"
  },
  "output_config": {
    "effort": "low"
  }
}

カテゴリ分類、項目抽出、短い変換、定型応答向けです。

出力形式と適用範囲を厳密に指定します。判断が複雑になったら、プロンプトを継ぎ足す前にmediumへ上げます。

2. 判断を含む定型処理

{
  "model": "claude-sonnet-5",
  "max_tokens": 4000,
  "output_config": {
    "effort": "medium"
  }
}

同じ形式を繰り返し処理しながら、内容に応じた判断も必要な仕事向けです。

thinkingフィールドは省略し、adaptive thinkingを使います。必要な場合だけツールの利用条件を加えます。

3. 標準的な調査・実装

{
  "model": "claude-sonnet-5",
  "max_tokens": 16000,
  "output_config": {
    "effort": "high"
  }
}

thinkingフィールドを省略し、adaptive thinkingを使います。

検索、コード読み取り、編集、テストの条件を伝え、成果物と検証結果がそろった状態を完了とします。

4. 難しいコーディングエージェント

{
  "model": "claude-sonnet-5",
  "max_tokens": 64000,
  "output_config": {
    "effort": "xhigh"
  }
}

複雑なデバッグ、複数ファイルにまたがる実装、横断調査などに使います。

最初のユーザー入力に、目的、背景、対象範囲、制約、完了条件を集約します。可逆な作業を自律実行できる権限を用意し、thinkingとツール呼び出しのためにmax_tokensを十分に確保します。

64,000という値は、ここでの構成例です。実際の上限は、タスクと評価結果に合わせて決めます。

強いモデルを使うことと、すべてを最高設定で動かすことは違う

Claude Sonnet 5の性能を引き出すとは、すべての仕事をmaxで実行することではありません。

簡単な仕事には、短く速い設定を使う。難しい仕事で回答が浅ければ、「深く考えて」と重ねる前にeffortを上げる。ツールを使わせたいなら、thinking、発火条件、完了条件まで見る。

プロンプトは、今回の目的と合格条件を書く場所です。

effortは、どれだけ知能を使うかを決める設定。ツールと権限は、何を実行してよいかを決めるもの。評価セットは、その組み合わせが本当に改善したかを確かめるものです。

必要なのは、さらに長いプロンプトではありません。仕事ごとに、必要な知能を割り当てることです。

それではまた！

情報元

• What's new in Claude Sonnet 5 - Claude Platform Docs
• Effort - Claude Platform Docs
• Prompting Claude Sonnet 5 - Claude Platform Docs
• Stop reasons and fallback - Claude Platform Docs
• Model configuration - Claude Code Docs