# Claude Codeの「opus」が5.5に変わったら：effortとAPIの400を4段階で点検する > 同じopus指定でも解決先がOpus 5.5に変わる。実際のモデルIDとeffortをログで確認し、thinking無効化・強制tool_choiceの400、古いルールを順に点検する。 - Published: 2026年10月2日 - Author: Leo Kaka, Engineering - Tags: models, agents, coding-agents - Canonical: https://pirouter.ai/ja/blog/opus-5-5-ikou-otoshiana --- **Claude Codeで`--model opus`を使い続けているなら、モデルの解決先はOpus 5.5に変わっている可能性がある。** そのとき`claude-opus-5`用のeffort設定は新しいモデルに効かず、Messages APIではthinking無効化とtoolの強制指定が400になる。確認する順番は、**①実際のモデルID、②実際のeffort、③400になる要求、④読み込まれるルール**の四つだ。単にモデル名を書き換えて終わり、ではない。 2026年9月22日のClaude Code v2.1.280で、Anthropic API経由の`opus`エイリアスはOpus 5から**Claude Opus 5.5**に切り替わった。[Model configuration](https://code.claude.com/docs/en/model-config)を10月2日に読み直しても、Anthropic API上の解決先は5.5。一方で本文の実行ログは**9月27日、Claude Code 2.1.283の空ディレクトリで得た10回分**だ。CLIの`modelUsage`とセッションのeffortはそこで確認したが、後から追加された仕様を同じ実験で測ったことにはしない。**APIの400は自分で送信して再現していない**。下のエラー文言は公式ドキュメントから取った。 ## ① 同じ「opus」でも、中身のモデルIDを確かめる 発端となった[日本語の設定監査記録](https://zenn.dev/nanora/articles/20260925-claude-prompt-audit-opus55)では、Raspberry Pi上の`claude -p`に与えるルールがOpus 5を前提としていた。ところが解決先を調べると`opus`は5.5を指していた。文章で「Opus 5を使う」と書いてあっても、実際のCLI設定を止める力はない。エイリアスは便利な入口であり、固定した型番ではない。 Claude Codeの`opus`は利用するプロバイダによっても変わる。現行の[公式モデル設定](https://code.claude.com/docs/en/model-config)では、Anthropic API、Claude Platform on AWS、Amazon Bedrock、Google Cloudでは5.5を指すが、Microsoft FoundryではOpus 4.6を指す。ここで何をしているかは、**自分の作業環境のCLIに尋ねる**のが早い。 ```bash # いまの環境で opus が使った実際のモデルIDを表示する claude -p --model opus --tools "" --output-format json "ok とだけ返して" \ | jq -r '.modelUsage | keys | join(",")' ``` 9月27日、隔離したCLI 2.1.283での出力は`claude-opus-5-5`だった。JSON出力の`modelUsage`を確認する方法は[Claude Codeの公式案内](https://code.claude.com/docs/en/model-config)にもある。ここで普段のリポジトリの実際の設定を知りたいなら、**普段の場所でそのまま実行する**。設定同士の衝突を切り分けたいときだけ、空のディレクトリで`--setting-sources ""`を付けて走らせる。後者はユーザー・プロジェクト設定を外すので、その結果をいつもの環境の答えと取り違えない。 ![「opus」の名札は同じまま、古い「5」の木箱が運び出され、新しい「5.5」の木箱に入れ替わる概念図。](/blog/images/opus-5-5-ikou-otoshiana-comic.png "PiRouter制作の概念イラスト。エイリアス変更の根拠：[Claude Code Model configuration](https://code.claude.com/docs/en/model-config)") ここでAPIの話を混ぜないこと。`claude-opus-5`や`claude-opus-5-5`という**Messages APIのモデルIDは固定スナップショット**で、CLIの`opus`のように自動で新しい版を指すわけではない（[Model IDs and versioning](https://platform.claude.com/docs/en/about-claude/models/model-ids-and-versions)）。ただし固定なのはモデルIDに対応する重み・設定であり、周辺の配信基盤まで未来永劫同じという意味ではない。APIを直接使うコードではフルIDを確認し、ルーターを介するならレスポンスの`model`も確認する。 エイリアスの移動に気付けるようにするには、最初にフルIDを指定するか、チームの`.claude/settings.json`で`opus`の向きを明示する。環境変数の出典は[Model configuration](https://code.claude.com/docs/en/model-config)。以下は**対象キーだけの例**で、既存ファイルを丸ごと置き換える手順ではない。変更前に設定をバックアップし、既存のhooks・env・permissionsを残して対象キーだけ合併する。差分を確認し、チーム共通の`env`が各メンバーのシェルにある同名変数を上書きすることも合意してから反映する。 ```json { "env": { "ANTHROPIC_DEFAULT_OPUS_MODEL": "claude-opus-5-5" } } ``` リポジトリの設定に書けばチームの入口を揃えられる。シェルで同名変数をexportしている人も、プロジェクト設定の`env`がその値を上書きする点に注意する。組織管理者が新しい版を明示的に許可するまで止めたいなら、v2.1.283以降の**managed設定限定**で`availableModelsMatch: "exact"`を使う。一般のユーザー設定やプロジェクト設定に書いても有効にはならない（[Settings reference](https://code.claude.com/docs/en/settings-reference)）。 固定しても、CLIの更新や設定の変更を見落とす可能性は残る。CIでは**期待するフルIDを一回の最小リクエストで確かめ、違えば落とす**という簡単な検査にできる。CIの認証情報はsecretとして渡し、実行するClaude Codeの版も記録する。これは通信するテストなので無料ではない。当方が9月27日に行った単発`claude -p`の費用表示は、一回あたり$0.0006～$0.029のクライアント側推定だった。あなたの実行費用を約束する数字ではない。 ```bash actual=$(claude -p --model opus --tools "" --output-format json "ok とだけ返して" \ | jq -r '.modelUsage | keys | join(",")') test "$actual" = "claude-opus-5-5" || { printf 'unexpected opus model: %s\n' "$actual" >&2 exit 1 } ``` モデルIDを固定するのは変更の**予防**、CIの断言は想定外の変更の**発見**だ。どちらか一方だけで「すべての実行が同じ」と言い切れない。特に複数のプロバイダを使うチームでは、それぞれの入口で同じ検査を実行し、どの設定元が使われたかも一緒に残しておく。 ## ② effortが効かなければ、値より先に「どこに書いたか」を見る Opus 5.5のeffortは`low`、`medium`、`high`、`xhigh`、`max`の五段階で、既定値は**`medium`**。Opus 5の既定`high`から変わった。[公式Effortガイド](https://platform.claude.com/docs/en/build-with-claude/effort)は、同じ段階名をモデル間で同じ思考量と見なさず、仕事ごとに測り直すよう勧める。単価は5.5の通常APIで入力$4、出力$20／100万トークンとOpus 5の$5／$25より低いが、出力や手直しが増えれば完了した仕事の費用は単価どおりには減らない（[Opus 5.5 What's new](https://platform.claude.com/docs/en/models/opus-5-5/whats-new-opus-5-5)）。 落とし穴の一つ目は**モデル別のキー**。`modelSettings`で`"claude-opus-5"`に`high`を書いても、実際のIDが`claude-opus-5-5`なら当たらない。二つ目は**設定ファイルの場所**。現行[Model configuration](https://code.claude.com/docs/en/model-config)では、昔のユーザー設定`~/.claude/settings.json`のtop-level `effortLevel`はOpus 5.5に適用されない。しかし、プロジェクト・ローカル・managedのtop-level、または`--settings`で与える値は適用される。同じ一行でも、保存場所が違えば結果が変わる。 | 9月27日の当方の隔離probe（CLI 2.1.283） | 実モデル | 記録されたeffort | |---|---|---| | `--model opus`、effort指定なし | `claude-opus-5-5` | `medium` | | フルID `claude-opus-5`、指定なし | `claude-opus-5` | `high` | | `--model opus --effort low` | `claude-opus-5-5` | `low` | | `--settings`でtop-level `xhigh` | `claude-opus-5-5` | `xhigh` | | `--settings`で旧ID `claude-opus-5`のみ`high` | `claude-opus-5-5` | `medium` | | `--settings`で正しいID `claude-opus-5-5`を`high` | `claude-opus-5-5` | `high` | この表は**空のディレクトリ、`--setting-sources ""`で既存設定を外し、指定条件だけを`--settings`で渡した再現**。ユーザー設定ファイルのtop-levelを同じ方法で隔離して測ろうとしたときは認証が通らず、結果を得られなかった。「ユーザー設定では効かない」は公式の文書上の事実であって、その失敗した試行を成功した当方の検証に数えていない。[日本語の先行記事](https://zenn.dev/nanora/articles/20260925-claude-prompt-audit-opus55)にある「xhighで動いていた」という見立ても、筆者が実行記録を確かめる前の記述である。異なる設定元が重なった可能性はあるが、どれが原因だったかをこちらで断定はできない。 修正は、実モデルIDの項目に意図した値を書くことから始める。これも設定ファイル全体ではなく**`modelSettings`の対象エントリだけを合併する例**だ。既存ファイルをバックアップし、ほかのモデルやhooks・env・permissionsを消していないことを差分で確認する。 ```json { "modelSettings": { "claude-opus-5": { "effortLevel": "high" }, "claude-opus-5-5": { "effortLevel": "high" } } } ``` 二つを同じ`high`にすべきという推奨ではなく、**それぞれを別に設定できる**例だ。設定の優先順位は、該当モデルに適用可能な値がある**最高優先度の設定元**が勝つ。`CLAUDE_CODE_EFFORT_LEVEL`は`--effort`や設定ファイルより強いが、管理者の`maxEffortLevel`はその値にも上限をかける（[Settings reference](https://code.claude.com/docs/en/settings-reference)）。対話で`/effort`を使うか、CLI起動時に`--effort`を渡すかも含め、**実際に動いた段階**は次節の記録で答え合わせする。 **10月2日の追記：ultracodeは以前の説明のまま使わない。** 9月27日の旧版では`xhigh`と結びつける説明だったが、[v2.1.284の変更](https://code.claude.com/docs/en/changelog)後、`/effort ultracode on`と`"ultracode": true`は仕事の進め方を選ぶトグルで、**現在のeffortを自動的に`xhigh`にはしない**。一方、`--effort ultracode`は有効化と`xhigh`指定を同時に行う。上限の設定はなお適用される（[現行Model configuration](https://code.claude.com/docs/en/model-config)）。この変更は旧probeで測ったものではない。 ### 動いたeffortはセッションのjsonlで答え合わせする Claude CodeのJSON結果にはモデルの`modelUsage`があるが、effortが見えない場合、**セッション記録**を見る。既存の記録ならプロジェクトのディレクトリを指定して集計できる。例の`-Users-me-src-app`は自分のパスに合わせて替えること（[Sessions](https://code.claude.com/docs/en/sessions)）。 ```bash # 既存のセッションに記録されたeffortを数える rg -o '"effort":"(low|medium|high|xhigh|max)"' \ ~/.claude/projects/-Users-me-src-app/*.jsonl | sort | uniq -c ``` 新しい検証呼び出しなら、最新ファイルを時刻だけで探すのではなく、出力された`session_id`を使う。並列セッションを他人の結果と取り違えないためだ。 ```bash # 一回だけ実行し、そのセッションと子エージェントの記録を探す sid=$(claude -p --model opus --tools "" --output-format json "ok とだけ返して" \ | jq -r '.session_id') f=$(find ~/.claude/projects -name "$sid.jsonl" -print -quit) test -n "$f" || { printf 'session transcript not found\n' >&2; exit 1; } rg -o '"effort":"(low|medium|high|xhigh|max)"' "$f" | sort | uniq -c if test -d "${f%.jsonl}"/subagents; then find "${f%.jsonl}"/subagents -name '*.jsonl' -exec \ rg -o '"effort":"(low|medium|high|xhigh|max)"' {} + | sort | uniq -c fi ``` 最後の`find`は子エージェントを呼んだときだけ意味がある。子の記録は[公式Subagents](https://code.claude.com/docs/en/sub-agents)どおり親とは別の`/subagents/agent-*.jsonl`だ。9月27日に`--agents`の子を一回呼ばせた条件では親`medium`、子`low`を別々に確認した。[元の日本語記事](https://zenn.dev/nanora/articles/20260925-claude-prompt-audit-opus55)には子へのeffort指定が効かないという観察もあるが、版や確認した記録の違いをこの一回から特定できない。フロントマターで定義する子のeffortは公式に会話側を上書きする一方、当方はその**ファイル版**を実測していない。 Messages APIを直接呼ぶ人は、CLIの`opus`やjsonl探索は不要。自分が送った`output_config.effort`を確認し、レスポンスの`model`とトークン使用量を読む。レスポンスのモデルを確認するのは、特に途中にルーターやゲートウェイが入る構成で有効だ。APIの測定を、このCLI probeで済ませたことにはしない。 ## ③ thinking無効化の400は、effortを下げても直らない ここから先は**Messages APIのリクエスト形**。Opus 5で`high`以下なら通った`"thinking":{"type":"disabled"}`をOpus 5.5に送ると、公式の[What's new](https://platform.claude.com/docs/en/models/opus-5-5/whats-new-opus-5-5)によれば次の400 `invalid_request_error`になる。 ```text "thinking.type.disabled" is not supported for this model. Use "thinking.type.adaptive" and "output_config.effort" to control thinking behavior. ``` `low`に下げてもthinkingを無効にはできない。`thinking`を**省略**するか`{"type":"adaptive"}`にし、考える深さと全体の出力量は`output_config.effort`で調節する。例えばこうだ。 ```json { "model": "claude-opus-5-5", "max_tokens": 16000, "output_config": { "effort": "low" } } ``` 手動の`budget_tokens`を付けた`thinking.type.enabled`も400になる。ただし**Opus 5から5.5に移った日に初めて壊れた形ではない**。公式移行ガイドによると、固定budgetはOpus 4.7以降に受け付けられなくなった。[Claude Codeの環境変数](https://code.claude.com/docs/en/env-vars)でも、`MAX_THINKING_TOKENS=0`で5.5のthinkingは切れない。文書化された変数名は`MAX_THINKING_TOKENS`であり、`CLAUDE_CODE_MAX_THINKING_TOKENS`のように接頭辞を付けた別名を公式の現行設定だとは扱わない。 ![壁のthinkingスイッチにはOFFがなく、lowからmaxまでのダイヤルだけが残る概念図。](/blog/images/opus-5-5-ikou-otoshiana-comic-thinking.png "PiRouter制作の概念イラスト。thinking設定の根拠：[Opus 5.5 What's new](https://platform.claude.com/docs/en/models/opus-5-5/whats-new-opus-5-5)") リクエストが通っても、レスポンスの読み方を直さないと別の障害になる。先頭がthinkingブロックで、そのテキストは既定の`display: "omitted"`では空かもしれない。`content[0].text`という位置決め打ちはやめ、`type`で本文を選ぶ。 ```python text = "".join(block.text for block in response.content if block.type == "text") ``` tool呼び出しを続けるループではthinkingブロックを**受け取ったまま**履歴に戻す。途中の履歴やtool定義を勝手に書き換えると、保存されたthinkingとの整合性チェックに失敗し、新しいアカウントで400になる条件もある（[Opus 5.5の変更点](https://platform.claude.com/docs/en/models/opus-5-5/whats-new-opus-5-5)）。また`max_tokens`は本文だけでなくthinkingも含む。以前の「thinkingなしで短く返る」前提の低い上限なら、回答が途中で切れる。高いeffortで長い作業をさせるときは上限とストリーミングを別途確認する。 ### tool_choiceの強制も400：JSONの保証とは分ける 次はtool指定。Opus 5.5では`tool_choice`を`{"type":"any"}`または`{"type":"tool","name":"..."}`にすると、[公式ドキュメント](https://platform.claude.com/docs/en/models/opus-5-5/whats-new-opus-5-5)のエラーはこうなる。 ```text tool_choice: type "tool" and "any" are not supported for this model. ``` `auto`と`none`は有効。同じ検証は**token counting endpoint**、つまり実行前に入力トークン数を数えるAPIにも適用される。移行前の見積もり呼び出しだけが400になる場合も、そのリクエストの`tool_choice`を調べる。 ここは直したい目的で道が分かれる。**toolの引数を指定のJSON形にしたい**なら`auto`とtool定義の`strict: true`を使う。スキーマ中のすべてのobjectに`additionalProperties: false`が必要だ（[Strict tool use](https://platform.claude.com/docs/en/agents-and-tools/tool-use/strict-tool-use)）。**最終回答をJSON形にしたい**ならstructured outputsを検討する。一方、`auto`は「必ずtoolを呼ぶ」の保証ではない。必要な条件をプロンプトに書き、実際のレスポンスに`tool_use`があるか確認する。 ```json { "tool_choice": { "type": "auto" }, "tools": [{ "name": "get_weather", "strict": true, "input_schema": { "type": "object", "properties": { "location": { "type": "string" } }, "required": ["location"], "additionalProperties": false } }] } ``` APIを叩く前にソースを探しておく。`rg -n`で行を丸ごと出すと、同じ行にAPIキーがあった場合にターミナル記録やCIログへ漏れる。まずは**ファイル名だけ**を列挙する。`tool_choice`は正常な`auto`も見つけるので、該当ファイルを権限のある手元で確認し、秘密情報を含む元の行をCIログやチケットへ貼らない。以下は**静的な候補探し**で、エラー確定でも完全な移行テストでもない。 ```bash rg -l -e 'budget_tokens' -e '"type":\s*"(disabled|any|tool)"' -e 'tool_choice' . ``` もし送信前のリクエスト本文を**一行一JSONの`requests.jsonl`として安全に保存している場合だけ**、候補の形を数えられる。通常の`thinking.type.enabled`を単独では数えない。対象は`disabled`、**`enabled`かつ`budget_tokens`あり**、または強制`tool_choice`の`any`／`tool`だ。入力ログ自体は秘密情報を含み得るため権限のある環境だけで扱い、下記の出力も送信前の**候補**であって実際に400が確定した件数ではない。 ```bash jq -c 'select(.thinking.type == "disabled" or (.thinking.type == "enabled" and .thinking.budget_tokens != null) or .tool_choice.type == "any" or .tool_choice.type == "tool") | {thinking: .thinking.type, tool_choice: .tool_choice.type}' requests.jsonl \ | sort | uniq -c ``` 送信が成功しても既定effortは`medium`に変わり、tool間の進捗文は既定表示では空のthinkingブロックになる。進捗を人に見せるアプリは別途`thinking.display: "updates"`の対応を確認する。古い`computer_20251124`もClaude APIとGoogle Cloudでは400だがBedrockでは継続できる。いずれも同じ「400」と呼んで一律に直さず、使っている入口の公式条件を見る（[What's new](https://platform.claude.com/docs/en/models/opus-5-5/whats-new-opus-5-5)）。 ## ④ 古いルールは、消す前に読み込まれているか確かめる 設定値を直しても、仕事の手順を指示するファイルが古ければ問題は残る。[最初のZenn記事](https://zenn.dev/nanora/articles/20260925-claude-prompt-audit-opus55)の筆者はルール・エージェント定義・実行プロンプト・参照資料を監査し、使われなくなった`paths:`が既に存在しないファイルを指していることを見つけた。モデルがどれだけ賢くなっても、読まれないルールは効かない。別の予備経路に残っていた課金APIキーについても、筆者は**成功0回、失敗144回で課金は発生していなかった**と記す。これは筆者の環境の記録であり、一般的な課金障害の率ではない。 ![取り壊された場所の扉へ古いpaths条件が指し続け、ルールが読まれず積もる概念図。](/blog/images/opus-5-5-ikou-otoshiana-comic-paths.png "PiRouter制作の概念イラスト。描写した事例：[Zennの設定監査記録](https://zenn.dev/nanora/articles/20260925-claude-prompt-audit-opus55)") ただし「古いから全部消す」も危ない。同じ筆者は13項目の報告前チェックを、**ある版／ない版の二通りで5課題を各3回**解かせた（計30回、報告費用$1.46）。4課題は両方とも全問正解だったが、「禁止を不可能と読み替えない」の課題だけは**あり3/3、なし0/3**。項目を13から10に整理し、その差が出た指示は残した。ツールなし・各3回という小さな試験を、あらゆる長時間作業への保証にしない。それでも**削除前に何が変わるかを比べる**という手順は役立つ。 Opus 5でthinkingを切るために書いた「考えるな」「推論を本文に出せ」という指示も監査対象だ。Opus 5.5では前者は設定と矛盾し、後者は内部の推論を再現させようとする要求として拒否され得る（[Prompting Opus 5.5](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5-5)）。ファイルに書かれた道順が実在するか、設定を直接いじらずとも意図が伝わるかを確認する。`/doctor prompt-audit`で古いパスや矛盾を拾える版なら利用できるが、候補の削除は差分を読んでからにする。これも9月27日の先行記事の実験と、今の自分の環境を区別すべきところだ。 ## 四段階の合格条件を、移行前の一枚にする | 順番 | 見る場所・コマンド | 合格の形 | 失敗したら | |---|---|---|---| | ① 実モデル | `claude -p --output-format json`の`modelUsage`。直接APIはレスポンス`model` | 想定したフルID | `--model claude-opus-5-5`などでピン留め、チームの`env`も確認 | | ② effort | CLIは`~/.claude/projects/.../*.jsonl`と子の`subagents/*.jsonl`、直接APIは送信`output_config.effort` | 記録または送信値が意図どおりで、上限も把握 | 実IDで`modelSettings`を書き、userの旧top-levelとの違いを確認 | | ③ 400 | ソース`rg`、必要なら自前の要求ログ`jq` | disabled thinking、enabled budget、強制tool_choiceが残らない | thinking省略＋effort、toolは`auto`＋目的別の制約に変更 | | ④ 指示 | ルールの`paths:`とモデル名、監査結果 | 読まれるファイルが実在し、必要な指示が残る | 消す前に小さな再現課題であり／なしを比較 | まず①と②を**自分の普段の実行環境**で確かめる。コードを直接APIで呼んでいる人が省くのは**Claude Code固有の`modelUsage`／jsonl確認コマンドだけ**だ。送信するフルモデルIDと`output_config.effort`、返ってきたレスポンスの`model`は同様に確認する。CLI 2.1.283で得た表と、10月2日に再読した新しいドキュメントは同じ時点の実測ではない。その差を残しておけば、次のマイナーバージョンで「設定が効かない」と感じたときにも、印象ではなく**実際に走ったモデル・設定・要求の形**を起点に調べ直せる。 --- ## Sources ### code.claude.com - [Model configuration](https://code.claude.com/docs/en/model-config) - [Settings reference](https://code.claude.com/docs/en/settings-reference) - [v2.1.284の変更](https://code.claude.com/docs/en/changelog) - [Sessions](https://code.claude.com/docs/en/sessions) - [公式Subagents](https://code.claude.com/docs/en/sub-agents) - [Claude Codeの環境変数](https://code.claude.com/docs/en/env-vars) ### zenn.dev - [日本語の設定監査記録](https://zenn.dev/nanora/articles/20260925-claude-prompt-audit-opus55) ### platform.claude.com - [Model IDs and versioning](https://platform.claude.com/docs/en/about-claude/models/model-ids-and-versions) - [公式Effortガイド](https://platform.claude.com/docs/en/build-with-claude/effort) - [Opus 5.5 What's new](https://platform.claude.com/docs/en/models/opus-5-5/whats-new-opus-5-5) - [Strict tool use](https://platform.claude.com/docs/en/agents-and-tools/tool-use/strict-tool-use) - [Prompting Opus 5.5](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5-5)