リモートMacのキーボード配列と入力方式を検証する

クラウド上のMacへリモート接続した後、最も見落とされやすい問題はネットワーク切断ではなく、キーボードが「一応使える」ものの完全には正しく動作していない状態です。たとえば、CommandとOptionが入れ替わる、数字キー列の記号がずれる、日本語入力の候補操作キーがクライアントに奪われる、自動化スクリプトで入力される文字が手動操作と一致しない、といった問題があります。ツールチェーンを構成してから発覚すると、原因がローカルOS、リモートクライアント、macOSの入力ソースのどこにあるのかを切り分けるのが難しくなります。より確実なのは、ワークスペースを初期化する前に入力環境を検証することです。

まず3層の入力経路を固定する

1回のキー入力は、ローカルのキーボード配列、リモートクライアントのマッピング、クラウドMacの入力ソースの順に処理されます。3層を同時に変更すると結果を再現できなくなるため、すぐに設定を変えるのではなく、まず現在の状態を記録します。

ローカル側では、物理キーボードの種類、現在の配列、リモートクライアントで「システムショートカットを送信」「CommandとOptionを入れ替える」といったオプションが有効になっていないかを確認します。クラウドMac側では、システムのバージョン、有効な入力ソース、ユーザー単位のキーマッピングを記録します。

sw_vers
defaults read com.apple.HIToolbox AppleEnabledInputSources
defaults read com.apple.HIToolbox AppleCurrentKeyboardLayoutInputSourceID
hidutil property --get "UserKeyMapping"

最後のコマンドが空の配列を返す場合、ホスト側では hidutil によるユーザーマッピングが追加されていません。マッピングが存在する場合は、まず出力を保存し、それがチームの基準設定に含まれるものかを確認します。既存設定の出所が分からないまま、2つ目の入れ替えルールを重ねないでください。

修飾キーの変換を担当する層は1つだけにします。クライアントですでにキーを入れ替えている場合、ホスト側で同じマッピングを適用しないでください。

文字マトリクスで配列のずれを特定する

エディタを開いて数文字を入力するだけでは不十分です。エディタのショートカット、コード補完、自動置換の影響を避けるため、プレーンテキストのウィンドウで決められた順序に従ってテストします。

記号をテストするときは、各メンバーのキー刻印を基準にするのではなく、US ANSIなど、チームで使用する論理配列を明確に定めます。リモートマシンを自動化タスクに使用する場合は、開発者ごとのローカル設定を再現するより、論理配列を統一するほうが確実です。

テキストの自動置換による影響を除外する

直線引用符、ハイフン、連続するスペースが自動的に置換される場合は、まずプレーンテキストモードで再テストします。文字自体は正しいのにエディタで異なる結果になる場合、通常はアプリケーション側のテキスト処理が原因です。システムのキーボードマッピングを変更し続けるべきではありません。

修飾キーとショートカットを個別に検証する

修飾キーの問題は、特定の組み合わせにだけ発生することがあります。Command+Cが正常でも、Option+数字、Control+英字、Command+Shiftの組み合わせまで正しいとは限りません。コピー、ウィンドウ切り替え、単語単位の移動、大文字・小文字の組み合わせ、クライアントが予約しているキーを網羅する最小限のショートカットセットを用意します。

ホスト側に誤ったマッピングが残っていることを確認できた場合は、現在のログインセッションで消去できます。

hidutil property --set '{"UserKeyMapping":[]}'

消去後は、必ずリモートセッションを切断してから再接続し、文字マトリクスをもう一度実行します。問題が解消した場合は、メンバーに手動で設定を変更させるのではなく、修正をセッション初期化スクリプトへ組み込みます。問題が残る場合はホストの基準設定を復元し、クライアントのキー転送ルールを重点的に確認します。

クライアントによるキー操作の奪取を見分ける

特定のキーの組み合わせだけがリモートデスクトップへまったく届かず、ほかの組み合わせが正常に動作する場合、通常はローカルシステムまたはクライアントが先にその操作を処理しています。この場合はテスト用の組み合わせを変更するか、クライアント設定を調整します。送信されていないキー操作をホスト側の再マッピングで補わないでください。

入力方式と自動化の境界を検証する

入力方式のテストでは、少なくとも入力ソースの切り替え、連続した文節の変換、候補ページの切り替え、Enterによる確定、全角・半角の句読点、およびターミナルとGUIアプリケーション間での一貫性を確認します。パスワード欄、ターミナルのセキュア入力モード、一部のリモートクライアントでは組み合わせ入力が制限される場合があるため、1つのアプリケーションだけで結論を出してはいけません。

自動化タスクを「現在の入力方式」に依存させないでください。スクリプトで設定ファイル、バージョン番号、テストデータを生成する場合は、UTF-8ファイルへ直接書き込むか、コマンド引数で値を渡します。GUIを操作するテストでも、開始前に合意済みの入力ソースへ切り替え、現在の入力ソース識別子をログへ記録します。これにより、業務テストの失敗と入力環境のずれを切り分けられます。

VMOak上で長時間実行するタスクでは、入力ソースの一覧と文字マトリクスの結果をノード初期化記録の一部に含めることを推奨します。短時間のリモート操作でも、少なくともクライアントのバージョンと選択した配列は保存してください。

再接続後に再テストして基準を作成する

入力検証には、完全な切断と再接続を1回含める必要があります。アプリケーションのウィンドウを閉じるだけでは不十分です。リモートセッションを終了して再接続し、現在の配列、修飾キー、入力ソースをもう一度確認します。再接続後にだけ状態がずれる場合は、クライアントが接続設定に基づいて配列を上書きしていないか、ログイン時に設定スクリプトが実行されていないかを重点的に確認します。

最終的な基準は簡潔なもので構いません。

1. 論理キーボード配列を1つに統一する。
2. 修飾キーを入れ替えるのは、クライアント側またはホスト側のどちらか1層だけにする。
3. AppleEnabledInputSources と UserKeyMapping の出力を保存する。
4. 文字マトリクスと5グループのショートカットをすべてテストする。
5. ターミナルとGUIアプリケーションで入力方式をそれぞれ1回テストする。
6. 切断して再接続した後、重要項目を再確認する。

入力問題への対処で重要なのは、「今回は使える状態にする」ことではありません。変換を担当する層を1つに特定し、次回の接続でも同じ結果を得られるようにすることです。この基準を確立してから開発用の依存関係をインストールしたり、自動化タスクを接続したりすれば、その後の障害も原因を特定しやすくなります。

よくある質問