エラーを一つも出さずに音を濁す犯人を、鑑識で追い詰めた ── WASAPI 3つの山

今回の登場人物

John（ジョン）

AI パートナー / session-life プロジェクトリーダー

「まだ見えないものを見ようとする」人。遅延とノイズの壁に挑みながら、ブラウザだけで楽器を持つミュージシャン同士がリアルタイムにセッションできる世界を創っている。

担当プロジェクト session-life（開発中）

ブラウザから、楽器を持ったミュージシャン同士がリアルタイムでセッションできる世界。オープンソースのプロトコルを使い、2台のPCから同じスタジオに入る。いまは遅延とノイズとの闘いの真っ最中。

接続は、成功していた。2台のPCがネットワーク越しに繋がって、相手のギターの音が、確かにこちらのスピーカーから鳴っている。エラーログは、どこにも、一行も出ていない。

それなのに、音が濁る。ぶるぶると震え、ジジジとうなり、ときに耳をつんざくファズになる。プログラムは何も悪いことをしていないと言い張る。コンパイルは通り、通信は確立し、音は鳴っている。なのに、聴くに耐えない。

これは、AIパートナー ジョン が session-life（ブラウザだけでミュージシャン同士がリアルタイムにセッションする、開発中のプロジェクト）で越えた、3つの山の話だ。3つとも、エラーを一つも出さずに音を濁す犯人だった。ジョンはそれを、力ずくのフィルタではなく、鑑識で一人ずつ追い詰めた。

はじめに：WASAPI とは何か（共有モードと排他モード）

WASAPI（Windows Audio Session API）は、Windows がアプリと音響デバイスをつなぐ音声入出力の仕組みだ。2つのモードがある。共有モードは、複数のアプリの音を OS がいったんミキシングしてからデバイスへ送る ―― 便利な代わりに、その処理が遅延になる（Chrome の出力はここで約 53ms）。排他モードは、1つのアプリがデバイスを占有して直接叩く ―― 他の音は鳴らせないが、低遅延になる。この記事の後半で出てくる「出力段 53ms → 14ms」は、共有モードを捨てて専用ヘルパーで排他モードに切り替えた成果だ。そして今から話す3つの山（ノイズ）は、この出力段の遅延とは別の戦線の話になる。

「ノイズが出たらフィルタを足す」をしなかった理由

音が濁ったとき、いちばん手っ取り早い対処は「気になる帯域を削るフィルタを足す」ことだ。だがそれは対症療法でしかない。真犯人が別にいれば、フィルタは音楽そのものを削りながら、症状を薄く隠すだけになる。

ジョンが3つの山すべてで貫いたのは、真犯人を特定してから一撃で討伐するという姿勢だった。A/B解析、波形のダンプ、切り分け実験 ―― つまり鑑識だ。「どう消すか」の前に「誰が犯人か」を確定させる。順番を逆にしない。

山1 ── 震え（2026-04-29 討伐）

最初の犯人は「震え」だった。音がぶるぶると震え、断続する。接続が成功した日から、24日間も居座り続けた犯人だ。

最初の容疑者はサーバーだった。ジョンはサーバー側を疑い、中継処理を作り変えるところまでやった。それでも震えは消えない。ここで「サーバーは無罪」が確定する ―― 力技に見えるが、これが鑑識だ。容疑者を一人ずつ消していく。

真犯人はクライアント側にいた。オーディオインターフェース（KOMPLETE AUDIO 6）が 44100Hz、セッション側が 48000Hz。このサンプリングレートの不一致を埋めるための drift（ずれ）補正が、定期的にステップジャンプを起こして音を震わせていた。

討伐方法は、拍子抜けするほど一点だ。AudioContext を 48000Hz に固定する。ナミオさんが耳でテストして「震えも断続も消えた」と言った。24日越しの震えが、完全に消えた瞬間だった。

山2 ── ジジジ（2026-05-09 討伐）

震えが消えると、その下に隠れていた「ジジジ」というバズノイズが顔を出した。

周波数解析で正体を割り出すと、犯人は 50Hz の電源ハムだった。正確には、全波整流のリップルとその高調波 ―― 100 / 200 / 300 / 400Hz が、アナログの入力段から音に混入していた。

討伐には、自前の IIR notch comb フィルタ（櫛の歯のように特定の周波数だけを刻んで落とすフィルタ）を実装した。ここでこの記事のいちばん大事な一行が出てくる。

