メインコンテンツまでスキップ

Claude Sonnet 5.5:フィールドガイド

中級

2026 年 9 月 28 日、Anthropic は Claude Sonnet 5.5（claude-sonnet-5-5）をリリースしました。6 日前の Opus 5.5 に続く、5.5 ファミリー 2 番目のモデルです。興味深いのはレートカードですが、それはまさに価格が 動かなかったからです。入力 $2 / 出力 $10 per MTok で Sonnet 5 の価格とバイト単位で同一、トークナイザーも キャッシュ料金もバッチ料金も同じ。にもかかわらず Anthropic の主張は、出力が 30% 以上高速で、タスクあたり 最大 30% 安いというものです。

この 2 つは同時に成り立ちます。そしてなぜそうなるのかを理解することが、このページの主眼です。Sonnet 5.5 での 節約は トークン数とターン数に宿るのであって、トークン単価には決して宿りません。それは何を測るべきかを変え、 最初にどのつまみへ手を伸ばすべきかを変えます。

初日に知っておく価値のある 2 つ目のこと:安いモデルは高いモデルに一律で劣っているわけではありません。 Terminal-Bench 4.0 で Sonnet 5.5 は 70.6% を記録し、Opus 5.5 の 66.4% を上回ります — 公表された行の なかで、半額のモデルが前に出ている唯一の行です。そしてナレッジワークの Elo では両者は統計的に同等。残っている 差は特定の場所に集中しており、このページはそれがどこかを述べます。

What you'll learn
  • 実際の数字を押さえる:Sonnet 5 から変わらない $2/$10 per MTok、1M コンテキスト、128K の最大出力（Batches では 300K）、2026 年 6 月のカットオフ、デフォルトの effort は high
  • Sonnet 5 のコードベースを 400 エラーにする 5 つの破壊的変更を直す。そして 200 を返して進捗 UI を黙らせる 6 つ目も
  • between_tools を正しく使う — thinking disabled の代替であり、xhigh と max の effort では拒否され、あらゆる併記フィールドを拒否する
  • 発表時の表を正直に読む:Sonnet 5.5 が Opus 5.5 を上回るのはどこか、8 ポイント遅れるのはどこか、そしてなぜある行が 10.3% になっているのか
  • 設定を持ち越すのではなく effort をゼロから較正し直し、max effort が自発的なレビューに費やすセッションコストの約 1/3 を取り戻す
  • より静かな失敗モードに対処する:max_tokens まで思考し続ける構造化出力リクエスト、大文字小文字がずれたツール名、そして本物のユーザーメッセージをプロンプトインジェクションと誤認するケース

スペック、そして変わった 4 つの数字​

Sonnet 5Sonnet 5.5Opus 5.5
Claude API IDclaude-sonnet-5claude-sonnet-5-5claude-opus-5-5
入力 / 出力 per MTok$2 / $10$2 / $10$4 / $20
キャッシュ読み取り / 5 分書き込み$0.20 / $2.50$0.20 / $2.50$0.20 / $5
キャッシュ可能な最小プロンプト1,024 トークン512 トークン—
コンテキスト1M1M1M
最大出力（同期）128K128K128K
受け付ける thinking 設定adaptive, disabledadaptive, between_toolsadaptive のみ
デフォルトの efforthighhighmedium
信頼できるナレッジカットオフ—2026 年 6 月2026 年 6 月
提供終了はこれより早くしない—2027 年 9 月 28 日2027 年 9 月 22 日

この表のうち 4 つが本当に新しく、そのうち見出しになっているのは 1 つだけです:

  1. キャッシュ可能な最小プロンプトが半減、1,024 → 512 トークン。 システムプロンプトが 600〜1,000 トークンの範囲にあるなら、Sonnet 5 では黙ってキャッシュ不可だったものが、いま読み取り時に 入力価格の 10% でキャッシュできます。コード変更なし、ベータヘッダーなし。このページ全体でいちばん安い勝ちです。
  2. thinking: {"type": "disabled"} は廃止され、between_tools に置き換わりました。Sonnet 5.5 は Sonnet 5（disabled を受け付けた）と Opus 5.5（どちらも受け付けない）の中間に位置します — 事前の思考を スキップすることは依然できますが、新しい名前と新しい制限のもとでです。
  3. デフォルトの effort は high のまま — これは Opus 5.5 の medium デフォルトより高いことに注意。 安いモデルのほうが、素の状態では高いモデルよりターンあたり多く思考します。
  4. temperature、top_p、top_k はデフォルト以外の値で 400 を返します — 5.x ラインの他と同様です。 サンプリングパラメータのスイープはここではチューニング面ではありません。effort がそれです。

