■ 第309回 ■ Avalonがもたらすユーザー環境への変化

　もともとソフトウェア開発のプロ向けという事もあり、PDCはエンドユーザーにとって縁遠い印象があるかもしれないが、そこには数多くのエンドユーザー自身が将来体験するであろう、コンピューティング環境の未来を示すエッセンスが詰まっている。

　会期を終えての率直な感想を言えば、“よくここまで仕上げたものだ”と少々驚きを持って伝える事ができる。OSの核の部分に関しては、今後も継続してウォッチを続ける必要があるとは思うが、開発者が触れるアプリケーション開発のためのFoundationは、想像していたよりもずっと高い完成度を示しているようだ。

　アプリケーション開発のためのプラットフォームとして、次世代のWindows、つまりWindows Vistaが良いものに仕上がっているという事は、エンドユーザーにとっても無関係の話ではない。

　過去の例を見ればわかるように、ソフトウェア開発者が支持するプラットフォームは、必ず発展してきた歴史があるからだ。ユーザーにとって重要なのはOSではなくアプリケーションというのは当たり前の話だが、そのアプリケーションを実現するのはソフトウェアである。そのソフトウェアを開発するベンダーのモチベーションを刺激し、新しいアイディアを引き出すのは、やはりOSなのだろうというのが、PDC2005で最も強く感じた部分だ。

編集部注：本記事の画像は、サムネールをクリックすると別ウィンドウで開きます

●Avalonはエンドユーザーに何をもたらすのか

　Windows Vistaが実現しようとしているコンセプトや機能は、これまで何度も繰り返し伝えられてきた。Windows Vistaのニュースに興味を持っている読者なら、Avalon改めWindows Presentation Foundation(WPF)が、2D/3Dのグラフィックス、テキスト、動画、音声などを統合した複合型メディアエンジンであり、DirectX 9の上に構築されている事はご存知だろう。GPUが持つパワーを活用するため、ピクセルシェーダーを用いて描画処理を行なおうというAvalonの実装コンセプトについても何度か紹介してきた。

　Windows 2.xに端を発して拡張されてきたGDI、GDI＋は、プリミティブなグラフィック操作の集合体だ。しかしWPFはもっと上位に位置する機能を持ち、各種メディアをアニメーションエンジンの上で統合する。各グラフィックの要素は3Dモデルとテクスチャ(2Dの描画結果や動画もテクスチャの一種)へとブレークダウンされ、それらをGPUのパワーを用いてデスクトップ上でユーザーに情報を“体感してもらう”と言えばわかりやすいだろうか。

　アプリケーションが求めるグラフィック面での操作は、ほとんどすべてWPFの中にあるため、プログラマはリッチで見栄えのするユーザーインターフェイスを作るために、いちいちアニメーションをビットマップとして作ってブロック転送する必要はない。

　しかもピクセル単位の解像度からも解放されるため、ユーザーがウィンドウをどのような大きさで表示するのか、どの程度の解像度(ピクセル密度)のディスプレイを使っているのかなどをプログラマはさほど意識しなくとも、キチンとしたレイアウトでユーザーに見せてくれる。

　これまで非常に手がかかり、単純で面倒くさい作業だったユーザーインターフェイスを豊かにする部分で、すべてWPFに“お任せ”で動かす事ができるのだ。これはとても画期的な事だ。世の中のあらゆるプログラムの作成者が、そのユーザーインターフェイスを本当に使いやすくするためのアイディアを出し、デザインする事に集中できる事を意味しているからだ。

　しかもMicrosoftはユーザーインターフェイスのデザインと、機能のロジックを記述するための手法を完全に分離させている。Avalonを用いたアプリケーション開発の典型例では、ロジックをC#で記述してマネージドコード(CLR)にコンパイル。ユーザーインターフェイスはXAML(XMLベースの、WinFXアプリケーションを記述するためのマークアップ言語)で記述する。

　Microsoftは今回のPDCでExpressionシリーズという、グラフィックデザイン、ユーザーインターフェイスデザイン、アニメーションデザインを行なうツールを発表しているが、これらでデザインした結果はXAMLとして出力できる。

　ロジックを記述するプログラマはVisual Studio.NETでC#のコードを書き、デザイナーはExperienceシリーズを用いてWebアプリケーションのユーザーインターフェイスをデザインするのと同じような手順で、WPFのリッチな機能を活用したデザインを実装。その分業がキレイに行なえるのだ。

