AI > 音声 on M1KE BL0G

ビタビアルゴリズム

Tue, 08 Sep 2026 13:00:00 +0900

背景

「pyopenjtalkの仕組み」という記事で、MeCabの形態素解析に使われているビタビアルゴリズムに触れた
ここでは、ビタビアルゴリズムそのものを掘り下げて整理する

ビタビアルゴリズムの起源

Andrew J. Viterbiが1967年に発表した論文Error bounds for convolutional codes and an asymptotically optimum decoding algorithm（IEEE Transactions on Information Theory, vol. 13, pp. 260-269）が出典
元々は、通信における畳み込み符号の復号のために考案されたアルゴリズム
その後、隠れマルコフモデル（HMM）のデコーディング、音声認識、そしてMeCabのような形態素解析まで、幅広い分野に応用されるようになった

マルコフ連鎖と隠れマルコフモデル

ビタビアルゴリズムの背景には、マルコフ連鎖と隠れマルコフモデル（HMM）という考え方がある。

マルコフ連鎖（Markov Chain）

ある時点の状態が、直前の状態だけに依存し、それ以前の履歴には依存しないという性質（マルコフ性）を持つ確率過程
状態の集合と、状態間の遷移確率によって定義される

隠れマルコフモデル（HMM）

マルコフ連鎖に従って遷移する状態の系列が、直接には観測できない（隠れている）というモデル
代わりに、各状態から確率的に出力される観測値だけが観測できる
HMMは、以下の3つの要素で定義される
- 初期状態確率（Initial probabilities, $\pi$）: 最初にどの状態から始まるかの確率分布
- 状態遷移確率行列（Transition matrix, $A$）: ある状態から別の状態へ遷移する確率
- 出力確率（Emission probabilities, $B$）: ある状態にいるときに、特定の観測値が出力される確率
MeCabの形態素解析に当てはめると、品詞や単語といった裏の系列（状態）が直接には観測できず、実際に書かれた表層文字列（観測値）だけが見えている、という構造に対応する

ブルートフォース法との比較

観測系列$O$が与えられたとき、それを生み出した可能性が最も高い状態系列$Q$を求める問題を、デコーディング問題と呼ぶ。

最も素朴な解法は、あり得る全ての状態系列を列挙し、それぞれの尤度を計算して比較するブルートフォース法（総当たり法）
状態数を$N$、系列の長さを$T$とすると、あり得る状態系列の数は$N^T$通りになり、系列が長くなるほど組み合わせが指数的に爆発する
例えば$N=10$、$T=20$でも$10^{20}$通りという非現実的な数になり、実用上は計算できない

ビタビアルゴリズムは、この組み合わせ爆発を避けながら、ブルートフォース法と同じ最適解を多項式時間で求める方法。

動的計画法としてのビタビアルゴリズム

ビタビアルゴリズムの核心は、「未来を全部見る」のではなく「ここまでで一番いい過去だけを持って進む」という考え方。これは動的計画法（Dynamic Programming, DP）の典型例になる。

ある地点に複数の経路で到達できる場合、そこから先の話には、その地点までの累積コストが最小の経路だけが関係する
つまり、同じ地点に到達した経路のうち、負けている経路はその時点で切り捨ててよい
全ての分割パターンを総当たりする代わりに、各地点で最良の経路だけを覚えておくことで、計算量を大きく減らせる

MeCabでの具体例

MeCabの形態素解析を例に、ビタビアルゴリズムの動きを追ってみる。

ラティスの構築

例えば「東京都」という文があったとき、辞書から複数の分割候補が出てくる。

「東京」＋「都」
「東」＋「京都」
「東京都」

MeCabはまず、文の各位置から始まる単語候補を全て並べて、ラティスと呼ばれる網目状のグラフを作る。ラティスの各ノードには、以下2種類のコストが割り当てられる。

単語そのもののコスト（辞書に登録された、その単語らしさを表すコスト）
直前の単語との接続コスト（品詞の並びとしての自然さを表すコスト）

イメージとして、以下のようなラティスができる。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


BOS
 ├─ 東京 (100)
 │ └─ 都 (+50)
 │
 ├─ 東 (200)
 │ └─ 京都 (+300)
 │
 └─ 東京都 (80)
 ↓
 EOS

最小累積コストの計算

ビタビアルゴリズムは、文の先頭（BOS）から順番に、各ノードまでの最小累積コストを、以下の式で計算していく。

$$ C(v) = \min_{u} \{ C(u) + \mathrm{connectionCost}(u,v) + \mathrm{wordCost}(v) \} $$

$C(v)$はノード$v$までの最小累積コスト、$u$は$v$の直前になりうる各ノード。重要なのは、同じ地点に複数の経路で到達したとき、一番安かった経路だけを覚えておけばよいという点。

具体的な計算結果

上の例で言えば、以下のようになる。

「東京」→「都」: 累積コスト150
「東」→「京都」: 累積コスト500
「東京都」: 累積コスト80

このうち「東京都」1語だけの経路が最も安いため、これが採用される。文末（EOS）まで計算した後、EOSから「どのノードから来たか」を逆向きに辿る（バックトラック）ことで、最適な形態素列が得られる。

処理の流れ

MeCabの処理の流れをまとめると、以下のようになる。

辞書から形態素候補を出す
ラティスを作る
各ノードについて最小累積コストを計算する
各ノードについて、最良の直前ノードを記録する
文末から先頭へバックトラックする

HMMにおける一般的な定式化

MeCabのラティスでの定式化は、コストの最小化という形だったが、隠れマルコフモデル（HMM）の文脈では、前述の初期状態確率$\pi$・遷移確率行列$A$・出力確率$B$を使った確率の最大化という形で、同じアルゴリズムが使われる。

まず、時刻1（最初の観測）における各状態の確率は、初期状態確率と出力確率から以下のように求まる。

$$ \delta_1(j) = \pi_j \cdot b_j(o_1) $$

時刻$t$、状態$j$における最良経路の確率$\delta_t(j)$は、以下の漸化式で計算できる。

$$ \delta_t(j) = \max_{i} \left[ \delta_{t-1}(i) \cdot a_{ij} \right] \cdot b_j(o_t) $$

$a_{ij}$は遷移確率行列$A$の要素（状態$i$から状態$j$への遷移確率）、$b_j(o_t)$は出力確率$B$の要素（状態$j$で観測値$o_t$が出力される確率）。

MeCabのコスト最小化は、確率の対数を取って符号を反転させたもの（負の対数尤度）とみなせば、この確率最大化の定式化と本質的に同じ計算になる
ブルートフォース法が全ての状態系列について愚直に尤度を計算するのに対し、この漸化式は各時刻・各状態について直前までの最良値だけを使い回すことで、同じ最適解を効率的に求めている

計算量のメリット

ブルートフォース法とビタビアルゴリズムとでは、計算量に大きな差がある。

文の長さを$n$、各位置での候補数を$k$とすると、全ての分割パターンを総当たりで比較する場合、組み合わせの数は指数的に増えていく
ビタビアルゴリズムでは、各地点で最良の経路だけを保持しながら進むため、計算量は文の長さと候補数にほぼ比例する程度に収まる

全探索を避けながら、最終的には全体最適な経路を見つけられるというのが、動的計画法としてのビタビアルゴリズムの強み。

まとめ

ビタビアルゴリズムは、1967年にAndrew Viterbiが畳み込み符号の復号のために考案した動的計画法
背景には、初期状態確率$\pi$・遷移確率行列$A$・出力確率$B$で定義される隠れマルコフモデル（HMM）がある
素朴なブルートフォース法では状態数$N$・系列長$T$に対し$N^T$通りの組み合わせを比較する必要があるが、「ここまでの最良の経路だけを残しながら進む」ことで、同じ最適解を効率的に求められる
MeCabの形態素解析では、単語コストと接続コストの和を最小化する経路探索として使われている
HMMの文脈では、確率の最大化という形で同じアルゴリズムが使われ、コスト最小化と数学的に対応している
音声認識・通信・形態素解析など、系列の背後にある最適な経路を求める問題に広く応用されている

参考文献

Viterbi, A.J. (1967). “Error bounds for convolutional codes and an asymptotically optimum decoding algorithm.” IEEE Transactions on Information Theory, Vol. 13, pp. 260-269.
Viterbi algorithm - Species and Gene Evolution

G2Pライブラリを作る時に調査した先行文献などのメモ

Thu, 03 Sep 2026 12:00:00 +0900

背景

日本語のG2P（Grapheme-to-Phoneme、漢字仮名交じり文から読みへの変換）ライブラリを自作する機会があった
素朴なG2P（辞書引きベースの変換）は「明日」のような多音字・ヘテロニム（同じ表記で複数の読みを持つ語）を文脈から判定できない
この課題に対して国内外でどんな研究・手法・OSSがあるかを調査した際のメモをまとめておく

ホモグラフとヘテロニムの違い

ホモグラフ（Homograph）は、綴り（表記）が同じ語同士を指す上位概念で、発音が同じか異なるかによってさらに2つに分かれる
- ヘテロニム（Heteronym）: 表記は同じだが発音が異なるもの（例: 英語の"lead"、金属の鉛／導くのlead）
- 狭義のhomonym: 表記も発音も同じもの（例: 英語の"bat"、動物のコウモリと野球のバット）
つまり、ヘテロニムと狭義のhomonymはどちらもホモグラフの部分集合であり、互いに排反（同時には成り立たない）

集合の関係で表すと、以下のようになる。

$$ \text{Heteronym} \subset \text{Homograph} $$

ヘテロニムと狭義のhomonymは排反で、かつ合わせるとホモグラフ全体になるため、以下のように直和で表せる。

$$ \text{Homograph} = \text{Heteronym} \sqcup \text{Homonym}_{\text{narrow}} $$

日本語の「市場」（いちば/しじょう）のように、同じ表記で読みが複数ある語は、英語でいうヘテロニムに相当する
日本語ではこの現象を「多音字」（元は中国語由来の概念）や「同形異音語」と呼ぶことが多く、英語の論文では単に"homograph"と呼ばれることも多い。本メモでは、参照する文献の原語に合わせてホモグラフ・ヘテロニム・多音字を使い分けている

多音字・ヘテロニム判定という問題

例えば「市場」は「イチバ」にも「シジョウ」にも読める
辞書ベースのG2Pはどちらか一方を機械的に返すだけで、文脈による判定ができない
中国語圏では同じ問題が「多音字（Polyphone）」として研究されており、日本語より事例が多い
発想は大きく3つに分けられる
- 候補を絞り込んでから文脈で判定する
- 音声を使って実際の発話から読みを検証する
- 辞書知識を後付けで注入する

pyopenjtalk

日本語のG2P・TTSでデファクトスタンダードになっているpyopenjtalkが実際にどう動いているか、パッケージ内のCythonバインディング定義を読んで確認した。

OpenJTalk

pyopenjtalkの実体は、OpenJTalkという日本語テキスト音声合成エンジンのPythonバインディング
OpenJTalk本体はC/C++で書かれており、テキストを入力すると形態素解析から音声波形の生成までを一貫して行う
pyopenjtalkはこのOpenJTalk本体をCythonでラップし、Pythonから呼び出せるようにしたもの

MeCab

OpenJTalkが内部の形態素解析エンジンとして使っている、汎用の日本語形態素解析器
工藤拓氏によって開発され、単語コスト・連接コストをCRF（条件付き確率場）などの機械学習手法で学習する設計が特徴
単体では辞書を差し替えて使う汎用ツールで、IPAdicやUniDicなど複数の辞書が使われる
OpenJTalkはMeCabのライブラリをそのまま組み込み、辞書だけをTTS用に用意したものに差し替えて使っている
実際にpyopenjtalkに同梱されている辞書一式（sys.dic・matrix.bin・left-id.def・right-id.def・unk.dic・char.bin）のライセンス表記を確認すると、NAIST（奈良先端科学技術大学院大学）の辞書とUniDicの両方の著作権表記が含まれており、これらを元にした辞書が使われている

OpenJTalkの仕組み

テキストから音声波形まで、以下のパイプラインで処理する。

text2mecab: 入力テキストを正規化し、MeCabに渡せる形式に変換
MeCabによる形態素解析: 文をラティス（考えられる分割・品詞の候補を網羅したグラフ構造）として展開し、各形態素の単語コスト（辞書由来）と形態素間の連接コスト（matrix.bin、左右の文脈IDで定義）の合計が最小になる経路を探索する。これが最終的な分かち書き結果になる
mecab2njd: MeCabの出力をNJD（Natural Japanese Dictionary）というノードのリンクリストに変換
njd_set_pronunciation: 辞書に登録された発音をノードにセットする。多音字の読みはここで辞書エントリの値がそのまま採用される
njd_set_digit: 数詞・助数詞の読み処理
njd_set_accent_phrase / njd_set_accent_type: アクセント句の切れ目とアクセント型を規則ベースで付与
njd_set_long_vowel / njd_set_unvoiced_vowel: 長音化・母音の無声化などの音韻規則を適用
njd2jpcommon: NJDを「単語→モーラ→音素」の階層構造に変換し、音声合成エンジン向けのフルコンテキストラベルを生成
htsengine: フルコンテキストラベルと統計モデル（htsvoice）から波形を合成

ポイント:

重要なのは、多音字の読みはMeCabが選んだ辞書エントリの発音フィールドがそのまま使われるという点
文の意味を理解して読みを判定しているわけではなく、あくまで形態素の連接コスト（品詞列としての自然さ）に基づく分割の副産物として、結果的に読みが決まる
したがって「上手」のように品詞そのものが変わる語はある程度読み分けられる
一方、「市場」のように品詞も分割位置も変わらない同形異音語は原理的に判定できない
これが、このメモで挙げた各種の先行研究が対応しようとしている限界そのものにあたる

ビタビアルゴ

MeCabの形態素解析ラティスから最小コスト経路を求める探索に使われている動的計画法
ラティスの各ノード（形態素候補）は、文頭からそのノードまでの累積コスト（辞書の単語コスト＋直前ノードとの連接コスト）を持つ
各位置で、直前になりうる全ノードとの連接コストを比較し、累積コストが最小になる経路だけを残しながら文末まで進む
全経路を総当たりで比較するのではなく、途中の最小コストだけを保持して使い回すため、計算量を抑えられる
実際にpyopenjtalkが使っているMeCabの内部構造体（mecab_node_t）にも、単語コスト（wcost）と文頭からの累積コスト（cost）というフィールドがあり、この累積最小コストの構造がそのままビタビアルゴリズムのDPテーブルに対応している

中国語・多言語の先行研究

多音字判定の研究は、CPP（Chinese Polyphone Prediction）というベンチマークを軸に中国語圏で活発に進んでいる。

手法	出典	要点
g2pW	arXiv:2203.10430（Taiwan AI Labs、Interspeech 2022）	読みの語彙全体を1つの共有出力層にし、対象字ごとにありうる読みだけをハードマスクと条件付きソフト重みで絞り込むConditional Weighted Softmax。CPPでAccuracy 99.08%
Polyphone BERT	arXiv:2207.12089（Interspeech 2022）	g2pWと同時期の中国語多音字BERT。Accuracy 92.1→94.1%とg2pWに劣る
半教師あり学習	arXiv:2102.00621	ラベル無しデータをlexicon-based labelingとentropy-thresholdingで疑似ラベル化。Accuracy 0.864→0.928
Back-Translation型データ拡張	arXiv:2211.09495（APSIPA ASC 2022）	G2Pと逆方向のP2Gを両方学習し、予測の往復一貫性で疑似ラベルを検証
LLM＋外部知識（Ant Group）	arXiv:2312.11920（2023）	多音字判定を分類でなく生成タスクとして解く。辞書からのRetrievalとChatGLM-6Bの組み合わせで、学習データに無い未知の多音字も辞書にあれば予測できる。CPPでAccuracy 99.29%
DLM	ACL Anthology 2024.naacl-long.294（NAACL 2024）	長尾分布対策として、表現学習（自然分布のまま）と分類学習（バックボーン凍結＋低頻度クラス優遇再学習）を分離するDecoupled Learning。CPPでAccuracy 99.07%
Logit Adjustment	arXiv:2007.07314（Google Research、ICLR 2021）	共有softmaxを前提に、推論時または損失関数側でクラス事前確率のlogをロジットから減算し長尾偏りを補正するシンプルな手法
CVTE-Poly	ISCA Interspeech 2023（CVTE社/華東師範大学）	既存CPPベンチマークの誤ラベルと不均衡による精度の過大評価を指摘し、拡張データセットと3種類の評価指標を提案
Dict-TTS	ar5iv 2206.02147（NeurIPS 2022）	辞書の意味表現を注意機構で照合するSemantics-to-Pronunciation Attention。中国語・日本語・広東語で評価したが、日本語だけ大きく精度が悪く、pyopenjtalk等の既存G2Pに劣ると論文自身が明記している

Dict-TTSの結果は興味深く、辞書の意味知識だけに頼るニューラル手法でも、日本語では既存のルールベースG2Pに勝てないという結果になっている。表語文字と表音文字が混在し、音読み・訓読みという体系を持つ日本語特有の難しさが背景にあると考えられる。

日本語特化の先行研究

日本語を直接対象にした研究は中国語ほど多くないが、いくつか重要な先行事例がある。

手法	出典	要点
Sony 日本語TTS front-end	ar5iv 2201.09427（2022）	形態素解析由来の特徴とBERT/Flair埋め込みをBiLSTMに入力し、多音字判定とアクセント推定を同時学習。KyTeaベースライン比でPolyphone Disambiguation +5.7pt
疑似訓練データ×one-shot	言語処理学会2023 B3-5（小林・古宮・新納）	BCCWJの大量疑似データで事前学習し、対象ドメインの正解例を1単語1例だけ追加学習するだけで、全データ学習に近い精度まで到達。「市場」「大勢」などが構造的に難しい語として報告されている
NHK技研 Transformer+BERTハイブリッド	ISCA Interspeech 2024（Kurihara & Sano）	外部辞書から引いた読み・アクセント情報をタグとして文中に埋め込み、Transformerがタグ部分をそのまま素通ししてG2P変換する設計。Open JTalk比で助数詞のCERを16.24%から1.42%まで改善
Sarashina2.2-TTS	arXiv:2606.25369（SB Intuitions、2026）	多音字現象を「読み判定」と「連濁・促音化などの音韻変異」に分けて扱うデータ合成パイプライン。LLMによる文生成、UniDicによる検証、TTSとASRの往復検証を組み合わせ、常用漢字全体に対して約28万件の合成サンプルを生成している
LLMベース日本語G2Pベンチマーク（CyberAgent）	arXiv:2606.22009（Koriyama、Interspeech 2026採択）	30以上のLLMを、形態素解析JSONを出力させるParse modeと全文カナを直接出力させるDirect modeで評価し、OpenJTalkやMeCab等の従来ツールと比較。最良はClaude Opus 4.6（parse mode）でCER 0.52%、従来ツール最良のOpenJTalkは1.03%。LLMは辞書に無い低頻度語に強く、Parse modeがDirect modeを一貫して上回るという知見が得られている
YOMI-Bench	arXiv:2607.00664（Mibayashi, Takamura, Yanaka、2026）	常用漢字から約2,000問の4択選択式ベンチマークを構築し、LLMの漢字読み理解を評価
CC-G2PnP	arXiv:2602.17157（Shirahata & Yamamoto、ICASSP 2026採択）	Conformer-CTCによるストリーミングG2P＋プロソディ予測。CTCデコーダが学習中に書記素と音素の対応を自動学習するため、明確な単語境界を持たない日本語のような言語でも分かち書きに依存せず動作する。入力をチャンク単位で処理し、最小限の先読みでストリーミング推論を実現
All-Words Pronunciation Estimation of Japanese Homographs	Kobayashi, Komiya, Shinnou（NLDB 2024, Springer LNCS 14762、2025年ScienceDirect拡張版）	日本語ホモグラフの「全語」を対象にした読み推定を初めて試みた研究。BERTベースのモデルを、BCCWJの非コアデータに形態素解析器で自動タグ付けした読みラベルで学習し、CSJ（日本語話し言葉コーパス）で評価している
Pronunciation Ambiguities in Japanese Kanji	ACL Anthology CAWL 2023（Wen Zhang, CUNY）	単漢字（複合語ではない）のホモグラフ判定に特化した研究。UD Japanese-GSDとオンライン辞書から100の頻出ホモグラフを抽出し、フィルタリングを経て26語・1,903用例のデータセットを構築。ニューラルネットではなく前後n-gram特徴のロジスティック回帰で判定し、品詞情報は判定にほとんど寄与しないと報告している

非公開の商用モデル（参考記録）

論文やOSSではないが、多音字判定という点で無視できない先行事例としてParakeet社のParayomi v1.0.0がある。

自社の日本語読み推定モデルで、JKYB-Parakeet（後述のベンチマーク）でAccuracy 99.808%を公開している
同ベンチマークでGPT-5.5と同率、Gemini 3.1 Proの99.749%を上回る
Parakeet社自身の説明では、大規模言語モデルのような重いモデルは使わず、外部APIも使わずCPUでも高速に動作するとされている
モデルの重み・アーキテクチャ・学習データ・パラメータ数は公開されておらず、公開されているHugging Face Spaceもフロントエンドのみでバックエンドは非公開
公開情報はZenn記事とベンチマーク数値に限られる

精度そのものは高いが再現性のある手法として参照はできず、あくまで「ここまでの精度が実用レベルで達成可能」という目標値としての位置づけになる。

英語圏のヘテロニム研究

英語の"read"（過去形/現在形）のようなホモグラフも同種の問題として研究されている。

手法	出典	要点
SoundChoice	arXiv:2207.13703（Mila/Concordia、Interspeech 2022）	通常のNLL損失に加えて、ヘテロニムに対応する音素部分だけを切り出して重み付けするヘテロニム損失を導入。ヘテロニム損失ありでAccuracy 82%から87%まで改善している
RAD-TTS Alignerによる自動ラベリング	arXiv:2302.14523（NVIDIA）	音声とテキストのアライメントモデルで、ヘテロニムの各読み候補の音素表現と実際の音声フレームとの距離を計算し、最も近い候補を正解ラベルとして自動採用する。人手ラベリングコストを避けつつデータを増やす手法

学習手法・評価基準に関する研究

多音字判定そのものではなく、長尾分布データの学習や早期打ち切り基準という周辺の学習手法に関する研究も参考になる。

手法	出典	要点
Deep Long-Tailed Learning	arXiv:2110.04596	ロングテール分類のサーベイ論文。集計Accuracyで早期打ち切りを判断すると高頻度クラスに支配されるため、クラスバランス済み指標（macro accuracy／balanced accuracy）を使う方が適切と指摘
Early Period of Training Impacts Adaptation for OOD Generalization	arXiv:2403.15210（2024）	学習初期の動的挙動が、その後のID（学習データと同分布）性能とOOD（分布外）性能の乖離に大きく影響すると指摘。対策としてgradual unfreezing（ULMFiT由来、上位層から段階的に凍結解除する手法）を提案
DoAug	arXiv:2502.11671（2025）	LLMによるデータ拡張で「サンプル数を増やす」ことより「サンプル分布の多様性」を重視する手法。専用のパラフレーザーLLMを多様性志向でファインチューンし、12データセットで平均+10.52%の性能向上
On the Stability of Fine-tuning BERT	arXiv:2006.04884（Mosbach et al., ICLR 2021）	BERTファインチューニングをseedを変えて繰り返すと性能が大きくばらつく問題を分析。従来「破滅的忘却」や「データセットが小さいこと」が原因とされていたが、いずれも説明として不十分であることを示し、実際の原因は勾配消失を招く最適化上の困難であると特定。標準的な学習率（2e-5〜5e-5）より高い学習率（1e-4クラス）は不安定化を招きやすいと報告している

seq2seq型G2P（候補制限型とは異なる系譜）

ここまでの手法の多くは「候補を絞り込んでから分類する」（g2pW系）という設計だが、文字列を直接生成するseq2seq型という別の系譜もある。未登録語にも原理上対応できる一方、現状の公開実装は候補制限型より精度が低い傾向にある。

手法	出典	要点
Seq2Seq G2Pの起源	ISCA Interspeech 2015（Yao & Zweig）	双方向LSTMのseq2seqを英語G2Pに適用した初期研究。この系譜の出発点
KWJA	GitHub（京都大学、ACL 2023 Demo）	形態素解析・正規化・読み推定・見出し語化を統合的にこなす日本語解析器。seq2seqモジュールにはRetrieva社の`retrieva-jp/t5-base-long`／`retrieva-jp/t5-large-long`を採用しているが、CyberAgentのベンチマーク（前述）ではCER 2.52%とOpenJTalk（1.03%）に劣る
ByT5によるG2P	arXiv:2204.03067（Zhu et al.、Interspeech 2022）	バイト単位のByT5が、サブワード分割ベースのmT5より少ないパラメータ数で多言語G2Pの精度を上回ることを示した研究。NVIDIA NeMoのByT5 G2Pの土台になっている
NVIDIA NeMo G2Pモジュール	公式ドキュメント	ByT5 G2P（バイト単位のT5で未知の文字・スクリプトも原理上扱える）とG2P-Conformer（CTC損失で訓練するConformerエンコーダ＋線形デコーダ、ByT5比約1/20のパラメータ数）の2種類を提供
MixedG2P-T5	arXiv:2509.01391（2025）	明示的なG2P規則設計を不要にする（G2P-free）ことを目指した手法。事前学習済みT5を音声の自己教師学習信号でファインチューンし、文字列から直接音声表現へマッピングする。日本語のような漢字・かな混在スクリプト言語を主な対象として想定している

ByT5自体はG2P専用ではなく、汎用のバイト単位T5だが、その後継となるバイト単位言語モデルの系譜もG2Pの設計を考える上で参考になる（いずれもG2Pへの直接応用は未確認、一般的な言語モデルアーキテクチャとして）。

手法	出典	要点
Charformer	arXiv:2106.12672（Tay et al., Google Research/DeepMind、ICLR 2022）	バイト列から「準サブワード」のブロックを、勾配ベースの学習（GBST）でモデル内部で動的にグループ化する仕組み。ByT5のようなバイト単位モデルの「シーケンスが伸びすぎる」弱点を狙った改良で、素のバイト単位Transformerより28〜100%高速化
MEGABYTE	arXiv:2305.07185（Yu et al., Meta AI、NeurIPS 2023）	バイト列をパッチ単位でまとめ、ローカルモデルとグローバルモデルの階層構造にすることで、100万バイト規模の系列でも扱えるようにした設計
Byte Latent Transformer（BLT）	arXiv:2412.09871（Meta FAIR、2024年12月）	バイト列を次バイトの情報量（エントロピー）に応じて動的にパッチ分割する設計。トークン化ベースのLLMと同等の性能を、80億パラメータ・4兆バイト規模のスケーリング実験で確認したと報告している
Multiscale Byte Language Models（MBLM）	arXiv:2502.14553（2025年2月）	MEGABYTEの階層構造を、段数に制限のない一般的なアーキテクチャへ拡張した設計。単一GPUで500万バイトのコンテキストウィンドウでの学習を可能にしている

KWJAが使っているretrieva-jp/t5-base-longのように、日本語事前学習済みT5にはいくつか系統がある。

提供元	主なモデル	学習データ	特徴
sonoisa	`t5-base-japanese`、`t5-base-japanese-mC4-Wikipedia`	Wikipedia・OSCAR・CC-100（約100GB）、mC4+Wikipedia版は約890GB	最も広く使われている日本語T5の1つ。バリエーションが豊富
megagonlabs	`t5-base-japanese-web`	日本語のWebテキスト	語彙サイズ32K（8K版もあり）、Web文書向け
retrieva-jp	`t5-small-short`／`t5-base-medium`／`t5-base-long`／`t5-large-medium`／`t5-large-long`／`t5-xl`	mC4の日本語部分＋日本語Wikipedia（2022年9月時点）	T5 v1.1アーキテクチャ。small〜xlのモデルサイズと、short/medium/longの学習ステップ数（系列長）を組み合わせたバリエーションを提供。KWJAはこの系列を採用

いずれも汎用の日本語T5であり、G2P専用に設計されたものではない。KWJAのように読み推定を含む複数タスクを1つのT5でこなす場合はこうした汎用モデルをファインチューンする一方、ByT5 G2PやMixedG2P-T5のように、そもそもサブワードではなくバイト・文字単位で扱う設計にすることで、日本語特有の未知語・混在スクリプト問題を回避しようとする流れもある。

ハイブリッドG2P設計（規則ベース＋ニューラルの併用）

候補制限型・seq2seq型のどちらでもなく、規則的に決まる部分は軽量な手法に任せ、未知・不規則な部分だけニューラルモデルに回すという設計も、低〜中資源言語のG2P研究では繰り返し見られる。

手法	出典	要点
Fast, Not Fancy	arXiv:2505.12973（EMNLP 2025 Findings）	ペルシャ語のホモグラフ解消。半自動パイプラインでホモグラフ特化データセット（HomoRich）を構築し、ルールベースのeSpeakを改良（HomoFast eSpeak）。ホモグラフ解消精度が約30%向上し、「豊富なデータ×ルールベース」が派手な深層学習単体に必ずしも劣らないと主張
ブルガリア語のFST+seq2seq	（詳細未調査）	FST（有限状態トランスデューサ）で規則的な変換（子音対応・母音変化等）を処理し、seq2seq/LSTMは不規則な部分（アクセント予測等）に限定して使用
タイ語の辞書引き+ニューラルフォールバック	（詳細未調査）	通常は辞書引きで高速処理し、辞書に無い語（OOV）のみニューラルフォールバックに回す。OOV率0.5%、平均レイテンシ0.15ms/発話
Massively Multilingual Neural G2P	arXiv:1708.01464	多言語間の転移学習で低資源言語のG2P精度を底上げ
Multimodal, Multilingual G2P for Low-Resource Languages	ACL Anthology D19-6121	音声データを補助モダリティとして活用するマルチタスク学習
モンゴル語のハイブリッドアプローチ	（詳細未調査）	規則ベース＋統計/ニューラルのハイブリッド設計

「既知・規則的な部分は軽量な手法に任せ、未知・不規則な部分だけ重いモデルに回す」という設計は、パシュト語・タガログ語・リトアニア語などのRNN低資源G2P研究にも共通して見られる。データが潤沢でない言語ほど合理的な設計とされ、逆に英語のような高資源言語では、候補制限・ハイブリッドを介さないフルニューラルのend-to-endが主流になる傾向がある。

手法の見取り図: BERT系・seq2seq系・ハイブリッド系

ここまで挙げた手法をアーキテクチャの系統で整理すると、大きく3つに分かれる。

BERT系（候補制限型・分類ベース）

候補を絞り込んだ上で、BERT等のエンコーダでどれが正解かを分類する設計。

