いまや、携帯コンテンツにおいても、インタラクティブな処理や、画像の表示や音楽データの再生などは特別なものではなくなっている。インタラクティブな処理に不可欠な入力フォームは、WAP 2.0では大きく様変わりをした。また、マルチメディア拡張部分についても、使い勝手では大きく変わっている。

　最終回となる今回は、その入力フォームとマルチメディア拡張部分についてまとめてみる。ただし、マルチメディア拡張部分は、WAP 2.0の機能というよりは、WAP 2.0対応KDDI独自拡張機能ということは、理解しておいてほしい。

　WAP 1.3からWAP 2.0に移行して大きく変わった点は、入力フォームまわりだ。それまでのカードとデッキという概念から、HTMLライクな入力インターフェイスへと移行した。携帯端末向けのユーザビリティという観点からは、HTMLライクな入力フォームがカード＆デッキよりも優れているとは一概にいえないが、デファクトスタンダードに従う形となった。それに伴い、ローカル変数などの便利な機能がいくつか廃止されてしまった。開発者はその部分に注意する必要があるが、それ以外の部分では、基本的にHTMLやiモード向けHTMLとほとんど仕様が共通化されており、コンテンツ開発がスムーズになった。

　送信方式としては、GETメソッド、POSTメソッドのどちらも使用できる。従来指摘されていた「GETメソッド使用による同一URL誤認識問題」は解消されているようだ。

　WMLにおける<input>タグ、HDMLにおける<entry>タグと同等のタグ。HTMLの<input>タグと使用方法は変わらない。「type=""」で入力フォーム形式を指定し、それに対応した属性をその後に記述する。

　従来HDMLでは扱いが難しかった「type="hidden"」「type="checkbox"」が、特に制限もなく使用できるようになっている。

　また、HDMLで使用できた入力フォーマット指定「format=""」がそのまま使用できるようにも配慮されている。一方で、iモード用HTMLの入力フォーマット指定の拡張属性である「istyle=""」を指定することも可能だ。

　そのほか、特殊な属性としては、「type="passwd"」のときに最大入力数が指定できる「maxlength=""」、入力フォームが空値で送信できる「emptyok=""」（デフォルト値はtrueで空値でも送信できる）などがある。

　HTMLによる使用方法と基本的に変わりない。ただし<input>の項でも述べた「format=""」によって入力される文字の指定を別途行うことが可能。

◇

　このほか、<label>（入力フォームとページ内のオブジェクトを関連付けるタグ）や<optgroup>（<option>の上位タグで、オプション自体をまとめる意味付けを行う）などがある。ただし、使用する場面はほとんどないと思われる。

　文字以外に、画像や音声などのマルチメディアデータを添付して、表示・再生などの処理を行わせることができる。従来はデバイスレイヤなどを複雑に使いこなす必要があったが、タグの記述で利用できるようになり、利便性が大幅に向上した。

　HTMLの<img>タグとまったく同様。ただしモバイル向けの場合、リンクを張ったときには「border="1"」にして、利用者にリンクを張っている画像であることを告知するのが暗黙の了解となっている。ピクチャー広告（通常のWebでいうバナー広告のこと。モバイルではこのように呼ぶことが多い）などの扱いに気を付けたい。

　KDDIのWAP 2.0対応端末で使用できるイメージ画像は、GIF、JPEG、PNG、BMPの4つの形式。

　KDDIの独自拡張属性として「copyright=""」がある。「yes」にすると添付データの著作権保護設定が働き、ダウンロードした画像を端末上に保存ができない、転送ができないなどのコピーガード機能が働く（デフォルト値は「no」）。

　なお<img>タグで、画像以外の着信メロディデータなどを指定すると、対応端末によっては、ダウンロード後メロディ再生ができるものもある（<bgsound>タグと同機能だが、<bgsound>タグでは繰り返し回数が指定できるので、そちらを使った方がいいだろう）。添付データとして音源データを再生する場合は、コンパクトMIDI形式（.mid）、13K QCELP形式（.qcp）、SMAF形式（.mmf）の3つの形式に対応している。詳しいデータ形式の紹介や作成方法は、従来は著作権管理などの理由から公式コンテンツプロバイダのみに情報が提供されていたが、現在は、KDDI自らが公式情報として公開に踏み切っている。

　これまでのHDMLやWAP 1.2対応ページでは、着信メロディ、カラオケデータ、ezplusなどのアプリケーションデータは、デバイスレイヤという特殊なネットワークプロトコルをCGI（ダウンロードCGI）から制御し、直接端末の保存領域にダウンロードさせていた。そのため、このCGIの取り扱いが、このようなコンテンツを開発するための高いハードルとなっていた。

　WAP 2.0からは<object>タグの記述により、マルチメディアデータのやりとりが定義できるようになった。これにより、ダウンロードCGIのような複雑な仕組みは必要なくなり、作成プロセスが大幅に簡略化された。

　<object>タグで、ダウンロードデータ自体の定義を行い、必要に応じて、<param>タグで追加定義すると考えればよい（例えば、「standby=""」で、ダウンロードデータの再生時に画面に表示する文字を指定できる）。

　なおデータタイプに関するMIME形式の指定方法は、EZweb on the streetの技術情報「ダウンロードCGI」が参考になる。動画データ形式・拡張子に関しては上記の例をそのまま使用すればよい。RealAudioなどの「インターネット標準」データからの変換方法などについても、EZweb on the streetの技術情報「ezmovie」から情報を確認できる（動画データをezmovie形式（拡張子.amc）に変換するソフト「ezmovieコンバータLite」も配布中だ）。

