SaaSプラットフォームエンジニアリング：MVPからスケールへ、AI機能を最初から組み込む

このガイドは、新しいSaaSプロダクトを計画しているか、最初のアーキテクチャでは対応しきれなくなったプロダクトを立て直そうとしているファウンダー、プロダクトリーダー、CTOを対象としています。早期に安価に決定でき、後から変更するとコストがかかる事項を、遭遇する順序で説明します。AI機能がマルチテナントプロダクトにどう組み込まれるかも含みます。具体的な事例として、Netbaseが設計・開発・運営するWeb to PrintのSaaSであるPrintcartを取り上げます。

このガイドの内容

• すべてのSaaSプラットフォームの二つの側面
• テナンシーモデルの選択
• 課金、メータリング、エンタイトルメント
• クラウドコストとユニットエコノミクス
• マルチテナントプロダクトにおけるAI機能
• 初回リリースからのセキュリティ
• MVPからスケールへ：段階とタイムライン
• 基盤を構築するかそれとも再利用するか
• 具体的な事例：Printcart
• アーキテクチャ決定チェックリスト
• よくある失敗
• このガイドの限界
• よくある質問
• このガイドの作成方法
• 次のステップ

すべてのSaaSプラットフォームの二つの側面

SaaSプロダクトは、一緒に提供される二つのシステムで構成されます。アプリケーションプレーンとは顧客が対価を支払う部分で、機能・ワークフロー・データを指します。コントロールプレーンとはそれをサービスとして成立させる部分で、サインアップとオンボーディング、テナントプロビジョニング、ID管理、ロール、プラン、課金、メータリング、管理ツール、運用監視が含まれます。

この区別を無視したチームは、一つひとつの近道の積み重ねでコントロールプレーンを偶発的に構築してしまい、百番目の顧客が現れたときにそのツケを払うことになります。意図的に設計したチームは、エンジニアなしで顧客をオンボードし、どのテナントにどのくらいのコストがかかっているかを把握できます。

AWS SaaS Lensも逆の観点から同じ点を指摘しています。テナントに専用リソースがある場合でも、SaaS環境は共有IDやオンボーディング、運用に依存しています。この共有レイヤーこそが、SaaSプロダクトと顧客ごとにソフトウェアの個別コピーをホスティングすることを区別するものです。

テナンシーモデルの選択

テナンシーはSaaSにおける最も重要なアーキテクチャ上の決定です。コスト、分離、コンプライアンス、運用のすべてを同時に形成するためです。AWSは三つのパターンを説明しています：

ほとんどの新規プロダクトにとって、プールされたコアに特定のテナントやサービスをサイロにするオプションを加えることが現実的な出発点です。MVPの運用コストを低く抑えながら、専用データストレージを必要とするエンタープライズ顧客への対応も可能にします。分離、課金、スケールについては、マルチテナントSaaSアーキテクチャガイドで詳しく解説しています。

どのモデルを選択しても、三つの実践が重要です：

• あらゆる場所でテナントコンテキストを保持する。すべてのリクエスト、ジョブ、ログ行、メトリクスは、クライアントが変更できる値からではなく、認証済みIDから取得したテナント情報を持つ必要があります。
• アプリケーションの下層で分離を強制する。データベースポリシー、スコープ付き認証情報、またはテナントごとのキーを使用し、一つのクエリでフィルターが漏れても他のテナントのデータが露出しないようにします。
• ノイジーネイバーを想定する。レート制限、テナントごとのクォータ、バックグラウンドジョブの公平性により、一つの重いテナントが他のテナントを遅くしないようにします。

課金、メータリング、エンタイトルメント

価格設定は頻繁に変わるプロダクト上の決定であるため、エンジニアなしでビジネスが変更できるアーキテクチャを構築する必要があります。

