ITmedia NEWS
業界動向
元・Java専門記者がLog4j 2脆弱性に見た「複雑性と魔神のかけら」　Javaの歴史とバザールの矛盾

元・Java専門記者がLog4j 2脆弱性に見た「複雑性と魔神のかけら」　Javaの歴史とバザールの矛盾（6/6 ページ）

公開 2022年01月31日 11時17分

更新 2022年01月31日 21時29分

著者

星暁雄

[ITmedia]

印刷する Googleで優先するソースとして追加

ビル・ジョイ肝いりのプロジェクト「Jini」は不発に終わる

　Javaアプレットよりもはるかに意欲的な分散コンピューティングの試みが、1998年に発表されたビル・ジョイ肝いりのプロジェクト「Jini」だ。Jiniは「ジーニー」、魔神を意味する。Javaオブジェクトをリモートで呼び出して動的に結合する機能に基づき構築された、汎用的な分散オブジェクト環境だった。

　Jiniのデモンストレーションでは、例えばプリンタドライバに相当するオブジェクトを遠隔で呼び出し、動的に結合して機能できるようにし、任意のプリンタにプラグ＆プレイで接続する様子を見せていた。

　もちろん、Jiniの目的はドライバのハンドリングだけではない。世界中のコンピュータから目的に合ったオブジェクト（すなわち実行可能なプログラム）を呼び、手元のオブジェクトと連携して使うことができる分散コンピューティング技術だ。それは革新的な世界を切り開くはずだった。

　残念ながら、Jiniは不発に終わった。Jiniが登場した時期、Javaテクノロジーはエンタープライズ向けの技術体系として発展しつつあった。毛色が異なる分散コンピューティング技術のJiniには十分なリソースが割り当てられなかったようだ。

　以上見てきたように、Javaの根底には「安全な分散コンピューティング環境を構築する」という設計思想がある。魔神ジーニーのように自由自在に分散環境でポータブルなプログラム（オブジェクト）を操れる、そのような分散コンピューティング環境を作り出すことはジョイの狙いだったのだ。

　Javaオブジェクトはポータブルで、どのCPUアーキテクチャ上で実行されているかを意識する必要はない。タッチパネル付きコンピュータでも、ハイエンドサーバでも、組み込み機器でも情報家電でも同様に動かすことができ、必要に応じて呼び出される──。残念ながら、Jiniのこんな構想は不発に終わり、魔神は封印されてしまった。

　その後のJavaテクノロジーには、高度な分散コンピューティングの追求のためではなく、エンタープライズ向けソフトウェア開発のために多くのリソースが注ぎ込まれた。とりわけ米IBMの貢献は膨大だった。日本のジャストシステムも、初期のJavaのマルチバイト文字対応で貢献している。Apache財団のオープンソース・ソフトウェア群も、エンタープライズ向けソフトウェアをオープンソース・コミュニティーの力を借りて充実させる狙いのものだ。今回の脆弱性の問題を引き起こしたLog4j 2もApacheのプロジェクトの一つだった。

バザールの矛盾、魔神ジーニーの矛盾

　Log4j 2の脆弱性の背後には、バザールの矛盾と、封印された分散処理の魔神ジーニーの矛盾がある──そのように筆者は捉えている。エリック・レイモンドのいう「バザール型開発」、つまりどんな開発者でも自由に開発に参加できるオープンソースソフトウェアのムーブメントの中で、“魔神ジーニーの能力のかけら”、つまりJavaの豊富な分散処理機能の一つが、少しだけ間違った使われ方をした。それがLog4j 2の脆弱性という巨大な問題に結びついた。

　Javaのように複雑化した技術、そしてApacheのように多種多様で規模や成熟度もまちまちなプロジェクトを包含するオープンソース開発コミュニティーで、今回の脆弱性のような事故を完全に防ぐことは難しくなっているのかもしれない。

　今後必要なことの一つは、セキュリティへの取り組みに必要なリソースをオープンソースコミュニティーに提供する方法を発見することだ。それはセキュリティに貢献した開発者への寄付や報奨金の制度かもしれないし、開発者をフルタイムで雇用する企業や団体を充実させることかもしれない。前述したGoogleの提案もこのような考え方に沿っている。

　オープンソースソフトウェア開発に伴う脆弱性問題は国家の安全保障にも絡む。有効な取り組みを考えていくことは、ソフトウェア開発者やソフトウェアの発注企業だけでなく、今を生きる私たち全員にとっての課題といえるのではないだろうか。