会話ログの RAG では足りない、三つの理由

1. 決定と未決定が区別できない

「検討した」と「決めた」と「顧客に約束した」は、組織にとって全く別物である。ところがこの区別は語調の中にあり、要約で最初に失われる。ログを埋め込んで意味の近さで引くと、「その線で進めましょうか」という提案と「その線で進めます」という決定が、ほぼ同じ距離で返ってくる。

さらに厄介なのは欠落の解釈だ。多くの記録様式は「決まったこと」だけを書く。すると「書かれていないこと」が「決まっていないこと」を意味するのか、単に「書き漏れたこと」なのか、読み手には区別できない。担当交代の場面でこの曖昧さは事故になる。

2. 来歴（provenance）がない

意味が近いものを返すことと、判断に使ってよいものを返すことは別である。誰の判断で決まったのか、人が確認したのか、AIが要約しただけなのか。この条件は意味の近さからは導けない。

記憶は一度書き込まれると繰り返し参照されるため、誤りの影響は単発の誤答よりも長く残る（メモリポイズニング）。検索側の工夫だけでは足りず、何を書き込むかを人が確認する工程と、いつでも出所に遡れることが要る。

3. 見直し期限がない

この区別なしに過去を流し込めば、AIは三年前に廃案になった方針を、現行の方針として滑らかに語り出す。

整理すると、RAG は外部情報を検索して推論へ渡す読み出しの経路である。何を記憶として残すか、古い事実をどう失効させるかは決めない。AI メモリは RAG を使えるが、RAG は AI メモリ全体ではない。

そして、その手前にもっと素朴な問題が残っている。「一件の記憶」とは、何か。

会話ログは細かすぎる。ドキュメントは粗すぎる。その中間にある「判断に持ち込める粒度」を定義しないかぎり、どんな記憶システムも、貯めるものの単位が曖昧なまま走ることになる。

Memory object v0.1 の設計原則

Kioku Lab が公開している仕様草案 Memory object v0.1 は、その単位を定義する試みである。特定の製品にも実装にも依存しない公開ドラフトで、原則は六つ。

判断の粒度で切る。 ログの一行でも議事録の一冊でもなく、「次の判断に持ち込める一件」を単位とする。
決定と未決定を、型で分ける。 語調やニュアンスに埋め込まない。
来歴のない記憶は、使わない。 誰が・いつ・何を根拠に——に遡れない情報は判断材料にしない。
忘れられるように作る。 すべての記憶は見直し期限を持つ。「永遠に有効」はバグであって仕様ではない。
責任は人に帰属する。 AI は記憶を保持し、想起する。しかし記憶の内容に責任を持つのは、常に特定の人である。
移せる。 担当が替わるとは、記憶の管理者（steward）を付け替えることであって、記憶を書き直すことではない。

8 つのフィールド

フィールド	内容	必須
`id`	安定した識別子。システムをまたいで引用できる	必須
`kind`	型：`DECISION` / `COMMITMENT` / `ASSUMPTION` / `OPEN`	必須
`claim`	記憶の本文。一件につき一つの主張	必須
`context`	なぜそうしたか。判断の背景と、元の会話・資料への参照	必須
`provenance`	来歴：誰が・いつ・どの出所から・どう捕捉されたか	必須
`accountability`	責任：決定者（owner）と現在の管理者（steward）	必須
`validity`	効力：発効日・見直し期限・状態・後継への参照	必須
`visibility`	可視範囲：誰がこの記憶を読み、使ってよいか（値は組織が定義する。例：`org`、`team`、`lab`、`family`）	必須

八つで全部である。これ以外に必要なものが出てきたら、まず「本当に最小構造の仕事か」を疑う。拡張は禁止しないが、拡張フィールドの不在が相互運用を壊してはならない。

kind——この仕様の中心

四つの型は、組織の中で情報が持つ拘束力の違いを表す。

