お笑いグランプリの運営システムをバイブコーディングした
お笑いの大会の運営を、1 か所で回せる仕組みが欲しかった。大会は、エントリーを受け付けたあとも仕事が続く。入金を確かめ、審査員に動画を採点してもらい、結果を連絡して、決勝の観覧チケットを売る。フォームやスプレッドシートやメールを組み合わせれば回るが、そのあいだを人が手で埋めることになる。
その大会が、福岡社会人お笑いグランプリだ。働きながらお笑いに取り組む人のための大会で、2025 年に始まり、今年が 2 回目になる。予選はネタ動画だけで審査し、通った 9 組が 12 月 5 日に箱崎の AIWA HALL の舞台に立つ。私は運営を手伝っていて、今年は趣味の延長で、この大会の公式サイトと運営メンバーが使う管理画面を作った。公式サイトは plusfun.jp/grandprix2026 にある。管理画面は関係者しか使わないので、公開していない。
私はエンジニアではない（基本情報技術者試験くらいの知識はある）。コードは AI に書いてもらった。最初の土台は Codex で、8 月 30 日からは Claude Code が中心だ。いわゆるバイブコーディングである。決勝の観覧チケットの販売まで形になったので、エンジニアでない人がいま AI に運営システムを作らせるとどうなるのかを書き残しておく。
まずは公式サイト
8 月 21 日に作り始めた。頼んだそばから画面が増えていくのが楽しくて、22 日の夜に公式サイトと管理画面がそろったときには、もうほとんど終わった気でいた。大会の説明、エントリーのフォーム、お知らせ、お問い合わせ、それに運営が応募を見る画面まである。実際は、ここからが長かった。
デプロイナウ
ホスティングは、ロリポップ！デプロイナウの無料プランにした。去年までは、ほかの大会の LP を Vercel の Pro プランで出していたが、個人には大げさだった。デプロイナウは無料でも独自ドメインが付けられ、商用利用もできる。なお、勤務先の GMO ペパボのサービスなので、そこは差し引いて読んでほしい。
エントリー開始の前夜には、本番でだけ起きることが 2 つ続いた。まず、www 付きのアドレスから入ると、管理画面にログインできない。サーバーに届くホスト名がデプロイナウの内部のものだったので、www 付きを www なしへ転送する条件に一度も当てはまっていなかった。ログインのあと Google からは www なしのアドレスに戻されるのに、クッキーは www 付きのほうに付いているので、ログインの確認が通らない。
日付が変わった 0 時過ぎには、掲載したお知らせが一覧に出てこなくなった。デプロイナウ側が、いちど作ったページを長くキャッシュに残していた。エントリー開始の 9 時間ほど前だった。
10 月に入ってからは、無料プランの CPU 時間（月 4 時間）を 18 日間で 96% 使っていたと分かった。慌てて Claude Code に原因を探してもらった。画像が開かれるたびに、サーバーで WebP に変換し直していた。いまは変換済みの画像を先に置いている。
Google ログイン
ログインでは、1 日つぶれた。管理画面には、運営メンバーが Google のアカウントで入る。8 月 24 日、入った人が誰なのかが、データベースの Convex にうまく伝わらなかった。自分のパソコンで動かしても原因が分からないので、本番で何が起きているかを見るためだけのコミットを何本も入れ、様子を見ては直した。
9 月の終わりには、パソコンとスマホで同時に管理画面を開いたら、片方で入るたびにもう片方が弾かれた。ログインに使っている Auth.js が、そのつどユーザー ID を振り直していた。Google のアカウントに固定で付いている ID を使うように変えて、ようやく収まった。
Resend
メールは Resend で自動で送り、返信は管理画面のお問い合わせに入る。無料の枠では 1 日に送れる数が限られるので、結果のメールを全組に送る日は、ほかの一斉送信を重ねないようにしている。
Claude API
予選の結果は 10 月 18 日に発表した。決勝に残らなかった組にも、エントリーしてよかったと思ってもらいたい。そこで管理画面から Claude を呼んで、審査員の採点コメントを組ごとに一言にまとめさせ、結果のメールに入れることにした。
作ってみると、4 組まとめて頼んだときに 1 組しか返ってこない。最初はレート制限を疑ったが、外れだった。max_tokens（返事の長さの上限）が小さすぎて、Claude は答える前の thinking でそれを使い切っていた。その上限を書いたのも Claude Code である。直したあとは、Claude がまとめた一言を運営が 1 組ずつ読んで確かめ、発表の翌日にメールを送った。
Square
決済では、払ったお客さんの席まで手放してしまう作りに、あとから気づいた。
10 月半ばに、決勝の観覧チケットをカードで先に払えるようにすることにした。決済は Square にした。来年はエントリー料もカードで受けたいので、その先まで使えるものを選んだ。アカウントは主催の名義で作ってもらい、私は開発者として加わった。売上も主催の口座に入る。アクセストークンは Square の管理画面で作り、私が貼り付けて設定する。AI が見るのは、設定に名前が入ったかどうかだけだ。
決済のページを作る処理と、Square から支払いの通知を受ける処理は、その日のうちにできた。2 日後、決済まわりを見直していて、まずい作りに気づいた。Square からの通知が 30 分届かないと、お客さんがもう払っていても予約を期限切れにして、席を手放してしまう。期限切れにする前に Square の支払いの記録を読みにいくようにして、すぐ本番に出した。チケットをまだ売り始める前だったのが救いだった。
決済で何か起きても、私がすぐ見られるとは限らない。そこで数日後、1 時間ごとに Square と予約を自動で突き合わせる処理を入れた。全額返金されていれば予約を取り消し、おかしなものがあれば運営あてにまとめてメールを送る。運営がカード払いを止められるスイッチと、そのメールが届いたときの手順をまとめたページも作った。
データベースと定期実行
データベースは最初から Convex に任せていて、席を 30 分で空ける、1 時間ごとに突き合わせる、毎朝お知らせを送る、といった定期実行も同じ場所に書ける。おかげで、そのためのサービスを足さずに済んだ。大きくつまずいたのは、使わなくなったテーブルを消そうとしてデプロイが止まった 1 回くらいで、2 分後に元に戻した。
ひとことで言うと
作り始めは速くて楽しいが、本物の運営に使うところからが大変だった。ログイン、配信、メール、決済、AI と、外のサービスを順につなぎ、API キーを作り、設定を合わせていく。www のログインも、お知らせのキャッシュも、CPU も、自分のパソコンでは起きず、本番に出してから分かった。
そのつなぎ目にも、AI の手はかなり届く。Convex もデプロイナウもコマンドで操作でき、デプロイするのもデータを読むのも AI に任せられる。公開ページなら、AI が自分でブラウザを開いてスクショまで撮ってくる。
私がやったのは、外のサービスの管理画面で設定し、API キーを作って入れ、ログインが要る画面を開いて確かめることだった。AI はエラーにならない間違いもするので、出来たものを見て「これ変じゃない？」と言う役も残る。最近も、運営メンバーに届くメールの差出人が「福岡社会人お笑いグランプリ 管理画面」になっていた。管理画面からメールが来るのは変なので、運営団体の名前を取って「+Fun 運営システム」にした。
これから
ログインでつまずいた日に様子見のコミットを重ねたのは、デプロイナウのサーバーで何が起きているか（実行中のログ）を、AI が直接見られなかったからだ。CPU も、96% になってから気づいた。サーバーのログと使い具合を AI が読めて、使いすぎる前に知らせてくれれば、あの 2 回はもう少し早く片付いたと思う。
管理画面には、ヘルプの記事と、それを読んで答える「AI に聞く」を入れた。プロジェクトの管理者に、次にやる準備を 1 つずつメールで知らせる仕組みも用意した。私以外の人が操作するときも、ヘルプを見ながら自分で進めてもらえればいい。
ただ、そもそも運営の人に管理画面の使い方を覚えてもらう必要はあるのだろうか。入金の確認も、結果のメールも、いまは運営が画面を開いてボタンを押している。「今日やることを片付けて」と AI に頼めば済むなら、画面はもっと少なくていい。いまの「AI に聞く」は手順を返すところまでだが、次はそこを目指したい。
受付から入金、採点、結果の連絡、観覧チケットまで、ひとまず 1 か所で扱えるようになった。決勝は 12 月 5 日。何事もなく終わりますように。