---
type: Reference
title: "AI-DLC 用語集"
description: "AI-DLC（AI-Driven Development Lifecycle）の用語を、方法論の基本概念・成果物・フェーズと儀式・計画と見積もり・実装とテスト・参照実装（aidlc-workflows）の区分で定義し、XP・Scrum の用語との対応と、本プロジェクトの AI-DLC 版ガイドでの参照先を示す。"
tags: [reference]
status: stable
generated: { by: claude-code/claude-fable-5-1, at: 2026-09-12T06:45:00Z }
sources:
  - id: aidlc-paper
    resource: https://prod.d13rzhkk8cj2z0.amplifyapp.com/aidlc.pdf
    title: AI-Driven Development Lifecycle (AI-DLC) Method Definition
    author: human:raja-sp
  - id: aidlc-workflows-glossary
    resource: https://github.com/awslabs/aidlc-workflows/blob/main/docs/guide/glossary.md
    title: awslabs/aidlc-workflows Glossary
    author: org:awslabs
  - id: aidlc-guide
    resource: ./AI-DLC導入ガイド.md
    title: AI-DLC 導入ガイド
    author: claude-code/claude-fable-5-1
verified:
  - { by: human:kakimomokuri, at: 2026-09-12T06:25:42Z }
---

# AI-DLC 用語集

本プロジェクトで使う AI-DLC の用語を定義します。出典は AWS の Method Definition Paper（論文）、参照実装 awslabs/aidlc-workflows（参照実装）、および本プロジェクトの AI-DLC 版ガイド（本プロジェクト）のいずれかです。本プロジェクトが独自に導入した用語には、その旨を明記しています。

用語の背景は [AI-DLC 導入ガイド](AI-DLC導入ガイド.md) を、活動ごとの使い方は [開発ガイド（AI-DLC 版）](開発ガイド_AI-DLC版.md) を参照してください。

---

## 1. 方法論の基本概念

| 用語 | 英語 | 定義 | 出典 |
| :--- | :--- | :--- | :--- |
| AI-DLC | AI-Driven Development Lifecycle | AI を開発プロセスの中心的な協働者として据え、ワークフロー・ロール・イテレーションを AI 前提で再設計した AI ネイティブの開発方法論。AWS が提唱 | 論文 |
| AI 支援 | AI-Assisted | 人が知的労働の大半を担い、AI がコード補完など細粒度の個別タスクを強化する段階。AI-DLC 以前のパラダイム | 論文 |
| AI 駆動 | AI-Driven | AI が計画・タスク分解・設計・生成を担い、人が検証・決定・監督を担う段階。AI-DLC が採るパラダイム | 論文 |
| AI 自律 | AI-Autonomous | 要件を渡して AI に丸投げする方式。現在の AI では信頼性と検証可能性が不足するため、AI-DLC はこれを採らない | 本プロジェクト（Qiita 記事の整理に基づく） |
| 会話の方向の逆転 | Reverse the Conversation Direction | 人が AI に頼むのではなく、AI が計画を提案し質問を投げて会話を駆動し、人が承認者として応答する構図。AI-DLC の第 2 原則 | 論文 |
| 後付けではなく再設計 | Reimagine rather than Retrofit | 既存の SDLC やアジャイル手法に AI を後付けせず、第一原理から手法を再設計するという AI-DLC の第 1 原則。「速い馬車ではなく自動車」 | 論文 |
| 損失関数 | Loss function | 各ステップでの人の検証を、誤りが下流で膨らむ前に捕捉・修正する仕組みに見立てた比喩。承認ゲートの設計原理 | 論文 |
| 即席セメント | Quick-cement | AI が生成したコードが検証を経ずに積み上がり、硬直化して将来の変更を妨げる状態。人の検証で防ぐべき技術的負債 | 論文 |
| Google Maps のアナロジー | — | 人が目的地（Intent）を設定し、システムが道順（タスク分解と推奨）を示し、人が道中で監督する関係。AI と人の役割分担の説明 | 論文 |
| 人との共生 | Human symbiosis | 人の検証とリスク低減に不可欠な成果物（ユーザーストーリー・リスク台帳）を方法論の再設計後も残すという第 6 原則 | 論文 |
| フレーバー | Flavor | 中核に置く設計技法による AI-DLC の変種。論文は DDD フレーバーを定義し、BDD・TDD フレーバーの存在を明記。本プロジェクトは TDD フレーバー | 論文・本プロジェクト |
| セマンティクス密度 | Semantic density | AI に渡す記述の、曖昧さの少なさと意味情報の濃さ。ドメイン用語と制約を明示し、判断を AI に委ねる語を避けることで高める | 本プロジェクト（Qiita 記事の整理に基づく） |
| ガードレール | Guardrail | 人が AI の振る舞いを修正した内容を恒久的な規則として残し、同じ誤りを繰り返さないようにする仕組み。本プロジェクトでは `CLAUDE.md`・`PROJECT.md`・スキルに反映する | 参照実装・本プロジェクト |
| コンテキストメモリ | Context memory | 永続化された成果物（Intent・ストーリー・ドメインモデル・テスト計画など）の集合。AI がライフサイクル全体で参照する | 論文 |
| トレーサビリティ | Traceability | 成果物同士のリンクにより、前方（Intent → コード）と後方（コード → Intent）の両方向で対応をたどれること | 論文 |

