AI News HubLIVE
站内改写5 分で読了

SaaSはまだ死んでいない

AIエージェントの台頭により、多くの人がSaaSの時代は終わったと宣言していますが、本記事はSaaSはまだ死んでいないと主張します。仕事はチームで行うものですが、エージェントベースのプログラミングは個人向けであり、共有、コラボレーション、テスト、バージョン管理、セキュリティが欠けています。SaaS企業はエージェント向けAPIを提供することで適応し、データの記録システムとなることができます。

ソースO'Reilly AI & ML Radar著者: Mike Loukides

AIエージェントの台頭に伴い、多くの人々がSoftware as a Service(SaaS)の時代は終わったと宣言しています。数回の英語プロンプトとわずかなトークン費用で誰でも自分専用のソフトウェアを作成できるのに、なぜサービスに加入する必要があるのか?自分で作ったソフトウェア(おそらくエージェント内で動作するスキル)は、必要な機能だけを過不足なく備えているはずです。

しかし、SaaSの終焉が語られるたびに、その構図には何かが欠けています。仕事とはグループやチームで行うものですが、現在のエージェントプログラミングは個人が対象です。関連する課題として、SaaS企業は人間向けのダッシュボードやレポート作成に長けていますが、エージェントが必要とするのはデータの表現ではなく、生データそのものです。

優れた営業チームに必要な連携を考えてみましょう。ある営業担当者は顧客情報を管理するデータベースを必要とします。Claude、Gemini、GPTを使えば、SQLiteをバックエンドに、適切なWebフロントエンドを備えたCRMを簡単に構築できます。隣の席の営業担当者も同様のCRMを必要としますが、彼女もAIツールを使って作成できます。しかし、それは彼女のニーズと好みを反映したものになり、全く同じにはなりません。すぐに、チーム内の全員がそれぞれわずかに異なる個人用CRMを持つことになります。バックエンド(Filemaker、SQLite、MySQL、あるいは企業のOracleインスタンス)も異なり、スキーマも微妙に違います。そしてそれらは相互運用できません。

これが最も単純なケースです。全員が独自のデータバージョンを持っている場合、どのように会社全体のレポートを生成するのでしょうか?チームメンバーそれぞれが独自の指標を持っている場合、成功か失敗かをどうやって知るのでしょうか?誰もが自分のサイロ化された世界に閉じこもっています。

Salesforceのようなベンダーに購読料を支払っていないとしても、これは本当に進歩と言えるのでしょうか?むしろ、データと指標の共有を容易にする必要があり、困難にするべきではありません。さらに、Salesforceのような製品には何百もの機能があります。ほとんどの人がそれらのほとんどを必要としませんが、ほぼ全員が誰も必要としない機能を一つは必要とする可能性があります。そして、自分では気づいていなかったデータの価値を引き出す方法、つまりバンドルを購入することで得られる、当面の要件を超えた価値が常に存在します。

人々が自分自身のツールを開発できるようにすることには多くの利点があります。30年前にClaude Codeがあれば、私は確かに担当していた著者を管理するための独自のスキルを「バイブコーディング」していたでしょう。また、ある文書形式から別の形式に変換するために作成したクレイジーなツールもバイブコーディングしていたでしょう。今やエージェントプログラミングが可能になり、自分でツールを作ることはもうないかもしれません。しかし、SaaSのシナリオは、エージェントの世界に欠けているものを浮き彫りにします。それは共有やコラボレーションのためのツールです。誰も自分だけのためにSalesforceの購読を購入しません。それは部門や企業全体のリソースであり、多くの人々で共有されます。そして、簡単に共有できる能力こそ、エージェントプログラミングに欠けているものです。私は自分用のClaudeツールやスキルをいくつか作成しましたが、O'Reillyの他の同僚と共有するのは非常に困難です。ChatGPTの「ビジネスおよびエンタープライズ向けスキル」は、チームメンバー間でのスキル共有や協力的な生成の可能性を示唆していますが、それが実現されているという証拠を見つけるのは困難です。これは技術の過剰な自信の症状だと思います。「.mdファイルを生成して企業のGitHubに置くだけ」と簡単に考えてしまいがちですが、そのプロセスには、特に非技術者にとって多くの摩擦があります。

