Appleの新しいSpeechフレームワーク: SpeechAnalyzer と SFSpeechRecognizer

iOS 26では、既存のSFSpeechRecognizerと並ぶ形で新しい音声認識フレームワークが導入されました。新しいAPIの中心はSpeechAnalyzerと、その周囲に組み合わせるモジュール（SpeechTranscriber、SpeechDetector）です¹。Apple自身の位置づけでは、SpeechAnalyzerこそが現代的な選択肢です。新しいオンデバイスモデル、長尺音声のサポート、自動的な言語管理、リアルタイム用途に耐える低レイテンシ、そして分析タイプを将来にわたって追加できるモジュラーアーキテクチャを備えています。SFSpeechRecognizerも引き続き提供され、問題なく動作します。とどまる理由として残るのは、古いOSのサポートと、もう一つの狭い差分です。その差分とは、新フレームワークの長尺向けSpeechTranscriberモデルにおけるカスタム語彙のことで、短い発話向けのDictationTranscriberのパスであればcontextual stringsを受け取れます。

この記事では、新旧のフレームワークを突き合わせて見ていきます。切り口は「新しいAPIの使い方」ではなく「いつ移行すべきか」です。SFSpeechRecognizerで動く実装を抱えるチームは、いずれも同じ判断を迫られるからです。新フレームワークの新しいモデルとアーキテクチャは移行コストに見合うのか、それとも既存のカスタム語彙への投資が現状維持を正当化するのか、という判断です。

要点

• SpeechAnalyzer（iOS 26以降）はAppleの現代的なオンデバイス音声認識フレームワークです。初期化時に構成した分析モジュールを統括する役割を持ち、iOS 26では3つのモジュールが提供されます。SpeechTranscriber（長尺向け）、DictationTranscriber（短い発話向けで、SFSpeechRecognizer相当）、SpeechDetector（音声区間検出。トランスクライバーとの併用が必須）です²。
• 新しいフレームワークは長尺音声、つまり講義、会議、複数話者の会話を軸に設計されています。処理はすべてオンデバイスで完結し、ロケールごとのモデルアセットを自動的に扱い、同等の文字起こしタスクでWhisper Large V3 Turboの2倍高速と報告されるApple独自の新モデルを搭載します³。
• SFSpeechRecognizerも引き続き提供され、動作します。そしてカスタム語彙はもはやその専売ではありません。新フレームワークのAnalysisContext.contextualStrings（SpeechAnalyzer.setContext(_:)で設定します）は、DictationTranscriberのパス向けにドメイン固有のフレーズを最大100件まで登録できます⁶。残る差分は、contextual stringsを受け取らない長尺向けのSpeechTranscriberモデルだけです。
• 移行は機能単位で進めるものであり、全か無かではありません。長尺の文字起こし、より低いレイテンシ、遠くから拾った音声の品質を必要とするアプリはSpeechAnalyzerへ移行しましょう。カスタム語彙に投資してきたアプリでも、短い発話のディクテーションはDictationTranscriberとcontextual stringsで移行できます。レガシーAPIを推す理由が残るのは、カスタム語彙を伴う長尺の文字起こしだけです。
• このクラスターのVision frameworkの記事では、Appleのもう一つのオンデバイス知覚プリミティブを扱っています。SpeechAnalyzerは、同じオンデバイスかつクラウド不要のパターンを音声へ広げるものです。

アーキテクチャ: アナライザーとモジュール

SpeechAnalyzerはそれ自体がトランスクライバーではありません。音声分析セッションを管理し、オーディオバッファを1つ以上のモジュールへ振り分けるコーディネーターです²。モジュールはinit(modules:)イニシャライザによって初期化時に構成し、分析はstart(inputSequence:)を通じてAnalyzerInput値（それぞれがオーディオバッファをラップします）のAsyncSequenceを流し込むところから始まります。

import Speech

let transcriber = SpeechTranscriber(
    locale: .current,
    transcriptionOptions: [],
    reportingOptions: [.volatileResults],
    attributeOptions: []
)
let analyzer = SpeechAnalyzer(modules: [transcriber])

try await analyzer.start(inputSequence: audioInputSequence)

for try await result in transcriber.results {
    if result.isFinal {
        print(result.text)
    }
}

iOS 26では3つのモジュールが提供されます。

