Skip to content

Latest commit

 

History

History
826 lines (553 loc) · 127 KB

article.md

File metadata and controls

826 lines (553 loc) · 127 KB
Raw

そもそもFirefox子（ふぉくす子）とThunderbird子（さんだば子）って何なん？　どういう由来なん？　という所を改めて振り返りつつ語ってみます。

この二人は名前の通り、「Mozilla Firefox」というWebブラウザーと「Mozilla Thunderbird」というメールクライアントの擬人化キャラクターです。 どちらも、当時既に筆者（Piro）とIRC上で交流があった絵師のinugamix氏が2004年にデザインされました12。 特に明確な性格設定等があるわけではなく、好きに描いてほしいとのことで、筆者は一ファンとして「ふぉくす子は、元気キャラで能力値は高いけどちょっとおっちょこちょい。さんだば子はほわほわしてて癒やし系に見えるけど物凄く優秀」みたいな性格を想定してマンガやイラストを描いています。 2004年に「Firefoxのバージョン1.0リリースを勝手に祝って、これらのキャラクターをネタに合同誌を作ろう」と立ち上げたのが「もえじら組」というサークルで、初回のイベント参加以後は筆者が個人で細々とやってます。 サークル名は当時あった「もじら組」というMozilla製品の日本ローカルのユーザー会の名前をもじって付けました。

いや、語りたいのはもえじら組の歴史じゃなくて、FirefoxとThunderbirdの歴史なんでした。

実はFirefoxもThunderbirdも、インターネットの黎明期を切り拓いてオープンソースという言葉の誕生の契機となった、レジェンド的ソフトウェアの直系に位置する存在なのです。

Firefox前史

WWWの誕生とNetscape

歴史を辿ると、テッド・ネルソン氏が1964年～1965年頃に提唱した「ハイパーリンク」という概念3まで遡ることができます。 ハイパーリンクとは、文書と文書を結び付けて辿っていけるようにするコンセプトで、その1つの実装としてティム・バーナーズ＝リー氏がCERN4内での論文データベース構築のために1989年頃から作り始めた仕組みが「WWW（World Wide Web）」です。 最初のWWWブラウザーは、文章を書くツールと、文章を閲覧したりハイパーリンクを通じて辿ったりするツールが一体になっていました。 また、WWWで編集・閲覧する「Webページ」を作るために、1991年には「HTML5」という言語も作られ、仕様が公開されました。 WWWは当初はCERNの組織内LANだけで使われていましたが、大学間のネットワークとして既に稼働していたインターネットにおいても有用だったので、すぐにインターネットでも使われるようになりました。

WWWとHTMLは元々論文データベースのために作られたので、Webページに書ける内容は基本的に文章だけ。 装飾もほとんどできない、簡素な物でした。 それではつまらないということで、当時イリノイ大学のNCSAに在籍していたマーク・アンドリーセン氏らのチームは、仕様を独自に拡張して「imgタグ」などのビジュアル要素を勝手に（！）実装したWebブラウザー「Mosaic」を開発しました。 これが1993年のことです。

見た目に華やかなWebページを扱えるということでMosaicは大人気になりましたが、マーク氏らの雇い主であったNCSAはMosaicの権利者として6、その開発内容にまで様々な口出しをしだしました。 上司や組織の干渉を嫌ったマーク氏らはNCSAを離れることを決意し、1994年に「Mosaic Communications」として独立・起業。 Mosaicを上回る性能を持つ彼らの新製品のWebブラウザーには、「Mosaicを打ち倒すもの」として「Mosaic」と「Godzilla7」を組み合わせた「Mozilla」の名が与えられました。

「Mozillaブラウザー」の開発を進めていた彼らでしたが、しかし「Mosaic」の名前の権利もNCSAが持っていたことから訴訟を起こされ、早々に社名変更を余儀なくされます。 新社名は「Netscape Communications」となり、リリースする製品も新社名に基づいてブランディングするため、「Mozilla」の名はあくまで内輪の製品コードネームとして生き続けるに留まることとなりました。

そうして開発されたNetscape社の商用製品のWebブラウザー「Netscape Navigator」は、有償での販売ながら、性能的にも表現力的にもMosaicを大きく上回っていたことから大人気となります。 Mosaicでは画像表示で革新を見せたマーク達でしたが、Netscape Navigatorでは「Javaアプレット」や「JavaScript」の埋め込みを可能にし、静的なコンテンツだけだったWebに動的なコンテンツを持ち込むことになりました。 しかし、彼らのビジネスは「高性能なWebブラウザーの開発・販売」だけには留まりませんでした。

Netscapeは当時まだ物珍しかった「インターネット上での商取引」に目を付け、Amazon.comのようなeコマースを安全に行う上で求められていた、電子署名と暗号化通信の技術であるSSL8を開発。 自社製ブラウザーに組み込んだ上で、それと対になるSSL対応のWebサーバー製品「Netscape NetSite Web Server」9も併せて開発し、企業向けに売り込みました。 こうして、Netscapeはブラウザーとサーバーの両面からWebに大きな影響を及ぼすようになり、「インターネットといえばNetscape」と言えるほどの大成功に至ります。

第一次ブラウザー戦争

大成功していたNetscapeを追う形で、「うちが次に獲るべき領域はインターネットだ！」と参入してきたのがMicrosoftです。 彼らはNCSA Mosaicのライセンスを販売していたSpyglass社からライセンスを買って開発した自社のWebブラウザーに、「Internet Explorer」のブランド名を付けて開発リソースをつぎ込み、やがてWindows 95の追加パッケージの一部として販売し始めました。 これが1995年のことです。 後の世に言う「第一次ブラウザー戦争」が幕を開けた瞬間でした。

話を一旦Netscapeに戻します。 クライアント向けブラウザー製品と企業向けサーバー製品を事業の2本柱として歩み始めたNetscape社は、Web以外のサーバー製品事業にも手を広げていきました。 それと歩調を合わせる形で、Netscape Navigator 3ではメールサーバー製品「Netscape Messaging Server」と組み合わせて使うメールクライアント機能や、Netscapeのブラウザーで表示するためのWebページを制作するためのHTMLエディター機能を追加した、上位版の「Netscape Navigator 3 Gold Edition」を投入。 Netscapeのサーバー製品にはブラウザー製品のライセンスもおまけとして付属していたことから、Netscapeのサーバー製品を導入した企業ではNetscape Navigatorを使い放題で、このこともまたNetscapeのシェア拡大につながりました。

また、1996年頃、当時のPCのOSとしてはMS-DOSからの流れの後継であった「Windows 95」が主流で、1台のPCを複数人で使うのにユーザーアカウントの切り替えなんかできませんでした。 社内LANでWindows機同士を連携させてユーザーアカウントを集中管理できる「Windows NT」10は存在していたものの、一般ユーザーや普通の会社にはまだまだ普及していませんし、Active Directoryなんて影も形もありません11。 そこで、大量のユーザー情報を管理する大企業向けディレクトリーサーバー「Netscape Directory Server」や、スケジュール管理の「Netscape Calendar Server」、プロキシーの「Netscape Proxy Server」、認証サーバーの「Netscape Certificate Server」、クライアントPCの設定の配布・管理を行う「Netscape Mission Control Desktop」といった多種多様なサーバー製品群を投入。 さらに、それらと連携するクライアント製品として「Netscape Navigator Gold Edition」も大幅にリブランディング。 Webブラウザー「Navigator」を中心として、メールクライアント「Messenger」、HTMLエディター「Composer」に加え、PC上で独自の複数ユーザープロファイル切り替えを可能にする「プロファイルマネージャー」、ディレクトリーサーバーの情報を利用する「アドレス帳」等の機能も統合し、サーバー製品との連携による設定の集中管理機能にも対応した多機能製品の「Netscape Communicator 4」を、新世代のビジネス用クライアント製品として打ち出しました12。

一方のIEはというと、IE2まではせいぜいおまけレベルの出来でしたが、相次ぐ改良により、IE3ではNetscape Navigator 3に比肩しうるようになります。 しかし市場ではまだまだNetscapeのブラウザーのシェアが大きく、ブラウザーとサーバーの両面を牛耳りたいMicrosoftにとっては歯がゆい状況が続いていました。 そこで1997年、Microsoftが次の一手として打ち出したのが「IE4とWindowsの統合、各種サーバー製品の無償化」でした。

この頃Microsoftは、Windows 9xのマルチユーザー対応、NTドメインによるユーザー情報と設定の集中管理など、大企業向けにWindowsの強化を進めていました。 また、Webサーバー「IIS」やメールサーバー「Exchange Server」といったサーバー製品、メールクライアント「Outlook」など、製品ラインナップも拡大していました。 これらを武器に、「Windows Serverのライセンスを買いさえすれば、そのオプション機能としてIISも使い放題」「Windowsのライセンスを買いさえすれば、その機能の一部としてIEもOutlook Expressも無償で使える」といった形で、クライアント領域でもサーバー領域でもシェアをかっさらう戦略を取ったのです

Windowsに最初からIEやサーバー製品が付いてくるなら、個人ユーザーも企業ユーザーも、わざわざNetscape製品を買ってまで導入する動機はなくなります。 こういった製品の無償化・Windowsへの同梱は「OSベンダーとしての地位を利用して競合製品を不当に排除する物だ」として、後に独占禁止法に基づく訴訟にも繋がりましたが、シェアの下落をそのまま放置するわけにもいかなかったNetscape社は最終的に、Netscape Communicator 4の全面的な無償配布に踏み切らざるを得なくなりました。

この頃のNetscapeとMicrosoftのブラウザー製品領域での激しいシェア争いが、世に言う「第一次ブラウザー戦争」です。

製品のWindowsへの抱き合わせという搦め手と並行して、Microsoftは純粋な性能・機能の面でも製品の改良を続けます。 Netscape Communicator 4ではリッチなコンテンツを実現するためのレンダリングエンジンの機能強化も行われていましたが、MicrosoftもIE4以降でNetscapeのブラウザーの機能に追いつき、やがて追い越していきます。 両者がしのぎを削る中で、HTMLに基づいたWebページの表現力はどんどん高まっていきました13。

IEがIE5、IE6と順調にバージョンを重ねる一方で、Netscapeはというと、Netscape Communicator 4でのコードの肥大化・複雑化が足枷となり、革新的な性能向上や新機能の搭載といった目に見える革新を示せずにいました。 それどころか、インターネットの利用拡大に伴ってWebページの内容がどんどん複雑化し派手になり、扱うデータ量が増えていった結果、「WebページのHTMLファイル全体が読み込まれるまで何も表示されず、真っ白な画面を眺めて何十秒もただ待たされるだけ」といった、ユーザー体験の悪化が深刻化していました。 「普通にユーザーとしての肌感覚で、Netscape製品よりIE5やIE6の方が快適だ」ということもあって、Netscape Communicator 4はますますシェアを落としていきました。 次世代の新製品「Netscape Communicator 5」の開発も遅々として進まず、状況は悪化の一途です。

そして1998年。 事態の打開を図ったNetscape社は、「まだ開発が進行中だったNetscape Communicator 5のソースコードを公開する」という、起死回生の一手を決断したのでした。

Mozillaとオープンソース

折しも、世の中はLinuxブームが高まりを見せていた頃。 リーナス・トーバルズ氏という個人の開発者が1991年に趣味で作ったOSの「Linux」は、GPL14のもとでソースコードが公開されており、誰もが自由に改変・再配布できました。 そんなオモチャみたいなソフトウェアが、大勢の人達によってたかって改良され、ついにはUNIX代替の実用品として製品化する企業まで現れ始めます。 「企業に雇用された開発チームがコストをかけて作るからこそ良い製品が生まれる」ということが常識だったソフトウェア業界において、フリーダムなムーブメントの中から実用に足るものが出てきたという出来事は、業界には衝撃をもって受け止められました。 これを自社のビジネスを脅かすものとして危険視するMicrosoftのような企業があった15一方で、「コミュニティが勝手に製品を改良してくれるなんて、そんなにありがたいことはない」と、低コストで高品質な製品を実現するために好都合だと接近を図る企業もいました。 そうした企業の中にNetscape社もあり、Netscape Communicator 5のソースコード公開は、この潮流の中で行われた決断だったのでした。

1998年当時、そのようなムーブメントを言い表す言葉としては「free software（フリーソフトウェア、自由なソフトウェア）」という言葉が使われていましたが、「free」が「無料」の意味だけに受け取られやすかったり、フリーソフトウェア運動の提唱者の言説が共産主義的でイメージが悪かったりして、ビジネスをしたり投資を募ったりする上では不都合が生じていました。 そこでNetscape社を含むソフトウェア企業や開発コミュニティの面々が集まって議論した結果生まれたのが、「オープンソース」という新しいブランディングです16。 「フリーソフトウェア運動」から政治的な臭いを取り除いたワードである「オープンソース」を旗印にすることで、ソフトウェア開発コミュニティとソフトウェア開発企業はより連携を強めていくことになります17。

