Kiroの使い方の整理

Last updated at 2026-04-11Posted at 2026-04-10

作成日：2026年4月11日(土)

１．TL;DR

KiroはAWSが開発した仕様駆動開発（SDD）IDE。VS Codeベースで、macOS・Windows・Linuxに対応。2025年11月にGA（一般提供）開始。
最大の特徴はSpecモード。「何を作りたいか」を自然言語で伝えると、AIが要件定義（requirements.md）→設計（design.md）→タスク計画（tasks.md）→コード生成の順に進める。仕様書はGitで管理でき、チームの監査証跡になる。
開発スタイルは2軸で制御する。①Vibe（即時コーディング）かSpec（仕様駆動）か、②Autopilot（AI自律実行）かSupervised（人間が承認）か。この組み合わせで4つのワークスタイルが生まれる。
料金はFreeプラン（50クレジット/月）〜Powerプラン（$200/月・10,000クレジット） の4段階。初回登録で30日間・500クレジットの無料トライアルあり。Freeの50クレジットはSpecモードの本格評価には不足するため、トライアル期間の活用が現実的。
Spec Drift（仕様実装乖離）に注意。仕様書とコードのズレは構造的に蓄積する。「仕様書があるから大丈夫」という過信は禁物。Agent Hooksによる保存時自動検証・Steering Rulesによるスペックファースト規約・定期的な仕様の棚卸しの3つをセットで運用することが重要。
CursorやClaude Codeと比べ、チーム開発・エンタープライズ・長期保守が必要な場面で真価を発揮する。AIコーディングツールに不慣れなチームへの導入障壁が低く、組織全体への展開を検討するなら有力な選択肢。

２．対象読者

この記事は以下のような方を対象としています。

開発チームへのAI活用導入を検討している開発リーダー・テックリード
自社の開発生産性向上のために新しいツールを調査しているIT企画・AI推進担当者
AIを活用した開発プロセス改善に興味があるプロジェクトマネージャー

Kiroや類似のAI開発支援ツールをまだ使ったことがない方でも読み進められるよう、基本的な概念から順を追って説明しています。

この記事では扱わないこと
実際のコードの書き方やプログラミングの詳細な解説は対象外です。「どんなツールか」「どう活用できるか」という視点で書いています。

３．はじめに

私が所属するIT系企業では、生成AIを事業に活用することが組織のミッションとなっています。しかし実際に導入を推進してみると、開発されるのは「問い合わせチャットボット」ばかり。生成AIの知識をドキュメント作成や開発プロセスそのものに活かす取り組みは、まだほとんど進んでいませんでした。

そんな中で注目していたのが、AIを使ったバイブコーディングの進化です。特にClaude CodeとSpec駆動開発ツールのcc-sddを組み合わせることで、開発チームそのものにAIを組み込み、生産性を底上げできるという手応えを感じていました。

Kiroの存在はAWSが発表した当初から気になっており、すぐにWaitingリストへ登録しました。ただ、その後はcc-sddの調査に時間を取られ、Kiroを本格的に触る機会をつくれずにいました。

転機となったのは、社内の開発チームから「Kiroって使えますか？」という問い合わせを受けたことです。これを機に腰を据えて調査し、この記事にまとめることにしました。

この記事で伝えたいこと
Kiroは単なるAIコード補完ツールではなく、「仕様書を中心に据えた開発プロセス」を実現しようとするIDEです。 この記事では、Kiroがどんな思想で設計されているか、実際の開発フローでどう使うのかを、開発チームへの導入を検討している方向けに整理します。

４．Kiroとは

KiroはAmazon Web Services（AWS）が開発したAIネイティブの統合開発環境（IDE） です。技術的にはVS Code（Code OSS）をベースに構築されており、VS Codeの拡張機能との互換性を持ちます。対応プラットフォームはmacOS・Windows・Linuxの3つで、デスクトップアプリとしてダウンロードして使います。

