iOS 26の音声認識API SpeechAnalyzer でできること

はじめに

弊社では、6月15日（月）に「仕上検査音声入力AI機能」に関するプレスリリースを配信いたしました。

本記事では、こちらの音声入力の機能に関連して、iOS 26で使えるようになった音声認識API SpeechAnalyzer の機能について、「この仕組みを使うとどんなことができるのか」、そして「旧 API( SFSpeechRecognizer )と何が違うのか」を中心にご紹介しようと思います。

全体像: 音声がテキストになるまで

SpeechAnalyzer は、iOS 26 で刷新された Speech フレームワークの中心となる新しい API です。
この API を使った音声認識の「入口」の処理は、おおまかに次の流れになります。

マイク
↓
AVAudioEngine: 音声をPCMバッファ(AVAudioPCMBuffer)で取得
↓
AVAudioConverter: 認識エンジン用のフォーマットへ変換
↓
AsyncStream: 変換後のバッファを逐次供給
↓
SpeechAnalyzer: 実行エンジン(供給・セッション・確定を制御)
 └─ Transcriberモジュール: 音声認識〜テキスト生成
↓
認識テキスト

※PCMバッファ: 圧縮していない生の音声データの小さな塊。メモリ上で一時的に扱い、ファイルには残りません。

SpeechAnalyzer は音声を受け取って分析セッションを動かす「エンジン(器)」で、音声認識はしません。実際に聞き取ってテキストを生成するのは、そこに挿し込む「Transcriberモジュール」の役割です。認識結果もエンジンではなくモジュール側から受け取る形となります。

エンジンは共通のままで、用途に応じてモジュールを差し替えられることが、この新しい仕組みの設計思想のようです。

できること

1. オフラインでも動く

SpeechAnalyzer はオンデバイスで動作します。クラウドへ音声を送らないため、下記の利点があります。

ネットワークが無くても音声認識ができる（電波の届かない場所や機内でも動く）
音声データを外部に送らないため、プライバシー面、機密の面で懸念が小さい

2. ストリーミングで扱うことができる

マイクから取得した音声は、ファイルに保存せずPCMバッファのまま逐次エンジンへ流して認識できます。録音ファイルを書き出してから認識にかける、という処理は不要です。そのため端末に録音ファイルが溜まらず、ストレージに優しく、プライバシー的にも機密的にも安心です。

一方で「音声認識をしながら音声ファイルに残す」ことも可能です。

リアルタイム認識だけでよい: ファイルを作らずストリーミングのみ
後から聞き返したい、録音データを残したい: 同じバッファをファイルにも書き出す

という形で、用途に応じて選ぶことができます。

3. 発話の区切り・区間を扱える

iOS 26 の Speech フレームワークには、発話の有無を判定したり、認識結果を確定させる粒度を調整したりする仕組みが用意されています。

SpeechDetector モジュールは、テキスト化せず発話の有無・区間だけを検出する VAD（音声区間検出）です（無音と発話を切り分け、長い録音の区間分けや音声トリガの起点を見つける用途。Transcriberと併用）
Transcriber は結果を「暫定(volatile) → 確定(finalized)」の形で返し、ReportingOption（.frequentFinalizationなど）で確定の頻度＝区切りの細かさを調整できる

「どこで区切るか」を、用途に合わせて扱えるということです。

モジュールは用途で選ぶことができる

iOS 26 の Speech フレームワークには、用途の異なる複数のモジュールがあります。たとえば、短い発話を自然に扱いたいなら DictationTranscriber が素直な選択になります。

モジュール	向いている用途
DictationTranscriber	口述筆記(ディクテーション)向け。短い発話に適する [3]
SpeechTranscriber	長文向け。講義・会議など長時間の音声 [2][3]
SpeechDetector	テキスト化せず発話の有無・区間のみ検出。区切り用途でTranscriberと併用 [3]
SFSpeechRecognizer(旧API)	iOS 26未満もサポートする場合 [4]

SFSpeechRecognizer との違い

「できること」の多くは旧 API でも可能です。下記に新旧の違いを整理しました。

