【CEDEC2007レポート】

会場：東京大学

　「CEDEC2007」の2日目となった9月27日、マイクロソフトによるレギュラーセッション「Windows Vista ゲーム開発」が開催された。9月上旬に行なわれた「Gamefest Japan 2007」等、Windows Vista用ゲームをリリースするためのノウハウ伝道に余念のない同社だが、今回は通り一遍の要点説明だけでなく、多くの日本語対応ゲームタイトルで問題になっている「Windows VistaにおけるIME (テキスト変換入力システム) の互換性問題」について詳しく取り扱われた。特にこの問題については率直に「真相をぶっちゃける」という表現がぴったりの、爽快かつタメになる講演内容となったので、本稿ではその詳細をお伝えしたい。

■ Vista対応にあたり多数の日本語入力可能タイトルを悩ませた「IME問題」
　　　実はOSの問題ではなく、原因はDirectX SDKサンプルプログラムのバグ?

Windows Vista対応のための全般的な解説をおこなったマイクロソフトUXエバンジェリストの川西裕幸氏

　本セッションの演台に立ったのは、マイクロソフト株式会社デベロッパー&プラットフォーム統括本部にてUXエバンジェリストを勤める川西裕幸氏と、マイクロソフトからMicrosoft MVP for DirectXを受賞している技術者NyaRuRu氏。

　冒頭、川西氏による「今日の講演は言っておきますが地味です」という紹介があったとおり、例えばDirect3D 10の華麗な映像や、「Games for Windows - LIVE」などの華やかな機能説明はいっさい無し。しかしながら、Windows向けタイトルの開発者にとって、またゲームユーザーにとっても大変重要な情報を含む講演となった。

　今回のセッションがこれまでマイクロソフトが行なってきたWindows Vista関連カンファレンスと大きく異なるのは、各ゲームタイトルのいわばWindows Vista対応の鬼門となってしまった「IME問題」に深く踏み込み、その真相を暴露してしまったことにある。

・長年潜伏し続けたDirectX SDKサンプルのバグ。その実体はたったひとつのフラグ

いわゆる「IME問題」は、日本語入力対応ゲームのWindows Vista対応をつまづかせてきた原因のひとつ。NyaRuRu氏による解説は単純明快に進められた

事件の原因を単刀直入に紹介。会場からも思わず笑いが漏れる、瑣末なミスから全てが始まってしまったようだ

　「IME問題」とは何か。このテーマについては、NyaRuRu氏が深く踏み込んで解説した。本稿で既に何度も登場しているこの単語は、チャットなどの機能で日本語入力を必要とするゲームタイトル (その多くはMMOPRGだろう) のなかで、一部の、あるいは多くのゲームタイトルがWindows Vista上で「IMEがうまく動かない」という問題に直面するか、またはそのうわさを聞いてWindows Vistaを公式のサポートプラットフォームから外してしまったり、マイクロソフトから「Works With Windows Vista」ロゴを取得できなかったりといった現象のことだ。現在もいくつかのタイトルでつまづいているようで、問題としては決して小さくない。

　NyaRuRu氏は、「これはIME関連の処理で困ったことのある開発者ならよくわかる話題です」としつつ、その原因を単刀直入に説明した。主にフルスクリーンで動作するゲームは、チャットなどの日本語入力の際に表示されるMS-IME標準の変換ウィンドウの表示を抑制し、自前で画面スタイルに合った形で描画している。このとき多くのタイトルがIMEに対し、「IMM32」と呼ばれる標準APIを通じて「画面表示をするな」という命令を出す。この部分、多くのタイトルでDirectX SDKに付属しているサンプルコードを参考にしたり、流用 (コピペ) しているのが実体なのだが、実はそのサンプルコードにバグがあった。

　このバグは、サンプルコード中の「未確定文字列や候補ウィンドウを表示させないことを指示するフラグ」についての処理。この部分、実はVista以前のずっと昔から間違ったまま放置されてきていたのだが、NyaRuRu氏によると「これまでのIMM32は、このフラグを親切にも無視し続けていた」ということだ。

　つまり、従来の環境ではプログラムが誤っているのにもかかわらず正常に動作してしまい、誰もバグに気がつかなかった。結局のところ結局のところWindows Vistaに付属するMS-IMEにてIMM32がサポートされなくなるまで問題が顕在化してこなかっただけ、ということらしい。そのVista環境でもサードパーティ製のIMM32をサポートする旧タイプの入力システム (ATOKなど) をインストールしたシステムであれば問題なく動いてしまうので、問題の潜在化に余計拍車をかけてきたというのだから、もう笑うしかない。

