メインコンテンツにスキップ
自媒科技企業向けAI・開発から導入まで
日本語JA
プロジェクト相談
プロジェクト相談

企業AIプロジェクトWiki · 環境・バージョン・リリース

ロールバック

別名Rollback · Version Rollback · Deployment Rollback · 切り戻し

定義

ロールバックとは、変更によって許容できない結果が生じた後、事前に定めた順序で新たな統制変更を実行し、影響を受けたComponentを既知の正常・検証済み・互換状態へ戻し、変更期間中に生じたDataと外部影響を照合する過程です。旧Processの起動ではなく、Service、Data、権限、業務Flow、観測指標が規定の復旧状態に達した時に完了します。

ロールバック自体も一つの変更

信頼できるロールバックは、新Versionを削除したりLabelを `previous` へ向けたりするだけではありません。Delivery Systemでは通常、以前のLast Known Good Releaseを選び、それを同じTargetへ配備する新しいRolloutを作ります。これにより実行、承認、検証の新規記録を残し、前回配備後の環境変化も扱えます。

直前Versionが正しいTargetとは限りません。現在のRegion、Database状態、設定で正常稼働したことがない、または既に修正済みのSecurity問題を含む場合があります。明確なVersionと完全な設定Baselineを選び、変更後に書かれたDataを読めるか確認します。

PlatformのRollback範囲は限定的です。Kubernetes Deployment Revisionが主に保持するのはPod Templateであり、そのUndoはDatabase、外部設定、Secret値、Message、File、実行済み第三者Callを自動復元しません。Platform操作と業務復旧を分けて設計します。

変更前に作る実行可能なRollback Contract

  1. Triggerを定義する

    可用性、Security、Data、業務結果について、自動停止、人手判断、必須RollbackのEventと閾値を定めます。

    Alert Rule、閾値、判定Window、例外

  2. Target Baselineを指定する

    戻すApplication Artifact、設定Snapshot、Infrastructure Version、DB互換点、Model、Knowledge状態を記録し、「一つ前」だけにしません。

    Manifest、Digest、Snapshot、Last Known Good記録

  3. Component別Actionを決める

    Traffic、Application、設定、Schema、Data、Queue、Cache、Schedule Job、外部依存の復旧または補償を依存順に記述します。

    Component別Rollback Matrixと依存図

  4. Data方針を定める

    Write停止、期間内の正しいTransaction保持、旧Versionの新Data読取可否、互換Migration、逆Migration、Replication、Restore、照合のどれを使うかを示します。

    Data Cut Point、RPO、Backup、照合計画

  5. 権限と責任を割り当てる

    Trigger、承認、Data操作、業務復旧確認、利用者連絡のOwnerと、自動Rollbackの実行可能範囲を定めます。

    責任表、緊急権限、Escalation

  6. 復旧目標を設定する

    影響停止、Core Service復旧、Backlog処理、完全Closeの目標時間を分け、曖昧な「早急に」にしません。

    復旧時間、業務優先度、縮退目標

  7. Rollback失敗に備える

    Rollbackが失敗または悪化した時、いつ停止し、Traffic隔離、縮退、Backup Restore、Fix Forward、Incident対応へ移るかを決めます。

    二次復旧PlanとIncident Playbook

Rollback・Pause・Withdraw・Fix Forwardの判断

対応適用する判断
拡大停止段階配備・公開の初期異常で、新Instance、Traffic、公開拡大をPauseし、現場証拠を保存します。影響制御でありRollback完了ではありません。
利用者公開のWithdrawFeature Flag、Route、権限を旧体験へ戻し、新Artifactは一時的に環境へ残します。利用者を先に保護し、技術判断の時間を作ります。
Rollback取得可能な正常Baselineが現Data・依存と互換で、手順をTest済み、継続運転や現場修正より逆戻りRiskが低い時に使います。
Fix Forward旧Versionが新Dataを読めない、外部Protocol切替済み、Rollback Window終了、または小さく確実なPatchの方が安全な時に使います。承認、Test、復旧Planは必要です。
縮退・隔離Rollback経路が不明または影響拡大中なら、高Risk機能Off、Read-only、Consumer停止、Region隔離、人工処理でCore機能を守ります。
Restore・Disaster RecoveryDataやInfrastructureが破損し旧Artifact再配備だけで戻らない時、RPO、RTO、Data Loss評価、上位権限を伴う別の復旧Processへ入ります。

