AIモデル廃止・提供終了への変更管理｜利用箇所表・評価・切替・代替運用

AIの要約や問い合わせ対応が安定して動いていても、利用中のモデルに提供終了日が設定されると、そのままでは業務を継続できません。アプリの設定を一つ変えれば済むように見えて、夜間バッチ、検索用の埋め込み、外部サービスの連携設定に同じモデルが残っていることもあります。

AIモデルの廃止対応では、終了日と対象の提供経路を確定し、利用箇所を棚卸ししたうえで、新旧モデルの業務結果を比較し、段階的に切り替えます。旧モデルを呼べなくなる日以降はロールバック先にできないため、別の検証済みモデル、有人対応、処理の保留も先に決めることが重要です。

作業は、利用箇所ごとに担当、依存する処理、評価セット、切替期限、終了後の代替運用を1行に書いた利用箇所表から始めます。提供者が示す通知期間はモデルの種類で異なり、プレビュー版は短い場合があるため、案内が届いた日に表を作り始めます。

以下はAPIを組み込んだ業務システムの変更管理を対象とします。チャットアプリ上のモデル選択、APIのモデルID、クラウド経由の提供条件は同じとは限りません。AI運用全体の責任分担は、AIエージェントのガバナンス設計と合わせて整理すると、切替時の承認者を決めやすくなります。

廃止案内を受けたら、対象と期限を先に確定する

最初に確認するのは、発表日、利用停止日、対象モデルID、対象API、提供経路、推奨移行先です。通知メールの件名だけで判断せず、公式の廃止一覧と移行ガイドを開き、確認日時と根拠URLを変更記録へ残します。同名のモデルでも直接APIとクラウド経由では時期や利用可能な機能が異なる場合があるため、実際に使う契約・プロジェクト・リージョン単位で確認します。

2026年10月26日に確認したOpenAIのDeprecationsでは、deprecationはモデルやエンドポイントの提供を終了する過程を示し、廃止対象には必ず利用停止日（shutdown）が設定され、その時点でアクセスできなくなると説明されています。legacyは更新を受けなくなった状態を表し、それだけで即日利用停止という意味ではありません。通知期間は、一般提供のモデルで少なくとも6か月、その特化版（チャット向け、Codex向け、deep research向けなど）で少なくとも3か月とされています。一方、名前にpreviewを含むプレビュー版は2週間ほどの短い通知で終了することがあり、短期間で移行できない場合は業務上重要な本番利用に使わないよう案内されています。安全性やコンプライアンス上の理由で早まる例外もあるため、過去の猶予期間を今回の期限の根拠にしないでください。

Google Cloudのモデルのバージョンとライフサイクルも、利用可能なモデルと終了日、推奨移行先を示しています。短期提供のモデルは別枠で説明されているため、「新しいモデルだから長く使える」とは判断できません。個別の終了日や後継候補は変更され得るので、移行着手時と本番切替の承認時に公式一覧を再確認します。

Google Cloudの一覧では、リリースから少なくとも12か月提供されるモデルと、短期提供のモデルが分けて掲載されています。短期提供のモデルは後継が出て終了日が発表されるまで提供され、終了日を設定するときは少なくとも45日の移行期間がとられます。掲載された終了日は延長されることはあっても前倒しはされないと説明されています。プレビュー版や短期提供のモデルを本番で使っている場合は、利用箇所表で終了までの期間が短いことが分かるようにしておきます。

社内期限は停止日の前日ではなく、評価、修正、承認、切替後の観察に必要な期間から逆算します。月末だけ動く処理があるなら、その動作を確認できる日程が必要です。残り時間が短い場合も評価を丸ごと省くのではなく、顧客への送信やデータ更新を止め、影響の小さい範囲で確認できる運用へ縮小します。

利用箇所表の作り方と記入例

棚卸しの結果は、利用箇所ごとに1行の表にまとめます。列は「どこで使っているか」だけでなく、「誰が直し、何に影響し、何で確かめ、いつまでに切り替え、終了後にどう業務を続けるか」まで並べます。次の記入例は、問い合わせ対応と営業支援、社内検索で同じ提供者のモデルを使っている場合の書き方です。

