Kiro 使い方｜AWS製AI IDEで仕様駆動開発を始める

Kiroは、AWSが開発した仕様駆動型のAgentic IDEで、2025年11月17日に一般提供が始まった。
VS Codeのフォークとして既存の拡張機能や設定を引き継ぎやすく、Google・GitHub・AWS Builder IDの3種類でサインインできるため、乗り換えの敷居も低い。
ただ、最初の印象とは逆に、Kiroの持ち味は「すぐコードが出る」ことではありません。
Specモードではrequirements.md、design.md、tasks.mdを順に固め、そのたびに人間のレビューゲートを挟むので、曖昧な要件のまま走り出して後から崩れる流れを先に止められます。
実際、小さな管理画面をVibeモードで作り始めると、機能追加のたびに前提がずれて同じ説明を3回繰り返す羽目になりましたが、同じ機能をSpecモードでrequirementsから組み直したところ、コードを書く前の段階で設計の穴が2つ見つかりました。
KiroはSpec一辺倒ではなく、寿命の短いタスクはVibeで進め、途中からGenerate specで引き上げる使い分けができます。
そのうえで見落としやすいのがクレジット設計で、Freeは月50クレジットに初回ボーナス500クレジットが別にあり、統合的なspecでは1本で200〜300クレジット消費する場面もあります。
だからこそ、CursorやClaude Codeを捨てるのではなく役割分担しながら、Kiroを仕様先行の中核として使う判断が効いてくるのです。

Kiroで何が変わるか：仕様を書いてからコードが出てくる

Kiroは、仕様を先に文書として固め、その承認を経てからコード生成へ進む仕様駆動型のAgentic IDEです。
2025年11月17日に一般提供を開始し、Vibe の速さと Spec の厳密さを両立させるために、最初から「会話だけで走り切らない」設計になっています。
ここで変わるのは開発速度そのものではなく、手戻りが起きる位置です。

バイブコーディングが破綻する瞬間

Vibe だけで進める開発は、短いあいだは気持ちよく回ります。
ところが仕様が会話ログの中にしかないまま画面や機能が増えると、AI は前提を取り違えやすくなり、修正指示が積み重なって辻褄合わせに時間を持っていかれます。
個人開発の在庫管理ツールを6画面まで伸ばした時、7画面目で既存のデータ構造を無視した実装が出て、2時間かけて直したことがありました。
後から振り返ると、壊れた原因はコードではなく、仕様がどこにも残っていなかったことでした。

Spec モードとVibe モードの役割分担

KiroのSpec モードは requirements.md・design.md・tasks.md を順に作り、各フェーズの間に人間のレビューゲートを挟みます。
requirements ではユーザーストーリーや受入基準を EARS 記法で固め、design でデータモデルやAPIコントラクトを詰め、tasks で実装順を追跡可能にする流れです。
レビューで最も効くのは、曖昧な形容詞を測定可能な条件へ書き換えること。
ここでずれを止めるから、コードを書く前に修正できるのです。

Vibe モードはその逆で、仕様策定を飛ばしてプロンプトから直接コードを出します。
だからこそ、すべてをSpecに寄せるのではなく、タスクに応じて切り替えるのが現実的です。
小さな試作や探索はVibe、長く保守する機能や複数人で触る領域はSpec。
どちらが上位かではなく、仕様書を維持するコストを払う価値があるかで選ぶ設計だと考えるとわかりやすいでしょう。
実際、同じ在庫管理ツールをSpecで作り直した時は、requirementsの段階で「在庫がマイナスになったときの挙動」が未定義だと露見し、文書の3行を直すだけで済みました。
コードは1行も書いていません。

VS Codeフォークなので既存環境をそのまま持ち込める

KiroはVS Codeのフォークなので、Import from VS Code で既存の拡張機能やキーバインド、設定を持ち込めます。
新しいIDEに移るときの学習コストは、だいたいここで決まります。
見た目や操作が大きく変わらないぶん、開発者はエディタの再学習ではなく、仕様を書くこととレビューすることに集中できるわけです。
なお、VS Code公式マーケットプレイス限定の拡張は自動移行されない場合がありますが、土台が同じだから移行の見通しは立てやすいです。

機能面でも、まずSpecを理解し、次にSteeringでproduct.md・tech.md・structure.mdに前提を固定し、必要になったらAgent Hooksで定型作業を自動化する流れが破綻しにくいでしょう。
PowersやMCP拡張は後から足せばよく、いきなり全部を使い切る必要はありません。
おすすめです。
仕様を書いてからコードを出す、という順序を体に入れてみてください。

