Google版リモートデスクトップツールの登場
リモートデスクトップの歴史は古い。我々が普段使用しているWindows OSに搭載されたリモートデスクトップやリモートアシスタンスは、Windows XP以降から実装された機能だが、その元となる技術はCitrix SystemsがOS/2向けに開発したCitrix MULTIUSERまでさかのぼる。その一方で、UNIXのGUI環境を構築するソフトウェアであるX Window Systemのクライアント/サーバーの分類という概念も、リモートデスクトップに大きく寄与しているだろう。
使用中のコンピューターから遠方などに設置したコンピューターをGUI操作するリモートデスクトップには様々な実装形式がある。AT&Tケンブリッジ研究所が基礎を作り上げたVNC（Virtual Network Computing）は、デスクトップを複数のブロックに切り分け、変更が加わった部分のみを送信する差分方式を用いているため、シンプルなアプリケーションであれば問題ないが、動画などデスクトップの大部分をリアルタイムに書き換えるような用途に向いていない。
Windows OSの各リモートツールが使用するRDP（Remote Desktop Protocol）はT-120プロトコルを基にMicrosoftが独自拡張を行ったプロトコルであり、ウィンドウフレーム単位の差分情報（画像）を送信することで、ほかのリモートデスクトップとは異なるパフォーマンスを実現している（図01）。
 |
図01 Windows OSに標準で搭載済みのリモートデスクトップ。クライアントOSの場合、一部のエディションはクライアント機能のみとなる |
このように様々な実装形式を用いて各社が改良を重ねたリモートデスクトップツールは、機材や人材資源といったTCO（Total Cost of Ownership）の軽減につながると同時に、システム管理者としては利便性の向上も実現できるため、古くから注目を集めながら利用されてきた。
このリモートデスクトップツール類に新たに加わるのが、Googleの「Chrome Remote Desktop BETA」である。その名からもわかるとおり単独のツールではなく、Google Chromeの拡張機能に位置し、同Webブラウザーが動作する環境（Windows/Mac/Linux/Google Chrome OS）であれば、相互的なリモートデスクトップ接続が可能だ。執筆時点ではベータ版だが、Googleがリリースするアプリケーションの大半は“永遠のベータ版”であるため、さほど気にする必要はない。
LAN環境では実用レベルのパフォーマンス
まずは実際の接続手順から確認しよう。具体的にはリモート接続するコンピューターと接続を受け付けるコンピューターに、Google ChromeおよびChrome Remote Desktop BETAが導入済みであり、同一もしくは異なるGoogleアカウントが必要となる。また、接続はLAN内に限らず、インターネット経由の接続にも対応している。
各Google ChromeにChrome Remote Desktop BETAを導入し、一方のコンピューターで＜このパソコンを共有＞ボタンをクリックして、アクセスコードを自動生成される。もう一方のコンピューターでは＜共有したパソコンにアクセス＞をクリックして、アクセスコードを入力。これでリモートデスクトップ接続が完了した（図02～10）。
 |
図02 Chrome Remote Desktop BETAはGoogle Chromeでダウンロードページにアクセスし、ボタンをクリックして導入する |
 |
図03 Chrome Remote Desktop BETA導入後は新規タブにアプリケーションとして列挙される。これをクリックする |
 |
図04 最初にChrome Remote Desktop BETAを使用するための認証処理が必要となる。＜続行＞ボタンをクリックする |
 |
図05 ここでGoogleアカウントのログオン処理を経てアクセス（リモートデスクトップ接続）許可を行う |
 |
図06 次にリモート接続を受け付けるか、リモート接続を行うか選択を行う。ここではリモート接続を受け付け処理を行うため、＜このパソコンを共有する＞をクリック |
 |
図07 ランダムに生成されるアクセスコードが表示されるので、こちらをメモする。これで共有準備は完了だ |
 |
図08 こちらは同様の処理を行った別のGoogle Chrome。リモートデスクトップ接続を行うため、＜共有したパソコンにアクセス＞をクリック |
 |
図09 先ほどのアクセスコードを入力して＜接続＞ボタンをクリックする |
 |
