「SaaSの死」とは?AIエージェントの登場で揺らぐビジネスモデル

「SaaSの死」という刺激的な言葉が注目されています。しかし、クラウドサービスやSaaS企業がすぐに消えるという意味ではありません。揺らいでいるのは、利用者が製品ごとのWeb UIを操作し、ID数に応じて料金を払い、記録されたデータを閲覧するという従来の前提です。AIエージェントはこの構造をどこまで変えるのでしょうか。料金体系の変化、推論コスト、ローカルAI、安全性、Web UIが残る理由から検討します。

【関連記事】AIは数字に弱い?LLMでデータ分析を正しく進める方法

AIエージェントが従来型SaaSの前提を崩す

SaaSは、企業がサーバーやソフトウェアを個別に用意する負担を減らし、Webブラウザから共通の業務機能を利用できる仕組みとして普及しました。その価値を支えてきたのが、Web UI、シート課金、業務データの記録という3つの前提です。AIエージェントは、これらを同時に揺さぶる可能性があります。

SaaSのビジネスモデル

従来のSaaSでは、担当者が製品ごとのWeb画面を開き、メニューから必要な機能を選びます。顧客情報を入力し、検索条件を指定し、申請内容を確認して承認ボタンを押すといった操作です。導入企業は業務をシステムに合わせて整理でき、提供企業は共通の画面と機能を継続的に改善できます。操作方法を覚える負担はありますが、画面に表示された選択肢と入力欄が、担当者の作業範囲を分かりやすく示してきました。

利用者ごとにアカウントを発行するため、料金もID数やシート数に連動させやすくなります。営業担当者が増えればCRMの契約数が増え、承認者や閲覧者を追加すればワークフロー製品の料金も増える仕組みです。ソフトウェアを操作する従業員数と、提供企業が支える利用規模がおおむね一致するため、シート課金には合理性がありました。

CRM、ERP、ワークフローなどは、顧客、契約、会計、申請といった業務データを記録・共有するSystem of Recordとしても機能します。System of Recordとは、業務上の正しい記録を保持する基幹システムです。その役割は単なる記録や閲覧にとどまりません。保存するデータの形式、利用者の権限、承認状態、取引の整合性、変更履歴や監査証跡まで管理しています。AIエージェントが普及しても、この土台まで不要になるわけではありません。

「業務の入口」がエージェントへ移る

Microsoft CEOのSatya Nadella氏は2024年12月、業務アプリケーションをCRUDデータベースとビジネスロジックの組み合わせとして捉え、エージェント時代にはビジネスロジックがAI層へ移る可能性を語りました。CRUDとは、データの作成、参照、更新、削除という基本操作です。Nadella氏の発言はSaaS企業の消滅を断言したものではなく、業務ロジックの置き場所とアプリケーションの区分が変わるという将来像を示しています。

現在は、見込み客を登録するならCRM、請求内容を確認するなら会計システム、申請を承認するならワークフローというように、担当者が目的に応じてアプリケーションを使い分けます。AIエージェントが仕事の入口になれば、担当者は「商談内容を登録し、必要な申請を作成して、請求予定へ反映してほしい」と依頼するだけになるかもしれません。エージェントが指示を分解し、APIなどを通じて複数のシステムを参照・更新できれば、担当者が各製品の画面構成や入力手順を覚える必要は薄れます

この変化で失われやすいのは、Web画面そのものではなく、画面を頻繁に操作してもらうことを前提とした製品の価値です。入力と検索の多くをエージェントが代行すれば、画面の使いやすさだけでは差別化しにくくなります。利用者が個々のSaaSを意識せず、エージェントを通じて業務を完了するようになれば、製品の存在感も前面から背後へ移ります。

AIエージェントが崩す3つの前提

AIエージェントによる変化は、次の3点に整理できます。

  • Web UI:担当者が製品ごとの画面を開く方式から、エージェントへ自然言語で依頼し、必要な場合だけ結果を画面で確認する方式へ変わります。
  • シート課金:従業員1人が1つのアカウントを使う構造から、少数のエージェントが多数の処理を実行する構造へ変わり、従業員数と利用量が一致しにくくなります。
  • 記録中心の価値:データを保存して閲覧させるだけでなく、外部のエージェントが正確かつ安全に参照・更新できることが求められます。

