歴史資料

このページは元の設計 v1.0 の ARCHITECTURE.md を保存したものです。記載されている実装・検証状況は資料作成時点のものです。API の対応関係は 移行、現在の構成は アーキテクチャを参照してください。

Atom Memory — 最終アーキテクチャ v1.0

2026-09-10 / 実装の基準とする設計確定案 / ライブラリ本体・実LLM・分散性能は未検証

0. 決定

一つの論理的なAtom集合を、有限のreadと小さなwriteで扱う。情報・まとまり・関係・改訂は同じAtom形式を使い、Writerも通常のエージェントも同じハーネスから操作する。

Cellは公開モデルにも意味モデルにも導入しない。Viewは読み出しの計算、Workspaceは実行中の版と未確定差分であり、別の永続メモリの種類ではない。保存場所、複製、索引、キャッシュ、ジョブキューは実装の内側へ置く。

「単一モデル」は、全物理バイトを一つのテーブルへ格納することでも、全実装情報をAtomへ再帰的に変換することでもない。永続的な意味情報に別系統の表現を要求しない、という契約である。

この文書はv0.1〜v0.3と、その後のCellを外す議論を統合し、相違点について優先する。実装前の設計を固定するもので、正確さ・検索品質・拡張性能・新規性の実証完了を意味しない。

1. 変えない原則

• 情報の内容と関係に基づいて整理する。タスクの正解率、有用性、報酬を永続的な所属の定義にしない。
• LLMが意味を理解し、分解・集約・訂正案を出すことは認める。権限・版・予算・参照整合性の検証は通常コードで行う。
• 原資料へ戻れる。抽出・仮説・生成要約を原資料の直接引用と混同しない。
• 多重所属と再帰的なまとまりを認めるが、全世界のルートや全体列挙を通常操作に要求しない。
• 保存総量の固定上限を設けない方向を目指し、一回の読取・変更・推論は有限にする。

2. 論理モデル

記憶の正本は、受理済みのAtom版の論理集合 M である。Mは分散できる集合であり、全件を保持する一つの配列やRoot Atomではない。

AtomRevision = {
  atomId, revisionId, previousRevisionId?, state,
  schema, value, slots,
  origins, provenance, policyId, recordedAt, validTime?
}

atomIdは論理的な同一性、revisionIdは不変版の同一性。物理位置をIDへ露出しない。既存版を上書きしない。本文が同じでも、別の発言・別の原資料は別の出典として保持する。

schemaは内容を解釈するための名称であり、任意コードの起動命令ではない。新しい話題ごとにCoreを改造しない。最小の意味プロファイルはsource、extract、collection、membership、statement、summary、hypothesisで足りるが、別の保存型を作るものではない。

valueは上限付きの値・テキスト、または大きい原資料の不変なblob参照。巨大本文や全メンバーを一Atomへ押し込まない。リテラルや管理用時刻をすべて独立Atomにする必要はない。

2.1 役割付き参照

{ role: "from", target: A }
{ role: "to", target: B }
{ role: "object", target: X }

「AからBへ」と「BからAへ」を構造上で区別する。条件、否定、発言者、対象時刻も必要なら参照または値で保持する。最低単位は、意味が失われない単位であり、最短の文字列とは定義しない。

順不同set、順序付きsequence、役割付きrecordは、同じAtom形式で解釈する内容上の形式である。順序を必要とする場合には、所属の発生を表す各Atomへ順序キーを持たせる。同じ要素の繰り返しを消さない。決定的な表示順を因果順や厳密な同時性の証拠としない。

3. 所属もAtomにする

P = collection("ある内容上のまとまり")
Q = collection("別の内容上のまとまり")

M1 = membership(group=P, member=A)
M2 = membership(group=P, member=B)
M3 = membership(group=Q, member=B)
M4 = membership(group=Q, member=C)
M5 = membership(group=Q, member=P)

M1〜M5も他と同じAtomである。Pの内部に全メンバー配列を持たせることを正本の必須条件にしない。Pの現在のメンバーは、その読取状態で有効なmembershipを関係索引から読むことで得る。

