M3 Macで12秒：EmbeddingGemma転用によるローカルSTTの速度と精度のトレードオフ分析

はじめに：LLMアーキテクチャの多様化とローカルSTTの再評価

大規模言語モデル（LLM）の設計思想は、テキスト生成という単一タスクに限定されつつあるかのように見えて、実際には急速に多様化している。テキスト間の意味的類似度を埋め空間（embedding space）上で表現するモデルや、音声特徴量とのマッピングを推論パイプラインに組み込むモデルなど、本来の用途を超えた「転用」が技術的に検討されつつある。

音声認識（Speech-to-Text, STT）の分野では、従来、高精度な処理には専用モデルやクラウドAPIへの依存が前提だった。しかし、Apple Silicon（M3以降）に搭載されたNeural EngineとCore MLフレームワークの組み合わせにより、汎用クライアントデバイス上でも実用的な処理速度が得られるケースがある。この変化は、STTの「どこで動かすか」という設計判断に影響を与えている。

本記事では、EmbeddingGemma 2をSTTモデルに転用した実証プロジェクト（Embedding Gemma Transcribe）のデータを中心に、速度・精度・コストのトレードオフを検証する。M3 MacBook Air（8GB）という制約の厳しい環境で1時間分の音声処理に約12.6秒しか要しないという結果（E1）は、ローカル推論が「選択肢の一つ」になり得ることを示唆している。

読者は、自社のプライバシー要件やインフラコストの制約を踏まえ、クラウド依存からローカル推論への移行を判断する際の具体的材料を得られることを想定している。

技術的前提：EmbeddingGemmaの転用メカニズムと制約

EmbeddingGemmaは、本来テキスト間の類似度を埋め空間上で計算するために学習されたモデルである。入力テキストを固定次元のベクトルに変換し、そのベクトル間の距離や内積で意味的接近度を測る、という用途が設計の中心にある。

転用の本質：ファインチューニングではない

このモデルをSTTタスクに適用する際のポイントは、モデルの重みをゼロから学習し直すファインチューニングではなく、推論パイプライン側の変更（音声特徴量の抽出方法、プロンプトの設計、出力の解釈方法）によって既存の表現力を「活用」する点にある。つまり、モデル自体の学習済み知識が音声認識の性能上限を決定づける要因の一つとなる。

この設計判断にはトレードオフが内在している。音声固有の音素（フォネム）レベルの識別能力は、本来の言語理解能力に依存する。例えば、英語の「night」と「knight」のような同音異義語の区別は、文脈に基づく推論に頼らざるを得ない。専門用語が密集する医療・法務ドメインや、話者が早口で文脈依存度の高い会話を続ける場面では、この限界が顕在化する可能性がある。

精度評価におけるアーキテクチャ的制約

転用モデルの精度を評価する際は、この「本来の用途からの乖離度」を常に意識する必要がある。専用STTモデルが音声信号のスペクトル特徴から直接文字列をデコードするのに対し、EmbeddingGemma転用モデルは「音声特徴量→埋め空間→テキスト」という二段階の変換を伴う。各段階で生じる情報損失の累積が、最終的な単語誤り率（WER）に反映される構造になっている。

この理解がないまま「汎用LLMだから何でもできる」と過剰期待すると、ドメイン固有の精度要件を満たせない場合に後で設計をやり直すコストが発生する。導入前に、自社のユースケースで許容できるWERの閾値を定義し、それを転用モデルの特性と照合することが最初のステップとなる。

パフォーマンス検証：M3 MacBook Airでの処理速度ベンチマーク

速度面での検証結果を、M3 MacBook Air（8GBメモリ）という汎用クライアントデバイス上で確認する。この環境は、企業内のノートPCとして普及しているクラスの一つであり、ここで得られる数値は導入判断の参考になる。

実測データとリアルタイム係数

Embedding Gemma Transcribeは、1時間（3,600秒）分の音声データを約12.6秒で処理した（実証プロジェクトのベンチマーク）。これをリアルタイム係数（RTFx）に換算すると、3,600 ÷ 12.6 ≒ 285倍となる。すなわち、リアルタイムの約285倍の速度で音声認識が実行されている計算だ。

比較対象として、IBM Granite Speech 5.0 TurboCTCを同環境で実行すると、1時間あたり約25.7秒を要する。RTFx換算では 3,600 ÷ 25.7 ≒ 140倍であり、EmbeddingGemma転用モデルが約2.0倍の速度優位性を持つ。

