AI時代のSaaSプライシングと競争優位
コアコンピタンス | ネットワーク効果 | 価格差別 | 代理指標 | ソフトウェアの民主化
AI時代にSaaSはどうなるのか。
AIエージェントが開発を加速させる時代、「SaaSを契約するより自社で作った方が早い」という選択肢が現実的になりつつある。一方で、どれだけAIが進歩しても内製では代替しにくい領域もある。
この記事では、AI時代にSaaSが弱くなる領域と強みを持ち続ける領域を整理し、その論理を考える。
SaaSが弱くなる領域
AI時代に内製化の圧力を受けやすいのは、以下の条件を満たす領域だ。
コアコンピタンス領域である
最も重要な判断軸は「その領域が自社のコアコンピタンスかどうか」だ。
コアコンピタンス領域でSaaSに依存すると、いくつかのリスクが生じる。
差別化の喪失。競合も同じSaaSを使っている可能性が高い。同じツールで同じワークフローなら、差がつかない。SaaSは「最大公約数的な機能」を提供するからこそスケールできるが、それは裏を返せば「みんな同じになる」ということだ。
進化のペースが外部依存。SaaSベンダーのロードマップに自社の戦略が縛られる。「この機能が欲しい」と思っても、ベンダーの優先順位次第。コアコンピタンス領域で「待ち」の姿勢を取らざるを得ないのは、競争上の不利になる。
知見の蓄積場所。SaaSを使っていると、ノウハウが「ツールの使い方」に閉じてしまう。内製であれば、ドメイン知識がコードベースと組織に蓄積される。その蓄積が次の進化の土台になる。
継続的な進化が競争優位になる
コアコンピタンス領域は「作って終わり」ではない。市場環境の変化、顧客ニーズの進化、競合の動きに応じて、常に改善し続ける必要がある。
この継続的開発を自社でコントロールできるかどうかが、内製/SaaS選択の分かれ目になる。
- 月次・週次で改善サイクルを回したい → 内製優位
- 年に数回のアップデートで十分 → SaaSでも可
AIは開発コストを下げるが、継続的開発の意思決定と優先順位付けは人間の仕事として残る。エンジニアリング組織を持ち、プロダクト判断ができる企業は、コアコンピタンス領域を内製する選択肢を取りやすくなる。
自社データだけで完結する
SaaSの価値の一部は「外部との接点」だ。他社のデータとのベンチマーク、業界標準との統合、エコシステムへのアクセス。
逆に言えば、自社データだけで完結する用途では、この価値が薄れる。自社のデータ構造に最適化された内製ツールの方が使いやすい。アカウント内に閉じたデータが重要な領域は、AIで痒いところまでケアした専用ツールを作る価値がある。
結果として起きる二極化
┌─────────────────────────────────────────────────┐
│ エンジニアリング組織を持つ企業 │
│ → コアコンピタンス領域はAIで内製 │
│ → 非コア領域はSaaSを活用 │
├─────────────────────────────────────────────────┤
│ エンジニアリング組織を持たない企業 │
│ → コア/非コア問わずSaaSに依存 │
│ → 差別化の源泉が限定される │
└─────────────────────────────────────────────────┘
SaaSは「エンジニアを雇えない企業でもソフトウェアを使える」という民主化の役割を担ってきた。AI時代には、この民主化機能の意味が変わる。
上位層は「AIで内製」に移行し、SaaSの顧客ではなくなる。下位層はSaaSに依存し続けるが、コアコンピタンス領域まで外部依存することになる。内製できる企業とできない企業の格差が、新たな課題になるかもしれない。
SaaSが強みを持ち続ける領域
一方で、AIがどれだけ進歩しても内製では代替しにくい価値がある。共通するのは「自社だけでは原理的に得られない」か「自社で担うにはコストが見合わない」領域だ。
ネットワーク効果・データ集積
「他社も使っている」こと自体が価値になる領域。
- ベンチマークデータ(自社の数値が業界平均と比べてどうか)
- 業界標準のワークフロー(他社と同じプロセスで連携しやすい)
- 外部との接点(顧客・パートナーとの共通プラットフォーム)
これらは内製では原理的に得られない。ネットワーク効果が働く領域では、SaaSの優位性は揺るがない。
例:Salesforce、LinkedIn、Slack
規制・コンプライアンス対応
法改正への追従は継続的なコストがかかる。
- 電帳法、インボイス制度、GDPR等への対応
- 監査対応、認証取得(SOC2、ISO27001)
- 業界固有の規制(金融、医療、製薬など)
「専門家が常にウォッチしている」安心感は、内製では得にくい。法務・セキュリティ部門の負荷を考えると、規制の厳しい領域ほどSaaSの価値が高い。
これは「コアコンピタンスではないが、間違えると致命的」な領域だ。内製するメリットより、専門家に任せるメリットが上回る。
例:会計ソフト、電子契約、医療系SaaS
インテグレーション・エコシステム
他サービスとの連携が事前に構築されている価値。
内製ツールを作っても、連携先のAPI仕様変更に都度対応する必要がある。SaaSベンダーはこのコストを多数の顧客で分散できる。エコシステムへの接続を維持し続けることは、単独企業には重い負担になる。
例:Zapier、HubSpot、Shopify
運用・信頼性
24/365の監視・障害対応、SLAによる保証。
「自分たちで起きてなくていい」価値は大きい。内製の最大の隠れコストは運用だ。開発はAIで加速できても、本番環境の安定運用には人間の判断が必要な場面が多い。
コアコンピタンス領域を内製する場合でも、インフラ層はSaaSに任せる、という選択は合理的だ。
例:AWS、Datadog、PagerDuty
ドメイン知識の結晶
何百社もの利用から蒸留されたベストプラクティス。
優れたSaaSには「この業務はこうやるのが正解」が製品設計に埋め込まれている。内製だと自社の知見しか反映できない。「他社はどうやっているか」を学べるのはSaaSの隠れた価値だ。
ただし、これは両刃の剣でもある。コアコンピタンス領域では「他社と同じやり方」は差別化の放棄を意味する。非コア領域でこそ、この価値が活きる。
例:Figma、Notion、Linear
責任の所在
問題が起きたときにベンダーが責任を取る。
特にセキュリティインシデントや金融事故では、「自社で全責任を負う」リスクを避けたい需要がある。ベンダーに責任を委譲できることは、経営判断として合理的な場合がある。
例:Stripe、Auth0
初期コスト・Time to Value
今日契約して今日使える即時性。
AIで開発速度が上がっても、要件定義・テスト・デプロイ・ユーザー教育のリードタイムは残る。「まず動くものが欲しい」ニーズにはSaaSが応える。
特に非コア領域では、内製にリソースを割く理由がない。SaaSで済むならSaaSを使い、浮いたリソースをコアコンピタンス領域に投下する方が合理的だ。
補足:シート数課金の議論
AI時代のSaaSを語る文脈で「シート数課金が死ぬ」という議論がある。AIエージェントが人間の仕事を代替するなら、ユーザー数ベースの課金は意味をなさない、という主張だ。
この議論は、プライシングの本質を見ると違う景色が見える。シート数課金は「ユーザー数に応じた従量課金」ではなく、顧客の支払い能力を測る代理指標として機能していた。同じソフトウェアでも、5人のスタートアップと500人の大企業で価格が異なるのは、各顧客が得る価値に応じた価格設定を実現するためだ。
AI時代にシート数の有効性が下がるとしても、「顧客の支払い能力に応じた価格設定」という課題は残る。別の代理指標(使用量、成果、データ量など)への移行が模索されるだろうが、シート数ほど「測定しやすく、予算が立てやすく、公平感がある」指標を見つけるのは難しい。
これはSaaS自体の存亡とは別の問題であり、プライシング手法の進化の話として捉えるべきだろう。
まとめ
AI時代にSaaSが直面するのは「死」ではなく「再定義」だ。
判断の軸は「コアコンピタンスかどうか」に収束する。
コアコンピタンス領域:
- 差別化の源泉であり、継続的に進化させ続ける必要がある
- SaaSに依存すると、進化のペースが外部依存になり、競合と同質化する
- エンジニアリング組織を持つ企業は、AIを活用して内製に移行する
非コアコンピタンス領域:
- 「正しくやる」ことが重要で、差別化の源泉ではない
- ネットワーク効果、規制対応、運用、エコシステム連携など、SaaSの価値が活きる
- 内製にリソースを割くより、SaaSを活用してコア領域に集中する方が合理的
SaaSベンダーにとっては、自社が提供する価値がどちらに位置するかを見極めることが重要になる。顧客のコアコンピタンス領域で戦っているなら、内製化の圧力を受ける。非コア領域で価値を提供しているなら、むしろAI時代に「餅は餅屋」として選ばれやすくなる。
一方で、「AIで内製できる企業」と「SaaSに頼り続ける企業」の格差拡大は、SaaS業界全体にとっての課題でもある。民主化機能をどう維持するかは、個社の戦略を超えた論点として残り続ける。
抽出された概念
- Make or Buy判断 - 内製 vs 外部調達の意思決定フレームワーク(コアコンピタンスが核心軸)
- コアコンピタンス - Make or Buy 判断の核心軸(既存ノートに追記検討)
- 代理指標 - シート数課金が「支払い能力を測る代理指標」として機能していた構造(既存ノートに記載済み)