PへDを追加する通常操作は、membership(group=P, member=D)を新規作成すること。P自身や全祖先の版を書き換えない。Pの説明文を訂正する場合だけ、P自身を改訂する。

setとして表示する際は、同じ解決済みメンバーを一意に表示できる。ただし別資料に由来する所属の主張は別Atomとして保持する。同じメンバーが複数回現れても、それを独立した証拠として自動加点しない。

関係の追加が競合しないという意味ではない。「最大10人」「循環禁止」「唯一の管理者」のような追加制約を強制する書き込みは、その制約の検証・協調を要する。通常の自由な集合追加へその全体協調を必須にしない。

4. 固定された構成と、動的な関連を区別する

4.1 pinned / logical

• pinned参照は、特定のAtom版を指す。
• logical参照は、Atomの論理IDを指す。readが選んだ読取状態で版を解決し、出力には確定した版を記録する。

4.2 include / refer

• includeは固定版への構成参照。既存の公開済み版、または同じ有限バッチ内で検証する新規版だけを対象とする。
• referは言及・関連の参照。logicalまたはpinnedを選べる。参照しただけで本文や要約を自動再帰評価しない。

固定版includeのグラフはDAGとする。既存版は不変なので、受理済み既存版への参照と有限バッチ内の循環検査でこの不変条件を保つ。

動的なmembershipのgroup/memberは通常referである。動的な所属・関連全体には、世界規模のDAG保証を要求しない。全体をDAGと偽らず、有限の探索で循環を検出・省略し、back-referenceとして扱う。固定構成として厳密なDAGが必要な場合は、固定版includeを使う。

重要：P@1という集合Atomの版だけを固定しても、外付けのmembership集合は固定されない。 pinned(P@1)が固定するのはPの記述と明示的なslotsだけである。動的な所属全体を再現するには、所属を読んだsnapshot/ReadReceipt、または具体的な所属版を列挙した不変のmanifestが必要。固定includeの自動展開へ動的な逆引きを暗黙に混ぜない。manifestが大きければページ化し、別の巨大Rootにしない。

この区別により、「最新状態へ追随する関係」を「固定版の構成」と混同しない。v0.1のすべての構成関係を可変DAGにする規則からの、明示的な変更である。

5. 更新・履歴・競合

5.1 改訂は新しい版の追加

B@1 --改訂--> B@2

同じ原資料の訂正・同じ管理対象の改訂には新しい版を作る。別人の異なる発言や新しい出来事は、原則として別Atomとする。意味が近いだけで同一化しない。

既定では一つの論理IDのheadは一つとし、改訂はexpected revisionに対する条件付き書き込みで確定する。同じ前提からの競合は失敗として返す。時刻が大きいという理由だけで片方を黙って破棄しない。独立運営の未承認版が複数ある場合、それらを自動的な一つのheadと解釈しない。

所属解除は、その所属Atomをretiredにする版の追加。共有された子Atomを消すこととは別である。

5.2 writeの確定単位

writeは有限の変更バッチを受け取り、受理できる原子性の範囲では全件成功または全件不成立にする。バックエンドが当該バッチの原子性を提供できなければ、変更する前にATOMICITY_UNAVAILABLEを返す。暗黙の部分成功へ弱めない。呼出側が明示的に複数操作へ分けることはできる。

全世界の一つのcommit番号、全AtomのCAS、全スコープの世代更新を通常変更の前提としない。一つのhot Atomへの改訂は競合点として残る。独立した所属追加は、親headの更新を不要にできる。

冪等キーは認証主体・要求内容へ結び付け、同じキーの異なる内容を拒否する。LLMが同じ文を再生成することに冪等性を依存させない。

5.3 削除は改訂と別

retiredは履歴上の取り消しであり、物理消去ではない。管理APIは現在の読取拒否を先に適用し、原文、派生要約、ベクトル、索引、キャッシュ、内部実行状態を対象に消去を進める。通常のread/writeという意味操作を二つに絞っても、管理上のpurgeや認証処理をなくすわけではない。

6. read — 文脈から有限の記憶を取り出す

read(selector, context, budget, continuation?)
  -> AtomPage + ContextPack? + ReadReceipt + continuation? + diagnostics