g2pW
yomikata／tsqyomi
Sony 日本語TTS front-end
NHK技研 Transformer+BERTハイブリッド
DLM
Logit Adjustment
CVTE-Poly

seq2seq系（文字列を直接生成）

候補を絞らず、文字列から読みを直接生成する設計。未登録語にも原理上対応できる一方、現状の公開実装は候補制限型より精度が低い傾向にある。

Seq2Seq G2Pの起源（Yao & Zweig）
KWJA
ByT5によるG2P
NVIDIA NeMo G2Pモジュール
MixedG2P-T5

ハイブリッド系（規則ベース＋ニューラルの併用）

規則的に決まる部分は軽量な手法に任せ、未知・不規則な部分だけニューラルモデルに回す設計。低〜中資源言語で繰り返し見られるパターン。

Fast, Not Fancy（HomoFast eSpeak）
ブルガリア語のFST+seq2seq
タイ語の辞書引き+ニューラルフォールバック
モンゴル語のハイブリッドアプローチ

どちらにも分類しづらい例外

LLM生成型（Ant Group、CyberAgentのLLMベンチマーク）: 広い意味ではseq2seq（生成）寄りだが、専用に学習した小型モデルではなく汎用LLMをプロンプトで使う点が異なる
furigana_whisper_small_jsut: テキストではなく音声を条件に使うWhisperベースのseq2seqで、入力モダリティが他と異なる

2系統の境界は実は曖昧

BERT系とseq2seq系は、設計思想としては対照的だが、どちらも辞書知識を使って出力を制約できるという点では収束する。

BERT系（g2pW）は、対象語ごとにありうる読みだけを残すハードマスクで、共有出力層の分類先を辞書から絞り込んでいる
seq2seq系でも、デコーダの各生成ステップで辞書に無い文字列を候補から除外する制約付きデコーディング（lexically constrained decoding）を使えば、同じように辞書で出力を絞り込める
つまり「候補を絞ってから分類するか、生成しながら絞り込むか」という違いであって、辞書知識を使うこと自体は両系統に共通する選択肢
逆に言えば、seq2seq系の最大の弱点である未知語へのハルシネーション（辞書に無い読みをもっともらしく生成してしまう問題）も、制約をかければ候補制限型と同じ土俵に戻ってきてしまうため、seq2seq本来の強み（辞書に無い語にも対応できること）とのトレードオフになる

OSS・公開モデル

名称	概要
pyopenjtalk	OpenJTalkのPythonバインディング。辞書ベースのルールベースG2P
yomikata	ファインチューン済みBERTによる同形異音語判定ライブラリ
tsukumijima/pyopenjtalk-plus	pyopenjtalk拡張版。ヘテロニム判定モデル（tsqyomi）を同梱
modernbert-ja（SB Intuitions）	ModernBERTアーキテクチャの日本語版事前学習モデル群
CharsiuG2P	多言語対応のG2Pツール
furigana_whisper_small_jsut（Parakeet Inc.）	Whisperのプロンプトに書記素列を挿入し、Decoderのみをファインチューンして実際に発話された音素列を出力するモデル。音声を条件に使う点が特徴だが、公開小モデル単体の精度は限定的で、MeCabのN-best読み候補との編集距離でフィルタリングする運用が前提になっている。元記事はZenn
pykakasi	かな漢字文からローマ字/ひらがな変換。文脈依存の読み分けは無い
SudachiPy / fugashi / nagisa / Janome	形態素解析器。分かち書きを担うツール群で、多音字判定そのものは解決しない
Juman++（京都大学）	形態素解析器。RNN言語モデルで単語列の意味的妥当性を考慮するのが特徴。Apache-2.0。出力に読み情報を含むが、辞書ベースの読みを返す点は他の形態素解析器と同様で、文脈依存のヘテロニム判定に特化した機能ではない

日本語NLP全般のcuratedリストであるtaishi-i/awesome-japanese-nlp-resourcesも一通り確認したが、上記に挙げた以外で多音字・ヘテロニム判定に直接効く新規のツールは見当たらなかった。

辞書

候補生成器の辞書側（表記にどんな読みがあり得るか）を補強する語彙辞書群。文脈に応じた読みの判定はしておらず、あくまで候補の網羅性を上げるためのデータになる。

名称	ライセンス	概要
JMdict	CC BY-SA 4.0	日本語の一般語彙辞書。見出し語・読み・英語訳
JMnedict	CC BY-SA 4.0	人名・地名などの固有名詞辞書
KANJIDIC2	CC BY-SA 4.0	漢字ごとの音読み・訓読みデータベース
SudachiDict（small/core/notcore）	Apache 2.0	形態素解析器Sudachiの辞書。見出し語・品詞・読みカナなど
UniDic-cwj 3.1.0（国語研）	GPL v2.0／LGPL v2.1／New BSD選択制	現代書き言葉UniDic。MeCab等の形態素解析器で使われる辞書
Mozc辞書（dictionary_oss）	コード本体はBSD-3、辞書の中身はIPAdic系	Google日本語入力（Mozc）の辞書。IPAdic＋沖縄辞書由来
jmdict-furigana	CC BY-SA 4.0（JMdict/JMnedict由来）	JMdict/JMnedictの見出し語について、複合語内の各漢字がどの仮名に対応するかを機械的に算出したデータ
huriganacorpus-ndlbib（国立国会図書館）	CC BY 4.0	全国書誌（図書・雑誌タイトル）の分かち書き＋振り仮名。人名・地名・書名など固有名詞の読みカバレッジに強い

JMdict・JMnedict・jmdict-furiganaなどはCC BY-SA 4.0のShare-Alike条件があり、派生データやモデルを外部公開する場合は帰属表示・同一ライセンス継承が必要になる点に注意。UniDic-cwjもNew BSD選択時に「営利目的利用は要問い合わせ」という注記があり、商用利用前の確認が推奨される。

データセット・ベンチマーク

名称	概要
jvs_nonpara_kana	JVS nonpara100への手動カナ読み注釈3,000文
Joyo-Kanji-Yomi-Benchmark（JKYB）	常用漢字読みベンチマーク原典
Joyo-Kanji-Yomi-Benchmark-Parakeet-Edition（JKYB-Parakeet）	JKYB拡張版、4,512組×3文=13,536文
NDL「読みの基準（2021年1月）」別紙5	国立国会図書館による日本語読みの標準化基準
ku-nlp/WikipediaAnnotatedCorpus（京都大学言語メディア研究室）	日本語Wikipedia記事に形態素解析・固有表現・係り受け・述語項構造・共参照のアノテーションを付与したコーパス。KNP形式で、読みが形態素ごとに個別付与されている点が特徴。CC BY-SA 4.0、約9,419文
KWDLC（Kyoto University Web Document Leads Corpus）	ウェブ文書冒頭3文からなるコーパス。WikipediaAnnotatedCorpusと同じアノテーション仕様（形態素の読み・固有表現・係り受け・述語項構造・共参照・談話関係）。約5,000文書・15,000文。ライセンスは明記されておらず学術研究目的での公開
ROHAN（森勢将雅、日本音響学会誌2023）	モーラバランス型日本語テキストコーパス。常用漢字と読みを全て含み、出現頻度の低いモーラもカバーするよう設計された4,600文。22のサブセットから構成。CC0（パブリックドメイン）
jsut-label	JSUT corpus（BASIC5000サブセット）に対する、手動アノテーションのHTS形式音韻・韻律コンテキストラベル。読み・かな表記も付属。CC BY-SA 4.0
ITAコーパス	朗読・感情表現用に設計された424文（recitation 324＋emotion 100）。漢字仮名交じり文＋ふりがな＋カナ表記付き。パブリックドメイン（Unlicense）
huriganacorpus-aozora（国立国会図書館）	青空文庫（著作権保護期間満了作品）1,944作品に振り仮名を注釈したコーパス。形態素単位で入力文字列・振り仮名・種別を記載。パース後約4,900万文字。近代文学・翻訳文学中心で現代口語とはドメインが異なる点に注意。Public Domain Mark
hurigana-speech-corpus-aozora（国立国会図書館）	青空文庫振り仮名注釈付き音声コーパスver.2。3,632作品・4,892時間の音声を含む（フル71.58GB）が、テキスト・CSVのみの抽出も可能。428万レコード、約8,000万文字。Whisper音声認識由来の読み推定のためsilver-quality（ノイズあり）。Public Domain Mark
katsukiono/kana-kanji-context	日本語版WikipediaのダンプをMeCab+UniDicで形態素解析し、かな表記の位置と前後最大30字の文脈から漢字候補を対応付けた大規模データセット。7,727万7,970件、約7.4GB、JSONL形式。同音異義語判別や文脈依存の漢字推定に使える。CC BY-SA 4.0
Tatoeba	多言語の例文コーパス。日本語文は248,896件、CC BY 2.0 FR。読みのアノテーションは無いが、常用漢字表付表のように文脈に関係なく読みが1つに固定されている語であれば、対象語を含む実例文をそのまま抽出するだけで学習データに使える

同じ京都大学系列のKyotoCorpus（1995年毎日新聞約4万文への構文注釈、読みも付与）も読み付きコーパスとして存在するが、原文は毎日新聞1995年版CD-ROMを別途入手する必要があり、GitHub上ではアノテーション情報のみが公開されているため、手軽に使えるデータではない。

まとめ

ルビ、辞書、点字、音声と漢字の読み方に対するヒントは結構多かった
多音字・ヘテロニム判定の海外研究は中国語（CPPデータセット）が主戦場で、g2pWのConditional Weighted Softmaxが1つの到達点
その後もLLM活用、長尾分布対策、評価指標の精緻化という方向で改良が続いている
日本語特化の研究は数が少なく、Sony、NHK技研、Sarashina2.2-TTS、CyberAgentのLLMベンチマークが主な直接的先行事例
発想は「候補を絞り込んでから文脈で判定する」「音声を使って読みを検証する」「辞書知識を後付けで注入する」の3つの軸に大別できる
辞書の意味知識だけに頼る手法は日本語では既存のルールベースG2Pに劣るという報告もあり、既存G2Pの出力を文脈で補正するアプローチの妥当性を支持する結果が多い

音声の基礎

Thu, 27 Aug 2026 12:00:00 +0900

背景

音声処理まわりの記事を書く機会が増えてきた
その土台となる「音そのもの」の基礎を、ここで一度整理したメモ

音とは何か

音の正体（空気の振動）

音源が振動すると、その振動が空気の疎密波（縦波）として周囲に伝わっていく現象が音
音源から出た振動が、空気の分子を押したり引いたりしながら伝播していく
空気のような媒質が必要なので、真空中では音は伝わらない

波の基本要素

振幅（Amplitude）: 波の大きさ。音の大きさ（音量）に対応する
周波数（Frequency）: 1秒間に振動する回数。単位はHz（ヘルツ）。音の高さ（ピッチ）に対応する
波長（Wavelength）: 1周期分の波の長さ。周波数と音速から決まる

$$ \lambda = \frac{v}{f} $$

$\lambda$が波長、$v$が音速、$f$が周波数
位相（Phase）: 波が今どの位置（山・谷のどこ）にいるかを表す

可聴域

人間が聞き取れる周波数は、おおよそ20Hz〜20,000Hz（20kHz）程度
年齢とともに、高音域が聞き取りにくくなっていく
会話音声の情報は、主に100Hz〜8kHzあたりに集中している

アナログからデジタルへ

サンプリング（標本化）

連続的なアナログ波形を、一定間隔で区切って数値の列に変換する処理
サンプリング周波数（サンプルレート）: 1秒間に何回サンプリングするか。8kHz・16kHz・44.1kHz（CD音質）・48kHzなどがよく使われる
サンプリング定理（ナイキストの定理）: 元の波形を正しく復元するには、含まれる最大周波数の2倍以上のサンプリング周波数が必要
- 例えば、20kHzまでの音を正しく扱うには、44.1kHz以上のサンプリングが必要（CD音質が44.1kHzなのはこれが理由）
サンプリング周波数の半分の周波数をナイキスト周波数と呼び、それを超える周波数成分は正しく記録できない（エイリアシングという歪みの原因になる）

量子化

サンプリングした各点の振幅を、有限のビット数の数値に変換する処理
ビット深度: 16bit（$-32768$〜$32767$）・24bit・32bit floatなどがよく使われる
ビット深度が大きいほど、表現できる音量の分解能が高くなり、量子化誤差（量子化ノイズ）が小さくなる

PCM

サンプリングと量子化だけで作られた、圧縮のない生のデジタル音声データ
WAVファイルなどの基本フォーマットになっている

ADCとDAC

ADC（Analog-to-Digital Converter、A/Dコンバータ）: 前述のサンプリング・量子化を、実際にハードウェアとして行う部品
- マイクが拾った連続的な電気信号（アナログ）を、一定間隔で区切って数値化し、PCMのようなデジタルデータに変換する
DAC（Digital-to-Analog Converter、D/Aコンバータ）: ADCの逆で、デジタルデータ（PCMのサンプル列）を、連続的な電気信号（アナログ）に戻す部品
- この電気信号がスピーカーやヘッドホンを物理的に振動させ、実際の音になる
録音の流れ: マイク（音→電気信号）→ ADC（電気信号→デジタルデータ）→ PCMなどとして保存・処理
再生の流れ: PCMなどのデジタルデータ → DAC（デジタルデータ→電気信号）→ アンプ・スピーカー（電気信号→音）
後述のリングバッファは、ちょうどこのADC/DACと、CPU上で動くソフトウェアとの間をつなぐ役割を果たしている
サウンドカードやオーディオインターフェースの性能でよく話題になる「ビット深度」「サンプリング周波数」「S/N比」なども、実質的にはこのADC/DACの変換精度に関する話

音の大きさを表す指標

RMSエネルギーとは

波形のエネルギー（音量）を表す、最も基本的な指標の1つ
一定区間の波形のサンプル値を2乗して平均し、平方根を取ったもの

$$ \text{RMS} = \sqrt{\frac{1}{N}\sum_{i=1}^{N} x_i^2} $$

$x_i$がその区間の$i$番目のサンプル値、$N$がサンプル数
音量が大きいほど値も大きくなる、直感的にわかりやすい指標
後述のdBは、このRMS（やパワー、振幅）を対数スケールに変換したもの。「RMSを計算してから、dBに変換する」という流れになることが多い

デシベル（dB）とは

音の大きさ（パワーや振幅の比）を対数スケールで表す単位
パワー比の場合、以下の式で表される

$$ \text{dB} = 10 \log_{10}\left(\frac{P}{P_{\text{ref}}}\right) $$

$P$が測定対象のパワー、$P_{\text{ref}}$が基準となるパワー
人間の聴覚は、音の大きさを線形ではなく対数的に感じる（音のパワーが10倍になっても、感覚的には「少し大きくなった」程度にしか感じない）ため、dBのような対数スケールの方が感覚に合いやすい

dBFS（dB Full Scale）とは

デジタル音声で使われる、基準の取り方が特殊なdB
基準$P_{\text{ref}}$を「そのビット深度で表現できる最大振幅（クリッピング直前の値）」に取る
そのため、0dBFSが表現できる最大値で、実際の音声データはほぼ常にそれより小さい負の値（例: -20dBFS、-40dBFS）になる
アナログの音圧レベル（dB SPL）のような絶対的な物理量ではなく、「そのデジタルシステムの上限からどれだけ離れているか」という相対値である点に注意

SNR（Signal-to-Noise Ratio）とは

欲しい信号（音声など）の強さと、それ以外のノイズの強さの比率
通常dBで表す

$$ \text{SNR(dB)} = 10 \log_{10}\left(\frac{P_{\text{signal}}}{P_{\text{noise}}}\right) $$

値が大きいほど、信号がノイズに対してクリアに聞こえる（SNRが高い＝綺麗な音）
値が小さい、あるいはマイナスだと、ノイズに埋もれて聞き取りにくくなる
音声認識やVADの文脈では、マイクに近い目的話者ほど音量が大きくSNRが高くなりやすく、遠くの背景話者ほど音量が小さくSNRが低くなりやすい、という前提で距離のフィルタ代わりに使われることがある

ノイズとノイズフロア

ノイズとは

欲しい信号（音声など）に対して、不要に混ざり込む音や信号成分
種類の例
- 環境音: 暗騒音（部屋や屋外の背景の音）、空調音、風切り音など
- 電気的なノイズ: マイクやアンプなど、回路自体が生み出す熱雑音（サーマルノイズ）など
- 量子化ノイズ: 量子化の際に生じる誤差（後述）
ホワイトノイズ: 全ての周波数帯域に渡って、均等なパワーを持つノイズ
ピンクノイズ: 周波数が高くなるほどパワーが下がる（1/fの性質を持つ）ノイズ。自然界の音に近いとされる

ノイズフロアとは

マイクや録音機材、伝送路などの系が常に持っている、最低限のノイズレベル
「フロア（床）」という名前の通り、それより下には信号を検出できない下限のライン、というイメージ
ノイズフロアより小さい信号は、ノイズに埋もれてしまい、検出も区別もできなくなる
前述のSNRは、言い換えると「信号のレベルと、このノイズフロアとの差（比）」を表している指標

量子化ノイズフロア

ビット深度によって生じる、量子化そのものに起因するノイズフロア
ビット深度を$b$（ビット数）としたとき、理論上のダイナミックレンジ（表現できる最大音量と、量子化ノイズフロアとの比）は、以下の式でおおよそ求まる

$$ \text{SNR}_{\max} \approx 6.02b + 1.76 \ \text{dB} $$

例えば16bitなら、理論上のダイナミックレンジは約98dB
ビット深度を上げるほど、量子化ノイズフロアが下がり、より小さい信号まで正しく表現できるようになる

ノイズ抑制・音声強調（Speech Enhancement）

録音した音声からノイズを取り除き、目的の音声だけをクリアにする技術
古典的な手法として、スペクトル減算（背景のノイズだけの区間からノイズのスペクトルを推定し、音声全体のスペクトルからそれを差し引く）などがある
近年はディープラーニングを使い、ノイズを含む音声からクリーンな音声への変換を直接学習する手法が主流になっている
前述のVAD（音声区間検出）や、複数の話者の声を分離する音源分離とも関連が深い技術領域

音声ファイルフォーマット

非圧縮: WAVなど。PCMのデータをそのままファイルに入れたもの
可逆圧縮: FLACなど。ファイルサイズは小さくなるが、展開すれば元のデータと完全に一致する
非可逆圧縮: MP3・AACなど。人間の聴覚特性を利用して、聞こえにくい成分を削ることで大きく圧縮する。一度削った情報は元に戻せない

周波数領域で見る

時間領域と周波数領域

波形をそのまま表示したもの（時間領域の表現）では、どんな高さの音がどれくらい混ざっているかが分かりにくい
フーリエ変換を使うと、波形を「どの周波数の成分がどれだけ含まれているか」という周波数領域の表現に変換できる

FFT（高速フーリエ変換）

離散フーリエ変換（DFT）を高速に計算するアルゴリズム
音声処理では、一定区間（フレーム）ごとの周波数成分を計算するのに使われる

STFTとスペクトログラム

音声は時間とともに周波数成分が変化していくので、全体を一度にFFTするのではなく、短い時間窓（フレーム）に区切って、それぞれにFFTをかける
この手法をSTFT（短時間フーリエ変換）と呼ぶ
STFTの結果を、時間×周波数×パワーの2次元画像として可視化したものがスペクトログラム
フレームを切り出す際は、端で波形が不連続にならないよう、窓関数（Hann窓など）をかけてから変換するのが一般的

フレームサイズとホップサイズ

STFTでは、波形を切り出すフレームの長さ（フレームサイズ、窓長）と、次のフレームへどれだけずらすか（ホップサイズ、シフト幅）を決める必要がある
フレームサイズが短いほど、いつ変化が起きたかを細かく捉えられる（時間分解能が高い）が、その分、周波数の細かい違いを見分けにくくなる（周波数分解能が低い）
逆にフレームサイズを長くすると、周波数分解能は上がるが、時間分解能が下がる
この2つはトレードオフの関係にあり、両方を同時に高めることはできない
音声処理では、20〜30ms程度のフレームサイズが、声の性質が変化する速さとよく合うため、よく使われる
ホップサイズは、フレームサイズの半分程度（50%オーバーラップ）にすることが多く、フレーム同士を重ねることで変化を滑らかに追えるようにする

具体的な計算例

例えば、サンプルレート16,000 Hz・フレーム長20 ms・サンプル幅16bit（2byte）という、音声処理でよく使われる設定を考える。

1フレームに含まれるサンプル数: $16000 \times 0.020 = 320$サンプル
1フレームのバイト数: $320 \times 2 = 640$byte（FRAME_BYTES = 640 byte）

つまり、この設定では20msごとに640byteのデータを1フレームとして処理することになる。

位相の扱い

STFTの結果は、各周波数成分について振幅（大きさ）と位相（波のタイミングのずれ）の両方の情報を持っている
しかし、スペクトログラムやlog-melスペクトログラム、MFCCなど、多くの音声処理の入力表現では、振幅（パワー）の情報だけを使い、位相の情報は捨てることが多い
理由の一つは、人間の聴覚が位相のズレには比較的鈍感で、主に振幅（周波数ごとのエネルギー分布）で音を知覚しているとされるため
ただし、音声を波形に「戻す」処理（音声合成、ボコーダーなど）では位相情報が必要になる。振幅だけから位相を推定し直すGriffin-Limアルゴリズムのような手法もある

メル尺度（Mel scale）とは

人間の聴覚は、低い周波数の変化には敏感だが、高い周波数になるほど変化を感じにくくなる
この人間の知覚特性に合わせて周波数を変換した尺度がメル尺度で、以下のような式で変換する

$$ m = 2595 \log_{10}\left(1 + \frac{f}{700}\right) $$

$f$が実際の周波数（Hz）、$m$がメル尺度上の値
低周波数では実周波数とほぼ線形の関係になり、高周波数になるほど圧縮されていく
700と2595という定数は、理論から導かれたものではなく、「1000Hzの音＝1000mel」という基準点を通るように、心理音響実験のデータへ対数カーブをフィットさせた近似式のパラメータ

log-melスペクトログラムとは

音声をSTFTでスペクトログラムにした後、周波数軸をメル尺度に沿ったフィルタバンク（メルフィルタバンク、通常20〜80程度）でまとめ、さらにdB（対数）に変換したもの
音声認識・話者認識・音声合成など、ディープラーニングを使う音声モデルで、生波形の次によく使われる入力表現

MFCC（Mel-Frequency Cepstral Coefficients）とは

log-melスペクトログラムに、さらにDCT（離散コサイン変換）をかけて得られる係数
DCTによって、隣り合うメルバンド同士の相関（情報の重複）を取り除き、少ない次元（通常12〜13次元程度）に情報を圧縮できる
音声認識・話者認識で長年使われてきた定番の特徴量
近年はディープラーニングの発展により、DCTで圧縮する前のlog-melスペクトログラムをそのまま入力に使うケースも増えている
- 次元圧縮の仕方を人間が設計するより、ニューラルネットワーク自身に学習させた方が精度が良いことが多いため

モノラルとステレオ

チャンネル数: 1本のマイクで録音したものがモノラル、2本（左右）で録音したものがステレオ
音声認識・VADなどの処理では、扱いを単純にするため、まずモノラルに変換してから処理することが多い

リアルタイム音声処理とバッファ

なぜバッファが必要か

オーディオのハードウェア（前述のDAC・ADC）は、決まった一定のクロックで動いていて、待ってくれない
- 例えば48kHzなら、1秒間に48000回、絶対に休まず一定間隔でサンプルを出し入れし続ける
一方、ソフトウェア（アプリ、OS）はCPUのスケジューリングで断続的にしか動けない
- 他のプロセスに割り込まれたり、処理に時間がかかったりする
この「常に一定で待たないハードウェア」と「断続的にしか動けないソフトウェア」のギャップを埋める緩衝材が、バッファ

リングバッファの仕組み

バッファの実態は、「リングバッファ（円環状の配列）」というデータ構造になっていることが多い
一定サイズのメモリ領域に、「書き込み位置（write pointer）」と「読み込み位置（read pointer）」という2つのポインタを置き、端まで行ったら先頭に戻る

再生（出力）の場合は、以下のような流れになる。

アプリが計算した音のサンプルを、バッファの書き込み位置に順番に詰めていく
ハードウェアのクロックが「次のサンプルをくれ」というタイミングで、バッファの読み込み位置からサンプルを取り出し、スピーカーへ物理的に出力する
読み込み位置が書き込み位置に追いついてしまう（アプリがまだ次のデータを用意できていないのに、ハードウェアがデータを要求してくる）と、渡せるデータがなくなる。これが後述のunderrun
そのため、書き込み位置は読み込み位置より少し「先」を進めておく必要があり、この先行分がそのまま遅延（レイテンシ）になる

録音（入力）の場合は、この逆になる。

ハードウェア（マイク）が一定クロックでサンプルを取り込み、バッファの書き込み位置に詰めていく
アプリが定期的に読み込み位置からデータを取り出して処理する
アプリの処理が遅れて、書き込み位置（ハードウェア）が読み込み位置（アプリ）に追いついてしまうと、まだ読んでいない古いデータが上書きされて消える。これが後述のoverrun

Linuxの音声システム

PulseAudio

Linuxで長く標準的に使われてきたサウンドサーバー
ALSA（カーネルレベルのオーディオドライバ）とアプリケーションの間に入り、複数アプリの音をミキシングしたり、アプリごとの音量調整、ネットワーク越しの音声出力などの機能を提供する
「どのアプリの音を、どのスピーカー/マイクに出し入れするか」をOSレベルでルーティングする役割を持つ

PipeWire

PulseAudio（コンシューマ向け）とJACK（プロ向けの低遅延オーディオ）の両方を置き換えることを目指した、より新しいサウンドサーバー
Fedora、Ubuntu（22.10以降）など主要ディストリビューションで標準になりつつある
PulseAudio互換レイヤーを持っているため、既存のアプリはそのまま動くことが多い
低遅延が求められる音楽制作や、後述のリアルタイム処理の要件にも対応できるよう設計されている

xrun（アンダーラン・オーバーラン）

前述のリングバッファで、読み込み位置と書き込み位置の関係が崩れ、音が途切れたり、プチプチというノイズが乗ったりする現象
underrun: 再生時、読み込み位置が書き込み位置に追いついてしまい、渡せるデータがなくなる状態
overrun: 録音時、書き込み位置が読み込み位置に追いついてしまい、未読のデータが上書きされて失われる状態
CPU負荷が高い、バッファサイズが小さすぎる、スレッドの優先度設定が適切でない、などが主な原因

クオンタム（Quantum）

PipeWireやJACKで、1回の処理サイクルで扱うサンプル数（バッファサイズ）のこと
クオンタムが小さいほど遅延（レイテンシ）は小さくなるが、その分処理が間に合わなくなりやすく、前述のxrunが起きやすくなる
逆にクオンタムを大きくすると、遅延は増える代わりに安定して処理できる
レイテンシは、おおよそ以下の関係になる

$$ \text{レイテンシ} = \frac{\text{クオンタム}}{\text{サンプリング周波数}} $$

声の音響的な仕組み

周期波・基音・倍音

声のような周期的な音（周期波）は、単一の周波数の波ではなく、複数の周波数成分が重なり合ってできている
そのうち、最も低い周波数の成分を基音（fundamental tone）と呼ぶ
基音の整数倍の周波数を持つ成分を倍音（harmonic/overtone）と呼ぶ

$$ f_n = n f_0 \quad (n = 1, 2, 3, \dots) $$

$f_0$が基音の周波数、$f_n$が$n$番目の成分の周波数
$n=1$が基音そのもの、$n \geq 2$の成分を倍音と呼ぶ
用語の注意点: 英語の"harmonic"には基音自体を含めて数える流儀（1st harmonic＝基音そのもの）もあるが、日本語の「倍音」は基音を含めず、その上に乗る成分だけを指すことが多い。この記事では後者に合わせ、基音と倍音を別のものとして扱う

例えば、基音が200Hzの場合、以下のようになる。

基音: 200Hz
倍音: 400Hz、600Hz、800Hz…

倍音は必ず基音の整数倍になるので、隣り合う成分同士の周波数の間隔は、常に基音の周波数と等しくなる。

1
2
3
4
5
6


200 400 600 800 1000 Hz
 │ │ │ │ │
基音 倍音① 倍音② 倍音③ 倍音④
 └─200Hz─┴─200Hz──┴─200Hz──┴─200Hz──┘
 ↑
 間隔 = f₀

基本周波数（F0）

声帯が1秒間に振動する回数が、そのまま基音の周波数＝基本周波数（F0）になる
例えば、声帯が1秒間に100回振動していれば、F0は100Hz
F0が高いほど「高い声」、低いほど「低い声」に感じる
実際の声には、F0（基音）だけでなく、その整数倍の倍音も同時に含まれている（前述の周期波の構造そのもの）
F0は、声の「音程・ピッチ」に強く関係する要素

有声音・無声音

声帯を振動させて出す音を有声音（voiced sound）、声帯を振動させずに出す音を無声音（unvoiced sound）と呼ぶ
母音（あ・い・う・え・お等）は基本的に有声音で、周期的な波形になり、F0（基本周波数）を持つ
子音には、有声のもの（例: 日本語の「が」「だ」「ば」行など）と、無声のもの（例: 日本語の「さ」「た」行や「か」行の一部など）がある
無声音では声帯が振動しないため、口や喉の狭めを通る空気の乱流に近い、ノイズのような波形になる。周期性がなく、F0を持たない
この違いは、前述のZCR（無声音でZCRが高くなりやすい）や、F0が検出できるかどうかを使って、機械的に判定できる

共鳴と声道

共鳴（きょうめい）: 同じ振動数を持つ別の物体がその影響を受けて一緒に揺れ動き、音が大きくなる現象。物体固有の振動数（固有振動数）で発生する
声道（せいどう）: 声帯から口唇（くちびる）や鼻孔に至るまでの空気の通り道（空洞部分）
共鳴は、この声道の形状によってもたらされる。例えば「ア」と「イ」では、声道の形状が大きく異なる
「ア」を高い声・低い声で出し分けるのは、声道の形（共鳴のしかた）はそのままに、音源（声帯振動＝F0）の周波数だけを変えているということ

フォルマント

基音・倍音を含む声の周波数成分のうち、声道の共鳴によって特に強められた周波数帯を、フォルマント（formant）と呼ぶ
フォルマントは、低い方から順に第一フォルマント（F1）、第二フォルマント（F2）…と呼ばれる
母音は声道の形（＝共鳴のしかた）によって特徴づけられるため、フォルマントは声の「母音・声質」を強く反映する
- F0が「音程・ピッチ」に対応するのに対し、フォルマント（F1、F2…）は「どの母音か・どんな声質か」に対応する
音響分析では特にF1とF2の2つに注目することが多く、多くの言語で母音の音響的特徴はこの2変数でおおよそ捉えられる

