プロジェクト・資料・スキルのデータ構造

概要

プロジェクトの名前、登録した資料の本文、検索のために分割した文は、それぞれ別の表に保存します。資料が1件でも検索用の分割文は複数になるため、テーブルの行数は一致しません。

project_registry（プロジェクト）
  ├─ project_session_link ─ session_log（会話）
  ├─ project_source（資料の見出し）
  │    ├─ project_source_content（本文・URL・ファイル名）
  │    └─ project_source_chunk（検索用の分割文）
  ├─ memory（記憶）
  └─ skills（スキル）

この図はIDによる論理的な対応です。ダンプ内に外部キー制約があることを意味しません。各列の型は全テーブルの列と型で確認できます。

プロジェクトと会話

テーブル	主な項目と役割	MyMemで使う場所
`project_registry`	`id` がプロジェクトID。`name`、`description`、`color`、`icon`、`status` は見出しや表示。`memory_scope` は記憶の範囲設定	プロジェクト一覧・選択・カード
`project_session_link`	`project_id` と `session_id` を結ぶ。`pinned` は会話の固定、`added_at` は関連付けた日時	プロジェクト内の会話一覧
`provider_conversation_bindings`	`provider` と `conversation_key` に対する `project_id`、`conversation_url`	Webチャットの会話を対応するプロジェクトへ割り当てる処理

project_registry.id と、各表の project_id を対応させます。プロジェクト名は変更できるため、名前の一致だけで結合しないでください。provider_conversation_bindings のサービス側の会話キーと、MyMem内の session_log.session_id も別の識別です。

プロジェクト名と登録資料を一緒に見る例です。

SELECT p.id AS project_id, p.name AS project_name,
       s.id AS source_id, s.title, s.source_type,
       c.file_name, c.source_url,
       LEFT(c.body_text, 200) AS body_preview
FROM project_registry AS p
LEFT JOIN project_source AS s ON s.project_id = p.id
LEFT JOIN project_source_content AS c ON c.source_id = s.id
ORDER BY p.name, s.created_at
LIMIT 100;

LEFT JOIN のため、資料が未登録のプロジェクトも表示します。プロジェクト未指定の資料や記憶は、この例だけでは一覧できません。全資料を見たい場合は project_source を直接参照します。

資料の見出し・本文・検索用データ

project_source

資料の見出しを管理します。id が資料ID、project_id が所属先、source_type が資料の種類、title が表示タイトルです。作成・更新日時も記録します。MyMemの「情報源」で並ぶ資料を調べる入口です。

project_source_content

source_id が project_source.id に対応し、body_text に保存本文、source_url に取得元URL、file_name にファイル名、metadata_json に補足を持ちます。

保存本文は、取り込んだファイルからの抽出結果や編集後の本文です。元のPDFやその他のファイルの全バイトが、必ずそのまま入るという意味ではありません。画像等の補助情報が metadata_json に入る場合もあります。

project_source_chunk

資料を検索用に分割した表です。source_id は資料ID、chunk_index は資料内の分割順、content は分割した本文、vector は類似検索用の数値配列です。

列	参照すると分かること
`parent_heading`、`block_type`	元の見出し・ブロックの種類
`retrieval_text`	検索向けに文脈を補った文章。資料本文そのものとは区別
`document_title`、`section_path`	資料名と節の経路
`display_group_id`、`display_group_type`	検索結果の表示をまとめるための区分

「資料がある」「分割文がある」「現在の検索モデルで使えるベクトルがある」は別の状態です。資料の登録件数と分割件数を確認する例です。

SELECT s.id, s.title, COUNT(c.id) AS chunk_count
FROM project_source AS s
LEFT JOIN project_source_chunk AS c ON c.source_id = s.id
GROUP BY s.id, s.title
ORDER BY chunk_count DESC;

分割文が0件でも、本文がないとは限りません。検索準備やモデルとの対応は検索・管理用データも確認してください。

