携帯電話上で走らせるJavaプログラムは，サイズが小さいことが第一の条件である．しかし，Javaは元々PCなど比較的リソース制限が緩いコンピュータ上で走らせることを想定していたため，小さいプログラムを書くには特殊なテクニックが必要となる．つまり，一般のプログラマには敷居が高すぎ，このままでは携帯電話のJavaコンテンツの発展を阻害する恐れがある．
そこで，携帯電話上で動作するプログラムを開発するためのコンパイラなどの開発を提案する．このコンパイラが生成するプログラムは，同機能を持つ携帯電話上の通常のJavaプログラムの1/10以下のサイズ (目標値) であり，現状の携帯電話網においても無理なくダウンロードすることができる．
ただし，提案する方式では，実行時にオーバヘッドがあり，通常のJavaプログラムに比べ平均で30パーセント程度の実行速度の低下 (目標値) が予想される．今後の携帯電話の性能向上と，携帯電話網の帯域の向上を比較すれば，前者の伸びが大きいことは明らかであり，実行速度を多少犠牲にしてもサイズを小さくすることが重要であると判断した．
本提案コンパイラが扱うソースプログラムはJava言語との互換性を保持し，一般のプログラマが容易に開発できるようにするとともに，通常のJavaプログラムからの移植が容易になることを目指す．
リソースが厳しく制限された携帯電話の上で，いろいろなJavaアプレットを動かすことは困難である．Java(-like)な言語で書かれたソースを携帯電話上で走る無駄のないバイトコードにコンパイルし，一般的なJavaコンパイルに比して，アプレットの大きさを1/10程度に削減するコンパイラを開発することが本提案である．学術的な先進性はともかく，きわめて現実的で，即時のビジネス展開が図れるテーマである．提案技術の内容と，開発メンバーの能力から見て実現性も高いと判断した．このテーマは特にタイムリネスが必要であり，この事業でのタイムリーな助成には意義がある．
本提案は当初予算計画が粗すぎたが，意見交換によって大幅にスリム化してもらっている．
メモリ，通信速度とも厳しく制限された携帯電話の上で，Javaアプレットとほぼ同等なものを動かすためのシステムを開発した．
(1) Java VMから携帯電話アプリケーションに不要な機能を取り除き，1バイト当たりの情報量が大きいkamiyaバイトコートを設計し，それを動かすKamiya VMを作成した．
(2) Javaのサブセット (import文がサポートされていない) からKamiyaバイトコードへコンパイルするKamiyaコンパイラ，また中間言語としてKamiyaアセンブラを作成した．
(3) PC上のJava 2 SE上で動くKamiya VMシミュレータを開発した。このKamiya VMの上で動くアプリとして地図ブラウザのデモを作成した。Kamiyaコンパイラが生成したKamiyaバイトコードのサイズは493バイトである。このバイトコードがKamiya VMの上で動くことを確認した．
技術的な詳細は以下の通り．
Javaの実行ファイル形式であるJavaクラスファイルは，プログラム中で使用される文字列定数，数値定数などの通常の定数値の他に，クラス名，メソッド名，フィールド名などの文字列を含み，プログラム本体であるバイトコードのサイズよりもかなり大きくなる．これはJavaのダイナミックリンク機構において，実行時の名前解決を行なうためである．
ところが，携帯電話上でJavaプログラムを走らせる場合，ダイナミックリンク機構は提供されないし，使われないのが通常である．だとすれば，ダイナミックリンクではなく静的リンク方式を採用すれば，実行ファイルのサイズを大幅に削減することができる．このプロジェクトでは，Javaクラスファイル形式の代わりに独自の実行ファイル形式，すなわちKamiyaクラスファイルを設計した．Kamiyaクラスファイルは，複数のクラスを静的にリンクした形式である．
Javaクラスファイル形式との互換性を放棄したことにより，Javaバイトコードとの互換性も不要となる．そこで，バイトコードについても新たに命令セットを構築し，サイズ縮小を試みた．このバイトコード仕様がKamiyaバイトコードである．
Kamiyaバイトコードは，VMに四つのモードがあり，各モード毎に異なる命令セットを持つことにある．したがって命令セット空間が4倍になり，オペランドの一部を命令バイトに組み入れることが可能となる．例えば，頻出命令である分岐命令では−96 〜−1のオペランドを，即値命令では−16 〜 47のオペランドを1バイト命令で指定できるようになった．
以上の方法により，KamiyaクラスファイルはJavaクラスファイルの1/5〜1/10程度のサイズで，同等機能を実現することが可能となった．
現時点では，プログラム可能な携帯電話としては，NTTドコモの503iシリーズが唯一利用可能なので，Kamiya VMは503i上で動作することを目指した．まずPC上のJava 2 SE上にシミュレータを開発し，これを503iシリーズへ移植した．これはJava VM上で動くVMなので，実行速度は目標とした速度よりかなり遅くなる．そこでランタイム・ライブラリを充実させ，実行時間の多くをライブラリコードだけで実行できるようにしてできるだけ速度低下を回避した．
作成した地図ブラウザ (写真) はKamiyaクラスファイルのサイズが設計通りコンパクトなものになったことを検証し，Kamiya VMの今後の展開について検討する材料とするためのものである．ベクタ地図を読み込み，移動，回転，拡大縮小を行なうことができる．Kamiyaバイトコードのサイズはわずか493バイトである．
当初，バイトコード1/10以下という目標の達成は難しいかと思われたが，作り込みの成果が上がり，目標を達成することができた．33歳の仙石さんも，現役の大学院生のままこの世界に踏み込んだ春山さん，菅原さんもしかりだが，不眠不休でプログラミングできる馬力のなせる技であろう．
携帯電話をめぐる状況はドッグイヤーどころかマウスイヤーと思われるくらいに変化が速い．そんな中で，リソースが極端に制限された条件でのJavaバイトコードの問題点を素早く見切り，新バイトコードの設計から始めて，VMとコンパイラの実装，実機でのデモまでをこの短期間にやってのけた手腕は並み大抵のものではない．特にバイトコードを設計し直してしまったという挑戦的な踏み込みは高く評価したい．
それにしても，現地ヒアリングのときに聞いた携帯電話上のJavaリソース制限の技術的あるいは政策的な厳しさ (例えば，一つのiアプリのコードは10Kバイト以下に抑えないといけない) は，マウスイヤーの今日どれくらいの期間意味をもつのだろうか．このプロジェクトはこういったことに若干振り回されてしまったような印象もあるが，得られたKamiyaシリーズの技術自体は，携帯電話のモデルチェンジ周期より長い生命をもつであろう．特にダイナミックリンクが要らないという見切りは典型的なアプリケーションに対してある程度の汎用性があると思われる．
現在のDocomoのiアプリの10Kバイトというリソース制限では，Kamiya VM自体がその10Kの大半を消費してしまう．これではまだ人々を感激させるようなデモができないだろう．しばし我慢の子で，いつでも飛び出せる準備をしておくのがよいだろう．
開発者自身が述べておられるが，
(1) グラフィックAPIを充実させ，携帯電話用のプラットフォームとして耐え得るものにしないといけない．これもリソース制限の緩和次第である．
(2) 上のグラフィックAPIに相応するGUIの優れたオーサリングツールをつくる必要がある．開発の仲間を増やすために重要である．
(3) 上述の地図ブラウザのデモでは，iモード対応Javaの上にKamiya VMを実装した，インタプリタの上にインタプリタという2段構成になっているため性能が出ない．適当なハードウェアプラットフォーム上でのネイティブコード実装を行ないたい．
(4) 今後もメジャーな位置を保持するであろうブラウザとKamiya VMを連係させて，利用性を上げることが必要である．
という技術的目標の追求は今後の課題であろう．しかし，上記の(3)のような目標はビジネス展開を込みにした戦略で携帯電話会社と手を組まなければ意味がない．こういう話はタマゴが先か，ニワトリが先かということになりがちだが，とりあえずこのプロジェクトでタマゴは産めた．今後，携帯電話会社に対して戦略的なアプローチを支援組織とともに進めていくことを強く進言したい．特に携帯電話の通信帯域リソースを大幅に拡大するIMT-2000の導入が迫っている現在，それを睨んだ展開を考慮しないといけない．むしろ極度の節約とは違う視点，例えば上記の課題の必要性が増すだろう．
また，グラフィックAPIの開発を省エネで重点的に行なうために，携帯電話のアプリケーションでどんなものが受けそうかといったマーケティングも欠かせない．あの画面こそ，当面最も強いリソース制限だからである．
[1] 未踏性 B+ 競争の激しい分野であるが，独自性はある
[2] 発展性 A- タイミングを失っしないことが重要
[3] 完成度 A- とりあえず実機で動いたが，ほかの人が使えるようになるまでは…
[4] 生産性 A 予想以上の馬力が出ていた
[5] 戦略性 A- もともとベンチャー企業の発想で開発が進められた
[6] 意外性 B+ 1/10の目標の達成は立派，速度はその犠牲になったが