1.はじめに
1.1.背景
Amazon Q CLI でゲームを作ろう Tシャツキャンペーンというイベント参加するべく、Amazon Q CLIを利用してゲームを作成するまでの、考えたことなどをブログにしたためました。
1.2.Amazon Q とは?
AWSが提供する生成 AI アシスタント。
AWSで開発を行うすべての人に特化した機能を備えており、すべての人に対してタスクの処理を加速できるよう支援してくれる。
以下の２つに大別でき、今回Amazon Q Developerを利用していきます。
| サービス名 | 主な機能・特徴 |
|---|---|
| Amazon Q Business | 企業の知的資産（ドキュメント、データ等）を活用し、自然言語で質問・回答・要約・アプリ |
| Amazon Q Developer | AWSインフラ設計、コード生成、セキュリティチェック、トラブルシュート、ドキュメント生成 |
参考：Amazon Q Businessとは？
参考：Amazon Q Developer とは？
1.3.Amazon Q CLI とは？
Amazon Q Developer をコマンドライン環境（ターミナル）で利用するためのインターフェース のことを指します。
そして、Amazon Q Developer CLI Agent とは、その Amazon Q Developer CLI 内に導入されているエージェント機能 を指します。
このエージェントにより、ターミナル上で自然言語による対話(日本語も対応)や、ローカルファイルの読み書き、
AWSリソースの操作（クエリやデプロイなど）や デバッグなどを、LLM自身で判断し実行までをしてくれます。
今回のイベントでは、こちらのAmazon Q Developer CLI Agent と対話する だけで、直接コードを書かずにゲームを作るといったものとなります。
参考：Amazon Q Developer CLI での超高速な新しいエージェント型のコーディング体験
1.4.公開GitHub
以下 GitHubに詳細を公開
GitHub:GOGO囲碁
2.やってみた
2.1.最初にやったこと
- どんなゲームにするか要件を定める
2.1.1.要件概要
- 私が小学生という青春を謳歌していた時代 ヒカルの碁 という漫画・アニメが世の中を席捲したことがありました。
休み時間にクラスの全員が囲碁をするという謎ブームのなか、私は囲碁のルール(陣地という概念)が全く理解できずボッチ体験を今でも強烈に覚えています。
なので、そんな当時の私のために陣地を視覚的に把握できるという機能を追加した囲碁を作ろうと思い至りました。
クリック で 要件定義書 表示
GOGO囲碁 要件定義書
1. プロジェクト概要
- GOGO囲碁は、囲碁初心者が陣地の概念を視覚的に理解しながら楽しく学べるゲームアプリケーションです。石を置くと自分の陣地が色分けされ、どこが良い手かが一目で分かる機能を提供します。
2. 機能要件
2.1 基本機能
- 9×9の囲碁盤: 初心者向けの小さな盤面を提供
- 対局機能: プレイヤー（黒石）とAI（白石）の対戦
- 石の配置: クリックで石を置く
- パス機能: 手番をスキップする
- 投了機能: ゲームを途中で終了する（投了した側の負け）
- 連続パス終了: 連続2回のパスでゲーム終了
- 勝敗判定: 陣地と取った石の数で勝敗を決定（コミ3.5目）
2.2 視覚化機能
- 陣地の可視化: 確定陣地を色分けして表示
- 影響圏の表示: 石の影響が及ぶ範囲を色分けして表示
- プレビュー機能: 石を置く前に結果をプレビュー表示
- 最後の手のマーク: 直前に打たれた手を強調表示
- 優勢表示: 現在の盤面での優勢状況をバーグラフで表示
2.3 AI機能
- 囲碁検定5級レベル: 初心者向けの適切な強さのAI
- 思考時間の演出: AIの思考中を表示（0.5秒）
- パス判断: 有効な手がない場合にのみパスする機能
2.4 UI/UX
- 和風デザイン: 伝統的な囲碁のイメージに合ったデザイン
- ポップアップメッセージ: 重要な情報を通知（パス、連続パス終了など）
- 結果画面: ゲーム終了時に詳細な結果を表示
- リプレイ機能: 同じ設定で再度対局できる機能
- タイトル画面: ゲーム開始時のタイトル画面
3. 非機能要件
3.1 パフォーマンス
- 応答性: クリックからの石の配置は0.1秒以内
- AI思考時間: 1手あたり最大2秒以内（演出含む）
- 画面更新: 60FPSでの滑らかな描画
3.2 互換性
- 対応OS: Windows
- Python要件: Python 3.8以上
- 必要ライブラリ: pygame 2.0.0以上, numpy 1.19以上
3.3 保守性
-
モジュール分割: 機能ごとに適切に分割されたコード構造
- board.py: 盤面と石の配置ロジック
- ai.py: AI対戦ロジック
- ui.py: ユーザーインターフェース
- game.py: ゲームの状態管理
- life_death.py: 石の生死判定ロジック
- コメント: 主要な関数とクラスには適切なドキュメントコメント
- テストコード: 主要機能のユニットテスト
4. 制約条件
- 言語: Python
5. 開発プロセス
5.1 開発手法
- テスト駆動開発 (TDD): 機能実装前にテストを作成
- 継続的テスト: 変更後は必ずすべてのテストを実行
- コードレビュー: 重要な機能実装後にレビューを実施
- 実機テスト: 実際のゲームプレイでの動作確認を必ず実施
6. 将来の拡張性
- 盤面サイズの選択: 13×13や19×19の盤面サイズの追加
- 対局記録: 棋譜の保存と読み込み
- AIレベル調整: 複数の難易度から選択可能に
- 先手後手: 先手後手を選択可能に
7. リスク管理
- 技術的リスク: AIの思考ロジックの複雑さ
- スケジュールリスク: UI実装の遅延可能性
- 品質リスク: バグの発生と対応時間
- 特殊ケースリスク: 連続パスや特殊な盤面状況での不具合
2.2.Amazon Q Dev CLI 実行
2.2.1.実行環境
| 環境 | 設定 |
|---|---|
| OS | Windows |
| PowerShell | 5.1.26100.4202 |
| WSL2 | 2.4.13.0 |
| Ubuntu | 24.04.2 LTS (Noble Numbat) |
2.2.2.要件を確認してもらい実行
2.2.2.1.要件定義書(README.md ※のちに名前修正)確認
- 要件定義書を確認してもらい実行
2.2.2.2.実装完了
- 実行後およそ10分で、アプリケーション完成(※テストの時間は除く)
2.3.完成したゲーム画面
- トップ画面
- 残課題：ブラウザのゲームタイトルが文字化け
- カーソルを合わせると色を変える仕様
- パスした場合の挙動
- 対戦結果画面
2.4.テスト
あまりにもあっけなく完成してしまったため、機能追加に関してはテスト駆動で開発を進めてもらいました(※およそ6時間程度)
- テスト画面
- Unittestを利用したテストを実施
- Unittestを利用したテストを実施
3.さいごに
普段はアプリケーションのコードを直接書く機会が少ない私でも、作るだけなら ほぼ一撃で出来てしまうのは驚きです。
ただLLMが何を書いてるかわからないが正直なところで、品質を担保して意図通りに動作しているかのテストを実装することで手綱を握らないと、本当にLLMが何をしているか把握できていないという状況になることも学びました。
とはいえ、いままで認知負荷が高くて敬遠していたものが、Amazon Developer LLMなどのツールを利用することでハードルを越えられやすくなることは本当嬉しいことだと思います。