Question 1

AI-DLC 'log review' エラー "the reviewer appendix must contain exactly one Reviewer line matching the requested reviewer" の修正方法

Accepted Answer

これはAI-DLC v2.11.0の既知のバグで、v2.11.1で修正されました（#2221にて）。2.11.0では、`core/tools/aidlc-lib.ts`のレビュアー権限チェックがすべての`**Reviewer:**`行をカウントしていたため、レビューファイルがエージェントの識別マーカー（例：`**Reviewer:** aidlc-product-lead-agent`）で始まり、さらにverdictブロック自体にもReviewer行がある場合、2行とカウントされてレビューが拒否されていました。修正方法：AI-DLCをv2.11.1以降にアップグレードしてください（またはピン留めしているフレームワークバージョンを更新してください）。2.11.1以降では、Verdict、Reviewer、またはIteration行が一字一句同じ形で繰り返されている場合は1行としてカウントされるため、識別マーカーで始まるレビューファイルは正常に記録され、すべての発見事項がゲートに表示されます。*異なる*エージェントを指名する2行目のReviewer行は、引き続き正しく拒否されます。2.11.0を使い続けなければならない場合の回避策：レビュー担当エージェントに（ディスパッチブリーフで）、レビューファイルを`## Review`から始め、Reviewer行はverdictブロック内に1行だけ含め、ファイルの先頭行には置かないよう指示してください。注意：拒否後に`--retry-pending`を使用すると、再試行は意図的にクリーンなスロットから開始され、拒否されたレビューの発見事項は引き継がれないため、Majorな発見事項を失わないよう、最初のレビューの発見事項を手動でゲートに提示してください。

Question 2

aidlc engine state unit start の実行時に「could not resolve the current routed unit (no diagnostic)」エラーを修正する方法

Accepted Answer

このエラーは aidlc 2.10.0 で発生します。`unit start` および `unit complete` 内部のルーティングチェックが子プロセスとして `orchestrate next` を起動し、約30秒後にそれを強制終了するためです。`next` がそれより長くかかる場合（大規模なワークスペースでよくあります。例えば49,000個以上のファイルでは20～125秒かかることがあります）、開始は「no diagnostic」という誤解を招くメッセージで拒否されます。

**修正:** aidlc 2.11.0 以降にアップグレードしてください。PR #1369 でルーティングチェックのタイムアウトが約30秒から5分に引き上げられたため、低速な `next`（20～125秒）でも拒否されなくなりました。これは issue #1547 を解決したのと同じ修正です。

**すぐにアップグレードできない場合の回避策（Windows）:**
1. 重いプロセス（Chrome、他の Claude Code セッション、Visual Studio）を閉じてください。
2. フロントエンドの `node_modules` フォルダを一時的に削除してください。
3. `aidlc engine orchestrate next` を連続して2～3回実行し、ファイルキャッシュをウォームアップしてください。
4. `Start-Process` 経由で `unit start` を起動し、その後約6秒間、300ミリ秒ごとにマーカープロセスとその子プロセスである `next` の PriorityClass を High に設定してください。

注意: これらの回避策は、ウォームアップ済みの `next` が約30秒以内に終了する場合にのみ有効です。2.11.0 以降でも拒否が発生する場合は、通常の `aidlc engine orchestrate next` にかかる時間を計測して報告してください。

Question 3

Kiro CLI のサブエージェントが /model で選択したモデルとは異なるモデルで実行されるのはなぜですか？

Accepted Answer

Kiro CLI のサブエージェント（composer、developer、reviewer などのディスパッチされる AI-DLC エージェント）は、`/model` または `kiro-cli chat --model` で選択したセッションモデルを継承しません。常に保存されたデフォルトモデル（`~/.kiro/settings/cli.json` 内の `chat.defaultModel`）で起動します。これは、Kiro のサブエージェントが継承するのはステアリングファイル、MCP サーバー、ワークスペースへのアクセス、spec の状態、権限のみであり、モデルは継承しないためです。`/model` の切り替えは、保存するまで現在のチャットにのみ影響します。

