ゲーム音楽配信の設計と最適化──Nintendo Music における開発チームの取り組み
2024年10月に配信をスタートしたスマートフォン向けゲーム音楽配信サービス「Nintendo Music」。ニンテンドーシステムズは、Nintendo Musicの開発プロジェクトにおいて、インフラやメディア配信など、バックエンドの領域を中心に担当しました。お客様に快適な体験をお届けするために開発チームが採用した技術、工夫したこと、苦労したことなどを紹介します。
Nintendo Musicとは
Nintendo Music は、任天堂が提供するゲーム音楽配信アプリです。ファミリーコンピュータから Nintendo Switch 2 まで、さまざまなゲーム音楽を配信しています。詳細については「任天堂公式サイト」をご覧ください。
Nintendo Musicの開発体制
Nintendo Musicは、フロントエンドとバックエンドの2つに分かれて開発しています。お客様が直接触れる部分、つまりAndroid/iOSアプリの開発や、コンテンツ制作などのフロントエンドは任天堂が主体として開発しています。ニンテンドーシステムズは、API（Application Programming Interface）の提供、メディア配信、ワークフロー構築などのバックエンドに加え、アプリとメディア処理をつなぐSDK（Software Development Kit）の提供も担当しています。
開発は PoC（Proof of Concept）や技術選定から始まり、フロントエンド側の本開発にあわせてバックエンド開発も本格化しました。バックエンド開発の体制は、API周りをメインで開発する「サービスドメイン」、楽曲処理を全般的に担当する「ストリーミングドメイン」、CMS（Contents Management System）の開発を通してスムーズな楽曲公開を支援する「CMSドメイン」、お客様に対してレコメンドする楽曲を提案する「レコメンドドメイン」の4ドメイン（チーム）に分かれ、それぞれが連携しながら開発しています。また、開発メンバーの多くは複数ドメインを兼務しています。
開発は京都と東京の2拠点体制を敷いています。その理由は、ニンテンドーシステムズが京都が本社の任天堂株式会社と東京が本社の株式会社ディー・エヌ・エー（DeNA）の合弁で生まれた会社だからです。京都と東京で距離が離れていることもありますが、出張を含む対面コミュニケーションと、リモートワークの両方をうまく活用しながら開発を進めています。また、フロントエンドの任天堂側ともコミュニケーションを取り、認識がずれないように整合性を取りながら進めました。
開発時はチーム全体でドキュメントをしっかり残すことを意識しました。元々、ニンテンドーシステムズ全体にドキュメントを残す文化があり、合意を取ってから前に進めるカルチャーが浸透しています。チーム内での打ち合わせにおいても、任天堂との会議においても、必ずドキュメント化し、レビューをし、確定といった流れを踏んでいます。合意を取ってから前に進むため、メンバー全員の認識がぶれることがありません。
採用した技術スタック
バックエンドの開発では、極力一般的な技術スタックを採用し、複数のサービスを組み合わせながら属人化しない開発・運用を心がけていました。
インフラ基盤
グローバルで常に安定したサービスを提供するためには、どの時間帯においても、平時だけでなく突発的なアクセスにも対応することが求められます。また、快適な音楽体験を届けるためには、高速で安定したレスポンスも求められます。
そこでバックエンドの開発ではクラウドサービスを採用し、サーバーレスやマネージドサービスを中心に構成しています。インフラの実行基盤にはコンテナ、データ蓄積層には高速DBや高速ストレージを採用し、高速レスポンスとスケーラビリティを確保。メディア配信の基盤は、配信用のメディア作成やメディア配信でもフルマネージドでサーバーレスなサービスを積極的に採用しています。
開発言語その他
開発言語は、高速なスケールアウトと安定性を考慮してGoを採用しました。その他、サーバーサイドの開発では過剰な複雑性を避け、ベストプラクティスに則ることで、属人化しない開発・運用を心がけています。
メディア配信と再生技術
モバイルアプリ開発では Unity 等を用いて Android / iOS 共通のコードベースを構築するのが一般的ですが、本サービスでは OS ごとにネイティブ実装を行う方針を採りました。
これは、高度な権利保護と「Nintendo Music」特有の再生機能を実現するためには、各プラットフォームに最適化された技術選定が不可欠だったためです。まず IP（知的財産）保護の観点では、Android は Widevine、iOS は FairPlay Streaming を採用し、各 OS 標準の暗号化・復号パイプラインに適合させることでセキュアな配信を実現しました。
また、独自の「ながさチェンジ」機能（15分・30分などいくつかの設定から任意の長さでシームレスなループ再生を実施）の実現には、OS ごとの再生エンジンの挙動やシーク精度への深い介入が必要です。そのため、配信フォーマットも Android は MPEG-DASH、iOS は HLS (HTTP Live Streaming) と使い分け、それぞれの再生要件に合わせて最適化しています。
ゲーム音楽探索体験を支える技術、お客様の体験を高めるための工夫
CDNによるキャッシュ
CDN（Contents Delivery Network）は、バックエンド API のキャッシュに加えて、再生中の曲に関連したゲームの画面写真を配信する機能としても活用しています。Nintendo Musicでは、再生中の曲に関連したゲームの画面写真が、音楽とともに映し出されます。ところが、当初、CDNのリサイズ機能を利用して、画面写真を端末に適したサイズに自動変換して配信する機能を導入したところ、自然な色味が出ないケースがありました。これはリサイズの仕組みとして、はじめは変換の速さ重視で生成した画像を返却し、後ほど精度重視で生成した画像に差し替わっていくとなるところが、前者の変換の速さ重視で生成した画像のほうが意図せずキャッシュされてしまったことが原因でした。そこで、リサイズの仕組みを考慮したキャッシュ構成にすることで改善を行いました。
リリース前には、公開を予定しているすべてのゲームの画面写真をキャッシュ側に保存するプリロード（Preloading）を実施しました。CDNは基本的に誰かが1回アクセスすればオリジンサーバーからダウンロードされてキャッシュ側に画像が溜まり、次の人からは快適にWebアクセスができるようになります。しかし、リリース当初はすべての画像がキャッシュされているわけではありません。初期リリースする数十タイトルについては、想定される全パターンのリクエストを繰り返し実施することでCDNに画像をキャッシュしていました。
さまざまな管理システムとの連携
お客様がスムーズにサービスを開始できるような工夫もしています。Nintendo Musicは、Nintendo Switch Onlineの加入者を対象としたサービスです。そのため、バックエンドでは最初にNintendo Switch Onlineのアカウント情報を取得し、そこからNintendo Musicのサービスに入っていくことになります。そのためには、任天堂のさまざまな管理システムとの通信が必要で、その中の一つでも通信が途切れるとサービスが利用できなくなります。加えて、さまざまな管理システムに通信するということは、時間を要します。並列でスムーズに処理していかないと、お客様がサービスを開始するまでの目標時間を満たすことができません。そこで、負荷試験の際には Google Cloud の Cloud Trace を活用してレスポンスのボトルネックを確認し、内部ロジックの実行順の調整や可能な範囲で非同期化を実施したり、オンメモリキャッシュのキャッシュ時間の調整や、インスタンス自体のスペックや concurrency を調整することで、レスポンス時間の短縮とインスタンススペックの最適化を目指しました。
ゲーム音楽再生体験を支える技術、音に対するこだわり
Nintendo Musicでは、ゲーム音楽をスマートフォンアプリで配信するという、任天堂にとっての新たなチャレンジに取り組んでいます。そこで、音質についてはリリース直前までこだわり、さまざまな試行錯誤を重ねました。
iOSでのノイズ発生と原因追究
あらゆるアプリに共通することですが、開発や検証は安定したネットワーク環境で実施した後、リリースする前にはさまざまな環境でテストを行います。Nintendo Musicでもリリースの2～3か月前から環境を変えてテストを実施しました。その際、iOSに関しては楽曲の再生途中で「プチ」または「チリッ」といったノイズが発生することが確認されました。しかし、原因が特定できず、どのタイミングでノイズが出てくるのか、どういった状況で発生するのかも把握できませんでした。
リリースの2～3か月前といえば開発全体が佳境を迎えている時期であり、新たにノイズの解消に対応するほどの開発チームに余力が残されているわけではありません。しかし、屋外のフィールドテストでも「ノイズが気になる」という声が上がってきました。特に、ゲームの楽曲を詳しく知っている人ほど「ここに、この音は入るはずがない！」と気が付くはずです。お客様の体験を損なわないためにも、見過ごすことはできませんでした。
原因を突き止めるため、まず「最もノイズが聞き取りやすい環境」を作ることから始めました。具体的には、機械的な「正弦波（ピー音）」が鳴り続けるテスト音源を作成し、さまざまなネットワーク環境でひたすら再生テストを繰り返しました。
その結果、ネットワークが不安定になり、音質が切り替わる瞬間にノイズが発生していることが分かりました。 これは「ABR (Adaptive Bitrate Streaming)」という、回線状況に合わせて最適な音質を自動選択する機能によるものです。本来は再生を止めないための便利な機能ですが、電車移動や混雑した回線（特定のSIMのお昼休みなど）では、高音質と低音質が切り替わってしまい、その際にノイズが発生していました。
iOS のライブラリの仕様上、この ABR 機能自体をオフにすることはできません。そこで、再生するためのプレイリストファイル自体を音質ごとに作成することで楽曲再生中は「最初に選んだ音質から切り替えない」ように制御することでノイズを解消することができました。
現在は、Wi-Fi なら高音質、モバイル回線なら中音質で固定再生される設定をデフォルトとしています。
また、各音質のビットレートも任天堂のサウンド担当者と緊密に連携を図りながら、どの程度であればゲーム内の再生品質と同等の音響体験を維持できるのか、何曲ダウンロードすればどれだけ通信費用に影響があるのかなどを考慮して詳細に調整を重ねました。
屋外環境での聞きやすさの検証
開発の前半は屋内のWi-Fi環境でテストを繰り返してきたため、後半では実利用も想定して屋内・屋外を含めてさまざまな環境でモバイルデータ通信によるテストを重ねました。電車内や駅構内はもちろんのこと、車載環境でのテストも実施しました。日本より車社会となっているアメリカでは、車載環境での体験が重要と考え、任天堂の現地法人の協力を得てアメリカでテストを実施しました。日本でも滋賀にある国内でもトップクラスの長いトンネルで車載テストを実施するなど、さまざまな環境で確認を行いました。
モバイルデータ通信の課題となったのが、複数のSIMを使ったテストです。さまざまな場所でテストデータを集めた中、駅近辺でネットワークが混雑する昼の時間に実施したテストにおいて、SIMの違いで大きな差が現れました。ある通信会社のSIMの場合、京都では再生が安定しなかったのに対し、東京ではクリアに聞こえるという事象です。そこで、そのSIMをベンチマークとして楽曲のバッファリング時間を検証し、それをもとに調整を進めていきました。
屋内環境でテストしていた当初はバッファリング時間を数秒程度に留めて、再生開始までの時間を短縮していました。ところがあるSIMの環境では長めにバッファリング時間を確保しておかないと、楽曲の再生途中に止まってしまうという事象が発生しました。そこで、バッファリング時間に余裕を持たせるようにしました。ストリーミングの場合、セグメントの間隔が大きく影響するため、複数のパターンを試しながらバッファリング時間を決めました。最初にテスト用の曲をいくつか用意し、複数パターンを作って検証することで調整期間を短縮しています。
楽曲冒頭が再生されない問題の対策
開発の最終段階で、楽曲の一部で冒頭部分の0.01秒程度が再生できない状況が発覚しました。リリース直前であり、絶体絶命ともいえるピンチです。もちろん、テストでは何曲も聴いていたものの、配信する楽曲は大量にあるため、リリース前のテストでは一部の楽曲に留めていました。リリース直前で全曲テストを実施したところ、これまでに見つからなかった問題が顕在化しました。
解決策として、すべての楽曲の冒頭にわずかな無音を追加することでクリアしました。楽曲生成のパイプラインをすべて自前で構築していたことが大きな利点となり、スムーズに対応することができました。開発チームのメンバーがゼロから学びながら仕組みを作ってきたことも活き、楽曲冒頭に無音を加えるアイデアも検討の中で自然と辿り着きました。
テストとリリース
音に対する課題をクリアした後、最後の仕上げは最終テストとリリースです。
複数OS、複数端末でのテスト
スマートフォン向けサービスの開発では定番ですが、最後に複数OSでの対応テストや複数端末でのテストを実施しました。Androidの場合、バージョン9から最新の16(2025/10 時点)までのOSでテストしています。端末の種類についても、検証可能な範囲ではありますが様々な端末でテストしています。バラエティー豊富なAndroidは、標準ルールから逸脱した端末が存在します。こういった端末は注意深くケアし、ベンチマークとして利用しています。iOSに関しても、Androidほど注意する必要はないものの、楽曲の再生に関してはOSと密接に関連してくる部分でもあるため、早めにベータ版を使ってテストを実施しています。
テストの自動化
開発を効率化するためにテストを自動化したことも工夫の一つです。一部のAndroid端末では、楽曲の再生、停止、早送り、早戻しといった基本的な機能のテストはすべて自動化しています。iOSに関しても同様のことができるようにしていく予定です。今回の開発で苦労したノイズについても、自動的に検出することにも実用化に向けてチャレンジしていきます。
その他のテスト
その他のテストとして、サーバー側のリリースでも必ず変更後にはリグレッションテスト（回帰テスト）を実施しました。サーバー側のAPIを更新したり、セキュリティーアップデートを実施したりした際は、本番リリースの前に全機能が各種OSで問題なく動作するかを開発環境ですべてテストして品質を担保しています。
「Available now」によるリリース
本番のリリースでは、事前の予告やニュースリリースなしで「本日公開です」と告知して全世界一斉公開する「Available now」方式を採用しました。「Available now」方式は事前情報なしでリリースするため、どういったアクセスがくるか、ストアにいつ公開されるかわかりません。
そこで、バックエンドの開発チームや、任天堂側のメンバーも含めて全員が京都の本社に集まってスタンバイし、リリースを見守る体制を組みました。リモートで参加した北米と欧州のメンバーも含めて朝の7時からリアルタイムに見守り続け、無事に8時の公開を迎えることができました。
あらかじめNintendo Switch Onlineの加入者数をベースに最大アクセスを想定した負荷試験を行っていたことから、リリース直後のスパイクアクセスも乗り切ることができました。想定外の事象が発生した際も、開発担当者が一堂に集まり、24時間の見守り体制を組んでいたこともあり、クイックに対応することができました。
まとめ
ここまで、Nintendo Musicを支える技術として、お客様の体験を高めるための工夫と音に対するこだわりを中心に解説し、テストからリリースまでの流れを紹介してきました。Nintendo Musicは世に出たばかりのサービスのため、引き続き今後も改善、拡大、拡張を続けていきます。バックエンドのインフラ技術とメディア配信技術の詳細は「Google Cloud Next Tokyo 2025」のセッション動画でも解説していますので、興味がある方はこちらもご覧ください。