「RemoteApp」における悩ましき日本語入力環境の問題：その知識、ホントに正しい？ Windowsにまつわる都市伝説（32）

「RemoteApp」は、フルデスクトップ接続よりも速くて軽い、しかもネットワーク使用帯域を節約できると、いいことずくめのようですが、日本語入力環境に悩ましいところが……。

» 2015年05月26日 05時00分公開

[山市良，テクニカルライター]

RemoteAppの進化に置いてけぼりの日本語環境

　「RemoteApp」は、リモートのサーバーやVDI（仮想デスクトップインフラストラクチャ）で実行されるアプリケーションの“ウィンドウだけ”をローカルのデスクトップ上にシームレスに統合して表示する機能。Windows Server 2008の「リモートデスクトップサービス（RDS）」および「リモートデスクトッププロトコル（RDP）6.0」以降のテクノロジです。以下の記事で紹介したクラウドベースの「Microsoft Azure RemoteApp」も全く同じテクノロジで実現されています。

　前回説明したように、RemoteAppはログオンが速い、リソース使用量が少ない、ネットワーク使用帯域を節約できるなど、デスクトップ全体に接続するのと比べると、いろいろと良い点があります。

　しかし、これは筆者の個人的な考えかもしれませんが、日本語入力環境に関して不都合なことが多いような気がします。日本語と同様にIME（Input Method Editor）を使用する中国語や韓国語の環境も同様の問題を抱えているのかもしれませんが、筆者は中国語や韓国語の言語入力事情に詳しくないのではっきりしたことは分かりません。

RemoteAppはサーバー側のIMEを使う

　RemoteAppはリモートデスクトップ接続のデスクトップ全体への接続から、アプリケーションウィンドウだけを切り出して表示しているようなイメージです。

　デスクトップ全体への接続の場合、アプリケーションの入力にはリモートセッション内の日本語入力システム（以下、IME）が使用されていることに何の疑問も持たないでしょう。リモートの画面を表示しているだけで、こちら側はキーボードとマウス操作を転送するだけなのですから当然です。ただし、AndroidやiOS向けのRemoteAppクライアントでは、ローカルとリモートのどちらのIMEも利用できるようですが、今回の話はWindowsクライアントについての問題です。

　RemoteAppでリモートのアプリケーションを実行する場合も、日本語入力に関して違いはありません。アプリケーションへの日本語入力には、リモートデスクトップ（RD）セッションホストの役割を実行するリモートのWindows ServerのIMEを使用します。VDI環境の場合は、リモートの仮想マシンのゲストOSであるWindows 8.1 EnterpriseやWindows 7 EnterpriseのIMEになります。

　RemoteAppのテクノロジはWindowsのバージョンアップとともに進化しており、IMEの統合が進んでいます。初期のころはリモートのIMEがデスクトップ上に浮かんでいましたが、Windows 7ではタスクバーに統合できるようになりました。

　以下の画面1は、Windows 7クライアントからRDセッションホストの「Word」に、RemoteAppで接続しているところです。日本語入力のためのIMEの言語バーは、Windows 7のタスクバーに格納されています。このユーザーセッションに対して、「シャドウセッション」機能（二つのリモートデスクトップから同じセッションに接続できる機能、シャドウイングともいう）を利用して接続してみると、Wordアプリケーションに加えて、IMEの言語バーもサーバー側で実行されていることを確認できます（画面2）。

画面1　Windows 7からRDセッションホストの「Word」をRemoteAppで実行しているところ。タスクバーに格納されているIMEはリモート側のもの

画面2　シャドウセッション機能でRemoteAppのユーザーセッションに接続すると、IMEの言語バーがサーバー側にあることが分かる

　なお、RemoteAppにおけるIMEの統合が進んだといっても、一方で接続元のWindows 7側のタスクバーの高さが変わってしまったり、ローカルのIMEの位置が移動したり、ローカルとリモートの両方のIMEが同時に表示されてしまったりといった不具合もあります。

ローカル？リモート？ユーザー辞書はどちらを使う？