4.1. 発表から一般提供（GA）まで

Kiroは2025年7月14〜15日に開催されたAWS Summit New York 2025および公式ブログで初めて公開されました。プレビュー期間中は無料で試用でき、2025年11月17日に正式なGA（一般提供）が開始されています。

時期	出来事
2025年7月中旬	AWS Summit New York 2025にてプレビュー版を発表
2025年7〜11月	プレビュー期間（無料で利用可能）
2025年11月17日	GA（一般提供）開始

4.2. 一言でいうと「仕様駆動開発IDE」

Kiroの最大の特徴は「Spec-driven Development（仕様駆動開発、SDD）」と呼ばれる
開発ワークフローにあります。コードを書く前にAIが仕様書・設計書・タスクリストを
自動生成し、人間がレビューしてからコード生成に進む構造になっています。

具体的なステップや実際の操作については、6章で詳しく説明します。

AIモデルにはAnthropicのClaude（Claude Sonnet）をAmazon Bedrock経由で利用しています。

4.3. なぜ今、注目されるのか

2024〜2025年にかけて「バイブコーディング（vibe coding）」という概念が広まりました。CursorやGitHub Copilot、Claude Codeなどを使い、プロンプトから即座にコードを生成するスタイルです。個人開発やプロトタイピングには有効ですが、エンタープライズ環境ではドキュメント不足・設計の欠如・エッジケースの見落とし・コードの保守性低下といった問題が顕在化していました。

Kiroの仕様駆動開発は、この問題に正面から取り組みます。コードを書く前に仕様書と設計書を自動生成し、人間がレビューするステップを組み込むことで、AIが生成するコードの予測可能性・品質・保守性を大幅に向上させます。生成された仕様書はコードと一緒にバージョン管理でき、開発の意思決定プロセスの監査証跡（audit trail） としても機能します。

５．Kiroの２つの軸

Kiroには2つの独立した軸があり、その組み合わせで開発スタイルが決まります。

5.1. 第1軸：開発アプローチ

	Vibe モード	Spec モード
概要	プロンプトからすぐコード生成	仕様書→設計書→タスク→実装の順に進む
向いている場面	プロトタイプ・アイデア検証	チーム開発・本番品質が必要な機能
生成物	コードのみ	`requirements.md` / `design.md` / `tasks.md` + コード

5.2. 第2軸：自律性レベル

	Autopilot	Supervised
概要	AIが承認なしに連続実行	各ステップで人間が確認・承認
向いている場面	大量変更・高速な機能開発	本番コード・セキュリティ関連の変更
特徴	速度重視	安全性・制御性重視

5.3. 4つの組み合わせ

	Supervised	Autopilot
Vibe	会話的に進めながら各ステップを確認。学習・初心者向け	最速のプロトタイピング。AIに丸投げ
Spec	最も厳密な開発スタイル。仕様を作り各実装を確認	仕様に基づく自動実装。大規模機能開発に効率的

この2つの軸の組み合わせを頭に入れておくと、次章以降のKiroの機能説明が格段に理解しやすくなります。

６．Specモードの核心：SDD(仕様駆動開発)

Specモードの開発フローは、大きく5つのステップで構成されます。

① Steering — AIへの前提ルール設定

Steeringとは、プロジェクト単位でAIの振る舞いを制御する設定ファイル（.kiro/steering/に配置するMarkdown）です。コーディング規約・使用ライブラリ・アーキテクチャ方針などを定義しておくと、以降のすべてのAIインタラクションに自動適用されます。CursorやClaude Codeの.cursorrules / CLAUDE.mdに相当しますが、Kiroではより体系的にIDEへ統合されています。

② 要件定義 — `requirements.md`の生成

「何を作りたいか」を自然言語で伝えると、AIがユーザーストーリーや受け入れ基準を含む要件ドキュメントを生成します。開発者はこれをレビュー・編集してから次のステップへ進みます。

