【ITニュース解説】When the engine's phoneme and the course IPA disagree

ITシステム開発では、一見すると些細な問題がシステムの根本的な設計に関わる大きな課題へと発展することが少なくない。今回解説する英語スピーキング練習アプリの事例は、まさにその典型的な例だ。このアプリは、ユーザーが英語の単語を発音すると、その発音を評価し、どの音が正しく、どこが違ったかを詳細にフィードバックする機能を提供している。しかしある時、ユーザーから「cause（原因）」という単語の発音について、アプリが表示するIPA（国際音声記号、発音を正確に表すための世界共通の記号）が間違っているという指摘が寄せられたのだ。

このアプリでは、ユーザーが単語を録音した後、Microsoft Azureの発音評価サービスを利用して発音スコアを算出していた。そして、アプリの画面上には、「コースが学習者に教えたい正しい発音の音」と、「ユーザーが実際に発音したとAzureが判断した音」の両方が表示される仕組みだった。問題は「cause」という単語で浮上した。アプリのコースが教える「cause」のIPAは /kɑːz/ で、これは口を大きく開く「ah」のような母音を表す。しかし、ユーザーが発音した「cause」をAzureが評価すると、内部的には「ao」という独自の音素（Azureの発音評価エンジンが内部で使うSAPIという音素セットの一つ）で認識し、アプリはこれを /ɔ/、つまり口を丸める「oh」のような母音として画面に表示してしまっていた。結果として、同じ画面にアプリが教えるべき /kɑːz/ と、ユーザーの発音として認識された /ɔ/ が同時に表示されることになり、学習者にとってはアプリ自身が矛盾した情報を提示しているように見えてしまい、混乱を招いたのである。

この問題に対し、開発チームはいくつかの解決策を検討したが、それらの多くは後に「間違った修正」だと判明した。 まず一つ目の「間違った修正」は、アプリが持つ単語の辞書データを変更することだった。「cause」の発音として /kɔːz/ を採用している辞書も多数存在するため、アプリの辞書もこれに合わせれば問題解決になるのではないかと考えたのだ。しかし、このアプリは「General American」という特定のアメリカ英語アクセントを教える方針であり、そのアクセントでは「cot」の母音と「caught」の母音の区別がない「cot–caught merger」という現象があるため、「law」「thought」「caught」「cause」といった単語はすべて /ɑː/ の音として教えるべきだと定めていた。もし「cause」のIPAを /kɔːz/ に変更してしまうと、一箇所の修正で他の単語との一貫性が失われ、アプリ全体の教育方針が崩れてしまうため、この方法は採用できなかった。

次に二つ目の「間違った修正」は、Azureの発音評価エンジンが誤ってユーザーの音を聞き間違えたのではないかと疑うことだった。しかし、これは原因ではなかった。Azureは先述のSAPIという独自の音素セットで発音を評価し、SAPIでは「ao」は /ɔ/ を、 「aa」は /ɑ/ を表す。Azureは「cause」という単語に対して、「k ao z」という発音を期待することが多かった。ユーザーがその「ao」に近い音を発音した場合、Azureは良いスコアを与えつつ、その母音を「ao」とラベル付けする。アプリ側はAzureから受け取った「ao」を画面表示のために /ɔ/ に変換し、これに合うヒントを添えていたのだ。つまり、Azure自身の評価は正しく、問題はAzureの評価結果を「アプリが教えるべき音」としてそのまま表示してしまったことにあると判明した。システムが内部で使う記号と、学習者に見せる記号の区別ができていなかったのだ。

三つ目の「間違った修正」は、Azureが認識するすべての「ao」を、アプリが教える /ɑː/ の音として一括で再マッピングするというものだ。これはrの音を伴わない「thought」の母音（/ɑː/）に似ているため、一見有効に思えた。しかし、この考え方もすぐに破綻した。「more」という単語では、Azure側では「m ao r」と認識されるが、これはアプリが教える /mɔːr/ の「oh」と丸める母音だ。ここで「ao」を /ɑː/ に変換してしまうと間違った音になってしまう。また、「school」の発音がユーザーの録音によって「s k ao l」と認識されるような場合もあり、これらの「ao」が常にターゲットの /ɑː/ を意味するわけではない。SAPIの音素とアプリが教えるIPAを1対1でマッピングしようとすると、音の統合、rの音を伴う母音（rhotic vowels）、そして実際にユーザーが発した多様な音を同時に正確に表現することは不可能だった。さらに、この変換テーブルを変更すると、他の多くの表示機能にも影響が出てしまうため、この方法も断念せざるを得なかった。

これらの試行錯誤を経て、開発チームは根本的な解決策を見出した。それは、「発音評価エンジン」と「コースが学習者に教えるべきシンボル（記号）」の役割を明確に分離するという原則だ。具体的には、アプリの表示部分で「コースが学習者に教えたいIPA」のみをターゲットとして表示することを決定した。Azureは引き続き、単語全体のスコア計算、個々の文字の色付け、そして「ユーザーが実際にどのような音を発したか」という推測を提供する役割に徹することになった。

