🤖

Amazon Q CLI 初心者がゲームを作って分かった使用のコツ

に公開

tl;dr

下記イベントに参加するにあたって、普段から他のツールで使用している設定やルールを適用しつつ、どの程度使い勝手に違いが出るかも試しました。結論からいうと、MCPサーバの設定とルールの設定がコアな要素になるためか従来のツールと同程度の使い勝手は維持できたと感じてます(ポジティブな感想として)。その体験とAmazonQ CLIを利用する上でのポイントについても記載しています。
https://aws.amazon.com/jp/blogs/news/build-games-with-amazon-q-cli-and-score-a-t-shirt/

設定について

普段から特別な設定を使っているわけではありません。基本的にはGithubのMCPサーバを設定して開発ルールを設定しています。今回も同様の設定を行いました。

MCPサーバの登録

~/.aws/amazonq/mcp.jsonにMCPサーバの登録をしています。Playwrightの設定もしていますが今回は使っていません。
https://aws.amazon.com/jp/blogs/news/extend-the-amazon-q-developer-cli-with-mcp/

Q CLIでは起動時に下記の出力がされMCPサーバが使える状態になっていることが確認できます。

⠋ 0 of 2 mcp servers initialized. ✓ github loaded in 1.60 s
⠙ 1 of 2 mcp servers initialized. ✓ playwright loaded in 1.92 s     
✓ 2 of 2 mcp servers initialized.

/mcp でも確認できますし、 /tools を実行することでMCPサーバで登録されているツール一覧を参照することもできます。

ルールの設定

どのツールでも基本的に開発用のルールを定義するファイルがあると思います。AmazonQでも同じようにあります。下記の記事を参考にAmazonQ.mdを作成しました。

https://zenn.dev/ymotongpoo/articles/20250408-qdev-profile-beta#コンテキスト管理

その後、認識しているルールについて確認します。

> 今認識しているルールを教えてください。
現在認識しているルールは以下の通りです:

1. 開発の流れ
   • Issue毎にローカルにブランチを作成して開発を進める
   • 開発完了後、リモートにPushしてIssue番号を含めたPRを作成
   • PRレビュー後にマージし、Issueをクローズしてブランチを削
   • ローカルとリモートの差分を最新の状態に保つ
・・・
<中略>
・・・
4. Issue・PR管理
   • .github/bug_report.md と .github/feature_request.md を参考にIssueを作成
   • .github/pull_request_template.md を参考にPRを作成
   • エラー発生時はタスクを分解し、機能がデグレードしないように修正

これらのルールに従って、ゲーム開発
プロジェクトを進めています。

ここまでで準備は完了です。

開発にあたり

ゲームの開発自体はほかの方の記事とやっていることは変わらないので、まずはいくつか使用するうえでのポイントを上げます。

ポイント①:q chat を実行するときは --resume オプションをつける

q chat では会話を記憶しているとありましたが q chat 実行時に --resume オプションをつけることで明示的に記録を復元することができます。セッションを切ってしまったあとに続きをしようとしてもオプションなしだと会話を引き継いでくれていなかったように思うので明示的につけるとよいと思います。
https://docs.aws.amazon.com/ja_jp/amazonq/latest/qdeveloper-ug/command-line-chat-persistence.html

ポイント②:MCPサーバの利用は明示的に指示する

これは私のルールの書き方の問題で解決する可能性も高いのですが、Githubに対する操作はMCPサーバで行ってほしかったのですが毎回Githubの認証を求められてgitコマンドで実行しようとしていました。そのため、MCPサーバの利用を望む処理はルールに明記するといいかもしれません。試していなかったのですが、求める操作方法がある場合それをルールに明示するとよい結果になるかもしれないと考えました。

ポイント③:外部記憶をもっと利用する

普段はタスクをIssueとして登録し、Issue毎に開発を行っているのでGithubにはある程度開発した経緯の情報がのこっているのですが、今回はちょっと管理の手間を省いてインタラクティブに開発を進めていました。ただポイント①に書いたようにセッションが切れてしまったときに前の情報が失われてしまうことがありました。その時にコミットログとかIssueの情報がコンテキストとして役にたったので参照できるところに情報が保存されているということは非常に重要だと感じました。

ゲームについて

ゲームについては、まずはざっくりと要件を伝えます。たたき台を作ってもらってから細かい調整をします。たとえば文字の配置、ボタンの配置やなどです。できるだけ細かく指示したほうがしっかり更新されます。今回は、こどもが迷路をよくやっているので子供が遊べる迷路ゲームをテーマにしました。

作ったゲーム

いくつかゲームを作りましたが迷路ゲームが一番ちゃんとできました。難しくするときは案だしからお願いすることもできました。

次のステップとしてもっと難しい迷路を生成するのに挑戦したいと思います。

GitHubで編集を提案
GENDA

Discussion