AIマイグレーションの進め方。数十万行のシステムを一括変換せず、分割と並行処理で移行する手順

「数十万行のシステムを、AIは一度に変換するのですか」「一度指示すれば、あとは自動で移行が終わるのですか」。AIマイグレーションのご相談でよくいただく質問です。

答えはどちらも「いいえ」です。AIマイグレーションは、システム全体をAIに渡して待てば新しいシステムが出てくる、という手法ではありません。システムを作業単位に分割し、単位ごとに変換と検証を繰り返し、人のレビューを経て統合していく進め方です。以下では、当社が約25万行の基幹システムを移行したときの手順に沿って、分割の基準から本番切替の手前までを順に追います。

一括変換にならない理由

生成AIをはじめとするAIが一度に読み取れる文章の量には上限があります。数十万行のソースコードをそのまま渡すことはできません。仮に読み込めたとしても、ある画面の処理がどの共通部品を呼び、どのテーブルを更新し、どのバッチに影響するのかという依存関係を追いながら、変換と検証を体系的に回す必要があります。汎用のAIツールにコードを貼り付けて書き換えさせる方法が大規模システムで通用しないのは、この構造を扱えないからです。

変換した結果をどう確かめるか、という問題もあります。移行では、移行前と移行後で同じ動作をすることを、実際に動かして比較する必要があります。そのためには、比較する範囲を独立して実行できる大きさに切り分けておかなければなりません。数十万行を一気に変換して最後にまとめて動作確認する進め方では、差異が見つかったときにどこが原因かを切り分けられず、修正のたびに全体を確認し直すことになります。

そのため当社では、コードを解析して仕様を整理し、変換して動かし、新旧の結果を比べて修正し、再テストする、という一連の作業を作業単位ごとに何度も繰り返します。自動化されているのは、この繰り返しの中の各作業です。どこで切るか、差異をどう扱うか、いつ統合するかといった工程をまたぐ判断は、人が行います。

棚卸しと作業単位への分割

最初に行うのは、システムの棚卸しです。画面、機能、API、バッチ処理、帳票を一覧にし、それぞれがどの共通部品やテーブルに依存しているかを把握します。設計書が残っていれば参照しますが、当社では設計書の有無にかかわらず、AIがソースコードとデータベース構造を解析して一覧と依存関係を抽出します。設計書と現物のコードが食い違っていることが多く、コードから起こしたほうが正確だからです。仕様書がない場合の解析の進め方は仕様書がないシステムはAIで移行できる？で解説しています。

棚卸しの結果をもとに、システムを作業単位に分割します。分割の基準は、独立して変換と検証ができることです。多くの業務システムでは、認証やログ出力、データベースアクセスといった共通部品を基盤として、マスタ管理、受注や出荷などの業務機能、月次のバッチ処理が構築されています。共通部品は多くの機能から呼ばれるため、先に移行して土台を固めます。業務機能は、画面と、その画面から呼ばれる処理やAPIをひとまとまりにして切り出します。バッチ処理は、参照するテーブルを更新する業務機能の後に進めます。ただし、外部から受け取ったデータをマスタに取り込むバッチのように、画面側がその結果を前提にしているものは先に進めます。順番を決める手がかりは、データがどの処理からどの処理へ流れるかです。

このとき、ログや利用実績から、もう使われていない画面や機能を洗い出し、移行対象から外すことも同時に行います。長年運用されたシステムではこうした機能が残っているケースが多いので、対象を減らせば、費用と期間はその分だけ小さくなります。ただし、決算や年次の更新のように年に一度しか動かない処理は、数か月分のログには現れません。ログに出てこないことだけを理由に外さず、業務担当者の方に確認してから対象を決めます。

※実案件のものではなく、当社で作成したサンプル資料です。

作業単位の一覧は、そのまま進捗管理の単位にもなります。どの単位が変換中で、どの単位が新旧比較まで済み、どの単位が統合されたのかを、お客様と共有しながら進めます。

