Apple が発表した新たな音声分析 API「SpeechAnalyzer」のベンチマークテストで、Whisper とその前代モデルと比較

2026/07/14 1:06

Apple が発表した新たな音声分析 API「SpeechAnalyzer」のベンチマークテストで、Whisper とその前代モデルと比較

RSS: https://news.ycombinator.com/rss

要約

Japanese Translation:

Apple の新しい SpeechAnalyzer API は、次期 OS 26 の一部として提供されるもので、英語の読み上げ音声に対する優れたオンデバイス音声認識を実現しており、特定ベンチマークコンテキスト内では従来のツールや人気が高い Whisper モデル(Tiny, Base, Small)を大幅に上回っています。この優位性は、M2 Pro チップなどの Apple ハードウェアで行われた厳密なローカルベンチマークを通じて証明され、オーディオを外部サーバーにアップロードすることなく、高速な処理速度——Whisper Small の計算時間の約 1/3——を実現することが示されました。清潔な LibriSpeech テストデータに対しては、従来の SFSpeechRecognizer API に比べて単語誤りを約 4 倍削減し(2.12% WER から 9.02%)、ノイズのあるデータに対しても同様の劇的な改善が見られました。この研究では、Inscribe のプロダクションコードパスと同一のテストハルネスを用い、Whisper の測定値は OpenAI が公開した値と比較しましたが、Whisper の相対的な不正確さは、これらのベンチマーク(アクセントのある音声、遠距離音声、または複数話者シナリオを含まない)に限定されたもの임을 指摘しました。重要なのは、すべてのテストが完全にオンデバイスで行われたことであり、従来の SFSpeechRecognizer もローカルで使用される場合でもクラウド処理にデフォルトで切り替わるという点です。これらの結果に基づき、Inscribe は製品ロジックを更新し、対応言語(現在約 30 のロケール)では SpeechAnalyzer を優先し、未対応の言語のみを Whisper に切り替えました。さらに、研究チームは Inscribe が SpeechAnalyzer でオーディオファイルを取り扱う際に重大なバグを見出し、生テキストデータを検証のために公開ダウンロード可能とする措置を講じました。これは、Apple エコシステム内のプライバシー重視かつ高パフォーマンスなオンデバイス AI 機能において大きな飛躍を意味します。

本文

Apple SpeechAnalyzer: オンデバイス音声認識の新たな基準

Apple の新しいSpeechAnalyzerは、我々のテストにおけるオンデバイス音声エンジンの中で最も高精度であり、処理速度も卓越しています。主な特徴とベンチマーク結果を整理しました。

主要な性能ハイライト

  • 圧倒的な精度: Clean(クリーン)および Other(ノイズ混入あり)の両テストセットにおいて、配布されているすべての Whisper モデル(Whisper Small 含む)を上回りました。
  • 高速処理: SpeechAnalyzer は Small モデルに比べて約3 倍速く動作します。
  • 旧 API の低性能: 置換対象となった旧 API
    SFSpeechRecognizer
    は、クリーンな音声において精度が最も低く、40MB の軽量モデルである Whisper Tiny よりも劣る結果を示しました。

ベンチマーク結果比較表

エンジンクリーン WERその他 WERモデルサイズ
Apple SpeechAnalyzer (iOS/macOS 26)2.12%4.56%システム統合
Whisper Small (WhisperKit CoreML)3.74%7.95%〜460MB
Whisper Base5.42%12.51%〜140MB
Whisper Tiny7.88%17.04%〜40MB
Apple SFSpeechRecognizer (旧方式)9.02%16.25%システム統合

WER(単語誤り率)について: 数値が小さいほど性能が良いです。エンジンが誤って置換、漏らしたり、発明してしまった単語の割合を表します。

テストデータセット概要

  • LibriSpeech test-clean: 2,620 のクリーンな朗読発話で構成されています。
  • test-other: ノイズ混入がありより困難な 2,939 の発話です。
  • 環境: すべての処理は Apple M2 Pro (32GB) / macOS 26.5.1 で完全にオンデバイスにて実施されました(無償計算資源)。

クリーン音声における WER ランキング

  1. Apple SpeechAnalyzer: 2.12%
  2. Whisper Small: 3.74%
  3. Whisper Base: 5.42%
  4. Whisper Tiny: 7.88%
  5. SFSpeechRecognizer (旧方式): 9.02%

なぜこのベンチマークを実施したのか?

iOS 26 / macOS 26 の登場により、Apple は

