開発
長期記憶の可搬性と再ベクタライズ規格
長期記憶データの移植性と再ベクタライズの技術規格
10. 長期記憶の可搬性と再ベクタライズ規格 (Memory Portability Standard)
1. 概要
本プロジェクトにおいて、長期記憶（AIチャット履歴）はユーザーの重要な資産です。特定の実行環境や Embedding モデルに縛られることなく、永続的に利用・移動可能にするための技術規格を定義します。
2. 記憶データのエクスポート形式 (.bluememory)
長期記憶をポータブルにするためのテキストベースの交換フォーマットです。
- ファイル拡張子:
.bluememory - メディアタイプ:
application/json - 設計原則:
- モデル非依存性: ベクトル（Embedding）データ自体は含まず、元となるテキストとメタデータのみを保持します。
- 自己完結性: 関連するキャラクターの名称情報などを保持し、インポート先で環境を再構成できるようにします。
2.1. データ構造 (v1.0)
{
"format": "blueperiod-memory",
"version": "1.0",
"exportedAt": "2026-03-03T12:00:00.000Z",
"sourceModel": "onnx-community/gte-multilingual-base",
"characterMap": {
"char-uuid-1": { "name": "キャラクター名" }
},
"memories": [
{
"content": "発言内容...",
"role": "user",
"timestamp": 1740000000000,
"characterId": "char-uuid-1"
}
]
}3. インポートおよび再構成プロセス
3.1. 幽霊キャラクター (Ghost Character) の自動生成
インポート時に、現在の環境に存在しない characterId が検出された場合、システムは以下の最小限の情報を持つ「幽霊キャラクター」を characters テーブルに自動作成します。
id: オリジナルのUUIDname:characterMapから取得した名称prompt: インポートされたデータであることを示すデフォルトプロンプト これにより、参照整合性を保ちつつ、未知の環境からのデータ受け入れを可能にします。
3.2. バッチ処理による再ベクタライズ
インポートされた全記憶は、インポート先の現在の設定モデルを使用して一つずつ Embedding が生成され、ベクトルインデックス（Orama）に登録されます。
4. 再ベクタライズ (Re-vectorization) 規格
Embedding モデルを変更した際、既存のインデックスを新しいモデルに適応させるための標準プロセスです。
4.1. インデックスの整合性管理
- モデルIDの保持:
vectorIndexテーブルのレコードは、生成に使用されたmodelIdを保持します。 - モデル不一致の検知: システム起動時または管理画面表示時に、現在のモデル設定と
vectorIndex.modelIdを比較します。不一致がある場合、UIを通じて「再構成が必要な状態」であることをユーザーに通知します。
4.2. 再生成アルゴリズム
- ソースデータの抽出: 旧モデルの
modelIdを指定してgetAllMemoriesを呼び出し、既存の全ドキュメントをメモリ上に展開します。 - クリーンアップ: 新しいモデル用のインデックス準備（必要に応じて旧データの退避）。
- 逐次再計算: 各ドキュメントに対して新モデルでの Embedding 生成をバッチ処理で実行します。
- 一括更新: プロセス完了後、新しいインデックスを
chat-memory-indexキーで保存し、modelIdを現在のものに更新します。
5. UI/UX ガイドライン
- 不可逆的な不安の解消: 再ベクタライズは「データの削除」ではなく「最適化/変換」であることを、Primary カラー（青系）を用いて表現します。
- 透明性の確保: 進捗状況（完了件数/総件数）をリアルタイムでプログレスバー表示します。
- ガードレールの設置: 処理中はモデルの切り替えやタブ移動を制限し、データの不整合を防止します。