Mozilla製品全体で1万2千以上、Firefoxだけでも7000以上が存在するといわれるアドオン。そのバリエーションをさらに、はるかに豊かにするべくMozillaが打ち出したのが、Jetpackプロジェクトだ。Mozilla Labsが大々的にアナウンスし、多くのメディアで取り上げられたので、当ブログをお読みのみなさんであれば既にご存じのことと思う。
しかし、Jetpackプロジェクトの成果がFirefox.next（3.5の次のバージョン）に統合されると述べたものが見当たらなかったのは不思議だ。以前『Firefox.nextで「軽い」アドオンが加わりそう』で紹介した「拡張機能 2.0」こそが、今回発表されたJetpackである。したがって、アドオンとしてのJetpack（以下Jetpack）は、About:tabと同様にプロトタイプの側面をもち、Firefox.nextの開発プロセスの過程で本体に取り込まれていく運命にある。
現在の仕様を見てみよう。Jetpackは「Feature」と呼ばれる簡易アドオンのエンジンであり、この点ではGreasemonkeyに非常によく似ている。FeatureはHTML、CSSそしてJavaScriptといったWeb標準の規格を利用して作成・配布され、APIセットもシンプルかつ簡潔に保たれる予定であるため、開発者にとってアドオン作成の敷居が低くなることは間違いない。その代わり通常の拡張機能ほどの柔軟性はなく、機能的な制約をかなり受ける。Mozillaはそれを踏まえて「Extension」と区別した新名称を付けたのだろう。要するにFeatureは拡張機能ではなく、「補助機能」とでもいうべきものなのだ。
将来的には、FeatureでまかなえるものはFeatureでまかない、より深くシステムと統合したい場合に拡張機能が用いられるようになると考えられる。こうした相補的な関係にあるうえ、アドオン全体のエコシステムを拡大させるものだから、Mozilla Add-ons（AMO）がJetpackプロジェクトを歓迎するのも自然な流れだ。AMOによれば、Jetpackは次の点で従来のアドオンの欠点を補ってくれる。
- インストールにブラウザの再起動が不要
- よりよりデバッグ用ツール
- よりよいパッケージング
- 拡張機能の記述が簡単に
- コード生成／統合開発環境
以上の諸点を実感してもらうには、Mozilla Labsが作成したイントロダクション用のビデオを見てもらうのが手っ取り早いのだが、あいにく全編英語だ。実際にインストールして試す人以外は、「まめ畑」の『Jetpackでニコ動再生数表示Jetpack Featureを作ってみた』を読んでイメージを掴むといい。
Jetpackは、徹頭徹尾Webベースだ。Featureの本体は独自APIを叩くJavaScriptファイルであり、これをインストール用のWebページを通じて、外部リソースの形で公開する。この場面でHTMLとCSSが用いられる。逆に言うと、それ以外の余計なファイルを作成しなくて済むわけだ。そして、スクリプトを入れ替えるだけなので、Greasemonkeyと同じくFirefox本体の再起動は不要になる。
あらかじめ開発環境を用意している点もJetpackの特色の一つである。「about:jetpack」と打ち込んで開発画面を呼び出し、Bespinのコンポーネントを利用した編集画面でコードを書く。更新ボタンを押せばリアルタイムで結果がFirefoxに反映され、デバッグ用ツールとして、評価の高いFirebugをそのまま使えるようになっている。つまり、Jetpackはそれ自体一種のマッシュアップである。
Featureの機能面にも触れておこう。MozillaWikiの「Labs/Jetpack」によれば、いったん開発すればどこでもどんなバージョンでも動作することが目標だという。「どこでも」とは、Firefox向けのアドオンが、Firefox Mobile（Fennec）はもちろん、Thunderbirdでも動作するという意味。近い将来Thunderbird版Jetpackが公開されることを予感させる。
開発者がFirefoxなどのバージョンを気にしなくていいように、従来のAPIに新規のものを追加していく形式とし、後方互換性を維持する点も新しい。FirefoxのAPIが更新された場合でも、Jetpackが緩衝材となってFeatureに直接影響を及ぼさないようにするものとみられる。
セキュリティ面では、Featureは必要最小限のアクセス権限のみを有し、しかも他のFeatureと相互に干渉しあわないように設計されているそうだ。したがって、安全性は高いが、他のアドオンとの連携はまず無理ということになる。
アドオンといえばアップデート機能も必須だが、Featureは自動的かつ安全にアップデートが行われるそうだ。現行のアドオンよりも進んで、自動的にスクリプトを更新し、ユーザーには事後的な通知だけが行われる仕組みになるのではないだろうか。
Feature用APIに関しては、標準のものに加えてjQueryやDojoなどのサードパーティー製JavaScriptライブラリを使えるほか、TwitterをはじめとするWeb APIにも対応している。だが、前述のとおり、Firefox本体に対してできることは限られている（「hogehoge」の『Mozilla Jetpackについて調べたいこと』も参照）。『Target Add-ons』のページにあるとおり、OSのファイルシステムはもちろん、Placesにアクセスすることもできない。
なお、現在の仕様に基づくサンプルとして、MozillaWikiの『Labs/Jetpack/In The Wild』と「IT戦記」の『Firefox 拡張を jQuery で書く！ Jetpack を使ってみた。』、そして上記『Jetpackでニコ動〜』を挙げておく。
MozillaWikiによれば、JetpackのAPIからFeatureで次の各アドオンの機能を実現できるよう検討中だという。API進化の方向性を示すものとして興味深い。
- Download Statusbar
- AutoPager
- Speed Dial
- Forecastfox
- Morning Coffee
- Sage
- ShowIP
- allmusic.com toolbar
これを第一段階とすると、第二段階のAPIは格段に強化される。
- （Firefoxの）設定へのアクセス
- cookie jarへのアクセス、あるいはサンドボックス化された自前のcookieへのアクセス
- Firefoxのネットワーク設定（すなわちプロキシ設定）を通じたWebサービスの呼び出し
- mozStorage
- メニュー／キーボードショートカットの変更
- 新しいサイドバー、新しいツールバー、Firefoxのツールバーのボタンを追加／削除
- 検索プラグインの追加（無関係のプラグインは削除しない）
FirefoxのUIを変更し、SQLiteデータベースまで操作できるとなれば、現行のアドオンのかなりの部分を置き換えられそうだ。
今後、Jetpackはアドオンの形態で進化を続け、Firefox 3.5向けにはその形が維持されるだろう。Firefox.nextにはJetpackが統合され、FirefoxをインストールするだけでFeatureを利用できるようになるだろう。また、AMOとしてもFeatureのホスティングを行うはずだ。ユーザー視点からすると、拡張機能と補助機能を区別する理由はないのだから。
最後に、Piroさんが上記『Firefox.nextで「軽い」〜』のコメント欄で指摘されているように、JetpackがGoogle Chrome（以下Chrome）を強く意識していることにも言及しておきたい。「outsider reflex」の『Tree Style Tab on Google Chrome』本文およびコメント欄を読むとわかりやすいと思うが、要するにJetpackのFeatureはChrome 2.0の拡張機能に酷似している。
おそらく、Mozillaは先手を打ったのだ。FirefoxがFirefoxであるうえで、アドオンは不可欠の要素であり、この領域をChromeに浸食されるのは由々しき事態である。だからこそ、Jetpackというプロジェクトを立ち上げ、ChromeにおいてできることはFirefoxでもできることを示した。Chrome 2.0は完成が近づいており、近々拡張機能の詳細についてもアナウンスがあるだろう。それを見越して、この段階でのJetpackの発表である。内容といいタイミングといい、Chromeへの牽制を狙っていることは明らかといえよう。
（09/05/23追記）「hogehoge」の『Jetpackのセキュリティ性』も参照（API関係）。
（09/05/28追記）上の続編。『Jetpackのセキュリティ性(続報)』