エンジニアが新婦のために結婚式にITで全力で貢献しようとした話【連載第1回】なぜ結婚式に「IT」で貢献しようと思ったのか
エンジニアが新婦のために結婚式にITで全力で貢献しようとした話
〜Next.js + Supabase で40人のゲストが熱狂する結婚式を作りたい〜
🎯 この連載で得られること
この連載を読むと、「1回限りのイベント」向けフルスタックシステムの設計・実装・運用を追体験できます。
- ✅ Next.js 15 (App Router) + Supabase の実践的なアーキテクチャ設計
- ✅ AWS Rekognition を使ったリアルタイム顔認識写真システム
- ✅ チップ経済圏のゲームデザインと不正対策
- ✅ パリミュチュエル方式ベッティングの実装
- ✅ 40人が同時接続する本番環境の設計・テスト・運用ノウハウ
- ✅ 約9,000円で作るフルスタックイベントシステムの全貌
😰 「記憶に残る二次会」って、ありますか？
2025年の秋、僕は婚約者と二次会の打ち合わせをしていました。
「ビンゴ大会にする？」
「いや、前に出た二次会でビンゴ30分やって、全然当たらなくて退屈だった」
「じゃあ新郎新婦クイズ？」
「うーん、それも何回もやったことあるし...」
彼女の表情を見て気づきました。結婚式は新婦にとって特別な一日です。その一日を、「よくある二次会」で終わらせたくない。
結婚式の二次会に何十回と参加してきましたが、正直に言えば記憶に残っている二次会は一つもありません。
景品が豪華だったかもしれない。クイズが盛り上がったかもしれない。でも、「あの二次会は最高だった！」と語り継がれるような体験は、なかなかありません。
「彼女に、"あの結婚式は最高だった"と言われる一日を贈りたい」
エンジニアにできることは、コードを書くことです。ならば、ITの力で記憶に残る結婚式を作ろう。そう思い立ったのが、このプロジェクトの始まりでした。
この連載は、新婦に最高の一日を贈りたいという想いから始まったプロジェクトが、3ヶ月の開発期間、54のマイグレーションファイル、12のEdge Functionを経て、当日40人のゲストが熱狂するシステムになるまでの全記録です。
📖 二次会の「つまらなさ」をエンジニアリングで分析する
エンジニアらしく、まずは既存の二次会ゲームの問題点を洗い出しました。
ビンゴの問題
- 受動的：番号が呼ばれるのを待つだけ。自分から何もできない
- 運任せ：戦略も技術も関係ない。上手い下手がない
- 全員横並び：上位・下位の差がつかないから物語が生まれない
- 長い：30分以上かかることも。その間、ずっと座っている
新郎新婦クイズの問題
- 知識格差：友人は有利、会社関係は不利。平等じゃない
- 盛り上がりが一瞬：正解発表の瞬間だけ。次の問題まで退屈
- リプレイ性なし：一度答えたら終わり。追い上げも逆転もない
共通の問題
- スマホを見る時間：暇だからSNSを見始める。ゲスト同士の交流が生まれない
- 参加している感覚がない：抽選に当たらなければ「観客」で終わる
- 写真を撮るモチベーション：「あとで見返すかも」程度。積極的には撮らない
これらを一言でまとめると、従来の二次会ゲームは「受動的」で「運任せ」で「退屈な時間が長い」。
これはゲームデザインの問題です。ゲームデザインの問題なら、エンジニアリングで解決できるはず。
💭 3つのコンセプト：「設計」で解決する
問題を分析した結果、3つの設計コンセプトにたどり着きました。
コンセプト1：「遅延報酬」で披露宴と二次会をつなぐ
披露宴は感動と思い出の場。ゲームで盛り上げる場ではありません。
一方、二次会は「お祝い + エンターテイメント」の場。
この2つは、普通は完全に切り離されています。でも、ここを一つのストーリーとしてつなげたらどうだろう？
「披露宴での行動が、二次会の軍資金になる」
具体的には：
- 披露宴で写真を撮ると、裏でチップが貯まる（画面には表示しない）
- 二次会の冒頭で「披露宴での貢献がチップになりました！」と発表
- ゲストは「写真撮っておいてよかった！」となる
この遅延報酬の仕組みが、披露宴と二次会を一つの物語としてつなぎます。
何が重要かというと、披露宴中にゲームの存在を意識させないことです。披露宴はあくまで感動の場。写真を撮る行為自体が自然に報酬につながる設計にしています。
コンセプト2：「能動参加」で暇な時間をゼロにする
ビンゴのような「待つゲーム」ではなく、自分から行動を起こすゲームを設計しました。
- 誰かと対戦したければ、QRコードをスキャンして挑む
- チップが欲しければ、写真を撮る、対戦で勝つ、ドリンクを飲む
- ランキングを上げたければ、積極的に行動する
「暇な時間」を作らない。これが2つ目のコンセプトです。
会場にいる40人全員が、常に「次に何をしようか」と考えている状態。ビンゴのように「次の番号が呼ばれるまで待つ」時間を、ゼロにしたい。
コンセプト3：「リアルタイム性」で行動と結果を直結させる
会場のスクリーンには常にランキングやスライドショーが表示されます。
- 自分が撮った写真が数秒後にスクリーンに映る
- 対戦で勝つと即座にランキングが上がる
- 祝福メッセージを送るとリアルタイムで花火エフェクトが表示される
**「自分の行動が会場を動かしている」**という感覚。
これが参加者意識を高め、「観客」を「プレイヤー」に変えます。アクションゲームと同じで、ボタンを押した瞬間にキャラクターが動くから楽しいのです。入力と出力の間にタイムラグがあったら、つまらない。
🔧 システム全体像
アーキテクチャ
┌─────────────────────────────────────────────────────────────┐
│ ゲスト（40名） │
│ スマートフォン │
└─────────────────────────────────────────────────────────────┘
│ HTTPS
▼
┌─────────────────────────────────────────────────────────────┐
│ Vercel (Frontend) │
│ Next.js 15 App Router │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │/reception│ │ /casino │ │/coliseum │ │ /ranking │ │
│ │ 披露宴 │ │ 二次会 │ │ベッティング│ │ランキング│ │
│ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ Supabase (Backend) │
│ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────────────────┐ │
│ │ Auth │ │Database│ │Storage │ │ Edge Functions │ │
│ │ 匿名認証│ │PostgreSQL│ │ 写真 │ │ ・verify-pin │ │
│ └────────┘ └────────┘ └────────┘ │ ・analyze-face │ │
│ │ │ ・register-face │ │
│ Realtime └────────────────────┘ │
│ (WebSocket) │ │
└────────────────────────────────────────────┼─────────────────┘
│
▼
┌────────────────────────────────┐
│ AWS Rekognition │
│ ・顔認識（Face Collection） │
│ ・ラベル検出（不正画像判定） │
└────────────────────────────────┘
機能一覧
披露宴モード（白を基調としたエレガントなUI）
| 機能 | 説明 |
|---|---|
| 写真アップロード | HEIC対応、複数枚一括、AI分析で自動タグ付け |
| My Album | 顔認識で「自分が写っている写真」を自動収集 |
| スライドショー | Ken Burns Effectで写真を投影、優先度スコアリング |
| 顔認識登録 | アバター写真からAI学習 |
二次会モード（黒×ゴールドのカジノUI）
| 機能 | 説明 |
|---|---|
| 1vs1対戦 | QRスキャンで1対1チップ勝負 |
| バトルロイヤル | 最大10人の生き残り戦 |
| チップ移動 | PayPay方式のQRチップを贈る |
| テーブルゲーム | NFC座席管理のポーカー風ベッティング |
| バー端末 | ドリンク交換でチップ獲得 |
盛り上げ機能
| 機能 | 説明 |
|---|---|
| The Coliseum | パリミュチュエル方式ベッティング（競馬のようなオッズ変動） |
| 祝福メッセージ | 3カテゴリ（お祝い/質問/アドバイス）で新郎新婦にメッセージ |
| チーム対抗戦 | RED vs BLUE の自動振り分け |
| ランキング | リアルタイム順位表示（個人・チーム・所属別） |
エピローグ機能
| 機能 | 説明 |
|---|---|
| 称号システム | カジノ王、伝説のカメラマン等 |
| 統計表示 | 最終順位、撮影枚数、被写体回数 |
| 思い出ギャラリー | 全写真閲覧・一括ダウンロード |
規模感: 54マイグレーション、12 Edge Functions、100以上のルート。
技術スタック選定：なぜこの組み合わせなのか
Next.js 15 (App Router)
選定理由：
- Server Components で初期表示が高速
- Server Actions でフォーム処理がシンプル
- Vercel へのデプロイが一瞬
結婚式特有の事情：
ゲストのスマホは様々です。iPhone 8の人もいれば最新機種の人もいる。会場のWiFiは不安定。そして何より、結婚式の場で「読み込み中...」の画面を見せるのは失礼です。
SSR + Edge で、どんな端末でも高速に表示される設計を選びました。
Supabase
選定理由：
- PostgreSQL の信頼性
- Realtime が標準装備（これが決め手）
- RLS でセキュリティ担保
- Edge Functions で柔軟なサーバーロジック
結婚式特有の事情：
乾杯の直後、40人全員が同時にアクセスする瞬間があります。ランキングはリアルタイムで更新されてほしい。写真アップロードが集中する時間帯がある。
Supabase の Realtime 機能が、これらすべてに対応できると判断しました。
AWS Rekognition
選定理由：
- 顔認識の精度が高い
- Face Collection で「この人が写っている写真」を検索可能
- 不正画像（スクリーンショットなど）の検出
結婚式特有の事情：
「自分が写っている写真」を自動で見つけたい。これはゲストにとって最も嬉しい機能です。そして、ネットから拾った画像をアップロードしてチップを稼ぐ不正も防ぎたい。
Rekognition の IndexFaces + SearchFacesByImage の組み合わせで、これを実現しています。
技術スタック比較表
| カテゴリ | 選定技術 | 他の候補 | 選定理由 |
|---|---|---|---|
| Frontend | Next.js 15 (App Router) | Remix, Astro | SSR + Server Actions + Vercel親和性 |
| UI | Tailwind CSS | CSS Modules, styled-components | 高速開発、レスポンシブ対応が容易 |
| 認証 | Supabase Anonymous Auth | Firebase Auth | ゲストに会員登録させない |
| DB | Supabase PostgreSQL | PlanetScale, Neon | RLS + Realtime + Edge Functions が一体 |
| Storage | Supabase Storage | S3, Cloudflare R2 | DB連携がシームレス |
| AI | AWS Rekognition | Google Vision, Azure Face | Face Collection の精度と使いやすさ |
| Hosting | Vercel Pro | Cloudflare Pages | Next.js との親和性、エッジ配信 |
| E2Eテスト | Playwright | Cypress | マルチブラウザ、安定性 |
開発コスト
| 項目 | 金額 |
|---|---|
| Supabase Pro（1ヶ月） | $25 |
| Vercel Pro（1ヶ月） | $20 |
| AWS Rekognition | 約$5（40人 x 数枚） |
| ドメイン | 約$10/年 |
| 合計 | 約$60（約9,000円） |
9,000円で、40人が熱狂するフルスタックシステムが作れる時代です。
開発タイムライン
| 時期 | 内容 | 気持ち |
|---|---|---|
| 2025年10月 | 企画開始、技術選定 | 「これは面白くなるぞ」 |
| 2025年11月 | DB設計、認証システム | 「テーブル設計って楽しい」 |
| 2025年12月 | 写真システム、顔認識 | 「Rekognition すごい！動いた！」 |
| 2026年1月 | カジノ機能、対戦システム | 「機能が増えてきて複雑に...」 |
| 2026年1月末 | E2Eテスト、負荷テスト | 「テスト書くのは大事」 |
| 2026年2月 | The Coliseum、テーブルゲーム、最終調整 | 「完成が見えてきた」 |
| 2026年4月5日 | 本番当日 | 「...緊張してきた」 |
この記事を書いている今、本番まであと50日。
システムは9割完成。残りの1割は、本番前の最終テストと微調整です。そして、この連載を書くことで開発の振り返りもしていきます。
🎓 この連載の構成
全14回で、システムの全貌を解説します。
| 回 | タイトル | 内容 | 公開 |
|---|---|---|---|
| 第1回（本記事） | なぜ結婚式に「IT」で貢献しようと思ったのか | 動機、コンセプト、技術選定 | |
| 第2回 | 「1回限り」のシステムを設計する | アーキテクチャ、DB設計、認証フロー | |
| 第3回 | AI顔認識で自動タグ付けする仕組み | HEIC変換、Face Collection、報酬設計 | |
| 第4回 | Ken Burns Effectのスライドショー | 優先度スコアリング、排他制御 | |
| 第5回 | ゼロサムにしないチップ経済圏 | ゲーム理論、インフレ対策、PayPay風UI | |
| 第6回 | 1vs1からバトルロイヤルまで | 対戦システム、ルームコード、チップ分配 | |
| 第7回 | NFC座席管理のテーブルゲーム | ポーカー風ベッティング、ディーラー管理 | |
| 第8回 | パリミュチュエル方式ベッティング | The Coliseum、オッズ計算、運用フロー | |
| 第9回 | チップ消費を報酬に反転させた話 | UX改善、祝福カテゴリ、ランキング | |
| 第10回 | ゲームを壊さない多層防御設計 | クライマックスルール、冪等性、RLS | |
| 第11回 | 「祭りのあと」を設計する | NFC思い出トークン、称号、エピローグ | |
| 第12回 | 結婚式カジノ当日レポート | 2時間半の運用記録 | |
| 第13回 | データで振り返る結婚式カジノ | 全トランザクション分析、統計 | |
| 第14回 | やり直すなら何を変えるか | 振り返り、教訓、次へ |
第12回以降は、本番（2026年4月5日）後に公開予定です。
この連載はこんな人におすすめ
- 結婚式や二次会で「何か面白いことをやりたい」エンジニア
- Next.js + Supabase でリアルタイムアプリを作りたい人
- 個人開発で「本番運用」の経験を積みたい人
- ゲームデザインやイベント向けシステムに興味がある人
この記事の全文（ストーリー・背景解説を含む完全版）はブログで公開しています。
Discussion