Componentごとに戻し方が異なる理由

Application・Runtime Image

不変RepositoryからDigestで検証済み旧Artifactを再配備し、旧Versionが必要なRuntime、Secret、API、Dependencyの存続を確認します。

Traffic・機能状態

旧環境、旧Deployment、Flag Offへの切替は速い一方、Session固定、Cache、Long Connection、地域伝播、実行中Requestを処理します。

設定・Secret

旧Codeと新設定の組合せでは障害が続きます。不変Configuration Snapshotまたは明確な差分で戻し、漏えい・失効済みSecretを単純復元しません。

Infrastructure

IaCの管理Versionを再適用する前に、削除、置換、Address変更、Stateful Resourceへの影響を評価します。手作業で旧状態らしい構成を作りません。

Database Schema

旧Applicationが現Schemaを読める必要があります。Expand—Migrate—Contractの後方互換Stepを優先し、Field削除や意味・Format変更後の逆Migrationが安全とは仮定しません。

業務Data

Codeを戻しても期間内の正しいOrder、Approval、Payment、編集は消えません。旧Backup Restoreは正しい取引を失い得るため、Write停止、逆Replication、選択修復、補償、照合を検討します。

Queue・Job・Cache

旧Consumerが新Messageを読めず、実行中Jobが副作用を続ける場合があります。Producer/Consumer停止、Version Message処理、Cache再構築、Backlog Replayを決めます。

外部Action

送信済みMail/SMS、Payment、Ticket、File、Webhook、物理操作は技術Rollbackで消えません。実結果を記録し、取消、返金、通知などの業務補償を行います。

安全なロールバック実行手順

  1. 宣言して変更を統制する

    IncidentまたはRollback Leadを決め、無関係な配備・設定変更をFreezeし、Trigger時刻、症状、影響範囲、現状態を記録します。

  2. 新規影響を制限する

    RolloutとReleaseをPauseし、必要に応じWrite、高Risk機能、Queue Consumer、外部Actionを停止し、診断Logと証拠を保ちます。

  3. Targetと互換性を確認する

    現TargetのArtifact、設定、Schema、Data Format、Dependency、Security Fixを比較し、戻す順序、Capacity、通過済みOne-way Gateを確認します。

  4. Recovery Pointを作る

    追加変更前に現設定、DB、Queue、Traffic、Instance、重要LogのSnapshotまたはBackupを保存し、調査と二次復旧に備えます。

  5. 依存順に復元する

    互換前提とTraffic保護を先に行い、通常のDeployment経路でTarget Artifactと設定を適用します。DB、Writer、Reader、Async ComponentはProtocol互換順に扱います。

  6. 層別に検証する

    Ready、依存、Schema、Read/Write、Message、Cache、権限、重要業務Flow、外部結果をRollback前BaselineとTarget状態に比較します。

  7. 段階的にServiceを戻す

    社内または少量Trafficから復旧し、観測後に拡大します。Backlog、外部補償、利用者連絡を処理し、検証前に全負荷へ戻しません。

  8. 記録してCloseする

    各Step結果、手動偏差、Data影響、最終Baseline、残課題を残します。復旧後もRoot Cause、修正版、再Release条件をIssue化します。

復旧の証明とRollback失敗への対応

Command成功ではなく復旧を検証する

Automation完了後も、利用者Task、Data正確性、Security Control、Alert、Capacity、Backlog、外部依存を確認します。

Upgrade—Downgrade Testを行う

本番相似環境で新旧Versionを共存させ、Upgrade完了後に実順序でDowngradeします。API、Serialization、Batch、Job、依存障害を通して互換性を確認します。

観測Windowを保つ

