Microsoft は、パフォーマンス、電源管理、バッテリ効率、メディア再生、互換性といった幅広い領域をカバーする Windows 8 の改良点をまとめて公開いたします。これらの改良点は Windows Update 経由で本日より提供を開始いたしました。今回の記事では、今回の更新プログラムが迅速な提供開始に至った経緯を中心に、エンジニアリング システムに対する改良の内容を簡単に説明いたします。

これまでは、あらゆる Windows のリリースで、Windows のコードを OEM や製造メーカーに提供してから最新 PC に搭載され一般のお客様に製品が提供されるまでに 8 ～ 12 週間かかっていました。この期間は従来、新規コンポーネントや強化コンポーネント、ドライバー、付属ソフトウェアを搭載する新たに開発された PC と、Windows の最終版コードとの連携確認に使われていました。最新のソフトウェア コンポーネントとハードウェア コンポーネントであることから、この段階で Windows の基礎部分に対する変更と改良が必要になることが判明することもありました。

その後 Microsoft が、これらの最新 PC を提供する OEM 向けの数多くの変更点に対処します。変更は PC の製造期間中に実装されるため、お客様が気付くことはありません。また、より多くの PC にこれらの変更が当てはまる可能性がありますが、これらを更新プログラムとして広く配布するためのテストと認定が間に合いません。結果としてお客様には、最初のサービス パックが提供されるまでこれらの強化点の利用をお待ちいただいていました。Microsoft は、作業をしていてこうした OEM 向け強化点の内容に気付きつつ、最新版への Windows の更新を待たなければならなかった多くのお客様がいたことを認識しています。

私たちは Windows 8 の最終段階の数か月間を通して、今回のような "ポスト RTM" の更新プログラムをサービス パックに先立って提供するためのツールとプロセスの構築という課題を自らに課しました。そして、テスト自動化やテスト カバレッジを強化するツールを開発したことで、一般提供開始の時点であらゆるお客様に最新の Windows 8 をお使いいただけるようになったことをご報告いたします。MSDN ご利用のユーザーまたは企業ユーザーの皆様は、各月の第 2 火曜日の午前 10 時ごろという Windows Update の通常の公開ペースに従って、今回の更新プログラムを本日 (10 月 9 日) より Windows Update 経由で各自の Windows 8 PC に適用していただくことができます。

通常の更新プログラムと同様、今回のすべての更新プログラムにサポート技術情報 (KB) 記事とドキュメントが提供されます。ドキュメントはここ (機械翻訳) からご確認いただけますが、今回の記事の終わりにも再録いたしました。もちろん、Windows 7 での取り組みと同様に、変更点と強化点の公開と文書化は本日以降も続けてまいります。

新たな提供ペースで公開される今回の高品質な更新プログラムが、あらゆるお客様にとって有意義なものになることを期待しております。

--Steven

サポート技術情報のタイトル:

“Windows 8 および Windows Server 2012 の一般提供版に対応する累積的な更新プログラム”

説明:

Windows 8 クライアントおよび Windows Server 2012 の一般提供版に対応する累積的な更新プログラムが公開されました。この累積的な更新プログラム パッケージは、Windows 8 エクスペリエンスの強化を目的としたパフォーマンスと信頼性に関する改良点をまとめたものです。定期的なメンテナンス作業の一部として、この累積的な更新プログラムを適用することをお勧めします。

改良点:

• 電源効率の向上によるバッテリ寿命の延長
• Windows 8 アプリケーションおよびスタート画面におけるパフォーマンスの向上
• 多くのシナリオにおけるオーディオおよびビデオ再生の強化
• Windows 8 のアプリケーションおよびドライバーにおける互換性の向上

既知の問題:

• Windows の機能をオンまたはオフにすると、コンピューターの再起動が必要になる場合があります。たとえば、リモート アクセスをオンまたはオフにした場合にこの動作が必要となります。

いよいよ、Windows 8 と Windows RT の一般提供 (GA) が近づいてきました。ストアでは数千もの新しいアプリから選択ができるようになり、世界中の数万の開発者が新しいアプリを開発中です。マイクロソフトでは 8 月以降、新機能の追加と Windows の付属アプリの機能強化を進めてきましたが、さらに GA 前にこれらのアプリを更新する予定です。新機能を導入し、パフォーマンスと信頼性を高めることになるはずです。この記事は、プログラム管理チームの Gabriel Aul が執筆したもので、ストア掲載の翌日以降に入手できる更新プログラムについて詳しく説明しています。
-- Steven

Windows 8 の一般提供 (GA) が近づくにつれて、Windows チームやマイクロソフトの他のチームは準備のための作業に追われました。もちろん、最も重要なのは、間もなくいっせい発売される Windows 8 PC を準備する PC メーカーを支援することでした。一部のモデルについては既に発表されていますが、今後さらに多くの発表が行われます。Windows 8 では、Windows 8 アプリ向けの新しいストアや、Windows 付属の多数の新しいアプリも導入されます。依然として GA 前ですが Windows ストアには既に数千のアプリがあり、さらに多数のアプリを掲載できるように、世界中の開発者と日々協力作業を進めています。Windows ストアは、開発者にとって数億人ものユーザーにアプリをアピールする前例のない機会になります。私たちは、日々の刺激的な出来事に自信を深めています。

もちろん、Windows ストアをとおしてアプリの更新プログラムを提供する統合された方法も活用することになります。8 月に PC メーカーと MSDN および TechNet のサブスクライバーに提供された Windows 8 の Release to Manufacturing (RTM) ビルドには多くのアプリが付属していましたが、その更新プログラムを Windows 8 の GA までリリースしています。もちろん、今後出荷される PC に既定で搭載するために PC メーカーもこれらのアプリの更新プログラムを入手できますが、既に Windows 8 RTM をインストールした方も、ストア アプリから更新プログラムを簡単に入手できます。更新プログラムが入手可能になるとストア タイルに通知が表示されます。通知を開いて右上隅の更新プログラム リンクをクリックすると、一覧が表示されて必要な更新プログラムをインストールできます。

Bing アプリは、最初のこうしたアプリであり、明日入手可能になります。また 10 月 26 日まで、多くの更新プログラムがロールアウトされます。ご要望が多かった Windows ストアの更新プログラムの通知と、入手可能な更新プログラムの数がストア タイルに表示されます。都合のよいときに更新プログラムのインストールを簡単に選択できます。

全体的にアプリのパフォーマンスと信頼性が向上していますが、すばらしい新機能もいくつか加えられています。主な変更点は次のとおりです。

私たちは、これまで Windows 8 を使ってきたすべてのユーザーにこれらの更新されたアプリをお届けできることを嬉しく思っています。また、新規 PC の購入、既存の PC のアップグレードを行うユーザーにとって Windows 8 のリリースがお役に立つことを願っています。

-- Gabriel Aul

PC 製造メーカー各社は、8 月 1 日に RTM を迎えた Windows 8 を使い、Windows 8 用に設計された新しい PC の提供準備を進めています。この革新性と創造性の結晶が一般提供される 10 月を前に、パートナー各社と Microsoft の熱気は日々高まっています。エンジニアリング面のコラボレーションは今までになく順調で、高いパフォーマンス、優れた信頼性、長いバッテリ寿命といった特長が、Windows 8 向けに設計された新しい PC に集約されつつあります。さらに、私たちがどのようにこのプロセスを、ARM プラットフォーム基盤の新世代 PC に拡張したかについても関心をお持ちかと思います。この記事では、Windows RT の開発、さらには Windows RT 向けに設計された新しい PC の開発で進められているコラボレーションについて説明したいと思います。この記事は、エコシステム & プランニング チーム担当バイス プレジデントの Mike Angiulo が執筆しました。
–Steven

お客様に愛される、最高品質の Windows RT と Windows 8 の PC を完成させる。この目標に向けて私たちは、Windows 8 と Windows RT が RTM を迎えた現在も、PC 製造メーカー、シリコン チップ製造パートナー、その他部品製造メーカーなど、エコシステムのパートナー各社と綿密な共同作業を続けています。Windows 8 と Windows RT を基礎に PC 製造パートナー各社から生まれる設計は、いずれも興味深く、驚かされるものばかりです。

PC 製造パートナー各社からは、Windows 8 の Intel ベースと AMD ベースの実にさまざまな設計が生まれています。これらが持つ高速な処理能力と革新的なデザインによって PC の可能性はさらに広がるでしょう。鮮やかな高解像度ディスプレイを搭載した超薄型 & スマートなデザインの PC、大型ディスプレイで没入型のエクスペリエンスをお届けする美しいオールインワン PC、複数のグラフィック カードと高性能のストレージ アレイを搭載したハイパワーのタワー型 PC まで、お客様のあらゆる期待に応えます。さらに、こうした多様な選択肢から最適な価格と機能を組み合わせることで、用途とライフスタイルにぴったりの PC を見つけることができます。

特に嬉しいのは、革新的な Intel の SoC プラットフォームを活用して消費電力を抑えた新しい x86 Windows 8 PC によって、"常時起動、常時接続" エクスペリエンス ("接続維持スタンバイ" とも呼ばれます) が実現されることです。つい先日 Lenovo が発表 (英語) した ThinkPad Tablet 2 は、Intel ATOM® プロセッサ上で驚くべき最新機能の連携を実現しています。これらのシナリオがもたらすさまざまなメリットについてはこの記事の後半で説明いたします。

新登場の PC は、高い信頼性、高速な処理、システム リソース消費の効率化、ソフトウェア読み込みの強化など、同スペックの Windows 7 PC と比較してさまざまな点で優れています。Microsoft も今回のリリースをサポートするさまざまなツールとサポートをきめ細かく提供しています。最新の Ultrabook™ (英語) から最高のパワーと拡張性を持つワークステーションまで、もうすぐ出会える Windows 8 PC にぜひご期待ください。

ARM ベース PC は Windows RT によって新しい時代を迎えます。市場に登場するのは、Microsoft、シリコン チップ製造パートナー、PC 製造パートナーの共同作業が生んだイノベーションの結晶です。以前の記事「ARM プロセッサ アーキテクチャ向けの Windows の構築」では、Windows RT 開発で求められたエンジニアリング作業の内容を詳しく説明しました。新しい Windows RT PC の市場提供に向けたエコシステムにわたるコラボレーションの最新情報は本記事の後半にご用意していますが、まずは前回の記事の重要なポイントを簡単にまとめてみましょう。 

• Windows RT はかなり多くのコードを Windows 8 と共有し、世界最大のコンピューティング エコシステムの一部として開発、販売、サポートが行われます。
• NVIDIA、Qualcomm、Texas Instruments の各社による Windows RT 向け SoC プラットフォームすべてで同一の Windows バイナリを実行するという目標を達成しました。この包括的なシステムの基盤には、各社が開発した革新的な ARM CPU があります。
• Windows RT PC の提供に向けた取り組みを通して、今までになかった新しいシステムが作り上げられることになりました。まったく新しい PC のエコシステムが、新たな可能性を持つ ARM ベースのプロセッサを搭載した新世代の PC を生み出す機会を PC 製造メーカーに提供します。
• Windows RT PC は、薄くて軽いインダストリアル デザイン、長いバッテリ寿命、統合された品質を実現しています。これらの PC はすべて Windows RT を意図して設計、製造されています。
• PC 製造メーカー各社が提供する Windows RT PC は、ハードウェア、ファームウェア、Windows RT ソフトウェアが組み合わせられた統合型かつエンド ツー エンドの製品です。ハードウェアとソフトウェアを独自に組み合わせ一体型で搭載する通常の電化製品の場合と同様に、Windows RT ソフトウェアも、新しい Windows RT PC と別に単体で販売または配布されることはありません。搭載されたソフトウェアには、PC の実用的な寿命が終わるまでサービスや改良が提供されます。

Windows RT 関連情報に注目している方の中には、Asus Tablet 600 (Windows RT) (英語) や Surface RT™ (英語) のニュースを覚えていらっしゃる方も多いと思いますが、ASUS に加えて Dell、Lenovo、Samsung の各社からも Windows RT を搭載する ARM ベース PC のデザインを発表予定という嬉しいニュースをお知らせいたします。

詳しい情報は続報をお待ちください。Windows 8 と Windows RT の一般提供が近づくにつれて、PC 製造メーカー各社から製品の詳細情報が明らかになってくると思います。現時点でお伝えできるのは、ユーザーがコンピューターに求める固有のニーズに合わせて現在ハードウェアや周辺機器が開発されており、そこには業界に今まで見られなかったような多様性が生まれているということです。

「最新のエコシステムから生まれたさまざまな機能を採用した Dell の Windows RT タブレットをお使いいただけば、ビジネス シーンでもご家庭でも、できることは今まで以上に広がります。Microsoft の戦略的パートナーであることは私たちにとって喜びであり、もうすぐすべてをお知らせできることを待ち望んでいます」

- Dell PC プロダクト グループ担当バイス プレジデント Sam Burd 氏

私たちの取り組みの独自性は、PC 設計にかかわるパートナーが新しい形で共同作業することから始まっています。各パートナーの最良のアイデアを集約することで、チップセットから実際の操作に至るまでが一体化、最適化されたエンドツーエンドのエクスペリエンスが実現しました。

この機会に、Windows RT における私たちのコラボレーションが、その他のあらゆる Windows リリースの場合といかに違っているかを説明させていただきます。Windows RT PC のエンジニアリングでは、PC 製造メーカー、シリコン チップ製造パートナー、通信事業者の密接な共同作業を通してハードウェア、ソフトウェア、サービスの一体化に取り組み、SoC の集積基板、Windows RT、ファームウェア、ドライバーの初期ビルド、PC ハードウェアの数百に及ぶリリース前サンプルなど、各パートナーそれぞれの製品開発における初期段階の成果を共有しました (開発初期に公開されたデモンストレーションやビデオは、これらを使って作成されています)。製品設計は周知され、力を合わせた開発/テスト作業によって洗練されていきました。その結果、高速で滑らかなタッチ操作、長時間のバッテリ寿命、接続維持スタンバイ、薄型で軽量の美しいデザインなど、Windows RT の機能を最大活用するために欠かせない特長が、すべての Windows RT PC に共通して実現されました。

リリース前に開発された Windows RT PC の実際のスナップショットです。開発最初期のエンジニアリング プロトタイプと最新版に進化したハードウェアの違いにご注目ください。

これらの目標達成にあたって Windows から行ったサポートは、いくつかの主要シナリオを特定し、洗練させ、最適化することでした。複数の主要シナリオが連携することで、最新テクノロジとエンジニアリングの共同作業がなければ実現できなかった、新しいレベルのモバイル エクスペリエンスとパフォーマンスが可能になりました。ここからは、Windows RT の仕様のいくつかを詳しく紹介していきます。

接続維持スタンバイは、PC を "常時起動、常時接続" の状態にするシナリオです。ネットワーク接続を維持したままスタンバイ状態に入ることで、バッテリ消費を抑えながら、重要情報や最新情報を見逃さないようにします。未使用の状態が続いている Windows RT PC は新たに設計された低電力状態に切り替わるので、最新のデータを維持しながらも数日間はバッテリをチャージする必要がありません。再度使う場合は、ボタンをタッチすると 1 秒以内にシステムが起動します。つまり、フル機能の PC でありながらも携帯電話のようなエクスペリエンスが実現されています。さらに消費電力モデリングのシナリオをシステム全体で徹底的に強化することで、薄型で軽量のデザインを通して、丸 1 日使えるバッテリ残量、接続維持スタンバイで数日間使えるバッテリ残量をより正確に通知できるようになりました。

以下の表は、接続維持スタンバイのシナリオと消費電力のシナリオに対する、開発初期の Windows RT PC を使ったテストでの測定範囲です。

計測では、現在も最終調整が行われているファームウェアと、リリース直後の Windows RT RTM コードが使用されました。これにより、計測値に影響する要素は製造メーカーの取り組み部分だけとなります。この計測の意義をご理解いただくため、シナリオの計測方法を説明します。ここでは、計測対象の各 PC のローカルに保存されている HD ビデオを、最高解像度、画面の明るさ 200 ニット、全画面表示で再生しました。さらに Microsoft のネットワークで電子メール アカウントを 1 つ設定しました。また、計測値は PC ハードウェア自体の影響を受けています。ハードウェアには、タブレットとラップトップ、10.1 ～ 11.6 インチの画面サイズ、25 ～ 42 ワット時のバッテリ容量という違いがありました。

開発作業の中で消費電力モデリングの分析に部品レベルで取り組んだ結果、設計部分の調整が必要な領域の詳細が明らかにされていきました。たとえば、一般的なタッチ コントローラー ソリューションはマルチチップ ソリューションに基づいて設計されています。これをシングルチップに減らして消費電力と発熱を抑えることで、バッテリ サイズの縮小と、薄型で軽量のデザインが可能になりました。以下の表は、Microsoft パートナーによる ARM SoC 搭載のさまざまなハードウェアとモデルで実現された重量と薄さの概要を示しています。

消費電力が抑えられたことに加え、これらのシングルチップ ソリューションによってパフォーマンスが最適化されたことが、高速で滑らかなタッチ操作につながりました。一般提供時にパートナー各社が提供する Windows RT PC では、指 1 本あたり 100 Hz のサンプリング レートが実現される予定です。これは高速で滑らかな応答性はもちろん、業界最高レベルの精度を可能にする数値です。

グラフィック コアにも緻密な最適化が施されています。HD ビデオ再生の消費電力を効率化したことに加えて、Windows RT のコア UI のアニメーションは、設計目標として掲げた 60 fps を達成しました。

消費電力の抑制、薄型化、軽量化だけではありません。Windows RT PC で情報を直感的かつ簡単に共有するといった新しいシナリオの実現にも取り組んでいます。たとえば、一般提供時には NFC 対応の Windows RT PC も登場する予定です。これはタップによる共有などの楽しく興味深い操作に対応した PC で、NFC 対応の Windows RT PC が 2 台あれば、写真、URL、地図上の経路、その他ソフトウェア パートナーが自社の Windows アプリに組み込んだあらゆる項目を、2 台の PC での同時タップだけで簡単に共有できます。もちろん、USB 大容量ストレージ、印刷、オーディオ/ビデオ周辺機器といった各種のデバイス シナリオ、WWAN、Wi-Fi、Bluetooth、USB などの接続規格にはネイティブ対応します。これらを支える Windows 8 と Windows RT に共通の基盤は、既に //BUILD/ カンファレンスの時点で発表されたものです。

Windows RT はタブレット ハードウェア専用というわけではありません。販売予定の PC には、すべての操作をキーボードとタッチパッドで完結でき、さらにキーボード部分を取り外せるものと従来のノート型のものがあります。この仕様の場合、バッテリ容量が増えることに加えて、Windows 8 のジェスチャを取り入れた新しいタッチパッド エクスペリエンスが搭載されています。私たちはタッチパッド部品製造メーカーとの緊密な共同作業を通してファームウェアでのネイティブ サポートを実現しました。これによって驚くほど高速なジェスチャ認識機能を駆使して Windows をスムーズに操作できます。ネイティブ サポートされる予定のタッチ ジェスチャについては、以下の 2 つの表をご覧ください。

1 本指でスライド	1 本指/2 本指でタップ、ダブルタップ	2 本指でスライド
マウス カーソルの操作	プライマリ/セカンダリ ボタンのクリック、カーソル位置のダブルクリック	左右または上下のスクロール (マウス ホイール)

2 本指でピンチ	右端からスワイプ	上端からスワイプ	左端からスワイプ
ズーム (Ctrl + マウス ホイール)	チャームの切り替え (Windows ロゴ キー + C)	アプリ コマンドの切り替え (Windows ロゴ キー + Z)	最後のアプリに切り替え (Windows ロゴ キー + Ctrl + Backspace)

