CODE INSIGHT
設計書リバース生成
設計書は、動いているコードから作り直せる。
稼働中のシステムのソースコードを読み、既存の設計書と同じ章立て・同じ書式で再生成します。記述する値はすべてコードから取り、既存の記載は書き写しません。
「設計書にはこう書いてあるが、コードはそう動いていない」箇所を根拠つきで洗い出し、どちら側を直すべきかまで判定します。
長く動いているシステムほど、設計書とコードは離れていく
改修のたびにコードだけが更新され、設計書が追いつきません。よくある状態ですが、経営判断の材料としては次の三つの形で表面化します。
着手後に実装との差が出てくるため、追加工数の交渉余地が無くなる。
コードを読める人しか調べられず、その人の離任がそのままリスクになる。
設計書どおりに動いていない箇所は、誰も突き合わせていないため放置される。
AI と経験者の分担
まず AI が自ら検証し、経験者の確認は判断が分かれる箇所と抜取に絞ります。
まず AI が、注記の根拠がコード上で確認できるか、取りこぼしが無いかを自己検証し、直せる箇所はその場で直します。
そのうえで、判断が分かれるもの・影響が大きいもの・抜取分だけを経験者が確認します。指摘を反映し、内容が変わらなくなってから帰責と重大度を確定します。
指摘は次回の生成条件にも反映するので、同じ種類の見落としは回を追って減ります。
「更新」ではなく「書き起こし」にしている
既存の設計書には手を入れず、書式だけを借りて別に書き起こします。以下はすべてこの一点から出ています。
既存の設計書から受け取るのは章立てと書式だけで、書かれている内容は参照しません。
更新していく作り方では誤った記述が残りますが、写さないからこそ、差が食い違いとして残ります。
章立て・列の意味・記載粒度は、いまお使いの Excel 設計書に合わせます。並べて同じ順序で読めます。
返すのはテキストの Markdown。行単位で差分が取れ、検索・レビュー・機械処理がそのまま効きます。
言語ごとの解析器に頼らないので、社内独自言語、各種の定義ファイル、コード生成器の出力、旧世代の 4GL も対象です。
層構成と書式の対応が取れれば、同じ手順で進められます。一覧に無い言語も、少量のコードで判断できます。
見本が 1 種類あれば規約を起こせます。まったく残っていない場合は、書式をこちらで定義します。
お預かりするのは静的コピーだけ。稼働中のシステムや DB に接続しないので、稼働への影響が無く持ち出す範囲も明確です。
事前に整えていただくものはありません。
値をすべてコードから取る方式のため、運用手順や外部システム側の取り決めなど、コードに現れないものは対象外です。実行時にしか決まらない設定値も同じです。
手元の情報だけでは修正すべき側を判定できない食い違いは残ります。下の実施例では 101 件中 14 件がこれにあたり、推測で断定せず「要確認」としてお返ししています。
実際にやってみて、出てきた件数
対象は Java / Spring Boot 構成、約 52 万行の稼働中システム。件数はすべて実際の出力値で、事例は匿名化しています。
再生成した設計書と、検出した不一致
| 再生成した設計書 | 不一致 高 | 不一致 中 | 不一致 低 | 不一致 計 |
|---|---|---|---|---|
| 8 本 | 13 | 46 | 42 | 101 |
2026 年度に実施し、成果物はお客様の検収を通過しています。件数は実際の出力値です。
どちら側を直すべきか（全 101 件の判定内訳）
全件について修正すべき側を判定します。判断できないものは推測で断定せず「要確認」として残します。
この実施で得られたもの
NEXT
ご相談は、担当者までご連絡ください。
対象を一つ指定いただければ、成果物とその検証レポートを実物としてご提示します。
この方式が有効かどうかは、件数の説明ではなく、ご自身のシステムから出てきた成果を見ていただくのが最短です。
対象を一つお知らせいただくところから始まります。