初めてのKiroでAWSアプリを開発してみた — ゲームキャラクター自動生成ツールの構築記

Last updated at 2026-03-24Posted at 2026-03-24

はじめに

ソーイ村上です。

社内のAIツール評価の一環として、AWSが提供するAI搭載IDE「Kiro」を使い、ゲームキャラクターの設定を自動生成するWebアプリケーションを開発しました。

Kiroの開発体験は「AIにコードを書かせる」というよりも「AIと一緒に設計を固めてから実装する」という感覚に近いです。プロンプトの質が開発体験を大きく左右し、曖昧さを残せばその分だけ手戻りが発生します。一方で、Specに書いた要件をKiroが「良い意味で発展させて提案」してくれる場面もあり、無料枠500クレジットのうち約180でフロントエンド・バックエンド・インフラの実装が一通り完了しました。

この記事では、リリース時に話題になった仕様駆動開発（SDD: Spec-Driven Development — 仕様書を起点にAIと設計・実装を進める開発手法）を体験するため、Kiroを初めて触った視点から、開発の流れ・つまずいたポイント・よかった点をまとめます。CursorやClaude CodeなどのAIコーディングツールとは異なる「Spec→Design→Task→実装」というワークフローが特徴的だったため、SDDの実体験として記録しています。

想定読者はAI搭載IDEに興味があるエンジニア、またはKiroをこれから試してみたい方です。AWS（Amplify、DynamoDB、Lambda）の基本的な知識があると読みやすい内容になっています。

環境

macOS: 26.3.1
Kiro: 0.11.63

作ったもの

ゲーム開発のキャラクター設定フェーズを支援するWebアプリです。主な機能は以下の通りです。

「プロジェクト（世界観）」を作成し、その中でキャラクターを管理
指定人数のキャラクターをランダム生成（性別・種族・職業・見た目など）
Amazon Bedrockを使って、各キャラクターに約300文字のバックグラウンドストーリーを自動生成
キャラクター間の関係性を設定し、ネットワークグラフで可視化

Kiroとは

KiroはAWSが開発したAIネイティブなIDEです。VS Codeライクなインターフェースを持ちながら、AIエージェントが開発をサポートしてくれます。特徴的なのは「Spec（仕様書）」と「Design（設計書）」をAIと対話しながら作成し、そこから実装に落とし込むワークフローです。

単にコードを生成するだけでなく、要件定義→設計→実装という上流工程からAIが関わる点が、通常のエージェントコーディングとは異なります。

Kiroはアカウント登録時に500クレジットが付与されます。Spec生成やDesign Doc生成、エージェントによるコード実装など、AIを使う操作のたびにクレジットが消費される仕組みです。今回のプロジェクトではSpec作成からフロントエンド・バックエンドの実装完了まで、途中の試行錯誤を含めて約180クレジットを消費しました。無料枠の500クレジットでどこまでできるかの参考にしてください。

チャットを開くと最初にVibeまたはSpecを選択できます。Spec Firstということで今回はSpecを選択します。

最初にやること — テレメトリーをOFFにする

Kiroはデフォルトでテレメトリー（利用状況データの送信）が有効になっています。プロジェクトのコードやプロンプト内容が送信対象に含まれる可能性があるため、業務利用や機密性のあるプロジェクトでは最初にOFFにしておくことをおすすめします。

設定手順は以下の通りです。

Kiroの Settings を開く（Cmd + , または左下の歯車アイコン）
検索バーに「telemetry」と入力
「Allow Kiro to send content to AWS for service improvement.」をOFFに変更
「Allow Kiro to send usage data to aws.」のチェックを外す

開発の流れ

1. Specの作成 — AIに要件を伝える

Kiroでまず行ったのは、Spec（仕様書）の作成です。今回は事前にまとめていた要件（世界観・性別・性格・年齢・種別・職業・見た目・関係性といったキャラクター属性の定義、AWS構成、非同期生成フローの設計など）をMarkdownで整理し、Kiroに渡しました。

初回は新規開発かどうか、ドキュメントから始めるかといった質問が返ってきました。それぞれRecommendedで進めます。

Specとなるrequirements.mdを生成すると、Design Doc（設計書）の生成を提案されます。

2. Design Docの生成 — 設計をAIが提案

Specを元にKiroがDesign Doc（設計書）を自動生成します。DynamoDBのテーブル設計（隣接リストパターン — 1つのテーブルでエンティティ間の関係を表現するNoSQLの設計手法 — による関係性の管理）やLambdaの分割方針、非同期生成フローのシーケンスなど、インフラ寄りの設計もカバーしてくれました。

3. Taskの生成

