記憶・会話・要約のデータ構造

概要

MyMemが保存する「記憶」、元の「会話の発言」、そこから作る「要約」は、別のテーブルに入ります。同じ会話に関係するデータでも、1対1の件数にはなりません。

調べたいもの	テーブル	MyMemで使う場所
保存した記憶の本文	`memory`	記憶一覧、AI記憶、検索・Personal参照
記憶を検索するための分割文	`memory_segment`	記憶の検索
記憶の元になった発言と範囲	`memory_source`	保存元の会話・前後の発言の参照
会話ごとの見出し・日時・発言数	`session_log`	Timelineの会話一覧
発言1件ずつの原文	`raw_conversation_log`	会話本文、検索、記憶の根拠、要約の入力
質問と回答の組	`conversation_pair`	Q&Aの対応・会話参照
発言の検索用ベクトル	`message_embedding`	会話の類似検索
会話単位・日単位の要約	`summary_cache`	会話を選んだ要約処理・要約の再利用
検索語と記憶の関連履歴	`query_history`	記憶検索の履歴・類似度の記録
利用者の検索・操作履歴	`ui_search_history`	検索履歴・旧保存領域から移した履歴

列と型の全体は全テーブルの列と型に掲載しています。ここでは、画面と対応を理解するための項目を説明します。

記憶を読む

memory

1行が1件の記憶です。id がMyMem内の識別子です。term は用語・見出し、content は本文、text は別の保存経路や従来形式でも使う本文列です。参照するときは COALESCE(content, text) を使うと、片方にしか本文がない記録も読めます。

memory_type は記憶の種類で、explicit_ai_memory はAI記憶を表します。source は保存元の区分です。すべての行が同じ種類のAI記憶ではありません。まず値を集計すると、自分のデータの内訳を確認できます。

SELECT memory_type, source, COUNT(*) AS row_count
FROM memory
GROUP BY memory_type, source
ORDER BY row_count DESC;

項目	意味
`memory_topic`、`lang`	話題・言語の分類
`importance`	保存した記憶の重要度。ライフサイクル全体のスコアとは別
`project_id`	所属先の `project_registry.id`。`project` は名前などの文字列で、同じものとして結合しない
`conversation_trace_id`	元の会話をたどるための識別子
`turn_message_id`	取得元・保存経路で使う発言識別子。生ログの `id` と常に同じではない
`vector`、`embedding`	類似検索用の数値配列。本文・要約・AIのモデル本体ではない
`metadata_json`	プロフィールや保存経路などの補足。含まれるキーは保存方法で変わる
`created_at`、`updated_at`	作成・更新日時

手動登録など、元の会話を持たない記憶もあります。会話IDが空であることだけで異常とは判断できません。

memory_segment

1つの記憶を検索用に分けたデータです。memory_id が memory.id、segment_text が分割した本文、embedding がその部分のベクトルです。分割文の件数と記憶の件数は異なります。

memory_source

記憶と元の会話の対応を記録します。memory_id が記憶、session_id が会話、anchor_message_id が起点の生ログIDです。start_seq / end_seq は会話内の発言順の範囲、anchor_excerpt は起点の抜粋です。anchor_hash や extraction_version は元データ・抽出方法の確認に使います。

保存元を持つ記憶を調べる例です。raw_conversation_log.id はUUID型、anchor_message_id は文字列型のため、明示的に型をそろえています。

SELECT m.id AS memory_id,
       LEFT(COALESCE(m.content, m.text, ''), 120) AS memory_preview,
       ms.session_id, ms.start_seq, ms.end_seq,
       r.role, LEFT(r.text, 120) AS source_message
FROM memory AS m
JOIN memory_source AS ms ON ms.memory_id = m.id
LEFT JOIN raw_conversation_log AS r
  ON CAST(r.id AS VARCHAR) = ms.anchor_message_id
 AND r.conversation_trace_id = ms.session_id
LIMIT 100;

対応表がない記憶は、この例の結果には出ません。結果0件が記憶0件を意味するわけではありません。

会話原文を読む

session_log