---

## 2. 成果物

| 用語 | 英語 | 定義 | 対応する既存用語 | 出典 |
| :--- | :--- | :--- | :--- | :--- |
| Intent（意図） | Intent | 達成したいことを表す高水準の目的宣言。ビジネス目標・機能・技術的成果のいずれでもよい。AI によるタスク分解の起点 | ビジネス目標、プロダクトビジョン | 論文 |
| Unit（作業単位） | Unit / Unit of Work | Intent から導出された、測定可能な価値を提供する自己完結の作業要素。互いに疎結合で、独立した開発とデプロイを可能にする | DDD のサブドメイン、Scrum のエピック | 論文 |
| Bolt（ボルト） | Bolt | AI-DLC における最小のイテレーション。Unit またはその中のタスク群を時間・日単位で実装する。1 つの Unit は複数の Bolt で、並列にも逐次にも実行できる | Scrum のスプリント、XP のイテレーション | 論文 |
| ユーザーストーリー | User Story | Unit の機能スコープを記述した、人と AI の理解を揃える契約。AI-DLC でも従来のまま残る成果物 | XP・Scrum のユーザーストーリー | 論文 |
| 受入条件 | Acceptance Criteria | ストーリーの完了を一意に判定する条件。AI がテストを生成する根拠になるため、Given/When/Then で書く | 受入テストの基準 | 論文・本プロジェクト |
| Level 1 計画 | Level 1 Plan | Intent を実現するワークフロー全体を示す、AI が最初に提案する計画。人が検証・修正する | リリース計画の骨子 | 論文 |
| Level 2 計画 | Level 2 Plan | Level 1 計画の各ステップを AI が実行可能なサブタスクに分解したもの。再帰的に続く | イテレーション計画、タスク分解 | 論文 |
| ステップ計画 | Step plan | Bolt の中で AI が書くチェックボックス付きの Markdown 計画。人が承認してから 1 ステップずつ実行する | TODO リスト | 本プロジェクト |
| Domain Design | Domain Design | Unit の中核業務ロジックをインフラから独立してモデル化したもの。集約・値オブジェクト・エンティティ・ドメインイベント・リポジトリ・ファクトリを含む | ドメインモデル | 論文 |
| Logical Design | Logical Design | Domain Design を非機能要件に合わせて拡張し、CQRS やサーキットブレーカーなどのアーキテクチャパターンを適用したもの。ADR を伴う | アーキテクチャ設計 | 論文 |
| Deployment Unit | Deployment Unit | パッケージ化された実行可能コード・構成・インフラ。機能・セキュリティ・NFR・運用リスクについてテスト済みで、デプロイ可能な状態 | リリース可能なインクリメント | 論文 |
| PRFAQ | Press Release / FAQ | プレスリリースと FAQ の形式で、ビジネス意図・機能・期待効果を要約した文書。Inception の任意成果物 | — | 論文 |
| NFR 定義 | Non-Functional Requirements | Unit に固有の非機能要件。Logical Design と Deployment Unit のテストに反映される | 非機能要件 | 論文 |
| リスク記述 | Risk description | Unit に関するリスクを組織のリスク台帳と対応づけたもの。AI に渡せない情報や確認必須の操作を含む | リスク台帳 | 論文 |
| 測定基準 | Measurement criteria | Unit の成功をどう測るかを示し、Intent のビジネス価値にトレースできる指標 | KPI、成功指標 | 論文 |
| 静的モデル | Static model | ブラウンフィールドで既存コードから復元する、コンポーネント・責務・関係のモデル | クラス図、コンポーネント図 | 論文 |
| 動的モデル | Dynamic model | ブラウンフィールドで既存コードから復元する、主要ユースケースを実現するコンポーネント間の相互作用のモデル | シーケンス図、ユースケース実現 | 論文 |
| 昇格 | Elevate | 既存コードを静的モデルと動的モデルに引き上げ、AI に渡すコンテキストを簡潔かつ正確にすること | リバースエンジニアリング | 論文 |
| AI の仮定 | AI assumption | AI が成果物を生成する際に置いた前提。明示し、承認ゲートで確認してから先に進む | — | 参照実装・本プロジェクト |

