AI開発の本番切替とロールバック責任分界の決め方
AIシステムの本番切替(カットオーバー)で、切替判定・監視・ロールバック発動の責任分界を発注者とベンダーの間でどう決めるかを、判定基準と手順書の要件から解説します。

結論
AIシステムの本番切替で最も危険なのは、切替そのものの失敗ではなく、「戻すかどうかを誰がいつ決めるか」が決まっていないまま切替日を迎えることです。切替計画には、切替可否の判定(Go/No-Go)、切替後の監視、ロールバック発動、ロールバック実施、業務側の代替運用の5つの役割について、実行担当(R)と最終責任者(A)を発注者・ベンダーのどちらが持つかを明記します。特にロールバック発動の権限は発注側の業務責任者に置き、発動基準を数値で事前合意しておくことが原則です。
切替の責任分界とは何を決めることか
本番切替の責任分界とは、切替前後の一連の判断と作業について、発注者とベンダーのどちらが実行し、どちらが結果に責任を持つかを役割単位で確定させることです。RACI(実行・説明責任・協議・報告)の形式で整理すると、「両者で協力して対応」という曖昧な記述を排除できます。
AIシステムの切替が従来システムより難しいのは、切替直後の出力品質が事前検証と一致する保証がないことです。本番トラフィックの入力分布はテストデータと必ずずれるため、「切替は成功したが出力品質が想定を下回る」という中間状態が発生します。この中間状態で戻すか粘るかを決める仕組みが、ロールバック発動基準です。
役割分担表の標準形
切替計画書に入れる分担表の標準形は次のとおりです。
| 役割 | 実行(R) | 最終責任(A) | 補足 |
|---|---|---|---|
| Go/No-Go判定 | 発注側PM | 発注側業務責任者 | 判定材料の提出はベンダー |
| 切替作業 | ベンダー | ベンダーPM | 作業手順書はリハーサル済みのもの |
| 切替後監視 | ベンダー+発注側運用 | ベンダーPM | 監視項目と閾値は事前合意 |
| ロールバック発動 | 発注側業務責任者 | 発注側業務責任者 | 発動基準を数値で事前定義 |
| ロールバック実施 | ベンダー | ベンダーPM | 制限時間と完了確認手順を定義 |
| 代替業務運用 | 発注側業務部門 | 発注側業務責任者 | 切替失敗時の手作業運用手順 |
この表で発注側が譲ってはいけないのは、ロールバック発動の最終責任です。ベンダーに置くと、切替失敗を認める判断とベンダー自身の評価が利益相反になります。逆にロールバック実施(技術作業)はベンダー責任で構いません。
ロールバック発動基準を数値で決める
発動基準は「重大な問題が発生した場合」ではなく、監視項目ごとの数値で書きます。例として、エラー率が切替前比で2倍を30分継続、誤出力の報告が1時間に5件以上、応答時間のp95が閾値超過を15分継続、決済や個人情報に関わる誤処理が1件でも発生、のように定義します。
同時に「発動基準に達したら自動的に戻す」のか「基準到達で判定会議を招集する」のかを決めてください。深夜切替で判定者が捕まらない事態を避けるため、基準到達時の連絡順序と、連絡がつかない場合の代理権限者まで手順書に書きます。
ロールバック可能条件を検収前に確認する
ロールバックは「やると決めれば必ずできる」作業ではありません。切替時にデータベーススキーマを変更した場合や、新システムで書き込まれたデータが旧システムと非互換の場合、単純な切り戻しはデータ欠損を生みます。検収前に、ロールバック手順書に次の3点が含まれているかを確認してください。
第一に、切替後に発生したデータの扱い(旧システムへ再取込するか、切替時点まで巻き戻すか)。第二に、ロールバックの制限時間(切替後何時間まで単純切り戻しが可能か)。第三に、リハーサル実績(本番相当環境でロールバックまで通しで演習したか)です。リハーサルは切替作業だけでなくロールバック側も演習対象にすることが、手順書の実効性を担保します。
段階切替とカナリアリリースの選択
一括切替が怖い場合、対象部門や対象トラフィックの一部だけ新システムに流す段階切替(カナリアリリース)が選べます。AIシステムでは、新旧を並行稼働させて出力を比較するシャドー運用も有効です。ただし段階切替は移行期間中の二重運用コスト(両システムの保守費、データ同期)が発生するため、切替リスクと二重運用費のどちらを取るかは金額で比較して決めます。並行期間は目安として2-4週間に区切り、延長判断もGo/No-Go形式で行ってください。
実務チェックリスト
- 切替計画の5役割(判定・作業・監視・発動・実施)のRACIを文書化したか
- ロールバック発動の最終責任を発注側業務責任者に置いたか
- 発動基準を監視項目ごとの数値で定義したか
- 基準到達時の連絡順序と代理権限者を決めたか
- 切替後データの扱いとロールバック制限時間を手順書に書いたか
- ロールバックを含む切替リハーサルを本番相当環境で実施したか
- 切替失敗時の業務側代替運用手順を業務部門が確認したか
- 段階切替の場合、並行期間と延長判定のルールを決めたか
図解で確認するポイント
この記事の画像は、旧システムから新システムへの切替経路と、監視ポイントを経由して戻る切り戻し経路を文字なしで図解しています。前進経路と後退経路の両方が事前に設計されていることが安全な切替の条件です。
AllAI内での次の行動
切替前後の引き継ぎ項目は本番引き継ぎチェックリスト、監視設計はAI開発のログ監視設計ガイド、切替後のKPI確認はリリース後KPIレビューガイドが続きのテーマです。これから発注する場合はAI発注診断で切替要件まで整理し、AI開発パートナーで移行実績のある会社を比較してください。
FAQ
Q. ロールバック発動を発注側が持つと、技術判断ができず遅れませんか? A. 発動の「判断材料」はベンダーの監視報告に依存して構いません。重要なのは、業務影響を受ける側が最終決定権を持つことです。数値基準を事前に決めておけば、技術的知見がなくても判断は数秒で済みます。
Q. 切替失敗時の費用はどちらが負担しますか? A. 原因によります。手順書どおり実施して環境要因で失敗した場合と、ベンダーの作業ミスの場合を分け、後者の再切替費用はベンダー負担と契約に書くのが標準です。この切り分けのためにも作業ログの保全が必要です。
Q. AIモデルだけの入れ替え(モデル更新)でも同じ体制が必要ですか? A. 縮小版が必要です。モデル更新は業務システム全体の切替より軽い一方、出力品質の変動は起きやすいため、発動基準つきの監視期間と旧モデルへの即時切り戻し手段は常設にしておくと運用が安定します。
Q. リハーサルは何回やるべきですか? A. 最低1回、切替とロールバックを通しで実施します。1回目で手順書の不備が必ず見つかるため、修正後にもう1回やるのが理想です。リハーサルの指摘事項と修正履歴はGo/No-Go判定の材料として提出させてください。
出典と確認日
- IPA「情報システム・モデル取引・契約書」: https://www.ipa.go.jp/digital/model/index.html (確認日: 2026-07-10)
- 経済産業省「AI事業者ガイドライン(第1.2版)」: https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/20260331_report.html (確認日: 2026-07-10)
- IPA「システム再構築を成功に導くユーザガイド」: https://www.ipa.go.jp/archive/publish/qv6pgp0000000wo6-att/000059184.pdf (確認日: 2026-07-10)
- NIST「AI Risk Management Framework」: https://www.nist.gov/itl/ai-risk-management-framework (確認日: 2026-07-10)
関連する記事・ガイド
- AI開発会社ガイドBest-of-N: OpusAI開発 本番KPI未達時の契約見直し会議
AIシステムの本番KPIが未達のとき、事業責任者・PM・調達が開く契約見直し会議の論点、証跡、判断、費用の見方を整理します。
- AI開発会社ガイドBest-of-N: OpusAI開発 検収後クレームの紛争証跡ワークフロー
AI受託開発の検収後にクレームや紛争が起きたとき、法務・PM・経理が証跡を整理するワークフロー、紛争段階、費用の見方を整理します。
- AI開発会社ガイドBest-of-N: OpusAI開発 障害時ベンダー連絡のエスカレーション表
AIシステムの障害時に、運用・情シス・ベンダーが使うエスカレーション表の作り方、連絡基準、証跡、費用の見方を整理します。
- AI開発会社ガイドBest-of-N: OpusAI開発 運用マニュアル検収の版管理
AI受託開発で納品される運用マニュアルを、運用・品質保証・情シスが検収し版管理する手順、確認項目、証跡、費用の見方を整理します。