27日、Windows Vista β2のアップデートビルド、Build 5456.5の案内が届き、さらにその日本語版も即日に公開された。

　Vista初の広域βとなるβ2は、実装面でかなり製品に近くはなっているものの、まだまだ洗練度が低いものだっただけに、新ビルドでのパフォーマンスの向上と機能面での洗練度、バグの修正具合を楽しみにダウンロードを開始していたのだが、そんな真夜中にチャットコールに応答すると﹁WinFSが延期らしい﹂という情報が届いた。

　すでにその内容は元麻布氏が速報記事を入れているが、これによるアプリケーションへの影響の大きさは計り知れない。WinFSは最初のWidnows Vistaからは外されていたものの、将来的には追加モジュールとして提供され、WinFXを構成する3つの主要なモジュールの1つになるハズだった。

　情報ストレージに関するMicrosoftの挫折は今回が初めてではない。さまざまな犠牲をはらいながら、やっとOSへと統合されることになっていたWinFS実装の断念は、他製品にも影響を及ぼすものだ。


●WinFS断念の“小さな”波紋

　もともと最初からはVistaに組み込まれないWinFSが、WinFXから外れてなくなってしまったとしても、あまり気にするユーザーはいないかもしれない。さほど大きくない、いやむしろ“小さい波紋”と感じる人が多いのではないか。

　WinFSのFSは、“ファイルシステム”と紹介されることも少なくないが、実際には“フューチャーストレージ”の略で、一般的なファイルシステムの概念とは少し異なる。リレーショナルデータベース技術を活用したという意味では、BeOSなどが同様のコンセプトを持っていたが、それとも実装の手法は異なる。

　既存のNTFSとサイドバイサイドで動作し、ファイルコンテナとしてはNTFSを利用して互換性を保ち、それに対応するDBの管理をWinFSで行なうといった仕組みで動作している。このため従来との互換性を確保した上で、リレーショナルデータベース的機能を収めることができた。データの入出力にはXML技術を用いており、ネットワークアプリケーションとの親和性も高い。

　加えてOS側でいくつかのデータスキームが標準で定義されており、同じコンピュータ内で同じ意味のデータを重複管理することがなくなる。たとえば住所録において﹁出版社のインプレス﹂さんは、複数のデータを持つ必要はない。1つのマスターがあれば、同じデータベースにさまざまなアプリケーションがアクセスすればいい。追加のデータを扱いたい場合は、XMLスキーマを拡張定義して用いれば、少なくとも共通部分に関して同じ情報を共有、管理することができる。

　これらの機能や特徴を駆使すれば、人、場所、画像に関する情報など、日常的に収集される情報に対して共通のデータ保存・参照手法を簡単に実装可能になる。またオフラインアクセス向けの解決策も用意されており、WinFS対応アプリケーションが増加することにより、ユーザーは運用によってカバーしていた各種情報管理の煩わしさから解放されるハズだった。

　とはいえ、WinFSがなくともボリューム全体の全文検索は可能であり、WinFSがなくともさまざまな切り口でファイル閲覧の方法を切り替えることもでき、WinFSがないからといって住所管理やスケジューラソフトが動作しなくなるわけではない。データベース複製などという複雑なことをしなくとも、改良されたオフラインフォルダ機能があれば十分と思う人も(今は)少なくないだろう。

　しかしこの小さな波紋は、ジワジワと広がって大きな影響を及ぼしていくだろう。


●小さな波紋から大きな波紋へ

　WinFS廃止の小さな波紋は、徐々に広がって大きな波紋へとつながる。その波は小さなもので、ユーザーは気付かないだろう。しかし小さなズレは、結果として得られたはずのユーザー環境とは全く異なるものだ。データ管理に関する管理性が“今と変わらない”ことは、先に進んでいたはずの世界から見れば“後退”である。

　実はMicrosoftが、次世代の情報ストレージに関して挫折したのは(数え方にもよるが)今回が3度目だ。
　最初はオブジェクト指向OSとして構想されていた﹁Cairo﹂にさかのぼる。Cairoはファイルシステムをオブジェクトストアとして実装し、さまざまな情報を多くの付加情報を持つ意味づけされたデータとして管理すると言われていた。加えてExchangeの将来像とも重ね合わされ、サーバー上のミドルウェアはCairoのオブジェクトストアを用いて情報アイテム、フォームなどを直接記録できるなどと言われた。しかしその後、Cairoが具体的な姿として市場に登場することはなかった。

　その後、インターネットを中心にした市場環境の変化、技術トレンドの変遷に伴い、MicrosoftはXMLとWebDAVを基礎にした一種のデータベースで、Webアプリケーションの配布にも利用できるWeb Storage Service(WSS)を開発し、同社製ソフトウェアに全面的に採用する計画を示した。たとえばExchange 2000や、SharePointの最初のバージョンなどがそうだ。

　WSSに合わせてOfficeチームはLocal WSS(LWSS)というモジュールも開発している。これはWSSに対するプロキシサーバーのように動作するソフトウェアで、透過的にWSSにアクセスしつつローカルキャッシュやWSSデータベースの複製を保持し、オフライン時にもWSSのデータにアクセスし、Webベースのアプリケーションを動作させることを可能にするもの。Office XPの一部として開発され、OutlookがLWSS対応アプリケーション第1号になるはずだったが、結局、Office XPのβ2以降では削除されてしまった。