③ 設計 — `design.md`の生成

要件に基づき、技術アーキテクチャ・データモデル・APIコントラクト・コンポーネント構造などを含む設計ドキュメントを生成します。

④ タスク計画 — `tasks.md`の生成

設計を具体的な実装タスクへ分解し、チェックボックス形式のタスクリストを生成します。依存関係を考慮した順序で並んでいるため、実装の抜け漏れが起きにくくなります。

⑤ 実装 — タスクに従ったコード生成

AIがタスクリストを1つずつ消化しながらコードを生成します。各タスクが仕様に紐づいているため、「なぜこのコードが存在するか」が常に追跡可能です。

なぜこの流れが価値を持つか
バイブコーディングの「プロンプト→即コード」では、AIが何を根拠にコードを書いたかが残りません。Specモードでは仕様書・設計書・タスクリストがコードと並走してバージョン管理されるため、チームでの引き継ぎ・レビュー・保守のコストが大幅に下がります。これらのドキュメントは .kiro/specs/ 配下にMarkdownとして保存され、Gitで管理できます。

７．実際の開発フロー（具体的な操作）

KiroにはVibeモードとSpecモードの２つの開発スタイルがあります。
それぞれの操作の流れを順に見ていきましょう。

7.1. Vibeモードの流れ（バイブコーディング）

Vibeモードは「とりあえず動くものを作りたい」場面向けの会話型コーディングです。

① チャットを開く
Ctrl+L（Windows）/ Cmd+L（Mac）でチャットパネルを開きます。セッション選択ボタンで Vibe を選択します。

② プロンプトを入力する
作りたいものや修正したい内容を自然言語で入力するだけです。Kiroが「説明を求めているか」「実装を求めているか」を判断して応答します。

例：「Flaskを使ったTodoリストアプリを作って」
例：「この関数のバグを直して」

③ 生成・確認・反復する

Autopilotモードでは承認なしにファイル生成・変更が連続実行されます。「View all changes」でdiff確認、「Revert」で一括取り消しが可能です。
Supervisedモードに切り替えると、ターンごとにファイル変更の承認を求めてきます。

あとは追加プロンプトで会話形式に修正を重ねるだけです。

7.2. Specモードの流れ（仕様駆動開発）

Specモードは本番品質の機能開発向けです。要件→設計→タスクの3フェーズを順番に進めてコードを生成します。各フェーズへの移行は画面上のボタンで行います。「LGTM(Looks Good To Me:承認します)」と入力する必要はありません。

①Specを作成する（共通の起点）

Specを始める方法は2通りあります。

方法	操作
Kiroパネルから	左サイドバーの [Kiroパネル] → [Specs] → [`+`ボタン] をクリック
チャットから	チャットパネル上部のセッション選択で Spec を選択

起動後、Kiroが「Feature（新機能）」か「Bug（バグ修正）」かを尋ねるので Feature を選択します。続いてワークフローの選択肢が表示されます。

ワークフロー	起点	推奨場面
Requirements-First	要件 → 設計 → タスク	機能要件が明確な場合（通常はこちら）
Design-First	設計 → 要件 → タスク	技術アーキテクチャが先に決まっている場合

② 要件フェーズ — `requirements.md` の生成

ワークフロー選択後、チャットに「何を作りたいか」を自然言語で入力します。箇条書きや走り書きで構いません。

例：「ユーザーがメールアドレスとパスワードでログイン・ログアウト・
    パスワードリセットできる認証機能を作りたい」

Kiroは入力をもとに、EARS記法（WHEN [条件] THE SYSTEM SHALL [振る舞い]）でユーザーストーリーと受け入れ基準を含む requirements.md を生成します。内容はdiff表示されるので確認・修正してください。

次のフェーズへ進むには：
チャット下部に表示される 「Move to design phase」 ボタンをクリックします。
追加の修正がある場合はチャットで指示してから押してください。ボタンが表示されるまで、チャットでの追加要件の指示を続けることができます。

