SaaS / PaaS / IaaS：技術スタックの「どこを自社で持つか」の判断

「うちのインフラはSaaSとPaaSで構成しています」という説明を聞いたとき、それを技術的な選好の話として流してしまうか、事業戦略の読解として活用できるかで、技術DDの深度が変わります。SaaS・PaaS・IaaSの選択は、自社がどこに価値を生み出し、どこをコモディティとして扱うかの意思表示です。

本稿では、非エンジニアの投資家・M&A担当者がこの概念を事業判断の文脈で読み解くためのフレームワークを提供します。

定義：「誰が何の責任を持つか」という観点から整理する

SaaS・PaaS・IaaSは技術的な実装の差異ではなく、サービス提供者とユーザーの間の責任分界点によって分類されます。

図1：SaaS / PaaS / IaaS における責任分界点の比較

IaaS（Infrastructure as a Service） は仮想サーバー・ストレージ・ネットワークといった計算リソースを貸し出すサービスです。AWS EC2・Google Compute Engine・Azure Virtual Machinesが代表例です。OSのインストールからミドルウェアの設定、アプリケーションの運用まで、利用者がほぼ全てを担います。柔軟性が最も高く、カスタマイズの自由度も大きいですが、それに見合う技術的な管理責任が伴います。

PaaS（Platform as a Service） はアプリケーションを動かすための実行環境・ランタイム・ミドルウェアまでをベンダーが管理するサービスです。Heroku・Google App Engine・Cloud Run・Vercelなどが典型例です。開発者はアプリケーションのコードとデータに集中でき、サーバー管理や運用の大部分をプラットフォームに委ねます。

SaaS（Software as a Service） はアプリケーション機能そのものをサービスとして提供します。Salesforce（CRM）・Slack（コミュニケーション）・Notion（ドキュメント）・Stripe（決済）がその例です。利用者はアプリケーションの設定と自社のデータ管理のみを担い、それ以外の全てをベンダーに委ねます。

「どこを自社で持つか」の判断軸

この3区分を理解した上で重要なのは、どの選択が戦略的に正しいかは事業の性質によって異なるという点です。判断軸は主に2つです。

軸1：その機能は競合優位性の源泉か

自社のコアコンピタンスに直結する機能は、外部サービスへの依存度を下げる方向で設計すべきです。一方で、競合他社も同じように使う汎用的な機能はSaaSに任せる方が合理的です。

たとえば、物流最適化アルゴリズムを差別化の核心とするスタートアップが、その計算ロジックをPaaSの実行基盤上で動かすことは合理的です。しかし同社が社内のHR管理にSaaSを使うことも当然合理的です。「HR管理で競合他社と差をつける」ことは事業戦略ではないからです。

対照的に、金融系スタートアップが「決済処理はStripeで十分」と判断する場合、その判断の背後に「決済フローそのものは差別化要因ではなく、その上に構築するユーザー体験や金融商品が価値の源泉だ」という戦略的認識があるかどうかが問われます。あれば合理的、なければ単なる思考停止です。

軸2：規模拡大時にコスト構造はどう変わるか

SaaS・PaaS・IaaSはそれぞれコストのスケール特性が異なります。

SaaS はユーザー数・シート数に連動する従量課金が多く、組織の成長に伴ってコストが増加します。1人あたりのコストは安定していますが、100人・1000人と組織が拡大するにつれてコストが比例的に増えます。
PaaS はプロダクトの利用量（リクエスト数・処理時間・データ量）に連動します。ユーザーが増えるほどコストが増える構造で、粗利に直接影響します。
IaaS は最初の設定コストが高いですが、一定規模を超えると最もコスト効率が良くなる傾向があります。Netflixが独自のクラウドインフラを深く最適化しているのは、この段階に達しているためです。

スタートアップの初期段階では、SaaS・PaaSの活用が運用コストの最小化と開発スピードの最大化に寄与します。しかしプロダクトがスケールするにつれて、コスト効率の観点から一部機能をPaaSからIaaSへ、あるいはSaaSから内製化へと移行する判断が生まれます。

コスト構造の読み方

M&A・投資評価の文脈では、SaaS・PaaS・IaaSの混在比率がコスト構造の可読性に影響します。

SaaS過多のリスク は「見えない固定費の積み上がり」です。多数のSaaSツールを使うほど、月次のサブスクリプション費用が積み上がります。組織が100人を超えるスタートアップでは、技術系SaaSだけで月数百万円規模になるケースも珍しくありません。しかもこれらのコストは明細が分散しており、全体像を把握している担当者が不在なことがあります。デューデリジェンスでSaaSコストの全量を把握しようとすると、請求書や契約書の収集だけでかなりの工数がかかります。

IaaS過多のリスク は「管理コストの内部化」です。IaaSを使いこなすためにはインフラエンジニアの専門知識が必要です。サーバーの設定・パッチ適用・スケーリング設計・セキュリティ設定など、PaaSやSaaSではベンダーが担う作業を全て自前で行う必要があります。エンジニアが少ない段階でIaaSに過度に依存している場合、実質的に「インフラ管理という事業」を兼ねているという解釈も成り立ちます。

