AI英会話に向かって話した英語は、そのあとどこへ行くのか。
この問いは「そのアプリを信用していいか」の話に見えるが、答えの半分を持っているのはアプリの下で動いている部品を売っている会社のほうだ。
AI英会話アプリの多くは、音声認識も言語モデルも音声合成も自社では作っていない。
マイクロソフト・グーグル・OpenAIといった会社がAPIとして売っているものを、組み合わせて使っている。
そしてその3社は、預かった音声とテキストをどう扱うかを、開発者向けドキュメントに文章で書いている。
この記事では、その3枚のドキュメントに書いてあることだけを並べて、保持期間・学習への利用・ログの設定・置かれる場所の4点を比べる。
個別のアプリのプライバシーポリシーを推測で断定することはしない。読むのは部品側の仕様だけだ。
【結論】AI英会話のデータの扱いは、部品ごとに「既定値」が違う
先に答えを置く。
3社の公式ドキュメントを同じ質問で並べると、答えの形がはっきり分かれる。
| 質問 | マイクロソフト（Azure 音声テキスト変換） | グーグル（Cloud Speech-to-Text） | OpenAI（API） |
|---|---|---|---|
| 既定で保存されるか | リアルタイム処理では「保持または格納しません」と明記 | 「By default, Cloud Speech-to-Text does not log customer audio data or transcripts.」 | 不正利用監視ログが既定で生成される。ただし音声の文字起こしエンドポイントは保持「None」 |
| モデルの学習に使われるか | データ トレースなしの機能では保持しないと記載 | 既定はログしない。オプトインすると「refine and improve the service quality」に使われる | 「not used to train or improve OpenAI models（明示的にオプトインしない限り）」 |
| ログを残す／残さないの切り替え | 機能の選び方（リアルタイムかバッチか、コンテナーか）で変わる | プロジェクト単位でdata loggingをオプトイン | Zero Data Retention／Modified Abuse Monitoringを組織・プロジェクト単位で設定 |
| 置かれる場所を選べるか | バッチでは顧客が保存場所を指定する | ドキュメントにregional endpointsの項目がある | Data residency controlsでリージョンを指定できる |
⇒ 3社とも「既定では学習に使わない」と書いているが、既定で残るログの有無と、その切り替え方が違う。
だから「AI英会話のデータは安全か」ではなく、「どの部品を、どの設定で呼んでいるか」が問いの正しい形になる。
AI英会話のデータが通る道｜声が触る場所は1か所ではない
比べる前に、音声がどこを通るかを確認しておく。
マイクロソフトの音声テキスト変換のデータ、プライバシー、セキュリティは、処理されるデータの種類を3つに分けて書いている。
- オーディオ入力または音声オーディオ＝SDKやREST API経由でサービス エンドポイントにストリーミングされる入力。
- 文字起こしテキストの入力＝発音評価のとき、入力音声と一緒に「正しい」テキストとして送られるもの。
- 音声翻訳の文字起こし＝音声から起こしたテキストを、さらに翻訳サービスへ渡すもの。
ここで見落とされやすいのが2つ目だ。
発音採点は音だけを送っているのではなく、「あなたが読むはずだった文」も一緒に送っている。
同じ「話しただけ」でも、機能によって送られるものの数が違う。
同じドキュメントは冒頭で、音声データと文字起こしテキストについて「個人データや機密データと見なされる可能性がある」と断っている。理由は、声そのものだけでなくオーディオの内容にも個人情報が含まれうるからだと書かれている。
つまり扱いが厳しいのは「声紋だから」ではなく、「何をしゃべったか」も含めてという話になっている。
AI英会話のデータとマイクロソフト｜リアルタイムは「保持または格納しません」
マイクロソフトの書き方はいちばん短く、いちばん言い切っている。
同ドキュメントには「データ トレースなし」という見出しがあり、そこにこう書かれている。
⇒ 「リアルタイムの音声テキスト変換、高速文字起こし、発音評価、音声翻訳を実行する場合、Microsoftは顧客から提供されたデータを保持または格納しません」
さらにリアルタイム処理の説明では、オーディオ入力はAzureのサーバー メモリでのみ処理され、保存時にデータは格納されないと書かれている。転送中のすべてのデータは保護のために暗号化されるとも明記されている。
AI英会話で使われる機能の多くはこのリアルタイム側にあたるので、ここは読み手にとっていちばん近い記述になる。
ただし、同じページの中に「そうではない経路」も同時に書かれている。
| 経路 | 公式の記述 | データはどこに残るか |
|---|---|---|
| リアルタイム音声テキスト変換 | サーバー メモリでのみ処理、保存時に格納しない | 残らないと書かれている |
| 発音評価・高速文字起こし・音声翻訳 | 「保持または格納しません」に含まれている | 残らないと書かれている |
| バッチ文字起こし | 顧客が入力と出力の保存場所を指定する | 顧客側のストレージ（未指定ならMicrosoftストレージ） |
| 音声コンテナー | Dockerコンテナーを自分の環境にデプロイ | 顧客のコンテナー内。クラウドの音声サービスには送信されない |
バッチ文字起こしは、ストレージ内の大量のオーディオをまとめて文字起こしする使い方で、結果はストレージ コンテナーに格納される。
プライバシーのドキュメント側では、この出力についてtimeToLive というパラメーターで保持時間を設定できると書かれている。
出力がMicrosoftストレージに格納されている場合は、削除APIを呼ぶか timeToLive を設定して、指定した時間内に自動削除できるとも書かれている。
⇒ マイクロソフト側の「残る／残らない」は、機能の選び方でほぼ決まる構造になっている。
声の特徴はどう扱われるか｜話者分離は既定で無効、信号は完了後に破棄
「声の特徴を取られるのでは」という不安に、いちばん直接答えているのがこの項目だ。
話者分離（diarization）は、1つの音声に複数の人が入っているとき、誰が話したかで区切る機能だ。
マイクロソフトのドキュメントは、この機能について次のように書いている。
- 話者分離オプションは既定では無効。
- 有効にすると、音声入力から固有の音声特性信号を分析して抽出する。
- その信号は文字起こし出力に話者マーカーを付ける目的でのみ使われ、一時的に保持される。
- プロセスが完了すると、話者を分離するために使用されたすべての信号データが破棄される。
- 話者ID認識の登録や、複数のオーディオ ファイル間で一意の話者を追跡する機能はサポートされていない。
最後の1行が効いている。
この機能は「同じ人を別のファイルでも同じ人だと認識する」ようには作られていない、と公式が明記している。
なお同じページには、生体認証データを処理する場合の責任について、保持期間や破棄に関する通知・同意取得・削除の対応が実装する側（＝アプリ事業者）の責任だと書かれている。
ここでいう生体認証データは、GDPRの第4条に規定されている意味だとも添えられている。
AI英会話のデータとグーグル｜既定はログしない、オプトインで変わる
グーグルの書き方は、3社のなかでいちばん「はい／いいえ」がはっきりしている。
Cloud Speech-to-Text の Data logging は、冒頭でこう書いている。
⇒ 「By default, Cloud Speech-to-Text does not log customer audio data or transcripts.」（既定では、顧客の音声データも文字起こしもログしない）
そのうえで、data logging というプログラムにオプトインできると続く。
オプトインすると、ログされたデータがCloud STTのサービス品質を「refine and improve」するために使われ、代わりに割引された料金が適用されると書かれている。
つまり、この会社は「安くする代わりにデータを使わせてほしい」を、正面から契約として置いている。
オプトインしたあとの扱いについても、条件が具体的に書かれている。
| 項目 | Data loggingページの記述 |
|---|---|
| 適用範囲 | data loggingを有効にしたプロジェクトに送ったデータのみ。他のGoogle Cloudプロジェクトは有効にしないまま使える |
| データの所有権 | アップロードしたデータの完全な所有権は顧客が持ち続ける |
| モデルの所有権 | そのデータから学習されたモデルの所有権はグーグルが保持する |
| アクセスできる人 | 「a limited set of authorized Google employees and contractors」に限られる |
| 広告利用 | 顧客や顧客のユーザーへ製品・サービス・広告を狙って出すためには使わない、と明記 |
| プロジェクト削除との関係 | ログされたデータはプロジェクトを削除しても消えない。削除リクエストのフォームを出す必要がある |
最後の行は、3社のドキュメントのなかでもとくに実務的な注意書きだ。
原文は「Caution」として置かれており、「Your logged data is not deleted when you delete your project.」と書かれている。
プロジェクトごと消せば全部消える、という直感とは違う動きをする、と公式側が先回りして書いている形になる。
なお、Cloud Speech-to-Text の基本ドキュメントには、対応言語や認識のしくみなど、データの扱い以外の仕様がまとまっている。
AI英会話のデータとOpenAI｜学習には使わない、ただしログの話は別にある
OpenAIのドキュメントは3社のなかでいちばん長く、いちばん場合分けが細かい。
Data controls in the OpenAI platform は、冒頭で学習利用について言い切っている。
⇒ 「As of March 1, 2023, data sent to the OpenAI API is not used to train or improve OpenAI models (unless you explicitly opt in to share data with us).」
APIに送ったデータはモデルの学習には使わない。明示的にオプトインした場合を除く、という書き方だ。
そのうえで、学習とは別に保存されるものが2種類あると定義している。
- Abuse monitoring logs（不正利用監視ログ）＝利用ポリシーを守らせ、有害な使われ方を抑えるために生成されるログ。プロンプトや応答といった顧客コンテンツを含みうる。
- Application state（アプリケーション状態）＝機能を成立させるために保持されるデータ。
監視ログの既定については「retained for up to 30 days」と書かれている。法律上より長い保持が必要な場合などの例外も併記されている。
ここで大事なのは、この30日が「全部のエンドポイントで一律」ではないことだ。
同じページには、エンドポイントごとの保持を並べた表がある。AI英会話に関係する行を抜くと、こうなっている。
| エンドポイント | 学習に使うか | 監視ログの保持 | アプリケーション状態の保持 |
|---|---|---|---|
/v1/audio/transcriptions（音声→テキスト） | No | None | None |
/v1/audio/translations（音声翻訳） | No | None | None |
/v1/audio/speech（テキスト→音声） | No | 30 days | None |
/v1/realtime（リアルタイム会話） | No | 30 days | None |
/v1/chat/completions | No | 30 days | None（例外は後述と記載） |
/v1/responses | No | 30 days | None（例外は後述と記載） |
⇒ 音声の文字起こしと音声翻訳だけ、監視ログの保持が「None」になっている。
この表は、同じ「AI英会話」でもどのエンドポイントで作られているかで残り方が変わることを示している。
細かい例外も書かれている。たとえば /v1/chat/completions と /v1/responses では、音声出力のアプリケーション状態が複数ターンの会話を成立させるために1時間保存されると明記されている。
/v1/responses については、既定または store を true にした場合、応答データが少なくとも30日保存されるとも書かれている。
リアルタイムの文字起こしの使い方そのものは、Realtime transcription のガイドに別途まとまっている。
AI英会話のデータを「残さない」設定は、OpenAI側では申請制になっている
ログを止める仕組みは用意されているが、誰でもすぐ押せるスイッチではない、と書かれている。
OpenAIのページには、監視ログから顧客コンテンツを外すための制御が2つ並んでいる。
- Modified Abuse Monitoring＝全APIエンドポイントで、監視ログから顧客コンテンツを除外する。プラットフォームの機能はそのまま使える。
- Zero Data Retention＝上と同じく除外したうえで、
/v1/responsesと/v1/chat/completionsのstoreパラメーターが、要求でtrueにしようとしても常にfalseとして扱われる。
そして、この2つには条件が付いている。
⇒ 「これらの制御はOpenAIによる事前承認と、追加要件への同意を条件とする」と明記されている。
承認された組織は、設定画面の Data Retention タブで組織単位とプロジェクト単位の両方に設定できると書かれている。
プロジェクト側では default（組織の設定を継承）、明示的にどちらかを選ぶ、None（そのプロジェクトでは無効にする）から選べるとも書かれている。
加えて、Zero Data Retention や Modified Abuse Monitoring を有効にした顧客は、自分のユーザーにポリシーを守らせる責任と、適用される法律上の報告義務を果たす責任を負うと書かれている。
さらに、自前の鍵で暗号化する Enterprise Key Management（EKM）という仕組みもある。
外部のKMSで管理する鍵を使って、OpenAI側にあるアプリケーション状態を暗号化するもので、対応先として AWS KMS・Google Cloud・Azure Key Vault が挙げられている。
AI英会話のデータが置かれる国は、選べる場合と選べない場合がある
「日本から話した英語が、どの国のサーバーに置かれるのか」も、公式に項目がある。
OpenAIのページには Data residency controls という節があり、プロジェクトの設定としてインフラの場所を指定できると書かれている。
ここで重要なのは、「保存の場所」と「処理の場所」が別に書かれていることだ。
原文にも「Support for regional storage does not imply support for regional processing.」と、わざわざ念押しがある。
| リージョン | ドメイン | 保存（Regional storage） | 処理（Regional processing） | MAM／ZDRの要否 |
|---|---|---|---|---|
| United States | us.api.openai.com | Yes | Yes | No |
| Europe（EEA＋スイス） | eu.api.openai.com | Yes | Yes | Yes（注記あり） |
| Japan | jp.api.openai.com | Yes | No | Yes |
| United Kingdom | gb.api.openai.com | Yes | No | Yes |
| United Arab Emirates | ae.api.openai.com | Yes | Yes | Yes |
⇒ 日本リージョンは、保存はできるが処理はできない側に分類されている。
実際、音声の3エンドポイント（/v1/audio/transcriptions、/v1/audio/translations、/v1/audio/speech）の行を見ると、保存リージョンは「All listed regions」だが、処理リージョンはUnited States と Europe（EEA＋スイス）だけと書かれている。
/v1/realtime にいたっては、保存リージョン自体が United States と Europe の2つだけになっている。
また、選んだリージョンが処理に対応していない場合、サービス提供のためにリージョン外で一時的に処理・保存することがあるとも明記されている。
米国以外のリージョンを使うには、不正利用監視の制御（MAMまたはZDR）の承認と、Modified Retention amendment の締結が必要だとも書かれている。
マイクロソフト側にも「場所を選ぶ」に近い仕組みがある。
音声コンテナーは、Speech Services のAPIを Docker コンテナーとして自分の環境にデプロイする方式で、公式には「オーディオ データ入力と文字起こし出力は顧客のコンテナー内で処理され、クラウドベースの音声サービスには送信されません」と書かれている。
ただし同じ節に、コンテナーを動かす機器やインフラを守る責任は運用する側にあるとも書かれている。セキュリティは共有責任だという整理だ。
AI英会話のデータの話で起きやすい、3つの読み違い
3枚を並べて読むと、誤解が生まれる場所もはっきりする。
1つ目は、「学習に使わない」と「どこにも残らない」を同じ意味だと思うことだ。
OpenAIは学習利用を否定したうえで、不正利用監視ログとアプリケーション状態を別枠で定義し、エンドポイントごとの保持日数を表にしている。
2つ目は、「既定値」と「設定できる値」を混ぜることだ。
グーグルは既定でログしないと書いており、ログするのはオプトインした場合の話になっている。逆にOpenAIは既定で監視ログが生成され、外すほうが申請制になっている。
同じ「選べる」でも、初期状態が逆を向いている。
3つ目は、「消した」と「消える」を同じだと思うことだ。
グーグルはプロジェクトを削除してもログされたデータは消えないと注意書きを置き、削除リクエストのフォームを案内している。
マイクロソフトはバッチの出力について、削除APIか timeToLive という具体的な手段を書いている。
⇒ 消し方は3社とも書いてあるが、押す場所がそれぞれ違う。
AI英会話のデータについて、利用者の側から確認できること
ここまでは全部「部品を呼ぶ側」の設定の話で、アプリの利用者が直接いじれるものではない。
ただし、部品側のドキュメントに書かれている構造が分かっていれば、確認すべき点は絞れる。
- どの機能を使っているか。リアルタイムの会話なのか、録音をまとめて処理する形なのかで、部品側の既定の扱いが変わる。
- 履歴が残る画面があるか。会話ログが後から見返せる作りなら、どこかに保存されているということになる。
- 発音採点があるか。ある場合、音声だけでなく参照テキストも一緒に送られる作りになっている。
- 削除の導線があるか。部品側には削除の手段が用意されているので、アプリ側にそれを呼ぶ画面があるかどうかが分かれ目になる。
これらはいずれも、アプリの画面を見れば分かることだ。
仕組みを知る目的は不安を煽ることではなく、見るべき場所を4つに減らすことにある。
なお、音声テキスト変換そのものの仕様はAzure の音声テキスト変換のドキュメントにまとまっている。データの扱いとは別のページになっているので、両方を見ると全体像が取れる。
AI英会話のデータに関するよくある質問
ここまでで出てきた記述だけを使って答える。
Q. AI英会話で話した音声は、AIの学習に使われるのか。 A. 部品側の記述としては、OpenAIが「APIに送られたデータはモデルの学習や改善には使わない（明示的にオプトインしない限り）」と書いており、グーグルは「既定ではログしない」と書いている。オプトインしたプロジェクトについては、グーグルはCloud STTの品質改善に使うと明記している（出典）。
Q. 保持期間はどれくらいなのか。 A. OpenAIは不正利用監視ログを既定で「up to 30 days」と書いている。ただしエンドポイント別の表では、/v1/audio/transcriptions と /v1/audio/translations の監視ログ保持は「None」になっている。マイクロソフトはリアルタイム処理について「保持または格納しません」と書いている。
Q. 声そのもの（声紋）が保存されるのか。 A. マイクロソフトの話者分離の説明では、抽出された音声特性信号は話者マーカーを付ける目的でのみ使われて一時的に保持され、プロセス完了後にすべて破棄されると書かれている。加えて、複数のオーディオ ファイル間で一意の話者を追跡する機能はサポートされていないと明記されている（出典）。
Q. 日本のサーバーで処理させることはできるのか。 A. OpenAIのdata residencyの表では、Japanは保存（Regional storage）がYes、処理（Regional processing）がNoと書かれている。音声の3エンドポイントの処理リージョンは United States と Europe（EEA＋スイス）と記載されている（出典）。
Q. あとから消してもらうことはできるのか。 A. 部品側には手段が書かれている。グーグルはログされたデータについて削除リクエストのフォームを案内し、マイクロソフトはバッチの出力について削除APIか timeToLive を挙げている。OpenAIはZero Data Retentionなどの制御を組織・プロジェクト単位で設定できると書いている。いずれも操作するのはアプリを作っている側になる。
まとめ｜AI英会話のデータは「既定値」と「どの部品を呼ぶか」で決まる
もう一度整理する。
- マイクロソフトは、リアルタイム音声テキスト変換・高速文字起こし・発音評価・音声翻訳について「保持または格納しません」と書き、リアルタイムはサーバー メモリでのみ処理すると明記している。バッチだけは顧客がストレージを指定する。
- グーグルは「既定ではログしない」と書き、ログするのはオプトインした場合に限定している。ただしログ済みデータはプロジェクトを消しても消えないと注意書きがある。
- OpenAIは学習利用を否定したうえで、不正利用監視ログを既定で最大30日保持すると書いている。音声の文字起こしと音声翻訳だけは、その保持が「None」になっている。
- 置かれる場所は、保存と処理が別々に決まる。OpenAIの表ではJapanは保存のみ対応で、音声の処理は United States と Europe に限られている。
- 切り替えの重さは3社で違う。グーグルはオプトインのスイッチ、OpenAIは事前承認が要る申請制、マイクロソフトは機能そのものの選択で決まる。
⇒ 3社に共通しているのは、「何をどれだけ残すか」を書いたうえで、止める手段も同じページに書いていることだ。
だから利用者の側で見るべきなのは、漠然とした安全か危険かではなく、使っているアプリがどの部品を、どの設定で呼んでいるかになる。
そしてそれは、履歴画面の有無・発音採点の有無・削除導線の有無という、アプリの表側からでもかなりの部分が読み取れる。
※本記事の一次ソースはすべて2026-09-11に各公式ドキュメントで確認した。仕様は更新されるため、最新は各公式ドキュメントで確認してほしい。
Comments