DEVELOPMENT STORY
AIと一緒に作った新しい五目並べ『CYBER GOMOKU』の裏話
少しだけプログラミング経験があっても、サーバーを使うオンライン対戦ゲームを一人で安全に公開するには、多くの分野を学ぶ必要があります。サイバー五目は、その不足をAIの支援で補いながら形にしたプロジェクトです。
定番の五目並べに情報戦を加える
企画の出発点は、「昔からある分かりやすいゲームに、デジタルでなければ成立しない要素を加える」という考えでした。盤面と勝利条件は五目並べを基礎にしながら、次の3種類の能力を追加しました。
- 相手から見えない状態で置くステルス碁石
- 指定マスを踏むと周囲の石を消す碁石爆弾
- 隠された石や爆弾を発見する碁石レーダー
完全情報ゲームだった五目並べに、予測、罠、探索を加え、相手の盤面だけでなく意図を読むゲームにすることが目標です。
ブラウザゲームを選んだ理由
アプリのインストールを必要とせず、URLを開けばすぐ遊べることを重視してブラウザゲームにしました。アプリストアの審査や配信手数料を気にせず、修正をすぐ全プレイヤーへ届けられることも、個人開発との相性が良い点です。
技術構成は次のとおりです。それぞれ「個人でも運用し続けられるか」を基準に選びました。
- クライアント:React + TypeScript + Vite。型チェックがあることで、AIが生成したコードの誤りにビルド段階で気づけます。
- 対戦サーバー:Node.js + Socket.io。リアルタイム対戦の手番のやり取りをWebSocketで行います。
- ログインとデータ保存:Firebase AuthenticationとFirestore。認証基盤を自作しないことで、セキュリティ上の危険を減らしました。
- 配信:ゲーム本体はCloudflare Pages、対戦サーバーはRender。どちらも小規模なら低コストで運用できます。
どれも特別な構成ではありませんが、「枯れた組み合わせを選び、独自性はゲームルールに集中させる」という判断そのものが、完成までたどり着けた理由だったと思います。
AIには実装だけでなく、問題の切り分けを手伝ってもらう
AIへ要望を伝えるだけで完成したわけではありません。生成された実装がゲームルールに合っているかを確認し、ブラウザ、サーバー、認証、データ保存のどこに問題があるかを切り分ける必要がありました。
本番公開時にはGoogleログインが動かない問題が発生しました。このとき、画面に出たエラー、発生する環境、ローカルとの差を具体的に整理してAIへ渡すことで、設定不足を特定できました。「動かない」とだけ伝えるのではなく、再現条件と観察結果を共有する重要性を学びました。
日々の開発は、おおよそ次のサイクルの繰り返しでした。
- 要件を1機能まで小さくする:「オンライン対戦を作って」ではなく「手番が来たプレイヤーだけが着手できるようにする」まで分解してから依頼します。
- 生成物をルールと突き合わせる:実装が正しく見えても、禁じ手や看破のような境界条件はゲームの仕様を知る自分にしか判定できません。
- 動かして壊す:わざと不正な操作(相手の手番に着手する等)を試し、どの層で弾かれるかを確認します。
AIは「実装の速度」を大きく上げてくれますが、「何が正しいか」の定義は開発者の仕事のまま残ります。この分担を意識できてから、開発が安定して進むようになりました。
ゲームの正解はサーバー側で判断する
オンライン対戦では、ブラウザから送られた盤面や勝敗をそのまま信用できません。現在は、手番、座標、アイテム残数、勝敗をサーバー側で再検証し、クライアントは表示と操作を担当する構成にしています。
五目並べの判定ロジックはクライアントとサーバーから利用できる純粋なモジュールへ集約し、同じルールを別々に実装して結果がずれないようにしました。AIを使う場合でも、どこを信頼境界にするかは開発者が決める必要があります。
公開後も改善を続ける
ゲームを公開した後は、初回説明、アクセシビリティ、CPU戦の目標、海外ポータル向けビルドなどを追加しました。完成したコードを得ることより、問題を小さく分け、検証し、次の改善につなげることがAIとの開発で最も役立った点です。
公開後の具体的な改善は、それぞれ別の記事に記録しています。海外ポータルへの申請記録、プレイデータをもとにした見せ方の改善、遊びやすさのための設計もあわせてご覧ください。
これから個人開発を始める人へ
同じようにAIの支援を受けながらゲーム開発へ挑戦する人に向けて、この開発で得た教訓を3つ挙げます。
- ルールの一次情報は自分で書く:ゲームルールの仕様書だけは自分の言葉で明文化しておくと、AIへの依頼も検証も揺れません。サイバー五目では判定ロジックを1つのモジュールに集約したことが、後の全機能の土台になりました。
- 信頼境界を最初に決める:「クライアントの申告をどこまで信じるか」を後から直すのは大変です。オンライン要素があるなら、サーバーで再検証する前提で最初から設計することをおすすめします。
- 公開してから本当の開発が始まる:実際のプレイヤーの環境・行動は、開発中の想定を必ず裏切ります。小さく公開し、観察し、直すサイクルを前提にスケジュールを組んでください。
AIが生成した内容はそのまま採用せず、ゲームルール、セキュリティ、型チェック、ビルド結果を人間が確認する方針で開発しています。