---

## 3. フェーズと儀式

| 用語 | 英語 | 定義 | 対応する既存用語 | 出典 |
| :--- | :--- | :--- | :--- | :--- |
| Inception（開始） | Inception Phase | Intent を捉え、開発可能な Unit に変換するフェーズ。成果物はストーリー・受入条件・NFR・リスク・測定基準・推奨 Bolt | 分析、要件定義、計画ゲーム | 論文 |
| Construction（構築） | Construction Phase | Unit をテスト済みで運用可能な Deployment Unit に変換するフェーズ。Domain Design → Logical Design → コード → テストと進む | 開発、イテレーション | 論文 |
| Operation（運用） | Operations Phase | デプロイ・可観測性・保守を担うフェーズ。AI がテレメトリを分析して対応を提案し、人が承認して実行する | 運用、構築、配置 | 論文 |
| Mob Elaboration | Mob Elaboration | Inception の儀式。ファシリテーターの進行のもと、同じ部屋・共有画面でモブ全員が AI の質問に答え、AI が提案した分解を検証・精緻化する | バックログリファインメント、要件定義ワークショップ | 論文 |
| Mob Construction | Mob Construction | Construction の儀式。チームが同じ部屋で統合仕様を交換し、AI が提示する設計・UX・テストの選択肢に対して技術判断を下し、Bolt を届ける | ペア／モブプログラミング | 論文 |
| モブ | Mob | Mob Elaboration・Mob Construction に参加する、プロダクトオーナー・開発者・QA などの関係者の集まり | チーム全体（Whole Team） | 論文 |
| シングルピザチーム | Single-pizza team | AI-DLC で推奨される小さなチーム。目安はフルスタック開発者 1 名・ビジネス担当 1 名・スペシャリスト 1 名 | ツーピザチーム | 本プロジェクト（Qiita 記事の整理に基づく） |
| 承認ゲート | Approval gate | AI が生成した成果物を人がレビューし、承認・変更依頼・現状で受け入れのいずれかを選ぶチェックポイント。人の関与が「損失関数」として働く場所 | コードレビュー、受け入れ | 参照実装 |
| 変更依頼 | Request Changes | 承認ゲートで人が修正点を指示し、AI が修正して再提示すること | レビュー指摘 | 参照実装 |
| 現状で受け入れ | Accept as-is | 変更依頼が 3 回以上続いたときに現れる選択肢。現状の成果物を記録して先へ進み、無限の修正ループを防ぐ | — | 参照実装 |
| 検証ゲート | Verification gate | フェーズ境界で、必要な成果物の存在・トレーサビリティ・孤立した成果物の有無を自動チェックする仕組み | 整合性検証 | 参照実装 |
| ウォーキングスケルトン | Walking skeleton | 最初の Bolt。すべての統合ポイントを通るエンドツーエンドの最小の縦割り。ここで AI の出力品質を確かめ、以降のゲート密度を決める | XP のウォーキングスケルトン | 参照実装・本プロジェクト |
| ゲート密度 | Gate density | 承認ゲートをどの粒度（サイクルごと・ステップごと・Bolt ごと）に置くか。ウォーキングスケルトンの結果とエントロピー評価で決める | — | 本プロジェクト |
| 自律実行 | Autonomous mode | ウォーキングスケルトン通過後、失敗時と最終ゲート以外のゲートを省いて AI に進ませる選択。確認必須の操作では必ず停止する | — | 参照実装 |
| ラダープロンプト | Ladder prompt | ウォーキングスケルトンのゲート通過直後に 1 回だけ現れる、自律実行かゲート維持かを選ぶ問い | — | 参照実装 |
| フィードバックループ | Feedback loop | Operation で得た運用の洞察（利用状況・性能・コスト）を次の Inception の Intent に戻す循環 | ふりかえり、リリース後のフィードバック | 論文・参照実装 |

