『ユニバーサル ミュージック ジャパン』――アーティスト・音楽市場・経営・テクノロジーから読み解く世界最大級の音楽企業（第8回）（第7章　コミュニティからプラットフォームへ）

第7章　コミュニティからプラットフォームへ

第1節　ファンクラブの進化

ファンクラブは新しい仕組みではない。

会報。

会員証。

先行予約。

限定商品。

イベント。

アーティストからのメッセージ。

長い音楽産業の歴史の中で、ファンクラブはアーティストとファンを継続的につなぐ重要な基盤であり続けてきた。

しかし2026年のファンクラブを、かつての会員制度の延長だけで理解することは難しい。

Web。

スマートフォン。

ストリーミング。

動画。

ライブ配信。

チケット。

EC。

SNS。

デジタル会員証。

多言語。

そして生成AI。

これらが接続されることで、ファンクラブは、

会員を管理する仕組み

から、

アーティストとファンの長期的な関係を支えるデジタル基盤

へ変化し始めている。

ここに、第6章で見てきたCommunityがPlatformへ進む最初の接点がある。

かつてのファンクラブは情報の希少性を扱っていた

インターネット以前、アーティストについて知ることのできる情報には限界があった。

テレビ。

ラジオ。

雑誌。

新聞。

レコード店。

ライブ。

その中でファンクラブへ入ることには大きな意味があった。

会報が届く。

本人からのメッセージが読める。

公演予定を早く知る。

チケットの先行受付へ参加できる。

つまり、

Scarce Information → Membership Value

という構造があった。

一般には手に入りにくい情報へアクセスできること自体が、会員価値になっていた。

SNSによって情報の希少性は低下した

現在は状況が違う。

公式SNSを見れば新曲情報を知ることができる。

YouTubeでMVを見る。

ストリーミングで作品を聴く。

本人がSNSで直接発信することもある。

すると、

Information Access

だけをファンクラブの価値にすることは難しくなる。

無料で得られる情報が圧倒的に増えたからである。

ここでファンクラブには、次の役割が必要になった。

情報から体験へ

現代のファンクラブでは、

情報を早く知る

だけでなく、

限定映像を見る。

ライブチケットへアクセスする。

アーカイブを見る。

会員限定コンテンツを楽しむ。

イベントへ参加する。

商品を購入する。

場合によってはアーティストの活動履歴を長期間たどる。

つまり、

Information Service

から、

Experience Service

へ広がっている。

ファンクラブはニュースレターではなく、一つの継続的な体験環境へ近づく。

ExperienceからRelationshipへ

しかし「限定コンテンツが多いサービス」とだけ考えても不十分である。

最も重要なのは時間である。

一か月利用する。

一年利用する。

五年利用する。

その間に、

新曲が出る。

アルバムが出る。

ツアーがある。

活動が変わる。

会員本人の生活も変わる。

つまりファンクラブは、

Continuous Relationship Infrastructure

として機能する。

ここに通常のECサイトとの違いがある。

会員番号は時間の記録でもあった

伝統的なファンクラブでは、会員番号や入会年が長期関係を象徴することがある。

何年前から応援しているか。

どの時期から参加しているか。

これは単なる顧客IDではない。

一つのRelationship Historyである。

しかし、ここには慎重さも必要になる。

古くからいることを人間的な序列へ変えてはいけない。

したがって、

Membership History = Personal History

であって、

Membership History ≠ Fan Rank

である。

古参の記憶を残し、新規を排除しない

長期ファンクラブにとって難しいのは、この二つの両立である。

長年支えてきたファンの時間を尊重する。

一方で、新しく作品を知った人が入りやすくする。

過去を重視しすぎれば閉鎖的になる。

新規だけを重視すれば長期ファンの蓄積が消える。

必要なのは、

Legacy Memory + Open Entry

である。

長い時間と開かれた入口を同時に持つ。

ファンクラブからCommunityが生まれる

ファンクラブ自体は企業が運営できる。

しかし、そこへ参加した人同士に関係が生まれるとCommunityが形成される。

ライブで会う。

同じ企画について話す。

情報を交換する。

SNSでつながる。

したがって、

Fan Club ≠ Community

である。

ファンクラブは制度。

Communityは人間関係。

しかしファンクラブは、Communityが形成されるための重要な接点になり得る。

Community機能を入れればよいわけではない

ここで企業は、

掲示板を追加する。

チャットを追加する。

ファン同士を交流させる。

という機能開発へ進みやすい。

しかし、Communityは機能数では生まれない。

交流したくない人もいる。

一人でコンテンツだけ楽しみたい人もいる。

だから、

Membership ≠ Mandatory Social Participation

である。

ファンクラブには、

一人で楽しむモード。

Communityへ参加するモード。

両方があってよい。

Self ↔ Platform

この意味で、ファンクラブの最小構造は、

Self ↔ Platform

である。

一人のファンが、

作品。

情報。

チケット。

アーカイブ。

へアクセスする。

他者との交流がなくても成立する。

そして希望すれば、

Self ↔ Community

へ進める。

この二つを分離することが重要になる。

PlatformがCommunityを強制しない

SNS型サービスでは、投稿、反応、フォロワーが中心になる。

しかし公式ファンクラブがすべてSNS化する必要はない。

作品を静かに見たい人。

過去映像だけ見たい人。

ライブ情報だけ必要な人。

それぞれの利用形態を認める。

つまり、

Different Relationship Modes

を持つPlatformにする。

これは長期関係を支えるうえで重要である。

Mrs. GREEN APPLEのRingo Jam

Mrs. GREEN APPLEでは、公式ファンクラブ「Ringo Jam」がデジタル基盤の重要な一部になっている。

公式サイトのリニューアルやMGA Appとの接続によって、動画、ギャラリー、レポート、アーカイブ、ライブ情報など複数の接点が統合されている。

ここで重要なのは、

Fan Club Website

だけではなく、

Artist-specific Digital Environment

へ近づいていることである。

前章で見た、

One Artist, One Architecture

がファン側にも現れている。

Adoの秘密基地

Adoの公式ファン基盤では、本人のPrivate Visibilityを限定しながら、動画、配信、情報、記録などを通じて継続的な接点をつくる。

これは別のCommunity Architectureである。

Mrs. GREEN APPLE型の開かれた巨大エンタテインメント生態系と同じ設計である必要はない。

つまり、

One Artist, One Fan Club Architecture

である。

ファンクラブ自体もArtist Identityに合わせて変える必要がある。

Vaundy ART Work Studio Members

Vaundyでは、会員基盤の名称自体が「ART Work Studio Members」となっている。

これはFan Clubというより、創作活動の周囲へ人が集まるStudio的なRepresentationを持つ。

名称は単なるブランド表現ではない。

Platformの役割認識にも影響する。

ファンを「顧客」と呼ぶ。

「会員」と呼ぶ。

「メンバー」と呼ぶ。

それぞれ関係の設計が異なる。

名前はArchitectureを映す

ファンクラブ。

秘密基地。

Studio Members。

名称には、Artist-Fan Relationの違いが現れる。

したがって次世代ファンクラブを共通UIへ完全統一してしまえば、この差異を失う可能性がある。

企業側では共通技術基盤を使いながら、

表面の体験。

機能。

言語。

関係距離。

を変える。

つまり、

Shared Backend + Artist-specific Experience

というArchitectureが合理的になる。

共通基盤と固有体験

UMJのように多数のアーティストを持つ企業が、全てのファンクラブを完全に別システムで構築すると、コストもセキュリティ管理も複雑になる。

一方、全員を同じテンプレートへ入れればArtist Identityが薄くなる。

そこで、

Identity

Payment

Membership

Ticket Integration

Rights

Security

Analytics

といった共通機能を共有する。

その上で、

Visual。

Content Structure。

Community Function。

Artist Distance。

を個別化する。

これが次世代ファンクラブの企業Architectureになる。

ファンクラブはSuper Appになるのか

機能が増えると、

音楽。

動画。

EC。

チケット。

Community。

ライブ配信。

すべてを一つのアプリへ統合したくなる。

しかし、Super App化が常に最適とは限らない。

機能が多すぎれば複雑になる。

ファンが欲しいのはアプリそのものではなく、Artistとの適切な接点である。

したがって、

More Features ≠ Better Fan Club

である。

必要な機能だけを持つ。

ここでもMinimum Necessary Architectureという考え方が重要になる。

チケットがファンクラブを変えた

ファンクラブ価値の中で、ライブチケット先行は長く大きな位置を占めてきた。

人気が高まるほど、チケットへのアクセス自体がMembership Valueになる。

しかし、この構造には問題もある。

「ライブへ行くためには会員でなければならない」

という圧力が強くなる場合がある。

すると、

Relationship Membership

が、

Ticket Access Fee

へ縮小する。

ファンクラブ全体の価値設計をチケットだけに依存しないことが重要になる。

TicketingはRights Infrastructureでもある

一方、デジタルチケットには大きな可能性がある。

本人確認。

不正転売防止。

入場。

リセール。

会員権限。

これらを接続できる。

ただし、本人確認を強化すればPrivacyとのバランスが必要になる。

つまり、

Access Control + Privacy

を同時に設計する。

ファンクラブはIdentity Infrastructureへ一部近づく。

デジタル会員証

スマートフォン上のデジタル会員証も、単なるカードの電子化ではない。

チケット。

イベント。

会員資格。

購入権限。

限定コンテンツ。

と接続できる。

さらに真正性証明まで組み込める。

すると、

Membership ID

が複数サービスの認証基盤になる。

しかし一つのIDへ全データを過剰集中させる必要はない。

IdentityとPrivacy

次世代ファンクラブではIdentity Managementが重要になる。

一人の会員であることは確認する。

しかし、

実名をCommunity全体へ見せる必要はない。

購入履歴を他者へ公開する必要もない。

つまり、

Verified Identity ≠ Public Identity

である。

バックエンドでは必要な確認をする。

表面上は本人が表示範囲を選べる。

AdoのSelective Disclosureと同じ原則がファン側にも適用できる。

年齢も重要になる

音楽には未成年ファンもいる。

決済。

Community。

ライブ。

データ利用。

年齢に応じた適切な保護が必要になる。

すべての会員を同じ設計へ入れない。

特に高額商品や継続課金、公開Communityでは慎重さが必要になる。

つまり、

Age-aware Experience Design

も次世代ファンクラブの重要な要件になる。

会員データは誰のものか

企業には、

入会日。

購入履歴。

ライブ参加。

コンテンツ視聴。

などのデータが蓄積される。

これを使えば、個別化は高度になる。

しかし、

持っているデータだから何にでも使える

わけではない。

目的を明確にする。

必要な範囲だけ使う。

保存期間を決める。

本人が確認・削除できる。

つまり、

Purpose-limited Data Use

が必要になる。

Membership DataからRelationship Intelligenceへ

企業側では、ファンクラブデータを単なる会員管理から一段進められる。

どのコンテンツが長期的に利用されるか。

新規会員はどこから入るか。

海外会員がどこで困っているか。

どの過去作品が再発見されているか。

これを集計して理解する。

つまり、

Membership Database

から、

Relationship Intelligence

へ進む。

個人を心理的に監視するのではなく、Platform改善に必要な構造を学ぶ。

「解約」をどう見るか

サブスクリプション型ファンクラブでは、退会はChurnになる。

企業として重要な指標である。

しかし長期Artist Relationshipでは、

退会 = 関係終了

とは限らない。

生活状況が変わった。

一時的に利用しない。

後で戻る。

さまざまな理由がある。

したがって、

Membership Churn ≠ Fan Churn

である。

この二つを分ける必要がある。

退会を難しくしない

解約率を下げるため、退会手続きを複雑にすることは短期的には効果があるかもしれない。

しかし長期Trustを損なう。

次世代ファンクラブでは、

入るのが簡単。

離れるのも簡単。

戻るのも簡単。

という、

Easy Entry / Easy Exit / Easy Return

が望ましい。

これは第6章で示したReturnabilityをPlatformへ実装することでもある。

会員履歴を戻したい人、戻したくない人

再入会時には、

以前の履歴を引き継ぎたい。

過去の履歴を新しいAccountへ持ち込みたくない。

両方があり得る。

したがって、

Relationship Memory Control

を本人へ与える。

企業都合で永久に一つのFan Profileへ固定しない。

ファンクラブからアーカイブへ

長期活動するアーティストでは、ファンクラブ内部に巨大なコンテンツが蓄積する。

過去の会報。

写真。

ライブレポート。

動画。

インタビュー。

これらは時間とともに、

Fan Content

から、

Artist Archive

へ変化する。

新規ファンが過去を知る入口にもなる。

つまりファンクラブがArtist Memory Infrastructureの一部になる。

アーカイブを新規ファンへどう開くか

長期会員だけが全て見られる。

新規入会者も過去アーカイブへアクセスできる。

どちらが正しいかはアーティストごとに異なる。

重要なのは、権利、限定性、長期会員価値、新規アクセスをバランスさせることである。

ここにも、

Legacy vs Accessibility

という設計問題がある。

AIがアーカイブを変える

何十年分ものファンクラブコンテンツが蓄積すると、人間が全てを探索するのは難しい。

生成AIなら、

「このツアー当時のインタビューを探す」

「この曲が初めて語られた資料を探す」

「2015年と2025年の発言を比較する」

といった検索が可能になる。

つまり、

Archive → Conversational Knowledge Access

へ変化する。

長期ファンクラブほどAIとの相性が高くなる。

ただしAIがアーティストになり代わらない

ファンクラブにAIチャットを入れ、

本人のように24時間話す。

技術的には可能になる。

しかしこれは慎重であるべきだ。

公式AIと本人を混同させない。

本人の発言を生成しない。

人格を模倣しすぎない。

むしろ、

Archive Guide

Support Assistant

Translation Assistant

のような役割が適切である。

AIはRelationshipの代替ではなく、Relationship Infrastructureを支える。

多言語化

世界展開するアーティストでは、ファンクラブの国際化が重要になる。

日本語情報が遅れて英訳されるだけでは、海外ファンは常に二次的な位置に置かれる。

生成AIを使えば、

ニュース。

FAQ。

ライブ情報。

一定のアーカイブ。

を迅速に多言語化できる。

しかし歌詞や本人発言などは、機械翻訳だけで意味を確定しない。

文化的ニュアンスを確認する。

Speed + Cultural Accuracy

を両立する。

Global Membershipを一つにするか

国別ファンクラブ。

世界共通Membership。

どちらにも利点がある。

世界共通ならIdentityが一つになる。

国別なら現地サービスへ適応しやすい。

将来的には、

One Fan Identity + Localized Services

というハイブリッドが有力になる。

本人は一つのAccountを持つ。

地域に応じてチケット、決済、言語、法制度を切り替える。

One Fan Identity

複数の国。

複数のイベント。

Web。

Mobile。

その都度別アカウントをつくるのは不便である。

そこで、

One Fan Identity

が価値を持つ。

ただし企業グループ全体へ勝手に情報を共有するのではない。

ConsentとPermissionを持たせる。

Identityは接続のための基盤であり、追跡のための基盤ではない。

UMGレベルまで接続したら何が起こるか

UMJのファンクラブ基盤がUMGの世界ネットワークと安全に接続できれば、

日本のファンが海外公演へ参加する。

海外ファンが日本公演へ来る。

世界各地域の公式商品へアクセスする。

などの可能性が広がる。

つまり、

Artist-specific Fan Platform
↔ Global Music Infrastructure

が成立する。

ここにUMJが単独の日本企業ではなく、世界規模のグループへ属する強みが出る。

しかしグローバルIDは監視基盤にもなり得る

一つのIdentityで世界中の行動を追跡できれば、企業側には非常に強いデータが集まる。

だからこそ、

地域をまたいだ追跡をどこまで許すか。

目的ごとに同意を取る。

匿名化する。

本人が設定を変更できる。

必要がある。

Global Convenience ≠ Global Surveillance

という境界を明確にする。

ファンクラブとEC

現代のファンクラブでは商品購入も近接する。

会員限定商品。

先行販売。

記念商品。

ここでPlatformがCommerceへ接続する。

しかし、第6章で見たように、

Membership → Maximum Purchase

という設計にはしない。

ファンクラブの主目的を商業化しすぎると、Relationship Infrastructureが販売チャネルへ縮小する。

ファンクラブと推し活

一方で、商品を買いたいファンにとっては公式Platformが便利である。

真正性。

配送。

在庫。

会員限定性。

企業側は安全な購買環境を提供できる。

したがってCommerceを排除するのではなく、

Relationship-first Commerce

として配置する。

この順序が重要になる。

ファンクラブの経済モデルも多様化できる

月額。

年額。

無料会員。

有料会員。

イベント単位。

複数Tier。

さまざまなモデルがある。

しかし高額Tierほど「上位ファン」という社会的序列をつくる必要はない。

価格差は、

提供コスト。

コンテンツ。

体験。

によって説明する。

Price Tier ≠ Human Tier

である。

Community Tokenは必要か

将来的にMembership証明をトークン化することも技術的には可能である。

しかし目的を明確にする。

譲渡可能にするのか。

本人だけに紐づけるのか。

権利証明なのか。

投機可能なのか。

ファンクラブでは、価格上昇を狙う資産より、

Non-speculative Membership Credential

の方が適合する場合が多い。

技術を導入すること自体を目的にしない。

ファンクラブからPlatformへ

ここまで来ると、従来の「ファンクラブ」という言葉では機能の全体を表しにくくなる。

Membership。

Identity。

Content。

Archive。

Ticketing。

Commerce。

Community。

Translation。

Rights。

Support。

それらが一つの基盤へ接続される。

つまり、

Fan Club
→ Digital Membership Platform

へ進む。

しかし、その名称が必ず「Platform」へ変わる必要はない。

重要なのは内部構造である。

PlatformからEcosystemへ

さらにファンクラブが、

ライブ。

都市企画。

他アーティスト。

ブランド。

世界市場。

と接続すれば、

Artist-specific Platformの外側にEcosystemが形成される。

Mrs. GREEN APPLEで見た方向である。

したがって、

Fan Club
→ Membership Platform
→ Artist Ecosystem

という発展可能性を考えられる。

ただし、すべてのアーティストがEcosystem化する必要はない。

小さなファンクラブも正しい

数千人。

限定的なコンテンツ。

年数回の会報。

それで十分なアーティストもいる。

Technologyが使えるから巨大化する必要はない。

次世代化とは、機能数や規模を増やすことではない。

Artist-Fan Relationshipに適したArchitectureを選ぶこと

である。

成功指標も変わる

会員数。

継続率。

売上。

これらは重要である。

しかし、それだけで次世代ファンクラブを評価しない。

新規参加しやすいか。

退会しやすいか。

戻りやすいか。

Privacyが守られているか。

アーカイブが利用されているか。

サポート品質。

Community Safety。

Artist Workload。

複数の指標を見る。

つまり、

Membership Growth

だけではなく、

Relationship Quality + Platform Quality

を評価する。

AIが最適化すべきもの

AIを導入するなら、

最大継続率。

最大購入額。

だけを目的関数にしない。

FAQを解決する。

過去コンテンツを見つける。

海外ファンを支援する。

チケット不正を検出する。

権利を確認する。

通知を個人設定に合わせる。

こうした、

Friction Reduction

に大きな価値がある。

関係を操作するAIより、関係を邪魔する摩擦を減らすAIの方が自然である。

次世代ファンクラブの最小原則

ここまでを圧縮すると、次世代ファンクラブには五つの条件がある。

Access

作品、情報、体験へアクセスできる。

Memory

