PROTOCOL

Memory object の最小構造(v0.1)

組織の記憶の最小単位を、8つのフィールドで定義する仕様草案。決定と未決定を型で分け、来歴・責任・有効期限を第一級の要素として扱う。実装非依存の公開ドラフトとして、フィードバックを募集する。

PUBLISHED: 2026-08-22
READING: 11 min

総説は、未解決の論点を六つ挙げて終わった。読み返すと、最初の四つ——記憶の単位、決定と未決定の区別、忘却の設計、責任の所在——は、実は同じひとつの問いに畳み込める。

「一件の記憶」とは、何か。

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

本稿はその単位を Memory object と呼び、その最小構造を仕様草案として公開する。バージョンは v0.1。特定の製品にも、特定の実装にも依存しない。この草案は使われながら改訂される前提であり、異論と実装報告を歓迎する。

設計原則

フィールドの前に、原則を先に置く。フィールドは変わりうるが、原則は 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": "営業・山田",
    "recorded_at": "2026-08-05",
    "source": "2026-08-05 定例会議 議事録 §3",
    "captured": "ai_extracted",
    "confirmed_by_human": true
  },
  "accountability": {
    "owner": "営業・山田",
    "steward": "営業・佐藤(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": "営業・山田",
    "recorded_at": "2026-08-05",
    "source": "2026-08-05 定例会議 議事録 §5",
    "captured": "ai_extracted",
    "confirmed_by_human": true
  },
  "accountability": { "owner": "営業・山田", "steward": "営業・佐藤(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 にする。上書きはしない。
見直し期限が過ぎたら、想起時に必ず明示する。 提示なしの期限切れ記憶の引用は、この仕様への違反である。

規定しないこと(non-goals)

v0.1 は意図的に、以下を規定しない。

保存方式:データベースでもファイルでも、.md の frontmatter でもよい。
検索・想起のアルゴリズム:全文検索でも embedding でも、その組み合わせでもよい。
UI:カードでも一覧でもチャットでもよい。
転送プロトコル:組織間で Memory object を交換する手順は v0.1 の範囲外。
評価指標:記憶が「効いた」ことの測定は、総説の論点5のまま未解決。

最小構造の仕事は、何を残せば判断に持ち込めるかの合意だけである。

既存の実践との関係

車輪の再発明ではない、と言うために二つ挙げる。

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

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

v0.1 の限界と、募集

正直に書く。この草案が答えていないことは多い。

組織をまたぐ visibility と権限のモデル(承継・M&A の本丸はここにある)
法令上の削除義務と「忘れたことの記録」の両立
context の粒度——どこまで書けば「判断に持ち込める」のか、実地の基準
効果の測定——引き継ぎの立ち上がり時間、約束の履行率、同じ失敗の再発率

これらは実際の承継の現場で検証しながら、v0.2 以降で扱う。この仕様への異論、実装の報告、現場での破綻例は [email protected] へ。破綻例がいちばんありがたい。

出典

関連記事:組織の記憶とは何か——35年の研究史と、AI時代の論点(Kioku Lab, 2026)
Nygard, M. (2011). Documenting Architecture Decisions. cognitect.com/blog/2011/11/15/documenting-architecture-decisions
W3C (2013). PROV-DM: The PROV Data Model. W3C Recommendation, 30 April 2013. www.w3.org/TR/prov-dm/

改訂履歴

v0.1(2026-08-22):初版公開。

外部での言及

Qiita「組織の記憶の最小単位を JSON で定義してみた——Memory object v0.1 と 4 つの型」(2026-09-03)— https://qiita.com/AGI-is-coming/items/6e01d5c84e7d1a9234dc