NIIの48,000時間音声音響データセットはTTSの材料になる

NII/LLMCが日本語の「音響コーパス」として CC Audio と Archive.org Audio Dataset を公開した。
ただ開けてみると、データセットというよりは48,000時間超の日本語音声音響リソースをどう集めるかの索引と取得手順、という性格が強い。

NIIのニュースリリースでは「次世代の音声生成AIおよび音声認識AIの研究開発」と書かれている。
ここで気になるのは、これを使うとTTS（Text-to-Speech、音声合成）が作れるのか、音声Embedding解析向けなのか、というあたりだ。

URLリストから音声を取得する

公開物の中心は、音声URLとメタデータとダウンローダーだ。
リポジトリに音声ファイル本体が入っているわけではない。

この形式だと、使う側は次の流れを踏む。

flowchart TD
    A[URLリストとメタデータ] --> B[ダウンローダーで音声取得]
    B --> C[利用規約と到達性を確認]
    C --> D[音声の分割と正規化]
    D --> E[言語や音種別でフィルタ]
    E --> F[ASRやTTSや音響モデルの学習データ]

音声ファイル本体を再配布しないので、巨大なバイナリを置かずに済む。
一方で、リンク切れ、取得失敗、元サイト側の利用規約、ファイル形式のばらつき、重複、ノイズを全部こちらで処理する必要がある。

NIIの発表でも、音声ファイル自体はリポジトリに含まれず、各オリジナルソースの利用規約を守る責任はユーザー側にあると明記されている。
また、メタデータ等は日本の著作権法30条の4が定める情報解析目的に限って利用できる、という条件になっている。

ベクトルは最初から入っていない

「ベクトルどうなってんの」という疑問に対しては、今回の公開物自体はEmbedding済みベクトルの配布ではない、と見たほうがいい。
少なくともニュースリリース上で説明されているのは、音声URL、メタデータ、ダウンローダー、Whisper-ATによる10秒セグメント単位の音響イベント分類だ。

Embeddingは、音声をモデルに通して作る特徴量だ。
同じ音声ファイルでも、何をしたいかでベクトル化の方法が変わる。

目的	入力から作る表現	使い道
音声認識	音素や単語に効くフレーム特徴	音声から文字起こし
話者認識	話者性を表す埋め込み	同一話者判定、話者クラスタリング
TTS	音声トークン、話者埋め込み、韻律特徴	テキストから音声生成
音響イベント分類	音の種類に効く特徴	音楽、会話、環境音などの分類
検索	音声全体の意味ベクトル	類似音声検索、マルチモーダルRAG

前にSentence Transformers v5.4のマルチモーダルEmbeddingを見たときも、音声を同じ encode() に渡す設計は出てきた。
あれは「入力をベクトルにするモデル/API」の話で、今回のNIIデータセットは「その入力候補になる音声資源」の話だ。
レイヤーが違う。

TTSは作れるが、TTS用にそのまま食わせるものではない

48,000時間という量だけを見ると、TTSモデルをそのまま作れそうに見える。
ただ、TTSで欲しいデータは単なる音声量ではない。

TTS学習では、テキストと音声の対応が要る。
さらに日本語では読み、アクセント、数字や記号の読み替え、話者ID、収録品質、無音区間、BGM混入、複数人会話の分離が効いてくる。
ポッドキャストやアーカイブ音源を集めただけでは、このあたりが揃わない。

たとえば MioTTS は、音声をコンテンツトークンとグローバル埋め込みに分けるコーデックを作り、その上でLLMベースTTSを学習していた。
sarashina2.2-tts も、参照音声から音声トークン、ゼロショット埋め込み、音響特徴を取り出して条件づける。
TTSモデルを作るには、データセットの手前に音声処理パイプラインがかなり挟まる。

今回のデータセットは、その材料を増やすものだ。
ASR（Automatic Speech Recognition、音声認識）で文字起こしを作り、VAD（Voice Activity Detection、発話区間検出）で人の声だけを切り出し、話者分離で複数人を分け、品質フィルタでBGMやノイズを落とす。
そこまでやって、ようやくTTSや音声対話モデルの学習に入りやすくなる。

