AIツールの保守期限管理で業務停止を防ぐには【モデル退役を台帳で見る】

AIツールの保守期限管理は、契約更新日だけを見る作業ではありません。
モデル退役、API停止、管理者通知、代替モデルのテスト期限まで台帳で見ておく運用です。

生成AIは便利ですが、古いモデルやpreview機能に業務を固定すると、ある日から顧客対応、議事録作成、広告文チェック、社内検索が止まることがあります。
通知が来ることと、会社が期限内に動けることは別問題です。

すでにAI調達全体のリスクを見直したい場合は、先に使っていたAIが急に使えなくなる理由を読むと、ベンダー依存の全体像をつかみやすくなります。

AIツールの保守期限管理はモデル退役を台帳で見る

AIツールの保守期限管理とは、使っているAIがいつまで動くかを業務単位で見える化することです。
対象はChatGPTやClaudeのWeb画面だけでなく、API、AIエージェント、AI内蔵SaaS、社内ツールに組み込んだモデルまで含みます。

ここで混同しやすいのが、契約更新日とモデル退役日です。契約が残っていても、古いモデルIDやエンドポイントが退役すれば、API連携や自動処理は失敗します。

AnthropicはClaudeモデルについて、Active、Legacy、Deprecated、Retiredという状態を示しており、
Retiredになったモデルは利用できず、リクエストは失敗すると説明されています。

出典: Anthropic Docs「Model deprecations」(英語)

保守期限管理で見落とすと危ないのは、画面で使っているAIより、裏側で自動実行されているAIです。
社内でどのAIに誰がアクセスできるかを整理していない場合は、AIツールの権限棚卸しと同じ台帳で管理すると重複が減ります。

deprecated、retired、EOL、shutdownの違い

用語はベンダーごとに違いますが、実務で見るべき点はシンプルです。
そのモデルがまだ動くのか、いつ止まるのか、誰が通知を受けるのかの3点に読み替えれば判断ミスを減らせます。

退役管理で見る用語の実務整理

用語	実務上の意味	見る項目
Deprecated	非推奨または退役予定	代替先と期限
Retired	利用不可の段階	停止後の影響
EOL	提供終了	基盤側の期限
Shutdown	エンドポイント停止	最短停止日

OpenAIはdeprecationsページで、一般提供モデル、特殊派生モデル、previewモデルの通知期間を分けており、
一般提供モデルは最低6ヶ月、特殊派生モデルは最低3ヶ月、previewモデルは短い場合2週間程度という扱いで、previewを本番固定するほど移行余裕は小さくなります。

出典: OpenAI Platform Docs「Deprecations」(英語)

Google Gemini APIでは、deprecationはサポート終了の発表、shutdownはエンドポイントが利用できなくなる段階として説明されています。
表にあるshutdown日は最も早い可能性がある日付で、正確な停止日は別途通知される点も台帳に反映し、最短停止日だけで社内期限を決めないようにしてください。

出典: Google AI for Developers「Gemini deprecations」(英語)

AIツール保守台帳に入れる14項目

台帳は、ツール一覧ではなく停止影響の一覧として作ると使いやすくなります。
経営側が見たいのは「どのAIを使っているか」ではなく、「止まるとどの業務が困るか」です。

まず埋めるべき項目は、14個あります。
全社で完璧な棚卸しを狙うより、請求、顧客対応、公開、契約、社内検索など、止まると売上や信用に直結する業務から始めてください。

• ツール名、ベンダー名、契約名、プラン名を記録する
• Web版、直接API、Azure OpenAI、Amazon Bedrock、Google Cloud、SaaS内蔵などの利用経路を分ける
• モデル名、モデルID、バージョン、現在ステータスを記録する
• 用途、業務重要度、停止時の代替策、ロールバック方法を入れる
• 通知先、契約担当、技術担当、業務責任者、最終確認日、次回確認日を入れる

AI利用台帳をまだ作っていない会社では、権限棚卸しと保守期限管理を分ける必要はありません。
AIアクセス権限の台帳に、モデルID、退役予定、通知先、代替策の列を足すだけでも実務は前に進みます。

Claude、OpenAI、Gemini、Azure、Bedrockで見る退役管理の違い

