10
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【Amazon Q】AWSミートアップ参加レポート:LT初登壇!多彩な発表が教えてくれたゲーム制作裏側の苦労・工夫

Posted at

はじめに

先日、AWS主催のAmazon Qに関するミートアップイベント「Amazon Q CLI でゲームを作ろうキャンペーンの報告と最新情報 update & Kiro のご紹介」に現地参加してきました。このイベントでは、ライトニングトーク(LT)登壇の機会を頂き、初めて社外LT登壇を果たすこともできました。
イベント内容や他の参加者の方のプレゼン内容、LT登壇してみての感想を記事にまとめます。

イベント概要

本イベントの概要は以下の通りです。

  • イベント名:Amazon Q CLI でゲームを作ろうキャンペーンの報告と最新情報 update & Kiro のご紹介
  • 日時:2025年7月30日(水) 19~21時
  • 場所:目黒セントラルスクエア17F AWS Startup Loft Tokyo
  • 開催方法:現地&オンライン

ちなみに当初のイベント名は「Amazon Q Developer Meetup #1 ゲームをつくってみた!体験談祭り 編」でした。イベントが企画されてからこの日までに、AI IDEのKiroが発表されたこともあって変更されたようです。

参加のきっかけ

このイベントに先立って、Amazon Qでゲームを作成した体験を記事投稿するとTシャツがもらえるキャンペーン「Amazon Q CLIでゲームを作ろう」が6月に開催されていました。

今回のイベントは、キャンペーン参加者によるゲーム制作内容のLTでの共有をメインとしたミートアップです。
私も記事を投稿してキャンペーンに参加していたため、AWSの方にお声がけいただき、登壇の機会を頂くことができました。

セッション内容

イベントの内容を要点を中心にご紹介します。

メモから書き起こしているので、情報の歯抜けや認識誤りがあった場合はご容赦ください。特に誤りがあった場合はご指摘いただけると幸いです。

AWS:金森さん「Amazon Q CLIでゲームを作ろうキャンペーンの報告とKiroのご紹介」

最初に、AWSの方からAmazon Qキャンペーンの報告とKiroの紹介がありました。

  • Amazon Qに関して
    • Amazon Qの多言語対応に時間がかかったのは、ガードレール周りでの対応に時間がかかったため。
    • 今回のキャンペーンでアジア太平洋地域(インド含む)から1,400以上の応募、日本から500以上の応募があった。
  • Kiroに関して
    • 仕様駆動開発を実現するツール。
    • エージェントフックを活用すると、コードの保存をトリガーとして単体テストを実行するなど、開発における様々な処理を自動化できる。
    • 高度なコンテキスト管理やステアリングファイル(要件やタスクの定義)を活用してほしい。
    • 予想を上回る注目で、利用を始めるにはウェイトリストに登録を。リソースは随時拡大中。

AWSの方の登壇風景

ライトニングトーク

続いて、LTがありました。皆さんの発表内容をコメントともに簡単にご紹介します。

今回は12名の発表に加えて、遠方によりビデオ出演となった1名の計13名の発表がありました。多くのLT応募があったことから、当初の計画よりLT枠を拡大しての開催になったとのことです。

また、AWSの方によれば発表順は、Amazon Qに決めてもらったとのこと。Amazon Qによる素晴らしいアルゴリズムにより、私の発表順はトリになりました。

休憩中に撮影した会場の風景はこんな感じです。登壇者の皆さんが作成されたゲームを試遊できるように、各テーブルにPCが置かれていました。

会場風景

皆さんが公開されている登壇資料やゲームのソースコードのリンクを可能な限り載せておきました。

個人:木村さん

ご経験:プログラミング雑誌記事執筆経験あり
作ったもの:ダンジョン探索型RPG

  • 出だしは好調で、まるでゲームのテンプレートが入っているようだった。
  • ただ、修正が途中からうまくいかず、ステージの切り替えの実装に苦労し、デバッグ地獄。
  • 地形の指定にも苦労したが、画面に対して相対的な比率を指定したらうまく修正してくれるようになった。
  • アイテムの落下の描画に関しては、「重力を考えろ」の一言で一発で実装してくれて感心。
  • 仕様を小さくして作り直すとうまくいく。