③ 設計フェーズ — `design.md` の生成

要件に基づき、コンポーネント構成・シーケンス図・データフロー・APIコントラクト・エラーハンドリング・テスト戦略を含む design.md が自動生成されます。エディタ上部のステップバー（1 Requirements → 2 Design → 3 Task list）で現在のフェーズを確認できます。

design.md の内容を確認し、修正が必要であればチャットで指示するか、ファイルを直接編集します。

次のフェーズへ進むには：
チャット下部に表示される 「Move to implementation plan」 ボタンをクリックします。

④ タスクフェーズ — `tasks.md` の生成

設計をもとに、チェックボックス形式の実装タスクリストが tasks.md として生成されます。タスクは依存関係を考慮した順序で並んでおり、実装の抜け漏れを防ぎます。

エディタ上部のステップバーで 「Task list」 タブをクリックするか、左のフォルダビューから tasks.md を開いて内容を確認します。

実装フェーズへ進むには：
tasks.md を開いた状態になれば、次の実装フェーズへ進む準備完了です。

⑤ 実装フェーズ

タスクの実行方法は2通りです。

方法	操作
個別実行	`tasks.md` の各タスク上部に表示される「Start task」をクリックして1タスクずつ実行
一括実行	「Run all tasks」でキューに入れて順番に自動実行

タスクの実行中は「In Progress」、完了後は「Done」にステータスが自動更新されます。依存関係のあるライブラリのインストールなど、外部への操作が必要なステップでは都度確認が求められます。

生成されたすべてのSpecファイルは .kiro/specs/ 配下にMarkdownとして保存され、コードと一緒にGit管理できます。

⑥フェーズ移行の全体像（まとめ）

Specを新規作成（KiroパネルのSpecs → ＋）
        ↓
Feature / Bug を選択 → Feature を選択
        ↓
Requirements-First / Design-First を選択
        ↓
【要件フェーズ】チャットで機能を説明 → requirements.md 生成
        ↓ チャット下部「Move to design phase」ボタン
【設計フェーズ】design.md 自動生成・確認・修正
        ↓ チャット下部「Move to implementation plan」ボタン
【タスクフェーズ】tasks.md 自動生成・確認
        ↓ tasks.md の「Start task」または「Run all tasks」
【実装フェーズ】コード生成・テスト実行

VibeからSpecへの切り替えパターン
最初はVibeモードでアイデアを壁打ちし、方向性が固まったら「ここまでの内容をSpecに変換して」と指示することでSpecファイルを生成できます。Kiro初心者が段階的に慣れていくための入り口としても有効です。

８．KiroのUI・機能パネル

添付スクリーンショットが示す通り、KiroのIDEは3ペイン構成で動作します。

8.1. 画面の3ペイン構成

エリア	位置	役割
Kiroパネル（左）	左サイドバー	SPECS / AGENT HOOKS / AGENT STEERING & SKILLS / MCP SERVERSへのアクセス
エディタ（中央）	メイン領域	コード・仕様書の編集。Specモードでは要件・設計・タスクのタブナビゲーションが表示される
チャット（右）	右サネル	VibeセッションまたはSpecセッションのAI対話ウィンドウ

左サイドバーのKiroゴーストアイコンをクリックすると（またはショートカット Cmd+L / Ctrl+L）、Kiroパネルが展開されます。パネル内には、SPECS・AGENT HOOKS・AGENT STEERING & SKILLS・MCP SERVERSという4つのセクションが縦に並んで表示されます。

エディタ中央部（Spec編集ビュー）
スクリーンショット中央のエディタには、requirements.md が開かれており、上部に「1 Requirements → 2 Design → 3 Task list」というステップナビゲーションバーが表示されています。これはSpecモード専用のUIで、現在どのフェーズにいるかを常に把握できる構造になっています。右上の「Continue」ボタンを押すと次フェーズへ進み、「Sync Files」ボタンはSpecファイルとワークスペースの同期に使用します。

