AI エージェントのシステムオブレコード（記録システム）とは

システムオブレコードとは、業務上の「事実」が正式に置かれる唯一の場所です。以降の判断もレポートも、次のエージェントの実行も、チャットログではなくそこを参照します。AI エージェントの文脈でその名に値するかどうかは、一点で決まります。すべての書き込みについて、誰が提案し、誰が承認し、何が変わったのかを追えるかどうかです。

多くのツールの説明は、その手前で止まります。このページで扱うのは三つです。この言葉には二つの意味があり、あなたが必要としているのはおそらく後者であること。権威性は何によって生まれるのか。そして、Busabase が答えにならないのはどんな場合か。

まず区別する：「エージェントの記録システム」には二種類ある

2026 年、この言葉は両立しない二つの用途で使われています。方向を間違えると、検討そのものが無駄になります。

	エージェント自体を管理する（ASOR）	エージェントが書いたデータを管理する
管理対象	エージェントの ID・権限・コスト・パフォーマンス	エージェントが生み出した業務レコード
たとえるなら	「人間ではない働き手」のための人事システム	人とエージェントが共に読み書きする正式なデータベース
答える問い	「どのエージェントが、誰の権限で、いくらかけて動いているか」	「このレコードは正しいか。誰がそう言ったのか」
検討先	Workday が同名の製品を提供。エージェントレジストリ／カタログも同じ役割	Airtable、Notion、自前の Postgres——そして Busabase

前者が目的なら、ここから先は読む必要がありません。「社内で動いている全エージェントの一覧が欲しい」という課題は、エージェントレジストリや統制レイヤーの領域です。Busabase はそれをしません。エージェントの「在籍管理」は対象外です。

以降は後者の話です。エージェントはすでに実務の成果——表、ドキュメント、リサーチ、下書き、データセット——を出している。それを事業が依拠できる事実に変える場所が要る、という話です。

なぜエージェントがこれを「急ぎの問題」にしたのか

システムオブレコードという考え方自体は新しくありません。変わったのは書き込みの速度です。

人間のチームが共有データベースに書き込む速度は、人間の速度です。そして書き込みを遅くしている摩擦は、そのまま誤りを止める仕組みでもありました。誰かが気づき、誰かが確認し、広がる前に直る。エージェントはこの摩擦を丸ごと取り払います。1 分で 200 件を提案でき、そのどれもがもっともらしく、書式も整い、内部的にも矛盾がない。そして「もっともらしい誤ったレコード」は、明らかに壊れたレコードよりはるかに危険です。二度見する理由がどこにもないからです。

したがって本当の論点は「エージェントにデータベースが必要だ」ではありません。データベースはすでにあります。論点はこうです。エージェントの書き込み速度では、保存は簡単な方の半分にすぎず、検証こそが破綻する。

権威性はどこから来るか——保存先ではなく、書き込み経路

システムオブレコードは何のためにあるのか。答えはいつも同じ形をしています。情報源が食い違ったとき、こちらを正とする。その「正とする」根拠が要ります。根拠になるのは次の三つで、いずれも保存方式ではなく書き込み経路の性質です。

出所がわかる——各レコードが自分の出どころを示せる。「API キー 7 が作成」ではなく、どのエージェントが、どの依頼を受けて、どの元資料に基づいたのか。
責任者がいる——今この形で存在していることに責任を持つ人がいる。自分で書いたか、承認したかのどちらかです。
再構成できる——現在の状態に至る過程を再生できる。通過した版も、却下された変更も含めて。

API 付きのデータベースは、既定ではこのどれも与えてくれません。与えるのは 1 行のデータとタイムスタンプだけです。上の三つは、書き込みが着地する前の経路に組み込むしかありません。

ここが「AI ネイティブなデータベース」という語りに欠けている部分です。構造化データはエージェントの出力を良くする——これは事実で、言う価値もあります。しかしそれはエージェントが読む側の話です。エージェントが書くときに何が起きるのかは、たいてい権限と監査ログで片づけられます。監査ログは「起きたこと」を残すだけで、人が止める機会を作ったことは一度もありません。

エージェントが書き込めるからといって、その保存先がシステムオブレコードになるわけではない。それを成立させるのは、書き込みと確定のあいだに起きることです。

候補を測る五つの問い

Airtable、Notion、ベクトルストア、自前の Postgres、そして Busabase——どれにでもそのまま当てられるように書いています。通るものもあれば、こちらが手間を求めるものもあります。

書き込みは「待てる」か。エージェントが変更を提出し、それが保存され、レビューでき、しかしまだ正式ではない——そして正式にならないまま終わる選択肢もある。そうなっていますか。すべての書き込みが即座に正式データになるなら、それは API 付きのデータベースであり、唯一の防御はプロンプトの自制です。
差分は人が読めるか。40 件が変更されたとき、レビュー担当は数分で「何が変わったか」を把握し、判断まで到達できますか。誰も完了できないレビューは、必ず素通しになります。
マージ後も出所は残るか。変更が受理された後も、レコードは出どころと承認者を保持していますか。それとも別の監査ログにあり、手作業で突き合わせる必要がありますか。
人と機械の両方が使えるか。人にしか読めない保存先はエージェントにスクレイピングを強い、機械にしか読めない保存先は人をループの外に追い出します。エージェントが扱える程度に構造化され、人が判断できる程度に読めること。
出ていけるか。データ・履歴・添付を、他所でも使える形で書き出せますか。持ち出せない記録システムは、借りている記録システムです。