モデル	1時間音声の処理時間	RTFx（概算）
Embedding Gemma Transcribe	約12.6秒	≒285倍
IBM Granite Speech 5.0 TurboCTC	約25.7秒	≒140倍

なお、両モデルともM3 MacBook Air（8GB）という同一環境での測定であり、メモリ容量やGPUコア数の差による影響が排除されている。これにより、速度差がモデルアーキテクチャ自体の特性に起因していることが読み取れる。

速度差が設計判断に与える影響

約2倍の速度差は、単なる「少し速い」にとどまらない。具体的には、以下のようなユースケースで選定要因となる。

会議議事録の即時生成：1時間分の会議録をリアルタイムで文字起こしし、会議終了直後にテキストを共有したい場合、12.6秒 vs 25.7秒の差は「即座に使えるか、30秒待つか」の体験差になる。
バッチ処理のスループット：1日間に100本（合計100時間）の音声ファイルを処理する場合、EmbeddingGemma転用モデルでは約21分、Graniteでは約43分を要する。サーバーの稼働時間や電力コストに直結する。
ストリーミング推論の余地：バッチ処理ですら285倍のRTFxがある場合、ストリーミング（チャンク分割）モードに移行した際のレイテンシ余裕が大幅に確保される。

ただし、速度の優位性は環境に依存する点に注意が必要である。M3 MacBook Airはメモリ8GBという制約下であり、モデルがメモリに完全に載る前提での数値である。より大規模なモデルや、メモリ圧迫が発生する環境では、スワップによる性能劣化が生じ得る。導入前にターゲットデバイスのメモリ容量とモデルサイズの関係を確認するべきである。

精度分析：WER数値が示す実務適用の限界と可能性

Embedding Gemma TranscribeのWERは約5%である（eg2.haku.shのベンチマーク記事）。最先端の専用STTモデルがLibriSpeech test-cleanで2%台前半を記録するのに対し、2〜3ポイントの差がある。ただし、この比較には評価条件の不一致がある。Embedding Gemma Transcribeの5%は一般的な会話文を対象とした数値であり、LibriSpeechのような読み上げ音声とはノイズ特性・話者多様性が異なる。実環境の複数話者・背景音条件下では、専用モデル側もtest-otherで4%台に劣化するため、実際の差は2〜3ポイント程度に縮まる可能性がある。

FluidAudioの公開ベンチマーク（FluidAudio Benchmarks）では、Parakeet TDT v3がtest-clean 2.27%・test-other 4.12%、Phonon-2がtest-clean 2.47%・test-other 4.62%を記録している。test-cleanとtest-otherの差（約1.8〜2.1ポイント）は、話者・アクセント・ノイズの多様性に対する頑健性の限界を示す。Embedding Gemma Transcribeの5%がtest-other相当の条件で得られた値であれば、専用モデルとの実効差は0.5〜1ポイント程度に収まる。

設計判断の観点では、WER 5%が実務的に許容できるかをユースケースで分けるべきである。会議議事録のドラフト生成や、人間が最終校正を行うワークフローでは、5%は実用的な範囲内である。一方、医療・法務・金融など文脈の誤りが重大なドメインでは、1%の差が判断を分ける。後処理による補完——辞書ベースの正誤修正や、文脈付きのLLMによるリファイナリー——を組み合わせることで実効WERを下げられるが、これは追加のレイテンシと推論コストを伴う。精度要件が明確な場合は、後処理パイプラインの設計を初期段階で決めておくことが重要である。

モデル	test-clean WER	test-other WER	備考
Embedding Gemma Transcribe	約5%（会話文）	—	一般的な会話文ベース
Parakeet TDT v3	2.27%	4.12%	LibriSpeech
Phonon-2	2.47%	4.62%	Parakeet v3微調整版
Parakeet Unified（バッチ）	2.15%（平均）	—	LibriSpeech全体平均

ハードウェア最適化：Apple SiliconとNeural Engineの効果

EmbeddingGemma転用モデルがM3 MacBook Airで12.6秒を達成する背景には、Core ML経由でのApple Neural Engine（ANE）活用がある。ANEはCPU・GPUと並列に動作する専用アクセラレータであり、行列演算や非線形変換を低消費電力で処理する。モデルの各レイヤーがANEに完全にオフロードされるか、一部がCPUにフォールバックするかで、実効スループットが大幅に変動する。Core MLのコンパイル時にANE対応演算子のカバレッジが不足すると、想定外のCPUフォールバックが発生し、性能が設計値から乖離するケースが報告されている。