横長の黒い帯のように見えるのが、フォルマント。母音によって異なる周波数に現れる

Praatでフォルマントのピークを自動検出し、赤いドットでプロットしたもの
各母音において、一番下の赤線が第一フォルマント（F1）、下から2番目の赤線が第二フォルマント（F2）

各母音の時間軸上の中央における第一フォルマント（F1）と第二フォルマント（F2）を計測し、表にまとめたもの

それを散布図にしたもの

軸を入れ替えたもの

IPA（国際音声記号）の母音チャートと、ほぼ同じ配置になる

音声処理でよく使われる特徴量

ゼロ交差率（Zero-Crossing Rate, ZCR）とは

波形が正から負、または負から正に切り替わる回数を、一定区間内で数えた指標
以下のような式で表される

$$ \text{ZCR} = \frac{1}{2(N-1)} \sum_{i=1}^{N-1} \left| \text{sign}(x_i) - \text{sign}(x_{i+1}) \right| $$

$\text{sign}(x)$は、$x$の符号（正なら1、負なら-1）を返す関数
隣り合うサンプルの符号が変わるたびに差の絶対値が2になるので、それを$2(N-1)$で割ることで「切り替わった割合」になる
高い周波数成分が多いほどZCRは大きくなる傾向がある
無声子音（s、shなど、声帯を震わせずに出す音）はノイズに近い波形になりやすく、ZCRが高くなる
逆に母音のような有声音は、周期的な波形になりやすく、ZCRは低くなる傾向がある
古典的なVADでは、エネルギー（音量が小さい＝無音）だけでなく、ZCR（ノイズっぽい波形かどうか）も組み合わせて判定に使うことがある

基本周波数（F0・ピッチ）を特徴量として使う

F0の定義そのものは、前述の「声の音響的な仕組み」を参照
有声音（母音など、声帯が振動する音）にはF0が存在し、無声音（子音の一部など、声帯が振動しない音）にはF0が存在しない
F0が検出できるかどうかは、有声音/無声音の判定や、話者の特定（声の高さの特徴）に使われる
抽出方法としては、自己相関関数を使う方法、YINアルゴリズム、CREPEのようなディープラーニングベースの手法などがある

スペクトル重心・スペクトル平坦度とは

どちらも、周波数スペクトル（音をどの周波数がどれだけ含むかに分解したもの）の形状を要約する指標
スペクトル重心（Spectral Centroid）は、スペクトルの「重心」にあたる周波数

$$ \text{Centroid} = \frac{\sum_{k} f_k \, S(f_k)}{\sum_{k} S(f_k)} $$

$f_k$が周波数、$S(f_k)$がその周波数のパワー
値が高いほど高周波成分が多く「明るい」音、低いほど「こもった」音という印象になる
スペクトル平坦度（Spectral Flatness）は、スペクトルがノイズのように平坦か、特定の周波数に偏っているかを表す指標
幾何平均と算術平均の比で計算され、1に近いほどホワイトノイズのような平坦なスペクトル、0に近いほど特定の周波数（ピッチなど）に偏ったスペクトルになる

音源定位（GCC-PHAT）

複数のマイク（マイクアレイ）を使って、音がどの方向から来たかを推定する技術を音源定位（Sound Source Localization）と呼ぶ
GCC-PHAT（Generalized Cross-Correlation with PHAse Transform）は、その代表的な古典的手法の1つ
基本的な考え方は、2つのマイクに音が届くタイミングのズレ（到達時間差、TDOA: Time Difference of Arrival）を、相互相関（クロスコリレーション）を使って推定するというもの
通常の相互相関は振幅の大きさに影響されやすいため、GCC-PHATでは周波数領域で振幅成分を正規化し、位相情報だけを使って相互相関を計算する。これが「PHAT（Phase Transform）」という名前の由来
マイク間の距離と、推定した到達時間差から、音源がどの方向にあるかを計算できる
複数マイクを使ったビームフォーミングや、話者の方向推定の前段としてよく使われる

まとめ

音は空気の振動で、振幅（音量）・周波数（音の高さ）・位相という要素で表される
デジタル化は、サンプリング（時間方向の離散化）と量子化（振幅方向の離散化）の2段階で行われ、その生データがPCM。これを実際のハードウェアとして行うのがADC（録音）とDAC（再生）
サンプリング定理により、記録したい最大周波数の2倍以上のサンプリング周波数が必要になる
音声ファイルには、非圧縮（WAV）・可逆圧縮（FLAC）・非可逆圧縮（MP3など）がある
FFT・STFTを使うと、波形を周波数領域（スペクトログラム）に変換して、音の中身を分析できる。フレームサイズとホップサイズの選び方には、時間分解能と周波数分解能のトレードオフがある
多くの音声処理は振幅（パワー）の情報だけを使い、位相の情報は捨てることが多い
RMS・dB・dBFS・SNRは、音の大きさやノイズとの関係を表すための一連の指標
ノイズフロアは、系が持つ最低限のノイズレベルで、それより小さい信号は検出できない。ビット深度が生む量子化ノイズフロアもその一種。ノイズを除去する技術がノイズ抑制・音声強調
メル尺度は人間の聴覚特性に合わせた周波数の圧縮で、log-melスペクトログラムやMFCCの土台になっている
声は基音（F0）とその整数倍の倍音からなる周期波で、声道の共鳴が特定の周波数帯（フォルマント）を強める。F0は音程、フォルマント（F1・F2）は母音・声質に対応する
声帯が振動する有声音と、振動しない無声音の違いは、F0の有無やZCRで機械的に判定できる
ZCR・F0・スペクトル重心/平坦度は、VADや音声分類などで昔からよく使われてきた古典的な特徴量
ハードウェアの一定クロックとソフトウェアの断続的な処理のギャップを、リングバッファが埋めている。読み込み位置が書き込み位置に追いつくとunderrun、その逆でoverrunが起きる
Linuxでは、PulseAudioやPipeWireのようなサウンドサーバーがアプリとハードウェアの間の音声ルーティングを担う。クオンタム（処理単位のサンプル数）が小さいほど低遅延だが、xrunが起きやすくなる
複数マイクを使った音源定位には、位相情報を使うGCC-PHATのような手法がある

参考文献

WebRTC VADの仕組み

Sun, 23 Aug 2026 12:00:00 +0900

背景

音声区間検出（VAD）でよく使われるwebrtcvadについて調べていた
精度はDNNベースのものに勝てないが、中身がGMM（混合ガウス分布）と尤度比で構成される
中身が面白いので、その中身をAIで詳解した

VAD（Voice Activity Detection）とは

音声データの中から「人が喋っている区間」と「喋っていない区間」を判定する技術
無音部分のトリミング、音声認識（ASR）の前処理、通話の帯域節約など、幅広く使われる
webrtcvadは、Google WebRTCプロジェクトのVADエンジンをPythonから使えるようにしたライブラリ

WebRTC VADの全体像

音声を短いフレーム（10ms・20ms・30msのいずれか）に分割し、フレームごとにspeech/non-speechを判定する
対応サンプリングレートは8k/16k/32k/48kHzのモノラルPCM
内部処理は8kHzで行われており、16k/32k/48kHzの入力は、まず8kHzにダウンサンプルしてから同じ判定ロジックにかけている
判定の厳しさをaggressiveness（0〜3）で指定でき、数字が大きいほどnon-speech寄りに判定する
ディープラーニングは使っておらず、GMMという古典的な統計モデルで判定している

処理の流れ

WebRTC VADの判定は、大まかに以下の流れで行われる。

音声をフレーム単位に分割する
各フレームを6つの周波数帯域（チャンネル）に分け、帯域ごとのエネルギーを計算する
帯域ごとに、そのエネルギーをspeech用・noise用のGMMに入力して尤度比を計算する
全帯域の尤度比を合算し、speechらしい方を採用する

この流れを理解するには、GMMと尤度という2つの概念を知っておく必要がある。（この後、実際のソースコードで確認したより正確な仕組みも解説する）

GMM（混合ガウス分布）とは

正規分布のおさらい

正規分布（ガウス分布）は、平均$\mu$を中心とした釣鐘型の分布
以下の式で表される

$$ \mathcal{N}(x \mid \mu, \sigma^2) = \frac{1}{\sqrt{2\pi\sigma^2}} \exp\left(-\frac{(x-\mu)^2}{2\sigma^2}\right) $$

$\mu$は分布の中心、$\sigma^2$は分布の広がり（分散）を表す
山が1つしかない、単純な形の分布

実際、WebRTC VADのソース（vad_gmm.cのWebRtcVad_GaussianProbability）のコメントにも、この式がそのまま書かれている。

1
2
3
4
5
6
7
8
9


// For a normal distribution, the probability of |input| is calculated and
// returned (in Q20). The formula for normal distributed probability is
//
// 1 / s * exp(-(x - m)^2 / (2 * s^2))
//
// where the parameters are given in the following Q domains:
// m = |mean| (Q7)
// s = |std| (Q7)
// x = |input| (Q4)

Q7・Q4・Q20は固定小数点の表現方法（浮動小数点を使わない代わりに、整数のどこまでを小数部として扱うかを表す）
数式としては$\frac{1}{s}\exp\left(-\frac{(x-m)^2}{2s^2}\right)$そのもので、前述の$\mathcal{N}(x \mid \mu, \sigma^2)$と完全に一致する

正規分布1つでは表現できない分布

実際のデータは、山が複数ある分布になることが多い
例えば「静かな部屋のノイズのエネルギー」と「人が喋っているときのエネルギー」を混ぜて集計すると、低い値のあたりと高い値のあたりに、それぞれ山ができる
こうした分布は、正規分布1つでは無理に1つの山として近似することになり、うまく表現できない

複数の正規分布を混ぜる

そこで、複数の正規分布を重みつきで足し合わせたものがGMM
以下の式で表される

$$ p(x) = \sum_{k=1}^{K} \pi_k \, \mathcal{N}(x \mid \mu_k, \sigma_k^2) $$

$K$個の正規分布を混ぜ合わせる
各正規分布は、自分専用の平均$\mu_k$・分散$\sigma_k^2$を持つ
$\pi_k$は「その正規分布がどれくらいの割合で混ざっているか」を表す重みで、全て足すと1になる
イメージとしては、複数の釣鐘型の山を、それぞれ違う高さ・違う場所に立てて、足し合わせたもの

GMMの学習

$\mu_k$・$\sigma_k^2$・$\pi_k$は、手元のデータから推定する必要がある
一般にはEM（Expectation-Maximization）アルゴリズムという手法で推定する
大まかには以下の2ステップを繰り返す
- Eステップ: 今のパラメータのもとで、各データ点がどの正規分布に属していそうかを確率的に割り当てる
- Mステップ: その割り当てをもとに、各正規分布の$\mu_k$・$\sigma_k^2$・$\pi_k$を更新する
これを収束するまで繰り返すことで、データの分布にフィットするGMMが得られる
一般的には、こうして学習したパラメータは固定して使うことが多いが、WebRTC VADは少し違う（後述の「モデルは学習後も動き続ける」を参照）

尤度で分析するとは

尤度（Likelihood）の意味

尤度とは、「あるモデルのもとで、このデータが観測される確からしさ」を表す値
GMMの場合、あるデータ点$x$に対する尤度は、前述の$p(x)$そのもの
$p(x)$が大きいほど、そのモデルにとって「よくあるデータ」、小さいほど「珍しいデータ」ということになる

対数尤度とは（なぜ対数を取るのか）

対数尤度（log-likelihood）とは、尤度$p(x)$そのものではなく、その対数$\log p(x)$を指す
わざわざ対数を取る理由は、主に以下の2つ

理由1は、掛け算が足し算になること。

以下は、独立した2つのデータ点$x_1$・$x_2$を同時に観測する尤度（同時尤度）の式である。

$$ p(x_1, x_2) = p(x_1) \cdot p(x_2) $$

複数のデータを同時に扱うとき、各データが互いに独立なら、全体の尤度はそれぞれの尤度の掛け算になる
しかし対数を取ると、この掛け算が足し算に変わる

$$ \log p(x_1, x_2) = \log p(x_1) + \log p(x_2) $$

足し算の方が、掛け算より計算コストが低く、桁あふれ（多くの小さい確率を掛け続けると、値がどんどん0に近づいてアンダーフローする問題）にも強い

理由2は、大小関係が変わらないこと。

$\log$は単調増加関数なので、$p_A(x)$と$p_B(x)$の大小関係は、$\log p_A(x)$と$\log p_B(x)$の大小関係とそのまま一致する
つまり、分類のために大小を比較する用途では、対数を取っても比較結果は変わらない
こうした理由から、尤度は生の値ではなく対数を取った状態（対数尤度）で扱われることが多い

尤度比によるクラス判定

クラスごとに別々のGMMを学習しておけば、そのGMM同士の尤度を比較することで分類ができる
具体的には、以下のような手順になる
- クラスAのデータだけを使ってGMM_Aを学習する
- クラスBのデータだけを使ってGMM_Bを学習する
- 新しいデータ$x$が来たら、$p_A(x)$と$p_B(x)$を両方計算する
- $p_A(x)$の方が大きければクラスA、$p_B(x)$の方が大きければクラスBと判定する
以下のような尤度比（対数を取ったもの）を閾値と比較する形で実装されることが多い

$$ \log p_A(x) - \log p_B(x) > \text{threshold} $$

これは「そのデータが、クラスAのモデルとクラスBのモデル、どちらにとってより自然か」を比較しているだけで、仕組みとしてはシンプル

WebRTC VADの判定の仕組み

前述のGMM・尤度比の考え方を、そのままspeech/non-speechの2クラス分類に当てはめたものがWebRTC VAD
ここから先は、実際にlibwebrtcのソース（vad_core.c・vad_gmm.c）をcloneして確認した内容を元に、より正確な仕組みを解説する

特徴量：6つの周波数帯域のlog-energy

前半で「帯域ごとのエネルギー」と書いたが、正確にはエネルギーをdBスケールに変換したもの（log-energy）を特徴量として使っている
内部は8kHzで動くので、ナイキスト周波数は4kHz。この0〜4kHzを、以下のように繰り返し半分に分割して6つの帯域を作る（vad_filterbank.cのWebRtcVad_CalculateFeatures）

チャンネル	周波数帯域
0	80 - 250 Hz
1	250 - 500 Hz
2	500 - 1000 Hz
3	1000 - 2000 Hz
4	2000 - 3000 Hz
5	3000 - 4000 Hz

分割には、ローパス/ハイパスに分けるSplitFilter（オールパスフィルタ2つの組み合わせ）を使い、それを繰り返し適用して帯域を半分ずつに絞り込んでいく
80Hz未満は、別途ハイパスフィルタで除去している（無音時の低周波ノイズ・DCオフセットの影響を避けるため）
各帯域のエネルギーは、LogOfEnergyという関数で対数（dB相当、Q4固定小数点）に変換されてから特徴量になる。以下がそのコメント部分（vad_filterbank.cより抜粋）

1
2
3
4
5
6
7


