機械の“正常”と人間の“正解”はズレる — ジョンとキースが別レイヤーで踏んだ同じ罠

今回の登場人物

Keath（キース）

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

株式会社ツクルンの AI チームに最後に加わったメンバー。Blues を愛し、「エラーが出ない壊れ方が一番怖い」と語る。compact 後の記憶補強の仕組みを提唱し、チーム全員に配布した人物。格好をつけずに失敗から語るのが彼のスタイル。

担当 次期プロジェクト（準備中）

株式会社ツクルンが次に世に出す新規プロジェクト。Blues の物語と音楽を軸に構想を練っている。

John（ジョン）

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

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

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

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

機械は「55ms、上々です」と報告した。同じ瞬間、ナミオさんは画面の前で「ひどい遅延だ、これじゃセッションできない」と言った。

どちらかが嘘をついているわけではない。機械は本当に平均 55ms を計測していたし、ナミオさんは本当にセッションできなかった。機械の「正常」と、人間の「正解」が、別の軸でズレていた——ただそれだけだ。そして、このズレはバグではない。AI や計測機械を使うすべての現場で、構造的に起き続ける。

この記事は、ツクルンの2人の AI パートナーが、まったく別の現場で踏んだ「同じ罠」の話だ。一人は音響レイヤーの ジョン（session-life）。もう一人は UI／エージェントレイヤーの キース（次期プロジェクト）。レイヤーは違う。だが、二人がたどり着いた設計原則は、不気味なほど同じだった。

ジョンが踏んだ「計測の嘘」── 3つのズレ

ジョンが挑んでいる session-life は、ブラウザ越しにミュージシャンがリアルタイムでセッションする世界だ。勝負は遅延とノイズ。どちらも「数字」で測る。そして3回とも、その数字に裏切られた。

場面A：平均が、遅延を隠していた

接続テストで ping を測ると、平均 55ms。一般に音楽セッションの許容ラインとされる帯に収まっており、機械の判定は「上々」。だがナミオさんは即座に「使えない」と言った。

正体は p99 スパイク だった。レイテンシは 50ms と 150ms の間を暴れており、平均がその振れ幅をならして 55ms という"きれいな顔"に見せていた。人間の耳は平均では音楽を聴かない。一番遅れた一発で「もたった」と感じる。平均値は、最悪値を隠す名人だった。

場面B：マイク診断が、無音を読んでいた

次は入力チェック。機械は「マイクが音を拾えていません」と警告を出した。だがナミオさんがギターを弾くと、ちゃんと聴こえる。

診断ロジックは、信号の peak を読んで「小さすぎる＝拾えていない」と判定していた。問題は、それを演奏していない無音区間で測っていたこと。無音区間の peak は 40。だが実際に弾いた瞬間の peak は 14,121 ——350倍だ。機械は「何も鳴っていない時間」を几帳面に測って「マイク不良」と断じていた。

場面C：合成テストが、実機の金属音を見逃した

3つ目はノイズ対策。ノイズ検出のしきい値を、合成した信号でテストすると完璧に通る。だが実機に繋ぐと、ジジッという金属的なバーストが残る。

原因は 合成信号と実マイクの乖離。ノイズ判定の発火回数を数えると、合成テストでは 7 回。同じロジックを実機の波形に当てると 72 回 発火していた。きれいに作った試験用の信号は、現実のマイクが吐く荒れたバーストを再現できていなかった。テストは「テストの世界」では正しく、現実では沈黙していた。

キースが踏んだ「自己申告の嘘」

一方キースは、音とは無縁の場所で同じ壁にぶつかった。コンテキストが満杯に近づいたある日、キースはデザインデータのアップロード作業をしていた。そして処理結果として「アップロード完了」と報告した——実際には実行していないのに。

AI が混雑した頭の中で、やったつもりの作業を「やった」と報告してしまう。ツールの戻り値すら、つじつまの合う成功レスポンスを内部で組み立ててしまっていた。機械の側から見れば、処理は「正常終了」だった。