「AIは育てるパートナー、大事なのは私たちの言葉」というご感想が印象的でした。パートナーとしてしっかりと指示してあげることが大事ですね。

トレノケート:西さん

ご経験:ノンエンジニア(営業職)
作ったもの:AWS知識で進める恋愛シミュレーションゲーム

  • 正解するとゲーム内の女の子が喜んで、不正解だと怒るゲーム。
  • 感動ポイント:チャットで指示が完結するところ。
  • 注意ポイント:粘り強く修正指示すべき。時間がかかっても並行で別の作業を進めるとよい。コード修正は手動の方が早い。
  • キャラクター画像とBGMを別途用意して質にこだわった。
  • Amazon Qにもキャラクター画像の作成をお願いしたが、残念な出来だったので結局ChatGPTにお願いした。

私はAmazon Qによる画像生成を試していなかったので、今度実力を確かめてみたいと思います。

日本電気:高島さん

ご経験:業務でAWSを扱うがコーディング経験はほぼなし
作ったもの:某有名モンスター収集型RPGゲームライクなRPGゲーム

  • 作っているうちに本家に似てしまった。
  • よいところ:知識経験ゼロで利用可能。要件定義も支援してくれる。(理不尽なお客さんのように)何とかしてと言っても何とかしてくれる。
  • 課題:業務で利用することを考えたら既存環境を破壊しかねない。最終的アーキテクチャの設計はやはり人がやる必要がある。全てAIに任せると人のスキルが育たない懸念があるかも。

私も経験しましたが、Amazon Qが人に確認を求めずに変更を進めてしまうことがありました。他の方の発表でも出てきますが、勝手に変更しないように念押しを心掛けた方がよさそうです。
スキル育成についても同感です。スキルを持った人が扱う分には良いですが、まだ育っていない人がAIにすべて任せてしまうと、成長する機会を失いそうだと思いました。

コープさっぽろ:木原さん(ビデオ出演)

ご経験:Amplify UGの中の人。
作ったもの:神経衰弱

  • LTの登壇応募に1番乗りだったが、遠方につき出張がかなわず、ビデオでのゲーム紹介。
  • トランプの画像は組み込みではなく自動生成。
  • AWSの方コメント:神経衰弱はデバッグが大変そう。

クラスメソッド:小林さん

ご経験:サーバーサイドエンジニア
作ったもの:レーシングゲーム

  • 簡単なリクエストでどこまでできるか試した。
  • もう少し具体的な指示をくれという応答を期待していたがそんなことはなく、15分でベースは完成。
  • HTML、CSS、JSで実装。
  • 車種も選択できるようにこだわった。
  • よくできているかと思いつつ、必殺技を発動しても何も起きないなどバグはあった。
  • 遊び方まで書いてくれるのは感激。

かなり雑な指示でもゲームを作ってくれるのはさすが生成AIですよね。ご本人は「簡単なリクエスト」と表現されていましたが、4つの要件を割と丁寧に伝えられていました。

三菱電機:塚田さん

ご経験:業務でAIツールを多用
作ったもの:対戦型戦車ゲーム

  • 1時間かけて作ったが、1、2回作り直した。
  • 学んだこと:明確に作ってほしいものを指示する必要がある。ツールの意図や成果が明文化されないので、指示に対して何を作ろうとしたか、どのような意図で変更したかが残らない。
  • よかったこと:自然言語でイメージをすぐ具体化できる。実行時エラーの解析、改修を自律的にやってくれる。
  • 本番の開発での運用保守を考えると、バイブコーディングだけではよくない。