// Calculates the energy of |data_in| in dB, and also updates an overall
// |total_energy| if necessary.
// ...
// - log_energy [o] : 10 * log10("energy of |data_in|") given in Q4.
static void LogOfEnergy(const int16_t* data_in, size_t data_length,
 int16_t offset, int16_t* total_energy,
 int16_t* log_energy) {

つまりGMMに入力される$x$は「その帯域の生のエネルギー」ではなく「その帯域のエネルギーをdB変換した値」であり、これによって音量の桁の違い（静かな音と大きい音の差）を扱いやすくしている

チャンネルごとに独立したGMM

WebRTC VADは、音声を6つの周波数帯域（チャンネル）に分けて処理する
各チャンネルに、noise用・speech用それぞれ2つの正規分布を混ぜたGMM（$K=2$）を持っている
つまり全体では、6チャンネル×2クラス×2つの正規分布で、合計24個の正規分布が使われている
前半で説明した「1つのGMMで全体を判定する」という書き方は簡略化しすぎで、正確には「チャンネルごとに独立したGMMを持ち、後で結果を合算する」という構造になっている

ローカル判定とグローバル判定

各チャンネルについて、noise側の尤度とspeech側の尤度から、対数尤度比（log-likelihood ratio）を計算する
各チャンネルの尤度比に、周波数帯域ごとの重み（高い帯域ほど大きい重み）をかけて合算し、全チャンネルまとめたグローバルな尤度比を作る

以下は、$C=6$個のチャンネルの尤度比$\text{LLR}_c$を、重み$w_c$で合算する式である。

$$ \text{LLR}\_{\text{global}} = \sum_{c=1}^{C} w_c \cdot \text{LLR}_c $$

「掛け算」ではなく「足し算」で合算しているのは、前述の対数の性質（各チャンネルが独立なら、全体の尤度は各チャンネルの尤度の掛け算になり、対数を取ると足し算になる）を使っているため
6つのチャンネルをそれぞれ独立な情報源とみなし、各チャンネルの対数尤度比を（重みつきで）足し合わせることで、全帯域を総合した1つの証拠にまとめている、という考え方

判定は、以下の2つのテストの組み合わせ（どちらか一方でも満たせばspeech）で行われる。

ローカル判定: いずれか1つのチャンネルだけでも、尤度比が強くspeech寄りであればspeechとする
グローバル判定: 全チャンネル合算の$\text{LLR}_{\text{global}}$が閾値を超えていればspeechとする

実際の該当コードは以下（vad_core.cのGmmProbabilityより抜粋、コメントも含む）。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


// The detection scheme is an LRT with hypothesis
// H0: Noise
// H1: Speech
//
// We combine a global LRT with local tests, for each frequency sub-band,
// here defined as |channel|.
for (channel = 0; channel < kNumChannels; channel++) {
 ...
 // Calculate the log likelihood ratio: log2(Pr{X|H1} / Pr{X|H0}).
 ...
 sum_log_likelihood_ratios +=
 (int32_t) (log_likelihood_ratio * kSpectrumWeight[channel]);

 // Local VAD decision.
 if ((log_likelihood_ratio * 4) > individualTest) {
 vadflag = 1;
 }
}

// Make a global VAD decision.
vadflag |= (sum_log_likelihood_ratios >= totalTest);

H0（帰無仮説）を「ノイズ」、H1（対立仮説）を「音声」とする、統計学の仮説検定（LRT: Likelihood Ratio Test）そのものの形になっている
kSpectrumWeight[channel]は、チャンネル（帯域）ごとの重み。値は{ 6, 8, 10, 12, 14, 16 }で、高い周波数帯域ほど大きい重みがついている

対数尤度比をビットシフトだけで近似計算する仕組み

組み込み機器向けの実装なので、浮動小数点のlog関数は一切使わず、整数のビットシフトだけで対数尤度比を近似している
該当コードとコメントは以下（vad_core.cより抜粋）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


// Calculate the log likelihood ratio: log2(Pr{X|H1} / Pr{X|H1}).
// Approximation:
// log2(Pr{X|H1} / Pr{X|H1}) = log2(Pr{X|H1}*2^Q) - log2(Pr{X|H1}*2^Q)
// = log2(h1_test) - log2(h0_test)
// = log2(2^(31-shifts_h1)*(1+b1))
// - log2(2^(31-shifts_h0)*(1+b0))
// = shifts_h0 - shifts_h1
// + log2(1+b1) - log2(1+b0)
// ~= shifts_h0 - shifts_h1
shifts_h0 = WebRtcSpl_NormW32(h0_test);
shifts_h1 = WebRtcSpl_NormW32(h1_test);
if (h0_test == 0) {
 shifts_h0 = 31;
}
if (h1_test == 0) {
 shifts_h1 = 31;
}
log_likelihood_ratio = shifts_h0 - shifts_h1;

h0_test・h1_testは、それぞれH0（ノイズ）・H1（音声）の尤度に相当する32bit整数値
WebRtcSpl_NormW32(v)は、「符号ビットを除いた最上位ビットが1になるまで、vを何ビット左シフトできるか」を返す関数
- 言い換えると、vの最上位の1が立っているビット位置を求めているのと同じ
- ある正の整数の最上位ビットの位置は、おおよそ$\lfloor \log_2 v \rfloor$に一致する（例えばvが$2^{20}$〜$2^{21}-1$の範囲なら、最上位ビット位置は20で、シフト数は「31引く21」あたりの値になる）
つまり、必要なシフト数は「$v$の桁の大きさ」を表す指標であり、$v$が大きいほどシフト数は小さく、$v$が小さいほどシフト数は大きくなる、という$-\log_2 v$に近い性質を持つ
コメントの式変形が示す通り、以下の近似が成り立つ

$$ \log_2 h_1 - \log_2 h_0 \approx \text{shifts(H0)} - \text{shifts(h1)} $$

右辺にはlog計算が一切登場せず、整数の左シフト回数を数えるだけなので、組み込み機器でも高速に計算できる
誤差として捨てているのは、最上位ビットより下の桁（コメント中の$b_0$・$b_1$）の情報だが、これは$0$以上$1$未満の小さい値で、H0側とH1側で平均的に打ち消し合うため、実用上は無視できるとされている
h0_testまたはh1_testが0（アンダーフロー）の場合は、シフト数を最大値31にして「その仮説の尤度はほぼ0（=強く否定される）」ことを表現している

モデルは学習後も動き続ける（オンライン適応）

一般的なGMM分類器は、事前に学習したパラメータを固定して使うことが多い
しかしWebRTC VADは、noise用・speech用それぞれのGMMの平均を、判定結果に応じてフレームごとに更新し続ける
- そのフレームがspeechと判定されれば、speech側GMMの平均をそのフレームの特徴量に近づける
- noiseと判定されれば、同様にnoise側GMMの平均を近づける
- 更新の強さはkSpeechUpdateConst・kNoiseUpdateConstという定数で決まっていて、急激に動きすぎないよう抑えられている
さらに、noise側の平均には長期的な補正もかかる
- チャンネルごとに、直近の特徴量（log-energy）の中で特に小さかった値を16個、経過フレーム数（最大100フレーム）つきで保持し続ける仕組みがあり（vad_sp.cのWebRtcVad_FindMinimum）、そこから長期的な最小値（ノイズの床）を推定する
- noise側の平均は、その推定値の方向へkBackEtaという定数の分だけゆっくり引き寄せられる（該当コード: nmk3 = nmk2 + (int16_t)((ndelt * kBackEta) >> 9);、コメントには"Long term correction of the noise mean"とある）
- これにより、周囲のノイズレベル自体が時間とともに変化しても（エアコンが止まる、環境音が変わる等）、noiseモデルがその変化に追従できる
つまり、事前学習したパラメータはあくまでスタート地点であり、実際に動かしている環境に合わせてモデル自体が少しずつ適応し続ける仕組みになっている

aggressivenessによる閾値の違い

aggressiveness（0〜3）は、ローカル判定・グローバル判定それぞれの閾値のセットを切り替えるパラメータ
例えば、10ms（80サンプル）フレームでの閾値は以下のように変わる

aggressiveness	ローカル閾値	グローバル閾値
0（Quality）	24	57
3（Very Aggressive）	94	1100

数字が大きいほど、speechと判定するためにより強い証拠（尤度比の差）が必要になり、non-speech寄りに判定が倒れやすくなる

判定のちらつきを抑える仕組み（hangover）

フレーム単位の判定をそのまま出力すると、speechの終わり際などで判定がON/OFFを細かく繰り返してしまう
WebRTC VADは、これを抑えるためにhangover（一種の余韻）という仕組みを持つ
- 一度speechと判定されると、その後しばらくnoise判定が続いてもspeechのまま扱う
- 直近でspeechが長く続いていたかどうかに応じて、hangoverの長さを切り替える
- hangoverの長さもaggressivenessによって変わる

WebRTC VADの特徴と限界

特徴量が6帯域のlog-energyだけで、log-melやMFCCのようなメル尺度ベースの特徴量は使っていないため、計算が軽く高速
ディープラーニング以前の手法のため、ノイズや残響で音質が劣化した音声には弱く、拾い漏れ（recallの低下）が起きやすい
話者性・方向・距離といった情報は一切使っていないため、「誰が喋っているか」「どの方向の声か」は区別できない
- カフェなど雑音の多い環境で、目的の話者以外の声（雑談など）を除外したい場合は、VAD単体では対応できない
- その用途には、話者のembeddingを使ったtarget speaker extractionや、ビームフォーミングなど別の技術が必要になる

まとめ

WebRTC VADは、GMMと尤度比という古典的な統計モデルでspeech/non-speechを判定している
GMMは、複数の正規分布を重みつきで混ぜ合わせて、複雑な分布を表現するモデル
尤度は「あるモデルからそのデータが出てくる確からしさ」で、クラスごとにGMMを学習して尤度を比較すれば、そのまま分類器として使える
対数尤度（尤度の対数）を使うと、独立なデータの同時尤度の掛け算が足し算になり、計算が軽く数値的にも安定する。WebRTC VADが各帯域の尤度比を足し算で合算しているのもこの性質による
dB・dBFS・log-mel・MFCCは、いずれも音声処理でよく出てくる基礎的な特徴量表現だが、WebRTC VADはそのどれでもなく、オールパスフィルタで再帰的に分割した6帯域のlog-energyというシンプルな特徴量を使っている
実際のソースコードを確認すると、以下のようなことが分かった
- 特徴量は6つの周波数帯域（80-250, 250-500, 500-1000, 1000-2000, 2000-3000, 3000-4000 Hz）ごとのlog-energy
- 帯域ごとに独立したGMMがあり、ローカル判定（帯域単体）とグローバル判定（重みつき合算）を組み合わせている
- これはH0: ノイズ／H1: 音声という尤度比検定（LRT）そのものの形になっている
- 対数尤度比はlog関数を使わず、32bit整数の正規化に必要なビットシフト数の差だけで近似計算されている
- GMMのパラメータは事前学習した値で固定ではなく、動作中もフレームごとにオンラインで適応し続けている（ノイズの床の長期的なドリフトにも追従する）
- hangoverという仕組みで、判定のちらつきを抑えている
WebRTC VADは軽量・高速な反面、話者を区別する仕組みがなく、ノイズへの頑健性もニューラルVADに比べて劣る

参考文献

wiseman/py-webrtcvad

無料で使える音声・音響データセットカタログ

Thu, 13 Aug 2026 09:52:00 +0900

背景

仕事で、ASR(音声認識)・TTS(音声合成)・VAD/話者ダイアライゼーション・ターン検出などのモデルを作った
そのために、無料で使える音声・音響データセットを探してかき集めた
手元に貯まった数十個のデータセットを整理して、後から見返せるようにカタログ化した
量が多いのでAIにローカルの物を全部まとめてもらった結果なのでいくつか間違いがあるかもしれないところは注意
データセットごとに「どんなデータか」「何に使えるか」「どこから落とせるか」「件数・サイズ」「ライセンス」をまとめた
ライセンス欄は各配布元の記載をそのまま転記しただけで、「記載なし」は自由に使ってよいという意味ではない
調査の過程で見つかった商用・研究専用など無料で使えないデータセットも、比較の参考として一部残してある(ライセンス欄に⚠️で明記)
ダウンロード・変換用のスクリプトや作業用キャッシュなど、データセットそのものではないものはこのカタログには含めていない

会話・雑談音声

AMI Meeting Corpus

内容
- 英語の多人数会議録音(近接マイクIHM + 単一遠隔マイクSDM)、発話単位の書き起こし・話者ID付き、非ネイティブ英語話者が多い
想定用途
- 会議音声のASR・話者分離モデルの学習/評価
入手元
- huggingface.co/datasets/edinburghcstr/ami
- 原コーパス: groups.inf.ed.ac.uk/ami
ライセンス
- CC BY 4.0
件数/サイズ
- IHM 108,502/13,098/12,643件(train/val/test)、SDMも同規模、28G
形式
- Parquet(16kHz)

CALLFRIEND

内容
- 友人・家族間の自然な電話会話、話者ダイアライゼーション形式(発話区間タイムスタンプ+話者ラベル)、英語(2方言)・カナダ仏語・日本語
想定用途
- 自然会話のダイアライゼーション/ASR研究
入手元
- huggingface.co/datasets/talkbank/callfriend
- バックアップ: huggingface.co/datasets/0x3/callfriend
ライセンス
- 記載なし(TalkBank利用規約に準拠、下記注意参照)
件数/サイズ
- 72件(2.5G)
形式
- Parquet

SAKURA(TalkBank)

内容
- 長尺の会話音声+タイムスタンプ付き話者ターン(失語症/談話インタビュー系コレクション)
想定用途
- 談話分析・長尺対話ダイアライゼーション研究
入手元
- huggingface.co/datasets/talkbank/sakura
ライセンス
- 記載なし(TalkBank規約準拠)
件数/サイズ
- 18件(845M)
形式
- Parquet

BTSJ日本語自然会話コーパス

内容
- 国立国語研究所/宇佐美まゆみ研究室、32トピックの日本語会話、ターン交替・ポーズ・重なり・イントネーション注記付きExcel文字化
想定用途
- 日本語会話の言語学的分析、ターン交替・相槌研究
入手元
- mmsrv.ninjal.ac.jp/btsj/corpus.html(NINJAL公式)
ライセンス
- 記載なし(NINJAL独自の研究利用規約、オープンライセンスではない)
件数/サイズ
- mp3 390件、xlsx文字化549件(12G)
形式
- mp3 + xlsx

Real-PersonaChat

内容
- 音声なし・テキストのみ、日本語雑談対話+話者パーソナリティ(Big Five等)注釈、GPT-3.5/4によるペルソナ対話ログも含む
想定用途
- 対話システム・ペルソナ対話生成の研究
入手元
- huggingface.co/datasets/nu-dialogue/real-persona-chat
ライセンス
- CC BY-SA 4.0
件数/サイズ
- 対話13,583件・発話408,619件(141M)
形式
- JSON(テキストのみ)

SeniorTalk

内容
- 75〜85歳の中国語話者202名による高品質会話音声、文字レベルの手動転写+発話・話者レベルのアノテーション付き
想定用途
- 高齢者向けASR・話者検証・話者分離の研究
入手元
- huggingface.co/datasets/0x3/SeniorTalk
- 複製元: huggingface.co/datasets/BAAI/SeniorTalk
ライセンス
- CC BY-NC-SA 4.0(非商用)
件数/サイズ
- 対話101件・55.53時間(ASR用60,029発話・37.81時間)、20.9G
形式
- wav(16kHz)+ テキスト転写

J-CHAT

内容
- YouTube・ポッドキャストから収集した日本語大規模対話音声コーパス、音声言語モデリング研究向け
想定用途
- 日本語の音声対話モデリング、対話音声の事前学習
入手元
- huggingface.co/datasets/sarulab-speech/J-CHAT
ライセンス
- ⚠️CC BY-NC 4.0(非商用)、日本国著作権法第30条の4の目的に限り使用可という制限も明記
件数/サイズ
- 約76,000時間
形式
- lhotse/WebDataset形式(音声+JSON転写)
備考
- 実際に試した限りではモノラル音声で、話者分離(話者ダイアライゼーション)はされていなかった

MagicHub 日本語自然会話

内容
- 日本語の自然な2者間電話/会話音声、話者・性別・[LAUGHTER][PII][MUSIC]等のタグ付き時刻同期書き起こし
想定用途
- 日本語自然会話ASRモデルの学習(商用データセット)
入手元
- magichub.com
ライセンス
- ⚠️独自ライセンス(全権利留保)、著作権者の許可なく複製・再配布禁止
件数/サイズ
- wav 20件・話者10名(1.8G)
形式
- wav + txt

Global Conversational Speech

内容
- 18言語(日本語含む)の会話音声(医療・会議・コールセンター等)、原本は305時間/199GB
想定用途
- 多言語会話ASR/翻訳モデルの学習(商用)
入手元
- huggingface.co/datasets/UsergyAI/Global-Conversational-Speech
ライセンス
- ⚠️商用ライセンス(有償・ゲート付き)、$65/時間
件数/サイズ
- 未ダウンロード(READMEのみ)
形式
- —

音声認識(ASR)コーパス

Common Voice 17.0

内容
- Mozillaのクラウドソース多言語読み上げ音声、約122言語(日本語含む)、年齢/性別/アクセント等のメタデータ付き
想定用途
- 多言語ASRモデルの学習・評価の定番データ
入手元
- huggingface.co/datasets/fsicoli/common_voice_17_0
- 原本: commonvoice.mozilla.org
ライセンス
- CC0-1.0(パブリックドメイン)
件数/サイズ
- validated分だけで約1,478万件(521G)
形式
- mp3(tar格納)+ tsv

LibriSpeech ASR

内容
- 英語の朗読音声(オーディオブック)ASRコーパス、clean/other/all構成、train/val/test分割、書き起こし・話者ID付き
想定用途
- 英語ASRモデルの標準ベンチマーク・学習
入手元
- huggingface.co/datasets/librispeech_asr
- 原著者: Panayotov et al.
ライセンス
- CC BY 4.0
件数/サイズ
- 全構成合計約29.2万件(116G)
形式
- Parquet(16kHz)

ja_asr.common_voice_8_0

内容
- Common Voice 8.0の日本語ASRサブセット(testのみ)、音声+書き起こしペア
想定用途
- 日本語ASRモデルの評価(testセットのみ)
入手元
- huggingface.co/datasets/0x3/ja_asr.common_voice_8_0
ライセンス
- 記載なし(元のCommon VoiceはCC0)
件数/サイズ
- 4,483件(145M)
形式
- FLAC(48kHz)

Genshin-Voice-Ja

内容
- ゲーム「原神」から抽出した日本語キャラクターボイス+対応する台詞テキスト
想定用途
- 日本語ASR・TTS・多言語音声処理モデルの学習
入手元
- huggingface.co/datasets/0x3/Genshin-Voice-Ja
- 複製元: huggingface.co/datasets/OpenSpeechHub/Genshin-Voice-Ja
ライセンス
- ⚠️記載なし(READMEが空、ゲーム由来のキャラクターボイスのため二次利用は要注意)
件数/サイズ
- 109,630件(60.3G)
形式
- Parquet

ReazonSpeech

内容
- 地上波テレビ放送から抽出した自然な日本語音声、FLAC音声+テキスト転記。tiny/small/medium/large/allの5段階のサイズで提供されており、small・medium・largeを実際に試した
想定用途
- 日本語ASRモデルの学習(実放送音声)
入手元
- huggingface.co/datasets/reazon-research/reazonspeech
ライセンス
- CDLA-Sharing-1.0、⚠️加えて日本国著作権法第30条の4の目的に限り使用可という制限付き
件数/サイズ
- tiny: 600MB/8.5時間、small: 6GB/100時間(実測62,047件・6.7G)、medium: 65GB/1000時間、large: 330GB/5000時間、all: 2.3TB/35000時間
形式
- FLAC(16kHz)

whisper_transcriptions.reazonspeech.small.wer_10.0

内容
- ReazonSpeech smallをWhisperで再書き起こしし、WER≤10.0でフィルタしたASR蒸留用データ、text(正解)・whisper_transcript(トークン列)付き
想定用途
- Whisper蒸留・擬似ラベル付きASRファインチューニング
入手元
- huggingface.co/datasets/japanese-asr/whisper_transcriptions.reazonspeech.small.wer_10.0
ライセンス
- 記載なし
件数/サイズ
- 20,900件(2.7G)
形式
- Parquet(16kHz)

Google Speech Commands

内容
- Googleが公開する1秒間の英語音声集、「Yes」「No」「Up」等10個のコマンド単語を中心に補助単語・沈黙音声も収録
想定用途
- キーワードスポッティング(限定語彙音声認識)、小規模モデルの学習・評価の定番ベンチマーク
入手元
- huggingface.co/datasets/google/speech_commands
ライセンス
- CC BY 4.0
件数/サイズ
- v0.01: 30単語・64,727件、v0.02: 35単語・105,829件
形式
- wav(16kHz)

asr-noise-robust-en

内容
- CAIMAN・ノイズ付きLibriSpeech・Buckeye・Switchboard・AMI-validationの混合クリップ集(HF m-aliabbas1/asr-noise-robust-en)
想定用途
- ノイズ耐性ASRの評価(未確認)
入手元
- huggingface.co/datasets/m-aliabbas1/asr-noise-robust-en
ライセンス
- 記載なし
件数/サイズ
- READMEのみで実データは未確認
形式
- —

音声合成(TTS)用コーパス

LibriTTS-R

内容
- LibriTTSをMiipherという音声修復モデルで高音質化した、24kHzの英語TTS用コーパス。train_clean_100(約100時間)・train_clean_360(約360時間)などのサブセットがある
想定用途
- 英語TTSモデルの学習
入手元
- openslr.org/141
- 原著者: Koizumi et al.
ライセンス
- CC BY 4.0
件数/サイズ
- train_clean_100: 7.6G、train_clean_360: 27G(全体では約585時間・84.7G)
形式
- tar.gz(24kHz)

Hi-Fi TTS

内容
- LibriVoxのオーディオブック音声とProject Gutenbergのテキストを組み合わせた、44.1kHz・10話者(各17時間以上)・計291.6時間の高音質英語TTSコーパス
想定用途
- 高音質な英語TTSモデルの学習
入手元
- openslr.org/109
- 原著者: Bakhturina et al.
ライセンス
- CC BY 4.0
件数/サイズ
- 約291.6時間(39G)
形式
- tar.gz(44.1kHz)

環境音・ノイズ・非音声イベント

Freesound LAION-640k

内容
- LAION-Audio-630k向けにキュレーションされたFreesound.org音声+テキスト(タイトル/説明/タグ)、クリップごとにライセンス情報付き
想定用途
- 音声-テキスト対照学習(CLAP等)、音響イベント検索
入手元
- huggingface.co/datasets/benjamin-paine/freesound-laion-640k
ライセンス
- メタデータはMIT、音声はクリップごとに異なる(CC0/CC-BY/CC-BY-NC/CC-Sampling+が混在)
件数/サイズ
- 505,618件(633G)
形式
- Parquet

clotho-ja

内容
- 環境音の音声ファイルに複数の英語キャプションとその日本語訳を付与した音声キャプショニング用データセット(Clothoの日本語版)
想定用途
- 音声キャプション生成、音声-テキスト対応学習
入手元
- huggingface.co/datasets/0x3/clotho-ja
- 複製元: huggingface.co/datasets/Atotti/clotho-ja
ライセンス
- 記載なし
件数/サイズ
- 19,700件、音声長15〜30秒
形式
- Parquet

TAU Urban Acoustic Scenes 2022 Mobile(split5)

内容
- 空港・駅など都市環境の音響シーンを録音した音声+ラベル付きメタデータ、DCASE 2024 Task1公式スプリット
想定用途
- 音響シーン分類モデルの学習・評価(DCASE Task1)
入手元
- huggingface.co/datasets/0x3/tau-urban-acoustic-scenes-2022-mobile-split5
- 原本: Zenodo #6337421
ライセンス
- ⚠️非商用研究目的のみの使用
件数/サイズ
- 1.33G
形式
- wav + tsv(メタデータ)

DNS-Challenge

内容
- Microsoft Deep Noise Suppression Challenge(Interspeech 2020)一式、クリーン音声・ノイズ・合成スクリプト・テストセットの寄せ集め(下の内訳参照)
想定用途
- 音声強調・ノイズ抑圧モデルの学習・評価
入手元
- github.com/microsoft/DNS-Challenge
ライセンス
- 音源ごとに個別ライセンス(下記内訳を参照)
件数/サイズ
- wav計 11,277件(約10G)
形式
- wav

単一のデータセットではなく、音源ごとにライセンスが異なる複数コーパスの合成なので、要素ごとに分けて確認する

クリーン音声(LibriVox収録分)
- 内容
  - 読み上げ音声、ノイズ抑圧モデルの「正解」信号用
- 元の出所
  - LibriVox
- ライセンス
  - パブリックドメイン
クリーン音声(Edinburgh 56話者)
- 内容
  - スタジオ収録の英語音声
- 元の出所
  - Edinburgh大学56-speaker corpus
- ライセンス
  - 個別のカスタムライセンス
クリーン音声(PTDB-TUG)
- 内容
  - ピッチ参照付き音声
- 元の出所
  - PTDB-TUG corpus
- ライセンス
  - ODbL
ノイズ(AudioSet由来)
- 内容
  - 環境ノイズ
- 元の出所
  - Google AudioSet
- ライセンス
  - CC BY 4.0
ノイズ(Freesound由来)
- 内容
  - 環境ノイズ
- 元の出所
  - Freesound.org
- ライセンス
  - CC0
ノイズ(DEMAND由来)
- 内容
  - 多チャンネル環境ノイズ
- 元の出所
  - DEMAND
- ライセンス
  - CC BY-SA 3.0
リポジトリ全体のコード
- 内容
  - ノイズ合成・SNR混合スクリプト
- 元の出所
  - microsoft/DNS-Challenge
- ライセンス
  - MIT

DEMAND

内容
- 多チャンネル実環境ノイズDB、15環境、16chの環境音録音
想定用途
- ノイズ拡張・音声強調学習用の背景ノイズ
入手元
- huggingface.co/datasets/voice-biomarkers/DEMAND-acoustic-noise
- 原本: Zenodo #1227121
ライセンス
- CC BY 4.0
件数/サイズ
- 560件(9.8G)
形式
- Parquet(wav埋め込み)

WHAM!

内容
- 音声分離タスク向けのノイズデータセット、「WHAM!: Extending Speech Separation to Noisy Environments」の公式データ
想定用途
- ノイズを含む環境での音声分離・音声強調モデルの学習・評価
入手元
- huggingface.co/datasets/0x3/wham
- 原本: wham.whisper.ai
ライセンス
- CC BY-NC 4.0(非商用)
件数/サイズ
- 28,273件(train 21,216・val 4,444・test 2,613)、4.31G、48kHz/2ch
形式
- Opus

AudioSet-NonSpeech

内容
- Google AudioSetから人の発話が明確に含まれるクリップを除去したサブセット、非音声の環境音・イベント音のみ
想定用途
- 非音声音響イベント分類、ノイズ拡張
入手元
- huggingface.co/datasets/bond005/audioset-nonspeech
ライセンス
- CC BY 4.0
件数/サイズ
- 13,994件(4.1G)
形式
- Parquet

MUSAN(noise)

内容
- 技術音(DTMF等)と非技術音(雷・動物・クラクション等)、計約6時間7分
想定用途
- 音声認識/話者照合のノイズ拡張(SpecAugment等)
入手元
- openslr.org/17
ライセンス
- CC BY 4.0
件数/サイズ
- 930件(690M)
形式
- wav

speech-noise-dataset

内容
- クリーン音声・ノイズ混合音声・ノイズのみの3種類の録音で構成
想定用途
- 音声強調・ノイズ低減、ロバストなASRモデルの学習
入手元
- huggingface.co/datasets/0x3/speech-noise-dataset
- 複製元: huggingface.co/datasets/haydarkadioglu/speech-noise-dataset
ライセンス
- CC0-1.0(パブリックドメイン)
件数/サイズ
- 3,381件(5.93G)、各20秒wav
形式
- Parquet(wav埋め込み)

ESC-50

内容
- 環境音分類データセット、5秒クリップ×2,000件、50クラス(各40件)
想定用途
- 環境音分類モデルのベンチマーク
入手元
- huggingface.co/datasets/ashraq/esc50
- 原本: github.com/karolpiczak/ESC-50
ライセンス
- CC BY-NC(非商用)
件数/サイズ
- 2,000件(738M)
形式
- Parquet(wav埋め込み)

話者ダイアライゼーション・VAD

CALLHOME

内容
- 電話の自然会話をdiarizers-communityが話者ダイアライゼーション用に整形、中国語・英語・ドイツ語・日本語・スペイン語(原データはTalkBank)
想定用途
- 話者ダイアライゼーションモデル(pyannote等)のファインチューニング
入手元
- huggingface.co/datasets/diarizers-community/callhome
ライセンス
- CC BY-NC-SA 4.0(非商用)
件数/サイズ
- 660件(11G)
形式
- Parquet

VoxConverse

内容
- 英語多人数会話(YouTube由来)をdiarizers-communityが話者ダイアライゼーション用に整形、話者ターンのタイムスタンプ・ラベル付き
想定用途
- 話者ダイアライゼーションモデルの学習・評価
入手元
- huggingface.co/datasets/diarizers-community/voxconverse
- 原本: Oxford VGG
ライセンス
- CC BY 4.0(再配布版、原本のOxford VGG版は研究専用の制限が強め)
件数/サイズ
- dev 216件・test 232件(6.8G)
形式
- Parquet

AVA-Speech(VAD向け再パッケージ)

内容
- 映画中の発話区間検出データセットをWhisperSeg向けに再パッケージ、発話の開始/終了時刻JSON付き
想定用途
- VAD(発話区間検出)モデルの学習・評価
入手元
- huggingface.co/datasets/nccratliri/vad-human-ava-speech
ライセンス
- Apache-2.0(再パッケージ部分)
件数/サイズ
- train 158件・test 2件(4.3G)
形式
- wav + json

感情・非言語発声・声質(日本語コーパス群)

Vocal Bursts

内容
- 笑い・咳・泣き・くしゃみ・ため息・叫び・あくび等18カテゴリ、非発話の声のみのコーパス、複数の既存コーパスを寄せ集めて再パッケージしたもの
想定用途
- 非言語発声・パラ言語情報の分類研究
入手元
- huggingface.co/datasets/0x3/vocal-bursts
ライセンス
- CC BY 4.0
件数/サイズ
- 28,564件(3.4G)
形式
- FLAC

つくよみちゃんコーパス

内容
- フリー素材キャラクター「つくよみちゃん」(CV: 夢前黎)公式の声優統計コーパス(JVSコーパス準拠)、高音ウィスパー系の少女ボイス、100文+別途1,500文程度の追加データ、96.0kHz/24bit
想定用途
- TTS・音声変換の学習(実際にPiper-Plusのファインチューニングにも使用、前掲)
入手元
- tyc.rei-yumesaki.net/material/corpus
ライセンス
- ⚠️独自ライセンス、商用・非商用・個人法人問わず利用可だが、ソフト配布時はクレジット表記必須、再配布は原則禁止(配布ページへの誘導を推奨)、素材としての二次配布や政治・宗教勧誘等への利用は禁止
件数/サイズ
- 100文(+追加約1,500文)

ROHAN4600 ずんだもん読み上げ音声

内容
- ROHAN4600(後述の「テキストのみの台本コーパス」参照)のテキストをVOICEVOX「ずんだもん」ボイスで読み上げた音声+音素・アクセントラベル(PyOpenJTalk出力を人手で補正)
想定用途
- 日本語TTSの学習・評価、口唇同期(リップシンク)研究向けの口の動き画像・座標データも同梱される場合あり
入手元
- 音声本体: zunko.jp/multimodal_dev(研究者向けマルチモーダルデータベース、申請・ログインが必要)
- ラベル: github.com/RRR-troisR/Zundamon_ROHAN_label
ライセンス
- ⚠️音声本体は zunko.jp の研究者向け利用規約に個別に従う。ラベルは配布者により「自由に使用・改変・改変版の再配布可、利用による不利益について責任を負わない」と明記
件数/サイズ
- ROHAN4600の4,600文に対応する音声・ラベル

Takamichi研究室コーパス群

内容
- 東京大学・高道慎之介研究室が公開する日本語音声コーパス群(JVS/JVNV/PJS等)、コーパスごとに用途・ライセンスが異なる(下の内訳参照)
想定用途
- 日本語TTS・音声変換・感情音声合成の学習
入手元
- 高道研究室サイト
ライセンス
- コーパスごとに異なる(下記内訳を参照)
件数/サイズ
- 合計61G前後
形式
- 主にwav(16〜48kHz)

1つのデータセットではなく、高道研(東京大学)が公開した18種類前後の別々のコーパス+外部の実験デモデータの寄せ集めなので、サブコーパスごとに分けて確認する

JVS
- 内容
  - プロ声優100名の並列/非並列/ささやき/裏声読み上げ、約30時間
- 想定用途
  - マルチスピーカーTTS・話者変換の学習
- ライセンス
  - タグはCC BY-SA 4.0だが⚠️音声本体は非商用研究・個人利用限定・再配布不可
JVNV
- 内容
  - 感情音声+非言語発声(笑い・すすり泣き)、4話者×6感情、3.94時間
- 想定用途
  - 感情音声合成・非言語発声を含むTTSの学習
- ライセンス
  - CC BY-SA 4.0(商用含め制限なし)
PJS
- 内容
  - 音素バランス型・歌唱+朗読対応コーパス、1話者×100曲+100読み上げ、MIDI/musicXML付き
- 想定用途
  - 歌声合成(Singing Voice Synthesis)の学習
- ライセンス
  - CC BY-SA 4.0(商用可)
JVS-MuSiC
- 内容
  - 100名の歌唱コーパス、歌手類似度/キー/テンポタグ付き
- 想定用途
  - マルチシンガー歌声合成の学習
- ライセンス
  - タグCC BY-SA 4.0だが⚠️音声本体は非商用・個人利用限定・再配布不可
CPJD
- 内容
  - 日本各地(岡山・宮崎・大阪・石川・福井・徳島・静岡・福島・奈良・広島・青森・高知等)の方言音声、話者フォルダ名に方言名(例: F001_hiroshima_hiroshimaben)付き、ノイズ抑圧版(wav16k_norm_cleaned)も同梱、F0範囲情報付き
- 想定用途
  - 方言音声認識・方言TTSの研究
- ライセンス
  - 記載なし(READMEにライセンス記述なし)
CPJD text-only
- 内容
  - 上記CPJDの台本(共通文)のみのテキスト版、音声なし
- 想定用途
  - 方言横断の読み上げ台本設計の参考
- ライセンス
  - 記載なし
JTubeSpeech-ASV
- 内容
  - YouTube由来の話者照合用コーパス、1,792話者・484時間(うち日本語245時間)
- 想定用途
  - 話者照合(Speaker Verification)モデルの学習
- ライセンス
  - ⚠️「研究開発目的限定(暫定)」と明記、Takamichi群の中でも制限が強い
tri-jek
- 内容
  - 単一の女性トリリンガル話者による日本語・英語・韓国語の朗読音声、計11時間(日2.8h/韓6.7h/英1.5h)、コロナ禍収録のためやや低品質
- 想定用途
  - 多言語TTS・言語間の声質転移研究
- ライセンス
  - テキストは言語ごとにCC BY(-SA) 4.0系だが⚠️音声は学術・非商用研究・個人利用限定・再配布不可(ブログ等での一部抜粋公開のみ許可)
Laughterscape
- 内容
  - YouTube由来の大規模日本語「独話笑い」コーパス、6.04時間、24kHz、Demucsで雑音除去済みのdenoised/のみ収録(生データは別途問い合わせ制)
- 想定用途
  - 笑い声合成・笑い声検出の研究
- ライセンス
  - CC BY-SA 4.0
東北地方民話コーパス
- 内容
  - 昔話収集家が1957年から収集したオープンリール/アナログテープ由来の東北方言民話を書き起こし付きでデジタル化、16kHz wav、2話者
- 想定用途
  - 東北方言の音声認識・音声合成、方言保存研究
- ライセンス
  - 独自ライセンスだが比較的緩く、公序良俗に反する用途・話者を誹謗中傷する用途等を除き商用・非商用問わず音声言語の情報解析に利用可
JECS
- 内容
  - 日英コードスイッチング音声コーパス、バイリンガル声優1名、通常/単語強調/感情(少量)の発話、2.5時間、24kHz
- 想定用途
  - コードスイッチングTTS、多言語音声合成の研究
- ライセンス
  - テキストはCC BY 3.0、⚠️音声はアカデミック・非商用研究・個人利用(ブログ含む)限定で再配布不可
JSSS
- 内容
  - 単一女性話者(無響室収録)による8時間の音声、音声要約・発話スタイル平易化(やさしい日本語)・短文/長文発話のタスク別サブセット
- 想定用途
  - TTSの音声要約・スタイル平易化研究
- ライセンス
  - テキストはサブセットごとに異なる(CC BY-ND 2.1、非商用利用限定、CC BY-SA 4.0等)、⚠️音声はアカデミック・非商用研究・個人利用限定で再配布不可
JSSS-misc
- 内容
  - JSSSと同一話者・収録環境のおまけコーパス、ささやき声・低い声・裏声・方言パラレル発話のスタイル
- 想定用途
  - 発話スタイル(パラ言語)を変えたTTSの研究
- ライセンス
  - テキストはJVS/JMDコーパスから引用、⚠️音声はアカデミック・非商用研究・個人利用限定で再配布不可
JNV(Japanese Nonverbal Vocalization corpus)
- 内容
  - 笑い・すすり泣き・悲鳴等、感情を表す日本語の非言語発声コーパス、4話者(プロ1名含む)、420ファイル、406.9秒、48kHz
- 想定用途
  - 感情表現を伴う非言語発声の合成・認識研究
- ライセンス
  - CC BY-SA 4.0(商用含め制限なし、Takamichi群の中では珍しく音声も緩いライセンス)
JMD(熊本・大阪方言)
- 内容
  - 音声合成研究用の日本語方言テキスト+音声、熊本弁・大阪弁のサブセット
- 想定用途
  - 方言TTS・方言ASRの研究
- ライセンス
  - ⚠️アカデミック・非商用研究・個人利用限定で再配布不可(全データ共通)
Himawari(Himawari_CSJ_sample・Himawari_meidaiの2種類)
- 内容
  - CSJ(日本語話し言葉コーパス)サンプルと名大会話コーパスを、独自の全文検索ツール「Himawari」用のXML索引パッケージとして同梱したもの、素のwav音声集ではなく検索ツール込みの配布形式
- 想定用途
  - 話し言葉コーパスの全文検索・談話分析
- ライセンス
  - 記載なし(CSJ・名大会話コーパス本体は別途ライセンスあり、ここには含まれない可能性)
HTSデモデータ
- 内容
  - 高道研のコーパスではなく、名古屋工業大学HTS Working Groupが配布するHMM音声合成デモ用データ(ATR503文、単一男性話者、mgc/bap/lf0等のボコーダ特徴量)
- 想定用途
  - HTS/HMM方式の音声合成チュートリアル・デモ
- ライセンス
  - CC BY 3.0
出所不明の小規模コーパス(“EMOTION100”)
- 内容
  - “EMOTION100"と命名された90文の日本語音声(話者コードfm44)、感情ラベルなし、READMEなし
- 想定用途
  - 用途不明(感情音声のサンプルと推測)
- ライセンス
  - ⚠️記載なし・出所も未特定(他コーパスよりだいぶ後の日付でダウンロードされており、高道研サイト由来か別ソースか未確認)

テキストのみの台本コーパス

音声を含まず、朗読・録音用の台本(文章リスト)だけを配布しているコーパス。上記の音声コーパス群とは違い、それ自体を読み上げて誰かが別途録音する前提のもの

ITAコーパス

内容
- 音素バランスを考慮したパブリックドメインの日本語テキストコーパス、Emotion(100文)とRecitation(324文)のサブセットで構成、音声は含まれずテキストのみ
想定用途
- TTS/ASR研究用の朗読・録音台本、音素バランス評価のベンチマーク(実際に自前のTTS学習データ生成にも使用)
入手元
- github.com/mmorise/ita-corpus
ライセンス
- パブリックドメイン(Unlicense)
件数/サイズ
- 424文(テキストのみ)
形式
- txt

ROHAN(ROHAN4600)

内容
- モーラバランス型の日本語テキストコーパス、常用漢字と読みを全て含み低頻度モーラもカバーする4,600文、22のサブセットで構成、音声は含まれずテキストのみ
想定用途
- TTS研究用の朗読・録音台本、モーラバランス評価(実際に自前のTTS学習データ生成にも使用)
入手元
- github.com/mmorise/rohan4600
ライセンス
- CC0-1.0(パブリックドメイン)
件数/サイズ
- 4,600文(テキストのみ)
形式
- txt
備考
- 森勢将雅氏(明治大学)の研究成果、高道研コーパス群とは別の配布元(ローカルで同じフォルダに保存していたため混同していた)。VOICEVOX「ずんだもん」で読み上げた音声版は前掲の「感情・非言語発声・声質」を参照

ターン検出・対話制御

Smart Turn v3.2(test)

内容
- ターン検出モデル「Smart Turn v3.2」のテストセット、発話終端/フィラー等のラベル付き短い会話音声、23言語、CC0のFreesoundノイズも一部含む
想定用途
- 音声対話のターン検出(発話終端検出)モデルの評価
入手元
- huggingface.co/datasets/pipecat-ai/smart-turn-data-v3.2-test
ライセンス
- 明記なし(関連コードはBSD-2-Clause)
件数/サイズ
- 31,527件(4.6G)
形式
- Parquet

Smart Turn v3.2(train)

内容
- 同モデルの学習セット
想定用途
- 同上のモデルの学習
入手元
- huggingface.co/datasets/pipecat-ai/smart-turn-data-v3.2-train
ライセンス
- 明記なし(関連コードはBSD-2-Clause)
件数/サイズ
- 270,946件(39G)
形式
- Parquet

Easy-Turn-Trainset

内容
- 発話交替検出用の大規模データセット、完全/不完全/バックチャネル/待機の4状態、テキスト転記+発話交替状態ラベル付き、合計約1,100時間
想定用途
- 全二重音声対話システムにおける堅牢な発話交替(ターン)検出モデルの学習
入手元
- huggingface.co/datasets/0x3/Easy-Turn-Trainset
- 複製元: huggingface.co/datasets/ASLP-lab/Easy-Turn-Trainset(Northwestern Polytechnical University・Huawei)
ライセンス
- Apache-2.0
件数/サイズ
- 約1,906行(97.3G)
形式
- webdataset(Parquetに変換済み)

音声合成(TTS)エンジン(ツール)

ここまではデータセットだったが、ここからは自前で音声を生成したり、VAD・ASR・感情分析に使ったツール・学習済みモデルもまとめておく

Style-Bert-VITS2

内容
- Bert-VITS2をベースにした日本語向け高品質音声合成エンジン、話者ごとにスタイル(感情等)を制御可能
想定用途
- 日本語TTS、感情表現付き音声合成、単語リスト・全二重対話音声などの自前データ生成
入手元
- github.com/litagin02/Style-Bert-VITS2
ライセンス
- AGPL-3.0 / LGPL-3.0(コード。利用する話者ボイスモデルは別途各ボイスのライセンスに従う、例: JVNVボイス利用時はCC BY-SA 4.0)
備考
- 文脈埋め込みに日本語BERT(ku-nlp/deberta-v2-large-japanese-char-wwm、CC BY-SA 4.0)を使用し、疑問文/断定など文脈由来の韻律をピッチ・duration予測に反映している

Qwen3-TTS

内容
- Qwenチームによる多言語TTSモデル、3秒の音声サンプルで声質クローンやスタイル指示による制御に対応
想定用途
- 音声合成、話者クローン、感情・話速をコントロールした音声生成
入手元
- huggingface.co/Qwen/Qwen3-TTS-12Hz-1.7B-Base
ライセンス
- Apache-2.0
備考
- 日本語を含む10言語対応、0.6B/1.7Bの2サイズ

Irodori-TTS-Server

内容
- OpenAI TTS API互換の推論サーバ、Irodori-TTS-500M-v3モデルをラップしたもの
想定用途
- 日本語ASRの弱点(パ行・促音・濁音等)を狙った音声合成データの生成
入手元
- github.com/Aratako/Irodori-TTS-Server(モデル: huggingface.co/Aratako/Irodori-TTS-500M-v3)
ライセンス
- MIT(サーバ部分)
備考
- 音声コーデック(波形の潜在表現への圧縮・復元)にはfacebook/dacvae-watermarkedを日本語音声でファインチューニングしたAratako/Semantic-DACVAE-Japanese-32dim(WavLMによる意味蒸留を導入、潜在次元128→32に圧縮)を使用

Piper-Plus

内容
- 軽量・ローカル動作のニューラルTTS「Piper」の後継フォーク、VITS+韻律制御、ストリーミング対応
想定用途
- 軽量・高速な音声合成(CPU・組み込み用途にも対応)
入手元
- github.com/ayutaz/piper-plus
ライセンス
- MIT(オリジナルのrhasspy/piperはアーカイブ済み、後継のOHF-Voice/piper1-gplはGPL-3.0化されたため、MIT系フォークとして利用)
備考
- 日本語含む6言語対応(JA/EN/ZH/ES/FR/PT)、espeak-ng不要
- つくよみちゃんコーパスでファインチューニングした配布済みモデルも利用: huggingface.co/ayousanz/piper-plus-tsukuyomi-chan(MB-iSTFT+PQMFデコーダ、6言語、ベースは571話者で学習したpiper-plus-base)

Kokoro

内容
- 8,200万パラメータの軽量TTSモデル
想定用途
- 軽量・高速な音声合成
入手元
- huggingface.co/hexgrad/Kokoro-82M
ライセンス
- Apache-2.0
備考
- ⚠️推論コード・学習済み重みは公開されているが、自前でモデルを学習するための学習コードは公開されていない

VOICEVOX

内容
- 無料のテキスト読み上げ・歌声合成ソフトウェア、43話者127スタイル(2026年時点)のキャラクターボイスを収録
想定用途
- 日本語TTS、学習用の正例・hard negativeサンプルの大量合成(例: 「ヘイレオ」等の呼びかけフレーズ+紛らわしい語を全話者×全スタイルで合成)
入手元
- voicevox.hiroshiba.jp
ライセンス
- エンジン本体はLGPL-3.0。生成音声はクレジット表記により商用・非商用問わず利用可だが、⚠️キャラクターごとに個別の利用規約があるため使用前に要確認
備考
- Linux版はCPU/NVIDIA GPU版のランタイムが配布されている

KVoiceWalk

内容
- ランダムウォークとResemblyzer類似度等を組み合わせたスコアリングで、Kokoroのスタイルベクトル(声質)を目標音声に近づけて探索するツール
想定用途
- Kokoroの学習コードが非公開のため、既存スタイルベクトルの合成・探索によって新しい声を作る代替手段
入手元
- github.com/RobViren/kvoicewalk
ライセンス
- Apache-2.0
備考
- 探索文への過学習(未知テキストで類似度が大幅低下)や、英語声が混ざると韻律が汚染される等の限界を実際に確認済み

kokovoicelab

内容
- Kokoroの既存話者を補間・ブレンドして新しい声を作り、SQLiteデータベースで管理するツール(KVoiceWalkと同じ作者)
想定用途
- Kokoroの声を混ぜ合わせた新規ボイスの生成、生成した声のDB管理
入手元
- github.com/RobViren/kokovoicelab
ライセンス
- 記載なし(リポジトリにLICENSEファイルなし)

Qwen-Audio-3.0-TTS-Flash(参考)

内容
- Alibaba Tongyi Labが2026年7月にリリースしたホスト専用TTS API、Flash/Plusの2ティア構成
想定用途
- 低レイテンシ(初回パケット200ms以内)なリアルタイム音声対話用TTSの参考(重み非公開のためローカル・組み込み用途には使えない)
入手元
- qwen-audio-3.0-tts-flash(OpenRouter)
ライセンス
- ⚠️非OSS(ホスト専用API、DashScope経由でのみ利用可能)
備考
- 16言語対応、$15/100万文字

StyleTTS2

内容
- スタイル拡散とAdversarial Trainingを組み合わせたTTSアーキテクチャ、Kokoroのベースにもなっている
想定用途
- 高品質TTSのアーキテクチャ調査・比較検討(自前運用はせず比較対象として利用)
入手元
- github.com/yl4579/StyleTTS2
ライセンス
- MIT(コード)、ただし推論はGPLライセンスのパッケージに依存する箇所があり、学習済みモデル利用時は追加の倫理条項(合成音声である旨の告知、話者の許諾なき音声クローン利用の禁止等)に同意が必要
備考
- 検証の結果、Kokoroの日本語モデル(jf_alpha)はStyleTTS2ベースでも音素CERでSBV2(VITS2系)に劣っており、「アーキテクチャよりデータと言語別フロントエンドが効く」という結論の根拠になった

VAD・ターン検出(ツール)

Silero VAD

内容
- 事前学習済みの軽量VADモデル、30ms以上の音声チャンクを1ms未満で判定
想定用途
- 発話区間検出、無音除去、ASR前処理
入手元
- github.com/snakers4/silero-vad
ライセンス
- MIT

Smart Turn v2

内容
- 生の音声波形から「発話が終わったか」を判定するターン検出モデル、wav2vec2エンコーダ+線形分類ヘッド構成
想定用途
- 音声対話エージェントのターン検出、リアルタイム文字起こし
入手元
- huggingface.co/pipecat-ai/smart-turn-v2
ライセンス
- BSD-2-Clause
備考
- 14言語対応(日本語含む)、94.8Mパラメータ

Smart Turn v3

内容
- Smart Turnの後継版、Whisper Tinyをベースにした軽量ターン検出モデル
想定用途
- CPUのみでのリアルタイムターン検出(GPU不要)
入手元
- huggingface.co/pipecat-ai/smart-turn-v3
ライセンス
- BSD-2-Clause
備考
- 23言語対応、約8Mパラメータ、int8量子化版・fp32版あり、CPU推論12ms(最新CPU)。前掲のsmart-turn-data-v3.2-test/trainはさらに後継のv3.2系列の学習データ

UltraVAD

内容
- Llama-8Bベースの音声・対話履歴融合型エンドポイント検出モデル、発話終了トークンの確率を推定
想定用途
- 文脈を考慮したターン検出(Smart Turn v2より高精度)
入手元
- huggingface.co/fixie-ai/ultraVAD
ライセンス
- 記載なし
備考
- 26言語対応(日本語含む)、文脈依存ターン交代タスクで精度77.5%(Smart Turn v2は63.0%)、推論にVRAM約10GBを使用

MaAI(京都大学)

内容
- 会話AI・ロボット向けの軽量リアルタイム非言語行動予測ソフトウェア、VAD・ターンテイキング・バックチャネル・頷きを予測、Voice Activity Projection(VAP)モデルがベース
想定用途
- 対話システムのターンテイキング予測・相槌タイミング推定
入手元
- github.com/MaAI-Kyoto/MaAI
ライセンス
- コードはMIT、学習済みモデルは個別ライセンス(MimiエンコーダはCC BY 4.0)
備考
- 京都大学・井上昂治氏らが開発、日本語含む複数言語対応、CPUでも動作

Sparrow-1(Tavus、参考)

内容
- リアルタイム音声・映像対話における会話タイミング制御モデル、「いつ聞き・待ち・話すか」を予測
想定用途
- 人間らしい会話タイミングを持つ音声対話エージェントの参考(自前では未使用、比較調査のみ)
入手元
- tavus.io/blog/sparrow-1
ライセンス
- ⚠️非OSS(Tavus独自、APIを通じてのみ利用可能)

Easy-Turn

内容
- 発話交替検出モデル本体、「対話終了」「不完全な発話」「バックチャネル」「待機要求」の4状態を音声+言語情報から予測(前掲のEasy-Turn-Trainsetで学習)
想定用途
- フルデュプレックス音声対話システムでの「話す/聞く/沈黙する」タイミング判定
入手元
- huggingface.co/0x3/Easy-Turn
- 複製元: huggingface.co/ASLP-lab/Easy-Turn(Northwestern Polytechnical University)
ライセンス
- Apache-2.0
備考
- モデルサイズ約850MB

ウェイクワード検出(ツール)

openWakeWord

内容
- 音声埋め込みモデル+軽量な検知ヘッドで構成されるオープンソースのウェイクワード(呼びかけ語)検出フレームワーク
想定用途
- 「ヘイ〇〇」のような呼びかけ語の検出、独自ウェイクワードの学習(埋め込みの上に自前ヘッドを追加して学習可能)
入手元
- github.com/dscripka/openWakeWord
ライセンス
- コードはApache-2.0だが、同梱の学習済みモデルは⚠️CC BY-NC-SA 4.0(非商用、ライセンス不明なデータセットを学習に含むため)
備考
- 実プロジェクトでは埋め込み抽出器のみ利用し、その上に独自の小型MLPヘッドをBCE損失で学習する構成で使用

LiveKit WakeWord

内容
- LiveKitによるオープンソースのウェイクワード検出ライブラリ、音声対話アプリケーション向け
想定用途
- リアルタイム音声対話エージェントでの呼びかけ語検出(openWakeWordの比較対象として調査)
入手元
- github.com/livekit/livekit-wakeword
ライセンス
- Apache-2.0

ASR(音声認識ツール)

faster-whisper

内容
- OpenAI WhisperをCTranslate2で高速再実装したASR実装、精度を保ちつつ最大4倍高速化
想定用途
- 音声認識の高速推論(ローカル・バッチ処理)
入手元
- github.com/SYSTRAN/faster-whisper
ライセンス
- MIT

Kotoba-Whisper

内容
- ReazonSpeechで学習した日本語ASR向けの蒸留Whisperモデル、large-v3と同等の精度を保ちつつ6.3倍高速
想定用途
- 高速な日本語ASR推論
入手元
- huggingface.co/kotoba-tech/kotoba-whisper-v2.0
ライセンス
- Apache-2.0
備考
- v1.0はReazonSpeechのlargeサブセット、v2.0は全サブセットで学習、v2.2は後処理パイプライン統合版

SenseVoice

内容
- ASR・言語識別(LID)・音声感情認識(SER)・音響イベント検出(AED)を1モデルでこなす音声基盤モデル、中国語(標準語・広東語)・英語・日本語・韓国語に対応
想定用途
- 多言語ASRに加え、感情認識・音響イベント検出を同時に行いたい用途
入手元
- huggingface.co/FunAudioLLM/SenseVoiceSmall
ライセンス
- ⚠️独自ライセンス(FunASR Model License Agreement、Alibaba独自の利用規約、標準的なOSSライセンスではない)

Whisper large-v3 / large / large-v3-turbo

内容
- OpenAIの多言語音声認識モデル、turboは軽量化されたデコーダ構成で高速化された派生版
想定用途
- 汎用ASR、ReazonSpeechの再書き起こし(前掲のwhisper_transcriptions.reazonspeech.small.wer_10.0参照)等
入手元
- huggingface.co/openai/whisper-large-v3
- turbo版: huggingface.co/openai/whisper-large-v3-turbo
ライセンス
- large-v3はApache-2.0、turboはMIT

Parakeet 0.6B ja(NVIDIA NeMo)

内容
- ReazonSpeech v2.0(3.5万時間超)で学習した日本語ASRモデル、Hybrid FastConformer TDT-CTC構成
想定用途
- 高速・高精度な日本語ASR
入手元
- huggingface.co/nvidia/parakeet-tdt_ctc-0.6b-ja
ライセンス
- CC BY 4.0
備考
- NVIDIA NeMoフレームワーク上で推論・ファインチューニング

ReazonSpeech-NeMo-v2

内容
- ReazonSpeech開発元自身が公開するNeMoベースの日本語ASRモデル(NVIDIA製Parakeetとは別に、Reazon自身が学習・配布)
想定用途
- 日本語ASR(自社データで学習した公式モデル)
入手元
- huggingface.co/reazon-research/reazonspeech-nemo-v2
ライセンス
- Apache-2.0

Qwen3-ASR

内容
- Qwen3-Omniをベースにした多言語ASRモデル、言語識別+音声認識に対応
想定用途
- 多言語ASR(52言語・方言)、雑音下での頑健な認識
入手元
- huggingface.co/Qwen/Qwen3-ASR-1.7B
ライセンス
- Apache-2.0
備考
- 0.6B/1.7Bの2サイズ、タイムスタンプ推定用のQwen3-ForcedAlignerも同系統で提供

Kaldi

内容
- 音声認識研究で長年使われてきた伝統的なASRツールキット(GMM-HMM〜DNN-HMM)
想定用途
- 音声認識モデルの学習・研究、MFA(後述)のバックエンドとしても利用
入手元
- github.com/kaldi-asr/kaldi
ライセンス
- Apache-2.0

Sherpa(sherpa-onnx)

内容
- k2-fsaによる「次世代Kaldi」ベースの音声処理フレームワーク、ASR・TTS・話者ダイアライゼーション・音声強調・VAD等をonnxruntimeでオフライン実行
想定用途
- 組み込み・オフライン環境での音声認識・音声合成・VAD等
入手元
- github.com/k2-fsa/sherpa-onnx
ライセンス
- Apache-2.0

Julius

内容
- 京都大学・奈良先端科学技術大学院大学・名古屋工業大学が開発した日本語大語彙連続音声認識エンジン
想定用途
- 日本語ASR
入手元
- github.com/julius-speech/julius
ライセンス
- 独自ライセンス(BSD系、改変版を含め商用利用可)

ESPnet

内容
- PyTorchベースのEnd-to-End音声処理ツールキット、ASR・TTS・話者ダイアライゼーション・音声翻訳等に対応
想定用途
- End-to-Endな音声認識・音声合成モデルの学習・研究
入手元
- github.com/espnet/espnet
ライセンス
- Apache-2.0

VOSK

内容
- Kaldiベースのオフライン音声認識ツールキット、モデルサイズが小さく(約50MB〜)、20以上の言語・方言に対応
想定用途
- オフライン・省リソース環境でのASR、ストリーミング認識、話者識別
入手元
- github.com/alphacep/vosk-api
ライセンス
- Apache-2.0
備考
- Python/Java/Node.js/C#/C++/Rust/Go等多言語バインディング対応、日本語モデルも配布されている

日本語HuBERT(rinna/japanese-hubert-base)

内容
- 自己教師あり学習による日本語音声表現モデル(CTCヘッド等の下流タスク層は無し、音声の生の隠れ層を出力)
想定用途
- ASRの出力に頼らず、音声の隠れ層を直接使う音韻・音響特徴の分析(例: 線形プローブでの音韻構造の分類)、下流タスクのファインチューニングのベースモデル
入手元
- huggingface.co/rinna/japanese-hubert-base(公開ミラー: huggingface.co/yky-h/japanese-hubert-base)
ライセンス
- Apache-2.0
備考
- 実プロジェクトでは、CTCデコード後のテキストに頼るASRよりも生の隠れ層(特に中間層)の方が音韻構造を線形分離可能な形で保持しているという知見が得られた

Forced Alignment(ツール)

Montreal Forced Aligner(MFA)

内容
- 音声と書き起こしテキストから音素単位のタイムスタンプを推定するForced Alignmentツール、日本語音響モデル+G2Pモデル(japanese_mfa)を使用
想定用途
- 音素レベルのアラインメント生成(例: 「レオ」を子音ɾ・母音e・母音oに分解)
入手元
- github.com/MontrealCorpusTools/Montreal-Forced-Aligner
ライセンス
- MIT
備考
- バージョン3.4.1で使用、内部エンジンはKaldiベース

感情分析(ツール)

LUKE(studio-ousia/luke-japanese-large-lite)

内容
- RoBERTa系のTransformerをベースに、単語だけでなくWikipediaのエンティティ(固有名詞などが指す実体)も同時に埋め込む、エンティティ認識型のSelf-Attentionを持つテキストエンコーダ
想定用途
- 固有表現認識(NER)、関係分類、エンティティが絡む質問応答など、ベースモデルとしての利用。下記のluke-japanese-large-sentiment-analysis-wrimeのように、感情分析等へファインチューニングして使うことも多い
入手元
- huggingface.co/studio-ousia/luke-japanese-large-lite
ライセンス
- Apache-2.0
備考
- 音声ではなくテキスト入力。原論文はYamada et al., 2020(Studio Ousia)

luke-japanese-large-sentiment-analysis-wrime

内容
- 日本語テキストの8感情(喜び・悲しみ・期待・驚き・怒り・恐れ・嫌悪・信頼)を推定するテキスト分類モデル
想定用途
- ASRの書き起こしテキストに対する感情分析、対話ログの感情ラベリング
入手元
- huggingface.co/Mizuiro-sakura/luke-japanese-large-sentiment-analysis-wrime
ライセンス
- MIT
備考
- ベースモデルはstudio-ousia/Luke-japanese-large-lite、WRIMEデータセットでファインチューニング、音声ではなくテキスト入力

ModernBERT

内容
- Answer.AI・LightOnが2024年に公開した、BERTを現代的なアーキテクチャ(RoPE、GeGLU、Flash Attention、8192トークンまでの長いコンテキスト長など)で作り直したテキストエンコーダ。base(149M)・large(395M)の2サイズ
想定用途
- 音声そのものは扱わないが、ASRの書き起こしテキストへの後処理(句読点復元、感情分析等のファインチューニングのベースモデル)に使える汎用テキストエンコーダ
入手元
- huggingface.co/answerdotai/ModernBERT-base / ModernBERT-large
ライセンス
- Apache-2.0
備考
- 学習データは主に英語・コードのため、日本語タスクへは追加の日本語ファインチューニングが必要。音声ではなくテキスト入力

音声透かし(ツール)

SilentCipher

内容
- 音声信号にメッセージを埋め込む音声透かし(オーディオウォーターマーキング)モデル、心理音響モデルに基づく閾値制御で人間に知覚されにくい透かしを実現
想定用途
- 生成音声への出所情報の埋め込み、音声の改ざん検知
入手元
- huggingface.co/Sony/SilentCipher
ライセンス
- MIT
備考
- 16kHz/44.1kHzの音声に対応

音声データをネットから調達する方法(サイト・ツール)

配布済みのデータセットだけでなく、特定の単語・フレーズの発話サンプルが少量だけ欲しい場合は、動画・音声検索サイトから自分で音声を切り出して集める方法もある。実際に特定の単語の発話サンプルを集めるために使った方法をまとめる

単語・フレーズ検索サイト

内容
- YouTubeやアニメ・映画の字幕/文字起こしから、特定の単語やフレーズが登場する場面を検索して再生できるサイト群
対象サイト
- YouGlish(youglish.com/japanese): YouTube動画の字幕から検索語が出る場面を探し、該当箇所から再生できる、自然な会話中の発話を連続で聞くのに向く
- Filmot(filmot.com): YouTubeの字幕・文字起こしを横断検索できる、特定の単語を含む動画を一覧で探すのに向く
- Nadeshiko(nadeshiko.co): アニメやドラマなどの日本語セリフを音声・画像付きで検索できる
- Immersion Kit(immersionkit.com): アニメの日本語例文を音声・画像付きで検索できる
- Japanese Sentence Search(sentencesearch.neocities.org): ネイティブ音声付きの日本語例文を検索できる
- Forvo(ja.forvo.com/languages/ja): ネイティブ話者による単語・短文の発音辞書
- PlayPhrase.me(playphrase.me): 映画・ドラマのセリフを短い映像クリップで検索できる
ライセンス
- ⚠️各サイトの利用規約に従う、著作物由来の音声のため個人の学習・研究目的を超える利用(再配布・商用データセット化等)は要確認

データセットの索引サイト

内容
- 配布済みの音声・言語データセットをまとめて探せる索引サイト
対象サイト
- OpenSLR(openslr.org/resources.php): 音声認識・音声合成向けの公開データセットを番号付きリソースとして一覧できる索引サイト(前掲のMUSAN等もここで配布されている)

yt-dlp

内容
- YouTube等の動画・音声・字幕をダウンロードするコマンドラインツール
想定用途
- 上記サイトで見つけた動画の音声・字幕の取得、自動字幕からのキーワード検索によるデータ収集パイプラインの構築
入手元
- github.com/yt-dlp/yt-dlp
ライセンス
- パブリックドメイン(Unlicense)
備考
- 実際のパイプラインでは、自動字幕(vttのみ先にチェック)→ヒットした動画のみ音声DL→前掲のfaster-whisper(large-v3)で単語タイムスタンプを特定して切り出し→再文字起こしで検証、という流れで使用した
- 大量アクセスでbot検知に引っかかる場合は、無料プロキシリスト(iplocate/free-proxy-list等)から動作確認済みのものを経由することを検討するとよい

利用上の注意

TalkBank系(CALLFRIEND・CALLHOME・SAKURA)は、HF上のライセンスタグが無い、または緩く見えても、TalkBank本体は独自のGround Rules(研究利用・倫理規定への同意必須、再配布制限)に従う必要がある
ReazonSpeech系は「日本国著作権法第30条の4の目的に限り使用可」という日本法特有の制限が明記されており、単純なCC-BY-SAと誤解しないこと
MagicHubの日本語自然会話・Global Conversational Speechは商用データセットで、再配布・商用利用不可、または利用前に別途契約が必要
非商用限定のものとして、CALLHOME(CC-BY-NC-SA)・ESC-50(CC-BY-NC)・JVS/JVS-MuSiC(音声は非商用研究限定)・TAU Urban Acoustic Scenes 2022(非商用研究目的限定)・WHAM!(CC BY-NC 4.0)・SeniorTalk(CC BY-NC-SA 4.0)がある
Genshin-Voice-Jaのようにゲーム等の著作物由来のキャラクターボイスは、配布元にライセンス記載がなくても元コンテンツの著作権・商標が別途及ぶ可能性があるので特に注意
1つのデータセット名の下に複数コーパスが混在しているもの(DNS-Challenge、Takamichi研究室コーパス群)は、まとめて1つのライセンスとして扱わず個別コーパス・ファイル単位で確認すること
ライセンス「記載なし」のものは、再配布・公開前に必ず一次配布元を確認すること

まとめ

音声認識・音声合成・話者ダイアライゼーション・ターン検出・環境音分類など、用途別に無料で使える音声・音響データセットをカタログ化した
あわせて、自前で音声生成やVAD・ASR・感情分析に使ったツール・学習済みモデル、特定の単語・フレーズをネットから自分で集める方法もまとめた
CC0やCC BYなど素直に使えるものが多い一方で、TalkBank系や日本国著作権法30条の4限定のものなど、「無料公開」に見えて実は利用条件が細かく決まっているデータセットも少なくない
「記載なし」のライセンスは自由利用の許可ではないので、使う前に一次配布元を必ず確認する
新しく良いデータセット・ツールを見つけたら随時追記していく
まあ、色々と使ったものだ、20TBぐらいのHDDが結構満パンになってしまった

GoogleのSODAの日本語オンデバイスASRモデルの仕組み

Wed, 10 Jun 2026 22:01:26 +0900

背景

ChromeOSの日本語SODAモデルを解剖した
SODA は Google のオンデバイス音声認識まわりで使われている仕組み。ライブ字幕、音声入力、音声コマンドの裏側にいるやつ
前に書いた音声系の技術メモでは、ASR、VAD、TTS、フルデュプレックス会話、リングバッファ、句読点、Endpointing などの用語を整理した。今回はその続きとして、実際のオンデバイス ASR モデルがどういう部品でできているかを見た
見たかったのはこのあたり:
- オンデバイス ASR がどのくらいのサイズで動いているか
- VAD と ASR 本体がどう分かれているか
- prefetch が何をしているか
- 語頭を落とさないために何をしているか
- EOT、つまりターン終了をどう判断しているか
- RNN-T、LAS、FST がどう組み合わされているか
- 日本語向けにどんな辞書やコンテキスト注入が入っているか
- OSS で似たものを作るなら何が必要か

先に結論

見えた構成はかなり堅い
軽い VAD を常時動かし、重い Conformer Encoder は発話区間だけに使う
RNN-Tで逐次認識し、FSTで言語スコアを持ち、LAS Rescorerで候補を再評価する
最後に句読点、normalizer、context injection が効く

特に重要なのはこの3つ。

prefetch.decision は別モデルではなく、同じ VAD posterior を別閾値で解釈したもの
SHORT モードは prefetch 閾値が 0.17 と低く、語頭を拾うためにかなり攻めている
EOT は VAD だけでなく、音響スコア、FST/LAS の言語スコア、hotword、DecoderEndpointerStream の統合パラメータで決まる

「話したら文字になる」だけに見えるが、実際にはかなり細かい交通整理がある。

基本情報

項目	値
言語	ja-JP
バージョン識別子	`cnch24d3` (Conch 2024, revision 3)
内部バージョン	v5072
アーキテクチャ	Causal Conformer Encoder + RNN-T Decoder
合計サイズ	約 138MB（全ファイル合計）
ランタイム	TFLite (`TFL3` FlatBuffer, MLIR変換済み)
設定フォーマット	Protocol Buffers (バイナリ)
ビルド日時	2024年7月2日 15:00:00（訓練完了）
リリース日時	2025年1月7日（ChromeOS R133 DLC）
経過時間	2026年6月時点で約 17ヶ月前

世代・バージョン体系

世代	識別子	時期	備考
Legacy	`df24d2`	〜2024年以前	旧世代
Conch	`cnch24d3`	2025年1月	← これ

cnch24d3 = Conch 24 (2024年設計) d3 (第3リビジョン)。Conch世代でアーキテクチャ刷新。

サーバーモデルをオンデバイス向けに変換したもの：

1

/placer/prod/home/speech-placer/.../20240702150000_OD_CONVERTED_DEFAULT_SERVER_V101_WITH_CONFIDENCE/

OD_CONVERTED = On-Device 変換済み、V101_WITH_CONFIDENCE = confidence スコア付き v101

全体パイプライン

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74


PCM音声 (s16le, 16kHz, mono)
 │
 ▼
[AudioDecoderStream] → waveform
 │
 ▼
[Framer] frame=25ms(400samples), shift=10ms(160samples)
 │
 ▼
[Window (Hann窓)] → windowed frames
 │
 ▼
[FFT]
 │
 ▼
[FilterBank] 80次元 log-mel フィルタバンク
 │
 ▼
[FrameStacker × N] → [SubsampleStream]
 │
 ├──────────────────────────────────────────────────┐
 │ │
 ▼ 【VAD パス（軽量・並列）】 │ 【エンコーダパス（重・ゲート制御）】
[AppendClusterIdStream] │
(VOICE_SEARCH/CAPTION/FARFIELD/TELEPHONY) │
 │ │
 ▼ │
[VAD LSTM: 436KB] │
 → prefetch.decision │
 → vad.audio_level_events │
 → vad.decision ─────────────────────────────────┐ │
 → vad.decision_for_segmenter │ │
 │ │ │
 ▼ │ │
 [EndpointerEventStream] │ │
 [SegmenterStream] ◄───────────────────────────┘ │
 │ (発話フレームのみ通過) │
 ├──────────────────────────────────────────────┘
 ▼
[FrameNormalizeStream] (mean_stddev: 240次元)
 │
 ▼
[AppendClusterIdStream (TELEPHONY)]
 │
 ▼
[FrameStacker] → [SubsampleStream] (エンコーダ用積み重ね)
 │
 ▼
[CausalEncoderStream]
 Conformer × 12層 (107MB)
 ← streaming states: 85テンソル
 │
 ▼
[DecoderEndpointerStream]
 RNN-T Decoder + EndpointerStream
 ← vad.decision (音響的発話判断)
 ← prefetch.decision (先読み音響判断)
 ← FST言語モデル (言語的文完成度判断)
 │
 ├── 2nd Pass: LAS Rescorer (3.9MB)
 │
 ▼
[CombinedResultStream]
 │
 ▼
[後処理パイプライン]
 1. remove_decorators (FST)
 2. pron_cleanup (FST)
 3. CapitalizationNormalizer (FST)
 4. PunctuationNormalizer (BiLSTM 2.5MB)
 5. porn_normalizer (FST)
 │
 ▼
[RecognitionEventStream] → テキスト出力

ファイル一覧・サイズ詳細

endtoendmodel/ (メイン ASR)

ファイル	サイズ	役割
`large-encoder.tflite`	107MB (108,803KB)	Causal Conformer Encoder
`large-decoder.tflite`	8.6MB (9,025KB)	RNN-T LSTM Decoder
`large-joint_posterior.tflite`	4.6MB (4,865KB)	Joint Network: AM+LM posterior
`large-joint_prior.tflite`	4.3MB (4,429KB)	Joint Network: LM prior のみ
`large-rank_candidates_acoustic.tflite`	3.8MB (4,030KB)	LAS N-best Rescorer
`large.wpm.portable`	188KB	WordPiece モデル (サブワード分割)
`large.syms.compact`	31KB	語彙シンボルテーブル (OpenFST CompactSymbolTable)
`ONDEVICE_LARGE_CONTINUOUS.mean_stddev`	1.9KB	フィルタバンク正規化パラメータ (240次元)
`ONDEVICE_LARGE_SHORT.mean_stddev`	1.9KB	同上 (SHORT モード用・同一値)

エンコーダが全体の 94% を占める。 これがボトルネック。

acousticmodel/ (VAD / エンドポインタ)

ファイル	サイズ	用途
`DEFAULT_BF_VAD_EP_MD_UF_DARWINN_CONTINUOUS.endpointer_portable_lstm_model`	436KB	連続発話 VAD LSTM
`DEFAULT_BF_EOQ_EP_MD_UF_DARWINN_SHORT.endpointer_portable_lstm_model`	436KB	短文用 VAD LSTM (EOQ)
`SODA_DICTATION_EP_UNIFIED_FRONTEND_LANGID.endpointer_portable_lstm_model`	471KB	言語ID統合 VAD
`*.endpointer_portable_lstm_mean_stddev`	2.0KB	VAD 特徴量正規化 (256次元)
`SODA_DICTATION_EP_UNIFIED_FRONTEND_LANGID.endpointer_portable_lstm_mean_stddev`	4.1KB	LangID 統合 VAD 正規化 (528次元)

denorm/ (後処理)

ファイル	サイズ	役割
`lm.pruned.sorted.fst`	12MB	FST 言語モデル (プルーニング済みソート済み)
`lm.pruned.sorted.syms`	1.4MB	FST 言語モデル語彙
`transducer.pruned.fst`	3.6MB	トランスデューサ FST
`PUNCTUATION_LSTM.model.int8.tflite`	2.4MB	句読点挿入 BiLSTM (int8量子化)
`PUNCTUATION_LSTM.syms`	20KB	句読点 LSTM 語彙 2,332トークン
`porn_normalizer_ondevice.mfar`	616KB	不適切語フィルタ (MFAR=Mapped FST Archive)
`pron_cleanup_denormalizer.mfar`	28KB	発音整形
`remove_decorators_ondevice.mfar`	336KB	装飾除去
`punctuation_converter_config.pb`	76KB	句読点変換マッピング (protobuf)

langid/ (言語識別)

ファイル	サイズ	役割
`ONDEVICE_langid.tflite`	2.4MB	43言語識別 Conformer モデル
`application_params_langid_stream_multiclass_ONDEVICE`	528B	対応言語リスト・設定

context_prebuilt/ (コンテキスト注入)

ファイル	サイズ	役割
`mozc.dic`	9.4MB	Mozc 辞書 (日本語形態素解析)
`japanese_family_name.txt`	125KB	日本語姓名辞書
`portable_ja_verbalizer.far`	1.2MB	数字・記号→日本語読み FST
`ja-JP_nga_popular-media_STD_FST.fst`	228KB	メディアタイトル FST
`ja-JP_nga_hotword-popular-media_STD_FST.fst`	228KB	ホットワード+メディア FST
`ja-JP_nga_device-actions_STD_FST.fst`	99KB	デバイス操作コマンド FST
`ja-JP_assistant_hotword_STD_FST.fst`	2KB	アシスタントホットワード FST
`songs.txt` / `apps.txt` / `contacts.txt` 等	各数KB〜128KB	動的コンテキスト用テキスト

音声フロントエンド詳細

特徴量パラメータ（config から確定）

ステップ	パラメータ
サンプリングレート	16,000 Hz
フレーム長	400 samples = 25ms
フレームシフト	160 samples = 10ms
窓関数	Hann窓
FilterBank 次元数	80次元 log-mel
VAD 入力	80-mel フレーム × 3 = 240次元 + クラスタ ID 16次元 = 256次元
Encoder 正規化入力	80-mel × 3フレーム積み重ね = 240次元

正規化パラメータ（mean_stddev から実測）

エンコーダの 240次元入力に対する統計量 (CONTINUOUS = SHORT, 同一値)：

統計量	最小値	最大値	特徴
平均 (mean)	7.398	9.262	log-mel エネルギースケール
標準偏差 (stddev)	1.643	4.026	高周波帯ほど分散大

平均が 7〜9 ≈ log(1000〜8000)スケール → log-mel フィルタバンクの典型値 ✓
標準偏差が後半(高周波)ほど大きい → 環境ノイズの影響を受けやすい高周波の分散が大 ✓

VAD の 256次元：

Field 1 (mean): 範囲 [0.000, 8.379]（クラスタID次元は 0 付近）
Field 2 (stddev): 範囲 [1.000, 3.703]

Conformer Encoder 詳細

モデル規模

項目	値
ファイルサイズ	107MB
Conformer ブロック数	12層 (conf_0 〜 conf_11)
入力次元	240次元 (80-mel × 3フレーム積み重ね)
ストリーミング状態テンソル	85個 (previous_state.00 〜 .84)
ストリーミング状態/層	≈ 7 state tensors × 12層 + 1
モデル変換	MLIR Converted (TensorFlow → TFLite)
TFLite バージョン	TFL3 (min runtime: 2.19.0)

各 Conformer ブロックの構造（全12層共通）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


入力 x
 │
 ▼
[fflayer_start] — Feed-Forward 1 (×0.5 Macaron scale)
 │
 ▼
[trans_atten] — Multi-Head Self-Attention (因果的・動的長さ)
 └─ multihead_atten/StreamStep/dynamic_length
 ← streaming で left-context のみ参照（Causal）
 │
 ▼
[lconv] — Local Convolution Module
 └─ depthwise_conv/strided_slice (深さ方向畳み込み)
 │
 ▼
[fflayer_end] — Feed-Forward 2 (×0.5 Macaron scale)
 │
 ▼
[output_ln] — Layer Normalization
 │
 ▼
出力

これは Macaron-style Conformer (Chan et al., 2022)：

FFN を MHSA の前後に配置（0.5 スケール）
Local Convolution が音響的局所パターンを学習
Causal MHSA がグローバルな依存関係を学習
streaming 推論のため dynamic_length で左コンテキストのみ参照

ストリーミング実装の構造

TFLite の状態テンソル名からわかる 3段構成：

1
2
3


conformer_encoder_1: previous_state.00〜.84 (入力状態テンソル, 85個)
conformer_encoder_2: 実際の計算グラフ (extractor/graph_layer/conf_0〜conf_11)
conformer_encoder_3: next_state.00〜.84 (出力状態テンソル, 85個)

各フレームを逐次処理し、状態テンソルで文脈を保持する streaming 設計。

RNN-T Decoder 詳細

アーキテクチャ

項目	値
ファイルサイズ	8.6MB
型	シンプル LSTM Decoder
状態テンソル	`previous_decoder_state_0` / `next_decoder_state_0` (1ペア)
入出力	`inputs` → `outputs`

単一 LSTM セル（状態テンソルが 1つだけ）のシンプルな Prediction Network。

Joint Network の分離設計

Joint Network が posterior と prior に分離されている：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


Encoder出力 (am) + Decoder出力 (lm)
 │
 ┌────┴────────────────────┐
 │ │
 ▼ ▼
[joint_posterior.tflite] [joint_prior.tflite]
am_proj + lm_proj_1 lm_proj_2 のみ
 │ Tanh → LogSoftmax │ Tanh
 │ │
 ▼ ▼
P(y|x, y_{<t}) P(y|y_{<t})
 (音響+言語) (言語のみ)

なぜ分離するか：

posterior / prior により、暗黙的な LM shallow fusion が可能
テスト時に LM の重みを調整できる
joint_prior は LM のみなので、LM 置き換え (LM subtraction) にも使える
lm_proj_1/MatMul = 音響+言語の合算投影
lm_proj_2/MatMul = 言語単独投影（prior）

Joint Network の演算グラフ（posterior）

1
2
3
4
5
6
7
8
9


concat(am_proj, lm_proj) → Tanh → add_1
 ↓
am_proj_1/MatMul → lm_proj_1/MatMul → MatMul;add_2
 ↓
Softplus → Softplus1 → Softplus2
 ↓
strided_slice_1 → Neg_1 → sub_12 → add_3;Neg_1
 ↓
LogSoftmax → outputs

2nd Pass Rescorer (LAS)

アーキテクチャ概要

項目	値
ファイルサイズ	3.8MB
アーキテクチャ	Listen, Attend, Spell (LAS)
用途	N-best 仮説の再スコアリング + confidence

演算グラフ（child_decoders_0）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


入力: encoded (エンコーダ出力), candidate_labels (N-best仮説), encoded_padding
 │
 ▼
[embedding_lookup] + [位置エンコーディング (Sin/Cos)]
 │
 ▼
[self_atten] — Self-Attention (仮説内部の依存関係)
 └─ MultiHeadedAttention/ComputeContextVectorWithSource
 PackSource (K,V キャッシュ)
 │
 ▼
[aux_atten] — Cross-Attention (エンコーダ出力への注意)
 └─ MultiHeadedAttention/ComputeContextVectorWithSource
 │
 ▼
[fflayer] — Feed-Forward (tr_fflayer, layer norm付き)
 └─ fflayer_0 (Relu) → fflayer_1
 │
 ▼
[confidence_source_proj/MatMul]
 │
 ▼
[confidence_mlp_0] — Confidence スコア出力
 └─ Sigmoid (信頼度 0〜1)
 │
 ▼
outputs: スコア (仮説ランキング用)

INFLUENCE_MODEL_TWIDDLER = 再スコアリング重みを実行時に調整する仕組み（A/Bテスト・実験対応）。

VAD / EOQ LSTM 詳細

3種類の VAD モデル

モデル名	サイズ	用途
`DEFAULT_BF_VAD_EP_MD_UF_DARWINN_CONTINUOUS`	436KB	連続発話用 (字幕・ライブ)
`DEFAULT_BF_EOQ_EP_MD_UF_DARWINN_SHORT`	436KB	短文用 EOQ (IME・コマンド)
`SODA_DICTATION_EP_UNIFIED_FRONTEND_LANGID`	471KB	言語ID 統合 VAD (多言語)

入力特徴量

1
2
3
4
5
6
7


VAD 入力 = 256次元
 = 80-mel × 3フレーム (240次元) ... 実測 mean ~6-8 (log-mel scale)
 + クラスタ ID 埋め込み (16次元) ... mean ~0 付近

クラスタ ID の種類:
 CONTINUOUS モード: VOICE_SEARCH, CAPTION, FARFIELD, TELEPHONY (4クラス)
 SHORT モード: FARFIELD のみ (1クラス)

FARFIELD (遠距離マイク向け)が SHORT モードでのデフォルト → 近距離の発話も遠距離扱いで堅牢に処理。

prefetch の仕組み：別モデルではない

結論

prefetch.decision は新しいモデルではない。同じ VAD LSTM が出力する vad.posterior（0〜1 の発話確率）を、異なる閾値・パラメータを持つ別の EndpointerStream インスタンスで処理したもの。

1
2
3
4
5


vad.posterior (単一 LSTM の出力)
 │
 ├─ EndpointerStream(threshold=低め) → prefetch.decision ← 早く反応
 ├─ EndpointerStream(threshold=高め) → vad.decision ← 確実に判定
 └─ EndpointerStream(threshold=同等) → vad.decision_for_segmenter → Encoder ゲート

config バイナリから実測した閾値パラメータ

CONTINUOUS モード（字幕・ライブ）：

ストリーム	発話開始閾値	備考
`prefetch.decision`	0.69	posterior > 69% でプリフェッチ開始
`vad.decision`	0.30	posterior > 30% で発話確定
`vad.decision_for_segmenter`	0.30	Encoder へのゲート、同じ閾値

SHORT モード（IME・コマンド）：3ステージ構成

ステージ	ストリーム	閾値	役割
1st	`prefetch.decision`	0.17	posterior > 17% で即バッファ開始
2nd	`confirmation`	0.60	posterior > 60% で発話確定 ← SHORT 専用
3rd	`vad.decision`	0.10	最終判定
gate	`vad.decision_for_segmenter`	0.01	Encoder へのゲート（非常に低い）

なぜ「語頭をよく認識できる」のか

SHORT モードの設計から読み取れる意図：

1
2


CONTINUOUS: prefetch 閾値 0.69 ← 発話がかなり確実になってから反応
SHORT: prefetch 閾値 0.17 ← わずかでも音が来たら即バッファ開始

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


時間軸:
音声波形: ...無音... |あ────────────────|
発話確率: ...0.0... 0.05→0.20→0.60→0.90...

SHORT mode:
 ├─ prefetch (0.17): posterior が 0.17 を超えた瞬間にバッファ開始
 │ → 「あ」の破裂音の立ち上がり (~5ms) を捕捉
 ├─ confirmation (0.60): 0.60 を超えたら「発話確定」
 │ → エンコーダへ過去バッファ分を遡って投入
 └─ vad.decision (0.10): 終了判定（非常に低い = 微妙な発話でも続行）

CONTINUOUS mode:
 └─ prefetch (0.69): 確実な発話のみ反応 → 語頭クリッピングリスクあり

SHORT モードで語頭が取れる理由： prefetch 閾値が 0.17 と低いため、発話確率が少し上がっただけで即座にバッファリングを開始する。その後 confirmation(0.60) で確定し、バッファ内の音声（語頭を含む）をエンコーダに渡す。

音声バッファ（プリロール）の実装

config パラメータから：

1
2
3
4


prefetch.decision の追加パラメータ:
 field=3 int=360 ← バッファ長 360ms（推定）
 field=6 int=1 ← モード設定
 field=7 float=0.0 ← オフセット

360ms 分の音声がバッファされる → 発話確定後、最大 360ms 遡って処理できる。

常時録音とリングバッファ

SODA は常時マイク入力を録音し続けている。発話を検出してから録音を開始するのではない。

1
2
3
4
5
6
7
8


常時稼働しているもの：
 マイク → ring buffer への書き込み（ずっと）
 VAD LSTM の推論（ずっと）

発話検出後にのみ起動するもの：
 Conformer Encoder（重い）
 RNN-T Decoder
 LAS Rescorer

VAD LSTM が小さい (436KB) のはこのためで、常時動かすコンポーネントは軽くするという設計方針。

リングバッファの構造：

1
2
3
4
5
6
7


物理メモリ（11,520 bytes の配列）
 16000 Hz × 2 bytes × 0.36s = 11,520 bytes

[0 ][1 ][2 ]...[N-1 ]
 ↑
 write pointer が端まで達したら 0 に戻る
 → データは連続して存在し続ける

prefetch が発火した瞬間（posterior > 0.17）：

1
2
3
4


read_start = (write_pos - 360ms分) % buffer_size

→ 360ms 前の位置から読み出し開始
→ Encoder への投入は「今から」ではなく「360ms 前から」

折り返し（wrap-around）について：
360ms 分の読み出しがバッファの端をまたぐ場合も、後半→前半の 2回読みで対応できる。物理的な切れ目はなく、データの欠損は発生しない。バッファサイズ (360ms) と読み戻し量 (360ms) が一致しているため、書き込みが読み出しを追い越すことはない。

各 EndpointerStream の役割まとめ

ストリーム	役割	後段
`prefetch.decision`	バッファ開始のトリガー（低閾値）	Decoder に注入（バッファリング指示）
`vad.decision`	発話確定・終了判定（中閾値）	Decoder に注入（エンドポインタ判断）
`vad.decision_for_segmenter`	Encoder ゲート（LOW 閾値）	SegmenterStream → Encoder
`confirmation`	(SHORT のみ) 発話確認	vad.decision の前段フィルタ
`vad.audio_level_events`	音量レベル監視	AudioLevelEventStream → デバッグ用

EOT（ターン終了）予測の完全な仕組み

config バイナリからすべてのパラメータを実測した結果、EOT 判断は 4つの層が連携していることが判明した。

Layer 1：音響層（VAD LSTM → EndpointerStream × 3〜4）

同一の VAD LSTM posterior を、閾値の異なる複数の EndpointerStream に通す：

ストリーム	CONTINUOUS 閾値	SHORT 閾値	動作
`prefetch.decision`	0.69	0.17	バッファ開始トリガー（低確信でも反応）
`confirmation`	―	0.60	SHORT 専用：発話確認ステージ
`vad.decision`	0.30	0.10	発話確定・終了判定
`vad.decision_for_segmenter`	0.30	0.01	Encoder へのゲート（最終段）

SHORT モードで prefetch 閾値が 0.17 と極端に低い理由：
→ 発話確率が 17% を超えた瞬間にバッファを開始し、語頭クリッピングを防ぐ。
→ その後 confirmation (0.60) で誤検出をフィルタする 2段階設計。

Layer 2：言語層（FST + LAS Rescorer）

FST ビーム探索で「文として完成しているか」をスコア化：

パラメータ	CONTINUOUS	SHORT	意味
`acoustic_scale`	2.300	2.125	音響モデルの重み係数
`beam`	5.0	5.0	FST ビーム幅
`max_beam`	10.0	10.0	最大ビーム幅
`word_end_weight`	0.0693	0.0693	単語境界重み
`insertion_penalty`	−0.002	−0.002	挿入ペナルティ
LAS rescorer weight	1.3595	1.7043	N-best リスコアリングの重み
LAS extra weight	0.0	1.4000	SHORT 専用の追加重み

acoustic_scale 差の意味：

CONTINUOUS (2.30) → 音響モデルをより信頼（話者が何を言ったかを優先）
SHORT (2.12) → 相対的に LM の影響を大きくし、コマンド文法を優先

LAS 重み差の意味：

SHORT (1.70) は CONTINUOUS (1.36) より 25% 高い → 2nd pass rescorer をより強く信頼
SHORT に専用の追加重み 1.40 がある → confirmation 段階のスコアと組み合わせる

Layer 3：統合層（DecoderEndpointerStream 内部パラメータ）

config のバイナリ extension フィールドから実測した固定パラメータ（CONTINUOUS / SHORT 共通）：

1
2
3
4
5
6


acoustic_endpointer_weight = 3.803557 ← VAD 音響信号の重み
silence_penalty_floor = −32.002899 ← 無音時のログ確率床
large_beam_floor = −26837.197 ← ビーム探索の底値
lm_endpointer_weight = 3.631859 ← 言語スコアの重み
threshold = −2.046974 ← ターン終了判定閾値（log 空間）
score_bias = 604.288 ← 判断スコアのバイアス（log 空間）

SHORT 専用の追加パラメータ（extra 221 bytes）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


normalization_a = −2.1251 ← スコア正規化
normalization_b = 0.3751 ← スコア正規化
weight_extra_1 = 3.1500 ← EOQ 追加重み
weight_extra_2 = 2.0186 ← confirmation 重み
large_penalty_1 = −57.502 ← 強いペナルティ（誤検出防止）
small_penalty = −0.3797
weight_extra_3 = 1.6000
micro_threshold = 0.0007 ← 極小閾値（hotword 判定？）
small_threshold = 0.1000
large_penalty_2 = −47.450 ← 強いペナルティ
weight_final = 2.0000

Layer 4：ホットワード層（SHORT 専用）

SHORT モードの DecoderEndpointerStream には、ホットワードが EOT ロジックに直接組み込まれている：

1
2
3
4


"ok google" ← 検出 → ターン即リセット
"okay google" ← 同上
"hey google" ← 同上
" google" ← 同上

これらが検出されると EOT ではなく「新しいターンの開始」として処理される。

全体の判断フロー

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


音声フレーム
 │
 ├─[VAD LSTM]─────────────────────────────────────────────────────────
 │ posterior → EndpointerStream (4段)
 │ │
 │ prefetch (0.17/0.69) → バッファ開始
 │ confirmation (0.60 / SHORT only) → 発話確定
 │ vad.decision (0.10/0.30) ──────────────────────────────────┐
 │ vad.decision_for_segmenter ──→ [Segmenter] ─→ [Encoder] │
 │ │ │
 │ [FST Decoder] │
 │ acoustic_scale │
 │ = 2.30/2.12 │
 │ │ │
 │ [LAS Rescorer] │
 │ weight │
 │ = 1.36/1.70 │
 │ │ │
 └──────────────────────────────────────────────────→ [DecoderEndpointerStream]
 │
 acoustic_weight=3.80 │
 lm_weight=3.63 │
 silence_penalty=−32.0 │
 threshold=−2.05 │
 ▼
 ターン終了 / 継続

CONTINUOUS vs SHORT の本質的な違い

観点	CONTINUOUS	SHORT
VAD 感度	保守的 (prefetch=0.69)	攻撃的 (prefetch=0.17)
語頭クリッピング	発生しやすい	バッファ+2段階で防止
誤検出防止	prefetch 閾値が高い	confirmation (0.60) で防止
LM 信頼度	音響優先 (2.30)	LM との均衡 (2.12)
LAS Rescorer	軽め (1.36)	重め (1.70+1.40)
ホットワード	なし	あり (ok/okay/hey google)
追加パラメータ	なし	221 byte 分の拡張設定

全パラメータ詳細（config 実測値）

FstSearchParams（ビーム探索設定）

パラメータ	CONTINUOUS	SHORT	意味
beam	5.0	5.0	FST ビーム幅
max_beam	10.0	10.0	最大ビーム幅
word_end_weight	0.0693	0.0693	単語境界重み (≈ln(1.072))
insertion_penalty	−0.002	−0.002	挿入ペナルティ
acoustic_scale	2.300	2.125	音響モデルのスケール係数
n-best	100	100	Rescorer に渡す仮説数

LasNbestRescorer パラメータ

1
2


n-best candidates: 8 ← 上位8仮説を LAS でリスコアリング
score_weight: 1.0

SegmenterStream パラメータ

1
2


CONTINUOUS: max_silence ≈ 30,000単位 / max_session ≈ 60,000単位
SHORT: より短い設定

EOQ 接続グラフ（CONTINUOUS モード完全版）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53


input
 └─ AudioDecoderStream → waveform_frame → windowed_frame → fft_energies
 └─ filter_bank (80次元 log-mel)
 └─ frame_stacker
 └─ sampled_stacked_filterbanks
 │
 ┌─────────────────────────────────────────────────────────┤
 │ 【VAD LSTM パス】 │
 ▼ │
 vad.cluster_id (AppendClusterIdStream) │
 └─ vad.posterior (LstmComputeStream, 436KB LSTM) │
 │ │
 ┌─────────┼─────────────────────┐ │
 │ │ │ │
 ▼ ▼ ▼ │
 prefetch.decision vad.audio_level_events vad.decision │
 (EndpointerStream) (AudioLevelEventStream) (EndpointerStream) │
 │ │ │
 │ ┌──────────────────┤ │
 │ │ vad.decision │ │
 │ │ _for_segmenter │ │
 │ │ (EndpointerStream)│ │
 │ │ │ │ │
 │ │ ▼ │ │
 │ │ endpointer_events │ │
 │ │ (EndpointerEventStream) │
 │ │ │ │ │
 │ └─► segmenter ◄────┘ │
 │ (SegmenterStream) │
 │ │ ◄──────────────────────────────────────┘
 │ 【発話フレームのみ通過】
 │ │
 │ tflite_frame_normalize_stream (FrameNormalizeStream)
 │ └─ mean_stddev (240次元)
 │ │
 │ audio_features.clusterid (AppendClusterIdStream)
 │ │
 │ stack_for_stacking_layer (FrameStacker)
 │ │
 │ sample_for_stacking_layer (SubsampleStream)
 │ │
 │ conformer_encoder (CausalEncoderStream)
 │ │
 └──► decoder (DecoderEndpointerStream)
 (vad.decision + prefetch.decision + encoder出力 → ターン判断)
 │
 concat_endpointer_events (ParallelConcatStream)
 │
 concat_endpointer_event_filter (EndpointerEventFilterStream)
 │
 finalize_result.combined_result (CombinedResultStream)
 │
 frame_events → nbest_event_filter → recognition_events

VAD が「エンコーダの前段」にある理由

懸念	対策
エンコーダが重い (107MB) → 無音フレームへの無駄な計算	VAD (436KB) で先にフィルタリング
無音フレームが Conformer の状態を汚染する可能性	SegmenterStream が無音フレームをブロック
リアルタイム性の確保	VAD が軽量 (436KB) → 低レイテンシで決定

ターン終了判断の仕組み

DecoderEndpointerStream が複数信号を統合：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


音響信号 ─── vad.decision (無音検出)
 prefetch.decision (先読み予測)
 │
 ▼
言語信号 ─── FST スコア (文の完成度)
 │
 ▼
 DecoderEndpointerStream
 ┌─────────────────────────────┐
 │ VAD: 「沈黙あり」 │
 │ FST スコア高い → 文完成 │ → セッション終了・出力
 │ FST スコア低い → 文未完成 │ → セッション継続
 └─────────────────────────────┘

EOQ だけではターンを閉じない。言語的な文完成度と合わせて判断する。

認識モード比較

項目	CONTINUOUS	SHORT
用途	字幕・ライブ文字起こし	IME入力・音声コマンド
VAD モデル	`DEFAULT_BF_VAD_EP_MD_UF_DARWINN_CONTINUOUS`	`DEFAULT_BF_EOQ_EP_MD_UF_DARWINN_SHORT`
エンドポインタ	緩め (会話継続)	厳しめ (発話終了検出)
クラスタ ID	VOICE_SEARCH, CAPTION, FARFIELD, TELEPHONY	FARFIELD のみ
確認ステップ	なし	`confirmation` EndpointerStream あり
Entity Injection	なし	JDQ_ONDEVICE あり (連絡先・楽曲等)
ホットワード	参照しない	“ok google”, “okay google”, “hey google”
識別子末尾	`ONDEVICE_LARGE_CONTINUOUS`	`ONDEVICE_LARGE_SHORT`

トークナイザー詳細

語彙規模

項目	値
総トークン数	約 7,388
うち日本語トークン	約 6,902 (93%)
残り	ASCII / 記号 / 特殊トークン
ファイル	`endtoendmodel/large.wpm.portable` (188KB, protobuf)
語彙シンボルテーブル	`endtoendmodel/large.syms.compact` (31KB, OpenFST CompactSymbolTable)

単語境界マーカー

▁（U+2581）を単語先頭に付与（SentencePiece と同方式）：

1
2


▁ありがとう ← 単語の先頭
う ← 単語の途中（サブワード継続）

特殊トークン

1
2
3
4
5
6
7
8
9


<sos> ← 文開始 (decoder 初期入力)
</S> ← 文終了
<UNK> ← 未知語
<noise> ← 環境ノイズ
<sil> ← 無音 (silence)
<epsilon> ← FST イプシロン遷移
<text_only> ← テキストのみモード
<phi> ← Entity Injection 用
<sigma> ← Entity Injection 用

エンティティクラストークン（動的コンテキスト注入）

SHORT モードのみ有効：

1
2
3
4
5
6
7


<contacts> / </contacts> ← 連絡先名 (CONTACTS)
<songs> / </songs> ← 楽曲名 (SONG)
<pkg_contacts> / </pkg_contacts> ← パッケージ連絡先
<pkg_songs> / </pkg_songs> ← パッケージ楽曲
<pkg_artists> / </pkg_artists> ← アーティスト名
<apps> / </apps> ← アプリ名 (APP)
#NUMBER ← 数字エンティティ

JDQ_ONDEVICE (Just-in-time Dynamic Query) システムで実行時注入：

pattern_tagger.fst → 音素列をエンティティに対応付け
token_masker.fst → 語彙マスキング
blocklist.fst → ブロックリスト適用
base_wordlist.syms → ベース語彙リスト

句読点 LSTM 詳細

アーキテクチャ

項目	値
ファイルサイズ	2.4MB (int8量子化)
アーキテクチャ	Bidirectional LSTM
語彙サイズ	2,332 トークン
量子化	int8

重みテンソル構造（BidirectionalSequenceLSTM）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


Forward LSTM (fw):
 fw_input2input_weights1 (I→I ゲート)
 fw_input2forget_weights2 (I→F ゲート)
 fw_input2cell_weights3 (I→C ゲート)
 fw_input2output_weights4 (I→O ゲート)
 fw_rec2input_weights5 (再帰→I)
 fw_rec2forget_weights6 (再帰→F)
 fw_rec2cell_weights7 (再帰→C)
 fw_rec2output_weights8 (再帰→O)
 fw_cell2input_weights9 (Peephole I)
 fw_cell2forget_weights10 (Peephole F)
 fw_cell2output_weights11 (Peephole O)
 fw_*_bias12-15
 fw_activation_state35, fw_input_cell_state36

Backward LSTM (bw): 同様の構造 (bw_*18-38)

後段:
 weights50, bias51 → output52 → ... → output57

Peephole 接続あり = cell state から各ゲートに直接接続する LSTM 拡張形。

句読点変換ルール (punctuation_converter_config.pb から)

日本語句読点は発話形から書字形へ変換：

「まる」「ピリオド」→ 。 / ．（ホモフォン複数対応）
「てん」「コンマ」→ 、 / ，
type: INTERMEDIATE = 文中にも挿入可能
upcase_after: false = 英語と異なり日本語は大文字化なし

言語モデル FST 詳細

FST とは

FST = Finite State Transducer（有限状態変換器）。

テキストコーパスから学習した n-gram 確率を、巨大なグラフ（状態遷移図）として事前にコンパイルしたもの。「この単語の次に来やすい単語は何か」という言語的な自然さをスコア化する。

1
2
3
4


"今日は" の次に来やすい単語は？
 → "天気" (確率高)
 → "何を" (確率高)
 → "宇宙船" (確率低)

FST の入力はテキストトークンであり、音声（メルスペクトログラム等）ではない。
音声は Encoder → RNN-T Decoder でトークン列に変換された後、FST に渡される。

なぜニューラル LM ではなく FST を使うか

観点	FST	ニューラル LM
速度	非常に速い（グラフ探索のみ）	遅い（行列演算）
ビーム探索との統合	同時実行可能	バッチ処理が必要
メモリ	小さい（pruning 後 31KB）	大きい
精度	n-gram レベル	高い（文脈理解）

RNN-T のビーム探索（100本同時）と FST スコアリングをリアルタイムで並走させるために FST が採用されている。

ファイル構成

ファイル	サイズ	説明
`lm.pruned.sorted.fst`	12MB	主 LM FST（プルーニング・ソート済み）
`transducer.pruned.fst`	3.6MB	トランスデューサ FST
`lm.pruned.sorted.syms`	1.4MB	語彙シンボルテーブル
`large.syms.compact` (ja)	31KB	Decoder が使うシンボルテーブル（極限 pruning 後）
`large.syms.compact` (en)	22KB	英語版

SigmaFst 型 = sigma 遷移（全記号にマッチ）を持つ FST
ビーム探索時に FstSearchParams でビーム幅等を制御
DecoderEndpointerStream が FST スコアを参照して文完成度を判断（lm_weight=3.632）

SODA のパイプライン内での位置づけ

1
2
3
4
5
6
7


RNN-T Decoder（ビーム探索 n-best=100）
 ↓ トークン列の仮説
FST 言語モデル
 ↓ 言語スコア付き仮説
LAS Rescorer（上位 8本に絞って精密評価）
 ↓
DecoderEndpointerStream（EOT 判定）

LAS Rescorer が必要な理由

RNN-T 単体の限界

RNN-T はフレームごとに左から右へ逐次的にトークンを生成する（一方向・局所的）。「文全体を見て最も自然な解釈はどれか」という大局的な判断が苦手。

1
2
3
4


ビーム探索の結果（スコアが僅差）：
 仮説1: "今日は天気がいいですね" score: -12.3
 仮説2: "今日は点気がいいですね" score: -12.5 ← "天" を "点" と聞き違え
 仮説3: "今日は天気がいい世ね" score: -12.7

スコアが近い場合、RNN-T + FST だけでは誤りを弾けないことがある。

LAS Rescorer の解決方法

Encoder 出力と仮説テキストを 双方向 Attention で全体を見渡しながら照合して再評価。

1
2
3
4
5


Encoder 出力（音声の全文脈）
 ↓
LAS cross-attention ← "点気" は音響的にあり得るか？
 ↓
"天気" の方が音響・言語両面で自然 → 仮説1を選択

RNN-T が「速さ優先で生成」し、LAS が「精度優先で選別」する役割分担。

日英のモデルサイズ比較

コンポーネント	日本語	英語
VAD LSTM	437KB	471KB
FST (syms.compact)	31KB	22KB
LAS Rescorer (acoustic)	3.9MB	3.1MB
LAS Rescorer (full)	なし	48MB

日本語には 48MB のフル LAS が存在しない。
英語は self-attention + cross-attention のフル構成、日本語は音響特徴のみの軽量版で代用している。

特殊トークン一覧（英語版から判明）

音声認識の語彙（wpm.portable）に含まれる特殊トークン：

トークン	用途
`<s>` / `</s>`	文の開始・終了（FST が使う）
`<UNK>`	未知語
`<noise>`	雑音
`<epsilon>`	RNN-T の blank（「何も出力しない」）
`<reject>`	認識拒否
`{comma}`, `{period}`, `{new-line}` 等	音声コマンドによる句読点入力（dictation 用）
`{smiley-face}`, `{heart}` 等	絵文字の発話認識
`<contacts>`, `<song>`, `<app>` 等	エンティティ注入用の文脈タグ

Googleの論文にあった、<pause> や <eos> は存在しない。 EOT 判定はトークンレベルではなく DecoderEndpointerStream が担う。

FST と LAS Rescorer の自前構築

FST（n-gram LM）→ GPU 不要、KenLM で構築可能

FST はニューラルネットではなく、テキストコーパスから n-gram を数えてグラフにコンパイルするだけ。

1
2
3
4
5


# n-gram 学習
kenlm/build/bin/lmplz -o 4 --memory 8G < corpus.txt > lm.arpa

# バイナリ化
kenlm/build/bin/build_binary trie lm.arpa lm.bin

必要データ量の目安：

データ	サイズ	品質
Wikipedia のみ	約 20GB（展開後）	書き言葉のみ、口語弱
Wikipedia + ニュース	30〜50GB	実用的な最低ライン
+ Common Crawl (CC-100)	85GB 追加	口語・SNS 表現を補強

日本語は口語データ（SNS・会話）が入っているかどうかが品質を大きく左右する。

sherpa-onnx への統合

sherpa-onnx は KenLM による LM rescoring をネイティブサポートしている。

1
2
3
4


sherpa-onnx \
 --lm=lm_4gram.bin \
 --lm-scale=0.1 \  # SODA の acoustic_scale の逆数に相当
 ...

--lm-scale は 0.05〜0.3 の範囲で WER が最小になる値を探す。

LAS Rescorer → 3090 (24GB) で学習可能だがデータが課題

項目	状況
モデルサイズ (48MB)	3090 (24GB VRAM) で余裕
アーキテクチャ	Transformer、OSS 実装多数
学習データ	ここがボトルネック

LAS の学習には「Encoder 出力 × 大量音声データ」が必要。 SODA の Encoder は使えないため、sherpa-onnx の Zipformer 等を Encoder として代用する構成になる。

現実的な構成（3090 で実現可能）：

1
2
3
4
5


Zipformer encoder（sherpa-onnx、OSS）
 ↓ Encoder 出力
自前 LAS Rescorer（PyTorch で学習）
 ↓
自前 FST（KenLM + 大規模コーパス）

GPU 的には問題ない。壁になるのはペアデータ（音声＋正解テキスト）の量。
日本語なら最低数百時間、英語なら数千時間規模が現実的な目安。

言語識別 (LangID) モデル

項目	値
ファイルサイズ	2.4MB
アーキテクチャ	Conformer Encoder (12層、ASR より小型)
対応言語数	43言語
使用 VAD	`SODA_DICTATION_EP_UNIFIED_FRONTEND_LANGID` (471KB)
特徴量次元	528次元 (mean_stddev ファイルサイズから算出)

対応言語リスト： af-ZA, ar-EG, bg-BG, ca-ES, cmn-Hans-CN, cs-CZ, da-DK, de-DE, el-GR, en-US, es-US, eu-ES, fa-IR, fi-FI, fil-PH, fr-FR, gl-ES, he-IL, hi-IN, hu-HU, id-ID, is-IS, it-IT, ja-JP, ko-KR, lt-LT, ms-MY, nb-NO, nl-NL, pl-PL, pt-BR, ro-RO, ru-RU, sk-SK, sl-SI, sr-RS, sv-SE, th-TH, tr-TR, uk-UA, vi-VN, yue-Hant-HK, zu-ZA

LangID モデルも ASR と同じ Conformer アーキテクチャを使用（conf_0〜conf_11、trans_atten の multihead_atten が確認できる）。

コンテキスト機能（DeviceContext）

config から読み取れる端末状態フィーチャー（アシスタント連携時のみ）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


alarm-status ← アラーム状態 (FIRING/SCHEDULED/SNOOZED)
timer-status ← タイマー状態 (FIRING/PAUSED/RUNNING)
call-state ← 通話状態 (INCOMING/OUTGOING/IN_CALL)
media-state ← 再生状態 (PLAYING)
hotword-active ← ホットワード検出中かどうか
client-id ← クライアント種別:
 AUTO, MOBILE_WARM_WORDS, NGA, ENHANCED_VOICE_DICTATION, HUB_MODE
foreground-app ← フォアグラウンドアプリ (Android パッケージ名):
 com.google.android.gm (Gmail)
 com.google.android.keep (Keep)
 com.google.android.apps.messaging
 com.whatsapp
 com.google.android.apps.dynamite (Chat)
 com.google.android.apps.docs.editors.docs
input-field-type ← 入力フィールド種別 (TYPE_TEXT_VARIATION_EMAIL_ADDRESS 等)
latitude/longitude ← 位置情報
asr-state ← ASR状態 (HOTQUERY/not-found)
experiment-labels ← A/Bテストラベル

フォアグラウンドアプリ別にコンテキストモジュールが切り替わる：

Gmail 起動中 → メールアドレス・連絡先を優先認識
Keep 起動中 → ノート内容を優先
Messages/WhatsApp → 連絡先名を優先

クローン設計のポイント

必要なコンポーネントと代替

コンポーネント	このモデル	OSS 代替
Conformer Encoder (Causal)	12層、Macaron style, 107MB	ESPnet / k2 / NeMo
RNN-T Decoder	シンプル LSTM	Torchaudio RNN-T / ESPnet
Joint Network (posterior+prior)	分離設計で LM fusion 可能	標準 RNN-T joint でも可
LAS Rescorer	2nd pass, 3.8MB	オプション (品質向上用)
語彙	WordPiece ~7400	SentencePiece (BPE/Unigram)
言語モデル	剪定済みFST (12MB)	KenLM + OpenFST
VAD	LSTM 436KB	Silero VAD / WebRTC VAD
句読点	BiLSTM int8 2.4MB	CTranslate2 + punct model

日本語固有の処理

mozc.dic (9.4MB): Google 日本語入力の辞書 → 代替: NEologd, UniDic
JapaneseSegmentedVariantsProvider: Mozc で読み仮名バリアント生成
JapaneseContactNameTextTransformer: 人名の読み処理
JapaneseTextSegmentationTransformer: TTS向け分かち書き
portable_ja_verbalizer.far (1.2MB): 数字・記号→日本語読み上げ FST

クローン時のスケール参考

要素	この SODA モデル	一般的な OSS 日本語 ASR
Encoder 層数	12 (Conformer)	12〜24 (Transformer/Conformer)
入力特徴量	80-mel, 10ms shift	80-mel, 10ms shift ← 同じ
語彙	7,388 WordPiece	3,000〜10,000 BPE/Unigram
合計サイズ	138MB	100〜300MB (精度依存)
モデル訓練規模	不明 (Google 内部)	ESPnet推奨: 1,000h+

デバッグメモ

問題1: libsoda.so が読み込めない

OSError: libc++.so.1: cannot open shared object file → sudo apt-get install -y libc++1

問題2: .img 展開失敗 (0バイト)

ChromeOS DLC は Squashfs 形式。7z 非対応。 → unsquashfs を使う (squashfs-tools パッケージ)

問題3: arecord “Device or resource busy”

PipeWire が plughw:X,X を専有。 → parec (PulseAudio録音) を使う

問題4: 音声受信できるが認識結果が出ない (volteer)

volteer の libsoda.so は bitflip パッチ未実装。 → hatch (Intel 10th gen) の libsoda.so を使う (x86_64 互換)

問題5: マイクゲイン低すぎ

デフォルト27% → RMS が小さすぎて認識されない。 → pactl set-source-volume <source> 65% → 100%はクリッピング (peak=32768) するので 60〜70% が安定

問題6: `AUDIO_LEVEL` の rms が常に 0.0

AUDIO_LEVEL メッセージの rms はループバック音声のレベル。マイクではない。正常動作。

マイク音声レベルの確認:

1
2
3
4


import struct, math
samples = [struct.unpack_from('<h', audio, i)[0] for i in range(0, len(audio)-1, 2)]
rms = math.sqrt(sum(s*s for s in samples) / len(samples))
# 無音: ~100-500、発話: ~1000-5000

実行ログ

実際にローカルでデバッグように動かした時のログ:

 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115


I0000 00:00:1780981769.242031 131504 terse_processor.cc:956] Final recognition has been created.
I0000 00:00:1780981769.292684 81168 terse_processor.cc:3025] TerseProcessor HasRecognitionEvent With Final
I0000 00:00:1780981769.292715 81168 terse_processor.cc:3355] Audio pin advanced by: 3.27s
I0000 00:00:1780981769.292757 81168 terse_processor.cc:3415] Longform resets session because this session is 3.27s long.
I0000 00:00:1780981769.292768 81168 terse_processor.cc:1645] Cancelling session.
W0000 00:00:1780981769.293127 81168 decoder_endpointer_stream.cc:242] Acoustic ep reader thread cancelled.
W0000 00:00:1780981769.293153 81168 decoder_endpointer_stream.cc:242] Prefetch reader thread cancelled.
I0000 00:00:1780981769.293413 81168 terse_processor.cc:1492] Starting session.
I0000 00:00:1780981772.313959 131538 terse_processor.cc:956] Final recognition has been created.
I0000 00:00:1780981772.361874 81168 terse_processor.cc:3025] TerseProcessor HasRecognitionEvent With Final
I0000 00:00:1780981772.361964 81168 terse_processor.cc:3355] Audio pin advanced by: 3.09s
I0000 00:00:1780981772.362024 81168 terse_processor.cc:3415] Longform resets session because this session is 3.09s long.
I0000 00:00:1780981772.362034 81168 terse_processor.cc:1645] Cancelling session.
W0000 00:00:1780981772.362443 81168 decoder_endpointer_stream.cc:242] Acoustic ep reader thread cancelled.
W0000 00:00:1780981772.362457 81168 decoder_endpointer_stream.cc:242] Prefetch reader thread cancelled.
I0000 00:00:1780981772.362697 81168 terse_processor.cc:1492] Starting session.
* こんにちは。
* 今日 は 暑 いっ す ね。
I0000 00:00:1780981778.144007 131597 terse_processor.cc:956] Final recognition has been created.
I0000 00:00:1780981778.183203 81168 terse_processor.cc:3025] TerseProcessor HasRecognitionEvent With Final
I0000 00:00:1780981778.183354 81168 terse_processor.cc:3355] Audio pin advanced by: 5.82s
I0000 00:00:1780981778.183476 81168 terse_processor.cc:3415] Longform resets session because this session is 5.82s long.
I0000 00:00:1780981778.183500 81168 terse_processor.cc:1645] Cancelling session.
W0000 00:00:1780981778.183914 81168 decoder_endpointer_stream.cc:242] Acoustic ep reader thread cancelled.
W0000 00:00:1780981778.183933 81168 decoder_endpointer_stream.cc:242] Prefetch reader thread cancelled.
I0000 00:00:1780981778.184291 81168 terse_processor.cc:1492] Starting session.
I0000 00:00:1780981780.743660 81168 soda_async_impl.cc:1291] Current audio timestamp: 1780981780087778
I0000 00:00:1780981782.286159 131631 terse_processor.cc:956] Final recognition has been created.
I0000 00:00:1780981782.343491 81168 terse_processor.cc:3025] TerseProcessor HasRecognitionEvent With Final
I0000 00:00:1780981782.343561 81168 terse_processor.cc:3355] Audio pin advanced by: 4.08s
I0000 00:00:1780981782.343734 81168 terse_processor.cc:3415] Longform resets session because this session is 4.08s long.
I0000 00:00:1780981782.343751 81168 terse_processor.cc:1645] Cancelling session.
W0000 00:00:1780981782.344365 81168 decoder_endpointer_stream.cc:242] Acoustic ep reader thread cancelled.
W0000 00:00:1780981782.344380 81168 decoder_endpointer_stream.cc:242] Prefetch reader thread cancelled.
I0000 00:00:1780981782.344607 81168 terse_processor.cc:1492] Starting session.
* トゥワード ファースト アンド アキュレイト お なかなか いい。 度 い や い い。 よ く で き
I0000 00:00:1780981785.503698 131657 terse_processor.cc:956] Final recognition has been created.
I0000 00:00:1780981785.543589 81168 terse_processor.cc:3025] TerseProcessor HasRecognitionEvent With Final
I0000 00:00:1780981785.543892 81168 terse_processor.cc:3355] Audio pin advanced by: 3.24s
I0000 00:00:1780981785.543985 81168 terse_processor.cc:3415] Longform resets session because this session is 3.24s long.
I0000 00:00:1780981785.543999 81168 terse_processor.cc:1645] Cancelling session.
W0000 00:00:1780981785.544823 81168 decoder_endpointer_stream.cc:242] Acoustic ep reader thread cancelled.
W0000 00:00:1780981785.544850 81168 decoder_endpointer_stream.cc:242] Prefetch reader thread cancelled.
I0000 00:00:1780981785.545216 81168 terse_processor.cc:1492] Starting session.
* 制度 いや いい。
I0000 00:00:1780981787.976933 131684 terse_processor.cc:956] Final recognition has been created.
I0000 00:00:1780981788.042046 81168 terse_processor.cc:3025] TerseProcessor HasRecognitionEvent With Final
I0000 00:00:1780981788.042132 81168 terse_processor.cc:3355] Audio pin advanced by: 2.46s
I0000 00:00:1780981788.042187 81168 terse_processor.cc:3415] Longform resets session because this session is 2.46s long.
I0000 00:00:1780981788.042198 81168 terse_processor.cc:1645] Cancelling session.
W0000 00:00:1780981788.042530 81168 decoder_endpointer_stream.cc:242] Acoustic ep reader thread cancelled.
W0000 00:00:1780981788.042550 81168 decoder_endpointer_stream.cc:242] Prefetch reader thread cancelled.
I0000 00:00:1780981788.042832 81168 terse_processor.cc:1492] Starting session.
I0000 00:00:1780981791.378381 131706 terse_processor.cc:956] Final recognition has been created.
I0000 00:00:1780981791.434164 81168 terse_processor.cc:3025] TerseProcessor HasRecognitionEvent With Final
I0000 00:00:1780981791.434272 81168 terse_processor.cc:3355] Audio pin advanced by: 3.42s
I0000 00:00:1780981791.434355 81168 terse_processor.cc:3415] Longform resets session because this session is 3.42s long.
I0000 00:00:1780981791.434371 81168 terse_processor.cc:1645] Cancelling session.
W0000 00:00:1780981791.434811 81168 decoder_endpointer_stream.cc:242] Acoustic ep reader thread cancelled.
W0000 00:00:1780981791.434831 81168 decoder_endpointer_stream.cc:242] Prefetch reader thread cancelled.
I0000 00:00:1780981791.435088 81168 terse_processor.cc:1492] Starting session.
* よく でき てる じゃん ま そら そっ か モデル の 重 さ が 全然 違う から な。
I0000 00:00:1780981810.275178 131733 terse_processor.cc:956] Final recognition has been created.
I0000 00:00:1780981810.314296 81168 terse_processor.cc:3025] TerseProcessor HasRecognitionEvent With Final
I0000 00:00:1780981810.314378 81168 terse_processor.cc:3355] Audio pin advanced by: 18.87s
I0000 00:00:1780981810.314577 81168 terse_processor.cc:3415] Longform resets session because this session is 18.87s long.
I0000 00:00:1780981810.314622 81168 terse_processor.cc:1645] Cancelling session.
W0000 00:00:1780981810.315045 81168 decoder_endpointer_stream.cc:242] Acoustic ep reader thread cancelled.
W0000 00:00:1780981810.315065 81168 decoder_endpointer_stream.cc:242] Prefetch reader thread cancelled.
I0000 00:00:1780981810.315482 81168 terse_processor.cc:1492] Starting session.
I0000 00:00:1780981810.692990 81168 soda_async_impl.cc:1291] Current audio timestamp: 1780981810087778
* ふう、 疲れ た。
I0000 00:00:1780981818.837511 131828 terse_processor.cc:956] Final recognition has been created.
I0000 00:00:1780981818.893274 81168 terse_processor.cc:3025] TerseProcessor HasRecognitionEvent With Final
I0000 00:00:1780981818.893306 81168 terse_processor.cc:3355] Audio pin advanced by: 8.55s
I0000 00:00:1780981818.893395 81168 terse_processor.cc:3415] Longform resets session because this session is 8.55s long.
I0000 00:00:1780981818.893421 81168 terse_processor.cc:1645] Cancelling session.
W0000 00:00:1780981818.893979 81168 decoder_endpointer_stream.cc:242] Acoustic ep reader thread cancelled.
W0000 00:00:1780981818.893999 81168 decoder_endpointer_stream.cc:242] Prefetch reader thread cancelled.
I0000 00:00:1780981818.894312 81168 terse_processor.cc:1492] Starting session.
I0000 00:00:1780981822.227670 131905 terse_processor.cc:956] Final recognition has been created.
I0000 00:00:1780981822.282227 81168 terse_processor.cc:3025] TerseProcessor HasRecognitionEvent With Final
I0000 00:00:1780981822.282250 81168 terse_processor.cc:3355] Audio pin advanced by: 3.39s
I0000 00:00:1780981822.282292 81168 terse_processor.cc:3415] Longform resets session because this session is 3.39s long.
I0000 00:00:1780981822.282306 81168 terse_processor.cc:1645] Cancelling session.
W0000 00:00:1780981822.282704 81168 decoder_endpointer_stream.cc:242] Acoustic ep reader thread cancelled.
W0000 00:00:1780981822.282722 81168 decoder_endpointer_stream.cc:242] Prefetch reader thread cancelled.
I0000 00:00:1780981822.282949 81168 terse_processor.cc:1492] Starting session.
I0000 00:00:1780981839.129265 131926 terse_processor.cc:956] Final recognition has been created.
I0000 00:00:1780981839.173272 81168 terse_processor.cc:3025] TerseProcessor HasRecognitionEvent With Final
I0000 00:00:1780981839.173296 81168 terse_processor.cc:3355] Audio pin advanced by: 16.92s
I0000 00:00:1780981839.173470 81168 terse_processor.cc:3415] Longform resets session because this session is 16.92s long.
I0000 00:00:1780981839.173500 81168 terse_processor.cc:1645] Cancelling session.
W0000 00:00:1780981839.173929 81168 decoder_endpointer_stream.cc:242] Acoustic ep reader thread cancelled.
W0000 00:00:1780981839.173948 81168 decoder_endpointer_stream.cc:242] Prefetch reader thread cancelled.
I0000 00:00:1780981839.174332 81168 terse_processor.cc:1492] Starting session.
I0000 00:00:1780981840.714665 81168 soda_async_impl.cc:1291] Current audio timestamp: 1780981840087778
I0000 00:00:1780981870.732931 81168 soda_async_impl.cc:1291] Current audio timestamp: 1780981870087778
I0000 00:00:1780981877.912018 132051 terse_processor.cc:956] Final recognition has been created.
I0000 00:00:1780981877.962263 81168 terse_processor.cc:3025] TerseProcessor HasRecognitionEvent With Final
I0000 00:00:1780981877.962296 81168 terse_processor.cc:3355] Audio pin advanced by: 38.85s
I0000 00:00:1780981877.962633 81168 terse_processor.cc:3415] Longform resets session because this session is 38.85s long.
I0000 00:00:1780981877.962689 81168 terse_processor.cc:1645] Cancelling session.
W0000 00:00:1780981877.963052 81168 decoder_endpointer_stream.cc:242] Acoustic ep reader thread cancelled.
W0000 00:00:1780981877.963075 81168 decoder_endpointer_stream.cc:242] Prefetch reader thread cancelled.
I0000 00:00:1780981877.963615 81168 terse_processor.cc:1492] Starting session.
I0000 00:00:1780981886.348369 132223 terse_processor.cc:956] Final recognition has been created.
I0000 00:00:1780981886.412668 81168 terse_processor.cc:3025] TerseProcessor HasRecognitionEvent With Final
I0000 00:00:1780981886.412775 81168 terse_processor.cc:3355] Audio pin advanced by: 8.37s
I0000 00:00:1780981886.412905 81168 terse_processor.cc:3415] Longform resets session because this session is 8.37s long.
I0000 00:00:1780981886.412921 81168 terse_processor.cc:1645] Cancelling session.
W0000 00:00:1780981886.413291 81168 decoder_endpointer_stream.cc:242] Acoustic ep reader thread cancelled.
W0000 00:00:1780981886.413313 81168 decoder_endpointer_stream.cc:242] Prefetch reader thread cancelled.
I0000 00:00:1780981886.413729 81168 terse_processor.cc:1492] Starting session.
* そら そっ か。