　というわけで、ささいなミスがサンプルプログラムの流用と言う名の「コピペ」で広まってしまったこの問題、解決するためにはたった1カ所を修正すればいいという。この処方については完全に開発者向けの情報となってしまうので下記スライドを参照してほしい (ゼロクリアしていたフラグがローカル変数だったという、プログラマには恥ずかしい話だ)。もし、この問題を抱えたタイトルをプレイしているエンドユーザーであれば、従来型のIMEをインストールすれば対処できるそうなので試してみよう。

問題の原因と解決の方法。数年来潜伏してきた重大なバグは、たった1カ所修正するだけで問題なく動くという、トホホなものだった
会場のPCで実際にサンプルをビルドして実行。IME 2007を使い実際に問題なく動作する様子がデモされた	この問題で得た教訓の中でも、「何かあるとOSのせいになる」のくだりは、会場にも笑いが起こった	新タイプの「TSF」に対応した8月版のDX SDKでは、IMM関連で新たなバグが誕生したため、現在は7月版を修正して使うとよい、とのこと

・旧タイプIMEのAPI「IMM32」はエミュレーションのみのサポートに
　　　新旧の混乱を避けるため新タイプの日本語変換入力システムは「TIP」という呼称に

「TSF」の存在意義についてもフォローしておこう。音声入力や手書き認識などを統合し拡張性が高く、今後は主流になっていくとのことだ

Windows Vistaでは、IMM32はエミュレーションでサポート。かなりややこしいことになっている

　NyaRuRu氏の解説によると、Windows Vistaでデフォルト機能となった「Text Services Framework (TSF)」は、従来のIMEで使われていたIMM32を置き換えるものだ。このTSFは実はWindows 2000時代から存在しており、COMベースの「安全なプログラミング基準」を実現し、従来のキーボード入力に加えて音声認識や手書き入力機能を統合する機能を備えている。

　「TSF」はWindows XPにおいても「詳細なテキストサービスを無効にする」オプションをチェックしないでおけばアクティブになり、「詳細なテキストサービスをすべてのプログラムに拡張する」オプションをチェックすることですべてのアプリケーションに適用される。このとき、IMM32にしか対応していないアプリケーションに対し、「TSF」は、「CUAS」と呼ばれるエミュレーションレイヤを通じて制御されるようになる。

　NyaRuRu氏によるとこのときの挙動がまた曲者で、「TSFを使うとアプリが怪しい挙動をすることがあるのは『Visual Studio』のトラブルーシューティングなどで通例になっていた」などという認識だ。原因は「当時のエミュレーションはずいぶんとバグが多かったため」とした。下に掲げたスライドに示したように、「CUAS」によるエミュレーション構造は非常に複雑。このため、これが登場したWindows XP SP1の時代にはトラブルも多かったようだ。

　このように長いデビュー期間を通じてやっかいもの扱いされてきた感のある「TSF」も、Windows Vistaに搭載されたMS-IMEがIMM32のサポートをやめたことでついにデフォルトとなった。これに伴い、すべての旧タイプのアプリケーションに対しては「TSF」が「CUAS」を通じてIMM32をエミュレーションするという形で対応することになったわけだ。このエミュレーターがIMM32の仕様をあまりにも忠実に実行するため、上記の「IME問題」が顕在化したのは前述の通りである。

　テキスト入力サービスの多様化により、キーボード入力しかサポートしないIMEから「TSF」への流れはすでに確定的だとのことなので、今後、日本語入力機能を必要とするゲームを製作する開発者においては「TSF」の作法に対応したプログラミングを導入してほしい、とはUXエバンジェリスト川西氏の発言だ。

　NyaRuRu氏に言わせれば「身も蓋もない感じ」の内容となったIME関連の話題だが、Windows Vistaを公式にサポートしようとしてこの問題でつまづいた開発者にとっては非常に重要な情報となるだろう。エンドユーザーにも利益となるはずだ。これを機にVista対応に拍車がかかることを期待したい。

