実際に使ってみる
この記事が良かったら
「チップをリクエスト」で著者にチップの受け取り設定をお願いできます
シェア
photoba（フォトバ）を作った理由
ゲストのスマホに眠ったままの写真を、その日のうちに集めたかった
約6分で読めます11
ゲストのスマホに眠ったままの写真を、その日のうちに集めたかった
実際に使ってみる
この記事が良かったら
「チップをリクエスト」で著者にチップの受け取り設定をお願いできます
結婚式でいちばん多く写真を撮っているのは、プロのカメラマンではありません。参加したゲストです。
ところが、その写真のほとんどは各自のスマホに残ったまま終わります。後日グループLINEで「あの写真ちょうだい」と言い合い、何人かは送り忘れ、何人かは面倒になって流れる。撮った枚数のわりに、新郎新婦の手元に届く枚数はかなり少ない。
一方で、写真を集める既存の方法にはそれぞれ壁がありました。
「その場で盛り上がる」と「あとで手元に集まる」を同時に、しかもゲストに何もインストールさせずにやりたい。それがphotobaの出発点です。
きっかけは、友人の結婚式に出席したときのことでした。 披露宴のあいだ、周りのゲストはずっとスマホを構えていました。入場、乾杯、余興。同じ場面をそれぞれの角度から、何十枚も撮っている。ところが式が終わったあと、その写真がどこかに集まる気配はありませんでした。数日後にグループLINEで何人かが送って、そこで止まる。撮られた枚数と、新郎新婦の手元に届いた枚数の差が、そのまま宙に浮いたままになっていました。 その場にいた全員が「いい写真が撮れた」と思っていたはずなのに、それを持ち寄る手段だけが、たまたま誰も持っていなかった。技術的に難しいことは何ひとつないのに解決されていない、という点が引っかかって、そのまま作りはじめました。
QRを読むだけで参加できます。アプリのインストールも、会員登録も、合言葉の入力もありません。
結婚式のゲストは、久しぶりに会った人と話すのに忙しい人たちです。そこで3ステップの登録を求めた時点で、大半は使ってくれません。参加のハードルを下げることを最優先にしました。
写真の位置情報(Exif)は、サーバーに送る前に端末側で消えています。ただし、そのためのコードは書いていません。
やっているのは、canvasに長辺1600pxで描き直してtoBlobでJPEGに再エンコードすることだけです。canvasで描き直した画像にはExifが引き継がれません。表示用の縮小をした結果、位置情報が構造的に落ちる。
「消す処理」があると、バグったときに消え残ります。そもそもサーバーに届かない構造のほうが安全だと考えました。副次的に、アップロード量が減って会場のWi-Fiが弱くても詰まりにくくなっています。
保存期間を過ぎると、写真もイベントもまとめて自動削除されます。Cron Triggersで毎晩処理しています。
写真共有サービスで地味に困るのが「いつまで残るのか分からない」ことです。特に結婚式の写真は、写り込んだゲストの分まで預かることになります。主催者が削除を忘れても消えるようにしておきたかった。
保存期間を7日と短くしたのも同じ理由です。長く残すことは、このサービスの役目ではないと割り切りました。
photobaは長辺1600pxに縮小するので、大きく印刷する画質は残りません。保存も7日だけです。
サイトにもこの欠点を書いています。隠して使われても、期待と違えば結局がっかりされるだけです。「当日その場の盛り上がり」に振り切って、それ以外は他のサービスと併用してもらうほうが正直だと考えました。
Workers / Durable Objects / R2 / D1 / Workers AI。ビルド工程はなく、静的HTMLとWorkerだけです。
リアルタイム表示はDurable Objectsが担当しています。イベントごとに1つの「部屋」を持ち、WebSocketで接続中のスクリーンへ写真をブロードキャストする——という構造が、そのまま「会場のスクリーン」というユースケースに一致しました。
R2はegressが無料なので、画像を配信し続けても転送量を気にせずに済みます。個人が無料で公開し続けられる構成であることは、機能と同じくらい重要な要件でした。続けられない前提のサービスに、大事な日の写真は預けられません。
現在は無料ベータ版として公開中です。
