迷走する KDDI のアプリ戦略

コメントを残す

はじめに

KDDI と沖縄セルラーは、10 月 10 日付で au 携帯電話において Java で作成されたオープンアプリがご利用可能に というニュースリリースを掲載しました。これによれば、同社が採用している BREW プラットフォーム対応機種においても、来春以降発売機種で Java で作成されたアプリケーションが実行可能になるものが発売されるというものです。この Java によるアプリケーションを「オープンアプリ」と呼んでいる辺りに微妙さが現れていると思えてしまいます。

au の Java

KDDI と沖縄セルラーが au サービス向けの携帯電話に Java を搭載するのは今回が初めてではありません。BREW の採用以前から Java を搭載しており、当時はこれが公式で唯一のアプリケーション実行環境であり、当時のサービス名は「ezplus」でした。その後、BREW の採用を経て名称の変更が行われ、「EZ アプリ (Java)」になりました。ちなみに BREW は「EZ アプリ (BREW)」です。これは後々 Java を廃止するということの布石でした（EZ アプリという名称への統合により、Java の廃止を目立たないようにするマーケティング上の努力と思われます）。

au 向け携帯電話で最後の Java 搭載となったのが、WIN 向けでは 2003 年 12 月 20 日発売の W11K、CDMA 1X 向けでは 2004 年 6 月 30 日発売の A5406CA です（いずれも関東地方での発売日です。A5407CA という機種もありますが、関東では A5406CA の方が後からの発売となっていたようです）。携帯電話の更新サイクルから考えるとすでにかなり古い機種であるといえるでしょう。

au が Java をやめた理由

KDDI と沖縄セルラーが QUALCOMM が推進する BREW 一本にアプリケーションの実行環境を絞ったことに関しては、Impress Watch による BREW関係者インタビュー KDDI竹之内氏、「1000シリーズもBREW対応に」 – ケータイWatch が詳しいのですが、要するに、

  • BREWに絞ることで携帯電話のコストが下がる
  • 一般サイトからアプリケーションをダウンロードするのはニッチでしかないため切り捨てても問題ない
  • ウィルス的な心配があるため一般サイトのアプリケーションを締め出しても問題ない

というようなことを語っています（そこまでストレートにいっていない部分もありますが、実質的にそういうことを言っておられます）。そしてこのページ中で、

  • インタビュア：BREW 対応端末では Java が使えませんが、Java の VM を BREW で提供するとか、そういう展開はありえるんでしょうか？
  • KDDI 竹之内氏：まあ、ありえなくもないですが、たぶんやらないと思います。（以下略）

と発言しています。BREW 一本に統一し、Java は BREW アプリとしても提供しないというのが当時の KDDI の方針であったわけです。

ただ、Java アプリケーションの需要が少なかったというのには疑問があります。というのも、私はリニューアル前のこのサイトにおいて、EZアプリ(Java) のダウンロードを手助けするサービス（今風に言うなら ASP：EZアプリ(Java) の配布をするのはそれなりに手間のかかることだったのですが、それを単純な HTML の記載だけでダウンロードできるような仕組み）を提供していました。ゴールデンタイムになるとサイトが落ちそうになるほど（というか、数回落ちました）アクセスが殺到していました。このことを考えるとどうも納得しにくいものがあったりします。

KDDI Java の歴史

ezplus および EZアプリ(Java) と呼ばれていた Java アプリケーションの仕様を一般に「KDDI Java」といいます。この KDDI Java 仕様は、Java 実行環境として CLDC(Connected, Limited Device Configuration)-1.0 、プロファイルに MIDP(Mobile Information Device Profile)-1.0 と 独自の KDDIP(KDDI Profile) を採用していました。

仕様は４種類あり、それぞれ Phase-1 、 Phase-2 、 Phase-2.5 、 Phase-3 といいます。初期の Phase-1 では HTTP によるネットワークアクセスができないという制限がありましたが、Phase-2 ではこの制限が解除され、その他に多少の携帯電話制御 API とネイティブアプリケーション連携機能が追加されました。Phase-2.5 では効果音の再生や待ち受けアプリケーション対応などの機能が追加されました。そして、最後の仕様となる Phase-3 ではカメラ制御、3D ポリゴンの描画、2D スプライト描画機能など、当時の他社 Java アプリケーションで一般的となっていて出遅れていた機能を一気に取り込む意欲的な仕様でした。

オープンアプリの Java

新たに来春より搭載が開始される予定のオープンアプリによる Java は上記の KDDI Java の系譜には属しません。KDDI 独自の機能を提供するために搭載されていた KDDIP は存在せず、上記の各種特殊機能は一切提供されません。

オープンアプリで搭載される Java 実行環境は CLDC-1.1 、プロファイルは MIDP-2.0 です。KDDI Java と比較して、CLDC のバージョンが 1.0 から 1.1 に上がり、単精度浮動小数点演算やリファレンスの一部が提供されます。MIDP のバージョンも 1.0 から 2.0 にあがり、ゲーム向けの機能や認証関連機能、音に関連する機能などが追加され、一部の定型的な記述を迂回するための拡張（変更可能なイメージを UI コンポーネントの表示対象として設定することができず、必要であれば変更可能なイメージから変更不能なイメージを生成し、それを UI コンポーネントの表示対象として設定するしかできなかったのを、自動的に変更可能なイメージから表示のためのスナップショットを作成して取り込む機能など）も盛り込まれました。

Java の採用圧力

10 月 24 日から開始される番号ポータビリティ制度（この制度名もどうかと思いますが……）によって、他キャリア（主に NTT ドコモ）において一般サイトでアプリケーションをダウンロードして使用するということに慣れたユーザーを取り込むために、一般サイトに開放することのできるアプリケーション実行環境 ＝ BREW ではない ＝ つまり Java を採用するというマーケティング上の圧力が強まったのでしょう。KDDI および沖縄セルラーは、マーケティング上の理由で切り捨てた Java を再度採用するという決定をしたことになります。

まとめ

当時、Java アプリケーションを au 向けケータイ電話に対して提供していた作者たちは、KDDI に対して少なからず遺恨を抱いている者もいるでしょう。迷走した KDDI と沖縄セルラーによる Java 戦略に翻弄され、帰ってきた au 向けの Java 実行環境を複雑な思いで見ている人もそれなりにいるのではないでしょうか。そして、その迷走はまだ止まっていないかもしれないという不安を拭い去れないものがあります。

とはいえ、Java によって自由にアプリケーションを書いて配布できる環境が増えること自体は歓迎したいところです。私は応援していきたいと思います。また、NTT ドコモによるｉアプリ仕様が事実上の標準となっている日本において、これだけ MIDP をサポートした機器（今回の au 向けに限らず、ソフトバンク モバイル、ウィルコム向けなど）が出現してきたことは大きな変革です。これがどのような方向性をもたらしてくるのかも興味深いところです。

とりあえず、私は途中となっている MIDP-2.0 ドキュメントの作成をした方がよさそうですね(^^; それなりに進んでいますので、いずれ公開できると思います。MIDP-2.0 環境では MIDP-1.0 環境のアプリケーションも概ね動くので、MIDP-1.0 の API リファレンスもそれなりに参考になると思います……。

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です