ポストSaaSとは？AIエージェント時代に主役になるアプリの3つの型

---

SaaSは終わるのか。いま多くの企業で起きているのは、「席を増やしても、もう業務が伸びない」という違和感です。 AIエージェントが実務を回し始めたことで、SaaSの価値は「人が操作する画面」から「AIが業務を進める基盤」へ静かに移り始めています。

この変化を、本記事では「ポストSaaS」と呼びます。 主役になるのは、席数を増やすだけのアプリではなく、業務を地図化し、現場で実行し、使うほど改善が回るアプリ／ソリューションです。

本記事では、ポストSaaS時代の主役を「業務OS」「改善フライホイール」「サービスのソフト化」という3つの型で整理します。 PalantirのOntology、TPSの学習ループ、Service as Softwareの潮流を手がかりに、投資・調達・実装判断に使える見方を提示します。

✅ この記事の結論（TLDR）

• ポストSaaSとは：AIエージェントの普及により、SaaSの価値が「人が操作する画面」から「AIが業務を進める基盤」へ移る流れです。
• 主役になる型①：業務OS：企業の資産・プロセス・制約・責任を地図化し、AIが現場で迷わず動ける前提を作る型です。
• 主役になる型②：改善フライホイール：データ、判断、実行、結果、改善が循環し、使うほど成果が伸びる型です。
• 主役になる型③：サービスのソフト化：ツールではなく仕事そのものを引き受け、価値が席数ではなく実行量・成果近傍へ寄る型です。
• 実務判断：アプリを選ぶ基準は「AI機能があるか」ではなく、顧客業務を地図化し、実行し、改善し続けられるかです。

ポストSaaSとは何か――SaaSが消えるのではなく、立ち位置が変わる

ポストSaaSとは、AIエージェントが業務を実行することで、SaaSの価値が画面操作から業務実行基盤へ移る流れである。

ポストSaaSとは、SaaSが完全に不要になるという意味ではありません。むしろ、SaaSの立ち位置が変わるという見方が重要です。

これまでのSaaSは、人がログインし、画面を開き、情報を入力し、ボタンを押すことで価値を生みました。価値の単位は、多くの場合「ユーザー数」や「席数」に結びついていました。

しかしAIエージェントが業務を実行し始めると、人が画面を操作しなくても、タスクが進む場面が増えていきます。請求書処理、商談メモ整理、問い合わせ対応、レポート作成、承認前チェックなど、従来は人がSaaS上で操作していた作業の一部が、AIやAPI実行へ移ります。

このとき問われるのは、SaaSが「画面として便利か」だけではありません。AIが正しく業務を進められるだけの地図、権限、実行基盤、改善ループを持っているかです。

前提となる流れは、以下の2本の記事で整理しています。シート圧縮記事は「席がなぜ揺らぐのか」、Ambient Agent記事は「SaaSがAIの走る路面になる理由」を扱っています。

何が起きているか――課金・競争・実装の3つの変化

ポストSaaSへの移行は、課金モデル、競争軸、実装方法の3つを同時に変える。

ポストSaaSへの移行は、突然やってきたアイデアではありません。2024〜2026年にかけて、多くの企業で「エージェントPoCは増えるが本番運用は進みにくい」「席課金のままではAIの価値を説明しにくい」という矛盾が見え始めました。

この矛盾をほどく鍵が、課金、競争、実装という3つの変化です。ポストSaaSへの移行を理解するには、この3つを分けて見る必要があります。

変化1：課金モデルが「席」から実行量・成果近傍へ引っ張られる

もし何も手を打たなければ、AIで人の操作が減った分だけ席を削られ、しかし実行量や成果を測る指標を持たないため、値下げ交渉に応じるしかない――そんな状況が起こり得ます。Bainも、AIによって従来の席課金が一部で相対的に弱まり、使用量・成果指標を組み合わせるハイブリッド価格モデルが広がっていると整理しています。

AIエージェントによる実行が増えるほど、席数と価値の相関は弱まります。人間がSaaSを開く回数が減っても、AIが裏側で業務を進めるなら、価値は残ります。むしろ、処理件数、実行量、タスク完了、成果に近い指標の方が価値を測りやすくなります。

Deloitteは、SaaSとAIエージェントの関係について、2026年以降は価格体系の実験が増えると見ています。また、Gartnerの見通しとして、2030年までに企業SaaS支出の少なくとも40%が使用量・エージェント・成果ベースの価格へ移行すると紹介しています。重要なのは、課金モデルの変化は原因ではなく、実行主体が人からソフトへ移ることの結果だという点です。

