AI-DLC Workflow V2の承認ゲートとセッション管理: 長いワークフローを安心して進める仕組み
「途中で方向がずれたら？」「セッションが切れたら最初から？」。安心してください、AI-DLC Workflow V2では人間が常にハンドルを握り続けられます。承認ゲートとセッション管理の仕組みを見ていきましょう。シリーズ第16回。
Series: AI-DLC Workflow V2の解説 (31 articles)
- …
- 16AI-DLC Workflow V2の承認ゲートとセッション管理: 長いワークフローを安心して進める仕組み This article
1. はじめに
この記事はAI-DLC Workflow V2（以降V2）シリーズの第16回です。
V2のワークフローは最大33ステージ、5フェーズにまたがります。これだけ長い工程をAIエージェントが自律的に進めると聞くと、「途中で方向がずれたら取り返しがつかないのでは」「セッションが途切れたら進捗が消えるのでは」という不安が浮かぶかもしれません。
ここで重要なのは、V2が「User decides, AI executes」という原則を設計の根幹に置いていることです。AIは実行を担いますが、判断は人間がする。この原則を具体化しているのが、今回取り上げる2つの仕組みです。
- 承認ゲート（Approval Gate）: 各ステージの完了時に人間がレビューし、先に進むか修正するかを決める関所
- セッション管理（Session Management）: ワークフローの状態をディスクに永続化し、セッションをまたいでも作業を継続できる仕組み
では、それぞれの仕組みを具体的に見ていきましょう。
2. 承認ゲートとは
各ステージの出口に立つ関所
承認ゲートとは、ステージの作業が完了した時点でエージェントが人間に判断を仰ぐ仕組みです。初期化フェーズの3ステージを除き、ワークフロー内の各ステージに設置されています。
ゲートでは2つの選択肢が提示されます。
- Approve（承認）: 成果物を受け入れ、次のステージに進む
- Request Changes（修正依頼）: フィードバックを伝え、エージェントに修正させる
言い換えれば、エージェントがどれだけ優れた成果物を生成しても、人間がApproveしない限りワークフローは先に進みません。
なぜゲートが必要なのか
ゲートが存在する理由は3つあります。
1. 方向修正のコストを最小化する
ステージ間の依存関係があるため、上流の成果物に問題があると下流で手戻りが発生します。ゲートを各ステージに置くことで、問題を早い段階で検出し、修正コストを最小に抑えます。
2. 人間の意思決定を記録する
承認・却下の判断は監査ログ（audit trail）に
GATE_APPROVEDやGATE_REJECTEDイベントとして記録されます。「誰が、いつ、何を承認したか」がトレーサビリティとして残ります。3. AIの暴走を防ぐ
ゲートは実際の人間の操作を必要とします。プロンプトの送信やピッカーへの回答が
HUMAN_TURNイベントとして記録され、このイベントが記録されていない限りゲートの承認は受け付けられません。つまり、モデルが自動操縦で承認を偽造することはできない設計になっています。3. 承認ゲートのフロー
基本的な流れ
承認ゲートの動作を図で見てみましょう。
流れはシンプルです。ステージの作業が完了すると、ゲートが開きます。人間がApproveすれば次へ進み、Request Changesを選べばフィードバックを伝えてエージェントが修正し、再びゲートが開きます。
承認後の進捗確認
ワークフローの現在位置は
/aidlc --status で確認できます。1
2
3
4
5
6
7
8
9
10
11
12
13
AI-DLC Workflow Status
==============================
Project: 承認ゲートとセッション管理を解説するブログ記事を執筆する。
Scope: blog-content
Phase: CONSTRUCTION
Current Stage: Code Generation (3.5)
Status: Running
Completion: 4/5 stages (80%)
Phase Progress:
INITIALIZATION ███ 3/3
IDEATION █ 1/1
CONSTRUCTION ▒ 0/1この表示から以下が把握できます。
- プロジェクト全体の完了率（80%）
- フェーズごとの進捗（プログレスバー付き）
- 現在実行中のステージ名とフェーズ
ワークフローの現在地が常に明確なので、「あとどれくらいか」を把握しながら進められます。
3回目以降のエスケープハッチ
同じステージで何度もRequest Changesを繰り返すと、修正ループから抜けられなくなる可能性があります。V2にはこれを防ぐエスケープハッチが用意されています。
| 修正サイクル | ゲートの選択肢 |
|---|---|
| 1回目 | Approve / Request Changes（標準の2択） |
| 2回目 | Approve / Request Changes（2択 + 「次のサイクルでAccept as-isが使えるようになります」という通知） |
| 3回目以降 | Approve / Request Changes / Accept as-is |
Accept as-is（現状のまま受け入れる）を選ぶと、現在の成果物をそのままアーカイブしてワークフローを先に進めます。完璧を追求して先に進めないより、現実的な判断で前進することを可能にする仕組みです。
修正回数はステージごとにカウントされるので、次のステージに移れば回数はリセットされます。
Add Skipped Stage（スキップ済みステージの追加）
Ideation（構想）とInception（詳細化）フェーズでは、ゲートにもう1つの選択肢が現れることがあります。
1
2
3
4
▸ How would you like to proceed?
(1) Approve — Continue to Scope Definition
(2) Request Changes — Provide revision feedback
(3) Add Market Research — Include Market Research which was skippedスコープの設定によりスキップされたステージを、ワークフロー実行中に追加できる機能です。「Market Researchはスキップしたけど、やはり必要だった」と気づいた場合に、その場で計画を修正できます。
この選択肢が表示される条件は以下の通りです。
- 現在のステージがIdeationまたはInceptionフェーズ内にある
- スコープルーティングでスキップされたステージが先に存在する
- そのスキップ済みステージが現在のコンテキストに関連している
4. 修正ループの詳細
Request Changesを選んだあと
承認ゲートでRequest Changesを選ぶと、具体的なフィードバックを伝える機会が生まれます。エージェントはそのフィードバックに基づいて成果物を修正し、再度ゲートを開きます。
では、修正の過程でどの程度の手戻りが起きるのでしょうか。ここが重要なポイントです。
修正時に何が起きるか
Request Changesでフィードバックを提供すると、エージェントは以下の流れで動きます。
- フィードバックの内容を解析する
- 該当する成果物（ステージの出力ファイル）を修正する
- 修正完了後、再度承認ゲートを提示する
この時、ステージの成果物はその場で更新されます。つまり、前回の出力に対するインクリメンタルな修正です。ステージ全体をゼロからやり直すわけではありません。
修正ループの全体フロー
修正ループで保持されるもの
| 保持される | 保持されない |
|---|---|
| 以前のステージの成果物 | フィードバックで指摘された箇所の元の記述 |
| ワークフロー全体の状態 | 修正前バージョンの成果物（上書きされる） |
| 監査ログの全履歴 | — |
| 修正回数のカウント | — |
修正ループはあくまで「現在のステージの成果物を改善する」行為であり、ワークフロー全体の状態や過去の判断には影響しません。
どこまで修正すべきか
「何度もRequest Changesを繰り返すより、Approveして先に進んだほうがいいのか」という判断は実際に悩ましいところです。V2は以下の仕組みでこの判断を支えています。
- 2回目の修正後に通知が出る: 「次のサイクルでAccept as-isが使えるようになります」というメッセージにより、エスケープハッチの存在を認識できる
- Accept as-isは成果物をそのまま保持する: 不完全でも記録として残るため、後のステージで参照可能
- ステージジャンプで後から戻れる: 先に進んだ後で問題に気づいた場合、当該ステージにジャンプして再実行できる（詳しくはセクション8で扱います）
5. セッション管理の全体像
なぜセッション管理が必要か
ここからは、もう1つの制御の柱であるセッション管理について見ていきましょう。
V2のワークフローは、スコープによっては30ステージ近くを実行します。各ステージで人間のレビューと承認が入るため、1つのセッション（1回のCLI起動）で完了することは稀です。セッションが途切れる場面を挙げると、以下のような状況があります。
- 勤務時間が終わった
- コンテキストウィンドウが一杯になった（context compaction）
- PCを再起動した
- 「ここまでにして明日続けよう」と意図的に中断した
こうした場面でワークフローの進捗が失われないために、V2はワークフローの状態をディスクに永続化します。
何がディスクに保存されるか
V2のセッション管理は、以下のファイル群で状態を永続化しています。
| ファイル | 役割 |
|---|---|
aidlc-state.md | ワークフローの現在地、スコープ、各ステージの進捗状態 |
audit/<host>-<clone-id>.md | 監査ログ。判断・イベントの全履歴 |
| 各ステージの成果物（mdファイル群） | エージェントが生成した設計書・要件定義・コード等 |
.aidlc-recovery.md | 整合性チェック用ファイル（Claude Code固有） |
ここで重要なのは、ワークフローの進捗は「セッションのメモリ」ではなく「ディスク上のファイル」に記録されるということです。セッションが切れても、ファイルが残っている限り作業の継続が可能です。
セッション間で何が保持され、何が失われるか
| 保持される（ディスク上） | 失われる（メモリ上） |
|---|---|
| ステージの完了状態と成果物 | セッション中の会話コンテキスト |
| 監査ログの全イベント | 未書き込みの作業中データ |
| スコープ・設定情報 | エージェントのペルソナコンテキスト（再読み込みされる） |
| 整合性チェックファイル（Claude Code） | タスクIDの割り当て（状態ファイルから再構築される） |
会話の文脈は失われますが、判断の記録とその結果である成果物はディスクに残ります。新しいセッションでは状態ファイルを読み込んで「前回どこまで進んだか」を復元し、エージェントのペルソナはエージェント定義ファイルから再ロードされます。
6. 4つの再開オプション
セッション再開の入口
新しいセッションで
/aidlcを実行すると、V2はaidlc-state.mdの存在を確認します。状態ファイルが見つかった場合、ワークフローの現在地を要約した上で、4つの再開オプションを提示します。
各オプションの詳細
それぞれのオプションがどのような場面に適しているか、具体的に見ていきましょう。
Resume（最後のチェックポイントから継続）
多くの場合に使う再開方法です。「昨日の続きをやる」場面で使います。
- 進行中または次に保留されているステージから作業を再開する
- 状態ファイルからタスクの構造が再構築される
- 過去のセッションの会話コンテキストは失われるが、成果物とステージ進捗は完全に保持される
具体例: Inception（詳細化）フェーズのRequirements Analysisまで完了した状態でセッションが切れた。翌日Resumeを選ぶと、次のUser Storiesステージから作業が始まる。
Redo（現在のステージをやり直し）
現在進行中のステージを最初からやり直す場面で使います。
- 現在のステージのチェックボックスがリセットされ、再実行される
- 他のステージの成果物や状態には影響しない
- context compaction（コンテキスト圧縮）の直後で、作業中だったステージの品質に不安がある場合に適している
具体例: Code Generationステージの途中でコンテキスト圧縮が発生した。再開時にリカバリーファイルが警告を出したので、Redoを選んで安全にやり直す。
Jump（指定ステージへジャンプ）
特定のステージに直接移動したい場合に使います。前方（先のステージ）にも後方（過去のステージ）にもジャンプ可能です。
- 前方ジャンプ: 間のステージはスキップ扱い（
[S]）になる - 後方ジャンプ: 対象ステージがリセットされ再実行される。下流のステージの成果物は残るが陳腐化する可能性がある
- スキップされるステージと成果物への影響について警告が表示される
具体例: Architecture Designの成果物に問題があると気づいた。Construction（構築）フェーズの途中だが、Jumpで Architecture Designに戻り、修正した上で再びConstructionに進む。
Start Fresh（新しいインテントを開始）
既存のワークフローとは別に、新しいワークフローを始める場合に使います。
- 既存のワークフローの成果物・状態・監査ログはそのまま残る
- 新しいインテント（作業単位）が既存と並行して作成される
- 既存のワークフローはいつでも再開可能
具体例: 機能開発のワークフローを進めていたが、緊急のバグ修正が入った。Start Freshで
bugfixスコープの新しいワークフローを開始し、修正完了後に元のワークフローをResumeする。4つのオプション比較表
| オプション | ユースケース | 保持される | 変更される |
|---|---|---|---|
| Resume | 通常の作業継続 | 全成果物・状態・監査ログ | メモリ上の会話コンテキスト（再構築） |
| Redo | 品質不安のあるステージのやり直し | 他ステージの成果物と状態 | 現在のステージの完了状態と部分的成果 |
| Jump | 特定ステージへの移動 | 既存の成果物 | ジャンプ先以外のステージが[S]に（前方）、または対象ステージがリセット（後方） |
| Start Fresh | 別の作業を並行して開始 | 既存ワークフローの全データ | なし（新しいインテントが追加される） |
7. Parkとcontext compaction
2種類の「中断」
ワークフローが中断される場面には、大きく分けて2つのパターンがあります。
| 種類 | トリガー | 発生タイミング |
|---|---|---|
| Park（パーク） | 人間が意図的に中断する | 「今日はここまで」「別の作業を先にやる」 |
| Context compaction（コンテキスト圧縮） | ハーネスが自動的に実行する | コンテキストウィンドウが上限に達した時 |
どちらもワークフローを中断しますが、発生の仕方と影響範囲が異なります。それぞれ見ていきましょう。
Park（意図的な中断）
Parkは「ワークフローを一時停止し、後で再開する」ための明示的な操作です。ワークフローの状態に
WORKFLOW_PARKEDイベントが記録されます。Parkの特徴は以下の通りです。
- ステージの進行は止まるが、状態ファイルと成果物はそのまま保持される
- 次のセッションで
/aidlcを実行すると、再開オプションが表示される（--resumeで明示的にアンパークも可能） - Park中にステージが進むことはない。ワークフローは完全に静止する
Parkが適している場面は明確です。「今のワークフローを中断して、別のことをやりたい。でも後で必ず戻ってくる」という状況です。
Context Compaction（コンテキスト圧縮）
Context compactionは、ハーネス（Claude Code等）がコンテキストウィンドウの容量限界に達した時に自動的に行う処理です。これまでの会話履歴を要約し、コンテキストを圧縮して新しいスペースを作ります。
ここで重要なのは、compactionはV2のワークフローエンジンではなくハーネス側の機能だということです。V2はこの事象に対して以下の防御策を持っています。
整合性チェックの仕組み（Claude Codeハーネスの場合）
Claude Codeでは、コンテキスト圧縮が発生する前にフックが
.aidlc-recovery.mdというチェックポイントファイルを書き込みます。このファイルはその時点のステージ名を記録しており、次回の/aidlc実行時にaidlc-state.mdと比較されます。食い違いがあれば「圧縮中に状態が不整合になった可能性がある」と警告が表示されます。Kiro CLIではこの仕組みは動作しませんが、状態ファイル自体はディスク上に安全に保持されるため、Resumeで通常通り復帰できます。
Compaction後のリカバリー手順
コンテキスト圧縮が発生した後の復帰は、以下のステップで行います。
/aidlcを実行する。V2が状態ファイルを読み込み、再開オプションを表示する- 整合性チェックで警告が表示された場合（Claude Code）はRedoを選び、圧縮時に作業中だったステージをやり直す
- 警告が出なければResumeで通常通り継続する
コンテキスト圧縮は長いセッションでは正常に発生する事象です。V2の設計において、完了済みステージの成果物はディスクに書き込まれているため、圧縮で失われることはありません。リスクがあるのは「作業途中でまだファイルに書き込まれていないデータ」のみです。
ParkとCompactionの比較
| 観点 | Park | Context Compaction |
|---|---|---|
| トリガー | 人間の意図的な操作 | ハーネスの自動処理 |
| タイミングの予測 | 可能（自分で決める） | 困難（コンテキスト使用量に依存） |
| 状態ファイルへの影響 | なし（正常に記録される） | なし（ディスク上は安全） |
| 会話コンテキスト | セッション終了時に失われる | 要約に圧縮される |
| 作業中データのリスク | なし（Parkは作業完了後に行うため） | あり（書き込み途中のデータが不完全になりうる） |
| 復帰方法 | Resume | Resume またはRedo（警告時） |
| 監査イベント | WORKFLOW_PARKED / WORKFLOW_UNPARKED | SESSION_COMPACTED |
8. ステージジャンプ
ワークフロー実行中の移動
セッション管理の再開オプションとしてJumpを紹介しましたが、ステージジャンプはそれだけではありません。ワークフロー実行中（ステージの承認ゲートや質問への回答を求められている場面など）でも、CLIコマンドで任意のステージやフェーズに移動できます。
ジャンプしたい時は、チャットにそのまま以下のコマンドを入力してください。
1
2
3
4
/aidlc --stage code-generation # ステージ名で指定
/aidlc --stage 3.5 # ステージ番号で指定
/aidlc --phase construction # フェーズの先頭に移動
/aidlc --phase 3 # フェーズ番号で指定現在のステージの作業を中断し、指定先のステージに移動します。
前方ジャンプ（スキップ）
現在地より先のステージに移動する場合、間にあるステージはスキップ扱い（
[S]マーク）になります。1
2
3
4
5
6
7
8
例: Requirements Analysis（2.3）からCode Generation（3.5）にジャンプ
2.3 requirements-analysis [x] 完了
2.4 user-stories [S] スキップ
2.5 architecture-design [S] スキップ
...
3.4 nfr-design [S] スキップ
3.5 code-generation [-] 実行中 ← ここに移動前方ジャンプ時にエンジンが表示する警告は以下の通りです。
- スキップされるステージの一覧: どのステージが飛ばされるかを明示する
- 成果物の欠落: 下流のステージが上流の成果物を期待している場合、その依存関係が満たされない旨を伝える
- トレーサビリティへの影響: 要件→設計→実装の追跡チェーンに空白が生まれる可能性
ジャンプするかどうかの判断は人間に委ねられます。警告を確認した上で実行を決定します。
後方ジャンプ（やり直し）
過去のステージに戻る場合、対象ステージは未開始状態（
[ ]）にリセットされ、再実行されます。1
2
3
4
5
例: Code Generation（3.5）からArchitecture Design（2.5）にジャンプ
2.5 architecture-design [ ] リセット ← ここに移動
...
3.5 code-generation [x] 完了（成果物は残るが陳腐化の可能性あり）後方ジャンプの特徴を整理します。
- 対象ステージが再実行される
- 対象より下流のステージの成果物はディスク上に残る
- ただし、上流が変わったことで下流の成果物が古くなる（陳腐化する）可能性がある
- 陳腐化した成果物の扱いは、再度そのステージを通過する際に人間が判断する
スコープとの組み合わせ
状態ファイルがまだ存在しない場合（初回実行時）には、
--stageや--phaseと--scopeを組み合わせて使うこともできます。1
/aidlc --stage code-generation --scope bugfixこの場合、
bugfixスコープで新しいワークフローが作成され、直接Code Generationステージから始まります。「バグの原因は分かっている。すぐに修正コードを書きたい」という場面に適しています。ジャンプの判断基準
どの場面でジャンプを使うべきか、典型的なパターンを整理します。
| 状況 | 対応例 |
|---|---|
| 上流の設計に問題を発見した | 後方ジャンプで該当ステージに戻る |
| 明らかに不要なステージがある | 前方ジャンプでスキップする |
| バグ修正で設計工程が不要 | --scope bugfixで最初からスキップされる構成にする |
| Compaction後に不安定なステージがある | Redoで現在ステージをやり直す（ジャンプではなく） |
ジャンプは強力な機能ですが、前方ジャンプでスキップしたステージの成果物が下流で参照されると、整合性の問題が起こりえます。警告を注意深く読み、必要であればスキップではなくステージを通過させる判断も重要です。
9. まとめ
止められる、戻れる、続けられる
この記事では、V2がワークフローの制御権を人間に渡すための2つの仕組みを見てきました。振り返ります。
承認ゲートは「ワークフローの各ステップで人間が判断する」ための仕組みです。
- 各ステージの完了時にApprove / Request Changesの判断を求める
- 修正ループにはエスケープハッチ（Accept as-is）がある
- 人間の操作なしには承認が成立しない設計になっている
セッション管理は「長いワークフローを複数セッションにまたいで安全に進める」ための仕組みです。
- 状態はディスクに永続化される。セッションが切れても進捗は失われない
- 4つの再開オプション（Resume / Redo / Jump / Start Fresh）で柔軟に作業を継続できる
- Context compactionに対しては整合性チェックファイル（Claude Code）やRedoが防御策になる
- ステージジャンプで前方・後方どちらにも移動できる
この2つは独立した仕組みではなく、連携して動作します。承認ゲートがステージ単位の品質を保証し、セッション管理がワークフロー全体の継続性を保証する。両方が揃って初めて、「33ステージのワークフローを安心して進める」ことが可能になります。
「AIが自律的に動く」と「人間が制御する」の両立
V2の設計が興味深いのは、AIエージェントに大きな自律性を与えながらも、人間の制御を手放していない点です。エージェントはステージ内の作業を自律的に実行しますが、ステージ間の遷移は人間の承認なしには進みません。セッションが切れても状態は保存され、人間が戻ってきた時に判断を再開できます。
「User decides, AI executes」は単なるスローガンではなく、承認ゲートとセッション管理という具体的な仕組みとして実装されているのです。
Series: AI-DLC Workflow V2の解説 (31 articles)
- …
- 16AI-DLC Workflow V2の承認ゲートとセッション管理: 長いワークフローを安心して進める仕組み This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article