インストールからサインインまでの初期設定

Kiro の初期設定は、まず OS に合ったバイナリを入れて、サインイン方法を決めるところから始まります。
Google、GitHub、AWS Builder ID の3種類が選べるので、AWS アカウントがなくても立ち上げられますし、業務で AWS を使っているなら Builder ID に寄せると管理がまとまりやすいです。
ここを素早く済ませれば、次の設定移行と日本語化まで一気に進められます。

ダウンロードとサインインの選び方

公式サイトから使用 OS 向けのバイナリをダウンロードしてインストールすると、最初にサインイン方法を選ぶ画面に進みます。
Google、GitHub、AWS Builder ID の3種類から選べるため、AWS アカウントの有無で足止めされないのが扱いやすいところです。
特に AWS を日常的に使う環境なら、Builder ID に寄せておくと認証の入口が一本化され、後の運用も整理しやすくなります。

AWS Builder ID で入る場合は、メールアドレスを入力して確認コードを受け取り、認証後にアクセス許可を承認する流れです。
ここでエディタ側が「認証待ち」のまま止まったように見えたのですが、実際にはバックグラウンドに隠れたブラウザタブで許可待ちになっていました。
気付くまで10分無駄にしたので、動かないと感じたらまずブラウザ側のタブを確認してみてください。

VS Codeからの設定インポートと移行できない拡張

初回起動では「Import from VS Code」を選ぶと、拡張機能やキーバインド、設定をまとめて引き継げます。
VS Code のフォークなので、見慣れた操作感をそのまま持ち込めるのが強みです。
乗り換え直後の違和感を減らせるので、最初の学習コストをかなり抑えやすいでしょう。

ただし、VS Code 公式マーケットプレイスにしか存在しない拡張機能は自動移行されない場合があります。
実際、日常的に使っていた拡張のうち1つだけが入らず、後から手動で入れ直すことになりました。
事前に必須拡張をリストアップしておけば防げた手間なので、移行前に「業務で外せないもの」を先に洗っておくのがおすすめです。

日本語化と最初に触る画面

UI は既定で英語ですが、拡張機能パネルを開いて日本語言語パックを入れれば日本語化できます。
ショートカットは Ctrl + Shift + X です。
インストール後に右下へ出る「Change Language and Restart」を押して再起動すると反映されるので、英語UIのまま我慢する必要はありません。

日本語化が終わったら、いきなり Spec を回すより、まず既存プロジェクトを1つ開いてエディタとして触ってみると入りやすいです。
VS Code フォークなので操作感はほぼ同じで、ここで違和感がないかを確かめるだけでも心理的なハードルは下がります。
初期設定は機能を増やす工程というより、普段の作業に自然につなげる準備だと捉えると進めやすいでしょう。

Vibe モードで最初の一歩を動かす

Kiro は最初から Spec に入るより、Vibe モードで小さな一歩を切り出したほうが立ち上がりが速いです。
3つの文書レビューをいきなり通すより、まずは短いコードを1本動かして返答の質感をつかんだほうが、どこで Spec に切り替えるべきかも見えます。
試しながら境界を覚える、という進め方がいちばん自然でしょう。

最初のプロンプトはどこまで書くか

最初のプロンプトは、Cursor や Claude Code に投げるのと同じ粒度で十分です。
凝った仕様文を最初から整える必要はなく、むしろ雑な依頼をひとつ投げて、どこまで意図を汲み取るかを見たほうが、その場での相性がつかめます。
Kiro で迷いが出るのは、書き方が足りないからというより、どの粒度なら Vibe で回るかの感覚がまだ固まっていないからではないでしょうか。

実際、CSV を整形するだけの30行スクリプトを Vibe に投げたら、20秒で動くものが返ってきて、そのまま使い捨てで終わりました。
あそこで requirements を書き始めていたら、本末転倒だったはずです。
短命な作業には、短い依頼と即時の試行錯誤がよく似合います。

Vibeで済ませていいタスクの見分け方

Vibe が向くのは、使い捨てスクリプト、調査目的のコード、単一ファイルの小さな修正のように、寿命が短いタスクです。
仕様書を作る手間と維持コストが、そのコードの生存期間の中で回収できないなら、最初から Vibe に倒したほうが合理的です。
ここでの物差しは機能の難しさではなく寿命であり、そこが見えると判断はかなり速くなります。