• エンタイトルメントをプランから分離する。コードは「このテナントは機能X（上限Y）を利用できるか？」と問うべきであり、「このテナントはProプランか？」と問うべきではありません。プランは、エンタイトルメントにマッピングされる設定になります。
• 初回リリースからメータリングを行う。最初の価格設定がフラットなサブスクリプションであっても、テナントおよび機能ごとに利用イベントを記録します。利用データは後から価格設定をどう行うか、各テナントへのサービスコストがどれくらいかを教えてくれます。
• カードデータには決済プロバイダーを使用する。カードの取得、トークン化、継続課金はプロバイダーに任せ、カードデータを自社システムに保持しないようにします。
• 課金だけでなくライフサイクル全体を設計する。トライアル、アップグレード、ダウングレード、按分計算、支払い失敗、猶予期間、解約、データ保持のすべてにローンチ前に定義された動作が必要です。
• 財務部門に可視性を提供する。収益、解約、支払い失敗のレポートは手動エクスポートではなく管理コンソールに備わっているべきです。

クラウドコストとユニットエコノミクス

SaaSでは、クラウドコストは売上原価の一部です。問うべき問いは「プラットフォームにかかるコストは？」だけでなく、「各テナントにかかるコストは？その価格でカバーできているか？」です。

FinOps Foundationは、FinOpsをエンジニアリング、財務、ビジネスチーム間のコラボレーションを通じてテクノロジーのビジネス価値を最大化し、財務的説明責任を生み出す運用フレームワークおよび文化的実践として定義しています。SaaSプロダクトにとって、これはいくつかの具体的な習慣になります：

プロバイダーの選択はこれらの習慣ほど重要ではありません。NetbaseはAWS、Google Cloud、DigitalOcean、Cloudflareと連携しており、プロダクトはクライアントが選択するクラウドアカウントで動作します。クラウドパートナーティアは主張していません。小規模なプロダクトはよりシンプルなインフラからスタートし、負荷、コンプライアンス、または地域の要件が必要になったときに大きなプロバイダーに移行できます。ただし、アプリケーションがポータブルに構築されていることが条件です。SaaSのクラウドコスト管理ガイドでは、これらの習慣を実際のコントロールに変える方法を説明しています。

マルチテナントプロダクトにおけるAI機能

顧客は今や、SaaSプロダクトが利用しているワークフローの中で要約、検索、下書き作成、質問への回答を行うことを期待しています。これらの機能は上記のすべての決定に触れます。テナントデータを読み込み、呼び出しごとにコストが発生し、情報を漏洩させたり作り出したりする可能性があります。一つの画面に後付けするのではなく、プラットフォームに組み込んで設計してください。

• テナントスコープの検索。ドキュメントを検索するアシスタントは、現在のテナントのデータのみ、かつユーザーが閲覧可能なものだけを検索する必要があります。データベースの場合と同様に、アプリケーションの下層で強制される個別のインデックスまたは必須のテナントフィルターを維持してください。
• デフォルトでクロステナント学習を行わない。特定の顧客データで共有モデルをファインチューニングしたり、モデルプロバイダーがそのデータでトレーニングしたりしないようにします。利用から学習することで価値が生まれる場合は、テナントレベルのオプトインを提供し、利用規約に明記します。
• テナントごとにモデルコストをメータリングする。テナントおよび機能ごとにモデル呼び出しとトークンをメータリングし、エンタイトルメントにマッピングして上限を設定します。AIは一つの重いテナントがプランの利益を消してしまう最初の機能になりがちです。アドオン、従量課金、または制限として価格設定してください。
• インターフェースの背後でモデルを選択する。モデル呼び出しを自社のサービスレイヤーの背後に置き、価格と品質の変化に応じて機能ごとにモデルやプロバイダーを変更できるようにします。特定のリージョンまたはプライベートデプロイメントを必要とするエンタープライズテナントにも対応します。
• 評価と人間によるコントロール。各リリース前に固定評価セットに対してAIの出力をテストし、コンテンツがAI生成であることをユーザーに示し、データやお金を変更するアクションは人間の確認を必要とします。

Netbaseはこれらの機能を、一つのAIベンダーに縛られることなく、プロダクトごとに選択したモデルで構築しています。幅広い作業についてはAIとデータサービスをご覧ください。

初回リリースからのセキュリティ

テナント分離はアクセス制御の問題であり、アクセス制御はWebアプリケーションが最も頻繁に失敗する箇所です。OWASP Top 10:2025は「Broken Access Control」を最初に挙げています。SaaSプロダクトでは、テナントチェックが一つ欠けるだけで、ある顧客のデータが別の顧客に露出する可能性があり、これは多くの若いプロダクトにとって事業終了につながるイベントです。