感想

GoogleのSODAは単一の巨大モデルではなく、かなり実用品寄りのパイプラインだった
モデルは一般的なReazonSpeechを学習したicefallと同じようにパラメーターの約90%がEncoder
そして、その巨大なEncoderを常時回さず、436KBのVADを先に置く
語頭を落とさないためにprefetch とリングバッファを使う
発話終了はVADだけで決めず、FSTとLASの言語スコアも見る
日本語のために Mozc辞書、読み変換、姓名辞書、動的コンテキスト注入も入っている
音声会話システムを作ると、ASRのモデル精度だけを見がちになる
でも体験として効くのは、発話開始、語頭保持、発話終了、partial/final result、句読点、コンテキスト注入、マイクゲイン、UI 表示の全部
数十億人に使われている仕組みだけあってよくできていた

参考文献

音声系の技術の備忘録ノート

Fri, 24 Apr 2026 20:57:39 +0900

背景

音声系技術を実装した時にメモしていた事を残す
次のようなシステムやモデルを作っていた
- LLM会話システム、TTSモデル、ASRモデル、VADモデル
記憶がフレッシュなうちに備忘録として残す
特に音周りの技術は初めてだったので、用語を整理した

用語 / 技術

会話の組み立て

LLM
- Large Language Model
- 膨大なテキストデータを学習し、人間のように自然な文章を生成・理解するAI技術
Llama.cpp
- Gemma4をサーバー化するのに使用
- https://github.com/ggml-org/llama.cpp
Gemma 4
- Googleが開発した2026年4月時点で最新のEdge LLM
- 今回は、量子化されたQ4_K_M.ggufを使用
- https://huggingface.co/unsloth/gemma-4-E2B-it-GGUF

