イベントで写真は何枚集まるのか｜自社サービスの実データを公開します

「イベントで写真は何枚くらい集まるのか」「どのくらいの人が使ってくれるのか」を調べようとすると、ほとんど何も出てきません。各社が公開していないからです。

この記事では、私たちが運営しているサービスの実測値をそのまま出します。宣伝になる数字だけを選んだりはしません。うまくいかなかった部分のほうが多いので、そちらも書きます。

先に断っておきます。母数は「写真が集まった7イベント」です。統計として扱える量ではありません。それでも、ゼロよりは判断の材料になると思って公開します。

【2026-10-06 更新】山の形が2種類あることが分かりました

9月22日の更新で「投稿が集中する急さだけは、書いたよりずっと急だった」と訂正しました。そのあと237枚のイベントが、まったく違う形で来ました。負荷のかかり方が1種類ではないので、分けて記録します。

なぜ3分間の最大だけ逆転しているのですか？

瞬間のとがり方と、高い負荷が続く長さが別物だからです。

260枚のほうは1分だけ35枚に跳ねて、すぐ落ちます。237枚のほうは1分あたり30枚前後が3分続きます。1分間の最大だけを見ると後者のほうが低いのに、3分でまとめると1.8倍になります。

設計の目安にするなら、1分間の最大ではなく「高い負荷が何分続くか」で見てください。瞬間のピークはバッファで吸収できますが、13枚/分が18分続く負荷は吸収しきれません。

イベント中ではなく、終わったあとに送られるのですか？

そういう使われ方がありました。この237枚は昼間の行事のものですが、投稿は全部その日の23時33分から23時51分に行われています。撮りながら送るのではなく、帰宅後にまとめて送る形です。

初版で「イベント当日以外にも届きます」と書きましたが、想定していたのは数日にわたる追加投稿でした。当日の夜に全部まとめて、というパターンは想定していませんでした。

• 開催日の当日しか受け付けない設計だと、この型は丸ごと取りこぼします。深夜0時をまたぐ可能性もあります
• 保存期限の起算点が「開催日から」だと、投稿される前に期限が進みます。「最後の写真から」のほうがこの型には合います
• 会場のスクリーンに映す演出は、この型では成立しません。送られてくる頃には会場が解散しています

同種のサービスを作る方へ。「イベント中に少しずつ届く」だけを前提にすると、2つの意味で外します。負荷の見積もりと、受付期間の設計の両方です。

【2026-09-22 更新】母数が2.4倍になっても、初版の結論はほぼ残りました

9月6日の初版から16日で、写真が集まったイベントは7件から17件、合計は104枚から659枚になりました。母数が2.4倍、枚数が6.3倍になっても、初版で書いた見立ては1つを除いてそのまま成り立っています。更新した数字だけを先に置きます。

平均は2.6倍になったのに、中央値は1枚しか動きませんでした

初版で「平均には意味がない」と書きました。母数が増えて、その傾向はむしろ強まりました。

平均は15枚から39枚へ2.6倍になっています。ところが中央値は3枚から4枚にしか動いていません。17件の内訳はこうです。

初版では上位2件で全体の87%でした。更新後は上位4件で87%です。件数は増えましたが、少数のイベントが大半を占める形は変わっていません。17件のうち10件（59%）が6枚以下です。

「だいたい何枚集まるか」は、やはり言えません。集まるか、ほとんど集まらないかの二極という初版の観察は、母数2.4倍でも再現されました。サービスを検討する場合は、平均値ではなくこの振れ幅で計画してください。

唯一ひっくり返ったのは、投稿が集中する急さです

初版では「まとまって一気に来る」と書きました。実際は、書いたよりずっと急でした。

最多だった260枚のイベントの実測値です。写真の中身は見ておらず、投稿時刻だけを集計しています。

260枚が2時間に収まっています。間隔の中央値が0秒というのは、連続する2枚の半分以上が同じ1秒のうちに届いたという意味です。1分以上あいたのは、2時間を通じて16回しかありませんでした。

• 会場の大画面に映す設計は、3分で48枚に耐える必要があります。初版の「21時間で54枚」を基準にすると、まったく足りません
• 同時アップロードが重なります。1枚ずつ順番に処理する前提だと、この瞬間に詰まります
• 山は進行の節目に来ます。この日は乾杯前後の2時間にほぼ全部が集中していました

これは私たち自身にとっても想定外でした。初版の数字で性能を見積もっていたら、この日に間に合っていません。同種のサービスを作る方は、平均ペース（この日は2.2枚/分）ではなくピーク（1分35枚）で設計してください。

1人あたり2〜3枚は、そのまま残りました

初版では、参加ページを開いた50人に対して投稿104枚で「1人あたり2〜3枚」と書きました。

更新後は、参加ページが287セッションに対して投稿が598枚（計測を始めた9月7日以降に作られたイベントのぶん）で、1人あたり約2枚です。母数が5倍以上になっても、この比率はほとんど動きませんでした。

