AnthropicのClaudeが新たにリリースした機能によって、Salesforceを始めとするSaaSの株価が大幅に下落したのではという、衝撃的なニュースが入ってきました。
そこで、SaaS業界でデータサイエンティスト/PdMをやっている身として、SaaSに未来がないのかについて考えてみました。
- SaaSは業務を包含するのか、単なる“データ置き場”になるのか？
- 何が変わったのか：AIはUIではなく「操作の経路」を変える
- SaaSは「制約」と「実行」が価値の本体になる
- 「ガバナンスを外に出す」とは具体的に何を指すのか
- 役割分担：AIフロント × SaaSバックの“正しい分業”
- 吸収されるSaaS／残るSaaS
- SaaSのこれからの課金モデル
- AI時代に“強いSaaS”を見極めるチェックリスト
- チェックリスト
- まとめ：AI時代の争点は「UI」ではなく「ガバナンスと実行」
SaaSは業務を包含するのか、単なる“データ置き場”になるのか？
ClaudeやGPT（この後はまとめてAIフロントと呼ぶ）の進化で、会話からそのまま「検索」「更新」「実行」まで進められる世界線が見えてきました。すると、AIフロントややそのLLMを搭載した業務コミュニケーションツールで指示をすれば、そのまま画面上で結果を確認できたり、処理の実行ができたりします。SaaSはデータを持つだけの存在になり、UI/UXは求められなくっていきます。UI/UXは、AIフロントが握り、ユーザーはSaaSを開かなくなる。こうなると、これまでのライセンス課金のビジネスモデルが揺らぎます。
ただ、プロダクト視点で冷静に分解すると、議論の本丸は「UIを取られるか」ではなさそうです。AIが前面に立つほど、価値が増すSaaSと、逆に吸収されていくSaaSがはっきり分かれます。その分水嶺は、制約と実行（ガバナンス）を外部から使える形で提供できるかだと思います。今回は、この観点を掘っていきます。
何が変わったのか：AIはUIではなく「操作の経路」を変える
従来の業務は、ユーザーがSaaSにログインし、画面を開いて、検索して、入力して、承認して…という「UI起点」で回っていました。この状況ではUI/UXの良し悪しが生産性を左右し、ライセンス課金とも相性が良い構造です。
一方、AIフロントが普及すると「操作の経路」が変わります。Slackやチャット上で自然言語で指示すると、AIが裏側で各ツールを叩き、検索し、更新し、次アクションを登録します。人間は最後に承認するだけ、という形に寄っていきます。例えば以下の例です。
「今月の商談で確度70%以上を全部抽出して。金額が空欄のものは担当者に差戻しタスクを作って。今週中の次回アクションが未登録なら自動でリマインド入れて。最後に私に承認依頼を出して。」
つまり、プロダクトが戦う場所は“画面の中”から、“外部から安全に操作される世界”に広がります。プロダクトにとって重要なのは、UIを磨くことと同じくらい、外部からの操作（Actions/API/Policy）を前提にした業務OSとしての設計を持てるかどうかです。
SaaSは「制約」と「実行」が価値の本体になる
AIフロント化が進むほど、SaaSの価値の本体は 制約（Constraint） と 実行（Execution） に寄っていきます。
制約とは、業務の“正しさ”を保証するルールです。参照整合（案件は必ず取引先に紐づく）、必須項目、型、一意性だけでなく、状態遷移（見積→承認→受注の順でしか進まない）、権限制御（誰がどのデータを編集できるか）、監査（誰がいつ何を変えたか）まで含みます。
実行とは、その制約の下で処理が確実に進む仕組みです。承認・差戻し・例外処理、複数オブジェクト更新の原子性、冪等性（同じ操作が二重に来ても壊れない）、失敗時の補償やリトライなどのことです。
AIがフロントに立つほど、UIを経由しない更新が増えます。つまり、制約と実行が弱いプロダクトは、誤更新や二重更新、監査不能、権限逸脱といった事故が露出しやすくなります。AIが賢くなるほど「運用上の正しさ」を守るのが難しくなり、だからこそ壊れない業務OSとしての基盤が価値になります。ここがまさしく、SaaSの生存ラインになるでしょう。
「ガバナンスを外に出す」とは具体的に何を指すのか
「ガバナンスを外に出す」とは何か。単にAPIがあるという話ではありません。重要なのは、制約・実行・監査を、外部AIが“機械的に扱える形”で提供できる状態を指します。
ポイントは３つです。
- 仕様が外部から理解できる
スキーマ、制約、参照関係、状態、そして用語定義（受注・直近・売上などのセマンティクス）が外部から理解できる形で提供されているか。 - 仕様が外部から理解できる（業務アクションAPI）
CRUD APIだけではなく、承認、差戻し、クローズといった業務アクションAPIとして設計されているか。実行前検証（validate/dry-run）や、AIが解釈できる拒否理由、監査ログ取得まで揃っているか。 - ガードレールがある（暴走しても止められる）
スコープ制限、Human-in-the-loop、高リスク操作の制御、異常検知など、エージェントが暴走しても組織として止められるかどうか。
この3点が揃うほど、UIがどこにあっても、外部AIが触っても、プロダクトが壊れにくくなります。そしてそれ自体が“プロダクト価値”になります。
役割分担：AIフロント × SaaSバックの“正しい分業”
AI時代の基本構造は、AIがフロント、SaaSがバックという役割分担になります。ただし、ここで誤解が起きやすいのは、SaaSがバックに回る＝データ置き場になる、ではありません。
AIフロントの役割は、意図理解、曖昧さの解消、手順計画、文章生成、そしてアクションのオーケストレーションです。一方、SaaS側の役割は、System of Recordとしての正本（権限・監査・整合性）と、System of Actionとしての実行ルール（状態遷移・承認・例外処理・責任境界）を担うことです。
AIが強くなるほど、人間の操作は減りますが、組織として許される実行の枠組みはむしろ厳密に必要になります。したがって、SaaSが「実行の正しさを強制できる」構造を持っていれば、UIをAIに渡してもバックの価値は消えません。
吸収されるSaaS／残るSaaS
AIによって「吸収される」とは、SaaSが提供していた“アプリ内の手順（UI操作＋軽いルール＋通知+AI実行）”が、外部のAIエージェント＋自動化基盤に移植されることです。典型例は、議事録要約→CRM記録、定型レポート配信、文章ベースのナレッジ運用、軽量スコアリングやToDo生成のように、テンプレ、通知、単純ルール+αのLLM処理で成立していた領域です。こうした機能は、LLM＋連携（Actions）で外に出しやすく、正本を持たないほど“API先の一つ”に落ちやすい。
一方で残る強いSaaSは、正本と実行強制を持ちます。権限・監査・状態遷移が強く、例外処理が重い領域（取消・返品・按分・税・通貨・規制対応など）を内包し、外部AIから安全に使えるアクションAPIを提供できる。さらに、エコシステムや標準化、運用ノウハウといった非機能のモートを持つ。こうしたSaaSは、AIフロント化しても価値の中心が残ります。
SaaSのこれからの課金モデル
AIフロント化で「人がSaaSの画面を触る時間」は減り、ライセンス課金は説得力が弱くなります。一方で、SaaSの価値が「正本（System of Record）と実行強制（System of Action）」に寄るほど、課金の軸も UI利用量→“安全に業務を動かす価値” に移っていきます。現実的には、単一モデルへの置換ではなく、以下のハイブリッド化が進みます。
- ライセンス課金 → 「責任者ライセンス＋現場は薄く」へ
使い方が“承認・監査・例外処理”中心になるほど、フル機能のライセンスは管理者／決裁者／オペ責任者に寄ります。
現場はAIや外部UI経由で操作するため、閲覧のみ／限定操作のライトライセンスが重要になります（監査や権限の境界を保ったまま母数を広げられる）。 - 実行課金：Actions / Workflow / API 呼び出しに課金
AIが業務を“実行”する世界では、価値は「安全に実行できること」なので、業務アクション（承認、差戻し、受注確定、請求確定など）や ワークフロー実行回数に課金しやすい。
ただし濫用・暴走を想定し、上限（Rate limit / Budget）と監査をセットにしたプラン設計が必須。 - 価値課金：正本・監査・ガバナンスを“保険”として売る
「壊れない」「監査できる」「権限逸脱しない」は、AI時代ほど事故コストを減らす価値が大きい。
そのため、監査ログ保全、コンプライアンス、SLA、変更管理、承認フロー、データ保持/リーガルホールド等を エンタープライズ・ガバナンスパックとして上位課金に載せやすい。 - 連携課金：コネクタ／イベント／データ連携の“接続性”で課金
AI・ETL・iPaaS・BI・データ基盤と接続するほど価値が増えるため、Webhook/Event、コネクタ数、同期頻度、データ転送量などを課金単位にしやすい。
「データ置き場」化を避けるには、単なるCRUDではなく **業務アクションAPI＋イベント**を含む“実行の接続性”を商品化するのがポイント。 - AI同梱の課金：SaaS内AIは「補助」になり、主戦場は“制約と実行”の販売
要約や提案などのAI機能は差別化が薄くなりやすい一方、AIが操作しても壊れない設計（dry-run、拒否理由の機械可読、冪等性、補償設計）がプロダクト価値になります。
したがってAIは「追加オプション」よりも、安全な自動実行の権限・監査・制御と一体で売る方が筋が良い。
AI時代に“強いSaaS”を見極めるチェックリスト
AIフロント化が進むと、ユーザーはSaaSのUIを直接触らずに「外部のAI／自動化基盤」経由で操作する比率が増えます。このときSaaS側に求められるのは、壊れない業務OSとしてのガバナンス（制約）と実行（ワークフロー）の提供です。
チェックリスト
- 状態遷移が明示されており、UIだけでなく APIでも強制できる（例：見積→承認→受注の順序を破れない）
- validate / dry-run が用意され、実行前に安全に検証できる
- 失敗時の 拒否理由が機械可読（エラーコード・フィールド・制約ID等）で返る
- RBAC（Role-Based Access Control） / ABAC（Attribute-Based Access Control） がオブジェクト単位だけでなく フィールド単位まで設計されている
- 監査ログ（誰が・いつ・何を）を外部から取得でき、変更追跡が容易
- Webhook / Event が整備され、外部オーケストレーション（AI/ETL/ワークフロー基盤）と自然に接続できる
- 冪等性が担保され、エージェント起因の二重実行でも壊れない
- 途中失敗に備えた 補償設計（compensation / retry / rollback方針） がある
- 高リスク操作に対して スコープ制限・承認フロー・Human-in-the-loopを組み込みやすい
- 例外処理（差戻し、取消、返品、按分、税、通貨、規制対応など）を プロダクト内のルールとして保持している
まとめ：AI時代の争点は「UI」ではなく「ガバナンスと実行」
AIフロント時代に、SaaSが価値を失うかどうかはUIの優劣ではありません。階層データの深さも、単独では決定打になりません。重要なのは、業務の正しさを保証する制約と、正しく進める実行モデルを、外部AIから扱える形で提供できるかどうかです。
“薄いSaaS”は、AI＋内製ワークフローに吸収されやすい。一方で、System of RecordとSystem of Actionを握り、ガバナンスを外に出せるSaaSは、AIが前面に出るほど価値が上がり得ます。
AI機能の追加ではなく、AIに操作される前提で、プロダクトのコアを業務OSとして設計することが重要です。
