技術構成と実装のポイント（Next.js + Firebase + Gemini）

はじめに

この記事では、本サービスの技術的な裏側についてまとめます。
最初に動くものを作るのはかなり速くなった一方で、実際に公開して運用に耐える形に持っていくには、やはり別の大変さがありました。

Firebase App Hosting での運用

技術選定の段階からAIに相談しながら進めました。 結果、今回のバックエンドは、ほぼ全ての機能をFirebaseに委ねる形にしました。

• 匿名認証（Authentication）
• サーバー側ロジック（Functions）
• データの保存（Firestore）

以前、AWSのAmplifyは使ったことがありましたが、 Firebaseは、認証、Functions、Firestoreをまとめて扱えるので、個人開発ではかなり相性がよいと感じました。

ローカル開発環境の進化

今回、一番の驚きは Firebase Emulator Suite の存在でした。 認証やデータベース、バックエンドの関数まで、全てを手元のローカル環境で再現して動かせる。モノレポ構成でも挙動の確認が容易で、限られた時間で作業する身には、この「ローカルで完結する」スピード感は本当に助かりました。

また、開発効率を上げるためにツールへの投資も惜しまないことにしました。 具体的には、 AntigravityとGeminiの課金版（月額3,000円ほど） を使っています。 無料枠でも試せるのですが、実際に開発を進めているとすぐ制限に当たったので、途中からは課金して使うようにしました。結果として、開発のテンポはかなり上がったと思います。

2025年に購入した Mac mini も、エミュレータを回しながらの作業に全くストレスがなく、頼れる相棒になっています。

デプロイ方法とAIによるエラー解決

フロントエンドは「Firebase App Hosting」を使い、GitHubへの git push で自動反映されるようにしています。一方で、Cloud Functions はCLIから個別にデプロイする形です。方法が分かれているのは最初は少しややこしく感じましたが、慣れてしまえば特に困ることはありません。

デバッグについても、最近はエラーログをそのままAIに貼って解決策を聞くことが増えました。 以前なら数時間かかっていた原因調査が、数分で終わってしまう。便利すぎて「自分でログをじっくり読む力」が少し鈍っているかも、という危機感はありましたが、余った時間を純粋な要件出しに回せるようになったのはいい変化だと思っています。

最初の構成はかなり雑だった

最初から今の構成だったわけではありません。初期の段階では、クライアント側から直接AI APIを呼ぶような作りにしていました。

しかし、それでは通信を見れば誰がAIか一発で分かってしまいますし、セキュリティ的にもお話になりません。そこからロジックをバックエンド側に移し、徐々に「公開できる形」に寄せていきました。

振り返ると、環境構築やモック作成といった「0から1」は爆速でしたが、そこから公開レベルまで「1から10」に仕上げる部分には、やっぱり泥臭い時間がかかりました。開発全体を振り返ると、

• 環境構築〜モック作成：1
• 構成整理：2
• 画面・周辺実装：2
• AI会話調整：3
• 公開前のセキュリティ対策：2

くらいの感覚です。

最初に動くものを作るのは速くなりましたが、そのあとに「ちゃんとした構成に直す」「公開できる状態に持っていく」部分には普通に時間がかかりました。 また、実装だけでなく、画面構成や仕様の整理といった企画面でもGeminiやChatGPTをかなり使いました。
そのおかげで、手を止めずに考えながら進めやすくなり、実装以外の部分にも以前より時間を使えたと思います。

アイコンの実装

プレイヤーアイコンには、getavataaars.com の素材を使っています。（商用利用フリー）

組み合わせ自体はかなり多いのですが、今回はそこからいくつかを選び、

• 男女3種類ずつ
• 背景色6パターン

という形で使っています。

この画像取得についても、スクリプトを作りながら進めました。
必要があればコードも載せたいと思っています。

意外と悩んだ「プレイヤー名」の設計

ゲーム画面に表示されるプレイヤーの名前。ここは、実装の中で意外と時間をかけて悩んだ部分です。

最初は「自由に決められるのが一番だろう」と考えていました。しかし、そうなると人間側が自分の名前を工夫しすぎて、逆にAIが名前だけでバレやすくなってしまうという問題に気づきました。

次に「リス」や「犬」のような動物の名前をランダムに割り当てることも考えましたが、そうすると今度は、プレイヤーの発言のイメージが名前に引っ張られてしまいます。「リスっぽい発言」を期待されてしまうのは、ゲームとして不自然です。

また、「苗字＋名前」のフルネーム表示も試しましたが、2分という短時間のチャットの中では情報量が多すぎて、名前を覚えるだけで脳のリソースが削られてしまいます。

辿り着いた「苗字のみ」という解

最終的には、消去法で「日本でよく見る苗字（100種類ほど用意）」をランダムに割り当てる形に落ち着きました。

ここでもう一つ工夫したのが、 「同じ部屋の中で、漢字が被らないようにする」 という処理です。 テストプレイ中に「中山、中田、山田」が同じ部屋に揃ってしまったことがあり、パッと見た瞬間に誰が誰だか混乱してしまいました。

現在は、4人のプレイヤーの苗字から、どの1文字も重複しないようにロジックを組んでいます。一見地味な処理ですが、快適に遊んでもらうためには欠かせない調整でした。

余談：Antigravityの暴走？

なぜかたまに思考過程が表示されることがありますが、無限ループに陥っているようなこともあります。（なんなんだこれ・・）

まとめ

今回の構成は、Next.js、Firebase、Geminiという比較的扱いやすい組み合わせに寄せています。派手さはありませんが、

• Firebaseで全体をシンプルにまとめられたこと
• 有料ツールを活用して開発の「勢い」を維持したこと
• 名前の重複回避など、人間がこだわるべき細部に時間を使えたこと

など、個人開発としては、かなり無理のない構成にできたと思っています。

同じような構成で何か作ろうとしている方の参考になればうれしいです。