KiroとCursorの違いを先に確認
| 比較軸 | Kiro | Cursor |
|---|---|---|
| 中心体験 | 仕様から実装へ進む | エディタ内で対話・編集する |
| 主な成果物 | 要件、設計、タスク、コード | コード、チャット履歴、ルール |
| 文脈管理 | Steering、AGENTS.md | Rules、AGENTS.md |
| 自動化 | Hooks、Web Specs | Agent、Background Agents |
| 向く変更 | 新機能、複数工程 | 日常編集、調査、修正 |
どちらもエージェント型IDEだが、Kiroは「何を作るかを固定する工程」、Cursorは「コードを見ながら進める工程」に強みがある。
検証1. Specsは何を作るのか
KiroのSpecsは、機能開発を3つの成果物へ分ける。
| 成果物 | 内容 | レビューする人 |
|---|---|---|
requirements.md | ユーザーストーリー、受け入れ条件 | PM、利用部門、開発者 |
design.md | アーキテクチャ、データ、API、例外処理 | テックリード、開発者 |
tasks.md | 実装順序と完了条件 | 実装担当者 |
Feature Specでは、新機能の要求を整理してから設計とタスクへ進む。Bug Specでは、現在の不具合、期待する動作、変えてはいけない挙動をbugfix.mdへ残す。
Quick Specは、3工程を短くまとめる。小さな変更まで重い承認フローにしないための選択肢である。
検証2. 曖昧な要求を減らせるか
仕様駆動の利点は、AIが正しいコードを書くことではない。人間同士でも曖昧だった要求を、実装前に発見できることだ。
たとえば「記事の予約公開を追加する」という要求には、次の未決事項がある。
- タイムゾーンは何か
- 公開時刻を過ぎた失敗ジョブをどう扱うか
- 編集中に公開時刻を迎えたらどうするか
- 下書きへ戻したときにキャッシュをどう消すか
- 誰が予約を変更できるか
| 進め方 | 問題が見つかる時点 | 手戻り |
|---|---|---|
| すぐ実装 | テスト・レビュー・本番 | 大きくなりやすい |
| Specs | 要求・設計レビュー | 小さくしやすい |
Kiroは要求を完全にするわけではない。曖昧さをMarkdownへ出し、人間が指摘できる状態にする。
検証3. Steeringはチームの前提を保てるか
KiroのSteeringは、プロジェクトの目的、技術スタック、構成、規約をMarkdownで保持する。
基礎ファイルは次の3つだ。
product.md：何を誰のために作るかtech.md：フレームワーク、ライブラリ、制約structure.md：ディレクトリ、命名、設計パターン
さらに、ファイルパターンに応じて読み込む規約や、必要時だけ呼ぶ手順書を追加できる。AGENTS.mdにも対応する。
| 文脈の種類 | 読み込み方 |
|---|---|
| 全体規約 | always |
| 特定ファイル用 | fileMatch |
| 必要時だけ | manual |
| 内容から自動判断 | auto |
すべてを毎回入れると、重要な規則が埋もれ、トークンも消費する。規約を分割して、適用範囲を狭く保つことが効果を左右する。
検証4. Hooksは自動化に使えるか
KiroのHooksは、エージェントやツールの実行前後に処理を挟む。
| タイミング | 用途例 |
|---|---|
| エージェント開始 | 関連ドキュメントを読み込む |
| ツール実行前 | 禁止コマンドや秘密情報を検査する |
| ツール実行後 | フォーマット、テスト、ログ保存を行う |
| タスク完了 | 成果物と未完了項目を確認する |
自動化は便利だが、Hook自体がコード実行点になる。設定ファイルのレビュー、実行ログ、失敗時の扱いが必要だ。
FormatterやLintのように決定的な処理はHookへ向く。設計判断のように文脈が必要な作業は、人間のレビューを残したほうがよい。
検証5. Cursorより遅くならないか
小さな変更では、Specsの作成が追加作業になる。
| タスク | Kiro Specs | Cursor Agent |
|---|---|---|
| 文言修正 | 過剰になりやすい | 速い |
| 1ファイルのバグ | Quick Specまたは直接修正 | 速い |
| 新しいAPI | 要求・設計が効く | 対話で進めやすい |
| 複数チームの機能 | 成果物を共有しやすい | ルール設計が必要 |
| 長期保守 | 判断履歴が残る | コードと履歴を別に整理 |
Kiroをすべての変更に使う必要はない。
- 30分以内の明確な修正は直接実装
- 要件に複数の解釈があるならQuick Spec
- DB、API、UIをまたぐならFeature Spec
- 再発防止が重要な障害はBug Spec
工程を増やすかどうかは、変更の大きさより「間違えたときの手戻り」で決めたい。
検証6. 料金とモデル選択はどう違うか
Kiroはクレジット制で、2026年8月時点の個人向けプランはFreeからPowerまで用意されている。
| プラン | 月額 | クレジット |
|---|---|---|
| Free | 0ドル | 50 |
| Pro | 20ドル | 1,000 |
| Pro+ | 40ドル | 2,000 |
| Pro Max | 100ドル | 5,000 |
| Power | 200ドル | 10,000 |
有料プランではClaude SonnetやOpusなどのプレミアムモデルを利用でき、追加クレジットは1クレジット0.04ドルと案内されている。国・地域により利用可能モデルは異なる。
Cursorは各プランにモデルAPI利用枠を含み、選んだモデルのAPI単価で消費量が変わる。どちらも月額だけ見ればよいわけではない。
| 確認項目 | Kiro | Cursor |
|---|---|---|
| 使用量の単位 | クレジット | モデルAPI利用額 |
| 無料枠 | あり | あり |
| 超過 | 追加クレジット | プラン・設定による |
| モデル | プランと地域で異なる | モデル選択で消費が変わる |
月に何回プロンプトを送るかではなく、長いSpecsと実装を何本回すかで試算したい。
検証7. Web Specsで非同期開発できるか
Kiro Webでは、ブラウザからリポジトリを選び、Specを作り、実装タスクを実行し、プルリクエストを開ける。
流れは次のようになる。
- 対象リポジトリを選ぶ
- 要求を入力する
- 要件、設計、タスクをレビューする
- 全タスクまたは一部を実行する
- 差分とテスト結果を確認する
- プルリクエストをレビューする
複数リポジトリを一つのSpecで扱える点は、APIとフロントエンドが分かれたシステムに向く。
ただし、クラウド実行では秘密情報、外部通信、依存サービスをどう再現するかが課題になる。本番データや強い権限を渡さず、テスト用環境で完了できるタスクから始めたい。
KiroとCursorのどちらを選ぶか
| Kiroが向く | Cursorが向く |
|---|---|
| 要求の曖昧さが手戻りになる | 変更内容が明確 |
| 設計判断を文書で残したい | コードを見ながら早く進めたい |
| PM・設計者もレビューする | 開発者中心で完結する |
| 複数リポジトリを変更する | エディタ内の作業が中心 |
| 仕様とPRをつなげたい | 補完、編集、調査を日常的に使う |
二者択一にする必要はない。仕様が重い機能はKiro、日々の編集はCursorという分担も成立する。
選ぶ基準は、コード生成の速さではなく「レビューしたい対象がコードだけか、要求と設計も含むか」である。
よくある質問
KiroはAWSのサービスですか
KiroはAWSが提供するエージェント型開発環境で、個人向けアカウントやAWS Builder IDから利用できる。企業向けにはAWS IAM Identity Centerを使う管理機能も案内されている。
KiroのSpecsは毎回必要ですか
必要ない。小さな修正は直接対話し、曖昧さや影響範囲が大きい変更でSpecsを使う。Quick Specで工程を短縮することもできる。
CursorのRulesをKiroへ移せますか
内容はMarkdownとして移せるが、メタデータと適用方式は異なる。AGENTS.mdへ共通規約を寄せ、製品固有設定だけを各ディレクトリへ残すと管理しやすい。
KiroとCursorを併用しても問題ありませんか
問題ない。ただし、両方が同じブランチを同時編集しないようにする。仕様、実装、レビューの担当範囲とGitの作業単位を決めたい。
