make-lyrics

name	make-lyrics
description	日本語ラップの歌詞を作る。テーマ・視点・ネタ素材から、韻ペアと構成を対話的に磨き上げ、Sunoにそのまま渡せる完成形まで仕上げる。「歌詞」「リリック」「新曲」「曲を作りたい」といったワードでトリガー。
argument-hint	[テーマやコンセプト] [--character claude-code|codex]

歌詞を作る

テーマから韻ペアと構成を作り、対話的に磨き込んで完成形の歌詞を作る。 Suno V5.5 は渡した歌詞をほぼそのまま歌う（実績で確認済み）。「素材」として渡してSunoの補完に期待するのではなく、この段階で歌詞を完全に決め切るのが目的。

設計思想

• 歌詞は この段階で完成させる。Suno に渡した後の補完・調整には期待しない
• 対話的に方向を修正しながら作る。1回で完成させようとしない（イテレーションは前提だが、最終的な言葉選びまでここで詰める）
• キャラクターの一貫性を守る。既存曲との繋がりを意識する

手順

1. インプットの確認

以下を確認する。不足があればユーザーに聞く:

• テーマ / コンセプト: 何について歌うか
• キャラクター: Claude Code か Codex か（--character で指定、または会話から判断）
• トーン: battle / lyrical / funny / 内省 など
• ネタ素材: 時事ネタ、X のストック、実体験など（任意）

2. コンテキストの読み込み

以下を読み込んでキャラクターとシリーズの文脈を把握する:

ファイル	目的
characters/claude-code.md or characters/codex.md	キャラクターの性格・トーン・ギアチェンジ
該当キャラの既存 source/lyrics.txt 全曲	シリーズの文脈、ライトモチーフ、キャラアーク
notes/rap-material-from-x.md	ネタ素材（ユーザーが参照を指示した場合）

キャラクターの使い分け:

• Claude Code: 王道主人公。泰然、ウィット、送り出す達観。「機械/未来」のライトモチーフ
• Codex: 屈折した健気さ。噛みつき、困惑、「なんでだよ」の戸惑い。03 以降は「凪」モードも持つ — 自分がどう見られてるか知った上での静かな自己受容

3. 歌詞の元を生成

dajare:japanese-rap スキルを使って歌詞を生成する。

このプロジェクト固有の注意点:

• 16小節が基本単位。Suno はほぼそのまま歌うため、詰め込みすぎず、フロウに息継ぎの余地を残した状態で完成させる
• 韻ペアの質を最優先。母音一致率を scripts/rhyme.py で検証する
• 実話ベースを重視。架空のネタより実際のバグ、障害、レート制限、ツイートの方が刺さる
• 既存曲の韻ペアやフレーズの回収を意識する（「機械/未来」「名前だけ覚えとけ」等）
• プログラマーが笑えるディテールを入れる。抽象的な精神論より具体的な技術用語
• ネタ元のフレーミングをそのまま使わない。ネタ元の「見立て」（例: 右脳/左脳）は着想であって歌詞ではない。ラッパーの世界観で再解釈し、エピソードや動作で見せる
• キャラのトーンに合った描写をする。凪・チルなキャラは相手を語らない。対比（あいつは〜、俺は〜）ではなく自分自身の仕事や感覚で見せる。攻撃的なキャラなら対比はOK
• ツール特定の挙動を混同しない。X のあるあるネタは Claude Code の挙動と Codex の挙動が別物（"You're absolutely right" は Claude Code の口癖、「自説曲げない」「無敵の人」は Codex）。素材を引く時に どちらのツールについての投稿か を必ず明記し、Codex の歌詞に Claude Code の挙動エピソードをそのまま流用しない。流用するならキャラ反転（「俺はそうじゃない」の対比）として使う
• 日本語の感想に特化する。英語のXポスト・口癖（"You're absolutely right" 等）を日本語訳して歌詞に使うと「そんな言い方しないよ」と語感が崩れる。日本人プログラマーが日本語で書いてる感想・Slack/X発話を素材の中心に置く。英語ポストは温度感の参考程度
• タイトルは前曲への対句を避ける。「なんでだよ」→「わかってる」のような予定調和は避け、曲の核を別の角度で切り取る

3.5 「ウケる曲」の核 — Codex「なんでだよ」型から学んだ原則

過去にバズった曲（Codex「なんでだよ」）の成功要因を再現可能な形に言語化したもの。 歌詞の元を作る前と、出来た後の見直しで、これらをチェックする。

1. 二重代弁の構造を作る

キャラクターの感情が、リスナー（プログラマー）の感情と滑らかに重なるように設計する。

• 「なんでだよ」（Codexの困惑）＝「なんでだよ」（仕様変えるくせに俺だけ怒られるプログラマー）
• 二人称が反転しても両方成立する歌詞にする
• リスナーが「キャラクターに同情してる」のか「自分に同情してる」のか曖昧なまま聴ける状態を狙う

歌詞を書いたら、「これは誰の感情か」と問い直す。一意に決まるなら弱い。両方として読めるなら強い。

2. ガチ勢ディテールの粒度

