はじめに
対象読者は、Claude API（Messages API）や Claude Code を業務で使っていて、Opus 5 や Sonnet 5 から Claude Opus 5.5 への切り替えを検討している開発者です。
Anthropic は 2026年9月22日に Claude Opus 5.5 をリリースしました（Introducing Claude Opus 5.5）。価格は Opus 5 から下がり、ベンチマークでは上位モデルの Claude Fable 5.1 を上回る項目が多い一方で、Opus 5 で動いていたコードがそのまま 400 エラーになる破壊的変更が4つ あります。
この記事では、発表内容を一次情報に沿って整理したうえで、移行時に必ず踏む4つの破壊的変更について Before / After のコードを示します。あわせて、コードベースから該当箇所を洗い出す小さなチェックスクリプトを作り、実際に動かした結果も載せます。
何が発表されたか
公式発表と開発者ドキュメント（What's new in Claude Opus 5.5）で確認できる事実は次のとおりです。
| 項目 | 内容 |
|---|---|
| リリース日 | 2026年9月22日 |
| API のモデル ID |
claude-opus-5-5（日付サフィックスなし） |
| 価格（100万トークンあたり） | 入力 $4 / 出力 $20（Opus 5 は $5 / $25） |
| キャッシュ | 読み込み $0.20、5分キャッシュ書き込み $5、1時間キャッシュ書き込み $8 |
| Batch | 入力 $2 / 出力 $10（半額） |
| コンテキスト | 1M トークン、最大出力 128k トークン（Opus 5 と同じ） |
| 提供先 | Claude API、Amazon Bedrock（anthropic.claude-opus-5-5）、Claude Platform on AWS、Google Cloud、Microsoft Foundry |
公式発表では、典型的なワークロードで Opus 5 より約40%安く動く、出力の生成が 30%以上速い と説明されています。後続として Claude Sonnet 5.5 と Claude Haiku 5.5 が今後数週間のうちに出る予定です。
ベンチマーク（公式発表の数値から抜粋）
| ベンチマーク | Opus 5.5 | Fable 5.1 | Opus 5 |
|---|---|---|---|
| Terminal-Bench 4.0 | 66.4% | 55.8% | 52.3% |
| FrontierCode v1.1 | 54.4% | 50.3% | 48.0% |
| CursorBench 4.0 | 57.8% | 51.8% | 46.6% |
| OSWorld 2.0 | 81.8% | 80.7% | 74.0% |
| Humanity's Last Exam | 67.7% | 65.6% | 63.6% |
公式発表の注記によると、多くのスコアは adaptive thinking の max effort で測定されており、Terminal-Bench 4.0 のみ Opus 5.5 を xhigh effort で測定しています。エージェント型コーディングとコンピュータ操作の伸びが大きく、Fable 5.1 と同等以上の性能を Opus の価格帯で使えることが今回の最大のポイントです。
挙動の変化
コードを変えなくても表れる違いとして、ドキュメントには次の点が挙がっています。
-
effort の既定値が
mediumに変わりました。Opus 5 の既定はhighだったため、effortを省略しているリクエストは思考が浅くなります - 同じ effort でも Opus 5 より1ターンあたりの思考量が増える傾向があります（特に
xhighとmax） - ツール呼び出しの合間のテキストが
textブロックではなくthinkingブロックで返ります - 安全分類器に生物学の分類が加わり、内部推論の再現を求めるリクエストは
reasoning_extractionカテゴリで拒否されることがあります - 密なチャートや図、スクリーンショットの読み取り精度が上がりました
また公式発表では、応答の書き方も変わったと説明されています。専門用語を控え、重要な情報をメッセージの冒頭に置く書き方になりました。
移行で400エラーになる4つの破壊的変更
移行ガイド（Migrating to Claude Opus 5.5）が挙げる破壊的変更は4つです。4つ目は Claude API と Google Cloud に限った変更です。
1. thinking を無効化できない
Opus 5 では effort が high 以下なら thinking: {"type": "disabled"} を指定できました。Opus 5.5 では thinking は常に有効で、無効化の指定も budget_tokens による予算指定も 400 invalid_request_error になります。ドキュメントに記載されているエラーメッセージは次のとおりです。
"thinking.type.disabled" is not supported for this model. Use "thinking.type.adaptive" and "output_config.effort" to control thinking behavior.
対処は、thinking フィールドを削除して effort で深さを調整することです。トークン節約のために thinking を切っていた箇所は、低い effort に置き換えます。
# Before（Opus 5 では受理、Opus 5.5 では 400）
client.messages.create(
model="claude-opus-5",
max_tokens=16000,
thinking={"type": "disabled"},
messages=[{"role": "user", "content": "..."}],
)
# After
client.messages.create(
model="claude-opus-5-5",
max_tokens=16000,
output_config={"effort": "low"}, # thinking は常に有効で、深さは effort で決める
messages=[{"role": "user", "content": "..."}],
)
応答の先頭に thinking ブロックが来るようになるため、content[0] のように位置で取り出しているコードは type で選ぶ形に直す必要があります。ツール利用のループでは、thinking ブロックを改変せずにそのまま返します。
2. 強制ツール呼び出し（forced tool use）が使えない
tool_choice に {"type": "any"} や {"type": "tool", "name": "..."} を指定すると 400 になります。トークンカウントのエンドポイントにも同じ検証がかかります。
tool_choice: type "tool" and "any" are not supported for this model.
使えるのは auto（既定）と none だけです。スキーマどおりの JSON が欲しい場合は、auto のまま strict tool use を有効にするか、structured outputs に移します。特定のツールを使わせたい場合は、そのことをプロンプトに書きます。
# Before
client.messages.create(
model="claude-opus-5",
max_tokens=1024,
tools=tools,
tool_choice={"type": "tool", "name": "get_weather"},
messages=[{"role": "user", "content": "What's the weather in Paris?"}],
)
# After
client.messages.create(
model="claude-opus-5-5",
max_tokens=1024,
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.",
}
],
)
構造化抽出のために forced tool use を使っていた実装は多いので、4つの中で修正範囲が最も広くなりやすい変更です。
3. thinking ブロックがモデルと会話に紐づく
thinking ブロックには、それを生成したモデルが記録されます。Opus 5.5 は Opus 5 以前の Opus・Sonnet・Haiku の thinking ブロックを読めますが、Fable や Mythos のものは読めません。逆に、Opus 5.5 の thinking ブロックを読めるのは Claude API 上の Fable 5.1 と Mythos 5.1 だけです。読めないブロックは API が落としてから処理するため、リクエスト自体は失敗しません。
400 になるのは次のケースです。2026年8月31日 00:00 UTC 以降に作成されたアカウント では、thinking ブロックより前の system プロンプト・tools・過去のメッセージを会話の途中で書き換え、そのブロックを再送すると 400 になります。
対処は、会話を追記のみ（append-only）で扱うことです。指示やツールを途中で変えたいときは、既存部分を書き換えずに mid-conversation system messages を使います。Claude Code・claude.ai・Claude Managed Agents・Claude Agent SDK はすでに append-only で動いているため、これらの上で動かす場合は対応不要です。ルーターやフォールバックで途中からモデルを切り替える構成の場合は、切り替え後のターンが Opus 5.5 の推論を引き継げない点に注意が必要です。
4. computer_20251124 が Claude API と Google Cloud で使えない
コンピュータ操作で旧来の computer_20251124 ツールを宣言すると、Claude API と Google Cloud では 400 になります。移行先は computer_toolset_20260801 で、beta ヘッダーも名前も画面サイズも不要です。
# Before
client.beta.messages.create(
model="claude-opus-5",
max_tokens=4096,
betas=["computer-use-2025-11-24"],
tools=[{
"type": "computer_20251124",
"name": "computer",
"display_width_px": 1024,
"display_height_px": 768,
}],
messages=[{"role": "user", "content": "Open the display settings."}],
)
# After
client.messages.create(
model="claude-opus-5-5",
max_tokens=4096,
tools=[{"type": "computer_toolset_20260801"}],
messages=[{"role": "user", "content": "Open the display settings."}],
)
エージェントループ側も変更が必要です。操作の種類は input.action ではなく tool_use ブロックの name に入り、1ターンに複数の tool_use が返り、結果には毎回 toolset_name を付けて返します。Amazon Bedrock では従来の computer_20251124 がそのまま動きます。browser use tool を使っている場合は変更不要です。
400にはならないが見落としやすい変更
ツール呼び出しの合間に Claude が書く短い進捗メモは、Opus 5.5 では thinking ブロックとして返ります。既定の display: "omitted" では中身が空なので、進捗をユーザーに流している UI はエラーなしで静かになります。
進捗を表示し続けたい場合は、thinking.display を "updates"（beta・thinking-display-updates-2026-08-18 ヘッダー）か "summarized" に設定します。前者は推論を隠したまま進捗だけを返し、後者は両方を混ぜて返します。そのうえで、空でない thinking ブロックを直後の tool_use の前に描画します。
もう1つは effort の既定値です。effort を省略している呼び出しは high から medium に下がるため、移行ガイドは effort を明示したうえで、改めて effort ごとの比較（effort sweep）をやり直すことを推奨しています。
手元のコードから該当箇所を洗い出す
ここからは実際に手を動かした内容です。
SDK が新モデル ID を収録しているか
2026年9月23日（JST）の時点で、公開されている SDK の最新版を取得し、モデル ID が型定義に含まれているかを確認しました。
$ npm view @anthropic-ai/sdk version time.modified
version = '0.128.0'
time.modified = '2026-09-22T16:38:57.862Z'
$ pip download anthropic --no-deps -d py
$ ls py
anthropic-1.8.0-py3-none-any.whl
$ grep -rn '"claude-opus-5-5"' py/w/anthropic/types/model.py
py/w/anthropic/types/model.py:9: "claude-opus-5-5",
Python SDK 1.8.0 と TypeScript SDK 0.128.0 のどちらにも claude-opus-5-5 が入っていました。型補完でモデル ID を選んでいるプロジェクトは、SDK を上げるとこの ID を選べるようになります。なお、thinking の無効化や forced tool use を拒否するのはサーバー側です。SDK の型はこれらの指定を通してしまうため、型チェックが通っても実行時に 400 になる可能性があります。
破壊的変更のパターンを検出するスクリプト
型チェックでは見つからないので、正規表現で該当箇所を洗い出すスクリプトを作りました。対象は4つの破壊的変更のうちコードの字面で判定できる3つと、モデル ID の残りです。
import re, sys, pathlib
RULES = [
(r'thinking\s*[=:]\s*\{[^}]*"type"\s*:\s*"disabled"', "thinking disabled は 400。thinking を削除し output_config.effort で調整"),
(r'"type"\s*:\s*"enabled"\s*,\s*"budget_tokens"', "budget_tokens 指定は 400。effort へ置き換え"),
(r'tool_choice\s*[=:]\s*\{\s*"type"\s*:\s*"(any|tool)"', "tool_choice any/tool は 400。auto + strict tool use へ"),
(r'computer_20251124', "Claude API / Google Cloud では 400。computer_toolset_20260801 へ"),
(r'"claude-opus-5"(?!-)', "モデル ID を claude-opus-5-5 へ（effort 既定は medium に変わる）"),
]
hits = 0
for path in sys.argv[1:]:
for no, line in enumerate(pathlib.Path(path).read_text().splitlines(), 1):
for pat, msg in RULES:
if re.search(pat, line):
hits += 1
print(f"{path}:{no}: {msg}")
print(f"-- {hits} 件")
sys.exit(1 if hits else 0)
Opus 5 向けに書いた次のサンプルに対して実行しました。
import anthropic
client = anthropic.Anthropic()
resp = client.messages.create(
model="claude-opus-5",
max_tokens=16000,
thinking={"type": "disabled"},
tools=tools,
tool_choice={"type": "tool", "name": "get_weather"},
messages=[{"role": "user", "content": "..."}],
)
$ python3 check_opus55.py sample/app.py; echo "exit=$?"
sample/app.py:4: モデル ID を claude-opus-5-5 へ（effort 既定は medium に変わる）
sample/app.py:6: thinking disabled は 400。thinking を削除し output_config.effort で調整
sample/app.py:8: tool_choice any/tool は 400。auto + strict tool use へ
-- 3 件
exit=1
該当があると終了コード 1 で終わるため、CI に組み込めば移行漏れを防げます。ただし行単位の正規表現なので、複数行にまたがる辞書や変数経由の指定は拾えません。あくまで一次スクリーニング用で、最終確認は実際に API を呼んで 400 が出ないことを見る必要があります（本記事では API キーを使った呼び出しまでは行っていません）。
Claude Code の移行コマンドを使う
移行ガイドは、Claude Code に同梱されている Claude API スキルを使った自動移行も案内しています。
/claude-api migrate this project to claude-opus-5-5
このコマンドは、編集前に移行範囲（作業ディレクトリ全体・サブディレクトリ・ファイル指定）の確認を求めます。そのうえでモデル ID の置き換え、破壊的なパラメータ変更、prefill の置き換え、effort の調整を行い、手動で確認すべき項目のチェックリストを出力します。上のスクリプトで範囲を把握してからこのコマンドで直す、という使い分けができます。
Claude Code で使う
Claude Code では /model で Opus 5.5 に切り替えます。Anthropic の解説記事（Getting the most out of Opus 5.5 in Claude and Claude Code）によると、思考量は effort で調整します。やり取りの多い作業では /fast で fast mode に切り替えられます。fast mode はリサーチプレビューの扱いで、追加の従量課金（extra usage）を有効にする必要があり、トークン単価も上がります。API で fast mode を使う場合は、Claude API 上でのみ speed: "fast" と fast-mode-2026-02-01 ヘッダーを指定します。公式発表の価格は入力 $8 / 出力 $40 です。
サブスクリプションの利用枠も変わりました。公式発表によると、Pro・Max・Team とシート課金の Enterprise で5時間あたりの利用上限が引き上げられています。さらに、レート制限のリセットを保存しておき、好きなタイミングで使える仕組みが加わりました。
Opus 5 と比べてどう選ぶか
| 観点 | Opus 5 | Opus 5.5 |
|---|---|---|
| 価格（入力 / 出力） | $5 / $25 | $4 / $20 |
| effort の既定 | high |
medium |
| thinking の無効化 |
high 以下で可 |
不可 |
| forced tool use | 可 | 不可（auto / none のみ） |
| コンピュータ操作（Claude API） | 旧ツールと toolset の両方 | toolset のみ |
| ツール間テキスト |
text ブロック |
thinking ブロック |
性能と価格の両面で Opus 5.5 のほうが有利なので、新規の実装で Opus 5 を選ぶ理由はほぼありません。既存の実装は、forced tool use と thinking の無効化に依存しているかどうかで移行コストが大きく変わります。どちらも使っていない、append-only の素直なエージェント実装なら、モデル ID の変更と effort の明示だけで移行できます。
Sonnet 5 と比べてどう選ぶか
Opus 5 より2割安くなったことで、Sonnet 5 から Opus 5.5 への移行を検討する余地が出てきました。ここでは価格・性能・API の差分を一次情報に沿って整理します。
価格と仕様
公式の価格表（Pricing）とモデル比較表（Models overview）から、両モデルを並べます。価格は100万トークンあたりです。
| 項目 | Sonnet 5 | Opus 5.5 | 差 |
|---|---|---|---|
| 入力 | $2 | $4 | 2倍 |
| 出力 | $10 | $20 | 2倍 |
| キャッシュ読み込み | $0.20 | $0.20 | 同額 |
| 5分キャッシュ書き込み | $2.50 | $5 | 2倍 |
| Batch（入力 / 出力） | $1 / $5 | $2 / $10 | 2倍 |
| レイテンシ（公式の相対表記） | Fast | Moderate | Sonnet が速い |
| effort の既定 | high |
medium |
|
| 信頼できる知識の期限 | 2026年1月 | 2026年6月 | Opus が新しい |
| コンテキスト / 最大出力 | 1M / 128k | 1M / 128k | 同じ |
Opus 5 より2割安くなったとはいえ、Sonnet 5 と比べるとトークン単価はまだ2倍です。ただし、キャッシュ読み込みだけは同額です。Opus 5.5 はキャッシュ読み込みが入力単価の 0.05 倍に設定されていて、ほかのモデルの標準（0.1 倍）より割安だからです。両モデルとも Claude Opus 4.7 以降の新しいトークナイザーを使っているため、同じテキストのトークン数は変わりません。
キャッシュ読み込みが多いエージェントループでは、入力の価格差が縮まります。入力5万トークンのうち4万トークンがキャッシュ読み込みで、出力が5千トークンのリクエストを試算しました。
# 100万トークンあたりの単価（USD）: 入力, キャッシュ読み込み, 出力
PRICES = {
"Sonnet 5": (2.0, 0.20, 10.0),
"Opus 5.5": (4.0, 0.20, 20.0),
}
def cost(model, uncached_in, cached_in, out):
p_in, p_cache, p_out = PRICES[model]
return (uncached_in * p_in + cached_in * p_cache + out * p_out) / 1_000_000
for m in PRICES:
print(f"{m}: ${cost(m, 10_000, 40_000, 5_000):.4f}")
ratio = cost("Opus 5.5", 10_000, 40_000, 5_000) / cost("Sonnet 5", 10_000, 40_000, 5_000)
print(f"Opus 5.5 / Sonnet 5 = {ratio:.2f} 倍")
$ python3 cost_compare.py
Sonnet 5: $0.0780
Opus 5.5: $0.1480
Opus 5.5 / Sonnet 5 = 1.90 倍
同じトークン量なら、Opus 5.5 は Sonnet 5 の2倍弱です。出力の単価差がそのまま残るため、1リクエストあたりのコストだけを見れば Sonnet 5 のほうが安くなります。
性能は「解決1件あたりのコスト」で比べる
Opus 5.5 の発表のベンチマーク表には Sonnet 5 が含まれていません。同じ条件で両モデルを比べた公式の数値は、本記事の執筆時点では見つかりませんでした。
判断材料になるのは、公式ガイド Optimizing for cost and intelligence にある実測値です。ただし比較対象は Opus 5.5 ではなく Opus 5 です。
| SWE-bench Pro（コーディング） | 解決率 | 解決1件あたりのコスト |
|---|---|---|
| Sonnet 5（既定の effort） | 77.4% | $0.84 |
Opus 5（effort low） |
84.0% | $0.25 |
| Opus 5（既定の effort） | 91.7% | $1.01 |
トークン単価が Sonnet 5 の2.5倍だった Opus 5 でも、effort を low にすると、解決率は6.6ポイント高く、解決1件あたりのコストは約3割でした。上位モデルは少ない思考と試行で解き切るため、失敗と再実行を含めた総額では逆転することがあります。
一方、調査タスク（DeepResearch Bench II）では、Sonnet 5 がスコア 56%・1タスク $1.20、Opus 5（既定の effort）が 71%・$6.71 でした。精度の差より価格差のほうが大きく、どちらが得かはタスクの種類で変わります。
Opus 5.5 のトークン単価は Opus 5 より2割安く、公式発表では典型的なワークロードで約40%安く動くとされています。上の傾向が続くなら、コーディングでは Sonnet 5 との差がさらに開く可能性があります。ただし、Opus 5.5 は同じ effort でも Opus 5 より思考量が増える傾向があり、Opus 5.5 自体の実測は公開されていません。自分のタスクで測るのが確実です。
Sonnet 5 から移行するときの API 差分
Sonnet 5 で動いていたコードを Opus 5.5 に向けると、次の点が変わります。Sonnet 5 は Opus 5 と API の形がほぼ同じなので、本記事の4つの破壊的変更の多くがそのまま当てはまります。
| 観点 | Sonnet 5 | Opus 5.5 |
|---|---|---|
| thinking の無効化 | どの effort でも可 | 不可（400） |
forced tool use（any / tool） |
可 | 不可（400） |
| effort の既定 | high |
medium |
| mid-conversation system messages | 非対応 | 対応 |
| fast mode | 非対応 | 対応（Claude API のみ） |
コンピュータ操作の旧ツール computer_20251124 は、公式ドキュメントの記述が食い違っています。Sonnet 5 の What's new は「Sonnet 5 でも旧ツールを受理する」と書いています。一方、Computer use tool の対応表では、Sonnet 5 は computer_toolset_20260801 だけに載っています。Opus 5.5 は Claude API と Google Cloud で旧ツールを受け付けないので、どちらの記述が正しくても、移行時に toolset へ書き換えることになります。
もう1つ確認が必要なのが web fetch ツールです。Opus 5 の移行ガイドには「web fetch は Sonnet 5 では使えるが Opus 5 では使えない」とあります。Opus 5.5 での対応状況は、本記事の執筆時点で公式ドキュメント上の明記を確認できませんでした。web fetch に依存している場合は、切り替える前に実際のリクエストで確かめてください。
移行を検討する価値が高いケース
- 長時間のエージェント型コーディング: Sonnet 5 では失敗して再実行になりがちなタスクです。解決1件あたりのコストが下がる可能性が最も高い領域です
- キャッシュ読み込みが入力の大半を占めるループ: 入力側の価格差がほぼ消えます
- 2026年1月以降の知識が要るタスク: 信頼できる知識の期限が5か月新しくなります
逆に、次のケースは Sonnet 5 に残すほうが合理的です。
- レイテンシが重要な対話型の用途
- 大量の定型処理や調査タスクで、Sonnet 5 の精度で足りているもの
- forced tool use や thinking の無効化に広く依存していて、改修コストが大きいもの
公式の選び方ガイド（Choosing the right model）は、多くのワークロードで Opus 5.5 から始めることを勧めています。Sonnet 5 は、日常的なコーディングやエージェントの処理で速さと能力の両方が要る場面に位置づけられています。全部を置き換えるのではなく、難しい判断や長いタスクを Opus 5.5 に、量の多い作業を Sonnet 5 に振り分ける組み合わせ方も、同じガイドで紹介されています。
まとめ
- Claude Opus 5.5 は、入力 $4 / 出力 $20 と Opus 5 より2割安くなりました。エージェント型コーディングとコンピュータ操作では Fable 5.1 を上回るスコアが出ています
- Opus 5 からの移行では、thinking の無効化、forced tool use、会話途中の編集、
computer_20251124の4つが 400 エラーの原因になります - エラーにはならないものの、effort の既定値が
mediumに下がる点と、ツール間の進捗テキストが見えなくなる点は、見落とすと品質低下や UI の沈黙につながります - 移行作業では、正規表現のチェックで該当範囲を把握してから、
/claude-api migrateでの自動修正と実 API での確認に進むのが安全です - Sonnet 5 と比べると、トークン単価は今も2倍です。ただしキャッシュ読み込みは同額で、Opus 5 の公式実測では解決1件あたりのコストが Sonnet 5 を下回るケースがあります。単価ではなく、自分のタスクでの解決1件あたりのコストで比べるのが判断の近道です
Sonnet 5.5 と Haiku 5.5 も今後数週間のうちに出ると公式に予告されているので、同じ破壊的変更が小さいモデルにも及ぶかは、そのリリースで改めて確認が必要です。