ローカルで動く日本語STTを作る (1) 仕組みを理解する

1. はじめに

本記事から始まる全4回の連載では、Windows PC上で動く日本語STT（音声認識）アプリを、ローカル環境で一から作っていきます。第1回となる今回は、実装に入る前の準備として「そもそもSTTはどうやって動いているのか」を、初学者向けに丁寧に解説します。

連載の全体像

第1回仕組みを理解する ← 今回
第2回 faster-whisperでハンズオン
第3回リアルタイム化する
第4回精度を上げる

今回のゴールは「Whisperの中で何が起きているかを絵で説明できる」状態になることです。コードはほぼ出てきませんが、第2回以降の理解度がぐっと変わってくる重要な回です。

想定読者は、Pythonの基礎は分かっていて、STTをこれから使ってみたい、仕組みもなんとなく知っておきたい、という方です。それでは始めます。

2. STT（音声認識）とは何か

STTは Speech-to-Text の略で、日本語では「音声認識」と呼ばれます。技術文献では ASR（Automatic Speech Recognition） という呼び方もよく見かけますが、本記事ではSTTで統一します。

一言で言えば、音声を文字に変換する技術です。

マイクなどから入力された音声を、STTエンジンを通すことで、対応するテキストとして出力します。たったこれだけのシンプルな入出力ですが、内部では非常に複雑な処理が行われています。その中身を理解するのが今回の目的です。

STTの使われどころは年々広がっています。代表的なユースケースを見てみましょう。

議事録作成：会議音声を録音して自動文字起こし
字幕生成：動画コンテンツへの字幕付与
音声入力：キーボードの代わりに声で入力
コールセンター文字起こし：顧客対応の音声をテキスト化
音声検索：音声で検索クエリを入力
リアルタイム字幕：配信やオンライン会議の同時字幕

あなたが解きたい課題は、この中にありますか？あるいは別の形でSTTを活用したいケースもあるかもしれません。いずれの場合も、まずはSTTがどう動いているかを知ることがスタートラインになります。

3. 音声認識の仕組み

ここからが本題です。STTが内部でどう動いているのかを、5つのステップに分けて見ていきます。

3-1. 音声データはどう表現されるのか

そもそも、コンピュータは音をどう扱っているのでしょうか。

音は空気の振動です。マイクはこの振動を電気信号に変換し、コンピュータはそれを一定間隔で数値として記録します（これを サンプリング と呼びます）。その結果、音は 時間に沿って並んだ数値の列 として表現されます。

これを波形（waveform）として可視化したのが次の画像です。

これは「こんにちは」と発声した音声の波形です。横軸が時間、縦軸が音の振幅を表しています。

でも、この波形を眺めていても何の音か分からないですよね。実際、人間の目で波形から「こんにちは」と読み取るのはほぼ不可能です。コンピュータも、この生の波形だけを見て音声認識するのは困難です。

そこで、音を 周波数成分に分解 してパターンを見えるようにします。これが スペクトログラム です。

横軸が時間、縦軸が周波数、色の濃淡が強度を表します。「こ・ん・に・ち・は」の各音節に対応する縞模様が見えるはずです。波形だけのときは何も分からなかったのに、周波数で展開すると音の特徴が浮かび上がってきます。

実際のSTTでは、人間の聴覚特性に合わせた メルスペクトログラム という変形を使うのが一般的です。これは「人間は低い周波数の違いには敏感で、高い周波数の違いには鈍感」という特性を反映したスケールです。

最終的に、メルスペクトログラムから 特徴量ベクトルの時系列 が得られ、これがSTTモデルへの入力になります。

ここまでが「音をモデルに入れる前の前処理」です。Whisperを含め、現代の主要なSTTモデルは、入力としてこのメルスペクトログラムを受け取ります。

3-2. 従来型STT：音響モデルと言語モデル

2010年代前半まで、STTは複数の部品を組み合わせて作るのが主流でした。

ざっくり3つの部品で構成されています。

音響モデル：音の特徴量から音素（「あ」「い」「k」など、音の最小単位）を推定する
発音辞書：音素の並びから単語を引く
言語モデル：単語の並びがどれくらい自然か（「私は学校に行く」は自然、「私学校に行くは」は不自然）を判定する

これらをパイプラインのように繋いで、音声をテキストに変換していました。