---

## 4. 計画と見積もり

| 用語 | 英語 | 定義 | 対応する既存用語 | 出典 |
| :--- | :--- | :--- | :--- | :--- |
| 承認駆動 | Approval-driven | チームが「できる」と宣言する代わりに、人が AI の計画を承認ゲートで承認することで Bolt 計画を確定する方式 | コミットメント駆動 | 本プロジェクト |
| Bolt 計画 | Bolt plan | 各 Bolt に含める Unit・完了条件・確認したい仮説・担当・並列／順序を定めた計画。AI が提案し、人が承認する | イテレーション計画 | 参照実装・本プロジェクト |
| Bolt ゴール | Bolt goal | Bolt で達成することを 1〜2 行で書いたもの。必ず「確認したい仮説」を含める | イテレーションゴール | 本プロジェクト |
| 実装エントロピー | Implementation entropy | タスクの不確実性を表す 5 要素（意図の曖昧さ・構造的不確実性・検証の不確実性・リスク・未解決の仮定）の総称。参照実装のコンポーザーがステージ構成を決めるために推定する | 不確実性コーン | 参照実装 |
| エントロピー評価 | Entropy assessment | 実装エントロピーの 5 軸を Unit ごとに LOW／MED／HIGH で評価し、AI 自律度とゲート密度を決める手法。ストーリーポイント見積もりの代替 | ストーリーポイント | 本プロジェクト |
| AI 自律度 | AI autonomy level | AI がどれだけ人の介入なしに Unit やステップを進められるかの見積もり。エントロピー評価の逆数として扱う | — | 本プロジェクト |
| スコープ | Scope | 参照実装で、どのステージを実行するかを定める構成。enterprise・feature・mvp・poc・bugfix・refactor・infra・security-patch・classic・workshop・express の 11 種 | ワークフロープロファイル | 参照実装 |
| 深さ | Depth | 各ステージの成果物の詳細度。Minimal（要点のみ）・Standard（完全な成果物）・Comprehensive（コンプライアンス相互参照を含む）の 3 段階 | — | 参照実装 |
| テスト戦略 | Test strategy | 生成するテストの量と種類の水準。Minimal（要件ごとに 1）・Standard（コンポーネントごとに 5〜8）・Comprehensive（10〜15、全種類）の 3 段階。深さとは独立 | テスト計画 | 参照実装 |
| コンポーザー | Composer | 参照実装のエージェント。自由記述の Intent から実装エントロピーを推定し、必要最小限のステージ構成を提案する | — | 参照実装 |
| 依存 DAG | Dependency DAG | Unit 間の依存関係を有向非巡回グラフで表したもの。依存を共有しない Unit を並列 Bolt に割り当てる根拠 | 依存関係マップ | 参照実装 |
| 並列バッチ | Parallel batch | 依存を共有せず互いに依存しない Unit の集まり。同時に実行できる | — | 参照実装 |
| ストーリーマップ | Story map | ユースケース × Unit × ストーリーの対応表。トレーサビリティと検証ゲートでの欠落検出に使う | — | 参照実装・本プロジェクト |
| スコープバッファ | Scope buffer | 優先度の低い Unit を 30% 程度用意し、遅延時に削るための余裕。深さ・テスト戦略を 1 段階下げることも含む | フィーチャバッファ | 本プロジェクト |
| 検証バッファ | Verification buffer | 人の検証時間がボトルネックになることを前提に、承認ゲートに立ち会うモブの集中時間を先に確保する余裕 | スケジュールバッファ | 本プロジェクト |
| リードタイム | Lead time | Intent 表明（または Bolt 計画承認）から Deployment Unit 検証済みまでの経過時間。ベロシティに代わる主要指標 | サイクルタイム | 本プロジェクト |
| 手戻り率 | Rework rate | 承認ゲートでの変更依頼数 ÷ 通過数。AI の出力の安定度とガードレールの効果を表す | — | 本プロジェクト |
| 承認ゲート通過数 | Gate approvals | 人が検証して承認したステップの数。人の検証負荷を表す指標 | ベロシティ | 本プロジェクト |

