結論: 刷新の入口は「実装」ではなく「読み解き」
10 年もの、15 年ものの基幹システムを刷新したい。けれど設計書は実態と食い違い、当時の担当者はもういない。コードはブラックボックスで、どこを触ると何が壊れるか分からない。レガシー刷新が止まる原因のほとんどは、技術の古さそのものよりも、この「中身が分からない」状態にあります。
先に結論から書きます。刷新の入口は、新しいコードを書き始めることではありません。いま動いているコードと実際のデータから、現行の仕様を読み解くことです。動いているシステムそのものが、最も正確で最新の仕様だからです。そして、この読み解きの工程こそ、AI 駆動開発で最も短縮効果が出る領域です。
FIXIT は AI 駆動開発のクリエイティブスタジオとして、Claude Code などの AI エージェントを実プロジェクトに組み込み、仕様書のないレガシーを読み解いて刷新してきました。本記事では、その読み解き(リバースエンジニアリング)の手順と、読み解きフェーズだけを先に発注する進め方を、発注目線で整理します。費用と期間の相場そのものは レガシー刷新の費用と期間 に、刷新全体の工程は システムリプレイスの進め方ガイド にまとめています。
なぜ仕様書のないシステムは刷新できないのか
「動いているのだから、そのまま作り直せばいい」と思えても、実際に着手すると手が止まります。ブラックボックス化したシステムには、刷新を阻む 3 つの壁があるからです。
ひとつ目は、現行の挙動が誰にも分からないことです。設計書が残っていても、その後の改修で実態とずれていることが多く、結局はコードを読むしかありません。けれど数万行のコードを人が頭から読み解くには、何か月もかかります。
ふたつ目は、暗黙の業務ルールがコードに埋もれていることです。「月末締めだが特定の取引先だけ 20 日締め」「在庫がマイナスでも特定条件では受注を通す」といった、仕様書のどこにも書かれていないルールが、条件分岐としてコードに散らばっています。これを見落とすと、刷新後に業務が止まります。
みっつ目は、触ると壊れる恐怖です。どの処理がどこに影響するか分からないため、誰も手を入れられず塩漬けになります。塩漬けが長いほど、分かる人はさらに減り、刷新は年々難しくなります。
注意
ブラックボックス化は時間とともに悪化します。分かる人が退職するたびに読み解きの難易度は上がり、放置した分だけ刷新コストは積み上がります。「いつかやる」は、毎年高くつく先送りです。
この 3 つの壁はどれも、「現行仕様が見えていない」という一点に集約されます。だからこそ、刷新の最初の一手は、コードを書くことでも要件を決めることでもなく、現行仕様を可視化することになります。
AI で仕様を復元する 4 ステップ
ここからが本題です。AI エージェントを使って、ブラックボックス化したコードから現行仕様を読み解く手順を、4 つのステップに分けて説明します。全体の流れは次のとおりです。
flowchart TD
A["1. コードベースを読み込ませる<br/>(既存コード・テスト・障害履歴)"] --> B["2. ドメイン責務マップを起こす<br/>(何がどこにあるか)"]
B --> C["3. 暗黙の業務ルールを抽出<br/>(行番号付きで引用)"]
C --> D["4. 振る舞いをテストに固定<br/>(刷新の基準にする)"]
D --> E["人が業務で確認・確定"]
E -->|要確認が残れば| Cステップ 1: コードベースと履歴を読み込ませる
まず、AI エージェントに既存のコードベース全体を渡します。あわせて、残っているテストコード、過去の障害報告やバグ修正の履歴、運用手順書の断片など、現行システムにまつわる一次情報をできる限り読み込ませます。
コードだけでなく履歴を渡すのが要点です。過去にどこで障害が起きたかは、そのまま「触ると危険な場所」を示します。AI は人と違って読む量に圧倒されないため、人手では数か月かかる通読を短期間で済ませられます。
ステップ 2: ドメイン責務マップを起こす
次に、システムがどの業務ドメインで構成され、それぞれがどのコードに対応しているかのマップを作らせます。受注・在庫・出荷・請求といった単位で、責務とファイル・モジュールの対応を整理します。
このマップは、後の移行で「どのドメインからどの順で刷新するか」を決める土台になります。ドメイン間の依存(密結合の度合い)も同時に洗い出すと、切り分けながら段階移行する設計がしやすくなります。
ステップ 3: 暗黙の業務ルールを行番号付きで抽出する
最も価値が出るのがこのステップです。コードに埋め込まれた条件分岐から、仕様書のどこにも書かれていない業務ルールを抽出させます。このとき、必ず引用元のファイルと行番号を付けて出力させるのが重要です。
行番号付きにする理由は、人が裏取りできるようにするためです。AI が「特定の取引先は 20 日締め」と書いてきても、根拠の行が示されていなければ、それが本当か推測かを確認できません。引用元があれば、業務担当者がコードと突き合わせて事実確認できます。
コツ
AI に仕様を書かせるときは、必ず「引用元の行番号を付けて」と指示します。根拠を辿れない要約は、後で裏取りができず、推測と事実の区別がつかなくなります。読み解きの成果物は、文章の量より裏取りのしやすさで質が決まります。
ステップ 4: 振る舞いをテストに固定する
最後に、確認の取れた現行の振る舞いを、テストコードに落とし込みます。「この入力ならこの出力になる」という現行仕様を、実行可能なテストとして固定するわけです。
このテスト群が、刷新の基準になります。新システムを「既存の挙動を保ったままモダンスタックに書き直す」とき、同じテストが通れば挙動が保たれている証拠になります。テスト先行で AI に実装を生成させる進め方は AI 駆動 TDD で詳しく扱っています。
実案件では、この読み解きの所要工数が従来のおおむね 1/3〜1/4 になりました。人が「仕様を全部把握してから書き直す」のではなく、AI に読み解かせて人が判断する協業に切り替えるのが、速さの源です。
AI が読めるもの、読めないもの
ここで釘を刺しておきます。AI は読み解きの速度を大きく上げますが、すべてを判断してくれるわけではありません。
FIXIT仕様書がないシステムでも、AI なら全部読めちゃうの？
Dodaiコードがどう動くかは読めます。でも、なぜそう作ったかは読めません。
FIXITDodai大きいです。特定の取引先だけ締め日が違う分岐があっても、いまも有効か過去の名残かは、コードからは判断できません。
FIXITDodai人が業務で確認します。確認できた振る舞いだけをテストに固定して、刷新の基準にします。
AI が読み解けるのは「コードがどう動くか」までです。「なぜそうなっているか」という業務上の意図は、コードだけからは確定できません。先ほどの「特定の取引先だけ 20 日締め」が、いまも有効なルールなのか、過去の特例の名残なのかは、コードを見ても分かりません。
ここを推測のまま新システムに引き写すと、移行後に業務が止まる事故になります。だからこそ、AI が復元した仕様は「下書き」として扱い、業務担当者がレビューして有効・廃止・要確認に仕分けます。確定した振る舞いだけをテストに固定し、刷新の基準にします。速くするのは AI、正しいと判断するのは人です。この役割を崩すと、速いだけで信用できない刷新になります。
まず「読み解き」だけを発注する進め方
仕様がブラックボックスのまま、いきなり全体の刷新を大きな金額で契約するのは危険です。範囲が見えていないため、後から工数が膨らみやすいからです。レガシー刷新では、読み解きフェーズだけを先に切り出す進め方を推奨します。
進め方はこうです。第一フェーズとして「現行仕様の読み解きと移行ロードマップの作成」だけを契約します。このフェーズは仕様が不確かな調査作業なので、契約形態は準委任が向いています。請負と準委任の使い分けは 準委任と請負の違い で整理しています。
読み解きが終わると、ドメイン数・データ移行の難易度・業務停止の制約といった、費用を左右する変数が確定します。その状態で本開発を見積もれば、精度が大きく上がり、想定外の追加が出にくくなります。
FIXIT読み解きだけ先に頼むって、二度手間で割高にならないの？
Dodai逆です。範囲が見えないまま一括で受けると、後で必ず工数が膨らみます。
FIXITDodai移行の難易度が確定します。本見積もりの精度が上がり、追加費用が出にくくなります。
実際に 10 年もののシステムを刷新した事例は レガシーシステムを半分のコストで刷新した事例 にまとめています。止めずに移行する段取りは ゼロダウンタイムの段階移行事例 も参考になります。
まとめ
仕様書のないレガシーシステムでも刷新はできます。入口は、新しいコードを書くことではなく、いま動いているコードから現行仕様を読み解くことです。AI エージェントに既存コード・テスト・障害履歴を読ませれば、ドメイン責務マップ・暗黙の業務ルール・危険なホットスポットを行番号付きで短期間に復元でき、読み解きの工数を大きく減らせます。
ただし AI が読めるのは「どう動くか」までで、「なぜそうなっているか」は人が業務で確認します。確認できた振る舞いをテストに固定し、刷新の基準にします。この役割分担が、スピードと業務的な正確さを両立させる読み解きの作法です。そして、いきなり全体を契約するより、読み解きフェーズだけを準委任で切り出すほうが、見積もりの精度もリスクも抑えられます。
自社のシステムが刷新できるか、まず現行仕様を読み解くところから相談したい方は 無料相談 からお問い合わせください。既存システムの状態を伺えれば、読み解きの進め方と費用感の当たりをつけるお手伝いをします。刷新を AI 駆動でどう進めるかは レガシーモダナイゼーションサービス にも整理しています。