この方式の問題点は、それぞれの部品を別々に作って調整する必要があったことです。日本語の発音辞書を作り、日本語の言語モデルを学習し、それぞれの精度を上げる職人技が要求されました。専門用語や固有名詞が出てくると辞書を更新する必要があり、運用も大変でした。

そして2017年、Transformerが登場し、状況が一変します。

3-3. End-to-Endの登場

ディープラーニングの発展、特にTransformerアーキテクチャの普及により、1つのニューラルネットワークで音声からテキストまでを直接学習させることが現実的になりました。

これが End-to-Endモデル です。

部品ごとの境目が消え、データさえ十分にあれば、ネットワークが内部で自動的に「音と文字の対応」を学習します。音響モデルも、発音辞書も、言語モデルも、すべてが1つのモデルの中に統合されました。

複雑なパイプラインが、1つの箱に置き換わったのです。

このパラダイムシフトの代表格が、次に紹介する Whisper です。

3-4. Whisperの構造（Encoder-Decoder）

Whisperは、Transformerベースの Encoder-Decoderモデル です。難しそうな名前ですが、構造自体はシンプルです。

入力は30秒チャンクのメルスペクトログラム、出力はテキストトークン列です。中身は大きく2つに分かれています。

エンコーダ：入力された音声特徴量を「意味の埋め込み」と呼ばれる内部表現に圧縮します。音の特徴を、文字にする前段階の抽象的な情報に変換するイメージです。
デコーダ：エンコーダの出力を参照しながら、テキストトークンを1つずつ順番に予測していきます。先に予測したトークンを、次の予測の手がかりにする「自己回帰的」な動きをします。

翻訳の比喩で考えると分かりやすいかもしれません。エンコーダは「日本語を聞き取って要点をメモにまとめる人」、デコーダは「そのメモを見ながら言葉を組み立てる人」、という二人組の協働作業です。

なお、自己回帰生成という仕組み上、Whisperには 無音区間でも勝手に何かを文字起こししてしまう（ハルシネーション）という弱点もあります。この問題は第4回でしっかり扱います。

3-5. VAD（音声区間検出）

仕組みの話の最後に、もう一つ知っておきたい技術があります。VAD（Voice Activity Detection、音声区間検出） です。

VADは、連続音声から「人が発話している区間」だけを取り出す技術です。波形の上の緑の帯が発話部分、グレーの帯が無音部分です。

なぜこれが必要かというと、

長尺音声を効率的に処理するため（無音部分を読み飛ばせる）
リアルタイムSTTで「いつ文字起こしを発火するか」を判定するため

第3回のリアルタイム化では、このVADが主役の一人になります。今は「そういう道具があるんだ」と頭の片隅に入れておいてください。

4. Whisperとは何か

ここまでで仕組みの話は一段落です。連載で実際に使っていく Whisper というモデルについて、もう少し背景を整理しておきます。

Whisperは、OpenAIが2022年9月に公開したオープンソースの音声認識モデルです。特徴を箇条書きでまとめます。

学習データ規模：Web上の68万時間に及ぶ多言語音声で学習
対応言語：99言語（日本語ももちろん含まれます）
強さの源泉：データ量の暴力。多様な話者・録音環境・ノイズ環境を含むため、実世界での頑健性が非常に高い
モデルサイズ：tiny / base / small / medium / largeの5段階。large系は2026年現在v3まで出ています

そして特筆すべきは、Whisperがオープンソースで公開されたことで、派生プロジェクトが続々と登場したことです。

faster-whisper：CTranslate2による高速化版。本連載で採用
whisper.cpp：C++実装で軽量・CPU向き
distil-whisper：蒸留版で軽量
kotoba-whisper：日本語特化のファインチューニング版

なかでも faster-whisper は、純正Whisperの4倍程度の速度を出しつつ、同等以上の精度を保つことで人気を集めています。本連載では、これに日本語特化モデルを組み合わせて使います。

5. 主要STTサービス比較

ここで一度、STTサービスの全体像を整理しましょう。Whisperはあくまで選択肢の1つに過ぎません。

クラウド系・ローカル系を含めた主要サービスを比較表にまとめました。

