Building Windows 8

Windows 8 の一般提供に向け、最新の更新プログラムが公開されました

2012-10-11T18:15:00Z

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 の組み込みアプリを更新する

2012-10-11T00:46:00Z

いよいよ、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 ストアの更新プログラムの通知と、入手可能な更新プログラムの数がストアタイルに表示されます。都合のよいときに更新プログラムのインストールを簡単に選択できます。

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

	SkyDrive SkyDrive 内での検索フォルダーとファイルの名前の変更および移動新しい初期実行画面カスタムの並べ替え順序
	メール、カレンダー、People、メッセージング受信トレイのスレッドビュー IMAP アカウントのフルサポート招待メールの承認と拒否アカウントの画像のキャプチャと更新検索の強化メッセージングアプリ内での連絡先の検索
	フォト写真のトリミングと回転新しい自動キュレーションコラージュスライドショーピクチャライブラリでのネットワーク上 (Windows Home Server、ネットワーク共有、ホームグループ) の写真およびビデオの表示デスクトップから写真を開いているときでも、ピクチャライブラリで写真間を移動可能
	マップ概観図ビュー 3,000 以上の屋内施設地図ドライブナビゲーションのヒントナビゲーションとレイアウトの強化カスタマイズの強化 (カスタム画鋲やローミングオプションなど) Bing アプリおよびトラベルアプリとの統合
	Bing ローカルコンテンツおよび画像の豊富な検索結果 Bing による統合検索結果のズームを使用した関連クエリの表示ファイルピッカーを使用して Bing から画像を選択し、ロック画面や他のアプリで使用可能
	ファイナンス追加のニュースおよび雑誌コンテンツより多くの証券取引所に対応ファイナンスビデオ
	ニュース The New York Times や The Wall Street Journal などのパートナーによる追加のニュースコンテンツ記事リーダーの強化 (フォントのカスタマイズ、ズーム、改ページなど) オフライン閲覧エクスペリエンスの強化ニュースビデオスライドショー
	スポーツ追加のニュースおよび雑誌コンテンツスポーツビデオスライドショー MLS、J リーグ、ブラジルリーグなどの新しいサッカーリーグ
	トラベル追加のニュースおよび雑誌コンテンツフライト検索の強化と新しいフライト進行インジケーターホテル一覧ページの強化 360 度パノラマのサポート (ジャイロスコープのサポート)
	天気既定の場所の使いやすさの向上 1 時間ごとの天気予報 (最大 10 日間) 日中および夜間の最高気温/最低気温
	ビデオ自国通貨での購入クローズドキャプション俳優または監督による検索
	ミュージック音楽サービスの拡大豊富な "プレイビュー" エクスペリエンス SmartDJ による多くの音楽の発見
	ゲームエキサイティングな新しいゲームゲーム内購入招待とターン通知

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

-- Gabriel Aul

Windows RT PC の提供に向けたコラボレーション

2012-08-17T19:44:45Z

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 ワット時のバッテリ容量という違いがありました。

シナリオ	開発初期での計測範囲
HD ビデオ再生	8 ～ 13 時間 (シナリオ実行時)
接続維持スタンバイ	320 ～ 409 時間 (シナリオ実行時)

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

システムの仕様	測定範囲
重量 (g)	520 ～ 1200 g
長さ (mm)	263 ～ 298 mm
幅 (mm)	168.5 ～ 204 mm
高さ (mm)	8.35 ～ 15.6 mm

消費電力が抑えられたことに加え、これらのシングルチップソリューションによってパフォーマンスが最適化されたことが、高速で滑らかなタッチ操作につながりました。一般提供時にパートナー各社が提供する 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

シンプルになった Windows 8 の印刷機能

2012-08-03T20:30:00Z

オンラインリソースを読み、処理することが増えているとはいえ、印刷は 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 Vista	4200	55-60%	768 MB
Windows 7	2100	60-65%	446 MB
Windows 8	2500	リリース時は 70%、80% まで拡大	184 MB

これは、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 リリース - 2012 年 8 月 1 日

2012-08-02T20:24:00Z

本日 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 のグラフィックス

2012-07-31T22:40:00Z

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 点を主要な目標として設定しました。

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

それぞれの目標は 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 のようなメインストリームアプリでのコンテンツの描画方法には、いくつかの大きな違いがあります。例として、下のゲームの動画を考えてみましょう。このようなゲームでは、シーン全体が次々と変わります。"カメラ" が車の周辺を移動するのに伴い、空では雲が動き、エンジンからは煙が舞い上がります。魅力的で本物らしいエクスペリエンスを実現するためには、アプリでフレームごとにシーン全体を再描画する必要があります。

お使いのブラウザーでは HTML5 ビデオがサポートされていません。
ビデオをダウンロードしてお好みのメディアプレーヤーで再生することができます:
高画質 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 ビットの精度で実行すれば十分です。精度を下げても画質には影響しません。それでいて電力消費は抑えられます。

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

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

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

- Rob Copeland

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

フィードバックを基にタッチ操作でナレーターをさらに使いやすく

2012-07-27T18:57:00Z

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 で利用することができる、機能強化の一部をご紹介したいと思います。

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

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

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

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

音声による合図

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

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

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

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

対話式操作を簡単にする

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

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

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

タッチジェスチャ	コマンド
タップまたはドラッグ	指の下にある項目の読み上げ
ダブルタップまたは 1 本目の指で長押しし、2 本目の指で任意の場所をタップ	メインの操作を実行
トリプルタップまたは 1 本目の指で長押しし、2 本目の指でダブルタップ	サブ操作を実行
左または右にフリック	前の項目または次の項目に移動
上または下にフリック	動作の大きさを変更
1 本目の指で長押しし、他の指で 2 本指のタップ	ドラッグまたはその他のキーオプションを開始
2 本指のタップ	読み上げの停止
2 本指のスワイプ	スクロール
3 本指のタップ	ナレーターの設定ウィンドウの表示/非表示
3 本指で上にスワイプ	現在のウィンドウの読み上げ
3 本指で下にスワイプ	現在の位置からテキストを読み上げ
3 本指で左または右にスワイプ	前後にタブ移動
4 本指のタップ	現在の項目のコマンドを表示
4 本指のダブルタップ	検索モードの切り替え
4 本指のトリプルタップ	ナレーターのコマンド一覧を表示
4 本指で上または下にスワイプ	セマンティックズームの有効化/無効化 (セマンティックズームを使うと、より多くの領域が表示されてコンテンツを俯瞰できます)

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

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

Windows 8 のタッチキーボードのデザイン

2012-07-26T19:32:00Z

初期のタブレット 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 とおりがあることがわかりました。

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

タブレットと共に "生活" するユーザーを対象とした調査から、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 をタッチした場合は、その入力がユーザーの意図として尊重されます。このような処理がすべて入力中に行われるので、正しい文字が入力フィールドに出力され、それ以上の修正は不要になります。これが最適に機能しているときは、調整を意識することもなく、自信を持ってガラス面で入力を続けることができます。

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

入力に最適化

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

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

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

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

数字

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

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

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

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

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

数字の配置は、最上段を 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 キーを長押しすると、もう一方の手で記号や数字を選択することができます。キーを離すと元のビューに戻ります。私たちのチームでは、これを "マルチタッチビューのプレビュー" と呼んでいます。

モードの切り替え" src="http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/6710.Touch_2D00_optimized_2D00_keyboard_2D00_layout_5F00_thumb_5F00_3E70102A.png" border="0" />

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

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

Kip Knox

ファイル履歴を使ってユーザーファイルを保護する

2012-07-17T22:47:00Z

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

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

ファイル履歴とは

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

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

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

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

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

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

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

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

セットアップ

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

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

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

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

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

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

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

ファイルの復元

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ユーザーが存在しているかどうか、つまり、ログオンしていてシステムをアクティブに使っているかどうか。
コンピューターが 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 人のユーザーがホームネットワークのすべてのメンバーのバックアップを簡単に設定できるように、ホームグループとも統合されています。そのしくみは次のとおりです。

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

ファイル履歴と SkyDrive

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

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

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

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

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

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

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

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

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

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

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

システム全体のバックアップが必要なユーザーは、これまでどおり 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

Metro スタイルアプリを一般提供に備える

2012-07-06T23:24:00Z

皆さんの多くが 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 までに加えられた変更の詳細については、アプリ開発者ブログの次の記事をご覧ください。

今年の 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

Windows 8 用フォトアプリの紹介

2012-07-02T18:40:00Z

Windows 8 の新しいアプリを紹介する一連の記事の結びとして、この記事では新しいフォトアプリについて紹介します。Metro スタイルデザインの原則に従ったこのフォトアプリは、さまざまな異なるソースの写真を 1 か所に集約して、それらを表示、共有できるように設計されています。今回の記事は、Windows Live チームのグループプログラムマネージャーである Brad Weed が執筆しました。 --Steven

私たちが撮影した写真はさまざまな場所に格納されることになります。PC はもちろん、Flickr や Facebook などの写真共有サービス、携帯電話もよく使用されるはずです。そして、そうした写真のほとんどがそこに格納されたままではないでしょうか。写真を保存し共有するための方法と場所はこれまで変化し続けてきましたが、撮影する写真が増え、撮影可能なデバイスが多彩になり、共有する場所と相手が広がるにつれて、これからも変化し続けるでしょう。私たちに必要なのは、すべての写真を集めて、思い出を追体験し、楽しさを共有し、写真を使ったあれこれに集中できる場所だと思います。

すべての思い出を 1 か所に

Windows 8 Consumer Preview で公開されたフォトアプリのアプリプレビューでは、撮影した写真を今まで以上に楽しむことができる新たな方法を提案しました。皆さんが自分の写真をすべて見るためには、文字どおり無数の場所を探す必要があります。このために私たちは、このような写真をすべて 1 か所に集約することにしました。Microsoft アカウントを Facebook や Flickr と連携させることで、Microsoft アカウントを使って Windows 8 にサインインするだけで、すべての写真とその思い出をたどることができるようになります。もちろんフォトアプリは SkyDrive との連携、Windows Phone での使用に最適化されているので、撮影したすべての写真は携帯電話から SkyDrive に自動送信できます。つまり Windows 8 のフォトアプリがあれば、あちこちから集める手間なく、自分の写真を携帯電話に表示することができます。携帯電話で写真を撮影した場合も、撮影とほとんど変わらない手軽さで PC に写真を表示できます。

ストーリーを語ろう

横長の画面に最適化された Windows 8 に合わせてフォトアプリも横長で設計されています。これは、ストーリーを語るのに最も適した表示形式です。

ストーリーライン表示では、そのまま見て楽しむために写真をいっぱいに拡大することも、ちょうど良い大きさに写真を縮小して一度にたくさん表示することもできます。多くの写真を同時に見る場合は、ピンチを使ってズームアウトすると、写真のコレクションをサムネイル表示できます。

また、サムネイル表示では、すべての写真を正方形のサムネイルにトリミングして終わりというわけではありません。サムネイルは、元の写真の向きがすぐにわかるように表示されます。

もちろん、1 枚の写真を最も綺麗に表示したい場合は、景色の隅々まで見えるよう最大化します。手が触れそうなほど自然な表示です。ここから写真を 1 枚ずつ表示させていくことも可能です。

スワイプを使って写真を 1 枚ずつ、または数枚ずつ表示させるのが面倒な場合は、スライドショーを開始して、何もせずゆっくり鑑賞しましょう。さらに Windows 8 のデバイスチャームを使えば、TV や Windows 認定を取得したリモート再生対応デバイスにスライドショーを再生できます。もちろん映像にも対応しているので、最新のムービーメーカーで作った作品を同じように再生することができます。

Windows 8 Release Preview における強化点

あらゆるデバイスの写真を 1 か所に

私たちは Consumer Preview 以来皆さんから寄せられたご意見を検討し、精力的に改善を行ってきました。多くの方から聞かれたのは、写真の多くは Web サービス上ではなく家庭の PC にあるというご意見でした。PC 自体も、思い立ってすぐに使えるような場所や、夕食に呼んだ友人にモニターを見せながら説明してあげられるような場所にはないことが多いようです。このため私たちは、SkyDrive 担当のスタッフと連携して、このような使い方をもっと簡単にすることにしました。現在は SkyDrive デスクトップアプリをインストールすると、すべての写真を SkyDrive に自動送信/自動保存することを選択できます。フォトアプリには、SkyDrive デスクトップアプリがインストールされたすべての PC が表示されます。つまり、写真が格納されているすべての PC 上で SkyDrive デスクトップアプリを実行するだけで、フォトアプリによってそれぞれの PC から昔の写真が補完され、最近の写真と昔の写真を共存させられるようになります。これで、持っていたことを忘れてしまっていたような写真を再発見できます。

インポート

Windows 8 PC にすべての写真を集約する場合のために、フォトアプリにインポート機能も追加されました。

カメラを PC につないだ後は、インポート手段としてフォトアプリを選択すれば、後は何もする必要はありません。追加のケーブルも必要なく、写真の品質が低下することもありません。写真をインポートした後に整理する時間がなくても心配ありません。すべての写真は常に日付順で表示できるので、大量の写真コレクションを簡単に見ていくことができます。

新しいホーム画面

フォトアプリになくてはならないものは写真です。このため私たちは、アプリのホーム画面の背景として、画面いっぱいに表示される写真を用意しました。フォトアプリを最初に開いたときに表示される美しい写真がそれです。もちろんこの写真は自分の好きなものに変えることができます。お気に入りの 1 枚を選んで適用すれば、皆さんの PC は、"パーソナルコンピューター" にもっと近いものになります。

思い出を共有しよう

フォトアプリが提供する便利で美しい表示のすべては、写真を共有または印刷する場合に特に役立ちます。Windows 8 のロック画面用にお気に入りの写真を選ぶ場合も、とっておきの写真を共有チャームを使って共有する場合も、Facebook、Flickr、SkyDrive、または SkyDrive デスクトップアプリをインストール済みの PC から、フォトアプリをピッカーとして使って写真を選択できます。

写真を眺めているときに、関連する写真をまとめて共有したいと思いつくことがあります。フォトアプリでは、このような写真を簡単にまとめて選択して、共有チャームを使ってメールで共有できます。共有方法も、通常の添付ファイルはもちろん、スライドショーを SkyDrive 上にホストして、そのリンクを送信することもできます。ファイルサイズの制限を気にせず大量の写真を共有できる SkyDrive はとても便利です。

これまで写真のインポート、共有、保管といった操作では常に、多種多様な SD カード、ハードドライブ、インターネットサービスが必要でした。私たちがこうしたかつての状態に戻ってなお快適に感じるということはないでしょう。格納先があまりにも多すぎて、あまりにも面倒です。フォトアプリがあれば、Windows Phone で最近撮影した写真も、初めて買ったデジタルカメラで初めて撮影した写真も、同じように表示することができます。私たちは日常生活で多くの写真と映像を記録しますが、その数は増えることはあっても減ることはありません。フォトアプリがあれば、どんな思い出も、手元に呼び出すことができます。

皆さんのご意見を引き続きお寄せください。まだまだ尽力できることはあると感じています。次回にお知らせするときまで、フォトアプリでゆっくり楽しみながら、思い出を再発見してみてください。

Brad Weed
Windows フォト/ビデオグループ担当プログラムマネージャー

Windows 8 のカレンダーアプリのデザイン

2012-06-25T18:06:00Z

この記事は、メールアプリと People アプリの記事に続くもので、カレンダーアプリについて詳しく説明します。私たちは、これらのアプリを統合し、ユーザーにとって欠かせないクラウドサービスに接続するシームレスなコミュニケーションスイートとすることに尽力してきました。この記事では、Windows 8 との統合について詳しく説明します。いくつかの機能は現在のプレビュー版で体験していただけますが、まだ開発中の機能もあります。背景情報として、デザインが決まるまでの経緯と繰り返しについても少しご紹介します。今回の記事は、Windows Live チームのリードプログラムマネージャーである Colin Anthony が執筆しました。-- Steven

私たちが Windows 8 のカレンダーアプリのデザインに着手したとき、アプリの方向性には無限の可能性がありました。一般に使われているカレンダーの長い歴史と Windows の幅広いユーザー層を考えて、私たちは自らに問いかけました。優れたカレンダーエクスペリエンスに欠かせない要素とは何でしょうか。そして、豊富な Windows 8 の機能を活かしてそれを実現するにはどうすればよいでしょうか。

優れたカレンダーには、本質的に次のような機能が求められます。

日々の予定を明確に示す。プライベート、仕事、学校で何があるか、毎日の予定をはっきりと確認できる必要があります。
過去や未来を簡単に参照できる。過去や未来の日付にすばやく効率的に移動できる必要があります。予定を開く操作も自然でなければなりません。
新しいアイテムを簡単に追加できる。日々の暮らしの中では次々と新しいことが起こります。優れたカレンダーでは、新しい予定を立てるのも簡単でなければなりません。
時間どおりに行動できる。よく練られた計画も、遅刻したら台無しになってしまいます。
さまざまな状況に柔軟に対応する。多忙なときはスケジュールも複雑になります。カレンダーは、ニーズの変化に柔軟に対応できなければなりません。

日々の予定を明確に示す

カレンダーの最も重要な機能の 1 つは、"今日は何があるか" と "次に何があるか" という質問に答えることです。カレンダーアプリをデザインするうえで、私たちはこの答えをはっきりと提示し、関係のない要素を取り除くことに力を注ぎました。デジタルカレンダーの持つさまざまな可能性を考えると、この方針を貫くことは実際にはなかなか困難です。飾りや追加機能を搭載したいという強い衝動を抑えなければなりません。同時に、この方向性は紙のカレンダーが得意とする分野でもあります。紙のカレンダーは日付のますを提供するだけですが、そこに書き込まれた情報をひとめで見ることができます。

このような考察に加え、優れた Metro スタイルアプリ (英語) とはどのようなものかという明確な原則を鑑みて、私たちは、カレンダーのわかりやすさを追求することが重要だと結論付けました。カレンダーアプリでは、カレンダーとユーザーのコンテンツが中心となり、他の何よりも重点が置かれます。

余分なものが排除されたカレンダー - ユーザーの予定が中心になる

見やすいカレンダーが特に真価を発揮するのは、あらゆる情報が取り込まれた場合でしょう。仕事の予定を管理する場合でも、家族行事を計画する場合でも、学校の時間割を作る場合でも、カレンダーアプリにすべての情報をまとめれば、自分の生活の全体像を見渡すことができます。

仕事とプライベートの予定を 1 つのビューで確認できる

これらのカレンダーをアプリでどのように表示するかは、ユーザーが細かく制御できます。たとえば、いずれかのカレンダーに特別な意味がある場合は、そのカレンダーの表示色を変えて目立たせることができます。お気に入りのソーシャルネットワークから取り込まれた誕生日が多すぎる場合は、それらのアイテムを非表示にして、他の情報をもっと見やすくすることもできます。

このようなカスタマイズ用のコントロールはすべて [Settings] (設定) にすっきりとまとめられているので、必要のないときに邪魔になることはありません。

使用頻度の低いカレンダーオプションを [Settings] (設定) にまとめることで、余分な情報がなくわかりやすい画面を実現している

過去や未来を簡単に参照できる

もう 1 つの重要な機能として、カレンダーでは時間を自由に移動できなければなりません。私たちにとって特に重要な目標は次のようなものでした。

シンプルな操作で時間を前後に移動できる
ビューの切り替えをわかりやすくする
登録済みの予定を簡単に開いて確認できる

前後の期間への移動

早い段階から明らかになっていた目標として、私たちは、前へ進むジェスチャで未来を表示し、後ろへ戻るジェスチャで過去を表示するシンプルなモデルを求めていました。つまり、時間軸を移動する直接的な方法が必要でした。ボタンをクリックしたり、他のコントロールを操作したりするのは望ましくありません。

しかし、このようなシンプルなデザインにさえも、1 回あたりに進めたり戻したりする移動量をどのくらいにするべきかという問題がありました。妥当な落としどころを決めるには、ユーザーエクスペリエンスの観点だけでなく、技術的な観点も考慮に入れる必要がありました。

たとえば、1 回のスワイプで数か月先へ移動するようにしたとします (月数はジェスチャのスピードに応じて変わ��ます)。これなら、時間的に大きく離れた時点にも自然に移動できる強力な方法になりそうです。ところが、移動先の時点を予測しにくいという問題がありました。つまり、6 月から 7 月へ移動しようとしたのに、すばやくスワイプしすぎて 8 月まで進んでしまうという状況が起こり得ます。これが頻繁に起きると、思いどおりに使えないという感想に行き着いてしまいます。

また、月の変わり目ははっきりしているので、正確さも重要です。6 月と 8 月の中間に移動するのでは意味がありません。この点は、写真の一覧が表示された 2 次元のグリッドをパンで移動する場合と対照的です。写真のグリッドでは、探している写真のある位置に到達できれば、"付近に移動" するだけで十分です。

以上のような落とし穴を回避するために、私たちは一定量だけ移動するアプローチを選びました。1 回スワイプするか、キーボードの PageDown キーを押すか、[Forward] (進む) ボタンを押すと、一度に 1 か月ずつ先へ進みます。操作の結果を予測しやすいので、使いこなすのも簡単です。6 月から 8 月に移動したい場合は、2 回クリックするか、2 回スワイプするだけです。実にシンプルです。意図した移動先を超えて行き過ぎてしまう心配はありません。

シンプルな移動方法は動作がすばやく、移動先も予測できる

ビューの切り替え

カレンダーアプリの使われ方を考えると、大部分のユーザーは、普段のスケジュールの量に応じて特定のビューを選び、ほとんどの場合はその同じビューを使い続ける傾向にあります。予定の少ないユーザーには月表示が好まれます。多忙なスケジュールのユーザーには日表示が好まれます。そこで私たちは、ビューの切り替え機能をトップレベルのコマンドとして常に表示するのではなく、アプリバーに配置することにしました。Windows 8 では、右クリックするか下端からスワイプするだけで簡単にアプリバーを表示できるので、必要時にはすぐにビューの切り替え機能にアクセスできます。必要のないときに邪魔になることもありません。

アプリバーを表示すれば、必要時に簡単にビューを切り替えることができる

個々の予定の表示

予定を開きやすくするというのも興味深い問題で、次の 2 点のバランスを取る必要があります。

各イベントを大きくすると (高さと幅を広げると)、マウスでも指でもターゲットを選びやすくなる。
予定を小さくすると、一度に表示できるコンテンツが増える。

私たちは、各ビューに表示されるコンテンツの量を減らすことなく、簡単にターゲットを操作できるようなソリューションを見つけなければなりませんでした。これは特に月表示で重要になります。月表示では、各日付の領域が一番小さい面積に制限されるためです。先ほどの 2 点を考慮に入れて、私たちは、予定のサイズが最も効果的なサイズになるようにデザインしました。マウスでもタッチでも 100% に近い正確さでターゲットを操作できる状態を保ちつつ、月表示では、だいたい 1 日あたり 2 件の予定 (大部分のユーザーの平均) を表示します。プライベート、仕事、学校でもっと多くの予定が入っているときは、週表示に切り替えれば、同程度の正確な操作を実現しながら、必要な予定をすべて表示することができます。

新しい予定を簡単に追加できる

日々の暮らしでは次々と新しい予定が生まれる可能性があるので、予定の作成は直接的で、いつでもすぐに行うことができるというのが理想です。紙のカレンダーを考えてみれば、非常に直接的であることがわかります。目的の日付を見つけ、その日付へ向かって手を伸ばし、書き込みます。紙のカレンダーはシンプルで純粋なデザインをしているため、この一連の操作は、深く考えることなくきわめて自然に行われます。同じように、Windows 8 のカレンダーでも、目的の日付や時刻をクリックまたはタップするだけで新しい予定を追加できます。

クリックして追加する操作は、紙にペンを当てる動作と似ている

グリッドで直接コマンドを受け付けるこのデザインでは、予定の追加という頻繁に行われる作業を、他のボタンを必要とせずに完了することができます。すべての操作はカレンダーのグリッド上で行われます。これは、クロムよりもコンテンツを重視するという Metro デザインの原則に適っています。また、単に優れた使用感というだけでなく、シンプルで直接的な作成方法という純粋なエクスペリエンスも実現されます。

時間どおりに行動できる

もちろん、ここまでのすべてが実現されても、予定の時間を守るために役立たなければカレンダーの価値はありません。この目標を達成するため、カレンダーアプリには、重要な予定を忘れないようにするのに役立つ一連の便利な機能が用意されています。

通知とアラーム

予定の詳細ページでは、アラームの時刻を好きなように設定できます。指定した時刻になると、簡単なポップアップ通知が表示されます。

予定が近づくと通知機能が知らせてくれる

通知によって実行中の作業が中断されることはありません。通知に対してなんらかの操作をする必要もありません。カレンダー通知では、Windows 8 の組み込みの通知システムが使われます。これは、次にどのような予定があるかを知らせるだけで画面から立ち去ります。

また、Windows Phone と同様に、今後の予定の情報はロック画面やスタート画面のタイルでも見ることができます。

カレンダーのスナップによる常時表示

特に忙しい日には、その日のスケジュール全体をいつでも確認できるようにしておきたいことがあります。スナップ機能を使えば、他のアプリを使いながらカレンダーを見ることができます。

スナップ表示というフォームファクターは表示幅が狭いので、カレンダーのデザインを決めるのは難しい問題でした。ビューによっては、日表示のように、狭いスペースにごく自然にフィットすることもあります。この場合は、2 日単位ではなく 1 日単位の表示にするだけでフィットさせることができます。全体的なビューモデルは変わりません。問題はあっさりと解決してしまいました。

ただし、週表示と月表示はもっと厄介です。週全体や月全体を狭い領域に表示するのは非常に難しく、個々の予定のタイトルを表示できる望みはありません。また、システムの予測可能性を維持したいので、特定のビュー (日表示) はスナップ時にも基本的に同じように見えるのに、別のビュー (月表示、週表示) は通常版と比べてまったく違って見えるという状況を避ける必要があります。

問題と目標が明らかになったところで、私たちはシンプルで一貫性のあるモデルをデザインし、どのビューも同じ 1 つのスナップ表示で表すことにしました。この単一のビューは、通常のビューからコンテキストと位置を引き継ぎます。つまり、通常のビューで水曜日を表示している場合は、スナップ表示にしても水曜日が表示されます。また、予定のわかりやすさとナビゲーションのしやすさも変わらないようにデザインされています。カレンダーのすべての予定がシンプルな一覧として表示されます。右または左へスワイプするかクリックすると、時間を前または後ろへ移動できます。

スナップ表示のカレンダーにより、予定の計画と Web の閲覧を同時に行うことができる

さまざまな状況に柔軟に対応する

最後に、私たちの選んだデザインが優れていれば、より多くのユーザーが、プライベートや仕事の予定を管理するためにカレンダーを使い始めてくれることと思います。それを考慮して、カレンダーは、使用頻度が増えるにつれてさまざま��状況に対応できるようにデザインされています。

週表示

多くの方が予想することと思いますが、大量の予定がある場合は週表示が便利です。週表示は、特定の週をわかりやすく表示するように工夫されています。

週表示では日曜日から土曜日までの概要を確認できる

2 日表示

仕事、プライベート、学校、またはそのすべてが特別に忙しくなる日もあります。そのような日に備えて、私たちは、より詳しく、より正確な表示を提供するデザインも用意したいと考えました。ただし、ズームすることでコンテンツを減らして "視野を限定する" ことは望ましくありません。そこで、適切なバランスを実現するものとして 2 日表示のカレンダーがデザインされました。

2 日表示は今日と明日の詳細を確認するのに最適

"今日" の時間管理を適切に行うためには、明日の予定を把握していなければならないことがよくあります。2 日表示はこのような場合に役立ちます。加えてこのビューでは、最近の主流であるワイド画面ディスプレイが有効に使われ、余ったスペースを埋めるためにクロムや余分な情報が追加されることはありません。他のビューと同じように、表示されるのはカレンダーグリッドとユーザーの予定だけです (それぞれの日付は独立してスクロールされ、隣の日付には影響しません。したがって、明日の最初の予定を表示したまま、今夜の情報を見ることができます)。

より詳しい予定の管理

最後になりますが、カレンダーは、自分に対する手軽なアラーム ("電話料金を支払うこと"、"正午に保護者と教師の面談" など) として使われることがよくあります。この場合は、既にお話ししたように、カレンダーの任意の場所をクリックするかタップして必要な情報を少し入力するだけです。

カレンダーは、このような一般的なシナリオだけでなく、ニーズの変化に合わせていろいろなことができるようにデザインされています。ふところの深さと高機能さは、デジタルカレンダーの大きな特長の 1 つです。

たとえば、この夏に家族旅行を予定しているとしましょう。この場合、カレンダーに旅行を追加できるだけでなく、飛行機の出発時刻、予約番号、1 日ごとの日程など、その旅行に関係するあらゆる情報を予定に直接追加できます。紙やメッセージに分散させずに、すべて同じ場所にまとめることができるのです。他の家族に予定を送信して、必要な情報を全員に持たせることもできます。予定の送信は、カレンダーから直接行うことができます。

別の例として、私の家族のカレンダーには土曜日に定期的な予定が登録されています。この予定には、毎週土曜日の掃除で各自が担当する場所が記載されています。同じことを紙のカレンダーで実現するのは面倒で、場合によっては掃除専用の特別なカレンダーが必要になってしまいます。しかし、カレンダーの予定ごとに用意される専用ページを使えば、このような高度な管理もアプリ内だけで実現することができます。

予定ページには管理に役立つオプションが用意されている

ぜひ Release Preview のカレンダーをお試しになり、気に入っていただければ嬉しく思います。Consumer Preview では、皆さんからたいへん貴重なフィードバックをお寄せいただきました。私たちはすべてのご意見にじっくりと目を通しています。ご協力ありがとうございました。Windows 8 の最終リリースに向けて、今後の改良にもどうぞご期待ください。

-- Colin

メールアプリを構築する

2012-06-22T21:23:00Z

Windows 8 Release Preview 以降、何十万人もの方がメールの "アプリプレビュー" を毎日使ってきました。それと同時に更新も加えられており、新しい Windows ストアではさらに更新が予定されています。この記事では、メールアプリの背景について調べ、特に Metro スタイルデザインの原則に関連するデザインと機能についてお話しします。これは、メールの機能や、まだ追加されていない機能を徹底的に扱ったリストではなく、主にデザインと Windows 8 との統合に注目しています。この記事は、Windows Live チームのリードプログラムマネージャーである Jeremy Epling が執筆しました。これは、新しいアプリに関する一連の記事の 2 番目の記事です。--Steven

私たちが Windows 8 の電子メールエクスペリエンスの計画を始めたとき、目標は Metro スタイルデザインの原則に溶け込むアプリを作成することでした。高速かつ滑らかであり、タッチやキーボード、マウスでうまく操作でき、コンテンツに集中できる必要がありました。また、適切なときに適切な機能を使うことができ、最新のデバイスにおける電子メールの期待に応える必要もありました。一から始めたので、電子メールアプリに不可欠な機能を進歩させることができただけでなく、新たな視点で機能をデザインし、Windows 8 だけが持つ特徴を活用することができました。

今日のユーザーが電子メールを使う方法

デザインプロセスの始めに、私たちは今日のユーザーが電子メールを使う方法について調査を実施しました。電子メールは数十年存在していますが、かなり変化しており、私たちの期待も変化しています。

複数の電子メールアカウントを持っていることがよくある。平均的なユーザーは 2 ～ 3 つの電子メールアカウントを持っています。1 つは仕事用、1 つは個人用、そしてもう 1 つのアカウントは主にメーリングリストやクーポン用だったり、出席しなくなった学校からもらったアカウントなど、あまり使わないアカウントだったりします。

たくさんの電子メールを受信する。私たちのデータは、電子メールのライトユーザーと考えられるユーザーは週に 180 以上のメッセージを受信し、電子メールのヘビーユーザーは週に 2100 以上のメッセージを受信することを示しています。これらの数は、ますます多くのサービスがオンラインに対応し、ニュースレター、クーポン、領収書、他の種類のメッセージを電子メール経由で提供するにつれて、増え続けています。すべての電子メールに簡単に目を通すことができるようにする必要があります。

フォルダーはそれほど頻繁に使用されない。これは、フォルダーを多用しているユーザーにとっては驚きかもしれません。多くの企業環境や、上級ユーザーの間ではかなりよく使用されているからです。ある企業では、ユーザーは最大 50 のフォルダーを使っていますが、Exchange や Hotmail を使うユーザーの大部分はもっと少ないフォルダーしか持っていません。メールの適切なバランスは、フォルダーを使いやすくすることであり、50 以上のフォルダーや深くネストした階層に合わせて最適化することではありませんでした。

電子メールはリアルタイムである。電子メールは、多くの場合すぐに返信を期待しない非同期通信として使用されますが、リアルタイムの返信がますます期待されるようになっています。新しいサービスにサインアップすると、すぐに電子メールが送信されると表示されることがよくあります。新しい電子メールが着信した瞬間に通知を受け取ることが期待され、多くのユーザーは 1 日中頻繁に電子メールをチェックしたり、すべてのメッセージを着信時に確認できるように 1 日中実行したままにしています。

ユーザーは携帯電話でも一貫したエクスペリエンスを期待している。多くのユーザーは、PC と同時に携帯電話も使っています。実際、携帯電話を使って (たくさんある作業のうち) メールのトリアージ、閲覧、整理を行っています。携帯電話と PC における電子メールの一貫した表示の重要性は、これまでより増しています。メールアプリに実装された Exchange Active Sync (英語) などの標準プロトコルの使用は、ますます重要になっています。特に、このプロトコルでは、メールだけでなく連絡先、予定表を同期できるためです (IMAP などの他のプロトコルも間もなくサポートされますのでご安心ください)。

ユーザーがメールアプリを使って電子メールの管理、メッセージの作成、最新情報の入手をどのように行うかについて私たちが考え始めたとき、このような傾向を指針として考慮に入れました。

電子メールを管理する

アカウントとフォルダー

Metro スタイルデザインの目標の 1 つは、アプリのコンテンツを目立たせ、あまり使わない UI コマンドやナビゲーションを目立たないようにすることでした。メールアプリで、電子メールの最も重要な側面に集中できるようにしたいと思いました。Windows 8 の 16:9 のアスペクト比により、毎日使うコンテンツの最も重要な部分 (アカウント、フォルダー、メッセージ、閲覧ウィンドウ) がすべてなじむようになりました。ビューを切り替えなくても、開いている感覚のまま、すべての電子メールをすばやく読む簡単な方法があります。これは、Consumer Preview で登場した方法からの変更点です (メッセージと閲覧ウィンドウだけ表示されていました)。私たちは、アカウントとフォルダーの切り替えが十分に高速かつ滑らかでないことに気付きました (皆さんのフィードバックのおかげでこの結論に達することができました)。フォルダーとアカウントは、表示が必要なコンテンツの主要な部分であるため、Release Preview では表示されるようにデザインを更新しました。

メールアプリの 3 ウィンドウデザイン

これらの両方の結論から、現在 Release Preview で見られるような 3 ウィンドウデザインとなりました。このデザインでは、さまざまなアカウントが表示されるため、1 タップだけでアカウントを切り替えることができます。各アカウントの未開封数により、そのアカウントにチェックしていない新着メールがあるかどうかが簡単にわかります。同じことがフォルダーにも当てはまります。ほとんどのユーザーは、使っているフォルダーの数がそれほど多くありませんが、多くのユーザーが電子メールでフォルダーを使っているため、簡単に切り替えることができるようにしました。常に表示されるフォルダーリストは、サーバールールを使って電子メールを特定のフォルダーに自動的にフィルターしているユーザーにとっては特に役立ちます。

コマンド

私たちは、ユーザーがまったく使わないコマンドに気を取られることがないように、アプリに常に表示される機能、つまりコマンドを決めることにたくさんの時間を費やしました。各ユーザーがメールを起動したときにほぼ毎回使うタスクのコマンド (メッセージの作成、返信、削除) を加えることにしました。返信コマンドはすべて機能が似ているため、1 つのトップレベルのコマンドにまとめられています。[削除] は隅にあり、電子メールを作成するときは [キャンセル] コマンドも並んで表示されます。

ユーザーによっては、よく電子メールの開封済み/未開封を変更したり、電子メールを移動したりしますが、大部分のユーザーはほとんど行わないタスクです。メールの削除、作成、返信は、これらのタスクよりはるかによく行われるタスクであるため、常に表示されるようにしました。他のコマンドには、画面の一番下にあるアプリバーからすぐにアクセスできます (Windows + Z キーを押す、画面の下から上にスワイプする、または右クリックしてアプリバーを呼び出す)。複数のメッセージを選択した場合は [開封済みにする] や [移動] をよく使うと考えられるため、アプリバーに自動的に表示されるようにしました。

複数のメッセージを選択するとアプリバーが自動的に表示される

メッセージリスト

Release Preview では、できるだけ多くのメッセージが表示されるようにメッセージリストも更新されたため、電子メールにすばやく目を通すことができます。メッセージリストは、アプリの一番上から一番下まで表示され、メッセージプレビューは表示されません。また、これまでより小さいフォントが使用されています。1366x768 の解像度では、14 通のメッセージを表示できます。Consumer Preview では 8.5 通でした。うまくタッチできる大きさを保ちながら、多くの上級ユーザーが期待する密度になったメッセージリストを作るには、微妙なバランスが必要でした。さらに、メッセージリストにはプロフィール画像も追加されたので、友人や家族など、最も大切なユーザーからのメッセージをすぐに見つけることができます。これによって、メッセージリストが生き生きとしたものになり、よりパーソナルなエクスペリエンスとなります。友人のプロフィール画像は、Microsoft アカウントと関連付けた各種ソーシャルネットワークから取得されます。

閲覧ウィンドウ

閲覧ウィンドウでは、すばやく滑らかにメッセージを切り替えることができるので、ページ全体を移動する必要がありません。閲覧ウィンドウは 640 ピクセル幅に合わせて最適化されているため、ニュースレター、領収書、他の商用メールにぴったり合い、水平スクロールバーが要りません。さらに、既定の閲覧フォントを使うときは 640 ピクセル幅がテキスト行を読むのに最適なので、目が疲れたり、場所を見失うことがないこともわかりました。電子メールを受信すると、可能であればテキスト行がこの最適な長さに調整されるようになっています。

大きなプロフィール画像が表示されるため、メッセージの送信者を簡単に確認できます。件名からはメッセージの背景がわかるため、件名行を太字にして閲覧ウィンドウで目立つようにしました。メッセージの送信者や他の受信者を、Microsoft アカウントに関連付けられたソーシャルネットワークでも知っている場合、名前をタップすると People アプリのプロファイルページを表示できます。そこでは、最新ステータスの確認や IM の送信などを行うことができます。

電子メールを作成する

電子メール作成時に表示される画面は、2 つのウィンドウが横に並んでおり、メッセージを作成するスペースが広くなっています。タッチキーボードがあることから縦方向に使えるスペースが小さくなるので、宛先、CC、他の情報を電子メール本文の上に置くのは適切ではありませんでした。コンテンツのスペースを増やすため、宛先行と CC 行を 1 か所にまとめ、件名と本文を別の場所に置きました。これにより、情報が論理的にまとめられることにもなります。メッセージの宛先に関連する情報がすべて 1 つのグループとしてまとめられ、コンテンツが別のグループにまとめられます。書式設定コマンドは既定で非表示になるため、電子メールを作成するスペースが広くなっています。

電子メールを作成する

書式設定は頻繁に使うものではありませんが、必要なときは重要なコマンドです。メッセージの書式設定を行いやすくするため、メールではメッセージウィンドウでテキストを選択すると書式設定コマンドが自動的に表示されるようになっています。書式設定を適用すると、コマンドが消えてスペースが広くなり、作成中の内容に集中することができます。目標は、適切なときに適切なコマンドを表示することです。テキストを選択すると、そのテキストをコピーしたり書式設定したりする可能性が高いと思われるため、それらのオプションが自動的に表示されます。Outlook で使用されていた書式設定キーボードショートカットの多くも使うことができます。

電子メールを作成するとき、テキストを選択するとキーボードの上に書式設定コマンドが自動的に表示される

Windows 8 向けの設計

すばらしい Metro スタイルアプリをデザインする際のもう 1 つのポイントは、Windows 8 独自の側面を活用することです。メールでは、オペレーティングシステムにしっかり統合することで、電子メールの共有、印刷、新着メールの確認を簡単に行うことができるようになっています。

スナップ

私はよく、メールを別のアプリ (またはデスクトップ) の端にスナップして、他の作業を行っているときに簡単にメールを操作できるようにしています。こうすると、新着メールにすぐに気付いて対応することができます。スナップされたメールウィンドウで直接削除、移動、返信を行うことができるので、行っていた作業にすぐに戻ることができます。Release Preview では、スナップ状態でアカウントとフォルダーを切り替えることもできるため、別のアプリを使っているときにフォルダーやアカウントを操作することができます。これらの更新により、メールのスナップされたビューを 1 日中表示したままにすることが簡単になりました。

これは、長い電子メールを作成していて、複数のアプリから内容をコピーして貼り付ける必要がある場合は本当に便利です。新しいメッセージの作成を開始して、メールを端にスナップしてから、画面のメイン部分で他のアプリに切り替えて必要な内容を取得し、メッセージに直接貼り付けることができます。

IE の端にスナップされたメール

印刷

印刷は、電子メールで受信したチケット、領収書、クーポンを印刷するために今でもよく必要となるため、すべての Windows ユーザーが必要とする機能です。Release Preview では、印刷する電子メールを選択し、デバイスチャームを開いて印刷に使うプリンターを選択するだけで印刷できます。

メールで印刷する

メールは、共有コントラクト (英語) と統合されているため、どのアプリからでもメールに簡単に共有することができます。ソーシャルネットワーク全体に内容を送信したくないことはよくあります。むしろ、リンク、写真、またはゲームスコアは何人かの友人だけに送信したいと思うでしょう。メールには、共有チャームを使って、ターゲットを絞ったプライベートな共有を他のアプリから行う優れた方法が用意されています。同じユーザーグループと何度も共有する場合、Windows にそのグループが記憶されるため、次回からは簡単に共有できるようになります。

IE から共有チャームを開くと、メールを使ってよく共有するユーザーのリストが表示される

メールでは、テキスト、リンク、画像の共有がサポートされます。アプリに公開 URL がある場合、メールではその Web ページから画像、タイトル、説明が自動的に取得されます。その後、メッセージを追加して友人に送信することができます。共有チャームからメールを使ったときの外観や動作は、メールアプリで新しいメッセージを作成するときと同じであるため、Ctrl + B キーを使って太字にするなど、すべての書式設定キーボードショートカットが機能します。

Web ページから共有すると、メールでプレビューを送信できる

ライブタイル

最新のデバイスには、常に最新の情報が表示されることが期待されます。メールタイルでは、最新 5 通の未開封および未表示のメッセージを回転することでこれが実現されます。この結果、前回電子メールをチェックしたとき以降、新着メッセージがあるかどうかを知ることができます。

任意の電子メールフォルダーまたはアカウントのセカンダリタイルを作成し、スタート画面にピン留めしてそのフォルダーまたはアカウントと同じように新着メールの最新情報をリアルタイムで確認することもできます。これは、サーバールールを使って電子メールを別のフォルダーに自動的に移動している場合は特に便利です。

たとえば、会社の Exchange アカウントと個人用の Hotmail アカウントのタイルが別々に表示されるように [スタート] をアレンジした場合、どちらのアカウントに新着メールがあるかが簡単にわかります。

どの電子メールアカウントまたはフォルダーでもタイルをスタート画面にピン留めできる

これらのセカンダリタイルをロック画面に配置して、デバイスにサインインしなくても、新着電子メールがどのフォルダーにあるかが簡単にわかるようにすることもできます。

Exchange と Hotmail の両方の新着メール数が表示されたロック画面

新着メールが到着したことをすぐに知るには、[設定]、[アカウント] の順に移動することで各アカウントの通知を有効にします。

新着電子メール通知

もちろん、これらはすべてカスタマイズできます。必要に応じて、タイルやロック画面に表示される情報の量を減らすことができます。ライブタイルは、ピン留めしたフォルダーまたはアカウントごとに無効にできます。通知は、設定チャームからアカウントごとに管理でき、いくつかのサイレントレベルを設定したスリープモードを追加することができます。

常に最新の情報

最新のデバイスには、常に最新の電子メール (他の情報も) が表示されることが期待されます。さらに、アプリには CPU 使用率やバッテリー寿命を考慮して動作することが期待されます。メールでは、Windows 8 に組み込まれたバックグラウンド処理 API を使うことでこのバランスを取っています。このため、メールアプリは中断することができますが、新しい電子メールを受信したとき (プッシュ) やタイマーが発動したとき (ポーリング) も電子メール同期エンジンが動作します。最小限の機能だけが実行されるように、電子メール同期エンジンは別個のプロセスとしてデザインされているため、最新の状態を保ちながらバッテリーが節約されます。これがメールアプリのタイルと通知の特徴となっています。

メールにはアカウント固有の設定があるため、デバイスのアカウントごとに最適な構成を選択することができます。既定では、すべてのアカウントが新着電子メールを "着信したときに" (プッシュ) ダウンロードしますが、15 分、30 分、1 時間おきに、または手動でダウンロードするように構成することもできます。

私たちは、高額請求 (英語) を回避したいと思っているので、すばらしいエクスペリエンスを実現しながら、必要最小限のデータを使うように努めています。管理外のデータの使用を避ける 1 つの方法として、既定では直近 2 週間分の電子メールのみダウンロードされるようにしました。ほとんどのユーザーがよく使うのは直近 2 週間の電子メールだけであることがわかったため、アカウントで明確に構成したのでなければ、数ギガバイトある電子メールアカウントのすべてのメッセージはダウンロードされないようになっています。さらに、これによりそもそもダウンロードが速くなりますので、すぐにメッセージの操作を始めることできます。

Exchange のメールの既定のアカウント設定

使ったデータに対して MB 単位に課金される従量制課金ネットワークを使っている場合、メールでは Windows 8 の新しい Networking API を使ってこれが検出され、各メッセージの本文の先頭 20 KB 分だけがダウンロードされて添付ファイルはダウンロードされません。大部分のメッセージは、これで全体がダウンロードされます。大きい電子メールの場合、1 タップだけでメッセージの残りの部分をダウンロードできます。Wi-Fi を使っている場合、既定でメッセージ全体がダウンロードされます。

今後の予定

電子メールは、日常生活の重要な部分です。私たちは、引き続きメールの改良を続け、多くの機能を追加していく予定です。今後、アプリと最初のプレビューリリースに対する反応をいただけることを願っています。ユーザーの皆さんが、使用状況に応じた最新の期待に応えるすばらしい電子メールアプリを望んでいると考えており、これは Windows 8 のメールアプリで実現されています。

皆さんからいただいた貴重なフィードバックに感謝しております。引き続きフィードバックをお待ちしております。

Jeremy Epling
リードプログラムマネージャー
Windows メール

People アプリ: Windows 8 向けのすべて揃ったクラウド対応のアドレス帳

2012-06-19T16:45:31Z

"連絡先" の管理は、多くの人にとってちょっとした課題となってきました。特に、連絡先を保存できる場所と、連絡先へのアクセスに使う PC やデバイスの数が増えたためです。簡単にローミングおよび接続できるクラウドに連絡先を保存することは 1 つの解決策です。Windows 8 と新しい People アプリでは、ユーザーが既に使っている他のサービスへの接続を選択できるようにすることで、クラウドストレージが 1 歩前進します。この結果、電子メールの連絡先と、ご利用のサービス/ソーシャルアカウントの連絡先が、Windows 8 の PC と携帯電話の間でローミングされる 1 つの場所にまとめられ、簡単にアクセスして利用することができます。

この記事では、Windows Live チームのグループプログラムマネージャーである Jeff Kunins が、People アプリについて詳しく説明します。これは、現在アプリプレビューにある新しいサービス接続型アプリに関する一連の記事の最初の記事です。 --Steven

最近のデバイスには、アドレス帳や連絡先リストが付いています。私たちがそれらのデバイスを使うにあたって、コミュニケーションを取ったり、共有したりする人たちがとても重要だからです。電子メール、携帯メール、音声通話、ビデオ通話、コミュニティの最新情報やコメントがありますが、これらは毎日使う携帯電話、PC、タブレットで行う、"人" が関係するアクティビティの一部��すぎません。私たちは、Windows 8 で、新たな種類のエクスペリエンスである People アプリによってこの基本的なニーズを満たすことを目指しました。

Windows 8 の People アプリは、かつてのフラットな連絡先リストの現代的な形です。このアプリは、新しいコミュニケーション手段として作られ、既に使っているクラウドサービスに接続されます。People アプリは、電子メールアカウントとソーシャルアカウントに接続し、すべての連絡先 (およびそのアカウントで管理されている他の情報) を 1 つの便利な場所にまとめます。Windows 8 Consumer Preview ユーザーは、既に何百万回も People アプリを使っており、何百万ものソーシャル通知をライブタイルで受け取っています。私たちは、早くから示してくださった熱意 (英語) を誇りに思っており、初期プレビューバージョンをどのように改良できるかに関する皆さんの有用なフィードバックに感謝しています。また、最新のソーシャルアドレス帳に対する私たちの見方や、私たちの見解が Windows 8 の People アプリの進化をどのように促しているかをもっとたくさん伝えたいと思いました。

Windows 8 や Windows Phone などの最新のデバイスには、次の 4 つの簡単な原則に沿って作成されたアドレス帳が必要です。

すべて揃った接続型 – 個人用の連絡先と仕事用の連絡先だけでなく、ソーシャルアクティビティや写真がすべてそこにあり、すぐに利用したり反応することができます。1 回のインポートにより情報を取得するのではなく、電子メールアカウントとソーシャルアカウントからデータが同期されます。アカウントごとに異なる連絡先情報がいくつあるとしても、1 人あたり 1 つのシンプルな連絡先カードにまとめられます。
Windows 8 向けの設計 – 最新のデバイスにおいて、アドレス帳は全体的なエクスペリエンスの中核的な部分であるため、システム全体を念頭に置いて設計することが重要です。People アプリは Metro スタイル設計の原則に従っているため高速かつ滑らかに動作し、共有コントラクトや Picker (ピッカー) コントラクトをとおして他のすべてのアプリと連動します。
クラウド対応 – 連絡先と設定は何もしなくてもバックアップされるため、新しいデバイス、あるいは Web からサインインすると "そのまま機能" します。連絡先をスタート画面にピン留めすると、新しい写真、コメント、ツイートに関するリアルタイムの通知がライブタイルに現れます。
自由な制御 – 自宅のネットワーク、職場のネットワーク、ソーシャルネットワークでだれと何を共有するかを決めることができます。もちろん、各ネットワークのポリシーや顧客のプライバシーに応じて、共有および接続される情報が決まります。

次のショートビデオは、People アプリにおけるこれらの原則を示しています。

すべて揃った接続型

友人に不要な招待メールを再度送らずに既に使っているサービスに接続する方法については、以前お話ししました。何年もの間、連絡先データを電子メールアカウントまたはソーシャルネットワークに取り込む主な方法の 1 つとして、連絡先を別のアカウントからインポートしていました (場合によっては、インポートしてから再度招待を送っていました)。これは、モバイルデバイスにも当てはまります。連絡先を古い携帯電話から新しい携帯電話に "移行" するのが面倒なためだけに、新しい携帯電話の購入を遅らせている人たちを何人もご存じかもしれません。

多くの人は、電子メールアカウントが同期されるスマートフォンによってこの問題を少なくとも部分的に解決してきました。しかし、すべての人が利用できる、すべての連絡先とアカウントに対応する 1 つの簡単な場所が必要です。

ですから、People アプリがこれを行うのです。このアプリは、Exchange ActiveSync に加えて、Facebook、Twitter、Linked などのパートナーにより提供されている安全な標準ベースの API (OAuth、REST など) を使って、連絡先リストのコピーをクラウドから同期します。追加した新しい友人の情報が常に最新に保たれるため (友人から削除した場合もそれが適用されます)、1 回のインポートの不安定さによる問題が生じることはありません。

Facebook、Twitter、Exchange などのアカウントに接続する

連絡先が People アプリに追加されると、きれいにカスタマイズされた画面で、ソーシャルアクティビティや写真を見てコメントを付けたり、連絡先の詳細を表示したり、自分が使っていて連絡先も使っているサービスをとおしてメッセージを送信したりすることができます。さまざまな連絡先やネットワークの "What’s new" (新着情報) の概要を参照しているのか、特定の連絡先だけを見ているのかにかかわらず、簡単に近況を確認して接続されたままでいることができます。

連絡先リストのメインビューの大きいタイルに親しい連絡先が表示される

Windows 8 の "セマンティックズーム" では、すばやくピンチして連絡先リストをナビゲーションできる

連絡先を 1 つ表示すると、その連絡先情報と近況が表示される

[What’s new] (新着情報) をタップすると、ソーシャルネットワークの概要をひとめで確認できる

ソーシャルの最新情報を 1 つ表示すると、すべてのコメントを表示し、コメントを追加することができる

People アプリなどの最新のアドレス帳が扱わなければならない 1 つの課題は、重複です。さまざまなアカウントで友人ができたり、ある人の情報を入手することはだれにでもよくあることです。たとえば、私の友人である Omar Shahine の連絡先は Exchange と Hotmail にありますし、Facebook では友人、LinkedIn では同僚です。もちろん、Twitter でも彼をフォローしています。

People アプリは、Windows Phone や Hotmail と同じように、これらの連絡先がすべて同じ人 (友人の Omar) であることを自動的に検出し、"リンクされた" 1 つの連絡先としてすべてのデータが 1 か所にまとめられ、1 つのタイルに表示されます。そして、とても重要な点として、これは基になっているどのソースデータにも干渉せずに行われます。

私たちは、これが自動的に "しっかり" 機能するように最善を尽くしていますが、完璧にはできないことを認識していますので、ユーザーが自分のリンクを編集し、追加したり削除したりできるようにしたいと思っています。Hotmail と Windows Phone では既に実現されていますが、Windows 8 のバージョンにも徐々に追加する予定です。

複数のアカウントを選択して、重複する連絡先をリンクすることで、その人に接続していなくても、アドレス帳に含まれるすべての人の連絡先カードを作成することができます。ですから、簡単な概要がひとめでわかり、よく行うタスク (電子メールの送信、チャットの開始、地図情報の表示、電話番号や住所の検索、最近のアクティビティの参照など) を 1 クリックで実行することができます。

Windows 8 向けの設計

私たちが従った 2 つ目の原則は、Windows 8 の機能を活用するようにアプリを設計することでした。他のシステムとは異なり、Windows 8 のアプリは、私たちがコントラクト (英語) と呼んでいる API をとおして、他のアプリや OS 自体に接続することができます。つまり、メールやメッセージングなどの組み込みアプリケーションだけでなく、Windows 8 デバイスにインストールした他のアプリも People の連絡先リストを活用することができます。

Metro スタイルのスタート画面の 1 つのハイライトは、アクティビティが表示されるすべてのタイルであり、関心を持ったアプリやコンテンツにワンタッチでア��セスすることができます。People アプリはセカンダリタイル機能に対応しているため、基になっているアプリの特定の部分にすぐにリンクされるタイルを追加することができます。ですから、私が TechMeme、Top Chef、妻、友人の Omar などの連絡先をスタート画面に追加すると、タップ 1 回で連絡先情報やアクティビティを表示することができ、1 回か数回タッチするだけでメールを送信したり、最新の写真を見たりすることができます。

Consumer Preview 以降の新しい点として、People アプリで共有コントラクト (英語) がサポートされるようになったため、Internet Explorer など、どの Windows 8 アプリからでも Facebook や Twitter に投稿できるようになったということもあります。ですから、アカウントを People アプリに接続すれば、何回かタッチするだけでお気に入りの最新記事を友人やフォロワーと共有することができます。

Windows 8 アプリ (IE など) は共有チャームを使って Facebook や Twitter に投稿できる

最後に、もう 1 つのすばらしい機能は People ピッカーコントラクトです。これを使うと、どの Windows 8 アプリでも、Web サイトからパッケージを送信したり、People アプリから連絡先をすばやく選択して友人のリストに電子メールを送信するなど、簡単なタスクのスピードがアップします。反応のないフルアクセス API とは異なり、システムが仲介する制御可能なユーザーエクスペリエンスが必ず発生します。

どのアプリでも People ピッカーを呼び出すことができるため、使う連絡先を選択できる

クラウド対応

これまで説明したどの機能も、アプリとデバイスがクラウドに対応していなければ不可能なため、さまざまなアカウントのデータを同期し、アプリ内で表示できるようになっています。しかし、すべてのデータと設定が "クライアント" アプリ自体によってのみ管理されている場合 (従来の携帯電話や電子メールアプリのように)、いくつかの問題が生じます。(1) 携帯電話などの 1 台のデバイスでこれをセットアップしても、自宅や職場で新しい PC を入手したらセットアップをやり直す必要があります。(2) 他の人のコンピューターで Web ブラウザーを使うときに、統一されたこのエクスペリエンスの恩恵を受けることができません。(3) Facebook や LinkedIn などのサービスで API が新しくなった場合、正しく機能するにはアプリの新しいバージョンにアップグレードしなければなりません。

私たちは、Microsoft アカウントとクラウドを使って設定を安全にキャッシュし、新しいデバイスに移行したり、Web から連絡先リストにアクセスしても、期待どおりに "そのまま機能する" ようにしてこれに対処しました。さらに、Facebook や Twitter などのネットワークへの API 呼び出しの多くをクラウドから行うようにし、ユーザーが新しいバージョンのアプリに更新しなくても、私たちがそれらの API の進化に合わせて調整できるようにしました。

クラウドの利点の良い例は、サインイン元のデバイスにかかわらず、People アプリが Facebook、Twitter、LinkedIn などの接続を記憶するということです。既に 5000 万人を超えるユーザーが、Windows 8、Windows Phone、Hotmail、Messenger、SkyDrive のソーシャル機能を使ってソーシャルネットワークを自分の Microsoft アカウントに接続しています。どのユーザーも、新しい Windows 8 PC に初めてサインインすると、すべて揃ったクラウド対応の接続型アドレス帳が People アプリに自動的に読み込まれます。

クラウド対応とは、デバイス上に連絡先リストの最新のコピーが常に維持されるだけでなく、People アプリのタイルとピン留めされた連絡先のタイルが、ソーシャルネットワークの最新の通知と共に自動的に表示されることを意味します。たとえば、投稿したばかりの写真にコメントが付くと、People アプリのタイル (およびアプリの [Me] (Me) 通知タブ) に更新に関するアニメーションが表示され、内容を確認することができます。同様に、ピン留めされた連絡先のいずれかに最新の情報があるたびに、タイルにそのアクティビティが表示されます。

自由な制御

もちろん、私たちは接続先の各データソースのポリシーを順守しています。たとえば、People アプリは現在のところ Exchange データをクラウドに同期することはできません。この結果、雇用主のポリシーの対象となるデータがサードパーティのデータセンターに一時的であってもキャッシュされることがなくなります。ただし、これはデバイスごとに Exchange アカウントを別個にセットアップする必要があり、contacts.live.com から取得することはできないことも意味しています。同様に、連絡先の電子メールアドレスと電話番号の同期に関する Facebook のポリシーは、特定のモバイルアプリと他のデバイスおよび Web で内容が異なっています。このため、Facebook の連絡先を Windows Phone に取り込むには、別個に接続して、Windows Phone の People アプリで追加のデータを利用できるようにします。Twitter にも、ツイートの表示方法に関するよく考えられた具体的なポリシーがあるため、しっかりと理解することが重要です。

私たちは、人によってアドレス帳やネットワークの使い方が少しずつ異なることも理解しています。ですから、何をどのネットワークで共有するかや、ネットワーク上のだれを共有するかを自分で制御することができます。たとえば、Facebook に接続するとき、アドレス帳だけでなく、インスタントメッセージングなどの他の機能に接続するかどうかも決めることができます。

今後に向けて

最新のデバイスには、自由に制御できる、すべて揃ったクラウド対応の接続型アドレス帳が必要であるという私たちの見解に対して、すぐに反応をいただけることを楽しみにしています。セマンティックズームや、共有コントラクトを使うどの Windows 8 アプリからでも Facebook や Twitter の友人と共有できる機能など、Consumer Preview 以降これまで追加してきた機能を活用していただければさいわいです。

--Jeff Kunins

リッチで拡張性に優れたメディアプラットフォームの構築

2012-06-18T22:51:00Z

Windows では、ユーザーがビデオやオーディオを楽しむための幅広いテクノロジが提供され、開発者は豊富な API を通してこれらのテクノロジを利用することができます。この記事では、デスクトップアプリと Metro スタイルアプリの両方について大幅に改良された Windows のメディアプラットフォームに、コンシューマーと開発者の両方の視点から迫ります。メディア再生を取り巻く状況は Windows 7 のリリース時と比べて大きく変化しています。ストリーミングの重要性や、所有コンテンツをより幅広いデバイスで再生することへの需要は増しており、同時にメディア再生によるバッテリ消費量を大幅に削減することが求められています。Windows 8、そしてもちろん Windows RT にも組み込まれているこれらの新機能では、コンシューマーと開発者の両方に対して業界をリードするレベルのサポートを提供することを目指しています。この記事は、Media Platform and Technologies (メディアプラットフォームおよびテクノロジ) チームのグループプログラムマネージャーである Scott Manchester が執筆しました。–-Steven

映画鑑賞、ビデオチャット、音楽の再生といったリッチメディアの利用は、今日私たちが PC を利用する中で最も一般的かつ楽しい活動の一つです。今回は、幅広いマルチメディアアクティビテ��を可能にすると共に、それらの機能を拡張性のあるメディアプラットフォームを通してサードパーティの開発者に提供するために Windows 8 で行われた取り組みについてお話ししたいと思います。

Windows 8 のメディアプラットフォームは、次の 3 つの目標を念頭に設計されました。

最大限のパフォーマンス: ハードウェアの能力をフルに活かした高速で応答性に優れたメディア再生を実現し、かつ PC のバッテリ寿命を最大限に延ばすことを目指しました。
シンプルな開発と拡張: 革新的なカスタムメディアアプリの登場を助けるため、拡張がしやすく、さまざまなアプリケーションに合わせて簡単にカスタマイズできるようなプラットフォームを提供することを目指しました。
幅広いシナリオへの対応: これらを通して、さまざまな音楽、ビデオ、コミュニケーション、その他のマルチメディアアプリを可能にする、パフォーマンスと効率性に優れ、拡張性に富むプラットフォームを実現します。

これらの目標を意識して、Windows プラットフォームのメディアエクスペリエンスの刷新に臨みました。

より高速で応答性に優れたメディアエクスペリエンス

どのような種類のユーザーエクスペリエンスにおいてもパフォーマンスは重要な要素ですが、マルチメディア関連のシナリオではその重要性は特に高まります。動画はリアルタイムに再生でき、音声によるコミュニケーションは即時的に利用できる必要があります。なおかつ、これらの処理によるバッテリの消費は最小限に抑えなければなりません。

パフォーマンスを測定する際に指標となるのは、タスクを処理する際にシステムに要求する時間、演算リソース、そしてメモリの量です。これらをすべて最小限に抑えることを目指しました。メディアのパフォーマンスについての目標は、オーディオおよびビデオの再生、トランスコード、エンコード、およびキャプチャに注目して設定しました。

動画の効率的なデコード処理

あらゆるメディア関連シナリオにおいてバッテリ寿命や電力消費量を改善するため、新しくより高速なエクスペリエンスの実現に向けてシリコンチップ業界のパートナー各社と協力を続けています。Windows 8 認定 PC で実行される Windows 8 システムでは、一般的なメディアフォーマットの動画のデコード処理は、専用のハードウェアサブシステムにオフロードされます。メディア処理専用のハードウェアでは、CPU よりもずっと効率的にメディアのデコード処理を行うことができるため、CPU 使用率を大きく引き下げることができ、動画の再生はスムーズになり、バッテリ寿命も向上します。これによって、再生、トランスコード、キャプチャなど、動画のデコードを要するすべてのシナリオにおいてパフォーマンスが向上します。

以下の図は、720p の VC1 および H.264 形式の動画再生時と、Web カメラによるキャプチャ映像のプレビュー時の平均 CPU 使用率を、Windows 7 と Windows 8 とで比較したものです。

動画処理のオフロードに加え、Web カメラのキャプチャ処理でのパフォーマンス向上に寄与しているのは、DirectShow Capture API から、大幅に最適化された新しい Windows 8 メディアファンデーションの Capture API への移行です。また、H.264 および VC-1 形式のコンテンツのソフトウェアエンコーダーにも改良が加えられており、CPU を使ったエンコード処理を (それが最適な場合に) 行う際の速度と電力効率が向上しています。

オーディオ再生時のバッテリ寿命向上

Windows 8 で行われたメディアパフォーマンス改良点のもう一つの例として、オーディオ再生時のバッテリ寿命 (あるいは単に電力消費量) の改善が挙げられます。前述の動画処理のオフロードと同様にオーディオパイプラインのオフロードが可能になっているほか、オーディオ再生パイプラインが大きく改良され、定常的な再生時の効率性が高まっています。オーディオデータをバッチ化して大きな塊にまとめ、その塊の処理をまとめて同時に行うことで、CPU をスリープ状態にすることのできる時間が 100 倍以上 (10 ミリ秒から 1 秒以上) に増え、オーディオ再生時のバッテリ寿命が劇的に向上しています。

もちろん、この方法ではバッファー処理の増加によって遅延が増すため、すべてのシナリオにおいて最適というわけではありません。この後のコミュニケーションについてのセクションでは、こういったトレードオフや、各シナリオへのメディアスタックの対応方法について詳しく説明します。

オーディオおよびビデオのオフロードはあくまで一例で、Windows 8 では、デスクトップアプリと Metro スタイルアプリの両方において CPU 使用率やメモリ使用量を抑制し、バッテリ寿命を改善するため、他にもさまざまな点でメディアスタックの最適化が行われています。

メディア関連の多様なシナリオへの対応

パフォーマンスはプラットフォームの重要な要素ですが、パフォーマンス向上によって生きてくるさまざまな機能も、それに劣らず重要です。Windows 8 に含まれるこういった機能としては、近代的なビデオフォーマットのサポート、低レイテンシのコミュニケーションストリーム、外部メディアデバイスへのシームレスな接続などがあります。

プラットフォーム上のトレードオフ

多くのシナリオに対応する単一のメディアプラットフォームを開発する場合に課題となるのは、プラットフォームのさまざまな目標が互いに競合するということです。たとえば、コミュニケーションではレイテンシ低減が求められますが、オーディオ/ビデオのエンコーディングと再生で品質やパフォーマンスを向上させるためにバッファー処理を行えば、レイテンシは増します。この後のいくつかのセクションでは、こういった課題について、Windows 8 で取り組んだ以下のようなシナリオを通して説明していきます。

コミュニケーション (Skype、Lync など)
動画再生と近代的なフォーマットのサポート
動画の向きの自動調整
プレミアムコンテンツの再生
シームレスなオーディオ切り替え
メディアエクスペリエンスを追加スクリーンに
先進的なメディア技術

シンプルな開発と拡張

これらのエクスペリエンスに共通しているのは、マルチメディアプラットフォームに組み込まれた拡張性です。ユーザーがメディアを利用する際の使用ケース、メディアフォーマット、コーデック、保護メカニズム、処理方法などは多岐にわたるため、Windows では、さまざまな状況に合わせてカスタマイズされた優れたアプリや Web サイトを開発しやすいようになっています。

この後のいくつかのセクションではさまざまなメディア関連シナリオについて扱いますが、同時に、これらのシナリオが開発者やサードパーティのパートナーにとって拡張しやすいものにするために行った取り組みについてもお話ししていきます。それでは、Windows 8 開発の際にターゲットとなったさまざまなシナリオについて詳しく見てみましょう。

コミュニケーション

PC、特にモバイルデバイスを使ったリアルタイムのコミュニケーションは、過去 10 年で非常に大きな進歩を見せました。Windows のユーザーは、Skype や Lync といったサービスを使って 1 日あたり何十億分にものぼる音声通話やビデオ通話を行っています。TeleGeography (英語) の推定値によれば、Skype 対 Skype の国際通話 (ビデオ通話を含む) は 2011 年に 48% 増加し、1,450 億分に達しています。Windows 8 では、すべての PC でのビデオ/オーディオ通話のエクスペリエンス改善にも大きく投資が行われています。この目標を達成するため、次の 2 つの点に絞って取り組みました。

低レイテンシのメディアキャプチャ/レンダリングの組み込みを実現: コミュニケーションアプリでは低レイテンシが不可欠であるため、Windows は低レイテンシでのメディアのキャプチャと OS に向けた再生をサポートしています。
HD カメラのサポートによりビデオ通話のエクスペリエンスを強化: コミュニケーションのエクスペリエンスをよりリアルで楽しいものにするため、Windows では HD カメラによる高解像度のビデオをサポートしています。

低レイテンシの実現

ユーザー間の通話では、ほぼ即時的なレスポンスが求められます。このため、コミュニケーションシステムではエンドツーエンドの遅延 (レイテンシ) を最小限に抑えようとします。オーディオ/ビデオの再生では、処理量の急増やネットワークトラフィックの遅滞に対応し、電力消費量を抑えるため、バッファー処理を行うことが一般的です。しかしバッファー処理ではオーディオ/ビデオの遅延が生じるため、ユーザーにとってはレイテンシが発生することになります。Windows 8 では、メディア再生向けに最適化されたシナリオとコミュニケーション向けに最適化されたシナリオの両方に対応するよう、メディアプラットフォームが設計されており、再生モード (バッファー処理を多用し、より幅広い状況に対応) とコミュニケーションに最適化されたモード (遅延を抑制) に切り替えて、メディアインフラストラクチャを使用することができます。

TIA/EIA 920 の標準 (英語) によると、実用可能なリアルタイムコミュニケーションのエクスペリエンスを実現するには、メディア処理パイプラインに由来する一方向のオーディオレイテンシは 100 ミリ秒以内に抑える必要があります。このことを踏まえ、私たちは次の図に示すようなパイプラインのエンドツーエンドのレイテンシを計測するテスト環境を設計しました。

レイテンシ低減のために最適化を要するさまざまなコンポーネント

ビデオによるコミュニケーションの場合、エンドツーエンド、あるいは "グラストゥーグラス" のパイプラインレイテンシを計測します。これは、1 つのビデオフレームがカメラによってキャプチャされ、対応ビデオフォーマットにエンコードされ、ネットワークループバックインターフェイスを介してストリーミングされ、デコードされ、最後にディスプレイによってレンダリングされるまでに生じる遅延を指します。

下の図は、メディアパイプラインを低レイテンシモードで使用した状態で PCM オーディオのキャプチャとレンダリングを行った結果を示したものです。最初の山は送信側での発声、2 つ目の山はその音声が受信側に届いたことを示します。両者の間の遅延は 65 ミリ秒で、目標の 100 ミリ秒を十分にクリアしています。

PCM オーディオのエンドツーエンドのパイプラインレイテンシ: 低レイテンシモード

次のグラフは、ビデオフレームがキャプチャされ、H.264 形式でエンコードされ、ストリーミングされ、デコードされ、さまざまな解像度で表示された場合のパイプラインレイテンシを、再生モードとコミュニケーション向けに最適化されたモードとで比較したものです。グラフ上の緑色の線は、総レイテンシの目標値である 145 ミリ秒 (TIA/EIA 920 が指定する実用可能なリアルタイムのビデオ通話に必要な水準) を示したものです。

ビデオフレームは秒間 30 フレームでキャプチャされ、H.264 形式にエンコードされる

再生モードでは、パイプラインの平均レイテンシは 575 ミリ秒ほどです。この遅延はスムーズな動画再生エクスペリエンスには必要なものですが、リアルタイムのビデオ通話では認められないレベルです。一方、低レイテンシモードでは、どの解像度でも余裕を持ってレイテンシの目標値をクリアしています。

HD ビデオ通話のサポート

もう一つ、Windows 8 PC でのコミュニケーション品質改善に向けた取り組みの例として、OS での HD カメラのサポートが挙げられます。新しいクラスドライバーが透過的にアプリケーションと連動し、HD ビデオ機能をサポートします。さらに、ビデオのデコード処理には、以前にご紹介したさまざまなハードウェアアクセラレーションが活用され、コミュニケーションのシナリオに対応します。

Windows 8 向けに設計された PC と Windows 8 との組み合わせでは、一貫性と品質を兼ね備え、ハードウェアアクセラレーションを活かし、電力効率にも優れたメディアコミュニケーションエクスペリエンスが実現します。メディアプラットフォームへの大幅な投資により、パイプラインレイテンシが改善されているほか、H.264 カメラのサポートが追加されており、ユーザーは高品質な HD ビデオで家族や友人とコミュニケーションをとることができます。

Metro スタイルアプリ向けのビデオ/オーディオサポート

Metro スタイルアプリでのネイティブメディアフォーマットのサポートについての私たちの主な目標は、ユーザーやアプリ開発者が信頼できるような安定して高品質な再生エクスペリエンスを、幅広いフォームファクターの PC で実現すると共に、次のような一般的なシナリオで利用される近代的なフォーマットに対応することでした。

Web 上の HTML5 ベースのエンターテインメント
一般的なスマートフォン、コンパクトカメラ、AVCHD カメラなどで撮影されたホームムービー
一般的なサービスを利用した音楽、映画、テレビ番組のストリーミング

以下の表は、Metro スタイルアプリへの対応が組み込まれているビデオ/オーディオフォーマットを示したものです。Metro スタイルアプリでの使用が推奨されているフォーマットは、ハードウェア製造元各社との緊密なパートナーを反映したもので、各種 PC フォームファクターでの予測可能なハードウェアアクセラレーションや、再生だけでなく、キャプチャ、ストリーミング、トランスコーディングなどを含めた予測可能なエンドツーエンドのシナリオパフォーマンスが考慮されています。

Windows 8 は、MPEG-4 (H.264 ビデオと AAC オーディオの組み合わせによるものが一般的) に対する優れたサポートを提供します。DivX や Xvid など、いくつかの一般的なコーデックでは MPEG-4 Part 2 標準が実装されているため、これらのファイルの多くは Metro スタイルアプリで高品質な再生が可能です。MPEG-4 Part 12 標準ベースの近代的な MOV ファイルについても同様です。これには iOS デバイスでキャプチャされた動画が含まれます。Fragmented MPEG-4 や 2K/4K の解像度も利用できるようになっています。MPEG-2 と DVD の再生については以前の Windows 8 Media Center に関する記事でご紹介したとおりです。

Windows 7 での開発時には、Windows でネイティブにサポートするコーデックと拡張によって利用できるフォーマットについて、かなり踏み込んだ議論がありました。その後コーデックを取り巻く状況は変化を続けており、H.264 をはじめとする明確に定義され幅広くサポートされた少数のフォーマットにまとまっていく傾向が安定して見られます。知的財産権やハードウェアサポートなどについて考えれば、これは合理的な流れです。ブラウザーでさえも、こちらの記事 (英語) にあるように、HTML5 によって同様の移行を遂げつつあります。しかし一方で、個々のユーザーはさまざまな理由から異なるフォーマットを好むということもわかっているため、Windows 8 のアプリ開発では開発者が自分の希望するフォーマットを使用できるようにしたいと考えました。Windows 8 のメディアプラットフォームは拡張性に優れているため、先進的なユーザーのコミュニティや一部の開発者に人気のある FLAC、MKV、OGG などのフォーマットについては、Metro スタイルアプリの一部としてコーデックをパッケージ化することができます。

動画の向きの自動調整

従来型のカメラ、スマートフォン、タブレットなどへのビデオ録画機能の普及により、ビデオキャプチャは縦長でも横長でも行われるようになっており、近代的なタッチベースのインターフェイスにより、「正しい向き」というものがなくなりつつあります。動画を撮影した後、PC で表示してみて初めてカメラが横向きや逆さまになっていたことに気付き、苛立った経験をお持ちの方も多いでしょう。ビデオのスキャンパターンは固定されているため、再生してみると正しい向きに表示されないことがあります。

この問題を解決するため、MP4 や ASF といった主要なファイルフォーマットで、録画したビデオをストレージに保存する際に、カメラがメタデータとして向きの情報を書き込むケースが増えています。

個人撮影の動画を Windows PC で再生する際のエクスペリエンスを向上させるため、この問題に対しては次のような改良を施しました。

MP4 および ASF (VC-1、WMV) のビデオで向きのメタデータをサポート
向きのメタデータを含むビデオは再生時に自動回転
向きのメタデータを含むビデオのサムネイルも自動回転
ビデオキャプチャ機能を持つ Metro スタイルアプリは向きのメタデータを容易に読み込み/書き込み可能

プレミアムコンテンツ

Windows 8 で大きく投資したもう一つの点として、プレミアムコンテンツのシームレスな再生があります。インターネットで消費される動画コンテンツは当初ユーザー生成コンテンツが一般的でしたが、昨今のインターネット上のビデオの増加は、その多くが "プレミアムコンテンツ" によるものです。これは、オンデマンドでのストリーミングビデオによる映画のオンライン購入や、広告を利用したテレビ番組の配信などを指します。IHS Screen Digest の調査に基づく情報 (英語) によれば、2012 年に米国でストリーミング配信される有料ムービーの数は、2011 年の視聴数の 2 倍以上に相当し、DVD と Blu-Ray でのムービー再生数を 10 億以上上回る、34 億本に達する見込みです。

プレミアムビデオコンテンツの利用要件には、他のビデオコンテンツと同様の点も多くありますが、最適なエクスペリエンスを提供するためには、それ以外に 2 つの重要なプラットフォームの機能が必要です。可変ビットレートによるストリーミングと、コンテンツ保護です。

可変ビットレートストリーミング

可変ビットレートストリーミングでは、ネットワークやリソース使用率のさまざまな状況に応じて最適なビットレートを使用することによって、よりスムーズで応答性に優れたビデオ再生エクスペリエンスを実現します。この方法でビデオの最初の何フレームかを低めのビットレートで転送することにより、再生開始までの時間やシークに要する時間を大幅に短縮することができます。ネットワークやデバイスの状況が変われば、PC はビットレートの引き上げや引き下げを要求し、バッファー処理を最小限に抑えたり、ビデオの品質を上げたりすることができます。

Windows 8 のメディアファンデーションプラットフォームが備える拡張性により、アプリはカスタムメディアソースや可変ビットレートのメディアソースを利用して新しいフォーマットに対応することができます。また、カスタムメディアソースやストリーミングプロトコルで、ハードウェアオフロードやコンテンツ保護を使用することも可能です。

Windows Azure メディアサービス担当チームでは、Windows の拡張性モデルを利用して、Smooth Streaming Client SDK for Metro style apps (英語) の構築に取り組んでいます。スムーズストリーミングは、高品質なマルチビットレートコンテンツを配信し、ビデオオンデマンド、Live、リニア TV、ダウンロードアンドプレイなどの実現を目指す、Microsoft の取り組みです。

コンテンツ保護

インターネットでプレミアムビデオコンテンツを配信するサービスの多くでは、コンテンツ保護が適用されます。これは通常、コンテンツの所有者 (e.g. 映画スタジオ、テレビ局など) の要請によるものです。Metro スタイルアプリでの保護コンテンツ再生を可能にするため、Microsoft では、プレミアムコンテンツサービス向けに PlayReady Client SDK (英語) を提供しています。PlayReady はストリーミングとダウンロードの両方に対応しており、前述の IIS Smooth Streaming Client SDK と PlayReady Client SDK とのシームレスな連携により、サービス各社はコンテンツ保護が有効なストリーミングのエクスペリエンスを簡単に構築することができます。

もちろん、業界では現在、他のコンテンツ保護テクノロジも使用されています。可変ストリーミングと同様に、メディアファンデーションの拡張性モデルによって、サードパーティはハードェアアクセラレーションのビデオデコード処理に、独自のコンテンツ保��システムを組み合わせることができます。独自のストリーミングフォーマットやコンテンツ保護システムを利用する必要があるサービスでも、デコード処理の品質やバッテリ寿命を犠牲にすることなく、自社テクノロジを組み込むことができます。

Windows 8 では、ユーザーが選択できるプレミアムコンテンツサービスの幅が広がり、ストリーミングとダウンロードの両方に対応した優れたエクスペリエンスと優れたバッテリ寿命が両立した、高品質なプレミアムビデオコンテンツをデバイスで楽しむことができるのです。

シームレスなオーディオ切り替え

Windows 8 は多種多様なメディア利用のシナリオに対応しますが、それらのシナリオ間の切り替えをなるべくシームレスで滑らかなものにすることも重要な点でした。複数のオーディオ関連アクティビティがバッティングすることは珍しくありません。たとえば、ストリーミングサービスで音楽を聴いているユーザーが、そのままビデオクリップの視聴を開始することもあります。Windows 8 では、好きなコンテンツを好きなときにストレスなく利用できるような、クリーンで整理されたオーディオエクスペリエンスを目指しました。

Windows 8 では、すべてのオーディオコンテンツを単純に混ぜ合わせた (しばしば意味をなさない) 音声をスピーカーにストリーミングするのではなく、その方が合理的な場合は、一つの音声ストリームを再生するときは別のストリームを一時停止しておくことができます。ほとんどの場合、フォアグラウンドにあるアプリのオーディオが優先的に再生されます。アプリをバックグラウンドに移すと、そのアプリのストリームは停止されます。たとえばゲームアプリから他の画面に切り替えた場合は、ゲームの音声は止めておきたいことが一般的です。ただし、こういった挙動が望ましくないケースもあります。たとえば、背景で音楽を流しながらメールチェックや Web サーフィンをしている場合などです。こういったシナリオに対応し、意味のある場面ではバックグラウンドアプリのオーディオを聴くことができるよう導入されたのが、再生されるオーディオのタイプを反映する、ストリームタイプです。

以下はストリームタイプの一覧とそれに対応するコンテンツタイプの例を示したものです。

オーディオのカテゴリ	ストリームの例	バックグラウンド対応
バックグラウンド対応メディア	ローカルまたはストリーミングによるオーディオ再生リスト	はい
フォアグラウンド専用メディア	映画、ゲーム	いいえ
コミュニケーション	Skype、ボイスオーバー IP、ライブチャット	はい
アラート	アラーム、通知	いいえ
ゲームメディア	ゲームで再生される BGM	いいえ
ゲームの効果音	銃声、爆発音、キャラクターの会話、その他音楽以外のすべての音声	いいえ
効果音	ボタンの確認音、ビープ、警告音など	いいえ
その他	デフォルトのオーディオタイプで、バックグラウンドで再生を続ける必要のないすべてのオーディオメディアで使用を推奨	いいえ

メディアエクスペリエンスを追加スクリーンに

Windows 7 では、対応する外部デバイスにエクスプローラーや Windows Media Player からメディアファイルをストリーミングできる、"リモート再生" 機能が発表されました。Windows 8 ではこの機能がさらにシンプルで使いやすいものとなっており、個人的メディアコレクションや HTML5 メディアを、家の中のリモート再生対応デバイスと簡単に共有することができます。リモート再生機能の主旨は、個人のコンテンツを中心としたリッチでソーシャルなエクスペリエンスを構築することにあります。たとえば、家族や友人との写真の共有、ホームパーティーでの音楽のストリーミング、インターネットに公開されているユーザー生成のビデオコンテンツの視聴といった利用方法が考えられます。エクスペリエンスは既存の Web サイトの HTML5 コンテンツやユーザーの個人的なメディアコレクションと緊密に連携するよう、根本から設計されており、メディアが Windows PC やタブレット内のローカルライブラリに保存されている場合も、別の家庭内 PC やネットワーク接続されたメディアサーバー、あるいはクラウド上の Web サーバーに保存されている場合も、同じように楽しむことができます。

Windows 8 では、リモート再生は従来よりも発見しやすくなり、多種多様な Metro スタイルアプリを通して、一貫性のある高品質なエクスペリエンスを利用することができます。ユーザーエクスペリエンスの改良点としては、たとえば次のようなものがあります。

セットアップの改善: 共有を許可しているホームネットワーク (ホームグループ) では、リモート再生対応デバイスは自動的に検出され、PC にインストールされます。
デバイスのエクスペリエンス向上: Metro スタイルアプリは、Windows 認定のリモート再生レシーバーとのみ連動します。これらのデバイスは、近代的なメディアフォーマットへの対応状況が確認されているほか、DLNA 標準に準拠しており、パフォーマンス面でも優れています (年内に提供予定の更新プログラムを適用した Xbox 360 もこれに加わります!)。Windows 7 で導入されたデスクトップエクスペリエンスがエクスプローラーのリボンに追加され、DLNA DMR デバイスは引き続きすべてサポートされます。
発見が容易: リモート再生にはデバイスチャームからアクセスできるため、リモート再生機能をサポートするすべてのアプリから簡単に利用することができます。画面右端から内側に向かってスワイプし (または画面右上の角にマウスカーソルを合わせ)、デバイスチャームを選択し、ストリーミング先のデバイスを選択するだけです。
Metro スタイル IE への統合: IE によって、HTML5 の音楽、ビデオ、写真を Web から各デバイスへとストリーミングすることができます。
新しい音楽、ビデオ、およびフォトアプリと連動: アプリは、さまざまなソースやコレクションから個人の写真、音楽、ビデオをストリーミングすることができます。

ビデオアプリからのリモート再生

また、開発者がアプリや Web サイトで簡単にリモート再生を使用できるようにすることも重視しており、すべての Metro スタイルアプリがリモート再生コントラクトを通してこの機能を利用できます。Xbox 360 は年内に提供される更新プログラムによってリモート再生に対応する予定です。

先進的なメディア技術

Windows 8 では、新しいコンテンツタイプの消費が可能になると共に、コンテンツ作成やコミュニケーションの面でも柔軟性が増します。Windows 8 で導入されるマルチメディアエクスペリエンスの強化点としては、ステレオ 3D、アクセシビリティ、そして DSP エフェクトが挙げられます。

ステレオ 3D ビデオ

ここ数年のうちに、ステレオ 3D (S3D) の市場は、前評判や噂の段階から完成されたコンシューマー製品の段階へと一挙に進化しました。S3D は、別のアングルからキャプチャされた 2 つのビデオを同時に表示し、3D 眼鏡を通して見ることで、1 つの立体的なビデオとして視聴することを可能にするものです。私たちは、個々の 3D 技術の細部を抽象化してエンドユーザーの PC から切り離したプラットフォームを用意し、そのプラットフォーム上でゲームやビデオ再生のシナリオを実現することにより、Windows 向けに存続可能な S3D 環境を確立することを目指しています。

Windows 8 で S3D を利用するには、DirectX 10 またはそれ以上の GPU と互換ドライバーが必要です。S3D コンテンツの視聴には、S3D 互換のディスプレイが必要です。開発において重視したのは、一貫性のあるユーザーエクスペリエンスで幅広いディスプレイテクノロジをサポートし、ソフトウェアやハードウェアが育ちやすいプラットフォームを提供することです。その結果、グラフィックドライバーの力によって個々の S3D ディスプレイテクノロジの違いは問題でなくなり、ステレオ 3D を利用するアプリに、一貫性のある API 群を提供することが可能になりました。

Windows 8 のメディアプラットフォームは、標準準拠のメディアフォーマットで S3D ビデオをサポートします。オンライン配信で一般的に使用されているフォーマットは、フレームパッキングメタデータを SEI (Supplemental Enhancement Information) の形で付与された H.264 ビデオで、このため Windows 8 の S3D ビデオにもこのフォーマットが最適です。下の図に示すとおり、左右配置と上下配置の両方のフレームパッキング方式が、プラットフォームでネイティブにサポートされます。

左右配置と上下配置など、さまざまな 3D 入力フォーマットに対応

Web プラットフォームでのメディア利用のアクセシビリティ確保

メディアのアクセシビリティ確保、特にアクセシビリティのニーズを持つユーザーへの対応は、Windows からお客様への重要な約束の一つです。

解釈や追加情報を表示できる字幕は、文字化された音声を好むユーザーや、別言語に翻訳されたテキストを求めるユーザー、聴覚障碍のため文字情報が必要なユーザーに役立ちます。

Windows 8 での字幕付きのビデオ再生

W3C を通して Web コミュニティ全体が協力することにより、すべての近代的な Web プラットフォームで字幕表示をするための最適な方法が確立されています。これには以下が含まれます。

<track> 要素に、HTML5 ビデオタグの字幕やクローズドキャプションの情報を格納することができます。この機能は Windows 8 に組み込まれており、IE10 やその他の HTML を使ったアプリで、ビデオタグを使った字幕のサポートが可能になっています。
ユーザーコントロールは、ビデオタグの既定のメディアコントロール上から利用できます。
Web コミュニティやテレビ/放送業界のパートナーが一般的に使用している WebVTT および SMPTE-TT フォーマットがネイティブにサポートされます。
Windows 8 のメディアプラットフォームは、複数のオーディオトラックを含むメディアソースをサポートします。複数の言語のオーディオトラックをユーザーが自分の言語に合わせて切り替えることができるほか、視覚障碍のあるユーザー向けの音声情報にトラックを使用することも可能です。Metro スタイルアプリは、オーディオトラックの切り替えや、複数のオーディオトラックの同時再生が簡単にできるようになっており、たとえば通常のオーディオトラックに音声による解説を重ねて再生することができます。

Windows 8 での複数のオーディオトラックを含むビデオの再生

メディアパイプラインへのエフェクトの追加

Windows 8 のメディアプラットフォームは高い適応性を備えています。その一例として、パイプラインにエフェクト (デジタル信号処理、または DSP とも呼ばれます) を追加することができます。手ブレ補正や Web カメラのプレビューで便利な水平反転など、組み込みのエフェクトがいくつか用意されているほか、アプリケーションからメディアファンデーションのパイプラインにプラグインして独自の効果を追加するのも容易です。さらに、メディアのデータが効率よくパイプラインを通過するよう配慮されているため、DSP の追加によるパフォーマンスや消費電力への影響も最低限に抑えられます。

まとめ

Windows 8 のメディアプラットフォームは、滑らかで応答性に優れたメディアエクスペリエンスと、バッテリ寿命の確保を両立する設計となっており、音声によるコミュニケーション、オーディオおよびビデオの再生、コンテンツのストリーミングなど、幅広いシナリオで優れたユーザーエクスペリエンスを提供します。Windows のメディアプラットフォームが活躍の場を提供することによって、進化を続けるさまざまなメディア関連アプリケーションが、すべての Windows 8 PC で力を発揮していくでしょう。

最後に、新しいメディアプラットフォームの見どころを簡単に紹介したビデオをご覧ください。

--Scott

アプリで Windows 8 のコントラクトのアクティベーションを行う

2012-06-14T21:20:00Z

これまでよく取り上げてきたトピックの 1 つとして、Windows 8 PC のアプリがどのようにして他のアプリや Web サービスと通信できるかということがあります。Windows 8 の手始めとして、アプリが、より充実した操作モデルとより明確なセマンティクスにより、一種のクリップボードのように、共有するデータの移動元または移動先になるというアプローチを選択しました。アプリにコントラクト (英語) を実装すると、Windows 8 は、そのアプリとシステム上の他のアプリ、およびシステム自体をつなぐ糊のような役割を果たします。この実際の動作は、Metro スタイルの Internet Explorer で Web ページから共有チャームを使用するなど、単純な操作を行ったときに確認できます。People アプリなどに連絡先情報を保存しているユーザーと、メールアプリを使ってリンクを共有できます。検索コントラクトを実装するアプリ全体を検索できます。File Open Picker (ファイルオープンピッカー) コントラクトおよび File Save Picker (ファイル保存ピッカー) コントラクトを実装する任意の場所からファイルを開いたり、その場所にファイルを保存したりすることができます。この革新的なアプローチにより、Windows 8 は、特定のアプリの単一レベルのサポートを "ハードコーディング" するのではなく、任意のアプリとサービスのペアに対応できます。また、(選択している場合) これはすべて Microsoft アカウントによってサポートされ、Facebook から Twitter、LinkedIn など、異なるサービスに接続できます。今週 1 週間にわたって、新しい Microsoft アプリに関する一連の記事を投稿します。これらの記事では、Windows 8 による共有、接続、統合が主なトピックになります。これは、Windows 8 アプリ開発者ブログからの開発者に焦点を合わせた記事の再投稿で、ユーザーエクスペリエンスチームのプログラムマネージャーである Derek Gebhard が執筆しました。--Steven

Metro スタイルアプリの開発を始めるとすぐに行き当たるのがコントラクトです。コントラクトは Windows 8 で導入された強力な新しいコンセプトで、Metro スタイルアプリはこれを利用して、他のアプリや Windows との間の対話的操作のサポートを宣言することができます。検索コントラクト、共有コントラクトなど、いくつかはおそらく既に耳にされていることと思います。コントラクトを活用することで、アプリはシステムや他のアプリとの連携能力が増し、インストールされているコントラクト対応アプリの数が増えるほど、機能が向上していきます。この記事では、アクティベーションの流れをご紹介します。アクティベーションは、アプリにコントラクトを追加する際に考慮する必要のある中心的な概念の 1 つです。

Metro スタイルアプリの起動を行い、ユーザーがアプリを起動した理由をそのアプリに通知するのに使用されるのが、Windows アクティベーションプラットフォームです。アプリ起動の理由はさまざまで、ユーザーがスタート画面でアプリのタイルを使って起動した場合もあれば、たとえばユーザーが検索を行った際の結果表示など、具体的なタスクのために起動される場合もあります。Windows はアプリに、起動された理由と、必要な場合はタスクを完了するための追加情報を提供します。Windows 8 アクティベーションプラットフォーム以前、こういった情報をアプリに受け渡すために使用されていたのは、コマンドラインパラメーターでした。新しいモデルでは、StorageFile、ShareOperation などのライブオブジェクトを受け渡して、アプリにコンテキスト情報を与えることもできます。これはコントラクトの有用性がさらに際立つ要素の 1 つと言えるでしょう。それでは、コントラクトによる起動をサポートするために必要な知識を、詳しく見ていきましょう。

コントラクト: 目的に応じた、コンテキストを伴う Metro スタイルアプリの起動

Windows 8 Consumer Preview のデモ (英語) でご覧いただけるとおり、Windows 8 のコントラクトは、他の Metro スタイルアプリやシステム UI とアプリをつなぐ糊のような役割を果たします。たとえば、File Open Picker (ファイルオープンピッカー) コントラクトを使用すると、ユーザーはアプリ内から別のアプリのファイルをインポートすることができます。検索コントラクトでは、システム内のどこからでもアプリを検索することができ、クエリを複数のアプリ間で迅速に受け渡すことができます。いずれの場合も、そして他の多くのコントラクト使用シナリオでも、ユーザーが目的のタスクをすばやく効率的に完了できるよう、Windows がアプリの UI の特定の部分を直接指定して起動できるようになっている必要があります。そこで活躍するのが、アクティベーションプラットフォームと API です。

ユーザーがアプリの対話的操作を開始する方法は 2 種類あります。

アプリのイマーシブビューをフォアグラウンド表示する必要があるアクションによるもの。これを別名 "メインビューアクティベーション" と言います。検索コントラクトなどが該当します。

メインビューアクティベーションの例
実行中のアプリケーションのコンテキスト内にとどまったまま、インラインでホストされるアクションによるもの。これを別名 "ホステッドビューアクティベーション" と言います。以下に例を 2 つ示します。1 つはファイル選択機能に参加しているアプリ、もう 1 つは共有ターゲットとして使用されているアプリです。

ファイル選択ツールでのホステッドビューアクティベーションの例

共有ターゲットとしてのホステッドビューアクティベーションの例

両者の違いをまとめると、次のようになります。

メインビューアクティベーション	ホステッドビューアクティベーション
完全なイマーシブ表示で、メインアプリとして起動	システムのクロム内で UI を表示
幅広い用途に使用可能	流れの決まった短いタスクに使用され、コードもそのタスクのみに特化
切り替えリストに表示される	切り替えリストに表示されることはない
ジェスチャによって閉じることができる	同じアプリのメインウィンドウのビューには影響しない

それでは、各アクティベーションモデルについて見ていきましょう。いくつかの一般的なシナリオに適用して紹介しますので、優れた Metro スタイルアプリを開発する参考としていただければと思います。

シナリオ 1: アプリに検索アクティベーションを組み込む

Windows 8 では、検索コントラクトによる検索機能をアプリに追加すると、ユーザーはシステム内のどこからでも、好きなときにそのアプリのコンテンツを検索できます。アプリがメインアプリとして表示されている場合は、検索チャームから直接アプリのコンテンツを検索することができます。そうでない場合、検索チャームで検索ペインのアプリ一覧からアプリを選択することで、そのアプリの検索が可能になります。

アプリで検索アクティベーションをサポートすると、クエリに応じて検索結果を表示するためにいつでもそのアプリを起動することができます。検索ペインからの起動は、スタート画面からの起動と同様、メインビューアクティベーションに分類されます。よって、アプリで複数のコントラクトをサポートすると、さまざまな異なるシナリオでアプリが起動される可能性があります。さらに、この種のアクティベーションは、アプリが既に実行中の場合も発生することがあります。ユーザーがそのアプリのメインビューを、特定のシナリオ (たとえば検索結果の表示) 向けに転用したいと考える場合があるためです。こういった使用方法に対応するため、次のようにすることをお勧めします。

アプリ起動の目的であるメインビューコントラクトへの対応に必須でないコードは、読み込みを遅延させます。
すべてのコントラクトに使用する一般的な初期化ロジックと、特定のコントラクトに対応するためのロジックとを分離します。
起動の際に 1 回だけ実行されることを想定したコードは、複数回実行される可能性があるような形でアクティベーションのハンドラーに組み込まないよう、注意します。
ユーザーにとってアプリが常時実行/常時接続されているように見えるよう、終了された状態からの起動時には、前回の状態や設定を再度読み込みます。

参考に、"ストア" アプリと "フォト" アプリをご覧ください。いずれも、これらの推奨事項に忠実な形で検索アクティベーションをサポートしています。

"ストア" アプリでの検索

"フォト" アプリでの検索

では、JavaScript アプリと XAML アプリについて、検索アクティベーションを正しくサポートする方法を見ていきましょう。

JavaScript アプリ

JavaScript による Metro スタイルアプリの場合、アクティベーションは WinJS.Application.onactivated イベント (英語) によってエクスポーズされます。アプリが既に実行中や中断状態でない場合は、このイベントは、DOMContentLoaded の完了後に実行されます。それ以外の場合、このイベントは Windows がアプリをアクティベートする必要が発生した時点で実行されます。JavaScript アプリ向けの Visual Studio のツーリングでは、このイベント登録のセットアップを default.js 内で処理するようになっており、通常起動によるアクティベーションが発生した場合 (つまりユーザーがスタート画面からアプリを起動した場合) に実行するコードを追加できる領域が提供されます。

アプリで検索アクティベーションのサポートを拡張する方法は次のとおりです。

Visual Studio マニフェストデザイナーを使用して、検索の宣言をマニフェストに追加します。
アプリ起動のたびに理由を問わず実行が必要な、一般的な初期化コードがある場合は、JavaScript のグローバルスコープに配置します。その中に DOM へのアクセスが必要なコードが含まれる場合、そのコードは DOMContentLoaded イベントハンドラー内に追加します。
検索のためのアクティベーションをハンドルするよう、登録を行います。
検索によってアプリがアクティベーションを受けた場合は、アプリの検索結果ページを表示し、アクティベーションイベントの引数から得られる QueryText (英語) をパスします。

この処理を手動で行うよりも楽な方法はないのかとお考えのことと思いますが、さいわい、Visual Studio のツーリングを利用すると、処理の多くを簡単に済ませることができます。プロジェクトを右クリックして [Add] (追加) > [New Item] (新しいアイテム) を選択し、ダイアログで [Search Contract] (検索コントラクト) を選ぶと、この記事で紹介しているコードの大部分と、Microsoft が定める検索 UX のガイドライン (英語) に準拠した方法で検索結果を表示する検索 UI が、自動的に作成されます。ただし、このツーリングでは、WinJS.Navigation フレームワークを使用する必要があります。

次に示すのは、私が作成したフォトアプリの default.js ファイルから抜粋したコードスニペットで、検索アクティベーションをサポートしているようすが確認できます。

// Register activated event handler
WinJS.Application.addEventListener("activated", function (eventObject) {
    ...
    if (eventObject.detail.kind === appModel.Activation.ActivationKind.launch) {
        ...
    } else if (eventObject.detail.kind === appModel.Activation.ActivationKind.search) {
        uri = searchPageURI;
        pageParameters = { queryText: eventObject.detail.queryText };
    }
    // Indicate to the system that the splash screen must not be torn down
    // until after processAll and navigate complete asynchronously.
    if (uri) {
        eventObject.setPromise(ui.processAll().then(function () {
            return nav.navigate(uri, pageParameters);
        }));
    }
});

XAML アプリ

XAML による Metro スタイルアプリの場合、アクティベーションをサポートするために必要な処理の多くは、Windows.UI.Xaml.Application クラス (英語) が行います。このクラスは、検索などの一般的なコントラクトをサポートするためにオーバーライドすることができる、厳密に型指定されたアクティベーションメソッド群をエクスポーズします。厳密に型指定されたメソッドのないコントラクトアクティベーションでは、OnActivated メソッド (英語) をオーバーライドしてアクティベーションの種類を検査し、アプリのアクティベーションにつながったコントラクトを特定します。

Visual Studio の新しい XAML アプリプロジェクトには、Windows.UI.Xaml.Application クラス (英語) を使って通常起動によるアクティベーションにアプリを対応させるための、生成済みコードが付属しています。このアクティベーションをハンドルするためのコードは、App.xaml.cs/cpp/vb ファイルの、アプリのクラス表現内にあります。

アプリで検索アクティベーションのサポートを拡張する方法は次のとおりです。

Visual Studio マニフェストデザイナーを使用して、検索の宣言をマニフェストに追加します。
アプリケーション起動のたびに理由を問わず実行が必要な、一般的な初期化コードがある場合は、App.xaml.cs/cpp/vb の App コンストラクター内に配置します。
検索アクティベーションをハンドルするよう、App.xaml.cs/cpp/vb で厳密に型指定された OnSearchActivated メソッド (英語) をオーバーライドします。
アプリの検索 UI を読み込み、SearchActivatedEventArgs (英語) で受け取ったクエリに対する検索結果を表示します。

JavaScript アプリの場合と同様、手動よりも楽な方法が用意されており、Visual Studio のツーリングを利用して処理の多くをこなすことができます。プロジェクトを右クリックして、[Add] (追加) > [New Item] (新しいアイテム) を選択し、ダイアログで [Search Contract] (検索コントラクト) を選ぶと、この記事で紹介しているコードの大部��と、Microsoft が定める検索 UX のガイドライン (英語) に準拠した方法で検索結果を表示する検索 UI が、自動的に作成されます。

次に示すのは、私が作成したフォトアプリから抜粋した C# コードのスニペットで、検索アクティベーションをサポートしているようすが確認できます。

検索のためのアクティベーションをサポートするには、OnSearchActivated メソッド (英語) をオーバーライドする必要があります。

protected override void OnSearchActivated(SearchActivatedEventArgs args)
{
    // Load Search UI
    PhotoApp.SearchResultsPage.Activate(args.QueryText);
}

SearchResultsPage の Activate メソッドによって、ユーザーの検索クエリに対する検索結果を表示する UI のセットアップが行われます。

// SearchResultsPage.xaml.cs code snippet 
public static void Activate(String queryText)
{
    // If the window isn't already using Frame navigation, insert our own frame
    var previousContent = Window.Current.Content;
    var frame = previousContent as Frame;
    if (frame == null)
    {
        frame = new Frame();
        Window.Current.Content = frame;
    }
    // Use navigation to display the results, packing both the query text and the previous
    // Window content into a single parameter object
    frame.Navigate(typeof(SearchResultsPage1),
        new Tuple<String, UIElement>(queryText, previousContent));
    // The window must be activated in 15 seconds
    Window.Current.Activate();
}

ここでご紹介したロジックや原則が適用できるのは、検索アクティベーションのサポートだけではありません。同じくメインビューアクティベーション型のコントラクトに分類される Protocols (プロトコル) (英語)、File Associations (ファイルの関連付け) (英語)、Device AutoPlay (デバイス自動再生) (英語) のサポートを追加する際も、同じテクニックを使うことができます。

シナリオ 2: アプリに File Open Picker (ファイルオープンピッカー) アクティベーションを組み込む

Metro スタイルアプリでは、ファイル選択ツール (ファイルピッカー) を呼び出すことによって、システム内を参照してアプリで使用するファイルやフォルダーを選ぶ機能や、新しい名前、ファイルの種類、場所を指定してファイルを保存する機能 ("名前を付けて保存") をユーザーに提供することができます。また、ファイル選択ツールをインターフェイスとして使い、他のアプリにファイル、保存先、またはファイルの更新内容などを提供することもできます。File Open Picker (ファイルオープンピッカー) コントラクトを組み込むことによって、アプリのファイルを別のアプリ内から直接選ぶことが容易になり、ユーザーは自由かつ柔軟に、アプリが保存および表示するファイルを選ぶことができます。

File Open Picker (ファイルオープンピッカー) コントラクトによるアプリの起動は、ホステッドビューアクティベーションに分類されます。アプリの UI はファイル選択ツール内でホストされ、このアクティベーションによって実行するコードは、ユーザーにファイル選択機能を提供するタスクに絞った内容にする必要があります。この場合、ユーザーに優れたエクスペリエンスを提供するため、アプリの動作をできる限り高速にすることが重要です。指定されたホステッドビューアクティベーションタスクに必須でないコードやライブラリは読み込まないよう注意します。

SkyDrive アプリはこの点で非常に優れた例ですので、ぜひご覧ください。File Open Picker (ファイルオープンピッカー) アクティベーションが適切にサポートされており、ユーザーにファイル選択機能を提供するタスクに絞った動作となっています。

SkyDrive アプリでの File Open Picker (ファイルオープンピッカー) のサポート

では、JavaScript アプリと XAML アプリについて、File Open Picker (ファイルオープンピッカー) アクティベーションを正しくサポートする方法を見ていきましょう。

JavaScript アプリ

JavaScript による Metro スタイルアプリの場合、ホステッドビューアクティベーションの動作はメインビューアクティベーションと同様ですが、重要な違いが 1 つあり、ホステッドビューアクティベーションは、必ず新しいウィンドウとスクリプトコンテキストで実行されます。このため、この種類のアクティベーションをハンドルするコードでは、アプリ本体のライブラリ、グローバル変数、DOM を利用することができません。

File Open Picker (ファイルオープンピッカー) アクティベーションをサポートするようアプリを拡張する方法は次のとおりです。

File Open Picker (ファイルオープンピッカー) コントラクトをハンドルするために設計された、専用の HTML ページを新たに作成します。
Visual Studio マニフェストデザイナーで File Open Picker (ファイルオープンピッカー) の宣言を追加し、新たに作成した HTML ページをスタートページに指定します。
パフォーマンス向上のため、このページで読み込む JavaScript 等のリソースは、File Open Picker (ファイルオープンピッカー) コントラクトのサポートに必要なものだけに絞ります。
File Open Picker (ファイルオープンピッカー) コントラクトのためのアクティベーションだけをハンドルするよう、アクティベーションイベントハンドラーを構築します。このハンドラーは、ファイル選択タスク全体の中で、1 回だけ呼び出されます。
ファイル選択ツールとのやり取りは、アクティベーションイベントの引数を使用して行います。

Visual Studio のツーリングを利用すると、この処理にかかる時間を短縮することができます。プロジェクトを右クリックして、[Add] (追加) > [New Item] (新しいアイテム) を選択し、ダイアログで [File Picker Contract] (ファイル選択ツールコントラクト) を選ぶと、次に示すコードの大部分が、プロジェクト内に自動作成されます。

次に示すのは、私が作成したフォトアプリの fileOpenPicker.js ファイルから抜粋した、File Open Picker (ファイルオープンピッカー) アクティベーションをハンドルする部分のコードスニペットです。

// Register activated event handler for handling File Open Picker activation
WinJS.Application.addEventListener("activated", function (eventObject) {
    if (eventObject.detail.kind === Windows.ApplicationModel.Activation.ActivationKind.fileOpenPicker) {
        pickerUI = eventObject.detail.fileOpenPickerUI;
        pickerUI.onfileremoved = fileRemovedFromPickerUI;
        ...
    }
});

WinJS.Application.start();

XAML アプリ

XAML による Metro スタイルアプリの場合、ホステッドビューアクティベーションをサポートする方法は、メインビューアクティベーションの場合と似ています。最も大きな違いは、アクティベーションをハンドルするために、アプリで新しいスレッドと新しいウィンドウを作成する必要がある点です。ホステッドビューアクティベーションに必要な新しいスレッドと新しいウィンドウの作成は、Visual Studio のテンプレートコードがすべて代行してくれます。

XAML アプリで File Open Picker (ファイルオープンピッカー) アクティベーションをハンドルするには、次のようにする必要があります。

Visual Studio マニフェストデザイナーを使用して、File Open Picker (ファイルオープンピッカー) の宣言をマニフェストに追加します。
App.Xaml.cs/cpp/vb で OnFileOpenPickerActivated メソッド (英語) をオーバーライドし、コントラクトをハンドルするページを読み込みます。
ファイル選択ツールとやり取りできるよう、コントラクトをハンドルするページに FileOpenPickerActivatedEventArgs (英語) をパスします。

次に示すのは、私が作成したフォトアプリから抜粋した、File Open Picker (ファイルオープンピッカー) アクティベーションをハンドルする部分の C# コードのスニペットです。

// App.xaml.cs code snippet
protected override void OnFileOpenPickerActivated(FileOpenPickerActivatedEventArgs args)
{
    var fileOpenPickerPage = new PhotoApp.FileOpenPickerPage();
    fileOpenPickerPage.Activate(args);
}

// FileOpenPickerPage.xaml.cs code snippet 
public void Activate(FileOpenPickerActivatedEventArgs args)
{
    this._fileOpenPickerUI = args.FileOpenPickerUI;
    this._fileOpenPickerUI.FileRemoved += FileOpenPickerUI_FileRemoved;
            
    // Show the user’s photos in the Picker UI
    ...

    Window.Current.Content = this;
    // The window must be activated in 15 seconds
    Window.Current.Activate();
}

ここでご紹介したロジックや原則が適用できるのは、File Open Picker (ファイルオープンピッカー) アクティベーションのサポートだけではありません。同じくホステッドビューアクティベーション型のコントラクトに分類される共有ターゲット (英語)、File Save Picker (ファイル保存ピッカー) (英語)、Contact Picker (連絡先ピッカー) (英語)、Camera Settings (カメラ設定) (英語)、Print Task Settings (印刷タスク設定) (英語) のサポートを追加する際も、同じテクニックを使うことができます。

最後に

今回の記事では、検索、ファイル選択ツールなどの Windows 8 のコントラクトのしくみについてご紹介しました。コントラクトでは、特定のタスクを行おうとしているユーザーを、システム内の他の部分や、シナリオによっては別のアプリからでも、あなたのアプリへと誘導することができます。ユーザーがアプリに期待するすばやく滑らかなエクスペリエンスを提供するには、Windows とアプリがともに、ユーザーの意図と目的のタスクを正しく認識する必要があります。コントラクトで優れたエクスペリエンスを作り出すためには、アプリのアクティベーションを正しく実装することが肝要です。コントラクトを使用せず、アプリのコア部分の開発だけを行っている場合でも、通常起動によるアクティベーションをセットアップする際には、今回ご紹介したヒントを覚えておくと効果的です。将来的にコントラクトをサポートするようアプリを拡張することになった場合も、コードを組み直すことなく、簡単に対応することができます。

覚えておくべきポイント

一般的なアプリ初期化ロジックがある場合は、アプリのアクティベーション方法と関係なく確実に実行される場所に配置します。
アクティベーションハンドラーは、アプリが既に起動している場合や中断状態の場合にも、実行される可能性があります。これによって意図しない影響が生じないよう注意してください。
検索、共有ターゲット、File Open Picker (ファイルオープンピッカー) などのコントラクトをサポートする際は、Visual Studio のツーリングが便利です。プロジェクトを右クリックして、[Add] (追加) > [New Item] (新しいアイテム) を選択するだけで、必要な処理の多くが自動的に完了します。
ホステッドビューアクティベーションを受けた場合は、アクティベーションの目的となっているタスクに必要なコードのみを読み込むようにします。

Windows 8 でのアクティベーションやコントラクトの詳細については、以下のリンクをご覧ください。また、Microsoft のフォーラム (英語) でご質問いただくこともできます。

ドキュメント

JavaScript でのアクティベーション (英語)
XAML でのアクティベーション (英語)
検索コントラクト (英語)
File Open Picker (ファイルオープンピッカー) コントラクト (英語)
共有ターゲットコントラクト (英語)
File Save Picker (ファイル保存ピッカー) コントラクト (英語)
Contact Picker (連絡先ピッカー) コントラクト (英語)
Camera Settings (カメラ設定) コントラクト (英語)
Print Task Settings (印刷タスク設定) コントラクト (英語)
Cached File Updater (キャッシュファイル更新プログラム) コントラクト (英語)
Protocols (プロトコル) コントラクト (英語)
File Associations (ファイルの関連付け) コントラクト (英語)
Device AutoPlay (デバイス自動再生) コントラクト (英語)

サンプル

アクティベーション
検索コントラクト (英語)
File Open Picker (ファイルオープンピッカー) コントラクト (英語)
共有ターゲットコントラクト (英語)
File Save Picker (ファイル保存ピッカー) コントラクト (英語)
Contact Picker (連絡先ピッカー) コントラクト (英語)
Print Task Settings (印刷タスク設定) コントラクト (英語)
Protocols (プロトコル) コントラクト (英語)
File Associations (ファイルの関連付け) コントラクト (英語)

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

Derek Gebhard
Windows User Experience (Windows ユーザーエクスペリエンス) 担当プログラムマネージャー

協力: Jake Sabulsky、Marco Matos、Daniel Oliver

Windows 8 で IPv6 を使って接続する

2012-06-12T18:58:53Z

私たちは World IPv6 Launch (英語) に参加していることから、IPv6 をサポートする Windows 8 Release Preview での作業について説明する良い機会だと思いました。この記事は、コアネットワークプログラム管理チームに所属する Christopher Palmer が執筆しました。
--Steven

IPv4 は、数十年間インターネット接続に使用されているインターネットプロトコルです。しかし、最初の設計者の信じがたい先見の明は、かなり大きな規模でインターネットに力を与え続けていますが、IPv4 はこれほど大きい負荷や規模に合わせて設計されたものではないため、インターネットの成長に伴って過負荷の兆候が表れ始めています。インターネットサービスプロバイダーは IPv4 の管理コストがしだいに上昇していると感じています。インターネットに接続された PC やデバイスの今後の急増に備えて、総点検が必要になります。

ここ数年間、Microsoft を含むこの業界では、さまざまなデバイス、サービス、ネットワークインフラストラクチャ間でまったく新しいバージョンのインターネットプロトコルである IPv6 のロールアウトに力を注いできました。Windows XP SP3 以降の Windows リリースでは、IPv6 がサポートされており、IPv6 への移行が可能です。私たちは、この劇的な移行が起きた時、ユーザー (およびアプリ) が確実にインターネットに接続できるように Windows 8 をエンジニアリングしました。

IPv4 の限界

まず、基本的なことをいくつか説明します。www.bing.com などの Web サイトを参照するとき、わかりやすいこのような名前は必ず 23.3.105.97 などの IP アドレスに変換されます。IP アドレスは、概念としては電話番号と似ています。すべての連絡先に電話番号があるのと同じように、インターネットに接続するすべてのものが 1 つ以上の IP アドレスを持っています。インターネットの "電話帳" は、ドメインネームシステム (DNS) です。"ネーム" とあるように、DNS は名前を一連の IP アドレスに解決します。

IPv4 には、IP アドレスが約 40 億しかありません。これは、1970 年代には多く思えました。しかし、2015 年までに、およそ 150 億台のデバイスがインターネットに接続されます (英語) (PC、電話、家電製品、自動車、そして家具まで)。IPv4 では、これらのたくさんのデバイスがインターネットに接続のに必要なアドレスがどうしても足りません。

ここ数年 IPv4 アドレスの需要が高まるにつれて、インターネットコミュニティはこのきわめて重要なリソースを "共有" する方法を見つけ出しました。IPv4 アドレスを共有する最も一般的な方法は、ネットワークアドレス変換 (NAT) を使うものです。この機能は、ほとんどの家庭用ルーターに搭載されており、家庭内の複数のコンピューターや他のデバイスが 1 つのグローバル IPv4 アドレスを共有できます。

従来から、ISP は各家庭に 1 つの IP ドレスを割り当てています。しかし、これは次第に難しくなっています。IP の枯渇のため、どうしても各家庭で一意の IPv4 アドレスを利用することができません。間もなく、都市または国全体が大規模なネットワークアドレス変換で囲まれる可能性があります。インターネットサービスプロバイダーは、IPv4 のサポートを続けるために、コストのかかる複雑なインフラストラクチャを開発しなければなりません。エンドユーザーにとっては、IP アドレスの枯渇は、Bing などの位置ベースのサービスが正しく機能せず、ピアツーピアのアプリケーションのパフォーマンスが低下することを意味します。

IPv6 は未来の技術

Microsoft と他のテクノロジ企業は共に、IPv4 アドレスの枯渇によるパフォーマンスと接続の限界の影響を受けることなく、エンドユーザーが高品質なインターネットアクセスを行うことができるように、IPv6 の展開に取り組んできました。

IPv6 によりすぐに得られるメリットは、3 × 10³⁸ 個以上の IP アドレスです。これは、すべての人に専用のアドレスを数十億個ずつ割り当てたり、宇宙のすべての星に一意のアドレスを割り当てることができるほどの量です。この結果、インターネットは成長と進化を続けることができます。さらに、IPv6 では、IPsec の組み込みサポートのように、セキュリティとパフォーマンスも強化されています。(IPv5 はどうなったかについては、Bing を使うと "飛び越えた" 理由を調べることができます)。

インターネット全体をすぐに IPv6 にアップグレードすることはできません。現在の状態になるまで数年要したように、さらに何年も取り組みを続ける必要があります。現在、約 1% のデバイスが IPv6 のみを使ってインターネットに接続できます。

移行期間中、ほとんどのネットワークは次の 3 つのカテゴリに分類されます。

IPv4 のみのネットワーク: 大部分のインターネットサービスプロバイダーは IPv6 のサポートを開始したばかりのため、ほとんどのユーザーはこれを使っています。インターネットに接続する多くのデバイスも IPv4 のみサポートしていると思われます。
IPv4 および IPv6 ネットワーク (デュアルスタック): これは、インターネットサービスプロバイダーが IPv4 アドレスと IPv6 アドレスの両方を使って PC を構成していることを意味します。このモデルは、移行中のケーブルネットワークやダイヤルアップネットワークで一般的です。
IPv6 のみのネットワーク: これは、インターネットサービスプロバイダーが IPv6 アドレスだけを使ってデバイスを構成していることを意味します。多くの Web サイトはまだ IPv4 インターネット上にのみ存在するため、ISP は IPv6 ネットワークから IPv4 インターネットにアクセスできるように変換デバイスを使う必要があります。このデバイスは NAT64 と呼ばれます。モバイルデバイスと通信業者の間のインターネットプロトコルが 1 種類だけの方が、デュアルスタック構成より展開が簡単で安価であるため、このモードはモバイル環境で普及しつつあります。また、モバイル通信業者にとって IPv4 アドレスの枯渇は重大な危機的状況です。この構成の基本的な図を次に示します。

皆さんが今使っている接続はどの種類でしょうか。この記事の一番下に、それを調べることができるウィジェットを用意しました。

Windows 8 は、すべての種類のネットワーク構成間で確実に接続できるように設計されています。Windows 8 では、Windows PowerShell で Resolve-DNSname コマンドレットを使って DNS ルックアップを開始できます。PowerShell を開いて次のコマンドを実行すると、IPv6 レコードと IPv4 レコードの両方が返されます。IPv6 をサポートする Web サイトのみ IPv6 レコードを返します。

IPv4 のみのネットワークにおける Windows 8

IPv4 のみのネットワークでは、デバイスは IPv4 アドレスだけを使って構成されます。このモデルは、Windows 8 でもこれまでと同じように機能します。さらに、Windows ホストは、さまざまな変換テクノロジ内に IPv6 トラフィックをトンネル化して IPv6 接続を行うこともできます。変換テクノロジの例として、Teredo (英語) では IPv6 パケットが IPv4 UDP パケット内にカプセル化されます。IPv6 のみのサーバーやサービスが出現し始めているため、サーバーが IPv4 アドレスを提供していない場合、Windows 8 は自動的に IPv6 接続を試みるようになっています。Teredo は、非ドメインネットワークでのみ既定で有効になっており、UDP をブロックするネットワークでは Teredo を利用できないことがある点に注意してください。

デュアルスタックネットワークにおける Windows 8

移行期間中、デュアルスタックネットワークは一般的な展開モデルとなります。デュアルスタックネットワークでは、デバイスは IPv4 アドレスと IPv6 アドレスの両方を使って構成されます。

この移行期間中に関して私たちの主な焦点となってきたのは、毎日使うユーザーに対する移行の影響を最小限に抑えることでした。接続が IPv4 経由であるか IPv6 経由であるかが問題になってはなりません。IPv6 への移行をほとんど意識しなくても高速で信頼できるインターネットを使えるようにし、純粋にコンテンツを楽しむことができるようにする必要があります。

同時に、私たちにとっては IPv6 への移行を前進させやすいことも優先事項です。この目的を達成するため、IPv6 接続モードと IPv4 接続モードをどちらも使用できる場合、Windows では IPv4 接続を介したネイティブ IPv6 接続が優先して使用されます。

要約すると、私たちには、信頼できるユーザーエクスペリエンスを確保することと、IPv6 への移行を可能にすることの二重の目標があります。想像できるように、この目標にはある程度両立しない点があるため、インターネットコミュニティではかなり議論されてきたテーマです。

ときに矛盾するそれらの目標をうまくまとめるため、Bing.com、Microsoft.com、Xbox.com を含む、世界中の主要 Web サイトは昨年 World IPv6 Day (英語) と呼ばれるイベントを開催しました。この 1 日限りの IPv6 インターネットテストにおいて、参加した Web サイトは IPv4 に加えて IPv6 を有効にしました。

喜ばしいことにほとんどが正常に機能しました。サーバー、エンドユーザーデバイス、コンテンツ配信ネットワークなど、インターネットの正常な動作に寄与するものすべてが、問題のない規模で機能しました。

しかし、ごく一部のユーザー (世界の 0.01%) が IPv6 を間違って構成していることもわかりました。一見したところ、ルーターまたは ISP の問題のようです。IPv6 はかなり新しいテクノロジであり、間違いは起きるため、これはそれほど驚くべきことではありません。ただし、残念ながらこれらのユーザーは、毎日のインターネットの利用において大きな影響を被る可能性があります。

デュアルスタックネットワークの接続アルゴリズムに復元性を組み込む

デバイスがデュアルスタックネットワークを本当の意味でサポートするには、アプリが IPv4 と IPv6 でトラフィックを送信できるだけでなく、目の前にはどちらのタスクが適しているかを OS が判断できなければなりません。さらに具体的に説明すると、デバイスには IPv4 アドレスと IPv6 アドレスが複数割り当てられていて、接続先にも IPv4 アドレスと IPv6 アドレスが複数割り当てられている可能性があるため、スタックはどの接続元アドレスおよび接続先アドレスを接続に使うべきかを判断できなければなりません。この機能は、アドレスソートと呼ばれ、Windows 8 で強化された分野です。アドレスソートの背後にある考えは、最適な接続が生成され、アプリケーションが待機する必要がなくなる可能性が高いのはどのアドレスペアかを判断するというものです。

Windows がデュアルスタック Web サイトに接続しようとすると、Windows は自信の IP アドレスと Web サイトの IP アドレスをソートして、接続に使うペアを決定します (標準について興味がおありの場合、アドレスソートについては RFC 3484 で標準化されています)。

Windows がアドレスソートを使う方法を表した図を次に示します。

従来から、アドレスソートは Windows がルーターにより正しく構成されていることに依存しています。Windows はルーターにより提供されたルーティング情報を分析し、その情報をアドレスソートと組み合わせて使って、指定されたリソースへの高速な接続を実現します。RFC 3484 の標準では、ルーターにより IPv6 が構成されている場合は IPv6 を推奨すると定められています。

World IPv6 Day では、一部のクライアントは IPv6 ルーティング情報を使って構成されているが、実際にはインターネットに対して IPv6 接続を行っていないことが明らかにされました。これは、一部のインターネットサービスプロバイダーが構成を間違っているか、家庭用ルーターにバグがあるためのようです。Windows は、正常に機能することを期待して IPv6 を使って Web サイトに接続しますが、機能しません。最終的に、Windows は接続試行の失敗を検出し、IPv4 接続に戻します。一方、ユーザーからすると、デュアルスタックの Web サイトが 10 ～ 15 秒遅延する可能性があります。これは明らかに Web ブラウザーにとって問題となりますが、ネットワークに接続されたどのアプリでもこの問題の影響を受けます。

この問題に対する解決策を設計するとき、私たちは 2 つの重要な問題について考える必要がありました。まず、多くの企業は複雑なルーティングトポロジを展開しているという点です。変更によって、それらの環境の接続を遮断することがないようにする必要がありました。2 つ目は、Internet Explorer だけで機能するのではなく、Windows に依存する他のすべてのアプリがネットワークリソースに接続できるようにする解決策が必要であったという点です。これらのアプリが IPv6 への移行期間全体にわたってインテリジェントに接続できるかどうかは、私たちにかかっています。解決策は、既存のデスクトップアプリだけでなく、新しい Metro スタイルアプリの必要にも対応する必要がありました。

Windows 8 は、IPv6 でルーティング可能であると主張する新しいネットワークに接続すると IPv6 接続をテストし、IPv6 接続が実際に機能している場合は IPv6 のみを使います。このアプローチは、RFC 3484 の実装を変更したものです。ポリシーの結果としてアドレスをソートする代わりに、ネットワークの実際の状態をアルゴリズムへの入力として使います。構成が間違ったネットワークでは、このアプローチによりブラウザーのエクスペリエンスだけでなく、標準 Windows API を使ってデュアルスタックの接続先に接続するアプリのエクスペリエンスが改善されます。

新しいネットワークに初めて接続するとき、Windows 8 はネットワーク接続テストを実行し、この情報をキャッシュして 30 日おきにテストを繰り返します。接続の実際のテストは、Microsoft によりホストされた IPv6 のみのサーバーに対する簡単な HTTP GET です (標準について興味がある方のために付け加えると、これは RFC 3484 の実装の接続先アドレスソートのルール 5 および 6 の間で実装されます)。Windows は、IPv4 接続にも同様のネットワーク接続テストを実行します。IPv4 と IPv6 がどちらも機能する場合、IPv6 が優先されます。

Windows 8 によって企業ネットワークで問題が発生しないようにするため、この機能には 2 つの安全装置があります。

企業が、特定の接続先��対して一定のルーティング情報を提供してきた場合、Windows 8 では Windows により決定された接続よりもその設定が優先されます。企業環境では、Windows は、そのような経路を具体的に構成したネットワーク管理者がその経路の使用が適していると考えたと見なします。
この変更は、Web プロキシのあるネットワークでは実装されません。そのようなネットワークでは、プロキシがインターネットへの接続を行うため、IPv6 接続のエンドツーエンドのテストは役に立ちません。代わりに、Windows 8 はできる限り効率の良い方法でプロキシへの接続を開始します。

このように、私たちは、ローカルネットワークの設定が間違っていても、IPv6 への移行期間全体にわたって Windows 8 のアプリとエクスペリエンスが確実かつ高速にインターネットに接続し続けることができるようにしました。

将来の IPv6 のみのネットワークに対応

IPv6 のみのネットワークでは、IPv6 経由で利用可能なサービスとエクスペリエンスの数を増やすと、最も効果的にユーザーエクスペリエンスを向上させることができます。そのようなネットワークでは、IPv4 インターネットへのアクセスは NAT64 を介して行われます。これらのデバイスは、接続障害に対して脆弱であり、パフォーマンス上の重大な制限が生じてパケット損失が発生する可能性があります。さらに、一部のマルチプレーヤーゲームに必要な IPv4 ピアツーピア接続も切断されます。

Microsoft 全体として、企業とインターネットの両方の設定において、IPv6 展開が成長するようたくさんの作業を行ってきました。最も重要な取り組みは、サーバー製品で IPv6 がサポートされるようにすることです。IPv6 のサポートは、Common Engineering Criteria (CEC) の一部です。これは、Exchange Server や SharePoint などのビジネス製品で、デュアルスタック構成または IPv6 のみの構成の IPv6 がサポートされるようにするという、お客様に対する全社的な約束の一部です。2007 年以降に構築されたほとんどの Microsoft 製品では IPv6 がサポートされますが、他の Microsoft 製品の IPv6 サポート (英語) については Technet をご覧ください。この取り組みをとおして、開発者とソリューションプロバイダーは自身の製品で IPv6 をサポートすることができます。

Microsoft は、自社のサービスの IPv6 サポートにも取り組んでいます。今年前半には、Internet Society が World IPv6 Launch (英語) を発表しました。これは、インターネットを IPv6 にアップグレードするプロセスの主要なマイルストーンとなります。6 月には、Bing と他の Web サイトが永続的に IPv6 経由でのトラフィックの提供を開始します。ハードウェアベンダーは、家庭用ルーティングデバイスでの IPv6 サポートに取り組んでおり、多くの ISP は IPv6 の大規模展開を開始します。CDN (コンテンツ配信ネットワーク) も、ネットワーク内での IPv6 サポートを開始しました。

Windows 8 のリリースによって、Microsoft の一部のインフラストラクチャサービスで IPv6 サポートが展開されます。

Windows Update は、何百万人ものユーザーに毎日継続的なサポートと更新プログラムを提供する重要なサービスです。ますます多くの PC が、IPv6 のみの構成が普及しているモバイルブロードバンドネットワークに接続しています。それらのネットワークでも確実にダウンロードできるようにする必要があります。

このため、Windows Update サービスでは IPv6 と IPv4 の両方がサポートされるようになりました。Windows Update は、CDN を利用して更新プログラムを世界中に配布しており、Microsoft は IPv6 サポートを可能にするために CDN と提携しています。Windows 8 は、使用可能であれば IPv6 を使って Windows 更新プログラムをダウンロードし、ユーザーが更新プログラムをダウンロードするときに常に最適な接続を利用できるようにします。

私たちは、CDN と連携して IPv6 のサポートを Windows 8 以外にも拡大しています。その作業が終わると、Windows 7 と Windows Vista も自動的に IPv6 を使うようになり、Windows Update への接続に利用できるようになります。

道を切り開く

Windows 8 は、インターネットに接続可能ですぐに使うことができるため、IPv6 のサポートは今後数年間にわたってその接続を確保するための主要な部分です。IPv4 の設計は、現在の規模の接続を処理できるような設計にはなっていないため、インターネットは根本的な変化を経験しようとしています。すべての Web サイト、マルチプレーヤーゲーム、ビデオ通話に対するあらゆる接続が、徐々に IPv6 に移行していきます。

この移行の一部として、Microsoft は IPv6 対応製品およびサービスを提供しながら、Windows 8 でインターネットへの復元力のある接続を実現することで、道を切り開いています。

- Chris

Windows 8 Release Preview での IE10 による Web ブラウジング

2012-06-12T00:10:00Z

Windows 8 Release Preview では、Web ブラウザーのエクスペリエンスの刷新を引き続き推し進め、皆さんからのフィードバックを取り入れて、あらゆる Windows 8 デバイスで最高のブラウジングエクスペリエンスを実現しています。これにより、皆さんが日常的にアクセスしている Web を最大限に活用できます。この記事は、Internet Explorer 担当のグループプログラム管理者である Rob Mauceri が執筆しました。
-- Steven

ユーザーの皆さんに Metro スタイルアプリのメリットを感じていただけるように、私たちは、Windows 8 と足並みを揃えて新しいブラウジングエクスペリエンスを作り上げました。IE の基盤となっているアーキテクチャを拡張し、ハードウェアアクセラレーションに完全に対応する高速なブラウジングエンジンを構築し、堅固なセキュリティと、HTML5 およびその他の Web 標準のサポートを組み込みました。

Internet Explorer 10 は、マウスとキーボードを多用する使い方に対応するのはもちろんのこと、タッチ操作でも Web サイトとのやり取りを高速で滑らかに行うことができるように設計されています。IE10 によって、Web サイトは Windows 8 の Metro スタイルエクスペリエンスに含められ、スタート画面、チャーム、スナップなどの機能と共存することになります。さらに IE10 では、ユーザー自身によるオンラインプライバシーの制御を実現しつつ、Web 上の悪意のあるソフトウェアに対抗する最も効果的な保護機能が提供されます。

Metro スタイルのブラウジングエクスペリエンスは、マウスとキーボードで操作する大画面のデスクトップコンピューターにおいても、タッチ対応のモバイルデバイスにおいても、従来よりも優れた体験となります。携帯電話での "クロムレス" なブラウジングが一般に広がるにつれて、デスクトップよりも没入的で手間の少ないブラウジングエクスペリエンスに慣れてきた人が増えていることと思います。Metro スタイルのブラウジングでは、画面のすべてのピクセルがユーザーのお気に入りのサイトに使用され、全画面表示で集中しやすいサイトエクスペリエンスが提供されます。IE と Windows 8 では、Web サイトを見ていて何かをしたいと思ったら (共有、印刷、検索など)、いつでもチャームを使って達成することができます。私たちの元には、Metro スタイルのブラウジングは多くのユーザーに好まれ、特別に熱心で頻繁なブラウジングパターンを示すユーザーにさえも受け入れられているという声が届いています。この理由は、Metro スタイルの方が高速で滑らかに動作し、操作方法よりも情報に集中することができるからです。

Web ブラウジングの強化

Windows 8 Release Preview には、電源面で最適化されたタッチ操作対応の Adobe Flash Player が搭載されています。この IE10 用の Adobe Flash Player は、Windows Update を通じて更新されます。新しい Metro スタイル Web ブラウザーでは、互換性のある Web サイトの Adobe Flash コンテンツが再生されるようになりました。この最適化された Flash Player は Windows 8 の IE 10 に統合され、優れた Web ブラウジングエクスペリエンスを約束します。私たちは、Metro スタイルブラウザーで "動作する" サイトが増えることで、コンシューマーにとってのエクスペリエンスも企業にとってのエクスペリエンスも同様に向上すると確信しています。

実際問題として、主に持ち歩くデバイスでは、よく使うサイトの Web コンテンツが再生されなければなりません。再生できないと、そのデバイスは PC のおまけにすぎなくなります。一部の人気 Web サイトでは Adobe Flash が必須となっており、HTML5 による代替には対応していません。私たちの元には、Metro スタイル IE 向けに HTML5 だけで実現するエクスペリエンスを提供しないサイトに関して多くのフィードバックが寄せられました。このようなフィードバックを反映して、製品に変更を加えることになりました。たとえば、iPad で pbskids.org にアクセスしてみてください。Beeline (英語) のように Flash が必要な従業員ソリューションもあります。このサイト (英語) のような財務管理サイトでも Flash が要求されることがあります。youtube.com などのサイトも、Flash を使った場合に最良のエクスペリエンスが実現されます。

基盤となる HTML5 "Trident" ブラウザーエンジンと Chakra JavaScript エンジンの技術的な詳細および設計上の改良点、Flash Player のサポートなどについては、IE ブログを参照してください。

Windows 8 の Metro スタイルブラウザー

IE10 のユーザーエクスペリエンスは、Metro スタイルデザインパターンに合わせて専用に設計され、毎日繰り返されるブラウジングにおいても、高速かつ滑らかに動作するように作られています。私たちは、Consumer Preview に対する皆さんからのフィードバック (英語) に耳を傾け、Web ページからの画像の保存、"貼り付けて移動" コマンドによるすばやい移動、ネットワーク診断機能の統合などに対応しました。

インターフェイスとコントロールは、必要になったときに表示され、不要なときには目に入らないように設計されています。��た、毎日の頻繁な Web ブラウジングに求められるさまざまな機能も用意されています。これには、フォーム用の便利なタッチキーボードのサポート、オートコレクト付きのスペルチェック機能の統合、ページ上のテキストの検索などがあります。ユーザーエクスペリエンスは Metro スタイルのパターンと規則に準拠し、パーソナリティ、アニメーション、コマンド実行、Windows 8 チャーム、スナップなどがサポートされます。

IE10 ではサイトに重点が置かれ、端から端までのすべてのピクセルを Web のために使う
全画面表示のエクスペリエンスが提供される。

タブ機能もあり、必要になったときだけ表示される。

IE10 では、モバイル版のサイトだけでなく、フルバージョンの Web も高速かつ滑らかに動作します。タッチ操作、マウス、キーボードのどれを使う場合でも、非常に優れた応答性を期待できます。Metro スタイルブラウザーは、単なるタッチデバイスでのブラウジングを超えた、タッチ主導のブラウジングを実現します。これは、指に吸い付くような反応として体感していただけると思います。パンとズーム、スワイプによるページ移動、ダブルタップによるコンテンツの拡大縮小などのタッチ操作を行うとき、感触を確かめてみてください。Release Preview では、タッチ操作でリンクをたどるときの視覚的なフィードバックも改良され、サイトのコードがタッチ操作向けに記述されていない場合でも、より確実に操作できるようになりました。コンテキストメニューとフォームコントロールはタッチ操作向けに最適化され、デバイスの向きの変更にも適切に反応します (横向きと縦向きの画面レイアウトに合わせてスムーズに調整されます)。また、Windows 8 アプリケーションを横に並べて "スナップ" 表示することもできます。IE10 では、マウスとキーボードによる Web ブラウジングのエクスペリエンスも改良され、要望の多いキーボードショートカットのサポートや、便利なマウス操作による履歴の移動にも対応しています。これらも Release Preview で改良されています。たとえば、マウスを画面の左端へ移動して戻るボタンをクリックするだけという、より簡単な操作になっています。

Metro スタイル IE10 は、これまでとは異なる現代的なブラウジングアプローチを取っています。過去 10 年のブラウジングの主体となっていたタブとウィンドウの管理操作よりも、閲覧する Web サイトそのものにまっすぐに焦点が当てられます。たとえば Release Preview では、HTML5 ビデオに集中しようと思ったら、ダブルタップするだけで全画面表示で再生することができます。私たちは、社内でこの IE10 を普段のブラウザーとして、ラップトップやデスクトップワークステーションでも、タッチ画面やキーボードとマウスでも使い続けてきました。スタート画面に並ぶ Web サイトのタイルから、没入型の全画面表示の Web エクスペリエンスに至るまで、Windows 8 の IE は、現実の Web で毎日使ってもらえるブラウザーになるように設計されています。

ナビゲーション: ナビゲーションタイルは、最小限の入力で目的のサイトをすぐに見つけて移動できるように、各サイトのアイコンと色を使って表示されます。Release Preview では、これらのタイルをよりすばやく効率的に使えるようにレイアウトを改良しました。頻繁にアクセスするサイトを視覚的に見分けられるように最適化し、スタート画面との統一感も強化しています。

ナビゲーションタイルでは重要なサイトにすばやくアクセスできる。

お気に入りのサイトには、その名前の最初の数文字を入力するだけですばやくアクセスできます。さらに Release Preview では、お気に入りのサイトとピン留めされたサイトにバッジが表示され、簡単に見分けられるようになっています。この画面には、何度もアクセスしたサイトと、スタート画面にピン留めしたサイトが表示されます。アドレスバーに入力を始めるとナビゲーションタイルが絞り込まれ、履歴、お気に入り、または人気の高い URL のサイトが表示されます。

Windows 8 にローミングアカウントを関連付けて使うと、ブラウザーの履歴やお気に入りを持ち運ぶことができるため、どの PC からでも最近参照した Web ページに簡単にアクセスできます。

お気に入りの名前の最初の数文字を入力するだけで目的のサイトにアクセスできる。お気に入りのサイトとピン留めされているサイトはバッジ付きで表示されるので、すぐに見分けることができる。

Web サイトに重点を置くというコンセプトに従って、IE10 のナビゲーションバーは必要時にのみ表示されます。Windows Release Preview では、ナビゲーションバーに使いやすいコントロール (タッチでもキーボード/マウスでも) が統合され、戻る、進む、中止/更新、スタート画面へのサイトのピン留め、アプリの入手など、よく使われる操作を実行することができます。アドレスバーには、セキュリティで保護されたサイト、SmartScreen、InPrivate ブラウジングを示すアイコンと色が表示されます。オートコンプリートと Web 検索もサポートされ、デスクトップ版の IE と同じように動作します。Release Preview での新機能として、"貼り付けて移動" コマンドがあります。これにより、クリップボードにコピーした URL や検索語にすばやく移動できます。アドレスボックスには、ページの読み込み中に進行状況のインジケーターが表示されるほか、サイトの互換性と追跡防止に関するインジケーターも含まれます。ナビゲーションバーには、ページを検索するためのコマンドと、従来のプラグインテクノロジを必要とするサイトとの互換性のために、デスクトップ版の IE で開くためのコマンドがあります。デスクトップ版の IE は、既存のワークフローに沿ってデスクトップツールを使い続ける必要がある場合にも有用です。

[Paste and go] (貼り付けて移動) を使うことでよりすばやく移動できる。

タッチ操作によるブラウジングの強化: Release Preview では、IE10 の Metro スタイルエクスペリエンスの新機能として、複数のページから成る連続したコンテンツを新しい形で参照することができます。タッチ主体のデバイスでは、リンクをクリックする代わりに自然なスワイプジェスチャを使うことで (マウスの場合は次へ進むボタンを使うことで)、ページフリップによって雑誌を読むようにお気に入りのサイトを移動できます。New York Times で複数のページにわたる記事を読んだり、Amazon や eBay の製品一覧を参照したり、CNN.com で最新ニュースをすばやくチェックしたりする場合を想像してみてください。ページ上の "次へ" リンクを探さなくても、前方へスワイプするだけでページを移動できるのです。

"次へ" リンクを探さなくても、スワイプすることでページをめくって次の一覧に移動できる。

タッチ操作によって高速かつ滑らかに次のページに切り替えることができる。

複数のページから成るコンテンツを高速かつ滑らかに参照できる。

ページフリップを有効にすると、複数のページにまたがるコンテンツを閲覧する際に、スワイプによって同じ記事、投稿、またはスレッド内の次のページに移動できるようになります。ブログやニュースサイトのように連続したコンテンツの閲覧中に複数ページのコンテンツの最後に到達すると、次の記事、投稿、またはスレッドとして適切なページが提示され、続けて参照することができます。ページフリップを使うには、ユーザーがこの機能をオプトインし、閲覧の履歴を Microsoft に送信することに同意する必要があります。送信された情報はエクスペリエンスの品質向上に役立てられます。

Metro スタイルエクスペリエンスのその他の部分は、全体的にはこれまでと同じです。

タブ: 優れた Web ��クスペリエンスを達成するためには、複数の Web ページを参照できることが重要です。Metro スタイルのタブ切り替えの画面は、画面の下部または上部をタッチ操作でスワイプするか、マウスで右クリックするか、キーボードの Windows + Z キーを押すと表示されます。

アクティブなタブは、ページのサムネイルにページタイトルのオーバーレイテキストが重なった状態で表示されます。各タブにはタッチ操作でも使いやすいボタンが表示され、タブを閉じたり、新しいタブまたは新しい InPrivate タブを作成したりできます。IE10 は、最近使用された 10 個のタブを自動的に表示します。したがって、ユーザーが意図的にタブを管理する必要はそれほどありません。タブのクリーンアップも、コマンド 1 つで簡単にすばやく行うことができます。

タッチキーボード: IE10 は、物理キーボードだけでなく、Windows 8 のタッチキーボードにも対応しています。タッチキーボードの動作は、より使いやすいエクスペリエンスを実現するように自動的に調整されます。たとえば、アドレスバーにフォーカスがある場合は、URL をすばやく入力できるように "/" キーと ".com" キーが有効になります。

タッチキーボードは入力先の場所に応じて自動的に調整される。たとえば、
電子メールフォームフィールドでは "@" キーや ".com" キーが表示される。

IE10 では、通知に関してクリーンで "控えめ" なアプローチが取られています。警告とユーザープロンプトはすべて、画面下部にある通知バーに表示されます。ユーザーの操作が必要となる場合は、Windows 8 Metro スタイルの "ポップアップ" が使われます。通知バーは、状況に従って自動的に非表示になります。Metro スタイルブラウザーでダウンロードを行うときは、デスクトップ版の IE と同様に、SmartScreen のアプリケーション評価によって悪意のあるソフトウェアから保護されます。Release Preview の Metro スタイルエクスペリエンスでは、"ポップアップ" ウィンドウを後ろのタブとして開くことも可能になりました。

Metro スタイルでの Web サイトとアプリの関連付け

IE10 では、Web サイトは Windows 8 の Metro スタイルエクスペリエンスの一部となります。Metro スタイルのブラウジングでは、スナップ、チャーム、ストアとスタート画面の統合などにより、Web とアプリは明確には区別されなくなります。

サイトのピン留めを使用すると、よく使うサイトを Windows のスタート画面に並べてカスタマイズできます。どのような Web サイトでも IE10 からスタート画面にピン留めできるため、気になる情報や必要な情報をすべて 1 か所に集めることができます。

ピン留めされたサイトのタイルには、サイトの色とアイコンが反映されます。Release Preview では、サイトアイコンとして高解像度の PNG ファイルを使用でき、タイルの背景色も指定できます。IE10 を使うと、サイトからバックグラウンド通知を発行して、その Web サイト上の新しいメッセージや他のアカウント活動を知らせることができます。サイトでは、IE のナビゲーションバーに表示されるタッチ操作向けの追加コマンドをプログラミングすることもできます。この方法は、デスクトップ版の IE でジャンプリストをプログラミングする場合と同様です。

サイトタイルでは、Windows 8 のスタート画面からサイトに直接移動できる。

ピン留めされたサイトでは高解像度の画像、カスタム色のタイル、バックグラウンド通知を使用できるため、
お気に入りのサイトが簡単に見つかり、ひとめで最新情報を確認できる。

ストアとの統合により、IE でアクセスしたサイトの Metro スタイルアプリを簡単に見つけて起動することができます。Release Preview では、UI コンセプトが引き続き単純化され、IE の動作がわかりやすくなっています。[Tools] (ツール) アイコンは、ページに関する "特別" な情報がある場合に通知するように更新されました。そのアイコンをタップすると、ストアに移動してアプリをインストールすることができます。アプリがインストールされたら、サイトから直接起動できます。たとえば、WordPress.com は IE10 で次のように表示されます。

新しくなったツールメニューでは、サイト用のアプリがあるとユーザーに通知が表示される。

その他、Metro スタイルエクスペリエンスへのサイトの統合に関する機能として以下のようなものがあります。

Windows 8 で複数の作業を同時に行いたいときは、スナップが役立ちます。IE10 でブラウジングを行いながら、その横でメール、音楽、または他の任意のアプリケーションにアクセスすることができます。ブラウザーは、"スナップ" サイズが狭い場合にも適切に対応し、ユーザー操作のために必要となる場合は、自動的にドッキングを解除します。パン、ピンチ、ダブルタップによるズーム、リンクの参照など、コアとなるブラウジング機能はスナップ表示中もすべて利用できます。

Windows 8 の "スナップ" によるマルチタスキングを使うと、サイトをメッセージングアプリなどの他のアプリケーションと並べて表示できる。

Windows 8 では、検索や共有などの共通の操作を実行する一貫した方法として、チャームという機能が用意されています。IE10 は、検索、共有、デバイス、設定の各チャームをサポートしています。

チャームを表示するには、右端からスワイプするか、Windows + C キーを押すか、
マウスを画面の下部または右上隅へ動かす。

検索チャームでは、既定の検索エンジンが使われます。これは好みに合わせて設定できます。チャームのポップアップで検索を開始すると、入力に従って検索結果が表示されます。検索エンジンでサポートされていれば、デスクトップ版の IE と同じように、画像と簡単な結果が含められます。

共有チャームでは、共有をサポートしている任意のアプリケーション (メールなど) にアクセスできます。ここでは、画像、説明、ハイパーリンクから成るリッチなリンクプレビューを送信できます。単なるリンク以上の情報を簡単に共有できます。

IE10 とメールでは、画像、説明、ハイパーリンクから成るリッチなリンクプレビューの送信がサポートされ、
単なるリンク以上の情報をごく簡単な操作で共有できる。

デバイス チャームでは、印刷、プロジェクター出力、外部デバイスへの再生などの操作を一貫した方法で簡単に行うことができます。たとえば、デバイスチャームをタップまたはクリックしてプリンターを選べば、任意の Web ページを IE から印刷できます。飛行機の搭乗券などを印刷するのに便利です。

設定チャームでは、IE10 で特に頻繁に使われる設定にすばやくアクセスできます。ブラウジングの履歴を消去したり、アクセスの位置情報を変更したり、さまざまな設定を行うことができます。ここでの IE の設定は簡略化されていますが、デスクトップ版の IE の設定を表示すると、細かい調整を行うことができます。

悪意のある Web からの保護

IE10 には、これまでと同様に業界最先端のセキュリティ機能、プライバシー機能、信頼性機能が搭載されています。これらは、SmartScreen、XSS フィルタリング、アプリ��ーション評価、InPrivate ブラウジング、追跡防止、ハングアップの検出と回復などの IE9 の機能に基づいています。加えて IE10 では、"拡張保護モード" によって各タブ内の Web サイトのコンテンツが効果的に分離され、セキュリティとプライバシーがより安全に扱われます。また、Release Preview での新機能として、Web サイトに追跡拒否 (DNT: Do Not Track) 信号を送信するシンプルな設定 (既定でオン) が追加されました。

Consumer Preview からの主な変更点のまとめ

Windows 8 Release Preview の IE10 では、より機能が充実した Metro スタイルのブラウジングエクスペリエンスを体験していただけます。繰り返しになりますが、基盤の HTML5 エンジンに対する変更およびその他の詳細については、IE ブログを参照してください。高速で滑らかなブラウジングのために IE10 に加えられた改良点のうち、ほんの一部を以下にご紹介します。

高速で滑らかなタッチ操作の強化。完全で独立した構成により、現実の Web サイト (固定要素、サブスクロール領域、アニメーション、ビデオなど) を快適に表示します。
よりスムーズな UI の切り替えとアニメーション。ローエンドのハードウェアでのちらつきが減少しています。
Metro スタイル IE で Flash のサブセットをサポート。人気の高いメディア再生サイトやゲームサイトを楽しむことができます。
HTML5 ビデオの全画面表示をサポート。ダブルタップで全画面にズームできます。
サイト選択のレイアウトの改良。外側のタッチで非表示になる動作が採用され、お気に入りのサイトやピン留めされたサイトはわかりやすく表示されます。
ブラウザーのコマンドバーのレイアウトとサイトアイコンの扱いの改良。ナビゲーションバーコントロールが整理されました。
高解像度画面で Web ページの既定のズームレベルを調整。
"画像を保存" するためのコンテキストメニュー。
"貼り付けて移動" するためのコンテキストメニュー。
タッチ操作でリンクをたどるときの視覚的なフィードバックを改良。
スタート画面にピン留めされたサイトタイルで高解像度の画像をサポート。
Metro スタイル IE にネットワークトラブルシューティングツールを統合。
Metro スタイルのオートコンプリートドロップダウン。
ページフリップによる次のページへの移動 (ユーザーによるオプトイン)。
追跡拒否 (DNT: Do Not Track) の設定を追加。既定でオンになります。

Metro スタイルと妥協のないブラウジング

今までは、タッチ操作に適したモバイル Web を小さい画面で閲覧するか、マウスとキーボードに適したフルバージョンの Web を大きい画面で閲覧するかを選ばなければなりませんでした。これからは、Windows 8 Release Preview の IE10 による Metro スタイル Web エクスペリエンスに妥協はありません。Windows 8 と PC の機能を最大限に活用して、ブラウジング、タッチ、マルチタスキング、印刷、共有などの操作を行うことができます。IE10 での Web は、より高速で滑らかになり、アプリケーションを利用しやすく、セキュリティとプライバシーもいっそう強化されます。

-- Rob

Windows 8 のユーザーエクスペリエンスの作成

2012-06-06T22:32:00Z

このブログでは、これまで製品の詳細と機能に焦点を当てた記事が多く、"理念" や "背景" についてはあまり触れてきませんでした。しかし、Windows 8 に取り入れられている新しいイノベーションの大きさを考えれば、Windows 8 のデザインが生み出されるまでの背景に目を向けることにも価値があると思います。広く使われている製品に大掛かりな変更が加えられる場合の常として、Windows 8 もさまざまな物議をかもしています (各リンク先は英語)。Consumer Preview を日常の作業に使っている多数のユーザーが、それぞれの視点からさまざまな意見を表明しています。New York Times の David Pogue 氏 (英語) や Gizmodo の Mat Honan 氏 (英語) をはじめ、肯定的な立場からの意見も多く見られますが、そうでない意見もあります。特にこのブログのコメントでは否定的な声も目立ち、内容の濃い議論が交わされています。これこそ私たちが求めていたことです。製品に採用されることになったデザイン、今後の Windows の展開、新しいデザインが多様なユーザー層に適しているかどうかについて疑問を投げかける声もあります。Metro スタイル要素と従来のデスクトップをもっと切り離すことが重要 (英語) と考えているブロガーもいます。反対に、デスクトップはもっと Metro スタイルインターフェイスに近づけるべきだ (英語) と熱心に主張する人もいます。Consumer Preview を試用した人の数だけ、多種多様な意見があります。10 億人ものユーザーに使われている製品の新しいリリースを 10 億とおりもの形にデザインすることは、10 億人分のピザを注文するようなものです。その試みを公の場で行ったことで活発な議論が生まれたのは、私たちにとって喜ばしく価値のあることです。この記事は、ユーザーエクスペリエンスチームのプログラム管理ディレクターである Jensen Harris が執筆しました。
-- Steven

2011 年 6 月に行われた D: All Things Digital カンファレンスにおいて私たちは、Windows 8 向けに開発した (英語) 新しいユーザーインターフェイス (英語) を初めて披露しました。この新しい UI は高速で滑らかに動作し、ノート PC、タブレット、コンバーチブル PC など、現在のユーザーが大部分の時間を費やしているモバイルフォームファクターに向けて最適化されています。Windows 8 は、マウスとキーボードでも、指でのタッチ操作でも使いやすいように設計され、どの OS よりも優れたペンサポートを備えています。また、複数ディスプレイに対応すると共に、どの OS よりも幅広い構成とフォームファクターをサポートします。これらに加えて、Windows 8 には新しい種類のアプリが導入されます。これは、過去の Windows Media Center や新しい Windows Phone で展開された設計言語に従い、コードネーム "Metro スタイル" と呼ばれます。これらのアプリは、ユーザーが作業に没頭できるエクスペリエンスを提供し、全画面表示で動作し、美しく、今日のデバイスが一般にどのように使われているかを考慮して最適化されています。

ここで過去を振り返り、Windows 8 のユーザーインターフェイスがどのようにデザインされたのか、その背景について簡単に見ていきたいと思います。その後、私たちが下した決断の一部と、この新しいエクスペリエンスの目標についてより詳しくお話しします。

Windows ユーザーインターフェイスの簡単な歴史

Windows のユーザーインターフェイスは、27 年にも及ぶ歴史の中で進化と変遷を繰り返してきました。Windows UI には不変的な一面もありますが、実際には、インターフェイスはその時々の PC の使用方法に合わせて常に変化しています。ここでは、Windows UI の歴史を振り返り、時代と共にどのような劇的な変化があったかを見ていきましょう。

Windows 8 ではユーザーインターフェイスが格段に進化しているため、以降では、Windows のユーザーインターフェイスに重要な変化がもたらされたリリースに注目していこうと思います。また、それぞれの変化に対する初期の反応の一部もご紹介します。興味のある方は、Microsoft Web サイトで Windows の歴史を詳しくご覧いただけます。

Windows 1

1985 年にリリースされた Windows 1 は、現在一般に使われている PC とはまったく異なるシナリオを想定して設計されました。

最初のバージョンの Windows は DOS 上で動作する荒削りのグラフィックシェルで、主にキーボードで使うように作られていました。マウスは完全にオプションで、マウスのある PC はきわめてまれでした。

実際、当時はマウスが一種珍奇なものと考えられており、詳しい知識を持つユーザーの多くは、非効率的で扱いにくく、人間工学的に不適切で、使いこなすのが難しいものと見なしていました。マウスは完全に異邦者だったのです。画面上を転がすものにも、手に持って話しかけるものにも見えました。

ここで、1980 年代前半の出版物から、マウスの将来性に関して発表された専門家の意見をご紹介しましょう。

「マウスは良いアイデアだが、ビジネスユーザーの役に立つかどうかは疑わしい」(George Vinall、PC Week、1984 年 4 月 24 日)
「ユーザーがこういったものを使いたがる根拠はどこにもない」(John C. Dvorak、San Francisco Examiner、1984 年 2 月 19 日)
「使うのはとても楽しかったが、ビジネスの視点から考えると生産性に疑問を持たざるを得ない」(George Vinall、PC Week、1984 年 4 月 24 日)
「会社役員のような特定のターゲット層にとって、マウスはコンピューターを使いやすく馴染みやすいものにしてくれるのだろうか。答えはノーだ」(Computerworld、1983 年 10 月 31 日)
「会社役員にとって、このデバイスがキーボードよりも快適に感じられる可能性はまったくない。"回転性" のあるマウスは、仕掛けばかりに凝ったおもちゃのような感が否めない」(Computerworld、1983 年 10 月 31 日)
「現段階では、マウスとその仲間は単におもしろいというだけだ。革新的に見えるものが常に有用とは限らないわけで、そこには商業的寿命という真の試練が待っている」(David A. Kay、Datamation、1983 年 10 月)

ご覧のとおり、マウスは見せかけだけで必要なものではなく、主要な用途には役に立たないと考えられていました。一方、現在ではマウスの時代はもはや終わったと主張する人もいます (英語)。

Windows 3 および 3.1

初めて商業的成功を収めた Windows のバージョンは、1990 年にリリースされた Windows 3 でした。このバージョンではまったく新しいインターフェイスが採用され、"プログラムマネージャ" という新しいシェルがプログラムの起動、整理、切り替えを担いました。

ファイルマネージャは、Windows 3 の新しいプログラムの中で最も重要なものであり、ファイルとドライブの管理に使われました。このアップグレードは、ほとんどのユーザーがマウスを持っていて、カラフルで大きい (当時としては) 32x32 のアイコンをどうやってクリックするかを知っていることを前提した大きな賭けでした。このリリースを使いこなすには批判の多いマウスが必要だったので、レビューの多くは同様に批判的でした。

上のスクリーンショットでは、ファイルマネージャで OS 自体のファイルを参照しているという点も注目に値します。当時は普通のことでしたが、現在では、修理のために電気自動車の内部を調べるようなものと言えるでしょう。
Windows 3 の "デスクトップ" には、プログラムへのリンクやファイルを置くことはできませんでした。フローティングウィンドウの背後の領域は、最小化されたプログラムが表示される場所でした。このような最小化されたアプリに到達するには多数のウィンドウを移動させなければならなかったので、実行中のプログラムを切り替える手段として Alt + Tab というキーボードショートカットが一般的になりました。

Windows 95

数年後の 1995 年 8 月にリリースされた Windows 95 では、ユーザーエクスペリエンスの実質的な見直しが行われました。スタートメニュー、タスクバー、エクスプローラー、デスクトップなど、Windows 7 に引き継がれているコンポーネントの多くは、形は大きく違ってもこのバージョンで導入されたものでした。

これらのユーザーインターフェイス要素は今ではおなじみだと思いますが、当時は、それ以前までの PC の使い方を根本から変えるものでした。スタートボタンは、ボタン上に "スタート" という言葉が書いてあるにもかかわらず気付かれにくかったため、初期のテストリリースの後、"このボタンから始めます" というバウンドするテキストをタスクバーに追加することになりました。これにより、どうやって PC のプログラムを使い始めればよいかをユーザーに伝えようとしたのです。

いったんその "しくみ" が理解されると、スタートボタンはユーザーに受け入れられ、長く使われることになりました。そして言うまでもなく、後のバージョンでは "このボタンから始めます" というテキストを削除することができました。

当時、PC はまだ不思議な道具として見なされており、大多数の一般家庭には 1 台も PC が導入されていない状態でした。現在では当たり前のダブルクリックや右クリックなどの操作も、多くのユーザーにとってはなじみのないものでした。それにもかかわらず Windows 95 のユーザーインターフェイスで多用されたため、多数のユーザーが操作の理解と習得に苦労することになります。以下の古い動画は、私たちのユーザビリティラボで、あるユーザーが初期の Windows 95 を試しているようすを記録したものです。多くの人が経験した問題の一例を垣間見ることができます。

1993 年にデザインされた Windows 95 のユーザーインターフェイスは先進的で、当時一般的だった作業をずっと簡単に達成できるようになりました。それでも、一部のユーザーは使い慣れた Windows 3.1 から離れることを嫌い、何年も批判的な姿勢を崩しませんでした。ZDNet の Ed Bott 氏が、Windows 95 への移行過程で一部のユーザーが感じていた不満を表すおもしろい記事を発掘して紹介しています (英語)。

さて、現在よく知られている Windows エクスペリエンスの基礎は 1993 年にデザインされたものですが、2012 年の世界は大きく変わっています。1993 年には Web はまだ新しく、ほとんどの Windows 95 ユーザーは Web を試したことがありませんでした。付属のメディアプレーヤーは .wav ファイルにしか対応していませんでした。オンライン接続は一般的ではなく、利用できる環境があったとしても AOL のようなサービスを経由したものでした。つまり、モデムを使って専用のコンテンツとサービス内限定のメッセージングシステムに接続するだけでした。

Windows 95 の優れた特徴として、FAX サービス、ターミナルクライアント、ダイヤラーのサポートがありました。デジタルカメラや携帯型 MP3 プレーヤーなどのデバイスは今ではありふれていますが、1993 年の時点では消費者向け機器としては存在していなかったため、サポートもありませんでした。PDA 機能のある最初の携帯電話、IBM Simon (英語) が発表されたのはこのころです。重さは約 680 g、DOS が動作しましたが、この携帯電話向けに作られたアプリは 2 本しか販売されませんでした。今日の世界とは事情がまったく異なっていたのです。

Windows 95 の UI は当時の世界に合わせてデザインされましたが、スタートメニュー、タスクバー、デスクトップ、エクスプローラーなど、現在おなじみの Windows UI はすべて当時に生まれました。当時、ネットワークに接続して過ごす時間はほとんどなく、ユーザーは自分のコンピューターでワープロに入力したり、ファイルを操作したりしていました。DOS プロンプトで「win」と入力して Windows を起動する必要のない仕様は不自然に見え、非現実的とまで言われました (多くの議論の的にもなりました)。

現在親しまれている Windows ユーザーインターフェイスは、それほど遠い過去に生まれたのです。

Windows XP

Windows XP は、2001 年 8 月 24 日に PC メーカーにリリースされました。このバージョンでも、Windows のユーザーインターフェイスに重要な進化がもたらされました。

2001 年には、ユーザーは日常的に PC を使うようになっていました。PC の使用時間の最大部分を占めるのは、以前と同じく Web を必要としない入力作業とファイル操作でしたが、情報やメディア、特に音楽、写真、動画の収集と利用が主流になりつつある時期でもありました (ただし当時でも、初期のデジタルカメラの販売数はフィルムカメラの 1/4 に過ぎず、フィルムカメラを追い抜くまでにはさらに 3 年の年月が必要でした)。Windows 95 開発当時に想定されていたドキュメント中心の生産性シナリオに加えて、ユーザーは、PC で Web の閲覧やメールの読み書きにも時間を費やすようになっていました。

Windows XP では、画面左下に表示された "スタート" という文字をクリックしてスタートメニューを呼び出す点は以前と同じですが、スタートメニュー自体が大きく変わりました。Windows 95 以降のすべてのバージョンでおなじみの階層的なプログラム一覧は、かつてのプログラムマネージャから継承されてきたものです。これが [All Programs] (すべてのプログラム) というリンクの下にまとめられ、メール、Web ブラウジング、画像、音楽が上部に表示されるようになりました。

Windows XP は最終的に大成功を収めましたが、当時のユーザーの中にはユーザーインターフェイスの変更を不満に感じていた人もいました。そのようなユーザーにとって Windows XP のエクスペリエンスは飾りすぎていて、以前のバージョンに "ダウングレード" する方法を問い合わせる声もありました (リンク先は英語)。

Windows Vista

2006 年、Windows Vista の登場によって Windows の外観は大きく変わり、Aero 視覚スタイルが導入されました。Aero では、詳細に描画されたグラス、光源、反射など、複雑な視覚効果を持つテクスチャがタイトルバー、タスクバー、その他のシステムサーフェスに適用されます。このようなスタイル要素は当時のデザイン感覚を表しており、その作成と描画に使われた最新のデジタルツールの機能が反映されています。画面上で人工素材 (グラスやアルミニウムなど) を擬似的にシミュレートするこのスタイルは、今となっては時代遅れで安っぽく見えますが、当時は大流行していました。

Aero は、ウィンドウのクロム自体よりも、ウィンドウ内のコンテンツに集中できるようにデザインされました。タイトルバーやウィンドウの境界線から視線を離し、アプリが意図した重要な情報に注意が向くように考えられています。

スタートメニューにも再度変更が加えられました。最も目立つ変更は、Windows キー (Windows 95 で導入) を押して入力を始めるだけで、Windows のあらゆる場所から検索できるようになった点です (この便利な機能は Windows 8 にも引き継がれ、アプリ内まで検索対象とするように拡張されています)。

もちろん、それまでに行われた他の変更と同じように、これらの変更について否定的な声もありました (リンク先は英語)。

Windows 7

2009 年の秋にリリースされた Windows 7 では、さまざまな重要な局面において UI が大きく変わりました。変更の多くはタスクバーを整備するためのものでしたが、スタートメニュー、ウィンドウ操作、および PC 上のファイルを論理的に整理する方法にも重要な変更が加えられました。

大きな特徴として、新しいタスクバーではプログラムの起動とプログラム間の切り替えがまとめられました (英語)。タスクバーのアイコンは大きくなり、よりタッチしやすくなりました。スタートメニューは、使用頻度の低いプログラムを起動することに重点を置くように変更されました。これは、タスクバーとスタートメニューの両方に同じプログラムをピン留めすることはできないためです。従来、プログラムを最初に起動する場合と、既に実行中のプログラムに切り替える場合には明確な違いがありましたが、Windows 7 はその違いを取り除くスタート地点となりました。それまで私たちは、プログラムを最初に実行する場合と、既に実行中のプログラムを見つける場合とで別々の場所を参照するように慣らされてきましたが、これは考えてみれば不自然なことです。

Windows 7 は、携帯電話向け以外で初めてベース OS にマルチタッチサポートが導入された、最初のメインストリーム OS でもあります。後に他のプラットフォームのタブレットも追随しましたが、Windows 7 は、初めてマルチタッチがプラットフォームに組み込まれて出荷された OS でした。その開発を通して私たちは、タッチ操作で Windows を使おうとした場合の制限について大いに学ぶことになりました。既存のインターフェイスのほとんどと既存のプログラムのほぼすべては、マウスとキーボードでの使用に特化して設計されていました。

一部のユーザーは批判的な反応を示し、ユーザーインターフェイスの変更を求める声もありましたが、Windows 7 はすぐに世界で最もよく使われている OS となりました (各リンク先は英語)。

Windows 8 のデザインに影響を与えたトレンド

Windows 8 のユーザーエクスペリエンスのデザインは、2009 年半ば、ちょうど Windows 7 RTM のころに始まりました。私たちは当時、周囲を見渡してトレンドの調査を行いました。

当時はまだ iPad もなく、新しいフォームファクターや新しい種類のデバイスが急増する前の世界でした。今では PC の 93% 以上でいずれかのバージョンの Windows が動作していますが (英語)、当時でさえも、私たちを取り巻く世界と、ユーザーがコンピューターデバイスに求めるものが急速に変わりつつあることは明らかでした。

Windows 8 のユーザーエクスペリエンスと機能のデザインに影響を及ぼしたトレンドについて、以下に一部をご紹介します。

1.常時接続。

通信環境はユビキタスになりつつあります。現在のファイル中心の Windows ユーザーインターフェイスは、通信はオプションの機能であり、限定的であり、ときどきしか行われないという想定の下にデザインされました。しかし現在、ユーザーが PC で行おうとする操作のほとんどすべては、インターネットに接続することが前提となっています。公共の場でも Wi-Fi を利用できるケースが多くなり、モバイルブロードバンドネットワークへの接続に対応した PC の数も増えています。かつて通信は特殊な環境でしたが、今では常識になっています。

2.ファイルではなくユーザーを中心としたアクティビティ。

人々が PC で行うアクティビティの種類は大きく変化しています。文書作成や創作のような "伝統的" な PC の使い方と並行して、読むことや交流することに費やされる時間が増え、知り合いの近況、写真、考えを追いかけたり、短いメッセージを頻繁にやり取りしたりすることが多くなっています。オンラインでの活動は流れが速いので、遅れずに付いていくために PC を積極的に活用することになります。このような刺激的なアクティビティの大部分は Web ブラウザー内で行われ、HTML とその他の Web テクノロジを利用して構築されています。

3.デスクトップ PC に対するモバイル PC の台頭。

よく購入される PC の種類は、従来のデスクトップ型を離れ、ノート PC やタブレットなどのモバイルフォームファクターへと急速に移行しています。パワーのあるデスクトップ PC は、拡張性の高い PC を使って最大限のパフォーマンスを引き出したいユーザー (ビデオ編集者、金融アナリスト、科学者、ゲーマー、PC 愛好家など) にとっては引き続き選択肢として残りますが、大部分のユーザーは軽量で携帯しやすい PC を求めています。

2009 年には、世界中の市場におけるデスクトップ PC の割合は 44%、ノート PC は 56% でした。それからわずか 3 年後、PC の販売台数の 61% 以上はノート PC になり、その傾向はさらに強まっています。これは、販売された Windows PC をすべて測定した結果から読み取られた世界的な傾向です。米国で今年 PC を購入する消費者は、76% 以上がノート PC を購入すると見込まれています。一方、2012 年に米国で販売されるデスクトップ PC の絶対数は、タブレットよりも少なくなると予想されます。このように、それぞれのフォームファクターの役割は著しく変化しています。ビジネスにおいても、今やノート PC の販売台数は 2 倍以上に伸びています。

最近 2 月にバルセロナで開催された Windows 8 Consumer Preview イベント (英語) のビデオは、撮影から演出、編集、制御まで、すべてノート PC だけで行われました。その多くはきわめて高性能なノート PC で、画面領域を広げるためにセカンダリモニターを接続していましたが、これが数年前だったら、イベント用にデスクトップ PC を積んだトラックを引き回しているところでした。軽量で薄く、持ち運ぶことのできる PC だからといって、負荷の高い専門的な作業に向かないほどパワーや性能が不足しているものばかりではありません。

4.PC とクラウドの両方に保存されるコンテンツ。

ユビキタス通信環境とノート PC の流行に伴って、ユーザーのコンテンツは PC からクラウドサービスへと広がりを見せています。SkyDrive のような専用のストレージサービスにとどまらず、Facebook や Flickr などの写真、家族と見るために Vimeo にアップロードした動画、クラウドサービスに保存されてストリーミングされる音楽もあります。自宅の PC 上にあるビデオ、写真、音楽は GB 単位で増加し、場合によっては TB 規模にもなります。ユーザーのコンテンツはどこにでも広がり、最近ではだれもが常に高解像度カメラ (携帯電話に搭載) を持ち歩いている状態なので、日々生成されるコンテンツの量は急速に増え続けています。最大 100 GB ものクラウドストレージを提供する SkyDrive などのサービスにより、PC やアクセスできるリソースに対するユーザーの考え方は大きく変わりました。

2009 年、私たちはいくつかの重要な点に気付きました。このようなトレンドのすべてに共通しているのは、ユーザーが PC に期待することや想定しているシナリオが変わり始めたという点です。PC が文書作成、入力、創作、制作に世界一適した道具であることは変わりませんが、ユーザーによる PC の使い方の幅は日増しに広がり、さまざまなことが PC 上で行われるようになりました。そして、携帯電話のように使える PC を求める声が出始めました。つまり、ネットワークに接続され、持ち運ぶことができ、バッテリー寿命が長く、ユーザーとアクティビティに重点が置かれ、常に最新の情報を確認できる PC が必要になってきたのです。

そのころモバイルデバイスでは、開発者がアプリの開発に時間を費やして経験を積み重ねたので、アプリがどんどんリッチになっていました。その過程でモバイルプラットフォームには、既に Windows に存在していた API と機能が次々と追加されていきました。

私たちがこのトレンドの先頭に立つためには、Windows のエクスペリエンスを刷新する必要がありました。これまでの歴史の中で同様の時期が何度も訪れたように、私たちは Windows のエクスペリエンスを進化させなければなりません。つまり、現在ユーザーが使っている機能を改良するだけにとどまらず、将来の PC の使い方を予想して開拓し、Windows の使用感を時代に合うように新しくし、今後数十年間にわたるプラットフォームと開発者のイノベーションの基盤を確立して、PC を世界一魅力的で役に立ち、気に入られるデバイスにすることが必要でした。

Windows 8 は、新しい機能、新しいハードウェア、新しいアプリ、新しいシナリオで構成される未来の世界を見据えています。Windows 8 は、10 億人のユーザーに新しい体験を、別の 10 億人には初めての Windows エクスペリエンスを提供します。

Windows 8 のユーザーエクスペリエンスの目標

新しいエクスペリエンスをデザインするにあたり、私たちが求めていた特性を実装するために、いくつかの明確な目標が浮かび上がりました。

1.高速かつ滑らか。

昨年 Windows 8 に関する記事を追いかけていた方は、間違いなく "fast and fluid" (高速で滑らか) というフレーズを見聞きしたことがあると思います。これは最近作り出された "マーケティング" 用のキャッチフレーズではありません。これらの単語は、Windows 8 の新しいユーザーインターフェイスの精神を定義するために使われた設計言語 (design language) (英語) の一部です。Windows 8 をひとことで表すとしたらこのフレーズになり、私たちの目標は、このフレーズに合った製品を作ることです。

"高速で滑らか" という目標は、中核となるいくつかの特徴を表します。つまり、UI は応答性が高く、十分なパフォーマンスで動作し、美しく、アニメーション表示されなければなりません。あらゆる UI 要素はどこからともなく現れ、画面上で不要になったらどこへともなく消え去ります。最も本質的な操作が重視され、余計な質問やメッセージで中断されることなく完了できなければなりません。必要のないものは目に入らないようにする必要もあります。

さらにこの目標は、Windows の使用感を滑らかで軽快にすることも意味します。たとえば、画面の端から指でスワイプしてコントロールを表示する操作が、滑らかで自然、かつ楽しく感じられなければなりません。人間の指はそのように動くようにできているのです。たとえば、画面の上から下へドラッグしてアプリを閉じるときも、タイルを画面下部へドラッグしてズームした後、スタート画面の別の場所へ移動するときも、効率的に動作するだけでなく、気持ちのよい操作感でなければなりません。

2.長いバッテリー寿命。

現在、ほとんどの Windows PC はバッテリーで動作するようになっているため (近いうちに大多数がそうなるでしょう)、長いバッテリー寿命は必須要件です。最初の Windows プログラミングモデルが作られたころは、どの PC も常に電源に接続されていました。電源の管理やバッテリーの消耗という概念はありませんでした。このため、プログラムは必要なことを何でも自由に実行できました。当時のプログラムは、いったん実行されたら、ユーザーが操作しているかどうかにかかわらず連続的に動き続けます。システムのメモリや CPU がすべて使い果たされることも、毎秒ごとにディスクに書き込みが行われることもあり得ました。抑えの利かないプログラムでは、バッテリーが使い尽くされる可能性もありました。

従来、PC ソフトウェアの設計では CPU を最大限に利用することが重視されてきました。これは "MIPS が低かった" からです。しかし現在では、CPU の使用状況を綿密に調べ、バッテリー寿命の節約または消費にどのような影響を及ぼしているかを理解することが求められています。これは、モバイル環境における新しいエンジニアリングトレードオフです。Microsoft では主にメモリ消費量を減らすことに力を入れてきましたが、今ではバッテリー寿命を改善することにも焦点を当てています。さらに、高速で滑らかなユーザーエクスペリエンスも実現する必要があります。つまり、さまざまなプラットフォームとさまざまなハードウェア構成に対応しながら、メモリ消費、CPU、GPU、パフォーマンス、バッテリー特性のすべてを同時に最適化しています。実際には、モバイル OS を構築するのか、モバイルデバイスでも使われることがある現代的な OS を構築するかという点がエンジニアリングトレードオフになります。

バッテリー寿命を長く保つことの重要性が認識されると、エクスペリエンスに関して新たな局面が浮かび上がりました。たとえば、Windows エクスペリエンスを本当の意味で刷新するためには、アプリも同様に刷新する必要があることが計画プロセスの初期の段階で明らかになりました。こうして、WinRT (英語) と新しい種類のアプリが生まれました。
デバイスのバッテリー寿命を長持ちさせるため、WinRT ベースのアプリには、アプリの状態を瞬時に保存する方法が用意されています。Windows では、アプリを瞬時に抑制して CPU とメモリが消費されないようにすることができます。このとき、ユーザーがアプリで行っていた内容が失われる心配はありません。アプリの再開時には、中断した状態から使い続けることができます。ユーザーにはアプリがずっと動き続けていたように見えても、技術的には、バックグラウンドでプログラムが一時停止または終了されています。

一般に、携帯電話やタブレットの画面には一度に 1 つのアプリしか表示されませんが、これには理由があります。このようなデバイスは伝統的に画面が小さいからというだけではありません。ユーザーは 1 つのソーシャル更新しかしないからでもありません。"娯楽用のアプリは画面全体を使うから" でもありません。"一度に 1 つ" であれば、OS がデバイスのバックグラウンドのアクティビティを管理し、ユーザーが実際に操作しているアプリ以外はバッテリーを消費しないように制御できるからです。

しかし、デスクトップでは引き続きマルチタスキングに対応したとしても (かつ改良されたとしても)、Metro スタイルエクスペリエンスで "一度に 1 つ" しか実行できないのでは制約として大きすぎ、マルチタスキングに対応してきた Windows の歴史にもそぐわないと思われました。そこで Windows 8 のスナップ機能が生まれました。この機能を使えば WinRT ベースのアプリを 2 つ横に並べて実行できるので、Web を閲覧しながらビデオを見たり、メールをチェックしながらビデオチャットを行ったりすることが可能になります。さらに、幅広い種類のアプリをバックグラウンドで処理するためのしくみ (英語) とバックグラウンド通知機能も作成されました。これらも Windows に固有の機能です。

下の図では、マップアプリの横に Windows 8 のメッセージングアプリがスナップされています。タブレットでも 2 つのアプリを同時に実行できます。

3.強力で洗練された Windows 8 アプリ。

Windows 8 のアプリは、バッテリー寿命を長持ちさせるように最適化されているだけではありません。これらのアプリは美しく、ユーザーを夢中にさせ、画面上のすべてのピクセルを使ってコンテンツを表示します。長年にわたり、Windows には、リリースのたびにボタン、ウィジェット、ガジェットなどのクロムが画面の端やウィンドウに追加されてきました。Windows 8 はこの流れに逆らい、Windows 自体は舞台裏に下がり、アプリのコンテンツをクロムよりも前面に押し出します。

どのアプリも、その真髄を表すためのリッチなキャンバスを持っています。ニュースアプリを使っているときは、ニュースに本当に集中することができます。ソーシャルネットワークをチェックするときは、コンテンツが美しく巧みに表示され、時間を忘れるほど夢中になるでしょう。ゲームをプレイすれば、そのゲームに完全に没頭してしまうに違いありません (もっとも、ゲームの中には以前から全画面表示で動作するものもありました)。

時間と共にアプリが充実していけば、写真編集、ドキュメント作成、財務管理、その他効率が重視されるあらゆる専門的な作業にも集中して取り組めるようになります。もちろん、現在人気のあるプロフェッショナル向けツールを使っている場合は、全画面表示でどのように動くかを試して、現状のままでも十分に集中できるかどうかを確認できます。また、アプリどうしを連携させる新しい手段として、コントラクト、選択機能 (英語)、その他の多数のアプリ間連携機能 (英語) (いずれもチャーム (英語) からアクセス可能) のようなユニークなアプリ構造が取り入れられています。これらの機能は、アプリ間の大量のデータ転送から、電子メールを使った手軽なリンク共有まで、あらゆる用途に対応します。これらのアプリ間連携機能 (より重要な意味では API) は、Windows 8 にしかない優れた部分です。

Windows 8 アプリは、それぞれが得意とするシナリオに合わせて調整された専用のアプリです。この点は従来のデスクトッププログラムと異なります。従来のデスクトッププログラムでは、多くの場合、強力な機能が大量に搭載され、関係のある機能が幅広くカバーされていますが、目的の機能を見つけるのは容易ではありません。Windows 8 アプリは、特定の分野に秀でることを目的とし、対象とするシナリオを絞って真に優れたエクスペリエンスを提供します。

開発ツールとシステム管理ツールの歴史を振り返ると、大規模な統合アプリよりも "簡易言語" (英語) (または "小さいツール") というアプローチの方が、アプリの入手方法と使い方を簡単にできることに気付きます。Windows ストアの豊富な機能や検索に対応したスタート画面は、Windows 8 のたくさんのアプリを入手しやすく、見つけやすく、使いやすくするように設計されました。

それぞれのアプリでは独自の個性、ブランド、コンテンツが表現されますが、"Metro スタイル" のデザインエクスペリエンス全体との調和は保たれます。優れた Windows 8 アプリは共通のレイアウトグリッドに沿って表示される (英語) ので、アプリを切り替えても、PC としては滑らかで調和が取れているように感じられます。共通のタスクを実行する方法も標準化されています。タッチでは、端からスワイプするとコマンドが表示されます。マウスでは、画面の角をポイントします。画面の左下隅をポイントすると、どのアプリからでもスタート画面に移動できます。右クリックすると、使用中のアプリに応じたオフスクリーンコマンドが表示されます。アプリ内では、設定、検索、共有の各機能を常に同じ場所 (チャーム) から呼び出すことができます。この操作方法はどのアプリを使っている場合でも変わりません。アプリ間で一貫性を保ち、常に同じように動作する部分を用意することは本当に重要です。基本的な操作は最初に覚える必要がありますが、いったん理解すれば、システム全体を同じように使うことができるのです。

WinRT アプリは、小型の 7 インチ画面はもちろん、大型のデスクトップモニターにも、壁掛けサイズの大画面テレビにも適切に対応します。バルセロナでの Consumer Preview の発表イベントでは、下の写真のように、82 インチのタッチスクリーンでマップアプリを使う場面がありました (ビデオもご覧いただけます。1:13:00 付近から始まります)。

これらのアプリは、最初の設計の段階から、きわめて高密度のディスプレイを持つデバイスにも対応できるように考慮されました。また、マウス、キーボード、タッチ、ペンのどの入力方式を選んだ場合にも使いやすいように設計されています。WinRT アプリの設計には将来性があり、ハードウェアデバイスとユーザーの要望がどのように展開されても対応することができます。

すべての WinRT アプリは Windows ストアを通して提供されるため、検索もインストールも安心して行うことができます。アプリは AppContainer と呼ばれるローカルサンドボックスで実行されるので、アプリが原因で PC が改変されたり破損したりする心配はありません。アンインストール時にはきれいに削除され、痕跡が残ることもありません。

4.自分専用の画面にできるライブタイル。

新しい Windows 8 アプリの真髄はタイルにあります。最近のユーザーのニーズに応えるには、生の情報をかいつまんで入手することが重��になってきています。自分のタイムラインに書き込みがないか。新しい電子メールは届いていないか。昨日のパーティの写真が投稿されていないか。何か大きいニュースはないか。試合に勝ったのはだれか。提出した経費報告書は承認されたか。自分のハイスコアが抜かれていないか。自分の番はまだか。次の会議はいつか。好きな作家の新刊が予約可能になったか。在庫が少なくなっていないか。交通状況はどうか。

今日では、実に多くの人々が各自のデバイスを使い、Web サイトや PC 上のプログラム、携帯電話のアプリをめまぐるしく切り替えて、何か新しいことはないかとチェックしているところを見かけるようになりました。

タイルは、このような情報を 1 か所でまとめて確認できるようにデザインされています。クリック 1 回、タップ 1 回、またはキーを 1 回押すだけで、Windows 上のどこからでも目的の情報を見ることができます。アプリを開く必要もありません。現時点の Consumer Preview では、利用できるアプリが非常に少ないうえ、それらの多くは魅力あるタイルの完成に向けてまだ開発中の段階にあるため、タイルの動作を完全に思い浮かべるには想像力を働かせる必要があります。

この画面領域は、根本的に異なる概念を 1 か所に集め、それぞれを実際に使われるアプリに結び付ける場所と見なすこともできます。現在の Windows では、画面下部の時計の近くにアイコンの並ぶ通知領域があり、それらのアイコンから通知が表示されるようになっています (各アイコンでは別々のインターフェイスが使われ、通知を止める方法もさまざまです)。バックグラウンドでは別のプロセスが静かに (そしておそらく密かに) 実行され、あまり適切とは言えないタイミングでユーザーに通知を表示しますが、そうでない間はバッテリーなどのシステムリソースを消費しています。Windows Vista で導入されたガジェットには、もっと一貫性のある UI サーフェスを提供するという期待が込められていましたが、私たちが最も重視していたアプリとサービスに適合させることはできませんでした。

Windows 8 の一般リリースが近づき、お気に入りのアプリがすべて利用可能になってタイルとして表示されれば、スタート画面は個人用のダッシュボードに早変わりし、気になる情報をひとめで確認できるようになります。コンピューティングエクスペリエンス全体を 1 つのビューにまとめることも不可能ではありません。ビューの整理と制御はユーザーが行うことができます。

スタート画面にはアプリ内のコンテンツもピン留めできます。知り合い、メール、フォルダー、アカウント、Web サイト、本、アルバム、歌手、映画、顧客、スポーツチーム、都市など、何でもかまいません。気になる情報をすべて効率よく参照して、いつでも最新情報をチェックできます。タイルは未来であり、アプリや Web サイトの新鮮なコンテンツを求めているユーザーにぴったりの機能です。既にわかっていることしか表示されない道路標識が、アクティブでカスタマイズ可能な掲示板に置き換わり、道路状況、交通警報、可変車線などの情報を表示するようになったところを想像してみてください。ちょうどそれと同じように、PC が最新情報を伝えてくれるようになるのです。アイコンでアプリを表すのはもはや古い方法です。

5.アプリの連携による時間の短縮。

既に述べたとおり、人々は広範囲にわたる Web サイト、クラウドサービス、アプリ間を行き来し、さまざまな場所でコンテンツを利用するようになりました。この結果、ユーザーの情報はあちこちに分散しています。メイン PC に保存される情報もあれば、アプリやクラウドサービスの内部に取り込まれ、そのアプリや Web サイトからでないとアクセスできない情報もあります。

このため、すべてがローカル PC に保存されていた過去に比べて、多くの場合は一般的な作業を完了するまでのプロセスが複雑になっています。

たとえば、Skype での通話中、先週のショーの写真を相手に送信したくなったとしましょう。その写真は携帯電話で撮影したもので、Yammer に投稿してあります。

現在これを行う一般的な手順としては、Web ブラウザーを開き、Yammer にログインし、メインページに移動し、[Images] (画像) をクリックし、目的の写真を見つけてクリックして選択します。その写真を右クリックし、[Save As] (名前を付けて保存) をクリックして、ハードドライブに保存します。それから Skype に戻り、[Attach] (ファイル送信) をクリックし、先ほど写真を保存したハードドライブ上の場所に移動し (覚えていますように)、その写真をクリックして添付します。この操作の完了までには少なくとも 8 個のステップがあります。そして、写真のコピーは 2 つになってしまいます。1 つは Yammer 上にあり、同じ写真が PC のどこかにも保存されます。重複するファイルを見つけて移動または削除するには、PC についての知識が必要です。写真を共有するだけの簡単なシナリオのつもりだったのに、"ファイル管理" という面倒な作業になってしまいました。

もっと簡単な方法があり、それこそが Windows 8 アプリの便利な点の 1 つです。Windows 8 アプリでは、他の Windows 8 アプリとデータを共有することができます。それぞれのアプリが相手のアプリを知っている必要はありません。

先ほどのシナリオについてもう一度考えてみましょう。今回は Skype 用と Yammer 用の Windows 8 アプリを使うものと想定します。Skype で [Attach] (ファイル送信) をクリックすると、選択機能の画面になり、ローカルの写真がすべて表示されます。今回は Yammer アプリがインストールされているので、すぐに Yammer 上の写真に切り替えることもできます。目的の写真をクリックすると Skype で添付されます。これで完了です。たったの 3 ステップ、先ほどより 5 ステップも少なくなりました。

他の OS では、現時点で人気の高い 1 ～ 2 か所のサービスをハードコーディングすることでこのようなタスクを効率化しようとしていますが、Windows 8 のアプローチはより便利で柔軟性が高く、将来性があります。Windows 8 の方法では、OS に "焼き込まれた" 少数の既知のサービスに限定されることはありません。

新しい Windows 8 アプリはすべて、インストールされている他の任意のアプリ (およびアプリが接続に対応している各サービス) との間で選択、共有、保存を行うことができます。これは OS におけるアプリの動作の改革と言えます。Windows は、異なるアプリを結び付ける "のり" の役目を果たします。ユーザーのコンテンツがどのサービスに保存されていても、クラウド上のどこにあっても、ローカル PC やホームネットワーク上のデータにアクセスするのと同じようにアクセスできます。また、サービス側としては世界中の 10 億人規模の Windows ユーザーをターゲットにできるので、Windows 8 向けのアプリを制作することはほとんどのサービスにとって有益と思います。

6.PC 間でのエクスペリエンスのローミング。

多くの Web サイトを使うときと同じように、Windows 8 PC には、オンラインアカウントを使ってサインインできます。Windows へのサインインに使われるアカウントは、Microsoft アカウントと呼ばれます。これは、既にお持ちの Windows Live ID (Xbox LIVE、Hotmail、その他のほとんどの Microsoft サービスで使う電子メールアドレス) を使うことも、有効な任意の電子メールアドレスを使って新しく作成することもできます。

いったんサインインして Windows のエクスペリエンスをカスタマイズすると、その変更が他のどの PC にも反映されるようになります。

たとえば、ロック画面の画像やデスクトップの壁紙にお気に入りの写真を設定している場合は、それをサインイン先のすべての Windows 8 PC で見ることができます。設定や色を好きなように構成した場合や、Web サイトをピン留めした場合も、その環境を持ち運ぶことができます。ゲームをしてレベル 10 に達したら、他の PC で同じ場面をもう一度プレイする必要はありません。どこからサインインしても、保存済みのパスワード、お気に入り、言語設定にアクセスできます。

Windows を細部までカスタマイズして自分好みに設定した場合も、使用する PC ごとに同じ手順をやり直す必要はありません。たとえば、お気に入りの Web サイトにサインインして設定を変更したら、その変更はどのデバイスからサインインしても保持されるのが普通です。私たちは、これと同じエクスペリエンスを Windows 8 でも実現したいと考えました。ローミング機能は WinRT プラットフォームの一部なので、Windows がシステム設定をローミングするのと同じように、アプリ開発者も簡単に自分のアプリの設定をローミングできます。ローミングは、特定のアプリやブラウザーだけのものではありません。プラットフォームの一部であるローミングは、どのアプリからも簡単に利用でき、だれでもその恩恵にあずかることができます。

7.コンピューターではなく家電機器のように動作する PC。

今日、ほとんどのユーザーは PC に満足していると思いますが、市場にさまざまなデバイスが登場するのを受け、PC に対するユーザーの考えや期待が変化していることは明らかです。ユーザーが本当に求めているのは "使える製品" です。ユーザーは、レジストリの誤動作、多数のコントロールパネル、電源のプロファイルなどを気にすることなく、ソファに座ってお気に入りのアプリやゲーム、Web サイトを楽しみたいのです。手に取って快適に使い、使い終わったら片付ける、そのような使い方が理想と言えるでしょう。

これに対して、現在の Windows は呆れるほどに構成が可能です。最も目立たない機能でさえ、コントロールパネル、グループポリシー、特殊なコマンドラインユーティリティ、解説のないレジストリキーなどを通してカスタマイズできる場合がほとんどです。これらの設定のほとんどは、ユーザーが変更できるのはもちろんのこと、PC で実行中のプログラムで何かを "調整" する必要があれば、プログラムから変更することもできます。長年にわたり軽蔑を込めて winrot (英語) と呼ばれてきた現象の多くは、ダウンロードされたお節介なプログラムが境界線を越え、システムサービス、更新ツール、バックグラウンドタスクなど、システムの速度を低下させるさまざまなものをインストールしたことに原因があります。

正しく理解した場合、あるいはマイナス面を許容してくれる人にとっては、これらは Windows の重大な機能ではなく、Windows の資産と見なされます。私たちの目的は Windows をロックダウンすることではなく、ユーザーがデバイスに期待する動作を実現するようなプラットフォームを提供することです。これらの資産は、非常に簡単に悪用されたり、意図せず誤用されたりする可能性があるため、改善が必要です。

Windows 8 の目標は、PC に対するユーザーの期待を再定義することです。よく使われる設定 (最近の携帯電話やタブレットの多くに搭載されているような設定) は新しい UI で利用できます。ただし、システム設定の大部分は、新しい Windows 8 アプリで変更することはできません (位置情報サービスの有効化、Web カメラの使用など、ごく一部の特殊な機能は例外ですが、その場合もユーザーの同意が必要になります)。

Windows 更新プログラムは、夜間の "メンテナンス時間帯" に適切な時間が生じたときにバックグラウンドで適用されます。ユーザーによる操作は必要ありません。Windows 8 アプリでは自動的に状態が保存されるので、ユーザーから見た更新プロセスは完全にシームレスになります。

SoC ベースのデバイスでは、電源ボタンにタッチして画面をオフにすると、PC は内部的に低電力モードに移行します。もう一度ボタンを押すと、デバイスはすぐに再開します。Windows 8 によって PC は、ユーザーが最近のモバイルデバイスに期待するようなエクスペリエンスを提供するデバイスになります。

従来どおりの柔軟性とカスタマイズ性を必要としている上級ユーザーは、システム内の設定項目に Windows 7 と同じように簡単にアクセスできます。設定はなくなったわけではなく、引き続き機能します。コントロールパネル、gpedit.msc、PowerShell など、PC を高度にカスタマイズできる手段はすべて変わらずに残されています。このような高度な設定の使い方がわからないユーザーは、気にせずにデバイスを楽しむことができます。これらの機能は、そのパワーを求めるユーザーのためにあるものです。

私たちが Windows 8 のユーザーインターフェイスをデザインするときに掲げていた抱負は、決して上記の 7 つの目標だけではありません。それでもこれらの説明は、私たちが認識および予想していたトレンドと、その認識がどのように新しい UI に結び付けられたかを理解していただく助けになることと思います。

第一級の入力方式としてのタッチ (他の方式と共存)

Windows は、新しい PC の使い方に常に適応し、実現してきました。

ごく初期のバージョンの Windows は、キーボードで使うように設計されました。その後、最初のバージョンの Microsoft Word にマウスがバンドルされた (英語) ことで、メインストリームユーザーのマウスへの移行が促されました。今から 25 年以上も前のことです。当初、多くのユーザーはマウスについて非常に懐疑的な見方をしていたため、この移行にはかなりの時間がかかりました。「本当のユーザーはキーボードしか使わない」という声が強かったのです (このような意見は今でもありますが、Windows 8 はキーボードにも対応しているので心配はありません (英語))。それから何年も経った今では、ポインティングデバイスのない PC を使うことは考えられなくなりました。

2001 年、Microsoft は Tablet PC を発表しました (英語)。これは、ペンで操作する新しいタイプの PC フォームファクターの "実験" のようなものでした。私たちは、特定の言語について市場で一番の手書き認識機能を開発しました。自然な "インク" と描画 (英語) を Microsoft Office などの従来のプログラムに統合する手段も考案しました。キーボードのないスレート PC への対応は初の試みでした。10 年前のテクノロジは、十分なバッテリー寿命を持つ軽量で静かな PC を制作できるほど進んでいなかったため、この新しいフォームファクターが広く受け入れられるには至りませんでしたが、Tablet PC が将来のコンピューティング像として正しい方向性を示していることは明らかでした。

このように、もともとの Windows はキーボードしかサポートしていませんでしたが、やがてマウスを使うことが前提となり、その後ペンに対応する機能が追加されました。それぞれの過程では、既存の入力方式のエクスペリエンスはそのままに、新しい入力装置が Windows UI のコアに統合されました。

当然ながら、新しい入力方式が追加されるときには、ユーザーインターフェイスの動作の一部にも変更を加える必要が生じました (たとえば、かつては Windows 3 のプログラムマネージャのように 2D グリッドのアイコンが主流でしたが、キーボードの方向キーを動かしてアプリを起動する操作は面倒と見なされるようになり、シンプルなリストに取って代わりました)。しかし、Windows Vista の時点ではマウスとキーボードが第一級の入力方式で、ペンも十分にサポートされていたものの、PC を操作する方法としては二番手だったと言ってよいでしょう。

そして現在に至ります。Windows 7 では、基本 OS にマルチタッチのサポートが導入されました。タッチは私たちにとって、きわめて重要な長期的展望です。時間が経つにつれて、Windows の操作方法としてタッチを第一に選ぶユーザーが増えていくでしょう。そして、大部分のユーザーは最終的に、マウスとキーボードのエクスペリエンスを補完するためにタッチを併用する形を選ぶと思われます。

Windows 8 の設計が始まった 2009 年には、タッチ操作の携帯電話は冷ややかな目で見られることがよくありました。キーボード搭載の iPhone のうわさが飛び交い、しばしば願望も語られました。今振り返ると、このような憶測が出るほどスライド式キーボード搭載の iPhone を望む声が多かったことは奇妙に思えます。

さまざまな業界にさまざまなニーズがあるとは言え、現在では、物理キーボードのある携帯電話を待ち望んでいる人を見つけるのは至難の業でしょう。小さいパーセンテージが絶対数としては多くの人数を表したとしても、それほどの人数にはならないと思います。

もちろん、タブレットにも物理キーボードはありません。ただし、タブレットについては少し事情が異なり、今でも物理キーボードを求めるユーザーは少なくありません。ケースやその他のアクセサリとして、タブレットにキーボードを追加する周辺機器も数え切れないほど登場しています。これはなぜでしょうか。私たちが何度も確認したところによると、この理由は、タブレットを PC の代わりとして使おうとするユーザーが多く、作業効率を上げるためにはキーボードを追加することが一番だからです。

Microsoft Office のようなソフトウェアを使う場合でなくても、数行以上のテキストを入力する必要があるときは、どうしてもスクリーンキーボードより使いやすい入力手段が欲しくなるのが現実です。ガラス面へのタッチ入力では、最大でも物理キーボードの半分程度のスピードしか出ない (通常はそれよりもずっと遅い) ので、実際問題として作業を完了するまでに余分な時間、労力、思考が必要になってしまうのです。

中には、マルチタッチ入力が自分にとって最高だと主張する人もいます。これはちょうど、T9 で大量のテキストを入力できる人がいたのと同じです。しかし広い視野に立てば、多くのユーザーにとっては物理キーボードの方が正確で信頼性が高く、高速な入力を行うことができます。したがって、OS およびアプリとしては、物理キーボードを利用できるときには妥協するべきでないというのが私たちの考えです。

携帯電話にとどまらず、あらゆる対話操作において、タッチは単独の入力方式として最も普及したユーザーモデルになりました。このような対話型システムの多くは Windows PC がベースとなっています。レジ、ATM、レンタルビデオの自販機、空港でのチェックイン、スーパーでの会計まで、タッチは文字どおりどこにでもあふれています。このような世界の中で、5 歳の子がノート PC の画面に触れても何も起こらなかったとしたら、何と言って説明すればよいのでしょうか。

PC だけはタッチ操作に対応しないコンピューターデバイスとして残ると考えるのは非論理的です。そのような意見を見ると、PC のディスプレイが一般にモノクロだったころ、カラー化に関して交わされた過去の議論を思い起します。私たちの周囲には色があふれているにもかかわらず、カラー化は仕事の妨げになると信じる人が多く、娯楽向けに限定するべきだと考えられていました (実際に Office チームでは、ツールバーが最初に採用されたバージョンの開発中、カラーアイコンの使用を巡って活発な議論が交わされました)。

数十年後 (おそらくはもっと早く)、私たちはこの過渡期を振り返り、「ねえ、PC の画面がタッチ操作に対応していなかったころを覚えてる? 今考えると変だよね」などと言い合うことになるでしょう。

優れたタッチエクスペリエンスの設計

何人かのブロガーは、Microsoft が Windows 7 でタッチの開発に投資したことに関する記事を書いています。しかし、携帯電話とタブレットのタッチエクスペリエンスが Windows ベースのデバイスをしのいだことからわかるように、結局はアプローチが貧弱でした。Windows 7 の最初の公開デモの時点でも、私たちはタッチへの対応に多大な労力を費やしていましたが、既存の Windows デスクトップソフトウェアに単純に追加する形でタッチ機能を実装するというアプローチはあまりうまくいきませんでした。マウスとキーボード向けにデザインされた UI パラダイムの上にタッチ機能を追加した結果、エクスペリエンスは後退してしまいました。

そこで私たちは一歩下がって見直しを図り、Windows 8 では、タッチ機能に対するアプローチと実装の両方を実質的に変更しました。

Windows 8 にタッチを取り入れるアプローチは、大きく 2 つの部分に分かれていました。

1.デスクトップでのタッチの改良。

私たちは、Windows 7 のタッチユーザーから寄せられたフィードバックを基に、既存のデスクトップのタッチを改良する必要があると認識していました。そこで、タッチ操作の対象を大きくし、各コントロールのサイズも少し広げると共に、あいまいさを許容する操作ロジックを追加して、サイズ変更可能なウィンドウの境界線などの共通コントロールを操作しやすくしました。

"マウス + キーボード" とタッチのどちらかをユーザーに選んでもらうというアプローチも考えられましたが、私たちはその誘惑をはねつけました。デスクトップアプリの要素では、マウスとキーボードの両方が前提となっていることがほとんどです。私たちがデスクトップのタッチエクスペリエンスをどれほど強化しても、この前提を覆すことはできず、既存のアプリインターフェイスに組み込まれている動作を変えることもできません (なんといっても、これらのプログラムの多くは 10 年以上も前から既に市場に出回っているのです)。

ただし、デスクトップではマウスとキーボードの補助としてタッチが役に立つと思います。過去の例を考えると、新しい入力方式はユーザーが最適な使い方を覚えるにつれてシームレスに統合されていくものです。たとえば、コンテキストメニュー、キーボードショートカット、ツールバー、メニューはすべて同じことを達成する手段ですが、ユーザーはそれぞれ自分に一番合った方法を選んでいます。

タッチも同じように受け入れられていくでしょう。私自身、昨年から毎日タッチ対応のノート PC (Lenovo x220 Tablet) を使っていたので、スクロールしたりダイアログボックスの [OK] または [キャンセル] ボタンをタップしたりするために画面をタッチできない状況は考えられなくなってしまいました。タッチ対応でないノート PC を使うといつも、PC の使い方を忘れてしまったように感じます。私はこのノート PC をタッチ主体で使っているわけではありませんが、操作方法の一部としてタッチは欠かせなくなっています。職場で使っている大画面モニターにも無意識にタッチしています。「この画面はデスクトップ PC につながっているからタッチできないはず」とは思いません。

2.タッチ入力に適した専用または優先的な環境の作成。

新しい UI と WinRT アプリでは、タッチはマウスおよびキーボードと並ぶ正式な入力方式として扱われます。マウスとキーボードだけで (またはキーボードだけで) PC を使うときと同じように、タッチ操作だけでも優れたエクスペリエンスを得ることができます。私たちは、タッチ操作専用のデバイスに適した新しいユーザーエクスペリエンスをデザインし、マウスとキーボードが追加された場合は、マウスとキーボードだけを使うことも、タッチと同時に使うこともできるようにしたいと強く望んでいました。ジェスチャと共にキーボードショートカットも用意されているので、ユーザーの好みと PC の対応状況に合わせて適切な方法を選ぶことができます。

一部のフォームファクターではタッチの出る幕はないという意見もあります。ゴリラ腕、指紋、画面を突いてしまうなど、すぐに指摘される問題についてのコメントには慣れています。同様の調子で語られるコメントの多くは、マウスに対する初期の拒否反応、つまり「キーボードのホームポジションから手を動かしたくない」、「手首が痛い」、「画面を見上げたら仕事に集中できない」などの苦情と根底は同じです。

キーボード付きのドックに装着されたタブレット (英語) は、人間工学的にはタッチ対応のノート PC と似ていますが、ノート PC やデスクトップ PC ではタッチはまだ新しく、特殊であることに疑いの余地はありません。ただし、タッチしか使えないわけではないという点を考慮すれば、タッチの搭載にはメリットこそあれデメリットはないと見なすことができます (私たちのデザインでは、常にタッチを利用できるという想定はしていません。タッチがないと不便に感じるようになるとは思��ますが)。

Windows 8 のデザインは、キーボード搭載のノート PC でも、外付けのキーボード (有線または無線) を接続できるタブレットでも、その中間的なものでも、自分の希望に沿った PC を持ちたいというユーザーの要望を考慮に入れています。タッチはあらゆるフォームファクターで機能し、どの入力方式をいつ使うかはユーザーの自由です。これが "Windows 8 は妥協のないエクスペリエンスを提供する" ということです。

Metro スタイルとデスクトップの共存

ここまでこの記事では、ノート PC とタブレットの人気、長いバッテリー寿命に対する必然的な期待、単なるファイルとドキュメントよりも知り合いとアクティビティが注目される傾向、どこからでも利用できるクラウドサービス、今後予想されるあらゆる PC へのタッチの普及などのトレンドを受けて、Windows 8 がどのようにデザインされたかという点を中心にお話ししてきました。

では、Windows 8 のデスクトップの役割は何でしょうか。

これは単純です。デスクトップが用意されている理由は、マウスとキーボードで使うように設計された、強力で人気の高い多数の既存の Windows プログラムを実行できるようにするためです。Office、Visual Studio、Adobe Photoshop、AutoCAD、Lightroom などのソフトウェアは広く使われており、高機能で、現在 PC で行われている作業の大部分を占めています。これを前面に持ってくることができるのは (手動で個々のウィンドウのサイズを変更したり、ウィンドウを重ねて配置したりできることも含めて)、同様の機能もプログラムもないタブレットに比べて非常に大きなメリットとなります。これらのソフトウェアに対応し、以前のどのバージョンの Windows よりも快適に実行し、できるだけ優れた環境をこれらの製品に長期的に提供することは、Windows 8 の明確な設計目標の 1 つです。

私たちはこのアプローチが間違っていないことを何度となく確認しています。他方、タブレットや携帯電話のメーカーは、"PC の機能" をデバイスに追加しようと躍起になって、印刷用の周辺機器、リモートアクセス、高解像度画面をサポートしたり、既に Windows に存在している新しい API のクラスを開発者向けに追加したりしています。さらに私たちは、これらのプラットフォームにおいて、Windows に長年搭載されていた機能に対する需要があることも確認しています。ユーザーが求めているのは、キーボードとマウスのフルサポートのような基本的なものから、複数モニター、バックグラウンド処理、サードパーティ製のユーザー補助ツールのサポートなど複雑なものまで多岐にわたります。

他のタブレットプラットフォームでは、タッチデバイス上で Windows デスクトップを実現し、Office などのソフトウェアを実行するアプリがユーザーの強い関心を集めました。このようなソリューションでは、ネットワーク経由のリモート処理テクノロジを利用して、実際の Windows PC との間で画面の画像の送信やタッチ入力のやり取りが行われます。これらのタブレットデバイスは、Windows ソフトウェアやマウスをネイティブにサポートしているわけではありません。この方法には安定したネットワーク接続が必要なため、エクスペリエンスは二の次になります。いらいらする遅延、途切れ途切れの描画、ホスト PC からの切断のような問題が発生することもよくあります。

私たちは、デスクトップをモードと考えているわけでも、過去の遺産と見なしているわけでもありません。デスクトップとは単に、一部のユーザーや特定のアプリに適した 1 つの作業環境です。これはちょうど、携帯 "電話" のユーザーが、実際にはアプリや電話をほとんど使わず、モバイル用のブラウザーとメールクライアントとして利用している場合とよく似ています。あるいは、最新型のタブレットで Web ブラウザーしか使わないのと大差はありません。

デスクトップは、大画面のモニターや複数のモニターを使い、マウス/キーボードで操作する場合に適しています。強力で柔軟性のあるこの環境では、画面上にあるウィンドウのサイズとレイアウトを広く制御することができます。

デスクトップ環境だけを使いたい場合、タッチ対応の PC も Windows ストアのアプリも一切必要がなければ、Windows 8 の多数の機能を利用することができます (英語)。Windows 7 のデスクトップエクスペリエンスが一歩進んで大幅に改良され、新しいタスクマネージャー、新しいエクスプローラー、ファイルコピー UI、クライアントでの Hyper-V、マルチモニターのタスクバーと壁紙などが追加されました。標準の機能はすべて、システムリソースの消費量が Windows 7 よりも減少しています。新しいスタート画面は、起動、呼び出し、切り替え、通知などの異なるユーザーインターフェイス要素を統一するという Windows 7 の傾向を引き継いでいます。

選ぶのはユーザーです。必要や好みに応じて、デスクトップアプリだけを使うことも、新しいアプリだけを使うこともできます (後者の場合、デスクトップのコードは読み込みさえも行われません)。または、両方の環境を混在させ、両方で動作するアプリを見つけることもできます。現在、大勢の独創的な開発者が、新しい Windows 8 アプリで新しいシナリオを実現するべく開発に取り組んでいます。しばらくしてこれらのアプリが利用可能になれば、ほとんどのユーザーが混在環境を選ぶだろうと思います。

2 台のデバイス、3 台は不要

ここで、タブレットが 1 台あると想像してください。軽量で薄型、バッテリー寿命は驚くほど長持ちし、画面は申し分なくきれいです。ユーザーは、ソファにもたれて美しく滑らかなエクスペリエンスを楽しみながら、タブレットでやりたいことをすることができます。ゲーム、ソーシャル活動、Web の閲覧、読書、写真編集、テレビの視聴など、できることはさまざまです。好きなことをしているうちに夢中になっているはずです。小さいお子様でもすぐに使いこなすことができます。

もう少し詳細な制御や効率が必要になったら、同じタブレットをスタンドに装着し、キーボードを接続するか本体から引き出して、完全な Windows デスクトップのエクスペリエンスを手に入れることができます。フル機能の Microsoft Office、複数モニター、周辺機器、そしてマウスも使用できます。

あるいは、美しい大画面と入力しやすいキーボードが搭載された超軽量のノート PC を想像してください。そのノート PC を使って現在やっていることに加えて、最新のタブレット向けに作成された新しいアプリも使えるようになります。

Windows 8 は、ノート PC とタブレットという 2 種類のデバイスを合わせたようなものです。3 台のデバイス (携帯電話、タブレット、ノート PC) を持ち運ぶ代わりに、携帯電話と Windows PC だけを持ちましょう。今までに使った PC の中で一番のタブレットまたはノート PC になるはずです。しかも、必要時には使い慣れた Windows デスクトップの機能も利用できます。タブレットを選ぶことも、ノート PC やコンバーチブル PC を選ぶこともできますが、その両方を携帯電話と一緒に持ち運ぶ必要はありません。選択を迫られることも、何を持って行くかで悩むこともありません。妥協する必要もありません。

このようなすばらしいハードウェアはまだ存在していませんが、今年の後半には一般向けに発売される予定です。これが Windows 8 エクスペリエンスの展望です。少し想像力を働かせると、このようなデバイスによって PC に対する認識がどのように変わるのかが見え始めてくると思います。

デスクトップの外観の更新

いくつかのブログ記事では、Windows 8 でデスクトップの外観がどれほど変わるかを気にする意見が見られました。

私たちは、ユーザーの皆さんが提案する "Metro 化" デスクトップの外観デザインのスクリーンショットがさまざまなサイトに投稿されているのを喜んで拝見しました。自分でデザインを考えるほど関心と情熱を寄せていただけるのはとても嬉しいことです。

Windows 8 のデスクトップの外観をどの程度更新するかについては、多大な労力を費やして注意深く検討を重ねました。大量の画像を眺め、何百ものデザインを検討しました。第一の目標は、Windows 7 のデスクトップで親しまれた雰囲気をできるだけ引き継ぎ、既存のアプリとの互換性を犠牲にすることなく、Windows との視覚的な調和を保つことでした。

最終的な決定として、デスクトップの外観は Metro スタイルに近づけることになりました。ただし、互換性を保つため、ウィンドウクロム、コントロール、システム UI のサイズは変わらずに維持されます。Aero グラスからは卒業しました。表面は平面的になり、反射は取り除かれ、目を奪うグラデーションは少なくなります。

私たちが検討した内容の一部を以下にご紹介します。

Metro スタイル UI の多くではカラフルな単色の背景に白いテキストが使われますが、Windows 8 のデスクトップでは、Windows 7 と同様に明るい背景色に黒い文字を使います。これは、既存のプログラムとの互換性を最大限にするための決定です。

Windows Vista のリリース (Aero グラスの導入) 以降、多くのデスクトッププログラムでグラスの外観が取り入れられることになりました。これにより、プログラムのテキストを読みやすくするには、ぼんやりとしたテクスチャの背景の上に暗い色のテキストをカスタム描画することが前提となってしまいました。

皆さんの中には、システムカラーが暗い背景色と明るい前景色 (Windows XP) から明るい背景色と暗い前景色 (Windows Vista) に変わったとき、互換性の問題が多く発生したことを覚えている方もいらっしゃるでしょう。これらの問題がすべて解決されるまでには長い年月がかかりました。このような互換性の問題は二度と発生しないようにしなければなりません。このため、デスクトップの色を新しいデザインに合わせることは避ける必要があります。
しかし同時に、デスクトップのウィンドウは明るく軽やかに見せたいと考えています。また、アプリのコンテンツから注意をそらすことのないクロムスタイルを求めています。Metro スタイルアプリについては、"クロムレス" (タイトルバーや境界線がなく、周囲に Windows UI が表示されることもない) であると説明してきました。これとは反対に、デスクトップアプリには大量のクロムがあります。これらのウィンドウをすべて画面に追加していたら、ユーザーの注意は大量のクロムに奪われてしまいます。Aero は、アプリのコンテンツに注目を集め (英語)、Windows システムの UI は背後に下がるようにデザインされました。これは現在でも意味を持っており、私たちは Aero の先へ進もうとする中で、この目標を見失わないように心がけています。
Windows 7 との視覚的な互換性。Windows 7 は現在のところ、最もよく知られ、よく使われているバージョンの Windows です。Windows 8 デスクトップの外観は、なじみのある Windows 7 デスクトップの外観とかけ離れないように意識的にデザインされました。このため、デスクトップを中心に使うユーザーも、新しい環境にすぐになじんで快適に作業を行うことができます。

Windows 8 では、デスクトップの外観にさまざまな改良が加えられています。私たちは、これまでどおり使い慣れたデスクトップを提供すると同時に、新しい設計言語からいくつかのアイデアを取り入れ、適切な場面に適用したいとも考えました。

私たちは、ウィンドウとタスクバーのクロムを更新するにあたって "クリーンで鮮明" という原則に従いました。グラスと反射の効果は廃止されました。ウィンドウやタスクバーの端は直線的になりました。クロム内のボタンに使われていた光彩やグラデーションはすべて取り除かれました。不要な影や透過効果が削除されたので、ウィンドウの外観はより鮮明になっています。既定のウィンドウクロムは白く、軽やかで上品な見た目を演出します。タスクバーは引き続きデスクトップの壁紙に溶け込むように透けて表示されますが、全体的にはこれまでよりシンプルになっています。

しあげに私たちは、ボタン、チェックボックス、スライダー、リボンなど、ほとんどの共通コントロールの外観を更新しました。クロムの変更と調和が取れるように��丸みのある端を直線的に変え、グラデーションを取り除き、コントロールの背景を平面的にしました。より現代的かつ中立的に見えるように色も調整しました。

このような外観上の変更のごく一部は今後の Release Preview で感じ取ることができますが、大部分はまだ一般向けには実装されない予定です。すべてをご覧いただけるのは最終版の Windows 8 になります。

Windows 8 の使い方の習得

Consumer Preview を試用したユーザーの何人かからは、"習得しやすさ" に関する疑問が公に投げかけられました。UI が新しくなるということは、PC に新しい概念が導入されることを意味します。特に、端からのスワイプ (タッチ操作の場合) と画面の角への移動 (マウスの場合) はなじみのない動作でしょう。

Consumer Preview ではどちらのジェスチャも完全には機能しません。今回のように効果的なデザインとテストのために製品を公開する場合は、完全ではない機能も含まれていることをご理解ください。画面の角の判定は不安定すぎて、現状ではマウスで確実にポイントすることができず、頭にくるほどすぐにターゲットから "外れて" しまいます。この点は、社内ビルドでは既に大きく改善されています。また、Windows 7 用に設計された現行のタッチ対応ハードウェアでは、端からのスワイプが適切に解釈されるとは限りません。さいわい、Windows 8 向けに設計されたハードウェアでは端が正しく検出されるようになる予定です。私たちのデバイス製造パートナーは、長い間この機能の実現に取り組んできました。

ジェスチャは Consumer Preview よりも安定して動作し、適切な調整も加えられる予定です。では、ユーザーが使い方を覚えるにはどうすればよいでしょうか。

習得しやすさについては、近いうちに詳しい記事を投稿する予定です。そのときには、新しい概念を見つけて理解する方法と、初めて Windows 8 PC の前に座ったユーザーが戸惑わないようにするために用意されている手順について説明したいと思います。

基本的には、私たちは人々の適応力と前進する力を信じています。コンピューターの歴史の中で、人々は何度も新しいパラダイムや新しい操作方法に適応してきました。単に別の Web サイトに移動するだけでも、別のアプリや携帯電話に切り替えるだけでも、同様の適応力は必要になります。ユーザーが幸先のよいスタートを切れるようにお手伝いすることはもちろんですが、私たちは、皆さんが新しいパラダイムをすぐに理解して身に付けるものと確信しています。

今後を見据えて

Windows 8 のユーザーエクスペリエンスは、過去を尊重しながらも将来を考えたデザインになっています。Windows 8 では、PC でできること、最適なシナリオ、ユーザーによる操作方法が刷新されています。Windowos 8 では、ごく軽量で薄型のタブレットやノート PC がバッテリーで長時間駆動し、タッチ、キーボード、マウスを好きなように組み合わせて使用できます。デスクトップ PC やゲーム機にとっても、これまでで最も性能が良く、無駄が少なく、便利な OS です。

新しい Windows 8 ユーザーエクスペリエンスは、コンピューターの未来を見据えているだけでなく、その未来における Windows の役割を示すものです。私たちは、どうすれば PC を滑らかに楽しく使うことができるか、どうすればアプリどうしを連携させて日常的なタスクを単純化できるか、どうすれば気になる情報をすべて 1 つの画面にまとめて最新に保つことができるかを考え、新しい視点を切り開こうと試みました。

私たちは "収束" を信じています。テクノロジはこれまでに展開と収束を繰り返してきたので、この流れは今後も続くでしょう。ユーザーは、より高性能なデバイスを求め、持ち運ぶデバイスの数を減らしたいと思うはずです。携帯電話以外には、自宅のソファでも机でも使用できるデバイスが 1 台あれば十分です。望ましいのは、長時間持っていても疲れないくらい軽量ながら、使い慣れた高機能なソフトウェアを使って実際に仕事ができる程度の処理能力のあるデバイスです。さらに、必要時にマウスや物理キーボードを接続できる拡張性も必要です。そして、個人用に細かくカスタマイズでき、クラウドにネイティブに対応し、どこへ行っても設定とコンテンツを持ち運ぶことのできるデバイスが求められています。

Windows 8 の UI には、議論や論争を引き起こしている部分もあれば、ユーザーが理解して飲み込むまでに多少の時間を要する変更もあります。どの変更も最初は完全に理解するのが難しい可能性があり、賛成派と反対派の両方が声を上げることになるでしょう。特に、他のユーザーを見習うだけでは済まないような変更は理解されにくいかもしれません。

Windows 8 エクスペリエンスの全体像が明らかになるのは、パートナーから新しいハードウェアが発表され、ストアがサービスを開始して、さまざまな開発者が新しいアプリを登録し始めてからです。Windows 8 のすべての機能は、Windows 7 向けに設計された現行のハードウェアでも確実に動作します。そのハードウェアがタッチに対応しているかどうかは問いません。Windows 8 はノート PC やデスクトップ PC でも快適に動作するように設計されているので、Windows 7 ハードウェアでも自然に動作します。過去のバージョンの Windows を思い起こしてみてください。既存のハードウェアでも動作しましたが、新しいハードウェアなら新しい OS をいっそう堪能することができました。これは Windows 8 でも同じです。

1993 年、今ではおなじみとなった Windows 95 ユーザーエクスペリエンスが最初にデザインされたころ、PC は白くて重い物体で、ネットワークにはつながりませんでした。通常はオフィスの机の下に置かれ、常に電源に接続されていました。平均的な PC は現在の物価で約 35 万円もしました。

一方、最近の PC はキッチンや居間はもちろん、喫茶店や電車の中、車の助手席でも使うことができます。ハンドバッグにも収まります。PC はしだいに持ち運びやすくなり、いつでもネットワークにつながり、価格も低く、美しくなっています。そして、今やどこの職場にも Windows PC があります。20 年前には想像もできなかった "ポスト PC" の世界が、今ではまさに PC の定義となっているのです。

時代と共に世界は変わり、進歩していきます。Windows もまた、これまでの 27 年間の歴史を通じて変化してきたように、今後も変わり続けていきます。

Windows 8 で私たちが目指しているのは、現代的で高速で滑らかなユーザーエクスペリエンスを実現し、今後のコンピューティング環境の基盤となるプラットフォームを築くことです。従来の環境に固執するユーザーでも、タブレットとノート PC に対する考え方や、携帯型デバイスの役割についての認識を改めてもらるようなエクスペリエンスを目標としています。

ユーザーが何をする場合でも対応できるエクスペリエンスを作成し、持っていることが嬉しくなるような新しいタイプの PC を作り上げたいと思います。

Jensen Harris

これまでになく高速に起動する PC を設計する

2012-06-06T00:11:00Z

私たちは、PC の電源をオフにする必要が一度もないようにし、Connected Standby (接続維持スタンバイ) 状態で実行できるように努力していますが、それでも主要なシステムコンポーネントの更新時には再起動が必要なことを認識しています。以前、Windows の起動エクスペリエンスの再構築についてと、コアブートローダーと選択肢がどのように最新型でタッチパネル対応になったかについてお話ししました。さらに、起動もかなり高速になりました。実際にかなり速くなったので、BIOS を操作したり、代わりの方法で読み込んだりする場合に必要となる診断ツール類を有効にするには、設計について調べる必要があります。

この記事では、ユーザーエクスペリエンスチームのプログラムマネージャーである Chris Clark が、信じられないほど高速な起動エクスペリエンスについて話します。
--Steven

Windows 8 には問題があります。起動が本当に速すぎることです。

実際、かなり速いので、起動を中断するために操作する時間がまったくなくなりました。Windows 8 PC の電源をオンにしたとき、F2 キーや F8 キーなどのキーストロークを検出する十分な時間がなくなりました。まして、"セットアップするには F2 キーを押してください" などのメッセージを読む時間などありません。起動を中断して、通常行われる動作とは異なる動作を PC に指示することができなくなるのは、数十年ぶりのことです。

高速起動は、私たちがどうしても守りたい機能です。もちろん、起動を意図的に遅くして、これまで行っていたようにそれらの機能を実行できるようにするなどだれも想像できないでしょう。この記事では、これまでの操作をすべて行えるようにしながら、できるだけ高速な PC の起動を維持する新しい解決策によって、どのようにこの "問題" に対処したかについて順序立てて説明します。

速すぎて中断できない

少し時間を取って、Gabe Aul が「Windows 8 でお届けする高速な起動」という以前の記事で投稿した高速起動に関するビデオをご覧になることをお勧めします (既にご覧になった場合はもう一度ご覧ください)。このビデオでは、ソリッドステートドライブ (SSD) が搭載されたノート PC が 7 秒未満で完全に起動しています。この高速起動は、特別なハードウェアが必要なものではなく、新しい PC の機能です。既存のハードウェアでも起動時間がかなり向上しますが、多くの PC は BIOS 自体 (起動時に表示される BIOS ロゴとメッセージセット) にかなりの時間を費やします。ご想像のとおり、SSD も高速起動に寄与します。

起動全体の長さが 7 秒しかないと、ブートシーケンスを構成する個々の部分が速く終了しすぎて気付くことができません (まして中断することはできません)。起動時に何を行うかに関する決定の大部分は最初の 2 ～ 3 秒で終わります。その後は、できるだけ早く Windows に移るだけで起動が終了します。これらの 2 ～ 3 秒間には、ファームウェア初期化と POST (2 秒未満) の時間、および Windows ブートマネージャーが代替起動パスを検出する時間 (システムによっては 200 ミリ秒未満) が含まれます。これらの時間は短縮し続け、現在でさえ以前のように起動を中断する十分な時間がなくなっています。

Windows チームでは、この変化の影響を最初に感じました。特に、私たち自身が作った F8 キーの動作が最もたいへんでした。以前のバージョンの Windows (Windows 95 までさかのぼる) では、起動の開始時に F8 キーを押すと、高度な起動オプションメニューにアクセスできました。このメニューでは、セーフモードや "ドライバー署名の無効化" などの役に立つオプションがありました。私個人は、初めての PC を Windows 3.1 から Windows 95 にアップグレードしたときにこれらのオプションを使ったのを覚えています。F8 キーは、アップグレードの問題をすぐに解決して、Windows 95 を使い始めるのに役立ちました。

しかし、Windows 8 におけるハードウェアとソフトウェアの改良により、Windows が F8 キーストロークを読み取って反応するために残された時間が短くなりました。SSD ベースの UEFI システムでは、"F8 時間" は常に 200 ミリ秒未満になります。どんなに速く指を動かせても、200 ミリ秒のイベントを確実に捕らえる方法はありません。ですからタップしてみましょう。私は、社内を歩いたとき、同僚が F8 時間を必死で捕らえようとしていたのを覚えています。何度も何度もタップを繰り返しても、最終的に何とか F8 時間内にタップするまで結局何回も再起動を見ることになりました。非公式な調査を行った結果、繰り返しタップした場合の間隔は、最も優秀な人でもせいぜい約 250 ミリ秒であることがわかりました。この最良のケースでさえ、200 ミリ秒の時間を捕らえるにはある程度のでたらめさが必要です。最終的にこの短い時間を捕らえた場合でも、指が痛くなったり、時間を無駄にするだけでなく、キーボードに必死に指を打ち付けているおかしな人に見えてしまいます。

F8 キーで見られた問題は、起動時に押す他のすべてのキーにも当てはまります。たとえば、Windows 8 Developer Preview リリースでは、F8 キーを押すと修復オプション、回復オプション、および高度な起動オプションすべてを利用できるようになります。別のキーを使うと、デバッグの有効化やドライバー署名の無効化など、開発者用のオプションを利用できます。さらに、ほとんどの PC では、ファームウェアにより使用される追加のキーストロークや、POST 時にメッセージにより通知される追加のキーストロークがあります ("セットアップするには F2 キーを押してください" や "ネットワーク起動するには F12 キーを押してください" など)。POST は、これらの指示が表示されるまでにほぼ終了するようになりました。そして多くの場合、キーボードは POST のかなり後半まで機能しないため、ファームウェアがこれらのキーストロークを検出する時間がほとんどありません。デバイスによっては検出しようともしません。

それでも、これらのキーストロークはそれぞれ重要な役割を果たすため、私たちはこれまで起動時の重要な中断機能を提供するためにこれらのキーストロークを利用してきました。しかし、このどれも行う時間がなくなってしまいました。

問題の分野を定義する

私たちは、これらの問題を多くの角度から見て、全体的なアプローチによって解決しました。この試みは、開発者、テスター、プログラムマネージャーによって行われ、カーネルの最も深い部分から全体的なユーザーエクスペリエンスまであらゆることが検証されました。まず、エンジニアリングの問題としてこの問題にアプローチし、起動時にキーストロークに依存する状況やシナリオを特定し、Windows 8 の各シナリオで機能を回復する、文字どおり数十もの方法を考案しました。

そのリストからいくつかの主要なシナリオを抜粋します。

Windows が正しく起動するときでさえ、異なる動作が必要なことがあります。たとえば、USB ドライブなどの代替デバイスから起動したり、ファームウェアの BIOS セットアップオプションに移動したり、別個のパーティションにある保護された Windows 回復環境イメージ内からツールを実行したりする場合があります。一般に、以前は Windows を関与させず、主にファームウェア固有のキー (F2 または F12 キーや、なかなか覚えられない他のキー) を使ってこれらのシナリオを達成していました。
問題が発生した後にトラブルシューティングを行う必要が生じたり、発生した状況を元に戻す必要が生じることがあります。Windows には、このような状況に役立つたくさんのツールがあり、PC を更新したり初期状態に戻したりする、システムの復元を使って復元ポイントまで戻る、これまでもよく使っていたコマンドプロンプトで手動トラブルシューティングを実行する、などの作業を行うことができます。以前は、起動の開始時に F8 キーを押すことで、主に Windows ブートマネージャーからこれらのトラブルシューティングオプションにアクセスしていました。
起動時のエラーによっては、自動的に検出するのが困難です。たとえば、Windows の起動プロセスは成功しても、後で読み込まれるコンポーネント内のエラーにより Windows を使用できないことがあります。このようなケースはまれですが、ドライバーのインストールが破損しているため、ログイン画面が読み込み時に必ずクラッシュする場合などに発生します。以前の世代のハードウェアでは、キーストローク (F8 など) を使って起動を中断し、クラッシュの原因となっているコンポーネントが読み込まれる前に適切な修復オプションを表示することができました。時間の結果と共に、この方法で起動を中断するのが難しくなっていき、Windows 8 では事実上不可能になりました。
主に開発者により使用される特定の起動オプションを有効にする必要がありました (Windows の内部と外部の両方)。以前は、起動の開始時に F8 などのキーを押すことでこれらのオプションにアクセスできました。開発者を対象としたこれらのオプションは現在も重要で、ドライバー署名適用の無効化、"起動時マルウェア対策" の無効化などのオプションがあります。

私たちが焦点を当てたキー設計の原則の 1 つは、解決策が Windows 8 の残りの部分とどのように調和するかという点でした。私たちは、これらの各種起動オプションは異なるというよりは似ているため、Windows 内の異なる場所に配置してはならないと考えました。これを逆から考えると、あるタスクをどこから実行できるかを知るために、だれも Windows が見えないところでどのように構築されているかを知る必要はありません。最も簡単に言うと、私たちは "動作すればよい" と考えました。

3 つの解決策による 1 つのエクスペリエンス

最終的に、3 つの解決策を組み合わせてこれらの問題を解決しました。解決策を組み合わせることで、エクスペリエンスが 1 つにまとめられ、キーストロークを使って起動を中断しなくても問題が解決されます。

すべてのオプションを 1 つのメニュー (起動オプションメニュー) にまとめました。このメニューでは、すべてのトラブルシューティングツール、開発者用の Windows 起動オプション、ファームウェアの BIOS セットアップへのアクセス手段、USB ドライブなどの代替デバイスで起動する直接的な方法を利用できます。
PC が正常に起動して Windows に移行できない問題が発生した場合に必ず起動オプションメニューを自動的に表示する (かなり堅牢で検証された環境で) フェールオーバー動作を実現しました。
最後の点として、Windows または起動に何も問題がない場合でも起動オプションメニューを簡単に表示できる直接的な方法をいくつか用意しました。これらのメニューやオプションを "中断駆動型" にする代わりに、かなり簡単に実行できる意図的な方法でトリガーされるようにしました。

これらの各解決策により、中核となる問題のさまざまな側面が解決され、組み合わせることでエンドツーエンドの 1 つのエクスペリエンスにまとめられました。

起動オプションごとに 1 つのメニュー

起動オプションメニューの背景にある中核的なビジョンは、Windows 8 PC の起動動作に影響を与えるすべてのオプションを 1 か所から使えるようにすることです。このメニューの一部については、「Windows の起動のエクスペリエンスを再構築する」という以前のブログ記事で詳細に説明しました。この記事では、タッチ操作、Windows 8 の外観、起動を構成する多くのサーフェイスでまとめられたユーザーエクスペリエンスを実現するために起動メニュー内に加えられた根本的変更についてかなり詳細に説明されています。私の UEFI ベース PC における起動オプションメニューのスクリーンショットを以下に示します。

代替デバイス (USB ドライブやネットワークなど) での起動は、これまでキーストロークで起動を中断する必要があった最もよくあるシナリオの 1 つです。Windows 8 UEFI ベースのファームウェアでは、ソフトウェアを使ってこれをトリガーできるようになりました。これらのデバイスでは、起動オプションメニューに [Use a device] (デバイスを使用) ボタンが表示されるようになり、この機能を直接利用できます。上の画像からわかるように、この機能は他の起動オプションと並んで表示されます。Windows では、代替デバイスから起動する場合にキーストロークで中断する必要がなくなりました (ここでは、起動時にキーストロークを使わなくても起動オプションメニュー自体を表示できると仮定してください。この点についてはすぐに説明します)。

これと同じメニューに、UEFI ファームウェアの BIOS セットアップ (これがサポートされる Windows 8 UEFI ハードウェアの場合) で直接再起動できる新機能を追加しました。以前の世代のハードウェアでは、BIOS セットアップに入るための指示は POST で "セットアップするには F2 キーを押してください" などのメッセージとして表示されていました (これらのメッセージは、多くの場合他のどの種類の UI よりも長く PC に表示されていました)。これは、Windows 8 より前に作られたシステムにも当てはまり、これからも機能し続けます (主に、これらのデバイスの POST には数秒かかるためです)。一方、Windows 8 UEFI ベースの PC では、このようなキーストロークを使えるほど POST が長く続かないため、新しい UEFI ベースの機能ではこのオプションが起動オプションメニューに追加されています。このメニューの他の項目を調べた後、私たちは PC を UEFI ファームウェアの BIOS セットアップで再起動するボタンを [トラブルシューティング] ノードの [詳細オプション] グループ内に配置することにしました。

以前の非 UEFI デバイスについて簡単に述べると、Windows 8 より前に作られた従来のハードウェアには、UEFI によるこれらの新しいメニュー機能 (ファームウェア設定での起動とデバイスでの直接起動) は搭載されません。これらのデバイスのファームウェアでは、これまでと同様に POST 画面からこの機能を利用できます ("セットアップするには F2 キーを押してください" などのメッセージを使用)。これらの従来のデバイスには、Windows 8 PC の POST を 2 秒未満で実行できる機能強化がないため、引き続きこのようなキーストロークが機能する時間があります。

次の項目は、すべての Windows 8 デバイスで表示されます (UEFI も非 UEFI も同じです)。上の画像では、[Windows Startup Settings] (Windows 起動設定) が追加されているのがわかります。新たに追加されたこの項目により、開発者用の Windows 起動オプションのエントリポイントが、統一された起動オプションメニューにまとめられ、これまで起動時に別個のキーが必要であったシナリオに対応できます。これには、"ドライバー署名の無効化" や "デバッグモード" などの項目に加え、セーフモードや他の複数のオプションが含まれています。これらのオプションの情報ページの拡大表示を以下に示します。

起動オプションメニューでは、Windows 8 PC の起動動作に影響を与えるすべてのオプションを 1 か所から使うことができます。これらのオプションを 1 か所にまとめることで、起動オプションメニューは、これらの関連する項目を使うことができる、わかりやすくてとても使いやすい、統一された場所となりました。起動オプションメニュー自体を表示できるので、Windows の起動設定の変更、UEFI ファームウェアの BIOS セットアップの表示、USB ドライブでの起動などのタスクを実行する場合に、キーストロークを使って起動を中断する必要がなくなりました。では、メニューを表示する方法を見てみましょう。

問題がある場合に起動オプションメニューを (自動的に) 表示する

Windows 8 PC で起動オプションメニューを表示する必要がある状況は、主に 2 つあります。1 つ目のケースは、問題が起きたため、PC を完全に機能する状態に復元するために修復操作が必要な場合です。2 番目のケース (次のセクションで説明します) は、問題は起きていないが、起動動作やファームウェア構成のある側面を変更したり、通常とは異なるデバイスから起動したりする場合です。

1 つ目のケースでは、何らかの問題が発生したため修復が必要です。PC ハードウェアの以前のモデルでは、起動時にいずれかのキーストロークを押すことで、ユーザー (または信頼している他のユーザー) がこのトラブルシューティングプロセスを開始する必要がありました。たとえば、Windows Developer Preview リリースでのオプションは、Shift + F8、F8、および F2 や F12 などのファームウェア依存キー (多くの場合 PC ごとに異なります) に分割されていました。

これらの各キーストロークは、トラブルシューティングの最初の手順を表しており、その後修復を行います。これらのキーストロークをすべて 1 つの起動オプションメニューにまとめることで、利用可能な多くのオプションに複数のキーを使う必要がなくなります。この利点をさらに活かすため、Windows の起動を正常に完了することができなくなったときに起動オプションメニューを自動的に読み込むことで、この残りの 1 つのキーストロークさえなくしました。

Windows 8 では、PC に Windows が読み込まれない問題が発生した場合、必ずこの自動フェイルオーバー動作により起動オプションメニューが直接表示されます。これには、起動が成功したように見えるが (Windows から見て)、実際には PC を使用できないケースも含まれます。この状況の例として、ドライバーのインストールに欠陥があるため、メインログオン画面が完全に空白で表示される場合などがあります。Windows は画面が空白であることを認識できませんが、画面を見ればだれでもこの点にすぐに気付きます。私たちは、複数回の起動にまたがってこの状況が発生したことをアルゴリズムにより検出し、起動時に Windows 回復環境 (WinRE) 内で起動オプションメニューを直接自動的に表示するようにしました。WinRE のソースイメージには、Windows のメインインストールとは別に保持されたドライバーやファイルが含まれているため、ソフトウェアの変更の影響を受けず、起動オプションメニューからトラブルシューティングを開始するための信頼できる環境となります。

そもそも、この動作により、何も問題がない場合に Windows RE で起動オプションメニューが表示される可能性があるでしょうか。2 つの状況が連続して発生する必要があるため、この可能性は確かに低くなっていますが、もちろん可能性はあります。この点を念頭に置いて、起動オプションメニューの最初の位置に目立つ [続行] ボタンが表示されるように設計し、実際には Windows 8 PC で問題が発生していない場合に抜け出すことができるようにしました。私たちは、ユーザビリティラボでこの機能を調査し、この起動オプションメニューが意図せずに表示された場合にユーザーが何を行うかを調べました。[続行] ボタンが役目を果たし、誤検出の場合の重要な回避方法となっていたのを見て安心しました。

状況によっては、Windows 8 は問題の内容に応じてより具体的な処理を行うことがあります。たとえば、コアブートシーケンス自体が完了しなかった場合、自動的にもう一度試行されます。2 回目も成功しなかった場合、Windows RE が自動的に読み込まれ、特殊な起動修復ツールが起動されます。このツールは、起動プロセスの多くの問題を修正できるようにカスタマイズされていますが、起動修復ツールが成功しなかった場合のため、他のすべてのトラブルシューティングツールを使うことができる手段も起動オプションメニューに用意しています。

これらの自動検出動作により、Windows 自体を正しく読み込むことができない場合でも、Windows 内の修復および回復ツールを常に利用することができます。キーを押したり、何らかの操作を実行しなくても、必要な場合に Windows RE が自動的に読み込まれるため、起動オプションメニュー自体からトラブルシューティングツールを使って修復および回復することができます。

必要な場合に起動オプションメニューを表示する (問題が起きていない場合も含む)

エラーがない状況でも、Windows 内から起動オプションに移動できる簡単な方法が必要でした。メニュー項目の多くは、すべて正常に機能している場合でも必要です (代替デバイスでの起動、ファームウェア構成の変更、開発者用の Windows 起動設定の変更など)。

十分に機能する Windows 8 に論理的に適合する方法で、必要なときにいつでも起動オプションメニューを簡単に表示できるようにしたいと思いました。

一般に、私たちが好む方法は、特定のことを行う 1 つの手段を作り、その手段をできる限り良いものにする方法です。あることを行う方法が複数ある場合でも、常に主要な手段 (通常は大部分のケースに対応できる、最もよく使用される手段) があります。特定のことを行う 1 つの方法を選択することで、この方法を特定の使用シナリオセットに合わせて設計することができるので、シナリオが変わっても有用かつ便利で望ましい方法となることをある程度期待できます。ときには、主要な手段で対応できない他のケースもあります。それらのケースを解決する必要性がそれほど高くない場合、その主要な手段が唯一の方法である可能性があります。

しかし、私たちのケースでは、主要な手段を作成し、さらに 2 つの方法を追加しました。1 つ目は、必要なすべてのシナリオに対応できるようにするためで、2 つ目は既存の Windows コンポーネントとの一貫したパターンを維持するためです。

起動オプションを表示する主要な手段は、[PC 設定] の [全般] タブで [PC の起動をカスタマイズする] を選択する方法です。[PC 設定] は、設定チャームから、または特定の検索語 (起動、セーフモード、ファームウェア、BIOS など) を使ってスタート画面から検索することで表示できます。[全般] タブには、起動オプションメニューで使用可能なオプションの簡単な説明と、[今すぐ再起動する] ボタンが表示されます。この画面に表示される説明は完全に動的で、Windows 8 PC ごとに使用可能なハードウェア、ファームウェア、ソフトウェアに応じて変化します。

[PC の起動をカスタマイズする] の [今すぐ再起動する] ボタンを押すと、完全に機能するシステムで起動オプションを表示する主要な手段が開始されます。システムで通常の再起動プロセスが開始されます。次に、Windows がシャットダウンを完了し、完全に再起動して POST に入るすぐ前に、プロセス全体が一時停止し、起動オプションメニューがビューに表示されます。これは、シャットダウン/再起動プロセス中でも UI を表示できる最後のポイントです。私たちは、PC が別の POST を実行する前に目的のオプションを選択できるように、この中間ポイントで再起動プロセスを一時停止することにしました。POST が発生する前に目的の起動オプションを選択することで、再起動と POST をもう一度実行しなくても、ファームウェアセットアップやデバイスの起動に直接移動できます (選択した場合)。このメニューを使うと、必要な場合は 2 つ目の Windows インストールをすばやく起動できます。Windows により、再起動シーケンスが一時停止されて起動オプションメニューが表示されるため、これは 2 つ目の OS を起動する最も高速な方法です。

さらにすばやくアクセスするには、シャットダウンメニュー内から起動オプションメニューを表示します。Shift キーを押したまま [再起動] をクリックすると、[PC 設定] 内から [PC の起動をカスタマイズする] をクリックした場合と同じイベントシーケンスが実行されます。設定チャームを使うと Windows 8 のどの部分からもシャットダウンメニューを開くことができるので、これは起動オプションメニューを直接表示する特にすばやい方法です。この記事の最後にあるビデオを見るとわかるように、マウスを使って直線的なフロー (Windows 7 より要求が少ないフロー) でこれらのオプションを表示できるように、このコマンドを移動しました。

この Shift + [再起動] オプションをシャットダウンメニューに追加したのは、PC にサインインしているユーザーがいない場合でも起動オプションを使えるようにする必要があるためでした。起動時にキーストロークを使うことができる以前のハードウェアモデルでは、PC に物理的にアクセスできるユーザーがキーを押して起動を中断し、利用可能な起動オプションを使うことができました。これらのシナリオを維持するため、サインインしていない (ただし、PC を物理的に使っている) ユーザーが起動オプションメニューを使う方法が必要でした。

シャットダウンメニューは、この要件を完全に満たします。サインインしているユーザーがいない場合でも、ログイン画面からいつでも使うことができます。さらに、[再起動] での Shift キー修飾子の使用は、同じメニューの他の項目で Shift キーを使うパターンとも一致します。サインインしていないユーザーだけでなく、サインインしているユーザーの場合、他の多くの場所にもシャットダウンメニューが表示されることがあります。これらのどの場所でも、同じ Shift + [再起動] 動作が機能します。私たちは、シャットダウンメニューが表示されるとき��いつでも、一貫した予測可能な方法で動作することが重要であると感じていました。

シャットダウン時に起動オプションメニューをトリガーする方法がもう 1 つあります。この方法には、コマンドプロンプトから機能するというおまけがあります。shutdown.exe に新しいフラグ /o を追加しました。/o フラグは、/r (再起動) と組み合わせた場合のみ機能するので、完全な構文は以下のとおりです。

Shutdown.exe /r /o

この新しいフラグを shutdown.exe に追加したのは、Windows のこの部分の一貫性と予測可能性を維持するためでした。すべてのユーザーが Shutdown.exe を使うわけではありませんが、使う場合は、すべてのシャットダウン関連タスクをこのコマンドで行うことができます。

- Chris Clark

Windows 8 Release Preview 提供開始

2012-05-31T19:26:00Z

本日、Windows 8 Release Preview のダウンロードが 14 言語で開始されます。最後のプレリリース版である Release Preview には、Windows 8 本体と Internet Explorer 10 のほか、Hotmail、SkyDrive、Messenger に接続するアプリをはじめとするさまざまな新しい Windows 8 アプリ、そして Windows ストアをとおして提供される何百もの新しいアプリや更新されたアプリが含まれます。昨年 9 月に公開された最初のプレビューリリース以来、Windows 8 は何百万人ものユーザーによって日常的に使用されています。テスト使用しているユーザーの数はそれをさらに何百万も上回り、時間数にして何億時間もにのぼるテスティングが行われていることになります。プレリリースでのテスティングにこれだけ多くの方々が労力を注ぎ込んでくださったことに、心から感謝します。また、お寄せいただいた多くのフィードバックに対しても同じ思いです。直接のフィードバックと使用状況データという形のフィードバックによって、何百もの目に見える変更と、何万もの内部的な変更を製品に組み込むことができました。

Windows 8 の設計と開発についての対話を行う場としてこのブログが開設されたのは、わずか 9 か月前のことです。それ以来、機能や設計、それらの背景にあるものなど、Windows 8 の構築についてさまざまな踏み込んだ話し合いが行われました。投稿記事の数は 70 を超え、印刷すれば 500 ページ以上のボリュームとなっています。また、投稿されたビデオは 34 本、再生時間にして 90 分以上にのぼります。これらはいずれも、製品に携わるエンジニアたちが自ら執筆ないし製作したものです。コメントを投稿したユーザーは約 7,000 人、コメント件数は約 18,000 件です。対話に参加した Windows エンジニアは 170 名以上で、私も 200 件を超えるコメントを投稿しています (しかしながら、ある熱心な読者の方のコメント数には及びませんでした)。また、マイルストーンごとに、テクノロジに対する関心の強い何百万ものユーザーから製品利用統計情報が集まっており、これにも注意深く目を通してきました。

これが Windows の特異性です。これだけ多くのユーザーに利用される製品でありながら、開発過程のさまざまな選択肢やプロセスについてこれほどオープンに公開される製品は、他に類を見ません。設計が議論され、製品が積極的に使用される中、これがいまだ活発に開発中の製品であることを、時として忘れてしまいそうなことさえあります。肯定意見、議論、そして意見の不一致でさえも、Windows の開発において重要な役割を果たしています。チップセットからエクスペリエンスまで、Windows のあらゆる側面を刷新する今回の開発プロセスにおいては、このことがこれまで以上に大きな意味を持ちます。Windows 8 は、新しいハードウェアサポート、新しい操作モデル、新しいシナリオ、新しい API、その他多くの新しい要素を実現しながら、同時に 5 億 5,000 万台以上の PC にインストールされ、世界中で使用されている Windows 7 の使用感を継承し、さらに先へと推し進めます。Windows 8 向けに設計された新世代の PC や、Windows 8 の新しいプラットフォームを活かした新世代のアプリの登場が、すぐそこまで近づいています。

このブログでいただくレスポンスや、ブログの投稿内容を取り上げてくださった記事に対しては、チーム一同、深い敬意を覚えると共に、常に謙虚な気持ちで受け止めています。この場を借りて、改めて感謝したいと思います。

次のマイルストーンは、RTM (Release to Manufacturing) と呼ばれるものです。これまでの Windows のリリースと同様、Windows 8 でも、製品の改良は RTM まで続きます。Windows 8 Release Preview が何百万人ものユーザーにダウンロードされ、使用されていくにあたって、私たちが対応の基準とするフィードバックの種類について、ここで簡単に説明しておきたいと思います。

今後 RTM まで開発の焦点が置かれるのは、Windows 8 の品質を、私たちが重視するすべての尺度において、Windows 7 よりも優れたレベルに維持することです。これには、継続的な信頼性、コア部分のセキュリティ、PC、ソフトウェア、および周辺機器の互換性、リソース使用量などが含まれます。製品に組み込まれた遠隔測定機能をフルに活用して、セットアップから実際の使用時まで、製品利用統計情報を収集し、実際の使用環境での Release Preview のエクスペリエンスとその推移を分析していきます。また、Microsoft のフォーラムを注意深くモニタリングし、PC、ソフトウェア、周辺機器の互換性についての再現可能な問題のレポートを収集します。Windows 8 の完成に向けて、今後も製品のあらゆる側面に目を配っていきますが、特に重要な点を挙げておきたいと思います。

インストール - セットアッププロセスでは、製品利用統計情報やログの収集が集中的に行われます。Windows 8 のセットアップそのものが完了できないケースについては、当然ながら十分に情報を集めたいと考えています。Windows 7 からのアップグレードについても同様です。インストールの要件や注意事項については、ダウンロードページに詳しく記載していますので、必ずご確認ください。
セキュリティとプライバシー - 脆弱性についての対策は、当然重視されます。市場に流通する他の製品と同様の基準に応じて、対応を行います。
信頼性と応答性 - 製品のクラッシュについての報告をモニタリングし、多くのユーザーに影響する問題点を洗い出します。こういった問題の原因としては、Windows のコード、Microsoft またはサードパーティのドライバー、サードパーティのアプリなどが考えられます。クラッシュについての情報はリアルタイムで Microsoft に送信され、注意深く観察されています。Windows ストアで提供される何百もの新しいアプリについても、多くのデータが集まります。
デバイスのインストールと互換性 - Windows Update からドライバーをダウンロードしたり、製造元のセットアッププログラムをとおしてドライバーをインストールすると、プラグアンドプレイ (PnP) ID プログラムによってそのダウンロードの情報が収集されます。Consumer Preview では、何百万もの固有の PnP ID を確認することができました。また、ドライバーを見つけられなかったデバイスについても ID が収集されます。プラグアンドプレイ Web サービスは常時更新されており、各デバイスについての情報 (ドライバーの利用可否、使用手順など) へのポインターが追加されていきます。Windows 7 ベースの製品の初回インストールが成功しなかった場合に、必要となった互換モードの使用状況についても、積極的なモニタリングを行っています。
ソフトウェアの互換性 - デバイスの互換性と同じく、ソフトウェアについてもインストールプロセスをモニタリングし、インストールが成功しなかったプログラムを記録しています。互換性を改善し、RTM に向けた作業に織り込んでいくメカニズムが用意されている点は、前述のとおりです。ここでも、Windows 7 ベースの製品の初回インストールが成功しなかった場合に、必要となった互換モードの使用状況を積極的にモニタリングします。Release Preview の提供開始に向けて、これまでに世界中の何千もの複雑な商用ソフトウェアについてテストが行われています。
サービス - Windows 8 のサービス機能について引き続きテストするため、Windows Update で更新プログラムを提供していく予定です。これには新しいドライバーや Windows 8 の更新プログラムが含まれ、一部は計画的なロールアウトの一環として近日中に提供される見込みです。なお、テスト用の更新プログラムにはその旨が記載されます。また、新しいコードに重要な問題が見つかった場合に、その修正のためのプログラムが提供される可能性もあります。これらの取り組みはいずれも、サービスパイプラインを検証すると共に、Release Preview の品質を維持することに役立ちます。
新しいハードウェア - 多くのユーザーがビルド 8400 の使用を始めるにあたって、多くの新しいハードウェアとの連動性を確保する必要があります。これは、今後発生する可能性のある修正の中でも、特に重要なカテゴリと言えるかもしれません。PC やハードウェアを製造するパートナー各社では、まったく新しい PC の製作を進めており、市場にとっても OS にとっても前例のないハードウェアの組み合わせが使用されます。こういった新しい PC やハードウェアに適切なサポートを提供できるよう、Microsoft とパートナー各社が協力して取り組みを進めています。

お気付きの方もいらっしゃるように、RP そのものは、実は 1 週間以上前にコンパイルが完了しています (ビルド 8400)。このようにタイムラグがあるのは、ローカライズ版ビルドの製作や、ダウンロードイメージとプロセスの検証、大規模なダウンロードイベントに向けたネットワーク周りの準備などが必要なためです。

RTM への道筋は入念に計画されています。これは、PC を製造するパートナー各社に高品質な Windows 8 をスムーズに手渡すうえで不可欠なことです。RP から RTM までの間に製品に加えられる変更は、いずれも注意深く検討された計画的なものです。計画されている変更の中には (過去の記事でお話ししてきたとおり) ユーザーエクスペリエンス関連の具体的な機能変更もいくつか含まれます。Windows のような複雑な製品を市場に送り出すにあたっては、プロセスの終盤でこのような手順を踏むことが定石となっています。この段階でコードに加えられる変更はすべて、多くのメンバーによって精査されます。開発担当者とテスト担当者の両方がさまざまなチームから参加し、ごくわずかなコードの変更を何人ものエンジニアの手によって行っていきます。Microsoft では、大きな製品の出荷では "すべてをゆっくり行う" 必要がある、とよく言われます。RTM が近づくにつれて、品質確保の重要性はこれまでよりもさらに高まります。新しい PC への搭載や一般販売に向けて完成形の製品を準備するべく、ひとつひとつの変更に細心の注意を払いながら作業を進めています。

RTM そのものは、特定の時点というより、製品開発の一つのフェーズです。これまでのバージョンの流れをくんで Windows 8 も 100 以上の言語で提供を予定しており、現在も世界中の様々な市場に向けた最終版の製品が準備されつつあります。このプロセスが終わりに近づくとコードの変更も終了し、Windows 8 は "サービス" の段階に入ります。これ以降の変更は修正プログラム (サポート技術情報の記事) や、Windows Update 経由のサービスとして提供されます。Windows Update による修正プログラムの提供が可能になったことによって、RTM リリースのあり方も当然ながら変化しているため、Windows 7 と同様に、製品の完成から間を置かずに更新プログラムが提供されることも十分に考えられます。これは特に想定外のことではありませんが、このブログの読者の皆さんには、今後の流れを把握していただけるよう、念のため改めてお知らせしておきます。

RTM の段階に入ると、パートナー各社は最終イメージの作成と PC の製造を開始し、ハードウェアおよびソフトウェアのベンダーが Windows 8 のサポートと新しい製品を準備します。また、Microsoft でも世界各国での出荷に向けて小売り用パッケージの製造を始めます。また、エンタープライズ顧客との共同作業も続行され、ボリュームライセンス関連のツールや製品の準備が進みます。

また、既にお知らせしたように、現時点で Windows 7 搭載の PC を新たに購入された場合は、PC パートナー各社の協力により、Windows 8 へのアップグレード対応も万全です。

この段階で私たちが最も重視している尺度は、Windows 8 をあらゆる面で可能な限り高品質にしあげて提供することです。RTM のプロセスは、システム全体にわたるエンジニアリング面の整合性を確保しつつ、注意深く進められます。

PC が市場に出回る実際のタイミングは、最終的には製造元のパートナー各社が決定します。Windows 8 および Windows RT に対するフィードバックや製品利用統計情報が私たちの期待に沿ったものであれば、約 2 か月後に RTM プロセスの最終フェーズに入ります。このフェーズが滞りなく進行すれば、私たちの共通の目標どおり、歳末シーズンには Windows 8 と Windows RT を搭載した PC が市場に出回ることになるでしょう。

Windows チームを代表して

Steven Sinofsky

追記: Release Preview のシステム要件、リリースノート、アップグレード手順、その他インストールや使用手順の詳細については、ダウンロードページに記載していますので、ぜひご覧ください。

マルチモニターに関する Windows 8 の機能強化

2012-05-29T23:46:00Z

この記事では、Windows 8 のマルチモニターエクスペリエンスについて詳しく考えます。Windows 8 の最初の一般リリースとデモンストレーションでは、マルチモニターシナリオに関する Windows 7 からの改良点をお見せし、マルチモニター環境で新しい Metro スタイルアプリがどのようにサポートされるかについて説明しました。私たちは、マルチモニター機能の開発と調整を続けており、次のマイルストーンである Release Preview に向かうにつれてエクスペリエンスを大幅に強化してきました。この記事では、Consumer Preview ではまだ終わっていなかった作業のプレビューを少しお見せしますので、Developer Preview と Consumer Preview が未完成品だということを思い起こすことができます。この記事は、ユーザーエクスペリエンスチームのリードプログラムマネージャーである Mark Yalovsky が執筆しました (注: この記事は、@buildwindows8 でお知らせしたように先週誤って投稿したときから変わっていません)。
-- Steven

複数のモニターを PC に接続すると、Windows のエクスペリエンスをとても簡単に向上させることができます。2 台目のモニターを差し込むと、すぐに作業スペースが 2 倍になります。私は、これまで 10 年間マルチモニター環境を使ってきましたが、一度マルチモニターを使い始めると、前の環境には戻りたいと思いません。マルチモニター環境では、複数の画面で開けるウィンドウが増えるので、生産性が向上します。私たちは、Windows 8 のタブレットで大画面および高解像度モニターのサポート (多くの場合は HDMI 接続経由) が簡単になることにとても興奮しています。これによって、さまざまな新しいシナリオの可能性が広がるからです。

Windows 8 の計画を始めるとき、マルチモニター機能の強化は改良点の重要な分野でした。マルチモニター環境は現在、以前より確かに普及しており、多くの技術的プロフェッショナル (開発者、グラフィックスプロフェッショナル、アーキテクトなど) が使い始めています。現在、マルチモニターのサポートは事実上すべての PC ハードウェアで標準となっており、モニター価格はこれまでになく下がっています (この記事の執筆時点で、21 インチ LED ディスプレイは 140 米ドル前後で買えます)。結果として、マルチモニター環境は上級ユーザーの間でも技術的プロフェッショナルの間でも増え続けています。

Windows フィードバックプログラムで集められたデータによると、デスクトップ PC の約 14% とノート PC の約 5% がマルチモニターで実行されています。この特殊な選択データセットは上級ユーザーに偏っているので、ハイエンド用途を表している (以前お伝えした、PC 全体に目を向けた手法と比較して) 点に注意することは大切ですが、別のデータソースを補強するためにこのデータセットをお伝えした方がよいと考えました。

モニター数	デスクトップ PC	ノート PC
1	85.32%	95.64%
2	13.48%	4.36%
3	0.85%	0.00%
4	0.34%	0.00%

私たちは、マルチモニターを使うことの主な価値基準は、マルチタスクを増やしたいという願いにあると感じています。これは、デスクトップウィンドウを並べ替えて、複数のディスプレイ間で利用可能なスペースをできる限り増やすことに時間を割いている方には特に当てはまります。体験談をお話ししますと、マイクロソフトのほとんどの開発者とテスターはオフィスでマルチモニター環境を使っています。社内を歩くと、エンジニアリングチームが使っているモニター構成は 2 台から 4 台以上と、広範にわたることがわかります。この結果、2 つの重要なシナリオが得られます。1 つは、開発者が一方の画面で Visual Studio などのツールを使い、もう一方の画面で実行/デバッグプログラムを使うというシナリオで、もう 1 つのモニターを追加して、電子メールや Web ブラウズなどのサイドタスクのために確保しておくというシナリオです。

この点を念頭に置いて、私たちは Windows 8 でマルチモニターを使う方のために以下の目標を達成することを目指しました。

デスクトップでよりパーソナルなエクスペリエンスを実現する: おそらく、デスクトップで最もパーソナルな機能は、デスクトップの背景のカスタマイズでしょう。この優れたエクスペリエンスをマルチモニターでも実現することを目指しました。
モニター間でのアプリへのアクセス効率を向上する: Windows 7 では、マルチモニターを使っている方からの最も多いリクエストは、タスクバーの効率を上げることでした。
システム UI へのアクセス効率を向上する: Windows 7 では、1 台のモニターでしか [スタート] メニューにアクセスできませんでした。Windows 8 では、画面の端にコントロールを置く新しい UI が導入されたため、どのモニターからもスタート画面、チャーム、時計、最近使ったアプリに簡単にアクセスできるようにしたいと思いました。
Metro スタイルアプリとデスクトップアプリを並べることができるようにする: Metro スタイルを別のモニターで起動したり、別のモニターに移動したりし、別の画面でデスクトップアプリと並べることができます。

マイクロソフトのオフィスにおけるマルチモニター構成の例

マルチモニターでのデスクトップ背景のパーソナル化

デスクトップ背景のカスタマイズは、Windows 7 で最も人気のある機能です。実際、製品利用統計情報は 75% を超えるユーザーがデスクトップの背景をカスタマイズしたことを示しています。Windows 7 では、マルチモニター構成でも 1 つの背景画像しか選べないため、モニター間で画像が重複するという制限がありました。これは、カスタマイズの観点から制限となるだけでなく (同じ画像を 2 枚見たいと思う人がどれだけいるでしょうか)、モニターの解像度が大きく異なっていたり、向き (縦向きと横向き) が異なる場合は見た目も悪くなります。

私たちは、かなり高度な背景画像管理を行うことができるサードパーティツールを使っている方がいることを知っています。Windows 8 では、使っているモニターごとにカスタマイズできる背景カスタマイズ機能を加えました。メインストリームのユーザーには、Windows 7 でよく見られたデスクトップパーソナル化の問題に対する解決策を用意しました。

モニターごとに異なるデスクトップの背景を表示する: パーソナルテーマを選ぶと、Windows 8 によりモニターごとに異なるデスクトップの背景が自動的に配置されます。すべてのモニター間で画像を入れ替えるスライドショーを設定したり、モニターごとに特定の背景画像を選ぶこともできます。

モニターごとに異なる背景

モニターごとに異なる背景を選ぶオプション

マルチモニターのスライドショー: サイズや向きが異なるモニターを使ってマルチモニター環境を構成することはよくあります。もちろん、あらゆる写真が縦向きと横向きの両方で、またはどのようなサイズや解像度の画面でも美しく見えるわけではありません。この点に対処するため、モニターごとにちょうど合う画像を選択するスライドショーコードのロジックを追加しました。

モニターの向きに合う画像が選択されたスライドショー

すべてのモニターにまたがるデスクトップ背景: 複数のモニターにまたがって 1 枚のパノラマ画像を使うことができるようになりました。Windows 8 のパーソナル化オプションには、新しいパノラマテーマも追加する予定です。

すべてのモニターにまたがる画像を使う

すべてのモニターにまたがる画像を使うオプション (パノラマ写真など)

マルチモニターのタスクバー

ほとんどの場合、マルチモニター構成を使う主な理由はもちろん生産性を上げるためです。画面のスペースが広くなると、多くのウィンドウを同時に表示することができます。多くのウィンドウを表示できるのとは裏腹に、ウィンドウ管理はより難しくなることがあります。デスクトップでは、ウィンドウを管理する主な場所はタスクバーです。Windows 7 ブログで何人かの方が指摘されたように、タスクバーのマルチモニターサポートがないことがギャップとなっています。これは、e7 ブログにある 1 つのコメントにまとめることができます。

@AlexJerebtsov: “マルチモニターサポートが行われないのはほとんど犯罪ではないでしょうか”。

タスクバーへのマルチモニターサポートの追加に関して興味深いのは、比較的小さいユーザーグループの中にも、"正しい" 設計とは何かに関する意見がいくつかあるという点です。おわかりのように、これは新しいバージョンの Windows を設計する際によくあることです。比較的小さいことでもどのように実装すべきかに関して多くの考え方があるのです。さまざまな実地調査手法からいくつかの見解が得られています。

ユーザーは、系統立てた方法とその場限りの方法のどちらかでウィンドウ管理を行う傾向がある: ウィンドウをその場限りの方法で管理するユーザーは、ワークフローで必要になるとモニター間でウィンドウを頻繁に移動し、ウィンドウがどのモニターにあるかを把握しません。もっと系統立てた方法でウィンドウを管理するユーザーは、アプリとタスクごとに特定のモニターを決める傾向があります (電子メールは常に左に置き、ブラウザーは常に右に置くなど)。これらの 2 つの作業スタイルにはいつも明確な区別があるわけではなく、ほとんどのユーザーはときによってその場限りの方法でウィンドウを移動することがあります。
効率の向上は、常にタスクバーの目標として挙げられていた: ほぼすべてのユーザーが、タスクバーの効率の向上を望むと述べていました。マルチモニターを使って作業している人を観察したとき、ウィンドウを切り替えるという単純な動作でも、サブモニターからタスクバーのあるメインモニターにジャンプし、同じルートで元に戻るときに、頭の向きを変えて椅子を回転し、マウスカーソルの位置を変えなければならないことに気付きました。もちろん、これはマウスの効率の観点からもはっきりとわかりました。つまり、タスクバーのウィンドウを見つけて切り替えるためにマウスを動かす必要がある距離を短くしたいと思っています。
通常はメインモニターが決まっている: 多くのユーザーは、ほとんどのアプリを実行する 1 台のモニターと、付随的なタスク (プレイリストの管理、IM の送信、ビデオの再生など) のためにいくつかのウィンドウを開いておく小さ目のサブモニターを使っています。これは、新しい大型の高解像度モニターにアップグレードした後も、古いモニターを手元に残しておいたユーザーに特に当てはまります。この場合も、その場限りのユーザーはモニター間で自由にウィンドウを移動しますが、今対応しているタスクを行うためにどちらか一方のモニターを好む傾向があります。理由の 1 つは、椅子、キーボード、マウスを 1 台のモニターに直接向けて設置する方が楽だからです。
一般に、タスクバーのスペースは問題にならない: 私たちは、タスクバーを設計するとき、カスタマイズできる場所が見つけやすくても、ほとんどのユーザーは既定の設定で十分と感じることにかなり自信を持っていました。実地調査では、大部分のユーザーは、タスクバーでウィンドウがアプリごとにグループ化される既定の設定を維持していることが確証されました。何億以上ものセッションを調べた製品利用統計情報では、タスクバーボタンのグループ化を解除しているユーザーは 6% しかいないことがさらに確証されました。

マルチモニターのタスクバーオプション

実地およびラボでの観察により、ユーザーがさまざまなウィンドウ管理テクニック (常にその場限りの方法、常に系統立てた方法、両方) を使っていることがわかりました。このため、私たちは複数のマルチモニタータスクバーオプションを選び、マルチモニターを使う上級ユーザーでもデスクトップエクスペリエンスを細かく調整できるようにしました。

Windows 8 のタスクバーのプロパティ

[タスクバーボタンの表示先] の [開かれているウィンドウのタスクバー]: これは、マルチモニタータスクバーについて考えるときに真っ先に思い浮かぶオプションです。この構成では、各モニターのタスクバーにはそのモニターに表示されているウィンドウのアイコンのみ表示されます。このオプションの利点は、単純で予測しやすいことです。このオプションは、かたり系統立てた方法でウィンドウを配置するユーザーや、タスクによって専用のモニターを決めているユーザーから高い評価を得ました。一方、その場限りの方法を使うユーザーにとって、ウィンドウがどのモニターで開いているかを覚える必要があるため、この設計は十分ではありませんでした。

開かれているウィンドウのタスクバーに表示されたアプリボタン

[タスクバーボタンの表示先] の [メインタスクバーと、開かれているウィンドウのタスクバー]: この構成では、メインモニターには、すべてのモニターに表示されたすべてのウィンドウが表示される特別なタスクバーが表示されます。他のすべてのモニターには、上で説明した 1 つ目のオプションと同様に、独自のタスクバーが表示されます。このオプションでは、[開かれているウィンドウのタスクバー] モデルの明快さをいくらか残しながら、どのウィンドウにもマスタータスクバーから一貫した効率的な方法で移動することができます。メインモニターを中心に考えるユーザーには、このオプションが適していると思われます。

メインタスクバーと開かれているウィンドウのタスクバーに表示されたアプリボタン

[タスクバーボタンの表示先] の [すべてのタスクバー] (既定): この構成では、すべてのタスクバーにすべてのウィンドウが表示されます。どのウィンドウも常にすべてのモニターからアクティブ化できるため、この構成はマウスの効率が最大限に高くなるように設計されています。ウィンドウが開いている場所を把握する必要がないため、すべてのオプションの中でもこのオプションはその場限りのウィンドウ管理に最適です。一部のユーザーは他のいずれかのオプションが良いと述べましたが、圧倒的多数のユーザーに適していたのはこのオプションだけであったため、既定の設定となっています。

すべてのタスクバーに表示されたアプリボタン (既定のオプション)

Release Preview で加えられたいくつかの変更

マルチモニターで Consumer Preview を使っていた方は、スタート画面、チャーム、時計が 1 台のモニターにしか表示されないことに気付くと思います。この点に関する反響は大きく、はっきりしていました。もちろん、マイクロソフト社内でもマルチモニター環境が普及していることを考えると、この機能はまったく完璧でなかったことがわかりました。ここからは、Release Preview でのマルチモニターの使用に加えられる未公開の改良点をいくつか紹介します。

すべての角と端が機能する

Consumer Preview のマルチモニター環境では、マウスを使って角から呼び出すスタート画面や他の UI を見つけるのは簡単ではありません。それらの呼び出し領域が 1 台のモニターにしかないからです。近日公開される Release Preview では、すべてのモニターですべての角と端が機能するようになります。どのモニターの角からもスタート画面、チャーム、アプリ切り替えを呼び出すことができるようになりました。モニター 1 でスタート画面を開く場合、そのモニターの左下隅に移動するだけです。モニター 2 でスタート画面を開く場合は、モニター 2 の左下隅に移動します。これにより、見つけやすくなるだけでなく、マウスの効率が上がってマルチタスクも強化されます。アプリを起動したり、特定のモニターに移動したりするには、そのモニターでスタート画面を呼び出してアプリを起動するか、左端のアプリ切り替えツールを使ってアプリを切り替えます。

どのモニターでもスタート画面を起動できます。

どのモニターからでも最近使ったアプリに戻ることができます。

どのモニターでもチャームを呼び出すことができます。

Metro スタイルアプリを起動して任意のモニターに移動

アプリを起動して移動する方法はいくつかあります。

スタート: マウスを左下隅に移動するか、任意のモニターの右上隅および右下隅から呼び出すことができるスタートチャームを使って、どのモニターでもスタート画面を呼び出すことができます。Windows キーを押すと、スタート画面または Metro スタイルアプリが前回表示されたモニターでスタート画面が起動します。

任意のモニターからアプリに戻る: マウスを左上隅に移動することで、どのモニターのアプリにも戻ることができます。アプリの縮小版をクリックすると、そのモニターのアプリに戻ることができます。

キーボードショートカット: Windows 7 のショートカットの上に構築された新しいキーボードショートカットを導入します。Win + PageUp キーまたは Win + PageDown キーを押すと、モニター間で Metro スタイルアプリを移動できます。Win + 方向キーと Win + Shift + 方向キーを押すと、モニター間でデスクトップウィンドウをスナップして移動することにより、Windows 7 と同じようにデスクトップアプリでの作業を続けることができます。

ドラッグアンドドロップ: マウスを使って、モニター間で Metro スタイルアプリをドラッグアンドドロップできるようになりました。ドラッグアンドドロップは、全画面でもスナップされたアプリでも機能します。

共有された端にマウスのターゲットを定めやすい

マルチモニター構成には、スペースが広くなるという大きな利点がありますが、ディスプレイ間の角と端がしっかりしているというフィッツの法則の利点 (英語) がなくなります。モニターが 1 台の場合、角の UI (スタート画面、チャーム、最近使ったアプリなど) をトリガーするのはとても簡単ですが、マルチモニター構成で共有されている端に角が表示されている場合はマウスが飛び越えることがよくあります。

実際、マルチモニターでは、共有された端にターゲットを定めるのがかなり難しいことがあります。数ピクセル行き過ぎるだけで、カーソルは突然別のモニターに移動してしまいます。これは、以前のバージョンの Windows でも、最大化されたウィンドウの共有された端にある閉じるボタンやスクロールバーを押そうとしたときなどによく問題となりました。多くのユーザーは、共有された端に近づくとマウスをゆっくり動かすようにしたり、共有された端にぶつからないようなウィンドウレイアウトにすることで、この問題に対処してきました。この動作は、マイクロソフトでの使用や実地調査でもよく見られます。

Release Preview では、共有された端にある UI にターゲットを定めやすくするため、共有された端に改良モデルを導入します。

Windows 8 では、角がより重要となるため、共有された端に実質角を作って、1 台のモニターにおけるフィッツの法則の利点を模倣しました。下の図の赤い角は、それらの角がマウスのガイドにどのように役立つかを示しています。

角は、必要になったときに機能し、不要なときには邪魔にならないように設計されています。突き出た角のターゲットは高さ 6 ピクセルのため、画面の角にターゲットを定めようとしたときのみ目立つようになります。さらに、この角はカーソルがあるモニターでのみ機能します。たとえば、下の図のようにモニター 2 からモニター 1 に移動する場合、共有された端を通ってマウスを動かしてもモニター 1 の下の角は邪魔になりません。

共有された角はモニター間の移動を妨げない

共有された角は、新しい Windows 8 UI の改良点であるだけでなく、[閉じる] や [デスクトップを表示] など、デスクトップ上のコントロールにもターゲットを定めやすくなっています。この結果、共有された角にすばやく滑らかにターゲットを定めることができます。まずは実際にこの設計を体験してみてください。新しい Release Preview を使えばすぐにこの改良点に気付くと思います。

今後の展望

私たちには、マルチモニター環境の Metro スタイルアプリで行うことができることについてもっとたくさんのアイデアがあります。Windows 8 に対する私たちの目標は、マルチタスクの効率を上げ、各画面の端にある必要なコントロールにアクセスしやすくすることで、デスクトップアプリと同時に Metro スタイルアプリのすばらしいエクスペリエンスをお届けすることです。私たちは、タスクバーを複数の画面に表示するなどの新機能により、デスクトップエクスペリエンスの効率をさらに上げようとしてきました。さらに、デスクトップを使っているときも Metro スタイルアプリにアクセスできるようにしてきました。新しいアプリが開発され、開発者が没入型の全画面アプリにおいてマルチモニター構成の利点を新たな方法で活用するのを見るとき、このエクスペリエンス (および API) をさらに強化したいと思っています。

これらの新しいマルチモニター機能を活用されることを期待しています。皆さんからのフィードバックをお待ちしております。Developer Preview から Consumer Preview に、そして間もなく公開される Release Preview に移行するにあたって、フィードバックは Windows 8 の改良に本当に役立ちました。

--Mark

信頼できる Metro スタイルアプリを提供する

2012-05-25T02:49:00Z

Windows 8 と新しい Metro スタイルアプリのアプリモデルを開発したとき、主なアーキテクチャ要件は信頼して使うことができるアプリをユーザーに提供することでした。信頼できるアプリには、リソースをうまく活用して動作する、他のアプリに干渉しない、同意のもとにシステムリソースを消費する、簡単にインストールおよびアンインストールできる、などの特徴があります。これらの属性を実現するには、開発者に堅牢なプラットフォームと強力なツールセットが必要です。これは、作り直しが必要な作業であり、既存のシステム上で改良することはできません。Windows 8 は、この点で作り直されたものです。この記事では、信頼できる Metro スタイルアプリを実現するために私たちがプラットフォームレベルで行ったことの一部を詳しく説明します。この記事は、開発者エクスペリエンスチームのプログラムマネージャーである John Hazen が執筆しました。--Steven

Windows 8 の Metro スタイルアプリプラットフォーム開発における中心的な原則の 1 つは、ユーザーがアプリを信頼できることでした。これは、皆さんと私たち両方が担っている使命です。この記事では、アプリの信頼性に対する私たちのビジョンについて説明し、皆さんがアプリに計画的に信頼性を組み込むことができるようにします。

最初に、私たちが意味する信頼性とは何かについて説明します。ユーザーが Windows ストアで Metro スタイルアプリを調べているところを想像してみてください。ユーザーには、そのアプリがどんなアプリで、自分に適しているかどうかだけを考えてほしいと思います。また、実際に信頼できる、つまり、そのアプリが期待どおりに動作してシステムでうまく実行できる、許可したデータと情報だけ使う、他のアプリケーションと問題なく共存すると見なしてほしいと思います。

プラットフォームに関する私たちの目標は、信頼性のビジョンを実現するすばらしいアプリを確実に構築できるようにし、初期状態で信頼を得られるようにすることです。このために、システム全体にわたって投資を行いました。次のようなイメージです。

アプリの信頼性: Metro スタイルアプリ用の Windows 8 SDK、Windows アプリ認定キット、アプリの署名、
アプリコンテナー、評価とレビュー、ストアへの登録、スムーズなインストール、製品利用統計情報のフィードバック

この記事ではこれらの分野について扱い、最後の方ではアプリの機能について詳細に説明します。まずは簡単な概要です。

Windows ストア – ユーザーはまず Metro スタイルアプリのワンストップショップであるストアからアプリを探し始めます。ストアに登録するため、アプリの技術およびポリシー面での準拠状況 (セキュリティチェックを含む) が確認されます。ストアに公開されると、コミュニティによりアプリに評価とレビューが付けられます。同時に、登録プロセスとコミュニティによるレビューは、ユーザーが信頼してアプリを試せる環境を作るのに役立ちます。
アプリのインストール – アプリ展開に関する細かいことは皆さんの代わりにすべて Windows 8 が扱うため、ユーザーはアプリをインストール、更新、削除するときに他のアプリにマイナスの影響が及ぶことについて心配する必要がありません。
SDK – Metro スタイルアプリ用の Windows 8 SDK には、明確に定義された API セットが用意されているため、ストアの登録要件を満たし、ユーザーに最良のエクスペリエンスを提供する信頼できるアプリを構築することができます。
アプリコンテナーおよび機能 – Windows 8 では、従来のデスクトップアプリよりもアプリどうしを明確に分離できるため、互いにやり取りするアプリをこれまでより予測可能な方法で構築することができ、ユーザーエクスペリエンスがより一貫したものになります。

もちろん、私たちは、登録プロセスが操作されたり、API セットが悪用されたり、SDK の制限が巧妙に回避されたり、アプリコンテナーが機能しない可能性があることも認めています。しかし、この新しいエコシステムに対して行った投資は、ユーザーを喜ばせるアプリを構築するのに役立つと確信しています。この多次元なアプローチは、ユーザーの信頼を築くのに最も効果のある方法であり、私たちは経験から学ぶと同時に各次元を改良していきます。では、信頼性についてお話ししましょう。

Windows ストア

何人かのチームメンバーが、ストアの全体的な設計と計画について Windows ストアブログでたくさんのことをお伝えしてきました。これは、ユーザーとつながるための中心的な役割を果たすため、まだお読みでない方はぜひストアについてお読みください。アプリのエコシステムで信頼性を構築するのにストアがどのように役立つかをいくつか見てみましょう。

まず、ストアの登録プロセスによりアプリの品質と信頼性に関する一貫した基準が確立されます。Windows アプリ認定キットに含まれている技術的な準拠テストを行うと、アプリを提出する前に期待される標準を満たしているかどうかを調べることができます。皆さんや他の開発者がこれらの標準を満たすアプリを提供し続けると、ユーザーは喜んで新しいアプリを見つけて試すようになり、私たちすべてにとって強力なアプリのエコシステムができあがります。

ストアでは、ユーザーが簡単に評価とレビューを付けることもできるので、優れたアプリが目立つようになり、より多くのユーザーが高評価のアプリを信頼して試すきっかけともなります。以下のアプリの内容ページのサンプルでは、評価とレビューだけでなく、アプリの内容ページの他の 2 つの重要な要素をハイライトした部分にも注目してください。新しいアプリをインストールする前に、ユーザーはインストールするとアプリに与えられる許可を確認できます (詳細については、記事の後方で説明します)。アプリをインストールした後、アプリの内容や動作について懸念事項がある場合、ユーザーはその懸念事項を簡単に報告できるので、見つかった問題を皆さんが解決できるようにお知らせします。ニーズに最も合うアプリがどれかをユーザーが判断し、意見やフィードバックを述べることができるようにすることは、Windows 8 アプリのエコシステムの全体的な信頼性を向上させる重要な方法です。

Windows ストアのアプリの内容ページ

最後に、ストアでは製品利用統計情報データが収集され、発生したクラッシュの回数や種類など、ユーザーに生じた問題の調査に役立ちます。私たちは、自動化されたこの製品利用統計情報を確認し、アプリの動作が信頼できなかったり、ユーザーの期待と異なる部分があったことを示すものを探します。私たちの目標は、評価やレビューをとおしてユーザーから与えられたアプリの個々のフィードバックを効果的に利用するだけでなく、ユーザーのコンピューター上でアプリが実際にどのように動作しているかわかるようにし、このデータに基づいてアプリを改善する機会を皆さんに与えることでもあります。

これらの方法すべてを通じて、アプリを必要としているユーザーと皆さんをつなげ、アプリのユーザーエクスペリエンスを向上させる点で、Windows ストアは皆さんのパートナーとなります。

クリックするだけでアプリを使用可能

アプリの内容ページにユーザーの注意を引いたら、何もアプリを入手する妨げとなってほしくないと思います。Windows 8 では、アプリを入手するのに必要となるは 1 つのボタンをクリックすることくらいです。ユーザーは、一連の質問に苦労して答えたり、次から次へとボタンをクリックする必要がなくなりました。ストアにログインして、気に入ったものを見つけたら、ボタンをクリックして購入を確認するだけです。

皆さんにとって喜ばしいことに、この機能を実現するためにインストールコードを記述する必要がありません。すべて Windows 8 の一部として用意されています。Windows は、インストールを処理するだけでなく、デジタル署名を使ってストアからインストールまで (アプリが読み込まれて、ユーザーのコンピューターで実行されているときでも) アプリの整合性を確保します。アプリがデジタル署名に一致しなくなったことを Windows が検出した場合、修正されたバージョンをストアからダウンロードするようにユーザーに案内します。

Windows は、各アプリを別個の場所にインストールし、各アプリのデータと設定の場所は分離されているため、ユーザーはアプリをインストールまたは削除するときに他のアプリやコンピューターの動作と干渉することについて心配する必要はありません。ユーザーは、アプリをインストールしたり削除したりしてもエクスペリエンスが低下しないことを時間の経過と共に知るため、これまでよりも進んでアプリを試すようになります (実際、Windows 8 のコントラクトでは、アプリをインストールするたびにエクスペリエンスが向上します)。皆さんにとっては、別のアプリが皆さんのアプリのユーザーエクスペリエンスに悪影響を与えることがほとんどないというメリットがあります。

検証可能で一貫した 1 つのアプリインストールメカニズムにより、皆さんの作業が簡略化されるだけでなく、ユーザーエクスペリエンスも簡単になるというメリットがあるので、ユーザーはすばらしいアプリをこれまでよりたくさん確実に入手することができます。アプリの展開の詳細については、アプリパッケージと展開をご覧ください。

Metro スタイルアプリ用の Windows 8 SDK

アプリのユーザーエクスペリエンスが良ければ良いほど、新しいアプリや更新プログラムがリリースされるとユーザーはすぐに試すようになります。Metro スタイルアプリ用の Windows 8 SDK (英語) は、ユーザーがインストールをためらわないアプリを構築する優れた基盤となります。

私たちは、Metro スタイルアプリに用意した API セットにたくさんの考えを組み込みました。これは、Windows プログラミング環境を簡略化することだけでなく、Windows 8 の Metro スタイルアプリモデルとうまく連携することで信頼してアプリを構築できる、十分にテストされたプラットフォームを用意することでもあります。

SDK に含まれてない API を呼び出す方法を見つけようという誘惑に抵抗してください。結果的にはユーザーがアプリに対して抱く期待に背くことになります。SDK に含まれていない API は、このリリースでも今後のリリースでも Metro スタイルアプリと連携することが保証されていないため、ユーザーによってアプリが正しく動作しない可能性があります。このような API は、Metro スタイルアプリ設計の基盤となる非同期環境で正しく機能しないこともあります。さらに、このような API は、Metro スタイルアプリが通常は操作しないリソースやデータにアクセスすることでユーザーの信頼を裏切る可能性があります。これらのことから、SDK によって公開されていないインターフェイスが誤って呼び出されている場所を検出できるチェック方法を Windows アプリ認定キットに用意しました。

SDK に含まれていない API の呼び出しを隠したり、あいまいにすることはできますが、これもユーザーの期待やストアのポリシーに背くことになります。結局のところ、私たちは、皆さんのような開発者がシステムや他のアプリ/デバイスとうまく連携するすばらしいアプリを構築してユーザーを喜ばせることができるようにするためにこのプラットフォームを作成したのです。Metro スタイルの SDK を正しく扱うことは、この目的を実現するための基盤となります。

連携と分離

クリーンインストール処理はユーザーにとって重要であり、SDK はシステムとうまく連携するアプリを皆さんが構築するのに役立ちます。さらに、ユーザーはアプリとプラットフォームに高い信頼性を期待します。私たちは、従来の Windows デスクトップアプリケーションよりも Metro スタイルアプリどうしを明確に分離できるようにすることで、信頼性の目標を達成できるようにしています。Windows 8 では、各 Metro スタイルアプリが独自のアプリコンテナーのコンテキストで実行されるため、アプリとそのデータを他の Metro スタイルアプリと分離することができます。

アプリコンテナーには、すべての Metro スタイルアプリが共通して持ついくつかの特徴があります。以下のとおりです。

データと設定の専用の保存場所など、アプリ専用の環境が確保されます。他の Metro スタイルアプリが自分のアプリのデータ、設定、動作を変更することについて心配する必要がほとんどありません。
アプリが誤って Windows プラットフォーム自体の信頼性を脅かしたり、ユーザーのデータやデバイスをユーザーが望まない方法で使ったりすることがないようにします。
マニフェストで宣言を作成してアプリの内容ページでユーザーに開示することでアプリの機能を拡張する、明確に定義された方法があります。

このような明確な分離により、信頼性が高くてユーザーを尊重したアプリを記述することがはるかに簡単になります。同時に、アプリが互いにうまく連携することを私たち全員が望んでいます。Windows 8 には、Metro スタイルアプリが他のアプリやプラットフォームと連携するための、次のようなメカニズムが用意されています。

アプリコントラクト: Metro スタイルアプリを他のアプリおよびシステム UI とつなげる役割を果たします。
ファイル選択ツール (英語): ユーザーが選択したデータをアプリが操作できるようにします。
アプリ機能の宣言 (英語): 機能にとって適切な場合は、アプリがデバイスやデータをプログラムにより操作できるようにします。

これらはすべて、アプリが他のアプリやシステムとより深くかかわるための明確に定義された方法です。アプリコンテナーは、信頼性とユーザーを尊重したシステムおよびデータの利用に関してユーザーの期待に応えることができるように存在しています。アプリコンテナーの制約は、一貫した直観的なアプリの動作に関するユーザーの期待に応えるためのものであるため、アプリがアプリコンテナーの外でコードを実行できるようにする方法を使うことは、ユーザーの信頼とストアのポリシーに背くことになります。

このプレビュー期間における開発者との話し合いで、これらのメカニズムを誤解していたり、誤って誤用しているアプリが見られたため、特にアプリの機能について詳しく見ていきましょう。

アプリ機能の宣言

アプリコンテナーは、機能の宣言を使ってさまざまな方法で拡張でき、それぞれ特定のシナリオに対応するようになっています。そのため、これらの宣言は特定の条件下でのみ使うことをお勧めします。機能は、以下のように 4 つの主なカテゴリに分類されます。

データライブラリ: 既定では、アプリはユーザーのデータライブラリ (ミュージックライブラリやドキュメントライブラリなど) にアクセスすることができません。これらのライブラリはファイル選択ツールを使って操作することをお勧めしますが、まれにアプリがこれらの場所のデータを直接読み取って管理する必要が生じるケースがあります。
デバイスアクセス: 既定では、ほとんどのユーザーがプライバシーを脅かすと考えるデバイス (Web カメラ、マイク、GPS など) をアプリが使うことはできません。アプリがそれらのデバイスを必要とする場合、その目的を宣言した上でユーザーの同意を得る必要があります。
ネットワークアクセス: 既定では、アプリはユーザーのネットワークにアクセスすることができません。ほとんどのアプリはインターネットとやり取りするため、この特定の機能は Metro スタイルアプリのすべての Visual Studio テンプレートで有効にしました。アプリがインターネットアクセス以上のことを必要とする場合、以下のオプションについての説明をお読みください。
ユーザー ID: これらの機能を使うと、特定のユーザーの企業ログイン情報や、ユーザー ID に関連付けられた証明書に直接アクセスすることができます。めったにありませんが、特定のエンタープライズアプリでこれらの機能が必要になることがあります。認証にスマートカードが必要な銀行取引などのシナリオで使う必要が生じる可能性があります。

これらのどのカテゴリの機能も、Visual Studio のマニフェストデザイナーでチェックボックスをオフにするだけで簡単に宣言できます。しかし、これらの機能はアプリのシナリオを実現するために必要な場合のみ追加してください。Consumer Preview では、すべての機能、またはアプリに絶対必要とは言えない機能を宣言したアプリがいくつかストアに提出されているのを見ました。ですから、使用可能な機能のリストは比較的短くなっていますが、これらの各機能とその使用方法を詳しく確認することは重要です。

Visual Studio のマニフェストデザイナー

データライブラリ

これらの機能を使うと、アプリで作成されたものではないユーザーデータにアプリがアクセスできるようになります。ユーザーは、アプリがユーザーを尊重した方法でプライベートなデータにアクセスすることを期待します。ユーザーがアプリに対して抱く信頼を尊重する 1 つの方法は、アプリにとって必要最小限のアクセスのみ宣言することです。ほとんどの場合、ファイル選択ツール (英語) を使ってこれらの機能をすべて使うことを避けることができます。このツールでは、ユーザーはハードドライブまたはネットワーク上のどこにあるファイルでも参照できます。たとえば、ユーザーがアプリからライブラリやリムーバブルストレージにコンテンツを保存できるように、ファイルを開く機能やファイル名を付けて保存する機能を追加するためにファイル選択ツールを使います。

マニフェスト宣言	実現する機能
musicLibrary	ローカル PC およびホームグループ PC のミュージックライブラリでファイルを追加、変更、または削除する機能を追加します。
videoLibrary	ローカル PC およびホームグループ PC のビデオライブラリでファイルを追加、変更、または削除する機能を追加します。
pictureLibrary	ローカル PC およびホームグループ PC のピクチャライブラリでファイルを追加、変更、または削除する機能を追加します。
documentsLibrary	ローカル PC のドキュメントライブラリでファイルを追加、変更、または削除する機能を追加します。アプリは、ドキュメントライブラリ内にある、[ファイルの種類の関連付け] 宣言を使って定義されたファイルの種類にのみアクセスできます。ホームグループ PC のドキュメントライブラリにアクセスすることはできません。
removableStorage	リムーバブルストレージデバイスでファイルを追加、変更、または削除する機能を追加します。アプリは、リムーバブルストレージ上にある、[ファイルの種類の関連付け] 宣言を使ってマニフェストで定義されたファイルの種類にのみアクセスできます。ホームグループ PC のリムーバブルストレージにアクセスすることはできません。

Consumer Preview では、本当は必要ではない機能を制限したアプリが提出されていたのを見ました。たとえば、アプリは以下のようなさまざまな理由で documentsLibrary を宣言していました。

アプリ固有の設定をドキュメントライブラリに保存する。この目的では、プライベートストアが用意されています。アプリの設定とストレージの詳細については、ここをご覧ください。
ユーザーが生成したファイルを保存する。これは、ファイル選択ツールを使って、ユーザーがファイルを任意の場所 (ドキュメントライブラリを含む) に保存できるようにした方が適切に実現できます。
ドキュメントを別のアプリと共有する。この目的では、共有コントラクトが用意されています。

システムで特定のファイルの種類のプライマリハンドラーとなるようにアプリが設計されている場合 (たとえば、ユーザーのドキュメントライブラリにあるすべての .TIFF ファイルを扱う必要があるファックスビューアーなど)、この機能を宣言してください。

デバイスアクセス

方位センサーや加速度計などの多くのデバイスは、どのアプリでも利用できます。しかし、ほとんどのユーザーはあるデバイスを他のデバイスより機密性が高いと考えます。ユーザーのプライバシーに深くかかわっているためです。これらのデバイスを使うと、すばらしいアプリをたくさん構築できます。たとえば、共有ゲームプレイが可能なカジュアルゲームの��合、デバイス間で接続を確立するには近接通信が適しています。

これらのデバイスはユーザーのプライバシーに深くかかわっているため、この機能を宣言した場合、Windows 8 ではアプリが特定のデバイスに初めてアクセスしようとしたときにアクセスの許可を必ずユーザーに求めるようになっています。たとえば、アプリに地図機能が付いている場合、ユーザーの地理位置情報データにアクセスする必要があることと思います。アプリが初めてこの情報を取得しようとすると、アプリのアクセスの許可を求めるメッセージがユーザーに表示されます。この許可は、ユーザーが後で設定をとおしてアクセスを明示的に削除することを決定するまで有効です。ユーザーはアプリによるこれらのデバイスへのアクセスを拒否できるので、マニフェストに機能を追加した場合でも、アクセスできない状況を適切に処理できるようにアプリを設計してください。たとえば、ユーザーがアプリによる組み込み GPS へのアクセスを拒否した場合、地図から位置を選択するようユーザーに求めることができます。

マニフェスト宣言	実現する機能
location	PC の GPS センサーなどの専用ハードウェアから取得された現在位置情報や、利用可能なネットワーク情報から導き出された現在位置情報にアクセスできます。
webcam	Web カメラのビデオフィードにアクセスできます。アプリが、接続された Web カメラからスナップショットやムービーをキャプチャできるようになります。
microphone	マイクのオーディオフィードにアクセスできます。アプリが、接続されたマイクからオーディオを録音できるようになります。
proximity	近距離通信電波をとおして PC に近接するデバイスに接続する機能を追加します。近距離通信を使うと、ファイルを送信したり、近隣のデバイスのアプリと通信したりすることができます。

ネットワークアクセス

ほとんどのアプリはインターネット接続を必要とするため、Metro スタイルアプリの Visual Studio テンプレートには internetClient 機能が既定で含まれています。アプリがインターネット経由で通信する必要がない場合、この機能を削除してください。internetClientServer 機能は、一般にゲームや VOIP などのピアツーピア (P2P) シナリオで使用されますが、アプリがファイアウォール内でポートを開く必要がない限り、この機能を使わないでください。privateNetworkClientServer 機能は、アプリがプライベートネットワーク経由 (自宅内のデバイス間や、企業ネットワーク接続経由など) で通信する必要がある場合に使います。

マニフェスト宣言	実現する機能
internetClient	インターネット、および空港やカフェなどの公共の場所にあるネットワークに発信アクセスできます。インターネットに接続する必要があるほとんどのアプリではこの機能を使ってください。
internetClientServer	インターネット、および空港やカフェなどの公共の場所にあるネットワークに着信および発信アクセスできます。この機能は、internetClient の上位セットです。この機能を有効にした場合、internetClient 機能を有効にする必要はありません。
privateNetworkClientServer	認証されたドメインコントローラーがあるイントラネットネットワークや、ユーザーが自宅または職場のネットワークとして設計したイントラネットネットワークに着信および発信アクセスできます。

ユーザー ID

ほとんどの開発者は、これらの機能を使う必要がありません。これらの機能の使用は、かなり制限されており、追加の登録ポリシーおよび確認が必要になります。ただし、このような機能が必要かつ適切なケースがあります。たとえば、一部の銀行では 2 要素認証を要求しており、ID を確認するデジタル証明書が搭載されたスマートカードをユーザーが使えるようにする必要があります。主にコンシューマー向けではなくエンタープライズユーザー向けに設計された他のアプリでは、ドメイン資格情報がないとアクセスできない企業リソースへのアクセスが必要なことがあります。

マニフェスト宣言	実現する機能
enterpriseAuthentication	ドメイン資格情報が必要な企業イントラネットリソースに接続する機能を追加します。
sharedUserCertificates	ユーザーの ID を検証するため、スマートカード証明書などのソフトウェアおよびハードウェア証明書にアクセスする機能を追加します。実行時に関連する API が呼び出されると、ユーザーは操作を行う必要があります (カードの挿入、証明書の選択など)。この機能は、[証明書] 宣言によるプライベート証明書がアプリに含まれている場合は必要ありません。

信頼性の構築

ユーザーは、Windows 8 と皆さんが構築したアプリを安全に使いたいと思っています。Metro スタイルアプリのエクスペリエンスは、すべてのユーザーが信頼して試用し、購入できるアプリを皆さんが簡単に構築できるような設計になっています。この結果、ユーザーがたくさんのアプリを気に入って購入する前向きなサイクルができあがるので、開発者にとってはすばらしい Metro スタイルアプリをさらにたくさん作成して提供する機会が生まれます。

この記事の冒頭で触れたように、この点で皆さんと私たちは同じ立場にいます。私たちがこの新しいエコシステムに対して行った投資全体が、ユーザーが喜ぶアプリを皆さんが構築するのに役立つと確信しており、驚くような新しいエクスペリエンスを共通の顧客に提供する点で皆さんと協力できることを楽しみにしています。

--John Hazen

Windows 8 によって家族の安全を保つ

2012-05-21T19:09:00Z

Windows 8 にもともと備わっている機能の 1 つとして、どの PC でも複数のアカウントを使うことができるという点があります。これにより、保護者の皆さんはツールを使って簡単に、インターネット上のコンテンツからお子様を保護することができます。さらに、1 台の PC を共有する場合でも各自のオンライン ID を持つことは、家族全員にっても良いことです。マイクロソフトは、すべてのユーザー、特に保護者の皆さんにとって、安全なコンピューティング環境を維持するのに役立つツールを作成する点でリードしてきました。Windows 8 では、家族の安全のために利用可能な機能とサービスが大幅に強化されています。この投稿では、ファミリーセーフティのシニアプログラムマネージャーリードである Phil Sohn が、Windows 8 でファミリーセーフティがどのように機能するかを説明します。
-- Steven

現在の子供たちは、オンライン環境で育っています。コンピューターを使って宿題をし、ゲームをプレイし、友人だちとやり取りし、Web 上の健康に関する情報にもアクセスします。コンピューターにより、子供たちはたくさんの有意義な体験をすることができますが、保護者は子供たちがオンラインで見るもの、会う人、共有する情報について把握するという課題に直面します。

マイクロソフトでは、保護者の皆さんがお子様のために健全なコンピューティング環境を作るのを支援したいと思っています。保護者の皆さんには、オンライン環境での安全についてお子様と対話し、コンピューターの使用に関するガイドラインを定めることをお勧めします。マイクロソフトや安全を提言する多くの人たちは、家族のコンピューターを家の共用の部屋に移動して、お子様の後ろから目を向けてオンラインの活動をよく知ることができるようにすることも勧めています。このような保護者側の手法も重要ですが、家族が複数の PC を持っていたり、お子様がノート PC やタブレットを使っている場合は実行するのが難しいことがあります。また、10 代のお子様の場合、後ろから目を向けると保護者とお子様の双方が気まずくなることもあります。

クリックするだけでインターネットが安全に

Windows 8 では、お子様が PC をどこで使っていても、何を行っているかを観察できます。お子様ごとに Windows ユーザーアカウントを作成してファミリーセーフティーを有効にするチェックボックスをオンにし、お子様の PC の使用状況を示すレポートを毎週確認するだけです。追加でダウンロードしたり、インストールウィザードを操作したり、構成したりする必要はありません。チェックボックスをオンにするだけで済むのです。

"監視優先" アプローチ

かつて、家族の安全に関する業界のソフトウェアソリューションの多く (マイクロソフトを含む) は、Web フィルタリングや他のソフトウェアベースの制限に焦点を当てていました。この結果、設定手順が複雑になり、保護者の承認要求が絶えず発生し、管理するのが難しくなることがありました。最終的に、多くの保護者の皆さんがファミリーセーフティ製品を捨て、直接観察 (コンピューターがよりモバイルになった今では、効率が下がった方法になってしまいましたが) のみに戻ってしまいました。

Windows 8 では、"監視優先" アプローチが採用されており、お子様 1 人ひとりの有益な活動レポートが生成されます。この��ログで以前にお話ししたように、Microsoft アカウントを使って Windows 8 にサインインすると設定がより簡単になります。お子様ごとに別々のユーザーアカウントを作成して、ファミリーセーフティーを有効にするチェックボックスをオンにするだけです。この設定だけで、最初のご案内の電子メール受信後から、お子様のコンピューター活動の概要を示す週単位の電子メールレポートが送信されるようになります。活動レポートが、責任あるコンピューターの利用についてお子様に指導する際の最適なツールであると感じてくださることを期待しています。もちろん、活動レポートのリンクをクリックするだけで、簡単に制限を追加することもできます。活動レポートはシンプルなため、より多くの保護者の皆さんがファミリーセーフティを採用し、結果としてお子様のコンピューティング環境が安全になると確信しています。

ファミリーセーフティの活動レポートの例を次に示します。

レポートは電子メールの受信トレイに直接配信されるため、Microsoft アカウントを使うと場所とデバイスに関係なくすぐに行動することができます。ファミリーセーフティの設定に加えた変更はすべて、familysafety.microsoft.com のクラウドに保存されます。その後、これらの変更はファミリーセーフティが有効になっているすべての Windows PC に自動的に適用されます。

お子様用の標準アカウント

私たちは長い間、保護者の皆さんがコンピューター管理者としてログインして、お子様が別個の標準アカウントを持つことを推奨してきました。Windows 8 では、管理者 (つまり "保護者") が作成するアカウントは、自動的に標準アカウントとして作成されます。このアプローチにはいくつかのメリットがあります。たとえば、次のとおりです。

お子様は、保護者の電子メール、オンラインアカウント、ドキュメントなどにアクセスできません。
お子様は、保護者のアカウントに影響を与えずに自分のアカウント設定をカスタマイズできます。
お子様がマルウェアや他の疑わしいファイルをダウンロードしようとしても、SmartScreen アプリケーション評価サービスにより自動的に防止されます。

さらに管理を強化したいときは

新しいファミリーセーフティで自動的に有効になる活動レポートは、保護者の皆さんの多くにとって十分なソリューションです。しかし、管理を強化される場合は、強力でカスタマイズ可能な制限を活動レポートの電子メールのリンクから直接設定することができます。必要な場合は、familysafety.microsoft.com で行うこともできます。現在 Windows 7 で利用可能な制限に加えて、Windows 8 では次のような新しい制限が追加されました。

Web コンテンツの制限: 複数の Web コンテンツの制限レベルを選択できます。

セーフサーチ: Web コンテンツの制限が有効な場合、Bing、Google (英語)、Yahoo などの主要なサーチエンジンのセーフサーチが "強" 設定にロックされます。これにより、成人向けのテキスト、画像、ビデオが検索結果から除外されます。
時間制限: Windows 8 では、お子様が PC を使うことができる 1 日あたりの時間数を制限できるようになりました。たとえば、学校のある日は 1 時間に制限し、週末は 2 時間に制限することができます。これは、現在 Windows 7 で利用可能な就寝時制限に追加された機能です。
Windows ストア: 活動レポートには、最近行われた Windows ストアからのダウンロードが一覧表示されます。また、Windows ストアで特定の年齢制限より上のアプリをお子様が見ることができないように、ゲームの年齢制限レベルを設定できます。
アプリケーションとゲームの制限: Windows 7 と同様、特定のアプリケーションやゲームをブロックしたり、適切なゲーム年齢制限レベルを設定することができます。

次のショートビデオは、Windows 8 でファミリーセーフティがどのように機能するかを示しています。

Windows 8 Release Preview でファミリーセーフティを試す

私たちは、皆さんが家族にふさわしい安全なお子様のコンピューティング環境を作ることができるよう継続的に努力していますが、もちろんこれが何を意味するかは保護者によって異なることも理解しています。お子様を見守ることだけを望む方もいますし、お子様のコンピューティング活動にソフトウェアの制限を設定することを望む方もいます。私たちは、Microsoft ファミリーセーフティの "監視優先" アプローチがシンプルかつ強力であれば、どちらのスタイルにも効果的に対応できるため、オンラインの安全に関する家族の会話が増え、お子様のコンピューティング環境がより安全になり、保護者の皆さんも安心できるにようになると考えています。Release Preview でファミリーセーフティのこれらの機能をお試しください。

--Phil

chkdsk の刷新と新しい NTFS 正常性モデルの追加

2012-05-16T21:49:06Z

これまで私たちは、OS カーネル、ネットワーク、ファイルシステムの改良についてさまざまな記事を書いてきました。既に有効性が実証されている chkdsk ユーティリティは、ごく一部の状況を除き、ほとんどのクライアント PC で使われなくなる予定ですが、Windows 8 を機会にこのユーティリティにも改良が加えられています。私たちは、chkdsk 操作によるダウンタイムを短縮して可用性を高めるために、このユーティリティの機能を集中的に見直したいと考えました。実世界での chkdsk の使用状況を見ると、破損が生じるのはきわめてまれでありながら、chkdsk の実行はそれほど珍しくないことに気付きます。私たちは、ディスクツール (デフラグなど) を手動で実行する必要性を減らすことに力を入れてきましたが、そういったツールを "念のため" 手動で実行することを好むユーザーが多いことも理解しています。そこで、chkdsk の実行によってコンピューターの可用性が制限される状況を解消するため、chkdsk の処理能力を全体的に改善する取り組みを行いました。ディスク容量が巨大になり、マルチディスクシステムが一般的になった現在、このユーティリティには改良が必要と思われました。今回の記事は、コアシステムチームのプログラムマネージャーである Kiran Bangalore が執筆しました。
-- Steven

このブログ記事では、Windows 8 に導入される新しい NTFS 正常性モデルと、ディスク破損の検出と修正を行うツールである chkdsk ユーティリティの刷新についてお話しします。

皆さんの多くは、自宅のコンピューターや職場のサーバーの再起動中に突然 chkdsk が実行されていらついた経験をお持ちかと思います。起動プロセスが完了して Windows を利用できるようになるのを待っている最中に、予想外の割り込みが入るのですからたまりません。Windows 8 では、このような問題が発生した場合にすばやい解決方法を提供し、ユーザーが制御できない状態になるのを回避しています。これにより、システムの可用性とスケーラビリティが向上します。

Windows 8 の主要な設計目標の 1 つは、可用性を向上させ、システムの全体的なダウンタイムを短縮することでした。この機能は、記憶域スペースなどの他のストレージ機能や新しい ReFS ファイルシステムと合わせて、破損の修正時の複雑さを軽減し、システム全体の可用性を向上させる役割を果たします。

以前の chkdsk と NTFS 正常性モデル

ディスクが破損することはまれではありますが、その発生にはさまざまな原因があります。原因がハードディスクのメディアエラーの場合でも一時的なメモリエラーの場合でも、ファイルシステムのメタデータに破損が生じることがあります (メタデータとは、物理ブロックを個々のデータ、たとえば昨年撮影した休暇中の写真に対応付けるために使われる情報です)。このような場合、データへのアクセスを維持するために Windows でエラーを分離して修正する必要があり、その手段が chkdsk ユーティリティを実行することです。

過去のバージョンの NTFS に実装されていた正常性モデルは、ファイルシステムボリュームが正常かそうでないかという単純なものでした。そのモデルでは、ファイルシステムの破損を修正してボリュームを正常な状態に戻すまでに必要な間、ボリュームはずっと "オフライン" になりました。このダウンタイムは、ボリューム内のファイル数に比例して長くなりました。

世界中のシステムから収集された信頼性の高い製品利用統計情報データによると、破損が発生する頻度はかなり低いものの、chkdsk が必要となった場合、その実行時間はドライブ上のファイル数によって数秒から数時間に及び、大規模なストレージサーバーではさらに長い時間がかかる可能性もあることがわかりました。

Windows Vista と Windows 7 で chkdsk の速度は大幅に最適化されましたが、ハードディスクの容量が 18 か月ごとに倍増する現在、ボリュームあたりのファイル数も同等の速度で増え続けているため、chkdsk の完了までにかかる時間は (速度が改善されたにもかかわらず) 長くなる一方となっています。

そこで Windows 8 では、NTFS 正常性モデルに対するアプローチを見直すと共に、破損時の修正方法を変更して chkdsk によるダウンタイムを最小限に抑えるようにしました。また、将来に向けた新しいファイルシステムである ReFS も導入しました。このファイルシステムでは、破損を修正するためにオフラインで chkdsk を実行する必要はありません。

ファイルシステムの正常性機能の見直し

ストレージ容量とユーザーデータファイルの大幅な増加に伴い、私たちは、NTFS 正常性モデルと chkdsk を刷新する必要に迫られました。

ファイルシステムの正常性に関しては、ユーザーの皆さんから重要な要件が 3 つ寄せられていました。

ファイルシステムの破損によって生じるダウンタイムは、継続的な可用性が求められる構成ではゼロ、それ以外の構成でもゼロに近いこと。
ユーザーまたは管理者に常にファイルシステムの正常性が通知されること。
破損が発生した場合でも、ユーザーまたは管理者がスケジュールに沿った形で簡単にファイルシステムを修正できること。

私たちは、最大限の可用性を達成するため、ファイルシステムと chkdsk ユーティリティの両方に変更を加えるような設計を行いました。新しい設計では、プロセスを以下のフェーズに分け、破損に対する協調的で迅速、かつ透過的な解決方法を実現します。

私たちは、破損の種類を "動詞" として表す新しい方法を考案しました。これらの動詞は、主要なコンポーネントや設計上のポイント (ファイルシステムドライバー (NTFS)、自己復旧モジュール、スポット修正サービス、chkdsk ユーティリティ) に働きかける動作を示します。ファイルシステムの破損はすべて、Windows 8 に定義された 18 種類の "動詞" のいずれかに分類されます。さらに、将来発生し得る問題の診断にも対応しやすいように、新しい動詞を定義できる余地も残されています。

可用性を高めるための設計上の主な変更点

オンライン自己復旧: NTFS 自己復旧機能は、chkdsk を実行する必要性を減らすために Windows Vista (および Windows Server 2008) で導入されました。自己復旧は NTFS に組み込まれた機能の 1 つで、通常操作の中で発生した一定の種類の破損を修正します。この修正はオンラインのままで行うことができます。検出された問題のすべてが自己復旧によってオンラインで修正されれば、"オフライン" での修復の必要はありません。Windows 8 では、オンラインで対処できる問題の数を増やし、chkdsk の必要性をさらに低減しました。
オンライン検証: ディスク上に実際に破損箇所があるのではなく、メモリの問題が原因となって断続的に破損が発生する場合もあります。このため Windows 8 には、スポット検証サービスと呼ばれる新しいサービスも追加されました。これはファイルシステムドライバーによって呼び出され、正常性モデルに沿ってファイルシステムの状態を移行する前に、ディスク上に実際に破損箇所があるかどうかを検証します。この新しいサービスはバックグラウンドで動作するため、システムの通常の機能に影響することはありません。このサービスは、破損の検証のためにファイルシステムドライバーから呼び出されない限り何もしません。
オンライン識別とログ作成: 問題が検証されると、それをトリガーとしてファイルシステムのオンラインスキャンが行われます。これはファイルシステムのメンテナンスタスクとして実行されます。Windows 8 では、コンピューターのメンテナンス用にスケジュールされたタスクは、アイドル時間などの適切なタイミングにのみ実行されます。このスキャンは、他のプログラムがフォアグラウンドで実行されている間にバックグラウンドタスクとして実行できます。ファイルシステムのスキャンに伴い、見つかった問題は後で修正できるようにすべてログに記録されます。
的確で迅速な修正: ユーザーや管理者の都合の良いときにボリュームをオフラインにして、前のステップで記録された破損を修正することができます。この操作は "スポット修正" と呼ばれ、これによって発生するダウンタイムはほんの数秒です。クラスター共有ボリュームのある Windows Server 8 システムでは、このダウンタイムが完全になくなります。この新しいモデルでは、chkdsk offline の実行時間は破損の数に比例し、以前のモデルのようにファイル数に比例するのではなくなります。

Windows Server の比較: chkdsk /f と chkdsk /spotfix

管理性の向上: 新しい正常性モデルの透明性を高めるために、ファイルシステムの状態は Windows の次の各インターフェイスで確認できるようになります。

アクションセンター: ドライブの正常性を最も詳しく確認できるのは、アクションセンターの [Drive Status] (ドライブの状態) (下の図を参照) です。ボリュームを正常な状態にするためになんらかのアクションが必要な場合は、ここに表示されます。
エクスプローラー: 正常性の状態は、エクスプローラーのドライブのプロパティにも表示されます。
PowerShell: chkdsk の機能は、PowerShell で REPAIR-VOLUME という新しいコマンドレットを使って呼び出すこともできます。これは、ファイルシステムの正常性をリモート管理する場合に役立ちます。
サーバーマネージャー: Windows Server では、サーバーマネージャーユーティリティから直接ボリュームの正常性の状態を管理することもできます。

新しいファイルシステム正常性モデル

新しい正常性モデルでは、ファイルシステムの正常性は 4 つの状態で表されます。いくつかの状態は単に情報を表すものですが、ユーザーによる操作が必要な状態もあります。4 つの正常性の状態は次のとおりです。

オンラインで正常
オンラインスポット検証が必要
オンラインスキャンが必要
スポット修正が必要

Windows 8 ファイルシステムの正常性の状態

オンラインで正常 – この状態ではファイルシステムの破損は検出されていないため、ユーザーによる操作は必要ありません。ファイルシステムは、ほとんどの間この状態になります。

オンラインスポット検証が必要 – これは一時的な状態です。自己復旧できない破損がファイルシステムに見つかると、その後の短時間だけこの状態になります。スポット検証サービスによって破損が確認されるまで、ボリュームはこの状態に置かれます。この場合もユーザーによる操作は必要ありません。
オンラインスキャンが必要 – スポット検証サービスで破損が確認されると、ファイルシステムは "オンラインスキャンが必要" という状態になります。次回のメンテナンス時にオンラインスキャンが実行されるため、ユーザーによる操作は必要ありません。この状態はアクションセンターに反映され、必要であれば次回のメンテナンス時期が来る前に手動でスキャンを実行することもできます。スキャンはバックグラウンド処理として実行されるので、スキャンの実行中でもコンピューターを使い続けることができます。検証された問題と修正方法は、後で修復するときに参照できるように、このオンラインスキャン中にログに記録されます。Windows Server 8 システムでは、CPU とストレージのアイドル時間が監視され、アイドル時間が決定されます。

スポット修正が必要 - オンラインスキャンの完了後、ファイルシ��テムは必要に応じてボリュームをこの状態に変更します。この状態はアクションセンターに反映されます。クライアントシステムでは、PC を再起動することで、前のステップで記録されたファイルシステムの問題をすべて修正できます。再起動はすぐに完了し (通常よりも数秒長くなるだけです)、PC は正常な状態に戻ります。Windows Server 8 システムの場合は、データボリュームの破損を修正するために再起動する必要はありません。管理者は、次回のメンテナンス時にスポット修正が行われるようにスケジュールできます。

より詳しい知識のあるユーザーは、システムを再起動せずに非システムボリュームの破損を修正することができます。問題のあるボリュームのプロパティダイアログを開いて [Tools] (ツール) タブをクリックすると、ドライブのファイルシステムエラーをチェックするオプションが表示されます。現在使用中でないドライブ上の破損であれば、コンピューターを完全に再起動しなくても修正できます。

まとめ

Windows 8 では、ファイルシステムエラーの検出と修正がより透過的に行われ、通常操作が中断されることは少なくなります。この変更による機能強化は、きっと皆さんに喜んでいただけるものと思います。皆さんからのフィードバックを楽しみにしています。

-- Kiran Bangalore
Windows コアストレージおよびファイルシステム担当シニアプログラムマネージャー

FAQ

Q) 新しい正常性モデルはリムーバブルドライブでも機能しますか?
はい、新しいモデルは固定メディアとして認識されるリムーバブルドライブで機能します。これには、ほとんどの外付けハードドライブが該当します。

Q) 新しいファイルシステム正常性モデルを有効にするにはどうすればよいですか?
特に何もする必要はありません。新しいファイルシステム正常性モデルは、既定で有効になっています。

Q) 新しいファイルシステム正常性モデルは Windows Server にも適用されるのですか?
はい、正常性モデルはサーバーでもクライアントでもまったく同じです。既定で異なるのは、システムの起動中にデータドライブのチェックと修正が行われないという 1 点だけです。このメンテナンスは管理者の判断に任され、時間に余裕のあるときに行うことができます。

Q) ファイルシステムの正常性モデルに影響を与えずに Windows 8 と Windows 7 を混在させることはできますか?
はい、ファイルシステムの正常性モデルは、マウント先のオペレーティングシステムがどちらでも適切に対応します。

Q) ReFS で chkdsk を実行する必要はありますか?
ReFS では、復元性に関して別のモデルが採用されており、従来の chkdsk ユーティリティを実行する必要はありません。

Q) 昔ながらの chkdsk /f の実行が必要になることはありますか?
状況によっては、障害のあるハードウェアで深刻な破損が発生し、ファイルシステムをマウントできなくなることもあり得ます。このような場合には、オフラインで完全な chkdsk を実行してファイルシステムを修復する必要があります。なんらかの理由でこれが失敗した場合は、バックアップから復元することをお勧めします。

Q) 非システムボリュームの修正時にも必ず再起動が必要になるのですか?
いいえ、そうではありませんが、アクションセンターでは一般に最もシンプルな解決策が提示されます。詳しい知識のあるユーザーは、ドライブのプロパティを開くか、コマンドラインから chkdsk /scan <ボリューム>: および chkdsk /spotfix <ボリューム>: を実行することで非システムボリュームを修正できます。

Q) ドライブの状態をチェックするために chkdsk /f をよく実行しているのですが、今後もこれを実行する必要はありますか?
いいえ、破損が見つかった場合はシステムがお知らせします。その後 chkdsk /scan を実行すれば、すべての問題を検出できます。オンラインの chkdsk /scan では、ドライブやシステムの可用性が損なわれることはありません。

Q) 現在はドライブの状態をチェックするために読み取り専用モードで chkdsk を実行しているのですが、今後もこれを実行する必要はありますか?
いいえ、代わりに chkdsk/scan を実行することをお勧めします。chkdsk/scan では、実行できるオンライン修正はすべて実行され、必要に応じてスポット修正の準備も行われます。

	SkyDrive SkyDrive 内での検索フォルダーとファイルの名前の変更および移動新しい初期実行画面カスタムの並べ替え順序
	メール、カレンダー、People、メッセージング受信トレイのスレッドビュー IMAP アカウントのフルサポート招待メールの承認と拒否アカウントの画像のキャプチャと更新検索の強化メッセージングアプリ内での連絡先の検索
	フォト写真のトリミングと回転新しい自動キュレーションコラージュスライドショーピクチャライブラリでのネットワーク上 (Windows Home Server、ネットワーク共有、ホームグループ) の写真およびビデオの表示デスクトップから写真を開いているときでも、ピクチャライブラリで写真間を移動可能
	マップ概観図ビュー 3,000 以上の屋内施設地図ドライブナビゲーションのヒントナビゲーションとレイアウトの強化カスタマイズの強化 (カスタム画鋲やローミングオプションなど) Bing アプリおよびトラベルアプリとの統合
	Bing ローカルコンテンツおよび画像の豊富な検索結果 Bing による統合検索結果のズームを使用した関連クエリの表示ファイルピッカーを使用して Bing から画像を選択し、ロック画面や他のアプリで使用可能
	ファイナンス追加のニュースおよび雑誌コンテンツより多くの証券取引所に対応ファイナンスビデオ
	ニュース The New York Times や The Wall Street Journal などのパートナーによる追加のニュースコンテンツ記事リーダーの強化 (フォントのカスタマイズ、ズーム、改ページなど) オフライン閲覧エクスペリエンスの強化ニュースビデオスライドショー
	スポーツ追加のニュースおよび雑誌コンテンツスポーツビデオスライドショー MLS、J リーグ、ブラジルリーグなどの新しいサッカーリーグ
	トラベル追加のニュースおよび雑誌コンテンツフライト検索の強化と新しいフライト進行インジケーターホテル一覧ページの強化 360 度パノラマのサポート (ジャイロスコープのサポート)
	天気既定の場所の使いやすさの向上 1 時間ごとの天気予報 (最大 10 日間) 日中および夜間の最高気温/最低気温
	ビデオ自国通貨での購入クローズドキャプション俳優または監督による検索
	ミュージック音楽サービスの拡大豊富な "プレイビュー" エクスペリエンス SmartDJ による多くの音楽の発見
	ゲームエキサイティングな新しいゲームゲーム内購入招待とターン通知

Building Windows 8

Windows 8 の一般提供に向け、最新の更新プログラムが公開されました

Windows 8 の組み込みアプリを更新する

Windows RT PC の提供に向けたコラボレーション

シンプルになった Windows 8 の印刷機能

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

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

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

Windows RT からの印刷

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

プリンターの共有

Windows 8 の印刷システム

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

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

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

UI の構成

レンダリング

Windows RT からの印刷

まとめ

Windows 8 リリース - 2012 年 8 月 1 日

すべてにハードウェア アクセラレーションを: Windows 8 のグラフィックス

Windows 8 へ

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

1. フレーム レート

2. エラー カウント

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

4. メモリの使用状況

5. CPU の使用状況

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

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

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

画像のレンダリング

レンダリングと表示

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

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

Direct2D Effects

共通基盤としての Direct3D 11.1

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

省電力システム

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

フィードバックを基にタッチ操作でナレーターをさらに使いやすく

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

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

音声による合図

対話式操作を簡単にする

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

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

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

しあげをする

Windows 8 のタッチ キーボードのデザイン

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

ガラス面でのタイピング

入力に最適化

数字

Tab キー

Downshift: 学ぶべき失敗

テストと検証

さらなる微調整

ファイル履歴を使ってユーザー ファイルを保護する

ファイル履歴とは

セットアップ

ファイルの復元

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

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

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

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

簡単で安心

細かい制御

最小限のセットアップ

スケジュール不要

メンテナンス不要

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

ファイル履歴と SkyDrive

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

要件

FAQ

最後に

Metro スタイル アプリを一般提供に備える

Windows 8 用フォト アプリの紹介

すべての思い出を 1 か所に

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

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

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

すべてにハードウェアアクセラレーションを: Windows 8 のグラフィックス

1. フレームレート

2. エラーカウント

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

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

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

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

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

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

Windows 8 のタッチキーボードのデザイン

ファイル履歴を使ってユーザーファイルを保護する

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

Metro スタイルアプリを一般提供に備える

Windows 8 用フォトアプリの紹介

Windows 8 のカレンダーアプリのデザイン

メールアプリを構築する

リッチで拡張性に優れたメディアプラットフォームの構築

より高速で応答性に優れたメディアエクスペリエンス

Metro スタイルアプリ向けのビデオ/オーディオサポート

プレミアムコンテンツ

可変ビットレートストリーミング

メディアエクスペリエンスを追加スクリーンに

メディアパイプラインへのエフェクトの追加

コントラクト: 目的に応じた、コンテキストを伴う Metro スタイルアプリの起動

シナリオ 2: アプリに File Open Picker (ファイルオープンピッカー) アクティベーションを組み込む