はじめに
飲食店向けモバイルオーダー MasterOrder では、セキュリティを三原則の最優先に据えています。開発の過程で最も大きな転換点のひとつが、外部認証・外部機能への依存を減らし、サーバーサイド主導のセッション管理に寄せた ことです。
外部依存の落とし穴
初期のプロトタイプでは、楽をして外部の認証・決済・リアルタイム機能に寄せがちでした。短期的には速い。しかし運用が進むと、次の問題が出ます。
- コスト … 利用量に比例して請求が増える
- 制限 … プラットフォーム側のレート制限・機能制限
- BAN リスク … 利用規約変更で突然使えなくなる
- ブラックボックス … 障害時に中身が見えない
飲食店の売上データと注文情報を預かる SaaS として、自分の手の届かない場所にセッションの命運を任せる のは不安でした。
自前セッションへ
方針転換後の原則：
- セッションの正はサーバー側
- ブラウザ（来客 UI）は REST + SSE が主経路
- Firestore 直読は Server プロセスまたは限定的なスタッフモードに閉じる
- 認可・監査ログは PostgreSQL に残す
「要塞」という比喩は大げさに聞こえるかもしれませんが、境界を自分で引ける ことの重要性を指しています。
来客とスタッフで経路を分ける
MasterOrder には複数の UI があります。
| 利用者 | 主経路 | 備考 |
|---|---|---|
| 来客 | Server REST | Firestore 非接続 |
| スタッフ（通常） | Server REST + SSE | 同上 |
| スタッフ（固定 QR モード） | Firestore 直読 + REST enrich | 限定的 POC |
すべてに同じ方式を押し付けず、モードごとに境界を明示 しています。将来クライアント Firestore 直読を広げる場合も、write は Rules で拒否し、読取のみ scoped にする計画です。
個人開発での現実解
大企業並みの IAM を最初から構築する余力はありません。だから InventoryPort のような抽象化でストアを差し替え可能にし、セッション・在庫・メニューの責務を分けました。
「全部自前」ではなく、預かるデータほど自分で握る というバランスです。
まとめ
外部サービスは敵ではありません。ただし セッションと売上データの中枢 を外部のブラックボックスに置くのは、個人開発の飲食 SaaS にはリスクが高いと判断しました。
MasterOrder はサーバーサイド主導のセッション管理を軸に、現場（中野の飲食店）で鍛え続けています。