Kiro IDE に AI-DLC v2 を入れて PoC を完走させた記録

2026-06-24 時点の情報です。AI-DLC v2 は preview 段階（v2.0.2）であり、仕様は変更される可能性があります。

2026-06-18 に aidlc-workflows リポジトリの v2 ブランチが preview リリースされました。v1（main ブランチ）が Markdown のルールファイルをコピーするだけの方式だったのに対し、v2 は TypeScript で書かれた決定的エンジン（aidlc-orchestrate.ts）を中心に完全に再設計されています。

Kiro IDE で動かして Greenfield PoC を完走させたので、その記録を残します。

前提

• OS: macOS（Apple Silicon）
• Kiro IDE: Vibe モード
• bun: 1.3.14
• AI-DLC: v2 ブランチ（v2.0.2）

セットアップ

v2 ブランチを shallow clone して、Kiro IDE 向けの配布物をプロジェクトにコピーします。

git clone --branch v2 --depth 1 https://github.com/awslabs/aidlc-workflows.git
cp -r aidlc-workflows/dist/kiro-ide/.kiro ./
cp aidlc-workflows/dist/kiro-ide/AGENTS.md ./
rm -rf aidlc-workflows

dist/kiro-ide/ 以下には .kiro/ ディレクトリと AGENTS.md が入っています。コピー後の構成は agents 13 個・skills 38 個・tools 26 個・hooks 8 個です。

bun の PATH 問題

v2 のフックとツールは bun で動きます。bun を ~/.zshrc にだけ追加した状態では、Kiro IDE がフックを実行する /bin/sh には PATH が反映されず、次のエラーが出ます。

Hook execution failed with exit code 127.
Error output:
/bin/sh: bun: command not found

/usr/local/bin はデフォルトの PATH に含まれているので、シンボリックリンクを作るのが最もシンプルな解決策です。

sudo ln -s ~/.bun/bin/bun /usr/local/bin/bun

--doctor で確認

Kiro IDE でプロジェクトを開き、チャットに /aidlc --doctor を入力します。

27 項目が通過し、失敗は 1 件のみでした。

✗  aidlc-docs/ directory exists — run `/aidlc --init` to scaffold

aidlc-docs/ が未作成なだけです。次のステップで解消されます。

--init とワークフロー開始

Vibe モードで /aidlc --init を入力します。

bun .kiro/tools/aidlc-utility.ts init が走り、スキャフォールドが完了します。

Workspace scaffolded:
  aidlc-docs/knowledge/         (team knowledge — 11 agent dirs + aidlc-shared)
  aidlc-docs/initialization/    (3 stage artifact dirs)
  aidlc-docs/ideation/          (7 stage artifact dirs)
  aidlc-docs/inception/         (7 stage artifact dirs)
  aidlc-docs/construction/      (2 stage artifact dirs)
  aidlc-docs/operation/         (7 stage artifact dirs)
State initialized: poc scope, 7 stages, Minimal depth
Project type: Greenfield

デフォルトスコープは poc です。operation フェーズはスコープ対象外として自動スキップされます。

次のプロンプトを送信した瞬間、aidlc-session-start フックが起動し bun .kiro/tools/aidlc-orchestrate.ts next が呼ばれます。

v1 では LLM がルールファイルを読んで次のステージを判断していました。v2 ではエンジンが next を計算して LLM に渡すため、ステージ遷移が決定的になっています。

intent-capture ステージの動作

最初のステージ intent-capture が始まると、intent-capture-questions.md が自動生成されます。ビジネス課題・ターゲットユーザー・成功基準・起動理由の 4 問が記述されており、回答モードを 3 択で選べます。

「Guide me」を選ぶと Q1 から順に問われ、全回答が終わると矛盾チェックが走ります。

矛盾がなければ承認ゲートが開きます。Approve を送ると次のステージへ進み、intent-statement.md と stakeholder-map.md が生成されます。

Learning Loop と Reviewer

承認ゲートの前に aidlc-runtime-compile フックが走り、対話中の判断分岐から「learning 候補」を抽出します。「このルールをプロジェクトに保存するか？」という確認が来ます。

保存すると次の JSON が作られ aidlc-learnings.ts persist に渡されます。

{
  "type": "learning",
  "scope": "project",
  "heading": "Corrections",
  "text": "ALWAYS treat the primary user (Q2) and the management scope (Q1) separately when they diverge...",
  "source": "orchestrator"
}

{"rule_learned":1,"sensor_proposed":0} が返り、.kiro/steering/aidlc-project-learnings.md にルールとして書き込まれます。以降のセッションでは、同じ文脈でこのルールが自動適用されます。

Reviewer（NOT-READY → READY）

Requirements Analysis などのアーティファクトが生成されると、aidlc-product-lead-agent がレビューを行い、NOT-READY 判定を出すことがあります。

今回検出されたブロッカーのひとつが FR-3.3 と FR-3.4 の矛盾です。

• FR-3.3: terraform apply は自動実行
• FR-3.4: apply 前に plan 結果を確認・承認

ブロッカーを解消すると READY に昇格し、残ったギャップ（必須・推奨）を回答すれば次のステージへ進めます。

v1 では LLM が requirements を書いてそのまま次のステージへ進んでいました。v2 は専用の Reviewer エージェントが矛盾・未定義・スコープ逸脱を承認ゲートの前に検出します。

v1 との比較

v1（main ブランチ）は core-workflow.md をコピーするだけで動く Markdown ルールファイル方式で、ステージ遷移は LLM がルールを読んで判断していました。v2 は aidlc-orchestrate.ts がステージ遷移を決定論的に計算し、Learning Loop・Reviewer・フック群が TypeScript で実装されています。v1 の軽さと対照的に、v2 はプロジェクト固有のルール蓄積と自動品質チェックを持つ代わりに bun への依存と相応のファイル群の重さがあります。preview 段階なので仕様の変化には引き続き注意が必要です。