1人では保守できない複雑さに自動化で挑む：マルチテナントSaaS開発記【第1回】
この記事で得られること 「1人で作れる規模」を超えたシステムに挑む際の考え方 複雑なマルチテナントシステムの設計概要 手動テストゼロを実現する自動化戦略 はじめに 「1人で保守できないものは作るな」 ソロ開発の鉄則だと思う。でも、あえてその限界に挑戦してみたくなった。 AIコーディングエージェント（Claude Code、GitHub Copilot等）を数カ月実務で使ってきて、「これなら1人でも複雑なものを作れるかもしれない」と思い始めた。ただし条件がある。徹底的な自動化だ。 このブログでは、マルチテナント型サブスクリプション管理システム「Saru」の開発記録を残していく。複雑なシステムを1人で作り切るために、何を自動化し、どう設計したかを共有する。 なぜ「保守できない複雑さ」に挑むのか AIコーディングエージェントで「ちょっとしたもの」ではなく「本格的なもの」を作ってみたい 1人では普通作れない規模のシステムに、自動化でどこまで対抗できるか試したい 失敗しても学びになる。成功すれば再現可能なノウハウになる Saruの複雑さ 4階層のアカウント構造 一般的なSaaSは「管理者 → ユーザー」の2階層。Saruは4階層ある。 階層 役割 説明 System プラットフォーム管理 全体を統括 Provider サービス提供 SaaSや商品を提供 Reseller 販売代理 Providerのサービスを販売 Consumer 購入・利用 サブスクリプションを購入 さらに： ResellerがPROVIDE権限を持つと独自サービスも提供可能 ConsumerがPROVIDE権限を持つとCreator（個人事業者）になれる この柔軟性が複雑さの源泉であり、差別化ポイントでもある。 4ポータル × 4API 各階層に専用のフロントエンドとAPIがある。 ポータル API ポート System Portal system-api 3001 / 8080 Provider Portal provider-api 3002 / 8081 Reseller Portal reseller-api 3003 / 8082 Customer Portal customer-api 3004 / 8083 ポータルは動的サブドメインで分離（例: provider-xxx.example.com） ...