初回リリースからこれらを組み込んでください：

• テナントスコープの認可：すべてのエンドポイントとバックグラウンドジョブに適用し、別のテナントのデータを読み取ろうとする自動テストを用意します。
• 強力な認証：管理者にはMFA（多要素認証）、要望があるビジネス顧客にはシングルサインオンを提供します。
• 暗号化：転送中および保存時に暗号化し、アプリケーションコードの外でキーを管理します。
• セキュアなデリバリー：コードレビュー、依存関係スキャン、何がどこにデプロイされているかの記録を維持します。
• ロギングとアラート：「誰がいつこのテナントのデータにアクセスしたか？」に答えられるようにします。
• バックアップとリカバリー：バックアップジョブを実行するだけでなく、リストアすることでテストします。
• AI入力を信頼しない。ドキュメントやプロンプトが別のテナントのデータを開示するようアシスタントに指示したり、承認をスキップさせたりできないようにします。

SaaSセキュリティチェックリストでは、このリストを10の領域に展開し、それぞれの証跡も示しています。

Netbaseのデリバリーはこの実践セットに従っています：セキュアなコードレビューとバージョン管理、転送時のTLSと保存時のAES、ロールベースのアクセス制御、管理ダッシュボードへのMFA、脆弱性スキャンと侵入テスト、ディザスタリカバリ計画。NDA、DPA、SLAは要請に応じて提供します。Netbaseは情報セキュリティ管理についてISO 27001認証、SOC 2 Type II認証を取得しています。これらはNetbase自身の運用をカバーするものです。お客様のプロダクトとホスティングには、独自のコントロール、証跡、そして顧客が要求する場合は独自の監査が必要です。

MVPからスケールへ：段階とタイムライン

スケールは、大きくなる一つの問題ではなく、異なる問題の連続です。各段階では、次の段階に進む前に何かを証明する必要があります。

これらはNetbaseの一般的な範囲であり、見積もりではありません。ワークフローの数、インテグレーション、コンプライアンス要件、プロダクト決定の成熟度によって、プロジェクトがどこに落ち着くかが決まります。MVPが8〜12週間に収まるのは、スコープが厳格に管理されている場合のみです。一つのコアジョブを、コントロールプレーンの基本を整えた上でしっかりと実装することが条件です。SaaS MVPアーキテクチャガイドでは、そのスコープと初期の決定事項を詳しく説明しています。

MVPに含めるべきもの、待てるもの：

基盤を構築するかそれとも再利用するか

コントロールプレーンはプロダクト間で似た構造を持つため、再利用の最有力候補です。プロダクト化されたモジュールの再利用により、開発時間を最大60%短縮できます。この短縮効果は、モジュールがプロダクトをどれだけカバーするかによって異なり、モジュール再利用に適用されるものであり、プロダクト全体ではありません。ドメイン機能はあなたのために設計・開発する必要があります。プロダクトがマルチテナントサービスではなくストアである場合は、カスタムECプラットフォームガイドが適切な出発点です。

再利用が意味をなすのは以下の場合です：

• モジュールがアカウント、テナント、ロール、課金、管理、インテグレーションをカバーしており、プロダクトをそのモジュールの形に押し込めるような制約がない場合。
• あなたのプロダクトのために作成されたコードの所有権を維持でき、再利用モジュールのライセンス条件が明確な場合。
• モジュールがデモだけでなく、すでに本番環境で稼働している場合。

NetbaseはこのアプローチをSaaSプロダクトアクセラレータとして提供し、Webアプリケーション開発を通じてプロダクト機能を構築します。週次レビュー付きのアジャイルスプリント、APIファースト、初回リリースから設計に組み込まれたセキュリティで進めます。MVPからスケールまでのプロダクト全体はSaaS開発を通じて対応しています。

具体的な事例：Printcart

PrintcartはNetbaseが設計・開発・運営するWeb to PrintのSaaSです。CMSmart、Cloodo、Poslor、Storellyと並ぶ、五つのNetbaseビジネスディビジョンの一つです。公開されているプロダクトサイトによると、その機能は次の通りです：顧客パーソナライゼーション向けオンラインデザインスタジオ、全注文で返却される印刷対応ファイル、請求書発行とリアルタイムステータスを備えた印刷注文管理、Shopify・Wix・WooCommerce向けアプリ、WebhookによるREST API、マルチストア・マルチベンダー運用、印刷ジョブ履行API。Printcartは販売者自身のストアまたはShopify・Wix・WooCommerce向けアプリとして動作し、約7日でセットアップが完了し、2000以上のストアにサービスを提供しています。

