KIRO 活用セミナー 2026 Kiro入門 仕様駆動開発で変わる AI時代の開発スタイル クラスメソッド株式会社 クラウド事業統括本部 山口優 

自己紹介 所属 クラウド事業統括本部 コンサルティング部 名前 山口 優（ぐっさん） 業務 AWS環境構築支援／オンプレミスからの移行支援 など 趣味 旅行・音楽 2 

こんな経験、ありませんか？ AIに書かせるようにしたのに、 なぜかチームは、 前より忙しい。 AIはコードをいくらでも生成する。でも、その大量のコードを動かすには 誰かのレビューが要る。 しかも同じAIを使っても、人によってコードの質はバラバラ。 そのばらつきが、レビューをさらに重くする。 「書くこと」は速くなったのに、チームで正しく決めて進む負荷は、むしろ増えている 3 

本日のゴール Kiroが速くするのは、 「コードを書くこと」ではなく 「チームとして正しいものを作ること」 なぜそう言えるのか。その「設計意図」が腹落ちして帰っていただくのが、今日のゴールです 「正しい」とは、チームで合意したことと一致していること。 振る舞いは「要件」と、作り方は「規約」と一致しているか 4 

今日お話しすること チームの生産性を蝕む正体 01 手戻り・統制コスト・属人化という3つの課題 02 Kiroとは 仕様駆動開発という考え方と、それをツールにしたKiro Spec／Steering／Hooks 03 3つの機能が、それぞれの課題にどう効くか 04 得られる効果 チームのコスト構造がどう変わるか 5 

01 / PROBLEM チームの生産性を蝕む正体 AIを使っていても、使っていなくても、チームの生産性を蝕むのはこの3つ 01 手戻り 仕様の曖昧さ・認識ズレがコードになってから発覚し、作り直す 統制コスト 02 規約・設計方針を守らせるためのレビュー往復と指摘。人が増えるほど増える 03 属人化 なぜそう作ったかが人の頭の中にしかなく、引き継ぎ・オンボーディングが重い コードを書く速さは、「チームの生産性」のごく一部でしかない 6 

な ぜ 「 書 く こ と 」 を 速 く して も 、 こ の 3 つ は 消 え な い の か AIとの協働で失敗するときの正体は、 たいてい 「意図の誤解」 何を作るべきかが曖昧なままコードにすると、 速く書けるほど、速く間違える。 手戻りも、統制コストも、属人化も、根っこは同じ。 意図が「コード」の中にしか無いこと 7 

仕様駆動開発とは 「頭の中の意図」を、 AIに渡せる形に先に固める 人間はコードではなく仕様で意思決定する 人間の責務は「決めること」と「レビューすること」 AIの役割は「提案すること」と「実行すること」 8 

02 / KIRO Kiroとは Kiro さきほどの考え方を、誰でも・全員が同じ進め方で実践できるようにした、仕様駆動開発のフォーマットが揃ったAIコーデ ィングツールです 💻 VS Codeベース（見慣れた操作感） ☁️ AWSが開発 🔌 MCP対応（社内ツール・データ連携） 🧠 複数のAIモデルから選択可 中核となるのが、3つのペインにそれぞれ効く次の3つの機能 📋 Spec 仕様駆動開発のワークフロー Requirements → Design → Tasks 🧭 Steering チームの規約・文脈をAIに渡す ＝協働の前提知識 🪝 Hooks 定型チェックの自動化 運用中も品質を守る番人 手戻りはSpecが、統制コストはSteering／Hooksが、属人化は仕様の資産化が、それぞれ引き受ける 9 

02 / KIRO 4つの形態｜今日はIDEを中心に Kiro自体は4つの形態で使えます。このセッションでは、そのうちKiro IDEを中心にお話しします 💻 Kiro IDE 仕様駆動開発の中心 3本柱をフル活用できる ⌨️ Kiro CLI ターミナルの エージェント 実装支援・自動化・CI連携 🌐 Kiro Web 📱 Kiro iOS プレビュー中 プレビュー中 ブラウザから エージェントに タスクを委任 スマホでエージェントの セッションを 管理・承認 仕様駆動開発を体験するなら、まずIDEから。CLI・Web・iOSは普段の環境を補完する位置づけ 10 

