Appleの新しいSpeechフレームワーク：SpeechAnalyzer vs SFSpeechRecognizer

iOS 26では、既存のSFSpeechRecognizerに加えて、新しい音声認識フレームワークが導入されました。新しいAPIはSpeechAnalyzerと、その周りに組み合わさるモジュール（SpeechTranscriber、SpeechDetector）です¹。Apple自身の位置づけでは、SpeechAnalyzerはモダンなパスとされており、新しいオンデバイスモデル、長尺音声サポート、自動言語管理、リアルタイム用途向けの低レイテンシー、そして時間とともにより多くの分析タイプを追加できるモジュラーアーキテクチャを備えています。SFSpeechRecognizerは引き続き提供され、動作します。新しいフレームワークがまだ提供していないカスタム語彙機能に依存するアプリにとって、これは依然として正しいツールです。

この記事では、新しいフレームワークと旧フレームワークを比較していきます。視点は「新しいAPIの使い方」ではなく「いつ移行するか」です。なぜなら、動作するSFSpeechRecognizerの統合を持つすべてのチームは、同じトリアージ判断に直面するからです。新しいフレームワークのモダンなモデルとアーキテクチャは移行コストに見合うのか、それとも既存のカスタム語彙への投資が留まる理由となるのか。

TL;DR

• SpeechAnalyzer（iOS 26以降）はAppleのモダンなオンデバイス音声認識フレームワークです。初期化時に設定された分析モジュールを調整します。iOS 26では3つのモジュールが提供されます：SpeechTranscriber（長尺）、DictationTranscriber（短い発話、SFSpeechRecognizer相当）、SpeechDetector（音声活動検出、トランスクライバーとペアで使う必要あり）²。
• 新しいフレームワークは長尺音声を中心に設計されています：講義、会議、複数話者の会話など。完全にオンデバイスで動作し、言語を自動管理し、同等のトランスクリプション処理においてWhisper Large V3 Turboより約2倍高速だと報告されている、Apple独自の新しいモデルが付属しています³。
• SFSpeechRecognizerは引き続き提供され、動作します。レガシーフレームワークはカスタム語彙機能（既知のキーワードを登録してドメイン固有用語の認識精度を高める機能）を保持しており、新しいフレームワークではまだ提供されていません。
• 移行は機能単位であり、オール・オア・ナッシングではありません。長尺トランスクリプション、より低いレイテンシー、より優れた遠距離音声品質を必要とするアプリはSpeechAnalyzerに移行します。カスタム語彙への投資があるアプリは、その機能にはSFSpeechRecognizerを維持し、新機能にはSpeechAnalyzerを追加します。
• このクラスターのVision frameworkの記事では、Appleのもう一つのオンデバイス知覚プリミティブを取り上げています。SpeechAnalyzerは同じオンデバイス・ノークラウドのパターンを音声に拡張するものです。

アーキテクチャ：Analyzer + Modules

SpeechAnalyzerはそれ自体がトランスクライバーではありません。音声分析セッションを管理し、音声バッファを1つ以上のモジュールにディスパッチするコーディネーターです²。モジュールはinit(modules:)イニシャライザを通じて初期化時に設定され、分析はstart(inputSequence:)を介して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は音声セッション管理、言語検出、トランスクリプションを単一のオブジェクトに統合していました。新APIは関心を分離するため、アプリは必要なモジュールを組み合わせます。

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

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

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

遠距離音声処理。 部屋を挟んで配置されたマイク、複数話者を伴う会議テーブルの音声、環境ノイズを含む音声。モデルはこれらの条件向けに訓練されています。SFSpeechRecognizerの旧モデルはこれらをそれほど優雅に処理しません。

リアルタイム低レイテンシー動作。 SpeechTranscriberからのストリーミング結果は、旧フレームワークのSFSpeechRecognitionTask.shouldReportPartialResultsコールバックよりも速く到着します。ライブトランスクリプション（キャプション、音声駆動UI、ディクテーション）を表示するアプリは、よりスムーズな更新を得られます。

自動言語管理。 SpeechTranscriber(locale:)は開始ロケールを受け付けますが、モデルはストリーム途中の言語切り替えに適応できます。旧フレームワークでは、開発者が言語ごとのレコグナイザーをインスタンス化し、それらを切り替える必要がありました。

アプリサイズコストなし。 モデルはアプリではなくOSに付属します。SpeechAnalyzerを採用するアプリは、追加のモデル重みをバンドルしません。アプリバンドルにWhisperクラスのモデルを同梱する場合との対比は重要です：競争力のあるオンデバイストランスクリプションスタックがバンドルバイトゼロで実現できます。

旧フレームワークが今も提供するもの

SFSpeechRecognizerはiOS 26でも引き続き提供され、動作します。アプリがこれを使い続ける可能性のある理由は3つあります：