SpeechTranscriber。 長尺音声（講義、会議、複数話者の会話）向けに設計された音声認識モジュールです。トークンごとのタイミング情報、信頼度スコア、そしてアプリがfor try awaitで消費するresultsのAsyncSequenceとともに、ストリーミング結果を返します。各結果にはisFinalフラグがあり、暫定的な仮説と確定したテキストを区別できます。

DictationTranscriber。 従来のSFSpeechRecognizerのユースケースをそのまま置き換えるモジュールです。短い発話の文字起こしを、SFSpeechRecognizerと同じオンデバイスモデルで行います。短いクエリのためにSFSpeechRecognizerから移行するアプリはDictationTranscriberを、長尺の録音のために新フレームワークを採用するアプリはSpeechTranscriberを選びます。この使い分けが重要なのは、SpeechTranscriberとDictationTranscriberとで対応言語の範囲もモデルの経路も異なるからです。

SpeechDetector。 音声区間検出を担います。オーディオストリームの中で発話が始まった時点と終わった時点をイベントとして報告します。このディテクターは単独では動作せず、同じSpeechAnalyzerインスタンス内でいずれかのトランスクライバーモジュールと組み合わせる必要があります。文字起こしの計算を絞り込む（無音を文字起こししない）用途や、「話してください」といったUIの手がかりを制御する用途に使われます。

このモジュラーアーキテクチャこそが、SFSpeechRecognizerに対する構造上の改善点です。旧APIは設定、バッファの扱い、結果の受け渡しをrecognizerとrequestのペアに集中させ、しかも設定アプリでユーザーが言語を有効にすることに依存していました。新しいAPIはセッションのコーディネーターと分析モジュールを切り離し、必要なものだけをアプリ側で組み合わせられるようにしています。

新しいモデルがもたらすもの

SpeechTranscriberの背後にある文字起こしモデルは、このフレームワークのためにAppleが専用に開発した新しいオンデバイスモデルです⁴。WWDC 2025でAppleが強調した改善点は次のとおりです。

長尺音声の品質。 このモデルは短いクエリだけでなく、数分から数時間にわたる継続的な文字起こしのために訓練されています。講義、ポッドキャスト、複数話者の会議、ディクテーションのセッションが、AppleがWhisperクラスのモデルと並べて位置づけるほどの精度で文字起こしされます。MacStoriesによる独立したテストでは、同等の文字起こしタスクにおいてMacWhisperのLarge V3 Turboビルドよりおよそ2.2倍高速という測定結果が出ています³。

遠くから拾った音声への対応。 部屋の向こうに置かれたマイク、複数の話者がいる会議テーブルの音声、環境ノイズを含む音声。このモデルはそうした条件を想定して訓練されており、SFSpeechRecognizerの古いモデルはこれらをうまく扱えません。

リアルタイムかつ低レイテンシな動作。 SpeechTranscriberから届くストリーミング結果は、旧フレームワークのSFSpeechRecognitionRequest.shouldReportPartialResultsのコールバックよりも速く到着します。ライブの文字起こしを表示するアプリ（字幕、音声駆動のUI、ディクテーション）では、更新がなめらかになります。

自動的な言語管理。 ここでのAppleの位置づけ（Appleの用語ではなく筆者の言い換えです）が指しているのは、モデルとアセットの管理であって、ストリームの途中で言語を切り替えることではありません。OSがAssetInventoryを通じてロケールに応じた適切なモデルアセットをダウンロードしてインストールするため、アプリ側が言語ごとのモデルの有無を手作業で管理する必要はなくなります。トランスクライバーのインスタンスが一度に扱えるロケールが1つである点は旧フレームワークと同じですが、多言語対応を面倒にしていたアセットまわりの配管はシステムの仕事になりました。

アプリサイズへの負担がゼロ。 モデルはアプリではなくOSに同梱されています。SpeechAnalyzerを採用するアプリが追加のモデル重みを同梱する必要はありません。Whisperクラスのモデルをアプリバンドルに載せる場合との差は大きく、競争力のあるオンデバイス文字起こしのスタックがバンドルサイズ0バイトで手に入ります。

旧フレームワークに残る強み

SFSpeechRecognizerはiOS 26でも引き続き提供され、動作します。アプリが使い続ける理由としては次の3つが挙げられます。

