漫画を描く（内部表現（IR）の永続化）

ここはまさに 「OS の内部表現（IR）を永続化する層」なので、
MySQL のスキーマは 意味 → 構造 → SVG の責任分離を壊さないように設計する必要があります。

あなたの OS はすでに：

意味レイヤ（PoseSpace / FaceSpace / CharacterModel）
構造レイヤ（joints / bones / paths）
SVGレイヤ（線の集合）

という 3 層構造を持っているので、
DB も この 3 層をそのまま反映した構造にするのが最も強い。

🧱 結論：MySQL スキーマは「3レイヤ構造」で設計する

1. characters（キャラ固有の意味レイヤ）

キャラの頭身・骨長比率・顔矩形などを保存する。

CREATE TABLE characters (
  id            BIGINT PRIMARY KEY AUTO_INCREMENT,
  name          VARCHAR(255) NOT NULL,
  head_height   FLOAT NOT NULL,
  face_width    FLOAT NOT NULL,
  bone_ratio_json JSON NOT NULL,   -- { "upperarm":1.0, "forearm":0.9 ... }
  face_rect_json JSON NOT NULL,    -- { "top":120, "bottom":180, ... }
  created_at    DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP
);

2. poses（意味レイヤ：PoseVector）

PoseVector（回転角・意図・視線など）を保存。

CREATE TABLE poses (
  id            BIGINT PRIMARY KEY AUTO_INCREMENT,
  character_id  BIGINT NOT NULL,
  pose_name     VARCHAR(255),
  pose_vector_json JSON NOT NULL,  -- { "shoulder-L": 40, "elbow-L": 30, ... }
  created_at    DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
  FOREIGN KEY (character_id) REFERENCES characters(id)
);

3. joints（構造レイヤ：計算済み joint 座標）

PoseVector を適用した後の 絶対 joint 座標を保存。

CREATE TABLE joints (
  id            BIGINT PRIMARY KEY AUTO_INCREMENT,
  pose_id       BIGINT NOT NULL,
  joint_name    VARCHAR(50) NOT NULL,  -- "shoulder-L", "eye-R" etc
  x             FLOAT NOT NULL,
  y             FLOAT NOT NULL,
  z             FLOAT DEFAULT 0,       -- 2.5D 用
  created_at    DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
  FOREIGN KEY (pose_id) REFERENCES poses(id)
);

4. skeleton_paths（構造レイヤ：骨格の線）

OS の骨格ルールに従って生成された path を保存。

CREATE TABLE skeleton_paths (
  id            BIGINT PRIMARY KEY AUTO_INCREMENT,
  pose_id       BIGINT NOT NULL,
  path_order    INT NOT NULL,          -- spine=1, left-arm=2, ...
  joint_list    JSON NOT NULL,         -- ["spine1","spine2","spine3"]
  created_at    DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
  FOREIGN KEY (pose_id) REFERENCES poses(id)
);

5. svg_outputs（SVGレイヤ：最終SVG）

Gemini に渡す前後の SVG を保存。

CREATE TABLE svg_outputs (
  id            BIGINT PRIMARY KEY AUTO_INCREMENT,
  pose_id       BIGINT NOT NULL,
  svg_text      MEDIUMTEXT NOT NULL,
  created_at    DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
  FOREIGN KEY (pose_id) REFERENCES poses(id)
);

🌐 全体構造（OS の責任分離をそのままDBに写す）

characters
   ↓（キャラ固有の意味）
poses
   ↓（PoseVector）
joints
   ↓（joint座標）
skeleton_paths
   ↓（構造）
svg_outputs
   ↓（最終SVG）

この構造は あなたの OS の意味→構造→SVG の流れを完全に保存する。

🌌 このスキーマが OS として強い理由

✔ 意味レイヤ（characters / poses）が独立

→ キャラの頭身やポーズ意図を変えても、構造レイヤは壊れない。

✔ joints が「計算済み構造」を保持

→ Gemini に渡す前に OS が完全に制御できる。

✔ skeleton_paths が「OS の骨格ルール」を保証

→ AI が勝手に線を変えても OS が再生成できる。

✔ svg_outputs は「レンダリング結果」だけ

→ OS の真実は joints と paths にある。

🔥 次に進めるなら…

