Claudeモデルの引退で自動化が止まる日 — バージョン固定とエイリアスの設計判断

Claude Opus 4.1は2026年6月5日に非推奨化の通知が出て、8月5日に引退しました。引退したモデルへのリクエストは失敗します。エージェント定義・CI・スクリプトにそのモデルIDを直書きしていた自動化は、この日を境に全部止まります。

一方で、モデルIDをエイリアスにしておけば止まらないかというと、そうでもありません。エイリアスは解決先が移った日に、気づかないうちにコストと挙動が変わります。モデルIDを新世代へ書き換えた日には、渡していたパラメータが400エラーで弾かれることもあります。つまり「固定かエイリアスか」は好みの問題ではなく、どちらの壊れ方を引き受けるかという設計判断です。この記事では、引退の仕組みと2つの壊れ方を確認したうえで、書く場所ごとの使い分けまで見ます。

Claudeモデルの引退はどう進むか

Claudeモデルの引退とは、AnthropicがモデルをAPIから完全に取り下げ、リクエストが失敗するようになることです。公式はライフサイクルをActive(現役)・Legacy(更新停止)・Deprecated(非推奨、引退日確定)・Retired(引退済み)の4段階で定義しています。Deprecatedになると推奨代替モデルと引退日が割り当てられ、公開モデルでは引退の60日以上前に通知されます。通知はメールとドキュメントの両方です。例外もあります。claude-mythos-previewは2026年6月9日にDeprecatedになりましたが、引退日は「To be announced」のままです。

実績を見ると、猶予は本当に約2ヶ月しかありません。

現役モデルにも「これより早くは引退しない」という暫定日が公表されています。近いものでは、claude-haiku-4-5-20251001が2026年10月15日、claude-opus-4-5-20251101が2026年11月24日です。claude-opus-5は2027年7月24日まで動きます。日付の近いモデルを固定している自動化は、次の非推奨化候補を抱えていることになります。

この日程が適用されるのはAnthropic運営のプラットフォーム(Claude API・Claude Platform on AWS・Microsoft Foundry)です。Amazon BedrockとGoogle Cloudはパートナー運営のため引退スケジュールが別で、同じモデルでも状態と日付が食い違うことがあります。複数プラットフォームにまたがる自動化は、引退の監視も別々に必要です。

バージョン固定の壊れ方 — 引退日に確実に止まる

claude-opus-4-8 のような完全なモデルIDを書くのがバージョン固定です。注意したいのは、4.6世代以降の日付なしIDも固定であることです。claude-sonnet-4-6 は「最新のSonnetに追随するポインタ」ではなく、単一のスナップショットを指す正式IDだと公式が明言しています。重みが更新されることはなく、改良版は必ず別IDで出ます。日付がないから追随する、という直感は誤りです。

固定したIDが引退すると、そのIDへのリクエストは失敗します。Claude Codeでは、綴り違い・存在しないID・アクセス権のないIDを指定すると次のエラーになります。引退済みのIDでも、同じ系統のエラーになる場合があります。

There's an issue with the selected model (claude-...).
It may not exist or you may not have access to it.
Run /model to pick a different model.

非対話の -p では末尾が Run --model に変わり、Agent SDKではこのヒントが付きません。

--model フラグ・ANTHROPIC_MODEL・model 設定で渡した値は、Claude Codeが起動時に検査しません。綴りの誤りも引退済みIDも、最初のリクエストで初めてこのエラーになります。

自動化パイプラインでこの停止が起きる経路は、大きく2つあります。

1つ目は「自分で書いた固定」です。サブエージェント定義のfrontmatter(model: に完全IDを書ける)、CIの環境変数、スクリプトの引数。書いた本人が引退通知のメールを読み飛ばすと、引退日にそのサブエージェントの起動やCIジョブが一斉に失敗します。リクエスト自体は引退日まで成功し続けるため、警告や通知を見落とすと、事前のテストでは見つかりません。

2つ目は「ツールに同梱された固定」です。CIでCLIやSDKのバージョンを固定して使っている場合、その古いバージョンが内包する既定モデルや依存先が引退対象になることがあります。自分ではモデルIDを1文字も書いていないのに、実体としては固定していたというパターンです。この場合の対処はモデルIDの書き換えではなく、ツール自体の更新になります。「モデルIDをどこにも書いていないから無関係」とは言えません。

Claude Codeには、この事故を手前で知らせる仕組みが入っています。指定したモデルに引退予定日がある場合と、新しいバージョンに自動で置き換えられる場合に、起動時に警告が表示されます。v2.1.182以降は、非対話モードでも同じ警告がstderrに書かれます。サブエージェント定義のfrontmatterに書いた model: も検査対象です。加えてfallbackModelも緩和策になります。チェーンに引退済みモデルが混ざっていても、そのエントリを飛ばして次に切り替わる仕様です。

