Kiro CLI の新機能を使って仕様駆動開発をやってみた

はじめに

こんにちは、NRI の島田です。
2025年度に入社し、現在はパブリッククラウド運営サービス「QUMOA」にて AWS を中心とした開発・運用業務に携わっています。
クラウド未経験でのスタートでしたが、日々の実務を通じて新しい技術に触れ、自身のスキルや視野が広がっていくことに大きなやりがいを感じています。

近年の急速な AI の普及に伴い、私の周囲でもいわゆる「AI コーディングエージェント」を活用するエンジニアが増えてきました。私自身もワークショップなどで体験したことがあり、開発で AI エージェントを使いこなすことの優位性を実感しています。
そこで、今回は AWS 製の AI コーディングツール Kiro（Kiro CLI）を使い、2026年5月にリリースされたアップデートを試しつつタスク管理アプリを実際に作ってみました。

Kiro とは

Kiro は IDE・CLI・Web インターフェースの3つの形態で提供されている AI コーディングツールです。今回はその中の Kiro CLI を使います。ターミナルから操作でき、IDE と同じ Steering・カスタムエージェント・MCP 設定を共有して使うことができます。
AI エージェントを使って開発作業を支援する開発環境で、プロンプトを構造化された要件・設計・タスクに変換し、それをエージェントが実装する「仕様駆動開発（Spec-Driven Development）」を特徴としています。また、ドキュメントの更新・ユニットテストの生成といったタスクをバックグラウンドで自律的に実行するフック機能も備えています。

注目したアップデート

今回は、2026年5月20日に発表された以下2つのアップデートの内容に注目しました。
どちらも Kiro の効率的な利用を考えた際にあると嬉しい便利機能です。

/rewind

会話を巻き戻して新しいセッションとして分岐させる機能です。元のセッションは失われないので、分岐先で試した内容が気に入らなければ /chat resume（元のセッションを再開するコマンド）で戻れます。
「別のアプローチを試したい」「エージェントが意図しない方向に進んでしまった」という場面で、最初からやり直さずに特定の場面から再試行できます。

/effort

モデルの推論量を low / medium / high / xhigh / max の最大5段階で調整する機能です。モデル自体を切り替えるのではなく、同じモデルが思考に使うトークン数を増減させます。深い分析が必要な設計フェーズは high、設計が確定した実装フェーズは medium、定型的なテスト生成は low と使い分けることで、推論コストと品質のバランスを取りながら開発を進められます。現時点で対応しているのは Claude Sonnet 4.6・Claude Opus 4.6・Claude Opus 4.7・Claude Opus 4.8 の4モデルのみ（2026年5月現在）で、調整の段階はモデルによって異なります。

AI活用に関するソリューション・事例はこちら

開発の題材

今回は、Markdown ファイルで書いた要件メモ（下記図）1つだけを Kiro のインプットとして、AWS 上で動くタスク管理アプリの構築を目指します。S3 でホストしたフロントエンド（HTML/JS）が API Gateway・Lambda を経由して DynamoDB にアクセスするシンプルなサーバーレス構成で、CloudFormation によって一気通貫してデプロイするまで進めます。
要件メモでは、目的・機能要件・技術スタック（Python 3.13 / CloudFormation）・AWS インフラ構成の候補・制約と前提を1ファイルにまとめています。特に今回は新機能である /rewind を使ってみたかったので、DB に何を採用するかはあえて書かず、Kiro に比較してもらいました。/rewind を使えば、一方の案で開発を進めた後でも会話を巻き戻して別の案に切り替えられるため、RDS・DynamoDB の両案を実際に試して比較できます。

事前準備

今回の開発では、AI コーディングをスムーズに行うために次の2点を事前に準備しました。
1つ目はカスタムエージェントの利用です。カスタムエージェントは .kiro/agents/ に JSON ファイルを置くだけで認識されます。今回はメインエージェント（dev-agent）とレビューエージェント（reviewer-agent）の2つを用意しています。
メインエージェントが設計書の出力・実装・テストなど各ステップを完了した後、reviewer エージェントをサブエージェントとして起動してレビューさせています。
サブエージェントは独自のコンテキストで動作しメインの会話への参照を持ちません。そのため、設計書を書いたエージェントとは別の文脈でレビューが行われ、同じ思い込みを引き継がない独立したチェックになります。
参考：https://kiro.dev/docs/cli/chat/subagents/

