Zixuan Zhang氏は、自律型ローンサービシングおよび回収プラットフォームであるProximittyの共同創業者兼最高技術責任者（CTO）である。
世界はSaaS（Software as a Service）からエージェントへと移行しつつあるが、それは実際には何を意味するのだろうか。SaaS製品に大規模言語モデル（LLM）を追加すれば、それはエージェントになるのだろうか。
シンプルな定義を示そう。顧客が製品を使用するために作業方法を変更しなければならない場合、それはSaaSである。製品が顧客に適応する場合、それはエージェントである。
この転換は、製品の測定方法、プラットフォームの構築方法、そして優位性の蓄積方法を変える。以下のフレームワークは、製品がどこでまだSaaSのように振る舞っているかを検証し、適応型になるために何が必要かを示す。それは、エージェントを生成し、委任し、改善する組織の頭脳に向かうものである。
SaaS-エージェント・リトマステスト
SaaSの引力は、チームが認識しているよりも強い。多くのチームは、エージェントを構築していると考えながら、実際にはSaaSを構築している。新しいクライアントが異なるワークフローを持っている場合の本能は、その要件をハードコーディングすることである。それは、次のクライアントが異なるプロセスを必要とし、ゼロから再構築することになるまでは機能する。新しいクライアントごとに、能力を複合的に高めるのではなく、複雑性が倍増する。それは、言語モデルが関与しているかどうかに関係なく、SaaSの経済性である。
この転換を測定可能にするため、私は4つの次元にわたる「SaaS-エージェント・リトマステスト」を提案する。設定可能性、適応性、オーケストレーション、学習速度である。
1. 設定可能性：新しいクライアントが異なるワークフローをもたらす場合、どれだけの変更が発生するか。我々は、オンボーディングごとの設定変更とコード変更の比率を追跡する。エージェントモデルでは、コードベースではなく、ツールとポリシー制約を再設定する。ハードコーディングされたルールはすべて、適応性に対する技術的負債である。
2. 適応性：システムが明示的な指示の範囲外の状況に遭遇した場合、失敗するか、それとも推論するか。SaaSツールはエッジケースで破綻する。ほとんどの運用領域では、エッジケースが標準である。エージェントが意思決定の痕跡（どのようなコンテキストが収集され、どのポリシーが適用され、どのような例外が認められ、その理由は何か）を蓄積するにつれて、SaaSツールが捉えない組織的知性を構築する。
3. オーケストレーション：単一のエンドツーエンドのワークフローを完了するために、人間はいくつのシステムに触れる必要があるか。各引き継ぎは、遅延、エラーリスク、コストである。システム間の引き継ぎを排除するエージェントは、真のオーケストレーションを達成している。
4. 学習速度：システムは使用とともに改善するか、それとも次のリリースまで静的なままか。我々は、例外率が週ごとに減少するかどうかを測定する。減少しない場合、学習ループは機能していない。これは複合的な優位性を生み出す次元であり、この記事の残りの部分が構築する次元である。
プラットフォームの収束とシグナル裁定
多くの企業は、ポイントソリューションのパッチワークにわたって業務を運営している。これらのサイロは技術的必然性ではなく、SaaS経済性の産物である。各ベンダーは、その垂直スライスに最適化する。オリジネーションベンダーは、回収ベンダーとデータを共有するインセンティブを持たない。
エージェントは、ツールの上に位置し、ベンダーが協力するかどうかに関係なく、システム間でオーケストレーションすることで、これを解消する。そして、ここでシグナル裁定が現れる。サイロ間に閉じ込められた、誰も捉えていない貴重な知性である。例えば、融資において、私は取引量の急増が早期延滞のシグナルであることを発見した。それがサービシングチームに届けば、支払いが滞る前にプロアクティブなアウトリーチを開始する。リスク部門に届けば、借り手が保有するすべての商品にわたって与信限度額を調整する。今日、これらのシグナルはダッシュボード間のギャップで消滅する。
その意味するところは、統合されたエージェントプラットフォームが、以前は別々の製品カテゴリーだったものを吸収するということである。基盤となるシステムが消滅するからではなく、価値がそれらを接続する知性レイヤーに移行するからである。
自己改善のフライホイール
プラットフォームの収束が重要なのは、それが可能にするものがあるからである。タスクレベルだけでなく、組織レベルでの自己改善である。
単一システム内で改善するエージェントは、すぐに天井に達する。運用ライフサイクル全体にわたって改善するエージェントは、個々のツールが生成できないフィードバックループにアクセスできる。あるステージでの意思決定が、数カ月後の別のステージでの結果にどのように影響するかを見ることができる。
これが複合的なフライホイールである。すべてのインタラクションがシグナルを生成する。すべての失敗が評価と改善を生成する。すべてのシステム間パターンが、次の検出を容易にする。変更はプロンプトとポリシーの調整であり、モデルの再トレーニングではない。リプレイを通じて検証され、段階的なロールアウトと不変の監査証跡によって管理される。このシステムと静的なポイントソリューションとのギャップは、サイクルごとに広がる。
学習速度は、改善がさらなる改善を生み出す唯一のリトマステスト次元である。ここで競争上のギャップは永続的になる。
組織の頭脳
上記のすべては、ある目的地に向かって構築される。
プラットフォームが4つの次元すべてで高いスコアを獲得する場合（設定可能、適応的、システム間でオーケストレーション、自己改善）、ボトルネックは移行する。制約はもはや「エージェントはこのワークフローを処理できるか」ではない。「新しいワークフローのためのエージェントをどれだけ速く作成できるか」である。
プラットフォームがすでに組織の手順、意思決定パターン、システムランドスケープを理解している場合の答えは、それ自体がエージェントを生成できるということである。
これが組織が構築すべきものである。組織の頭脳である。単一のモノリシックなエージェントではなく、システム間で特化したエージェントをオーケストレーションし、継続的な自己評価を通じてそれらを改善し、SOP、ワークフロー記録、内部活動パターンを通じて、実際に作業がどのように行われているかを観察することで新しいエージェントを生成する知性レイヤーである。どのタスクを委任でき、どのタスクに人間の判断が必要かを決定する。組織のプロセスを実行するだけでなく、組織の知性をエンコードする。
コンポーネントは存在する。設定可能なエージェントコア、システム間オーケストレーション、自己改善評価ループ、SOP取り込みである。アーキテクチャは、発明ではなく統合の問題である。
問うべきこと
エージェント製品を構築または評価する人にとって、リトマステストは4つの質問に集約される。
1. クライアントごとのカスタムコードが標準か。それは設定可能性の失敗である。
2. システムは人間の引き継ぎなしにツール間で動作できるか。それはオーケストレーションのギャップである。
3. 改善は四半期ごとのリリースでのみ提供されるか。それは言語モデルを備えたSaaSである。
4. 例外率は時間とともに低下するか。そうでなければ、学習ループは壊れている。
これら4つの質問は、あなたがどこにいるかを教えてくれる。組織の頭脳は、その道が導く場所である。
