意思決定のための要約
executive_summary.md
リスク、優先度、推奨アクションを、全体像とともに短く把握するための資料です。
AI-ASSISTED REVERSE ENGINEERING
「誰も読めないコード」を、
「誰もが理解できる資産」へ。
Re::Viveは、レガシーシステムのソースコードを段階的に読み解き、仕組み・リスク・業務ルール・改修に役立つ情報へ整理する解析サービスです。
コードを実行しない静的解析
根拠・信頼度を記録
意思決定用の成果物へ整理
コードにない情報は確認事項へ
WHAT WE SOLVE
改修・移行の前に、現状を正しく理解する
仕様書や引き継ぎが十分でなくても、コードに残る情報から調査の出発点をつくります。
何が分かり、どこに追加確認が必要かを切り分けることで、改修や刷新の判断を前へ進めます。
?
仕様書と実装が一致せず、何を正とすべきか分からない
?
担当者や保守ベンダーが不在で、システムの全体像を説明できない
?
改修の影響範囲や、踏襲すべき業務ルールを確信できない
?
セキュリティ・性能・データ整合性の懸念を、着手前に把握したい
HOW IT WORKS
全体像から詳細へ、段階的に読み解く
いきなり全コードをAIに渡すのではなく、対象範囲と関係性を先に把握し、その文脈を次の分析へ渡します。
-
01
つながりを把握
依存関係、入口、解析対象の範囲を確認します。利用可能な場合はシンボル単位の呼び出し・参照関係も扱います。
-
02
全体像をつかむ
構成、アーキテクチャの特徴、技術スタックを並列で整理します。
-
03
専門観点で深掘り
データ、業務ルール、API、DB、UI、設定、非同期処理、性能の手掛かりなどを調査します。
-
04
資料化して検証
分析結果から文書を作成し、コードとの整合性と前回版との差分を確認します。
-
05
テスト案を生成
完全分析では、抽出した業務ルールやAPIに基づくテストケースも生成します。
文書は一度作って終わりではありません。 生成した文書をコードと照合し、検証結果と差分を次の生成に反映します。検証が失敗した場合や、同じ未解決事項が続く場合は、成功として扱いません。
DELIVERABLES
読む人に合わせた資料と、確認できる分析記録
利用目的に合わせた文書と、その記述を確認するための分析データを、同じ出力先に残します。
技術者向けの詳細資料
technical_specification.md
構成、依存関係、データフロー、業務ロジック、APIなどを整理します。要件・設計・機能/非機能仕様も目的に応じて生成します。
確認・再利用できる分析記録
.knowledge/
依存グラフ、Finding、ファイル・行の根拠、信頼度、未解決参照、診断、検索・影響確認用カタログを保持します。
成果物の使い方
改修前: 変更候補の影響範囲と追加確認事項を洗い出します。
移行計画: 踏襲・改善・廃止を判断するための材料にします。
引き継ぎ: コードを読み直さなくても会話を始められる共通資料にします。
CROSS-RUN KNOWLEDGE
一度の解析で終わらない。
次の調査を、確かな履歴から始める。
完了した解析のJSON正本は、対象リポジトリの外側に、同じ対象プロジェクトの履歴として追記保存します。対象リポジトリのファイルは変更しません。
次回の解析準備では、対象パス・成果物のハッシュ・Gitコミットを確認します。整合性が取れ、現在のコードに対して鮮度を確認できる履歴だけから、前回との差分、優先確認候補、次の担当者向けのタスク概要を作成します。複数回の解析結果にある矛盾や鮮度切れも検査できます。
矛盾、未解決参照、低信頼度、変更・高影響領域を優先します。上位候補はAIでレビューすることもできますが、対象コード内の根拠となるファイル・行、状態、矛盾を検証してから登録します。履歴やAIの出力を無条件に正しいものとして引き継ぐ機能ではなく、確認できない場合は停止理由と人による確認事項を明示します。
CONFIRMATION PACK
「コードに答えがないこと」を、
確認できる質問に変える
解析結果から、コード上で観測できる現行挙動、コードからの推定、コード外でしか確定できない事項を切り分け、確認質問の一覧として出力します。
仕様書も担当者も揃わない現場ほど、この切り分けが調査の速度と安全性を決めます。
コードから観測できる現行挙動
根拠となるファイル・行を伴い、実装として確認できた内容です。「いま、こう動いている」という事実として扱います。
コードからの推定（要確認）
実装から読み取れるものの、断定はできない内容です。確認質問と、未確認のまま進めた場合のリスクを添えます。
コード外での確認が必須
業務判断、運用実態、外部との契約など、コードには答えが存在しない事項です。確認先と必要な証跡を示します。
| 確認が必要になる論点 | 生成される質問の例 | 確認先と必要な証跡 |
|---|---|---|
| 業務ルールの妥当性 | 抽出したルールは現在も正しい業務仕様か。適用開始時期、対象外・例外、変更権限とその根拠は何か。 | プロダクトオーナー／業務責任者 — 現行の業務規程・契約条件、例外運用の記録 |
| 数値ルールの根拠 | ルールに含まれる数値（上限、料率、日数など）を採用した理由、変更できる範囲、例外条件。 | プロダクトオーナー／業務責任者 — 料金表・業務規程、承認済みの変更記録 |
| 実行時設定の実値 | 環境ごとの実際の値、変更手順、Feature Flag の適用条件。 | 運用／プラットフォーム担当 — 環境別設定一覧、デプロイ設定 |
| 外部との契約 | APIの利用者、互換性要件、認証・権限、実際のリクエスト／レスポンスの例外。 | 連携先担当／API責任者 — API契約書またはOpenAPI、本番ログの代表例 |
| 実行時に決まる挙動 | この参照は、本番でどの設定・入力・経路により解決されるか。 | 開発担当＋運用担当 — 実行時設定、実行ログまたはトレース、対象環境での再現結果 |
| 設計意図・非機能 | その実装を選んだ理由と当時の制約、現在も維持すべき理由。実負荷、目標値、障害時の運用。 | 開発責任者／保守担当、運用担当 — 設計資料、変更履歴、監視指標・運用手順 |
1件ずつ、根拠と優先度を付けて渡します
confirmation_pack.md として、他の解析成果物と同じ出力先に残します。各項目には、確認質問、確認先の役割、必要な証跡、未確認のまま進めた場合のリスク、コード上の根拠（ファイル・行）が付き、優先度順に並びます。限られたヒアリングの時間を、重要な論点から使えます。書き出す際は、既知の機密項目名・パターンに当たる値をマスキングします。
推測を足さず、古い結果は「参考」と明示します
確認パックは保存済みの解析結果だけから作成し、追加のAI推論で内容を膨らませません。現在のコードに対して鮮度を確認できない場合は参考情報として明示し、確定仕様の判断には使わないよう注記します。作成できない場合は、停止理由と人による確認事項を返します。
コードに処理が存在することは、それが正しい業務仕様であることを意味しません。 確認パックは、この差を埋めるための質問リストです。既存実装をそのまま正解として移行・再実装してしまうリスクを、着手前に可視化します。
RELIABILITY
「それらしく見える」だけで終わらせない
分析の途中結果と生成文書を、あとから確認できる状態に残します。分かったことと、追加確認が必要なことを混同しないための仕組みです。
根拠の記録
発見事項に、元のファイル・行・参照の状態を紐付けます。重要な記述をコードまでたどって確認できます。
信頼度と未解決の可視化
静的に解決できない参照、解析範囲の不足、部分失敗を記録し、追加調査が必要な領域を明示します。
観測・推定・要確認の分離
コードで観測できた現行挙動、コードからの推定、コード外でしか確定できない事項を、別の分類として出力します。
構造化出力と検証
主要な分析結果は定めた形式で検証し、不正・空の結果を成功扱いしません。
解析履歴の再利用判定
保存した結果のハッシュ、対象パス、Gitコミットと現在のコードとの差分を確認し、使える履歴だけを次の調査の出発点にします。
AIレビューの根拠ゲート
AIで優先候補をレビューする場合も、対象コード内の根拠となるファイル・行、状態、矛盾を検証してから登録します。
構造化データの秘密値マスキング
パスワード、トークン、接続文字列など、既知の機密項目名・パターンに当たる値を保存時にマスキングします。
WHY WE DO NOT GUESS
確定できない部分を、根拠付きの確認事項へ変えます
Re::Viveは生成AIも使ってコードの意味や関係を読み解きます。ただし、AIがコードを読むことと、存在しない実行環境を再現できることは別です。
本番データや認証情報に触れず、対象システムを実行しないからこそ、実行時に初めて決まる振る舞いを推測だけで「確定」とは表示しません。
コード上で呼び出し先が明示されている処理は追跡できます。 呼び出し先が設定値・文字列・実行時の条件で選ばれる場合も、候補・設定参照・入口を特定します。実際に選ばれる一つの実装だけは、その時点の設定やデータで確定します。
動的な読み込み・リフレクション
import(moduleName) のように名前が設定値で決まる読み込みや、文字列・注釈からクラスやメソッドを選ぶ仕組みです。プラグイン、DIコンテナ、ORMなどで使われます。これは密結合・疎結合の良し悪しではなく、実装の選択がコードだけで一意に決まるかの違いです。候補・入口・設定参照は追えますが、実際にどれが選ばれるかは、その時点の設定が必要です。
コード生成・ビルド工程
スキーマやテンプレートからORMクライアント、APIクライアント、画面部品などを生成する仕組みです。生成後のコードや生成条件が対象に含まれていれば解析できます。含まれない場合は、生成元・参照箇所・必要な入力を明示します。
実行時設定
環境変数、Feature Flag、デプロイ先ごとの設定、秘密情報、リバースプロキシの設定などです。コードから「どの値が参照されるか」は抽出できますが、実際の値や有効な分岐は、安全に提供された設定資料なしには断定しません。
外部サービスの実際の応答
呼び出し先、リクエスト、エラー処理、認証方式はコードから追えます。一方、外部APIの現在の契約、相手側のデータ、障害時の挙動は対象コードの外にあります。必要に応じてAPI仕様、ログ、許可された検証環境で照合します。
Re::Viveが残すもの: 不確実な箇所を曖昧に埋めるのではなく、関連するファイル・行・参照候補とともに「何を確認すれば確定できるか」を成果物に残します。これらは前述の確認パックとして一覧化され、限られた担当者へのヒアリングや設定・ログの確認を、優先度の高い論点から進められます。
セキュリティ上のFindingと生成テストは、調査・レビューを効率化する材料です。専門監査や対象環境でのテストを置き換えるものではありません。
CASE STUDY
実績の紹介
仕様書が実態と乖離し、Gitのコミット履歴もなく、前任開発者と連絡が取れない既存Webシステムを解析。着手から約2週間で、移行判断に直接使える解析成果物一式を完成させました。
株式会社S様
| 解析対象コードベース | 460ファイル / 約8.7万行 |
|---|---|
| 解析対象画面 | 57画面 |
| 一件ずつ突合したAPIエンドポイント | 106本 |
| 特定・分類した高リスク | 83件（重大度 高23 / 中35 / 低25） |
| 納品した解析ドキュメント | 35ファイル / 4,425行 / 約57万文字 |
| AI基盤が自動抽出した構造化知見 | 296件（平均信頼度 0.965） |
| 自動生成した依存関係グラフ | 463ノード / エントリポイント169点 |
セキュリティ・認証
認証情報の露出経路、認証機構の実装上の弱点、ログ経由のデータ露出。
認可・権限境界
権限チェックの欠落箇所、権限の非対称性、権限バイアス経路。
パフォーマンス
N+1問題の発生箇所、一括処理の最適化箇所、一覧取得の非効率クエリ。
非同期処理
同期実行のままになっている処理系統、キュー基盤の有効化状態。
データ整合性
同時実行時の競合、トランザクション境界の不統一、多重実行時の制約違反。
運用・インフラ
定期実行基盤の稼働状況、ログ保持設定、ファイル配信のアクセス制御。
スコープ削減
未使用コード、実質動作していない機能、移行不要と確定した領域。
テスト空白
自動テストが存在しない機能領域の特定。