音楽ロイヤリティのトークン化|再生実績と入金が合わないときの分配の決め方

コラム

/約17分で読めます

コラム

/約17分

音楽ロイヤリティのトークン化|再生実績と入金が合わないときの分配の決め方
目次(タップで折りたたみ)

    ある音楽レーベルが、持っている音源の配信収益の一部をトークンにして、ファンや投資家に届けることにしました。トークンを持つ人には、収益の一部が定期的に分配されます。

    最初の分配の締めで、担当者は手を止めます。配信サービスから届いた明細に、同じ曲名のライブ版やリミックスの再生が混ざっている。どの曲にも結び付けられない再生も残っている。先月分の明細の訂正も届いた。そして、明細の合計と、実際に口座へ入ったお金が合わない。

    ここで近い曲名に割り振ったり、先月の確定分を書き換えたりすると、誰にいくら払ったのかを後から説明できなくなります。

    音楽ロイヤリティのトークン化で大事なのは、次の2つです。

    • トークンが、どの収益を受け取る権利なのかを契約で決めておく
    • 権利の情報、再生などの利用実績、実際の入金、差し引く費用、分配額を別々に記録し、訂正や異議が片付いてから払う

    以下では、このレーベルが分配の仕組みを作っていく順に見ていきます。

    この記事でわかること

    • 何をトークンにするかの決め方と、楽曲・録音・権利を分けて持つ理由
    • 再生の実績と入金の突き合わせ、分配額の計算のしかた
    • 訂正と異議の扱い、PoCで試す9つのこと

    この記事で使う言葉

    • ISRC/ISWC:録音(音源)を見分ける番号/楽曲そのものを見分ける番号
    • 著作隣接権:歌手・演奏家やレコード製作者が持つ権利。作詞・作曲者の著作権とは別
    • ウォーターフォール:入ったお金から費用を差し引き、決めた順番で配っていく計算
    • スナップショット:ある時点の状態をそのまま写し取った記録
    • オラクル:チェーンの外の情報を、チェーンの上へ届ける仕組み

    このトークンは、何を受け取る権利なのか

    同じ「音楽のトークン化」でも、トークンが表しうるものはさまざまです。著作権の持分、原盤の収益の分配を求める権利、特定の契約の収益に参加する権利、信託受益権、会員権などです。

    スマートコントラクトを作る前に、少なくとも次のような文を埋められるようにします。

    このトークンは、契約ID C-104の対象音源群について、対象地域JP、対象利用ストリーミング、2026-01-01から2028-12-31までに回収・確定した純収益の2.5%を、分配基準日に受け取る契約上の地位を表す。

    この文には、次の項目が入っています。

    • 対象の資産、権利や受益の種類、地域、利用の形
    • 期間、持分、差し引く費用、分配の基準日
    • 譲渡できるか、正本となる契約・原簿

    ここが空欄のままだと、トークンの残高が増えても減っても、「誰が、何の収益を、いつ受け取れるか」を決められません。

    文化庁の著作権契約マニュアルが示すとおり、音楽には別々の権利が重なっています。歌詞・楽曲という著作物。歌手・演奏家の実演。レコード製作者が録った音源。音源ファイルやNFTを手に入れただけで、これらの権利がまとめて移るわけではありません。

    同じ曲名でも、楽曲と録音は別のもの

    冒頭の明細の混ざり方は、ここから来ています。楽曲(musical work)と、録音された音源(sound recording)は別の資産です。同じ曲にも、原盤違い、再録音、ライブ版、リミックスがあります。実演家とレコード製作者には著作隣接権があり、その中身も作詞・作曲者の権利とは違います(文化庁「著作隣接権」)。

    ですから、表示される名前が同じでも混ぜずに、次の5つを別々に管理します。

    管理する対象主な属性混ぜると起きること
    楽曲(歌詞・旋律など)ISWC、曲名、作家、音楽出版社音源の再生を、正しい作家の持分に結べない
    録音(特定の録音・ミュージックビデオ)ISRC、バージョン、アーティスト、レーベル別の録音やリミックスの実績を、誤って配る
    権利の持分(権利者の権利主張)権利の種類、地域、利用の形、期間、持分地域・期間をまたいで持分が重なる
    トークンの対象(トークンが指す受益の対象)契約、対象のカタログ、ウォーターフォール、分配基準日トークンを持つことと、法的な権利を取り違える
    利用明細(配信サービスなどから届く明細)送り元、期間、地域、数量、金額同じ明細を二重に取り込む、別の作品に誤って結ぶ

    録音を見分けるISRCは、楽曲そのものは見分けません(International ISRC Agency)。楽曲にはISWCがあります。CISACはこれを、権利の管理、利用の特定、ロイヤリティの分配を効率よくするための国際的な番号と説明しています(CISAC International Identifiers)。

    ただ、届くデータにいつも両方の番号がそろうとは限りません。そこで、社内で変わらない独自のIDを主にします。外部の番号、曲名、参加者、再生時間などは、突き合わせの根拠として版を付けて残します。

    権利者が変わっても、過去の記録を消さないためには

    権利者、音楽出版社、管理を任せる先、持分は変わっていきます。譲渡、契約の終了、相続、地域ごとの管理、紛争の解決などがきっかけです。

    JASRACも分配ルールの基本で、段取りを説明しています。利用曲目の報告から作品を特定し、作品届などから関係する権利者と分配率を決める、という流れです。権利者の変更をふまえ、利用の形・分配の期ごとに、権利を確定する基準日も設けています。

    ですから、今の持ち主や持分を上書きしてはいけません。権利の主張は、有効な期間を付けた記録(スナップショット)として足していきます。

    計算の誤差を避けるため、持分は小数ではなく整数で持ちます。同じ資産・権利・地域・期間で、有効な持分の合計が契約の上限を超えないことも確かめます。争いになった権利の主張は消しません。対象の金額を止めておき、記録を残します。データの形は後半にまとめています。

    再生の数と入金の額は、なぜ合わないのか

    再生、放送、演奏などの利用の報告は、「使われた」という証拠です。口座に入ったお金とは別のものです。利用された月と入金の月は、次のような理由でずれます。

    • 報告の遅れ、為替、最低支払額
    • 返金、税、管理手数料
    • 過去の期間の訂正

    JASRACの分配も、利用の報告、作品の特定、権利者の確定、分配額の計算という段階を踏みます。

    DDEXは、世界のデジタル音楽の流通でデータを自動でやり取りするための標準をまとめています(DDEX Standards)。その中には、Musical Work Right Share Notification Standardもあります。権利の持分や、権利の主張どうしの衝突を伝えるための標準です。衝突を伝える仕組みが、標準の中に用意されているわけです。ですから、受け取ったデータを標準の形にそろえても、権利が正しいとまでは言えません。衝突そのものを、業務の中のひとつの状態として扱う必要があります。

    明細が届いてから分配に回すまでは、次の6段階で進めます。

    1. 取り込み:元のファイル、送り元、形式の版、受け取った時刻、SHA-256(ファイルの指紋のような値)を保存する。
    2. 形をそろえる:通貨、期間、地域、利用の形、数量の単位を社内の形式に直す。元の値も残す。
    3. 重複を除く:送り元の明細IDがあれば使う。なければ、送り元・期間・音源・地域・金額などから、いつも同じになる値を作る。
    4. 突き合わせ:音源を楽曲へ、楽曲を権利の持分へ結ぶ。確からしさの数字だけで自動で決めず、根拠と突き合わせのルールの版を残す。
    5. 入金との突き合わせ:明細書の総額、銀行などの入金の記録、通貨、手数料を突き合わせる。
    6. 締め:対象の期間と権利の記録を固め、承認されてから分配の計算に渡す。

    冒頭の「どの曲にも結べない再生」は、実際の運用でも残ります。The MLCのMatching Toolがその例です。自動処理の後にも、音源と楽曲を結べない利用実績が残ります。そこで権利者が候補を提案し、The MLCが確かめてから確定します。

    結べない行を、近い曲名へ無理に配ってはいけません。「未照合」の保留にしておきます。後で解決したら、元の期間を参照する調整として処理します。

    分配額を、後から同じ数字で出し直すには

    分配額には、トークンの発行量のほかに、次のものがかかわります。

    • 契約で認められた、差し引く費用の種類と順番
    • 回収済みのアドバンス(前払金)、準備金、税・送金の費用、通貨の換算
    • 権利の持分と、トークンを持つ人の記録

    これらを固めておかないと、分配額は決まりません。基本の関係は次のとおりです。

    • 配れる額=受け取ったお金-認められた手数料-源泉徴収した税-アドバンスの回収-準備金の積み増し+準備金の取り崩し
    • 1人への支払額=配れる額×権利の持分×トークンの持分(通貨ごとのルールで端数を丸める)

    「受け取ったお金」には、見込みの額ではなく、突き合わせの済んだ入金の記録を使います。差し引く費用には契約上の根拠を付け、マイナスや上限を超えるものは受け付けません。

    計算では、誤差の出る小数(浮動小数点)を使いません。通貨の最小単位か、桁数を自由に扱える10進数で計算します。最後に残る端数を担当者がそのつど調整すると、後から同じ数字を出し直せなくなります。ですから端数は、「いちばん大きい持分に付ける」「次回に繰り越す」など、決めた規則で扱います。

    計算式と、残しておく記録の一覧は後半にまとめています。

    月の途中でトークンが売られたら、誰が受け取るのか

    トークンが月の途中で別の人へ移ったとします。そのとき、次のお金を誰が受け取るかを決めておきます。

    • 移るまでに生じたが、まだ報告されていない利用分
    • 報告は済んだが、まだ入金されていない収益
    • 入金は済んだが、まだ分配していない金額

    「支払いの時点の持ち主にすべて渡す」のか、「利用された時点の持ち主に渡す」のか。どちらにするかで、必要な記録が変わります。

    作り方の一例は、分配の回ごとに基準の時点を決めることです。その時点で持つ資格のある人の残高を、ブロックの番号か原簿の版で固めます。ただし、そのやり方が、契約での受益者の決め方と同じでなければなりません。二次流通の注文の途中、決済が済んでいない、凍結、相続、秘密鍵の紛失、裁判・当局への対応があるときの扱いも決めます。

    トークンが金融商品に当たるか。どの登録・開示・勧誘・分別管理・譲渡制限が要るか。これはトークンの名前では決まりません。金融庁の金融商品取引業者等向けの総合的な監督指針 IV-3-7も、電子記録移転有価証券表示権利等の取引・管理の体制を求めています。具体的な権利の組み立てと、売り方・移し方は、公開の時点の法令にもとづく判断を正本にします。システムは、その結論を形にします。

    訂正や異議が届いたら、どう進めるか

    ここまで見てきたとおり、権利者は譲渡や相続で変わり、明細には過去の期間の訂正も届きます。つまり、権利の主張や利用実績の訂正は、例外ではありません。管理画面で過去の確定した行を直接書き換えると、前回の支払いと計算し直した結果の差を説明できなくなります。

    そこで、1回の分配を次の段階で追います。

    1. 受け取り:利用明細を受け取る。受け取っただけでは払わない。
    2. 突き合わせ:音源・楽曲・権利の主張を特定する。確からしさが低いものを黙って確定しない。結べないものや争いのあるものは保留にし、近い権利者へ仮に送金しない。
    3. 入金の確認:明細書と実際の入金を突き合わせる。見込みの収益を現金として扱わない。
    4. 計算:ウォーターフォールで計算する。入力の版なしに計算し直さない。
    5. 承認:作った人とは別の人が、複数で承認する。作った人が1人で承認しない。
    6. 支払:支払いを確定する。応答が途切れても、別のIDで送り直さない。
    7. 突き合わせの完了:支払いの結果と台帳が一致する。失敗した分を成功扱いしない。

    異議の申し立てがあったら、争いの対象だけを止めます。契約の上で分けられる、争いのない金額まで全部止める必要はありません。解決した後も、元の分配の記録は消しません。差額を調整として、次回か個別の支払いに反映します。

    チェーンに載せるのは、誰がどの版を承認したかの記録

    音楽ロイヤリティのオラクルは、市場価格を届ける仕組みのように、1つの数字を送るものではありません。送るのは、次のものを誰がどの版で承認したか、という記録です。

    • 配信サービスなどの利用明細、権利の主張、契約
    • 銀行などの入金の記録、為替レート
    • 差し引く費用の証拠

    確定した値に版・期限・署名を付けて届ける一般的な設計は、RWA・金融システムのオラクル設計で扱っています。

    チェーンの外とチェーンの上では、持つものを分けます。

    • チェーンの外:個人情報、契約の全文、明細、異議の資料、突き合わせの根拠。アクセスを制限して持つ。
    • チェーンの上:分配の回、対象の期間、入力一覧のハッシュ、支払額をまとめた値、総額、ルールの版、承認の署名。必要な分だけ記録する。
    • 支払いを実行する側:同じ分配の回を送り直しても二重に払わない。支払い後の差し替えはせず、調整にする。
    • 管理のしかた:オラクルの鍵、ウォーターフォールのルール、一時停止、受け取る人の資格、アップグレードを別々の役割にする。複数人の承認と緊急停止を用意する。

    ハッシュは、「後で同じ文書かどうかを確かめる」ための材料です。チェーンにハッシュを置いても、入力の中身が本当だという証明にはなりません。入力の権限、取得元、承認、異議の処理までそろって、はじめて監査できる形になります。

    1回の分配には、多くの記録がかかわります。契約・権利の原簿、利用実績、明細書、入金、差し引いた費用、トークンの発行量、支払手段、会計の仕訳です。ですから突き合わせも、「チェーン上の残高が合う」だけでは足りません。これらすべてに同じ分配の回の番号を付け、番号でたどって突き合わせます。秘密鍵とウォレットの基礎はブロックチェーンウォレットの解説で確かめられます。会社で運用するなら、署名する人、承認する人、突き合わせる人を分けます。

    PoCで試す9つのこと

    このレーベルがPoCで確かめるのは、ふつうの分配が動くかではありません。訂正・停止・送り直しが起きても、正しく片付くかです。

    試験入力・障害合格の証拠
    権利期間の境目月の途中で音楽出版社・持分を変える有効日と権利確定日に従い、新旧の記録へ正しく分ける
    音源と楽曲の突き合わせ同名の曲、別の録音、ISWCの欠け誤って自動で結ばず「未照合(UNMATCHED)」に取り置き、根拠付きで解決する
    重複した取り込み同じ報告を10回送る利用実績・分配・支払が1件だけできる
    入金の差明細書と着金額・通貨が合わない「入金確認済み(CASH_RECONCILED)」へ進まず、差の対応記録を起票する
    ウォーターフォールの再現同じ入力一覧を別の環境で計算し直す受け取る人ごとに、通貨の最小単位まで同じ結果
    紛争1曲の持分の合計が上限を超える対象の額だけ止め、争いのない分配と記録はそのまま
    二次流通権利確定日の前後でトークンを移す契約のルールどおりに、持ち主の記録を再現できる
    支払の応答切れ送った後に応答が消える同じIDで照会し、別の支払を作らず最終の状態に落ち着く
    訂正支払済み(PAID)の後に、過去の利用実績を直す履歴を上書きせず、調整で差額を追える

    性能は、1秒あたりの件数だけでは測りません。次のものも測ります。

    • 大量の報告の締めにかかる時間、未照合の割合、手作業の対応件数
    • 分配が確定するまでの遅れ、計算し直しにかかる時間、支払いが戻ってきた割合

    よくある質問

    トークンを発行すれば、音楽著作権も自動的に移転しますか?

    いいえ。トークンを発行しただけで、著作権、著作隣接権、収益の分配を求める権利が自動で移るとは限りません。何が移るか、何が与えられるかは、契約、原簿、対象の権利、地域、期間、法令上の要件で決まります。システムは、その法的・契約上の結論を、トークンの対象の定義と移転のルールへ正確に組み込みます。

    ストリーミングの再生ごとに即時分配できますか?

    再生をすぐ記録できても、最終的なロイヤリティを同時に確定できるとは限りません。音源と楽曲の突き合わせ、権利の持分、地域、料率、返金、税、差し引く費用、実際の入金は、後から確定したり訂正されたりするからです。速報の残高と、払ってよい残高を分け、確定した回だけを送金します。

    音楽ロイヤリティ分配にブロックチェーンは必須ですか?

    ブロックチェーンは必須ではありません。複数の組織が同じ分配結果を確かめ、トークンの移転と支払いを連動させる必要があるなら役に立ちます。一方、1社の中の台帳で足りる場合もあります。使うかどうかは、次の点で判断します。参加者どうしをどこまで信頼できるか、改ざんを見つける必要、秘密の守り方、処理量、訂正のしやすさ、運用の費用です。

    実装する人向けの詳細

    ここからは、このレーベルで分配の仕組みを作る開発チームの話です。

    管理する対象の記録名

    前半の5つの対象は、次の記録として持ちます。楽曲はmusical_work、録音はrecording、権利の持分はright_share、トークンの対象はroyalty_asset、利用明細はusage_lineです。

    権利主張のスナップショット

    owner_idやshareを今の値で上書きせず、権利主張を次のような記録として追加します。

    {
      "claim_id": "CLM-9021-v3",
      "asset_id": "WORK-4481",
      "party_id": "PARTY-71",
      "right_type": "interactive_streaming",
      "territory": "JP",
      "share_bps": 2500,
      "effective_from": "2026-04-01",
      "effective_to": null,
      "status": "ACTIVE",
      "contract_hash": "sha256:...",
      "supersedes": "CLM-9021-v2"
    }

    share_bpsは、百分率の小数ではなく、ベーシスポイントなどの整数で持ちます。持分の合計が上限を超えないことは、データベースの制約か承認の処理で確かめます。DISPUTEDになった権利主張は消さず、対象の額を保留して記録を残します。

    ウォーターフォールの式と、残す記録

    allocatable = cash_received
                - authorized_fees
                - taxes_withheld
                - recoupment
                - reserve_increase
                + reserve_release
    
    recipient_payout = round(allocatable × right_share × token_share, currency_rule)

    cash_receivedには、突き合わせの済んだ入金記録を使います。分配ごとに、少なくとも次の記録を持ちます。

    記録最低限保持する値検証
    receipt送信元、通貨、総額、入金日、明細書ID銀行等の着金と明細書の総額が一致
    deduction種類、金額、契約条項、請求書・証憑許可された種類・上限・順序
    distribution_run期間、ルールの版、権利スナップショット、保有者スナップショット同じ入力で同じ結果を再計算できる
    payout受取人、金額、通貨、支払手段、状態同じ冪等キーで二重に支払わない
    adjustment元の明細、理由、承認済みの証拠、差額過去の行を消さず反対仕訳で追跡できる

    冪等キーは、同じ依頼を何度送っても1回しか実行しないための番号です。反対仕訳は、元の記録を消さずに、逆の向きの記録を足して打ち消すやり方です。

    二次流通の基準時点

    分配の回ごとの基準時点はrecord_atとして持ち、その時点の適格な保有者残高を、ブロック番号か原簿の版で固定します。

    分配の状態遷移

    状態意味次へ進む証拠禁止する動作
    REPORTED利用明細を受信原本のハッシュ、送信元、スキーマ検証受信だけで支払う
    MATCHED音源・楽曲・権利主張を特定採用したID、照合ルール、確信度低い確信度を黙って確定する
    UNMATCHED / DISPUTED対象または持分が未確定対応記録、関係者、争点、保留額近い権利者へ暫定送金する
    CASH_RECONCILED明細書と実入金を照合入金記録、通貨、差異ゼロまたは承認済みの差異見込収益を現金扱いする
    CALCULATEDウォーターフォール計算済みルール・権利・保有者のスナップショット入力の版なしで再計算する
    APPROVED職務分離された承認済み複数承認、合計、例外一覧作成者が単独で承認する
    PAID支払手段へ確定支払ID、トランザクションID、銀行の照会番号タイムアウト時に別IDで再送する
    RECONCILED支払結果と台帳が一致成功・返却・残高・総勘定の照合失敗分を成功扱いにする

    異議の申し立てには、case_id、対象の資産・期間・地域、申立人、今の根拠、反証、保留額、期限、決める人を持たせます。解決後の差額はADJUSTMENTとして反映します。

    チェーンの上に記録する項目

    チェーンの上には、distribution_run_id、対象期間、入力一覧のハッシュ、支払額のMerkleルート(多数の支払額を1つの値にまとめ、後で個別に確かめられるようにしたもの)、総額、ルールの版、承認の署名を記録します。ルートの差し替えは、古い処理を取り消せる時点だけ許し、PAIDの後は調整にします。

    分配のたびに確かめる6つの不変条件

    1. 同じ資産・権利・地域・期間で、有効な権利の持分が契約上の上限を超えていない。
    2. 各利用明細は0件または1件の確定対象へ結び、未照合・紛争中は支払対象に入っていない。
    3. receipt = deductions + reserve change + payouts + undistributed balanceが通貨ごとに成立する。
    4. 分配処理の保有者スナップショットの総量が、その時点の適格なトークン供給量と一致する。
    5. 同じpayout_idまたは冪等キーから、成功した支払は1件しか生成されていない。
    6. 訂正は元の記録への参照を持つ反対仕訳・差額仕訳であり、確定済みの履歴が消えていない。

    関連記事

    XTELAができること

    私たちは、音楽ロイヤリティのトークン化で、権利スナップショットの台帳、利用明細の取込と照合、入金照合、ウォーターフォール計算、支払と調整の状態遷移を設計し、開発します。本記事のPoC試験9項目を実データに近い明細で回し、訂正や再送が起きても分配が1円単位で再現できることを貴社と確かめます。権利構成の法的な判断は弁護士と連携して進めます。設計の相談はお問い合わせからどうぞ。

    参考資料

    資料の確認日と注意

    法令・標準仕様・分配ルールの一次情報は2026年8月13日に確認しました。JASRACの分配ルールとThe MLCのMatching Toolの記述は、2026年9月24日に確認し直しています。内容は公開資料にもとづく技術・業務設計の解説です。個別のスキームの法務・金融規制・税務・会計・投資の判断は、資格を持つ専門家と確定してください。

    お問い合わせ

    どんなフェーズからでも、お持ちのアイデアや企画をもとにご提案可能です。
    まずはお気軽にご相談下さい!