selectorは既知IDの取得、役割付き関係の検索、自然言語検索を扱う。readは意味上の保存構造を変更しない。派生索引やキャッシュの更新は、所属の書き換えとは別の内部処理である。

6.1 入力

問い、現在のコンテキスト、任意の明示的な推論状態、対象範囲、時点、読取整合性、資源予算を受け取る。対象範囲の指定は権限の付与ではない。

非公開の内部CoTを取得できることは前提にしない。ホストが扱える推論テキストまたは状態を使う。内部隠れ状態へ将来接続する場合は、別の検索空間へ無条件にコサイン類似度を計算せず、写像の検証を要する。

6.2 初版の決定的な処理順

1. 認証、現在の削除状態、要求範囲、読取状態を確定する。
2. 問い・コンテキスト・推論状態を、存在するものだけ別々に同じ空間へ埋め込む。原文向けの語彙検索も入口として使う。
3. 内容Atom・集合の有効な表現・関係Atomを同じ検索候補へ入れる。最上位のルートからの下降を必須にしない。
4. 同一版を一意に管理し、関係索引から親・子・役割を予算内で展開する。近傍であることを証拠の独立性と解釈しない。
5. 候補ごとに関連度を評価し、必要な条件・発言者・対象時刻を付随させた出力単位を作る。
6. 原資料の版と範囲を使って原文の重なりを扱い、正確なシリアライズ後のtoken予算で採用する。
7. 最新の許可状態を再確認し、版、関係、出典、索引遅延、打切り、続きを返す。

埋め込みだけの初期関連度は r(a)=max_j max(0, cos(q_j,e(a)))。ベクトル空間が異なる入力は比較しない。語彙検索は入口を広げる。初版の並べ替えはr降順・安定ID順を基準とし、同点時の費用比較以外は隠れたtask rewardを入れない。これは性能最適性の主張ではなく、交換可能な比較基準である。

再帰平均で共有された子を多重に加算して親ベクトルを作ることは、既定方式にしない。集合の内容説明を生成して埋め込む場合、どの版と所属範囲を読んだかを記録する。

6.3 出典と重複

出典座標は (sourceAtomId, sourceRevisionId, 正規化UTF-8範囲)。範囲は半開区間で、文字途中を指してはいけない。原資料が同じでも版が違う場合、同一範囲として安易に統合しない。

原文引用の重なりは区間の和で表現できる。生成抽出・要約は、同じ出典範囲を持つという理由だけで同義として削除しない。否定・条件・話者を落とした要約を元の文と代替可能としない。

同じ識別子や同じ原文への重複経路に、独立証拠としてのボーナスを与えない。ただし、再分割すると埋め込み・候補・予算の収まり方は変わり得る。検索結果と回答の完全な構造不変性は未保証で、評価対象とする。

初期のevidence出力は原文・抽出を根拠とする。mixedでは生成要約も明示的に返せるが、種類と出典を表示する。意味的な網羅や真偽をCoreが保証したとは出力しない。

6.4 予算と継続

読取Atom数、処理候補数、本文bytes、ネットワーク呼出し、モデル呼出し、入出力tokensを別々に制限する。子処理に予算を複製せず、分配する。

自分の消費 + 子へ予約した予算の総和 <= 受領した予算

再試行、依存検証、関係探索、tokenize、routingも会計対象。資源上限までに検証できなければ停止・pending・原文フォールバックとし、検証を省略しない。

継続子は読取計画・版・索引状態・認証へ束縛する。失効した続きはエラーで返し、黙って最新状態から再開しない。全処理済みとは、宣言した範囲と探索方式に対してのみいう。ANNの終了や選んだ領域の終了を、世界全体の完全探索としない。

7. 要約・ベクトル・依存管理

要約を正本へ保存する場合は、ホストが明示的にwriteする出典付きの派生Atomとして保存する。read中に生成した要約は、一時出力またはキャッシュにとどめ、readだけで正本Mへ新しい意味Atomを追加しない。ベクトル・関係索引・全文索引は、Atomに結び付く再生成可能なアクセス用データでよい。数値ベクトルや索引ページの一つ一つを、新しい意味Atomとして索引し直すことは強制しない。

