AIでSaaSを置き換えられるか？ 解約前に確認する記録・権限・復旧
「この顧客の契約を確認して、変更案を作って」と話せば、AIが複数の画面を操作する。人がソフトを開かなくなるなら、そのソフトの利用料は不要になるのだろうか。
ここには、操作画面を使わなくなることと、裏側の仕組みが不要になることの飛躍がある。AIが呼び出した先で顧客情報を保持し、更新できる人を限定し、失敗時に状態を戻しているなら、その仕事は消えていない。
本稿は「SaaS市場が何年後に消えるか」を予測しない。代わりに、出力を作る機能だけを買っていたサービスと、会社の記録・権限・業務の継続を支えるサービスを分ける。前者は代替を試し、後者は責任と費用の移し先まで確認して解約を判断すると提案する。AIの進歩を否定するためではなく、実際に減らせる支出を見つけるための区別である。
この記事の目次
「作れる」と「継続して運用できる」の間にある仕事
説明用に、会議のメモから社内向けの要約を作る専用サービスを考える。AIで同程度の要約を作れ、入力できる情報の条件も満たし、見直しの手間を含めて費用が下がるなら、代替候補になる。成果物を他の場所で保管でき、契約固有の機能へ依存していなければ、移す範囲は比較的限られる。
同じ発想を請求管理へ当てはめると、確認事項が増える。請求書の文章や画面を作るだけでなく、請求番号の重複を防ぎ、取消と再発行を区別し、入金と対応させ、誰が金額を変えたかを追える必要がある。これらは架空の業務例であり、特定製品の機能比較ではない。
AIが画面を生成できることは、その一連の仕組みを既に引き受けた証拠にならない。自作して置き換えるなら、必要な振る舞いを実装し、変更後も保ち、障害時に対応する主体が変わる。安くなる可能性はあるが、「AIが書けるコードの量」と同じ計算ではない。
また、要約サービスにも、保存・共有・機密管理が組み込まれている場合がある。そのときは、見た目が単機能だからという理由で簡単な代替と決めない。分類するのは製品の名前ではなく、自社が実際に依存している仕事である。
会話が自然でも、取引の状態が正しいとは限らない
2024年のτ-benchは、小売や航空の模擬環境で、AIが利用者と会話し、業務ルールに従ってツールを使う課題を評価した。会話の流暢さだけでなく、終わった時点のデータベース状態を正解と比較し、繰り返しの成功も測っている。当時のモデルには成功率と一貫性の課題が報告された。研究論文
これは2024年のモデルと模擬利用者による評価であり、現在の全AIの能力や、日本の実業務の失敗率ではない。古い低いスコアを持ち出して「今も任せられない」と断定することはできない。一方、終わった状態を確かめるという評価の考え方は、代替を試す際の手掛かりになる。
例えば、取消できたとAIが答えていても、実際には予約が残っていれば完了ではない。二回同じ依頼をしたとき、二重に返金してしまうなら、一回の成功画面だけでは採用判断を支えられない。ここで見る対象は回答文より、記録の変化と、許されない操作が起きていないことである。
2025年のτ²-benchは、利用者側も端末の操作などを行う通信サポートの模擬環境を導入した。AIが単独で行う条件から、利用者と協調する条件へ移ると成績が下がる結果を報告している。技術的な推論と、人へ必要な操作を伝えることは同じ能力ではない。後続研究
両研究は課題や環境が違い、数値を直接並べて進歩率を出すものではない。実運用の経済効果も測っていない。ここから借りるのは、自動実行だけを試すのでなく、確認待ちや利用者の誤操作を含む流れまで試すという論点である。
AIを足すことで、既存のSaaSが実行基盤になることもある
置換だけが技術の進み方ではない。SalesforceのAgentforceの公式資料では、エージェントが使うアクションを、FlowやApexなど既存の機能を使って構築する設計が示されている。利用者との接点がAIへ移っても、処理の実行先が既存プラットフォームに残る形がある。公式開発資料
これは提供企業による製品説明であり、独立した費用対効果の検証ではない。その製品を買うべきだという根拠でも、SaaS全体が生き残る証明でもない。ただ、「AIが操作するなら、ソフトの基盤は不要」という一方向の想定には、別の構成を示している。
この構成で見直す対象は、人が画面を操作するための契約と、AIから処理を呼び出すために必要な契約である。席数を減らせても、実行回数や連携機能の費用が増える可能性がある。具体的な条件は製品と契約ごとに異なり、画面を使わないだけで料金が下がるとは限らない。
逆に、既存基盤へ接続できることだけを理由に残す必要もない。必要な記録と処理を別の仕組みに移せ、移行と保守の費用を含めて有利なら、基盤ごとの置換も比較対象になる。守るのは既存ベンダーではなく、業務が成立する条件である。
解約の判定は、最後の例外処理で変わる
仮に、定型見積書の作成をAIへ移したとする。担当者が内容を確認して送付し、正式な受注は従来の販売管理へ登録する。必要な書式を満たし、従来の作成サービスにしかない履歴を使っていないなら、作成機能の解約を検討できる。
ところが、過去の価格承認や契約条件がそのサービスにだけ残っており、更新時に参照するなら、作成画面を使わなくても依存は残る。記録を移して意味を保てるかを確かめるまで、解約の条件は満たせない。
さらに、見積と受注の不一致を検出する作業を人が追加しているなら、それも代替後の費用に入れる。AIの月額だけを旧サービスの月額と比べると、安く見える代わりに手間を社内へ戻しただけかもしれない。
一方、その確認が従来も必要で、追加負担になっていないなら二重に数えない。新旧の案を同じ対象件数、保存期間、提供範囲で比べる。必要な機能が違う案を料金だけで競わせないことが、解約できる機能を正当に見つける条件になる。
見積書を作れた後にも、修正、取消し、担当交代、障害後の再開が残ります。その取引を完了する費用に、AIの生成単価だけでなく状態管理・権限・例外対応を含めて比べます。生成部分を代替し、SaaSを実行基盤として残す案も候補です。
技術戦略を、消滅予想から契約の見直しへ移す
更新時期が迫っている場合も、代替の実験と、次の契約期間に業務を維持する判断を混ぜない。試験が成功する前に基盤を解約すれば、技術への期待を業務停止の危険へ変えてしまう。一方、検証済みの作成機能まで一括更新すれば、削減できる支出を残す。契約上分けられる範囲と期限を確認し、既に代替できた部分から交渉する。
費用は導入時の構築と移行、継続する利用料、確認と復旧、変更への対応を分ける。内製の人件費が固定費だからとゼロにせず、他の仕事に使えなくなる時間も比較する。ただし、不確かな障害損失へ架空の精密な確率を置いて、結論を作る必要はない。
独立した機能の代替が確認できたら、その契約を減らす。記録や責任が残るなら、AIから使う基盤として契約を組み直す。 SaaSの死を予言しなくても、更新のたびに「何に払い続けるか」を選ぶ技術戦略は進められる。