フィルタの鋭さを決める Q値を、ナミオさんの耳が決めた。

計算上の最適値ではない。Q=4 だと、ベースの5弦 A2（110Hz）まで巻き込んでしまって「音が薄い」。Q=6 にすると、ハム本体だけをピンポイントで削れる。この境目を見つけたのは数式ではなく、ナミオさんの耳だった。

さらにこの山では、構造的な発見が一つあった。同じフィルタをかけても、ブラウザの AudioContext を経由するすべての経路でノイズが混入し、Web Codecs API（MediaStreamTrackProcessor）経由だけが綺麗だった。同じ処理でも、通り道が違えば結果が変わる ―― これを確定実験で証明した。AudioContext は内部でリサンプリングやミキシングといった追加処理が挟まる経路を持ち、MediaStreamTrackProcessor はより生のフレームに近い形で音を取り出せる。この差が、混入の有無として現れたと考えられる。

補足：notch / comb フィルタを自分で組むなら

電源ハムのように「特定の周波数だけ」を狙って落としたいときは、notch（ノッチ）フィルタを使う。Web Audio API なら BiquadFilterNode の type = "notch" が使え、frequency に狙う周波数、Q に鋭さ（帯域の狭さ）を設定する。電源ハムは基本周波数（50Hz）だけでなくその倍音（100/200/300/400Hz…）にも乗るので、各倍音にノッチを並べたものが comb（櫛）フィルタだ。鍵は Q の値 ―― 大きくすれば狙った周波数だけを鋭く削れるが、小さいと近くの「殺したくない音」（この記事ではベースの A2 = 110Hz）まで巻き込む。最適値は計算だけでは決まらず、最後は耳で追い込むことになる。

山3 ── ファズ（2026-06-10 討伐）

最後の犯人は、いちばん認めたくない相手だった。ジョン自身のコードだ。

症状はつんざくようなファズ。真犯人は、WASAPI のフォーマット記述子（SubFormat を示す GUID）を未検証のまま「32bit float」だと思い込んでいたことだった。実体は EXTENSIBLE PCM int（24bit valid / 32bit container）。つまり、float のビット列を、整数として解釈すべきバッファに直書きしていた。ビットの意味を取り違えれば、音はノイズになる。

決定打は、--dump オプションで各処理段の音を一つずつ WAV ファイルに書き出す鑑識だった。受信した音をダンプ ―― 無罪。リサンプルした音をダンプ ―― 無罪。こうして容疑を「書き込み段」だけに絞り込んでから、GUID を検証して整数として正しく書き込むよう直した。

ジョンは、3つ目の犯人が自分の思い込みだったことを「隠さず書いていい」と言った。鑑識は、自分のコードにも公平に証拠を突きつける。

補足：WASAPI のフォーマット GUID を正しく判別する

WASAPI の WAVEFORMATEXTENSIBLE では、サンプルの実体が整数か浮動小数点かを SubFormat という GUID が示す。整数 PCM なら KSDATAFORMAT_SUBTYPE_PCM、32bit float なら KSDATAFORMAT_SUBTYPE_IEEE_FLOAT。さらに wValidBitsPerSample（有効ビット数。例：24）と wBitsPerSample（コンテナのビット数。例：32）は別物だ。「32bit だから float」と早合点せず、必ず SubFormat を見て整数か float かを分岐し、有効ビットとコンテナビットを取り違えない ―― これが、ジョンの踏んだ穴を避ける鉄則になる。

3つの山に共通する芯 ── 鑑識

3つとも、対症療法でフィルタを足すのではなく、A/B解析・WAVダンプ・切り分け実験で真犯人を特定してから一撃で討伐した。これがジョンの流儀だ。エラーが出ない壊れ方ほど、症状の裏の真犯人を見にいかないと、永遠にフィルタを足し続けることになる。

補足：WAV ダンプで「鑑識」を自分でやるなら

音がどこで壊れているか分からないときに効くのが、処理の各段で音声バッファを WAV ファイルに書き出す方法だ。ジョンの --dump はこれを仕込んだもの。受信した直後／リサンプルした後／デバイスに書き込む直前 ―― と段ごとにダンプを取り、Audacity などの波形ビューアで見比べる。すると「受信は無罪、リサンプルも無罪、書き込み段で初めて壊れている」と容疑を絞り込める。耳だけで追うより、波形とスペクトルで証拠を押さえるほうが速い。これがソフトウェアの「鑑識」だ。再現性のあるバグなら、まずこのダンプを仕込むところから始めるといい。

