Kiroの新機能「すべてのタスクを一括実行（Run all tasks）」を試してみた

こんにちは、サーバーワークスで生成AIの活用推進を担当している針生です。

「開発作業を AI に全部お任せしたい」 と思ったこと、ありませんか？

Kiro に「すべてのタスクを一括実行（Run all tasks）」機能が実装されました。

AWS ブログにて、この機能が実装された経緯について紹介されています。興味深い内容だったので、実際に試してみることにしました。

Kiro ってそもそも何？

Kiro は AWS が 2025 年 7 月にプレビュー公開した AI IDE（統合開発環境）です。特徴は Spec-driven development（仕様駆動開発） で開発を進められること。

普通の AI コーディングツールは「コード書いて」と言ったらすぐコードを生成します。一方 Kiro は、まず仕様を作るところから始めます。

流れはこんな感じです。

1. 自然言語でやりたいことを伝える
   「TODO アプリを作りたい」

2. Kiro が要件定義を生成
   - ユーザーストーリー
   - 受け入れ条件（EARS 記法）

3. 設計ドキュメントを生成
   - アーキテクチャ
   - 技術スタック
   - データ構造

4. タスク一覧を生成
   - 依存関係を考慮した実装順序
   - 各タスクの詳細

5. タスクを実行してコード生成

Kiro 公式は「Vibe coding から Viable code へ」と表現しています。なんとなく AI に指示して動くコードを作る「雰囲気コーディング」ではなく、ちゃんと仕様に基づいた「実用コード」を目指すということです。

この「仕様 → タスク → 実装」という流れがあるからこそ、「タスクを一括実行」という機能が意味を持つわけです。

なぜ Kiro は「一括実行」を実装しなかったのか

Kiro がローンチした当初、多くのユーザーから「なぜ仕様のすべてのタスクを一度に実行できないの？」という質問が寄せられていましたが、Kiro チームはその機能を意図的に実装しなかったそうです。

6 ヶ月間、ユーザーからのリクエストが山のように来ても「ノー」と言い続けたそうです。

スピード vs コントロール

AWS ブログではこう説明しています。

Kiro における私たちの基本的な考え方は、開発者が可視性とコントロールを維持することで AI 開発が最も効果的に機能するというものです。

開発者には、以下のことを期待しています。

何が起こっているかを見てほしい
各タスクの実行を理解してほしい
問題を早期に発見してほしい

一方、避けたいシナリオは「コーヒーを取りに行っている間に AI がコードベース全体を自動実行する」こと。Kiro チームはこれを「無謀」と判断しました。

内部テストで見えた現実

実際、内部テストではこんな結果が出ていたそうです。

AI がうまく自律的に動くケースもある
でも失敗するケースもある
失敗した場合、ユーザーはどこで問題が起きたか特定するのに多くの時間を費やす

個人的に共感するポイント

私も他の AI ツールで「自動でやってくれ」モードを使ったことがありますが、途中で何かおかしくなったとき、デバッグが大変でした。どの段階で AI が誤解したのかわからないし、コンテキストが長すぎて追いきれません。

結局、最初から自分でやり直した方が早かったりします。

だから Kiro チームの「まずは 1 つずつ確認させる」という判断は、ユーザー体験を考えた上での選択だったんだと思います。

なぜ今リリースしたのか

では、なぜ今になってリリースしたのでしょうか。

答えは「信頼性を担保する基盤を構築したから」です。

Kiro チームは過去数ヶ月、いくつかの重要な機能を静かにリリースしてきました。

Property-Based Testing（PBT）

普通のユニットテストは「この入力に対してこの出力が返る」ことを確認します。一方 PBT は「このコードは仕様の性質（property）を満たしているか」を検証します。

// 通常のユニットテスト
test('add(2, 3) returns 5')

// Property-Based Testing
test('add(a, b) は常に add(b, a) と同じ結果になる')
test('add(a, 0) は常に a を返す')

Kiro は Spec（仕様）からこの「性質」を自動で抽出して、生成されたコードがそれを満たすかテストします。

つまり「コードが動く」ではなく「仕様通りに動く」ことを検証できるようになりました。

Dev Server チェック

生成されたコードを実際に Dev Server で動かして、実行時エラーがないか確認します。

LSP 診断

構文エラー、型エラー、セマンティックエラーをリアルタイムでチェックします。

これらが組み合わさると

「すべてのタスクを実行」を押したとき、Kiro は単にコードを高速生成するわけではありません。以下の検証を通過させます。

各タスクの出力を PBT で検証
Dev Server でコードをチェック
LSP 診断でエラーを確認

「慎重に監視された開発の信頼性を備えた、自動実行のスピード」

これが Kiro チームの目指したところということです。

実際に試してみた

では実際どうなのでしょうか。

TODO アプリを Kiro で作って、「すべてのタスクを一括実行」を試してみました。

Spec モードでプロンプトを入力

新しいプロジェクトを作って、Kiro を Spec モードに切り替えます。チャットに以下のプロンプトを投げます。

シンプルな TODO アプリを作りたい。
- タスクの追加、完了、削除ができる
- ローカルストレージでデータを永続化
- React + TypeScript で実装