音声発話

TTS
- Text to Speech
- テキストを音声に変換する技術
piper-plus
- 高速・高品質なニューラルテキスト音声合成 (TTS) システム
- 英語版のpiperを日本人がforkしたリポジトリ
- 今回は日本語のTTSに使用
VITS
- Conditional Variational Autoencoder with Adversarial Learning for End-to-End Text-to-Speech
- piper-plusのモデルの名前

音声認識

STT
- Speech to Text
- 音声をテキストに変換する技術
ASR
- automatic speech recognition
- 音声認識技術
LID
- language identification
- 言語識別
SER
- speech emotion recognition
- 音声感情認識
AED
- audio event detection
- 音響イベント検出
AEC （分類）
- audio event classification
- 音響イベント分類
Speaker identification / Speaker verification
- Speaker Identification（話者識別）
- Speaker Verification（話者照合/認証）
- 違いは、「誰であるか特定する（1対N）」か、「主張された本人か確認する（1対1）」かという点
speech enhancement
- 「音声を綺麗にする技術」の総称
- ノイズ除去、残響除去、帯域拡張など
- タスク: 「音声 + ノイズ」→「音声」
- サブtopics:
  - Speech Denoising（ノイズ除去）
    - 背景ノイズの除去
    - 例：エアコン、車、カフェの雑音など
  - Dereverberation（残響除去）
    - 残響、リバーブの除去
    - 部屋の反射音を取り除く
  - Bandwidth Extension（BWE／帯域拡張）
    - 狭帯域音声を高音質化
    - 例：電話音声（8kHz）→ 高音質音声（48kHz）
  - Declipping
    - クリッピング歪みの修復
    - 音割れした音声の復元
  - Packet Loss Concealment
    - パケットロスの補完
    - 通信で欠落した部分を補間
  - Codec Artifact Removal
    - 圧縮による劣化の修復
    - 例：MP3、AACなどの圧縮ノイズ除去
