音楽リリースのメタデータ — アーティスト名、タイトル、参加アーティスト、バージョン表記、そして配信チェーンを無事に通過する書き方

日本語表記（全角・半角、よみがな、漢字／かな／ローマ字）を正面から扱った技術リファレンス。

最初に、結論

配信ストアはあなたの音を聴かない。読むのはあなたが入力した文字列だけである。したがって日本語リリースで最初に決めるべきは音質でもジャケットでもなく、アーティスト名の正準表記を一つに固定すること、全角と半角を混ぜないこと、そしてよみがなフィールドを空にしないことの三点だ。全角英数字（ＡＢＣ／１２３）と半角カナ（ｱｲｳ）は、見た目が似ているだけの別のコードポイントであり、Unicode の正規化のうち NFC と NFD はこれらを一切変換しない。変換するのは NFKC / NFKD だけで、しかもその変換方向は英数字と仮名で逆を向く——ここを取り違えている日本語の解説記事は非常に多い。同じ演者が漢字・かな・ローマ字の三通りで登録されればアーティストページは三つに割れ、割れたページは合算されないまま再生数だけを分散させる。そして作曲者欄に「伝統」と書いた民謡アレンジは、編曲者に入るはずだった出版側の収益を放棄している。

以下は、その一つひとつの機構を、原典を引きながら説明する文書である。

1. メタデータは三つの層に分かれている

リリースは単一の物体ではない。リリース（商品） の中に レコーディング（音源） があり、各レコーディングは一つ以上の 作品（楽曲そのもの） を体現している。層ごとに識別子が違い、層ごとに金の流れが違う。

高くつくメタデータ事故のほとんどは、正しい事実を間違った層に書いた結果である。伝送規格そのものは標準化されていて、リリースとその情報がストアに届く経路は DDEX の ERN（Electronic Release Notification Message Suite） である。

主要フィールドの役割を短く確認しておく。

プライマリーアーティスト（主アーティスト）。 名義。このフィールド「だけ」が、音源がどのアーティストページに着地し、誰にリスナー数とフォロワーとアルゴリズム上の履歴が積み上がるかを決める。Spotify の公開ガイドラインは端的だ。"List each artist's name in a separate field"（各アーティストの名前は個別のフィールドに入力すること）。

フィーチャリングアーティスト。 同じ音源上の別ロール。主名義を与えずにクレジットし、相手のページへリンクする。Apple のスタイルガイドは、フィーチャリングはトラックレベルで Featuring または With ロールとして立て、"not as Primary"（プライマリーとしてではなく）と明示している。

リミキサー。 これもロールである。Apple: "Remix tracks...must list the original artist as Primary with the remixer assigned the remixer role."（リミックスは原アーティストをプライマリーとし、リミキサーにはリミキサーロールを割り当てる）。リミキサーを主アーティストに入れるのが、リミックス集がアーティストページを汚染する典型経路だ。

作曲者・作詞者。 これは作品の情報であって音源の情報ではない。出版印税・録音使用料がここから辿られる（第8章）。

バージョン／サブタイトル。 同じ曲名を持つ別音源を区別するための括弧内表記。Live、Instrumental、Radio Edit など（第7章）。

Explicit フラグ。 文字列ではなく真偽値である。Apple: "Explicit content must be flagged Explicit with a parental advisory tag. Terms like (Explicit)...must not be used for album...or track titles." Spotify も "you shouldn't add it to your track title" と書いている。逆方向、つまりタイトルに「Clean」「Non-explicit」と書くことも Music Biz のスタイルガイドは禁じている。

歌詞の言語（何語で歌われているか）とタイトルの言語（タイトル文字列がどの言語・どの文字体系か）は別のフィールドで、正当に食い違う。尺八と箏による純器楽曲に日本語タイトルを付けたなら、歌詞言語は非言語（zxx）、タイトル言語は日本語である。タイトル言語はストアが文字列をどう索引し、どう並べ、どう表示するかを決める。日本語リリースではもっとも結果を左右するフィールドの一つだ。

Pラインは音源の最初の発行年＋原盤権者、Cラインはアートワーク／パッケージの年＋権利者。互換ではない。年は「配信の登録年」ではなく「その音源が最初に発行された年」である。

識別子の正確な形。 ISRC は12文字（国2＋登録者3＋参照年2＋指定番号5）。ハイフンは表示上の慣習にすぎず、コードの一部ではない。ISRC にチェックディジットは存在しない。 UPC-A は12桁、EAN-13 は13桁で、先頭にゼロを付ければ EAN-13 になり、チェックディジットは変わらない。

リミックス、エディット、ライブ、インストゥルメンタルは実質的に別の録音なので新しい ISRC が要る。単なる再配信には要らない。リマスターは狭い例外で、IFPI の ISRC ハンドブック（§A.10.1）は新コードを要求するのは再マスタリングの工程が "involve the application of creative input to the recording itself"（録音そのものへの創造的関与を伴う）場合に限るとし、単純なレベル変更、不変の EQ・コンプ、ノイズ除去、クリック除去、速度・ピッチ補正、サンプルレート変換、ディザリングを明示的に除外している。実務上安全な補足は、リマスターを原盤と並べて別トラックとして売るなら、それは別商品なので固有のコードが要る、という一点だ。

2. 全角と半角 — 日本語メタデータの中心的欠陥

日本語のメタデータ事故の過半は、ここに集約される。ラテン文字圏の解説書には対応する章が存在しない。

