「SaaSpocalypse」という言葉には煽りの匂いがあります。ですが一次情報を読むと、問いは単純です。SaaSが一夜で消えるのではなく、AIエージェントが人の代わりに仕事を「完了」させ始めたとき、課金の単位と責任の分界点はどこから組み替わるのか。どのSaaSが圧迫され、どこが逆に太るのか。
私は普段、企業に最新のAI技術を実装し、PoCで終わらせず実務で使える形に落とし込む仕事をしています。その立場から見ると、エージェントがどの単位で課金され、どこまでの権限を持ち、どこで人間に処理を戻すかという設計は、実装がうまくいくかどうかを左右する変数です。だからこそ、SaaSの値付けとガバナンスがどう組み替わるかは、私にとって観察対象ではなく、実装の前提条件そのものだと考えています。
私はこの問い自体、「SaaSは死ぬのか」というフレームでは筋が悪いと考えています。この記事は、Intercom・Salesforce・Microsoft・ServiceNow・Workdayが自ら公開した価格文書と発表資料を手がかりに、その理由を確かめていきます。
本題に入る前に、3つの言葉を定義しておきます。定義がないと、この先の主張は検証のしようがなくなるからです。
まず「SaaSpocalypse」自体。これは業界のコメントやニュースレターで使われている通称であり、正式な市場区分ではありません。
Salesforce・Microsoft・ServiceNow・Workdayは2025年公開の文書、Intercomは現行の公式ページ(継続更新)に基づきます。契約前には必ず最新の公式文書を確認してください。
次に「課金の複線化」。本稿ではこの言葉を、seat課金がまるごと利用量や成果、クレジットに置き換わることではなく、複数の課金軸が同じ契約の中に併存する状態、という意味で使います。この定義には反証点があります。SalesforceがAgentforceでuser licenseを維持したままFlex Creditsを重ねているのがその根拠であり、逆にどこかの主要ベンダーがseat課金を完全に廃止すれば、この定義は崩れます。
最後に「操作価値型SaaS」と「記録価値型SaaS」。操作価値型は、人がUIで同じ操作を繰り返すこと自体が価値の源泉になっているSaaSを指します。記録価値型は、正本データ・承認・監査・責任分界が価値の源泉になっているSaaSを指します。両者は排他的な分類ではなく、多くのSaaSは両方の性質を併せ持ちますが、AIエージェントが担う仕事が増えるほど、どちらの性質が強いかでSaaSの受ける圧力が変わります。この軸は、後半でもう一度使います。
この3つの言葉を前提に置くと、変わっている前提がどこにあるのかが見えてきます。
| 変わる前提 | 従来のSaaS | AIエージェント時代の変化 |
|---|---|---|
| 価値の出し方 | 人がUIを開き、操作して成果を出す | エージェントがAPI・UI・ワークフローをまたいで仕事を進める |
| 課金の単位 | seat数が中心 | seat + 利用量 + 成果 + クレジットの複線化 |
| 運用の単位 | ユーザー登録、SSO、利用ログ | エージェントの役割、許可範囲、監査、コストの可視化まで必要 |
| 競争の焦点 | 画面機能の多さ、操作性 | 完了した仕事の質、ハンドオフ、ガバナンス、システム連携 |
SaaSpocalypseの本質は、値付けと責任分界点の組み替えです。
最も分かりやすい変化は価格です。公式文書を読むと、主要ベンダーは「何人が使うか」だけでなく「エージェントが何をどれだけ完了したか」へ課金軸を広げています。
| ベンダー | 公開文書で確認できる現在の考え方 | 読み解き方 |
|---|---|---|
| Intercom Fin | 成果(アウトカム)ベース課金。Finが問い合わせを解決した、または意図的なハンドオフを伴う手続きを完了したときに課金される | サポートは「何席必要か」より「何件解決したか」に近づいていく |
| Salesforce Agentforce | Flex Creditsによるアクション単位の利用と、従業員向けエージェント用のuser licenseを併用 | CRMでもseat一本足の構造から、エージェントの実行量との混合へ |
| Microsoft Copilot Studio | pay-as-you-goのメーター課金、容量課金や前払いクレジットの購入、Microsoft 365 Copilotとの組み合わせで提供 | エージェントのコストが、特定ユーザー単位のライセンスではなく利用量に応じた単位で扱われる |
ここでのポイントは、成果課金が勝ち、seat課金が負けると単純化しないことです。実際にはseatが残る部分と、利用量・成果に応じた部分が伸びる部分が共存しています。これが、さきほど定義した課金の複線化です。全置換ではありません。
IntercomとSierraをそれぞれ個社単位で読み込んだときの分析を重ねると、この複線化の解像度はもう一段上がります。Intercomの個社分析ではper-outcome課金を「月間の会話量×想定自動解決率」で検算する型を確認しました。これはseat課金の「人数」という固定費思考とは異なり、volume×解決率という変数思考を要求する設計です。一方、Sierraの個社分析ではoutcome-based pricingを、runtimeで引く「outcome境界」(どこまでをAIの成果とし、どこから人間へのエスカレーションとするかの線引き)の延長として整理しました。この2本の分析を突き合わせると、課金の複線化とは単に課金軸が増えることではなく、何をoutcomeと合意するかという交渉コストが、seat契約にはなかった形で新たに発生することだと私は見ています。
エージェントはもはやチャット欄の一機能ではありません。SalesforceはAgentforceを、SalesforceとSlackの中で動く実行レイヤーとして位置づけ、MicrosoftはCopilot Studioを、エージェントを構築・管理・公開するプラットフォームとして扱っています。ServiceNowはAI Agent Studio、AI Agent Orchestrator、AI Control Towerを通じて、構築からガバナンスまでを一続きの運用面として提供し始めました。競争の焦点は、AIボタンの有無ではなく、エージェントをどこにつなぎ、誰が監督し、どう人間にハンドオフするかへ移っています。
この統制の必要性を、価格の変化以上に明確に打ち出しているのがServiceNowとWorkdayです。
この2社の発表から読み取れるのは、企業にとってエージェント導入の論点が「使えるか」ではなく、監査できるか、費用を追えるか、権限を絞れるか、に移っていることです。
私はここが、価格より先に効くレイヤーだと見ています。ガバナンスを提供できないエージェント基盤は、機能がどれだけ優れていても本番導入の土俵に乗りません。
ここまでの一次情報からの推論として、圧迫されやすいのは操作価値型SaaS、重要性が上がりやすいのは記録価値型SaaSである、という整理ができます。
| 圧力が高まりやすい領域(操作価値型) | 理由 |
|---|---|
| カスタマーサポートの一次対応 | 問い合わせ分類、回答、手続き実行、ハンドオフがエージェント向き |
| CRMの入力・更新・フォロー定型業務 | 反復性が高く、ワークフロー化しやすい |
| 社内IT・HRの定型サービスデスク | ルール化された手順と権限管理の相性がよい |
| 定型レポート・ステータス共有 | 情報集約と文面生成の自動化余地が大きい |
| むしろ重要性が上がる領域(記録価値型) | 理由 |
|---|---|
| 正本データ | エージェントが動くほど、記録の置き場が重要になる |
| 権限・承認・監査 | 誰が何を実行したかを追跡できなければ導入できない |
| 業界固有の制約や責任分界 | 汎用エージェントだけでは置き換えにくい |
| 複数システムを横断する連携 | エージェントと人間のハンドオフを設計する必要がある |
SaaSを選ぶ側も作る側も、価格表を開く前に確認すべき点は共通しています。
比較すべきは「50人が使うから50ライセンス必要か」ではありません。見るべきは、1件の問い合わせ解決、1件の商談フォロー完了、1件のチケットクローズ、1回のエージェントのアクション、といった仕事の単位あたりのコストです。契約更新のタイミングでは、seat・利用量・成果のどれで請求されるか、上限設定や予算管理ができるかも合わせて確認する必要があります。ここは公開事例の範囲にとどまり、各社のパイロットにおける完了率・ハンドオフ率・1件あたりコストの実測はまだ揃っていません。
エージェントが前面に出ても、基幹データの正本は別です。次を先に決めておくと、導入後の混乱が減ります。
| 問い | 例 |
|---|---|
| 正本データはどこか | CRM、ERP、ITSM、HRISなど |
| エージェントはどこで実行するか | Copilot Studio、Agentforce、ServiceNow、独自エージェントなど |
| 人間の最終承認はどこで行うか | CRMのapproval、ITSMのchange、契約ワークフローなど |
価格表だけで判断すると失敗します。エージェントごとの権限範囲、実行ログと監査証跡、ハンドオフの条件、サードパーティ製エージェントを含む場合の統制方法は、最低限確認すべき項目です。あわせて、ベンダーの発表は一般提供済みの機能と将来構想が混在しがちなので、追加ライセンスが必要か、自社のコンプライアンス要件に必要な機能が今の時点で備わっているかは分けて読む必要があります。
汎用業務であれば、まずベンダー管理のエージェント機能を試す方が現実的でしょう。自社構築が有利になりやすいのは、強い業界規制、独自データ、複雑な責任分界がある場合です。
私はここまでの一次情報を踏まえて、次のように考えています。seat課金が全滅するような動きは当分起きません。先に動いているのはUIではなく、課金とガバナンスです。そして導入側が見るべき優先順位は、価格表よりもエージェントの権限・監査・ハンドオフが先に来ます。
ただし、これは各社が公開した価格文書と発表資料からの読みです。実際の契約現場で、これらのガバナンス機能がどこまで運用に耐えるかまでは、私にはまだ検証できていません。ここが崩れれば、この記事の結論も書き直します。
ここまで見てきた課金とガバナンスの動きが行き着く先に、本文でまだ扱っていない問いが一つ残ります。エージェントの実行記録・役割・コストの正本を、基幹SaaSが取るのか、それともエージェントプラットフォームが取るのか、という問いです。Workdayが Agent System of Record という名前で先に旗を立てたのは、示唆的です。
この問いは、「ツールを売るか、仕事を売るか」というフレームを提示した記事の続きにあたります。あちらは事業設計の観点でこの分岐を扱いましたが、本記事はその分岐が各社の公開価格文書とガバナンス発表として実際にどう現れているかを確認しました。また、Sierraのoutcome境界と更新耐性を個社で分析した記事とIntercomのper-outcome課金を検算した記事で見た論点は、本記事のガバナンス・ハンドオフの議論の土台になっています。SaaSの価値がどこに残るかをAll-In Podcastの議論から整理した記事は同じ問いを議論ベースで扱ったもので、本記事はそれを一次価格文書とガバナンス発表で検証した位置づけにあります。