吉田真吾 (@yoshidashingo) です。
これだけは覚えて帰ってね💡
- OPERATIONSフェーズは将来拡張のためのプレースホルダーとして設計されている
- Adaptive Depthは「ステージの実行有無 (二値) 」と「成果物の詳細度 (適応的) 」を分離する
- aidlc-state.mdとaudit.mdは「再開可能性」と「追跡可能性」を高める設計になっている
- 承認ゲートは人間がAIの判断を検証・制御するための重要なチェックポイントとして機能する
- GitOps、SOC2/ISO27001の監査、Stage Gate Processと比較し、AI-DLCの設計原則を位置づける
第1回から第6回まで、AI-DLCの14ステージを1つずつ辿ってきました。今回は視点を変え、個々のステージを横断する設計原則 ― 適応的深度、状態管理、監査証跡、承認ゲート ― に焦点を当てます。これらの仕組みにより、AIが開発プロセスを主導する際の品質と安全性のリスクを低減する設計になっています。
引用元：AI 駆動開発ライフサイクル:ソフトウェアエンジニアリングの再構築 | Amazon Web Services ブログ
前半の総括: ステージを横断する設計原則へ
第6回のBuild and Testで「Ready for Operations: Yes/No」の判定が出たところで、CONSTRUCTIONフェーズまでの全ステージを見終えました。INCEPTIONで「何を、なぜ作るか」を決め、CONSTRUCTIONで「どう作るか」を設計してコードを生成する ― この流れを支える14ステージを、第1回から第6回まで6回にわたって解説してきました。
今回は視点を変えます。個々のステージではなく、AI-DLC全体を貫く横断的な設計原則に焦点を当てます。
OPERATIONSフェーズ: 未実装
AI-DLCの3フェーズの最後、OPERATIONSフェーズの仕様書を開くと、実質的な定義はわずか数行で、未実装な状態です。今後の拡張に期待しましょう。
Purpose: Placeholder for future operational phases (deployment, monitoring, maintenance)
Status: This phase is currently a placeholder and will be expanded in future versions.
デプロイメント計画と実行、監視と可観測性のセットアップ、インシデント対応手順、メンテナンスとサポートのワークフロー、本番準備チェックリスト ― 将来のスコープとして5項目が列挙されていますが、現時点では何も実装されていません。
Adaptive Depth: 深さを問題に合わせる
第3回で「3段階の深度 (Minimal / Standard / Comprehensive) 」として紹介したAdaptive Depthを、ここで改めて掘り下げます。これはAI-DLC全体を貫く中核的な設計原則です。
「実行するか」と「どこまで詳しく」の分離
Adaptive Depthの核心は、2つの判断を明確に分離していることにあります:
| 判断 | 性質 | 決定タイミング |
|---|---|---|
| ステージの実行有無 | 二値 (EXECUTEかSKIP) | Workflow Planningで決定 |
| 成果物の詳細度 | 適応的 (問題の複雑さに応じて変化) | 各ステージの実行中に判断 |
ステージを実行すると決まったら、そのステージで定義されたすべての成果物をAIが生成します。省略されるのは成果物そのものではなく、各成果物の中の詳細度です。
詳細度を決める6つの要因
仕様書では、詳細度を判断する際に考慮すべき6つの要因が定義されています:
| # | 要因 | 内容 |
|---|---|---|
| 1 | リクエストの明確さ | ユーザーの要求がどれだけ明確か |
| 2 | 問題の複雑さ | 解決空間がどれだけ複雑か |
| 3 | スコープ | 単一ファイルか、コンポーネントか、システム全体か |
| 4 | リスクレベル | エラーや漏れのインパクトの大きさ |
| 5 | 利用可能なコンテキスト | Greenfield/Brownfield、既存文書の有無 |
| 6 | ユーザーの好み | 簡潔さを好むか、詳細を好むか |
仕様書はこれを「問題に必要な詳細だけを生成する ― それ以上でも以下でもない」という原則で要約しています。
具体例: バグ修正とシステム移行
同じRequirements Analysisステージでも、バグ修正とシステム移行では生成される成果物の粒度が異なります:
バグ修正の場合:
- requirement-verification-questions.md: 必要最小限の確認質問
- requirements.md: 簡潔な機能要件、最小限のセクション構成
システム移行の場合:
- requirement-verification-questions.md: 複数ラウンド、10以上の質問
- requirements.md: 機能要件＋非機能要件の包括的な定義、トレーサビリティ、受入基準
成果物のファイル名と構造は同じですが、中身の密度が問題の複雑さに応じて変わります。
なお、詳細度の判断はAIに委ねられているため（仕様書には "Model decides" と明記されている）、AIが問題の複雑さを過大評価して不必要に詳細な成果物を生成したり、逆に過小評価して重要な詳細を省略したりするリスクがあります。また、同じプロジェクトでもセッションが異なれば判断が変わりうるため、一貫性の保証はありません。このリスクは、各ステージの承認ゲートでユーザーが成果物の詳細度を検証することで低減される設計ですが、最終的な品質判断は人間に委ねられています。
aidlc-state.md: 「どこまで進んだか」を記録する状態管理ファイル
AI-DLCのプロセスは、短くても数十分、複雑なプロジェクトでは数時間に及びます。AIとの対話セッションが中断されたり、コンテキストウィンドウ (AIが一度に処理できるテキスト量の上限) に達したりすることがあります。
aidlc-state.mdは、この中断と再開の問題を解決するための仕組みです。
記録される情報
aidlc-state.mdには、プロジェクトの現在位置が常に記録されています:
- プロジェクト名: 何のプロジェクトか
- 現在のフェーズ: INCEPTION / CONSTRUCTION / OPERATIONS
- 現在のステージ: どのステージを実行中か
- 最後に完了したステップ: どこまで終わったか
- 次のステップ: 次に何をすべきか
セッション再開の仕組み
ユーザーが新しいセッションでAI-DLCを再開すると、AIはまずaidlc-state.mdを読みます。そして以下のプロンプトを表示します:
前回の続きから再開できます。
- A) 中断したところから続ける
- B) 前のステージを確認する
この再開プロセスで重要なのは、仕様書が定義するSmart Context Loading (ステージに応じた段階的なコンテキスト読み込み) です。実行するステージに応じて、読み込むべき過去の成果物が変わります:
| 実行するステージ | 読み込む成果物 |
|---|---|
| 初期ステージ (Workspace Detection、Reverse Engineering) | ワークスペース分析 |
| 要件・ストーリー | RE成果物 ＋ 要件 |
| 設計ステージ | 要件 ＋ ストーリー ＋ アーキテクチャ ＋ 設計 |
| コードステージ | すべての成果物 ＋ 既存コード |
後のステージほど読み込む情報量が増えます。これは当然で、Code Generationを再開するなら、Requirements AnalysisからInfrastructure Designまでの全設計情報が必要だからです。
ただし、成果物ファイルの読み込みだけでは、前のセッションでの議論の文脈（なぜその設計判断に至ったかの推論過程）が完全に復元されるわけではありません。また、後半のステージでは読み込むべき成果物が増大し、LLMのコンテキストウィンドウの容量制約と競合する可能性があります。Smart Context Loadingはステージに応じた段階的読み込みでこの問題を緩和する設計ですが、大規模プロジェクトでの完全なコンテキスト復元には限界があります。
audit.md: すべてを記録する監査証跡
aidlc-state.mdが「現在地」を記録するのに対し、audit.mdは「過去の全記録」を保持します。AI-DLCのcore-workflow.mdには、監査ログに関する厳格なルールが定義されています。
4つの必須ルール
- すべてのユーザー入力をタイムスタンプ付きで記録する: 承認だけでなく、質問への回答、変更要求、コメントのすべて
- ユーザーの入力を完全にそのまま記録する: 要約や言い換えは禁止。原文をそのまま記録する
- 承認プロンプトを記録してからユーザーに提示する: 何を聞いたかも記録する
- ユーザーの応答を受信後にタイムスタンプ付きで記録する: 応答を受け取った後の記録も必須
タイムスタンプの形式はISO 8601 (YYYY-MM-DDTHH:MM:SSZ) が指定されています。
なぜ「要約禁止」なのか
2番目のルールが特に厳しいものです。AIは自然言語の要約機能を持つため、ユーザーの発言を「要約して分かりやすくする」ことができます。しかしaudit.mdでは、それが明示的に禁止されています。
理由は監査の原則にあります。監査証跡の価値は「後から第三者が検証できること」にあります。AIが要約した時点で、原文の意図が変わるリスクが生まれます。「承認します」と「まあいいんじゃない」では同じ承認でもニュアンスが異なります。原文を残すことで、後からの解釈の余地を排除しています。
追記のみ、上書き禁止
audit.mdに対する操作にも制約があります。既存の内容を読んだ上で追記するのが正しい方法であり、ファイル全体を上書きすることは禁止されています。これは単なる技術的な制約ではなく、監査ログは追記専用 (append-only) であるべきという監査の基本原則を、フレームワークのルールとして規定しているものです。
ただし、audit.mdは通常のMarkdownファイルであり、ファイルシステムレベルでの上書き防止機構や暗号学的な改ざん検知は備えていません。「追記のみ」ルールはLLMへのプロンプト指示として実装されており、ユーザーがテキストエディタで直接編集することは技術的に可能です。Gitなどのバージョン管理と組み合わせることで変更履歴を追跡できますが、エンタープライズの監査システムが備えるような改ざん耐性とは性質が異なります。
承認ゲート: 人間が最後に判断する
第1回で「ほぼすべてのステージに承認ゲートがある」と述べました。ここでは、この承認メカニズムの設計を掘り下げます。
ほぼすべてのステージに承認ゲートがある
14ステージのうち、承認なしで自動的に次に進むのはWorkspace Detectionだけです (理由は第2回で述べた通り) 。OPERATIONSフェーズは現時点でプレースホルダーであるため、実質的に承認ゲートが設置されているのは12ステージです。
それ以外のすべてのステージでは、「DO NOT PROCEED until user confirms」という指示が仕様書に明記されています。しかもこれは単なるガイドラインではなく、MANDATORY (必須) として定義されています。
2択の標準フォーマット
CONSTRUCTIONフェーズの承認メッセージには、統一されたフォーマットがあります:
あなたの選択肢:
- 変更を要求する ― レビューに基づいて修正を依頼
- 次のステージに進む ― 承認して次へ
「3番目の選択肢を追加するな」という指示まで仕様書に書かれています (NO EMERGENT BEHAVIOR) 。これはCONSTRUCTIONフェーズに限定されたルールで、3択に限らず、AIが独自に「一部だけ承認して進む」「スキップする」のような創発的なナビゲーションパターンを生み出すことを防ぐための設計です。LLM特有の問題（プロンプトに書かれていない選択肢を自律的に生成する傾向）に対する対策と位置づけられます。
承認疲れのリスク
12ステージに承認ゲートが設置されていることは安全性の観点からは望ましいですが、ユーザーが承認判断に疲弊し、内容を十分に精査せずに承認してしまう「承認疲れ (Approval Fatigue)」のリスクがあります。これはセキュリティ分野の「アラート疲れ」と同様の構造的課題です。Adaptive Depthによってステージ自体をスキップできることが部分的な緩和策になりますが、承認ゲートの有効性は最終的にユーザーの注意力に依存するという限界は認識しておく必要があります。
過信防止の仕組み
承認ゲートと関連して、AI-DLCにはOverconfidence Prevention (過信防止) という設計文書があります。AIが十分な質問をせずに先に進んでしまう傾向への対策です。
5つの原則が定められています:
- 迷ったら聞け: 曖昧さがあれば質問する
- 網羅的にカバーせよ: カテゴリを飛ばさず全領域を評価する
- 回答を徹底分析せよ: ユーザーの回答に曖昧さがないか精査する
- フォローアップは必須: 不明瞭な回答には必ず追加質問する
- 曖昧さを残して進むな: すべての曖昧さが解消されるまで次に進まない
仕様書は「聞きすぎるくらい聞け」と明言しています。これは、AIが間違った前提で設計を進めるコストのほうが、質問が多すぎるコストよりも大きいという設計判断に基づいています。ただし、質問が過多になるとユーザーの集中力が低下し、かえって回答の質が下がる可能性があります。開発速度も質問・回答のラウンドトリップ分だけ遅延します。Adaptive Depthが緩和策として機能し、単純なタスクでは質問数が自然に減る設計になっていますが、質問量と回答品質のバランスは実際の運用で注意が必要です。
既存手法との比較: 適応・監査・承認の系譜
GitOps: Gitを「唯一の真実」とする
GitOpsは、Alexis Richardson (Weaveworks CEO兼共同創業者) が2017年にブログ記事「GitOps - Operations by Pull Request」で提唱した運用手法です。その後、CNCF GitOps Working GroupがOpenGitOps v1.0 (2021-2022年) として4つの原則を正式に定義しました:
| # | 原則 | 内容 |
|---|---|---|
| 1 | Declarative (宣言的) | システムの望む状態を宣言的に記述する |
| 2 | Versioned and Immutable (バージョン管理・不変) | 望む状態をバージョン管理し不変性を担保する |
| 3 | Pulled Automatically (自動プル) | ソフトウェアエージェントが望む状態を自動的に取得・適用する |
| 4 | Continuously Reconciled (継続的調整) | エージェントが実際の状態を継続的に観測し、望む状態に収束させる |
ArgoCD、Fluxなどのツールが、この原則に基づいてKubernetesクラスターの状態をGitリポジトリと自動同期します。
AI-DLCとGitOpsの共通点は「単一の情報源 (Single Source of Truth) 」という考え方です:
| 観点 | GitOps | AI-DLC |
|---|---|---|
| 単一の情報源 | Gitリポジトリ | aidlc-state.md ＋ audit.md |
| 状態のテキスト表現 | YAMLマニフェスト (望む状態の宣言的仕様) | Markdownの成果物群 (設計意図の文書化) |
| 差分の検知 | Git diffで自動検知 | セッション再開時にstate読み込み |
| 差分の修復 | Reconciliation Loopによる自動修復 | ユーザーが手動でセッションを再開 |
| 変更の承認 | Pull Requestレビュー | 各ステージの承認ゲート |
管理対象のレイヤーは異なります。GitOpsが「インフラの状態」を、AI-DLCは「設計プロセスの状態」を扱います。「現在の状態がファイルに書かれている」という設計思想には共通点がありますが、性質は異なります。GitOpsのファイルは「あるべき姿 (desired state) 」を宣言し、ソフトウェアエージェントが実環境を自動的にその状態に収束させます。AI-DLCのaidlc-state.mdは「現在の進捗 (current state) 」を記録するファイルであり、次のセッション再開時にAIがこの記録を読み取って作業を継続します。自動収束と手動再開という運用面での違いがある点は重要です。
SOC2 / ISO27001: 監査証跡の国際標準
SOC2は、AICPA (米国公認会計士協会) が2010年にSSAE 16とともに導入した、サービス組織の内部統制に関する報告フレームワークです。セキュリティ、可用性、処理の完全性、機密性、プライバシーの5つのTrust Service Criteria (元はAICPAのTrust Servicesフレームワークに由来) で構成されています。
ISO 27001は、情報セキュリティマネジメントシステム (ISMS) の国際標準です。2005年にISO/IECとして初版が発行され、2013年と2022年に改訂されています。継続的改善を要求し、その構造はPDCAサイクル (Plan-Do-Check-Act) の概念を内包しています。
両標準に共通する核心は監査証跡 (Audit Trail) です:
| 観点 | SOC2 / ISO27001の監査証跡 | AI-DLCのaudit.md |
|---|---|---|
| 記録対象 | システムアクセス、変更操作、セキュリティイベント | ユーザー入力、AI応答、承認判断 |
| タイムスタンプ | 必須 | ISO 8601形式で必須 |
| 原文保持 | 証跡の改変は禁止 | ユーザー入力の要約・言い換えは禁止 |
| 追記専用 | ログの削除・上書きは禁止 | audit.mdの上書きは禁止 (追記のみ) |
| 改ざん耐性 | 技術的保証あり (WORMストレージ、暗号的ハッシュ、アクセス制御等) | なし (通常のMarkdownファイル、プロンプト指示による規定のみ) |
| 目的 | 第三者による事後検証 (法的証拠能力を含む) | 設計判断の追跡と再現性の確保 |
「後から検証可能な記録を残す」という根底の思想は共通しています。ただし、SOC2/ISO27001の監査証跡は技術的な改ざん防止機構と法的証拠能力を備えた仕組みの上に成り立っているのに対し、AI-DLCのaudit.mdはプロンプト指示による追記専用ルールに依存しています。audit.mdは開発プロセスの透明性を高めるための仕組みとして評価するのが妥当であり、SOC2/ISO27001が求める厳格な監査証跡と同等の証拠能力を持つものではありません。
Stage Gate Process: ゲートで進捗を管理する
Stage Gate Processは、Robert G. Cooperが1986年の著書『Winning at New Products』で新製品開発プロセスの研究を発表し、1990年の論文で「Stage-Gate」の名称とフレームワークを確立した、新製品開発のプロセスモデルです。ソフトウェアに限らず、製造業を含む幅広い業界で使われています。
Stage Gate Processの構造はシンプルです: Stage (作業フェーズ) とGate (判定ポイント) が交互に並びます。各Gateでは以下の4つの判定が下されます:
| 判定 | 意味 |
|---|---|
| Go | 次のStageに進む |
| Kill | プロジェクトを中止する |
| Hold | 条件が揃うまで保留する |
| Recycle | 手戻りして修正を求める |
AI-DLCの承認ゲートと対比します:
| 観点 | Stage Gate Process | AI-DLCの承認ゲート |
|---|---|---|
| 判定者 | Gatekeepers (リソースを管理する機能横断的なシニアマネージャー) | ユーザー (人間) |
| 判定の種類 | Go / Kill / Hold / Recycle | 承認 / 変更要求 |
| 判定基準 | Must-Meet (必須) ＋ Should-Meet (推奨) | 成果物のレビュー |
| 不合格時 | Kill (中止) またはRecycle (手戻り) | 変更を適用して再承認 |
| 対象 | 新製品開発プロジェクト全体 | ソフトウェア設計の各ステージ |
最大の違いはKill (中止) の有無です。Stage Gate Processでは、ゲートでプロジェクト自体を中止できます。AI-DLCの承認ゲートには中止という選択肢がありません ― 「承認する」か「変更を要求する」かの二択です。
これは対象の性質の違いを反映しています。Stage Gate Processは製品開発全体を管理するため、市場性がないと判断されればプロジェクトごと中止する判断が必要です。AI-DLCは1つのプロジェクト内の設計プロセスを管理するため、プロジェクト中止の判断はフレームワークの外にあります。Kill選択肢の欠如は、プロジェクトの前提条件が崩れた場合（予算凍結、技術的不可能性の発覚等）に問題になりえます。ユーザーはセッションを単に終了するしかなく、その場合、中止の判断理由がaudit.mdに記録されず監査証跡の連続性が途切れます。
共通しているのは「成果物が基準を満たすまで次に進めない」という基本的な発想です。Stage Gate Processではこれを「Must-Meet Criteria (必須基準) 」と呼び、AI-DLCでは「Explicit Approval (明示的承認) 」と呼びます。ただし、Stage Gateは財務指標や技術成熟度などの定量的基準をGatekeepersが組織的に判定するのに対し、AI-DLCはユーザー個人が成果物をレビューして判断するため、判定の厳密性やガバナンスのレベルは異なります。
まとめ
第7回はAI-DLCを貫く設計思想 (OPERATIONSフェーズ・適応的深度・状態管理・監査証跡・承認ゲート) について説明しました。今回学んだことは以下です。
- OPERATIONSフェーズは意図的なプレースホルダーであり、拡張性と設計範囲の明示を両立しています
- Adaptive Depthはステージの実行有無 (二値) と成果物の詳細度 (適応的) を分離し、6要因で詳細度を調整します。ただし詳細度の判断はAIに委ねられており、過少・過剰のリスクは承認ゲートで低減する設計です
- aidlc-state.mdはプロジェクトの現在位置を記録し、Smart Context Loadingで効率的なセッション再開を支援します。ただし推論過程の復元やコンテキストウィンドウの容量制約という限界があります
- audit.mdは全ユーザー入力を原文のままタイムスタンプ付きで追記し、監査証跡を形成します。ただしMarkdownファイルであり、技術的な改ざん耐性はありません
- 承認ゲートは14ステージ中12ステージに設置され、人間の判断権を確保する設計です。一方で承認疲れのリスクもあり、有効性はユーザーの注意力に依存します
- GitOpsの「単一の情報源」、SOC2/ISO27001の「監査証跡」、Stage Gate Processの「品質ゲート」は、それぞれAI-DLCのstate管理、audit.md、承認ゲートと共通する発想に基づいていますが、技術的保証のレベルや運用の厳密性には差があります
ここまでの7回で、AI-DLCが14ステージとこれらの横断原則によって「何を、なぜ、どう作るか」を体系的に設計するフレームワークの概要を紹介しました
次回予告
ここまでの7回で、AI-DLCの概念と設計思想の解説を終えます。第8回からは視点を大きく変え、AI-DLCのワークフロー定義ファイルを1行ずつ読み解いていきます。まずはcore-workflow.md ― AI-DLCの「憲法」とも言えるマスターワークフローファイルの構造と、4つのMANDATORYルールを解説します。
