SPEC BASELINE

ソースコード仕様書一致性検査

設計意図と実装のズレを、全件・根拠つきに突き合わせます。

OUTPUT #1
比較基準の設計書

ソースコードを読み、既存の設計書と同じ章立て・書式で、比較の基準になる設計書を作ります。内容はコードを基準に取り、既存の記載は写しません。返却は Markdown で、行単位で比較できます。

OUTPUT #2
差異検証レポート

「設計書にはこう書いてあるが、コードはそう動いていない」箇所を、両側の原文を引用して洗い出します。重大度(高・中・低)と確度、どちら側を直すべきかまで判定します。

領域

品質保証(成果物の正しさを、根拠つきで示す)

対象

稼働中の業務システム(Java / Spring Boot / MyBatis / Thymeleaf 構成での実施例)

キーワード
全件の突き合わせ両側の原文で示す差異重大度と帰責生成と検証の分離
01 ISSUE

設計意図と実装のズレは、探しに行かない限り出てこない

改修のたびに少しずつズレても、システムは動き、テストも通ります。障害にならないので、気づく機会がありません。見つからないのは注意不足ではなく、次の三つが重なるからです。

WHY 01
ズレても動いてしまう

処理は流れ、テストも通る。障害として表に出てこない。

WHY 02
比べる形が揃わない

日本語の記述とコードは、そのままでは比べられない。

WHY 03
全件を見る工数が出ない

数十万行規模のコードを、人手では追い切れない。

02 PROCESS

AI と経験者の分担

工程の順序と再試行はプログラムが持ちます。AI は「生成」と「検証」を担い、経験者の確認は判断が分かれる箇所と抜取に絞ります。

STEP 01 書式の解析 章立て・列構成 STEP 02 コードの解析 画面〜SQL を層ごと STEP 03 設計書の書き起こし + 差異の記録 AI 自己検証 根拠と網羅性 直せる箇所はその場で 品質判定 合格・要修正・例外 STEP 04 経験者レビュー 例外・高リスク・抜取に絞る STEP 05 帰責・重大度の判定 どちら側を直すべきか 提出 設計書 + 差異検証レポート 要修正 ── AI が直して再生成(人手を介さない) 指摘 ── 取り下げ・記述の修正 合格(低リスク) 例外・高リスク レビュー結果は次回の生成条件へ ── 同じ種類の見落としが減る AI が担う 人が判断 外へ渡すもの 機械が止める関門

お預かりするのはソースコードと既存設計書の見本だけで、稼働中のシステムや DB には接続しません。原本からは章立て・列・行の枠だけを機械で取り出し、値は AI に見せません。

生成する AI と検証する AI は別で、検証は別の会話・別のエンジンで動きます。機械が判定するのは形式と証拠だけです ── 結論の当否まで機械の合否にすると、AI は指摘そのものを減らして通そうとするためです。判断が分かれるもの・影響が大きいもの・抜取分だけを経験者が確認し、確定してから帰責と重大度を判定します。

03 STRENGTH

全件に届いて、根拠が原文のまま残る突き合わせ

人手だけでは規模に比例して長くなり、AI にそのまま作らせると裏が取れません。この二つを避けるために、突き合わせる枠と根拠の出し方を先に決めてあります。

POINT 01
気づいた範囲ではなく、枠の全行を突き合わせる

突き合わせる単位は、原本から取り出した枠 ── 章立て・列・行です。その全行について、設計書側の記述とコード側の事実を 1 行ずつ照合し、食い違った行だけが差異として残ります。

読む作業を人の時間から切り離しているので、数十万行規模でも一巡できます。探さなかったから出てこなかった、が起きません。

原本から取り出した枠の全行を、設計書側の記述とコード側の事実に突き合わせ、食い違った行だけが差異として残ることを示す図
POINT 02
差異は、両側の原文を引いて示す

差異 1 件には、設計書側の出典(シート名とセル番号)とコード側の出典(ファイル名と行番号)が対で付き、どちらも原文をそのまま引用します。読み手は同じ箇所をその場で開いて、成り立つかどうかを自分で確かめられます。

重大度と確度に加えて、どちら側を直すべきかまで判定します。手元の情報だけでは決められないものは断定せず、「要確認」として残します。

差異1件に設計書側とコード側の出典と原文が対で付き、重大度・確度・帰責の判定が添えられることを示す図
POINT 03
言語専用のツールに依存しない

言語ごとの解析器に頼らないので、社内独自言語、各種の定義ファイル、コード生成器の出力、旧世代の 4GL も対象です。

層構成と書式の対応が取れれば、同じ手順で進められます。一覧に無い言語も、少量のコードで判断できます。

各種言語のソースコードから、層構成と書式の対応が取れれば同じ手順で進められることを示す図
適用の前提
設計書が揃っていなくても、本番に触らずに始められます

見本が 1 種類あれば規約を起こせます。まったく残っていない場合は、書式と実装から比較の骨格をこちらで取り決めます。

お預かりするのはソースコードだけ。稼働中のシステムや DB に接続しないので、稼働への影響が無く持ち出す範囲も明確です。

事前に整えていただくものはありません。

できないこと
コードに書かれていないことは、突き合わせられません

比べる材料をコードから取る方式のため、運用手順や外部システム側の取り決めなど、コードに現れないものは対象外です。環境変数など実行時にしか決まらない値も同じです。

手元の情報だけでは修正すべき側を判定できない差異は残ります。下の実施例では 101 件中 14 件がこれにあたり、推測で断定せず「要確認」としてお返ししています。

本ページでご案内している範囲は、比較基準の作成・差異検証・重大度と帰責の判定までです。その先の影響分析・修正案・テスト観点への展開は、範囲を決めたうえで個別にご相談ください。変更のたびに自動で再検証し続ける「継続保証」は今後の構想で、いまお出しできる範囲には入りません。

04 RESULT

約 52 万行のシステムで出てきた件数

1 案件で実施した結果です。対象は Java / Spring Boot 構成、約 52 万行の稼働中システム。件数はすべて実際の出力値で、事例は匿名化しています。

比較基準の設計書と、検出した差異

比較基準の設計書 差異 高 差異 中 差異 低 差異 計
8 本134642101

2026 年度に実施し、成果物はお客様の検収を通過しています。件数は実際の出力値です。

どちら側を直すべきか(全 101 件の判定内訳)

全件について修正すべき側を判定します。判断できないものは推測で断定せず「要確認」として残します。

50 ソース誤り
14 要確認
37 設計書誤り
ソース誤り ── 設計書が正しく、コード側の修正が必要 要確認 ── 手元の情報だけでは判断できなかったもの 設計書誤り ── コードが正しく、設計書の記載が古い/誤り

この実施例で得られたもの

8 本
比較の基準になる設計書。保守・引継ぎ・改修調査の共通基準に使えます。
101 件
目視では拾えていなかった差異。両側の原文を引用して一覧に。
13 件
データの欠落・誤登録、未実装。放置すれば実データに影響が出るものを事前に特定。
全件
修正すべき側を判定済み。そのまま改修対象の一覧として使えます。

NEXT

ご相談は、担当者までご連絡ください。

対象を一つ指定いただければ、成果物とその検証レポートを実物としてご提示します。

この方式が有効かどうかは、件数の説明ではなく、ご自身のシステムから出てきた成果を見ていただくのが最短です。

連絡先を見る →

対象を一つお知らせいただくところから始まります。