Make Song

曲＋歌詞制作ウィザード（汎用作曲エンジン）

トリガーワード

「曲作って」「作曲して」「音楽作って」「歌作って」「オリジナル曲作って」「新しい曲作って」「武将で曲作って」「サイバー和で曲作って」「/make-song」

📁 保存場所（固定・変更禁止）: 成果物は /home/yn4416/projects/<該当リポジトリ>/songs/<曲名>/ 配下に保存。~/Music/ には一切保存しない。

前提知識（進行開始前に必ず読み込む）

MiniMax API使用ルール

⚠️ 重要: 動画生成用と音楽生成用で異なるAPI

make-songスキルの使用対象:

• ✅ 音楽生成のみ（music-generation API）
• ❌ 動画生成（video-generation API）
• ✅ MCPサーバー名: minimax
• ✅ 環境変数: MINIMAX_API_KEY（NTH39）

注意:

• 動画生成用キーは間違えないこと
• music_generation APIは通常300秒でタイムアウトする可能性がある
• 長時間生成が必要な場合は分割生成またはバックグラウンド実行を検討

知見は AI 依存度で4層に分離（AI 変更時に Layer 2 だけ差し替え・Layer 1 は残す）:

• references/[L1]プロンプト技法.md（確定・汎用: GMIV順序・具体語推・楽器制限・構造タグ・1変数テスト）
• references/[L1]構造理論.md（確定・AI非依存: 小節×BPM計算・ジャンル別構造・感情曲線）
• references/[L1]日本語歌詞技法.md（確定・AI非依存: 韻・発音ルール・歌詞構成論・音節設計）
• references/[L1]楽曲制作基礎_ジャンル別.md（確定: コード進行・スケール・リズム・10ジャンルの作曲の型）
• references/[L1]音楽的キャラクター辞書.md（確定: Phase 0.5用・感情→定番コード進行→ジャンル具体語のプリセット＋マッピング）
• references/[L1]発音ルール.md（確定・AI非依存: 母音・音節・発音の基本ルール・ひらがな化の理論的根拠）
• references/[L1]韻技術.md（確定・AI非依存: 韻の踏み方・脚韻/頭韻・母音合わせ・日本語ラップ韻論）
• references/[L1]曲構成_BPM計算.md（確定・AI非依存: 小節数逆算・BPM×曲長連動・構造タグ対応表・タイミング計算）
• references/[L1.5]潮流サンプル参照.md（月更新: 流行り・サンプル曲・陳腐化リスクあり・必要時）
• references/[L2]MiniMax実測知見.md（実測・MiniMax固有: duration不存在・圧縮率・声質固定・括弧記法）
• references/[L2]music-cover手法.md（実測・MiniMax固有: 曲先メロディ固定の中核・cover_feature_id取得→music-coverループの手順・Phase 3/5で使用）
• references/[L2]失敗パターンカタログ.md（育成: 失敗する書き方・実測で拡充）
• references/[L2]発音問題_MiniMax固有.md（MiniMax固有: 漢字誤読→ひらがな化・music-cover・日本語ボーカル時・themes/<theme>/kanji_map.json＋scripts/kanji_to_hiragana.py で固有名詞ひらがな化）
• references/[META]ポータビリティチェックリスト.md（AI変更時: Layer 2 差し替え検証手順）
• references/[THEME]三国志_HIPHOP.md（テーマ選択時: 三国志HIPHOP・Phase 0 で選択時のみ）
• references/[THEME]サイバー和モダン.md（テーマ選択時: サイバー和モダン・Phase 0 で選択時のみ）

知見アーキテクチャ（核心・厳守）

知見仕分け: 4象限マトリクス（汎用性 × 検証度）

5層構造

• Layer 0: 制作姿勢（不変）— 実測ファースト・1変数変更法・「知見は確たるものではない」認識
• Layer 1: 普遍の音楽理論・技法（年更新・AI非依存）→ references/[L1]*
• Layer 1.5: 潮流・サンプル参照（月更新・陳腐化リスク）→ references/[L1.5]*
• Layer 2: MiniMax固有の実測知見（即時更新）→ references/[L2]*
• META: ポータビリティ（AI変更時の差し替え手順）→ references/[META]*
• THEME: テーマ固有作曲知識（三国志HIPHOP/サイバー和モダン・Phase 0 選択時のみ）→ references/[THEME]*（旧 sangoku-song/cyber-wa-song の固有資産を本体化・2026-06-29統合）

