AI-DLC 用語集
本プロジェクトで使う AI-DLC の用語を定義します。出典は AWS の Method Definition Paper（論文）、参照実装 awslabs/aidlc-workflows（参照実装）、および本プロジェクトの AI-DLC 版ガイド（本プロジェクト）のいずれかです。本プロジェクトが独自に導入した用語には、その旨を明記しています。
用語の背景は AI-DLC 導入ガイド を、活動ごとの使い方は 開発ガイド（AI-DLC 版） を参照してください。
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 をテスト済みで、独立してデプロイ可能な状態を確認する |
参照先