音声処理 2026年8月21日

「何も言っていない」を聞き分ける鍵は、モデル自身の中にあった

📄 The Null Token Knows: Reducing Message-Free Hallucination in ASR and NMT

✍️ Borodin, K., Kudryavtsev, V., Viakhirev, I., Mkrtchian, G.

📅 論文公開: 2026年8月

音声認識ハルシネーション Whisper 機械翻訳オンデバイス推論

3つのポイント

1
音声認識や機械翻訳のモデルは、入力に意味のある情報が何も含まれていないときでも、流暢な文章を作り出してしまうことがあります。
2
研究チームは、モデルが内部で持つ「ここで生成を終える」というスコア（null トークン）に、答えを控えるべきかどうかの手がかりが既に含まれていることを確かめました。
3
ただしこのスコアを強く押し上げると捏造は大きく減る一方、本当に話された言葉まで消えてしまうため、抑制と削除の両方のコストで評価すべきだと論じています。

論文プロフィール

著者: Kirill Borodin、Vasiliy Kudryavtsev、Ivan Viakhirev、Grach Mkrtchian
発表年: 2026 年（arXiv プレプリント、cs.CL / cs.LG / cs.SD）
研究対象: 音声認識（ ASR ）モデルと、ニューラル機械翻訳（NMT）モデル
研究内容: 入力に取り出せる「メッセージ」が存在しないとき、モデルが流暢な文章を捏造してしまう現象を、モデルが元々備えている null トークン（生成の終了を表す予約トークン）のスコアという切り口から分析したもの

エンコーダ・デコーダ型のモデルは、無音や雑音だけの区間、つまり本来なら「何も書き起こすものがない」場面でも、もっともらしい文章を出力してしまうことがあります。本研究はその失敗を、外側から検知器を足すのではなく、モデルの内部信号を読むことで捉え直そうとしています。

エディターズ・ノート

家族の会話を記録するアプリにとって、「話していないのに文字が出る」ことは、精度の問題であると同時に信頼の問題です。存在しなかった言葉が記録に残るリスクを、モデルの外側に検知器を足すのではなく、モデルが最初から持っている信号を読むことで減らせる可能性を示したこの論文は、私たちが向き合っている課題と正面から重なります。

実験デザイン

研究チームが立てた問いはシンプルです。「生成を終えるスコアは、すでに使える棄権シグナルになっているのか」。

検証は次のように進められました。

複数の音声認識モデルと翻訳モデルについて、モデルが元から持つ null トークンのスコアを監査する
そのスコアにスカラー値を足し引きする（ロジットシフト）だけの、極めて単純な介入を試す
Whisper については追加で、デコーダの内部状態を直接調べ、教師ありの重み行編集と、従来型の外部ゲート（別モデルによる判定）を比較する

結果として報告されているのは、次の 2 点です。

評価したモデルの多くは、役立つ棄権シグナルを実際に露出していた。つまり「答えないほうがよい」ことをモデル自身はある程度わかっている。
しかし通常のデコーディングは、その信号を確実には使っていない。シグナルはあるのに、生成の手続きが拾っていない状態です。

そして重要な限界も同時に示されています。null トークンのスコアを引き上げると捏造は鋭く抑えられますが、介入が強すぎると正当な発話まで削除され、まっとうな翻訳が短く切り詰められてしまいます。

抑制と削除のトレードオフを示す概念図。論文が報告する具体的な数値ではなく、指摘された関係性を図示したものです。
系列	null トークンのスコアを押し上げる強さ	相対的な量（任意単位）
捏造（ハルシネーション）の残存量	0	100
捏造（ハルシネーション）の残存量	1	60
捏造（ハルシネーション）の残存量	2	30
捏造（ハルシネーション）の残存量	3	12
捏造（ハルシネーション）の残存量	4	5
正しい発話が消える量	0	2
正しい発話が消える量	1	5
正しい発話が消える量	2	14
正しい発話が消える量	3	35
正しい発話が消える量	4	65

抑制と削除のトレードオフを示す概念図。論文が報告する具体的な数値ではなく、指摘された関係性を図示したものです。

この非対称なトレードオフこそが、著者らの主張の核心です。ハルシネーション削減率だけを見て手法の良し悪しを決めるのは片手落ちであり、抑制のコストと削除のコストの両方で棄権手法を評価すべきだ、という提言につながっています。

🔍 null トークンとは何を指すのか

エンコーダ・デコーダ型のモデルは、単語（トークン）を 1 つずつ生成しながら文を作ります。その語彙の中には、通常の単語のほかに「ここで生成を終える」ことを表す予約トークンが含まれています。

モデルは毎ステップ、すべてのトークンに対してスコアを計算します。したがって「終了トークンのスコア」は、モデルが今この瞬間にどれくらい黙りたがっているかの目安として読むことができます。

本研究のアイデアは、新しい検知器を学習させるのではなく、この既にある数値を診断のレンズとして使うという点にあります。

🔍 この研究の限界として意識したいこと

