イメージです
はじめに
こんにちは、クラウドインテグレーション事業部の遅れてきたルーキー八木です。
最近、生成AIを使ってゲームを作るというYouTube動画を見たのですが、かなり雑なプロンプトでも意外と完成度高いものを作っており、生成AIのコーディング性能の進化に驚いていたところに、ブログを書けばKiro を自由に検証で使えるというチャンスに恵まれました。 Kiro の仕様駆動開発を使えばもっと完成度の高いゲームも作れるのでは？と思い至り、Kiro の性能をフルに無駄遣い!?して「あの」ロールプレイングゲームをスクラッチで作ってみました。
それでは、Let's Kiro！
本ブログでわかること
- 非プログラマーがKiro を使うとどのレベルのものが実装できるか
- 非プログラマー目線でKiro を使って良かった点、改善してほしい点
注意点
- 自分はインフラエンジニアでして、業務ではPythonを少し触る程度で、ゲームはおろかアプリケーションを作った経験はございませんので、そのくらいのレベル感でどの程度のものが実装できるか、という視点でお読みいただけると嬉しいです。
- ゲームを作成する場合はゲームエンジンを利用するのが一般的だと思いますので、あくまでKiroの実装能力を計るという視点でお楽しみいただければ幸いです。
出来上がったもの
とりあえず成果物です
概要
素人の作ったしょうもないゲームといえば反論の余地は全くないのですが、実装過程において、コードのコピペはすれども、自分で考えてPythonのコードを実装することは皆無 でここまでできたので、個人的に生成AIの進歩ひいてはKiroの実装能力に改めて驚愕しました。
以下は成果物概要です。
工数としては休みの日を2日間(13~14時間くらい？)まるまる使いましたが、Kiro が ドキュメントおよびタスクを自動生成していた時間は体感でその1/4に満たないと思います。
ほとんどの時間が私自身がKiroの出力内容を解釈したり、コードを指示通りコピペする時間、また後述するChat GPTを使ったクロスチェックの時間で使ったと思われます。
成果物コードの行数合計
合計: 約3,850行
内訳：
- core/: 約1,150行（ゲームロジック）
- pygame_app/: 約850行（描画・入力処理）
- scenes/: 約850行（シーン管理）
- メインファイル: 約50行
- テストファイル（tests/配下）: 約350行
- デモ・検証スクリプト: 約600行
実装したClassの合計数
合計: 38クラス内訳：
- core/: 17クラス
- Character, PlayerCharacter, Enemy
- BattleSystem, BattleState, BattleAction, ActionResult, BattleResult
- Skill, SkillEffect, SkillTarget
- MovementSystem, Direction
- GameMap, Tile
- EncounterSystem, EnemyAI, EnemyLoader, SkillLoader
pygame_app/: 11クラス
- CharacterRenderer, TileRenderer
- Camera, InputHandler
- Animation, AttackAnimation, DamageAnimation, SkillEffectAnimation, FadeOutAnimation
- BattleAnimationSystem, FlashEffect
scenes/: 2クラス
- FieldScene, BattleScene
tests/: 8クラス（テスト用
- TestMovementInvariants, TestCharacterRendererMinimal
- MockCharacter, TestSkillEffect, TestSkillTarget, TestSkillInitialization
- TestSkillDamageCalculation, TestSkillHealCalculation
テストコードを記載したファイルの合計数
合計: 10ファイル
- tests/配下: 3ファイル
- test_movement_invariants.py（不変条件テスト）
- test_renderer_minimal.py（描画テスト）
- test_skill.py（技システムテスト）
ルートディレクトリ: 7ファイル
- test_camera_demo.py
- test_core_setup.py
- test_field_scene.py
- test_input_handler.py
- test_movement_system.py
- test_renderer_demo.py
- conftest.py（pytest設定）
これらのデータもKiroが集計してくれました。
実装過程
事前調査
前述のように自分はゲーム開発の素人ですので、Kiroの助けを借りるとは言え、どのように進めればよいか右も左もわかりませんでした。そこで、今や世界9億人の良き相談相手ChatGPTに相談したところ次のことがわかりました
- シューティングやアクションなど様々なジャンルのゲームがあるうち◯◯クエ風RPGは最も作りやすい部類である
- ブラウザ前提ならPhaserを使うのがよい。ただし、ブラウザ前提でないなら、pygameでも十分作れる
Pythonであれば多少わかるので、トラブルシューティングなどを考慮し、pygameでの実装にしました。
また、ブラウザで公開することを想定するなら、ロジックをPythonで作り、描画をpygame担当というように分けておくことで、後から移行しやすいことがわかりました。さらに、実装タスクをフィールドシーンとバトルシーンにそれぞれ分けて進めることで、責任範囲が明確になる、バグの波及が減る、拡張が楽などの利点があることもわかりました。
Kiroの準備
Kiroでの実装時の重要事項のひとつステアリングファイルはhttps://techblog.forgevision.com/entry/reinvent2025/dvt402-r の記事を参考にカスタムステアリングファイルを作成しました。
次に以下プロンプトで `product.md` , `structure.md `, ` tech.md`
を作成しました。結果としてこの指示が後で効いて来たように思います。
◯◯ 風のRPGをpygameで作成したい。次の内容をステアリングファイルに反映して。 Product overview Target user - general game player including children Key features - Japanese famous RPG “Dragon Quest” like game - 2D mapping - Turn command battle system Business objectives - Even those with no programming experience can create games using Kiro. Technology stack - Language: python - Library: pygame architecture - core game logic -- deploy with Python only pygame_app - drawing -- input -- sound Scene Structure -Title Scene -- Start screen - Field Scene -- Map movement -- NPC dialogue - Battle Scene -- Combat -- Menu Scene Status - Equipment - Items - Event Scene - Story cutscenes - Shop
フィールドシーンの実装
ここからKiroでの実装を本格的に始まります。
ゲーム開発未経験者からすると、Kiroが出力したrequirements.md、design.md、task.md は適切かどうかの判断はかなり無理ゲーとの判断から実装フローは以下の様に行いました。
事前準備(済)
- 前述のプロンプトを投入
- Kiro が プロンプトを元に(ステアリングファイルをproducts.md、structured.md、product.md、tech.md)を生成する
フィールドシーンの実装
- Kiroが requirements.md を生成
- ChatGPT で requirements.md をレビュー
- KiroにChatGPTのレビューをフィードバック
- Kiroが design.md を生成
- ChatGPT で design.md をレビュー
- KiroにChatGPTのレビューをフィードバック
- Kiroが tassk.md を生成
- ChatGPT で tassk.md をレビュー
- KiroにChatGPTのレビューをフィードバック
バトルシーンの実装(specフォルダ内に別の要件定義書、設計書、タスクを生成)
- Kiroが requirements.md を生成
- ChatGPT で requirements.md をレビュー
- KiroにChatGPTのレビューをフィードバック
- Kiroが design.md を生成
- ChatGPT で design.md をレビュー
- KiroにChatGPTのレビューをフィードバック
- Kiroが tassk.md を生成
- ChatGPT で tassk.md をレビュー
- KiroにChatGPTのレビューをフィードバック
各ドキュメント群をChatGPTにレビューさせると、ほぼ9割方はOKという判断になるのですが、定義漏れ、考慮漏れみたいな箇所をChatGPTがめざとく見つけるので、その修正点を、自分がやった体でKiroにフィードバックして実装を進めました。
今回の実装では時間の制約があり、あまりできなかったのですが、Kiroが生成する要件定義書から基本設計書への落とし込みなど、アプリ開発未経験者がしっかり読み込むだけでも勉強になるとは感じました。
task.md のレビューまで終わると、コードの生成に入りますが、タスクには、MVP開発（Minimum Viable Product）(実用最小限の実装)箇所とオプションのタスクが定義されましたが、今回は検証目的なので、MVPのみ実施しました。
実装した各機能は次のフローでデバッグを行って修正しました
今回の開発におけるデバッグフロー
- Kiro が機能を検証するテストコードが生成される
- 各タスクが完了したら、生成されたテストコードを手動で実施
- Kiroにフィードバック
- コードのエラー箇所を調査、修正コードを出力
- 出力されたコードを作業者が該当箇所にコピペ
- 再度テストコードを実行
- パス：次のタスク
- エラー: 3へ
かくして、ついにフィールドパートの実装が完了しました
それでは、いざ参る!
フィールドシーンプロトタイプ
って、こんなもんで遊べるかーーーーーー
バトルシーンの実装
フィールドシーンの実装のみではゲームのゲの字にもなっていなかったので、もう一日休日フル稼働して、バトルシーンの実装に取り掛かりました。
基本的な実装フローはフィールドシーンと同様です。
ひたすらChatGPT と Kiroの橋渡し役をするインフラエンジニアの図が数時間繰り広げられました。
フィールドシーンの実装段階ではほぼ全てのテストコードは一発でパスしてましたが、バトルシーンからはテストコードが一発で通らないケースが発生し始めました。ただ、エラーメッセージをKiroに伝えたら、確実にエラー箇所を特定し、修正コードを生成。そのコード差し替えると、ほとんどエラーは解消されました。
バトルシステムには、いわゆる魔法(実装上は技という名称で定義)のような機能を実装したのですが、ふわっとした指示にも関わらず、Kiro が要求を明確に理解してくれ、デフォルト値を勝手に設定して実装をすすめてくれました。おまかせで定義してもらったデフォルトの魔法(技)は「火の玉」。これ「◯ラ」とはいえないから著作権に配慮した名称！?にしてますよね！！！素晴らしい配慮。
{
"skills": [
{
"name": "体当たり",
"mp_cost": 0,
"power": 1.0,
"effect_type": "damage",
"target": "opponent",
"duration": 0
},
{
"name": "火の玉",
"mp_cost": 5,
"power": 1.5,
"effect_type": "damage",
"target": "opponent",
"duration": 0
},
{
"name": "回復",
"mp_cost": 3,
"power": 20.0,
"effect_type": "heal",
"target": "self",
"duration": 0
},
{
"name": "力溜め",
"mp_cost": 2,
"power": 5.0,
"effect_type": "buff",
"target": "self",
"duration": 3
}
]
}
さらに初期設定で実装されていたモンスターは「ゴブリン」「スライム」という2大王道RPGの最弱モンスターを完全網羅しており(学習データの影響かもしれませんが)、ちゃんと伝えたイメージを確実に実装に反映してくれていて感心しました。ここがすごいよ、Kiro 1 - 設計書にない機能追加
レビュー時点で漏れていたのか、タスク実行中にバトルシステム内アニメーションの詳細設計がなされておらず、実装タスクが止まることがありました。
Kiroくんは要件定義書の内容を再確認し、すぐに実装を再開し、苦も無く実現しました。
設計仕様外の機能まで自動補完されたのは非常に驚きました。
ここがすごいよ、Kiro 2 - シニアエンジニア級のデバッグ力
フィールドシーンを自分のキャラクターが歩く時のアニメーションは、歩行中の連続した静止画をpngファイルに一枚におさめ、そこから適切な座標のイメージのみ切り取って適切なタイミングで表示することで歩いているように見せています。
ところが、自分が用意したpngファイルがKiroが指定したサイズではなかったため、静止画と論理的な表示座標が合わず、「なにこれ？」状態となっておりました。
Kiroに状況を伝えると、pngファイルの実寸を計るスクリプトを瞬時に作成し、その結果にもとづいて画像を表示位置の実装も即座に修正してくれ、なんとか歩いている風には仕上げることができました。ジャンプしているようなエフェクトになっているのは、準備したpngファイルの座標を手作業で調整したことによるズレが原因でして、Kiro の実装は正確なんです。。。。
ここがすごいよ、Kiro 3 - コーディングだけじゃない!
フィールドシーンの初期版では、一面緑色一色の画像を謎のしろくまキャラが飛び跳ねながら移動するというシュールな絵面を展開していたので、なんとか背景画像としてタイル上のフリー素材を表示させようと考えていました。Kiroさんに要望を頼んだところ、なんとこんな答えが。。。
ファイルの配置方法などにまぎれて、マップに当て込むフリー素材の入手先まで案内していただきました。しかも、普通に有用なサイトだったので、そこからマップ素材を拝借して実装しました。
地味に便利編、Kiro 4 - やり直せる
Kiroとやり取りして実装をすすめていると節目節目で、Checkpoint という箇所が生成されます。そのまま実装をすすめたとしても、後からこの地点まで切り戻しできます。 (Restore)これにより、Kiroへの指示を間違えたりした場合でもContextを汚すことなく、切り戻しができます。
Kiro よ、ここはどうなのか
ということで散々持ち上げてきたKiroさんですが、ツッコミどころがゼロという訳ではありません。タスクをお願いした後、わりと頻繁に以下のように仕事しているフリをして、さぼっている？ことがあります。
システムプロンプトで重要な変更は実行前にユーザーに許可を取ること、のような指示がある影響かもしれませんが、許可を求める訳ではなく、ただ固まっていることがよくありました。
こうした場合は、Kiroに修正したコードをプロンプト上に出力させて、自分でエラー箇所にコピペした方が早かったです。
あとがき
かくして、1行も自分でPythonコードをひねり出すことをせず、実装が完了してしまいました。自分が行ったKiroが出力した仕様書をChatGPTにレビューさせる方法は有用だとは思いますが、実務上では守秘義務の関係で難しいでしょう。
ただ、何らかの方法でセキュリティ的な問題が担保されたLLMを利用したクロスチェックであれば可能性はあるかもしれません。
その場合、自分が今回やっていたChatGPT とKiro間のインプット、アウトプットの橋渡しはエージェントで充分可能ですので、人間は最終的な製品のイメージさえ持っていて、それを正しく生成AIに伝えることができれば、あとは最終的な成果物が仕上がってくるのを待つだけになりそうです。
実際、Kiro 自体が仕様書群の作成やコーディングに要した時間は全体のわずか一部で、最も時間がかかった作業はイメージ通りの画像を生成AIに出力させるように自分が試行錯誤してた時間でした。
まとめますと、 KiroであのRPGを作るのに際して以下のものが必要でした。
- フルコミットできる休日
- ドラクエ愛
- Pythonスキル(汗)
- ゲーム開発経験
