Windows 8がタイルUIを採用する意図、そして“面倒な制約”とは──ここまで判明、「Windows 8」詳報：COMPUTEX TAIPEI 2011（4/4 ページ）

[鈴木淳也（Junya Suzuki），ITmedia]

今後のWindows 8の課題　ハードウェアベンダーが「面倒な制約がある」と述べた理由は？

　外見が大きく変化すると思われるWindows 8だが、より内部的な変化もみられると筆者は考えている。アンギウロ氏はHTML5で記述されたWebアプリケーションがWindows 8におけるメインのアプリケーション実行環境であり、今後はネイティブコードよりもWebプログラミングが中心になると示しているためだ。問題はWindows Phone 7のメインの開発環境が「Silverlight」であり、こちらの今後の戦略の変化が気になるのだが、Microsoftとしてはもう“Webプログラミング”に主軸を置くよう開発者らを誘導しているように思える。

異なるフォームファクタでも同じアプリケーションが動作するのがWindows 8の特徴だ。アンギウロ氏が手に持つのはWindows on ARM上で動作するピアノアプリケーションだが、同様のものがWindows PCのデスクトップマシン上でも動作している。このアプリケーションはHTML5ベースで記述されており、「すべてのWindows 8アプリケーションはハードウェア支援を受けたWebアプリケーションとして動作する」のが基本だという（写真＝左）。Windows 8におけるハードウェア要件の中では、UEFIに注目。Windows 8プラットフォームではARMを含むすべてのマシンでUEFIが必須になるという。これにより起動速度が従来のBIOSに比べて5、6秒程度での起動が可能になるほか、2Tバイト以上のストレージ管理も可能になるという（写真＝中央）。Windows 8ではアスペクト比16：9が標準になるという（写真＝右）

　これは同時に、Windows on ARMでは従来のアプリケーションがそのままでは動作しない可能性も示している。一部ではWindows on ARMでも既存のアプリケーションやネイティブコードがそのまま動くと報じられているが、アンギウロ氏自身はそうした話題には触れず、あくまで「Windows 8のアプリケーションはWebベース」「Windows 7におけるシステムをそのまま8へと移行できる」と述べただけだ。既存のWindowsアプリケーションは、x86系プロセッサで動作するWindows 8なら普通に動くだろうが、それがそのままARM環境でも動作するものではないと筆者は考える。実際、エミュレーション動作はx86系CPU比で非力なARMにとってはつらい作業であり、バイナリトランスレーションのような仕組みを用意したとしてもパフォーマンスの大きな低下は避けられない。搭載メモリ量が顕著に異なることも問題と思われ、ARMでは多くて1Gバイト、最大でも2Gバイト程度の搭載量にとどまるであろうことを考えれば、そのままWindowsアプリケーションやシステムを持ち込むのは得策ではないと思える。

　ちなみにアンギウロ氏は、現段階で伝えられるWindows 8のハードウェア要件として以下を挙げた。

• UEFIの搭載
• 各種センサーのサポート
• タッチスクリーンの感知範囲
• アスペクト比16：9のディスプレイ

　UEFIはSandy Bridge世代のCPUでWindows搭載PCの世界にも少しずつ一般ユーザーに広がりつつあるBIOSに変わるPCファームウェアだが、これによりブートシーケンスが40％ほど高速化し、5、6秒程度のインスタント起動が可能になるという。このほか（UEFIとは直接関係ないが）ARM世代のマシンの特徴として“always-on”（常時起動）が重要になるとも示唆している。これはマシンがスリープ状態でもバックグラウンドでメールチェックや各種通知情報を受信する機能のことで、いわゆる携帯電話の待機状態に近いものだ。こうした細かい制御が今後はより重要になるという。

　各種センサーのサポートについては前述の通りだが、搭載するセンサーが多いほど動きや状態をより正確に追尾できるようになる。加速度センサーだけではデバイスの正確な位置や移動量などを把握できないが、これに磁気センサーとジャイロスコープを組み合わせることでより正確な動きを追尾できるといった感じだ。センサーAPIの標準提供は、これを推奨するものになるとみられる。

多くのハードウェアベンダーにとって課題の1つとなりそうなのがこのタッチセンサーのカバー範囲だ。Windows 8ではシステム操作やアプリケーションのメニュー操作で、画面端の部分のタッチ認識が必須となる。そのため、画面端のピクセルでタッチ認識できないようなデザインでは、正しいタッチ認識が行われないことになりかねない。Microsoftでは「スクリーン全面まで広がるガラス面」のような表現をしており、例えると初代iPadライクなデザインが必要になるのかもしれない

　そしてハードウェアベンダーにとって大きな課題となるのが「タッチスクリーンの感知範囲」と「16：9のスクリーンサイズ」の2つだ。前述のようにWindows 8のUIは、画面の端から指をなぞってシステムメニューを呼び出す機能が特徴の1つだ。だが、肝心の画面端のピクセルをタッチで感知できなければこの操作スタイルは実現できない。仮に画面の周囲を枠で表示ピクセルぎりぎりまで囲い込むようなデザイン・構造のデバイスの場合、こうしたタッチスライド操作は難しいわけだ。

　そのためMicrosoftは、ガイドラインとして“全面ガラススクリーンのようなタッチディスプレイの採用”を持ちかけている。また、ディスプレイのアスペクト比は16：9を規定しており、解像度も1366×768ドット（以上？）を推奨している。さらには両手で持って使うシーンを検知するために、やはり本体にはそれ専用のセンサーが必要になる。

今回は、ソフトウェアの互換性、ドライバに関する情報、既存のWindows 7からのマイグレーション、Windows 8プログラミングなど、ソフトウェアに関する重要な情報はほとんど提供されていない。そのためMicrosoftでは、過去に実施されたPDC、WinHEC、MIXといった3つの開発者カンファレンスを1つに統合し、「Build Windows」と題したカンファレンスを2011年9月13日〜16日にかけて米カリフォルニア州アナハイムで開催する予定。これは、今年のMIX11カンファレンスでWindows 部門トップのスティーブン・シノフスキー氏が「謎のカンファレンス」として予告していたものだ

　以上をまとめると、ハードウェアベンダーにとってWindows 8デバイスの開発は「非常にデザイン上の制約が大きいものになる」可能性が高いといえる。このWindows 8のUI公開前に台湾AcerのJ・T・ワン会長兼CEOが「Windows 8ハードウェア開発に“面倒な制約”がある」とコメントしたという報道があったが、振り返れば、こうしたハードウェアの制約はその「面倒な制約」の一部であるといえるかもしれない。

　またWindows Phone 7でUIのカスタマイズがいっさい認められていないように、「統一的なユーザー体験」の実現のためにWindows 8でもベンダーによるUI改変が許されない可能性が高い。Androidなどではベンダー各社が独自のUIを工夫でき、それぞれに個性を出している経緯もある。それを考えれば、フォームファクタの違いこそあれど、Windows 8ではいわゆる画一的なハードウェアが出そろう可能性があるのは否めない。Windows Phone 7と違いハードウェアスペックまで縛ることはないと思うが、独自の開発力をアピールしてきたベンダー各社にとっては差別化のポイントを見直す必要が出てくるかもしれないだろう。

　ともあれ、Windows on ARMの互換性、既存資産の継承、エンタープライズ分野での戦略、クラウドとの連携、ドライバの記述、その他各種要件など、Windows 8にはまだまだ不明な部分は多い。アンギウロ氏は最後に「Build Windows」というカンファレンスが2011年9月13日〜16日まで期間、米カリフォルニア州アナハイムで開かれることを告知した。すべてはここで明かされることになりそうだ。