茶まみれ

こんにちは。茶まみれです。

2026 年 5 月、AmiVoice API に新しいリクエストパラメータとして
「confidenceLevel」「completeTimeout」「wildcardModelPenalty」の３つが追加されました。

この３つは、特にルールグラマ用エンジンを使う場合に活躍するパラメータです。
今回はこれらのパラメータについて紹介をします。
なお、パラメータの使い方についてはマニュアルを参照してください。

そもそもルールグラマって？

AmiVoice API をご利用いただいているユーザーの中でも、ルールグラマやルールグラマ用エンジンはご存じない、という方もいらっしゃるのではないでしょうか。

このエンジンは、AmiVoice API Private にてご利用いただける特殊なエンジンで、ユーザーが事前に設定した文法（ルール）に従う表現だけを認識させるようにすることができるものです。

たとえば飲食店でのオーダーの発話を想像してみてください。

「塩ラーメン１つ、醤油ラーメン２つ、五目チャーハン１つ、餃子２つ、ウーロン茶３つ。以上でお願いします」

この発話の場合、主要な部分は「<メニュー名> <個数>」の任意の回数の繰り返しで構成されています。また、<メニュー名>には、その店舗で提供しているメニューの名前のみが当てはまり、発話される単語の候補が限られることが想像されます。

このように、発話の法則性（<メニュー名> <個数>）や使用する単語（<メニュー名>の個々の単語、<個数>で使用する数字や数詞）が決まっている場合に、予めそれを指定したルールグラマを作成することで、その内容に沿った表現の発話だけを認識させることができます。

たとえばメニュー名の中に「ピザ」を含まずにルールグラマを作成すれば、「ピザ１つ」という認識結果は出て来ません。また、「明日は９時集合」などのルールと全く異なる発話も認識されません。

ルールグラマによる認識については、マニュアル（ルールグラマ | AmiVoice API マニュアル | AmiVoice Cloud Platform）の他、このテックブログでも詳しくご紹介していますので、よろしければこちらもご覧ください。

信頼度しきい値：confidenceLevel

AmiVoice API の返却する認識結果には、「confidence（信頼度）」という情報が含まれています。これは、音声認識エンジンが、その部分の認識結果をどの程度確からしいと考えたかを表す数値です。値は ０～１の数値をとり、１に近づくほど、より認識結果が確からしい、ということになります。信頼度は、単語単位および発話区間単位の結果にそれぞれ出力されます。

「confidenceLevel」は、発話区間単位での信頼度について、最低値のボーダーラインを指定することができるパラメータです。このパラメータを用いると、信頼度の値が指定した値よりも小さい発話区間については、認識結果がリジェクトされます。つまり、音声認識エンジン自身が結果に自信が無いような認識結果をリジェクトすることができるというわけです。デフォルトでは 0.1 に設定されているため、かなり信頼度の低い、怪しい認識結果でないとリジェクトされません。

このパラメータ自体は、ルールグラマ用エンジン以外の音声認識エンジンを使う場合にも適用できるものです。
たとえば、著しく雑音が多い音声や音量が小さすぎる音声など、音声認識が難しい音声の場合、信頼度の値が低くなりやすく、認識結果の精度もあまり良くなりません。このような音声の音声認識処理に対して「confidenceLevel」を用いると、ユーザーが指定した値よりも「confidence」が小さくなる発話区間は結果がリジェクトされます。

ルールグラマ用エンジンにおいても、「confidenceLevel」を指定すると同様の振る舞いをするようになります。
たとえば、冒頭にあげた飲食店のオーダーの発話を認識させるためのルールグラマを使って音声認識をしてみましょう。ルールは、「<メニュー名> [を] <個数>」というものです。<メニュー名>には塩ラーメン、醤油ラーメン、五目チャーハン、餃子、ウーロン茶が、<個数>には「一つ、二つ、……九つ」および「一個、二個、……九個」が入り、[を] は０または１回入る、とします。

#JSGF V1.0 UTF-8;
grammar order;

public <order> = <item> [を] <count>;

public <item> = ( 醤油ラーメン\らーめん/しょうゆらーめん {shoyu}
                | 塩ラーメン\しおらーめん {sio}
                | 五目チャーハン\ごもくちゃーはん/ちゃーはん {chahan}
                | 餃子\ぎょうざ {gyoza}
                | ウーロン茶\うーろんちゃ {oolong}
                );

<count> = ( 一つ\ひとつ {1} | 二つ\ふたつ {2} | 三つ\みっつ {3} | 四つ\よっつ {4} | 五つ\いつつ {5}
          | 六つ\むっつ {6} | 七つ\ななつ {7} | 八つ\やっつ {8} | 九つ\ここのつ {9}
          | 一個\いっこ {1} | 二個\にこ {2}   | 三個\さんこ {3} | 四個\よんこ {4} | 五個\ごこ {5}
          | 六個\ろっこ {6} | 七個\ななこ {7} | 八個\はっこ {8} | 九個\きゅーこ {9}
          );