図10 これでChrome Remote Desktop BETAによるリモートデスクトップ接続が完了した。切断時はデスクトップ上部に現れるメニューバーの＜切断＞ボタンをクリック |
実際の操作感覚だが、ギガビットLAN経由ではウィンドウの切り替えが引っかかる程度で全体的な操作に問題は生じなかった。その一方でインターネット経由の接続も特定の問題は発生せず、簡単に接続完了。これはGoogleアカウントと共有するたびに自動生成されるアクセスコードの二つでセキュリティを維持しているからだろう。なお、いずれの接続ケースでも、五分程度でセッションが自動的に切れる仕組みである。
インターネット経由の接続は、LANに比べてネットワーク帯域が狭いため、快適とは言い難かった。実験環境として100Mbps接続のFTTH回線に接続したコンピューターから、マンションに組み込まれたVDSL回線（局との接続はFTTH）に接続したコンピューターへリモートデスクトップ接続したが、ウィンドウの切り替えにも数秒ほど待たされるため、使いこなすにはコツが必要かもしれない（図11）。
 |
図11 デスクトップとは異なるネット回線に接続したモバイルコンピューターにリモートデスクトップ接続してみた |
メディアファイルの再生は現時点ではサポートされていないらしく、音楽ファイルを再生するとリモート接続先のコンピューターで再生されてしまう。その一方で動画再生は一秒間に数フレームしか描くことができなかった。Chrome Remote Desktop BETAがどのような実装を用いてリモートデスクトップ接続を実現しているのか、現時点で公表されていないが、このあたりは今後実装されるのか興味深いポイントである（図12）。
 |
図12 リモートコンピューターのデスクトップをそのまま描画するため動画再生なども可能だが、数フレーム/秒の再生となる |
日本語入力はインプットメソッドが同一であれば対応するが、リモートデスクトップ接続元がATOK、接続先がMS-IMEなどのように異なる場合、キーによってIMEを有効にすることができなかった。この場合コンテキストメニューの＜IMEを開く＞を選択することで、入力可能になる。我々日本人としては、この点も改善して欲しいポイントだ（図13）。
 |
図13 各コンピューターで異なるIMEを用いている場合でも、メニューから＜IMEを開く＞を選択すれば日本語入力は可能だ |
マルチプラットフォームで同じ使用感を得られる
最後にChrome Remote Desktop BETAを使用するシチュエーションを想定してみる。前述のとおりメディア関連の機能は、先発組となるWindows OSのリモートデスクトップ接続に至らず、インターネット経由の接続はネットワーク帯域に左右されるため、現時点での評価は難しい。
しかし、それらを踏まえてもChrome Remote Desktop BETAが上回っているのが、接続の容易さだ。Googleアカウントによる認証と、接続ごとに自動生成されるアクセスコード認証は呆気ないほど簡単。セキュリティ面もデスクトップ共有を有効するたび、新しいアクセスコードが生成されるため、Googleアカウントが漏えいしなければ、不特定多数の攻撃に晒（さら）される可能性が低いのは嬉しい。
もう一つのアドバンテージは多用なプラットフォーム。例えばWindows OSのリモートデスクトップ接続は、rdesktopというオープンソースベースのソフトウェアで接続可能だが、執筆時点でサポートしているのはRDPバージョン5まで。Windows VistaでサポートされたRDP6やWindows 7のRDP7や7.1は未サポートのため、同一の使用感になることはない。
その点Chrome Remote Desktop BETAは、特殊な描画機能は備えていないものの、WindowsでもMacでもLinuxでも同一の認証方式とUI（ユーザーインターフェース）を用いることになるため、複数の異なるOSを使っているユーザーには大きなアドバンテージとなるのではないだろうか。
Chrome Remote Desktop BETAが、ほかのGoogleアプリケーションと同じようにバージョンを重ねながら多機能と安定性を誇るリモートデスクトップツールになる可能性は高い。業務やプライベートでリモートデスクトップツールを活用しているユーザーは、Chrome Remote Desktop BETAの今後に注目すべきだろう。
阿久津良和（Cactus）