長尺音声でのカスタム語彙。 SFSpeechRecognitionRequest.contextualStringsを使うと、既知のキーワード（固有名詞、専門用語、製品名）のリストを登録でき、モデルがそれらをより正確に認識しやすくなります。この機能は、ドメイン固有のアプリ（薬剤名を扱う医療用ディクテーション、判例引用を扱う法務アプリ、部品番号を扱うエンジニアリングアプリ）の精度を大きく引き上げます。新しいフレームワークにも、ディクテーションのパス向けに独自の仕組みが用意されています。AnalysisContext.contextualStringsはタグごとにグループ化したフレーズを最大100件まで受け取り、SpeechAnalyzer.setContext(_:)でアナライザーに設定します。ここに登録したフレーズは、システムの語彙に存在しない場合でも認識できます⁶。さらにDictationTranscriberは、ContentHint.customizedLanguage(modelConfiguration:)というコンテンツヒントを通じてカスタム言語モデルの構成も受け付けます⁷。まだ相当するものがないのは、長尺向けのSpeechTranscriberモデルにおけるcontextual stringsです。つまり長尺の文字起こしでカスタム語彙を必要とするアプリは、そのパスを移行すると機能が後退してしまいます。

古いOSのサポート。 SFSpeechRecognizerはiOS 10以降で利用できますが、SpeechAnalyzerはiOS 26以降を必要とします。iOS 18以前をターゲットにするアプリにはレガシーフレームワークが必要です。

すでに動いている実装。 安定していて、監査済みで、性能も出ているSFSpeechRecognizerの実装を持つアプリに、急いで移行する理由はありません。新フレームワークの改善が最も効くのは新しいユースケース（長尺の文字起こし、遠くから拾った音声、複数話者の会話）であり、レガシーAPIで短い音声クエリを処理しているアプリでは、移行コストに見合うだけの恩恵が得られないかもしれません。

移行すべきタイミング

移行の引き金として挙げるに値するものが3つあります。

アプリが長尺音声を処理している。 会議のレコーダー、講義の文字起こしアプリ、ポッドキャストをテキスト化するツールなどです。継続的な音声で訓練された新しいモデルがぴったり合いますし、古いモデルは長いセッションになるほど精度が落ちます。まずここから移行しましょう。

アプリが遠い音声やノイズの多い音声を必要としている。 会議室の文字起こし、遠くに1本だけマイクを置いたインタビュー録音、環境ノイズのある場所で収録した音声などです。こうした条件では新しいモデルの扱いが目に見えて優れています。

アプリがライブの文字起こしUIを表示している。 字幕のオーバーレイ、ディクテーションのインターフェース、音声で操作する支援UIなどです。SpeechTranscriberのストリーミング結果は低レイテンシなので、UIの反応が良く感じられます。

一方、必ずしも移行を要しないケースもあります。

• カスタム語彙に依存する長尺の文字起こし（薬剤名や判例引用を取りこぼせない会議レコーダーなど）。長尺向けのSpeechTranscriberモデルはcontextual stringsを受け取らないため、Appleがこの差分を埋めるまではSFSpeechRecognizerにとどまります。カスタム語彙を伴う短い音声クエリのほうはきれいに移行できます。DictationTranscriberとAnalysisContext.contextualStringsの組み合わせでカバーできるからです⁶。
• iOS 18以前をサポートする必要があるアプリ。SpeechAnalyzerはiOS 26専用なので、いずれにせよ古いターゲット向けにはレガシーフレームワークがコードベースに必要です。

併存パターン

古いOSバージョンもターゲットにしつつ、iOS 26以降では新フレームワークの品質を活かしたいアプリには、2つを併存させるパターンが適切です。

import Speech

if #available(iOS 26.0, *) {
    let transcriber = DictationTranscriber(locale: .current, preset: .shortDictation)
    let analyzer = SpeechAnalyzer(modules: [transcriber])
    try await analyzer.start(inputSequence: audioInputSequence)
    for try await result in transcriber.results {
        if result.isFinal {
            handleTranscription(result.text)
        }
    }
} else {
    let recognizer = SFSpeechRecognizer(locale: .current)!
    let request = SFSpeechAudioBufferRecognitionRequest()
    request.shouldReportPartialResults = true
    request.requiresOnDeviceRecognition = true
    let task = recognizer.recognitionTask(with: request) { result, error in
        guard let result else { return }
        handleTranscription(result.bestTranscription.formattedString)
    }
}

iOS 26以降の分岐でDictationTranscriberが適切なのは、移行の対象がSFSpeechRecognizerのユースケース（同じディクテーションモデルによる短いクエリ）だからです。長尺音声を狙うアプリは、iOS 26の分岐でDictationTranscriberをSpeechTranscriberに置き換えましょう。