過去の活動へ戻れる。

Identity

安全に会員資格を保持できる。

Choice

参加、公開、購入、退会を自分で選べる。

Connection

希望すればCommunityやライブへ接続できる。

この五つがあれば、ファンクラブは単なる「特典会員制度」を越える。

会員制度からRelationship Infrastructureへ

したがって、ファンクラブの進化を最小構造で表せば、

Newsletter Club
→ Membership Service
→ Digital Experience
→ Relationship Infrastructure

となる。

そして必要な場合には、

Relationship Infrastructure
→ Artist Platform

へ進む。

重要なのは、最後まで中心に一人のファンが残ることである。

Platformはファンを閉じ込めるものではない

優れた次世代Platformは、

毎日使わなくてもよい。

Communityへ参加しなくてもよい。

商品を買わなくてもよい。

一度退会してもよい。

それでも必要なときに作品へ戻れる。

つまり、

Platform Value = Persistent Possibility of Connection

である。

この状態なら、ファンクラブは囲い込み装置ではなくなる。

アーティストとファンの長い時間を支える基盤になる。

第7章の出発点

第6章では、SelfからCommunityまでを見た。

第7章では、そのCommunityを現実に支えるInfrastructureを見る。

最初の形がファンクラブである。

しかし関係が拡張すると、ファンクラブだけでは足りなくなる。

ライブ。

商品。

映像配信。

チケット。

物理空間。

これらが接続し始める。

すると音楽企業は、作品を販売するだけではなく、複数の体験を一つのArtist Architectureとして設計する企業へ変わっていく。

次節では、ライブ・物販・配信を扱う。

Physical ExperienceとDigital Experienceは競合するのか。

ライブの一回性と配信の拡張性をどう両立するのか。

商品はどこまでRelationship Objectになり得るのか。

そして三つを別々の事業としてではなく、一つの長期的なファン体験として接続すると何が起こるのか。

ファンクラブというMembership Infrastructureから、音楽企業のExperience Infrastructureへ観測点を広げていく。
第2節　ライブ・物販・配信

音楽企業の事業を分類すれば、ライブ、物販、配信は別々の事業に見える。

ライブは会場で行われる。

物販は商品を販売する。

配信はデジタルネットワークを通じて映像や音声を届ける。

担当部署も、契約も、収益構造も異なることがある。

しかしファンの側から見れば、この三つは必ずしも分離していない。

新曲をストリーミングで聴く。

ライブへ行く。

会場で商品を買う。

帰宅して同じ曲をもう一度聴く。

後日ライブ映像を見る。

商品を見るたびに公演を思い出す。

ここでは、

配信 → ライブ → 物販 → 記憶 → 再聴取

という一つの体験が成立している。

したがって次世代音楽企業に必要なのは、ライブ、物販、配信をそれぞれ最適化するだけではない。

三つを一人のファンの時間の中で接続することである。

ライブは最も物理的な音楽体験である

ストリーミングでは、世界中の作品へ瞬時にアクセスできる。

しかしライブには、ストリーミングでは完全に再現できない条件がある。

同じ場所。

同じ時間。

実際の身体。

その場で発せられる声。

照明。

空気。

観客。

偶然。

つまり、

Presence

である。

録音された音楽は何度でも同じデータを再生できる。

ライブは一回ごとに異なる。

同じセットリストでも同じ公演にはならない。

だからライブには、

Non-repeatability

という価値がある。

デジタル化が進んでもライブが消えない理由

音楽へアクセスするだけなら、ライブへ行く必要はない。

ストリーミングの方が安く、早く、便利である。

それでも人はライブへ行く。

これは、音楽体験が情報取得だけではないことを示している。

音圧を身体で受ける。

アーティストが同じ空間にいる。

他者と同じ瞬間を共有する。

その日の出来事として記憶する。

したがって、

Recorded Music = Reproducible Experience

に対して、

Live = Situated Experience

と整理できる。

場所と時間に位置づけられた体験である。

ライブでは観客も体験をつくる

ライブはアーティストから観客への一方向配信ではない。

拍手。

声。

沈黙。

身体の動き。

観客の反応によって空間が変わる。

つまり、

Artist → Audience

ではなく、

Artist ↔ Audience

である。

ライブではCommunityが、抽象概念ではなく物理的Realityとして現れる。

第6章で整理したSelf同士の関係が、一つの会場へ身体を伴って集合する。

Physical Community

この状態を、

Physical Community

と考えることができる。

SNS上のアカウントではない。

実際の人間がいる。

そこには年齢や身体条件の違いもある。

だからライブ設計には、

安全。

アクセシビリティ。

移動。

座席。

音量。

混雑。

医療対応。

まで含まれる。

音楽企業がPhysical Realityへ入るとは、映像演出だけではなく、こうした現実条件まで引き受けることを意味する。

巨大ライブほどTechnologyが必要になる

数万人規模の公演になれば、人間だけの運営では扱いにくい情報量が生まれる。

チケット。

入退場。

交通。

混雑。

音響。

映像。

通信。

セキュリティ。

Technologyは不可欠になる。

しかしTechnologyの目的は人間を管理することではない。

より安全にする。

待ち時間を減らす。

見えにくい人を支援する。

音響を改善する。

つまり、

Technology → Better Physical Experience

へ使う。

Perfumeが示した身体とTechnology

Perfumeの分析では、Technologyは舞台装置の外部ではなくPerformanceそのものへ入っていた。

身体。

映像。

光。

演算。

空間。

が同期する。

ここから次世代ライブの一つの方向が見える。

Technologyによってライブをデジタル化するのではない。

TechnologyによってPhysical Presenceをさらに表現可能にする。

これは生成AI、エッジAI、空間コンピューティングへ直接接続する。

エッジAIが必要になる場所

ライブ会場では、全データを遠隔クラウドへ送り、結果を待つことが適さない場合がある。

映像演出。

音響制御。

安全監視。

字幕。

リアルタイム翻訳。

極めて低い遅延が必要になる。

そこで、

Cloud + Edge

が必要になる。

第2冊で扱う超低遅延エッジAIは、このPhysical Experienceを支える技術になる。

しかし観客を測り尽くさない

カメラやセンサーを置けば、

観客の動き。

表情。

歓声。

滞在。

さまざまな情報を解析できる。

しかし、

測れるから測る

という設計にはしない。

ライブは実験室ではない。

個人識別が必要でない分析は集計レベルで行う。

端末やエッジで処理し、生データを残さない。

同意を取る。

つまり、

Experience Intelligence + Privacy

を両立させる。

観客反応を「作品評価」にしない

歓声が大きい。

身体がよく動いている。

それを、

「この曲の方が優れている」

と自動判定することも危険である。

静かに聴く曲もある。

感動して動けない場合もある。

したがって、

Observable Reaction ≠ Artistic Value

である。

AIは運営や体験改善を支援できるが、芸術価値の判定者にはしない。

⸻

物販――商品は何を売っているのか

ライブ会場には商品がある。

Tシャツ。

タオル。

バッグ。

キーホルダー。

写真。

レコード。

限定品。

経済的には物販である。

しかし、前章で見たように、ファンにとって商品は単なる実用品とは限らない。

ライブで購入したTシャツを見る。

その日の会場を思い出す。

つまり、

Product → Memory

へ変化する。

商品は体験を物理的に保持する媒体になり得る。

Relationship Object

このような商品を、

Relationship Object

として理解できる。

価値は素材原価だけではない。

どのアーティストのものか。

どのツアーか。

どの時期か。

その人自身にどのような記憶があるか。

それらが重なる。

だから音楽物販では、通常の商品マーケティングとは異なる価値構造が成立する。

物販を最大化しすぎない

Relationship Objectとして価値があるからこそ、企業側には自制が必要になる。

ファンは作品やアーティストへの感情によって商品へ通常以上の価値を感じる。

その感情を使って、

商品数を無限に増やす。

限定を連発する。

購買回数を競わせる。

という方向へ行けば、関係を消耗させる。

したがって、

Merchandise Revenue

だけでなく、

Merchandise Meaning

を見る必要がある。

商品数より編集が重要になる

次世代物販では、

何種類増やすか

より、

何を残すか

が重要になる。

ツアーを象徴する商品。

日常的に使える商品。

作品世界をPhysical Representationへ変える商品。

アーティストによって異なる。

ここでも、

One Artist, One Merchandise Architecture

が成立する。

VaundyとVisual Direction

VaundyのようにVisualやDesignまでCreative Directionに含むアーティストでは、物販も単なるロゴ商品とは限らない。

音楽。

映像。

グラフィック。

商品。

が一つのArtist Representationとして接続できる。

つまり、

Music → Visual → Object

という翻訳が起こる。

企業は単にSKUを増やすのではなく、Artist Identityを異なる媒体へ正しく変換する必要がある。

ヨルシカでは本そのものが作品になる

ヨルシカではさらに境界が薄くなる。

本。

音楽画集。

物理的な書簡。

ここでは「物販」と「作品」の区別自体が曖昧になる。

つまり、

Merchandise ≠ Secondary Product

である。

場合によっては物理商品そのものがPrimary Workになる。

これは企業の事業分類を見直す必要性を示している。

商品をMediaとして見る

物販をMediaとして考えると設計が変わる。

何を売るかではなく、

この物体によって何を表現するか

を見る。

すると、

音楽。

ファッション。

出版。

デザイン。

工芸。

複数産業との接続が可能になる。

ただし協業先のブランド価値だけでなくArtist Representationとの整合性が必要になる。

在庫というPhysical Reality

デジタルコンテンツと違い、商品には物理的制約がある。

生産。

在庫。

倉庫。

配送。

返品。

廃棄。

ここで需要予測が重要になる。

AIによって精度を高められる。

しかし、売り切れを完全になくすため過剰生産すれば廃棄が増える。

少なすぎればFOMOが強まる。

したがって、

Demand Forecasting + Sustainability

が必要になる。

受注生産という選択

限定商品を大量に作って売り切る以外にも、

受注。

再販。

予約。

複数のモデルがある。

ファン側のアクセス可能性と在庫リスクを両立できる。

次世代Commerce AIでは、

売上最大化だけではなく、

廃棄。

配送負荷。

在庫リスク。

も目的関数へ入れる。

世界へ商品を届ける難しさ

海外ファンが増えれば、商品も世界へ届けたくなる。

しかし、

送料。

関税。

税制。

決済。

サイズ。

言語。

返品。

国ごとの規制。

がある。

ここでも、

Global Demand ≠ Simple Global Commerce

である。

UMGの各地域法人や物流基盤との接続が重要になる。

⸻

配信――ライブを複製することではない

次に配信である。

ライブ配信。

アーカイブ配信。

短尺映像。

舞台裏。

ドキュメンタリー。

映像作品。

一つのPhysical Eventをデジタルへ変換すれば、会場にいなかった人にも届けられる。

これは非常に大きな価値を持つ。

遠方。

海外。

身体的理由。

仕事。

経済条件。

さまざまな理由で会場へ来られない人が参加できる。

つまり配信には、

Access Expansion

という重要な役割がある。

配信はライブの劣化版ではない

ライブをカメラで撮影し、そのまま流す。

これだけなら、配信はPhysical Experienceの記録になる。

しかし配信には配信固有の表現がある。

カメラアングル。

編集。

字幕。

音響ミックス。

舞台裏。

複数画面。

インタラクティブ機能。

つまり、

Live Reality → Streaming Representation

への翻訳である。

ライブと同じである必要はない。

同じ公演から二つの作品をつくれる

会場の観客が経験したものと、配信視聴者が経験するもの。

両方に価値を持たせることができる。

Physical Version

と、

Digital Version

である。

一方を劣化版にしない。

この発想はライブ配信を独立したCreative Mediumへ変える。

Ado――Controlled Visibilityと配信

Adoでは、映像化するときにもArtist Identityの境界を維持する必要がある。

ライブの臨場感を届ける。

しかし、本人が公開しないVisual Informationを意図せず公開しない。

ここでは、

Media Expansion + Identity Boundary Preservation

が必要になる。

つまり配信Technologyは、可視性を最大化するのではなく、Artist-specificな境界を保持しなければならない。

Perfume――映像で別のRealityをつくる

Perfumeでは逆に、カメラやデジタル映像自体がPerformanceの一部になり得る。

会場から見た舞台と、映像作品として見たPerformanceが異なる。

つまり、

Camera is not merely a recorder.

映像自体がRepresentationを生成する。

同じ配信技術でもArtist Architectureによって役割が違う。

多言語字幕

Global Fan Communityでは字幕が重要になる。

ライブMC。

舞台説明。

ドキュメンタリー。

生成AIによるリアルタイム字幕・翻訳には大きな可能性がある。

しかし自動翻訳の誤りが本人発言として拡散する危険もある。

したがって、

AI Translation + Confidence / Human Review

が必要になる。

重要な発言は確認する。

自動字幕であることを明示する。

アクセシビリティとしての配信

配信には、単なる市場拡大以上の意味がある。

字幕。

手話。

音声説明。

視聴環境の調整。

会場へ来られない人へのアクセス。

Technologyによって音楽体験へ参加できる人を増やせる。

つまり、

Distribution Technology → Accessibility Infrastructure

へ役割を広げることができる。

ライブ後に配信がMemoryになる

一回のライブが終わる。

しかし映像が残る。

何年後にも見られる。

すると、

Event → Archive

へ変化する。

Adoの世界ツアーやRADWIMPSのライブ映像でも見た構造である。

Physical Eventは時間の一点にある。

Digital Archiveは時間を越える。

ArchiveはCatalogへ入る

長期的には、ライブ映像もArtist Catalogの一部になる。

音源カタログ。

MV。

ライブ。

インタビュー。

ファンクラブ資料。

それらが接続される。

つまりカタログ概念そのものが、

Recorded Music Catalog

から、

Multimodal Artist Archive

へ拡張する。

生成AI時代には、ここが非常に大きなKnowledge Assetになる。

⸻

ライブ・物販・配信を一つの時間として見る

三つを統合すると何が見えるか。

ライブ前。

ストリーミングで作品を聴く。

チケットを取る。

商品を見る。

ライブ当日。

会場へ行く。

商品を購入する。

Performanceを体験する。

ライブ後。

セットリストを聴く。

配信を見る。

購入商品を見る。

SNSで語る。

つまり、

Before
→ During
→ After

という一つのExperience Timelineがある。

企業側の事業部門は分かれていても、ファンの時間は一つである。

Before

期待をつくる。

作品へアクセスする。

チケットや会場情報を確認する。

During

身体的体験。

安全。

音響。

商品。

Community。

After

記憶。

再聴取。

映像。

アーカイブ。

再接続。

この三段階を統合することで、Experience Architectureが成立する。

しかし全行動を追跡しない

統合するとデータも接続できる。

誰が曲を聴いた。

チケットを買った。

会場へ入った。

商品を買った。

映像を見た。

企業にとって魅力的なCustomer Journeyになる。

しかし、一人の全行動を常時追跡する必要はない。

必要な目的ごとにデータを分ける。

本人が接続を選択する。

つまり、

Integrated Experience ≠ Integrated Surveillance

である。

One Fan Identityは便利だが慎重に使う

第1節で示したOne Fan Identityを使えば、

会員。

チケット。

商品。

配信。

を一つのAccountで扱える。

これは便利である。

しかし、

便利さ

と、

全データの永久統合

は別である。

権限を分ける。

イベント終了後に不要情報を削除する。

匿名化する。

IdentityはAccessのために使い、Personality Profilingへ過度に転用しない。

Experience Graph

次世代企業では、個人を追跡するのではなく、体験構造そのものをKnowledge Graphとして持つこともできる。

あるライブ。

関連楽曲。

商品。

会場。

映像。

出演者。

権利。

次の公演。

こうした関係を、

Experience Graph

として構造化する。

すると、

「このツアーの関連映像を探す」

「このライブで演奏された旧曲へ戻る」

といったナビゲーションが可能になる。

Fan GraphではなくExperience Graph

これは重要な違いである。

人間を中心に全行動を結ぶ、

Fan Surveillance Graph

ではなく、

作品と体験の関係を中心にする、

Experience Graph

を優先する。

必要なときだけ本人のMembershipや権利を接続する。

Human-centered Architectureとして、この方が自然である。

ライブと物販と配信の収益を別々に見ない

経営では、それぞれ売上が計上される。

しかし長期価値では相互作用がある。

ライブがストリーミングを伸ばす。

ストリーミングがライブ需要をつくる。

ライブが商品価値を高める。

配信が海外需要をつくる。

したがって、

Revenue₁ + Revenue₂ + Revenue₃

だけでなく、

Cross-channel Effect

を見る必要がある。

一つのKPIに統合しない

ただし、すべてを「Fan Value Score」のような一数値へまとめる必要はない。

ライブにはライブの価値。

配信にはAccess。

物販にはPhysical Memory。

それぞれ違う。

Different Experiences, Different Metrics.

統合するのはデータの意味であり、価値の差異を消すことではない。

体験設計からPlatform Architectureへ

ここまで機能が増えると、個別システムでは運営が難しくなる。

Membership。

Ticketing。

Commerce。

Streaming。

Rights。

Identity。

Analytics。

それぞれが別々に動けば、ファンにも企業にも摩擦が生まれる。

そこで、

Experience Platform

が必要になる。

ただし表面上すべてを一つのアプリにすることが目的ではない。

Backendで安全に接続し、必要な画面だけをアーティストごとに提供する。

Shared Infrastructure + Artist-specific Experience

これは第1節の原則をさらに拡張したものになる。

共有する。

Identity。

Payment。

Rights。

Ticketing API。

Commerce。

Streaming Infrastructure。

Security。

しかし、

どの機能を見せるか。

どう組み合わせるか。

はアーティストごとに変える。

つまり、

**Shared Enterprise Platform

* Artist-specific Experience Layer**

である。

Mrs. GREEN APPLEでは統合が早く見える

Mrs. GREEN APPLEの活動では、

音楽。

Ringo Jam。

MGA App。

大型ライブ。

都市企画。

商品。

CEREMONY。

Project-MGA。

が複数方向へ接続している。

そのため、ライブ・物販・配信を個別サービスとしてではなくArtist Ecosystemとして扱う必要性が特に早く現れている。

これは次世代UMJ Platformを考える重要な実例になる。

しかし全アーティストを同じ規模にしない

スピッツ。

Ado。

Vaundy。

ヨルシカ。

それぞれ必要なExperience Architectureは違う。

巨大都市企画が必要なアーティストもいる。

ライブと音源だけで十分な場合もある。

TechnologyはScaleを可能にする。

しかしScaleを義務にしない。

Capability ≠ Requirement

である。

AIが支援すべきもの

生成AIは、ライブ・物販・配信の全域へ入ることができる。

需要予測。

翻訳。

字幕。

FAQ。

商品説明。

アーカイブ検索。

権利確認。

会場運営支援。

しかし、生成AI導入そのものを体験価値にしない。

ファンがAIを意識しない部分で摩擦を減らす用途も多い。

つまり、

Invisible AI where possible.

技術を前面に出すかどうかもArtist Architectureによって決める。

生成型空間音響へ

ライブでは、さらに音そのものをリアルタイムに適応させる可能性がある。

会場形状。

位置。

演出。

複数スピーカー。

パーソナルデバイス。

生成AIと空間音響を組み合わせれば、新しい体験を設計できる。

ただしArtistが意図していない音を勝手に生成しない。

Generative Capability under Creative Direction

という原則が必要になる。

第2冊で扱うGenerative Audioも、この制約下で実装する。

PhysicalとDigitalの境界は消えない

