Amazon Q Developer CLIでAWSアイコン版ライフゲームを作りました
「Amazon Q CLIでゲームを作ろう」キャンペーンは、AIコーディングアシスタントを実際に体験し、Amazon Q CLI を使って自分のペースで新しいゲームを作り出すための創造性と想像力を発揮する機会です。この学習機会は 2025 年 5 月 20 日から 6 月 30 日まで実施され、アジア太平洋、日本、中国地域の参加者のみが T シャツを獲得できます。
Amazon Q Developer CLIでAWSアイコン版ライフゲームを作りました
こちらの記事がきっかけなのですが、Amazon Q Developer CLI“だけ”でゲームを作るというテーマがすごく面白いなと思いまして今回はAWSのアイコンを使ったライフゲームを作りました。
どんなのができたのか？
まずは、動作イメージを紹介しましょう。
ライフゲームというジャンル（あるいは数理モデル）があります。Wikipediaの言葉を借りると、
ライフゲーム (Conway’s Game of Life) は1970年にイギリスの数学者ジョン・ホートン・コンウェイ (John Horton Conway) が考案した数理モデルである。単純なルールから複雑な結果が生成され、パズルやミニスケープの要素を持っている。生命の誕生、進化、淘汰などのプロセスを連想させるパターンも存在し、シミュレーションゲームと分類される場合がある。
ライフゲーム – Wikipedia
とのことで、マップ上に生物（ドットだけで表現されたり、小さなアイコンで表示されたりすることが多い）が置かれて、ランダムに移動や接触を繰り返していく中で、その空間で生物のライフサイクルを観察して楽しむジャンルです。
今回はゲームとして楽しめる形を目指しつつ、せっかくAmazon Q Developer CLIのイベントなので、AWSをテーマにして作ってみました。
AWSサービスのそれぞれ特徴を踏まえた行動パターンをもつアイコンたちがマップ内を動き回り、ライフサイクルを経た（体力が0になった）アイコンは破棄され、また新たなシステムを作るためにAWSサービスを導入する（アイコンをマップに追加する）、ということを表現できればと思いながら作成しました。
開発プロセス
まずは、今回どのように開発を進めたか紹介したいと思います。
序盤は丁寧にスクリーンショットを撮っていたのですが、途中から開発が楽しくなってしまってスクリーンショットが少なくなってしまいました。ご了承ください。
1. 設計書作成
まずはじめに上記のようにAWSのアイコンを使ったライフゲームを作りたいということで、設計書作成から依頼しました。
出力された内容もCLIを通じて調整を指示し、完成したのが次の設計書です。
初期の設計書. GitHub Gist: instantly share code, notes, and snippets.
実現したい仕様などは一旦ファイルに落とし込んで、それに基づいた出力をするようにすることで、万が一CLIのセッションなどが切れても手戻りならずに進めることができました。
2. 初期版の作成
ここで出力された設計書のすごいところは開発プロセスのマイルストーンについてもあらかじめ書き出してくれていたのですよね。
たとえば、この部分
フェーズごとに実装する内容を定義してあって、私はこれに沿って上から順番に区切りながら実装することができました。
たとえば、メインとなるコードもこのような具合
この結果できたのがこんなイメージ
まだ、画像を当てはめておらず大体の四角形を使っています。
また、どのアイコンとも同じ行動パターン（直線的な移動のみ）になっています。
ただ、これだけでも十分ライフゲームの体をなしています。
「動くものを作る」という、初期バージョンとしては重要な目標を達成できていたと感じます。
3. 追加機能の実装
最低限、動くものができたので、この辺りから楽しくなってしまって、スクリーンショットも撮らなくなってしまったのですが…!
ここからは冒頭にQ Developerが定義してくれたマイルストーンに沿って実装を進めていきました。
・・・なんだか仕事のようなことをしている気がしてくるのですが、もりもりと機能が増えていくのが楽しく続けられました。
実装した主な内容は以下のとおりです。
アイコンの種類の追加
アイコンごとの行動パターンの追加
（たとえば、「S3はあまり動かない」など）
アイコン同士の重なり過ぎ防止
（前の画像だと、アイコン同士が完全に重なってしまった挙句、だんご状になって動かなくなってしまっていたのを修正）
マウスを使ってアイコンを動かせるようにする
といったことを機能ごとに実装していきました。
全部、CLIでのチャットベースでの実装です。IDEのコード編集部分に一切触ってません。
冒頭の設計図があったことで、チャット上では「次に進めよう」と伝えれば、「どの部分を実装しましょうか？」と提案してきてくれるので、それに対して「設計書のこの部分を実装しよう」と返せば実装を進めてくれました。
設計書を固めておくことで、実装最中には最低限のことを伝えれば実装が進む感覚があり、「設計書って大事なのだな」とも感じました。（結局、人間と働くのと同じなのかもしれません。）
たとえばこんな具合でした。
4. 最終的な仕様
ほしい機能単位で実装を進めていき冒頭のようなライフゲームが仕上がっていきました。
AWSアイコンなどは画像をダウンロードしてきて配備する必要はありました。ここは人間の仕事ですね。
冒頭と同じ画像を再掲：
開発していく中での気づき
元々、「AWSのアイコンを使ったライフゲームを作りたい」という構想はあったのですが、Amazon Q Developerの方から提案されてきて、「なるほどそれはいいな」と思わせられるところがいくつかありました。
たとえば、AWSアイコンごとの行動パターンの違い付けがそのひとつです。
ライフゲームにおいて、種別ごとの違いをつけることで、マップ内の動きに変化をもたらしてくれるので取り入れたいと思っていました。が、Amazon Q DeveloperはそこにAWSの教育的観点を取り入れて行動パターンに理由付けをするように設計してくれていました。
行動パターンをドキュメント化した内容が次の通り
EC2はVPCに依存しているからVPCに引き寄せられるし、S3は安定性と信頼性のあるストレージサービスだからゆっくりと動く。
そして、VPCはネットワーク基盤として広い範囲をカバーするから円を描くような動きをする。正直、アイディアで完全に負けたと感じました。
他にもアイコン間の依存関係のようなギミックも入れておりまして、「EC2はVPCの近くにいないと体力が減っていく（VPCの中に配備する必要があるから）」ですとか「CloudFrontがS3の近くに行くと体力を回復し、移動スピードが上がる（コンテンツの高速配信を表現）」などのようなアイディアも出してくれていました。
一度とっかかりになるギミックができると、そのパターンを真似しながら積極的にアイディアを出してくれました。（こだわればいくらでも時間かけることができそうで途中で切り上げる必要があったくらいです）
うまくいかなかったところ
一方で、本当に最初の初期バージョンにおいては、表示文言に日本語を使っていたのですがこれがどうしても文字化けしてしまいまして、私の知見不足もあり時間がかかってしまい完成を優先するべく英語での表記にすることにしました。
やはり、完全にAI任せともいかず、人間側にも一定の知見はいるのだなと感じました。
Q Developer CLIを使った開発プロセスについて
今回この開発に取り組んでみて、大きな気づきがありました。それは、最初に設計書を作り、それを起点にQ Developer CLIとチャットで機能をひとつずつ実装していくという開発スタイルが、非常に効果的だったということです。
設計書があることで、Q Developerが想定している実装の方向性を、開発者側も把握しやすくなります。もし方向性にずれがあった時は、設計書に加筆・修正すれば、軌道修正が可能になります。
また、設計書の中でマイルストーンを設定し、それに合わせて機能を段階的に追加していく進め方も効果的でした。たとえば、各ステップごとにGitブランチやPullRequestを切って進めることで、変更の粒度を明確に保つことができました。
これにより「チャットしながら変更加えているうちによくわからない変更だらけになってしまい、元に戻せなくなってしまった」ということも防げます
このように、AIとのやり取りを”設計書.md”のような形で意識的にファイルに残すことで、不明確な部分を極力減らしながら開発を進めることができます。
結局のところ、人間同士の開発で有効だった手法は、AIとの開発でも同様に機能するのかもしれません。
まとめ
ジャンルとしてライフゲームの類が好きでして、いつか自分で作ってみたいなと思っていたのですが今回Amazon Q Developerの力を借りてある程度動くものを作ることができました。
仕組み的にも今後も開発を継続して、AWSアイコンを増やし、行動パターン、アイコン同士の依存関係など、これからさらにのめり込んでしまいそうで自分でも少し心配になるほどです。
Amazon Q Developerの使い道の可能性としてはなかなか面白いものを探れたのではないかなと思いますので、Amazon Q Developer CLIの使い方に関する参考事例として、お役に立てば幸いです。