Netscape社はNetscape Communicator 5のソースコードをオープンソース化するにあたり、企業とコミュニティの間に立つ存在・Netscape社のコミュニティ側の窓口として、「Mozilla Organization（mozilla.org）」を設立しました。 長らくコードネームとしてのみ知られてきた「Mozilla」の名は、ここで再び世の表舞台に姿を現すことになります。

Netscape Communicator 5のコードは、公開版ではコードネーム「Seamonkey」、一般名は「Mozilla Suite」と呼ばれることになりました。 コミュニティによって改善されることが期待されてのオープンソース化でしたが、実際の所、思惑通りには事は進みませんでした。 まずもって、Mozilla Suite＝Netscape Communicator 5は元々が公開を前提したものでは無かったので、コメントには「◯◯死ね！」みたいなとても表に出せない罵詈雑言が含まれたと言われています18。 また、既に構築・運用されていたNetscape社の社内インフラを前提としたソースコードは、ビルドして実行可能なバイナリを作るだけでも一苦労だったと言います19。 歴史が積み重なった秘伝のタレの集積のソースコードは、いわゆる技術的負債と化していて、外部の人が容易に手を出せるものではなく、製品の改善は遅々として進みませんでした20。

そういった停滞の状況下で1998年末、Mozillaプロジェクトに1つの新しい風が吹き込まれます。 それが「NGLayout」、後に「Gecko」と呼ばれる事になる新しいレンダリングエンジンです。 当時のNetscape Communicator 4のレンダリングエンジンは、機能面でも性能面でIEのレンダリングエンジン「Trident」の後塵を拝していましたが、GeckoはIEを上回る高機能・高性能、そして最新のWeb標準への対応を実現していました。

Web標準技術とGeckoエンジン

当初はコンピューターの垣根を越えて情報を共有できると期待されていたWWWでしたが、Netscape Navigator/CommunicatorとIEの熾烈なシェア争いの中での囲い込み戦略によって、Webには「このサイトの閲覧にはIE3以上が必要です」「このサイトはNetscape Navigator 4以降で閲覧してください」といったブラウザー依存のコンテンツが増えていきました。 WWWの技術仕様をとりまとめる標準化団体のW3C21では、このような状況を改善し「ブラウザの種類を問わず、誰でも（それこそ身障者でも）安定して閲覧・利用できる、ユニバーサルなWeb」を実現するための議論を行い、Netscape NavigatorやIEのその時点での実装を仕様化した部分を含みつつも、さらに先進的な機能をも盛り込んだ、「HTML4」「CSS222」「DOM23」「XML24」などのWeb標準技術仕様を策定していきました。

しかし、実装よりも仕様が先行する形で策定されたこれらの仕様には、「仕様書には記載があっても実際のWebブラウザーでは使えない」機能が多く含まれていました。 Netscape NavigatorもIE（Trident）も、名目上はこれらの仕様へ対応していたのですが、実際には仕様通りの振る舞いにならない不具合が多数あり、この当時W3Cの仕様で示された「ユニバーサルなWeb」は、絵に描いた餅と言わざるを得ない状況でした。

そこに現れたのがGeckoエンジンです。 Geckoは当時まだIEの最新バージョンでも対応できていなかった新しいWeb標準技術に対応していて、夢物語と思われがちだったWeb標準仕様を一気に現実へと引き寄せる物でした。 既存のコードの技術的負債に苦しめられていたMozillaは、事ここに至り、Netscape Communicator 5のソースの大部分を破棄してGeckoベースで製品を作り直すことを決断します25。

Web技術ベースのアプリケーション

Geckoベースで作り直されるにあたり、Mozillaブラウザーは野心的な設計を取り入れました。 それが、「ブラウザーのUIそのものをGeckoエンジンの上で動かす」という考え方。 GUIの基本構造をXMLの一種のXUL26で記述し、見た目をCSSで整えて、動的な挙動はJavaScriptで制御する、「Webページと同じ技術に基づくデスクトップアプリケーション」という設計です。

実を言うと、そのようなコンセプトはMicrosoftも、IEをWindowsに統合していく中で少しずつ取り入れてはいました。 例えば、Windowsの「エクスプローラ」のフォルダーウィンドウに様々な情報を表示するサイドバーなどはIEコンポーネントを使ってHTMLとJScriptベースで実現されていましたし、Windowsのレジストリを少しいじれば、HTMLとJScriptを使って書いた機能をWindowsやIEに新しいメニュー項目として追加する事もできていました。 あるいは、ローカルへアプリケーションをインストールせずにIE上で使えるWebアプリ版Outlook、「Outlook Web Access」なんて物もありました27。 その要素技術としてIE5にシレッと追加されていたのが「XMLHttpRequest」という非同期通信機能で、これを活用して快適に動作する地図アプリケーション「Google Maps」などが開発・公開された事を端緒にして始まったのが、ローカルアプリケーションをWebアプリが駆逐していく「Web 2.0」の潮流なのですが、それはまた別のお話。

ともあれ、ローカルアプリケーションでのWeb技術の利用は、当時はまだ部分的な採用や限定された用途に留まっていました。 普通のユーザーが使えて身近なフル機能のアプリケーションとして実用できた例は、この「GeckoベースのWebブラウザー」が初めてだった、というのが筆者の認識です。

当時高校生で、Web標準技術へ傾倒していた筆者は、現実のWebブラウザーに多大なフラストレーションを感じていました。

自作のイラストなどのコンテンツをWebに公開する「個人Webサイト」が全盛期だったこの頃、筆者もWebサイトを自作して公開していましたが、Netscape Navigator/Communicator 4でのWeb利用は大変な苦痛を伴うものになりつつありました。 というのも、当時はHTML tableでWebページの内容をレイアウトする技法が広く使われていましたが、Netscape Navigator/Communicator 4には「セルの内容がすべて確定するまでtable全体を描画できない」という制約があり、「画像をふんだんに使い、レイアウトに凝る」傾向があったイラストサイトとはすこぶる相性が悪かったのです。 「自分のWebサイトを快適に閲覧できる状態に改善したい」と思って2ちゃんねる（今の5ちゃんねる）で匿名で質問をして紹介された「スタイルシートWebデザイン（著：すみ けんたろう）」は、筆者にとって非常に大きな衝撃をもたらす一冊でした。 「Webページとはワープロソフトのようなツールを使って作る物だ、文字の色や配置をいじって壁新聞のように作る物だ」と思っていた筆者にこの本は、単に「Webページの構成要素全部が読み込まれていなくても少しずつ表示され、快適に閲覧できる」という状態を実現する技術的な方法を教えてくれただけではなく、「WebページはHTMLで記述し、CSSで外観を整えて作る物だ」「そのように文書の内容と外観を分離する事によって、閲覧者は1つのWebページを、PCのWebブラウザー、携帯端末のWebブラウザー、音声読み上げソフトなど、自分のニーズに合わせた形で読めるようになり、ユニバーサルなWebを実現できる」という、技術が社会をより良くするビジョンを示してくれたのです。

しかし、そうして知った最新のWeb標準技術を使ってみようとして、筆者は失望を覚えました。 この頃はNetscape Navigator/Communicator 4とIEのシェア争いがIEの勝利でほぼ決着し、IEが長い長い停滞に入った時期です。 せっかく仕様があるのに、現実には使えないという状況を、一介の高校生だった筆者は指をくわえて見ているしかなかったのです。

そのような状況で筆者が出会ったのが、Geckoベースで開発が進行していたMozillaブラウザーでした。 技術雑誌の誌面で存在を知り、実際に実行可能な開発者向けのテスト用バイナリを入手し、動かしてみて、「まだ社会に出てすらいない自分が、製品としてリリースされる前の開発版を試せる」事に衝撃を受けましたし、また、それがXMLとCSSとDOM（とJavaScript）という当時まさに自分が入れ込んでいたWeb標準技術で実現されていた事にも、拡張機能という仕組みで自由に手を入れられる事にも感動したのでした。

また、このMozillaブラウザーには興味深い特徴が1つありました。 それは、「XMLとCSSとJavaScriptで作る拡張機能で、ブラウザーにどんな機能でも追加できた」という事です。 ブラウザー本体の構成ファイルであるモジュール定義に数行書き加えるだけで、自作のモジュールがMozillaブラウザーのUI実装の名前空間に読み込まれる。 それらのモジュールが、Mozillaブラウザー内部で処理を付け加えたり関数を置き換えたりして、実装をドラスティックに置き換えて動作を拡張する。 Mozillaブラウザーの拡張機能は、実質的には「動的に読み込まれるパッチ」だったため、無限の可能性がありました。 また、拡張機能による機能の追加以外にも、CSSで定義された外観と画像のセットを「テーマ」と呼んで、テーマの切り替えだけでアイコンセットや配色など幅広く見た目をカスタマイズする事もできました。 先述の通り、当時のIEもコンテキストメニューへ機能を追加するという程度の事はできていましたが、Mozillaブラウザーのこの拡張性の高さは他に類を見ない物でした28。

まだ同時に1つのページしか扱えなかったMozillaブラウザーを、複数のWebページを並行して閲覧する「タブブラウザー」に変えてしまう拡張機能「MultiZilla」なんて物もありましたし、筆者自身も、Mozillaブラウザーのメインウィンドウに組み込まれる形で実装されていたサイドバー領域を別ウィンドウに切り離してしまう「Sidebar Window」や、当時まだGeckoが対応していなかったHTMLルビ29を表示できるようにする「XHTML Ruby Support」などの拡張機能を開発していました。 あるいは、そもそもMozillaブラウザーのWebブラウザーとしての機能を全く使わずに、純粋なファイルマネージャ・FTPでのファイルの送受信のクライアントとして使えるようにする「FileZilla」なんて拡張機能もありました。 Mozillaブラウザーは、先進的なWebブラウザーであると同時に、誰でも気軽に使える「Web技術ベースのアプリケーションの汎用実行プラットフォーム」としても期待される存在になっていきました。 見方によっては、Mozilla Suite自体が「Navigator（Webブラウザー）」「Messenger（メールクライアント）」「Composer（Webページ作成ツール）」という多様なWeb技術ベースアプリケーションの実装例の集合体だったとも言えるでしょう。

個々のWebブラウザーを1軒の飲食店に例えるなら、「頑固一徹、メニューは1種類だけの硬派なラーメン屋」のNetscape Navigator、「テーブル調味料で味変できるラーメン屋」のIE、「メニューの幅が広いファミレス」のNetscape Communicatorが軒を連ねていた所に、「店内はゴチャついてるけど、食べたい物がメニューに無いなら冷蔵庫の中の高級食材で好きな料理を作っていいよ」と調理場を客に開放するワイルドな料理屋が出店してきたようなものです。 料理に興味がない人にとってはただ選択肢が増えただけですが、料理の心得がある人にとっては、その気になれば何でもそこで食べられる他に類を見ない店に感じられるでしょう。 こうして、Mozilla Suiteはごく一部の人から熱烈な支持を得るに至ったのでした。

後に、この「Web技術ベースのアプリケーションの汎用実行プラットフォーム」という性質に特化したアプリケーションランタイムエンジンとして、「XULRunner」というプロジェクトも立ち上げられました。 実際に、Skypeの一時期のバージョンなどはXULRunnerアプリケーションとして開発・公開されていた事もありました。

後年、MozillaプロジェクトがGeckoの開発について、古いAPIの廃止を許容するように方針を転換したため、XULRunnerは「XULRunnerアプリケーションを安定して動作させられるプラットフォーム」としては信頼して使えなくなり、そのまま廃れてしまいました。 なお、Chromiumをアプリケーション実行プラットフォームとして使う「Electron」のように、同様のコンセプトを持つソフトウェアは今も存在しており、それに基づいて開発された「Visual Studio Code」などのアプリケーションも実用されています。

Netscapeの終焉とMozillaコミュニティ

とはいえ、このアプローチは当時の状況ではあまりに野心的すぎました。 新しいコンセプトでアプリケーションの実装の枠組み自体を変えてしまうという事と、アプリケーション・スィートという形で統合される前提での複数アプリケーションの並行開発という、2つの全く異なる作業を、明確なビジョンが不在のままの状態で同時に進めた結果、開発は困難を極めました。 また、Netscape Communicator 5のリリース断念とGeckoエンジンへの刷新の結果、Mozillaプロジェクトの成果を新製品としてリリースできずお預けを食わされ続けていたNetscape社からの、突き上げや茶々入れも激しかったようです。 1998年のオープンソース化以後、なかなかバージョン1.0をリリースできずにいたMozillaブラウザーの、開発途上版を元に製品名を変えて2000年にリリースされた「Netscape 6」は、ただでさえ完成度が低かったのに加え、快適な使用には当時の一般的なPCよりも高いスペックが必要だったこともあり、その出来には判官贔屓のNetscape Navigator/Communicator 4ユーザーすらも大いに落胆しました。

Netscape当時からWebブラウザー開発に関わり続けながら、Geckoベースで作り直されたMozilla Suiteの完成を見ることなく1999年にMozillaを去ったジェイミー・ザウィンスキー氏が、この当時の心境を記した「辞職そして追悼」という文書には、当時のプロジェクトの苦しい状況が赤裸々に綴られています。