---

## 5. 実装とテスト

| 用語 | 英語 | 定義 | 対応する既存用語 | 出典 |
| :--- | :--- | :--- | :--- | :--- |
| TDD の三原則 | Three Laws of TDD | 失敗するテストを書くまで実装しない、失敗に十分なだけテストを書く、テストを通す以上の実装を書かない。AI-DLC の TDD フレーバーでも変えない規律 | XP の TDD | 本プロジェクト |
| 先回り実装 | Speculative implementation | AI がテストに要求されていない分岐・将来用の引数・汎用化を先に書いてしまう振る舞い。三原則の第 3 法則に反する | YAGNI 違反 | 本プロジェクト |
| 同型テスト | Tautological test | 実装をなぞるだけで振る舞いを検証しないテスト。期待値を実装の出力からコピーした場合に生じる | — | 本プロジェクト |
| 全行理解 | Read every line | AI が書いたコードでも、理解していないコードはマージしないという規律。承認ゲートでの人の責務 | コードレビュー | 本プロジェクト（Qiita 記事の整理に基づく） |
| インターンとして扱う | Treat AI as an intern | AI は優秀だが成果物は必ずチェックする、という AI との向き合い方 | — | 本プロジェクト（Qiita 記事の整理に基づく） |
| ソース束縛レビュー | Source-bound review | コード生成のレビューを、変更したソースファイルの一覧とフィンガープリントに束縛し、レビュー後の未申告の変更を検出する仕組み | — | 参照実装 |
| 停止して確認 | Halt-and-ask | 自律実行中でも、テスト失敗・未確認の仮定・確認必須の操作・計画外のステップが生じたら AI が停止して人に判断を求めること | — | 参照実装 |
| 再試行・スキップ・中止 | Retry / Skip / Abort | 並列 Bolt の 1 つが失敗したときに、失敗した Unit についてのみ人が選ぶ 3 つの選択肢 | — | 参照実装 |
| 契約テスト | Contract test | 並列に開発する Unit 間のインターフェース（API・イベント・スキーマ）を先に固め、それを検証するテスト | 統合テスト | 本プロジェクト |
| レビュアーエージェント | Reviewer agent | 成果物を作らず、生成物を審査して READY／NOT-READY の判定と指摘表を出すエージェント。人の最終判断は奪わない | マルチパースペクティブレビュー | 参照実装 |

