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

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

- Kind: PROTOCOL
- Published: 2026-08-22
- Canonical: https://kiokulab.com/notes/memory-object
- Publisher: Kioku Lab (https://kiokulab.com)

---

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

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

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

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

## 設計原則

フィールドの前に、原則を先に置く。フィールドは変わりうるが、原則は v0.1 の立場そのものである。

1. **判断の粒度で切る。** ログの一行でも、議事録の一冊でもなく、「次の判断に持ち込める一件」を単位とする。
2. **決定と未決定を、型で分ける。** 語調やニュアンスに埋め込まない。組織の事故の多くは、決まっていないことが決まったものとして伝わる瞬間に起きる。
3. **来歴のない記憶は、使わない。** 誰が・いつ・何を根拠に——に遡れない情報は、どれだけもっともらしくても判断材料にしない。
4. **忘れられるように作る。** すべての記憶は見直し期限を持つ。「永遠に有効」はバグであって仕様ではない。
5. **責任は人に帰属する。** AIは記憶を保持し、想起する。しかし記憶の内容に責任を持つのは、常に特定の人である。
6. **移せる。** 担当が替わるとは、記憶の管理者(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が書いた記憶を、人の判断に使うために

[総説](/notes/organizational-memory)で述べたとおり、記憶の獲得コストは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 で書くと、こうなる。

```json
{
  "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"
}
```

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

```json
{
  "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 が要求する運用は三つだけである。

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

## 規定しないこと(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 以降で扱う。この仕様への異論、実装の報告、現場での破綻例は [info@kiokulab.com](mailto:info@kiokulab.com) へ。破綻例がいちばんありがたい。

---

### 出典

- 関連記事:[組織の記憶とは何か——35年の研究史と、AI時代の論点](/notes/organizational-memory)(Kioku Lab, 2026)
- Nygard, M. (2011). Documenting Architecture Decisions. [cognitect.com/blog/2011/11/15/documenting-architecture-decisions](https://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/](https://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

---

Source: https://kiokulab.com/notes/memory-object · Contact: info@kiokulab.com