2つ目の工夫は、Steering と Skills の活用です。
Steering と Skills はいずれも Kiro にコンテキストを与える仕組みですが、役割が異なります。
Steering は毎回プロンプトとして説明していたプロジェクト規約を、一度書くだけで永続化できる機能です。今回はコーディング規約やテスト方針など技術的な前提を記載したファイルと、プロジェクト配下の各ディレクトリの責務について記載したファイルの2つを用意しました。
Skills は必要なときだけ読み込まれる手順書で、エージェントが必要と判断したときのみファイル全体が読み込まれます。これにより、コンテキストを節約しながら、多くのドキュメントへのアクセスが可能になります。
今回は開発フローの各ステップに対応する5つの Skill を用意しました。

.kiro/ 配下のディレクトリ構成（agentの定義と skills/steering の配置）

ステップ1：システム概要設計書を作成する
ステップ2：DB 設計書を作成する（/rewind で2案を比較させたい工程）
ステップ3：CloudFormation テンプレートを作成する
ステップ4：バックエンド・フロントエンドを実装する
ステップ5：テストを生成・実行する

Skills を細分化したもう一つの理由は effort の制御です。各 Skill に各ステップ開始時のeffort レベルを明示することで、開発フローの各工程で推論量を変える指示を自然な形で書けるようにしています。今回は設計段階の Skill には high、実装段階の Skill には mediumを指定してトークンを効率的に利用しています。
なお、Steering も Skills も今回のようにカスタムエージェントを利用する際はデフォルトで読み込まれないので、エージェント定義の resources に明示的に追加する必要があります。
参考：https://aws.amazon.com/jp/blogs/news/kiro-cli-1-24-0/

Kiro による開発

ここまでの下準備を終えて、実際に開発に移ります。先ほど定義した dev-agent を指定して Kiro を起動することで、開発スタートです。

kiro-cli --agent dev-agent

各 Skill にはフェーズ開始時に effort レベルの設定を促す指示を入れているため、まず /effort を設定してから開発を始めます。

あとは Kiro が要件メモ（system-plan.md）を読み込み、成果物を生成しながらステップを順番に進め、サブエージェントがレビューしたものについて承認を求めてきます。人間がやることは承認と推論量の調整（/effort）、必要ならば会話の巻き戻し（/rewind）です。
今回は /rewind の機能を試すために、DB 選択は Kiro に委ねる形にしています。
実際、構成のシンプルさ・コスト・拡張性などの点で RDS/DynamoDB の両案を比較してくれて、DynamoDB の方が向いていそうだと判断しているようです。
ただし、今回は /rewind の動作を確認するためにあえて RDB 案から進め、途中で切り替えるという手順で試してみました。

まず RDB 案を採用して進めていくと、CloudFormation のテンプレート実装まで完了し、全体像が完全に固まりました。

VPC Endpoint 経由で Secrets Manager にプライベートアクセスしていたり、Lambda の実行ロールが最小権限になっていたりと配慮して実装してくれているのですが、やはりコスト面が気になります…
ここで、/rewind を使って RDB 案を選択したタイミングまで立ち返ってみました。

/rewind を使うことによって、Kiro とのこれまでのやり取りの断面の中から戻りたいタイミングを選択することができます。
ここで注意が必要なのは、/rewind はあくまで会話の分岐であり、ディスク上のファイルは元に戻らないという点です。
当初の RDB 案で生成された CloudFormation テンプレートなどのファイルはディスクに残ったままになるので、今回は DynamoDB 案で上書きされる形になりました。厳密に管理したい場合は git でコミットしてから /rewind する方がよさそうです。
DB 設計が確定した後は、CloudFormation テンプレートの生成・バック/フロントエンドの実装・テストと順番に進み、デプロイまでを Kiro にお任せして簡単なタスク管理アプリを AWS 上に構築することができました。IaC 化しているので片付けも簡単です。

おわりに

今回は Kiro CLI で追加された /rewind と /effort を使いながら、タスク管理アプリの AWS 構築を一気通貫で進めました。
仕様駆動開発（Spec-Driven Development）の考え方自体は以前からありましたが、/rewind で設計の分岐・比較が手軽にできるようになり、/effort でフェーズごとの推論コストを意識的にコントロールできるようになってきました。
AI コーディングエージェントの進化のスピードを改めて感じつつ、そのぶん AI 開発における人間の役割も明確化されてきたのではないかなと感じています。アップデートのたびに開発体験が洗練されていく Kiro に、引き続き注目していきたいと思います。