「オフラインでAI英会話は動くのか」という問いは、そのままでは答えが出ない。
AI英会話は1個の道具ではなく、音声認識・会話生成・音声合成という3つの部品が直列につながったものだからだ。
そして、この3つは通信の要り方がそれぞれ違う。
だから「オフラインで使える／使えない」ではなく、どの部品が端末の中で動く形を持っていて、どの部品が接続を前提に設計されているのかを分けて見るしかない。
この記事では、AIの部品を売っている会社が公開している開発者向けドキュメントの記述だけを材料にして、そこを1つずつ切り分けていく。
扱うのは「公式ドキュメントに何と書いてあるか」であって、特定のアプリが内部で何を使っているかではない。
サービスの順位づけはしない。仕組みの話だけをする。
【結論】オフラインでAI英会話が動くかは、部品ごとに答えが変わる
先に答えを置く。
音声認識と音声合成には、端末の中で動かすための公式の仕組みが存在する。
一方で、会話の返事を作る層は、接続を張ってセッションを開くところから始まる設計で書かれている。
| 段 | 部品 | 公式ドキュメントにある「端末内で動かす形」 |
|---|---|---|
| ① | 音声認識（Speech to Text） | ある（Embedded Speech／切断されたコンテナー） |
| ② | 会話を作る層（音声エージェント） | OpenAIのRealtime APIはWebRTCまたはWebSocketで接続する手順として書かれている |
| ③ | 音声合成（Text to Speech） | ある（Embedded Speech／切断されたニューラル テキスト読み上げコンテナー） |
⇒ 「音を文字にする」「文字を音にする」は端末内で完結させる道が公式に用意されているが、「何と返すかを考える」層は接続の上に置かれている。
これは性能の良し悪しではなく、部品の売られ方の違いだ。
オフラインの話が噛み合わない理由｜3つの部品は別々の会社が別々に売っている
オフラインで動くかどうかを1つの答えで言えないのは、3つの部品が最初から別々の商品だからだ。
マイクロソフトは音声テキスト変換を、リアルタイム文字起こし・ファスト トランスクリプション・バッチ文字起こしという複数の使い方をもつ機能として説明している。
グーグルの Cloud Speech-to-Text は、冒頭で「an API that lets you integrate Google’s speech recognition technologies into your developer applications」と自己紹介している。
そしてOpenAIの Voice agents は、音声エージェントの作り方を「GPT-Live」「Realtime API」「Chained voice pipeline」の3つのアーキテクチャとして並べている。
⇒ 1つのアプリの中で動いていても、中身は別会社の別商品を配線したものである場合がある。
だから「オフライン対応」という言葉は、どの段の話をしているかで意味が変わる。
- 音を文字にする段＝端末内で動かす形が公式にある。
- 返事を考える段＝接続してセッションを開く手順で説明されている。
- 文字を音にする段＝端末内で動かす形が公式にある。
オフラインで動く形①｜音声認識と音声合成には「Embedded Speech」がある
ここが「オフラインでAI英会話は動くのか」に対する、いちばん直接的な公式の答えだ。
マイクロソフトの Embedded Speech（埋め込み音声） は、冒頭でこう定義されている。
「クラウド接続が断続的または使用できない、デバイス上の音声テキスト変換およびテキスト読み上げシナリオ向けに設計されています」。
用途の例として、産業機器、音声対応の空調ユニット、範囲外に移動する可能性のある自動車が挙げられている。
そして「ハイブリッド クラウドおよびオフライン ソリューションを開発することもできます」と明記されている。
重要なのは、この形ではクラウドのリソースを使わないと書かれている点だ。
公式には「埋め込み音声の場合、Speech には Foundry リソースを使用しません。クラウド リソースの代わりに、ローカル デバイスにダウンロードするモデルと音声を使用します」とある。
つまり、モデルそのものを端末に置いて、そこで認識と合成をする作りだ。
メモリの見積もりも公開されている。
| 処理 | 公式に示されたメモリ消費量の一般的な見積もり |
|---|---|
| 音声認識または翻訳 | モデルのファイルの合計サイズ + 200 MB |
| 音声合成 | ロケールに応じて 100〜200 MB |
⇒ 端末内に置くのは「サービスへの入り口」ではなく「モデルのファイルそのもの」なので、容量がそのまま前提条件になる。
オフラインで使うための条件｜Embedded Speechには申請と形式の制限がある
「オフラインで動く形がある」と「誰でもすぐ使える」は別の話だ。
公式には「Microsoftは、埋め込み音声へのアクセスを制限します」と書かれており、制限付きアクセス レビューを通じて申請する仕組みになっている。
モデルと音声のダウンロード手順も、「制限付きアクセス レビュー プロセスが正常に完了すると、手順が提供されます」という順序で説明されている。
使える入り口も限定されている。
- 埋め込み音声をサポートするのは C#、C++、Java、Python、Go の Speech SDK のみと明記されている。
- 公式には「その他の Speech SDK、Speech CLI、REST API では、埋め込み音声はサポートされていません」とある。
- 埋め込み音声認識はモノラル 16 ビット、8 kHz または 16 kHz PCM でエンコードされた WAV のみがサポートされる。
- 埋め込みニューラル音声は 16 または 24 kHz の RIFF/RAW がサポートされる。
言語も、クラウド版と同じだけ並んでいるわけではない。
公式に列挙されている埋め込み音声テキスト変換モデルは、da-DK、de-DE、en-AU、en-CA、en-GB、en-IE、en-IN、en-NZ、en-US、es-ES、es-MX、fr-CA、fr-FR、it-IT、ja-JP、ko-KR、pt-BR、pt-PT、zh-CN、zh-HK、zh-TW である。
英語学習という文脈で見ると、en-US・en-GB・en-AU・en-CA・en-IE・en-IN・en-NZ が並んでいるので、英語の主要ロケールは押さえられていることが分かる。
さらに、読み上げの細かい制御にも差が出る。
公式は「埋め込み音声の場合、モデル構造の違いにより、特定の音声合成マークアップ言語（SSML）タグが現在サポートされていない可能性がある」と注意している。
オフラインで動く形②｜「切断されたコンテナー」という別ルート
端末内モデル以外に、もう1つ公式のオフライン経路がある。
切断されたコンテナーの説明は、「切断されたコンテナーを使用すると、これらの API のいくつかをインターネットから切断して使用できます」と始まる。
そして、この方法で実行できるコンテナーの一覧に音声テキスト変換・カスタム音声テキスト変換・ニューラル テキスト読み上げが含まれている。
⇒ AI英会話の①と③にあたる部品は、インターネットから切り離した環境で動かす道が公式に用意されている。
ただし、これも申請制だ。
- 要求フォームに記入して送信し、チームが確認して10 営業日以内に決定を電子メールで送信すると書かれている。
- アクセスできるのは「組織が、Microsoft の戦略的な顧客またはパートナーとして認定されている必要があります」という条件を満たす相手に限られる。
- 想定ユース ケースとして「インターネットに断続的にアクセスできるリモートの場所」「どのような種類のデータもクラウドに返送しないという厳格な規制の下にある組織」が挙げられている。
- 使用状況は消えるのではなく、コンテナーが出力マウントに使用状況レコードを書き込む形で残る。
この条件を読むと、切断されたコンテナーが個人の英語学習アプリ向けの入り口ではないことが分かる。
公式が例に出しているのも、銀行や政府機関のような安全な環境にデバイスを置く必要があるシナリオだ。
オフラインにならない形｜通常のコンテナーは接続を切ると応答を止める
「自分のサーバーで動かす＝オフライン」ではない、というのがここで分かる。
Docker で音声コンテナーをインストールして実行するの公式手順には、はっきりこう書かれている。
「音声コンテナーは、計測のために Azure に接続されていないと、実行のライセンスが許可されません」。
接続が切れたときの挙動も、時間つきで説明されている。
| 状態 | 公式に書かれている挙動 |
|---|---|
| 通常時 | コンテナーは約10〜15分ごとに使用状況を報告する |
| 接続できない時間が続く | コンテナーは実行され続けるが、課金エンドポイントが復元されるまでクエリには対応しない |
| 再試行 | 10〜15分の同じ時間間隔で10回試行される |
| 10回で復旧しない | コンテナーによる要求の処理は停止される |
⇒ 手元のマシンに置いていても、承認された切断構成でなければ、通信が要らなくなるわけではない。
ハードウェア側の条件も軽くない。
公式は「ホストは、高度なベクター拡張機能（AVX2）をサポートしている必要があります」と書き、AVX2 が無いと「コンテナーは正しく機能しません」と断っている。
オフラインが効かない部分｜会話を作る層は接続を張って始まる
ここが、AI英会話をまるごとオフラインにできるかどうかの分かれ目だ。
OpenAIの Realtime API は、ブラウザから音声で会話する流れを4段階の手順として書いている。
- アプリのサーバーが、Realtimeセッション用の一時的なクライアント シークレット（ephemeral client secret）を作る。
- フロントエンドが
RealtimeSessionを作る。 - セッションがブラウザではWebRTC、サーバーではWebSocketで接続する。
- エージェントが、そのセッションの中で音声のターン・ツール・割り込み・引き継ぎを扱う。
3番目の「接続する」が、この設計では省略できる工程として書かれていない。
Realtime conversations でも、セッションは「a stateful interaction between the model and a connected client」と定義されている。
接続したクライアントとモデルのあいだの状態、という定義だ。
さらに同じページには「The maximum duration of a Realtime session is 60 minutes」と書かれている。
⇒ 会話の層は「つなぎっぱなしの時間」そのものが仕様として定義されている。ここを切ると、会話は続かない。
グーグル側も同じ構図だ。
Cloud Speech-to-Text の3つの方式は、同期認識が「sends audio data to the Cloud Speech-to-Text API」、非同期認識も「sends audio data to the Cloud Speech-to-Text API」、ストリーミング認識が「performs recognition on audio data provided within a gRPC bi-directional stream」と説明されている。
いずれも「音声データをAPIへ送る」ことが手順の中心に据えられている。
オフラインとクラウドの中間｜ハイブリッド構成という公式の答え
現実の製品が採るのは、たいてい二択ではなく中間だ。
Embedded Speech のドキュメントには HybridSpeechConfig という構成が載っている。
公式の説明は「クラウドの接続が制限されているか遅い場合に備え、既定でクラウド音声サービスと埋め込み音声がフォールバックとして使用されます」というものだ。
そして、認識と合成で切り替え方が違うと明記されている。
| 部品 | ハイブリッド構成での公式の挙動 |
|---|---|
| 音声テキスト変換（認識モデル） | クラウド サービスへの接続が繰り返し試行された後に失敗したときに埋め込み音声が使われる。後で接続が再開されると、認識はクラウドを再び使い続ける可能性がある |
| テキスト読み上げ（音声） | 埋め込み合成とクラウド合成が並列に実行され、応答速度に基づいて最終的な結果が選択される。最適な結果は新しい合成要求ごとに再評価される |
読み上げは「どちらが速く返ってきたか」で毎回決まる、と書かれているのが面白いところだ。
同じアプリを使っていても、声の質や反応の速さが日によって違って感じることがあるとすれば、こういう切り替えの設計が背景にありうる。
なお公式には「Speech SDK for Python と Speech SDK for Go では、ハイブリッド音声はサポートされていません。ハイブリッド シナリオでは、C#、C++、または Java SDK を使用します」という但し書きもある。
オフラインにすると何が変わるか｜仕様の差を1枚にする
ここまでの記述を、学習者の目線で1枚にまとめる。
| 見たいところ | 端末内（Embedded Speech） | クラウド接続 |
|---|---|---|
| 入り口 | C#／C++／Java／Python／Go の SDK のみ | SDK・CLI・REST API が使える |
| 使い始めるまで | 制限付きアクセス レビューの申請が要る | リソースを作ってキーとエンドポイントを使う |
| 置くもの | モデルと音声のファイルを端末に置く | クラウド リソースを参照する |
| 音声形式 | 認識はモノラル16ビット・8/16 kHz PCM WAV | 複数の形式と圧縮入力に対応 |
| 読み上げの制御 | 一部のSSMLタグが未対応の可能性ありと注意されている | SSMLのドキュメントが別に用意されている |
⇒ オフライン側は「軽い代わりに条件が細かい」、クラウド側は「条件が緩い代わりに通信が要る」という交換になっている。
どちらが優れているという話ではなく、何を諦めるかの選択だ。
オフラインでAI英会話を考える人が、仕様から読み取れること
ここは仕様の読み取りであって、特定アプリの動作保証ではない。
公式ドキュメントの記述から言えるのは、次の3点に整理できる。
- 発音の練習や読み上げの再生といった「音の入り口・出口」は、端末内で完結させる技術的な道が公式に存在する。
- 自由な受け答えを続ける部分は、接続したセッションの上に置かれた設計として説明されている。
- その中間として、接続が細いときだけ端末内へ落とすハイブリッド構成が用意されている。
だから、機内や地下で英語アプリの反応が変わるとしたら、その変化は「3段のどこが切れたか」で説明できる場合がある。
音は拾えているのに返事が返らないなら、切れているのは②の層だ。
そもそも文字起こしすら出ないなら、①がクラウド側にある構成だということになる。
ただし、どのアプリがどの構成を採っているかは、そのアプリの提供元が公表している情報で確かめるしかない。
オフラインのAI英会話に関するよくある質問
Q. オフラインでもAI英会話は成立するのか。 A. 部品ごとに答えが違う。音声認識と音声合成には端末内で動かす公式の仕組み（Embedded Speech・切断されたコンテナー）があるが、OpenAIのRealtime APIはWebRTCまたはWebSocketで接続する手順として書かれている。
Q. 自分のパソコンでコンテナーを動かせば通信は要らないのか。 A. 通常の音声コンテナーについては「計測のために Azure に接続されていないと、実行のライセンスが許可されません」と公式に書かれている。接続が10回の再試行で復旧しないと要求の処理は停止される。
Q. Embedded Speech はどの言語に対応しているのか。 A. 公式に列挙されている音声テキスト変換モデルは da-DK、de-DE、en-AU、en-CA、en-GB、en-IE、en-IN、en-NZ、en-US、es-ES、es-MX、fr-CA、fr-FR、it-IT、ja-JP、ko-KR、pt-BR、pt-PT、zh-CN、zh-HK、zh-TW である（出典）。
Q. 接続が不安定な場所ではどうなる設計になっているのか。 A. HybridSpeechConfig が用意されていて、認識はクラウドへの接続が繰り返し失敗したときに埋め込み側へ落ち、読み上げは埋め込みとクラウドを並列で走らせて応答速度で結果を選ぶと書かれている。
Q. オフライン構成にすると音質や表現は変わるのか。 A. 公式は「埋め込み音声の場合、モデル構造の違いにより、特定のSSMLタグが現在サポートされていない可能性がある」と注意している。読み上げの細かい制御には差が出うる。
Q. 録音した音声を後からまとめて処理するのは、どの仕組みになるのか。 A. その用途はバッチ文字起こしにあたる。公式は「ファイルに格納されている大量のオーディオを文字起こしできるように設計されています」と説明しており、オーディオを非同期的に処理する方式だとしている。
まとめ｜オフラインでAI英会話は「部品ごとに」答えが違う
もう一度整理する。
- AI英会話は音声認識・会話生成・音声合成の3段でできていて、通信の要り方は段ごとに違う。
- 端末内で動く道が公式にあるのは①と③＝Embedded Speech は「クラウド接続が断続的または使用できない」場面向けに設計されたと明記されている。
- 切断されたコンテナーの対象には音声テキスト変換・カスタム音声テキスト変換・ニューラル テキスト読み上げが含まれるが、申請と承認が前提になっている。
- 通常のコンテナーは接続前提＝計測のための接続が無いと実行ライセンスが許可されず、再試行10回で復旧しなければ要求の処理が止まる。
- 会話を作る②は接続の上にある＝Realtime セッションは「接続したクライアントとモデルの状態」と定義され、最大60分という時間まで仕様に書かれている。
⇒ 「オフラインで使えるか」ではなく、「自分が切りたい通信は、3段のどこにかかっているか」で見る。そこが分かれば、電波の無い場所で何が動かなくなるのかを、感覚ではなく仕様で説明できる。
※本記事の一次ソースはすべて2026-09-16に各公式ドキュメントで確認した。仕様は更新されるため、最新は各公式ドキュメントで確認してほしい。
Comments