早くも第2世代に突入する携帯Java

松原敦

2001.04.19

　1月22日付けの本欄に「iモードの世界を抜本から変えるiアプリ」と題する記事を書いた。それから約3カ月，次の順番が回ってきた。折りしもKDDI，J-フォンが相次いでJava戦略を発表した。今回は前回の記事を振り返るとともに，KDDIやJ-フォンのJavaについて考えてみたい。

予想以上に大きかった問題点

　まず前回の記事は，Javaアプリケーションによって，従来のiモードのブラウジングとは世界が大きく変わるといことを主眼にしていた。例えばオフラインで利用できることや，クライアントでインテリジェントな処理ができるようになることである。一方，iアプリの10Kバイトという容量制限や，機種間の互換性の問題に関しては，過渡的なものだという立場を取った。

　そのときの気持ちとしては，マイナス面よりも，どれだけ新しいことができるかに目を向けたかった，ということがある。10Kバイトの小ささに困惑するベンダーがある一方で，その小ささ故に技術力の差が出ると張り切っているベンダーがあることも，筆者の気持ちを後押した。

　今でも基本的には「容量が少ないから，互換性に問題があるからといってiアプリを否定してはいけない」と考えているのは変わらない。一方で，容量と互換性，および他機能との連携の問題が，想像していた以上に重要であることも分かってきた。

　容量に関しては，10Kバイトに多くの機能を詰め込むのは困難であり，Javaアプリケーションとしてのメリットを生かしきれないことが判明した。多くのコンテンツ・プロバイダが，パケット料金が下がること以外のメリットを打ち出しきれないでいる。

　容量に関して取材を進めるうちに，もう一つの問題が浮かび上がってきた。携帯電話の持つ他の機能，ブラウザやメールとの連携ができないことである。アプリケーションの機能が限定されていても，適宜Webブラウザを呼び出すことができれば，相互に補い合って長所を生かすことができる。メールも同様である。

　しかし，現状ではJavaのアプリケーションはそれぞれが完全に隔離された状態で動くため，そういった連携ができない。これがJavaアプリケーションを使ったシステムを作る上で，ある意味，容量以上の大きな機能制限となっている。

　また互換性の問題に関しては，振る舞いの違いだけでなく，速度の差も激しいことが分かってきた。機種回収があったり，4月を表す記述の誤りによるバグが発覚したP503iは，速度面でもコンテンツ・プロバイダの評価が低い。

iアプリの二つの弱点を克服しようとするKDDIとJ-フォン

　先の記事の時点では，他のキャリアの動きは見えていなかった。正直言って，Javaという技術の難しさから見てキャッチアップは難しいのではないかと思っていた。したがって，これらの問題を解決するのもNTTドコモの次世代機種になる可能性が高いと考えていた。しかしKDDIとJ-フォンが予想以上に早く，NTTドコモに追いつき，機能的には追い越すことになった。

　まず，容量制限に関してはKDDIは50Kバイト，J-フォンは30Kバイトだ。iアプリに関してコンテンツ・プロバイダに取材したとき，当初実現したい機能を盛り込んで作ったところ30Kバイト程度になってしまった，という話を数社で聞いた。30Kバイトというのは，いい線だと思う。

　互換性に関しても大きな進歩がある。ここで重要な役割を担っているのがアプリックスである。同社の「microJBlend」と呼ぶ携帯電話用Java仮想マシンは，KDDIとJ-フォンのJava対応携帯電話機すべてに搭載されることになる。KDDIもJ-フォンもこういった措置を取ることで，（1）機種間の互換性の問題を最小限に抑え，（2）携帯電話機メーカーの開発負担を減らすことができたのである。microJBlendはNTTドコモのJava搭載機で最速と言われるSO503iでも採用されており，性能面でも期待できる。

　両キャリアとも米Sun Microsystemsなどが策定したMIDP（Mobile Information Device Profile）をAPIとして採用する。これは歩調を合わせたというより，「標準だから採用した」というのが理由である。

　それでも結果としてMIDPのAPIだけで書かれたアプリケーション（おそらくビジネス向けアプリケーションの多くはMIDPだけで書けるだろう）は，J-フォンでもKDDIでも動作する可能性が高くなった。アプリケーション配布用ファイルの作り方などが異なるため，まったく一つにしてしまうことは不可能だが，プログラム自体は共通化が可能になる。