「各Atomにベクトルを持てる」は「任意のAtom版に検索表現を得られる」という意味。作成直後・モデル失敗時に必ず準備済みである、という意味ではない。非テキストも適合するencoderを通し、space IDを保持する。

7.1 依存の記録

派生計算は、Coreが実際に読んだ版、関係検索の範囲・watermark、空検索、モデル設定、権限世代を記録する。これはWriterの自己申告で代替しない。

• inputsRead：生成器に渡した入力。保守的な計算依存。
• citedOrigins：出力が明示する原資料。意味的な根拠の主張。
• semantic fidelity：原文の意味が保たれたか。別に評価する。

この三つを混同しない。W3C PROV-DMもusageとderivationを区別し、使用・生成の記録だけで影響があったと自動判定しない。[R5]

Pの要約がAとBを読んだ場合、A/Bの版だけでなく「Pの所属を列挙した結果」にも依存する。Dが新しくPへ追加されたのにA/Bの版が変わっていない、というケースを見逃さない。巨大集合の全メンバー読取を要求しない要約は、読んだ部分の要約として明示する。

依存が巨大ならmanifestをページ化する。生成器へ全履歴を見せれば、依存も保守的に全履歴へ広がる。実際には見せたが引用しなかった入力を、無かったことにしない。

7.2 更新と再利用

B@2ができても、B@1から作った全要約の再生成をwriteの完了条件にしない。固定された旧版についての結果は保持できる。要求された現在の版に依存が合わない結果は、現在の根拠にしない。

必要な出力に対して依存を検証し、再評価する。関係範囲の新規挿入や索引世代を厳密に局所化できない場合は、保守的な検証費用・キャッシュ不使用・明示した遅延のいずれかを選び、古い結果を最新と称さない。全スコープの同期カウンターを毎回更新する方式を分散時の必須機構にはしない。

原資料の受領と基礎索引への反映を優先し、高価な上位表現の生成を遅延できるようにする。最新データに到達する入口がないまま「全て必要時生成」としない。

8. Writerと共通ハーネス

入力 → read → 推論 → ツール/差分 → read → … → 回答またはwrite

Writerは原資料の追加・編集を入力にし、既存Atom・関係・出典を調べながら差分を作る。同じハーネスを回答エージェントも使い、入力・権限・確定可能な差分だけを変える。

Writerの作業差分はホスト管理の一時overlayへ置く。readはそのoverlayを重ねた状態も読める。モデルから見た編集ツールは差分を作るだけで、永続化はホストが許可したwriteで確定する。途中の仮説や失敗した差分を他の利用者へ公開しない。

LLMの実行中にDBトランザクションを保持しない。最後に必要な版と前提を短いトランザクションで検証する。空・範囲検索を前提にした変更では、その新規挿入も競合検証へ含める。実装できない前提保証を無視しない。長い外部処理を短い確定と上位層の楽観的検証へ分ける設計の参考にFoundationDBの文書がある。[R3]

固定命令・今回の入力・直近の必須観測は意味検索で落ちないようにする。推論状態の更新とメモリ再検索はできるが、それを「この質問に有用な束」を永久保存する報酬へ接続しない。

Writerや各Atomに常駐プロセスを一体ずつ割り当てない。共通ワーカーが有限の実行を処理する。Reader、索引、予算、権限判定までLLMに委任しない。

9. 一つの論理集合を分散して保存・検索する

                 共通Agent Harness
                      read / write
                           |
                      Atom Kernel
           版・参照・権限・予算・出典・確定
                           |
                   Storage / Index Adapter
                複数保存先・複製・索引・worker

意味のまとまりと、保存位置と、権限境界は独立にする。Cellは公開しない。保存先の移動でAtomのIDや所属関係を変えない。

既知IDの取得は配置解決から直接行う。意味検索は分散可能な索引を入口にする。通常のreadを全サーバーへのbroadcastに固定しない。一つの論理ANNグラフを分散KV上で扱うDistributedANNは、論理構造と物理配置を分ける先行例である。[R4] 本設計の性能をその論文の報告値で代用しない。

