婚活パーティーのマッチングツールをAIで作った話｜回収忘れをゼロにするまでの1週間
目次（11件）
婚活パーティーで、やってしまった。
いいねの回収忘れだ。
マッチング結果には影響がなかった。 でも、参加者からすれば「あの運営、ちゃんとやってるのか？」という印象になる。
複数人で動いていると、こういうことが起きる。 「あの人が回収するだろう」と思っていたら、誰も回収していなかった。 責任の分散が、ミスを生む。
パーティーが終わってから、ずっと気になっていた。
なくせるミスは、技術で解決できるのではないか。
ツールを探せばあるだろうとも思った。 でも同時に思った。
あるなら、AIで作れるのでは？
それが始まりだった。
手動集計の何が問題だったか
婚活パーティーのマッチング方式はシンプルだ。 参加者が気になる相手の番号を紙に書く。 運営が回収して、相互に選び合ったペアを発表する。
問題は、回収の段階にある。
複数のテーブルを複数のスタッフで担当する。 全員が動いていると、「あのテーブルは誰かが回った」という思い込みが生まれる。 その思い込みが、回収忘れになる。
回収できても次の問題がある。 手動で突き合わせる計算だ。
男性5番が女性2番と3番を選んでいて、 女性2番が男性5番を選んでいたら、それがマッチ。
参加者が10人ずつなら、100通りの組み合わせを頭で追う。 ミスが起きやすい。時間もかかる。
「このプロセス、全部システムで置き換えられる」と思った。
何を作ったか
ツールのフローはこうなった。
参加者側:
- QRコードを読んで入室（性別と番号を入力）
- セクションごとに気になる相手の番号を選んでいいねを送信
- 全員が送信完了後、結果が届く
管理者側:
- セッションを作成してQRコードを表示
- 参加者の送信状況をリアルタイムで確認
- 全員送信後に締め切り → マッチ結果を確認 → 参加者へ送信
紙もなく、回収もなく、手計算もない。 参加者が自分のスマホから操作して、管理者画面に即座に集計が出る。
技術選定
使ったのは Next.js + Supabase の組み合わせだ。
Supabase を選んだ理由は、Realtime がある点だった。
参加者全員がいいねを送信するまで、管理者は待つ。 全員送信したら管理者が締め切る。 締め切ったら、参加者の画面が自動で「結果待ち」に変わる。 管理者が送信ボタンを押したら、参加者の画面に結果が届く。
この「全員に同時に届く」という体験を作るには、リアルタイム通信が要る。 Supabase の Realtime はデータベースの変更を WebSocket でリアルタイムに通知してくれる。 自前でソケットサーバーを立てる必要がない。
Next.js は、このブログを作るときにすでに使っていた技術スタックだ。 Claude Code が得意な領域でもある。 迷いなく選んだ。
1週間の開発記録
公開までに1週間かかった。
「1日で実装して公開」とはいかなかった。 バグの洗い出しに、思った以上に時間がかかったからだ。
最初のバージョン（v1）
最初に作ったのは、シンプルな構成だった。
- 参加者が番号を入力して入室
- 気になる相手の番号にチェックを入れて送信
- 管理者が締め切ると、相互マッチを計算して表示
動いた。でも使ってみると、細かいところがおかしい。
「やり直せない」「同じ番号を2回登録できる」「管理者が締め切るタイミングが分からない」
使いながら見つかるバグが、次々に出てきた。
v2での改善
実際の運営スタッフと試運転を重ねながら修正した。
入室のやり直し機能。重複登録の防止。参加者の送信状況を管理者がリアルタイムで確認できる画面。送信済み参加者の番号一覧表示。
使ってみないと分からない問題ばかりだった。
v2.1で追加した3つの機能
打ち合わせから3つの要件が確定した。
① いいね回数の上限を設定できる
小規模パーティー（参加者が少ない）では1セクションで十分。 大規模なら2〜3セクション。 管理者がセッション作成時に選べるようにした。
② 管理者が確認してから結果を送信する
全員のマッチ結果を管理者が先に確認してから、参加者へ送信する。 「サプライズ発表」のような演出もできるようになった。
③ 重複マッチングの防止
男性A・男性Bが同じ女性Cにいいねして、女性Cが両方にいいねしている場合。 通常なら2マッチになるが、「1人1マッチ」に絞ることができる。
一番詰まったこと
Realtime のバグが、最も解決に時間がかかった。
症状はこうだった。
管理者が「参加者へ送信」ボタンを押す。 でも参加者の画面が変わらない。 ページをリロードすると結果が表示される。
「送信できているのに届かない」。
原因を特定するのに時間がかかった。
コードを読み返して分かった。
Realtime の購読を解除するタイミングが早すぎた。
管理者が締め切ると、セッションの状態が closed になる。
そのとき「セッションが閉じられた = もう変更はない」と判断して、Realtime の購読を解除していた。
でも手動送信モードでは、そこで終わりじゃない。
closed になった後に、管理者が「送信する」を押して初めて results_visible = true になる。
参加者の画面はその変更を受け取って結果を表示するはずだった。
でも購読を解除した後だから、変更が届かない。
修正は1行だった。
// 修正前
if (!session || session.status === "closed") return;
// 修正後
if (!session || (session.status === "closed" && session.resultsVisible)) return;
「閉じられた」だけでは解除しない。 「閉じられて、かつ結果も送信済み」になって初めて解除する。
シンプルな条件だが、見つけるまでに時間がかかった。 Realtime の購読解除タイミングは「状態が完全に確定したとき」に限定する。 これが今回の一番の学びだ。
Claude Code との役割分担
今回のツールは、ほぼすべての実装を Claude Code と一緒に進めた。
自分がやったのは:
- 「こういう機能が必要」という要件を言語化する
- 試運転して「ここがおかしい」を報告する
- バグの症状を説明する
Claude Code がやったのは:
- 設計を提案する
- コードを書く
- バグの原因を特定して修正する
自分はエンジニアではない。 Next.js も Supabase も、Claude Code に教わりながら使っている。
でも「何が問題か」「どう動いてほしいか」を具体的に伝えることはできる。 それだけで、動くものができた。
1週間かかったのは、バグの洗い出しに時間がかかったからだ。 コードを書く速さではなく、「実際に使って問題を見つける」繰り返しに時間がかかった。
AIで作れるかどうかよりも、何を作るべきかを言語化できるかどうかが、時間を左右した。
5/31 本番に向けて
このツールは、2026年5月31日に本番の婚活パーティーで初導入する予定だ。
今は試運転と調整の段階。
残っている課題:
- 実際の参加者数での動作確認
- いいね送信の非アトミック問題（技術的な安定性向上）
v3候補として考えているのは、こんな機能だ。
- ペア選択送信: マッチしたペアを1組ずつ選んで送信。結果発表に演出を持たせる。
- 結果表示専用ページ: 運営スタッフが自分のスマホで番号ペアを確認。退出時の誘導に使う。
- いいねロック: 管理者が参加者のいいね送信をロック。セクションの開始と終了を明示的に制御する。
本番を経験してから、実際に必要なものを判断する。
次の1歩
「自分も同じものを作りたい」という場合、必要なのはこれだけだ。
- Claude Code（AIとのペアプログラミング環境）
- Supabase のアカウント（無料枠で十分）
- 「何を解決したいか」の言語化
コードを書けなくてもいい。 「こういう問題がある。こう動いてほしい」を言い続ける力があれば、作れる。
婚活パーティーの回収忘れをなくしたかった。 それだけで、1週間でツールができた。
なくせるミスは、技術で解決できる。 技術がないなら、AIを使えばいい。