LASSIC Media らしくメディア
アプリの音声入力・文字起こしをオンデバイス実装、外注
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- 音声入力・文字起こしをアプリの端末内で完結させるオンデバイス実装は、通信不要かつプライバシー保護を重視する用途に向いています。
- iOSはSpeech frameworkのrequiresOnDeviceRecognition、AndroidはSpeechRecognizerのcreateOnDeviceSpeechRecognizerが、それぞれの端末内処理を支えています*2*4。
- クラウド型音声認識APIとの使い分けや、外注時に確認すべき論点も含めて解説します。
目次
- 音声入力・文字起こしのオンデバイス実装とは、端末内処理で通信を不要にする方式
- iOSはSpeech frameworkのSFSpeechRecognizerでオンデバイス認識を実装する
- AndroidはSpeechRecognizerのcreateOnDeviceSpeechRecognizerで端末内認識を実装する
- オンデバイスとクラウドAPIの比較——精度・対応言語・通信要否のハイブリッド判断
- 権限設定とプライバシー説明文で見落としやすい落とし穴
- 内製と外注の分かれ目——OS対応・言語検証・精度確認の工数で判断する
- まとめ：オンデバイス音声入力・文字起こし実装で押さえる3つの判断軸
- よくある質問
音声入力・文字起こしのオンデバイス実装とは、端末内処理で通信を不要にする方式
アプリの音声入力・文字起こしのオンデバイス実装とは、サーバーへ音声データを送信せず、スマートフォン端末内の処理だけで音声をテキストに変換する実装方式を指します。iOSとAndroidは、いずれも端末内だけで認識を完結させる仕組みを公式に提供しています*1*4。
本稿では、サーバーへ音声を送信するクラウド音声認識ではなく、端末内だけで完結する音声入力・文字起こし機能に対象を絞って解説します。業務システムへの音声認識AI組み込みや、議事録・文字起こし専用システムの構築とは異なるテーマです。
この記事では、iOSのSpeech framework、AndroidのSpeechRecognizer、双方の公式仕様に基づいて実装のポイントを整理します。加えてクラウド型音声認識APIとの使い分けや、外注時に確認すべき論点も取り上げます。
iOSはSpeech frameworkのSFSpeechRecognizerでオンデバイス認識を実装する
iOSでの音声認識はSpeech framework(Appleが提供する音声認識用のフレームワーク)が担い、中心となるオブジェクトがSFSpeechRecognizerです。SFSpeechRecognizerは、音声認識サービスの利用可否を確認し、新しい認識タスクを開始するためのオブジェクトです*1。
SFSpeechRecognizerのsupportsOnDeviceRecognitionプロパティは、その端末がネットワークなしで認識できるかどうかを示すブール値です*1。値がtrueであれば、通信環境に依存しない実装が選択肢になります。
実際に端末内処理を指定するには、SFSpeechRecognitionRequestのrequiresOnDeviceRecognitionプロパティをtrueに設定します*2。このプロパティが機能するには、supportsOnDeviceRecognitionもtrueである必要があります*2。
Apple公式は、オンデバイスのリクエストは精度が下がる場合があると説明しています*2。低遅延・プライバシー保護と認識精度は、トレードオフの関係にあると捉えておくとよいでしょう。
対応言語の範囲は、SFSpeechRecognizerのsupportedLocalesメソッドが返すSet<Locale>に限られます*1。端末やOSバージョンによって対応ロケールが変わるため、開発時に実機で確認する工程が欠かせません。
音声認識機能を使うには、Info.plistにNSSpeechRecognitionUsageDescription(音声認識の利用目的を説明する文字列)を追加します*3。このキーがないと、認可リクエストやSpeech framework API呼び出し時にアプリがクラッシュします*3。
許可状態はSFSpeechRecognizer.requestAuthorizationで取得でき、authorized・denied・restricted・notDeterminedの4種類に分かれます*3。初回はシステムがユーザーに確認ダイアログを表示し、以降は記録済みの結果を即時に返します*3。
AndroidはSpeechRecognizerのcreateOnDeviceSpeechRecognizerで端末内認識を実装する
Androidでの音声認識はSpeechRecognizerクラスが担います。Android公式ドキュメントは、SpeechRecognizerが追加のライブラリなしでAndroidに標準搭載され、オフラインでも動作すると説明しています*4。
端末内処理に特化した認識器を使うには、SpeechRecognizer.createOnDeviceSpeechRecognizer(Context)という静的メソッドでインスタンスを生成します*4。生成したインスタンスにRecognitionListenerを設定すると、認識結果のコールバックを受け取れます*4。
この機能を使うには、インスタンス化する前にRECORD_AUDIO権限(マイクからの録音を許可する権限)をユーザーから得ておく必要があります*4。権限が付与されていない状態で呼び出すと、想定した動作になりません。
従来型のインテントベース(RecognizerIntentを使うACTION_RECOGNIZE_SPEECHなど)の音声認識にも、オフライン処理を優先するオプションが用意されている場合があります。採用するAPIによって設定箇所が異なるため、実装前に対象バージョンでの挙動を確認することが大切です。
iOSと同様、Android側も端末やOSバージョンによって対応言語やオンデバイス認識の可否が変わります。開発対象の端末で実際に動作検証する工程を、実装計画にあらかじめ組み込んでおく必要があります。
オンデバイスとクラウドAPIの比較——精度・対応言語・通信要否のハイブリッド判断
オンデバイスとクラウド型の音声認識APIは、それぞれ得意な条件が異なる点に注意が必要です。両者を比較すると、実装方式を選ぶ際の判断軸が見えてきます。
| 比較軸 | オンデバイス認識 | クラウド音声認識API |
|---|---|---|
| 通信要否 | 不要(端末内で処理)*1 | 必須(サーバーへ送信) |
| データの外部送信 | 送信しない設計が可能*2 | 音声データがサーバーに送信される |
| 認識精度 | ネットワーク型より下がる場合がある*2 | 相対的に高くなりやすい |
| 対応言語 | 端末のsupportedLocalesの範囲に依存*1 | サービス側で対応言語を拡張しやすい |
| レイテンシ | 低遅延(往復通信が発生しない) | 通信環境に左右される |
通信が不安定な環境や、プライバシー要件が厳しい業務での利用を想定するなら、オンデバイス実装が有力な選択肢になります*2。対応言語の幅や認識精度を優先する場合は、クラウド型APIとのハイブリッド構成も検討に値します。
実務では、まずオンデバイスで認識を試み、信頼度が低い結果や未対応言語のときだけクラウドAPIへ切り替える設計も一つの方法でしょう。切り替え条件の設計が、利用者の体験と認識精度のバランスを左右します。
権限設定とプライバシー説明文で見落としやすい落とし穴
権限設計を誤ると、審査段階やユーザーの初回起動時にトラブルが生じやすくなります。iOSではNSSpeechRecognitionUsageDescriptionを設定しないままAPIを呼び出すと、アプリがクラッシュします*3。
Androidでも、RECORD_AUDIO権限の許可フローを実装しないままcreateOnDeviceSpeechRecognizerを呼び出すと、音声入力機能が動作しません*4。権限を拒否された場合の代替導線(テキスト入力への切り替えなど)も、設計段階で用意しておく必要があります。
この実装を内製で担うには、iOSのSpeech framework、AndroidのSpeechRecognizer、両OSの権限モデル、対応言語・精度のフォールバック設計など、複数領域の知識が必要になります。担当エンジニアがOSごとの仕様差を把握していないと、片方のOSだけ動作するアプリになりかねません。
専門パートナーに委託する場合は、両OSでの動作検証、対応言語の実機確認、クラウドAPIへのフォールバック設計までを一括して依頼できるかどうかが分かれ目になります。内製では、既存の開発担当者が通常業務と並行して検証工程を担うことになり、確認できる範囲が限られる場合があります。
内製と外注の分かれ目——OS対応・言語検証・精度確認の工数で判断する
音声入力・文字起こしのオンデバイス実装そのものは、AppleとGoogleがそれぞれ公式に手順を公開しているため、対象OSが1つで対応言語も限定的であれば、自社で対応できる場合もあります*1*4。
判断が分かれるのは、iOSとAndroidの両方に対応し、複数言語や複数端末での精度検証まで求められる場合です。検証対象が増えるほど、確認に必要な時間も比例して増えていきます。
。対応OS数や対応言語数によって必要な工数は変わってくるため、要件を診断したうえで内製・外注の切り分けを検討することが実務的です。
まとめ：オンデバイス音声入力・文字起こし実装で押さえる3つの判断軸
本稿では、アプリの音声入力・文字起こしを端末内で実装する方法を、AppleとGoogleの公式情報に基づいて整理しました。要点は3つに集約できます。第一に、iOSのrequiresOnDeviceRecognition、AndroidのcreateOnDeviceSpeechRecognizerは、いずれも通信を必要とせず端末内で認識を完結させる仕組みです*2*4。第二に、オンデバイス処理は精度が下がる場合があり、対応言語も端末に依存するため、クラウドAPIとのハイブリッド判断が欠かせません*2。第三に、対応OS数や検証言語数によって実装・検証の工数は変わり、内製と外注の判断材料になります。
よくある質問
オンデバイスとクラウドの音声認識は、どちらを選ぶべきですか。
通信環境やプライバシー要件を重視する場合は、オンデバイス実装が向いています*2。対応言語の幅や認識精度を優先する場合は、クラウド型APIとの併用が選択肢になります。要件に応じて両方を組み合わせるハイブリッド構成も検討できます。
iOSでrequiresOnDeviceRecognitionを設定すると、常に端末内だけで処理されますか。
requiresOnDeviceRecognitionをtrueに設定すると、音声データを端末外へ送信しない設定になります*2。ただしこの設定が機能するには、端末がsupportsOnDeviceRecognitionでtrueを返すことが前提になります*1。対応していない端末では、設定が反映されない点に注意が必要です。
Androidでオンデバイス認識を使うには、どのような準備が必要ですか。
SpeechRecognizer.createOnDeviceSpeechRecognizer(Context)でインスタンスを生成する前に、RECORD_AUDIO権限の許可を得ておく必要があります*4。権限が許可されていない状態では、音声入力機能が動作しません。
対応言語や認識精度は、クラウド型と同じですか。
同じとは限りません。iOSのオンデバイス認識は精度が下がる場合があるとApple公式が説明しており、対応言語も端末が返すSet<Locale>の範囲に限られます*1*2。導入前に、対象言語・対象端末での実機検証が欠かせません。
実装を外部に委託する場合、何を確認すればよいですか。
iOS・Android双方での動作検証範囲、対応言語の実機確認方法、クラウドAPIへの切り替え設計まで委託先に一括で依頼できるかを確認します。契約前に検証環境での確認範囲を明確にしておくと、リリース後のトラブルを抑えやすくなります。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Apple Inc.「SFSpeechRecognizer」（Apple Developer Documentation）（https://developer.apple.com/documentation/speech/sfspeechrecognizer）
- *2 出典：Apple Inc.「requiresOnDeviceRecognition」（Apple Developer Documentation, SFSpeechRecognitionRequest）（https://developer.apple.com/documentation/speech/sfspeechrecognitionrequest/requiresondevicerecognition）
- *3 出典：Apple Inc.「Asking permission to use speech recognition」（Apple Developer Documentation）（https://developer.apple.com/documentation/speech/asking_permission_to_use_speech_recognition）
- *4 出典：Google「Handle audio input from audio glasses and display glasses using Automatic Speech Recognition」（Android Developers, Jetpack XR SDK）（https://developer.android.com/develop/xr/jetpack-xr-sdk/asr）