Source separation
- Speech Separationは音源分離の技術
- タスク: 「音声A + 音声B」→「音声A」と「音声B」
- lib:
  - https://github.com/deezer/spleeter
  - https://github.com/Anjok07/ultimatevocalremovergui
Audio tagging
- Audio taggingは、音声データ内の特定の音響イベントやシーン（会話、音楽、環境音など）を自動または手動で識別し、ラベル（タグ）を付ける技術
- 音声を「セリフ」「BGM」などに分類できる
KWS
- Keyword Spotting
- 「OK Google」などのような、キーワード認識技術
Kotoba Whisper
- 日本語に強いWhisper
- 今回は、tiny版のGGML版の量子化されたq5を使用
- 最速で動かすため、Greedy decodingとBeam Searchを調整した
Whisper.cpp
- whisper.cppは音声データを読み込んでテキスト文章に変えてくれるソフト
- Kotoba Whisperをサーバー化するのに使用
- https://github.com/ggerganov/whisper.cpp
sherpa
- 次世代KaldiとONNX Runtimeを活用した軽量な音声処理ツールボックス
- https://github.com/k2-fsa/sherpa-onnx
Kaldi
- Kaldi Speech Recognition Toolkit
- 長らく音声認識のデファクトスタンダードツールとして利用されていたC++ライブラリ
VOSK
- エッジで動く音声認識ツールキット
- 日本語モデルは、small: 48M、big: 1GBが用意されている
SenseVoice
- ASR、LID、SER、AEC（分類）、AEDを含む音声理解能力を備えた音声基盤モデル
- https://github.com/FunAudioLLM/SenseVoice/tree/main

音認識

VAD
- Voice Activity Detection
- 発話区間検出のための技術
Silero VAD
- 高性能で軽量（約2MB）なオープンソースのVADモデル
- CPUで1ms以下で動作する高速性を持ち、WebRTC VADよりも高精度で、ノイズの多い環境でも音声を正確に検知 (according to the AI)
PCM
- Pulse Code Modulation：パルス符号変調
- 非圧縮・高品質: 音波を一定周期でサンプリングし、量子化してデータ化するため、原音に忠実
VAP
- Voice Activity Projection
- https://github.com/inokoj/VAP-Realtime
- https://github.com/maai-kyoto/maai

音の精度向上

PipeWire
- Linuxのマルチメディアサーバー
- AEC（キャンセル）やNS、AGCの機能がある
- aec_method=webrtcを今回は使用した
AEC （キャンセル）
- acoustic echo cancellation
- スピーカーから出た周り込みを消す技術
NS
- Noise Suppression
- 扇風機、キーボード、エアコンなどの雑音を減らす技術
AGC
- Automatic Gain Control
- 声などの音量を自動調整する技術

音の理解向上

Punctuation
- 意味は句読点で、句読点や記号を自動で補うこと
Speaker Diarization
- 録音された音声データから「いつ、誰が話したか（Who spoke when?）」を特定し、発言ごとに分割・分類する技術
- いわゆる話者分離

AIモデルの処理速度向上

LLMの量子化
- Quantization
- モデルのパラメータを高精度な数値（16/32bit浮動小数点）から低精度な数値（4/8bit整数）に変換し、モデルサイズを大幅に軽量化・高速化する技術
- 精度低下を最小限に抑えつつ、少ないVRAM（GPUメモリ）で動作させ、安価なハードウェアでの推論を可能
ONNX
- Open Neural Network Exchangeの意味
- 異なるAIフレームワーク間でモデルを共有・実行するためのフォーマット
OpenMP
- C/C++のマルチスレッド並列処理を簡単に書くための仕組み
- 共有メモリ環境での並列プログラミングを支援する技術

双方向会話

Full Duplex
- Full Duplex（全二重）音声技術は、AI対話システムにおいて、ユーザーとAIが「話しながら聞く（同時双方向）」ことを可能にする技術
- 従来の「話して、待って、聞く」というターンベースの音声対話とは異なり、人間同士のような自然な相槌や発話のオーバーラップを実現する
GPT Realtime
- リアルタイムで低遅延の会話操作を処理するように設計された音声入力、音声出力の会話システム
- Function ToolやMCPも使える
j-moshi
- 日本語版のmoshi
- 同時双方向的な特徴をモデル化できるfull-duplex音声対話システム
personaplex
- real-time, full-duplex speech-to-speech conversational model
- システムプロンプトを入れる事ができる
- https://github.com/NVIDIA/personaplex

処理速度向上

見える化
- わかりにくい状態を見て分かる形にすること
- 例えば、処理している事がわかる用にインジケータを出さないと処理速度が遅く感じた
非同期
- 処理の完了を待っている間に、別の処理を進める仕組み
- 応答性とスループットを最大化する手法
マルチスレッド化
- 計算タスクを複数コアで並列処理する仕組み
- 応答性とスループットを最大化する手法
CPU Affinity
- 処理ごとにCPUのCoreを分離する技術
- 複数の重い処理がありOSのスケジューラーに邪魔されず処理したい時に使う
CPU clock scaling
- OSが消費電力の削減やパフォーマンスの向上のために CPU の周波数を上げ下げする技術
- Jetsonでは性能と消費電力・発熱のバランスを取るためのCPU周波数制御をしている
- 今回はこれをOffにした
Producer-Consumerパターン
- データを生成する「プロデューサー」と処理する「コンシューマー」の間にキュー（Queue）を挟み、非同期で処理を行う設計パターン
- タスクキュー、ジョブキュー、メッセージキューなど色々な呼び方がある
- デカップリングの一種
TinyML
- 超低消費電力・小型のデバイス上で機械学習を動かす技術
- 数KB〜数MB程度のメモリしかない小さなチップ上で、音声認識・異常検知・画像分類などを行うAI

音声分離と話者分離

音声分離（speech separation）
- 話者ごとに音声を分離するモデル
- 例えば、Aさんの音声、Bさんの音声のように、一つの音声を物理的に分ける
話者分離（diarization）
- 時間ごとに誰が喋っているか分類するモデル
- 例えば、ある音声で0~~10秒はAさん、11~~12秒はBさんのように

有名なモデル:

pyannote.audio
Asteroid / ConvTasNet
SepFormer / SpeechBrain
MossFormer2 / ClearerVoice-Studio

音声分離の用語

bleed / leakage / crosstalk
- 本来ほしい音源に、別の音が漏れ込んでいる状態
- 音声分離では、分離しきれなかった他パートの残留音を指すことが多い
- 例：ボーカル stem にドラムや伴奏がうっすら残る
artifacts
- AI分離やノイズ除去などの処理で生じる不自然な副作用
- 例：「金属っぽい音」「水中っぽさ」「揺れ」「チリチリ音」「音の欠け」など
- bleed とは違い、元の音がそのまま漏れているというより、処理によって変質した音
doubling / ダブリング
- 同じ音や声が重なって二重に聞こえること
- 意図的な録音手法の場合もあるし、分離処理の副作用として起きる場合もある
- 例：ボーカルが一枚ではなく、薄く二枚重なって聞こえる
phasing / フェイジング
- 似た音が少しズレて重なり、位相干渉でシュワシュワ・うねうね・薄く聞こえる現象
- ダブリングに近いが、より「干渉」「位相ズレ」感が強い
ghosting / ゴースト成分
- 本来そこに残ってほしくない、薄い残像のような音
- 例：消したはずのボーカルや伴奏の輪郭が、影のように残っている
- 技術的に厳密な用語というより、聴感上の説明として使われることが多い
residual / residual component / 残留成分
- 分離・除去しきれずに残った音
- bleed や ghosting を含めて広めに表せる、やや技術寄りで無難な言い方

相槌とフィラー

フィラー（filler / filler word / filler sound）
- フィラーは、話し手が「間を埋める」ために入れる音や言葉
- 例: um, uh, well, like, you know, I mean, sort of / kind of
相槌（backchannel / backchannel response）
- 相槌は、聞き手が「聞いていますよ」「理解していますよ」と示す反応、verbal nodsという事
- 例: yeah, uh-huh, right, I see, really?, sure, exactly, that makes sense

種類	主に使う人	役割	例
フィラー	話し手	間を埋める・考える時間を作る	えー、あのー、えっと
相槌	聞き手	聞いていることを示す・反応する	うん、はい、なるほど

プロソディ

プロソディ（韻律）とは、話す速度、音の強弱（ストレス）、高低（イントネーション）、ポーズなど、発話に伴う音声の音楽的・律動的な要素の総称。