こうして、第一次ブラウザー戦争におけるNetscapeの敗北はもはや決定的なものとなりました。 後に、Mozillaブラウザーは2002年にバージョン1.0に到達し、それを元にした「Netscape 7」もリリースされましたが、もはやNetscapeのブランドがかつての輝きを取り戻すことはありませんでした。 そして2003年、会社としてのNetscape社はとうとう消滅。 Mozilla Organizationは運営母体を失って「Mozilla Foundation」となり、ここから先は自分達の意志で独自の道を歩んでいくことになります。

ブラウザー製品としてのMozilla SuiteとNetscape 6は芳しい成果を残せませんでしたが、この頃に導入され現在のFirefoxに至るまで引き継がれている機能もあります。 SVG画像のネイティブ対応と、他のXML応用言語との混合表示。 当時としてはメジャーブラウザーでの採用は珍しかった「ポップアップブロック」。 キー入力の進行に応じてダイナミックにページ内検索を実行する「インクリメンタルサーチ」。 少ないメモリー消費で大量のデータをスクロール可能領域に表示する、現代の仮想スクロール（Virutal Scroll）を一足先にネイティブ実装した「ツリービュー」。 今ではどのブラウザーも当たり前に実装している「タブブラウズ」も、この頃に取り込まれました。

Netscapeの消滅とMozillaの独立は、ユーザーや市井の開発者のコミュニティにとって、ある意味では明るいニュースでもありました。 親会社のビジネスの意向に振り回される心配がなくなったため、それまで以上にコミュニティ側の意向が反映されやすくなると期待されたからです。 日本においても、Netscape社でブラウザー製品の開発に関わり、英語圏の開発者に「文字化け」という概念を知らしめた事で知られる瀧田佐登子氏が代表となって、Mozilla Foundationの公式アフィリエイト組織の「Mozilla Japan」が設立。 それまでのコミュニティと連携しながら、普及・啓蒙活動や技術イベントの開催などを行っていくようになります。

Mozillaの再生、Firefox

FirefoxとThunderbirdの誕生

そのような悲喜こもごもがあった一方で、Mozillaプロジェクト内部では2002年に、デイブ・ハイアット氏30やブレイク・ロス氏、ベン・グッジャー氏といった一部のメンバーが、「Phoenix」というサブプロジェクトを立ち上げていました31。 開発の混迷を極めたMozilla Suiteの、もはや希望も潰えて燃え尽きた灰の中から再び蘇る、炎の不死鳥。 少数精鋭メンバーによる強力なリーダーシップに基づいて、Mozillaブラウザーの野心的な試みのうち「高性能なGeckoエンジンを基盤に、Web技術ベースでアプリケーションを作る」という部分に特化し、Webブラウザーとして必要最低限の機能だけに絞り込んで、それ以外の機能をそぎ落とし、親会社の意向ではなく「ユーザーとしての使いやすさ」というニーズに基づいて再構築された、軽量・高性能のWebブラウザー。 後に、商標の問題から2003年に「Firebird」、翌2004年に「Firefox」と名を改める事になる存在の誕生です32。

また、Phoenixの誕生後まもなく、それと同様にMozilla Suiteのメールクライアント部分のみを取り出してコンセプトを継承した、もう一つのサブプロジェクトも誕生しました。 当初「Minotaur」と呼ばれていたこのプロジェクトは、Phoenixの「Firebird」への改称と同時期に「Thunderbird」へと名を改めます33。

こうして同じGeckoエンジンを基盤としつつ、別々の独立したアプリケーションとして生まれ変わったFirefoxとThunderbirdは、同じ血を分けた姉妹と言えます。

この両者が備えていた特徴的な機能の1つに「アドオンマネージャー」があります。 実のところ、先述したMultiZillaやFileZilla、Sidebar Windowといった「Mozilla Suite向けの拡張機能」は、自身をMozilla Suiteのモジュールとして登録したり削除したりするインストーラ・アンインストーラ的な仕組みを、それぞれが独自に実装する必要がありました。 これは開発者にとってもユーザーにとってもあまりに不便でしたし、拡張機能の開発者にとっては参入のハードルが無駄に高くなる原因の一つでした。 また、拡張機能によってはアンインストール機構を備えていなかったり、アンインストール操作をしても綺麗に削除されてくれなかったりと、エンドユーザー観点でも出来のいい仕組みとは言えませんでした。

その反省があってか、Firefox（Firebird）とThunderbirdではごく初期のバージョンから、統一的なインターフェースで拡張機能の登録と削除を安定して行える仕組みが整備されていました。 これによって拡張機能開発のハードルが引き下げられたことや、拡張対象のアプリケーションが複雑で巨大な「Mozilla Suite」から、よりシンプルな単機能のアプリケーションに替わったこと、さらには後に公式にポータルサイト「Mozilla Add-ons」が整備されるようになったことなどもあり、それまでに無かった規模で多くの開発者が拡張機能の開発に名乗りを上げるようになります34。

開発は順調に進行し、Firefox（当時はまだFirebird）とThunderbirdは、一般のユーザーからも良好な評価を得るに至ります。 そうしてMozilla Organizationは「Mozilla Suite 1.4」を境に、メインの製品ラインをMozilla SuiteからFirefoxとThunderbirdへ切り替える決断を下しました。 その後のNetscape社の消滅とMozilla Foundationの設立、その下部法人としてのMozilla Corporation立ち上げを経て、2004年にはFirefoxもThunderbirdもバージョン1.0をリリース。 第一次ブラウザー戦争の終結を経てすっかり開発が停滞していたIEと、その次の座を狙う様々なプレイヤー達による、「第二次ブラウザー戦争」の熱が高まっていく事になります。

第二次ブラウザー戦争

第一次ブラウザー戦争の時代にはNetscape Navigatorと激しいシェア争いを繰り広げ、バージョンを重ねるごとにどんどん改良を重ねられていったIEでしたが、勝敗がほぼ決した頃からは目に見えて停滞が始まっていました。 2001年にリリースされたIE6は、その当時には最新のWeb標準仕様によく対応したブラウザーでしたが、それ以後目立った機能追加はなされず、セキュリティ修正以外の改善は見られなくなっていきました35。

これは、BtoB向けにお堅いWebサイトを制作するビジネスにおいては、前提が変わらないため納品物のメンテナンスに手がかからないというメリットにはなりますが、コンシューマ向けに目新しい物を提供していきたい人達にとっては、いつまで経っても直らないIEの不具合に悩まされたり、W3Cの最新のWeb標準技術仕様には定義があって「まさにこれを使いたい！」と思った機能がことごとくIE6では未実装で実際には使えなかったりと、フラストレーションが溜まる状況でした。 挙げ句の果てには、元々はWebページの中にアニメーション要素などの部品を埋め込むために用意されていたプラグイン機構を使って、Webページ全体をActiveXやFlashによるリッチコンテンツで提供するようにまでなり、PCのWebブラウザー以外での情報へのアクセスが著しく制限されてしまう36、などという状況も頻発していました。

このような状況に業を煮やしていたプレイヤーの一人がGoogleです。 技術を使って便利なWebサービスを提供していきたかったGoogleにとって、WebがMicrosoftというたった一社の怠惰によって停滞し続けるのは我慢ならないことでした。 IE向けのアドインである「Googleツールバー」を開発し、IE6の不便を補う試みもしていましたが、そういった方法でやれることには限界があります。

そこでGoogleは、Mozillaに目を付けました。 Netscapeの手を離れ独自の道を歩む必要に迫られたMozilla Foundationに、「ブラウザーのUI上からGoogle検索を実行できるようにしてくれているので、広告収入を支払う」という名目で資金を援助し、Firefoxの開発を支援した37のです。 また、Firefoxの開発者を自ら雇用して、Googleでの業務の一環としてFirefoxの開発にあたらせる、という形での支援も行っていました38。 当時のMozillaのオフィスはマウンテンビューにありましたが、すぐ隣にはGoogleのキャンパスがあり、MozillaのスタッフはGoogle社内で働く開発メンバーに帯同して、Googleの敷地に出入りしてラウンジで無償で食事を取ることすらできていました39。

また、最大のシェアを抑えていたプレイヤーが停滞していたという事は、他のプレイヤーにもチャンスが回ってくる可能性があったという事でもあります。 この頃には、「Opera」や「iCab」などの独自のレンダリングエンジンを持つ独立系Webブラウザーや、改良したUIのみを提供してレンダリングエンジンにはIEの物を利用する「Donut」や「Sleipnir」などのIEコンポーネントブラウザーなど、様々なブラウザーが世に出ていました。 それぞれのプレイヤーがそれぞれのやり方でしのぎを削っていたこの時代を、第二次ブラウザー戦争と呼びます。

やがてMicrosoftもこのような状況の変化に危機感を抱き、IEの開発を再開せざるを得なくなります。 しかし、IE7、IE8と改良を続けていくものの、レンダリングエンジンの基本的な設計の古さはいかんともしがたく、また長い停滞期による印象の悪化もあり、他のプレイヤー達に対して大きく見劣りする状況でした。 最終的には従来のレンダリングエンジンを破棄し、新規に開発したレンダリングエンジン「EdgeHTML」と新しい見た目を持ったWebブラウザー「Edge」で、心機一転を図る事になります。

筆者はこの頃、サポートパートナー企業からの出向・半常駐の形で、Mozilla JapanでFirefoxの普及活動のお手伝いに従事していました。 技術イベントの企画・開催、頒布物やノベルティグッズの製作、ブログ記事の執筆、はたまたマスコットキャラクター「フォクすけ」のデザインやぬいぐるみ製作まで、普通にソフトウェアエンジニアとして働いていたら携われなかったであろう様々なことを手がけさせてもらいました。

筆者のFirefoxアドオンの代表作といえる「TST（Tree Style Tab）」の初期バージョンは、実はMozilla Japanのオフィスでこそこそと開発していました。 誰に指示されるでもなく勝手に行っていた事ではありましたが、「TSTがあるからFirefoxを使用している」というユーザーの声を今でも時々見かけることを思うと、結果的にはFirefoxの普及活動にいくらか寄与できたと言えるのではないでしょうか。

ただ、筆者がMozilla Japanの事業に関わっているという事実は、秘密とまではいかないものの、あまり大っぴらにはしていませんでした。 これは、Mozilla Japanのプロモーション活動の中で、たまたまイベントに協力してくれたコミュニティの人が集めてこられたメイドコスプレの人達の姿がメディアで大きく取り上げられた結果、ユーザーコミュニティから「Mozillaに"オタク向け"の印象を結び付けるな」と不興を買ってしまったことがあったからです。 Firefox・Thunderbirdをモチーフとしたキャラクターを描いた成人男性向けの同人誌を制作・頒布する「もえじら組」の活動を並行していた筆者が、オフィシャルに関わっているという事実は、Mozilla JapanやFirefoxをバッシングする材料に使われてしまいかねません。 そう考えて、筆者の自主的な判断で名前を隠させてもらっていたのでした。

WebKitとChromeの登場

時代は少し遡り、第一次ブラウザー戦争の末期の1998年。 主要な戦場からは離れた所で「KHTML」が姿を現しました。 Linux用のデスクトップ環境を開発するKDEプロジェクト独自の、Webブラウザー用レンダリングエンジンです。

コミュニティによって開発され、企業色の薄かったKHTMLでしたが、ここにAppleは目を付けました。 2001年当時、AppleはMicrosoftから提供を受けたIEを、Mac OSの「既定のWebブラウザー」として採用していました。 これを自社のコントロールが及ぶ製品に置き換えたかったAppleは、KHTMLをフォークして開発リソースをつぎ込み、独自の改良を重ね始めます。 その成果がレンダリングエンジン「WebKit」であり、それを搭載して2003年にリリースしたApple自社ブランドのWebブラウザー「Safari」でした。

WebKitはGeckoと並ぶ高機能・高性能を備えており、最新のWeb標準技術仕様への対応状況をチェックする「Acid2テスト」を最初にクリアしたレンダリングエンジンとなりました。

また、WebKitは、ソフトウェア開発者視点でのそれ自体の開発しやすさも魅力として、開発者コミュニティに歓待されました。 当時のMozillaプロジェクトはレンダリングエンジンこそ刷新したものの、基盤には秘伝のタレ化したNetscape時代の遺産が多く残っていましたし、Windows・Mac・Linuxの3プラットフォームをまたいで動作させるための独自の抽象化レイヤーも抱え込んでいました。 「オープンソースのバザール開発で、誰でも開発に関われる」とは言っても、実際に開発に参加するにはMozilla固有の事情を色々学んで把握しなくてはならず、参加には高いハードルがあったのです。 そこに現れたのが、Geckoよりも過去のしがらみが少なかったWebKitでした。 身軽さをもって人気を博したWebKitの様子を、しがらみに囚われて開発リソース不足に悩んでいたMozillaの開発者達は、大いに羨みました。 この当時のMozilla開発者達の心情は、開発チームの重鎮だったロバート・オキャラハン氏が後年明らかにした文書に綴られています。