ベンダー依存リスクの評価

SaaS・PaaSを多用するほど、ベンダーの価格変更・サービス廃止・規約変更のリスクを引き受けることになります。評価時に問うべき論点は3点です。

第1に、単一ベンダーへの集中度です。特定のSaaSが業務の中核を担っている場合（例：顧客データの全量が特定CRMに集約されている）、そのSaaSの価格改定や廃止が事業継続性に直結するリスクがあります。

第2に、データポータビリティです。SaaSに蓄積したデータを自社でエクスポートできるか、標準的なフォーマット（CSV・JSON等）で取り出せるかを確認します。特定SaaSのデータ形式に強く依存している場合、移行コストが高くなります。

第3に、契約の引き継ぎリスクです。M&Aにおいて、ターゲット企業が締結しているSaaSの長期契約は買収後に引き継がれることがあります。複数年契約・高額な解約違約金・特定条件下での解約禁止条項が含まれていないか、デューデリジェンスの段階で契約書を精査することが必要です。

投資・買収時のスタック評価チェックリスト

戦略的整合性の評価

コアコンピタンスの技術的実装方法は何か？ — 差別化の核心にあたる機能をSaaSに依存している場合、その理由を確認します（コスト効率の判断か、深く考えていないかを見分ける）
利用SaaSの全量リストは存在するか？ — Shadow ITとして管理外のSaaSが多い場合、コスト管理・情報セキュリティ・契約管理の成熟度が低い可能性があります
技術スタックの選択に明確な理由があるか？ — 「そのときのエンジニアが知っていたから」という選択と、「スケールのコスト特性を考慮して選んだ」という選択では、技術戦略の成熟度が大きく異なります

コスト構造の評価

SaaSコストの月次総額と内訳を把握しているか？ — 主要SaaSの年間契約総額を確認します。ARRに対して過大な場合はコスト最適化の余地があります
PaaSコストの売上連動率はどうか？ — 売上・ユーザー数の増加に対してクラウドコストが線形以上に増加する場合、ユニットエコノミクスが悪化するリスクがあります
コスト最適化の取り組みはあるか？ — 未使用のSaaSシート・過剰なPaaSリソースの定期整理が行われているかを確認します

技術的リスクの評価

重要データのエクスポートは可能か？ — 顧客データ・取引データ・コンテンツ等を主要SaaSからエクスポートできるか確認します
長期SaaS契約の有無と条件は？ — 解約違約金・最低利用期間・自動更新条項を確認します
サービス廃止時の代替手段は検討されているか？ — 特にニッチなSaaSに依存している場合、そのサービスが廃止された場合の影響を評価します

スタートアップのライフサイクルとスタックの変化

最後に重要な観点として、スタックの選択は事業のフェーズによって最適解が変わります。

初期フェーズ（〜PMF前後） では、速度とコストの最小化が優先されます。PaaSとSaaSを最大限活用し、自社でインフラを管理するコストを最小化することが合理的です。Heroku・Vercel・Supabaseのようなフルマネージドのプラットフォームで開発速度を上げ、認証・決済・メールはSaaSに任せる構成は、この段階では最良の選択肢の一つです。

成長フェーズ（PMF後〜Series B前後） では、コスト構造の最適化と技術的負債の解消が課題になります。過去にSaaSで賄っていた機能の一部を内製化するか、よりコスト効率の高いPaaS・IaaSに移行する判断が生まれます。

スケールフェーズ（Series B以降〜） では、IaaSを深く活用した最適化が競争力に直結することがあります。スケールするほどインフラコストの最適化余地が大きくなるためです。この段階でIaaSの運用知識が社内にない場合、採用・育成コストが課題になります。

投資・買収時にスタックのフェーズ適合性を評価することは、「現時点で技術的負債がどの程度積み上がっているか」「将来の成長に向けてどのような投資が必要か」を読み解く上で有効な視点です。

SaaS/PaaS/IaaSの議論は、クラウドベンダー選択とセットで理解が深まります。クラウドサービス入門：AWS/GCP/Azure を「事業上の意思決定」として読み解くでは、どのクラウドプロバイダーを選ぶかの判断軸を解説しています。

アプリケーションをどう設計するかという観点では、アーキテクチャパターン入門：モノリス・モジュラモノリス・マイクロサービス・サーバーレスを判断軸としてでシステム構成の選択について整理しています。SaaS/PaaS/IaaSの選択と合わせて読むことで、技術スタック全体の読解力が高まります。

技術スタックの評価を含む技術DDの全体フレームワークについては、技術デューデリジェンスの全体像と7つの評価軸をご参照ください。

Tied株式会社では、技術スタックの評価を含む技術デューデリジェンス支援を提供しています。詳細は投資家向けサービスページまたはスタートアップ向けのTiedProサービスページをご覧いただくか、お問い合わせからご相談ください。