昇格ルール（循環）

③④（仮説）→ 実測で効果確認 → ①②（確定/実測）へ昇格。①のうち特定AIで効かないものは②へ降格。

AI変更時（核心）

Layer 1（基礎）はそのまま再利用。Layer 2 のみ [META]ポータビリティチェックリスト.md で再検証して書き直す。

進行（Phase -1 〜 6）

🔴 = 人間判断ポイント。必ず停止してユーザー確認を待つ。 楽曲制作は「聴かないと分からない」ので生成ごとに停止。

Phase -1: 目的・用途の定義

楽曲の用途を確認（設計厳密さが変わる）:

• 商用BGM / 個人作品 / 動画投稿用 / クライアントワーク / 実験
• Quick Mode（Phase -1+0+1+4+5・Phase 3メロディ淘汰スキップ・歌詞先で手軽に1曲）or Full Mode（全Phase・メロディ淘汰あり・最高品質）を選択
• Phase 0.5 の深さも連動: Quick=第1-2層（ジャンル→系統）のみ / Full=第1-3層（+エッセンス追加）

Phase 0: コンセプト起点

• アイデア/テーマ/情景を聞く（フリー記述 or 選択）
• テーマ選択（任意・該当する場合）:
  • 汎用（テーマなし）
  • 三国志HIPHOP → references/[THEME]三国志_HIPHOP.md 読込
  • サイバー和モダン → references/[THEME]サイバー和モダン.md 読込
• リファレンス仕様書の持ち込みがあれば読込（reverse-engineer-song 経由）
• 起点曲の定量解析（0d・任意・analyze-song連携）: 「この曲っぽく作りたい」と起点曲（曲名/YouTube URL/MP3パス・DB登録済み曲・DB外どちらも可）が挙がった場合に実行
  • コマンド（cd /home/yn4416/projects/claude-config/skills/analyze-song で実行）。<timestamp> は実行前に date +%Y%m%d_%H%M%S 等で1つ確定し、以下2コマンドで同じ値を使うこと:

    /home/yn4416/projects/claude-config/.venv/bin/python scripts/analyze_song.py \
      <起点曲(URL/MP3パス)> -o /tmp/make-song-query/<timestamp> -t <仮タイトル>
    /home/yn4416/projects/claude-config/.venv/bin/python -m scripts.match_song \
      /tmp/make-song-query/<timestamp>/features.json \
      /home/yn4416/projects/obsidian-ssot/reference/名曲DB \
      -o /tmp/make-song-query/<timestamp>/match_report.md
    

    • Windows Desktop環境: 上記は.venv/bin/python直接実行のためWSL-CLI環境専用。Windows Desktopではwin-wsl-exec.sh経由で実行（詳細は analyze-song SKILL.md の「Windows Desktop環境での実行」参照）
  • Demucs音源分離を含むため数分かかる。実行前にユーザーへ「数分かかります」と伝える
  • 失敗時（YouTube DL失敗・Demucs失敗・対応外フォーマット等）は本ルートを諦め、下記「エラー処理・フォールバック」表の該当行に従う
  • 成功時: /tmp/make-song-query/<timestamp>/make_song_input.json を Phase 0.5/1 で参照する（詳細は Phase 0.5/1 セクション参照）
  • オプトイン確認 🔴（人間）: 解析完了後、必ず一度「このDBに恒久登録しますか？」とユーザーに尋ねる
    • Yes → 曲ID/タイトル/アーティスト/ジャンル/commercial-rank/era/selection-reason を聞き、analyze-song SKILL.md の「使い方（Phase 2・名曲DB登録）」コマンド（register_song）を実行
    • No（デフォルト） → 何もしない。/tmp/make-song-query/<timestamp>/ は本セッション終了後に削除して構わない（永続化不要）
• 楽曲の目的: フックonly / 60秒 / フル3-4分