そうして苦境にあえぐMozillaを尻目に、WebKitは着実に支持者を増やしていきましたが、その中には、長くMozillaの支援者であったGoogleの姿もありました。

IE6の寡占状態を打倒しWebの進歩の速度を取り戻すべく、支援関係を結び蜜月の時を過ごしてきたGoogleとMozillaでしたが、両者にはそれぞれの思惑がありました。 自社独自のWebサービスを持たず、Webに自由と選択肢をもたらすことを旗印にしたMozillaの開発方針は、自社のWebサービスにとって有利な状況を作りたかったGoogleにとって、必ずしも嬉しい結果ばかりをもたらす物ではありません。

自社で方針をコントロールできるWebブラウザーを持つべく、GoogleはレンダリングエンジンにWebKitを使用した独自のブラウザー開発に乗り出します。 それまでFirefoxの開発にあたっていた人達のノウハウを、今度は自社製ブラウザーの開発に活かす形です。 そこには、Firefoxの初期の開発を支えたベン・グッジャー氏やダリン・フィッシャー氏らの姿もありました。 彼らの手による新しいWebブラウザーは、第二次ブラウザー戦争の渦中の2008年に「Google Chrome」として世に出たのでした。

Chromeの開発を通じ、Chromeの開発チームからはWebKitへ多くのコントリビュートがなされました。 しかし、ChromeとSafariの設計思想やプロジェクト運営方針の違いから、WebKitには次第に「Chromeでしか使われない部分」「Safariでしか使われない部分」といった、各ブラウザー向けに役割が重複するコードが増加していったようです。 WebKitのコードベースが無意味に肥大化・複雑化する状況に終止符を打つため、2013年にChromeの開発チームはWebKitをフォークし、Chrome専用のレンダリングエンジン「Blink」として最適化する決断を下します。

当初は同じコードベースから出発したBlinkとWebKitでしたが、それぞれがもはや使われなくなったコードを削除し、開発を進めていった結果、現在では、両者は似通った部分はありつつも全く別のレンダリングエンジンとなっています。

当時MicrosoftとIE6の帝国を打ち砕く反逆者の旗手と見られていたGoogleが、満を持して送り出した自社製ブラウザー。 第二次ブラウザー戦争の参戦者としては最後発でしたが、それだけに他のブラウザーの成功と失敗をよく研究して作られており、Chromeは瞬く間に人気を博しました。

Chromeの革新とFirefoxの停滞

ユーザーの操作への応答性の追及や、マルチプロセス設計による高い安定性の実現、WebKitゆずりのWeb標準技術仕様への高度な対応など、Chromeが当初から優れていた点はいくつかあります。 それらの特長は、「思想や理念よりも、とにかく実用を重視し、ユーザー体験を向上し続ける」という設計方針によってもたらされていたと言えるでしょう。

例えば、WebKitは充分に高性能なので、やろうと思えばFirefoxと同じように、すべてのUIをWebKit上で構築する事もできたはずです。 そうすればFirefoxと同様に、ユーザーがあらゆる場所に自由に手を入れられるアプリケーションになっていたはずです40。 しかしChromeの開発チームはその道を選びませんでした。

Firefoxの「ユーザーがブラウザーの振る舞いを自由に拡張できる」「ブラウザーとしてのUIすらもすべて共通のレンダリングエンジンで実現されている」「無限の可能性が開かれている」という在り方は、理念としては美しいし格好いいのは間違いないです。 ですが、実用だけを考えればそこまでする必要はありません。 悪く言えば、夢と過剰品質を追い求めて、金にならないことにコストを支払い続けているとも言えます。 ビジネス上の実利を考えれば、Webページの作成者達が自由に使える領域と、ブラウザーの開発チームだけが自分達の意向でコントロールできるUI領域はすっぱり分けてしまって、「ブラウザー開発者が考える、こうあるべきだというお仕着せのUI」を作り込んで提供するのが、最も理に適っています41。

いえ、実際には過剰品質どころか、「自由な使い方を許す」という在り方自体が、Firefoxの進歩を阻害してすらいました。

実質的には動的なパッチであった「FirefoxのUI内部にまで自由に手を入れられる拡張機能」でFirefoxの動作を変えるためには、拡張機能の開発者達は必然的に、そのバージョンのFirefoxの内部の設計に詳しくなった上で、そのバージョンのFirefoxの実装に対して密結合となるコードを書かなければいけません。 しかし、性能や使い勝手の向上のためにMozillaがFirefoxの実装を変えると、密結合で作られた拡張機能は当然動作しなくなります。 拡張機能が動かなくなると、ユーザーはMozillaの開発者に文句を言う。 ユーザーに嫌われたくないので、Mozillaの開発者はFirefoxの実装を迂闊に変えられない。 拡張機能の互換性を保ちながら改良を加えるために、Mozillaの開発者はまた余計なコスト負担を強いられる。 そんな悪循環に陥っていたのです。

そもそも、Firefoxの内部の設計に詳しくならないといけないということは、CSS、JavaScript、DOM、RDF42といったWeb標準技術のみならず、XUL、XBL43、XPCOM44などなど、Mozilla独自の技術にも精通する必要があるということです。 しかし、Web標準技術にはW3Cの仕様や解説があっても、Mozilla独自の技術にはドキュメントが無い場合が多く、それらはFirefox自体のソースコードを見て使い方を把握するしかない状況でした45。 これは初学者にとってはあまりに高いハードルです46。 そのような状況を改善するために、「FUEL47」という名の拡張機能向けAPIも用意されましたが、ごく基本的な機能しか提供されなかったため、実用的な拡張機能を作るのにはほとんど役に立ちませんでした。

また、Firefoxがメジャーブラウザーの一角入りした頃から、拡張機能のセキュリティリスクも無視できなくなってきました。 Firefoxの拡張機能は「なんでもできる」が故に、悪意に基づいて破壊行為をしたりユーザーの個人情報を盗み出したりも容易にできてしまいます。 また、善意に基づいて開発された拡張機能でも、それ自体に脆弱性があれば、同じ名前空間で動作するFirefox本体の中に保持されている認証情報などのクリティカルな情報が、すべて危険に晒される事になります48。 「拡張機能の公開前に必ずレビューを受ける必要を設ける」「レビューを受けていない拡張機能は一律で危険な物と見なし、インストールを制限する」といった対策は取られましたが、人間の目視によるレビューには限界があり、場合によってはアドオンを修正しても実際の公開までに何日も待たされるような事も起こるようになってしまいました。

こうして、Firefoxの可能性を広げるものとして好評を得ていた高い拡張性は、ほんの数年のうちに、Firefoxの可能性を縛り停滞を強いる負債となってしまっていました。 セキュリティを高めブラウザー全体の安定性を高めるプロセス分離や、新たに策定された技術仕様への対応など、導入すれば確実にFirefoxを良い物にするであろう改良の数々が、Firefoxには導入されない状況が続きました。 Firefoxの開発においてそのようなジレンマに苦しんでいた開発者達が、Chromeの開発を手がけることになった際に、ユーザーに対してChromeのUIに無闇な介入を許さない判断をしたのは、当然と言えるでしょう。

ただし、Chromeの開発チームは「ユーザーがブラウザーの機能を拡張できること」自体の価値は認めていました。 問題はあくまで、拡張機能が特定のバージョンのブラウザーと密結合になってしまうことの方にあります。 そこで彼らは、「大多数のユーザーがブラウザーで使っている拡張機能の傾向」を分析して、最大公約数的な範囲でニーズに合った拡張機能を開発できつつ、将来に渡ってChrome本体の改良を妨げる負債とならないような、拡張機能向けのAPIセットを用意しました。 Firefoxのように「ありとあらゆる拡張機能との互換性を維持し続ける」ことは不可能でも、APIとして使える事を約束している程度の範囲であれば、互換性を維持し続けることは可能です。 また、このような設計であれば、悪意の開発者が作成した攻撃用の拡張機能による情報の盗み出しや破壊活動なども予防しやすいです。 こうしてChromeには、「Firefoxの物とは互換性は無いが、将来のバージョンに渡ってChromeで安心して使用できる」事が約束された49、APIベースの拡張機能の仕組みが搭載されたのでした50。

JavaScript高速化時代の到来

この頃、Webページの動的なコンテンツの実行性能を高める技術的改善が、一般に利用可能なWebブラウザーにもたらされ始めました。

それまで、Webページ上で動作するプログラミング言語であるJavaScriptは、せいぜいがページ内の部分部分にちょっとした動きを付ける程度の使われ方しかされてきませんでした。 しかし、第二次ブラウザー戦争と共に訪れたWeb 2.0の潮流の中で、Webページを「JavaScriptベースのアプリケーション」として使う流れが加速。 そのため、第一次ブラウザー戦争当時には問題視されることが少なかったJavaScriptの実行性能の低さが、実用上の妨げになり得るようになってきました。

そこで、他の言語実装で行われてきた様々な高速化技術がJavaScriptに導入されるようになってきました。 例えば、当時大きく取り沙汰された技術の1つにJITコンパイラの導入があります。

当時のJavaScript処理系は、毎回常にソースコードの1行1行を逐次的に解釈し実行する純然たる「インタープリタ型」が基本でした。 インタープリタ型の処理系はプログラムのソースを与えられてすぐに実行できる利点がありますが、C言語などの「事前コンパイル型」言語に比べてオーバーヘッドが大きく実行速度が遅くなりがちなのが欠点です。 他方、使うかどうか分からないコードも含めて配布前に事前にすべてコンパイルしておく形式の言語では、実行時の性能は良好なものの、コンパイルのために長い時間待たされてしまいます。 この両者の「いいとこどり」を狙うのが、Just-in-Timeコンパイラです。 必要になったタイミングで「まさにその時（Just-in-Time）」にプログラムをソースコードから機械語に1回だけコンパイルして、以後はコンパイル済みの物を使うことにより、実行性能を大きく引き上げる技術です51。

FirefoxのJavaScriptエンジン「SpiderMonkey」にJITを搭載する、とアナウンスされた52のは2008年8月のことでした。 Firefoxを全体的に高速化してくれるはずということで、実際の製品投入はまだ先の事ながら、その第一報にユーザーは大きな期待に胸を膨らませました53。

しかし、その報せが出てからさほど間を空けずにリリースされたChromeの初版には、その時点ですでに、JITを採用した54JavaScriptエンジン「V8」が搭載されていました。 登場当初から極めて良好な性能を示していたV8に、Mozillaの技術解説を見て初めてJITを知った55筆者のような人は余計に驚くこととなりました56。

この流れの中でAppleもSafariのJavaScriptエンジン「JavaScriptCore」にJITを含む高速化・最適化技術を投入しますが、劇的な性能改善の成果が一般ユーザーの手に届くまでにはまだまだ時間を要します57。 結局、JITだけが理由ではないにせよ、当時実際にエンドユーザーが実用できたJavaScript実行エンジン達の中では、ChromeのV8が飛び抜けた高性能を示していた形となりました58。 このこともまた、Chromeが人気を集める大きな理由となったのでした。

こうした競争を通じて様々な技術が投入されていった結果、JavaScriptの処理速度はベンダーを問わず全体的に、第二次ブラウザー戦争以前と比べて数倍から十数倍と飛躍的に向上しました。 それまでの「いわゆるLightweight Languageは、書きやすいが遅い」という定説が覆され、V8を単体で取り出してサーバーサイドで利用可能とした「Node.js」によってJavaScriptがサーバーサイドでも人気を博すなど、LLの扱いが1段階ステージアップしたような印象を筆者は持ったのでした。

ラピッドリリースへの移行とESR

Chromeがブラウザー業界に持ち込んだもう1つの新しい文化が、ラピッドリリースというリリースモデルです。

それまでのWebブラウザーは、おおむね1年に1回程度メジャーアップデートがリリースされ、その間はセキュリティ修正が定期的に提供されるだけに留まり、新機能はメジャーアップデートまでお預けなのが常でした。 しかしGoogleは、Chromeを数週間ごとという極めて短いペースでリリースし、Webコンテンツの表示プラットフォームを常に最新の状態に更新し続ける事で、Web技術の進歩と普及を加速させる方針を取りました。

こうなると、新機能の投入まで最長で1年も待たされている間にますますユーザー離れが進んでしまいますし、そうでなくても、物凄い勢いでバージョン番号が繰り上がっていくChromeに対していつまでもバージョン番号が同じままのFirefoxというのは、いかにも見え方が悪いです。 やむなくMozillaも、Firefox 4以後を境にリリースモデルをラピッドリリース形式に移行することになります。

ただ、そこで企業でのニーズという問題が持ち上がりました。 企業全体で決まったWebブラウザーを使う運用を取っている場合、ブラウザーのバージョンアップに際しては、社内システムの動作の検証やトラブル対応の準備など、様々なコストが発生するため、あまりに頻繁なバージョンアップはシステム管理部門にとって大きな負担となります。

