看板にしていた機能が、いちばん使われていなかった

イベントの写真共有サービスを個人で作って、2ヶ月ほど無料で公開しています。

宣伝になる数字だけを並べても仕方がないので、いちばん都合の悪いところから書きます。

先に断っておくと、母数は小さいです。

実イベント18件、そのうち写真が集まったのは7件。 統計として扱える量ではありません。

それでもゼロよりは判断の材料になると思って出します。

（数字はすべて2026年9月6日時点の実測値です）

看板にしていた機能が、いちばん使われていなかった

photoba は「参加者がQRから投稿した写真が、数秒で会場のスクリーンに映る」を中心に据えて作りました。トップページの見出しもそれです。

技術的にいちばん手をかけたのもそこで、Durable Objects でリアルタイム配信を組んでいます。

30日間の実測はこうでした。

しかも7セッションのうち、実際のイベントで使われたと確認できたのは 1件 です。54枚集まったイベントですら、スクリーンを開いた記録がありませんでした。

関心が無いわけではありませんでした。 同じ期間にトップページのFAQで押された回数を数えると、2番目に多いのが「会場の大画面にはどう映しますか？」（8回）です。1位は「いま使えますか？費用は？」。

関心はあるのに、使われない。理由を並べると、全部こちらの設計の問題でした。

①　映すには パソコンとネット回線が別に必要。会場によっては持ち込み機器に制限もある

②　主催者の管理画面の利用は 6〜7割がスマートフォン。手元にURLがあっても、会場のPCに渡す手段がない

③　説明が文字だけで、手順の絵がなかった

3つ目は明確にこちらの落ち度なので、実際の画面のスクリーンショットを載せる形に直しました。2つ目は、登録したメールアドレスにスクリーンURLを入れて、会場のPCでメールを開けば済むようにしました。

いちばん時間をかけた機能が、いちばん使われない。 個人開発だと自分の「作りたい」と利用者の「使いたい」がズレていても誰も止めてくれないので、数字を見るまで気づけませんでした。

自分の書いた式が、結婚式の前日に写真を消していた

これは危うい不具合でした。保存期限の計算が、こうなっていました。

・開催日が設定されていれば「開催日の7日後」に削除

・ただし「作成から90日」を超えないように上限をかける

一見それらしいのですが、半年先の結婚式のために早めにイベントを作ると壊れます。

90日の上限が先に来て、削除予定日が結婚式より前になる。実際に2件がその状態で、片方は式の前日に消える設定になっていました。

上限は「入力できる開催日」の側にかけるべきで、計算結果の日付にかけてはいけませんでした。

修正して、既存データも延長方向にだけ直しました。

同種のサービスを使う側に立つと、「保存期間の起算点は何か」 は確認したほうがいい項目です。「イベント日から」「作成から」「最後の写真から」で意味がまったく違い、先の予定のために早めに作るときに事故になります。

事前テストを禁止していたら、同じイベントが5分で4件できた

もうひとつ。開催日を設定すると、その日以外は投稿を403で弾く仕様にしていました。「当日その場」のサービスなので、そのほうが筋が通ると思っていたのです。

結果どうなったか。主催者が事前の動作確認をできませんでした。

操作ログを見ると、ある方が同じ名前のイベントを 5分間に4件 作っていました。別の日には同じ名前で 33秒差の2件 も。

理由は2つありました。イベント名を後から変更できなかったことと、管理画面のURLを見失ったら戻る手段がなかったことです。名前を直したいだけなのに、作り直すしかない状態でした。

この手のサービスの管理URLは、たいていそれ自体が鍵です。パスワードの代わりにURLを知っていれば操作できる。再発行できない設計だと、ブックマークを忘れた時点で戻れません。

どちらも直しました。開催日の前後でも投稿できるようにして、名前も変更できるようにして、メールアドレスを任意で登録すれば管理URLが届くようにしました。

その後に来たイベントを見ると、写真が集まった4件のうち2件が「投稿してから一部を削除する」動きをしています（9枚→7枚、6枚→2枚）。試し撮りの後片付けなのか写真の選別なのかは区別できませんが、少なくとも 事前に触れる状態にしたこと自体は使われています。 禁止していた操作が、実は必要な操作でした。

データの形が、設計を決めた

技術寄りの話をひとつ。写真は平均的なペースでは届きません。

54枚集まったイベントの実測です。

大半が数分の集中した塊で来て、その間に長い空白があるということです。ということです。36枚のイベントも同じ形でした（約7時間・中央値49秒・3分で最大7枚）。

山は「乾杯」「集合写真」など進行の節目に来ます。つまり 平均スループットで設計すると当日に破綻します。 ピークに合わせて組む必要がある。ここは Durable Objects で1イベント1インスタンスにしてあるので耐えましたが、最初にDBのポーリングで作っていたら詰まっていたはずです。

もうひとつ、21時間という幅が重要でした。これは準備中や後日の追加を含んでいます。「イベント当日しか受け付けない」設計だと取りこぼす。まさに上で書いた403の失敗です。

枚数の話（期待するほど集まりません）

写真が集まった7件の内訳です。

「だいたい何枚集まる」という言い方ができません。集まるか、ほとんど集まらないかの二極でした。

参加ページを開いた50人に対して投稿は104枚なので1人あたり2〜3枚。「1人が大量に送る」のではなく「多くの人が数枚ずつ送る」形です。つまり参加者の頭数がそのまま枚数になるので、QRを1か所に置くよりテーブルごとに置いたほうが効きます。

あと、アルバムは当日だけのものではありませんでした。 当日6セッション→翌日5（13閲覧）→翌々日2。当日は撮るのに忙しく、ゆっくり見るのは後日ということだと思います。保存期間を「当日限り」にすると、この時間を奪うことになります。

構成

参考までに。

・Cloudflare Workers … 本体。ビルドなしの静的HTML＋Worker

・Durable Objects … リアルタイム配信。1イベント1インスタンス

・R2 … 画像

・D1 … メタデータ

・Workers AI … 不適切画像の判定（表示前に保留）

・Cron Triggers … 保存期限切れの自動削除、日次スナップショット

サーバーは0台、ビルド工程もなし。個人開発・個人運営です。Exifの位置情報は 送信前に端末側で 落としています。

数字の限界

・母数は写真が集まった7イベント です。業界の平均値ではありません

・枚数の話の大半は 上位2件 から来ています。1件増えれば数字は動きます

・無料ベータ版なので、有料サービスの利用実態とは違う可能性があります

・用途が会社関係のイベントに偏っています。結婚式の実データはまだ十分にありません

もう少し細かい数字（アルバムの閲覧が何日続くか、投稿された写真の何%が主催者に消されるかなど）は、9月17日に自分のサイトのほうで全部出します。

・photoba（フォトバ）

　https://photoba.app/?src=tsukutta-story

・結婚式での使い方

　https://photoba.app/wedding?src=tsukutta-story

・コラム

　https://photoba.app/blog/?src=tsukutta-story

同じように「作ったけど使われない機能」を抱えている方の役に立てば。