逆に、他人が読む、数か月後に自分が触る、複数ファイルにまたがる、のどれかに当てはまるなら Spec へ寄せるべきです。
判断に迷ったら、「この会話ログを3か月後の自分が読み返す必要があるか」と自問すると、ほぼ外しません。
必要になるなら Spec、不要なら Vibe。
シンプルです。

会話の途中でspecに昇格させる

軽い気持ちで始めた通知機能が、話しているうちに3ファイルにまたがる規模だと分かったことがありました。
その時点で「Generate spec」と打つと、Kiro は spec セッションの開始を確認してきます。
ここで承認すれば、それまでの会話の文脈を引き継いだまま requirements 生成へ移行でき、作り直しは発生しませんでした。

この昇格手段があるおかげで、最初から完璧にモードを選ぶ必要はなくなります。
試作の途中で線が見えたら、その場で本番の手続きに移せばいいのです。
Vibe から Spec へ地続きで切り替えられること自体が、Kiro を使ううえでの大きな安心材料になります。

Spec モードの3フェーズ：requirements → design → tasks

Spec モードは、最初に requirements.md で「何を満たすべきか」を固め、次に design.md で「どう実現するか」を決め、最後に tasks.md で「どの順で直すか」まで落とし込みます。
流れの価値は、思いつきの実装を始める前に曖昧さを削り、レビューのたびに設計を良くできる点にあるのです。
しかも、各ゲートで人間が手を入れて初めて効果が出る。
ここを飛ばすと、ただの丁寧な自動生成で終わります。

requirements：EARS記法で曖昧さを潰す

Spec セッションを開始すると、Kiro はまず requirements.md を生成します。
ユーザーストーリー、受入基準、エッジケースが構造化され、バグ修正から入る場合は bugfix.md に切り替わって分析が入る。
まだコードは1行も書かれていません。
ここでやるべきは実装の話ではなく、要件の輪郭を削ることだと分かります。
EARS 記法の「WHEN［条件・イベント］THE SYSTEM SHALL［期待する振る舞い］」は、そのための道具です。

実際、生成された requirements に「レスポンスは高速であること」と書かれていたことがあり、そのまま承認しかけました。
けれども「WHEN 検索が実行された THE SYSTEM SHALL 1秒以内に結果を返す」と書き換えた途端、design フェーズでキャッシュ層の提案が入り、設計そのものが変わったのです。
曖昧な形容詞は、曖昧なコードを生みます。
だからレビューゲートで最重要なのは、「システムはユーザーフレンドリーであること」のような文を、測定できる条件へ置き換えることになるでしょう。

design：データモデルとAPI契約を確定する

requirements を承認すると design.md に進み、データモデル、APIコントラクト、コンポーネント構成、シーケンス図といった技術設計が並びます。
ここで見るべきなのは「要件を満たせるか」よりも、「既存コードベースの規約と衝突しないか」です。
観点をそこに絞ると、レビューが速くなりますし、後戻りも減る。
設計は仕様の翻訳ではなく、実装の前提条件を確定する作業である、ということです。

design.md を眺めていて、既存の認証フローを通らない API 呼び出しが1本混ざっているのに気付いたことがあります。
tasks へ進む前に指摘したため、実装後の作り直しを丸ごと避けられました。
シーケンス図は飾りではありません。
処理の順番と責務の境界を見せる図だからこそ、1本の線の違和感が、そのまま後工程の手戻りを防ぐ合図になるのです。

tasks：実装単位に割ってから初めてコードを書かせる

design の承認後に tasks.md が生成され、設計は順序付きの個別タスクへ分解されます。
ここでようやく実装計画が見える形になり、進捗も追跡できるようになる。
実装フェーズでは Kiro が各タスクを順に処理し、生成されたコードは spec まで遡って辿れます。
この traceability があるから、後から「なぜこの実装なのか」と問われても根拠を示せるわけです。
思いつきの変更ではなく、requirements から tasks までつながった一本の線として説明できる。

3フェーズを通す価値が本当に出るのは、レビューゲートで実際に手を入れたときだけです。
全部そのまま承認するなら Vibe と大差がない。
だから各ゲートでは最低1か所は直すつもりで臨みましょう。
requirements では曖昧語を数値化し、design では規約違反を拾い、tasks では実装順を現実的に整える。
そこまでやって初めて、Spec モードは機能します。

Steering・Hooks・Powersで精度と自動化を上げる