---

## 6. 参照実装（aidlc-workflows）の用語

本プロジェクトは参照実装をそのまま導入していませんが、設計判断の根拠として参照するため、主要な用語を定義します。

| 用語 | 英語 | 定義 |
| :--- | :--- | :--- |
| ハーネス | Harness | AI-DLC の中核（core）を実行する CLI エージェント。Claude Code・Kiro CLI・Codex CLI・Cursor・opencode・GitHub Copilot |
| コンダクター | Conductor | `/aidlc` セッション自体。エンジンから次の指示を受け取り、ステージの実行・質問・並列実行を行い、結果を報告する |
| エンジン | Engine | ステージ間のルーティング（スコープ解決・順序・ジャンプ・再開・ゲート状態）を決定的に扱うツール。コンダクターに指示（Directive）を出す |
| フェーズ | Phase | ライフサイクルの 5 区分。Initialization（0）・Ideation（1）・Inception（2）・Construction（3）・Operation（4） |
| ステージ | Stage | 33 の離散的なステップ。各ステージに主担当エージェント・入出力・承認ゲートがある。番号はフェーズ付き（例：2.4） |
| Ideation | Ideation Phase | イニシアチブを検証するフェーズ。Intent 把握・市場調査・実現性・スコープ定義・チーム編成・ラフモックアップ・承認と引き継ぎ。論文の Inception の前半に相当 |
| Initialization | Initialization Phase | ワークスペースの検出と状態ファイルの初期化。承認ゲートなしで自動実行 |
| ワークフロー | Workflow | ライフサイクルの 1 回の端から端までの実行。特定のタスク（機能・欠陥修正など）にスコープされる |
| 状態ファイル | State file | Intent ごとの進捗の唯一の正本。ステージを `[ ]` 未着手・`[-]` 進行中・`[?]` 承認待ち・`[R]` 修正中・`[x]` 完了・`[S]` スキップの 6 状態で管理 |
| 監査ログ | Audit trail | 追記専用のイベントログ。98 種類のイベントを ISO タイムスタンプ付きで記録し、Intent から本番までの完全なトレーサビリティを提供 |
| 対話モード | Interaction mode | ステージで入力を集める 3 つの方式。Guide Me（構造化質問）・Edit File（質問ファイルを直接編集）・Chat（自由対話）。いずれも質問ファイルに収束する |
| 質問ファイル | Questions file | ステージでの決定を記録する正本。対話モードによらず、すべての回答がここに書かれる |
| エージェント | Agent | 14 のペルソナ。11 のドメイン専門家（product・design・delivery・architect・aws-platform・compliance・devsecops・developer・quality・pipeline-deploy・operations）、2 のレビュアー、1 のコンポーザー |
| 小さなモブ、幅広いエージェント | Small mob, broad agents | 数十の狭い専門家ではなく、複数のステージを横断する 11 の幅広いエージェントで構成する設計原則。狭い専門家の連鎖はウォーターフォールの引き継ぎを再現するため |
| 通信トポロジー | Mode / topology | ステージでのエージェントの協働方式。inline（コンダクターがペルソナを演じる）・subagent（ハブ・アンド・スポーク）・pipeline（連鎖）・mob（メッシュ） |
| ルール | Rule | 作業前に適用される恒久的な振る舞いの規則。組織 → チーム → プロジェクト → フェーズ → ステージの 5 層で加算的に解決される |
| センサー | Sensor | 成果物に対して実行される決定的な検査（Lint・型チェック・必須セクション・トレーサビリティなど）。ルールが前向き制御、センサーが後向き検証 |
| 学習ループ | Learning loop | ステージ中の観察を承認ゲートで人が確認し、確定した学びをプロジェクトまたはチームのルールとして書き込む仕組み。本プロジェクトのガードレールに相当 |
| 知識 | Knowledge | エージェントがステージ開始時に読み込む参照資料。方法論の知識（出荷分）とチームの知識（利用者管理）の 2 層 |
| Space | Space | チームごとの作業空間。メモリ・知識・Intent の記録を持つ |
| ワークツリー | Worktree | 自律実行の並列 Bolt で使う git の分離機構。Bolt ごとにブランチを持つ |
| ステージ優先 | Stage-major | Construction の既定の進め方。1 つのステージを全 Unit に対して実行してから次のステージへ進む。Unit 優先（unit-major）はオプトイン |

