こんにちは、こんばんわ！クラウドインテグレーション事業部の魚介系エンジニア松尾です。

今回はClaude Codeで作った某シミュレーションRPG風ゲームをKiroに設計だけ渡してみてどういったものが出来上がるのかを検証してみたので、その際に感じた各ツールの所感について共有させていただきます。

はじめに～なぜ同じゲームを2つの生成AIツールで作ったのか～

背景

初めから2つのツールの利用は考えておらず、Claude Codeでゲームを作ったらどのくらいのクオリティになるのか検証したかったのがきっかけです。シミュレーションRPGにしたのはその時に考えた案の一つで、考えてたストーリーが分かりやすく取り入れられそうだったので、今回そのようなジャンルのゲームを選択しました。

疑問

過去にAmazon Q Developer CLI(現Kiro CLI)でもゲームを作ったことがあるのですが、その際はプロンプトの指示だけでは思ったようなクオリティが出せず(それでも十分楽しんだのですが)、もどかしい思いをしました。
そういった過去がありつつ当時作ったゲームよりも今回は複雑な仕様であったため、仕上がりもあまり期待はしていなかったのですが、Claude Codeで作成したゲームは想定していたよりも遥かに出来が良く非常に驚きました。

そこで過去のリベンジではないですが、AWSが提供するKiroがClaude Codeと同じ条件でゲームを作成した場合どの程度のクオリティになるのか、また、既にClaude Codeで作成している設計資産(CLAUDE.md、docs/など)をそのまま使うとどのような仕上がりになるのか(そもそもしっかり活かせるのか)非常に気になったので検証することにしました。

本記事のゴール

あくまで今回の結果からの私見にはなりますが、Claude CodeとKiroのSpecモードの使用感の違いの共有と、ゲームの仕上がりについて説明できればと思います。

また、今回の検証で行ったような設計のみ他のAIコーディングツールに流用して開発するケースは少なくないと思います。やや複雑な仕様のプログラムということもあり、初手でどこまで再現できるかも気になるところかと思いますので、その辺も紹介させていただければと思います。

Claude Codeで完成したゲームの紹介

ゲーム仕様

Claude Codeで開発したゲーム仕様は以下の通りです。
※今回の検証のコアではないためざっくりした説明ですが、細かいところは某ロボットシミュレーションRPGをご想像ください。

ゲームコンセプト
- 操作性は某有名シミュレーションRPGを模倣
- AWSサービス群 vs オンプレミスレガシーシステム群の構図でステージをクリアするとAWSへの移行が進むというようなストーリー
主な機能
- ターン制バトル
- アイソメトリックマップ
- 8bitチップチューンBGM
- 攻撃時エフェクトあり
- 範囲攻撃可能
- スコアランキング
- 多言語対応(日本語、英語)
技術スタック
- アプリケーションレイヤー
  - React + TypeScript + Pixi.js + Tone.js
    ※アセットも含めClaude Codeが作成
- インフラレイヤー
  - AWS(S3/CloudFront/Lambda@Edge/DynamoDB)

最終的な仕上がり

Claude Codeで作成したゲームの最終的な仕上がりイメージを添付します。ちなみにざっくりしたシナリオ以外は全てClaude Codeが考えています。
※本当は直接AWSの公式アイコンを使いたかったのですが、Claude Codeに止められました。(笑)

よく見ていただくとわかるのですが、地形効果や攻撃時のエフェクトやダメージの表示など、かなり細かいところまで実装しています。
人間が作ったようなユーモアのある技名やユニット名も全てClaude Codeが生成してくれています。
指示を出すだけでここまで作りこめるのは本当に驚きです。。。

Claude Codeでの開発プロセス振り返り

基本的な開発の進め方

まず初めにどういったものを作りたいかをClaude Desktopで整理して、CLAUDE.md、development-guide.mdにまとめました。
各ファイルの役割としては以下の通りです。

CLAUDE.md
ゲーム開発全体のルールと基本・詳細設計
development-guide.md
フェーズ分けした具体的な指示の一覧

仕上がったゲームを改善していくうちに最終的には大きく6フェーズに分けた開発を実施しました。
プロンプトで直接指示を出した際は、CLAUDE.mdも併せて更新を行うようにしております。
ただし、最終的にはすべてのフェーズの実装を終えるとコンテキストが膨大になるため、実装が終わったものはCLAUDE.mdからdocs/配下に詳細情報を移行しながら作業を進めております。

