Agentforce、Copilot Studio の先へ:なぜ一部の企業はオープンでセルフホストのランタイムを選ぶのか
Agentforce や Copilot Studio は自社エコシステム内で強い。だがデータ、権限、モデル選択が複数システムにまたがる企業では、オープンでセルフホスト可能なランタイムも比較軸になる。
結論から言うと： 閉じたスイートは自社のエコシステムの中では勝つ――あなたの世界がまるごと一社の壁の中にあるなら、だ。だがデータが複数のシステムに散らばり、それは自分のものであり続けねばならず、しかもモデルを選びたいのなら、答えはオープンでセルフホストのランタイム（あるいは両方を使うこと）だ。
ある会社が AI agent の製品選定をした。候補リストはごく自然なものだ。Agentforce、Copilot Studio、ServiceNow AI Agents。三社とも強く、推す人もいる。
彼らはあと一歩で Agentforce にサインするところだった――CRM のシナリオのデモが最も美しかったからだ。サインの寸前、あるアーキテクトが一つの問いを出した。「我々が agent に処理させたい顧客の問題は、半分は Salesforce の中の商談を照会する必要があり、半分は自前のシステムの中の納品や作業指示を照会する必要がある。Agentforce はどうやって壁の外側のその半分を取りにいくのか?」
営業の答えは「統合はできます」だった。そこで彼らは六週間かけて統合 PoC を作った。結論ははっきりしていた。つなぐことはできるが、壁の外のシステムを一つ足すごとに、同期を一式書き直し、定義を一度すり合わせ、いつか切れるパイプラインを一本保守しなければならない――そして彼らの壁の外のシステムは七つ八つあった。その瞬間、チームはようやく気づいた。問題は Agentforce が良くないことではなく、それが他の二社と同じく、この会社には成り立たない一つの前提を仮定していたことだ。
六週間と一つの PoC のコストで、本当は最初から考え切れたはずの教訓を一つ買った。
口に出されなかったその前提:あなたの世界はすべて一社の壁の中にある
これらのスイートの強さは、本質的に「エコシステム内で最適」だ。Agentforce はあなたの顧客、フロー、オブジェクトがすでに Salesforce の中にあると仮定する。Copilot Studio はあなたの協働、ドキュメント、ID が 365 の中にあると仮定する。ServiceNow はあなたのフローがその上にあると仮定する。前提が成り立つとき、それらは確かに手間が省ける――データが出来合い、権限が出来合い、統合が出来合いで、agent はほとんど手なりでつながる。
だがこの前提は、大多数の企業には成り立たない。本物の企業はこうだ。CRM は一社、ERP は別の一社、作業指示は三社目、加えて自前のシステムとスプレッドシートの山。彼らはモデルの選択権を残したい、モデルが一年ごとに変わるからだ。彼らは規制の制約を受け、データを勝手に域外に出せない。こうした企業にとって、「エコシステム内で最適」はかえって制約になる――あなたの世界がそもそもどの一社の壁の中にもないからだ。壁の外のシステムを一つつなぐごとにパイプラインを一本書き直す、まさにあの会社が PoC でぶつかった壁だ。
並べて比べる:どちらが良いかではなく、それぞれ誰に向くか
| 観点 | 閉じたスイート(Agentforce / Copilot / ServiceNow) | オープンでセルフホストのランタイム(ObjectStack / ObjectOS) |
|---|---|---|
| 最も向くのは | 業務がすでにそのエコシステム内に重度に集中している | データが多システムに散り、スタックをまたぎ、自分で持ちたい |
| データの位置 | ベンダーのクラウド | あなた自身のインフラ |
| モデル選択 | 自社製または拘束されたモデルに偏る | 自由に替えられる、モデルは外、ランタイムは内 |
| 業務定義の帰属 | プラットフォームの中に生える | あなたのリポジトリの中のオープンプロトコルのメタデータ(Apache 2.0) |
| 課金 | アクション / 席ごと | ランタイムとインフラに連れて、使用量とデカップリング |
| 出発の姿勢 | まず業務をエコシステムに移す | 既存システムを拡張し、先に移行することを要求しない |
この表に「全部正しい」列はない。
まず二杯の冷や水を:多くの場合、あなたはスイートを選ぶべきだ
先に言っておく。この記事が一方的な売り込みにならないように。オープンでセルフホストは、より高尚な選択ではない。それは特定の状況のために用意された選択だ――そして多くの会社の状況は、まさにスイートに向いている。
第一に、もしあなたの世界が本当にほぼ一社の壁の中にあるなら。 あなたの業務の 90% が Salesforce の中にあり、データの域外流出も気にせず、モデルを替えるつもりもない――なら Agentforce がおそらく最適解だ。「ロックインされない」という、まだ起きていないリスクのために、目の前の実在する移行と運用の負担を背負うのは、割に合わない。
第二に、もしあなたにプラットフォームチームがいないなら。 これは典型的な「自作 vs 購入」だ。オープンでセルフホストは、あなた自身がそれを運用しなければならないことを意味する――パッチを当て、可用性を保証し、アップグレードを管理する。スイートのあの「箱から出してすぐ使え、事が起きれば電話に出る相手がいて、SLA が裏付ける」マネージドな体験は、専任のプラットフォームチームのいない会社にとって、しばしば「完全な制御権」よりも価値があり、手間がかからない。制御権には運用コストがあり、誰も受け止められない制御権は負担だ。
だが「スイートを買う」ことで省ける作業は、あなたが思うほど多くない
ただし「購入」の側には、よく計算から漏れる一筆がある。統合税 だ。
スイートの見積書に書かれているのは席またはアクションの金額で、書かれていないのは――あなたのあの七つ八つの壁の外のシステム、その一つひとつに統合パイプラインが一本必要だ。作るときには定義をすり合わせ、作ったあとは両側のアップグレードに連れて継続的に保守し、どちらかがフィールドを変えれば、パイプラインは黙って切れるかもしれない。冒頭のあの会社の六週間の PoC が測り取ったのは、まさにこの税の頭金だ。だから「スイートを買う + 壊れやすい統合の山」は、表面は buy だが、骨の髄ではまだ build をしている――しかも build しているのは、最も価値がなく、最も壊れやすい部分だ。
この統合税を TCO に算入すれば、「購入のほうが手間がかからない」という結論は、あなたの壁の外のシステムがごく少ないか、あるいはそれらがそもそも agent に触れられる必要がないときにだけ安定する。システムが散らばるほど、この税は重くなり、スイートの「手間が省ける」優位は、かじり取られていく。
実は、両方使ってもいい:ハイブリッドは日和見ではない
ここから、製品選定の議論で長らく見過ごされてきた選択肢が導かれる。これは必ずしも単一選択の問題ではない。
最も実務的なアーキテクチャは、しばしばハイブリッドだ。あなたが確かに重度に使っているそのエコシステムの中では、引き続きそのスイートを使う――Salesforce の中の営業 agent は、Agentforce に最も得意なことをやらせればいい。だが システムをまたぎ、定義を統一し、データを自分で持ちたい その層では、オープンでセルフホストのランタイムを使って接続組織を作る。後者はスイートを置き換えるのではなく、スイートが構造上うまくやれないことをやる――複数の壁に散らばった業務を、あなた自身が保有する、権限と監査を備えた統一された定義に収める。
言い換えれば、オープンランタイムは、あなたの複数のシステム(それらのスイートを含む)の上の 接続組織 になりうるのであって、あなたに引っ越しを迫る、また一つの壁ではない。これを認めれば、製品選定は「どの一社に賭けるか」から「どの部分はスイートを使い、どの部分はオープンを使うか」へと変わる――これこそ、大多数の本物の企業が最後に落ち着く姿だ。
オープンでセルフホストは、いったい何をもたらすのか
もしあなたが右の列に属する、あるいはやろうとしているのがまさにあのシステムをまたぐ接続層なら、「オープン + セルフホスト」がもたらすのは情緒ではなく、具体的な能力だ。最も問題を物語るのは、それが既存システムに対して取る姿勢だ――それはまさに、冒頭のあの会社が行き詰まったところでもある。
スイートはあなたの世界がその壁の中に引っ越してくることを望む。オープンランタイムはあなたの世界がもともと散らばっていることを前提とし、その仕事は既存システムをネイティブに AI 対応させることであって、先に移行させることではない。あの会社の顧客データは半分が Salesforce、半分が自前システムにあった。ObjectOS の上では、両側をそれぞれデータソースとして接続し、各々をオブジェクトとしてモデル化したうえで、共通のキー(法人番号)によって、権限と監査を備えた一つの「顧客」へと揃えられる。
export const Customer = ObjectSchema.create({
name: 'crm_customer',
label: '顧客',
fields: {
name: Field.text({ label: '顧客名', required: true }),
tax_id: Field.text({ label: '法人番号' }), // システムをまたいで「同一の顧客」を揃えるための共通キー
},
});違いは一回の質問にまで具体化できる。「この顧客は、リソースを投じて守る価値があるか?」――
- 以前:agent は Salesforce に接続し、商談が活発なのを見て「価値あり」と答える。自前システムの中でこの顧客の納品がずっと遅延し、作業指示が滞留していることを、まったく知らない。
- 以後:agent が向き合うのは 一つの 統一された顧客で、商談、納品、作業指示を一緒に見て、「商談は良いが、納品リスクが高い。まず履行を解決してから拡販を話そう」と答える。
同じモデル、同じ問いなのに、足元の「顧客」がもはや壁で切り分けられていないというだけで、結論は一面的なものから全体的なものへと変わった。そしてこのすべてが、壁の外のシステムごとに同期パイプラインを書き直す必要がない――業務定義はあなたのリポジトリの中で diff が取れ、移行できるメタデータだ。ランタイムはあなた自身のインフラ上で動き、権限を強制し、監査を記録する。モデルは外部のどの一社から来てもいい。あなたは「自分の業務の定義」を、どの一社にも預けて保管させていない。
一つの正直な選択問題
だからこれは「誰が淘汰されるべきか」ではなく、「どの部分を誰に任せるか」だ。自分に三つの問いを問おう。
- 私の業務は、ほぼある一社のエコシステムの中にあるのか、それとも複数のシステムに散らばっているのか?
- データが継続的にベンダーのクラウドへ流れることを受け入れられるか? コンプライアンス上、サインできるか?
- 私には、セルフホストのランタイムを一式運用する チームがいるか?
最初の二つの答えが「散らばっている、できない」寄りで、三つ目が「いる」寄りなら――あなたが探すべきは、もともと、また一つのより強い閉じたスイートではない。少なくともあのシステムをまたぐ層では、そうではない。もし三つの答えがすべて反対側に寄っているなら、堂々とスイートを使えばいい。それらは確かに使いやすい。正直に自分の状況を当てはめ、さらには堂々と混ぜて使うことが、どの一社の機能更新を追いかけるよりずっと重要だ――そして六週間かけて PoC を作ってようやく分かるよりも、ずっと安く済む。
結び
閉じたスイートが勝つのは「エコシステム内で最適」であり、この優位はその前提が成り立つときには非常に本物で、否定すべきではない。オープンでセルフホストのランタイムが勝つのは「前提が成り立たないときにも成り立つ」ことだ――あなたの世界が散らばっていて、データを自分で持ちたく、モデルを自由にしたく、定義を自分の手に握りたく、そしてあなたがそれを自分で運用するその責任を担えるとき。
どの部分にスイートを使い、どの部分にオープンを使い、そのために各々どんな代償を払うのかを知ること――それが、どの一社の機能リストよりも重要だ。冒頭のあの会社が早めにあの三つの問いを問うていたら、六週間と一つの PoC を節約できたはずだ。
npm i -g @objectstack/cli && os start移行も、どこかの壁に入ることもなしに、五分で自分の環境の中に二つのシステムをまたぐ統一されたオブジェクトを動かしてみて、それからこの道があなたの求めるものにより近いかどうかを判断しよう。