修正方法：Kiro CLI で `/model set-current-as-default` を実行するか、エージェントをディスパッチする前に `aidlc config models --session-model <model-id> --yes` を実行し、`chat.defaultModel` が意図したモデルと一致するようにしてください。これにより、保存されたデフォルトモデルが利用できなくなった場合（"model is unavailable, retrying now"）に、conductor は動作し続けているのにディスパッチが失敗するという問題も防げます。

AI-DLC v2.11.1（PR #2405）では、ドキュメント、`aidlc config models --show`、`aidlc doctor` が修正され、エージェントはセッションモデルを継承するのではなく、Kiro 設定に保存されたモデルで起動する旨が明記されました。

Question 4

プラグインのビルドが15分間ハングする場合の "could not acquire plugin build output lock" エラーの修正方法

Accepted Answer

このハングはロック競合ではなく、パーミッションの問題です。共有ロックフォルダ `/tmp/aidlc-plugin-build-locks` は、最初にビルドを実行したユーザー(例:CI では root)によってモード 0700 で作成されます。そのため、他のユーザーは `EACCES` エラーとなり、900000 ms(15 分)のタイムアウトに達するまで 25 ms ごとにサイレントにリトライされ続けます。回避策 — ビルドを実行する前に、各ユーザー専用の一時ディレクトリを設定します: ```sh mkdir -p "$HOME/.tmp" export TMPDIR="$HOME/.tmp" TMP="$HOME/.tmp" TEMP="$HOME/.tmp" bun /aidlc-plugin-build.ts ``` 前のステップが root として実行され、後のステップが非特権ユーザーとして実行される CI では、非特権ステップで `TMPDIR`/`TMP`/`TEMP` をジョブのスクラッチディレクトリ内のフォルダに設定してください。あるいは、フォルダの所有者として、スティッキービットを付けて共有ロックディレクトリを全ユーザーがアクセス可能にします: `chmod 1777 /tmp/aidlc-plugin-build-locks`。 `ls -ld /tmp/aidlc-plugin-build-locks` で確認してください — モードが `drwx------` で、所有者が別のユーザーになっている場合、これが原因です。

Question 5

「Refusing to complete feasibility」/ SUMMARY_QUESTIONS_MISSING エラーによるt242テストの失敗を修正する方法

Accepted Answer

テスト `tests/unit/t242-state-transition-guard.test.ts` が失敗するのは、その bare なフィクスチャに stage-questions ファイルが存在しないためで、エンジンの `gate-start` が `"reason_codes":["SUMMARY_QUESTIONS_MISSING"]` で拒否します。これはロジックの破綻ではなく、後から追加された前提条件に対してテストが古くなっている（stale）ことが原因です。修正方法は2つあります:

1. **推奨:** テストが生成する環境で `AIDLC_SKIP_SUMMARY_CONFIRMATION_GUARD=1` を設定します。これは `tests/unit/t-guard-refusal-actionable.test.ts` の前例に合致し、テストの焦点をゲートワードに保てます。以下で検証してください:

```bash
AIDLC_SKIP_SUMMARY_CONFIRMATION_GUARD=1 bun test tests/unit/t242-state-transition-guard.test.ts
# → 56 pass, 0 fail
```

2. **代替案:** フィクスチャに `feasibility-questions.md` ファイルをシードして、実際のガードパスが実行されるようにします。より忠実ですが、テストが summary-confirmation フローに結合してしまいます。

注意: この失敗は `CLAUDE_CODE_SESSION_ID` のリークが原因ではありません（それは別件の t265 の問題です）。その変数を unset しても解決しません。

aidlc-workflows

主な機能

できないこと

使用例

タグ

はじめ方

類似プロジェクト