Cue AI、Gemma 4 E4Bのローカル実行で音声入力レイテンシを44%短縮

従来のCueは、クラウドベースの整列ステップを使用していました。これにより、各インタラクションに800〜900msの遅延が発生していました。さらに、テストした他のモデルはカジュアルな話し言葉をフォーマルな文体に過剰編集し、話者の個性を消す傾向がありました。チームは、モデルの文体ではなくユーザー自身の声色で読めるテキストを求めていました。

Gemma 4 E4Bの統合により、レイテンシは44%短縮されました。中央値は876msから488msに低下しています。これにより、整列ステップは「タイピングより速く感じる」という感覚的な予算内に収まるようになりました。

測定はApple Silicon (Mシリーズ)上でOllamaを通じて行われました。対象は英語と多言語混在を含む227サンプルの実音声ベンチマークです。データは2026年5月時点のもので、ベータユーザーの4週間前後のデータに基づいています。

Cueのパイプラインはシンプルです。ユーザーが話すと、クラウドSTTで生テキストに変換されます。その後、ローカルで動作するGemma 4に送信され、約400トークンのシステムプロンプトでフォーマットルールを適用します。整列されたテキストは、ネイティブOS API経由でカーソル位置に挿入されます。

一連の処理は1秒未満で完了します。この改善により、一人あたりの文字入力量は約30%増加しました。以前は短いメッセージしか入力しなかったユーザーが長い文章を入力するようになり、時間制約のある作業でも音声モードを使い続けるユーザーが増えました。

Cueでは、無料プランも含めすべてのユーザーで文字入力が無制限です。Gemma 4 E4Bが完全にオンデバイスで動作するため、整列ステップの限界コストはゼロになりました。これにより、従来は上限設定や有料化が必要だった機能が、無料プランでも経済的に成立するようになりました。

当初、チームはGemmaをオフラインフォールバックとして計画していました。より大きなモデルの方が精度が高いと仮定していたからです。しかし、227サンプルのベンチマークにより、Gemma 4が過剰編集せずにフォーマットと修正を行うのに適切な容量を持つことが分かりました。テキスト整列において、その特性は制限ではなく、まさに必要な動作です。

Cueのデプロイメントでは、ベースモデルとプロンプトエンジニアリングのみを使用しています。アクティブなアプリのコンテキスト（アプリ名、フィールドタイプ、プレースホルダーテキスト）をプロンプトに注入し、モデルがSlackメッセージを作成しているかどうかなどを認識できるようにしています。