LLM-jp-Moshiの改善材料

NIIは今回のデータを LLM-jp-Moshi の改善に利用すると書いている。
LLM-jp-Moshi は、日本語の同時双方向音声対話モデルで、英語の7B full-duplex音声対話モデル Moshi をベースに、日本語音声対話データで追加学習したものだ。

同時双方向というのは、ユーザーが話している途中でモデル側も聞きながら応答を出すタイプの音声対話を指す。
通常の「音声認識して、LLMに投げて、TTSで読み上げる」直列パイプラインより、ターンテイキングや割り込みがモデル設計に入りやすい。

このブログで前に書いた音声API調査は、STT、LLM、TTSをどう組み合わせるかというアプリ側の視点だった。
LLM-jp-Moshiはもっと下の層で、音声対話そのものをモデルとして学習する方向にある。
そこでは、きれいな朗読音声だけでなく、会話、間、相づち、非言語的な人声、雑音混じりの実環境音も効いてくる。

NIIのリリースでWhisper-ATの分類に出てくる Grunt は、うなり声や息継ぎのような非言語的人声のカテゴリだ。
こういう成分はTTS単体では邪魔に見えることもあるが、音声対話モデルでは「人間の会話っぽさ」に関わってくる。

Archive.org側は音楽と環境音も多い

CC Audioは Common Crawl 2025-18 スナップショットのRSSフィードから抽出した音声URL・メタデータ・ダウンローダーで、日本語だけに絞ると約24,000時間。
ポッドキャスト音声が多く、英語、スペイン語、ドイツ語、日本語など上位20言語以上を含む。

Archive.org Audio Datasetも約24,000時間だが、こちらは日本語のみを対象としている。
ただし中身は話し声だけではない。
NIIの発表では、音楽が約50%、話し声が約7%、ほかに動物の鳴き声や乗り物の音なども含むとされている。

TTSだけを期待すると、Archive.org側の音楽や環境音は遠回りに見える。
でも音声AI全体では、音楽、環境音、非言語的人声を分けて認識する能力も要る。
動画生成AIや音声付き映像生成でも、台詞だけでなく環境音や効果音を同時に扱う方向に進んでいて、MOVAの映像・音声同時生成で見た問題ともつながる。

実際に何が入っているか

CC Audioの各エントリには音声URL、タイトル、説明文、言語コード、ソースページURLが入っている。
加えてWhisperによる書き起こしセグメント（開始・終了時刻とテキスト）も含まれるので、音声とテキストの対応がある程度ついた状態で配られている。
日本語のエントリは約56,700件。

日本語サンプルのWhisper-AT分類を見ると、None（分類不能）44.1%、Music 17.9%、Speech 14.5%、Grunt 13.3%、Animal 4.9%と続く。
Speechが14.5%しかないのは、ポッドキャストでもBGMやジングル、無音区間のセグメントが多いからだ。
Grunt 13.3%は息継ぎや相づち、うなりのような非言語的人声で、Speechよりわずかに少ない程度ある。

Archive.org側は約245,000件で、identifier、タイトル、説明文、言語がメタデータに入る。
CC Audioと違ってWhisperの書き起こしは含まれない。

Archive.orgの日本語音声をダウンロード数で並べると、ゲームサウンドトラック（AKIRA、ファイナルファンタジーX/XIII、ペルソナ4/5、スーパーマリオギャラクシー）、アニメサウンドトラック（うる星やつら、ウルトラマン）、LibriVoxの朗読（百人一首、奥の細道、夏目漱石「こころ」、太宰治「グッド・バイ」）、日本語教材（みんなの日本語）、Vocaloid楽曲集、琴の古典音楽録音あたりが上位に並ぶ。
ゲームやアニメのサウンドトラックの層が厚く、前のセクションで見たMusic 50%の内訳に納得がいく。
Speech 7%は朗読と語学教材が中心で、日常会話の生録音はほぼない。