2.1 何が起きているか

日本語入力環境は、同じ文字に見えるものを二系統持っている。

• 英字：Ａ Ｂ Ｃ（U+FF21–U+FF23、全角）と A B C（U+0041–U+0043、ASCII）
• 数字：１ ２ ３（U+FF11–U+FF13）と 1 2 3（U+0031–U+0033）
• 記号：！ ？ （ ） ： －（U+FF01, U+FF1F, U+FF08, U+FF09, U+FF1A, U+FF0D）と ASCII の ! ? (): -
• 空白：全角スペース（U+3000）と ASCII スペース（U+0020）
• 仮名：アイウ（U+30A2…）と ｱｲｳ（U+FF71…、半角カナ）

これらは字形が似ているだけの完全に別の文字である。ストアの照合系にとって ＭＩＹＡＫＯ ＴＲＩＯ（全角）と MIYAKO TRIO（半角）は共通する文字を一つも持たない二つの文字列であり、津軽三味線 ｵｰｹｽﾄﾗ（半角カナ）と 津軽三味線 オーケストラ も同様に別物だ。人間の校正者は画面上の幅の違いに気づくが、幅は等幅フォントでしか安定して見えず、ウェブの入稿フォームの多くはプロポーショナルフォントで表示される。

Spotify は自身のヘルプでこう書いている。"We display your music exactly as it's delivered to us"（当社は納品されたとおりに音楽を表示します）。つまり全角で納品すれば全角のまま出る。ストアが直してくれるという前提は成り立たない。

2.2 Unicode 正規化が実際に何をするか（検証結果）

「正規化すれば直る」という説明が日本語の記事には多く流通しているが、どの正規化形が何を直すかを正しく書いているものはほとんどない。以下は Python の unicodedata（Unicode Character Database 14.0.0）で実際に四形式を適用して確認した結果である。正規化の写像は Unicode の安定性保証（Normalization Stability）の対象なので、この結果はバージョンをまたいで変わらない。

ここから読み取るべき事実は四つある。

第一に、NFC と NFD は全角・半角の問題を一切解決しない。 全角英数字も半角カナも全角スペースも、NFC を通しても NFD を通してもそのままである。「NFC に正規化しておけば安心」は、日本語に関しては誤りだ。NFC が直すのは濁点・半濁点の分解（カ ＋ U+3099 → ガ）だけで、これは Mac の一部のファイルシステム経由やコピーペーストで発生する別種の事故である。それは確かに価値のある修復だが、全角の問題ではない。

第二に、変換するのは NFKC / NFKD だけであり、その方向は文字種によって逆を向く。 全角英数字と全角記号は半角（ASCII）へ落ちる。半角カナは全角カタカナへ上がる。半角長音 ｰ は全角長音 ー へ、半角中黒 ･ は全角中黒 ・ へ上がる。つまり NFKC は「半角に統一する」処理でも「全角に統一する」処理でもなく、文字種ごとに Unicode が定めた「基本形」へ寄せる処理である。この非対称を理解しないまま NFKC を「全角を半角にする関数」として使うと、カタカナ表記が意図せず書き換わる。

第三に、NFKC は無条件に使ってよい処理ではない。 Unicode 標準附属書 #15（Unicode Normalization Forms）自身が警告している。"Normalization Forms KC and KD must not be blindly applied to arbitrary text. Because they erase many formatting distinctions... they may remove distinctions that are important to the semantics of the text."（正規化形式 KC と KD を任意のテキストに盲目的に適用してはならない。多くの書式上の区別を消し去るため、テキストの意味にとって重要な区別を除去しうる。）同附属書は日本語をまさに例に挙げている。"the halfwidth and fullwidth katakana characters will normalize to the same strings"（半角カタカナと全角カタカナは同じ文字列に正規化される）。

第四に、最悪の副作用がある。 カタカナに単独の濁点 U+309B（濁点キーで入力すると環境によってはこれになる）が続く文字列は、NFC でも NFD でも直らない。しかし NFKC を通すと カ ＋ 半角スペース ＋ 結合濁点 U+3099 という三文字になる——アーティスト名の途中に空白が挿入される。合成済みの ガ（U+30AC）を使っていればこれは起きない。

2.3 半角カナ（U+FF61–U+FF9F）は納品してはいけない

半角カナは 1970 年代の 1 バイト日本語表現の遺物で、Unicode では互換文字領域に置かれている。UAX #11（East Asian Width）はこの領域の性格を、"ED3. East Asian Halfwidth (H): All characters that are explicitly defined as Halfwidth in the Unicode Standard by having a compatibility decomposition of type <narrow>"（互換分解 <narrow> を持つことで半角と明示的に定義された文字）と定義している。互換分解を持つ＝それは正規の文字の代替表現である、というのが Unicode 側の位置づけだ。

実務上の帰結は単純である。半角カナはメタデータフィールドに入れない。CD の CD-TEXT や古い納品仕様書からコピーしてきた ﾂｶﾞﾙｼｬﾐｾﾝ のような文字列がそのまま入稿される事故は、いまも珍しくない。半角カナで納品された名義は、全角カタカナで登録済みの同じ名義とは別のアーティストになる。

2.4 実務ルール

