0
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?

ライブラリなしで大富豪をAIに作らせてみた ― Gemini × Antigravity CLI × マルチエージェント【後編】

0
Posted at

AIに作らせた大富豪は本当に正しかったのか?複数AIでロジックをレビューしてみた【検証・完結編】

前回の振り返り

【中編】では、マルチエージェントによる設計の試行錯誤
https://qiita.com/0903osa/items/7cc83be8294d87326170

【実装・トラブル編】では、GitHub Copilotの迷走や「相手の手札がフルオープン」「CPUを人間が操作」といった珍バグ、さらにAPIのクォータ上限エラーを乗り越え、なんとかブラウザで動く大富豪を完成させました。

人間がテストプレイする分には、「普通に遊べる」状態になりました。

しかし、遊んでいるうちに、一つ気になるバグを見つけてしまいました。


実際に見つけたバグ:革命中の「階段」判定漏れ

大富豪には「革命」というローカルルールがあります。

4枚以上の同じ数字を出すと、カードの強弱が逆転し、通常時とは強さの順番が変わります。

自分でプレイしていたとき、単発やペア出しでは、革命による強弱の反転がちゃんと反映されていることを確認できました。

ところが、

「革命中に階段を出した場合」だけ、強弱の反転が正しく反映されていない

ことに気づきました。

「階段」とは、3枚以上の連続した数字をまとめて出すルールです。

単発やペアはテストプレイでも何度も試していたので、比較的早い段階で問題に気づくことができました。

しかし、「革命中に階段を出す」という条件が重なったケースは、通常のプレイではそれほど頻繁には発生しません。

そのため、しばらく見落としていました。

大富豪は、単純に「カードを出す」だけではなく、

  • 革命
  • 階段
  • 複数枚出し
  • 8切り
  • 縛り
  • ジョーカー
  • ターン進行

など、複数のルールや状態が組み合わさります。

そのため、

「個別の機能は正常に動いているのに、条件が重なった瞬間におかしくなる」

というバグが発生しやすいことを実感しました。

そして、ここで一つ疑問が出てきました。

「他にも、自分がまだ気づいていない見落としがあるんじゃないか?」

そこで今回は、完成した大富豪のコードを別のAIにもレビューさせ、ロジック上の見落としがないかを探してみることにしました。


検証方法:別のAIにコードをぶつける

開発時はGeminiとAntigravity CLI/IDEを中心に進めていました。

そこで今回は、開発時とは別のAIにもコードを見てもらい、セカンドオピニオンを求めることにしました。

投げたプロンプトの骨子は、こんな感じです。

以下は、ライブラリなしで実装した大富豪のコアロジックです。

革命中に「階段」の強弱判定が反転しないバグが見つかりました。

同じような、状態が重なったときに起きるエッジケースの見落としが
他にもないか、コードをレビューしてください。

今回のポイントは、

単純に「バグを探してください」と依頼したのではなく、自分で発見したバグを起点にして、「同じ種類の問題が他にもないか」という観点でレビューを依頼したこと

です。

「革命×階段」という一つの具体的な事例から、他の状態の組み合わせにも同じような問題が潜んでいないかを調べてもらいました。


AIが指摘してきた、それらしいバグたち

レビューを依頼すると、AIからはいくつかの「怪しい箇所」が指摘されました。

例えば、

  • ジョーカーを含む複数枚出しで、最強判定の比較処理が競合する可能性
  • 8切りで即座に場が流れた際、スート縛りの状態が正しくクリアされない可能性

といったものです。

確かに、大富豪の状態遷移を考えると「ありそうだな」と思える指摘でした。

ただし、ここで重要なのは、

これらは、この記事を書いている時点では自分自身では実際に再現・検証できていない

ということです。

AIがコードを読んで、

「この条件では問題が起こる可能性があります」

と指摘しただけです。

そのため、この記事では、

「AIがこういう問題を指摘してきた」

という事実として紹介するにとどめます。

実際にそのバグが存在するのか、特定の条件で本当に再現するのかについては、別途テストが必要です。

ここは、今回の検証を通して自分自身がかなり意識するようになった部分です。


AIの指摘=バグ発見、ではない

今回、改めて感じたのが、

AIが「バグかもしれない」と言ったことと、本当にバグが存在することは別

ということです。

AIによるコードレビューは、自分では思いつかなかった視点を提示してくれます。

一方で、その指摘をそのまま、

「AIがバグを発見した!」

として扱ってしまうと危険です。

実際に、

  1. AIが問題になりそうな箇所を指摘する
  2. 人間がその内容を確認する
  3. 再現条件を考える
  4. 実際にテストする
  5. 本当に問題があれば修正する
  6. 修正後に再テストする

という工程が必要になります。

つまり、

AIにレビューさせること自体が検証のゴールではありません。

AIの指摘を、

「人間が次に調べるべき場所を教えてくれるもの」

として使う。

今回の経験から、私はそのくらいの距離感がちょうどいいのではないかと思いました。


3部作を通して得られた知見

今回、「チェスを自作した際にライブラリの存在を知った」ことをきっかけに、あえてライブラリを使わず、大富豪をゼロからAIと作ってみました。

最初は、

「大富豪くらいならAIに作らせたらどうなるんだろう?」

という、かなり軽い気持ちでした。

ところが、実際に始めてみると、単純なゲーム開発では終わりませんでした。

設計を考え、

AIに実装させ、

生成されたコードを確認し、

AIが迷走し、

バグが発生し、

人間が原因を探し、

修正し、

さらにテストする。

そして最後には、別のAIにもコードをレビューさせるところまで進みました。