① SPECS

KiroパネルのSPECSセクションには、プロジェクト内に存在するSpecの一覧が表示されます。スクリーンショットでは spec-change-queue と taberipple という2つのSpecが並んでいます。+ ボタンから新規Specを作成でき、既存のSpecをクリックすると対応する requirements.md / design.md / tasks.md がエディタで開きます。

SPECSパネルとエディタの対応関係：

SPECSパネルで「taberipple」を選択
        ↓
エディタに requirements.md が表示される
        ↓
上部ステップバーで Design / Task list へ切り替え可能

② AGENT HOOKS

AGENT HOOKSは、ワークスペース内の特定のイベントをトリガーにして、AIエージェントのアクションを自動実行する仕組みです。「if-then ロジック」をAIが実行する形で、ファイル保存・作成・削除・編集などのイベントに反応します。

設定ファイルは .kiro/hooks/ 配下に *.kiro.hook 形式で保存されます。

代表的なユースケース：

イベントトリガー	自動アクション例
Pythonファイルを編集	テストファイルを自動更新
機能ファイルを追加	READMEを自動更新
ファイルを保存	コーディング規約への準拠をチェック
AIエージェントがターンを完了	コードをコンパイルして結果をフィードバック

パネル内の「+ Create New Hook」ボタンから自然言語でHookを作成でき、KiroがJSONに変換して設定ファイルを生成します。

③ AGENT STEERING & SKILLS

スクリーンショットでは Workspace の下に product / structure / tech という3つのSteeringファイルが表示されています。これは「Generate Steering Docs」で自動生成された、プロジェクト標準の3ファイル構成です。

SteeringとSkillsは、AIへの「長期記憶」と「再利用可能なワークフロー」を担います。

	Steering	Skills
役割	プロジェクト固有のコンテキストとルールをAIに注入	再利用可能なワークフローをポータブルなパッケージで提供
保存場所	.kiro/steering/（Workspace）または ~/.kiro/steering/（Global）	.kiro/skills/（Workspace）または ~/.kiro/skills/（Global）
適用タイミング	always / fileMatch / manual モードで制御	会話内のキーワードや要求に応じてオンデマンドで読み込み
記述形式	Markdownファイル（front matter付き）	Markdownファイル（open standard準拠）
典型的な用途	コーディング規約・命名規則・アーキテクチャ方針	コードレビュー手順・ドキュメント生成テンプレート

優先順位はWorkspaceレベルがGlobalレベルより上になります。これにより「個人の共通設定はGlobalで管理、プロジェクト固有のルールはWorkspaceで上書き」という運用が可能です。

④ MCP SERVERS

MCP（Model Context Protocol）は、KiroのAIエージェントを外部ツールやデータソースに接続するための標準プロトコルです。スクリーンショットのパネル下部に「Connect external tools and data sources」「Enable MCP」と表示されているのが、MCPサーバーのセクションです。

MCPサーバーの設定ファイルは .kiro/settings/mcp.json（Workspaceレベル）または ~/.kiro/settings/mcp.json（Userレベル）に配置します。

主な機能：
各MCPサーバーの接続状態をパネル上でリアルタイム確認できる
ツール単位で有効/無効を切り替えられるため、AIに渡すツールを最小化してコストを最適化できる
サーバーを右クリックして「Reconnect」「Disable」「Show MCP Logs」などの操作が可能

// .kiro/settings/mcp.json の構成例
{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "..." }
    }
  }
}

各セクションと開発フローの対応
第6・7章のフロー説明を踏まえると、各パネルは開発の「いつ」に対応するかが明確になります。