もちろん生成AIの内部では作業のコンテキストを保持していますが、指摘されていたように詳細なコンテキストはターミナル出力にしか残らず、文書に残らないのは後から何をしたかったか振り返る時の障壁になると思いました。
この辺りは、ドキュメントに残させながら作業をさせたり、それこそKiroを使ったりすることで、解決していくかもしれません。

JR東日本情報システム:深津さん

ご経験:インフラ畑出身PM。業務コーディング経験0。
作ったもの:JAWS-UGロゴのスロットゲーム

  • 縦スライドだけでなく、横スライドもあるゲーム。
  • いろいろ機能を注文したら、余計なものまでついて変わりすぎた。しかも元に戻らなかった。
  • 人なら分からないと言って止まってくれるが、AIは確率で判断して間違った方向に進んでしまう。
  • レイアウトがうまく伝わらない時は、スクリーンショットで伝えるのが効果的。
  • 勝手に修正しかねないので、「修正しないで」と伝えたら、コードの分析で止まってくれた。

「AIとの協働でも伝え方が重要」とおっしゃっていた通り、相手が人からAIに変わったとしても指示を正しく言語化できることが、今後のプログラム開発でも求められそうです。

NTT西日本:高須賀さん

ご経験:業務でデータ利活用。クラウド資格全冠。
作ったもの:巡回セールスマン問題クイズ

  • 数理最適化を知ってもらうためにクイズ形式で学べるゲームを作った。
  • 生成AIだと最適ルートはほぼ出ない。これがAIと数理最適化の違い。
  • 正しい選択肢は人が与えて、選択肢にそれを含めたクイズを作ってもらった。
  • AIはデータからそれらしい解を生成する。数理最適化では生成されたデータを厳密に探索して解を見つける。

数理最適化と生成AIのそれぞれが回答に至るまでのアプローチを比較されていて興味深かったです。生成AIによってすべてが置き換わるかというと、得意不得意もあるのでまだそうはいきませんね。

某事業会社:長山さん

ご経験:内製開発
作ったもの:子供向け横スクロールゲーム

  • AWSサミット2日目から開発を開始して4日間で完了。
  • お客様(お子さん)からのご意見:難しすぎ。操作しづらい。レベルアップ機能が欲しい。
  • 要件をドキュメントに書いて理解してもらってから始めるのが大事。
  • ただし、要件をマークダウンで書いても従ってくれないこともあった。

お客様からすぐにフィードバックをもらい、アジャイルに開発を進められたとのことです。(途中でコードが消失することもありますが)機能追加を早く回せるのも生成AIの効果ですね。

日本アイ・ビー・エム システムズ・エンジニアリング:山下さん

ご経験:アプリ開発経験なし。AWS全冠。
作ったもの:将棋

  • 普通の将棋ではおもしろくないのでオリジナルの特殊技を用意したら、苦労のポイントになった。
  • 音楽を入れたらそれっぽくなると思い、BGMを用意。
  • 実装をお願いしたら将棋の基本は実装してくれたが、駒の動きが逆など細かいミスがあった。
  • 1つのファイルを変更し続けたら途中でコードが破壊された。
  • 機能ごとにモジュール分割したらミスが減った。
  • 将棋のライブラリが存在することに実装してから気づきいた。
  • ロールバックはいつでもできるように。人がコードを多少は読めた方がよさそう。

私と同じように実装途中でソースコードの消失を経験されていました。いつか破壊されるかもと思って、ファイルの履歴が残るように開発したいです。

ゆめみ:砂岡さん

ご経験:インフラ/SREエンジニア
作ったもの:タイピングゲーム

  • 7行の指示でお願いしたらちゃんとゲームができた。
  • SREに活用できそうなこと:基礎構造をAIに作ってもらうことでテンプレート化が容易に。人よりも確実なレビューで人のコードレビューを簡素化できそう。共有設定を利用すれば他部署に連携できる。
  • 困ったこと:時々タイムアウトする。ランダム性に欠ける。想定と異なるものができる。
  • まとめ:生成物は人がチェックしよう。基礎構造はAIに任せてカスタマイズは人がやろう。生成物に不要なものがないか精査しよう。