発動の使い分け: 「曲作って」「作曲して」「武将で曲作って」「サイバー和で曲作って」等=本スキル（Phase 0 の [THEME] 選択で三国志HIPHOP/サイバー和モダンを吸収）。曲+詞だけなら Phase 0 テーマ選択で完結。映像まで欲しい場合は Phase 6 の橋渡し（ルートA）で video-prompt-spec へ誘導。

Phase 0.5: 音楽的キャラクター設計（Harmony & Character Design）

目的: 和声・メロディ・リズム等の揺れやすい要素を固定し、生成ブレを低減する。 AI音楽生成は直接コード進行指定を無視するため、ジャンル→系統→エッセンスで絞り込み、ジャンル具体語に翻訳して渡す（[L1]音楽的キャラクター辞書 参照）。

• 0a ルート選択 🔴（人間） — 以下3ルートから選ぶ:
  • A. ジャンル起点ドリルダウン（デフォルト・推奨）: 第1層ジャンル → 第2層系統（アーティストイメージ命名）→（Full時）第3層エッセンス追加
  • B. 個別選択（上級）: 和声/メロディ/リズム/ダイナミクス/転調を要素ごとに指定
  • C. リファレンス曲逆引き（優先）: Phase 0 持ち込み曲（仕様書 or 0d定量解析）があれば、その曲のジャンル・系統に当てはめ。0d実行済みの場合のジャンル採用方法は下記「0d実行済みの場合の優先ルール」参照
• 0b 具体語翻訳: 選んだ系統の「ジャンル具体語」+ エッセンスの具体語 を結合。コード進行の文字列・アーティスト名は絶対にプロンプトに書かない
• Quick/Full 深さ差:
  • Quick Mode: Aルート第1-2層（ジャンル→系統）まで・エッセンスなし
  • Full Mode: Aルート第1-3層（ジャンル→系統→エッセンス）+ 個別選択(B)可
• 出力: 翻訳した具体語を Phase 1（GMIVのGenre/Mood）と Phase 2（構造・感情曲線）に流し込む
• 0d実行済みの場合の優先ルール: リファレンス仕様書（定性・reverse-engineer-song経由）と make_song_input.json（定量・0d経由）が両方ある場合、BPM・キー・ジャンルの3項目のみ定量側（実測値）を優先。構造・感情曲線等の定性的要素は引き続き仕様書側を使う。各項目の取得元フィールド:
  • ジャンル = genre_distribution（{ジャンル名: 出現回数}の辞書）の出現回数が最大のキー。同数タイの場合は reference_songs のrank最上位（rank=1）のジャンルを優先
  • キー = query.key（起点曲自身の実測キー。recommended.key_pcは参照曲群の最頻ピッチクラス整数のため使わない）
  • BPM = recommended.bpm（参照曲群の平均BPM。Phase 1 GMIVのBPMにそのまま使う）

Phase 1: 設計パラメータ固め（Reference 3曲 → GMIV）

Phase 0.5 の出力（ジャンル具体語）を Genre/Mood に反映してから GMIV を組む。キャラクター辞書の「ジャンル具体語」列が GMIV の G/M の骨。

0d実行済みの場合: make_song_input.json の値を以下に反映する（ジャンル・BPMの取得元はPhase 0.5「0d実行済みの場合の優先ルール」参照）

• Reference 3曲 = reference_songs[:3]（下記1.の代わりに使用可）
• GMIVのG = genre_distribution 最大カウントのジャンル（Phase 0.5の3項目優先ルールに対応）
• GMIVのBPM（下記3.） = recommended.bpm（Phase 0.5の3項目優先ルールに対応）
• GMIVのV性別 = query.gender_estimate（Phase 0.5の3項目優先ルールの対象外・GMIVのV専用の追加反映項目）

1. Reference 3曲（業界標準）: 雰囲気を具体曲で伝える（[L1.5]潮流 参照可）
2. GMIV順序（[L1]プロンプト技法・[L1]楽曲制作基礎 参照）:
   • Genre — ジャンル＋時代・具体語（抽象語NG）
   • Mood — ムード/情景（ジャンル×感情の翻訳）
   • Instrumentation — 楽器2-4個・重要音源順
   • Vocal — 性別＋声質プロファイル（[L2]固定文字列・声色ブレ防止）＋Delivery（歌い回し: ウィスパー/ベルティング/ラップ等）