　RemoteAppにおけるIMEの統合は、ユーザーエクスペリエンスを向上させることを目指した機能強化なのでしょう。しかし、日本語環境ではそうともいえません。日本語環境では、日本語入力における変換の学習や、ユーザー辞書が入力エクスペリエンスの大きな部分を占めていると思うのですが、RemoteAppのIMEの統合は逆に入力エクスペリエンスを低下させていると筆者は考えるのです。

　例えば、ローカル環境でユーザーが育てた学習情報や辞書は、RemoteAppプログラムでは利用できません。RemoteAppのアプリケーションへの日本語入力には、リモート側のIMEが使用されるため、学習情報やユーザー辞書もリモート側のものが使用されます（画面3）。

画面3　RemoteAppのアプリケーションへの日本語入力に使用される学習情報やユーザー辞書はリモート側のもの

　ユーザー辞書や学習情報は「ユーザープロファイル」に格納されています。Active Directoryドメインの「移動ユーザープロファイル」を使えば、辞書や学習情報をローカルのWindowsとリモートデスクトップ接続先のリモートセッションで共有できるかもしれません。

　実際、同じ種類の同じバージョンのIMEを使用していれば、辞書や学習情報の共有はできているように見えます。しかし、移動ユーザープロファイルは、ユーザーが同時に複数のWindowsにログオンすることを想定して作られてはいません。RemoteAppのセッションで新たに学習された内容や辞書登録は、RemoteAppのアプリケーションを終了して、リモートからログオフした時点で移動ユーザープロファイルに反映されます。しかしそれは、その後のローカルのWindows環境からログオフしたときに、ローカルの学習内容や辞書登録で上書きされてしまいます（画面4）。

画面4　移動ユーザープロファイルは根本的な解決策にならないばかりか、別の問題を発生させる可能性も

　このような問題が予想されるため、ローカルのWindowsとRDS用で同じ移動ユーザープロファイルを使用するべきではありません。移動ユーザープロファイルの競合を回避できるように、Active Directoryでは「RDS専用の移動ユーザープロファイル」を設定できるようになっています。

　ちなみに、Windows Server 2012以降のRDS／VDI、およびAzure RemoteAppは「ユーザープロファイルディスク」というユーザー専用の仮想ハードディスクをセッションに割り当ててユーザー環境をローミングするようになっているため、移動ユーザープロファイルを使用するように構成していなくても複数のサーバーで構成されるファームや、VDIの仮想デスクトッププール内でユーザー環境をローミングすることができます。

Windows 8以降でIME統合はさらに進み、もっと厄介なことに

　Windows 8以降では、RemoteAppのIME統合がさらに進んでいます。リモートのIMEを使用する点は変わりませんが、ローカルのIMEのGUI（Graphical User Interface）をRemoteAppのアプリケーションへの日本語入力のフロントエンドとして利用するようになったのです。

　以下の画面5は、Windows 8.1クライアントからRDセッションホストのWordにRemoteApp接続したときのものです。また、画面6はそのユーザーセッションにシャドウセッション機能で接続したところです。言語バーを外に出しても同じです。

画面5　Windows 8.1クライアントからRemoteAppアプリケーションへの日本語入力は、ローカルのIMEを使用しているようにしか見えない

画面6　シャドウセッションにもサーバー側のIMEは表示されない

　Windows 8以降では、RemoteAppのアプリケーションへの日本語入力に、ローカルのIMEを使用しているようにしか見えません。しかし、前出の画面3を見れば分かるように、学習情報やユーザー辞書はリモートのものを使用しています。ローカルのIMEのGUIをフロントエンドとして利用しているのです。

　Windows標準の「MS-IME」では分かりにくいと思いますので、ジャストシステムの「ATOK」の環境で説明しましょう。

　以下の画面7は、RDセッションホストにATOKをインストールし、クライアントはMS-IMEのみという状況で、MS-IMEしか存在しないWindows 7とWindows 8.1からRemoteAppでWordを実行したところです。Windows 7では、リモートのATOKを使用して日本語入力ができます。一方、Windows 8.1はフロントエンドとなるATOKのGUIがローカル側に存在しないため、ATOKによる入力ができません。

画面7　Windows 7クライアントからはサーバー側のATOKでの入力が可能（画面上）。Windows 8.1クライアントはサーバー側のATOKを利用できない（画面下）