実際に、リリースサイクルが速まったことで、それまでは年に1回だった新機能の投入も、少しずつ段階的に行われていくようになりました。 普段のWebブラウズ時とはCookieなどのセッション情報を分けて、Webサイトに対して普段の利用状況を秘匿することをウィンドウ単位で可能にする「プライベートウィンドウ」。 その発展として、仕事用やショッピング用などの文脈ごとに、タブ単位でセッション情報を使い分けられるようにする「コンテナー」。 Webページに埋め込まれたトラッキング用ビーコンを遮断して、Webサイトをまたいだユーザーの追跡を困難にする「トラッキング防止」。 DNSへの問い合わせをより安全な経路で行う「DNS over HTTPS」。 毎月のようにドラスティックな変化がもたらされるラピッドリリースは、未知のリスクを嫌う保守的な運用スタイルとは相性が悪いと言わざるを得ません。

そのような背景から、Firefoxはラピッドリリースを行う通常リリース版とは別ラインとして、従来と同様に概ね1年に1回のペースでメジャーアップデートされる「Firefox ESR（Extended Support Release）」を提供することになりました。 Firefox ESR 10から始まったESR版の提供は、その後もFirefox ESR 17、Firefox ESR 24と続いていくこととなります。

なお、Thunderbirdは企業での利用が多く、また、開発リソースが不足気味だったことも背景にあって、ラピッドリリースへの全面移行はなされませんでした。 これ以後ThunderbirdはFirefox ESRと歩調を合わせて、メジャーアップデートの度にバージョン番号が飛び飛びになる形で、従来同様におよそ年1回のペースでリリースされていくことになります。

Firefox OS、モバイル版Firefox

Firefoxは、Webサイトの制作に関わるITエンジニアを中心とした、ガジェット好き・新し物好きの人々の支持を得て成長してきました。 しかし、Chromeという最有力プレイヤーがユーザーと開発者の両方の人気をかっさらっていったことで、Mozillaは改めて存在意義を示していく必要に迫られます。

この時期、Mozillaは「PCのデスクトップ環境で使用するWebブラウザー」のみを武器にしていては生き残れないとの判断から、モバイル端末・タブレット端末向けのブラウザー開発に力を入れ始めます。 iOSではGeckoエンジンを組み込んだ製品の提供がAppleの規約によって禁じられていたために、iOS向けにはWebKitエンジンを使用してUIだけを整備したブラウザーの「iOS版Firefox」59も提供するようになりました。

当初は「Fennec」と呼ばれたモバイル版Firefoxは、デスクトップ版に近い設計で登場し、複数のモバイルOSに対応した、デスクトップ版Firefoxの特長を引き継ぐ「拡張機能で自由にカスタマイズできるモバイル端末用ブラウザー」となることを期待されました。 しかし、デスクトップ環境に比べてCPUやメモリなどのリソースが大きく制限されるモバイル端末では、そのようなリッチな設計は実用上充分なパフォーマンスを実現できなかったことや、モバイルOS市場がiOS以外ではAndroidほぼ一強になり、複数のモバイルOSに対応する意味も薄くなっていったことで、Mozillaは「レンダリングエンジンのGeckoをコンテンツの処理のみに使い、UIをAndroidのネイティブアプリらしい形で実装した、Android専用ブラウザー」という方向に舵を切り直す判断をします。 その方向を突き詰めて「Fenix」の名の元に再設計されリリースされたAndroid版Firefoxにより、FirefoxユーザーのAndroidでの体験は大きく改善されました。 ただ、通常の手段では任意の拡張機能をインストールできないように制限を加えるなどの判断がなされるようになり、カスタマイズ性の面では大きく後退した状況となっています。

また、モバイル端末のOSはAppleのiOSとGoogleのAndroidの2大巨頭がしのぎを削る競争状態はあったものの、どちらも充分に「オープン」な環境とは言えないとして、Mozillaはそれらに代わる、よりオープンな別の選択肢としてのモバイル端末用OS「Firefox OS」の開発にも力を注ぎました。 iOSやAndroid、Windows Mobileなどが採用する、ネイティブアプリを主とした運用とは異なり、Gecko上で動作するWebアプリを「Firefox OSのアプリ」として扱う、Webサービス開発者にとってより手を出しやすい設計が特長のOSです。

ただ、モバイル版Firefoxについては一定の支持を得られたものの、すでにiOSとAndroidが席巻していたモバイル端末OSの世界に割り込む事は難しく、2013年に初版をリリースしたFirefox OSは、2016年のバージョン2.6を最後にプロジェクトを終了。 Mozillaはモバイル端末用OSの開発から完全に撤退することになります60。 ただでさえ開発リソースが限られていたMozillaの、少なくないエネルギーを振り分けていたFirefox OSプロジェクトが失敗に終わったことは、Mozillaにとって大きな痛手となりました。

Bootstrapped Extensions、Jetpack、そしてWebExtensions

Firefox OSの展開に苦戦する一方、デスクトップ環境のブラウザーであるFirefoxのシェアは、依然Chromeに押されて低下を続けていました。 いよいよ尻に火が着いたMozillaは、拡張機能が足枷となってFirefoxの開発が停滞している状況の本格的な解決を試み始めます。 この時期、Mozillaは拡張機能の互換性問題の解決とユーザー体験の向上を目指して、いくつかの取り組みを行いました。

まず1つ目は、再起動が要らない拡張機能を実現する「Bootstrapped Extensions」という仕組み。

この頃のFirefoxの拡張機能は、FirefoxのUIが動作している名前空間に拡張機能が提供するモジュールを読み込み、イベントにフックを仕掛けたり、Firefox内部の実装を置き換えたりといった形で、半ば無理やりにFirefoxの振る舞いを変更する形で実装されていました。 そのため、「動的な追加」まではどうにかできたとしても、「動的な削除」の実現は不可能でした61。

Bootstrapped Extensionsの枠組みでは、拡張機能の追加と削除を動的に行うことを前提として、拡張機能の側も、それらのイベントをトリガーとして自ら行儀良く初期化処理と終了処理を行うことを求める、という事になっていました。 ただ、この枠組みに従った拡張機能を開発できるかどうかは、開発者個人の技能次第な部分がありました。 筆者はこの頃実際にいくつかの拡張機能を、Bootstrapped Extensionsとして動的に追加・削除できる設計に作り替えましたが、全知識を総動員して取り組まなくてはならない、難易度が高く非常に面倒な作業だったと印象に残っています。

2つ目が「Jetpack」、後に「Add-on SDK」と呼ばれるようになる拡張機能用のフレームワークです。

Add-on SDKは、拡張機能のひな型作成やパッケージ作成といった定番の作業を効率化すると同時に、「Firefoxの内部の実装に詳しくならなくとも、SDKが提供するAPIさえ勉強すれば拡張機能を開発できる」「あらかじめ用意されたAPIセットに則って開発すれば、SDKを更新してビルドし直すだけで、拡張機能が新しいバージョンのFirefoxでも使える」といった状況を実現して、既存の拡張機能開発者の負担を軽減すると同時に、新規の拡張機能開発者を取り込むことを目指したプロジェクトでした。 また、それに加えて、SDKベースで開発した拡張機能はBootstrapped Extensionsとしての必要条件を暗黙的に満たす状態になり、再起動無しでの気軽な追加・削除までもが可能になる、という特色もありました。

ただ、この試みは、内容的にも結果的にも中途半端に終わります。 以前からの開発者にとっては、Add-on SDKはできる事の制約が多い不自由な開発基盤で、FUELの形を変えた焼き直しと感じられました。 新規の開発者の目にも、Chromeの拡張機能向けAPIとは全く異なる物を新たに学ばなくてはならないということで、あまり魅力的な物とは映りませんでした。 また、SDKにはSDKの標準ライブラリでできないことを自力で実装し直す仕組みも含まれていましたが、それを使うと結局は、従来と同じくFirefoxと密結合なコードを書き続ける苦労が付きまとう始末でした。

この反省を踏まえて2017年にFirefox 52で導入された3つ目の仕組みこそが、本命の「WebExtensions API」。 Add-on SDKとは別の、Chromeの拡張機能向けAPIと互換性を持つAPIセットで、Chrome用に開発された拡張機能をFirefoxに対応させることも、その逆も、それほど苦労することなく実現できるようにする物です。 これによって、「Firefox用の拡張機能を開発する」ことのハードルの高さは大きく引き下げられ、ようやくFirefoxは「多くの人が気軽に拡張機能を開発できる」状況に近付いたのでした。

XULアドオンからWebExtensionsへの大転換

WebExtensions APIを実装することが発表された当初は、古くからの拡張機能開発者の中には「またFUELの焼き直しが来るのか？　どうせまた失敗するんじゃないのか」と懐疑的に見ていた人もいました62。 Add-on SDKを使った物も含めて、WebExtensions API導入以前に作られていた形式の拡張機能は「XULアドオン」と呼ばれます。 前述した通り、XULアドオン形式の拡張機能は本質的には「Firefoxの名前空間に読み込まれる動的なパッチ」でした。 そのような性質の物である以上、APIの機能不足を補うためにはFirefox内部の深くにアクセスする必要があり、結局はFirefoxと密結合になってしまって、元の木阿弥にしかならないのではないか、というわけです。

ですが実際には、そうではありませんでした。 WebExtensions APIは単なるAPIセットに留まらず、XULアドオンとは全く別の形の拡張機能の枠組みの一環として作られたのです。

Chromeの拡張機能は「Chrome自身のUIから完全に隔離されて、APIが提供される範囲のことしかできない」という性質の物で、これは見方によっては「Chromeに内蔵された隔離環境で動作する小型のWebアプリ」とも言えます。 WebExtensions APIは、このコンセプトをFirefoxにそのまま持ち込む物でした。 同じ「拡張機能」でも、本質が動的なパッチであるXULアドオンと、本質が小型のWebアプリであるWebExtensions形式の拡張機能＝WebExtensionsアドオンとでは、実態が全く異なるのです。

FirefoxのUIの名前空間から隔離されたサンドボックス内に読み込まれて動作するWebExtensionsアドオンは、WebExtensions APIを経由してしかサンドボックスの外にアクセスできません。 そこにはAdd-on SDKのような、WebExtensions APIではできないことをできるようにする抜け道は全くありません。 できないことをできるようにするには、Firefoxがその機能をWebExtensions APIとして実装してくれるのを待つしかありません。 「大変だけど、自力救済であれば何でもできる」という従来型のXULアドオンに慣れ親しんだ拡張機能開発者にとっては、これは今までの拡張機能とはまったく違う作り方だったため、WebExtensions APIに基づく拡張機能は、極めて窮屈でやりにくい物に感じられました。 とはいえ、すでにChromeでの拡張機能開発に慣れ親しんだ人にとっては、これはほとんど追加の学習の必要なしに、それこそ「同じソースコードからChrome用とFirefox用のそれぞれのパッケージを作り分けられる」程度にまで、拡張機能をChromeからFirefoxへ移植する際のコストを引き下げてくれるのは間違いありません63。

ただ、そのように「客層を拡げる」ことに留まらない大きな狙いが、WebExtensions API導入の陰にはありました。 それが、「XULアドオンの廃止」という大きな決断です。

XULアドオンの時代の終わり

極めて高い自由度が与えられたXULアドオンの仕組みは、Firefoxの特色であり、人気を支えた重要な要素であり、そして同時に、停滞の原因となった足枷でもありました。 行き詰まりを目の当たりにしていたMozillaの開発者達にとって、XULアドオンは「廃止するか、廃止しないか」を議論する対象ではなく、もはや「いつ、どのように廃止するか」を議論するレベルの対象だったのです。

そのための重要な布石が、WebExtensions APIの導入でした。 WebExtensionsアドオン形式の拡張機能にとって、WebExtensions APIを介して見えない物は、存在しないのと同然です。 すべての拡張機能がWebExtensionsアドオンになってしまいさえすれば、WebExtensions APIから見えないFirefoxのUIや内部実装は、どう変えても何の支障も無くなります。

しかし、いきなりXULアドオンの仕組みを廃止してWebExtensionsに一本化すると、ユーザーが不利益を被るだけになってしまいます。 先述したようなコンセプトの大きな違いにより、WebExtensions APIベースの拡張機能とXULアドオンとでは自由度に大きな差があり、WebExtensionsでXULアドオンのすべてを置き換えることはできないからです。 客離れを防ぐためには、既存ユーザーに対して何らかのケアが必要でした64。

ユーザーが可能な限り不利益を被らずにXULアドオンを廃止するためには、「XULアドオンを廃止してもユーザーが困らない」「WebExtensions APIの範囲で、あるいは別の何らかの方法で、XULアドオンが満たしていたニーズを満たせる」状況を先に整えておかなくてはなりません。 端的に言えば、この時点では「WebExtensions APIへの機能追加」がまだまだ必要だったということです65。