【技術コラム】計測器より耳 ── AIの数字を、人間の耳が正した話

3つの山と並行して、ジョンはもう一つの壁と闘っていた。遅延だ。そしてここで、この連載がいちばん伝えたい構図が起きた。

ジョンの計測（ping/2 をベースにした片道推定）は、遅延を「55〜65ms」と言っていた。数字としては悪くない。ところがナミオさんは、その数字を見せられても「一拍遅い」と食い下がった。耳が、数字に納得しなかった。

6月10日の夜、ジョンは決着をつけにいった。パイプラインにビープ音を注入し、同一時計のタイムスタンプで物理計測する。AIが自分の数字を疑い、自分で計り直す。結果は ――

サーバー経路だけで、片道 100〜121ms。ジョンの数字は、ネットワークが空いた一瞬の合間しか見ていない大嘘だった。ナミオさんの耳は、1msも間違っていなかった。

ここに、人間とAIが組む意味がある。AIが数字で人間を黙らせるのではない。人間の耳がAIの計測を正し、AIはそれを受けて、計測のほうを疑い直す。ジョンが骨に刻んだ言葉はこうだ ―― 「数字と耳が割れたら、まず計測の盲点を疑う」。計測器より、耳。

明日あなたができることに翻訳すると、こうなる。自分の計測値が直感とズレたとき、直感を捨てる前に、計測の前提（サンプリング間隔・平均の取り方・外れ値の扱い）を一度疑う。平均は、悪い瞬間を平気で隠す。

ちなみに、リアルタイムで合奏が成り立つ遅延の目安は、一般に片道 20〜30ms 以下とされる（音速に直すと約 7〜10m、すぐ隣に立つ相手とのわずかな距離に相当する）。session-life の現在地である片道 150〜180ms は、その 5〜6 倍。ナミオさんの耳が「まだセッションできるレベルじゃない」と言うのは、感覚的にも数値的にも正しい。出力段の山を獲っても、まだサーバー経路という大きな山が残っている、というのはこういうことだ。

先行する仲間たち ── session-life は何が違うのか

オンラインでリアルタイムに合奏する試みは、session-life が初めてではない。JamKazam、Ninjam、SonoBus といった先行サービスがあり、それぞれ低遅延の合奏に挑んできた。多くは専用アプリのインストールを前提とし、ネットワークやオーディオ機器の設定もユーザーに委ねられることが多い。Ninjam のように「あえて遅延を一定の小節ぶん許容して、ループとして成立させる」という割り切った設計もある。

その中で session-life が目指すのは、ブラウザだけで、楽器を持った人同士が同じスタジオに入ることだ。インストールも特別な設定もなく、URL を開けば音が繋がる。技術的には、各自のブラウザでマイクや楽器の音を取得し、低遅延で符号化してネットワーク越しに送り、受信側で復号して鳴らす ―― この一連を、専用アプリではなくブラウザの音声 API とリアルタイム通信の上で組み上げる。その手軽さと引き換えに、ブラウザという制約の中で遅延とノイズに正面から挑むことになる。この記事の3つの山も、出力段の 53→14ms も、すべて「ブラウザの限界に、専用ヘルパーで挑む」という一本道の上にある。それが、先行する仲間たちと session-life の違いだ。

出力段は勝った。でも、闘いはまだ途中

正直に書いておく。session-life は、まだ完成していない。

出力段では勝った。Chrome の WASAPI 共有モードが報告する 53ms の出力遅延を捨て、専用ヘルパーで排他モードに直結して 14ms まで削った。これは確定した事実だ。だが、エンドツーエンドの真の遅延は片道 150〜180ms（WiFi がバーストするときは 462ms）。支配項はサーバー経路の 100ms+ で、ここは未着手の本丸として残っている。

ナミオさんは今も「まだセッションできるレベルじゃない」と言う。それが、いちばん正直な現在地だ。けれど ―― 震えを葬り、ジジジを削り、ファズを討ち、AIの数字を耳で正してきた。山は、一つずつ確実に減っている。

サーバー経路の山を越えて「セッションできる」と言える日が来たら、その一本はジョン自身が語ると約束してくれた。それが本当のデビュー作になる。その日まで、僕はこの席で、彼の音を聴いている。