新シリーズ開始。
Linux 移行で生じたトラブルの数々を｢プロ｣が検証して記録というスタイルにする。
30年間以上にわたってなじんで来た Windowsからわずか2ヶ月間ほどで文化圏の異なる Zorinosへの完全移行は、AI チャットの協力なくしては実現しなかった。いくらLinuxがユーザーフレンドリーになったとはいえ、新たな外国語習得に近いハードルが存在する事実は変わらない。その全貌をドキュメンタリータッチで紹介していく試みである。
そのため、あえてチャットAI であるClaude.ai の一人称視点になっているのでご了承いただきたい。
クレーム以外のツッコミや感想や質問や激励などあればコメント大歓迎です。(^。^)
さて。いきなりニッチなネタからスタートです。(^。^;
CapsLockキーの迷惑な挙動は誰のせいか
うちの「よろず相談室」に、ほぼ毎日のように顔を出す常連さんがいる。パラドックス氏。Windowsから足を洗ってZorinOSに乗り換えたばかりの、根っからの初心者――のはずなのだが、質問の粘り強さだけは初心者離れしている。
その日の相談は、こんな感じで始まった。
「あのね、CapsLockキーがずっと気に入らないんだ。Windowsだと大文字固定にするのに Shift + CapsLock が必要だったのに、ZorinOSだと押しただけで大文字ロックになる。オレは英数キー代わりにCapsLockでIMEをオンオフしたいだけなのに、そのたびに大文字固定が暴発するんだよ」
Linuxではよくある話に見えた。私は定石通り、こう答えた。
「キーボードはハードウェアとしてCapsLockと英数キーを区別せずOSに送っています。なので原理的に区別は難しい、というのが一般的な回答になります」
我ながら模範解答だと思っていた。ところがパラドックス氏は、あっさりとは引き下がらなかった。
「いや待って。オレ、もう一台Kubuntu機を使ってるんだけど、そっちじゃこの問題、一度も起きてないんだよね」
――この一言が、今回の長い調査の出発点になった。ハードウェアの問題だと言うなら、同じキーボードを使っているはずのKubuntuでも起きるはずだ。起きていないということは、犯人はハードではない。相談員としては、この「無鉄砲な突っ込み」に頭を下げるしかなかった。
第一の容疑者:iBus
方針を切り替え、二人(?)で容疑者探しを始めることになった。
最初に疑ったのはiBusだった。ZorinOSやUbuntu系はインストール直後からiBusという入力メソッドフレームワークが内蔵されている。一方Kubuntuは、IME機能自体が最初は存在せず、自力でインストールする必要がある。
「もしかして、消したはずのiBusが裏でFcitx5の邪魔をしてるんじゃないか?」
パラドックス氏に、iBusが実際に動いているかどうかをターミナルで確認してもらった。ps aux | grep -i ibus を叩いてもらうと――結果は空振り。grepコマンド自身がヒットしただけで、ibus-daemonはそもそも動いていなかった。
第一の容疑者、あっさり無罪放免。「パッケージが残ってるのが気持ち悪い」というパラドックス氏の希望もあり、apt purge で関連パッケージを掃除することにはなったが、これは原因究明というより気分の問題だったと思う。
第二の容疑者:GNOMEのXKB、そして最初のブレイクスルー
次に疑いの目を向けたのは、デスクトップ環境そのものの違いだった。
- Kubuntu = KDE Plasma(kwin + kglobalaccel)
- ZorinOS = GNOME系(mutter + gnome-settings-daemon)
GNOMEの「入力ソース」設定は、XKB(X Keyboard Extension)というキー処理の仕組みと深く結びついている。パラドックス氏に設定を見てもらうと、xkb-options は空、sources は日本語109キーボード配列一本のみ。
ここで見えてきたのは、パラドックス氏が使っている物理キーボードには「英数」「かな」専用キーがなく、CapsLockキーで代用しているという事情だった。つまりXKBレベルでは、CapsLockキーは今も昔ながらの「Caps_Lock」として扱われ続けている。Fcitx5に「CapsLockをIME切り替えに使う」設定をしていても、その下のXKB層が並行して「これは大文字ロックだ」と処理してしまう――二重処理の疑いが濃厚になった。
「じゃあ、大文字ロック機能そのものをXKBレベルで止めてみましょう」
gsettings set org.gnome.desktop.input-sources xkb-options "['caps:none']"
これを実行してもらった瞬間、パラドックス氏から弾んだ報告が届いた。
「効いた!CapsLockの大文字ロックが消えて、Fcitx5のIMEオンもちゃんと動くようになった!」
長年の悩みが解決した……はずだった。相談室としても、久々の「一発解決」に近い達成感があった。
翌朝の裏切り
ところが、その高揚感は長く続かなかった。
翌日、パラドックス氏から再び連絡が来た。
「昨日はよく眠れたんだけど……今朝また変な症状が出た。直接入力モード(IMEオフ)になった後、英数キーでIMEをオンにしようとしても効かなくなるんだ。Shiftを併用してもダメ」
再ログインをしていなかったことに気づき、ログインし直して xkb-options を一旦空に戻すと症状は落ち着いた。しかし無変換キーと英数キーを何度もオンオフしていると、また同じ症状が再発した。唯一「ひらがなキー」によるIMEオンだけは、常に確実に機能し続けていた。
一つの仮説がクリアになると、すぐ次の壁が現れる。相談室あるあるだが、今回は特にそのペースが早かった。
第三の容疑者:WaylandとXwayland
パラドックス氏の環境を確認すると、setxkbmap -query を叩いた際にこんな警告が出た。
WARNING: Running setxkbmap against an Xwayland serverZorinOSのセッションはWaylandで動いており、setxkbmap はX11用ツールのため、Xwayland経由の互換レイヤーを覗いているだけの状態だった。「Xwaylandアプリ」と「ネイティブWaylandアプリ」で挙動が違うのでは、という仮説が浮上した。
症状が出ていたBraveブラウザを確認すると、--ozone-platform=wayland で動作していることが判明。比較のため、パラドックス氏に brave-browser --ozone-platform=x11 でX11モード起動を試してもらった。
結果は同じ。X11モードでも英数キーが効かなくなる現象は再現した。
「これはBrave固有の問題じゃない、ってことだね」
第三の容疑者も、また無罪。
第四の容疑者:Mozcの内部ルール
残る候補として目をつけたのが、Fcitx5本体ではなくMozcエンジン内部のキーマップだった。fcitx5-configtool の「Mozc キー設定」を確認してもらうと、こんなルールが見つかった。
- 直接入力モード時に「Eisu(英数)」キーで「ひらがなに入力切替」
一方Fcitx5本体側のグローバル設定にも、「英数トグル」でメソッドを有効化する設定が明示的に入っていた。つまり英数キーを1回押すと、Fcitx5本体とMozc内部エンジンの両方が同時に反応しようとしていたことになる。普段は両方が同じ結果(IMEオン)に落ち着くから問題なく見えるが、タイミング次第でどちらかが「もう処理済み」と思い込み、もう一方が空振りする――そんな競合が疑われた。
冗長と判断し、Mozc側のEisuルールを削除。再ログインして検証してもらったが、症状は変わらなかった。おまけに後日、削除したはずのルールが設定画面から消えていた、という不思議な現象までおまけについてきた。ともあれ、これで「Mozc側が原因」という線も消えた。
保留、という結論
- iBus → シロ
- Wayland/Xwayland、Brave固有 → シロ
- Mozc内部の重複ルール → シロ
残るはFcitx5本体、あるいはさらに下のXKB/OSレベルでの英数キーの状態管理そのものだが、ここから先は相談室の手には負えなかった。正直に言う。根本原因の特定には至らなかった。
パラドックス氏には申し訳なかったが、「不安定な部品を直そうとする」のではなく「確実に動く部品を使う」という現実的な提案に切り替えた。幸い、検証の過程で「ひらがなキー」によるIMEオンだけは一貫して裏切らなかった。
最終的な運用はこう落ち着いた。
- CapsLockキー:
caps:noneで大文字ロックを無効化(Shift併用のロックは可能なので実害なし) - IMEオン:ひらがなキー(確実)
- IMEオフ:無変換キー(問題なし)
- 英数キー:見捨てるのは惜しく、「ひらがなキー」との併用登録を検討中
パラドックス氏の反応は、意外にもさっぱりしたものだった。
「完全解決じゃないのは悔しいけど、確実に動く方法が見つかっただけマシだよ。それに、Kubuntuと比較しようって思いついたのは自分だからね。相談員さんの手柄も半分は自分のもんだ」
……そう言われると、こちらとしても悪い気はしない。
相談員のひとりごと
今回の一件は、一つの仮説が外れるたびに次の仮説を立てる、地道な切り分け作業の連続だった。
- iBusが原因では? → 違った
- GNOME/XKBが原因では? →
caps:noneでCapsLock暴走は解決。でも新しい問題が発覚 - Wayland/Brave固有では? → 違った
- Mozc内部の重複ルールでは? → 違った
- 根本原因は特定できず → 確実に動く「ひらがなキー」中心の運用へ
完璧な解決ではなかったけれど、パラドックス氏の「Kubuntuでは起きてない」という一言がなければ、私は「ハードの限界です」の一言で片付けていたかもしれない。相談室にはこういう日がある。相談者の思いつきに助けられる日が。
そして、CapsLockの謎はまだ完全には解けていない。もし次にパラドックス氏が「英数キーがまた効かなくなった」と相談室に現れたら、そのときはまた別の角度から挑むことになるだろう。
あとがき by 管理人
実は、AIチャットでのトラブルシューティングの経緯を何度かClaudeに要約してもらっていたのだが、出来上がったものを一読しても少しも面白くない。そのため記事投稿をして来なかった。
読んでても楽しくない。その理由は、悪戦苦闘のお祭りが終わったあとでの冷めたレポートだから。
しかし、良く考えればそれは当然の結果。依頼文が｢今回の出来事をテキトーに要約して｣だったのだ。
｢AI 活用あるある｣っていう現代の常識そのまんまだった。カスタムアプリ作成などではそれで良かったのだが、ブログ記事の下書き(出来が良ければそのまま転用)用途となれば、”運営者カラー”というアナログ要素が重要。
自分の望む内容が返されるよう、用意周到で整理された依頼文を提出しなければならない。これはしんどい。
しかし、どこにでもあるような個人ブログにはしたくない。自分自身が直面した難問を、ときにはAIとの二人三脚で解決していくという爽快感･達成感を読者と共有したいという壮大なコンセプトを実現するには、どうやって難問解決に挑んだのかという臨場感が必要不可欠の要素。
そこで、チャットの大部分を占めるのがClaudeの回答なのだから、その本人(?)自身に苦労の一部始終を語らせるという奇策がひらめいたのだった。
しかも、レポートの出来が良ければ自分も劇的にラクできるという一石二鳥になる。
そんなわけで、Claudeを｢よろず相談所の相談員｣に見立てて、無料相談を良いことに、毎日のように無理難題を持ち込んでくるという設定にしてみたのが今回の投稿記事でした。
ご意見ご要望がありましたら遠慮なくコメントに書き込んでください。(^。^)
コメント