エージェントの SoR と、エージェントのデータの SoR は別物です
一方はエージェントを統治し、もう一方はエージェントが書いたものを統治する。予算も買い手も違い、代替にならない。どちらが必要か決める三つの問い。
← ブログに戻るほぼ同じ言葉のもとで、二つの異なる製品が売られています。しかも違いは微妙ではありません。一方はあなたのエージェントを統治し、もう一方はエージェントが書いたものを統治します。出てくる予算も違えば、決裁する人も違い、互いの代わりにもなりません。
自分がどちらを探しているのか、一分ほどで見分ける方法を書きます。
二つのもの
Agent System of Record（ASOR） は、人間ではない働き手のための統制レイヤーです。どのエージェントが存在し、誰の権限のもとで動き、どんな権限を持ち、いくらかかり、どう機能しているかを追跡します。最も近い類比は人事システム、ただし対象は「行動するソフトウェア」です。Workday がまさにこの名前で製品を出しており、エージェントレジストリやカタログも別の角度から同じ役割を担います。
エージェントが書いたデータのシステムオブレコード は、エージェントが生み出す業務上の事実の正式な保存先です。あるレコードが真かどうか、誰がそう言ったのかに答えます。最も近い類比は、あなたのレポートが乗っているデータベース。ただし今や書き手は速く、疲れを知らず、一定の割合で自信たっぷりに間違えます。
| ASOR | エージェントのデータのシステムオブレコード | |
|---|---|---|
| 統治対象 | エージェント自体 | エージェントが書いたレコード |
| 答える問い | 「どのエージェントが誰の権限でいくらかけて動いているか」 | 「このレコードは真か、誰が承認したか」 |
| 買う人 | 情シス、セキュリティ、運用、人事 | エージェントが触れるデータの持ち主 |
| 失敗する形 | 持ち主も監視もないエージェントが動き続ける | 誤ったレコードが業務上の事実になる |
| たとえると | 非人間の働き手のための HRIS | レポートが乗っているデータベース |
決め手になる三つの問い
1. 何もしなければ、先に壊れるのは何か。
「何体のエージェントが動いていて、誰が持ち主で、いくらかかっているか分からなくなる」なら ASOR です。「誰も検証していない数字を前提に動いてしまう」ならデータ側です。
2. いま誰が困っていると言っているか。
セキュリティ、情シス、調達、コンプライアンスが問うのはエージェントのことです。台帳、権限、コスト、停止手続き。運用担当、アナリスト、データの持ち主が問うのはレコードのことです。これはどこから来たのか、誰が承認したのか、なぜ変わったのか。
3. 課題は「棚卸し」か「真偽」か。
棚卸しの課題は網羅の話です。存在するものをすべて見えるようにする必要がある。真偽の課題は検証の話です。存在する一つひとつが正しい必要がある。網羅のために作られた道具が検証を上手にこなすことはまれで、その逆も同じです。
両者は競合ではなく補完である
この二つをライバルとして描く枠組みは間違っています。マーケティングとしては整うとしても、抗う価値があります。
ASOR は「エージェント 14 は顧客データベースへの書き込み権限を持ち、先月 300 回動き、RevOps チームに属する」と教えてくれます。しかし、エージェント 14 が書いた 4,000 行が正しいかどうかは教えてくれません。それは製品の欠落ではなく、別の対象について問われた別の問いです。
データ側のシステムオブレコードは「この顧客レコードはエージェントが提案し、名前のある人がレビューし、その後 2 回改訂された」と教えてくれます。しかし、社内で何体のエージェントが動きいくらかかっているかは教えてくれません。これも欠落ではなく、別の問いです。
規模を持ってエージェントを運用する組織は、いずれ両方を欲しがります。三体のエージェントから実際の成果を出している小さなチームに必要なのはたいてい後者だけで、その段階で前者を買うのは高価な演出です。
用語の混乱がどこから来るか
どちらの意味も同じ言葉の妥当な読み方です。だからどちらの側もこの言葉を手放しません。
「システムオブレコード」は何十年もある種類の業務データの正式な保存先を意味してきました。従業員なら Workday、商談なら Salesforce、お金なら元帳。この読み方なら「エージェントのシステムオブレコード」は自然に「エージェントが生み出すものの正式な保存先」になります。
しかし「エージェント」を作者ではなく対象として読むこともできます。人事システムが従業員のシステムオブレコードであるように、ASOR はエージェントのシステムオブレコードである。この読み方では、エージェント自体がレコードです。
どちらも正当です。だからこそ、要件定義の最初の一文でどちらを指しているか明示すべきですし、その区別を最後までしないベンダーページは、より注意深く読む価値があります。
Busabase はどちらか
後者です。Busabase は、エージェントが生み出す業務上の事実が保存され、出所が付き、正として扱われる場所です。エージェントが変更リクエストを提案し、人が差分をレビューし、マージされたものだけが出所と全履歴を伴って事実になる——その書き込み経路によって。
前者はやりません。エージェントの在籍数もライセンス費用も、ソフトウェアの人事評価も扱いません。それが課題なら Workday やエージェントレジストリ各社を見てください。違うものを売るより、そう言うほうを選びます。
我々の側の長い議論はAI エージェントのシステムオブレコードに、書き込みが権威を得る仕組みはエージェントの書き込みは、なぜ「正」になれるのかにあります。