3. BPM＋曲規模（テンポ×曲長連動）

Phase 2: 楽曲構造設計（理論/補正の分離）

• 2a 理論構造（[L1]構造理論・AI非依存）: 小節数逆算＋構造タグ14種＋感情曲線（Emotion Arc）
  • 感情曲線は Phase 0.5 で選んだキャラクターの感情・ダイナミクス展開（Full Mode時）に合わせて設計
• 2b AI補正（[L2]MiniMax実測・圧縮率60-70%）: 補正設計値＋長尺化ベストプラクティス（番号付きVerse/(掛け声)/[Break]）

  AIが変わっても 2a は不変・2b だけ差し替え

Phase 3: メロディ淘汰（進化的選択・曲先）★コア

業界標準（KPOPトップライン手法）に倣い、メロディを先に確定。歌詞は後載せ。 出典: BMI / Berklee / MasterWindow — ヒット曲は「良いメロディ×平凡な歌詞」で成立するが、逆は稀。サビのメロディが売れるかを決める。 MiniMax はメロディを直接設計できない→スキャット生成→人間選別→music-cover でメロディ固定により曲先を実現。

• 3a メロディプロトタイプ量産:
  • 歌詞はスキャット（la la la / 母音列）= メロディ抽出用の「単なる音」（歌詞は後で載せる）
  • Aメロ〜サビのコアのみ、10個一括生成（inst＋メロディボーカル）
  • GMIV（Phase 1）＋構造タグ（Phase 2）を反映。「キャッチーなサビフック」をプロンプトで最重視
  • 声質プロファイル（[L2]固定文字列）はここで固定（以降ブレ防止）
  • スキャット生成プロンプトに Phase 0.5 の和声/メロディキャラクター（王道進行なら順次進行・跳躍少 等）を反映。これが揺れ低減の本体
• 3b トーナメント選別 🔴（人間）:
  • 10個を聴取（ユーザー手動再生）→ キャッチーな2-3個を選別
  • 基準: サビのフック・記憶に残る・惹きつける（= 売れる要素・最重視）
• 3c 変奏展開（淘汰）:
  • 選別した2-3個をベースに各5個ずつvariation生成（計10-15個）
  • また2-3個に絞る。収束まで2-3ラウンド反復
• 3d 最終メロディ決定 🔴（人間）:
  • 残った1個をフル尺展開のベースに決定

    コスト注意: 淘汰サイクルは生成数が跳ね上がる（10+15+15…）。プラン枠/従量を事前確認（[L2]MiniMax実測 Token Plan）。Quick Mode では本Phaseをスキップ。

Phase 4: 歌詞作成（決まったメロディに載せる）

⚠️ メロディ品質3軸ルール（必須・2026-07-11拡張）: 歌詞とメロディの組み合わせが「人間味ある歌」になるかを 3軸で判定。詳細: ~/.claude/skills/make-song/references/[L1]音節密度指標.md、SSOT: obsidian-ssot/01_DECISIONS/ai-music/_レシピ集/音節密度指標.md。

v2楽曲「祭礼前夜」の失敗を受けて多次元化: 音節密度A（8音節/秒以下）が安全域でも、ウィスパー低音偏り（B）+ 抑揚なし（C）で「ラップ調ウィスパー」になる事故が発生。sentaku L3弁証論（GLM/Gemini/MiniMax）の結果、案A'（合成案） を採用。

軸	何を防ぐか	判定基準	違反時の症状
A. 音節密度（既存）	早口・ラップ調	8音節/秒以下 ✅・8〜10 ⚠️・10超 ❌	ラップ調・人間離れ
B. 中高音使用率（Phase 1実装済・歌詞文字列ベース）	ウィスパー低音偏り	スコア50以上 ✅・30〜50 ⚠️・30未満 ❌	ウィスパー低音・抑揚なし
C. 抑揚幅スコア（Phase 1実装済・歌詞文字列ベース）	平板メロディ	スコア40以上 ✅・20〜40 ⚠️・20未満 ❌	抑揚なし・平板メロディ