---

## 7. XP・Scrum との用語対応

| XP・Scrum | AI-DLC | 変わる点 |
| :--- | :--- | :--- |
| スプリント／イテレーション | Bolt | 週単位から時間・日単位へ。AI が計画し、人が承認する |
| エピック | Unit | AI が疎結合・高凝集に分解し、独立して開発・デプロイできることを条件にする |
| ユーザーストーリー | ユーザーストーリー | 変わらない。人と AI の契約という役割が加わる |
| ストーリーポイント | エントロピー評価 | 規模ではなく、人が検証に費やす負荷（AI 自律度の逆数）を測る |
| ベロシティ | 完了 Unit 数・承認ゲート通過数・リードタイム | 生成量ではなく、価値の到達と人の検証負荷を測る |
| 計画ゲーム／バックログリファインメント | Mob Elaboration | AI が初期案を出し、モブがその場で精緻化する |
| ペア／モブプログラミング | Mob Construction | AI が選択肢を提示し、人が技術判断する |
| デイリースタンドアップ | 承認ゲート | 定例の進捗共有ではなく、AI の完了報告に対する検証を都度行う |
| コードレビュー | 承認ゲート＋レビュアーエージェント | AI の指摘を材料に人が判断する。人の最終判断は変わらない |
| TODO リスト | ステップ計画 | AI が書き、人が承認する |
| タスクボード | 状態ファイル | 6 状態のチェックボックスで進捗を表す |
| ふりかえり | Bolt ふりかえり＋ガードレール化 | 学びを記録するだけでなく、AI の振る舞いの規則として反映する |
| ウォーキングスケルトン | ウォーキングスケルトン | 変わらない。AI の出力品質を確かめ、ゲート密度を決める役割が加わる |
| 受け入れ | Deployment Unit の検証 | 機能・セキュリティ・NFR をテスト済みで、独立してデプロイ可能な状態を確認する |

---

## 参照先

| 用語の区分 | 詳しい説明 |
| :--- | :--- |
| 方法論の基本概念、フェーズと儀式 | [AI-DLC 導入ガイド](AI-DLC導入ガイド.md) 第 3〜5 章 |
| 成果物 | [AI-DLC 導入ガイド](AI-DLC導入ガイド.md) 第 4 章、[ユースケース作成ガイド（AI-DLC 版）](ユースケース作成ガイド_AI-DLC版.md) |
| 計画と見積もり | [リリース・イテレーション計画ガイド（AI-DLC 版）](リリース・イテレーション計画ガイド_AI-DLC版.md) |
| 実装とテスト | [コーディングとテストガイド（AI-DLC 版）](コーディングとテストガイド_AI-DLC版.md) |
| 参照実装 | [AI-DLC 導入ガイド](AI-DLC導入ガイド.md) 第 11 章、[awslabs/aidlc-workflows](https://github.com/awslabs/aidlc-workflows) |
| ライフサイクル全体 | [開発ガイド（AI-DLC 版）](開発ガイド_AI-DLC版.md) |