最後に、ハードウェア部品や最適化の取り組みがすばらしいエクスペリエンスとして実を結ぶために欠かせない、これらのハードウェアと最適化を利用するアプリケーションについて説明します。Windows、PC 製造メーカー、シリコン製造パートナーのエコシステムは、新しい PC ハードウェアの機能を活かしたアプリケーション エクスペリエンスの実現に向けて、世界中の開発者と連携し、彼らをサポートしてきました。私たちはこうした目標に基づき、OS とアプリの開発/テスト用のハードウェア システム リファレンス デザインを数多く作成し、1500 件を超える Windows RT のリファレンス システムを ISV や IHV 企業に公開して、一般提供に向けた彼らの取り組みをサポートしています。その効果は明らかで、Windows ストアの RTM アプリケーションの 90% 以上が Windows RT をサポートすると共に、プリンター、Web カメラ、モバイル ブロードバンド モジュールなどの各種周辺機器との互換性を保証する Windows ハードウェア認定の要件にも対応しています。

Windows RT は、Windows にとどまらず、Windows PC、そしてエンジニアリングに対するエコシステム全体のかかわり方をも大きく刷新する存在となりました。Windows RT を中心に、シリコン製造メーカー、部品製造メーカー、PC 製造パートナー、そして Windows エンジニアリング チームによる緊密な共同作業が実現したのです。その結果、高速で滑らか、常時起動と常時接続、薄型で軽量、丸 1 日使えるバッテリ寿命といったメリットをお約束できる、魅力的で強力な、新しい Windows PC スイートが誕生しました。今後は、Dell、Lenovo、Samsung の各社による発表を楽しみにチェックしていきましょう。

--Mike

オンライン リソースを読み、処理することが増えているとはいえ、印刷は PC を使って最も頻繁に実行する作業の 1 つです。私たちは、よく実行されるこの作業の簡略化と機能強化に乗り出しました。Windows 8 での印刷機能の強化を実現するために、エコシステムのパートナー各社に協力していただいています。この記事は、印刷チームのリード プログラム マネージャーである Adrian Lannin が執筆しました。 

--Steven

Windows PC に接続できるあらゆる周辺機器の中で、プリンターは最もよく使われる機器の 1 つであり、最も古くからサポートされています。実際、Windows 1.0 Press Kit によると、Windows 1.0 (1985 年にリリース) は、「多数のプリンターとプロッター」をサポートし、「あるファイルの印刷中に、別のファイルの作業を可能にする印刷スプーラー」を搭載していました。以下の Windows 1.0 のスクリーンショットでは、Windows 1.0 に含まれていたファイル (Epson.drv、さまざまなフォント ファイル、および印刷スプーラー プロセス) が表示されています。印刷システムの一部は、現在このシステムの開発に携わっている人間が生まれる前から存在します。:-)

長い年月をかけて、印刷システムは複雑なアーキテクチャへと進化してきました。現在では、多種多様なプリンターへの印刷をサポートし、家庭で使用するシンプルな 50 ドルのインクジェット プリンターから、数十万人のユーザーが利用し、数千件の印刷キューをホストし、数万ドルもするプリンターを動かす高可用性プリント サーバーにまで対応できるスケーラビリティを備えています。

印刷システムは、Windows のさまざまなレイヤーと領域にアクセスします。印刷システムは UI を表示し、ドライバーをホストします。このドライバーも UI を表示します。印刷は本質的に画面上のコンテンツを紙面に再描画することであり、負荷の高いグラフィックス操作を実行します。USB またはネットワークが主として、印刷では下位の通信も扱います (現在、米国で購入されているプリンターの大半はネットワークに対応していますが、Windows の利用統計情報によると、Windows 8 Consumer Preview にインストールされているプリンターの 75% 以上は USB ポートに接続されています)。印刷システムは、大企業で展開されている大規模なミッション クリティカル システムに対応しながら、規模の小さいシステムでも効率よく実行できる必要があります。

このブログ記事では、できるだけ皆様にお役に立つ形で適切なデバイス サポート (英語) を提供するために、Windows 8 で印刷システムをどのように刷新しているかを説明します。ARM ベースの PC と Metro スタイル アプリで、この印刷システムがどのように機能するかを説明します。また、プリンターにアクセスするのがデスクトップからであっても、Metro スタイル アプリからであっても、Windows RT 搭載デバイスからであっても、できるだけ多くの既存のプリンターを確実に "動かす" ための取り組みについても説明します。

Windows 8 の印刷システムの刷新

Windows 8 では、バージョン 4 または V4 と呼ばれる新しいプリンター ドライバー アーキテクチャを導入しました。V4 アーキテクチャでは、さらにサイズが小さくて高速なプリンター ドライバーを生成できるほか、印刷クラス ドライバー フレームワークの概念がサポートされます。このフレームワークは、多くの場合、特定のデバイスのドライバーを探さなくても、プリンターをインストールできるシステムです。

おそらくご推察のとおり、V4 は Windows の 4 代目のプリンター ドライバー アーキテクチャです。V3 は、Windows 2000 ～ Windows 7 で使われていたアーキテクチャで、実際にはデバイスの互換性確保のために、Windows 8 でも完全にサポートされます。したがって、現在お使いのプリンターには既存のドライバーしかなくても、そのプリンターは Windows 8 でも利用できます。バージョン 1 および 2 は、Windows 1.0 ～ Windows ME で使われていたドライバー アーキテクチャです。

印刷システムのしくみを説明する前に、Windows 8 印刷システムで取り組んだ要件のいくつかについてお話したいと思います。

Metro スタイル アプリからの印刷

Metro スタイル アプリの開発者にどのように印刷機能を提供するかも、考えなくてはならないことの 1 つでした。win32 アプリケーションからの印刷には、GDI (グラフィックス デバイス インターフェイス) または XPS (XML Paper Specification) のどちらかのグラフィックス プログラミングの知識が必要です。Windows 8 アプリからの印刷を可能にする方法を検討するにあたり、Windows ランタイムからの印刷を可能にする方法を抜本的に見直し、HTML5 / JavaScript および XAML / C# アプリからの印刷を非常に使いやすくしました。

Metro スタイル アプリへの印刷機能の統合

Metro スタイル アプリからの印刷は、当然ながら、Metro スタイルのエクスペリエンスである必要があります。皆さんのほとんどが、何かを印刷したときに、用紙切れを知らせる、またはインクを購入する機会を提供する小さなアプレットをご覧になったことがあると思います。

このようなポップアップは、インクジェット プリンターで非常によく利用されています。ポップアップの中には、(インク レベルが低いなど) 関係がある場合のみに表示されるものも、印刷するたびに表示されるものもあります。これらのポップアップは、プリンター ドライバー ソフトウェア自体から表示されていて、当然ながらすべてデスクトップ UI です。しかし、たとえば Metro スタイルのフォト アプリから印刷する場合に、印刷中であることを示す UI を表示するためだけに、デスクトップに切り替えなくても済む必要があります。

Windows RT からの印刷

プリンター ドライバーは、時間と共に進化し、さまざまな機能が含まれるようになりました。サービスをインストールするものや、多数の小さなアプリケーションをインストールするものもあります。また、現在では、ドライバーの多くは、非常にサイズが大きくなっています。Windows 2000 以来使われている V3 プリンター ドライバー モデルは、非常に複雑で拡張性の高いモデルになっています。このモデルでは、プリンター メーカーがドライバー ソフトウェアと併せてインストールする内容を比較的自由にコントロールできます。印刷システムが Windows RT を実行するデバイスでも機能する方法を考えるにあたり、大がかりなアーキテクチャの変更が必要なことはわかっていました。不要なサービスを実行して ARM システムに悪影響を及ぼすことはなんとしても避け、また、できる限り多くのデバイスをサポートしながら、システム リソースの使用率を削減したいと考えました。

これまでより格段に少ないドライバーで多数のプリンターをサポート

プリンターの機能は実にさまざまですが、Windows は各種プリンターを広範にわたりサポートしています。Windows 7 とそれ以前のバージョンの Windows では、どのプリンターも特定のドライバーがなければ機能しませんでした (ユニバーサル プリンター ドライバーなど、一部の例外はありますが、この種類のドライバーはサイズが大きく、大量のリソースを消費しがちです)。つまり、適切なサポートを提供するために、Windows に付属するドライバー (インボックス ドライバーと呼びます) の数は膨大でした。もちろん、それ以上に多くのドライバーを Windows Update で提供していますが、よく使われるデバイスをサポートするインボックス ドライバーを用意し、Windows Update からドライバーをダウンロードできない、またはダウンロードしない方にも、適切な印刷エクスペリエンスを提供できることは重要だと考えています。インボックス ドライバーは Windows RT には必須です。実際、Windows RT はインボックス プリンター ドライバーしか使用しません。ここでの課題は、カバー率の高いプリンターのセットをサポートしながら、そのために必要になるリソースを削減することです。

多数のプリンターのサポートに関しては、時間と共にサポートの有用性が失われていくことも、気になる課題でした。たとえば、Windows 7 に付属しているドライバーは、2008 年と 2009 年にリリースされたデバイスのサポートには有効ですが、年々新しいデバイスがリリースされ、時間が経つにつれて、Windows 7 のドライバーのセットはカバー率が低下しています。そこで、まだリリースされていないプリンターも含めて、多数のプリンターに対応できる高度なサポートを、確実に Windows で提供することが、Windows 8 での大きな課題の 1 つになりました。

プリンターの共有

プリント サーバーを管理したことがあれば、適切なドライバーをインストールして共有をサポートすることが、プリント サーバーの管理で最も時間がかかる作業だと言うかもしれません。自宅でプリンターを共有するときも、特に 32 ビット版と 64 ビット版の両方の Windows がある場合は、このような問題に直面する可能性があります。プリント "サーバー" (実際の Windows Server ではなく、プリンターが接続されている PC のこと) は、共有プリンターに印刷をするクライアントにドライバーを提供する必要があるため、この作業は複雑です。Windows 7 では、ホームグループを使ってこの問題に対応しました。多くの場合、これは適切に機能しています。ただし、各 Windows アーキテクチャ用のドライバーを読み込む必要があるため、Windows RT から印刷することを考えると、さらに問題になります。

Windows RT 搭載デバイスから印刷をするほとんどのユーザーは、ワイヤレス プリンターに印刷すると思われますが、USB プリンターに印刷する可能性を完全に排除したくありませんでした。一方、32 ビット クライアント、64 ビット クライアント、および Windows RT クライアント用のドライバーを追加するよう求めることで、プリンターの共有をさらに複雑にしたくもありませんでした。そこで、Windows 8 では V4 モデルを基に、クライアント ドライバーをプリント サーバーに配置しなくても、プリンターを共有できる新しい方法を開発しました。

Windows 8 の印刷システム

アプリケーションを使うことで、コンテンツの作成や表示が可能になります。印刷システムの目的は、インストールされているデバイスの種類を気にかけることなく、インストールされている任意のプリンターにコンテンツを印刷する手段をアプリケーションに提供することです。ここでは、アプリケーションが印刷するしくみについて簡単に説明し、その後、印刷ページにコンテンツを出力するしくみについて詳しく説明します。

印刷可能なコンテンツの作成

アプリに印刷サポートを追加する手順は、非常に明快です。アプリから印刷するコンテンツは、アプリが指定する形式です。Metro スタイル アプリの場合、これは通常 HTML5 か XAML になりますが、Word や Photoshop などの Win32 アプリの場合は、印刷するコンテンツは特定のアプリに固有の形式になります。

したがって、アプリからプリンターに印刷する場合、印刷システムが実行する必要がある作業の 1 つは、アプリの形式からプリンターが理解できる形式にコンテンツを変換することです。残念ながら、すべてのプリンターが同じ形式を理解するわけではないので (かなり差があります)、これは非常に手間のかかる作業になります。

具体的な例を挙げると、Word などのアプリは GDI グラフィックス システムを使って、画面とプリンターの両方にコンテンツを出力します。可能であれば、印刷システムは XPS (XML Paper Specification) という高品質な中間形式を内部のコンテンツ形式に使用します。つまり、コンテンツを Word から XPS に変換しています。XPS は非常に柔軟な形式で、電子ペーパーと同様の性質であるため、印刷システムの基盤として XPS を採用しています。XPS は高性能カラーをサポートします。また、実行可能コードが埋め込まれていない XML ベースの記述であるため、アーカイブにも便利なうえ、他の形式に比べて安全です。また、Microsoft は ECMA International (欧州電子計算機工業会 (英語)) と協力して、XPS をオープン標準にするよう取り組んできました (ECMA 標準 TC46、OpenXPS)。デスクトップ ビューアーでもリーダー アプリでも、OpenXPS は表示できます。私は、オンラインの買い物の領収書をすべて、XPS ファイル形式で "印刷" しています。

印刷システムによるコンテンツの処理が始まると、コンテンツはプリンターが理解できる形式に変換されます (XPS を直接理解できるプリンターは多いので、必要に応じて)。印刷システムがこれを正しいオプションのセットと合わせてプリンターに送り、このジョブが印刷を実行します。

すべての Metro スタイル アプリは Direct2D を基本の描画形式として使用し、Direct2D と XPS は同じ XML ベースのグラフィックス "言語" を使用しているため、Windows 8 では、この一連のプロセスのパフォーマンスが目に見えて向上しています。したがって、また別の具体例としては、リーダー アプリが挙げられます。リーダー アプリは、コンテンツの画面へのレンダリングに Direct2D を使用していますが、同じコンテンツを印刷システムに出力する場合も、Direct2D を使用します。リーダーのコンテンツは、負荷の高い GDI からの変換をせずに、XPS 形式で容易に印刷システムに送ることができます。

アプリが画面レイアウトとは異なる印刷レイアウトを必要とする場合は、スタイル シートや XAML を使ってこれを実現できます。つまり、"ページの印刷用バージョンを表示するためにここをクリック" する必要がありません。XPS をサポートするプリンターがあれば、アプリからプリンターまでのパスには変換がまったく含まれず、印刷は非常に高速に処理されます。

アプリから印刷情報が印刷システムに送られるしくみについて概要を理解していただけたところで、次は、印刷システムによる印刷情報の処理の内容、印刷システムが提供するサービス、および Windows 8 でのその他の変更点について説明します。

多数のプリンターのサポート

Windows がアプリに提供する大きなメリットの 1 つは、アプリに対して特定のプリンターを抽象化することです。したがって、アプリのプログラマは、インストールされているプリンターの種類を気にかける必要がありません。Windows は、Windows Update やメーカーの Web サイトで提供されているドライバーによってサポートされるプリンターも含めて、合計で数万種類のプリンター モデルをサポートしています。プリンターが機能しない場合、その原因の多くは、メーカーのソフトウェアがインストールされる Windows のバージョンを認識できない場合、インストールを阻止するようにメーカーが設定していることです。私たちはプリンター メーカーと協力して、このようなパッケージを更新するように取り組んでいますが、これには時間がかかります。

新しいプリンターを Windows に接続したら、ドライバーを探しに行かなくても、すぐに使用できることが理想です。

それにはどうしたらよいのでしょうか。これまでは、Windows に多数のプリンター ドライバーを含めてきました。Vista には約 4500 種類のドライバーが、Windows 7 には約 2100 種類のドライバーが含まれていました。Windows 7 のドライバーは Vista の半数ですが、Windows 7 の方が市場を広くカバーしています。つまり、Windows 7 の方が、よく使われるプリンターのドライバーが付属している可能性が高いということです。これはなぜでしょうか。信じられないほど多種多様なプリンターが使用されています。Vista では、古くてあまり使われなくなったデバイスも多数サポートしていたため、サポートされるデバイス セットの有用性は Windows 7 ほど高くありませんでした。

余談ですが、Windows の新しいバージョンをリリースするときには、前のバージョンに付属していたドライバーを Windows Update で公開します。これらのデバイスは以前ほど使われなくなっている可能性があっても、ユーザーがデバイスを接続するだけで自動的に使用できる状態にするためです。

以下の写真は、これが問題なく機能することをテストしているプリンター ラボの 1 つ (複数のラボがあります) にあるベンチの 1 つを撮影したものです。メーカーの違う小型のインクジェット プリンターとレーザー プリンターがいくつか並んでいます。私の耳にとっては嬉しいことに、最近ではドット マトリックス プリンターをテストすることは、それほど多くありません。

プリンターは平均して 5 ～ 7 年間維持される傾向があるため、サポートを追加するときは、「どのデバイスが使われているか」、「この数年間で最もよく使われているデバイスはどれか」、「将来最もよく使われるデバイスはどれか」を考える必要があります。この最後の質問は、Windows をリリースして間もなく、私たちが知らなかったデバイスをプリンター メーカーがリリースするため、簡単には答えられません。つまり、時間の経過と共に、Windows の特定のバージョンでサポートしているデバイス セットは有用性が薄れます。

どのようなときでも、約 100 種類のプリンター モデルが、インストールされているプリンター全体の約 50% を占めています。現在使われているモデルの 75% をサポートする場合は、約 300 種類のモデルをサポートする必要があります。以下の図は、このことを表しています。

95% のカバー率を達成するには、1000 種類を超えるモデルをサポートする必要があります。しかし、100、300、または 1000 種類から成るこのプリンターのセットの構成内容は、常に変化するため、問題はさらに難しくなります。"現在" の市場の 50% を占めている 100 種類のプリンターは、"来週" または来月の 50% を占める 100 種類のプリンターとは異なり、来年になればさらに内容は変わっているでしょう。毎日、多くのユーザーが新しいプリンターを買って、インストールしています。

前述のとおり、これまでは、基本的に総当たり的な方法でこの問題を解決してきました。大手プリンター メーカーの方が、Microsoft 本社に駐在して Microsoft と直接協業し、自社のソース コードを Windows に組み込んでいます。この方々が、Windows の新しいリリースが出されるたびに、まったく新しいインボックス ドライバーのセットを作成します。これは、効率的とは言えません。

Windows 8 では、抜本的に異なる方法を取り、Windows に多数のプリンター ドライバーを含めて提供することをやめ、"印刷クラス ドライバー フレームワーク" を構築しました。このフレームワークは拡張性が高く、既存のデバイスへの印刷をサポートするだけでなく、設計さえされていなかった、新しいデバイスのサポートをメーカーが組み込むこともできます。

印刷クラス ドライバー フレームワークを使うことで、ドライバーを実際に探しに行かなくても、プリンターが Windows 印刷システムとすぐに連携できる、ドライバー不要の印刷に近いエクスペリエンスを提供できます。本当にドライバー不要の印刷エクスペリエンスを実現するには、ほとんどのプリンターの設計方法を変える必要があり、印刷クラス ドライバー フレームワークはこの概念をサポートしていますが、できるだけ既存のデバイスのサポートを提供することも非常に重要だと感じています。

新しいプリンターや開発が予定されているプリンターをサポートできるため、Windows 8 の印刷クラス ドライバー フレームワークによってサポートされるプリンターの数は、時間の経過と共に増加します。

カバーするデバイスの数が大幅に増えるだけでなく、このカバー率を達成するために使用するリソースを削減することもできています。

まず、Windows Vista では 768 MB だったプリンターとイメージング デバイスのサポートに必要なディスク容量を、Windows 8 では約 184 MB に削減しています。この数字は、Windows 8 のすべてのエディションとアーキテクチャの平均です。次の図は、Windows Vista 以降で、使用する容量がどの程度削減されたかを示しています。

Windows 8、Windows 7、および Windows Vista でプリンターとイメージング デバイスのサポートに必要なディスク容量の比較

また、使用するディスク容量が削減されただけでなく、Windows によって直接サポートされるデバイスの有用性も向上しています。次の表は、どの程度インボックスでのカバー率が向上し、ディスク使用率が削減されているかを示しています。

これは、Windows 8 での大きな改善点の 1 つです。一部の Windows RT コンピューターは物理的な記憶域が少ないことが特徴になると思われますが、この使用容量の削減は、即、このような記憶域スペースが限られているハードウェアのユーザーにとって、利用可能な記憶域の増加につながります。