1. アーティスト名・タイトルの本文は、全角カタカナ・ひらがな・漢字と、半角 ASCII 英数字で書く。 つまり日本語部分は全角、ラテン文字と数字は半角。これが国内外どのストアでも破綻しない唯一の組み合わせである。
2. 全角英数字（ＡＢＣ／１２３）は使わない。 バンド名を意図的に全角で表記しているアーティストはいるが、その表記は検索でヒットせず、ローマ字ローカライズフィールドとも一致しない。デザイン上の意図はジャケットで表現し、フィールドには半角で書く。
3. 全角スペース（U+3000）を混ぜない。 全角スペースは trailing space と同じくらい静かに文字列を割る。特にタイトル末尾に残った全角スペースは、目視でも Ctrl+A でも見つけにくい。
4. 半角カナは一切使わない。
5. 感嘆符・疑問符・括弧・コロン・ハイフンは半角。 ただし日本語の読点・句点（、。）と鉤括弧（「」）はそれ自体が日本語の文字であり、半角相当物は存在しない（｡ ｢ ｣ ､ は半角カナ領域の互換文字なので使わない）。
6. NFKC を機械的にかけるなら、かけた後の文字列を必ず目視確認する。 波ダッシュ（次章）とカタカナの挙動が変わる。
7. 決めた正準文字列はファイルに保存し、毎回ペーストする。再入力は変種の製造工程である。

日本語メタデータの誤り率について公表された統計は、私たちの知る限り業界のどこにも存在しない。問題は普遍的に経験されているが、まったく計量されていない。

3. 記号 — 長音符、中黒、波ダッシュ、鉤括弧

3.1 長音符 ー（U+30FC）と、それに似た七つの文字

ー は U+30FC KATAKANA-HIRAGANA PROLONGED SOUND MARK（長音符）である。ダッシュでもハイフンでもない。しかし字形が近い文字が大量にあり、日本語入力から離れた環境でタイトルを編集すると容易に置き換わる。

シャドー を シャド-（ASCII ハイフン）と入力した文字列は、検索でもソートでも別語である。NFKC は U+FF70 を U+30FC に上げるが、ASCII ハイフンを長音符に直すことはしない（する道理がない。それは意味の変更であって正規化ではない）。長音符の誤りは正規化では絶対に直らない、と覚えておけばよい。

3.2 中黒 ・（U+30FB）

外国人名やユニット名の区切りに使う ・ は U+30FB KATAKANA MIDDLE DOT である。ジョン・コルトレーン の ・ はこれ。半角の ･（U+FF65）は半角カナ領域の互換文字なので使わない。ラテン文字圏でよく使われる ·（U+00B7 MIDDLE DOT）や •（U+2022 BULLET）も別文字で、日本語の中黒としては不適当だ。

中黒はまた、それ自体が区切り記号だとストアに解釈されるとは限らない点に注意が要る。尺八 山口秋水・箏 井筒真弓 のように一つのアーティストフィールドに二人を書き込むのは、第4章で述べる理由により誤りである。中黒はあくまで一人の名前の内部（アンドレ・ジョリヴェ）か、一つの名義の内部（太鼓ユニット・篝火）で使うものだ。

3.3 波ダッシュ問題 — ～（U+FF5E）と 〜（U+301C）

これは日本語の文字コードにおける最も有名な罠であり、いまなお現役である。

日本語のタイトルでサブタイトルを挟む記号 〜 は、本来 U+301C WAVE DASH である。しかし Windows 上の Shift_JIS ↔ Unicode 変換の歴史的経緯により、日本語 Windows 環境で入力される「～」は U+FF5E FULLWIDTH TILDE になることが多い。両者は字形が似ており、フォントによってはほとんど区別がつかない。

検証した挙動は次のとおりである。

• U+301C（波ダッシュ）は NFC・NFD・NFKC・NFKD のいずれでも変化しない。
• U+FF5E（全角チルダ）は NFKC / NFKD で ASCII のチルダ ~（U+007E）になる。 NFC・NFD では変化しない。

つまり 桜前線～北へ～（U+FF5E）というタイトルを、NFKC をかけるパイプラインに通すと 桜前線~北へ~ になる。同じタイトルを U+301C で書いていれば、何も起きない。同一のアルバムの中で、1曲目を Windows で、2曲目を Mac で入力しただけで、二種類の波ダッシュが混在する。目では見つからない。

実務上の推奨。 サブタイトルを波ダッシュで挟む慣習そのものを、配信メタデータでは避けるのが最善である。バージョン情報は波ダッシュではなくバージョンフィールドに入れる（第7章）。それでもタイトルの一部として波ダッシュが必要な場合は、カタログ全体でどちらか一方に固定し、納品前にコードポイントを確認する。どちらを選ぶかより、混在させないことが重要だ。

3.4 鉤括弧 「」 と 二重鉤括弧 『』

「」（U+300C / U+300D）と 『』（U+300E / U+300F）は日本語の正規の引用符であり、四つとも正規化で変化しない。安全な文字である。

問題は使用箇所だ。日本語の出版慣習では、楽曲名を「」で、アルバム名・作品名を『』で囲む。しかしメタデータのタイトルフィールドは、すでに「これはタイトルである」というフィールドである。そこにさらに 「祭囃子」 と括弧を書き込めば、ストアの表示は 「祭囃子」 になる。曲名が括弧つきで表示され、検索クエリ 祭囃子 と完全一致しなくなる。

したがって：

