「SaaS is Dead」の正体 ─ 生成AI時代に業務アプリは“製品”から“実行レイヤー”へ
最近、海外のテック業界を中心に「SaaS is Dead（SaaSは死んだ）」という刺激的な言葉が話題になっています。これはもちろん、SaaSというビジネスやシステムが消滅するという意味ではありません。従来のように「人間が画面（UI）を開いて操作すること」を前提に設計された業務アプリの価値が、急速に相対化しているという指摘です。
なぜ「Dead」と言われるのか。その背景にあるのが、生成AIとAIエージェントの普及です。利用者はアプリごとの画面を渡り歩くのをやめ、「何をしたいか」を自然言語で指示し、裏側でAIに複数サービスをまたいで処理させる使い方へ移り始めています。価値の中心は、表層の「UI」から、裏側の「API・ワークフロー・実行制御」へとシフトしつつあります。
このパラダイムシフトにより、業務アプリのあり方も激変します。これからは、単体の完成品（ソフトウェア）として選ぶだけでなく、AIが駆動する業務プロセスの「部品」として接続・組み替える対象になります。言い換えるなら、アプリは「人が使うもの」から「AIに自律駆動させるもの」へと変わっていきます。
年明け早々にAnthropicが、Claude Codeのエージェント能力を非エンジニア向けに解放し、業務オペレーションそのものをAIが肩代わりする「Claude Cowork」を発表した影響も大きいです。Microsoftも「Copilot Cowork」で追従しようとしています。ほかにもSalesforceの「Agentforce」など、エージェント主体の業務アプリ操作にシフトしつつあります。
これに伴い、IT部門に求められる役割も、従来の「導入・アカウント管理」中心から、「実行基盤のアーキテクチャ設計と統制（ガバナンス）」中心へとシフトします。
一方で、この変化はIT運用に新たなリスクをもたらします。
第一に、「権限の肥大化」です。AI連携が増えるほど、マシンアカウントやAPIトークンに過大な権限が与えられやすくなります。
第二に、「監査と説明責任の難化」です。どの判断を人間が行い、どの処理をAIが実行したのかを追跡できなければ、事故時の原因究明は不可能です。
第三に、「障害時の責任境界の曖昧化」です。複数SaaSとAIエージェントが複雑に絡み合うフローでは、障害の一次ソースの特定が難しく、初動が遅れるリスクがあります。
これらを踏まえ、運用レビューでの確認ポイントも見直しが必要になります。
- AIエージェント経由で実行される業務フローにおいて、過剰な権限付与（特権の肥大化）がないか
- AIの判断と実行ログが、後から確実に監査（トレース）できる状態で残されているか
- 複数サービスを跨ぐフローにおいて、障害発生時の責任分界点とエスカレーション手順が定義されているか
「SaaS is Dead」は、終わりの合図ではなく、業務アプリの構成や評価基準が変わったことを示すシグナルです。例えば個人レベルでのAIエージェントの利用で、買い物を頼んだら「ブラウザを起動して楽天市場のカートに入れる」ところまで勝手に行ったという投稿を見たことがありますが、決済権限まで与えたら、限度額一杯まで使い込まれるインシデントの可能性も想定する必要があります。一方で市場予測からの自動発注などは現在でも普通に動いているところもありますので、利用シーン別での構成やガードレール設置などが構築のノウハウになっていくのだと思います。自社の運用設計をこの新しい前提（AIネイティブ）に合わせてアップデートしていくことです。
