AI英会話の文字起こしに、いきなりアスタリスクの並んだ伏せ字が出ることがある。
自分では普通に話したつもりなのに、そこだけ記号で潰されている。
多くの人はこれを「発音が崩れて認識できなかった跡」だと受け取る。
しかし仕様上、伏せ字は認識に失敗したときの表示ではない。
認識には成功していて、そのうえで出さないと決めた語に掛かるのが伏せ字だ。
この処理には設定項目があり、既定値があり、利用者側では切れない部分がある。
この記事では、音声認識の部品を売っている会社の開発者向けドキュメントの記述だけを材料にして、伏せ字が何をどう隠しているのかを分解する。
サービスの順位づけはしない。仕組みの話だけをする。
【結論】AI英会話の伏せ字は、聞き取れなかった印ではなく「不適切表現フィルター」の出力である
先に答えを置く。
音声テキスト変換には、不適切表現フィルターという独立した機能が用意されている。
マイクロソフトの公式ドキュメントによれば、書き起こしの最終出力に現れる不適切な表現を、伏せるのか・取り除くのか・そのまま見せるのかは、開発者が3択で指定できる。
| 状態 | ドキュメントでの説明 |
|---|---|
| Masked | 不適切な言葉の文字を、アスタリスク（*）文字に置き換える。既定のオプション |
| Raw | 不適切な言葉をそのとおりに含める |
| Removed | 不適切な言葉を削除する |
3つのうち、既定で選ばれているのは Masked である。
⇒ サービス側が何も指定しなかった場合、伏せ字が出るほうが標準の挙動になる。
出典は音声テキスト変換での表示テキストの書式設定（Microsoft Learn）で、この3択はページ内の「不適切表現フィルター」の項に並んでいる。
AI英会話の伏せ字①｜マスクは「消す」ではなく「感情を残したまま隠す」処理だ
マスクと削除は、似ているようで設計思想が違う。
同じドキュメントがマスクについて述べているのは、対象の語をアスタリスクの文字へ差し替えることで、場面にそぐわない言い方をやわらげつつ、元の文が帯びていた感情（センチメント）のほうは残せる、という趣旨だ。
つまりマスクは、そこに強い言葉があったという事実を残す設計だ。
削除（Removed）を選ぶと、その痕跡ごと文から消える。
学習の場面で言えば、伏せ字が出る設定のサービスは「何かを言ったが出せない」ことを利用者に知らせる側に寄っている。
削除の設定のサービスでは、自分の発話の一部が黙って落ちる。
- 伏せ字が出た＝その語は認識され、そのうえで置き換えられた。
- 何も出なかった＝聞き取れなかったのか、削除されたのかを画面から区別できない。
- そのまま出た＝Raw が選ばれているか、フィルターの対象語ではなかった。
⇒ 画面に何も出ないことのほうが、判断材料としては厄介である。
AI英会話の伏せ字②｜グーグルは「頭文字1文字＋アスタリスク」で返す
伏せ字の見た目は、提供元によって違う。
グーグルの Cloud Speech-to-Text は、profanity filter について次のように書いている。
profanityFilter=trueをRecognitionFeaturesに設定すると有効になる。- 有効なとき、不適切語を検出し、最初の1文字だけを残してあとをアスタリスクにして返す。ドキュメントが挙げている表記例は
f***である。 - このフィールドが false または未設定なら、フィルターを試みない。
ここがマイクロソフト側と対照的だ。
グーグルの既定は「フィルターしない」で、マイクロソフトの既定は「マスクする」と書かれている。
なお、こうした認識機能をオンにする場所は、グーグル側ではSpeech-to-Text basics（Google Cloud）が説明するとおり、リクエストの認識構成の中である。
| 比べる点 | Microsoft の記述 | Google の記述 |
|---|---|---|
| 設定名 | 不適切表現フィルター（Masked / Raw / Removed） | profanityFilter（true / false） |
| 既定 | Masked が既定のオプション | false または未設定ならフィルターしない |
| 伏せ字の形 | 不適切な言葉の文字をアスタリスク文字に置き換える | 最初の1文字＋アスタリスク（例 f***） |
| 削除の選択肢 | Removed が用意されている | true/false の2択として説明されている |
同じ「伏せ字」でも、頭文字が残るかどうかで読み手に渡る情報量が変わる。
仕様はEnable profanity filtering（Google Cloud）に書かれている。
AI英会話の伏せ字③｜設定をオフにしても、返ってこない語がある
この記事でいちばん重要な一文は、マイクロソフトのページの注記にある。
そこには、マイクロソフトも不適切と見なされる単語をマスクまたは削除する権利を持っている、と書かれている。
続けて、そうした語は、フィルターをオンにしていてもオフにしていても、音声サービスの側からそもそも返ってこない、と書かれている。
フィルターを Raw にしても、素通しになるわけではないという意味だ。
これは、サービス提供者が設定で外せる層と、提供者にも外せない層が二重にあることを示している。
| 層 | 誰が決めるか | 利用者から見た挙動 |
|---|---|---|
| 組み込みの非返却 | 提供元（設定に関係なく返さない） | どの設定でも画面に出ない |
| 不適切表現フィルター | サービス開発者（Masked / Raw / Removed） | 伏せ字・そのまま・欠落のいずれかになる |
| カスタムの追加リスト | サービス開発者（独自に単語を追加） | サービスごとに伏せ字の範囲が違う |
⇒ 「このAI英会話は伏せ字が出ない」と感じても、それは何も隠していないという意味にはならない。
AI英会話の伏せ字④｜同じ結果の中に、伏せ字が掛かる欄と掛からない欄がある
音声認識の結果は、1つの文字列ではなく複数のプロパティで返る。
マイクロソフトのドキュメントは、フィルターがどこに効くかを明示している。
- 不適切表現フィルターが効く先は、結果のうち
TextとMaskedNormalizedFormという2つのプロパティである。 LexicalFormおよびNormalizedFormプロパティには適用されない。- どちらのフィルターも単語レベルの結果には適用されない。
つまり、画面に伏せ字が出ていても、伏せ字になっていない同じ発話の別バージョンが同時に返っている。
ここは学習者にとって、2つの意味を持つ。
1つは、伏せ字は表示上の加工であって、認識そのものが止まったわけではないということ。
もう1つは、画面に見えている形とサービス内部で扱われている形は、必ずしも同じではないということだ。
発音採点やフィードバックが伏せ字の語にも付くことがあるのは、この構造で説明がつく。
AI英会話の伏せ字⑤｜サービス側は独自の伏せ字リストを足せる
伏せ字の範囲は、提供元が決めた語彙だけで固定されているわけではない。
マイクロソフトのカスタム音声認識には、表示フォーマットを自分で定義する仕組みがある。
そのファイルの #profanity セクションは、組み込みの不適切表現リストに加えて、表示およびマスク出力からマスクする不要な単語のリストだと説明されている。
| セクション | 用途 | 上限 |
|---|---|---|
| #ITN | 数値・住所・日付などの表示パターン | 最大200行 |
| #rewrite | 大文字化やスペル修正の書き換えペア | 最大1,000行 |
| #profanity | マスクする不要な単語のリスト | 最大1,000行 |
| #test | 表示ルールの単体テスト | 最大10MBのファイル |
ドキュメントに載っているテストケースの例が、挙動をそのまま示している。
入力の Mask the fakeprofanity word に対して、期待される表示出力は Mask the ************* word と書かれている。
アスタリスクの本数は13本で、伏せられた単語 fakeprofanity の文字数と一致する。
頭文字も残らず、長さだけが残る形だ。
⇒ 同じ英語を話しても、どのサービスを使うかで伏せ字の範囲と形が変わる。伏せ字は英語そのものの性質ではなく、設定の写しである。
仕様はカスタム音声認識のテストとトレーニングのデータ（Microsoft Learn）に書かれている。
AI英会話の伏せ字⑥｜字幕として出すときにも同じ選択肢が現れる
伏せ字の話は、リアルタイムの字幕表示にもそのまま持ち込まれている。
マイクロソフトのキャプション付けのドキュメントには、不適切な言葉フィルターのオプションが用意されており、不適切な単語をマスク、削除、または表示するかどうかを指定できると書かれている。
同じページは、コマンドラインの例として --profanity masked のような指定も示している。
AI英会話の画面下に出る字幕は、この設定を通ったあとの文字列だ。
さらに字幕には、句読点をめぐる別の制約も掛かっている。
同じドキュメントは、部分的な結果の句読点は使用できないと明記している。
⇒ 話している最中の字幕と、話し終わったあとの字幕は、別の加工を通った別物として読むほうが正確だ。
出典はキャプション付けの概要（Microsoft Learn）。
AI英会話の伏せ字と、返事を作る側のフィルターは別物である
ここまでの話は、すべて「あなたの音声を文字にする部品」の中で起きている。
AI英会話にはもう1つ、返事を作る言語モデルの部品があり、そちらには別系統の安全装置が置かれている。
OpenAI の安全に関するドキュメントは、開発者向けの推奨事項を並べている。
- Moderation API は無料で使えるものとして案内されており、生成結果に含まれる安全でない内容の頻度を下げる助けになると書かれている。
- 敵対的なテスト、いわゆるレッドチーミングを行い、想定外の入力に耐えるか確かめることが推奨されている。
- 可能な限り、出力が実際に使われる前に人間が確認する体制を持つことが勧められている。
- 入力できる文字数や出力トークン数を制限することが、悪用の抑制として挙げられている。
- 利用者が問題を報告できる手段を用意し、それを人間が監視することも挙げられている。
音声側の伏せ字が「文字の置き換え」なのに対し、こちらは「何を返すか」の設計である。
だから、AIが急に話題を避けたり、当たり障りのない返答に切り替わったりする現象は、伏せ字とは別の層で起きている。
2つを混ぜて「このAIは検閲が厳しい」と一括りにすると、原因の切り分けができなくなる。
推奨事項の一覧はSafety best practices（OpenAI Platform）にある。
AI英会話で伏せ字が出たとき、学習者が確認すべきこと
仕様を、使う側の行動に落とすとこうなる。
- 伏せ字を発音ミスの証拠として受け取らない。認識は通ったうえでの置き換えである。
- 伏せ字の形を見る。頭文字が1つ残っているか、長さだけが残っているかで、どちら系の仕組みかの見当がつく。
- 伏せ字が出ないことを「何も弾かれていない」と読み替えない。設定に関係なく返さない語があると明記されている。
- 単語が丸ごと欠けているときは、聞き取り失敗と削除設定の両方を疑う。
- 返事の内容が変わったのか、文字起こしが変わったのかを分けて見る。担当している部品が違う。
スラングや口語をわざと試したい学習者ほど、この区別は効いてくる。
映画やドラマで拾った表現が画面で潰れても、それが通じない英語だという判定にはならないからだ。
判定しているのは語彙の妥当性ではなく、出力してよいかどうかの方針である。
AI英会話の伏せ字についてよくある質問
ここまでで触れきれなかった点を、質問の形で並べる。
Q. 伏せ字は自分の発音が悪いから出るのか。 A. 仕様上は違う。不適切表現フィルターは、認識された語に対してマスク・削除・そのまま表示のいずれかを適用する機能として説明されている。
Q. 設定で伏せ字を全部オフにできるのか。 A. サービス開発者はフィルターを Raw に設定できる。ただしマイクロソフトは、不適切と見なされる単語をフィルター処理の有効無効にかかわらず返さない場合があると注記している。
Q. アスタリスクの本数に意味はあるのか。 A. マイクロソフトのカスタム表示フォーマットの例では、fakeprofanity という13文字の語が13本のアスタリスクに置き換わっている。グーグルの説明では、最初の1文字を残して以降をアスタリスクにすると書かれている。
Q. 伏せ字になった語も採点の対象になるのか。 A. フィルターが適用されるのは Text と MaskedNormalizedForm で、LexicalForm と NormalizedForm には適用されず、単語レベルの結果にも適用されないと書かれている。
Q. サービスによって伏せられる語が違うのはなぜか。 A. カスタム表示フォーマットの #profanity セクションで、組み込みのリストに独自の単語を最大1,000行まで追加できるからだ。
まとめ｜AI英会話の伏せ字は、英語の評価ではなく出力方針の表示である
この記事で分解したことを5点に整理する。
- 伏せ字は認識失敗の跡ではなく、不適切表現フィルターがマスクを選んだ結果である。
- マイクロソフトは Masked・Raw・Removed の3択で、Masked が既定と書かれている。グーグルは true/false で、未設定ならフィルターしないと書かれている。
- フィルターを切っても返らない語があると明記されており、設定で外せない層が存在する。
- フィルターは
TextとMaskedNormalizedFormに効き、字句形式や単語レベルの結果には効かない。 - サービス側は独自の単語を最大1,000行まで足せるため、伏せ字の範囲はサービスごとに違う。
伏せ字を見たときに問うべきは「自分の英語が間違っていたか」ではなく「どの層が、どの方針で隠したか」だ。
そこを分けて読めれば、画面の記号に学習の判断を引きずられずに済む。
※本記事の一次ソースは、各公式ドキュメントを2026-09-16および2026-09-18に取得した生テキストで確認した。仕様は更新されるため、最新は各公式ドキュメントで確認してほしい。
Comments