モデル提供元と利用基盤を分けて見ることが、生成AIモデル退役対策の核心です。
たとえばClaudeを使っていても、Anthropicの直接APIなのか、Amazon Bedrock経由なのか、別SaaSの内蔵機能なのかで確認先が変わります。

主要基盤ごとの確認ポイント

基盤	見るもの	注意点
Anthropic	モデル状態	基盤差あり
OpenAI	通知期間	preview注意
Gemini API	停止日	最短日と確定日
Azure OpenAI	Lifecycle	410 Gone確認
Bedrock	modelLifecycle	EOL後失敗

Microsoft FoundryのAzure OpenAIモデル退役資料では、Retiredモデルへの推論リクエストが410 Goneになると説明されています。
Models APIでlifecycleStatus、deprecation、deprecationDateを確認できるため、技術担当がいる場合は定期点検に組み込むべきで、エラー後の調査では遅いと考えてください。

出典: Microsoft Learn「Azure OpenAI model retirements」(英語)

Amazon BedrockはActive、Legacy、End-of-Lifeという状態を使い、GetFoundationModelやListFoundationModelsのmodelLifecycleで確認できると説明しており、
EOL後は対象モデルへのリクエストが原則失敗するため、AWS経由のAI利用は提供元公式だけでなくBedrock側の期限も見る必要があります。

出典: AWS Docs「Model lifecycle」(英語)

AWS経由でAIモデルを使う会社は、Amazon BedrockのAIモデル比較もあわせて確認すると、調達経路を分けて考える感覚がつかみやすく、
モデル終売リスクの具体例としては、Imagen4の移行記事も参考になり、特定モデルに業務を寄せすぎない判断につながります。

業務停止を防ぐ月次チェック手順

月次チェックは、公式ページを見るだけで終わらせないことが大切です。
期限が近い項目を見つけたら、同じ入力を新旧モデルに入れて、出力形式、精度、速度、費用、承認フローへの影響を確認します。

• 公式のdeprecations、model lifecycle、管理画面通知を確認する
• 管理者メールに退役、価格、規約、セキュリティ通知が届いていないか見る
• 台帳から90日以内に期限が来るAIツールを抽出する
• 代替モデルで同じ入力を試し、出力形式と承認フローの差分を残す
• 切替後のエラー、費用、品質差を1週間だけ重点監視する

90日以内という目安は、社内説明、テスト、切替、関係部署への共有を考えるための実務期限です。
公式通知が60日前でも、通知先が退職者のメールなら会社にとってはゼロ通知になります。

停止時の社内ルールをまだ決めていない場合は、生成AI利用停止対策で、代替手段と周知フローを先に整理しておくと、退役通知を見てから慌てる状態を避けられます。

AI導入のベンダー契約で確認すべき注意点

AI導入のベンダー契約で見るべき注意点は、料金表より先に責任分界です。
モデル退役、API廃止、プラン変更が起きた時に、誰が何日前に、どの方法で、どこまで支援するかを確認してください。

• モデル退役、API廃止、プラン変更時の通知方法を確認する
• 通知先を複数登録できるか確認する
• 推奨代替モデルと移行支援の有無を確認する
• ログ取得、データエクスポート、ロールバック方法を確認する
• previewやbeta機能を本番利用してよい契約か確認する

ツール選定そのものから見直す場合は、生成AIツール選定の比較ポイントを使い、料金、セキュリティ、管理機能、サポートを同じ軸で並べると判断しやすくなります。
社内の利用範囲を決める段階なら、生成AIの社内利用ルールも合わせて確認してください。

まとめ: AIツール保守期限管理は業務停止を防ぐ運用である

AIツール保守期限管理とは、生成AIモデルやAI内蔵ツールがいつまで使えるかを、業務影響、通知先、代替策、切替テスト期限まで含めて台帳化するプロセスです。
契約が残っているかではなく、業務が止まらず移行できるかを見ます。

最初の一歩は、全AIツールを完璧に洗い出すことではありません。
請求、顧客対応、公開、契約、社内検索など、止まると困る業務に使っているAIから、モデルID、利用経路、通知先、代替策を埋め、期限前にテストを終える状態を作ってください。

AIツールの保守期限管理でよくある質問