Kiroとは？AWS発の仕様駆動AI IDEの特徴と使いどころ

Kiro（キロ）とは、AWSが提供するエージェント型のAI IDE（統合開発環境）です。チャットの指示からいきなりコードを書かせるのではなく、要件定義書、設計書、タスクリストを先に作らせてから実装に進む「仕様駆動開発（SDD）」を、製品の中核に据えていることが最大の特徴です。 SDDを正面に打ち出した早期の代表的な製品で、この分野の議論で必ず名前が挙がる存在です。

Kiroとは何か

Kiroは2025年7月にパブリックプレビューが公開され、同年11月に正式版（GA）となりました。 VS Codeのオープンソース基盤（Code OSS）をベースにしたスタンドアロンのIDEで、VS Codeの設定やテーマを引き継げます。正式版の公開と同時に、ターミナルで動くKiro CLIも提供されています。

生まれた背景は、AIコーディングの品質問題です。チャットの勢いでAIにコードを書かせる進め方は、プロトタイプでは速い一方、仕様の曖昧さがそのままコードに埋め込まれ、本番開発では手戻りと品質劣化を生みます。 Kiroはこの対策として、「実装の前に文書を確定させる」工程を製品の標準フローにしました。

モデルは自社製にこだわらず、AnthropicのClaude系やOpenAIのGPT系など複数のLLMを切り替えて使えます。料金は月額のクレジット制で、無料枠のほか、1ユーザー月20ドルからの有料プランが段階的に用意されています（2026年7月時点）。

仕組み：3つの中核機能

Kiroの性格を決めているのは、次の3つの機能です。

Specs（仕様駆動の実装フロー）：機能開発を依頼すると、Kiroはまず要件定義書（requirements.md）を生成し、人間の承認を待ちます。承認されると設計書（design.md）、次にタスクリスト（tasks.md）へ進み、各段階に承認ゲートが挟まります。標準のフローでは、実装が始まるのは文書の承認後です。バグ修正用や設計から入る型、承認ゲートを省いて3文書を一気に作るQuick Specなどの変種があり、IDEでは独立したタスクの並行実行にも対応しています
Hooks（イベント駆動の自動実行）：ファイルの保存や作成、エージェントのツール実行前後といったイベントを引き金に、決まったチェックや処理を自動で走らせます。保存のたびにテストを回す、危険な操作の前に検証を挟む、といったチームの規律を自動化する仕組みです
Steering（プロジェクト知識の常備）：プロダクトの概要、技術スタック、リポジトリ構成などをMarkdownファイルとして所定のフォルダに置いておくと、エージェントが参照します。基本の文書は常時読み込まれ、条件に応じた読み込み方式も選べます。プロジェクトの前提を毎回説明し直さなくて済むようにする、コンテキストエンジニアリングの製品実装です

いずれも、個人の腕前ではなく「工程と規律」でAIの品質のばらつきを抑える、という設計思想で貫かれています。

似たツールとの違い

Cursorなどの汎用AI IDEとの違い：汎用AI IDEにも計画を立ててから実装する機能は広がっていますが、Kiroは要件・設計・タスクの3文書化と承認ゲートを標準フローそのものに据えています。個人の開発速度を上げる道具と、チーム開発の工程を整える道具、という性格の違いです
Spec Kitとの違い：GitHubのSpec Kitは、同じ仕様駆動のワークフローを各種エージェント（Claude CodeやCopilotのほか、Kiro自身も対応先に含まれます）に後付けするツールキットです。Kiroは仕様駆動をIDE本体に組み込んだ製品であり、外付けの型か、内蔵の標準フローか、という違いになります
AI-DLCとの関係：AWSが提唱する開発方法論AI-DLCは、公開されているワークフロー定義をKiroの設定として取り込める形になっており、Kiroはその代表的な実践ツールにあたります

実務での使いどころと注意点

Kiroが効くのは、仕様の確定に価値がある開発です。まとまった機能の新規開発や、複数人での並行開発では、要件と設計が文書として残ること自体が、レビューと引き継ぎの資産になります。 AWS中心のインフラで開発している組織にとって、ベンダーの連続性も選定理由になります。

注意点は4つあります。

小さな修正には冗長：数行のバグ修正にまで文書化フローを通すと、オーバーヘッドの方が大きくなります。実務者の検証記事でも、小さな修正には冗長すぎるという指摘が出ています。定型修正は通常のチャット指示で、まとまった開発だけSpecsで、という使い分けが前提です
既存の複雑なコードベースとの相性：バグ修正用や設計から入るスペックの型も追加されていますが、文書と実態が乖離した歴史の長いコードベースでは、その乖離を埋める作業が先に必要です
拡張機能の制約：VS Code本家のマーケットプレイスは使えず、既定では互換のOpen VSXから導入します。依存している拡張機能がある場合は、移行前の確認が必要です
クレジット制の見積もりにくさ：料金は操作量に応じたクレジット消費で、使うモデルによって消費倍率が変わります。チーム導入時は、小規模に使って消費傾向を実測してから人数分を見積もるのが安全です

「規律を製品で買う」という選択肢

Kiroが提起しているのは、AIコーディングの品質を個人のスキルに頼るか、工程の規律で抑えるか、という問いです。仕様の文書化や実装前の承認は、運用ルールとして人間に課しても形骸化しがちですが、Kiroはそれをツールの標準フローとして強制します。

すでにVS CodeやCursorで回っているチームが乗り換えるべきかは、開発の中身によります。プロトタイプ中心なら現状維持で足り、仕様の曖昧さによる手戻りが繰り返し起きているなら、試す価値があります。無料枠で仕様駆動のフローを一巡させ、自分たちの開発に「実装前の承認ゲート」が合うかを確かめるのが、堅実な入り口です。