既にエラーが返っている
claude-opus-4-1-20250805 は 2026 年 8 月 5 日に Claude API 上で退役しました。 予告ではなく、既に実行済みです。
公式のリリースノートにはこう書かれています。
We've retired the Claude Opus 4.1 model (
claude-opus-4-1-20250805). All requests to this model will now return an error.
現場では、この種の退役はこう見えます。手元で対話的に使っている人はすぐ気づき、自動処理に組み込んでいる人はしばらく気づきません。 気づいた時点で数日分の処理が飛んでいる、という形になりがちです。
運用に乗せるなら、順番は決まっています。確認、置き換え、次への備え。 この 3 段で見ていきます。
自分が影響を受けているかの確認
やることは 1 つです。claude-opus-4-1-20250805 で全文検索してください。
見る範囲は次のとおりです。
- リポジトリ全体 (コード・設定ファイル・環境変数の定義)
- CI やバッチの定義
- 社内の手順書やドキュメント
- 外部サービスに設定したモデル名 (連携先の管理画面など)
ヒットが 0 なら、あなたの環境では何も起きていません。ヒットがあれば、その箇所は今エラーを返しています。
注意
ログを見るだけでは足りません。エラーを握りつぶしている処理では、ログにも出ないことがあります。設定側から探すのが確実です。
気づきにくい場所
運用に乗せるなら、次の順で見てください。上から気づきやすい順です。
| 場所 | 気づくまでの時間 |
|---|---|
| 対話的に使っている箇所 | すぐ |
| 開発中のコード | 実行したとき |
| CI に組み込んだ処理 | 次のビルドまで |
| 日次・週次のバッチ | 次の実行まで。気づかない場合も |
| 例外時にだけ通る経路 | 発生するまで分からない |
いちばん下が厄介です。普段は通らない経路にモデル指定が残っていると、必要なときに動きません。 ここは検索でしか見つかりません。
エラーの見え方
エラーが返るとき、アプリ側にどう出るかは実装によって変わります。そのままエラーとして表示される場合と、握りつぶされて「結果が空」に見える場合があります。
現場で紛らわしいのは後者です。処理は最後まで走っているように見えるのに、中身だけが空。モデルの退役が原因だとは、なかなか結びつきません。
次のような症状が出ていたら、まずモデル指定を疑ってください。
- 特定の処理だけ、8 月 5 日以降に結果が空になっている
- リトライしても同じ結果になる
- 別の処理は正常に動いている
3 つ目が手がかりになります。全体が止まっているならネットワークや認証ですが、一部だけなら指定の問題です。
移行先について
公式の案内は、時期によって内容が違います。ここは正確に書きます。
| 時期 | 案内されている移行先 |
|---|---|
| 2026 年 6 月 5 日 (告知時) | Claude Opus 4.8 |
| 2026 年 8 月 5 日 (退役時) | Claude Opus 5 |
今から移すなら Opus 5 が案内どおりです。 6 月時点の告知を見て 4.8 に移した場合も、それ自体は当時の案内に沿っています。
いずれにせよ同系列の後継なので、指示の書き方を変える必要はありません。 世代が上がるだけです。世代間の違いを確認したい場合は Claude Opus 5 とは を参照してください。
研究目的の場合
公式には、研究者向けの継続アクセスが案内されています。External Researcher Access Program 経由で申請できます。
ただし、業務で使い続ける手段として考えないでください。 対象が研究目的に限られているため、通常の運用には使えません。業務で使っているなら、移行が唯一の選択肢です。
なお、過去のモデルとの比較検証を継続したい、という需要はこの枠に近いところにあります。再現性が要る評価をしているなら、申請を検討する価値はあります。 ただし、そこまでの必要がある組織は限られるはずです。
移してから確認すること
置き換えたあと、1 回だけ結果を見てください。 世代が上がると、同じ指示でも出力の傾向が少し変わることがあります。
見るのは 2 点で足ります。
形式が保たれているか。 決まった形で出力させている処理では、ここが崩れると後段が壊れます。JSON や表形式で受け取っている場合はとくに。
長さが極端に変わっていないか。 世代が上がると、説明が丁寧になって長くなる傾向があります。文字数に上限を設けている処理では、そこに引っかかることがあります。
いずれも、移した直後に 1 回流せば分かります。 気づかずに数日運用してから直すより、桁違いに安く済みます。
2 か月の猶予があった
念のため経緯を書いておきます。告知は 2026 年 6 月 5 日でした。
We announced the deprecation of the Claude Opus 4.1 model (
claude-opus-4-1-20250805), with retirement on the Claude API scheduled for August 5, 2026.
猶予は 2 か月ありました。 それでもエラーが出ているとしたら、告知を見ていなかったか、見たけれど作業が残っていたかのどちらかです。
現場では、後者のほうが多い印象があります。「あとでやる」と判断した時点で、忘れる確率がかなり上がります。 期日が 2 か月先だと、なおさらです。
FIXIT2 か月もあったのに、なんで間に合わないんだろう。
Kaname現場では、先が長いほど後回しになります。手順にしておくと回ります。
FIXITKaname誰がいつまでに、の 2 つで足ります。内容は数分の作業なので。
期日が先のものをどう扱うか
2 か月先の期日を忘れないための方法は、大掛かりである必要はありません。予定に入れるだけで足ります。
現場で回っているのは、次の形です。
- 告知を見た日に、期日の 1 週間前 で予定を入れる
- 予定の中身に、やることを 1 行だけ書く (「モデル指定を検索して置き換え」)
- 当日はその 1 行を見て、数分で終わらせる
2 番が要点です。 予定だけ入れて中身を書かないと、当日に「何をするんだったか」から始まります。調べ直すぶんの時間が、結局いちばん重くなります。
なお、期日そのものを予定にしないでください。当日に別のことが起きると、そのまま過ぎます。
次の退役に備える
モデルの退役は今後も定期的に起きます。そのたびに全文検索して回るのは、避けられる手間です。
運用に乗せるなら、次の 2 つが効きます。
モデル名を直接指定する箇所を減らす
指定が必要な理由がない箇所は、既定に任せてください。指定していなければ、退役のたびの作業が発生しません。
理由がある場合だけ指定します。たとえば、特定の世代でないと出力が安定しない処理、費用を厳密に管理している処理などです。「なんとなく指定した」箇所が、次回の作業対象になります。
指定する場合は 1 箇所にまとめる
どうしても指定が要るなら、設定として 1 箇所に集めておいてください。 環境変数でも設定ファイルでも構いません。
散らばっている状態が、いちばん手間がかかります。1 箇所にまとまっていれば、次回は 1 行の変更で終わります。
| 状態 | 次回の作業量 |
|---|---|
| 指定していない | 作業なし |
| 1 箇所にまとめている | 1 行の変更 |
| コード中に散らばっている | 全文検索して 1 つずつ |
上 2 つに寄せておくのが、運用としての備えです。
ついでに言うと、この整理は費用の管理にも効きます。どのモデルをどこで使っているかが 1 箇所で分かる状態は、使用量を見直すときの出発点 にもなります。退役対応のためだけの作業にはなりません。
「動いているから触らない」が効かない領域
サーバーやライブラリなら、動いているうちは触らないという判断が成立します。モデルの指定では、この判断が効きません。
理由は単純で、提供が止まる日が決まっているからです。こちらが何もしなくても、期日が来れば動かなくなります。放置は「現状維持」ではなく「期日に壊れる選択」です。
現場では、この違いが伝わりにくいところがあります。「今動いているものをなぜ触るのか」という反応は自然ですが、告知が出ている時点で、動き続ける選択肢は存在しません。
説明するときは、この一点だけ伝われば十分です。
| 対象 | 放置したときの結果 |
|---|---|
| 自社で動かすもの | 当面はそのまま動く |
| 提供を受けるモデル | 期日に停止する |
下の行に当てはまるものは、期日を見て動く前提で扱う のが運用です。
発注先に任せている場合
自社で開発していない場合、この種の対応は委託先の作業になります。ただし、確認の責任はこちら側に残ります。
聞くのは 2 点で足ります。
「モデルの退役に対応する運用はありますか」。 告知を見る係がいるか、期日をどう管理しているか。答えられるなら、たいてい回っています。
「今回の Opus 4.1 は影響しましたか」。 具体的な事例で聞くのがいちばん早い方法です。影響の有無と、対応済みかどうかが一度に分かります。
保守契約の範囲に入っているかも、あわせて確認しておいてください。「モデルの退役対応は別途費用」という切り分けをしている場合があります。 想定していないと、請求を見てから気づくことになります。
発注時の確認項目としては AI 開発の発注前に確認する 10 項目 にも整理しています。動き続けるものではない、という前提を契約時に共有できているかが分かれ目です。
告知を拾う仕組み
もう 1 つ、告知そのものを拾えるようにしておく話です。
Claude API の場合、リリースノートに退役の告知が載ります。全員が追う必要はなく、1 人が見て、影響がありそうなものだけ流す形で足ります。
見る頻度は週に 1 回で十分です。今回のように 2 か月の猶予があるものが多いので、週次でも間に合います。
見るときの観点も絞ってください。「retire」「deprecat」「終了」「廃止」に相当する記述だけを拾えば足ります。 新機能の追加は、見落としても困りません。困るのは、動いていたものが止まる変更だけです。
この絞り込みがあると、週次の確認が数分で終わります。全部を読もうとすると続かないので、拾う対象を先に決めておくのが現実的です。
なお、同じ時期に他のツールでも期限のある変更が重なっています。まとめて確認したい場合は Codex で GPT-5.4 が 8/31 終了 と GitHub Copilot で 6 モデルが 9/1 廃止 も合わせて見てください。この 3 件は、確認する場所が違うだけで作業の性質は同じです。
まとめ
claude-opus-4-1-20250805は 2026 年 8 月 5 日に退役済み。リクエストはエラーになる- まず全文検索で、指定が残っている箇所を洗い出す
- 移行先は、退役時点の案内では Claude Opus 5。6 月時点の告知では Opus 4.8 だった
- 気づきにくいのはバッチと例外時の経路。ログではなく設定側から探す
- 研究目的の継続利用は申請制。業務利用の手段にはならない
- 次回に備えるなら、モデル名の直接指定を減らし、残す分は 1 箇所にまとめる
- 告知は週 1 回、「終了・廃止」に相当する記述だけを拾えば足りる
- 発注先に任せている場合も、対応の運用があるかの確認はこちら側の仕事