「担当者が辞めたら詰む」を卒業する
――AIリバースエンジニアリングが解くレガシーシステムの呪縛

「あの担当者が辞めたら、このシステムはどうなるんだろう――」。ある中堅製造業の社長は、基幹システムを 30 年間支えてきた社員が突然休職した途端、3 週間にわたって受注システムの小さな不具合すら直せない状態に陥った。外部のエンジニアに依頼しようにも、「設計書がなく、コードも読めない言語で書かれているため、見積もりすら出せない」と断られ続けた。こうしたリスクを抱えたまま動き続けている基幹システムが、国内企業には相当数存在する。その解決策として、「AIリバースエンジニアリング」という手法が 2026 年、実用化の本格段階に入った。

AIリバースエンジニアリングは単なる「調査」ではない。レガシーシステムを解析（DECODE）し、可視化（VISUALIZE）し、刷新の準備（ENABLE）まで進める AIオーケストレーション（AIO）の入口だ。その後の AIディレクターによる上流設計、AIコーディングによる実装まで、一社で一気通貫での支援が可能な仕組みである。

1. 「触れないシステム」が生む静かな経営リスク――属人化対策の第一歩

基幹システムが「触れない」状態になる原因は、技術的な問題ではなく「情報の欠落」だ。

① ドキュメントが存在しない（または古すぎて使えない）
開発当時の仕様書が残っていても、10 年分の改修が一切反映されていないケースが大半だ。紙の上の仕様と、実際に動いているコードが別物になっている。

② 現役エンジニアが読めない言語で書かれている
COBOL（金融機関や行政で今も現役の古いプログラム言語）・VB6・古い PL/SQL――こうした言語を読み書きできるエンジニアは年々減少しており、新卒採用でカバーすることも難しくなっている。

③ 業務の"なぜ"がコードに埋め込まれている
「なぜこのロジックになっているか」は、かつてその開発に関わった担当者の記憶の中にしかない。コードを読んでも意図がわからない。メモもない。確認テストの仕組みもない。

この 3 つが重なった状態で担当者の退職・異動・休職が発生すると、「仕様がわからないから手が出せない」「何かを変えると別の何かが壊れる」という硬直状態に入る。新機能の追加が止まり、DX 投資が凍結し、競合他社に数年分の差をつけられる。これは「IT 部門の問題」ではなく、「経営のリスク」だ。

2. 「解析に 1 年」が「3 ヶ月」に変わった理由――COBOL も読める AI

従来、レガシーシステムの解析は専門家の手作業に頼っていた。コードを 1 行ずつ読み、業務ロジックを推測し、依存関係を紙に手でマッピングする――熟練エンジニアが数名がかりで 6 ヶ月〜1 年を要することが珍しくなかった。

2026 年 2 月、AI 開発企業の Anthropic が「Claude Code」による COBOL コードの自動解析・文書化機能を正式に公開した（Anthropic による技術ブログ、2026 年 2 月）。この発表が業界に与えた衝撃は大きく、「AI が COBOL を読める」という事実を受け、大手 IT ベンダーの株価が一日で約 13% 下落したことが複数のメディアで報じられた（CNBC、2026 年 2 月 23 日付）。

LLM は、従来の解析ツールと何が違うのか。従来のツールは「どの処理がどの処理を呼ぶか」という構造を把握できたが、「なぜそういう処理になっているのか」という意味は理解できなかった。LLM はコードを「文章」として読み、業務ロジックの意図・例外処理の意味・変数の役割を「人間が読める文章」に変換できる。

この能力により、従来 1 年かかっていた解析が 3 ヶ月に短縮されるケースが生まれ始めている。同社は「基幹システムのモダナイゼーションは、数年ではなく数四半期で完了できる」と予測している（同社技術ブログより）。

3. AIリバースエンジニアリング 3 ステップ：DECODE / VISUALIZE / ENABLE

STEP 1：DECODE（解読）
AI がレガシーコードを自動解析する。COBOL・VB6・古い PL/SQL・Java など、複数の古い言語が混在していても対応できる。処理の内容・業務ロジックの意図・例外処理の理由を自然言語に変換し、「このコードが何をしているか」を文章として取り出す。

STEP 2：VISUALIZE（可視化）
DECODE で得た情報をもとに、システム全体の構造図・データの流れ・業務フロー・「どれを変えると何に影響するか」の依存マップを自動生成する。設計書がない状態から、現状の「設計書代わり」となるドキュメント群が初めて生まれる。

