◇ アプリ開発/2026-07-01上級

Rork Max のネイティブ Swift で ShazamKit を使い、流れている曲を認識するアプリを作る

SHManagedSession を使って、周囲で流れている曲を認識するアプリを Rork Max のネイティブ Swift で組む実装メモです。旧来の AVAudioEngine 手回しとの違い、idle・prerecording・matching の状態設計、認識精度を上げる prerecording の使いどころ、Expo からの橋渡しの境界設計まで、実際にハマった点を添えてまとめます。

ShazamKit Rork Max¹⁹⁹ 音楽認識 iOS⁹² SwiftUI⁵⁷

✦ プレミアム記事

友人と入った喫茶店で、耳になじむのに曲名が出てこない音楽が流れていて、二人でしばらく唸っていたことがありました。スマートフォンをかざせば一発で分かるあの体験を、自分の小さなアプリの一機能として持てたら面白いのに、とそのとき思いました。個人開発でユーティリティ系のアプリをいくつか作ってきましたが、「かざすと分かる」という手触りには、理屈抜きの気持ちよさがあります。

その入口になるのが ShazamKit です。Apple の音楽認識をアプリに組み込める仕組みで、周囲の音や自分のアプリの再生音から、曲を照合できます。かつては録音の面倒を自分で見る必要がありましたが、iOS 17 以降の SHManagedSession を使えば、その大半を任せられます。Rork Max がネイティブ Swift を生成するようになったことで、この API を個人開発でも素直に組み込めるようになりました。実際に「かざすと分かる」小さなアプリを作ってみて分かったことを、順を追ってまとめます。

手回しの旧来型か、任せる SHManagedSession か

ShazamKit には、大きく二つの組み方があります。ここを最初に選んでおくと、後の設計が決まります。

観点	SHSession（手回し）	SHManagedSession（iOS 17+）
録音の管理	AVAudioEngine を自分で組む	フレームワークに任せられる
マイク権限	自分で要求・確認する	セッションが面倒を見る
結果の受け取り	デリゲート	async の結果列（results()）
状態の可視化	自前で管理	idle / prerecording / matching を観測できる
向いている用途	再生音との突き合わせなど細かい制御	周囲の曲をかざして認識する定番用途

「周囲で流れている曲をかざして当てる」という王道の用途なら、迷わず SHManagedSession を選びます。録音とマイク権限の面倒を肩代わりしてくれるので、書く量が目に見えて減ります。私自身、最初は勉強のつもりで AVAudioEngine を手で組みましたが、権限まわりとバッファの取り回しで思いのほか時間を食い、SHManagedSession に切り替えたら本質だけが残りました。

状態を SwiftUI に映す

SHManagedSession は Observable に準拠しているので、状態の変化を SwiftUI がそのまま拾えます。状態は三つです。

idle：録音も照合もしていない、待機の状態
prerecording：照合に必要な準備が整い、先んじて録りためている状態
matching：実際に照合を試みている状態

この三状態をそのままボタンの見た目に反映すると、ユーザーに「いま何をしているか」が伝わります。以下は、状態に応じて表示を変える最小の画面です。

import SwiftUI
import ShazamKit
 
@MainActor
final class RecognizerModel: ObservableObject {
    let session = SHManagedSession()
    @Published var title: String?
    @Published var artist: String?
    @Published var isWorking = false
 
    /// かざして照合する。結果は results() の非同期列から受け取る。
    func recognize() async {
        isWorking = true
        defer { isWorking = false }
 
        // 照合を1回試み、最初の結果で打ち切る
        for await result in session.results {
            switch result {
            case .match(let match):
                if let item = match.mediaItems.first {
                    self.title = item.title
                    self.artist = item.artist
                }
                return                    // 当たったら止める
            case .noMatch:
                self.title = "一致なし"
                return
            case .error(let error, _):
                self.title = "エラー: \(error.localizedDescription)"
                return
            @unknown default:
                return
            }
        }
    }
}
 
struct RecognizeView: View {
    @StateObject private var model = RecognizerModel()
 
    var body: some View {
        VStack(spacing: 24) {
            if let title = model.title {
                Text(title).font(.title2).bold()
                if let artist = model.artist {
                    Text(artist).foregroundStyle(.secondary)
                }
            } else {
                Text(model.isWorking ? "聴いています…" : "タップして曲を認識")
                    .foregroundStyle(.secondary)
            }
 
            Button {
                Task { await model.recognize() }
            } label: {
                Image(systemName: "shazam.logo.fill")
                    .font(.system(size: 64))
            }
            .disabled(model.isWorking)
        }
        .padding()
    }
}

session.results は照合結果の非同期列を返します。当たった時点で return して抜けているのは、一曲当てられれば十分な用途だからです。連続して当て続けたいなら、抜けずに列を回し続ければ、流れる曲が変わるたびに結果が届きます。

✦

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること

✦AVAudioEngine を手回しする旧来のやり方と、SHManagedSession に任せる新しいやり方の違い、どちらを選ぶかの判断基準が分かります

✦idle・prerecording・matching の状態を SwiftUI に映し、prerecording で初動の認識精度を上げる、動く Swift コード一式が手に入ります

✦Rork Max が生成するネイティブ Swift で ShazamKit を使う手順と、Expo / React Native から橋渡しする際の境界設計が身につきます

Stripe による安全な決済 · いつでもキャンセル可能

✦

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または

メンバーシップなら全記事が読み放題 →

prerecording で初動の取りこぼしを減らす