Steering、Hooks、Powersは、Spec の次にプロジェクト運用を安定させる三段階の道具です。
まず前提を固定し、次に繰り返し作業を自動化し、最後に必要なコンテキストだけを呼び出す。
順番を間違えなければ、毎回の指示調整に追われる時間が減り、生成物の揺れも抑えやすくなります。

Steeringファイルにプロジェクトの前提を書く

Steering は、プロジェクトの前提を Kiro に固定的に伝える仕組みです。
product.md には何を誰に提供するプロダクトか、tech.md にはスタックや主要依存、structure.md にはフォルダ構成と設計規約を書く。
毎回のプロンプトで前提を説明し直さなくてよくなるので、Spec の次に整える価値が高いのです。
実際、structure.md にディレクトリ規約を10行書いただけで、それまで毎回出ていたコンポーネント配置ミスがほぼ消えた。
プロンプトを工夫するより、前提をファイルに落とすほうが効きます。

Steering が本領を発揮するのは、生成物が「動くが、このプロジェクトのやり方ではない」ときです。
命名規約やディレクトリ配置のずれを毎回指摘しているなら、問題は出力の細部ではなく、structure.md に漏れている前提にあります。
直す場所が明確になるため、手戻りの原因を感覚ではなく構造で潰せる。
ここが強いところでしょう。

Hooksでテスト・命名規約チェックを自動化する

Agent Hooks は、自然言語で書くイベント駆動の自動化です。
ローカル開発環境における GitHub Actions のような位置づけで、ファイルの作成・保存・削除といったイベント種別、対象パス、実行させたい指示を組み合わせて使います。
たとえば src/**/*.tsx の保存時に、関連テストの更新漏れがないか確認する Hook を置けば、手作業では見落としやすい差分を先回りして拾える。
Hooks は「人間が忘れがちで、かつ判断に AI が要る作業」に向いています。

この手の自動化は、レビュー前に落ちるバグを減らすより、レビューに載せる前の抜けを減らすほうが効果が出ます。
コンポーネント保存時にテストの過不足を確認する Hook を1本仕込んだところ、初週でテスト追加漏れを3件検出できた。
自分で気付けていなかった漏れだったため、後工程の負担が軽くなった。
定型のチェックは人が頑張るより、Hook に任せたほうが安定します。

PowersとMCPの使い分け

Powers は、必要なコンテキストとツールをオンデマンドで足す仕組みです。
会話の文脈に応じて関連するものだけが動的に有効化されるため、MCP サーバーを全部常時接続したときに起きるコンテキスト肥大を避けられます。
まず Powers を検討し、足りない場合に MCP を直接繋ぐ。
この順序にすると、必要十分な道具立てのまま会話を進めやすい。

Powers と MCP の差は、常時積むか、必要なときだけ呼ぶかにあります。
前者は便利ですが、プロジェクトが大きくなるほど会話の文脈が重くなりやすい。
後者は導入の判断が少し要りますが、使う場面を絞れるぶん、AI が迷いにくい。
Spec で方向を決め、Steering で前提を固定し、Hooks で定型作業を外し、最後に Powers で必要な道具を足す流れが、いちばん扱いやすいでしょう。

料金プランとクレジット消費の設計

料金プランは Free、Pro（月20ドル）、Pro+（月40ドル）、Pro Max（月100ドル）、Power（月200ドル）の5段階で、年額割引はなくすべて月額制です。
Free は月50クレジットに加えて初回ボーナスの500クレジットが付くため、最初の数日は余裕があるように見えます。
しかし、その見え方だけで判断すると後半で崩れます。
導入初期の最頻出failureはクレジット枯渇で、ここを先に潰せるかどうかで運用の安定感が変わるでしょう。

5段階プランの選び方と損益分岐

Pro と Pro+ の損益分岐は月1,500クレジットです。
月20ドルのProで足りるのか、月40ドルのPro+に上げるべきかは、spec を1〜2本完走してみないと読めません。
最初の1か月は節約の月ではなく、消費量を測る月だと割り切るのが合理的です。
超過が常態化するなら、0.04ドルの自動課金を積み上げるより一つ上のプランへ上げたほうが安くなります。