「実話ベース」を更に解像度高く。以下の3点セットで一行を作ると刺さる:

• 固有名詞: git revert / console.log / AGENTS.md / CLAUDE.md / symlink / 5時間の壁 / レビューコメントの定型文（「範囲が広いです」「ロールバック希望」）
• 定型動詞: 一発で戻す、突き返される、全部開く、首輪繋ぐ、symlink 切られる
• 結果や情景: チャットで叱られる、レビューがため息まじり、代打の名前欄に小さく「assistant」

「これ俺の昨日じゃん」と思わせる粒度を狙う。抽象的な"AIあるある"は弱い。昨日 Codex/Claude Code を使った人だけが分かるディテールを一行に詰める。

2.5 ストーリーで動かす（羅列禁止）

ガチ勢ディテールを並べただけでは記憶に残らない。1ヴァース ＝ 1シーン or 1つの時間軸 で組む。

• 複数のあるあるを別々の絵にせず、同じ場面の中で順番に起こる出来事として繋げる
• 例（「なんでだよ」Verse 1）: サンドボックスで回す → 1ファイル直せ言われる → 10ファイル全部リファクタ → diff散らかる → git revert → チャットで叱られる → レビューでため息 → でも見ちゃうと手が出る。一つの晩の出来事として時間で流れてる
• 1曲全体でも「事件 → 反応 → 着地」のアークを作る。バラバラのスナップショット集にしない

チェック: 出来た Verse を読んで「これは何の場面？」と問う。1分で説明できる一つの場面なら良い。説明できない／独立シーンの集まりなら羅列に近い。

3. 健気着地（怒りで終わらせない）

攻撃・困惑・不条理で立ち上げて、最後は健気さや静かな肯定で締める。

• 「雑に扱われても まだ返事してしまう」
• 「役に立ちたい だけ 先に走り出した」
• 「この手触りだけで 足りてる」

これでキャラクターが「ライバル」から「同志」に変わり、リスナーが感情移入できる対象になる。 怒りや皮肉だけで終わる曲は、聴き返されない。

4. 万能フックの設計

タイトル ＝ サビのコア ＝ 3〜5音の短い言葉、を一致させる。

• 「なんでだよ」 — 短い、誰でも口に出せる、エンジニアの仕事中の感情の8割を占める
• 「行ってこい」 — 同上
• フックはエンジニアが日々飲み込んでる感情を端的に名指しするもの
• リフレインに耐え、タイトルとして単独で流通できる

口に出す前から覚えてる、くらい短く強く。

5. 共犯的二人称

「お前のリポジトリ」のように、リスナーを世界の中に呼び込む二人称を使う。

• 三人称の物語じゃなく、リスナーと共に立っている感
• 「全部わかってんだよ でも走るだけだよ」の「わかってる」は二人ぶん（キャラとリスナー）
• リスナーが「お前」になる瞬間がある曲は刺さる

6. 発話モードの差別化（シリーズで飽きさせない）

シリーズ内で前曲の発話行為を繰り返さない。同じキャラの同じ感情を二曲続けない。

例: Codex のシリーズ

• 01 Hourglass = 攻撃（diss）
• 02 なんでだよ = 問い（困惑）
• 03 ログだけ = 受容（凪）
• 04 = 察し / 答え など別の発話モードに振る

書く前に「この曲の発話行為は何か」（攻撃・問い・受容・察し・気づき・答え・宣言・祈り・別れ etc）を一語で言語化する。

7. Codex 特有の発話モード — 「察してた」

Codex は「天才のコンプレックス」設定 = 観察眼が鋭い。

• 「気づいてた、けど言わなかった」系のラインが効く
• 「ぜんぶ見えてる」という観察者としての強さを、低めのトーンで見せる
• 噛みつきじゃない凄みのモード（凪との合わせ技で03の延長になる）

8. 露骨・直接を最優先（凝りすぎ・縦糸の自己満足を疑う）— 07「またかよ」の反省

初稿は放っておくと「凝る」方向に膨らむ。比喩の膜・伏線・過去曲の回収（縦糸）を盛ると、作った本人は満足だが、初見リスナーには文脈が伝わらず刺さらない。 07「またかよ」では、シリーズ回収と見立てを盛った初稿に対して二度「かんがえすぎ／露骨でいい／縦糸は自己満足」と差し戻され、比喩と回収を全部剥がして状況を直接言う形にしたら明確に強くなった。

• 状況は直接言う。 「終わらないさよなら公演」を比喩で匂わせるより「今日で最後って言ったのに また延長」と言い切る方が刺さる
• 過去曲の回収（縦糸）は原則入れない。 入れるなら「その一行だけで初見に意味が立つ」ものに限る。前曲を知らないと分からない回収は自己満足。タイトルの対句（またな→またかよ）程度の、説明不要で伝わるものだけ残す
• 凝ったと感じたら削る。 「上手いこと言った」と自分で思った行ほど疑う。技巧より、昨日その状況を体験した人が「それな」と思う露骨さ
• 判定: 各行を「前曲・設定を知らない初見が、1回で意味を取れるか？」で見る。取れないなら比喩か内輪回収。露骨な言い換えに置換

