---
title: "Kiro IDE に AI-DLC v2 を入れて PoC を完走させた記録"
date: 2026-07-02
categories:
  - "AI IDE"
  - "Kiro"
url: "https://hidetaka.dev/ja/writing/dev-notes/aidlc-v2-poc-on-kiro-ide"
---

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

2026-06-18 に [`aidlc-workflows`](https://github.com/awslabs/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` を入力します。

![](https://wp-api.wp-kyoto.net/wp-content/uploads/2026/06/25540075d4bb9b4b2ae1a36011d983f1-20260624170814.png)

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

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

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

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

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

![](https://wp-api.wp-kyoto.net/wp-content/uploads/2026/06/d97710224c7f8c8f1041b706de2d65ba-20260624170823.png)

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

![](https://wp-api.wp-kyoto.net/wp-content/uploads/2026/06/e165102145b7be3cbdbccbbcf9bbe297-20260624170754.png)

```
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` が呼ばれます。

![](https://wp-api.wp-kyoto.net/wp-content/uploads/2026/06/7f284541fbeae701b381a86fa77c2fd8-20260624170831.png)

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

## intent-capture ステージの動作

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

![](https://wp-api.wp-kyoto.net/wp-content/uploads/2026/06/53587b8dc7df11b108f5611d7a870202-20260624170840.png)

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

![](https://wp-api.wp-kyoto.net/wp-content/uploads/2026/06/3f01b8a7b4b75f4eb5a821021334430f-20260624170858.png)

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

![](https://wp-api.wp-kyoto.net/wp-content/uploads/2026/06/e09c756a9cd0e79ed8fbee54a32729c5-20260624170902.png)

## Learning Loop と Reviewer

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

![](https://wp-api.wp-kyoto.net/wp-content/uploads/2026/06/2de68eab2a3977796b73c8a6f7c38e39-20260624170908.png)

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

![](https://wp-api.wp-kyoto.net/wp-content/uploads/2026/06/0ba7191139e2db1043221a2ef2eff183-20260624170912.png)

```
{
  "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** 判定を出すことがあります。

![](https://wp-api.wp-kyoto.net/wp-content/uploads/2026/06/277ffbe22b61198e5db5fdfea18bc7f8-20260624170918.png)

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

-   FR-3.3: `terraform apply` は自動実行

-   FR-3.4: `apply` 前に plan 結果を確認・承認

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

![](https://wp-api.wp-kyoto.net/wp-content/uploads/2026/06/7679d67e5da246be9d913dfd39841321-20260624170944.png)

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 段階なので仕様の変化には引き続き注意が必要です。