AWS Japan の新卒が Kiro でマネコン上の操作を支援する Chrome 拡張機能をチーム開発してみた！

みなさん、こんにちは！

本ブログは Kiroweeeeeeek ( X: #kiroweeeeeeek) の第 9 日目です。昨日のブログは鈴木さん（ともぞん）の「負債にならない Spec ファイルの扱い方」という内容でした。

Kiroweeeeeeek が終盤を迎えた今、Kiro を使い始めた方の中には、このように思った方も多いのではないでしょうか。「Kiro、個人開発においては爆速で開発が進みそうだけど、チーム開発で使うイメージは掴めないな…」

そこで今回は、Kiro をチーム開発において利用しソリューションを作成した AWS Japan の新卒メンバーが、Kiro を用いたチーム開発におけるノウハウや使い方をご紹介したいと思います！

開発の経緯と Kiro

2025 年 4 月に AWS Japan に入社した Solutions Architect と Professional Services のメンバーは、新卒研修である Tech U における最終成果発表として、一つのソリューションを 4 〜 5 名のチームで開発しプレゼンテーションを行うことになっています。開発期間は約 2 ヶ月で、Tech U の講義や実習演習、各自の実務と並行して企画から開発まで行いました。

ソリューションの開発は、Amazon におけるイノベーションメカニズムであるPRFAQ (Press Release and FAQ) を書くところから始まります。PRFAQ とは、製品を開発する前に「完成した製品のプレスリリース」を先に書く手法です。顧客にどんな価値を提供するのかを明確にしてから開発を始めることで、開発の方向性のブレを防ぎ、本当に必要な機能に集中できます。また、想定される質問を FAQ としてまとめることで、開発におけるリスクや未解決の課題を事前に洗い出し、関係者間で認識を合わせることができます。私たちのチームは、AWS のマネジメントコンソールを初めて使う方向けに、操作を視覚的に支援する Chrome 拡張機能を開発しました。開発を行ったソリューションは実際にお客様にご利用いただき、ソリューションに対するフィードバックももらいました。

ちょうど開発を始めた時期に、Kiro がプレビュー版で発表されました。AWS Japan の新卒技術者として、開発に使わない手はなかったため、チーム開発に取り入れました。手探りで始めた Kiro を使ったチーム開発ですが、使っていくうちに、Kiro にできること・難しいことが見えてきました。

ソリューション紹介

まず、作成したソリューションについてご紹介します。作成したソリューションは、次の 3 つの機能を搭載しています。

資料やチャットをもとにした実行プラン（操作ステップ）作成
実行プランをもとにしたマネジメントコンソール上へのハイライト指示テキスト表示
チャット機能による質疑応答

1. 資料やチャットをもとにした実行プラン（操作ステップ）作成

「Amazon Bedrock を触ってみたい」という内容をチャットに入力、またはワークショップや勉強会などにおいて配布された資料を添付すると実行プランという操作ステップを自動で作成します。

2. 実行プランをもとにしたマネジメントコンソール上へのハイライト指示テキスト表示

実行プラン作成後、プランに基づいて選択すべき箇所を赤枠で強調表示し、操作手順を示します。また、ユーザーの操作をトラッキングしているため、各ステップの完了を自動判定できます。また、すでに操作が完了している場合は、手動で該当ステップを完了としてマークすることもできます。

3. チャット機能による質疑応答

操作をしていて AWS についてや技術的にわからない点が生じた際は、チャット機能で質問することができます。

アーキテクチャ

作成したソリューションの技術アーキテクチャはこちらです。

Chrome 拡張機能は、バックエンドの共有メモリーとやりとりを行いながら、実行プランを作成するプランナー、チャットを行うチャットエージェント、画面上の要素を解析する UI 解析エージェント、ユーザの操作が実行プラン通りに行われているかを検証する検証エージェントの各エージェントとやりとりを行います。

チーム開発で Kiro を使いこなすコツ

続いて、先ほどご紹介したソリューションを 4 人のチームで開発する際に得た、Kiro 活用のコツをご紹介します。

ステアリング機能の活用

Kiro の主要な機能の一つとして、ステアリング機能があります。これは AI コーディング時に参照してほしいルールや前提知識を AI エージェントに伝えるためのコンテキストファイルです。このファイルをコードベースと一緒に Git 管理することで、開発メンバー全員が同じガイドラインに基づいて AI コーディングを活用できるようになります。

私たちの開発チームでは、以下の項目をステアリングファイルとして、.kiro/steering/development-guidelines.mdというファイルを作成し、以下の内容を記述しました。

コーディング規約

## コード品質基準
**品質チェックフックが自動実行** (code-quality-check.md)
### TypeScript
- 厳密な型定義を使用
- 既存のクラス構造を維持
- ES2020+ の機能を活用
- エラーハンドリングを必ず実装
- 型安全性を最優先
- インターフェースと型定義を適切に使用
- コンソールログで動作を確認可能にする
### Python
- 既存のクラス構造を維持
- 型ヒントを使用
- 例外処理を適切に実装
- ログ出力で動作を追跡可能にする

技術選定・アーキテクチャ構成

#### AIエージェント（agent/）
**メインアプリケーション**
- `agent/app/main.py`: FastAPI エントリーポイント、API サーバー起動
- `agent/app/orch.py`: オーケストレーション、ワークフロー制御
- `agent/app/shared_models.py`: アプリケーション全体で共有するPydanticモデル
**コア機能（core/）**
- `agent/app/core/config.py`: アプリケーション設定管理
- `agent/app/core/logging_config.py`: ログ設定とログレベル管理
- `agent/app/core/store.py`: データストアとデータ永続化
**機能別モジュール（features/）**
- `agent/app/features/analysis/`: AWS Console要素の分析機能
- `agent/app/features/chat/`: チャット機能とユーザー対話
- `agent/app/features/planning/`: タスクプランニングと実行計画
- `agent/app/features/validation/`: 入力検証とデータバリデーション
...

ディレクトリ構成

## プロジェクトディレクトリ構成
### 必須ディレクトリ構造
プロジェクト全体は以下の構造に従って開発すること：
```
aws-console-guidance-extension/
├── extension/                      # Chrome拡張機能
│   ├── src/                       # ソースコード
│   │   ├── content.ts            # メインContent Script
│   │   ├── background.ts         # Background Service Worker
│   │   ├── sidepanel.html        # Side Panel HTML
│   │   ├── sidepanel.ts          # Side Panel メインスクリプト
│   │   ├── types.d.ts            # グローバル型定義
│   │   ├── lib/                  # 共通ライブラリ
│   │   │   └── constants.ts      # 定数定義
│   │   ├── sidepanel/            # Side Panel関連
│   │   │   ├── main.ts          # Side Panelエントリーポイント
│   │   │   ├── types.ts         # Side Panel型定義
│   │   │   ├── components/      # UIコンポーネント
│   │   │   │   ├── chat-manager.ts      # チャット管理
│   │   │   │   ├── notification.ts      # 通知システム

構成動作確認・テスト方法

## 動作確認の原則
### ❌ 禁止事項
- **テスト機能やデバッグ機能を既存コードに追加しない**
- 動作確認のたびにコードが複雑になることを避ける
- 一時的なテストコードを本番コードに混入させない
### ✅ 推奨する動作確認方法
- **Chrome MCPを使った実際のAWS Management Console上での動作確認**
- ユーザー視点での実際の操作フロー確認
- 既存コードを変更せずに外部からの動作確認
- **自動フックによる継続的な品質確保**
- **実際のAWS Console環境での拡張機能テスト**

ステアリングファイルを作成することで、コーディングを開始するときにファイルを読み込んで、内容を理解した上で AI との対話を始めることができます。

このようにすることで、コードの整合性を保ち、デバッグや動作確認の負担を軽減しています。既存のワークスペースを読み込んでステアリングファイルを Kiro に生成させることもできます。私たちの開発ではこれらの基本項目に加えて、実際の開発で直面した課題から重要なポイントが見えてきました。

技術選定とバージョン管理の重要性

LLM は学習データの影響で、古いバージョンのフレームワークやライブラリに基づくコードを生成してしまうことがあります。実際の開発では以下のような課題に直面しました。

Tailwind CSS v4 を使用したいにも関わらず、 v3 のコードが生成される
Chrome 拡張機能の Manifest V3 における仕様変更への対応不足

この問題を解決するには、ステアリングファイルで使用する技術をバージョン情報まで含めて明確に指定することが重要です。今回の開発ではステアリングファイルに以下の内容を記述しました。

### 8. バージョン確認と正しい実装
- **使用しているライブラリやフレームワークのバージョンを必ず確認し、そのバージョンにおける正しい処理を実装する**
- **古いバージョンや異なるバージョンの処理を使わない**
- 実装前にpackage.json、pyproject.toml、requirements.txt等でバージョンを確認
- 公式ドキュメントの該当バージョンのAPIリファレンスを参照
- 非推奨（deprecated）なAPIや機能は使用しない
- バージョン固有の制約や変更点を考慮した実装
- Chrome拡張機能のManifest V3仕様に準拠した実装
- TypeScript、Python、Node.js等のランタイムバージョンに適合した構文・機能を使用
- ライブラリの破壊的変更（Breaking Changes）を考慮
- 可能な限り最新の安定版機能を活用し、将来的な互換性を確保

また、LLM の学習データに多く含まれるような、広く普及してきた安定版のフレームワークを選択することで、より一貫した結果を得られる傾向があります。

Spec 機能との連携による設計統一

私たちは Kiro でチーム開発を行う際、機能ごとに Spec を生成して開発を行いましたが、開発メンバー間で設計思想やコードベースの理解に違いが生じることがあります。その際、主要な Spec から設計思想やディレクトリ構造を定期的にステアリングファイルに反映することで、開発メンバーによらず、統一されたコーディングスタイルを維持できます。Agent Hooks を用いることで、 Spec を作成する度に自動でステアリングをアップデートできるほか、ステアリングファイルのエディタから Refine ボタンを押すことで、ステアリングの中身を AI が理解しやすい形で簡潔に最適化してくれます。

AI との認識齟齬を防ぐヒアリング

開発者の意図や既存コードベースから逸脱したコーディングを防ぐために、ステアリングファイルに AI からの質問やヒアリングを促す指示を含めると効果的です。これにより、開発メンバーごとに各プログラミング言語やフレームワークの習熟度に違いがある場合においても一貫した開発が可能となりました。そのほか AI による意図しないコード変更を防止し、事前の提案とレビューによりコード品質を向上させることができました。

開発プロセスにおいて、AI エージェントへの追加指示を適宜ステアリングファイルに反映することで、コード生成の精度を継続的に向上させることができます。このようにしてステアリングを育てていくことで、他のプロジェクトでも活用できる資産として蓄積させることが可能です。この継続的な改善プロセスこそが、Kiro をチーム開発で最大限活かすうえで避けて通れない重要なポイントだと考えています。

タスク分解での活用

チーム開発で Kiro を活用する上で最も重要なポイントの一つが、タスク分解の扱い方です。Kiro の Spec 機能では単一のプロンプトから、要件 (Requirements)、設計 (Design)、タスク (Tasks) という 3 つのフェーズから構成されるプロセスにより開発を進めていきます。この仕様上 Spec の生成方法を工夫しないと、タスク数が膨張し、結果的にウォーターフォール的な進め方になりがちです。この状態ではチームで作業を分担しづらいという問題が生じます。

Spec を小さく保つことの重要性

この問題を解決するには、MVP (Minimum Viable Product) 思考で Spec 自体を小さく保つこと が重要です。MVP とは「まずは最小限の価値をユーザーに届けられる状態を定義し、その実現に必要な要素だけに絞って開発する」という考え方です。大規模機能を一気に Spec 化しようとするのではなく、まずは「技術的境界」で分割することを意識しました。

ソリューションの開発で「DynamoDB を用いたセッション管理機能」を実装した際、アプリケーションとインフラをひとまとめに Spec 化するとタスクが 20 件を超えてしまいました。そこで以下のようにアプリケーション層とインフラ層で技術的境界を引き、「別の Spec」として切り分けるという工夫を行いました。

Spec 1: アプリケーション層の実装 (例: DynamoDB 用データクラスの実装)
Spec 2: インフラ層の実装 (例: Terraform ・ECS ・ CI/CD 設定)

このように領域ごとに切り分けることで Spec 生成後のタスクも自然と適切な規模に収めることができました。

適切なタスク分解によるチーム開発支援

Spec の粒度を技術的境界で適切に設定することで、Kiro が生成するタスクは以下の情報を明確に持つことができます。

タスクの目的
背景となる設計意図
タスク間の依存関係

さらに、Kiro の Spec から生み出された細かい粒度のタスクはチーム開発との相性が非常に良いと感じています。今回のソリューション開発ではそこまで踏み込みませんでしたが、生成されたタスクを GitHub Issues や GitLab Issues と紐づけて、メンバーごとに担当タスクを割り振る運用を行えば、よりスムーズな協働が実現できるはずです。また、

既存の Issues をもとに小さな Spec を生成する
Spec 側で分割したタスクを各 Issues に紐づける

のように状況に応じて双方向に連携できることも利点だと考えています。他者との協働作業における活用方法については、「Kiroを使ったペアプログラミングのすすめ」も併せてご覧ください。

例えば今回の Spec 1: アプリケーション層の実装 ではこのようなタスクが生成されました。図のように一つ一つのタスクに終了条件を記述してくれますので、タスク分担した際にメンバー間で共通認識を持つことが可能になります。

こうしたタスク分解の仕組みをうまく活用することで、Kiro は単なる AI コーディングツールの枠を超えた、チーム開発支援を行う強力なツールとして機能させることができます。そのため、Spec の分割や適切なタスク分解は、Kiro をチーム開発で最大限活かすうえで避けて通れない重要なポイントだと考えています。Spec についてより詳しく知りたい方は「Kiro における負債にならない Spec ファイルの扱い方」も併せてお読みください。

まとめ

本記事では、AWS Japan の新卒メンバーが Kiro をチーム開発に取り入れ、約 2 ヶ月で Chrome 拡張機能を開発した実践例をご紹介しました。個人開発ツールという印象が強い Kiro ですが、適切な工夫によりチーム開発でも十分に力を発揮できることを実証しました。

特に重要なポイントは以下の 3 点です。

ステアリングファイルの共有: チーム全体で一貫したコーディングスタイルと技術選定を実現
MVP 思考での Spec 分割: 技術的境界で適切に分割し、管理しやすいタスク粒度を維持
継続的な改善: 開発中に得た知見をステアリングファイルに反映し、資産として蓄積

このような工夫により、高品質なコードベースを維持しながら、仕様駆動開発だからこそ可能な明確な終了条件を持つタスク分割を行うことができました。また、技術的境界での分割により、マージ時のコンフリクトが起きにくく、コード管理がしやすいという利点も得られました。

Kiro は単なるコーディングアシスタントではなく、チームでの協働を支援するツールとしても大きな可能性を秘めています。みなさんもぜひ Kiro を用いたより良い開発手法を模索し、#kiroweeeeeeek で共有してください！

深澤真愛 (Mana Fukasawa)
アマゾンウェブサービスジャパン合同会社広域事業統括本部ソリューションアーキテクト
2025 年 4 月入社。Kiro のキャラクターのかわいさに毎日悶えている。IoT 技術、家電、スマートプロダクトに強い情熱を燃やしている。
LinkedIn: https://www.linkedin.com/in/manafukasawa/
X: https://x.com/mana_sar_

末永将也 (Masaya Suenaga)
アマゾンウェブサービスジャパン合同会社プロフェッショナルサービス本部デリバリーコンサルタント
2025 年 4 月入社。ゲーム・エンターテインメント業界のお客様を中心に IT 支援を提供している。

菊地泰斗 (Taito Kikuchi)
アマゾンウェブサービスジャパン合同会社パブリックセクター技術統括本部　ソリューションアーキテクト
2025 年 4 月入社。公共のお客様を中心に技術支援をしています。ネットワークに強い興味関心がある。
LinkedIn: https://www.linkedin.com/in/taito-kikuchi-439523369

Amazon Web Services ブログ