はじめに
Anthropic は 2026 年 9 月 28 日に Claude Sonnet 5.5 を公開しました。Claude 5.5 ファミリーの 2 つ目のモデルで、Claude Opus 5.5 より速く安い位置づけです。価格は Claude Sonnet 5 から据え置かれています。
モデル ID を書き換えるだけで移れそうに見えますが、公式ドキュメントは「Claude Sonnet 5 で動いているコードに影響する破壊的変更が 5 つある」と明記しています。そのうちいくつかは、これまで普通に使われてきた設定が 400 エラーになる変更です。
本記事では、公式発表とドキュメントをもとに、Sonnet 5.5 で何が変わったか、どう呼び出すか、移行で何を直す必要があるかを整理します。
対象読者は、Claude API（Messages API）を使ったアプリケーションやエージェントを運用していて、Sonnet 5 から Sonnet 5.5 への切り替えを検討している開発者です。
検証の範囲
| 内容 | 根拠 |
|---|---|
| Claude Code から Sonnet 5.5 を指定して動くか、コンテキスト長・最大出力・課金の内訳 | 実機（claude -p の JSON 出力） |
| 出力速度と思考トークン量の Sonnet 5 との比較 | 実機（同じプロンプトで各 3 回） |
SDK が claude-sonnet-5-5 と between_tools を型として持つ最小バージョン |
実機（pip / npm でインストールし、mypy で型チェック） |
| 400 エラーになる 5 つの破壊的変更とエラーメッセージ | 公式ドキュメント（API キーでの直接呼び出しは未実施） |
| ベンチマーク・提供プラットフォーム | 公式発表（未検証） |
実機の環境は Claude Code 2.1.284 のクラウド実行環境（Linux）、Python 3 の venv、Node.js 22 です。Messages API を API キーで直接呼ぶ環境は無いため、Claude Code の -p（非対話モード）経由で呼び出しています。Claude Code 自身のシステムプロンプトが毎回入力に含まれる点に注意してください。
TL;DR
- Claude Sonnet 5.5（
claude-sonnet-5-5）は入力 $2 / 出力 $10（100 万トークンあたり）で、Sonnet 5 と同じ価格です - 公式発表では、出力は Sonnet 5 比で 30% 以上速く、タスクあたりのコストは最大 30% 下がるとされています
- コンテキストは 1M トークン、最大出力は 128K トークン、既定の effort は
highです -
thinking: {"type": "disabled"}と、tool_choiceのany/toolは 400 エラーになります - 移行の中心は「thinking の切り方」「強制ツール呼び出しの置き換え」「会話履歴を追記のみにすること」の 3 点です
- Claude Code 経由で実測すると、出力速度は Sonnet 5 の約 1.4 倍、同じ計算問題の思考トークンは Sonnet 5 の約 5 分の 1 でした（各 3 回・正答は同じ）
-
between_toolsを型として持つのは Python SDK 1.9.0・TypeScript SDK 0.129.0 からで、1.8.0 では mypy が型エラーを出しました
何が発表されたか
モデルの位置づけと仕様
公式のモデル概要ページでは、Sonnet 5.5 は「速度と知能の最良の組み合わせ」、Opus 5.5 は「長時間のエージェント的コーディングと知識労働向け」と説明されています。公式発表は Sonnet 5.5 を、Opus 5.5 を補完するより速く安いモデルと位置づけています。
| 項目 | Claude Sonnet 5.5 | Claude Opus 5.5 | Claude Haiku 4.5 |
|---|---|---|---|
| API モデル ID | claude-sonnet-5-5 |
claude-opus-5-5 |
claude-haiku-4-5-20251001 |
| 価格（入力 / 出力、100 万トークンあたり） | $2 / $10 | $4 / $20 | $1 / $5 |
| コンテキスト | 1M | 1M | 200K |
| 最大出力 | 128K | 128K | 64K |
| Thinking | Adaptive | Adaptive（常時オン） | Extended |
| 既定の effort | high |
medium |
非対応 |
| 相対レイテンシ | Fast | Moderate | Fastest |
| 知識の信頼できるカットオフ | 2026 年 6 月 | 2026 年 6 月 | 2025 年 2 月 |
プロンプトキャッシュは読み込みが $0.20、5 分キャッシュの書き込みが $2.50、1 時間キャッシュの書き込みが $4（いずれも 100 万トークンあたり）です。Batch API は入出力とも 50% 引きです。トークナイザーは Sonnet 5 と同じなので、同じテキストなら同じトークン数になります。
提供先は Claude API、Amazon Bedrock（anthropic.claude-sonnet-5-5）、Claude Platform on AWS、Google Cloud、Microsoft Foundry です。廃止は 2027 年 9 月 28 日より前には行わないとされています。
なお、Claude Haiku 5.5 は「数週間以内」に登場予定と公式発表で予告されています。
公式ベンチマーク
公式発表ページに掲載されている主な数値です。数値はいずれも Anthropic が公表したもので、評価条件（effort やツール有無）は発表ページの脚注に依存します。たとえば FrontierCode の Sonnet 5.5 の値は Max effort、Terminal-Bench の Opus 5.5 の値は Xhigh effort の結果で、OSWorld 2.1 の 3 モデルの値には partial の注記が付いています。
| ベンチマーク | Sonnet 5.5 | Sonnet 5 | Opus 5.5 |
|---|---|---|---|
| Terminal-Bench 4.0 | 70.6% | 10.3% | 66.4% |
| FrontierCode 1.1（Main） | 46.2% | 42.4% | 54.4% |
| CursorBench 4.0 | 55.5% | 34.1% | 57.8% |
| GDPval-AA v2.1（Elo） | 1844 | 1449 | 1846 |
| OSWorld 2.1 | 80.1% | 57.0% | 81.8% |
| Humanity's Last Exam（ツールあり） | 64.5% | 54.9% | 67.7% |
知識労働系の GDPval-AA では Opus 5.5 との差が 2 ポイントしかありません。一方で FrontierCode のように難度の高いコーディング評価では Opus 5.5 が明確に上回っています。速さと価格を優先する作業は Sonnet 5.5、長く難しいコーディングは Opus 5.5 という使い分けが、数値の並びからも読み取れます。
最小の呼び出し方
モデル ID を差し替えるだけで、Sonnet 5 と同じ形の呼び出しが通ります。Adaptive thinking は既定でオンで、effort の既定は high です。
import anthropic
client = anthropic.Anthropic()
response = client.messages.create(
model="claude-sonnet-5-5",
max_tokens=16000,
output_config={"effort": "medium"},
messages=[{"role": "user", "content": "このエラーログの原因を3行で説明してください"}],
)
print(response.content[-1].text)
公式ドキュメントは effort について「Sonnet 5 と同じ設定を持ち越さず、測り直す」ことを勧めています。同じ effort でも考える量が Sonnet 5 とは違うためです。出発点の目安は次のとおりです。
| ワークロード | 推奨の開始 effort |
|---|---|
| 一般的な用途 | high |
| 仕様がはっきりしたエージェント的コーディング・複数ステップのツール利用 |
medium（難しい・長いタスクは high） |
| チャットなどレイテンシ重視の用途 |
medium または low
|
effort は low / medium / high / xhigh / max の 5 段階です。
Claude Code から呼び出して確かめたこと
ここからは、Claude Code のクラウド実行環境で実際に動かした結果です。Claude Code は --model でモデルを、--effort で effort を指定でき、--output-format json で使用量の内訳を返します。
モデルの上限と課金の内訳
作業ディレクトリを一時ディレクトリにして、次のコマンドを実行しました。
claude -p --model claude-sonnet-5-5 --output-format json \
"1から10までの整数の和を答えだけ返してください"
出力 JSON の modelUsage 部分を抜粋します。
"modelUsage": {
"claude-sonnet-5-5": {
"inputTokens": 2,
"outputTokens": 3,
"cacheReadInputTokens": 0,
"cacheCreationInputTokens": 31981,
"costUSD": 0.12795800000000002,
"contextWindow": 1000000,
"maxOutputTokens": 128000,
"thinkingTokens": 0,
"canonicalModel": "claude-sonnet-5-5",
"provider": "firstParty",
"costBasis": "list"
}
}
contextWindow が 1,000,000、maxOutputTokens が 128,000 で、公式ドキュメントの 1M / 128K と一致しました。
課金額も公式の単価で説明できます。usage.cache_creation を見ると、31,981 トークンはすべて 1 時間キャッシュ（ephemeral_1h_input_tokens）への書き込みでした。1 時間キャッシュの書き込み単価 $4、入力 $2、出力 $10（いずれも 100 万トークンあたり）で計算すると、次のようになります。
| 内訳 | トークン | 単価（/MTok） | 金額 |
|---|---|---|---|
| 1 時間キャッシュ書き込み | 31,981 | $4 | $0.127924 |
| 入力 | 2 | $2 | $0.000004 |
| 出力 | 3 | $10 | $0.000030 |
| 合計 | $0.127958 |
合計は JSON の costUSD（0.127958）と一致します。ほとんどが Claude Code のシステムプロンプトをキャッシュに書き込む費用で、2 回目以降の呼び出しではキャッシュ読み込み（$0.20）に変わります。
出力速度
同じプロンプト（Python の型ヒントのベストプラクティスを 20 項目書かせる）を、effort low で Sonnet 5.5 と Sonnet 5 に 3 回ずつ投げ、出力トークン数を duration_api_ms で割りました。
| モデル | 出力トークン（3 回） | API 時間（ms、3 回） | 出力速度の平均 |
|---|---|---|---|
| Sonnet 5.5 | 852 / 887 / 929 | 7,932 / 7,804 / 8,538 | 約 110 トークン/秒 |
| Sonnet 5 | 622 / 702 / 737 | 8,165 / 8,712 / 9,486 | 約 78 トークン/秒 |
トークン/秒で見ると Sonnet 5.5 は約 1.4 倍で、公式の「30% 以上速い」と矛盾しない結果でした。ただし Sonnet 5.5 は同じ指示で平均約 3 割長く書いたため、応答が返るまでの時間は平均で 1 割弱しか縮んでいません。duration_api_ms には最初のトークンが出るまでの待ち時間も含まれるため、この値は目安です。
思考トークンと effort
次は、ツールを禁止した状態で計算問題を解かせました（1〜1000 のうち、桁の和が素数で 7 の倍数でない整数の個数。正解は Python で数えて 290）。
claude -p --model claude-sonnet-5-5 --effort high \
--disallowedTools "Bash,Write,Edit,Read,Glob,Grep,WebSearch,WebFetch,Agent" \
--output-format json "1以上1000以下の整数のうち、…最後の行に数値だけを書いてください。"
effort high で 3 回ずつ実行した結果です。
| モデル | 思考トークン（3 回） | 出力トークン（3 回） | API 時間の平均 | 回答 |
|---|---|---|---|---|
| Sonnet 5.5 | 1,785 / 1,589 / 1,536 | 2,102 / 2,029 / 1,748 | 約 12.8 秒 | 3 回とも 290 |
| Sonnet 5 | 8,504 / 8,526 / 9,002 | 8,854 / 8,593 / 9,466 | 約 64.2 秒 | 3 回とも 290 |
同じ正解に対して、Sonnet 5.5 の思考トークンは Sonnet 5 の約 5 分の 1、所要時間も約 5 分の 1 でした。出力単価（$10/MTok）は同じなので、この問題に限れば出力側の費用も同じ比率で下がります。公式発表の「トークンやツール呼び出しが減るのでタスクあたりのコストが下がる」という説明と同じ傾向です。
Sonnet 5.5 で effort だけを変えた結果（各 1 回）は次のとおりです。
| effort | 思考トークン | API 時間 | 回答 |
|---|---|---|---|
low |
1,761 | 13.4 秒 | 290 |
medium |
1,550 | 9.8 秒 | 290 |
high |
1,785 | 13.3 秒 | 290 |
xhigh |
2,474 | 17.5 秒 | 290 |
low から high まではほぼ同じ量で、xhigh で増えました。effort は「考えてよい量の上限の目安」で、問題が易しければ low でも high でも同じくらいしか考えないと読めます。1 回ずつの計測なのでばらつきは大きいはずですが、公式ドキュメントが「effort は測り直す」と勧める理由は、この表からも見て取れます。
いずれの計測も Claude Code 経由のため、Claude Code のシステムプロンプトとツール定義が入力に含まれています。Messages API を直接呼んだときの値とは一致しません。モデル間の比較は同じ条件で行っています。
移行で 400 エラーになる 5 つの変更点
公式の What's new ページが挙げている破壊的変更は次の 5 つです。どの変更がどのコードに当たるかを先に図で整理します。
1. thinking の disabled が使えない
Sonnet 5 では thinking: {"type": "disabled"} で思考をオフにできましたが、Sonnet 5.5 では 400 invalid_request_error になります。公式ドキュメントに載っているエラーメッセージは次のとおりです。
"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 でもっとも思考量の少ない設定で、最初の応答前の思考（up-front thinking）を止めます。ベータヘッダーは不要です。
client.messages.create(
model="claude-sonnet-5-5",
max_tokens=16000,
thinking={"type": "between_tools"},
output_config={"effort": "high"},
messages=[{"role": "user", "content": "..."}],
)
between_tools には制約がいくつかあります。
- effort が
low/medium/highのときだけ使えます。xhigh/maxと組み合わせると 400 エラーになります -
display/budget_tokens/block_bindingを一緒に送ると 400 エラーになります - 会話の途中で effort を変えられません。ターンごとに effort を変えたいときは adaptive thinking を使います
- ツールを使わないリクエストでは、応答はテキストだけになります（Sonnet 5 の
disabledと同じ見え方です）
budget_tokens を指定する手動の思考予算（{"type": "enabled", "budget_tokens": N}）も 400 エラーです。また、between_tools を型定義に持たない古い SDK では Python と TypeScript の例が型チェックで失敗するため、SDK の更新が必要です。
実際に SDK をインストールして、どのバージョンから対応しているかを確かめました。
| SDK |
claude-sonnet-5-5 と between_tools の型定義 |
|---|---|
Python anthropic 1.9.0 |
あり |
Python anthropic 1.8.0 |
なし |
TypeScript @anthropic-ai/sdk 0.129.0 |
あり |
TypeScript @anthropic-ai/sdk 0.128.0 |
なし |
上のコード例を mypy で型チェックすると、1.9.0 では Success: no issues found in 1 source file で通り、1.8.0 では次のエラーになりました。
sample.py:7: error: No overload variant of "create" of "Messages" matches argument types "str", "int", "dict[str, str]", "dict[str, str]", "list[dict[str, str]]" [call-overload]
1.8.0 の型定義では thinking が ThinkingConfigEnabledParam | ThinkingConfigDisabledParam | ThinkingConfigAdaptiveParam の 3 択で、between_tools がありません。1.9.0 では ThinkingConfigBetweenToolsParam（type: Literal['between_tools'] のみを持つ型）が加わっています。なお、1.9.0 でも ToolChoiceAnyParam と ToolChoiceToolParam は型として残っているため、強制ツール呼び出しは型チェックでは検出できず、実行時の 400 エラーで初めて分かります。
2. 強制ツール呼び出し（forced tool use）が使えない
tool_choice に {"type": "any"} または {"type": "tool", "name": "..."} を指定すると、次のエラーが返ります。トークンカウント API でも同じチェックがかかります。
tool_choice: type "tool" and "any" are not supported for this model.
使えるのは auto（既定）と none だけです。「スキーマどおりの入力でツールを呼ばせたい」という目的には、auto のまま strict tool use を組み合わせます。
client.messages.create(
model="claude-sonnet-5-5",
max_tokens=1024,
# strict tool use: every call matches the tool's input_schema
tools=[{**tool, "strict": True} for tool in tools],
tool_choice={"type": "auto"},
messages=[
{
"role": "user",
"content": "What's the weather in Paris? Use the get_weather tool.",
}
],
)
auto ではモデルがテキストで答える可能性が残るため、公式ドキュメントは「どのツールをいつ使うかをプロンプトに書く」ことを勧めています。ツールを経由した構造化抽出が目的なら、structured outputs へ移す選択肢もあります。
移行ガイドによると、Amazon Bedrock では Claude Sonnet 5.5 で structured outputs（strict tool use を含む）を使えません。Bedrock の場合は
autoのまま、ツールを使う場面をプロンプトで指示し、ツール入力をコード側で検証します。
3. thinking ブロックがモデルと会話に紐づく
Sonnet 5.5 の thinking ブロックは、生成したモデルと会話の内容に紐づきます。影響は 3 つあります。
1 つ目はモデル間の読み書きです。Sonnet 5.5 は Sonnet 5・Opus 4.8・Haiku 4.5 などの thinking ブロックを読めますが、Opus 5 / Opus 5.5 / Fable / Mythos 系のブロックは読めません。逆に、Sonnet 5.5 のブロックを読めるモデルは他にありません。読めないブロックは API が黙って捨てるため、リクエスト自体は成功し、捨てたブロックは課金されません。
2 つ目は履歴の改変チェックです。system プロンプト、tools、それより前のメッセージを書き換えたうえで Sonnet 5.5 の thinking ブロックを送り直すと、400 エラーになります。このチェックは 2026 年 8 月 31 日 00:00 UTC 以降に作られたアカウントで既定で有効です（Claude API・Amazon Bedrock・Google Cloud）。
3 つ目はアカウントとの紐づけです。Sonnet 5.5 の thinking ブロックは、生成したアカウント（または紐づいたアカウント）でしか使えません。
対策は、会話を「追記のみ」で扱うことです。途中で指示やツールを変えたいときは、履歴を編集せず mid-conversation system messages で追加します。改変したときにエラーではなくブロックを捨てさせたい場合は、thinking-binding-controls-2026-08-01 ベータヘッダーを付け、thinking.block_binding.prefix_mismatch_behavior を "drop_block" にします（adaptive thinking のときだけ使えます）。
4. computer_20251124 が Claude API と Google Cloud で使えない
Claude API と Google Cloud では、computer use は computer_toolset_20260801 ツールセット経由でしか使えません。旧ツールを宣言すると、次のように始まるエラーになります。
'claude-sonnet-5-5' does not support tool types: computer_20251124.
Amazon Bedrock では旧ツールも引き続き受け付けます。移行ではベータヘッダーを外し、tools の要素を {"type": "computer_toolset_20260801"} に置き換えたうえで、エージェントループ側をツールセットの形式（メンバーの tool_use ブロック、バッチアクション、結果の toolset_name）に合わせます。
5. advisor tool の組み合わせ制限
advisor tool（ベータ）で Sonnet 5.5 を実行役にする場合、アドバイザーに指定できるのは 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 エラーになります。
また、Sonnet 5.5 が受け付けるアドバイザーの助言はすべて advisor_redacted_result として暗号化されて返るため、クライアント側で助言の本文は読めません。
エラーにならないが挙動が変わる点
リクエストは成功するのに、見え方が変わる変更もあります。
ツール呼び出しの合間にモデルが書く説明のうち、1〜2 文より長いものは text ではなく「進捗更新」の thinking ブロックとして返ります。既定の display: "omitted" ではこのブロックの本文は空です。そのため、ツール呼び出しの合間の説明をユーザーに見せているアプリは、エラーも出ないまま無言になります。
adaptive thinking を使っているなら thinking に display: "summarized" を指定すると要約が読めるようになります。移行ガイドには、thinking-display-updates-2026-08-18 ベータヘッダーと display: "updates" で進捗更新だけを受け取る方法も載っています。between_tools の場合は display を指定しなくても本文が返ります。
もう 1 つは、拒否（refusal）の分類です。Sonnet 5.5 の安全機構が応答を断ると、HTTP 200 で stop_reason: "refusal" と stop_details が返ります。分類は cyber / bio / frontier_llm / reasoning_extraction / general_harms の 5 種類です。reasoning_extraction は、内部の推論を応答本文に書き出させようとするリクエストに付く分類です。
Sonnet 5 からの移行チェックリスト
公式の What's new ページにある「確認すべき 6 項目」を、コードで探す場所と合わせて並べます。
| # | 確認項目 | コードで探すもの |
|---|---|---|
| 1 | thinking を disabled にしていたら between_tools へ（effort は high 以下） |
"disabled" |
| 2 |
tool_choice の any / tool を auto と strict tool use へ |
tool_choice |
| 3 | 会話履歴を追記のみにする | 履歴を編集・要約して再送している箇所 |
| 4 | Claude API / Google Cloud で computer_20251124 を使っていたらツールセットへ |
computer_20251124 |
| 5 | advisor に Opus 4.8 / 4.7 / Sonnet 5 を指定していたら変更 | advisor tool の設定 |
| 6 | ツール呼び出しの合間の説明を表示しているなら thinking.display を設定 |
ストリーミング表示の処理 |
あわせて、temperature / top_p / top_k を既定値以外にすると 400 エラーになる点も公式ドキュメントに記載があります。サンプリングパラメータを渡しているコードがあれば外しておきます。
Claude Code を使っている場合は、同梱の Claude API スキルで移行を自動化できると移行ガイドに書かれています。
/claude-api migrate this project to claude-sonnet-5-5
このスキルはモデル ID の置き換えに加え、必要に応じてパラメータの変更や effort の調整まで行い、手で確認すべき項目の一覧を出します。ファイルを編集する前に対象範囲（作業ディレクトリ全体・サブディレクトリ・ファイル指定）を確認してくる仕様です。なお、Claude Managed Agents を使っている場合は、モデル名の更新以外に変更は不要とされています。
Sonnet 5.5 で追加された機能
What's new ページが Sonnet 5.5 で使える機能として挙げているものです。上の 4 行は Sonnet 5 では使えないと明記されています。下の 2 行（ベータ）は、Sonnet 5 で使えるかどうかがこのページには書かれていません。
| 機能 | 概要 |
|---|---|
| per-message effort（ベータ） | メッセージ単位で effort を変える |
| mid-conversation system messages | 会話の途中で指示を追加する（履歴を編集しない） |
| mid-conversation tool changes（ベータ） | 会話の途中でツールを追加・変更する |
| プロンプトキャッシュの最小長 | 512 トークン（Sonnet 5 は 1,024 トークン） |
| Compact on demand（ベータ） |
compact-2026-09-04 ヘッダーで、会話全体を署名付きの要約ブロックに圧縮する |
| Define tools in a message（ベータ） |
inline-tools-2026-09-15 ヘッダーで、ツール定義を会話の途中に置き、キャッシュを失わずにツールを追加・変更する |
mid-conversation system messages は、3 番目の破壊的変更（履歴改変のチェック）への対策としても使えます。
まとめ
Claude Sonnet 5.5 は、価格を Sonnet 5 に据え置いたまま、公式ベンチマークの多くで Sonnet 5 を上回り、一部では Opus 5.5 に並ぶ数値を出しています。タスクあたりのコストは最大 30% 下がると公式発表は説明しています。
移行はモデル ID の差し替えだけでは完了しません。thinking の disabled、tool_choice の any / tool、会話履歴の書き換えを使っているコードは、切り替えた瞬間に 400 エラーになる可能性があります。まず上のチェックリストの 1〜3 番をコードから探し、そのうえで effort を測り直すのが安全な順序です。
関連記事
- Claude Opus 5.5 リリース、Opus 5 からの移行で400エラーになる4つの破壊的変更と対処コード
- Claude Sonnet 5に切り替えて分かった、Opus 4.8との実力差とコスト差
- Claude API 1Mコンテキストベータ廃止ガイド — 4/30期限の移行チェックリスト