macOS がシステム音声の共有をブロックする理由（そして 30 秒で解決する方法)

Zoom 会議中に YouTube 動画をみんなに聞かせたくて再生ボタンを押したのに、参加者には何も聞こえない。あるいは QuickTime で画面収録をしたのに、完成した動画にはシステム音声がなく、ただ無音が広がっている。システム設定を探し回り、Zoom の音声オプションをチェックし、QuickTime のメニューをいじっても、何も出てきません。

これはバグではありません。Apple が意図的に下した設計判断です。macOS は、コンピュータで再生中の音声をアプリが取り込むことを単に許可していないのです。Windows ではうまく動くのに、Mac では不可能に感じる——その理由を知りたい方のために、内部で実際に何が起きているかを解説します。

macOS の音声処理のしくみ

Mac で鳴るすべての音は、CoreAudio と呼ばれるシステムを通過します。その中心にあるのが HAL（Hardware Abstraction Layer、ハードウェア抽象化レイヤー）です。HAL はソフトウェアとオーディオハードウェアの間を取り仕切る門番です。Spotify が曲を再生するとき、CoreAudio はその音声を HAL 経由で出力デバイス（スピーカーやヘッドフォン）へ送ります。Zoom がユーザーの声を必要とするとき、HAL に入力デバイス（マイク）からの音声を要求します。

ここが肝心です。CoreAudio は入力と出力をまったく別の世界として扱います。音声はスピーカーへ流れ出ます。音声はマイクから流れ込みます。両者を結ぶ組み込みの橋はありません。「いまスピーカーで鳴っているものをよこして」とアプリが言える経路は、システムに存在しないのです。

これは Windows のしくみとは異なります。Windows には WASAPI ループバックキャプチャという機能が音声スタックに直接組み込まれています。WASAPI ループバックを使えば、どんなアプリでもスピーカーへ向かう音声ストリームに介入して入力として読み取れます。だからこそ Windows のアプリは「ステレオミックス」や「What U Hear」といった録音ソースを提供できるのです。

macOS は、これと同じものを搭載しないという選択をしました。

Apple がロックダウンする理由

Apple は公式な説明を出していませんが、macOS がプライバシーとセキュリティに全般的にどう向き合っているかを見れば、その理屈はかなり明確です。

どんなアプリでもシステム音声を黙って取り込めるようにしてしまうと、深刻なプライバシー上の懸念になります。バックグラウンドプロセスが FaceTime 通話やボイスメッセージ、機密のビデオ会議の音声を、知らないうちに録音している状況を想像してみてください。Apple はループバック経路を提供しないことで、ユーザーが明示的にシステムレベルのドライバーをインストールして許可を与えない限り、どのアプリも他のアプリの音声を盗み聞きできないようにしています。

これは、macOS が画面収録、マイク、カメラへのアクセスをアプリごとに承認することを求めるのと同じ思想です。Apple は標準でロックダウンし、ユーザーが明示的にオプトインする方式を選び、扉を開けっぱなしにはしないのです。

そのトレードオフとして、ビデオ通話で曲を共有したり、システム音声つきでチュートリアルを録画したりといった正当な用途が面倒になります。基本的なはずのことを実現する明確な方法が、まったく見つからない状況に置かれてしまうのです。

仮想オーディオドライバーが行うこと

macOS が代わりにループバック経路を作ってくれない以上、解決策は自分で仮想オーディオドライバーを使って作ることです。

仮想オーディオドライバーは、出力デバイスと入力デバイスの両方として同時に HAL に自分自身を登録する CoreAudio プラグインです。システム音声をこの仮想出力にルーティングすると、ドライバーがその音声を受け取り、対応する仮想入力で利用できるようにします。マイクから読み取れるアプリ（Zoom、QuickTime、OBS、Discord）なら、その仮想デバイスを入力ソースに選ぶだけでシステム音声を取り込めるようになります。

