移行当日の段取りを机の上で書き出しながら、順番と戻し方を静かに確かめている開発者
設計・レビューでのAI活用約17分

AIにデータ移行・マイグレーション計画を立てさせる｜手戻りを防ぐ確認

「来月、旧システムからデータを移します。手順、まとめておいて」

そう言われた日から、移行の週末が近づくたびに胃のあたりが重くなる。この感じ、覚えのある方は多いと思います。機能開発なら、間違えても直せばいい。でも移行は違います。やり直しがきかない一発勝負のように見えるし、実際、失敗すれば止まるのは自分のコードではなく、お客さんの業務のほうです。

だから、AIに「データ移行の計画を立てて」と頼んでみる。すると、それらしい手順書がすぐ出てきます。事前準備、バックアップ、移行実行、検証、切り戻し。項目はきれいに並んでいて、抜けがあるようにも見えない。

でも、それを持って当日を迎えるのが怖い。 その感覚は正しいです。AIが出した計画書は、あなたのデータを一度も見ていません。見ていないものについて、それらしい章立てだけが返ってきている。怖いと感じるのは、あなたが慎重だからであって、準備不足だからではありません。

結論：AIにデータ移行を任せるときは、計画の「骨格」はAIに、判断は人にと分けると事故が減ります。具体的には、①移行元の実データを先に調べ、その結果をAIに渡す（調べていない前提で立てた計画は必ずずれます）。②「戻せるか」を最初に決める——切り戻しの手順が書けない移行は、当日どれだけ祈っても安全になりません。③リハーサルを本番相当のデータで1回やる（件数と所要時間が読めるのはここだけです）。④移行後の照合を「件数・合計・抜き取り」の3点に決めておく。⑤当日の判断基準（何時までに終わらなければ戻すか）を、事前に文章にしておく。

一度に全部やらなくて大丈夫です。今日は、移行対象のテーブルを1つ選んで、件数と、NULLがどれくらい入っているかを数えるだけでも十分です。その数字が1つあるだけで、AIから返ってくる計画の中身が変わります。

なぜAIの移行計画は「きれいなのに使えない」のか

まず、いま何が起きているのかを整理させてください。

AIが移行計画を出すとき、持っていない情報が3つあります。あなたのデータが実際どうなっているか。止められる時間はどれくらいか。失敗したとき誰が何を判断するか。 この3つがないと、AIは世の中の一般的な移行手順を、教科書どおりに並べます。それは間違いではありません。前提のない場所では、それが唯一書けるものだからです。

そして実務でつまずくのは、いつもその教科書に載っていないところです。

どれも、AIの能力の問題ではありません。人間の先輩に「移行手順まとめといて」とだけ頼んでも、同じくらい一般的なものが返ってきます。ずれているのは、渡している前提のほうです。

だから直す場所は、AIの出した計画書そのものではありません。渡す材料と、確認する順番です。

① 実データを先に調べて、その結果を渡す

移行計画で最初にやる作業は、手順を書くことではありません。移行元のデータを見ることです。ここを飛ばして書いた計画は、当日ほぼ必ず修正が入ります。

調べるのは、難しいことではありません。SQLを数本流すだけです。何を数えればいいか分からないときは、AIに「このテーブル定義に対して、移行前に確認すべきデータの偏りを調べるSQLを出して」と頼むと、候補がすぐ出ます。探す作業はAIが得意で、結果を読むのは人がやる——この分け方が、移行では特によく効きます。

最低限、この5つは数えておきたいところです。

出てきた数字を、そのままAIに渡します。「件数は約42万件、うち email がNULLのものが1,203件、重複が58件」——この一行があるだけで、返ってくる計画は「NULLと重複をどう扱うか」から始まるものに変わります。

そして、ここでいちばん大事な問いが出ます。その1,203件、どうしますか。

これは技術の問題ではなく、業務の問題です。移さない、仮の値を入れる、移行対象から外して別途手作業、いずれも「システムとしては」ありえます。決められるのは、そのデータを使っている人だけです。AIに決めさせないでください。AIは聞かれれば必ず何か答えますが、その答えに責任を持てるのは業務側の人だけです。

聞き方としては、こんな形が通りやすいです。

「移行対象のうち、メールアドレスが未登録のお客様が1,203件あります。新システムはメールアドレスが必須の作りなので、このままだと移せません。（A）仮の値を入れて移す（B）移さずリストで渡す、のどちらがよいでしょうか。件数が多くないので、（B）でも運用は回りそうです」

選択肢を2つに絞って、こちらの推奨を添える。 これだけで、返事が来るまでの時間がかなり変わります。判断が必要な論点の洗い出し自体は、AIを設計の壁打ち相手にする｜問いの立て方の型のやり方が使えます。

② 「戻せるか」を、手順を書く前に決める

移行計画で二番目に決めるのは、実行手順ではなく戻し方です。順番が逆に感じるかもしれませんが、こちらが先です。