ライブを配信する。

商品をオンラインで買う。

ARを使う。

それでもPhysicalとDigitalは同じにはならない。

身体でいること。

物体を持つこと。

ネットワークでアクセスすること。

それぞれ別の価値を持つ。

したがって目的は、

Physical → Digital

へ一方向に移行することではない。

Physical ↔ Digital

を接続することである。

三つのReality

ライブは、

Physical Reality

を持つ。

物販は、

Material Reality

を持つ。

配信は、

Digital Reality

を持つ。

次世代音楽企業は三つを一つに潰さない。

差異を保持しながら接続する。

ここでも、

Integration without Erasure

が基本になる。

最小構造

本節を最小構造へ圧縮すると、

Streaming
→ Discovery / Access

Live
→ Presence / Shared Experience

Merchandise
→ Material Memory

である。

この三つが循環すると、

Access
→ Presence
→ Memory
→ Return

が生まれる。

そして再び作品へ戻る。

つまり、

Work
→ Streaming
→ Live
→ Merchandise / Memory
→ Streaming / Archive
→ Work

という長期Experience Loopが成立する。

商品販売からExperience Infrastructureへ

20世紀のレコード会社は、録音された商品を大量流通させる能力によって成長した。

2026年の音楽企業には、それに加えて、

人を会場へ安全につなぐ。

Physical Experienceをつくる。

物理的な記憶を残す。

Digital Experienceへ拡張する。

世界へ配信する。

過去へ戻れるようにする。

という能力が必要になっている。

つまり、

Product Distribution Company

から、

Experience Infrastructure Company

への拡張である。

しかし、そのInfrastructureの中心にTechnologyを置かない。

中心にあるのは、

一人の人間が一つの作品と出会い、現実の時間を過ごすこと

である。

次の接点――アプリ

ライブ、物販、配信が接続すると、その入口をどこに置くかという問題が生まれる。

ブラウザ。

メール。

SNS。

複数サービス。

そしてスマートフォン。

2026年の人間にとって、スマートフォンは最も継続的なデジタル接点の一つである。

そこへ、

Membership。

作品。

チケット。

Commerce。

Streaming。

Archive。

Community。

をどこまで接続するのか。

一方で、通知やデータ収集によって生活へ入りすぎないためには、どのような境界が必要なのか。

次節では、アプリとデジタル接点を扱う。

アプリを単なる「ファンクラブのスマートフォン版」ではなく、ArtistとSelfを必要なときに接続するRelationship Interfaceとして読み解いていく。
第3節　アプリとデジタル接点

スマートフォンは、2026年の音楽産業において最も継続的なデジタル接点の一つである。

音楽を聴く。

動画を見る。

ライブを探す。

チケットを表示する。

商品を買う。

ファンクラブを見る。

通知を受け取る。

SNSへ移動する。

一台の端末から、ほとんどすべての音楽体験へアクセスできる。

そのため、アーティストの公式アプリをつくることは、一見すると自然な進化に見える。

しかし、アプリをつくればPlatformになるわけではない。

機能を増やせば関係が深くなるわけでもない。

重要なのは、

なぜアプリが必要なのか

である。

次世代の公式アプリは、ファンを長時間滞在させるための場所ではない。

作品、ライブ、アーカイブ、商品、Communityなど、分散した体験へ必要なときに到達できるRelationship Interfaceとして設計する必要がある。

デジタル接点は既に分散している

一人のアーティストについて知ろうとしても、現在は複数のサービスを行き来することになる。

ストリーミングサービス。

YouTube。

Instagram。

TikTok。

X。

公式サイト。

ファンクラブ。

EC。

チケットサービス。

ライブ配信。

それぞれ別の企業が運営し、別のAccountを持ち、別のデータ構造を持つ。

つまりファン側から見ると、

One Artist
→ Many Digital Touchpoints

である。

アーティストは一人でも、デジタル上では断片化されている。

分散していること自体が問題なのではない

すべてを一つの公式アプリへ移せばよいわけではない。

SpotifyやApple Musicには音楽配信としての強みがある。

YouTubeには映像発見の強みがある。

SNSには拡散性がある。

チケットサービスには興行基盤がある。

それぞれのPlatformには固有の役割がある。

したがって次世代公式アプリの目的は、

Replace every external platform

ではない。

むしろ、

Connect the artist-specific experience across platforms

である。

置き換えるのではなく接続する。

アプリは「ホーム」になり得る

複数の外部サービスが存在する中で、公式アプリが担える重要な役割がある。

Authoritative Home

である。

新曲はどれか。

次のライブはどこか。

どの商品が公式か。

どの映像が公式か。

ファンクラブ情報。

最新ニュース。

アーティスト本人や企業が正式に公開している情報へ、一つの入口から到達できる。

生成AIによって偽情報や偽コンテンツが増える時代ほど、この「公式な入口」の価値は高くなる。

Officialという価値

SNSでは、公式投稿とファン投稿、切り抜き、転載、AI生成物が同じ画面へ並ぶことがある。

その中で、

これは公式情報である

と確認できる場所が必要になる。

したがって公式アプリは、

Content Platformである前に、

Trust Interface

として価値を持つ。

Adoの分析で見たAuthenticity Infrastructureが、ここでファン側のUIへ現れる。

アプリの価値は機能数ではない

音楽。

動画。

チャット。

EC。

チケット。

ゲーム。

AI。

すべてを入れれば多機能になる。

しかし多機能であるほど良いわけではない。

機能が増えれば、

操作が複雑になる。

通知が増える。

データ収集も増える。

維持コストも上がる。

したがって、

Feature Count ≠ Platform Value

である。

必要なのは、そのアーティストとファンの関係に必要な最小機能を選ぶことである。

One Artist, One App Architecture

前節までの原則をここでも適用できる。

Mrs. GREEN APPLE。

Ado。

Vaundy。

ヨルシカ。

スピッツ。

必要なアプリは同じではない。

Mrs. GREEN APPLEでは、ライブ、Community、映像、商品など多数の活動を接続する役割が大きくなる。

Adoでは、作品やライブへのアクセスを提供しながらIdentity Boundaryを保護する設計が重要になる。

長期カタログ型のアーティストでは、アーカイブ探索が重要になるかもしれない。

したがって、

One Artist, One App Architecture

である。

企業側では共通基盤を持つ

一方、全アーティストについて完全に別システムを開発する必要はない。

企業内部では、

Identity。

Membership。

Payment。

Ticketing。

Commerce。

Archive。

Notification。

Analytics。

Security。

Consent。

を共通基盤として持つことができる。

その上にArtist-specificなInterfaceを構築する。

つまり、

**Shared Platform Core

* Artist-specific Interface**

である。

この構造なら、企業側の効率とアーティスト固有性を両立できる。

WebとAppを対立させない

すべての人がアプリをインストールしたいわけではない。

検索結果から公式情報を見たいだけの人もいる。

初めてそのアーティストを知った人へ、いきなりアプリ導入を求めるのは摩擦になる。

したがって、

Web → Open Access

App → Persistent Relationship

という役割分担が考えられる。

Webは入口。

Appは継続利用。

ただし両者の情報を分断しない。

App InstallをFan Conversionにしない

アプリをインストールした。

だから深いファンである。

とは限らない。

ライブのために入れただけかもしれない。

逆にアプリを入れず、何十年も作品を聴いている人もいる。

したがって、

App User ≠ Fan Depth

である。

インストール数をArtist Relationshipの深さへ直接変換しないことが重要になる。

アプリはSelf ↔ Platformの接点である

第6章で整理した、

Self ↔ Platform

が最も具体的に現れるのがスマートフォンである。

一人の人間が、自分の意思でアプリを開く。

作品を見る。

ライブを確認する。

情報へアクセスする。

ここで重要なのは、

Self initiates access

である。

Platform側が常に注意を奪うのではない。

本人が必要なときに接続できる。

Push Notificationという強力な介入

スマートフォンアプリには、Webにはない強い機能がある。

通知である。

新曲。

ライブ。

商品。

生配信。

企業側から一人の端末へ直接情報を届けられる。

これは便利である。

同時に、人間の日常へ割り込む能力でもある。

したがって、

Notification = Privileged Access to Attention

と考える必要がある。

通知を最大化しない

通知を増やせばアプリ起動率は上がるかもしれない。

しかし、

新商品。

残りわずか。

今日まで。

ライブ映像。

毎日のように届けば疲れる。

そこで、

Notification Governance

が必要になる。

新曲だけ。

ライブだけ。

商品だけ。

重要なお知らせだけ。

本人が種類と頻度を選べる。

Quiet Design

優れた次世代アプリには、

Quiet Design

という考え方を置ける。

必要がないときには静かである。

毎日開かせない。

連続ログインを要求しない。

通知を止めても使える。

つまり、

Persistent Availability without Persistent Interruption

である。

いつでも存在する。

しかし、常に人間の注意を要求しない。

DAUを唯一の成功指標にしない

一般的なアプリでは、

Daily Active Users。

Session Length。

Retention。

が重要になる。

しかしArtist Appでは、毎日開く必要がない場合もある。

新曲発表時。

ライブ前。

ライブ後。

特定の時期に利用が増える。

これは自然である。

だから、

High Daily Engagement

だけを成功としない。

むしろArtist Activityのリズムに合った利用を見る。

Artist Timeに合わせる

毎日投稿するアーティスト。

アルバム単位で活動するアーティスト。

長期間制作へ集中するアーティスト。

それぞれ時間が違う。

アプリ側も同じ頻度で更新する必要はない。

つまり、

App Rhythm follows Artist Rhythm.

Platform都合のコンテンツ供給ノルマをArtistへ課さない。

アーティストを「アプリ運営者」にしない

公式アプリをつくると、

本人から毎日投稿してほしい。

限定動画を出してほしい。

配信してほしい。

という需要が生まれやすい。

しかし、それをすべて本人へ戻すと創作負荷になる。

企業側が、

アーカイブ。

スタッフコンテンツ。

公式情報。

ライブ記録。

などで基盤を維持する。

Platform Activity ≠ Artist Constant Labor

という設計が必要になる。

アーカイブがアプリの時間を長くする

新しいコンテンツだけに依存すると、更新がない期間にアプリ価値が下がる。

しかし音楽企業にはカタログがある。

過去作品。

ライブ。

写真。

インタビュー。

過去ツアー。

これらへアクセスできれば、アプリは新着情報だけの場所ではなくなる。

つまり、

News Feed → Living Archive

へ拡張できる。

新しいファンには過去が未来である

長期アーティストほど重要になる。

新しくファンになった人にとって、

十年前のライブ映像。

二十年前のインタビュー。

過去アルバム。

は新しい発見である。

したがってアプリは、

Latest

だけでなく、

Discover the Past

を持つ必要がある。

ここで生成AIが大きな価値を持つ。

AI Archive Guide

「この曲が最初に演奏されたライブはどれか」

「このアルバムについて本人が語った記事を読みたい」

「初期から現在までの作品を知りたい」

こうした質問に、権利処理された公式アーカイブから答える。

つまり、

AI as Archive Guide

である。

これは本人の人格を模倣するAIより、公式音楽Platformには適合しやすい。

AIを本人にしない

生成AIを使えば、

「Adoと話せるAI」

「アーティスト本人のように答えるAI」

をつくることも可能になる。

しかし、本人とSynthetic Representationを混同させてはいけない。

本人が実際に語ったこと。

AIが生成したこと。

を明確に分離する。

つまり、

Artist ≠ Artist-like AI

である。

公式アプリほど、この境界に責任を持つ必要がある。

AIはInterfaceになれる

一方、AIを人格化しなくても価値は大きい。

検索する。

翻訳する。

チケットを探す。

商品の情報を説明する。

ライブ会場を案内する。

アーカイブを横断する。

つまり、

Menu-driven Interface

から、

Intent-driven Interface

へ進める。

「どこに書いてあるか」を探すのではなく、

「何をしたいか」を伝える。

AIが適切な公式機能へ案内する。

IntentからActionへ

たとえば、

「次の東京公演は？」

「この曲が入っているアルバムは？」

「海外発送できる商品だけ見たい」

「字幕付きのライブ映像を探したい」

と聞く。

AIは答えるだけでなく、

公式チケット。

ディスコグラフィー。

EC。

配信。

へ安全に接続できる。

つまり、

Intent → Authorized Action

というInterfaceが成立する。

AIに購買権限を与えるとき

将来的には、

「この商品を注文して」

まで可能になる。

しかし経済行為には明確なApprovalが必要である。

AIが推薦し、そのまま勝手に購入する設計にはしない。

価格。

送料。

数量。

条件。

を示す。

本人が承認する。

つまり、

Recommend → Review → Approve → Execute

である。

推し活AIを購買最適化AIにしない

公式アプリには購買データがある。

したがって、

「この人ならこれも買う」

という推薦は容易になる。

しかし第6章で示したように、

Maximum Revenue per Fan

を目的にしない。

既に似た商品を持っている。

短期間に多数購入している。

本人が通知を減らしている。

そうした条件を尊重する。

Commercial AIにもRestraintを組み込む。

購入しない選択を残す

商品ページを見た。

購入しなかった。

これを失敗イベントとしてだけ扱わない。

比較した。

見るだけで満足した。

後で考える。

理由は分からない。

だから、

No Purchase ≠ Failed Experience

である。

アプリ全体をConversion Funnelとしてだけ設計しないことが重要になる。

デジタルチケットとWallet

スマートフォンはチケット基盤にもなる。

ライブ日程。

チケット。

座席。

入場。

リセール。

本人確認。

交通情報。

これらを一つへ接続できる。

特に公式アプリなら、

Membership → Ticket → Venue

というPhysical Journeyまでつなげられる。

AppからPhysical Realityへ

ライブ当日には、

会場マップ。

入場口。

開演時間。

物販。

交通。

安全情報。

アクセシビリティ。

アプリが現実世界の行動を支援する。

つまりデジタルInterfaceが、

Digital → Physical

へ出る。

この時点でアプリは単なるContent Viewerではなくなる。

Edgeとの接続

会場へ入れば、ローカルネットワークやBluetooth、端末内AIなどを使える可能性もある。

字幕。

座席案内。

混雑情報。

限定的な会場コンテンツ。

ただし位置情報を常時追跡する必要はない。

必要な機能だけ、その場で処理する。

つまり、

Context-aware without permanent tracking

である。

ローカルLLMの意味

第2冊で扱うローカルLLMは、ここで具体的な意味を持つ。

一部の検索。

個人設定。

翻訳。

アクセシビリティ支援。

を端末内で処理できれば、全情報をクラウドへ送る必要がない。

つまり、

On-device Intelligence → Privacy Preservation

という利点がある。

性能だけでなくPrivacy ArchitectureとしてEdge AIを見る。

生体情報は原則として別レイヤーにする

スマートフォンやウェアラブルからは、身体活動や生体情報へアクセスできる場合がある。

しかし音楽公式アプリが当然のように取得する必要はない。

利用目的を限定する。

本人が明示的に選択する。

端末内処理を優先する。

つまり、

Fan App ≠ Health Surveillance App

である。

生体AIを導入する場合には、通常のFan Platformと明確に権限を分離する必要がある。

Camera Permissionも慎重に扱う

AR。

ライブ演出。

撮影。

カメラを使った体験も可能である。

しかし常時Camera Accessを要求する必要はない。

利用するときだけ許可する。

保存範囲を示す。

顔解析を無目的に行わない。

つまり、

Capability does not imply continuous permission.

Permissions as Experience Design

カメラ。

マイク。

位置情報。

通知。

写真。

Bluetooth。

アプリは多くのPermissionを要求できる。

次世代アプリでは、

「全部許可してください」

ではなく、

Why this permission?

を明確にする。

必要な瞬間に説明して求める。

拒否しても主要機能を利用できる。

これがTrustにつながる。

One Fan Identity

Web、App、EC、チケットを接続する場合、

One Fan Identity

は便利である。

しかしOne IdentityはOne Profileを意味しない。

チケット用の本人確認情報。

Communityで表示する名前。

ECの配送先。

それぞれを分離できる。

つまり、

One Identity, Multiple Contextual Representations

である。

AdoのIdentity Architectureをファン側へ反転する

Adoでは、

Private PersonとPublic Artistを分けた。

ファンにも同じ構造を適用できる。

企業には決済上の本人確認をする。

CommunityではNicknameを使う。

ライブではDigital Ticketを表示する。

すべてに同じ個人情報を見せる必要はない。

これがSelective Disclosureである。

データポータビリティ

長期Platformでは、本人の履歴も蓄積する。

Membership。

購入。

ライブ。

お気に入り。

もしサービスを移行したい場合、どこまで持ち出せるのか。

将来的には、

Data Portability

も重要になる。

ファンを過去データで囲い込まない。

Platform Lock-inとの違い

一般的なPlatform戦略では、他サービスへ移りにくくすることが競争力になる場合がある。

しかしArtist Relationshipでは、

Lock-in

と、

Loyalty

を混同してはいけない。

出にくいから残る。

好きだから戻る。

全く違う。

次世代公式アプリが目指すべきなのは後者である。

Exit Design

したがって、アプリにはEntry Designだけでなく、

Exit Design

も必要になる。

退会する。

通知を止める。

データを削除する。

アプリを消す。

手続きが分かりやすい。

そして再び必要になれば戻れる。

Easy Exit + Returnability

である。

Community機能をどう置くか

アプリ内にCommunityを持つ場合も慎重に設計する。

投稿。

コメント。

チャット。

それぞれが必要とは限らない。

一方、ライブ後の感想共有や公式企画への参加が価値になる場合もある。

だからCommunity Layerを独立させる。

本人が使うか選ぶ。

Self ↔ Platform

を利用するだけでも成立する。

Social Graphを作りすぎない

ファン同士をフォローさせればSocial Graphができる。

しかしArtist Appを新しいSNSにする必要はない。

人間関係を大量に保持すると、

モデレーション。

プライバシー。

嫌がらせ。

運営負荷。

も増える。

必要なCommunity機能を最小限にするという選択も合理的である。

Communityと外部SNSを接続する

公式Platformですべてを囲わず、

公式情報。

会員機能。

チケット。

アーカイブ。

は公式アプリ。

広い会話や拡散は外部SNS。

という役割分担も可能である。

つまり、

Owned Platform + Open Social Web

である。

企業が全ての関係を所有しようとしない。

デジタル接点はAppだけではない

ここまで公式アプリを中心に見てきたが、実際には接点はさらに広い。

スマートスピーカー。

自動車。

テレビ。

ウェアラブル。

ゲーム。

ARグラス。

将来的な空間コンピューティング。

つまり、

App = One Interface among Many

である。

次世代Architectureでは、Backend APIを中心に複数Interfaceへ接続できるようにする必要がある。

Voice Interface

「Adoの最新曲をかけて」

「次のライブを教えて」

音声Interfaceも重要になる。

ここでも公式情報への接続を明確にする。

AI音声が本人の声を無断で模倣しない。

つまり、

Voice Access ≠ Artist Voice Simulation

である。

Car Interface

自動車では画面を長く操作できない。

必要なのはシンプルな音声操作である。

このように、同じArtist Platformでも端末ごとにInterfaceは変わる。

One Backend, Multiple Context Interfaces

が必要になる。

Televisionと大画面

ライブ映像はスマートフォンより大画面で見たい場合がある。

アプリをMobileへ閉じ込めず、テレビやWebへ状態を引き継ぐ。

すると、

Mobile → TV → Mobile

と体験が継続する。

One Fan Identityの価値がここにある。

