ユーザーの意見を集めて毎日自動開発・デプロイされるWebゲーム制作記

ユーザーのフィードバック項目を集めて、その翌日に配布されるコンセプトでWebゲームを作ってみました。
AIツールに慣れるために作ってみたプロジェクトで、GitHubも公開しているので気軽にご覧ください。
game: https://spiralwave.frogred8.dev
github: https://github.com/frogred8/SpiralWave

• プロジェクト概要と企画
  • 動機と目的: 進化したAIツール（Geminiなど）を活用したバイブコーディング実験と、使ったことのない技術を適用したWebゲーム開発の試み。
  • 開発方針: ユーザーの意見が毎日自動で反映される「時間制限付き資源収集型」ミニWebゲームに決定。
• 初期プロトタイプの作成
  • コアコンセプト: 競争や損失のない資源収集とスキルツリー構築ゲーム。
  • AI活用: 紙のスケッチをプロンプトに変換し、TypeScript、Vite、Phaserベースの基本的なゲーム構造を30分で実装。
• 複雑なロジック実装の限界と直接対応
  • スキルツリー開発: 基本的な前提スキルロジックはAIで実装したが、中間ノードを取り消すと下位ノードが連鎖的に取り消される複雑なロジックはAIでは解決できず、直接実装。
  • テストコード省略: 頻繁な設計変更と高速な開発速度のため、意図的にテストコードを書かずに進行。
• 大規模リファクタリングとAIデバッグの特性
  • UI分離作業: 単一ファイルの肥大化によりUIコードを分離したが、統一性と構造的な満足度は低く、大きな作業ではプロンプトを補強して再作業する方式が有効だと確認。
  • 実行順序バグ: リファクタリング後に発生したランタイムエラー（状態更新とUI表示の順序が入れ替わる）に対してAIはガードコードを乱発するだけで、結局は人間の開発者が流れを把握してコード2行を修正し、簡単に解決。
  • AIのミスが比較的人間的で、不思議な感覚を覚えた。
• Git自動コミットとガイド適用
  • プロンプトガイド構築: 繰り返し指示する煩わしさを減らすため、技術スタックと動作方式を整理したガイドファイル（GEMINI.md）を導入。
  • 自動化ワークフロー: コード作業完了後、エージェント稼働時間、指示プロンプト、作業要約を含むコミットメッセージを自動生成するよう設定し、単純なレビュー工数を削減。
• 自動更新アーキテクチャ設計と最適化
  • デプロイ方式の転換: 当初構想していた2時間単位のリアルタイム自動デプロイは、ランタイムバグ発生率の高さ（約25%）でビルド安定性が低かったため断念し、別途日次テストビルドを生成・配布する方式に決定。
  • Cronワークフロー: node:cronを活用し、「フィードバック収集 → 整理 → コード生成 → ビルドとリリース生成 → デプロイ」へとつながるモノリシック構造の自動化プロセスを構築。
  • リリースノート更新: Dockerインスタンス間でサーバー一覧ファイルを共通ボリュームとして共有し、5分の有効期限キャッシュを適用して負荷を制御。また、ユーザーの多言語リクエストを英語に整理した後でもう一度翻訳し、リリースノートとして表示するよう実装。
• 開発中に除外された機能
  • リーダーボードの意見推薦（Like）機能（識別子不在とAPI呼び出しコスト負担）。
  • 精巧なスキルデータ管理ツール（想像力の限界と、JSONを直接修正するほうが効率的）。
  • サービス別Docker分散環境の構築（運用・管理の複雑さを最小化するため1つのイメージに統合）。
  • ユーザー意見反映時のメール通知機能（会員登録なしのメール収集の有効性と、なりすましリスク）。
  • サイド広告の追加（プラットフォーム承認手続きの負担感と、低単価に対して効果が乏しいこと）。
• AIベース開発の所感
  • 生産性とテストのトレードオフ: 開発実装速度は約10倍に増えたが、検証（QA）にかかる時間と疲労も比例して大きくなる限界に直面。
  • コード品質の特徴: 関数単位の完成度は高いが可読性が低く、全体の流れを把握しづらい一方で、局所的なハードコーディングが有利な状況でも不要に肥大化した一般化パターンを導入する傾向を確認。

[recast7838]

面白いですね