　Windows 8.1クライアントでサーバー側のATOKを利用するには、ローカルのWindows 8.1環境にATOKをインストールする必要があります（画面8）。これで、サーバー側のATOKのエンジンがローカルのATOKのフロントエンドと対話して、ATOKによる日本語入力が可能になります。

画面8　Windows 8.1の場合、RemoteAppで特定のIME（この場合はATOK）による日本語入力を可能にするには、ローカルにもリモートと同じIMEがインストールされている必要がある

Windows 8以降でIMEの設定に触れられない問題

　Windows 8以降におけるRemoteAppのIME統合の最大の問題は、リモート側のIMEの設定を操作できないことでしょう。方法はあるのかもしれませんが、筆者は確認できていません。

　先ほど説明したように、Windows 8以降ではRemoteAppでローカルのIMEの言語バーがフロントエンドとして使用されます。このローカルの言語バーを操作してリモートのIMEの設定や辞書ツールを開こうとしても、言語バーにマウスで触れた途端にローカルのIME環境に切り替わってしまい、ローカルのIMEの設定や辞書ツールが開いてしまうのです。

　この問題の解決策があるとすれば、筆者が思い付いたのは「IMEの設定」（%Windir%￥System32￥IME￥IMEJP￥IMJPSET.EXE）と「ユーザー辞書ツール」（%Windir%￥System32￥IME￥IMEJP￥IMJPDCT.EXE）をRemoteAppで公開することです（画面9、画面10）。

画面9　IMEの設定（%Windir%\System32\IME\IMEJP\IMJPSET.EXE）とユーザー辞書ツール（%Windir%\System32\IME\IMEJP\IMJPDCT.EXE）をRemoteAppで公開する

画面10　この方法がWindows 8以降のユーザーがリモート側のIMEを設定できる唯一の方法かもしれない

さらに日本語環境では「外字」の問題も

　これはRemoteAppだけでなく、RDS／VDI環境に共通の問題ですが、日本語環境では「外字」の問題もあります。

　Unicodeが普及した今となっては、外字を必要とする状況はほとんどなくなったと思います。しかし、シフトJIS時代のレガシーなデータ資産を抱えている場合は、過去のデータを正しく表示したり、印刷したりするために外字が必要な場合もあるでしょう。

　RDS／VDI環境においても、外字の扱いはローカルのWindows環境と変わりません。リモートデスクトップ接続のセッションやRemoteAppのアプリケーションで外字を利用したければ、RDセッションホストやVDIの仮想マシン側に外字を登録しておく必要があります（画面11）。

画面11　レガシーなデータ資産を抱えている場合は、RDS／VDI環境において外字への対応も必要。外字登録が必要なのは、リモート側だということを忘れずに

「その知識、ホントに正しい？ Windowsにまつわる都市伝説」バックナンバー

筆者紹介

山市良（やまいちりょう）

岩手県花巻市在住。Microsoft MVP：Hyper-V（Oct 2008 - Sep 2015）。SIer、IT出版社、中堅企業のシステム管理者を経て、フリーのテクニカルライターに。マイクロソフト製品、テクノロジを中心に、IT雑誌、Webサイトへの記事の寄稿、ドキュメント作成、事例取材などを手掛ける。個人ブログは『山市良のえぬなんとかわーるど』。

ファイル共有プロトコルSMB／CIFS（その1）
今回より、Windowsネットワークの核心、SMB／CIFSに入る。ネットワーク設計やトラブルシュートなどで不可欠な知識だ。
ファイル共有プロトコルSMB／CIFS（その2）
Windowsネットワークの核心、SMB／CIFS解説の第2回。SMBプロトコルにおけるリソースの公開とその使用までの処理を追う。
ファイル共有プロトコルSMB／CIFS（その3
SMB／CIFSプロトコルのパケットの構造やコマンド・コードの詳細。Windowsネットワークのトラシューには必須の情報だ。
強化されたファイル共有プロトコルSMB 3.0の概要
Windows Server 2012ではファイル共有プロトコルが強化され、SMB 3.0となった。クラスター環境対応やスケールアウト／マルチチャンネル対応などによるパフォーマンス改善、そして管理機能の強化と、改善点は多岐にわたる。本稿ではその概要をまとめておく。