Kiro IDE の Spec モードで、要求分析から実装まで AI にサポートしてもらう（AI-SDD 入門）

はじめに

AI を使った開発というと、チャットで指示しながらコードを書いてもらう「vibe コーディング」を思い浮かべる方が多いと思います。
一方で、最近は 仕様（Spec）を先にドキュメントとして固めてから実装する「Spec Driven Development（AI-SDD）」 という進め方も注目されています。

AWS が提供する Kiro には、この進め方をそのままツール化した Spec モード があります。
今回は Kiro IDE の Spec モードを実際に触り、要求定義 → 設計 → タスク分解 → 実装 → テスト という一連の流れを AI にサポートしてもらいながら進めてみました。
その感想と、良かった点をまとめます。

Kiro IDE とは？

Kiro IDE は、VS Code をベースに、AI サポートを前提として設計された IDE です。
Cursor などの AI 搭載エディタと同じ系統のツールと考えるとイメージしやすいと思います。

利用する AI モデルとして Anthropic Claude などを選べるのも特徴です。

Kiro には CLI 版（kiro-cli）もあり、CLI でも /spec コマンドで Spec ワークフローを使えます。
ただし、執筆時点では CLI 3.0 の Early Access 機能として案内されています。
最新の対応状況は公式ドキュメントでご確認ください。

Spec で作成した requirements.md / design.md / tasks.md は .kiro/specs/ に保存され、CLI と IDE で共有されます。
また、AWS Labs が公開している AI-DLC ワークフローも Kiro CLI / IDE のどちらでも利用できます。

一方、IDE 版では Spec が UI に組み込まれている ため、生成されたドキュメントを画面で確認しながら進めやすいのが利点です。
IDE 版には、次のようなモードがあります。

• Vibe モード
  • その場の会話ベースでコードを書いていくモード
• Spec モード
  • 要求定義 → 設計 → タスク分解 → 実装 → テスト、という流れを、ドキュメントとして整理しながら AI と相談して進めていくモード

今回は、この Spec モード を試しました。

【追記】開発モードがさらに細分化されました

Kiro IDE のアップデートで、開発モードがさらに細分化されました。
執筆時点（2026/08/27）で確認できたモードは次のとおりです。

Spec

構造化された機能開発ワークフローです。
要件 → 設計 → タスクの 3 フェーズを順番に進め、各フェーズの間に承認ゲートがあります。
しっかり設計してから実装したい場合に向いています。

Plan

コードを変更せず、アイデアを実装計画（プラン）に落とし込むワークフローです。
「何をどう実装するか」を先に整理したいときや、実際の作業に入る前に見通しを確認したい場合に使います。

Bug Fix

バグを構造的に扱う専用ワークフローです。
「調査 → 診断 → 解決」という流れで進みます。
再現条件の特定から根本原因の分析、修正の実施まで、一連のプロセスをサポートします。

Quick Spec

Spec の高速版です。
まずエージェントが clarifying な質問をしてから、要件・設計・タスクを一括で自動生成します。
通常の Spec のようなフェーズごとの承認ゲートがなく、手間を減らしてスピーディーに進めたい場合に向いています。

なお、ワークフローを選ばずにそのままテキストを入力すれば、フリーフォームのチャットセッションとしても使えます（旧 Vibe モード相当）。

※ 本記事の以降の内容は、通常の Spec モード を使った検証に基づいています。

Spec モードの全体像

Spec モードでは、実装に入る前に、AI と相談しながら以下の 3 つのドキュメントを作っていきます。

• requirements.md（要求整理）
• design.md（設計）
• tasks.md（タスクリスト）

要求整理・設計・タスク分解を行い、それらをドキュメントとして明示的に残してから実装に進みます。
「まず作って、あとで考える」ではなく、考えるプロセスそのものを AI がサポートしてくれる 点が、このモードの特徴だと感じました。

requirements.md（要求整理）

やったこと

まずは requirements.md で要求整理を行います。
今回は、記事管理を行う Web アプリを題材に、例えば次のような内容を定義しました。

• アプリの目的・ゴール
• 機能要件 / 非機能要件
• AWS にデプロイできること
• フレームワーク選定の方針
• ローカルでデバッグ可能な開発環境
• UI のダークモード対応

など。

良かった点

• 「何を決めるべきか」を AI が質問形式で整理してくれる
• 曖昧な要求に対して「ここ、もう少し具体化しませんか？」と指摘してくれる
• 後工程（設計・実装）を意識した要求整理になる

雑にそのまま実装へ進ませない流れを作れる点が、Spec モードの良さだと感じました。

design.md（設計）

次に design.md で設計を行います。
アーキテクチャやテスト方針などについてこちらからリクエストした内容をもとに、AI が 表や作図 でわかりやすく整理・構造化してくれました。

設計内容の例

• 全体アーキテクチャ
• 使用技術スタック
• Docker を含む開発環境構成
• ソースコードのディレクトリ構成
• コンポーネントごとの責務
• インターフェース定義（Web のフロントエンド / バックエンド間 API など）
• テスト方針（unit / integration など）

設計内容がテキストとして整理されるため、後から見返したり、レビュー時に参照したりしやすい点も便利でした。

Mermaid での作図が便利

設計で特に良いと思ったのが、Mermaid 記法による作図 です。
今回作成したサンプルでは、単純な図だけでなく、構成図・プロセスフロー図・シーケンス図といった少し複雑な図も、内容を伝えるだけで Mermaid を使って作図してくれました。

• 設計レビューでそのまま使える
• 後から見返しても理解しやすい
• 関係者との認識合わせに使いやすい

シンプルな作図例

構成図の例

シーケンス図の例

tasks.md（タスクリスト）

設計がまとまると、tasks.md が生成されます。

タスク分解の特徴

• requirements / design をもとに実装タスクを分解してくれる
• 最初は 必要最小限の構成 になっている
• 一部のタスクは グレーアウト されており、「今回入れるか」「将来対応にするか」を選択できる

最初から盛りすぎない計画になる点が良いと感じました。

実装フェーズで感じたこと

不具合修正が速い

実装中に不具合や想定漏れがあっても、次のように対応してくれます。

• 文脈を理解した上で修正案を出してくれる
• 関連ファイルを含めた修正を提案してくれる

そのため、修正から解決までがかなり速い印象でした。

大規模な変更時には一旦相談が入る

変更量が多くなりそうな場合には、「この変更は影響範囲が大きそうですが、進めて大丈夫ですか？」と一旦確認が入ります。
勢いで進めてしまうのを防ぐガードレールとして、実務的にありがたい挙動だと感じました。

派生開発・仕様変更との相性

派生開発や比較的大きな仕様変更を行う場合でも、既存ドキュメントとは別に、あらためて次のドキュメントを生成して再整理してから進められます。

• requirements.md
• design.md
• tasks.md

大きな要求項目ごとにドキュメントを分けて管理できるため、新規開発だけでなく派生開発とも相性が良いと思います。

これらのドキュメントはすべて Markdown で残ります。
そのため Git でそのまま管理でき、設計変更の履歴確認やレビュー、差分確認がしやすい点も実務的に嬉しいポイントでした。

まとめ

Kiro IDE の Spec モードを使ってみて、次のような印象を持ちました。

• 要求分析や設計をきちんと考える流れを作れる
• ドキュメントが自然に残る
• 仕様変更や派生開発にも対応しやすい
• チーム開発や長期運用との相性が良い

「仕様を先に固めてから実装する」開発フローに慣れている方ほど、一度 IDE + Spec モードを試してみる価値があると思います。