2025年6月
 1
2345678
9101112131415
16171819202122
23242526272829
30 
SNS・リンク

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を通じて調整を指示し、完成したのが次の設計書です。

実現したい仕様などは一旦ファイルに落とし込んで、それに基づいた出力をするようにすることで、万が一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任せともいかず、人間側にも一定の知見はいるのだなと感じました。

まとめ

ジャンルとしてライフゲームの類が好きでして、いつか自分で作ってみたいなと思っていたのですが今回Amazon Q Developerの力を借りてある程度動くものを作ることができました。

仕組み的にも今後も開発を継続して、AWSアイコンを増やし、行動パターン、アイコン同士の依存関係など、これからさらにのめり込んでしまいそうで自分でも少し心配になるほどです。

Amazon Q Developerの使い道の可能性としてはなかなか面白いものを探れたのではないかなと思いますので、Amazon Q Developer CLIの使い方に関する参考事例として、お役に立てば幸いです。

関連記事