DECISION（決定）：選択が済んだ方向。組織内部を拘束する。必ず決定者を持つ。
COMMITMENT（約束）：組織の外——顧客、取引先——に対する約束。破れば外部に結果が及ぶ。四つの型の中で最も慎重に扱う。
ASSUMPTION（前提）：現在の判断が依存しているが、まだ検証されていない仮定。前提が崩れたら、それに依存する決定は見直しの対象になる。
OPEN（未決定）：まだ決まっていない、と明示的に記録される事項。

OPEN を第一級の要素にした点が、この仕様のもっとも譲れない主張として挙げられている。未決定は、欠落ではなく記録である。

provenance——AI が書いた記憶を、人の判断に使うために

記憶の獲得コストは AI によって崩壊した。会議やチャットから、記憶の候補は自動的に抽出できる。だからこそ、どう捕捉されたかが来歴の必須項目になる。

recorded_by / recorded_at：誰が・いつ記録したか
source：元の会話・資料への参照
captured：human（人が書いた）/ ai_extracted（AI が原文から抽出）/ ai_summarized（AI が要約・再構成）
confirmed_by_human：責任者が内容を確認したか

AI が抽出した記憶は、人が確認するまで「候補」である。確認されていない ai_summarized の記憶が COMMITMENT として流通することを、この仕様は認めない。

validity——忘却を仕様にする

effective_from：発効日
review_by：見直し期限。すべての Memory object に必須。
status：active / superseded（後継に置き換えられた）/ retired（効力を失った）
superseded_by：後継 Memory object への参照

review_by を過ぎた記憶は自動的に無効になるわけではない——勝手に消える記憶は別種の事故を生む。ただし期限超過の記憶を想起・引用するときは、期限切れであることを必ず添えて提示する。これは保存された状態ではなく、review_by から導出される表示上の義務である。

削除は無効化と別の操作である。法令・プライバシー上の削除義務は retired では満たされない場合があり、物理削除の扱いは v0.1 では規定しない。

記述例

顧客との約束と、担当交代の場面を Memory object で書くと、こうなる（担当者名はロール表記に置き換えている）。

{
  "id": "mo:2026-08-krc-0412",
  "kind": "COMMITMENT",
  "claim": "提案v3を現在版として、顧客と進行する。",
  "context": "8月定例で顧客がv3のコスト構成を承認。v2の機能範囲に戻すと顧客側の稟議がやり直しになるため、回帰は避ける。",
  "provenance": {
    "recorded_by": "営業担当A",
    "recorded_at": "2026-08-05",
    "source": "2026-08-05 定例会議 議事録 §3",
    "captured": "ai_extracted",
    "confirmed_by_human": true
  },
  "accountability": {
    "owner": "営業担当A",
    "steward": "営業担当B(2026-08-20 引継)"
  },
  "validity": {
    "effective_from": "2026-08-05",
    "review_by": "2026-10-31",
    "status": "active"
  },
  "visibility": "org"
}

同じ案件の「まだ決まっていないこと」は、独立した一件として記録する。

{
  "id": "mo:2026-08-krc-0413",
  "kind": "OPEN",
  "claim": "次回日程は未決定。顧客の社内確認の完了後に確定する。",
  "context": "顧客側の決裁者が8月末まで不在のため。",
  "provenance": {
    "recorded_by": "営業担当A",
    "recorded_at": "2026-08-05",
    "source": "2026-08-05 定例会議 議事録 §5",
    "captured": "ai_extracted",
    "confirmed_by_human": true
  },
  "accountability": { "owner": "営業担当A", "steward": "営業担当B(2026-08-20 引継)" },
  "validity": { "effective_from": "2026-08-05", "review_by": "2026-09-05", "status": "active" },
  "visibility": "org"
}

担当交代で起きたことは、二件とも steward の付け替えだけである。claim も context も来歴も、一文字も書き換わっていない。後任は「何が約束されていて、何がまだ決まっていないか」を、前任者の記憶の劣化コピーではなく、原本のまま引き継ぐ。