観点	SFSpeechRecognizer (iOS 10+)	SpeechAnalyzer (iOS 26+)
動作場所/オフライン	サーバー利用が基本。iOS 13以降はオンデバイス認識も可能だが、対応言語・端末に依存し、精度はサーバーに劣る [4][5][6]	オンデバイス前提。ローカルの新モデルで処理 [1][2]
ストリーミング(ファイル不要)	可。`SFSpeechAudioBufferRecognitionRequest` にPCMバッファを `append` して逐次認識(ファイル不要) [7]	可。`AsyncStream` で音声を供給し、入力と結果を非同期に分離して処理 [2]
長文・長時間	短い発話向け(DictationTranscriber が「SFSpeechRecognizer 相当=短発話」と位置づけ) [3]	長文・会議・数分〜数時間の連続音声向けに設計 [2][3]
構造	単一の Recognizer + リクエスト [4]	分析セッション + 差し替え可能なモジュールを非同期に協調動作 [2]
発話区間検出(VAD)	専用モジュールなし。終了は `endAudio()` で明示制御 [7]	`SpeechDetector`(発話区間を検出するモジュール)を併用可能 [3]
対応OS	iOS 10+(広い) [4]	iOS 26+(限定) [1]

内容を簡単に整理します。オフライン動作やストリーミングは新旧どちらも可能で、差が出るのは下記の部分になります。

①新しい高性能モデル
②長文・長時間への適性
③オンデバイスが前提か後付けか
④モジュール差し替えという構造の柔軟さ

代償として、iOS 26+ という対応OSの制約がついてくるということになります。

最小実装の骨組み

※以下は公式ドキュメント・公開APIをもとに認識の入口だけを一般化した最小例です。そのままでは動作しません（マイク供給部分などは流れの説明に留めています）。 ※各APIの呼び出しは実際に動作している形を確認していますが、利用時は公開時点の公式ドキュメントをご確認ください。

import Speech
import AVFoundation

let audioEngine = AVAudioEngine()

// 1. モジュールを用意(ロケール対応を確認。未DLなら downloadIfNeeded でモデル取得)
guard let locale = await DictationTranscriber.supportedLocale(equivalentTo: .current) else { return }
let transcriber = DictationTranscriber(locale: locale, preset: .phrase)

// 2. エンジンにモジュールを登録し、入力フォーマットを決める
let analyzer = SpeechAnalyzer(modules: [transcriber])
let analyzerFormat = await SpeechAnalyzer.bestAvailableAudioFormat(compatibleWith: [transcriber])

// 3. 音声供給用のストリームを用意して認識開始
let (inputSequence, inputBuilder) = AsyncStream<AnalyzerInput>.makeStream()
try await analyzer.start(inputSequence: inputSequence)

// 4. マイク入力(AVAudioEngine)のPCMバッファを analyzerFormat に変換して供給
//    （AVAudioEngine のタップ内で、変換したバッファを AnalyzerInput として
//      inputBuilder.yield(...) で投入する）

// 5. 認識結果をモジュール側から受け取る
Task {
    for try await result in transcriber.results {
        // result から確定テキストを取り出して利用する
    }
}

// 6. 停止時に確定
try await analyzer.finalizeAndFinishThroughEndOfInput()

マイク → 変換 → 供給 → エンジン → モジュール という一方向の流れに収まるのが、構成上のポイントです。

活用可能な場面

音声認識は活用の幅が広い機能です。

音声メモ / 議事録の文字起こし
ハンズフリー入力（手がふさがっている場面でのテキスト入力）
音声コマンド操作
アクセシビリティ（発話による操作・入力支援）
ライブ字幕 / 音声検索

特に「オンデバイスで動く × 音声をファイルに残さず扱える」という性質が、通信環境やプライバシーが気になる場面で効いてくるのではと思います。

まとめ

iOS 26 の Speech フレームワークは、「エンジン（SpeechAnalyzer）+ 差し替え可能なモジュール」という構成がポイントです。

オンデバイスで動作し、通信なしで音声認識ができる
ストリーミングで扱うことができ、音声ファイルを作らない（必要なら保存も選べる）
無音で発話を区切る仕組みもある
モジュールは用途で選ぶ
ただし多くの機能は旧 API でも可能。本質的な違いは「モデル性能・長文適性・オンデバイス前提・構造の柔軟さ」で、その代償が iOS 26+であること

この音声認識機能によってどんなことができるのか、その全体像をつかむ一助になれば幸いです。

終わりに

スパイダープラスでは、今回の音声認識機能のような技術を用いて、建設現場の課題を解決する取り組みを進めています。こうしたチャレンジに興味を持っていただけた方は、お気軽にご連絡ください。 https://hrmos.co/pages/spiderplus/jobs/0000067/apply

スパイダープラス Tech Blog

建設SaaS「スパイダープラス」のエンジニアとデザイナーのブログ