分岐点は 1 番目です。この議論に出てくる多くのツールはここを通りません。出来が悪いからではなく、書き手が人間だった時代に設計されたからです。人が共有データベースに何かを書くとき、判断はすでに済んでいます。

Busabase の位置づけ

Busabase は 1 番目の問いを中心に作られています。Busabase ワークスペースに接続したエージェントは、あなたのデータを直接書き換えません。変更リクエスト（Change Request）を開きます。意図した変更一式を保持し、正式データの外側にとどまり、待つ提案です。

人が差分を見て、マージするかしないかを決めます。マージされたものは出所を伴って入ります——どのエージェントが、どの依頼で、どのレビュー担当が承認したか。その履歴は却下された版も含めてレコードに残り続けます。

この仕組みの周りにワークスペースが揃っています。業務上の事実は、1 行のデータだけで完結することがまれだからです。

ベース：実用的なフィールド型・ビュー・リレーションを持つ構造化レコード
ドキュメント：レコードが依拠する長文の資料
ドライブ：主張の根拠になった元ファイル
スキルとアプリ：エージェントが一度組み立てた手順を、次回は再発見せずに再利用する

接続は MCP、エージェントスキル、OpenAPI のいずれかです。Claude Code、Codex、Cursor、Gemini CLI などの個別設定はエージェントを接続するを参照してください。動かし方は二通り。Busabase デスクトップはローカルファーストで、データは自分のディスクに置かれます。Busabase Cloud はチームで共有するワークスペース向けです。コードはオープンソースです。この種の主張においてそれは通常以上に重要で、自分で確かめられない監査証跡は、仕組みではなく約束にすぎません。

Busabase が適さない場合

ここを明示するのは謙遜ではなく、検討時間の節約のためです。

必要なのがエージェントレジストリであってデータ基盤ではない場合。前述の ASOR 領域です。Workday やエージェントカタログ各社を見てください。
書き込みが高頻度の機械データの場合。イベント、ログ、メトリクス、センサーデータ。1 日 100 万行をレビューする人はいませんし、いるべきでもありません。その形状には専用のデータベースを使い、レビュー付きの層は人が実際に判断に使う事実のために取っておいてください。
トランザクション型のアプリケーションバックエンドを作っている場合。自社プロダクトの決済経路が書き込むなら、必要なのは通常のアプリケーションデータベースです。ユーザーの取引の途中に承認を挟むのは、機能ではなく不具合です。
必要なのが意味的な検索だけの場合。「この問いに近い一節を探す」ならベクトルストアの仕事です。検索には向きますが、権威性については何も言いません。最近傍一致は、その一節が正しいかどうかについて意見を持ちません。
誰もレビューしない場合。これが本質です。この仕組みの価値は、背後にある注意の量とちょうど同じです。誰も差分を見ないのであれば、承認キューは未検証のデータに遅延を足すだけです。このカテゴリの製品を選ぶ前に、まずここに正直に答えてください。

よくある質問

AI エージェントのシステムオブレコードは、結局データベースでは？

データベースは保存の半分です。システムオブレコードは、保存に加えて、保存された値を正式なものにする規則——出所、責任を持つ人、再構成できる履歴——を備えたものです。どんなデータベースの上にも構築できますが、多くのチームは構築しません。だからエージェントの出力が信用されないまま残るのです。

エージェントのメモリとどう違いますか。

メモリはエージェントのためのものです。次の実行をより良くするために存在し、想起のために最適化されています。システムオブレコードは事業のためのものです。人がそれを根拠にできるために存在し、正しさと追跡可能性のために最適化されています。エージェントがそこから読むのは当然ですが、コンテキストウィンドウに入ったというだけで真になるものがあってはいけません。

すべての書き込みに承認が必要ですか。

いいえ。すべてに要求するのは悪い設計です。問うべきは、どのレコードに結果が伴うかです。下書き、作業メモ、検索キャッシュにゲートは不要です。顧客情報、財務数値、公開コンテンツ、下流システムが読むものには必要です。習慣ではなく、結果の重さで線を引いてください。

複数のエージェントで一つのシステムオブレコードを共有できますか。

それがほぼ核心です。レコードが構造化されレビューを通っていれば、二番目のエージェントは一番目が止めたところから続けられます。文脈を導き直す必要もなく、前のエージェントの未検証の推測を引き継ぐこともありません。未検証のものは正式データになっていないからです。

却下された変更はどうなりますか。

Busabase では削除せず保持します。却下された提案は、そのエージェント・そのプロンプト・そのデータについての証拠です。消すことは、「何を受け入れないと決めたか」の唯一の記録を消すことになります。

次の一歩

判断する最短の方法は、実際に変更を一つ通してみることです。ワークスペースにエージェントを接続し、何かを提案させ、その差分を見てください。エージェントを接続するか、まずデータを自分の環境に置きたい場合はBusabase デスクトップをローカルで動かすところから始められます。