　実現していれば、ExchangeとOutlookが、XMLベースの共通アーキテクチャを持つデータベースで結ばれる美しい形となったのだが。削除された表向きの理由は、LWSSが当時主流のPCではメモリ、処理能力両面で厳しいというものだったが、実は同時期にMicrosoftはWSSを主要なオブジェクトストアのインフラとすることをやめて、SQL Serverのエンジンを利用する方針に転換している。

　この方針転換こそ、当時のLonghorn、すなわち今回、Windows Vistaへの実装をあきらめたWinFSへとつながっている。Microsoftがオープン標準をベースにしたWSSではなく、自社のSQL Serverをベースにしたシステムで統一する方針にした理由はわからない。だが、BackOfficeやOfficeのチームが作っていたデータストレージインフラが、Windowsチームの決断によって崩され、他製品にも与えた影響は少なくない。看過できる問題だったかもしれないが、肝心のWinFSが登場しないのであれば結果の出しようもない。


●WinFS廃止でOffice開発チームは救われる?

　こうしたストレージシステムに関連するMicrosoftの“蛇行”は、もちろん他社製品にも影響を与えているだろうが、もっとも影響を及ぼしているのは自社製品である。先行して自社の最新技術を採用するBackOfficeやOfficeなどでは特に顕著だ。その中でも身近なOutlookのデータ保存形式について見ると、Office開発チームの苦悩がわかる。

　OutlookはAccess用に開発されたデータベースのJETエンジンを基礎に、メッセージを保存している。Outlookはメールだけでなく、さまざまな情報アイテムを保存し、一括管理し、さらにオフラインアクセスにも対応する仕組みのため、汎用的なデータベースエンジンが必要だったためだ。Exchangeサーバー自身がJETベースだったからというのも、もちろん理由の1つだろう。

　しかしJETはパフォーマンス、最大サイズ(当時は2GBまで。現在は拡張されている)、現行技術との親和性などに問題があり、前述したように将来を見据えてWSSとLWSSを用いたXMLベースのアーキテクチャに移行。同じくWSSを採用するExchange Server 2000とはWebDAVでコミュニケーションし、WebアプリケーションをExchangeフォーム上で動作させることが可能に……。と、技術トレンド、オープン標準などを踏まえつつ、新しい仕組みに移行する。LWSSはWSS対応アプリケーションから透過的に利用できるため、Outlook以外のサードパーティを含むソフトウェアがこの仕組みを利用できるはずだった。

　が、結果的にこれがWindowsの開発方針に引っ張られ(当時、Longhornは2003年には登場する予定だった)、OulookはJETエンジンベースの古いアーキテクチャで作り直しされ、メッセージ保存データベースの改善は次のバージョンに先送りされた。

　ところがLonghornの開発スケジュールは早々に遅れが表面化。Office 2003の世代でも間に合わないことがわかった。そこでOfficeチームはJETを改良することにして、Outlook 2003ではJETのままでExchangeとのHTTP経由での同期や、キャッシュ動作モードのサポートなどを追加している。このとき担当者は﹁早々にあきらめてOfficeチームだけで対処することに決めていた﹂と話していた。

　そして現在βテストが行なわれているOffice 2007だが、この中に含まれているOutlook 2007も、Outlook 2003と同様にJETをベースとしたアーキテクチャを引き継いだ。実は初期段階ではWinFSを基礎にプロトタイプまでは開発したようだが、Windows Vistaの最初のリリースにWinFSが間に合わなくなったため、急遽、仕様を変更してコードを書き直したのだという。

　とはいえ、次のOutlookではいよいよWinFSを用いたアーキテクチャに、との構想は描いており、Office 2007でのWinFSの応用についてアイディアが出されていたのである。が、それもキャンセルされたことで、Officeチームは構想の練り直しを迫られることになる。


●落胆の大きさ

　“Microsoft自身の責任なのだから”と、Officeチームの不幸を笑うことはできない。

　功罪はあるにせよ、Outlookは世界でもっとも多く使われているメッセージクライアントの1つだ。Outlookを基礎に、同期を行なうためのソフトウェアやネットサービス、PDAや携帯電話などの機器が多数ある。

　WinFSへの移行によって、それらはOutlookというMicrosoft独自のアプリケーションという枠を超えて、WindowsのAPIを通じて共有するデータベースから同じ情報を引き出すことができたはずだったのである。これはOutlookにとどまらず、すべてのWindowsアプリケーションに共通するものだ。

　今後はまた、データ保存形式やオフライン時の複製などについて、個別に仕様をまとめてシステムとしての連動をさせていかなければならない。WinFSこそがWinFXの中でも目玉の機能だと思っていた開発者の落胆は大きなものだろう。

　WinFSの開発成果自体は、SQL ServerやActive Data Object .NETなどで応用されるというが、実質的にはOSへのオブジェクトストア機能実装の挫折と捉えるのが正しいだろう。WinFSそのものが掲げていた理想は、それらでは達成することはできない。

□関連記事
︻6月28日︼︻元麻布︼Microsoft、WinFSの開発中止を表明
http://pc.watch.impress.co.jp/docs/2006/0628/hot434.htm
︻2005年7月27日︼︻本田︼Windows Vistaが描く風景の完成度
http://pc.watch.impress.co.jp/docs/2005/0727/mobile300.htm
︻2005年3月10日︼︻本田︼すべての問題はLonghornへと繋がる
http://pc.watch.impress.co.jp/docs/2005/0310/mobile280.htm

□バックナンバー

(2006年6月29日)

[Text by 本田雅一]