--resume や --continue で再開したセッションは、保存時のモデルを引き継ぎます。そのモデルが引退済みなら、通常の優先順位でモデルを選び直す動きです。古いセッションが引退済みIDのせいで開けなくなる、という事態は起きにくい作りになっています。ただしBedrock・Google Cloud・Foundryでは、保存時のモデルは復元されません。

Agent SDKやアプリ経由では、v2.1.268以降は最初にそのモデルへ切り替えるとき、IDをプロバイダーに照会して確かめます。提供されていないIDは、次のリクエストを待たずに切り替えの時点で拒否されます。

もう1つ、認識されないIDを拾う診断があります。-p で動かすスクリプトやハーネスでは、stderrの [claude-code:unrecognized_model] 診断行を監視すると、認識されないモデルIDのリクエストを検出できます。対話セッションとバックグラウンドセッションでは、この行はdebug log(--debug)に書かれます。この診断は、そのバージョンのClaude Codeが認識しないIDに対して出るもので、引退済みでも既知のIDでは出ません。

エイリアスの壊れ方 — 移動した日に静かに別物になる

エイリアスの壊れ方は逆で、止まらない代わりに中身が変わります。Claude Code v2.1.287の claude --help は、この区別を引数の説明にそのまま書いています。

--model <model>   Model for the current session. Provide an alias for the
                  latest model (e.g. 'fable', 'opus', or 'sonnet') or a
                  model's full name.
--fallback-model <model>   ... Accepts a comma-separated list to try each in
                  order. Re-tries the primary at the start of each user turn.

エイリアスは「最新のモデル」、完全名は特定のモデルです。fallback-modelはカンマ区切りで複数を並べられ、主モデルへはユーザーのターンごとに再挑戦します。Claudeのエイリアスは主に3種類です。

API上の簡易エイリアスは、そのマイナー版の最新日付スナップショットに留まり、世代をまたいで移ることはありません。世代をまたいで解決先が動くのは、Claude Codeのファミリーエイリアスです。移動した日から、料金・トークナイザー・応答の性格が一度に変わります。

実害が出やすいのは、モデルIDを新世代へ書き換えた日です。引退に伴う移行や、自前のゲートウェイ・ラッパーで別名の向き先を付け替えた日がこれにあたります。Opus 4.7以降のモデルは temperature / top_p / top_k に既定値以外を渡すと400エラーを返します。旧世代向けのコードがこれらを渡していると、書き換えた日から全リクエストが失敗します。

Opus 5.5にはもう1つ落とし穴があります。tool_choice に {"type": "any"} か {"type": "tool", ...} を指定した場合です。400の invalid_request_error が返ります。メッセージは次のとおりです。

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

スキーマに沿ったJSONを強制する目的で使っていた呼び出しは、移行先がOpus 5.5だと動きません。固定の壊れ方が「引退日に止まる」なら、エイリアスの壊れ方は「移動日に化ける」です。止まるのは、IDを書き換えた日です。

止まらないケースのほうが、実は厄介です。トークナイザーの変更でトークン数が変わればコストが黙って動きます(Opus 4.7世代のトークナイザーは従来比1〜1.35倍)。応答の性格が変われば、プロンプトの調整前提が崩れます。パイプラインは緑のまま、成果物の品質だけが変わっている状態は、監視では捕まえにくいものです。

中間解として、Claude Codeには ANTHROPIC_DEFAULT_OPUS_MODEL などの環境変数があります。仕組みはfableエイリアスの解決先を変えるANTHROPIC_DEFAULT_FABLE_MODELと同じ仕組みです。エイリアスという書き方を保ったまま、解決先の移動タイミングを自分の管理下に置けます。組織なら、管理設定(managed settings)で enforceAvailableModels と env ブロックを併用すると、許可モデルの制限とバージョン固定を両方かけられます。

どこに何を書くか — 固定とエイリアスの使い分け

壊れ方が対照的なので、使い分けの軸は「その場所で起きてほしくないのはどちらの事故か」です。

固定を選んだ日から、次の4手を運用に組み込むと、引退が不意打ちになりません。

よくある質問

Python SDKなら、temperatureを渡しても400にならないのですか

Opus 4.7以降を対象にしたPython SDK(v1.0以降)は、これらのパラメータを型として定義していません。渡すと400ではなく、リクエストの前に TypeError が出ます。いずれにしても既定値以外は通りません。

引退したモデルの重みは消えるのですか

消えません。Anthropicはモデル重みの長期保存を確約しており、将来的に過去モデルを再公開したい意向も表明しています。ただし仕様としては、引退済みモデルへのリクエストは失敗します。「いつか戻るかもしれない」を運用の前提にはできません。

まとめ

最初の一手は、自分の自動化がモデルIDを書いている場所を洗い出し、それぞれがどちらの壊れ方を抱えているかを見分けることです。固定の箇所は引退日、エイリアスの箇所は解決先が動いたときの料金と挙動を控えておけば、不意打ちは減ります。現行モデルの一覧と各IDの位置づけはClaudeモデル一覧にあります。