「TSF」が有効な状態では、非対応のアプリケーションは「CUAS」と呼ばれるレイヤーを通じて動作する	Windows XPでは画像上のチェックを外すことで「CUAS」を無効化できるが、Windows Vistaでは標準となり、常時使用になった	だからといって「TSF」専用のアプリを作れば、今度はサードパーティ製IMEで問題が。道は険しい

■ 「Works on Windows Vista」、「Certified for Windows Vista」各種のロゴ獲得のため
　　　ゲームデベロッパーが最低限チェックしておくべきポイントを紹介

　NyaRuRu氏がIME関連の話題を終えると川西氏が再登場し、「Windows Vista対応を謳うために準拠してほしい機能」について説明がなされた。これはマイクロソフトが各カンファレンスで再三訴えている部分であり、また、あまりにも開発者向けすぎるため、本稿ではそのポイントを1点紹介するにとどめよう。

・Windows Vista準拠のためには、まずユーザーアカウント制御(UAC)への対応に尽きる

Windows Vista対応タイトルのためのガイドライン。いろいろあるが、特に商用アプリにはユーザーアカウントコントロールへの配慮が必須

　マイクロソフトはWindows PC向けに発売されるタイトルに対し、その準拠具合によって数バージョンの承認ロゴ提供をおこなっている。ひとつは「Works With Windows Vista」で、これはWindows Vistaのx86版にて一通りの機能が不具合無く動作するのであれば問題ない。上記のIME問題を解決すれば、おおむね対応可能なタイトルは数多くあることだろう。

　川西氏がさらに「顧客に安心を提供」するというのは、「Certified for Windows Vista」ロゴ。これはWindows Vista環境との互換性、セキュリティ機構への対応、インストーラの動作、信頼性などがテストされるという本格的な承認プロセスを必要とするものだ。現行のWindows XP用タイトルは、特にセキュリティの面でWindows Vistaに対応していないものが多いようだ。

Windows Vistaユーザーならおなじみの確認ウィンドウ。UACに配慮していないアプリを使うと毎回これが出てしまう

　その本質はWindows Vistaの「ユーザーアカウント制御(UAC)」への対応だ。使用したことのあるユーザーならすぐに思い当たることと思うが、Windows Vistaはプログラムが特定の動作をしようとした場合に、プログラムの実行レベルを「昇格」させるための確認ダイアログがユーザーに対して必ず提示されるようになっている。その動作とは、例えばCドライブのルートディレクトリなどユーザーデータ以外のフォルダへの書き込みや、特定の場所以外へのレジストリ書き込みなどである。

　Windows XP以前のタイトルでは、プログラムがインストールされたフォルダに設定ファイルなどを残し、実行のたびに書き込み操作を行なうようなものが多い。Windows Vistaではこの種の動作にも実行レベルの昇格を必要とし、ユーザーの許可を求める仕組みになっている。つまりゲームのインストーラーひとつとって見ても、プログラムの書き込み、レジストリへの登録といった動作で複数回の確認ダイアログが表示されてしまうわけだ。このようなプログラムは「Certified for Windows Vista」ロゴを取得できない。

　ユーザーアカウント制御に準拠するためには、昇格確認ダイアログの表示を最小限にとどめなければならない。そのため書き込みを行なう場所をユーザーデータディレクトリに限定したり、レジストリ書き込みも特定の場所に限定するなど、作法に準拠する必要がある。また、昇格が必要なプログラムでは、バイナリに動作権限を明示する「manifest」データを埋め込み、同時にデジタル著名を埋め込んでマイクロソフトからの承認を受ける必要がある、ということだ。なかなかやっかいだが、セキュリティ保全に万全を尽くしたWindows Vistaに完全対応するための「通過儀礼」として、商用ゲームのデベロッパーは意識していく必要があることだろう。

UAC対応のための各種ポイント。特にプログラムからUACを無効にすることは硬く禁じられている。「Certified for Windows Vista」ロゴを取得するためにはこれらのガイドラインを遵守する必要があるので、商用ゲームの開発者は関連資料をあたって充分な準備をしよう
Windows Vista SP1と同時に導入されるとされるDirect3D 10.1について。本セッションでは軽く触れるだけにとどまった

□マイクロソフトのホームページ
http://www.microsoft.com/japan/
□「CEDEC 2007」の公式ページ
http://cedec.cesa.or.jp/

(2007年9月27日)

[Reported by 佐藤“KAF”耕司]