マイクロソフトのEngineering Windows 7 ブログ

バグレポートにどう対処するか?

ある一つのWindows 7 のバグ レポートのため、チームの何人かはこの 2 日、忙しく過ごしました。この問題についての詳細はそれほど重要ではなさそうなので、その内容そのものよりも今回はその例を使用して、私たちがこの種の状況にどのように対処するか、その背景とプロセスについて説明したいと思います。

今週、あるブログで Windows 7 でクラッシュする問題が報告されました。クラッシュを再現する手順はとても簡単で、(1) システム ドライブ以外のドライブで chkdsk /r を実行すると、その後システム メモリが消費されてクラッシュが発生するというものでした。「再現」が容易だったので、この件は急速に広がりました。それに続く投稿やコメントは、この問題が他のユーザーによっても再現されることを示していました。このレポートには 2 つの特徴があり、(a) 多くのメモリを消費して、(b) クラッシュする、ということでした。

すぐに、私はこのレポートに関する多くのメールを個人的に受け取とるようになりました。多くのみなさんと同様、私が最初にしたことは、それを試してみることでした。そして、ご想像のとおり、私はどちらの問題も再現できませんでした。が、メモリの使用は確認しました。別のコンピューターでもやってみて、同じことを確認しました。どちらの場合も、コンピューターは chkdsk 中も chkdsk 後も正常に機能しました。いつものように、私は受信したほとんどのメールに返信し、クラッシュの再現手順の説明と、システム ダンプ ファイルの共有をお願いしました。メモリの使用については、クラッシュほど心配ではありませんでした。興味深いメールのやりとりをかなりの数しましたが、再現ケースに関する手がかりや対処すべきクラッシュ ダンプを得るには至りませんでした。

もちろん、Microsoft 社内で最初にこれを知ったのは私ではありません。ファイル システムのチームは、直ちに問題を調査し始めていました。彼らもまた、クラッシュを再現することができませんでした。彼らの分析によると、このメモリ使用は計画的なもので、このシナリオに対する Windows 7 特有の変更点でした。(/r フラグは、排他的ロックを使用してディスクを修復します。したがって、私たちの仮定は、コンピューター上で何かを行う前に、ユーザーはディスクが修復されて欲しいと考えているということです。これは、このトピックに関するその後の複数の第三者によるブログ投稿によって立証された仮説でもあります)。私たちはさらに調査を進め、クラッシュ ダンプとレポートを探し続けました。下記に述べるように、私たちは自由に使えるかなり多くのツールがあります。

調査を続けている間、私が受け取るメールの雰囲気はエスカレートし、さらに重要なことに、私が返信したうちの 1 人が、ブログの投稿で私たちのメール交換について言及しました。そのため、電子メールでふつうに対話しようとしていましたが、それは話し合いの途中で終了せざるを得ませんでした。Windows 7 の開発中、きわめて慣例的に行ってきたように、私は元のブログ (および、この特定のメル友がコメントしているブログ) にコメントを追加し、私たちが行っている手順やその時点でわかっている情報を説明しました。面白いことに (残念なことではありません)、コメントを投稿するだけで、取り上げられたこの問題にさらに多くの注意が向けられました。個人的に、私は広いコミュニティのメンバーであるのが大好きなので、多少混乱を引き起こすような場合でさえ、当事者になることを楽しんでいます。

クラッシュの問題に関するレポートを受け取ったときの内部プロセスは、まさに説明する価値があります。数年前まで、私たちは次の 2 つの対応のうち、どちらか 1 つを行っていました。バグを見つけられそうにないので降参する、あるいは、すべてを後回しにして、再現可能なケースを見つけられるかもしれないという希望を抱いて、ターミナル デバッガーを持って飛行機に乗る、です。このどちらも特別に効果的であるということはなく、後者は非常に英雄的に聞こえますが、努力にみあった結果を生み出しません。最も重要なことは、クラッシュの可能性があったとして、それがただ 1 つの事例なのか、それとも多くのユーザーが遭遇している、または遭遇しうるクラッシュなのか、私たちには分からないということです。私たちは判断の材料となるデータなしで作業していました。

今では、インターネットと製品 (Windows 7 だけではありません) に組み込まれた遠隔測定によって、私たちはソフトウェアの全体的な状態に関して、はるかに明瞭に観察できるようになりました。したがって、初めてクラッシュの報告を受けると、私たちは、そのクラッシュがほかの何百万台ものコンピューター上で発生しているかどうかを確かめます。これは全体的には役立ちますが、クラッシュが 1 つの特定の構成である場合は、もちろん役に立ちません。ただし、統計的に妥当なコンピューターのサンプリングがなされれば、1 つの特定の構成上のクラッシュでも明らかにできます。一定のユーザー ベースの大きさがあれば、これが、そのケースであることはほとんど確実です。たとえば、私たちは報告されたすべてのクラッシュの呼び出しスタックを照会して、特定のプログラムがそのスタック上にあるかどうかを確かめられます。

遠隔測定でクラッシュを見つけたとき、私たちには自由に使えるツールがいくつもあります。もしかすると、みなさんは、クラッシュしたときにこれらが動いているのを見たことがあるかもしれません。送信してもらうデータの量を (同意により) 増やすことができます。クラッシュへの対応として、サポート技術情報を掲載できます (Windows 7 では Action Center で通知されます)。「電話してください」と言うことすらできます。正気でないように聞こえるかもしれませんが、時には役立ちます。出荷済みの製品で突然クラッシュの問題が発生した場合は、事情は多少異なります。おそらく新しいハードウェア デバイス、新しいデバイス ドライバー、あるいは他のソフトウェアが、以前よりも頻繁にクラッシュを生じさせる原因です。しばしば、単に変更したものを確認するだけで、問題の診断に役立ちます。私がこのことを学んだ初めての機会の 1 つが、ある日突然 Word でクラッシュが起こり始めた時です。私たちは何も変更していませんでしたが、人気のあるアドインの新しいバージョンがリリースされ、そのアドインでクラッシュが発生していることが分かりました。しかし、もちろん、エンド ユーザーには Word がクラッシュしているとしか見えません。私たちは、修正プログラムを送り出すためにソフトウェア メーカーと協力する一方、アドインを削除する手順を急いで提供しました。この、変化する状況を見て、診断し、問題に対応する能力は、製品の問題についてどのように考えるかを根本的に変えました。

私たちは絶えず、新しい問題と頻繁に生じる問題 (クラッシュ、ハング、デバイスが見つからない、セットアップの失敗、潜在的なセキュリティの問題点など) を調査しています。実際、企業や OEM の顧客 (そして、つまり、ハードウェア パートナーやソフトウェア メーカーなど) と協力しながら、月に何百もの問題点を調査します。しばしば、コアの Windows コード以外のコード (ドライバー、ファームウェア、ソフトウェア メーカーのコードなど) の変更によって問題が解決することを発見しました。これは、責任逃れをしようということではなく、根本的な原因において修正を行う手助けをするということです。また、毎月の更新プログラム、修正プログラム、および Service Pack で見られるように、Windows の多くのコード変更を行います。修正のほとんどは広範囲に適用可能ではなく、そのため緊急にはリリースされません。広く適用可能な場合は、広くリリースすることをお知らせします。私たちが、広く送り出そうとする変更の量のバランスを取りつつ、広範囲のユーザーに影響を与える重大な問題がないようにする責務をいかに真剣に受けとめているか、みなさんに理解していただくとこはとても重要です。

Chkdsk ユーティリティの調査について、私たちがこの 2 日間どのように仕事に没頭していたかを具体的にお伝えしましょう。私たちはまず、クラッシュの遠隔測定 (ユーザー レベルと「ブルー スクリーン」レベルの両方) に目を通しましたが、chkdsk に関して報告されたクラッシュは見つかりませんでした。もちろん、Windows 7 の開発中に見つかった既存の問題のレポートにも目を通しましたが、何もわかりませんでした。報告された既存のクラッシュ (報告当初からのすべての種類) の呼び出しスタックを照会しましたが、クラッシュの際に chkdsk.exe が実行されているものは見つけられませんでした。そこで、私たちはたくさんのコンピューター上で自動テストを実行し始めました。これらを夜通し実行し、2 日間続行しました。さらに、特定のハードウェア構成に関連づけられたレポートを見て、そのチップ セット、ドライバーおよびファームウェアの異なる組み合わせに基づいた 40 台以上のコンピューターをセットアップし、テストを実行しました。それでも、クラッシュは発生しませんでした (前述のように、メモリ使用については既に理解していました)。コンピューターが応答しないと言う人がいたので、手動テストでそれも確認しましたが、何も見つかりませんでした。さらに、世界中の Microsoft 社員にこの問題を伝え、試してみるよう依頼し (世界中すべての Microsoft の職場を考えると、相当数の固有の構成があります)、数百のテストを実行していました。私たちは、ページ ファイルがない状態で実行すると、クラッシュが発生するという報告を得ました。それは事実かもしれませんが、このユーティリティの問題とは言えないでしょう。なぜなら、物理的に使用可能なメモリよりたくさんのメモリを要求するプログラムでは、物事がひっくり返ってしまう可能性があり、このような構成は汎用的な使用には推奨されません (これは、少数の再現不可能なクラッシュに関する一般的なスレッドのようでした)。興味のある方は、一般的なページ ファイルのトピックに関する Mark のブログを参照してください。注目すべきものが何も見つけられず、問題の可能性は無視できませんでしたが、この時点で、広範囲にわたる問題である可能性は非常に少なくなりました。

一方、私たちは再現が可能なケースを調べるために、外部のブログ、フォーラム、およびの他のクラッシュに関するレポートに目を通し続けました。すべての人にはコンタクトしませんが、フォーラムやレポートがよい成果を導きそうな場合は問い合わせます。公平に見て、火元を見つけようとしているときに多くの「煙」が上がっていると、手助けになりません。私たちは山と積み上げられた多くの「致命的な問題」のコメントを受け取りましたが、追加情報は多くなく、再現可能なケースやクラッシュ ダンプが不足していました。

体系的にクラッシュを排除した、またはクラッシュが発生する状況が定義できたと私たちが納得できるまで、この種の作業は続行されます。これはハードウェア/ソフトウェアに関連する問題なので、このトピックに関して、さまざまなハードウェア メーカーの皆様からの情報を歓迎します。このケースでは、ディスクと関係があったので、ディスクが実際に壊れているか壊れそうになっていて、/r による修復中のディスクの過度の使用が問題を引き起こしているという可能性を排除することができません。また、(ご想像のとおり) コードはこのような障害を処理するように設計されていますが、特定の障害が適切に処理されない可能性があります。実際、テストラボで(数日間テストを継続的に実行していて)、これに関連する障害に 1 回遭遇しました。そのクラッシュは、ディスク用のコントローラーのファームウェア上で発生しました。言うまでもなく、私たちは引き続きこの特定の問題を調査します。

私たちがどれほど真剣にこれらの問題に対処しているかをみなさんに知っていただきたいと思いました。ブログやコメントは時々とてもエキサイトしています。「致命的な問題」のようなものを見ると、誰も注意が引かれます。しかし、それらは建設的かつ合理的な調査を行う助けにはなりません。大規模なソフトウェア プロジェクトは、本質的に極めて複雑です。環境や構成に依存する問題がしばしばあります。既にご存知のように、ソフトウェアはそれが当然だと思われていますが、問題を再現できないことがあります。レポートを調査する方法についてはとても明瞭なプロセスがあり、Windows が、変化する状況に直面してさえ、確実に正常な状態を保つことに重点を置いています。私はこの投稿でいくつかの問題の見方をお伝えしようと思いました。

ソフトウェアのバグを見つけることは常に素晴らしいことです。それが ATM であろうと、映画チケット販売機であろうと、Windows であろうと、そう機能すべきだと思われるように機能していないものを見つけ出すことに、私たちは皆ある誇りを感じています。Windows は多くの人々の製品であって、単に Microsoft の人たちのものではありません。何かが意図されたようになっていない場合、問題に対して効果的に対処できるようにするため、さまざまなパートナーと協力しています。私たちは皆、これからも問題を調べ続け、Windows に期待している品質レベルを維持するためにコードを変更しなければならないような問題が将来発生するであろうことを承知しています。それと同様に、私たちがこの責務をどれほど真剣に受けとめているかをみなさんにわかっていただければ幸いです。

--Steven

次のエンジニアリング マイルストーン: RTM

本日、Windows 7 プロジェクトにおいて重要なマイルストーンを迎えました。Windows 7 チームは、先ほど Windows 7 を PC OEM や製造パートナーへリリースし始めました。皆様にお知らせできることを光栄に思います。次の大きなマイルストーンは、Windows 7 を搭載した PC や Windows 7 のパッケージが店頭に並ぶ 2009 年 10 月 22 日になります。

このブログでも何度もお話ししてきたように、PC エコシステム全体の幅広い参加なくして、このマイルストーンに到達することはできませんでした。Windows 7 は Microsoft だけでなく、あらゆる種類のパートナーの業界全体の製品です。Windows 7 の開発期間中、非常に多くの人々が関与し、 Windows 7 のエンジニアリング プロジェクトが関連するすべてのパートナーの方々にとってよりよいものとなるように、たくさんのご協力をいただきました。Windows 7 開発期間中のフィードバックや連携は計り知れないほど有益でした。これらの作業は、このブログでも数多く論じられてきたような素晴らしい効果を生み出しました。それは、いろいろな種類の PC ハードウェアや周辺機器を、とても簡単に、追加設定などすることなく使えるようにすることです。完璧なインストールや、新しく開発されたデバイスのとても簡単な接続法は、パートナーの皆様とのコラボレーションがなければ実現しませんでした。すばらしい仕事をしてくださったハードウェア パートナーのすべてのエンジニアの皆様に対して、Windows チームを代表し心からお礼申し上げます。

Windows 7 は、これまでリリースしてきたソフトウェアの中で、最も広く深くテストされた製品のひとつです。数千人の開発者が初期の段階で使用した 2008 年 10 月の Pre-Beta に始まり、Beta がそれに続き、そして 5 月の RC では何百万もの人々が製品を (しかも複数の PC で) 問題なく動かすことができました。以前もお話ししたように、さまざまなハードウェアおよびソフトウェア構成で、広範にしかも詳細に Windows 7 を使用していただいたことで、かつてないほど改善されたOS の品質を生み出し続けるようにするため、重要なツールを提供することができました (そして、今後も提供し続けます)。

Windows 7 を開発するうえで、みなさんとの対話も重要視しました。おそらく、みなさんは私たちにとってもっとも厳しい批評家であり、かつ、強力なサポーターです。私たちは、みなさんの Windows 7 に対する大きな期待や OS を開発しているチームへのいろいろな要求について理解しています。このブログは重大な項目や重要な決定を公表するのに役立ち、私たちはそれについて議論を重ねてきました。その間、一緒に取り組むことについて、また、みなさんにとって重要な具体的な項目について、本当にいろいろと学びました。さまざまな観点がある中で、適正なバランスを見出せるよう一生懸命取り組んできました。また、私たちの Windows 7 エンジニアリングのアプローチについて、透明かつ率直で誠実にお伝えしてきたつもりですが、みなさんにもそう感じていただければ幸いです。このブログでの会話は Windows 7 の開発で忘れられないものであり、オフィスの廊下やレドモンド、ひいては世界中で、みなさんから寄せられたフィードバックについて討議し対応するために、トータルで何千時間もが費やされました。(訳注：このブログの翻訳は、日本のWindows 開発チームが担当しました。翻訳にも非常に多くの時間を費やしてきましたが、私たちは翻訳が本業ではないため、わかりにくい表現があったかもしれません。お詫び申し上げます。昨年の夏、スティーブン・スノフスキーから、「多少日本語がぎこちなくても投稿の遅れがあってもよいので、Windows 7 の開発の実情を理解している実際の開発者が翻訳をしてもらいたい」という指示を受け、私たちが始めました。当初はこれほどまで多くの投稿があるとは予想しておらず、途中で挫折しそうにもなりましたが、おかげさまでどうにかここに至ることができました。この日本語版のブログによって私たちの想いもお伝えすることが、少しはできたかもしれません。また、このブログは、私たちが日本の多くのパートナーの皆様と協業を進めていくにあたり、大変有益なものとなりました。ありがとうございました。)

RTM のマイルストーンに到達はしましたが、本当に「完了」するソフトウェア プロジェクトはありません。私たちは実世界で Windows 7 がどのように使われていくかについて引き続きモニターし、対応していきます。Beta や RC のプロセスを私たちのサービスをテストするためにも使いましたが、この製品の重要な側面に対してすばらしい仕事をしようと固い決意で望んでいます。ハードウェア パートナーはこれからも新しいデバイスを提供し、既存のデバイスに対するサポートを向上し続けるでしょう。PC メーカーからは Windows 7 の新しい API や機能用に設計された PC がたくさん店頭にお目見えすることでしょう。ソフトウェア開発者もたくさんの新しいソフトウェアを出してくることでしょう。今後の展開にとてもワクワクしています。

Windows のように大規模なソフトウェア プロジェクトはまれで、私たちのチームはそのことに誇りを持っています。そして、これまで何度も申し上げてきたように、重大な責任に対し常に謙虚であり続けたいと考えています。私たちは、最高のエンジニアになるために、そして世界中のさまざまなお客様に最高の OS を提供するために、製品をどのように開発していくかについて、これからも学習し改善をし続けていきます。エンジニアであることは学習するこということであり、その学習は製品を設計し生み出す経験によってもたらされます。そして私たちは、エコシステムのみなさんと一緒に、共に学習し、共に素晴らしい製品を作り上げてきました。

Windows 7 をいつどうやって入手できるか、たくさんのご質問があるかと思います。そして Windows 7 の機能を実際に使用していかれるとともに、さらに質問が出てくるでしょう。本日の Windows Team Blog にはたくさんの最新情報と重要な詳細情報が掲載されているので、それらがみなさんの質問の回答になれば幸いです。これからWindows 7 がどのように展開していくか、どんなハードウェアやソフトウェアが出てくるか、私たちのブログを引き続きご覧ください。

RTM に至る最後の数分は、サインオフというプロセスが行われました。これは、Windows に貢献したすべてのチームが、製品をリリースするために必要な仕事を成功裏に完了したことを正式に誓約するものです。私たちは「シップ ルーム (Windowsの品質を常時モニターする毎日の定例会議が行われる会議室。リリースを最終決定する。)」に (Windows 7 としては) 最後にもう一度集まり、各チームからの代表者が (文字通り) サインをして自分のチームが RTM の準備ができていることを表明しました。ここで、その瞬間をみなさんと分かち合いたいと思います。

Windows 7 のエンジニアリング チームを代表して、すべてのエコシステムパートナーの方々、そしてWindows 7の開発にご協力いただいたすべての方々に対し、心より感謝申し上げます。そして、今後とも Windows 7 をよろしくお願いいたします。ありがとうございました。

次は 2009 年 10 月 22 日です!

--Windows 7 チーム

グローバル マーケットに向けた Windows 7 のエンジニアリング

Microsoft は長い間グローバルなソフトウェア会社であり続け、常に世界中のお客様をベースとした製品開発を心がけています。また、インターナショナルへの対応というのは開発がとても複雑な分野でもありますーおそらく、みなさんが思っているよりはるかに複雑であり、私たちもいつも学習し改善しようとしている分野です。グローバルなソフトウェアを構築することはチーム全員の責任です。また、グローバルな機能と特定のマーケットに特化した機能の両方を開発することに注力しているチームもありますーたとえば、フォントの処理や、東アジア言語用の入力システムなどです。もちろん、Windows を 100 近い言語にローカライズ (「翻訳」はあまり正確な表現ではありません) することに対しても、私たちは莫大な開発労力をつぎ込んでいます。Julie Bennett がグローバル開発およびローカライズのチームを代表し、同じチームの John McConnell と一緒にチーム全体と協調して、グローバル マーケット用の開発の概略を説明するためにこの投稿を書きました。--Steven

E7 ブログの読者の多くは、アメリカ以外の場所に住んでいたり、英語以外の言語を話していたりします。そこで、Windows 7 におけるインターナショナルおよび多言語の改良点について共有するのも役に立つのではないかと考えました。私たちの Windows 7 での目標は、世界中のユーザーのためになるワクワクするような機能や、すべてのユーザーが Windows は地域に密着していると感じるような機能を提供することです。Windows 7 がパフォーマンスや信頼性の基礎的なシナリオを向上することに重点を置いているように、私たちがサービスを提供しているすべての国のすべての言語ですばらしいカスタマー エクスペリエンスをもたらすことができるように、プロセスを改善しました。Windows 7 を世界中でできるだけ同時に提供しようとする試みもその 1 つです。このブログでは、Windows 7 が世界中ですばらしいリリースになると信じるに値する新機能と改善されたプロセスについて説明します。

 

インターナショナル機能

Windows 7 のインターナショナル機能は、NTFS ファイル名でサポートされる文字 (Unicode 5.1 と一致するようにアップグレードされました) といった低レベルの側面から、背景やテーマの選択 (地域と関連のある写真が入りました) といった高レベルの側面まで、システム全体に波及します。しかし、世界のたくさんの言語や文化を適切にサポートするのに本質的に重大な特定の機能があります。ここでは、そのいくつかについて見ていきたいと思います。

フォント

言語と書くことはどんな文化においても中心的存在であり、そのためフォントのサポートはインターナショナル ユーザーのサポートに欠くことのできないものです。Windows 7 ではフォントの幅と品質の両方がかなり増えました。次の 50 のフォントを新しく追加しました。

上記の表のフォント名から推測されるように、新しいフォントの多くはラテン系ではない書体用です。実際、Windows 7 は、ラテン系書体より非ラテン系書体用のフォントの方が多い、初めての Windows です。大きな改善点の 1 つが、インドの言語に対するものです。Vista では 9 つのインド言語用フォントが入っていましたが、Windows 7 では40 以上のフォントを追加しました。Windows 7 には、インドの公式言語のそれぞれについて、複数のフォント (通常は、複数の太さ) が入っています。

Aparajita: 新しいデーヴァナーガリー フォントの標準、太字、斜体、および太字斜体

新しいフォント以外にも、多くの既存フォントも改良しました。たとえば、Consolas、Calibri、Cambria Bold、および Cambria Math に対して 2000 を超える字形 (グリフ) を追加しました。しかし、もっとも大規模な改善は、非ラテン系の書体に対してです。たとえば、Windows 7 は、アラビア語で一般的である Lam-Alef リガチャ (合字) (下の図を参照) と母音記号の配置の表示が大変よくなりました。

左: Vista での Lam-Alef リガチャ 右: Windows 7 での Lam-Alef リガチャ

フォントに対する変更は (明白な改善点であっても)、下位互換性の問題により、常に扱いにくいことです。たとえば、ある文字の幅や位置が変わると、既存のドキュメントのリフロー (再作成) が必要になるでしょうが、これは受け入れがたいことです。そのため、フォントを変更するときはいつも、変更に対して大規模な検証テストを実行し、フォント メトリックや他の表が変更されないか確認する必要があります。先に示した Lam-Alef の修正の場合、既存のアプリケーションの中には、古いフォント中のグリフの (文書化されていない) 順番に依存しているものがあることが判明しました。そのようなアプリケーションは、単にグリフを置き換えるだけでは壊れてしまうでしょう。そこで、フォント チームはインターナショナル アプリケーション互換性チームと緊密に働き、変更がフォント中のグリフの順番に影響を及ぼさないようにし、その結果下位互換性を提供できるようにしました。

[フォント] コントロール パネル

Windows 7 での非常にたくさんの新しくそして拡張されたフォントとともに、私たちはユーザーがもっと簡単にフォントを管理できるようにしたいと思いました。そこで、数年ぶりに、コントロール パネルの [フォント] の徹底的な見直しを行いました。

下記の最初の図は、[フォント] コントロール パネルを大アイコンで表示させたところです。最も顕著な違いは、フォントのアイコンがフォントの外観についてより多くの情報を伝えてくれることです。アイコンの内容は、フォントのグリフのレパートリーに関するヒントを与えてくれます。非ラテン語のフォントは、それがどうデザインされているか分かるように書体から代表的なグリフを表示します。微妙な変更点として、あるフォントのアイコンは薄くなっていますが、これはインストールされているが隠されていることを示しています。隠しフォントはデフォルトではリボンやフォント ダイアログには表示されません。ユーザーは、[フォント] コントロール パネルで、日常的に使用するフォントを調整できます。まったく使用しないフォントを隠すことにより、アプリケーション内で適切なフォントを選択する動作を単純化できます。デフォルトでは、ユーザーがインストールしている入力ロケール (キーボード レイアウトと言語) で書ける言語をサポートしているフォントのみが表示されます。たとえば、英語とフランス語の入力ロケールをインストールしているユーザーは、ラテン語のフォントのみを見ることになりますし、一方で日本語入力方式をインストールしているユーザーは、日本語フォントだけを見ることになります。このデフォルト設定は、コントロール パネルでフォントを右クリックすることにより、変更することができます。隠しフォントはインストールされているので、隠しフォントを使用するような既存のアプリケーションもこれまでと同様に動作します。

大アイコン表示の [フォント] コントロール パネル

次の下の図は、[フォント] コントロール パネルを詳細表示させたものです。これにより、ユーザーはフォントについてこれまでよりも詳しい情報を得ることができます。たとえば、フォントをスタイルや表示/非表示、フォントの製作者で並び替えることができます。通常、フォント ファイルにはフォントのデザイン言語の情報しか含まれていません (たとえば、日本語のフォントは、情報を日本語でしか持っていません)。Windows 7 では、すべての言語ですべてのフォントに対して機能するソリューションが必要でした。そこで、フォント自身からの情報をメタデータ (システム上のフォントについて情報を提供する XML ファイル) と組み合わせるハイブリッドなやり方を考え出しました。

詳細表示の [フォント] コントロール パネル

ローカル パック

Windows 7 では個人用設定の選択肢が増えました。新しいテーマ、背景、およびサウンドにより、Windows 7 を自身の個性にマッチさせるよう簡単にカスタマイズできます。私たちの好みは言語や地域によって影響を受けるという点を、Windows 7 はローカル パックの導入という形で反映しています。ローカル パックは、特定の地域用にカスタマイズされた Windows 7 の視覚テーマを提供します。視覚テーマには、その地域に関連する壁紙の画像や、カスタマイズされた Aero グラスの色、地域色の濃いサウンド設定が含まれます。Windows® Internet Explorer® のお気に入りや RSS フィードも、コンピューター上でローカル パックが有効になっていると更新されます。たとえば、フランスのローカル パックを追加して有効にすると、コントロール パネルの [個人設定] にフランスの市場用にカスタマイズされたテーマが追加され、ユーザーのプロファイルに役に立つフランス公共部門のウェブサイトへのリンクや RSS フィードが追加されます。

 

