音声入力の2つのアプローチ
すべての音声入力ツールは根本的な設計上の決断を迫られます。マイクはいつ聞くのか、ということです。
2つの主要なモデルはプッシュ・トゥ・トーク（ボタンを押している間だけマイクが有効になる）と常時オン（マイクが継続的に聞き、通常はウェイクワードまたは開始・停止コマンドを使用する）です。それぞれのアプローチはプライバシー、精度、ワークフローへの組み込み方、リソース消費に異なる影響を与えます。
この選択は単なるUXの好みではありません。音声入力が作業環境にどのように組み込まれるかについての、根本的に異なる前提を反映しています。
プッシュ・トゥ・トーク：意図的で区切りがある
プッシュ・トゥ・トークのディクテーションでは、ホットキーを押してマイクを有効にし、コンテンツを話し、終わったらキーを離します。マイクはそれ以外の時間は無効です。
プライバシー： これは音声入力において利用可能な最強のプライバシー保証です。アプリケーションはホットキーが物理的に押されている間だけ音声をキャプチャできます。バックグラウンドでの盗聴はなく、プライベートな会話が誤って録音される心配もなく、意図しない瞬間の音声が処理されるかどうかという疑問も生じません。同僚、クライアント、機密情報が耳に届く職場環境では、この点が重要です。
精度： プッシュ・トゥ・トークは一般的により高い精度を生み出します。音声セグメントがクリーンで区切りがはっきりしているからです。モデルは正確に一つの発話を受け取ります——ホットキーを押したときから離したときまで——環境音からの音声の開始点を検出する必要がありません。バックグラウンドの会話が意図した入力かどうかという問題も生じません。
ワークフロー： プッシュ・トゥ・トークの操作は明示的かつ意図的です。何を言いたいかを準備してからキーを押し、話して、離す。これは「今書いている」「終わった」という思考の流れに自然に合致します。ハンズフリーを必要としないため、キーボードやマウスの使用と自然に共存できます。
バッテリーとリソース： 実際にディクテーションしていないときはマイクがアイドル状態になります。CPUとネットワークのアクティビティはディクテーションセッション中のみ発生します。
制限： すべてのディクテーションに意図的な操作が必要です。医師が患者を診ながら手が塞がっている医療トランスクリプションのような継続的なハンズフリーのディクテーションは、プッシュ・トゥ・トークの自然なモードではありません。
常時オンのディクテーション：連続的でハンズフリー
常時オン（または連続）のディクテーションは音声活動検出を使って、あなたが話しているときを自動的に識別して音声を処理します。Apple Dictationを連続モードで使う場合、Android上のGoogle 音声入力、そしてハンズフリーのアクセシビリティツールは通常この方式で動作します。
プライバシー： 常時リッスンにはマイクへの継続的なアクセスが必要です。ツールはあなたが話し始めるタイミングを検出するために音声を常に処理し続けなければなりません。ローカル処理が良好でも、固有のリスクがあります。マイクの近くで行われるあらゆる会話が、入力として意図していなくてもキャプチャされる可能性があります。多くのエンタープライズ環境やオープンオフィスでは、これは現実的な懸念です。
精度： 一定しません。モデルは意図したディクテーションと環境音——同僚の会話、バックグラウンドで流れる動画、近くで誰かが話している声——を区別しなければなりません。誤作動や開始点の見逃しが出力にノイズをもたらします。
ワークフロー： ハンズフリーのシナリオにより適しています。患者を診察しながらディクテーションを使う医療専門家、両手が塞がった状態で作業する人、キーを押し続けることが難しい運動障害のあるユーザーは、連続ディクテーションから利益を得られます。
バッテリーとリソース： マイクへの継続的なアクセスと音声活動の常時検出は、プッシュ・トゥ・トークと比べて、より多くのバッテリーと処理能力を消費します。
制限： 共有スペースやオープンオフィス環境には不向きです。誤作動がノイズを生みます。音声とテキスト入力を頻繁に切り替えるコンテキストでは、ツールとの継続的な「会話」が不自然に感じられます。
ウェイクワード方式
3つ目のアプローチはウェイクワード（「Hey [製品名]」）でリッスンを開始し、停止コマンドや一定時間の無音でセッションを終了します。SiriやAlexa、Google Assistantが採用しているモデルです。デスクトップのディクテーションでは、高頻度の使用においてウェイクワードが摩擦となるため、ほとんど使われません。
出力品質への影響
生のトランスクリプション精度を超えて、起動モードはAIエンリッチメントの品質にも影響します。
プッシュ・トゥ・トークの優位性： AIは区切りがはっきりした一つの発話を受け取ります。エンリッチメントモデルは完結した意図的なステートメントを処理します。意図しない発話からのノイズがなく、モデルが境界を検出する必要もありません——ユーザーがホットキーを離したタイミングがセグメントを定義します。
常時オンの課題： エンリッチメントモデルは、言い直しや環境音、曖昧な境界を含む可能性がある音声セグメントを受け取ります。これによってモデルの処理が難しくなり、フォーマット済み出力に乱れが生じる場合があります。
Telvrの設計上の選択
Telvrはプッシュ・トゥ・トークのみを中心に構築されています。これは2つの確信に基づく意図的な選択です。
第一に、プロフェッショナルな環境ではプライバシーが重要です。機密の会話が日常的に行われるデスクトップ生産性ツールは、マイクがいつアクティブになるかについてユーザーに完全なコントロールを与えるべきです。プッシュ・トゥ・トークは設定なしでそのコントロールを提供します。
第二に、プッシュ・トゥ・トークの明示性がより良い出力を生み出します。ホットキーを押してディクテーションするユーザーは、意識の流れを話してAIに意味を抽出させるのではなく、話す前に考えをまとめる傾向があります。結果として入力がより凝集性を持ち、AIエンリッチメントの出力品質も向上します。
どちらのアプローチが適しているか
プッシュ・トゥ・トークを選ぶべき場合：
- 共有オフィスやオープンオフィス環境で働いている
- プライバシーが懸念される（通話、機密情報、秘密の会話が近くで行われる）
- 音声とテキスト入力を頻繁に切り替える
- すべてのディクテーションセッションを明示的にコントロールしたい
- キーボードを補完する形で特定の場面に音声を使いたい（常時ハンズフリーではなく）
常時オンを選ぶべき場合：
- 完全なハンズフリー操作が必要（医療処置、肉体的な作業）
- プライベートで静かな環境で働いている
- コンピュータを操作せずに長い文章を連続して口述する
ウェイクワードを選ぶべき場合：
- ディクテーションツールではなく音声アシスタントを使いたい
- 物理的なボタンなしで周囲からの起動が必要
デスクのパソコンの前でメール、ドキュメント、メッセージ、ノートを書くためにキーボードの補完として音声入力を使いたい、多くのナレッジワーカーにとっては、プッシュ・トゥ・トークの方が適しています。明示的で区切りのある起動は、デスクワークが実際にどう行われるかに合致しています——連続的なモノローグではなく、断続的なテキスト作成のバーストです。