交響曲オマージュ生成（DBスキーマ）

ここは一度 完全に誤解を解消して、正しい設計軸に戻す必要がある。

あなたが今説明してくれた内容は、
Symphony OS の本質そのもので、
僕がさっき提示したスキーマは その本質を満たしていなかった。

つまり、僕は「Mangas OS の構造を音楽に移植する」方向に寄りすぎていた。
あなたが求めているのは “作曲家 → 作品 → 楽章 → モチーフ” の階層構造を持つ、音楽専用の OS。

ここを正しく理解した上で、
Symphony OS 専用の正しい DB スキーマを作り直す。

🎼 Symphony OS の本質（あなたの説明から抽出）

作曲家（Composer）
作品（Work）
楽章（Movement）
モチーフ（Motif）
モチーフの意味付け（semantic）
モチーフの入れ替え（remapping）
AI（Gemini）を 2 回使う
- ① モチーフ抽出（構造解析）
- ② オマージュ生成（再構成）

この 7 層構造を支える DB が必要。

🎯 Symphony OS 専用 DB スキーマ（正しい構造）

◆ 1. composers（作曲家）

CREATE TABLE composers (
    id INT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(255) NOT NULL,
    era VARCHAR(255),            -- 古典派 / ロマン派 / 近代 など
    metadata JSON,
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);

◆ 2. works（作品）

CREATE TABLE works (
    id INT AUTO_INCREMENT PRIMARY KEY,
    composer_id INT NOT NULL,
    title VARCHAR(255) NOT NULL,
    catalog_number VARCHAR(255),     -- Op.95, K.550 など
    metadata JSON,
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (composer_id) REFERENCES composers(id)
);

◆ 3. movements（楽章）

CREATE TABLE movements (
    id INT AUTO_INCREMENT PRIMARY KEY,
    work_id INT NOT NULL,
    movement_index INT NOT NULL,     -- 第1楽章 = 1
    title VARCHAR(255),
    key_signature VARCHAR(50),       -- 調
    form VARCHAR(255),               -- ソナタ / ロンド / 三部形式
    metadata JSON,
    FOREIGN KEY (work_id) REFERENCES works(id)
);

◆ 4. motifs（モチーフ）

Gemini（1回目）で抽出したモチーフを保存する。

CREATE TABLE motifs (
    id INT AUTO_INCREMENT PRIMARY KEY,
    movement_id INT NOT NULL,
    motif_index INT NOT NULL,
    notes JSON NOT NULL,             -- pitch/duration の配列
    role VARCHAR(255),               -- 主題 / 副主題 / 展開素材（初期推定）
    metadata JSON,
    FOREIGN KEY (movement_id) REFERENCES movements(id)
);

◆ 5. motif_map（モチーフの入れ替え）

オマージュ生成のための「モチーフ置換マップ」。

CREATE TABLE motif_map (
    id INT AUTO_INCREMENT PRIMARY KEY,
    movement_id INT NOT NULL,
    original_motif_id INT NOT NULL,
    new_motif_id INT NOT NULL,
    metadata JSON,
    FOREIGN KEY (movement_id) REFERENCES movements(id),
    FOREIGN KEY (original_motif_id) REFERENCES motifs(id),
    FOREIGN KEY (new_motif_id) REFERENCES motifs(id)
);

◆ 6. generation_logs（Gemini 2回目）

Gemini に渡したパラメータと生成結果。

CREATE TABLE generation_logs (
    id INT AUTO_INCREMENT PRIMARY KEY,
    movement_id INT NOT NULL,
    request JSON NOT NULL,
    response JSON,
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (movement_id) REFERENCES movements(id)
);

🔥 このスキーマが “正しい” 理由

✔ 1. 「作曲家 → 作品 → 楽章 → モチーフ」の階層を完全に保持

Roblox 版でやっていた構造をそのまま Web に移植できる。

✔ 2. Gemini を 2 回使う流れが自然に表現できる

motifs：Gemini 1回目（構造抽出）
generation_logs：Gemini 2回目（再構成）

✔ 3. motif_map が「オマージュ生成の核」

どのモチーフをどれに置き換えるか
作品ごと、楽章ごとに管理できる

✔ 4. Mangas OS の構造を無理に流用していない

あなたが言った通り、
共通化すると逆に使いにくくなる
→ 専用スキーマが正しい。

✨ あなたへ

このスキーマは、
あなたが本当に作りたい Symphony OS の構造を正確に反映したもの。

次に進めるなら、どれをやりたい？

motifs 抽出（Gemini 1回目）の API 設計
motif_map の UI 設計（モチーフ入れ替え GUI）
楽章ビュー（MusicXML → SVG）
Gemini 2回目のオマージュ生成プロンプト設計
DB の CREATE 文を実際に流す

どこからでも進められる。