コミュニケーションのKDDI，マルチメディアのJ-フォン

　MIDP以外のキャリア独自のAPIは，両社の特徴が出ており面白い。なお，KDDIもJ-フォンも携帯電話機メーカによるAPIの拡張は認めていない。これも互換性を重視するためである。

　携帯電話間でチャットをしているKDDIのテレビCMを見たことがある人は多いだろう。このチャットで使っている「Cメール」の「おしゃべりモード」次期版がKDDIのJavaでも目玉になる。JavaアプリケーションからCメールの機能を使えるほか，標準搭載するライブラリ「Jumon」がCメールをプロトコルとして使う。

　Jumonはオムロンが開発したエージェント・プログラム。端末間でプログラムをやり取りしたり，他の端末のプログラムを呼び出すアプリケーションを簡単に作ることができる。例えばアンケートの回覧といったアプリケーションだ。Jumonで他のユーザーにプログラムを送ったりCメール新版でメッセージを送ると，受け取り先で自動的にプログラムが起動できる。

　またKDDIはセキュリティに関しては，他のキャリアより少し冒険をしている。アプリケーションにセキュリティ・レベルを設け，アプリケーションによってはアドレス帳や位置情報（基地局の位置），自身の電話番号やメール・アドレス，氏名といったプライバシの情報を利用できる。これらの機能はKDDIが認証したアプリケーションだけで利用でき，そういったアプリケーションはKDDIが保持するサーバーからダウンロードしなければならない。

　位置情報も利用可能である。当初はアクセスする基地局の位置情報を使うだけだが，2001年秋に開始予定の次期サービスでは「gpsOne」と呼ぶ精度の高い位置情報が利用できる。次期サービスでは，このほかブラウザを呼び出す機能などもサポートする予定である。

　一方，J-フォンの拡張API「JSCL」（J-Phone Specific Class Liblary）は，マルチメディアの機能を重視している。目玉は3次元グラフィックスの機能。キャラクタの視点を自由に変えたり，アニメーションも可能である。バンダイネットワークスなどが開発した3次元描画用のレンダリング・エンジンを搭載することで実現する。

　2次元画像のスプライト表示用のエンジンも載せる。8×8ドットのブロックを最大256個，8フレーム/秒以上の速度で動かす。回転や反転，透過といったスプライト画像の処理も可能である。J-フォンによると，携帯電話メーカには8フレーム/秒以上の描画性能を義務付けているという。

　固定小数点演算や2次元のベクトル演算機能も搭載する。主に画像処理を考慮したものだというが，携帯電話用JavaのベースとなるCLDC（Connected, Limited Device Configuration，NTTドコモを含めたすべてのキャリアがこれを採用している）では整数演算機能しか用意しないため，重宝するだろう。

　さらにJPEGやPNGフォーマットで作成したアニメーション画像とサウンドの演奏を同期することも可能だ。これによって，カラオケのようなコンテンツが開発しやすくなる。KDDIと同様，位置情報も利用できる。現在のJ-スカイの「ステーション」サービスと同様，基地局レベルの位置情報も使える。

　なお，当初はJavaアプリケーションの開発元はJ-フォンの公式コンテンツ・プロバイダに限るという。2001年秋頃と見られる次期サービスで，一般のサイトからのダウンロードを可能にする。その時点でブラウザとの連携もできるようにする。

NTTドコモはどう動くのか

　KDDIやJ-フォンのこういったJava戦略は基本的にはうなづけるものである。NTTドコモから半年遅れずに追いついてきたことも立派である。

　こうなると気になるのがNTTドコモの次の一手である。そもそも10Kバイトの制限は，ユーザーの通信料負担を増やさないというのが最大の理由だった。ユーザーが大容量を望むならば，容量の制限は変わる可能性が高い。

　一方互換性に関しては，開発を携帯電話機ベンダーにまかせるというスタンスを崩していない。さまざまな互換性の問題に関しても，特に調整を行う考えはないとのことだ。これからも，その姿勢を貫くのだろうか。それで自然に互換性の問題が解消されていくのか。携帯電話機メーカの切磋琢磨と，キャリアによる統一とどっちが勝るのか。

　これまでは圧倒的に優勢にあったNTTドコモだが，ことJavaに関しては予断を許さない情勢になってきた。