AIモデル廃止・提供終了への変更管理｜利用箇所・評価・切替・ロールバックを揃える方法
AIの要約や問い合わせ対応が安定して動いていても、利用中のモデルに提供終了日が設定されると、そのままでは業務を継続できません。アプリの設定を一つ変えれば済むように見えて、夜間バッチ、検索用の埋め込み、外部サービスの連携設定に同じモデルが残っていることもあります。
AIモデルの廃止対応では、終了日と対象の提供経路を確定し、利用箇所を棚卸ししたうえで、新旧モデルの業務結果を比較し、段階的に切り替えます。旧モデルを呼べなくなる日以降はロールバック先にできないため、別の検証済みモデル、有人対応、処理の保留も先に決めることが重要です。
以下はAPIを組み込んだ業務システムの変更管理を対象とします。チャットアプリ上のモデル選択、APIのモデルID、クラウド経由の提供条件は同じとは限りません。AI運用全体の責任分担は、AIエージェントのガバナンス設計と合わせて整理すると、切替時の承認者を決めやすくなります。
本記事のポイント
- モデルの廃止対応では、提供経路と利用停止日を確定し、定期処理や連携先を含む利用箇所を棚卸しします。
- 後継モデルは同じ評価セットで内容・構造化出力・ツール操作・性能・費用を確認し、段階的に切り替えます。
- 提供終了後は旧モデルを復旧先にできないため、検証済みの代替モデル、有人対応、処理保留を先に決めます。
廃止案内を受けたら、対象と期限を先に確定する
最初に確認するのは、発表日、利用停止日、対象モデルID、対象API、提供経路、推奨移行先です。通知メールの件名だけで判断せず、公式の廃止一覧と移行ガイドを開き、確認日時と根拠URLを変更記録へ残します。同名のモデルでも直接APIとクラウド経由では時期や利用可能な機能が異なる場合があるため、実際に使う契約・プロジェクト・リージョン単位で確認します。
2026年9月8日に確認したOpenAIのDeprecationsでは、deprecationはモデルやエンドポイントの提供を終了する過程を示し、shutdownの時点でアクセスできなくなると説明されています。legacyは更新を受けなくなった状態を表し、それだけで即日利用停止という意味ではありません。通知猶予にもモデル種別や安全性・コンプライアンス上の例外があるため、過去に半年の猶予があったことを今回の期限の根拠にしないでください。
Google Cloudのモデルのバージョンとライフサイクルも、利用可能なモデルと終了日、推奨移行先を示しています。短期提供のモデルは別枠で説明されているため、「新しいモデルだから長く使える」とは判断できません。個別の終了日や後継候補は変更され得るので、移行着手時と本番切替の承認時に公式一覧を再確認します。
| 確認する状態 | 業務上の扱い | 次に決めること |
|---|---|---|
| 旧版・更新停止 | 利用停止と混同せず、保守上の制約を確認する | 後継候補を評価する時期 |
| 廃止予告・非推奨 | 対象と停止日を変更案件として管理する | 社内の切替期限と責任者 |
| 利用停止 | 旧モデルを復旧先として当てにしない | 検証済み代替経路と業務の保留方法 |
| モデル名の参照先変更 | 同じ設定名でも実際の応答が変わり得る | 実行ログでの識別と再評価条件 |
社内期限は停止日の前日ではなく、評価、修正、承認、切替後の観察に必要な期間から逆算します。月末だけ動く処理があるなら、その動作を確認できる日程が必要です。残り時間が短い場合も評価を丸ごと省くのではなく、顧客への送信やデータ更新を止め、影響の小さい範囲で確認できる運用へ縮小します。
利用箇所の棚卸しから切替までの7段階
移行は、利用箇所の棚卸し、新旧モデルの評価、段階的な切替、停止・代替運用の順で整理します。評価で問題が見つかったら切替を広げずに条件を見直します。図の戻り矢印は再評価を示すもので、廃止後にも旧モデルへ戻せることを意味しません。
1. 実際の呼び出し元を集める
コード内のモデルID検索だけでなく、環境設定、ワークフロー、ノーコード連携、定期ジョブ、委託先の処理を調べます。設定ファイルに存在することと、実際に呼ばれていることは別なので、API利用ログや請求の内訳、ジョブ実行履歴と照合します。利用ログがないものは「未使用」と断定せず、担当者確認待ちとして残します。
2. 入出力と下流の動作を一行ずつ記録する
棚卸し台帳には、業務名、責任者、呼び出し元、モデルID、エンドポイント、実行頻度、入力データの種類、出力形式、連携先、停止時の影響を記録します。たとえば商談要約なら、文章を読むだけなのか、抽出した金額や日付をCRMへ書くのかで評価の厳しさが変わります。検索用の埋め込みモデルは、ベクトルの次元やインデックスとの整合も別項目にします。
3. 後継候補の利用条件を確認する
公式推奨の後継は候補として有力ですが、自社の業務で同じ結果が出るという保証ではありません。入力上限、画像や音声の対応、構造化出力、ツール呼び出し、認証、レート制限、料金、データの取扱条件を確認します。評価用の少量リクエストが成功しても、本番の同時実行数で動くとは限りません。新しいモデルの利用許可と必要な割当を、切替作業とは別に点検します。
4. 同じ評価セットで新旧を比較する
通常の入力に加え、長文、日本語の表記ゆれ、欠損値、矛盾した情報、回答できない質問、権限外の依頼を含めます。正解例と採点基準を固定し、新旧双方の入力、設定、出力を記録します。機密情報や個人情報は、評価環境への持ち出しが許される範囲に限定し、匿名化や合成データも使います。同じモデルでも結果にばらつきがあるため、代表的な失敗が一度も出なかったことだけで安全とは扱いません。
5. プロンプトと連携処理を調整する
互換性がないパラメーター、構造化出力の扱い、応答の長さ、終了理由、ツールの引数を確認し、変更点を分けて記録します。モデルとプロンプトと出力処理を一度に変えると原因を特定しにくくなるため、まずモデル差を見てから必要な修正を加え、最終の組合せでもう一度評価します。ツールを使う業務では、AIエージェントの権限設計を再点検し、モデル変更を理由に実行権限まで広げないようにします。
6. 影響を限定して本番へ切り替える
最初は内部利用や読み取り専用など、失敗時の影響を抑えられる範囲を選びます。少人数や一部の処理から始め、成功率、遅延、費用、有人修正の件数を見て拡大します。比較のために同じ入力を新旧へ送る場合でも、メール送信やレコード更新を双方で実行してはいけません。片方は評価用の出力取得だけにし、実処理は一系統へ固定します。
7. 残存利用と終了後の運用を確認する
切替後は通常業務だけでなく、夜間、週次、月次の処理を含めて旧モデルへの呼び出しが残っていないか確認します。利用がゼロでも、古い設定や再実行待ちのジョブに旧IDが残っていれば再発します。ジョブ定義、手順書、監視、障害対応用の設定も更新し、終了日後の代替運用を運用担当へ引き継ぎます。古い認証情報を消す場合は、他のモデルや連携との共用を確認してから対象を限定します。
評価は文章の自然さと、業務が完了するかを分ける
読みやすい回答になっても、必須項目が欠けたり、ツールを余計に呼んだりすれば業務では失敗です。評価の合否は総合点だけにせず、必ず満たす条件と、改善を比較する指標に分けます。金額や日付の誤抽出、権限外の操作、重複送信のような重大な失敗は、文章の評価が高くても切替を広げない条件にします。
| 評価対象 | 具体的な確認 | 判定に残す記録 |
|---|---|---|
| 回答の内容 | 根拠との一致、誤回答、回答を保留すべき場面 | 入力と正解基準、失敗例、確認者 |
| 構造化出力 | JSONの構文、必須項目、型、業務上の値の妥当性 | 検証結果と下流での受付結果 |
| ツール操作 | 選択したツール、引数、権限、二重実行の防止 | 実行前の承認と実際の操作結果 |
| 性能と費用 | 応答時間、同時実行、再試行、完了一件あたりの費用 | 測定条件と許容範囲 |
| 障害時の動作 | タイムアウト、制限超過、拒否応答、代替経路 | 停止判断と復旧までの手順 |
許容値は業務の要求から決めます。即時応答が必要な受付と、翌朝までに終わればよい集計で、同じ遅延基準を使う必要はありません。平均値だけでは遅い処理を見落とすため、分布や極端に遅い事例も確認します。費用は入力単価だけでなく、出力量、再試行、人による修正を含めて比較すると、単価が安いのに運用費が増える事態を見つけやすくなります。
承認記録には、評価したモデルID、プロンプトの版、連携処理の版、評価セットの版、合格条件、未解消の制約、承認者をまとめます。切替後に問題が起きたときの追跡項目は、AIエージェントの監査ログ設計も参考になります。認証情報や不要な個人情報をログへ丸ごと残す必要はありません。
旧モデルへ戻せない場合に備える
モデル移行の復旧計画は、旧モデルがまだ使える期間の切り戻しと、提供終了後の業務継続を分けて初めて成立します。切替設定を戻せても、参照先が既に停止していれば復旧しません。終了後は別の検証済みモデルへ切り替える、回答を有人確認へ回す、書き込みを止めて処理を保留するなど、業務ごとに実行可能な方法を決めます。
停止条件は「何となく品質が悪い」ではなく、必須項目の欠損、誤った宛先への送信、権限外の更新、処理遅延の継続など、観測できる事象で定めます。検知者、判断者、操作担当、利用者への案内担当を分け、判断者が不在のときにどこまで停止できるかも決めておきます。緊急時に代替モデルを初めて試す状態は避けます。
ロールバックはモデル設定だけの問題でもありません。切替後にデータを書き換えていれば、そのデータが旧処理で読めるか確認が必要です。外部へ送ったメールや確定済みの申込は、設定を戻しても取り消されません。処理IDと実行済みの範囲を照合し、再実行で二重処理を起こさないようにします。埋め込みの移行では新旧インデックスを混ぜず、どの埋め込みで検索するかと参照先を一緒に管理します。
引き継ぎでは、復旧先、切替手順、未処理の確認方法、業務再開の条件、確認すべきログを一枚にまとめます。最後に担当者が実際に手順をたどり、必要な権限と連絡先が使えるかを確認します。モデルの選定だけで終わらせず、停止しても業務を安全に続けられる状態まで整えることが、提供終了への備えになります。
AIモデルの廃止対応でよくある質問
非推奨と提供終了は同じ意味ですか？
同じとは限りません。OpenAIでは非推奨化は終了までの過程、shutdownはアクセスできなくなる時点として説明されています。用語は提供者ごとに確認し、実際の対象と停止日を記録します。
推奨後継モデルへIDを変えるだけでよいですか？
十分ではありません。対応する入力、パラメーター、構造化出力、ツールの引数、権限、料金、レート制限を確認し、業務の完了結果まで評価します。
旧モデルを固定指定すれば廃止を避けられますか？
固定したID自体が終了対象なら避けられません。固定指定の可否と提供期間を確認し、期限前の移行と終了後の代替運用を準備します。
本番データで新旧を比較してもよいですか？
契約とデータ取扱ルールで許可された範囲に限ります。匿名化や合成データを使い、同じ入力を二系統へ送る場合も、外部送信やデータ更新を二重に実行しないようにします。
提供終了後に品質問題が出たらどうしますか？
旧モデルへの復帰を前提にせず、検証済み代替モデル、有人確認、処理の保留へ切り替えます。既に実行した外部操作と未処理を照合し、再実行による重複を防ぎます。
モデル利用ログがゼロなら対応完了ですか？
完了とは限りません。月次ジョブ、停止中の連携、再実行待ちの処理に旧モデルIDが残る場合があります。設定と実行周期を確認し、手順書と復旧設定も更新します。
AIモデルの移行に向け、業務要件と評価項目、実装範囲を整理したい場合は、ファネルAiの超速AIパートナーの支援内容をご確認ください。