変化2：競争軸が「機能」から「顧客業務の最適化構造」へ移る

従来のSaaS競争では、機能の多さ、UIの使いやすさ、導入のしやすさが重要でした。もちろん、これらは今後も無意味にはなりません。

ただし、AIエージェント時代の主戦場は、単なる機能差ではありません。顧客の業務をどれだけ正確に理解し、現場で実行し、継続的に改善できるかが競争軸になります。

変化3：実装が「PoC」から実務投入へ寄る

AI活用の価値は、デモ画面ではなく、現場で業務が回り始めた瞬間に出ます。ポストSaaS時代に強いアプリは、PoCで終わらず、承認、例外処理、監査ログ、ロールバックまで含めて実務に入る仕組みを持ちます。

結論として、最初の分岐は「価値が席に乗るか、実行に乗るか」です。 価値が人のUI操作に依存するなら、従来型のSaaS課金は残りやすい。一方、価値が裏側の実行、品質、改善に移るほど、ポストSaaS型の設計が必要になります。

主役アプリを見分ける共通軸――地図×実行×改善

ポストSaaS時代の主役アプリは、顧客業務を地図化し、現場で実行し、使うほど改善が回る仕組みを持つ。

AIエージェントの普及で「席数＝価値」という前提が揺らぐほど、次に伸びるのは、同じ機能を広く配って席を増やすだけのSaaSではありません。

次に伸びるのは、顧客の業務に入り込み、個別最適化で効果を出し、そのやり方を共通アーキテクチャとして再現できるアプリ／ソリューションです。

ここで重要なのは、個別最適化を「毎回作り込む」方向へ進めないことです。それでは、日本のITが長年苦しんできた受託開発型に戻ってしまいます。勝ち筋は、個別最適化のやり方そのものを製品化し、何社でも回せる状態にすることです。

地図：AIが現場制約を踏み外さないための業務モデル

地図とは、AIが「この会社の現実」を踏み外さないための前提です。資産、プロセス、例外、権限、KPI、責任分界などを、AIが参照できる形で整理しているかどうかが問われます。

ここがないと、AIは一般論に逃げるか、現場の制約を破って、それっぽい失敗をします。

実行：PoCで終わらず、現場で回る仕組み

実行とは、デモやPoCで終わらず、現場の例外処理まで含めて「動く状態」に持っていく力です。承認、差し戻し、監査ログ、失敗時のロールバックまで含め、業務の中で回る設計になっているかが重要です。

改善：使うほど成果が伸びる学習ループ

改善とは、一度うまくいったで終わらず、データ、判断、実行、結果、再学習または標準化が循環する構造です。ここがあると、席が減っても価値が増えます。

この3点が揃っているかどうかが、シート圧縮後の主役アプリを見分ける共通軸になります。

型①：業務OS――AIが迷わない「業務の地図」を作る

業務OS型は、企業の資産・プロセス・制約・責任を地図化し、AIが現場で迷わず動ける前提を作る。

ポストSaaS時代の1つ目の型は、業務OSです。これは、単なる業務アプリではありません。企業の資産、プロセス、制約、KPI、責任分界を「業務の地図」として整理し、AIが現場で判断できるようにする基盤です。

この型の代表例として分かりやすいのが、PalantirのOntologyです。Palantirは、データを単に蓄積するのではなく、企業の現実に対応する資産、プロセス、関係性として再定義し、AIやアプリケーションがその上で動けるようにします。

ここで重要なのは、Ontologyが単なるデータモデルではなく、AIが現実の業務を理解し、実行するための地図として機能する点です。

さらにPalantirは、FDE（Forward Deployed Engineer）やBootcampを通じて、顧客現場に入り込み、短期間で実戦配備に近いアプリを構築する仕組みを持っています。つまり、地図を作るだけでなく、現場で動かすところまで型にしているのです。

型②：改善フライホイール――使うほど成果が伸びる仕組みを作る

改善フライホイール型は、現場観察、標準化、実行、計測、改善、再学習を循環させ、導入後に強くなる。

2つ目の型は、改善フライホイールです。AIエージェントを導入して一度成果を出すだけでは、競争優位は長続きしません。重要なのは、現場で得られた結果を次の改善へ戻し、使うほど精度と成果が伸びる構造です。

