データベースの一行に「権威がある」と言うのは、考えてみると奇妙な表現です。その行は何も知りません。実際に言いたいのは、人がそれを自分で導き直さずに行動の前提にできるということで、その「できる」はどこかから来なければなりません。
来るのは、そのレコードが入ってくる途中で起きたことからです。四つのものが書き込みを生き延びる必要があり、たいていのシステムでは少なくとも一つが静かに失われています。
1. 出所の連鎖は「誰が」で切れる
典型的なシステムに「このレコードはどこから来たのか」と尋ねると、created_by: api_key_7、created_at: 2026-08-14T09:12:00Z が返ってきます。これが特定しているのは資格情報であって、原因ではありません。
本当に必要な連鎖は三つの環からなり、通常は最初の一つしか記録されません。
- 資格情報——どのキーが書いたか。これはどのシステムにもあります。
- 行為者——どのエージェントが、誰の代わりに、どの実行で。多くのシステムはこれを資格情報に潰してしまい、キーを共有するエージェントは区別できなくなります。
- 経緯——それを生み出したとき、エージェントは何を頼まれていたのか。半年後、「CRM には 4,000 万と書いてある」は使えません。「エージェントが取引先を要約する際、第 3 四半期の更新スレッドから 4,000 万を抽出した」なら、確かめに行けます。
三つ目の環こそ、レコードを「ログされただけ」から「監査できる」に変えるものであり、そしてほぼ誰も保存しない環です。書く時点では冗長に感じるからです。自分はその場にいたし、覚えている。出所は、その場にいなかった方の自分のために書くものです。
2. 差分は「表示できる」ではなく「判断できる」必要がある
何が変わったかを見せられるシステムはいくらでもあります。人が実際に持っている時間の中で判断まで到達できるものは、ずっと少ない。
計算は容赦がありません。1 件変更：レビュー担当が差分を読み、考え、決める——30 秒ほど。1 つの提案で 40 件、それぞれ 3 フィールド：同じ担当が本当に注げる注意は同じく 30 秒程度です。後ろに並んでいる仕事は一つも減っていないからです。
次に起きることは予測可能で、しかも規律の問題ではありません。レビューは止まらず、浅くなります。承認は出続け、ただ意味を持たなくなる。空押しのハンコはゲートが無いよりも悪い。「誰かが見た」という証拠を製造してしまうからです。
だから「判断できる」は歯を持った設計要件です。
- 行ではなく決定でまとめる——同じ変わり方をした 38 件は一つの決定であり、加えて読む価値のある例外が 2 件。
- 例外を浮かび上がらせる——外れ値、二度変わったフィールド、自分の出典と矛盾するレコード。
- 却下を承認と同じくらい安くする——却下に理由の記述とエージェントの再実行が必要なら、担当はその摩擦を避けるために際どい変更を通します。
レビューゲートの価値は、その背後にある注意の量とちょうど同じです。プロセスが前提とする注意ではなく、実際に得られる注意に合わせて設計してください。
3. 出所はマージを生き延びなければならない
多くの実装がここで失敗します。レビュー中は文脈が豊かです。提案が見え、差分が見え、エージェントの理由づけも見える。そしてマージされ、テーブルに残るのは値だけになります。文脈は別テーブルの監査ログに移り、タイムスタンプとレコード ID で結合されることになります。
技術的には何も失われていません。実務的には失われています。半年後、その結合を実行する人はいないからです。人が見るのはレコードで、レコードには 40,000,000 とだけ書かれていて、かつて別の値だった記憶はどこにもありません。
判定は単純です。レコードだけを見て、どこから来て誰が承認したか分かるか。 監査ログの存在を知っていて、その引き方も知っている必要があるなら、出所は「持っている機能」であって「レコードが備えた性質」ではありません。
4. 却下された変更は証拠である——残すこと
受け入れなかったものは捨てる、というのが直感です。その直感は間違いです。
却下された提案は、何を真にしないと決めたかの唯一の記録です。どのエージェントが「もっともらしいが誤った」出力を出すか、どのプロンプトがずれていくか、どの上流ソースが信頼できないかを教えてくれます。消せば、却下は誰かの頭の中で一度だけ起きた私的な出来事になります。
もう一つ、目立たないがより重要な理由があります。却下を残すことは、システムオブレコードが自分自身について正直であるための方法です。 受け入れた歴史しか覚えていない保存先は、「自分はずっと正しかった」という物語を語っています。却下された版こそ、判断が実際に働いたことを示す部分です。
権限と監査ログでは埋まらない理由
どちらも答えとして提示されますが、どちらも答えではありません。
権限が決めるのは誰が書いてよいかです。それは能力の周りに引かれた境界で、しかも何が書かれるか誰も知らないうちに引かれています。顧客テーブルへの書き込み権限を持つエージェントは、顧客テーブルに何でも書けます。形式は正しく事実は誤っているものも含めて——そしてそれこそが問題の本体です。エージェントが生み出すのはまさにそれだからです。
監査ログが記録するのは書き込みが起きたことです。定義上、事後に書かれます。監査ログとは、火曜に何が壊れたかを木曜に知る方法です。有用ではありますが、統制ではありません。誰かに「ノー」と言う機会を、一度も差し出していないからです。
両者が残す空白は同じです。エージェントの書き込みとレコードが真になることのあいだに、人が止められたはずの瞬間。その瞬間は権限でもログでもありません。状態です——「提案されたが、まだ真ではない」——データモデルがそれを表現できる必要があります。存在するがまだ成立していない変更を保持する術がスキーマに無いなら、どれだけプロセスを積んでもシステムオブレコードにはなりません。
実務ではどうなるか
すべての書き込みがこれに値するわけではありません。全部に適用することこそ、誰も読まない承認キューができあがる原因です。
習慣ではなく、結果の重さで線を引いてください。
- ゲート無し——下書き、作業メモ、検索キャッシュ、次の実行でエージェントが上書きするもの。
- ゲート有り——下流システムが読むもの、人が引用するもの、顧客名や規制の名前が近くにあるもの。
そのうえで、ゲート付きの量を人が本当に注意を向けられる範囲に収めます。キューが減るより速く増えているなら、答えは「もっと速いレビュー担当」ではありません。ゲートの後ろのものを減らす、まとめ方を良くする、あるいはエージェントの依頼範囲を狭める、です。
Busabase での実装
Busabase ワークスペースに接続したエージェントは書き込む代わりに変更リクエストを開きます。意図した変更一式を保持し、正式データの外側にとどまる提案です。人が差分を読み、マージするかしないかを決めます。マージされたレコードは出所——どのエージェント、どの依頼、どのレビュー担当——をレコード自体に伴って保持し、却下された版を含む履歴が恒久的に残ります。
ある書き込みが実際に人を待つかどうかは、エージェントの善意ではなく資格情報の権限レベルが決めます。これは意図的です。毎回の呼び出しで維持しなければならない慣習より、指させる強制境界のほうが強い。
なぜこれらが保存先に権威を与えるのか、その長い議論はAI エージェントのシステムオブレコードにあります。読むより仕組みを見たいなら、エージェントを接続して、却下できる何かを提案させてみてください。