2つのフレームワークは共存でき、実行時のチェックが利用可否に応じて適切なほうを選びます。どちらももう一方を妨げることはなく、アプリの文字起こしパイプラインが状況に適応します。

プライバシーと音声認識の許可まわり

2つのフレームワークは、許可のレイヤーで違いがあります。SFSpeechRecognizerは音声認識専用の許可を必要とし続けます。Info.plistのNSSpeechRecognitionUsageDescriptionと、SFSpeechRecognizer.requestAuthorization(_:)によるプロンプトです⁵。SpeechAnalyzerはその仕組みを使いません。これでライブ音声を文字起こしするアプリにはマイクの許可（NSMicrophoneUsageDescription）が必要ですが、すでに手元にある音声を文字起こしするだけならそれ以上は不要です。プライバシーの面ではどちらもオンデバイスです。SpeechAnalyzerは設計上オンデバイス専用であり、SFSpeechRecognizerはSFSpeechRecognitionRequest自体でrequiresOnDeviceRecognitionフラグをtrueに設定したときにオンデバイスで動作します。これは既定値ではなく明示的な指定が必要で、設定しなければサーバー側の経路が使われる可能性があります。

併存パターンにおける意味合いはこうです。両方のフレームワークを動かすアプリは両方の許可を抱え込みます。SpeechAnalyzerの分岐にはマイクのプロンプト、レガシーの分岐には音声認識の許可が必要であり、App Storeのプライバシー「栄養成分表示」にも両方を反映させるべきです。

マイクの音声をアナライザーへ流し込むアプリには、通常どおりのAVAudioSessionの構成が当てはまります。このクラスターのPrivacy Manifestの記事では、Speechを使うアプリのマニフェスト項目を扱っています。プライバシーの宣言という点では、2つのフレームワークはどちらも同じ枠組みに入ります。

エージェントワークフローとのつながり

SpeechAnalyzerのオンデバイスモデルと構造化された出力は、このクラスターの2つのパターンときれいに噛み合います。

アプリ内推論のためのFoundation Models。 SpeechTranscriberで音声を文字起こしし、そのトランスクリプトをオンデバイスLLM（Foundation Modelsによるオンデバイス LLMで扱っています）で要約するパイプラインは、すべてオンデバイスで完結します。ネットワーク呼び出しの合計はゼロ。サードパーティへのデータ露出も合計ゼロです。

音声駆動のアクションのためのApp Intents。 トランスクリプトを入力として受け取るAppIntentは、Vocal Shortcuts（プラットフォームとしてのアクセシビリティで扱っています）や、Apple Intelligenceのアクション面から呼び出せます。intentのperformメソッドがSpeechAnalyzerを実行して入力を文字起こしし、アプリのロジックへ引き渡します。この流れ全体がプライベートかつローカルです。

パターンとしてはこうです。新しいSpeechフレームワークはオンデバイス知覚の三角形（画像のVision、言語推論のFoundation Models、音声のSpeech）を完成させ、完全にローカルなAI機能をiOSアプリで実用的なものにします。

iOS 26以降のアプリにとっての意味

持ち帰るべき点は3つです。

1. 新しいコードではSpeechAnalyzerを既定にする。 新しいモデル、モジュラーアーキテクチャ、そして長尺・遠方・ライブでの性能向上を踏まえれば、出発点として適切です。レガシーフレームワークは、古いOSのサポートや長尺の文字起こしでのカスタム語彙が求められる場合のフォールバックです。

2. 語彙に依存するアプリは音声の長さで分かれる。 カスタム語彙を伴う短い発話のディクテーションは移行できます。DictationTranscriberとAnalysisContext.contextualStringsがドメイン用語を運んでくれるからです⁶。カスタム語彙を伴う長尺の文字起こしは、SpeechTranscriberモデルがcontextual stringsを受け取るようになるまでSFSpeechRecognizerにとどめます。2つのフレームワークは共存するので、機能ごとに使い分けるのが正しいパターンです。

3. オンデバイスのプライバシーの物語がVisionからSpeechへ広がる。 Visionのオンデバイスコンピュータビジョンを軸に作られてきたアプリに、音声でも同等のものが手に入りました。推論のためのFoundation Modelsと組み合わせれば、知覚から言語までのパイプライン全体を、サードパーティへのデータ露出なしにローカルで動かせます。