特に大きいのは、操作主体の変化です。従業員が各製品へログインするなら、人数は契約規模を測る分かりやすい基準になります。しかし、エージェントが数千件の更新をまとめて実行する場合、利用者(アカウント)が1人でもシステム負荷と業務上の価値は大きくなります。反対に、多数の従業員へIDを発行していても、日常業務の大半を共通エージェントが処理するなら、ID数に応じて課金されるサービスは敬遠されます。

記録と閲覧だけを提供し、APIが乏しい製品や、外部から細かな権限を設定できない製品も不利になります。エージェントが安全に利用できなければ、業務の入口が変わった後も手作業を残さざるを得ないからです。「SaaSの死」が現実になるとすれば、SaaS全体がなくなる形ではありません。人が画面を操作することを前提に価値と売上を作る従来型の製品設計が、競争力を失う形で表れるでしょう。

SaaSは「エージェントが使う業務基盤」へ変わる

AIエージェントが複数のシステムを横断するようになっても、業務データを正確に保つ基盤は必要です。実際の料金体系や業績を見ると、SaaSが消滅する兆候よりも、既存の製品がエージェントを取り込み、操作層と課金方法を組み替える動きが確認できます。

ビジネスロジックはAIが担うのか

AIエージェントが仕事の入口になれば、CRM、会計、ワークフローといった製品の境界は利用者から見えにくくなります。エージェントは依頼を理解し、必要なデータを探し、複数のバックエンドへ処理を振り分けます。従来は各SaaSの内部に閉じていた検索、入力、更新、要約などの手順の一部が、AI層やシステム間の処理を調整する層へ移る可能性があります。

ただし、業務上のすべてのルールがAIへ移るわけではありません。顧客番号の形式、承認済みデータだけを後工程へ渡す制御、取引を矛盾なく更新する処理などは、安定した業務基盤の中で管理する価値があります。AIは曖昧な依頼を解釈し、処理の順序を組み立てる部分に向いていますが、決められた条件を毎回同じように適用する処理まで置き換えるとは限りません。

したがって、ビジネスロジックがSaaSから一斉に消えるという予測は現実的ではありません。自然言語の解釈や複数システムの連携はエージェントが担い、データの制約や取引の整合性は業務基盤が守るという分担が考えられます。利用者が接する操作層と、正確な記録を維持する基盤が分離すれば、SaaSの価値は画面の機能数よりも、エージェントから安全に利用できるデータとルールの管理へ移っていきます。

「シート課金」から複数の料金基準へ

操作主体がエージェントへ移れば、料金もシート数だけでは測れません。実行回数、処理量、利用した計算資源、完了した業務などが、新たな料金基準の候補になります。ただし、現在の市場で起きているのはシート課金の廃止ではなく、利用者単位の料金へ従量課金を加える動きです。

SalesforceのAgentforceには、月額125ドルの従業員向けアドオンや月額5ドルのAgentforce User Licenseといった利用者単位の料金があります。同時に、エージェントが実行するアクションに応じてFlex Creditsを消費する方式もあり、10万Credits当たり500ドルとされています。通常のAgentforceアクションは20 Credits、音声アクションは30 Creditsです。利用者数を基準にする商品と、処理量を基準にする商品が同じサービス内で併存しています。Salesforceは料金例として、100人の担当者が1日3件、月20日ケースを処理し、1件当たり3アクションを使う場合を示しています。この条件では月36万Credits、月額1800ドルです。同社自身が説明用の試算であり、実際の利用量や費用を保証するものではないと注意しています。重要なのは金額の大小ではなく、エージェントが行う仕事をアクション単位で測り、料金へ反映する仕組みがすでに商品化されていることです。

Microsoftも2026年度第4四半期の説明で、利用者単位ライセンスに使用量ベースの課金商品を加えることによる収益機会へ言及しました。同じ四半期にはMicrosoft 365 Commercialの有料シート数が前年同期比6%増え、Copilotの有料シートも3000万を超えています。これはシート課金の終焉ではなく、シート課金と従量課金の複線化を示しています。

SaaS企業は立ち位置が変わる

