開発未分類
生成AI時代のSaaS生存戦略 - 議論まとめ
概要
生成AIの台頭により、SaaS企業の淘汰が進むという仮説について、四象限フレームワークを用いて整理した議論のまとめ。
前提：生成AIで変わること
需要が減るのはエンジニアではなくIT企業（SaaS事業会社）
生成AIによって「エンジニアが不要になる」のではなく、「AIを活用したいから、AIを一番うまく使えるエンジニアを採用する」という流れになる。
新しいプレイヤーの登場
- 従来のエンジニア
- AIネイティブエンジニア（AIで生産性爆上げ）
- AI活用専門家（税理士、医師、弁護士など専門家 × AI）← NEW!
この「AI活用専門家」の増加が、SaaSの内製化を加速させる可能性がある。
生き残るSaaSの条件
以下の条件に該当するSaaSは代替されづらい：
- グループウェア: Google Workspace、Microsoft 365（開発コスト・移行コストが尋常ではない）
- 深いドメイン知識が必要な分野: freee、マネーフォワード、医療、法務、金融系
- ネットワーク効果があるSaaS: Slackコネクトのような他社と一緒に使う機能
- 運用コストが高いSaaS: 決済、認証（セキュリティを考えると運用したくない）
- 低価格SaaS: 運用コストを考えて内製化しない選択
四象限①：SaaSの生存マトリクス
目的：どのSaaSが生き残るか
| スイッチングコスト 高 | スイッチングコスト 低 | |
|---|---|---|
| 内製化障壁 高 | 🏆 王者 | 🛡️ 専門性で防御 |
| 内製化障壁 低 | 🧟 ゾンビ化 | 💀 淘汰候補 |
🏆 王者（内製化障壁 高 × スイッチングコスト 高）
- Google Workspace
- Microsoft 365
- Salesforce（エンタープライズ機能）
🛡️ 専門性で防御（内製化障壁 高 × スイッチングコスト 低）
- freee、マネーフォワード（税務連携部分）
- 決済SaaS（Stripe等）
- 認証SaaS（Auth0等）
🧟 ゾンビ化（内製化障壁 低 × スイッチングコスト 高）
- 汎用CRM（Salesforceの基本機能）
- 人事管理（Workday）
- 社内Wiki（Confluence、DocBase）
- 勤怠管理（シンプルな打刻系）
特徴: 切りたいけど移行が面倒で惰性で使い続ける。新規獲得は激減。
実例: Klarnaが1,200のSaaSを削減し、SalesforceとWorkdayの利用停止を宣言
💀 淘汰候補（内製化障壁 低 × スイッチングコスト 低）
- シンプルなタスク管理（Trello、Todoist、Any.do）
- フォーム作成（Typeform、JotForm）
- シンプルなアンケート（SurveyMonkey基本機能）
- 基本的なチャットボット
- ノーコードの簡易ツール
特徴: AIで「作って」と言えば30分で作れるレベル。AI活用専門家が増えると真っ先に内製化される。
四象限②：人材需要の変化マトリクス
目的：これからどんな人材が求められるか
| ドメイン知識 深い | ドメイン知識 浅い | |
|---|---|---|
| AI活用力 高 | 🚀 最強人材 | 💻 AIネイティブエンジニア |
| AI活用力 低 | 📚 従来の専門家（徐々に苦しく） | 📉 代替リスク高 |
🚀 最強人材
税理士×AI、医師×AI、弁護士×AI など。ドメイン知識とAI活用力の両方を持つ。
四象限③：SaaSへの脅威源マトリクス
目的：誰がSaaSを代替するのか
| 従来エンジニアが内製化しやすい | 従来エンジニアでも内製化しにくい | |
|---|---|---|
| AI活用専門家が内製化しやすい | ⚡ 即死 | 🎯 専門家に奪われる |
| AI活用専門家でも内製化しにくい | 🔧 エンジニア採用で対応 | 🏰 鉄壁 |
重要な示唆: ドメイン特化SaaS（freee等）は、「AI活用専門家」に食われるリスクがある。
バリューチェーン視点での分析
SaaS単位ではなく「業務のどの部分を押さえているか」で見る
会計ソフト（freee）を例にした分解：
| 機能 | 内製化障壁 | スイッチングコスト | 判断 |
|---|---|---|---|
| 紙→仕訳変換（入力側） | 低 | 低 | 自分で作る |
| 仕訳→試算表（計算処理） | 低 | 低 | どっちでもいい |
| 税務申告連携 | 高 | 高 | SaaSに任せる |
| 法改正対応 | 高 | 高 | SaaSに任せる |
| 電子帳簿保存法対応 | 高 | 高 | SaaSに任せる |
バリューチェーン視点の四象限
| バリューチェーン上流（入力・作成） | バリューチェーン下流（連携・申告・法対応） | |
|---|---|---|
| 内製化障壁 高 | 専門判断が必要な入力 | 🏰 鉄壁（税務、決済、認証） |
| 内製化障壁 低 | ⚡ 真っ先に内製化 | 🧟 ゾンビ化 |
新カテゴリ：インフラ化
5つのSaaS運命カテゴリ
| カテゴリ | 状態 | 例 |
|---|---|---|
| 🏆 王者 | 全機能が必要とされ続ける | Google Workspace, MS365 |
| 🛡️ 専門防御 | ドメイン知識で参入障壁 | 医療系、法務系 |
| 🧟 ゾンビ | 惰性で残る（新規は減る） | 汎用CRM、社内Wiki |
| 💀 淘汰 | 真っ先に消える | Trello、フォーム系 |
| 🔌 インフラ化 | 一部機能だけ使われる | 会計ソフト、決済 |
インフラ化SaaSの特徴
- バリューチェーンの下流だけ価値がある
- 上流は内製化される → 客単価（ARPU）が下がる可能性
- でも「なくてはならない」から契約は続く
- 競争軸が「便利さ」→「安さ・安定性」に変わる
時間軸で見たSaaSの運命
会計ソフトを例にした時間軸分析：
| 段階 | 状態 | 説明 |
|---|---|---|
| 現在 | 🔌 インフラ化 | 上流（入力）は内製化、下流（税務連携）はSaaS |
| 近い将来 | 🧟 ゾンビ化 | API仕様を読めたが移行が面倒 |
| その先 | 💀 淘汰？ | 直接APIを叩けばいい |
会計ソフトの残存価値
紙/レシート → 仕訳データ → 会計ソフト → 国税庁API/弥生連携
↑ ↑ ↑
AI活用専門家が ただの 「仕様を翻訳してくれる」
すでに内製化 パススルー ＝残存価値
重要な問い: 生成AIに仕様書を読ませて「e-Tax連携のコード書いて」で済むなら、会計ソフトの存在意義は？
SaaSが本当に生き残るための条件
「仕様の翻訳」（AIで代替可能）ではなく：
- 仕様そのものを作る側になる
- ネットワーク効果を持つ
- 運用責任を引き受ける（決済、セキュリティ）
日本市場の特殊性
海外では「SaaS is Dead」議論が活発だが、日本市場は「逆SaaS is Dead」現象が起きている。
- 米国: エンジニアが多い → 内製化が進む → SaaS淘汰
- 日本: エンジニア少ない → SaaS依存継続
しかし: 「AI活用専門家」が増えると、日本でも淘汰が始まる可能性がある。
結論
- SaaS単位ではなく、バリューチェーンのどこを押さえているかで生死が分かれる
- 「インフラ化」は安泰ではなく、単なる時間稼ぎ
- AI活用専門家（ドメイン知識×AI）の増加がSaaS淘汰を加速させる
- エンジニアの未来は明るい（AIを最もうまく使える人材として需要増）