[アップデート] Kiro IDE 0.12 で Spec のタスク並列実行、Quick Plan、要件分析（Analyze Requirements）が追加されたので確認してみた

いわさです。

Kiro IDE の Spec ワークフローでは各フェーズが順番に進んでいきます。

この Spec フローではいくつかの要素から時間がかかりすぎることがありました。簡単な検証アプリでも要件定義から設計、タスク整理と順番に確認しながら進める必要があったり、タスクがひとつづつ順番に実行されるのを待ったり、作成した後に要件定義矛盾が見つかったりとです。
それらが必要な場合もあるのですが、概念実証だけやってしまいたいとかトライアンドエラーが必要な場合は出来るだけ早く一気に作成したいことがあります。

これが今回の Kiro IDE 0.12 で、Spec ワークフローに 3 つの新機能が追加されました。

https://kiro.dev/changelog/ide/0-12/

• Parallel Task Execution: 既存の Run all Tasks が並列実行に対応し、独立タスクを同時に処理
• Quick Plan: 承認ゲートなしで requirements/design/tasks を一括生成するセッションモード
• Analyze Requirements: 要件の論理的矛盾・曖昧さ・ギャップを自動推論で検出

Quick Plan は以前紹介した /quick-spec コマンドが正式なセッションモードとして独立した形のようです。
Analyze Requirements は要件定義と設計の間に挟む分析パスで、automated reasoning を使って要件間の矛盾を検出してくれるとのこと。
今回こちらを確認してみたので紹介します。

Quick Plan を使ってみる

まずは Quick Plan から確認してみましょう。

以前、こちらの記事で /quick-spec コマンドによる Spec の一括生成を紹介しています。

https://dev.classmethod.jp/articles/kiro-ide-quickspec-architecture-selection/

/quick-spec と同様に承認ゲートなしで 3 ドキュメントを一括生成する機能ですが、今回はスラッシュコマンドではなく Spec セッション開始時に選択できる正式なセッションモードとして追加されています。

Spec セッションを開始すると、「Build a Feature」「Fix a Bug」と並んで「Quick Plan」が選択肢に表示されます。

Quick Plan を選択すると、承認ゲートなしで requirements.md → design.md → tasks.md を一気に生成してくれます。
今回は「最小限のサンプルアプリを Spec モードで作成したいです」と入力して試してみました。

「要件が生成されました。続いてデザインを生成します...」「デザインも完了しました。タスクリストを生成します...」と、各フェーズを自動的に進めてくれます。

生成が完了すると、.kiro/specs/sample-app/ 配下に requirements.md、design.md、tasks.md の 3 ファイルが生成されていました。

/quick-spec との違いとしては、スラッシュコマンドではなくセッションモードとして独立したことで、Spec の作成フローに自然に組み込まれている点ですね。
なお、公式ドキュメントによると clarifying questions で意図を確認してから生成に入るケースもあるようですが、今回のようにシンプルな入力の場合は即座に生成が始まるみたいです。
生成されるドキュメントの形式は通常の Feature Spec と同じなので、生成後に会話でリファインしたり、後述の Analyze Requirements で分析したりすることも出来ます。

Parallel Task Execution を使ってみる

次に Parallel Task Execution を確認してみます。

今回の changelog に以下の記載があります。

Run all Tasks now runs independent tasks concurrently instead of one at a time.

従来は1つずつ順番に実行されていた Run all Tasks が、依存関係のない独立したタスクを並列で実行するように変更されたみたいです。
公式ドキュメントによると、タスクリストから依存関係グラフを構築し、独立したタスクを Wave（波）としてグループ化して同時実行するとのこと。
具体的には、依存関係のないタスクを Wave 1 として同時実行し、Wave 1 が完了したら次の Wave 2（Wave 1 に依存していたタスク群）を同時実行する...という流れです。

Kiro builds a dependency graph of the tasks in your tasks.md and groups independent tasks into waves:

• Wave 1 — all tasks with no dependencies. These run concurrently.
• Wave 2 — all tasks whose dependencies were satisfied by Wave 1. These run concurrently.
• Wave N — continues until all tasks are complete.

https://kiro.dev/docs/specs/

設定は不要で、従来と同じ Run all Tasks ボタンを押すだけで自動的に並列実行されるとのこと。
先ほど Quick Plan で生成した Spec の tasks.md を開くと、右上に「Run all tasks」ボタンが表示されています。

Run all tasks を押すと、チャット側に「All tasks queued. Now let me start the execution loop. First wave: tasks 1.1 and 1.2 (no dependencies).」と表示され、依存関係のないタスク 1.1 と 1.2 が同時に実行されました。
「Now dispatching both tasks in parallel:」というメッセージとともに、両タスクが「Status: In Progress」になっているのが確認できます。

