Xのタイムラインで、ある投稿がよく流れてくる日があった。catnose氏（@catnose99）による「個人的Webサービスを作るときの構成 2026」という投稿で、静的ページ・サーバー・DB・ストレージ・メール配信・決済・認証まで、2026年時点でどれを選ぶといいかを一枚にまとめたものだった。表示は52.8万、ブクマは5,293。しずかなインターネット「sizu.me」を運営していることでも知られる方の投稿で、反響の大きさからしても、しばらく引用され続けそうな内容だった。
読みながら、素直にドキッとした。ここに挙げられている項目、うちの本番環境は今どうなっているんだっけ。改善できる余地があるんじゃないか、と思って、一つずつ照らし合わせてみることにした。
一つずつ突き合わせてみた
投稿の中身と、うちが実際に事業として動かしている構成（メタバース rezona・管理画面・監視ダッシュボード・自社サイト boundarylabo.com）を並べてみる。
- 静的ページ → Cloudflare：うちは Droplet+Caddy で自社サイトとゲームコンテンツを配信し、画像などのアセットは Cloudflare R2 に置いている。配信基盤は違うが、「重いアセットはR2」という判断はすでに一致していた。
- サーバーが必要な場合 → TanStack Start / Next on Vercel：うちはメタバース本体を Render（Bunランタイム）、管理画面を Vercel、監視ダッシュボードを Droplet の docker で動かしている。単一の答えではなく、用途ごとに置き場所を分けている状態だった。
- DB → D1 / Turso / Supabase / Neon：先方が挙げた4択のうち、うちは Neon と Supabase の2つをすでに本番で使い分けていた。
- ストレージ → R2 / S3：うちも R2。ここは満点で一致。
- メール配信 → SES / Resend / Cloudflare Email：うちは Resend を使っている。以前 SMTP まわりで詰まった経験があり、その後 Resend に移行した経緯がある。
- 決済 → Stripe：うちも Stripe。一致。
- 認証 → BetterAuth：うちは Privy と Supabase Auth の組み合わせ。ここだけ選んでいる道具は違った。
一通り並べ終えて、少し拍子抜けした。項目のほとんどが、すでに実際に動いていたからだ。
事業として運用するからこそ、足している部分
ただの答え合わせで終わらせるのも面白くないので、なぜ違う道具を選んでいるのかも考えてみた。すると、個人開発の構成ガイドには出てこない、事業として動かしているからこその判断がいくつか見えてきた。
一番わかりやすいのは音声まわりだ。うちのメタバースには、リアルタイムで会話できる音声SFU（LiveKit）が入っている。この手のリアルタイム音声通信は UDP という通信方式を使うのだが、メタバース本体を動かしている Render はこの UDP に対応していない。だから音声SFUだけは Vultr の VPS に独立して置いている。これは流行りかどうかではなく、「動くか動かないか」で決まった選択だった。
もう一つは監視の層だ。事業として本番を回している以上、ダッシュボードによる監視は必須で、それに加えて自宅のホームラボでも別系統の監視を併走させている。個人開発の構成ガイドは「サービスをどう作るか」の話だが、こちらは「動かし続けるにはどう見張るか」まで含めた構成になっている。
用途ごとに Render・Vercel・Droplet・Vultr を使い分け、そこに監視の二重化まで足す。個人開発の構成としては過剰かもしれないが、事業を止めないためには、これくらい足しておく方が釣り合っている気がしている。
採用しなかったものにも、それぞれ理由があった
先方の推奨で、うちが採っていないものについても触れておきたい。避けているというより、今のところ乗り換える理由が見当たらない、という判断だ。
- D1 / Turso：エッジで動く軽量なSQLite系のDBだが、今の Neon と Supabase で不足を感じたことがない。実際、Neonは容量が枯渇しかけたことが一度あったが、それは移行の理由にはならず、運用でしのげる範囲だった。
- BetterAuth：Privy と Supabase Auth ですでに用は足りている。認証まわりを入れ替えるコストに見合う利点が今は見えない。
- TanStack Start：新しい選択肢として面白いとは思うが、乗り換える具体的な理由が今のところない。
ここまでの道具にも、それぞれ小さな痛い目を見た記憶がある。R2では一時的なCORSエラーに振り回されたことがあったし、Renderでは負荷が集中して輻輳したこともあった。Resendへの移行自体も、前段のSMTPが壊れたことがきっかけだった。今の構成は、教科書どおりに選んだというより、実際に動かしながら痛い目を見て、その都度直してきた結果でもある。
流行を見て焦る前に、棚卸しをする
見終えて思ったのは、話題になっている技術選定を見るたびに「うちは遅れているんじゃないか」と焦る必要はない、ということだった。今回は、改善できる場所を探しに行ったつもりが、ほとんどの場所ですでに同じ答えにたどり着いていた。違いがあった部分も、流行に乗り遅れていたからではなく、事業として運用するために別の判断をしていただけだった。
私たちは普段、メタバースの中の体験を「入場した瞬間から退場まで、感情の動きを設計する」という目線で見ている。今回気づいたのは、自分たちを支えている裏側の構成にも、同じ棚卸しの目線が要るということだ。流行を眺めて焦る前に、まず自分の足元を一つずつ並べてみる。それだけで、たいてい答え合わせになる。
Boundary LAB は「境界を越える体験を設計する」会社です。自社ホスティングのメタバース rezona を運営しています。空間づくりのご相談は X（@shuuuuuuvuu）の DM へ。私たちについては Boundary LAB について もどうぞ。