理由は単純で、戻せない移行は、当日どれだけ慎重にやっても安全にならないからです。逆に、戻せると分かっていれば、当日の判断はぐっと楽になります。「うまくいかなければ戻せばいい」と思えているかどうかで、深夜の頭の働き方はまるで違います。

決めておきたいのは、この3つです。

どこまで戻すのか。 データだけ戻せばいいのか、アプリのバージョンも戻すのか、両方戻すのか。新旧が別のデータベースなら「新しい側を消してやり直す」で済むことも多いですが、同じデータベースを作り変える移行は、戻すのがぐっと難しくなります。この違いは、計画の最初に確認する価値があります。

戻すのに何分かかるのか。 ここが抜けやすいところです。「バックアップから戻す」と一行書いてあっても、42万件のリストアに何分かかるか測っていなければ、その手順は当日使えません。戻す作業も、リハーサルで一度は時間を測っておきます。

誰が「戻す」と言うのか。 これは技術ではなく体制の話です。当日その場にいる人のうち、誰が最終判断をするのか。連絡がつかないときは誰が代わるのか。名前で決めておきます。役割で書くと、当日「それ、私ですか？」が起きます。

あわせて、移行の前にバックアップを取ったことを、取った本人以外が確認する手順も入れておきましょう。「取ったつもり」で当日を迎えるのは、いちばん避けたい形です。ファイルのサイズと件数を見て、実際に別の場所へ戻せることを一度試しておくと、確実です。バックアップは、取った時点ではまだ半分しか終わっていません。

③ 本番相当のデータで、リハーサルを1回やる

計画書の中でいちばん当てにならないのが、所要時間の見積もりです。そしてこれは、AIには絶対に出せません。あなたのサーバーの性能も、ネットワークも、その日の混み具合も知らないからです。

だから、1回やってみます。

リハーサルの結果が出たら、それをAIに渡してもう一度計画を見直させると効きます。「投入に3時間20分かかった。止められるのは4時間。この条件で、危ないところと短縮の余地を挙げて」——測った数字を渡した後のAIは、急に役に立ちます。

なお、リハーサル用の変換スクリプトや検証SQLを書かせるのは、AIの得意分野です。ただし、そのSQLが本当に意図どおりかは人が読みます（AIに書かせたSQLの確認ポイント｜N+1・インデックス漏れ）。移行のSQLは、間違っていても静かに通ってしまうのが怖いところです。

もし時間が取れず、リハーサルが1回しかできないなら、その1回は「本番と同じ時間帯」にやるのがおすすめです。深夜バッチや他システムの処理と重なっているかどうかが、そこで分かります。

④ 移行後の照合を「件数・合計・抜き取り」に決めておく

移行が終わった直後、何を見れば「成功した」と言えるのか。これを当日その場で考え始めると、たいてい時間が足りません。事前に決めておきます。

おすすめは、次の3点セットです。多すぎず、少なすぎず、ほとんどの移行事故がこの3つのどれかに引っかかります。

移行の前と後を突き合わせる3つの確認方法（件数をそろえる・合計をそろえる・一部を抜き出して中身を見比べる）を横に並べた図
全件を目で見るのは無理。この3点だけ決めておけば、当日迷わずに済みます

件数：テーブルごとに、移行前と移行後のレコード数が一致するか。意図的に除外した分があるなら、その数を引いて合うか。合わないときは、必ず理由を数字で説明できるまで先へ進まない——これが移行のいちばん基本的な守りです。

合計：金額・数量など、足し算できる列の合計を突き合わせます。件数が合っていても、値が壊れていれば合計はずれます。桁が飛ぶ、小数が丸められる、マイナスが消えるといった変換ミスは、ここで一番よく捕まります。

抜き取り：ランダムに数十件を選んで、移行前と後で中身を並べて見ます。ここで見るのは、機械では気づけないところです。文字化けしていないか。日付が1日ずれていないか。全角と半角が入れ替わっていないか。古いレコードほど怪しいので、最古と最新を必ず1件ずつ入れるのがコツです。

3つとも、SQLを事前に書いて、リハーサルで一度動かしておきます。当日その場で書くと、書き間違えたSQLの結果を見て青ざめる、という無駄な30分が発生します。

そして忘れがちなのが、移行後の画面を人が触ることです。データが正しく入っていても、新しいシステムで一覧が出ない、検索が引っかからない、印刷が崩れる、ということはあります。業務でいちばんよく使う画面を3つだけ決めて、当日それを開く。この3つは、開発者ではなく業務の人に選んでもらうと、外しません。

⑤ 当日の判断基準を、事前に文章にしておく

最後に、いちばん抜けやすくて、いちばん効くものを。「何時になっても終わらなかったら戻す」という基準を、当日より前に文章で決めておくことです。

当日の深夜、想定の1.5倍時間がかかっているとき、その場で冷静に判断するのはとても難しいです。ここまで来たんだから、あと少しで終わるはず——そう思いたくなるのが人間です。そして、そこから先が伸びたときに、いちばん大きな事故になります。

だから、疲れていない今日の自分が、当日の自分のために決めておきます。

書き方は、これくらいで十分です。