「依存する処理」には、モデルの出力を受け取る下流の処理を書きます。出力を人が読むだけの業務と、出力を別のシステムへ書き込む業務では、評価の厳しさと止め方が変わるためです。「社内の切替期限」は提供者の停止日ではなく、評価、修正、承認、切替後の観察に必要な期間を差し引いた日にします。埋め込みモデルの行は、文書の再生成とインデックスの切替が必要になるため、埋め込みモデルの移行手順に沿って別の計画を立てます。

利用箇所の棚卸しから切替までの7段階

移行は、利用箇所の棚卸し、新旧モデルの評価、段階的な切替、停止・代替運用の順で整理します。評価で問題が見つかったら切替を広げずに条件を見直します。図の戻り矢印は再評価を示すもので、廃止後にも旧モデルへ戻せることを意味しません。

1. 実際の呼び出し元を集める

コード内のモデルID検索だけでなく、環境設定、ワークフロー、ノーコード連携、定期ジョブ、委託先の処理を調べます。設定ファイルに存在することと、実際に呼ばれていることは別なので、API利用ログや請求の内訳、ジョブ実行履歴と照合します。利用ログがないものは「未使用」と断定せず、担当者確認待ちとして残します。

2. 入出力と下流の動作を一行ずつ記録する

集めた呼び出し元を、前述の利用箇所表へ1行ずつ記録します。表の列に加え、モデルID、エンドポイント、実行頻度、入力データの種類、出力形式も控えておくと、後継モデルの条件確認で使えます。検索用の埋め込みモデルは、ベクトルの次元やインデックスとの整合も別項目にします。

3. 後継候補の利用条件を確認する

公式推奨の後継は候補として有力ですが、自社の業務で同じ結果が出るという保証ではありません。入力上限、画像や音声の対応、構造化出力、ツール呼び出し、認証、レート制限、料金、データの取扱条件を確認します。評価用の少量リクエストが成功しても、本番の同時実行数で動くとは限りません。新しいモデルの利用許可と必要な割当を、切替作業とは別に点検します。

後継候補の入力と出力、想定用途と既知の制約は、提供者が公開しているモデルカードで確認できる場合があります。読み方はAI Model Cardの読み方で整理しています。

4. 同じ評価セットで新旧を比較する

通常の入力に加え、長文、日本語の表記ゆれ、欠損値、矛盾した情報、回答できない質問、権限外の依頼を含めます。正解例と採点基準を固定し、新旧双方の入力、設定、出力を記録します。機密情報や個人情報は、評価環境への持ち出しが許される範囲に限定し、匿名化や合成データも使います。同じモデルでも結果にばらつきがあるため、代表的な失敗が一度も出なかったことだけで安全とは扱いません。

5. プロンプトと連携処理を調整する

互換性がないパラメーター、構造化出力の扱い、応答の長さ、終了理由、ツールの引数を確認し、変更点を分けて記録します。モデルとプロンプトと出力処理を一度に変えると原因を特定しにくくなるため、まずモデル差を見てから必要な修正を加え、最終の組合せでもう一度評価します。ツールを使う業務では、AIエージェントの権限設計を再点検し、モデル変更を理由に実行権限まで広げないようにします。

6. 影響を限定して本番へ切り替える

最初は内部利用や読み取り専用など、失敗時の影響を抑えられる範囲を選びます。少人数や一部の処理から始め、成功率、遅延、費用、有人修正の件数を見て拡大します。比較のために同じ入力を新旧へ送る場合でも、メール送信やレコード更新を双方で実行してはいけません。片方は評価用の出力取得だけにし、実処理は一系統へ固定します。

7. 残存利用と終了後の運用を確認する

切替後は通常業務だけでなく、夜間、週次、月次の処理を含めて旧モデルへの呼び出しが残っていないか確認します。利用がゼロでも、古い設定や再実行待ちのジョブに旧IDが残っていれば再発します。ジョブ定義、手順書、監視、障害対応用の設定も更新し、終了日後の代替運用を運用担当へ引き継ぎます。古い認証情報を消す場合は、他のモデルや連携との共用を確認してから対象を限定します。

評価は文章の自然さと、業務が完了するかを分ける

