Tesuji手筋
投稿
記事を投稿ノードを投稿

LOG 2026.10.31 · CONSTELLATION · 4 STARS

Jev を音声コマンドの意図判定に使ってみた:1回170ms、正規表現とのハイブリッドで全発話を読めた

Jev(TypeSafe AI)を音声・チャットの意図判定にどう組み込むと速くて取りこぼしがないか、実測の数字と使いどころ・向かないところが分かる。

結論

Jev は、文章を作らずに「選択肢のどれか」を確率つきで返すAIです。音声で指示するとコードを書く VS Code 拡張で、話した言葉の意図判定に使いました。

  • 1回の呼び出しは中央値 170 ms(p90 209 ms)。LLM に分類させるより桁違いに速い
  • 正規表現だけだと「FizzBuzz がほしい」のような言い換えを 0/30 しか読めなかった
  • Jev だけにすると全部読めたが、キーワードのある発話では起動が遅くなった
  • 正規表現 → 読めなければ Jev のハイブリッドが一番良かった(全60発話を正解、起動も最速)

「まずルールで読む、読めないときだけ Jev」が、私の今の結論です。

Jev とは

TypeSafe AI が2026年9月に公開した System One モデルの第一弾です。

  • 入力:状態(テキストなど)+ 型の決まった問い(選択、スコア、はい/いいえ)
  • 出力:型どおりの答えと確率・信頼度。文章は返さない
  • 公称の応答時間は70〜500ミリ秒、料金は入力100万トークンあたり $0.042(出力は無料)

公式は「賢い if 文」と表現しています。LLM に JSON を書かせてパースする代わりに、プログラムの分岐の中に判断を直接はめ込むイメージです。

使い方:音声コマンドの意図判定

音声で「FizzBuzz を作って」「このファイルを説明して」と話すと、Soniox で文字起こしし、意図(生成・説明・テストなど)を読んでから処理を起動します。

意図を読む方法を3つ比べました。

  1. 正規表現のみ:「作っ」「説明」のような動詞の語幹で読む
  2. Jev のみ:途中経過(partial)と確定テキストを全部 Jev に投げる(1回=選択の問い1つ、モデルは jev-latest)
  3. ハイブリッド:まず正規表現、読めなかったときだけ Jev

測った条件

  • 計測日:2026-10-02
  • STT:Soniox stt-rt-v5
  • 音声:合成音声30本(意図語あり15本、なし15本)を実時間で流して2周
  • 「起動」=話し終わってから処理が始まるまで(マイナスは話し終わる前に起動)

結果

意図語あり(「FizzBuzz を作って」など)30発話

方式正解起動(中央値/最大)
正規表現のみ30/30181 ms/704 ms
Jev のみ30/30272 ms/1131 ms
ハイブリッド30/30130 ms/704 ms

意図語なし(「FizzBuzz がほしい」「テストが通らないんだけど」など)30発話

方式正解起動(中央値/最大)
正規表現のみ0/30読めない
Jev のみ30/3090 ms/787 ms
ハイブリッド30/3086 ms/737 ms

Jev の呼び出し1回あたり:中央値 170 ms、p90 209 ms。ハイブリッドにすると呼び出し回数は 688 回 → 546 回に減りました。

分かったこと

  • 言い換えはルールでは読めない。 ここが Jev の出番です
  • Jev だけにすると、キーワードのある発話で遅くなる。 partial を毎回投げると、正規表現なら一瞬で読めるものまで Jev の往復を待つことになります。キーワード側で partial を2回取りこぼしたのも Jev のみの方式でした
  • STT が行番号を聞き違えても(「10行目」→「従業目」)、意図は正しく読めた
  • 意図語なしの発話は、partial の途中から文脈で読めることが多く、話し終わる前に起動できるケースもありました

他のプロダクトでの使い方

  • 引っ越しくらべ(東京の自治体比較):チャットの各発話で、比較・ゴミ・制度などの意図を Jev で判定しています。LLM に文章を書かせないので、存在しない制度をでっち上げる心配がありません。Jev が使えないときはキーワード分類に切り替えて、サービスは止まらないようにしています
  • 七王の盟約(外交ゲーム):最初は「NPC が約束を守るか」を Jev の確率で決めていました。ただ、途中で API が使えない時間があったのと、単純なルールと比べて強さに差が出なかったので、最終的にはルールベースに置き換えました。ゲームの意思決定のように「確率の中身」が面白さになる用途より、分類して次の処理に回す用途のほうが向いている と感じています

向かないところ

  • 文章を書かせる仕事はできません(返すのは型どおりの判断だけ)
  • ホスト型のAPIなので、API が落ちたときのフォールバックは自分で用意する必要があります
  • 速度は公称値どおりとは限らないので、自分の環境で測ってから使うのがおすすめです

参考

自分のブックマーク

読み込み中…

NEXT MOVE — 次の一手

同じ星が登場する星座