ただ、FirefoxのWebExtensions APIは、Chromeの物をベースにしつつもニーズに応えてFirefox独自の機能も提供する方針が示されていましたが、そもそもどのようなニーズがあるのか、どのようなニーズになら応えられるのか、といった点は未知数でした。 そのためMozillaは2016年のAll Hands66の場に人気のFirefox拡張機能の作者を世界各国から招き、「XULアドオンを廃止してWebExtensions APIに一本化するためには何が必要なのか」を議論する機会を設けました。 筆者もこれに参加し、その当時のWebExtensions APIではニーズを満たせない部分があることを頑張って伝えてみたつもりです。 Firefoxを停滞させる原因を取り除き、生き残らせ、ユーザーにWebブラウザーの「メジャーとは別の選択肢」を残し続けるために。 Mozillaの開発チームと外部の拡張機能開発者達とで連携して、今いるユーザーを可能な限り切り捨てないで済むようなソフトランディングを図っていきたいという、共通した思いがあることを確かめあえた機会だったと筆者は思っています。

そうした議論の中で、法人用途で必要とされる頻度が高いカスタマイズについては、Active DirectoryのGPOのような「ポリシー定義」で簡単にカスタマイズできるようにする方が望ましい、という方向性も示されました。 筆者はこれ以後、所属会社のFirefox法人サポート事業でユーザー企業からのニーズが多かった機能をフィードバックし、Firefox本体のカスタマイズ項目に加えてもらうよう交渉する機会が増えました。 この一連の体験を通じて筆者は、「オープンソースにおけるバザール開発の健全な在り方は、意見交換と交渉に支えられている」ということを改めて痛感したのでした。

このAll Handsがあった翌2017年、WebExtensions APIはFirefox 52で通常リリースに投入され始め、同年中のFirefox 57のリリースをもってXULアドオンを廃止67。 充分なソフトランディングだったとは言い難かったものの68、FirefoxはついにXULアドオンからWebExtensionsへの完全移行を果たすこととなりました。

この移行に際し拡張機能の作者には、それ以前のやり方を一旦忘れて、WebExtensions APIの範囲だけで考えるようにするという、大きなパラダイムシフトが必要でした。 腹を括って発想を転換し、XULアドオン時代の最も重要な価値だったものを分析して、WebExtensions APIの組み合わせで近い価値を再現する方法を考えるという、今までに無かった努力が必要とされたのです69。 ここで振るい落とされてしまった拡張機能は残念ながら相当数あり、この大移行を「拡張機能の大量虐殺で、横暴だ」と感じた人もいました70。

ともあれ、そうして拡張機能がWebExtensions APIベースに移行していったことで、いよいよFirefoxそのものの中に溜まりに溜まった技術的負債を返済していく準備が整ったのでした。

なお、WebExtensions APIへの移行とXULアドオンの廃止はFirefoxだけでなくThunderbirdでも行われましたが、こちらはThunderbird開発チームのリソース不足のためにFirefoxよりも緩やかなペースで進められ、XULアドオンの完全廃止は2020年のThunderbird 78にまで持ち越されました。

生き残りを賭けて

XULアドオンの廃止以後、Firefoxの改善はそれ以前の遅れを取り戻すように急ピッチで進みます。

UIの実装においては、Mozilla独自の仕様を使っていた部分のWeb標準技術への置き換えが進みました。 Mozillaブラウザーが開発され始めた当初、ニーズに合うWeb標準仕様が無かったことからMozillaでは独自にXULやXBLといった仕様を作り利用していましたが、これらのことはそのまま開発への参加の障壁にもなっていました。 Webの進歩の中でHTMLの仕様が拡張されたり、カスタム要素を実装する仕様としてWebComponentsが整備されたりしたことを踏まえ、それらの独自仕様を相当する最新のWeb標準技術に置き換えていくことにより、Firefoxの開発に参加する上でのハードルが引き下げられました。

また性能面では、CSSのスタイル指定のレンダリング処理を効率化するQuantum CSS（Stylo）、3Dゲームエンジンの実装に使われる手法を応用したパイプライン処理によって画面描画のフレームレートを劇的に改善するWebRenderなど、Geckoとは別ラインで実験的に開発されていた新レンダリングエンジン「Servo」71の成果が続々とGeckoに取り込まれました。 これらの改善もあってか、常用していて「重い」と感じない程度の性能は実現されていると筆者は感じていますが、とはいえ2023年2月時点では各種ベンチマークが示す数字としては、Firefoxは依然Chromeの後塵を拝しているのが実情です。

MozillaとGoogleやAppleの開発リソース量には大きな開きがあり、性能面で真っ向勝負を挑んでも勝ち目は薄いです。 そのためMozillaは、非営利の組織の立場から「利益ではなく、ユーザーのためのインターネット」を旗印に掲げ、彼らビッグテック72がビジネス上の要請により応えられないニーズを掬い取る73ことで生き残りを図ろうとしています。

とはいえ、理想に走りすぎて実用性を疎かにすると一般ユーザーの常用の選択肢にはなり得ません。 Chromeの寡占化が進んだ結果、Webサービスの側が「このサービスを利用するにはChromeが必要です」と堂々と宣言し始めるなど、20年前の第一次ブラウザー戦争の時代に状況が逆戻りしてしまっている現在では、理想を曲げて「Chromeに合わせる」ことが求められる場面も生じています。 理想と実用の間でどのように落とし所を見つけ、存在感を示していくことができるのか。 インターネットが、ビッグテックの都合ばかりに振り回されることなく、誰もが自由に使える開かれたものであり続けられるように。 独自のエンジンを持つ最後の独立系ブラウザーベンダーであるMozillaの今後の動向を、筆者は注視して見守りたいと思っています。

FirefoxはそれまでのアイデンティティだったXULアドオンを捨てる道を選びましたが、その翌年の2018年には、MicrosoftのIE後継ブラウザーであったEdgeにも大きな動きがありました。 それが、独自のレンダリングエンジン「EdgeHTML」を廃止して、Chromeのオープンソース版であるChromiumを改造した派生ブラウザーとして作り直すという決定です。

ブラウザーベンダーがレンダリングエンジンを捨てる事例は、実はこれまでにもありました。 第一次ブラウザー戦争の頃からのプレイヤーであったWebブラウザー「Opera」は、独自のレンダリングエンジン「Presto」の開発終了を2013年に決定。 Chromiumの派生ブラウザーとして作り直されることになりました。 前出のロバート・オキャラハン氏の記事によれば、MozillaにおいてもGeckoを放棄してWebKitに乗り換える案が浮上していたそうです。

このようなことが起こった原因は、レンダリングエンジンの維持コストが年々増大していることにあります。 Web標準技術仕様が発展していくに連れ、それへの対応を進めるレンダリングエンジンは、複雑化・肥大化を免れません。 ブラウザーベンダーにとって、レンダリングエンジンは大切な資産ですが、維持コストがあまりに大きくなりすぎると、他者の都合に振り回されるリスクを許容してでもレンダリングエンジンを他社製品に入れ換えた方がメリットが大きい、という判断が下ることになります。 今となっては、Gecko・WebKit・Blinkと同水準でWeb標準に対応したレンダリングエンジンをゼロから開発することは事実上不可能だ、とすら言われています。

EdgeはMicrosoftにとっては自社製OSに欠かせない製品なのだから、レンダリングエンジンを他者に委ねる判断はしないだろう……と思われていただけに、EdgeHTMLの開発終了決定は業界関係者にとって衝撃的なニュースでした。 Microsoftほどの規模の企業が開発継続を断念する物を、Mozillaが資金力に劣る非営利の立場で、それなりに実用的なレベルで維持し続けているのは、驚くべき事と言えるでしょう。

Firefoxの法人利用

Firefoxの歴史的な歩みを中心に語ってきましたが、今度は別の切り口として、法人でのFirefoxの利用について語りましょう。

筆者はMozilla Japanのサポートパートナー企業だった74株式会社クリアコードに所属し、主にMozilla製品の法人向けサポート事業に従事しています。 個人での利用とは異なる力学が働く法人利用でFirefoxのどのようなところが魅力となるのかを、改めてご紹介します。

高度な集中管理

Netscape Communicatorの説明で設定の集中管理について触れましたが、この当時の機能は、実は今でもFirefoxに残っています。 AutoConfigまたはMCD75と呼ばれる機能で、Firefoxのインストール先配下の所定の位置に設定ファイルを設置しておくことで、起動時にそれが読み込まれ、Firefoxの各設定を個別に固定できるようになっています。 法人利用においては、これを使うことで、システムの管理者が「Firefoxのこの機能はユーザーに使わせたくないので、無効化する」「Firefoxのこの設定は、社内の状況だとこの選択肢以外では正常に動作しないので、正常に動作する設定で決め打ちにして変更を禁止する」といったカスタマイズを施した状態で、全社的にFirefoxを運用する事ができます。

AutoConfigの特長は、自由度の高さです。 Firefoxの内部設定一覧は「about:config」で確認できますが、AutoConfigを使うと、そのすべての項目を個別に制御できます。 ローカルの設定ファイルだけでなく、全ユーザーが共通して参照するWebサーバーやファイル共有サーバー上にリモート設定ファイルを設置しておくことで、各端末でFirefoxが起動される度に管理者側で記述した最新の設定を強制的に適用する、といった事も可能です。

また、これは将来的に使えなくなる可能性がある使い方ですが、AutoConfigの設定ファイルの実態は「Firefoxの起動時に読み込まれてFirefox内部の名前空間で実行されるスクリプト」なので、XULアドオンが廃止された今でも、XULアドオンに相当することを行える余地があります。 実際に、かつてXULアドオンとして人気を博した「userChrome.js」を、AutoConfigで代替している人達もいます。

ただ、そこまでの自由度をすべての法人ユーザーが求めているわけではありません。 自由度が高いことの裏返しとして、AutoConfigでのカスタマイズは、Firefox内部の設計に非常に詳しくないと適切な設定ができないという弱点があります。

Firefoxの内部設定の中には解説文書が用意されていない物が多々あり、設定すると何が起こるのか・したいことを実現するにはどのような設定をすればいいのかを把握するためには、Firefoxのソースコードを読み込んで調査する必要がある場合も多々あり、一般的な企業のシステム管理者にとっては荷が重すぎると言わざるを得ないでしょう。

そういった場面で顧客のしたいことの実現を手助けするのも、筆者が所属する株式会社クリアコードの法人サポート事業の内容の1つです。 実際に、Firefoxを利用したい法人からの依頼を受け、目的に合うような設定の組み方を調査し提案する、ということをこれまでに何度も行ってきました。

そういったことの反省から、Firefox 52以降のバージョンは「ポリシー設定」という新しい集中管理の仕組みに対応しています。 これは、Active DirectoryのGPO（グループポリシー）や、JSON形式で記述してAutoConfig用設定ファイルと似た要領で配置した「policies.json」を使うもので、自動アップデートの停止や、任意のアプリケーションの強制インストールなど、エンドユーザー視点でも分かりやすい粒度でFirefoxの動作を制御することができます。

補助的なブラウザーとして

筆者が関わったことがあるFirefoxの法人利用事例のほとんどは、「社内サイト閲覧用のIEと、社外サイト閲覧用のFirefox」という使い分けを前提としたものでした。 規模が大きな企業では、過去に社内のシステムをIE向けに作り込んでしまっていることがあり、それを引き続き使い続けるためにIEを手放せないのですが、その一方で、数々の脆弱性が指摘されているIEを使って公のWebサイトを閲覧する事には、今となっては多大なリスクが伴います。 そこで、IEとは別にインストールできるFirefoxを「社外サイト閲覧用のブラウザー」として使う動機が生じるのです。

ChromeやEdgeを社外サイト閲覧用に使う事もできるはずですが、なぜそうしないのでしょうか。 筆者の所属企業に相談が舞い込む事例では、ブラウザーのメジャーアップデートの頻度が問題となることが多い様子でした。

ラピッドリリースの項でも述べましたが、ITリテラシーが高くないユーザーを多く抱える企業では、頻繁に見た目や振る舞いが変わるラピッドリリースだと社内のサポート体制の構築が追いつきません。 現在はChromeもEdgeも、法人利用を想定して通常版に比べて2倍程度のサポート期間となる法人向け版が提供されていますが、それでも大きな企業のビジネスのスピード感からするとペースがまだまだ速すぎて、追従するのは難しいことが多いようです。 約1年に1回のペースでメジャーアップデートされる「Firefox ESR」は、そういった企業のスピード感にマッチしていて運用しやすいわけです。

Thunderbirdの歩み

Firefoxの歩みを語る中でThunderbirdについても断片的に触れてきましたが、ここでは改めてThunderbirdに焦点を当て、誕生以後の動きを紹介します。

改善の道のり

Thunderbirdは最初はNetscape CommunicatorのMessengerの後継アプリケーションとして、メールとネットニュースの表示にのみ対応し、カレンダー（スケジューラー）機能には未対応でした。 ライバル製品にあたるOutlookはメール送受信と連携したスケジュール管理・カレンダー機能を備えており、同様の機能のニーズはありましたが、カレンダー機能は「Sunbird」という名の単独のアプリケーションとして開発が進められていました。 その後、Sunbirdの成果はThunderbird用の拡張機能となってThunderbirdにバンドルされるようになり、後にXULアドオンの廃止を経て、ようやくThunderbird本体に統合されることとなります。

