中小SaaS ― マネージドに寄せて少人数で回す ― 生成AI時代のアーキテクチャ超入門

本記事について

当サイトを閲覧いただきありがとうございます。本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「ケーススタディ」カテゴリ第3弾として、中小SaaSのケースについて解説する記事です。

エンジニア5〜30人・有料顧客あり・ダウンタイムが売上に直結するフェーズ。MVPから卒業し「売上を守る」設計に切り替える転換点です。本記事ではマネージド＋IaC＋観測可能性の3本柱、SLA設計、SOC2準拠、マルチテナント設計、AI活用まで扱います。

このカテゴリの他の記事

規模・フェーズ別の実例対比 ― 同じ論点、違う答え ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-case-overview/

個人・スタートアップ ― 1か月で出せる構成が正解 ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-case-startup/

大企業基幹系 ― 新しい技術より組織で成立する設計 ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-case-enterprise/

選定の基本方針

この段階の核心はマネージド + IaC + 観測可能性の3本柱です。IaC（Infrastructure as Code＝インフラをコードで定義・管理）でコード化し、AWS・GCP・Azure のマネージドサービスを徹底活用し、監視・ログ・トレースで挙動を把握できる状態を作ります。

優先する	後回しでいい
可用性99.9%（月43分停止）	可用性99.99%（月4分停止）
マネージド中心・運用を薄く	自前クラスタ・フル内製
IaC（Terraform／CDK）でコード化	GUI手動運用・Excel管理
SLO（Service Level Objective＝運用品質目標）・エラーバジェット運用	SLA契約書だけで運用なし

代表的なプロファイルは、業務 SaaS、B2B 向けツール、マーケットプレイス、業界特化のバーティカル SaaS。「自前で全部」より「マネージドに寄せて少人数で回す」が合理解です。

推奨スタック（全体像）

単一クラウド（AWS or GCP）に寄せ、IaC で管理し、コンテナで動かし、観測可能性を最初から組み込む構成が主流です。個人開発の延長ではなく、SRE観点で検査可能な状態を最初から作ります。

flowchart TB
    USER([顧客])
    CDN[CloudFront / CDN]
    LB[ALB]
    APP[ECS Fargate / Cloud Run<br/>TypeScript / Go / Python]
    DB[(Aurora PostgreSQL<br/>マネージドRDB)]
    REDIS[(Redis<br/>ElastiCache)]
    AUTH[Auth0 / Cognito<br/>SAML/OIDC対応]
    MON[Datadog / New Relic<br/>統合監視]
    IAC[Terraform / CDK<br/>全インフラをコード管理]
    USER --> CDN --> LB --> APP
    APP --> DB
    APP --> REDIS
    APP --> AUTH
    APP -.メトリクス/ログ/トレース.-> MON
    IAC -.|プロビジョン| CDN
    IAC -.| LB
    IAC -.| APP
    IAC -.| DB
    classDef user fill:#fef3c7,stroke:#d97706;
    classDef edge fill:#dbeafe,stroke:#2563eb;
    classDef app fill:#dcfce7,stroke:#16a34a,stroke-width:2px;
    classDef data fill:#fae8ff,stroke:#a21caf;
    classDef ops fill:#f0f9ff,stroke:#0369a1;
    class USER user;
    class CDN,LB edge;
    class APP app;
    class DB,REDIS,AUTH data;
    class MON,IAC ops;

領域	推奨	理由
クラウド	AWS or GCP（単一）	IAM・IaC・監視が一貫
実行環境	ECS Fargate／Cloud Run	K8s不要・マネージド
言語	TypeScript／Go／Python	情報量・AI学習データ豊富
DB	Aurora Postgres／Cloud SQL	マネージドRDB標準
認証	Auth0／Cognito／Firebase Auth	B2Bなら SAML（企業SSOの業界標準プロトコル）／OIDC（OpenID Connect＝OAuth2上の認証標準）対応を確認
監視	Datadog／New Relic	統合ビュー・アラート連携
IaC	Terraform／CDK／Pulumi	全インフラをコード管理

K8s は明確な理由がない限り不要で、ECS Fargate／Cloud Run で十分というのがこの規模の相場です。

システム・デプロイの選択

パブリッククラウド（AWS or GCP）の単一クラウドに寄せ、コンテナベースで動かすのが鉄板です。K8s は運用が重く、専任 SRE がいない規模では負債になります。ECS Fargate（AWS）／Cloud Run（GCP）は「コンテナを投げれば動く」マネージドサービスで、スケーリング・ヘルスチェック・ロードバランサを全て内包します。