読みやすい回答になっても、必須項目が欠けたり、ツールを余計に呼んだりすれば業務では失敗です。評価の合否は総合点だけにせず、必ず満たす条件と、改善を比較する指標に分けます。金額や日付の誤抽出、権限外の操作、重複送信のような重大な失敗は、文章の評価が高くても切替を広げない条件にします。

許容値は業務の要求から決めます。即時応答が必要な受付と、翌朝までに終わればよい集計で、同じ遅延基準を使う必要はありません。平均値だけでは遅い処理を見落とすため、分布や極端に遅い事例も確認します。費用は入力単価だけでなく、出力量、再試行、人による修正を含めて比較すると、単価が安いのに運用費が増える事態を見つけやすくなります。

承認記録には、評価したモデルID、プロンプトの版、連携処理の版、評価セットの版、合格条件、未解消の制約、承認者をまとめます。切替後に問題が起きたときの追跡項目は、AIエージェントの監査ログ設計も参考になります。認証情報や不要な個人情報をログへ丸ごと残す必要はありません。

旧モデルへ戻せない場合に備える

モデル移行の復旧計画は、旧モデルがまだ使える期間の切り戻しと、提供終了後の業務継続を分けて初めて成立します。切替設定を戻せても、参照先が既に停止していれば復旧しません。終了後は別の検証済みモデルへ切り替える、回答を有人確認へ回す、書き込みを止めて処理を保留するなど、業務ごとに実行可能な方法を決めます。

停止条件は「何となく品質が悪い」ではなく、必須項目の欠損、誤った宛先への送信、権限外の更新、処理遅延の継続など、観測できる事象で定めます。検知者、判断者、操作担当、利用者への案内担当を分け、判断者が不在のときにどこまで停止できるかも決めておきます。緊急時に代替モデルを初めて試す状態は避けます。

ロールバックはモデル設定だけの問題でもありません。切替後にデータを書き換えていれば、そのデータが旧処理で読めるか確認が必要です。外部へ送ったメールや確定済みの申込は、設定を戻しても取り消されません。処理IDと実行済みの範囲を照合し、再実行で二重処理を起こさないようにします。埋め込みの移行では新旧インデックスを混ぜず、どの埋め込みで検索するかと参照先を一緒に管理します（手順は埋め込みモデルの移行手順）。

引き継ぎでは、復旧先、切替手順、未処理の確認方法、業務再開の条件、確認すべきログを一枚にまとめます。最後に担当者が実際に手順をたどり、必要な権限と連絡先が使えるかを確認します。モデルの選定だけで終わらせず、停止しても業務を安全に続けられる状態まで整えることが、提供終了への備えになります。

AIモデルの廃止対応でよくある質問

廃止の通知はどのくらい前に来ますか？

提供者とモデルの種類で異なります。OpenAIは、一般提供のモデルで少なくとも6か月、その特化版で少なくとも3か月前の通知を示す一方、プレビュー版は2週間ほどの短い通知で終了することがあるとしています。Google Cloudは短期提供のモデルについて、終了日を設定してから少なくとも45日の移行期間を示しています。安全性などの理由で早まる例外もあるため、利用中のモデルごとに公式の一覧で確認します。

非推奨と提供終了は同じ意味ですか？

同じとは限りません。OpenAIでは非推奨化は終了までの過程、shutdownはアクセスできなくなる時点として説明されています。用語は提供者ごとに確認し、実際の対象と停止日を記録します。

推奨後継モデルへIDを変えるだけでよいですか？

十分ではありません。対応する入力、パラメーター、構造化出力、ツールの引数、権限、料金、レート制限を確認し、業務の完了結果まで評価します。

旧モデルを固定指定すれば廃止を避けられますか？

固定したID自体が終了対象なら避けられません。固定指定の可否と提供期間を確認し、期限前の移行と終了後の代替運用を準備します。

本番データで新旧を比較してもよいですか？

契約とデータ取扱ルールで許可された範囲に限ります。匿名化や合成データを使い、同じ入力を二系統へ送る場合も、外部送信やデータ更新を二重に実行しないようにします。

提供終了後に品質問題が出たらどうしますか？

旧モデルへの復帰を前提にせず、検証済み代替モデル、有人確認、処理の保留へ切り替えます。既に実行した外部操作と未処理を照合し、再実行による重複を防ぎます。