サービス	種別	料金	日本語精度	レイテンシ	オフライン
Google Cloud Speech-to-Text	クラウド	従量課金	高	低	×
AWS Transcribe	クラウド	従量課金	中	中	×
Azure AI Speech	クラウド	従量課金	高	低	×
OpenAI Whisper API	クラウド	$0.006/分	高	中	×
Deepgram	クラウド	従量課金	中	低	×
Vosk	ローカル	無料	中	低	○
whisper.cpp	ローカル	無料	高	中	○
faster-whisper	ローカル	無料	高	中	○

簡単にコメントしておきます。

クラウド系の強み：セットアップが楽、品質が安定、スケールしやすい
クラウド系の弱み：音声データを外部に送る必要、従量課金で長時間音声はコスト負担、ネット必須
ローカル系の強み：完全オフライン、ランニングコストがほぼゼロ、データを外に出さない
ローカル系の弱み：環境構築の手間、計算リソース（特にGPU）が必要、モデル更新は手動

「とりあえず使ってみたい」だけならクラウドAPIが圧倒的に楽です。ただし本格的に運用する場面では、上記のトレードオフが効いてきます。

これだけ選択肢がある中で、本連載があえて「ローカル」を選ぶ理由を、次に整理します。

6. なぜローカルで動かすのか

本連載がローカル環境を選ぶ理由は、大きく4つあります。

1. プライバシー
音声データを外部に送信する必要がありません。議事録、社内会議、医療記録、法務系のヒアリングなど、機密性の高い用途では大きな利点です。

2. コスト
APIの従量課金が発生しません。長時間の音声（例：1日分の会議録音）でも、電気代を気にする程度で済みます。

3. カスタマイズ性
将来的に、自分のデータでのファインチューニングや、独自辞書の追加など、深く手を入れられる余地があります。クラウドAPIではここまでの自由度は得にくいです。

4. オフライン動作
ネット接続が不要なので、社内ネットワークだけの環境や、ネット環境のない現場でも動かせます。

もちろんローカルにも弱点はあります。初期セットアップの手間、GPUなどのハードウェア投資、モデル更新を自分で追う必要があるなど、楽な選択肢ではありません。それでも上記のメリットを求める用途には、十分以上の価値があります。

ローカルで動かすと決めたら、次は「どのモデルを選ぶか」です。特に日本語に強いモデルを見ていきましょう。

7. 日本語に強いSTTを紹介

「ローカルで動く、日本語に強いSTTモデル」というテーマで、現時点（2026年）の主な選択肢を紹介します。

kotoba-whisper（Kotoba Technologies）
Whisper-large系をベースに、ReazonSpeechという大規模な日本語音声コーパスでファインチューニングしたモデルです。Hugging Faceで公開されており、faster-whisper互換のフォーマットも提供されています。日本語の精度と速度のバランスが非常に良く、現時点で最有力候補です。

ReazonSpeech-NeMo（Reazon Human Interaction Lab）
ReazonSpeechコーパスを公開している研究機関が、NVIDIAのNeMoフレームワーク向けに公開しているモデルです。Whisper系とは異なるアーキテクチャを採用しており、推論速度が速い一方で、扱うのに少し慣れが要ります。

Nue-ASR（rinna）
日本語に特化した軽量モデル。CPUでも動作するため、組み込み用途やオフライン用途に向いています。

Whisper Large-v3（オリジナル）
英語含む多言語に強いオリジナル版。日本語にも十分対応しますが、上記の日本語特化モデルと比べると、固有名詞や口語表現で差が出る場面があります。

選定時に見るべきポイントは、日本語精度、推論速度（GPU性能との相性）、モデルサイズ（VRAM消費）、ライセンス、コミュニティの活発さ、といったあたりです。

本連載では、kotoba-whisper を採用します。 理由は次の3点です。

faster-whisperと組み合わせやすい（同じCTranslate2形式が用意されている）
日本語精度とモデルサイズのバランスが優秀
Hugging Faceで誰でも入手でき、コミュニティの情報も豊富

次回はこのモデルを使って、実際にあなたの声を文字起こししてみます。

8. 次回予告

次回（第2回 faster-whisperでハンズオン）では、いよいよ実際に手を動かします。

Python環境のセットアップ
CUDAおよびGPU動作確認
faster-whisperとkotoba-whisperのインストール
自分の声を録音して文字起こし

お手元のマイクとPython環境を準備してお待ちください。

ここまでが第1回です。お疲れさまでした。Whisperが「だいたいどう動いているか」を絵で説明できる状態になっていれば、第1回のゴールは達成です。次回でいよいよ実装に入ります。