02 / KIRO Kiro IDEの画面｜主に3つのエリア 🗂️ 左｜ファイルツリー .kiro/specs配下にrequirements.md／ design.md／tasks.mdが並ぶ 📝 中央｜エディタ 今どのステップを見ているかがナビゲーション で分かる 💬 右｜Kiroとの対話 チャットでやり取りしながら仕様・設計・タス クを進める 11 

03 / SPEC Spec｜仕様の3ステップ＋実装で進める開発フロー チームの生産性を削るのは手戻り・統制コスト・属人化。Specがまず狙うのは、この「手戻り」 1 Requirements 要件をAIと固める ▶ 人間のレビュー 2 Design 設計をAIと固める ▶ 人間のレビュー 3 Tasks タスクに分解 ▶ 人間のレビュー 4 実装 AIが実行・人間が検収 各ステップの間に、必ず人間のレビューゲートがある（決めるのは人間、提案・実行はAI） 手戻りの正体は「仕様の曖昧さ」。コードになってから直すのではなく、仕様の段階で舵を切る 12 

03 / SPEC Specが効く理由｜資産として残るから、属人化を防げる 📄 大規模開発で仕様書をきちんと管理したい企業にも効く。改修もSpec更新から始めれば、仕様と実装が乖離しない 統一フォーマットで仕様書が資産として残る 🔍 人員が入れ替わっても、後からプロセスを追える 「なぜこうなったか」が仕様に残るので、属人化・ブラックボックス化を防げる Specは納品物ではなく、運用の起点 13 

04 / OPS Steering／Hooks｜統制コストを「仕組み」で下げる 🧭 Steering 🪝 Hooks 例：コーディング規約／技術スタック／ドメイン用語集 例：Lintチェック／テスト自動実行／セキュリティスキャン コーディング規約・技術スタック・ 業務ルールを共有 IDE以外の形態からも同じ前提知識を参照できる 保存時・コミット前などのタイミングで 定型チェックを自動実行 Specで決めた基準を、実装後も守り続ける 規約を守らせるのはレビュアーの根気ではなく、リポジトリにコミットされたルール 14 

04 / OPS Hooksの画面｜自然言語で頼むだけで設定が完成する 今回のデモでは扱いませんが、Hooksはこんなふうに設定できます 💬 頼んだこと 「保存時にコーディング規約をチェックして」と自然言語で一 言依頼 ⚙️ 自動で埋まった設定 トリガー・対象ファイル・チェック項目・指示文まで自動生成 15 

05 / VALUE 得られる効果｜チームのコスト構造が変わる 📋 手戻りが減る 🪝 品質が個人に依存しない 🧭 資産が残る ← Spec ← Steering / Hooks ← 仕様の資産化 「思ってたのと違う」が、コードになる 前に止まる 規約遵守が、レビュアーの根気ではなく 仕組みで担保される 作った過程（仕様・設計・タスク）がチ ームの資産として残る 本当に嬉しいのは、チームのコスト構造そのものが変わること 16 

Kiroが速くするのは、 「コードを書くこと」ではなく 「チームとして正しいものを作ること」 仕様という形でチームの合意をAIに渡せるから、手戻り・レビュー・引き継ぎのコストごと下がる 次のセッションのデモでは、これが実際に動く様子をご覧いただけます Requirements 要件をAIと固める Design 設計をAIと固める Tasks タスクに分解 実装 AIが実行・人間が検収 17 

06 / REFERENCES 参考文献 Kiro https://kiro.dev/ Kiro and the future of AI spec-driven software development https://kiro.dev/blog/kiro-and-the-future-of-software-development/ Specs just got faster (and smarter) https://kiro.dev/blog/faster-smarter-specs/ Steering https://kiro.dev/docs/steering/ Hooks https://kiro.dev/docs/hooks/ Kiro for iOS https://kiro.dev/mobile/ AWS Amplify Conference 2026 レポート https://aws.amazon.com/jp/blogs/news/aws-amplify-conference-2026/ 本資料の内容は2026年7月時点の情報にもとづきます。Kiroはアップデートが頻繁なため、最新情報は各リンク先でご確認ください。