本記事の位置づけ — 本記事は、
awslabs/aidlc-workflowsリポジトリの規範ルールおよび利用ガイドを素材として、筆者が AI を活用して読み解き、まとめた解釈です。AWS が公式に発表した方法論ではなく、一次資料の翻訳・要約でもありません。シリーズ — 本記事は AIで紐解くAI-DLC v2 シリーズの一部です。
参照した版 — Claude Code 実装を対象に、2026 年 8 月 4 日時点のコミット
c73ee984（AIDLC_VERSION 2.5.37、core/）を参照しています。Claude Code 以外の実装（Kiro CLI／Kiro IDE／Codex CLI／opencode）は対象外で、記述が異なる場合があります。OSS 実装は更新が続いているため、最新の状態は公式リポジトリをご確認ください。
概要
フェーズ境界検証は、ワークフローがフェーズを切り替える継ぎ目で、前フェーズの成果物から次フェーズへ鎖が通っているか（トレーサビリティ）を点検する仕組みです。各フェーズは固有の成果物を作りますが、要件のない設計や設計に遡れないコードのように鎖が切れていては意味がありません。こうした「鎖の切れ目」を、フェーズが変わるタイミングで洗い出します。
ただし、これは進行をせき止めるものではありません。境界をまたぐと PHASE_VERIFIED という監査マーカーが無条件に記録される一方、合否そのものはコンダクター（ワークフローを回す進行役）がプロトコル規約に沿って判定し、問題が見つかれば承認ゲートに合流します。本記事では、3つの境界、確かめる鎖、そして監査マーカーと停止機構の関係を読み解きます。
フェーズ境界検証とは
AI-DLC v2 のワークフローは 発想 → 構想 → 構築 → 運用 と進みます。各フェーズは固有の成果物を生み出しますが、それらが互いに孤立していては意味がありません。要件のない設計、設計に遡れないコード、ストーリーに対応しないアーキテクチャ。フェーズ境界検証は、こうした上流から下流への鎖の整合を、フェーズが変わる継ぎ目で確かめます。
検証が走るのは、この境界だけです。境界は3つあり、それぞれ確かめる鎖が違います。
3つの境界
| 境界 | 遷移点 | 確かめる鎖 |
|---|---|---|
| Ideation → Inception | approval-handoff → reverse-engineering（グリーンフィールドでは requirements-analysis） | Intent → Scope → Intent Backlog の一貫性。scope 項目すべてに feasibility の裏付けがあるか |
| Inception → Construction | delivery-planning → functional-design | Requirements → Stories → Architecture の整合。全ストーリーが要件に遡れ、アーキテクチャが全ストーリーをカバーするか |
| Construction → Operation | ci-pipeline → deployment-pipeline | Architecture → Code → Tests の整合。全コードが設計に遡れ、テストが受け入れ基準に対応するか |
Initialization → Ideation には境界検証がありません。ここはワークスペースを用意するブートストラップ段階で、検証すべき上流成果物がまだ存在しないためです。
たどる鎖と、見つかる問題
検証はフェーズをまたぐ1本の鎖をたどります。
Intent → Requirement → Story → Architecture Component → Code Module → Test Suite
この鎖をたどり、各成果物に次の状態を付けます。
- Fully traced — Intent からテストまで鎖が完全に通っている
- Partially traced — 鎖に欠落がある（どこが切れているかを具体的に示す）
- Orphan — 上流のリンクを持たない
検証が拾う問題は、突き詰めると次の3種類です。
- gap（欠落リンク） — 要件はあるのに対応する設計がない、など鎖の途中が切れている
- orphan（孤児成果物） — 設計はあるのに対応する要件がない、上流を持たない成果物
- contradiction（矛盾） — フェーズ間で出力が食い違っている
なお、成果物が互いにどう連結しているか（slug による参照・1つの成果物に生産者は1つ）という鎖の土台は、別記事「成果物の流れ」で扱います。
走るタイミング
| タイミング | 内容 |
|---|---|
| フェーズ最終ステージの承認後 | そのフェーズの全成果物が揃った直後 |
| 次フェーズの初手の前 | 次フェーズが始まる前に鎖を確認する |
| オンデマンド | 人が /aidlc --status で随時要求できる |
| 各ステージ完了時（別機構・軽量） | このステージの出力が前ステージの出力を参照しているかのセルフチェック |
最後の「各ステージ完了時の軽量チェック」はフェーズ境界検証とは別物で、ステージ単位で走る upstream-coverage センサーが担います。ステージ定義のフロントマター（ファイル冒頭のメタ情報）に宣言された consumes:（消費する上流成果物）が、出力の本文で実際に参照されているかを見る助言です。センサーが成果物の保存時に何を見ているかは、別記事「センサー」で扱います。
検証の出力
検証結果は、アクティブな intent の記録ディレクトリ（aidlc/spaces/<space>/intents/<YYMMDD>-<label>/、以下 <record>）の verification/ に残ります。
-
traceability.md— Intent → Requirement → Story → Architecture → Code → Test のマッピング。各成果物の状態（Fully traced / Partially traced / Orphan）を一覧する -
phase-check-[phase].md— フェーズ境界ごとのチェック結果。カバレッジ率（対応ストーリーのある要件の割合、対応コンポーネントのあるストーリーの割合など）、警告（不完全なマッピング）、整合性チェック、そして人の承認チェックボックス
「検証ゲート」との違い
フェーズ境界検証でいちばん誤解されやすいのは、これを進行を止める仕組みだと思い込むことです。実装を読むと、そうではありません。
境界をまたぐと PHASE_VERIFIED という監査イベントが記録されますが、これは事後の監査マーカーです。記録は無条件で、合否で分岐しません。イベントに載るデータ（ペイロード）は境界名の文字列（例: inception → construction）だけで、検証の成否そのものはこのイベントに含まれません。
では合否はどこで判定されるのか。それはコンダクター（LLM）がプロトコル規約に沿って行う知識作業です。stage-protocol-governance.md §13 が境界ごとに何を確かめるかを定め、そこから読み込まれる verification.md が「成果物を読み、鎖を組み立て、gap・orphan・矛盾を洗い出し、レポートを書き、人に提示する」という中身を定義しています。検証が失敗したときは、承認ゲートに合流します。
検証の結果が進行にどう効くかで切り分けると、AI-DLC v2 の機構は次の2つに分かれます。
| 機構 | 進行への効き方 | 実体 |
|---|---|---|
| センサー | 止めない（助言のみ） | 全センサーが advisory。upstream-coverage などステージ単位で走り、欠落を報告するが進行は止めない |
| 承認ゲート | 人が止める | 人が成果物を確認して承認する。フェーズ境界検証の失敗もここに合流する |
これとは別に、中身を判定せず証拠の有無だけを見て完了を拒む前提条件がいくつもあります（成果物の実在、人の操作、協働者の記録、レビューの記録、作業単位の充足）。この前提条件と、LLM 規約に委ねたこの検証の判定が現実にどこまで効くかは、別記事「限界と注意点」で扱います。
フェーズ境界の PHASE_VERIFIED はこのどちらでもなく、境界を越えた事実を記録する監査マーカーです。検証の判定は規約に沿ってコンダクターが担い、失敗時は承認ゲートが受け止めます。承認ゲートの差し戻しや「現状で承認」の仕組みは、別記事「承認ゲート」で扱います。
全体像
図の3つの境界は、どれも同じ分岐をたどります。鎖が通っていれば次フェーズへ進み、gap・orphan・矛盾が見つかれば人に提示して承認ゲートに合流します。PHASE_VERIFIED の記録は、この分岐とは別に、境界を越えるたび無条件に行われます。
参照元
| ファイル | 内容 |
|---|---|
core/aidlc-common/protocols/stage-protocol-governance.md |
§13 フェーズ境界検証の規約。3境界・検証手順・失敗時の合流を定義 |
core/knowledge/aidlc-shared/verification.md |
検証方法論。トレーサビリティ鎖・状態指標・出力ファイルの定義 |
core/tools/aidlc-state.ts |
PHASE_VERIFIED 監査イベントの発行（無条件・境界名のみのペイロード） |
core/tools/aidlc-audit.ts |
PHASE_VERIFIED を含む監査イベント定義 |
core/aidlc-common/protocols/stage-protocol.md |
承認ゲート。検証失敗時の合流先 |
core/sensors/aidlc-upstream-coverage.md |
ステージ単位の助言センサー。consumes: 参照チェック（default_severity: advisory） |
core/tools/aidlc-sensor.ts |
センサー実装。全センサーの結果は advisory で進行を止めない |
関連記事
前の記事: レビュアー
次の記事: ルールとナレッジ
目次: AIで紐解くAI-DLC v2