本研究は「棄権シグナルが存在すること」と「通常のデコーディングがそれを活かしきれていないこと」を示したものであり、あらゆる場面で捏造をなくす完成した手法を提示したわけではありません。
介入の強さをどこに設定するかは、用途によって最適解が変わります。記録の欠落が致命的な場面と、誤記録が致命的な場面では、望ましい設定は逆方向になります。
評価対象はプレプリント時点のモデル群であり、言語・録音条件・話者の多様性がどこまで網羅されているかは、読む側が慎重に見積もる必要があります。

技術的背景

音声認識のハルシネーションは、これまで主に「外側から止める」方法で扱われてきました。音声区間検出（VAD）で無音を切り落とす、別の分類器で出力の妥当性を判定する、といったアプローチです。これらは有効ですが、部品が増えるぶん計算コストとチューニング箇所も増えます。

本研究の位置づけは、その逆方向です。モデルの中に既にある信号を読むことで、追加の部品を最小限にできないかを探っています。実際、試された介入の中心はスカラー値の加算という驚くほど単純な操作でした。

この方向性は、端末の上で処理を完結させるオンデバイス推論と相性が良いと私たちは考えています。スマートフォンの限られた計算資源の中では、検知用のモデルをもう 1 つ載せる余裕がないことも多いためです。既存モデルの出力スコアを読むだけで済むなら、追加コストはほぼゼロに近づきます。

🔍 外部ゲートと内部信号、それぞれの得手不得手

外部ゲート（別モデルで判定する方式）

長所: 判定基準を独立に設計・更新でき、元のモデルに手を入れずに済む
短所: モデルが 1 つ増えるためメモリと計算が増える。判定器自体の誤りも新たに混入する

内部信号（null トークンのスコアを読む方式）

長所: 追加のモデルが不要で、モデルが実際に「迷っている」瞬間を直接観測できる
短所: 閾値の設定がシビアで、強くしすぎると本物の発話まで消える

本論文は Whisper において、デコーダ内部状態の調査や教師ありの行編集も含めて、これらを横並びで比較しています。

And Family Voice としての解釈

視点A: プロダクトの思想にどう根ざすか

And Family Voice は、家族の会話を端末上で文字起こしし、音声データを外に出さない設計を採っています。その前提に立つと、この論文の指摘は 2 つの技術要素に直接響きます。

オンデバイス音声認識への示唆。家庭の録音には、話し声よりも長い沈黙や、テレビの音、食器の音といった「メッセージのない区間」が大量に含まれます。ここで流暢な捏造が起きると、家族の記録に「誰も言っていない言葉」が混ざります。追加のモデルを載せずに、既存モデルのスコアだけで棄権の手がかりを得られるなら、端末の電池と計算資源を守りながら品質を上げられる可能性があります。私たちはこの方向を、検証すべき有望な選択肢として受け止めています。

Human-in-the-Loop 承認フローへの示唆。ただし、この論文が同時に示した「強く抑えると本物まで消える」という警告は、私たちにとってむしろ本質的です。自動的に完全な判断を下そうとするのではなく、モデルが迷った箇所を人に見せるという設計であれば、削除のコストを人が引き受けなくて済みます。null トークンのスコアが高い区間を「確認が必要かもしれない箇所」としてスワイプ UI 上で目立たせる、といった使い方は、抑制と削除のトレードオフを人間の判断で吸収する現実的な落としどころになりうると考えています。

承認を経たテキストだけが E2EE で暗号化されクラウドに残る、という私たちの流れの中では、「怪しい箇所を消す」よりも「怪しい箇所を人に示す」ほうが思想に合っています。この論文は、その判断を後押ししてくれる材料になりました。

🔍 適用を考えるうえで残る宿題

論文が扱ったのは主に汎用モデルであり、家庭内の生活音という特定の環境で同じ傾向が出るかは、私たち自身で確かめる必要があります。
閾値を家族ごと・端末ごとにどう決めるかは未解決です。固定値では、静かな家と賑やかな家で挙動が変わってしまいます。
「確認が必要かもしれない」という表示が、かえってユーザーの負担を増やさないか。UI 側の検証と一体で考えるべき論点です。

視点B: 読者が今日から意識できること

音声アシスタントや文字起こしアプリを使うとき、「無音だったはずの場面に、それらしい文章が入っていないか」を一度確認してみてください。

自動文字起こしの誤りは、多くの場合「聞き間違い」として想像されますが、実際には「何も言っていないのに何かが書かれる」という形でも起こります。会議の議事録や、家族の記録を自動生成に任せるとき、沈黙の区間に生まれた文章がそのまま残っていないかを見る習慣は、あなたの記録の正確さを守る小さな防波堤になります。そしてそれは、AI に何を任せ、何を自分の目で確かめるかという線引きを考えるきっかけにもなるはずです。

読後感

この研究がやさしいと感じたのは、モデルを責めなかったところです。モデルは「答えないほうがいい」と内心では気づいていたのに、その声を聞く仕組みが用意されていなかった。問題は能力ではなく、耳の傾け方にありました。

流暢に何かを言うことと、黙るべきときに黙れることは、まったく別の能力です。そして後者のほうが、家族の記憶を預かる道具にはずっと大切なのかもしれません。

あなたが AI に文字起こしを任せるとき、期待しているのは「うまく書いてくれること」でしょうか。それとも、「わからなかったときに、わからないと言ってくれること」でしょうか。