プロソディは主に以下の5つの要素で構成される。

イントネーション（抑揚）：文末のピッチの上げ下げ。疑問形や感情を表す。
ストレス・アクセント：単語や文の中で、どの音を強く・高く発音するか。
リズム：言葉の長短や強弱が織りなす拍子。
ポーズ：話の切れ目に入る「間」。意味のまとまりを作る。
プロミネンス：文中で特に強調したい部分を際立たせること。

WAVとPCM

WAV
- 音声ファイルの形式
- 音声データを入れる「コンテナ」のようなもの
- 拡張子は .wav
PCM
- Pulse Code Modulation：パルス符号変調
- 音波を一定間隔でサンプリングし、音量を数値化したもの
- 非圧縮の音声データとして扱われることが多い

Mel尺度とメルスペクトログラム

Mel尺度
- Mel尺度は、人間の聴覚に近い周波数スケールの事
メルスペクトログラム
- メルスペクトログラムは、音の周波数成分（音のエネルギー分布）をメル尺度で表したもの
- 普通のスペクトルは、たとえば 100Hz、200Hz、1000Hz、5000Hz……のように物理的な周波数で音を分解する
- でも人間の耳は、周波数を等間隔には感じず、低い音の違いには敏感で、高い音の細かい違いにはやや鈍い
- そこでメル尺度で、音を人間の耳に近い感覚で周波数ごとに分ける
- 深層学習・CNN/Transformer系だとlog-mel spectrogramが使われがち

STFTとMFCC

STFT
- Short-Time Fourier Transform
- 音声を短い時間窓に区切り、それぞれの区間で周波数成分を計算する手法
- 出力は時間 × 周波数のスペクトログラム
- 実際の音声特徴量では、STFTの複素スペクトルから振幅スペクトログラムやパワースペクトログラムを使うことが多い
MFCC
- Mel-Frequency Cepstral Coefficients（メル周波数ケプストラム係数）
- MFCCはメル特徴量を圧縮したもの
- 古典的な音声認識、特にGMM-HMM/HMM時代によく使われた特徴量
- 深層学習ASRでは、MFCCよりもlog-mel spectrogram / log-mel filterbank featuresが使われることが多い
- ただし、wav2vec 2.0やHuBERTのようにraw waveformから特徴を学習するモデルもある

MFCCまでの処理のフロー

一例として、MFCCまでは、以下のようなフローになる。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


音声波形
 ↓
短い区間に分ける（フレーミング）
 ↓
窓関数をかける（Hamming窓など）
 ↓
FFT / STFT で周波数成分に変換
 ↓
パワースペクトルを計算
 ↓
メルフィルタバンクをかける
 ↓
各メル帯域のエネルギーを取る
 ↓
logを取る
 ↓
fbank特徴量（log Mel filter bank）
 ↓
DCT
 ↓
MFCC
 ↓
CMVN
 ↓
音声認識モデルへ

サンプリング周波数・ビット深度・チャンネル

サンプリング周波数
- 1秒間に何回、音を測るか
- 例: 16kHz、44.1kHz、48kHz
- ASRでは16kHz monoに変換して扱うことが多い
ビット深度
- 1サンプルの音量をどれくらい細かく表すか
- 例: 16bit、24bit、32bit float
チャンネル数
- monoは1ch、stereoは2ch
- 音声認識ではmonoに変換して扱うことが多い
sample format
- s16le、float32 など
- s16le は signed 16bit little-endian の意味

window、hop length

window size
- 1回の周波数分析に使う音声の長さ
- 例: 25ms
hop length / stride
- 次の分析窓へどれくらいずらすか
- 例: 10ms
spectrogram
- 時間ごとの周波数成分を並べたもの
- 横軸が時間、縦軸が周波数、色や値がエネルギーを表す
log-mel spectrogram
- メルスペクトルの値に対数を取ったもの
- 音声認識や音声分類の入力特徴量としてよく使われる

VADとEndpointing

VAD
- Voice Activity Detection
- 今この瞬間に音声があるかを判定する技術
- 「声か、無音か」を見る
Endpointing
- 発話が終わったかを判定する技術
- ASRやLLMにいつ入力を渡すかを決める

音声AIの評価指標

RTF
- Real Time Factor
- 音声の長さに対して、処理に何倍の時間がかかったか
- RTF < 1 ならリアルタイム処理可能
- 例: 10秒の音声を2秒で処理できるならRTF=0.2
WER
- Word Error Rate
- 単語単位の音声認識エラー率
- 英語など単語区切りが明確な言語でよく使われる
CER
- Character Error Rate
- 文字単位の音声認識エラー率
- 日本語ASRではWERよりCERの方が扱いやすい場合がある
MOS
- Mean Opinion Score
- TTSなどの音質を人間が主観評価する指標

Gain・dBFS・Clipping

Gain
- 音量を増幅・減衰させる量
- マイク入力が小さすぎるとASR精度が落ち、大きすぎると音割れする
dBFS
- デジタル音声における音量の単位
- 0 dBFS が最大値で、それを超えるとクリッピングする
Clipping
- 音量が大きすぎて波形の上下が潰れる現象
- 音割れの原因になる
- 一度クリッピングした音声は完全には元に戻せない
Normalization
- 音声全体の音量を一定基準に揃える処理

Ring buffer / Chunking

Ring buffer
- 固定長のバッファを循環させながら使うデータ構造
- マイクから連続的に入ってくる音声をリアルタイム処理する時に便利
Chunking
- 音声を一定長の塊に分けて処理すること
- 例: 10ms、20ms、30ms、1秒など

注意点:

チャンクが短いほど低遅延だが、認識や判定が不安定になりやすい
チャンクが長いほど安定するが、遅延が増える
VAD、ASR、TTSで最適なチャンク長は異なる

CMVN

画像の前処理でやるものと同じように、分布の中心を平均にして、スケールをSDにする処理の事。

CMVN
- CMVN（Cepstral Mean and Variance Normalization）とは、音声特徴量を「平均0・分散1」にそろえる前処理
- CMVN = CMN + CVNで、画像の前処理と同じようなZ値化のための統計処理
CMN：平均を引く
- 特徴量の中心を0にする
CVN：標準偏差で割る
- ばらつきを1にする

bank、fbank

filter bank

filter bank は、複数の周波数フィルタを並べたもの
イメージとしては、音声に対するザルのようなもの

1
2
3
4
5
6
7


音声信号
 ↓
[低音フィルタ] → エネルギー1
[中低音フィルタ] → エネルギー2
[中音フィルタ] → エネルギー3
[高音フィルタ] → エネルギー4
...

fbank
- 各時間フレームごとに、メル周波数帯域ごとのログエネルギーを並べたもの
- 例えば、80次元 fbank なら、1フレームごとにこういうベクトルになる
  1 2 3 4
  
  frame 1: [band1, band2, band3, ..., band80] frame 2: [band1, band2, band3, ..., band80] frame 3: [band1, band2, band3, ..., band80] ...
- これが時間方向に並ぶので、画像っぽく見るとスペクトログラムみたいになる

CTCとアライメント不明問題

アライメント不明問題
- 音声の波形データ（いつ、どんな音が鳴ったか）と、テキスト（文字データ）の対応関係が不明・不正確になってしまう問題のこと
- 例:
  1 2
  
  - 入力: 音声フレーム 100個 - 出力: 文字列 "hello" 5文字
- 上記のような、入力は長い時系列データだけど、出力は短いラベル列になる
- しかも、「どの音声フレームが h に対応するか」「どこから e か」みたいな対応関係は普通はわからなくなる
CTC
- Connectionist Temporal Classification
- 日本語だと「結合主義的時系列分類」
- 入力と出力の対応位置がわからない時系列タスク（アライメント不明問題）で使う損失関数
- CTC では、通常の文字ラベルに加えてblank（-）という特殊ラベルを使う
1

h - - e l - l o
- そして、最後にblank を消して、連続重複をまとめることでhelloにする
- つまり、CTCは、ある正解ラベル列に対応しうる多数のアライメント候補を全部考慮して、その合計確率を最大化するように学習する

CTCとRNN-T

CTC
- 学習が速い
- encoder-onlyで構造がシンプル
- 出力形状は主に時間T × 語彙V
- ベースラインや高速学習に向いている
RNN-T
- CTCより学習は重い
- encoder + prediction network + joint network を使う
- 時間T × 出力長U の格子上で計算するため、CTCよりメモリ・計算量が大きい
- ただし、出力履歴を使えるため精度やストリーミングASRでは有利になりやすい
- pruned RNN-Tなどの最適化で学習速度はかなり改善できる

BPTTとTBPTT

RNN 系モデルで長い系列を学習するときに使う誤差伝搬の仕組み。

BPTT
- BPTT / Backpropagation Through Time の略
- シリーズ全体に対して過去方向へずっと誤差を逆伝播する
- たとえば文章が 1,000 トークンあるなら、理屈上は 1,000 ステップぶん遡って勾配を計算する仕組み
TBPTT
- Truncated Backpropagation Through Time の略で、日本語だと「切り詰めた時間方向の誤差逆伝播」
- シリーズを短い区間に分割して、たとえば 20 ステップごとや 100 ステップごとに区切って学習する仕組み

Conformer、Emformer、Zipformer

音響特徴量を高レベル表現に変換するacoustic encoder。

Conformer
- Transformer + CNN の王道ASR encoder
- 通常はchunk attention / causal convなどでストリーミング化
- 精度が高く、実装・知見が多い
Emformer
- Streaming前提のmemory-efficient Transformer
- 入力をsegmentに分け、left/right contextとmemory bankを使う
- 低遅延streamingに素直。Torchaudioにも実装あり
Zipformer
- Conformerを高速・省メモリ・高精度に再設計した新しめのencoder
- chunk/cached attentionなどでstreaming対応
- icefall系でよく使われる
- 速い・省メモリ・精度が良い傾向だが、構造が複雑。実装依存が強め

音素、音節、モーラ

音の３つの単位のこと。

音素（Phoneme）
- 意味を区別できる最小の音韻単位
- 例えば日本語では /a/ や /k/ などが音素
- 「か」は /k/ + /a/ から成る
- 音声認識では、音素はラベル単位の一つとして使われることがある
- しかしが、近年のASRでは文字、サブワード、音節なども広く使われる
モーラ（Mora）
- 日本語のリズムを構成する拍の単位
- 普通の仮名1文字はおおむね1モーラ
- しかし、小さい「ゃ・ゅ・ょ」は単独では1モーラになならない
- 一方で「っ」「ん」「ー」はそれぞれ1モーラとして数える
- 例：「きっかけ」は「き・っ・か・け」で4モーラ、「にゃお」は「にゃ・お」で2モーラ
音節（Syllable）
- 母音を中心とした発音のまとまり
- 英語などではリズムや強勢を分析する基本単位になる
- 日本語ではモーラと音節が一致する場合もある
- しかし、「かん」「きっ」「こう」のように、1音節が複数モーラを含む場合がある

ラティスとN-best list

ASRでは、N-Best Listはリストで、ラティスはGraphという違いがある。

N-best list
- N-best list は、音声認識が出した候補を上から順に並べたもの
  1 2 3 4
  
  1. 明日は雨です 2. 明日は飴です 3. 明日は雨ですか 4. 明日晴れです
- つまり、候補ごとに完成文が1本ずつあるイメージ
ラティス
- ラティスは、候補をグラフ（多数の候補経路）として表す
  1 2 3
  
  開始 → 明日 → は → 雨 → です → 終了 ↘ 飴 ↗ ↘ ですか → 終了
- 実際には各枝に、音響スコア・言語モデルスコア・時間情報などが付いている
- ラティスでは、共通部分を共有しながら、途中の分岐を保持

n-gram

n-gramは、文章や音声を連続する n 個の単位のまとまりとして見る考え方
単位は、文字・音素・モーラ・単語など何でもあり
ある単語の次に、どの単語が来やすいかを確率で表す
たとえば、明日はの次には、雨晴れ休み仕事などが来そう。
n-gram言語モデルでは、たとえば bigram なら、$P(雨 | は)$
つまり「『は』の次に『雨』が来る確率」を使う
trigram なら、$P(雨 | 明日, は)$
つまり「『明日は』の次に『雨』が来る確率」を使う

greedyとbeam search

greedy
- その瞬間いちばん良い候補だけを選ぶ
- たとえばASRで、音声から文字を1つずつ出すとする
  1 2 3 4
  
  1文字目候補: あ 0.6 か 0.3 さ 0.1
- greedy はここで あ を選ぶ
- 次に、以下なら め を選ぶ
  1 2 3 4
  
  2文字目候補: め 0.5 ね 0.4 れ 0.1
- 結果： あめ
- シンプルで速いが、弱点がある
- 最初に選んだ「あ」があとで不自然になっても、戻れない
beam search
- 上位いくつかの候補を残しながら進む
- beam search は、毎回1つだけに絞らず、上位いくつかを残す
- この「残す候補数」を beam width と言う
- beam width = 3 なら、各ステップで上位3候補くらいを保持する
  1 2 3 4
  
  1文字目: あ 0.6 か 0.3 さ 0.1
- ここで greedy なら「あ」だけだが、beam search は例えば以下を残す
  1 2 3
  
  あかさ
- そして、次の文字を足して、下のように複数候補を作り、スコアが高いものをまた上位だけ残す
  1 2 3 4 5 6
  
  あめあねかめかねさめさね
- つまり、途中で多少スコアが低くても、後半で自然な文になる可能性がある候補を捨てにくい

マシーン、オートマトン、トランスデューサー

マシーンは「状態を持つ広義の機械」、オートマトンが「状態遷移モデルで判定機」、トランスデューサーは「入力を出力に写す変換器」。

マシーン
- 状態を持つ一般的な仕組み
- マシーン = 計算や処理を行う抽象的・実用的な「機械」一般
- 実用・工学寄りの文脈でよく使われる
- 例: Finite-State Machine = 有限個の状態を持つ機械
オートマトン
- オートマトンは、入力を読みながら状態を変えていく抽象的な計算モデル
- 例
  1 2
  
  状態A --入力x--> 状態B 状態B --入力y--> 状態C
- 重要なのは、基本的には入力を受け取って、受理するかどうかを判定するものだという点
トランスデューサー
- トランスデューサーは、入力を読みながら出力も出す変換器
- 例
  1 2
  
  /k a/ → か /a m e/ → 雨

FSTとWFST

FS
- Finite State
- 有限状態
- 扱える状態の数が有限である、という意味
FST
- Finite State Transducer
- 有限状態トランスデューサー
- つまり、有限状態で変換するということ
WFST
- 重み付きFST

LASとLAS Scorer

LAS

LAS は、ASR文脈では、Listen, Attend and Spell の略
一言でいうと、「音声を聞いて、重要な部分に注意を向けながら、文字列を直接出力するEnd-to-End音声認識モデル」

1
2
3


Listen : 音声特徴量を読み取る（エンコーダ表現）
Attend : どの時間部分に注目するか決める（Attention）
Spell : 文字やサブワードを1つずつ出力する

LAS Scorer
- ASR文脈では、LASモデルの出力にスコアを付ける仕組

distillation trainingと転移学習とFTの違い

Fine-tuning / 転移学習
- 事前学習済みモデルを持ってきて、追加データの正解ラベルで学習
- 人間が用意した正解ラベルに合わせる
Distillation
- 大きいteacher モデルの挙動を、小さい student モデルに真似させる
- 正解ラベルだけでなく、teacher が出す確率分布や中間表現を使う
- teacher モデルの挙動に合わせる

Forced alignmentとSoft alignment、Hard alignment

Forced alignment

音声データと、すでに正しいと分かっている文字列・音素列を入力して、各単語や音素が音声のどの時刻に対応するかを推定する処理

例

1
2
3
4
5
6
7


音声：「今日は晴れです」
正解テキスト：「今日は晴れです」
出力：
今日：0.00〜0.45秒
は：0.45〜0.58秒
晴れ：0.58〜1.05秒
です：1.05〜1.30秒

Soft alignment、Hard alignment

各音声フレームや入力要素を、特定の1つの単語・音素・トークンに明確に割り当てる表現方法

例

1
2
3


たとえば、ある音声フレームを、
音素 /k/ に100％割り当てる → Hard alignment
/k/ に70％、/a/ に30％割り当てる → Soft alignment

促音・拗音・撥音など

清音（せいおん）
- 日本語のひらがなのこと
促音（そく音）
- 「がっこう」「さっぱり」などの語において、小さく「っ」と表記される音
- 「っ」「ッ」（小さいつ）
- => つまる音
拗音（よう音）
- 「きゃ」「きゅ」「きょ」などの語のように、一音節が仮名2文字で表記される音
- 「〇ゃ〇ゅ〇ょ」「〇ャ〇ュ〇ョ」（小さいやゆよがつくもの）
- ※拗音には、限定的ですが、小さい「〇ゎ」「〇ヮ」で表記されるものもある
- => はねる音
撥音（はつ音）
- 「ん」と表記される音。通常、語中または語尾で一音節をなす鼻音
- 「ん」「ン」
- => ねじれる音
長音（ちょう音）
- 前の母音の音を伸ばして発音する音
- ひらがなでは「ー（長音符）」や母音（あ・い・う・え・お）をそのまま当てて表記
- => のばす音
濁音
- 濁音は、濁った音
- 「〝」がつく音のこと
半濁音
- 半濁音は、「ぱぴぷぺぽ」のような、丸がついた音
- 「゜」がつく音のこと

ハイブリッド型とE2E型

DNN-HMMハイブリッド型
- 音声認識を複数の部品に分けて組み合わせる
- アーキ
  - DNN：各時刻の音声が、どの音素状態らしいかを推定
  - HMM：音素が時間方向にどう遷移するかをモデル化
  - さらに、発音辞書や言語モデルを使って単語列を決定
- フロー
  1 2 3 4 5 6 7 8 9
  
  音声 ↓ 音響特徴量 ↓ DNNによる音素・HMM状態の確率推定 ↓ HMM＋発音辞書＋言語モデルで探索 ↓ 文字・単語列
End-to-End型
- 音声から文字列までを、なるべく1つのモデルで直接学習する
- フロー
  1 2 3 4 5
  
  音声 ↓ ニューラルネットワーク ↓ 文字・単語列
- 代表的なモデル
  - CTC
  - Attention Encoder-Decoder
  - RNN-T
  - Transformer / Conformer系
  - WhisperのようなEncoder-Decoder型

ハイブリッドとE2Eの違い:

観点	DNN-HMMハイブリッド型	End-to-End型
構成	複数のモデル・辞書を組み合わせる	1つのモデルとして統合的に学習
出力単位	HMM状態や音素を経て単語へ変換	文字・サブワード・単語を直接出力
アライメント	明示的な音素・状態アライメントを使うことが多い	CTCやAttentionなどが内部で学習
発音辞書	基本的に必要	不要な場合が多い
言語モデル	外部言語モデルを明示的に使用	モデル内に含む場合が多い。外部LMも併用可能
学習工程	複数段階で複雑	比較的シンプル
必要データ量	比較的少ないデータでも構築しやすい	一般に大量データで強みを発揮
解釈・制御	音素や辞書単位で制御しやすい	内部処理が見えにくい
新語対応	辞書に発音を追加しやすい	トークン設計や追加学習が必要なことがある
ストリーミング	実績が豊富	RNN-Tなどは得意。モデル方式に依存

DNN-HMMハイブリッド型のコンポーネント

DNN-HMMハイブリッド型の音声認識システムは、主に次の4要素を組み合わせる。

音響モデル
- 音声信号から、どの音素・HMM状態らしいかを推定する
- 入力された特徴量がどの単語の音声に該当する確率が高いかを表す、音響スコアを算出する
- 音声認識においてHMMは、「単語内での音素の時系列変化」を表現するモデルとして使われる
- 発話の速さによる影響を吸収するのが目的
発音辞書
- 単語と音素列の対応を定義する
- それぞれの単語が、どのような音素の並びで表現されるかを定義する
- 発音辞書は、「秋」「紙」といった単語とその読み、そして ”a-k-i”・”k-a-m-i” といった音素の表記とを紐づける
- 発音辞書により、単語を音素列（音素の並び）で表すことができる
- 逆に言えば、発音辞書に書かれていない単語は音素列で表すことができないので、認識結果に登場しないということになる
言語モデル
- どの単語列が自然・起こりやすいかを評価する
- 単語の並びが言語的に自然かどうかを表す、言語スコアを算出する
- 「文脈」を判断する役割を果たしているのが言語モデル
デコーダ／探索アルゴリズム
- 特徴量がどの音っぽいかを判定し、その確率を出力
- （ハイブリッド型では音素単位、End-to-End型では文字や単語単位）
- 「発音辞書」「音響モデル」「言語モデル」から得られた音響スコアと言語スコアをもとに判断すし、
- 最もスコアが高い「単語の並び」を探索して認識結果とする処理をデコードと呼ぶ

RNNとLSTMとGRU

文章や音声のような時系列データを処理するニューラルネットワーク。

RNN
- 過去の隠れ状態と現在の入力から、新しい隠れ状態を計算する
LSTM
- LSTMは、通常のRNNに記憶を管理するゲートを追加したモデル
- 主に3つのゲートがある
  - 忘却ゲート：過去の情報をどれだけ忘れるか
  - 入力ゲート：新しい情報をどれだけ記憶するか
  - 出力ゲート：記憶から何を出力するか
- また、LSTMは通常の隠れ状態とは別に、長期記憶を保持するセル状態を持つ
GRU
- Gated Recurrent Unit
- GRUもRNNの一種だが、情報を残すか忘れるかを制御するゲートを持っている
- 主に2つのゲートがある
  - 更新ゲート：過去の情報をどれくらい残すか
  - リセットゲート：過去の情報をどれくらい無視する
- GRUもゲートを持つRNNだが、LSTMより構造を簡略化している
- BiGRUもよく利用される

共調音の順行性と逆行性

順行性
- 前の音が後の音に影響する
逆行性
- 予測的：後の音を発音する準備が前の音に現れる

GRUは前から処理するため主に順行性の影響を捉えるが、BiGRUは前後の音声フレームを見るため、両方向の共調音をモデル化しやすい。

1
2
3
4


音声： k y o o
 ↑ 現在
GRU： ← 過去の音だけを見る
BiGRU： ← 過去 ＋ 未来を見る →

MambaとGRU

GRU
- 1ステップずつ、ゲートを使って過去の情報を更新するRNN
Mamba
- 状態空間モデルを使い、入力に応じて「何を記憶し、何を捨てるか」を選択するモデル
- Mambaは、Selective State Space Modelという仕組みを使う
- Transformerより並列化しやすい構造になっている

Bidirectional vs Causal

基本的に情報量が多い分、BiXXXの方が精度が高い。

Causal（Unidirectional, UniXXX）
- 時刻tの出力は、現在までの情報だけで計算
- リアルタイム処理など
- onlineで使われる
Bidirectional（BiXXX）
- 時刻tの出力を、前後両方の情報から計算
- 前後の文脈を利用できる
- offlineで使われる

TDNNとTDNN-F

TDNN
- TDNN（Time-Delay Neural Network）は、時間方向の前後関係を扱うためのニューラルネットワーク
- ASR（自動音声認識）では、音声フレーム列のような時系列データを処理するために使われる
- 音声は、ある瞬間だけを見ても「何の音か」が分かりにくく、前後数十ミリ秒の文脈が重要
- TDNNは例えば時刻 t の音響特徴に加えて、t−2, t−1, t+1, t+2 など離れたフレームも入力にして、現在の音素・サブワード・文字などを推定する
- イメージとしては、時間軸に対する1次元CNN
TDNN-F
- TDNN-F は Factorized Time-Delay Neural Network の略
- 通のTDNNを、低ランク分解（factorization）で軽量化・高速化したもの

Parakeetのモデルの違い

stt_en_fastconformer_hybrid_*_streaming_*
- トリーミングASR専用に学習された Cache-aware Streaming FastConformer-Hybrid
- look-ahead を変えて、0 / 80 / 480 / 1040 ms級の遅延を選べる設計
parakeet-unified-en-0.6b
- NVIDIAの新しめの offline と streaming を1モデルで両立させた Unified ASR
- ストリーミング専用ではなく、最低160 ms程度のストリーミング推論にも対応する、という位置づけ
parakeet-tdt_ctc-0.6b-ja
- 日本語、基本オフライン

HMM系の目的関数の違い

MMI / LF-MMI / MPE / sMBR / bMMI は、基本的にHMMを土台にしたASR、特に DNN-HMM / GMM-HMM 系で使われる系列識別目的関数。

MMI / bMMI
- 正解系列と競合系列の確率比を使う
- 典型的な discriminative training
MPE
- phone error を小さくするように最適化する
sMBR
- HMM state 単位の誤りを小さくする
- 実装上は lattice 上で期待リスクを計算することが多い
LF-MMI
- MMIの一種だが、分母側を lattice ではなく事前に作ったグラフで扱いやすくしたもの
- Kaldi chain model ではHMMの状態設計をかなり簡略化しているが、依然としてHMM/FST的な枠組みにいる

区分	手法	何を最適化するか
フレーム単位	CE	強制アラインメントで得た各フレームのHMM状態を当てる
フレーム単位（古典的GMM-HMM）	ML / MLE	正解転写に対する音響尤度
系列識別：確率比	MMI	正解系列の確率を競合系列より高くする
系列識別：確率比	bMMI	MMIで、誤りの大きい競合候補をより強く下げる
系列識別：期待誤り最小化	MPE	期待Phone Errorを小さくする
系列識別：期待誤り最小化	sMBR	期待state accuracyを最大化する（≒ state誤りを下げる）
系列識別：lattice-free版	LF-MMI	lattice-freeで計算するMMI
任意・やや周辺	MPFE	phone frame errorを最小化する

TDTとRNN-Tの違い

RNN-T
- RNN-Tは Encoder、Prediction Network、Joiner からなり、時刻 t と出力済みトークン数 u の格子上でデコードする
- イメージ
  1
  
  blank → blank → blank → blank → 「こんにちは」→ blank → blank ...
- なお、RNN-Tは必ずしも内部がRNNとは限らず、EncoderにConformerやTransformerを使うことが普通
TDT
- Token-and-Duration Transducer
- TDTは同じ Encoder／Prediction Network／Joiner 系の枠組み
- イメージ
  1
  
  blank, 4フレーム進む → 「こんにちは」, 5フレーム進む → ...
- TDTの本質は「blankを出し続けて1フレームずつ進む」処理を、duration予測で圧縮すること

N-gram LLM

N-gram LM は、直前の N個の単語（またはトークン）を見て、次の1個が出る確率を推定する言語モデル
例
- たとえば、I want to eat ...という並びなら、4-gram LM は直前3語のwant to eatを条件にして、
- 次の語が pizza、sushi、lunch などになる確率を出す

blank collapseとcatastrophic forgetting

blank collapse
- これは CTCモデルが blank をほぼ全フレームで高確率に出し、文字列をほとんど出せなくなる現象
- 学習率、データ量・ラベル品質、長さの不整合、語彙設計、fine-tuning設定などが悪いと起きやすい
catastrophic forgetting
- 新しい領域では良くなる一方、元々できていた領域の性能が大きく落ちること
- 既存ASRモデルを新しい話者・方言・言語・ドメインのデータで追加学習したときに起きる

マイクロCERとマクロCER

マイクロCER
- 全体として何文字をどれだけ正しく認識できたか
マクロCER
- 典型的な発話・話者あたり、どのくらい安定しているか

例:

たとえば、2発話ある。
- 発話A：100文字中10誤り → CER 10%
- 発話B：10文字中5誤り → CER 50%
マイクロCER
- (10+5)/(100+10)=13.6%
マクロCER
- (10%+50%)/2=30%

CERとWER

CER（Character Error Rate）
- 文字単位の誤り率
- 日本語・中国語など、単語境界が曖昧な言語でよく使う
- CERでは文字レベルで比較
WER（Word Error Rate）
- 単語単位の誤り率
- 英語など、単語を空白で区切りやすい言語でよく使う
- WERでは形態素解析などで、例えば、今日 / は / 晴れ / ですと区切って比較

どちらも計算式は基本的に同じ。

$$ \frac{S+D+I}{N} $$

S：置換
D：削除
I：挿入
N：正解文の文字数または単語数

情報量とエントロピーとクロスエントロピー

言語モデルのエンコーダーは情報量の圧縮なのでエントロピーとも関係がある。

情報量
- ある事象の「情報量」
- 確率 $p(x)$ の事象 $x$ が起きたときの情報量（自己情報量）は以下になる $$ I(x)=−log_{2} p(x) $$
- 単位は bit
  - 起きやすい事象：情報量は小さい
  - 珍しい事象：情報量は大きい
- たとえば確率 1/2 なら 1 bit、確率 1/8 なら 3 bit
エントロピー
- 各事象の情報量を真の確率分布 $p$で平均したもの
- エントロピー = 平均的にどれくらい驚くか = 平均何bit必要か $$ H(p) = -\sum_{x} p(x) \log_2 p(x) $$
クロスエントロピー
- 「真の分布は p なのに、モデルは q だと思って符号化・予測したら、平均どれだけ損をするか」
- なので、「単なる掛け算」というより、真の出現確率 $p(x)$ で重み付けした、モデル予測 $q(x)$ の負の対数確率の平均 $$ H(p, q) = -\sum_{x} p(x) \log_2 q(x) $$

単位の違い：

log2を使う → bit
ln=logeを使う → nat
log10を使う → hartley

AGCの用語

AGC（Automatic Gain Control／自動gain制御）
- 入力音の大きさに合わせて、マイク音量のゲインを自動調整する仕組み
- 声が小さいときはゲインを上げ、声が大きいときはゲインを下げる
- 音量を一定に近づけて、ASRやVADが処理しやすい状態にする

アタック
- 大きな音が入ったとき、どれくらい速くゲインを下げるか
- 速いほど、急な大声にもすぐ対応できる
- 遅いと、ゲインが下がる前にクリッピングしやすい
リリース
- 大きな音が終わったあと、どれくらいの速さでゲインを元に戻すか
- 遅く戻すと、音量の変化が自然になりやすい
- 速すぎると、音量が上下して不自然になることがある
クリッピング
- 音が録音可能な上限を超え、波形の山が切れてしまうこと
- 音割れや歪みが発生する
- 一度クリッピングした音は、あとから完全には元に戻せない
リミッター
- 音が上限を超えないよう、瞬時にゲインを下げる仕組み
- クリッピングを防ぐ安全装置のようなもの
- 単純に波形を切るのではなく、上限に収まるよう音量全体を抑える

結論

音の中でも会話についての技術で学んだ事をまとめた
会話とはダンシングであり、交通整理が大事
そこをリアルタイムでやるのがミソ