実機で試すと、ボタンを押した「その瞬間」の数秒が認識の成否を分けることに気づきます。押してから録り始めるのでは、頭が欠けて当たりにくいのです。SHManagedSession の prerecording は、ここを埋めるための状態です。

照合を始めそうなタイミング、たとえば画面が表示された直後にあらかじめ prepare() を呼んでおくと、セッションが先回りして録りためます。ユーザーがボタンを押した頃には、すでに数秒分の音が手元にあるので、初動の取りこぼしが目に見えて減ります。

// 画面が出た時点で、先回りして録りためておく
.task {
    await model.session.prepare()   // idle → prerecording へ
}

私の場合、この一行を入れる前と後で、静かなカフェのような小音量の環境での当たり方がはっきり変わりました。ユーザーは「押したのに当たらない」を敏感に嫌がるので、初動の数秒を先取りする効果は、体感として大きいです。ただし、prepare() を呼んだ時点でマイクは動き始めるため、画面を離れたら確実にセッションを止め、待機に戻すことが必要です。ここを怠ると、裏で録り続けてしまいます。

.onDisappear {
    model.session.cancel()   // 待機に戻し、録音を止める
}

自分のカタログと突き合わせたいとき

ShazamKit は Apple の音楽カタログだけでなく、自分で用意した音源とも突き合わせられます。館内アナウンスや、自社で配信している音声コンテンツを認識させたい、といった用途です。この場合は、あらかじめ音源から署名（シグネチャ）を作ってカスタムカタログに登録し、そのカタログをセッションに渡します。

// 自前音源からカタログを作り、セッションに渡す
let catalog = SHCustomCatalog()
let signature = try SHSignatureGenerator.signature(from: myAudioFile)  // 事前生成した署名
let mediaItem = SHMediaItem(properties: [.title: "館内アナウンス A"])
try catalog.addReferenceSignature(signature, representing: [mediaItem])
 
let session = SHManagedSession(catalog: catalog)

この仕組みを使うと、「特定の音が鳴ったらアプリが反応する」という体験を、Apple のカタログに頼らず自作できます。イベント会場の音や、限定コンテンツの認識など、用途を工夫すると個人開発でも面白い企画に育てられます。

Rork Max のネイティブ生成と Expo の境界を決める

Rork Max はネイティブ Swift を生成するので、ShazamKit のような音声フレームワークにも素直に手が届きます。一方、既存アプリの多くは Rork 本体の Expo / React Native です。両者の分担を最初に決めておくのが、実装を軽くするコツです。

私の切り分けは次の通りです。

層	担わせるもの	担わせないもの
ネイティブ Swift（Rork Max 生成）	SHManagedSession の起動・照合・結果の取得	履歴の保存先・画面遷移
React Native（JS 側）	認識開始の指示・当たった曲の受け取り・保存や共有	音声の生データの往復

要点は、音声そのものを JS 側へ渡さないことです。ネイティブ側で照合を完結させ、当たった曲名・アーティスト・（あれば）Apple Music の識別子だけをイベントで返す、という一方向の流れにします。ネイティブモジュールとしては、startRecognition の一メソッドと、結果を流す onMatch イベントだけ公開すれば足ります。

// Expo Modules API での最小の公開面（イメージ）
public class ShazamModule: Module {
    let session = SHManagedSession()
 
    public func definition() -> ModuleDefinition {
        Name("Shazam")
 
        // JS からはこのメソッドと onMatch イベントだけを触らせる
        AsyncFunction("startRecognition") {
            for await result in self.session.results {
                if case .match(let match) = result, let item = match.mediaItems.first {
                    self.sendEvent("onMatch", [
                        "title": item.title ?? "",
                        "artist": item.artist ?? "",
                        "appleMusicID": item.appleMusicID ?? ""
                    ])
                    return
                }
            }
        }
 
        Events("onMatch")
    }
}

これで JS 側は「認識を頼み、当たった曲を受け取って保存・共有する」だけになります。音声の重い部分はネイティブに閉じ込められるので、ブリッジを詰まらせません。

作ってみて分かった落とし穴

最後に、実装でつまずいた点を残しておきます。

第一に、マイク権限の説明文です。Info.plist に NSMicrophoneUsageDescription を入れ、「なぜマイクが必要か」を正直に書きます。ここが空だと審査で弾かれますし、ユーザーの不信も招きます。

第二に、待機への戻し忘れです。前述の通り、prepare() でマイクが動き始めるので、画面を離れたら必ず cancel() します。裏で録り続けると、電池のクレームやプライバシーの懸念に直結します。本番運用でこの落とし穴を踏むと発見が遅れがちなので、画面遷移の節目で確実に止める設計にして回避します。

第三に、当たらないときの見せ方です。周囲がうるさい、曲がインストゥルメンタルで特徴が薄い、といった理由で noMatch は普通に起きます。「一致しませんでした。もう少し近づけて、もう一度お試しください」のように、次の一手を添えると、体験が優しくなります。

第四に、prerecording の入れどころです。画面表示と同時に始めると自然ですが、常時録りためるとその分だけ電力を使います。認識機能を使いそうな画面に限って先取りする、といった絞り込みが、電池持ちとの折り合いになります。

まずは Apple のカタログを相手に、「タップして一曲当てる」ところまで作ってみてください。その手触りが掴めれば、prerecording での精度上げも、自前カタログへの拡張も、Rork Max と Expo の分担も、素直に伸ばしていけるはずです。同じ「かざすと分かる」を作ってみたい方の参考になれば幸いです。