アプリではなくRelationship Layerとして考える

ここまで来ると、「アプリ」という言葉自体が狭くなる。

本当に必要なのは、

スマートフォンの一つのアイコン

ではない。

ArtistとFanを、必要なときに適切なInterfaceで接続する、

Digital Relationship Layer

である。

Mobile Appはその主要な入口の一つにすぎない。

Digital Touchpoint Graph

企業側では、

Web。

Mobile。

Streaming。

Ticketing。

Commerce。

Live。

Archive。

を一つの構造として把握する必要がある。

ただし人間を中心に追跡するのではなく、

Touchpoint Graph

としてサービス間関係を持つ。

どの入口からどの公式機能へ移れるか。

どこに摩擦があるか。

を理解する。

摩擦を減らすAI

たとえば、

ライブ情報をSNSで知る。

公式サイトへ行く。

ログインする。

ファンクラブ認証。

別サイトでチケット応募。

また別サイトで決済。

こうした分断はFan Experienceを悪化させる。

AIや共通Platformが最も価値を出せるのは、こうした企業側の分断を吸収することである。

Reduce organizational fragmentation visible to the fan.

人間を統合するのではなく、企業システムを統合する

ここは極めて重要である。

AI時代には、

ファンの全データを統合する

方向へ考えやすい。

しかし先に統合すべきなのは、

企業側の分断されたシステム

である。

チケット情報。

商品。

作品。

権利。

アーカイブ。

それらを適切に接続する。

つまり、

Integrate enterprise systems, not the human being.

これがHuman-centered Platformの核心になる。

Artist AppからEnterprise Architectureが変わる

表面上は一つの公式アプリでも、裏側では多数の企業システムが動く。

CRM。

CMS。

EC。

Ticketing。

Rights。

Identity。

Data Warehouse。

AI。

Cloud。

アプリ体験を良くしようとすると、企業内部の分断そのものを再設計する必要が出てくる。

だから公式アプリは単なるMarketing Toolではない。

Enterprise Integration Pressure

にもなる。

Project-MGAへの接続

Mrs. GREEN APPLEのようにArtist Activity自体が広がると、デジタル接点も増える。

作品。

ファンクラブ。

MGA App。

ライブ。

都市企画。

CEREMONY。

商品。

これらを継続的に支えるには、アプリだけでなく組織側にもArtist-specificな統合構造が必要になる。

ここで、

Digital Interface ↔ Organizational Architecture

が接続する。

そして次節で扱うProject-MGAへ直接つながっていく。

アプリは企業の鏡でもある

アプリ内で情報が重複する。

ログインが複数必要。

チケットが見つからない。

商品と会員情報がつながらない。

こうした問題はUIだけの問題ではない。

企業内部でデータや事業が分断されている可能性が高い。

つまり、

Bad Digital Experience often reveals fragmented enterprise architecture.

逆に、優れた公式Interfaceをつくるには企業内部の接続が必要になる。

次世代アプリの最小構造

ここまでを最小化すると、公式アプリには五つの役割を置ける。

Official

何が公式か確認できる。

Access

作品、ライブ、商品、情報へ到達できる。

Memory

過去作品や活動へ戻れる。

Identity

安全にMembershipや権利を保持できる。

Choice

通知、データ、Community、購入への関わり方を本人が選べる。

この五つを中心にする。

AIを加えるなら六つ目はNavigationである

生成AIを入れる場合には、

Navigation

を加える。

何を探しているのかを自然言語で伝える。

公式情報から見つける。

必要なら適切な機能へ接続する。

AIは人間の代わりに判断する存在ではなく、

complex platformを簡単に使うための翻訳層

になる。

Appの最終目的

アプリを毎日開かせることではない。

アプリ内で全てを完結させることでもない。

アーティストとファンの間にある不要な摩擦を減らし、必要なときに正しい場所へ接続できること。

つまり、

Digital Touchpoint
→ Lower Friction
→ Better Access
→ Sustainable Relationship

である。

CommunityからPlatformへの転換点

ファンクラブだけならMembership Serviceである。

ライブ、物販、配信まで接続するとExperience Platformになる。

さらにアプリが、

Identity。

Ticketing。

Commerce。

Archive。

Community。

AI。

を横断するInterfaceになると、Platformとしての輪郭が明確になる。

しかし、このPlatformは企業側から先に完成させるものではない。

Artist ActivityとCommunityの拡張によって生まれるRequirementから設計する。

ここに次節への接続がある。

Project-MGAという実例へ

これまでの三節では、

ファンクラブ。

ライブ・物販・配信。

アプリ。

と、ファン側からPlatform形成を見てきた。

しかしPlatformが本当に拡大すると、デジタル機能だけでは足りない。

企業内部の組織そのものを変える必要がある。

アーティスト固有の活動を支えるチーム。

レーベル。

マネジメント。

グローバルネットワーク。

事業開発。

ライブ。

デジタル。

それらをどう接続するか。

Mrs. GREEN APPLEでは、このRequirementに対して実際にProject-MGAという企業構造が形成された。

次節では、Project-MGAを単なる専属チームとしてではなく、一人のアーティストの成長が企業Architectureを変更した実例として読み解いていく。
第4節　Project-MGA

Project-MGAは、Mrs. GREEN APPLEのためにつくられた一つのプロジェクトである。

しかし、その企業的意味を考えると、単なる専属チームやアーティストマネジメント組織として見るだけでは足りない。

重要なのは、その成立方向である。

先に企業の新事業構想があり、そこへMrs. GREEN APPLEを配置したのではない。

アーティストの活動可能性が既存の組織境界を越え始め、その可能性を受け止めるために新しい組織構造が必要になった。

ここには、

Artist
→ New Requirement
→ Organizational Change

という流れがある。

一般的な企業では、組織が人を配置する。

Project-MGAでは、その逆方向――アーティストの成長可能性が組織を生成する――を読み取ることができる。

これは、ここまで検討してきたArtist-centered Managementが、思想ではなく現実の企業構造として現れた重要な事例である。

2021年に始まったProject-MGA

Mrs. GREEN APPLEは2020年に「フェーズ1完結」を宣言し、活動を休止した。

その翌2021年2月、Universal Music Groupと共同して「Project-MGA」が始動した。

発表時点から、これは国内だけを前提とした企画ではなく、UMGの世界的ネットワークを活用しながらMrs. GREEN APPLEのエンタテインメントの可能性を拡張し、世界へ活動を展開する構想として位置づけられた。

つまり、

Current Activity Support

だけを目的とした組織ではなかった。

最初から、

Future Capability

を含んでいた。

ここが重要である。

現在必要な組織ではなく、未来に必要になる組織

通常の組織設計では、

現在どれだけ仕事があるか。

現在何人必要か。

現在どの機能が不足しているか。

を考える。

Project-MGAをより構造的に読むと、それだけではない。

Mrs. GREEN APPLEが、

音楽。

ライブ。

映像。

ブランド。

デジタル。

Community。

海外。

へ活動を広げる可能性を前提として、企業側のCapabilityを先に準備する。

つまり、

Future Artist Possibility
→ Present Organizational Capability

である。

企業経営の言葉へ翻訳すれば、Strategic ForesightとCapability Buildingの組み合わせになる。

フェーズ1からフェーズ2への境界

Project-MGAの成立を考えるうえで、Mrs. GREEN APPLEが活動を「フェーズ」で区切ったことも重要である。

活動休止は単なる停止ではなかった。

旧来の活動形態を一区切りし、その後に異なる構造で再始動する。

すると、

Phase 1
→ Pause
→ Organizational Reconstruction
→ Phase 2

という時間が見える。

フェーズ2は、フェーズ1の活動をそのまま再開するだけではない。

アーティスト側の変化に企業側のArchitecture変更が伴った。

アーティストの変化と企業の変化を同期させる

企業が変わらず、アーティストだけが変化する。

すると、ある時点で両者にGapが生じる。

アーティストはライブ以外のこともしたい。

海外へ進みたい。

映像を拡張したい。

Communityとの新しい接点をつくりたい。

しかし企業側の部門は、

音源。

宣伝。

営業。

という過去の事業単位のままである。

そこで、

Artist Reality ≠ Corporate Architecture

という不一致が起こる。

Project-MGAは、このGapへ企業側が適応したケースとして読むことができる。

レコード会社の境界を越える

従来型のレコード会社が中心的に扱ってきたのは、

録音。

原盤。

宣伝。

流通。

である。

しかしMrs. GREEN APPLEの活動は、それだけでは収まりにくい。

ライブ。

ファンクラブ。

アプリ。

商品。

大型イベント。

ブランド協業。

都市空間。

海外。

他アーティストとの企画。

ここまで広がると、必要なのはRecord Businessだけではない。

Artist Business Architecture

である。

Project-MGAの重要性は、この境界移動にある。

EMI RecordsとProject-MGA

Mrs. GREEN APPLEは音楽レーベルとしてEMI Recordsと接続しながら、Project-MGAというアーティスト固有の組織を持つ。

この二層構造は興味深い。

一方には、Universal Music Japanが長期間蓄積してきたレーベル機能がある。

もう一方には、Mrs. GREEN APPLE固有の活動を扱うArchitectureがある。

したがって、

**Shared Label Infrastructure

* Artist-specific Organization**

という形になる。

これは企業全体を一人のアーティスト仕様へ変更する必要がないという意味でも重要である。

共通化すべきものと固有化すべきもの

企業Scaleを維持するには共通化が必要である。

契約。

経理。

法務。

権利。

データ。

クラウド。

Security。

海外ネットワーク。

こうしたものをアーティストごとにゼロからつくれば非効率になる。

一方、

Artist Identity。

Creative Direction。

Community。

ライブ。

事業開発。

には固有性が必要である。

したがって次世代音楽企業のArchitectureは、

**Shared Corporate Core

* Artist-specific Layer**

になる。

Project-MGAは、そのArtist-specific Layerが組織として表面へ出たケースと理解できる。

Projectという言葉の意味

名称が「Company」でも「Department」でもなく、「Project」である点にも意味がある。

Projectは、固定的な部門より可変性を持ちやすい。

活動に応じて、

必要な人。

必要な技術。

必要な外部Partner。

を接続できる。

音楽産業のようにArtist Activityが変化し続ける領域では、この柔軟性が重要になる。

つまり、

Static Organization

より、

Adaptive Organization

に近い。

しかし一時的なプロジェクトに閉じていない

一般にProjectには開始と終了がある。

しかしProject-MGAはMrs. GREEN APPLEの活動基盤として継続し、フェーズ2以降の多様な事業を支える存在になった。

ここでは、

Project as Temporary Task

より、

Project as Adaptive Artist Organization

という意味合いが強くなる。

固定された企業部門でも、一度限りの施策でもない。

アーティストとともに変化する組織である。

Artist Organizationという新しい単位

従来の企業では、

部署をつくる。

その部署が複数アーティストを担当する。

という設計が自然だった。

Project-MGA型では、

一人のArtist Architectureを中心に複数職能を接続する。

つまり、

Function-centered Organization

から、

Artist-centered Organization

への部分的転換である。

これは顧客企業でいうAccount Teamとも少し違う。

扱う対象が商品販売だけではなく、創作主体の長期的な活動全体だからである。

A&Rも孤立しなくなる

第3章ではA&Rを、アーティストと企業の境界を担う機能として見た。

Project-MGA型になると、その役割も変化する。

A&RだけがArtistを理解していても足りない。

デジタル。

ライブ。

海外。

映像。

データ。

事業開発。

複数の専門家が、同じArtist Contextを共有する必要がある。

つまり、

One A&R knows the artist

から、

Organization shares an artist model

へ進む。

Artist Knowledgeが必要になる

ここで企業AIの必要性が現れる。

活動が大きくなるほど、

楽曲。

過去発言。

ライブ。

商品。

Community。

海外反応。

契約。

映像。

Project。

大量の情報が発生する。

担当者全員がすべてを記憶することはできない。

そこで、

Artist Knowledge Base

が必要になる。

ただし本人のPrivate Personを分析するDatabaseではない。

企業活動に必要なProfessional Contextを構造化する。

Artist Knowledge Graph

具体的には、

Artist。

Work。

Creator。

Live。

Campaign。

Market。

Partner。

Rights。

Audience Segment。

Project。

を関係として持つ。

すると、

「この作品とこのライブ企画はどう接続していたか」

「韓国展開で何を学習したか」

「CEREMONYにはどの外部主体が関与したか」

などを横断的に参照できる。

つまり、

Artist Knowledge → Organizational Memory

へ変える。

担当者が変わっても知識を失わない

大企業では人事異動がある。

担当者が変わる。

退職する。

そのたびにArtist Contextが失われれば、長期関係は弱くなる。

Project-MGAのようなArtist-specific Organizationには、

Institutional Memory

が重要になる。

個人の頭の中にある情報を、適切な権限の下で組織Knowledgeとして残す。

これがAI時代のArtist Managementの重要な基盤になる。

しかし「アーティストモデル」を本人より上に置かない

AIが過去データを学習すると、

「Mrs. GREEN APPLEとはこういうアーティストである」

というモデルをつくれる。

しかし本人たちは変化する。

したがって、

Artist Model(t₀) ≠ Artist(t₁)

である。

Knowledge Baseは正解ではない。

現在の活動を理解するための暫定Representationである。

本人の新しい意思が過去データと矛盾したら、モデル側を更新する。

Project-MGAはArtist Twinではない

次世代企業ITではDigital Twinという言葉を使いたくなる。

しかし一人のアーティストを完全なTwinへ再現する必要はない。

企業に必要なのは、

活動。

作品。

権利。

Project。

公開された方針。

などを扱うOperational Modelである。

つまり、

Artist Operational Model

で十分である。

本人の人格や未来の創作まで予測しようとしない。

Project-MGAとMGA App

Mrs. GREEN APPLEではMGA Appも存在する。

表面ではFan Interface。

内部では、Artist-specific Organizationとの接点になる。

ここで興味深い構造が成立する。

Project-MGA
↔ Digital Platform
↔ Fan

である。

組織。

Technology。

Community。

が分離せず接続し始める。

前節で示した、

Digital Interface ↔ Organizational Architecture

が具体化する。

アプリだけ先進化しても意味がない

アプリ上では統合されて見える。

しかし内部で、

チケット部門。

EC部門。

レーベル。

ライブ。

マネジメント。

が完全に分断されていれば、最終的にファン側へ摩擦が出る。

したがってProject-MGAのような横断組織とDigital Platformは相性がよい。

Integrated Experience requires integrated coordination.

UIだけでは企業分断を隠し切れない。

Project-MGAはPlatformではない

ここで区別も必要である。

Project-MGAそのものをPlatformと呼ぶ必要はない。

Project-MGAは企業組織である。

MGA AppはDigital Interfaceである。

Ringo JamはMembership / Fan Relationを担う。

ライブはPhysical Experience。

それぞれ異なる。

しかし互いに接続することで、

Artist Ecosystem

が形成される。

組織とPlatformを分けて考える

したがって、

Organization ≠ Platform

である。

Organizationは人間と権限の構造。

Platformは継続的なサービスや関係を支える基盤。

両者が接続して初めて、Artist-specificな事業運営が持続する。

この区別は第2冊の実装でも重要になる。

CEREMONYへの接続

Project-MGAの可能性がより明確に見えるのがCEREMONYである。

Mrs. GREEN APPLE自身のライブだけではない。

複数のアーティストを招く。

一つのEntertainment Showを構成する。

ここではArtist Organizationが、自分たちだけを支える機能から、

External Connection

をつくる機能へ広がる。

つまり、

Artist Support Organization
→ Context Creation Capability

である。

アーティストが企業の外側を接続する

CEREMONYには他アーティストが参加する。

するとProject-MGAが扱う関係も、

MGA ↔ Fan

だけではなくなる。

他アーティスト。

他レーベル。

制作チーム。

会場。

スポンサー。

複数主体へ広がる。

ここでProject-MGAはNetwork Coordinator的な機能を必要とする。

Platform化の境界

あるArtist Organizationが、

自分の作品を管理する。

自分のファンを管理する。

だけなら専属組織である。

しかし、

他のCreator。

他のArtist。

企業。

都市。

世界市場。

を継続的に接続し始めると、Platform的機能が現れる。

つまり、

Internal Coordination
→ External Coordination

への転換である。

CEREMONYはその重要なSignalになる。

Platformとは他者が参加できること

Platformを単なる大きなサービスと定義しない。

重要なのは、

Third-party Participation

である。

自分たちだけで完結しない。

他者が参加し、そこから新しい価値が生まれる。

CEREMONYで別アーティストが参加することは、この条件に近づいている。

ただし2026年時点で、Project-MGA全体を完成した音楽Platformと断定する必要はない。

より正確には、

Platform Capability Emerging from an Artist-centered Organization

と読むことができる。

ArtistからPlatformへの途中にOrganizationがある

この点は本章全体の構造をより精密にする。

これまで、

Artist
→ Community
→ Platform

と整理してきた。

しかしMrs. GREEN APPLEの実例では、その間に企業組織が入る。

より具体的には、

Artist
→ Activity Expansion
→ Organizational Requirement
→ Project-MGA
→ Community / Experience Integration
→ Platform Capability

である。

Platformは突然生まれない。

それを運営するOrganizationが必要になる。

TechnologyだけではPlatformにならない

アプリをつくる。

Cloudをつくる。

AIを入れる。

それだけではPlatformにはならない。

誰が運営するか。

誰が意思決定するか。

誰がArtist Contextを理解するか。

誰が権利を処理するか。

誰が問題発生時に責任を持つか。

つまり、

Technology Architecture + Organizational Architecture

が必要になる。

Project-MGAは後者の重要性を示している。

Governanceが必要になる

Activityが広がれば、判断も増える。

作品。

ブランド協業。

イベント。

映像。

海外。

ファンデータ。

AI。

すべてを一人の判断へ集中させることはできない。

そこで、

誰が何を決めるか。

本人承認が必要なものは何か。

企業側で処理できるものは何か。

を定義する。

つまり、

Governance Architecture

が必要になる。

Artist Approval Layer

次世代Artist Organizationでは、すべてを本人へ確認する必要はない。

それでは負荷が大きい。

一方、重要なCreative Decisionを企業だけで決めてもいけない。

そこで、

Routine Operation

Business Decision

Creative Decision

を分ける。

Creative DecisionにはArtist Approval。

Routine Operationは権限委譲。

これによりArtist AutonomyとOrganizational Scalabilityを両立できる。

AI Agentを入れるならここである

第2冊でAI Agentを実装するとき、Project-MGA型組織は重要な対象になる。

たとえば、

権利確認Agent。

海外市場分析Agent。

ライブ運営Agent。

アーカイブAgent。

Commerce Agent。

複数のAgentが動く。

しかし勝手に実行しない。

権限を持つ。

重要操作にはApprovalを要求する。

つまり、

AI Agent → Recommendation / Preparation → Human Approval → Execution

という構造にする。

AIは組織を置き換えるのではない

Artist-centered OrganizationではContext理解が非常に重要になる。

生成AIは情報処理を高速化できる。

しかし、

作品の方向性。

アーティストとの信頼。

最終的な企業責任。

をAIへ全面委譲することはできない。

AIは、

Organizational Intelligence Amplifier

として置く。

人間組織を縮小するためではなく、分断された知識を接続する。

Project-MGAで学んだことを企業へ戻す

Project-MGAがMrs. GREEN APPLEにとって成功しても、その知識がProject内に閉じれば企業全体への効果は限定される。

重要なのは、

何がArtist-specificだったか。

何が一般化可能か。

