macOS音声入力が突然効かない問題を「構造」で直すDictation障害の実践ランブック

結論先取り：この障害は「設定ミス」ではなく、プロセス連携の破綻です

macOSの音声入力（Dictation）が突然反応しなくなる現象は、ユーザー操作の問題ではなく、corespeechd・DictationIM・coreaudiod という複数デーモンの連携不整合で起きる構造的障害です。設定画面でオフ→オンすると直るのは、実質的にこれらのプロセスを再初期化しているためです。

復旧速度を最優先するなら、手動トグルではなく「ショートカット1発でプロセス再起動」へ移行するのが最適解です。

典型症状を先に整理する

以下の症状が出たら、原因のレイヤーをほぼ切り分けられます。

障害メカニズム：3つのプロセスを1本線で理解する

1. corespeechd（認識エンジン層）

生音声を認識してテキスト化する中核です。ここがハングすると、マイクメーターは動いていても文字が一切出ません。

2. DictationIM（入力メソッド層）

変換結果を「現在フォーカス中のUI」へ注入する橋渡しです。ここが起動遅延・タイムアウトすると、起動音だけ鳴って入力が始まりません。

3. coreaudiod（オーディオHAL層）

マイクデバイスのルーティング管理を担います。スリープ復帰・ドック再接続・外部IF切替のタイミングで不整合が起きると、音声入力全体が崩れます。

まず効く即効策：corespeechd の再起動をショートカット化する

最も再現性が高い復旧は、corespeechd の強制再起動です^[2]。

killall corespeechd

反応しない場合のみ、より強いシグナルを使います。

killall -9 corespeechd

Automatorで「Fix Dictation」クイックアクションを作る

1. Automatorで「クイックアクション」を新規作成
2. 「入力なし」「すべてのアプリケーション」に設定
3. 「シェルスクリプトを実行」を追加
4. 次の1行を登録

/usr/bin/killall -9 corespeechd

1. 例: ⌘⌥⌃D を割り当て
2. これで、設定画面を開かず1秒未満で復旧できます。

ビープ音が続くときの第2手：フォーカスを再構築する

WindowServerのレスポンダチェーンが壊れている場合、音声注入先が Null 扱いになり、ビープ音で拒否されます。以下の順で回復率が上がります。

1. Spotlight（⌘Space）を一度開いて閉じる
2. プレーンテキスト入力欄へ一度入力
3. 元アプリへ戻る
4. それでも不可なら killall corespeechd
5. この順番は「フォーカス再取得」と「認識エンジン再初期化」を分離できるため、再発パターンの観測にも有効です。

外部機器環境での本命対処：coreaudiod リセット

外部ディスプレイ、USBマイク、Thunderboltドックを多用する環境では、coreaudiod 側が起点になるケースが多くなります。

sudo killall coreaudiod

実行直後に音が一瞬途切れますが、通常はOSが自動再起動します。Shortcuts.appに登録する場合、パスワード取り扱いは慎重に設計してください^[3]。

予防策：DictationIM の自動終了タイムアウトを延長する

長時間放置後の「コールドスタート失敗」を減らしたい場合は、待機時間を延長します。

defaults write com.apple.inputmethod.ironwood DelaySecondsUntilTerminatationOffline -float 3600
killall DictationIM

元に戻す場合:

defaults remove com.apple.inputmethod.ironwood DelaySecondsUntilTerminatationOffline
killall DictationIM

これは万能ではありませんが、運用上の失敗頻度は体感で大きく下がります。

UIトグル自動化（AppleScript）は「最後の選択肢」

killall 系に抵抗がある場合、設定画面のオン・オフ操作自体をUIスクリプトで自動化できます。

tell application "System Settings"
    reveal anchor "Dictation" of pane id "com.apple.preference.keyboard"
    delay 0.5
end tell

tell application "System Events"
    tell process "System Settings"
        -- ここでトグル要素をクリック（OSバージョンごとに調整）
    end tell
end tell

ただし Ventura以降はUI階層変更の影響を受けやすく、OS更新で壊れる確率が高いため、実運用の第一候補にはしにくいのが実情です。

長期の最適解：標準Dictation依存を減らす

選択肢A: Voice Controlへ寄せる

Voice Controlは常駐型でコールドスタート失敗が起きにくく、DictationIM経由より安定する場面が多くあります^[4]。

選択肢B: Whisper系ローカルSTTツールへ移行する

MacWhisper / Voicy などは独自パイプラインで認識し、結果を貼り付けるため、標準Dictationの内部不整合から独立しやすい構造です^[5]。

実務向けランブック（運用手順）

障害発生時（30秒以内）

1. フォーカス再取得（Spotlight往復）
2. killall corespeechd
3. 外部機器利用中なら sudo killall coreaudiod

1日1回の予防

1. マイク入力デバイスを固定（自動切替を避ける）
2. 使用言語を必要最小限にする
3. 必要なら DelaySecondsUntilTerminatationOffline を延長

週次見直し

1. 再発ログ（発生時刻・接続機器・直前操作）を簡単に残す
2. 再発が続くなら Voice Control または Whisper系へ段階移行

まとめ

この問題の本質は、個人の操作ミスではなく、音声認識・入力注入・オーディオ管理の多層連携が崩れることです。したがって、最適な対処は「設定を触る」ではなく、「壊れる層を最短で再起動する」運用に置き換えることです。

最初の一歩としては、killall corespeechd をショートカット化するだけでも十分な改善が得られます。音声入力依存が高い方ほど、標準Dictationへの過剰依存を下げる設計へ早めに移行する価値があります。