AI-DLC Workflow V2のCLIコマンドガイド: やりたいことから逆引きする
`/aidlc` で始まる。ここまでは分かった。でもフラグ、ランナーコマンド、ユーティリティツール、セッションスキルと広がっていくと、どれをいつ使うのか見失いがちです。この記事で全部整理しましょう。AI-DLC Workflow V2（以降V2）の全コマンドを、ユースケース別に逆引きできる形にまとめます。シリーズ第18回。
Series: AI-DLC Workflow V2の解説 (31 articles)
- …
- 18AI-DLC Workflow V2のCLIコマンドガイド: やりたいことから逆引きする This article
1. ハーネス別の呼び出しプレフィックス
まず前提を揃えましょう。V2のコマンドは、どのハーネス（実行環境）でも同じ機能を持ちますが、呼び出しのプレフィックスだけが異なります。
| ハーネス | プレフィックス | ツールパス |
|---|---|---|
| Claude Code | /aidlc | .claude/tools/ |
| Kiro IDE | /aidlc | .kiro/tools/ |
| Kiro CLI | /aidlc | .kiro/tools/ |
| opencode | /aidlc | .aidlc/tools/ |
| GitHub Copilot | /aidlc | .aidlc/tools/ |
| Codex CLI | $aidlc | .codex/tools/ |
2. Quick Reference表
では、全コマンドの全体像を眺めてみましょう。細かい使い方はセクション3以降で扱うので、ここではまず「何があるのか」を把握するための一覧です。
/aidlc フラグ群
| コマンド | 説明 |
|---|---|
/aidlc [scope] | 明示スコープで新規ワークフロー開始 |
/aidlc [description] | 記述からスコープを自動検出して開始 |
/aidlc compose "<task>" | Adaptive Composerでカスタムスコープを提案 |
/aidlc compose --report <path> | スキャンレポートからComposeを実行 |
/aidlc --new-scope "<task>" | 既存スコープにマッチしても強制的にカスタムスコープを作成 |
/aidlc | 既存ワークフローの再開（またはインテント新規作成） |
/aidlc intent [name] | インテント一覧表示、または切り替え |
/aidlc space [name] | スペース一覧表示、または切り替え |
/aidlc space-create <name> | 新しいスペースを作成 |
/aidlc --status | 読み取り専用のステータス表示 |
/aidlc --doctor | セットアップのヘルスチェック |
/aidlc --doctor --export | 診断レポートを書き出し |
/aidlc --stage <slug|#> | 指定ステージへジャンプ |
/aidlc --stage <slug> --single | 1ステージだけ単独実行（ワークフロー非進行） |
/aidlc --phase <name|#> | 指定フェーズの先頭へジャンプ |
/aidlc --scope <name> | スコープを変更 |
/aidlc --depth <level> | 深度レベルを変更 |
/aidlc --test-strategy <level> | テスト戦略を変更 |
/aidlc --review <class> | レビュー上限を設定 |
/aidlc config get/set/list | ワークフロー設定の取得・変更・一覧 |
/aidlc plugin select/list/sync | プラグイン管理 |
/aidlc --version | バージョン表示 |
/aidlc --help | ヘルプ表示 |
ランナーコマンド
| コマンド | 等価操作 |
|---|---|
/aidlc-bugfix | /aidlc --scope bugfix |
/aidlc-feature | /aidlc --scope feature |
/aidlc-mvp | /aidlc --scope mvp |
/aidlc-security-patch | /aidlc --scope security-patch |
/aidlc-<stage-slug> （29種） | /aidlc --stage <slug> --single |
/aidlc-init | フレッシュなワークスペースでの /aidlc |
/aidlc-compose | /aidlc compose のタイプ可能なショートカット |
セッションスキル
| コマンド | 説明 |
|---|---|
/aidlc-session-cost | セッションのコストビュー |
/aidlc-replay | セッションのナラティブ生成 |
/aidlc-outcomes-pack | チームへの引き継ぎドキュメント生成 |
一覧を見て「多いな」と感じたかもしれません。でも安心してください。日常的に使うのはこの中のごく一部です。次のセクションで「やりたいこと」から引ける形に整理します。
3. 用途別ガイド（逆引き）
ここからが本題です。「やりたいこと」から引ける形で整理していきましょう。
ワークフローを始めたい
新しいワークフローを始める方法は複数ありますが、どれもスコープ（どのステージを実行するか）を決めるところから始まります。
| やりたいこと | コマンド |
|---|---|
| スコープを指定して始めたい | /aidlc bugfix /aidlc feature /aidlc enterprise など |
| タスクを説明して始めたい（スコープ自動検出） | /aidlc Fix the null pointer in ProfileSerializer |
| 既存スコープに当てはまらないタスクを始めたい | /aidlc compose "harden the deployment pipeline and add observability" |
| スキャンレポートから修正フローを組み立てたい | /aidlc compose --report sonar.json |
| スコープが自動検出でマッチしても、カスタムスコープを強制的に作成させたい | /aidlc --new-scope "harden the deployment pipeline and add observability" |
覚えているでしょうか。スコープは9種類あります。
enterprise, feature, mvp, poc, bugfix, refactor, infra, security-patch, workshop です（第4回 で解説）。ワークフローを管理したい
ワークフローが動き出した後の操作です。進捗確認、再開、切り替えなど、セッションをまたいで作業する場面で使います。
| やりたいこと | コマンド |
|---|---|
| 中断したワークフローを再開したい | /aidlc （引数なし） |
| 進捗を確認したい（状態変更なし） | /aidlc --status |
| 別のインテントに切り替えたい | /aidlc intent <name> |
| インテント一覧を見たい | /aidlc intent |
| 別のスペースに切り替えたい | /aidlc space <name> |
| 新しいスペースを作成したい | /aidlc space-create <name> |
| ワークフロー設定を確認したい | /aidlc config list |
| 設定値を変更したい | /aidlc config set depth minimal |
スコープ・深度・テスト戦略を変更したい
ワークフロー実行中でも、3つの制御軸はいつでも変更できます。ここで重要なのは、
--depth と --test-strategy は独立した軸であることです（第14回 で詳解）。「成果物は詳細に作るが、テストは軽量に」という組み合わせ（--depth standard --test-strategy minimal）も可能です。| やりたいこと | コマンド |
|---|---|
| スコープを変更 | /aidlc --scope bugfix |
| 深度を変更（minimal / standard / comprehensive） | /aidlc --depth minimal |
| テスト戦略を変更 | /aidlc --test-strategy comprehensive |
| レビュー上限を変更（adversarial / advisory / none） | /aidlc --review advisory |
| 複数フラグを同時に指定 | /aidlc --scope bugfix --depth comprehensive |
ステージやフェーズにジャンプしたい
「途中のステージだけ試したい」「あのフェーズからやり直したい」という場面です。slug（ステージの短縮識別名）または番号で指定できます。
| やりたいこと | コマンド |
|---|---|
| 特定ステージへジャンプ | /aidlc --stage code-generation |
| ステージ番号でジャンプ | /aidlc --stage 3.5 |
| フェーズの先頭へジャンプ | /aidlc --phase construction |
| フェーズ番号でジャンプ | /aidlc --phase 3 |
| 1ステージだけ単独で試したい | /aidlc --stage requirements-analysis --single |
--single を付けると、メインのワークフローを進めずにそのステージだけを実行します。エンジン側で隔離が強制されるため、安全に試行できます。Adaptive Composerを使いたい
静的スコープにフィットしない場面で、カスタムステージ構成を動的に提案させるコマンドです（第5回 で詳解）。
| やりたいこと | コマンド |
|---|---|
| タスクからカスタム構成を提案させたい | /aidlc compose "タスクの説明" |
| レポートファイルから構成を提案させたい | /aidlc compose --report <path> |
| 実行中にステージ構成を変えたい | /aidlc compose（ワークフロー実行中） |
| ショートカットで呼び出したい | /aidlc-compose |
セットアップを確認したい
初回セットアップ時や、何かがうまく動かない時の診断に使います。
| やりたいこと | コマンド |
|---|---|
| ヘルスチェックを実行 | /aidlc --doctor |
| 診断レポートをファイルに書き出し | /aidlc --doctor --export |
| 出力先を指定して書き出し | /aidlc --doctor --export --output <dir> |
| バージョン確認 | /aidlc --version |
ワークフローを振り返りたい
ワークフロー完了後（または進行中でも）、セッションの経緯やコストを確認できます。これら3つのセッションスキルは読み取り専用です。ステージを進めたり監査イベントを発行したりすることはありません。
| やりたいこと | コマンド |
|---|---|
| セッションのコスト・統計を確認 | /aidlc-session-cost |
| セッションの経緯をナラティブで確認 | /aidlc-replay |
| チームへの引き継ぎドキュメントを生成 | /aidlc-outcomes-pack |
4. コマンド詳細 — /aidlc フラグ群
逆引き表で「何を使えばいいか」は分かりました。ここからは各コマンドが具体的にどう動くのかを見ていきます。
ワークフロー開始
/aidlc [scope] — 明示スコープで開始
スコープキーワードを直接指定して新規ワークフローを開始します。エンジンがスコープを認識し、何を作りたい（あるいは修正したい）かを尋ねてから、Initializationフェーズを実行してワークフローが始まります。
1
2
3
/aidlc bugfix
> What would you like to fix?
> The login API returns 500 when email contains a plus sign/aidlc [description] — 自動検出で開始
タスクを自然言語で記述すると、エンジンがキーワードから適切なスコープを自動検出します。明確なマッチがあれば、スコープ名とステージ数・ゲート数が提示され、確認を求められます。
1
2
3
4
5
/aidlc Fix the null pointer in ProfileSerializer
> Starting a "bugfix" workflow for: "Fix the null pointer in ProfileSerializer"
> - 7 of 33 stages, 4 approval gates, 1 stage repeats per unit of work
> in Construction. Confirm to proceed, name a different scope, or say
> "compose" for a tailored plan.どのスコープにもマッチしない場合や、記述が複合的な場合はAdaptive Composerの利用を提案します。
/aidlc compose "<task>" — Adaptive Composerを起動
静的スコープに当てはまらないタスクで、カスタムステージ構成を動的に提案させます。
1
/aidlc compose "harden the deployment pipeline and add observability"Composerがタスクを分析し、EXECUTE/SKIPグリッドを提案します。承認ゲートで人間が確認してからワークフローが始まります。承認されたカスタムスコープは永続化され、以降
--scope <name> で再利用可能です。/aidlc compose --report <path> — スキャンレポートからCompose
静的解析ツールの出力をそのまま入力として、修正フローを構成できます。
1
/aidlc compose --report sonar.json/aidlc --new-scope "<task>" — カスタムスコープの強制合成
キーワードが既存スコープにマッチする場合でも、Composerにカスタムスコープを強制的に合成させます。
1
/aidlc --new-scope "harden the deployment pipeline and add observability"ワークフロー再開・管理
/aidlc — 既存ワークフローの再開
引数なしで実行すると、
aidlc-state.md を読み込み、4つの再開オプションを提示します。- チェックポイントから再開
- 現在のステージをやり直し
- ステージへジャンプ
- 最初からやり直し
ワークフローが存在しない場合は、新規作成としてスコープの確認に入ります。
/aidlc intent [name] — インテントの一覧・切り替え
引数なしで現在のスペース内のインテント一覧を表示します。
--json でJSON出力も可能です。名前を指定するとそのインテントに切り替えます。インテントの新規作成やワークフロー進行は行いません。SpaceとIntentの詳細は 第17回 で解説しています。/aidlc space [name] — スペースの一覧・切り替え
引数なしでスペース一覧を表示します。名前を指定するとそのスペースに切り替えます。
/aidlc space-create <name> — 新しいスペースの作成
フレームワークのベースラインから新しいチームスペースを作成します。
memory/, knowledge/, codekb/, intents/ の構造が生成されます。作成後に自動で切り替わることはありません。ステータスと診断
/aidlc --status — 読み取り専用ステータス
現在のワークフロー進捗を表示します。フェーズ、ステージ、完了数、スコープ、深度が確認できます。状態の変更は行いません。
/aidlc --doctor — ヘルスチェック
前提条件、設定、ステージグラフの整合性を検証します。読み取り専用で、インテントが存在しない状態でも安全に実行できます。
検証項目には以下が含まれます。
bunのインストール確認- フックファイルの存在確認
settings.jsonの存在確認- ワークスペースシェルの完備確認
- 環境変数
AWS_AIDLC_DEFAULT_SCOPEの妥当性確認 - ステージグラフのサイクル検出
- スキーマバリデーション
- キーワード重複検出
全項目パスなら終了コード0、1つでも失敗があれば終了コード1を返します。
/aidlc --doctor --export — 診断レポートの書き出し
--export を追加すると、ヘルスチェック結果を編集済みの診断レポートファイルとして書き出します。1
2
/aidlc --doctor --export
/aidlc --doctor --export --output <dir>デフォルトの出力先は
aidlc/diagnostics/ です。レポートにはワークスペースのソースコード、環境変数、シークレット情報は含まれません。ホームディレクトリは ~、プロジェクトルートは <project> に置換されます。ナビゲーション
では、ワークフロー内を移動するコマンドを見ていきましょう。
/aidlc --stage <slug|#> — ステージへジャンプ
slugまたは番号でステージを指定してジャンプします。
1
2
3
/aidlc --stage code-generation
/aidlc --stage 3.5
/aidlc --stage requirements-analysis--scope と組み合わせることもできます。1
/aidlc --stage code-generation --scope bugfix/aidlc --stage <slug> --single — 1ステージを単独実行
メインワークフローの
Current Stage を進めずに、指定ステージだけを実行します。エンジンが隔離を強制するため、メインワークフローに影響を与えることはありません。1
2
/aidlc --stage requirements-analysis --single
/aidlc --stage reverse-engineering --singleこの単独実行には、ステージに設定されたエージェントとレビュアーが適用されますが、ワークフロー学習や承認ゲートは実施されません。
/aidlc --phase <name|#> — フェーズへジャンプ
指定フェーズの先頭ステージにジャンプします。
1
2
/aidlc --phase construction
/aidlc --phase 3スコープ・深度・テスト戦略・レビュー
次に、ワークフローの「形」と「密度」を制御するフラグを見ていきます。
/aidlc --scope <name> — スコープ変更
実行中ワークフローのスコープを変更します。EXECUTE/SKIPの再計算が行われ、
SCOPE_CHANGED 監査イベントが記録されます。1
2
/aidlc --scope bugfix
/aidlc --scope enterprise--depth, --test-strategy, --review と組み合わせて同時に変更することも可能です。ワークフローが存在しない場合は、そのスコープで新規ワークフローを開始する動作になります。
ここで注意が必要なのは、自律実行中のConstruction（
Construction Autonomy Mode: autonomous）では拒否される点です。プラン変更にはゲートでの人間の確認が必要なため、先にゲートモードに切り替えるか、Swarmの完了を待つ必要があります。/aidlc --depth <level> — 深度レベル変更
1
2
3
/aidlc --depth minimal
/aidlc --depth standard
/aidlc --depth comprehensiveDEPTH_CHANGED 監査イベントが記録されます。他のフラグと組み合わせ可能です。1
2
/aidlc --scope bugfix --depth comprehensive
/aidlc --stage code-generation --depth minimal/aidlc --test-strategy <level> — テスト戦略変更
深度とは独立した軸で、テストのボリュームを制御します。
1
2
3
/aidlc --test-strategy minimal
/aidlc --test-strategy standard
/aidlc --test-strategy comprehensiveテスト戦略のモデルは以下の通りです。
- Minimal（Nyquist）: 要件あたり1テスト、ユニットテストのみ（合計約5〜15本）
- Standard: コンポーネントあたり5〜8テスト、ユニット＋統合テスト
- Comprehensive: コンポーネントあたり10〜15テスト、全テスト種別
/aidlc --review <class> — レビュー上限の設定
ステージレビューの上限を設定します。
1
2
3
/aidlc --review adversarial
/aidlc --review advisory
/aidlc --review none実効レビュークラスは「ステージ宣言」「スコープの
review_cap」「このオーバーライド」のうち低い方が適用されます。--review advisory はadversarialループをシングルパスに、--review none はレビュー自体をスキップします。ワークフロー設定
/aidlc config get/set/list
設定値の取得・変更・一覧表示をまとめて提供するサブコマンドです。
1
2
3
4
5
6
/aidlc config get depth
/aidlc config set depth minimal
/aidlc config set test-strategy comprehensive
/aidlc config set review advisory
/aidlc config list
/aidlc config list --jsonプラグイン管理
プラグインとは、ステージやエージェントをワークフローに追加する拡張機構です。デフォルトでは何もインストールされていませんが、追加すると以下のコマンドで管理できます。
/aidlc plugin select/list/sync
プラグインの有効化・無効化を管理します。
1
2
3
4
/aidlc plugin list
/aidlc plugin select test-pro
/aidlc plugin select aidlc,test-pro
/aidlc plugin syncplugin list はインストール済みプラグインと有効/無効状態を表示します。plugin select はカンマ区切りでプラグイン選択を設定します。plugin sync はインストール済みプラグインのcomposeフックを実行します。その他
/aidlc --version
フレームワークのバージョンを表示します。読み取り専用で、ワークフローなしでも動作します。
/aidlc --help
利用可能なコマンドとフラグのサマリーを表示します。
5. ランナーコマンド
ランナーコマンドとは、
/aidlc にフラグを付けた操作を1コマンドにまとめたショートカットです。たとえば /aidlc-bugfix は /aidlc --scope bugfix と同じ動作をします。独自の機能は持たず、タイピングの省力化と / メニューでの可視性が目的です（Skills and Runner Commands ）。ランナーをすべて削除しても、/aidlc フラグで同じことができます。スコープランナー（4種）
スコープを固定してワークフローを駆動します。スコープ検出をスキップして、すぐに始めたい時に便利です。
1
2
3
4
/aidlc-bugfix == /aidlc --scope bugfix
/aidlc-feature == /aidlc --scope feature
/aidlc-mvp == /aidlc --scope mvp
/aidlc-security-patch == /aidlc --scope security-patchランナーにも説明やフラグをそのまま渡せます。
1
2
/aidlc-bugfix The profile API returns 500 when display_name is null
/aidlc-feature --statusスコープランナーがあるのは、スコープファイルで
runner: true が設定されている4つのみです。残りの5スコープ（enterprise, poc, infra, refactor, workshop）は /aidlc --scope <name> から使えます。ステージランナー（29種）
1ステージを単独実行するランナーです。メインワークフローの
Current Stage を進めることはありません。1
2
3
/aidlc-code-generation == /aidlc --stage code-generation --single
/aidlc-requirements-analysis == /aidlc --stage requirements-analysis --single
/aidlc-reverse-engineering == /aidlc --stage reverse-engineering --singleライフサイクルの全ランナブルステージに対して1つずつ存在します。Initializationの3ステージにはステージランナーがありません（半端なインテント作成に意味がないため）。代わりに、Initializationフェーズ全体を1コマンドにまとめた
/aidlc-init があります。1
/aidlc-init [--scope <name>] [description]/aidlc-compose — Composeのショートカット
1
/aidlc-compose "harden the deployment pipeline and add observability"/aidlc compose と同じ動作です。タイプ可能なショートカットとして提供されています。6. コマンド詳細 — セッションスキル
セッションスキルはワークフローの振り返りに使う読み取り専用のコマンドです。ステージを進行させたり、監査イベントを発行したりすることはありません。データソースは
aidlc-runtime summary --json の出力です（Skills and Runner Commands ）。では3つそれぞれの役割を見ていきましょう。
/aidlc-session-cost — コストビュー
セッションの所要時間、ステージ結果、メモリエントリ数、センサー実行結果、学習数を表示します。ターミナル出力のみで、ファイル生成は行いません。
/aidlc-replay — セッションナラティブ
非同期レビュー向けに、セッションの経緯を読みやすいナラティブ形式で表示します。「今日のセッションで何が起きたか」をチームメンバーに共有したい場面で使います。ターミナル出力のみです。
/aidlc-outcomes-pack — 引き継ぎドキュメント
チームへの引き継ぎ用ドキュメントとして
OUTCOMES.md を生成します。3つのセッションスキルの中で、これだけがファイルを書き出します。7. 環境変数
AWS_AIDLC_DEFAULT_SCOPE
1
2
3
4
5
{
"env": {
"AWS_AIDLC_DEFAULT_SCOPE": "workshop"
}
}有効な値は9つの組み込みスコープ名です。
enterprise, feature, mvp, poc, bugfix, refactor, infra, security-patch, workshop。では優先順位を確認しましょう。スコープの決定は以下の順序で行われます。
- CLIフラグによる明示指定（
--scope bugfix） - 記述テキストからのキーワード検出
AWS_AIDLC_DEFAULT_SCOPE環境変数- ハードコードされたフォールバック
言い換えれば、明示フラグが最優先で、環境変数はフラグもキーワードマッチも存在しない場合のデフォルトとして機能します。
この環境変数はワークフロー初期化時にのみ読み込まれます。一度
aidlc-state.md が作成されると、以降はステートファイルが権威ソースになります。AIDLC_DISABLE_USAGE_TRACKING
1 に設定すると、トークン使用量のトラッキングを無効化します（Claude Codeのみ）。ステータスラインの ↑<in> ↓<out> $<usd> 表示が消え、完了イベントにコストロールアップが付かなくなります（Troubleshooting ）。AIDLC_DISABLE_REVIEWER_SCOPE_HOOK
1 に設定すると、レビュアーのファイル読み取りスコープ制約を無効化します。プロジェクト内に construction/ ディレクトリがAI-DLCのユニットとは無関係に存在し、正当なレビュアーの読み取りがブロックされる場合に使います（Troubleshooting ）。AIDLC_HOOK_DEBUG
1 に設定すると、フックの実行時にデバッグ出力を有効化します（Kiro IDE harness guide ）。8. コマンド詳細 — ユーティリティコマンド
ここまでは
/aidlc で始まるフラグ群を見てきました。次に、直接呼び出すユーティリティツールを見ていきましょう。これらはフック（自動実行される処理）やステージプロトコルが内部で使用するものですが、デバッグや手動操作のハンドルとしても利用できます。呼び出し形式は
bun <harness-dir>/tools/<tool>.ts <subcommand> です。1
2
3
4
5
6
7
8
9
10
11
# Claude Codeの場合
bun .claude/tools/aidlc-utility.ts <subcommand>
# Kiro IDE / Kiro CLIの場合
bun .kiro/tools/aidlc-utility.ts <subcommand>
# Codex CLIの場合
bun .codex/tools/aidlc-utility.ts <subcommand>
# opencode / GitHub Copilotの場合
bun .aidlc/tools/aidlc-utility.ts <subcommand>aidlc-utility codekb-path — コードナレッジベースのパス解決
リバースエンジニアリングステージが生成するコードナレッジベースのディレクトリパスを返します。読み取り専用で、ディレクトリの作成や監査イベントの発行は行いません。
1
bun .claude/tools/aidlc-utility.ts codekb-path --repo <repo>--json を付けると {space, repo, dir} の構造で出力されます。aidlc-utility codekb-scope-diff — コードナレッジベースの鮮度確認
リバースエンジニアリングの再実行前に、既存のコードナレッジベースが最新かどうかを判定します。「前回のスキャン結果はまだ使えるのか」を確認する場面で使います。
1
bun .claude/tools/aidlc-utility.ts codekb-scope-diff --repo <repo>判定結果は以下のいずれかです。
| 判定 | 意味 |
|---|---|
NO_STORE | 初回スキャン（ストアが存在しない） |
CURRENT | 分析済みパスに変更なし（再利用可能） |
STALE | 分析済みパスに変更あり |
UNVERIFIED | フィンガープリント計算不可（gitワークツリー外など） |
UNKNOWN_SCOPE | スコープ追跡以前のストア |
--compare <timestamp.md> で新旧カバレッジの比較、--mint --paths <a,b,...> でフィンガープリントの生成も可能です。aidlc-utility detect — 読み取り専用のワークスペーススキャン
ワークスペースの検出結果（プロジェクトタイプ、言語、フレームワーク、ビルドシステム）を出力します。Adaptive Composerが内部で利用しているスキャンと同じものです。
1
bun .claude/tools/aidlc-utility.ts detect --jsonaidlc-utility select-plugins — プラグイン選択
/aidlc plugin select の直接ユーティリティ形式です。1
2
bun .claude/tools/aidlc-utility.ts select-plugins test-pro
bun .claude/tools/aidlc-utility.ts select-plugins aidlc,test-pro引数なしで現在の選択状態を表示します。カンマ区切りで名前を渡すと設定を変更し、グラフの再コンパイルとランナーの再生成まで一括で行います。
aidlc-utility recompose — 実行中のプラン変更
実行中のワークフローで、まだ未実行のステージのEXECUTE/SKIP状態を変更します。通常は
/aidlc compose（ワークフロー実行中）経由で到達するものであり、直接タイプする場面は限定的です。1
bun .claude/tools/aidlc-utility.ts recompose --skip <slugs> --add <slugs>slugはカンマ区切りです。監査ロック下で実行され、
RECOMPOSED イベントが記録されます。aidlc-workspace-sync — リポジトリセットの同期
ワークスペースルートにオプションの
repos.json マニフェストがある場合、宣言されたリポジトリセットとディスク上の状態を照合します。1
2
bun .claude/tools/aidlc-workspace-sync.ts
bun .claude/tools/aidlc-workspace-sync.ts --force宣言済みだがディスク上にないリポジトリをクローンし、
.gitignore のマネージドブロックと aidlc.code-workspace ファイルを更新します。--force を付けると、repos.json に存在しないオーファン（孤立した）チェックアウトの処理も行います。aidlc-graph ars — ARSスコアの算出
Adaptive Composerが内部で使用するAutonomy Risk Scoreの算術計算を直接実行できます。5つのスコアを渡すと、重み付け合成スコア、バンドラベル、ステージごとの期待値スクリーン、近接する既存スコープを含む結果がJSON形式で返ります。
1
bun .claude/tools/aidlc-graph.ts ars --iae 0.55 --csu 0.75 --ve 0.65 --r 0.50 --ua 0.55定数は
tools/data/ars-priors.json から読み込まれるため、同じスコアからは常に同じ結果が得られます。aidlc-graph validate-grid — グリッドの依存関係チェック
任意のEXECUTE/SKIPグリッドJSONに対して依存関係の妥当性を検証します。
1
2
bun .claude/tools/aidlc-graph.ts validate-grid --proposal <path>
bun .claude/tools/aidlc-graph.ts validate-grid --proposal <path> --strict--strict は recompose と同じ厳格モードです。--keywords でキーワード衝突チェックも行えます。aidlc-sensor list/describe/fire — センサーの管理と手動実行
センサー（Sensor）とは、ステージ出力に対して自動実行される決定論的チェックのことです（第16回 で詳解）。通常はPostToolUseフックが自動で起動しますが、このツールで手動実行やマニフェストの確認もできます。
1
2
3
4
5
bun .claude/tools/aidlc-sensor.ts list
bun .claude/tools/aidlc-sensor.ts describe required-sections
bun .claude/tools/aidlc-sensor.ts fire required-sections \
--stage requirements-analysis \
--output-path <artifact-path>| サブコマンド | 動作 |
|---|---|
list | フレームワークのセンサーをID・種別・説明とともに表示 |
describe <id> | 1つのセンサーのマニフェスト詳細を表示 |
fire <id> --stage <slug> --output-path <path> | 指定ファイルに対してセンサーを手動実行 |
手動実行でも
SENSOR_FIRED 監査イベントが記録されます。センサーはアドバイザリー（助言的）であり、失敗してもコマンド自体はエラーになりません。フレームワークには claim-sources, required-sections, upstream-coverage, linter, type-check の5つが同梱されています。aidlc-learnings surface/persist — 学習ゲートツール
ステージ承認後に
memory.md（ステージ実行中の記録）から学習候補を抽出し、確認済みのものを永続化するツールです（第6回 で解説したLearning Loopの実装部分）。通常はオーケストレーターが自動で駆動するため、直接呼び出す場面はありません。| サブコマンド | 動作 |
|---|---|
surface --slug <stage-slug> | 承認済みステージの memory.md から候補を抽出（読み取り専用） |
persist --slug <stage-slug> --selections-json <path> | 確認済み学習を project.md / team.md に書き込み |
確認された学習は次のワークフローから適用されます。
aidlc-runtime compile/read/summary — ランタイムグラフの操作
ランタイムグラフ（
runtime-graph.json）は、ワークフローで実際に何が起きたかを記録するデータ面のファイルです。セッションスキル（/aidlc-session-cost, /aidlc-replay, /aidlc-outcomes-pack）はこの summary --json の出力をデータソースとして使用しています。| サブコマンド | 動作 |
|---|---|
compile | 監査シャードと memory.md からランタイムグラフを再構築 |
read <stage-slug> | 1ステージの行を表示（タイムスタンプ、エージェント、センサー実行結果、結果） |
summary [--json] | ワークフロー全体の集計値を表示 |
1
2
bun .claude/tools/aidlc-runtime.ts read requirements-analysis
bun .claude/tools/aidlc-runtime.ts summary --json9. ハーネス別の差異まとめ
最後に、ハーネスごとの差異を整理しておきましょう。機能は同一ですが、プレフィックスとツールのファイルパスが異なります（README ）。
プレフィックス
| ハーネス | オーケストレーター | ランナー |
|---|---|---|
| Claude Code | /aidlc | /aidlc-bugfix など |
| Kiro IDE | /aidlc | /aidlc-bugfix など |
| Kiro CLI | /aidlc | /aidlc-bugfix など |
| opencode | /aidlc | /aidlc-bugfix など |
| GitHub Copilot | /aidlc | /aidlc-bugfix など |
| Codex CLI | $aidlc | $aidlc-bugfix など |
ツールパス
ユーティリティコマンドを直接呼び出す場合のパスです。
| ハーネス | パス |
|---|---|
| Claude Code | .claude/tools/ |
| Kiro IDE | .kiro/tools/ |
| Kiro CLI | .kiro/tools/ |
| Codex CLI | .codex/tools/ |
| opencode | .aidlc/tools/ |
| GitHub Copilot | .aidlc/tools/ |
1
2
3
4
5
# 例: doctorの直接実行
bun .claude/tools/aidlc-utility.ts doctor # Claude Code
bun .kiro/tools/aidlc-utility.ts doctor # Kiro IDE / Kiro CLI
bun .codex/tools/aidlc-utility.ts doctor # Codex CLI
bun .aidlc/tools/aidlc-utility.ts doctor # opencode / GitHub Copilot動作に違いはあるか
フラグの動作、ステージグラフ、監査イベント、エンジンの挙動はハーネス間で同一です。エンジン（状態マシン、監査ログ、並行エージェントを調整するレフェリー）はバイト単位で同一であり、異なるのはシェル（呼び出し方法とスキルの配置場所）のみです。
まとめ
この記事ではV2の全コマンドをユースケース別に整理しました。
/aidlcフラグ群: ワークフローの開始・再開・ナビゲーション・設定変更をカバーする主要インターフェース- ユーティリティコマンド: エンジンが内部で使うツール群で、デバッグや手動操作にも使える
- ランナーコマンド:
/aidlcフラグのパッケージ化。タイピング省力化と/メニューでの可視性が目的 - セッションスキル: ワークフロー完了後の振り返り用。読み取り専用
- 環境変数:
AWS_AIDLC_DEFAULT_SCOPEでプロジェクトデフォルトを設定可能
「やりたいこと」が明確な場合はセクション3の逆引き表を、フラグの動作を知りたい場合はセクション4〜5を参照してください。
Series: AI-DLC Workflow V2の解説 (31 articles)
- …
- 18AI-DLC Workflow V2のCLIコマンドガイド: やりたいことから逆引きする 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