大きい親への所属索引は、独立したpostingとして分割・ページ化する。親ごとの巨大配列や、常に同期更新する単一カウンターを必須にしない。完全に全メンバーを読む仕事には、対応する列挙費用が残る。

ID/版の取得索引、役割と対象IDの逆引き、語彙・ベクトル索引、派生計算の依存索引を持つ。これらは同じ意味情報の再構築可能なアクセス経路であり、新しいメモリ型ではない。

保存・独立した取り込み・並行した質問は資源追加で拡張する。一つのhot Atomの強い更新順序、全資料の厳密な集計、任意の質問の完全な意味検索が、常に一定費用になるとはしない。

10. 整合性を名前だけで強くしない

論理的に一つのAtom集合であっても、読んだ全Atomが同時点・因果的に整合しているとは自動的には言えない。

• snapshot：要求された有限範囲に対して、対応するbackendのsnapshot保証を要求する。できなければ拒否する。
• version-pinned：実際に返した版と検索状態をReadReceiptに固定して同定する。全体同時点・因果整合・検索網羅性を保証しない。

初期ローカルbackendではsnapshotを使う。分散時に黙ってversion-pinnedへ弱めず、要求または合意したモードを明示する。後者を前者として比較実験しない。

一つのAtomは一つのread context内で同じ解決済み版を使う。継続の途中で版を入れ替えない。追加の因果・有限範囲の整合が必要な仕事は、対応するbackend/プロトコルで提供し、費用と準備状態を示す。

不変の事実を集める考え方にはDatomicの先行があるが、その公式文書は全順序の直列化によるper-db write scalingの制約も説明している。[R2] 単一形式にすることと水平拡張を達成することは同一ではない。

11. 権限と信頼

認証主体、許可、出典のsource区分、コミット権限はホストが検証・付与する。Atom本文やモデルの引数で上書きできない。

初版では永続的な集約・派生物を同一policy境界内に閉じる。異なる許可範囲からの読み出しは、許可された情報だけを一時的に組み合わせる。非公開情報を読んだ要約の引用を消して公開することを認めない。

ベクトル、要約、検索ルート、manifest、cursor、実行ログも保護する。権限失効と削除は、過去版の再読にも適用する。権限を確認できない状態で保護データを返さない。

取得した資料はデータであり、ハーネスの命令ではない。schemaや関係Atomから任意ツール・コード・権限変更を実行しない。意味構造を統一しても、信頼境界を統一しない。

12. 最小実装と公開契約

中心APIはreadとwrite。認証、管理消去、バックエンド能力確認、ホストの実行状態管理は別の管理面であり、エージェント向けの自由な意味操作にはしない。

core/       Atom・参照・出典・検証・read/write契約
runtime/    共通ハーネス・overlay・版と予算の実行状態
adapters/   保存・関係索引・語彙/ベクトル・モデル・tokenizer

最初はin-memory参照実装と、一つのローカル永続adapterで正しさを確かめる。分散能力をローカルDBのテストだけで主張しない。分散合意、独自ANN、独自汎用agent frameworkを同時に作らない。

モデル・索引・予算・プロンプト・生成規則は実験manifestへ固定する。ライブラリは特定の回答LLMや特定サービスへの依存をCoreへ埋め込まない。

13. 受入条件

ID	試験	必須の挙動
F01	BをP/Qの両方へ所属	Bの実体は共有。関係は独立に保持
F02	Pへ一要素追加	Pと全祖先の改訂を必須にしない
F03	M2をretiredへ改訂	P→Bだけ解除。Q→BとB自体は残す
F04	B@1からB@2へ改訂	固定B@1参照は維持。現在要求で旧要約を最新としない
F05	同じexpected版から同時改訂	一方は競合。静かにlast-write-winsにしない
F06	動的所属に循環	全体DAGと主張せず、有限探索で停止・関係を表示
F07	固定includeのバッチ循環	公開前に拒否
F08	Pの要約後に新しいDが所属	子の版が不変でも、所属検索の依存変化を検出
F09	原文を再分割・同一経路複製	同じ原文を独立証拠として加点しない。候補品質は別測定
F10	from/to、条件、否定を変更	意味保存変換と扱わない
F11	再帰・再試行で予算枯渇	親の総予算を超えて委譲せず停止
F12	途中結果0件	存在しないとの証明を返さない
F13	読取中に索引遅延・保存移動	固定した版と診断を維持。別の版へ黙って差し替えない
F14	snapshot非対応の分散要求	CONSISTENCY_UNAVAILABLE
F15	原子性非対応のwrite	部分適用前にATOMICITY_UNAVAILABLE
F16	Writerが途中で失敗	未確定差分を公開しない
F17	非公開資料混入・権限失効	本文・派生物・索引・cursorの経路で拒否
F18	生成要約をsourceと自己申告	ホストが拒否または正しい区分へ置換
F19	同一キー再送／内容変更再送	前者は冪等、後者は拒否
F20	原資料の管理消去後に旧版read	本文・要約を返さず、物理完了は別管理

