「数十万行のシステムを、AIは一度に変換するのですか」「一度指示すれば、あとは自動で移行が終わるのですか」。AIマイグレーションのご相談でよくいただく質問です。
答えはどちらも「いいえ」です。AIマイグレーションは、システム全体をAIに渡して待てば新しいシステムが出てくる、という手法ではありません。システムを作業単位に分割し、単位ごとに変換と検証を繰り返し、人のレビューを経て統合していく進め方です。この記事では、当社が約25万行の基幹システムを移行したときの進め方に沿って、分割の考え方、並行処理と統合の流れ、そのなかでAIと人がそれぞれ何を担うのかを解説します。
一括変換にならない理由
生成AIをはじめとするAIが一度に読み取れる文章の量には上限があります。数十万行のソースコードをそのまま渡すことはできません。仮に読み込めたとしても、ある画面の処理がどの共通部品を呼び、どのテーブルを更新し、どのバッチに影響するのかという依存関係を追いながら、変換と検証を体系的に回す必要があります。汎用のAIツールにコードを貼り付けて書き換えさせる方法が大規模システムで通用しないのは、この構造を扱えないからです。
変換した結果をどう確かめるか、という問題もあります。移行では、移行前と移行後で同じ動作をすることを、実際に動かして比較する必要があります。動かして比べるには、動かせる大きさに切り分けておく必要があります。数十万行を一気に変換して最後にまとめて動作確認する進め方では、差異が見つかったときにどこが原因かを切り分けられず、修正のたびに全体を確認し直すことになります。
そのため当社の進め方は、解析、仕様整理、変換、実行、新旧比較、修正、再テストという一連の作業を、作業単位ごとに何度も繰り返す形になります。自動化されているのは、この繰り返しの中の各作業です。どこで切るか、差異をどう扱うか、いつ統合するかといった工程をまたぐ判断は、人が行います。一度指示すれば自動で完了するのではなく、人が決めた単位と方針のなかでAIが変換と検証を繰り返す。それが実際の姿です。
棚卸しと作業単位への分割
最初に行うのは、システムの棚卸しです。画面、機能、API、バッチ処理、帳票を一覧にし、それぞれがどの共通部品やテーブルに依存しているかを把握します。設計書が残っていれば参照しますが、当社では設計書の有無にかかわらず、AIがソースコードとデータベース構造から一覧と依存関係を起こします。設計書と現物のコードが食い違っていることが多く、コードから起こしたほうが正確だからです。仕様書がない場合の解析の進め方は仕様書がないシステムはAIで移行できる？で解説しています。
棚卸しの結果をもとに、システムを作業単位に分割します。分割の基準は、独立して変換と検証ができることです。多くの業務システムでは、認証やログ出力、データベースアクセスといった共通部品の上に、マスタ管理、受注や出荷などの業務機能、月次のバッチ処理が乗っています。共通部品は多くの機能から呼ばれるため、先に移行して土台を固めます。業務機能は、画面と、その画面から呼ばれる処理やAPIをひとまとまりにして切り出します。バッチ処理は、参照するテーブルを更新する機能の後に回します。
このとき、ログや利用実績から、もう使われていない画面や機能を洗い出し、移行対象から外すことも同時に行います。長年運用されたシステムではこうした機能が残っているケースが多いので、対象を減らせば、費用と期間はその分だけ小さくなります。
※実案件のものではなく、当社で作成したサンプル資料です。
作業単位の一覧は、そのまま進捗管理の単位にもなります。どの単位が変換中で、どの単位が新旧比較まで済み、どの単位が統合されたのかを、お客様と共有しながら進めます。
作業単位の数と大きさは、システムの構成によって変わります。共通部品への依存が整理されているシステムは細かく切れますが、ひとつの処理が数千行に膨らみ、画面と業務ロジックとデータベース操作が混ざっているシステムでは、単位を大きく取らざるを得ません。この違いは費用と期間に直接響きます。規模と難易度の測り方はマイグレーションの見積方法で解説しています。
並行処理と統合の流れ
作業単位ごとに独立した環境を用意し、並行して処理します。各単位の中では、AIが変換、実行、新旧比較、修正、再テストを繰り返し、比較結果の差異がなくなるまで品質を作り込みます。単位が独立しているため、ある単位で差異が見つかっても、他の単位の作業は止まりません。
単位ごとの作業が終わると、人がレビューします。ここで見るのは、AIが抽出した確認事項です。新旧比較で差異が残った箇所のうち、現行の不具合をそのまま再現するのか、正式な仕様として整理するのか、移行を機に修正するのかは、コードからは判断できません。この判断はお客様の業務担当者に確認して確定します。
レビューを通った単位から統合していきます。統合後には、単位の中では確認できない部分を全体テストで確かめます。画面をまたぐ遷移、業務機能とバッチ処理の連携、統合後のデータの整合が主な対象です。すべての単位が統合され、全体テストを通った時点で、本番切替の判定に進みます。
並行処理の効果は期間に表れます。単位を順番に処理すれば単位の数だけ時間がかかりますが、並行して処理すれば、全体の期間はもっとも大きな単位の処理と統合後の全体テストでほぼ決まります。約25万行の基幹システムを、従来手法の見積と比べて工期約60%削減で移行できた背景には、AIによる各作業の高速化に加えて、単位を並行して進められることがあります。
繰り返しの中でAIと人が担う工程
ここまでの流れを、AIの作業と人の作業に分けて整理します。
| 工程 | AIの作業 | 人の作業 |
|---|---|---|
| 棚卸しと分割 | コードとデータベース構造から一覧と依存関係を起こす | 作業単位の切り方と順序を決める |
| 変換 | 移行先の言語・フレームワークの規約に沿って書き換える | 変換の方針と、変換できない箇所の対処を決める |
| 実行と新旧比較 | 新旧を動かし、入力、表示、API、バッチ、データベースの結果を比べて差異を抽出する | 差異が不具合か仕様かを判断する |
| 修正と再テスト | 差異がなくなるまで修正とテストを繰り返す | 成果物をレビューする |
| 統合と切替 | 統合後の全体テストを実行する | 業務担当者による受入確認と、本番切替の判定 |
人の作業のうち、判断の重さが最も大きいのは「差異が不具合か仕様か」です。再現するか直すかは、業務を知る人にしか決められません。判断の進め方は仕様書がないシステムはAIで移行できる？の「不具合か仕様かの判断の進め方」で解説しています。
AIでうまく変換できない箇所の扱いも、人が決めます。変換できない原因は、情報の不足、特殊な言語仕様、外部部品への依存、実行環境の再現の難しさ、業務ルールの曖昧さのどれかに切り分けられます。原因に応じて、追加の資料をいただく、変換ルールを調整する、その箇所だけ人が方針を決めて個別に実装する、といった対処を組み合わせます。
お客様側にお願いするのは、現行資産へのアクセス、テスト環境の準備、主要機能と例外処理の確認、そして業務上の正解を判断できる担当者の方のご協力となります。用意していただきたいものの詳細はマイグレーションの見積方法の「見積を依頼するときに用意するもの」にまとめています。
移行中の改修への追従
分割して繰り返す進め方には、もうひとつ利点があります。移行期間中に現行システムへ入る改修に追従できることです。人手による従来の移行では、解析した時点のコードを正として書き換えるため、途中で現行側が変わると手戻りになり、改修の凍結を長期間お願いするのが普通でした。作業単位に分かれていれば、変更のあった単位だけを再解析し、再変換すれば済みます。約25万行の基幹システム移行では、改修の凍結期間を本番切替前の2週間に抑えました。凍結期間の考え方はシステムマイグレーションの期間の「移行期間中の改修凍結」で解説しています。
業務の切替方式との違い
「分割して移行する」と聞くと、段階移行を思い浮かべる方が多いと思います。段階移行は、新システムへの切替を部門や機能ごとに順番に行う方式で、ある日を境に全体を切り替える一括移行と対比されます。この記事で述べてきた分割は、あくまで開発と検証の作業を単位に分けて進めることですので、本番の切替をどう行うかについてはまた別の話です。
作業を分割して進めたシステムでも、切替は一括で行うことがあります。新旧のシステムに同じデータを持たせたまま部分的に切り替えると、データの整合を保つ仕組みが別に必要になるためです。切替を段階的にするかどうかは、システムの構成、業務の繁忙期、切替時に許容できる停止時間から決めます。切替日の決め方はシステムマイグレーションの期間の「切替日の決め方」で解説しています。
当社の事例: 約25万行の基幹システム
この進め方は、当社が株式会社ウイズ・ワンと共同で実施した、サービス管理基幹システムの移行で実際に用いたものです。対象は約25万行、移行元はFuelPHP、移行先は最新のPHPとLaravel 12でした。マイグレーション専用に開発した独自のAIエージェントが作業単位ごとに変換と検証を繰り返し、人がレビュー、業務知識に基づく受入テスト、本番移行の判定を担いました。結果は、従来手法の見積と比較して金額・工期とも約60%の削減です。プロジェクトの背景と移行の難所はFuelPHPからLaravelへの移行事例で紹介しています。
まとめ
AIマイグレーションは一括変換ではありません。棚卸しで全体を把握し、独立して検証できる作業単位に分割し、単位ごとにAIが変換と新旧比較を繰り返し、人が判断とレビューを担って統合する。数十万行・数百画面のシステムでも工数を抑えて変換できる理由は、この分割と反復にあります。
自社のシステムをどう分割でき、どのくらいの単位数になるかは、実際のコードを解析すれば見えてきます。DEN-NOのAIマイグレーションサービスでは、NDA(秘密保持契約)を締結のうえシステム概要とソースコードの一部をお預かりし、現状リスクと移行可能性をまとめた診断レポートと概算費用を無料でご提示しています。仕様書・設計書のご準備は必須ではありませんので、お手元にないお客様もご安心ください。
よくある質問
Q. 数万行程度の小さなシステムでも、分割して進めるのですか？
規模にかかわらず作業単位に分けて進めます。小さなシステムでは単位の数が少なく、並行処理による期間短縮よりも、差異が出たときに原因を切り分けやすいことが分割の主な目的になります。
Q. 単位ごとに並行して変換すると、コードの書き方がばらつきませんか？
移行先の規約と変換の方針を先に決め、すべての単位に同じ方針を適用します。共通部品を先に移行して土台を揃えること、統合後の全体テストと人のレビューで確認することで、ばらつきを抑えます。
Q. 本番移行に進む前に、この進め方で本当にうまくいくかを確かめられますか？
事前検証(PoC)で一部の作業単位を実際に変換し、新旧で主要な機能が一致するか、AIだけでは難しい範囲がどこか、本番の期間と費用を見積もれるかを確認してから、本番移行に進むかを判断できます。PoCで確認する項目はマイグレーションの見積方法の「PoCによる見積の確定」で解説しています。
Q. 移行費用は行数だけで決まるのですか？
行数は指標のひとつです。作業単位にどれだけ細かく分けられるか、共通部品への依存がどれだけ整理されているか、外部連携や特殊な部品があるかによって、同じ行数でも工数は変わります。規模別の相場観はシステムマイグレーションの費用相場にまとめています。