この考え方を理解するうえで参考になるのが、TPS（Toyota Production System）です。TPSは、現場を観察してムダを特定し、必要なものを必要な時に必要なだけ届ける仕組みへ再設計する思想です。

そのうえで、標準、実行、計測、改善のループを回し、異常が起きれば即座に可視化します。重要なのは、改善が単なる精神論ではなく、現場とシステムを相互適応させる運用の型として設計されている点です。

これをAI運用に接続する場合、単にログを採るだけでは不十分です。AIエージェントのツール利用失敗、APIエラー、ハルシネーション、人間の差し戻しを、評価データやプロンプト改善、ナレッジ更新、モデル改善へ戻す構造が必要です。これにより、エージェントが複数並走する状況でも、動的なリソース最適化と例外処理が回ります。

一回うまくいったで終わらず、次も再現でき、別業務へ拡張できる状態へ近づく。これが、ポストSaaS時代の改善フライホイールです。

型③：サービスのソフト化――ツールから仕事の引き受けへ

サービスのソフト化では、ソフトウェアが単なる道具ではなく、仕事そのものを引き受ける方向へ進む。

3つ目の型は、サービスのソフト化（Service as Software / Services-as-Software）です。これは、AIが便利なツールになるというだけの話ではありません。

従来は人が担っていたプロフェッショナルサービスやBPOの一部を、AIとソフトウェアが引き受け、成果に近いところまで踏み込む価値の移動です。例えば、経理・税務・カスタマーサポート・広告運用などで、「ツールの使い方を教えるSaaS」から「その仕事をまるごと回すAIエージェント付きサービス」への置き換えが静かに進んでいます。

Foundation Capitalは、このサービスのソフト化を、企業が給与や外部サービスに投じる4.6兆ドル規模の支出にAIエージェントが食い込む機会として位置づけています。つまり、これは単なるSaaS市場内の再編ではなく、ソフトウェアが労働や外部サービスの一部を吸収していく大きな構造変化でもあります。

従来のSaaSは、人がUIを操作してタスクを進める前提が強く、価値も課金も席数に乗りやすい構造でした。ところがエージェントAIが普及すると、仕事の中心が「人が触る」から「ソフトが裏側で実行する」へ移ります。

すると価値の源泉は、画面の使い勝手ではなく、どれだけ確実に仕事が片付くか、どれだけ品質と速度が上がるかへ寄っていきます。

ここで強いのは、単発の自動化ではなく、業務の中に入り込み、責任分界と例外処理まで含めて「仕事として完了」させる設計を持つアプリです。

サービスのソフト化は、課金モデルの話である前に、主役アプリが担う価値の定義が変わる話です。 価値が席ではなく、仕事の完了、品質、改善に乗る世界では、勝敗は機能数では決まりません。提供側にとっては、労働集約型サービスをソフトウェア化し、高い粗利と継続収益へ近づける可能性があり、投資家にとっても企業価値評価の前提を変え得る論点になります。

実務ではどう判断するか――3つの質問で見分ける

主役アプリ候補は、業務の地図、実務投入の仕組み、改善ループの3点で見分ける。

たとえば、年次のSaaS棚卸しで「AI機能付き」をうたうアプリが10本並んだとします。どれもデモは魅力的ですが、すべてを更新する予算も、使いこなす人員もありません。

そんなとき、投資、調達、導入判断をシンプルにするために、次の3つの質問だけで十分です。

質問	YESなら強い理由	NOのときに起きがちなこと
Q1：業務の地図があるか？ 資産、プロセス、例外、権限、KPI、責任分界	AIが現場制約を踏み外しにくく、顧客最適化が再現可能な設計になる	一般論の自動化に留まり、成果が出ても横展開できない
Q2：PoCで止まらず実務に入る仕組みがあるか？ 承認、例外、監査、戻し	現場の例外処理まで含めて回るため、価値がデモではなく運用で証明される	実務投入で詰まり、導入したが使われない状態に戻る
Q3：改善が回り、使うほど成果が伸びるか？ 計測、標準、学習	席が減っても価値が増え、課金も成果・実行量側へ自然に寄る	初期効果で頭打ちになり、更新理由が弱くなる

結論として、個別最適化をやり切ること自体が目的ではありません。 個別最適化を同じ仕掛けで何度でも回せることが、シート圧縮後の勝敗を決めます。

まとめ――ポストSaaSの勝者は、業務を動かし続ける仕組みを持つ