【当日の判断基準】
- 業務停止の開始：土 22:00
- 業務再開の約束：日 06:00
- 判断ポイント①：日 01:00 時点でデータ投入が終わっていなければ、切り戻しを開始する
- 判断ポイント②：日 03:00 時点で検証が終わっていなければ、内容にかかわらず切り戻す
- 切り戻しの所要：約50分（リハーサル実測。最大でも90分を見込む）
- 判断する人：<氏名>（連絡がつかない場合は<氏名>）
- 切り戻した場合の連絡先と文面：別紙のとおり（事前に用意しておく）

ポイントは、判断ポイントの時刻を「作業が終わる時刻」ではなく「戻し始めても間に合う時刻」から逆算することです。再開が06:00で、戻すのに最大90分なら、04:30が最終ラインです。安全を見て03:00に置いておく。この引き算を、当日ではなく今日やっておきます。

そして、切り戻したときの連絡文面も、先に書いておく。これがあるだけで、当日の心理的な重さがずいぶん違います。「戻す」が失敗ではなく、あらかじめ用意された選択肢のひとつになるからです。

段階的に切り替えられる作りにできるなら、それも有効な選択肢です（AI機能を本番に出すのが怖い｜機能フラグと段階リリースの型）。一部の利用者から新システムに移す、旧システムを読み取り専用で残しておく、といった形が取れると、当日の全か無かが避けられます。

AIに渡す前提の文例

計画を書かせる前に、これくらい添えるだけで返ってくるものが変わります。コピーして、<> の中だけ埋めてください。

前提：
- 移行元：<システム名/DB種別・バージョン>、移行先：<システム名/DB種別・バージョン>
- 対象テーブルと件数：<users 42万件、orders 380万件、…>
- 実データの状況：<users.email が NULL 1,203件／重複58件、orders.memo に改行あり、…>
- 業務を止められる時間：<土22:00〜日06:00の8時間>。これを超えられない。
- 新旧は<別のDB/同じDBを作り変える>。旧システムは移行後<1か月読み取り専用で残す/即停止する>。
- 移行は<一括/期間を分けて複数回>で行う。
- 切り戻しの想定：<新DBを破棄して旧を再開/バックアップからリストア>。
- 使えるツール：<標準のダンプ/自作スクリプト（言語・バージョン）>。新規ツールの導入は不可。

依頼：
1. 上記の前提で、当日のタイムラインを工程ごとに（各工程に「戻せるかどうか」を明記して）出す。
2. この前提で「まだ決まっていないこと・確認が必要なこと」を、質問の形で挙げる。
3. 所要時間は書かなくてよい（こちらで実測する）。

2番目の「まだ決まっていないことを質問の形で挙げて」が、実はいちばん価値があります。 きれいな手順書より、「これ決まってましたっけ？」の一覧のほうが、移行では役に立ちます。そして3番目——所要時間をAIに書かせないこと。書かせると、それらしい数字が入ってしまい、測っていない数字が計画書の中で独り歩きします。

AIの出力に含まれる数字を鵜呑みにしない話は、AIのハルシネーションの見抜き方｜開発現場で気づく型にもまとめています。移行計画の所要時間は、その典型例です。

明日やること（小さく3つ）

全部を一度にやろうとすると重いので、まずこの3つから。

  1. 移行対象のテーブルを1つ選んで、件数とNULLの数を数える。数字が1つあるだけで、計画の解像度が変わります。
  2. 「戻すのに何分かかるか」を調べる。分からなければ、それが今いちばん先に埋めるべき穴です。
  3. 当日の判断ポイントの時刻を、紙に1行書く。「◯時に終わっていなければ戻す」。これだけで、当日の自分がずいぶん助かります。

チェックリスト（コピーして使えます）

AIに立てさせた移行計画をレビューするときの確認項目です。一度に全部でなく、今日は使える所だけで十分です。

事前調査：

戻し方：

リハーサル：

移行後の照合：

当日の段取り：

最後に

データ移行が重いのは、腕の問題ではありません。やり直しがきかないように見えるという、この仕事の性質そのものが重いのです。だから怖い。何度やっても、前日はよく眠れない。

でも、移行の怖さのほとんどは、「戻せるか分からない」ことから来ています。逆に言えば、戻せると分かった瞬間に、その重さの半分は下ろせます。今日やることは、完璧な計画を書き上げることではなく、「うまくいかなかったらここまで戻る」を一本決めておくことです。

移行が無事に終わった朝、旧システムの資料を片づけながら開発者と業務担当者が穏やかに一息ついている場面

AIは、その一本を決めてはくれません。でも、調べるSQLを書いてくれるし、抜けている論点を並べてくれるし、あなたが測った数字を渡せば、そこから先の段取りを一緒に考えてくれます。決めるところと、任せるところ。この線を引けたなら、もう計画は半分できています。

今日は、テーブルを1つ選んで件数を数えるところから。数字が1つ手元にあるだけで、次の相談はずいぶん具体的になります。焦らず、一つずつでいきましょう。

よければ、こちらも

関連用語