　PDCのセッションでは、非常に分かり易い形でそれが表現されていた。2つの画面は全く同じコードを、異なるXAMLで実行したものだ。プログラムロジックは同じため、その振る舞いは全く同じになるが、XAMLの中でWPFへと指示されている内容が異なるため、画面デザインは全く異なるものになっている。このグラフィックを比べるだけでも、WPFが生み出すダイナミズムのようなものが理解できるのではないだろうか。

　Windows Vistaによってアプリケーションのユーザーインターフェイス部分は、明らかに大きな変化が起きるだろう。もちろん、これまでに言われてきた色の扱いに関する違いや解像度非依存性の高さなどもメリットではあるが、それ以上にアプリケーションユーザーインターフェイスの変化という面で、ユーザーはWPFの恩恵を受けることになるだろう。

2つのアプリケーションの背景で動いているC#のコードは全く同じもの。しかしXAMLによるユーザーインターフェイスの記述が異なるため、全く違う見た目になっている。同様にXAMLでWPFを活用することにより、アニメーションを含むリッチなユーザーインターフェイスをデザイナーが自由に作ることが可能となる

●WPFは機器やプラットフォームへの依存も解消

　実際にWindowsでソフトウェア開発を行なっている読者以外は、まだ多少ピンとこない面もあるかもしれないが、C#とXAMLを用いたアプリケーションの構築手法は.NETによる開発そのもの。もちろんスタンドアローンのアプリケーションでも利用可能だが、そのままネットワーク透過となるため、Web上で動作するアプリケーションにもそのまま適用できる。

　またロジックを構成するマネージドコードとXAMLが分離されているため、目的ごとにXAMLの入れ替えるといった使い方も可能だ。例として効率的に情報を管理するプロ向け、エンドユーザー向けのリッチユーザーインターフェイス、リモコンで操作するユーザー向けのMedia Center向けのアプリケーションを、XAMLの入れ替えだけで実現する例が示されたが、XAMLを処理するモジュールがあれば、必ずしも動作するクライアントはWindowsでなくても良い。

XAMLで指定するスタイルを変更することで、用途ごとに同じアプリケーションに異なるユーザーインターフェイスを与えるといった使い方も可能。デバイスへの依存度を下げる事も可能となり、同じコードで携帯電話からパソコンまでを流麗なユーザーインターフェイスでサポート可能になる

　PDCで発表されたWPF/E(Windows Presentation Foundation Everywhere)は、WPFのサブセットとしてXAMLに書かれたWPFへの指示を、Windows Vista/XP以外のプラットフォームで動作するWebブラウザ上で実行するための技術だ。WPF/EはMacOS XやPDA、携帯電話などの上にも実装することを考えているという。最近、MicrosoftがMacromedia Flashの対抗技術を開発していると報道されたのは、実はこのWPF/Eの事だ。

　これは同じロジックを用い、ターゲットとする各デバイスごとにカスタマイズしたXAMLをデバイスに与えることで、デバイスごとに最適化されたユーザーインターフェイスとすることができるわけだ。WPFは解像度への依存がないため、たとえば携帯電話の画面解像度が将来の機種で増えたとしても、ユーザーインターフェイスが期待通りに動作しなくなるといった可能性も排除できる。

　ただし、WPF/Eがどこまで正確な再現性を持つランタイムになるのか、どのタイミングで提供されるのかは現時点ではわからない。おそらくWindows Vistaリリース後、1～2年ぐらいのタイムフレームで徐々に整っていくという話になるだろう。また日本市場だけを考えた場合、Microsoftは携帯電話向けのOSを持っていないため、WPF/Eをどのような形でエンドユーザーに届けるかといった問題もある。

　とはいえ、アプリケーションのデザインという領域まで踏み込む事になるわけで、Adobeとの対決姿勢が米国でことさらに強調され、報道されている理由も理解できるというものだ。MicrosoftとAdobeは、アプローチの方向こそ異なるものの、最終的なゴールは非常に似たものに見える。

　しかも、それはWebアプリケーション開発向けのデザインツールという分野だけではない。WPFやXAMLの話は、実はAdobeが得意とするPDFを用いた電子ペーパーソリューションの分野とも無関係ではないからだ。

●XPS(Metro)がPDFキラーへと通じる“遠そうで近い”道のり

　今年のWinHECでは、WPFの描画オブジェクト定義構造であるビジュアルツリーの構造を、そのまま印刷イメージとしてXMLで記述するMetroという技術が発表された。Metroは正式名でXPS(XML Paper Specification)と名付けられており、当初、Microsoft関係者に話を聞いたところ「あくまでも印刷イメージを記録するため、WPFのデータ構造をそのままXML化したもの」と話し、Adobe PDFの対抗技術である事を否定していた。

