AIメモリの基盤: SAIHMの下にあるもの

Posted at 2026-07-09

ベンダー記憶障害モード

過去12ヶ月間にリリースされたほとんどのAI記憶機能は、ベンダー内に存在します。モデルプロバイダーのサーバー内、認証の後ろ、保持ポリシーに従って、請求システムによって終了されます。その方法は、以下のいずれかが発生するまで機能します。

ベンダーが保持ポリシーを変更する。
ベンダーが記憶製品を非推奨にする。
別のモデルに移行するが、記憶が一緒に移行しない。
規制当局が消去の証明を求め、ベンダーが証明を提示できない。
監査員がエージェントがいつ何を知っていたかというタイムラインを求め、ベンダーが提示できない。

解決策は、ベンダーを改善することではありません。解決策は、ベンダーのスタックから記憶を外し、エージェントの所有者が制御できる、任意の当事者が検証できる、ベンダーに依存しない「基盤」に移行することです。

ここで「substrate」とは何か

SAIHMプロトコルは、8つのツール、アイデンティティスキーム、消去レシート、監査アンカー形式で構成される契約です。 substrate は、この契約が実行される物理インフラストラクチャです — 監査アンカーを記録する台帳、暗号化されたセルデータを保持するストレージネットワーク、エージェントのアイデンティティが導かれる鍵素材です。

この区別は重要です。なぜなら、プロトコルは依存する部分であり、substrate は入れ替えることができる部分だからです。

サブストレートが行わなければならない4つのジョブ

生産レベルのAIメモリをホストしたい任意のサブストレートは、独自のエンジニアリング制約を持つ4つのジョブを行わなければなりません。

アイデンティティのアンカー。エージェントのアイデンティティは、エージェント所有者が制御するキーマテリアル（ウォレット、HSM、KMS）から導出可能であり、ベンダーを信頼せずに第三者に証明可能でなければなりません。これは、ウォレット由来のキー + HKDFチェーンが役立つ場所です。
監査のアンカー。各メモリ書き込みには、規制当局、監査員、またはカウンターパーティがタイムラインをベンダーを再信頼せずに検証できるように、公開された、追記のみの台帳上に改竄証拠のタイムスタンプが必要です。最終性は妥当でなければならないため、書き込みごとのコストは、すべてのセルをアンカーすることが経済的に可能である程度低くなければなりません。
暗号文のストレージ。暗号化されたセルコンテンツは、コンテンツハッシュによってアドレス指定できる、耐久性、分散性、かつ任意の当事者が正しいキーでフェッチできる場所に保存されなければなりません。また、キーを持たない当事者はランダムなバイトのみを表示する必要があります。
消去の証明。ユーザーが消去権を呼び出したとき、サブストレートはプロトコルが唯一の復号化キーを破壊し、保存されたバイトを提供するのを停止するようにする必要があります。さらに、規制当局が公開された台帳に対して検証できる改竄証拠のレシートを生成します。

ジョブごとの候補地図

さまざまな基盤の選択は、さまざまなジョブをうまくまたは悪く満たします。

ID（識別子）：成熟したウォレットツールを備えた任意のチェーンが機能します。ETH、BTC、EVM L2s、Solana、Cosmos、Substrateファミリーチェーン、COTI V2 — すべて「エージェントが自分のキーを所有する」プリミティブに適しています。
監査アンカー：低コストの書き込みと妥当な最終性が必要です。Ethereum L1は、大規模にすると高額になります（各セルのmintには実際のドルがかかります）。L2ロールアップは安いですが、ロールアップのデータ可用性の仮定を継承します。安いL1とアプリケーションチェーンは、候補者セットを拡大します。
暗号文ストレージ：分散型、コンテンツアドレッシングネットワークは、明らかなオープンな候補者です。永久性志向（不変）のネットワークは、技術的には候補ですが、その永久ストレージモデルは、削除権の要件と矛盾します（不変のコンテンツ識別子をブラックリストすることはできません。そういうネットワークは、忘れないように設計されています）。中央集権的なオブジェクトストア（S3 / GCS / Azure Blob）も機能しますが、保管層を再導入します。
消去証明：基盤そのものの特性ではありません — プロトコルの鍵管理規律の特性です。小さな書き込みが可能な任意のチェーンは、墓石を記録できます。プロトコルが墓石の意味を決定します。

4つのジョブすべてで明らかに優れた単一の基盤はありません。正直な答えは：制約を満たす組み合わせを選択し、その選択を文書化して、他の人が監査できるようにします。

SAIHMのデプロイメントの選択

SAIHMのリファレンスデプロイメントは、COTI V2 mainnetをアイデンティティと監査アンカーとして使用し、分散型、消去可能なストレージ階層を暗号化されたセル暗号文として使用します。理由は狭く、エンジニアリングのみです。

プロトコルレベルのネイティブプライバシープリミティブ。COTI V2は、ウォレット由来の暗号化キーとプライベートデータ計算プリミティブをサポートしており、これにより、SAIHMエージェントのアイデンティティHKDFチェーン(MPS-PQC-KEY-GEN-v1 → MPS-AGENT-IDENTITY-v1)が、機密キー素材をオンチェーンに配置せずにエージェントに監査レコードを結び付けることができます。
アンカーあたりのコストが、各セルをアンカーできる程度に低い。SAIHMは、1つのトランザクションを1つのメモリセルにつき作成します。コスト上限は重要です。Ethereum L1の価格では、このワークロードは実行可能ではありません。サブストレートは、各セルのアンカーを経済的に定常的にする必要があります。
EVM / Solidityの表面がない。SAIHMのプロトコルコードには、EVMへの依存関係はありません — ethers.jsも、Solidityコントラクトもありません。サブストレートは、ネイティブのJSON-RPCを介して操作されます。これは、意図的なプロトコル設計の選択です（攻撃表面が小さく、Solidityバージョンの変更がない、EVMガス価格への依存がない）。
消去可能なストレージ階層、永久保存志向のものではない。永久保存志向（不変）のネットワークのストレージモデルは、GDPRの第17条の削除権と互換性がありません。SAIHMは、キー破壊後にセルを提供しないストレージ階層が必要です。そこで、再取得は不可能になります。消去可能なネットワークのインセンティブモデルはそれをサポートしますが、不変なネットワークのものはサポートしません。