[個人設定] コントロール パネルのカスタマイズされたテーマ

ローカル パックの中身は、すぐに使えるシームレスな地域のエクスペリエンスを提供します。ローカル パック自体はユーザーの目には触れません。ユーザーは単に Windows の「ようこそ」でいつもどおり自分の場所を選ぶだけです。そうすると、設定に基づいて、適切な地域のコンテンツが表示されます。

他の国用のテーマを探しているユーザー、または他の分野に興味のあるユーザーは、コントロール パネルの [個人設定] の [オンラインで追加のテーマを取得] リンクからアクセスできる、Windows オンライン ギャラリーで見つけることができます。

その他の機能

他の新機能には、5 つの新しいロケール (これにより、サポートされるロケール数の合計は 210 になりました)、12 の新しい入力ロケール、および中国語繁体字の改善された並び替えがあります。また、概して、システムのデータベースを Unicode 標準の最新バージョンである 5.1 にアップデートしました。開発者がよりよいグローバル アプリケーションを開発できるようにインターフェイスも改善しました。後述の [インターナショナルの適時性と品質] セクションで説明しますが、Extended Linguistic Services (ELS) はクールな新しい機能です。

おそらく、コアのインターナショナルの機能以外で最も重要な改善は、検索についで、より多くの言語を認識するようになりました。たとえば、Windows 7 のデスクトップ検索はロシア語の形態論 (単数、複数、時制、および格の決まり) を認識します。つまり、ロシア語のある特定の単語の検索は、これまでの完全一致の単語だけでなく、単語の一般的なバリエーションに対してもマッチさせ、検索結果が格段に向上します。

 

インターナショナル版リリースのタイミングと品質

前回のバージョンの Windows では、すべての言語の最終製品をすべての市場へ提供するのに数ヶ月かかりました。Windows 7 では、この時差をかなり短くするためにインターナショナル版への取り組み方を変え、世界中のユーザーができるだけ同時に Windows を楽しめるようにしました。この目標は、エンジニアとしてどのように作業を行うか、また、公開テスト期間中にパートナーや顧客とどのようにやりとりするかに対し、広範囲にわたって影響を及ぼしました。

私たちの取り組みを理解していただくために、まず 2 つの重要なコンセプトであるローカリゼーションとグローバリゼーションについて説明します。

ローカリゼーションは、ユーザー エクスペリエンスを他の言語に適応させるプロセスです。文字列の翻訳だけでなく、ダイアログのサイズを変更したり、ヘブライ語やアラビア語のように右から左へ書く言語のためにアイコンを逆にするといった作業があります。メニューの翻訳ミスのようなローカリゼーションのバグは、このプロセスで発生する欠陥です。

一方、グローバリゼーションとは、ユーザー インターフェイスが何語であろうと、すべての国で正しく動作する製品を作るプロセスのことです。グローバリゼーションのバグは、誤った言語で UI の要素を表示するような単純なものから、右から左への文字列の処理が正しく動作しないなど複雑なものまで多岐にわたります。グローバリゼーションのバグは、本質的にローカライゼーションのバグよりも深刻です。なぜなら、グローバリゼーションのバグは通常、多くのまたはすべての言語に影響を与え、技術的な設計を考え直さなければならないことがよくあるからです。過去の Windows では、グローバリゼーションのバグを修正することで、長いリリースの時差が必要になっていました。しかし Windows 7 では、グローバリゼーションのバグを、開発プロセスのできるだけ初期の段階で防ぎ、見つけ、修正するように取り組みました。

擬似ローカリゼーション

一般的なグローバリゼーションのバグを防ぐために、擬似ローカリゼーション ビルドが作られました。擬似ローカリゼーションとは、人工言語でローカライズした製品を作るプロセスのことです。その言語は英語とそっくりですが、それぞれの文字は英語の文字に見た目が似た別の文字で書かれています。完全にマシンによって生成されることを除き、擬似ローカライズ ビルドはローカライズ ビルドを作るのとまったく同じ方法で作られます。英語しかわからないソフトウェア開発者でさえ擬似ローカライズのテキストは読めるので、開発サイクルの初期にグローバリゼーションの問題を発見する大変優れた方法となっています。Windows 7 のベータでは、いくつかの UI 要素はまだ擬似ローカライズの状態でしたが、この意味について面白い説が唱えられていました。このブログの投稿で謎が解けたかと思います J

擬似ローカライズ版 Windows 7のコントロール パネル

パイロット言語

ベータ版は私たちにとって常にワクワクするときです。なぜなら、みなさんから私たちの努力に対して本当に意見を聞くことができる最初のチャンスだからです。113 の国の人たちが Windows 7 Beta をダウンロードしたと聞いて、感激しました。このように規模が大きく、多様性のあるベータ プログラムでは、フィードバックを集めて具体化するには、高度に拡張性のあるプロセスが必要です。Windows 7 では、新しい取り組みに大変張り切りました。

過去に、Windows のベータ版用のローカリゼーション言語は、実用的な理由が入り混じって選択されていました。このような場当たり的なアプローチはメリットもありましたが、重大なグローバリゼーションの欠陥が選ばれた言語では現れず、報告されなかったということがよくありました。Windows 7 Beta では、私たちの優先事項はグローバリゼーションのバグを見つけることであり、そのため、これまでの経験上、特定の種類の欠陥が見つかりやすい 4 つの言語 (プラス 英語) に集中することにしました。

· ドイツ語 – とても長い単語があるため、ダイアログのサイズや配置の欠陥が他の言語より明らかになりやすいです。

· 日本語 – 何万もの文字、複数の非ラテン語の書体、入力方式エンジンの代替手段、特に複雑なつづりといった理由により、日本語は東アジア言語に影響する欠陥を見つけるにはうってつけです。

· アラビア語 – 右から左へ書き、前後関係によって形が変わるので (文字の形は隣接した文字による)、ドイツ語や日本語では実施できないテストで役立ちます。

· ヒンディー語 - Windows 95 と Windows 98 ではヒンディー語はサポートされておらず、この言語は完全に Unicode に依存しています。ヒンディー語をテストすると、古い (Unicode ではない) 欠陥を見つけるのに役立ちます。

ベータ期間中にこの 4 つの言語に集中することにより、多くの言語に影響を及ぼすグローバリゼーションのバグを見つけて修正できるチャンスを最大限に高めました。それに、実際の製品をリリースする前に、すべての言語のローカリゼーションを向上させるための時間も増えました。下記の図は、ベータで見つかった 2 つのバグですが、パイロット言語に注力したことの利点を示しています。

Windows 7 Beta 中に見つかったグローバリゼーションの欠陥

これらの言語を通じてグローバリゼーションのバグを見つけることに加え、OEM メーカーに対しても、彼らの製造プロセスにおいて言語に関するフィードバックを提供してくれるようお願いしています。多くの OEM メーカーは東アジアに拠点があるので、Windows 7 Beta を簡体字中国語、繁体字中国語、および韓国語にもローカライズしました。

RC の言語パック

先に説明したようなエンジニアリング プロセスの向上を主な理由として、Windows 7 RC では過去の Windows で実現したしたよりも多くの言語パックを提供することができました。Windows 7 RC の Ultimate バージョンを実行している方は、下記の 32 の言語パックを Windows Update からダウンロードできることにお気づきでしょう。

Windows Update にある 32 の Windows 7 RC 用言語パック

将来的には、Beta 版で利用可能な言語はすべて、RC版でも提供できるようにする予定です (たとえば、ヒンディー語は Windows 7 RC には入っていません) 。将来のバージョンではこの点を改善します。

 

世界中からのフィードバックを理解することについて

Windows 7 の Beta 版は 5 つの言語にローカライズされ、プラス数百の言語用にグローバル対応されているので、Beta 版のバグ報告も世界中のユーザーから受け取ります。Windows 7 の改善にはこのようなバグ報告が欠かせないので、製品の問題かどうか判断するために、バグ報告を読むのにかなりの時間をかけました。バグ報告は世界中のユーザーから非常に多くの言語で寄せられるので、単にフィードバックを理解するだけでなく、できるだけ迅速に対応できるような方法を模索しました。問題を早く理解すればするほど、フィードバックに対応できるチャンスが高まります。バグ報告はユーザーが話すあらゆる言語で寄せられるので、これは時に大変困難な課題です。

過去に、私たちは複数の言語によるバグ報告を手作業で処理していました。それは、個々のバグを確認し、原因となるコンポーネントの責任チームに適切にフォローしてもらえるようひとつひとつ手作業で翻訳するといったプロセスでしたが、とても時間がかかり、しかも Windows 7 Beta のように規模の大きく多様性に富んだプログラムでは、見積もりを間違いやすい方法でした。最悪のケースでは、最終製品に影響を及ぼすような価値のあるインターナショナルのフィードバックが見過ごされ、Service Pack や次期バージョンまで対応がなされない可能性もあります。

Windows 7 では、新しい拡張言語サービス (Extended Linguistic Services, ELS) の言語検出 API を使用することにより、報告されたユーザーからのバグの言語を自動的に検出できるようになりました。ELS は Windows 7 の新機能で、OS の高度な言語機能を活用したい開発者は誰でも利用可能です。Windows 7 から、開発者は Unicode テキストの言語やスクリプトの検出や、文字間でテキストをマップさせるような書き直しに ELS を使用できます。この Windows 7 のサービスおよび今後のリリースに追加する予定のさらなるサービスを使用するには、開発者は 1 つのシンプルで統合されたインターフェイスを学ぶだけです。100 以上の言語を検出する能力が Windows 7 のアプリケーション開発者に提供されますが、この機能をみなさんが世界中から送ってくださったベータ フィードバックの優先度を判定して処理するのに適用することができました。ユーザーからのグローバルな問題に対する対応を向上するため、私たちは自身のインターナショナルの開発機能を使用したわけです。

言語を検出すると、続いてその結果のテキストを用いて、機械翻訳サポートを使用します。機械翻訳は、オンラインの Live Translator で利用可能です。これにより、テキストを英語に翻訳し、フィードバックの言わんとすることを理解します。そしてエンジニアは、特徴や機能性の分野を、私たちのフィードバック データベースで検索します。ユーザーが報告するとすぐに、問題となりそうなインターナショナル アプリケーションのエクスペリエンスについて学べるので、インターナショナル アプリケーションの互換性の確認にも役立ちます。機械翻訳は完全な翻訳ではありませんが、どの問題がさらなる調査が必要そうかの判断には使えます。その結果、ユーザーの問題に対して耳を傾け対応することが、前回のリリースよりも格段に短い所要時間で実現できるようになりました。つまり、世界に Windows 7 をリリースしたとき、それはよりよい品質であるということです。

Windows 7 Beta の終了時までに、このプロセスを使用して、フィードバック ツールを使って寄せられた 35,408 件の問題や意見を翻訳しました。

まとめ

グローバリゼーションとローカリゼーションの品質向上に対する取り組みの最終結果は、「すべての完全にローカライズされた言語版の Windows 7 は、10 月の最初のリリースから 2 週間以内にリリースされる」と言う発表に現れています。私たちは、ユーザーのみなさんが、このリリースの全体的な品質がこれまでで一番よいと思ってくださることを願っていますし、それを信じています!

2009 年 10 月にリリースされる Windows 7 の 36 言語

