BREWを使ったプラットフォーム「KCP」とは何か：BREW最新事情

[斎藤健二，ITmedia]

　Qualcommが推進するアプリケーション実行環境「BREW」──そのもう1つの顔が、携帯電話のプラットフォームとしてのものだ。ダウンロードして実行するゲームなどのアプリケーションとは別に、携帯電話にはWebブラウザやメールソフトなどが組み込まれている。「ネイティブアプリケーション」と呼ばれるこれらのアプリケーションを、BREW上に実装する試みが始まっている。

BREWを使ったプラットフォーム　KCP

　KDDIがBREWを使って取り組んだ携帯向けプラットフォーム、それがKCP（KDDI Common Platform）だ。WIN夏モデルとして登場した「W32SA」「W31T」に、まずは組み込まれた（5月25日の記事参照）。KDDIでソフトウェアの企画開発に携わるプロダクト統括部アプリケーショングループリーダーの坂庭宏行次長は、KCPの意図を次のように話す。

　「携帯電話のソフトウェアが大規模化、高度化、複雑化している中で、商品力を上げ、リードタイム（製品化までに時間）を短くし、安くするにはどうしたらいいか。共通化する部分は共通化し、差別化する点はメーカーごとに取り組む。共通化のためのベースがKCPだ」

　携帯電話開発のコストのうち、半分以上はソフトウェアの開発に費やされていると言われる。ソフト開発費を削減する手段の1つが、各端末メーカーでバラバラだったプラットフォームを共通化し、開発を1つに集約することだ。

　KCP上には、共通アプリケーションであるブラウザ、メール、EZナビウォーク、SMIL、Flashなどを実装した（5月25日の記事参照）。こうした共通ソフトウェアの開発には時間をかけず、テレビやラジオ、はたまたデザインなど各社が差別化できる部分に力を注いでほしいという狙いだ。「各端末メーカーは同じことをやるのに力をかけないで、自分ならではのところに力を入れてほしい」（アプリケーショングループの石谷雄一郎課長補佐）

BREW採用の理由

　こうしたソフトプラットフォームの共通化は、KDDIだけが進めているわけではない。ドコモはFOMA端末においてLinuxやSymbian OSを推奨OSとし（2003年12月3日の記事参照）、2005年冬のFOMA端末では全端末がどちらかのOSを採用してくる見込みだ。こうした汎用OSの採用も、開発コストを削減するための工夫だといえる。では、KDDIがBREWをプラットフォームとして使ったのはなぜか。

　もともとはアプリケーションをダウンロードして実行させる、Javaに近い位置づけで始まったBREWだが、「BREW導入の段階から、プラットフォームになり得るものだという認識を持っていた」と坂庭氏は話す。

　「BREWはQualcommのベースバンドチップとの親和性が高い。KDDIが採用しているチップはすべてQualcomm製なので、最適化を図れる」（坂庭氏）

　BREWを採用することで、現実的にはベースバンドチップがQualcomm製に限られるという制限はある。しかしそもそもQualcomm製ベースバンドチップを搭載し、QualcommのREX OS上でソフトウェアを開発してきたKDDI端末の場合、プラットフォームにBREWを使うのは自然な流れだったといえるだろう。

KCPで何が変わるのか

　では、KCPがどのような仕組みで動いているのか簡単に見ていこう。まずBREW3.1をベースに、KDDIが要求するフレームワークを実現するための拡張を施したものがKCPだ。KCP用のインタフェース（API）とKTM（KDDIタスクマネージャ）から、KCPは成り立っている。

Qualcomm製ベースバンドチップ上で、REX OS（Qualcomm提供）が動作し、その上にAMSSライブラリ（旧DMSS）が乗り、OMEレイヤー、そしてBREW3.1が乗るという階層構造となっている。KTMは自身もBREWアプリでできており、アプリケーションの競合管理や連携機能を提供する

　「ネイティブアプリは、ユーザーオリエンテッドの視点から複雑な画面遷移を要求される。これをBREWで実現するのは“素”では難しかった」（石谷氏）ため、いくつかの拡張がなされている。

　例えば、終話キーのハンドリングやアプリケーション間の連携だ。「呼び出してキックするのは簡単だが、戻すのが難しい」（石谷氏）。KCPを使えば“箱を出して、電話帳のデータを入れて戻して”──といったことが簡単に行えるという。KCP対応のEZナビウォークでは、地図から取得した位置情報をアドレス帳に書き込むなどの連携が容易になっているが、これがKCPの効果の一例だ。「普通のOSでは存在しないフレームワークだと思う」（石谷氏）。

画面左はKCP非対応の現行機種「G'zOne TYPE-R」のEZナビウォーク。現在位置の登録メニューが「Myスポット登録」になっている。画面中央はKCP対応の「W31T」の位置登録メニュー。「スポット情報登録」となっており、登録先はMyスポットのほか、アドレス帳も選択できる。つまり、アドレス帳の位置情報欄に直接登録が可能になった

　通常のBREWアプリケーションとKCPアプリケーションでは、タスクの優先順位を変えることもできる。KCP対応端末では、ブラウザやメーラー、バックグラウンド受信モジュールなどのコアアプリケーションはBREWアプリケーションとして作られており、BREWのメモリ空間に展開されたままになっている。BREWのタスクが積み重なった場合、これまでは古いものから強制終了されていたが、KCP対応端末の場合、コアアプリケーションは終了されない仕様になっている。アプリケーション連携を行う場合、どのタスクが生きているかどうかの管理が重要になるわけだが、ここでもKCPの管理機能が生かされている。

　KCPの実装に当たっては、タスク管理の概念も少々変更された。「今こんなタスクが動いています。選んでください──というタスク管理が優れているとは思っていない。選択させてはいけない、中断でも優れているとは思わない」（石谷氏）。ブラウザであれば、終了時の画面へ戻る選択肢を用意する。ゲームならば、終了時のステータスに戻る。こうした思想から、KCP化されたEZナビウォークも、中断ではなく、終了時に開いていたページに戻る「前回ページ」といったボタンを用意したという。

　ちなみにKCP対応になったからといっても、ブラウザなど各種アプリケーションを自由にダウンロードさせて組み合わせて使うのは少々難しいようだ。例えば、EZナビウォークはダウンロードアプリのままKCPに対応した。つまり、ダウンロードしてアップグレードしたり交換が可能な代わり、起動の都度、BREWメモリ空間に展開する必要があるということだ。コアアプリのように組み込まれた形であれば、常にメモリ空間に展開しているため起動（タスク切り替え）は瞬時に行えるが、逆にEZナビウォークは通常のBREWアプリと同様の起動時間がかかる。こうしたアプリケーションの動作のレスポンスを考えると、まだKCPにも改良の余地はある。

2006年には標準搭載に

　現在のところ、2機種に採用されたKCP。今後のスケジュールはどうなっているのか。

　「基本的にはau端末全部に展開していく。今年終わりから来年にかけて、標準搭載となるだろう」（坂庭氏）。au端末は基本的に全端末でQualcomm製チップを搭載しており、BREWも全機種が採用している。ハイエンドからローエンドまで、ハードウェアの追加なく同じプラットフォームに揃えることが可能だ。

　現在のところ、KCPを導入したのは2機種だけだが、「KCP導入端末のメーカーによると、競合、連携機能をKCPで管理するようにしたので、デバッグが効率的にできるようになった」（坂庭氏）という効果が上がっている。もっとも、KCPの真価が問われるのは対応機種が増えてきたときだ。「東芝端末、三洋端末でベースを作った。これをベースに水平展開したときに（KCPの）効果が現れる」（坂庭氏）。