ここで「行田お散歩（ぎょうだおさんぽ）」という発話を認識させてみます。
デフォルトで、つまり「confidenceLevel=0.1」で認識させてみると、「餃子を三個」と認識されました。次に、「confidenceLevel=0.6」と指定して認識させてみると、信頼度がしきい値を下回ったとしてリジェクトされました。

一方、同じ「行田お散歩」という音声を、会話_汎用エンジン（-a-general）で認識させると、「行田お散歩」と認識され、「confidenceLevel」を 0.9 まで上げてもリジェクトされませんでした。つまりこの「行田お散歩」という認識結果は、音声認識エンジンとしても自信のあるものだったのです。

会話_汎用エンジンのように、ルールグラマを使わない音声認識エンジン（ディクテーションによる認識を行うエンジン）では、入力された音声に対し、多くの候補の中から確からしいものが選択され、認識結果として出力されます。もしかたら「行田お散歩」の発話に対する認識の候補の中には「餃子を三個」もあったかもしれませんが、それら候補の中で「行田お散歩」の確率が高いと判断されて認識結果として出力されたわけですから、信頼度は高くなりやすいです。

一方、ルールグラマを用いた音声認識の場合、予め決められたルールの範囲内という限定された中から認識結果が選ばれます。もちろん、このルールに当てはまらない発話だと判断されれば、認識結果が出力されませんが、「行田お散歩」のように、ルールに当てはまる発話とやや似ている発話の場合、低い信頼度で認識結果として出力される可能性があります。このような場合に、「confidenceLevel」を使ってしきい値を指定することで、間違っている可能性が高そうな認識結果をリジェクトする、ということが可能になります。
ただし、認識結果が正しくないのに「confidence」がそこまで低くならないこともあれば、認識結果はちゃんと正しいのに「confidence」が低い値となる、ということもあります。様子を見ながらバランス調整をし、場合によってはルールのほうも読みの調整などの見直しをしてみると良いでしょう。

余談ですが、餃子……ではなく、埼玉県行田市には、古代蓮の里や埼玉古墳群、石田三成の水攻めで有名な忍城址など、歴史ロマンあふれるスポットがあります。気候の良いシーズンに観光などいかがでしょうか。

ワイルドカードペナルティ：wildcardModelPenalty

こちらはルールグラマ用のエンジンでのみ有効なパラメータです。

ルールグラマの中で使える特殊なルール名に「<GARBAGE>」というものがあります。これは、どんな発話にも合致することを意味する特殊ルールで、発話のうち <GARBAGE> であると判断された部分は、認識結果として出力されません。
たとえば「<GARBAGE> <num> <GARBAGE>」とし、<num> には１から９の数字が一つ入る、というルールを作成したとします。これを用いて「それは２です」という発話を認識させると、「それは」と「です」がそれぞれ <GARBAGE> と認識されて、「２」のみが認識結果として出力されます。

「wildcardModelPenalty」は、この <GARBAGE> のあるルールグラマを用いて音声認識を行う際に、発話がどの程度 <GARBAGE> と認識されやすくなるかを指定するパラメータです。指定可能な範囲はおおよそ 2.0～6.0 で、値が小さいほど <GARBAGE> と認識されやすく、大きいほど <GARBAGE> 以外のものとして認識されやすくなります。

例として、１～９の数字と、S、M、L の３つのアルファベットを認識させるルールグラマを用意します。以下のように、英数字は何桁続いてもよく、末尾には <GARBAGE> が０回以上（<GARBAGE> があるかもしれないし、なくてもよい）とします。

#JSGF V1.0 UTF-8;
grammar Alphanumeric;
public <alphanumeric> = <alnum>+ <GARBAGE>*;
<alnum> = １\いち {1} | ２\に/にー {2} | ３\さん {3} | ４\よん/し/しー {4} 
        | ５\ご {5} | ６\ろく {6} | ７\なな/しち {7} | ８\はち {8} 
        | ９\きゅー/く/くー {9} | ０\ぜろ/れー/まる {0} 
        | S\えす {s} | M\えむ {m} | L\える {l};

これを使って、「１２３４です」という発話を認識させてみます。
まず「wildcardModelPenalty=2.0」として認識させてみると、認識結果は「1234」となりました。つまり、「です」は <GARBAGE> と認識された、ということです。
次に「wildcardModelPenalty=4.0」と数字を大きくして、すなわち、<GARBAGE> 以外のものとして認識されやすいように設定して認識させてみると、認識結果は「1234S」となりました。この場合、「です」が <GARBAGE> ではなく「S（えす）」と認識された、ということです。

<GARBAGE> は語尾のように発話パターンを事前に把握しきれず、かつ認識結果には不要な発話を処理するのに便利なルールです。しかし、「なんでもあり」であるがゆえに、本当は認識結果として出力してほしかった部分まで <GARBAGE> として処理されてしまう可能性がありますし、逆に本当は <GARBAGE> で処理してほしかった部分がそれ以外として出力されてしまう可能性もあります。「wildcardModelPenalty」を使うことで、その加減を調整することができるようになります。

確定待ちタイムアウト：completeTimeout

こちらもルールグラマ用のエンジンでのみ有効なパラメータです。