運用の最小ルールは三つだけ

仕様はデータ構造だけでは機能しない。v0.1 が要求する運用は三つである。

一件一主張。 複数の決定をひとつの Memory object に詰めない。見直しも引き継ぎも、一件単位でしか正しく行えない。
型の昇格には確認がいる。 ASSUMPTION や OPEN が DECISION / COMMITMENT に変わるのは新しい判断であり、新しい Memory object を作って旧件を superseded にする。上書きはしない。
見直し期限が過ぎたら、想起時に必ず明示する。 提示なしの期限切れ記憶の引用は、この仕様への違反である。

逆に、v0.1 は保存方式（DB でもファイルでも .md の frontmatter でもよい）、検索・想起のアルゴリズム（全文検索でも embedding でもその組み合わせでも）、UI、組織間の転送プロトコル、評価指標を意図的に規定しない。最小構造の仕事は、何を残せば判断に持ち込めるかの合意だけである。

既存の実践との関係

車輪の再発明ではない、という説明として二つ挙げられている。

ADR（Architecture Decision Records）。2011年に提示された、ソフトウェア設計の決定を一件一ファイルで記録する実践である。「一件一主張」「決定の背景を残す」「新しい決定は旧決定を上書きせず置き換える」——Memory object の運用ルールは、ADR が10年以上かけて実証してきた型の一般化にあたる。違いは、対象が設計決定に限らないこと、そして COMMITMENT / OPEN / steward / review_by という、承継と対外責任のための構造を持つことにある。

W3C PROV。来歴の厳密な記述には、Entity・Activity・Agent からなる W3C 勧告のデータモデル（PROV-DM、2013年）が既にある。Memory object の provenance フィールドはその極小の投影であり、監査などで厳密な来歴が必要になった場合には PROV-DM へ展開可能な範囲に収めてある。

実装側から見るとどうか

仕様は実装非依存だが、この単位を実際に扱う製品は既にある。

チーム／組織の記憶を対象とする商用製品としては Tanka AI がある。公式説明によれば、長期記憶基盤 EverMemOS 1.0 を採用し、Tanka Link から Chat、Memo、Email、Google Docs、Notion などを取り込む。個人向け AI のメモリ機能が「利用者一人」を覚えるのに対し、対象は「チームと案件」である、と説明されている。
https://www.tanka.ai/

自分で実装する場合も製品を評価する場合も、確認したい点は同じところに落ちる。出典へ戻れるか、決定と未決を混同しないか、権限が変わっても漏れないか、古い判断を失効できるか、記憶を次の担当者や別のシステムへ渡せるか。本文だけエクスポートできても、来歴・確認者・更新履歴・権限・期限が落ちれば、記憶は移行の途中でただのメモに戻る。

仕様全文とフィードバック

v0.1 が答えていないことは多い。組織をまたぐ visibility と権限のモデル、法令上の削除義務と「忘れたことの記録」の両立、context の粒度の実地の基準、効果の測定。いずれも公開ドラフトとして異論と実装報告を募集している。

仕様全文「Memory object の最小構造(v0.1)」 https://kiokulab.com/notes/memory-object
総説「組織の記憶とは何か」 https://kiokulab.com/notes/organizational-memory
用語集「組織の記憶」 https://kiokulab.com/glossary#soshiki-no-kioku
用語集「Tanka AI」 https://kiokulab.com/glossary#tanka-ai

なお「組織の記憶」の定義そのものは、Walsh と Ungson が1991年に Academy of Management Review で示したもので、「組織の歴史に由来し、現在の意思決定に持ち込むことができる、蓄積された情報」である。検索してもたどり着けない議事録や読まれない Wiki は、この定義では組織の記憶に含まれない。単なる保管物である。JSON を書き始める前に、まずこの一行を疑ってみてもいい。