10 月にリリース予定の 36 言語に加え、追加の言語が、どのエディションの Windows 7 にもインストール可能な言語インターフェイス パック (Language Interface Packs, LIP) の形でダウンロードできるようになる予定です。これは、世界中の政府、大学、言語学者との共同研究である、ローカル言語プログラム (Local Language Program, LLP) の一環です。LLP の一環です。(LLP の詳細については、http://www.microsoft.com/unlimitedpotential/programs/llp.mspx を参照してください)。LIP の作業は RTM と同時に開始し、パートナーのスケジュールに基づいてその後何か月も続きます。2 つの LIP が 10 月の Windows 7 と同時にダウンロード可能になる予定です。それは、カタロニア語とヒンディー語です。その他の LIP は、パートナーのスケジュールに基づいて随時ダウンロードできるようになる予定です。最初の 38 言語 (36 + 2 LIP) について、提供時期を改善できたことをうれしく思います。そして、将来のリリースにおいて、さらに改善していきます。私たちの方で信頼できる実績を作り上げることは、世界中の人々が、より統一されたリリース スケジュールの計画を立てるのに役立ちます。

拡張言語サービス (ELS) およびその他の Windows 7 のすばらしい新機能についての詳細は、オンラインで MSDN で提供しています。特に、Windows 7 用の Windows SDK をダウンロードし、「International」セクションで最新情報について読まれることをお勧めします。また、MSDN の新しい Go Global Developer Center には、インターナショナルのテクノロジーについて豊富な情報があります。

フィードバックについては、このブログ エントリに対してコメントしていただくか、Windows 7 のフィードバック ツールを使用してください。皆さんからのご意見を (どの言語でも) お待ちしています。

-- Windows International Team

Windows 7 での ClearType の技術的な変更点

Bill Gates が持っている数多くの情熱のうちの 1 つは読むことであり、PC 上で読むことを快適なエクスペリエンスにするという彼の望みは、長年にわたり続けられてきた取り組みです。1998 年の COMDEX で、Bill Gates は ClearType を発表しました (こんなにも昔のことだったなんて、信じられません)。発表時、LCD モニターを持っていた人はごくわずかで、15 インチの 1024x768 モニターが数千ドルもしました (今だと 100 ドルもしないようなもの)。スムージングやアンチエイリアシングという概念はずいぶん前から存在しており、タイポグラフィ (文字体裁) やアニメーション、ゲームの世界では一般的なものです。ClearType は LCD パネルの特性を基盤として、これを新たなレベルに引き上げました。ClearTypeはその後 Windows XPに搭載され、Vista と Windows 7 にも引き続き入っています。リリースごとに、基礎となるテクノロジー、それをサポートするフォント、および開発者が利用できる API が変更されてきました。ユーザーの中には、ClearType で表示した画面をそれほど良いと思わず、この機能を無効にしたいと考える人々もいることが長年の間に判明しています。私たちはこれを認識しており、適切なコントロールを提供できるようにしたいと考えています。ClearType は Windows プラットフォームの一部でもあり、アプリケーションの開発者が呼び出してコントロールできる API を提供しています。ClearType は「視覚的な好み」であるという従来からの見方があり、この投稿でも好みと言える一面があることを紹介したいと思います。しかし、アプリケーションによって使用される API であるという一面、つまり、アプリケーションが必要に応じてフォント、色、その他の属性を選択できるのと同じである、ということについても説明したいと思います。この投稿では、歴史や背景を交えながら Windows 7 での実装の詳細に踏み込んで説明します。Greg Hitchcock は ClearType の開発リーダーで、開発当初から担当しています。 また、Windows 7エンジニアリング チームで在職期間が最も長いメンバーのうちの 1 人です。彼より Microsoft での在職期間が長い同僚はたったの 6 人しかおらず、そのうちの 1 人は Larry です!

--Steven

フィードバックに基づき、Windows 7 におけるフォント レンダリングのしくみを明確にし、ClearType フォント レンダリングが、どのような経緯で Windows のデフォルトとして選ばれたのかについて説明します。ClearType が好きではなく、システムのデフォルト設定を Windows Me でデフォルトだった 2 階調のレンダリングに変更したいときは、次のステップを実行します。

• [スタート] メニューの [検索] で「視覚」と入力する
• コントロール パネルから [Windows のデザインとパフォーマンスの調整] を選択する
• カスタム オプションの下で、[スクリーン フォントの縁を滑らかにする] をオフにする

この投稿でこれから説明するより詳しい答えは、デフォルトの設定を変更しても「白黒」のようにはっきり認識できるわけではないことをご説明します。お気付きのように、Windows 7 のコントロール パネルには新しい ClearType チューナーも含まれており、レンダリングを詳細にコントロールすることができます。これについても、この後で詳しく説明します。

ClearType

ClearType は、フォント レンダリングのデザインおよびコンピューター ディスプレイで読むことのパフォーマンスの両方を向上させるために開発されたテクノロジです。ほとんどのユーザーがコンピューターでの作業の 80% 以上を画面を読むことに費やしているため、この分野における向上は Windows の全体的なエクスペリエンスの大幅な向上につながります。ClearType テクノロジは絶えず進化しており、E7 ブログの以前の投稿で説明したように、最新の変更は Windows 7 に盛り込まれました。

簡単に説明すると、ClearType は、ディスプレイの色付きのサブピクセルの基になるジオメトリを完全なピクセルであるかのように使用することにより機能します。それによって、より優れた解像度を得ると同時に、色の影響の認識を排除するために人間の視力の原理を使用しています。テクノロジの詳細および人間の視覚的な認識をどのように利用しているかは、こちらで説明されています。具体的には、ClearType テクノロジは、赤、緑、青 (RGB) が垂直方向に並べられているサブピクセルを備えた LCD に対して最適化されていますが、CRT ディスプレイ (特にアパーチャ グリル形式のもの) や RGB が水平方向に並んでいる LCD でも十分に機能します。これは直観に反しているように思えるかもしれませんが、非公式な研究の結果、ユーザーの約 70% がこれらの最適でないディスプレイでも ClearType を好むことがわかりました。他のレンダリング技法を好んだ 30% のユーザーにとって、これらの最適でないディスプレイにおける ClearType に関する最大の懸念事項は、テキスト コントラストの損失でした。

Windows のほかの種類のフォント レンダリング

多くのディスプレイ方式、さまざまなユーザーや視覚体系が混在する中で、私たちはどのような経緯で Microsoft Windows に ClearType を実装することにしたのでしょうか? Microsoft は、がむしゃらに ClearType をデフォルトのレンダリングにしようとしたわけではありません。テクノロジは、2000 年に Windows CE 製品で初めてリリースされました。Windows CE 環境は通常、使用されるハードウェアが十分にコントロールされているため、ClearType が各デバイス上で適切に機能するか容易に検証でき、画面の読み取りエクスペリエンスを最適化するために ClearType またはハードウェアを調整することも簡単でした。Windows プラットフォームでの ClearType の最初のリリースは 2001 年の Windows XP でした。

2 階調レンダリング

2 階調レンダリングの例。ブラウザによってこの画像が拡大/縮小されている場合、テキストが正しく表示されない場合があるのでご注意ください。

Windows XP より前では、2 種類のフォント レンダリングが Windows でサポートされていました。まず 1 つ目は 2 階調レンダリングですが、「白黒」レンダリングという呼び方の方が一般的かもしれません。エイリアスされたテキストと呼ばれることもあります。2 階調レンダリングでは、2 つの色 (前景色および背景色) でフォントを表します。これは Windows 3.1 がリリースされた時に TrueTypeによってサポートされていた最初の種類のレンダリングですが、Windows 1.0 からのビットマップ形式のフォントを表示するために欠かせない方法でもありました。2 階調レンダリングは、特に TrueType のようなアウトライン テクノロジから生成された場合は、画面の解像度が低いと、最適化が非常に困難です。2 階調で最良の品質を得るためには、TrueType フォントのヒンティングに相当の労力をかける必要があります。レンダリングの詳細をこのレベルに持ってくるには、ベテランでも 1 つのフォント当たり 6 か月から 1 年近くヒンティングに時間がかかるのが普通です。4 種類のフォント ファミリなら 4 倍になります。一部のシステム フォントのように、文字セットがより大きい場合は、さらに長くかかる可能性もあります。

フォントのスムージング / グレースケール

レンダリングの 2 つ目の形式は、フォント スムージングとして知られています。Windows 2000 のデフォルトのレンダリングになり、Windows 95 のオプションとして Plus! パックで初めてリリースされました。フォント スムージングは、従来のアンチエイリアシング技法のフォントのコントラストを向上させることを目指したハイブリッド グレースケール アンチエイリアシング技法です。従来のテキスト アンチエイリアシングとフォント スムージングを差別化するのには、2 つの要素があります。

まず、従来のアンチエイリアシングは、フォント アウトライン データを拡大してから、ダウンサンプリングすることにより機能します。フォント スムージングも同じ技法を使用しますが、アウトライン データを拡大する前に、フォントのヒント情報を適用する点が異なります。ここではフォントのヒンティングについての詳しい説明は割愛しますが、簡単に言うと、フォントのアウトラインがピクセル グリッドに合わせて配置されるよう、フォントのアウトラインの縦および横のエッジをスナップするために「グリッド フィッティング」と呼ばれる方法がよく使われます。このような場合、フォントのほとんどの縦および横のステムは、拡大時に、基になるピクセルの 100% をカバーし、ダウンサンプリングされた時は、テキスト前景色 （通常は黒） を返します。フォントの斜めの部分や丸みのある部分は、ピクセルを完全にはカバーしないため、一部は、基になるピクセルのカバレッジを反映した灰色の網掛けを返します。テキストに「ジグザグ」(より正確にはエイリアシング) が見られる場合、これは一般にグリフの丸い部分か対角線の部分で生じますが、ちょうどこの方法で灰色のカバレッジが返された領域です。この方法のアンチエイリアシングは、フォントにおけるステムのコントラストがより高く、一部の空間的精度のコストもごくわずかであるため便利です。

第 2 の差別化する要素は、フォント スムージングを有効または無効オフにする正確なサイズを決定するのは、フォントであるということです。このレベルの情報を提供するほとんどのフォントは、9 PPEM (pixels per em) より下のグレースケール アンチエイリアシングを有効にします。これは 96 PPI の画面では 7 ポイントに相当します。9 PPEM を超えると、フォントの主要ステムの幅が 2 つのピクセル程度、つまり約 13 ～ 20 ポイント程度でなければ、書体に応じてアンチエイリアシングは無効になります。主要ステムの幅が 2 ピクセルになると、サイズが大きくなってもアンチエイリアシングは有効なままになります。2 ピクセル幅のステムが一般的に基準とされるのは、ステムのコントラストが高い状態を維持するうえで、前景色のピクセルの「バックボーン」が 2 ピクセルあれば十分だからです。フォント スムージングに対する具体的なサイズがフォントで指定されていない場合は、システムの既定値が使用されます。標準書体とボールド書体はそれぞれ独立した既定値を持っています。したがって、フォント スムージングがデフォルトでも、ほとんどのフォントは、通常の読むサイズでテキストを表示する際、2 階調で表示します。

フォント レンダリングのデフォルト値

Windows XP に ClearType が追加されたことで、現在利用可能なフォント レンダリングの種類は 3 つ (2 階調、フォント スムージング、ClearType) となりました。Windows XP が開発されている間に、CRT モニターを備えたデスクトップ型から、ラップトップおよび LCD ディスプレイを備えたデスクトップへの明らかな移行が進んでいました。この移行はまだまだ完了しそうになかったので、私たちは Windows XP のフォント レンダリングのデフォルトは Windows 2000 と同様にグレースケール フォント スムージングにするべきだと感じました。システムとして Windows XP を提供する OEM は、このデフォルト値を変更できました。また、実際、Windows XP SP 2 が出荷される時期までには、OEM の多くが ClearType をデフォルトに設定していました。OEM は PC を構成する作業の一部として、これらの設定を常に変更できたことは注目に値します。

Windows Vista では、システムのデフォルトのフォント レンダリングは ClearType に変更されました。デフォルトのフォント レンダリングが何を意味しているかを明確に理解することが重要です。Windows では、デフォルトのフォント レンダリングとは、アプリケーションでレンダリングの種類が明示的に指定されていない時に使用されるレンダリングのことです。このデフォルト値が、すべてのアプリケーションが使用しなければならない値を意味するものと誤解しているユーザーもいました。この考え方は、Windows 95 のフォント スムージングが導入された時、テキスト API が機能した方法と矛盾しています。GDI では、現在のフォントを選択するための API は、レンダリングの種類を明示的に入力データとして持っています。どの種類のレンダリングを使用すると最適かをアプリケーションが一番よくわかっている状況があります。たとえば、小さなテキストが含まれている印刷プレビュー ページを表示する場合、レンダリング方法としては、従来のフォント スムージングが最良の選択肢となります。同様に、アプリケーションの目的が画面を読むことである場合は、そのアプリケーションのレンダリングとしては ClearType の使用が最も良いと思われます。状況によっては、リモート ターミナル サービスのように、アプリケーションでリモート クライアントに送信する必要があるテキスト情報の帯域幅を減らすために、2 階調のレンダリングの使用を選択することもできます。

アプリケーションがシステムのデフォルト以外のレンダリングを使用するために、別の方法を使用するケースは多数あります。異なるフォント、カラー、サイズあるいは他のテキスト属性を使用するアプリケーションなどです。最も一般的な例は、ドキュメントのレイアウトおよびフローを複製可能にするようなアプリケーションです。テキストのレンダリング方法を指定できるようにすることで、アプリケーションはテキストが異なる PC で表示される方法を確実に指定することができます。別の一般的な例は、先にも述べた印刷プレビューです。特に小さなテキスト サイズの場合に、より高い解像度の出力を適切にレンダリングして表示する能力が、非常に向上しています。私たちは、"表示" プロパティで表示される内容が、場合によってはアプリケーションで "覆す" ように選択できるものであることが、直観に反していると認識しています。私たちはデフォルトの状態での設定を考慮してレンダリングを設計しましたが、Windows 自体を含むアプリケーションでは明示的なレンダリング技法を必要とする要素がある場合もあります。

各アプリケーションはどのレンダリングを使用するかについて、フォント単位で選択できますが、大多数のアプリケーションはデフォルトのレンダリングを選択します。したがって、Windows Vista のデフォルト値を変更するという決断には非常にためらわれました。以前のブログの投稿で示したように、Windows XP および Windows Vista の実世界の遠隔測定によると、ハードウェア ディスプレイの傾向は、CRT から LCD ベースのディスプレイへの急速な移行を強く示していました。まだ CRT が使用されている時期でも、Windows XP ユーザーからのフィードバックは CRT での ClearType レンダリングの品質に対して肯定的でした。私たちが Windows Vista のデフォルト値として ClearType を有効にすることを決定した後、この決定に対するフィードバックは、肯定的なものがほとんどでした。

デフォルトのレンダリングが ClearType に設定されているとしても、デフォルト値を変更できるシナリオがいくつかあります。OEM がハードウェアで Windows を提供している場合、OEM でデフォルト値を変更できます。状況によっては、ハードウェアがレンダリング テクノロジの最小要件を満たしていない場合があります。これは Windows 95 のフォント スムージングではより一般的でした。フォント スムージングと ClearType の両方の場合は、最低 16 bpp のディスプレイ解像度が必要です (GDI のオフスクリーンのビットマップにレンダリングする際、ClearType テキストをキャプチャしたい場合は、デフォルトの色深度が 1 bpp でないことが重要です)。場合によっては、システム パフォーマンスを最適化するために、フォント スムージング (ClearType とグレースケールの両方) を無効にできます。同様に、別のコンピューターあるいはセッションへの接続にリモート デスクトップを使用する場合は、通常、ClearType をデフォルトで無効にします。

Winodws 7 でデフォルトのレンダリングを変更する

Windows 7 では Windows Vista と同じデフォルト値が維持されます。ユーザーが Windows 7 のフォント レンダリングのデフォルト値を変更するには、いくつかの方法があります。デフォルトのレンダリングを 2 階調にしたい場合、この選択のユーザー インターフェイスは、コントロール パネルのパフォーマンス セクションにあります。コントロール パネルのルートから、[システムとセキュリティ] -> [システム] -> [システムの詳細設定] -> [パフォーマンス] セクションの [設定] ボタンの順に選択することでアクセスできます。もっと簡単な方法としては、スタート メニューの [検索] で「視覚」と入力して、「Windows のデザインとパフォーマンスの調整」を選択します。カスタム オプションの下で変更する設定は、次の図に示すように、[スクリーン フォントの縁を滑らかにする] です。

フォント スムージングをまったく使用しないことをデフォルトとする設定は、一般的ではないと考えられるため、他の設定よりも若干見つけにくくなっています。デフォルトのフォント レンダリングの選択内容を、先に説明した Windows グレー スケーリング アンチエイリアシング技法に変更したい場合、Windows 7 では ClearType チューナーによって行います。

ClearType チューナー

ClearType テキストの品質は、ユーザーおよびモニターに対して最適化することができます。ClearType チューナーは Windows 7 の新しいコントロール パネル コンポーネントです。モニターの特性や読者の目には違いがあるので、そのモニター上でテキストを見る読者のみが最適化できるフォント レンダリング オプションがあります。ClearType チューナーは、ClearType アルゴリズムをきめ細かく調整するために視力検査の形式で表された、ClearType のさまざまなサンプルを使用します。各ウィザード ページでは、モニター ガンマ (電圧と明るさ間の関係)、色の影響に対する感度、文字の厚みの好みなどのパラメーターを調整します。

ClearType とグレースケールを切り替えるには、ClearTypeチューナーの最初のページの [ClearTypeを有効にする] で切り替えることができます。

いずれにしても、アプリケーションが ClearType レンダリングを明示的に有効にしている場合、一部のグラフィックス プラットフォームには、グレー レンダリングおよび ClearType の両方についてより細かい調整機能がある場合、ClearType チューナー ウィザードは最後まで実行されます。

フォント デザインとフォント レンダリング

ClearType のような高解像度フォント レンダリング技法の登場は、画面を読むためのフォントのデザインに大きな影響を与えてきました。印刷機の時代から、新しい技術と印刷スタイルが開発されると、これらのテクノロジを活用するために書体がデザインし直されました。たとえば、現在でも使用されている多くの書体では、グリフの主要な特徴がインクでつぶれてしまわないようにするために、デザインに "インク トラップ" を取り入れています。これは、テクノロジを最大限活用するため、フォントにおいて特定のデザインの選択を行う 1 つの例です。従来の書体デザインでは、フォントという言葉は、所定のサイズでの書体を指します。したがって、10 ポイントの Times New Roman と 24 ポイントの Times New Roman は異なるフォントとなります。金属製のタイポグラフィの時代、それぞれのサイズは使用されるメディアに合わせてパンチ カッターを使ってデザインされ、所定のサイズでのステムのコントラスト、x-height、文字間隔を変更しました。20 世紀半ばに写真植字が登場すると、活字のマスターとしての 1 つのサイズが使用され、それを光学によって任意の表示サイズに拡大縮小していたため、この点に関しては後退したことになります。

Microsoft Windows ではデジタル アウトライン フォントに対してより伝統的なアプローチを取ってきました。私たちは、フォント ヒンティングおよび新しい書体デザインの組み合わせによって、意図されたメディアの各サイズを最適化しようと考えています。Microsoft の Windows 3.1 で初めてリリースされた TrueType では、伝統的な書体である Times New Roman、Arial、および Courier New が基本フォントとして使用されました。これらのフォントの作成では、1 つのマスター サイズがアウトライン データとして選択されました。通常は、10 ～ 12 ポイントで、写真植字で使用された技法のように、アウトラインを所定のディスプレイ解像度の必要なサイズに拡大縮小しました。ただし、従来の方法にならって、各サイズの検査を慎重に行い、フォント ヒンティングによって基本デザインを変更しました。これには、ステム コントラスト、x-height、グリフ間隔のような重要な特徴への変更などがありました。先にも言及したように、96 PPI の画面上の完全なピクセルといった低解像度の媒体用に調整するためのフォントのヒンティングは、非常に時間のかかる作業でした。Microsoft Windows におけるこの処理を助けるため、私たちは 96 PPI の 2 階調レンダリングの世界に最適化された新しいアウトライン書体のデザインの委託をしたり社内で独自にデザインしました。これらのカスタム フォントには、Tahoma、Verdana、Georgia、Trebuchet MS、さらには Comic Sans MS などがあります。個々のサイズを調整するためには、これらのフォントのヒンティングが必要となりますが、媒体を念頭に置いて書体がデザインされているため、より簡単な処理となり、それほど時間もかかりませんでした。

ディスプレイ媒体に合わせて調整された書体でも、画面上の 96 PPI ピクセルは、書体で表示したい多くの機能よりさらに大きくなります。そして、このようなところで ClearType が役立ちます。したがって、ClearType により、新しい媒体に最適化された新しい一連のフォントを依頼することは理にかなっています。Windows 用の既存のフォントは、このテクノロジで現在も十分に機能します。しかし、このプロジェクトは、ClearType を使用して画面を読むために最適なデザインを見つけようという試みでした。その結果、Windows Vista 用にチューニングされた新しいフォント セットが誕生しました。ClearType コレクション フォントである Calibri、Cambria、Consolas、Corbel、Candara、Constantia、新しいユーザー インターフェイス フォントの Segoe UI、および日本語フォント Meiryo は、この媒体用に設計されました。ClearType のデフォルトの設定と共に、これらのフォント プロジェクトのエンジニアリング作業の一部として、ヒンティングのプロセスでは ClearType 用のみ詳細なサイズ固有のヒントづけを行い、2 階調レンダリングではしないことに決めました。これにより、大部分のユーザーのために、より細かいレベルおよび高い品質を目指した作業に集中することができました。

Windows 7 の ClearType フォント

自分たちに対して質問すべきことは、Windows 7 で 2 階調またはハイブリッドのフォント スムージングをデフォルト値として選択すると、どのような結果になるのか? という点です。

前述のように、すべてのアプリケーションがデフォルトでレンダリングするように選択しているわけではありません。Microsoft Office と Internet Explorer は、一部のケースで ClearType レンダリングの使用がデフォルトとなります。2 階調レンダリングではなく ClearType 用にチューニングされたフォントを使用する一部のアプリケーションは、フォント デザインの利点を維持するために ClearType レンダリングを選択する場合があります。一部のアプリケーションは、サブピクセル ポジショニングあるいは "自然幅 ClearType" のような高精度のグリフ幅が必要で、この場合に 2階調レンダリングまたはグレースケール レンダリングに変更されると、流れに逆らうことになります。Adobe Reader のような他のアプリケーションは Windows グラフィックス プラットフォームに依存しない独自の組み込みテキスト レンダリング エンジンを備えています。同様に、Windows 上の Java のようなプラットフォームも独自のレンダリング技法を使用しています。

場合によっては、Windows 7 エクスプローラーで、Segoe UI が最適なデザインを維持するように、ClearType レンダリングがそのまま使用されます。Segoe UI から他のフォントにシステム フォントを変更することには問題があり、ダイアログ ボックス エントリの流れが逆になったり、テキストが折り返されて見えなかったり、ボタンのラベルが付いていないなどの問題につながります。ほとんどの人が Windows で使用されるフォントへのグローバルな変更を評価すると思いますが、たとえば解像度、DPI、言語などの領域にまたがって確実に維持するためには、現時点において、システム フォント設定に総合的な柔軟性を持たせることはできないということを意味します。

ClearType をオフにするという課題がある中、ClearType を利用できないシナリオに対応するための、フォントでの緩和措置があります。ClearType フォントの Calibri は、Microsoft Office のデフォルトのフォントであるため、フォント スムージング グレースケールが選択されたときに、フォント レンダリングの品質を向上させることを試みるため、変わった方法が取られました。この場合、ぼかしを除去するために小さいサイズのテキストでフォント スムージングを無効化するという正常な状況に反して、これらの小さいサイズのテキストで、文字の形状を改善するために、フォントはグレースケールを有効にしました。さらに、いくらかのキー サイズでは、Calibri フォントはアウトライン ファイルにいくつかのビットマップ フォントを埋め込みました。これらのビットマップは 2 階調レンダリングが要求された場合に役立ちます。これらのビットマップは、Calibri がリモート端末で使用されていて、リモート端末のデフォルトがパフォーマンス上の理由から ClearType に設定されていないという状況に対処することが目的です。

ClearType のパフォーマンス調査

先に述べたように、ClearType の背景にある目的の 1 つは、コンピューター画面上でテキストを読むパフォーマンスを向上させることです。私たちは、この作業の評価に関する複数の研究をサポートしました。研究は大学で行われ、専門誌で発表されています。ほかにもフォントに関係する Microsoft ブログ があり、そこでは読むパフォーマンスに関する研究内容が説明されています。それらのブログ エントリに詳細および背景情報が説明されているため、ここでは、パフォーマンスの特徴のみいくつか説明することにします。

· 測定の結果、2 階調レンダリングに対して、ClearType を使用した場合、単語認識の正確さが 17% 向上しました。

· 分かったことは、2 階調レンダリングに対して、ClearType を使用した場合、読み取り速度が 5% 向上し、理解力が 2% 向上すること (これは注目に値します) です。5% の読み取り速度の向上は小さく思えるかもしれませんが、ユーザーが読み取りに費やす時間の長さを考えれば、累積した効果は大きなものになります。

· 分かったことは、読み取り速度の 5% の向上は広範囲におよぶテキストで継続されることです。また、ドキュメント スキャンのような非伝統的な読み取り作業では、2 階調レンダリングに対し、ClearType では約 8% も高速になることを発見しました。

· 分かったことは、部分的に最適化されたテキストを読むことは、目を細めることが増え、瞬きの回数が減るため、眼精疲労の原因になることです (当たり前に思えるかもしれませんが、この研究を行う前は、眼精疲労の生理学的なメカニズムはわかっていませんでした)。

レンダリングの好みに関する ClearType の調査

私たちが疑問に思った別の問題は、なぜ一部のユーザーが ClearType よりも 2 階調レンダリングを好むのか? という点です。ハードウェアに関する問題なのか、何らかの影響を持つ視覚のしくみについて、私たちも理解していない特性が存在するのか。これは長い間、私たちの好奇心を刺激した問題です。これをさらに調査しようとする初の試みとして、Microsoft の近くのコミュニティー センターにおいて、非公式で小規模な好みの研究がなされました。2 台の同一のノート PC を、1 つは ClearType、もう 1 つは 2 階調レンダリングの設定で用意し、並べて配置して、参加者にどちらが好きかを尋ねました。これを 3 つの異なるサンプルに対して行いました。結果は次のとおりです。

	ClearTypeの方がよい	2 階調の方がよい	どちらでもよい
サンプル 1	33	1	1
サンプル 2	33	2	0
サンプル 3	33	2	0
平均 %	94%	5%	1%

備考:

1. 参加者は 35 名。
2. 2 階調レンダリングに対する感想:
   ぼやけている。ジグザグ。粗い。これがプリンターだったら、新しいカートリッジが必要だったと思う。特に数字が消え入りそう。読むときは目を細めないといけなかった。眼鏡か、私のせいでしょうか? 集中することができない。気が散る。読もうと努力しなければならない。繋ぎ目がある。
3. ClearType に対する感想:
   はっきりしていて、太く見える (複数回答)。濃く、はっきり見える (4 人)。コンピューターの画面が優れているように見える (ユーザーは、2000 ドルのノート PC に対して、画面が良くなるのであれば、さらに 500 ドル払ってもいいと提案しました)。青っぽくて、濃くて、読みやすい (3 人)。きれいで、切れがあって、こちらの方が好き、良く見えて、気に入っている。これは非常に明白に見える。

ほかに 2 つのテストを実施しましたが、2 階調レンダリングよりも ClearType を好んだのは、一方の調査では、30 人の参加者のうちの 28 人、もう一方の調査では、55 人の参加者のうちの 52 人でした。これらの 3 つのテストを総合すると、120 人中 113 人の参加者が 2 階調レンダリングよりも ClearType レンダリングを好むという結果になりました。このように、どちらか選ばなくてはならないテストでは、ClearType が良いと言ったからといって、その人が 2 階調レンダリングを嫌いなわけではない点に注意する必要があります。単に、どちらかといえば ClearType が良いということです。

2 階調レンダリングを好む人々についての詳しい検査は私たちにとっての最大の関心事であり、引き続き、大学の研究者と共にこのトピックについて調査を進める予定です。将来このトピックに関する論文が発表されことを期待しています。

今後の調査

この先、私たちの調査のほとんどは、最も高い品質のテキスト レンダリングを誰でも利用できるようにする方法を見つけることにあります。どの視覚体系にもそれぞれ独自の特性があり、ClearType チューナーで表示特性のアルゴリズムをチューニングできるのと同じように、視覚体系の特性についてもチューニングできれば良いのではないかと思います。たとえば、米国では、男性人口の 7% は色覚障害を持っています。私たちは、ClearType アルゴリズムを向上させることで、障害を持っていない読者よりも、色覚障害を持つ読者にとってテキストがより見やすくなるようにできると信じています。高色感度の人や視力の低い人向けのテキスト レンダリングを向上させる方法の研究も同様に重要です。

最後に

画面で読むことを最適な状態にすることは、私たちにとってワクワクするようなチャンスです。それは、さまざまな表示テクノロジと人間の視覚体系での取り組みというエンジニアリング上の課題と、美しい一連のグリフを作成するという芸術的な課題の融合であり、活字の細かいニュアンスすべてが重要となります。これを行う際に、私たち人間にとって最適な経験を実現するうえで、読むことに関する科学をどう利用するべきかに留意する必要があります。レンダリング テクノロジにはさまざまなユーザーにとっての利点と欠点があります。使用するアプリケーションによっては、トレードオフも伴います。これらの問題点の多くはユーザーが簡単に識別できるものではありません。私たちの役目は、優れたプラットフォームと、ユーザーがどのようにテクノロジを使用するか決めたりコントロールしたりするのに使用できるツールを開発者に提供するため、一生懸命努力することです。私たちの目標は、そのまま使ったときに適切に機能させることです。私たちは、通常、これを達成していると思っていますが、この領域は複雑で、さまざまなフィードバックがあるということも認識しています。

これらの問題に取り組んでいる Microsoft のチームは、1990年以来、フォントおよびフォント レンダリング ソリューションを開発し、読むことの科学に関する理解を深めるために努力してきました。チームはエンジニア、設計者/アーティスト、および心理学者から構成され、Microsoft 中のその他さまざまな専門家と共に作業して、手強くて極めて重要な作業に取り組んでいます。あなたは、コンピューターでの作業の 80% 以上を、画面を読むことに費やしています。したがって、できるだけ快適なエクスペリエンスであるべきです。この IEEE Spectrum の記事は、テキストのテクノロジー、アート、および科学に関して、私たちが扱っている問題のいくつかを説明しています。

--Greg

Windows 7 でのオーディオの不具合に対する回復力の向上

PC 上で優れたオーディオの再生をもたらすことは、「みかけよりもはるかに難しい」技術的な課題のひとつです。専用のオーディオ機器やビデオ機器と異なり、PC ではオーディオの再生中にもさまざまなことが起きており、とてつもないハードウェアとソフトウェアの組み合わせの環境下で再生は行われています。みなさんの多くは、時々生じる「グリッチ (音飛びや画像飛びの不具合)」についてご存じでしょう。この投稿では、Device and Media チームのプログラム マネージャーである Kristin Carr が、Windows 7 でのこの分野で向上した点について、チームのメンバーを代表して説明します。プロダクト サイクルの初期に私が学んだことは、「不具合ゼロ」よりも「不具合からいかに早く回復するか」が大事だということですが、みなさんもこれを読んでお分かりいただけると幸いです。 --Steven

みなさんは MP3 や DVD を再生するために PC を使用したことはありますか? はいと答えた人は、映画を見る、ゲームをする、YouTube のクリップを見るなどさまざまなオーディオおよびビデオ アプリケーション用にコンピューターを使用している PC ユーザーの圧倒的大多数のひとりです。しかし、オーディオやビデオがちゃんと再生されない－ おそらく、ビデオが少しガクガクしたり、オーディオが途切れたりといった経験もお持ちだと思います。この再生エクスペリエンスを中断させるような、オーディオやビデオにおける認識できる途切れを、「グリッチ (glitch)」と呼んでいます。グリッチの原因となるエコシステムの課題を分析し、Windows 7 のエクスペリエンスを向上させるために私たちが取り組んできたことについてお話していきます。

何がグリッチを引き起こすか?

これまでの投稿で、Windows 7 に対して私たちが取り組んできたさまざまなエコシステムのイニシアチブや課題について、とりわけ アプリケーションの互換性、アクセシビリティ、および システムのパフォーマンス について述べてきました。オーディオのグリッチの根本的な原因を調査しても、同じような場所に行き着きます。なぜなら、Windows は多様なハードウェア構成および 10個以上のアプリケーションによるマルチタスクの上で動いており、コンピューター上で動作しているすべてのプログラムやドライバーがきっちり期待通りに機能しているかどうかを確かめるのは至難の業です。

オーディオは特に繊細です。スピーカーから音楽を聴くには、データがオーディオ ハードウェアへ約 10 ミリ秒ごとに送られなければなりません。これは、まばたきの 30倍の回数です! 難題は、音楽を聴いている間にも、PC は TouTube のビデオを流したり、新曲をダウンロードしたりとたくさんのことを行っており、しかもその多くは複雑なタイミングを要求するということです。ご想像のとおり、遅いネットワーク ドライバーや長大な CPU 時間を必要とするグラフィックス ドライバーなどが、連続してオーディオが耳に届くのを妨げるのはわけないことです。

では、この難題へ対処するために私たちが行ったことは何でしょう? 答えは「たくさん！」です。そして、このブログの残りは、それらの説明に充てます。

1. 問題を特徴づけるためのデータを収集する
2. グリッチを検出して解析するための系統的な方法を開発する
3. テストやツールを Microsoft と Windows パートナーの双方で広く展開する
4. グリッチの問題を検出、診断、修正するためにパートナーと協働する

誰がグリッチを経験しているか?

Windows 7 の開発サイクル中にこの研究をするにあたり、まず手をつけなければならない仕事はデータの収集でした。オーディオ グリッチに関する報告は聞いていましたが、問題の正確な範囲はわかりませんでした。ユーザーはどのくらいの頻度でオーディオ グリッチを聞いているのか? 他と比較してパフォーマンスの悪い特定マシンはあるのか? これらの質問を念頭に、問題をより理解するために着手しました。

私たちは、Windows に組み込まれている テレメトリー (遠隔測定) のインフラ を使用して、データを集めました。テレメトリーは、ユーザーが、OSの改良に役立つパフォーマンス データやその他統計情報を Microsoft へ折り返し報告できるようにするものです。Microsoft へデータを提供すると選択したマシンで、オーディオ ハードウェアがデータを待ち望んでいる時 (すなわち、ユーザーがグリッチを聞いたであろう時) の回数を測定しました。このデータは「セッション (ひとつのマシンで 1日の間に集められたデータ、またはマシンがリブートする間に集められたデータの、いずれか短い方)」にまとめられました。

では、その結果を見ていきましょう。まずは、オーディオ グリッチの全体的な割合です。

図 1: セッションごとのグリッチ数の分布

上のグラフは、外部 (Microsoft 以外の) RC ユーザーからのデータを示しています。 約 80% のセッションは全くグリッチがありません。しかし 4.3 % は 10 回以上のグリッチがあり、これはかなりの数のユーザーがオーディオ グリッチの影響を受けていることを示しています。

グリッチの発生頻度を把握したら、今度は「なぜ」それが発生するのかを調べ始めました。まず、ノート PC とデスクトップ PC のフォーム ファクター別にデータを分類しました。

図 2: フォーム ファクター別グリッチの発生しやすさ

このデータから、ノート PC はオーディオ グリッチの経験しやすさが 2 倍近いことがわかりました。その結果、私たちのグリッチ テストや診断ツールでのカバレッジをよくするため、モバイル PC とモバイルのシナリオ (たとえば、バッテリー駆動中に音楽を再生する、など) をターゲットとして取り組むことにしました。

次に、PC メーカー別に、グリッチの発生しやすさを調べました。

図 3: PC メーカー (Mfr) 別グリッチの発生しやすさ

このデータから、特定のメーカーは他のメーカーよりもオーディオ グリッチの疑いが高いことがわかりました。その結果、私たちのテスト活動が広範なマシンやメーカーにわたるようにしました。さらに、このデータを使用して、グリッチ発生率が高いコンポーネントや原因を特定できないか、メーカーと協力して作業しました。

最後に、さまざまな PC モデルでのグリッチを見ていきました。

図 4: PC モデルごとのグリッチ セッションの分析結果

上のグラフにあるように、最低 1 回のグリッチがあったすべてのセッションを分析し、また上の表で示したように (実際のマシン名は伏せています)、PC メーカーや PC モデルと相関関係があるか見ていきました。最初に気づいたことは、Machine A はリストのほかのマシンに比べて 3 倍以上のオーディオ グリッチに関与しているということです。このデータは、先にあったこの特定マシンでのオーディオ グリッチの報告を裏付け、私たちは誤った構成で出荷されたグラフィック カードをつきとめました。その結果、メーカーと協力して構成を改善することができました。

このグラフはまた、問題がいかに広範囲に及んでいるか理解するのにも役立ちます。グリッチの形跡がある PC モデルは数百あります。実際、まったくオーディオ グリッチが発生していない PC モデルを探すほうが難しいくらいです。一方、個々のマシンのほとんどは、まったく問題が発生していません。私たちが導き出した結論は、オーディオ グリッチは何か 1 つのハードウェア構成が原因となっているのではなく、ユーザーが自分のマシン上で遭遇しうるさまざまなハードウェアとドライバー置換に依存する、ということです。いかなるマシンも無縁ではいられないことは明らかで、エクスペリエンスを向上するには、この問題に対する広範囲に及ぶシステム全体のソリューションが必要でした。

グリッチを診断するためのツールを開発する

いつ、なぜグリッチが発生するかのデータが集まったら、次に Windows Devices & Media Performance チームは、メディア再生シナリオに集中し、そのシナリオで PC がどの程度機能したか評価するような包括的なテスト一式を開発しました。メディアの再生中、このテストは、CPU 負荷、システム上のすべてのコンポーネントの動作状況とそれに対応する相互作用を含む、何千ものシステムのパフォーマンスに関する統計情報を記録します。私たちは意図的に広範なシナリオと構成、たとえばバッテリー電源で動いているノート PC、ストレス テスト中のハードウェア、何百ものメディア コンテンツの種類などをカバーしました。この目的は、各 PC を幅広いユーザーシナリオで試して、オーディオ グリッチを発見して分離することでした。

さらに、Devices & Media Performance チームは、グリッチと、グリッチが発生する前と発生している間の CPU の動作状況をハイライトするツールを作りました。これにより、発見したグリッチの問題を素早く診断できるようになりました。たとえば、下記の図が示すように、疑わしい動作を簡単に突き止めるため、グリッチが発生したときの視覚表示と、そのときに発生した関係する測定値を表示できます。

図 5: オーディオ グリッチのトラブルシューティング用の図式的表示の例

このケースでは、4 つのオーディオ グリッチが見えます (一番上のパネルの赤い線の部分)。2 つ下のパネルでは、3ms より長くかかった CPU 呼び出し (長い ISR/DPC と呼ばれています) を表示しています。この例では、オーディオ グリッチと長い ISR/DPC との間に直接的な相関関係があることがわかります。ISR/DPC はオペレーティング システムによって実行されたプロシージャ コールで、CPU を独占してオーディオ グリッチを引き起こす恐れがあります。ここから、グリッチを削減または除去するために、このコールを行ったコンポーネントを突き止めます。この図には、先に述べた特定の問題を診断するために使用した情報以外にも、他の情報が含まれています。しかし、他のグリッチやメディアのパフォーマンス問題を幅広い情報源で診断するために、この情報および他の測定値が利用できる状態にあります。

ツールで作業にとりかかる

テストとツールの用意ができたら、次の手順として、できるだけ多くのシステム上でそれらを展開します。この取り組みの一環として、私たちは、OEM が PC を出荷時期の前にテストできるようにするという Windows 全体のイニシアチブに参加しています。何百もの OEM のマシンが Microsoft に送られ、Windows ラボにて、最高のユーザー エクスペリエンスであることを確認するための何千ものテストに使用されます。これが意味するのは、もし特定のマシンや構成でグリッチが起こりやすいことが分かったら、消費者がその新しい PC を目にする前に、OEM と協力して問題を修正できる、ということです。

これらのテストを実施して新しいツールでその結果を分析することにより、オーディオ グリッチの原因となりうる数百の問題を見つけることができました。あるケースでは、この分析により Windows のコードを変更することになりました。また別のケースでは、パートナーが開発したオーディオ グリッチを引き起こす可能性のあるコンポーネントを特定することができました。

Windows パートナーと協働する

ツールによって見つかった問題は、さまざまなパートナーのコンポーネントが関わっているケースが多いので、この作業の重要な局面はパートナーと協働することです。現在まで、メーカーが、自分たちのコンポーネントがどうシステム全体に影響するか知ることは、ほぼ無理でした。そこで、テストやツールを提供することにより、自分たちのコンポーネントがどう相互作用するか、ユーザーに対する最終的な影響はどのようなものかをパートナーが理解できるようにしました。

この取り組みの一環として、パートナーが新しいツールやテストを十分に活用できるようにしました。私たちは、OEM、ODM (= Original Design manufacturers、伝統的に OEM のために PC を組み立てるメーカーのこと)、ハードウェア メーカー、およびソフトウェア メーカーとお話ししてきました。プレゼンテーションや個別指導、ホワイト ペーパーを提供し、ビデオ会議も開催してきました。私たちの目標は、グリッチからの回復力があるソフトウェアやハードウェアをできるだけ簡単に作っていただけるようにすることでした。

まとめると、この取り組みでは以下のことを実行しました。

1. オーディオ グリッチの遠隔測定データを共有する。パートナーはオーディオ グリッチの現象に対して、明確なデータを限られた範囲でしかお持ちではありません。私たちが収集したデータにより、問題を診断し、彼らの製品を向上するのに役立ちます。
2. オーディオおよびビデオ パフォーマンスのテスト一式を実行する。OEM から送られてきた何百ものマシン上でテストをし、その結果をパートナーに知らせます。できるだけ多くのシステムを評価し、結果を提供することにより、オーディオ グリッチの原因に取り組み始めています。
3. ツールとサポートを提供する。パートナーが、自分たちのコンポーネントが PC 上で他のすべてとどう相互作用しているか理解し、オーディオ グリッチの原因となりうるわずかな問題に対し、より簡単に対処できるようにします。

今後について

最後に、私たちおよびすべての Windows パートナーは、同じお客様 (つまり、これを読んでいただいているみなさんです!) を共有しています。パートナーと協働し、これらの問題への注意を促し、オーディオ グリッチの根本的な原因を明らかにすることにより、すべての人のオーディオ エクスペリエンスを向上し続けていきます。

Windows 7 の“テーマ”：作成、保存、そして共有

Windows 7 の“テーマ”：作成、保存、そして共有

新しい「インボックス」に入っているデスクトップの背景について投稿したとき、反応は単にどう個人設定ができるかというものでした。個人設定というテーマの中で、Windows 7 の“テーマ”に対する取り組みについて、取り上げたいと思います。これまでの Windows リリースにおけるカスタマイズについてのデータはすでにお話ししており、今回の投稿はそれに基づいたものです。また、この分野は個人設定に対する非常に幅広い要望 (ニーズ) があり、しかも当然エンジニアリングとデザインの間でバランスを保たなければなりません。スクリーンのほぼ全域を個人設定 (カスタマイズ) したいと思っているたくさんの人からメールを受け取りました。それこそ、境界線の幅から、タイトル バーの透明度、タスクバーの高さ、[閉じる] ボタンの色・サイズ・場所までです (それぞれについて、少なくとも一度は電子メールを受け取りました)。その一方で、背景の画像と色彩を簡単に変更できればとても満足、という方々も多くいらっしゃいます。Windows 7 では、個人設定をするうえで最も満足度の高いと思われる設定群を選定すると同時に、アプリケーションの互換性を保つ堅牢なプラットフォームを提供し、それらを簡単に変更できるようにしました。さらに、この設定を簡単にパッケージ化し、保存して共有できるようにもしました。これは、幅広いユーザーに対して堅牢な個人設定 (およびカスタマイズ) をもたらす第一歩だと考えています。コア ユーザー エクスペリエンス チームのプログラム マネージャーであるKatie Frigon がこの投稿を書きました。

--Steven

追伸: どのように RTM マイルストーンに到達するかお話しした通り、物事は「ゆっくりと」推移しています。アジアで行ったWindows 7 のリリースおよび入手可能時期に関する発表にお気づきの方もいらっしゃるでしょう。RC を使用していただいているすべての方に感謝します。

Windows 7 のテーマを作成し共有する

Windows 7 の初期のビルドには、デスクトップの背景、ウィンドウの色、サウンドをシングル クリックで変更できる様々なテーマが入っていたことを覚えていらっしゃるかもしれません。このテーマはコントロール パネルの [個人設定] にあり、デスクトップのショートカット メニューからも簡単にアクセスできます。

[個人設定] コントロール パネル

デスクトップのショートカット メニュー

RC には、「アーキテクチャ」など数々の新しいテーマがあります。このテーマは、デスクトップの背景として切り替わる 6 枚の建築物の写真と、それを補完する「ぐんじょう」のウィンドウの色、都会のジャズ クラブの音からインスピレーションを受けた「都市景観」サウンド設定から成っています。

テーマはデスクトップの背景、ウィンドウの色、サウンドの調和されたセット

Windows には最初からテーマのセットが入っていますが、ユーザーがもっとほかのテーマが欲しければ、コントロール パネル内に [オンラインで追加のテーマを取得] リンクがあります。このリンクをクリックすると、Microsoft が追加のコンテンツ (さまざまな地域ことのテーマもあります) を提供している Windows Online のテーマ ギャラリーが開きます。

[個人設定] コントロール パネルの [オンラインで追加のテーマを取得] リンク

テーマを作成する

多くのユーザーは、最初から入っているインボックスのコンテンツやオンラインで提供しているコンテンツを楽しんでいますが、単にテーマを選択するだけでなく、より細かく PC をカスタマイズしたいと望んでいるユーザーもいます。Windows 7 は自分自身と自分が何をするかを反映する PC そのものであり、そのエクスペリエンスを自分でコントロールできるようにする存在であり続けます。したがって、インボックスやオンラインで提供されているオプションの上を行きたければ、自分自身のテーマを作成し、共有することができます。自分自身のテーマの作成はとても簡単で、単にデスクトップの背景の画像のみを変更して他の設定はそのままにしておく、ということも可能です。もちろん、ひとつひとつ設定を変更することもできます。

ベータ ユーザー エクスペリエンス向上プログラムのデータから、ユーザーはテーマを変更したり作成したりしていることがわかりました。また、多くのユーザーは異なる設定を変更しており、最も多い変更はデスクトップの背景でした。

図 1: テーマの種類の内訳

注: たった 15% のベータ テスターがデフォルトのテーマを使用し続けていました。ベータ テスターのうち 77% は、インボックスのテーマから 1 つ以上の要素を変更してカスタマイズしたテーマを作成していました。

図 2: セッションでテーマの各コンポーネントを選択したベータ ユーザーの割合

注: [個人設定] コントロール パネルを開いたベータ テスターのうち 35% は [デスクトップの背景] をクリックしました。

さて次に、さまざまな設定をどう変更し、カスタマイズしたテーマをどう保存するかを見ていきましょう。まず、テーマのいかなる設定も、コントロール パネルの [個人設定] から変更できます。

[個人設定] コントロール パネル: テーマの設定を変更するには、テーマ ギャラリーのすぐ下にあるアイテムをクリックする。

最初に [デスクトップの背景] コントロール パネルから始めましょう。このコントロール パネルは Windows 7 で強化され、画像ライブラリと新しくデスクトップの背景のスライドショーがサポートされました。[画像ライブラリ] を選択すると、サブフォルダも含めてそのライブラリにあるすべての画像が表示されます。その中から、スライドショーでデスクトップの背景として表示させたい画像を選ぶだけです。下記の例では、最近旅行に行ったハワイでのお気に入りの写真を、デスクトップの背景として使用するように選択しました。

[デスクトップの背景] コントロール パネル: Windows 7 にはライブラリとスライドショーのサポートが追加された。自分のテーマとして使用したい画像を選択しているところ。

PC をカスタマイズするには、単に背景を変更するだけでは物足りないでしょう。ウィンドウの色やサウンド設定を変更するのもシンプルで、テーマ ギャラリーのすぐ下にあるアイテムをクリックするだけです。Windows 7 にはウィンドウの色が 16 色用意されており、自由に色を選択することもできます。サウンドは、Windows 7 で新しく、さまざまな地域の音楽からインスピレーションを受けた 14 のサウンド設定が入っています。たくさん選択肢があるわけですが、これで十分でなければ、自分のサウンドを含めることも可能です。

[ウィンドウの色] および [サウンド] コントロール パネル: 簡単にウィンドウの色を変更したり、14 の多様なサウンド設定からサウンドを選択できる。

デスクトップの背景やウィンドウの色、サウンド設定を変更すると、「未保存のテーマ」が作成されているのに気付かれることでしょう。この「未保存のテーマ」には自分で変更した内容が含まれており、ギャラリーの他のテーマを試した際に、直近のカスタマイズした内容に戻すことができます。自分でカスタマイズした設定が気に入れば、[テーマの保存] をクリックして、いつでもテーマの 1 つとしてギャラリーに置いておくことが可能です。

[個人設定] コントロール パネル: 現在のカスタマイズした設定が常にテーマ ギャラリーに表示されるよう、[テーマの保存] をクリックしたところ。

テーマを共有する

自分で使用するカスタマイズした設定を保存したら、その設定を友人や家族と共有したり、他の PC に持っていきたいと思うかもしれません。Windows 7 では、現在設定されているテーマを右クリックし、[テーマを保存して共有] を選択することにより、自分のテーマを共有することができます。テーマの保存場所と名前を指定すると、Windows はカスタマイズされたデスクトップの背景画像、サウンド、マウス ポインター、およびアイコンを収集し、テーマ パック (*.themepack) という新しい形式のファイルに保存します。このファイルを Windows 7 が実行されている他のコンピューターに適用できます。

[個人設定] コントロール パネル: 自分のテーマを友人、家族や Web 上で共有したい場合、現在のテーマを右クリックし [テーマを保存して共有] を選択する。

楽しい休暇の後などに、旅行の思い出をテーマとして作成することがあります。それには、まず、デスクトップの背景として順番に表示するため、旅行の写真からベスト ショットをいくつか選びます。そして、それに合うウィンドウの色と、Windows 7 のサウンド設定から旅行のムードに最も合ったものを組み合わせます。新しいテーマ パックとして保存した後、そのファイルを Windows Live 経由で友人や家族と共有したり、Homegroup 経由で家にある他の PC で使用したりします。

Windows Live で共有する

個人設定のすべてを 1 つのファイルにまとめることができるので、テーマを Windows Live Skydrive にアップロードしたり、Windows Live Spaces のブログでテーマへのリンクを投稿したりするのも簡単です。友人や家族が Windows 7 にアップグレードした暁には、一緒に行った旅行のテーマをダウンロードし、私の写真を彼らのデスクトップの背景で楽しむことができます。

Windows Live: 自分のテーマを Windows Live の Skydrive にアップロードし、My Blog でリンクを追加したところ。

Homegroup 経由で共有する

エクスプローラーでテーマ ライブラリを作成します。それから、Homegroup 内の他の PC から共有されている場所をブラウズし、一回のクリックで希望するテーマを適用することができます。

Explorer: ある PC でテーマ ライブラリを作成し、Homegroup 経由で共有したところ。家の他の PC からテーマをクリックすると、それがその PC にも適用される。

それだけではありません

Windows 7 のテーマに付加した価値のもう 1 つの使い方は、RSS 写真フィードに対する人気の高まりを利用して写真を共有することです。マニアの人は、デスクトップの背景のスライドショーが、RSS 写真フィードをポイントするようなテーマを作成できます。たとえば、私の姉は離れた場所に住んでおり、一年に一回程度しか会いません。彼女に対して私の家族の近況を知らせる簡単な方法は、私の RSS 写真フィードをポイントする Windows 7 のテーマを彼女に送ることです。私が新しい写真をアップロードすると、自動的にその写真が彼女のデスクトップに表示されます。

RSS 写真フィードを作る方法は限られているので、Windows 7 のテーマに RSS 写真フィードを含めるためのプロセスは、RSS 写真フィードが「enclosure」要素を使用して高解像度の写真へリンクしているときのみ動作します。フィードはJPEG や PNG などの画像形式しか参照できません。この制限により、RSS 写真フィードを含むテーマは手動で作成しなければなりません。

そのようなテーマを作成するには、次の手順に従ってください:

1. MSDN からテンプレートをダウンロードします。
2. メモ帳でテンプレートを開きます。
3. {themename} を [個人設定] コントロール パネルのテーマ ギャラリーで表示させたい名前に置き換えます。
4. {rssfeedurl} を自分の互換 RSS 写真フィードへのフル パスに置き換えます。
5. 変更したものを「*.theme」という拡張子のついたファイルとして保存します。

これで共有の準備が整いました! 友人や家族に、電子メールなどでファイルを送ってください。

写真共有サイトでも、このような Windows 7 用 RSS 写真テーマを提供することにより、顧客とつながる方法が増えます。

将来的に

Windows 7 のテーマにより、PC に自分自身を反映させることができます。個人的な写真をテーマとして共有するという私の例のほかに、ユーザーが Windows 7 でテーマを使用するうえで、新しく独創的な方法を見つけてくれることを願っています。結婚式のカメラマンは、自分の顧客に渡すパッケージの中に、Windows 7 用のテーマを含めることができます。また、芸術家は自身の創造的なスタイルを紹介するためにテーマを作成できますし、企業は自社のブランドを宣伝するためにテーマを作成することができます。Windows 7 において、これらの側面をカスタマイズするのに、みなさんがどのようにテーマを使用しているか見るのを楽しみにしています。

--Katie

追伸: みなさんがダウンロードして使えるように、追加のテーマをhttp://windows.microsoft.com/en-US/Windows7/Personalize にアップロードしています。これは、英語 (米国) 版の [テーマ] コントロール パネルにあるリンクです。

(日本語版のリンクは http://windows.microsoft.com/ja-jp/Windows7/Personalize です。)

Windows 7 を守る － 保護者による制限

ご想像のとおり、私たちのチームはこの Windows 7 の次の段階の対応で大変忙しくしています。Windows 7 RC の何百万ものダウンロード、そしてそれをインストールしてくださったことに心から感謝します。現時点で、状況は私たちの期待通りに推移していています。個人的には、私宛にメールをくださった方々に感謝したいと思います。RC に関してたくさんの温かいお言葉とサポートをいただきました。「もうこれでリリースにしてほしい!」とおっしゃる方もたくさんいます。が、私たちは次のマイルストーンに向けて取るべき手順をまとめており、あわてて物事を進めるというようなことはありません。本当にたくさんのやるべきことがあります! ちゃんとは数えていませんが、このブログの Contact リンクから私が送った電子メールは 3,000 通を超えました。すべてにはお返事できていませんが、頑張っています。それぞれの、そして、すべてのやり取りに感謝しています。

Windows 7 には、子供が PC を使用する際に PC を守るための一連の機能があります。この投稿は Safety Team のプログラム マネージャーである Vladimir Rovinsky によるもので、Windows 7 の [保護者による制限] について詳しく説明します。この取り組みは OS そのものの安全性に追加するもので、もちろん Internet Explorer にも安全で安心なブラウジングを提供するために機能が組み込まれています。Windows Live ファミリー セーフティもチェックしてみてください。これは Windows Live Essentials (http://download.live.com) の一部で、より高い安全性と保護者によるコントロールを提供します。 --Steven

今日、子供たちは過去のいかなる時よりもデジタル ハザードにさらされやすくなっています。特に、強力な検索ツール、便利な SNS アプリケーション、動画や写真を公開するための低価格のツールやサービスにより、Web は子供たちに不適切なコンテンツであふれており、保護者はみな自分の子供たちがそれらに接触することを禁じたいと思っています。

子供たちは、Web ブラウザー、インスタント メッセージング アプリケーション、メディア プレーヤー、ゲーム、電子メールアプリケーションなど、さまざまなアプリケーションを介してデジタル ハザードにアクセスできてしまいます。このようなアプリケーションの多くは、保護者による制限機能 (ペアレンタル コントロール) を提供しようとしてきました。しかし、ユーザー インターフェイス、場所、および用語はアプリケーションによってまちまちです。重複し、あるいは整合性のない設定管理は、保護者にとって、複数のアプリケーション間で正しい設定を行うことを困難にしています。

Windows Vista の [保護者による制限] は、以下を用意することにより、問題を解決するためのフレームワークを提供しました。

· 保護者による制限機能の設定や活動を管理するための、コントロール パネル内の単一で特定の場所。

· Web コンテンツやファイルのダウンロード、コンピューターを使用する時間、アプリケーションの使用、ゲームの使用に対する組み込まれた規制、およびユーザーの活動をログに残して確認する機能。

· Windows Parental Control プラットフォームのパブリック API。インボックスの規制設定やログ機能をどのアプリケーションでも使用できるようにします。たとえば、Internet Explorer と Mozilla Firefox 3.0 はこの API を使用して、ファイルのダウンロードをブロックするかどうかを決めています。

· ユーザー アカウント制御 (UAC) との統合。標準のユーザー アカウントを保護者による制限機能で規制されるユーザーとして強化します。Windows PC 上で子供たちを安全に保つためのベスト プラクティスの推進。たとえば、管理される子供ごとに別々の標準アカウントを作成する、保護者 (管理者) のアカウントにパスワードを設定する、など。

Windows Vista の [保護者による制限] についてのデモは、こちらの動画をご覧ください。

Windows Vista の [保護者による制限] 用のソフトウェア開発についての詳細は、Using Parental Controls APIs を参照してください。

Windows 7 の [保護者による制限] に対する更新の重要な設計決定

ユーザーからのフィードバックと Web の発展性と保護者にもたらされる課題に対応し、柔軟で効果的な安全性機能の提供に努めました。Windows 7 での [保護者による制限] に対する取り組みは、次の目標に焦点を絞りました。

1. サード パーティの開発者が Windows 7 の [保護者による制限] と十分に統合できる機能豊かな保護者による制限機能を作成できるように、Parental Controls プラットフォームの拡張性をさらに発展させる。

Windows 7 の Parental Controls プラットフォームは、さまざまな保護者による制限機能の独立プロバイダーが、システムにインストールされています。そして Windows 7 によって提供される 保護者による制限機能を補強または完全に置き換えることができるよう、変更されました。Windows Vista では、Windows の [保護者による制限] の一部だけを置き換えることができました (Web フィルターは置き換え可能)。Windows 7 では、Web フィルターに加え、Windows 7 の [保護者による制限] ユーザー インターフェイス全体をサード パーティ製プロバイダーで置き換えることが可能です。基礎的なオフライン規制の施行は、引き続き Windows の Parental Controls プラットフォームが担当します。サード パーティ製プロバイダーが Windows の [保護者による制限] ユーザー インターフェイス全体を置き換えられるようにすることにより、既存の保護者による制限機能とサード パーティ製プロバイダーによる新しい機能をシームレスに一体化し、一貫性のあるユーザー エクスペリエンスを提供することができます。

コントロール パネルの [保護者による制限] ウィンドウは、保護者による制限機能がデフォルト (システム) のものであれ、サード パーティ製プロバイダーによるものであれ、Windows 7 での保護者による制限機能の中心点であり起動場所であり続けます。

2. Web コンテンツ規制と活動レポート機能をデフォルト (システム) の保護者による制限プロバイダーから削除し、これらの機能については Windows Live またはサード パーティ製プロバイダーに任せる。

Web は私たちが Windows OS をアップデートするよりもずっと高速に変化し続けています。たとえば、Vista がリリース時には、ソーシャル ネットワーキングはまだあまり知られていませんでしたが、今では Web で盛況な存在感のあるものとなっています。Web 用の保護者による制限機能は、日々の革新に遅れず対応する必要があります。そのため、この機能は Windows Live に任せることにしました。

Web フィルターおよび活動レポートの機能は、Web ベースの配信を実装した Windows Live またはサード パーティによるソリューションの方が、効果的に提供できます。たとえば、Microsoft の Windows Live ファミリー セーフティは無料のアプリケーションで、Web コンテンツ フィルター、ファイルのダウンロードの規制、活動の監視といった機能を提供しています。また、子供が Windows Live のオンライン アプリケーション (Windows Live Hotmail、Windows Live Messenger など) を使用するときのために、オンラインの連絡先の管理機能も提供しています。

Windows Live のファミリー セーフティについてはこちらに情報があります。

Windows 7 での Parental Controls (保護者による制限) プラットフォームに対する変更の詳細は、こちらを参照してください。

Windows 7 の [保護者による制限] ユーザー インターフェイスの変更

Windows 7 の [保護者による制限] の最上位ウィンドウにおける新しい要素について、次のスクリーン ショットをご覧ください。

図 1 Windows 7 の [保護者による制限] ウィンドウ

1. [追加の制限] セクションにより、ユーザーは Web フィルター、活動レポート、オンラインの連絡先の管理など、追加の制限機能を選択できます。コンピューターにサード パーティ製の制限機能がインストールされている場合、ウィンドウには [プロバイダーの選択] ドロップダウン リスト ボックスが表示され、現在選択されている (有効な) プロバイダーが表示されます。リスト ボックスの下には、プロバイダーによって提供される機能説明が表示されます。
2. ユーザーの名前または画像をクリックしてユーザーのアカウントを選択すると、そのユーザーに対するプロバイダーの設定が起動します。プロバイダーは、インボックスのオフライン規制のデフォルト設定画面を置き換えることができます。オプションで、ユーザーのアカウントの画像の下に、プロバイダーが生成するステータスを表す文字列が表示されます。
3. プロバイダーによるアイコンが、ウィンドウの右上に表示されます。

追加の制限プロバイダーは、インボックスのオフライン規制の設定に、デフォルトの (システムの) プロバイダーの UI を利用することもできます。その場合、[ユーザーの制御] ウィンドウが表示され、保護者による制限機能が設定できます。

追加のプロバイダーが選択され設定されると、Windows 7 の [ユーザーの制御] ウィンドウに、次のような新しいユーザー インターフェイスの要素が表示されます。

図 2 Windows 7 の [ユーザーの制御] ウィンドウ (追加の制御プロバイダーがインストールおよび設定済みの状態)

1. [その他の設定] では、現在選択されているプロバイダーの機能に直接アクセスできます。
2. [Web の制限] では、現在選択されているプロバイダーの機能にアクセスできます。

Windows の [保護者による制限] の設定と Vista から Windows 7 へのアップグレード

Web フィルターの制限が有効の状態で、保護者によってユーザー アカウントが管理されている Windows Vista PC が Windows 7 へアップグレードされると、保護者 (管理者) はアップグレード中および Windows 7 の [保護者による制限] ウィンドウを開いたときに、Windows 7 の [保護者による制限] にはWeb フィルターおよび活動レポートの機能はない旨が警告されます。

図 3 Windows 7 の [保護者による制限] ウィンドウ (あるユーザーは Web フィルターの規制を受けているが、追加のプロバイダーはインストールされていない状態)

Windows Vista から Windows 7 へアップグレードされたとき、Windows Vista の [保護者による制限] の設定内容 (Web フィルター、活動レポートを含む) は、そのまま変更されずに保持されます。Web フィルターの設定や活動レポートのログ情報は Windows 7 の [保護者による制限] では使用されませんが、サード パーティ製のプロバイダーが保持された内容を使うことができます。

Windows 7 を使用するにあたり、今回の保護者による制限機能に対する変更により、ご家族の皆さんがコンピューターを使用し Web を楽しむ上で、より確実にコントロールできていると感じていただければ幸いです。

--Vladimir

Windows 7 でのメディア ストリーミング

私たちはこれまでに、Windows 7 のホーム ネットワークとメディアに関連する多くの機能について、ブログを執筆してきました。メディア ストリーミングは、これらすべてをかなり格好良くまとめたシナリオです。このシナリオでは、Windows 7 PC をメディア共有のハブとして使用し、ホーム ネットワーク上の他の PC およびデバイスとストリーミングを介してメディアを共有したり、情報をインターネット上で安全にストリーム配信したりできます。この投稿は、デバイス&メディア プログラム管理チームの Scott Manchester が中心となってまとめたものですが、その内容は、コア ユーザー エクスペリエンス、Media Center、ネットワーク、Windows Live などにまたがったものです (Windows Live もこのシナリオで新しい API を活用しています)。この投稿はかなり詳細なもので、実際に試していただきたいことがたくさんあります。テストに RC 版を使用する際、新しい PID キーを入手することなく、別の PC にもインストールして 30 日間使用することができます。それでは、どうぞお楽しみください! --Steven

Windows 7 には、家庭内の他の PC やデバイスで、また、外出先からインターネット経由で自分のメディア コレクションを楽しめるようにするための、わくわくするような新しいストリーミング機能を数多く備えています。私たちは、より使いやすく、セットアップが簡単なネットワーク対応のメディア エクスペリエンスを作成しました。これにより、ネットワークに接続された PC やメディア デバイスでの音楽、画像、ビデオなどの鑑賞が、メディア フォーマット、転送方法、プロトコルなどを気にせず簡単に楽しめます。

Digital Living Network Alliance (DLNA) という広く支持されたオープンな業界標準を使用した相互運用を認定されたネットワーク メディア デバイス (NMD) の数は、ますます増加しています。Windows 7 は、このオープン スタンダードを実装しているため、NMD、Windows PC、Windows Home Server、および Windows Media Center エクステンダー (Xbox 360 を含む) の間で、より容易かつ自然にメディアの共有を行えます。この標準をサポートしているということは、デジタル フォトフレーム、ラジオ、テレビなど無数の NMD を Windows 7 PC とともに使用でき、シームレスにホーム メディア エクスペリエンス全体に追加できるということです。

ハイテク通でない人にも

私たちはメディア ストリーミングの設定をかなりシンプルにしました。Windows 7 以前では、メディア ストリーミング機能はメディア好きな人だけを対象としていました。セットアップ エクスペリエンス向上のため、メディア ストリーミングは新しい HomeGroup 機能と統合されました。その結果、一般的なホーム ネットワーク構成では、メディア ストリーミングはデフォルトで有効になっており機能するようになっています。また、Windows Media Player のユーザー インターフェイスには、新たに [ストリーム] メニュー (下記の図を参照) が目立つ場所に表示され、シンプルなシナリオ ベースの設定オプションが表示されるようになっています。これらのオプションでは、次の設定を行えます。

1. 外出先からメディア ライブラリにアクセスできるように自宅 PC をセットアップする
2. 他のWindows 7 PC およびデバイスから Windows Media Player にメディアをプッシュし、それを制御できるようにする
3. 自宅のすべての PC およびデバイスからのメディア コレクションへのアクセスを迅速に承認する

この投稿では、この各シナリオについて見ていきます。

HomeGroup は、ミュージック、画像およびビデオの「共有ライブラリ」の概念を導入したものです。以前のブログで説明したように、これらの共有ライブラリへは、エクスプローラと Windows Media Player の各ナビゲーション ウィンドウ内、および Windows Media Center の各メディア カテゴリの [共有] ビューからアクセスできます (下記の図を参照)。これらのライブラリの領域は、各ビューで同じです。

エクスプローラは HomeGroup 内にある他の PC の共有メディア ライブラリを自動的に検出し、アクセスできるようにします。また、Windows Media Player と Windows Media Center は、次のものから自動的に共有ライブラリを検出します。

1. Windows Media Player 11 および 12
2. Windows Home Server
3. すべての DLNA 準拠のメディア サーバー (ネットワーク接続ストレージなど)

誰が私の共有メディア ライブラリへアクセスできますか?

HomeGroup とは、互いのメディアをシームレスに表示および実行できる、セキュリティで保護された Windows 7 PC のセットです。共有は、HomeGroup の PC 間で自動的にセットアップされます。また、HomeGroup の設定により、共有するメディアのタイプを選択することができます (たとえば、ミュージック ライブラリのみを共有し、ビデオや画像は共有しない、など)。

HomeGroup のすべての PC が自分のメディアにアクセスできるようにするだけでなく、デバイスから Windows 7 PC 上の共有メディア ライブラリへのアクセスも簡単に行えるようになりました。この操作は、HomeGroup の設定または Windows Media Player 内から手軽に実行できます。

また、Windows Media Player の [ストリーム] メニューから [その他のストリーミング オプション] を選択することにより、自分のメディアにアクセスできる PC やデバイスを制限することもできます。

Play To (リモート再生): メディア コレクションの汎用リモコンとしての Windows 7

Windows 7 では、Windows Media Player の他の共有メディア ライブラリからストリーム配信されたメディアを再生するだけでなく、他のWindows 7 PC や DLNA 認定 DMR (Digital Media Renderer) にメディアを送信して再生できるようになりました。私たちは、この機能を「Play To」(日本語版では「リモート再生」)と呼んでいます。「Play To」を使用すると、Windows Media Player またはエクスプローラで参照または検索して目的のメディアを見つけた後、再生先を選択することができます。各「Play To」セッション用に多機能のリモコン ウィンドウが表示され、全エクスペリエンスを制御できます。

メディア コレクションがどこに格納されているかは問題にはなりません。「リモート再生」はローカル メディア ライブラリおよび共有メディア ライブラリの両方で使用できます。ある Windows 7 PC から別の Windows 7 PC にメディアを送信する場合は、受信側 PC の Windows Media Player の [ストリーム] メニューから [プレーヤーのリモート制御を許可] を選択します。これにより、その Windows Media Player が同じネットワーク上の他の Windows 7 PC の [リモート再生] メニューに表示されます。

Windows 7 PC でメディア ストリーミングが有効な場合、Windows Media Player とエクスプローラでメディア項目を右クリックすると、メニューに [リモート再生] が表示されます。「リモート再生」が可能な PC またはデバイスがネットワーク上で検出されなかった場合、このコンテキスト メニューは表示されません。DLNA は、さまざまなデバイスのカテゴリと役割の認定に関するガイドラインを提供しています。DLNA 認定デバイスのすべてが「リモート再生」機能をサポートするわけではありません。最良のパフォーマンスを得るには、DLNA 認定の DMR の中でも、「Compatible with Windows 7」のロゴ付きの DMR デバイスを探してください。

別の PC またはデバイスで再生するメディア項目を選択したら、[リモート再生] リモコン ウィンドウが表示され、再生、一時停止、停止、前後へのスキップ、前後への選局、音量、ミュートなどの標準コントロールが提供されます。すべてのデバイスですべてのコントロール機能がサポートされるわけではなく、メディアの種類によっては選局がサポートされない場合があります。[リモート再生] リモコン ウィンドウが表示されたら、項目の並べ替えや削除、キューへの項目の追加、繰り返しの切り替えなどを実行できます。また、Windows Media Player やエクスプローラからこのウィンドウにメディア項目をドラッグすることにより、新しい項目を追加することもできます。

起動できる「リモート再生」セッション数に制限はありません。フォトフレームへの画像の送信、テレビへのビデオ クリップの送信、別の Windows 7 ラップトップへのミュージックの送信などをすべて同時に実行できます。さらに、上記の例に示すように、複数の種類のメディアを同じ宛先に送信することもできます。

Xbox 360 および Windows Media Center エクステンダーについて

Xbox 360 には、他の Windows 7 PC からメディア ストリームを受信する方法が 2 つあります。私たちはそれを「ダッシュボード」モードと「エクステンダー」モードと呼んでいます。

ダッシュボード モードでは、Xbox 360 は単なるメディア プレーヤーの役割として機能します。Xbox 360 は正式な DLNA 認定デバイスではありませんが、Xbox 360 を使用して Windows 7 PC の共有メディア ライブラリを参照し (この機能は Windows Media Player 11 でもサポートされます)、ダッシュボードでこれらのライブラリからコンテンツをプルし、再生することができます。

エクステンダー モードでは、Xbox 360 (および他の Windows Media Center エクステンダー) は、ネットワーク上の Windows 7 PC から DMP (Digital Media Player) デバイスと DMR (Digital Media Renderer) デバイスの両方として認識されます。Xbox 360 上で Windows Media Center エクステンダーを使用すると、他のコンピューターのメディア ライブラリを参照してそのコンテンツをプルし、ローカルで再生することができます (ダッシュボード モードで Xbox 360 を使用する場合と同様のプロセスです)。ただし、エクステンダー モードでは、Xbox 360 は「リモート再生」もサポートするため、ネットワーク上の Windows 7 PC のユーザーは、Xbox 360 にコンテンツをプッシュすることもできます。すべてのエクステンダーは、Windows 7 PC に関連付けられると、他の Windows 7 PC の [リモート再生] メニューで検出されます。

ホーム メディアへのインターネット アクセス

Windows 7では、メディア ストリーミング エクスペリエンスを自宅の外にまで拡張し、インターネットを通じて世界のどこからでもホーム メディアにアクセスできるようにしました。インターネット経由のメディア ストリーミングは自宅でのエクスペリエンスと違和感のないように拡張されています。シームレスなエクスペリエンスを実現するため、私たちは次のようないくつかの重要な技術的課題を解決する必要がありました。

1. 検出 – 家庭のコンピューター名をルーティング可能な IP アドレスに解決する
2. プライバシー – 許可されたユーザーのみがホーム メディアにアクセスできるようにする
3. セキュリティ – メディアのブラウジングやストリーミングが盗聴されないように暗号化する
4. 信頼性 – ネットワーク接続速度、メディア フォーマットとビット レート、ルーター ファイアウォールのすべてがシームレスなエクスペリエンスの信頼性をゆるがす原因となりうる

これらの技術的なハードルを克服するために、私たちは、オンライン ID プロバイダーを使用して検出、プライバシーおよびセキュリティの実現を容易にするモデルを設計しました。Windows 7 の新しいオンライン ID プロバイダーのインフラストラクチャでは、Windows ユーザー アカウントにオンライン ID (you@live.com など) をリンクすることができます。これにより、認証/承認サーバーは、2 つの Windows 7 PC (外出先のラップトップと自宅の PC) の間に保護されたリンクを確立するために必要なプライバシーを提供することができます。ホーム メディアへのインターネット アクセスは、Windows Media Player の [ストリーム] メニューから有効にできます。

セットアップ手順に従って、オンライン ID を Windows ユーザー アカウントにリンクします。この作業は、自宅の PC とリモート PC の両方で実行する必要があります。これらの間の接続を確立するには、両方の PC で同じオンライン ID を使用する必要があります。リモート PC からホーム メディア コレクションにアクセスするには、自宅 PC (サーバーとして機能する) が「ホーム」ネットワークの場所にある必要があります。リモート PC (クライアントとして機能する) は、どのネットワークの場所 (パブリック、社内、またはホーム) からでも、自宅の PC からストリーム配信されたコンテンツを参照し、受信できます。ネットワークの場所は、ネットワークに最初に接続する際に選択しますが、[ネットワークと共有センター] で後から変更できます。

信頼性 - ネットワーク接続の要件

自宅からインターネット経由のメディア ストリーミングは、「常時接続」のブロードバンド接続で最も優れた機能を発揮します。ブロードバンドのアップリンク速度は、わずか 200Kbps から 10Mbps 以上までさまざまです。ダウンリンク接続速度も、混雑したホット スポット、ホテルの部屋、友人宅のワイヤレス ネットワーク接続などで変化します。私たちは、アップリンクまたはダウンリンク速度にかかわらず、高ビット レートのコンテンツ (ハイビジョンで録画されたテレビなど) も優れたエクスペリエンスでストリーム配信できるようにしたいと思いました。インターネット メディア ストリーミング機能は、高度な帯域幅検出アルゴリズムとエンド ツー エンドのネットワーク ヒューリスティックを使用して、ネットワーク パスの最小リンクより高いビット レートのコンテンツをストリーム配信する方法を決定しています。

ホーム メディアへのインターネット アクセスにおける別の課題に、リモート クライアント PC とメディアを提供する自宅 PC 間のピア ツー ピア接続の作成があります。一般的なホーム ネットワークでは、インターネット サービス プロバイダーから 1 つの固有の IP アドレスを取得し、この IP アドレスを、インターネット ゲートウェイ デバイス (IGD) またはワイヤレス ルーターの機能であるネットワーク アドレス変換 (NAT) を使用して、家庭内のすべてのデバイスや PC で共有しています。これにより、家庭内で未承諾の接続を作成するリモートの PC やデバイスにとって、自宅の固有 IP アドレスの解決という点でも、ホーム ネットワーク上の固有の PC またはデバイスとの直接通信のために NAT をスキャンするという点でも、課題が出てきます。

Windows 7では、ある高度な NAT スキャン テクノロジを採用してピア ツー ピア接続を確立しているため、ほとんどの IGD で任意のリモート PC から自宅 PC への信頼性の高い接続が可能です。最良の結果を得るには、Windows ロゴ プログラムで認定されたワイヤレス ルーターか IGD を使用することをお勧めします。

メディア フォーマット

Windows 7 では、ほとんどの場合、ファイルの種類やコーデックを意識することなく希望のメディアを楽しむことができます (詳細については、下記の「表 1」を参照してください)。新しいフォーマットのローカル再生のサポートに加えて、コーデック、ビット レート、コンテナーまたはフォーマットがサポートされていないデバイスでもそのコンテンツを再生できるようになりました。この機能は、Windows 7 の新しいトランスコード サポートを使用して実現されます。

たとえば、WMV と MPEG2 しかサポートしていない新しい DLNA 認定テレビで見たい DivX ムービーがあるとします。Windows 7 は、テレビの機能 (コーデックやビット レートなど) を判別し、DivX ビデオをテレビで再生可能なフォーマットに自動的に変換します。一般経験則としては、PC 上の Windows Media Player で再生できるコンテンツならば、ほぼどれでもネットワーク接続デバイス上で再生できるということです。家庭内およびインターネット経由のメディア ストリーミングに帯域幅見積もりの技法を使用することにより、Windows 7 では、最適なフォーマットやビット レートを使用してトランスコードを実行することができます。

表 1: Windows 7 の新しいデコーダー

トランスコードに選択されるフォーマットとビット レートは、特にビデオの場合、トランスコードを実行する PC の CPU パフォーマンス (Windows エクスペリエンス インデックスで確認される) に大きく依存します。

私たちはまた、メディア ストリーミングや他の Windows 7 機能に自動的に対応して動作するハードウェア アクセラレーターを CPU メーカーが提供できるように、柔軟なモデルを作成しました。この新しいアクセラレーション モデルにより、ハードウェア開発者は、自社のハードウェア (おそらく GPU などのハードウェア デバイス内) に完全に実装されたメディア フォーマット エンコーダーおよびデコーダー用のメディア ファンデーション プロキシを構築することができます。ハードウェアによってサポートされたエンコードとデコードにより、Windows 7 は、計算上負荷の高いトランスコード処理を、PC の CPU パフォーマンスに影響を与えることなくバックグラウンド タスクとして、専用ハードウェアにオフロードすることができます。

Windows 7 での Digital Living Network サポート

Digital Living Network Alliance (DLNA) は、ホーム ネットワークでメディア交換するためのテクノロジの仕様規定に関心のある、200 以上の企業が参加するコンソーシアムです。DLNA アーキテクチャは UPnP 仕様に基づいていますが、DLNA ではさらに転送プロトコル (HTTP と RTP に基づく) とメディア フォーマットのセットを規定していします。

DLNAは、デバイスの役割 (サーバー、プレーヤー、レンダラーなど) と、デバイスがお互いを検出して通信するために使用するプロトコル (UPnP、HTTP、RTP など) を定義します。Windows 7 は、DLNA デバイスのいくつかの役割 (下記の表 2 を参照) と、通信およびメディア交換に必要な DLNA プロトコルを実装しています。Windows 7 では、テレビ、ステレオ システム、携帯電話、DVR、ゲーム機といったさまざまな DLNA 認定デバイスと PC を相互運用できるようになります。

表 2: Windows 7 でサポートされるDLNAデバイスのプロファイル

Windows 7 は複数のデバイスの役割を実装しているので、家庭ではいくつかの異なった方法で Windows 7 PC を使用することができます。このセクションの残りの部分では、各シナリオを説明します。

シナリオ 1: Windows 7 PC に、ミュージック、ビデオおよび画像を格納しています。最近、DLNA ロゴ付きのテレビを購入しました。このテレビを使用して、Windows 7 PC 上のメディア ライブラリを参照できます。また、テレビを、PC に格納されたビデオや画像を見たり、音楽を聴いたりするために使用できます。図 1は、このシナリオを示したものです。このケースでは、Windows 7 PC は DMS として動作します。なお、このシナリオは、Windows Vista および Windows Media Player 11 を使用した Windows XP で、既に利用可能です。

.

図 1: テレビで PC に格納されたコンテンツを参照および再生する

シナリオ 2: ネットワーク接続ストレージ (NAS) デバイスを持っており、そこにミュージック、ビデオおよび画像を格納しています。NAS デバイスは DMS を実装しています。Windows 7 PC 上で Windows Media Player を開きます。Windows Media Player を使用して NAS デバイスを検出し、NAS デバイス上のメディア ライブラリを参照できます。 NAS デバイスに格納されたビデオや画像を見たり、音楽を聴いたりすることができます。 図 2 はこのシナリオを示したものです。このケースでは、Windows 7 PC は、DMP として動作します。

図 2: Windows 7 PC で NAS デバイスに格納されたコンテンツを参照および再生する

シナリオ 3: 写真撮影機能に加え Windows 7 PC への画像のプッシュ機能のある携帯電話を持っています。USB メモリなどを使って PC へ物理的にファイルを転送しなくても、PC の大画面を使用して友人に写真を見せることができます。図 3はこのシナリオを示したものです。このケースでは、携帯電話は DMS および DMC として機能し、Windows 7 PC は DMR として動作します。

図 3: 携帯電話から Windows 7 PC に画像をプッシュして表示する

シナリオ 4: DLNA ロゴ付きのステレオ システムを購入しました。Windows 7 PC には、何千もの曲の膨大なミュージック コレクションが蓄積されています。コレクションが大きいので、Windows Media Player の豊富な機能を使用して曲の検索、整理および選択を行います。曲を選択したら、「Push To」を使用してステレオ システムに曲をプッシュするだけです。さらに、別のミュージックとビデオのコレクションが保存されている NAS デバイスも持っています。Windows 7 PC を使用して、NAS デバイスのコンテンツを参照し、ステレオ システムにプッシュすることができます。図 4 はこのシナリオを示したものです。 このケースでは、Windows 7 PC は DMS および DMC として動作します。

図 4: Windows 7 PC でローカル コンテンツまたはネットワーク上の共有コンテンツを参照し、PC からテレビ (DMR) にコンテンツをプッシュして再生する

面白い機能が盛りだくさんです。どうぞお楽しみください!!

-- Scott, Tim、およびDevice & Media チーム

次のエンジニアリング マイルストーンについて

今年の 1 月に Beta 版をリリースし、Beta から RC (= Release Candidate、製品候補版) へ進む上での全体的な開発プロセスについて更新情報をお知らせしました。今日、RC のダウンロードが始まり、既にたくさんのインストールと大きな興奮を目にしています。Beta 版を実行してテストし、RC 版のリリースを可能にすることに貢献してくださった何百万人ものみなさんに対し、チームを代表して感謝申し上げます。ブログでも説明したさまざまなメカニズムを通じて寄せられたフィードバックは、Windows 7 のエンジニアリングの非常に有益なものです。私たちは Windows 7 への反応に謙虚であり続けます。ありがとうございます!

この投稿は、RC から RTM (= Release To Manufacturing、正式版) と呼ばれるものまでの道のりについてです。RTM は時間のある一点ではなく、「プロセス」です。というのも、RTM より、PC メーカーが新しい PC 用に Windows 7 のイメージ構築のプロセスを開始できるようにし、既存マシン用のダウンロードの準備を整え、一般消費者の手元へ Windows 7 が届くよう供給プロセスを用意するからです。つまり、RTM は Windows 7 のエンジニアリングの最終ステージですが、エンジニアリングは RTM 以降も、みなさんが Windows 7 や Windows 7 PC を店頭で購入できるようになる GA (= General Availability、一般に入手可能になること) と呼ばれるときまで続きます。

RTM への道のりは RC をダウンロードすることから始まります。RC は「完了した」ものであり、私たちが行うのはパートナーと共にエコシステムの幅広さに対してこれを検証することです。つまり、私たちの観点では、いくつものテストを何度も実行してきて、広い感覚でリリースの品質について理解するために作業しています。この作業はもうおなじみです。なぜなら、同じことを、Pre-Beta から Beta へ移行するときも、Beta から RC へ移行するときにもやってきたからです。RC との第一の違いは、この時点では製品の機能や特徴を変更することはないということです—それは将来のリリースに取っておくことです。設計や機能について山ほどのフィードバックを受け取りました。そのフィードバックをどう消化して対応したかについては、このブログのたくさんの投稿で述べたとおりです。お願いされたことのすべてをやってはいませんし、折り合いをつけるのが大変なことをお願いされたこともありました。このブログでの対話によって、多種多様な意見に耳を傾けつつバランスをとるという私たちのお約束と、Windows の進化について私たちがどう考えたかについて、示すことができていれば幸いです。

RC ではどのようなフィードバックを期待しているのでしょうか? まず、遠隔測定によって製品の動作をモニターすることに全力を注いでいます。もちろん、Beta の品質からいかなる側面においてもリグレッション (以前は動作していたものが動作しなくなること) が発生しないように注意しています。Beta からずっと継続していることのひとつに、遠隔測定の強化があります—多くのシステムに監視ポイントを追加しました。特に、どんなデバイスがインストールされているか、必要とされるドライバー、全体的なシステムのパフォーマンスに興味があります。スタートメニューの UI の応答性、Internet Explorer (最近投稿されました)、起動、シャットダウン、レジューム、およびサブシステム全体にわたって監視する遠隔測定ポイントがあります。もちろん、最終製品では、この遠隔測定はオプションでユーザーの許可を得て有効になるもので、常に非公開です。

現時点から RTM の間にコードに変更を加えなければならないような、私たちが目を光らせている特定の種類のレポートがあります。それは次のようなものです。

• インストール – セットアップ プロセスに対して重要な遠隔測定を行っており、かなりのログも取っています。もちろん、もしまったくセットアップができなかったら、それはそれで興味深いことで Windows Vista からのアップグレードでも同じでしょう。「参加した」ベータ プログラムでは、これらの問題に対して Microsoft へ報告したり、公式のサポート グループが監視しているコミュニティへ接続したりして、助けを得るしくみがあります。
• セキュリティの問題 – 明らかに、あらゆる脆弱性の問題は修正の可能性があります。市場に出荷済みの製品と同じ基準で問題に対応します。
• クラッシュ、ハング – 広範な人々に影響を与えるような問題の「クラッシュ」レポートを監視しています。問題は、Windows のコード、ドライバー、またはサード パーティー製のソフトウェアかもしれません。この情報は「リアルタイムに」 Microsoft へ流され、私たちはとても注意深く見ています。
• デバイスのインストールと互換性 – Windows Update からドライバーをダウンロードしたり、メーカーのセットアップ プログラムに沿ってドライバーをインストールしたりする際に収集するデータ点です。Beta では何百万もの固有の PnP ID が集まりました。また、ドライバーの場所指定に失敗したデバイスの ID も受け取っています。私たちは定期的にこの Web サービスを更新し、デバイスに関する情報へのポインター (ドライバーの有無、取り扱い説明、など) を示しています。
• ソフトウェアのインストール – デバイスと同様に、ソフトウェアのインストール プロセスを監視し、正常に完了しなかったプログラムを記録しています。繰り返しになりますが、このしくみにより物事を前進させ、RTM マイルストーンで互換性作業を取り入れるのに役立ちます。
• サービス – 今後も Windows 7 のサービスについて継続してテストしていくので、Windows Update から更新プログラムが配布されることになるでしょう。更新プログラムには、新しいドライバーや、今後は Windows 7 に対するパッチも含まれる予定です。テスト更新は、テスト版であると表示されます。新しいコードでの重要な問題に対しても同様に修正するでしょう。このすべては、サービス パイプラインを確認し、RC の品質を保持するための活動です。
• 新しいハードウェア – おそらく最も重要なカテゴリは、ビルド 7100 を使用するにあたり、すべての新しいハードウェアが動作することを確認することです。PC メーカーとハードウェア メーカーのパートナーは新しい PC を開発中で、それらは市場にとっても OS にとっても新しい組み合わせです。私たちは Windows 7 がそのような PC やハードウェアに対してすぐれたサポートを提供できるよう、一緒に取り組んでいます。

すべてのフィードバックは評価されます。そして、問題の原因が Windows 自身にあっても、ハードウェアでも、ソフトウェアでも、はたまた OEM パートナーのコードであっても、完全に統合されたすばらしい PC を届けるために必要なことを行うため、私たちはエコシステム全体にわたってパートナーの皆様と密接に作業していきます。この時点では、この目標は他の何よりも重要です。広範なパートナーと、誰もがすばらしい PC エクスペリエンスを提供する準備ができるようにするための開発時間を一緒に過ごすという意味で、この作業の深さはチームにとって初めてのものでした。

全体的に、多くの人は Beta の品質は過去の RC レベルに匹敵すると言っていますが (RC を最終製品としてリリースするよう提案した人もいました!)、Windows 7 をさらによいものとするために作業を続けています。それを実行するためのツールが適所に備わっていると思います。

RC そのものは 2 週間ほど前にコンパイルされましたが、リリースするすべての ISO やイメージを検証するのに少し時間がかかりました。その間にも、私たちは毎日製品をビルドし続けました。日々のビルドは、先に述べたような多くのユーザーに影響を与える問題に対処したコードの変更を組み込んだものです。このとき、コードの変更とリグレッションの可能性を天秤にかけ、コードの変更の方がより価値があると判断したときのみ変更を反映します。このプロセスの間ずっと、コードに対するすべての変更は、開発チーム、テスト チーム、およびその他多くのチームにわたる大勢の人によってチェックされています。多くのエンジニアがほんの少しのコードを変更しています。私たちはよく、メジャー製品を出荷することは「すべてをゆっくりやること」だと言っています。現在、すべての変更について、私たちは慎重に審議しています。

RTM マイルストーンは日付ではなく、プロセスです。プロセスが完結するにあたり、コードの変更を完了し、公式に Windows 7 を「サービス」します。これは、その後の変更は、修正プログラム (KB サポート技術文書) または最初のサービスパックにまとめられることを意味します。Windows Update を通じて修正を配布できるようになったことにより、明らかに ”RTM する” 方法が大きく変わりました。ですので、Windows XP や Windows Vista で行ったように、製品が完成した直後に更新プログラムが出るのは不思議なことではありません。

現在から RTM マイルストーンの間に、先に述べたようなフィードバックに対応した変更をコードに加える予定です。私たちは減速しつつあり、変更を加えるとしても「おしとやかに」あわてずに行っていきます。達成しなければならない「締め切り」はなく、製品の (すべての側面の) 品質および順調に終了することが Windows 7 におけるもっとも重要な基準です。それに加え、舞台裏では他にもたくさんの作業が待っています。世界中の 100 近い言語用に Windows 7 をビルドし、Windows Web サイト、SDK、Resource Kit といったサポート資料の準備がすべて整ってタイミング良く提供できるようにしなければなりません。

いったん RTM の段階に入ると、パートナーは自社製品用に最終イメージを作成し始め、PC を製造します。ハードウェア メーカーやソフトウェア メーカーは、新製品に対する Windows 7 のサポートの準備を整えます。私たちはまた、小売りのパッケージを製造して世界中に出荷します。企業ユーザーとも連携を続け、RTM プロセスに基づいてボリューム ライセンス製品も提供できるようになります。

この時点では、可能な限り高品質な Windows 7 をお届けすることが、私たちにとって最も重要な基準です—それはあらゆる側面における品質ということです。RTM のプロセスは、慎重に、システムの全体的なエンジニアリングの整合性を保つように計画されています。多くの方から、一刻も早く製品をリリースしてほしい、とご要望をいただいていますが、私たちの焦点は高品質のものをリリースすることにあります。

最終的にはPC OEMのパートナーの皆様が、いつ自社製品 (PC) を市場に投入するか決定します。Windows 7 に対するフィードバックや遠隔測定が私たちの期待と一致したら、これから約 3 か月以内に、RTM プロセスの最終段階に入ります。それが順調に進めば、今年の年末に Windows 7 がインストールされた PC が市場に出回るようにする、という共通の目標を実現したいと考えています。

--Steven と Jon

ソリッド ステート ドライブ (SSD) に関するサポートと Q&A

プライマリ ストレージとしてソリッド ステート ドライブ (SSD) が広範囲に採用される可能性について、特にノート PC への採用や、サーバーにどう応用していくかということについて、関心が高まっています。あらゆる新技術がそうであるように、その導入時には、使用されるテクノロジのパフォーマンス特性の結果として、全体的なシステム (OS、デバイスのサポート、アプリケーション) に当てはめる場合、しばしば再考する必要があります。この投稿では、SSDの最新世代に合わせて Windows 7 を調整してきたことについて見ていきます。これは非常に速く変化する分野であり、今後も Windows を調整するいろいろな方法が存在するだろうと考えています。また、このテクノロジが進化し続け、新たなトレードオフをもたらしたり、基礎となる仮定を覆したりすることを期待しています。Michael Fortin が、ストレージおよびファンダメンタルズ チームの多くの人々からの援助を受け、この投稿を執筆しました。 --Steven

今日のソリッド ステート ドライブ (SSD) の多くは、パフォーマンスの向上、より一貫した応答性、バッテリ寿命の増加、優れた耐久性、より迅速なスタートアップ時間およびノイズと振動の低減を約束します。価格が急激に低下したことにより、多くのアナリストは、従来の回転型ハード ディスク ドライブ (HDD) の代わりに SSD を搭載した PC の販売がますます増えるだろうと予測しています。

Windows 7 では、SSD のオペレーティング特性を念頭に置いて、数々のエンジニアリングの取り組みに焦点を当ててきました。その結果、Windows 7 のデフォルトの動作は、ユーザーの介入を必要とせずに SSD 上で効率的に機能します。Windows 7 の動きがどのように SSD 上で効率的に機能するよう自動的に調整されているかを探る前に、SSD のオペレーティング特性の概要について見てみましょう。

ランダム読み取り: SSD にとって、とても良い面

SSD はランダム読み取りが非常に高速になる傾向があります。回転ディスク ヘッドを配置するために必要な機械的な作業が不要なため、ほとんどの SSD は従来の HDD をはるかに凌駕します。その結果、優れた SSD は、従来の HDD のほぼ 100 倍の速さである 4 KB のランダム読み取りを実行できます (約 1 ミリ秒の 1/10 vs. 約 10 ミリ秒)。

順次読み取りと書き込み: 良い面

順次読み取りと書き込みの操作は、”非常に良い” から ”最高” の間のレベルです。フラッシュ メモリは同時に構成でき、データはチップ間に分散するため、今日のより優れた SSD では、200 MB/秒を超える速度で順次読み取りを実行できます。これは、多くの 7200 RPM ドライブが提供する速度のほぼ 2 倍にあたります。順次書き込みについては、一部のデバイスでは従来の HDD の速度をはるかに上回り、大多数の SSD では HDD と比較して大変良い動作をします。今日の市場では、順次書き込みの速度は SSD の間でかなりの差があります。あるものは通常の HDD のパフォーマンスをはるかに上回り、他のものはわずかに遅れをとり、少数ながら比較して劣るものもあります。

ランダム書き込みとフラッシュ: 効果はさまざま

順次書き込みの速度の違いは、興味深い点ではありますが、ほとんどのユーザーにとって、全体的なパフォーマンスにおいては、ランダム書き込みほどには顕著な相違点とはならないでしょう。

ランダム書き込みにかかる長い時間とはどのくらいでしょうか? 平均的な HDD は通常 4 KB のランダム書き込みを、7 ～ 15 ミリ秒で回転メディアに移動させます (これは許容しがたいことが分かっています)。その結果、ほとんどの HDD には 4 MB、8 MB、またはそれ以上の内部メモリがあり、7 ～ 15 ミリ秒をずっと待機する代わりに、少量のランダム書き込みのキャッシュを試行します。読み取りをキャッシュすると、バイトが回転メディアに移動されていなくても、OS に処理が終わったことを返します。通常このようなキャッシュされた書き込みは、数百 "マイクロ" 秒 (つまり、実際の回転メディアへの書き込みの、10 倍や 20 倍の速さ) で完了します。何千もの遠隔測定による何百万ものディスク書き込みを見てみると、4 KB 以下の IO の 92% で 1 ミリ秒未満、80% で 600 マイクロ秒未満、そして驚異的な 48% は 200 マイクロ秒未満しかかかっていませんでした。これはキャッシュの威力です!

時折、HDD が大量のランダム書き込みやフラッシュをうまく処理できない場合があります。ドライブがあまりに長い間、大量にキャッシュすると、フラッシュの際に大量の作業のバックログを完了するのに時間がかかり、問題となることが分かりました。これらのフラッシュおよび関連する IO は、応答時間を大幅に増加させることがあります。一部のデバイスでは、個々の IO を完了するのに 0.5 秒 ～ 1 秒かかり、より一貫した応答状態に戻るには数十秒もかかります。応答性が苦痛を感じるレベルにまで低下するため、ユーザーにとって耐え難いものとなり得ます。考えてみてください、単一 I/O の応答時間は、200 "マイクロ" 秒から、途方もない 1,000,000 "マイクロ" 秒 (1秒) にまで及ぶのです。

現実的なワークロードで示すと、最悪の SSD の場合、個別のランダム書き込みおよびフラッシュ要求を完了するのに 0.5 秒 ～ 1 秒と、非常に長い IO 時間が発生していることがわかりました。多くのワークロードにとってこれはひどく、システム全体が不安定、応答がない、または遅すぎるといった状態になります。

ランダム書き込みとフラッシュ: なぜそれほど難しいのか?

多くの人にとって、電子的アクセスを行う SSD で、従来の機械的アクセスを行う HDD よりもランダム書き込みの問題が発生しやすいという説は、初めは理解しがたいかもしれません。SSDは回転ディスク上のトラックでディスク ヘッドをシークおよび位置付けする必要がないのです。それなのに、なぜランダム書き込みが、そのような難題となるのでしょうか?

この疑問に答えるにはかなりの説明を要しますが、Anand 氏の記事で詳細の大部分をカバーしています。興味のある方は、時間をとってこの記事や優れた USENIX ペーパーをお読みになることを強くお勧めします。同じ資料をカバーしすぎることを避けるため、ここではいくつかの要点のみを取り上げます。

• ほとんどの SSD は、フラッシュ セル (SLC または MLC のいずれか) で構成されています。DRAM から SSD を構築することは可能です。これらは、非常に高速になりますが、非常に高価で消費電力も大きくなります。これらが使用されることは比較的まれであるため、はるかに一般的な NAND フラッシュ ベースの SSD を中心にディスカッションを行います。未来の SSD は、フラッシュだけでなく他の不揮発性メモリ テクノロジを活用するかもしれません。
• フラッシュ セルは実際には電子にとってのトラップであり、そして電子はトラップされることを好みません。1 つのフラッシュ セルに 100 個の電子を配置することが 0 のビット値を構成し、それより少ない場合は値が 1 になる場合、コントローラー ロジックは 80 から 120 の間をビット値 0 の許容範囲と見なす必要があるでしょう。ある電子はトラップを回避したり、他の電子は近くのセルを埋めようとしてトラップにはまったりする場合があるので、許容範囲は必要です。その結果、データ整合性を保証するには非常に高度なエラー修正ロジックが必要となります。
• フラッシュ チップは、ブロック、ダイ、プレーン、およびパッケージなど、複雑な配列で編成される傾向があります。サイズ、配列、並列処理、消耗、相互接続、および転送速度の特性は、大幅に異なります。
• フラッシュ セルは、書き込む前に消去される必要があります。フラッシュ セルを使用する前に、そこに残留電子がないと決め込むことはできないため、電子を注入する前にセルを消去する必要があります。消去は大規模なスケールで行われ、1 つのセルを消去するのではなく、大きなセルのブロック (128 KB 相当など) を消去します。消去時間は通常長く、1 ミリ秒またはそれ以上になります。
• フラッシュは消耗します。ある時点で、フラッシュ セルは電子に対するトラップとして機能しなくなります。頻繁に更新されるデータ (ファイル システムのログ ファイルなど) が同じセルに常に格納されていると、これらのセルは、読み取り専用のデータを含むセルよりも早く消耗します。書き込みをデバイスのセル全体に分散するよう、フラッシュ コントローラー ファームウェアは消耗平均化ロジックを採用しています。適切に行われれば、ほとんどのデバイスは通常のデスクトップ/ラップトップ ワークロードで何年も機能します。
• 電子を高速でトラップし、しかもそれをエラーなしで行い、またデバイスが平均的に消耗するようにするには、非常に有能なデバイス物理学者と、ゆるぎないエンジニアリングが必要となります。これまでのところ、どの SSD メーカーも、これをうまくやる方法を見つけ出せていないようです。

時間とともに起こるパフォーマンス低下、消耗、および Trim

先にも述べたように、フラッシュ ブロックおよびセルは、新しいバイトを書き込む前に消去する必要があります。その結果、新しく購入されたデバイス (あらかじめすべてのフラッシュ ブロックが事前消去されている) は、かなりの使用期間を経た後よりも、購入時の方がはるかに良く動作します。私たち自身このパフォーマンス低下を観察していますが、これが致命的な問題であるとはみなしません。実際、ベンチマーク測定によってでなければ、ユーザーが通常の使用中にパフォーマンスの低下に気付くことはないでしょう。

もちろん、デバイス メーカーと Microsoft は、可能な限り最良のパフォーマンス特性を維持したいと願っています。より優れた SSD メーカーが、通常の使用時にパフォーマンスに不利な条件が大部分は実現されないようあらかじめブロックを消去することにより、または書き込みが短期に大量に発生した場合に十分な予備領域を維持することにより、経年劣化の問題を克服しようと努めていることは、想像に難くありません。企業向けに設計された SSD ドライブでは、高度に持続する書き込みパフォーマンスを長期間提供するために、50% もの領域が予約されています。

上記に加えて、Microsoft と SSD メーカーは、Trim 操作を採用しています。SSD が ATA プロトコルの Data Set Management 命令の Trim 属性をサポートする場合、Windows 7 では,

ファイルが削除されファイルをバックアップする SSD ページを消去しても安全になると、NTFS ファイル システムはデバイスに対して新しい操作を発行するよう ATA ドライバーに要求します。消去されたページは再使用可能なので、後続する書き込みでブロックの消去操作は必要ないことを前提として、この情報により SSD は該当するブロックを必要に応じて (かつ頻繁でなく) 消去することを計画できます。

付加価値として、Trim 操作により、多数のマージ操作を発生させる必要がなくなるので、SSD の消耗を軽減できます。たとえば、128 KB のファイルを含む、1 つの 128 KB の SSD ブロックについて考えてみましょう。ファイルが削除され、Trim 操作が要求されると、SSD では、その SSDブロックからのバイトと、そのブロックに後で書き込まれるその他のバイトとが混在されなくなります。これによって消耗が減少します。

Windows 7 では、ファイル削除操作のためだけに Trim 操作が要求されるわけではありません。Trim 操作は、Format や Delete など、パーティション レベルおよびボリューム レベルのコマンド、切り捨てや圧縮に関連したファイル システム コマンド、およびシステムの復元 （または、ボリューム スナップショット） 機能と完全に統合されています。

Windows 7 の最適化とデフォルト動作のまとめ

前述のように、今日の SSD はすべて、ディスク書き込みおよびディスク フラッシュに関しては、まだまだ改善の余地があります。Windows 7 は、このような今日の SSD 上でも、ある程度うまく動作します。これは、私たちが書き込みとフラッシュの頻度を減らすよう多数のエンジニアリング上の変更を行ってきたからです。これは、従来の HDD にも役立ちますが、今日の SSD 上で特に有用です。

Windows 7 は、SSD システム ドライブ上ではディスク最適化を無効にします。SSD はランダム読み取り操作できわめて優れたパフォーマンスを発揮するため、ファイルの最適化は、最適化によって生成される追加のディスク書き込みを埋め合わせるほど有用ではないからです。この後の FAQ セクションに、追加の詳細情報があります。

デフォルトでは、ランダム読み取り、ランダム書き込み、およびフラッシュの優れたパフォーマンスを備えた SSD 上では、Windows 7 は Superfetch、ReadyBoost、起動およびアプリケーション起動プリフェッチを無効にします。これらのテクノロジはすべて、ランダム読み取りのパフォーマンスが主要なボトルネックとなりやすい、従来の HDD のパフォーマンスを向上させるために設計されたものです。詳細については以下の、よく寄せられる質問のセクションを参照してください。

SSD は、オペレーティング システムのパーティションが SSD 配列を考慮して作成される場合に最高のパフォーマンスを実現する傾向があるため、Windows 7 のパーティション作成ツールはすべて、新規に作成したパーティションを適切な配列で配置します。

よく寄せられる質問

よく寄せられる質問を取り上げる前に、私たちはモバイルおよびデスクトップ PC (そして、エンタープライズ サーバー) に入っている SSD の将来は、私たちにとって非常に明るいと信じていることをみなさんに伝えたいと思います。SSDは、パフォーマンスの向上、より一貫した応答性、バッテリ寿命の増加、優れた耐久性、より迅速なスタートアップ時間およびノイズと振動の低減を約束します。価格が順調に低下し、品質が向上するにつれ、ますます多くの PC が従来の回転 HDD に代わって SSD を搭載して販売されることでしょう。それを念頭に置いて、Windows 7 ユーザーに SSD の優れたエクスペリエンスを保証するために、適切なエンジニアリングの取り組みを行いました。

Windows 7 は Trim をサポートしますか?

はい。詳細については、上記を参照してください。

SSD 上でディスク最適化はデフォルトで無効になっていますか?

はい。最適化の自動スケジュールは、自身を SSD として宣言するデバイス上のパーティションを除外します。また、システム ディスクに8 MB/秒のしきい値を越えるランダム読み取りのパフォーマンス特性がある場合も除外されます。このしきい値は内部分析によって決定されました。

市場に存在する SSD の大半は、自身を SSD として適切に識別していない、という事実に対処するため、ランダム読み取りのしきい値テストが最終製品に追加されました。8 MB/秒はやや控え目の速度です。私たちがテストした HDD はどれも 8 MB/秒にはるかに及びませんでしたが、テストした SSD はすべてそのしきい値を越え、そのパフォーマンスは 11 MB/秒 ～ 130 MB/秒の範囲に及びました。テストされた 182 台の HDD のうち、わずか 6 つの構成だけがランダム読み取りテストで 2 MB/秒を超えました。その他の 176 台は、0.8 MB/秒 ～ 1.6 MB/秒の間でした。

Superfetch は SSD 上で無効にされますか?

はい、SSD を備えた大半のシステムで無効になります。

システム ディスクが SSD であり、その SSD がランダム読み取りで十分に動作し、ランダム書き込みまたはフラッシュにおいてもパフォーマンス上の目立った問題点がない場合、Superfetch、起動プリフェッチ、アプリケーション起動プリフェッチ、ReadyBoost、および ReadDrive はすべて無効になります。

最初は、すべての SSD 上でこれらの機能がすべてオフとなるよう構成しましたが、一部のシステム上でかなり顕著なパフォーマンス低下に直面しました。このような低下を引き起こす原因として、一部の第一世代 SSD には深刻なランダム書き込みとフラッシュの問題があり、それによって結果的に長時間ディスク読み取りがブロックされていたことを発見しました。そして、Superfetch および他のプリフェッチ機能を再度有効にすると、主要なシナリオにおけるパフォーマンスは著しく向上しました。

SSD 上でのファイルおよびディレクトリの NTFS 圧縮は推奨されますか?

ファイルの圧縮は領域の節約に役立ちますが、圧縮と展開にかかる労力によって、余分な CPU サイクルとその結果としてモバイル システムでは電力が必要となります。とは言え、めったに変更されないディレクトリおよびファイルでは、圧縮は貴重な SSD 領域を節約する優れた方法であり、領域が本当に貴重である場合には、良いトレードオフになり得ます。

ただし、頻繁に書き込まれるファイルまたはディレクトリを圧縮することはお勧めできません。ユーザー自身のドキュメント ディレクトリおよびファイルはまだよいですが、インターネット一時ディレクトリやメール フォルダーは、突発的に大量のファイル書き込みが発生するため、圧縮には適しません。

Windows Search Indexer は SSD 上では違った動きをしますか?

いいえ。

BitLocker の暗号化プロセスは SSD 上で動作するよう最適化されていますか?

NTFS では 「はい」です。BitLocker がパーティション上で最初に構成されるとき、パーティション全体が読み取られ、暗号化され、書き直されます。これが終わると、NTFS ファイル システムは、SSD が動作を最適化できるように Trim コマンドを発行します。

SSD を含むドライブ上で BitLocker を有効にする場合、データ プライバシーと保護に十分ご注意ください。

SSD上で設定したとき、Media Center で何か特別なことができますか?

いいえ。SSD は従来の HDD よりも利点がありますが、SSD は HDD に比べて GB あたりの単価が高くつきます。ほとんどのユーザーにとって、メディアの録音のために最適化された HDD の方がよりよい選択肢でしょう。なぜなら、メディアの録音および再生のワークロードは事実上連続して行われるためです。

書き込みキャッシュは SSD 上で機能しますか? また、SSD で書き込みキャッシュがサポートされる場合、Windows 7 で特別な機能がありますか?

一部の SSD メーカーは、単なる制御ロジック以上の理由でデバイスに RAM を組み込んでいます。それらのメーカーは、書き込み、そして恐らく読み取りをキャッシュすることで、従来のディスクの動作を模倣しているのです。揮発性メモリ内でキャッシュ書き込みを実行するデバイスについては、Windows 7 では、フラッシュ コマンドおよび書き込み順序が少なくとも従来の回転するディスクと同じ程度に保持されると考えています。また Windows 7 は、書き込みキャッシュを無効にするユーザー設定が、従来のディスク上でそうであるように、書き込みキャッシュ SSD によっても受け入れられます。

RAID 構成は SSD 上で機能しますか?

はい。HDD RAID 構成によって得られる信頼性およびパフォーマンス上の利点は、SSD RAID 構成によっても実現できます。

ページ ファイルは SSD 上に配置する必要がありますか?

はい。ほとんどのページ ファイル操作は、小規模なランダム読み取りまたはより大規模な順次書き込みです。これらのどちらのタイプの操作も、SSD で適切に処理できます。

何千もの遠隔測定データを観察し、ページ ファイルの読み取りと書き込みに注目した結果、次のことがわかりました。

• pagefile.sys 読み取りは、約 40 対 1 で pagefile.sys 書き込みを上回る。
• pagefile.sys 読み取りサイズは、通常非常に小さく、67% が 4 KB 以下、88% が 16 KB 未満。
• pagefile.sys 書き込みは比較的大きく、62% 以上が 128 KB、45 % がちょうど 1 MB。

実際、通常のページ ファイルの参照パターンおよびそれらのパターンに対する SSD の持つ有利なパフォーマンス特性を考えると、SSD 上に配置するのにページ ファイルより適したファイルはほとんどありません。

休止状態のファイルと SSD に関して、何か懸念事項がありますか?

いいえ、hiberfile.sys は、連続して大きなブロックで書き込みおよび読み取りされるため、HDD または SSD のどちらにも配置できます。

SSD パフォーマンス特性に対応するため、どのような Windows エクスペリエンス インデックスの変更が行われましたか?

Windows 7 では、新しくランダム読み取り、ランダム書き込みおよびフラッシュの評価を行います。より優れた SSD は 7.9 中 6.5 以上のスコアを出せます。その範囲に含まれるには、SSD には高いランダム読み取り速度が必要であり、フラッシュおよびランダム書き込みワークロードからの復帰も早くなければなりません。

Windows 7 Beta の期間では、ランダム書き込みおよびフラッシュの評価時にディスク (SSD または HDD) が十分に動作しなかった場合、1.9 や 2.9 といったスコアに制限されていました。この点についてのフィードバックはかなり一貫しており、大半のユーザーが、制限のレベルが行き過ぎだと感じていました。その結果、パフォーマンス上の問題のある SSD は、新しく追加された 6.0+ および 7.0+ の範囲にはしないことにしました。すべての評価にわたって高パフォーマンスを出せない SSD は、Windows Vista と同様の方法で採点されますが、Windows 7ではランダム読み取りパフォーマンスには寄与することはありません。

個性について少し、、、

こんにちは! データによると、MSDN・TechNet・Connect ユーザーの多くは、Windows 7 の RC (製品候補版) を使うことで忙しくされているようです。ありがとうございます!!! そしてもちろん、多くの人はRC をダウンロードして使うことを楽しまれています。私たちはダウンロードの規模を拡大し、皆さんの参加と RC の評価データをみることを楽しみにしています。ユーザー自身が Windows 7 を「コントロールできる」ようにすることについてお話しましたが、自分の PC に対してコントロールする方法のひとつが、使う楽しみを独自なものにすることです。RC では Windows 7 の新しい個人設定の「要素」にお目にかかれるでしょう。この投稿は、製品デザイン チームの Denise Trabona と Samuel Moreau が、彼らの仕事の舞台裏について書いたものです。画像の下のリンクをクリックしていください。才能あふれるアーティストたちによるたくさん作品をご覧いただけます。なお、この投稿にあるのは単なるサムネイルです。フルスクリーンの画像は RC でお楽しみください。 --Steven

追伸: ただのお知らせですが、プリベータ版やベータ版でも行ったように、Windows Update とシステムにパッチがあたって更新されるかのテストを行う予定です。新しいドライバーと共に、システムに対するその他の更新も目にされるかもしれません。

Windows 7 のエンジニアリングで最もエキサイティングなことのひとつは、全プロダクト サイクルにわたって成されるさまざまな種類の仕事です。このブログでもいろいろなトピックがあるように、製品のあらゆるレベルにおいて私たちが一生懸命取り組んでいることがお分かりかと思います。みなさんは Windows 7 での新しい個人設定の裏話に興味があるのではないかと思い、今回の投稿となりました。

お気づきの方もいらっしゃるでしょうが、RC ビルドで、個人の使い勝手をより柔軟にカスタマイズできるようにする新しい個人設定のコンテンツ (壁紙、グラスの色、サウンド設定) のいくつかをお見せします。Windows ユーザーはデスクトップの背景を変更することにより自分自身を表現することが好きですが、Windows 7 にはすぐに自分のエクスペリエンスをカスタマイズできるようなコンテンツが最初から含まれています。

1000の言葉に値するひとつの絵

個人設定の機能を開発する上で、ユーザーが自分のスタイルを表現するためのすばらしいコンテンツが必要だと感じていました。デスクトップの背景は非常に活気に満ちた面なので、独創的な人々がこの機能でどうするか表現したような高品質のコンテンツを提供することに重点を置きたいと思っていました。みなさんがフィードバック ボタンを使ってスクリーンショットを送ってこられるとき、設定されている壁紙の豊かな多様性と個性にいつも刺激を受けています。

どのように Windows 7 の個人設定に取りかかろうかと考えていたとき、これまでの伝統に敬意を表すのもひとつの方法だと思い当たりました。過去にも写真は Windows の大きな特色でした。いくつかの写真は大変美しく、ずっと維持していきたい誇り高い伝統になっていました。また、新しい領域に足を踏み入れ、視覚的なパレットを広げたいとも思っていました。写真の分野では、伝統的にテーマを風景写真に絞ってきましたが、建築物や自然の新しいテーマを追加しました。多くの画像は、画像をストックしているパートナーによるものですが、才能ある地元の写真家 Will Austin と一緒に仕事ができたのは幸運でした。Will は多くの題材を、特に建築物に力を入れて、世界中で写真を撮影してきました。Will の写真には、私たちが誇りを持って本拠地と呼ぶシアトル エリアのローカル色が少し入っています。

インスピレーションと喜びのハードルを上げる

対象となる写真ですが、人々の想像力にひらめきと喜びを与えて活性化させるような画像を追加のするよう、取り上げる範囲を広げる努力をしました。ユニークで、タイムリーで、独特な観点を持つような新しいコンテンツにまで幅を広げたかったのです。目標は、不朽のすばらしい写真と、エネルギーにあふれたモダンで新鮮なイラストとの、バランスが取れたコンテンツです。それに加え、さまざまな好み、性別、年齢の人に気に入ってもらえるような、色調もおとなしいものから派手なものまで、構成も大きなものから小さく緻密なものまで、数多くの豊かなイラストを実現することも重要でした。

ご近所の Zune チームからヒントを得て、Windows 7 でほかにない芸術作品をみなさんのために創造するため、72 and Sunny という代理店と一緒に世界中のイラストを探しました。大量のサンプルを見ていく中で、スタイルが多様性をカバーするようにとても変化に富んでおり、かつ、私たちが達成しようとしている全体的なトーンに当てはまるような共通のテーマを維持しているようなアーティストのグループを探し求めました。そして、それからが楽しいのですが、シンプルな指針となる言葉 (光輝く、エネルギッシュな、活気づける、楽観的な、など) だけを頼りに、アーティストはオリジナル作品のコンセプト スケッチを描くために、何も描かれていないキャンバスを持って出かけて行きました。

繰り返して磨きをかける

アーティストの最初のスケッチとコンセプト作品を初めてレビューしたときのことを今でも覚えています。そしてその時から、これらの画像はとても楽しくなることがわかっていました。次のステップは、一定の目標が達成できていることを確認し、細かいところを調整するために、何度か行ったり来たりすることでした。たとえば、私たちにとって重要なのは、新しいタスクバーのもとで画像がどう見えて視覚的なインパクトとして適正なバランスを保っているかということと、ユーザーがデスクトップ上で重要なファイルを探すときに気が散って邪魔にならないか、という 2 点でした。適正なバランスを見つけるのは大変ですが、幸運にも、驚くほど才能豊かなアーティストと、このプロジェクトで一緒に働く 72 and Sunny の仲間に恵まれました。

世界中の人々のための Windows

最後に、さまざまなバックグラウンドやスタイルを持つイラストレーターを探し出し、世界中の人々を代表して世界中の人々の心に訴えることにより、全世界の Windows ユーザーを認めたいと思いました。

そこで、驚くほど才能豊かなアーティストと、Windows 7 の個人設定に貢献してくれる彼らの作品を敬意を持って紹介いたします。

近藤 有稿

日本出身、イギリス、ロンドン在住

 

 

Katharina Leuzinger

スイスのチューリッヒでスイス人と日本人の両親の間に生まれる。イギリス、ロンドン在住

 

 

Osmand Nosse

アイルランド、ウィックロウ

 

 

Klaus Haapaniemi

フィンランド出身、イギリス、ロンドンをベースに活動

 

 

Red Nose Studios の Chris Sickles

アメリカ、インディアナ州

 

 

Punga

アルゼンチン、ブエノスアイレス

 

 

Pomme Chan

バンコクで生まれ、教育を受ける。イギリス、ロンドン在住

 

 

Kustaa Saksi

オランダ、アムステルダム

 

 

Nanosphere の Paul Hwang と Benjamin Lee

カリフォルニア州、ロサンジェルス

 

 

Adhemas Batista

ブラジル、サンパウロ出身、カリフォルニア州、ロサンジェルス在住

 

 

Kai and Sunny

イギリス、ロンドン

 

 

Nan Na Hvass

アフリカのスワジランドでデンマーク人の父と中国人の母の間に生まれる。デンマーク コペンハーゲン在住

 

 

この投稿により、Windows 7 コンテンツを準備してきたその舞台裏を提供できたとしたら幸いです。また、Windows 7 のこの要素に対して私たちの目標を達成できたと、みなさんから言っていただければ、最高です。

-Denise Trabona、Samuel Moreau

”自動再生”の改善

以前にこのブログ (UAC の変更に関して) および IE ブログ (マルウェア対策の SmartScreen® filter に関して) で以前述べたように、私たちが重視しているのは、ユーザーが自分のコンピューターで実行しようと選択したソフトウェアに対して、ユーザー本人が自信を持ってコントロールできるようにすることです。このブログにも、自動再生に対して具体的に抱いている懸念事項についてのコメントがあります。このブログの記事では、Windows でメディアやデバイスを使用する際の、ユーザーの信頼性を高めるために行われた変更点が示されています。Core User Experience チームの Arik Cohen がこの記事を書きました。 –Steven

Conficker ワームなどの特定のマルウェアは、自動実行の機能を利用して、一見したところ害のなさそうなタスクを提供するようになりました。しかし、それはトロイの木馬のように、マルウェアをコンピューターに進入させるためのなりすましです。そして、マルウェアは同じトロイの木馬を使って、コンピューターに接続されるデバイスに感染します。Conficker に関する詳細については、http://www.microsoft.com/japan/protect/computer/viruses/worms/conficker.mspx を参照してください。

下記の、写真が保存されている USB フラッシュ ドライブの例では、マルウェアは [Open folders to view files (フォルダを開いてファイルを表示する)] という害のなさそうなタスクを登録します。最初の赤で囲った [Open folders to view files] を選択すると、マルウェアが起動してしまいます。しかし、二番目の緑色で囲ったタスクを選択した場合は、Windows のタスクが安全に実行されます。

感染した USB の自動再生

これを見た人は、なぜ同じことをするように見える 2 つのタスクがあるのかと混乱してしまいます。信頼できない発行元からのソフトウェアは実行しないように気をつけているコンピューターの知識がある人でさえ、一番目のタスクを選択するという間違いを犯しがちです。その結果、ユーザーは自信を失い、コントロールできていないように感じます。

増大するアタック

自動再生の中に自動実行タスクを表示するのは Windows XP の時からですが、増殖の方法として自動実行を使用するマルウェアの数は著しい増加を見せています。Security Intelligence Report によると、2008 年の下半期において、Forefront Client Security による企業調査の結果、自動実行によって増殖するマルウェアのカテゴリは、感染の 17.7％ を占めました。これは、マルウェア感染のカテゴリの中で最大です。

以下のグラフは、自動実行によって広がった感染の、Microsoft Anti-Virus による検出報告の増加を示しています。(注: 感染の実際の方法は特定できません。)

 自動再生で広がったマルウェアの感染検出数

今のところ、完全に自動再生を無効にすることが、コンピューターの USB フラッシュ デバイスの使用において、ユーザーや企業が信頼できる唯一のソリューションです。自動再生を無効にする方法については、こちらを参照してください。

ユーザーの信頼を高める

Windows 7 では、自動再生に対して主要な変更が加えられました。その変更は、一般的なシナリオでのデバイス使用時に (たとえば、USB フラッシュ ドライブ内のファイルにアクセスする、SD カードから写真をダウンロードする、など)、Conficker のようなマルウェアにうっかりさらされないようにするためです。

具体的には、Windows は、リムーバブル光ディスク (CD/DVD) 以外のデバイスの自動再生ダイアログ中に、自動実行のタスクを表示することは今後はありません。なぜなら、この挿入されたタスクの由来を確認する方法がないからです。ハードウェア メーカーによって挿入されたものでしょうか? 誰か人によるものでしょうか? それともマルウェアの仕業?この自動実行のタスクを除去することにより、現在マルウェアが悪用している増殖方法をブロックし、ユーザーが保護された状態を保つことができます。コンピューターにインストールされている他の自動再生のタスクには、引き続きアクセスすることができます。

この変更により、マルウェアに感染している写真入りの USB フラッシュ ドライブを挿入しても、表示されるタスクはすべて、既にコンピューター上にあるソフトウェアによるものだと自信を持てます。

 新しく自動再生しないように変更されたUI - 感染している USBフラッシュドライブを挿入した場合

一方、ソフトウェアをインストールするために CD を挿入すると、Windows は、ソフトウェア メーカーがメディア作成時に入れた自動実行のタスクを表示します

 自動実行のタスク入り CD 用の自動再生

この更新された自動実行のエクスペリエンスは、Windows 7 の RC ビルドで最初にお目見えします。また、将来的には、Vista や XP に対しても、この変更が加えられる予定です。

エコシステムへの影響

私たちは、エコシステム パートナーと共に、この自動実行の仕様変更による影響を緩和するために取り組んでいます。

製造過程でハードウェア メーカー指定の自動実行タスクが書かれたような CD および DVD (CD エミュレーションを含む) では、引き続き、ユーザーが特定のソフトウェアを実行できるようにするための自動実行の選択肢が現れます。一般的な大容量記憶装置のメーカーは、ソフトウェアを起動するために、ユーザーがデバイスの中身をブラウズするであろうことを予期しなければなりません。新しい動作では、メディアやデバイスにアクセスするのにユーザーが引き続き自動再生 (すべての Windows およびソフトウェア メーカーがインストールしたタスクを含む) を使用することを許可しますが、マルウェアによるタスクは表示されません。さらに、ポータブル メディア プレーヤーや携帯電話といったデバイス クラスは、Windows 7 の Device Stage™ をサポートします。Device Stage は、ソフトウェアや一般的なタスクへのリンクを表示できるような、自動再生に代わる多機能なもので、デバイスを使用する上での追加機能を提供します。

Windows 7 RC を試したとき、今回の変更により、メディアやデバイスを使用する際に、これまでよりも自信を持ってコントロールできていると感じていただけると幸いです。

-Arik Cohen

Windows 7 グラフィックス パフォーマンスのエンジニアリング

Windows 7 グラフィックス パフォーマンスのエンジニアリング

最高の CAD やゲーム グラフィックスなどデスクトップ グラフィックスのパフォーマンスは、Windows 開発の中でかなり多くのテストと調査が実施される分野の1つです。Windows をサポートする幅広いハードウェアとさまざまな利用シナリオは、基本的なフレーム レートからマルチ モニターでの最高のフレーム レートまで、さまざまな目標を持つエコシステムに役立ちます。Windows 7 の設計では、グラフィックスの最先端の要素を向上させる努力を続けると同時に、「実世界」のグラフィックスのパフォーマンスを向上させることを目指しました。当社のパートナーがドライバーを介してプラットフォームとなるハードウェアとソフトウェアの組み合わせを向上させるようとしています (注: Windows Vista ドライバーは、Windows Vista で機能したように機能し続けますが、Windows 7 用にドライバーを更新することにパートナーとともに取り組んでいます。これらのドライバーは、ユーザーの多くが Windows Update 経由でダウンロードしてテストしてきました)。この投稿では、広範な設計とパフォーマンスを測定するさまざまな方法について見ていきます。そして最終的に、異なるハードウェア上でさまざまなシナリオにより Windows 7 を比較テストしているみなさんに検討の余地を残しながら、Windows 7 の設計で実施した内容について報告します。この投稿は、デスクトップ グラフィックス機能チームのプログラム マネージャー、Ameet Chitreによって書かれました。--Steven

新しい PCの購入を考えるとき、「より高速なグラフィックス」や「卓越したパフォーマンス」は常に重要なアピール ポイントとなります。写真を編集し、電子メールを実行し、高解像度ビデオを見て、最新の 3D ゲームをプレイする、これらすべてのタスクをシームレスに簡単で頻繁に行き来できる、そんなより高速なシステムをユーザーは期待しています。そのようなユーザーの多くは、グラフィクス ベンチマークを実行するマニア的なコミュニティ ブログやさまざまなレビュー サイトを参照し、新しいハードウェアまたはソフトウェアのグラフィクスの実行速度を評価して結果を報告しています。従来、グラフィクス パフォーマンスは、3Dゲームを通して測定および分析されましたが、Windows の UI を使い、ウィンドウを移動または最大化する、Word または IE などでスクロールする場合など「デスクトップ シナリオ」と呼んでいるものにも影響を与えます。これらのデスクトップ シナリオのパフォーマンス要件は、3D ゲームとはまったく異なります。実際、これが、Windows Vista エクスペリエンス インデックス (Windows Experience Index、WinEI) において、2 つのシナリオを別々に評価する理由です (以下の画像で強調表示している部分)。

図 1. WEI のサンプル (グラフィックス機能を強調表示)

グラフィックス パフォーマンスは、通常、多くのベンチマークによって評価されます。これらのベンチマークは 2 つの大きなカテゴリに分類できます。

• シナリオ ベンチマーク: 特定のシナリオのパフォーマンス、たとえば、フライト シミュレーターである領域を飛行する際のフレーム レートを報告します。一般のゲームの多くには、そのゲームの典型的なシーンでグラフィックスが実行する速度を実証するベンチマーク モードが組み込まれています。
• 統合ベンチマーク: 可能な限り高速で多数の線を描く能力など、グラフィックスの特定の側面のパフォーマンスを強調表示します。

しかし、測定のベンチマークが存在しなくても、高速化のために重要なタスクは多数あります。この場合、Windows 内の計測機能を使用して、タイミング情報を取得し、パフォーマンスを分析します。

このブログでは、グラフィックス パフォーマンスのさまざまな側面、ゲームおよびデスクトップ グラフィックスのパフォーマンスの両方について説明します。ユーザーのフィードバックに対応し、最新のハードウェアを活用して、グラフィックス パフォーマンスを向上するために Windows 7 で行った変更について説明します。

デスクトップの応答性

多くのユーザーが、アプリケーションまたは Windows そのものが一時的に応答を停止することを経験しています。これは、PC のグラフィックス パフォーマンスによって大きく影響を受けるパフォーマンスの問題の一種です。この問題はデスクトップの応答の問題として分類されています。応答しない時間をなくすことは、システムでパフォーマンスを向上させる重要な方法の 1 つです。しかし、これを測定することは困難です。

応答に影響を与える問題の多くは、簡単に再現できず、また、非常にさまざまな問題があるため、デスクトップの応答性を測定することは、難しい問題です。これらの問題は現実の要素の組み合わせに依存するため、いずれの種類のベンチマークでもほとんど問題の本質を捉えることはできません。Windows 7 では、重要な OS イベントとそれが発生した時間を記録する機能を持つテスト版 Windows 7 のメカニズムを使用して、パフォーマンスの誤動作を調べることに相当の時間を費やしました。実世界でのシナリオに基づいたテスト中に応答の問題が発生した場合、テスターは記録キーを押して、発生した問題の簡単な説明を入力できます。「パフォーマンス トレース」という診断情報を含むイベント履歴がファイルに書き出され、サーバーにアップロードされます。サーバーでは、パフォーマンス分析者のチームがデータを解析して応答の問題の原因を解明します。このプロセスは、現在、問題の多くを迅速に追跡し、問題の根本原因となる範囲において成果を上げています。

この方法を使用して、ベータ テスターのみなさんが経験した 100 ミリ秒から数秒までのデスクトップのフリーズに関する大量の応答トレースを分析しました。問題の種類は、ウイルス対策プログラムがメーカーの Web サイト上で自身の更新中にすべてのアプリケーションによるディスク アクセスをブロックしていたものから、アプリケーションが UI スレッドからネットワーク アクセスを実行していたものにまで及びました。これらのトレースのかなりの部分で、ある GDI アプリケーションが別の GDI アプリケーションを待機し、そのために過剰なページング動作が発生して速度が大幅に低下していることを発見しました。これが、デスクトップ応答の問題において単独で最も頻繁に発生する原因であり、このデータなしには特定できませんでした。これらの調査に基づいて、次の 2 つの主要な分野においてアーキテクチャの改善を行いました。

1. GDI 自動実行: 複数のアプリケーションが実行されている場合の応答を向上させます。これには、GDI (Graphics Device Interface) 同期オブジェクトまたは「ロック」のコードの再設計が必要でした。
2. Windows の全体的なメモリの占有領域の削減: デスクトップのレンダリングを担うコンポーネントであるデスクトップ ウィンドウ マネージャー (DWM) に構成されるメモリ オーバーヘッドを削減します。これにより、ページング動作を削減でき、特に共有グラフィックス メモリを使用しているような、メモリの少ない PC にとって特に重要となります。

これらについて、さらに詳しく説明します。

GDI 同時実行

デスクトップ応答がどのようなものか調査した多くのパフォーマンス トレースによって、GDIの同期メカニズムを設計するためのポイントが明確になってきました。Windows Vista における GDI の設計では、単一のアプリケーションだけがシステム全体にわたる排他的グローバル ロックを保持できるため、パフォーマンスの課題が発生します。後から考えると、これは明白ですが、当初、この決定がなされたとき、システムのさまざまな部分でのパフォーマンス特性により、この楽観的な実装は完全に合理的であるとされていました。

図 2. 既存アーキテクチャでの GDI 同時実行

同時に動作する GDI アプリケーションでは、画面でレンダリングするために、このグローバル ロックが競合します。グローバル ロックにアクセスするアプリケーションにより、それがグローバル ロックを解放するまで、他のアプリケーションはレンダリングすることができません。ディスクから RAM までメモリを移動することに比較的長い時間がかかるので、ロックを保持しているアプリケーションでディスクから大量のメモリでページングする必要がある場合には、多くの場合、状況は悪化します。上の図では、2 つの GDI アプリケーションが同時に実行されており、グローバル ロックが競合します。App X がロックの維持を取得した場合、画面にレンダリングできますが、App Y はレンダリングできず、App X がレンダリングを終了するまで待機します。

図 3. Windows 7 アーキテクチャ でのGDI 同時実行

したがって、問題に対する解決策は、ロック競合を減らし、また、確実に複数のアプリケーションが同時にレンダリングできる内部同期メカニズムを再設計することにより、同時実行を向上させることでした。排他的グローバル ロックによる競合は、排他的ではなく並列処理を促進する複数の詳細に設定されたロックの実装により避けられます。詳細に設定されたロックが増加すると、単一のアプリケーションだけが一度にレンダリングしているシナリオに対して小さなオーバーヘッドが追加されます。

最も広く使用されている API スタックの内部同期メカニズムの変更により、デッドロックやレンダリング破損などのタイミングの問題を潜在的に生じさせることがあるので、GDI アプリケーションの互換性に特別な注意を払う必要がありました。

また、この作業は、マルチコア CPU 上で同時実行の GDI アプリケーションのレンダリング パフォーマンスを向上させることになりました。現在では複数のアプリケーションで同時にレンダリングできるようになったため、マルチコア Windows PC では、この変更の利点を活用できます。

GDI 同時実行作業がベータ版の元となる Windows 7 ビルドに実装された後、GDI によって 1 つのアプリケーションが別のアプリケーションをブロックすることに起因するデスクトップ応答の問題について、テスターからの報告件数が大幅に減少しました。さらに新しい実装のスケーラビリティを検証するために、2D の GDIプリミティブを描くテストを作成し、複数のアプリケーションを同時に起動することによってレンダリング スループットを測定しました。スループットは、各アプリケーション ウィンドウのフレーム レート (FPS) を同時に追加することにより測定されます。下記は、クワッドコア CPU システム上でのこれらの結果のサンプルです。

図 4. GDI 同時実行とスケーラビリティ.

Windows 7 の GDI 同時実行なしでは、これらのアプリケーションのレンダリング スループットは、事実上、単一 CPU コアのパフォーマンスに制限されます。別のアプリケーションが待機している間に、1 つのアプリケーションだけが排他的なグローバル ロックを取得できるので、このシナリオでは複数の CPU コアを持っていてもそのメリットを活かせません。ここでは、Windows 7 のGDIアプリケーションは、現在ではお互いにほとんど依存しないことを示しています。この利点では、新しいディスプレイ ドライバーを必要としません。Vista (WDDM 1.0) およびより新しいディスプレイ ドライバーのいずれでも機能します。

デスクトップ グラフィックス - メモリの占有領域の削減

システムの応答性に影響を与える別の分野は、メモリ使用量です。簡単に言えば、システム メモリ (RAM) 使用量が増加すると、システム応答を直接低下させるページング動作の増加につながります。したがって、最適の応答では、すべてのアプリケーション、プロセス、および OS コンポーネントがシステム メモリを可能な限り使用しないことが必要です。

Windows Vista では、複数のウィンドウの実行に必要なメモリ量は、システム上で開かれたウィンドウ数に比例します。これは、ウィンドウをさらに増やした場合、または、モニターでより高い解像度を使用した場合、より大きなメモリ圧力につながります。複数のモニターを使用する場合、さらに悪化します。システムの応答性を向上させるさまざまな手段を調査していく中で、DWM によるシステム メモリの使用量を大幅に減らせる可能性を発見しました。Windows Vista では、すべての GDI アプリケーション ウィンドウは、まったく同じコンテンツのメモリ割り当てを 2 つ、ビデオ メモリ内とシステム メモリ内に持っています。DWM は、グラフィックス ハードウェアによるデスクトップの構成を担当しています。したがって、グラフィックス ハードウェアが簡単にアクセスできるよう、ビデオ メモリ内に同じ割り当てのコピーを必要とします。システム メモリ内の重複コピーですが、GUIはオペレーティング システム内で、グラフィック ハードウェアによって支援または「高速化」されることなく、完全に CPU を利用してレンダリングされます。つまり、GDI アプリケーションをレンダリングするすべてのタスクは CPU が実行するため、CPU は容易にアクセスしてキャッシュできるメモリのコピーを必要とします。

図 5. 既存のメモリ割り当て

一方で、Windows 7 では、システム メモリのコピーを完全に削除し、1 つのアプリケーション ウィンドウあたり 1 つのメモリ割り当てコピーを保存します。したがって、デスクトップ上に表示される GDI アプリケーション ウィンドウでは、消費されるメモリは半分に削減されます。

 
図 6. Windows 7 でのメモリ割り当て

私たちは、グラフィックス ハードウェアを活用して共通の GDI 操作を高速化することにより、システム メモリの削減を達成しました。WDDM ドライバーでは、GDI 操作を高速化して、ビデオ メモリの CPU リードバックのパフォーマンスの影響を最小限に抑えます。これらの操作を実行しなければ、CPU 上で重大なパフォーマンス上のデメリットが発生するため、必要な処理でした。高速化する GDI 操作を決定するためには、さまざまな GDI アプリケーションの使用パターンを分析することが重要です。GDI アプリケーションの呼び出しパターン、および GDI 操作の頻度と性質についての詳細を理解するために、上位 100 個の GDI アプリケーションをプロファイルしました。

図 7. 100 個の GDI ベースのアプリケーションでの GDI 操作の呼び出しパターンおよび頻度

上記の小さなスナップショットで示すように、実世界のアプリケーション統計に基づいて、最もよく使用される GDI 操作を高速化するために、グラフィックス メーカーの パートナーと協力して、これらをサポートするドライバーを提供しました。「WDDM v1.1」というこの更新されたドライバーがインストールされた Windows 7 のシステムでは、このメモリ節約作業の恩恵を受けられます。なお、WDDM 1.0 ドライバーもWindows 7 上で完全にサポートされます。ベータ期間中に Windows Update でこの 1.1 ドライバーを提供していることに気が付かれたかもしれません。これらのドライバーも、ベータ版です。

図 8. WDDM 1.1 と WDDM 1.0 を使用した場合のデスクトップ ウィンドウ マネージャーのメモリ消費量の比較

上記のデータでは、デスクトップ上で複数のアプリケーション ウィンドウを表示した場合、メモリの節約がますます必要となることを示しています。たくさんのシステム メモリを節約すると、ページング動作が削減されます。その結果、システムの応答性は同じワークロードに対して向上します。

デスクトップの応答性の向上のために、ある種のトレードオフが発生します。たとえば、特定の操作の「迅速化」が導入されたシステム メモリの重複コピーを排除することにより、CPU でデータをビデオ メモリから読み込む必要があるため、パフォーマンスがわずかに低下しました。しかし実世界のアプリケーション統計の分析では、これらの操作がほとんど実行されなかったことがわかっています。ただし、これらの操作を発行する特定の GDI ミクロ ベンチマークでは、一部でパフォーマンス低下が見られます。これは、特定の GDI 操作に繰り返しストレスを与える既存のベンチマークを実行した場合、注意が必要な点です。なぜなら、実世界でのパフォーマンスを反映しているとは限らないからです。速度の低下がエンドユーザー機能に直接影響を与えないこと、また、メモリの節約が Windows 7 で全体的に応答を良くする結果に直接つながることがわかっています。全体的な向上点は、共有メモリ グラフィックスを備えた、メモリ制約がある PC の場合に顕著となります。

ゲーム パフォーマンス

ゲームのことを語らずに、グラフィックス パフォーマンスの話を終わりにすることはできません。ゲームは今でも広く分析され議論されています。ベンチマークには、3DMark など一般的なものから、ゲームを実行している最中にユーザーによるインタラクションなしに実行できるようなゲームに組み込まれたものまで、さまざまな種類があります。この分野は、ゲーム業界によって、実際のゲームをかなり現実的に表すさまざまな業界ベンチマークを使用して、詳しく追跡記録されてきました。さまざまなベンチマークやテストが広く検討され、ゲームのプレイヤーはこれらの測定の微妙な点まですべて精通し、その結果をプレイヤーのハードウェア、ドライバー、およびゲームに対する期待値に応じた推奨事項として役立てています。

Windows 7 では、グラフィックスパートナーと密接に協力し、同じドライバー モデルおよび互換性を維持しつつ、Windows 7 の動作への特定の変更を行って WDDM ドライバーのゲーム パフォーマンスを向上するための作業を行ってきました。パフォーマンス ツールへの継続的な投資により、マイクロソフトおよびハードウェア パートナーは、さまざまなゲーム パフォーマンスのボトルネックを追跡して分析し、それらのボトルネックを次のドライバー リリースで修正することが可能となりました。Windows Display Driver Model の基礎は Windows 7においても変更ありません。GPU スケジュールおよびメモリ管理に関する一部のポリシーは、特定のシナリオにおいてより適切なパフォーマンスを可能にするために変更されました。

これらのベンチマークは、特定のハードウェア、ファームウェア、ドライバー、システム全般に対して非常にセンシティブであるので、また、他の場合では、非常に広範に測定および検討されているので、これらの比較をサード パーティに行ってもらう予定です。Windows 7 の多くの分野がそうであるように、マイクロソフトの責任は、多くの側面にわたってより最適なパフォーマンスを設計することです。みなさんには、これらの取り組みを直接体験していただくのがよいと思います。Windows 7 を比較する際は、Windows Vista SP1 の使用をお勧めします。また、WDDM 1.0 と 1.1の相違点について、および 1.1 ドライバーがまだ開発中であることに留意してください。

最後に…

ご存知のように、Windows 7 の設計では、実世界のパフォーマンスに関するグラフィックス向けのアーキテクチャを向上させるために努力してきました。これは、どのようなハードウェアでも有益です。物理メモリが少ないシステムでも高速で効率的に Windows を実行でき、同時に、マルチコア PC では複数のグラフィックス アプリケーションをとても効率的にレンダリングできるようになります。

-Ameet

インク入力と Tablet PC

特定の市場 (医学、教育、基幹業務) 向けに、インク入力/TabletPC 機能を活用してユニークなソリューションを開発している開発者たちの大きなコミュニティがあります。彼らはこの経験に基づき、彼らのエンド ユーザーが PC (通常、スレートや壁掛けPC のようなユニークなフォーム ファクターを持つもの) 上の情報と対話する方法を効率化するために、Windows のソフトウェアを作成しています。今週初め、そのようなソフトウェア メーカー (医療用ソフトウェア) の開発リーダーから「Windows 7では自分たちにとって何が新しいのですか?」という貴重な電子メールをいただいたので、この新機能の概要をまとめてみました。この投稿はチームの複数のプログラム マネージャーが作成しました。--Steven

Tablet PC 入力パネル

私は Windows 7 のコア ユーザー エクスペリエンス チームのプログラム マネージャーをしている Jan-Kristian です。私の担当領域の 1 つはペンとタッチのテキスト入力です。これから私たちが取り組んでいるエキサイティングなことについてお話したいと思います。

私たちが略して TIP と呼ぶ Tablet PC 入力パネル (Tablet PC Input Panel) は、任意の Windows アプリケーションへ手書きでテキストを挿入するツールです。これは、テキストの入力に使用できるソフト キーボードも備えています。この入力パネルは、Windows XP Tablet PC Edition の最初のバージョンで登場し、バージョンごとにユーザー エクスペリエンスを着実に向上させてきました。

新しい手書きパッド

TIP での私たちの目標は、できるだけ軽量化し、ユーザーがその使用方法を意識することなく、書いている内容について集中できるようにすることです。Windows Vista の入力パネルで実現した改良に対して、私たちは多くの好意的なフィードバックを得ました。ただし、混乱を招いたり、必要以上に多くの手順を要したりする部分もありました。

 Windows Vista の入力パネル – 手書き認識の結果は、手書き入力領域の下部のテキストの小さな吹き出しで示されます。認識を確認するために、この吹き出しを見ていく必要があります。エラーを見つけたら、その吹き出し上をタップして、修正用のウィンドウを表示します。

Vista の遠隔測定とユーザビリティ実験の分析に基づいて、私たちは Windows 7 の向上について 2 つの重要な分野に重点を置きました。

· エクスペリエンスの簡略化 – 手書きは、容易かつ自然に流れるようなエクスペリエンスである必要があります。しかし、私たちは、TIP を使用すると、ユーザーが何を行っているかについて強く意識をせざるをえない、ということを発見しました。手書きされたものと小さな吹き出しの間で視線を素早く動かす必要があり、修正があれば別のモードに入り、しばしば単語全体を書き直すことにさえなります。私たちの目標は、これを簡略化し、より少ない負担で行えるようにすることでした。

· 柔軟性の追加 – 私たちは、入力にマウスやキーボードを使用するときの柔軟性に慣れ親しんでいます。インク ベースのモデルはいったん書かれた文章を編集するのが難しく、Windows Vista の入力パネルでの手書きには最小限の柔軟性しかありませんでした。単語間にテキストを挿入したり、単語を置換したりする簡単な方法がなかったのです。私たちの目標は、ペンの機能を使用するときの編集エクスペリエンスを、マウスとキーボードで慣れ親しんだものにより近づけることでした。

新しいモデルの作成

これらの目標を達成するには、手書きパッドを根本的に変更する必要がありました。私たちはさまざまなアイデアを検討し、ユーザーが書いているときに、インクがインプレースでテキストに変換されるモデルを採用することにしました。これは簡単な UI モデルのように聞こえますが、正常な動作をどうするかについて、いつ変換するか、テキストはどれくらいの大きさにするか、どのフォントを使用するかなど、多くの解決すべき問題がありました。自然で効率的な手書きエクスペリエンスを確実に実現するただ一つの方法は、ユーザーからフィードバックを得ることでした。そこで私たちは RITE (Rapid Iterative Testing and Evaluation) メソッドを使用しました。RITE テストは、Age of Empires II ゲームのユーザビリティ テストの一部として Microsoft で開発されたサイクル ベースのユーザビリティ メソッドです。サイクルごとに、ユーザー エクスペリエンスを少しずつ向上させ、それがうまく機能するか再テストします。文書化の準備が整ったと思えるようなデザインの最終決定の前に、私たちはおよそ 20 のサイクルを実施しました。

RITE テスト中に調整した最も重要なものの 1 つは、インクからテキストへ自動変換を行うタイミングでした。変換が早すぎたり遅すぎたりすると、ユーザー エクスペリエンスを低下させます。これを正しく行うには、各シーンの作業の裏で多くのことを行う必要がありました。私たちの最終的なソリューションは、距離のトリガー (自動的にユーザーの平均単語間隔に適応)、認識エンジンの結果に基づいたトリガー、および時間ベースのトリガーを組み合わせたものです。もう一つの問題は文字のサイズでした。私たちは結局、手書きのサイズに一致するよう動的なサイズ変更を使用することにしました。

手書き入力領域の新しいテキスト ベースの UI によって、対象のテキストにより迅速に到達できるようになります。テキストの表示が 1 か所になったことにより、エクスペリエンスの複雑さが軽減され、入力パネルの高さが低くなります。インクの代わりにテキストを使用すると、手書き入力領域は大幅に柔軟性を増し、望むようにテキストを移動できます。2 単語間に単語を挿入することが、空白に書くのと同じくらい簡単になり、また、必要に応じてスペースが自動で拡大します。

インクからテキストへの変換作業とともに、それに伴う認識されたテキストを編集する自然な方法が必要になりました。これには、ジェスチャが最適なソリューションに思えました。私たちはペン ベースの UI を作成していたので、ペンを使用するべきです。私たちはジェスチャを 3 種類 （削除、分割 (スペースの追加)、結合） に制限し、ユーザーがこれらの 3 つの操作を紙の上でどのように行うかサンプルを収集しました。そして、収集されたデータに基づいて、ジェスチャを作成しました。このジェスチャを見つけやすくするために、「ジェスチャ パネル」を追加しました。これは、入力パネルのタイトル バー上に表示される、いわば対話型の「カンニング ペーパー」です。

これらが Windows 7 の新しい手書き入力領域でどのように実現されているかご覧ください。[編注: YouTube と Windows 7 の Windows Live フォト ギャラリーを使用]:

 

Windows 7 – 手書きの概要

手書きパッド: 操作中の新しい手書きパッド。自分の操作した結果が容易にわかるように、アニメーションを使用してどうなるか示します。

スマート コレクション

遠隔測定の結果、Vista で TIP を使用する上で苦労することは、入力した文字の修正であることが判明しました。ある単語を修正するために、すべての文字を書き直さなければならないこともよくあります。Windows 7 では、Microsoft Research の成果を活用し、スマート コレクション機能を設計しました。これにより、単語の修正が非常に高速に行えます。ただ左から右へ単語を修正していけばよく、文字を入力するごとに、Windows は新しい認識を行います。このように抑制された認識により、ほとんどの場合わずかな文字修正で望んだ結果を得られます。

Windows 7 – 手書きのスマート コレクション

スマート コレクション: “Worked” が、たった 1 文字変更しただけで自動的に “Wonderful” に修正されました。単語の左から修正を始めるだけで、望んだ単語にたどり着くまで更新し続けます。

URL の入力

注目に値する手書きパッドのもう 1つの機能: 計測データによると、入力パネルが最もよく使用されているアプリケーションは Web ブラウザーでした。そして、ブラウザーを利用する際、主要なシナリオの 1 つは URL の入力です。

Windows 7 の手書き入力 - URL の修正

URL の入力: 新しい手書きパッドの柔軟性により、URL のパーツがあらかじめ設定されており、URL の入力が容易になります。

URL のセグメントがどのように分離され、そのすべてに対して意味をなす変換候補があることに注目してください。変換候補は、ユーザーの使用頻繁に基づいて決定されます。したがって、「．NET」を何度も選択していれば、それが候補の上位に挙げられ、デフォルトで URL テンプレートに設定されます。また、[挿入] ボタンは、ユーザーが URL を挿入した後にシングル クリックでそこに移動できるよう、[移動] (Go to) に変更されました。

タッチ キーボード

入力パネルには、ペンやタッチで優れた力を発揮するソフト キーボードもあります。私たちが行ったアップデートのいくつかは、可視的な更新だけのように見えるかもしれません。しかし、これらは非常に熟慮されたもので、タッチ キーボードのユーザビリティに大きな影響を与えます。たとえば、タッチ スクリーン PC は、モバイル状況でしばしば使用されます。これらを暗い画面や光の状態が最適でない画面で確実に使用可能にするには、主要なラベルの色やコントラストによく注意する必要がありました。

 Windows 7 のタッチ キーボード

タッチ ベースのキーボードの使用における課題の 1 つは、触覚的なフィードバックがないことです。その結果、キーがタップされているとき、ユーザーの指がそのキーを覆ってしまうという事実があります。指がキーを覆っていたら、正しいキー (あるいは何かのキー) を打っていることをどうやって知ることができるでしょうか? キーを打つごとに、焦点をテキスト フィールドとタッチ キーボード間で切り替える必要があるとしたら、ユーザーはタッチ入力にすぐに疲れてしまいます。私たちはユーザーに、「了解」「このキーを打ちました」といったシンプルな、ちょっとした合図を送りたいと思いました。採用した方法は、放されたキーに短時間、光のフェード アウト効果を持たせることでした。この光のフィードバックは、目的の (あるいは目的でない) キーを打ったという簡単な確認をユーザーに与えます。

キーボードはマルチタッチをサポートするようになり、[Ctrl] + [C] や [Shift] + [a] などを押すことができます。キーのロールオーバーも有効になりました。これは、指を前のキーから上げる前に、別のキーを押すことができるということです。これにより、はるかに自然な入力エクスペリエンスが実現されます。[Ctrl] キーを押してから [C] を押すという前置修飾キー (sticky modifier key) モデルをご希望の場合でも、それは引き続きサポートされていますので、どうぞご心配なく。

予測入力および手書き認識の個人用設定

私は Tablet PC 手書き認識チームのプログラム マネージャーをしている Jen です。です。以前の投稿で、私の同僚である Yvonne から新しい手書き認識エンジンに関しての話がありました。今回は、予測入力や個人設定、東アジア言語の新しい認識エンジンなど、認識エンジンの機能を増大させる新機能のいくつかを取り上げます。

予測入力

Tablet PC チームの目標の 1 つは、キーボードの使用が不便あるいは非現実的なときに、テキスト入力をできるだけ効率的にすることです。これを達成するため、私たちは TIP に投資を行いました。私たちは全体的な手書き認識の正確さを向上させ、これと同じテクノロジを活用してソフト キーボードで予測入力を提供しています。予測入力では、入力中の単語について可能性のある単語を完成して提供しますが、次の単語あるいは語句の候補を提示することもできます。

 予測入力 – ここでは英語 (米語) 用ソフト キーボードを使用して、単語「Microsoft」を入力しようとしています。最初の 2 つの文字「mi」を入力した後、最初の候補として単語「Microsoft」が提案されます。この候補を選択し、単語「Microsoft」をドキュメントへ挿入することができます。

Windows 7 では、ソフト キーボードで英語、フランス語、イタリア語、ドイツ語、およびスペイン語の予測入力を、1 字単位の入力モードの手書きで繁体字中国語と簡体字中国語をサポートしています。このセクションでは、ラテン語ベースの言語に焦点を当て、中国語などの例は次のセクションで取り上げます。

私たちが予測入力を開発したとき、主な目標はユーザーの入力速度を速めることでした。そのために、予測が適切であるようにする必要がありました。私たちの認識エンジンでは、認識の正確さを向上させるために用語集 (辞書) を使用します。システム辞書は、認識エンジンに搭載されており、任意の言語で最もよく使用される単語の一覧を意味します。この辞書を使用する場合、即座に利用可能な予測を使用してもよいのですが、ユーザー固有のその他の単語 (ユーザーの単語) を追加して、正確さを大幅に向上させることもできます。これにはテキスト収集が関わっています。

私たちは手書き認識を向上させるために、Windows Vista で米国英語と英国英語のテキスト収集 (自動学習) を搭載しました。Windows 7 では、この機能はすべての言語で使用可能です。これにより、電子メールを書くとき、入力する単語に基づいてシステム辞書を自動的に拡張できます。テキスト収集はユーザーごとに実行されるので、データは各ユーザー専用です。テキスト収集の結果から、各ユーザー専用の語彙を含む新しい辞書を構築し、既に通常使用している単語の確率を高めます。この辞書は、手書き認識と予測入力の両方で使用されます。各ユーザーの単語と使用パターンにより辞書を増強した後の結果は感動的なものです。次に入力するつもりの単語を予測する能力は、ほとんど魔法に思えます!

Windows 7 には、ユーザー辞書のサポートも含まれています。これは、システムに追加できる特別な単語リストです。企業は、医学や化学などの分野専用の辞書を開発し、システムに追加できます。たとえば、「acetaminophen」という単語の予測は、これを入力するよりずっと高速です!

東アジアの手書き認識の向上点

著しい改良が、私たちがサポートする繁体字中国語、簡体字中国語、韓国語、および日本語という 4 つの東アジア言語の手書き認識で実現されました。これらの言語は文字セットが大きいため、多くのユーザーにとって、手書きが効率的な入力方式になっています。

東アジアの手書きには 2 つの入力モードがあります。1 字単位モード (ボックス モード) およびフリースタイル モード (ライン モード) です。ボックス モードでは、固定幅のボックスへ一度に 1 文字を入力します。フリースタイル モードでは、ライン上に文字を筆記体で手書きし、文字間隔に注意する必要はありません。どちらのモードを選ぶかはユーザーの好みによります。ボックス モードの方がわずかに制約度が高く、予測入力がより正確で、ライン モードの方がより自然な手書きです。

 ライン モードでの繁体字中国語 – 上部ウィンドウにユーザーの手書き、下部ウィンドウに認識されたテキストが表示されています。

これらすべての言語にわたって中核となる認識精度の向上に加え、ユーザー エクスペリエンスを向上させるために、個人設定も使用しています。個人設定の方法の 1 つは、字形コレクターを使用してユーザーの書き方に適合させることです。字形コレクターは、手書き認識に、ユーザー独自の手書きスタイルをトレーニングするためのウィザードです。4 つの東アジア言語では、特定の文字や単語の認識を向上させたり、サポートされていない文字や単語を追加するために、字形コレクターを「トラブルシューティング」モードで使用できます。

さらに、ユーザーが書いたり誤りを修正するときに、学習が行われます。文字を書き、最初に誤認識された場合、候補一覧が表示され、目的の文字を選択できます。この操作に基づいて学習され、ユーザーが次にこの文字を書くときに、最初の候補としてそれが示される確率が高くなります。

Windows 7 では、簡体字中国語と繁体字中国語は、ボックス モードでの予測入力もサポートしています。これらの言語では、個々の文字を書くのに時間がかかるため、予測入力は特に価値があります。ユーザーが 1 字ずつのモードで書くと、全てを書く前に、単語や語句を入力するためのオプションが示されます。下記の場合では、ユーザーは中华人民共和国を入力しようとして、最初の 2 つの文字、中华を入力しただけで、目的とするテキストを予測として得ました。灰色の文字は入力された文字を示し、黒い文字は予測を示します。

この例では予測入力が、2 番目の文字 (华) と同様に始めの 2 文字 (中华) で機能していることに注目してください。他の言語もそうですが、予測入力はユーザー固有の語彙でも機能します。ユーザーが同じ単語を何回も入力すると、認識エンジンはこの動作を学習します。

私たちは Windows Vista 以来、繁体字中国語、簡体字中国語、日本語、および韓国語の手書き認識を大きく改良してきました。改良は、正確さとスループットを向上させることにより、全体的なカスタマー エクスペリエンスを向上することに基づいています。私たちの目標は、ユーザーに、これらの言語のより自然な入力方法、およびキーボード使用とは別の実行可能な選択肢を提供することです。

手書き数式認識

Word で数学の論文を書いたり、Mathematica で演算を行ったことはありますか? そして、「使いやすい入力方式のためなら、何でもするのだが、、、」と思いながら、多くのボタンや複雑な線形のフォーマットを使って数式を作成するのに何時間も費やしたことはありませんか? その願いはかなえられました。私たちは Windows 7 の手書きの向上に加え、インク入力での数式の認識に注力しました。

私は Windows の数式認識のプログラム マネージャーをしている Marko です。数式入力の最も自然で最も効率的な方法、つまり手書き認識を提供する数式入力パネルを紹介したいと思います。私たちはこの問題に対して完全に新しいアプローチをとり、手書き数式認識を機能、パフォーマンス、およびカバーしている分野を、全く新しいレベルにまで引き上げることができました。

数式入力パネル (Math Input Panel、MIP) は、Tablet PC のタブレットとペンを使用するように設計されています。ただし、タッチスクリーン、外部デジタイザー、あるいはマウスなどの任意の入力デバイスでも使用可能です。MIP は、クリップボードを介して、標準化された数学的なマークアップ言語である MathML フォーマットで認識結果を出力します。MIP で手書きされて認識された数式は、完全に編集可能な形式でレプリケート先アプリケーションに出力されます。テキストを編集したいときは、出力に対して挿入したり編集したりできます。

私たちは、可能な限り多くの数学分野と、尽きることのないさまざま数学の表記法を調査したり識別するのに多くの時間を費やしました。最終的に、高校および大学レベルの数学と、さらに高度な分野を広くカバーできました。

数式入力パネル – 上記の例で認識された数式をご存知ですか?これは複雑な分析で使用される Schwarz の公式です!

MIP の使用法は実にシンプルで簡単です。鉛筆と紙で書くように、整形式の数式を書くと認識エンジンに取り込まれます ( は認識されませんが、 は認識されるということです)。認識された数式は、プレビュー領域に示されます。誤りが全くない認識エンジンは存在しないので、MIP の優れた能力は、すばらしい修正エクスペリエンスで発揮されます (正直、人間でさえ何が書かれたか分からない時があります。私の手書きをご覧ください!)

手書きの数式が誤認識された場合、その部分 (シンボルやサブ構造全体など、どこでも) を選択して、ドロップダウン リストから候補を選択するか、数式の一部を書き直すことにより修正できます。通常、数式の一部分を修正することにより、自動的に残りの部分が 1 回の手順で修正されます。

数式入力パネルでの修正

この後、行う必要があるのは [挿入] をタップするだけです。それにより、ワープロや計算プログラムで数式を苦労せずに作成できます。

このほかにも、履歴、インクの移動、OneNote のような他のインク アプリケーションから MIP へのインクのドラッグ アンド ドロップなど、多くの素晴らしい機能があるので、ぜひご自分でお試しください。ソフトウェア開発者のみなさん、MIP を自分のアプリケーションに埋め込むことができます – 詳しくは MSDN のドキュメント.をご覧ください。

上質のアップグレード エクスペリエンスを提供する

この投稿は少々書きにくい内容です。というのも、みなさんにはWindows 7 ベータ版 を使用してくださるようお願いしてきましたが、それは手間がかかる作業です。そして次のマイルストーンでも私たちは同じことを皆さんにお願いしようとしています。しかしベータ版のリリースは、大変な数のとても厳しいテストや使用により、Windows にとって実に価値があり有益なテストサイクルでした。1 月以来、何百万もの人が ベータ 版をインストールして使用してきました。そして、お話したように、フィードバックや遠隔測定は、製品を仕上げるうえで実に価値のあるものでした。ベータ テスターのみなさんの貢献により、高品質の製品を何億ものユーザーに提供できるようになりました。私たちはすでにまとめられている計画に従っており、この投稿は計画について新しいニュースや変更を発表するものではありません。多くの人は ベータ 版を使用中だと思われるので、アップグレードに関する RC (Release Candidate) 版の動作についての注意を申し上げたいと思います。もちろん、私たちは RC 版に対し、自ら課したスケジュールに従って懸命に取り組んでいます。

ベータ プロセスの大部分は、できるだけ多くの「実世界」のシナリオやエクスペリエンスをカバーし、そのエクスペリエンス全体を遠隔測定でモニターすることです。エンジニアにとって最も挑戦的な分野のひとつに、ある Windows リリースから他の Windows へのアップグレード プロセスがあります。考えてみてください、アップグレードを行う前、基本的にシステムのすべてを「知る」ために、一度に膨大な量のコードを実行しなければなりません。Windows 7 の開発中、何百回とオリジナル OEM イメージの Windows Vista からのアップグレードを日常的にテストし、そしてアップグレードの成否を検証するために自動テストを実施しました。また、何千ものアプリケーションと何千ものデバイスについても、アップグレード プロセスで正しく移行できるかテストしました。

多くの人は Vista が動いていた PC に Windows 7 ベータ版をインストールしていました。遠隔測定でそれが判明し、それに対応してきました。ベータテストの期間中、アップグレードのエクスペリエンスを改善し続けることができたと信じています。同様に、遠隔測定によると、大多数の人は新しいパーティションに新規インストールしていました。この遠隔測定を通して、デバイスのエコシステムと、どのドライバーがすでにあり、どれが足りないかがわかりました。また、ボタンやコネクター、その他のハードウェア コンポーネントのサポートを有効にするために、(XP または Vista からの) ドライバーやアプリケーションのインストールが必要な PC に固有の機能についてもわかりました。あわせて、私たちはセットアップ エクスペリエンスの広いエリアをカバーできました。

また、(何百万もの) 多くの人は Windows 7 ベータ版を常時使用していることもわかりました。みなさんは最新版を心待ちにしていらっしゃることでしょう。みなさんは、すべてのアプリケーションをインストールし、システムを設定してカスタマイズされてきました。そして、RC 版を入手して、すぐにでも ベータ版からアップグレードしたいと思っていらっしゃることでしょう。しかしながら、RC 版は、実世界のシナリオで製品を検証するために、広範囲で使用されることを目的としています。そのため、みなさんには、既存の ベータ版からアップグレードするのではなく、Vista イメージの状態に戻してからアップグレードまたは新規インストールされることをお勧めします。それは再インストール、再カスタマイズ、再設定、などを意味することはわかっています。そして、それはとても面倒なことです。しかし現実は、あるプレリリース版から他のプレリリース版へのアップグレードは重きを置いているシナリオではありません。なぜなら、それは実世界のユーザーが体験することではないからです。開発中、製品 (の中身) に変更を加えますが、私たちが「ビルドからビルド」へのアップグレードと呼ぶものに対して、常に互換性があるとは限りません。サポートされたアップグレードのシナリオは、Windows Vista から Windows 7 です。ビルド間のアップグレードが絶対に必要であれば、そのメカニズムを提供したいと思いますので、このブログのコメント セクションへ移動する前にお読みください。開発チームのメンバーの一員として、また ベータプログラムの参加者として、みなさんには、実世界のセットアップを体験し、実世界の遠隔測定データを提供してくださるようお願いいたします。

下記の手順を踏むと、アップグレードに奇妙な現象に遭遇するかもしれません。マイクロソフト社内でもたまに経験しますが、問題を突き止めて修正することはしていません。なぜなら、この問題は一回限りのプレリリース版での作業でしか現れないので、他のバグに時間をかけたいからです。ときどき、私たちがオフィシャルにリリースしていないビルドを使用して、アップグレード後の「不安定さ」について不満を言っているブログを見かけます。が、たいがいの問題は、ビルド間の問題によるものです。メッセンジャー クライアントが動かなくなった、プリンターやデバイスが「消えた」、スタート メニューのショートカットが2重になっている、といったことを言う人を見てきました。多くの場合は問題になりませんが、最悪の場合はソフトウェアやデバイスをインストールしなおさなければなりません。

私たちは決定論的で、実世界で役に立つ製品を作ろうとしているだけです。実世界と言ったとき、多くの人は Windows XP からのアップグレードがどうなるか疑問に思っているでしょう。それについては、これまで多くのフォーラムで説明してきたように、計画に変更はありません。このプロジェクトを始めた時、XP からの「アップグレード」はすばらしいエクスペリエンスをもたらさないであろうことがわかりました。なぜなら、PC の設定方法 (アプレット、ハードウェア サポート、ドライバー モデルなど) に膨大な変更があり、それらを Windows 7 へ持ち越してサポートするのは、新規インストールするほど高品質な結果になりそうにないからです。このことは、多くの人がわかっていて、すでに経験されていることです。私たちはファイルや設定の移行のサポートを提供し、セットアップ時にも指示するようにする予定ですが、アプリケーションは再インストールする必要があるでしょう。あるユーザーにとっては、このトレードオフは割が合わないものかもしれませんが、先行投資する時間は十分に価値のあるものだと思います。

RC より前のビルドからアップグレードしようとしたとき、実際にはできなくて、そのまま終了しないといけないということがわかるでしょう。新規インストールは可能で、もしアカウント、設定、ファイルなどを移行したければ Windows Easy Transfer の機能も使用可能です (もちろん、現在インストールされているところから起動します)。バージョン チェックをスキップするには、下記の手順のように企業ユーザーのために用意されているメカニズムを使用します (私たちもこれはテストしています)。単純なコマンド ライン スイッチではありません。わざと複数の手順にしたわけではなく、実績があり、ドキュメント化され、テストされたメカニズムを使うことにこだわりました。

この説明書は簡略版です。これを読まれているみなさんは、経験豊かで精通したベータテスターですから、いかなる OS でもインストールを実行する前にはいつもマシンのバックアップを取ることと、OS を自分のデータが 1つしかない環境ではテストしないことはご存知でしょう。プレリリース製品をテストするということはそういうことです—これはテストであり、正式にリリースする前のものです。たとえ、RC (製品候補) 版であったとしても、まだ製品はテスト中です。私たちは非常に強い自信がありますが、万が一エラーが発生するかもしれないので、みなさんには通常のプレリリース製品と同様に予防策を講じるようお願いいたします。

関連した注意事項として、Microsoft からオフィシャルにリリースされたビルドのみをインストールすることがあげられます。「最先端」のビルドを入手することは常に心をそそることですが、そのビルドに対して何がされているか本当のところはわかりません。最新のものを手に入れるのはワクワクしますが、定量化すらできないリスクも伴います。RC では、ハッシュ値またはそのほかの方法でビルドを認証できるようにする予定ですが、ベストな方法は常に Microsoft から直接ダウンロードすることです。

下記は、もし本当に必要なら、プレリリース アップグレードのチェックをスキップするための方法です。

1. ISO イメージをダウンロードし、DVD に焼きます。
2. アップグレードを実行したいストレージの場所 (ブート可能なフラッシュ ドライブ、またはプレリリース ビルドが動いているマシンのいずれかのパーティション内のディレクトリ) に全イメージをコピーします。
3. [sources] ディレクトリに移動します。
4. メモ帳などのテキスト エディターで cversion.ini ファイルを開きます。
5. MinClient のビルド番号を、古いビルド番号より小さい数字に変更します。たとえば、7100 を 7000 に変更します (下記の図を参照)。
6. ファイルを同じ場所に同じ名前で保存します。
7. この変更したイメージから、通常どおりにセットアップを起動します。するとバージョン チェックがスキップされます。

同様の手順が、RC のマイルストーンから RTM (最終製品) のマイルストーンへ移行する際にも必要になる予定です。

繰り返しになりますが、多くの人 (Microsoft 社内の何万人も含めて) は、Windows 7 のプレリリース ビルドを基幹業務や毎日の仕事で頼りにしており、この手順は決して便利とはいえないことはわかっています。私たちは非常に高品質な製品を提供するために一生懸命取り組んでおり、このテストの最終段階ではできるだけ実世界のシナリオをサポートするようにしたいと考えています。つまり、ビルドからビルドへの上書きアップグレードは、そのようなシナリオではないのです。同時に、ベータ版の時みなさんは大変すばらしかったので、少なくとも、自身の専門性を活用して十分な説明を受けたうえで、アップグレードをどう処理するかについて選択のチャンスを提供したいと思いました。

私たちは常に、リリース前後の興奮やプレリリース版の実行を選んだ人々のサポートや熱意を謙虚に受け止めています。私たちはプレリリース版を実行するために費やされたみなさんの時間や努力に対して大変感謝しています。お返しに、製品の進化の各段階で、すばらしいリリースを提供したいと思っています。次は RC です。では、そこでお会いしましょう！

ありがとうございます!

--Windows 7 チーム

追伸: 上記の手順 1 において、多くの人は「なぜ DVD に焼かないといけないのか? ISO をマウントするだけではいけないのか?」と思われるかもしれません。そのようなフィードバックをこれまでにもいただいており、それは当然のことです。Windows 7 にはこの機能はありませんが、あるべきだと思っています。マウントするためのサードパーティー製のツールがいくつかあるので、Vista のイメージがあれば、PC にそのようなツールが付いてきているかもしれません。