トークナイザーは Sonnet 5 から変わっていないので、同じテキストは同じトークン数になります。請求額で観測される 変化はすべて、モデルが選んで出力したトークン数の変化です。

価格が下がっていないのに請求額が下がる理由​

ここは多くの発表記事が「30% 安い」に圧縮して、微妙に誤る部分です。レートカードは同一。Anthropic の主張は 3 つの別個の効果に分解でき、それらは捕まえやすさが同じではありません:

Guided walkthrough1 of 3
  1. 入力 $2 に対して出力は $10/MTok で、高いのは出力側です。Sonnet 5.5 は Sonnet 5 より少ない出力トークンで同じ結果に到達します。これには thinking トークンも含まれます — thinking は、そのテキストが返されない場合でも出力として課金されます。この効果は、同じコードのまま無料で手に入ります。

効果 1 と 2 は、持ち越した effort 設定がちょうど打ち消してしまえるものです。だからこそ次の節が、モデル ID を 変える前に読むべき節になります。

Effort:持ち越さず、較正し直す​

Anthropic は effort レベルが再較正されていることを明言しています — あるレベルが買う思考の量は、Sonnet 5 で 買っていた量とは違います。変換表は、意図的に存在しません。スイープをやり直してください。

公表されている出発点はデフォルトではありません:

ワークロード出発点理由
一般 / 不明highAPI のデフォルト。
エージェンティックコーディング、多段のツール利用、仕様が明確mediumより難しい、またはより長いタスクでは high へ。
チャット、レイテンシに敏感medium または loweffort が高いほど、返答が始まるまでの待ち時間が長くなる。
何であれxhigh / max品質向上を測定した場合にのみ。

本番で刺さる 3 つの帰結:

  • リクエスト間でトップレベルの effort を変えるとプロンプトキャッシュが無効化されます。 安いインタラクティブ セッションで難しいターンだけ引き上げたいなら、メッセージ単位の effort ベータ（1 つのメッセージに対する output_config.effort）を使ってください。キャッシュが保たれます。このベータは 5.5 で新しく、Sonnet 5 では 利用できませんでした。
  • max_tokens は thinking と返答の両方をカバーしなければなりません。 thinking のテキストが応答から省かれて いても、thinking はこれに対してカウントされます。思考なしのリクエスト用に決めた上限は切り詰められます。 エージェンティックコーディングについての Anthropic のガイダンスは率直です:max_tokens を 128,000 に設定して ストリーミングしなさい。
  • モデルに「あまり考えるな」と頼んでも確実には効きません。 effort レベルを下げると効きます。medium 以上では ほぼすべての返答の前に思考し、low では単純なリクエストのほとんどで思考をスキップします。

max effort のレビュー税​

xhigh と max では、Sonnet 5.5 はタスクが終わっても止まりません。自前のレビューと検証のラウンドを始め、 ハーネスがサブエージェントを提供していればレビュアーのサブエージェントを起動します — 頼まれもせずに。 Anthropic は修正策を、そして珍しくその効果の大きさも公表しました:max effort のコーディングタスクでの彼らの テストにおいて、下の段落は品質を変えずにセッションコストを約 3 分の 1 削減しました。

xhigh と max の effort で自発的なレビューラウンドを止める

When the work the user asked for is done and its checks pass, stop and report. Don't start extra
rounds of review or hardening on your own, and don't launch reviewer sub-agents unless the user
asked for a review. If you think a deeper review is worth doing, say so at the end.

これは自発的なレビューを不可能にするのではなく、まれにします。鏡像の問題はレンジの下端にあります:長い エージェンティックタスクでの low と medium では、モデルは完了前に止まって確認を取る可能性が高くなり、 low ではコード変更を、それを実際に動かすチェックを走らせずに完了と報告することがあります。

5 つの破壊的変更​

いずれも、Sonnet 5 で動いていたコードに対して HTTP 400 invalid_request_error を返します。