を分けることである。

たとえば、

専属組織そのもの

は全Artistに必要ではない。

しかし、

Artist Growth can require Corporate Architecture Change

という原則は一般化できる。

Specific CaseからStructural Principleへ

企業学習は、

Project-MGA
→ Copy Project-MGA

ではない。

正しくは、

Specific Case
→ Structural Analysis
→ General Principle
→ New Artist-specific Implementation

である。

これが次世代企業AIの中心的なOperationになる。

Adoへコピーすると失敗する

たとえばAdoに、Mrs. GREEN APPLEと同じCommunity PlatformやPublic Event Architectureをそのまま適用すれば、Artist Identityと衝突する可能性がある。

Adoには、

Privacy。

Voice Identity。

Controlled Visibility。

Global Live。

が重要である。

必要な組織は違う。

したがって、

Generalize the operation, not the form.

形ではなく、組織をArtistに合わせて変えられるという原理を一般化する。

Vaundyなら別の組織になる

Vaundyでは本人のCreative Direction範囲が広い。

必要なのは、

本人の制作領域を企業が分断すること

ではなく、

その統合されたCreative IntentをScaleさせるOrganizationかもしれない。

つまりArtist-specific Organizationは、一つの形式ではない。

ヨルシカならRights Architectureが中心になる

音楽。

文章。

出版。

ライブ。

作品世界。

これらを横断するなら、Narrative IPとRightsを扱う組織能力が重要になる。

Project-MGAから学ぶのは、

専属組織をつくること

ではない。

作品Realityに合わせて企業側の境界を変更すること

である。

Project-MGA → UMJ

ここで知識循環が始まる。

Project-MGAで学習した、

Artist-specific Organization。

Digital Fan Platform。

大型体験。

Community。

Global Expansion。

それらの知識をUMJへ戻す。

つまり、

Project-MGA → UMJ

である。

一つのProjectから企業が学習する。

UMJ → Project-MGA

逆方向もある。

UMJは、

レーベル。

権利。

デジタル。

営業。

マーケティング。

法務。

Technology。

という共通Capabilityを持つ。

それをProject-MGAへ提供する。

したがって、

Project-MGA ↔ UMJ

である。

これがCompany ↔ Artistの企業内部版になる。

UMJ → UMG

さらにUMJは孤立していない。

親会社グループには世界各地域の法人と事業基盤がある。

日本でProject-MGAから得られた知識のうち、一般化可能なものをグローバルへ返せる。

つまり、

UMJ → UMG

である。

ここから企業学習が世界へ広がる。

UMG → UMJ

逆に、

海外市場データ。

現地Partner。

ライブ運営知識。

権利。

Streaming Market Intelligence。

がUMJへ戻る。

つまり、

UMJ ↔ UMG

である。

Project-MGAをこの循環へ接続すると、

Artist-specific Local Learning ↔ Global Corporate Learning

が成立する。

世界各法人との横方向の学習

さらに親会社を経由するだけでなく、

日本法人。

韓国。

米国。

欧州。

東南アジア。

各地域が互いに学習できる。

すると、

UMJ ↔ Other UMG Companies

という横方向のKnowledge Networkになる。

日本で生まれた仕組みが世界へ行く。

世界で生まれた仕組みが日本へ来る。

Japan → World

Project-MGAは、Mrs. GREEN APPLEの世界展開という意味でも、

Japan → World

の実装基盤になり得る。

しかし第5章で見たように、海外展開は日本性を消すことではない。

Artist Identityを保持する。

地域ごとにContextを翻訳する。

つまり、

Japanese Artist Identity
→ Local Translation
→ Global Access

である。

World → Japanも必要になる

海外での反応を日本側へ返す。

何が理解されたか。

どこに文化差があったか。

どの作品が支持されたか。

その知識から次の展開を考える。

つまり、

Japan → World → Learning → Japan

である。

海外展開は一方向の輸出ではない。

学習循環である。

Project-MGAは日本法人の実験環境になり得る

この意味でProject-MGAには、もう一つの企業的価値がある。

巨大企業全体を一度に変える必要はない。

一つのArtist Organizationで、

新しいDigital Platform。

AI。

データ。

Global Workflow。

を試す。

成果を検証する。

成功した原理だけを企業全体へ展開する。

つまり、

Controlled Organizational Experiment

として機能できる。

ただしアーティストを実験対象にしない

ここには重要な境界がある。

「Project-MGAを企業実験に使う」

とは、Mrs. GREEN APPLEを実験材料にするという意味ではない。

本人たちの活動上必要な仕組みをつくる。

その結果から企業が二次的に学習する。

順序は、

Artist Need → Implementation → Corporate Learning

である。

Corporate Experiment → Artist

ではない。

Fact → Observation → Hypothesis → Verification

Project-MGAは、本書全体で採用してきた分析法を適用しやすい。

まずFactがある。

Project-MGAが存在する。

Mrs. GREEN APPLEの活動を支えている。

フェーズ2以降、活動領域が拡張している。

そこからObservationを行う。

Artist-specific Organizationが形成されている。

次にHypothesisを置く。

アーティストの成長が企業Architectureを変化させ得る。

そして今後、

他アーティスト。

他地域。

UMG内の組織。

との比較でVerificationする。

Project-MGAを神話化しない

一つの成功例を未来企業の完成形として扱わない。

Project-MGAにも課題はある。

活動Scaleが増えればGovernanceは複雑になる。

Creative FreedomとCorporate Responsibilityを調整する必要がある。

「コロンブス」MVの公開停止と公式謝罪が示したように、Artist-specific Organizationを持っていても、文化的・歴史的文脈の確認や企業責任が不要になるわけではない。

むしろScaleが大きくなるほどReview Architectureが重要になる。

FailureもOrganizational Memoryへ入れる

企業学習では成功だけを残してはいけない。

何がうまくいかなかったか。

どの確認が不足したか。

どこでRiskを検出できたか。

それを構造化する。

つまり、

Success Memory + Failure Memory

である。

失敗を消すのではなく、同じ問題を繰り返さないためのInstitutional Knowledgeにする。

Cultural Context Review

世界展開するArtist Organizationには、

歴史。

宗教。

民族。

ジェンダー。

地域文化。

などを考慮する能力が必要になる。

AIは複数地域の文脈を事前確認する支援をできる。

しかし最終判断は人間が行う。

つまり、

AI Context Check
→ Specialist Review
→ Creative Decision

という仕組みが考えられる。

Project-MGAから見える次世代企業の最小構造

ここまでを最小化すると、Project-MGAの企業的価値は四段階で整理できる。

第一に、

Artist Potential

がある。

第二に、

その可能性が既存企業構造とのGapを生む。

Architecture Gap

第三に、

新しいArtist-specific Organizationをつくる。

Organizational Adaptation

第四に、

そこで得られた知識を企業へ戻す。

Corporate Learning

したがって、

Artist Potential
→ Architecture Gap
→ Organizational Adaptation
→ Learning

である。

そして再びArtistへ戻る

企業が学習すれば、次の支援Capabilityが高まる。

さらにアーティストの活動可能性が広がる。

すると、

Artist
→ Organization
→ Learning
→ Better Organization
→ Artist

という循環になる。

これこそ、第3章で示したCompany ↔ Artistの実装形である。

ProjectからPlatformへ

Project-MGAは、組織として始まった。

しかし、

MGA App。

Ringo Jam。

ライブ。

商品。

都市企画。

海外。

CEREMONY。

と接続することで、組織の外側に継続的なArtist Ecosystemが形成され始めている。

したがって、

Project
→ Organization
→ Experience Network
→ Platform Capability

という進化を観測できる。

まだ完成したPlatformと固定する必要はない。

重要なのは方向である。

Platformの先にEcosystemがある

Platformが成立すると、その上で複数主体が関係する。

Artist。

Fan。

Other Artists。

Creators。

Companies。

Cities。

Global Markets。

すると、

Artist-centered Platform

から、

Artist-originated Ecosystem

へ進む可能性がある。

ここにMrs. GREEN APPLEの現在地の独自性がある。

Project-MGAの本当の意味

Project-MGAを最も短く定義するなら、

Mrs. GREEN APPLEを企業の既存構造へ適応させる組織ではなく、企業構造の側をMrs. GREEN APPLEの可能性へ適応させる試み

として読むことができる。

この方向転換が重要である。

企業が中心ではない。

Platformが中心でもない。

最初にArtist Potentialがある。

しかし、Artistだけですべてを担うわけでもない。

企業がArchitectureをつくる。

Technologyが支える。

Communityが広がる。

そして学習が企業へ戻る。

次のCEREMONYへ

Project-MGAが内部組織の再設計だとすれば、その外部への展開を最も明確に示すのがCEREMONYである。

Mrs. GREEN APPLEだけを支える。

そこから一歩進み、

他のアーティストを招く。

異なるファンが集まる。

異なる音楽が同じ場に存在する。

つまり、

Artist-centered Organization

が、

Multi-artist Context

をつくり始める。

ここで初めて、

自分の活動を支えるOrganization

から、

他者が参加できるPlatform的機能

への境界が見える。

次節では、CEREMONYを扱う。

単なるフェスティバルではなく、なぜ一つのアーティストが他の表現者のための「場」をつくるのか。

競争するアーティスト同士を同じ空間へ置くことで何が生まれるのか。

そしてArtistからContext Creatorへという変化が、次世代音楽企業のPlatform Architectureへどのようにつながるのかを読み解いていく。
第5節　CEREMONY

CEREMONYは、Mrs. GREEN APPLEの活動を考えるうえで重要な境界にある。

単独ライブではない。

通常の対バンでもない。

既存の音楽賞でもない。

Mrs. GREEN APPLE自身が主催者側に立ち、異なるアーティストを一つの場へ招き、観客とともに新しいエンタテインメント空間をつくる。

2025年6月18日にKアリーナ横浜で初開催された「Mrs. GREEN APPLE presents『CEREMONY』」には、Mrs. GREEN APPLEに加え、ATEEZ、日向坂46、HY、LE SSERAFIM、M!LK、My Hair is Bad、the engy、TOMOOが出演した。公式発表でも、Mrs. GREEN APPLEを除く出演者はアルファベット順で示され、単一ジャンルへ統一されたラインアップではなかった。

ここで起きているのは、

Artist performs

から、

Artist creates a context

への変化である。

自分たちが出演する場から、自分たちが場をつくる側へ

通常、アーティストはライブやフェスへ出演する。

主催者がいる。

会場がある。

企画がある。

そこへアーティストが参加する。

CEREMONYでは、Mrs. GREEN APPLEが「presents」の主体になる。

つまり、

Participant → Organizer / Curator

という役割変化が起こる。

これは小さな違いではない。

自分たちのPerformanceだけを設計すればよかった状態から、

他のアーティスト。

出演順。

時間。

観客体験。

チケット。

物販。

映像。

運営。

まで含む全体Contextを考える立場へ移るからである。

ArtistからContext Creatorへ

ここで、

Context Creator

という概念が重要になる。

作品をつくる。

ライブをする。

だけではない。

他者の作品が存在できる「文脈」をつくる。

これはPlatform的機能へ近い。

Platformとは、必ずしもソフトウェアサービスではない。

他者が参加でき、その参加によって新しい価値が生まれる基盤である。

CEREMONYには、その萌芽を見ることができる。

2025年は一日、2026年は二日間へ

2025年の初回開催後、CEREMONYは2026年にも継続された。

2026年は6月10日・11日の二日間、同じKアリーナ横浜で開催され、公式サイトでは各出演アーティストのPerformance時間を15〜20分程度とする構成も案内された。

ここで重要なのは、単発イベントで終わらなかったことである。

Event₁ → Event₂

が成立した。

しかも、

一日開催

から、

二日開催

へ拡張した。

つまりCEREMONYは少なくとも2026年時点で、一度限りの周年企画から継続可能なFormatへ近づいたと見ることができる。

そして2027年開催が決まった

さらに2026年8月17日、公式サイトは「CEREMONY 2027」を2027年6月16日・17日に開催すると発表した。

これは本節にとって重要な最新Factである。

2025。

2026。

2027。

少なくとも三年にわたる時間軸が見えた。

したがってCEREMONYを、

One-off Event

として扱うことは既に難しい。

より正確には、

Recurring Artist-originated Entertainment Format

と位置づけられる段階へ進んでいる。

EventからInstitutionへ

継続することで意味が変わる。

一度なら企画である。

二度なら継続性が見える。

三年目が決まれば、ある程度のInstitutional Memoryが形成される。

つまり、

Event
→ Recurrence
→ Format
→ Institution-like Structure

という進化可能性がある。

まだ恒久制度と断定する必要はない。

しかし「毎年戻ってくる場」になる可能性が現実になり始めている。

京都大作戦との違いと対応

10-FEETの京都大作戦では、長期間にわたって同じ地域へアーティストと観客が戻るPhysical Communityを見た。

CEREMONYは歴史がまだ短い。

しかし共通点がある。

自分たちだけのライブを越え、

Other Artists + Audience + Repeated Place / Time

を形成することである。

一方、違いも大きい。

京都大作戦には地域とフェス文化の長期蓄積がある。

CEREMONYは、都市型・アリーナ型のEntertainment Showとして形成途上にある。

同じContext CreatorでもArchitectureは異なる。

「フェス」と呼べば十分なのか

複数アーティストが出演するので、フェスティバルとして理解することもできる。

しかしCEREMONYという名称と構造は、単純なフェス分類だけでは捉えにくい。

2025年の公式発表では「新しいエンターテインメントショー」として位置づけられた。

ここには、

Festival

より広い設計意図を読む余地がある。

ただし、その「新しさ」を過剰に思想化する必要はない。

事実として見るべきなのは、

異なるジャンルの表現者を集める。

一つの空間へ配置する。

Mrs. GREEN APPLEが主催側に立つ。

という構造である。

ジャンル横断

初回出演者を見るだけでも、

バンド。

K-POP。

アイドル。

ダンス＆ボーカル。

シンガーソングライター。

異なる音楽文化が同じ場へ配置された。

ここでは、

Same Genre Community

をつくるのではない。

Different Artist Communities

を同じ空間へ置く。

これは重要である。

各アーティストにはそれぞれFan Baseがある。

そのFan Base同士が一日だけでも接触する。

すると、

Community A ↔ Community B

という新しい接続可能性が生まれる。

観客は「自分の推し」以外を見る

単独ライブでは、ほとんどの観客が同じArtistを目的に集まる。

CEREMONYでは違う。

ある人はMrs. GREEN APPLEを目的に来る。

別の人はATEEZ。

LE SSERAFIM。

HY。

TOMOO。

他の出演者。

そこで、自分が普段聴かない音楽を同じ空間で体験する可能性が生まれる。

つまり、

Known Artist → Unknown Artist Discovery

がPhysical Spaceで起こる。

これはストリーミングのRecommendationとは別のDiscovery Architectureである。

Physical Recommendation

アルゴリズムは、

「この曲が好きなら、この曲も」

と推薦する。

CEREMONYでは、

「この場へ来たなら、異なる表現も同時に経験する」

という構造になる。

これは、

Physical Recommendation

と表現できる。

ただし推薦するのはAIではない。

Curatorial Contextそのものである。

ここにArtistによるCurationの価値がある。

Curationはランキングではない

複数アーティストを集める方法には二つの方向がある。

一つは、

順位をつける。

賞を与える。

勝者を決める。

もう一つは、

同じ場へ置く。

CEREMONYは少なくとも現時点では後者である。

したがって、

Ranking

ではなく、

Co-presence

が中心になる。

誰が一位かではない。

異なる表現が同じ時間を共有する。

CompetitionとCoexistence

もちろん音楽市場には競争がある。

チャート。

再生数。

チケット。

ブランド契約。

アーティスト同士が市場で競争しないわけではない。

しかし同じアーティストが、

競争相手

でありながら、

同じ舞台を共有する表現者

にもなれる。

つまり、

Competition + Coexistence

を同時に持つ。

これは音楽生態系を理解するうえで重要な構造である。

他者を消さずに自分の場をつくる

Platform化という言葉には、巨大企業が他者を自社規格へ取り込むイメージがある。

CEREMONYでは別の可能性を見ることができる。

他のアーティストはMrs. GREEN APPLEになる必要はない。

音楽性を合わせる必要もない。

それぞれのArtist Identityを保持したまま参加する。

つまり、

Participation without Identity Erasure

である。

Platformが他者を均質化しない。

この原則は次世代Artist Platformにとって非常に重要である。

「CEREMONY」という共通Frame

異なるArtist Identityを一つへ同化させないためには、上位に共通Frameが必要になる。

その役割を果たすのが、

CEREMONY

というEvent Identityである。

Mrs. GREEN APPLE。

出演アーティスト。

それぞれのIdentityを残す。

その上に、

CEREMONYという共通Contextを置く。

つまり、

Artist A
Artist B
Artist C
↓
Shared Event Context

である。

統一するのではなく、接続する。

Mrs. GREEN APPLE自身も一出演者になる

主催者でありながら、自らもPerformanceを行う。

ここにも興味深い二重性がある。

Host + Participant

である。

完全に外部から他アーティストを管理するPlatform Operatorではない。

自らも同じ文化空間の中で表現者として参加する。

この点で、一般的なテクノロジーPlatform企業とは異なる。

Artist-originated Platform

SpotifyはTechnology Companyが音楽Platformを運営する。

CEREMONY型では、

Artist自身の文化活動からPlatform機能が生まれる。

したがって、

Platform-originated Artist Ecosystem

ではなく、

Artist-originated Platform Capability

である。

この方向が本章の核心になる。

Project-MGAとの関係

前節で、Project-MGAをArtist-specific Organizationとして分析した。

CEREMONYが成立するには、その背後にOrganizationが必要になる。

出演交渉。

制作。

会場。

チケット。

権利。

運営。

配信。

商品。

複数の機能を調整する。

つまり、

Project-MGA / Corporate Capability
→ CEREMONY

という関係がある。

Artistの構想だけでは大規模な場は持続しない。

企業Architectureが実装する。

Artist Vision → Organizational Execution

ここで、

Artist Vision
→ Organization
→ Physical Reality

という流れが成立する。

アーティスト側に構想がある。

企業組織がRequirementへ変換する。

会場、契約、Technologyとして実装する。

観客が現実に体験する。

これは第2冊のImplementation Architectureへ直結する。

2025年CEREMONYは配信へ拡張された

初回CEREMONYは会場だけで終わらなかった。

2025年9月にはTVerとWOWOWで放送・配信され、TVerでの無料配信はMrs. GREEN APPLEメンバーの発案によるものだったと公式サイトが説明している。またWOWOWでは過去ライブと合わせた特集として放送・配信された。

ここで、

Physical Event → Digital Distribution

が成立する。

会場へ行かなかった人にもEvent Experienceが開かれる。

EventからMediaへ

ライブが映像化されること自体は珍しくない。

しかしCEREMONYでは、

複数アーティストが一つの番組・配信Contextへ再構成される。

つまり、

Event

が、

Media Property

へ変わる可能性を持つ。

会場。

配信。

アーカイブ。

YouTube。

複数の媒体へ展開できる。

2026年から2027年へ、アーカイブも次年度へ接続する

2026年8月17日の2027年開催発表では、同時に「CEREMONY 2026」DAY-1出演アーティストのライブパフォーマンスを一曲ずつYouTubeで先行公開することも発表された。

ここでは、

2026 Event Archive → 2027 Event Announcement

という時間接続が起こっている。

過去のEventが次のEventへの入口になる。

つまり、

Eventₙ → Archive → Eventₙ₊₁