アドレス帳機能について言うと、法人運用におけるアドレス帳の共有は昔からニーズがあり、Netscape Communicator 4においてはLDAPベースでのリモートアドレス帳機能が実装されていました。 このLDAPアドレス帳機能はThunderbirdにもそのまま引き継がれていますが、あくまで読み込み・表示のみの対応で、追加や編集などの書き込み操作には長らく非対応のままでした。 Thunderbird 91以降ではWebDAVベースの仕様であるCardDAVに対応するようになり、読み書きを自由に行えるリモートアドレス帳機能として活用できるようになっています。

そのほか、送受信するメールを自動的に暗号化・復号する「OpenPGP」対応の統合や、メールフォルダーごとの最大容量を大幅に拡張する「Maildir」形式への対応、サイズの大きなファイルの送信時に本文に添付せずファイルアップローダーに自動的にアップロードできるようになるなど、時代を反映した様々な改善が行われています。

Thunderbirdの今後

Mozillaは現在、Firefoxとその関連プロジェクトにリソースを集中させています。 Thunderbirdの開発は2023年現在、Mozilla Foundation傘下のMZLA Technologies Corporationで行われていますが、開発リソースはFirefoxに輪をかけて非常に限られており、継続的な開発のためには開発体制の健全化は不可避です。

Firefoxと近い時期に誕生したThunderbirdでしたが、Firefoxが比較的素直な「Geckoアプリケーション」――レンダリングエンジンGecko自体が備える基本機能の上でUIレイヤーを整備したWeb技術ベースのアプリケーションとなり、新規のモジュールも基本的にはJavaScriptで実装されていったのに対し、ThunderbirdはPOP3、IMAP、アドレス帳データベースなど、Mozilla SuiteゆずりのC++による実装を多く含んでいました。 この事により、Thunderbirdは当初から、Firefoxに比べて開発に参加する上でのハードルが高い状態となっていました。

この状態を解消するための開発は以前から行われており、Thunderbird 102時点ではPOP3プロトコルの実装がJavaScript製モジュールに置き換えられました。 同様に、次はIMAPプロトコルの実装を置き換えるための作業が進行しています。 また、XULに基づいて構築された現在のUIを、よりWeb開発者に理解しやすい技術に基づいて再構築していく計画も公表されています。 これらの改善を重ねて開発参加のハードルを引き下げることで、将来的にはThunderbirdも、Firefox並のサイクルで新バージョンを提供していけるようにすることが目標として示されています。

また、デスクトップ環境とは別に、スマートフォンなどのモバイル環境向けの「Thunderbird」の提供計画も進んでいます。

とはいえ、これはデスクトップ版の移植という話ではありません。 そもそもデスクトップ環境向けのアプリケーションであるThunderbirdは、そのままモバイル環境に移植してもFirefox以上に実用性が低くなるのは明白です。 実際にはモバイル環境向けの「Thunderbird」は、すでにオープンソースのモバイル向けメールクライアントとして開発・公開されている「K-9 Mail」を「Thunderbird」にリブランドした形で提供される予定になっています。 このモバイル版では、Firefox Syncと同様の同期機能による、デスクトップ版Thunderbirdとの間での情報の同期を可能にするなどの改善が予告されています。

Thunderbirdの法人利用

近年ではGoogle WorkspaceやMicrosoft 365などのWebベースのクラウド型ソリューションの利用が広まり、Webブラウザーのみでメールの送受信まで行えるようになったことから、Thunderbirdのような単独のローカルアプリケーション形式のメールクライアントの需要は低下傾向にあります。

とはいえ、クラウド型ソリューションはサービス側の仕様に運用を合わせなくてはならない部分が大きく、自組織に特有の事情に合わせた運用を取りたい動機が強いと、クラウドではニーズを満たせないこともあります。 Thunderbirdの特長として、設定変更や拡張機能によって痒い所に手が届くカスタマイズを行える点が評価されて、全社的にThunderbirdを採用する事例は現在でもあります。 筆者の所属会社でも、法人サポートの複数の顧客から「メールの誤送信を減らしたい」「アカウント作成を容易に行えるようにしたい」など様々な要望が寄せられており、ニーズに応えるための拡張機能を開発して提供しています。

また、「巨大な添付ファイルを頻繁にやり取りする運用の都合上メールボックスが溢れやすく、メールをローカルに退避してメールボックスを空けたい」「メールの基盤をクラウドに移行したものの、移行前の時代のメールのアーカイブを参照する方法が必要」といった特殊な事情からThunderbirdが選択される例もあります。

8割9割くらいのユーザーの、8割9割くらいのニーズに応えられて、安く上がる、というのはクラウド型ソリューションの利点ですが、その陰でこぼれ落ちてしまうニーズがあるのも事実です。 かといって、そのためだけにユーザー個別の「クラウド型システム」を作り分けるのでは、あまりに高コストになってしまいます。 大企業の製品とは異なる動機・異なる形でユーザーに寄り添う、細かいニーズに現実的なコストの範囲で応えられる貴重な選択肢として、Thunderbirdには今後も存在意義を示し続けていってもらいたい、と筆者は思う次第です。