SFSpeechRecognizer
を新しい API(
SpeechAnalyzer
SpeechTranscriber
)に置き換えました。しかし、Apple 側からは精度に関する数値は公表されていませんでした。そのため、移行すべきか判断に困る開発者や、比較を試みる方々は推測を余儀なくされていました。

  • Inscribeでの実装経験: Apple の 2 つのエンジンと、3 つの Whisper モデルを実行・配送しています。
  • 公平な比較環境: 異なるマシンやデータではなく、同一のマシン上で同じ音声データに対して、5 つの全エンジンを実行する共通の実践コードパスを通じて比較を行いました。

SFSpeechRecognizer から移行すべきか?

✅ 結論:はい、移行を強く推奨します

明確な事実です。新しい API は、同一の音声データにおいて単語誤り率(WER)を大幅に削減します。

  • クリーン音声:
    9.02%
    2.12%
    (約 4 倍の向上)
  • ノイズ混入音声:
    16.25%
    4.56%
    (約 3.5 倍の向上)

精度と形式の向上

  • 精度: 測定したすべての点で優れており、トレードオフは不要です。
  • 出力品質: 旧方式は荒っぽいテキストでしたが、新 API は句読点を付け、大文字小文字を整えた高品質なテキストを生成します。
    • 具体例:
      SFSpeechRecognizer
      で書き起こされた 1 時間の会議記録に含まれる誤り語数は、
      SpeechAnalyzer
      の場合の約4 倍です。

注記: ご自身のアプリが音声コマンド用途(短時間)のみであれば移行は必須ではありませんが、長時間の音声コンテンツやより正確なテキストが必要な場合は、精度向上のために移行する価値があります。


SpeechAnalyzer と Whisper の比較

SpeechAnalyzer の優位性

  • Whisper Smallを含むすべてのモデルを凌駕しました。
  • 処理速度は Small モデルの方が速いですが(約 3 分の 1)、精度では完全に敗北しました。
  • macOS / iPhone で英語を書き起こす場合、標準搭載のエンジンが最強です。

Whisper の残された利点

Whisper がまだ選ばれる理由は以下の 2 つに限られます:

  1. 言語対応数:
    SpeechTranscriber
    が約 30 の言語をサポートする一方、SpeechAnalyzer は英語特化(推測)。※注記:原文「100 を超える」または「SpeechTranscriber は 30」という文脈から、多言語には WhisperKitCoreML などが必要となる可能性があります。
  2. 環境の汎用性: Apple プラットフォームだけでなく、他の環境(Windows など)でも動作します。

今後の方向性:Inscribe の変更

  • 英語では自動的にSpeechAnalyzerが選択されます。
  • 対応言語がない場合は、Whisper にフォールバックします。
  • デフォルト設定から意図的に外すことは推奨されません(ベンチマーク結果を参照)。

処理速度について

すべてのエンジンはリアルタイム処理能力を大幅に上回ります(M2 Pro で約 12〜40 倍の処理速度)。

  • オンデバイスでの所要時間: 1 時間の音声を書き起こすのに、約 1.5 分〜5 分で済みません。
  • 性能差: SpeechAnalyzer は Small モデルよりも毎秒あたり約 3 倍速く動作し、精度も凌駕しています。

計測テーブル公開について: 現時点では詳細な計時テーブルは非公開とします。WER 測定と同機上で開発タスクを行っていたため、計時データにノイズが含まれる可能性(変動)があるためです。将来的には専用アイドルランの実績に基づく情報を更新いたします。


メソロジーと検証性

ベンチマーク結果への懐疑に対処するための透明性のある設計です。

1. Whisper の数値の再現性

我々は OpenAI が公開した LibriSpeech WER を基準に測定しました。全 6 つのケースにおいて、OpenAI の値とほぼ一致しています(わずかな正のオフセットは、誠実な再現の結果であり、厳格なテキスト正規化や CoreML クアンティゼーションによるものです)。

エンジン / セグメント当社測定値OpenAI 公開値デルタ
Whisper Tiny, test-clean7.88%7.6%+0.28
Whisper Base, test-clean5.42%5.0%+0.42
Whisper Small, test-clean3.74%3.4%+0.34
Whisper Tiny, test-other17.04%16.9%+0.14
Whisper Base, test-other12.51%12.4%+0.11
Whisper Small, test-other7.95%7.6%+0.35
  • Apple の測定も同様のコーパス、正規化器、スコアラーを使用しており、誰でも検証可能です。

2. 生テキストデータの公開

