Claudeモデル退役でAI機能が急に止まる前に確認する3項目

Claudeで作った社内のAI機能は、モデル退役を見落とすと急にエラーになることがあります。チャット画面だけを使っているなら影響は限定的でも、問い合わせ対応、社内検索、記事下書き、顧客向けツールにAPIを組み込んでいる場合は話が変わります。

退役管理は新モデルの性能比較より地味ですが、AI機能が止まる前提の備えとしては優先度が高い領域です。2026年6月29日時点のAnthropic公式情報をもとに、まず見るべき項目は3つに絞ります。

Claudeモデル退役で何が起きるか

Anthropicはモデルの状態をActive、Legacy、Deprecated、Retiredに分けています。ここで特に注意したいのは、Deprecatedはまだ動くが退役日が近い状態、Retiredは利用できない状態だという違いです。

状態	意味	社内での扱い
Active	現行モデル	通常利用。ただし台帳には残す
Legacy	古いがまだ利用できるモデル	新規採用は避け、移行計画を確認
Deprecated	非推奨で退役日が割り当てられた状態	置換モデルでテストを始める
Retired	利用できない状態	そのモデルIDへのリクエスト失敗を疑う

出典: Anthropic公式 Model deprecations

公式ページでは、公開モデルの退役について少なくとも60日前に通知すると説明されていますが、通知が開発者のメールだけに届き、業務責任者まで伝わらないことがあります。APIキーの発行者と、AI機能を使う部署が違う会社では、通知経路そのものが弱点になります。

確認1: 使っているClaudeモデルIDを見る

最初に探すのは「Claudeを使っているか」ではなく、どのモデルIDを指定しているかです。2026年6月29日時点で、claude-opus-4-1-20250805 はDeprecatedで退役予定日は2026年8月5日、claude-sonnet-4-20250514 と claude-opus-4-20250514 は2026年6月15日にRetiredになっています。

出典: Anthropic公式 Model deprecations

確認場所はコードだけでなく、環境変数、API gateway、ログ、ノーコード連携、AI機能付きSaaSの管理画面にも残ります。社内の利用棚卸しは、AIツールのアクセス権限棚卸しと同じ感覚で、機能名ではなく管理対象を一段細かく分けると進めやすくなります。

出典: Anthropic公式 Model IDs and versioning

確認2: どの経路でClaudeを使っているか分ける

同じClaudeでも、Anthropic APIを直接使う場合と、Amazon BedrockやGoogle Cloud経由で使う場合では、モデルIDの書き方や確認場所が変わります。Anthropic公式も、パートナー運営プラットフォームでは日程が異なる場合があると注記しています。

利用経路	見る場所	注意点
Anthropic API	Claude Console、コード、Usage CSV	モデルIDと退役日を公式表で照合
Amazon Bedrock	AWS管理画面、モデルID、リージョン	anthropic. 付きのID形式を別管理
Google Cloud	エンドポイントURL、基盤側のモデル表	Google Cloud側の提供状況も確認
AI機能付きSaaS	契約、管理画面、ベンダー回答	裏側のモデルIDと移行責任を確認

出典: Anthropic公式 Claude in Amazon Bedrock / Anthropic公式 Claude on Google Cloud

外部ベンダーに任せている機能ほど、「どのモデルか分からない」まま使われがちです。AIベンダー任せのリスク管理では、使用モデルID、退役通知の方法、移行時の責任範囲を確認項目に入れてください。Bedrock経由の利用がある場合は、Bedrockのモデル確認も別タスクとして扱うほうが安全です。

確認3: 置換モデルで業務品質を試す

退役対応で危ないのは、モデル名だけを新しいものに変えて「APIが通ったから完了」と判断することです。実際には回答の長さ、拒否の出方、指示追従、コスト、速度が変わる可能性があり、社内AIの速度や待ち時間も現場の使い勝手に直結します。

出典: Anthropic公式 Migration guide

退役日が近いときの優先順位

退役日が近い場合、すべてを同じ重さで見ると遅れます。先に見るのは止まると顧客対応や売上に影響する機能で、社内の補助ツール、顧客向け機能、外部ベンダー管理の機能を分けて、影響が大きい順に確認します。

1. 顧客向け画面、問い合わせ返信、予約や見積もりなど、止まると外部に見える機能を先に確認する。
2. 毎日使う社内業務を次に確認する。記事作成、議事録、社内検索など、代替作業に時間がかかるものを優先する。
3. ベンダー提供AI機能は、使用モデルID、通知方法、移行予定、利用者側で必要な作業を確認する。

この優先順位は、AI停止時の代替手順と合わせて作ると実務に落ちます。退役対応だけを単独で考えるより、止まったときの連絡先、切り戻し、手作業の手順まで並べたほうが、現場は動きやすくなります。

モデル退役管理台帳に入れる列

管理台帳は複雑にしすぎると続かないため、最初は次の列だけで十分です。重要なのは、AIツール名ではなく機能ごとに1行を作ることです。

列名	記入する内容
機能名	問い合わせ返信、社内検索、記事下書きなど
利用経路	Anthropic API、Bedrock、Google Cloud、SaaSなど
モデルID	コードや管理画面で確認した文字列
業務責任者	停止時に判断する人
退役日	公式表またはベンダー回答で確認した日付
置換候補	テストするモデルや代替手段
最終テスト日	代表プロンプトで確認した日

月1回でも、この台帳を見直すだけで「誰も気づかないうちに非推奨モデルを使い続ける」状態を減らせます。新しいAI機能を追加したときも、同じ台帳に1行足す運用にしておくと、後から追いやすくなります。

よくある質問