SaaSの死について議論する時に、見落とされていると感じること
近年、AIコーディングの発展によって、自作のアプリケーションやワークフローを構築するコストは下がりつつある。
その結果として、「AIによってSaaSは死ぬ」という議論を目にする機会も増えてきた。
私の理解では、この文脈で語られる「SaaSの死」とは、AIコーディングによって個人や企業が必要な業務システムを安価に自作できるようになり、従来SaaSが担ってきた役割が代替されることで、SaaSが利用されなくなる、あるいは従来ほど必要とされなくなるという意味で使われている。
本記事の目的は、この予測が正しいかどうかを判定することではない。
私が気になっているのは、自作アプリケーションによるSaaSの代替を考える際に、実装上は避けて通れないように思える点が、なぜか議論の中であまり語られていないことである。
AIがコードを書けることと、そのコードによって既存SaaSの役割を代替できることの間には、いくつかの条件がある。
特に私が気になっているのは、自作アプリケーションがSaaS内の正式なデータを扱おうとした時、その処理がSaaSベンダーの設計したシステムや仕様から、どこまで自由になれるのかという点である。
そのため本記事では、私が見落とされていると感じる点を、次の二つの側面から整理してみたい。
一つは、SaaSベンダーが製品を開発する際に設計した仕様から生じる、技術的な制約である。
もう一つは、利用者のデータを安全かつ継続的に運用するために生じる、セキュリティ・運用上の制約である。
そのうえで、これらの制約は自作アプリケーションによる代替の議論の中でどのように考えられているのか、あるいは私が何か見落としている点があるのか、皆さんの意見も伺ってみたい。
技術的な制約
まずは、技術的な制約から整理してみたい。
私が見落とされていると感じる技術的な制約に共通しているのは、SaaS製品を開発したベンダーが設計・実装した仕様である。
AIコーディングによって高度な業務アプリケーションを作成できたとしても、そのアプリケーションが既存SaaSの正式なデータを扱うためには、この仕様を避けて通ることはできないように思える。
言い換えれば、自作による自由化が可能になる範囲は、実質的にはベンダーが公開した仕様によって決まるのではないか、というのが私の疑問である。
私が特に気になっている点は、次の五つである。
① 業務アプリケーションとデータベースの間にある通信・接続層
業務アプリケーションとデータベースは、一体のものではない。
利用者が業務アプリケーションで入力や操作を行うと、その結果がそのままデータベースの中へ書き込まれるように見える。
しかし実際には、業務アプリケーションとデータベースの間には、処理要求やデータを受け渡すための通信・接続の仕組みがある。
業務アプリケーションは、この仕組みを通じて、
• データを取得したい
• 新しいデータを保存したい
• 既存のデータを更新したい
• データを削除したい
といった要求をデータベース側へ渡す。
データベース側は、その要求を受け取り、自らの管理規則に従って処理を行い、成功したか、失敗したか、その結果を業務アプリケーションへ返す。
つまり、業務アプリケーションとデータベースの間には、ベンダーが設計した受け渡し方法と、そのための仕様が存在する。
② APIを利用しても、データベースを直接操作するわけではない
自作アプリケーションからAPIを利用する場合も、この構造は基本的に変わらない。
APIは、ベンダーが外部向けに公開した特定の機能を、決められた方法で利用するための仕組みである。
例えば、自作アプリケーションが顧客情報の更新をAPIから依頼したとしても、自作アプリケーションがデータベースの内部へ入り、直接データを書き換えているわけではない。
自作アプリケーションが行っているのは、
> この顧客情報を、この内容へ変更してほしい
という要求を、ベンダーが定めた形式で送ることである。
その要求を受け取ったベンダー側の業務機能が、権限や入力内容、現在の状態などを確認する。
問題がなければ、更新要求が通信・接続層を通じてデータベース側へ渡され、そこで実際の保存処理が行われる。
つまり、APIは通信・接続層を飛び越えて、データベースを直接操作するための抜け道ではない。
APIによって簡略化されるのは、業務機能へ依頼を届けるまでの操作である。その後の業務判断や保存処理は、依然としてベンダー側の仕組みを通る。
③ データベースは外部から直接操作できる領域としては閉じられている
データベースには、企業の顧客情報、契約、売上、在庫など、正式な業務データが保存されている。
そのため、外部の任意のアプリケーションが、自由に内部へ接続し、好きな方法でデータを書き換えられる状態にはできない。
もし複数のアプリケーションが、それぞれ独自の判断で同じデータを操作すれば、
• 同じデータが二重に登録される
• 一方の変更が、もう一方の変更を上書きする
• 処理の順番が前後する
• 関連するデータ同士が矛盾する
• 更新途中で処理が止まり、不完全な状態が残る
といった問題が起こり得る。
こうした混乱を防ぐため、データベース側では、
• どの要求を受け入れるか
• どの順番で処理するか
• 同時に届いた処理をどう扱うか
• 重複や矛盾をどう防ぐか
• 処理に失敗した場合にどう戻すか
といった管理が行われている。
ここで重要なのは、通信・接続層だけが、これらの問題をすべて解決しているわけではないという点である。
通信・接続層は、要求を決められた形式と経路でデータベース側へ届ける。
その要求を実際に受け入れ、保存時の順番や整合性を管理するのは、データベース側の仕組みである。
両者が役割を分担することで、データベースは外部から直接操作されない閉じた領域として維持されている。
④ 業務アプリケーションも、データベース内部で直接作業しているわけではない
データベースが外部から直接操作できないという点は、AIコーディングによって作った自作アプリケーションだけに当てはまる話ではない。
SaaSベンダー自身が作った業務アプリケーションも、データベース内部で自由に作業しているわけではない。
業務アプリケーションが担当するのは、
• どの顧客を対象とするか
• どの業務を実行するか
• どのような内容へ変更するか
• 業務上、その処理を認めてよいか
といった判断である。
一方で、
• 実際にどこへ保存するか
• 同時に届いた別の処理とどう調整するか
• 保存途中で問題が起きた場合にどう戻すか
• 内部でどのように重複や矛盾を防ぐか
といった保管上の処理は、データベース側が管理する。
業務アプリケーションは、業務上必要な更新要求を作成し、それを通信・接続層へ渡す。
データベース側は、その要求を自らの管理規則に従って処理する。
この構造がある以上、自作アプリケーションが既存の業務アプリケーションの一部を置き換えたとしても、データベース内部の管理方法まで自由に置き換えられるわけではない。
⑤ ベンダー仕様への従属
以上のことから、自作アプリケーションが既存SaaSの正式なデータを扱おうとする場合、その動作はベンダーが設計・公開した仕様に従うことになる。
自作アプリケーションが外側でどれほど高度な処理を行っても、既存SaaSの正式なデータとして保存・更新するためには、
• ベンダーが公開した機能
• ベンダーが定めた入力形式
• ベンダーが認めた権限
• ベンダーが許可した状態変更
• ベンダーが設計した通信・接続方法
• データベース側が受け入れられるデータ構造
に合わせる必要がある。
独自の機能を自作アプリケーションへ追加すること自体は可能である。
例えば、独自の分析、分類、表示方法、入力画面、操作手順などを作ることはできる。
しかし、その処理結果を既存SaaSの正式なデータとして保存したい場合には、最終的にベンダーが受け入れられる形式へ変換し、ベンダーが公開した経路から処理を依頼しなければならない。
自作アプリケーションが独自に新しい種類の情報を作ったとしても、既存SaaS側にその情報を保存する項目や業務機能が用意されていなければ、そのまま正式なデータとして書き込むことはできない。
つまり、自作アプリケーションによって自由化できるのは、ベンダーが公開した仕様の範囲内での操作方法、処理の組み合わせ、表示、補助的な業務ロジックである。
既存SaaSのデータ構造、正式な状態、保存規則そのものまで自由化されるわけではない。
以上の①から④を踏まえると、私が考える技術的な制約とは、自作アプリケーションが既存SaaSの正式なデータを扱う限り、その処理がベンダー仕様へ従属することである。
AIがどれほど高度なコードを書けるようになっても、接続先であるSaaSが受け入れられる操作とデータの範囲は、SaaSベンダーが決めている。
自作アプリケーションを作る自由と、そのアプリケーションが既存SaaSの内部で何を実行できるかという自由は、同じものではない。
セキュリティ・運用上の制約
技術的な制約では、自作アプリケーションが既存SaaSの正式なデータを扱う限り、ベンダーが設計した仕様に従うことになるという点を整理した。
では、その仕様を利用者へ公開し、自作アプリケーションから自由に実装できるようにすればよいのだろうか。
私が気になっているのは、ここにもセキュリティと運用の両面から制約が存在するように思えることである。
SaaS製品内で扱われるデータは利用者（クライアント）のものである。しかし、そのデータを管理・運用するデータベースや業務アプリケーションは、SaaSベンダーが設計・運用するシステムであり、利用者が自由に改造・実装できるものではない。
私が特に気になっている点は、次の三つである。
① 内部仕様を開放すると、攻撃対象領域も広がる
技術的な制約で述べた通信・接続層や、データベース内部の管理方法を自由に利用できるようにすれば、自作アプリケーションとデータベースを現在より直接的に接続できる可能性はある。
しかし、それらの仕組みは、単に利用者を制限するために存在しているわけではない。
どの要求を受け付けるのか、どの形式のデータを許可するのか、誰にどの権限を与えるのか、どの処理を拒否するのかといった設計は、利用者のデータを守るための安全境界でもある。
そのため、内部仕様や管理領域を自由に開放すれば、正規の利用者だけでなく、悪意のある第三者にとっても利用できる情報や経路が増える可能性がある。
もちろん、公開仕様そのものが危険というわけではない。
しかし、ベンダーが管理する内部領域へ外部のコードや独自実装を自由に受け入れることは、攻撃対象領域を広げる可能性がある。
ベンダーが守らなければならないのは、一人の利用者の利便性ではない。
そのサービスを利用するすべての利用者のデータである。
その責任を考えると、自由化だけを理由に内部領域をそのまま開放することは難しいように思える。
② SaaSは一人の利用者だけのシステムではない
個別の利用者とベンダーが契約を結び、限定的に内部仕様を公開することは技術的には可能かもしれない。
しかし、SaaSは通常、一人または一社だけが利用するシステムではない。
複数の利用者が同じ基盤を共有し、それぞれ異なる業務を同時に実行している。
そのため、一部の利用者へ特別な実装を許可した場合、その影響が当該利用者だけにとどまるとは限らない。
例えば、
* 同じデータへの同時更新
* 大量処理による性能低下
* 独自実装と共通業務ルールとの衝突
* 更新途中で異常終了した場合の整合性
* 他サービスとの連携への影響
など、製品全体へ影響する可能性も考えなければならない。
もちろん、実際のSaaSにはプラグインや拡張機能を提供している製品も存在する。
しかし、それらは利用者がベンダー内部を自由に改造しているわけではない。
ベンダーが、
* 実行できる場所
* 利用できる機能
* 与えられる権限
* 処理時間や利用量
などをあらかじめ制限した、安全な共有領域を提供しているのである。
つまり、拡張機能が存在することは、ベンダーの閉じた領域がなくなったことを意味しない。
むしろ、閉じた領域を維持したまま、安全に拡張できる範囲だけを公開していると考えた方が実態に近いように思える。
③ ベンダー仕様は変化し続ける
もう一つ気になるのは、ベンダー仕様そのものが固定されているわけではないという点である。
SaaS製品は、
* セキュリティ対策
* バグ修正
* 性能改善
* 法制度への対応
* 新機能追加
* 古い機能や通信方式の廃止
などを目的として継続的に更新されている。
その結果、
* API
* 通信方式
* 認証方法
* データ形式
* 業務ルール
などが変更されることもある。
例えば、これまで利用できた通信方式にセキュリティ上の問題が見つかれば、ベンダーはその利用を停止するかもしれない。
その通信方式へ依存していた自作アプリケーションは、その時点で修正が必要になる。
つまり、自作アプリケーションは開発時だけベンダー仕様へ従うのではない。
運用を続ける限り、ベンダーによる仕様変更の影響も受け続ける。
セキュリティ・運用上の制約とは何か
以上のことから、ベンダーが内部仕様や管理領域を自由に開放しない理由は、単なる囲い込みだけでは説明できないように思える。
ベンダーには、
* 利用者全体のデータを守ること
* サービス全体を安定して運用すること
* 障害や攻撃へ対応すること
* 必要に応じて仕様を改善・更新すること
といった責任がある。
その責任を果たすためには、利用者が自由に実装・変更できない領域を一定範囲で維持する必要がある。
そして、その領域が閉じられている以上、自作アプリケーションが正式なデータを扱うためには、ベンダーが公開した仕様を利用するしかない。
私が技術的な制約で述べた「ベンダー仕様への従属」は、このセキュリティ・運用上の制約によって生まれる構造でもあるように思える。
貸金庫会社に例えると
ここまで説明した技術的な制約と、セキュリティ・運用上の制約は、どちらも少し抽象的な話だった。
そこで、一度貸金庫会社に例えて整理してみたい。
この例えは実際のSaaSを完全に再現するものではない。しかし、私が考えている「ベンダー仕様への従属」と「閉じた領域を維持する理由」を理解するには近い構造だと思っている。
SaaSと貸金庫会社の対応
SaaSシステム 貸金庫会社の例え
SaaS利用者 依頼人
自作アプリケーション・AIエージェント 依頼人が雇った代理人
業務アプリケーション 業務課・業務担当
通信・接続層 受付・社内配送
API 定型化された作業依頼書
データベースエンジン 金庫番
DB管理・インフラ運用 設備管理部
データベース 貸金庫・金庫室
通常の業務アプリケーションを利用する場合
例えば、利用者が業務アプリケーションから顧客情報を更新するとする。
貸金庫会社で言えば、依頼人が窓口を訪れ、
「この書類を更新して保管してください。」
と依頼することに当たる。
業務課は、まず依頼内容を確認する。
* 本人に権限があるか。
* 必要な情報がそろっているか。
* 業務ルールに違反していないか。
問題がなければ、更新後の成果物を作成する。
しかし、この時点ではまだ貸金庫へ保管されたわけではない。
業務課は成果物を受付・社内配送へ渡す。
受付・社内配送は、成果物を自分で変更する部署ではなく、決められた手順で金庫番へ届ける役割を持つ。
成果物を受け取った金庫番は、
* 保存順序
* 他の処理との競合
* 重複
* 整合性
などを確認し、問題がなければ正式な記録として貸金庫へ保管する。
保管が終わると、その結果は逆の経路で業務課へ戻り、最後に依頼人へ「更新が完了しました」と通知される。
APIを利用した場合
次に、自作アプリケーションからAPIを利用して同じ更新を行う場合を考える。
この例えでは、APIは定型化された作業依頼書に当たる。
通常の窓口では、担当者へ一から依頼内容を説明しなければならない。
しかし、定型依頼書では、
* 誰からの依頼か。
* 何をしてほしいのか。
* 必要な情報は何か。
があらかじめ決められた形式で書かれている。
そのため、受付は内容を確認すると、すぐに担当部署へ回すことができる。
つまり、APIは受付までの手続きを簡略化する仕組みである。
しかし、その後の流れは通常利用と変わらない。
業務課は依頼内容を確認し、成果物を作成する。
成果物は受付・社内配送を経由して金庫番へ届けられる。
金庫番は貸金庫のルールに従って保管する。
APIを利用しても、金庫番を飛び越えて貸金庫を直接操作できるわけではない。
金庫は作業場所ではない
この例えで私が最も伝えたいのは、
貸金庫は保管場所であって、作業場所ではない
ということである。
依頼人が雇った代理人は、会社へ仕事を依頼することはできる。
しかし、
* 貸金庫の中へ自由に入ること。
* 金庫の配置を変更すること。
* 新しい保管方法を実装すること。
* 金庫内部の管理方法を書き換えること。
はできない。
それは会社が意地悪をしているからではない。
貸金庫全体を安全に運用し、利用者全員の成果物を守る責任があるからである。
業務課も金庫の中では作業しない
ここでもう一つ重要なのは、業務課ですら貸金庫の中で作業しているわけではないという点である。
業務課は、
「この成果物を保管してください。」
と依頼することはできる。
しかし、
* 空いている私書箱はどこか。
* 他の利用者と競合していないか。
* 保存順序をどうするか。
* 故障した私書箱がないか。
といったことは管理していない。
それを管理しているのは金庫番である。
つまり、ベンダー自身が作った業務アプリケーションですら、データベース内部を自由に操作しているわけではない。
設備管理部は貸金庫そのものを守る
設備管理部は、
* 貸金庫の増設
* 故障対応
* 配置変更
* 防犯設備の管理
などを担当する。
設備管理部の目的は、貸金庫全体を壊さず、安全に運用し続けることである。
そのため、たとえ社内の許可証を持っていたとしても、外部の代理人を自由に貸金庫へ入れることはできない。
設備管理部が守る対象は、一人の利用者ではなく、貸金庫全体だからである。
この例えで伝えたいこと
この例えでは、
* 業務課が業務アプリケーション
* 受付・社内配送が通信・接続層
* 金庫番がデータベースエンジン
* 設備管理部がDB管理・インフラ運用
に対応している。
依頼人は、自分の成果物を預けたり受け取ったりすることはできる。
代理人を雇って、その作業を代行させることもできる。
しかし、代理人が貸金庫の中へ入り、保管方法そのものを変更することはできない。
SaaSも同じように、自作アプリケーションによって操作や業務フローを自由化することはできる。
しかし、既存SaaSの正式なデータを扱う限り、その保存方法や内部管理はベンダーが設計した仕組みに従うことになる。
私が技術的な制約で述べた「ベンダー仕様への従属」と、セキュリティ・運用上の制約で述べた「閉じた領域を維持する必要性」は、この貸金庫会社の構造を見ると、同じ仕組みの表と裏として理解しやすいのではないかと考えている。
まとめと私の考え
本記事では、「SaaSは死ぬのか、生き残るのか」という結論を出すことを目的とはしなかった。
私が気になっていたのは、AIコーディングによる自作アプリケーションでSaaSを代替する議論の中で、実装上は避けて通れないように思える点が、あまり語られていないように感じたことである。
私なりに整理すると、その点は大きく二つに分けられる。
一つは、技術的な制約である。
自作アプリケーションが既存SaaSの正式なデータを扱う限り、通信・接続の仕組みやデータ構造、業務ルールなど、ベンダーが設計した仕様に従う必要がある。
もう一つは、セキュリティ・運用上の制約である。
SaaSベンダーは、一人の利用者ではなく、サービス全体とすべての利用者のデータを守る責任を負っている。そのため、内部の管理領域を自由に開放することは簡単ではない。
この二つを合わせて考えると、自作コーディングによって自由化できる範囲は、実質的にはベンダーが公開した仕様によって決まるように思える。
さらに、その「自由になれる範囲」は固定されたものでもない。
SaaS製品は継続的にアップデートされるため、APIや通信方式、業務ルールが変更されれば、自作アプリケーション側もそれに対応していく必要がある。
もちろん、この限られた範囲であっても、自作アプリケーションによる自動化や業務改善には大きな価値があると考える人も多いだろう。
どこまでを「十分な自由」と考えるかは、利用者や企業ごとに異なるため、一概に評価できるものではない。
少なくとも現時点での私の考えでは、「AIコーディングによってSaaSから簡単に自由になれる」という議論を考えるのであれば、今回整理したような技術的・セキュリティ・運用上の制約も、あわせて考える必要があるように思える。
そして、この記事で私が一番聞いてみたかったのは、この点である。
SaaSの死を論じている人たちは、今回整理したような制約をどのように考えているのだろうか。
私が何か重要な前提を見落としているのか。
あるいは、これらの制約を乗り越える現実的な方法がすでに存在するのか。
もしそうであれば、ぜひ教えていただきたい。
私自身、このテーマについてはまだ考察の途中であり、この記事がその議論のきっかけになれば幸いである。