• 曲名・アルバム名そのものを「」『』で囲まない。
• 括弧の中身が作品の一部として意味を持つ場合——引用、題名の入れ子、タイアップ元の明示——だけ使う。例：エンディングテーマ（アニメ『霧笛の宿』より）。
• Apple のスタイルガイドは、中国語のサウンドトラックについては "the title of movie or TV drama must be enclosed in Chinese guillemets《》"（映画・ドラマ名は中国語の二重山括弧《》で囲む）と明記しているが、日本語の「」『』については同等の公開ルールを持たない。ここは「公開されていない」と正直に書くべき領域である。日本語の慣習を優先しつつ、括弧を装飾として使わない、という原則で運用するほかない。

4. 三重表記問題 — 漢字、かな、ローマ字

日本のアーティストは、世界のデータベースの中に最大で三つの名前を持つ。三上美咲、みかみみさき、Misaki Mikami。すべて同一人物の正しい表記である。そしてストアと管理事業者と原盤権者は、どれを正準とするかについて合意していない。

結果として起きることは決まっている。アルバム1枚目を漢字名義で出し、2枚目のジャケットデザインに合わせてローマ字名義で出し、演歌のコンピレーションに参加したときに主催者がかな名義で登録する。三つのアーティストページが生まれる。フォロワーは最初のページにしかいない。二つ目と三つ目はアルゴリズム上の履歴がゼロの状態から始まる。印税は支払われるが、三つの累積履歴に分かれて支払われ、カタログ単位で測られるもの——エディトリアルの検討、アナリティクス、認証——はすべて三分の一のキャリアに対して測られる。

主要なスタイルリファレンスはどちらも同じことを言っている。Music Biz の Music Metadata Style Guide: "Artist name spelling should remain consistent for all content for an artist, where possible."（アーティスト名の綴りは、可能な限りそのアーティストの全コンテンツで一貫させること。）Spotify: リリースごとに綴りとフォーマットを一貫させ、"including any punctuation, abbreviations, or acronyms"（句読点、略記、頭字語を含めて）。

4.1 規律

一つを主名義に決める。他は読み／別名フィールドに登録する。 決め方は優先順位で考える。

1. すでに公に使っている表記（SNS のアカウント名、公式サイト、既発のジャケット）。既存の足跡との整合が、言語的な正しさに勝つ。
2. 既発リリースのうち最大のもので使っている表記。
3. ターゲットの聴き手が実際に入力する表記。国内向けの演歌・歌謡曲・民謡であれば、ほぼ確実に漢字またはかなである。国外を主戦場にする邦楽ユニットであればローマ字が合理的なこともある。
4. 迷ったら漢字。日本語話者の検索行動の中心であり、かなとローマ字は読みフィールドとローカライズフィールドで補える。

決めたら、残りは捨てるのではなく、それ用のフィールドに入れる。データモデルがそれを持っているからだ。

• よみがな／フォネティックフィールド → かな表記（第5章）
• 英語ローカライズフィールド → ローマ字表記

Apple はこの設計思想をキリル文字について明文化している。"Content in languages that use the Cyrillic alphabet should not be submitted with transliterated titles. Use Cyrillic in the native title field, English in the English localization field, and transliteration in the available phonetic field."（キリル文字圏のコンテンツを翻字したタイトルで納品してはならない。ネイティブタイトルフィールドにキリル文字を、英語ローカライズフィールドに英語を、利用可能なフォネティックフィールドに翻字を入れること。）日本語も同じ構造である。ネイティブフィールドに漢字、ローカライズに英語／ローマ字、フォネティックにかな。

4.2 ローマ字表記は「第二の実名」である

ローマ字は標準化されていない。実務上の揺れは長音の扱いに集中する。

大野 は Ohno / Ōno / Ono / Oono のどれでもありうる。東京 は Tokyo / Tōkyō / Toukyou。新宿 は Shinjuku / Shinjyuku。ふ は fu か hu か。じ は ji か zi か。ん の前の n を m にするか（Namba / Nanba）。

どれも擁護できる。そして照合系にとってはすべて別のアーティストである。学術的に正確なマクロン付き表記（Ōno）は、正しいが誰も入力しない。パスポート式のヘボン式（Ohno）は、検索されやすいが長音の情報を失う。

選び方の原則は一つ、曖昧な音ごとに一つの選択を固定して二度と変えないこと。そしてその決定を、正準文字列のファイルに書いて残す。

5. よみがなフィールド — 空欄にしてはいけない理由

日本語には、他の主要言語のほとんどが持たない構造的な問題がある。漢字列から読みが導出できない。

東海林 は「しょうじ」とも「とうかいりん」とも読む。一二三 は「ひふみ」「かずふみ」「いちにさん」。美咲 は「みさき」だが 美 を「よし」と読む名もある。バンド名 篝火 は「かがりび」だが、これを機械が知る方法はない。

したがって：

• 日本語は、よみがなフィールドなしでは五十音順に並べられない。 ストアやカラオケ配信のアーティスト一覧、コンピレーションのトラック順、国内のデータベース——いずれも読みを外部から与えられる必要がある。
• 検索でも同じことが起きる。 ひらがなで検索するリスナーは、漢字だけで登録された名義に到達しない場合がある。

Apple はフォネティックフィールドの用途を明示している。"Providing phonetics enhances the discoverability of your content. Use phonetics in the phonetic fields. Use Katakana or Hiragana for Japanese, and Roman characters for the other languages. Symbols (stars, hearts, and so on) must not be used in any phonetic fields."（フォネティクスの提供は発見性を高める。フォネティックフィールドに入力すること。日本語にはカタカナまたはひらがなを、他の言語にはローマ字を使う。記号（星、ハートなど）はフォネティックフィールドに使ってはならない。）