スキル

skills

1行が1つのスキルです。title / description が見出しと説明、body_markdown が手順や知識の本文です。tags、when_to_use、when_not_to_use は分類や利用条件をJSONで持ちます。

列	意味
`project_id`、`scope_type`、`scope_value`	所属先と利用する範囲
`status`、`enabled`	下書きなどの状態と有効・無効
`source`、`confidence`	作成経路・確認の区分
`danger_level`、`requires_confirmation`	操作の扱い・確認が必要かという設定
`version`、`reviewed_at`	スキルの版と確認日時
`created_at`、`updated_at`	作成・更新日時

行が存在することだけで、そのスキルが現在の会話に必ず適用されるわけではありません。有効状態・スコープ・利用条件をあわせて確認します。MyMemでの操作はスキルを参照してください。

アバターに割り当てた知識

avatar_knowledge_assignment

アバターの一覧ではなく、資料・会話・記憶・スキルを、どのアバターの知識として扱うかという対応表です。

列	意味
`resource_kind`	`source` は資料、`timeline` は会話、`memory` は記憶、`skill` はスキル
`resource_id`	対象の資料ID・会話ID・記憶ID・スキルID
`avatar_ids`	割当先アバターIDのJSON配列。`shared` は共有区分
`updated_at`	割当を更新した日時を表す文字列

resource_kind と resource_id を組み合わせて対象を識別します。resource_id だけでは、どのテーブルを見ればよいか決まりません。アバターの名前・性格・画像などのプロフィール本体は、ZIP内のプロフィールJSON・設定にも保存します。

思考マップと解析

テーブル	内容と使う場所
`memrag_human`	Human側の思考マップの点・段階・説明
`memrag_ai`	AI側の思考マップの点・段階・説明
`thinking_analysis`	解析依頼の状態、根拠、結果、失敗・再試行などの履歴
`memrag_domain`	領域・会話に関する分析内容を持つ形式。現在の解析履歴すべての代わりにはならない

memrag_human と memrag_ai は、conversation_trace_id / turn_message_id が元の会話・発言、ui_flow_id / step_index が流れと段階です。x / y / mountain_id は地形上の配置、label / description / note は説明、default_perspectives / sub_route / why / stance は構造化情報です。mmcode_hash は元になる表現の識別に使います。timestamp を、バックアップ取得時刻のUNIX時刻だと決めつけないでください。

thinking_analysis の status、attempt_count、error_code / error_detail は処理状況を示します。summary と raw_structured_result が解析結果、evidence_manifest / retrieval_trace は参照根拠、limitations は制約の記録です。actor はHuman／AIなどの解析対象の区分です。

analysis_version / schema_version / prompt_version / scope_policy_version、analyzer_provider / requested_model / reported_model などは、どの条件で解析したかを確認する項目です。event_id / branch_id / revision、source_message_hash、previous_analysis_id / supersedes_analysis_id は、元の発言・再解析・履歴の対応に関係します。next_attempt_at / lease_owner / lease_expires_at / cancel_epoch は処理を管理する情報で、利用者向け本文ではありません。

解析中や失敗の行では、結果本文が空でも不自然ではありません。また、ここでの summary は思考解析の要点で、会話の要約キャッシュ summary_cache と別です。画面の使い方は思考マップを参照してください。

注意点

IDは、テーブル名・列名と組み合わせて読みます。project_id、session_id、resource_id など、名前が似た列をすべて直接結合できるわけではありません。1つの資料に複数の分割文、1つの発言に複数回の解析があるため、結合後の行数が増えることもあります。

概要​

プロジェクトと会話​

資料の見出し・本文・検索用データ​

project_source​

project_source_content​

project_source_chunk​

スキル​

skills​

アバターに割り当てた知識​

avatar_knowledge_assignment​

思考マップと解析​

注意点​

関連ページ​

概要