Claude APIをコードに埋め込んだまま半年運用して、ある日突然リクエストが400エラーで返ってくる——これは設定ミスではなく、モデルの退役によるものかもしれない。IT担当が1人しかいない中小企業では、非推奨化の通知メールを見落としたまま退役日を迎えるケースが起こりやすい。
Claudeのモデルは定期的に非推奨化・退役する設計になっている。本記事では、そのライフサイクルの仕組みと、中小企業が無理なく移行計画を立てる手順を解説する。
Claudeモデルはどう非推奨化されるのか
Claudeモデルはactive・legacy・deprecated・retiredの4段階で管理され、deprecated時に後継モデルと退役日が示される。
Anthropicはモデルのライフサイクルを4段階で管理している。「active」は完全サポート中の推奨モデル、「legacy」は更新が止まり将来非推奨化される可能性がある状態、「deprecated」は動作はするが推奨されず後継モデルと退役日が明示された状態、「retired」はAPIリクエスト自体が失敗する状態だ。この区分はClaude API・AWS上のClaude Platform・Microsoft Foundryに適用され、Amazon BedrockやGoogle Cloud経由の利用では各プラットフォームが独自の退役日を設定する点に注意が必要だ。
非推奨化から退役までに何が起きるか
公開済みモデルの退役には最短60日前の通知が義務付けられ、メールとドキュメントの両方で案内される。
本番環境でモデルを使っているアカウントには、退役の最低60日前に通知が届く。実際の運用では、2026年4月14日にClaude Sonnet 4・Opus 4の退役が通知され、同年6月15日に退役するという約2カ月のスケジュールで進んだ。通知を見落とさないためには、契約者個人のメールだけでなく、チームの共有チャンネルにも転送する運用を組み込んでおくとよい。
中小企業はどう移行計画を立てるべきか
後継モデルでの事前テストを退役日より十分前に終え、段階的に本番トラフィックを切り替えるのが安全だ。
移行計画は3ステップで組める。まず非推奨化の通知を受けたら、ドキュメントの移行ガイドで後継モデルと変更点を確認する。次に、本番と同じプロンプト・ツール定義で後継モデルをテスト環境で動かし、出力品質とレイテンシーを比較する。最後に、退役日より余裕を持って本番のmodelパラメータを切り替える。あわせて、リクエストヘッダーのanthropic-versionは固定したまま使えるため、API自体の互換性を気にする必要はない。パラメータ側では、temperature・top_p・top_kがClaude Opus 4.7以降の一部モデルで非デフォルト値を渡すと400エラーになる変更も入っているため、プロンプト側での制御に切り替える移行も合わせて検討したい。
API利用状況をどう確認するか
Claude ConsoleのUsageページからCSVをエクスポートすれば、APIキー・モデル別の利用実態を棚卸しできる。
どのコードがどのモデルを呼んでいるか分からなくなっている場合は、Claude ConsoleのUsageページから利用状況をCSVでエクスポートできる。APIキー・モデル別の呼び出し件数が確認できるため、非推奨化対象のモデルIDを使っている箇所を洗い出し、優先的に移行するリストを作る土台になる。
参考
まとめ
Claudeモデルの非推奨化は、最短60日前の通知を起点に、後継モデルでのテストと段階的な切り替えで乗り越えられる。モデル選定の基準を押さえている企業ほど、移行時の後継モデル選びに迷わない。通知の見落としを防ぐ体制作りから、まずは着手するとよい。
Kuuのエージェントガバナンスサービスでは、モデル運用の体制整備から移行計画の設計までサポートしている。