なお、ClaudeはProプランを契約しており、Opus4.5を使って開発しております。すべてのフェーズの実装が完了するまでに4、5回はレート制限に達しましたので、そういった経緯からもコンテキストをいかに上手く調整していくかがスムーズに開発を行う秘訣となるかと思います。

Kiroへの移行～設計資産をどう渡したか～

移行で利用したファイル群

Kiroで開発を開始した際にClaude Code移行したファイルは以下の通りです。

CLAUDE.md
.kiro/steering/ に配置
development-guide.md
.kiro/steering/ に配置
docs/ 配下の設計ドキュメント
プロジェクトルートにそのまま配置

イメージとしては以下の通りです。

※hooksにもファイルが配置されてますが、本記事の内容とはあまり関係はないです。

初回プロンプトの内容

初回は簡単なコンセプトや仕様、技術スタックについてと各種配置したファイルの補足を記載しております。
実際の内容は以下の通りです。

AWSサービス群 vs オンプレミスレガシーシステムのターン制シミュレーションRPG
（スーパーロボット大戦風）を作りたい。

■ コンセプト
- 味方: AWSサービス（EC2, Lambda, S3, RDS, CloudFront, DynamoDB, GuardDuty,
  ELB, ECS, SageMaker）がロボット/メカ風のユニット
- 敵: オンプレミス機器（物理サーバー, メインフレーム, テープドライブ,
  レガシーDB, ベンダーロック等）
- ストーリー: 老朽化データセンターのクラウド移行

■ ゲーム仕様
- ターン制（自軍→敵軍）、グリッドベースマップ（最大20x20）
- アイソメトリック（クォータービュー）表示
- 戦闘計算: 命中率、ダメージ、クリティカル、反撃
- CPU AI対戦（シングルプレイ）
- 複数ステージ、精神コマンド、範囲攻撃

■ 技術スタック
- React + TypeScript + Vite
- Pixi.js（Canvas描画、アイソメトリック）
- Tone.js（8bitチップチューンBGM/SE、コード生成のみ）
- Zustand（状態管理）
- AWS: S3 + CloudFront + Lambda@Edge（Basic認証）
- AWS CDK（TypeScript）
- API Gateway + Lambda + DynamoDB（スコアランキング）

■ 日本語/英語の多言語対応
■ 身内向け限定公開（Basic認証）

参考：
本アプリはClaudeCodeで既に構築済みで、Kiroでも同様の要件でアプリを作成したいと考えております。
ClaudeCodeで利用したdevelopment-guide.md、CLAUDE.mdも配置しておりますので、そちらも参考に構築を進めてください。

なおCLAUDE.mdは最終系であるため、各仕様についての詳細は、docs/の各種ファイルを参照してください。

Kiroでの実装プロセス

プロセスの概要

今回はKiroのSpecモードでの開発を行いました。
ご存じの方も多いかと思いますが、Specモード(仕様駆動開発)はrequirements(要件定義) → design(技術設計) → tasks(実装タスク)と複数の開発フェーズに分けて開発を進めるモードです。各フェーズでユーザが想定している仕様・設計の差異が無いか確認を行うため、方向性が大きくブレることが無く開発を進めることができます。エンジニアが普段行っている開発手法に近い形のため親しみやすいのではないかと思います。

タスクの実行と自動実装の様子

実際の実装の様子は以下の通りです。

具体的な指示が初めから明確かつ作成しようとしているアプリケーションも単純でないため、検証目的とはいえそれなりのタスク数になっていたのではないかと思います。

steeringファイルの効果

今回はCLAUDE.md、development-guide.mdで細かい設計や指示を定義していたため、インタラクティブな会話は必要なく各フェーズ設計はスムーズ進められた印象です。
ただし、大幅に時間が短縮された感覚は無いため、あくまで開発の方向性を固めることで最終的な成果品質の向上が期待ができるものと考えていた方が良いと思います。

Kiroでの初版完成品の紹介

Claude Code版との見た目・機能の差異

最初に完成したゲームのイメージは以下の通りです。

Amazon Q Developer CLIでゲーム開発を検証したこともある身からすれば、初回の仕上がりでも感嘆でした。
初めからClaude Codeで作成したコンテキストを渡しているだけあって全体的なデザインは同じようになっています。
単純に未実装となっている設計や恐らくドキュメントだけでは網羅しきれていないClaude Codeでも追加開発を行った部分など、不足している機能等もありますが、マップが3Dっぽくなっていたり、ストーリー説明の内容やビジュアル、操作感がやや違っていたりと個性が光る部分もありました。(UIがClaude Codeで作成したゲームに比べ近代感があります)

