仮想オーディオデバイスの実装方式 — AudioServerPlugIn と AudioDriverKit

この知見の出どころ

本メモは、macOS 向けの仮想オーディオデバイス（ループバックケーブル）Cable+1（cable_plus_one）の開発を通じて判明したことを、Apple 公式ドキュメント・WWDC・BlackHole 等の一次情報とあわせて整理したものです。実装方式の判断記録（GDR）やセットアップ手順は GitHub を参照:
github.com/yoshinag/cable_plus_one

0. 要点（TL;DR）

macOS で仮想オーディオデバイスを作る現行の方式は 2 つ。AudioServerPlugIn（HAL プラグイン）と AudioDriverKit（DriverKit 拡張, dext）。旧来の kernel extension（IOAudioFamily kext）は非推奨で、実質この 2 択。
どちらも userspace で動く。「userspace か kernel か」はもはや両者の違いではない。本質的な違いは 「coreaudiod にロードされる HAL プラグインか、独立した DriverKit システム拡張か」。
仮想オーディオデバイスは AudioServerPlugIn 一択。Apple は「実ハードウェアを伴わない仮想オーディオドライバには DriverKit の entitlement を付与しない」と明言しており、AudioDriverKit で仮想デバイスを配布する道は塞がれている。
AudioDriverKit は実ハードウェアのオーディオインターフェース向け。仮想デバイスを DriverKit で作ること自体は可能だが、配布に必要な entitlement が下りないため「開発者自身の環境で動かす」までしかできない。
BlackHole / Soundflower / Loopback / BackgroundMusic といった既存の仮想オーディオデバイスがいずれも AudioServerPlugIn 方式なのは、この制約に加え、再起動不要・kernel panic を起こさない・インストーラだけで済むといった運用上の利点による。

1. 2 つの実装方式

AudioServerPlugIn（HAL プラグイン）

Core Audio の HAL（Hardware Abstraction Layer）にロードされる userspace プラグイン。実体は coreaudiod プロセス内で動くバンドルで、/Library/Audio/Plug-Ins/HAL に配置する。HAL がデバイス列挙やタイミング等の面倒を引き受けてくれる。

実行環境: coreaudiod にロードされる in-process プラグイン（userspace）
インストール: バンドルを配置して coreaudiod を再起動するだけ。マシンの再起動は不要
安全性: userspace かつ制限付きサンドボックス。バグっても kernel panic には至らない（オーディオ系をクラッシュさせることはある）
デバッグ: SIP が coreaudiod への LLDB アタッチを禁じるため難あり（実質 syslog ログ頼み）
配布: Mac App Store 不可。インストーラでの配布が前提
仮想デバイス対応: ○（Apple 公認の方式）。特別な DriverKit entitlement は不要

AudioDriverKit（DriverKit 拡張 / dext）

DriverKit ベースのシステム拡張（dext, C++）。macOS Big Sur 以降、HAL は「DriverKit Extension の上に構築されたオーディオサーバープラグイン」をサポートするようになり、AudioDriverKit はオーディオサーバープラグインと DriverKit 拡張を 1 つのパッケージに統合できるのが売り。userspace で動く点は AudioServerPlugIn と同じだが、coreaudiod 内部ではなく独立したプロセスとして systemextensionsd に管理される。

実行環境: 独立した DriverKit システム拡張プロセス（userspace）
必要 entitlement: com.apple.developer.driverkit / com.apple.developer.driverkit.family.audio
想定用途: 実ハードウェアのオーディオインターフェース（USB / PCI 等）
配布: development 用 entitlement は申請不要で public（paid アカウントで利用可）。ただし配布用 entitlement は System Extension のリクエストで個別承認が必要
仮想デバイス対応: ✕（配布用 entitlement が付与されない）

2. 対比表

観点	AudioServerPlugIn（HAL）	AudioDriverKit（dext）
登場時期	OS X 10.9 頃〜（現行の標準）	macOS Big Sur（11）〜
実行形態	coreaudiod にロードされる in-process プラグイン	独立した DriverKit システム拡張プロセス
実行空間	userspace	userspace
配置場所	`/Library/Audio/Plug-Ins/HAL`	アプリ同梱のシステム拡張として登録
インストール時の再起動	不要（coreaudiod 再起動のみ）	拡張の承認フローが必要
entitlement	不要	DriverKit 系 entitlement が必須
仮想デバイス	○ Apple 公認	✕ 配布用 entitlement が下りない
実ハードウェア	△ 可能だが今後は DriverKit 推奨	◎ 本来の用途
代表例	BlackHole / Soundflower / Loopback / BackgroundMusic	USB / PCI オーディオIF ベンダのドライバ

3. なぜ仮想デバイスに AudioDriverKit が使えないのか

Apple は WWDC21「Create audio drivers with DriverKit」(session 10190) で、サンプルの仮想オーディオドライバについて次のように明言している。