という循環である。

これは継続Formatが形成される際の重要な構造になる。

Live EventがCatalogになる

一度の公演を映像化する。

YouTubeで公開する。

配信する。

するとEvent自体がCatalog Assetになる。

作品カタログとは別に、

Event Catalog

が形成される。

三年、五年と続けば、

CEREMONY 2025。

2026。

2027。

それぞれの出演者、Performance、映像が蓄積する。

これは将来、非常に大きなCultural Archiveになり得る。

Event Knowledge Graph

企業側では、これを構造化することができる。

Year。

Artist。

Song。

Performance。

Rights。

Audience。

Video。

Partner。

これらを接続すると、

CEREMONY Knowledge Graph

が形成できる。

そこから、

過去出演者を探す。

共演関係を見る。

地域別需要を見る。

映像権利を確認する。

といった活用が可能になる。

CEREMONYはDiscovery Engineにもなり得る

Eventが継続し、アーカイブが蓄積すると、新しいアーティスト発見の入口にもなる。

「2025年CEREMONYで初めてTOMOOを知った」

「2026年出演者から別ジャンルへ広がった」

こうしたDiscoveryが積み重なる。

するとCEREMONYは、

Performance Platform

だけでなく、

Discovery Platform

としての機能を持ち得る。

ただし「次に売るアーティストを選ぶ装置」にしない

Discovery機能が強くなると、企業は、

どの新人を出せば売れるか。

どの出演者が最もConversionしたか。

とデータ化したくなる。

それ自体は事業分析として有用である。

しかし出演者選定をデータだけへ委ねれば、既に人気のあるアーティストへ偏りやすい。

したがって、

Data-informed Curation

であって、

Data-determined Curation

にはしない。

最終的な編成には人間の文化的判断を残す。

Weak Signalの観測地点

むしろCEREMONYには、まだ巨大市場化していない表現を早く観測できる可能性がある。

新しいアーティスト。

新しいジャンル。

異なる世代。

異なる国。

そこで生まれる観客反応。

つまり、

CEREMONY → Cultural Weak Signal Observatory

として使える可能性がある。

ただし観客を過剰計測しない。

作品と文化の変化を見る。

海外アーティストとの接続

初回からATEEZやLE SSERAFIMのように、日本国外を基盤とするアーティストも参加した。

ここでCEREMONYは、

Japan ↔ Korea

を含むCross-border Cultural Contextにもなる。

将来的にさらに地域が広がれば、

Japan ↔ Asia ↔ World

へ展開する可能性がある。

ただしこれは現時点ではPotentialとして分けて扱う必要がある。

日本から世界へ「イベントそのもの」を持ち出せるか

海外展開というと、

Mrs. GREEN APPLEが海外公演をする

ことを考える。

しかしPlatform化が進めば別の選択肢が生まれる。

CEREMONY Formatを海外へ展開する

ことである。

これはArtist Exportではなく、

Experience Format Export

になる。

ただし2026年時点で海外CEREMONYが決定しているというFactではない。

将来のScenarioである。

Experience Architectureの輸出

もし実現すれば、

日本で確立した、

Curation。

Production。

Brand。

Digital Distribution。

Community。

を地域ごとに翻訳することになる。

つまり、

Japan-created Experience Architecture
→ Local Translation
→ World

である。

これはUMJからUMGへの知識循環とも整合する。

CEREMONYとUMG

UMJ単独で海外へ進むより、UMGの各地域法人と接続できれば、

現地アーティスト。

会場。

権利。

流通。

配信。

を組み合わせやすくなる。

したがってPotentialとして、

CEREMONY / UMJ
↔ UMG Global Network

を考えることができる。

ここではイベントそのものが企業グループ内Knowledgeを循環させるNodeになる。

他法人にも逆輸入できる原理

すべての国でCEREMONYという名前のイベントを開く必要はない。

重要なのは、

Artist can curate other artists and create a recurring context

という原理である。

それぞれの地域で別のArtist、別のFormatに翻訳できる。

つまり、Project-MGAと同じく、

Copy the principle, not the surface form.

である。

商品もCEREMONY Identityを持つ

CEREMONYには独自のOfficial Goodsも展開されている。

2026年には会場販売だけでなく、開催後にオンライン受注販売が行われ、日本国内・国外の双方から購入できる仕組みも用意された。

ここでは商品も、

Mrs. GREEN APPLE単独の物販

ではなく、

CEREMONYというEvent Identityの物販

になる。

つまりEvent Brandが独立したRepresentationを持ち始める。

Event Brand

一つのアーティストの名前とは別に、

CEREMONYという名称を記憶する。

来年もある。

出演者が変わる。

商品がある。

配信がある。

すると、

Artist Brand

の下から、

Event Brand

が独立し始める。

これはPlatform化の重要なSignalである。

Artist Brandから独立しすぎると何が起こるか

将来的にCEREMONY Brandが巨大化した場合、一つの問いが生まれる。

Mrs. GREEN APPLEが中心であり続けるのか。

それともCEREMONYそのものが独立した文化ブランドになるのか。

現時点では答えを出す必要はない。

しかし企業Architectureとしては重要である。

Artist-originated Brand → Independent Event IP

へ進む可能性があるからである。

独立しても起源を消さない

もしEvent IPが成長しても、

Mrs. GREEN APPLEから生まれたというOriginは重要なIdentityになる。

Platformが成長すると創業者やOriginを消す必要はない。

一方、Originへ過度に依存して本人負荷を増やさない。

つまり、

Origin Identity + Operational Independence

を将来的には検討できる。

Artistを毎年過剰稼働させない

CEREMONYが継続Formatになるほど、Mrs. GREEN APPLE側の負荷管理が重要になる。

毎年、

企画。

出演。

宣伝。

映像。

を本人たちがすべて担えば持続しにくい。

だからProject-MGAや企業側がOperational Infrastructureを厚くする必要がある。

Event Growth ≠ Artist Workload Growth

でなければならない。

PlatformはArtistを自由にするためにもある

ここでPlatform概念を逆転できる。

Platform化とは、Artistへ仕事を増やすことではない。

むしろ、

繰り返し発生する運営。

権利処理。

配信。

チケット。

商品。

をInfrastructure化し、

ArtistがCreative Directionへ集中できるようにする。

つまり、

Platform → Artist Freedom

という方向もある。

CEREMONYとGovernance

複数アーティストが参加するとGovernanceはさらに複雑になる。

出演契約。

肖像。

原盤。

映像配信。

YouTube公開。

商品。

スポンサー。

それぞれ権利者が違う。

ここで、

Multi-party Rights Governance

が必要になる。

これを人力だけで毎年処理するのは大きな負担になる。

Rights Graphが価値を持つ

誰がどのPerformanceの権利を持つか。

放送可能期間。

配信地域。

YouTube公開範囲。

これらをRights Graphとして管理する。

すると、

「2026 DAY-1のこの曲を2027告知で公開できるか」

という判断を高速化できる。

CEREMONYの継続性が高まるほど、この基盤の価値は増す。

AIによるRights Assistant

次世代AIは、

出演契約を読む。

権利条件を構造化する。

公開可能範囲を確認する。

担当者へ注意点を提示する。

ことができる。

ただし最終法的判断をAIへ任せない。

AI Rights Assistant → Human Legal Approval

とする。

AIによるCurationは補助に留める

どのアーティストを招くかについても、

市場データ。

音楽的関連。

Fan Overlap。

海外需要。

をAIで分析できる。

しかし、その結果をそのままLineupにしない。

意外性。

文化的意味。

新しい組み合わせ。

は、人間によるCuratorial Judgmentが重要である。

つまり、

AI discovers possibilities. Humans create the context.

である。

CEREMONYの「場」としての価値

最終的にCEREMONYの価値を一つに絞るなら、

異なるものを同じ場へ置けること

である。

同じにするのではない。

順位を決めるのでもない。

異なるアーティストが異なるまま存在する。

観客も異なる。

それでも同じ時間と空間を共有できる。

この構造は音楽だけでなく、社会のCommunity Designとしても興味深い。

DiversityからConnectionへ

多様性とは、異なるものが存在することである。

しかし存在するだけでは互いに接続しないこともある。

CEREMONYでは、

Diversity → Encounter

が起こる。

違うものが出会う。

そこから新しい発見が生まれる可能性がある。

つまり、

Diversity + Shared Context → Connection Potential

である。

接続しても一体化しない

ただし、Connectionの結果として全員が一つになる必要はない。

好きにならなくてもよい。

自分のArtistだけを見る人もいる。

それでも同じ場へ存在した経験が残る。

したがって、

Connection ≠ Assimilation

である。

この境界が、次世代Platformの重要な原則になる。

CEREMONYを最小構造へ圧縮する

CEREMONYの現在地は、

Artist
→ Host
→ Curator
→ Context Creator

という役割拡張として整理できる。

Event側では、

Single Live
→ Multi-artist Event
→ Recurring Format
→ Platform Capability

となる。

さらに、

Physical Event
↔ Digital Distribution
↔ Archive
↔ Next Event

という時間循環が形成され始めている。

Project-MGAからCEREMONYへ

前節では、

Artist Potential
→ Organizational Adaptation

を見た。

本節では、

Organizational Adaptation
→ External Context Creation

へ進んだ。

つまり、

Mrs. GREEN APPLE
→ Project-MGA
→ CEREMONY

という一つの構造が見える。

Artistが企業組織を変える。

変わった企業組織が、Artistの外側へ新しい場をつくる。

これはCompany ↔ Artistの循環が外部へ開いた状態である。

CEREMONYから次の企業学習へ

そして、そこで得た知識は再び企業へ戻る。

Multi-artist Event。

Rights。

Fan Community。

Broadcast。

Digital Archive。

Cross-border Artists。

そのKnowledgeをProject-MGAだけに閉じず、UMJへ戻すことができる。

すると、

CEREMONY
→ Project-MGA
→ UMJ

という学習経路が生まれる。

さらに、

UMJ → UMG → Other Markets

へ展開できる可能性がある。

Platformは完成していない

ただし、2027年開催が決まったからといって、CEREMONYを完成したPlatformと呼ぶ必要はない。

まだ変化している。

出演構成も変わる。

配信方法も変わる。

規模も変わるかもしれない。

重要なのは、

継続性と第三者参加が確認できるようになったこと

である。

これはPlatform化の重要な条件である。

CEREMONYの現在地

2025年に始まった。

2026年に二日間へ拡張した。

2027年の開催も決まった。

そして映像は放送・配信・YouTubeへ展開され、物販も国内外へ広がっている。

したがって2026年8月時点で、CEREMONYは、

**Recurring Physical Event

* Digital Media Property
* Event Brand
* Multi-artist Context**

という複数の性質を持ち始めている。

次の問い――これらは一つの事業生態系なのか

ここまで第7章では、

ファンクラブ。

ライブ。

物販。

配信。

アプリ。

Project-MGA。

CEREMONY。

を見てきた。

これらを別々の新規事業と考えることもできる。

しかしMrs. GREEN APPLEを中心に見ると、相互に接続している。

作品が人を集める。

Communityが形成される。

MGA Appが接点になる。

Project-MGAが企業側を支える。

ライブがPhysical Experienceになる。

商品がMemoryを残す。

CEREMONYが他のアーティストへ場を開く。

配信が会場の外へ拡張する。

ここまで来ると、一つずつを個別に見るより、

相互作用する事業生態系

として見る方が自然になる。

次節では、Mrs. GREEN APPLEがつくる事業生態系を扱う。

どこまでがArtist Businessで、どこからPlatformなのか。

作品、Community、Technology、Organization、他アーティスト、都市、世界市場が接続すると、音楽企業の事業単位そのものはどのように変わるのか。

CEREMONYという「場」から、その場を含むEcosystem全体へ観測点を広げていく。
第6節　Mrs. GREEN APPLEがつくる事業生態系

Mrs. GREEN APPLEを2026年の音楽企業という視点から見ると、単一の事業分類へ収めることが難しくなっている。

音楽を制作する。

ストリーミングで届ける。

ライブを開催する。

ファンクラブを運営する。

アプリを持つ。

商品を展開する。

企業と協業する。

都市空間で企画を行う。

CEREMONYを開催し、他のアーティストを同じ場へ招く。

海外へ活動を広げる。

そして、その全体をProject-MGAというアーティスト固有の組織が支える。

一つひとつを別事業として見ることはできる。

しかし相互の関係を見ると、別の構造が現れる。

Music
↔ Experience
↔ Fan
↔ Community
↔ Platform
↔ Organization
↔ Partner
↔ Other Artists
↔ World

複数の主体と事業が、一つのArtist Identityを起点に相互作用し始めている。

ここで初めて、「事業ポートフォリオ」ではなく事業生態系という言葉が適切になる。

事業が多いことと、生態系であることは違う

企業が多数の事業を持つだけならDiversificationである。

音源。

ライブ。

物販。

映像。

それぞれ独立して売上を生む。

これだけではEcosystemとは言いにくい。

生態系になるためには、ある活動が別の活動へ影響し、その結果が再び最初の活動へ戻る必要がある。

Mrs. GREEN APPLEでは、その循環が見え始めている。

新曲を出す。

ストリーミングで聴かれる。

新しい人が知る。

ライブへ進む。

ライブからCommunityが強まる。

アプリやファンクラブへ接続する。

商品や映像を通じて体験が持続する。

その関係が次の大型企画を支える。

そして新しい作品が生まれる。

つまり、

Work
→ Discovery
→ Experience
→ Relationship
→ Participation
→ New Experience
→ New Work

である。

Product PortfolioからInteraction Systemへ

従来型の事業分析なら、

音源事業。

ライブ事業。

物販事業。

ファンクラブ事業。

として売上を分解する。

必要な分析である。

しかし生態系では、

何がどれだけ売れたか

だけでなく、

一つの活動が別の活動をどう変えたか

を見る。

ライブ後に旧曲再生が増える。

CEREMONYで別アーティストを発見する。

都市企画から初めてMrs. GREEN APPLEへ接触する。

アプリからライブへ進む。

つまり価値が事業間を移動する。

ここでは企業の基本単位が、

Product

から、

Interaction

へ広がる。

中心にあるのは音楽である

しかし、事業生態系という言葉を使うと、音楽が多数の事業の一つへ後退したように見える危険がある。

順序は逆である。

中心には作品がある。

曲が生まれる。

人が聴く。

意味を感じる。

そこから活動が広がる。

したがって、

Platform → Music

ではない。

Music → Relationship → Platform

である。

Mrs. GREEN APPLE型の事業生態系が一般的なTechnology Platformと異なる最も重要な点がここにある。

Music Core

事業がどこまで大きくなっても、中心に、

Music Core

を残す。

ライブの規模が拡大する。

ブランド協業が増える。

アプリが高度化する。

CEREMONYが継続する。

それでも新しい作品がなければ、生態系は次第にArtist EconomyからEntertainment Brand Economyへ変質する。

それ自体が必ずしも悪いわけではない。

しかしMrs. GREEN APPLEというArtist Identityとの一貫性を保つなら、音楽が新しい関係を生成し続けることが重要になる。

Artist Identityが生態系の一貫性をつくる

事業が多様化すると、それらを何が一つにしているのかという問題が生じる。

アプリ。

ライブ。

商品。

イベント。

都市企画。

それぞれだけを見れば別の事業である。

しかし、

Mrs. GREEN APPLE

というArtist Identityを共有することで、一つの文脈に入る。

つまり、

Artist Identity = Ecosystem Coherence Layer

として機能する。

一般企業ならCorporate Brandが果たす役割の一部を、ここではArtist Identityが担っている。

だからブランド管理だけでは足りない

ただしArtist Identityをロゴやカラーへ還元してはいけない。

作品。

声。

言葉。

ライブ。

活動姿勢。

時間。

それらの蓄積によってIdentityは形成される。

したがって生態系の一貫性も、

同じロゴをつける

ことではない。

同じArtist Realityから自然に導出された活動か

を見る必要がある。

すべての事業を行う必要はない

事業生態系が成長すると、

ホテル。

飲食。

ゲーム。

教育。

金融。

何でもArtist Brandで展開できるようにも見える。

しかしCapabilityがあることと、実行すべきことは違う。

Capability ≠ Strategic Fit

である。

その活動がArtist Identityとどうつながるか。

ファンに何の価値を返すのか。

企業側にどのCapabilityがあるのか。

これらを検証する必要がある。

生態系は無限拡張を意味しない。

Boundary Management

むしろ生態系化すると、何をしないかが重要になる。

どの協業を断るか。

どの事業へ入らないか。

どこまで本人が関与するか。

つまり、

Expansion Management

だけでなく、

Boundary Management

が必要になる。

AdoのIdentity分析ではVisibility Boundaryを見た。

Mrs. GREEN APPLE型ではBusiness Boundaryが重要になる。

Project-MGAが内部のCoordination Layerになる

活動が増えるほど、Artist本人だけでは全体を調整できない。

そこで前節のProject-MGAが意味を持つ。

音楽。

ライブ。

デジタル。

商品。

Community。

海外。

複数の専門機能を、Artist Contextの周囲で調整する。

つまりProject-MGAは、

Internal Coordination Layer

として捉えることができる。

Artist Ecosystemの外側に見えるPlatformだけでなく、その内側にOrganizationが必要になる。

Organizationがなければ生態系は断片化する

ライブチームだけがライブを考える。

ECチームは商品だけを見る。

Digitalチームはアプリだけを見る。

それぞれ個別最適すれば、ファン側では一つのArtist Experienceなのに企業内部では別々の事業になる。

すると、

重複。

矛盾。

過剰な施策。

ブランド不整合。

が起こる。

そこで、

Cross-functional Coordination

が必要になる。

Project-MGA型の価値は、この横断性にある。

一つのArtist Stateを共有する

次世代企業ITへ翻訳すれば、複数部署が同じ「現在地」を参照できる必要がある。

現在どの作品期なのか。

どのライブが進行しているか。

どの市場へ展開しているか。

どの企画が正式決定しているか。

何が仮説なのか。

これを共通化する。

つまり、

Shared Artist State

である。

企業内部で異なる部署が異なるRealityを持たないようにする。

事業生態系にはMemoryが必要になる

活動が複雑になるほど、現在だけでは足りない。

なぜこの企画を始めたのか。

過去に何がうまくいったか。

何が失敗したか。

海外で何を学んだか。

CEREMONYの前年はどうだったか。

こうしたMemoryが必要になる。

つまり、

State + Memory

が生態系運営の基本になる。

Continuous Learning

そして次の活動結果を再びMemoryへ入れる。

観測する。

検証する。

更新する。

したがって事業生態系は固定Architectureではない。

Continuous Learning System

として考える必要がある。

Mrs. GREEN APPLEがPhaseという考え方を採用してきたこととも整合する。

変化を例外として扱わない。

変化することを前提に企業側も更新する。

Phaseという企業設計

Phase 1。

活動休止。

Project-MGA。

Phase 2。

さらにその後。

この時間構造から企業側が学べることは大きい。

Artist Careerを、

Continuous Linear Growth

だけで考えない。

一度止める。

再設計する。

Scaleを変える。

活動領域を変える。

つまり、

Phase Transition

を正式な経営選択肢として持つ。

成長し続けることだけが成功ではない

人気が上がれば、

公演数を増やす。

商品を増やす。

露出を増やす。

という線形成長へ進みやすい。

しかし、それではArtist Sustainabilityを損なう可能性がある。

生態系には、

拡張。

維持。

休止。

再設計。

という複数Modeが必要になる。

つまり、

