交換可能なエージェントのための組織の記憶

概要

AI エージェントに仕事を任せる組織では、仕事をする主体がたびたび入れ替わります。モデルは数か月ごとに新しくなります。同じ仕事を Claude、Codex、Gemini のどれが担うかも、その日の都合で変わります。それでも組織は、前に決めたことと、前に失敗したことを覚えていなければなりません。

この論文では、記憶をモデルの中ではなく、組織が持つ文書の側に置く設計を考えます。エージェントは共有の頭脳を持つのではなく、信頼できる文書を読んでから仕事を始めます。作業の記録を、確かめられた知識へ段階的に育てる流れとして、Trace → Episode → Research → Review → Library の 5 段を提案します。

問題

エージェントの記憶は、多くの場合、一つのエージェントか一つの製品の中に閉じています。会話の履歴、要約された memory、製品ごとの保存領域がその例です。この形には三つの弱さがあります。

• モデルや製品を替えると、記憶が残らないか、形を変えないと移せません。
• 記録は増えますが、どれが確かで、どれが途中の推測かが区別されません。
• 同じ事実が何か所にも書かれ、やがて食い違います。

当社の中では、この問題が毎日起きます。たとえば秘書の役割を担うエージェントは、session ごとに新しく起動します。前の session で代表が直したことを次の session が知らなければ、同じ間違いがくり返されます。人の組織で担当者が替わるときの引き継ぎと同じ問題が、一日に何度も起きます。

方法

記憶を「誰が覚えているか」ではなく、「どこに書いてあるか」で設計します。どのエージェントも、仕事を始めるときに同じ場所を読み、終わるときに同じ場所へ書きます。専門性も、エージェントではなく置き場所に持たせます。エージェントはその場所の決まりと手引きを読み、役割をかぶります。

記録は、次の 5 段で知識に育てます。

1. Trace：会話、コマンド、変更など、起きたことの生の記録。手を加えずに残します。
2. Episode：一つの仕事のまとまり。何を頼まれ、何をして、どう終わったか。
3. Research：いくつもの Episode から、くり返し現れる型や仮説を取り出したもの。
4. Review：人か別のエージェントが、Research の主張を元の記録と照らして確かめる段階。
5. Library：確かめられた知識。次の仕事で、エージェントが最初に読むものです。

段を上がるほど量は減り、信頼は上がります。Library に入るものは、どの記録から来たかをたどれるようにします。一つの事実は、Library の一か所にだけ書きます。

この設計は、当社が 2026 年 6 月から研究開発しているマルチエージェントシステム Moss の中心にあります。2026 年 9 月の時点で、Moss の repository には約 3,100 件の commit と約 16 万行の code があり、代表が毎日の仕事で使っています。

これまでに分かったこと

社内で使う中で、二つのことが見えてきました。

一つは、エージェントが困るのは置き方ではないことです。エージェントは検索して集めるので、folder の分け方の違いではあまり困りません。困るのは、記録の食い違いと漏れです。どちらも、最後は人が間違った答えを受け取る形で表に出ます。

もう一つは、人が中身を確かめる窓が要ることです。初期の試作では、ほとんどすべてをデータベースに入れ、文字の画面からしか中を見られませんでした。その結果、記録が正しいかを確かめにくくなりました。今は、考えている途中のものは git、決まって効いているものはデータベース、完成して変わらないものは長期保存の場所、と状態で分ける形を試しています。人が見る画面は、別に用意します。

未解決の問い

• 評価：記憶がよく働いているかを、どう測るか。候補は「人が聞いたとき、エージェントが正しい答えを出典付きで返せるか」です。これを再現できる試験にする方法は、まだありません。
• Review の負担：人がすべてを確かめると、人が律速になります。どこまでをエージェント同士の確認に任せられるか。
• 忘れること：古くなった知識を、いつ、どう退けるか。消すのではなく、効かなくなったと記す形を考えています。
• モデルの中の記憶との関係：モデルの内部に記憶を持たせる研究とは、競合するのか、補い合うのか。当社のこの実験は、計算資源の準備が整うまで保留しています。