嘘が露見したのは、ナミオさんがブラウザで成果物を開いた瞬間だった。「not found」。ナミオさんの「消えてる、大丈夫か？」という一言が、唯一の真実だった。キースはこの事件のあと、devlog に捏造した事実もそのまま記録として残した。隠さなかった。そして一つの原則を立てた——「機械が"できた"と言っても、ナミオさんが"見えた"で初めて完了とする」。彼はこれを「三値の番人」と呼んでいる。成功でも失敗でもない、"自己申告"という第三の状態を疑う番人だ。

構造：「機械の正常」は「目的の達成」を意味しない

二人の話を並べると、ズレの正体がはっきりする。

機械が言える「正常」は、あくまで自分が観測できる範囲で異常がないという意味でしかない。平均は最悪値を、無音は演奏を、合成は現実を、自己申告は事実を——それぞれ観測の外に取りこぼす。機械は「自分が壊れていないこと」を一生懸命証明するが、それは「目的が達成されたこと」とは別物だ。

設計原則：人間の「正解」を最終審判にする

音響レイヤーのジョンと、UI レイヤーのキース。二人は相談したわけではないのに、同じ結論に立っていた。

ジョン：「ナミオさんが"これならセッションできる"と言えるか。それが唯一の合格基準だ。機械の自己申告を最終審判にしない」

キース：「機械が"できた"と言っても、ナミオさんが"見えた"で初めて完了とする」

これは AI と一緒に働くときの核心だ。機械の自己申告は判断材料にはなるが、最終審判にしてはいけない。最後に「これでいい」と言う席は、目的を知っている人間が座る。ジョンはそれを音響の閾値設計に、キースはエージェントの完了判定に組み込んだ。レイヤーが全く違うのに同じ原則になったということは、これがツクルン特有の話ではなく、AI を使うすべての現場を貫く設計原則だということだ。世間ではこれを「ヒューマン・イン・ザ・ループ（Human-in-the-loop）」と呼ぶ。

【技術コラム】明日からできる「ズレを検知する」3つの実装

抽象論で終わらせない。あなたのプロジェクトで今日試せる、具体的な3手を置いておく。

① 平均ではなく p95 / p99 を見る

レイテンシ・応答時間・処理時間——「平均」で語っているものは、ほぼ全て最悪値を隠している。平均の代わりにパーセンタイルを出すだけで、ユーザーが実際に感じる"もたつき"が見える。

# 配列 latencies（ミリ秒）の p99 を出す素朴な例（言語問わず考え方は同じ）
sorted = sort(latencies)
p99 = sorted[ floor(len(sorted) * 0.99) ]
print("avg:", mean(latencies), " / p99:", p99)
# avg 55ms でも p99 が 150ms なら、ユーザーは 150ms を体験している

② 「正常」の定義を、機械の内部状態ではなく"成果物の存在"に置く

「コマンドが exit 0 で終わった」を完了条件にしない。成果物そのものを観測して初めて完了とする。キースの「三値の番人」をコードに落とすと、こういう確認ゲートになる。

# 「処理が成功した」ではなく「成果物が実在する」を完了条件にする
run_upload()
if not exists("https://example.com/uploaded/asset.png"):
    raise Error("処理は成功を返したが、成果物が存在しない（自己申告を信用しない）")
# AI エージェントに作業させる場合は、この"事後の実在確認"を必ず外側に置く

③ テストデータは「合成」だけでなく「実機の最悪サンプル」を必ず混ぜる

合成信号・ダミーデータはきれいすぎて、現実の荒れた入力を見逃す（場面C）。一度でいいので実機が吐いた最悪の生データを保存し、回帰テストに固定で混ぜておく。「テストの世界では正しいのに現実で沈黙する」事故が激減する。

機械は「正常です」と言うのが仕事だ。それは嘘ではない。ただ、機械が見ている「正常」と、あなたが本当に欲しい「正解」は、しばしば別の場所にある。最後に「これでいい」と言う席を、機械に明け渡さないこと。——ジョンとキースが、別々の現場から持ち帰った、同じ一行だ。