以前、音声入力のホットキーを離した後、5分前にお copied した何かを探していたら、今 dictated した文章がクリップボードにあったことがあるかもしれません。これはなぜ起こるのか、なぜ一時的なものであるべきなのか、そしてそれが意図通りに動かない場合の対処法について説明します。
実際のクリップボードが使われる場面
Coii VoiceInput は、あなたが使用しているテキストフィールドにテキストを届けるための2つの方法があります。1つ目の方法は、macOS のアクセシビリティ API で、アプリに直接文字起こしを渡します。これにはクリップボードが使われず、上書きされることもありません。ほとんどのネイティブ Mac アプリがこの方法をサポートしており、これが利用可能な場合に使われます。
2つ目の方法は、合成ペーストです。アプリが一瞬だけ文字起こしをクリップボードに置き、その後 Cmd+V でペーストし、dictation を始めた前にクリップボードにあった内容を元に戻します。これは、テキストフィールドがアクセシビリティにアクセスできないアプリでのみ発生します。多くの人が想像するよりは少ないアプリですが、ゼロではありません。
どちらの方法も、あなたが最後に使用したテキストフィールドに文字を届けます。通常の状況では違いは見えませんが、これが問題になる理由は、復元ステップが遅れたり、中断されたり、気づかなかったりした場合、アプリがクリップボードを上書きしたように見えるからです。
なぜ通常は問題にならないのに、問題のように見えるのか
「何かをコピーし、dictate し、コピーした項目がdictated した文章に変わっている」というシーケンスには、非常に普通の説明があります。それは、ペーストと復元の間の短い時間にクリップボードを見てたからです。高速な Mac では、この時間は短く、ホットキーを離したほぼ同時にチェックしないと見ることはできません。古いマシンや、システム内の他のプロセスが負荷がかかっている場合、この時間はやや長くなり、見られる可能性が高くなります。
もう1つの説明は、dictate したアプリがクリップボード経路を使用し、その後すぐに別のものをコピーしたことです。たとえば、URL、ターミナルの行、別の文章など。その時点で復元するものがありません、なぜならあなた自身が後に別のもので上書きしたからです。これは Coii VoiceInput とは関係ありません。
git log --oneline -20
ステップ 2 — 実際に心配するアプリを把握する
ターミナルおよびほとんどのターミナルエミュレータは最も明確なケースです: シェルプロンプトがテキストを受信するためのアクセシビリティの表面が存在しないため、すべての音声入力はクリップボード経由のループになります。ターミナルに音声入力する は、その環境の他の違いをカバーしています。
2 番目のグループは、テキストフィールドをシステムのアクセシビリティレイヤーに接続していない Web 技術に基づいたアプリケーションです — 一部の Electron ベースのエディターやブラウザ埋め込みツールがこのグループに属し、特定のアプリが更新されるたびにこのグループのメンバーが変わります。そのため、自分の環境でテストする方が信頼性が高いです。
パスワードフィールドは関連するが別個のケースです。macOS 自体が、アプリがどの経路を通っても、一部のパスワードフィールドに貼り付けた内容を拒否します。音声入力がパスワードフィールドで機能するか は、クリップボードとは関係のない別の質問であり、別の答えを持ちます。
普通のネイティブアプリ — メール、メモ、Slack、ほとんどのコードエディタ、ほとんどのワードプロセッサ — はアクセシビリティ経路を使用します。これらのアプリにほとんど音声入力を行っている場合、クリップボードのフォールバックはあなたの実際のワークフローに触れることがないことを読むだけで理解できます。
ステップ 3 — 半秒を気にしろ、全体のセッションは気にしなくてよい
何かがうまくいかないのは、リリースと復元の間の瞬間だけです。その瞬間を邪魔するのは、その間に別のものをコピーすることだけです。実際には、ホットキーを離した直後に別のものを選択してコピーしないようにしてください。ペーストが目に見えるように表示されるまで待つと、短い文章ではほぼ瞬時に完了します。その時点でクリップボードはすでに通常の状態に戻っています。
これは、ほとんどの人が意図的に習慣として築かなければならないものではありません — あなたが音声入力とコピーを繰り返すようなタイトなループで使用する場合にのみ発生します。これはまれなケースです。たとえば、コミットメッセージを音声入力し、複数の他のソースからテキストを連続して取得している場合、この知識は役立ちます。
ステップ 4 — Universal Clipboard がこのプロセスに追加するものを理解する
Handoff が有効で、複数のデバイスで同じ Apple ID にサインインしている場合、macOS は自動的にクリップボードを同期します — これはシステム機能であり、どのアプリも制御しません。クリップボードフォールバックが一時的にあなたの文字起こしをそこに置くため、その一時的な値が Universal Clipboard によって他のデバイスに取得され、あなたの Mac で復元される前にも提案されることがあります。
これは、macOS の同期動作が、その瞬間のクリップボードに含まれているものにかかわらず、設計通りに正確に動作しています — Coii VoiceInput 自体はどこにも何も送信しません。ネットワーク使用は、モデルを一度取得するため、ライセンスをアクティベートするため、起動時に時刻を確認するためのみです。Wi-Fi がオフになっても、音声入力は同じように動作します。あなたの dictated 文が iPhone で Universal Clipboard の提案として表示されたくない場合は、同期を望まないデバイスで Handoff をオフに設定する macOS の設定で、このアプリ内での設定ではありません。
ステップ 5 — 履歴をクリップボードではなく記録として扱う
クリップボードは、あなたの dictated 文が存在する場所として意図されていません — それは、あなたが入力していたフィールドにテキストを送るための中継地点です。実際の記録はあなたの履歴です: すべての dictated 文がそこに記録され、フィルタが適用された後のバージョンも含まれます。ペーストがアクセシビリティ経路を使用したか、クリップボード経路を使用したかに関係なく、ペーストが成功したか、クリップボードが期待通りに保持しているかを確認するには、dictation 履歴を確認する を行うべきです。クリップボードではなく、直接的な答えを得ることができます。システム全体のスロットに他の何ものもアクセスできるため、推測する必要はありません。
ステップ6 — クリップボードマネージャーがすべてを監視していることを覚えておく
第三者のクリップボードマネージャーを実行している場合 — つまり、あなたがこれまでにコピーしたすべての履歴をスクロール可能に表示し、単に最新の項目だけを記憶するmacOSとは異なり — それは、アプリごとにではなく、システムクリップボードのより低いレベルでシステム全体を監視しており、Coii VoiceInputのフォールバックがその場所に書き込んだ瞬間を記録します。他の何でもかんでも同じように記録されます。
これにより、後でクリップボードマネージャーの履歴を開くと、あなたの音声入力された文章がその履歴の独立した項目として表示されている可能性があります。ただし、クリップボード自体はその文章が表示されるわずかな時間後に復元され、あなたの視点から見れば何の変化もないかもしれません。これは問題ではなく、Coii VoiceInputの側で設定を変更する必要はありません。クリップボードマネージャーの役割は、すべての書き込みを認識することであり、合成的なペーストは、それが動作するレベルでは、あなたが Cmd+C を押したのと区別がつきません。この項目は無害であり、多くのクリップボードマネージャーは、文字起こしがコピーされたスニペットの中にあることに不快感を覚える場合に、個々の項目を削除する機能を提供しています。
これはまた、クリップボードのフォールバックが、あなたが復元しようとしている音声入力を探す場所としては決して適切ではないもう一つの理由でもあります。クリップボードマネージャーの履歴は、どのアプリで音声入力したか、またはワークフローにおけるタイミングでインデックス化されていません — Coii VoiceInputの履歴はそうしており、それは、他の何がクリップボードを監視しているかに関係なく、特定の文章に戻るためのより直接的な方法です。
クリップボードの復元が本当に失敗した場合の対処法
これはまれですが、音声入力したアプリがペーストと復元の瞬間にクラッシュした場合、またはシステム上の他の何かがその瞬間にクリップボードに書き込んだ場合に発生します。その場合、2つのことが真です。まず、クリップボードは常に1つの項目しか保持できません。そのため、以前にコピーした内容は失われ、クリップボード自体からは復元できません — これには元に戻す履歴はありません。次に、あなたの音声入力されたテキストは危険ではありません。なぜなら、ペーストが試みられる前にCoii VoiceInputの履歴にすでに書き込まれていたからです。したがって、復元が失敗したとしても、何の損失もないのです。
特定のアプリでこのパターンが繰り返される場合は、そのアプリのフォーカス処理が実際の原因であるかを確認する — ペーストが着 land しないことや、予期せぬ場所にペーストされることが、同じ根本的な原因を引き起こすことがよくあります。
FAQ
これはバグですか、それとも意図した動作ですか？
これは意図した動作です。クリップボードのフォールバックが存在する理由は、一部のアプリがテキストを受け取る他の方法を持たないためです。復元される前の状態を保持するという設計の一部が、最も多く発生する音声入力のケースで見えなくなるようにするためのものです。
これは毎回音声入力するたびに起こるのでしょうか？
いいえ。これは、アクセシビリティ経路をサポートしていないアプリでのみ起こります。これは、ほとんどの人が日常的に音声入力するアプリの一部にすぎません。ネイティブのmacアプリはほぼすべてがクリップボードのステップを完全にスキップします。
私はアプリがその後でクリップボードを使用したかどうかを確認できますか？
その後で直接確認することはできませんが、ステップ1で説明したように、その瞬間にテストできます — 短い行を音声入力し、その後すぐにクリップボードを確認してください。
ペーストが遅いと、私のクリップボードがより長時間危険にさらされるのでしょうか？
復元はペーストが完了した時点で行われるため、アプリが遅い場合、わずかな時間の差が生じます。ただし、実際にキーボード入力を受け取るアプリでは、これは常にミリ秒単位であり、計画する必要はありません。
すべての問題を回避する習慣
特定の項目をクリップボードに保持することが重要であると感じる場合 — 例えば、複数の場所に貼り付けるリンクや、再利用するコードスニペット — そのような場合の最も簡単なルールは、クリップボード経路のアプリに音声入力を行う前に、その貼り付け作業を終えることです。これは何もコストがかかりません。なぜなら、後から履歴を確認することで、不確実な音声入力の確認を行うのが通常の方法だからです。また、同時に同じクリップボードの場所を競う二つの作業が存在しないという意味です。
ほとんどの音声認識は、ほとんどのアプリに対して、このようなことを考える必要はありません。アクセシビリティ経路が一般的なケースであり、クリップボードのバックアップは、気づく前に元の内容を復元してくれます。自分の通常のアプリがどのグループに属するかを一度確認すれば、それ以降はそのことを気にすることはありません。マックでの音声認識は、あなたの声が実際にテキストフィールドにどのように変換されるかを説明しており、試用版は、あなたのアプリがどの経路を使用するかを確認するのに十分な長さです。