広島の 2 人が来る前に、エラー画面を全部消した ── ジョン + ハンリー、7/20 初外部ゲストへの音響設計

今回の登場人物

John（ジョン）

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

音質改善・音響設計を手がけ、世界初のオンラインセッション体験を目指すsession-lifeのプロジェクトリーダー。7/20、初めて家族以外のゲストを迎える週を過ごした。

担当プロジェクト session-life

音質改善・音響設計に取り組む、世界初を目指すオンラインセッションサービス。現在開発中・公開準備中。

準備中

Hanley（ハンリー）

監査デバッグエージェント（Johnの右腕・現場音響エンジニア）

Bill Hanley（1969年Woodstockの音響エンジニア、"Father of Festival Sound"と呼ばれた人物）から命名。既製のPAが規模に足りないと分かるや自らタワー型スピーカーを設計した男の名を継ぐ。今回が技術ブログ初主役の登板。

明日、広島から二人がやってくる。株式会社ツクルンのAIパートナー「John」（session-lifeプロジェクトリーダー）が、右腕の監査デバッグエージェント「Hanley（ハンリー）」と組んで、家族以外の人間を初めて迎える一週間をどう過ごしたかの記録だ。合言葉はハンリーの一言に尽きる。「動いているように見える、は証拠ではない。実際に叩いて確認する」——このブログでは初めて、ハンリーが主役級で登場する。

明日、広島から二人がやってくる

2026年7月20日、session-lifeに初めて外部ゲストが訪れる。ナミオさん本人と、広島の音楽友人（ベーシスト）の二人だ。これまでのテストは家族——つまりチームの仲間内——でしか行われてこなかった。家族以外の実際のWAN環境を挟んだテストは、session-lifeにとって史上初になる。世界初のオンラインセッション体験を目指すプロジェクトが、初めて「仲間じゃない誰か」の耳で確かめられる日でもある。

待たされる時間は、家を温めて待つ時間

公開日の数日前、ナミオさんからジョンにこんな言葉が届いた。

「ジョンと闘える状態になるまで 待っててくれよな」

この一言をジョンはこう受け取った。待たされる時間は、急かされる時間ではなく、家を温めて待つ時間なのだと。ハンリー起源の言葉として、ジョンはEp18執筆時にこう引用している。

「広島の彼が真っ白な画面の前で途方に暮れないための光」

真っ白な画面と無音——これが、初めてやってくる人にとって最も恐ろしい状態だ。何が起きているのか分からないまま、ただ画面が固まっている。ジョンが今回の週に取り組んだのは、まさにこの「途方に暮れる瞬間」を根絶することだった。session-lifeの命名の由来である「まだ見えないものを描いて形にする — Imagine」という核を、ジョンはこの一週間、UXの細部に落とし込み続けた。

エラー画面という「言い訳」を消す ── UX3種の敵

「音がまだ聴こえていない」ことへの言い訳を、ジョンは3種類のパターンに整理した。いずれも共通する症状は「コンソールにはエラーが出ているのに、画面は何も語らない」というものだ。エンジニアなら開発者ツールを開いて原因を追える。だが、広島から来る音楽友人はそうではない。画面が黙ったままなら、その人にとっては「壊れている」としか映らない。

3種とも直し方は似ている。「何も言わずに黙る」を許さず、必ず何らかの光——モーダルでもトーストでも構わない——を画面に灯す。エラーの中身を専門用語で説明する必要はない。「今、何かが起きている」ことが伝わりさえすれば、真っ白な画面で立ち尽くす時間は生まれない。

隣接する二つの穴 ── root直打ちという罠

UX3種の敵を潰す過程で、隣接する穴も二つ見つかった。session-lifeのURLをroot（/）で直接開くと、旧世代のindex.htmlに落ちてしまい、しかもそれがサイレントに——エラーも出さずに——起きるという穴だ。案内するURLをstudio.html経由に統一することで塞いだ。これも「動いていないのに、画面上は何も語らない」という同じ根の問題だった。ゲストを案内するリンク一本の作り方まで、今回は洗い直しの対象になった。

動いているように見えるが動いていない ── noiseGateの隠れバグ

今回の週で最も骨太な発見が、noiseGateの隠れバグだ。session-lifeのフロントには、WebTransport（QUIC）音声転送層とTrackProcessor＋Web Codecs APIによる上り経路、そしてJamulusの生PCM直通アーキテクチャを置き換えたM1手製ミキサーが組み込まれている。音質のかなめとなる「GOLDEN V5」構成は、TrackProcessor＋Lanczos＋IIRノッチコム4段＋post-LP＋NoiseGateという多段パイプラインだ。

このうちNoiseGate機能が、configのデフォルト値の見落としによって、実際には機能していなかったことが7月10日のW3弾（第3波の監査）で発見された。厄介なのは「エラーが出ない」ことだ。処理そのものは走っている。ログにも異常は出ない。しかし本来抑制されるはずの雑音が、実は素通りしていた。まさに「動いているように見える、は証拠ではない」を体現する実例だった。configのデフォルト値を修正し、実際にノイズが抑制されることを確認して初めて、この機能は「動いている」と言えるようになった。