Growth Mode

だけではなく、

Regeneration Mode

を持つ。

Ecosystem Health

ここから企業は、単一事業の売上だけでなく生態系全体の状態を見る必要が出てくる。

Artist Workload。

Fan Sustainability。

Community Health。

Platform Reliability。

Revenue。

Rights Risk。

Brand Fit。

Global Growth。

複数の状態を同時に見る。

これを、

Ecosystem Health

として考えることができる。

ただし一つの点数には圧縮しない。

「成長しているから健康」とは限らない

売上が増えている。

会員数が増えている。

ライブ規模が大きい。

それでも、

本人が疲弊している。

ファンが過剰支出している。

Platform障害が増えている。

運営負荷が限界に近い。

ならば持続可能とは言えない。

したがって、

Growth ≠ Health

である。

この区別は、Artist Ecosystemが巨大化するほど重要になる。

CEREMONYが他者への接続を開いた

前節で見たCEREMONYは、生態系が自分たちの内部から外部へ開く重要な地点である。

それまでは、

Mrs. GREEN APPLE。

その作品。

そのファン。

が中心だった。

CEREMONYでは他アーティストが入る。

そのファンも入る。

つまり、

Closed Artist Ecosystem

から、

Open Cultural Ecosystem

へ一部が開く。

ここでPlatform的性質が強くなる。

Third-party Participation

Platformの重要な条件は、第三者が参加できることである。

CEREMONYでは、

Other Artists

が参加する。

将来的にCreator、企業、地域などがさらに継続参加するなら、Platform Capabilityは強くなる。

ただし参加者をMrs. GREEN APPLEの下位へ置くのではない。

それぞれのIdentityを保持する。

Independent Identity + Shared Context

が重要になる。

PlatformとEcosystemの違い

ここで二つの言葉を分ける。

Platformは、

接続を可能にする基盤

である。

Ecosystemは、

その基盤の上や周囲で複数主体が相互作用する状態

である。

したがって、

Platform ⊂ Ecosystem

と見ることもできる。

アプリやCEREMONYなどが接続基盤となり、その周囲にArtist、Fan、企業、Creator、地域が関係する。

生態系の中心を一つに固定しない

ただしArtist-originated Ecosystemだからといって、すべての価値がArtistから一方向に流れるわけではない。

ファンがCultureを広げる。

他アーティストから新しい刺激が入る。

企業がTechnologyを提供する。

地域がPhysical Placeを提供する。

つまり、

Multiple Value Sources

が存在する。

起源はArtistでも、成熟した生態系は複数主体によって維持される。

Artist-centeredとArtist-dependentを分ける

ここは特に重要である。

Artist-centered

は、Artist Identityと創作を尊重して設計すること。

Artist-dependent

は、全機能が本人の継続稼働なしには動かないこと。

後者では持続しない。

したがって次世代生態系は、

Artist-centered, but not artist-overloaded.

である必要がある。

本人が休んでもInfrastructureは動く

情報管理。

チケット。

アーカイブ。

商品発送。

問い合わせ。

権利管理。

これらまで本人が止まれば停止する構造にはしない。

Artistが制作へ集中している期間も、最低限のRelationship Infrastructureは企業側で維持する。

つまり、

Creative Independence + Operational Continuity

を両立する。

Fanも中心の一つである

Artistだけでなく、Selfも重要である。

音楽を聴く。

ライブへ行く。

参加する。

しかし全員が同じ深さで参加しなくてよい。

したがってEcosystem Membershipを階段にしない。

Listener

のままでもよい。

Communityへ入ってもよい。

Platformを使ってもよい。

CEREMONYへ行ってもよい。

異なる入口を保持する。

Open Periphery

生態系の外周は開いている方がよい。

初めて一曲を聴いた人。

イベントでたまたま知った人。

別アーティスト目的でCEREMONYへ来た人。

そこから自然に内側へアクセスできる。

つまり、

Open Periphery, Structured Core

である。

入口は開く。

内部の権利・Identity・Securityは適切に管理する。

ファンを囲い込むより入口を増やす

Platform StrategyではLock-inを高めたくなる。

しかしArtist Ecosystemでは、外部ストリーミングやSNSとの共存が必要である。

Spotifyで聴く。

YouTubeで見る。

公式アプリへ来る。

再び外へ出る。

つまり、

Open Ecosystem

である。

価値は「外へ出られないこと」ではなく、「戻る理由があること」に置く。

外部Platformとの関係

Spotify。

Apple Music。

YouTube。

TikTok。

SNS。

これらは競合でもあり、Distribution Partnerでもある。

自社Platformだけでは世界中へDiscoveryを広げにくい。

したがって、

Owned Platform + External Platforms

を使い分ける。

Owned PlatformではIdentity、Membership、Archiveなど深い関係を支える。

External PlatformではDiscoveryとReachを広げる。

DiscoveryとRelationshipを分離する

この役割分担を最小化すると、

External Platforms → Discovery

Artist Platform → Relationship

である。

もちろん完全には分離しない。

しかし企業Architectureとして区別すると分かりやすい。

すべてを自社内に閉じ込める必要がない理由もここにある。

事業生態系と都市

2025年の10周年企画では、商業施設や原宿など物理的な都市空間との接続も見られた。

ここではArtist Ecosystemがデジタルとライブ会場の外へ出る。

店舗。

街路。

商業施設。

都市が一時的にExperience Layerになる。

つまり、

Artist Ecosystem ↔ City

である。

都市もPlatformの一部になり得る

街の複数地点で体験が展開されれば、一つの建物ではなく都市全体がNavigation Spaceになる。

ここでは、

交通。

店舗。

広告。

飲食。

地域ルール。

多数の外部主体とのCoordinationが必要になる。

音楽企業がPhysical Platformへ広がるとは、このような複雑性も引き受けることである。

地域経済への波及

ファンが移動する。

宿泊する。

飲食する。

商品を買う。

Artist Activityは音楽企業外にも経済効果を生む。

つまり、

Artist Economy → Local Economy

へ広がる。

しかし混雑や環境負荷も生じる。

したがって地域連携にもSustainabilityが必要になる。

Partner Ecosystem

ブランドや地域と協業する場合には、

Partner Ecosystem

が形成される。

しかし、協業数を増やすことが目的ではない。

Artist RepresentationとのFitを見る。

Fan Valueを見る。

地域価値を見る。

この三者が接続するものを選ぶ。

Partnership Quantity ≠ Ecosystem Quality

である。

海外展開すると生態系も翻訳が必要になる

韓国公演。

将来の他地域。

海外へ進むと、日本国内で成立した体験をそのままコピーできない。

Ticketing。

Fan Culture。

言語。

商品。

決済。

会場。

法制度。

異なる。

したがって、

Ecosystem Export

ではなく、

Ecosystem Translation

が必要になる。

Artist Identityは保持する

ローカライズしすぎれば、地域ごとに別のMrs. GREEN APPLEになる。

それではIdentityが分裂する。

だから、

Core Identity = Stable

Experience Layer = Localized

という構造が考えられる。

これは第9章の日本から世界への分析へ接続する。

Project-MGA ↔ UMJ ↔ UMG

ここで企業階層を重ねる。

Project-MGAはArtist-specific Layer。

UMJはJapan Corporate Layer。

UMGはGlobal Network Layer。

したがって、

Project-MGA
↔ UMJ
↔ UMG

という三層がある。

Local Artist EcosystemとGlobal Corporate Ecosystemが接続する。

ここにUMJが独立系の小規模企業とは異なる強みがある。

日本で学び、世界へ返す

Mrs. GREEN APPLEの活動から得た知識を、

UMJへ戻す。

一般化可能な原理を抽出する。

UMGへ共有する。

世界各法人が必要に応じて翻訳する。

つまり、

Local Innovation → Global Learning

である。

世界で学び、日本へ戻す

逆方向には、

Global Touring。

Streaming。

Rights。

Technology。

各国のFan Culture。

のKnowledgeがある。

それをUMJへ戻す。

Project-MGAが活用する。

つまり、

Global Learning → Local Adaptation

である。

この往復があることで、事業生態系は日本国内だけで閉じない。

Japan ↔ World

したがって、最終構造は一方向の、

Japan → World

ではない。

Japan ↔ World

である。

日本で生まれたArtist Identityを世界へ運ぶ。

世界での経験を日本へ戻す。

次の作品や企業Capabilityへ反映する。

これが継続的なGlobal Learning Networkになる。

生態系には企業外部の知識も入る

UMGだけですべてを学ぶ必要もない。

Technology Company。

大学。

映像制作。

ライブ事業者。

地域。

Creator。

外部Knowledgeがある。

次世代音楽企業は閉じたVertical Integrationだけでなく、

Selective Open Innovation

も必要になる。

必要なCapabilityを外部から取り込み、自社とArtist Contextへ翻訳する。

AIは生態系全体の翻訳層になる

ここまで主体が増えると、情報量は人間だけでは扱いにくくなる。

Artist。

Work。

Fan。

Community。

Live。

Commerce。

Partner。

Rights。

Market。

Global Company。

AIはこれらを一つへ潰すのではなく、相互に翻訳する層として使える。

つまり、

AI = Ecosystem Translation Layer

である。

Artist Intelligence

Artistの作品と活動を理解する。

Community Intelligence

集計された反応や課題を見る。

Business Intelligence

収益、需要、在庫を理解する。

Rights Intelligence

権利と許諾を確認する。

Global Intelligence

地域差を理解する。

これらを分離した上で、必要な時に接続する。

一つの巨大AIにしない

すべての情報を一つのモデルへ無制限に渡す必要はない。

権限が違う。

機密性が違う。

目的が違う。

したがって、

Federated Intelligence

のように役割を分ける方が適切になる。

Artist情報を扱うAgent。

Rightsを扱うAgent。

Commerceを扱うAgent。

それぞれ最小権限で動く。

第2冊でのAI Agent Runtimeは、このArchitectureとして実装できる。

Authoritative Dataが必要になる

生態系が大きくなるほど、

公式情報。

推測。

市場予測。

ファン投稿。

を混同してはいけない。

そこで、

Fact
Observation
Hypothesis
Prediction

を分ける。

Project-MGAでの企業判断も、CEREMONYの次の企画も、これを明確にする。

企業AIが「事実のように仮説を語る」ことを防ぐ。

FactからNext Algorithmへ

事業生態系そのものが、継続的な学習Loopになる。

Fact
→ Observation
→ Hypothesis
→ Verification
→ Implementation
→ New Fact

である。

そして結果を次のAlgorithmへ戻す。

この循環が続けば、企業は固定された成功モデルではなく学習するOrganizationになる。

Artist Representationから企業Algorithmへ

第4章・第5章では、作品そのものから文化変化やArtist-specificな構造を読み取った。

Mrs. GREEN APPLEの場合、そのRepresentationが、

Community。

Platform。

Project-MGA。

CEREMONY。

という現実の企業構造と対応し始めている。

ここから、

Artist Representation
→ Organizational Requirement
→ Business Architecture

という重要な経路が見える。

ただし作品から事業を機械的に導出しない

作品に「世界」という言葉があるから海外事業をする。

Community的な歌詞だからCommunity Serviceをつくる。

そのような単純な対応ではない。

必要なのは、作品、本人発言、実際の活動、市場反応を複数資料で突合することである。

つまり、

Representation is a signal, not a command.

この慎重さを維持する。

生態系の価値を売上だけで測らない

もちろん事業である以上、収益は必要である。

しかし生態系では長期資産も形成される。

Artist Brand。

Catalog。

Community。

Trust。

Event IP。

Knowledge。

Global Network。

これらは単年度売上だけでは測れない。

つまり、

Current Revenue + Future Capability

を見る必要がある。

Capability Portfolio

Mrs. GREEN APPLEの事業生態系がUMJへ生む最大の価値の一つは、Capabilityの蓄積かもしれない。

Artist-specific Organizationを運営する能力。

大型体験を設計する能力。

Digital Platformを運営する能力。

Multi-artist Eventをつくる能力。

海外展開する能力。

これらは次のArtist、次のProjectにも応用できる。

つまり、

Business Portfolio

だけではなく、

Capability Portfolio

が形成される。

しかし他アーティストへコピーしない

能力は共有する。

Architectureは個別化する。

これが重要である。

CEREMONY運営能力を持っていても、全アーティストにCEREMONYをやらせない。

アプリ基盤を持っていても、全員へ同じアプリを出さない。

つまり、

Shared Capability + Selective Realization

である。

事業生態系から企業生態系へ

Mrs. GREEN APPLEの周囲に形成された生態系で企業が学習する。

そのKnowledgeがUMJへ戻る。

別アーティストへ異なる形で実装される。

すると今度はUMJ全体が、

複数のArtist Ecosystemを持つ企業

になる。

つまり、

Artist Ecosystem₁
Artist Ecosystem₂
Artist Ecosystem₃
↓
Corporate Ecosystem

という構造が生まれる可能性がある。

UMJは「一つのPlatform」になる必要があるのか

ここで次の問いが出る。

すべてのArtist Ecosystemを統合し、UMJという巨大な共通Fan Platformをつくるべきなのか。

必ずしもそうではない。

Artist Identityが異なる。

Communityも違う。

関係距離も違う。

表面を一つへ統合すると、固有性を失う可能性がある。

企業側では共通Infrastructureを持つ。

しかしファン側ではArtist-specificな世界を保持する。

この二層構造が自然である。

Invisible Corporate Platform

つまりUMJのPlatformは、ファンから必ずしも一つの巨大アプリとして見える必要はない。

裏側で、

Identity。

Rights。

Data。

Security。

Cloud。

AI。

Global Connectivity。

を共有する。

表側には複数のArtist-specific Interfaceがある。

つまり、

**Invisible Corporate Platform

* Visible Artist Platforms**

というArchitectureである。

これは第2冊の実装へ非常に自然につながる。

生態系を最小構造へ圧縮する

Mrs. GREEN APPLEの事業生態系を最小化すると、

最初に、

Artist / Music

がある。

そこから、

Self

へ届く。

Self同士が、

Community

を形成する。

関係を支えるため、

Platform

が発達する。

活動を支えるため、

Organization

が進化する。

他者が参加することで、

Ecosystem

へ開く。

そして世界へ接続する。

つまり、

Artist
→ Work
→ Self
↔ Community
↔ Platform
↔ Organization
↔ Ecosystem
↔ World

である。

しかし矢印は一方向ではない

Worldから新しい知識が戻る。

EcosystemからArtistが刺激を受ける。

CommunityからPlatformが変わる。

Organizationから新しいCapabilityが提供される。

したがって最終的には、

すべてが双方向である。

これがPortfolioとEcosystemの最大の違いである。

Mrs. GREEN APPLEがつくっているもの

Mrs. GREEN APPLEがつくっているのは、単なる巨大なファンクラブではない。

単なるアプリでもない。

単なるライブブランドでもない。

単なる多角化事業でもない。

2026年時点でより正確に表現するなら、

音楽を中心に、作品、ファン、Community、Technology、企業組織、他アーティスト、物理空間、世界市場が相互作用する動的なArtist-centered Business Ecosystem

である。

ただし、まだ形成途中である。

だからこそ重要である。

完成したモデルを観察しているのではない。

Platformがどのように生まれ、生態系へ変化していくのか、その生成過程を現実時間で観測できる。

次節――アーティスト発プラットフォーム

ここまで来れば、第7章の最後の問いは明確になる。

このMrs. GREEN APPLE固有の生態系から、一般化可能な企業原理は何か。

すべてのアーティストが同じ規模へ拡張するわけではない。

すべてがアプリを持つ必要もない。

CEREMONYを開催する必要もない。

それでも一つの原理は抽出できる。

Platformは企業が先につくってアーティストを入れるものだけではない。

作品が人を動かす。

関係が形成される。

新しいRequirementが生まれる。

企業構造が変わる。

その結果としてPlatform Capabilityが形成されることがある。

次節では、アーティスト発プラットフォームという概念へ進む。

Technology CompanyがつくるPlatformと何が違うのか。

Artist IdentityはPlatformの中心にどこまで残るのか。

複数Artist PlatformをUMJ・UMGはどのように支えるべきなのか。

そして、アーティストから始まった小さな関係が、なぜ企業と世界を接続するInfrastructureへ成長し得るのか。

第7章全体をそこへ収束させる。
第7節　アーティスト発プラットフォーム

第7章では、ファンクラブから始めた。

ファンクラブがデジタル会員基盤へ変わる。

ライブ、物販、配信が一つの体験時間として接続される。

アプリが複数の接点を横断するInterfaceになる。

Artist Activityの拡張によってProject-MGAのような組織が生まれる。

その組織がCEREMONYという他のアーティストも参加できる場を実装する。

そしてMrs. GREEN APPLEを中心として、作品、ファン、Community、Technology、Organization、企業、他アーティスト、都市、世界市場が相互作用する事業生態系が形成され始める。

ここまでを一本の流れにすると、

Fan Club
→ Community
→ Digital Relationship
→ Organization
→ Platform Capability
→ Ecosystem

となる。

しかし、この順序で最も重要なのは最後のPlatformではない。

最初にアーティストと作品があることである。

ここに、一般的なTechnology Platformとは異なる「アーティスト発プラットフォーム」の特徴がある。

PlatformからArtistを集めるモデル

現代のデジタル産業には、多くのPlatformが存在する。

サービスをつくる。

利用者を集める。

Creatorを参加させる。

Network Effectを発生させる。

音楽ストリーミングも、その一部をこの構造で理解できる。

最小化すれば、

Platform
→ Artists / Creators
→ Users

である。

Platformが先に存在し、その内部へ多数のCreatorとUserが入る。

これは巨大Scaleを実現する強力なArchitectureである。

しかし、Mrs. GREEN APPLEを中心に見えてきた方向は逆である。

ArtistからPlatformが生まれるモデル

最初に作品がある。

作品へ人が反応する。

繰り返し聴く。

ライブへ行く。

Communityが形成される。

活動が増える。

既存システムでは支えられなくなる。

新しいOrganizationがつくられる。

デジタル基盤が発達する。

他者が参加する。

ここで初めてPlatform Capabilityが現れる。

つまり、

Artist
→ Work
→ Self
→ Community
→ Requirement
→ Organization / Infrastructure
→ Platform

である。

Platformが需要を生成したのではない。

既に存在する文化的関係がPlatformを必要とした。

この因果方向が重要である。

アーティスト発プラットフォームとは何か

したがって本書では、アーティスト発プラットフォームを、

アーティストの作品と活動から生じた関係が一定の規模と複雑性へ達した結果、その関係を持続・拡張し、さらに他者の参加を可能にするために形成される事業・技術基盤

として整理できる。

ただし、この定義には三つの条件がある。

第一に、Artist Identityが起点である。

第二に、CommunityそのものとPlatformを混同しない。

第三に、第三者が参加して新しい価値を生成できる段階になるとPlatform性が強まる。

CommunityはPlatformではない

ファンが100万人いる。

それだけではPlatformではない。

Communityは、

People ↔ People

の関係である。

Platformは、

その関係や活動を支え、複数主体が継続参加できる、

Infrastructure

である。

したがって、

Community ≠ Platform

である。

この区別は最後まで維持する必要がある。

ファンクラブも直ちにPlatformではない

会員管理。

限定コンテンツ。

チケット先行。

これだけならMembership Serviceである。

しかし、

Identity。

Commerce。

Ticketing。

Archive。

Community。

Live。

Streaming。

外部サービス。

がAPIや共通基盤によって接続されれば、Platform的性質が強くなる。

つまりPlatformは名称ではなく、