スキルを企業全体で真に有用にするには、以下が必要です。

  • 共有:プライベートマーケットプレイスとして登録されたGitサーバーを、企業の管理ダッシュボードを介して設定する方法があります。ただし、スキルをマーケットプレイスに公開するにはGitに詳しいユーザーである必要があり、それが問題です。
  • 要件:誰もが個人用ツールセットを構築することを望んでいるわけではありません。それが解決すべき問題です。異なるものを望むユーザー間の違いをどのように解決するのでしょうか?スキルのPRDはどのようなものであるべきでしょうか?
  • コラボレーション:Google Docsを除けば、現在広く使われているコラボレーションツールの状態は貧弱です。Gitリポジトリの異なるブランチで作業し、変更をマージすることはプロのプログラマーには機能するかもしれませんが、他の誰にも機能しません。
  • テスト:エージェントのテストと評価(関連していますが同じではありません)は、まだ十分に理解されていないトピックです。しかし、ユーザーがエージェントツールを使って予測やレポートを作成することを許可するのであれば、それらが逆効果にならないことを確認する必要があります。スキルは他のAIアプリケーションと同様に、時間の経過とともにドリフトします。公開後も、定期的に正しく動作するか評価する必要があります。
  • バージョン管理:他のソフトウェアと同様に(エージェントツールやスキルは、たとえ英語で書かれていてもソフトウェアであることを認識する必要があります)、要件の変化やLLMの動作ドリフトに応じてアップデートすることが重要です。ユーザーが最新バージョンに簡単にアップデートできるようにすることも重要です。これもまた、非技術者向けにGitを適切にラッピングする問題です。
  • セキュリティ:インテリジェントエージェントのセキュリティはまだよく理解されていません。プロンプトインジェクションについては知っていますが、それがまだ解決不可能な問題であることも知っています。攻撃者は新しい方法で悪意のあるプロンプトを注入し続けています。エージェントスキルやツールが企業データにアクセスできる場合、どのような脆弱性があるでしょうか?

プログラミングの民主化はSaaS企業を脅かすものではありませんが、インテリジェントエージェントはより深い課題を提起しています。Jesus Rodriguezが「SalesforceのエージェントはSalesforceにならず、GoogleのエージェントはGoogleにならない」で指摘しているように、SalesforceやGoogleのようなサービスの未来はWeb UIやダッシュボードではなく、エージェント向けに設計されたAPIです。これらのAPIには、人間が一目で状況を把握できるようなデータではなく、「構造化された状態、タスクの目的、関係グラフ、許可されたメモリ、機械可読なセールスプレイブック、意図を更新するための信頼性の高いAPI」が必要です。人間はダッシュボードによるデータ圧縮を必要としますが、エージェントはデータそのものを必要とし、圧縮は自分で行います。SaaS企業は、正確なデータを提供する記録システムになることができます。彼らが認識すべきことは、真の顧客が人間のユーザーではなくエージェントになる可能性があり、それがマーケティング戦略から製品設計、価格設定に至るまで全てに影響を与えるということです。

SalesforceやGoogleが自社のデータにアクセスするためのAPIを構築できない、あるいは構築しないとは言いません。SaaSは依然として関連性を持ちますが、それは現在とは異なる種類のSaaSです。Salesforceのような企業は、どのようなデータが利用可能で、どのように扱うかを知っています。次世代のSaaSを提供するために必要なデータインフラの設計と構築は簡単ではなく、C++ではなく英語でプログラミングしても容易にはなりません。SalesforceやGoogleは何を構築すべきか知っています。彼らはAPIとともに、独自のエージェントスキルコレクションを出発点として提供する可能性が高いです。しかし、大規模で確立された企業は、動きが遅いと不意を突かれる可能性があります。大規模な組織が迅速に動くことは難しいのです。

SaaS企業は momentum(勢い)を持っています。物理学者にとっては inertia(慣性)と同じものです。彼らは変化しなければなりませんが、AI、エージェント、ユーザー定義スキルによって脅かされているわけではありません。機械が使用できる形式でデータを提供するために設計されたAPIを提供することは、明らかな次のステップであるべきです。もし彼らが死ぬとしたら、それは適応しなかったからです。しかし、それは新しいことではありません。