Phase 1の実装範囲: B/C は歌詞文字列レベルでの自動評価（漢字→ひらがな変換＋強母音カウント＋破裂音加点）。実測オーディオ解析（librosaスペクトル重心、pYIN音程推定）は Phase 2（1-2ヶ月後） で実装予定。Phase 1でも十分な失敗検出が可能（祭礼前夜v1-v6の歌詞再評価で実証）。

BPM連動の計算: 4/4拍子の1小節 = 60/BPM × 4 秒。8小節なら 1920/BPM 秒。各セクションの歌詞を len(line) で数えて、Σ / 秒数 が 8以下 であることを確認。

プロンプト指示（軸B・C・予防制御）:

• B（中高音使用率）: 声質プロファイルに「中高音域(A4以上)を主軸に歌う・低音ウィスパーに偏らない・whisper-to-belt contrast（belt=主）」を明記
• C（抑揚幅）: 「メロディーの起伏を5音以上確保・サビで音程の跳躍・AメロBメロで順次進行+サビで跳躍」を明記

• 4a 売れ線歌詞構造生成（売れ線パターン適用）:
  • サビ構造: 「～だ」「～だろ」の終止形決定＋「さぁ～だ」「やっぱり～だ」のモチーフ再確認
  • 呼びかけ形式: 「踊りませんか？」「笑え、笑え」「酔え、酔え」「泣いて、笑って、息して」
  • 3拍子反復: 「泣いて、笑って、息して」「進め、果て、越えて」
  • 感情単語: 鼓動、震え、嘘、痛み、夢、生きる証、夜、影、光
  • PC用語排除: 「ゼロ」「バイナリ」「コード」「プログラム」→「零（ゼロ）」「記憶」「調べる」「道標」
• 3d 最終メロディの呼吸・音節に合わせて歌詞を書く（[L1]日本語歌詞技法・韻・音節・呼吸ポイント）
• 3軸チェック:
  • 軸A（音節密度）: 上記「⚠️メロディ品質3軸ルール」の表に従い、各セクションの文字数を BPM から秒数を割り出して 1秒あたり音節数 8以下 を満たすか。簡易的には「1行 = 18文字以下（目安）」を遵守
  • 軸B（中高音使用率・自動）: 「胸を張れ」「鳴らせ」型の高音を促す語彙・破裂音（パ・バ・タ・ダ行）の存在・ウィスパー語彙（「囁く」「眠る」型）の不在を加点・減点。スコア50以上で ✅
  • 軸C（抑揚幅・自動）: 行の音節数ばらつき（標準偏差）・強母音（あ・い・う・え・お）のセット遷移頻度・平板メロ減点。スコア40以上で ✅
  • 総合判定: 3軸のうち最低値で判定 ❌/⚠️/✅
• チェックツール: python3 scripts/check_song_quality.py --bpm 98 歌詞.md（3軸自動評価・2026-07-12実装）
  • 出力例:

    📊 メロディ品質3軸チェック結果（BPM=98）
    セクション             行数  小節    秒数   音節    密度     A  B中高    B  C抑揚    C  総合
    Chorus             4   16   39.2    44   1.1   ✅   76.0   ✅   61.5   ✅   ✅
    Verse 1            4   16   39.2    49   1.2   ✅    7.9   ❌   35.0   ⚠️  ❌
    

  • 重要: Chorus 等サビが ✅ でも Verse/Intro で ❌/⚠️ があれば全体再生成検討。3軸全 ✅ になるまで歌詞・プロンプトを調整

Phase 2: 実測オーディオ解析（librosa/pYIN）

Phase 1 の文字列ベース評価に加え、wav ファイルから実測オーディオ解析を行います。 評価融合戦略（実測50% + 文字列50%）で、Phase 1 の17テストを維持しつつ精度向上。

軸B: 実測中高音使用率（librosa.spectral_centroid）

# wav 指定で実行（融合評価）
python3 scripts/check_song_quality.py --bpm 98 \
  --audio songs/祭礼前夜/祭礼前夜.wav \
  songs/祭礼前夜/歌詞.md

• A4（440Hz）以上の周波数帯での音響エネルギーの時間的比率
• 判定: ≥0.4 → ✅ / 0.2-0.4 → ⚠️ / <0.2 → ❌

軸C: 実測抑揚幅（librosa.pyin）