プロンプトを送信すると、Kiro が Spec の生成を開始します。

Requirements（要件）の確認

まず生成されるのが Requirements（要件定義） です。EARS 記法で書かれた受け入れ条件が表示されます。

WHEN ユーザーが新しいタスクを入力して追加ボタンを押す
THE SYSTEM SHALL タスクを一覧に追加し、入力欄をクリアする

WHEN ユーザーがタスクの完了チェックボックスをクリック
THE SYSTEM SHALL タスクの状態を完了/未完了に切り替える

WHEN ページがロードされる
THE SYSTEM SHALL ローカルストレージからタスクを読み込んで表示する

「こういう条件のとき、システムはこう振る舞う」が明確になっています。内容を確認して、問題なければ次に進みます。

Design（設計）の確認

次に Design（設計ドキュメント） が生成されます。ここにはアーキテクチャ、技術スタック、データ構造などが記載されています。

今回は React + TypeScript でのコンポーネント構成、ローカルストレージの使い方などが設計として提示されました。設計内容を確認して、問題なければ次に進みます。

Task List（タスク一覧）の確認

最後に Task List（タスク一覧） が生成されます。今回は 8 つのタスクに分割されました。

プロジェクトの初期セットアップ
Todo の型定義
Todo コンポーネントの作成
TodoList コンポーネントの作成
AddTodo コンポーネントの作成
ローカルストレージのカスタムフック
App コンポーネントの統合
スタイリング

タスクは依存関係を考慮した実行順序になっています。

「すべてのタスクを一括実行」を押す

Requirements → Design → Task List をすべて確認したら、いよいよ本題です。

画面上部にある 「Run all tasks」 ボタンをクリックします。

クリックすると、Kiro はタスクを効率良く実行していきます。

ただし、完全に放置できるわけではありません。タスクの実行中、Kiro がターミナルコマンド（npm install など）を実行しようとするたびに 許可を求めるダイアログ が表示されます。ユーザーはその都度「Allow」をクリックして許可する必要があります。

「コーヒーを取りに行っている間に全部終わっている」というわけにはいきませんが、コードを書く作業自体は自動化されているので、許可ボタンを押すだけで進んでいきます。

なお、設定ですべてのコマンドを自動許可にすれば完全自動化も可能です。ただしその場合は、他に影響を及ぼすような環境で実行する場合は注意してください。基本的にはすべてを許可するのは非推奨です。

結果の確認

8 つのタスク、すべて完了しました。

npm run dev で起動すると、TODO アプリがちゃんと動きました。

使ってみた感想

良かった点

1. 時間の節約が実感できる

タスクを手動で 1 つずつ実行・確認していたら、もっと時間がかかりました。「一括実行」によって、許可ボタンを押しながら見守るだけで基本的な実装が終わります。

2. 検証が走る安心感

ただ高速にコードを吐き出すんじゃなくて、PBT で検証してくれるのは心強いです。「動いてるけど実は仕様を満たしてない」というケースを防げます。

3. Spec があるから何が起きているかわかる

一括実行中も、どのタスクを実行しているか、何を検証しているかが見えます。ブラックボックスじゃないから安心感があります。

4. 小規模な機能開発と相性が良い

AWS ブログでも書かれている通り、「手取り足取り導きたくない小規模な機能仕様」に最適です。今回の TODO アプリくらいの規模なら、一括実行がベストな選択だと思います。

気になった点・改善希望

1. 大きな機能では慎重に

タスクが 20 個以上あるような大規模な実装では、途中で「ちょっと待て」と言いたくなることがあるかもしれません。一括実行する前に Spec を念入りに確認することが重要です。

2. PBT の限界

Property-Based Testing は万能ではありません。仕様自体が曖昧だと、テストも曖昧になります。結局「良い Spec を書く」スキルが求められます。

3. 失敗時のリカバリー

今回はスムーズに完了しましたが、途中で失敗したときの対処法はもう少し試してみたいです。どこまで自動でリカバリーしてくれるのか、手動介入が必要なのか。

どんな場面で使うべきか

一括実行が向いているケース：

小〜中規模の機能追加
仕様が明確で、迷いがない場合
プロトタイプや MVP 開発
定型的な CRUD 機能の実装

ステップバイステップが向いているケース：

大規模で複雑な機能
仕様が曖昧で、実装しながら詰めていきたい場合
既存コードベースへの慎重な統合
学習目的（AI の実装過程を観察したい）

まとめ

Kiro チームが 6 ヶ月間「ノー」と言い続けた理由、そしてなぜ今リリースできたのか。その背景には「信頼性を担保する基盤」の構築がありました。

Property-Based Testing でコードが仕様を満たすか検証
Dev Server と LSP で実行時・静的エラーをチェック
これらを組み合わせて「安全な自動実行」を実現

「AI に全部お任せ」は魅力的ですが、ただ速いだけではダメです。検証が伴って初めて、安心して任せられます。

「便利な機能を追加する前に信頼性の基盤を整える」という姿勢からも、今後の発展も大いに期待できそうです。

気になった人は、ぜひ試してみてください。