生成 AI や AI エージェントを使えば、長年稼働してきた業務システムの刷新期間を大幅に短縮できる。その可能性を示した事例として報じられたのが、常石造船の資材調達システムである。このシステムは 17 年間にわたって運用され、仕様を把握する担当者の高齢化と文書不足が進んでいた。従来の人手中心の方法では約 2 年、2 億円を要すると見積もられた工程に AI エージェントを適用し、現状分析とリファクタリングを 2 日間で完了したとされている[1]。
「2 年から 2 日」という数字は、システム刷新の全工程を同じ期間で置き換えたことを意味しない。別の記事では、2 日間で完了した対象を「調査と再設計の検討」と説明している。AI エージェントは数千本以上の既存プログラムを読み込み、プログラム構造の分析、技術的負債の可視化、業務領域の再設計を支援した。最終移行までの工数については、従来方式より 70％ 以上削減される見込みとされており、2 日間という実績と最終移行に関する見込みは区別されている[2]。
この区別によって、AI がモダナイゼーションのどこへ作用したのかが明確になる。従来は、移行先の設計やコード変換へ進む前に、現行システムが何をしているのかを調べる必要があった。文書が不足している場合、技術者はソースコードを順番に読み、呼び出し関係、データ更新、例外処理、外部連携を追跡する。調査が終わらなければ対象規模を確定できず、規模が分からなければ費用、期間、移行方式も決められない。現行解析の遅さは、一工程の作業時間にとどまらず、投資判断を開始できない原因になっていた。
AI エージェントがこの解析を数日へ圧縮すれば、刷新計画の入口にあった不確実性を早期に減らせる。ただし、解析結果が早く得られるほど、次の判断も早く発生する。抽出された処理を新システムへ残すのか、過去の制度や運用上の都合に由来するものとして廃止するのか。新しい構造が同じ業務結果を再現できるのか。コードを変換できることと、変換後のシステムを本番へ移せることの間には、仕様選択、データ照合、受入試験、切替判断が残る。
常石造船の事例を期間短縮の成功例として読むだけでは、AI 導入後の工程変化を十分に捉えられない。短縮されたのは、刷新を始めるために必要だった現行理解と再設計の一部である。その工程が高速化した結果、プロジェクト全体を止める制約は、コードを読み書きする作業量から、残すべき仕様を決め、移行結果を証明する能力へ移り始める。本稿では、国内外の事例と研究を手掛かりに、この制約の移動を追う。
1. 「2 年から 2 日」で何が終わったのか
常石造船の資材調達システムでは、購買、鋼材発注、在庫管理などを担う既存プログラムが長年の改修によって複雑化していた。AI エージェントは数千本以上のプログラムを解析し、処理のまとまり、依存関係、技術的負債を可視化した。その結果をもとに業務領域を再設計し、システムを 9 つのマイクロサービスへ分割する構成が作られた[1][2]。
従来の現行解析では、技術者が個々のファイルを読み、呼び出し先をたどり、データの参照と更新を確認し、その結果を図や一覧へ転記する。プログラム同士の関係を一つずつ確認するため、対象本数が増えるほど調査量も増える。文書が古ければコードとの照合が必要になり、担当者が離職していれば処理の存在理由まで遡れない。対象が大きいほど時間がかかるだけでなく、調査を進めるまで総量を確定できないという循環が生じる。
AI エージェントは、この循環のうち、コードを読み、関係を抽出し、分類案を作る作業を大量に実行できる。人間の読解速度に合わせて直列に進んでいた調査を、複数の処理単位へ分けて進められるため、全体像へ到達するまでの時間が短くなる。全体像が早く得られれば、刷新対象、移行方式、概算費用を早い段階で検討できる。2 日間という数字の実務上の意味は、コード変換の速さだけでなく、投資判断に必要な材料を作るまでの待ち時間を減らした点にある。
| 区分 | 常石造船の事例で確認できる内容 | 後続工程として残る内容 |
|---|---|---|
| 現行解析 | 数千本以上の既存プログラムを読み込み、構造と技術的負債を分析した。 | 抽出漏れ、誤った依存関係、実際の運用との不一致を確認する。 |
| 再設計 | 業務領域を整理し、9 つのマイクロサービスへ分割する構成を作成した。 | 分割境界、データ整合性、処理性能、運用責任の妥当性を確認する。 |
| 最終移行 | 従来方式より工数を 70％ 以上削減できる見込みが示された。 | コード変換、データ移行、外部接続、業務受入、本番切替を完了する。 |
現行解析の短縮は、刷新全体の完了とは異なるが、刷新の成否を左右する。従来は、調査費用を投入した後でなければ対象規模が分からず、規模が判明した時点で予算超過が見込まれれば計画を中止することもあった。着手前に費用と期間を説明できないため、経営側は現行維持を選び、保守担当者の減少と文書の陳腐化がさらに進む。調査不能が刷新延期を生み、刷新延期が次の調査を難しくする構造である。
AI によって調査と再設計を圧縮できれば、この悪循環を入口から切断できる。少ない初期費用で対象規模と分割案を確認できれば、全面刷新、段階移行、現行維持のいずれを選ぶかを具体的に比較できる。刷新を必ず実行できるという意味ではなく、判断材料を得るための負担が下がるため、従来は検討対象にできなかったシステムも選択肢へ戻せる。
一方、AI が抽出した処理の一覧は、そのまま移行仕様にはならない。コードに存在する処理には、現在も必要な業務規則、過去の制度に対応した処理、現場では使われていない機能、不具合を回避するための暫定実装が混在する。AI はそれらの存在場所と関係を示せても、どれを将来の仕様として残すべきかまでは決められない。採否には、業務部門、情報システム部門、移行責任者による判断が必要になる。
移行後の一致を確認する範囲も、解析だけでは確定しない。金額、在庫、発注状態が同じ結果になることに加え、データ更新の順序、外部システムとの連携、障害時の再実行、処理時間、権限制御、監査記録をどこまで保持するかを決める必要がある。旧システムの全挙動を残せば、不具合や不要な個別対応まで移植する可能性がある。差分を広く許容すれば、業務上必要な性質を失う危険がある。
現行解析の高速化によって、その後ろにあった仕様選択と検証が工程上の制約として表面化する。
2. レガシーは古いコードではなく変更できない状態である
レガシーシステムは、古い機種やプログラミング言語を使っているという理由だけで決まらない。IPA のレガシーシステムモダン化委員会は、運用、保守、機能改良が困難となり、経営戦略や事業戦略の足かせ、高コスト構造の原因になっている状態をレガシーとして捉えている。メインフレームや古い言語で構築されていても、仕様が明確で、保守体制が維持され、外部とのデータ連携と継続的な機能改良が可能なら、技術の導入時期だけを理由にレガシーとはいえない[3]。
反対に、新しい技術へ移行済みでも、特定の担当者しか変更方法を知らず、設計書と実装が一致せず、影響範囲を確認できないシステムは再びレガシー化する。使用技術の更新は構成要素を新しくするが、変更の根拠、判断手順、検証方法まで自動的には整備しない。レガシー化を判断する基準は、システムの年齢ではなく、事業上必要な変更を説明可能な手順で実施できるかにある。
委員会は、経済産業省、デジタル庁、IPA を事務局として設置され、2024 年 7 月から 2025 年 3 月まで議論を行った[4]。総括レポートの基礎となった市場動向調査は約 4,000 社のユーザー企業とベンダー企業を対象とし、799 社から回答を得ている。全設問と集計データも公開されているため、個別の比率だけでなく、回答企業の範囲と設問間の関係を確認できる[5]。
調査では、ユーザー企業の 61％、大企業の 74％ がレガシーシステムを保有していた[3]。大規模な企業ほど長期間運用される基幹システムを持ち、業務ごとの追加開発、外部システムとの接続、制度変更への対応を積み重ねやすい。追加された機能が既存機能へ依存し、その依存を前提に次の改修が行われるため、システム規模の増加はコード量だけでなく、変更時に確認すべき関係の数を増やす。
レガシー化の直接原因には、技術の老朽化、機能追加による肥大化、設計文書の未整備、保守の属人化がある。その背後では、IT 投資を事業の変更能力ではなく維持費として扱う経営判断、障害時に恒久対策より応急処置を優先する運用、既存業務を変えずにシステムだけを更新しようとする方針が作用する。個々の改修は当面の業務を継続させるが、変更理由と設計判断が記録されなければ、次の改修で確認すべき範囲が広がる。短期的な延命を繰り返した結果、全面刷新の費用と危険がさらに大きくなる。
| 観点 | 古くても変更可能なシステム | レガシー化したシステム |
|---|---|---|
| 仕様 | 文書、コード、実際の運用の対応関係を確認できる。 | 稼働中のコードや特定担当者の記憶だけが事実上の仕様になっている。 |
| 影響分析 | 変更対象からデータ、外部連携、関連機能への影響を追跡できる。 | 小さな修正でも影響範囲を確定できず、広範な回帰試験が必要になる。 |
| 保守体制 | 複数の担当者が手順と判断根拠を共有し、担当変更後も作業を継続できる。 | 特定の担当者や外部事業者へ知識が集中し、離脱によって変更能力を失う。 |
| 事業対応 | 制度、顧客要求、事業方針の変化に応じて機能とデータを変更できる。 | システム上の制約によって業務変更を見送り、既存手順を人手で補完する。 |
| 技術更新 | 移行目的、保持する性質、検証条件を定めたうえで段階的に更新できる。 | 現行挙動を確認できないため、全面刷新にも部分改修にも大きな危険が伴う。 |
IPA の調査では、経営層、情報システム部門、業務部門の間でシステム情報を共有している企業ほど、仕様の可視化、ブラックボックス対策、内製化、モダナイゼーションが進む傾向も示されている[3]。これは情報共有だけで刷新が成功するという因果関係を証明するものではない。それでも、技術情報を持つ部門、業務上の採否を決める部門、投資を決定する経営層の情報が分断されたままでは、刷新対象と優先順位を確定できない構造を示している。
情報システム部門が技術的な危険を把握していても、業務への影響と費用対効果を経営層へ説明できなければ予算は確保されない。業務部門が現行処理の不便を把握していても、それがどのプログラム、データ、外部連携に由来するか分からなければ、改修要件へ変換できない。経営層が刷新方針を示しても、残すべき業務規則と廃止可能な処理が整理されていなければ、現行踏襲を前提とした大規模な再構築へ戻る。部門間の情報共有は、単なる会議回数ではなく、技術上の事実、業務上の判断、投資上の決定を同じ変更単位へ結び付ける必要がある。
長期間使われたシステムでは、業務知識が単一の設計書に保存されていない。文書に記載された仕様、実際に動くコード、データベースの制約、外部システムとの接続条件、障害時の復旧手順、担当者が表計算で補正している処理が、組み合わさって業務を成立させている。設計書が失われたという説明だけでは不十分であり、知識が複数の媒体と担当組織へ分散し、それらの対応関係を再構成できなくなっている。
この状態では、新しい言語へコードを変換しても変更可能性は回復しない。変換元の処理が必要な理由を確認せずに移植すれば、過去の制度、不要な個別対応、不具合回避のための暫定処理まで新しいシステムへ持ち込む。反対に、コード上の利用頻度だけで削除すれば、月次処理、障害復旧、例外取引のように実行回数は少なくても業務上必要な機能を失う。
モダナイゼーションの最初の仕事は、プログラム言語を選ぶことではなく、分散した知識の対応関係を再び確認できる状態へ戻すことである。どのコードがどの業務規則を実装し、どのデータを更新し、どの外部システムと接続し、どの運用手順で補われているかを明らかにする。この関係が観察可能になって初めて、残す仕様、廃止する仕様、再設計する範囲を決定できる。AI がモダナイゼーションへ入る最初の場所も、コード生成より前にある現行理解となる。
3. AI はコード変換の前後へ入り始めている
生成 AI を使ったモダナイゼーションは、古い言語を新しい言語へ置き換える処理として紹介されやすい。しかし、最近の企業事例では、AI の適用範囲が変換前の現行把握と、変換後の検証へ広がっている。既存文書とコードの読解、設計情報の再構築、業務規則の抽出、移行コードの生成、テスト項目と試験データの作成を、互いに入力と出力を受け渡す工程として扱っている。
この広がりには理由がある。コード変換だけを自動化しても、変換元の意図を説明できなければ、生成されたコードが正しいか判定できない。判定基準がなければ、出力されたコードを人間が再び一行ずつ読み直すことになり、自動化によって短縮した時間を検証工程で失う。AI モダナイゼーションの実用性は、生成量ではなく、現行理解から検証までを追跡可能な形で接続できるかによって決まる。
3.1 NTT データは現行把握からテストまでをつなぐ
NTT データは、生成 AI の利用領域として、既存文書とソースコードからの現行把握、設計、開発、テスト項目、試験手順、試験データの作成を挙げている。将来像としては、工程ごとの担当者と AI エージェントが設計書、コード、テスト項目を作成し、試験まで実行する形を示している[6]。
現行把握では、設計書だけを正解として使えない。長期間の改修によって文書とコードが異なる場合、文書は当初の意図を示し、コードは現在実装されている挙動を示す。さらに、実際の入力と出力、データ更新、運用手順を照合しなければ、現在の業務がどちらに依存しているか判断できない。生成 AI は複数の資料を関連付けられるが、不一致が見つかったときにどれを正式な仕様とするかは、業務部門とシステム責任者の決定になる。
テスト生成も同じ情報系列へ置かれる。現行把握で抽出した入出力条件、例外処理、データ制約を試験項目へ変換できれば、コード生成とは別にテストを最初から作る負担を減らせる。ところが、現行把握の段階で誤った仕様を抽出すると、その誤りが設計、実装、期待値へ連続して伝わる。工程がつながることは効率を上げる一方、一つの誤認が後続成果物へ広がる経路も作る。
この構成で必要になるのは、工程間の接続を切ることではなく、接続点ごとに確認条件を置くことである。設計へ渡す前に仕様候補の根拠を確認し、実装へ渡す前に採用仕様を確定し、試験では生成元と異なる実行結果や業務条件を使う。AI の価値は一度のコード生成ではなく、現行理解、実装、比較を反復できる点にあるが、その反復を正しい方向へ進めるには人間が判定できる中間成果物が必要になる。
3.2 DIT はコードから設計情報を再構築する
デジタル・インフォメーション・テクノロジーは、設計書が十分に整備されていない PHP のレガシーシステムを対象に、生成 AI でソースコードを解析し、設計情報を再構築し、Python への移行とテストコード生成まで進めた事例を公開している[7]。
設計情報の再構築は、既存コードを自然言語で説明するだけの作業ではない。どの機能がどのデータを読み書きし、どの処理を呼び出し、どの条件で分岐するかを、移行先の構造を検討できる単位へ整理する。既存コードと新しいコードの間にこの中間成果物がなければ、変換後のコードがなぜその構造になったのかを追跡できない。
中間成果物を置くと、変換前に判断できる事項が増える。複数の画面から重複して呼ばれている処理は共通機能として分離できる。特定のデータ構造に強く依存する処理は、単純な言語変換ではなく再設計の対象になる。呼び出し元が存在しない処理は削除候補になるが、定期処理や外部実行の可能性を確認するまで廃止は決められない。AI は候補を分類し、人間は業務上の必要性と移行危険を判断する。
テストコード生成まで同じ流れへ含めることで、再構築した設計情報が実装と試験の双方に使われる。ただし、設計情報の誤りをそのまま両方へ渡せば、生成コードと生成テストは同じ誤解の上で一致する。DIT の事例は、設計復元から移行、試験までを連結できる可能性を示す一方、中間成果物を誰がどの証拠で確認するかが移行品質を決めることも示している。
3.3 富士通は構造化した情報を変換と検証へ渡す
富士通は 2026 年 7 月、生成 AI とモダナイゼーションの実践知を組み合わせた「Fujitsu AI ドリブンモダナイゼーションサービス」を開始した。既存システムに関する情報を横断的に分析して構造化し、AI エージェントが複数の作業を並列に進め、プログラム変換と検証を反復する。最終判断は専門技術者が担い、移行期間を約 40％ 短縮するとしている[8]。
横断分析が必要になるのは、モダナイゼーションに使う情報が工程ごとに分断されているためである。ソースコードは実装を示し、設計書は当初の意図を示し、試験記録は過去に確認した条件を示す。障害記録には、通常の設計書へ現れない失敗条件と復旧方法が残る。これらを個別に扱うと、コード変換時に参照した条件と、検証時に確認した条件が一致しない。共通の構造化情報へ結び付ければ、変換結果と検証結果を同じ機能、データ、業務規則の単位で比較できる。
AI エージェントによる並列実行は、処理量を増やす。複数のプログラム群を同時に解析し、変換し、試験できれば、大規模システムでも人間の読解速度だけに依存せず進められる。その一方で、共通機能や共有データに対する判断が誤っていれば、複数の変換作業へ同じ誤りが同時に伝わる。並列化による速度向上には、作業開始前の境界設定と、共通成果物を変更するときの影響管理が必要になる。
報道では、利用企業のシステム特性と安全要件に応じて複数の AI を使い分け、工程ごとに異なりやすい判断基準を統一する構成も説明されている[9]。利用する AI を増やすだけでは判断基準はそろわない。各工程が参照する仕様、許容する差分、停止条件、専門技術者へ引き渡す条件を共通化して初めて、異なる AI の出力を同じ移行計画の中で評価できる。
富士通の構成で最終判断が専門技術者に残されているのは、AI の変換性能が不十分だからという説明だけでは捉えられない。移行可能かどうかは、コードの構文的な正しさに加え、業務上残すべき性質、法令、安全要件、停止可能時間、切戻し条件によって決まる。これらの条件は企業と対象システムごとに異なり、複数の妥当な選択肢から責任を伴って一つを選ぶ必要がある。AI は候補の生成と比較を高速化し、技術者は採用条件と結果の受入れを担う。
3.4 Cognizant は技術構造から業務規則へ対象を広げる
Cognizant は、レガシーカード管理やメインフレーム刷新などの事例で、ソースコードからの業務規則の抽出、文書化、コード変換を組み合わせている。公表されている精度向上や市場投入期間の短縮は提供企業による事例値であり、対象規模、評価対象、比較方式と切り離して共通性能にはできない。一方、AI による解析対象がプログラム構造だけでなく、その中に埋め込まれた取引条件や例外処理へ広がっていることは確認できる[10]。
カード管理や金融取引のシステムでは、同じ画面とデータ項目を再現するだけでは足りない。利用限度額、締め日、手数料、例外承認、取消し、再実行などの規則が複数のプログラムへ分散している。個々の条件式を新しい言語へ翻訳できても、適用順序や規則間の優先関係を失えば、通常取引では動作しても例外取引で異なる結果になる。
業務規則の抽出は、コード変換前にその危険を確認するための工程になる。処理を「何を計算しているか」という技術的説明から、「どの業務条件で、誰に対し、どの結果を適用するか」という判断単位へ移す。業務部門が確認できる表現へ変換すれば、現行処理のうち残すもの、制度変更に合わせて直すもの、廃止するものを選べる。ただし、抽出された文章が自然であることは正確性を保証しないため、元コード、実行結果、制度文書との対応を残す必要がある。
Thoughtworks の実践例でも、生成 AI の価値を新規コードの生成より既存コードの理解に置き、抽象構文木から作った知識グラフと大規模言語モデルを組み合わせている[11]。抽象構文木はプログラムを構文上の要素へ分解した表現であり、知識グラフは関数、データ、呼び出しなどの関係をたどれる形にする。大規模言語モデルだけにコード全体を読ませるのではなく、解析器が得た構造を根拠として説明を生成することで、説明と実装箇所の対応を保ちやすくする。
IBM の研究者らも、非 AI のモダナイゼーションから生成 AI を使う方法までを整理し、モノリスの理解、構造変換、評価方法を研究課題として挙げている[12]。企業事例が示す期間短縮と、研究が指摘する評価上の未解決問題は矛盾しない。現行解析と候補生成が速くなっても、業務規則の完全性、変換後の等価性、長期保守性を測る共通方法が確立したことにはならないからである。
各社の対象業界、製品、使用する AI は異なる。それでも、既存資産を解析し、構造と業務規則を中間成果物へ変換し、その成果物をコード生成とテストへ渡す工程は共通している。この中間成果物によって、人間は数千本のコードを直接読み続ける代わりに、機能、データ、規則、差分の単位で判断できる。
同じ構造は、誤りの伝播経路も作る。現行解析で抜けた例外条件は設計情報に現れず、設計情報に現れない条件は生成コードとテストからも欠落する。後工程を自動化するほど、最初の仕様復元が持つ影響範囲は広がる。AI がコード変換の前後へ入ることで、モダナイゼーションは高速になるが、仕様候補の根拠、工程間の受渡し条件、独立した検証経路を設計する必要も増す。
AI モダナイゼーションの中心は、古いコードを新しい構文へ置き換えることから、既存システムを人間と機械の双方が検証できる表現へ変えることへ移っている。この表現が整えば、コード変換を反復し、差分を比較し、対象を段階的に移行できる。整わないまま生成だけを速めれば、理解できない旧システムが、生成過程を説明できない新システムへ置き換わる。コード変換の前後を含む工程設計は、移行速度を上げる方法であると同時に、レガシー化を新しい技術上で繰り返さないための条件になる。
4. 解析が速くなっても移行全体が同じ割合で短くなるとは限らない
モダナイゼーションは、現行システムを解析して新しいコードへ変換すれば完了する作業ではない。最初に対象範囲と移行目的を定め、現在の挙動から将来も残す仕様を選び、移行先の構造を決める。その後にコードとデータを変換し、外部システムとの接続、処理性能、障害復旧、安全性、業務上の受入条件を確認する。試験を通過した後も、本番切替、切戻しへの備え、移行後の監視とデータ照合が続く。
各工程は直列に並んでいるだけではない。現行解析で見つかった依存関係は移行範囲を変え、仕様確認で廃止すると決めた処理はコード変換とテストの対象から外れる。試験でデータ更新の差異が見つかれば、設計や仕様判断まで戻る。前工程の成果が後工程の入力になり、後工程の発見が前工程の修正を要求するため、一部の作業時間を短縮しても、全体期間が同じ割合で減るとは限らない。
| 工程 | AI で短縮しやすい作業 | 残る判断と確認 | 未確定のまま進めた場合の帰結 |
|---|---|---|---|
| 対象選定 | コード量、依存関係、変更頻度、技術的負債を集計し、候補を比較できる。 | 全面刷新、段階移行、現行維持のどれを採用し、どの範囲へ投資するか決める。 | 調査対象が拡大し、移行方式と費用見積もりを確定できない。 |
| 現行解析 | コード読解、依存関係抽出、機能分類、文書候補作成を大量に実行できる。 | 抽出漏れ、誤った関係、文書と実装の差、現場運用との不一致を確認する。 | 欠落した処理や誤った依存関係が、後続の設計と変換へ引き継がれる。 |
| 仕様確定 | 既存挙動、関連文書、障害記録を一覧化し、矛盾と未決事項を早期に発見できる。 | 残す挙動、廃止する挙動、意図的に変更する挙動、判断責任者を決める。 | 未確定の仕様候補が実装へ固定され、業務確認後に大規模な手戻りが発生する。 |
| 構造設計 | 機能とデータのまとまりを分析し、分割案や移行案を複数生成できる。 | サービス境界、データ所有、取引単位、運用責任の配置を決める。 | コードは分割されてもデータと障害の影響範囲が分離されず、複雑性だけが増える。 |
| コード変換 | 定型変換、修正案作成、依存部品の更新、反復実行を並列化できる。 | 業務規則、処理順序、例外処理、性能条件が保持されたか確認する。 | 構文上は正しく動作しても、特定の業務条件で旧システムと異なる結果を返す。 |
| データ移行 | 項目対応、形式変換、照合処理、異常値候補の抽出を補助できる。 | 欠損値、重複、履歴、コード体系の差をどの規則で補正するか決める。 | プログラムは正常でも、移行後の残高、在庫、状態履歴が一致しない。 |
| 試験 | 試験項目、入力データ、期待値候補、比較処理、回帰試験を生成できる。 | 何を等価とみなし、どの差分を許容し、誰が受け入れるか決める。 | 生成コードと生成テストが同じ誤解を共有し、誤った実装が合格する。 |
| 本番移行 | 移行手順候補、データ照合処理、監視項目、切戻し手順の作成を補助できる。 | 業務停止時間、データ補正、切戻し条件、本番移行の承認責任を確定する。 | 障害発生時に継続と切戻しの判断が遅れ、業務停止とデータ不整合が拡大する。 |
AI の効果は工程ごとに異なる。ソースコードを読み、呼び出し関係を抽出し、定型的な変換案を作る作業は、対象を分割して並列に進めやすい。一方、旧システムの挙動を残すか廃止するかという判断は、対象企業の制度、契約、業務方針に依存する。入力情報を増やしても、判断権限を持つ部署が採否を決めなければ仕様は確定しない。
後工程には、前工程と異なる種類の負荷が発生する。AI が短期間に数百本の変換結果を生成すれば、コード変換の待ち時間は減る。その結果、レビュー、業務確認、試験環境、外部接続先との調整へ成果物が集中する。従来は 1 か月に 10 本を確認していた体制へ数百本が到着しても、確認担当者、受入基準、試験データが変わらなければ、成果物はそこで滞留する。
この滞留は、単純な人員追加だけでは解消しにくい。レビュー対象を増やすには、何を確認すれば合格なのかを共通化する必要がある。確認基準が担当者の経験に依存していれば、担当者を増やすほど判断のばらつきも大きくなる。AI による生成能力の増加は、レビュー人数だけでなく、仕様、許容差、証拠、承認条件を再利用できる形へ整備することを要求する。
大規模な PL/SQL 資産を Java へ移す研究事例では、約 250 万行のコードに一貫した文書と自動テストが不足していることが、変換と評価の制約として挙げられている[13]。コードを翻訳できても、元の処理が満たしていた条件を列挙できなければ、変換結果を比較する基準を作れない。基準がなければ人間が元コードを再読する必要が生じ、変換で短縮した時間が確認工程へ移る。
移行全体の期間は、最も自動化しやすい工程ではなく、成果物を次工程へ渡せる状態にするまでの時間によって決まる。現行解析が高速化すれば、仕様確定が次の制約になる。仕様が確定してコード変換が進めば、データ移行と等価性確認が制約になる。AI はプロジェクト全体を同じ倍率で圧縮するのではなく、工程ごとの待ち時間の分布を変える。
期間短縮を評価するときには、総期間だけでなく、各工程で何を完了とみなしたかを確認する必要がある。解析完了がプログラム一覧の生成を意味するのか、業務部門による仕様確認まで含むのか。変換完了がコンパイル成功を意味するのか、実データによる旧新比較まで含むのか。完了条件をそろえずに従来方式と AI 利用方式を比較すると、同じ名称の工程で異なる成果物を数えることになる。コード変換が高速になるほど、仕様確定、検証基準、証拠評価を先に設計しておかなければ、生成された成果物の量が新しい停滞要因になる。
5. AI が復元するのは確定仕様ではなく仕様候補である
既存コードから直接確認できるのは、そのシステムにどのような処理が実装されているかである。その処理が当初意図された仕様どおりなのか、現在の業務でも使われているのか、新システムへ残すべきなのかは、コードの存在だけでは決まらない。実装されている挙動と、将来採用する仕様を同じものとして扱うと、過去の制約と不具合まで移行対象へ含めることになる。
長期運用されたシステムには、性質の異なる処理が同じコードベースへ混在している。現在も必要な業務規則、過去の法制度への対応、旧製品の制約を避けるための暫定処理、既に使われていない画面、障害を回避するために追加された条件分岐、運用担当者が手作業で補正することを前提とした出力である。AI がこれらを同じ精度で説明できても、移行時の扱いは同じにならない。
| コードから抽出された処理 | 確認すべき根拠 | 移行時の判断 | 誤った場合の帰結 |
|---|---|---|---|
| 現在も使用する業務規則 | 制度文書、業務手順、実行履歴、担当部署の確認と一致するか調べる。 | 新しい構造に合わせて再実装し、業務結果の等価性を試験する。 | 必要な計算や判定が欠落し、本番業務の結果が変わる。 |
| 過去制度への対応 | 適用期間、保存義務、過去データの再処理可能性を確認する。 | 削除、参照専用化、履歴環境への隔離のいずれかを選ぶ。 | 不要処理を移植して複雑性を残すか、必要な履歴参照を失う。 |
| 技術上の暫定処理 | 旧基盤の容量、形式、接続制約を避けるための処理か確認する。 | 移行先で制約が消えるなら、業務仕様と分離して廃止する。 | 旧技術に由来する複雑性を新システムへ再生産する。 |
| 不具合回避の分岐 | 障害記録、修正履歴、入力条件、現場の回避手順を照合する。 | 根本原因を修正し、必要な回帰試験だけを残す。 | 分岐を無条件に削除して障害を再発させるか、不具合ごと移植する。 |
| 未使用に見える機能 | 定期実行、外部呼び出し、年度処理、障害復旧時の利用を確認する。 | 利用経路が存在しないことを証明した後に削除する。 | 実行頻度の低い重要機能を未使用と誤認して失う。 |
| 人手補正を前提とする出力 | 出力後の表計算、承認、再入力などを含む実際の業務手順を調べる。 | 補正を新システムへ組み込むか、正式な手作業として残すか決める。 | コード上の出力は再現できても、最終的な業務結果が一致しない。 |
AI による仕様復元は、コードに含まれる処理を人間が確認しやすい単位へ変換する。関数名、条件分岐、データ項目、呼び出し関係を読み、処理の目的を文章や図として提示することで、技術者以外も確認に参加しやすくなる。ところが、説明の読みやすさは、その説明が正しいことを保証しない。自然な文章ほど未確認の推測が事実に見えやすくなるため、生成品質と事実性を別々に評価する必要がある。
大規模言語モデルを使って MUMPS と IBM のアセンブリ言語から文書を生成した研究では、生成された説明を完全性、読みやすさ、有用性、事実と異なる生成の観点から評価している[14]。読みやすい説明でも、参照していないデータの用途を補ったり、条件分岐の意味を誤って一般化したりすれば、移行判断には使えない。反対に、構文を正確に説明していても、業務部門が理解できない粒度では仕様確認を進められない。
仕様復元には、少なくとも三つの異なる評価が必要になる。第一は、コードに存在する処理を漏れなく拾っているかという完全性である。第二は、説明内容が元コード、データ定義、実行結果と一致するかという正確性である。第三は、その説明から残す処理と廃止する処理を判断できるかという利用可能性である。どれか一つだけを満たしても、確定仕様にはならない。
要件工学への生成 AI 利用を調べた文献レビューでも、解釈可能性、再現性、制御可能性が主要な課題として報告されている[15]。解釈可能性が不足すれば、生成された要件がどの資料に基づくのか分からない。再現性が不足すれば、同じ入力から異なる分類や優先順位が出る。制御可能性が不足すれば、対象範囲と粒度を指定しても、不要な一般化や推測が混入する。
同じ資料から表現の異なる説明が生成されること自体は、直ちに誤りを意味しない。業務向けの説明と技術者向けの説明では、必要な語彙と粒度が異なるからである。判断に必要なのは文章の一致ではなく、どちらの説明も同じコード、データ、実行結果へ戻れることである。表現の違いを許容しながら事実の根拠を固定するには、仕様候補ごとに出典と対象箇所を保持する必要がある。
正式な要件管理簿へ登録する段階では、AI が生成した文章だけでなく、確認状態も管理対象になる。元コードから直接確認できた事実、複数資料が一致している事項、担当部署による判断、未確認の仮説を同じ記述形式で並べると、確実性の違いが見えなくなる。仕様候補に根拠、確認者、確認日、未解決事項を付けることで、調査結果と組織判断を分離できる。
ソフトウェア構造への生成 AI 利用を調べた研究では、アーキテクチャ復元や設計支援が主要用途として確認される一方、厳密な試験と共通評価方法の不足が指摘されている[16]。構造図やサービス分割案は、コードの関係を理解する助けになる。しかし、図上で機能が分かれていても、複数機能が同じデータを同時に更新するなら、実行時には分離できていない。
サービス境界の妥当性は、名称や図形の配置ではなく、変更と障害の影響範囲で確認する必要がある。ある業務規則を変更したときに一つのサービスだけで完結するか。取引途中で一部が失敗したときにデータを一貫した状態へ戻せるか。担当部署と運用監視の責任を境界に合わせて分けられるか。AI が生成した分割案は、これらの質問を検討する候補であり、完成した設計ではない。
2026 年に提案された Reversa は、レガシーコードから運用仕様を作る際に、元コードへの追跡情報、確信度、未確認箇所を残す構成を採用している[17]。この構成では、AI が理解できなかった部分を自然な文章で埋めるのではなく、空白として表面化させる。確認済みの関係と未確認の関係を分ければ、人間はコードベース全体を再読せず、危険度の高い空白へ調査を集中できる。
確信度は、仕様の採否を自動的に決める点数ではない。高い確信度でも、年に一度しか動かない決算処理や障害復旧機能なら、業務上の影響が大きいため人間の確認が必要になる。低い確信度でも、呼び出し元がなくデータ更新も行わない処理なら、調査の優先度を下げられる。確信度、影響度、利用頻度を組み合わせることで、確認作業を配分する判断材料になる。
仕様復元の成果物には、結論だけでなく不確実性を残す必要がある。どのコードと文書が一致し、どこで矛盾し、どの挙動が実データで確認され、誰の判断を待っているのかを示す。AI が人間の調査を代替する範囲は、確定仕様を自動的に決めるところまでではなく、確認対象を絞り、根拠と空白を同時に提示するところにある。
この区別を保てば、AI の仕様復元はモダナイゼーションの速度を上げる。人間は数千本のコードを一律に読む代わりに、根拠が競合する処理、影響度が高い処理、未確認の例外へ時間を使える。区別を失えば、生成された説明が新しい正解として固定され、旧システムのブラックボックスが AI の推測を含む設計書へ置き換わる。AI が復元する仕様候補を確定仕様へ変えるのは、根拠の照合と採否の判断を記録する工程である。
6. 最初のボトルネックはコード変換から仕様選択へ移る
AI が数千本のプログラムを横断し、処理、データ、呼び出し関係を短時間で一覧化すると、従来は別々の担当者や文書に分散していた矛盾が同時に表面化する。設計書では必須とされながら実行経路から到達できない機能、コードには残っているが現場では使われていない処理、名称は異なるものの同じ対象を表すデータ、同じ入力に対して部門ごとに異なる判定を返す規則が、仕様候補として同じ検討台帳へ並ぶ。
解析前には、こうした不一致の存在自体が分からない。解析後には、不一致を認識できても、どれを正しい仕様として採用するかが決まっていない。AI はコードに実装された挙動、文書に記載された規則、データの利用箇所を関連付けられるが、その差異が文書の更新漏れなのか、現場が承認した運用変更なのか、過去の障害対応が残ったものなのかまでは、技術資産だけから確定できない。
| 表面化する差異 | AI が提示できる情報 | 採否を決める主体 | 未確定のまま実装した場合の帰結 |
|---|---|---|---|
| 文書にあるが実行されない機能 | 記載箇所、対応するコード、呼び出し経路の有無を示せる。 | 業務部門とシステム管理部門が、現在も必要な要件かを確認する。 | 不要な機能を再実装するか、必要な機能を欠落させる。 |
| コードにだけ残る処理 | 実装場所、入力条件、更新対象、関連する外部連携を抽出できる。 | 業務部門が利用実態を確認し、必要に応じて法務、監査、顧客担当が廃止可否を判断する。 | 契約上必要な例外を失うか、廃止済みの規則を新システムへ持ち込む。 |
| 同一対象を表す複数のデータ | 名称、型、更新元、参照先、値の一致率を比較できる。 | データ管理責任者が正本と同期条件を決める。 | 移行後も複数の正本が残り、部門間で異なる結果を参照する。 |
| 部門ごとに異なる判定規則 | 条件式、適用範囲、処理結果、利用画面を並べられる。 | 業務責任者が統一、併存、廃止のいずれかを選び、経営層が影響を承認する。 | 一方の部門の規則が全社仕様として固定され、移行後に業務対立が障害として現れる。 |
技術者は、それぞれの実装場所と変更による影響範囲を説明できる。しかし、過去の規則を廃止してよいか、顧客との契約や監査要件のために残すべきかを単独では決められない。業務部門は必要な結果を判断できても、その変更が夜間処理、外部接続、会計データへ波及する範囲をコードだけから把握することは難しい。経営層は投資額と業務上の危険を受容できるが、数千件に及ぶ処理差分を一件ずつ判定する役割には向かない。
この分担が整理されないまま生成工程を開始すると、AI は未確定の仕様候補をコードへ変換する。生成されたコードが多いほど、同じ仮定が複数の画面、処理、試験へ展開される。その後に業務判断が変われば、修正対象は一つの処理にとどまらず、関連する設計情報、生成コード、試験データ、移行手順へ広がる。実装速度の向上が手戻りを減らすのではなく、判断前に実装する量を増やすことで、誤った決定を固定する速度まで上げる場合がある。
人手による開発では、コードを書く時間が長いため、仕様の曖昧さが実装待ちの間に解消されることもあった。AI によって実装待ちが短くなると、未決事項を整理する猶予も失われる。コード生成能力が工程上の制約でなくなった後には、候補の根拠を確認し、影響を引き受ける主体が期限内に採否を決められるかが、着手可能な作業量を決める。
仕様選択を進めるには、候補ごとに出典、現在の利用状況、変更時の影響、判断期限、決定権を持つ部署を結び付ける必要がある。出典には設計書やコードだけでなく、実行記録、問い合わせ履歴、障害対応、契約条件、現場で使われる補助資料も含まれる。利用状況が不明なら廃止判断はできず、影響先が不明なら変更を承認できず、決定権が不明なら候補は保留のまま後続工程へ流れる。
AI は候補の抽出と影響調査を支援できるが、廃止によって生じる業務上の損失や契約上の責任までは引き受けない。仕様選択とは、人間に残された曖昧な作業ではなく、組織内の決定権、技術資産に残る証拠、移行後の責任を一つの変更判断へ接続する工程である。この接続が成立して初めて、生成速度を手戻りの増幅ではなく移行期間の短縮へ変えられる。
7. 二つ目のボトルネックは等価性をどこまで求めるかである
仕様を選択しても、新しい実装が選択した内容を満たすかを確認しなければ本番へ移せない。しかし、新旧システムが同じであることを単一の条件で示すことはできない。同じ入力から同じ画面表示が得られても、データ更新の順序が変わり、障害時に処理途中の状態が残るなら、業務システムとして同等とはいえない。金額計算が一致しても、承認履歴、権限制御、監査記録が失われれば、会計や監査の条件を満たさない。
等価性は、旧システムの出力を複製することではなく、移行後も保存しなければならない性質を対象ごとに定義し、その性質が保たれた証拠を作ることで成立する。確認対象が画面や単体機能に限られると、取引全体の更新順序、外部システムとの時間的な関係、障害からの復旧条件が試験から抜ける。局所的な一致を積み上げても、業務が成立する条件を試験していなければ、本番運用の等価性は示せない。
| 等価性の対象 | 確認する内容 | 必要な証拠 | 一致しない場合の影響 |
|---|---|---|---|
| 業務結果 | 金額、在庫、発注状態、締め処理の結果が、合意した入力条件と業務規則に一致する。 | 代表例だけでなく、境界値、例外、取消、再処理を含む新旧比較結果を残す。 | 請求誤り、在庫不整合、取引の重複、締め処理の停止につながる。 |
| データ更新 | 更新順序、取引単位、同時実行時の整合性、再実行時の重複防止が保たれる。 | 更新前後のデータ、障害注入時の中間状態、再実行後の照合結果を確認する。 | 途中状態や二重登録が残り、後続処理が誤ったデータを正しい状態として扱う。 |
| 外部連携 | データ形式、送受信時刻、再送、重複排除、異常応答の扱いが接続先の条件を満たす。 | 接続先との結合試験、応答遅延や通信断を含む異常系試験、運用合意を用意する。 | 自システム内の試験に成功しても、接続先で欠落、重複、処理順序の逆転が起きる。 |
| 非機能要件 | 処理時間、同時利用数、可用性、復旧時間、安全性、監査証跡が必要水準に達する。 | 性能測定、障害復旧試験、権限試験、監査記録の確認結果を残す。 | 機能上の結果が正しくても、業務量や統制要件に耐えられず本番運用へ移せない。 |
| 変更可能性 | 仕様根拠、構造、依存関係、試験が、移行後も更新可能な成果物として残る。 | 要件からコードと試験までの追跡関係、変更手順、保守責任者を確認する。 | 移行直後から変更理由を追えなくなり、新しい技術基盤の上で再びブラックボックス化する。 |
旧システムの全挙動を完全に複製すれば安全になるとも限らない。長期運用されたシステムには、現在の業務に必要な例外処理と、既に廃止された制度への対応、不具合を回避するための迂回処理、過去の技術制約が同じコード内に残っている。すべてを一致条件に含めれば、不要な挙動まで新システムの正式仕様となり、技術基盤を更新しても変更困難性は保存される。
一方、旧システムとの差異をすべて改善として扱うこともできない。新しい構造のほうが簡潔であっても、月末処理の順序、外部連携の締切時刻、障害時に担当者が再開できる地点が変われば、現場の運用条件を壊す可能性がある。変更の妥当性はコード品質だけでは決まらず、その挙動に依存する業務、接続先、統制条件まで含めて判断される。
このため、等価性の設計では、何を一致させるかだけでなく、何を意図的に変えるかも先に定める必要がある。保存する挙動には新旧比較の証拠を割り当て、変更する挙動には変更理由、承認者、影響範囲、移行後の期待結果を記録する。差異をすべて欠陥とみなすのでも、すべて改善とみなすのでもなく、合意済みの差異と未説明の差異を分けることで、試験結果を本番移行の判断材料として使える。
AgentModernize は、業務規則を明示的な中間表現へ抽出し、仕様化、コード生成、検証を異なる役割として扱っている。評価では、個々の検証関数を生成できても、処理間の結合を誤ったために試験へ失敗する例が報告されている[18]。個別処理の入力と出力が正しくても、前段の結果を次段へ渡す順序や条件が誤れば、業務全体の結果は一致しない。
ただし、この研究は評価対象とした 8 つのシナリオについて、業務規則の抽出よりコード生成がボトルネックだったとも報告している。個別研究の結果だけから、すべてのモダナイゼーションで仕様選択が先に制約になるとはいえない。本稿が扱うのは、解析と生成を十分に高速化できた案件で、その後にどの制約が現れるかである。
この失敗は、生成コードの局所的な正しさと、システム全体の等価性が別の検証対象であることを示す。関数単位の試験は実装上の誤りを発見できるが、業務上の取引境界や外部接続を含む順序制約までは保証しない。検証範囲を広げるには、単体、処理連鎖、データ更新、外部連携、業務受入を階層として設計し、上位の試験ほど業務部門や接続先を判断主体へ加える必要がある。
AI によってコードと試験の生成量が増えると、検証すべき成果物も同じ速度で増える。何を等価とみなすかが未定義なら、試験項目を大量に生成しても合否を決められない。仕様選択の次に工程を止めるのは試験コードを書く能力ではなく、保存すべき性質、許容する差異、承認に必要な証拠を事前に定義する能力である。
8. AI が生成したテストは独立した証明になるとは限らない
コードとテストを同じ AI が同じ仕様候補から生成すると、両方が同じ誤解を共有することがある。AI が業務規則を「条件 B なら結果 C」と誤って解釈し、その解釈から実装と期待値を作れば、生成されたコードは生成されたテストに合格する。実際の業務が求める結果が D であっても、実装と期待値の由来が同じであれば、生成物同士の一致だけでは誤りを発見できない。
この状態では、テストが確認しているのは業務要件への適合ではなく、同じ解釈から作られた二つの成果物が整合していることである。テスト件数や網羅率を増やしても、期待値を導いた前提が変わらなければ、同じ誤解を異なる入力で反復する可能性がある。生成コードに対して生成テストを実行すること自体は有用だが、その成功を移行可否の証拠として使うには、期待値が実装とは別の根拠から導かれているかを確認しなければならない。
| 検証方法 | 確認できること | 共有される可能性がある誤り | 補うべき情報源 |
|---|---|---|---|
| 生成コードに対する生成単体テスト | 関数や部品が生成時に想定した入力と出力の関係を満たすか確認できる。 | 実装と期待値が同じ仕様解釈を共有すると、要件の誤読を検出できない。 | 承認済みの業務規則、旧システムの実行結果、業務部門が定めた期待値を使う。 |
| 新旧システムの差分試験 | 同じ入力に対する出力、更新データ、外部送信内容の差異を検出できる。 | 旧システムに残る不具合や廃止対象の挙動まで正解として扱う可能性がある。 | 保存する挙動と変更する挙動を区分した仕様決定記録を使う。 |
| 実データによる再生試験 | 実際の値の分布、例外、境界条件を含む処理結果を比較できる。 | 過去データに存在しない新制度や未発生の障害条件は確認できない。 | 制度資料、契約条件、障害想定から追加した試験データを使う。 |
| 業務受入試験 | 利用者が必要とする結果、操作、運用手順を満たすか判断できる。 | 通常運用だけを確認すると、月末処理、再実行、障害復旧が抜ける。 | 運用記録、障害履歴、監査要件を受入条件へ組み込む。 |
| 性能、権限、復旧の試験 | 機能結果以外の本番運用条件を満たすか確認できる。 | 正常系の機能試験だけでは、負荷、権限逸脱、途中障害を検出できない。 | 本番相当の負荷条件、権限表、復旧目標、監査基準を使う。 |
VAPU の研究は、複数の AI に役割を分けて古いソフトウェア部品を更新し、構文エラーや実行時エラーの減少だけでなく、要求をどの程度満たしたかを別の指標で比較している[19]。動作可能なコードと、要求を満たすコードを分けて測るのは、変換の成功条件がコンパイルや試験実行の成否だけでは決まらないためである。プログラムが実行できても必要な機能を欠いていれば移行成果物にはならず、生成された試験に合格しても要求との対応を示せなければ業務上の正しさは証明できない。
複数の AI に役割を分ける構成にも限界がある。実装担当と試験担当を別の AI にしても、両者が同じ誤った仕様書や同じ不完全なコード解析結果を参照すれば、判断経路は独立しない。役割の数ではなく、期待値を導く証拠が生成時の根拠から分離されているかが、検証の独立性を左右する。
COBOL のモダナイゼーション工程について、あらかじめ定めた制御と大規模言語モデルによる工程制御を比較する研究もある。この研究は、変換、検証、試験の順序と中間結果を機械的な規則で確認できる場合に、工程の進行判断まで AI に委ねることが有利とは限らないという問いを立てている[20]。次の工程へ進める条件が明示できるなら、その判定を確率的な生成へ置き換えることで、同じ入力に対する判断の再現性や失敗箇所の追跡可能性を失う場合がある。
AI を工程内の作業へ使うことと、工程間の進行判断を AI に渡すことは異なる。コード変換案、試験項目、差分の説明を AI が作成しても、コンパイル成功、必須試験の合格、未解決差分の不存在、責任者の承認といった条件は決定的な規則として管理できる。生成が得意な作業と、同じ条件なら同じ結果を返す必要がある判定を分けることで、速度を維持しながら監査可能性を残せる。
独立した検証には、生成時とは異なる情報源が必要になる。旧システムの実行結果、匿名化した実データ、障害記録、法令、契約、業務部門が定めた受入条件を使えば、コード解析から生じた誤解を別の経路から反証できる。ただし、旧システムの結果をそのまま正解とすると不要な挙動まで保存するため、仕様選択で合意した保存対象と変更対象を検証条件へ反映しなければならない。
生成 AI のソフトウェア開発利用を調べた研究でも、定型作業の短縮が進む一方、価値の中心が仕様品質、構造上の判断、監督へ移ると報告されている[21]。コードとテストを生成できるようになるほど、人間の役割は成果物を一件ずつ書くことから、合格条件の根拠を用意し、異なる証拠が同じ結論を支持するかを判断することへ移る。テスト生成の高速化を品質向上へ結び付ける条件は、試験数ではなく、誤った解釈を生成物の外側から検出できる構成にある。
9. 要件、権限、検証の分離はボトルネック移動への対応である
既稿「AI モダナイゼーションはモデルではなく工程を変える」では、AI の性能差だけでなく、どの工程を省略し、どの作業を自動化し、何を共通資産へ移し、どの判断を人間に残すかを扱った[22]。本稿で確認した事例は、その工程変化が実際に進んだ後、コード生成より遅くなる作業がどこに現れるかを示している。現行解析が速くなれば仕様候補の選択が滞り、実装が速くなれば等価性の定義と検証が滞る。
この接続を一段抽象化すると、AI モダナイゼーションが変えるのは個々の作業時間だけではない。従来は人間の読解と実装が遅かったため、調査、判断、変更、試験が同じ担当者の作業系列に収まりやすかった。AI が大量の資産を並列に処理すると、観測された差異の量、生成される変更量、確認すべき結果の量が、人間の判断能力を上回る。そこで必要になるのは、従来は一人または一部門の中に暗黙にまとまっていた要件確定、変更権限、合否判定を、工程上の異なる境界として明示することである。
| 境界 | 管理する対象 | 主な判断主体 | 分離しない場合の失敗 |
|---|---|---|---|
| 要件 | 抽出された仕様候補のうち、保存、変更、廃止する挙動を確定する。 | 業務責任者が中心となり、技術、法務、監査、データ管理の担当者が根拠を提供する。 | 未確定の候補が正式仕様として実装され、生成後の手戻りが複数成果物へ広がる。 |
| 権限 | AI が参照、変更、実行、接続できる資産と環境の範囲を定める。 | システム所有者と運用責任者が、変更の影響と復旧可能性に応じて許可する。 | 誤った解釈や操作がリポジトリ、データ、外部環境へ連鎖し、影響範囲を限定できない。 |
| 検証 | 生成物が確定要件と運用条件を満たし、本番へ移行できる証拠を定める。 | 試験担当、業務部門、運用部門、監査担当が対象ごとの合否を判定する。 | 生成時と同じ誤解に基づく試験が成功し、誤った変更が自己確認を通過する。 |
AI が扱える変更量が増えると、正しい修正だけでなく、誤った仕様解釈が広がる速度も上がる。要件が未確定のまま広い変更権限を与えれば、仕様候補が多数のコード、設定、データ変換、試験へ固定される。さらに、同じ認識経路で期待値と合否判定まで作れば、最初の誤解が後続工程で否定されず、整合した成果物の集合として本番移行候補へ到達する。
既稿で整理した Devin の変化も、この構造へ接続する。AI は開発者の手元で候補を表示する道具から、独立した環境でリポジトリを調査し、実装し、試験し、失敗に応じて修正を繰り返す作業主体へ移っている[23]。人間が一つずつ操作を指示しなくても作業を継続できるため、委任できる範囲は広がる。その一方で、依頼時に曖昧だった完了条件や権限範囲も、作業の反復を通じて多数の変更へ展開される。
作業主体が独立するほど、依頼文の詳しさだけでは制御できない。参照可能な資料、変更可能なディレクトリ、実行できるコマンド、接続できる外部環境、停止条件、成果物の採用手順を、実行環境と工程側で制約する必要がある。指示を誤解しても変更範囲を越えられず、試験に失敗すれば進行が止まり、承認前の成果物が本番へ到達しない構成であれば、個々の生成精度だけに安全性を依存せずに済む。
要件、権限、検証を分ける目的は、人間による承認回数を一律に増やすことではない。仕様候補が確定仕様へ変わる地点、AI が変更してよい範囲、移行可能と判断する証拠を別々に管理し、変更の影響に応じて人間が介入する箇所を絞ることにある。名称変更や定型的な構文変換のように、影響範囲が限定され、機械的な合格条件を設定できる作業は自動で進められる。金額計算、権限制御、外部契約、データ正本の変更は、根拠と影響を責任者へ提示して判断を求める。
この分離がなければ、低リスクの変更にも同じ承認負荷がかかり、人間の確認工程が新たな滞留点になる。反対に、影響の大小を区別せず自動化すれば、高リスクの変更まで未確認で進む。変更対象、影響範囲、検証可能性に基づいて経路を分けることで、定型処理の速度を維持しながら、人間の判断能力を仕様上の差異や本番影響が大きい箇所へ配分できる。
観測、変更、判定を同じ主体へ集中させると、その主体が持つ誤解を外側から検出しにくい。これは AI 固有の問題ではなく、仕様を作った担当者が実装し、自ら作った期待値だけで合否を決める工程にも存在する。AI は処理量と反復速度を上げるため、従来は限定的だった共通誤解を短時間で広範囲へ複製する。そのため、分離されていなかった責任境界がモダナイゼーションの成否へ直接影響するようになる。
AI の精度が高いか低いかだけでは、工程の安全性を判断できない。誤りが生じたときに変更範囲を限定できるか、生成時とは別の証拠で反証できるか、影響を引き受ける主体が採否を決められるかが必要になる。AI モダナイゼーションによるボトルネック移動へ対応するとは、人間へ作業を戻すことではなく、生成速度に耐えられる形へ決定権と検証経路を再配置することである。
10. AI モダナイゼーションは短縮率だけでは評価できない
AI サービスをモデル性能だけでなく、実行環境、業務への接続、権限、監査、失敗時の復旧を含む作業成立条件で比較する考え方は、既稿「最新 AI は何が変わったのか 2026」で整理した[24]。モダナイゼーションでも同じ見方が必要になる。変換速度や自動変換率が高くても、何を変換対象とし、どの条件を正しい結果とみなし、誰が本番移行を承認したかを説明できなければ、その数字は移行の成立を示さない。
短縮率を評価するには、比較対象となる工程の範囲をそろえる必要がある。現行解析だけを対象とした短縮率と、仕様確定、データ移行、外部接続、受入試験、本番切替まで含む短縮率は同じ指標ではない。従来方式の見積期間と AI 利用後の実績期間を比べる場合も、対象プログラム数、文書の整備状況、試験の範囲、再利用した既存資産が異なれば、差のすべてを AI の効果には帰属できない。
自動変換率にも同じ注意が必要になる。全資産のうち AI が変換案を出力した割合、修正なしでコンパイルできた割合、既存試験に合格した割合、業務受入まで完了した割合は、それぞれ異なる状態を測っている。生成されたコードの割合だけを示すと、手作業で修正した量や、未解決の仕様差分、試験に必要だった工数が数字の外へ残る。評価対象を工程上の終了条件と結び付けなければ、生成量が移行成果として数えられる。
| 評価軸 | 確認する問い | 確認に使う証拠 | 欠けた場合の帰結 |
|---|---|---|---|
| 工程範囲 | 短縮率は現行解析、設計、変換、試験、移行のどこからどこまでを測っているか。 | 工程定義、開始条件、終了条件、従来方式との比較範囲を確認する。 | 一部工程の短縮が刷新全体の完了として解釈される。 |
| 追跡可能性 | 仕様候補がどのコード、文書、実行結果から導かれ、どの成果物へ反映されたか確認できるか。 | 仕様候補から設計、コード、試験、判断記録までの対応関係を残す。 | 誤りを発見しても、同じ前提から作られた修正対象を確定できない。 |
| 判断主体 | 仕様の採用、廃止、差分許容、本番移行を決める責任者が定まっているか。 | 決定事項、承認者、根拠、判断日、保留条件を記録する。 | 技術成果物は完成しても、業務上の責任を引き受ける主体がなく受入段階で停止する。 |
| 権限制御 | AI が参照、変更、実行、外部接続できる対象が工程と危険度に応じて制限されているか。 | 実行環境、アクセス権、変更可能範囲、承認経路、停止条件を確認する。 | 誤った解釈や不適切な操作が、コード、データ、接続先へ連鎖する。 |
| 独立検証 | 生成時とは異なる情報源と合格基準を使って、結果を反証できるか。 | 旧システムの実行結果、実データ、業務受入条件、契約、監査要件を使う。 | コードとテストが同じ誤りを共有し、生成物同士の一致が正しさとして扱われる。 |
| 再現性 | 入力資産、モデル、指示、設定、ツール、実行結果、承認履歴を後から確認できるか。 | 版管理された入力と成果物、実行記録、利用モデル、設定値を保存する。 | 差分の原因を特定できず、同じ移行判断を再検証できない。 |
| 復旧可能性 | 誤変換や本番障害が起きたとき、影響を限定し、変更前の状態へ戻せるか。 | 段階移行、切戻し手順、データ照合、復旧試験、責任者の連絡経路を確認する。 | 短期間で変更できても、失敗時の停止時間とデータ損失が拡大する。 |
| 移行後の更新 | 設計情報、判断根拠、試験、運用手順を新システムの変更に合わせて保守できるか。 | 日常の変更工程に文書と試験の更新条件を組み込み、保守責任者を定める。 | 新しいシステムが数年後に再びブラックボックス化する。 |
これらの評価軸は、短縮率を否定するためのものではない。どの作業が短くなり、その代わりにどの判断や確認が増えたかを明らかにするためにある。現行解析が数か月から数日へ短縮されても、仕様差分の承認に数か月を要するなら、次に改善すべき対象は解析モデルではなく、差分を分類して適切な責任者へ渡す工程である。指標を工程へ対応付けることで、短縮率を宣伝上の数字ではなく、次の制約を発見する観測値として使える。
NIST の AI リスク管理枠組みは、AI に関する危険を統治し、把握し、測定し、管理する循環と、人間による監督の必要性を示している[25]。この枠組みがレガシー解析、仕様選択、コード変換、移行試験といったモダナイゼーション固有の工程を定めているわけではない。そのため、枠組みだけから個別の試験項目や承認条件を導くことはできない。
一方、AI の出力精度を一度測って導入可否を決めるのではなく、利用状況、影響を受ける主体、失敗時の重大性に応じて統制を更新する考え方は、モダナイゼーションの評価に適用できる。現行解析で誤った機能分類が生じた場合と、本番データの変換で誤更新が生じた場合では、必要な権限制限、検証、復旧手段が異なる。工程ごとに危険と証拠を対応させることで、人間による監督を一律の目視確認ではなく、影響の大きい判断へ集中させられる。
移行時に設計書とテストを生成しても、その後の変更で更新されなければ、数年後にはコードだけが再び現行仕様になる。設計書と実装の差異が増えれば、次の担当者は再びコードから仕様を推定しなければならず、今回復元した知識と判断根拠は失われる。移行時の文書生成は、一時的な納品物を増やすだけではレガシー化を防げない。
AI モダナイゼーションの成果は、移行日に新システムが動くことだけでは測れない。仕様変更のたびに根拠、コード、試験、運用手順を同じ変更単位で更新できるか、判断主体が交代しても過去の決定を追跡できるか、障害時に期待した状態へ戻せるかまでが評価対象になる。短縮率が示すのは移行時点までの速度であり、変更可能性が示すのは移行後に同じレガシー化を繰り返さない能力である。
11. AI はレガシー刷新の作業量ではなく制約の位置を変える
常石造船の「2 年から 2 日」は、システム刷新の全工程が自動化されたことを示す数字ではない。短縮された中心工程は、数千本以上の既存プログラムを読み、構造と技術的負債を把握し、業務領域の再設計を検討する部分である。それでも、現行資産の規模と依存関係を早期に把握できれば、予算、期間、移行方法を比較し、従来は調査費用のために着手できなかったシステムを刷新候補へ戻せる。
入口が開くと、復元された挙動から将来仕様を選ぶ判断と、採用した仕様について業務結果、データ更新、外部連携、性能、権限制御、障害復旧、監査証跡が保たれたことを示す検証が次の制約になる。コードとテストを同じ解釈から生成すれば両者が同じ誤りを共有するため、旧システムの実行結果、実データ、契約、業務受入条件など、生成時とは異なる根拠も必要になる。
コード変換が速くなるほど、仕様選択と等価性の証明が工程全体に占める割合は大きくなる。これは、従来の作業がそのまま残るという意味ではない。人間によるコード読解と書き換えが減る一方で、差異の採否を決める業務責任、許容する変更を定める権限、移行を認める証拠の設計が、工程上の明示的な仕事になる。AI は作業を単純に消すのではなく、暗黙だった判断を可視化された待ち行列へ変える。
AI によってモダナイゼーションのボトルネックは、コード変換から仕様の選択と等価性の証明へ移る。これは AI の能力不足によって自動化されずに残った作業ではない。機械が大量の現行資産を読み、依存関係を整理し、変更案と試験を生成できるようになったため、何を残し、何を廃止し、どこまでの差異を認め、どの証拠をもって移行を承認するかが、以前より明確な制約として現れたのである。
この制約へ対応するには、AI の精度を高めるだけでは足りない。仕様候補の出典と影響を追跡し、採否を決める責任者へ渡し、変更権限を影響範囲に応じて制限し、生成時とは別の情報源で結果を反証する工程が必要になる。これらが分離されていれば、低リスクの定型変換は自動化し、高リスクの差分だけを人間の判断へ集められる。分離されていなければ、生成速度は未確定仕様と共通誤解を広範囲へ固定する速度にもなる。
レガシーから脱却するとは、古い言語を新しい言語へ置き換えることではない。システムの挙動について、根拠を追跡でき、変更の責任者を特定でき、影響範囲を制御でき、結果を独立した証拠で検証できる状態へ戻すことである。新しい言語と基盤へ移しても、この状態が成立しなければ、内部を説明できず変更できないというレガシーの条件は保存される。
AI が速くするのは、その状態へ到達するための読解、関連付け、変換、試験の反復である。人間に残るのは、数千本のコードを順番に読み、定型的な変換を手作業で繰り返す仕事ではない。どの挙動を将来へ残すか、どの差異を受け入れるか、どの証拠があれば業務を新システムへ移せるかを決め、その判断に責任を持つ仕事である。
「2 年から 2 日」という数字が示す本質は、刷新全体が二日で終わることではなく、これまで現行解析の背後に隠れていた判断を、早い段階で扱えるようになることである。AI モダナイゼーションの成否は、生成されたコードの量ではなく、表面化した仕様差分を決定へ変え、その決定を検証可能な新システムへ引き渡せるかによって決まる。
参考文献
- 遠藤文康, 塩漬け“17 年”のレガシー刷新作業を「2 年→2 日に短縮」 常石造船の事例で見えた、AI プロジェクトの成否（2026-06-23）. https://atmarkit.itmedia.co.jp/ait/articles/2606/23/news029.html
- ＠IT, 常石造船はなぜ「延命を続けたレガシーシステム」の刷新を“一気に”進められたのか？（2026-06-29）. https://atmarkit.itmedia.co.jp/ait/articles/2606/29/news054.html
- 経済産業省、デジタル庁、IPA, DX の現在地とレガシーシステム脱却に向けて（2025-05-28）. https://www.ipa.go.jp/disc/committee/begoj90000002xuk-att/legacy-system-modernization-committee-20250528-report.pdf
- IPA, レガシーシステムモダン化委員会. https://www.ipa.go.jp/disc/committee/legacy-system-modernization-comittee.html
- IPA, 2024 年度ソフトウェア動向調査 調査結果データの公開と分析レポートの募集. https://www.ipa.go.jp/digital/software-survey/software-engineering/result-software2024.html
- 三好将司, レガシーシステムのモダナイゼーションを加速する、生成 AI の活用法（2025-07-23）. https://www.nttdata.com/jp/ja/trends/data-insight/2025/0723/
- デジタル・インフォメーション・テクノロジー, 生成 AI を活用したシステムのモダナイゼーション. https://www.ditgroup.jp/showcase/case34.html
- 富士通株式会社, 生成 AI とモダナイゼーション実践知でレガシーシステムの刷新を加速する「Fujitsu AI ドリブンモダナイゼーションサービス」を提供開始（2026-07-14）. https://global.fujitsu/ja-jp/pr/news/2026/07/14-01
- 日川佳三、河原潤, 富士通、レガシーシステムのリライト／リホストを生成 AI で支援、移行期間を 4 割短縮（2026-07-15）. https://it.impress.co.jp/articles/-/29582
- Cognizant, AI モダナイゼーション：レガシー基盤に埋もれたコンテキストを解き放つ. https://www.cognizant.com/jp/ja/services/ai/ai-modernization
- Birgitta Böckeler, Carlos Cuesta, Pratap Lakshman, Legacy Modernization meets GenAI（2024-09-24）. https://martinfowler.com/articles/legacy-modernization-gen-ai.html
- Shivali Agarwal, Sridhar Chimalakonda, Saravanan Krishnan, Vini Kanvar, Samveg Shah, Legacy Software Modernization: A Journey From Non-AI to Generative AI Approaches（2024-02-22）. https://research.ibm.com/publications/legacy-software-modernization-a-journey-from-non-ai-to-generative-ai-approaches
- Lola Solovyeva et al., Leveraging LLMs for Automated Translation of Legacy Code: A Case Study on PL/SQL to Java Transformation（2025-08-27）. https://arxiv.org/abs/2508.19663
- Colin Diggs et al., Leveraging LLMs for Legacy Code Modernization（2024-11-22）. https://arxiv.org/abs/2411.14971
- Haowei Cheng et al., Generative AI for Requirements Engineering: A Systematic Literature Review（2024-09-10）. https://arxiv.org/abs/2409.06741
- Matteo Esposito et al., Generative AI for Software Architecture: Applications, Trends, Challenges, and Future Directions（2025-03-17）. https://arxiv.org/abs/2503.13310
- Sanderson Oliveira de Macedo, Ronaldo Martins da Costa, Reversa: A Reverse Documentation Engineering Framework for Converting Legacy Software into Operational Specifications for AI Agents（2026-05-18）. https://arxiv.org/abs/2605.18684
- Sheikh Nazib Ahmed, Marnim Galib, AgentModernize: Preserving Business Logic in Legacy Modernization with Multi-Agent LLMs and Behavioral Specification Graphs（2026-05-17）. https://arxiv.org/abs/2605.17535
- Valtteri Ala-Salmi et al., VAPU: System for Autonomous Legacy Code Modernization（2025-10-21）. https://arxiv.org/abs/2510.18509
- Naing Oo Lwin, Rajesh Kumar, Deterministic vs. LLM-Controlled Orchestration for COBOL-to-Python Modernization（2026-05-11）. https://arxiv.org/abs/2605.09894
- Vincent Gurgul, Robin Gubela, Stefan Lessmann, The State of Generative AI in Software Development: Insights from Literature and a Developer Survey（2026-03-17）. https://arxiv.org/abs/2603.16975
- id774, AI モダナイゼーションはモデルではなく工程を変える（2026-07-21）. https://blog.id774.net/entry/2026/07/21/5118/
- id774, 2026 年上期の Devin の進化を振り返る（2026-07-10）. https://blog.id774.net/entry/2026/07/10/4976/
- id774, 最新 AI は何が変わったのか 2026（2026-07-03）. https://blog.id774.net/entry/2026/07/03/4937/
- NIST, Artificial Intelligence Risk Management Framework 1.0（2023-01）. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf