AIに作らせた大富豪、実際に動かしてみたら問題だらけだった【実装・トラブル編】
前回記事：https://qiita.com/0903osa/items/64209acae21ffb6700cc
前回、チェスアプリを作った際に「実はライブラリがあった」と気づいたことをきっかけに、あえてライブラリなしで大富豪をAIに作らせてみる、という企画を始めました。
前回はGeminiに「大富豪を作るためのマルチエージェント環境を組んで」と依頼し、Agent1〜4の役割分担表をもらったところまで書きました。
実は、この表にたどり着くまでに、ひと悶着ありました。
実は、Geminiに聞く前に別のAIにも聞いていた
Geminiにマルチエージェント環境を組んでもらう前、実はCopilotにも似たような相談をしていました。
「4つのエージェントで大富豪を開発するとしたら、どのような役割分担にするか？」
その回答がこちらです。
Agent1: E2E（ゲーム統括）
Agent2: Player（人間）
Agent3: CPU1
Agent4: CPU2・CPU3（まとめて扱う）
さらに続けて、こんな提案をしてきました。
「Antigravity CLIの環境があるので、4エージェントを同時に走らせて、相互に状態を共有しながらゲームを進める構成を作りたい。」
……。
あのなあ。
君が大富豪のプレイヤーになってどうするねん。
何回かやり取りしてみても、この思考がなかなか抜けません。どうやら、
「大富豪を開発するエージェント」
と
「大富豪をプレイするプレイヤー」
を完全に混同しているようでした。これは困りました。
Geminiに会話を整理させてみる
そこで、このやり取りをGeminiにそのままコピーして、
「この会話で、本当にやりたいことを整理して」
と投げてみました。すると、かなり綺麗に整理してくれました。
「PythonによるOS非依存（Web）の大富豪ゲーム」を開発・検証・運用するために、役割分担された4つの開発・自律エージェント群（マルチエージェント環境）を構築・実行したい。
そう、それです。最初からこう言ってくれればいいのに（笑）。
そして、ここから改めてGeminiに役割分担を提案してもらったのが、前回紹介した
- Agent1：仕様・ルール統括
- Agent2：ゲームロジック実装
- Agent3：CPU戦略・AI設計
- Agent4：E2E・自動検証
という表でした。Copilotの「プレイヤー視点」の提案から一転、ちゃんと「開発チーム」としての分担に整理されたわけです。
AIを長く使っていると目的がズレる？
ここで痛感したのは、AIとやり取りを重ねていると、最初に考えていた目的から少しずつズレていくことがあるという点です。
原因がAIやセッションの違いなのか、最初の指示の曖昧さなのかはさておき、「人間が作りたいと考えている意図を、AIが常に正確に保持し続けてくれるとは限らない」ということは、今回かなり実感しました。
早速、マルチペインで作ってみる
気を取り直して、Geminiに整理してもらった構成をもとにマルチペインへコマンドを投入し、開発を開始しました。
まずは大まかな骨組みを作成。
画面が表示され、カードが並び、一見するとゲームらしくなってきました。
「これはいけるんじゃないか？」と思ったのですが……。
実際に遊んでみると、問題だらけでした。
実際に動かして直面した3大バグ
1. カードが選択できない
最初の問題。カードをクリックしても選択状態になりません。
大富豪なのにカードを選べない。これではゲームが始まりません（笑）。
2. CPUが自動で動かない
次の問題。CPUのターンになっても何も起きず、相手のカードを出すために人間側がいちいち操作しないといけません。
「CPU戦を作った」と言いながら、人間が全プレイヤーをワンオペ操作する仕様になっていました。
3. 極めつけ：相手の手札がフルオープン
さらにひどかったのが、相手の手札が画面上に最初から全部見えている状態だったことです。
相手の手札が丸見えの大富豪。心理戦もへったくれもありません（笑）。
「動く」と「ゲームとして成立する」の決定的な違い
AIは「画面にカードを描画してクリックイベントを受け取る」というUIのコードはそれっぽく書けていました。
しかし、大富豪のような不完全情報ゲームに不可欠な「情報の隠蔽（他プレイヤーの手札非表示）」や、「自律的なターン進行ループ（CPU思考）」というゲームの根幹ロジックがすっぽり抜け落ちていたわけです。
「コードとして動いている」ことと「ゲームとして成立している」ことは全くの別物なのだと痛感しました。
開発中に直面したもう一つの壁：API制限（Error -2008）
修正を繰り返している最中、ターミナルに ...-2008 という見慣れないエラーが出現しました。
最初はコードのシンタックスエラーを疑いましたが、調べてみるとモデルAPI側の利用上限（Rate Limit / Quota制限）に達した際のエラーでした。
Gemini APIにはリクエスト数（RPM）やトークン数（TPM）の上限があり、今回のように4つのペインで複数のエージェントを同時に自律稼働させていると、短時間でリクエストが跳ね上がって制限に引っかかります。
コードやプロンプトの問題だけでなく、「マルチエージェントを回すためのインフラ・クォータ管理」も意識しなければならないのは、実際に作ってみて初めて得られた知見でした。
地道な「バイブコーディング」で修正を重ねる
発生した問題を一つずつリストアップし、Geminiに投げて修正をかけていきました。
- カード選択イベントのバインド修正
- CPU用の自律思考ルーチンとターン自動遷移の実装
- プレイヤー視点に応じた手札情報の隠蔽（裏面表示）
- 場のクリア判定・パス処理の調整
- 実際にゲームを動かす
- おかしな挙動を見つける
- Geminiに原因と修正内容を指示する
- 生成されたコマンドをマルチペインへ投入
- 再度プレイして確認
このループをひたすら回しました。
AIに「大富豪を作って」と一言投げて一発で完成するわけではありません。人間が動かして違和感に気づき、AIと一緒に直していく。まさにこの対話的な反復こそが開発のリアルな感触でした。
マルチエージェントCLIとIDEの使い分け
このループを回すうちに、あることに気づきました。
マルチペイン（Antigravity CLI）によるマルチエージェント開発は、全体の骨組みを一気に立ち上げる「ゼロイチのフェーズ」には圧倒的な威力を発揮します。
しかし、「ボタンの配置を数ピクセル動かしたい」「特定の条件分岐のフラグを1行だけ直したい」といった微調整の段階になると、毎回AIにプロンプトを投げてペインで実行するのはオーバーヘッドが大きすぎます。
そこで、以下のように作業内容でツールを切り替える構成に落ち着きました。
- 大枠の設計・自律コード生成：Gemini ＋ マルチペイン（Antigravity CLI）
- UIの微細なレイアウト調整・ピンポイントのバグ修正：Antigravity IDE
「すべてをAIに丸投げする」のではなく、開発のフェーズや作業粒度に応じてCLIとIDEを使い分けるハイブリッドなスタイルが、一番ストレスなく開発を進められる現実的なアプローチだと感じました。
というわけで、完成
そんなこんなで試行錯誤を重ね、なんとか普通に遊べる大富豪が完成しました。
「大富豪」という一見シンプルなトランプゲームでも、状態遷移、情報の隠蔽、CPUルーチン、マルチエージェントの役割分担など、ゼロから組むと様々な課題が浮き彫りになります。
今回作成したコードはGitHubに公開しています。
リポジトリ：https://github.com/mitsuosa0903/daifugo
実際に触ってみて「ここのルール判定おかしくない？」という部分があれば、ぜひフィードバックをいただけると嬉しいです。
次回予告
人間がプレイする分には「普通に遊べる」ようになりました。
しかし、大富豪はローカルルールが多く、状態遷移（革命、縛り、階段、8切りなど）が複雑に絡み合うゲームです。
「このルール判定、本当にプログラムとして正しいのか？」
次回は、完成したコードを複数のAIにぶつけて、ロジックの正当性を徹底検証してみようと思います。