接続可能性と継続性

によって判断する。

第三者参加が境界になる

さらに重要なのが、

Third-party Participation

である。

Mrs. GREEN APPLEとそのファンだけが利用する仕組みならArtist-specific Serviceとして理解できる。

しかしCEREMONYのように、

他アーティスト。

そのファン。

制作会社。

放送・配信事業者。

などが参加する。

すると、

Internal Relationship Infrastructure

から、

External Participation Infrastructure

へ一段進む。

ここがPlatform化の重要な境界になる。

CEREMONYが示したもの

CEREMONYではMrs. GREEN APPLEが、自らPerformanceするだけでなく他のアーティストを同じContextへ招く。

すると、

Artist → Host → Curator → Context Creator

という役割変化が起こる。

さらにイベントが継続し、映像、商品、次年度企画へ接続すれば、単発イベントを越えたFormatが形成される。

つまりPlatformとはアプリだけではない。

継続的に他者が参加可能なContextそのものもPlatform Capabilityを持ち得る。

Physical Platform

この点から、Platform概念をDigitalだけに限定しない方がよい。

CEREMONY。

京都大作戦。

ライブ空間。

都市企画。

そこではPhysical Placeが他者を接続する。

したがって、

Digital Platform

だけでなく、

Physical Platform

が存在する。

そして現代の音楽企業では両方が接続する。

Digital ↔ Physical

公式アプリでイベントを知る。

チケットを取得する。

Physical Venueへ行く。

商品を買う。

ライブを体験する。

帰宅後に配信を見る。

アーカイブへ戻る。

つまり、

Digital
→ Physical
→ Digital

という循環がある。

次世代Artist Platformは、この二つを別世界として扱わない。

しかし同一化もしない。

それぞれの固有価値を保持したまま接続する。

Platformの中心はアプリではない

ここからもう一つ重要な整理ができる。

Platformを一つのアプリとして考える必要はない。

ファンから見えるのは、

MGA App。

Ringo Jam。

CEREMONY。

ライブ。

公式EC。

など複数のInterfaceでよい。

裏側で、

Identity。

Rights。

Ticketing。

Commerce。

Data。

Security。

AI。

が接続される。

つまり、

Platform = Shared Infrastructure

であり、

App = One Interface

である。

見えないPlatform

この構造では、最も重要な企業Platformはファンから直接見えない可能性がある。

共通クラウド。

Identity基盤。

Rights Graph。

Knowledge Graph。

AI Runtime。

Global API。

これらは裏側で動く。

一方、ファンに見えるのはアーティスト固有の世界である。

したがって、

**Invisible Corporate Platform

* Visible Artist Experience**

という二層Architectureが成立する。

これがUMJに適する理由

UMJには多数のアーティストがいる。

全員を一つのブランド、同じアプリ、同じCommunityへ入れる必要はない。

それを行えばArtist Identityの違いを消してしまう可能性がある。

一方、すべてを個別システムにすると企業Scaleの利点を失う。

だから、

共通化するのはInfrastructure。
固有化するのはExperience。

という分離が重要になる。

Shared Core

企業側で共有できるものには、

Identity。

Security。

Rights。

Cloud。

Payment。

Data Governance。

AI Runtime。

Translation。

Observability。

などがある。

これらはArtistごとにゼロから作る必要がない。

Artist-specific Layer

一方、

Community Distance。

Visual Identity。

Content Structure。

Live Architecture。

Commerce。

AIの利用範囲。

はアーティストごとに異なる。

つまり、

**Shared Core

* Artist-specific Layer**

である。

Project-MGAは、Organization側にこの構造が現れた事例でもある。

Platformを全アーティストへ押しつけない

企業に共通基盤が完成すると、

全アーティストへ導入したくなる。

しかし、

Platform Capability ≠ Mandatory Platformization

である。

ファン規模。

Artist Intent。

活動領域。

必要な機能。

によって利用する範囲を変える。

Webサイトだけで十分な場合もある。

Membershipだけ必要な場合もある。

巨大Ecosystemまで成長する場合もある。

Platform Readiness

そこで、アーティストごとにPlatform化の準備状態を見ることができる。

作品がある。

長期Communityがある。

複数事業がある。

デジタル接点が増えている。

外部参加者がいる。

運営Complexityが増している。

このRequirementが一定水準へ達したときPlatform基盤を拡張する。

つまり、

Platform by Requirement

である。

Technology Pushではない。

アーティストが「Platform企業」になる必要はない

アーティスト本人がCEOのようにPlatformを経営する必要もない。

重要なのはArtist Originであり、Artist Operationではない。

運営は企業や専門チームが担える。

つまり、

Artist-originated
≠ Artist-operated everything

である。

この区別によってArtist Sustainabilityを守れる。

Artist-centered, not Artist-overloaded

Platformが大きくなるほど、

本人がすべて発信する。

本人がすべて承認する。

本人がすべて企画する。

という状態は持続しない。

したがって、

Artist-centered
but not Artist-overloaded

である必要がある。

Creative Directionと重要なIdentity判断は本人へ残す。

Routine Operationは組織へ移す。

Artist Approval Architecture

ここで企業システム側にもApproval Layerが必要になる。

たとえば、

商品発送。

FAQ。

通常のデータ処理。

は企業側で運営する。

一方、

新しい作品利用。

本人のSynthetic Voice。

ブランドの重要な表現。

には本人または権限者のApprovalが必要になる。

つまり、

Autonomy by Permission Architecture

である。

AI時代にはこの境界がさらに重要になる

生成AIを使えば、

アーティストの声。

映像。

文章。

キャラクター。

を大量に生成できる。

Platformが大きいほど、それを新サービスへ使いたくなる。

しかし、

Technical Capability ≠ Artist Consent

である。

Artist発Platformだからこそ、Artist IdentityをPlatformによって侵食しないGovernanceが必要になる。

AIはアーティストを大量生産するために使わない

AIによって本人不在でもコンテンツを作り続ける。

それは短期的にはPlatform Activityを維持できるかもしれない。

しかしArtist-centered構造と矛盾する。

より適切なのは、

アーカイブ検索。

多言語化。

権利処理。

運営支援。

需要予測。

などへAIを使い、

AI extends infrastructure, not identity without permission.

という原則を置くことである。

PlatformとCreator Network

一方、Artist発Platformは本人だけを中心に閉じる必要もない。

作詞家。

作曲家。

映像Creator。

Stage Designer。

他アーティスト。

Platformが広がればCreator Networkが見える。

ここでは、

Artist Ecosystem → Creator Ecosystem

へ拡張する。

CreditとRightsがさらに重要になる。

誰が何をつくったのかを消さない

AI時代には作品制作が複雑になる。

人間。

AI。

既存素材。

共同制作。

だからPlatform側に、

Provenance

が必要になる。

誰が関与したのか。

何を利用したのか。

誰が許諾したのか。

を保持する。

Artist-centeredとは、一人だけを可視化して他のCreatorを消すことではない。

PlatformとCommunityを循環させる

PlatformはCommunityのRequirementから変わる。

CommunityはPlatformの機能によって行動を変える。

したがって、

Community ↔ Platform

である。

しかしPlatformがCommunityへ最適行動を押しつけない。

ランキングを追加すれば競争が生まれる。

投稿機能を変えれば文化も変わる。

Technology DesignはCommunity Designでもある。

Engagement Maximizationを目的にしない

一般Platformでは、

滞在時間。

投稿数。

通知反応。

を高めたくなる。

しかしArtist Platformでは、

Maximum Engagement

が必ずしも最適ではない。

音楽を聴いてアプリを閉じる。

ライブへ行って数週間利用しない。

それでも良い関係は成立する。

したがって、

Relationship Quality > Interface Addiction

という優先順位が必要になる。

Platformは日常を奪わない

一人のファンは、複数アーティストを好きになる。

仕事もある。

家族もある。

生活がある。

一つのArtist Platformが人間の時間を最大限囲い込もうとすれば、その生活と競争する。

だから、

Platform serves life. Life does not serve the platform.

という原則を置ける。

複数のArtist Platformは競合するのか

UMJ内部だけでも、複数アーティストが固有Platformを持つ可能性がある。

しかし同じファンが複数に参加することもある。

ここで各Platformを完全に孤立させると、

Account。

決済。

設定。

が重複する。

企業Backendでは共通化できる。

一方、ファンの表面体験は別にする。

つまり、

One Corporate Infrastructure
→ Multiple Artist Realizations

である。

One Fan Identityの可能性

共通InfrastructureではOne Fan Identityを採用できる可能性がある。

ただし、

「UMJの全Artist行動を一人のProfileへ統合する」

ことを意味しない。

Identityは認証のために共有する。

データ利用はArtist / ServiceごとにPermissionを分ける。

つまり、

Shared Identity, Segmented Consent

である。

一つのArtistを好きだから別Artistへ広告しない

企業から見ればCross-sellingしたくなる。

しかしArtist-specificな関係を、本人が望まない企業横断広告に利用すればTrustを損なう。

だから、

「関連アーティストを見たい」

と本人が選んだときだけDiscoveryを広げる。

このような、

Consent-based Cross-discovery

が考えられる。

CEREMONYなら自然なCross-discoveryが起こる

企業の広告より自然なのが文化的Contextである。

CEREMONYへ行く。

別アーティストを聴く。

自分で興味を持つ。

つまり、

Context-driven Discovery

である。

Artist発Platformでは、AlgorithmだけでなくEvent CurationがDiscovery機能を持つ。

Platformが市場をつくる

ここまで来ると、Artist Platformは既存需要を処理するだけではない。

新しい出会い。

新しいCreator。

新しいイベント。

を生む。

つまり、

Platform → New Market Formation

が起こり得る。

しかし、その市場も作品と関係を基盤にする。

広告在庫を増やすためのPlatformとは異なる。

アーティスト発Platformとブランド企業

企業Brandを基盤にしたPlatformでは、

Corporate Identity

が中心になる。

Artist発Platformでは、

Artist Identity

が中心になる。

ここには利点とリスクの両方がある。

利点は、強い文化的意味と既存Communityを持つことである。

リスクは、一人のArtist Identityへ依存しすぎることである。

Artist Dependency Risk

本人の活動休止。

方向転換。

長期休養。

Platformはどうするのか。

したがって、

Artist-centered ≠ Operationally fragile

でなければならない。

アーカイブ。

Support。

既存契約。

Rights。

は本人が休んでも維持できる。

一方、新しいCreative OutputをSyntheticに補充しない。

この境界が重要になる。

Platformにも休止Modeがあってよい

Artistが休止したら、

更新頻度を下げる。

Archive Modeへ移る。

通知を止める。

必要なSupportだけ維持する。

Platformそのものも常に成長しなくてよい。

つまり、

Active Mode
Maintenance Mode
Archive Mode

のような複数運用状態を持つ。

これは長期Artist Careerと整合する。

企業PlatformにもTime Architectureが必要になる

ArtistにはPhaseがある。

Fanにも生活のPhaseがある。

Platformも同じである。

Launch。

Growth。

Maturity。

Pause。

Reactivation。

したがって、

Platform(t)

として考える。

固定したサービスとして永遠に成長させない。

アーティスト発Platformと日本市場

このモデルは日本音楽市場と特に相性が良い可能性がある。

日本には、

長期ファンクラブ。

ライブ文化。

フィジカル商品。

アニメ・映像IPとの連携。

バンド文化。

推し活。

長期Catalog。

複数のRelationship Infrastructureが既に存在する。

したがって日本では、ゼロからPlatformをつくるというより、

既に存在する関係をデジタル・企業基盤によって接続する

方向が有力になる。

日本の複雑性は弱点だけではない

事業が分散している。

サービスが多い。

市場構造が複雑。

これは効率面では課題になる。

しかし、その中には多様なArtist-Fan Relationが存在する。

標準化ですべて消すのではなく、

共通Infrastructureで接続し、表現の多様性を保持する

なら強みに変えられる。

Japan-born Platform Architecture

Mrs. GREEN APPLEから抽出できるのは、

MGA Appそのものを世界へ売ることではない。

CEREMONYを全地域へそのまま輸出することでもない。

より一般化すると、

Artist-originated, community-informed, enterprise-enabled platform architecture

という原理である。

これなら別のArtist、別の国へ翻訳できる。

UMJ → UMG

ここにUMJのグループ内役割が生まれる。

日本でArtist発Platformの実装と検証を行う。

どの部分が一般化できるかを見る。

UMGへKnowledgeを返す。

世界各地域で別のArtistへ適用する。

つまり、

UMJ Innovation
→ UMG Knowledge
→ Local Realization

である。

世界からUMJへ戻る

同時に、他国にも異なるFan PlatformやD2C、Live、Digital Communityの知識がある。

それを日本へ持ち帰る。

つまり、

World Knowledge
→ UMJ Translation
→ Japan Realization

である。

ここでも一方向ではない。

Japan ↔ Worldの循環

したがってArtist発PlatformのGlobal Architectureは、

Japan
↔ World

になる。

日本で生まれたArtist-specificな仕組みを世界へ。

世界で得られたKnowledgeを日本へ。

その結果を次のPlatformへ戻す。

これがContinuous Corporate Learningになる。

世界へ進むほどArtist Identityを守る

Global Platform化するとScaleが大きくなる。

多言語。

多通貨。

複数法制度。

海外商品。

世界公演。

しかしInfrastructureを世界標準へしても、Artist Experienceまで均質化しない。

つまり、

**Global Standardized Infrastructure

* Local / Artist-specific Representation**

である。

これがGlobalizationとIdentity Preservationを両立する。

AIはPlatformのOperating Layerになる

規模が拡大すれば、AIは一機能ではなくOperating Layerへ近づく。

検索。

翻訳。

権利。

需要予測。

Community分析。

問い合わせ。

海外市場分析。

複数Agentが動く。

しかしAIはPlatform Ownerではない。

判断権限は人間と組織に残す。

AI Agentにも最小権限を与える

Commerce AgentにはCommerceに必要な権限。

Rights AgentにはRights。

Translation Agentには公開情報。

一つのAIに全アクセス権を持たせない。

つまり、

Least Privilege for AI Agents

である。

これはSecurity上だけでなくArtist / Fan Privacyのためにも重要になる。

FactとHypothesisを分離する

AIがPlatform全体を分析すると、

「このArtistは次に海外で伸びる」

「このファンは購入する」

と予測できる。

しかし予測をFactとして扱わない。

企業基盤では、

Fact
Observation
Hypothesis
Prediction
Decision

を別レイヤーで保持する。

これは本書の分析法そのものを情報システムへ翻訳した形になる。

Next Algorithmは検証から生まれる

一つの施策を実装する。

結果を見る。

学習する。

そして次のAlgorithmを更新する。

つまり、

Fact
→ Observation
→ Hypothesis
→ Verification
→ Implementation
→ New Fact
→ Next Algorithm

である。

Artist発Platformそのものが、このLoopを実行する企業学習装置になり得る。

Platformは完成品ではない

ここで第7章の最後の境界を置く。

Platformは完成しない。

Artistが変わる。

Communityが変わる。

Technologyが変わる。

市場が変わる。

世界が変わる。

したがって、

Platform = Continuous Architecture

である。

一度完成して保守するだけのシステムではない。

関係の変化に応じて更新する。

ただし更新し続けることを目的にもしない

Continuousであるからといって毎月機能を追加する必要はない。

むしろ不要機能を消すことも更新である。

Platformを軽くする。

通知を減らす。

古い機能を終了する。

つまり、

Evolution includes subtraction.

これも長期Platformに必要な能力である。

Platformの「0」

一人のファンがアプリを使わなくなる。

Communityから離れる。

購買もしない。

Platformとの接続が一時的に0になる。

しかし作品へのAccessは残る。

再び戻れる。

したがって、

0 ≠ Termination

である。

0 = Open Return State

として扱える。

この設計ならPlatformは人間を閉じ込めない。

アーティスト発プラットフォームの最小原則

ここまでの分析を、七つの原則へ圧縮できる。

1. Artist-originated

最初にArtistとWorkがある。

2. Community-informed

Requirementは実際の関係から導く。

3. Infrastructure-enabled

企業とTechnologyが持続可能性を支える。

4. Third-party-open

必要な場合には他者が参加できる。

5. Identity-preserving

参加者の違いを消さない。

6. Human-controlled

AI、データ、Commerceが人間の自律性を奪わない。

7. Continuously learnable

実装結果から企業とPlatformが学習する。

この七つが揃うと、Artist Platformは単なるFan Appを越える。

Mrs. GREEN APPLEから一般化できること

Mrs. GREEN APPLEから学ぶべきなのは、

巨大ライブを開くことでもない。

アプリを作ることでもない。

CEREMONYを真似ることでもない。

最も重要なのは、

Artist Activityが企業の既存境界を越えたとき、Artistを元の境界へ押し戻すのではなく、企業側のArchitectureを変更できること

である。

Project-MGAはOrganizationを変えた。

CEREMONYは他者へ場を開いた。

その結果、Platform Capabilityが生まれ始めた。

形ではなくOperationを学ぶ

したがってUMJが一般化すべきなのは、

MGAという形

ではない。

その背後のOperationである。

観測する。

Artist固有のRequirementを理解する。

既存組織とのGapを見る。

必要なら組織を変える。

Technologyを接続する。

実装する。

検証する。

学習する。

つまり、

Observe
→ Understand
→ Adapt
→ Implement
→ Learn

である。

これは第2冊の次世代アルゴリズムへ直接つながる。

第7章の結論

第7章では、CommunityからPlatformへの移行を追った。

しかし最後に見えてきたのは、

CommunityがそのままPlatformになる

という単純な構造ではなかった。

一人のSelfが作品へ反応する。

複数のSelfがCommunityを形成する。

関係を持続するためMembershipやDigital Interfaceが必要になる。

Activityが大きくなるとOrganizationが変わる。

他者が参加し始める。

継続的なContextとInfrastructureが形成される。

ここでPlatform Capabilityが生まれる。

したがって、

Artist
→ Work
→ Self
↔ Community
→ Requirement
→ Organization
↔ Platform
↔ Ecosystem

という方が正確である。

そしてすべては固定されていない。

相互に戻る。

企業はPlatformの所有者から学習主体へ

最後に企業側を見る。

Platformを所有する。

データを持つ。

ファンを囲い込む。

それだけが次世代企業の競争力ではない。

より重要なのは、

アーティストから学ぶ。

ファンから必要な範囲で学ぶ。

CommunityからWeak Signalを読む。

世界各法人から学ぶ。

その学習によって企業Architectureそのものを更新することである。

つまり、

Platform Company

の先に、

Learning Music Company

がある。

第Ⅲ部から第Ⅳ部へ

第Ⅲ部では、ファンと市場を見てきた。

消費者からListenerへ。

ListenerからSelfへ。

SelfからCommunityへ。

CommunityからPlatformへ。

そしてArtist発PlatformからEcosystemへ。

ここまで来ると、次の問いが生まれる。

この構造は、日本という市場の中でなぜ成立したのか。

世界有数のフィジカル市場。

急速に伸びたストリーミング。

J-POP。

洋楽。

K-POP。

アニメ。

ライブ文化。

長期Catalog。

複数の文化と経済が同時に存在する日本市場は、世界の他市場と何が違うのか。

そして、その日本で形成されたArtist、Community、Platformの知識を、どのように世界へ届けるのか。

次の第Ⅳ部では観測点を企業内部から外へ広げる。

日本と世界。

まず第8章では、世界有数の規模を持ちながら独自の構造を残している日本の音楽市場そのものを読み解いていく。