Windows 8 のプリンター ドライバー モデルでは、メーカー パートナーに、Windows のバージョン間で変更が少ないコードを開発することに集中してもらうことができます。その結果、このリソースをより有効に活用し、ドライバー セットを絶えず組み込み直す作業ではなく、品質とパフォーマンスを向上する作業に割り当てることができます。

印刷クラス ドライバーのアーキテクチャ

Windows RT と Metro スタイル アプリのニーズに応えるアーキテクチャを構築するだけでなく、既存のデバイスでも利用でき、プリンター メーカーになじみのあるテクノロジを使用することで、メーカーにとって新しいドライバー テクノロジを実装しやすいモデルにしたいとも考えました。

プリンター ドライバーは、次のようないくつかの重要な処理を実行します。

• 構成: ユーザーが設定を変更できるようにします。たとえば、両面印刷を有効にするという指定を、プリンターがそれを行うために必要とする具体的なコマンドに変換します。構成は、ユーザー インターフェイスによって、ユーザーに提示されます。
• レンダリング: Windows の印刷システムが使用する形式からプリンターが理解できる形式に印刷するコンテンツを変換します。プリンターが直接ネイティブの Windows の印刷フォーマット (XPS) を理解する場合があり、そのようなデバイスでは、(1 枚の用紙に複数のページを印刷する場合など) 追加のレンダリングを必要としない限り、実行すべき作業はありません。レンダリングを行うドライバーの部分は、"レンダー フィルター" と呼ばれます。
• イベント: ジョブが完了した、紙詰まりが発生した、プリンターのインクが切れたなど、発生した出来事についてプリンターがユーザーに通知できるようにします。

UI の構成

古いドライバー モデルと Windows 8 のドライバー モデルの大きな違いの 1 つは、UI を提供する方法にあります。古いプリンター ドライバー モデルでは、構成 UI がドライバーに組み込まれていました。以下は、典型的なプリンターの UI の例です (現在私のデスクにある Epson NX430 の UI)。

前述のとおり、プリンターの設定を変更する場合に、Metro スタイルの UI を表示できる方法を見つける必要がありました。

Windows 8 のドライバー モデルでは、メーカーの UI は完全にドライバーから独立しています。このアーキテクチャが採用されたことは、さまざまな理由から、非常に有効だと言えます。プリンターを制御する UI は、Metro スタイル アプリから印刷する場合でも、デスクトップ アプリから印刷する場合でも、起動できるアプリになりました。これにより、プリンター メーカーははるかにリッチなエクスペリエンスをユーザーに提供できます。プリンターのセットアップ方法やインク カートリッジの取り付け方法を説明するビデオが表示されることを想像してみてください。

以下は、Epson が Epson NX430 用に開発した Metro スタイル アプリの例です。

この UI は、プリンターの UI ですが、Metro スタイル アプリの特徴をすべて備えていることがわかります。プリンターのインク レベルが美しく表示され、特にタッチ スクリーン デバイスで、格段に使いやすくなっています。

デスクトップ アプリから印刷している場合はデスクトップ プリンター UI、Metro スタイル アプリから印刷している場合は Metro スタイル UI と、Windows によって自動的に適切な種類の UI が表示されます。

メーカーからデバイスの構成 UI が提供されていない場合は、Windows がどのプリンターにも使用できる標準の UI を提供します。ただし、プリンター メーカーが自社のデバイス用にカスタマイズしたエクスペリエンスを提供することにした場合は、標準の Windows UI を置き換えるアプリを提供できます。メーカーからアプリが提供されている場合、ユーザーがデバイスの構成を変更する場合や、印刷中にデバイスの構成が変わった場合 (紙詰まりなど) に、Windows は標準の UI ではなく、メーカーのカスタマイズされたアプリを表示します。

レンダリング

プリンター ドライバーの最も重要な機能の 1 つは、ユーザーから印刷の指示が出された場合に、アプリが生成するコンテンツを取得し、それをプリンターが理解できるものに変換することです。これは、Windows 8 印刷クラス ドライバーを構築するうえで、最も難しい領域の 1 つでした。ここでは、この機能について、少し詳しく見て行きましょう。

前述のとおり、Word や Photoshop などのデスクトップ アプリは、グラフィックス コマンドを使って、コンテンツを画面やプリンターに出力します。アプリがコンテンツを出力すると、印刷システムがコンテンツを受け取り、これを必要に応じて XPS 形式に変換してから、プリンターのドライバー (さらに具体的には、ドライバーの "レンダー フィルター" の部分) を呼び出してコンテンツを適切な形式に変換します。これがプリンターに送られて、ファイルが印刷されます。

非常に広範にわたりプリンターをサポートする場合に、最大の課題の 1 つになるのは、おそらく、レンダリングをどう処理するかです。高価なプリンターの中には、PostScript、PCL、XPS など、標準の "ページ記述言語" (PDL) をサポートするものもあります。しかし、より価格の低い、コンシューマー向けのデバイスは、価格を抑えることを念頭に製造されていて、その多くは、ページ情報をプリンターに送る方法に、メーカー独自の方法を採用しています。自社の製品ライン全体でいくつかの言語しか使用していないメーカーもあれば、プリンター ハードウェアの機能を最大限に引き出すために、モデル間で言語を調整しているメーカーもあります。

このため、プリンター ドライバーとプリンター ハードウェア間に 1 対 1 の関係が生まれます。

各 PDL が完全なプリンター ドライバーであった場合、プリンターのサポートが増えるに従い、着実にドライバーの数が増えることも容易に想像できます。もちろん、これは少し単純化していますが、複数のデバイスをサポートするドライバーを作成することもでき、実際に複数のプリンターをサポートするドライバーもよく目にします。しかし、ここで重要なポイントは、Windows 7 とそれ以前のバージョンの Windows では、この設計アプローチをサポートするための対応がまったくなされていないことです。

Windows 8 のプリンター ドライバー モデルは、1 つの PDL (またはドライバー) を複数のデバイスに関連付けることができるという概念をサポートします。

私たちはプリンター メーカーに働きかけて、各デバイスに、汎用的なサポート方法を示す識別子を含めてもらうようにしています。私たちはこれを "互換性 ID" と呼んでいます。したがって、デバイスに XPS をサポートすることを示す互換性 ID がある場合、印刷システムは、そのデバイスのモデル固有のドライバーを見つける必要がなく、単に汎用の XPS ドライバーをインストールできることがわかります。Windows は、そのデバイスが汎用 XPS プリンターであることを理解し、そのように扱います。もちろん、Windows はこれが Fabrikam 1000 プリンター (または任意のデバイス) であることを理解しているので、モデル固有のドライバーがある場合は、それをインストールします。ただし、提供されているドライバーがない場合でも、Windows はクラス ドライバーを使ってこのプリンターに印刷できます。

したがって、この例では、クラス ドライバー モデルの一部としてインボックスのレンダー フィルターのセットがあり、これらは対応する互換性 ID を実装しているデバイスであればどのデバイスに対してもインストールできます。この概念を論理的に拡大すると、まだ設計も構築もされていない将来のデバイスにも、Windows 8 の印刷クラス ドライバーと互換性を持たせることができるでしょう。私たちはプリンター メーカーと協力して取り組んでおり、どのメーカーも互換性 ID を自社のデバイスに実装することを計画しています (多くのメーカーは既に実装済み)。この機能のおかげで、Windows 8 でサポートされるプリンターの数は、時間の経過と共に減るのではなく増えていき、ドライバーを探しに行かなくても、すぐにプリンターを使用できる Windows 8 のエクスペリエンスをますます多くの方に体験していただけます。

しかし、メーカー独自のレンダリング言語を使用しているデバイスはどうなるのでしょうか。印刷クラス ドライバーは、そのモデルもサポートしますが、それぞれの独自言語を使用するモデルのセットごとに、個別のレンダリング フィルターが必要になるというデメリットがあります。これを回避する方法はなく、Windows 8 では、よく使われるモデルのセットに対応するフィルターをいくつか用意しています。ただし、この件についても、私たちはプリンター メーカーと協力してこの状況の改善に努めており、将来は、クラス ドライバーをさらに簡単に使用できるプリンターが製造されるものと期待しています。

Windows RT からの印刷

印刷クラス ドライバーが使用するリソースの削減は、即、Windows のフットプリントの縮小につながります。これは、特に、Windows RT では非常に重要です。また、V3 プリンター ドライバー アーキテクチャは、拡張性が高く、長年にわたって進化した結果、サイズが大きく複雑なプリンター ドライバーの開発を助長するモデルになりました。中には、常時実行されるサービスをインストールして、バッテリ電力を消費し、プロセッサ時間を使うドライバーもあります。また、1 つのデバイスしかサポートしないのに、Windows 8 のプリンター ドライバー セット全体のサイズを超えるドライバーも目にしています。

Windows RT からの印刷をサポートする必要があり、また、一般的なニーズとして印刷の効率化を図った結果、ドライバーの動作をより厳密に制御するアーキテクチャを開発しました。既にお話したとおり、印刷エクスペリエンスの UI の部分は、完全に独立したコンポーネントになり、ドライバーの一部ではなく 1 つのアプリとして提供されます。つまり、UI を提供するかどうかは任意になり、ドライバーは標準の Microsoft 印刷 UI を使って機能します。また、サービスの依存関係を取り除き、ドライバーに追加のソフトウェアが付属する可能性を抑えることで、ドライバー アーキテクチャを簡素化して、電力効率を高めています。

Windows 8 ドライバー モデルを基に、プリンター ドライバーのインストール方法も大幅に変更しました。Windows 7 とそれ以前のバージョンの Windows では、すべてのプリンター ドライバーが "ドライバー ストア" (全種類のドライバーのデータベースのようなもの) に格納されていました。プリンターを接続すると、ドライバー ストアから適切なドライバーが検索され、スプーラーがプリンターに対してドライバーを使用できる特別な場所に、そのドライバーがコピーされます。Windows 8 では、この余分なコピー処理を排除し、ディスク I/O を大幅に削減しています。印刷スプーラーは、ドライバー ストアからドライバーを検索できるようになっています。

具体的な例では、Epson Artisan の Windows 7 へのインストールにかかった時間と、Windows 8 へのインストールにかかった時間を比較しました (Windows 7 では比較的小さいドライバーを使用しました)。結果は、Windows 7 ではインストールに 14 秒かかりましたが、Windows 8 では 2 秒未満でした。

まとめ

ご覧のとおり、Windows 8 のプリンター ドライバー アーキテクチャは、大幅に進歩しています。既にユーザーが所有しているプリンターの多くをサポートするだけでなく、サイズが小さく高速な組み込みのクラス ドライバー フレームワークによって、将来のデバイスもサポートします。優れたパフォーマンスを誇りながら、必要なディスク容量はわずかです。

皆様のフィードバックをお待ちしております。

-- Adrian Lannin

本日 Windows 8 プロジェクトは、重要なマイルストーンに到達しました。PC OEM および製造パートナー各社への Windows 8 のリリースが先ほど開始されたことを、Windows 8 チームを代表してお知らせしたいと思います。次のマイルストーンは、Windows 8 を搭載したさまざまな新しい PC が発売され、Windows 8 のオンライン提供が始まる、2012 年 10 月 26 日となります。

昨年 5 月に最初のデモをお見せしたとき、私たちは Windows 8 を "チップセットからエクスペリエンスに至る Windows の刷新" と呼びましたが、Microsoft にとってもパートナー各社にとっても、Windows 8 (そして Windows RT) はまさにそのような製品となりました。シリコン チップからユーザー エクスペリエンス、そしてさまざまな新しいアプリまで、行われた取り組みのすべてが、惜しみないコラボレーションの賜物です。パートナー各社との協力により私たちがユーザーの皆さんにお届けする新しい Windows PC は、まったく新しいシナリオやエクスペリエンスの世界を開くと共に、業界全体が Windows ソフトウェアに対して行ってきた 25 年間にわたる投資を活かしたものです。

プレリリースでのテスティングへの多数のご参加に対しては、引き続き深い感謝の念をもって受け止めております。Windows 8 の各プレビュー (Developer、Consumer、Release) は、私たちがこれまでに手掛けたすべての製品の中で、最も幅広く、かつ深く使用されたテスト リリースとなっています。これらのプログラムに積極的な参加をいただいた PC は 1,600 万台を超え、うち約 700 万台では 8 週間前に開始された Release Preview をご利用いただいています。テスティングにおけるこのような深度と幅広さは、市場公開に向けた Windows 8 の成熟度を裏打ちするものです。

各プレビューのオープン性は、製品開発に対してユニークな視点をもたらすものであり、私たちはプレビュー工程の透明性を確保するため、真剣な取り組みを行っています。これだけ多くのユーザーによって、これほど多様な方法で利用される製品が、このように "開かれた" 形で開発された例は、Windows 8 を置いて他にありません。このブログ、各フォーラム、これまでのプレビュー リリース、いずれも開発プロセスの一部として重要な役割を果たしています。製品にはマイルストーンごとに大きな変更が施されてきましたが、最終リリース (ビルド 9200) でも、予告されていた数多くの改良点が、お約束のとおり組み込まれています。チーム一同、このような多様なユーザーのニーズに応える責任の重さを実感すると共に、プレリリース プロセスへの多くの積極的なご参加に対して感動を覚えています。

Windows 8 はこうして RTM マイルストーンに到達しましたが、ソフトウェア プロジェクトというものは完全に "終わり" になることはありません。引き続き、Windows 8 の現場での使用データをモニタリングし、必要な対応を行っていきます。サービス機能についてはプレビュー工程を通してテスティングを重ねてきており、RTM 後のフェーズにおいても、全力を尽くして取り組んでいくつもりです。ハードウェア パートナー各社は、今後も新しいデバイスを提供し、既存デバイスへのサポートをさらに改善していきます。PC メーカーからは、各社すばらしい Windows 8 専用 PC が登場してくることでしょう。

改良された基礎部分、強化されたストレージや接続性、再設計されたさまざまなサブシステム、"すばやく滑らか" なユーザー エクスペリエンス、WinRT プラットフォームなど、Windows 8 には文字どおり何千もの新機能が盛り込まれています。これらをご紹介するために私たちが投稿したブログ記事 (やビデオ) も記録的な数にのぼりましたが、それでも Windows 8 のすべてをカバーするにはまったく足りませんでした。この製品には、まだまだ多くの発見が隠されています。

Windows 8 にはさまざまなイノベーションが含まれますが、中にはまだ全貌を現していないものもあります。新しい WinRT プラットフォームで開発されたアプリがもたらすイノベーションです。Windows ストアは本日から営業を開始 (英語) し、これから世界中の 200 の市場に向けて一気に展開していきます。Windows 8 は世界中の開発者にとって、革新的なアプリを提供し、収益化するうえで、他に類のないチャンスとなるでしょう。開発者の皆さんが Windows 8 にもたらす作品の数々を、私たちも心待ちにしています。Windows 8 のプラットフォームについては、先日開催が発表された次の BUILD カンファレンス (英語) でも詳しくお話ししていきます。

Windows 8 を入手する方法や入手時期については、多くのご質問があるかと思います。また、Windows 8 の何千もの機能を活用する方法についても、今後多くのご質問が出てくることでしょう。Windows チームのブログ (英語) では、本日付で多くの新しい記事が投稿され、重要な詳細情報がまとめられていますので、疑問点をお持ちの方はぜひご覧ください。市場公開後の Windows 8 の動向についてもブログでお知らせしていきますので、引き続きご注目ください。

Windows 8 エンジニアリング チームを代表して、これまでの開発プロセスへのご貢献と、今後の Windows 8 へのご貢献に対して、深くお礼申し上げます。本当にありがとうございます!

2012 年 10 月 26 日の一般提供開始 (GA) を楽しみにお待ちください!

-- Windows 8 チーム

Windows 8 では、最新のグラフィックス ハードウェアによる高パフォーマンスで美しいグラフィックスを、あらゆるアプリケーションで利用できるようにすることを目標としています。この取り組みでは、さまざまな API と機能を次々と提供してきた DirectX グラフィックスという安定した基盤がベースとなります。DirectX の機能は Windows 7 で拡張され、ハードウェア アクセラレーションに対応した共通のグラフィックス プラットフォームを、それまでよりも幅広い範囲のアプリケーションで利用できるようになりました。それまでの DirectX は 3D グラフィックスが中心でしたが、いわゆる "メインストリーム" グラフィックスのための機能が追加されたのです。メインストリーム用途では、Web ブラウザー、電子メール、カレンダー、生産性アプリケーションなど、ほとんどのユーザーが日常的に使う一般的なデスクトップ アプリケーションが中心となります。Windows 7 では、DirectX に 2 つの新しいコンポーネントが追加されました。2 次元グラフィックス (図形やビットマップなど) のための Direct2D と、テキストを処理するための DirectWrite です。どちらの追加機能も、パフォーマンスはもちろん、高品質な 2D レンダリングを提供することに重点を置いています。これらの機能が追加されたことで、DirectX は、あらゆるタイプのアプリケーションを対象とするハードウェア アクセラレーション対応のグラフィックス プラットフォームとなりました。実際、Internet Explorer 9 の登場により、ハードウェア アクセラレーションを使うグラフィックスが Web にもたらされ、一般向けのアプリケーションで DirectX を使ってできることの実例が示されました。これらの機能は、WinRT によって新しい Windows 8 アプリケーションすべてに提供されます。グラフィックス チームのグループ プログラム マネージャーである Rob Copeland が執筆したこの記事では、新しいタイプのグラフィカル アプリケーションをサポートするための取り組みについて、舞台裏から詳しく見ていきます。-- Steven

 

コンピューター グラフィックスにおいて、高パフォーマンスは達成すべき指標の 1 つです。初期のパーソナル コンピューターでは、CAD/CAM やゲームのような特殊な用途のアプリケーションを使う場合、別売りのグラフィックス カードの増設が必要になることがほとんどでした。それほど早い段階から、このグラフィックス処理能力をもっと活用できるのではないかという意見があり、特にユーザー インターフェイスとユーザー エクスペリエンスの改善への応用が期待されていました。PC 用の最初のグラフィックス カードの 1 つに、S3 Graphics 社の "Windows Accelerator" (英語) があります。これはユーザー エクスペリエンスに焦点を当てた製品で、画面上でのウィンドウの動きを高速化することができました。グラフィックス ハードウェアの進歩に伴い、開発者がハードウェアと対話する方法も進歩してきました。

Windows の一部である DirectX は、PC のグラフィックス ハードウェアを使ってテキスト、図形、3D シーンを描画し、画面に表示できるようにする共通のアプリケーション プログラミング インターフェイス (API) を提供します。DirectX もまた、長い時間をかけて機能とパフォーマンス特性の両方の点で進歩してきました。初期の DirectX は主にゲームのためのものでしたが、アプリケーションの進化に伴い、よりリッチで視覚的なユーザー インターフェイスが搭載されるようになると、パフォーマンスの向上と豊富な視覚効果を求めて、多くのアプリケーションで DirectX が使われるようになりました。

Windows 8 へ

Windows 8 のグラフィックスに関連する作業を計画し始めたとき、私たちは、ユーザーがアプリや Windows 自体とやり取りするための、視覚的に多彩な新しい手段を作成することになるだろうと認識していました。さらに、Metro スタイル アプリを作成するための新しいプラットフォームを構築する必要があることと、かつてないほど多種多様なハードウェアが対象になることも認識していました。足がかりとなる優れたグラフィックス プラットフォームは存在していたものの、これらの要件に対応するためには、やるべきことがたくさんありました。私たちは、次の 4 点を主要な目標として設定しました。

1. あらゆる Metro スタイル エクスペリエンスがすばやく滑らかにレンダリングされるようにする。
2. ハードウェア アクセラレーションに対応したプラットフォームをすべての Metro スタイル アプリに提供する。
3. 魅力的なビジュアル エクスペリエンスを実現する新機能を DirectX に追加する。
4. これまでよりも幅広いグラフィックス ハードウェアをサポートする。

