先週、複数の報道によって、Windows 7 にアップグレードする前は適切に機能していたと思われるシステムで、Windows 7 が「consider replacing your battery (バッテリを交換してください)」と警告すると述べているユーザーのブログやフォーラムに注目が集まりました。これらの記事では、Windows 7 は消耗しつつあるバッテリをユーザーに警告せず、この状態を誤って報告し、さらに悪いことにバッテリをダメにした、とするサポート フォーラムの投稿を紹介していました。－しかしWindows 7 は消耗しつつあるバッテリの警告メッセージを表示するように設計されているのです。エコシステムでのこれまでの経験で知る限り、Windows 7 は、実際に消耗しつつあるバッテリについて適切に警告し、バッテリのステータスに関して誤って報告することはなく、いかなる方法によってもバッテリにダメージを与えることはありません。私たちが確認できたどのケースでも、交換する必要があると報告されているバッテリは、実際に交換の必要がありました。

フォーラムでこの問題についてレポートしているユーザーへの連絡、カスタマー サービスとのコミュニケーション、PC メーカーとの協力、そしてもちろん Windows 7 での遠隔測定など、利用できるすべての手段を使って、この新機能に関するレポートやディスカッションを注意深くモニターし、意図された動作に関するレポートを Windows 7 の問題点を示している可能性があるレポートから分離するようにしています。後者のケースでは、適用範囲の理解と、問題の現象を再現できるハードウェアの入手を試みています。これらすべての手順によって、これまでに、バッテリの調子の件で通知メッセージを見たユーザーがいて、調査したすべてのケースで、Windows 7 は単に消耗したバッテリを正確に検出していたことが判明しています。この特定の問題に関する私たちの立場をお伝えする前に、この新機能の背後を見ていく必要があるでしょう。

PC のバッテリ寿命 (バッテリ電源での実行時間) の最も大きな要因は、バッテリそのものです。PC のバッテリは本質的に、電荷を保持して電力を提供する能力が減衰していきます (すべての充電式バッテリはそうです)。この原因は複雑で、バッテリ化学における不可逆的変化や、他の物資との増加した内部抵抗、バッテリの設計や製造に関係があります。この減衰は、ユーザーにとっては、PC を使用するにつれて内蔵バッテリの寿命が低下することを意味します。最終的には、満足できるバッテリ寿命に復元するために、バッテリを交換する必要があります。主流のラップトップ PC について簡単に調べたところ、バッテリの保証期間は通常 12 か月で、これは統計的に、認識できる減衰 (より頻繁に充電する必要があることに気付き始めるという意味) が生じると思われる長さです。2、3 年間同じラップトップ (または、携帯電話、音楽プレーヤー、あるいは他の充電式バッテリ内蔵の製品) を所有して定期的に充電していると、間違いなくバッテリの寿命が短くなっているのを「感じ」ますが、情報がなかったので、さまざまな要因のせいにしてきたかもしれません。

Windows 7 では、バッテリの全体的な調子を Windows に報告できる回路およびファームウェアを備えた現代的なラップトップ バッテリの機能を活用しています。これは、ワット時 (W-hr) 電力容量として絶対的に報告されます。そして、Windows 7 は簡単な計算を行って、元の設計容量から低下した割合を判定します。Windows 7 では、しきい値が 60% の減衰 (バッテリが設計容量の 40% を切って動作している状態) に設定されており、この値を切ると Windows 7 はユーザーに状況を報告します。この時点で、たとえば、本来 5 時間稼動が可能な程度に充電できたバッテリは、平均で約 2 時間分しか充電できません。Windows 7 では、バッテリ メーター アイコンと「Consider replacing your battery (バッテリを交換してください)」という通知メッセージで、このことをユーザーに知らせます。この通知は Windows 7 の新機能で、Windows Vista や Windows XP にはありません。

PC のバッテリは、システム ファームウェア (または BIOS) を介して、バッテリ容量とステータスに関する情報を提供します。ファームウェア インターフェイス (ACPI) について詳細な仕様規定がありますが、最も基本的なレベルでは、ハードウェア プラットフォームとファームウェアは、バッテリとその状態を説明する複数の読み取り専用フィールドを提供しています。ファームウェアは、「製造者名」、「シリアル番号」、「設計容量」、「最終的なフル充電容量」といったバッテリに関する情報を提供します。最後の 2 つの情報 (設計容量と最終的なフル充電容量) は、バッテリが自然にどの程度減衰したか判断するために Windows 7 が使用する情報です。この情報は読み取り専用となっており、Windows 7 や他の OS がバッテリ状態の情報を書き込んだり、設定したり、構成したりすることはできません。実際、充電および放出というバッテリの動作はすべて、バッテリ ハードウェアによって完全に制御されています。Windows は単に、システム ファームウェアから読み取ったバッテリ情報を報告するだけです。いくつかのレポートで、Windows がバッテリ情報を変更していると誤って述べられていますが、そのようなことはありえません。

前述したように、調査したレポートに関して唯一言えることは、Windows 7 は単に新機能を使用してバッテリのステータスを報告しており、問題のバッテリは単に設定されたしきい値を切っているということです。以下に、この観点をサポートするデータについて説明します。以前は正常に動作していた PC で、アップグレード後にこの警告が表示されて驚くユーザーがいるのは当然のことです。本質的にバッテリは減衰していきますが、Windows 7 がこの情報を伝えるまで、ユーザーにはこのことが明らかではなかったのです。Windows 7 がパフォーマンスを悪化させた「原因」ように一見思われますが、実際には Windows 7はただ既成事実を報告しただけであると、私たちは認識しています。

