Kiro触ってみた

AWSが提唱する新しいIDE「Kiro」を実際に触ってみたハンズオン資料です。
「AI coding with spec-driven development」を掲げ、仕様書作成から実装・自動化までAIが支援するKiroの特徴や、Copilot・Cursor・Claudeとの比較、実際に試した際の課題や利点についてまとめています。
第131回NearMe技術勉強会（2025年9月25日）での発表資料。

Transcript

1. 0 Kiro触ってみた 2025-09-25 第131回NearMe技術勉強会 Ryo Omori
2. 1 Kiroとは • 「AI coding with spec-driven development」を提唱するAWSの新しいIDE • Copilot が「コード補完」中心なのに対して、Kiroは「タスクや仕様に基づいて開発フロー全体を支 援」 • 「仕様化・実装・自動化」までAIに支援させる仕組み
3. 2 コア機能 • Specs → 仕様書。User Story と Acceptance Criteriaで構成 • Hooks → ⾃然⾔語でHooksを実装可能 • Chat ◦ Spec → 上述のSpecs をベースとして実装を体系的に⾏う ◦ Vibe → 双⽅向の質疑応答中⼼のセッションであり、より会話的なアプローチ。 • Steering → プロジェクトに関する規約など。Kiroから⾃動⽣成も可能 • MCP連携 → GitHubリポジトリ、Figmaデザイン、外部APIを直接参照可能
4. 3 デモ / ハンズオン例
5. 4 使ってみた感想 • 超仕事が早いメンバーのPRレビューしている気分 • タスク実行後すると詳細なドキュメントとコードがPRとして上がってくるイメージ • （現実はPRのドキュメントはあまり書かれてないし、じっくりコードから読み解かないといけない） • 作る楽しさみたいなものは個人的には皆無 • 人より早いとはいえタスクの実行に10分以上かかり遅く感じる • importをしてないモジュールを利用しているなどのミスも多くテストに何度も失敗 • 同じ様なミスを何度も繰り返していて若干ストレス • エラーが残ったままtask completeになることもしばしば • 手こずる事が多い環境設定まわりのエラー（xxx.configの設定不足など）をサクサク解決してくれ るのは快適 時間かかるし単純な機能でもSpecsが肥大化するし、大規模とまで行かなくとも既存コードでまともに開 発できるのか🤔
6. 5 既存コードで使う場合 • 既存コードからSpecsを作りたい • コード量が多いためSpecsを階層化したい • 随時行われる修正をSpecsに反映したい
7. 6 既存コードのSpecs作成 タスク化は不要ですと指示しても意地でも改善を入れてくる😇 既存コードのapiの一つのSpecs作成を依頼
8. 7 既存コードのSpecs作成 全ての仕様を書き出そうとするのではなくコ アのロジックに集中する。 Design.mdをみてみると /about /contact などコアとならないページが除外されてコア 機能の仕様がまとめられている。 既存コード全体を指定してSpecの作成を依頼
9. 8 Specのディレクトリ管理 /specsの下に design.md requirements.md tasks.md があるとSPECSとして認識されるが
10. 9 Specのディレクトリ管理 ある程度の規模の開発に階層化 して整理したいところだが/specs の下に階層を作るとSPECSとして 認識されない。
11. 10 Vibeセッションで機能追加してSpecsに反映
12. 11 Vibeセッションで機能追加してSpecsに反映
13. 12 既存システムでの運⽤⽅法 Specsの粒度 • コード量が多い場合、⼀度にSpecs作成しようとしても概要レベルのSpecsになる • Contextの上限から考えても、全体を直接読ませるのではなく、部分的に Spec化する必要がある。 ◦ KiroはClaude Sonnet 4を利用。上限: 約 200k tokens。 ◦ 英文ベースでだいたい 15〜20万ワード相当 ◦ ride-apiで27万ワード メンテナンス • 「コード変更 → Specs更新」はできるがコードとSpecsの乖離は発生してしまいそう • 「重要なモジュールのSpecだけ維持する」「定期的なSpecリファクタ」など、何かしら運用ルールが必要。
14. 13 Kiro vs Copilot vs Cursor vs Claude 機能 Copilot Agent Cursor Claude Code Kiro 補完 ◎ インライン補完精度は最 高 ◎ Copilot同等レベル ◯ 普通にできるが補完特化 ではない △ 基本はチャット／ Spec駆 動で、補完体験は弱い チャット ◎ コード意図説明・修正提 案 ◎ プロジェクト横断の依頼 が得意 ◎ 長文のやりとりや大規模 変更に強い ◎ タスク・仕様ベースでの 会話が得意 プロジェクト横断理解 △ ファイル指定が必要 ◎ @workspace で広範囲 参照可能 ◎ Claudeの長コンテキスト で大規模理解可 ◯ Specを分割して整理 リファクタ △ 小規模向け ◎ リポジトリ全体で可能 ◎ 大規模変更も得意（ただ し要指示） ◯ Specに従ったリファクタ は可能だが精度は Spec依 存 仕様駆動 (Spec) × 仕様の概念はない × × ◎ 特徴的。ただし Spec整 備コストがかかる 自動化 (Hooks) × × × ◎ ユニーク。 Lint/Test/Design検証など。 ただし セットアップと学習コ スト高め
15. 14 Kiro vs Copilot vs Cursor vs Claude ツール ビジネス向けプラン名 月額 / ユーザー 備考・条件 GitHub Copilot Copilot Business $19 USD/月/ユーザー 組織向け定額課金。月 単位で請求される。 (GitHub Docs) Cursor Teams $40 USD/月/ユーザー Pro機能 + チーム管理 機能を含む。 (Cursor) Sonnet 4のリクエスト約 225回、Geminiのリクエ スト約550回、GPT 4.1 のリクエスト約650回が （Cursor） Claude Code 従量課金 $80 ~ 130/月/全ユー ザー（実績ベース） Kiro Pro / Pro+ $20 or $40 USD/月/ ユーザー 価格プランがローンチさ れており、従量クレジット 制などを採る方向。 (spr.ly)
16. 15 Kiro vs Copilot vs Cursor vs Claude Copilot • インライン補完による日々のコーディングの効率化 Cursor • IDEベースで日常的な不具合修正や横断的リファクタ Claude Code • 長文コンテキストの理解が必要な大きなタスク、難易度の高いタスク Kiro • コアモジュールをSpec化し開発プロセスを体系化
17. 16 サマリー エンジニアももちろん PdMでも使うイメージは沸いた（こんなに潤沢にお金を使えるかは置いておいて） 1. リサーチ段階（現状把握・調査） • Claude Code • 長文コンテキストに強く、 Specsなしでもシステム全体の挙動を素早く把握できる 　（PdMにCopilot使ってもらってるけどClaudeに乗り換えましょう。従量課⾦だし。） 2. 仕様書化 /PRD作成/実装のDraft作成 • Kiro • 重要モジュールの仕様（ Specs）を自動生成・更新 • User Story / Acceptance Criteria を自動生成でき、PRD作成の土台 • 簡単な機能追加は、そのままチケット化してオフショアや外注に依頼可 • Hooks を活用して仕様とコードの乖離を防止 3. 実装の手直し • Copilot、Cursor • インライン補完 で小さな修正を素早く実装 4. テスト • Kiro、Claude • Kiro HooksでSpecsとコードの差分を検知して自動テストを更新 • リポジトリ横断で機能理解して e2eテストの作成
18. 17 その他の仕様駆動開発ツール リサーチできてないですが Claude Code を使った https://github.com/gotalab/cc-sdd /kiro:steering, /kiro:spec-init, /kiro:validate-gap などの slash コマンドが使えるようになる Githubの https://github.com/github/spec-kit
19. 18 Thank you