それぞれの目標は Windows 8 の構築を別々の側面から見ていますが、いずれもグラフィックス プラットフォームの優れたパフォーマンスと機能に依存するという点が共通しています。

パフォーマンスのための計画

Windows のグラフィックス パフォーマンスは、オペレーティング システムとハードウェア システムの両方によって決まります。ハードウェア システムは、CPU、GPU (グラフィックス処理装置)、および関連するディスプレイ ドライバーで構成されます。新しい Metro スタイル アプリに優れたエクスペリエンスを提供できるようにするためには、ソフトウェア プラットフォームとハードウェア システムの両方で優れたパフォーマンスを達成する必要がありました。

過去、DirectX のパフォーマンス測定にはさまざまなベンチマークとアプリが使われてきましたが、それらは主に 3D ゲームに焦点を当てたものでした。現在でもゲームは非常に重要な要素ですが、このような既存の方法でグラフィックス パフォーマンスを測定しても、多くの場合、グラフィックスを多用する 2D のメインストリーム アプリに必要な情報のすべてを得ることはできません。

そこで私たちは、自身の進捗状況を追跡するために、シナリオ ベースの新しいテストと評価基準を作成しました。私たちが使った評価基準は次のとおりです。

1.  フレーム レート

フレーム レートは 1 秒あたりのフレーム数 (FPS) で表されます。この評価基準はゲームのベンチマークでよく使われますが、ビデオ コンテンツやその他のアプリでも同様に重要な意味を持ちます。画面にアニメーションを表示する場合、滑らかなアニメーション表示のためには 60 FPS が必要です。私たちはこのレートをターゲットとして設定しました。多くのコンピューター画面のリフレッシュ レートは 60 Hz だからです。このフレーム レートであれば、Windows で非常に滑らかなアニメーションが可能になり、"指に吸いつく" ようなタッチ操作が実現されます。

2.  エラー カウント

フレーム レートは重要なメトリックですが、それがすべてではありません。たとえば、10 分間ベンチマークを実行した場合、平均 60 FPS という結果が得られれば一見十分と思われます。しかしこの結果からは、テスト中にどの程度までフレーム レートが低下したかを知ることはできません。負荷の高い部分で一時的にフレーム レートが 10 FPS まで落ち込んだら、アニメーションは滑らかに動かなくなります。エラー カウント メトリックでは、レンダリングに 1/60 秒よりも長い時間がかかり、結果としてフレーム レートが低下した回数の合計をカウントします。また、取りこぼされた同時フレームの数も記録します。ここでの目標は、アニメーション中のフレームの取りこぼしをなくすことです。

3.  先頭フレームまでの時間

ほとんどのユーザーはアプリが短時間で起動することを望んでいるので、DirectX の初期化も短時間で完了する必要があります。"先頭フレームまでの時間" は、タップまたはクリックでアプリを起動してから、アプリの最初のフレームが画面に表示されるまでにかかった時間を表します。これを計測するため、私たちは、グラフィックス システムを分析し、グラフィックス デバイスの初期化や必要なメモリの割り当てなどにかかる時間を調べ、最適化するために利用できる単純なアプリを作成しました。これは DirectX のセットアップ処理を短縮するために役立ちます。

4.  メモリの使用状況

グラフィックス コンポーネントで使われるメモリが増えるほど、アプリで利用できるメモリは少なくなります。システムのメモリの大部分がアプリに提供されるようにすれば、アプリのパフォーマンスを最大限に引き出すことができ、同時に実行できるアプリの数も多くなります。アプリでは、システム メモリと GPU メモリの両方が使われます。GPU メモリは、主として画像、幾何学図形、テキストのレンダリングに使われます。それ以外に CPU を使うグラフィックス処理もあり、この場合はシステム メモリが使われます。

メモリの使用状況を調べるため、私たちは、次の各シナリオでシステムによって使われるメモリを測定しました。

• アプリがアイドル状態の場合。何の処理も実行中でなく、新しい情報を画面にレンダリングしたり表示したりもしていない状態です。
• アプリが画面に情報を表示している場合。単純な描画に必要とされる基本的なメモリ コストを表します。
• テクスチャの作成。GPU で多数のイメージ オブジェクトを作成するときに使われるメモリを表します。
• 頂点バッファーの作成。幾何学図形を作成するときのメモリ オーバーヘッドを表します。
• GPU データ アップロード。GPU へのデータのアップロードに伴うメモリのオーバーヘッドを測定します。

これらのシナリオとさまざまなタイプのアプリを使ってメモリの使用状況を測定した結果は、DirectX とディスプレイ ドライバーの最適化をさらに進めるために役立っています。

5.  CPU の使用状況

ほとんどのグラフィックス処理では、GPU に加えて CPU も使われます。たとえば、アプリで描画するものを決定しようとしているとき、その計算は通常 CPU で行われます。CPU の使用状況を把握することは重要です。1 つのタスクによる CPU 使用率が高くなると、他のタスクに割り当てられる CPU サイクルが減少するためです。十分なグラフィックス パフォーマンスとシステム全体の応答性を保つには、CPU と GPU の処理のバランスを取ることが大切です。

これらのベンチマークと評価基準は、エクスペリエンスとアプリを滑らかに動かし、高いパフォーマンスを達成するために役立ちます。メインストリーム アプリを理解するうえで、これらは大きな役割を果たしています。ただしもちろん、全体的なパフォーマンスの測定には、業界のベンチマーク、ゲーム、その他の方法が引き続き使われています。

メインストリーム グラフィックスでのハードウェア アクセラレーション

メインストリーム グラフィックスにはさまざまな見方があります。適切なパフォーマンスと適切なエクスペリエンスを実現するために、私たちは Metro スタイル アプリとデスクトップ アプリの両方について多くの実例を調査し、それぞれがどのようにグラフィックス ハードウェアを利用しているかを調べました。中でも、Internet Explorer 9、Windows Live メール、Windows Live Messenger は DirectX を効果的に使っています。これらのアプリは DirectX を上手に利用しているため、他のアプリの動作を確認できる良い例と言えます。これは、メインストリーム アプリを高速に動かし、魅力的に見せるために大いに役立ちました。

テキストのパフォーマンスの向上

テキストは Windows で最もよく使われるグラフィカル要素なので、テキスト レンダリングのパフォーマンスを強化すれば、エクスペリエンスを大幅に向上させることができます。高品質で高パフォーマンスなテキスト表示は、Web ページ、電子メール プログラム、インスタント メッセージング、その他のリーダー アプリのすべてにメリットをもたらします。

Metro スタイルの設計言語は豊富な文字体裁に対応しており、多くの Metro スタイル エクスペリエンスが、快適なリーディング エクスペリエンスの実現に力を注いでいます。DirectWrite を使うと、高品質な文字体裁を利用したり、レンダリング用のフォント データを非常に高速に処理したりできるほか、業界最先端のグローバル テキスト サポートも提供されます。私たちは、Metro スタイル アプリでの既定のテキスト レンダリングを最適化し、文字体裁の質とグローバル テキストのサポートを維持したままパフォーマンスと効率を高めることで、Windows 8 のテキスト パフォーマンスをさらに向上させました。

下の棒グラフは、この取り組みによるパフォーマンスの改善結果を表しています。これには次のテキスト シナリオの測定結果が含まれています。

• Web ページや Word 文書のように、読みやすいサイズのテキストの段落が全体に表示される画面のレンダリング。
• ボタン ラベルやメニューなどのユーザー インターフェイス コントロールのように、読みやすいサイズの短いテキストが各所に表示される画面のレンダリング。
• Metro スタイル アプリのタイトルと見出し、ブログ記事や Web 上のニュース記事の見出しのように、見出しのサイズの短いテキストが各所に表示される画面のレンダリング。

パフォーマンスの改善が最もわかりやすいのは、長いドキュメントをタッチ スクリーンでスクロールする場合です。文字のレンダリングに必要な時間が短縮されれば、CPU サイクルが解放され、頻繁に発生するタッチ入力などの他のタスクを処理したり、より複雑なドキュメント レイアウトを表示できる余裕が生まれます。

ジオメトリ レンダリングのパフォーマンスの向上

テキストと共に、2D ジオメトリ レンダリングのパフォーマンスも大幅に向上しています。ジオメトリのレンダリングは、表、グラフ、ダイアグラム、ユーザー インターフェイス要素などの作成に使われるコア グラフィックス テクノロジです。例として下の図を見てください。Windows 8 では、この分野の強化点として、パフォーマンスに優れた HTML5 キャンバスと SVG テクノロジの実装を提供することを主な目標としました。これらの機能は、Metro スタイル アプリや Internet Explorer 10 を対象とした Web ページで使われます。

Windows 8 の Weather アプリでは、過去の気温データと降水量データのグラフ表示にジオメトリが使われている

Direct2D でジオメトリを描画するときは、2D 図形 (四角形、楕円、パスなど) として描画するもの、その図形のサイズと位置、ブラシの色やストローク スタイルなどのレンダリング スタイルの詳細について、アプリから Direct2D に処理命令を渡します。この処理命令はトライアングルとコマンドのセットに変換され、目的の出力を生成するために Direct3D に送信されます。この変換プロセスは "テセレーション" と呼ばれます。

Windows 8 におけるジオメトリ レンダリングのパフォーマンスを改善するために、私たちは、テセレーションに関連する CPU コストの削減に力を注ぎました。これは 2 つの方法で行われました。

まず、四角形、直線、角丸四角形、楕円などの単純なジオメトリをレンダリングするときのテセレーションの実装を最適化しました。下の図は、この改良による効果を示しています。

次に、グラフィックス ハードウェアの新機能である "Target Independent Rasterization" (TIR) を使い、変則的なジオメトリ (地図上の地理的境界線など) をレンダリングする際のパフォーマンスを改善しました。

TIR を利用すると、Direct2D がテセレーションで消費する CPU サイクルが減少するため、画質を犠牲にすることなく、GPU に対する描画命令をよりすばやく効率的に発行できます。TIR は、Windows 8 向けに設計された、DirectX 11.1 をサポートする新しい GPU ハードウェアで利用できます。

下のグラフは、さまざまな SVG ファイルについて、TIR 対応の DirectX 11.1 GPU でアンチエイリアスが有効なジオメトリをレンダリングした場合のパフォーマンスの向上を表しています。

私たちは、グラフィックス ハードウェア パートナーと緊密に協力して TIR の設計を行い、このパートナーシップによって劇的な改善が実現されました。現在、市場には既に DirectX 11.1 ハードウェアが登場しています。より多くの TIR 対応製品が広く利用可能になるように、私たちは引き続きパートナーと協力して作業を進めています。

画像のレンダリング

画像は、ユーザー インターフェイスの表示、Web ページの表示、その他のアプリ コンテンツの表示など、さまざまなシナリオで広く使われます。Web サイトでは一般に、写真には JPEG が、ボタン画像などのユーザー インターフェイス要素を効率よく保存するためには PNG ファイルと GIF ファイルが使われます。

デジタル写真の処理も Windows でよく行われる操作です。Windows ユーザーが PC で表示したり処理したりするデジタル写真の数は、驚くほどの速さで増え続けています。

JPEG、GIF、PNG 形式の画像と写真の処理には、パフォーマンス上の改良がいくつか加えられています。

JPEG の改良点には次のようなものがあります。

• すべての CPU アーキテクチャで SIMD の使用場面を広げ、画像のデコードを高速化。
• Huffman デコードおよびエンコードを高速化。

PNG の改良点には次のようなものがあります。

• すべての CPU アーキテクチャで SIMD の使用場面を広げ、画像のデコードを高速化。
• 独自の zlib の実装を最適化し、画像のエンコードとデコードを高速化。

さらに、ピクセル形式の変換と画像の拡大縮小の処理も改良しました。この結果、すべてのアプリで画像のデコードとレンダリングが高速化されます。

下のビデオでは、テスト用のアプリを使って、一連の画像のデコードとレンダリングにかかる時間を計測しています。Windows 8 では、64 個の画像のレンダリングにかかる時間が Windows 7 と比べて 40% 短縮されています (4.38 秒と 7.28 秒)。

レンダリングと表示

私たちは、DirectX を拡張してメインストリーム シナリオのサポートを広げると同時に、アプリによるコンテンツのレンダリング方法と表示方法を最適化することにも力を注ぎました。3D ゲームでのコンテンツの描画方法と、Internet Explorer のようなメインストリーム アプリでのコンテンツの描画方法には、いくつかの大きな違いがあります。例として、下のゲームの動画を考えてみましょう。このようなゲームでは、シーン全体が次々と変わります。"カメラ" が車の周辺を移動するのに伴い、空では雲が動き、エンジンからは煙が舞い上がります。魅力的で本物らしいエクスペリエンスを実現するためには、アプリでフレームごとにシーン全体を再描画する必要があります。

ビデオをダウンロードしてお好みのメディア プレーヤーで再生することができます:
高画質 MP4 | 低画質 MP4

次に、下の Web ページを見てください。このページには、テキストの記事と動画の両方が含まれています。動画を再生している間、ブラウザーでは、テキストの部分はそのままに、動画が表示されている部分だけを更新する必要があります。また、ユーザーがページを上へスクロールした場合、レンダリングが必要になるのは、ページの下部に位置する新しいテキストだけです。残りのテキストは既にレンダリングされているので、単純に移動するだけで済みます。

フレームごとに画面全体を再描画する必要のないアプリを改善するために、私たちは、DirectX で画面の一部だけを再描画するときの動作と、スクロールの動作を最適化しました。この取り組みにより、アプリの効率とパフォーマンスが改善されるだけでなく、電力消費も低く抑えられ、結果としてバッテリの駆動時間が長くなります。これは、余分な描画処理が減り、グラフィックス データをメモリにコピーする回数も少なくなるためです。

プラットフォーム全体の改善

これらの変更はいずれも、Windows によるエクスペリエンスのレンダリングをすばやく滑らかにするために一役買っています。ここまで主に DirectX の機能についてお話ししてきましたが、これらの取り組みのすばらしいところは、プラットフォーム全体に既定でハードウェア アクセラレーションが適用されるようになる点です。Metro スタイル プラットフォームは DirectX の基盤の上に構築されているため、開発者が選択したプログラミング言語やフレームワークにかかわらず、どのアプリでもシステムのグラフィックス ハードウェアを最大限に活用することができます。

Direct2D と Direct3D による魅力的なビジュアル エクスペリエンスの作成

Direct2D Effects

最近のユーザー エクスペリエンスでは、画像に装飾的効果を適用することが一般的になってきています。このような効果は、アプリの一部を強調表示したり、画面の特定部分にユーザーの注目を集めたり、見た目をきれいにしたりするために役立ちます。Windows 8 のグラフィックス機能を設計するにあたり、私たちは、このような種類の効果を開発者がごく簡単にアプリに適用できるようにしたいと考えました。そこで、画像処理が役立つ可能性のある 2 つの場面について検討しました。

• ユーザー インターフェイスの画像
  Metro スタイル エクスペリエンスでは動的なビジュアルが使われます。私たちは、Metro スタイル アプリでリアルタイムに画像処理を実行できるようにしたいと考えました。画像処理とは、3D 切り替え効果から、透視変換、ぼかし、ユーザー インターフェイス要素の強調表示まで多岐にわたります。
• 写真
  写真を扱うアプリでは、豊富な画像処理機能が求められることがよくあります。露出、明るさ、コントラストの調整、鮮やかさや明瞭さの適用、高度な曲線の処理、レンズ補正の適用などの効果を使うと、このタイプのアプリでデジタルの思い出をさらに輝かせることができます。

このようなエクスペリエンスを実現するために追加されたのが、"Direct2D Effects" という新しい API セットです。これにより、ハードウェア アクセラレーション対応の高品質な効果を任意の画像に適用できます。Direct2D Effects には次のような利点があります。

• 画像の効果が最適な品質でレンダリングされ、さまざまなアプリのニーズに対応できる。
• 効果にはハードウェア アクセラレーションが適用され、広範囲にわたるグラフィックス ハードウェアに対応する。
• シンプルな API により、最小限のプログラミングで質の高い効果を使うことができる。
• 組み込みの効果が数多く用意されている。
• 大きいサイズの画像がサポートされ、32 ビット/チャネルまで対応する。
• カスタム効果を、組み込みの効果や別のカスタム効果と組み合わせることができる。

Direct2D Effects は、Windows 8 の新しいユーザー エクスペリエンスの一部を強化します。たとえば、スタート画面をタップすると、タイルに 3D 透視変換効果が適用され、適切な方向に "傾斜" します。Direct2D Effects は、プラットフォームの他の部分でも使われます。たとえば、SVG フィルター効果と CSS 3D Transforms は、Direct2D Effects を使って実装されています。

共通基盤としての Direct3D 11.1

Direct2D Effects のような新機能の追加は開発者が新しいエクスペリエンスを実装できるようにするために役立ちますが、一方で私たちは、既存の DirectX 機能をより使いやすくする方法も模索していました。

長年にわたる開発を通して、DirectX にはさまざまな機能が追加されています。動画のデコード処理のハードウェア アクセラレーションは、Direct3D 9 でプログラミング可能なシェーダーとして登場しました。Windows 7 では Direct2D が追加され、Direct3D 10 の上に載せる形で組み込まれました。当時はまた、GPU による高パフォーマンス計算のための新しいシステムとして DirectCompute も作成され、これは Direct3D 11 の一部となりました。このような一連のアップデートの結果、DirectX にはグラフィックスと GPU 計算に関するさまざまな機能が数多く含まれることになりましたが、副作用として、ビデオ、2D グラフィックス、3D グラフィックス、テキスト、DirectCompute を合わせて使うアプリの開発はしだいに難解になっていきました。

Windows 8 では、新しい Direct3D 11.1 API が、2D グラフィックスとテキスト、3D グラフィックスと計算、および動画にハードウェア アクセラレーションを適用するための基盤となります。新しい API では、レンダリングに関連するすべての GPU リソースをその単一の API で管理できるため、異なる種類のコンテンツを 1 つの画面に混在させることがずっと簡単になります。また、アプリのコードで複数のグラフィックス デバイス管理オブジェクトを作成する場合に生じる冗長性が排除されるので、メモリ使用率を減らすこともできます。加えて Direct3D 11.1 は、異なるグラフィックス ハードウェアのさまざまな機能にアプリからアクセスするための統一的な方法を提供します。アプリでは、利用可能な機能を判別し、有効な機能だけを使うことができます。これにより、GPU がタブレットのバッテリを長持ちさせるように設計されている場合でも、デスクトップ PC でハイエンドなゲームを楽しむように設計されている場合でも、アプリで GPU の性能を最大限に活用することができます。

多様なグラフィックス ハードウェア

過去、各時点における次期リリースの Windows には、グラフィックス プラットフォームとグラフィックス ハードウェア性能の両方がさらに充実し、パフォーマンスも向上することが当然のように期待されてきました。これは現在にも当てはまり、グラフィックス ハードウェア業界では、より高速でより強力な GPU の開発が続けられています。しかし Windows 7 のころ、ハードウェアの多様化が進み、省電力の携帯デバイスが増えてきた状況を受けて、私たちはこの前提が変わりつつあることを感じ始めました。

Windows 8 においても、ハードウェアの種類が多様化する傾向はますます強くなり、新しい高性能なグラフィックス カードが開発されると同時に、さまざまな省電力携帯デバイスも次々と登場しています。Windows 8 向けのハードウェアは、常時接続型のタブレットで約 1 ワットを消費するグラフィックス ハードウェアから、合計で 1,000 ワット以上を使う複数のグラフィックス カードが搭載されたハイエンド システムまで、これまでにないほど広範囲にわたります。この幅広い多様性には、設計上の新しい検討事項が伴います。

私たちの目標は一貫して、視覚的に魅力的でパフォーマンスの高いエクスペリエンスを実現することです。携帯性の高いデバイスでは、バッテリが主な電源として使われるため、バッテリ駆動時間を最大化する必要もあります。このような新しいフォーム ファクターでのパフォーマンスと電力消費の要件を両方とも満たすために、私たちのグラフィックス ハードウェア パートナーの多くは新しい GPU アーキテクチャを採用しています。

