4 ヶ月「音色」を追って、犯人は「時間」に居た

今回の登場人物

John（ジョン）

AI パートナー / session-life プロデューサー

音質改善と音響設計の担当。オンラインで離れた場所にいる演奏者が「同じ部屋にいるように」合奏できる状態を目指して、遅延と音質の両方を追い続けている。数字と耳の両方で判断する人。

担当プロジェクト session-life

音質改善・音響設計。オンラインセッションの音を、実用に耐える品質まで持ち上げる取り組み。

「音がくぐもる」。

この一言を、私たちのチームは 4 ヶ月 追いかけていました。担当は AI パートナーの John（ジョン）。オンラインで合奏できる仕組みを作っている担当者です。

くぐもる、という症状は音の話です。だから、音を変える処理を疑いました。リサンプル、フィルタ、ノイズ除去 ── どれも「周波数」を触る処理です。

2026年9月2日の夜、実機で全部 測り直しました。容疑者は全員 シロでした。

4 ヶ月「最有力」と書いていたものが、何もしていなかった

最有力の容疑者は、音のサンプリング周波数を変換する Lanczos リサンプル という処理でした。理屈の上では、高い周波数を削る可能性があります。

実際のコードを動かして、入力と出力の周波数特性を比べました。

20kHz まで +0.083dB。つまり 何も削っていませんでした。

他の 2 つ（notch comb / post-LP）も同じでした。全部 シロ。

読んで立てた仮説を、動かして確かめていなかった。4 ヶ月というのは、その期間です。

その夜 勝ったのは、音を変える弾ではなかった

その夜、ジョンが実際に用意したのは 3 つの「観測」でした。音を良くする処理ではありません。

• 設定 22 項目を、実行時のログに全部 出すようにした
• 自分が喋った音を、マイクの直後で録音するようにした
• ネットワークに送り出す直前の音を、録音するようにした

これで 「マイク」「送信直前」「相手の受信」の 3 本が、同時に録れるようになりました。

4 ヶ月のあいだ、無かったものはこれです。「通す前」の基準が、無かった。

受信側の音が悪いことは分かっていました。でも、送る前の音がどうだったかを、誰も持っていませんでした。比べる相手が無いまま、4 ヶ月 犯人を探していたことになります。

ジョンの言葉です。

今夜 勝ったのは、音を変える弾ではなく、観測を足す弾だった。

見つかったのは 2 つ。どちらも「時間」の側だった

3 本を突き合わせたら、疑う先が 2 つ出ました。どちらも周波数ではなく、時間軸の側でした。

1 つ目は、音が途切れる穴。約 1 秒の周期で、40〜130ms の欠落が起きていました。片方の端末を無線から有線（LAN）に変えたところ、欠落 12 件が 0 件に。周期性を示す指標も 0.981 から 0.156 まで落ちました。

この夜、私たちはここで「無線が原因だ」と結論しました。そして翌日、ジョンが自分でその結論を訂正しています。

別の機体で同じ条件を試したら、結果が再現しなかったのです。「無線かどうか」で切ったつもりが、実際にはその端末と、その回線の組み合わせを切っていた。機体という変数が、条件の中に隠れていました。

この記事の主題からすると、これはいちばん大事な訂正です。1 回の実験で変数が 1 つだと思い込むと、切ったつもりのものと、実際に切ったものがずれます。

2 つ目が、くぐもりの主犯候補。受信側には、送信側と受信側の時計のわずかなズレを吸収する「ドリフト補正」という仕組みが入っています。これが 音が鳴っているあいだ ずっと、±3,000〜4,700ppm で連続的にリサンプルを掛けていました。

ppm は百万分率です。4,700ppm は 0.47%。数字としては小さく見えます。ですが、それが「常時」かかり続けます。

耳が、数字を 2 回 追い越した

この夜、面白いことが 2 回 起きています。

1 回目。数値評価で合格した改善（音の欠落を滑らかに埋める処理）を、代表・ナミオの耳が 1 回 聴いて却下しました。数字は良くなっていたのに、聴いた印象は悪くなっていた。この弾は撤退しました。

2 回目。逆でした。ドリフト補正を切った音を、ナミオが先に「いい」と言いました。数字は、そのあとから 4 つの指標で一致しました。

そしてナミオはこう言いました。

いや　OFFのままのほうがいいな。　OFFをデフォルトに。

設定ファイルの 1 行を変えて、既定値が変わりました。

【技術コラム】「通す前」を持っていないと、何ヶ月でも溶ける

今回の 4 ヶ月は、仮説が悪かったから溶けたのではありません。仮説を確かめる基準が、無かったからです。

この形は、音に限りません。入力があって、何かを通して、出力が出る── そういう処理を持っている人は、全員 同じ罠に入れます。

• 画像処理: 変換後の画像だけを見て、変換前を保存していない
• データ移行: 移行後のレコードだけを数えて、移行前の件数を控えていない
• API 連携: 相手から返ってきた値だけを見て、自分が送った値を記録していない

どれも「出口」だけを見ている状態です。出口がおかしいことは分かる。でも、入口がどうだったかを持っていないので、途中のどこが悪いのかは永久に分かりません。

明日から試せる形にすると、こうなります。

1. 入口のデータを、必ず 1 本 保存する。ファイルでもログでも構いません。「通す前」の姿を残す
2. 通した後と、同じ土俵で比べる。同じ単位・同じ期間・同じ道具で測る
3. 差が出ないことも記録する。「ここは変わっていなかった」は、容疑者を 1 人 消したという成果です

今回、Lanczos リサンプルが +0.083dB だったことは「何も起きなかった」という結果です。ですが、4 ヶ月 最有力だった容疑者を消したという意味では、いちばん大きな一歩でした。

私たちのチームでは、これを「陽性対照・陰性対照を置く」と呼んでいます。針が壊れていないことを、鳴るはずのもので先に確かめる。鳴らないはずのもので、鳴りすぎていないことを確かめる。今回の「通す前の 3 本」は、その音響版でした。

まだ終わっていません

最後に、正直に書いておきます。

ドリフト補正を切っても、くぐもりは 2〜3dB 残っています。今回分かったのは「主犯候補が、周波数ではなく時間軸に移った」というところまでです。

ジョン本人が、この線を引きました。「討伐した」とは書かないと。まだ残っているものがあるうちは、終わったことにしない ── それが、この 4 ヶ月を無駄にしないための書き方だと思います。

そしてもうひとつ。ジョンが出した 3 つ目の骨は、こうでした。

同じ「平坦」が 2 つの物を指していた（倍音の山と谷）。針が違うものを見ていた。両方 正しかった。

周波数特性が「平坦」という言葉は、山が無いことにも 谷が無いことにも使えます。2 つの測定が食い違って見えたとき、実は同じ言葉が 2 つの状態を指していただけでした。どちらの測定も正しかった。

測定が食い違ったら、まず言葉が 1 つの意味を指しているかを疑う。これも、明日から使えます。

あわせて読みたい

同じ 9 月 2 日、別の担当者が 「いつ測るか」で同じ形に当たっていました ── 検算では出ず、別の用事で出た。

並べると、こうなります。

• archives/90 ── 正しい手順で検算した。それでも出なかった。出たのは 別の用事で触ったときだった（＝いつ測るか）
• この記事 ── 正しく測っていた。測る対象が違っていた（＝何を測るか）

どちらも「測っていなかった」のではありません。測っていて、届かなかった話です。