Whisper-ATが使うAudioSetの分類体系自体は527カテゴリある。
人の声だけで男性・女性・子ども・ささやき・叫び・笑い・泣きに分かれ、楽器は弦・鍵盤・打・管から個別楽器名まで、動物は犬猫から鳥・カエルまで細かい。
ただし今回のデータセットで使われているのは上位の大分類（Music、Speech、Grunt、Animal、Vehicle程度）で、527カテゴリすべてにタグが付いているわけではない。

Archive.orgの実際のエントリを identifier 付きで見ると、データセットの中身がもう少し具体的になる。
identifier は https://archive.org/details/{identifier} で元ページに飛べるIDだ。

identifier	内容	DL数
65-dai-18-ka-mondai-2	みんなの日本語 I 第2版 音声CD	355K
hyakunin_isshu_librivox	百人一首 朗読（LibriVox）	226K
oku_no_hosomichi_librivox	奥の細道 朗読（LibriVox）	197K
furusato_1308_librivox	ふるさと 朗読（島崎藤村、LibriVox）	129K
AKIRAOriginalSoundtrack	AKIRA サウンドトラック	120K
hikibiki_podcast	ひいきびいき Podcast	117K
25_20200430	JLPT N4 文型・例文	99K
john_22	日本語聖書 旧新約 MP3朗読	82K
kokoro_natsume_um_librivox	こころ 朗読（夏目漱石、LibriVox）	81K
meian_1403_librivox	明暗 朗読（夏目漱石、LibriVox）	79K
smap-singles	SMAP シングル全集	63K
flying-beagle	Flying Beagle（菊池ひみこ）	53K
final-fantasy-x-original-soundtrack	FF X サウンドトラック	52K

語学教材とLibriVox朗読がDL数で上位を占める。
クリアな単独話者の発話が多く、ASRやTTS素材としては最も扱いやすい層だ。
サントラやJ-POPは件数の厚みでMusic 50%を構成しているが、音声モデル用途では前処理が重い。

CC Audio側の1エントリは、ポッドキャストのメタデータにWhisperの書き起こしがセグメント単位で付いた構造になっている。

{
  "audio_url": "https://example.com/podcast/ep42.mp3",
  "title": "テック雑談 ep.42",
  "description": "LLMの最近の動向について",
  "language": "ja",
  "page_url": "https://example.com/podcast/ep42",
  "transcript_segments": [
    {"start": 0.0, "end": 10.5, "text": "こんにちは、テック雑談の42回目です"},
    {"start": 10.5, "end": 22.3, "text": "今日はLLMの話をしようと思います"}
  ],
  "transcript": "こんにちは、テック雑談の42回目です。今日はLLMの話をしようと思います..."
}

transcript_segments にセグメントごとの開始・終了秒数があるので、音声とテキストの時間的な対応が取れる。
ただしWhisperの自動書き起こしなので、固有名詞の誤変換やBGM区間への幻覚テキスト生成は混じる。

研究用の大きな索引として見る

この公開で手元に即TTS APIが生えるわけではない。
でも、日本語音声・音響データのURL索引としてはかなり大きい。

大規模音声モデルの学習量を見ると、数万時間はもう巨大すぎる数字ではない。
NIIらの「Common Crawlを用いた大規模音声音響データセットの構築」では、Whisperが68万時間、Moshiが700万時間、Kimi-Audioが1300万時間以上のデータで学習されている例が挙げられている。
日本語で48,000時間にアクセスできるという話は、それ単体で世界最大級というより、日本語で足りない部分を埋めるための現実的な足場に近い。

個人がそのまま全部落として学習するには、容量、回線、利用条件、クリーニング、計算資源が重い。
研究室や企業が、日本語音声認識、音声対話、音響イベント分類、音声Embedding、TTSの前処理済みコーパス作成に使うための入口として見るのが自然だ。

参考

• NIIニュースリリース「WebクロールとWebアーカイブに基づく大規模音声・音響データセットの一般公開」
• CC Audio
• Archive.org Audio Dataset
• LLM-jp-Moshi
• Common Crawlを用いた大規模音声音響データセットの構築