1. disabled → between_tools​

thinking: {"type": "disabled"} は、代替の名前を示すメッセージとともに 400 を返します:

"thinking.type.disabled" is not supported for this model. Use "thinking.type.between_tools" for the
lowest thinking setting, or "thinking.type.adaptive" and "output_config.effort" to control thinking
behavior.

between_tools は Sonnet 5.5 でもっとも低い thinking 設定です。ベータヘッダーは不要で、このモデルを提供する すべてのプラットフォームで動きます。ただし disabled よりずっと気難しいです:

  • low、medium、high で受け付けられます。xhigh または max では 400 を返します — それらのレベルは アダプティブ thinking を要求します（thinking を省略する、または thinking: {"type": "adaptive"} を送る。 両者は等価です）。
  • effort を会話の途中で変えられません。 有効なレベルと異なるメッセージ単位の output_config.effort は 400 を返します。ターン単位の effort にはアダプティブ thinking が必要です。
  • 併記フィールドを一切取りません。 display、budget_tokens、block_binding を並べて送ると 400 を返します。 手動の予算指定（thinking: {"type": "enabled", "budget_tokens": N}）も 400 です。
  • サーバーサイドフォールバックでは、between_tools のリクエストが Sonnet 5 にフォールバックした場合、 そこでは thinking: {"type": "disabled"} で実行されます — 設定はフォールバックをまたいでマップされます。

もう 1 つの罠:between_tools では、モデルに思考するなと指示している行をすべて削除してください。 それらの 行は、モデルが内部の XML タグを可視の出力に書き込む可能性を高めます。

thinking を切っていた統合の移行 — Sonnet 5 から Sonnet 5.5 へ

# Before — accepted on Sonnet 5
client.messages.create(
  model="claude-sonnet-5",
  max_tokens=16000,
  thinking={"type": "disabled"},
  output_config={"effort": "xhigh"},      # fine with disabled on Sonnet 5
  messages=[{"role": "user", "content": "..."}],
)

# After — on Sonnet 5.5: rename the type AND drop effort to high or below
client.messages.create(
  model="claude-sonnet-5-5",
  max_tokens=16000,
  thinking={"type": "between_tools"},     # xhigh/max with this -> 400
  output_config={"effort": "high"},
  messages=[{"role": "user", "content": "..."}],
)

# If you need xhigh or max, use adaptive thinking instead of between_tools:
#   thinking={"type": "adaptive"}   (or omit the field entirely)

# SDKs that predate between_tools fail type checking on the literal.
# Update the SDK, or pass the value as raw JSON.

2. 強制的なツール利用が拒否される​

tool_choice を {"type": "any"} または {"type": "tool", "name": "..."} に設定すると 400 を返します:

tool_choice: type "tool" and "any" are not supported for this model.

auto（デフォルト）と none はまだ動きます。同じチェックがトークンカウントのエンドポイントにも適用され、 /v1/messages だけを叩くテストスイートでは見落としやすいところです。

強制的なツール利用は 2 つの仕事をしていました。分けましょう:

  • スキーマの妥当性はstrict tool use（ツールに strict: true）または構造化出力から得ます。
  • 誘導 — モデルにそのツールを実際に呼ばせること — は、そのツールがいつ当てはまるかをプロンプトで述べることから 得ます。

3. thinking ブロックはモデル、会話、アカウントに紐づけられる​

すべての thinking ブロックは、どのモデルが生成したかを記録し、モデルは一部の他モデルのブロックしか読みません。 このグラフは非対称で、直感的ではありません:

ブロックの生成元Sonnet 5.5 は読めるか？
Sonnet 5.5 自身はい
Sonnet 5、Opus 4.8、Haiku 4.5 とそれ以前はい
Opus 5、Opus 5.5いいえ
Fable または Mythos の各モデルいいえ

そして逆方向には:他のどのモデルも Sonnet 5.5 の thinking ブロックを読みません。 したがって Sonnet 5 から Sonnet 5.5 へ上がる会話は推論を保ちますが、Sonnet 5.5 から他の何かへ移る会話は — 魅力的なエスカレーション 先である Opus 5.5 を含めて — 以降のすべてのターンを推論なしで走ります。読めないブロックはモデルが見る前に 捨てられ、リクエストは成功し、捨てられたブロックは課金されません。thinking-binding-controls-2026-08-01 ベータヘッダーを付けると、捨てられた内容がトップレベルの input_transformations 配列に列挙されます。