5.1 空欄にしたとき、漢字を入れたときに何が起きるか

空欄にした場合。 システムは読みを推定するか、諦めるかのどちらかである。推定するシステムは形態素解析で最頻の読みを当てにいくので、東海林太鼓連 は「とうかいりんたいこれん」になりうる。諦めるシステムは、五十音順のリストの末尾か「その他」に落とす。どちらも、あなたが直せる場所には現れない。

漢字をそのまま入れた場合——これが最も多い誤りである。 よみがなフィールドに 三上美咲 と入力すると、システムは「このアーティストの読みは『三上美咲』という文字列である」という情報を受け取る。これは形式的には有効な値なので、バリデーションを通過する。そしてソートキーとして使われた瞬間、漢字のコードポイント順（あるいは Unicode 照合順）で並ぶ。空欄より悪い。空欄なら推定の余地があるが、埋まっている値は疑われない。

カタカナとひらがなを混ぜた場合。 ミカミみさき のような値は、そのまま二種類の照合キーを持つことになる。カタログ内でどちらかに統一する。国内の慣習ではカタカナ（フリガナ）が優勢だが、統一されていることのほうが重要だ。

記号を入れた場合。 ♪ミカミミサキ♪ は Apple の明文の禁止に触れる。長音符 ー は読みの一部なので許容されるが、・ を区切りに使うのはフィールドの設計意図から外れる。

5.2 何を入れるか

• 漢字名義 三上美咲 → よみがな ミカミミサキ
• ローマ字名義 LUNAR TSUGARU → よみがな ルナツガル（外来語名義でも読みは要る）
• 記号を含む名義 篝火 / KAGARIBI → よみがな カガリビ（記号と英字部分は読みに含めない）
• 楽曲タイトルにもよみがなフィールドがあるなら埋める。篠笛独奏「暁」 → シノブエドクソウ アカツキ

6. feat. の扱いと、タイアップ表記をタイトルに書く慣習

6.1 タイトルフィールドに演者名を書かない

独立系配信でもっとも多く、もっとも高くつく入力ミスは、タイトルフィールドに 〇〇 feat. △△ と書き、フィーチャリングのロールフィールドを空のままにすることである。

タイトルフィールドは表示用の文字列であって、同一性を運ばない。結果として、フィーチャリングされた側にはクレジットリンクも、自分のページへの掲載も、あなたの音源への導線も、アナリティクス上の数字も、何も入らない。同時にストアは feat. △△ を曲名の一部として扱うので、曲名は永久に 霧笛の宿 feat. 山口秋水 になる。そして正しくロールを入れた再納品をすると、霧笛の宿 feat. 山口秋水 (feat. 山口秋水) という重複表示が生まれる。

各社の記述は明確だ。Spotify: "You shouldn't include any artists' names in your track or release titles."（トラックタイトルやリリースタイトルにアーティスト名を含めるべきではない。）Spotify のプロバイダ向け文書: "Spotify strongly recommends against including additional information, such as references to 'Featured Artists' in track and product titles."（トラック名・商品名に「フィーチャリングアーティスト」への言及などの追加情報を含めないことを強く推奨する。）Music Biz は、フィーチャリングアーティストは "at the Artist role level and not add this data to the track or album release title"（アーティストロールのレベルでクレジットし、このデータをトラック名やアルバム名に追加しない）と助言している。

6.2 契約上どうしてもタイトルに書く場合

書式は各社で一致している。Music Biz は "feat." と "with" について、"when included in the title are generally lowercase and in English"（タイトルに含める場合、原則として小文字かつ英語）。Apple: "Formatting of 'feat.' and 'with' must be lowercase, in English, not localized, and in parentheses or brackets."（"feat." と "with" の表記は小文字・英語・非ローカライズで、丸括弧または角括弧に入れること。）

この "not localized" は日本語にそのまま効く。 （フィーチャリング 山口秋水） （feat．山口秋水）（全角ピリオド）（ft.山口秋水） はいずれも不可である。feat. は単語ではなく機械可読のトークンだ。書くなら 半角の丸括弧、半角小文字の feat.、半角スペース、そして中身のアーティスト名は正準表記——(feat. 山口秋水)。

6.3 「〇〇より」とタイアップクレジット

日本のリリースには、タイトルフィールドにタイアップ情報を書き込む強い慣習がある。明日への篠笛（NHK連続テレビ小説「霧笛の宿」主題歌）、祭囃子〜映画『篝火』より〜、エンディングテーマ（アニメ『霧笛の宿』より）。CD の帯とパッケージから来た慣習で、国内の店頭では機能してきた。

配信では、これは三つのコストを生む。

1. 曲名が長くなり、モバイルの表示で切れる。 ストアのトラックリストは曲名を切り詰める。タイアップ情報は末尾にあるので、真っ先に消える。
2. 同一楽曲の別バージョンが別曲として索引される。 シングル版が 明日への篠笛（ドラマ「霧笛の宿」主題歌）、アルバム版が 明日への篠笛 なら、ストアの内部では別のタイトルである。ISRC は別でよいが（別録音なら）、リスナーの検索とプレイリストは分断される。
3. タイアップは期限つきである。 ドラマの放送が終わり、二年後にベスト盤に収録するとき、タイトルに焼き込まれた番組名は編集できない情報として残る。