エディタ側でもタスク 1.1 と 1.2 が同時に「Task in progress」になっており、タスク 1.3 は「Task queued」で待機しています。
タスク 1.3 は 1.1 と 1.2 に依存しているため、Wave 1 が完了してから実行される流れですね。

なお、公式ブログによると、並列実行の信頼性を担保するために Property-Based Testing（PBT）、Dev Server / LSP Diagnostics、サブエージェントによるコンテキスト分離といった仕組みが裏側で動いているとのことです。

https://kiro.dev/blog/run-all-tasks/

Analyze Requirements を使ってみる

ここからは今回のメイン、Analyze Requirements を詳しく確認してみます。

Analyze Requirements は要件定義（requirements.md）に対して深い分析を行い、論理的矛盾、曖昧さ、競合する制約、暗黙の前提、エッジケースの欠落などを検出する機能です。
個々の要件を単独で見るのではなく、要件間の関係を横断的に推論するのが特徴みたいですね。

公式ドキュメントによると、検出できる問題は以下の5種類です。
論理的矛盾（個別には正しいが組み合わせると実現不可能な要件）、曖昧な表現（「大きなファイル」「高速なレスポンス」のように実装者によって解釈が分かれる記述）、競合する制約（機能要件と非機能要件が同時に満たせない）、暗黙の前提（未定義の概念への参照）、エッジケースの欠落（正常系しかカバーしていない）です。

• Logical inconsistencies — two requirements that individually make sense but are collectively impossible
• Ambiguities — language like "large files" or "fast response times" that would produce divergent implementations
• Conflicting constraints — functional and non-functional requirements that can't all be satisfied at once
• Unstated assumptions — references to undefined concepts or behaviors
• Missing edge cases — failure modes, boundary conditions, and concurrent access scenarios not covered by the happy path

https://kiro.dev/docs/specs/analyze-requirements/

requirements.md を開いた状態で、右上の「Continue」ドロップダウンをクリックすると「Review Design」と並んで「Analyze requirements」が表示されます。

Analyze requirements を選択すると、Kiro が requirements.md と tasks.md を読み込んで分析を開始します。
分析が完了すると、チャットに要件分析サマリーが表示されました。

今回は Quick Plan で生成したシンプルな Hello World REST API の要件だったので、要件構成（3つの要件、それぞれの受け入れ基準数と概要）がテーブルで整理され、要件の特徴として以下が報告されています。

• スコープが明確: 単一エンドポイント（GET /）のみで、認証・DB・ミドルウェアなどの複雑さがない
• 受け入れ基準が具体的: WHEN/SHALL 形式で検証可能な条件が書かれている
• トレーサビリティ: tasks.md の各タスクが要件番号を参照しており、追跡可能

また「気になる点」として以下が検出されていました。

1. エラーハンドリング要件がない — 存在しないパスへのリクエスト時の振る舞いが未定義（MVP としては問題なし）
2. PORT のデフォルト値 — tasks.md では 3000 と記載されているが、requirements.md には明記されていない（暗黙の仕様）
3. テストが任意 — 受け入れ基準の検証手段としてテストがオプション扱い

今回はシンプルな要件だったので致命的な矛盾は検出されませんでしたが、暗黙の前提（PORT のデフォルト値が requirements.md に明記されていない）やエッジケースの欠落（エラーハンドリング未定義）はしっかり指摘してくれていますね。
もっと複雑な要件（例えば「オフラインでも動作すること」と「リアルタイムで他ユーザーの変更が反映されること」のような矛盾する制約）を含めた場合は、より明確な矛盾として検出されるのだと思います。

なお、公式ドキュメントによると、分析後に要件を手動で編集して再度 Analyze Requirements を実行することも出来るとのこと。
変更された要件とその相互作用を再分析してくれるみたいです。

You can re-run the analysis after editing requirements manually — Kiro will re-analyze affected requirements and their interactions.

さいごに

本日は Kiro IDE 0.12 で追加された Parallel Task Execution、Quick Plan、Analyze Requirements を確認してみました。

Quick Plan は以前の /quick-spec コマンドがセッションモードとして正式に組み込まれた形で、Spec 作成フローの選択肢として自然に使えるようになっていますね。
Parallel Task Execution は設定不要で Run all Tasks を押すだけで、依存関係のないタスクが自動的に並列実行されます。
今回の検証でもタスク 1.1 と 1.2 が同時に実行されているのが確認でき、独立タスクが多い Spec では実行時間の短縮が期待できそうです。

Analyze Requirements は今回初めて追加された機能で、要件の暗黙の前提やエッジケースの欠落を指摘してくれるのは面白いですね。
今回はシンプルな Hello World API の要件だったので大きな矛盾は出ませんでしたが、PORT のデフォルト値が requirements.md に明記されていない点など、地味だけど実装時に困りそうなポイントを拾ってくれていました。

今回のアップデートで Spec ワークフロー周りが強化されましたね。ぜひ使ってみてください。