つまり枚数は参加者の頭数でほぼ決まります。「1人が大量に送ってくれる」ことは期待できません。QRを1か所に置くより、テーブルごとに配ったほうが効く、という初版の見立ては維持します。

【2026-09-19 更新】3つの数字が、初版からひっくり返りました

9月6日の調査から2週間で、この記事の結論のうち3つが変わりました。古いほうを消さずに、何がどう変わったかを残します。

1. 189枚 — 参加ページを開いたのは73人

あるパーティで189枚が集まりました。参加ページを開いたのは73人です。1人あたり2〜3枚という初版の観察は、この規模でも変わりませんでした。

この主催者は3日前に別のイベントを作って練習していました。初版で書いた「準備した人のところには集まった」という並びが、もう1件増えたことになります。

2. 会場スクリーンは、使われました

初版では「看板にしていた機能がいちばん使われていない」と書きました。これは覆りました。

• スクリーン画面の利用は38セッション（初版時点は7セッション、うち実イベントは1件だけ）
• 189枚が集まったイベントでは、スクリーンが実際に開かれています

初版を書いたあと、トップページに実際の画面を載せ、登録メールにスクリーンURLを入れる変更をしました。因果の証明はできませんが、「関心はあるのに使われていない」状態ではなくなりました。

3. 写真の持ち帰りが、初めて起きました

初版の時点で、ZIPでの一括ダウンロードは0件でした。写真が集まっても、誰も持ち帰っていませんでした。

更新時点で3件になっています。うち1件は189枚のイベントで、削除予定日の6日前に、主催者が自分で戻ってきて保存しています。通知メールはまだ送っていない時点でした。

同時に回収した満足度の回答は1件のみで、「良かった」でした。有料プランへの関心にはチェックが入りませんでした。n=1なので断定はできませんが、「満足はしたが払う理由はない」という形は、ありうる反応だと思います。

母数：18イベントのうち、写真が集まったのは7件

まず前提の数字です。テストや動作確認のために作られたものを除いた、実際のイベントだけを数えています。

作っても半分以上は使われません。ただしこの中には「半年先の結婚式のために早めに作った」ものも含まれるので、失敗とは言い切れません。

ここから先の枚数の話は、写真が集まった7件だけを対象にしています。

【2026-09-19 追記】「使われなかった」の一部は、本番前の練習でした

初版では「作っても半分以上は使われません」と書きました。これは数え方に問題がありました。

投稿された写真のうち、主催者が削除した枚数を見ると、こうなっていました。

本番前に自分で試して、写真を消してから当日を迎えているのです。残り枚数だけを見ると「ほとんど集まらなかった失敗例」に見えますが、実際は準備が済んでいる状態でした。

• 作成されたイベントのうち、開催日がまだ先のものが18件あります。これらは成否を判定できません
• 残り枚数が0〜3枚のイベントには、本番前の練習を片付けたものが含まれます
• つまり「半分以上が使われない」は、言い過ぎでした

同種のサービスの利用率を測るときは、作成数を分母にしないほうがよいと思います。開催日が過ぎたものだけを数え、削除された枚数も合わせて見ないと、準備中と失敗の区別がつきません。私たちはそこを間違えていました。

集まる枚数は「二極」だった

7件の内訳です。多い順に並べました。

平均は約15枚ですが、この平均には意味がありません。上位2件で全体の87%を占めていて、残り5件は6枚以下です。中央値は3枚です。

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

何が違ったのか

枚数が多かった2件には共通点がありました。どちらも会社関係のイベントで、主催者が事前に動作確認をしていました。片方は本番前に別のイベントを作ってテスト投稿し、その写真を後から削除しています。

1〜3枚で止まった5件は、作成から投稿までの間に主催者の操作記録がほとんどありません。配る前に止まっている可能性が高いです。

これは7件からの観察で、因果関係の証明ではありません。ただ「準備した人のところには集まった」という並びにはなっています。

写真は「まとまって一気に」来る

投稿の時刻を見ると、平均的なペースで届くのではないことがはっきり分かります。54枚が集まったイベントの数字です。

21時間にわたって届いているのに、間隔の中央値は11秒です。大半の写真が数分の集中したかたまりで届き、その間に長い空白があるということです。

36枚のイベントも同じ形でした。期間は約7時間、間隔の中央値は49秒、3分間の最大は7枚です。

この形が意味すること

• 会場の大画面に映す設計は、この山に耐えられる必要があります。1枚ずつゆっくり来る前提だと、山が来たときに追いつきません
• 山は「乾杯」「集合写真」など、進行の節目に来ます。司会の合図とQRの案内を合わせると効きやすいはずです
• イベント当日以外にも届きます。21時間という幅は、準備中や後日の追加を含んでいます。開催日の当日しか受け付けない設計だと取りこぼします

最後の点は、私たち自身が失敗していた部分です。以前は開催日を設定するとその日以外は投稿を受け付けない仕様にしていて、事前の動作確認ができませんでした。実際に困った方が出たので取りやめました。

