はじめに

先日、知人たちとボードゲームを遊ぶ機会がありました。
そのゲームが盛り上がりまたやりたいという話が出たのですが、そのゲームの流通量は少なく、また対面でのプレイとなると遊べる機会も限られます。
そこで今回は、非エンジニアの知人グループが気軽にオンラインボードゲームを自作できるようなプラットフォームを開発してみました。

具体的には以下のような仕組みです：

ユーザーがブラウザ上でゲームのアイデアを投稿
GitHub Actions 経由で Claude Code が自動起動
AI がゲームロジックを実装し、PR を作成
検証環境で検証 → 承認で本番反映

非エンジニアが使えるよう、GitHub やコードといった技術的な要素を全て隠蔽しています。

全体構成

レイヤー	技術
フロントエンド	React + Vite + Tailwind CSS
フロントエンドホスティング	Cloudflare Pages
バックエンド	Cloudflare Workers + Hono
データベース	Supabase PostgreSQL
リアルタイム通信	Supabase Realtime
認証	Supabase Authentication
CI/CD	GitHub Actions
AI 実装	Claude Code

Cloudflare と Supabase はどちらも無料枠が充実しているため、個人プロジェクトでも継続運用しやすい構成です。

認証に Supabase Authentication を採用したのは、Supabase Realtime
との親和性が高いためです。同じクライアントでリアルタイム通信と認証を扱えるため、実装がシンプルになります。

運用フロー

ユーザー視点のフロー

1. ブラウザでゲームのアイデアを投稿
2. しばらく待つと「検証できます」と通知が届く
3. 検証環境でゲームをプレイ・検証
4. 承認 or コメントをつけて差戻
5. 承認すると本番環境に反映、差戻すると2に戻る

内部で起きていること

ユーザーがゲーム要望を投稿
  ↓ API が GitHub Issue を自動作成 + wip ラベル付与
  ↓ GitHub Actions で Claude Code が起動
  ↓ AI がゲーム定義を実装 → ブランチ作成 → PR 作成
  ↓ 検証環境に自動デプロイ
  ↓ 検証 URL を Issue コメントに通知 → UI に表示
ユーザーがプレイ・検証
  ↓ 「承認」→ API が PR をマージ → 本番デプロイ
  ↓ 「差し戻し」→ Issue にコメント追加 → Claude Code 再実行

デプロイフロー

3 つの GitHub Actions ワークフローで自動化しています。

1. implement.yml（実装）

Issue に wip ラベルが付くと Claude Code が起動します。

on:
  issues:
    types: [opened, labeled]

jobs:
  implement-game:
    runs-on: ubuntu-latest
    if: |
      (github.event.action == 'opened' &&
      contains(github.event.issue.labels.*.name, 'wip')) ||
      (github.event.action == 'labeled' && github.event.label.name == 'wip')
    steps:
      - name: Run Claude Code
        uses: anthropics/claude-code-action@beta
        with:
          claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
          direct_prompt: |
            ## タスク
            1. Issueから要望を解析
            2. 実装
            3. ブランチを作成してコミット・プッシュ
            4. PRを作成

Claude Code Max プラン（OAuth 認証）を使用しているため、API キーではなく
claude_code_oauth_token を指定しています。

Note: OAuth トークンは Claude Code の Max プラン契約が必要です。取得方法は公式ドキュメントを参照してください。

2. preview.yml（検証環境）

PR が作成・更新されると自動で検証環境にデプロイされます。

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  deploy-preview:
    runs-on: ubuntu-latest
    steps:
      # API を Cloudflare Workers にデプロイ
      - name: Deploy API to Preview
        run: wrangler deploy --env preview

      # フロントエンドを Cloudflare Pages にデプロイ
      - name: Deploy to Cloudflare Pages
        uses: cloudflare/pages-action@v1

      - name: Update Issue
        # review ラベルを付与

3. production.yml（本番環境）

PR がマージされると本番環境にデプロイされます。

on:
  push:
    branches: [main]

jobs:
  deploy-production:
    runs-on: ubuntu-latest
    steps:
      - name: Deploy API
        run: wrangler deploy

      - name: Update Issue
        # done ラベルを付与して Issue をクローズ

ラベルによる状態管理

Issue のラベルで受け付けたアイデアの状態を管理しています。

ラベル	状態	トリガー
`wip`	開発中	ユーザーがアイデアを投稿 or 検証で差戻
`review`	検証待ち	Claude Codeによる実装完了 & 検証環境デプロイ完了
`done`	完了	ユーザーが承認 & 本番デプロイ完了

Issueの作成やラベルの更新は、Web UIから叩いたAPIやGithub Actionsを通して実行されます。

リアルタイム同期

複数人でゲームをプレイするため、リアルタイム同期が必要でした。

Cloudflare Workers 単体で WebSocket を実装する場合、Durable Objects が必要になります。しかし
Durable Objects は無料枠がかなり厳しいため、Supabase Realtime を採用しました。

supabase
  .channel(`game_states:session_id=eq.${sessionId}`)
  .on('postgres_changes',
    { event: '*', schema: 'public', table: 'game_states' },
    (payload) => {
      // 他プレイヤーの操作をリアルタイム反映
    }
  )
  .subscribe();

Supabase Realtime は PostgreSQL の変更を WebSocket で配信してくれる機能で、無料枠に含まれています。

設計判断のポイント

招待制によるアクセス制限

ユーザー操作をトリガーに Claude Code や GitHub Actions が起動する仕組みのため、以下のリスクがあります：

悪意あるプロンプトによる意図しない操作
API 使用量の急増によるコスト増加
GitHub Actions の実行時間制限の消費

そこで招待リンク経由でのみログイン可能な構成にし、信頼できるユーザーのみに利用を制限しています。

検証環境の活用

検証環境へのデプロイまでをAIによる自動作業、本番環境へのデプロイを人間による承認必須とすることで、ほとんどAIと非エンジニアによる運用想定ながら、本番環境は安全な状態を維持できるようにしています。

ランニングコストの抑制

このプラットフォームの運用にかかる費用は以下です：

Claude Code: 月額固定（もともと契約していたもの）
ドメイン: Cloudflare 経由で購入（年間数ドル）

それ以外は身内での利用なら無料枠に十分収まります：

Cloudflare Workers / Pages
Supabase
GitHub Actions

使ってみた感想

実際にこのプラットフォームからゲームを実装してみた所感です。

難しくないルールのゲーム（独自のボードやコマがいらないもの、トランプゲーム等）であれば、動くところまでは割とすんなりいけます。ただし演出や UI の作り込みは苦手な印象でした。「分かりやすいUI」「気持ちいいアニメーション」といった正解が明確でない領域は、AI にとってまだ難しいようです。

そのため、ユーザーが満足するレベルまで仕上げようとすると、どうしてもフィードバックの回数が多くなります。当初の目論見であった「Webフォーム経由で非エンジニアが自由に機能拡張していく」という使い方は、できなくはないものの時間がかかりすぎる印象でした。本格的な実用ラインにはまだ届いていないと感じています。

プロトタイピングとしては十分使えますが、クオリティを上げるのであれば、最初にしっかりしたエンジンやテンプレートツールを作っておくか、AIの性能向上を待つことになりそうです。

以上です。
最後まで読んでいただきありがとうございます。