さらに 2 つの紐づけがその上に乗ります:

  • 会話プレフィックス。 API は、Sonnet 5.5 の thinking ブロックが生成されてから system プロンプト、 tools リスト、またはそれ以前のメッセージが変わっていないかを確認します。これは 2026 年 8 月 31 日 00:00 UTC 以降に作成されたアカウントに対してデフォルトで、Claude API、Bedrock、Google Cloud で強制されます — そうした編集の後にブロックを再送すると、そこでは 400 を返します。失敗させる代わりに該当ブロックを捨てるには、 thinking-binding-controls-2026-08-01 を送り、thinking.block_binding.prefix_mismatch_behavior を "drop_block" に設定します。block_binding はアダプティブ thinking でしか働かないことに注意。between_tools のもとでの選択肢は、追記のみの履歴か、編集したターン以降の thinking ブロックを取り除くことだけです。
  • アカウント。 Sonnet 5.5 の thinking ブロックは、それを生成したアカウント、または連携したアカウントでのみ 機能します。別のアカウントが送ると捨てられ、binding-controls ベータのもとでは reason: "organization_binding_mismatch" として報告されます。より古いモデルのブロックは影響を受けません。
Guided walkthrough1 of 5
  1. Claude Code、claude.ai、Claude Managed Agents、Claude Agent SDK はすでにそうしています。追記のみの統合には変更は不要です。

4. computer_20251124 が拒否される — 3 つのうち 2 つのプラットフォームで​

Claude API と Google Cloud では、Sonnet 5.5 は computer_toolset_20260801 ツールセット経由でしか コンピュータ利用をサポートしません。古い computer_20251124 ツールを宣言すると 400 を返します:

'claude-sonnet-5-5' does not support tool types: computer_20251124.

Amazon Bedrock では、Sonnet 5.5 はまだ computer_20251124 を受け付けます。 この非対称性は、マルチ プラットフォームのデプロイが片方のクラウドで CI を通り、別のクラウドで落ちる類の原因になります。移行の内容は: 古いベータヘッダーを外し、tools のエントリを {"type": "computer_toolset_20260801"} に置き換え、メンバーの tool_use ブロック、バッチアクション、結果の toolset_name に合わせてエージェントループを更新する。すでに このツールセットを使っている統合、およびブラウザ利用ツールを使うものは、変更不要です。

5. advisor の組み合わせが狭まった​

advisor ツール（ベータ）では、Sonnet 5.5 のexecutor は advisor として Mythos 5.1、Fable 5.1、Mythos 5、 Fable 5、Opus 5.5、Opus 5、または Sonnet 5.5 自身を受け付けます。Opus 4.8、Opus 4.7、Sonnet 5 は 400 で 拒否されます — 3 つはいずれも Sonnet 5 の executor では advisor として動いていました。Sonnet 5.5 が受け付ける advisor はすべて、助言を暗号化して advisor_redacted_result ブロックとして返すため、クライアントは助言の テキストを読めません。

6 つ目の変更:HTTP 200、そして UI が静まる​

これは何も失敗させず、ログに届く前にユーザーに届く可能性がもっとも高いものです。

ツール呼び出しの合間に、Sonnet 5.5 はいま何を見つけ次に何をしているかについて、ユーザー向けのメモを書きます。 1〜2 文より長いメモは、いまや進捗更新の thinking ブロックとして返ってきます。短い所見は text のままです。 デフォルトの display: "omitted" では、進捗更新ブロックの text フィールドは空です。したがって text ブロックだけを描画するクライアントは、長いエージェンティックなターンのあいだ何も表示しません — エラーもなく、 警告もなく、ナレーションがあった場所にただ沈黙があるだけです。

手間の少ない順に、3 つの脱出路:

  1. between_tools を使う。 メモは要約テキスト付きで返ってきます。display フィールドは不要です （そして受け付けられません）。
  2. display: "updates" を設定する — thinking-display-updates-2026-08-18 ベータヘッダーとともに。推論自体は 隠したまま、各進捗更新の短い要約が得られます。
  3. ユーザーにメッセージを送るツールをモデルに与える — ターンの途中で正確なテキストを見せる必要がある場合 （コードスニペット、答えてほしい質問）のために。そうした内容にのみそのツールを使うよう指示し、tools が 後から変わらないよう最初のリクエストでそのツールを宣言してください。