最後にこれまでの仕様書からタスク一覧を作成します。ここまでの内容を確認して問題なければ「Run all tasks」で実装が順次開始されます。

実装が一気に進むので壮観です。

4. 初期プロンプトからの変更点 — Kiroの設計判断

設計が完了した時点で、最初に渡したプロンプトとKiroが生成した最終的な仕様書を比較すると、いくつかの変更点が出ました。Kiroがプロンプトの意図を汲み取りつつ、自ら設計を発展させた部分です。

項目	プロンプトの想定	Kiroの判断	理由
Lambda分割	3関数	4関数（CRUD＋生成を分離）	Bedrock呼び出し関数のみリソースを大きく設定可能
API定義	backend.ts or data/resource.ts内	api/resource.tsとして独立	Cognito Authorizer含むAPI層の分離
テスト	指示なし	Jest + Vitest + MSW等を自動選定	Kiroが自発的にテスト構成を追加

Lambda関数の分割粒度が細かくなった

プロンプトでは3つ（generateCharacters、projectsApi、relationshipsApi）を想定していましたが、Kiroは4つに分割しました。キャラクターのCRUD（character-lambda）とランダム生成＋Bedrock呼び出し（generate-lambda）を別関数に分離しています。Bedrock呼び出しを含む関数だけタイムアウトやメモリを大きく設定できるため、この分離は合理的です。

API Gateway定義が独立ファイルになった

プロンプトではamplify/backend.tsまたはamplify/data/resource.tsでAPI定義を想定していましたが、Kiroはamplify/api/resource.tsとして独立させました。Cognito Authorizerの設定も含めてAPI層をきれいに分離しています。

テスト構成をKiroが自動で決定した

プロンプトにはテストに関する指示を一切書いていませんでしたが、Kiroはバックエンド（Jest + ts-jest + aws-sdk-client-mock）とフロントエンド（Vitest + React Testing Library + MSW）のテスト構成を自ら選定し、テストファイルも生成しました。

ポイント

MCP Serverの設定

KiroではMCP（Model Context Protocol — AIモデルが外部ツールやデータソースと連携するための標準プロトコル）サーバーを追加して機能拡張できます。AWSサービスならスムーズに実装・設計をしてくれることを期待して、AWSサービスで実装を固めるようにしました。

MCP Powers — エージェント専用のMCP

KiroにはMCP Serverとは別に「Powers」という仕組みがあります。通常のmcpServersがユーザーのチャットセッションで使われるのに対し、powersはKiroのエージェント（Spec生成やコード実装を担うバックグラウンドAI）が使うMCPです。

今回のプロジェクトでは以下のPowersを設定しました。

aws-iac-mcp-server — CDK/CloudFormationのIaCパターンをエージェントに提供。amplify/backend.tsでのカスタムリソース追加時に活用
iam-policy-autopilot — IAMポリシーの自動生成・最小権限の提案
mcp-server-fetch — エージェントが外部URLからドキュメントを取得する際に使用。ライブラリの公式ドキュメントなどを参照してコード生成の精度を上げてくれる

最初は他のAWS系Powersもインストールしていましたが、不要なPowersを入れておくとエージェントのコンテキストにノイズが増え、かえって生成品質が下がるリスクがあるため上記のみに絞りました。

{
  "mcpServers": {
    // ユーザーセッション用のMCP（チャットで使う）
    "aws-docs": {
      "command": "uvx",
      "args": ["awslabs.aws-documentation-mcp-server@latest"],
      "env": { "FASTMCP_LOG_LEVEL": "ERROR" }
    },
    "aws-knowledge-mcp-server": {
      "url": "https://knowledge-mcp.global.api.aws",
      "type": "http"
    }
  },
  "powers": {
    "mcpServers": {
      // エージェント用のMCP（Spec生成・実装時にエージェントが使う）
      "power-iam-policy-autopilot-mcp": {
        "command": "uvx",
        "args": ["iam-policy-autopilot@latest", "mcp-server"]
      },
      "power-aws-iac-mcp-server": {
        "command": "uvx",
        "args": ["awslabs.aws-iac-mcp-server@latest"],
        "env": {
          "AWS_PROFILE": "your-named-profile", // ← 自分のAWS CLIプロファイル名に変更すること
          "FASTMCP_LOG_LEVEL": "ERROR"
        }
      },
      "power-mcp-server-fetch": {
        "command": "uvx",
        "args": ["mcp-server-fetch"]
      }
    }
  }
}

注意点として、aws-iac-mcp-serverの設定にはAWS_PROFILEの指定が必要です。デフォルトのyour-named-profileのままだと動作しないため、自分のAWS CLIプロファイル名に書き換えてください。

Steering — エージェントの振る舞いをルール化する

