どうもPHPerです。
先日、私の結婚式がありまして、その際に使用することにした写真共有WEBアプリのお話をさせてください。
これリポジトリ： https://github.com/HrOkiG2/wedding-memory-sns
何を作ったの？
結婚式によくある卓に配置されたインスタントカメラ（写ルンです）の代わりにリアルタイムで式の様子を共有するWEBアプリを作成しました。
下記のようにQRコードとスクリーンに式の様子が共有されるというWEBアプリです。
（このQRコードには悪意のあるスクリプトが含まれているので読み込まないように。。嘘です、もうページ開けないです）
なぜ自作したのか
シンプルにお金がなかったからです。
自身の結婚式にあたり、初めはゲストが写真を撮って楽しめる演出として、各テーブルに「写ルンです」を配置することを検討していました。
しかし、本体代に加えて「現像・データ化代」を含めると、想定以上のコストになることが判明しました。
- 本体代： 2,000円/1台 * 卓数分
- 現像代： 950円 * 卓数分
- データ化： 900円 * 卓数分
今回の結婚式ではゲストの卓数が15になるため以下のコストが掛かります。
(2000 * 15) + (950 * 15) + (900 * 15) = 57,750
結婚式を実施するだけでもウン百万かかっているので、不必要な出費がかなり痛く、そもそもの段階として 写ルンですを配置するという企画を取りやめうと考えました。
嫁さんからの「あんたエンジニアだからどうにかならないの」の一言からそれもそうだ自分で作ろうと思い立ち結婚式用の写真共有WEBアプリを開発しました。
システム概要
仕組みはシンプルです。
- 各テーブルに QRコード を設置。
- ゲストがスマホでスキャンすると、ブラウザアプリが起動（ログイン不要）。
- 撮った写真をアップロードすると、会場の スクリーンにリアルタイムで反映 される。
技術構成
開発期間は仕事の合間を縫って約2週間。
「維持費を極限まで下げる（サーバーレス）」ことと、「TypeScriptで統一する」ことをテーマに構成しました。
フロントエンド
- Framework: Nuxt 3 (Vue 3)
- Language: TypeScript
- Styling: Tailwind CSS
- Hosting: S3 + CloudFront (Static Site)
バックエンド・インフラ (AWS CDK)
インフラは全て AWS CDK でコード管理しています。
使用したスタックは以下のとおりです。
| サービス | 用途 |
| CloudFront | CDN・HTTPS終端・APIへのプロキシ |
| S3 | フロントエンドのホスティング & 写真ストレージ |
| API Gateway | HTTP API (REST) |
| Lambda | Node.js 20 (ARM64) で実装。認証と署名付きURL発行を担当 |
| DynamoDB | ゲスト認証情報、写真メタデータ、レートリミット管理 |
こだわった技術ポイントと「ハマりどころ」
単純なアップローダーに見えますが、「不特定多数のゲストが」「多様な端末で」「一斉に使う」 という環境特有の課題がありました。
署名付きURL (Presigned URL) の活用
Lambdaを経由して画像をアップロードすると、ペイロードサイズ制限（6MB）や実行時間課金の問題が発生します。
そこで、クライアントから「アップロードしたい」とリクエストがあった際に、Lambdaが S3への一時的な書き込み許可証（Presigned URL） を発行し、クライアントがS3へ直接アップロードする構成にしました。
これにより、サーバー負荷を最小限に抑えています。
iPhoneの「コードスキャナー」
これが開発中最大の落とし穴でした。
iPhoneのコントロールセンターにある「コードスキャナー」でQRを読むと、Safariではなく一時的なアプリ内ブラウザで開かれてしまいます。
このブラウザは画面を閉じるとCookieやLocal Storageが即座に破棄されるため、「さっきアップした写真を確認しよう」と再度QRを読み込むとログアウト状態になってしまいます。
技術的に「強制的にSafariを開かせる」方法は存在しないため、「iPhoneの方は標準カメラアプリで読み取ってください」 という物理的なPOPを各卓に置くという、アナログな解決策に着地しました。
やらなかったこと
あえて、アップロードされた画像のダウンロード機能は実装しませんでした。
これは嫁と相談した結果なのですが、アップロードされた画像は一度、私達夫婦のもとに落としてそれをLINE等で発信したい。その過程の中で結婚式の思い出にもう一度触れたいという考えのもとです。
結果としては、LINEで結婚式について参列者の友人たちと思い出に浸ることもできました。
また、機能減らしたことで実装コストが下がったのも大きかったですね。
コスト比較結果
AWS利用料は、開発期間を含めても数百円。当日のスパイクアクセス（CloudFront, Lambda, S3）も微々たるものでした。
約3.5万円の節約 に成功し、その分を料理や引き出物のグレードアップに回すことができました。
参列者の反応
結果は 大成功 でした。
- リアルタイム性: 投稿した写真がすぐスクリーンに出るため、「今の面白い瞬間」が共有され、会場の一体感が生まれた。
- 懐かしさの共有: 「新郎新婦との昔の写真」をスマホから掘り出して投稿してくれるゲストが多数おり、スライドショーがエモい雰囲気に。
- 交流: ゲスト同士で「今の写真送って！」ではなく「QRから上げといて！」という会話が生まれ、自然な交流のきっかけになった。
副次的な成果として、参列していた友人2名から「自分の式でもこれを使わせてほしい」とオファーをもらいました。(すごく嬉しかった)
また、アップロードされた画像は約300枚になり、予定していた100枚よりも大幅に多い画像がアップロードされました。
余興の多い沖縄の結婚式の中で、これだけの数の画像がアップロードされたのは機能を絞ったこととUIをシンプルにしたことが影響したのかなぁという印象です。（シンプルにすごく嬉しい）
今後の改善点
- 画像配信の最適化:現在はS3のPresigned URLで画像を表示しているため、エッジキャッシュが効いていません。CloudFront経由の署名付きCookie/URLに切り替え、表示速度を向上させたいです。
- 不適切画像のAI検知:今回はゲストのモラルに助けられましたが、Amazon Rekognitionを使って「不適切な画像」を自動で弾く機能を入れれば、より安心して運用できます。
- アクセス解析:Microsoft Clarityなどを入れて、ゲストがどこでつまづいたか（UX）を計測すべきでした。
- これネイティブアプリにしたら面白そうじゃねという気持ちがあります（作ったことないけど…誰か共同で開発しませんか…！）
まとめ
「節約」から始まったプロジェクトでしたが、結果として 「写ルンです」には出せないリアルタイムな体験価値 を提供できました。
なにより、自分の技術で一生に一度のイベントを盛り上げられた達成感は、何にも代えがたいものでした。
これから結婚式を挙げるエンジニアの皆さん、「結婚式自作Webサービス」、おすすめです。