※ 本記事は、Casius Leeによる”Building the enterprise brain: what changes when agent memory belongs to a company“を翻訳したものです。

2026年11月8日

連休を使って「第二の脳」を作ったとします。Obsidianの保管庫に数百件のノートがあり、その上で動くAIエージェントが、ようやく自分の知識を理解してくれるようになりました。そこに、チームからアクセスしたいと言われます。

そのまま渡せるでしょうか。

先月アムステルダムで開かれたAgentConのブースでは、多くの会話の根底に、この問いがありました。政府、教育機関、さらには宇宙機関の開発者まで、個人では巧みな仕組みを作れると話していました。難しいのは、それを組織内で信頼して使えるようにすることでした。

個人の「第二の脳」を、そのまま共有できない理由

そのセキュリティモデルを担っているのは、自分自身だからです。中身はすべて自分が書き、エージェントが読むものは自分にも閲覧権限があり、間違えたらノートを直せば済みます。共有すると、この3つの前提が一度に崩れます。コンテキストウィンドウを大きくしても解決しません。変えなければならないのは、誰が判断するかです。

病院での情報の扱い方を考えてください。自分のノートは「第二の脳」です。読むのは自分だけです。病棟のホワイトボードは「チームの脳」です。当直中の全員が書けて便利ですが、「ペニシリンアレルギー」と誰が書いたのかを問われると、問題になります。診療録は「企業の脳」に相当します。それを成り立たせるのは、規模ではなくガバナンスです。すべての記載に署名があり、見られる内容は役割で決まり、すべての変更を監査できます。問題が起きたとき最初に問われるのは、医師が判断した時点で、診療録に何が書かれていたかです。

ただし、このたとえには重要な違いが1つあります。診療録は、人が意図して書きます。一方、エージェントのメモリの多くは、プロンプトに従って動く抽出器が書くので、誰も読む前から間違っている可能性があります。共有メモリには、読む人の制御だけでなく、何を書き込むかの制御も必要です。

「チームの脳」になると、何が変わるか

一緒に取り組んでいる方々による2つの実装が、最初の2段階を示しています。どちらもオラクルとの協力で作られました。

Linda Havivの自己改善する「第二の脳」は、ノートをMarkdownで保持しつつ、処理を担う層をOracle AI Databaseに移しています。文脈が増えるにつれ、ファイルのフォルダーにおけるプライバシーは「単なる取り決め」にすぎなくなったためです。

Cole Medinの「チームの脳」は、その先へ進みます。各人が自分のエージェントと個人メモリを持ち、共有知識はModel Context Protocolサーバーの背後に中央配置されます。データベースで行レベルセキュリティを適用し、デフォルトでは拒否します。その理由を述べた言葉は、どのチーム向けプロジェクトにも掲げたいものです。「システムの個人用部分である、この第二の脳に、セキュリティの責任を少しでも持たせてはいけません。」

これが変化です。個人の第二の脳では、自分のものだからエージェントを信頼します。チームの脳では、信頼できないことを前提にし、制御の適用をデータベースに移します。Coleの実装が未解決のまま残しているのは、企業向けへの次の段階で解決すべき点です。共有層は読取り専用で、アクセスには固定トークンを使い、エージェントが何を見たかは記録していません。

「企業の脳」は何に答えなければならないか

問いは3つです。これは誰のメモリか。ほかに誰が読み書きできるか。そして、エージェントが行動したとき、何を知っていたか。

最初の問いは簡単です。Oracle AI Agent Memoryは、すべてのレコードをユーザー、エージェント、スレッドで範囲分けします。ただし、それだけでは不十分です。ドキュメントにも、アプリケーションから渡すユーザーIDは「範囲指定する値であり、本人である証拠ではない」と明記しています。2つ目の問いには、9月22日公開のリリース26.8が対応します。Agent MemoryをOracle Deep Data Securityに接続し、サインインしたどのユーザーが各メモリにアクセスできるかを、データベース自体が決めます。ユーザーのIDトークンをデータベースに渡し、検証したうえで、すべての読取りと書込みにポリシーを適用します。具体例では、Aliceは自分のメモリを保存できますが、Bobのメモリを保存しようとするとデータベースが拒否します。アプリケーションがその判断をしないため、そこで判断を誤ることもありません。

3つ目は、銀行のリスク管理チームが半年後に尋ねる問いです。答えるには、2つの記録が必要です。重要な回答では、モデルに何を見せたかを、ユーザー、時刻、使用したメモリとともにログに残します。さらに、価格やポリシーなど、エージェントが読む表でFlashback Time Travelを有効にし、その瞬間にどのような状態だったかを正確に確認できるようにします。

この仕組みがどれほど新しいかについては、率直にお伝えすべきでしょう。新しいAgent Memoryは9月下旬に出たばかりで、具体例も本番用テンプレートではなく、学習用の環境です。Deep Data Security自体は、Autonomous AI Databaseだけでなく、26ai以降の無償Oracle AI Databaseコンテナでも動くので、クラウドアカウントを使う前にローカルでこのパターンを試せます。履歴の保持は消去権と相反する面もあるため、削除を履歴へどう反映するかは、有効化前に決めるべき設計事項です。また、エージェントが何を知っていたかを監査するための、合意された標準はまだありません。米国の銀行監督当局は4月にモデルリスクのガイダンスを改定しましたが、エージェント型AIを明示的に対象外にしました。確信できるのは、ルールを置くべき場所です。すべてのエージェントが必ず通る層に置かなければなりません。

詳細情報

pip install oracleagentmemoryと、Oracle AI Developer Hubのエージェントメモリ用ノートブックをご覧ください。