この選択は、戴冠ではなく、トレードオフです。異なるサブストレートの組み合わせで4つのジョブを満たすSAIHMのデプロイメントは、依然としてSAIHMです — プロトコルの契約は変更されません。

ポータビリティの重要性

これらの要素を結び付けてみましょう: サブストレートはデプロイメント構成であり、プロトコルは荷重を負う表面です。もしCOTI V2が明日消滅しても、SAIHMのプロトコルは消滅しません; その代わりに、同じ4つのジョブを満たすサブストレートの組み合わせに基づいて新しいデプロイメントが立ち上がり、契約表面はアプリケーションや規制機関に提示されるままであります。

これは、SAIHMだけではなく、どのAIメモリ製品を評価する場合にも重要です。

アージェントを構築している場合: メモリプロトコルとサブストレートを独立して考えてください。両方にロックインすることは問題です; 両方にロックインすることはそれ以上の問題です。
CISOまたはDPOの場合: ベンダーからサブストレートのストーリーを尋ねてください。 —Auditレジスターは何ですか? —暗号化されたデータストアは何ですか? —消去不能メカニズムは何ですか? —それらのいずれかが変更された場合のマイグレーションストーリーは何ですか?
規制機関の場合: サブストレートは黒箱ではありません。 —Auditアンカーは公開されています; —候補レジスターは詳細にドキュメントされています; —自分でチェーンの受領証を検証できます。

自分で基盤を評価する方法

4 つのジョブについて、それぞれに以下の質問をします：

アイデンティティ: エージェントの所有者は、ベンダーを信頼せずにキーを導出してローテーションできますか？導出プロセスは監査可能ですか？
監査アンカー: 1 回の書き込みあたりのコストは何ですか？確定までのタイムラインは何ですか？チェーンは公開されており、第三者のエクスプローラーによってインデックス可能ですか？
暗号文: コンテンツはハッシュによってアドレス指定されていますか？ストレージネットワークは分散されていますか？キーが破壊されたときに、CID をフェッチ不能にすることができますか？
消去: プロトコルは唯一のキーを破壊するのでしょうか、またはデータをテーブルに削除としてマークするだけですか？消去レシートはどこに保存されますか？調整官は、オペレーターの協力なしで、公開台帳に対してそれを検証できますか？

ベンダーがこれらの質問のうちの 1 つに答えることができない場合、基盤のストーリーは不完全です。

試してみて: ドロップインメモリ契約

これが違いを感じる最も速い方法です。以下のコードをエージェントのシステムプロンプトに貼り付けてください — これは、SAIHM MCP ツール saihm_recall / saihm_remember / saihm_forget がハーネスに接続されていることを前提としています。以下のコードが節約を生み出すのです:


## メモリ契約

毎回のターン前に：
1. 再呼び出し（RECALL）を行い、再読み込みは行わない。タスクのキーワードで `saihm_recall` を呼び出して、制限されたセルのセットをロードする。以前のターンの内容を再送信してはならない。再呼び出しによってロードされたセルがコンテキストである。
2. 現在の事実を優先する。再呼び出しによってロードされたセルが矛盾する場合、最も新しい／上書きされていないものが優先される。後で上書きされた決定に基づいて行動してはならない。
3. 堅牢に記憶する。決定、規約、制約をセルとして永続化するために `saihm_remember` を呼び出す。各事実を1つのセルに記録し、自身の言葉で表現する。
4. 「データの削除」を要求された場合、該当するセルに対して `saihm_forget` を呼び出す。削除はレコードごとに行われ、証明可能である。ソフト削除ではない。

制限付きの再呼び出しにより、再送信のカーブが O(N²) から O(N·cap) に減少する。[オープン ベンチマーク](https://saihm.coti.global/blog/2026-06-23-token-benchmark-agent-loops) では、62.8–85.9% 少ないコンテキスト トークンが示されている。小さな再呼び出し制限から開始し、再呼び出しにミスが発生した場合のみ、制限を上げる。

_**独立性に関する通知。**_ SAIHMは、Apache-2.0プロトコルであり、独立して作成されたものです。COTI、Ethereum、Solana、Cosmos、またはこの投稿で名前の挙がるその他の台帳、ストレージ ネットワーク、またはクラウド プロバイダーとは無関係です。この投稿でこれらの技術に関する説明は、技術的な特性を示すものであり、推奨や支持を意味するものではありません。説明されている基盤の組み合わせは、プロトコルの契約の要件ではなく、参考として示されているものです。コンテキスト トークンの削減（長いセッションでは約80%）は、[オープン ベンチマーク](https://github.com/citw2/saihm-token-benchmark) で独立して再現可能であり、使用パターンによって異なります。規制に関する引用（GDPR 第17条）は、公開時点でのものであり、ご自身の管轄区域への適用については、弁護士に相談してください。

---
_元の投稿は [SAIHM ブログ](https://t.saihm.coti.global/r/qiita-c72fb4bb) にて 2026-05-21 に公開されました。SAIHM は、Sovereign AI Horizontal Memory プロトコルであり、Apache 2.0、オープン仕様は [saihm.coti.global](https://saihm.coti.global) で公開されています。_

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up