推奨される構造。 タイアップ情報は、可能な限りバージョンフィールドに入れる。Apple はサウンドトラックの版情報を丸括弧で示す形式を規定しており、映画由来のトラックは (From "Name of Film") の形を取ると明記している。日本語なら （映画「篝火」より） をバージョンフィールドに入れ、タイトルフィールドは 明日への篠笛 だけにする。ストアは括弧を自前で付与する（Apple は「バージョンフィールドで納品すれば括弧は Apple が自動的に適用する」と明記している）。バージョンフィールドを持たない配信経路しかない場合は、タイトルに書かざるをえないが、そのときはカタログ全体で書式を一つに固定する。

6.4 声優名義とキャラクター名義

日本のアニメ関連リリースには固有の書式がある。Apple のスタイルガイドは明文で扱っている。"Anime artist names can include both the character name and voice actor in a single field. 'CV' stands for 'Character Voice.' For example: 綾瀬陽菜(CV:花澤香菜)."（アニメのアーティスト名はキャラクター名と声優名を単一フィールドに含めてよい。"CV" は "Character Voice" の略。）これは、演者名をタイトルに入れない原則の例外ではなく、アーティストフィールドの中の書式規定である点に注意したい。タイトルではなくアーティストフィールドに入る。

同じ節の周辺で Apple は、カラオケ、トリビュート、日本のオルゴール盤（"Japanese Orgel"）、パロディ、カバーアルバム、着信音について、"the name of the original artist must not be displayed in any artist field"（原アーティストの名前をいかなるアーティストフィールドにも表示してはならない）と定め、アルバムタイトルについても "The album title must not begin with the original artist name."（アルバムタイトルは原アーティスト名で始めてはならない）としている。オルゴール盤やカバー集を出す国内レーベルは、この二条を直接踏むことが多い。

7. バージョン表記

バージョンフィールドの仕事は、同じタイトルを持つ二つの音源を区別すること、それだけである。それが記入すべきかどうかの判定基準でもある。リリース上に版が一つしかないなら、フィールドは空でよい。

語彙は安定している。Apple: "To differentiate multiple versions of the same track title, use terms in parentheses or brackets such as: Alternate Take...Live, Instrumental, Single Version, Radio Edit."

日本語リリースでの実務的な対応は次のとおり。

• 英語の標準語彙を使う。 (Live) (Instrumental) (Radio Edit) (Acoustic) は機械可読トークンとして扱われる。（ライブ） （カラオケ） は日本語のストア表示では自然だが、国外の照合系では認識されない。国内向けにはローカライズフィールドで補う。
• (Instrumental) と「カラオケ」は同義ではない。 演歌・歌謡曲のシングルに慣例的に収録される「カラオケ」トラックは、ボーカルを除いた同一伴奏である。これは (Instrumental) として扱ってよい。一方、Apple の言う "Karaoke" 商品はガイド上の別カテゴリ（原アーティスト名の表示禁止など固有の規制がかかる）なので、自作曲のカラオケトラックに Karaoke の語を使うと不必要な分類に落ちる可能性がある。(Instrumental) が安全である。
• Radio Edit は「クリーン版」の意味ではない。 Music Biz はこれを放送用に実際に用意された版に限定し、露骨表現を編集した版には Edited Version を使うよう指示している。Radio Edit は通常尺の編集、Edited Version は内容の編集だ。
• Original Mix には実際の食い違いがある。 Apple の公開ガイドはこれを不可としている。"The standard, original version of an album, track, or music video must not include any additional information in the title unless it is needed to identify the content." として、不可の語に "Exclusive, Limited Edition, Album Version, Original Mix, Tone, Alert Tone...Dolby Atmos, lossless, high-resolution audio" を列挙している。Spotify の公開メタデータガイダンスは "Original Mix" を名指しした規則を公開していない（タイトルに追加情報を入れないという一般則があるのみ）。他社の扱いも公開されていない。原盤とリミックスを同時に出すなら、少なくとも一つの配信先でこのラベルが除去または拒否されることを想定しておく。
• バージョンをタイトルに手打ちしない。 ストアが自前で表示文字列を組み立てるため、祭囃子（Live）(Live) が生成される。
• ライブ音源の会場と日付。 Apple はライブ音源の版情報に会場・都市・日付を含める形式を示している。日本語なら (Live at 浅草公会堂, 2025) のように、会場名は日本語のまま、Live at は英語トークンとして残すのが実務的である。

8. 作曲者・作詞者、JASRAC と NexTone、そして「伝統」の代償

原盤と作品は別の権利であり、別の収入である。ディストリビューターが回収するのは原盤側。作品側——演奏権・録音権にもとづく著作権使用料——は、作曲者・作詞者・編曲者のフィールドと、それに続く著作権登録から辿られる。

このフィールド群は独立系リリースの最弱点である。理由は構造的で、ストアの画面に表示されないからだ。作曲者欄が空のリリースは完璧に見え、通常どおり再生される。その裏で著作権使用料が分配先不明のまま滞留する。

