業務を止めずに新システムへ移行するには？

新システムが実力を証明するまで旧システムを止めなければ、業務を止めずに移行できます。両方に同じ実際の取引を処理させて出力を比べ、業務責任者が挙げるまれなケースをテストし、各モジュールの本番投入前に人による承認を必須とし、旧システムをいつでも切り戻せる状態に保ちます。マイクロソフトは移行実行ガイドで、移行後の最初の 24 時間から 48 時間は新システムを監視し、安定化期間中は移行元環境を切り戻し先として残すよう推奨しています。

第 5 回では、システムごとに進め方を選びました。今回は、ダウンタイムなしのレガシーシステム刷新で解説した一般的な移行手順は繰り返しません。新しい点に絞ります。つまり、新しいコードを AI が書いた、または変換した場合に何をテストすべきかです。

AI が変換したコードに別のテストが必要な理由

変換ツールが生成したコードは整っていて、最初から動きます。だからこそ誤りが見えにくいのです。誤りは日常の処理ではなく、月に一度や年に一度しか起きないケースで表面化します。アマゾンはメインフレームアプリケーション変換ガイドで、COBOL から Java への最初の変換では同じ動作を保ち、その後 Reforge という手順で大規模言語モデルを使ってコードを現代的な Java の書き方に作り替えると説明しています。COBOL は今も多くの銀行システムやメインフレームで動いている古いプログラミング言語で、メインフレームとは大組織の基幹システムが動く大型の中央サーバーのことです。

コードを書き直す手順は、どれも小さな点を変えてしまう可能性があります。ですから、開発者が新しいコードを読んで正しそうだと言うだけでは足りません。経営側の問いはひとつです。同じデータで、新システムは旧システムと同じ結果を出すのか。その答えはコードを読むことではなく、出力を比べることで得られます。

同じ実際の取引で出力を比べる

締めが終わった月など、業務上すでに確定した期間を選び、その取引を新システムに通して、旧システムが出した結果と比べます。比べる対象は次のとおりです。

• 最終的な数字：期末時点の請求合計、残高、在庫。
• レポート：経営陣が頼りにしている月次レポートを 一行ずつ。
• 他システムへ送るもの：銀行、経理、行政ポータルへ送るファイルやメッセージ。
• 拒否とエラー：旧システムが拒否する取引は、新システムも同じ理由で拒否しなければなりません。

ツールは準備を助けるもので、判断を下すものではありません。たとえばメインフレーム向けの AWS Transform は、コードの属性、ジョブの複雑さ、スケジューラーの経路からテスト計画を 3 つの段階（設定、範囲の決定、レビュー）で作成し、続いてメインフレームからテストデータを集めるスクリプトを 4 つの段階で生成します。ただしアマゾンは同じガイドで、これらのスクリプトは自社のメインフレーム上で、自社チームの権限で実行する必要があると注意しています。ツールが準備し、実行と判断はチームが担います。データそのものの検証について、マイクロソフトは簡易チェックとして行数の比較を、より深いチェックとしてチェックサムの比較を勧めています。チェックサムとは、データから計算される数値で、一文字でも変われば値が変わるものです。

まれなケースは、それを知る人に聞く

一か月分の実際の取引には、すべてのケースが含まれるわけではありません。システムを壊すケースを知っているのは開発者ではなく業務責任者です。期末の決算、古い請求書に対する一部返品、特別価格の顧客、計上後に取り消された請求書、月の途中で入社した社員の給与などです。業務責任者それぞれに気がかりなケースを書き出してもらい、ひとつずつ、実行前に期待結果を書いたテストに変えていきます。

ここで第 4 回で確認したルールが生きてきます。確認済みのルールは、それぞれ少なくとも一つのテストケースになります。テストのないルールは、変換を生き残ったかどうか言えないルールです。テストの種類そのものについては、ソフトウェアテストと品質保証のガイドをご覧ください。

モジュールごとに人が承認する

この原則の公開事例として最もわかりやすいのは、Thought Machine が 2026 年 9 月 29 日にアマゾンと共同で発表した銀行システム移行の仕組みです。4 つの段階で進みます。AWS Transform でレガシーアプリケーションから業務ロジックを抽出し、重複したバリエーションを統一された仕様にまとめ、AI エージェントで新しい金融商品とテスト一式を生成し、最後の検証段階では、何かを受け入れる前に銀行のエンジニアリングチームとリスクチームに明確な承認権限を与えます。承認後も、成果物はすぐに本番へ入るのではなく、追加評価のために隔離されたサンドボックス環境へ送られます。

この教訓は、銀行やアマゾンでなくても使えます。請求、給与、在庫など、システムの各モジュールは本番投入前に 二つの署名を得ます。一つは技術側から、すべてのテストを実施したことの確認。もう一つは業務責任者から、結果が業務上正しいことの確認です。マイクロソフトも移行後に同じことを求めています。アプリケーションの責任者が、主要な機能がすべて正しく動くことを確認するのです。

並行稼働と切り戻し計画

並行稼働とは、旧システムを正式な基準としたまま、両システムを一定期間並べて動かすことです。始める前に、その期間をいつ終えるのか、どんな条件で終えてよいのかを決めておきます。たとえば業務の 一サイクル全体で結果が一致することです。そのうえで移行を次のように組み立てます。

切り戻し計画は失敗を認めるものではなく、保険です。請求書の誤りや主要プロセスの停止など、何が起きたら戻すのか、誰がその判断を下すのか、ユーザーをどう旧システムに戻すのかを事前に書いておきます。安定化期間が終わるまで、旧システムを完全に止めてはいけません。移行後の最初の数週間によく起きる問題は、移行後の最初の三十日で解説しています。

Origami の視点

私たちは移行を技術的な出来事ではなく、経営の判断として扱います。そのため、新システムそのものを作る前に両システムを比較する仕組みを作り、まれなケースとその期待結果を早い段階で業務責任者と合意します。こうして、誰かが結果を見る前に成功の基準が書面で決まっている状態にします。

変換の高速化やテストの生成には AI を使いますが、各モジュールの承認は御社チームの名前のある担当者が行います。私たちの進め方は、サービス紹介をご覧ください。

今週の演習：モジュールごとの移行シート

第 5 回で変換または再構築を選んだシステムごとに、移行日を決める前に業務責任者と一緒にこのシートを埋めてください。

これは説明用の例で、御社のシートは異なるはずです。大切なのは、すべてのモジュールに名前のある承認者 二名と書面の切り戻し条件がそろうまで、移行日を決めないことです。

次回

最後に残るのは、コードとデータを AI ツールに渡す前に、どの経営者も問う疑問です。刷新の間、自社のデータはどこへ行くのか。最終回の第 7 回ではこの問いに答え、シリーズ全体の演習を 90 日計画にまとめます。

出典

• マイクロソフト：移行の実行（クラウド導入フレームワーク） — 切り戻し基準の会議、変更凍結、データ検証、24 時間から 48 時間の監視、移行元環境の保持。
• アマゾン：AWS Transform によるメインフレームアプリケーションの変換 — テスト計画、テストデータ収集スクリプト、Reforge の手順。
• アマゾン：Thought Machine と AWS による銀行レガシー移行の発表 — 4 つの段階と、エンジニアリングチームおよびリスクチームによる承認。
• AWS Transform：公式ページ。