Amazon Web Services ブログ
【資料公開 & 開催報告】Kiro ハンズオン「手を動かして実感する、Kiro が変える開発体験」
アマゾン ウェブ サービス ジャパン合同会社（以下、AWS ジャパン）は、2026 年 9 月 24 日（木）に、AWS ジャパン オフィスで、Kiro のハンズオンイベント「手を動かして実感する、Kiro が変える開発体験」を開催しました。3 時間の中で講義とワークショップを交互に進め、Kiro の仕様駆動開発（Spec）、Steering、Agent Skills、MCP、そして 2026 年 8 月に公開された Kiro Crew までを体験していただきました。定員約 50 名の募集は開催前に満席となり、キャンセル待ちが出るほどのお申し込みをいただきました。
同じ日の夜には、同じ会場で「Kiro Meetup #8」も開催しました（Meetup の開催報告もあわせてご覧ください）。本記事では、ハンズオンの模様をレポートします。
イベント概要
- 開催日時: 2026 年 9 月 24 日（木）14:00〜17:00
- 会場: AWS ジャパン オフィス
- 講師: AWS ジャパン ソリューションアーキテクト 稲田 大陸
ワークショップは AWS Workshop Studio の教材を使いました。教材には全部で 14 のラボがあり、すべて取り組むと丸 1 日かかります。今回は、伝えたい要素を含む 4 つのラボを選び、その間に講義を挟みました。
ワークショップ教材: Kiro – ビルド、運用、変革、そして Kiro Crew の開始方法（AWS Workshop Studio）
オープニング
講師の稲田は、2021 年に AWS に入社し、製造業のお客様を担当しているソリューションアーキテクトです。担当業務のかたわら、Kiro や AI 駆動開発、AWS Amplify など開発者向けサービスの情報発信も行っており、AWS ブログの Kiro 関連記事の多くを執筆しています。
最初に「これだけは持って帰ってほしい」として紹介したのが、Kiro が 9 月 21 日から開催している Kiro University Challenge です。名前に University とありますが大学生に限らず、18 歳以上で条件を満たす方なら参加できます。1 週間にわたって公開される 7 つのレッスンに取り組み、学んだことを使ったプロジェクトを提出すると、5,250 クレジットが付与されます。稲田は「やればやるだけ得するイベント」として、社内の方にも広めてほしいと呼びかけました。
講義: AI が変えるソフトウェア開発と Kiro
前半の講義では、コーディングエージェントの流れを振り返りました。AI によるコーディング支援は、2023 年ごろの 1 行ずつコードを提案する形から、タスクを任せるコーディングエージェントへと進化し、特に 2025 年ごろからはコードを書く主体が人から AI に移ってきました。
コードを書く速さが上がった一方で、仕様をどう伝え、仕様どおりに動かすかには、まだ決まった答えがありません。2025 年 7 月に登場した Kiro は、この課題に仕様駆動開発で応えました。稲田によると、Kiro の登場を伝えた AWS ブログの記事は公開から約 1 か月で 10 万 PV ほど読まれ、そのうち 3 割ほどが日本からのアクセスだったそうです。開発の関心は、プロンプトエンジニアリングからコンテキストエンジニアリングへ、さらに最近はハーネスエンジニアリングやループエンジニアリングへと広がっており、今回のワークショップはその流れに沿って構成しています。
Kiro を使う方法は、Kiro IDE、Kiro CLI、Kiro Web、Kiro for iOS、Kiro Crew の 5 つです。以前は IDE と CLI で使える機能にかなり差がありましたが、最近はほぼなくなり、好きな方法で同じ開発ができます。
Kiro の仕様駆動開発では、requirements.md、design.md、tasks.md の 3 つのファイルを順に作りながら開発を進めます。
ハンズオン: 環境の準備と Web アプリケーションの作成（Lab 2）
参加者は、ワークショップ用の環境に用意した VS Code Server か、ご自身の PC のどちらかを選んで進めました。手元の環境を変えたくない方は VS Code Server を使い、AWS Builder ID、Google、GitHub、IAM Identity Center のいずれかで Kiro にログインします。
最初のラボはウォーミングアップとして、Kiro に「シンプルな HTML の数独 Web アプリケーション」を作ってもらいました。操作ごとに「常に許可」「今回だけ許可」を選べる権限の仕組みや、/ を入力すると 30 個以上のコマンドの一覧が出ることもあわせて紹介しました。できあがったアプリに README を作らせ、先に進んだ方は、UI を強化する詳細な要件を追加で伝えて機能を加えていきました。講師が確認したところ、7〜8 割の方がこの段階で数独アプリを動かせていました。
ハンズオン: 仕様駆動開発（Lab 12）
続いて、同じ数独アプリを仕様駆動開発で作り直しました。Kiro IDE では「〇〇を作りたい」と伝えるとスペックで進めるかを提案してくれます。Kiro CLI では /spec new でスペックモードに入ります。新しい機能を作るか、バグを直すかを選べるほか、requirements、design、tasks の 3 つを一度に作る Quick Spec もあり、社内で時間の限られた勉強会を開くときに便利だと紹介しました。その場合は、モデルを Auto にしておくのがおすすめです。
Kiro が作ったファイルは .kiro/specs/ の下に保存されます。requirements.md は、最初に「グリッド」「セル」などの用語を定義し、ユーザーストーリーと受け入れ基準を対にして書き出します。スペックはプロダクト全体を 1 つにまとめず、機能ごとに分けた方が管理やレビューがしやすくなります。Kiro の公式ドキュメントの Best practices でも、コードベース全体で 1 つのスペックにするのではなく、機能ごとに複数のスペックを作ることが推奨されています。design.md では Mermaid の図でアーキテクチャを示してくれます。tasks.md のチェックボックスは、チャットを切り替えたり作業を再開したりしたときに、どこまで終わったかを Kiro が把握するためのものです。アスタリスクが付いたタスク（ユニットテストやプロパティベーステストなど）は任意で、有効にすると実行時間がおよそ倍になります。
お客様からよく受ける相談として、スペックが 10 個、20 個と増えたときの扱い方も紹介しました。稲田がおすすめしているのは、スペックを 1 回の開発のための中間成果物として使い、決まった内容は別に管理している開発ドキュメントに反映することです。過去のスペックを全部整合させ続けると、それだけでトークンを使い、開発が進まなくなります。
講義: Steering と Agent Skills
タスクを実行している待ち時間には、Steering と Agent Skills の使い分けを解説しました。
Steering は、コーディング規約やプロジェクトの構成など、Kiro に常に守ってほしい決まりを書いておくファイルです。LLM は会話のたびに前回の内容を覚えていないため、Steering があれば毎回同じ説明をせずに済み、チームでの引き継ぎにも使えます。作り方は「ステアリングファイルを作って」と頼むだけで、Kiro がプロジェクトを調べて product.md（プロダクトの目的）、tech.md（技術スタック）、structure.md（ディレクトリ構成）の 3 つを作ります。デモでは、Git のコミットメッセージのルールを書いたファイルを Steering に加えると、コミットメッセージがそのルールどおりに変わる様子を見せました。お客様の開発ルールは Word や Excel にあることが多いため、支援の現場ではそれを Kiro に渡して Markdown にするところから始めることが多いそうです。
Agent Skills は、特定の作業のときだけ読み込ませたい手順や知識をまとめたものです。常に読む必要のない情報まで渡しておくと、LLM がその情報に引っ張られてしまうことがあります。Kiro は起動時に各スキルの冒頭の説明だけを読み、会話の内容に合いそうなときに本文を読み込みます。稲田は、ベテランが当たり前に使っているプロンプトをスキルや Steering として組織に配布すれば、若手も同じ水準で開発できると話しました。
使い分けの目安として、始めたばかりの方はまず常に守ってほしいことを Steering に書き、Steering が 1,000〜3,000 行ほどに増えてきたら、常に読む必要のない部分をスキルに移すことを勧めました。最初から完璧な構成を目指すのではなく、使いながら直していくのが基本です。
講義: ハーネスエンジニアリング
休憩後の講義では、仕様駆動開発の次の段階として注目されているハーネスエンジニアリングを取り上げました。
コーディングエージェントを使っていると、与えた制約を守らない、検証していないのに「完成しました」と報告する、進捗を見失って途中で止まる、といった期待とのずれが起きます。その背景には、LLM は確率的に動き、生成はしても自分で検証はせず、会話の状態を持たない、という性質があります。
稲田は「モデル単体は、エージェントではない」と説明しました。エージェントはモデルと、その周りで入力やツール呼び出し、検証を制御する仕組み（ハーネス）の組み合わせです。ハーネスには、Kiro のようなエージェントの提供元が作るエージェントハーネスと、利用者が作るユーザーハーネス（Steering、スキル、Hooks など）の 2 つがあります。稲田は、今回持ち帰ってほしいのは Kiro の中身の細かな仕組みではなく、利用者が自分で作るユーザーハーネスの方で、それを上手に作ってもらうためにこのワークショップを開いていると話しました。
ハーネスは一度作って終わりではありません。稲田は「一回作っておしまいってことはほぼないと思ってください」と強調し、エージェントを動かし、うまくいかなかった点を見つけてハーネスを直し、また動かすという改善を続けることが、組織の開発力の差になると話しました。仕組みは、事前に与えるもの（フィードフォワード）と結果から直すもの（フィードバック）、毎回同じ結果になるもの（LSP、テスト、静的解析など）とそうでないもの（Steering に書いた規約など）の組み合わせで整理でき、これらを使い分けることが大切です。
ハンズオン: Steering、MCP、Agent Skills（Lab 7）
Lab 7 では、AWS リソースのサポート終了日（EOL、EOS）を追跡するエージェントを作りながら、Steering、MCP、スキルを組み合わせました。
Steering には、ホームディレクトリに置いてすべての作業で読み込ませる「グローバル」と、プロジェクトの中に置く「ワークスペース」の 2 つの範囲があります。稲田は、言葉遣いのように開発以外でも守ってほしいことはグローバルに、プロジェクト固有の決まりはワークスペースに置いているそうです。
参加者は .kiro/settings/mcp.json に AWS Knowledge の MCP サーバーを設定し、/mcp で読み込まれたことを確かめました。次に、EOL レポートのテンプレートとエージェントの役割を Steering に置き、/context show で Steering が読み込まれていることと、コンテキストの使用量を確認しました。そのうえで、ワークショップ用の AWS アカウントにあるリソースを一覧にし、EOL を調べさせました。Kiro は AWS Knowledge の MCP サーバーを通じて AWS の公式ドキュメントを参照し、アカウント内の AWS Lambda で使っている Python 3.10 のランタイムがまもなくサポート終了になることを見つけました。結果は、Steering のテンプレートで指定した Expired・Critical・Warning の区分と件数の形式でレポートにまとめられました。
後半はスキルを作りました。スキルは SKILL.md、scripts、references、assets という共通の構成で作ることが多く、一度作れば Kiro 以外のコーディングエージェントにも持っていけます。スキルの冒頭に書く説明文を読んで、エージェントは本文を読むかどうかを決めるため、説明文の書き方が重要です。最後に、Steering に書いた手順をスキルに移すリファクタリングにも取り組みました。100 行の Steering のうち 60 行が手順なら、それをスキルに移すことで、毎回読み込む量を 40 行に減らせます。「最近コーディングエージェントのコストが高い」という相談の多くは、Steering に大量のファイルが入っていることが原因だそうです。
ハンズオン: Kiro Crew（Lab 13）
最後のラボでは、Kiro Crew を体験しました。Kiro IDE、Kiro CLI、Kiro Web、Kiro Mobile (Kiro for iOS) は裏側の仕組みがほぼ共通になっていますが、Kiro Crew は Kiro CLI を包んで動かすアプリケーションで、CLI だけでは足りない機能を補います。料金体系は他の Kiro と同じで、Kiro Crew のために追加の支払いは必要ありません。
Kiro Crew は、もともと Amazon の社員が有志で作った社内向けのエージェントアプリケーションで、約 3 万 9,000 人の Amazon 社員に使われるまでに広がり、2026 年 8 月に公開されました。今回は参加者の PC の環境に影響を与えないよう、ワークショップ環境の EC2 上に Kiro Crew を用意し、VS Code Server のターミナルからスクリプトを実行して接続しました。
Kiro Crew は裏で Kiro CLI を使っているため、それまでのラボで作った Steering やスキルをそのまま使えます。CLI の画面に抵抗のある非エンジニアの方にも、同じ仕組みを使ってもらえます。稲田が特に紹介したのはスケジュール実行で、稲田自身は毎朝 9 時に、前日に公開された Kiro 関連の記事を調べ、Kiro の最新アップデートと比べた一覧を作らせているそうです。結果を Slack に通知したり、Slack から Kiro Crew に作業を頼んだりすることもできます。Kiro Crew はオープンソースで、ディープリサーチなどの拡張機能をライブラリから選んで有効にできます。稲田は、記事の執筆にはほぼ Kiro Crew を、開発には Kiro CLI を使っているそうです。
質疑応答
最後に、参加者からの質問に答えました。
1 問目は「AWS が提唱している AI-DLC は、社内で実際に使われているのか」という質問でした。サポーターとして会場を回っていた、AI-DLC の日本のリードを務める AWS ジャパン シニアスペシャリストソリューションアーキテクトの金森が回答しました。Amazon ではいくつかの製品チームが AI-DLC を全面的に採用して開発しています。ただし、AI-DLC は Amazon が以前から使っていた開発手法ではなく、ソリューションアーキテクトがお客様との対話の中で課題を見つけ、お客様と一緒に作り上げた方法を、Amazon や AWS が取り入れているものです。仕様駆動開発と時期が近いため混同されやすいものの、仕様駆動開発は個人の開発者でも使えるのに対し、AI-DLC はチームの体制や仕事の進め方そのものを見直す取り組みで、扱う範囲が違うと説明しました。
2 問目は「Amazon Quick と Kiro Crew は機能が似ているが、どう使い分ければよいか」という質問でした。AWS のメンバーからは、Amazon Quick にもデスクトップ版があり、たしかに似ている部分があるとしたうえで、ナレッジベースやファイルの共有が必要なオフィスワーク中心の方には Amazon Quick が、Git でドキュメントやコードを管理している開発者には Kiro Crew が合っている、という回答がありました。お客様からは、Kiro のライセンスを配っておけば、それぞれが使いやすい方法で使える点が評価されているそうです。
クロージング
クロージングでは、AWS ジャパン 事業開発マネージャー 井形が、シルバーウィーク明けに 3 時間のワークショップに参加いただいたことへのお礼を述べ、18 時からの Kiro Meetup を案内して、ハンズオンを締めくくりました。
おわりに
今回のハンズオンでは、Kiro の仕様駆動開発から、Steering と Agent Skills によるコンテキストの管理、ハーネスエンジニアリングの考え方、そして Kiro Crew まで、講義と手を動かす時間を交互に設けて体験していただきました。ワークショップの教材と講義資料は公開していますので、当日参加できなかった方も、ぜひ手を動かして試してみてください。
ご参加いただいた皆様、ありがとうございました。