　なお、本連載は、あくまでWAP 2.0に焦点を絞っており、マルチメディアデータの作成方法などについての解説は割愛する。

　EZwebにはダウンロードとは逆に端末情報をサーバに送信して機能させるアプリケーションも存在する。「GPSケータイはじまる」のCMでおなじみの「簡易位置情報」がそれにあたる。ただし、この機能については、WAP 2.0の仕様とは直接関連性はないので混乱しないようにしたい。

　この機能は、端末のデバイスレイヤを使用している。いくつかキラーコンテンツの候補なるものが登場してきているようだが（例えば「Lycosあしあと日記」など）、位置情報の同期の取り方がいまだにHTTPを経由して行われている関係上、カーナビゲーションのようなGPSを期待するのは現時点では時期尚早だろう。

　なお、簡易位置情報機能を強化したgpsOne機能に関しては、現段階では一般にその使用方法が公開されていない。

■合理的な開発方法

　本連載の第1回でも触れたが、これまで見てきたWAP 2.0という新しい仕様に対応したコンテンツの実際の開発方法について最後に考えてみたい。コンテンツ開発に不可欠なエミュレータに関しては、従来どおり、Openwave Systems社の開発者向けサイトからダウンロードできる。この開発ツールは、以前のWMLやHDML向けの開発ツールとは一線を画すほど多機能だが、その半面、動作が重いのが難点だ。基本的なテストはこのエミュレータを利用すれば、事足りるだろう。またアイコン画像などを使用しないのであれば、特に通常のWebブラウザでも構わない。

　これまでもたびたび説明してきたが、WAP 2.0は、WAP、XHTML Basicという名をかたりながらも事実上はHTMLであり、HTMLベースで開発を進めることこそが最も効率的だ。HTMLベースでコンテンツを開発し、WAP 2.0向けに拡張タグ、拡張属性を別途追加して開発を進める、というスキームで進められれば、特に問題はない。実際iモード向けに作ったサイトをそのままEZweb向けに公開してしまっても、特に問題はないのが現実だ。KDDIでは、WAP 2.0といいながらも、iモード互換にこだわったいくつもの拡張仕様を実装しているのだ。

　逆にいえば、iモード向けサイトのオーナーや事業者は、いますぐにでもWAP 2.0対応化を完了させ、コンテンツ提供を始めることができるのだ。

■今後の課題

　スタイルシートを使用したモバイルサイト作成の試みがどこまで進化するのか、まだコンテンツ作成者サイドでは手探り状態だ。スタイルシートを利用する価値は、コンテンツ提供側からみれば「インターフェイス定義部分の共通化・簡略化の実現」、利用者サイドからみれば「記述方式の簡略化による省パケット、より限られた記述での豊かな表現力の実現」ということになってくると思う。この部分を徹底し、スタイルシートを必要以上に使い、逆に使い勝手が悪くなるような失敗に陥らないことを期待したい。すでにモバイルコンテンツ市場は、発展期というよりはむしろ成熟期を迎えている。いかに先進的な技術でユーザーを魅了するかということよりも、いかに軽快で使いやすく、面白く、利用者の満足度の高いコンテンツが何か、ということを明確にしていくことが肝要だ。そうでないとWAP 2.0というプラットフォームならではのキラーコンテンツと呼ばれるものが登場することはますます難しくなってしまうことだろう。

　また、従来はコンテンツの記述やコンテンツを支える根幹自体に多くのリソースが割かれるという時代が続いてきたが、これからは、その上に載せるデータや本当の意味での「コンテンツ」自体に注力することに焦点が移行していくだろう。記述言語の壁みたいなことが昔話として語られるぐらい、開発者が記述言語を意識しないようになることこそが、今後のモバイルコンテンツのあるべき姿であるように思う。そうした意味でiモード、そしてWAPもすべて取り込んでしまったKDDIの次世代サービスには期待する面も大きい。

　また次の焦点としては、クライアントサイドスクリプト、すなわちPCでいうJavaScriptに相当するものの実装と、連携したコンテンツおよびMacromedia FlashなどのWeb上でのデファクトスタンダードであるデータ形式への携帯端末上での対応が挙げられる。

　Openwave Systems社から提供されている開発者向けツールには、JavaScriptに相当するECMAScriptのテンプレート作成機能も搭載されているので、興味のある方は試してみてはどうだろうか。

　これまでXHTML Basicを中心として、WAP 2.0のコンテンツ記述を追いかけてきた。WAP 2.0といっても、実質的にはほとんどHTMLと変わらない現実にやや戸惑いもあったが、この連載を通じて少しでも多くの人がWAP 2.0というプラットフォームに慣れ親しみ、コンテンツ開発に励まれることを期待してやまない。

　iモード向けサイトの場合もそうだったが、現在コンテンツを引っ張っているのはやはりASPサービスだ。ホームページ作成サービスなどが早急にWAP 2.0に完全対応して、利用者がアクセスできるようになることを期待して締めくくりたい。またそうしたコンテンツやミドルウェアのようなものこそが、現時点での最大のキラーコンテンツになり得るものと思う。

「連載 XHTMLで変わるモバイルコンテンツの世界」