このガイドの決定事項に照らし合わせると、プロダクトが各決定事項の重要性を示しています：

他のプロダクトへの教訓は、インテグレーションの選択にあります。Printcartはストアアプリを通じて販売者がすでに販売している場所で会い、APIを通じてカスタムビルドにも対応しています。多くのB2B SaaSプロダクトは同じ二つのパスを必要とします：一般的なプラットフォーム向けのパッケージ化されたコネクタと、その他すべてへのAPIです。

Printcartポートフォリオ記録はそのスコープ、スタック、運用を紹介していますが、パフォーマンス指標は公開されていません。業界の文脈については印刷・包装を、印刷側のアーキテクチャと内製・外注の選択についてはWeb to Printプラットフォームガイドをご覧ください。

アーキテクチャ決定チェックリスト

これらの質問は、最初のスプリントの前のアーキテクチャフェーズで使用してください。各質問には担当者と書面による回答があります。

質問に担当者がいない場合、それは決定事項ではなくリスクです。回答をアーキテクチャ記録に書き込み、各段階変更時に再確認してください。MVPにとって正しい答えが、エンタープライズプラットフォームにとっては誤った答えであることが多いためです。

よくある失敗

• マルチテナントプロダクトにおけるシングルテナントのショートカット。ハードコードされた顧客設定とスコープのないクエリは、2週目には安価に見えますが、2年目には高くつきます。
• コードへの価格設定の埋め込み。プラン変更にリリースが必要だと、すべての実験でセールスとプロダクトがエンジニアリングを待つことになります。
• 従量課金が必要になるまでメータリングを行わない。その時点では、価格を設計する基盤となる履歴がありません。
• セキュリティをローンチタスクとして扱う。最後に追加されたテナント分離は証明が難しく、見落としやすいです。
• リテンション前のスケーリング。顧客が留まる前にエンタープライズ機能に投資することは、誤った段階への支出です。
• 全テナント共通のAIインデックス。テナントフィルターが強制されていない共有の検索インデックスは、役立つアシスタントをデータ漏洩の経路にしてしまいます。
• テナントあたりのコストを無視する。重いユーザーで損失が出るプランは、成長とともに損失を拡大させます。

このガイドの限界

これはNetbaseのデリバリー経験に基づく実用的なガイダンスであり、独自の研究やベンチマークではありません。テナンシー、FinOps、セキュリティの参照は一般的なフレームワークを説明しており、その適用はプロダクト、市場、規制によって異なります。タイムラインはスコープに依存する一般的な範囲であり、最大60%の再利用の数字はモジュール再利用に紐付いた上限値です。AIモデルの価格と能力は急速に変化します。AIセクションは設計原則を提供するものであり、コストの数字を示すものではありません。Printcartの例は公開されている機能と数字を説明するものであり、このガイドはその内部実装を開示していません。Netbase自身の認証はクライアントのプロダクトやホスティングには及びません。

このガイドの作成方法

Netbaseの編集チームは、Netbaseが公開しているSaaS、セキュリティ、モジュールライブラリのページ、Printcartのプロダクトサイト、AWS・FinOps Foundation・OWASPの公開フレームワークを基にこのガイドを執筆し、David（CEO）がすべてのNetbaseに関する事実を確認しました。外部ソースはアクセス日付とともに引用されています。執筆にはAIアシスタンス（Claude）を使用しました。Netbaseの数字はすべて検証済みの社内記録に基づいています。このガイドの目的は、プロダクトチームが早期のSaaS決定を意図的に行い、変更が高くつくようになる前に判断できるよう支援することです。

次のステップ

SaaSプロダクトを計画中または再構築中であれば、プロダクトのアイデア、ターゲット顧客、現在のアーキテクチャをお聞かせください。テナンシー、課金、デリバリープランをマッピングするためのソリューションレビューを予約します。関連サービスを見るか、Netbase JSCのインサイトをもっと読むこともできます。

関連サービスとソリューション