この3部作を通して、いくつか感じたことがあります。

AIは「作る」のが得意。でも、整合性は人間が見る必要がある

AIは、画面を作ったり、イベント処理を書いたり、ある程度まとまったコードを生成したりすることが非常に得意です。

一方で、

  • ゲームの状態
  • ターンの進行
  • 手札
  • 場の状態
  • 革命状態
  • 複数ルールの組み合わせ

といった複雑な状態遷移になると、局所的には正しそうなコードでも、全体として整合しなくなることがあります。

今回の「革命×階段」のバグは、その典型でした。

自分で実際にプレイしていなければ、気づくのがもっと遅れていたと思います。


別のAIによるレビューは「気づき」を増やしてくれる

一つのAIとのセッションだけで開発を完結させると、そのAIが持っている前提や思い込みに引きずられる可能性があります。

そこで別のAIにコードを渡して、

「これ、おかしいところない?」

と聞いてみる。

すると、自分では考えていなかった視点が出てきます。

今回も、ジョーカーを含む複数枚出しや、8切りと縛りの組み合わせなど、自分が改めて考えるきっかけになる指摘が出てきました。

ただし、

AIの指摘を鵜呑みにしない。

ここは重要です。

AIが出した答えをさらに人間が確認する。

この一手間が必要だと感じました。


「AIに作らせる」から「AIと一緒に検証する」へ

今回の大富豪開発で一番大きかったのは、最初と最後でAIとの付き合い方が変わったことかもしれません。

最初は、

「AIに大富豪を作らせる」

という発想でした。

しかし、開発を進めるにつれて、

「AIに設計させる」

「AIに実装させる」

「AIにテストさせる」

「別のAIにレビューさせる」

というように、AIを工程ごとに使い分けるようになりました。

そして、AIが出した結果を人間が確認する。

結局のところ、

「AIに全部任せる」のではなく、「AIを複数の工程で使いながら、人間が全体を見ている」

という形になりました。

これは、今回の開発を始める前には、そこまで明確には考えていなかったことです。


GitHubで公開しています

今回の大富豪のソースコードはGitHubで公開しています。

実際にコードを確認してみたい方は、こちらをご覧ください。

「このルール判定、おかしくない?」

「この条件ではどうなる?」

など、気になるところがあれば、ぜひ見ていただければと思います。


そして、ここで最後にネタばらし

実は、この「検証・完結編」。

最初から予定していたわけではありません。

もともとは、

前編・中編の2部構成で終える予定でした。

ところが、記事を書いている途中で、

「まだ役割分担の食い違いとか、ネタが残っているんじゃない?」

という話になりました。

そこで、そのことをGeminiやChatGPTに相談してみました。

すると、

「それなら、完成したゲームを別のAIで検証する記事にしたらいいのでは?」

という話になり……

気がついたら、

記事の構成、見出し、検証内容、バグの例、まとめまで、ほぼ丸ごと第三部の形になっていました。

つまり、この第三部。

最初から存在していませんでした。


AI、勝手に話を広げすぎ(笑)

最初は、

「ライブラリなしで大富豪を作ってみよう」

くらいの軽い気持ちでした。

そこから、

AIに大富豪を作らせる。

AIがいろいろやらかす。

人間が修正する。

完成したと思ったら、自分でバグを発見する。

別のAIにレビューさせる。

そして、その検証記事までAIが書き始める。

……という流れになりました。

なんというか、

AI、勝手に話を広げすぎです(笑)。


でも、よく考えてみると……

これも今回の大富豪開発そのものを象徴しているのかもしれません。

人間が最初に考えたことをAIに渡す。

AIが解釈する。

時には勘違いする。

人間が修正する。

別のAIに意見を聞く。

さらに別の方向へ話が広がる。

今回の大富豪では、

「AIにゲームを作らせました。」

そして、

「AIに検証方法を考えさせました。」

最後には、

「AIに第3部そのものを作らせることになりました。」

最初の予定にはなかったものが、いつの間にか出来上がっていました。


おわりに

今回の開発を始めたときは、まさかここまで話が広がるとは思っていませんでした。

「ライブラリなしで大富豪を作る」という小さな実験のつもりが、

マルチエージェント開発

AIによる実装

AIによるテスト

人間によるデバッグ

別AIによるコードレビュー

そして、

AIによる記事執筆

まで進みました。

そして最後に一番感じたのは、

AIは非常に便利だけれど、最後まで人間が確認することはやっぱり必要

という、ごく当たり前のことでした。

ただ、その「人間が確認する」という部分を、AIとの対話を繰り返すことで、以前よりも効率的にできるようになったとも感じています。

最初は「AIに大富豪を作ってもらう」だけのつもりでした。

それが気づけば3部作。

そして、その3部目までAIが書いてしまいました。

これで本当に完結です。

……たぶん。


※念のため補足しておくと、「革命中の階段判定漏れ」は、実際に自分でプレイしていて見つけたものです。

一方、記事後半で紹介した「ジョーカーを含む複数枚出しの判定競合」や「スート縛り解除漏れ」については、AIがコードレビューで指摘した内容であり、この記事を書いている時点では、自分ではまだ実際の再現確認までは行っていません。

そのため、これらを「発見されたバグ」とは扱わず、「AIが指摘した検証候補」として紹介しています。

また、この第三部自体も、構成や内容をAIと相談しながら作ったものです。

そのあたりも含めて、

「AIと一緒に作って、AIと一緒に悩んで、最後はAIに記事まで書かせたんだな」

くらいの温度で読んでもらえればと思います(笑)。

今度こそ、本当に完結です。

0
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
0
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?