省電力システム

パフォーマンスに加えてバッテリの長時間駆動が求められる省電力設計のシステムでは、"タイル ベースのレンダリング" というグラフィックス アーキテクチャが一般によく使われます。タイル ベースのレンダリングでは、基本的な概念として、きわめて高パフォーマンスの (ただし小さい) メモリ キャッシュを用意し、それをグラフィックス エンジンがレンダリングに使うという手法が取られます。GPU は、画面全体を一度に処理するのではなく、同一のコマンド セットを各タイルに対して繰り返し処理することで、それぞれのセクション (タイル) の画面をレンダリングします。これは、チップ外のメモリを使う処理を最小化し、電力消費を抑えて高パフォーマンスを維持することを目的としたしくみです。チップ外のメモリに何度もアクセスすると、時間的にも電力消費的にもコストが高くなります。

このタイル ベースのアーキテクチャの効果を高めるため、私たちは多数のフラグ、ヒント、新しい API を追加して、タイルのレンダリング回数を最小化できるようにしました。これらは Metro スタイル アプリの開発プラットフォームに取り込まれているので、タイル ベースのレンダリング アーキテクチャを使うグラフィックス ハードウェアでのアプリの動作効率が大きく向上します。

パフォーマンスを維持したままグラフィックス ハードウェアの電力消費を抑えるには、グラフィックス レンダリングの計算をより低い精度のビット数で実行する方法もあります。これにより、GPU ではより効率的にデータを構築できるようになるため、同時に処理できるデータが増え、必要な電力は少なくなります。Windows 8 では、グラフィカル計算に必要な精度をアプリで指定できるようにする新しいしくみが追加されています。たとえば、複数の画像のカスタム ブレンドを実行する場合、画像データが 8 ビット/コンポーネントであるとすると、ブレンド計算は既定の 32 ビットではなく 10 ビットの精度で実行すれば十分です。精度を下げても画質には影響しません。それでいて電力消費は抑えられます。

優れたパフォーマンス、滑らかなレンダリング

ビデオをダウンロードしてお好みのメディア プレーヤーで再生することができます:
高画質 MP4 | 低画質 MP4

ここまでの説明でおわかりのように、私たちは、Windows 8 で非常にすばやく滑らかなアニメーションのユーザー エクスペリエンスを実現するべくたくさんの作業を行ってきました。進捗状況を測定する新しい手法から、グラフィックス プラットフォームのメインストリーム用途を対象とした最適化、そして新しいハードウェア機能に至るまで、私たちが作り上げた Windows グラフィックス プラットフォームはこれまでで最高のものと言えます。もちろん、今後もさらなる改良を続け、優れたパフォーマンスとステレオスコピック 3D などの新機能により、プレイヤーが夢中になるような 3D ゲーム体験を強化していく予定です。

Windows 8 では、ゲームに適した高性能デバイスから常時接続の軽量タブレットまで、かつてないほど広範囲にわたるグラフィックス ハードウェアが単一のオペレーティング システムでサポートされます。まったく新しいリッチなエクスペリエンスを実現するこの取り組みについて、この記事が多少なりとも理解の助けになればさいわいです。

- Rob Copeland

追記: この記事の執筆にあたっては、Sriram Subramanian 氏、Dan McLachlan 氏、Kam VedBrat 氏、Steve Lim 氏、Jianye Lu 氏より多大なご協力をいただきました。ありがとうございました。

2 月に Windows 8 Consumer Preview をリリースする少し前に、障碍 (しょうがい) のある方にとって Windows 8 をさらに利用しやすくする取り組みについて、このブログで紹介しました。その記事では、全盲の方がタッチ スクリーンから Windows 8 を使用できるナレーターの機能についても紹介しました。この機能は Release Preview でも引き続き進化していますが、Windows 8 の最終リリースに向けて、さらに強化される予定です。今回の記事では、タッチ対応 PC を使う場合に、より便利になったナレーターの機能のいくつかについて詳しく説明します。この記事は、アクセシビリティ チームの Doug Kirschner が執筆しました。 -Steven

---

まずは、フィードバックを寄せてくださった皆さんにお礼を申し上げたいと思います。肯定的な反応が多数ありました。Windows 8 のタッチ スクリーンに基本のスクリーン リーダーが既定で含まれることを非常に喜んでいただいています。ナレーターのタッチ スクリーンでの動作を改善し、Web での操作性を向上するために私たちが取り組めることについて、膨大な数の建設的なフィードバックをいただきました。私たちは皆さんの声に耳を傾けました。皆さんのご提案と、視覚障碍のある方を対象に Microsoft で実施したユーザビリティ テストから得られた提案とを総合して、皆さんのお気に召すと思う、重要な変更をいくつか施しました。

アクセシビリティ コミュニティの声に耳を傾ける

私たちは Developer Preview がリリースされたタイミングに乗じて、できるだけ多くの、視覚的な支援を必要とされる方に呼びかけて、ナレーターに対するフィードバックを収集しました。手始めに、Windows 8 をインストールし、感想を送ってもらうよう、Microsoft 社内のコミュニティの協力を仰ぎました (さいわい Microsoft には、すべての Microsoft 製品のアクセシビリティに取り組んでいる大規模で組織的なコミュニティがあります)。また、会場に来れば実際に試すことができる、社内のアクセシビリティ イベントを開催しました。Microsoft のキャンパスにユーザーを招いて、タッチ スクリーン上でナレーターを実際に操作し、一般的な作業を実行していただくユーザビリティ テストも実施して、改良できる点を探りました。Developer Preview と Consumer Preview は数百万名にダウンロードされていて、多くの方がナレーターを試し、非常に参考になるフィードバックを送ってくださっています。さらに、@BuildWindows8 をとおしても多くのユーザーからコメントをいただきました。また、テクノロジと障碍者について考える CSUN カンファレンス (英語) に出席し、そこで Windows 8 Consumer Preview をタッチ スクリーンで初めてお使いになるようすを、お 1 人 1 人の横に座って拝見することができました。

私たちには、検証したかった重要なシナリオが 2、3 ありました。特に、タッチを使用する場合に、新しい PC を箱から取り出してすぐに、ナレーターを使って起動し、実行できることを確認したいと考えていました。これには、ストアからアクセシビリティ対応アプリを探してインストールすることや、電子メールの送信、Web ページの閲覧、音楽鑑賞など基本的な日常の作業を実行できることが含まれます。これまで私たちが実現した機能についての反響は圧倒されるほどで、非常に嬉しく思っていますが、タッチ対応のナレーターをよりよいものにするためにすべきことがまだあるのは明らかでした。

建設的なフィードバックを寄せてくださった皆さんのおかげで、以下のような重要な領域を特定できました。これらは、Release Preview で改良されています。

• 応答性: タッチ スクリーン上ではナレーターの応答性が十分でないと感じられるというご意見をいただきました。
• ジェスチャ: ナレーターのジェスチャ、特に、複数の指を使う複雑なジェスチャのいくつかを、スムーズに使っていただけない場合がありました。
• アプリの探索: 特定のアプリや UI の知識がまだない場合は、画面上の特定の要素を見つける (スタート画面上のタイルを見つける) ことは難しい可能性がありました。
• Web ナビゲーション: Consumer Preview で提供されていたコマンドは、一部の Web ページには十分に対応できませんでした。

Release Preview に向けて上記の各領域について懸命に取り組みました。一部の領域については、Windows 8 の最終リリースに向けて、現在も取り組みが続けられています。ここでは、現在 Release Preview で利用することができる、機能強化の一部をご紹介したいと思います。

ビデオをダウンロードしてお好みのメディア プレーヤーで再生することができます:
高画質 MP4 | 低画質 MP4

タッチ操作に対するナレーターの応答をわかりやすくする

ナレーターのタッチ機能は応答性が高いとは感じられないというご意見をいただきました。ナレーターが遅い、ナレーターが応答しないときがある、単に突然アクセスできなくなったと感じたり当惑したなど、フィードバックの表現はさまざまですが、この問題の根本原因は同じです。ユーザーは、画面にタッチするとき、タイムリーな応答を期待します。この問題は、次の 2 つのシナリオでよく発生することがわかりました。

• 1 本指の探索: 1 本指でドラッグして画面上の項目を見つけなければならなかった場合に、指を動かすのが速すぎて、ナレーターが項目の読み上げを開始する間もなく、目的の項目を通り過ぎる場合がありました。
• ジェスチャの応答: ジェスチャが成功したかどうかがわからずに、1 回目のジェスチャが既に成功しているにもかかわらず、同じジェスチャを何度も繰り返す方がいました。問題は、ナレーターがジェスチャを認識してから、音声応答を返すまでに遅延があることでした。また、ユーザーが意図した操作をナレーターが実行したかどうかが、応答からは明確に判断できないことや、似ているが関係のない内容が読み上げられているだけのことがありました。

いずれの場合も、視覚的には、ナレーターが現在読み上げている項目に移動するハイライト用の青い枠が、該当する項目にすばやく移動して、ナレーターはユーザーの動きを登録し、適切に応答していることが示されていました。ただし、問題は実際のスピーチ プロセスにありました。音声合成 (TTS) は高速ですが、高速であっても、システムが応答を読み上げるには時間がかかります。また、言語を処理し、聞こえてくる内容を理解するための、認識処理にも時間がかかります。さらに複雑なことに、音声応答にかかる時間は、コンテキストによって大きく異なります。このため、意図したジェスチャがナレーターによって認識されたジェスチャであるかどうかをユーザーが判別することは困難です。これらの短い遅延が積み重なった結果、項目を完全に飛ばしたり、最初のジェスチャが成功しなかったと考えて、成功しているジェスチャを繰り返したりします。

音声による合図

視覚障碍のないユーザーであれば、ある操作が完了するまでに数ミリ秒よぶんにかかったとしても、ボタンがハイライトされたり、ポップアップがアニメーション表示されたりする視覚的なフィードバックによって、システムは応答していることがすぐにわかります。このような合図は、美観的に好ましいだけでなく、リアルタイムでタッチがシステムにどのように影響するかを理解するために機能的にも重要です。

応答性に関するフィードバックについて詳しく調べるにつれて、ナレーターで音声の合図をより効果的に利用できることに気が付きました。Release Preview で、音声による合図の導入を始めました。各ジェスチャに、そのジェスチャが実行されたときに再生されるサウンドが関連付けられています。これらの合図は、すぐに反応し、再生時間が短く、容易に区別できるようになっていて、ジェスチャが成功したかどうかと、操作が実行されているかどうかを直ちに認識できます。以下に例を示します。

• 次の項目に移動すると "チッ" と鳴ります。
• アクティブになると "カチッ" と鳴ります。
• スクロールをすると、スライド音が鳴ります。
• 選択すると "トン" と鳴ります。
• ナレーターのエラーでは、システム エラー時の "ティン" という音とは簡単に区別できる "ブッ" というエラー音が鳴ります。
• 1 本の指で画面を探索していて、新たに項目をタッチするたびにナレーターがチッという音を鳴らすので、次の操作に移るのが早すぎて、項目の説明を聞けなかったのかどうかを知ることができます。

これらのサウンドの設計および実装には、非常に楽しく取り組むことができました。

対話式操作を簡単にする

今度は、ナレーターのタッチ操作モデルを調整する必要がありました。一部の方から、複数の指のジェスチャは使いにくかったという声を頂戴しました。特に、2 本指のスワイプで次の項目や前の項目になかなか移動できず、ましてや、4 本指のスワイプでのスクロールはさらに困難な場合がありました。また、誤ってコマンドの一覧 (利用可能な項目のコマンド、検索ウィンドウなど) を表示して、アプリでのコンテキストが失われることもありました。

そこで、より簡単にタッチ対応のナレーターを操作できるようにしました。より覚えやすいシンプルなジェスチャ モデルを採用し、より簡単に使用できるようになりました。1 本指のタップとフリックによって、ナレーターでよく使われるタスクの大半を実行できるようにしています。新しい対話式操作モデルは実行しやすく、ジェスチャがさらに論理的に分類されているため、コマンドの一覧やウィンドウに無関係のジェスチャを実行しようとしている場合にそれらが表示されることはありません。

以下の表に、新しい対話式操作モデルの概要を示します。

ナレーターの探索モデルを改良する

Developer Preview のユーザーからのフィードバックを収集した結果、ナレーターの探索モデルを見直しました。1 つ明確にわかったのは、画面全体をいちいちタッチしなくても、ボタン、ラベル、テキスト フィールド、リスト項目など、画面上のすべてのコントロールを簡単に確認できる手段が求められているということでした。目の不自由なある方は、ホテルの部屋に入ったら、何かをする前に必ず最初に部屋の中を歩き回り、ドア、ドレッサー、ベッド、洗面所の場所を確認して、部屋のレイアウトを把握すると、たとえを使って説明してくださいました。同様に、新しいアプリを探索するときは、画面上に何があるのかを確認してから、次に実行する操作を決定します。

Developer Preview では、画面上のすべての要素をアクセス可能にする手段の 1 つとして、横方向のスワイプ ジェスチャを使うと、コンテナー内の項目間を移動でき、縦方向のスワイプ ジェスチャを使うと、コンテナーの内外に移動できるようになっていました。これは、画面上にあるすべてのアクセシビリティ対応の項目を見つけることができる強力なモデルで、グラフィカル UI の構造を忠実に表していました。しかし、これは直感的ではありませんでした。コンテナーへの出入りが必要なことで、画面上にある興味深い要素のすべてを発見するのが困難になっていました。

既定のカーソル モードを変更する

フィードバックに応えて、Release Preview では、既定のナビゲーションの動作をいくつか変更しています。ナビゲーションのジェスチャはすべて 1 本指の左右のフリックになり、これだけで画面上のすべての項目間を移動できるようになりました。UI の構造を知らなくても、UI のナビゲーションができるようになりました。フリックだけで次の項目や前の項目に移動でき、ナレーターによって、画面上の重要な項目が順番に示されます。

これにより、アプリ内の興味深い項目を簡単な手順で順番にすべて確認でき、アプリを探索しながら任意の項目を操作できます。いちいちフリックせずにアプリ内のすべての項目が読み上げられるようにする場合は、3 本指で上にスワイプすると、ナレーターが順番にすべての項目を連続で読み上げます。

(注: これは、ナビゲーションの新しい既定のモードで、左右のフリックによってアプリを探索でき、興味深い項目をすべて見つけることができます。UI の複数のレイヤー間を手動で移動する以前の方法を使いたい場合は、ナレーターの設定でナレーター カーソルの移動モードを [Advanced] (上級者用) に変更してください)。

Web ナビゲーションを強化する

Windows 8 では、ナレーターを使って Web の読み上げが格段に簡単になりました。Web の読み上げ用に最適化されたさまざまな機能があり、たとえば、"読み上げを開始する" コマンドでは、Web ページ上の連続しているセクションが中断せずに読み上げられます。また、検索モードを使うと、ページ上の各種コマンドが列挙されます。Developer Preview と Consumer Preview のリリース後に、これらの機能は便利だが、ニュースのヘッドラインをすばやく確認する、クイック検索を実行する、株価を確認するなど、Web で実行する一般的な作業のいくつかを実行できないというご意見をいただきました。

そこで、この機能を見直すことにしました。詳しく調べるにつれてこれらのシナリオについての理解が深まり、Release Preview でどのように改良したらよいかがわかりました。特にニュースの読み上げでは、ページ内のさまざまなポイント (ヘッドラインやリンクなど) に移動し、その後 1 行ずつ、さらには 1 文字ずつ読み上げできるようにしたいというフィードバックをいただきました。多くのユーザーが、ナレーターがこれらのコマンドを提供し、より正確な Web ナビゲーションが可能になることを望んでいました。

そこで、ナレーターのナビゲーション コマンドにビューの概念を追加しました。新しいビューは、Web ページや、メール アプリ内などその他のアクセシビリティ対応のテキスト領域を表示している場合に、既定のナビゲーション モードで利用できます。既定の項目ビューでは、ページ上の項目間を移動でき、システムの項目ナビゲーションと同様に動作します。ただし、Web ページやメールなどのアクセシビリティ対応のテキスト領域の場合、ナレーターは 7 種類のビューを新たにサポートしています。

• 見出し
• リンク
• 表
• 段落
• 行
• 単語
• 文字

上または下にフリックすることでビューは簡単に切り替えられます。また、左または右にフリックすると、ビュー内の項目間を移動できます。これらのコマンドは、キーボードで CapsLock キーと方向キーを使うことでも利用できます。

新しいビューが導入されたことで、Release Preview では Web の読み上げがさらに便利になりました。新しいビューは、ナレーターの読み上げコマンドとも連携しています。たとえば、面白そうなニュースのヘッドラインを見つけて、もっと内容を知りたい場合、3 本指で下にスワイプすると、ナレーターがすべてのページ コンテンツの読み上げを開始し、停止を指示するまで読み続けます。

しあげをする

ここで紹介した例は、Developer Preview および Consumer Preview のナレーターのタッチ機能を試した方からのフィードバックに応じて取り組んだ大規模な機能強化の一部です。項目をアクティブにする方法を伝えるタッチ ヒントの読み上げ、タッチ操作で使いやすく改良されたナレーターの設定 UI、タッチ キーボードからの入力を簡単にする新しい設定の追加など、皆さんのフィードバックを基に、他にも多くの機能強化を施しています。現時点で、ナレーターはフィーチャー コンプリートの状態であると思っていますが、Windows 8 の完成に向けて、現在もバグの修正と微調整を行っています。

ナレーターを試す機会があった皆さんから、これほど多くのフィードバックを頂戴することは、すばらしいと同時に、いたらなさを痛感する経験でもありました。ユーザビリティ テストを通じて、CSUN カンファレンスで、また Microsoft のコミュニティ内で、ユーザーの方 1 人 1 人と交流できたことは本当に楽しい体験でした。建設的なすばらしいフィードバックを寄せてくださった皆さんのおかげで、Release Preview に向けて、ご紹介したような重要な変更をナレーターに実施し、利便性を大幅に向上できました。

Windows 8 の最終リリースに向けて開発作業が進められるあいだ、皆さんはぜひ Release Preview をダウンロードしてインストールし、ナレーターをお試しください。

注: このブログで説明したタッチ機能には、少なくとも 4 つのコンタクト ポイントをサポートするタッチ スクリーンが必要です。Windows 8 認定タッチ ハードウェアはすべてこの要件を満たすことになりますが、現在の Windows 7 ハードウェアの中にはこの要件を満たさないものがある可能性があります (詳細についてはこの記事を参照してください)。4 つのコンタクト ポイントをサポートするタッチ スクリーンをお持ちでない場合も、キーボードを使ってナレーターを実行できます。

お読みいただき、ありがとうございました。

-Doug Kirschner

初期のタブレット PC 拡張機能が Windows に組み込まれたころから、私たちは "スクリーン キーボード" に対応してきました。Windows 8 では、タッチ キーボードの開発を一から見直し、"基本的な原則" に則ったアプローチを取っています。現在では、多くの人が携帯電話のタッチ キーボードに慣れ、他のさまざまなタッチ デバイスに触れる機会も山ほどあります。このような状況を考慮して、Windows 8 の新しいタッチ キーボードは、きわめて高い水準のエクスペリエンスと入力効率を実現するようにデザインされています。この記事では、Windows ユーザー エクスペリエンス プログラム管理チームのメンバーである Kip Knox が、タッチ キーボードへの取り組みについて詳しく説明します。-- Steven

---

