Macの日本語入力が長期稼働で壊れたので、再起動せずIMEだけ直した

長く動き続けた日本語IMEプロセスを抽象的なタイムラインと円形矢印で再起動する様子

Macを再起動せずに数週間使っていたら、日本語入力まわりで変な壊れ方をした。

普通の日本語入力や漢字変換は問題ない。なのに、日本語入力をオンにしたままShiftキーで英単語を大文字から打ち始めると、入力した英字列が別の英字列へ勝手に変わることがあった。具体的には、ND と打ったつもりが NAS のようになる。

最初はユーザ辞書かテキスト置換を疑った。でも、該当する置換登録はなかった。結果としては、Mac全体を再起動しなくても、Apple日本語入力の本体プロセスだけを確実に入れ替えることで直せた。

この記事は、その時の実験ログだ。Appleがこの原因を公式に認定した話ではないし、macOS 26.5.2で必ず起きるという話でもない。自分の環境では、長期稼働中にIME内部の状態が壊れていた可能性が高そうだった、という観察として書く。

症状は「Shiftから始める英字」だけだった

今回ややこしかったのは、日本語入力全体が壊れたわけではなかったことだ。

ひらがなの入力はできる
漢字変換もできる
普通に日本語を書く分には大きな違和感がない
日本語入力オンの状態からShiftで英字を始めたときだけ目立つ

Appleの日本語入力には、「Windows風のキー操作」を使っている場合、文字入力中にShiftキーを押すと英字モードへ切り替わり、Returnで確定すると元の入力モードへ戻る、という挙動がある。Appleの日本語入力ガイドにもその説明がある。

つまり、通常のABC入力とは別に、日本語IME内の一時的な英字入力経路を通っている。今回壊れていたのは、どうもそのあたりだった。

まずプロセスの状態を見た

確認時のOSは macOS 26.5.2。Mac本体は約29日連続稼働していた。

日本語IME本体の JapaneseIM-RomajiTyping を見ると、約11日間、同じPIDのまま動き続けていた。長く動いていること自体が悪いとは限らない。ただ、今回の症状と合わせると、IMEの内部状態が古いまま詰まっている可能性を疑いたくなる状態だった。

状態確認には、だいたいこういうコマンドを使った。

pgrep -ifl 'JapaneseIM-RomajiTyping|TextInputMenuAgent'
ps -p <PID> -o pid,lstart,etime,rss,command

ここで大事なのは、「コマンドを実行した」ことではなく、対象プロセスが実際に入れ替わったかを見ることだった。

TextInputMenuAgentだけでは直らなかった

最初に試したのは、入力メニュー周辺のプロセスを再起動することだった。

ただ、TextInputMenuAgent を再起動しても、日本語IME本体のPIDは変わらなかった。症状も解消しなかった。

この時点で、メニューバーや入力ソース表示側ではなく、実際にローマ字入力を処理している JapaneseIM-RomajiTyping 側を入れ替える必要がありそうだと分かった。

次に、IME本体の実PIDへ通常終了の SIGTERM を送った。これも少なくとも数秒間は同じPIDが残り続けた。環境によっては killall JapaneseIM-RomajiTyping や通常の終了で直るかもしれない。でも今回の環境では、PIDが入れ替わっていなかった。

最後はIME本体をSIGKILLした

そこで対象を現在のユーザーのApple日本語IMEだけに限定して、SIGKILL で終了した。

pkill -9 -u "$(id -u)" -f '^/System/Library/Input Methods/JapaneseIM-RomajiTyping\.app/'

このコマンドは、現在のユーザーで動いている JapaneseIM-RomajiTyping だけを対象にする。むやみに別プロセスへ kill -9 するためのものではない。

実行すると、対象プロセスは終了し、約1秒後にmacOSが別PIDで JapaneseIM-RomajiTyping を自動起動した。そのあと同じ入力操作を試すと、症状はその場で解消した。

注意点もある。未確定の入力が残っている状態でIMEを落とすと、その未確定文字は消える可能性がある。実行するなら、入力途中の文章がない状態でやるのがよい。

重要だったのはPIDの入れ替わり確認

今回の学びはかなり単純だ。

「IMEを再起動したつもり」でも、実際には本体プロセスが生き残っていることがある。

だから、次の順番で見るのがよかった。

JapaneseIM-RomajiTyping のPIDと起動時間を見る
再起動系の操作をする
もう一度PIDと起動時間を見る
PIDが入れ替わったことを確認してから症状を再確認する

今回の環境では、TextInputMenuAgent の再起動でも、通常の SIGTERM でも、IME本体のPIDは変わらなかった。SIGKILL 後に初めて別PIDへ入れ替わり、そのあと症状が消えた。

「再起動すれば直る」はたぶん正しい。でも、Mac全体を再起動したくない時には、壊れているプロセスだけを本当に入れ替えられているかが大事だった。

再発予防として日次リセットを入れた

同じ症状が繰り返すと面倒なので、常時稼働に近いMac向けの予防策として、未明に日本語IMEだけをリセットするジョブも設定した。

毎日リセットが万人に必要だとは思わない。普通にMacを再起動している人なら、そもそも出ないかもしれない。ただ、自分のように長く起動したまま使う環境で、同じ症状が再発するなら、実用的な回避策にはなる。

スクリプトの形にすると、こんな感じだ。

#!/bin/bash
set -euo pipefail

pattern='^/System/Library/Input Methods/JapaneseIM-RomajiTyping\.app/'
uid="$(id -u)"
pids="$(pgrep -u "$uid" -f "$pattern" || true)"

[[ -z "$pids" ]] && exit 0

while IFS= read -r pid; do
  [[ -n "$pid" ]] || continue
  kill -KILL "$pid"
done <<< "$pids"

成功時は何も通知せず、失敗時だけ気づけるようにしておけば十分だと思う。未確定入力が消える可能性があるので、使っていない時間帯に動かすのが前提になる。Macがスリープ中なら、その時刻どおりには実行されない可能性もある。

まとめ

今回直したかったのは、Mac全体ではなく、日本語IMEの中の壊れた状態だった。

Mac本体は約29日連続稼働していた
JapaneseIM-RomajiTyping は約11日間、同じPIDで動いていた
日本語入力そのものではなく、Shiftから始める英字入力だけがおかしかった
TextInputMenuAgent の再起動では直らなかった
IME本体のPIDが入れ替わったあと、症状は解消した

こういう時、雑に「再起動」で済ませるのが一番速いことは多い。でも、再起動したくない時は、壊れているプロセスを特定して、本当に入れ替わったことまで確認すると解決できることがある。

今回はそれがApple日本語入力の JapaneseIM-RomajiTyping だった。