過去の情報を役立てながら、訂正や削除を確実に反映するには？
まず図全体の流れを見て、細部は「原寸で読む」を開いて確認してください。原寸の図は横にスクロールできます。正常な流れの次に、失敗時の分岐を追いましょう。
記憶は一つの箱ではない
AIのメモリという言葉には、保存した会話、今回モデルへ渡す文脈、抽出した好み、検索索引、キャッシュが混在します。これらの責任を一つにすると、「訂正したのに古い情報で答える」「削除した記録が要約から復活する」という問題を説明できなくなります。本章は学習用の参照設計で、Kumyuの実運用を示すものではありません。
設計の出発点は、何を正本にするかです。ここでは会話と明示的な利用者設定を正本、要約と埋め込みを再生成可能な派生物にします。モデルへ渡す文脈（context）は一回の推論の入力であって、永続DBそのものではありません。ベクトル索引も意味的に近い候補を探す装置で、所有権や事実の正しさを保証する装置ではありません。
全体像：正本から必要な文脈を組み立てる
原寸で読む（横にスクロール）
図1は独自の概念図です。矢印は、正本から派生物とモデル入力を作る経路、および削除を伝える経路を示します。リクエストごとに利用者、会話、目的を確定し、その範囲で検索します。検索後も取得元の所有者と削除状態を確認します。検索条件の入れ忘れ一つで他人の記録が混ざる設計にはしません。
文脈の予算は有限なので、最近の発言、関連する確定設定、出典付き要約を優先します。関連度が高くても古い訂正前の設定は採用しません。「すべてを渡す」以外にも、必要な資料だけを取得するRAGがあります。どちらでも選んだ情報の出典とバージョンを実行記録に残すと、回答の原因を追えます。
状態とスキーマ：要約には出典の範囲を持たせる
原寸で読む（横にスクロール）
図2で大切なのは、原文取得と要約公開の間に利用者の編集が入り得ることです。長いモデル呼び出しの間、DBトランザクションを保持しません。最初にバージョンを取得し、生成後に現在版との一致を確認して公開します。古ければ破棄し、必要なら作り直します。
{
"memory_id": "memory-example",
"owner_id": "user-example",
"source_version": 12,
"source_range": [1, 80],
"summary_version": 3,
"expires_at": "2026-11-23T00:00:00Z",
"state": "active"
}
これは未実行のスキーマ例です。source_rangeはどの発言を要約したか、source_versionは編集前後を区別します。要約は情報を落とす変換なので、原文と同等の証拠として扱いません。抽出した設定は利用者の明示指定と推測を区別し、競合時は明示指定を優先するという方針も必要です。
同時更新への対応は分離レベルに依存します。PostgreSQLの分離レベルを確認し、アプリケーションの不変条件に合う更新条件を選びます。この設計ではUPDATE ... WHERE version = expected_versionの件数で競合を検知します。古い読み取り結果で無条件上書きしないことが要点です。
障害：削除と再生成がすれ違う
原寸で読む（横にスクロール）
図3では削除要求が最初に正本の状態を変えます。物理削除が終わるまで、読み取りは削除済みの状態を確認して候補を除外します。削除イベントを非同期処理へ送り、索引、要約、キャッシュを順に消します。各派生物について完了を記録し、未完了を再試行します。
特に危険なのが、削除前に始まった要約ジョブです。生成が後から完了しても、削除世代やsource_versionが変わっていれば公開を拒否します。キャッシュキーにも利用者と元データの版を含め、存在確認だけで認可を省略しません。
TTLは保持期限であり、削除要求の代替ではありません。期限切れの確認を読み取り時にも行い、掃除処理の遅れで利用されないようにします。バックアップ、監査記録、外部サービスへ送ったデータは別の保持契約になります。利用者へ何をいつ消すかを説明できる粒度で管理します。これは本章の設計方針であり、特定法域の法的要件を示していません。
選択肢を比較する
| 記憶の形 | 得意なこと | 設計上の注意 |
|---|---|---|
| 原文DB | 訂正・監査・再生成 | 取得量と保持期間を管理する |
| 要約 | 文脈を短くする | 情報損失と更新遅延がある |
| ベクトル索引 | 類似する内容を探す | 検索後の権限・鮮度確認が必要 |
| キャッシュ | 同じ取得を減らす | 古い値と越境参照を防ぐ |
設計例：文章の好みを覚える
利用者が「説明は短く」と指定した後、「調査記事は詳しく」と訂正したとします。単純な一行の好みで上書きせず、用途を持つ設定として保存します。scope=researchとscope=defaultを分け、該当範囲が狭い設定を優先します。モデルが会話から推測した「いつも短文が好き」は確認待ちの候補にとどめます。
要約を評価する際は、短縮率だけでなく、重要な否定条件、訂正、数値、未決事項が残ったかを見ます。回復手順として原文へ戻れるリンクを持たせます。一貫性の強さはすべて同じでなくてよいが、削除と権限は回答へ出す直前の判定に含めます。
練習と解答
利用者が会話を削除した直後、古い会話から作っていた要約ジョブが完了しました。保存先に同じIDがなければ、新規作成してよいでしょうか。
作成してはいけません。削除による不在と、まだ作成されていない不在を区別する墓標または世代を確認します。jobの元バージョンが失効していれば結果を破棄します。正本の削除、派生物の削除、生成中処理の失効という三つを組み合わせて、記憶が復活する経路を閉じます。
押さえたいポイント
正本と派生物を区別し、バージョンと削除の伝播を設計する。
出典・さらに読む
- PostgreSQL 18: Transaction isolation内容の確認日: 2026-10-23
- PostgreSQL 18: Constraints内容の確認日: 2026-10-23
学習と設計検討のための概念的な構成例です。稼働中のKumyuの実装を表す図ではありません。