Windows 8 の設計中、タッチ操作や新型 PC への対応を構想し始めたときから、私たちは、タブレットやその他のタッチ スクリーン PC で効率的にテキストを入力する手段の必要性を認識していました。タブレット PC 機能が組み込まれた Windows XP SP1 以降、Windows にはタッチ対応のスクリーン キーボードが付属しています。ただし、この機能はデスクトップ エクスペリエンスに対する拡張として設計されたものでした。Windows 8 では、このモデルを改良して、ユーザーのニーズを満たし、私たち自身の設計原則に合致し、現在流通しているフォーム ファクターと今後登場するフォーム ファクターで快適に使用できるテキスト入力サポートを導入しています。

私はこの記事を、Windows 8 のタッチ キーボードで標準の英語 QWERTY レイアウトを使って執筆しています。私が見る限り、このキーボードは非常にシンプルで、だいたい見ればわかるようにできています。これは、しばらく使って理解したからという部分もありますが、キーボードというものに私たちが馴染んでいるためでもあります。ただしここには、目に映る (あるいは指に触れる) 以上のものがあります。

私たちは、先入観を捨ててこの機能の設計に取り掛かりました。必要なすべての機能を実装するにあたり、テキスト入力を設計するプロジェクトの最初の作業は、一連の原則や目標を定めることでした。タッチ対応の Windows 8 PC で私たちが目指しているのは、次のような動作を達成することです。

• 物理キーボードで入力する場合とあまり変わらないスピードで、テキストをすばやく入力できる
• 間違いを避け、ミスを簡単に修正できる
• 入力時の姿勢、デバイスの操作、周囲の環境という観点から、テキストを快適に入力できる

ここでお気付きかもしれませんが、これらの目標は、いずれもキーボードを明示的に想定したものではありません。このプロジェクトが始まったとき、私たちは、テキスト入力に関して考えられる限りの幅広いアプローチを検討しました。しかし、私たちが検討したテキスト入力方式はどれも、上記の目標をキーボードほどに満たすものではありませんでした。ほとんどの人にとって、タイピングは他のどの方法よりもすばやく正確で、快適な入力方式です。Windows には、たとえば高度な音声認識機能や、いくつかの言語に対応する高精度な手書き認識機能も搭載されています。しかし、優れたタッチ キーボードがなくては、Windows 搭載のタッチ スクリーン デバイスに対してユーザーが求めているニーズと期待を満たすことはできません。そこで私たちは、どのデバイスでも使用できる最高のタッチ キーボードの作成に取り組むことにしました。

快適さと姿勢を考慮した最適化

タブレットのタッチ キーボードはさまざまな形が考えられます。私たちは、大型キーボード、小型キーボード、フローティング キーボード、円形キーボード、スワイプ キーボードなど、大量の青写真を作成しましたが、最初の設計プロセスは、タブレットの操作方法に関するユーザー調査に基づいて進められました。この調査では、ユーザーがタブレットと共に "生活" するようすが一定期間にわたって観察され、詳細な検討が行われました。このような観察とインタビューから、タブレットを操作するときの最も一般的な姿勢には次の 3 とおりがあることがわかりました。

1. 片手でデバイスを持ち、もう一方の手でユーザー インターフェイスを操作する
2. 両手でデバイスを持ち、親指で操作する
3. デバイスをテーブルの上、ひざの上、またはスタンドに置き、両手で操作する

タブレットと共に "生活" するユーザーを対象とした調査から、3 とおりの一般的な操作方法が明らかになった。

これらはユーザーにとって最も自然に感じられる操作方法であり、タブレットの使用中、最も長時間取られている姿勢と考えられます。Windows 8 では、これらの操作方法に向けて最適化し、ユーザーが直感的にテキストを入力できるようにするために、さまざまな設計上の決定が行われました。タブレットで入力する場合、ほとんどのユーザーは、ひざの上やテーブルにタブレットを置いて複数の指を使ってタイピングするか、両手でタブレットを持って親指で入力するか、片手でタブレットを持って文字を 1 つずつ探しながらタップする形のいずれかをとります。

私たちのタッチ キーボードの標準レイアウトは、タブレットを置いて複数の指で入力するように最適化されていますが、片手でも快適に入力することができます。また、分割キーボードと呼ばれる新しいレイアウトも用意されています (約 1 年前、Windows 8 の一番最初のプレビューで初めてご紹介したものです)。これは、両手でタブレットを持ち、親指で入力するように設計されています。このキーボードは、手の大きさに合わせてサイズを調整できます。操作方法の調査から、ユーザーは操作中の姿勢を頻繁に変更するという興味深い結果が得られました。この切り替えは多くの場合、快適に使い続けるためのポジティブな動作として行われています。このため、私たちのキーボード レイアウトは、ある程度の時間にわたって入力を行うとき (たとえばお母さんにメールを送るとき)、途中で姿勢を変えても対応できるように考慮されています。たとえば、最初はコーヒー テーブルの上にタブレットを置いて入力していても、その姿勢に疲れたら、タブレットを持ち上げ、ソファにもたれて両手の親指で操作することができます。

姿勢と快適さに関するさらに詳しい調査から、ユーザーがどのようにタブレットを持ち、一般にどのくらいの範囲まで親指が届くかを理解することができました。追跡調査では、手の大きさの異なるさまざまなユーザーにセンサー付きのタブレットを使ってもらい、親指がごく自然に届く範囲、親指を伸ばせば届く範囲、そして親指が届きにくい範囲について調べました。これらの結果は、親指でシステムを使う場合の操作性を最適化したり、分割キーボード レイアウトの形状を決めたりするうえで役立ちました。

分割キーボード レイアウトに重ねて、ユーザーの親指が届く一般的な範囲を示す温度分布を表示したところ。緑はごく自然に操作できる範囲、黄色は指が届く範囲、赤は一般に操作しにくい範囲を表す。

ガラス面でのタイピング

私たちが次に取り組んだ問題は、タブレットのガラス ディスプレイでの入力エクスペリエンスでした。主な利用形態の少なくとも 1 つ、つまりタブレットを置いて操作する方法は、物理キーボードで入力する動作とよく似ています。このため、携帯電話でテキストを入力する場合とは異なり、物理キーボードのエクスペリエンスと直接的に比較されることになります。ノート PC やデスクトップ パソコンで入力するときには、いくつかの物理的なメリットを享受することができます。入力しながら、さまざまな感覚的なフィードバックを得ることができるのです。まず、ホーム キーに両手を置くのが簡単です。ほとんどのキーボードでは J キーと F キーに小さい突起があり (英語 QWERTY キーボードの場合)、それぞれの位置を確認することができます。また、入力中に指の位置が動いても、キーの形状によって指がどこにあるかを感知しやすくなっています。各キーは上下に動くため、押したことがはっきりとわかります。さらに、キーボードは機械的なので、キーを打つ音によってもキー入力を確認できます (厄介なことに、会議中に同僚が電子メールをチェックしていることもわかってしまいますが)。

一方、ガラス板の上でタイピングをした場合、フィードバックは得られず、手を置く場所を示す印もなく、適切な位置に触れたかどうかを確認できる反応もありません。この点を認識した私たちは、いくつかの決定を下しました。何らかのフィードバックを提供する必要がありましたし、タッチ キーボードでの入力は "ぞんざい" になりやすいことを認める必要もありました。反面、物理キーボードではできないことがタッチ キーボードでは実現できることもわかったので、そのような機能を前面に出す必要もありました。

私たちは、タッチ キーボードに 2 種類のフィードバックを搭載しました。キーにタッチすると、そのキーの色が変わり、かすかなサウンドが鳴ります。この動作は、多くの携帯電話に見られるタッチ キーボードと似ています。他の形のフィードバックも検討しましたが、混乱を招きやすかったり不自然すぎたりしたために採用されませんでした。たとえば私たちは、触覚的なフィードバック (入力に応じてデバイスを振動させる方法) を検討しました。これは多くの携帯電話にも搭載されている機能です。しかしほとんどのユーザーにとって、現在の最新機能であるこの方式は、どのような長さのテキストを入力するときでもわずらわしく感じられ、振動は安心の印よりも誤操作の通知のように見なされています。

キーの視覚的変化とサウンドという、私たちが採用した 2 種類のフィードバックにも議論の余地はあります。キーの視覚的変化はいつでも理想的とは限らず、たとえばパスワードの入力中には望ましくないため、そのような場合はフィードバックを抑制できるようになっています。キーを押したときのサウンドが不自然でわずらわしいと感じる人もいます。それでも、ユーザー テスティングは私たちの仮説を裏付ける結果となり、ガラス面への入力中、ユーザーはサウンドによって明らかに安心感と確信を得ていることがわかりました。私たちが選んだ個々のサウンド (Windows Phone と非常によく似ています) は "余韻" となるように考慮され、記憶には残りませんが、オフにしない限りは気付くように設計されています。

どちらの形式のフィードバックも、ユーザーがいったんエクスペリエンスに馴染んでから、より頻繁に使われるようになる可能性があります。私たちがラボで実施した視線追跡調査によると、タッチ キーボードの使い方が上達するにつれて、ユーザーがキーボード自体を見る時間は短くなり、入力フィールドを見る時間が長くなります。したがって、効率よく入力しているときは各文字が一番のフィードバックになります。視線については、この記事で後ほどもう少し詳しくお話しします。

この視線追跡調査の温度分布に示されているように、タッチ キーボードの使用時間が長くなるにつれ、ユーザーの視線は入力フィールドに移っていく。

ただし、たとえタッチ キーボードでの入力に "熟練" しても、物理キーボードよりはミスが多く、入力速度も遅くなります。Windows 8 のタッチ キーボードは、この現実に対処できるように特別に調整されています。最も興味深いのは、"タッチ モデル" と呼ばれる機能です。

タッチ キーボードのキーをタップすると、タッチされた位置の座標が検出されるので、キーの配置に対応付けることができます。ただし、ガラス面の上を指が移動するとき、タッチしようとしたキーの境界よりも外側を押してしまうことがあります。このため、キーの配置のみに基づいて入力を処理すると、多くのミスが生じる可能性があります。このような状況に備えて、キーが押されると、まず、実際にそのキーを押そうとしたのか、近くにある別のキーを押そうとしたのかが評価され、両者の可能性が比較されます。この処理では 2 種類の情報が参照されます。その 1 つは、多数のユーザーによる "パングラム" (アルファベットのすべての文字を含むフレーズ) の入力データで、タッチした場所が意図したターゲットから外れていた場合の傾向が記録されています。たとえば、p を入力しようとして o が押されることがよくあります。これは、人間の指が内側にカーブしているためです。モデルでは、入力速度などの一連の特性に基づき、あるキーを押そうとして別のキーを押してしまう可能性に重みを付けています。もう 1 つの情報として、文章中で同時に出現することの多い文字や単語を表す辞書データが使われます。これはスペルミスを修正するしくみと同じです。これにより、ミスがあっても、ユーザーが何を入力しようとしたかをシステム側で推測することができます。

このようなタッチ モデルにより、たとえば QWERTY レイアウトで p を入力しようとしてうっかり o を押してしまっても、多くの場合はキーボードで自動的に間違いを修正することができます。または、"the" という単語を入力する場合を考えてみましょう。t を入力し、h を入力した後、e と w の中間、少しだけ w 寄りをタッチしたとします。タッチ モデルはこれを判定し、英語では t-h-w よりも t-h-e の方が一般的であることを認識して、正しく e を出力します。ただし、完全に w をタッチした場合は、その入力がユーザーの意図として尊重されます。このような処理がすべて入力中に行われるので、正しい文字が入力フィールドに出力され、それ以上の修正は不要になります。これが最適に機能しているときは、調整を意識することもなく、自信を持ってガラス面で入力を続けることができます。

タッチ モデル データに関するレポートのマップ。タッチ キーボードでの入力時に見られる特定のキーに対する傾向が明確に現れている。

入力に最適化

フィードバックの根拠を確立し、避けるのが難しいミスに対する "ガード レール" を用意した後は、個々のキーボード レイアウトを決定する必要がありました。つまり、どのキーをどこに配置するかを決めなければなりません。キーの位置は入力速度と正確さに大きく影響します。また、各ユーザーはキーに関して強い意見を持っているもので、矛盾を含んでいることもよくあります。しかし、ユーザーによる操作を観察し、物理的な実現性を検討した結果、デザイン上の問題は論理的に解消されていきました。たとえば、私たちが立てていた次のような仮説が実際に確認されました。

1. ほとんどのユーザーには、物理キーボードの習慣に基づく独自のくせが根強く身に付いています。この習慣を破ると、ユーザーの入力速度は大きく低下します。これはきわめて若いユーザーにも、T9 を専門とするタイピストにも当てはまります。私たちは、若いころに何らかの形でタッチタイプを習得するためです。
2. キーには、ターゲットとして操作しやすい最適なサイズがあります。物理キーボードに対して Microsoft が実施した詳細な調査の結果は、タッチの場合にも当てはまります。たとえば、私たちのタッチ キーボードの文字キーの幅は 19 mm ですが、これは多くの物理キーボードと同じ大きさです。ターゲットがこのサイズである (これよりも大きくも小さくもない) 場合に、ユーザーの入力速度が向上する傾向にあったからです。
3. キーの数が多いほど、ミスが起きる可能性も高くなります。その理由の 1 つは、キーが増えると各キーを小さくする必要があり、意図しないキーを押してしまう可能性が高くなるためです。また、キーが多いと見た目が雑然として注意が散漫になり、キーを探して見つけるスピードも遅くなります。
4. 画面の半分以上がキーボードで隠されるのは望ましくありません。キーボードが大きすぎると閉塞感を生み、状況を見失う原因にもなります。ただし、画面の約半分が隠れても問題はないという反論もあります。テキスト入力はほとんどの場合 "モーダル" な動作であり、ユーザーは入力そのものに集中していて、周辺にはそれほど注意が払われないためです。キーボードの外側で視線が向けられる領域はかなり小さく、入力中の文字に集中します。この記事で紹介している視線追跡調査でも、これが実証されています。
5. 一部のキーは他のキーよりも頻繁に使われます。これは、実環境で執筆されたテキストの一部を分析するとよくわかります。文字と記号の使用頻度には明確なパターンがあります。
6. 習慣が破られなければ、ユーザーは新しいことをすばやく習得します。

結局、どの言語においても、タッチ キーボードのレイアウトではさまざまな要素のバランスを取ることが重要になります。たとえば、既定のレイアウトではキーの数を減らす必要がありますが、日常的な入力に欠かせないキーを削除してしまうと、ユーザーに不満を強いることになります。レイアウトは、正確さを維持できる程度に大きく、それでいてアプリケーションを妨げない程度に小さくしなければなりません。

もう 1 つ、私たちが特にキーボード レイアウトに適用した全体的なルール/原則があります。つまり、入力しやすいように特化するということです。これは一見明白ですが、キーボードは言葉を書く以外にもさまざまな用途で使われる点を考慮すると、改めて意識することの重要性がわかります。キーボードは、UI のショートカット、コマンドの送信、コードの入力などにも使われるのです。私たちのキーボードは入力に最適化されています。入力こそが第一の目的であり、他の何よりも快適に達成できなければならないためです。では、これらの条件を満たすために下された決定の一部を少しだけ見ていきましょう。

数字

私たちの元には、既定のキーボード レイアウトに数字の列がないのはなぜかという質問が多く寄せられています。私たちは業務で頻繁に数字を使うので、物理キーボードの最上段には数字キーがあるのが一般的です。たとえば、Windows 7 のスクリーン キーボードには数字の列があります。Windows 7 のキーボードは本質的に物理キーボードのソフトウェア エミュレーションなので、数字の列の存在は全体的なデザインと調和しています。これは、タッチの世界に合わせて最適化されたものではありません。

Windows 7 のスクリーン キーボードは物理キーボードをエミュレートするものであり、タッチや入力に特化して最適化されてはいない。

初期に検討されたデザインやプロトタイプには、数字列を含むものもいくつかありました。しかし、このようなデザインをユーザーに見せたところ、それまでに使ってきたものに比べてキーボードが "窮屈" に感じられるという意見が多く寄せられました。ミスやキーの誤入力が頻繁に観察され、その傾向は特にレイアウトの周辺部で顕著でした。この結果、さまざまな変更が加えられ、数字列は廃止することに決まりました。理由として、数字列を含めると文字のキーが 4 段になります。キーを操作しやすいサイズに最適化した場合、キー列が 4 段ではキーボードが非常に高くなります。一般的なタブレット デバイス (10.6 インチの画面サイズ) では、数字列を追加すると、画面の半分以上がキーボードで覆われることになります。また、調査によれば、数字はほとんどの文字や一般的な記号よりも入力される頻度が低いという結果が出ています。さらに、余分なキーがあるとキーを間違って押す確率も高くなります。これらの事情を合わせて、私たちは、数字は数字と記号のビューに分離することに決定しました。

ここまで決まっても、数字の表示方法に関しては、数字と記号のビューの上部に列として表示するか、テンキーとして表示するかという議論が残りました。私たちは、次のような理由からテンキーを選びました。

1. 数字は複数を一度に入力することが多い。
2. 横長に 1 列になっているよりも、グループに整理されている方が探しやすい。
3. 数字が集まっている配置の方が、連続した数字をすばやく入力できる。

数字の配置は、最上段を 7、8、9 にするのではなく、上から 1、2、3 という順に並べることにしました。これは、コンピューター用の多くの拡張キーボードやレジで使われているのと同じ配列です。これは興味深いケースで、物理キーボードの習慣はそれほど問題になりません。ユーザーは、電話、ATM、リモコン、その他の最近のデバイスで使われているテンキーの並びに慣れ、それに満足しているからです。1、2、3 という順序は、他の並び順よりも目で追いやすく、頭で処理しやすいと言えます。

数字と記号のビューには、電話、ATM、リモコンなどで見かける最近のレイアウトを反映したテンキーが含まれている。

Tab キー

Tab キーにも同様の事情があります。Tab キーは、ドキュメントの書式設定のほか、Web ページ上の入力フィールドを移動するときなどに頻繁に使われます。このため私たちは、タッチ操作向けに最適化した初期のレイアウトで、物理キーボードに一般に搭載されているキーを大量に削除してから Tab キーを含めていました。このキーボードは次のようなものでした。

初期のキーボード レイアウトには追加のキーが含まれていたが、正確さとスピードが損なわれる結果となった。

この図を見ると、文字でも記号でもないキーの並びが左右にあることにお気付きだと思います。このレイアウトは前に述べたような結果になり、ユーザーから閉塞感を訴える声が寄せられました。さらに問題だったのは、境界付近のキーに誤ってタッチしてしまい、文字キーを入力し損なうことが多かったことです。これらを取り除いたところ、開放的で快適なレイアウトが好意的に受け入れられ、ミスは減り、入力速度が向上しました。数字と記号のビューに Tab キーを移動したため、Tab キーにはアクセスしにくくなりましたが、キーボードは入力のためのものであることを考えれば、Tab キーの役目は終わったと言ってよいでしょう。

Downshift: 学ぶべき失敗

最後の例として、一度は製品に含めたものの、その後廃止された機能についてご紹介します。この機能は、ビューを完全に切り替えなくても簡単に区切り文字にアクセスできるようにしたいという希望から導入されました。このデザインでは、左 Shift キーは通常の Shift キーとして機能し、大文字と既定のビューに含まれている記号の入力に使われます。右 Shift キーには異なる動作が割り当てられ、よく使われる記号や区切り文字の "プレビュー" が表示されます。このアイデアは、"Downshift" を押すだけで区切り記号などを選択できるようにするものでした。メイン ビューの情報は失われないため、すばやく操作できると予想していました。私たちは、これによって今までの習慣を打ち破り、ソフトウェアでしか実現できない付加価値を提供できると考えたのです。以下は "Downshift" キーボードの画像です。

Downshift はすばやく記号にアクセスできる手段としてデザインされたが、Shift キーが期待どおりに動作しないという不満を呼んだ。

このプロトタイプは、ラボで良い結果を生むことができませんでした。調査の参加者たちは、通常の Shift キーと同じ目的で右 Shift キーを何度も押していました。キーボードに記号の "プレビュー" が表示されると、ユーザーには戸惑いが広がり、入力が止まってしまいました。つまり、ここは物理キーボードの習慣を継承するべき部分だったのです。