1行が1つの会話です。session_id がMyMem内の会話IDで、provider はサービス区分、provider_conversation_id は取得元サービスの会話IDです。canonical_url は保存されている会話URL、title は会話の見出しです。

started_at / last_message_at は会話の期間、message_count は管理されている発言数、last_seq_no は最後の発言順です。作成・更新日時は created_at / updated_at に別に入ります。

raw_conversation_log

1行が1件の発言です。text が保存済み原文、role が利用者・AIなどの区分です。conversation_trace_id で会話にまとまり、seq_no で会話内の順序を表します。persona_id は保存時のプロフィール識別、body_hash は本文の変化を確認する値です。

id はMyMem側の生ログID、turn_message_id は取得元などの発言IDです。外部サービスのIDとMyMem内のIDを混同しないでください。

会話名と発言を一緒に見る例です。

SELECT s.title, r.conversation_trace_id, r.seq_no, r.role,
       LEFT(r.text, 300) AS message_preview, r.created_at
FROM raw_conversation_log AS r
LEFT JOIN session_log AS s
  ON CAST(s.session_id AS VARCHAR) = r.conversation_trace_id
ORDER BY r.conversation_trace_id, r.seq_no
LIMIT 100;

ここにあるのはMyMemが取得・保存した発言です。利用したすべてのAIサービスの全履歴が必ずそろうという意味ではありません。

conversation_pair / message_embedding

conversation_pair は conversation_trace_id と user_turn_message_id / ai_turn_message_id で質問・回答の組を表します。組の表には本文列がなく、対応する raw_conversation_log の turn_message_id から原文を参照します。vector はその組の検索用表現です。

message_embedding は message_id / session_id、発言の embedding、本文確認用の body_hash を持ちます。access_count、summary_used、importance_score なども記録します。検索・要約処理の補助データで、これだけを発言の原本として読むものではありません。

要約を読む

summary_cache

会話や日付を指定して作った要約を再利用するための表です。会話の原文でも、保存済み記憶の一覧でもありません。 原文が存在しても要約処理をしていなければ、対応行がない場合があります。

項目	意味
`scope_type`	`session` は会話単位、`day` は日単位
`scope_key`	会話ID、または対象日を表すキー
`session_id` / `target_date`	対象の会話・日付。対象の種類により片方が空になる
`summary_text`	要約の本文
`content_hash`	要約の入力元が変わったかを識別するハッシュ
`summary_version`	要約の形式・処理版
`source_message_count`	その要約の入力にした発言の件数
`model`	生成方法の記録。現在の既定処理は `deterministic-v1`
`importance_score`	要約側の重要度
`created_at` / `updated_at`、`metadata_json`	作成・更新日時と補足

現在のこのキャッシュの既定経路は、保存済み発言から規則に従って要点を構成します。model 列があるからといって、すべて外部AIへ送信して生成した要約とは限りません。Editorなどで行う別の要約処理の全結果が、この表に入るわけでもありません。

同じ会話でも、入力のハッシュや処理版が異なる複数の行を持ち得ます。表の行数を会話の件数として数えたり、先頭1行を無条件に最新版と扱ったりしないでください。

SELECT id, scope_type, scope_key, session_id, target_date,
       LEFT(summary_text, 300) AS summary_preview,
       source_message_count, summary_version, model, updated_at
FROM summary_cache
ORDER BY updated_at DESC
LIMIT 100;

検索履歴を読む

query_history は query_text / query_embedding と、結果に対応する memory_id / similarity を持ちます。検索1回につき関連する記憶が複数あれば、複数行になることがあります。

ui_search_history は keyword、searched_at、activity_type、source_origin など、利用者向けの検索・操作履歴を持ちます。両表は同じ意味の重複テーブルではありません。

注意点

記憶1件・発言1件・Q&A1組・検索用分割1件・要約1件は、それぞれ違う単位です。単純合計を「記憶の総数」と扱わないでください。バックアップの版によって、列や保存経路、利用される補助テーブルは変わります。

概要​

記憶を読む​

memory​

memory_segment​

memory_source​

会話原文を読む​

session_log​

raw_conversation_log​

conversation_pair / message_embedding​

要約を読む​

summary_cache​

検索履歴を読む​

注意点​

関連ページ​

概要