「ミニゲームゲームズ」では、3日以内に必ず1本公開する、というサイクルでゲームを作っています。短い期間で作って出すには、道具を増やしすぎないことが何より大事でした。この記事では、実際に十本以上を作ってきたいまの構成を、正直にそのまま書きます。派手なものは一つも使っていません。
まず前提として、このお店のゲームはすべてブラウザ内だけで動き、外部ライブラリをできるだけ使いません。素の JavaScript で書けるものは書く。そうすると、ビルド工程がなく、ファイルを開けば動き、長く壊れずに動き続けます。個人が1人で量産するなら、この「軽さ」が回転数に直結します。
特別なワークステーションは使っていません。ふつうの Windows デスクトップ1台です。3Dゲームも扱いますが、ここで作っているのはブラウザで軽く動く規模なので、ハイエンドGPUは必須ではありません。長時間コードと向き合うので、効いてくるのは画面の広さと、キーボード・マウスの快適さのほうでした。
実装の主役は AI コーディング環境の Claude Code です。仕様を渡すと、ロジックの実装・テストの作成・ブラウザでの動作確認までを一気に進めてくれます。私（運営者）の役割は、企画を決め、仕様書を書き、出てきたものをレビューして公開判断をすること。「1人でチームを持つ」感覚に近く、これが1日1本を可能にしている一番大きな要素です。
コツは、あいまいな指示を投げないこと。ルール・勝敗条件・品質ゲート（何をテストで保証するか）を最初に言語化して渡すと、手戻りが激減します。ここは AI 任せにできない、人間側の仕事です。
立体を扱うゲーム（空間認識テスト、影当て、積みバトルなど）では three.js を使っています。WebGL を直接書くより圧倒的に速く、それでいてブラウザだけで完結します。使うのは基本図形とライトくらいで、凝ったことはしていません。「読める・軽い」を優先しています。
three.js は日本語の情報も増えてきましたが、体系立てて学ぶなら書籍が結局いちばん早い、というのが実感です。
「動いたつもり」で公開して壊れているのが一番こわいので、公開前に必ず自動チェックを通します。ゲームの中核ロジックは three.js に依存しない純粋な JavaScript として切り出し、Node.js でテストします。UI は Playwright でブラウザを自動操作し、実際にプレイして「エラーが出ないか・崩れないか・スマホで横スクロールしないか」を確認します。この2段構えで、公開してから気づく事故をだいぶ減らせました。
公開先は GitHub Pages です。作品ごとにリポジトリを分け、push すればそのまま世界に出ます。サーバー代はかからず、静的ファイルを置くだけ。個人が数を出すには、この「タダで・すぐ・壊れにくい」公開先が向いています。作品を並べる店頭（このサイト）もここに置いています。
並べてみると分かる通り、特別な道具は何もありません。ふつうのPC、AIコーディング、three.js、テスト、無料の公開先。むしろ大事なのは、「小さく作って、必ず出して、反応を見て、ダメなら畳む」を回し続ける仕組みのほうでした。道具は最小限にして、その分を「企画と公開の回数」に振り向ける——これが、AIと一緒に1日1ゲームを続けるための、いまの結論です。