そのうえで周辺を片付けます:「すべての発見は最終応答まで保留せよ」のような指示を削除し、予測可能な時点で 更新が欲しいなら明示的に求めてください — 最初のツール呼び出しの前に 1 行、最後にまとめを。モデルはそれに従います。

それでも長いターンが静まるなら、ハーネスから促すことができます — ただし慎重に。ユーザーにテキストを送らなかった 連続するツール呼び出しステップを数え、数回（たとえば 5 回）を超えたら、最新のツール結果の後ろに、ターン スコープのシステムメッセージとして 1 ターン限りのリマインダーを追記します:

静かになったエージェンティックターンに対するハーネスの促し

The user hasn't heard from you in a while — say in a few words what you're doing, then continue.

効かない場合は 2 回目か 3 回目で止めてください。ツール結果の後にハーネスのテキストが頻繁に現れると、モデルは プロンプトインジェクションを疑います — それが次の節です。リマインダーは挿入して後で取り除くのではなく追記 されるため、プロンプトキャッシュと保存された thinking の両方が生き残ります。Anthropic の測定では、high effort でユーザーにメッセージを送るツールが利用可能な場合、これはタスク品質に測定可能な変化を与えずに、 沈黙のもっとも長い区間を短くします。

発表時の表を正直に読む​

ベンチマークSonnet 5Sonnet 5.5Opus 5.5Opus 5.5 比の Sonnet 5.5
Terminal-Bench 4.010.3%70.6%66.4%106%
GDPval-AA v2.1 (Elo)14491844184699.9%
AA-Briefcase v1.1 (Elo)13591811182299.4%
OSWorld 2.1（部分点）—80.1%81.8%98%
CursorBench 4.034.1%55.5%57.8%96%
Chartography（ツールなし）—61.6%64.4%96%
Humanity's Last Exam（ツールあり）54.9%64.5%67.7%95%
FrontierCode 1.1（max effort）42.4%46.2%54.4%85%

この表の正直な読み方が 4 つ:

  • 差は一律ではなく、平均して均してしまうと有用なシグナルが隠れます。 ナレッジワークの Elo では、2 つの モデルは互いのノイズの内側にあります。もっとも難しいコーディングベンチマークである FrontierCode 1.1 では、 Sonnet 5.5 は 8.2 ポイント遅れ — Opus 5.5 の 85% です。この 1 行こそが、複雑で終わりの開いた、持続的な 判断を要する仕事では Opus 5.5 が明確に強いままだという Anthropic 自身の位置づけの、正直な根拠です。
  • Terminal-Bench 4.0 は半額のモデルが勝つ唯一の行で、70.6% 対 66.4% です。このベンチマークは「仕事が 終わるまでシェルでエージェントを走らせる」の、公表されているものとしてもっとも近い代理指標であり、そこは まさにツール呼び出しとトークンの少なさが複利で効く場所です。
  • Terminal-Bench 4.0 における Sonnet 5 の 10.3% は、畏敬ではなく疑いをもって扱ってください。 1 つの ベンチマークバージョンで 60 ポイントの世代間ジャンプがあるということは、モデルについてと少なくとも同じくらい、 ハーネスとスコアリングのバージョンについて多くを語っています。これは「このベンチマークのこのバージョンは Sonnet 5 のエージェント挙動を罰する」と結論するために使い、「Sonnet 5.5 はエージェンティックコーディングで 7 倍良い」と結論するためには使わないでください。
  • effort レンジの上端における FrontierCode について、情報源が食い違っています。 Anthropic の表は max effort で 46.2% を報告していますが、少なくとも 1 つのアグリゲーターは xhigh でより高い 52.1% を報告して います。2 つ目の数字を一次情報の表と照合できていないため、未検証として読んでください — ただし「effort を 増やしたらスコアが下がった」は、単調な改善を仮定するのではなく品質向上を測定できた場合に xhigh と max を取っておけというドキュメント自身の助言と整合的であることには注意してください。

独立した測定は、常にそうであるように、エージェンティックなベンチマークではベンダーの測定より低い値に着地します。 数字をスライドに載せる前に、自分の評価を走らせてください。

