仕様書に理由が書かれていない例外処理を見つけたとき、削除してよいか判断するのは容易ではありません。過去の障害や取引上の条件を踏まえて、その処理が加えられた可能性があるためです。AIエージェントによって、既存コードの資料化や新しい言語への変換は進めやすくなりました。しかし、長年動いてきたシステムには、コードだけでは読み取れない運用の経験も蓄積されています。何を残し、何を移行し、何を捨てるかを判断するには、運用者の知識と経験を引き継ぐ作業が欠かせません。
【シリーズ「AIトランスフォーメーション（AX）」】
AIエージェントはどこまで届く？MCPが広げる可能性とリスク
GeminiはAIモデル競争から脱落したのか？Googleの勝ち筋とは
「Claude Fable 5」規制騒動から考えるモデルルーティング戦略の必要性
ダッシュボードで「見える化」する時代は終わったのか
「A2A」でAIエージェント同士をつなぐ！期待が先行する技術の実像と課題
「AIの暴走」を止められるか？AIエージェント時代のリスク管理
Hugging Face事件を技術報告から読み解く！AIエージェントの責任境界はどこにあるのか
AIの競争軸は「価格」から「仕事単価」へ！AIが実際に稼ぎ出す利益をどう測るか
なぜ日本企業のDXとAXは進みにくいのか？雇用制度の違いから読み解く
GrokとMicrosoft Officeの連携は何を生み出すのか？進化するExcelと今後の課題
Jevが注目される理由とは？AIエージェントの安定運用を支える判定モデルの真価
リバースエンジニアリングの歴史
コードは残っていても、設計を説明する資料が見当たらないシステムでは、まず実装と動作から仕組みを読み解く必要があります。互換機の開発やソフトウェア保守を支えてきたリバースエンジニアリングは、AIによる解析と資料化によって、既存システムを見直すための手段としても重要性を増しています。
完成したシステムから仕組みを読み解く
リバースエンジニアリングとは、既存システムを分析し、構成要素や相互の関係を明らかにして、別の形式や、より抽象度の高い表現にまとめる活動です。通常の開発では、必要な業務や機能を決め、設計してから実装します。リバースエンジニアリングでは、実装されたプログラムや実際の動作を調べ、処理の流れや構成を読み解きます。得られた情報を図や説明にまとめると、コードを一行ずつ追うだけでは把握しにくい全体像を確認できます。
例えば、請求処理のコードには、日付の比較、取引の分類、金額の集計などが記述されています。関連するプログラムやデータを合わせて調べると、どの取引を当月の請求に含め、どの条件で翌月へ回すのかを整理できます。個別の命令を読み解いた結果を、業務上のルールとして説明し直すわけです。プログラム間の呼び出し関係や、データを受け渡す順序も、改修の影響を調べる材料になります。
解析した内容は、設計資料の作成や改修範囲の検討に使えます。処理の流れを基に、変更する部分と影響を確認する部分を具体的に挙げ、その内容を移行先の要件や設計へ反映します。既存の実装を理解したうえで、こうして定めた範囲の設計やテストに着手します。
互換機開発から既存ソフトウェアの保守へ
1980年代のIBM PC互換機開発は、リバースエンジニアリングが製品の互換性を支えた代表的な事例です。IBM PC向けに作られたソフトウェアを別のコンピューターで動かすには、必要な機能や動作を再現する必要がありました。その要素の一つが、コンピューターの基本的な入出力を扱うBIOSです。CompaqはMicrosoftからMS-DOSのライセンスを受け、IBMのBIOSをリバースエンジニアリングして互換機を開発しました。
Computer History Museumは、ColumbiaによるBIOSの独自実装も紹介しています。Columbiaでは、IBMのコードを参照しないクリーンルーム環境で、同等の機能を実装しました。クリーンルームとは、元のコードを実装者が参照しないようにする方法です。既存製品に求められる動作を把握し、別の実装で再現する作業が、互換性のある製品の開発を支えました。
ソフトウェア保守の分野でも、実装から構造や設計を読み解く活動が研究されてきました。1990年には、Elliot J. ChikofskyとJames H. Cross IIが、リバースエンジニアリングと設計復元に関する用語を整理した論文を発表しています。既存システムの仕組みを資料にまとめ直す活動や、設計を読み解く活動を整理し、それぞれの関係を示しました。こうした研究からも、動いているソフトウェアを理解する作業が、長く開発・保守の課題になっていたと分かります。
技術負債を解消するために現状を理解する
技術負債とは、将来の変更や保守に追加の負担を生む、実装や設計上の問題です。Ward Cunninghamは1992年、未成熟なコードを出荷する行為を借金に例えました。早い段階で書き直して整理するのであれば、開発を進められます。ただし、整理を先送りすると、不十分なコードへの対応に費やす時間が利息として積み重なります。変更のたびに広い範囲を調べる必要がある実装や、影響を確かめにくい構造は、改修を続けるうえで負担になります。
技術負債を片付けるには、どの構造や処理が、その負担を生んでいるかを調べる必要があります。使用年数だけでは、改修すべき箇所を判断できません。依存関係、変更の多い部分、障害時に調査が難しい部分を把握して、手を加える範囲を決めます。リバースエンジニアリングで得た資料は、複雑な処理を理解し、整理する順序を考えるために使えます。
米カーネギーメロン大学ソフトウェア工学研究所が2001年に公表した報告書では、既存の仕組みと新しい仕組みを併用しながら、システムを段階的に近代化する方法が紹介されています。一部ずつ改修する場合も、プログラムやデータがどう関係しているかを把握する必要があります。現状を理解してから移行範囲を決めるという手順は、既存業務を続けながら技術負債を解消する際にも有効です。
AIが境界値や例外処理の資料化を支援する
AIは、既存コードの解析や資料化から、新しい実装への変換までを支援します。例えばAWS Transformは、メインフレームのコード分析、技術資料の生成、業務ロジックの抽出、コード変換を提供しています。メインフレームとは、大規模な業務処理などに使われる大型コンピューターです。同サービスには、COBOLで書かれた処理をJavaのアプリケーションへ変換する機能もあります。
AIエージェントによる資料化では、処理の概要に加え、場合分け、条件が切り替わる境界値、例外時の動作を確認できます。例えば、締め日の当日を含むか、入力が欠けたときにどの処理へ進むか、途中で失敗した後に何を再実行するかを整理します。関連するコードを調べ、説明の草案を作らせると、人は元の処理と照合しながら確認を進められます。
AWSが2025年12月に公開した手順では、既存コードから業務ルールを抽出した後、AIエージェントで仕様とコードを生成し、展開とテストを行います。今後は、解析、資料化、実装、検証を連携させてAIを活用することが、さらに重要になると考えられます。その過程では、処理の説明を得るだけでなく、それぞれの処理を新しいシステムへ引き継ぐ理由も確認する必要があります。この判断が、移行の成否を左右します。
蓄積された経験とリプレースに求められる品質
長年使われてきたレガシーシステムには、障害への対応、取引上の条件、日々の運用判断が積み重なっています。古いコードを整理するときには、その複雑さを生んだ経緯も確かめる必要があります。現在の業務を支えてきた経験を見落とすと、新しい実装に置き換えても、利用者が求める品質を満たせなくなります。
複雑な処理に残る運用経験
例えば、請求の締め日が休日の場合に、処理日を調整する分岐があるとします。コードから、どの日付を比較し、どの取引を対象にするかは調べられます。しかし、その条件が取引先との取り決めによるものか、遅れて届くデータに対応するためかによって、変更の可否は変わります。複雑に見える条件の中にも、実務で必要になった対応が含まれています。
プログラムの外にある作業も、業務を支えています。例えば、外部データの到着が遅れた日は、担当者が未着を確認し、取込処理を再実行している場合があります。再実行の時刻や確認先、締め処理との前後関係を担当者が決めている場合、そうした判断も業務を支えています。プログラムの正常終了だけを確認しても、こうした対応を新しい運用へ引き継げるかは分かりません。
レガシーシステムを見直す際には、コード、設定、処理の順序、担当者の作業を合わせて確認する必要があります。AWSの解析に関する解説も、業務ロジックがプログラム、バッチの実行順序、共通のデータ定義などに分散する問題を指摘しています。処理の背景まで理解して、現在も必要なルールと、環境の制約を補ってきた対応を見極めることが、経験を生かした改修につながります。
リプレースに要求される品質水準
実際に動いているシステムのリプレースには、新規開発よりも高い品質水準が要求されます。既存のシステムでは業務が続いており、その動作は利用者が日々の利用を通じて確かめてきたものです。新しいシステムでも、必要な機能、過去のデータ、取引先や外部システムとの連携を引き継ぎ、業務を続けられる状態にする責任があります。仕様書に明記されていない対応も、その対象になります。
例えば、年度末だけ実行する集計や補正処理は、通常月の操作を確認するだけでは検証できません。新しい画面から日常の業務を行えても、年次の処理を引き継いでいなければ、必要な時期に問題が表面化します。利用頻度の低い機能も、利用する場面、処理の条件、結果を受け取る担当者まで確認する必要があります。既存の運用と比較されるため、通常時の使いやすさに加え、年次処理などを適切に実行できるかどうかも問われます。
途中で処理が失敗した場合には、業務を再開するための復旧手順も検証します。データの一部を更新した後で処理を再実行する場合は、更新済みのデータの扱い方と、重複処理を防ぐ方法を確かめます。外部へのデータ送信が始まっている場合は、どこまで送信済みかも確認します。現行システムで運用者が確認してきた項目を基に、新しいシステムでも、復旧後に期待どおりの処理結果が得られるかを検証します。
コードを変換した後にも判断が残る
AIを活用して、レガシーコードを読み解き、モダンな言語へ置き換える作業を進められます。しかし、単純に変換を実行するのは危険です。必要な条件や例外対応を取りこぼすと、業務に必要な動作が失われます。既存の処理をすべて引き継ぐ場合には、すでに役割を終えた機能や、不要になった暫定対応まで、新しいシステムに持ち込む可能性があります。
処理を整理する前に、その処理を必要とする業務と、現在も使われている理由を確かめます。例えば、手作業で行ってきた再実行を自動化する際には、運用者が再実行の前に何を確認していたかを調べます。確認作業を省いたまま自動化すると、従来は担当者の判断で防いでいた問題を起こしかねません。実装をどう変えるかは、それまでの運用を理解したうえで判断します。
AWSが紹介するAIによる移行手順でも、生成された仕様やコードを業務の専門家が確認する工程を重視しています。移行では、維持する動作と、改善のために変更する動作を決め、それぞれに合った要件と検証方法を用意します。何を残し、何を移行し、何を捨てるかという判断が、技術負債の解消で最も重要です。 AIの解析や変換は、その判断に基づいて進める必要があります。
資料不足より深刻な運用者の不在
既存システムの理解を難しくする問題は、以前から指摘されています。IBM Researchが2022年に公表した研究では、資料が更新されておらず、開発や設計を担当した人もすでにいない状況を挙げています。こうした状況では、近代化に加えて、通常の保守のためにシステムを理解する作業も難しくなります。AIによる資料化は、残されたコードから処理を調べる助けになります。
ところが、コードを説明する資料ができても、当時の判断理由や、現場で守ってきた前提を確認できるとは限りません。例えば、再実行の手順を説明できても、その前に取引先へ確認していた事情や、過去に別の対応を試して断念した理由は、運用者の経験の中に残っている場合があります。その経験が失われると、同じ問題を避けるために、何を確かめるべきかも分からなくなります。
レガシーシステムの扱いでは、資料不足以上に、当時の運用者がいないことが深刻な問題になります。どの例外を残すべきか、どの手順を変えてよいかを確認する相手が失われるためです。AIで資料を補えても、運用の知識や経験が残っていなければ問題は解決しません。運用者と処理の背景を確認できる今は、その経験を知識として残す貴重な機会です。
何を残し、何を移行し、何を捨てるか
運用経験を引き継ぐ作業は、全面的なリプレースの計画が決まる前から始められます。現在の運用者とともに、例外処理や手作業が必要になった理由を確かめ、次の担当者が使える記録へまとめます。その知識を基に、維持する業務ルール、移行する実装、廃止する機能を判断していきます。
運用者が残っているうちに経験を記録する
まず、コード、設定、データ定義、バッチ、外部連携、運用手順、障害記録を集め、関連する処理を整理しましょう。バッチとは、複数の処理をまとめて実行する仕組みです。AIには、各処理の役割や条件分岐を調べさせ、運用者へ確認する項目の草案を作らせます。解析した説明と、根拠となるコードや設定を対応付けると、聞き取りの際に具体的な処理を示せます。
運用者への聞き取りでは、実際の画面や作業手順を一緒に確認します。日常の操作に加えて、月次・年次処理、入力の欠落、外部連携の遅延、失敗時の対処を取り上げます。NASAの知識継承ガイドも、日常の作業で何を考えているかを後任に説明し、定期的な作業、繰り返し起こる問題、対処方法、経験から得た教訓を確認するよう勧めています。作業を見ながら、その都度、判断の理由を聞く方法が有効です。
聞き取りでは、処理を加えたきっかけ、当時の制約、採用しなかった対応、現在も必要な理由まで記録しましょう。対象の処理やデータ、根拠となるコードの版、確認した人と日付も残します。未解決の疑問は、確認済みの内容と区別して記載します。そのうえで、聞き取った内容をAIで整理し、本人に内容を確認してもらいます。処理の説明と、その背景や判断理由を併せて記録し、次の改修で参照できる知識として残します。
業務上の価値を基に移行方針を決める
残す対象は、現在も必要な業務ルール、例外への対応、外部との取り決めです。現行の仕組みのうち、どの部分を使い続けるかも、業務上の価値と改修の負担を基に決めます。例えば、利用頻度が低い集計でも、年度末の業務に必要な場合があります。短期間のログに実行記録が見当たらなくても、使う時期、結果を受け取る担当者、廃止した場合の影響を確かめてから判断しましょう。
移行にあたっては、業務上の役割を引き継ぎながら、実装、データ、連携方法を新しい環境へ移します。締め日に関する取り決めを維持し、そのルールに従って計算するプログラムを新しくするなど、業務ルールの維持と実装の移行を組み合わせます。手作業で補ってきた処理を新しい実装に含める際には、運用者が確認していた条件を要件へ反映します。どの部分を自動化し、どこで人が確認するかも、この段階で決めます。
捨てる対象は、終了した業務の機能、不要な重複処理、現在の環境では役割を終えた暫定対応です。廃止の判断には、利用状況に加え、業務担当者の確認が必要です。関係する処理やデータへの影響を調べ、何を根拠に廃止できると判断したかを記録します。維持・移行・廃止のいずれも、判断理由、確認した人、関係する業務、検証方法をまとめ、移行先の要件へ反映します。
運用経験をテストへ反映する
聞き取った経験は、具体的な状況を再現するテストシナリオにします。AWS Transformでも、抽出した業務ルールをテスト計画に利用し、ルールとテストを対応付ける方法が提供されています。例えば、外部データの到着が遅れた場合には、入力データの状態、処理を開始する条件、運用者が確認する事項、最終的に得るべき結果を決めます。AIが作成したテスト案にも、過去に問題となった条件を加えましょう。
締め処理では、締め日の直前・当日・直後や休日の動作に加え、データが遅れて届いた場合の動作も確認します。再実行の処理では、正常に終了するかを確認するとともに、途中で失敗した場合や、同じデータを再び処理した場合のデータの更新結果も確かめます。外部へ送信する処理がある場合には、送信済みかどうかを含めて確認します。運用者が経験してきた例外を、入力条件と期待する結果の組み合わせとして記録すると、移行先でも検証できます。
維持すると決めた動作については、新旧システムの出力やデータの更新結果を比較します。改善のために変更する動作は、新しい要件を満たしているかを検証します。例えば、従来の手作業を自動化する場合には、確認のタイミングや失敗時の対応まで含めた受入条件を、業務担当者と確かめます。資料、判断理由、要件、テストを対応付けると、変更時に何を確かめる必要があるかを把握しやすくなります。
小さく移行し、判断の記録を更新する
着手する部分は、業務への影響、変更頻度、障害の影響、調査と改修の負担を基に選びます。Martin Fowlerが紹介するStrangler Figは、既存システムと新しい実装を共存させながら、段階的に置き換える方法です。小さな単位で移行するためには、処理やデータの依存関係を調べ、どこで分けられるかを検討します。解析資料と運用者の知識は、この区切りを決める際にも役立ちます。
新旧システムの共存中には、データの受け渡し、処理の順序、失敗時の対処を確認します。切替の条件と確認担当者、問題が起きた場合の対応も決めましょう。特に、切替後に更新したデータや、外部へ送信したデータをどう扱うかは、復旧の手順に関わります。切替の判断に使う確認結果をまとめ、業務を継続する手順とともに運用担当者と共有します。
移行後も、改修や障害対応で分かった内容を、仕様、運用手順、判断理由、テストへ反映し続けます。NASAの知識継承に関するガイドも、知識や教訓の記録を日常業務に組み込む方法を勧めています。変更の理由と検証結果が記録されていれば、次の担当者は、その情報から現在の動作が必要な理由を理解できます。記録を参照し、新しい判断を加えて更新する習慣が、次の改修の負担を抑えます。
まとめ
AIによって、レガシーシステムの解析、資料化、コード変換を進めやすくなりました。長年かけて加えられた条件分岐や例外処理を整理し、新しい実装を検討するための材料を得られます。その材料を基に、業務を支えるルール、移行すべき実装、役割を終えた機能を見極めることが重要です。
レガシーシステムの扱いでは、これまで「資料がないこと」が問題にされがちでした。だが、資料以上に深刻なのは、「当時の運用者がいないこと」です。処理を読み解く資料をAIで補えても、その処理が必要になった理由や、例外時の対応を判断してきた経験が失われていれば、何を引き継ぐべきかを確かめられません。資料の不足を補うだけでは、この問題は解決しません。
今やるべきことは、運用者が残っているうちに、その経験を知識化することです。 全面的なリプレースの決定を待たず、現在の処理を一緒に確認し、過去の判断理由、手作業で補っている対応、失敗時の対処を記録しましょう。得られた知識を仕様とテストへ反映し、次の担当者が使える形で残しましょう。その積み重ねが、蓄積された経験を生かしながら技術負債を片付けるための土台になります。
参考文献
Amazon Web Services：Modernization of mainframe applications — AWS Transform
この記事を書いた人