作業単位の数と大きさは、システムの構成によって変わります。共通部品への依存が整理されているシステムは細かく切れますが、ひとつの処理が数千行に膨らみ、画面と業務ロジックとデータベース操作が混ざっているシステムでは、単位を大きく取らざるを得ません。この違いは費用と期間に直接影響します。規模と難易度の測り方はマイグレーションの見積方法で解説しています。

並行処理と統合の流れ

作業単位ごとに独立した環境を用意し、並行して処理します。各単位の中では、AIが変換したコードを動かして新旧の結果を比べ、差異があれば修正して再テストする作業を、差異がなくなるまで繰り返します。環境が単位ごとに分かれているため、ある単位で差異が見つかって修正している間も、他の単位の作業は止まりません。

単位ごとの作業が終わると、人がレビューします。ここで見るのは、AIが抽出した確認事項です。新旧比較で差異が残った箇所のうち、現行の不具合をそのまま再現するのか、正式な仕様として整理するのか、移行を機に修正するのかは、コードからは判断できません。この判断はお客様の業務担当者に確認して確定します。

レビューを通った単位から統合していきます。統合後には、単位の中では確認できない部分を全体テストで確かめます。主に見るのは、画面をまたいでデータが正しく引き継がれるか、業務機能で登録したデータをバッチ処理が正しく扱えるか、統合後のデータに矛盾がないかです。すべての単位が統合され、全体テストを通った時点で、本番切替の判定に進みます。

並行処理の効果は期間に表れます。単位を順番に処理すれば単位の数だけ時間がかかりますが、並行して処理すれば、全体の期間はもっとも大きな単位の処理と統合後の全体テストでほぼ決まります。約25万行の基幹システムを、従来手法の見積と比べて金額・工期を約60%削減して移行できた背景には、AIによる各作業の高速化と、単位を並行して進められることの2つがあります。

繰り返しの中でAIと人が担う工程

どの工程でも、手を動かす作業はAIが受け持ち、その結果をどう扱うかは人が決めます。

人の作業のうち、判断の重さが最も大きいのは「差異が不具合か仕様か」です。再現するか直すかは、業務を知る人にしか決められません。判断の進め方は仕様書がないシステムはAIで移行できる？の「不具合か仕様かの判断の進め方」で解説しています。

AIでうまく変換できない箇所の扱いも、人が決めます。まず原因を切り分け、手がかりになる情報が足りなければ追加の資料をいただき、特殊な言語仕様が原因なら変換ルールを調整します。外部の部品に依存している箇所や、実行環境を再現しにくい箇所は、その部分だけ人が方針を決めて個別に実装します。業務ルールがはっきりしない箇所は、業務担当者の方に確認してから方針を決めます。

お客様側には、現行資産へのアクセス、テスト環境の準備、主要機能と例外処理の確認、そして業務上の正解を判断できる担当者の方のご協力をお願いしています。用意していただきたいものの詳細はマイグレーションの見積方法の「見積を依頼するときに用意するもの」にまとめています。

移行中の改修への追従

移行期間中も、現行システムには業務上必要な改修が入り続けます。人手による従来の移行では、解析した時点のコードを基準に書き換えるため、途中で現行側が変わると手戻りになり、長期間の改修凍結をお願いするのが一般的でした。作業単位に分かれていれば、画面ひとつの改修なら、その画面を含む単位だけを再解析し、再変換すれば済みます。テーブル定義や共通部品に手が入る改修は、依存するすべての単位に影響するため、再変換と新旧比較の範囲もそれだけ広がります。約25万行の基幹システム移行では、改修の凍結期間を本番切替前の2週間に抑えました。凍結期間の考え方はシステムマイグレーションの期間の「移行期間中の改修凍結」で解説しています。

業務の切替方式との違い

「分割して移行する」と聞くと、段階移行を思い浮かべる方が多いと思います。段階移行は、新システムへの切替を部門や機能ごとに順番に行う方式で、ある日を境に全体を切り替える一括移行と対比されます。この記事で述べてきた分割は、あくまで開発と検証の作業を単位に分けて進める手法であり、本番の切替を一括で行うか段階的に行うかとは切り離して考える必要があります。

作業を分割して進めたシステムでも、切替は一括で行うことがあります。新旧のシステムに同じデータを持たせたまま部分的に切り替えると、データの整合性を保つ仕組みが別に必要になるためです。切替を段階的にするかどうかは、システムの構成、業務の繁忙期、切替時に許容できる停止時間から決めます。切替日の決め方はシステムマイグレーションの期間の「切替日の決め方」で解説しています。

当社の事例: 約25万行の基幹システム

この進め方は、当社が株式会社ウイズ・ワンと共同で実施した、サービス管理基幹システムの移行で実際に用いたものです。対象は約25万行、移行元はFuelPHP、移行先は最新のPHPとLaravel 12でした。マイグレーション専用に開発した独自のAIエージェントが作業単位ごとに変換と検証を繰り返し、人がレビュー、業務知識に基づく受入テスト、本番移行の判定を担いました。結果として、従来手法の見積と比べて金額・工期を約60%削減しました。プロジェクトの背景と移行の難所はFuelPHPからLaravelへの移行事例で紹介しています。

まとめ

自社のシステムでこの進め方を検討するなら、最初に確かめたいのは、認証やデータベースアクセスのような処理が共通部品にまとまっているかどうかです。まとまっていれば作業単位を細かく切れます。画面と業務ロジックとデータベース操作が混ざった大きな処理が残っていれば、その処理を含む単位が最も大きくなり、並行処理をしても全体の期間はその単位で決まります。

もうひとつは、差異が不具合か仕様かを判断できる業務担当者の方に、移行期間中どれだけ時間を割いていただけるかです。この判断が済まない単位は統合に進めないため、担当の方の予定は、作業単位の計画を立てる段階で押さえておくことをお勧めします。

自社のシステムをどう分割でき、どのくらいの単位数になるかは、実際のコードを解析すれば見えてきます。DEN-NOのAIマイグレーションサービスでは、NDA(秘密保持契約)を締結のうえシステム概要とソースコードの一部をお預かりし、現状リスクと移行可能性をまとめた診断レポートと概算費用を無料でご提示しています。設計書と現物のコードが食い違っていることも多いため、仕様書・設計書のご準備は必須ではありません。お手元にない場合も、そのままご相談ください。

AIマイグレーションサービスの詳細はこちら

よくある質問

Q. 数万行程度の小さなシステムでも、分割して進めるのですか？

規模にかかわらず作業単位に分けて進めます。小さなシステムでは単位の数が少なく、並行処理による期間短縮よりも、差異が出たときに原因を切り分けやすいことが分割の主な目的になります。

Q. 単位ごとに並行して変換すると、コードの書き方がばらつきませんか？

移行先の規約と変換の方針を先に決め、すべての単位に同じ方針を適用します。共通部品を先に移行して土台を揃えること、統合後の全体テストと人のレビューで確認することで、ばらつきを抑えます。

Q. 本番移行に進む前に、この進め方で本当にうまくいくかを確かめられますか？

事前検証(PoC)で一部の作業単位を実際に変換し、新旧で主要な機能が一致するか、AIだけでは難しい範囲がどこか、本番の期間と費用を見積もれるかを確認してから、本番移行に進むかを判断できます。PoCで確認する項目はマイグレーションの見積方法の「PoCによる見積の確定」で解説しています。

Q. 移行費用は行数だけで決まるのですか？

行数は指標のひとつです。作業単位にどれだけ細かく分けられるか、共通部品への依存がどれだけ整理されているか、外部連携や特殊な部品があるかによって、同じ行数でも工数は変わります。規模別の相場観はシステムマイグレーションの費用相場にまとめています。