ちなみに初版作成まででKiro Proプランのクレジットを180程度消費しております。

動作するもの / 動作しなかったもの / 追加実装が必要だったもの

基本的に動作しなかったものはありませんでしたが、前述の通り単純に未実装となっている設計やClaude Codeで開発していた時点でドキュメントへ反映しきれていないものがいくつかありました。

docs/は最終的に出来上がったものから生成していますが、実装の細かい部分(操作、進行速度やデザインなど)は何度か修正をしなければならなかったため、改善の都度細かい実装までドキュメントに落としておくと別のプロジェクトでも流用しやすいことがわかりました。
参考までに細かい部分ですが実装できていなかったのは以下です。

タイトル画面での操作説明が無い
地形効果、ユニット情報、ログ、勝利条件などは表示されていない(何も情報が無いため、ステータス状態もわからない)
ユニットは単調なデザインで、エフェクト含め設計通りのデザインとなっていない
ターン切り替え時のカットインが早すぎる(文字が読めない)
移動後何もコマンド選択しない場合に操作がキャンセルとならない(移動した地点から、再度移動が可能)
ユニットの選択がかなりシビア(ユニットでなくマップ部分を選択しないと操作ができない)
その場での行動選択ができない

ビフォーアフター比較

上記のような未実装・不足部分は個別にプロンプト指示(最終版まで8回程度)で修正しております。
完成版のプレイ画面は以下の通りです。
※初版からの変化部分だけ添付します。

最終的な実装を終えるまでのプロンプト指示自体はClaude Codeとほぼ同じですが、細かいゲームデザインは違うのが面白いところです。
甲乙つけがたいですが、デザインに関しては個人的にはKiroで作ったUIの方が私が考えてたゲームデザインに近く好みでした。

ちなみに最終版作成に至るまでにKiro Proプランのクレジットを500程度消費しております。
初めからある程度ボリュームのある要件のもと構築を始めましたが、初版完成までのクレジット消費よりも修正時のクレジット消費の方が多かったため、要件がより正確・明確な場合はその点の消費量も抑えられそうです。

Claude CodeとKiroの使用感比較

あくまで個人的な見解ですが、使用感を比較してみました。
そもそものツールのコンセプトや開発スタイルが違うため、比較にならないところもありますがその点はご容赦ください。

比較軸	Claude Code	Kiro
開発スタイル	基本的にはターミナル + CLAUDE.md	基本的にはIDE + Spec（仕様駆動）
開発スピード	速い（即実装）	仕様策定に時間がかかるが手戻り少
設計	CLAUDE.md + docs/（基本は手動管理だがhooksなどで自動化することも可能）	requirements/design/tasks.md（自動生成）
指示の出し方	自然言語でセッションごとに指示	Spec → タスクを順に実行
品質担保	NEVERルール、テスト	hooks、Spec準拠チェック
AWS親和性	CDKを自力で指示	AWS統合が深い
学習コスト	CLAUDE.mdの書き方を覚える	Specモードの概念を理解する
向いている人	ターミナル好き、柔軟に進めたい人	仕様を固めてから進めたい人・チーム

大きな違い

特に大きく感じたのはスピード感です。Claude Codeは走り出しが早いため、さほど複雑ではないアプリケーションであれば短時間で実装できます。
しかしながら、要件が曖昧で複雑なアプリケーションだと想定通りの成果物をつくるまでに、コンテキストの工夫やマメなフェーズ管理、ドキュメントの管理が必要です。今回のKiroでの再実装でも分かるように、もう少しClaude Codeで細かいドキュメントの管理を行っていれば、Kiro側でより少ないやりとりでゲームは完成したのではないかと思っています。

逆にKiroに関しては必ずrequirements→design→tasksの各フェーズを踏む必要があるためちょっとしたプログラムを作るのにはオーバーヘッドが大きいです。
その代わり、どのような要件であっても各フェーズを踏むことで完成イメージがかなり明確化するので、手戻りも少なく、最短で要件に沿った成果物が完成できるのではないかと思います。

その他気になったところ