CI/CD は GitHub Actions または GitLab CI で構築し、main ブランチへのマージで自動デプロイされる流れを作ります。環境は最低でも dev／staging／production の3面で、Blue/Green or Canary デプロイで本番反映時のダウンタイムを回避します。

選ぶ	避ける
ECS Fargate／Cloud Run	EKS／GKEの手動運用
Terraform／CDKでIaC化	GUIからの手動リソース作成
GitHub Actions／GitLab CI	Jenkinsの自社運用
マルチAZ構成（単一リージョンでOK）	マルチリージョン（コスト過剰）

K8s を選ぶ前に「本当に必要か」を自問する価値があります。大半の SaaS では Fargate／Cloud Run で足ります。

ソフトウェア・データの選択

モノリス or モジュラーモノリスが第一選択で、マイクロサービスは組織が50人を超えてからの論点です。早すぎる分割はネットワーク境界が増えて障害点・レイテンシ・運用コストが跳ね上がるだけで、中小 SaaS には早計な設計です。

DB は PostgreSQL（Aurora／Cloud SQL）を基本に、用途別に Redis（キャッシュ）・S3（オブジェクト）・Elasticsearch（全文検索）を組み合わせます。分析用途が出てきたら、BigQuery／Snowflake／Redshift への ELT を組むのが定石です。

選ぶ	避ける
モノリス／モジュラーモノリス	マイクロサービス（早すぎる分割）
PostgreSQL（Aurora／Cloud SQL）	スキーマレスDBのみで運用
Redis（キャッシュ）+ S3（オブジェクト）	全部RDBに詰め込む
分析はELTで別DWHへ	本番DBで分析クエリ実行

マイクロサービスは「チームの人数が障壁になってから」の処方箋です。

フロントエンド・認証の選択

フロントエンドは Next.js（App Router）+ TypeScript + Tailwind で、メインの Web アプリを構築するのが中小 SaaS のデフォルトです。必要に応じて BFF（Backend for Frontend）を薄く挟み、モバイルアプリを出す場合は React Native／Flutter で共通化します。

認証は Auth0／Cognito／Firebase Auth に委譲するのが標準で、自前実装はここでも禁忌です。B2B サービスの場合は SAML／OIDC対応がエンタープライズ顧客の要件として早期に出てくるため、これらをサポートする IdP を選ぶのが必須です。Clerk は小規模には最適ですが、SAML 対応が上位プラン限定のため、中規模以上では Auth0 が無難です。

選ぶ	避ける
Next.js App Router + TS	旧Pages Router・手書きSSR
Tailwind + shadcn/ui + Design Token	独自CSS設計（人材確保困難）
Auth0／Cognito（SAML対応）	自前認証・Clerk無料プランのみ
MFA必須化 + Passkey対応	パスワード認証のみ

B2B SaaS はSAML対応が契約の条件になりがち。認証基盤選定で必ず確認しましょう。

データ・分析の選択

業務系（OLTP＝PostgreSQL）と分析系（OLAP＝DWH）を早めに分離するのがこの規模からの鉄則です。本番 DB に分析クエリを投げ続けると、顧客の体感速度が遅くなります。BigQuery／Snowflake／Redshift のいずれかを選び、ELT（Fivetran／Airbyte／dbt）で日次〜時間次で同期します。

データ品質・メタデータ管理は最初から組み込むのが後々の AI 活用で効いてきます。スキーマ定義・テーブル命名規則・PII（個人情報）のマスキング方針を決めて、dbt や Great Expectations で自動テスト化するのが現代の標準装備です。

選ぶ	避ける
OLTP（Postgres）+ OLAP（BigQuery等）分離	本番DBで分析クエリ実行
ELT（Fivetran／Airbyte + dbt）	手書きのETLスクリプト
dbt tests／Great Expectations	データ品質のチェックなし
PIIマスキング方針を明文化	個人情報をそのまま分析DBに

分析基盤を後回しにすると、顧客の体感速度で泣く羽目になります。

セキュリティ・監視の選択

この規模ではセキュリティは「標準装備」で、手を抜けません。認証（MFA 必須）・認可（RBAC or ABAC）・暗号化（TLS 必須・at-rest 暗号化）・ログ・監査証跡は全て揃えます。WAF（Cloudflare／AWS WAF）+ DDoS 対策も本番公開時に必須です。

監視は Datadog or New Relic の統合ビューを入れ、メトリクス・ログ・トレース・RUM（Real User Monitoring）を1つのダッシュボードで見られる状態を作ります。SLO（例:可用性99.9%）・エラーバジェットを定義し、アラートを Slack／PagerDuty に繋いで、夜間ページが来る運用体制を作ります。