Apple Ecosystemクラスターの全体像です。型付きのApp Intents、MCPサーバー、ルーティングの問い、Foundation Models、ランタイムとツーリングにおけるLLMの違い、3つのサーフェス、単一の信頼できる情報源というパターン、2つのMCPサーバー、Apple開発のためのhooks、Live Activities、watchOSのランタイム、SwiftUIの内側、RealityKitの空間的なメンタルモデル、SwiftDataのスキーマ規律、Liquid Glassのパターン、マルチプラットフォームでの出荷、プラットフォームマトリクス、Vision framework、Symbol Effects、Core MLによる推論、Writing Tools APIの採用、Swift Testing、Privacy Manifest、プラットフォームとしてのアクセシビリティ、SF Proのタイポグラフィ、visionOSの空間パターン、私が書かないと決めていること。ハブはApple Ecosystemシリーズにあります。iOSとAIエージェントのより広い文脈については、iOSエージェント開発ガイドをご覧ください。

よくある質問

SFSpeechRecognizerは非推奨になったのですか。

AppleはSFSpeechRecognizerを正式に非推奨とはしていません。iOS 26でも引き続き提供され、サポートされています。WWDC 2025での位置づけは、新しいコードにはSpeechAnalyzerが現代的で推奨される選択肢だというものです。レガシーフレームワークは特定のケース（長尺の文字起こしでのカスタム語彙、古いOSのサポート）に適したツールです。

録音済みの音声ファイルにSpeechAnalyzerを使えますか。

使えます。SpeechAnalyzer.start(inputSequence:)はAnalyzerInput値のAsyncSequenceを受け取り、各値がオーディオバッファをラップします。アプリは任意の音源（AVAudioEngine経由のマイク、録音済みファイルのURL、AVAssetのインスタンス）をAsyncSequenceのアダプターに包んでアナライザーへ渡します。文字起こしのストリームは、入力元が何であれ同じfor try await result in transcriber.resultsという消費の形になります。

移行するとカスタム語彙はどうなりますか。

移行先がどのトランスクライバーになるかによります。ディクテーションのパスは対応しています。AnalysisContext.contextualStringsで最大100件のフレーズを登録し、SpeechAnalyzer.setContext(_:)でコンテキストを設定すれば、DictationTranscriberがそれを利用します⁶。長尺向けのSpeechTranscriberモデルはcontextual stringsを受け取らないため、語彙に敏感な長尺の文字起こしは、Appleがこの差分を埋めるまでcontextualStringsを使ったSFSpeechRecognizerにとどめるべきです。ハイブリッドなアプローチ（一般的な文字起こしには新フレームワーク、語彙に敏感な長尺のパスにはレガシーAPI）はiOS 26でも有効です。

SpeechAnalyzerをサーバー側で動かせますか。

動かせません。SpeechAnalyzerはオンデバイス専用のフレームワークであり、サーバー側の経路を持ちません。サーバー側で文字起こしを行うなら、適切なのはクラウドAPI（OpenAI Whisper API、Google Cloud Speech-to-Text、AWS Transcribe）か、セルフホストのモデルです。Appleのフレームワークの価値は、まさにオンデバイスのプライバシーと呼び出しごとのコストがゼロだという点にあります。

言語の検出はどのように動きますか。

SpeechTranscriber(locale:)はトランスクライバーのインスタンスごとに1つのロケールを受け取り、ストリームの途中で言語を切り替えることはできません。iOS 26が自動化するのはアセット側です。AssetInventoryがロケールごとのモデルアセットをダウンロードして管理するため、複数の言語をサポートするために手作業でモデルの有無を管理する必要はもうありません。言語が事前に分かっているアプリ（ローカライズ済みアプリのディクテーション機能など）では、明示的に指定しましょう。多言語の場面（話者が言語を切り替えうる会議の文字起こしなど）では、言語を検出するかユーザーに選ばせたうえで、そのロケール向けのトランスクライバーを生成します。

このクラスターの他のオンデバイスMLの記事とはどう関係しますか。

SpeechAnalyzerはオンデバイス知覚スタックの3本目の柱です。Vision（Vision Frameworkで扱っています）が画像を、Speechが音声を担当し、Core ML（Core MLによるオンデバイス推論で扱っています）が両者の土台となるエンジンです。言語推論はFoundation Models（Foundation Modelsによるオンデバイス LLMで扱っています）が担います。これらを合わせると、ネットワーク呼び出しを必要としない完全なオンデバイスAIパイプラインができあがります。

参考文献