Kiroの「Steering」機能は、プロジェクトのルート直下の.kiro/steering/に配置するMarkdownファイルで、エージェントが従うべきルールやコーディング規約、ワークフローを定義できます。

Specが「何を作るか」を定義するのに対し、Steeringは「どうやって作るか」のルールを定義します。Cursorでいう.cursorrules、Claude CodeでいうCLAUDE.mdに相当する仕組みです。

今回のプロジェクトでは以下のSteeringファイルを作成しました。

# ワークフロールール

## コード変更のルール

1. 変更前に仕様書（design.md / requirements.md）を更新してユーザーの承諾を得る
2. 変更後に `git commit` を実行する（変更単位ごとに1コミット）
3. コミットメッセージは変更内容を簡潔に英語で記述する

## 回答言語

- 日本語で回答する

都度Specでチャットセッションを仕切り直すのも手間なので、「変更前に仕様書を更新してユーザーの承諾を得る」というルールを追加しています。これにより、Kiroがいきなりコードを変更するのではなく、まずrequirements.mdやdesign.mdの該当箇所を更新して確認を求めてくるようになりました。

Steeringにはワークスペース単位（.kiro/steering/）とグローバル（~/.kiro/steering/）の2つのスコープがあります。回答言語のように全プロジェクト共通のルールはグローバルに、コミット戦略のようにプロジェクト固有のルールはワークスペースに配置すると管理しやすいです。

よかった点と課題

よかった点

Specの選択UIが自然にSDDへ導く

チャットUIとしてSpecの選択が出るため、最初に仕様書を更新するという意識が自然と生まれます。また、セッションが限界になると自動的に新規のチャットセッションが開かれ、コンテキストの読み込みと残タスクを提案してくれるのは良い体験でした。

インフラコードも含めた一貫性

フロントエンド・バックエンド・インフラ（CDK）を同じIDE内で、同じAIコンテキストで扱えるのは大きな利点です。「DynamoDBのスキーマを変更したらLambdaのハンドラーも合わせて更新」といった横断的な修正がスムーズでした。

Specに書いた要件を発展させてくれる

前述の通り、Lambda関数の分割やテスト構成の自動選定など、プロンプトに書いていない部分をKiroが合理的に補完してくれる場面がありました。設計の叩き台としてDesign Docを出してくれるのは、一人で開発しているときに特に助かります。

課題・注意点

仕様変更時はSpecから仕切り直す

途中でCognito認証の方式をメールアドレス＋パスワードからGoogle認証に変更しました。チャットで指示を出すとVibeコーディング方式でコード修正を始めてしまったため、中止して仕様書更新を指示する形になりました。仕様に関わる変更は、既存のチャットで指示するのではなく、新規チャットでSpecから始めるほうが安定します。

コミットなしで進めるとエラーが出る

コミットなしで作業を続けていると以下のようなエラーに遭遇することがありました。

Write verification failed - file content does not match expected.
The agent has seen this error and will try a different approach to write the file if needed.

これはエージェントがファイルを書き込んだ後の整合性チェックで、期待した内容と実際のファイル内容が一致しなかった場合に発生します。エージェントが複数ファイルを連続で変更している途中で、前の変更との整合性が取れなくなるケースがあるようです。

対策として、Steeringに「各タスク完了時にgit commitを行うこと」と明示的に指示を追加しました。これにより、機能ごとに区切られたコミット履歴が残り、後からの差分確認やロールバックがやりやすくなります。

プロンプトの曖昧さがそのまま手戻りになる

Kiroはrequirements.mdに書かれていないことは確認してくれません。「Cognito認証」と書くか「CognitoのGoogle認証」と書くかで出力が変わります。曖昧さを残せば、その分だけ手戻りが発生するため、要件は具体的に書くことが強く求められます。

できたもの

キャラクター設定が生成されるようになりました。

今はファンタジーに引っ張られた結果になっていますね。現代小説的なものを考えると、プロンプトやジャンル設定の調整が必要そうです。ここまでに約180/500クレジットを消費しています。

ソース: https://github.com/sugumura/character-generator

まとめ

Kiroを使った開発は、「AIにコードを書かせる」よりも「AIと一緒に設計を固めてから実装する」感覚です。Specドリブンのワークフローは、設計を言語化する力が求められる分、成果物の質がプロンプトの質に直結します。

AWSサービス側の構築はエラーが発生しても都度修正を依頼することで対応可能で、全体的な設計のほうが重要だと感じます。

次回記事ではBedrockによるストーリー生成の詳細や、実際に作成された内容について見ていく予定です。

お知らせ

技術ブログを週1〜2本更新中、ソーイをフォローして最新記事をチェック！
https://qiita.com/organizations/sewii

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up