既存SaaSの業績も、直ちに市場が崩れているという見方とは一致しません。MicrosoftのDynamics 365は2026年度第4四半期に前年同期比13%増収となり、為替一定では12%増でした。Salesforceの2026年度のサブスクリプション・サポート売上は393億8800万ドルで、前年度の356億7900万ドルを上回っています。AIエージェントへの期待が高まる一方で、既存のサブスクリプション事業も大きな収益を維持しています。現在確認できるのは、既存SaaSがエージェントに置き換えられて消える過程ではなく、エージェントを製品内部へ取り込み、新たな機能と課金対象へ変える動きです。SaaS企業には顧客データ、業務ルール、既存の契約関係があります。これらを生かしてエージェントを提供できるため、新興のAIサービスに一方的に市場を奪われるとは限りません。

エージェントが業務を実行するほど、正しいデータを保つ場所の重要性はむしろ増します。顧客、契約、会計、在庫の情報が不正確なら、エージェントは誤った前提で処理を進めます。API、データモデル、アクセス権、監査ログ、トランザクション、外部連携の品質は、画面の使いやすさ以上に製品の競争力を左右する可能性があります。

外部からデータを取り出しにくく、エージェントへ必要最小限の権限を与えられないSaaSは不利になります。反対に、業務データとルールを信頼できる形で提供し、エージェントの操作を記録・制御できるSaaSは価値を維持できます。現実的に起こり得るのはSaaS企業の一斉消滅ではなく、人が直接使うアプリケーションから、人とAIエージェントが共有する業務基盤への進化です。

それでも残るWeb UI

すべての業務をAIエージェントへ任せるには、継続的な推論費用と安全性という2つの壁があります。高頻度の定型処理までエージェント化するにはローカルAIの普及が重要ですが、それだけでクラウドAIやWeb UIを置き換えられるわけではありません。

エージェントのランニングコスト

単純なチャットは、利用者の入力に対して回答を返せば処理が終わります。AIエージェントは、1件の依頼を完了するまでに指示を解釈し、必要な情報を検索し、複数のシステムを参照し、次の処理を判断します。外部ツールを実行した後に結果を確認し、失敗すれば別の方法で再試行することもあります。モデルやツールを何度呼び出すかが事前に決まりにくいため、費用も予測しにくくなります。

クラウドAIの費用は、最終的な回答文だけで決まりません。OpenAIのAPI料金では、モデルの入力、キャッシュされた入力、出力に加え、Web検索、ファイル検索、コンテナ、ツール呼び出しなどにも料金が設定されています。実際の業務システムでは、外部APIの利用料、監視、ログ保存、失敗時の再試行といった運用費も必要です。エージェントの費用を検討する際は、モデルの単価ではなく、1件の業務を完了するまでの処理全体を見る必要があります。

Salesforceの試算が示すように、処理量に連動する料金は利用が少なければ抑えやすい一方、大量処理では実行回数がそのままコスト増につながります。従業員数が一定なら年間費用を見通しやすかったシート課金と比べ、従量課金では業務量やエージェントの動き方まで管理対象になります。エージェントが不要な検索や再試行を繰り返せば、成果を増やさずに費用だけが膨らむおそれもあります。大量の定型処理を常時エージェントへ任せるには、処理内容に応じた低価格モデルの使い分け、同じ情報を何度も読み込まないためのキャッシュ、実行回数の制限が必要です。条件が明確な処理は決められたプログラムへ戻し、曖昧な判断だけをAIへ任せる設計も有効です。エージェント化は、既存のプログラムをすべてAIへ置き換えることではなく、費用と柔軟性が釣り合う部分を選ぶ作業になります。

「ローカルAI」は万能ではない

こうした問題を解決すると期待されているのがローカルAIです。ローカルAIは、端末や社内設備でモデルを動かすため、推論のたびに外部サービスへ料金を支払わずに済みます。通信できない環境でも利用しやすく、機密情報を端末内で処理できる点にも利点があります。高頻度の要約、分類、情報抽出などをローカルで処理できれば、クラウドへ送るデータと呼び出し回数を減らせます。

日常業務の隅々までエージェントを浸透させるには、ローカルAIの一般化が重要な条件になります。Appleは2025年、Apple silicon上で動作する約30億パラメータのオンデバイス基盤モデルと、開発者が利用するためのFoundation Models frameworkを紹介しました。Appleは要約、情報抽出、文章理解などを用途として挙げ、オンデバイス推論を追加の推論料金なしで利用できると説明しています。ローカルAIが研究上の構想ではなく、アプリケーションへ組み込める段階へ進んでいる例です。

