エージェントのメモリ・ナレッジベース・システムオブレコードの違い

AI エージェントの下には三つのものが置かれていて、そのどれもが「エージェントが知っていること」を保存しています。メモリ、ナレッジベース、そしてシステムオブレコード。チームはどれか一つを選び、うまくいかないと気づき、「同じ種類のもっと良いもの」が必要だと結論する——本当は別の種類が必要だったのに。

三つを分ける問いは一つだけです。

この情報が間違っていたとき、誰が気づき、誰が責任を負うのか。

三つそれぞれについて答えれば、境界はすぐに見えます。

メモリ：誰も気づかない

エージェントのメモリは、次の実行をより良くするために存在します。過去セッションの要約、抽出された好み、検索されたチャンク、ドキュメントのベクトルインデックス。最適化されているのは一点だけ、想起です。必要な瞬間に関連するものを浮かび上がらせること。

その設計のどこにも、真偽についての意見はありません。最近傍一致が返すのはクエリに最も似た一節であって、最も正しそうな一節ではありません。セッション要約が圧縮するのは「何が言われたか」であり、間違って言われたことも含みます。誤った事実が一度メモリに入ると、失敗の仕方は静かです。何度も想起され、一貫して聞こえ続け、言い直されるたびにもっともらしくなっていきます。

メモリが正しい道具なのは、「速くだいたい正しい」が「遅く厳密に正しい」に勝つときです。この顧客は電話よりメールを好む、このコードベースは pnpm を使う、先月の施策は振るわなかった。そして危険になるのは、下流の誰かがそれを事実として扱った瞬間です。

責任者：いない。 欠陥ではありません。メモリが安い理由そのものです。

ナレッジベース：作者が気づく。ただし遅れて

ナレッジベースは人が読むために書かれます。ドキュメント、wiki、ランブック、社内規程。作者がいて、作者がいること自体が一種の責任です。ページに名前が載っています。

しかしその責任は前払いです。書いた瞬間に効き、あとは減衰します。wiki には再確認を強制する仕組みがありません。ナレッジベースの典型的な失敗は「書いた時点で間違っていた」ではなく、真でなくなってから十八か月そのままページに残り、しかも昨日更新されたページとまったく同じくらい権威ありげに見える、というものです。

エージェントはこれを具体的な形で悪化させます。読み方に迷いがないのです。人はランブックを流し読みして「最終更新 2024」の行に気づき、一瞬ためらいます。エージェントは内容を受け取り、実行します。

責任者：元の作者。ただし書いた時点のみ。

システムオブレコード：責任者がいて、証拠も出せる

システムオブレコードは、情報源が食い違ったときに正とされる側です。その権威はラベルを貼れば手に入るものではなく、三つの性質によって生み出される必要があります。そして三つとも、保存方式ではなく書き込みの性質です。

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

このリストにないものに注目してください。データベースの話が一言も出てきません。システムオブレコードは Postgres の上にも、表計算の上にも、書類キャビネットの上にも作れます。できないのは、データストアに API を付けただけでそれが手に入ると考えることです。

責任者：名前のある人間。恒久的に。しかも差分という証拠つきで。

並べて見る

	メモリ	ナレッジベース	システムオブレコード
誰のために書くか	エージェント	人	両方＋下流システム
最適化の対象	想起	読みやすさ	正しさと追跡可能性
責任を負うのは	誰も	作者、書いた時点のみ	名前のあるレビュー担当、恒久的に
典型的な失敗	誤った事実が静かに流通する	内容がその場で古びる	レビュー待ちが注意力を追い越す
間違いのコスト	低い——誰かが事実として読むまでは	中	高い。だからゲートがある

名指しする価値のある間違い

高くつく間違いは、三つのうちどれを選ぶかを誤ることではありません。境界が漏れること——具体的には、メモリにあったものが、間に何も起きないまま事実になってしまうことです。

こういう形をしています。エージェントが見込み客を調査する。見つけたものの一部は裏が取れていて、一部は肩書きとプレスリリースからの推測です。すべてがコンテキストウィンドウに入り、そこでその区別は消えます——コンテキストウィンドウに確信度の列はありません。そしてエージェントが CRM レコードを書く。誰も却下しなかったので、それは今や業務上の事実であり、翌四半期には誰かがそれを前提に予測を立てます。

どの一歩も単体では不合理ではありません。失敗は構造的です。「エージェントがそう信じている」から「会社がそう主張する」への移行に、何かが起きなければならない瞬間が存在しなかったのです。

システムオブレコードが課金しているのは、まさにその一点です。それがコストのすべてであり、価値のすべてです。

三層は実際どう噛み合うか

これらは代替案ではなく、層です。

メモリは実行と実行のあいだで作業文脈を運ぶ。安く、使い捨てで、出典として引用されることはない。
ナレッジベースは人が読みエージェントが参照する長文の資料を持つ。実際の数字を持つレコードへリンクするべきで、数字を書き写すべきではない。
システムオブレコードは他のものが依存する事実を持つ。レポート、請求、予測、あるいは別のエージェントが読むものはここに属し、レビューを通った書き込みでのみ入る。

どの層か迷ったときの実務的な判定：これが三か月間まちがっていたら、いくらかかるか。 何もかからない——メモリ。誰かが少し誤解する——ナレッジベース。判断か、顧客か、数字がまちがう——システムオブレコード、手前にレビューゲート付きで。

Busabase の位置

Busabase は三層目です。Busabase ワークスペースに接続したエージェントはあなたのデータを直接書き換えません。変更リクエストを開き、人が差分を見て、マージされたものだけが事実になります。出所と、却下された版を含む全履歴を伴って。

メモリ層ではありませんし、目指してもいません。ベクトルストアはそのまま使ってください。エージェントは両方から読むべきです。この記事が守りたい区別は一行で言えます。読むのは広く、書くのは狭く。

権威性が何によって生まれるのかの長い議論はAI エージェントのシステムオブレコードにあります。レビュー付きの書き込みを実際に見たいなら、エージェントを接続して何か提案させてみてください。