下記のデータの要点は、調査中のレポートの理解に役立っています。ちなみに、私たちが見ている遠隔測定はすべて、オプトイン (自発的に承諾) かつ匿名で、プライバシー ポリシーが遵守されています。

• 新しいハードウェアまたは新しく購入された PC では、この通知メッセージが再現できるというレポートはまだありません。新しい PC でこの通知メッセージが表示されたというレポートがありましたが、すべてのケースでバッテリが減衰状態にあったことを確認できました。
• PC メーカーのパートナー様からは、遠隔測定 (コール センター、サポート フォーラムなど) を活用して情報を収集しているが、想定外の動作は見られないとの知らせを受けています。PC メーカーが、バッテリ問題に関して顧客と連携していること、一般的な観点および特定のモデル、タイムライン、バッテリを考慮したうえでの観点の両方において、期待されるものが何であるかの明確な考えを持っていることはとても貴重です。
• 私たちは主要なオンライン サポートおよびセルフヘルプ フォーラムをチェックし、適切と思われる場合には、誤って表示されたこの通知メッセージに関するレポートの追跡調査を行ってきました。しかし、新しいバッテリまたは PC で通知メッセージが再現されるケースはなく、ただ容量が低下したバッテリのみが確認できました。
• RTM コードを使用しているユーザーの遠隔測定では、ごく一部のユーザーのみが「Consider replacing your battery (バッテリを交換してください)」のメッセージを受け取っています。そして予想どおり、それらのシステムは 1 年半以上使用されています。システムの平均使用年数が少ないほど、プレリリース ソフトウェアの場合と比較して、通知がより少なく表示されていました。
• Microsoft ではこれまでに、サポート サービスで12 のお問い合わせと、さまざまなフォーラムでの 8 つのインシデントを見てきました。現在まで (合計 20 のインシデント)、減衰したバッテリ以外確認できませんでした。
• Microsoft では TechNet のモデレーターにお願いして、この通知メッセージに関してレポートしたユーザーにさらに問い合わせてもらっています。また、この件に対応できるサポート サービスのスタッフを増やしました。ただし、受け取った約 30 のレポートでは、この通知メッセージに関する新しい事実や条件は得られませんでした。
• 私たちは Windows 7 のプレリリース (リリース前の) テスト中に、このメッセージの表示に関してユーザーとほぼ同じ経験をしています。実際には、プレリリース テストでのハードウェアの配分を考えると少し多いと思える割合のシステムで、このメッセージが表示されました。これは、ユーザーの皆様の多くは Windows 7 搭載の新しい PC を購入するか、Windows 7 へのアップグレード付きの最近の Windows Vista PCを使用している結果として起きたことです。
• この通知メッセージを表示すると報告されたコンピューターの遠隔測定レポートを見ると、この他にシステムの異常を示す信頼性データはありませんでした。
• バッテリのステータスに関する情報は ACPI によってオペレーティング システムに読み取り専用で提供されますが、私たちは完全なコード レビューを実行し、バッテリ状態の情報を変更できるコードが存在しないことを確認しました。

これらのデータはまさに、長期わたってバッテリが自然に消耗しているという視点の正しさを証明するものです。この Windows 7 の新機能で提供された透明性により、以前はわからなかったものが、アップグレード直後にメッセージが表示されるようになりました。これが、投稿が急激に増えた根本的な原因で、バッテリの条件は実際には変わっていません。買ったばかりのバッテリを搭載した新しいコンピューターで、この問題が確認されたケースはありません。

Windows 7 の品質に関するレポートに関して常に述べているように、私たちはこれからも真摯に努め、利用可能なツールをすべて使用して、コードの変更が必要になる可能性のあるレポートの背後に迫っていきます。私たちがこのレポートの根本的な原因および懸念事項に対処してきたことは確かですが、引き続き動向を監視していきます。特に、長年にわたってユーザーや PC をモニターしているシステム メーカーとの情報交換に、重点的に取り組んでいきたいと思います。

最後になりましたが、バッテリが新しくまだ消耗してないはずなのに、この警告メッセージが表示されているとお考えのときは、製造元の PC メーカーに報告されることをお勧めします。また、このページにある Email フォームでメッセージをお寄せください。TechNet フォーラムや Microsoft Answers フォーラムを使用したり、マイクロソフト サポートオンラインでお住まいの地域の Microsoft サポート サービスへのお問い合わせ方法を確認したりすることもできます。

今週、あるブログで 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

このブログでも何度もお話ししてきたように、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 チーム

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 の詳細については、https://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

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

みなさんは 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 リリースにおけるカスタマイズについてのデータはすでにお話ししており、今回の投稿はそれに基づいたものです。また、この分野は個人設定に対する非常に幅広い要望 (ニーズ) があり、しかも当然エンジニアリングとデザインの間でバランスを保たなければなりません。スクリーンのほぼ全域を個人設定 (カスタマイズ) したいと思っているたくさんの人からメールを受け取りました。それこそ、境界線の幅から、タイトル バーの透明度、タスクバーの高さ、[閉じる] ボタンの色・サイズ・場所までです (それぞれについて、少なくとも一度は電子メールを受け取りました)。その一方で、背景の画像と色彩を簡単に変更できればとても満足、という方々も多くいらっしゃいます。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

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

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

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

この投稿は、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