ただし、このモデルは幅広い一般知識へ答えるチャットボットを目的としていません。AppleもオンデバイスモデルとPrivate Cloud Compute向けのサーバーモデルを、用途の異なる補完的な仕組みとして位置づけています。複雑な推論や大量の知識が必要な業務まで、端末上の小規模モデルだけで処理できるとは限りません。対応端末の導入、処理性能の確保、モデルの更新、端末管理にも費用がかかります。

定型的で高頻度な処理をローカルAIへ寄せ、複雑な判断や大規模な処理をクラウドAIへ任せるのが現実的な構成です。ローカルAIはランニングコストと情報管理の問題を軽減しますが、AI利用の費用をゼロにする仕組みではありません。クラウドとローカルの振り分けを含めて、1件の業務に必要な総費用を管理する必要があります。

Web UIが異常な操作を防ぐ

AIエージェントは、誤った判断だけでなく、外部から与えられた悪意ある命令に従う危険もあります。NISTは、メール、ファイル、Webページなどへ埋め込まれた命令をエージェントが読み込み、意図しない有害な操作を行う攻撃を「エージェント・ハイジャック」と説明しています。信頼できる指示と、処理対象として読み込んだ外部データを明確に分離できないことが問題になります。メールの内容を確認するだけのAIなら、誤りの影響は回答文にとどまるかもしれません。しかし、同じAIが顧客データの更新、ファイルの送信、コードの実行まで許可されていれば、危険は実際の操作へ広がります。顧客情報の外部送信、データの改変、権限を超えた処理などにつながる可能性があるため、エージェントへ広い権限をまとめて与えることはできません。

OpenAIはエージェントの安全策として、信頼できない入力を高い権限の指示へ直接渡さないこと、構造化された出力でデータの流れを制限すること、入力の検査、評価、ツール実行時の承認などを案内しています。コンピューター操作についても、データの削除、権限変更、第三者への送信、金融取引などは、事前の明示的な許可がなければ実行直前に確認する方針を示しています。対策を組み合わせても誤りを完全にはなくせないため、操作範囲の制限と承認の仕組みが欠かせません

日常的な入力や検索はエージェントへ移っても、重要な更新内容を承認者が確認する画面は残ります。例外処理、設定変更、権限管理、監査ログの確認、障害時の復旧にも、情報を一覧できる画面が必要です。すべての操作を毎回確認すれば効率が落ちるため、不可逆な変更や外部送信など、影響の大きい処理へ確認を絞る設計が求められます。将来のWeb UIは、担当者が毎日の作業を最初から最後まで入力する場所ではなくなるかもしれません。その代わり、エージェントが提案した処理の確認、異常時の介入、権限の統制、監査、復旧を担う画面になります。Web UIは消えるのではなく、操作のための画面から統制のための画面へ役割を変えるのです。

まとめ

「SaaSの死」とは、クラウドサービスや業務データ基盤がなくなることではありません。人が製品ごとのWeb UIを操作し、ID数に応じて料金を払い、記録されたデータを閲覧するという従来の前提が崩れることです。AIエージェントは仕事の入口となり、複数のシステムを横断して、これまで各SaaSに閉じていた処理の一部を担う可能性があります。

ただし、既存SaaSの売上は現在も伸びており、シート課金も消えていません。起きているのは、利用者単位の料金へ処理量に応じた課金を加え、SaaS自体をエージェントが利用する業務基盤へ変える動きです。全面的なエージェント化にはランニングコストと安全性の壁もあります。ローカルAI、クラウドAI、Web UIを用途に応じて使い分ける構成が現実的です。

SaaSは死ぬのではなく、人が操作するアプリケーションから、人とエージェントが共有する業務基盤へ変質します。競争力を失うのは、記録と画面だけを囲い込み、エージェントから安全に利用できない製品です。正確なデータ、細かな権限、監査可能な操作を提供できるSaaSは、AIエージェント時代にも業務を支える役割を担うでしょう。

参考文献

Microsoft Fiscal Year 2026 Fourth Quarter Earnings Conference Call

Salesforce Delivers Record Fourth Quarter Fiscal 2026 Results

Technical Blog: Strengthening AI Agent Hijacking Evaluations

この記事を書いた人

ビジネス・テクノロジスト 貝田龍太