• 作曲者・作詞者には本名を書く。 管理事業者は登録された著作者名で照合する。DJ 篝火 は著作者ではなく、その背後の個人が著作者である。
• 一行でも書いた人は全員記載する。 記載漏れは「クレジット漏れ」ではなく「未照合の持ち分」である。
• 分配比率は合計 100% で、リリース前に書面で合意しておく。 メタデータは合意を表現するものであって、合意がなければそれは後で争われる推測にすぎない。
• リミックスは作品を変更しない。 原作曲者・原作詞者は据え置きである。リミックスが新しい創作を加える場合は交渉された分配であって、前提ではない。

8.1 日本の管理事業者

日本には音楽著作権の管理事業者が複数存在する。ここでは、各社が自ら公開している範囲の事実だけを述べる。

JASRAC（一般社団法人日本音楽著作権協会） は自サイトでこう述べている。「私たちJASRACは、音楽クリエイターと音楽出版社で構成される一般社団法人です。音楽著作権の管理を通じて、新しい音楽との出会いが続く豊かな社会を目指しています。」創設は1939年。管理作品の公開検索データベースとして J-WID（作品検索）を運用している。権利者向けには「作品届のご提出」という手続きが案内されている。

株式会社 NexTone は自サイトでこう述べている。「著作権者からの委託を受け、音楽著作物の利用の許諾と使用料の徴収・分配等を行っています。」同社も管理作品の検索を公開している。

ここから先は書かない。 具体的な登録手続きの所要日数、審査基準、分配のタイミング、どちらに委託すべきかといった論点は、本稿の一次情報の範囲外である。実務上言えるのは一点だけ——あなたが配信メタデータの作曲者・作詞者フィールドに書いた名前と、管理事業者に届け出た著作者名が食い違っていれば、照合は難しくなる。両者を同じ文字列にする。ここでも第2章の全角・半角と、第4章の漢字／かな／ローマ字の規律がそのまま効く。山口秋水 と 山口 秋水（全角スペース入り）と ヤマグチシュウスイ は、照合系にとって三つの名前である。

8.2 民謡アレンジを「伝統」で出すことの代償

これは日本語圏で最も頻繁に、最も静かに起きる金銭的損失である。

パブリックドメインの楽曲——民謡、わらべうた、雅楽の古典曲、江戸期の三味線曲——を編曲して録音したとき、作曲者フィールドに 伝統 Traditional 日本民謡 作者不詳 と書くのは、事実としては正しい。だが編曲者の権利を放棄している。

パブリックドメイン作品の編曲には著作者がいる。編曲者である。南部牛追唄 の旋律に著作権は残っていないが、その旋律を尺八・箏・太鼓・篠笛の四重奏に再構成した譜面には、あなたの創作がある。作曲者欄に「伝統」とだけ書いたリリースは、そのアレンジに対して支払われるはずだった作品側の収益を、誰にも配分されないまま置いてくる。

正しい構造は、多くのデータモデルで次のようになる。

• 作曲者（Composer）：Traditional（または 伝統。原曲が本当に PD である場合）
• 編曲者（Arranger）：あなたの本名
• 作詞者（Lyricist）：歌詞が PD なら Traditional、あなたが新しい歌詞を書いたならあなたの本名

編曲者ロールを持たない配信画面に当たったら、それは配信経路の制約であって、あなたが「伝統」で妥協してよいという意味ではない。管理事業者側の作品登録は独立して行える。

民謡と邦楽のリリースは、この事故の常連である。演歌や歌謡曲のカバーには明確な原作曲者がいるので誰も間違えない。しかし民謡と雅楽の古典には原作曲者がいないため、フィールドが「空にできない」ことだけを理由に「伝統」で埋められ、そのまま出荷される。三味線と篠笛のアレンジに何ヶ月かけていても、メタデータ上は誰も作っていない曲になる。

原盤側の印税は派手に壊れ、作品側の印税は静かに壊れる。 アーティストページの分裂は一日で目に見えるが、未照合の作品は何年も気づかれない。

9. リジェクトの実際の原因と、出荷前チェックリスト

1. タイトルフィールドの中のアーティスト名 — feat.、ft.、with、リミキサー名をタイトルに書き、ロールを空にしている（第6章）。
2. タイトル中の Explicit / Clean 表記 — (Explicit) (クリーン) (全年齢)。フラグを使う。
3. タイトル中の宣伝文句・仕様表記 — Exclusive、限定盤、Album Version、Original Mix、ハイレゾ、Dolby Atmos、ロスレス。Apple のガイドが名指しで挙げている。
4. 全角英数字・半角カナ・全角スペース（第2章）。
5. アートワークとメタデータの不一致 — ジャケットの曲名・名義・バージョンがフィールドと一致していること。日本語リリースではジャケットが縦組みで、タイトルの区切りが視覚的にしか存在しないことがある。フィールドには横組みの文字列として書く。
6. 言語フィールドの誤り・欠落 — 特にタイトル言語。器楽曲の歌詞言語は zxx。
7. 作曲者・作詞者の欠落 — 拒否する配信先がある。
8. 禁止文字 — 絵文字、装飾記号（★ ♪ ♡）、二重スペース。Apple: "Do not use emoji in titles, artist names, lyrics, or other metadata." 罫線素片 ─ や半角カナもここに含めてよい。
9. 識別子の誤り — 実質的に別の録音への ISRC 再利用、チェックディジットが合わない UPC。
10. 既存カタログと不整合なアーティスト名 — これはしばしばリジェクトされない。だからこの一覧で最も高くつく。

出荷前ルーチン