開発フェーズ	使うパネル	典型的な操作
プロジェクト開始前	AGENT STEERING	Steering Docsを生成してコーディング規約・構成を定義
機能開発（Spec作成）	SPECS	+ でSpec作成 → Requirements / Design / Tasks を順に作成
反復開発中	AGENT HOOKS	保存時の自動テスト更新・ドキュメント同期などを設定
外部連携が必要な場面	MCP SERVERS	GitHub / Notion / DB などのMCPサーバーを接続・管理

９．料金・モデル選択

9.1. プラン体系

Kiroは4つのプランで提供されており、クレジットと呼ばれる単位で利用量が管理されます。

プラン	月額	クレジット/月	実用的な目安
Kiro Free	$0	50	シンプルなチャット問答50回分程度。Specタスクに換算すると10〜20件前後。機能を一通り試すには足りない水準。トライアルの500クレジット（30日間）で機能評価を行うのが現実的。
Kiro Pro	$20	1,000	チャット系なら約500〜1,000回の対話。Spec機能を週5日フル活用した場合（1日10〜20タスク換算）でほぼ使い切る水準。個人開発者の日常用途には概ね十分。
Kiro Pro+	$40	2,000	Proの倍量。Spec駆動で中規模機能を複数本同時に進めるユースケースに対応。「Specモードをメイン開発環境として使いたい」個人・フリーランスに向く。
Kiro Power	$200	10,000	Pro+の5倍量。複数プロジェクトを掛け持ちしたり、Agent Hooksを多用したりするヘビーユーザー向け。1日あたり333クレジットを30日使い続けられる計算。

初めてKiroを登録すると、30日間有効な500クレジットの無料トライアルが付与されます（social login または AWS Builder ID でのサインアップが対象）。有料プランの超過分（Overage）は $0.04/クレジットで、設定でオプトインした場合のみ適用されます。未使用クレジットの翌月繰り越しはありません。

⚠️ Free tierの50クレジットは想定より少ない
Specモードのタスク実行は複数クレジットを消費するケースがあるため、機能の全体像を確認するにはトライアルの500クレジットを活用することをお勧めします。

9.2. クレジットとモデル選択

1クレジットは固定のリクエスト数ではなく、プロンプトの複雑さに応じて0.01単位で消費されます。使用するAIモデルによっても消費量が変わります。

デフォルトは Auto で、Kiroが複数のモデルを状況に応じて使い分けます。意図検出・キャッシュ・専門タスク向けモデルを組み合わせることで、品質・速度・コストのバランスを最適化しています。

以下はAutoを基準（1x）とした場合のクレジット消費倍率の目安です（最新の倍率は公式Pricingページを参照してください）。

モデル	倍率	Free	Pro	Pro+	Power
Auto	1x	〇	〇	〇	〇
Claude Haiku 4.5	0.4x	〇	〇	〇	〇
DeepSeek v3.2	0.25x	〇	〇	〇	〇
Claude Sonnet 4	1.3x	〇	〇	〇	〇
Claude Sonnet 4.5	1.3x	〇	〇	〇	〇
Claude Sonnet 4.6	1.3x	ー	〇	〇	〇
Claude Opus 4.5	2.2x	ー	〇	〇	〇
Claude Opus 4.6	2.2x	ー	〇	〇	〇

Freeプランで選択できるモデルは Auto / Sonnet 4.5 / Sonnet 4 / Haiku 4.5 / DeepSeek v3.2 の5つです。Sonnet 4.6・Opus 4.5・Opus 4.6 はPro以上のプランが必要です。

１０．Kiroの課題と向き合い方

KiroのSpec駆動開発は強力ですが、「仕様書とコードのズレ（Spec Drift）」という構造的な課題を抱えています。これはKiro固有の欠陥ではなく、仕様書を明示的に管理するからこそ可視化される問題です。CursorやWindsurfは形式的な仕様を持たないため問題が表面化しないだけで、見えないところで同じことが起きています。

10.1. 3つの「蓄積するドリフト」

仕様書とコードのズレは、以下の3パターンで静かに蓄積していきます。