　しかし今回のPDCで集まった情報を整理してみると、どう考えてもその道は、PDFが実現しようとしている電子ペーパーソリューションへとつながっている。

　XPSの売りの1つは、WPFと全く同じデータ構造とメソッドを持つため、高度な描画処理を簡潔に記述でき、描画のズレなどもない正確なレンダリングが可能なことだ。しかし、PDFが持っているようなフォーム入力や入力データチェックなどのロジックは記述できない。ポータブルドキュメントとしては利用できるが、アプリケーションの基盤ではないというのが、Microsoftが今年5月の時点でPDFとの違いを話す上で使ったレトリックだった。

　しかし、XAMLの中で定義される描画オブジェクトの構造も、やはりWPFのビジュアルツリーを元にしており、XPSのデータ構造とも同じになっている。もっと簡単に言えば、XAMLの中から描画オブジェクトの構造を記述する部分を抜き出したサブセットがXPSである。これはXPSがちょっとした実装の変更で、簡単にPDFのようなアプリケーションプラットフォームになる事を意味している。

　たとえばOfficeファミリの中に、InfoPathというフォームデザイン兼入力ツールがある。Office 12の段階ではInfoPathの位置づけは現在とは変わらない。しかし、将来のInfoPathがXPSを読み込んで入力フォーム用のフィールド部品を配置し、簡単な処理ロジックを加えてXAML互換の拡張XPSとして保存するツールになったとしたら、XPSはまるまるPDFソリューションを置き換えるポテンシャルを持つ技術になってくる。いや、サーバサイドのミドルウェアの充実度を考えれば、いくらPDFが先行している分野とはいえ、Adobeとしてもかなり苦しい戦いになってくるかもしれない。

●Officeの文書フォーマットがXML化する意味

　“さらに”をもう一度繰り返す話もある。XPSとXAMLの基本構造は、実はOffice 12が採用するXMLベースのオープンな文書フォーマット「Open XML Format」にも引き継がれている。XPSとXAMLとOpen XML Formatのコア部分の構造はすべて同じで、それを異なる方向へと拡張したものだ。拡張子も異なり、たとえば.docは.docxといったファイル名となる。それぞれXMLファイル全体の構造は異なり、当然スキーマも異なるため、同一フォーマットではないがデータの互換性はある。中でもXPSとOpen XML Formatは非常に近い構造だ。

　Microsoftはこれらのファイルから特定項目のデータを取り出したり、書き込んだりといった操作を行なうAPIを提供する。つまりXPSとOpen XML Formatのファイル(つまりOfficeのファイル)を、全く同じロジックで扱えるようになる。

　またOpen XML Formatへの出力は、必ずしもOffice 12を必要としない。Office 12ではOpen XML Formatがデフォルトのファイル形式になるが、過去のOfficeに対してもアドオン機能の形でOpen XML Formatへの出力モジュールが提供されるため、Officeをバージョンアップしなくとも文書のXML化を行なえる。

　Open XML Formatはその名の通りオープンな仕様であるため、これまでのようにファイル互換性を取るために内部を解析する必要もない。Open OfficeなどもOpen XML Format互換を簡単に、しかも高い互換度で実現できるはずだ。画面表示をWPFへと実装し直せば、画面上での表示互換性も高くなる。

　何より、作成した文書が将来にわたって再利用しやすいというのは最大のメリットとなるだろう。たとえば.docファイルで文書を保管しておく場合、将来に渡ってOfficeを使い続け、システムの中でもサポートし続けなければ文書は再利用できない。しかしOpen XML Formatならば、MicrosoftのOfficeによる縛りから解放される。

　一見、Microsoftが圧倒的シェアを誇るOfficeスイートでの利権を手放したようにも見えるが、Microsoftにとってもメリットのある選択肢だったはずだ。独自形式では公的文書の作成ツールとしては敬遠されてしまう。しかし、Open XML Formatならばそのような障害もなくなる。

　加えてアプリケーション開発、画面表示、文書作成、印刷までを一貫した構造のフォーマットで統一し、そのネイティブの処理系としてWindowsがある事の方が遙かに大きな意味を持つからだ。

□PDC2005のホームページ(英文)
http://msdn.microsoft.com/events/pdc/

□バックナンバー

(2005年9月18日)

[Text by 本田雅一]