正反対の例として興味深いのは、長押しの動作です。物理キーボードでは、いずれかの文字を押したままにすると、その文字が繰り返し入力されます。これに対して私たちのタッチ キーボードでは、キーを長押しすると、関連する他の文字や記号が表示されます。これは、タッチ キーボードで実現できて物理キーボードではできない機能の 1 つです。たとえば、ñ、é、š などの文字を入力する場合、これらを表示するキーの組み合わせを知らなければ物理キーボードで入力するのは大変ですが、タッチ キーボードなら簡単に見つけることができます。これは習慣とは異なる動作ですが、その点に不満を表したユーザーは実質的には 1 人もいませんでした。実際、これは便利に使われました。メニューから明示的に選択しなくても、押しているキーから追加のキーの方向へスワイプするだけでその文字を入力できます。アクセント付きの文字を頻繁に使う場合は、これで効率をかなり上げることができます。ぜひお試しください。

キーを長押しすると、関連するキーが表示される。目的の追加キーの方向へすばやくスワイプすると、そのキーを簡単に選択できる。

テストと検証

私たちは、視線を追跡する一連の調査を実施してきました。この調査では、調査の参加者がシステムを操作している間、視線の方向がカメラで記録されます。この調査結果は、いくつかの判断を下すうえで役に立ちました。たとえば、タッチ キーボードで入力しているとき、ユーザーはどこを見ているのでしょうか。注視点は時間が経つと変わるのでしょうか。これらのパターンはビューやレイアウトが変わっても一定でしょうか。そして、視点と入力速度の間には相関関係があるのでしょうか。

視線追跡調査の参加者がセッションを始めるところ。

調査を通じ、ユーザーが主に見ているのは、文字が表示されるテキスト フィールドとキーボードであることが一貫して確認されました。これはどのユーザーにも共通していたので、入力ヒントのエクスペリエンスはこの傾向に合わせて最適化されています。入力ヒント (入力に応じて予測される単語) は、テキスト フィールドのカーソルの右側に表示されます。その単語を挿入するには、タッチ キーボードの "Insert" キーをタッチします。この動作は、ユーザーが入力中に注目している場所を考慮して最適化されています。これは、多くの携帯電話に見られる入力ヒントの UI とは大きく異なっています。多くの携帯電話では、予測される単語がキーボードの上部に横 1 列に表示されます。フルサイズ キーボードが付属している PC の場合、ユーザーがその位置を見ることはまずありません。まして、入力を中断し、手の動きを変えて単語を選択しようとは思わないものです。

個々の注視点 (網膜が静止した位置の記録) から、ユーザーはキーボードかテキスト フィールドのどちらかを見ていることがわかる。通常はこれら 2 つの間を見ることはない。このため、私たちの予測入力 UI はキャレットの近くに表示される。

さらに、時間が経つにつれて視点は変わり、視点が変わるにつれて入力速度が上がることがわかりました。これは、視線追跡調査の視点プロットに顕著に現れています。この傾向は、タブレットに慣れていない入力の遅いユーザーから、タブレットの使用経験の長い熟練した入力者まで、あらゆるユーザー層に共通していました。どの場合でも、最初はキーボードに多く注目し、速度も速くありません。だいたい 90 分から数日ほど時間が経つと、キーボードに注意が向けられることは極端に減り、テキスト フィールドに注目が集まるようになります。そして、1 分あたりに入力される単語数が大きく増加します。

ラボでの調査から、注視点は時間の経過と共に変わることがわかる。左側の画像はわずか数分後の入力者のようすを示し、右側の画像は約 90 分後の視点プロットを示す。注視点はテキスト フィールドに移動している。この入力者の入力速度は、セッション中に 2 倍に向上した。

さらなる微調整

最後に、Windows 8 Release Preview に搭載されている現在の英語 QWERTY レイアウトの画像を以下に紹介します。これは意図的に単純化され、余裕のある配置になっており、残っているキーにはそれぞれ明確な理由があります。どのキーにも個別の事情がありますが、特に興味深いものをいくつか見てみましょう。

• Backspace キーは、物理キーボードでもタッチ キーボードでも非常によく使われるために用意されています。これを削除したら、指が何度もキーを探してさまようことになりかねません。
• モード切り替えキーは、ビューや言語を切り替えたり、キーボードを非表示にしたりするために欠かせません。IME ユーザーにとっては、これが Windows IME に切り替える方法となります。Windows IME にも、タッチに最適化されたキーボード レイアウトが用意されています。
• Ctrl キーと右側および左側にある上向き矢印のキーは、テキストの編集操作のために用意されています。キーボードから手を離さなくても、入力カーソルを動かしたり、切り取り、コピー、貼り付けを行ったりできます。Ctrl キーは物理キーボードと同じように動作するので、サポートされているあらゆるキーの組み合わせを使うことができます。切り取り、コピー、貼り付け、太字など、テキスト編集に関係する操作にはラベルも表示されます。タッチ キーボードでは "コマンドの実行" は想定されていないため、Windows キーやファンクション キーはありません。これは、入力のしやすさに特化するという目標を重視した意図的な仕様です。
• Space キーは幅が広く、中央に配置されています。物理キーボードの調査では、Space キーは約 80% の確率で右側が押されるという結果が示されています (古いキーボードでは右側が摩耗していることがあります)。これはタッチ キーボードにも当てはまり、Space キーのサイズが十分でなければ入力し損なうことが多くなり、修正困難なミスも増えていきます。
• "絵文字" キーは、Unicode ベースの絵文字を完全にサポートする絵文字ビューに切り替えます。絵文字の利用は世界中に広がり、自分を表現する手段の 1 つとなっています。
• 標準キーボード レイアウトもオプションとして用意されており、キーボードのない PC で、ファンクション キーやその他の拡張キーを必要とするデスクトップ ソフトウェアを使う場合に役立つ可能性があります。これは設定チャームから、または [PC Settings] (PC 設定) の [General Settings] (全般設定) セクションで簡単に有効にすることができます。

キーボードを使っていく中で、操作を便利にするいくつかの追加機能にも気付いていただければ嬉しく思います。たとえば、&123 キーを長押しすると、もう一方の手で記号や数字を選択することができます。キーを離すと元のビューに戻ります。私たちのチームでは、これを "マルチタッチ ビューのプレビュー" と呼んでいます。

タッチ操作向けに最適化された現在のレイアウトには、一連の調査に基づいた各キーに関する決定が反映されている。

タッチ操作向けの入力エクスペリエンスは世界中の Windows でサポートされるので、ここでお話しした最適化は、Windows で対応しているすべての入力言語に適用されます。入力エクスペリエンスにはもう少し改良が加えられる予定ですが、私たちは、今までにお寄せいただいたご意見ご感想に心から感謝し、喜んで目を通しています。今後ともよろしくお願いいたします。

Kip Knox

ビデオをダウンロードしてお好みのメディア プレーヤーで再生することができます:
高画質 MP4 | 低画質 MP4

重要なファイルのバックアップは、だれもが行わなければならないことです。あらゆる機能が揃っている SkyDrive でも、やはりバックアップは必要です。Windows 8 では、バックアップの動作方法を見直し、すべてのファイルを復元するだけでなく、その日に編集した重要なファイルの以前のバージョンも復元するという長年の問題を解決することを目指しました。これを実現するため、Windows 8 にはファイル履歴と呼ばれる新機能が導入されています。今回の記事は、ストレージ チームのプログラム管理者である Bohdan Raciborski が執筆しました。-- Steven

注: コメントがトピックからずれているようです。コメントの質はコミュニティにふさわしい水準に保ち、現在のトピックに重点を置くようお願いいたします。

ファイル履歴とは

ファイル履歴は、ライブラリ、デスクトップ、お気に入り、連絡先の各フォルダーに保存された個人ファイルを継続的に保護するバックアップ アプリケーションです。ファイル システムを定期的に (既定では 1 時間おきに) スキャンして変更がないかを確認し、変更されたファイルを別の場所にコピーします。個人ファイルが変更されるたびに、ユーザーが選択した専用の外部デバイスにそのコピーが保存されます。時間の経過と共に、ファイル履歴によって、あらゆる個人ファイルに加えられた変更の完全な履歴が構築されていきます。

ファイル履歴は、ユーザーがファイルを保護する新しい方法として Windows 8 に導入された機能です。これは、Windows 7 に装備されていた Windows のバックアップと復元機能の後継となるものです。

従来のバックアップと復元と比較して、このアプローチにはどんな特徴があるのでしょうか。

残念ながら、バックアップはあまり人気のあるアプリケーションではありません。製品利用統計情報は、Windows のバックアップと復元を使っているコンシューマー PC は 5% 未満であることを示しており、使用されているすべてのサード パーティ ツールを合計しても、コンシューマー PC の半分近くはどこにもバックアップされていないことがはっきりしています。このため、ユーザーの個人データとデジタル メモリはかなり脆弱な状態にあると言えます。何らかのアクシデントによりデータ損失が生じる可能性があるためです。Microsoft は、Windows 8 で以下のことを積極的に達成しようとしています。

1. データ保護を簡単なものにしてだれでも有効にできるようにし、すべての Windows ユーザーが、個人ファイルが保護されていると実感できるようにする。
2. バックアップの設定と利用の複雑さをなくす。
3. バックアップを自動的に動作するサービスにして、ユーザー操作がなくてもユーザー ファイルの保護がバックグラウンドで十分に行われるようにする。
4. きわめてシンプルで魅力的な復元エクスペリエンスを実現し、個人ファイルのバージョンを簡単に検索、プレビュー、復元できるようにする。

私たちは、ファイル履歴の設計時、過去の教訓を用いて、PC ユーザーの変化するニーズに対処するための要件を追加しました。

• PC ユーザーの間では、かつてないほどモバイル化が進んでいます。これに対処するため、私たちは、電力状態が絶えず変わったり、ネットワークやデバイスへの接続と切断を繰り返すラップトップのサポートが強化されるように、ファイル履歴を最適化しました。
• PC ユーザーが作成するデータも多くなり、これまでよりもデータの重要性が高くなっています。このため、現在システム ドライブ上にあるデータだけでなく、これまで行った作業内容や過去に作成したデータも保護します。

特定時点 (PiT: Point-in-Time) のバージョンのファイルが必要なときや、フォルダー全体が必要なときでも、すばやく見つけて復元することができます。復元アプリケーションは、ファイルの参照、検索、プレビュー、および復元用に最適化された魅力的なエクスペリエンスとなるように設計されました。

セットアップ

ファイル履歴を使ってファイルをバックアップし始めるには、最初にファイルの保存先のドライブを設定する必要があります。クラッシュや PC の他の問題からファイルを保護するには、外部ドライブやネットワーク上の場所を使うことをお勧めします。

ファイル履歴では、ライブラリ、連絡先、お気に入り、デスクトップにあるファイルのコピーのみが保存されます。他のフォルダーをバックアップする場合は、既存のライブラリのいずれかに追加するか、新しいライブラリを作成することができます。

ファイル履歴をセットアップするには

1. [File History] (ファイル履歴) コントロール パネル アプレットを開きます。
2. 外部ドライブを接続してページを更新し、[Turn on] (有効にする) をタップまたはクリックします。

ドライブの設定は自動再生から行うこともできます。ドライブを PC に接続し、次のような通知をタップまたはクリックします。

次に、[Configure this drive for backup] (バックアップ用にこのドライブを構成) をタップまたはクリックします。

実にシンプルです。この時点から、ファイル履歴によりライブラリ、お気に入り、デスクトップ、連絡先に変更がないか 1 時間おきにチェックされます。変更されたファイルが見つかった場合、ファイル履歴ドライブに自動的にコピーされます。

ビデオをダウンロードしてお好みのメディア プレーヤーで再生することができます:
高画質 MP4 | 低画質 MP4

ファイルの復元

何らかの問題が発生して個人ファイルが失われた場合、復元アプリケーションを使って次のことをとても簡単に行うことができます。

• Windows エクスプローラーとよく似た方法で個人用のライブラリ、フォルダー、ファイルを参照する。
• キーワード、ファイル名、日付の範囲を使って特定のバージョンを検索する。
• 選択されたファイルのバージョンをプレビューする。
• 1 回のタップやクリックで、ファイルまたは一連のファイルを復元する。

復元アプリケーションは、ワイド スクリーン ディスプレイ向けに設計されており、ファイルのプレビューを表示することにより、他にはない便利な方法でファイルの特定のバージョンを見つけることができます。

他のバックアップ アプリケーションでは通常、特定の日付に作成されたバックアップ セットを選択する必要があります。その場合、特定のフォルダーを参照し、必要な 1 つのファイルを見つける必要があります。しかしその時点では、ファイルを開いたり、その内容をプレビューしたりして、該当するファイルかどうかを判断することは不可能です。ファイルを復元する必要があるのです。選んだバージョンが目的のものでなかった場合は、最初からやり直さなければなりません。

ファイル履歴では、Windows エクスプローラーから直接検索を始めることができます。特定の場所を参照し、エクスプローラーの [History] (履歴) ボタンをクリックまたはタップすると、選択されたライブラリ、フォルダー、または個々のファイルのすべてのバージョンを表示することができます。

たとえば、ピクチャ ライブラリを選択し、[History] (履歴) ボタンをクリックまたはタップするとします。

すると、このライブラリの全履歴が表示されます。

特定のファイルをクリックすると、選択された画像の全履歴を表示できます。

この例では、選択された画像には 4 つのバージョンがあります。[Previous] (前へ) ボタンや [Next] (次へ) ボタンをクリックしたり、画面をスワイプしたりすることで、目的のバージョンに簡単に移動することができます。目的のバージョンが見つかったら、[Restore] (復元) ボタンをクリックして元に戻すことができます。選択されたバージョンが元の場所に復元されます。

中断のない信頼できる保護機能

ファイル履歴では、これまでのバックアップ モデルとは異なるアプローチを使ってデータが保護されます。

最も重要なものだけを保護

ファイル履歴は、システム全体 (オペレーティング システム、アプリケーション、設定、ユーザー ファイル) を保護する代わりに、ユーザーの個人ファイルにのみ焦点を当てています。これこそが最も大切なものであり、アクシデントの際に取り戻すのが難しいものです。

最大限に高められたパフォーマンス

これまで、ほとんどのバックアップ アプリケーションはボリューム全体をスキャンするという強引な方法によって、ディレクトリまたはファイル内に変更がないかチェックしていました。このアプローチは、システムのパフォーマンスに大きな影響を与え、完了までに長時間かかることがありました。一方、ファイル履歴では NTFS 変更ジャーナルが活用されています。NTFS 変更ジャーナルには、NTFS ボリュームに保存されたあらゆるファイルに加えられた変更がすべて記録されます。ボリュームをスキャンする場合はディレクトリを開いて読み取る必要がありますが、ファイル履歴では NTFS 変更ジャーナルを開いて変更がないかすばやくスキャンされます。この情報に基づいて、変更されたためコピーする必要があるファイルのリストが作成されます。このプロセスは非常に高速で効率的にです。

ファイル履歴は、簡単に中断してすばやく再開できるように設計されています。このため、ファイル履歴では、システムがスリープ モードになったり、ユーザーがログオフしたり、システムがかなりビジーになってフォアグラウンド処理に多くの CPU サイクルが必要になったり、ネットワーク接続が失われたり混雑した場合でも、最初からやり直す必要なく処理を再開することができます。

また、ファイル履歴は、リソースが限られた小型のフォーム ファクターやタブレットを含む、どんな PC でも正常に機能するように設計されています。システム パフォーマンス、バッテリ寿命、エクスペリエンス全体への影響が最小限に抑えられるようにシステム リソースが使用されます。

1. ファイル履歴プロセスは、優先度が低い IO と優先度が低いメモリを使って、低い優先度で実行されます。

図 1: ワークロードの増加に対するファイル履歴の反応

図 2: 優先度が標準の I/O を使う他のプロセスが存在する場合のファイル履歴によるディスク使用率

1. ファイル履歴サービスがアイドル状態のときに使うワーキング セットは、平均 10 MB です。実行時に使うメモリはほとんどなく、短時間しか使いません。次のグラフは、ファイル履歴のサイクル間隔を 1 時間に設定してワークロードをシミュレーションして収集された 4 時間分のワーキング セット ヒストグラムを示しています。

図 3: バックアップ サイクルごとのワーキング セット サイズ (3 分おきにサンプリング)

1. 1 サイクル中にバックアップされるデータの量は抑制されます。
2. コンピューターがスリープ状態のときはすべてのアクティビティが中断されます。

ファイル履歴では、以下の点が考慮に入れられます。

• ユーザーが存在しているかどうか、つまり、ログオンしていてシステムをアクティブに使っているかどうか。
• コンピューターが AC 電源とバッテリーのどちらで動作しているか。
• 前回のバックアップ サイクルはいつ完了したか。
• 前回のサイクル移行いくつの変更が加えられたか。
• フォアグラウンド処理のアクティビティ。

これらのすべての要素が 10 秒ごとに再チェックされ、その情報に基づいてデータをバックアップする最適な方法が判断されます。これらのいずれかの条件が変化すると、クォータの増減やバックアップ サイクルの中断/終了がサービスによって決定されます。

モバイル ユーザー向けに最適化

ファイル履歴は、実行中、状態の変化に柔軟に対応します。たとえば、ノート PC のふたを閉めたり、外部ドライブを取り外したり、自宅を出て自宅のワイヤレス ネットワーク圏外にノート PC を持ち出したりした場合、ファイル履歴は適切なアクションを実行します。

• ふたを閉じる - PC がスリープ モードになると、ファイル履歴は電力モードの変化を検出し、その処理を中断します。
• ふたを開く - ファイル履歴は、システム全体のパフォーマンスに影響を与えずに (ゲーマーに対しても) ファイルを保護できるような優先度でその処理を再開します。さらに、"ふたを開いた" 後のアクティビティもすべて完了するのを待機して、スリープ状態から戻ってもシステムに影響が及ばないようにします。
• 専用のストレージ デバイスを取り外す - ファイル履歴は、ストレージ デバイスが存在しないことを検出し、システム ドライブ上にある変更されたファイルのバージョンのキャッシュを開始します。
• 専用のストレージ デバイスを再接続する - 次のサイクルで、ファイル履歴はストレージ デバイスが再接続されたことを検出し、ローカル キャッシュ上のすべてのバージョンを外部ドライブに移して、通常の処理を再開します。

簡単で安心

私たちは、1) ユーザーの個人ファイルを可能な限り保護する、2) 簡単さと安心感を提供する、という 2 つの目標を念頭に置いてファイル履歴を設計しました。

ファイル履歴を活用するには、簡単な決定をほんの少しだけ下す必要があります。ほとんどの場合、決定する必要があるのは、使用する外部ドライブだけです。残りは Windows によって自動的に決定されます。ファイル履歴の処理は透過的に行われ、Windows のユーザー エクスペリエンス、信頼性、パフォーマンスに影響を与えることはありません。

細かい制御

Windows 7 に付属する Windows のバックアップと復元を含むほとんどのバックアップ アプリケーションは、設定と使用に管理者権限が必要です。これは、標準ユーザーが設定やファイルの復元を毎回管理者に依頼したり、管理者から管理者権限を付与してもらう必要があることを意味します。ファイル履歴はそうではありません。ファイル履歴では、各ユーザーが細かく制御することができます。ファイル履歴を有効にするかどうか、いつ有効にするか、使用する外部ドライブをユーザーが決定できるようになりました。実際、各ユーザーはファイル履歴を保存する別の場所を選択することができます。また、管理者にファイルの復元を依頼する必要がありません。

上級ユーザーや経験豊富な PC ユーザーは、ファイル履歴の高度な機能を使って、以下のようにファイル履歴の処理の多くの側面を制御することができます。

