仕様書がなく作った人もいないレガシーシステムを、AIコーディングエージェントで解読・仕様復元し、段階的に置き換えるアプローチを解説します。一括リプレースとの比較、周辺ツールから始める現実的な順序、権限とリスク管理まで、情シス責任者の視点で整理します。
老朽化した社内システムの刷新は、多くの情報システム部門にとって長年の懸案でありながら、実際にはなかなか着手できないテーマです。予算が承認され、経営層の理解が得られたとしても、いざ動き出すと止まってしまう。その原因を「エンジニアが足りないから」「移行に金がかかるから」とだけ捉えると、本質を見誤る可能性があると考えています。
10年、15年と稼働してきた基幹系や業務システムには、いくつかの共通した特徴があると考えられます。第一に、仕様書が存在しない、あるいは初期のものしか残っておらず現行と乖離している。第二に、開発した本人や当時のベンダー担当者がすでにおらず、改修履歴の意図を説明できる人がいない。第三に、度重なる小改修の積み重ねで、コードのどの部分が実際の業務で使われ、どの分岐が過去の名残なのかが判別できなくなっている。
このような状態を、しばしば「ブラックボックス化」と呼びます。刷新プロジェクトが止まる最大の要因は、新しい技術の選定でも移行ツールの不足でもなく、「置き換える前に、まず現行が何をしているかを正確に把握しなければならない」という、地味で膨大な解読作業にあると考えられます。この工程は成果が見えにくく、担当者の心理的な負荷も高いため、着手そのものが先送りされがちです。
ブラックボックス化したシステムは、往々にして「よく分からないが動いているので触らない」という運用に落ち着きます。短期的には合理的な判断に見えますが、この状態が続くほど、担当者の記憶はさらに薄れ、周辺技術のサポート終了が迫り、いざ改修が必要になったときの難易度は上がっていきます。動いている資産が、時間の経過とともに解読不能な負債へと変質していく構図です。
加えて、こうしたシステムほど日々の業務に深く組み込まれているため、止めることも作り直すこともできないという二重の拘束が生まれます。情シス責任者の立場では、リスクを認識しながらも打ち手を欠く、という苦しい状況が長期化しやすいと考えられます。
従来、この解読作業は経験豊富なエンジニアがソースコードを一行ずつ読み、業務担当者にヒアリングを重ねて仕様を復元する、という進め方が中心でした。しかし、この作業は総量が事前に見積もれません。どこまで読めば全体が把握できるのか、隠れた分岐がいくつあるのか、着手前には分からないためです。工数が読めないタスクは予算化しづらく、結果として「いつかやる」に据え置かれます。
本記事では、この解読・仕様復元・段階的な置き換えという一連の流れに、AIコーディングエージェントをどう組み込みうるかを整理します。ツールが万能だと主張するものではありません。むしろ、どこに使え、どこに使うべきでないかの線引きこそが、情シス責任者にとって実務的な論点だと考えています。
AIコーディングエージェントとは、自然言語の指示を受けてソースコードを読み、変更を提案し、場合によっては実行までを担う自律的な開発支援の仕組みを指します。IDE内でコードを補完する従来型の支援と異なり、リポジトリ全体を横断して文脈を把握し、複数ファイルにまたがる作業を進められる点が特徴だと考えられます。レガシー刷新の文脈では、コードを新しく書く能力よりも、既存コードを「読んで説明する」能力の方がまず価値を持つ場面が多いと見ています。
解読工程で最初に効くのは、コードベース全体を読ませて構造の見取り図を作らせる使い方だと考えられます。どのファイルが何の機能を担い、どこからどこへデータが流れ、外部システムとの接点がどこにあるか。人が数週間かけて追う全体像の初稿を、エージェントに素早く出させ、それを人が検証していく進め方です。あくまで初稿であり、鵜呑みにはできませんが、白紙から始めるのと叩き台があるのとでは、心理的にも工数的にも差が出る可能性があります。
特定の関数や画面が「実際にどの業務で呼ばれているか」を追跡させる使い方も有効だと考えられます。過去の名残で残っているだけのデッドコードなのか、今も動いている経路なのかを切り分ける手がかりを、呼び出し関係の解析から得られる場合があります。
次の段階は、読み取った内容を業務仕様の形に言語化させる使い方です。コードの振る舞いを日本語で説明させ、入力・処理・出力・例外処理の分岐を一覧化させる。これは仕様書そのものではなく、あくまで「コードから逆算した仕様の下書き」ですが、業務担当者がレビューする際の共通言語になります。「コードはこう動いていますが、業務上は正しいですか」と問える状態を作ることが、仕様復元の実務では重要だと考えられます。
ここで生成された下書きは、そのまま新しいドキュメント資産として蓄積する価値があります。刷新の副産物として、これまで存在しなかった仕様書が整備されていく。これは次の担当者への引き継ぎ資産にもなり、単なる置き換え以上の意味を持つと考えられます。
一方で、AIコーディングエージェントの出力は常に正しいわけではありません。存在しない仕様を「もっともらしく」補完してしまう、いわゆるハルシネーションのリスクは、コード解読の文脈でも残ります。読み取った内容と、AIが一般論から推測で埋めた内容が、出力上は区別なく提示されることがある点に注意が必要です。
したがって、エージェントの出力は「検証すべき仮説」として扱うのが妥当だと考えられます。生成された仕様の下書きは、必ず実際の挙動やデータと突き合わせて確認する。この検証を省くと、誤った仕様書を新たに作り込むことになり、かえって混乱を招きかねません。AIを使うか使わないかではなく、使ったうえで人がどう検証するかが問われます。
解読の目処が立ったら、次は置き換えの戦略です。ここでの判断が、プロジェクト全体の成否を大きく左右すると考えられます。AIコーディングエージェントが使えるようになったからといって、これまで難しかった一括リプレースが急に現実的になる、と考えるのは早計だと見ています。
一括リプレースは、古いシステムを新しいシステムに一度で置き換える手法です。設計が新しく揃い、技術的負債を一掃できる魅力があります。しかし、旧システムの全仕様が正確に把握できていることが前提であり、ブラックボックス化した資産に対してはその前提自体が崩れています。把握しきれていない機能を新システムが取りこぼせば、カットオーバー時に業務が止まるリスクを負います。
AIエージェントを使えば解読が速く進む可能性はありますが、それは「一括リプレースの前提を満たしやすくなる」ことを意味するのであって、「検証なしで一気に作り替えてよい」ことを意味しません。むしろ、生成されたコードや仕様の検証量が増えるため、一括であればあるほど検証のボトルネックが集中する点に注意が必要だと考えられます。
より現実的なのは、旧システムを稼働させたまま、機能を少しずつ新しい実装に置き換えていく段階的なアプローチだと考えられます。周辺の独立した機能から新しく作り、旧システムの該当部分を徐々に無効化していく。全体を一度に止めずに移行できるため、リスクを小さな単位に分割できます。
この進め方は、AIコーディングエージェントとの相性が良いと考えられます。置き換える単位が小さければ、解読・仕様復元・再実装・検証のサイクルを一つの機能で完結させられ、AIの出力を人が検証しきれる規模に収まります。失敗しても影響範囲が限定され、学びを次の単位に活かせます。段階を重ねるほど、チームもエージェントの使い方に習熟していく副次効果も期待できます。
戦略と並行して、この刷新を内製で進めるか外部に委託するかという判断も避けられません。AIエージェントの登場で、これまで外注一択だった領域を内製で担える可能性が広がりつつあると考えられますが、判断軸は「作れるか」だけではありません。むしろ「刷新後に誰が保守し続けるのか」を起点に考えるべきだと見ています。この論点は社内AIエージェントは内製か外注かで詳しく整理していますので、あわせてご参照ください。刷新でせっかく解読したシステムを、再び説明できる人がいない状態に戻さないための体制設計が重要です。
段階的置き換えを選んだとして、では最初の一手をどこに置くか。ここで基幹の中核から手をつけるのは、リスクの面でも学習の面でも得策ではないと考えられます。まずは失敗しても業務が止まらない周辺から始め、チームとエージェントの両方が経験を積む順序が現実的だと見ています。
最初に取り組むべきは、何かを書き換えることではなく、現行システムを「読んで理解する」ことに徹する段階だと考えられます。エージェントには読み取り権限のみを与え、コードの構造説明、仕様の下書き生成、データフローの可視化といった、既存資産に一切変更を加えない作業を任せます。この段階の成果物は、後続すべての土台になります。
この段階で得た理解を、社内で共有できる形に集約しておくことも重要です。復元した仕様やシステム構成図を、いわゆる社内ナレッジ基盤に蓄積し、属人化を防ぐ。刷新の第一の成果は「動くコード」ではなく「説明できる状態」だと捉えると、進め方がぶれにくくなると考えられます。
次に、帳票出力、データ変換、定型レポート生成、参照系の画面といった、基幹の中核から切り離しやすい周辺機能を新しく作り替えます。これらは仕様が比較的単純で、出力を旧システムと突き合わせて正しさを検証しやすいという利点があります。旧システムの出力を正解データとして、新実装が同じ結果を返すかを比較すれば、検証の客観性を確保できると考えられます。
この段階を通じて、チームはエージェントへの指示の出し方、生成物のレビュー観点、検証の勘所を実地で学べます。周辺ツールの内製そのものについては、AIエージェントと社内システムの連携設計で、既存システムとの接続をどう設計するかを扱っていますので参考になると考えられます。
周辺で実績と勘所を積んだうえで、ようやく業務の中核に近い機能へと踏み込みます。ここでは検証をより厳格にし、旧新の並行稼働期間を設けて結果を照合するなど、慎重な進め方が求められると考えられます。中核に着手する頃には、第一段階で整備した仕様資産が効いてきます。解読が済んでいる部分から手をつけられるため、行き当たりばったりを避けられます。
この順序を貫く狙いは、リスクを時間軸で分散させることにあります。最も難しく影響の大きい部分を、最も経験を積んだ段階で、最も整った資産を手元に迎えられる。焦って中核から始める誘惑に抗うことが、結果的に近道になると考えています。
AIコーディングエージェントを刷新に使う際、技術的な期待ばかりが語られがちですが、実務では権限・検証・データ管理といった統制面の落とし穴が成否を分けると考えられます。ここでは特に注意すべき点を整理します。
自律的に動くエージェントに、いきなり本番環境への書き込み権限や実行権限を与えるのは危険だと考えられます。基本は最小権限の原則です。まず読み取り専用から始め、次に検証環境での書き込み、危険な操作には人の承認ゲートを設ける、という段階設計が妥当だと見ています。特にレガシー刷新では、エージェントが現行システムの重要なデータやコードを誤って変更するリスクを、構造的に排除しておく必要があります。
AIコーディングエージェントの利用は、規模によっては相応の費用が発生する可能性があります。解読で大量のコードを読ませる工程は特にトークン消費が大きくなりやすいため、事前に費用構造を把握しておくことが望ましいと考えられます。料金体系や仕様の細部は変わり得るため、最新は各ツールの公式情報を確認してください。導入全体の費用の考え方はAIエージェント導入の費用構造で整理しています。あわせて、ソースコードや業務データを外部の生成AIサービスに渡す際のデータ取り扱い方針は、契約・設定の両面で事前確認が必須だと考えられます。クローズドな環境での運用を検討すべき場面もあります。
レガシー刷新は、古い実装を新しい実装に置き換えるだけの作業ではありません。むしろ、システムがどうデータを持ち、どう他システムと連携しているかを見直す好機だと考えられます。この視点を欠くと、古い設計思想をそのまま新しい技術で再現するだけに終わり、数年後に同じ問題が繰り返されかねません。
刷新の議論では、しばしば大規模なパッケージ導入が万能薬のように語られます。しかし、業務やデータの実態を把握しないまま大きな箱を先に入れても、うまく根付かない可能性があると考えています。順序としては、まず現行のデータがどこにどう散在しているかを解読・可視化し、集約できる状態を作ることが先だと考えられます。この論点はERPを入れる前にで掘り下げていますので、パッケージ導入を検討している場合はあわせてご覧ください。
AIコーディングエージェントによる解読は、この「データがどこにどう存在するか」を明らかにする作業とも重なります。刷新の第一段階で整備した理解を、そのままデータ集約基盤の設計インプットに転用できると考えられます。
刷新後のシステムを設計する際、将来的に社内AIエージェント基盤から安全に参照・操作できる構造を意識しておくことにも価値があると考えられます。データの持ち方や外部からの接続方式を標準的な形に整えておけば、刷新で得た資産を今後の業務自動化にも活かしやすくなります。今回の刷新を「負債の解消」で終わらせず、「次の内製化の土台」として位置づける視点が、投資対効果を高めると見ています。
せっかく復元した仕様も、更新されなければ再び現行と乖離し、数年後にはまたブラックボックスに戻ります。刷新の過程で得たドキュメントを、変更のたびに更新し続ける運用こそが、同じ問題の再発を防ぐ本質的な対策だと考えられます。ここでもAIエージェントは、コード変更から仕様差分の下書きを生成する補助として機能しうると考えられますが、最終的な正しさの担保は人の責任に残ります。
ここまでの内容を、情シス責任者が明日から検討できる順序として整理します。レガシー刷新は一度で完結する事業ではなく、解読・仕様復元・段階的置き換えを繰り返す継続的な取り組みだと捉えるのが現実的だと考えられます。
この順序は、成果を焦らず、しかし着実に前進させることを狙っています。一括で片づけたい誘惑は理解できますが、ブラックボックス化した資産に対しては、小さく検証しながら進める規律が結果的に速いと考えています。
私たちNsightは、産業用画像検査やVLM/AIの現場で、机上で成立する仕組みと、実際の現場で継続して使える仕組みの間には距離があることを繰り返し経験してきました。この感覚は、元キーエンス画像処理事業部で現場の検査ラインに向き合ってきた監修者の知見に支えられています。カタログ上の性能ではなく、現物・現場で確かめて初めて分かることがある、という規律です。
レガシー刷新におけるAIコーディングエージェントの活用も、同じだと考えています。ツールの能力は日進月歩で、一般論として有望なアプローチであることは確かですが、御社の実際のシステム・実際の業務・実際のデータで何ができ、何が難しいかは、現物で検証してみないと分かりません。だからこそ、いきなり大きく賭けるのではなく、小さな対象で一度試し、その結果を一緒に確かめていく進め方をおすすめしています。私たちも、その検証のプロセスに伴走できればと考えています。
コードが読める形で残っていれば、構造の要約や仕様の下書き生成を進められる可能性はあると考えられます。ただし出力は推測を含むため、必ず実際の挙動やデータと突き合わせて検証する前提です。解読の初稿を素早く得られる点に価値があり、検証を省くと誤った仕様を作り込むリスクがあります。
ブラックボックス化した資産に対しては、影響範囲を小さく分割できる段階的な置き換えの方が現実的だと考えられます。一括は全仕様の把握を前提としますが、その前提自体が崩れている場合が多いためです。周辺の独立機能から始め、検証しながら中核へ進む順序をおすすめしています。
まずは書き換えではなく、読み取り専用での解読・可視化から始めるのが安全だと考えられます。次に帳票やデータ変換など影響範囲の小さい周辺ツールを置き換え、チームとエージェントの両方が経験を積んでから、中核機能へ段階的に踏み込む順序が現実的です。
最小権限の原則に沿い、まず読み取り専用から始めることをおすすめします。書き込みは隔離された検証環境に限定し、危険な操作には人の承認ゲートと監査ログを設けるのが望ましいと考えられます。いきなり本番への書き込み権限を与えるのは避けるべきです。
解読工程は大量のコードを読ませるためトークン消費が大きくなりやすく、規模に応じた費用が発生する可能性があります。料金体系は変わり得るため最新の公式情報を確認しつつ、小さな対象で一度試して実費感をつかんでから拡大する進め方が、見積もりの精度を高めると考えられます。
御社の実際のシステムで、AIコーディングエージェントによる解読・仕様復元がどこまで有効かは、現物で検証してみないと分かりません。元キーエンス画像処理事業部出身の監修者を含む私たちが、小さな対象での検証から一緒に確かめます。
刷新の進め方を相談する