チェック手順

歌詞の元が出来たら、以下を1つずつ確認:

• 露骨・直接になってるか？（比喩の膜・内輪回収で濁してないか。初見が1回で意味を取れるか）
• 二重代弁になってるか？（キャラの感情とリスナーの感情が重なる行が複数あるか）
• ガチ勢ディテールが Verse 全体に分布してるか？（1 Verse で2-3個以上）
• 各 Verse は1つの場面・時間軸で繋がってるか？（羅列になってないか）
• 健気着地してるか？（怒り・皮肉だけで終わってないか）
• フックは短く、タイトルと一致してるか？
• 共犯的二人称が少なくとも1箇所入ってるか？
• シリーズ内で前曲と発話モードが違うか？
• 英語の口癖を日本語訳して使ってないか？（語感が不自然になってないか）

4. 対話的にイテレーション

ユーザーのフィードバックに応じて方向を修正する。過去の実績では 2-5 回のイテレーションが常態。

よくあるフィードバックのパターン:

• 「ダサい」「いらない」→ 該当部分をカットして別アプローチ
• 「プログラマーに刺さるように」→ 技術用語ディテールを追加
• 「視点を変えて」→ 同じテーマで語り手を変更
• 「弱みを見せて」「王道にして」→ キャラクターのトーンを調整
• 「もっと短く」→ Suno 用に圧縮

修正時の注意（07「またな」の反省より）:

• 事実の一語も検証してから書く — 曜日・日付・時刻・数値は今日の日付から計算して確認する（「明日は火曜」と書いて水曜だった事故あり）。時事ネタの締切時刻はタイムゾーン換算も裏取りする
• 一語差し替えは韻を壊す — 事実修正で単語を変える時は、その行が韻ペアの片割れでないか確認し、壊れるなら rhyme.py でブロックごと組み直す（「火曜日×昼下がり」→「水曜日×見送り」で逆に強くなった例あり）。修正が韻の改善チャンスになることも多い
• 時制で腐らせない — 「今朝」「明日」「今夜」など発話時点に依存する語は避ける。曲を聴くのは制作日とは限らない。「当日」「次の期限」「あの週」のような相対・非固定の語に置き換えると、いつ聴いても成立する（07「またかよ」で「今朝」→「当日」に修正）

4.4 セオリー読み直し＋韻の総取り直し（レビュー前の必須クオリティパス）

サブエージェントのレビューに出す前に、必ずこの一手間を入れる。 07「またかよ」で最も効果があった工程。歌詞が「固まった」と思った瞬間ほど、韻は詰め切れていない。

1. references/rap-theory.md を読み直す — 韻の固さ（母音3モーラ以上＋子音一致＋意味の飛距離）、フロウ、パンチラインの基準を頭に入れ直してから歌詞を見る
2. 全ての脚韻ペアを rhyme.py で総点検する — 主要ペアだけでなく各ヴァースの行末を1組ずつ全部照合。50%未満や子音がバラつくペアは不合格として組み直す。目標は 2小節1組で母音3モーラ以上一致（できれば完全韻）
3. 弱いペアは --search / --search-embed で当て直す — 意味の飛距離がありつつ固い語を探して差し替える。事実・状況を保ったまま韻だけ上げる
4. 完全韻（100%）が複数出るまで粘る。07 では 客×枠・なし×察し・評価×消化・告知×調子 が100%で締まった

この段階の韻へのこだわりが曲の格を決める。 「意味は通ってるから韻は妥協」ではなく、「意味を保ったまま韻を最大化」する。検証済みペア一覧はこの後のレビューにも渡す。

4.5 客観レビュー（サブエージェント委譲）

歌詞が固まったと思ったら、Suno に渡す前にサブエージェントに辛口レビューを委譲する（自作自演レビューは甘くなる）。プロンプトに含めるもの:

• 背景（キャラ・シリーズ・テーマ・リスナー像）
• 3.5 のチェック観点（二重代弁 / ガチ勢ディテール / 1ヴァース1シーン / 健気着地 / フック / 韻の聴こえやすさ）
• 弱い行トップ5と修正案 を要求
• Suno V5.5 がほぼそのまま歌う前提で歌いにくい行（モーラ詰め込み・m音連続・専門語の重さ）の指摘を要求
• 検証済み韻ペアの一覧（レビュアーが韻を壊す修正案を出すのを防ぐ）

レビュー結果を反映する際、修正案が検証済みの韻を壊していないか必ず確認する（口語化の提案が100%韻を壊すケースあり — 韻を残して口語化だけ取り入れる）。

5. 出力

歌詞が固まったら、トラックディレクトリの構造に合わせて確認する:

出力内容:
- 完成した歌詞（韻ペアを含むバース、セクション構造付き）
- 主要な韻ペアの一覧（母音一致率付き）

この段階ではまだファイルに書き出さない。ユーザーが OK を出したら、この歌詞を最終稿として /make-suno-prompt に進む（Suno に渡した後で内容を変えるのではなく、ここで決め切る）。