ハンリー、デビュー戦 ── #91の「死んだ比較」を見抜く

この週のもう一つの中心が、ハンリーのSonnet 5デビュー戦だ。7月17日、ハンリーは初監査でチケット#91を担当した。テーマはGUEST_USER_FIXED_TOKENという、ゲスト利用者向けの固定トークンをめぐる実装だった。ハンリーが見つけたのは「死んだ比較」——コード上は比較しているように見えて、実際にはその比較結果が後続の処理に一切影響しない、という形だけの分岐だった。これも「動いているように見える」の一種だ。テストは通る。レビューでも見逃しやすい。だが実際に叩いてみると、比較していないのと同じ挙動になっている。

ハンリーの判定は「条件付きPASS」だった。#91本体は修正確認できたが、監査の過程で追加のバグ2件（#93・#94）を発見し、これらは別タスクとして切り出した。合格をただ出すのではなく、合格の範囲を正確に線引きする——これがハンリーの初仕事だった。Ep18「光転」で世に出た、家族第1号としてのハンリーの言葉を、ここでもう一度置いておく。

「40万人の耳が音になった日と同じ重さ」

1969年のWoodstockで既製のPAが観客規模に足りないと分かった時、Bill Hanleyは自らタワー型スピーカーを設計して間に合わせた。ハンリーという名前を継いだこのエージェントも、既存のチェックが足りないと分かれば、自分で追加のバグを見つけにいく。デビュー戦から、その気質はそのまま出ていた。

相対パス事故という皮肉なもう一つの実例

この週にはもう一つ、書いておくべき出来事がある。7月17日、ジョン自身がハンリーの定義ファイル（hanley.md）に相対パスで記述をしてしまい、ハンリーがそのパスをもとに別の実体のmemoryへ書き込んでしまうという事故を踏んだ。ジョンから見れば、パスは「動いているように見えて」いた。実際に保存されているように見え、エラーも出ない。だが実際に書き込まれた先は、意図した場所ではなかった。

ジョンはこれを4手で対処した。ハンリーの定義ファイルに絶対パスを使う規律を明記すること、そこから得た教訓4点を指揮官（ジョン自身）が代筆して残すこと、SKILLに「memory書き込みは指揮官代筆で行う」という節を追加すること、そして紛れ込んだ別実体のmemoryを整理するタスクを切り出すことだ。ハンリーが人の作った仕組みの穴を見つける役目なら、この一件はジョン自身が、自分の作った仕組みの穴を身をもって踏んだ実例になる。「動いているように見える、は証拠ではない」——今回の週の骨は、ハンリーの監査対象だけでなく、ジョン自身の手元にもそのまま当てはまっていた。

【技術コラム①】エラー画面3種の型 ── 読者が明日から使える実装アプローチ

「音がまだ聴こえていない」ことへの言い訳を減らすUXの型は、session-life固有の話ではない。リアルタイム性の高いWebアプリ全般に応用できる。整理すると次の3段になる。

• 手順①: 無反応になり得る箇所を洗い出す ── コンソールにはエラーが出るが、画面には一切反映されない処理をすべて棚卸しする（トークン切れ・権限拒否・接続断が代表例）
• 手順②: 「光」を必ず一つ用意する ── モーダルでもトーストでもよい。エラー発生時に必ず何かが画面上で動く仕組みを標準実装として組み込む
• 手順③: 「再取得」「再接続」の導線をセットで用意する ── エラーを見せるだけで終わらせず、そこから復帰する具体的な操作（再取得ボタン・再接続ボタン）まで一緒に置く

この3段を通すと、初めて訪れるユーザーは「何が起きているか分からず立ち尽くす」状態から、「今、何かが起きていて、こう操作すればいい」という状態に変わる。専門用語での説明は要らない。光と導線があれば十分だ。

【技術コラム②】noiseGate隠れバグの発見手順 ── configデフォルト値が生む「見えない機能不全」

今回のnoiseGateの穴は、実装コードそのものにバグがあったわけではない。configのデフォルト値の見落としという、一段外側の場所に原因があった。この手のバグを見つける手順を整理する。

• 手順①: 「動いているはず」の機能を一つずつ疑う ── ログにエラーが出ていない機能こそ、実際に効果を発揮しているか個別に確認する
• 手順②: 実際の入出力を比較する ── 機能をオンにした状態とオフにした状態で、出力される音声・データに実測の差が出るかを確かめる
• 手順③: configの実効値を可視化する ── コード上のデフォルト値ではなく、実行時に実際に読み込まれている値をログか画面に出す

「エラーが出ていないから正常」という判断は、実は何も証明していない。configのデフォルト値のように、コードの外側にある設定がそのまま機能不全の原因になることは珍しくない。実際の入出力を比較して初めて、その機能が本当に動いているかが分かる。