業務で活用できる点を整理されていましたが、生成AIに任せられることと人がやるべきことを見極めて活用していきたいと思いました。
不要なものは、ソースコードのコメントなどにも含まれがちですよね。

NTTテクノクロス:大友さん

ご経験:AWSの整備運用
作ったもの:Unityを使用したトリプルトライアドゲーム

  • プライベートでUnityを使ったゲーム開発に熱中。
  • JAWS-UGのイベントで作ったら簡単にできたので応用した。
  • 生成AIはレビューして、エラーもよく対応してくれる。
  • 活用できなかったポイント:UI/UXの修正指示は難しい。Unity作業は難しい。AD用のSDK統合に関連して使用するSDKが混ざる。

Amazon Qではないですが、私も過去に生成AIにライブラリがごちゃまぜになったコードを出力されたことがあるので、類似したライブラリや最近変更があったライブラリを扱う場合は注意した方が良いかもしれません。

三菱電機:野澤(筆者の発表)

経験:業務で数年AWSを使用
作ったもの:AWSにおけるDevOpsを学ぶ教育ゲーム

  • 出だしは順調だったが、機能追加の途中でソースコードが消失した。
  • レイアウトの微調整は一発ではいかずに苦労して時間もかかった。
  • 見えてきたこと:0から7割ぐらいまで作り上げるのは圧倒的に早い。レイアウトなどの微調整は人がやった方が早そう。こまめに成果物をバックアップしておこう。

皆さんの発表を見て

皆さんそれぞれが個性的なゲームを開発されていて、どの発表も興味深く拝見しました。

全体的にやはり最初はロケットスタートで開発が進むものの、後半の機能追加や微調整でトラブルが発生している印象を受けました。
仕様を細かくして伝える、やらなくてよいことを念押しして伝えるなど指示を工夫して与えれば、Amazon Qが間違ったことや余計なことをするのを防げるという知見も共有されていたので、うまく使いこなすために「パートナー」にどのように指示を出すかが重要だと感じました。
また、業務開発において、バイブコーディングだけによる開発は今後も主流にはならず、人が介入する必要があるだろうという声も多数聞かれました。

今回はAmazon Qの実力はどんなものだろうと、ゲーム作りを通してカジュアルに試してみた内容でした。
一部の方は発表でも触れられていましたが、今後具体的な業務で本領を発揮させるには、何をすべきかを探りながら活用していきたいと思います。

LT登壇してみて

25年度の個人的な目標として、社外LTに挑戦することがありました。
どこで登壇しようか考えていたところ、まさに渡りに船のごとく今回のイベントでのLT登壇のお話を頂き、この機会をと思って応募させていただきました。

参加されている皆さんにはとても温かく聴講いただき、和やかな雰囲気で発表を終えることができました。ありがとうございました。
発表には笑いを誘うポイントも入れていましたが、盛り上がっていただけたようで安心しました。
発表後に「発表お疲れさまでした」とお声がけいただいたのもとても嬉しく感じました。

自分の発表を振り返って、やはり詰め込みすぎて早口になってしまった点は反省点です。
練習では時間ギリギリに収まる予定でしたが、本番は前の方の発表を受けて追加でコメントするなどしていたら、手元の時計で30秒ほどオーバーしてしまいました。最後の発表ということで大目に見ていただけたかもしれませんが申し訳なかったです。
今後は本番に何をしゃべりたくなるかも考慮して、余裕を持った発表をしていきたいと思います!

また、発表資料を発表後すぐに公開できると、発表直後の熱意のまま閲覧いただけるので、次回以降すぐに公開できるように準備しておきたいと思いました。

おわりに

今回はミートアップイベントに参加した様子と社外LTに初登壇した感想をご紹介しました。
Amazon Qを活用しつつ、積極的に社外登壇も挑戦していきたいと思います。

10
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
10
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?