カスタム語彙。 SFSpeechRecognitionRequest.contextualStringsを使うと、アプリは既知のキーワード（固有名詞、技術用語、製品名）のリストを登録でき、モデルがそれらをより正確に認識する可能性が高まります。この機能は、ドメイン固有のアプリ（薬品名を含む医療ディクテーション、判例引用を含む法務アプリ、部品番号を含むエンジニアリングアプリ）で精度を大幅に向上させます。SpeechAnalyzerはまだカスタム語彙を提供していません。この機能に依存するアプリにとって、移行は精度の後退となります。

古いOSサポート。 SFSpeechRecognizerはiOS 10以降で利用可能です。SpeechAnalyzerはiOS 26以降を要求します。iOS 18以前を対象とするアプリにはレガシーフレームワークが必要です。

動作する既存の統合。 安定した、監査済み、高性能なSFSpeechRecognizer統合を持つアプリには、移行する緊急の理由はありません。新しいフレームワークの改善は、新しいユースケース（長尺トランスクリプション、遠距離音声、複数話者の会話）にとって最も重要です。レガシーAPIを通じて短い音声クエリを処理するアプリは、移行を正当化するほどの利益を得られないかもしれません。

いつ移行すべきか

挙げる価値のある3つの移行トリガー：

アプリが長尺音声を処理する。 会議レコーダー、講義トランスクリプションアプリ、ポッドキャストからテキストへのツールなど。新しいモデルの持続的音声に対する訓練が適しています。旧モデルは長いセッションで品質が低下します。最初に移行しましょう。

アプリが遠距離または騒がしい音声を必要とする。 会議室のトランスクリプション、単一の遠距離マイクを使ったインタビュー録音、環境音のある場所で取得した音声。新しいモデルはこれらの条件を顕著に上手く処理します。

アプリがライブトランスクリプションUIを表示する。 キャプションオーバーレイ、ディクテーションインターフェース、音声駆動のアシスティブUI。SpeechTranscriberからのストリーミング結果の低レイテンシーにより、UIはより応答性が高く感じられます。

必ずしも移行を正当化しないケース：

• カスタム語彙を伴う短い音声クエリ（処方箋ディクテーション、法律用語など）。語彙機能のためにSFSpeechRecognizerを維持しましょう。Appleが将来のリリースで語彙サポートを追加した場合はSpeechAnalyzerに手を伸ばしてください。
• iOS 18以前のサポートが必要なアプリ。SpeechAnalyzerはiOS 26専用です。コードベースには古いターゲット用にレガシーフレームワークがいずれにせよ必要となります。

並列パターン

古いOSバージョンも対象とし、かつiOS 26以降では新しいフレームワークの品質を求めるアプリにとって、並列パターンが正しいアプローチです：

import Speech

if #available(iOS 26.0, *) {
    let transcriber = DictationTranscriber(locale: .current)
    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)
    }
}

DictationTranscriberがiOS 26以降のブランチに適した選択である理由は、移行ターゲットがSFSpeechRecognizerのユースケース（同じディクテーションモデルを使った短いクエリ）だからです。長尺音声を対象とするアプリは、iOS 26ブランチでDictationTranscriberをSpeechTranscriberに置き換えます。

2つのフレームワークは共存します。ランタイムチェックが可用性に基づいて適切なものを選択します。どちらも他方をブロックしません。アプリのトランスクリプションパイプラインは適応します。

プライバシーとSpeech認可サーフェス

両フレームワークは同じSpeechフレームワークパーミッション（Info.plistのNSSpeechRecognitionUsageDescription）と同じユーザー向け認可フローを共有します⁵。プライバシーストーリーは同じです：両フレームワークで音声トランスクリプションはオンデバイスで行われます。SpeechAnalyzerは設計上オンデバイス専用です。SFSpeechRecognizerは、SFSpeechRecognitionRequest自体でリクエストのrequiresOnDeviceRecognitionフラグがtrueに設定されている場合にデフォルトでオンデバイスとなり、それ以外ではサーバーサイドのパスにフォールバックすることがあります。

含意：SpeechAnalyzerを使うアプリでも、Speech認可を正しく処理する必要があります。ユーザープロンプト、設定エントリ、App Storeのプライバシー栄養ラベルは、すべて同じ認可メカニズムを使用します。

マイク音声をアナライザーにストリーミングするアプリでは、標準のAVAudioSession設定が適用されます。このクラスターのPrivacy Manifestの記事では、Speechを使うアプリのマニフェストエントリを取り上げています。両フレームワークは同じプライバシー宣言の対象となります。

エージェントワークフローとの接続

SpeechAnalyzerのオンデバイスモデルと構造化された出力は、2つのクラスターパターンと綺麗に組み合わせられます：

アプリ内推論のためのFoundation Models。 SpeechTranscriberで音声を文字起こしし、その後オンデバイスLLMでトランスクリプトを要約するパイプライン（Foundation Models on-device LLMで取り上げ）は、完全にオンデバイスで動作します。総ネットワーク呼び出し：ゼロ。総サードパーティデータ露出：ゼロ。