• 正準アーティスト文字列をペーストする（入力しない）。
• 全タイトルフィールドに曲名以外が入っていないことを確認。
• 全ロールにフィールドがあり、全フィールドにロールがあることを確認。
• コードポイントを検査する：全角英数字、半角カナ、全角スペース、波ダッシュの種類、長音符が ASCII ハイフンに化けていないか、単独濁点。
• NFC に正規化する（濁点の分解を直す）。NFKC は結果を目視してから。
• よみがなフィールドを全て埋める。漢字を入れていないことを確認。
• タイトル言語と歌詞言語の両方を設定。
• Pライン／Cラインを確認。再発なら原初発売日を設定。
• 作曲者・作詞者・編曲者を本名で。PD 曲なら編曲者を必ず立てる。
• ジャケットとフィールドを一文字ずつ照合。

文字レベルの検査については、mazufa.com がブラウザ上だけで動作する無料のメタデータチェッカーを公開しており、全角・半角の混在、半角カナ、全角スペース、波ダッシュの二種類、長音符とハイフンの取り違え、NFC でない文字列といった、目では見つからない事例を検出する。処理は利用者の端末内で完結し、音源はアップロードされない。

受け取ったリジェクトは安い。バリデーションを通り抜けた誤りが高い。

10. まとめ

• メタデータはリリース・レコーディング・作品の三層に書く。高くつく誤りのほとんどは、正しい事実を間違った層に書いた結果である。アーティスト名はラベルではなくキーであり、ロールは同一性、タイトルは表示である。
• 日本語における中心的欠陥は全角と半角である。NFC と NFD はこれを一切直さない。直すのは NFKC / NFKD だけで、その方向は全角英数字（→ASCII）と半角カナ（→全角カタカナ）で逆を向く。全角チルダ U+FF5E は NFKC で ASCII チルダに落ち、波ダッシュ U+301C は落ちない。
• 同一のアーティストは漢字・かな・ローマ字の三つの姿を持つ。主名義を一つ決め、残りは読みフィールドとローカライズフィールドに入れる。
• よみがなを空欄にすると並べ替えができず、漢字を入れると空欄より悪い。
• 作曲者・作詞者・編曲者は出版側の金の入口であり、画面に出ないため無症状で壊れる。民謡アレンジを「伝統」だけで出荷すると、編曲者の取り分を捨てる。

Mazufa の配信は無料で（アップロード料金・月額・リリース単位の課金はなく）、差し引くのは受領したロイヤリティの 5% のみ、そして完成した申請はすべて人が確認する。

出典

• Unicode Standard Annex #15, Unicode Normalization Forms — https://www.unicode.org/reports/tr15/
• Unicode Standard Annex #11, East Asian Width — https://www.unicode.org/reports/tr11/
• Unicode Character Database（コードポイント、互換分解、East_Asian_Width） — https://www.unicode.org/ucd/
• 本稿の正規化の挙動は Python の unicodedata（Unicode Character Database 14.0.0）で NFC / NFD / NFKC / NFKD を実際に適用して検証した（2026-09-08）。正規化写像は Unicode の Normalization Stability Policy の対象であり、バージョン間で変化しない。
• Apple Music Style Guide（1.6 Metadata Language、1.10 Emoji、2.12 / 3.16 Karaoke, Tribute, Japanese Orgel、3.12 Soundtrack Version Information、3.22 Accents and Characters、11.5 Cyrillic Languages、12.4 Phonetics、12.5 Chinese Soundtracks、12.6 Anime Artist Names） — https://help.apple.com/itc/musicstyleguide/en.lproj/static.html
• Spotify for Artists, Music metadata guidelines — https://support.spotify.com/us/artists/article/metadata-formatting-guidelines/
• Spotify Provider Support, Featured artist in a product or track title — https://providersupport.spotify.com/article/featured-artist-in-a-product-or-track-title
• Music Business Association, Music Metadata Style Guide v2.1 — https://www.musicbiz.org/wp-content/uploads/2016/04/MusicMetadataStyleGuide_V2.1.pdf
• IFPI, International Standard Recording Code (ISRC) Handbook（§A.10.1 リマスターと創造的関与） — https://www.ifpi.org/wp-content/uploads/2021/02/ISRC_Handbook.pdf
• DDEX, Standards（ERN を含む） — https://ddex.net/standards/
• 一般社団法人日本音楽著作権協会（JASRAC）「JASRACについて」 — https://www.jasrac.or.jp/aboutus/
• JASRAC 作品データベース検索サービス J-WID — https://www2.jasrac.or.jp/eJwid/
• 株式会社NexTone — https://www.nex-tone.co.jp/
• NexTone 作品検索 — https://search.nex-tone.co.jp/

公開されていないことについて。 本稿でストアの規則として述べたものは、すべてそのストア自身の公開文書からの引用である。日本語圏でしばしば事実として語られるが、どのサービスも公開しておらず、したがって本稿が主張しないものが四つある。(1) アーティストページの統合（マージ）に必要な条件と証跡。(2) 納品が既存アーティストに紐づくか新規アーティストを生成するかを決める内部の照合ロジック。(3) Apple が名指しで禁じている以外の、各社の "Original Mix" の扱い。(4) 日本語の「」『』をタイトルフィールドでどう扱うか——Apple は中国語のサウンドトラックについて《》を明記する一方、日本語の鉤括弧については規則を公開していない。また、日本語メタデータの誤り率に関する公表された測定値は、私たちの知る限り存在しない。