はじめてのバイブコーディング with Amazon Q Developer CLI

1. はじめてのバイブコーディング with Amazon Q Developer CLI 2025年7月31日 日本アイ・ビー・エム システムズ・エンジニアリング株式会社 山下 祐樹
2. 2 • 氏名 - 山下 祐樹（やました ゆうき） • 所属 - 日本アイ・ビー・エム システムズ・エンジニアリング 株式会社（ISE） • 普段の業務 - AWSインフラの設計構築案件に従事 • AWS資格 - 2023/2025 Japan AWS All Certifications Engineers 自己紹介
3. 3 はじめにお断り • 本資料の内容は個人の見解です。所属組織を代表する意見ではありませんので、ご理解ご認識の程 よろしくお願いいたします。
4. 4 つづけてお断り • 2025年6～7月の個人的な体験をお話させていただきますが、生成AI関連のアップデートが速すぎるた め、既に一部の情報が古くなっている可能性もあります。何卒ご容赦くださいませ。
5. 5 前提（登壇者の開発スキル） • 本格的なアプリ・ゲーム開発経験は無し。 • 普段はAWSのインフラ業務中心。 • しょっちゅうコーディングしているわけではない。 - ちょっとしたバックエンド用Lambdaのコードを書いたりする程度。 - 今はStrands Agentsに苦心中。 →そんな私でもゲームが作れました！
6. 6 Amazon Q Developer CLIを使ってゲームを作りました • ゲームを作ってブログやSNSに投稿すると、Tシャツがもらえるというキャンペーンをやっていた。 - https://builder.aws.com/content/2xIoduO0xhkhUApQpVUIqBFGmAc/ended-build-games-with-amazon-q-cli-and- score-a-t-shirt • 自分でコーディングせず、Qへのプロンプトだけで完成させるというのが条件。
7. 7 今回作ったゲームについて • 将棋。 • 将棋にした理由は、以下の理由から取っつきやすいと思ったため。 - ルールが広く認知されているので、（Qに対して）細かい説明が不要。 - 動きが非常に制御しやすい（行と列で駒の位置が指定可能）。 • 少しだけオリジナル要素を入れたかったので、特殊技を導入。 • 「音楽を入れればそれっぽくなる」と思い、フリー素材の楽曲を導入。 - そこだけクオリティがやたらと高い。 • 作ったゲームはGitHubで公開中。 - https://github.com/Y-Yamashita-83/Shogi-game
8. 8 導入 ～順調な滑り出し～ • 目論見通り、「将棋のゲームを作ってください」で基本的な部分は大体実装してくれた。 • ただし、駒の動きが上下逆など、細かいミスはチラホラ。 プロトタイプ。 駒の動きと成り判定が逆。
9. 9 特殊技追加 ～暗雲が立ち込め始める～ • 特殊技の導入あたりでコードが複雑になり始める。 • ずっと単一ファイル（main.py）にコードを追記し続ける。 • コードが1,000行を超え始めたあたりから、更新ミスが頻発し始める。 - main() が複数個所あったり、インデントが狂ってたり。 - 追記のはずが上書きして、コードを完全に破壊したことも。。
10. 10 テコ入れ ～機能分割～ • 機能追加を止めて、機能毎にモジュール分割するよう依頼。 • 「モジュール化はコードの保守性を高めるために重要です。」とか言いながら分割してくれた。 - 基本的に「その方が良いと知ってました」という返しをする。 - が、Q側から提案してくれることはなかった。 • 分割後はミスが減り、エラーが出てもトラブルシュートが容易に。 Q 分かってました！ （けど、言われなかったので やりませんでした。） 私 逐一言わない とダメか。。
11. 11 対戦相手の自動化 ～そしてコードのカオス化～ • コンピュータと対戦できるように、判断ロジックを追加。 • 最初コンピュータが弱すぎたので強くするように依頼したら、コードが一気に複雑化し、レビュー が追い付かなくなった。 • あとで見たら、似たような関数が複数作成されていた。 - まだまだ小さなアプリだが、すでに大分カオス。。 Q いや、それなら t押しなよ。。 私 もう見切れないなあ。動作テ ストで確認すればいいか。。 （ y連打） ※ Q がファイルを作成したり更新する場合、y で承認す る。t はセッション中の作業を全て自動で承認する。
12. 12 なんとか動くものが完成 ～そして今更気づく～ • 95%くらいできたところで、「そういや、将棋ゲーム用のライブラリって世の中にあるんじゃ？」と 気づく。 → あった。 • 将棋の基本部分は外部ライブラリを使って、特殊技やその他の部分を作り込む方が良かったと反省。 - 車輪の再発明にかなりの時間を費やす。 - しかも亜種を大量生産。 Q 私 見よ、この傑作の数々！ 既に同じの あったわ。。 色とりどりの車輪たち 既出の車輪
13. 13 個人の感想① • いつでもロールバックできるようにしておいた方がよい。 • 多少なりともコードは読めた方が都合がよい。 - かなり具体的にエラー箇所を指摘しないと直してくれないことがあった。 - 局所的には、自分で直した方が早い部分もあった。 - 例えば、「ボタンの位置をちょっとだけ下げたい」の「ちょっと」を正確に言語化するのは面倒。 - 数値を微修正しながら画面表示して、自分が納得いく場所を見つける方が早かった。 • 多少なりとも開発のプラクティスも知っていた方が都合がよい。 - AIはプラクティスの説明は出来ても、勝手にその通りにはやってくれなかった。 • レビューはした方が望ましいが、追い付かなくなりがち。（個人開発だと特に） • 外部ライブラリを使ってほしい場合は、明示的な依頼が必要そう。
14. 14 個人の感想② • トラブルシュートにはかなり力を発揮しそう。 - 大量の情報をトレースして分析するのは、人間より圧倒的に速い。 - 真因までたどり着けない事もあるが、初手としてはかなり使えそう。 • モデルの能力は影響する。 - 2025年7月31日現在、Q CLIでは以下のモデルが選択可能。 - Claude 3.5 Sonnet - Claude 3.7 Sonnet（デフォルト） - Claude Sonnet 4 - Claude 3.7に作らせたコードが期待通り動作せず、Sonnet 4に解析させたら、すぐに原因にたどり着いて正し く修正してくれた。 - ただし、2025年7月31日現在、Claude Sonnet 4 はアクセスエラーが発生することが多い。。
15. 15 個人の感想③ • バイブコーディングは想像以上に楽しかった。 - 指示だけでものを作ることに、最初は多少モヤる気持ちがあった。 - 実際にやってみると、頭に思い描いたものがドンドン形になることがとにかく楽しかった。 • （自分の場合は）独力で全部コーディングするより遥かに早かった。 - 独力だったら途中で飽きて投げ出していたように思う。 • 試行錯誤のサイクルを高速化できるようになったと前向きに捉えて、色々と試してみたい。
16. FIN