ホットキーを押しながら文を読み上げ、キーを離した後、予想していた場所に何も表示されなかったかもしれません。文が消えたと思い込まず、この点を理解してください。Coii VoiceInputは、キーを離した瞬間にあなたの言葉を履歴に書き込みます。その後、クリーンアップやどこかに貼り付けするための処理を実行する前に、履歴に保存します。貼り付けが失敗したのは、配達の問題であり、情報が失われたわけではありません。この手順で文を取り戻すことができます。
ステップ1 — 再度音声入力する前に履歴を開く
Coii VoiceInputを開き、履歴画面に移動します。これまでに音声入力したすべての文は、行として表示されます。時間、対象アプリ、およびテキストが表示されます。最も最近の行は、上部に表示されます。これがあなたの失った文です。それがどこに貼り付けられたかに関係なく、履歴に保存されています。
- 09:143.1sConfirming the 2pm slot works for both of us — see you then.Slack
- 09:125.6sThe migration script needs the read replica lag checked first.Terminal
- 09:072.4sDraft reply: happy to extend through Friday if that helps.Mail
まだ再び読み上げる必要はありません。まず履歴に文が保存されているか確認してください。そうすることで、すでに正しく記録されている文を複製することを防げます。
ステップ2 — 実際に使用したいバージョンをコピーする
各行には2つのバージョンのテキストがあります。1つは、あなたが実際に言ったとおりの「文字起こし」、もう1つは、あなたの単語登録、繰り返しの統合、フィラー除去（有効にしている場合）、記号やスペースの処理を経た「処理済みバージョン」です。貼り付けが失敗したとしても、どちらのバージョンが保存されたかは変わりません。どちらかを選択し、コピーしてください。
どちらのバージョンが異なるのか、あるいはどちらが通常の出力になるか分からない場合は、音声入力で何が出てきてなぜそうなるのか が処理済みバージョンがどのように生成されるかを説明し、なぜ文字起こしは処理済みバージョンと併せて保存されるのかを説明しています。
ステップ3 — 本来の場所に手動で貼り付ける
履歴からコピーしたテキストを、元々音声入力していた場所にクリックし、通常通り貼り付け（Cmd+V）してください。自動貼り付けが失敗した理由に関係なく、この手順は機能します。なぜなら、テキストをクリップボードからフィールドに貼り付けるという作業は、Coii VoiceInputではなく、フィールド自体が制御しているからです。
一部のパスワードフィールドや少数のアプリでは、貼り付けを完全に受け付けない場合があります。その場合は、履歴の行からテキストを読み取り、手動で入力する必要があります。これはフィールドの制限であり、復元機能の限界ではありません。テキストは画面に表示されており、問題はそのテキストをフィールドに送る方法に過ぎません。
ステップ4 — 貼り付けが失敗した理由を調べる（再発する可能性がある場合）
一度きりの失敗は通常、調査する価値はあまりありません。同じアプリで繰り返し起きる場合は、2つの原因のどちらかを特定し、それぞれに対応する必要があります。
フィールドが貼り付けを受付けない。 これはアプリの性質であり、音声入力で回避することはできません。パスワードフィールドで音声入力が機能するか がこの問題の最も一般的なケースを説明しています。他のアプリでは、音声入力に関係なく、Cmd+Vで手動で貼り付けしても失敗するという特徴があります。
キーを離す前にフォーカスが移動した。 ウインドウを切り替えたり、別の場所をクリックしたり、通知がフォーカスを奪った場合、キーを離した時点でフォーカスがどこに移動したかによって、テキストがその場所に届きます。それが役に立たない場所だったり、貼り付けが「行われなかった」ように見えるアプリだったりします。音声入力が間違ったアプリに届く理由 はこの問題の詳細な説明であり、再発を防ぐ方法も含まれています。
アプリがクリップボードのフォールバックを使用しており、何かが干渉した。 一部のアプリ（例：ターミナル）では、音声入力がクリップボード経由で受信される ことがあり、まれにその経路が妨げられることもあります。履歴に影響を与えることはありません。最初に履歴に保存するという設計の目的です。
ステップ5 — 新規の場合、アクセシビリティの許可を確認する
音声入力が通常通り動作していたが、突然どこにも反映されなくなった場合、最初に確認すべきことは、System Settings で Coii VoiceInput がアクセシビリティの許可を持っているかです — macOS はアップデート後にこの許可をしばしば取り消します。許可がなければ、アプリはほとんどのテキストフィールドにテキストを届ける方法を持たず、これは一気にすべてのペーストが失敗したように見えます。 macOS アクセシビリティ API がこの許可によって実際に許可されるものです。アップデート後に設定で再度許可を有効にするだけで、通常は問題が解決します。
すでに再音声入力を行った後で履歴を確認した場合
これは自然な反応です：テキストが表示されないため、もう一度音声入力してしまい、最初の試行が単に消えたのだと考えます。もしこれを上記のステップを読む前に行っていた場合、何も壊れてはいません — 履歴には非常に似た、あるいはまったく同じテキストの行が数秒違いで2行残っているはずです。実際に必要な方（通常は2回目 — 話した瞬間に意識していたのはそちらだからです）を使い、もう一方はそのままにしておいてください。履歴は記録であり、作業用の文書ではありません。誤発話による余分な行があっても損失はなく、片付ける必要もありません。
2回目の試行も1回目と同じ理由で貼り付けに失敗した場合 — 同じアプリ、同じフィールド、同じ原因 — それ自体が有用な情報です。問題が一度きりの不具合ではなく、そのフィールド固有の性質であることを示しており、3回目を音声入力で乗り切ろうとするより、ステップ4に進むべきだと教えてくれます。
習慣化する — 何かが失われたと決めつける前に履歴を確認する
すぐに再音声入力してしまう衝動は、変える価値のある唯一の習慣です。代替手段より時間がかかるうえ、ときどき上記のような重複行を生み出すからです。履歴は時刻順に並んでいるため、欲しい行はほぼ常に一番上にあり、それがあることを確認する方が、どんな長さの文章であっても言い直すよりも短時間で済みます。音声入力を重ねるうちに、まず確認することが習慣になり、意識してやることではなくなります。
これは、一度きりの出来事だけを見ていると分かりにくい、耐久性保証の価値が現れる場面でもあります。クラウド型の音声入力サービスは、転送中に文が本当に失われることがあります — あなたのMacとサーバー間の接続切断、タイムアウトしたリクエスト、処理途中のサーバー側エラーなど — なぜなら、何かが行われる前に、まず言葉があなたの端末を出ていかなければならないからです。Coii VoiceInputの履歴書き込みはローカルで行われ、エンジンに何かを尋ねる前に完了しているため、ここで起こりうる失敗はフィールドへの配達に関するものだけであり、文がそもそも記録されたかどうかには関わりません。$19の一括価格はこれを変えません — 変えるのはアーキテクチャであり、それは最初の1文を音声入力した日でも、1万文目でも同じです。
この耐久性保証を支えているもの
復元がこれほど単純な理由は、物事が起きる順番にあります。ホットキーを離した瞬間に文字起こしは履歴に書き込まれます — 文字起こしエンジンに何かを確定するよう求める前、フィルターが実行される前、貼り付けが試みられる前にです。エンジンの遅延、アプリのクラッシュ、貼り付けを拒否するフィールド、意図しない場所に移ったフォーカス — これらはすべてその書き込みの後に起きるため、そのどれもが文そのものを失わせることはなく、失われるとすればその配達だけです。
これはまた、復元がオンラインであることに依存しないことも意味します。履歴はあなたのMac上のローカルな記録であり、ネットワーク接続の有無にかかわらず同じ方法で確認・コピーできます — アプリの他の部分の動作と一貫しています。話した内容がアップロードされることはなく、ネットワーク通信はモデルを一度取得すること、ライセンスをアクティベートすること、起動時の時刻確認だけであり、履歴の行を開いて中身を読むのにそのいずれも必要ありません。
音声入力の忙しい部分で正しい行を見つける
上記のアドバイスは、欠けている文が最も最近の行であると仮定しています。これは、ほとんどの場合が正しいのですが、数分後に貼り付けが失敗したことに気づくため、望む行は上部にあります。ただし、朝早くに複数のアプリに音声入力を行い、その後になって気づくと、この状況はやや曖昧になります。
そのような状況では、時間と宛先アプリの2つの列が重要になります。もし、欠けている文をいつ頃音声入力したかを覚えているなら（「あのSlackスレッドへの返信をしていた頃だった」というような）、まずその時間帯の行を検索し、その後宛先アプリで絞り込みます。朝からSlackを使い始めたわけではないのに、Slack宛ての行が欠けている文であるとは限りません。
欠けている文に含まれる特徴的な単語やフレーズを覚えているなら、直接履歴を検索する方が目視でスキャンするよりも速いです。正確な時間は再構築しなくても、文の一部さえ再構築できれば十分です。これは、仕事中の高頻度音声入力を行う人にとって特に重要です。そのような人にとっては、「これらの20行のうちどれが貼り付けられなかったのか」がより現実的な質問であり、「朝の音声入力が失われたのか」はそれほど重要ではありません。
音声入力の量が増えるほど、裏付けは弱まりません。各行は、その音声入力のホットキーを離した瞬間に独立して記録されるため、朝に100回の音声入力を行ったとしても、それぞれが独立して貼り付けに失敗する可能性があり、それぞれが独立した履歴行となります。どの行が欠けていたかを見つけるのは検索問題であり、それが保存されたかどうかの問題ではありません。
FAQ
履歴はいつまで戻せますか？
これまでに音声入力したすべての行は、行として保存されるため、必要に応じて最も最近の行よりも前のものまで戻せます。
履歴を検索する代わりにスクロールする必要がありますか？
いいえ。履歴は各行のテキストで検索可能なので、欠けている文に含まれる単語やフレーズを覚えているなら、直接検索して、時間を基にスキャンするよりも速く見つけることができます。
貼り付けが失敗した行は、成功した行とは履歴上で表示が異なりますか？
いいえ。行は音声入力した内容と宛先を記録しており、その後の貼り付けが成功したかどうかは記録されません。これは意図的な設計です。音声入力した内容の記録は、その後の処置とは関係ありません。
連続して複数の音声入力を行ったが、どれも貼り付けられなかった場合はどうすればいいですか？
それぞれが独立した行として順番に保存されているため、すべてを回復するには同じプロセスを繰り返すだけです。履歴を開き、それぞれをコピーし、該当するテキストフィールドに貼り付けます。
回復を簡単にすること
上記のステップはどれも複雑ではありません。これは意図的な設計です。回復プロセスが役立つのは、手動で文をタイプするよりも速い場合です。しかし、手動でタイプした文はもともと正確に覚えていたとは限りません。一度行えば、不思議な貼り付けの後に履歴を確認する行為は、メールを送信した後に送信フォルダを確認するのと同じように自動的になり、そして同じくらい速くなります。
簡潔な説明
予期しない場所に表示されない音声入力は、文が欠けていないことを意味します。貼り付けの問題です。まずは履歴を確認し、望むバージョンをコピーして、手動で貼り付けます。Coii VoiceInputは1回の買い切り価格で$19で、30日間の無料トライアルが付いており、この種の失敗モードは履歴が存在する目的であり、再録音して二回目に成功する理由にはなりません。