再スコアリングを行うことでご自身で確認いただけます。

  • summary.json
    : すべての測定値(機械可読、3KB)
  • raw-transcripts-apple.json.gz
    : SpeechAnalyzer の発話データ(620KB)
  • raw-transcripts-legacy.json.gz
    : SFSpeechRecognizer の発話データ(620KB)

WER 計算の詳細なルール

  • 同一の実践コードパス: Inscribe ユーザーが入手できる正確なコードでの実行です。
  • テキスト正規化: 大文字・句読点なしの参照データに対し、現代エンジンが出力する句読点や数字を付与します(OpenAI の英語正規izer を模倣)。「誤聴」に対してのみペナルティを与えます。
  • 平均ではなく全体: コーパス全体の WER(総誤り数 ÷ 参照単語総数)を使用するため、短い発話が過大評価されません。
  • 完全なオンデバイス:
    SFSpeechRecognizer
    のデフォルトではクラウド送信が行われますが、我々は明示的にオフライン強制し、クラウド結果を排除しました。
  • 失敗はカウントされる: エンジンが出力しない場合は 100% WER と計算されます(旧方式にて 1 件発生)。

このベンチマークから学んだこと (Inscribe の改善)

このベンチマークにより、

Inscribe
アプリの重大なバグを発見しました。

  • 問題:
    SpeechAnalyzer
    にオーディオを供給し入力ストリームを閉じても、
    finalizeAndFinishThroughEndOfInput()
    を呼び出さなかったため、アナライザーが最終結果を伝達せず、処理が永久に停止していました。
  • 原因: Auto 設定で Whisper が優先されていたため、この不具合が見過ごされていました。
  • 解決: 同日に修正パッチを配信しました。

製品開発の原則: 自社製品を詳細に測定することは、見逃していたバグを見つけるための道を開きます。


制限事項

  • 英語のみ: 基準となる LibriSpeech は英語音声のため、多言語対応については言及できません(WhisperKit で 100 以上の言語に対応は可能)。
  • 使用音源の種類: 朗読音声です。アクセントや複数人での話し声を含む実際の会議録画とは異なる可能性があります。
  • ハードウェア依存: 精度は Apple Silicon 間で共通ですが、速度はチップ性能によって異なります(M2 Pro で測定)。
  • WhisperKit CoreML の仕様: クアンティゼされたオンデバイス変換であり、GPU 実装とは若干異なります(検証表で定量化済み)。

まとめ:何を意味するか?

現在の iPhone または Mac で英語の書き起こしを行いたい場合:

  • Best Choice: オペレーティングシステム内の標準機能(
    SpeechAnalyzer
    )。
  • Privacy: 完全にオンデバイス。何ものもアップロードされません。
  • Inscribe の推奨設定: 英語では
    SpeechAnalyzer
    、多言語では
    Whisper
    を採用します。

ベンチマークは製品を売るための広告ではなく、製品の挙動を決める客観的な基準です。詳細な数値や生データはいつでも公開可能です。

同じ日のほかのニュース

一覧に戻る →

2026/07/14 7:19

『アジア最浄の村』が日曜日観光客禁止に

## Japanese 翻訳: 2026 年 1 月以来、インディアのメガラヤ州にある約 600 人の居住者がいるモーリャン・オン(Mawlynnong)村では、「真の村の生活」を再建する目的として、日曜日の昼間の観光客に対する厳格な禁止措置を導入しています。1902 年に設立された教会が存在し、人口の推定 100% がクリスチャンであるこのコミュニティは、日曜日には単一の道路への入口を黒い金属製のゲートで閉鎖して、 uninterrupted な礼拝を保証しています。以前からほとんどの観光関連事業所が日曜日の営業停止を選択していました(レストランは 2 カ所のみ営業)ましたが、公式な禁止措置により、今では店舗や一日利用施設が完全に閉鎖されるようになっています。一泊予約を持つゲストはこの昼間の旅行禁止からの例外扱いで、ゲストハウスに滞在することができ、一方で地元のレストランや記念品販売店は引き続き閉鎖されています。住民は、村評議会の委員でもあるプリシウス・コングドプ(Precious Khongdup)を含むコミュニティの一致した支持を受けながら、この取り組みを文化のアイデンティティ、精神的なリズム、および 2003 年に「アジアで最も清潔な村」と命名されたり、2014 年にナレンドラ・モディ首相のクリーン・インディア・ミッションキャンペーンの際に全国的な注目を得たりした功績をもたらした規律を保持するために不可欠だと考えています。この決定は、観光客による妨害に対する具体的な懸念に対応しており、観光客が地面にプラスチック製の水ボトルを置き去りにするというバイラル化した事象などが挙げられ、これにより地元からは強い反発が生じていました。言語学の教授ヴィジャヤ・デブナス(Vijaya Debnath)を含む専門家は、このイニシアチブを称賛しており、清潔さを維持しつつ、村民の静かな一日の休息と祈りの必要性にも敬意を表していると評価しています。