参加者1人あたりは3枚前後

参加ページを開いた人の数と、集まった枚数の関係です。直近30日の数字です。

参加ページを開いた50人に対して投稿は104枚なので、1人あたり2〜3枚という並びです。「1人が大量に送る」のではなく、多くの人が数枚ずつ送る形でした。

これは配り方の設計に影響します。1人でも撮ってくれれば成立するのではなく、参加者の頭数がそのまま枚数になります。QRを1か所に置くより、テーブルごとに置いたほうが効くはずです。

アルバムは当日だけのものではない

共有アルバムが見られた日を追うと、イベントの翌日・翌々日も見られていました。

• イベント当日 … 6セッション
• 翌日 … 5セッション（13回の閲覧）
• 翌々日 … 2セッション

当日は撮るのに忙しく、ゆっくり見るのは後日ということだと思います。保存期間を「当日限り」にすると、この時間を奪うことになります。

いちばん使われていないのは、看板にしていた機能でした

ここが公開しづらい数字です。

photoba は「その場で会場の大画面に映る」を中心に据えて作りました。トップページの見出しもそれです。ところが実測はこうでした。

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

関心が無いわけではなかった

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

関心はあるのに、使われていない。つまり分からないか、面倒だと判断されているということです。

• 映すにはパソコンとネット回線が別に必要です。会場によっては持ち込み機器に制限もあります
• 主催者の管理画面の利用は6〜7割がスマートフォンでした。手元にURLがあっても、会場のパソコンに渡す手段がありません
• 私たちの説明が文字だけで、手順の絵がありませんでした

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

同種のサービスを検討している方には、「大画面に映す」は当日の必須機能として計画に組み込まないほうが安全だと言えます。映せなくても成立する形にしておくべきです。詳しくは貸会議室のプロジェクター接続にまとめました。

主催者が実際につまずいた場所

枚数よりも、こちらのほうが役に立つかもしれません。実際に起きた操作の記録から見つかった、設計の失敗です。

同じイベントを5分で4件つくった人がいた

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

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

写真共有サービスの管理URLは、たいていそれ自体が鍵です。パスワードが無い代わりに、URLを知っていれば操作できます。再発行できない設計が多いので、ブックマークを忘れると戻れません。選ぶときに確認しておくとよい点です。

保存期限の計算式が、本番前に写真を消していた

これは危うい不具合でした。私たちの期限の計算式は、こうなっていました。

• 開催日を設定すると「開催日の7日後」に削除
• ただし「作成から90日」を超えないよう上限をかける

半年先の結婚式のために早めにイベントを作ると、90日の上限が先に来て、削除予定日が結婚式より前になります。実際に2件がその状態でした。片方は式の前日に消える設定になっていました。

上限は「入力できる開催日」の側にかけるべきで、結果の日付にかけてはいけませんでした。修正して、既存のデータも直しました。

他社を選ぶ場合も、「保存期間の起算点は何か」を確認してください。「イベント日から」「作成から」「最後の写真から」で意味がまったく違い、先の予定のために早めに作るときに事故になります。

投稿された写真の26%が削除されていた

投稿104枚のうち、主催者が削除したのは27枚でした。ただしこのうち24枚は1つのイベントに集中しています（36枚中24枚）。

テスト投稿の後片付けなのか、写真の選別なのかは区別できません。削除できること自体は必要な機能ですが、割合が高いようなら投稿画面に確認の手順が足りていない可能性があります。

この数字の限界

最後に、この記事を引用する場合の注意です。

• 母数は写真が集まった17イベント・659枚です。業界の平均値ではありません
• 枚数の話の大半は上位4件から来ています。1件増えれば数字は動きます
• 投稿の集中（3分で最大88枚）は2イベントの実測値です。しかも山の形が2種類あり、すべてのイベントがこうなるわけではありません
• 無料のベータ版なので、有料サービスの利用実態とは違う可能性があります
• 用途が会社関係のイベントに偏っています。結婚式の実データはまだ十分にありません
• 保存期間を過ぎたイベントは記録ごと消えるため、過去の累計は追えません。各更新時点の数字として読んでください
• 初版の調査日は2026年9月6日、最新の更新は2026年10月6日です

それでも公開する理由は、この種のデータがどこにも無いからです。同じことをやろうとしている方や、サービスを選ぼうとしている方の判断材料になれば十分です。

数字が増えたら更新します。

photoba について

この記事の数字は、私たちが運営しているphotobaの実測値です。イベント参加者がスマホで撮った写真を、その場で会場の大画面に表示する無料のサービスです。

• 参加者はQRを読むだけ。アプリのインストールも会員登録もありません
• 主催者もイベント名を入れるだけで、登録不要で始められます
• 1イベント500枚まで無料
• 写真は一定期間後に自動削除されます

画質は長辺1600pxに縮小されます。元データのまま残す用途には向きません。他社との違いは写真共有サービス10社の比較にまとめています。