STEP 3：ENABLE（刷新準備）
可視化されたシステムをもとに、「どこから手を入れるべきか」「どの部分を現代のシステムにつなぎ変えるべきか」の優先順位と移行計画を策定する。ゼロからの再開発か、段階的な入れ替えか――経営判断に必要な情報が揃う。

この 3 ステップは分割して着手できる。「まず DECODE だけ試してみる」という始め方が可能だ。

4. 「調査報告書が棚に並ぶだけ」に終わらせない――ENABLE が ROI を生む

よくある失敗パターンがある。コンサルタントにシステム調査を依頼し、数ヶ月後に分厚いドキュメントが届く。内容はまとまっている。しかし次のアクションを誰も持っていない。「調査報告書」が棚に並んだまま、2 年後も何も変わっていない――これがレガシー調査プロジェクトの典型的な失敗だ。

AIリバースエンジニアリングの本質的な価値は「ENABLE」にある。解析・可視化は手段であり、目的は「次の投資判断を経営者が下せる状態にすること」だ。

ENABLE フェーズでは、AI が生成した情報をもとに外部AIディレクター（「プロダクトオーナーの外部 No.2」として月額 30 万円〜で関与する当社の上流設計サービス）が「次の一手」を経営視点で整理する。「この部分に他のシステムとつなぐ接続口を設ければ、新サービスが立ち上がる」「この夜間の自動処理をクラウドに移せば、保守の外部委託費や障害対応工数が月 70 万円削減できる（当社実績事例の一例）」――具体的な数字と優先順位が出るから、経営判断ができる。

調査で終わらず、戦略に変換する。そこが AIO（AIオーケストレーション）アプローチの核心だ。

5. なぜ AI だけに任せないのか――人間レビューが品質を担保する理由

AI が解析した結果をそのまま 100% 信頼するのは危険だ。LLM はコードの文脈をよく理解するが、業務特有の暗黙ルールや「コードには書いてあるが今は使われていない処理」を誤って重要と判断することがある。

ディレクトリジャパンでは「AI-HITL5モデル」（当社独自の品質管理モデル：AI と人間が 4 観点 × 5 層でレビューを行う仕組み）を採用している。AI 処理（約 60%）と人間レビュー（約 40%）を組み合わせることで、AI が取りこぼした解釈ミスや業務ロジックのズレを確実に検出できる。

レガシーシステムには「コードに書いてあること」と「実際のビジネスルール」のギャップが無数にある。「書いてあるが今は運用していない処理」「書いていないが現場でカバーしている例外」――これを AI は見落とす可能性がある。このギャップを埋めるのが人間レビューの役割だ。AI だけに任せず、人間の判断を仕組みとして組み込むことで、レガシー解析の精度は実務レベルに引き上がる。

6. 「うちのケースで使えるか？」――よくある 3 つの疑問に答える

Q1. 言語が古すぎる / 設計書が一切ない場合でも対応できるか？
対応できる。設計書が存在しない状態から DECODE を行うことが、AIリバースエンジニアリングの最も力を発揮する場面だ。COBOL・VB6・古い PL/SQL への対応実績がある。

Q2. 費用・期間の目安は？
システムの規模による。DECODE フェーズのみであれば、数百万円台・3 ヶ月以内が一つの目安だ。まず現在のシステム規模・使用言語・保守体制をヒアリングした上で見積もりを提示している。

Q3. 解析後の開発もお願いできるか？
一気通貫で対応可能だ。ENABLE フェーズ以降、AIコーディング × ベトナム精鋭オフショアチームとの連携で、国内 SIer 相場の 1/3〜1/5 コスト・月額 60 万円〜・最短 3 ヶ月での実装フェーズに移行するオプションがある。

7. まず DECODE だけ試す――着手ハードルを下げる入口

「全部いっきにやるのは予算・体力的に難しい」――これが多くの経営者の現実だ。

だからこそ、DECODE だけから始める入口を設けている。「自社の基幹システムが何をやっているか」を言語化するだけで、経営の視野は大きく変わる。

「実は使われていない機能に毎月保守費をかけていた」「この処理を変えるだけで月次作業の工数が半減する」「担当者だけが把握していた例外処理が、実はコードのここに書いてあった」――こうした発見が、次の投資判断の根拠になる。

「触れないシステム」が「わかるシステム」に変わる。それだけで、経営の選択肢は大きく広がる。