@k2works/claude-code-booster 5.0.0 → 6.0.0

package/lib/assets/docs/reference/AI-DLC/347/224/250/350/252/236/351/233/206.md

@@ -0,0 +1,207 @@
+---
+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) |

package/lib/assets/docs/reference/index.md

@@ -9,7 +9,11 @@
 - [よいソフトウェアとは](./よいソフトウェアとは.md)
 - [ロジカルシンキング](./ロジカルシンキング.md)
 - [開発ガイド](./開発ガイド.md)
+- [開発ガイド（AI-DLC 版）](./開発ガイド_AI-DLC版.md) - 開発ライフサイクルを Inception・Construction・Operation で読み替え、各活動の AI と人の分担と AI-DLC 版ガイドへの入口を示す
 - [エクストリームプログラミング](./エクストリームプログラミング.md)
+- [AI-DLC 導入ガイド](./AI-DLC導入ガイド.md) - AWS が提唱する AI-DLC の 10 原則・成果物・フェーズ・参照実装（aidlc-workflows）と、XP ベースの開発ライフサイクル・Skills 体系への組み込み方
+- [AI-DLC 用語集](./AI-DLC用語集.md) - AI-DLC の用語を基本概念・成果物・フェーズと儀式・計画・実装・参照実装の区分で定義し、XP・Scrum との対応を示す
+- [ドキュメント構成ガイド](./ドキュメント構成ガイド.md) - 単一企業・統合戦略・複数プロジェクトのコンセプトに基づく docs/ と apps/ の構成規約
 
 ### 経営・ビジネス
 
@@ -22,6 +26,7 @@
 - [ビジネスアーキテクチャ分析ガイド](./ビジネスアーキテクチャ分析ガイド.md)
 - [要件定義ガイド](./要件定義ガイド.md)
 - [ユースケース作成ガイド](./ユースケース作成ガイド.md)
+- [ユースケース作成ガイド（AI-DLC 版）](./ユースケース作成ガイド_AI-DLC版.md) - Mob Elaboration で AI が初稿を書き人が検証する手順、人と AI の契約としての記述基準、AI 生成物の検証観点
 - [アーキテクチャ設計ガイド](./アーキテクチャ設計ガイド.md)
 - [データモデル設計ガイド](./データモデル設計ガイド.md)
 - [ドメインモデル設計ガイド](./ドメインモデル設計ガイド.md)
@@ -34,11 +39,13 @@
 - [非機能要件定義ガイド](./非機能要件定義ガイド.md)
 - [運用要件定義ガイド](./運用要件定義ガイド.md)
 - [コーディングとテストガイド](./コーディングとテストガイド.md)
+- [コーディングとテストガイド（AI-DLC 版）](./コーディングとテストガイド_AI-DLC版.md) - AI が Red-Green-Refactor を回し人が承認ゲートで全行検証する Bolt 実装フロー、AI 生成コード・テストのレビュー観点、ガードレール
 
 ### 開発・運用
 
 - [リリースガイド](./リリースガイド.md)
 - [リリース・イテレーション計画ガイド](./リリース・イテレーション計画ガイド.md)
+- [リリース・イテレーション計画ガイド（AI-DLC 版）](./リリース・イテレーション計画ガイド_AI-DLC版.md) - Intent → Unit → Bolt の計画、承認ゲート駆動の検証、エントロピー評価による見積もりと進捗指標
 - [環境変数管理ガイド](./環境変数管理ガイド.md)
 - [言語別開発ガイド](./言語別開発ガイド.md)
 - [Java アプリケーション環境構築ガイド](./Javaアプリケーション環境構築ガイド.md)