AIリバースエンジニアリングの成果物品質
──解読ドキュメントに「使える」と「使えない」を分ける5つの評価基準【2026年版】
AIがレガシーシステムのソースコードを解読しても、出てきた「設計書らしきもの」が現場で使えないケースが増えている。問題は技術の精度ではなく、成果物の品質基準がないまま発注していることにある。本記事では、解読ドキュメントに「使える」と「使えない」を分ける5つの評価基準と、発注者が受領時に確認すべきチェックポイントを実務的に整理する。
「解読した」で安心してはいけない──設計書の『使えない問題』の実態
AIがレガシーシステムのソースコードを解読し、設計書が出力された──ここまでは順調に見える。しかし実際には、受け取った設計書が現場で使われないまま棚上げになるケースが後を絶たない。当社が支援してきたレガシー解読プロジェクトを振り返ると、成果物が「次の開発フェーズで実際に活用された」と評価できる事例は半数を下回る。
根本的な問題は、技術の精度ではない。「何をもって設計書が完成したとみなすか」という品質基準を、発注前に定義していないことだ。品質基準が存在しなければ、ベンダーは自社が「合格」と判断した状態で納品するしかなく、発注者は受け取った成果物が使えるかどうかを判断する軸を持てない。
典型的な失敗は以下の3パターンだ。
- パターン①：ブラックボックスが残存する──「複雑な処理のため詳細解析を省略」という記述が複数箇所に残り、次の改修で同じ箇所を再解析するコストが発生する
- パターン②：エンジニアにしか読めない──変数名・テーブル名がそのまま羅列され、経営層やPMが意思決定に使える内容になっていない
- パターン③：コードとの乖離が生まれる──解読後にコードが小改修され、設計書との整合が取れなくなり、現場が「設計書は信用できない」と使わなくなる
この3つはいずれも、事前に品質基準を定義して発注することで防げる問題だ。本記事ではその基準を「5つの評価軸」として体系化する。
品質評価の前提：AI解読の成果物に求められる3ドキュメント原則
5つの評価基準を適用する前に、まず「解読の完了条件」を確認する必要がある。HITL5 REVERSEでは、以下の3種類のドキュメントが揃って初めて解読が完了したとみなす。どれか1つでも欠けていれば、評価基準を適用する以前に「解読が未完了」だ。
| ドキュメント種別 | 記載内容 | 主な用途 |
|---|---|---|
| システム構造ドキュメント（Architecture Map） | モジュール・API・データストア・外部連携の全体構成図。コンポーネント間の依存関係を含む | 刷新計画の策定・移行方針の意思決定・ベンダー比較時の共通言語 |
| 処理フローシーケンス（Process Flow） | 業務別のデータの流れ・条件分岐・例外処理・トランザクション境界 | 機能改修・追加開発の影響範囲特定・テスト設計の基礎 |
| データ定義・依存関係図（Data Catalog） | テーブル・変数の役割・型・参照先・更新ルール・業務上の意味 | データ移行計画・DB再設計・API仕様書への転用 |
この3ドキュメントは、業界でも広く参照される「解読の3原則」に対応している。すなわち、①業務で引ける（Business-Indexed）：業務担当者が目的の情報に辿り着けること、②人もAIも読める（Dual-Format）：人間とAIの両方が参照・更新できる形式であること、③更新され続ける（Living Docs）：コードの変更に追随して陳腐化しないこと。これらが揃っていない状態で納品された設計書は、いかに精緻に見えても実用的な資産にならない。
評価基準①：網羅性──ブラックボックスが一切残っていないか
最初の評価基準は網羅性だ。「重要な業務処理がすべて文書化されているか」を定量的に確認する。
確認のポイント
- 任意の処理モジュールを5つ指定し、設計書だけで「このモジュールは何をしているか」を説明できるか
- 「詳細不明」「未解析」と記載された箇所の割合が5%以下か
- 受発注・在庫管理・会計連携など主要業務フローの処理パスが、入力から出力まで完全にトレースできるか
- 例外処理・エラーハンドリングのパスも文書化されているか
不合格の典型例
「この関数は内部構造が複雑なため詳細解析を省略した」という記述が複数箇所にある状態は、ブラックボックスを温存したまま納品したことを意味する。発注者がこれを見落とすと、次の改修でエンジニアが同じ箇所を再解析するコストが発生し、AI解読の投資対効果が半減する。
網羅性の合否は、受領時に「未解析率チェックシート」を要求することで客観的に確認できる。未解析箇所の一覧と、それぞれについて「省略した理由」「今後の対応方針」が記載されているかを確認すること。
評価基準②：可読性──エンジニア以外が読める記述になっているか
可読性は「技術者以外の関係者が設計書の意図を読み取れるか」の基準だ。AIリバースエンジニアリングの成果物が経営判断や調達判断に使われるためには、経営層・プロジェクトマネージャー・業務担当者が読める形式であることが不可欠だ。
確認のポイント
- 変数名・テーブル名がビジネス用語（日本語）に変換されているか。例：
tbl_m_adr_keiro→「配送ルートマスター」 - 業務フロー図が日本語ラベルで付属しており、1時間で全体概要を把握できるか
- 「なぜこの実装になっているか」という背景・制約が注記されているか
- 専門用語を使う場合、用語集または脚注が付いているか
不合格の典型例
データベースのテーブル名・カラム名がそのまま羅列されている設計書は、業務担当者には暗号と同じだ。経営層が「このシステムを刷新するか、延命するか」を判断するために設計書を見ても、判断材料が得られない。ビジネスの文脈への翻訳がなければ、設計書は技術者間の引き継ぎ資料にとどまり、意思決定の道具にはならない。
可読性の確認方法として有効なのは、エンジニアでない担当者に設計書の一部を渡し、「この業務フローを口頭で説明してください」と依頼するテストだ。説明できなければ可読性は不合格だ。
評価基準③：整合性──コードと設計書の矛盾がゼロか
整合性は「設計書の記述と実際のコードが一致しているか」の基準だ。AI解読では、学習データや解析手順の特性から、出力された設計書がコードの実態と乖離するケースが起きやすい。特に複雑な条件分岐や非同期処理、レガシー特有の暗黙的なフラグ処理において誤差が生じやすい。
確認のポイント
- 設計書に記載された分岐条件を、実際のコードでそのままトレースできるか
- 設計書上の処理順序と、コードの実行順序が一致しているか
- 自動整合性チェックの実施記録または第三者レビューの証跡が添付されているか
- 解読後に行われたコード修正が設計書に反映されているか
不合格の典型例
設計書では「条件Aの場合に割引処理が発動する」と記載されているが、実際のコードでは条件Bで分岐している──このような矛盾が潜在していると、設計書を信じて改修を行ったエンジニアがデグレを引き起こすリスクがある。実際のプロジェクトでは「設計書どおりに直したのに本番でバグが出た」という事例が当社支援実績でも複数発生している。
整合性の担保には、解読後のコードと設計書を突き合わせる「差分チェック」の実施証跡を納品物に含めることを仕様として明記する。証跡なき納品は整合性を保証しない。
評価基準④：更新可能性──改修のたびに設計書を使い続けられるか
更新可能性は「コードが変更されるたびに、設計書も追随して更新できる構造になっているか」の基準だ。一度だけ使える設計書ではなく、開発が続く限り機能し続ける資産として設計されているかを見る。
確認のポイント
- モジュール間の依存関係グラフ（または依存マトリクス）が提供されているか
- あるモジュールを変更した場合の影響範囲を、設計書だけで特定できるか
- 設計書の更新手順・更新責任・更新のトリガー条件が明記されているか
- ファイル形式が継続的な編集を想定した形式か（画像としてのPDFのみの納品は不合格）
不合格の典型例
モジュール間の依存関係が記載されておらず、1つの機能を修正するたびに影響範囲を再調査しなければならない状態。この場合、AI解読コストが毎回の改修で再発生し、解読投資の費用対効果が損なわれる。「解読は一度やれば終わり」ではなく「解読を継続的な開発基盤にする」という設計思想が更新可能性の核心だ。
受領時の確認として「このモジュールXを変更した場合、影響する箇所はどこか」をベンダーに設計書を使って回答させるテストが有効だ。設計書から即座に回答できなければ更新可能性は不合格だ。
評価基準⑤：検証可能性──第三者がレビューできる形式か
検証可能性は「解読を担当したベンダー以外の第三者が、コードを見なくても設計書だけで品質レビューを行えるか」の基準だ。社内エンジニア・監査担当・後任ベンダーが設計書を見て内容を評価できることが、持続的な品質担保の前提になる。
確認のポイント
- 標準フォーマット（UML・E-R図・構造化テキスト）で出力されているか
- ベンダー独自の記法を使っている場合、凡例・注釈・読み方ガイドが完備されているか
- 設計書の目次・インデックスから必要な箇所に30秒以内で辿り着けるか
- 第三者が1週間以内に内容レビューを完了できる分量・構造か
不合格の典型例
解読ベンダーのみが使う独自フォーマットで出力された設計書は、ベンダーを変更した瞬間に引き継ぎ不能になる。ベンダーロックインを防ぐためにも、標準フォーマットへの準拠は必須だ。また、設計書の分量が膨大すぎてインデックスがなければ、必要な情報を探すコストが実用を妨げる。「存在するが使えない設計書」は「存在しない設計書」と実用上同じだ。
検証可能性の確認方法：解読に関与していない社内エンジニア1名に設計書を渡し、「主要な業務処理のフローを3つ説明できるか」を試す。説明できれば合格、できなければ改訂を要求する。
HITL5 REVERSEの5層構造が担保する品質の仕組み
5つの評価基準は、HITL5 REVERSEの5層構造と対応している。各層でAI処理と人間のゲートが組み合わさることで、評価基準を満たす成果物が段階的に生成される仕組みだ。
| HITL5 REVERSE 層 | 主な処理内容 | 担保する評価基準 |
|---|---|---|
| SCOPE（スコープ定義） | 解読対象範囲・網羅率の合意・未解析の許容条件をドキュメントで確定する | ①網羅性 |
| DECODE（AIによる解読） | コードを機械的に解析し、処理ロジック・依存関係・データフローを抽出する | ①網羅性・③整合性 |
| KNOWLEDGE（意味付け） | 変数・処理・テーブルをビジネス用語・業務コンテキストへ変換し、背景注記を付与する | ②可読性 |
| VISUALIZE（可視化） | 依存関係グラフ・処理フローシーケンスを標準フォーマット（UML/E-R図）で図化する | ③整合性・④更新可能性 |
| ENABLE（引き渡し） | 第三者レビューの実施・標準形式での納品・更新ルール文書化・引き渡し検証 | ⑤検証可能性・④更新可能性 |
各層には人間のゲートが設けられており、「AI出力を承認する・差し戻す・修正を指示する」という3動作で機能する。評価基準①〜⑤を満たすためのチェックポイントは、各ゲートで機械的に確認される。これにより、発注者が事前に5つの評価基準を提示しておけば、ベンダー側で各層の完了条件として組み込める。
帰属表記：AI-HITL5 Framework ／ ディレクトリジャパン株式会社 提唱 ／ 2026
まとめ──「品質基準を持つ側」が次の開発コストを制する
AIリバースエンジニアリングの成果物に「使える・使えない」の差を生むのは、技術の精度よりも発注者が品質基準を持って発注しているかどうかだ。本記事で整理した要点を以下にまとめる。
- 前提確認：3ドキュメント（Architecture Map / Process Flow / Data Catalog）が揃っているかを受領前に確認する
- 評価基準①：未解析率5%以下・重要業務フローの完全トレースを要件に明記する（網羅性）
- 評価基準②：非エンジニアが1時間で概要を把握できる日本語化を要件に含める（可読性）
- 評価基準③：整合性チェックの実施証跡を納品物に必ず含める（整合性）
- 評価基準④：依存関係グラフと更新手順書を必須納品物として仕様書に記載する（更新可能性）
- 評価基準⑤：解読に関与していない第三者によるレビュー合格を納品条件とする（検証可能性）
これら5つの基準を発注仕様書に明記してから発注するという手順が、AI解読投資を次の開発フェーズの資産に変えるための最短経路だ。品質基準を持たずに解読を委託すれば、「動いた設計書」を受け取るだけで終わる。品質基準を持って委託すれば、「使い続けられる設計書」が手元に残る。
ディレクトリジャパンでは、HITL5 REVERSEを用いた14日間の無償トライアルで、NDA締結のうえ1機能分の設計書サンプルを実物でご確認いただけます。品質基準を実際の成果物で検証してから発注判断を行いたい方は、ぜひトライアルをご活用ください。
なお、解読プロジェクトの失敗パターンと回避策については AIリバースエンジニアリングの失敗パターンと回避策 で詳しく解説している。発注前にあわせてご確認いただきたい。
設計書サンプルの実物を見てから判断する
HITL5 REVERSEによる解読ドキュメントがどのような品質になるか、NDA締結のうえ1機能分の設計書サンプルを14日間のトライアルで実際にご確認いただけます。
14日無償トライアルを申し込む まずは無料相談するよくある質問（FAQ）
一般的には、システム構造ドキュメント（Architecture Map）・処理フローシーケンス（Process Flow）・データ定義・依存関係図（Data Catalog）の3種類が基本的な成果物です。ただし、ベンダーによって納品物の定義は異なるため、発注前にこれら3ドキュメントの納品を仕様書に明記することが重要です。HITL5 REVERSEでは、この3ドキュメントを解読完了の必須条件と定義しています。
まず本記事の5つの評価基準に照らし合わせ、どの基準が未達かを特定してください。未解析箇所の一覧提出・ビジネス用語への変換作業・整合性チェックの実施・依存関係図の追加作成・第三者レビューの実施を、個別に追加作業として依頼する方法が現実的です。ただし、発注仕様書に品質基準が明記されていなかった場合は交渉が難しくなるため、次回からは事前に基準を明記することをお勧めします。
可読性・網羅性の簡易チェックは社内で実施可能です。ただし、整合性（コードと設計書の突き合わせ）と検証可能性の厳密な評価には、解読に関与していない技術者による第三者レビューが必要です。社内に適切なリソースがない場合は、解読ベンダーとは別の技術支援会社に検証を依頼することをお勧めします。
各基準を「納品条件」として仕様書の「検収基準」欄に記載します。例：「①未解析率5%以下を示す未解析箇所一覧を納品物に含めること」「②第三者レビューの実施記録を納品物に含めること」「③モジュール間依存関係グラフを納品物に含め、影響範囲の特定に使用できることを検収時に確認すること」のように、測定可能な形で書くことが重要です。
設計書の品質確認が完了したら、次のステップは「刷新か延命かの意思決定」です。解読ドキュメントを使って、現行システムの技術的負債の深さ・刷新コスト・段階的移行の可否を経営層向けに整理します。この意思決定プロセスについては「AIリバースエンジニアリング レガシーリスク 2026」および「リバースエンジニアリング 刷新か再構築かの判断」も参考にしてください。