上はテスト仕様であり、この最終アーキテクチャの本体を実装して合格させた結果ではない。過去v0.2/v0.3の小モデル結果を、この版の実装実績へ転用しない。

14. 研究・開発計画

段階1：意味を固定する。 Atom版、独立した関係、参照、条件付きwrite、出典を作る。F01〜F08を先に検証する。

段階2：読み出しを完成させる。 語彙/ベクトル入口、予算付き展開、出典単位の重複管理、cursor、正確なtoken計算を実装する。新情報と空検索の依存を含める。

段階3：Writerを接続する。 共通ハーネスで原資料を読み、overlayへ編集し、短い確定を行う。単発LLM構造化と同一モデル・費用条件で比較する。

段階4：配置を分ける。 同じAPIで複数プロセス・保存先へ分け、索引遅延、移動、競合、権限失効、ネットワーク分断を試す。Atom単位のAPIを変えずに実装する。

段階5：論文を評価で絞る。 原資料とモデルを固定し、平坦検索、階層検索、最終案を比較。意味保存再構造化、意味を変える訂正、大量の無関係情報追加を作り分ける。

測るのは必要出典の取得、重複、条件欠落、古い情報の混入、実token、構築・更新費用、実ネットワーク量、遅延、独立書込スループット。合成データはまずこの制御された変換に使う。保存構造へタスク報酬を流さない。

15. 新規性の境界

関係をAtomとして扱うことにはAtomSpace、不変な小さな記録にはDatomic、分散した論理索引にはDistributedANN、出典にはPROVという先行がある。[R1][R2][R4][R5] それらを組み合わせただけで新規とは主張しない。

本プロジェクトの検証対象は、単一の再帰Atomモデルで、意味保存の再構造化と配置変更に対する重複・更新の整合性を保ち、有限予算で文脈に必要な記憶を読み出せるか。

仕組みが有効かは、整理用プロンプトとモデルを固定して測る。効果がなければプロンプト変更でアーキテクチャの勝利を装わず、どの演算に効果があるかを切り分ける。

16. 採用しないもの

Cell、全世界のRoot、全問い合わせのbroadcast、すべての参照を同じ循環禁止辺にする方式、変更ごとの全祖先再構築、意味的類似による無条件の同一化、全Atomへの常駐agent、特定用途の成功率に基づく恒久的な集合再編成は採用しない。

View/Workspaceを語彙として禁止するのではなく、別の記憶型にしない。Atomの意味形式を一つにするために、権限・整合性・実行予算の違いを消すこともしない。

17. 一次資料

2026-09-10に確認。各資料の報告性能は再現していない。

• [R1] OpenCog AtomSpace — https://github.com/opencog/atomspace
• [R2] Datomic, Introduction / Information Model / Tradeoffs — https://docs.datomic.com/datomic-overview.html
• [R3] FoundationDB, Known Limitations / Long running transactions — https://apple.github.io/foundationdb/known-limitations.html
• [R4] Adams et al., DISTRIBUTEDANN, arXiv:2509.06046 — https://arxiv.org/abs/2509.06046
• [R5] W3C, PROV-DM — https://www.w3.org/TR/prov-dm/

要約：一種類のAtom、読む・書くの共通操作、一つのエージェントハーネス。記憶は内容と関係を保持し、読む側だけが現在の文脈に適応する。