作業用 BGM を流すユーティリティの企画を練っていたとき、音楽ソースをどこから持ってくるかで手が止まりました。ストリーミングサービスの SDK は魅力的ですが、外部依存の審査リスクと保守の重さが個人開発には見合わない。そう考えて Apple 純正の MusicKit を選びました。
結論から言うと、MusicKit は「サーバーを1台も持たずに音楽カタログへアクセスできる」という点で、個人開発との相性が飛び抜けて良い API です。開発者トークンの発行・更新すらフレームワークが自動で処理してくれます。
Rork Max はネイティブ Swift を出力するため、React Native では回り道が必要だったこの領域に直接踏み込めます。認可から再生までの最小構成を、実装の順番どおりに追っていきます。
事前設定 — コードを書く前に2箇所
MusicKit はコードより先に、プロジェクト外の設定でつまずきやすい API です。必要なのは次の2つです。
App ID の App Services で MusicKit を有効化する 。Apple Developer サイトの Identifiers から対象 App ID を開き、App Services タブで MusicKit にチェックを入れます。ここが開発者トークン自動発行の根拠になります。Info.plist に NSAppleMusicUsageDescription を追加する 。ユーザーのライブラリへアクセスする理由を書きます。これが無いと認可ダイアログの表示時にクラッシュします。
かつての MusicKit（Apple Music API 直叩き）では JWT の開発者トークンを自前のサーバーで署名・更新する必要がありました。現在の Swift 版 MusicKit はこの設定さえ済んでいれば、トークンの発行・キャッシュ・更新をすべて自動処理します。サーバーレスで完結する理由がここにあります。
認可 — MusicAuthorization.request()
最初のコードは認可リクエストです。async 一発で書けます。
import MusicKit
@MainActor final class MusicAccessModel : ObservableObject { @Published var status: MusicAuthorization.Status = .notDetermined
func requestAccess () async { // 初回はダイアログが出る。2回目以降は保存済みの判定が即座に返る status = await MusicAuthorization. request () } } status は .authorized .denied .restricted .notDetermined の4値です。.denied の後にアプリ内から再度ダイアログを出すことはできないため、設定アプリへの導線（UIApplication.openSettingsURLString）を用意しておきます。
認可を求めるタイミングは、起動直後のオンボーディングではなく音楽機能に最初に触れた瞬間 に寄せることを推奨します。BGM 機能がアプリの主目的でない限り、起動直後の権限ダイアログは離脱要因にしかなりません。
カタログ検索 — MusicCatalogSearchRequest
Apple Music の全カタログを検索します。構造体を組み立てて response() を呼ぶだけです。
func searchSongs ( matching term: String ) async throws -> MusicItemCollection<Song> { var request = MusicCatalogSearchRequest ( term : term, types : [Song. self ]) request.limit = 10 let response = try await request. response () return response.songs } types に Album.self や Playlist.self を足せば横断検索になります。返ってくる Song には曲名・アーティスト・アートワーク URL・プレビュー用の previewAssets まで揃っているので、検索結果の一覧 UI はこのメタデータだけで組めます。
アートワークは song.artwork?.url(width:height:) でサイズ指定付きの URL が取れます。一覧のサムネイルに原寸を読み込まないよう、表示サイズに合わせた幅を渡してください。スクロール時のメモリ使用量が体感で変わります。
再生 — ApplicationMusicPlayer と SystemMusicPlayer の分岐点
再生プレイヤーは2種類あり、ここがユーザー体験の分岐点になります。
func play ( _ song: Song) async throws { // アプリ内で完結させたいので ApplicationMusicPlayer を使う let player = ApplicationMusicPlayer.shared player.queue = [song] try await player. play () } 作業用 BGM のような「アプリの中の体験」なら ApplicationMusicPlayer、検索して見つけた曲をユーザーの音楽環境へ送り出すなら SystemMusicPlayer です。私の場合、最初のプロトタイプで SystemMusicPlayer を選んでしまい、「アプリを閉じても音楽が続くのが不気味だ」というテスターの声で作り直したことがあります。用途に対する直感と実挙動がずれやすいので、この表の1行目だけでも覚えておいてください。
未加入ユーザー — MusicSubscription で分岐する
Apple Music に加入していないユーザーはカタログのフル再生ができません。加入状態は MusicSubscription.current で取れます。
func canPlayFullSongs () async throws -> Bool { let subscription = try await MusicSubscription.current return subscription.canPlayCatalogContent } 未加入ユーザーには2つの選択肢を用意できます。
プレビュー再生 。previewAssets の URL を AVPlayer で流せば、30秒程度の試聴は加入なしで提供できます。検索と試聴だけでも機能として成立します。
加入オファーの表示 。SwiftUI の musicSubscriptionOffer(isPresented:options:) モディファイアで、Apple 標準の加入シートをアプリ内から出せます。加入が成立すればそのままフル再生に移行できます。
未加入だから機能を丸ごと隠す、という設計だけは避けてください。検索・試聴・オファーの三段構えにしておくと、どの状態のユーザーにも見せられる画面が残ります。
Rork Max への指示で欠落しやすいもの
Rork Max に「Apple Music 検索付きの BGM アプリを作って」とだけ指示すると、コードは正しいのに動かない状態になりがちです。原因はコード外の設定にあります。プロンプトに次の2文を足しておくと確実です。
「Info.plist に NSAppleMusicUsageDescription を追加して」
「MusicAuthorization.request() を音楽画面の初回表示時に呼ぶ構成にして」
「未加入ユーザー向けに previewAssets の試聴再生と musicSubscriptionOffer の導線を用意して」
App ID 側の MusicKit 有効化だけは Apple Developer サイトでの手作業になるため、生成コードがどれだけ正しくても省略できません。実機で認可ダイアログが出ない・検索が 401 相当のエラーで落ちる場合の対処は、まずこの App ID 設定の確認からです。
もうひとつ、シミュレータでは Apple Music の再生ができません 。検索とメタデータ取得までは動くため、途中まで動いて再生だけ沈黙する、という紛らわしい状態になります。再生確認は最初から実機で行うと、原因調査の遠回りを避けられます。
審査と運用の小さな注意
MusicKit を使うアプリの審査では、音楽再生が主機能の場合に「Apple Music 未加入でもアプリが成立するか」を見られる傾向があります。試聴とオファー表示を実装しておくことは、体験のためだけでなく審査対策としても効きます。
運用面では、MusicSubscription.current の結果をキャッシュして長期間使い回さないこと。加入状態は変わります。画面表示のたびに取り直しても十分軽い API です。
サーバー無しでここまで組めるメディア連携は、個人開発の規模だと他に選択肢がほとんどありません。まずは認可と検索の2ステップだけ通して、カタログが手元に届く感覚を確かめてみてください。