静かな失敗モード​

いずれも例外を投げません。いずれも精度か信頼を失わせます。

尽きるまで思考する構造化出力​

いくつかの段階の計算を要するタスク — 文書から数値を合計する、ルールを適用する、項目を順位づける — に JSON の 答えを求めると、Sonnet 5.5 はしばしば先に思考せずに答えます。とくに low と medium の effort でです。 構造化出力では応答テキストは JSON だけを保持するので、計算過程は thinking 以外に行き場がありません。思考を スキップすれば精度は落ちます。

  • アダプティブ thinking では、システムプロンプトに Think the problem through before you answer. を追記すると、 控えめな出力トークン増で high effort の精度が xhigh に近づきます。
  • between_tools はこうしたリクエストには誤った設定です:ツールが関与しないなら、それは思考ゼロを意味し、その行は 何の効果も持ちません。
  • 構造化出力での low と medium では、モデルが max_tokens に達するまで思考し続けることが時折あります。 stop_reason: "max_tokens" の応答は、そのテキストがたまたま妥当な JSON を含んでいても、失敗として扱い リトライしてください。これは、自信に満ちた誤った数字を出荷するもっともありそうな経路です。

構造化出力を使えずプロンプトで JSON を求める場合、モデルは応答テキストの中で問題を解き、JSON を最後に置く 傾向があります。最初の { から最後の } まで切り出さないでください — 最終回答の前に下書きを書くことが 時折あり、両方を捕まえてしまいます。

混在した応答から最後の JSON 値を取り出す

# Read only text blocks. Treat stop_reason == "max_tokens" as a failure and retry.
# Starting at each { or [, try to parse a JSON value; continue from the END of a value
# that parses, so values nested inside it are not counted on their own. Keep the LAST one.

import json

def last_json_value(text):
  dec, best, i = json.JSONDecoder(), None, 0
  while i < len(text):
      if text[i] in "{[":
          try:
              value, end = dec.raw_decode(text, i)
          except ValueError:
              i += 1
              continue
          best, i = value, end          # jump past it: skip nested values
      else:
          i += 1
  return best

# Then check the fields you expect are present, and retry once if they are not.

本物のユーザーメッセージがプロンプトインジェクションと読まれる​

Sonnet 5.5 は間接的なプロンプトインジェクション — ツール結果や、タスク途中で読むその他のコンテンツを通じて 届く指示 — に抵抗するよう訓練されています。時折、本物のユーザーメッセージをそう誤分類し、ツール結果に ユーザーからのメッセージを装ったテキストが含まれていたとユーザーに告げ、それを無視するか確認を求めます。 引き金は配置です:ツール結果の直後に届くテキスト、とくに毎ステップで届く場合です。

  • ユーザーのテキストを tool_result ブロックの中に入れないでください。 これがもっとも誤読されやすい配置です。
  • ターン途中のユーザー入力はユーザーターンとして届けます:tool_result ブロックを運ぶユーザーメッセージの 中に、最後の tool_result の後ろでテキストブロックとして追記します。
  • ハーネスの通知は別の会話中システムメッセージに、ユーザーの言葉の後ろで保ちます。通知とユーザーの言葉を 同じブロックに入れないでください。
  • ユーザーがターン途中で入力できるインタラクティブなセッションでは、ツール結果の後に自前のトークン/予算の カウントダウンを置くのをやめてください。ステップごとのカウントダウンが古典的な原因です。Task budgets ベータも 似たカウントダウンを加えますが、この誤読を引き起こすのは観測されていません。

大文字小文字がずれたツール名​

Sonnet 5.5 は、宣言されたツールを大文字小文字だけが違う名前で呼ぶことが時折あります — Bash に対して bash — あるいは既知のパラメータを少し違う名前で渡します。これを致命的として扱わないでください。マッチが曖昧でない ときは呼び出しを受け入れるか、期待される正確な名前を述べる is_error: true の tool_result を返してください。 モデルはたいてい次のターンで自ら修正します。

チャート:effort を与える前にツールを与える​

密なチャートや技術図面には、画像を切り出す、ズームする、あるいは画像に対してコードを走らせる手段をモデルに 与えてください。測定された結果は内面化する価値があります:high effort でツールありのほうが、max effort で ツールなしよりも正確にチャートを読み、コストはごく一部でした。 技術図面ではツールは high 以上でのみ助けに なり、xhigh と max でもっとも効きます。ダイヤルではなく、ツールに手を伸ばしてください。