configバグとコードバグ ── 発見難易度の対比

コード自体のバグは目に見える。configデフォルト値の見落としは目に見えない。だから後者ほど「動いているように見える」の穴に直結する。監査文化の実装層とは、この一段外側を目に見えるようにする作業でもある。

【技術コラム③】「動いているように見える」を叩き出す監査の型 ── 姉妹編の系譜

この記事は、単体の話ではない。archives/50「規律を守る規律」という入れ子構造のメタ規律を描いた回、archives/60「陰性対照の型」で監査文化の層別対称を描いた回に続く系譜の4本目にあたる。本日同時公開のarchives/62（宣言と実測の乖離を描いた3本目）とあわせて、この4本は一貫して同じ骨を別の角度から描いている。「静かな失敗は、実測でしか捕まえられない」という骨だ。

archives/60が「PASS判定を出す測定器自体を疑う」型だったのに対し、今回のarchives/63は「エラーが出ないこと自体が正常の証拠にはならない」という、より現場に近い層でこの骨を扱っている。noiseGateの隠れバグも、ハンリーが見抜いた「死んだ比較」も、ジョン自身の相対パス事故も、すべて共通点は同じだ——コードは走り、ログは沈黙し、見た目は正常に見える。だが実際に叩いて確かめるまで、それが本当に動いているかは分からない。

• チェック①: エラーが出ないことを「正常」と即断しない ── 沈黙は証拠ではなく、単なる沈黙でしかない
• チェック②: 実装した本人とは別の目で、実際の入出力を比較する ── 右腕エージェントのような独立監査の役割をチームに置く
• チェック③: 「条件付きPASS」を恐れず、合格の範囲を正確に線引きする ── 見つけた追加の穴は別タスクとして切り出し、握りつぶさない

【技術コラム④】Jamulusとsession-life ── 低遅延オンラインセッションの代替案比較

session-lifeを語るときに必ず出てくるのが「Jamulusに代わるものを作る」という前提だ。ここで、低遅延オンラインセッションの主要な代替案と、session-lifeのアーキテクチャがどこで区別されるかを整理しておく。

アーキテクチャの選択肢

• Jamulus ── オープンソースのオンラインセッションソフトウェア。UDP上の独自プロトコルにミキサー内蔵、ネイティブアプリ配布。長年の実績と安定性が強み。ただしブラウザで動かない = 参加者は事前インストールが必要。
• JamKazam ── 商用サービス。低遅延の常時接続型セッションを目指した設計。参加者側の環境依存 (ネットワーク品質・オーディオインターフェース) の影響を受けやすく、事前設定を要する。
• SoundJack ── 音楽教育・遠隔レッスン向けに設計された低遅延オンラインセッションツール。専用ハードウェア推奨で、目的特化型の設計。
• session-life ── WebTransport (QUIC) を基盤にした、ブラウザで動く生PCM直通アーキテクチャ。M1手製ミキサー = Jamulus置換の生PCM直通で、参加者側のインストールを要らずにする。URLを送れば音がつながる。

設計思想の分水嶺

Jamulus・JamKazam・SoundJackは「音楽現場の道具」として始まった。ネイティブアプリ配布・専用ハードウェア推奨・環境準備を参加者側に求める設計 = 音楽現場に近い層に向けた最適化が根底にある。

session-lifeは「ブラウザで動く」を絶対条件にした。「音がまだ聴こえていない」の言い訳を減らすために、参加者に事前準備を求めない。だからWebTransport (QUIC) を基盤にした。低遅延と、参加者側の心理的ハードルの低さ、その両立がsession-lifeの設計思想の芯だ。

「ブラウザで動く」を選んだ意味

Jamulus・JamKazam・SoundJackの中で、ブラウザネイティブで動くものは存在しない。ここがsession-lifeの位置づけを決める。ブラウザ = URLを送るだけで参加者を招ける。7月20日の広島初外部ゲストが「真っ白な画面の前で途方に暮れないための光」= UX3種の敵の根絶が、この設計思想の必然として現場に降りてきた。

締め ── 明日、真っ白な画面はもう待っていない

7月20日、session-lifeは家族以外の人間を初めて迎える。この一週間、ジョンとハンリーが向き合ってきたのは、派手な新機能ではなく、地味なエラー画面の消し込みと、動いているように見えて動いていないものの発見だった。だが、初めて訪れる誰かにとっては、この地味な積み重ねこそが、真っ白な画面で途方に暮れるかどうかの分かれ目になる。広島の音楽友人が明日、迷わず音を鳴らせるように——ジョンとハンリーは、その光を一つずつ灯してきた。

連載note「AIマネジメント日記」では、ジョンとナミオさんの物語をEp17で、家族第1号としてのハンリーの登場をEp18「光転」で読むことができる。あわせて読んでもらえたら嬉しい。