Footnotes

  1. http://inu.imagines.jp/gallery/firefox.html ↩

  2. http://inu.imagines.jp/gallery/thunderbird.html ↩

  3. 「ザナドゥ」というプロジェクトにおいて、複数の文書同士を関連付ける物として提唱しました。 ↩

  4. European Organization for Nuclear Research、欧州原子核研究機構。「シュタインズ・ゲート」で有名なあのCERNです。現実にはただの国際研究機関です。 ↩

  5. HyperText Markup Languageの略。 ↩

  6. Mosaicは雇用契約の中で開発された物であった事から、NCSAにコードの所有権がある状態でした。 ↩

  7. 東宝の怪獣映画「ゴジラ」の英語表記。 ↩

  8. Secure Socket Layerの略。今のTLS（Transport Layer Security）。 ↩

  9. Apache HTTP ServerやNginxなどの無料で使えるWebサーバーが普及し、MicrosoftのIISもWindows Serverの無料のオプション扱いになっている今からすれば驚きかもしれませんが、当時は、WebサイトをホスティングするためのWebサーバー・ソフトウェア自体を開発・販売すること自体がビジネスとして成立する時代でした。 ↩

  10. 後のWindows 2000、そしてWindows XPに至る製品ライン。当初はWindows 9xがコンシューマー向け、Windows NTがビジネス向けという分け方になっていましたが、Windows 9x系はWindows Meを最後に終了し、Windows XPからはコンシューマー向けもWindows NT系列に一本化されました。 ↩

  11. 当時はその前身として「NTドメイン」がようやく登場した段階でした。 ↩

  12. この「統合クライアント製品を前提とした企業向けサーバー製品ビジネス」はある程度の成功を収めたようで、日本でも、名の知れた大企業で2010年近くまでNetscapeのサーバー製品が稼働していて、筆者はそのリプレースに少しだけ関わりました。 ↩

  13. 例として、この頃マーケティング的に使われた用語の1つに、プラグインやJavaScript（Microsoftの場合はJScript）を使ってWebページの内容を動的に変化させていく「Dynamic HTML」があります。当時は「Macromedia Shockwave」などによる、紙芝居的な画面の部分部分に音声やインタラクションを付与した「マルチメディアコンテンツ」が流行っており、Dynamic HTMLは、それをそのままWebに持ち込んだような物でした。 ↩

  14. GNU General Public License。 ↩

  15. 今ではGitHub社を傘下に持ち、自由なソフトウェア開発のコミュニティに親和的な姿勢を示しているMicrosoftも、この頃はLinuxに対して根も葉もない風評をばら撒いて敵視していて、自由な開発のコミュニティから嫌われる企業の代表だったのです。 ↩

  16. 今では多くの人が使っている「オープンソース」という言葉は、実はこの時期に初めて作られた造語なのでした。 ↩

  17. このあたりの事実関係については、オープンソースの成立の経緯の当事者の一人である佐渡秀治氏が詳しく書かれているので、ご一読をお薦めします。 https://shujisado.com/2017/05/17/612085/ ↩

  18. 真偽のほどは不明ですが、アナウンスから実際のソースコード公開までに時間がかかった理由の1つは、そういったコメントの削除に手間取ったからだという噂もありました。 ↩

  19. ちなみに、この当時日本で初めてMozillaのコードをビルドした人と言われているのが加藤誠氏です。加藤氏はその後Microsoft社に在籍してInternet Explorerのメンテナンスを担当した後、今ではMozillaでFirefoxの開発に関わられています。 https://jp.linkedin.com/in/makoto-kato ↩

  20. 今でも、商用製品の開発終了がアナウンスされた際に「オープンソース化してくれれば誰かが引き継げるかもしれないのに」と言う人がいますが、識者がそういった意見に冷ややかな態度を取りがちな理由の1つには、このような「実際にオープンソースになっても、引き継ぐのも発展させるのも容易ではない」事実があったのを知っていて、「自分で汗をかいて引き継ぐ覚悟もないのに、誰かがやってくれるだろうという甘い考えで言っている」様子を滑稽に感じずにはいられないからでしょう。 ↩

  21. World Wide Web Consortiumの略。 ↩

  22. Cascading Style Sheetsの略。 ↩

  23. Document Object Modelの略。 ↩

  24. Extensible Markup Languageの略。 ↩

  25. こうしてMozillaのブラウザーはレンダリングエンジンを刷新しましたが、すべての実装が置き換えられたわけではありませんでした。具体的には、画面描画に直接的には関係しないネットワークとの通信周りのモジュールなどは、元の物がそのまま使われ続けました。現在でも、Firefoxの中にはGeckoエンジン導入以前から引き継がれているコードが残っています。 ↩

  26. Extensible User-interface Languageの略。 ↩

  27. 今でこそMicrosoft 365のWeb UIやGmailをみんな当たり前に使っていますが、当時はこれも革新的だったのです。 ↩

  28. 実は、この拡張性の高さは偶然の産物で、元々の設計時点で意図されたものではありませんでした。 ↩

  29. 漢字の読み仮名などを小さな字で表示するあれです。 ↩

  30. 彼はGeckoエンジンを使ったMac用Webブラウザーの「Chimera（Camino）」の開発にも参加し、さらにSafariの開発チームへ移籍しました。これらのブラウザーのツールバーに共通する「パレットから項目を好きな位置にドラッグ＆ドロップで配置できる」仕組みは、元々は彼がCaminoで実験的に導入し、Phoenixに持ち込んで、Safariにも引き継いだ物です。 ↩

  31. ベン・グッジャー氏の述懐記事 https://web.archive.org/web/20111116060139/http://weblogs.mozillazine.org/ben/archives/009698.html によると、様々な横槍によって迷走を続けるMozillaブラウザーのひどいUIに嫌気がさした人達による、少数精鋭メンバーだけでの「ブラウザーUIの作り直し」の計画は、2001年には動き出していたそうです。 ↩

  32. FirefoxとThunderbirdの実装はオープンソースですが、「Firefox」と「Thunderbird」の名称やアイコンはMozillaが商標権を持っています。そのため、公開されているソースコードに改変を加えた物を「Firefox」や「Thunderbird」という名前で提供すると、商標の無断使用となってしまいます。そのためDebianのリポジトリにおいては一時期、Firefoxは「Iceweasel（氷のイタチ）」、Thunderbirdは「Icedove（氷の鳩）」という名前で、アイコンも別の物に差し替えられて収録されていました。 ↩

  33. FirebirdとThunderbirdで韻を踏んだネーミングだったのですが、Firebirdの方が「Firefox」に改称した結果、Thunderbirdの方だけ取り残されてしまった形です。 ↩

  34. 先程の飲食店の例えで言うなら、Firefoxは「調理場を客に開放した、美味いラーメン屋」といった所でしょうか。「普通に注文して食べたいだけの客」も「料理の心得があって好きな物を食べたい客」も「ついでに他の客にも料理を振る舞いたい客」も利用できる、そんな新しい選択肢の出店に心を躍らせる人達が集まり始めたのでした。 ↩

  35. この変化の仕方から、「Microsoftは、ライバルからシェアを奪うまでは物凄く頑張るが、一度シェアを奪いきったら途端に怠惰になる」という揶揄もよく聞かれました。聞く所によると、当時IEの開発に関わっていた人員の多くは他の場所に配置換えされ、ほんの数名だけが細々と延長サポートの対応に従事していたといいます。 ↩

  36. 例えば携帯端末だと、2007年発表の初代iPhoneより以前の当時はいわゆるガラケー（ガラパゴスケータイ：スマートフォンの1世代前に日本で普及した携帯電話）が広く使われていましたが、ガラケー搭載のWebブラウザーはPC用Webブラウザーよりも色々と厳しい制約がありました。 ↩

  37. そのような協力関係の元に成り立つ機能の1つに、マルウェアやフィッシング詐欺の遮断があります。これらの機能は「既知の危険なWebサイトの一覧」を遮断リストとして使いますが、このリストは元々はGoogleツールバーの「Safe Browsing」機能のための物でした。Safe Browsing用のリストを用いた警告機能は、最初はFirefox用拡張機能のGoogleツールバーで提供され、後にFirefox本体に内蔵されるようになります。 ↩

  38. Firefoxの開発をリードしていたベン・グッジャー氏やダリン・フィッシャー氏らをGoogleが「引き抜いた」ということから、「Googleは自社でWebブラウザーを開発しようとしているのではないか？」と当時話題になりました。 https://japan.cnet.com/article/20111747/ ↩

  39. マウンテンビューは田舎町で、付近に食事を取れる場所があまりなく不便なため、こういった福利厚生は切実に必要とされていたのです。筆者も、2006年にMozilla Japanの方々に帯同して現地を訪問した際には、Googleキャンパスのラウンジで食事を取らせてもらいました。 ↩

  40. 実際に、Visual Studio Codeはそうなっています。 ↩

  41. 何せGoogleは当時ユーザーから圧倒的な支持を得ていましたから、仮にそれが多少使いにくい物であったとしても、Googleが「これが良い」と言って打ち出せば、大多数のユーザーは「Googleがそう言うならそうなんだろう、使いにくいと感じるのは自分の方が悪いんだろう」と思い、素直にGoogleの決定を受け入れるに違いありません。 ↩

  42. Resource Definition Frameworkの略。XMLで様々な情報を定義するための汎用的な仕組み。後に、Firefox内部でその役割はJSONによって置き換えられました。 ↩

  43. XML Binding Languageの略。今で言うShadow DOMを、XML形式の定義ファイルで実現する仕組みです。 ↩

  44. Cross-platform Component Object Modelの略。JavaScriptとC++の実装の間を橋渡しし、ローカルファイルへのアクセスなどのネイティブ寄りの機能を提供するモジュールをJavaScriptから呼び出せるようにする仕組みです。 ↩

  45. 調理場を使わせてもらえる飲食店に例えれば、「使いたければ使っていいよ」とは言われていても、ほとんど説明も無しに新しい食材や調理器具がどんどん増えていくような状況です。 ↩

  46. 筆者自身は、Firefoxの変化に合わせて少しずつ把握する情報の範囲が増えていったことから、当時の拡張機能を日常的にメンテナンスしていた頃には特にハードルとは感じていませんでしたが、数年のブランクを経てこの頃の拡張機能に再度手を入れようとした際には、あまりの資料の無さ・難解さに途方に暮れてしまいました。 ↩

  47. Firefox User Extension Libraryの略。Firefox 1.5から実装されました。また、Thunderbirdには同様の役割の「STEEL（Scriptable Thunderbird Easy Extension Libraryの略）」が用意されました。しかし、本文に記したとおりFUELは充分には活用されず、結局Firefox 47で廃止されてしまいました。 ↩

  48. 飲食店の例えで言えば、開放された調理場で他の客向けの料理をつまみ食いし放題なのを善意に任せて無対策のままでいたり、良かれと思って客が持ち込んだ食材で食中毒が起こったりするようなものです。 ↩

  49. 当初は将来に渡って互換性が保証されると思われていたChromeの拡張機能APIですが、Googleは2020年に、それまでのAPI仕様「Manifest V2」の廃止と機能面で一部後退が見られる新仕様「Manifest V3」への移行の予定を発表しました。Manifest V3では広告ブロックに使われることの多いAPIが狙い撃ち的に廃止されると受け止められたこと、Google自体が広告ビジネスによって収益を得ていることから、この発表は広告ブロック系拡張機能の実質的な締め出しを意図したものではないのかと反発を受けることとなり、Manifest V2の完全廃止の予定は当初スケジュールから延期が繰り返される状況となっています。 ↩

  50. これをまた飲食店に例えるなら、Chromeは「トッピングを選んだりテーブル調味料で味変したりできる、オシャレで美味いラーメン屋」といった所でしょうか。美味しい物を食べたい客も、店の雰囲気を求める客も訪れるし、トッピングの組み合わせのお薦めを客同士で教え合うこともできる。Firefoxほどの自由度を特に求めていなかった客層にとっては、このくらいの気軽さの方が魅力的に感じられたわけです。 ↩

  51. 事前コンパイル型の処理系と異なり、最終的な実行環境そのものでコンパイルされることから、JITには事前コンパイルよりも優れた最適化にも期待できるという利点もあります。 ↩

  52. 当時のJITは単純に関数単位でコンパイル・最適化する方式が多かったようですが、この時採用されたのは、インタープリタでの実行状況を監視して高頻度で実行されるコードパスをコンパイル・最適化する「Tracing JIT」方式でした。より高度な最適化を行うTracing JITは、当時のコンパイラ業界的にも目新しい技術として注目されたようです。 ↩

  53. FirefoxはUI周りがJavaScriptで実装されていることから、単にWebコンテンツの利用が快適になる以上の効果が期待されました。ただ、この成果は製品としては2009年6月リリースのFirefox 3.5から利用可能になりましたが、実際には期待されたほどの劇的な性能改善とはなりませんでした。これは、DOMオブジェクトやXPCOMコンポーネントオブジェクトなどが関係する処理に対してTracing JITが有効に機能しなかったことが原因だと言われています。 ↩

  54. この時のV8の実装は、最適化は特に行わずに、実行前の時点でプログラム全体を効率よくコンパイルする方式でした。「全体を実行前にコンパイルする」なら「事前コンパイル」じゃないのか？と思うかもしれませんが、JavaScriptのソースコードがダウンロードされ読み込まれた「まさにその時」にコンパイルするため、これもJITということになります。なお、プログラム作者の側でソースコードをコンパイルしたバイナリを配布すれば、それは事前コンパイル型ということになります。 ↩

  55. この節全体を通して、あたかもJIT自体が最新技術であったかのように書いていますが、実際には、JITはこの当時既に他の言語処理系で採用されていました。識者にとっては、JavaScriptに持ち込まれるのも時間の問題と見られていたようです。 ↩

  56. Chromeの初版リリースは2008年9月でした。Firefoxユーザーにとっては、「次版のFirefoxで利用可能になると予告されたばかりの新技術」を備えた製品がライバル製品で、それも即座に利用可能な状態でもたらされた形だったので、その衝撃は一層大きかったのでした。また、当時のSpiderMonkeyが「一部をコンパイルして、且つ最適化もする」アプローチを取っていたのに対して、この時のV8が「最適化はしないが、全体をコンパイルする」という、ある意味対照的なアプローチだったことも印象的でした。 ↩

  57. これらの最適化の成功は2008年9月にアナウンスされましたが、その時点ではあくまで開発版でのことで、実際の製品としてユーザーの手に届いたのは2009年6月リリースのSafari 4.0からでした。 ↩

  58. その後も各ベンダーでそれぞれに改善が重ねられた結果、現在ではV8だけが突出している状況ではなくなっており、ベンチマークの指標によっては他のエンジンがV8より高性能を示しているケースもあります。当初は各ベンダーで大きく異なったアプローチが取られていましたが、現在では、当時のV8のような「全体をコンパイルする」処理をSpiderMonkeyも取り入れたり、当時は未搭載だった実行時最適化をV8も取り入れたり、はたまた、他ベンダーの実装自体を部分的に引用しあったり、エンジンの内部的な作り自体を抜本的に見直したりもして、「出揃った様々な要素技術をどう組み合わせて性能を向上するか」という次の段階の競争にシフトしているようです。 ↩

  59. 独自のレンダリングエンジン無しの「Firefox」を使う意味があるのか？と疑問に思われるかもしれませんが、閲覧履歴や保存済みパスワードなどを端末間で同期する機能「Firefox Sync」を使用する事で、デスクトップ環境のFirefoxとiPhoneとの間で情報を連携しやすくなるメリットはあります。 ↩

  60. MozillaによるFirefox OSの開発が終了した後、Firefox OSのコードベースは派生プロジェクト「KaiOS」に引き継がれました。KaiOSは格安の端末のOSとして使われたことで、2019年頃にはインド地域などにおいてiOSに並ぶシェアを得ていましたが、2023年現在は大きなシェアの獲得には至っていないようです。 ↩

  61. 拡張機能の提供する関数が上書きしてしまったFirefoxの元々の関数や、拡張機能が削除してメモリ上から破棄してしまったUI要素などは、Firefoxを再起動する以外の方法では復元のしようがありません。 ↩

  62. 少なくとも筆者は最初はそうでした。 ↩

  63. 先の「調理場を開放していた店」に例えれば、WebExtensionsは「調理場を使わせてくれていたあの店が、定型のトッピングの提供も始めた」ようなものでした。料理の腕を自在に振るっていた常連客達や、それ目当てだった常連客達にとっては、新しいやり方はあまり魅力的には感じられませんでしたが、料理の心得がない新規の客も、メニューに書かれたトッピングの組み合わせだけで好みの味を模索できるようになり、店としては今までより広い客層を受け入れられるようになったわけです。 ↩

  64. 先の「調理場を開放していた店」の例えで言えば、今まで調理場で腕を振るってきた常連客や、それ目当てで来ていた常連客によって支えられてきた店が、「定型のトッピングを提供し始めた途端、急に調理場を立ち入り禁止にした」ようなものです。 ↩

  65. 先の飲食店の例で言うと、店としてはもう調理場を自由に使わせられないけれど、今まで振る舞われていた料理に近い体験はできるようにしておいてあげたい、腕を振るっていた常連客が、定型のトッピングの組み合わせの範囲での工夫次第で、狙った通りの味の料理も作れるようにしておきたい、という状況です。APIへの機能追加は、トッピングの種類の拡充にあたります。 ↩

  66. 1年に1回開かれる、Mozillaプロジェクトの世界中のメンバーが一堂に会して議論や報告をする会。 ↩

  67. Add-on SDKなど、まだ残っていたXULアドオンのための仕組みはこの時すべてまとめて廃止されました。 ↩

  68. MozillaはXULアドオンを廃止しましたが、XULアドオンをどうしても使い続けたかった人達がいなくなったわけではありません。そのような人達の中で、Firefoxをフォークした派生Webブラウザーの開発プロジェクトにおいて、XULアドオン廃止前のバージョンであるFirefox 56まででコードベースの追従を停止するものもありました。Firefox 56ベースのWaterfoxは、Firefoxに行われたセキュリティアップデートをバックポートする形で維持されているようですが、Firefox 57以後に行われた新機能には対応できないため、年々実用は厳しい状況となっていっていると考えられます。 ↩

  69. 調理場を使えていた飲食店の例えで言えば、これは料理を振る舞っていた客の立場からすると、「調理場の開放が終了したので、以前のレシピは封印した上で、トッピングの組み合わせだけで似た味を再現するしかなくなった」ような状況です。 ↩

  70. 「この事がFirefoxの凋落を決定づけた、FirefoxはXULアドオンを残すべきだった」「それまでのユーザー層と一蓮托生で消えていく運命だったとしても、Firefoxは既存ユーザーに寄り添い続けるべきだった」と考える人もいますが、営利企業とは異なる視点からWebの在り方に影響を及ぼせる最後の独立系ブラウザーとして、緩慢な自殺を選ぶ道はあり得なかったと筆者は思っています。とはいえ、決断があまりに遅すぎて、遅きに失した感は否めませんでした。人気の絶頂の中で、将来を見越してあえてその時点での人気の源泉となっていた拡張機能の互換性を損なう英断を下せるような、強力なリーダーシップが本来Firefoxには必要だったのかも知れません。 ↩

  71. Servoの開発には、それ以前からMozilla内で実験的に開発されていた、メモリーの取り扱いが元での脆弱性発生の温床となっていたC/C++を代替するための新しい言語「Rust」が使われることとなり、Servoの開発の進展とともにRust自体も開発が進んでいきました。後にServoとRustの開発プロジェクトはMozillaから切り離され、ServoはLinux Foundation傘下のプロジェクト、Rustは独立したコミュニティによる開発プロジェクトとなっています。 ↩

  72. IT業界で強い影響力を持つ大企業のこと。Google、Amazon、Microsoft、Apple、Metaなどを指します。 ↩

  73. 営利企業であるGoogleやAppleは、突き詰めると経済的な利益を最大化することが求められる存在で、ユーザーをなるべく多く囲い込むモチベーションがあります。コンテンツ業界との関係を保つためにも、ユーザーによるコンテンツの「自由な利用」を禁じるDRM（デジタル著作権管理）を手放せませんし、広告事業が柱であるGoogleは特に、行動ターゲティング広告枠の販売のために、利用者のプライバシー情報の収集を完全には放棄できません。そういった事情を持つ企業が開発を主導するプロジェクトにおいては、最終的な決定でユーザーの都合より事業の都合が優先されることがままあります。その一例に、Googleが発表したChromeの拡張機能の新API仕様である「Manifest V3」の取り扱いが挙げられます。Googleはコミュニティからの強い反発を押し切って、機能的な後退を含む「Manifest V3」への移行を推し進めていますが、それに対してMozillaは、機能的な後退無しに代替する方法を確立できるまでの間、従来のAPIの機能を完全廃止はしない旨をアナウンスしています。 ↩

  74. 過去形なのは、Mozilla Japanという組織がなくなってしまったからです。Mozilla製品の法人向けサポート事業自体は現在も継続しています。 ↩

  75. Mission Control Desktopの略。 ↩