新しい表示ルールは以下の通りだ。 もしAzureが期待する音素が、アプリが教えるIPAの音（例えば /ɑː/ はAzureの「aa」と「ao」の両方を許容するなど、コースの音素定義に照らして許容範囲内と判断できる場合）と一致すると判断できる場合、アプリは教えるべきIPA記号を表示し、Azureの正確度スコアも表示する。 もしAzureが期待する音素が、アプリが教えるIPAの音とは異なる場合、アプリは教えるべきIPA記号はそのまま表示するが、Azureのスコアは非表示にする。その代わりに「この音は一致しません」というメッセージと、「あなたの録音は（アプリが教えるIPAで表現された）〇〇のように聞こえました」という情報を添える。 さらに、ユーザーの録音が非常に品質が低い場合（例えば、IPAが全く認識できない、または3つ以上の音素の正確度がゼロだった場合）は、個々の音素について細かく説明しようとせず、シンプルに「特定の音を指摘できません」と表示し、ユーザーにモデル音声と自分の録音を再生して比較するよう促す。 この変更では、Azureへのリクエスト方法や、アプリが保存するスコア、Azureが特定したSAPIのエラー音素といった基盤となる部分は変更しなかった。文字単位の色付けは引き続きAzureの評価に従い、アプリ内のコーチキャラクターも、コースが教える正しいIPA（「cause」なら /ɑː/）に基づいてフィードバックを行うようになった。

この設計が本当に機能するかどうかを検証するために、開発チームは重要な一歩を踏み出した。それは、架空の例ではなく、過去の実際のユーザーの発音データ（Azureから返されたJSONデータ）を大量に引っ張り出し、それぞれの単語に対する「iscommon US IPA」（アプリが教える一般的なアメリカ英語のIPA）を付与して、新旧の表示を比較するHTMLシートを生成したことだ。偽のサンプルデータでは問題なく見えても、実際のデータでは様々な予期せぬ問題が露呈した。 例えば、アプリが教えるIPAの選定ミスがあった。システムが辞書から複数の品詞の発音を抽出し、その中で最も長い文字列を選んでしまうような誤りがあり、本来教えるべきではない発音がターゲットとして表示されることがあった。 また、音素のアライメント（音と音の対応付け）にも問題が見つかった。「believe」という単語の「-lieve」の部分で、アプリが教えるIPAでは /ɪ/ と /iː/ のように異なる音が続く場合、Azureの音素を強引に一致させようとして、本来一致すべき /ɪ/ の部分を不一致と表示してしまうことがあった。 語尾の母音の扱いも課題だった。「sorry」のような単語の語尾の /i/ は、Azureの「iy」と一致する必要があるが、単純なマッピングでは見落とされ、不一致と表示される問題が発生した。 さらに、シュワ（曖昧母音）とRの音が結合した /ɚ/ や /ɝː/ のような音は、アプリでは一つの音として教えるべきだが、Azureのデータでは二つの音として扱われることがあり、表示行が不自然になるケースもあった。 そして、録音品質が極端に悪い（例えば「water」や「person」の発音がすべて正確度ゼロと判定されるような）場合には、無理に個々の音素を対応付けようとすると、全く意味不明な結果が表示されてしまうことも判明した。これらのケースでは、単に不一致メッセージを表示する「フォールバック」の仕組みを適用することになった。 これらの実際のサンプルからの学びは、画面に表示される中国語のヒントメッセージの再考にもつながった。「〜のように聞こえます」という表現は、それがユーザーの発音に対するフィードバックであることを明確にし、混乱を避けるために変更された。

この新しいシステムを本番環境に導入する際、最も大きなリスクとされたのは、音素のインデックスの再マッピングだった。Azureは独自の音素に基づいて文字の色付けを行うため、アプリ側でいくつかの音素をまとめて一つの表示行にするとき（例えば「ax r」を一つの /ɚ/ として扱うとき）は、表示される行の数がAzureが持つ音素のリストよりも短くなる。この状態でユーザーが特定の文字をタップすると、そのタップ位置に対応する音素のインデックスがずれてしまい、間違った音素の情報が開いてしまう可能性があった。この問題を解決するため、インデックスの調整ロジックを慎重に実装する必要があった。 また、一部の頻出単語（are, been, got, was, were, wonなど）については、アプリのデータに「iscommon POS」（一般的な品詞）が設定されていないため、現状ではこれらの単語を練習すると、一致しないというメッセージが表示されてしまう。これはマッピングの問題ではなく、辞書データの整備という別の課題として認識されている。

この経験から得られる最も重要な教訓は、発音評価のような複雑なシステムを構築する際には、「評価エンジンが何をし、コースが何を教えるか」という役割を明確に分離することの重要性だ。評価エンジンは技術的な正確さでスコアを計算するが、学習者に提示するシンボルや情報は、教育的な基準に基づいてコース側が決定すべきである。両者の間にある変換テーブルは、あくまで表示上の便宜のためのものであり、教育の標準そのものを歪めてはならない。表示のロジックを変更することは許容されることが多いが、システムの根幹をなすスコアリングの仕組みや、すでに保存されているユーザーの練習データに変更を加えるべきではない。 そして、理論的なマッピングテーブルだけでは発見できないような、実際のユーザーによる様々な「誤認識」のケースを、本物のデータを使って徹底的に検証することが不可欠だ。例えば、「school」が「ao」と認識されるケースや、「one」が /ʌ/ ではなく「aa」と認識されるケース、「the」が /ə/ ではなく「iy」と認識されるケースなど、これらは実際のユーザーの多様な発音を反映しており、システムはこれらの予期せぬ状況にも対応できるように設計されていなければならない。これらの経験が、単一のユーザーのスクリーンショットからの指摘だけでなく、システム全体の堅牢性を高める上で非常に重要な役割を果たしたと言えるだろう。