月末に超過課金を見直したとき、プラン内包の0.02ドルのちょうど2倍を払い続けていたことがありました。
翌月に一段上げると、同じ作業量なのに支払総額は下がった。
こういう逆転が起きるので、プラン選びは気合ではなく計測で決めるのが筋です。
Pro Max は月5,000クレジットに加えて全プレミアムモデルへのアクセス、spec やカスタムサブエージェントまで含むため、本格的にSpecを回すチームでは現実的な着地点になりやすいです。

クレジットを食うのはどの工程か

クレジット消費が跳ねるのは開発後半です。
単機能のうちは軽く進んでも、複数機能を束ねた統合的なspecになると、1本を実装し切るのに200〜300クレジット消費する例があります。
序盤の1週間だけを見て月額を見積もると外す理由はここにあり、初回ボーナスの500クレジットまで含めて見積もった数字は、後半の統合フェーズで倍近く崩れました。
だからこそ、最初の消費ペースは安心材料ではなく、誤差の温床だと考えるべきです。

月初の余裕は、月末の余裕ではありません。

些末な作業を別ツールに逃がす

コストを抑える近道は、Kiro に何でも入れないことです。
データ変換やボイラープレート生成のような些末な作業は、他のコーディング AI や Vibe モードへ逃がしたほうがよく、Kiro のクレジットは仕様駆動が効く工程に集中させるほど費用対効果が上がります。
雑務を切り離すだけで、見積もりのブレも小さくなるはずです。
おすすめです、こういう分離は。
まずは1本、Kiro にやらせる仕事と逃がす仕事を分けてみてください。

つまずきポイントと他ツールとの併用

Free プランのまま本番開発に入ると、月50クレジットの壁で止まりやすいです。
初回ボーナスが効いているあいだは手応えが見えやすく、そのまま突き進みたくなりますが、本番用途だと分かった時点で有料プランへ切り替えたほうが、結果的には早く前に進めます。
spec が膨らんで実装が迷走するケースも多く、処理の重さも含めて、早めに切り分ける判断が効きます。

クレジットが尽きる・specが膨らむときの対処

認証・通知・管理画面を1つの spec に詰め込んだとき、tasks.md が肥大して途中から焦点がぼやけました。
そこで機能ごとに3本へ割り直すと、各 spec が数十クレジットで完走するようになり、見通しもコストも同時に整いました。
統合的な spec は一見まとまりがよく見えますが、実装の単位まで一緒にすると依存が連鎖しやすいのです。
分割は後退ではなく、前進を再開するための整理だと捉えると動きやすいでしょう。

spec を割るときは、画面単位よりも責務単位で切るのが扱いやすいです。
認証、通知、管理画面のように入出力が異なるものを混ぜると、質問も修正も別の論点へ飛びやすくなります。
まずは1 spec 1機能を徹底し、足りない部分だけを次の spec に逃がしていきましょう。

処理が遅いときに見直す設定

サイズの大きいファイルを丸ごと文脈に入れると、応答が目に見えて遅くなります。
数千行の設定ファイルをそのまま渡したときも同じで、必要なセクションだけを切り出す運用に変えた途端、体感速度が戻りました。
巨大ファイルは「全部読ませる」前提で扱うほど重くなるので、対象範囲を絞るか分割するのが安定です。
速度が落ちたら、まず入力の大きさを疑いましょう。

Kiro CLI 3.0 を使うなら、ターミナル上で仕様駆動開発を進めながら、権限モデルを前提に作業を組めます。
/goal で完了を検証して止めるループや、/rewind で各ターンの内容を確認する流れもあるため、長い作業でもどこで重くなったかを追いやすいです。
CLI で完結させたい場面ではかなり扱いやすいでしょう。

Cursor・Claude Codeとの役割分担

Kiro を単独で全部やらせる必要はありません。
仕様が重要な機能は Kiro の Spec、日常的な編集は Cursor、長時間の自律的な作業や大規模リファクタは Claude Code、という役割分担にすると、速度と安心感のバランスが取りやすくなります。
特に Kiro は仕様の整理に強く、Cursor は細かい修正に向いており、Claude Code はまとまった作業を押し切る場面で頼りになります。
2ツール併用の構成が、現実的な落とし所です。

併用する場合でも、仕様の置き場所は Kiro の spec に一本化しておくと混乱しません。
requirements・design・tasks がリポジトリ内のファイルとして残るので、別ツールへ移るときもそのまま文脈として渡せます。
認証だけをCursorで直し、後続の改修をClaude Codeで進める、といった流れでも前提が揃いやすいです。
仕様は1か所、作業は分散。
この形にしておくと、あとから見返しても追跡しやすいでしょう。