2026/07/14 3:22

Xcode を起動することなく Mac および iOS アプリを開発して配送する方法

## Japanese Translation: 本テキストでは、Xcode を一度設定した後の開封を不要とする堅牢で完全にヘッドレスの iOS アプリケーションの作成・デプロイワークフローが概説されています。シェルスクリプトによるライフサイクル全体のアオマティゼーションを通じて、開発者は `xcodebuild` コマンドラインツールを用いてコードをコンパイルし、`notarytool` によってビルドを保護し、`devicectl` を用いて物理デバイスにアプリを直接インストールします。セキュリティは、証明書ベースのキーチェーンおよび外部パスワードマネージャーの活用により維持され、プライベートキーなどの機密情報はバージョン管理システムへの投入を完全に防ぎます。本システムは XcodeGen を用いてプロジェクトを管理し、煩雑なローカルフォルダではなくクリーンな YAML 設定ファイル(`.yml` ファイル)によってプロジェクトを制御し、アドホックテスト版と公式開発者 ID リリースを自動的に区別します。一度設定されたリリーススクリプトは、アーカイブ、署名、認証化、スタプリング、インストールを含む厳格なパイプラインを実行し、沈黙する失敗を防ぐために堅牢なエラー処理(`set -euo pipefail`)を採用します。このアプローチは、チームが手動のマウス操作または GUI ウィンドウなしに、実際に動作するソフトウェアを効率的にデプロイするために安全で再現可能な CI パイプラインを構築することを可能にします。 ## Text to translate: The text outlines a robust, fully headless workflow for creating and deploying iOS applications that eliminates the need to open Xcode after an initial setup. By automating the entire lifecycle through shell scripts, developers utilize command-line tools such as `xcodebuild` to compile code, `notarytool` to secure builds, and `devicectl` to install apps directly onto physical devices. Security is maintained by leveraging certificate-based keychains and external password managers, ensuring sensitive secrets like private keys never enter version control. The system employs XcodeGen to manage projects via clean YAML configurations (`.yml` files) rather than cluttered local folders, automatically distinguishing between ad-hoc testing versions and official Developer ID releases. Once configured, a release script executes a rigorous pipeline involving archiving, signing, notarizing, stapling, and installation, while using strict error handling (`set -euo pipefail`) to prevent silent failures. This approach empowers teams to establish secure, repeatable CI pipelines that deploy real software efficiently without any manual mouse interactions or GUI windows.

2026/07/14 7:03

クルードはただの「ミーズシックス」さんです

## Japanese Translation: 本稿では、`mr-meeseeks` という Claude Code プラグイン(`thephw/claude-meseeks`)を紹介する。このプラグインは、アイドル時間中に「Mr. Meeseeks」の音声クリップを再生し、ワークフローの速度を遅らせずしてユーザーエクスペリエンスを向上させる。非ブロック型のコンパニオンとして機能し、フィルタリングされた `Notification` イベント(および `UserPromptSubmit`)を利用して、「done」「asking」「feedback」といったカテゴリからランダムなクリップをトリガーする一方、背景エージェントの動作や認証の更新など自動的タスク中は無音で保持される。特に重要なのは、音声処理を別プロセスに分離することでプロンプト行がフリーズしないよう防止し、AI が待機中でもレスポンシブなインターフェースを保証することである。設定方法は柔軟であり、プラグインマーケットプレイスからのインストールまたはローカルリポジトリのクローンが可能で、事前構築済み `bin/` ディレクトリのバイナリ検出(自動)またはフォールバックとして `go build` が利用される。音声再生には Linux では特定のプレイヤー(例:`ffmpeg`/`ffplay`、`mpg123`)が必要だが、macOS では追加設定なしでネイティブに動作する。このプラグインは、「Mr. Meeseeks」の理念である「単一タスクを迅速に完了し、その後は『poof』として消える」という哲学に沿っており、長時間継続的なセッションを避けるように設計されている。ユーザーは受動的待機中に魅力的な聴覚体験を得ながら、`enableDone` などの設定フラグや `meeseeks play` といった手動 CLI コマンドを通じて完全な制御を保ち続ける。究極的には、このツールは待ち時間を没入感のある体験に変えつつ、パフォーマンスを損なったり複雑な設定を必要としたりしない。