ドリフトの種類	内容
増分乖離	バグ修正や軽微な修正でコードを手動編集した際、仕様書を更新しないまま作業を続ける。1回は些細でも積み重なる。
意味的ドリフト	チームの理解が進化するにつれて用語の意味が暗黙的に変わるが、仕様書のテキストは更新されない。
アーキテクチャ侵食	設計時のアーキテクチャと実装後のアーキテクチャが乖離する。

10.2. 3層構造が生む同期コストの爆発

KiroのSpecは requirements.md → design.md → tasks.md の3層構造です。この構造は「仕様→コード」の前方向には強力ですが、コード側の変更が仕様側に自動フィードバックされる逆方向の同期は標準では存在しません。仕様・設計・タスク・コードの4者を常に同期し続けるコストは、開発が進むほど増大します。

10.3. VibeモードがSSoTを破壊する

VibeモードでのチャットベースのコーディングはSpec体系を完全にバイパスします。プロトタイピングでVibeモードを使った後にSpecモードに戻ると、コードと仕様書の間に大きな断絶が生じます。テストが通っていても、検証対象の仕様が古いままという「偽の安心感」 が生まれるのが最も危険な状態です。

10.4. Kiroでの具体的な対処法

対処法① Agent Hooksによる保存時の自動検証

ファイル保存をトリガーに、変更内容と仕様書を自動で突合するHookを設定します。

[Kiroパネル] → [Agent Hooks] → 新規Hook作成

{
  "name": "Spec Drift Check on Save",
  "version": "1.0.0",
  "when": {
    "type": "fileEdited",
    "patterns": ["src/**/*.ts", "src/**/*.py"]
  },
  "then": {
    "type": "askAgent",
    "prompt": "保存されたファイルの変更を .kiro/specs/ 内の関連仕様書と比較し、design.mdの設計と合致しているか、tasks.mdの更新が必要かを確認して、乖離があれば報告してください。"
  }
}

対処法② Steering Rulesによるスペックファースト規約の強制

.kiro/steering/ にルールファイルを置くことで、すべてのAIインタラクションに規約を自動適用できます。

## スペック同期ルール
- コード変更の前に必ず関連する .kiro/specs/ のスペックファイルを確認すること
- スペックから逸脱する変更が必要な場合は、先にスペックを更新してから実装すること
- tasks.md のタスクは design.md の実装に完全に一致するまで完了マークにしないこと

対処法③ 定期的な「仕様の棚卸し」

リアルタイム同期より実用的な方法として、機能完成時やPR作成前に以下のプロンプトでスペックを一括更新します。

src/features/[feature]/ のコードを分析し、
.kiro/specs/[feature]/ のスペックを現在の実装に合わせて更新してください。

対処法④ VibeからSpecへの逆生成

Vibeモードでプロトタイプを作った後、以下のプロンプトでSpecを逆生成できます。

src/features/[feature]/ のコードベースを分析し、
現在の実装を正確に文書化する requirements.md、design.md、tasks.md を生成してください。

10.5. 構造的問題には構造的対策を

課題	対処法
コード変更時の仕様更新漏れ	Agent Hooksで保存時に自動検証
AIが仕様を無視して実装する	Steering Rulesでスペックファーストを強制
Vibeモードとの断絶	機能完成後に「仕様の棚卸し」プロンプトで同期
仕様テストドリフト（偽の安心感）	定期的にスペックからテストを再生成し、古い仕様に基づくテストを排除

Agent Hooksによる保存時検証・Steering Rulesによるスペックファースト規約・定期的な棚卸しの3つを組み合わせるのが、現時点で最も現実的な対策です。

１１．まとめ・所感

11.1. Kiroが提示する「次の開発スタイル」

Kiroを一通り調査して感じたのは、これは単なる「賢いコード補完ツール」ではないということです。仕様書→設計書→タスク→実装という流れをAIと一緒に歩む開発プロセスそのものを変えようとするIDEです。