拒否:5 つのカテゴリ、リトライされるのは 2 つだけ​

拒否されたリクエストは HTTP 200 で、stop_reason: "refusal" と、カテゴリを示す stop_details オブジェクトを 伴います。Sonnet 5.5 は、Anthropic のもっとも高性能なモデルに匹敵するサイバーセーフガードを備えて出荷された 最初の Sonnet であり、推論の抽出をブロックする分類器を備えた最初の Sonnet です。

stop_details のカテゴリ対象サーバーサイドフォールバックは Sonnet 5 でリトライするか？
cyberサイバー上の危害を可能にしうるもの — マルウェア、エクスプロイト開発。ソースコード中の脆弱性を見つけることは許容され、高リスクのデュアルユース作業は許容されない。はい
frontier_llm競合する AI モデルの開発を助けうるもの。はい
bio生物学的な危害を可能にしうるもの。日常的な健康や教育目的の質問は影響を受けない。いいえ
reasoning_extraction内部の推論を応答テキストに再現することをモデルに求めるもの。いいえ
general_harms利用ポリシーの別の領域。無害な作業がこれを引き起こすこともある。いいえ

実務的な注意が 2 つ。第一に、プロンプトがモデルに推論を回答に含めるよう求めているなら、それらの行を削除して ください — reasoning_extraction の拒否を招きます。推論は代わりに要約された thinking ブロック （display: "summarized"）から読んでください。第二に、出力の前に届く拒否が課金されるかどうかはそのカテゴリに 依存し、いずれにせよレート制限にはカウントされます。

bio 分類器にブロックされた正当なライフサイエンスの作業は、Anthropic の Life Sciences Verification Program に 申請できます。

では実際にどのモデルを走らせるか？​

Guided walkthrough1 of 5
  1. 日常のタスク、バグ修正、多段のツール利用、仕上げられた文書とスプレッドシート。エージェンティックコーディングは medium effort から、一般的な仕事は high から始めて、測定してください。$2/$10 で 1M コンテキストという条件で、ナレッジワークにおいてなおフロンティア近傍にとどまるラインナップ中もっとも安いモデルです。

移行そのものはモデル ID の入れ替えと 6 つのチェックで、Anthropic はそのための自動化を提供しています: Claude Code で /claude-api migrate this project to claude-sonnet-5-5 を実行すると、コードベース全体に対して ID の入れ替えと破壊的なパラメータ変更を適用し、手で確認すべき項目のチェックリストを渡してくれます。何かを 編集する前にスコープの確認を求めます。Messages API を直接使うのではなく Claude Managed Agents を使っている場合、 必要な変更はモデル名だけです。

Enter キーまたはスペースキーでカードを裏返します。左右の矢印キーでカードを移動できます。用語を表示しました。
1 / 10

Check yourself

0/6
  1. Sonnet 5.5 は Sonnet 5 とまったく同じ価格 — $2/$10 per MTok、同じキャッシュ料金、同じトークナイザー — を課金します。それでも Anthropic はタスクあたり最大 30% 安いと主張します。節約はどこから来るのでしょうか？
  2. あなたの統合は Sonnet 5 を thinking: {"type": "disabled"} と output_config の effort "xhigh" で動かしています。Sonnet 5.5 に向けた最小限の正しい変更は何でしょうか？
  3. チャットプロダクトを Sonnet 5.5 に移行した後、ツールを使う長いターンのあいだアシスタントが固まって見えるとユーザーが報告します。最終的な回答は問題なく届き、エラーもログに出ていません。何が起きたのでしょうか？
  4. Sonnet 5.5 の会話で難しいターンが来て、もっと深さが欲しくなりました。そこまでに蓄積された推論を保てる選択肢はどれでしょうか？
  5. 請求書から合計を抽出するために、medium effort で構造化出力を使っています。ある応答が stop_reason "max_tokens" で返ってきましたが、そのテキストはもっともらしい数字を含む妥当な JSON としてパースできます。コードは何をすべきでしょうか？
  6. 発表時のベンチマーク表について、正確な記述はどれでしょうか？

次に​

出典と参考資料​