FluidAudioのベンチマークでは、ハードウェア世代による性能差が明確に現れる。Parakeet TDT v3はM4 Pro Macで156倍のリアルタイム処理速度（RTFx）を記録し（eg2.haku.shのベンチマーク記事）、Phonon-2はM5 Pro Macで480倍を達成している（同記事）。M4 ProからM5 Proへの進化で約3倍の性能向上が見られるのは、ANEのコア数増加とメモリ帯域の拡大が主因と考えられる。この差は、同一モデルでもデバイス世代によって「実用的か否か」が分かれることを意味する。M3世代で快適に動作する処理が、M1世代ではスラッシングにより数倍劣化する可能性を、設計段階で織り込む必要がある。

導入判断における核心的リスクは、ハードウェア依存性である。最低限の動作保証デバイスと、最適性能を発揮する目標デバイスの2軸で要件を定義し、その間の性能グラデーションを許容する設計にするべきである。特にメモリ容量はボトルネックになりやすく、モデルサイズとRAMの比率を事前に検証しておくことが望ましい。8GBのM3 MacBook Airで動作確認したモデルが、16GBのM4 ProではANEへの完全オフロードが可能になり、逆にメモリ帯域の差で速度がさらに向上する——このような非線形な性能変化を、単一のベンチマーク値で代表させないことが、実務的なハードウェア選定の要点である。

アーキテクチャ比較：バッチ処理とユニファイドモードの選択

FluidAudioのParakeet Unifiedバッチモードは、LibriSpeechで平均WER 2.15%、全体RTFx 123.3倍を示している（FluidAudio Benchmarks）。これは音声エンコーディングとテキストデコーディングを単一モデル内に統合したアーキテクチャの成果であり、パイプラインの中間ステップ（特徴量抽出→エンコーダ→デコーダ）を削減することで、メモリ転送と推論ラウンドトリップのオーバーヘッドを削減している。分離型アーキテクチャでは各ステージ間の中間データがメモリを往復するが、ユニファイドモデルでは内部状態を保持したまま一気通貫で処理するため、スループットが向上する。

EmbeddingGemma転用モデルとの比較では、精度では専用STTモデルが明確に優位（WER 2.15% vs 約5%）である。しかし速度面では、EmbeddingGemma転用モデルがM3 MacBook Airで約285倍RTFxを達成しており、Parakeet Unifiedの123.3倍を上回る。これはモデルサイズやアーキテクチャの軽量化が速度に寄与した結果と考えられる。つまり、「精度と速度のトレードオフ」ではなく、「精度で専用モデル、速度で転用モデル」という棲み分けが成立し得る。導入判断では、どちらか一方の指標でモデルを選定するのではなく、許容WERと許容レイテンシの2軸で候補を絞り込むべきである。

モード選択はワークフローに依存する。リアルタイム翻訳や音声アシスタントではストリーミングモード（チャンク分割）が必須であり、レイテンシが第一優先となる。大量の音声データを一括処理する（例：過去の会議録のテキスト化）場合はバッチモードが効率的であり、メモリ使用量とスループットの最適化が設計の焦点になる。単発のファイル変換であれば、モードの区別なくバッチ処理で問題ない。設計時に重要なのは、モード固定ではなく、入力データ量やレイテンシ要件に応じて動的にモードを切り替える仕組みを備えることである。特にストリーミングモードでは、チャンク境界での文脈断絶が精度劣化の原因になるため、オーバーラップチャンクや文脈ウィンドウの設計が精度維持の鍵となる。

flowchart TD
    A["処理要件の定義"] --> B{"リアルタイム出力が必要か"}
    B -->|Yes| C["ストリーミングモード（チャンク分割）"]
    B -->|No| D{"大量データ処理か"}
    D -->|Yes| E["バッチモード（ユニファイド）"]
    D -->|No| F["単発バッチ処理"]

実装と運用：ローカル推論パイプラインの構築手順

ローカルSTTパイプラインを構築する際、最初に直面するのはモデルのロードオーバーヘッドである。FluidAudioの公開ベンチマークによると、iPhone 16 Pro MaxでのCore MLモデルロード時にEncoderのウォームスタート時間が162.05msを要する。この値は「ウォームスタート」であり、コールドスタート（プロセスが完全に停止している状態からの起動）ではさらに時間がかかる。M3 MacBook Airのようなデスクトップ環境でも、メモリ圧縮やスワップが発生すると初回推論のレイテンシが数秒単位で跳ね上がる場合がある。