音声駆動アクションのためのApp Intents。 トランスクリプトを入力として受け取るAppIntentは、Vocal Shortcuts（Accessibility as platformで取り上げ）またはApple Intelligenceのアクションサーフェスを介して呼び出せます。インテントのperformメソッドは入力を文字起こしするためにSpeechAnalyzerを実行し、その後アプリのロジックにディスパッチします。フロー全体がプライベートかつローカルです。

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

このパターンがiOS 26以降のアプリにとって意味すること

3つの要点。

1. 新しいコードではSpeechAnalyzerをデフォルトに。 モダンなモデル、モジュラーアーキテクチャ、改善された長尺・遠距離・ライブパフォーマンスにより、これが正しい出発点となります。レガシーフレームワークは、古いOSサポートまたはカスタム語彙が必要な場合のフォールバックです。

2. 語彙依存アプリではSFSpeechRecognizerを維持。 Appleが新しいフレームワークにカスタム語彙を追加するまで、ドメイン固有用語の精度のためにcontextualStringsに依存するアプリは旧APIを維持します。2つのフレームワークは共存します。機能ごとに混在させるのが正しいパターンです。

3. オンデバイスのプライバシーストーリーがVisionからSpeechへと拡張される。 VisionのオンデバイスCVを中心に構築したアプリは、音声についても同等のものを手に入れました。推論のためのFoundation Modelsと組み合わせることで、知覚から言語までの完全なパイプラインを、サードパーティへのデータ露出なしにローカルで実行できます。

Apple Ecosystemクラスター全文：型付きApp Intents；MCPサーバー；ルーティングの問い；Foundation Models；ランタイム vs ツール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 typography；visionOS空間パターン；書かないと決めていること。ハブはApple Ecosystem Seriesにあります。AIエージェントを伴うiOSの広範な文脈については、iOS Agent Developmentガイドを参照してください。

FAQ

SFSpeechRecognizerは非推奨ですか？

AppleはSFSpeechRecognizerを正式に非推奨としていません。iOS 26でも引き続き提供され、サポートされています。WWDC 2025での位置づけは、SpeechAnalyzerは新しいコードのためのモダンで推奨されるパスであり、レガシーフレームワークは特定のケース（カスタム語彙、古いOSサポート）に適したツールであるというものです。

事前録音された音声ファイルでSpeechAnalyzerを使えますか？

はい。SpeechAnalyzer.start(inputSequence:)は音声バッファのAsyncSequenceを受け取ります。アプリは任意の音声ソース（AVAudioEngineを介したマイク、事前録音されたファイルURL、AVAssetインスタンス）をAsyncSequenceアダプターでラップしてアナライザーにフィードできます。トランスクリプションストリームは、入力ソースに関係なく同じfor try await result in transcriber.resultsという消費形を生み出します。

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

カスタム語彙は現在SpeechAnalyzer / SpeechTranscriberではサポートされていません。ドメイン固有の精度のためにこれに依存するアプリは、Appleが機能を追加するまでそのパスを移行すべきではありません。ハイブリッドアプローチ（一般的なトランスクリプションにはSpeechAnalyzerを使い、語彙に敏感なトランスクリプションにはcontextualStringsを伴うSFSpeechRecognizerを使う）はiOS 26で動作します。

SpeechAnalyzerをサーバーサイドで実行できますか？

いいえ。SpeechAnalyzerはオンデバイス専用フレームワークです。サーバーサイドのパスはありません。サーバーサイドのトランスクリプションには、クラウドAPI（OpenAI Whisper API、Google Cloud Speech-to-Text、AWS Transcribe）またはセルフホストモデルが適切なツールです。Appleフレームワークの価値はまさに、オンデバイスのプライバシーと呼び出しごとのコストゼロのストーリーにあります。

言語検出はどのように機能しますか？

SpeechTranscriber(locale:)は初期ロケールを受け取ります。モデルはストリーム途中の言語切り替えに自動的に適応できます。言語が事前にわかっているアプリ（ローカライズされたアプリのディクテーション機能）では、明示的に指定しましょう。多言語コンテキスト（話者が切り替わる可能性のある会議トランスクライバー）では、自動管理が適切な動作です。

これはクラスターの他のオンデバイスML記事とどう位置づけられますか？

SpeechAnalyzerはオンデバイス知覚スタックの第三の柱です：Vision（Vision Frameworkで取り上げ）が画像を、Speechが音声を扱い、Core ML（Core ML On-Device Inferenceで取り上げ）は両方の基盤となるエンジンです。Foundation Models（Foundation Models on-device LLMで取り上げ）は言語推論を扱います。これらが一緒になって、ネットワーク呼び出しを必要としない完全なオンデバイスAIパイプラインを形成します。

参考文献