データベースモデル
AI スタックがデータをどこにどんな形で持つかを整理した文書です。ストレージは四つあり、 それぞれ役割が異なります。運用手順は データベース管理 を参照してください。
PostgreSQL・Aster TSDB は PlantPulse プラットフォームのインストール分を共用で使います。AI スタックが自分の DB を立てるわけではありません。そのため「AI バックアップ」と「プラットフォームバックアップ」が重なります — どちらが何を 受け持つか整理しておかないと、両方とも漏れる区間が生じます。
| ストレージ | 所有 | 格納するもの |
|---|---|---|
PostgreSQL pi · スキーマ co | AI（プラットフォーム PG 内の別DB） | チャット・インシデント・設定・MCP（コパイロット） |
PostgreSQL pi · スキーマ dt | AI（〃） | 外部システムコネクタ登録簿・バインディング・行動記録（デジタルスレッド） |
PostgreSQL lightrag | AI（〃） | LightRAG の文書処理状態（PGDocStatusStorage） |
PostgreSQL rag_ingest | AI（〃） | 文書投入パイプライン（rag-api）の状態 — 下記「PostgreSQL rag_ingest」 |
PostgreSQL litellm | AI（〃） | LiteLLM ゲートウェイのキー・使用量 |
Aster TSDB pi | AI | フィーチャーストア・異常検知の算出物 |
Aster TSDB pp | プラットフォーム（読み取り専用） | 原始センサー・アラーム・OEE |
Neo4j plantpulse-neo4j | AI | LightRAG ナレッジグラフ |
Neo4j plantpulse-digital-thread-neo4j | AI | デジタルスレッドの工場グラフミラー — 参照のみ |
| Qdrant | AI | 文書埋め込みベクトル |
lightrag-storage ボリューム | AI | LightRAG の KV キャッシュ — ローカル JSON ファイル |
lightrag-inputs ボリューム | AI | アップロードされた原本文書 |
AI は自分の PostgreSQL を立てず、プラットフォームの PostgreSQL を使います。その中に
pi · lightrag · rag_ingest · litellm の四つの DB を作って（provision-platform-db.sh が
冪等に）使います。pi は AI アプリ群が共用する DB で、アプリごとにスキーマを一つ持ちます（co コパイロット ·
dt デジタルスレッド）。2026.09 以前の DB ch は起動時に pi.co に移されます →
データベース管理 Aster TSDB · Valkey · RustFS · MQTT ブローカー（設備アラーム購読）も同様にプラットフォームのものを付けて使います —
AI ボックスをサイジングする際はこの四つを別枠で見積もらないでください。
PostgreSQL pi.co — 会話と運用状態
プラットフォーム PostgreSQL 内の別データベース pi のスキーマ co です
（jdbc:postgresql://<platform-host>:5432/pi?currentSchema=co）。コパイロットはこのスキーマ一つだけを見て接続するので、
スキーマを付けていないテーブル名はすべて co になります。
ch と同じテーブルです以前は DB ch の public にあったテーブルです。名前も形もそのままで、場所だけ pi.co に移りました。
| グループ | テーブル |
|---|---|
| 会話 | chats · chat_messages · prompts · prompt_history — chats.context は会話に固定した文脈（2026.10 再リリース） |
| チャット行動 · 回答品質（2026.10 再リリース） | chat_action（チャット回答に載った草案提案1枚＝1行 — 誰が・いつ・なぜ承認したか）・chat_turn_metric（回答したターンごとの遅延・トークン・モデル・引用数・根拠種類・👍👎、および結果マーク outcome — 空なら正常回答、no_answer 再試行しても空の回答、loop_cut 繰り返しを打ち切り）・chat_bench_run（ベンチ回次スコア） |
| ユーザー | users · user_roles · employees · web_push_subscription — employees.work_role は管理者が定める業務ロール（承認権限）、employees.home_role は旧画面で本人が選んでいた開始画面（2026.10 再リリース3 — 新しい画面では使いません）→ 業務ロール |
インシデント（テーブル名は incident のまま） | incident · incident_event · assignees |
| ウォッチ（条件監視 — 廃止された機能） | watch · watch_run。画面刷新版からは作成も使用もしません。旧インストールにあったテーブルはそのまま残ります |
| 異常検知運用 | anomaly_mute · hourly_anomaly · asset_tag_profile |
| MCP · ツール | agent_tool_call_log — 人が承認した行動であれば approved_by に承認者が残ります。旧テーブル mcp_server · mcp_tool_pref · mcp_tool_call_log は 2026.10 再リリース(2026-10-20) で起動時に削除されます — サーバー · オン/オフ · 呼び出し記録の正本は MCP ゲートウェイ DB(pi の gw スキーマ)です |
| 公開 API | api_key |
| 設定 | config · config_audit_log · metadata |
上記「2026.10 再リリース」テーブルとカラムはコパイロット起動時に CREATE TABLE IF NOT EXISTS · ADD COLUMN IF NOT EXISTS で
作成します。手動で実行するマイグレーションはありません。 chat_turn_metric には質問・回答原文はなく（原文は
chat_messages）、chat_action には音声・回答本文はありません — ツール引数と結果番号のみです。
agent_tool_call_logAI が呼び出したツールは一件も漏れずにここに残ります — 時刻・ユーザー・セッション・ツール名・
出所 MCP サーバー・引数（秘密値は *** で隠す）・結果（ok · error · denied）・所要時間。
denied は承認ゲートが阻止した変更ツール呼び出しです → MCP
mcp_tool_call_log は登録 MCP サーバー別の成功・所要統計のみなので、「誰が何を」はこのテーブルで確認します。
api_keyキーの平文は保存しません — ハッシュ（key_hash）と識別用の先頭文字（key_prefix）のみ保持します。
失効させても行は削除せず revoked_at を記録します。last_used_at が空であれば使われていない
キーです → コパイロット管理コンソール
2026-07 改編前は Aster TSDB にも会話履歴がありました。今は**chat_messages
単一ソース**です。古い文書を見て Aster TSDB で探さないでください。
PostgreSQL pi.dt — デジタルスレッド登録簿
デジタルスレッド API が所有するスキーマです。テーブルはサービス起動時に作成します。すべての文が dt. に
限定されており、他のスキーマには触れません。
| グループ | テーブル |
|---|---|
| コネクタ | dt_connector · dt_connector_tool |
| バインディング | dt_binding · dt_binding_log（運用者が定めたカラムバインディングとその変更記録 — 誰が・いつ・前後） |
| 行動記録 | dt_action_log（承認を経て外部システムに送信した草案・要請） |
| Episode | dt_episode · dt_episode_label |
| 同一性宣言 | dt_identity · dt_identity_log（「この現場でキー A とキー B は同じものである」という運用者宣言とその変更記録 — 自動では付与されません） |
dt_connector の資格情報は PI_DT_SECRET_KEY で封印して保存されます。このキーを失うと DB を復旧しても
保存された資格情報が使えず、コネクタごとに再入力が必要です。ホストの env ファイルをバックアップする際に合わせて確保してください
→ デジタルスレッド
PostgreSQL rag_ingest — 文書投入状態
rag-api が所有する DB です。テーブルは rag-api 起動時に作成します（冪等）。
| グループ | テーブル | いつ生成されるか |
|---|---|---|
| 同期 | rag_asset_doc_sync · rag_sync_run · rag_asset_card | 常に |
| 図面 | rag_drawing_doc · rag_drawing_chunk · rag_drawing_ident · rag_drawing_dim · rag_drawing_kg · rag_drawing_outbox | DRAWING_INGEST_ENABLED=true のときのみ |
| 映像 · 音声 | rag_media_job · rag_media_segment · rag_media_sidecar | 映像・音声を有効化したインストール（PI_MEDIA_ENABLED=true — rag-api 内では MEDIA_INGEST_ENABLED=true）のみ |
rag_drawing_doc.sourceは図面がどこから来たかです — 管理コンソールからアップロードされたもの（MANUAL）と、プラットフォームの資産文書を取り込む同期が 入れたもの（PLATFORM、2026.10 再リリース3）。後者はプラットフォームが正本なのでコンソールから上書き・削除しません。rag_drawing_dimは寸法一行ごとに上下限（upper_limit·lower_limit）とその根拠（limits_basis— 図面に記載された値か、 はめあい公式で計算した「公式推定」か）を持ちます。rag_media_jobは映像・音声ファイル一本＝一行です（どこから来たかsource・処理状態・試行回数・サムネイル数など）。管理コンソールの RAG › 索引 › 動画画面がこれを表示します → 動画 · 音声検索
図面原本の構造・プレビューと映像の書き起こしはテーブルではなくオブジェクトストレージバケット plantpulse-rag に置きます →
データベース管理
Aster TSDB pi — フィーチャーストア
時系列インサイトサービスが所有・生成する12個のテーブルです。接頭辞は tsi_ です。
| グループ | テーブル |
|---|---|
| フィーチャー | tsi_tag_feature_hourly · tsi_tag_feature_daily · tsi_asset_feature_hourly · tsi_asset_feature_daily |
| 文脈·プロファイル | tsi_asset_context_daily · tsi_asset_profile |
| 異常·故障 | tsi_anomaly_embedding · tsi_failure_signature · tsi_precursor_alert |
| パイプライン | tsi_pipeline_status · tsi_pipeline_history · tsi_backfill_status |
テーブルはサービス起動時に冪等生成します。ただしキースペース pi 自体はアプリが作成し
ません — インストールスクリプト（provision-platform-db.sh）の管轄です。
管理コンソールの異常検知・予測画面はすべてこれらのテーブルを読みます。結果が空であれば、モデル ではなくパイプラインをまず確認してください → 管理コンソールの Pipeline Status Run History（AI 管理コンソール）。
コパイロットも pi に自分のテーブルを置きます（朝のカードなど）。2026.10 再リリースで構造化レポートの対応チェック状態を持つ
PI_NAVIGATOR_ACTION_CHECK が追加され、コパイロット起動時に作成されます。
pp.ti_* はありません2026-07-30 に pp キースペースから pi に移し、旧テーブルは DROP しました。
旧名で照会しても出てきません。
Aster TSDB pp — プラットフォーム原始データ（読み取り専用）
AI はプラットフォームが収集したデータを読むだけです。ここには書き込みません。
| テーブル | 用途 |
|---|---|
tm_asset_data_based_second / _minute / _hour | 設備センサー時系列 |
tm_tag_point | タグポイント |
tm_asset_alarm | アラーム |
tm_kpi_oee_history | OEE |
tm_kpi_ram_history · tm_kpi_ems_history | RAM · EMS |
tm_monitor_platform_status | システムリソース（CPU・メモリ・ディスク） |
パーティションキーが解像度ごとに異なります
second : PRIMARY KEY ((asset_id, date, hour), timestamp)
minute : PRIMARY KEY ((asset_id, date), timestamp)
hour : PRIMARY KEY (asset_id, timestamp)
kpi : PRIMARY KEY ((asset_id, day), timestamp) -- tm_kpi_*_history
KPI 履歴（tm_kpi_*_history）の day は UTC 日付（yyyymmdd）です。現地の一日は UTC
バケット二つにまたがるため、期間を UTC 日付のリストに展開してバケットごとに読みます。1行はその時刻までの
オーダー累計なので行を加算しません。 詳細なルールは
KPI テーブル にあります。
秒単位は設備・日付・時刻までパーティションに入ります。長期間を秒単位でスキャンするとパーティションを
数千個触ることになります。広い期間は _hour、狭い期間のみ _second で見てください。
プラットフォーム側の全体スキーマは プラットフォームデータベースモデル にあります。
Neo4j · Qdrant — ナレッジグラフとベクトル
| ストレージ | 格納するもの |
|---|---|
Neo4j（plantpulse-neo4j） | LightRAG のナレッジグラフ — 文書から抽出した個体・関係 |
| Qdrant | 文書チャンクの埋め込みベクトル |
デジタルスレッドの工場グラフミラーは別の Neo4j インスタンス（plantpulse-digital-thread-neo4j）にあります。
LightRAG のストレージではないため、以下の「四つ」には含まれません。
RAG エンジン（LightRAG）のストレージは四つに分かれています。 二つしか把握していないと復旧が食い違います。
| 何 | どこ | 設定 |
|---|---|---|
| ベクトル | Qdrant | LIGHTRAG_VECTOR_STORAGE=QdrantVectorDBStorage |
| グラフ | Neo4j | LIGHTRAG_GRAPH_STORAGE=Neo4JStorage |
| KV キャッシュ | lightrag-storage ボリュームのローカル JSON | LIGHTRAG_KV_STORAGE 未設定 — LightRAG デフォルト値（JsonKVStorage） |
| 文書処理状態 | プラットフォーム PG の lightrag DB | LIGHTRAG_DOC_STATUS_STORAGE=PGDocStatusStorage |
KV がローカル JSON なのは意図的にそうしてあるものです — インスタンス1台には十分で、
プラットフォームの Valkey に依存しなくても構いません。複数台に拡張する際は
LIGHTRAG_KV_STORAGE=RedisKVStorage + REDIS_URI に切り替えます。
文書処理状態のみ PostgreSQL にあります。PG だけ復旧して Qdrant・Neo4j を空のままにしておくと、 LightRAG は「すでに投入済みの文書」として扱い、再投入しません — 検索はずっと空手で 返ってきます。逆にグラフ・ベクトルだけ復旧すると状態が合わず、重複投入が発生します。
戻す際は四つを同じ時点に揃えるか、四つをすべて空にして原本から再投入してください。
原本は lightrag-inputs ボリュームにあります — このボリュームが事実上のバックアップであり、
これまで失うと索引を再生成する方法がありません。
オントロジーの概念は オントロジーを理解する を参照してください。
バックアップ範囲の整理
| ストレージ | 誰が取るか | ないとどうなるか |
|---|---|---|
PostgreSQL pi（co · dt） | AI 側で確保する必要あり | チャット・インシデント・設定、コネクタ登録簿が消える |
PostgreSQL lightrag · rag_ingest | AI 側で確保する必要あり | 文書処理状態が消える — 上記 danger を参照 |
PostgreSQL litellm | AI | ゲートウェイキー・使用量履歴が消える |
Aster TSDB pi | AI 側で確保する必要あり | フィーチャーが消え分析画面が空になる（再計算は可能だが時間がかかる） |
Aster TSDB pp | プラットフォームバックアップ | — |
| Neo4j · Qdrant | AI | 文書索引が消える（原本から再生成可能） |
| デジタルスレッド Neo4j | AI（bin/backup.sh がボリュームごと） | ミラーが消える（原本から再構築可能） |
lightrag-storage ボリューム | AI | KV キャッシュが消える（再生成可能） |
lightrag-inputs ボリューム | AI — 最も重要 | 原本文書が消え、索引を再生成する方法がなくなる |
手順は データベース管理 を参照してください。
関連文書
- データベース管理 — 接続・点検・運用
- AI 管理コンソール — パイプライン状態確認
- サービスポートマップ
- プラットフォームデータベースモデル