このオーバーヘッドを運用上許容するためには、以下の対策が有効である。第一に、推論プロセスを常駐化し、アイドル状態でもモデルをメモリに保持しておくこと。第二に、ウォームアップ用のダミー推論を定期実行し、Neural Engineのアクティブ状態を維持すること。第三に、APIゲートウェイ層でリクエストキューを設け、モデルロード中のリクエストをバッファリングすること。特にKubernetes環境でデプロイする場合、Podのスケールアウト時にコールドスタートが集中するため、プレウォーム用のInit Containerを設ける設計が現実的である。

推論エンジンとの連携では、音声ファイルのプリプロセッシングが精度に直接影響する。具体的には、サンプリングレートの統一（モデルが想定するレート、例えば16kHzへのリサンプリング）、ノイズ除去（スペクトラル減算やWienerフィルタ）、ラウドネスの正規化が必須である。これらを推論エンジン内部に組み込むのではなく、独立した前処理パイプラインとして分離することで、モデル更新時に前処理ロジックを固定でき、再現性が高まる。

Apple Silicon環境以外での運用については、同等のパフォーマンスを得るにはGPUアクセラレーションが事実上の必須要件となる。ONNX RuntimeのCUDAバックエンドや、Triton Inference ServerのGPUデプロイが選択肢となるが、Neural Engineのような専用ハードウェアがない環境では、同モデルでも処理速度が数分の一に低下する可能性がある。導入前にターゲットハードウェアでのスモークテストを必ず実施すべきである。

sequenceDiagram
    participant C as クライアント
    participant P as 前処理パイプライン
    participant M as 推論エンジン
    participant O as 後処理
    C->>P: 音声ファイル送信
    P->>P: リサンプリング・ノイズ除去
    P->>M: 特徴量ベクトル送信
    M->>M: モデル推論（Neural Engine）
    M->>O: 生テキスト出力
    O->>O: 文脈補完・フォーマット整形
    O->>C: 最終テキスト返却

設計判断：クラウドAPI vs ローカル推論のトレードオフ

クラウドSTT APIとローカル推論の選択は、単に「どちらが速いか」ではなく、組織のデータガバナンス要件とコスト構造を複合的に評価する設計判断である。クラウドAPIは最先端モデルのWER 2〜3%という高精度と、スケールアウトによる可用性を標準で提供する。一方で、音声データを外部ネットワーク経由で送信する行為自体が、コンプライアンス上問題になるケースが少なくない。

ローカル推論の最大の利点は、データが組織のネットワーク内から出ないことである。EmbeddingGemma転用モデルのWERが約5%であるという精度の限界（実証記事）は、この利点と引き換えに許容すべきコストである。また、ハードウェア購入後のマージナルコストがほぼゼロになる点は、大量の音声データを継続的に処理する運用において、クラウドAPIの従量課金モデルと明確に差別化する。

観点	クラウドSTT API	ローカル推論（EmbeddingGemma転用）
WER（精度）	2〜3%（最先端モデル）	約5%
データプライバシー	外部送信あり	組織内完結
レイテンシ	ネットワークRTT依存	ローカル（数秒以内）
運用コスト	従量課金（継続発生）	HW購入後のマージナルコストほぼゼロ
スケーラビリティ	クラウド側で自動	自社HW追加が必要

実務では、この二択を避け、ハイブリッド構成を採用するケースが増えている。具体的には、対外的な議事録や顧客対応ログなど「正確さが最優先」のデータにはクラウドAPIを、内部ミーティングや研究開発の音源など「機密性が高い」データにはローカルモデルを割り当てる。この二重構造をAPIゲートウェイのルーティングポリシーで制御すれば、アプリケーション層は統一的なインターフェースで両者を呼び出せるため、モデル切替時の影響が最小限に抑えられる。

GDPRや国内の個人情報保護法を視野に入れる場合、音声データが「個人データ」に該当するかどうかの判定が先行課題となる。話者識別可能な音声は原則として個人データ扱いとなり、ローカル処理が「データ送信の回避」として有効な制御手段になる。設計判断では、精度の絶対値よりも「どのデータをどこで処理するか」というデータ分類が先行し、その後にモデル選定を行う順序を推奨する。