低頻度Job、Cache失効、Async Callback、段階伝播の問題は後から現れます。System周期に合わせて観測し、別変更を同時開始しません。

Rollback中の新障害を検出する

Error、Data不整合、権限問題が増えるなら後続StepをPauseし、状態を保存して二次復旧またはFix Forwardへ移ります。

技術復旧と業務修復を分ける

Service復旧後も補填、Replay、Refund、再Index、権限再計算、顧客通知、規制Reportが残ります。個別OwnerとClose証拠を置きます。

Rollback能力を振り返る

検知、判断、開始、Core復旧、完全Closeの時刻を測り、Target、Artifact保持、権限、手順、Testを次変更のGateへ反映します。

企業AIのロールバックで追加対応すること

AIの完全な組合せを戻す

Model Route、Prompt、Guardrail、Knowledge Index、Embedding/Reranker、Tool Schema・権限、Application Orchestrationを互換Manifestへ戻します。Modelだけの切替では不足です。

Model Trafficを先に戻す

旧Deploymentを保持していればEndpoint TrafficをKnown Good Modelへ戻し、SessionとFallbackを確認後、新Deployment削除を判断します。切流は影響制御で、完全Rollbackには設定照合が残ります。

KnowledgeにAliasまたはPointerを使う

新Index検証後にAliasを切替え、観測終了まで旧Indexを保ちます。戻す時は文書増減、Tenant権限、引用、Cache、新Index期間のFeedbackを照合します。

Conversation・Memory状態をVersion管理する

旧PromptやToolが新VersionのConversation State、Memory、Planを理解できない場合があります。Schemaを識別し、互換読取、Migration、Clear、隔離を選びます。

Agent副作用を補償する

AIが送信したMessage、変更したRecord、作成したOrder、起動したWorkflowはModelを戻しても残ります。Tool権限を止め、Auditから確認・取消・修復します。

品質を再評価する

技術Metricの復旧だけでは回答品質を証明しません。Trigger Scenario、固定Evaluation、高Risk Sample、実問題でGrounding、拒否、Tool、人工引継ぎを再確認します。

Hosted Modelは元へ戻せない場合がある

Providerが固定Snapshotを提供しなければ、Aliasで旧動作を復元できません。代替Model、Route停止、縮退、人工対応、Provider Incident対応を準備します。

ロールバックと混同しやすい概念

関連概念ロールバックとの違い
Release WithdrawFlag、Route、権限、Channelで新規利用者公開を止めます。Rollbackは技術ComponentをBaselineへ戻します。Withdrawを先行または一部代替できます。
Git revertSource変更を反転する新Commitを作ります。Build、Deployment、設定・DB復元、Production Traffic切替は自動実行しません。
Backup RestoreDataやSystemをRecovery Pointへ戻し、RPO内の変更を失う場合があります。RollbackはDataを戻さず旧Artifactだけ再配備する場合があります。
Failover可用性維持のためStandby Instance、Region、Systemへ切替えます。Software Versionは同じ場合があります。
Fix Forward旧Baselineへ戻さず、現状態へ新しい修正を適用します。Rollback非互換または小Patchの方が安全な時に使います。
Disaster RecoverySite、Region、Infrastructure、広範なData喪失を扱い、単一変更Rollbackより範囲と復旧目標が大きくなります。
業務補償Order、Payment、通知など既に発生した業務結果を取消または相殺します。技術Rollbackだけでは自動実行できません。

出典と適用範囲

本項は、Software Systemへの変更が許容できない結果を生んだ後、明確な技術状態を承認済みBaselineへ戻すロールバックを扱います。ロールバックは、すべての結果を自動で逆転するButtonではありません。Application、Infrastructure、設定、Database、Traffic、Queue、Cache、Model、Knowledge、外部業務Actionは可逆性が異なります。利用者公開のWithdraw、Git revert、Backup Restore、Failover、Disaster Recovery、Fix Forwardとも同一ではありませんが、実際の対応では組み合わせる場合があります。Target、時間、Data処理、権限は変更ごとに定めます。