ある発話区間の音声認識処理を行っている最中に、それまでに得られた認識結果が、ルールグラマから期待される認識結果の条件に既に合致している場合に、次の発話入力があるのを待つ時間の長さをミリ秒単位で指定することができるものです。
つまり、発話区間の途中まで処理をした段階で、既にルールグラマにマッチする認識結果が得られている時、次の発話が一定時間（completeTimeout）の間に始まらなければ、その時点でその発話区間の処理を切り上げて認識結果を確定してしまう、ということを可能とします。

例として、「はい/いいえ」を認識させるルールグラマを用意します。以下のように、認識させるのは「はい」か「いいえ」という発話であるとし、「はい/いいえ」の後に何か発話が続いても構わない（<GARBAGE>*）とします。

#JSGF V1.0 UTF-8;
grammar Yesno;
public <yesno> = <yesorno> <GARBAGE>*;
<yesorno> = はい\はい {yes} | いいえ\いいえ {no};

これを使って、「はい、ええ、まあ、そうです、はい……」と、「はい」の後にだらだらとしゃべり続けるような音声を WebSocket インタフェースで、少しずつ音声を送るようにして認識させてみます。だらだらとしゃべり続ける部分は <GARBAGE> となって認識結果は「はい」のみとなる、と見込まれる音声認識です。
この音声では、発話区間の検出プロセスにおいて、約 6.2 秒間の発話区間が検出されました。
また、「resultUpdateInterval=500」（0.5秒に１回認識の途中結果を送信）と設定し、認識の経過を細かく見られるようにしました。

まず「completeTimeout=10000」（10秒）で認識させてみると、認識結果が「はい」と確定して A イベントが送られてくるまでに、途中結果の U イベントは全部で 12 回送られてきました。このうち、最初の１回以外は全て、認識の途中結果は「はい」となっていました。また、音声認識開始を示す C イベントが送られてきてから A イベントが送られてくるまでに、約６秒かかりました。そして、A イベントが送られてきたのは、発話区間の終端の検出された通知である E イベントが送られた後でした。

次に「completeTimeout=200」（0.2秒）で認識させてみると、認識結果が「はい」と確定して A イベントが送られてくるまでに、途中結果の U イベントが送られてきたのは２回だけでした。このうち、２回目の U イベントでは、認識の途中結果は「はい」となっていました。また、音声認識開始を示す C イベントが送られてきてから A イベントが送られてくるまでにかかった時間は、約 1.5 秒であり、E イベントよりも先に A イベントが送られてきました。
つまり、この発話区間の処理の途中で「はい」という、ルールグラマに合致する認識結果が得られたため、その後は 0.2 秒次の発話が無ければタイムアウトする、という判定が行われるようになり、そしてタイムアウトが発動したため、発話区間の終端が検出されるよりも先に、この発話区間の認識結果が確定された、ということです。

このように、「completeTimeout」を短く設定することで、同じ発話区間内で発話が続いていても、ルールに当てはまる認識結果が得られていれば、早くに認識結果を確定させることができます。

もう一つ違うパターンも試してみます。今度は、２桁以上の数字を認識させるルールです。桁数は２桁以上であれば上限はありません。

#JSGF V1.0 UTF-8;
grammar Numbers;
public <number> = <num> <num>+;
<num> = １\いち {1} | ２\に/にー {2} | ３\さん {3} | ４\よん/し/しー {4} 
      | ５\ご {5} | ６\ろく {6} | ７\なな/しち {7} | ８\はち {8} 
      | ９\きゅー/く/くー {9} | ０\ぜろ/れー/まる {0};

これを使って、「１、２、３、４、５、６、７、８、９」と、短く区切りながら数字を読み上げる音声を認識させてみます。

まず「completeTimeout=10000」（10秒）で認識させてみると、認識結果は「123456789」となりました。つまり、発話区間の最後まで認識が行われた、ということです。

次に「completeTimeout=200」（0.2秒）として認識させてみると、今度は認識結果が「12」となりました。最初の「１、２」の発話を認識して「12」の認識結果が得られた時点で、ルールグラマによって期待される認識結果の条件（２桁以上の数字）には合致しており、次の発話入力まで指定した 0.2 秒待ったものの入力が無かったため、その発話区間の認識結果がここで確定された、ということです。

このように、「completeTimeout」を使うと、「はい/いいえ」のような一言の短い発話を期待する場合に、早く認識結果を確定させて得ることが可能となります。また、たとえば電話番号のように、一定のルール（例：数字の羅列）はあるがルールに幅がある（例：桁数が複数種類ある）ような場合にも、言い終わったら発話に間ができることを期待して、発話が一定時間無ければ確定させることにより、発話区間の最後まで認識処理せずに結果を得る、ということが可能となります。

パラメータを活用してルールグラマをもっと便利に

ルールグラマを用いた音声認識は、場面によってはより高い精度で認識をさせることができ得るものです。今回ご紹介したパラメータと一緒に活用していただくことで、さらに効果的な使い方ができるようになるかと思いますので、「もしかして自分の使い方には向いているのでは」と思うパラメータがあれば、ぜひ試してみてください。

AmiVoice 「ルールグラマ」関連記事