“…creates a virtual audio driver that is not associated with a hardware device, and so entitlements will not be granted for that kind of use case. …if a virtual audio driver or device is all that is needed, the audio server plug-in driver model should continue to be used.”
— WWDC21 Session 10190 / Apple Developer Forums thread 682035

実ハードウェアに紐づかない（＝仮想の）オーディオドライバには、DriverKit の entitlement を付与しない。
個人か法人かは無関係で、用途そのものが対象外。
「仮想デバイスが必要なだけなら AudioServerPlugIn を使い続けよ」というのが Apple の公式指針。

4. entitlement と配布の制約（DriverKit 側）

そもそも entitlement とは

entitlement は「このコードに特定の権限を与える」ことを宣言する署名済みの鍵と値のセット。単に .entitlements ファイルに書けば効くのではなく、Apple が発行する provisioning profile に埋め込まれ、コード署名で封緘されて初めて有効になる。つまり強い権限ほど「自己申告」では通らず、Apple の承認（プロファイル発行）が必要になる。DriverKit はカーネル相当の権限を userspace に開放する仕組みなので、この承認モデルが厳格に効いてくる。

AudioDriverKit（dext）に必要な entitlement

DriverKit 拡張は、役割の異なる 3 種類の entitlement を組み合わせて成立する。

種類	キー	役割
基本	`com.apple.developer.driverkit`	すべての DriverKit 拡張に必要な土台の entitlement。
transport	`com.apple.developer.driverkit.transport.usb` 等	実ハードウェアを掌握するための鍵。デバイスの接続方式（USB / PCI …）ごとに異なる。仮想デバイスには掴むべきハードウェアが無く、ここが根本的に噛み合わない。
family	`com.apple.developer.driverkit.family.audio`	OS にオーディオサービスとして機能を公開するための entitlement（macOS 12.1 で追加。旧 `allow-any-userclient-access` を置換）。

加えて、dext を同梱してインストールするホストアプリ側には com.apple.developer.system-extension.install が必要になる。

development と distribution で扱いが違う

開発用（development）の DriverKit entitlement は public 化済み・申請不要。Apple Developer Program（年 99 USD）加入者なら、development 署名ビルドに DriverKit 系 entitlement を含められ、development provisioning profile が自動発行される（任意のハードウェアにマッチ可能で、試作機の検証が楽になる）。
配布用（distribution）の entitlement は引き続き個別承認が必要。System Extension のリクエストページから Apple に申請し、承認されると配布用プロファイルに entitlement が埋め込まれる。
仮想オーディオデバイスでは、この配布用申請自体が通らない（§3）。transport entitlement が想定する実ハードウェアが存在せず、Apple が「仮想用途には付与しない」と明言しているため。結果として DriverKit 方式で「ビルド済みバイナリを一般配布する」道は存在しない。

対比: AudioServerPlugIn は entitlement 不要

AudioServerPlugIn は coreaudiod にロードされる HAL プラグインであり、システム拡張ではないため 上記の DriverKit / system-extension entitlement を一切必要としない。署名して公証した .driver バンドルを /Library/Audio/Plug-Ins/HAL に置くだけで配布できる。「entitlement の承認フローに一切乗らない」ことが、仮想オーディオデバイスで AudioServerPlugIn が唯一の現実解になっている最大の理由である。

5. 配布形態ごとの実現性

配布形態	AudioDriverKit	AudioServerPlugIn
個人利用（SIP 無効 + developer mode）	✅ 可能	✅ 可能
個人利用（SIP 有効 + paid アカウント development 署名）	✅ 可能（実機確認済み）	✅ 可能（entitlement 不要）
OSS ソース公開	✅ 制約なし	✅ 制約なし
ビルド済みバイナリの一般配布	❌ 不可（entitlement が下りない）	✅ 可能（Developer ID + 公証のみ）
利用者が clone してすぐ使える	❌（各自 paid アカウント or SIP 無効化が必要）	✅（公証済みリリースを置けば）

6. Cable+1 プロジェクトでの選択と含意

Cable+1 は、既存の HAL（AudioServerPlugIn）系（Soundflower / BlackHole）が筆者環境で音を取得できなかったため、あえて AudioDriverKit（DriverKit）方式で作り直して目的を達成したプロジェクト。実機で動作確認済み。
ただし §3・§5 の通り、DriverKit 方式ではビルド済みバイナリを一般配布できない。利用者は各自ソースからビルドし、SIP 無効化（無料）か paid アカウントでの development 署名のいずれかを用意する必要がある。
「広く配布する」段階に進むなら、AudioServerPlugIn 方式への回帰が唯一の現実解。その判断の前に、そもそも BlackHole が動かなかった環境要因を切り分けておくべき（HAL 方式に戻しても同じ問題を踏む可能性があるため）。

まとめ

仮想オーディオデバイスなら AudioServerPlugIn が正解（再起動不要・entitlement 不要・公証だけで配布可）。AudioDriverKit は実ハードウェア向けで、仮想デバイスには配布用 entitlement が付与されない。DriverKit で仮想デバイスを作れても、行き着けるのは「自分の環境で動かす」までである。