# イベントで写真は何枚集まるのか｜自社サービスの実データを公開します イベント写真共有サービスを運営して分かった実際の数字を公開します。17イベント・659枚の実測で、1イベントに集まる枚数、投稿が集中する速さ（3分で48枚）、アルバムが見られる期間、主催者が実際につまずいた場所まで。母数が小さく統計として扱える量ではないことを先に明記します。 --- - 出典: https://photoba.app/blog/event-photo-real-data - 公開日: 2026-09-17 - 発行: photoba（https://photoba.app/） --- 「イベントで写真は何枚くらい集まるのか」「どのくらいの人が使ってくれるのか」を調べようとすると、ほとんど何も出てきません。各社が公開していないからです。 この記事では、**私たちが運営しているサービスの実測値をそのまま出します。**宣伝になる数字だけを選んだりはしません。うまくいかなかった部分のほうが多いので、そちらも書きます。 先に断っておきます。**母数は「写真が集まった7イベント」です。**統計として扱える量ではありません。それでも、ゼロよりは判断の材料になると思って公開します。 ## 【2026-10-06 更新】山の形が2種類あることが分かりました 9月22日の更新で「投稿が集中する急さだけは、書いたよりずっと急だった」と訂正しました。そのあと**237枚のイベントが、まったく違う形で来ました。**負荷のかかり方が1種類ではないので、分けて記録します。 | | イベント中に分散する型 | 終了後に一気に来る型 | |---|---|---| | 枚数 | 260枚 | 236枚 | | 投稿が続いた時間 | 118分 | **18分** | | 平均ペース | 2.2枚/分 | **13.1枚/分** | | 1分間の最大 | 35枚 | 30枚 | | **3分間の最大** | 48枚 | **88枚** | | 投稿された時間帯 | イベント中（昼） | **当日の深夜23時台** | ### なぜ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つを除いてそのまま成り立っています。**更新した数字だけを先に置きます。 | | 初版（9/6） | 更新（9/22） | |---|---|---| | 実イベント | 18件 | **42件** | | 写真が集まった | 7件 | **17件** | | 投稿の合計 | 104枚 | **659枚** | | 最多のイベント | 54枚 | **260枚** | | 平均 | 約15枚 | **約39枚** | | 中央値 | 3枚 | **4枚** | | ZIPでの持ち帰り | 0件 | **4件** | ### 平均は2.6倍になったのに、中央値は1枚しか動きませんでした 初版で「平均には意味がない」と書きました。**母数が増えて、その傾向はむしろ強まりました。** 平均は15枚から39枚へ2.6倍になっています。ところが中央値は3枚から4枚にしか動いていません。17件の内訳はこうです。 | 投稿枚数 | |---| | 260 / 189 / 70 / 54 / 44 | | 9 / 8 / 6 / 4 / 3 / 3 / 3 / 2 / 1 / 1 / 1 / 1 | 初版では**上位2件**で全体の87%でした。更新後は**上位4件**で87%です。件数は増えましたが、**少数のイベントが大半を占める形は変わっていません**。17件のうち10件（59%）が6枚以下です。 > 「だいたい何枚集まるか」は、やはり言えません。**集まるか、ほとんど集まらないかの二極**という初版の観察は、母数2.4倍でも再現されました。サービスを検討する場合は、平均値ではなく**この振れ幅**で計画してください。 ### 唯一ひっくり返ったのは、投稿が集中する急さです 初版では「まとまって一気に来る」と書きました。**実際は、書いたよりずっと急でした。** 最多だった260枚のイベントの実測値です。写真の中身は見ておらず、投稿時刻だけを集計しています。 | 項目 | 初版（54枚） | 更新（260枚） | |---|---|---| | 最初の1枚から最後の1枚まで | 21時間 | **2.0時間** | | 投稿間隔の中央値 | 11秒 | **0秒** | | 前の1枚から1秒以内に届いた割合 | — | **69%** | | 1分間の最大 | — | **35枚** | | 3分間の最大 | 7枚（36枚のイベント） | **48枚** | 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つが変わりました。**古いほうを消さずに、何がどう変わったかを残します。** | | 初版（9/6） | 更新（9/19） | |---|---|---| | 最多の投稿枚数 | 54枚 | **189枚** | | 会場スクリーンの利用 | ほぼ使われていない | **実際に使われた** | | 写真の持ち帰り（ZIP） | 0件 | **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件 まず前提の数字です。テストや動作確認のために作られたものを除いた、実際のイベントだけを数えています。 | 項目 | 件数 | |---|---| | 作成されたイベント | 18件 | | 写真が1枚以上集まった | **7件**（39%） | | 10枚以上集まった | **2件**（11%） | **作っても半分以上は使われません。**ただしこの中には「半年先の結婚式のために早めに作った」ものも含まれるので、失敗とは言い切れません。 > ここから先の枚数の話は、**写真が集まった7件**だけを対象にしています。 ## 【2026-09-19 追記】「使われなかった」の一部は、本番前の練習でした 初版では「作っても半分以上は使われません」と書きました。これは**数え方に問題がありました。** 投稿された写真のうち、主催者が削除した枚数を見ると、こうなっていました。 | 投稿 | 削除 | 残り | 状況 | |---|---|---|---| | 44枚 | 41枚 | 3枚 | 本番は翌週 | | 6枚 | 5枚 | 1枚 | 本番は翌週 | | 3枚 | 3枚 | 0枚 | — | **本番前に自分で試して、写真を消してから当日を迎えている**のです。残り枚数だけを見ると「ほとんど集まらなかった失敗例」に見えますが、実際は準備が済んでいる状態でした。 - 作成されたイベントのうち、**開催日がまだ先のものが18件**あります。これらは成否を判定できません - 残り枚数が0〜3枚のイベントには、**本番前の練習を片付けた**ものが含まれます - つまり「半分以上が使われない」は、**言い過ぎでした** > 同種のサービスの利用率を測るときは、**作成数を分母にしないほうがよい**と思います。開催日が過ぎたものだけを数え、削除された枚数も合わせて見ないと、準備中と失敗の区別がつきません。私たちはそこを間違えていました。 ## 集まる枚数は「二極」だった 7件の内訳です。多い順に並べました。 | 投稿枚数 | 備考 | |---|---| | 54枚 | 企業の交流会 | | 36枚 | 会社イベント | | 6枚 | | | 3枚 | | | 3枚 | | | 1枚 | | | 1枚 | | **平均は約15枚ですが、この平均には意味がありません。**上位2件で全体の87%を占めていて、残り5件は6枚以下です。**中央値は3枚**です。 つまり「だいたい何枚集まる」という言い方ができません。**集まるか、ほとんど集まらないかの二極**でした。 ### 何が違ったのか 枚数が多かった2件には共通点がありました。**どちらも会社関係のイベントで、主催者が事前に動作確認をしていました。**片方は本番前に別のイベントを作ってテスト投稿し、その写真を後から削除しています。 1〜3枚で止まった5件は、作成から投稿までの間に主催者の操作記録がほとんどありません。**配る前に止まっている**可能性が高いです。 > これは7件からの観察で、因果関係の証明ではありません。ただ**「準備した人のところには集まった」**という並びにはなっています。 ## 写真は「まとまって一気に」来る 投稿の時刻を見ると、平均的なペースで届くのではないことがはっきり分かります。54枚が集まったイベントの数字です。 | 項目 | 実測値 | |---|---| | 最初の1枚から最後の1枚まで | 21時間 | | 投稿間隔の中央値 | **11秒** | | 3分間に届いた最大枚数 | **18枚** | 21時間にわたって届いているのに、間隔の中央値は11秒です。**大半の写真が数分の集中したかたまりで届き、その間に長い空白がある**ということです。 36枚のイベントも同じ形でした。期間は約7時間、間隔の中央値は49秒、3分間の最大は7枚です。 ### この形が意味すること - **会場の大画面に映す設計は、この山に耐えられる必要があります。**1枚ずつゆっくり来る前提だと、山が来たときに追いつきません - **山は「乾杯」「集合写真」など、進行の節目に来ます。**司会の合図とQRの案内を合わせると効きやすいはずです - **イベント当日以外にも届きます。**21時間という幅は、準備中や後日の追加を含んでいます。開催日の当日しか受け付けない設計だと取りこぼします > 最後の点は、私たち自身が失敗していた部分です。以前は開催日を設定すると**その日以外は投稿を受け付けない**仕様にしていて、事前の動作確認ができませんでした。実際に困った方が出たので取りやめました。 ## 参加者1人あたりは3枚前後 参加ページを開いた人の数と、集まった枚数の関係です。直近30日の数字です。 | 画面 | のべ人数（セッション） | 閲覧回数 | |---|---|---| | 参加ページ（写真を送る画面） | 50 | 141 | | 共有アルバム（見る画面） | 31 | 100 | | 会場スクリーン | **7** | 12 | 参加ページを開いた50人に対して投稿は104枚なので、**1人あたり2〜3枚**という並びです。「1人が大量に送る」のではなく、**多くの人が数枚ずつ送る**形でした。 これは配り方の設計に影響します。**1人でも撮ってくれれば成立する**のではなく、参加者の頭数がそのまま枚数になります。QRを1か所に置くより、テーブルごとに置いたほうが効くはずです。 ### アルバムは当日だけのものではない 共有アルバムが見られた日を追うと、**イベントの翌日・翌々日も見られていました。** - イベント当日 … 6セッション - **翌日 … 5セッション（13回の閲覧）** - 翌々日 … 2セッション 当日は撮るのに忙しく、**ゆっくり見るのは後日**ということだと思います。保存期間を「当日限り」にすると、この時間を奪うことになります。 ## いちばん使われていないのは、看板にしていた機能でした ここが公開しづらい数字です。 photoba は「その場で会場の大画面に映る」を中心に据えて作りました。トップページの見出しもそれです。ところが実測はこうでした。 | | 30日間の利用 | |---|---| | 参加ページ | 50セッション | | 共有アルバム | 31セッション | | **会場スクリーン** | **7セッション** | しかも7セッションのうち、実際のイベントで使われたと確認できるのは**1件だけ**です。写真が54枚集まったイベントでも、スクリーンを開いた記録が見当たりませんでした。 ### 関心が無いわけではなかった 同じ期間に、トップページのよくある質問で押された回数を数えると、2番目に多いのが**「会場の大画面にはどう映しますか？」（8回）**でした。1位は「いま使えますか？費用は？」です。 **関心はあるのに、使われていない。**つまり分からないか、面倒だと判断されているということです。 - 映すには**パソコンとネット回線**が別に必要です。会場によっては持ち込み機器に制限もあります - 主催者の管理画面の利用は**6〜7割がスマートフォン**でした。手元にURLがあっても、会場のパソコンに渡す手段がありません - 私たちの説明が文字だけで、**手順の絵がありませんでした** > 3つ目は明確にこちらの落ち度なので、トップページに実際の画面のスクリーンショットを載せる形に直しました。2つ目は、登録したメールアドレスにスクリーンURLを入れて、会場のパソコンでメールを開けば済むようにしました。 同種のサービスを検討している方には、**「大画面に映す」は当日の必須機能として計画に組み込まないほうが安全**だと言えます。映せなくても成立する形にしておくべきです。詳しくは[貸会議室のプロジェクター接続](/blog/projector-connection-guide)にまとめました。 ## 主催者が実際につまずいた場所 枚数よりも、こちらのほうが役に立つかもしれません。**実際に起きた操作の記録から見つかった、設計の失敗です。** ### 同じイベントを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社の比較](/blog/wedding-photo-sharing-comparison)にまとめています。 --- *この記事の数字は photoba（当サイトが運営するイベント写真共有サービス）の実測値です。初版の調査日は2026年9月6日、2026年9月19日・9月22日・10月6日に更新しました。母数が小さいため、業界の平均値として扱わないでください。個別のイベントが特定できる情報（イベント名・主催者・開催日・写真の内容）は一切含めていません。*