吉田真吾 (@yoshidashingo) です。
これだけは覚えて帰ってね💡
- AI-DLCは最初に「今、何がある？」を自動で調べる (Workspace Detection)
- 既存コードがあれば、AIがリバースエンジニアリングで全体像を読み解く
- 「現場を把握してから計画する」という考え方は、TOGAFやレガシーコード改善にも共通する
引用元：AI 駆動開発ライフサイクル:ソフトウェアエンジニアリングの再構築 | Amazon Web Services ブログ
なぜ「出発点」が大事なのか
ソフトウェアプロジェクトには、大きく分けて2つの出発点があります。
ゼロから作る (Greenfield) か、既存のコードがある状態から始める (Brownfield) か。
Greenfield (更地) は文字通り何もない状態です。自由度は高いですが、すべてを一から決める必要があります。一方、Brownfield (既開発地) は既存のシステムがすでに動いています。制約は多いですが、ゼロから作る必要はありません。
この区別が重要なのは、出発点によってやるべきことがまったく違うからです。更地に家を建てるのと、既存の家をリフォームするのでは、最初にやるべき調査が根本的に異なります。AI-DLCはこの違いを、フレームワークレベルで自動判定します。
Workspace Detection: AI-DLCの「健康診断」
AI-DLCのプロセスは、Inception (計画) フェーズの最初のステージ「Workspace Detection」から始まります。第1回で紹介した14ステージの1番目にあたります。
やること
Workspace Detectionでは、AIが以下の6ステップを実行します:
- 既存プロジェクトの確認: 以前のAI-DLCセッションの状態ファイル (
aidlc-state.md) があるか確認します。あれば、前回の続きから再開できます。 - コードの有無を調べる: ソースコードファイル (.java, .py, .ts, .goなど) 、ビルドファイル (package.json, pom.xml, build.gradleなど) 、プロジェクト構成を自動スキャンします。
- Brownfield/Greenfieldの判定: コードがあればBrownfield、なければGreenfieldとフラグを立てます。
- 状態ファイルの作成: プロジェクトの基本情報をaidlc-state.mdに記録します。
- 結果の報告: 「こういう状態でした」とユーザーに知らせます。
- 次のステージへ自動で進む: ここが特徴的 ― 承認不要で次に進みます。
唯一の「承認なし」ステージ
第1回で「ほぼすべてのステージに承認ゲートがある」と書きました。Workspace Detectionは、承認ゲートの例外です。
なぜ承認が不要なのか？ このステージは情報を集めるだけで、何も変更しないからです。コードを書き換えたりファイルを消したりしません。ユーザーの意思決定を要する判断もしません。「現場の状況を報告する」だけなので、逐一承認を求める必要がありません。
これは合理的な設計です。承認ゲートは重要ですが、何でもかんでも承認を求めると作業が停滞します。「リスクのない情報収集は自動で、判断を伴うステップは承認を」という設計思想がここに表れています。
Brownfield判定のあと: Reverse Engineering
Workspace Detectionの結果によって、次に何が起こるかが分岐します。Greenfieldと判定された場合はそのまま要件分析 (Requirements Analysis) へ進みます。一方、Brownfieldと判定された場合は「Reverse Engineering」が実行されます。これはCONDITIONAL (条件付き実行) ステージの1つで、既存コードがあるときだけ実行されます。
既存コードを「読み解く」とは
Reverse Engineeringという言葉は、もともとハードウェアの世界で使われていました。完成品を分解して、設計図を逆算する行為です。ソフトウェアの世界では、既存のコードベースを解析して、設計上の意図や構造を文書化することを指します。
AI-DLCのReverse Engineeringステージでは、AIが既存のコードを隅から隅まで読み、以下の8つの成果物を生成します:
| # | 成果物 | 内容 |
|---|---|---|
| 1 | ビジネス概要 | システムの存在目的、ビジネスコンテキスト図、業務トランザクション一覧 |
| 2 | アーキテクチャ | コンポーネント構成、データフロー、外部システムとの統合ポイント |
| 3 | コード構造 | ビルドシステム、主要クラス/モジュール、採用されている設計パターン |
| 4 | API仕様 | REST/内部APIのエンドポイント一覧、リクエスト/レスポンスのデータモデル |
| 5 | コンポーネント一覧 | アプリケーション/インフラ/共有ライブラリ/テストの分類と構成 |
| 6 | 技術スタック | 言語、フレームワーク、インフラ基盤、ビルドツールのバージョン情報 |
| 7 | 依存関係 | 内部依存のMermaid図、外部ライブラリのバージョンとライセンス |
| 8 | コード品質評価 | テストカバレッジ、コーディング規約の遵守状況、技術的負債の所在 |
なぜ8つも必要なのか
一見すると多く見えます。しかし、これには明確な根拠があります。
既存コードベースを前にしたとき、「何が分からないか分からない」状態に陥りがちです。「認証はどうなっているんだろう」「このAPIはどこから呼ばれているんだろう」「テストはどこまで書かれているんだろう」― 疑問は尽きません。
AI-DLCは、8つの成果物テンプレートであらかじめ「調べるべきこと」を網羅的に定義しています。AIが「何を調べればいいか」を判断するのではなく、フレームワークが「これを調べろ」と指示する構造です。抜け漏れを防ぐための設計です。
Reverse Engineeringの特殊な再実行ルール
もう1つ注目したい仕様があります。Reverse EngineeringはBrownfieldプロジェクトが検出されるたびに必ず再実行されます。以前の成果物が残っていても、スキップせずに最新のコード状態を反映し直します。
「前回の解析結果をそのまま使えばいいのでは？」と思うかもしれません。しかし既存コードは日々変化します。前回の解析時から新しいAPIが追加されていたり、依存ライブラリが更新されていたりする可能性があります。陳腐化した設計文書は誤った判断を招くリスクがあります ― AI-DLCはこのリスクを「毎回やり直す」というシンプルなルールで回避しています。
既存手法との比較: 同じ知恵、異なるスケール
AI-DLCの「事実確認ファースト」は、実はソフトウェア工学の世界で繰り返し発見されてきたアプローチです。3つの既存手法と対比してみましょう。
TOGAFのArchitecture Vision
TOGAF (The Open Group Architecture Framework) は、エンタープライズアーキテクチャのフレームワークとして広く知られています。その中核であるADM (Architecture Development Method) の最初のフェーズが「Phase A: Architecture Vision」です。
Phase Aでは以下のようなことをします:
- ステークホルダーの特定と要件の把握
- ビジネスゴールと推進要因の確認
- 現在の能力 (Capability) の評価とギャップ分析
- 目指すべき将来像 (Architecture Vision) の策定
- リスクの洗い出し
AI-DLCのWorkspace Detection + Reverse Engineeringと並べてみると、面白い対比が見えてきます:
| 観点 | TOGAF Phase A | AI-DLC (WD + RE) |
|---|---|---|
| 目的 | 将来のアーキテクチャビジョンを定義 | 現在のワークスペース状態を把握 |
| 対象 | 組織全体のエンタープライズアーキテクチャ | 1つのプロジェクト/コードベース |
| 実行者 | 人間のアーキテクト | AI |
| 所要時間 | 数週間〜数ヶ月 | 数分〜数十分 |
| 成果物 | Architecture Vision文書、Statement of Architecture Work | 8つの設計文書 (自動生成) |
| 承認 | ステークホルダー承認が必要 | WDは承認不要、REは承認必要 |
※AI-DLC側の所要時間はコードベースの規模やAIモデルの処理能力に依存します。上記はあくまで目安です。
スケールと対象はまったく異なるため単純比較はできませんが、「まず現状を把握してから計画を立てる」という設計思想は共通しています。
レガシーコード改善の考え方
Michael Feathersの名著『Working Effectively with Legacy Code (レガシーコード改善ガイド) 』では、レガシーコードを「テストのないコード」と定義しています。そして、レガシーコードを改善する最初のステップは「まず理解する」ことだと説いています。
Feathersが提案するアプローチはこちらです:
- 変更すべき箇所を特定する: どこを直したいのかを明確にします
- テストを書ける場所を見つける: 既存コードの中で、テストが書ける「接ぎ木点 (seam) 」を探します
- 依存関係を把握する: 変更対象のコードが、他のどこに影響するかを調べます
- テストで保護してから変更する: テストという安全網を張ってから、初めてコードに手を入れます
AI-DLCのReverse Engineeringが生成する依存関係の文書、コード品質評価、技術スタック一覧は、この「テストで保護する前段階の理解」と同じ発想をAIによる解析で実現しようとするものです。
Strangler Figパターンとの接点
Brownfieldプロジェクトで既存システムを段階的に刷新する手法に、Martin Fowlerが命名した「Strangler Fig (絞め殺しの木) パターン」があります。熱帯の絞め殺しの木が宿主の木に巻きついて徐々に置き換えるように、レガシーシステムの機能を新しいシステムに少しずつ移行していきます。
このパターンの第一歩も「既存システムの理解」です。何が動いているのか分からないまま置き換えを始めるわけにはいきません。AI-DLCのReverse Engineeringで生成されるビジネス概要やAPI仕様は、Strangler Figパターンを適用する際の「置き換え計画」の基礎資料としても機能します。
AI-DLCが「出発点」で示す設計原則
ここまで見てきたWorkspace DetectionとReverse Engineeringには、AI-DLC全体を貫く3つの設計原則が凝縮されています。これらの原則は、今後の回で取り上げるすべてのステージにも共通するものです。
1. 事実 → 判断 → 実行の順序を強制する
AI-DLCはステージの実行順序をフレームワークレベルで固定しています。「何を作るか」を議論するRequirements Analysisの前に、必ずWorkspace Detectionが来ます。人間だけのプロジェクトでは「とりあえず作り始めよう」と順序が崩れがちですが、AI-DLCではそれが構造的に起こりません。
2. リスクに応じてプロセスを調整する
Greenfieldでは発生しない「既存機能の意図しない破壊」というリスクに対して、BrownfieldではReverse Engineeringが自動で追加されます。プロセスの重さを一律にするのではなく、リスクの大きさに応じて調整する ― この考え方は第7回で扱う「Adaptive Depth (適応型深度) 」にもつながっていきます。
3. 承認コストを最小化する
前述のとおり、Workspace Detectionは情報収集なので承認不要、Reverse Engineeringは設計判断を含むので承認必要。この使い分けは、後続のステージでも一貫して適用される原則です。
まとめ
第2回はAI-DLCの出発点となるWorkspace DetectionとReverse Engineeringについて説明しました。今回学んだことは以下です。
- AI-DLCは最初のステージ「Workspace Detection」で、プロジェクトの状態を自動調査します
- Brownfield/Greenfieldの判定結果に応じて、以降のプロセスが自動で分岐します
- Brownfieldの場合は「Reverse Engineering」でAIが8つの設計文書を生成し、毎回最新状態を反映し直します
- 「事実確認ファースト」の考え方は、TOGAF、レガシーコード改善、Strangler Figパターンにも共通します
- 「事実 → 判断 → 実行」の順序強制、リスクに応じたプロセス調整、承認コストの最小化 ― この3原則はAI-DLC全体を貫く設計思想です
次回予告
第3回では、現場把握のあとに来る「Requirements Analysis」と「User Stories」を取り上げます。「何を作るか」をどうやって決めるのか？ AI-DLCが採用する3段階の深度 (Minimal / Standard / Comprehensive) や、質問ファイル方式という独自の仕組みを、アジャイルのユーザーストーリーやEARS記法、DDDのユビキタス言語と比較しながら解説します。