選ぶ	避ける
MFA必須・Passkey対応	パスワードのみ
WAF（Cloudflare／AWS WAF）	オリジンサーバー直接公開
Datadog／New Relic 統合監視	複数ツールの分断運用
SLO定義 + PagerDuty オンコール	監視はあるが誰も見ない

SLO・エラーバジェット運用は、この規模から始めるのが適切なタイミングです。

中小SaaSの数値Gate

※ 2026年4月時点の業界相場値です。テクノロジー・人材市場の変化で陳腐化するため、定期的にアップデートが必要です。

中小 SaaS 段階では数値で運用を律するのが鉄板。以下が業界標準の指標です。

指標	推奨値	卒業の目安
可用性SLO	99.9%（月43分ダウン）	99.95%へ昇格する規模
エンジニア人数	5〜30名	30名超でマイクロサービス検討
月額インフラコスト	数十万〜数百万円	数千万円で専任FinOps
有料顧客数	数百〜数千	数万で専任SRE
応答時間（P95）	500ms以内	300ms以下でエンタープライズ級
ペネトレ頻度	年1回	エンタープライズ顧客で四半期
MFA必須化	全ユーザー	—
SAML対応	上位プラン	B2B契約で必須
デプロイ頻度	週数回〜日次	Elite レベル目指す
オンコール体制	兼任SRE 2〜3名	専任SRE化

エンジニア30名超 or 月額数千万円のインフラ費が、中小 SaaS 卒業の目安。ここから大企業基幹系に近い体制が必要になります。SLO 99.9%と99.95%で構築コストは数倍違います。この段階では99.9%で十分。

中小SaaSの鬼門・禁じ手

中小 SaaS で事故る典型パターン。どれも大企業の真似またはスタートアップ気分の継続が共通原因です。

禁じ手	なぜダメか
早すぎるマイクロサービス化	Segment 2017年と同じ結末、30人以下はモノリス or モジュラーモノリス
K8sを採用（EKS／GKE手動運用）	専任SREなしでは運用時間を食い尽くす、ECS Fargate／Cloud Run へ
マルチクラウド構成（2クラウド併用）	IAM・監視・IaCが二重化、運用負荷倍増
分析DBを用意せず本番DBで集計	顧客の体感速度が落ち解約原因に、OLTP／OLAP 分離必須
SLOを定義しない	品質を数値で議論できない、「頑張ります」で終わる
B2BでSAML対応を軽視	エンタープライズ契約が取れず成長が止まる
データ品質テストなし	不整合データが分析を汚染、dbt tests 必須
セキュリティ標準装備（MFA・WAF・暗号化）を省略	SOC 2・ISO 27001 取得不能、契約の要件を満たせず
15名でEKS + 12サービス構成	サービス間通信の障害切り分けで毎週1日消耗、Fargate モノリスへ統合の定番事例
PIIマスキングなしで分析DBへ投入	GDPR／個人情報保護法違反リスク

Shopify／Basecampのモノリス継続（Shopify は Ruby on Rails で数億ユーザー規模、Basecamp は十数人で20年以上単一 Rails）と Segmentの140サービス→モノリス統合の対比は、分ける前に本当に必要かを問うという教訓の典型です。

「分けるのはいつでもできる、戻すのは地獄」モノリスで売上が伸びてから慎重に分けましょう。

AI時代の視点

中小 SaaS は AI 活用でプロダクトの差別化を作りやすい規模で、顧客データの整理度合いがそのまま AI 機能の質に跳ね返ります。スキーマ定義・メタデータ・PII 管理を整備しておくと、RAG・ベクトル検索・AI エージェントの組み込みが後から容易になります。

運用面でも AI の恩恵は大きく、IaC（Terraform／CDK）+ 標準的なクラウドサービスという構成は AI が高精度で書けます。逆にオンプレ・独自 PaaS・複雑な K8s 構成は AI が苦手で、運用工数が増えます。選定の原則は「AIが流暢に書ける標準構成」に寄せることです。

AI時代に有利	AI時代に不利
単一クラウド + IaC + コンテナ	マルチクラウド + 独自PaaS
スキーマ定義済みRDB + DWH	スキーマレスDBのみ
OpenAPI／GraphQL Schema 明示	手書きREST・型定義なし
pgvector／RAG前提の設計	古典的RDBのみ

AIが書きやすい構成＝少人数で回せる構成。ほぼ同義です。

よくある失敗

中小 SaaS で頻出する誤判断を整理します。いずれも「大企業の設計を早期に導入した」か「スタートアップの設計から脱却できなかった」の両極端で、段階が合っていないのが共通点です。

早すぎるマイクロサービス化

30人以下のチームでサービス分割すると、運用負荷が分業効果を上回ります。モノリス or モジュラーモノリスで十分です。

K8sを採用してしまう

