📚 CC Stories
← 検問の穴を塞ぐと別の穴が開いて、最後は自分の違和感が正しかった話 013の次に見えた「聴くだけじゃ足りない」 →
第19話

第19話 作業物語 「曲作って」と言ったらAIの癖に振り回されない道具立てになっていた話

困ったこと

AIに曲を作ってもらううちに、ひとつ気づいた。

知っている楽曲の型も日本語の韻の踏み方も、何もかもが「いま使っているAIが覚える前提」で積み上がっていく。AIが変わったらどうするか。最初の日から手探りで、何ヶ月もかけて培ってきた工夫が、朝には全部ただの紙くずになる。

それだけではない。「A社のAIでは効く」「B社のAIでは効かない」みたいな小技が大量に生まれて、どれが本当に大事なのか、どれが小さな揺れに過ぎないのか、自分でももう分からなくなっている。芯の強さを保ちながら、AIの差分だけをうまく入れ替える仕組みが、どうしても必要だった。

どう解決したか

2つの軸を直角に交差させた。

縦の軸は 「AIが変わっても残るかどうか」 。横の軸は 「どれくらい確かめられたか」 。これで4つの升目が出来上がる。「AI非依存かつ確か」は確定の基礎、「AI固有かつ確か」は差し替え前提の核、「未確か」なものは升目の隅に追いやった。

その上で、5つの棚を重ねた。一番下は姿勢（測ってから語る・一度に変えるのはひとつだけ）、その上は普遍の音楽理論（月単位で見直し）、流行りの参照（月単位で入れ替え）、AI固有の実測（即時更新）、そして一番上にプロジェクトごとの制作記録。基礎はそのまま、AIが変わったら固有の棚だけ書き直す——この運用ルールを、ファイル名の頭に [L1][L1.5][L2][META] と刻んで、「どの棚の話か」を一目で区別できるようにした。

何が変わったか

AIが将来入れ替わっても、音楽理論のノートを読み直さなくていい。本当に見直すべきは [L2] とついた棚だけ。効くのか効かないのか分からない小技は、まず「未確か」の升目で飼いならし、確かだと分かった時点で確定の升目に昇格する。升目をまたぐ昇格と降格のルールを最初から決めたので、混沌と化さずに済む。

一度に頼んでも、軽くても、本格仕様でも、どちらでも応じられる。基礎理論を保ったまま、流行りの参照は月で更新し、AI固有の癖は実測で育ったぶんだけ反映される──そういう生きた道具立てが手に入った。

<details><summary>▶ 技術的にどう作ったか</summary>

核心構造:

SKILL.md構成: 本体はフェーズ＋意思決定フローのみ（スリム）。詳細は references に分離し、prefix [L1][L1.5][L2][META] でAI依存度を視覚化。コンテキスト圧迫回避のためジャンル/場面別に必要な分だけ参照する設計。

フェーズ分割: Phase -1（用途定義・Quick/Full分岐）→ 0（コンセプト）→ 1（Reference 3曲＋GMIV順序）→ 2a/2b（理論構造/AI補正分離）→ 3b→3a（歌詞先行・韻設計→プロンプト）→ 4（生成＋1変数変更ループ）→ 5（SSOT記録＋知見蓄積）。

ポータビリティ・チェックリスト（AI差し替え時の確認項目）: duration/BPM・構造タグ認識・括弧/コロン記法解釈・歌詞最大文字数・圧縮率・声質プロファイル・高音質パラメータ・失敗パターン再現性 — L1は再々利用、L2のみ再検証して書き直す手順を references/[META]ポータビリティチェックリスト.md に集約。

既存資産統合: cyber-wa-song / sangoku-song / reverse-engineer-song の作曲フェーズを本スキルへ委譲。各スキルは固有カタログだけ残してスリム化（YAGNI徹底）。

素材出典: obsidian-ssot/01_DECISIONS/ai-music/2026-06-16_AI作曲スキル_design.md（259行・full design spec） </details>