マルチテナントSaaSプラットフォーム設計

概要

ベテランの豪州ソロ創業者が、EC事業者に特化した会計SaaSを構築中。汎用の大手会計ソフトでは長年手薄だった領域。初期版はすでに稼働・有償ユーザーあり、この段階から「顧客ごとに手動でセットアップ」方式を脱して、セルフスケールするプラットフォームへ移行する必要があった。

俺の役割: プラットフォーム層の長期エンジニアリングパートナー。VPS統合から始まり、マルチテナント自動構築、運用ツール、創業者が退場した後も10年以上回る設計判断まで担当。

構築中の要素

• セルフサーブのテナント自動構築 — サインアップが自動ジョブを起動し、テナント毎のDB作成、EFマイグレーション実行、デフォルトデータ投入、テンプレート化されたApache vhostフラグメント書き込み、テナント毎のsystemd unit配置まで完了。顧客ごとの手作業ゼロ。
• 暗号化された集中クレデンシャルボールト — 外部サービス（銀行アグリゲータ、SMTP、税務API）のキーをAES-256-GCMで暗号化してバージョン管理付きで保持。テナントは起動時にサービス/環境指定で取得、テナント設定ファイルに機密データは置かない。
• テナント分離層 — リクエスト毎に動的解決するテナント毎DB。運用簡素化が優先になった時に共有DB構成へ安く寄せられる経路も残す設計。EFのグローバルクエリフィルターをORMレベルの第2防壁として配置。
• スーパー管理者用運用ダッシュボード — テナント一覧+ヘルス指標（API稼働、DBサイズ、最終アクティビティ）、ライセンス編集（プラン/最大ユーザー数/最大会社数）、ユーザー・会社追加、漏洩キーのローテーション、suspend/resumeフロー。
• リクエスト境界でのテナント解決 — ミドルウェアでリクエストスコープのパラメータからテナントIDを取得、リクエストコンテキストに付与、ダウンストリームの全クエリ・サービス呼び出しをスコープ化。

納品済み内容

• VPS統合 — Ubuntu 24.04素からKeyHelpフル管理スタック（Apache、PHP-FPM、MariaDB、SVN+WebSVN、Let's Encryptメイン+サブドメイン自動更新）を24時間以内に構築。
• ライセンスシステムスキーマ — プランティア、最大ユーザー・会社数制約、suspend/cancelエンドポイント（ハードウェアバインド解除付き）、E2Eテスト済み。
• テナントテーブルDDL+プロビジョニング契約確定。暗号化設計承認済み（AES-256-GCM、環境変数キー、KeyVersion列でローテーション）。
• 複数のステージング・デモ環境稼働中 — 公開Coming Soonページ+保護された運用ダッシュボード+プロダクトチーム用Swagger APIを並行運用。
• サードパーティ連携の信頼性改善 — 銀行APIキーの環境ミスマッチがデモ環境で静かに失敗していた構成ドリフトを診断・修正。

運用モデル

創業者がプロダクトオーナー+ステークホルダー側（会計、法務、マーケ、税務コンプラ）を担当。俺は技術アーキテクチャ・実装・運用ツールを駆動。意思決定は全て非同期テキストで完結、ビデオコール無し・会議無し、双方のディープワーク時間を尊重する形。主要なアーキテクチャ判断は全て「創業者が5年後に手を引いても、この設計はまだ意味があるか？」の基準で選んでる — まさにそれが狙いの設計だから。

技術スタック

なぜ意味があるのか

SaaSの助言のほとんどは「次のXeroになろう」としてる会社向けに書かれてる。この案件はそうじゃない — 既存大手が手薄な特定マーチャント層に特化した防衛可能なニッチプロダクト。アーキテクチャの目的は1,000万ユーザーの受け入れじゃなく、ソロ創業者が持続可能で地味に強い運用を10年+続けられる基盤の提供。これは思ってるより難しい: 創業者が別の事業に移った後も働き続けるものを作ること。