バイブコーディングが「AIに任せて速く作る」ツールだとすれば、Kiroは「AIと一緒に考えて正しく作る」ツールと言えます。この違いは、個人のプロトタイプ開発ではあまり意味を持ちませんが、チーム開発・長期保守・エンタープライズ環境では大きな差になります。

11.2. 仕様駆動開発を「うのみ」にしない

ただし、Kiroの仕様駆動開発を過信するのは危険です。10章で詳しく述べた通り、仕様書とコードのズレ（Spec Drift）は構造的に発生します。

Kiroが生成する3層の仕様書（requirements.md / design.md / tasks.md）は、あくまで「開発開始時点のスナップショット」です。バグ修正・仕様変更・リファクタリングを重ねるうちに、コードは進化しても仕様書は古いままになっていきます。テストが通っていても、検証対象の仕様が古ければ「偽の安心感」しか得られません。

特に注意が必要なのは以下の3点です。

VibeモードはSpec体系をバイパスする — プロトタイプをVibeで作った後にSpecモードに戻ると、コードと仕様書の間に断絶が生じます
3層構造の同期コストは想定より高い — requirements / design / tasks の3ファイルを常に最新に保つコストは、開発が進むほど増大します
「仕様書があるから大丈夫」という形骸化リスク — 日本の開発現場でよく見られる「存在するが実態を反映しない仕様書」と同じ問題がAI時代にも再発します

11.3. 現実的な使い方の提案

Kiroを導入する際は、以下の3つをセットで運用することをお勧めします。

Agent Hooksで保存時に自動検証 — コード変更のたびに仕様書との乖離をAIがチェックする仕組みを最初から組み込む
Steering Rulesでスペックファーストを強制 — 「コード変更前に必ず仕様書を確認する」というルールをAIに守らせる
機能完成時に「仕様の棚卸し」を習慣化 — PR作成前に「現在のコードに合わせてSpecを更新して」とプロンプトを投げる

仕様駆動開発の価値は「仕様書が存在すること」ではなく、「仕様書が常に現実を反映していること」 にあります。この維持コストを自動化で下げる工夫なしに導入しても、形骸化した仕様書が増えるだけです。

11.4. 自社での活用可能性

社内の開発チームへの導入を検討する観点では、Kiroは 「AIを開発プロセスに組み込む」という目的に最も正直なツール だと感じています。

チャットボット開発に偏りがちな生成AI活用を、開発プロセスそのものへ広げるための入り口として、Kiroは有力な選択肢です。特に「仕様書を書く文化がない」チームにとっては、AIが仕様書を自動生成してくれるSpecモードは、ドキュメント文化の醸成にも貢献できる可能性があります。

一方で、Spec Driftへの対処を組織的に運用できるかどうかが、導入成否を分ける鍵になると思います。ツールを入れるだけでなく、Agent HooksやSteering Rulesを使った「仕様を生きた状態に保つ仕組み」をチームで設計することが、Kiroを本当に活かすための条件です。

11.5. cc-sddとの比較・棲み分け

私がこれまで調査してきたClaude Code + cc-sddとの棲み分けは、おおよそ以下のように整理できます。

	Kiro	Claude Code + cc-sdd
インターフェース	GUI（IDE）	CLI
仕様管理	IDE統合（Specパネル）	Markdownファイル手動管理
対象ユーザー	チーム・エンタープライズ	パワーユーザー・個人
学習コスト	低い（VS Code互換）	高い（CLI操作）
柔軟性	中程度（Kiroのワークフローに沿う）	高い（自由にカスタマイズ可能）

どちらが優れているかではなく、チームの規模・技術レベル・開発スタイルに合わせて選ぶのが正解です。GUIで直感的に使えるKiroは、AIコーディングツールに不慣れなチームへの導入障壁が低く、組織全体への展開を考えるなら有力な選択肢になります。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up