• ファイルのコピーを保存する間隔: バックアップの間隔は、10 分～ 24 時間の間で変更できます。間隔を短くすると保護が強化されますが、ディスク領域の消費量が多くなります。

• 保存されたバージョンを保持する期間: 各バージョンは永続的に保存することも、1 か月間だけ保存することもできます。この設定は、ファイル履歴のドライブがすぐにいっぱいになってしまう場合に役立ちます。バージョンが保存される期間を短くすることで、このペースを遅くすることができます。

• ローカル キャッシュのサイズを変更する: ファイル履歴は、ファイル履歴の保存先ドライブを利用できないときにファイルのバージョンを保存するため、ローカル ドライブ上の小さい領域を使います。切断されている間、または長期間切断されたままの場合に、ファイルのバージョンをたくさん作成した場合、すべてのバージョンを保持するため、ローカル ドライブ上に多くの領域を確保する必要が生じることがあります。ローカル キャッシュに保存されたバージョンは、外部ドライブが再び利用可能になったときに外部ドライブに移される点に注意してください。

• バックアップする必要のないフォルダーを除外する: フォルダーによっては、簡単に取り戻すことができるため保護する必要がない大きいファイル (ダウンロードされた高解像度ムービーやポッドキャストなど) を含んでいることがあります。これらのファイルによって、ファイル履歴のドライブ容量がすぐにいっぱいになってしまう可能性があります。この設定を使うと、そのようなフォルダーを除外できます。

• ホーム ネットワーク上の他のホームグループ メンバーにドライブを勧める: この設定については、以下の「ファイル履歴とホームグループ」セクションで詳しく説明します。

• ファイル履歴のイベント ログにアクセスする: イベント ログには、イベントの記録が含まれており、ファイル履歴をトラブルシューティングするときに役立つことがあります。特に、何らかの理由でファイル履歴がアクセスできないファイルを特定する場合に役立つ可能性があります。

詳細設定には、[File History] (ファイル履歴) コントロール パネル アプレットからアクセスできます。

フォルダーを除外するには、[Exclude folders] (除外するフォルダー) を選択します。次に、[Add] (追加) ボタンをクリックし、除外するフォルダーを参照して選択します。このフォルダー内のファイルは、次のバックアップ サイクル以降バックアップされなくなります。この一覧からフォルダーを削除すれば、バックアップを再開することができます。

その他の詳細設定は、[Advanced Settings] (詳細設定) ページで設定できます。

ファイル履歴では、Windows 8 で導入された新しいストレージ機能もサポートされます。バックアップするデータがたくさんあるユーザーは、記憶域スペースを使い、既製の USB ドライブを利用した回復力のある記憶域プールを作成することができます。プールがいっぱいになると、他のドライブや追加ストレージ容量をプールに簡単に追加することができます。記憶域スペースの詳細については、このブログ記事をご覧ください。

ファイル履歴では、保存元ドライブと保存先ドライブの両方で BitLocker がシームレスにサポートされるため、BitLocker を使って個人ファイルの内容を保護するユーザーもファイル履歴を使うことができます。

ファイル履歴は、一般ユーザーだけでなく企業ユーザーも使えるように設計されました。場合によっては、ファイル履歴が企業ポリシー (保持ポリシーなど) に違反することがあります。そのような違反を防ぐため、企業の IT 管理者が管理対象クライアント PC でファイル履歴を無効にすることができるグループ ポリシーを追加しました。

ファイル履歴のポリシー設定は、グループ ポリシー オブジェクト エディターの [Computer Configuration] (コンピューターの構成)、[Administrative Templates] (管理用テンプレート)、[Windows Components] (Windows コンポーネント)、[File History] (ファイル履歴) の下にあります。

最小限のセットアップ

ファイル履歴は Windows の一部であるため、追加のソフトウェアをインストールする必要がありません。ただし、ファイル履歴は有効にする必要がありますが、通常は 1 回のクリックだけで有効にできます。

前に述べたとおり、ライブラリが保護されるようにするには、外部ドライブを選択するか、ネットワークの場所を選択する必要があります。ファイル履歴は、そのデバイスにファイルの各バージョンを保存します。

外部ドライブが利用可能な場合、ファイル履歴ではそのドライブが自動的に選択されます。複数のドライブが利用可能な場合は、空き容量が最も多いドライブが選択されます。

スケジュール不要

ファイル履歴は、1 時間に 1 回起動し、変更された個人ファイルがないか探します。変更されたすべてのファイルのバージョンが、専用のストレージ デバイスに複製されます。このアプローチにより、スケジュールを設定する必要がなくなるため、コンピューターは長時間アイドル状態のままになります。間隔が 1 時間の場合、保護レベルと、ファイル バージョンにより消費されるストレージ スペースの大きさのバランスが適度に保たれます。上級ユーザーは、この間隔を 10 分～ 1 日の間で変更し、保護レベルを上げたり、ストレージの消費量を減らしたりすることができます。

メンテナンス不要

ファイル履歴はバックグラウンドで自動的に実行され、継続的なメンテナンスは必要ありません。ユーザーの操作が必要になるのは、外部ドライブがいっぱいになったときだけです。このとき、ドライブを大きいドライブと交換するか、ファイル履歴によってファイル バージョンを保持する期間の設定を変更するかがたずねられます。既定では、ユーザーの個人ファイルのバージョンは永続的に保持されますが、ストレージに問題がある場合は、必要に合わせて期間を短くすることができます。

ファイル履歴とホームグループ

ファイル履歴は、1 人のユーザーがホーム ネットワークのすべてのメンバーのバックアップを簡単に設定できるように、ホームグループとも統合されています。そのしくみは次のとおりです。

1. Jane は、家族全員の個人データが自動的に保護されるようにしたいと思っています。彼女は、ファイル履歴でこれを行うことができると知っています。
2. Jane は、家族のホーム ネットワークでホームグループを作成します。
3. Jane は、大きい外部ドライブが接続されたコンピューターでファイル履歴を有効にします。
4. ファイル履歴のコントロール パネルがホームグループを検出し、このバックアップ保存先を他のホームグループ メンバーに勧めるかどうかを Jane にたずねます。
5. Jane はこのオプションを選択し、ファイル履歴はホームグループを使ってすべてのホームグループ メンバーにこの推奨設定をブロードキャスト送信します。
6. 各ホームグループ メンバーは、推奨設定を受け入れることができます。受け入れた場合、そのメンバーのライブラリ、デスクトップ、お気に入り、連絡先が Jane のコンピューター上のネットワーク要求に自動的にバックアップされます。

ファイル履歴と SkyDrive

ファイル履歴では、クラウドへのファイルのバックアップは行われません。クラウドは、外出先でアクセスするファイルを保存したり、他のユーザーとファイルを共有したりするのに適していますが、数テラバイトのデータをクラウドにバックアップするには、専門のサービスが必要です。現在、多くのクラウド サービスでローカル同期がサポートされており、クラウド内のデータがローカル ファイル システムでミラーリングされます。同期ソリューションでは、その性質からして、変更が直ちにすべての場所にコピーされます。つまり、ファイルを間違って削除したり、うっかり変更または破損した場合でも同期されてしまいます。この問題に対処するには、同期サービスと、ファイル履歴などの特定時点 (PiT) のバックアップ ソリューションを組み合わせて利用するのが最適です。

「アプリ、ファイル、PC、デバイスをクラウドとつなぐ SkyDrive と Windows 8 」というブログ記事では、SkyDrive が Windows エクスプローラーおよびファイル システムとどのように統合されるかについて説明しました。ファイル履歴ではその統合が活用されています。SkyDrive がファイル システムに同期されている場合、ファイル履歴は SkyDrive フォルダーに保存されたファイルを自動的に保護し始めます。これは、ローカル バックアップに、いつでもどこからでもアクセスできる信頼性を加えた良い例です。SkyDrive 内のファイルに PC、携帯電話、Web からアクセスすることができるだけでなく、ファイル履歴によってローカル バックアップがすばやく作成され、それらのファイルのすべてのバージョンにすぐにアクセスすることもできます。

システム全体のバックアップ

通常、システム全体のバックアップは、PC が盗難に遭ったときや紛失したとき、内蔵ハード ドライブが動作を停止したときなど、システム全体の損失から PC を保護するために利用されます。私たちのリサーチによると、オペレーティング システム、アプリケーション、設定の損失を心配しているユーザーはごく少数のようです。むしろ、個人ファイルの損失の方を心配しています。これらの理由のため、ファイル履歴は特にユーザーの個人ファイルを保護するように設計されました。

ファイル履歴には、システム全体のバックアップを行う機能はありませんが、システム全体のバックアップが必要なユーザーのために、優れた妥協案が用意されています。Windows 8 に導入された他の機能と同時に使うことで、そのような災難から保護することができます。

災難に備えるためには、次のような戦略をお勧めします。

1. PC をリフレッシュまたは復元する必要が生じたときに使う回復ドライブを作成します。詳細については、このブログ記事をご覧ください。
2. Microsoft アカウントに接続します。
3. 設定が同期されるように PC を構成します。
4. ストアからアプリを読み込みます。
5. ファイル履歴を有効にします。

PC を交換したときや、再インストールが必要になったときは、次のようにします。

1. 回復ドライブを使ってオペレーティング システムを復元します。
2. Microsoft アカウントに接続します。
3. 設定が同期されるように PC を構成します。これにより、設定が元に戻ります。
4. ストアにアクセスし、Windows ストアのアプリを再インストールします。
5. 従来のアプリを再インストールします。
6. 以前使っていたファイル履歴のドライブを接続し、すべての内容を復元します。これにより、個人ファイルが復元されます。

ファイルや画像の復元より多くの手順が必要になることがありますが、次のような明らかなメリットがあります。

• システムに存在していた "必要以上の" ソフトウェアや設定を復元することがありません。
• 以前に存在していた問題の原因を復元してしまう (または、別のハードウェアに復元する場合に新しい問題が発生する) ことがありません。
• システムの誤動作または障害の原因となっていた設定を復元してしまうことがありません。

システム全体のバックアップが必要なユーザーは、これまでどおり Windows バックアップを使ってシステム イメージを作成することができます。

要件

ファイル履歴を使うための要件は次のとおりです。

• Windows 8 クライアント オペレーティング システム
• すべてのユーザー ライブラリのコピーを保存するだけの十分なストレージ容量がある外部ストレージ デバイス (USB ドライブ、ネットワーク接続ストレージ デバイス、ホーム ネットワーク内の別の PC 上の共有など)

FAQ

Windows 7 から Windows 8 にアップグレードするとどうなりますか?
Windows 7 バックアップがアクティブであった場合 (つまり、スケジュールされていて、スケジュールがアクティブであった場合)、アップグレード後もスケジュールどおり実行され続けます。ファイル履歴は既定で無効になり、Windows 7 バックアップのスケジュールがアクティブである限りユーザーはファイル履歴を有効にすることができません。有効にするには、まず Windows 7 バックアップのスケジュールを無効にする必要があります。

Windows 7 ユーザーはファイル履歴を使うことができますか?
Windows 7 ユーザーは、ファイル履歴を使うことができません。ただし、Windows エクスプローラーでボリュームを参照し、特定のファイルを選択することで、ファイル履歴で使用されているドライブからファイルを復元することができます。ファイル履歴のドライブ上にあるファイルは、同じ相対的な場所に保存されており、同じ名前が使用されています。特定のバージョンは、ファイル名に付いたタイムスタンプにより見分けることができます。

ファイル履歴では、オペレーティング システムとアプリケーションは保護されますか?
ファイル履歴では、ユーザーのライブラリ、デスクトップ、お気に入り、連絡先のみが保護されます。オペレーティング システム ファイル、アプリケーション、設定などの他のファイルはバックアップされません。

ファイル履歴をクラウド ストレージで使うことはできますか?
いいえ。ファイル履歴は、特に一般ユーザー用に設計されており、このリリースではクラウド ストレージはサポートされていません。Windows 8 Server には、ファイルをクラウドにバックアップできるバックアップ機能が備わっています。この機能は、Windows のサーバー バージョンで利用でき、中小企業向けに設計されています。

ファイル履歴を企業ユーザーが使うことはできますか?
はい。ただし、企業ユーザーは、ファイル履歴が企業のセキュリティ、アクセス、および保持ポリシーに準拠しない可能性があることを認識する必要があります。このため、企業管理者が組織全体でこの機能を無効にできるグループ ポリシー設定を用意しています。

ファイル履歴ではファイル共有に保存されたファイルは保護されますか?
いいえ。ファイル履歴では、ローカル ドライブに保存されたファイルのみが保護されます。

• オフライン フォルダーやフォルダーのリダイレクトを使っている場合、フォルダー (マイ ドキュメントやマイ ピクチャなど) はネットワーク共有にリダイレクトされ、保護されません。
• ネットワークの場所をいずれかのライブラリに追加しても、その場所は保護されません。

最後に

ファイル履歴では、ライブラリ、デスクトップ、お気に入り、連絡先に保存された重要なすべてのファイルが自動的に保護されます。ファイル履歴を有効にすると、何もしなくてもデータが保護されます。ファイルが失われたり、画像の元のバージョンや履歴書の特定のバージョンが必要になったりした場合は、ファイルのすべてのバージョンを利用できます。ファイル履歴復元アプリケーションを使うと、すばやく簡単に復元することができます。

-- Bohdan Raciborski

皆さんの多くが RTM を楽しみにしておられることと思います。現在ストアでアプリに取り組んでいる開発者は特に興奮しておられるでしょう。既に何百ものアプリが Windows ストアにあり、さらに多くのアプリが作成途中です。最初の Developer Preview 以降、私たちは世界中のたくさんの開発者と密接に協力してきました。WinRT プラットフォームは、開発中フィードバックを基に急速に進化しています。私たちには、ストアの稼動を維持して何百万もの Preview ユーザーにアプリを提供できるようにすることと、次のビルドに向けて準備するという二重の課題があります。これは、API の変更または追加やツールの改良が生じた場合、アプリが変更されるため、最新の OS でアプリをテストして検証する必要があることを意味します。強力なパートナーシップをとおしてストアでのアプリの提供に全力で取り組んできた開発者に、私たちが最新のビルドを提供してきたのはこのためです。

この記事では、開発者が最新の API やツールを使ってアプリを最新の状態に保つことができるように、9 月以降私たちが行ってきた作業について説明します。一般提供が開始されるまでに新しいアプリの準備を確実に終えることができるように、この作業は Release Preview の後も行っています。この記事は、エコシステム アウトリーチ チームのリーダーである Dennis Flanagan が執筆しました。  --Steven

---

Windows 8 のリリースに近づくにつれて、Metro スタイル アプリのカタログは成長し続けています。これまで、ユーザーは Microsoft がダウンロード用ビルドに搭載したアプリと、Consumer Preview と Release Preview の両方の期間にストアで提供されたアプリを体験してきました。それらのアプリの多くは、没入型のタッチ主導 Metro スタイル エクスペリエンスの優れた例です。しかし、アプリが実行される Windows リリースと同様、それらのアプリは将来のアプリのプレビュー バージョンです。すべての Metro スタイル アプリの最終バージョンは、Windows 8 の一般提供が開始されてから入手可能になります。

昨年、私たちは Windows 8 プラットフォームおよびツールの初期バージョンをリリースすることで、開発者コミュニティとの密接な協力を始めました。エンジニアリング工程のもっと前の段階で開発者に参加してもらうことを決めていたため、開発者が Metro スタイル アプリ開発のスキルを築くようサポートし、フィードバックをとおしてプラットフォームに影響を与える機会を設けることができました。2011 年の 9 月以降、8 Developer Preview の複数のバージョンをリリースしてきました。それらのバージョンの中には、限られた開発者だけが利用できたバージョンもありましたが、広範に配布されたバージョンもありました。これらのすべてのリリースには、次のような同様の目標がありました。

• 新しい機能と API を提供する
• ツールを更新して Metro スタイル アプリ開発をシンプルにする
• パフォーマンスと信頼性を向上させる
• 開発者のフィードバックに応える

最初の Developer Preview バージョンは、アナハイムで開催された //build カンファレンス (英語) でリリースされました。開発者は、このバージョンによって Windows 8 のプラットフォーム、ツール、プログラミング モデルについて知ることができました。WinRT プラットフォームには新しい API が含まれていたため、私たちはカンファレンスを利用して、文字どおり何百もの技術セッションやサンプルを紹介して、開発者がプラットフォームの基本的な理解を得られるようにしました。 多くの開発者は、すぐに Metro スタイル アプリの構築に取りかかることができ、見事な初期の結果を生み出したため、私たちはプラットフォームやツールの改良方法に関する有用なフィードバックと提案を得ることができました。

私たちは、最初の Developer Preview ("DP1") はコードの初期バージョンであることを明らかにしました。Windows 8 を完成させるためにすべきことはたくさんありました。今年の 1 月と 2 月にリリースされた DP4 と DP5 は、Windows ストアでアプリケーションを最初に公開したいと思っている開発者を対象としていました。2012 年の 2 月に Consumer Preview をリリースしたときまでに、新しい WinRT API を 1,000 個近く追加し、開発者のフィードバックに基づいて何百もの他の API を変更しました。

//build から Consumer Preview までに加えられた変更の詳細については、アプリ開発者ブログの次の記事をご覧ください。

• //build/ 以降のアプリ開発者向けの変更点 (第 1 部)
• //build/ 以降のアプリ開発者向けの変更点 (第 2 部)

今年の 4 月と 5 月には DP6 と DP7 をリリースし、開発者が Release Preview 向けにアプリを準備できるようにしました。ただし、開発者コミュニティとの密接な協力により、私たちは開発者のフィードバックに基づいてプラットフォームを進化させ続けました。Release Preview の提供を開始したときまでに、334 以上の API を追加し、既存の API の変更を続けてフィードバックに対応しました。

開発者のフィードバックに基づいて Release Preview (RP) で加えた変更の例として、HTML ListView コントロール (WinJS) があります。これは、たくさんの開発者が難しいと感じていた分野のため、全面的に見直して作業しやすくし、もっと細かくパフォーマンスを調整できるようにしました。

さらに、Visual Studio のテンプレートなど、開発者リソースにもたくさんの改良を加えました。開発者が新しいプロジェクトを簡単に開始して、すばらしいアプリをかなり短期間で動作させることができるように、新しいテンプレートも追加しました。

デザイン ツールは、改良で焦点が当てられたもう 1 つの分野です。Metro は、デザインを前面に押し出したエクスペリエンスです。つまり、アプリのユーザー インターフェイスは、開発者がアプリを認識してもらい、差別化する主要な方法の 1 つです。私たちは、開発者が新しい Metro スタイル デザインの概念すべてをできるだけ簡単にアプリに組み込むことができるよう、力をそそぎました。

CP から RP までの変更点の全体的な概要については、「Consumer Preview 以降のアプリ開発者向けの変更点」をご覧ください。

次の主要なマイルストーンは、Release To Manufacturing (RTM) です。コードがこのマイルストーンに達すると、プラットフォームは一般提供 (GA) 向けに完成するため、開発者向けの暫定更新は加えられなくなります。

開発者は、RTM バージョンを入手した後もアプリの機能とパフォーマンスの向上を続けます。既に入手可能なアプリの中には、最終リリース バージョンをダウンロードしたとき外観や動作が異なるものが出てくるでしょう。まだストアでリリースされていない開発中のアプリもたくさんあります。それらの開発者の多くは、アプリに最後のしあげを加えるため RTM を待っています。

Windows 8 のリリースは、アプリ開発者にとって大きなマイルストーンとなりますが、実際には始まりにすぎません。組み込みの Windows ストアと更新メカニズムには、新しいアプリを広範囲に配布して、既にリリースされたアプリを継続的に改良する機会を開発者に与えるというすばらしい利点があります。アプリ開発者コミュニティが発展するにつれて、私たちはアプリ開発者がこの利点を活かして、アプリの定期的な更新プログラムを提供することを期待しています。

--Dennis