PoseVector の正規化（角度の範囲・意味の定義）
joints の Z（2.5D）をどう扱うか
表情ベクトルを DB にどう保存するか
Gemini への IR を DB からどう生成するか

どこを深めたい？

ここは OS の「永続化レイヤ」の精度に関わる重要ポイントだね。
あなたが指摘した 「Gemini に渡す前後の区別がない」というのはまさにその通りで、
前のスキーマ案では “前処理（IR）” と “後処理（SVG）” が混ざっていた。

OS の責任分離を守るなら、
Gemini に渡す前（意味→構造） と
Gemini から返ってきた後（構造→SVG）
は完全に別テーブルにする必要がある。

ここで、OS の 3 層構造に沿った正しいスキーマを示すね。

🧩 OS の 3 層構造をそのまま DB に写す

あなたの OS はこうなっている：

意味レイヤ（PoseVector / FaceVector / CharacterModel）
構造レイヤ（joint座標 / skeleton paths）
SVGレイヤ（Gemini が描いた線）

だから DB もこの 3 層で分ける。

🟦 1. Gemini に渡す前（意味 → 構造）

characters（キャラ固有の意味）

CREATE TABLE characters (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  name VARCHAR(255),
  bone_ratio_json JSON NOT NULL,
  face_rect_json JSON NOT NULL,
  created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);

poses（PoseVector：意味）

CREATE TABLE poses (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  character_id BIGINT NOT NULL,
  pose_vector_json JSON NOT NULL,
  face_vector_json JSON,
  created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
  FOREIGN KEY (character_id) REFERENCES characters(id)
);

joints（構造：計算済み joint 座標）

CREATE TABLE joints (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  pose_id BIGINT NOT NULL,
  joint_name VARCHAR(50) NOT NULL,
  x FLOAT NOT NULL,
  y FLOAT NOT NULL,
  z FLOAT DEFAULT 0,
  created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
  FOREIGN KEY (pose_id) REFERENCES poses(id)
);

skeleton_paths（構造：OS の骨格ルール）

CREATE TABLE skeleton_paths (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  pose_id BIGINT NOT NULL,
  path_order INT NOT NULL,
  joint_list JSON NOT NULL,
  created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
  FOREIGN KEY (pose_id) REFERENCES poses(id)
);

🟥 2. Gemini に渡す IR（意味→構造→IR）

ここが “前”。

CREATE TABLE gemini_requests (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  pose_id BIGINT NOT NULL,
  request_json JSON NOT NULL,   -- Gemini に渡した IR
  created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
  FOREIGN KEY (pose_id) REFERENCES poses(id)
);

🟩 3. Gemini から返ってきた後（SVG レイヤ）

ここが “後”。

Gemini は SVG を返すので、それを保存する。

CREATE TABLE gemini_responses (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  request_id BIGINT NOT NULL,
  svg_text MEDIUMTEXT NOT NULL,  -- Gemini が返した SVG
  created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
  FOREIGN KEY (request_id) REFERENCES gemini_requests(id)
);

🌐 全体の流れ（OS の責任分離が完全に成立）

characters
   ↓
poses（PoseVector）
   ↓
joints（計算済み座標）
   ↓
skeleton_paths（構造）
   ↓
gemini_requests（IR：前）
   ↓
Gemini
   ↓
gemini_responses（SVG：後）

これで：

意味レイヤ（PoseVector）
構造レイヤ（joint / skeleton）
レンダリングレイヤ（SVG）

が完全に分離される。

🔥 なぜこの分離が OS として強いのか

✔ Gemini は「描画エンジン」でしかない

→ OS の真実は joints と skeleton_paths にある。

✔ Gemini が暴れても OS の意味は壊れない

→ joints が絶対基準。

✔ IR（前）と SVG（後）が明確に分離

→ デバッグ・再生成・比較が容易。

✔ 2026 年のあなたOS の「世界理解の骨格」が揺れない

→ 意味 → 構造 → SVG の流れが永続化される。

🌱 次に進めるなら…

gemini_requests の IR を自動生成する関数設計
SVG を joints に逆変換する（逆運動学）
PoseVector の正規化（角度の意味モデル）
表情ベクトルの DB 保存方法

どこを深めたい？