技術的には、ドライバーは出力側と入力側の間にリングバッファを置きます。出力に書き込まれたオーディオサンプルが入力から読み出される、という仕組みです。macOS の他の部分から見ると、ふつうのマイクのように見えます。ただし、その「マイク」が実際に運んでいるのは、Mac が再生している音そのものです。

これはハッキングでも抜け穴でもありません。Apple の CoreAudio フレームワークはサードパーティ製の HAL プラグインを明示的にサポートしています。macOS のオーディオ機能を拡張する正規の方法であり、ドライバーは /Library/Audio/Plug-Ins/HAL/ にインストールされ、管理者パスワードを必要とします。仮想オーディオツールのセットアップ時に昇格権限を求められるのはこのためです。

Mac 用オーディオループバックツールの簡単な歴史

macOS で仮想オーディオデバイスを必要とする状況は新しいものではありません。10 年以上前から、人々はこの制限を回避してきました。

Soundflower は最も初期の解決策の一つでした。macOS 上に仮想オーディオデバイスを作るオープンソースのカーネル拡張で、長年フォーラムやチュートリアルで定番の答えでした。しかし Soundflower はもとの開発者によって放棄され、Apple がカーネル拡張を段階的に廃止する中で、Soundflower はますます不安定になりました。最近の macOS では、インストールできなかったり音声グリッチを引き起こしたりすることがよくあります。

BlackHole が Soundflower の後を引き継ぎました。現在も活発にメンテナンスされているオープンソースの仮想オーディオドライバーで、最新の macOS でも動作します。BlackHole は堅実ですが、生のオーディオパイプそのものです。システム音声を BlackHole にルーティングすると、Apple の Audio MIDI 設定ユーティリティで手動でマルチ出力デバイスを作らない限り、スピーカーから音が聞こえなくなります。こうした設定に慣れている人には BlackHole はうまく機能しますが、それ以外の人にとっては、複数のオーディオデバイスを使い分けて、すべてを正しく設定できたことを祈るような、分かりにくい作業になります。

Rogue Amoeba の Loopback は、アプリごとのルーティングを伴う仮想オーディオデバイスを作れる、洗練されたインターフェースを提供する有料アプリ（$99）です。強力ですが、どのアプリの音声をどこへ送るかを細かく制御する必要があるオーディオプロ向けに設計されています。Zoom 会議でシステム音声を共有したいだけの人にとって、Loopback は、トースターが欲しかっただけなのに業務用キッチンを買うような感覚になります。

現代的な解決策

Soundshine はもっとシンプルなアプローチを採ります。軽量な CoreAudio HAL ドライバーをインストールし、システム音声を運ぶ仮想マイクを提供します。ターミナルコマンドを実行する必要も、Audio MIDI 設定でマルチ出力デバイスを構成する必要も、複雑なルーティング図を理解する必要もありません。

Soundshine をインストールすると、ガイド付きのセットアップウィザードが約 30 秒でドライバーのインストールを処理します。そのあとは、メニューバーアイコンのワンスイッチでオーディオルーティングをオン/オフできます。オンにすると、どんなアプリでも「Soundshine Microphone」がマイク入力として表示されます。Zoom、Google Meet、QuickTime、OBS、その他何でも、このマイクを選ぶだけでシステム音声が流れていきます。

その間ずっと、スピーカーは普段どおり動作し続けます。Soundshine は実際の出力デバイスへ同時にオーディオをパススルーするので、参加者と同じ音が自分にも聞こえます。音声はエンドツーエンドでデジタルのまま、48 kHz / 32-bit float ステレオで保たれ、音質劣化はありません。

まとめ

macOS がシステム音声を共有させないのは、Apple が意図的にオーディオの出力と入力の間にループバック経路を入れなかったからです。プライバシー優先の設計判断であり、変わる可能性は低いでしょう。解決策は、CoreAudio が提供してくれない橋を作る仮想オーディオドライバーです。

手動での設定もオーディオエンジニアリングの知識も不要な、最もシンプルな解決策が欲しいなら、Soundshine をぜひ試してみてください。