将来展望：マルチモーダルLLMの進化とSTTの統合

EmbeddingGemmaのSTT転用が示した本質的な意義は、「タスク特化モデル」ではなく「汎用的な埋め空間を学習したモデル」が、適切なパイプライン設計により多様な推論タスクに応用できることを実証した点にある。これは、単一のモデル重みでテキスト生成・音声認識・埋め込み計算を兼用する「ユニバーサルモデル」への道筋を示唆している。

この潮流は、音声認識の出力が「文字列」から「構造化された意味表現」へと進化していくことを意味する。将来的には、推論の副産物として話者識別（誰が話しているか）、感情分析（話者のトーンや意図）、話者変換タイミングの検出などが同時に出力され、単一の推論パスで会議の構造化要約まで生成できる可能性が視野に入る。EmbeddingGemmaが本来持つ埋め込み空間の特性は、こうした付加情報の推論に天然の適合性を持っている。

ハードウェア面では、Apple Siliconの世代交代がローカル推論の性能上限を継続的に押し上げている。M4 Pro MacでのParakeet TDT v3の156倍RTFx（実証記事）から、M5 Pro MacでのPhonon-2の480倍RTFx（同）への飛躍は、単なるクロック速度の向上ではなく、Neural Engineの演算能力とユニファイドメモリ帯域の拡大が複合的に寄与した結果である。この傾向が続けば、3〜5年以内に現在のクラウドAPIと遜色ない精度・速度のローカルモデルがクライアントデバイス上で動作する可能性が高い。

技術責任者が取るべき姿勢は、特定のモデルやハードウェアにアーキテクチャを固定せず、モデル交換・HWアップグレードを前提とした抽象化レイヤーを設計することである。具体的には、推論エンジンのインターフェースを統一し（例：ONNX RuntimeのExecution Provider切替、Core MLのモデルファイル差し替え）、モデル更新時にアプリケーションコードの変更が不要になるようにすること。これにより、将来のマルチモーダルモデルが登場した際にも、既存パイプラインの拡張のみで対応できる体制が整う。

まとめ：ローカルSTT導入のための実践的なチェックリスト

本記事で検証したEmbeddingGemma転用モデルは、M3 MacBook Air (8GB) で1時間分の音声を約12.6秒で処理し、IBM Granite Speech 5.0 TurboCTC（同環境で約25.7秒）に対して約2倍の速度優位性を示した。一方で、WER約5%という精度は、最先端STTモデルの2〜3%と比較して明確なギャップがある。このトレードオフを正しく理解した上で導入判断を行うことが、失敗を避けるための第一歩である。

導入を検討する際は、以下の観点で評価する。

精度の許容ラインを数値で定義する：WER 5%が許容できるユースケース（人間による校正を伴う議事録生成、内部メモのテキスト化）と、許容できないユースケース（法的文書、医療記録）を事前に区別する。許容ラインを超える場合はクラウドAPIまたはファインチューニングを併用する。
ターゲットハードウェアのNeural Engine性能を確認する：M3/M4/M5世代で性能差が数倍に及ぶため、導入デバイスのチップ世代を最低要件として明記する。Neural Engine非対応環境では、同等の速度は期待できない。
コールドスタート対策を設計に組み込む：ウォームスタート162ms（iPhone 16 Pro MaxのEncoder）が実測値である以上、コールドスタート時のレイテンシをSLAに含めた設計が必要。常駐プロセス化やウォームアップ処理を実装する。
クラウドAPIとのハイブリッド構成を最初から想定する：「ローカルだけ」ではなく「ローカル＋クラウド」の二重構造を前提にAPIインターフェースを設計すれば、精度要件の変化やモデル更新時にアーキテクチャ変更が不要になる。
ドメイン固有のデータで精度検証を行う：LibriSpeechのような汎用データセット上のWERは参考値に過ぎない。自社の音声データ（専門用語、特定の話者、ノイズ環境）でPoCを実施し、実務での実効WERを測定する。

ローカルSTTは「クラウドの代替」ではなく「クラウドを補完する選択肢」である。精度・速度・プライバシー・コストの四つを軸に、組織の要件に最も適合する構成を選ぶことが、実務での有用性を最大化する設計判断となる。

参考

本記事は海外の技術トレンド「We turned EmbeddingGemma 2 into a speech-to-text model」（Hacker News）で話題のテーマをもとに、両儀システムソリューションズが独自に解説したものです。