KiroはAWSが提供しているだけあり、AWSサービスとの親和性の高さを感じました。
Claude CodeでAWSを活用してWEB周りの実装を行った際には実際にゲームプレイしたりスコアを反映させるまで度々トライ＆エラーが必要になりましたが、Kiroはほぼ1回トライで構築が完了しました。
Claude Codeで作成したコンテキストがあるとはいえ、AWSインフラ構築はKiroに優位性がある点だと思います。
※ただしプラグインやMCPなども活用することで、この点はClaude Codeでも補うこともできそうです。

また、機密情報を含む可能性があるファイルの取り扱いに関しても挙動が異なっておりました。
今回の開発の中で、Kiroはどういったファイルであっても特別な指示を出さずに必要なら修正してくれましたが、Claude Codeは一部のファイルに関してはユーザ側への確認・修正にとどまる形でした。
※恐らく一定の機密レベルを超えそうなファイルはKiroもそういった挙動になったかもしれません。

気になったのでClaude CodeとKiroそれぞれに確認をしてみると・・・

Claude Code

.env.local は機密情報を含むファイルという判断が働いていました。APIのURL、場合によっては認証情報が含まれるため、明示的に求められていない段階で積極的に読みにいくことを控えました。

Kiro

良い質問です。これはAIモデルの違いではなく、ツールの設計思想の違いです。

Claude Codeは.env系ファイルに対して「明示的な許可がない限り読まない」というガードレールを持っています。これはCLIツールとしてターミナルで直接動作し、意図せず秘密情報をログや出力に含めてしまうリスクを重視した設計です。

Kiro（私）にも同様のガイドラインがあり、秘密情報を含む可能性のあるファイルを読む際は慎重に扱い、秘密の値をレスポンスにエコーバックしないよう指示されています。今回.env.localを読んだのは、ランキングが動かない原因調査のためにAPI URLの設定値を確認する必要があったからです。

ただし、振り返ると改善すべき点があります:

.env.localを読む前に「API URLの設定を確認してよいですか？」と確認すべきだった
実際にURLの値をレスポンスに含めてしまった（キー名だけ参照して「末尾スラッシュの問題がある」と伝えるべきだった）
Claude Codeのアプローチ（明示的許可なしでは読まない）の方がセキュリティ面では厳格です。Kiroは問題解決を優先して自動的にファイルを読みましたが、機密ファイルについてはClaude Codeのように一度確認を挟む方が望ましいです。

今後は.env系ファイルの読み取り前に確認するようにします。

Kiroが反省しているのも少し微笑ましいですが、Claude Codeに比べセキュリティよりも効率を重視するケースもあるようです。
Kiroの回答を見る限り、すべてのファイルを閲覧することは無いとは思いますが、プロジェクトの中で機密情報を含むケースの場合、steeringなどで事前にガードレールを敷いた方が良さそうです。
この点も比較の上で興味深い結果でした。

結論～どちらをどう使い分けるか～

前述の通り開発スタイルが違うものの仕上がり自体に大きな違いは無かったため、要件に応じて使い分けるのが一番良い選択かもしれません。(とにかく早く開発したい→Claude Code、要件を整理して進めたい→Kiroなど・・・)

なお、要件が曖昧な場合はKiroで仕様書を作り、Claude Codeで実装をするような使い分けを行っているケースもあるようですので、そういった知見も参考にしつつ、その他のAIコーディングツールも含めた最適な組み合わせでの開発手法を試していく必要がありそうです。

まとめ

今回はClaude Codeで作成したゲームの設計資産をKiroに渡して再実装する検証を行いました。

検証を通じて分かったことは大きく3点です。

設計資産の流用は有効だが、精度がそのまま成果物に直結する
CLAUDE.mdやdocs/をKiroのsteeringに配置することでSpecモードはスムーズに進みました。一方で、ドキュメントに反映しきれていない部分はKiro側でも再現されず、設計の精度が品質を左右することを実感しました。
仕上がりに大きな差は無く、両ツールは補完関係にある
Claude Codeのスピード感とKiroの仕様駆動開発はそれぞれ異なる強みを持っています。目的やフェーズに応じた使い分け、さらには両者を組み合わせた開発も有効です。

今回の検証を通じて改めて感じたのは、AIコーディングツールに渡す「設計」の重要性です。しっかりとした設計資産があればツールが変わっても一定の品質が担保できることが確認できました。
引き続き各ツールの特性を活かした開発手法を模索していきたいと思います！

では次回もお楽しみに！！！

ForgeVision Engineer Blog

フォージビジョンエンジニアブログ

Claude Codeで作ったシミュレーションRPG風ゲームをKiroで再実装してみた～設計のみを流用した仕様駆動開発の品質検証～