• pYIN 音程推定で音高時系列の標準偏差
• 判定: ≥40Hz → ✅ / 20-40Hz → ⚠️ / <20Hz → ❌

評価融合

# コードから直接呼び出し
from check_song_quality import calc_mid_high_score_fused
score = calc_mid_high_score_fused(
    section_name="Chorus",
    lines=lyrics_lines,
    audio_path=wav_path,
    weight_audio=0.5,  # 実測の重み（1-2ヶ月運用後に0.7等へ調整）
)

必要な依存ライブラリ

pip install librosa==0.10.2 numpy scipy

詳細: obsidian-ssot/01_DECISIONS/ai-music/2026-07-12_音節密度ルール拡張-Phase2実測オーディオ解析導入.md

• ひらがな化（[L2]発音問題・日本語ボーカル時必須・janome＋固有名詞）＋漢字版併記
• 4b LLMレビュー:
  • MiniMaxで構造・キャッチーさ評価（1-10点・売れ線構造適合度）
  • Geminiでバグ・矛盾チェック（構造的矛盾・実装可能性）+ 音節密度の計算結果確認
• 🔴 人間判断: 歌詞提示 → MiniMax評価結果確認 → 3軸すべて が警告域/禁止域になっていないか確認 → 「この歌詞で載せていいですか?」

Phase 5: フル生成＋検証（メロディ保持・曲先の完成形）

1. 3d 最終メロディinstを music_cover_preprocess で音響特徴取得（24h有効）→ cover_feature_id
2. music-cover（curl直接API・MCP非対応）でメロディを固定しつつ Phase 4 歌詞を載せてフル生成
3. 聴取はユーザー手動再生（play_audio 不使用・300sタイムアウト対策）
4. Success Metric: 音質 / メロディ保持 / 歌詞適合 / 雰囲気一致
5. 修正は1変数変更法（発音→music-cover再ループ・声色→プロファイル強化）
6. 打切基準: コスト・時間制約でイテレーション上限を設定

• 🔴 ループ継続/完了判断

Phase 6: 成果物整理＋SSOT記録＋知見蓄積

1. 楽曲保存（/home/yn4416/projects/<該当リポジトリ>/songs/<曲名>/）＋lyrics.md（ひらがな/漢字/修正履歴）＋淘汰履歴（各ラウンドの選別結果）
2. SSOT記録: 01_DECISIONS/ai-music/YYYY-MM-DD_<曲名>.md（詳細）＋10_DAILY/（サマリー+リンク）
3. 知見蓄積（実測ファーストの循環エンジン）:
   • [L2]失敗パターンカタログ へ今回の失敗/解決を記録（淘汰型の知見も）
   • [L2]MiniMax実測知見 へ確定知見を昇格
   • [L1.5]潮流 へ流行り知見を記録
   • 4象限マトリクスの昇格/降格候補を明示

Phase 6 追加: 映像への橋渡し（ルートA・一気通貫）

AskUserQuestion で確認: 質問:「この楽曲の映像を video-prompt-spec で作りますか?」 選択肢: はい（映像生成へ進む）→ 楽曲ファイルパス・テーマ・世界観を引き継ぎ video-prompt-spec Phase 0 へ誘導 いいえ（楽曲のみで終了）

エラー処理・フォールバック

関連

• テーマ固有（統合済・Phase 0 の [THEME] 層で対応）: cyber-wa-song / sangoku-song（※旧スキル・参照は [THEME]サイバー和モダン.md / [THEME]三国志_HIPHOP.md へ片方向統合済）
• reverse-engineer-song（参考曲仕様書→Phase 0 持ち込み・定性分析）
• analyze-song（起点曲の定量解析→Phase 0d・make_song_input.json連携）
• video-prompt-spec（Phase 6 橋渡し・ルートA: 楽曲→映像プロンプト仕様書へ一気通貫）
• 設計書: obsidian-ssot/01_DECISIONS/ai-music/2026-06-16_AI作曲スキル_design.md
• 実装計画: obsidian-ssot/01_DECISIONS/ai-music/2026-06-16_AI作曲スキル_plan.md
• 連携設計書: obsidian-ssot/docs/superpowers/specs/2026-06-29-make-song-analyze-song-bridge-design.md