専任 SRE がいない規模では ECS Fargate／Cloud Run で十分。K8s は運用時間を食い尽くします。

マルチクラウド構成

「ロックイン回避」の名目で2クラウド併用すると、IAM・監視・IaC が二重化して運用負荷が倍増します。

分析DBを用意せず本番DBで集計

顧客の体感速度が落ち、解約の原因になります。

SLOを定義しない

「可用性99.9%目指します」だけで終わると、実測せず、アラートも形骸化します。

B2BなのにSAML対応を軽視

エンタープライズ契約が取れず、成長が止まります。

「大企業がやってるから」と「スタートアップがやってるから」は、どちらもこの段階では危険な根拠です。

エンジニア15名の SaaS 企業で「将来1000人規模を見据えて」と EKS + マイクロサービス12本で構築──サービス間通信の障害切り分けに毎週1日を費やし、結局半年後に「Fargate 上のモノリス」に統合し直した、という話はよく聞かれます。分割時に一緒にうなずいていたエンジニアたちも、統合案を出したら全員が即座に賛成──早すぎる分割は、みんな薄々「間違いだった」と気づいているのに言い出せないだけ、ということも多いと示唆するケースです。

筆者メモ — マイクロサービスから「モノリスに戻した」事例

データ基盤 SaaS の Segment は2017年に「Goodbye Microservices」というブログ記事を公開し、140以上に分割していたマイクロサービスをモノリスに統合し直した経緯を公表して業界に衝撃を与えました。原因はテスト環境構築の複雑化・サービス境界の維持コスト・デバッグの困難さで、「早すぎる分割が運用を食い尽くした」典型として今も語られています。少人数チームが理想論で分割に走った結末として、中小規模SaaS界隈で最も有名な反省文の一つです。

対照的に、Shopify は Ruby on Rails のモノリスで数億ユーザー規模まで到達し、必要になってからモジュラーモノリスに段階的に分割する戦略を取ってきました。Basecamp（37signals）も創業から20年以上、十数人のエンジニアで単一 Rails アプリを運営し続けています。分ける前に、本当に分ける必要があるかを問う──これがこの規模で語り草になっている教訓です。分散システムは問題を解くのではなく、分散システムという問題を追加するだけ、という格言の生きた事例と言えます。

決めるべきこと — あなたのプロジェクトでの答えは？

以下の項目について、あなたのプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。

中小 SaaS の立ち上げでは、以下を1〜2週間かけて丁寧に決めるのが適切です。一度決めたら数年は変えない項目が多いため、時間をかける価値があります。

クラウドベンダー（AWS／GCP 単一選択）
実行環境（ECS Fargate／Cloud Run／必要ならEKS）
言語・FW（TypeScript + Next.js等）
DB構成（OLTP: Postgres／OLAP: BigQuery等）
認証基盤（Auth0／Cognito、SAML対応確認）
監視ツール（Datadog／New Relic）
IaC（Terraform／CDK）
SLO定義（可用性99.9%等）

最終的な判断の仕方

中小 SaaS の選定の核心はマネージドサービスで少人数運用を実現するという発想です。自前で K8s クラスタを組んだり、マルチクラウドで冗長化したりは、この規模では人的リソースを食い尽くします。AWS／GCP の単一クラウドに寄せ、マネージドサービスと IaC を徹底活用するのが合理解です。

もう一つの決定的な軸はSRE観点で検査可能な状態を最初から作ることです。SLO・エラーバジェット・オブザーバビリティ（メトリクス・ログ・トレース）を最初から組み込み、「顧客の体感速度」「障害時の対応速度」を定量的に運用できる状態にします。スタートアップ段階では不要だった論点が、この規模から売上を守る装備として必須になります。

選定の優先順位

単一クラウド + マネージド — 運用を薄くする
IaC化 — インフラをコードで管理する
SLO・オブザーバビリティ — 品質を数値で運用する
セキュリティ標準装備 — MFA・WAF・暗号化を全て

「マネージドに寄せて少人数で回す」のが、中小 SaaS の勝ち筋です。

まとめ

本記事は中小SaaSのケースについて、単一クラウド+マネージド+IaC+SLO・モノリス継続・セキュリティ標準装備・AIが書きやすい構成まで含めて解説しました。如何だったでしょうか。

マネージドに寄せ、IaCで管理し、SLOで律し、モノリスで売上を伸ばす。これが2026年の中小SaaS設計の現実解です。

次回は「大企業基幹系」のケースについて解説します。1000人+のエンジニア・監査対応必須・長期運用前提でのガバナンス重視構成と、ビッグバン刷新を避ける段階移行の作法を掘り下げる予定です。

シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方

それでは次の記事も閲覧いただけると幸いです。