ポストSaaS時代の勝者は、AI機能の数ではなく、業務を地図化し、実行し、改善し続ける仕組みで決まる。

SaaS市場再編の本質は、AIエージェントによって実行主体が人からソフトへ移ることにあります。

その結果、席課金の前提が揺れ、競争軸は機能差から顧客ごとの業務最適化を、共通の仕掛けで最短に回せるかへ移っていきます。

本記事で示した3つの型、すなわち業務OS、改善フライホイール、サービスのソフト化は、この新しい競争軸で主役になるアプリ／ソリューションの設計図です。

PalantirのOntology/FDEや、Toyota TPSの学習ループは、その設計図を運用レベルで体現しているリファレンスケースだと言えます。

落とし穴は、「席を削ること」自体を目的にしてしまうことです。 そこに向かうと、成果が落ち、外注費、人件費、炎上対応という別コストで跳ね返ります。ポストSaaSの本質はコスト削減ではなく、業務をより速く、正確に、改善し続ける構造を作ることです。

問いは1つに集約されます。あなたの会社は、AIに「席を明け渡す」側か、それとも「業務の地図」を握る側か。 この分岐は、次の更新交渉の席ですでに始まっています。

2027年に振り返ったとき、「ポストSaaSの波に乗れた会社」と「単なるAI機能追加で終わった会社」の差は、この3つの型をどこまで意識して設計できたかで、はっきりと分かれているはずです。

専門用語まとめ

ポストSaaS

SaaSが消えるのではなく、AIエージェントの普及により、価値の中心が「人が操作する画面」から「AIが業務を進める基盤」へ移る流れ。

Service as Software（サービスのソフト化）

ソフトウェアが単なるツールではなく、仕事そのものを引き受け、サービス提供の一部を置き換える潮流。課金は席よりも実行量・タスク・成果近傍へ寄りやすい。

AIエージェント（Agentic AI）

人の指示待ちの補助に留まらず、計画し、ツールを使い、タスクを実行し、結果を学習して改善する実行主体。

ハイブリッド課金（Hybrid Pricing）

席課金に、使用量、タスク、機能レベル、上限付き従量などを組み合わせる設計。成果報酬へ飛ぶ前の段階移行として現実解になりやすい。

オントロジー（Ontology）

企業の資産、プロセス、制約、関係性を業務の地図として定義する枠組み。AIを現実の制約に結びつけ、実務実行の確度を上げる。

FDE（Forward Deployed Engineer）

顧客現場に深く入り込み、要件、実装、運用改善を高速に回すエンジニア職。導入をデモから実務投入へ寄せる実行部隊。

TPS（Toyota Production System）

必要なものを、必要な時に、必要なだけ届けるため、ムダの除去、異常の可視化、現場とシステムの相互適応を回す運用設計思想。AIエージェントの多タスク実行や例外処理とも構造的に相性が良い。

業務改善フライホイール

データ、判断、実行、結果、再学習が循環し、改善が自己強化していく構造。再編期の競争優位は機能数よりこの構造の有無で決まりやすい。

よくある質問（FAQ）

Q1. ポストSaaSとは何ですか？

A1. AIエージェントの普及により、SaaSの価値が「人が操作する画面」から「AIが業務を進める基盤」へ移る流れです。 SaaSが消えるというより、立ち位置が変わると捉える方が正確です。

Q2. SaaS市場再編では何が起きているのですか？

A2. 実行主体が人からソフトへ移り、席課金と機能競争の前提が揺れています。 その結果、業務を地図化し、実行し、改善し続ける仕組みを持つアプリが有利になります。

Q3. シート課金は終わりますか？

A3. 即座に終わるわけではありません。 ただし、エージェント実行が増える領域ほど、使用量、タスク、成果近傍を組み合わせるハイブリッド課金への圧力が強まります。

Q4. PalantirのOntologyは、この記事の3つの型ではどこに当たりますか？

A4. 主に型①の業務OSに当たります。 ただし、FDEやBootcampまで含めると、型②の改善フライホイールにも接続します。地図を作り、現場で動かし、改善する設計を持っている点が特徴です。

Q5. ユーザー企業はまず何から始めるべきですか？

A5. まずは、自社で影響を受けるSaaSを選別することです。 価値が人のUI操作に乗っているのか、裏側の実行・自動化に移っているのかを見極め、削減ではなく再配分と単位変更で成果を守ることが重要です。

参考サイト・出典

合わせて読みたい

更新履歴