“Rediscover the Web”
――「Webを再発見する」。このキャッチコピーのもと、満を持して2004年11月9日、Mozilla Firefox初の正式版となるバージョン1.0が公開された。Firefoxの擬人化キャラクター「Firefox子（ふぉくす子）」、そしてその姉妹分であるThunderbirdの擬人化キャラクター「Thunderbird子（さんだば子）」をinugamix氏※が世に送り出したのは、それに先立つこと半年も前※だった。当時FirefoxがいかにWeb関係者の注目を浴びていたかが窺い知れる。 Webの歴史は、ブラウザーの進歩の歴史と表裏一体だ。数あるブラウザーの中でもFirefoxは、Web黎明期を切り拓き、オープンソースという言葉の誕生の契機ともなった、レジェンド的ソフトウェアの直系に位置する。Firefox、そしてThunderbirdが20周年の節目を迎えた今、「彼女ら」を通してWebとブラウザーの歴史を振り返ってみよう。
※絵師・inugamix（犬神）氏：日本のWebにおいてまだCSSの使用が一般的でなかった2000年代に、個人Webサイトで全面的にCSSを導入していた一人。理念・技術先行で同様の試みをし、論争に明け暮れる人が多かった中で、作品公開のための「道具」としてスマートにCSSを活用する氏の在り方は、Web技術活用の1つのモデルケースと言えた。Webサイト：画廊犬神堂（http://inu.imagines.jp/）
※キャラクターの誕生：Firefox子のデザイン画初公開は2004年4月5日、Thunderbird子のデザイン画初公開は2004年5月9日である。
Moezilla Historica
第1章 Firefox前史 6 第2章 第二次ブラウザー戦争 33 第3章 Firefoxの機能の進歩 56 ふぉくす子テーマコレクション 76 第4章 Thunderbird 92 第5章 Firefoxとコミュニティ 107
参考文献 116
※本書の記述は参考文献を含む公開情報に基づきますが、紙幅の都合による省略や、筆者の主観的解釈が含まれます。読み物としてではなく事実関係を正確に把握するための資料として参考にする際は、一次情報を探すためのキーワードの資料集としてお使いいただくことをお勧めします。
■World Wide Webの誕生とNetscape Webの歴史は、テッド・ネルソン※が提唱した「ハイパーリンク」の概念にまで遡れる。文書と文書を結び付けて辿れるようにするハイパーリンクの1つの実装として、ティム・バーナーズ＝リー※がCERN※内での論文データベース構築のために1989年頃から作り始めた仕組みが「WWW（World Wide Web）」だ。ソフトウェアとしてのWWWは文書作成ツールと文書閲覧ツール（ブラウザー）が一体となっており、文書は「HTML（HyperText Markup Language）」というマークアップ言語※で記述する形式だった。HTMLの仕様は1991年にCERN内で公開され、大学間のネットワークとして既に稼働していたインターネットを通じて、瞬く間に世界中の研究者へと広まった。 論文データベースのために作られたWWWとHTMLは、当初は単純な文書しか表現できず、装飾もほとんど行えなかった。このことに不満を持ったマーク・アンドリーセン※らは、仕様を独自に拡張して「imgタグ」などのビジュアル要素を独自に実装したブラウザー「Mosaic」を開発し、1993年に公開。当時すでに様々なブラウザーの実装があったが、その中でも性能の良さや見た目の華やかさから、Mosaicは特に好評を博した。
だが、Mosaicの覇権は長くは続かなかった。勤務中の開発だったためにMosaicの所有権は雇用主のNCSAにあったため、マークらは思うようにMosaicの開発を行えないくなっていったのだ。1994年、業を煮やした彼らはMosaic Communicationsを起業して独立。Mosaicを上回る性能を持つ新ブラウザーを「Mosaicを打ち倒すもの」としてMosaicとGodzilla※からの造語・Mozillaと名付けて開発を始めた。ほどなく社名の「Mosaic」の権利を巡ってNCSAに訴訟を起こされ、社名をNetscape Communicationsに変更。ブランディングの都合でブラウザーもNetscape Navigatorに改称し、以後、Mosaicの名はあくまで内輪の製品コードネームとして生き続けるに留まることとなる。 Javaアプレット※やJavaScript※の埋め込みを可能にし、静的コンテンツだけだったWebに動的コンテンツを持ち込んだNetscape Navigatorは、性能的にも表現力的にもMosaicを大きく上回っていたため、有償での販売ながら、すぐに市場を席巻した。また、同社は当時まだ物珍しかった「インターネット上での商取引」に目を付け、注文や決済を安全に行うための電子署名と暗号化通信の技術・SSL※を開発し、ブラウザーに組み込んだ上で、対になるSSL対応のWebサーバー製品※を企業向けに売り込んだ。 こうして、NetscapeはWebに大きな影響を及ぼすようになり、「インターネットといえばNetscape」と言われるほどの大成功に至ったのである。
※テッド・ネルソン（Theodor Holm Nelson）：アメリカの社会学者。1960年代、当時主流の紙の文書では不可能だった文書同士の相互参照や課金システムなどまで含む壮大な計画「ザナドゥ計画」を立ち上げた。
※ティム・バーナーズ＝リー（Timothy "Tim" John Berners-Lee）：イギリスの計算機科学者。WWW以外にURL、HTTPなどの関連技術も開発した。後にWWW発明の功績から、大英帝国上級勲爵士の称号をエリザベス女王より授与された。
※CERN：European Organization for Nuclear Research、欧州原子核研究機構。
※マークアップ言語：指示を手続き的に記述する「プログラミング言語」とは異なり、文書内の個々の部分に「タグ」を付けることで意味や役割を明示するデータ記述言語。
※マーク・アンドリーセン（Marc Lowell Andreessen）：1993年当時、イリノイ大学のNCSA（National Center for Supercomputing Applications、米国立スーパーコンピュータ応用研究所）に在籍しソフトウェアエンジニアとして勤務。後に起業し、2024年現在はベンチャーキャピタルの運営者となっている。
※Godzilla：東宝の怪獣映画「ゴジラ」のこと。
※SSL：Secure Socket Layer。現在のTLS（Transport Layer Security）の前身。
※Java：Java VM（Virtual Machine：仮想マシン）上で実行される事を前提としたクラスベースのオブジェクト志向プログラミング言語。Webページ内に埋め込む形で実行する物をアプレット、サーバー上で実行する物をサーブレットと呼ぶ。アプレットの実行にはJavaプラグインを必要とする。
※JavaScript：NetscapeがWebページへの組み込み用に開発したプロトタイプベースのオブジェクト指向スクリプト言語。開発初期はLiveScriptと呼ばれていたが、Javaの開発元であったSun MicrosystemsとNetscapeが提携していたことから、Java人気にあやかるべく名称を「JavaScript」と改めた。ブラウザー非依存の基本部分の仕様はECMAScriptの名で標準化されている。
※NetscapeのWebサーバー：製品名はNetscape NetSite Web Server。現代ではApache HTTP ServerやNginx、MicrosoftのIISなどの無料で使えるWebサーバーが普及しているが、この当時は、Webサーバー・ソフトウェアを開発・販売すること自体がまだビジネスとして成立していた。
■第一次ブラウザー戦争 ブラウザーと企業向けサーバー製品を事業の2本柱として歩み始めたNetscapeは、さらに事業を拡大する。Netscape Navigator 3では同社製メールサーバーと対になるメールクライアント機能やWebページ制作用のHTMLエディター機能を追加した上位版「Netscape Navigator 3 Gold Edition」を投入。同社のサーバー製品にはブラウザー製品のライセンスも付属しており、企業での仕様が促進されたこともまた、Netscapeのブラウザーのシェア拡大に寄与した。
こうして大成功するNetscapeを追う者の影があった。IT業界の巨人、Microsoft※である。 1995年、NCSA MosaicのライセンスをSpyglass社経由で購入して改良する形でブラウザー「Internet Explorer」を開発し、Windows 95の追加パッケージの一部として販売し始めた。IE2まではせいぜいおまけレベルの出来だったものの、改良に次ぐ改良により、ついにバージョン3に至って、IEは機能面でも性能面でもNetscape Navigatorに比肩しうる存在となる。 Netscape一強の時代が終わり、NetscapeとMicrosoftの一騎討ち※による熾烈なシェア争いが始まった。後の世に言う「第一次ブラウザー戦争」の幕開けである。
ソフトウェアの競争は、機能強化による差別化で行われるのが常だ。Netscapeは、ビジネス利用への訴求を狙った改良をさらに進めた。 1996年当時のPC向けOSの主流だったWindows 95はシングルユーザー前提で、大企業での運用で求められる、ユーザーの情報や設定を集中管理するための仕組みを持っていなかった※。そこでNetscapeは大量のユーザー情報を管理するディレクトリーサーバーや、スケジュール管理、プロキシー、認証サーバー、クライアントPCの設定の配布・管理サーバーといった多種多様なサーバー製品群を投入。それらと連携するクライアント製品として「Netscape Navigator Gold Edition」を大幅にリブランディングし、Webブラウザー「Navigator」を中心として、ディレクトリーサーバーを利用したアドレス帳をも含むメールクライアント機能、HTMLエディター機能※に加え、独自の複数ユーザー管理機能も統合し、サーバー製品との連携による設定の集中管理機能に対応した多機能製品の「Netscape Communicator 4」を、新世代のビジネス用クライアント製品として打ち出した※。
またNetscape Communicator 4では、テキストを点滅させるや、コンテンツの重ね合わせ表示を可能とする、表示をスクリプトで制御するJSSS（JavaScript Style Sheets）など、いわゆる「マルチメディアコンテンツ」※並のリッチな表現力をWebページに与える機能強化も行われた。 これに対抗し、MicrosoftもInternet Explorer独自の動的コンテンツ機能として、別のWebページを埋め込む<iframe>や、CSSでWebページ内の任意の要素の重ね合わせ表示を行うpositionプロパティ、Webページ内の全構成要素をスクリプトで制御するためのdocument.all、Windows向けバイナリーをWebコンテンツに直接埋め込むActiveXなどを実装※。両者が導入したこれらの技術に基づくWebコンテンツは「Dynamic HTML」と呼ばれ、Webコンテンツの世界を大きく発展させたものの、双方で互換性のない独自仕様の乱立は囲い込み合戦の様相を呈し、Webコンテンツ制作者や一般ユーザーはブラウザーベンダー同士の争いの中で大いに翻弄されることとなった。
※Microsoft：1975年創業。コンピューター向けOSや各種アプリケーションを開発・販売するソフトウェアメーカー。MS-DOS、およびその後継となるWindowsによってPC向けOS市場の覇者となった。
※一騎討ち：実際には、個人の開発者や小規模ベンダーによるブラウザーも存在していた。タブブラウズ機能をいち早く実装して独自の立ち位置を築いたOpera、Mac専用のブラウザーのiCab、ソフトウェアとしてのWorld Wide Webの流れを汲むテキストブラウザーのLynxなどが代表例。
※Windowsの集中管理：Windows 95の上位製品である「Windows NT」はビジネス向けとして、Active Directoryの前世代の技術「NTドメイン」によるユーザー情報の集中管理に対応していたが、当時は普及度が低かった。
※Netscape Communicator 4のメールクライアントとHTMLエディター：それぞれ「Messenger」「Composer」と名付けられた。
※Netscapeの統合クライアント製品を前提とした企業向けサーバー製品：このビジネスはある程度の成功を収め、日本でも、名の知れた大企業で2010年近くまでNetscapeのサーバー製品が稼働していた。
※マルチメディアコンテンツ：テキスト、画像、音声、動画などを組み合わせて、ユーザーの操作に動的に反応するように作られた動的コンテンツ。ゲームの「ダンガンロンパ」シリーズや「艦これ」「Fate/Grand Order」などの画面構成は、当時のマルチメディアコンテンツの発展形と言える。
※IEの独自拡張仕様：仕様としてこなれていたため、CSSやDOMなど後に普及するWeb標準仕様はIE発の仕様の発展形が多い。
■戦争の終結 競争が激化の一途を辿る中で、Microsoftは1997年、「IE4とWindowsの統合、各種サーバー製品の無償化」を打ち出した。大企業向けにWindowsの強化を進めると同時に、サーバー製品群やメールクライアント・Outlookの投入などで製品ラインナップも拡充し、それらを武器に「Windowsのライセンスを買いさえすれば、そのオプション機能としてサーバー製品もブラウザーもメールクライアントも無償で使えるから、わざわざNetscape製品を買う必要がない」状況を作り出して、クライアントとサーバーの両市場のシェアを根元から押さえる戦術をとったのである※。
WindowsへのIE統合の効果はてきめんだった。急速なシェア下落に、NetscapeはNetscape Communicator 4の全面的な無償配布に踏み切った※ものの、凋落の勢いは止まらなかった。 IEがIE5、IE6と順調に進歩を重ねる一方で、NetscapeはNetscape Communicator 4でのコードの肥大化・複雑化が足枷となり、性能向上や新機能の搭載といった目に見える革新を示せずにいた。それどころか、インターネットの利用拡大に伴ってWebページのリッチ化が進んだ結果、コンテンツのデータ量が増加し、ユーザー体験は悪化の一途を辿っていた※。「普通にNetscape製品よりIE5やIE6の方が快適」、それが当時の一般ユーザーの感覚であった。
次世代の新製品「Netscape Communicator 5」の開発が遅々として進まなかったNetscapeは、1998年、事態を打開するべく起死回生の一手に出た。開発中の次世代製品のソースコードを一般向けに公開したのである。
※WindowsへのIEの抱き合わせ戦術：この商法はOSベンダーとしての地位を利用して競合製品を不当に排除する物だとして、後に独占禁止法に基づく訴訟を提起された。
※Netscape Communicator 4の無償化：当時すでに、Netscapeはサーバー製品の付属物としてNetscape Communicator 4の使用権をばらまいており、実質無償で使用するのは容易な状況だった。無償化の発表は、その現実を追認したものと言える。
※ユーザー体験の悪化：当時のNetscape製品は仕様・性能上の制限により、Webページ全体を
で段組レイアウトしていた場合に、ページの内容がすべて読み込まれるまで真っ白な画面を眺めて何十秒も待たされる事態が頻発していた。■Mozillaと オープンソースの誕生 折しも、世はLinux※ブームが高まりを見せていた頃。リーナス・トーバルズという個人の開発者が趣味で開発しソースコードを公開したオモチャのようなOS※が、大勢の人達によってたかって改良され、ついにはUnix代替の実用品として製品化する起業まで現れ始めていた。「企業がコストをかけて作るからこそ良い製品が生まれる」という常識に反して、フリーダムなムーブメント※の中から実用に足るものが出てきた事実は、ソフトウェア業界において衝撃をもって受け止められていた。 これを自社のビジネスを脅かすものとして危険視するMicrosoftのような企業がある※一方で、コミュニティによる自発的な改良が低コストで高品質な製品を実現するために役立つと考えて接近を図る企業もいた。Netscape Communicator 5のソース公開は、この潮流の中で行われた決断だった。
1998年当時、そのようなムーブメントはfree software（フリーソフトウェア、自由なソフトウェア）と呼ばれていた。しかし、「free」から想起される「無料」の印象や、GNUのフリーソフトウェア運動につきまとう共産主義的な印象などから、ビジネスの世界で活用する上では不都合を感じる者も少なくなかった。そこでNetscapeを含むソフトウェア企業や開発コミュニティの面々が集まり議論して作られたのが、「オープンソース」という新しいブランディングだった※。 「フリーソフトウェア運動」から政治的な臭いを取り除いたワードである「オープンソース」を旗印に、ソフトウェア開発コミュニティとソフトウェア開発企業は、より連携を強めていくこととなった。
NetscapeはNetscape Communicator 5のソースコードをオープンソース化するにあたり、企業とコミュニティの間に立つ存在、Netscapeのコミュニティ側窓口としてMozilla Organization（mozilla.org）を設立。長らくコードネームとしてのみ知られてきたMozillaの名は、ここで改めて世の表舞台に姿を現したのだ。
ソースを公開された開発版のNetscape Communicator 5は、コードネームをSeamonkey※、一般名をMozilla Suite※しくは単にMozillaブラウザー※と言った。
コミュニティによる改善が期待されてのオープンソース化だったが、実際の所、思惑通りには事は進まなかった。まずもって、Mozillaブラウザーのソースは公開を前提にしていなかったため、アナウンスから実際の公開までに時間を要した※。また、Netscapeの社内インフラ上でのビルドを前提としたソースは、一般の開発者がビルドするだけでも一苦労だった。歴史が積み重なった秘伝のタレの集積は、いわゆる技術的負債と化しており、外部の開発者が容易に手を出せるものではなかったのである。Netscapeや開発者コミュニティの期待とは裏腹に、製品の改善は遅々として進まなかった。
※Linux：1991年、GPL（GNU General Public License）の下で公開。Unixとある程度の互換性があるPC用OSとして人気を博す。Linux自体はOSの中枢部分（カーネル）のみの存在であり、実用にはそれ以外の要素を別途用意する必要がある。一般に「Linux」と呼ばれているものは、LinuxカーネルにUnix互換のソフトウェア類を組み合わせた「Linuxディストリビューション」である。
※フリーダムなムーブメント：1983年頃、ライセンスによって再利用が妨げられる不自由なソフトウェアを、自由に再利用できるソフトウェアで代替することを目指して、リチャード・ストールマンはGNUプロジェクトを開始した。GPLは、GNUにおいて自由に再利用できるソフトウェアを公開するためのライセンスとして作られた。
※MicrosoftとLinux：今ではGitHub社を傘下に持ち、自由なソフトウェア開発のコミュニティに親和的な姿勢を示しているMicrosoftだが、この頃はLinuxを危険視し過度な悪評をばら撒いていたために、自由なソフトウェア開発を志すコミュニティとは敵対していた。
※オープンソース：GNUの「フリーソフトウェア」が「ソフトウェアを自由に改変・再利用できる状態を保つために必要なソース公開」であるのに対し、「オープンソース」は「ソフトウェアの品質を高めるために有用なソース公開」と言える。この違いのため、「フリーソフトウェア」は改変後のソースを秘匿しにくくすることが奨励されるのに対し、「オープンソース」は改変後のソースの秘匿もまた1つの選択肢として許容する傾向がある。オープンソースは一般名詞ではなく、この時に作られた造語である。
※シーモンキー：水生の小型甲殻類の一種であるアルテミアがペット用として販売された際のブランド名に由来。
※Suite（スイート）：求められる様々な物を一揃い備えること。ホテルの「スイートルーム」もこの意味。ブラウザー、メールクライアント、HTMLエディターといった複数機能を備えたNetscape Communicatorは「ブラウザー・スイート」である。同様に、ワープロ、表計算、図表作成などの複数機能を備えた「Microsoft Office」や「LibreOffice」は「オフィス・スイート」と呼ばれる。
※Mozillaブラウザー：実際には単に「Mozilla （バージョン番号）」と呼ばれることが多かった。また、後にブラウザー・スイートでない単体のブラウザーであるPhoenixが登場したことにより、レトロニム的にMozilla Suiteと呼ばれるようになった。
※ソースコード公開の遅延：見るに耐えない罵詈雑言のコメントなどを取り除くのに手間がかかったため、との噂もあった。
■Web標準技術と Geckoエンジン 停滞の中で1998年末、Mozillaプロジェクトに1つの新しい風が吹き込まれる。NGLayout、後にGeckoと呼ばれる新レンダリングエンジン※である。当時のNetscape Communicator 4由来のレンダリングエンジンが、機能面でも性能面でIEのレンダリングエンジン・Tridentの後塵を拝していたのに対し、Geckoはこの時点ですでに、IEを上回る高機能・高性能、そして最新のWeb標準への対応をも実現していた。
誕生当初は環境を問わない情報共有に期待されたWord Wide Webだったが、NetscapeとMicrosoftの囲い込み戦略の結果、Webには「特定ブラウザー用のコンテンツ」が溢れ返った。理想とはほど遠い分断の時代である。 WWWの技術仕様をとりまとめる標準化団体・W3C（World Wide Web Consortium）は、この状況を改善し「閲覧環境やユーザーの状況を問わず誰でも安定して利用できるユニバーサルなWeb」を実現するべく、各ブラウザーの独自拡張をベースに中立な仕様をまとめ上げた上で、さらに先進的な機能をも盛り込んだ新たなWeb標準技術仕様を策定していった※。実装よりも仕様が先行する形で策定されたために、ブラウザーの対応が追いつかず「絵に描いた餅」の状況が続いていた新しいWeb標準仕様だったが、Geckoエンジンは、それらを一気に現実へと引き寄せた。 既存のソースの技術的負債の膨大さに苦しんでいたMozillaは、高い性能と表現力を持つGeckoを手に入れ、事ここに至り、Netscape Communicator 5のソースの大部分を破棄してGeckoベースでの作り直しを決断した※。
※レンダリングエンジン：HTMLやCSSなどを解釈し、画面上に描画して、ユーザーの操作に応じて表示を更新する、ブラウザーとしての根幹をなすモジュール。
※新たなWeb技術：この頃策定された代表的な技術仕様として、HTML4、XML、XHTML、CSS2、DOMなどがある。
※Geckoベースでの再出発：すべての実装を置き換えたわけではなく、ネットワークとの通信周りのモジュールなどは、元の物をそのまま使い続けた。現在でも、Firefoxの中にはGeckoエンジン導入以前から引き継いだコードが部分的に残っている。
■Web技術ベースの アプリケーション Geckoベースでの再開発にあたり、Mozillaは野心的な設計を取り入れた。「ブラウザーのUIそのものをGeckoエンジン上で動かす」という考え方だ。GUIの基本構造をXMLベースの言語であるXUL※で記述し、見た目をCSSで整えて、動的な挙動はJavaScriptで制御する、Webページと同じ技術に基づくデスクトップアプリケーション※である。 IE上で動作するWeb版メールクライアントのOutlook Web Access※など、Web技術を活用して「コンテンツ」ではなく「アプリケーション」を実現する考え方は、この頃すでに形になりつつあった。WindowsとIEの統合も、「WindowsのUIをHTMLとJScript※で記述するため」という建前の下で行われたものだった。だが、いずれも部分的な採用や限定的な用途に留まっていた。一般のユーザーが気軽に使用できる、Web技術に基づくフル機能のアプリケーションは、Mozillaブラウザーが事実上初めてだったと言える※。
また、そのような設計を採用したことによる偶然の産物として、Mozillaブラウザーは「XMLとCSSとJavaScriptで拡張機能を作り、ブラウザーにどんな機能でも追加できる」「CSSで記述された外観の定義の切り替えによって、ブラウザーの見た目を大きく変えられる」という特長も備えることとなった。 ブラウザーのモジュール定義ファイルに数行を書き加えるだけで、自作のモジュールやCSSがブラウザーのUI領域内に読み込まれる。それらのモジュールが、ブラウザー内部に処理を付け加えたり関数を置き換えたりして、実装をドラスティックに変更し、動作を拡張する。当時のIEも「HTMLとJScriptで記述した機能をコンテキストメニューに登録し、ユーザーが自由に呼び出せるようにする」という形の拡張機能には対応していたものの、Mozillaブラウザーの拡張機能の自由度の高さは、それを遙かに上回っていた。 1ウィンドウで同時に1つのページしか扱えないMozillaブラウザーを、複数のWebページを並行して閲覧する「タブブラウザー」に変えてしまう拡張機能「MultiZilla」。ブラウザーのウィンドウに統合されていたサイドバー領域を別ウィンドウに切り離せるようにする「Sidebar Window」。当時まだGeckoが対応していなかったHTMLルビを表示可能にする「XHTML Ruby Support」。ブラウザーの機能とは無関係に、純粋なファイルマネージャー・FTPでのファイルの送受信クライアントとしての機能を加える「FileZilla」。Mozillaブラウザーの拡張機能は、実質的には「動的に読み込まれるパッチ」だったため、無限の可能性があった。 このような性質を持つMozillaブラウザーを、先進的なブラウザーであると同時に、誰でも気軽に使える「Web技術ベースのアプリケーションの汎用実行プラットフォーム」として期待する向きもあった。見方によっては、Mozillaブラウザー自体が「ブラウザー」「メールクライアント」「Webページ作成ツール」という多様なアプリケーション実装例の集合体だったとも言える。
※XUL：Extensible User-interface Language。XMLの書式に則り、
や、といったUI記述専用の要素型でUIの構造を定義する。「ズール」と読み、映画ゴーストバスターズ作中に登場した「門の神」ズールと同じ発音であることから、それにちなんだネーミングがプロジェクト内の他の場面でも度々見られた。※Web技術に基づくアプリケーション：実際には、RDF（Rsource Definition Framework）、Mozilla固有の技術であるXBL（XML Binding Language）、ローカルファイルの読み書きなど既存のWeb技術ではカバー不可能な部分を担うXPCOMと名付けられたネイティブコンポーネント群なども使用されていた。
※Outlook Web Access：現在のMicrosoft 365の原形。
※JScript：JavaScriptと互換性を持つMicrosoft独自のスクリプト言語。
※Web技術を基盤とした汎用アプリケーション実行環境：後にこのコンセプトに特化したものとして、Geckoを基盤としたXULRunner、Flashを基盤としたAdobe AIR、Chromiumを基盤としたElectronが生まれた。XULRunnerやAdobe AIRは短命に終わったが、ElectronはVisual Studio Code、Discord、Slack、Microsoft Teamsなどで活用されている。
■Netscapeの終焉 とはいえ、このアプローチは当時の状況ではあまりに野心的に過ぎた。新しいコンセプトでの再設計という大きな手戻りの上で、アプリケーション・スイートとして統合される前提の複数アプリケーションを並行開発することは、困難を極めた。ソースコード公開から2年を経てもなお、Mozillaはまだ新ブラウザーのバージョン1.0※をリリースできずにいた。 Mozillaプロジェクトの成果を早急に新製品としてリリースしたかったNetscapeは、まだ開発途上だったMozillaブラウザーを元にNetscape 6をリリースしたが、ただでさえ完成度が低かったことに加え、快適な使用には当時の一般的なPCよりも高い性能が必要な超・重量級アプリケーションと化していたこともあり、Netscape 6のアプリケーションとしての出来は惨憺たるものだった。2年以上待たされた結果のあまりの質の低さに、判官贔屓のNetscape Communicator 4ユーザーも大いに落胆した。ソースコード公開の時点で、第一次ブラウザー戦争におけるNetscapeの敗北を多くの人が悟っていたものの、Mozillaプロジェクトの成果にはまだ一縷の望みが残っていた。Netscape 6の惨状は、その望みがもはや潰えたことをまざまざと示していた。 そこからさらに2年後、Mozillaブラウザーはようやくバージョン1.0に到達し、それを元にしたNetscape 7もリリースされた。しかし、もはやNetscapeのブランドがかつての輝きを取り戻すことはなかった。 1998年のソースコード公開後にAOL※に買収されて以後、独立企業としての存在感をすでに失っていたNetscapeだったが、翌2003年にはついに解散し完全に消滅。Mozilla Organizationは運営母体を失い、Mozilla Foundationと名を改めて、独立した組織として歩み始めることとなる。
※バージョン1.0：ソフトウェア開発の分野では伝統的に、初期の開発版には1未満の小数のバージョンをあて、当初の目標通りの完成度に至った時点でバージョンを1.0に繰り上げて一般向け公開の節目とすることが多かった。
※AOL：American Online。当時はアメリカ大手のISPで、インターネット需要の高まりによる好景気の中で2000年にはタイム・ワーナーと合併し話題となった。後に業績悪化により合併を解消し、2024年現在は買収されYahoo!の一部門となっている。
■基盤技術の停滞、応用技術の爛熟 時を一旦遡り、第一次ブラウザー戦争の趨勢が決したNetscapeのソースコード公開前後。この頃から、Webの技術発展の進み方に変化が起こり始めた。 NetscapeとMicrosoftはシェア争いにおいて優位性を示すために、互いに競って新技術をブラウザーに導入していった。競争がないなら、わざわざコストをかけて新技術を投入する必要もない。ブラウザー戦争に勝利したMicrosoftは、IEの開発にあたっていた人員を他の製品の開発に回し、IEはごく少数のメンテナーが細々とセキュリティ脆弱性の修正や不具合解消にあたるのみとなった。ブラウザー戦争の敗者は大幅な人員削減により開発力を失い、公開したソースコードを元にした製品も一向にリリースされない。二大巨頭ブラウザーベンダーの両者ともが歩みを止めたことにより、ベンダー主導での新技術の投入が行われず、W3Cが提唱したWeb技術仕様の実装も進まない、停滞の時代が始まった。 だが、基盤技術の領域の停滞とは裏腹に、この時期に応用技術の領域ではWebコンテンツ制作者達の手による様々な“工夫”が行われもしていた。
人口の大量流入によりビジネス的な価値が飛躍的に高まったWebには、さらに多くの企業が集まった。コンテンツ制作者達はブラウザーの機能でできることを研究し、収益を最大化するために、あるいは悪意の攻撃のために、あらゆる手を使った。Webページを訪問した際に最全面に表示されてユーザーの操作を妨げる「ポップアップ広告」はその代表で、様々な手法が猛威を振るっていた。 あるいは、コンテンツ領域という枠を飛び出した者達もいた。IE4以降のバージョンでWindowsとの統合のためにコンポーネント化が進んだIEに、アドイン機構によってIEに独自のUIコンポーネントを追加できることが分かり、ブラウザーのUI上という一等地に自社サービスへの誘導経路を設けるため、あるいは広告を掲示するために、専用ツールバーが多数作られた。
そのようにユーザーをいかに食い物にするかに心血を注ぐプレイヤー達がいた一方で、ユーザーの利益のためにブラウザーの利便の向上を試みるプレイヤー達もいた。 Web検索サービス大手のGoogle※は、IE用の「Googleツールバー」を単なる自社サービスへの誘導に使うにとどめず、広告ポップアップの防止や検索語句のハイライト表示など、ユーザー体験を向上する機能を積極的に盛り込んだ。 また、IEの中枢であるレンダリングエンジンをコンポーネントとして他のアプリケーションに容易に組み込めることから、独自のブラウザーUIの開発のみに注力した個人の開発者や小規模ベンダーによる、ユーザー目線での利便を追究した「IEコンポーネントブラウザー」※が多数登場した。それらの多くは一つのウィンドウ内で複数のWebページを平行して閲覧する「タブブラウズ」機能※を備え、ザッピング※的なWebの閲覧スタイルに適していたこともあり中・上級者ユーザーからの支持を集めた。
Webコンテンツ制作の現場においては、ブラウザーのプラグイン機構を利用してコンテンツを表示するFlash※に依存したページが急増した。アニメーション効果や音声・動画の再生など、ブラウザーの機能だけでは実現できない視聴者の目を惹くリッチな表現が可能となるため、エンターテインメント業界やクリエイティブの世界では、Flashが特に重用された。 その一方で、プラグイン無しの状態ではコンテンツを一切閲覧できないWebサイトや、視覚に障害を持つ人にはまったく閲覧できないWebサイトが多数生まれ、アクセシビリティ※の問題は深刻化の一途を辿った。ブラウザー上のコンテンツに通常与えられる権限を超えて動作するプラグインという仕組みに基づくがゆえの、クラッシュの頻発やセキュリティ脆弱性の影響の拡大も問題となっていた。 ブラウザーのレンダリングエンジンではできないことを既存の技術で無理にカバーしたことによって生じた歪みは、もはや無視できないレベルに達していた。
※Google：1998年創業。当時すでに飽和状態にあった、一般のWebサイトの情報を自動収集して検索可能とするロボット型Web検索の分野において、独自のアルゴリズムで他に類を見ない高い検索精度を実現し、後発ながら覇権を握った。また、検索結果のページ内に検索ワードに関連する広告を表示する（ワードごとに広告枠を販売する）ビジネスを最初に始めた企業でもある。
※IEコンポーネントブラウザー：日本においてもDonut、hub.net、Lunascape、Sleipnirなどが人気を博した。
※タブブラウズ機能：複数のWebページを並行して閲覧する機能そのものは、第一次ブラウザー戦争の時代に登場した独立系のブラウザー「Opera」が1995年時点ですでに搭載していた。それがこの時期に再発見された形である。
※ザッピング：テレビの視聴スタイルの1つ。見たい情報を放送している番組を求めて、チャンネルを頻繁に切り替えながらテレビを視聴すること。
※Flash：コンテンツ制作ツール「Macromedia Flash」によって作成された動的コンテンツを「Flash Player」プラグインによってWebページ内に埋め込む形で表示・再生する仕組み。Windows 95登場前後に流行したマルチメディアコンテンツは「Macromedia Director」で制作された物が多く、それをブラウザー内に組み込む「Shockwave」プラグインも存在したが、より軽量なFlashの方がWebでは広く使われた。どちらも、後に企業買収によってAdobe製品となった。
※アクセシビリティ：コンテンツが「使いやすいかどうか」以前の問題である、コンテンツの内容に「アクセスできるかどうか」という点。行政などの公的機関が提供する情報は、視覚や聴覚に障害を持つ人、日本語の読み書きに難を持つ人などにも行き渡らなくてはならないため、特に高いアクセシビリティが求められる。
■不死鳥のごとく そのような状況を改善すると期待されたGeckoエンジンを搭載するMozillaのブラウザーだったが、ユーザーの反応は芳しくなかった。 Netscape 6のリリースを機にバージョンを0.6としたMozillaブラウザーは、その後も地道な改良が続いてはいた。広告ポップアップ防止機能や、タブブラウズ機能など、GoogleツールバーやIEコンポーネントブラウザーによって有用性が広く知られたユーザー志向の機能を取り込んだほか、キー入力の進行に応じてダイナミックにページ内検索を実行するインクリメンタルサーチ、SVG画像のネイティブ対応、他のXML応用言語との混合表示など、先進的な機能も続々取り入れられた。2002年にはついに待望のバージョン1.0もリリースした。 だが、それらの改良を打ち消してなおあまりある、大きな欠点があった。Geckoエンジン発表当初に「高速・軽量」と謳われたにも関わらず、実際のMozilla ブラウザーは、Netscape Communicator 4をも凌ぐ超・重量級アプリケーションとなっていたのだ。 Web技術ベースの設計であることによるオーバーヘッド※もあったが、Mozillaプロジェクトの事実上の支配者※であったNetscapeの方針の影響も大きかった。多機能アプリケーション・スイートを指向していたために、単にブラウザーを使用したいだけの一般ユーザーには無駄な部分が多く、Geckoはその性能を十分に発揮できていなかった。開発の上でも、その多機能さ・複雑さが足を引っ張っていた。事あるごとにユーザーよりもNetscapeのビジネスの都合が優先されるMozillaの状況は、有志の技術者達が協力しあって意志決定しソフトウェアを改善するというオープンな開発の理想※からは、遠くかけ離れていた。
そして2002年、そのようなMozillaプロジェクトの開発の在り方に不満を抱いていたデイブ・ハイアット※、ブレイク・ロス※、ベン・グッジャー※ら一部のメンバーが、Phoenixという名のサブプロジェクトを立ち上げた。「最初から全部入りでも、どれもいまいち役に立たないスイス・アーミーナイフ※」と揶揄されたブラウザー・スイートに見切りをつけて、少数精鋭メンバーによる強力なリーダーシップで、高性能なGeckoエンジンを基盤に、Webブラウザーに不要な機能をそぎ落として、親会社の意向よりもユーザーにとっての使いやすさを重視した、軽量・高性能のブラウザーとして再構築する。混迷を極めたMozillaブラウザーの、もはや希望も潰えて燃え尽きた灰の中から蘇る炎の不死鳥。後に商標の問題※から2003年にFirebird、翌2004年にFirefoxと名を改める事になる、新しい軽量ブラウザーの誕生である。
無駄な贅肉がそぎ落とされたPhoenixは、Geckoエンジンが持つ本来の性能を遺憾なく発揮した。IEコンポーネントブラウザーという、進歩を止めたIEのレンダリングエンジンを騙し騙し使い続ける工夫の産物に慣れた中・上級者ユーザーに対して、Phoenixはまだ正式バージョンのリリースのはるか手前にありながら「次世代」を強烈に印象付けた。
Netscapeの凋落は依然として止まらなかったが、より良いブラウザーの開発に熱意を持っていたMozillaの開発者達や、ユーザーや市井の開発者のコミュニティにとっては、ある意味で好都合でもあった。MozillaプロジェクトへのNetscapeの影響力が弱まることで、開発コミュニティの意向を反映したユーザー志向の開発を進めやすくなったからだ。 そうして2003年4月。Netscape社の消滅が秒読みとなった段階で、Mozilla Organizationは大きな決断を下した。Mozilla 1.4を境に、メインの開発ラインをアプリケーション・スイート型のMozillaブラウザーからPhoenix、もといFirebirdへ切り替える※と発表したのだ。■
※オーバーヘッド：スクリプトの逐次実行や動的なレイアウト再計算処理などのほか、ネイティブコンポーネントの呼び出し処理にも時間がかかっていた。
※事実上の支配者：Mozilla OrganizationはあくまでNetscapeとは別組織ということになっていたが、開発者の多くはNetscapeに雇用されており、重要な意志決定にNetscapeが及ぼす影響力は絶大だった。
※オープンな開発の理想：誤解されがちだが、オープンソースかどうかと開発体制がオープンかどうかは無関係である。
※デイブ・ハイアット（Dave Hyatt）：Geckoエンジン採用のMac用ブラウザーCamino（Chimera）の開発に参加した技術者。後にAppleのSafari開発チームへ移籍。これらに共通のドラッグ＆ドロップ操作形式のツールバーカスタマイズは彼の手による物。
※ブレイク・ロス（Blake Ross）：16歳頃よりNetscape でインターンとして勤務し、若手の旗手として知られた。後にFacebookに移籍。
※ベン・グッジャー（Ben Goodger）：MozillaのUI関係モジュールの責任者として勤務。Googleに移籍後Chromeの開発プロジェクトを立ち上げる。
※スイス・アーミーナイフ：柄の中にナイフの刃意外にも様々なツールが折り畳まれたナイフ。サバイバルナイフ。転じて英語圏では、名目上は万能に見えて、実際には使いにくいことの例え。日本語で言うと器用貧乏。
※名称の商標問題：Phoenixは同名のPC用BIOSの、Firebirdは同名のデータベース開発プロジェクトの商標である。なお、Firefoxの名称やアイコンはMozillaが商標権を持つため、公開されているソースに改変を加えた物を第三者がFirefoxの名で提供することはできない。Debianのリポジトリにおいては、FirefoxはIceweasel（氷のイタチ）の名で異なるアイコンを伴って収録されている。
※メインラインの切り替え：これ以後、Mozillaブラウザー・スイートはコミュニティの自主開発に委ねられることになった。コードネームであったSeaMonkeyを正式名称に改めて採用したこのブラウザー・スイートは、FirefoxやThunderbirdの開発の成果を逆輸入する形でメンテナンスが継続されている。
■Firefoxの熱狂 2003年7月、Netscape社の消滅に伴ってMozilla OrganizationはMozilla Foundation※へ移行し、Firebirdの開発はさらに加速。翌2004年、Firebirdは正式に名をFirefoxと改め、待望のバージョン1.0のリリースを迎えた。
Firefoxの売りは明確だった。高性能で、初心者でも迷わず使えるほどにシンプルで、上級者にとってはカスタマイズ性の高いブラウザー。初心者向けと上級者向けの2つの顔を両立させる鍵になったのが、新たに搭載されたアドオンマネージャー※の存在だった。 Mozillaブラウザーは拡張機能に高い自由度を許していたが、拡張機能の管理や削除を一元的に行う仕組みはなく※、扱いにはユーザー側に相応の知識と慎重さを要するものだった。ブラウザーの再設計にあたり、Firefoxの開発チームはほとんどすべての拡張機能に共通する要件として、拡張機能の追加や削除、設定画面の提供、最新バージョンへの自動更新などをブラウザー側で一手に行うようにした。また、拡張機能公開用のポータルサイトを立ち上げて市井の開発者達に登録を促し、開発者がソフトウェア開発そのものに安心して集中できる環境も整備した。Firefoxというアプリケーションがエコシステムと組み合わさることで、その有用さは何倍にも増幅された。
まず率先して使ったソフトウェア開発者達がファンとなり、自分たちのニーズに基づいて気軽に拡張機能を開発・公開する。それがまた呼び水となって、新たなユーザーを集める。このような好循環により、Firefoxは急速にシェアを拡大していった。Spread Firefoxと題したユーザーコミュニティによる口コミ普及活動も行われ、その勢いは、開発と普及に関わった1万人の貢献者達の名を記した全面広告をNew York Times紙面に掲載するほどだった※。 翌2005年のFirefox 1.5では常に安全な最新版をユーザーに届ける自動更新機能、2006年のFirefox 2.0では社会問題と化していたフィッシング詐欺に対抗するための詐欺サイトブロック機能と、Firefoxは着実に進歩を続けた。こうした躍進の陰では、Googleが少なくない役割を果たしていた。
※Mozilla Foundation：Mozilla Foundationは非営利法人として活動に制限を受けることから、Mozillaは2005年に完全子会社としてMozilla Corporationを設立し、開発体制の実体をそちらに移している。
※アドオン：Firefoxではブラウザーに機能を追加する物を「拡張機能」、外観を変更する物を「テーマ」、Webページ内に埋め込まれたメディアコンテンツを表示する物を「プラグイン」と呼び分けており、それらを総称して「アドオン」と呼ぶ。ただし、「Firefox用のアドオン」と言った場合は拡張機能のことを指すことが多い。
※拡張機能の削除：中には自身の情報の登録解除やファイルを削除するアンインストール機能を自前で備えた拡張機能もあったが、ほとんどの場合は「入れたら入れっぱなし」だった。
※全面広告：広告掲載費を寄付として募り、2004年12月6日付の紙面に掲載された。その後、この時の貢献者名を四面に刻んだモニュメントも作成された。
■GoogleのMozilla支援 2001年以後IEが歩みを止めたことは、Webに安定したインフラであることを望む既存社会には好都合だった※一方で、Webをフィールドとして一般ユーザー向けに目新しい物を提供していきたい者達には足枷となった。仕様はあってもIEには未実装のWeb標準技術を尻目に、IEの不具合を回避するためのバッドノウハウを積み重ねることは、Web制作に携わる者達にとって大きなストレス要因となっていた。 技術力を以て便利なサービスを提供し事業を拡大したいGoogleにとって、Web技術の発展がMicrosoftという一プレイヤーのビジネスの都合により停滞し続けていることは、由々しき問題だった。IE用Googleツールバーやデスクトップアプリケーションなどは提供していたものの、Googleにとってはやはり、ソフトウェア導入の手間が不要なWebこそが主戦場であり、革新的なWebサービスを提供するにはブラウザーの技術的進歩は必須であった。 そこでGoogleはMozillaに目を付けた。GoogleはFirefoxの開発にフルタイムで従事する技術者の雇用や、Mozillaへの資金提供※、自社サービスのAPIの解放※など、様々な形で支援を行い※、Mozillaを陰日向で支援した。 Web業界にあったフラストレーションの受け皿として最適な位置にいたFirefoxは、こうして後顧の憂いなく開発に邁進し、好スタートを切ることができたのだった。
※堅いビジネスとWeb：現実との接続が強い事業会社や行政においては、プロジェクトが数年に渡ることも多い。Webの技術発展の速度では、その技術を採用したプロジェクトよりも先に技術の方が寿命を迎えてしまうことがある。
※GoogleによるMozillaへの支援：ブラウザーのUI上のWeb検索機能の初期設定をGoogle検索とすることの対価という名目で多額の広告費用が支払われたが、これは当時のMozilla製品のシェアからは破格だった。Chrome登場後の現在も、これはMozillaにとって最大の収益源である。なお、2020年に米司法省がGoogleに対して提起した反トラスト法訴訟では、これが他社検索エンジンの締め出しにあたるとして、金銭支払いの停止を求めている。
※APIの解放：具体的には、マルウェアやフィッシング詐欺の遮断機能が該当する。これらの機能が用いる既知の危険なWebサイトのリストは、元々はGoogleツールバーのための物だったが、後にFirefox 2.0において組み込みの機能となった後も、そのまま同じリストを使用している。
※その他の支援：当時、Mozillaのマウンテンビューオフィスのすぐ隣にはGoogleキャンパスがあり、MozillaのスタッフはGoogle社内で働く開発メンバーに帯同して、敷地に出入りしてラウンジで無償で食事を取ることができた。マウンテンビューは田舎町で、付近に食事を取れる場所がなく不便なため、こういった福利厚生は切実性が高かった。
■SafariとWebKitの登場 GoogleがMozillaを支援して間接的にWebの進歩を促そうとしたのに対して、Apple※はより直接的に、レンダリングエンジン込みでブラウザーを自社開発する道を選んだ。ただし、ゼロからの開発ではなく、すでにあった実装をベースにして。 2001年当時のAppleは自社製ブラウザーを持たず、Microsoft製のInternet Explorer for Mac※をMacの標準ブラウザーに採用していた。これを自社のコントロールの及ぶ製品に置き換えることを狙ったAppleは、KHTMLをその出発点に選んだ。Linux用デスクトップ環境を開発するKDEプロジェクトで開発されていた、KDE独自のWebブラウザー用のレンダリングエンジンである。 AppleはKHTMLのフォーク※をWebKitと名付け、求める水準まで引き上げるべく開発リソースを投入。その成果は2003年、Apple自社ブランドのMacOS Xの新たな標準ブラウザー・Safariとしてリリースされた。Macには独特の世界観があり、その世界観に最もマッチするのはApple純正の製品だという意識がMacの支持者にはある。待望の純正ブラウザーとしてSafariはMacユーザーに歓待された。
また、SafariはWeb開発者やソフトウェア開発者からも大いに支持された※。WebKitはGeckoと並ぶ高機能・高性能を備えていたことも特長で※、当時の最新のWeb標準技術仕様への対応状況をチェックするAcid2テストに最初に合格したレンダリングエンジンとなった※。 MozillaのGeckoが、Netscapeの意向を強く受けていた頃の開発内容の影響で複雑化しており、ブラウザーの開発者達にとって手を着けづらい物となっていた※のに対し、WebKitは過去のしがらみが無い分、開発者視点でも触りやすい物となっていた。このためWebKitは、高性能なオープンソースのレンダリングエンジンを自らのソフトウェアに組み込みたかった開発者や、オープンソースのレンダリングエンジン開発に関わりたかった開発コミュニティの人々からも、広く支持を得ることとなった※。
※Apple：1976年創業。MacシリーズやiPhoneシリーズなどを開発・販売する電気機器メーカー。Mac専用OSであるmacOS、iPhoneなどの専用OSであるiOS、およびそれら用の各種アプリケーションやWebサービスなど幅広い製品ラインナップを持つ。
※Internet Explorer for Mac：Windows用IEのTridentとは別のレンダリングエンジンであるTasmanを搭載し、Windows用IEよりも高い水準でWeb標準仕様に準拠していた。2003年開発終了。
※フォーク：元プロジェクトの開発に参加するのではなく、ソースコードのみを引き継いで独立した別プロジェクトを作るやり方。
※ソフトウェア開発者のMac贔屓：MacOS X（現macOS）は使いやすいGUIがUnixに備わった物として、Unixに慣れ親しんだ古参開発者や、コマンド体系に共通点が多いLinuxを使うWeb開発者にも人気を博した。また、MicrosoftのLinuxやオープンソースに対するネガティブキャンペーンに反感を持った開発者達の“移住先”にもなった。
※GeckoとWebKit：この頃、GeckoはWeb標準仕様によく対応したレンダリングエンジンの代表と扱われていた。WebサイトによってはGeckoを特別扱いする場合もあり、WebKitはWebサイトに通知する自身のバージョン情報末尾に「like Gecko」という文字列を付与して、Geckoと同等の性能であることを示していた。
※Acid2テスト：WaSP（The Web Standards Project）が2005年4月に公開した、HTML4とCSS2.1の対応度に対するテストケース。一般向けにリリースされたバージョンのブラウザーでは、Safariは2005年10月、Operaは2006年、Firefoxは2008年、IEは2009年にテストに合格した。
※Geckoの複雑さ：レンダリングエンジンこそ刷新したものの、旧製品由来の部分や、Windows・Mac・Linuxの3環境に対応するための独自の抽象化基盤があり、開発に参加するにはこれらの事情の把握から始める必要があった。
※ソフトウェア開発者からの支持：この事実は「オープンにしさえすれば善意の開発者が協力してくれる」というナイーブな考え方がいかに甘いものであるかを如実に示している。善意の開発者も、協力しにくい物より協力しやすい物に流れるのは道理である。
■競争の激化 「Acid2テスト合格」という明快な性能指標ができたこともあって、開発が停滞していたIEの次の座の候補となるその他の次世代ブラウザーにも注目が集まるようになった。Operaはメールクライアントなども含む多機能さと、フィーチャーフォン上で動作するモバイル版の存在を武器に支持を得ていた。iCabはMac用のみのリリースであったが、MacOS Xのみならずその前世代のMacOSでも動作する強みがあった。 こうして戦国時代の様相を呈してきた次世代ブラウザー達の覇権争いを、人は「第二次ブラウザー戦争」と呼んだ。
やがてMicrosoftもこのような状況の変化に危機感を抱き、IEの開発再開を決定。2006年、およそ2年ぶりの新バージョンとなるIE7をリリースした。しかし、IE7、IE8と改良を続けていくものの、レンダリングエンジンTridentの設計の古さはいかんともしがたく、また停滞期での印象の悪化もあり、他のプレイヤー達に対して大きく後塵を拝した状況が続くこととなる。
こうした激しい開発競争に終止符を打ったのもまた、Googleであった。
■Google Chromeの衝撃 Firefox 1.0が世に出て注目を集め始めた頃、GoogleはFirefoxの開発をリードしていたベン・グッジャーやダリン・フィッシャー※ら主要開発者達を相次いで迎え入れた。Googleが独自にブラウザーを開発するのではないかと噂されたが、彼らはGoogle転籍後も変わらずFirefoxの開発に従事していた。このことは、GoogleとMozillaの良好な関係を示す一例※として捉えられた。 だが、蜜月は突如終わりを迎える。Safariのリリース以後、WebKitは着実に支持者を増やしていたが、その中にはGoogleの姿もあった。IE6の寡占状態を打倒しWebの進歩を加速するべくMozillaを支援してきたGoogleだったが、両者の思惑は異なる。自社独自のサービスを持たず、Webに自由と選択肢をもたらすことを旗印にしたMozillaの開発方針は、自社のWebサービスにとって有利な状況を作りたいGoogleにとって、必ずしも嬉しい結果ばかりをもたらす物ではなかった。 Appleがそうしたように、自社で方針をコントロールできるWebブラウザーを持つべく、GoogleはWebKitベースでの独自ブラウザーの開発に乗り出した。それまでFirefoxの開発を支えてきた開発者達の持つノウハウを、今度は自社製ブラウザーに活かす。元Firefox開発者達の手による新しいWebブラウザーは、第二次ブラウザー戦争の渦中の2008年に、Google Chromeとして世に姿を現した。 当時MicrosoftとIE6の帝国を打ち砕く反逆者の旗手と見られていたGoogleが、満を持して送り出した自社製ブラウザー。第二次ブラウザー戦争の参戦者としては後発だったものの、それだけに他のブラウザーの成功と失敗をよく研究して作られたChromeは、開発者達のみならず一般ユーザーにまでも、瞬く間に人気を博した。
※ダリン・フィッシャー（Darin Fisher）：Netscape初期からの開発者の一人。Netscape消滅後はIBMに在籍してFirefox開発に参加していた。
※GoogleによるMozillaの支援：オープンソースのソフトウェアへの依存度が高い企業においては、そのプロジェクトの重要な開発者を雇用した上で、自社の業務には関わらせずに、オープンソース開発プロジェクトの作業に専従させる、という形でのプロジェクト支援がしばしば行われる。
■Firefoxの停滞、 Chromeの躍進 ユーザー操作への応答速度と安定性の追求のためのマルチプロセス設計や、WebKit採用によるWeb標準技術仕様への高度な対応、洗練された拡張機能の仕組みなど、Chromeは様々な点で当初から優位性を持っていた。それらの特長は、「思想や理念よりもとにかく実用を重視し、ユーザー体験を向上し続ける」という開発チームの強い意志で実現されていたが、彼らがFirefoxで試みたことの反省も含まれていた。
この頃すでにFirefoxでは、拡張機能の高すぎる自由度ゆえのデメリットが深刻化しつつあった。拡張機能の開発者にとっては、管理周りの苦労は減ったものの、Firefoxの内部設計を熟知していなければ開発を行えない点は変わっておらず、依然として負担は大きかった。ブラウザーを開発する側にとっても、内部設計に深く食い込む拡張機能がブラウザー側の変更で動作しなくなる恐れがあるため、大幅な設計変更をしにくいという、開発上の制約となってきていた。また、脆弱性のある拡張機能や悪意の攻撃者が作った拡張機能を排除しきれない※ことによって、その巻き添えでFirefox自体までもが「危険」と見なされる事態も生じてきていた。 Firefoxの可能性を拡げた拡張機能が、ほんの数年のうちに、Firefoxの停滞を招く「負債」となる。セキュリティと性能の両方が向上するマルチプロセス動作や、新たに策定された技術仕様への対応など、期待された改良は多々あったが、Firefoxには導入されない状況が続いていた。
こうした変遷を知るChrome開発チームは、Chromeにおいては拡張機能の自由度を敢えて制限し、公開された「拡張機能開発用のAPI」を介してのみブラウザーの動作に介入できる設計とした。APIの互換性※さえ保証すれば、ブラウザー側は速度を落とさず進歩を続けられる。また、セキュリティ上脅威となる機能をAPIから省いたことにより、安全性も飛躍的に高まった。その時点ですでに多数あったFirefoxの拡張機能を分析した開発者達は、機能的にそのうち大多数を実現可能なら妥当なトレードオフだと判断した。 この判断は、Chromeの開発チームが「ブラウザーは斯くあるべし」という強いポリシーと自信を持っていることの表れだと言える。「Chrome」の名自体、「Webページというコンテンツがあくまで主であり、ブラウザーはただの枠組みに過ぎない」という思想からの命名※だった。そのような思想のもとでは、ただの「窓枠」に過ぎないブラウザーのUIに、過度の自己主張をするような高い自由度は必要無い。それが、Chrome開発チームがユーザーに示した「答え」だった。 こうした選択が功を奏してか、Firefoxに飛びついていたアーリーアダプター達は、今度は続々とChromeへ乗り換えていった。
※拡張機能のセキュリティ：Firefoxの拡張機能は自由度の高さ故に、悪意に基づく破壊行為や機密情報の取得も容易だった。また、善意の拡張機能であっても、脆弱性があった場合、Firefox内に保持されているユーザーの機密情報が危険に晒される恐れがあった。後には、公開前のレビューや、未検証の拡張機能のインストール制限などの対策が取られたが、根本的な解決にはならなかった。
※拡張機能APIの互換性：当初は仕様の安定性も保証されると思われていたが、Googleは2019年に、現行のAPI仕様「Manifest V2」の廃止と、機能面で一部後退が見られる新仕様「Manifest V3」への移行の予定を発表。Manifest V3では広告ブロックに使われることの多いAPIが廃止されることから、広告ブロック系拡張機能の締め出しと疑われ反発を受けた。
※Chromeの名の由来：ソフトウェア開発業界の一部には、昔のアメリカ車の車体外周を飾る銀色の金属部品になぞらえて、アプリケーションのUI部分を「クローム」と呼ぶ習わしがある。Mozillaにおいては、ブラウザーのUI部分をクロームと呼び、リソースには内部的に「chrome://～」というURLを割り当てている。
■JavaScript高速化の時代 第二次ブラウザー戦争における競争の結果、Webページの動的コンテンツの実行性能はそれ以前に比べ飛躍的に向上した。その鍵となったのがJIT※である。
煩わしいWeb広告やジョーク・イタズラ程度にしか使われてこなかったために、世間的には評価が低かった※JavaScriptだったが、第二次ブラウザー戦争と共に訪れたWeb 2.0※の潮流の中で、本格的なアプリケーション開発に用いられる場面が急増。それ以前には問題視されることが少なかったJavaScriptの実行性能の低さが、実用上の妨げになり始めてきていた。当時すでに他のプログラミング言語において実行性能を引き上げるためにJITの採用が広まりつつあり、このような状況を改善する本命の技術として、JavaScriptの処理系にもJITの導入が望まれるようになっていた。 そのような状況下の2008年8月、まずFirefoxのJavaScriptエンジンであるSpiderMonkeyにJIT搭載がアナウンスされた※。次のメジャーアップデートを目指して開発が始まったばかりで、一般向けのリリース版で使用可能になるのはまだまだ先だったが、FirefoxはブラウザーのUIの実装にもJavaScriptを使用しているため、ブラウザーの動作が全体的に高速化されるものとユーザーは大いに期待した※。 しかし、JavaScriptのJIT時代は思いのほか早く訪れた。FirefoxのJIT実装の報せが出てからさほど間を空けずに公開されたChromeが、初版からJITを採用していたからだ。Chromeに搭載されたV8 JavaScriptエンジン※は登場当初から極めて良好な性能を示し、高速なJavaScriptエンジンを待ちわびていたユーザー達に「速度第一のGoogle」を改めて印象付けた。 この流れの中でAppleもSafariのJavaScriptエンジンであるJavaScriptCoreにJITを含む高速化・最適化技術を投入することを告知したものの、劇的な性能改善の成果が一般ユーザーの手に届くまでには、Firefoxと同様にここからさらに時間を要した※。 JIT以外の工夫の効果もあり、当時実際にエンドユーザーが実用できたJavaScript実行エンジンの中では、ChromeのV8が飛び抜けた高性能を示していた※。このこともまた、Chromeが人気を集める大きな理由となっていた。
※JIT：人間が読み書きしやすい高級言語は、実行用プログラム（インタープリター）が都度解釈して実行するか、翻訳用プログラム（コンパイラー）がコンピューターで実行可能な機械語に事前に翻訳しておいた物を実行する必要がある。JITは、スクリプトの実行時に、翻訳済みの物が無ければその場で（Just In Timeで）翻訳してメモリー上にストックし、以後はそちらを実行することで、事前に翻訳しておく手間の省略と実行性能の向上を両立する技術。開発環境での事前翻訳とは異なり、JITでは最終的な実行環境上で翻訳することから、より高度な最適化に期待できる利点もある。
※JavaScriptの当時の評価：ただマウスカーソルを追いかける画像、無限に開き続けて閉じられないポップアップ広告など、実用性のない使い方や迷惑な使い方が多く、Webを安全・快適に閲覧するためにはJavaScriptの実行を禁止することが中級者以上のユーザーには常識となっていた。
※Web 2.0：GmailやGoogleマップに代表される、JavaScriptによる非同期通信を用いて快適な操作性を実現した新世代のWebアプリのコンセプト。それ以前のWebアプリは、静的なページを低速な回線で都度読み込む形式が多く、何か操作する度に「読み込み中」と表示され数十秒待たされるのが常だった。
※FirefoxのJIT：SpiderMonkeyが採用したTracing JITは、インタープリターでの実行状況を監視し、高頻度で実行される部分のみをコンパイル・最適化する方式だった。関数単位でコンパイルする既存方式よりも高度な最適化を行う試みとして、当時のコンパイラ業界的にも注目された。
※Firefoxの性能向上への期待：この成果は2009年6月リリースのFirefox 3.5から正式に反映されたが、DOMオブジェクトなど純粋なJavaScriptのオブジェクトでないものが関係する処理に対してTracing JITが有効に機能せず、実際には期待されたほどの劇的な性能改善にはならなかった。
※V8：WebKitにはJavaScriptエンジンのモジュールとしてJavaScriptCoreが含まれているが、GoogleはChrome用として新たに独自のJavaScriptエンジンを開発した。名前の由来は「バージョン8」ではなく、自動車用の強力なエンジンの代名詞として知られるV型8気筒エンジン。初版時点でのJITは最適化は特に行わずにスクリプト全体を効率よくコンパイルする方式だったが、SpiderMonkeyのTracing JITほどの凝った工夫をせずとも充分高速に動作した。
※SafariのJIT投入：JavaScriptCoreの開発版における最適化の成功は2008年9月にアナウンスされたが、一般向けのリリース版に反映されたのは2009年6月リリースのSafari 4.0からであった。
※各JavaScriptエンジンの性能改善：当初は各ベンダーで大きく異なった高速化手法が試みられていたものの、各実装で有用性が示された手法を相互に取り入れていった結果、後にはV8だけが突出して高性能というわけではなくなってきている。
■ラピッドリリースとESR Chromeはブラウザー業界に、ラピッドリリースというリリースモデルも持ち込んだ。それまでWebブラウザーは、新機能を投入したメジャーアップデートは基本的に1年に1回程度行われ、その間の期間はセキュリティに関わる修正のみ定期的に提供されるのが常だった。しかしGoogleはこの常識を打ち破り、Chromeを数週間ごと※という極めて短い間隔でリリースする方針を取った。バージョン番号はもはや、リリース回数のカウントでしかなかった。Webコンテンツの表示プラットフォームを常に最新の状態に更新し続けることで、Web技術の進歩と普及を加速させるのが狙いだった。 急速にバージョン番号を上げていくChromeに対し、Firefoxの歩みの速度は落ちていた。バージョン2.0の次のバージョン3.0のリリースまでには1年半以上の期間がかかり、その後も3.5、3.6と小刻みな改良は続くものの、バージョン4.0はなかなか世に出ずにいた。Chromeにとってはもはや形骸化した物とはいえ、バージョン番号でまで追い抜かれ引き離されることを、Chromeにユーザーを奪われ続けるMozillaは看過できなかった。2年以上越しのメジャーアップデートとなるバージョン4を境にFirefoxもラピッドリリース体制に移行し、ユーザーの元に新機能や改良を発表からさほど間を開けずに迅速に届けるようになった。
ただ、このスピード感は、保守的な運用スタイルの企業などの法人組織にはそぐわなかった。コミュニティから頻繁な更新によるシステム管理担当者の負担増大を懸念する声が寄せられ、折衷案として、Firefoxはラピッドリリースを行う通常リリース版とは別に、従来同様に約1年にメジャーアップデートが提供される法人向けチャンネルとしてFirefox ESR（Extended Support Release）を提供することとなった※。Firefox初のESRとしてバージョン10がリリースされた後も提供は継続しており、現在最新のESRはバージョン128となっている。
※Chromeのリリース間隔：初期は6週間ごとのリリース、2021年以降は4週間ごとのリリースとなっている。
※法人向け延長サポート版：長期サポート版とも呼ばれる。2024年現在、ChromeおよびEdgeも同様のコンセプトで法人向けに拡張サポート版（Extended Stable）を提供しているが、そのサポート期間は8週間である。
■Web開発ツールの 標準搭載 FirefoxもChromeも、最初に飛びついたユーザー層には当然ながらWeb開発関係者が多かった。そのため拡張機能もWeb開発者向けのデバッグ支援ツールが充実することとなった。 Firefox以前のMozillaブラウザーにおいても、ブラウザー自体に内蔵されたDOMインスペクター※や、拡張機能としてJavaScriptデバッガー・Venkman※が提供されていたが、2006年にはそれらの様々な開発ツールを内蔵した統合Web開発ツールのFirebug※が登場。Web 2.0でのJavaScriptによる本格的なアプリケーション開発のニーズの高まりを受け、Firebugは大いに人気を博し、Firefox用拡張機能の代表的存在となった。 このことがあってか、Chromeは最初期のバージョンから「Web開発ツール」としてFirebugと同等以上の機能を標準搭載しており、Web開発者からの支持をより一層得る一因となった。このChromeの動向を承け、FirefoxもWeb開発ツールの標準搭載へと進んでゆくこととなる。 その後のWeb技術の発展に伴い、ブラウザーに内蔵された開発ツールは、その後もIndexedDBのデータベース解析やWebフォント指定の分析機能など、続々と機能強化を続けていくこととなる。
※DOMインスペクター：Webページ内のHTML要素のツリー構造を表示し、各ノードに紐付いているスタイルシートの情報やJavaScriptのオブジェクトとしての情報などの詳細な内部状態を調べられるようにするツール。
※JavaScriptデバッガー：ブラウザー上に読み込まれたJavaScriptの任意の行にブレークポイントを設定し、処理がそこに到達した時点で処理の流れを一時停止して、その時点でのスコープ内の変数を参照したり処理を1行ずつステップ実行したりすることで、JavaScriptで記述されたプログラムの障害調査を支援するツール。Venkmanの名は、映画「ゴーストバスターズ」の主人公の一人であるピーター・ヴェンクマン博士に由来。
※Firebug：Netscapeに在籍し、MozillaにおいてDOMインスペクターを開発したジョー・ヒューイットらが開発を手がけた。2017年に開発終了。
■モバイルファースト Chromeのリリースと前後する2007年のiPhone※発売、翌2008年のAndroid※発表を経て、Webの中心地はモバイル環境へと急速に移っていった。使用に一定のリテラシーを要するPCに比べて、指先での簡単な操作でインターネットを利用して人とコミュニケーションを取り、Web上の豊富なコンテンツを閲覧できるスマートフォンは、それまでPCを使用していなかった人達にまで急速に普及し、インターネット利用者の絶対数を増加させた。 Googleはこの流れを承けて、モバイル向けWebサイトを検索結果で優遇するモバイルファーストの方針を打ち出し、多くのWebサイトが、否応なくモバイル対応の必要に迫られるようになった。第一次ブラウザー戦争の折、PC環境以外の表示環境を考慮しないWebコンテンツのアクセシビリティの問題は看過されがちだったが、一般ユーザーがスマートフォンでWebを閲覧する上では切実な問題となった。PC向けとスマートフォン向けのコンテンツを別々に維持するコストが嵩むことで、ようやくアクセシビリティの重要度が認知された形であった。
動画や音声などのメディアを含むWebサービスは、このモバイル対応に苦戦した。この時期の動画や音声などのメディアを含むWebページは、プラグインを必要とするFlashベースで作られるのが常だったが、AppleはiPhone上のSafariでのFlash使用を禁止しており、メディア再生を伴うコンテンツは専用アプリで閲覧するほか無かったからだ。 この閉塞を打ち破るべく、AppleとGoogleはFlashと同等のことをWebブラウザー上のJavaScriptのみで実現可能にするために、こぞってWebKitに機能を追加していった※。
この流れにMozillaは出遅れた。Fennec※と呼ばれたAndoriod版Firefoxは、デスクトップ版Firefoxの特長を引き継ぐカスタマイズ性の高いモバイル用ブラウザーとなることが期待されたが、PCに比べてCPUやメモリーなどのリソースが大きく制限されるモバイル環境においては実用品質には至らず、計画は頓挫。UIを再設計して出直したFenix※でようやく実用に達したものの、カスタマイズ性の面ではPC版に劣り、Android用の標準ブラウザーに対して「Geckoエンジン採用」以外の特色が見えづらく、シェアは伸び悩んでいる。 また、Geckoエンジン込みのFirefoxを規約上開発できないiOS※においては、WebKitベースでUIだけを実装したiOS用Firefoxも提供したが、Firefoxならではと言える目立った特徴が無いことから、こちらも存在感を示せてはいない。 AppleとGoogleの二大巨頭企業が牛耳るアプリストアでの勝負ではなく、その上位のモバイルOSの領域でもMozillaは勝負を挑んだ。自由で開かれた選択肢の提供によって地位を確立するべく、軽量のLinux上でGeckoエンジンを動作させて、あらゆるアプリやコンテンツをその上で表示する形式を取った新たなモバイルOS※としてFirefox OSを立ち上げ、Mozillaはその開発に多大なリソースを注いだ。しかし、2013年の初版リリースからめざましい成果を挙げられないまま、2016年のバージョン2.6をもってプロジェクトは終了※。Firefox OSに少なくない開発リソースを振り分けていたMozillaにとって、この失敗は大きな痛手となった。
※iPhone：Appleが音楽再生デバイスであったiPodを出発点に、大きなタッチ操作式画面を搭載したiPod Touchを経て、インターネット接続機能と通話機能を加える形で完成したスマートフォン。それ以前にあったモバイル版Windows（Windows CE）搭載機などが「小型のPC」、Blackberryなどが「メール送受信端末」といった趣だったのに対し、それらとは異質な新世代の携帯型情報端末としての標準を確立した。
※Android：Googleが発表したオープンソースのモバイル端末向けOS。実際の端末は、これを各社が自社の端末用にカスタマイズした物を搭載する形で発売されている。
※リッチコンテンツのためのWeb技術：HTML canvasはAppleがMac OS Xでのニーズのためにすでに対応済みだった。この時期に実装が進んだものには、動画・音声を再生しつつJavaScriptで制御できるHTML videoとHTML audioや、3Dコンテンツの描画を可能とするWebGLなどがある。
※Fennec：GeckoエンジンをベースにXULやJavaScriptなどのWeb技術でUIを実装するという、デスクトップ版Firefoxと同様の構成を取ったモバイル用Firefoxの開発プロジェクト。名前は、砂漠に生息する狐の一種であるフェネックに由来する。
※Fenix：Fennecに代わる物として、コンテンツのレンダリング用にGeckoエンジンを採用しつつ、UIは一般的なAndroidアプリの作法に則ってJavaで実装する構成を取ったモバイル用Firefoxの開発プロジェクト。Firefox SyncによりPC上のFirefoxとブックマークや履歴、タブを共有することができる。
※iOS：当初はiPhone OSと呼ばれたが、iPadなど時計型以外の端末にも使われることから、2010年にiOSへと改称された。
※WebブラウザーベースのOS：同様のコンセプトを取った物として、軽量のLinux上で直接Chromeを動作させ、その上ですべてを構築したChrome OSがあり、こちらはタブレットPC用として一定の地位を築いた。
※Firefox OSのその後：Mozillaによる開発が終了した後、Firefox OSのコードベースは派生プロジェクトのKaiOSに引き継がれた。KaiOSは格安端末用のOSとして2019年頃にはインド地域などにおいてiOSに並ぶシェアを得るに至ったものの、圧倒的なシェアを誇るAndroidに比肩するには至っていない。
■レンダリングエンジンの 収斂 WebKitを採用したChromeが第二次ブラウザー戦争の勝者となる趨勢が見えてきたことで、Webブラウザーのレンダリングエンジンは実質的にWebKit一色になるかと思われたが、Googleはここでまた一石を投じた。WebKitのフォークを決定したのである。 Appleが開発を主導するWebKitプロジェクトに対し、GoogleはChromeの開発を通じて多大な貢献をしていたが、AppleとGoogleの開発方針の違いから、プロジェクトは次第に混乱を増してきていた※。そのフラストレーションがついに閾値を超え、Googleは2013年、WebKitをフォークした新プロジェクトとしてのBlinkの立ち上げを発表。これを機にWebKit側はGoogle固有の事情に由来するコードを、Blink側はApple固有の事情に由来するコードを互いに削除し、それぞれ別々の道を歩んでいくこととなった。
この時期、発展を続けるWeb技術の高度化により、ブラウザーのレンダリングエンジンの維持コストは増大の一途を辿っていた。一社で開発のすべてのコストを負担しきることは年々困難になり、それまで独自のレンダリングエンジンを採用していたWebブラウザーの中には、それを捨ててWebKitベースで再出発する事例が現れ始めていた。それだけに、WebKitのフォークとはいえ、Googleがレンダリングエンジンの開発プロジェクトをあえて立ち上げたという発表は、インパクトをもって業界に受け止められた。
Googleが新たなレンダリングエンジン開発プロジェクトを立ち上げる一方で、他のブラウザーベンダーにおいては、自社製エンジン放棄の流れが進んだ。第一次ブラウザー戦争の頃から独自の路線を貫いてきたOperaは、2012年に自社開発のレンダリングエンジンPrestoの開発終了し、以後はChromium※ベースでの開発となった。また、Opera創業者が当初のOperaの思想を引き継ぐ形で新たに立ち上げたブラウザー・Vivaldiや、Mozillaを2014年に離脱したブレンダン・アイク※が立ち上げたブラウザー・Braveも、Chromiumをベースとしていた。 Microsoftは2013年のIE11を最後に、旧来からのレンダリングエンジン・Tridentの開発に見切りをつけて、過去との互換性を犠牲にしてでもモダンなWeb技術に対応するべく、新エンジン・EdgeHTMLを開発。新たなWindows標準ブラウザーとして2015年、Edgeを発表した。その後もMicrosoftはEdgeの改良を続けたが、最終的には膨らみ続けるレンダリングエンジンの維持コストに白旗を揚げ、開発の放棄を決定。2020年にはChromiumをベースに作り直した新Edgeへ移行した。自社製OSに欠かせない部品であるブラウザーの根幹部をビジネス上のライバル※でもある他社に委ねるこの判断は、巨人・Microsoftが膝を屈したことを示すものとして、業界関係者にとって衝撃的なニュースとなった。
このようなレンダリングエンジンの収斂は、Webに対するAppleとGoogleの影響力を大きく増大させた。 かつてのMicrosoft一強時代には、寡占の弊害が「Webの発展の停滞」として認知されていた。その点において現代では、AppleもGoogleも技術開発の手を止める様子は見られないため、一見するとさほど問題は無いようにも見える。しかし、別の問題はある。Googleが自社のビジネスにとって都合が良いように提案したWeb技術について、ユーザーのプライバシーを損ねかねない物としてAppleやMozillaに反対されWeb標準仕様化には至らなくとも、充分に大きなシェアを持っているGoogleがChromeへ「独自拡張」として実装すれば、それはもはや事実上の標準として機能してしまうのだ。悪くすれば、そのような技術に対応していない他のブラウザーが締め出される※ことも起こる。この状況は、従来とは異なる形で表れた寡占の弊害と言える。
実はMozillaにおいても、WebKit登場当初の勢いを前に、負の遺産を多く含むGeckoエンジンを放棄してWebKitに乗り換えるべきではないかとの声は上がっていた。しかし、目新しさや目先の人気を優先して独自のエンジン実装を捨てることは、プロジェクトの独自性を永久的に損なう片道切符の選択でもある。Mozillaの開発者達は結局、安易な道に流れず踏みとどまり地道な改善を続ける道を選んだ。その成果として2024年現在もMozillaは、ベンチマーク性能でWebKitやBlinkには及ばないながら、総合的には充分に競争力を持つ物としてGeckoを維持している。資金力・開発体制で劣るMozillaが、ビッグテックに食らいつき彼らに比肩する製品を維持し続けていることは、驚嘆と言うほかない。 Web技術があまりに高度化した現在においては、Gecko・WebKit・Blinkと同水準でWeb標準に対応したレンダリングエンジンをゼロから開発することは事実上不可能とも言われている。Mozillaにおいても、Geckoの次世代となるレンダリングエンジン・Servoの開発がゼロから行われたが、現在あるレンダリングエンジンと同水準の機能を完備するには至らなかった。一プレイヤーだけの意志に左右されないWebの健全性が保たれるかどうか、特に、営利企業の都合によらない意見を議論の場で説得力を持って示し続けられるかどうか。EdgeHTMLが脱落した今、事実上最後の独立系レンダリングエンジンのベンダーとして、Mozillaは社会に対しても重い責任を背負うこととなっている。■
※WebKitプロジェクトの混乱：Googleの提案でWebKitに取り込まれた部分を、AppleがGoogleの都合を踏まえず変更してしまい、両者のエンジニア同士の関係が険悪になる事態が度重なっていた。
※Chromium：Google ChromeからGoogle社が独占的に権利を持つロゴや一部の秘匿モジュールを取り除いた、オープンソース版のChrome。建前的には、ChromeはChromiumの派生物にあたる。
※ブレンダン・アイク（Brendan Eich）：NetscapeにおいてJavaScriptを開発したプログラマー。Mozilla Foundation傘下のMozilla CorporationにおいてCTOを勤めた。
※ビジネス上のライバル：Microsoftはオフィス・スイート製品のライセンス販売で大きな収益を上げており、Webベースのオフィス・スイートのGoogle Apsを展開するGoogleとは直接的な競合関係にある。
※他のレンダリングエンジンの事実上の締め出し：実際に、公共性の高いWebサービスにおいてまで閲覧可能なブラウザーをChromeなどのChromium系ブラウザーとSafariのみに限定する例が出てきている。世の趨勢は、議論の上で確立されたWeb標準が軽視され「特定のブラウザーでなければ情報にアクセスできない」という低アクセシビリティの時代に戻りつつある。
ここまで、Webとブラウザーの歴史の概略を語ってきた。ここからは、前章で省略したFirefox特有のトピックに焦点を当てて紹介しよう。
■拡張機能開発者への支援 当初のFirefoxの拡張機能は、前身となったMozillaブラウザーと同様に、XUL、CSS、JavaScriptからなるFirefoxのUI部分の名前空間内に直接的にスクリプトを注入する、実質的には動的パッチとでも呼ぶべき物だった。そのため開発にはブラウザー内部で使われている各種の技術の知見が要求され、このこと自体が高い参入障壁となっていた。 そもそもの問題として、W3CのWeb標準仕様等とは異なり、Mozillaの独自仕様であるXULやWeb技術の域を超える部分を担うXPCOMコンポーネント群には、公式の仕様書と呼べる物が存在しなかった。XUL Planet※のチュートリアルやリファレンスやMozillaZine※のナレッジベースなど、非公式に断片的な情報はあったものの、日々開発が進行するMozillaの内部仕様の一部であるXULやXPCOMについて網羅的な最新情報を得ることは困難だった。 そこでFirefox 1.0リリース後の躍進を機に、Mozillaは公式の技術情報サイト・DevMoを設立。後にMozilla Developer Center、Mozilla Developer Network、MDN Web Docsと名を改めていくことになるこのWebサイトに、Netscape DevEdge※やXUL Planetなどに散在していた技術情報を集約し、リファレンスとしての情報を補強していった。これにより、新規の拡張機能開発者にとって、何から手を付ければよいか分からないという状況は改善され、負担は幾分減ることとなった。
※XUL Planet：MozillaでXULの開発を担当していたニール・ディーキンが個人的に開設していたWebサイト。
※MozillaZine：Mozilla製品のユーザー同士による相互サポートを提供するコミュニティサイト。Mozilla公式のサポート情報が整備されるまでは、MozillaZineのフォーラムがその役割を担っていた。
※Netscape DevEdge：NetscapeがMozilla Organizationと同時期に開設した技術情報サイト。広範なWeb技術の情報を無償で提供していた。
■FUEL ドキュメントが揃ったとしても、Firefox内部の低レベルのAPIは歴史的な経緯から癖が強く、それまでのMozillaの事情を知らない状態で関わり始めた開発者にとっては、依然として拡張機能の開発は面倒事が多い状態であった。 この状況を実装面から補助するための仕組みとしてFirefox 1.5において導入されたのが、FUEL※である。拡張機能向けのAPIセットとして用意されたFUELは、XPCOMを使用するための独特の記法※ではなく、よりJavaScriptらしい記法でFirefoxの動作に介入する方法を提供する物だった。 しかしながら、期待を伴って登場したFUELは、期待外れと言わざるを得ない物だった。ニーズの高い拡張機能を開発するためにはどのようなAPIが必要なのかを充分に分析しきらないままに用意されたAPI群は、帯に短し・たすきに長しを地で行く中途半端さにとどまっていた。また、そのAPIも作りが甘く、実用する上では様々な内部事情を考慮した工夫が必要な始末であった※。注意が必要なFirefoxの内部API群に対するラッパー※であるFUELの使用自体にまた注意が必要という本末転倒さと、実用できる機能はごく一部のみに留まっていたことから、使用を推奨できるレベルにはなかった。 FUELを使用した拡張機能のためにメンテナンスは継続されたものの、充分に成功したとは言えないまま、FULEはFirefox 47で廃止される運びとなった。
※FUEL：Firefox User Extension Libraryの略。「燃料」を意味する単語と同じ綴りで、フューエルと読む。
※XPCOMの呼び出し：JavaScriptからXPCOMコンポーネントの機能を利用する際は、XPConnectと呼ばれる呼び出し方を使用する。
※FUELの問題点：具体的には、「現在アクティブなウィンドウ」のように何かの情報を取得するメソッドを呼び出したりプロパティを参照したりした際に、毎回新しいインスタンスが返されるため、JavaScript的に過去に取得したオブジェクトとの同一性を比較する方法が存在しなかった。
※ラッパー：wrapper、包み込むもの。プログラミングの領域においては、ある機能の詳細を隠蔽して安全あるいは簡単に扱えるようにする物を指す。
■再起動不要な拡張機能とAdd-on SDK 当初のFirefoxの拡張機能の制約の1つに、インストールやアンインストールには必ずFirefoxの再起動が必要という点があった。実質的に「動的なパッチ」であったため、動的な追加まではできたとしても、置き換えられた関数や変更されたUI要素などを元に戻すことでの動的な削除は不可能で、安全に「元に戻す」にはブラウザー自体を再起動するほか無かったのだ。 また、そのような形式上、拡張機能はFirefoxの特定のバージョンの内部仕様に強く依存して開発されることになるため、Firefoxのバージョンアップによって拡張機能が動作しなくなる事態が頻発していた。人気の拡張機能の動作を壊さないためには、Firefoxの内部仕様を変えないでいるしかない。このことが、Firefoxの開発の歩みを阻む足枷となっていた。 Firefox 3.0以後に登場したChromeは、専用のAPIを使用してのみ拡張機能を開発できる仕様としたことで、そのような制約から解放されていた。それを参考に、先述した問題を解消するためFirefox 4.0で新たに整備された仕組みが、再起動不要な拡張機能とAdd-on SDK※であった。
拡張機能の導入時のブラウザー再起動を不要とする仕組みは、Bootstrapped Extensionsと呼ばれた。拡張機能の追加と削除を動的に行うことを前提とし、拡張機能側もそれらのイベントを契機に自ら行儀良く初期化・終了処理を行うことを求める枠組みである。 ただ、この枠組みに従って実際に安全に追加・削除可能な拡張機能を開発するためには、開発者側に高い技術力が要求される。そこで対になるものとして用意された仕組みが、Firefox用の拡張機能開発フレームワークであるAdd-on SDKだった。
Add-on SDKは、コマンドラインツールによって、拡張機能のひな型作成やパッケージ作成といった定番の作業を効率化すると同時に、SDKが提供するAPIセットのみを使用しての拡張機能開発を可能とする。そうして開発された拡張機能を専用のコマンドラインツールで“ビルド”することにより、Firefoxにインストール可能なBootstrapped Extensionsの仕組みに則った拡張機能ができあがる寸法である。Firefox側の仕様変更はSDKのライブラリーの層で吸収し、SDKベースで開発された拡張機能は再ビルドによって容易に新バージョンのFirefoxに対応できる、というフレームワークを提供することにより、Add-on SDKは既存の拡張機能開発者の負担を軽減すると同時に、新規の拡張機能開発者を取り込むことを目指した。
だが、この試みもFUELと同様、大きな成功には至らなかった。以前からの拡張機能開発者にとっては、Add-on SDKはFUELと同様に、できる事の制約が多い不自由な開発基盤と見えた。Firefoxのバージョン依存からの解放や再起動不要といった点は魅力的だったが、そのためにすでにある拡張機能をSDKベースで開発し直す負担の大きさを乗り越える判断は難しかった。APIが用意されていないことをするためには結局従来通りの低レベルの内部仕様に触れる必要があり、そうすると結局はFirefoxのバージョンに対して密結合にならざるを得ない点も、中途半端と見えた。また、新規の開発者となることが期待された人々にとっても、この時点ですでにあったChromeの拡張機能向けAPIとは全く異なるFirefox用のAPIを学習する動機は薄かった。
※Add-on SDK：SDKはSoftware Development Kitの略で、ソフトウェア開発に必要なライブラリ集やツール集をこのように呼ぶ。Add-on SDKによる再起動不要な拡張機能の枠組みは、開発初期段階ではJetpackと呼ばれていた。
■XULアドオンからWebExtensionsへ FUELとAdd-on SDKでの2度の失敗を踏まえた3度目の正直が、WebExtensions APIだった。 WebExtensions APIはChromeの拡張機能向けAPIと互換性を持つ※APIセットで、Chrome用に開発された拡張機能をFirefoxに対応させることも、その逆も容易になるように設計された。また、非同期処理の結果をawaitで待ち受けて簡潔に記述できるという独自の改良も加えられた※。 Firefoxの拡張機能のニーズを分析して慎重に定義されたChromeの拡張機能APIを元にしており、WebExensions APIは充分な実用性を備えていた。これによって、APIのみを使用しての拡張機能開発が現実に可能となり、ようやくFirefoxは新規の開発者を取り込める準備ができた。
ただ、そのように客層を拡げることに留まらない大きな狙いが、WebExtensions API導入にはあった。従来型の動的パッチ形式の拡張機能、XULアドオンの廃止である。 極めて自由度の高いXULアドオンは、Firefoxの特色であり、人気を支えた重要な要素であり、そして同時に停滞の原因でもあった。Chromeの人気に水をあけられながら、追い上げるための抜本的な改良が拡張機能の互換性を理由に阻まれていたMozillaの開発者達にとって、XULアドオンは「廃止するか、廃止しないか」を議論する対象ではなく、もはや「いつ、どのように廃止するか」を議論する対象だった。XULアドオンを廃止してWebExtensions APIの世界に拡張機能を閉じこめられれば、FirefoxのUIや内部実装がどれだけ変わっても互換性の問題は生じない。Firefoxの改善を進めるために、拡張機能のWebExtensions移行は必須の要件だった。
Chromeの開発チームは拡張機能のニーズを分析して、定型的な大多数の拡張機能をカバーできるようにAPIを整備した。言い換えると、定型から外れる拡張機能はAPIでは実現できない。この時点でFirefoxに居残っていた拡張機能には、そのような理由でXULアドオンであり続けている物が多かった。そしてユーザーにとっても、Firefoxにしかない拡張機能こそがFirefoxに居残る理由となっていた。Chromeが切り捨てた領域を再び掬い上げることが、XULアドオン廃止のため、ひいては今後のFirefoxの抜本的改良のためには必要だった。WebExensions APIがするべき事は1つ、APIの拡充である。 FUEL、Add-on SDKに続く3度目の轍を踏まないためには、拡張機能の開発者から見て真に望まれていることを理解する必要があった。そのため2016年、Mozillaは世界各国にいる人気のFirefox拡張機能の作者をAll Hands※の場に招き、「XULアドオンを廃止してWebExtensions APIに一本化するためには何が必要なのか」を議論する機会を設けた。法人用途で必要なカスタマイズのためにXULアドオンの仕組みが用いられていたことが分かり、代替としてポリシー設定※の拡充の必要性が確認されるなど、単に「どういうAPIが必要か」に留まらずにニーズの本質に踏み込んだ様々な議論と合意形成が、そこで行われた。ユーザーにブラウザーの選択肢を残し続けるために、Mozillaの開発チームと外部の拡張機能開発者達とで連携して、今いるユーザーを可能な限り切り捨てないソフトランディングを図ろうという熱意が、関係者の間にはあった。 翌2017年、WebExtensions APIはFirefox 52で通常リリースに投入され始め、同年中のFirefox 57のリリースを以てXULアドオンの廃止はついに実行された※。充分なソフトランディングとはならなかったものの、FirefoxはついにXULアドオンからWebExtensionsへの完全移行を果たしたのだった。
WebExensionsへの移行には、拡張機能開発者の側にも大きな発想の転換が必要だった。その拡張機能の最も重要な価値を分析し直して、WebExtensions API上で価値の再現を試み、場合によっては新APIの提案も行うという、発想力・根気・設計力・交渉力などが広く要求される難題を前に、克服しきれず移行を断念した拡張機能も残念ながら多数あった。このことから、WebExensionsへの移行を「拡張機能の大量虐殺という横暴」「Firefoxの凋落を決定づけた愚行」と評する向きもあった。 初期の中心的な開発者達をChromeに引き抜かれて以後、批判を覚悟で大鉈を振るう強力なリーダーシップの不在ゆえにXULアドオンの廃止が遅れたことは、Firefoxにとって痛恨の極みだったと言える。しかし後述するとおり、XULアドオンの互換性問題がなくなったことで急速に進んだFirefoxの多数の改善は、この決定が必要かつ正しい物であったことを如実に物語っていると言える。
Firefoxが拡張機能開発者達との議論の結果を踏まえてWebExensions APIの拡充を進める一方で、2019年、Chromeは拡張機能用APIのバージョンを改めて仕様を一部変更することを発表した。Manifest V3と呼ばれる新仕様ではそれまでの仕様から一部に機能的な後退が生じることから、影響を承ける拡張機能の開発者達から猛反発を受けた。2024年現在、MozillaはManifest V3の仕様上で機能的な後退無しで拡張機能を移行できる手段が確立できるまでは、旧仕様であるManiefst V2を完全には廃止しないことをアナウンスしている。APIベースという新たなステージに戦場を移してなお、Firefoxはユーザーのための拡張性の高さをアイデンティティとし続けているのだ。
※WebExensions APIの互換性： FirefoxのWebExtensions APIは、W3C Draft Community Groupで議論中のBrowser Extensionsの仕様とChromeの拡張機能APIの両方を参照している。FirefoxとChromeのアプリケーションとしての仕様の違いや、Firefoxにおいて未実装の機能、Firefoxのみの独自に拡張された機能などがあり、WebExensions APIはChromeの拡張機能APIと完全互換ではない。
※WebExensions APIの非同期処理：WebExensions APIは、Chrome互換の書き方をした場合はコールバック関数を使用し、Firefox向けの書き方をした場合はPromiseが返される。なお、ブラウザー間の差異を吸収するpolyfillと呼ばれるライブラリーを使用することにより、ChromeにおいてもFirefox向けと同様のPromiseベースの非同期処理を使うことができる。
※All Hands：1年に1回開かれる、Mozillaプロジェクトの世界中のメンバーが一堂に会して議論や報告をする会。多くのメンバーが遠隔で働く組織において、メンバー同士の良好な人間関係を維持するために、このようなオフラインミーティングを定期的に開くことがある。
※ポリシー設定：Active DirectoryのGPO（Group Policy Object）など、組織のシステム管理者が設定した
※XULアドオン廃止：これに伴い、XULアドオンを前提にしたAdd-on SDKなどの仕組みもまとめて廃止された。なお、XULアドオンをどうしても使い続けたかった人のために、XULアドオン廃止前のバージョンのFirefoxをフォークして派生Webブラウザーとして独自にメンテナンスしている例はいくつかある。
■Mozilla Labsからもたらされた物 拡張機能はユーザー側での工夫のみならず、Mozillaの実験場としての役割も果たした。2005年から2014年にかけてMozilla Labsと題して行われたプロジェクトでは、Firefoxの可能性を広げる機能を拡張機能として開発・公開し、広くユーザーに公開してフィードバックを求め、すぐに試せる形で示した。ここではその例として、軽量テーマとFirefox Syncを紹介する。
テーマ切り替え機能はFirefoxの最初のバージョンからの特色の1つだが、このテーマ機能には大きな転換点があった。 Mozillaブラウザーにおいて、切り替え可能なテーマと拡張機能は極めて近い物だった。XULで構成されたUIに対して、テーマが提供するCSSを読み込ませて外観を調整するのが基本だが、同じXUL要素に触れている以上、JavaScriptによって動的に反映されるスタイル指定とCSSで定義されたスタイル指定が競合することは少なくなかった。また、border-imageプロパティもなければグラデーション機能も無い時代においては、スライス画像※を駆使するためにDOMツリー自体を改変する必要があり、そうなるとますます拡張機能との競合が起こりやすくなった。無論、XULで構成されたUIと直接的に接する部分であるため、テーマは拡張機能と同様に、Mozillaブラウザーの仕様変更の影響を承けやすいのも問題だった。 Firefoxもこの仕様を引き継いで、初期のテーマは拡張機能に近い物となっていた。そのため作成者の負担は大きかった。Firefoxのバージョンアップの度にテーマの互換性は損なわれ、都度多大な作業が必要となっていた。
2007年、この状況を変える試みがMozilla LabsにおいてPersonasの名で行われた。ツールバー領域の背景画像とウィンドウ内の各箇所の配色を動的に変更する拡張機能を用意し、配色の情報と背景画像1枚だけを伴う「軽量なテーマ」を拡張機能が処理することで、Firefoxの内部構造に明るくない非技術者であっても切り替え可能なテーマをより簡単に提供できるようにするというアイデアであった。 Personasによって有用性が確認された軽量テーマ機能は、2010年のFirefox 3.6において正式にFirefox本体の機能として統合された。XULアドオンが廃止された現在では、軽量テーマのみが唯一の切り替え可能なテーマの仕組みとなっている。
また、2007年にはMozilla Labsではもう1つ、Weaveの名でプロジェクトが開始された。自宅のPCや職場のPC、スマートフォンなど、複数のデバイス上のFirefoxを1つのアカウントに紐付けて、それぞれの間でブックマーク、Webの閲覧履歴、パスワードマネージャーに保存した認証情報などのユーザー情報を同期・共有するプロジェクトである。 Weaveは2010年にバージョン1.0に到達。Google Chromeに同等の同期機能が標準搭載されたこともあり、Firefox 4.0において正式にFirefox Syncとして統合された。 Syncの開発の成果はすべて公開されている。プライバシーの保護を重視するユーザーは、Mozillaのサーバーを使用せずとも、自分の管理下で憂いなく同期サーバーを用意できるようになっている。
※スライス画像：画像を縦横の線で細かく分割した物。例えば、装飾的な枠線を持つボックスを表現するためには、上下左右の枠・4つの角・中央の計9個に画像を分割する。それぞれの画像を伸縮させたり繰り返し表示したりすることで、CSS2までの機能では表現できない派手な見た目を実現できた。
■安全とプライバシー ChromeやEdge、Safariに対するFirefoxの特色として、ユーザーのプライバシー保護に関する機能の充実がある。 Chromeに備わるシークレットウィンドウモードは、一時的に他人のPCを使用してWebサービスにログインする場合や、他人と共用しているPCで機密情報を含むWebサービスを使用する場合など、同じPCの使用者に対するプライバシーの保護を想定した、履歴や認証情報を保存せずに動作するモードである。 対するFirefoxのプライベートウィンドウは、Chromeのシークレットウィンドウモードと同様の性質も持つが、それと同時に、さらに強力なプライバシー保護機能としてWebビーコン※やフィンガープリンティング※などのユーザートラッキング技術を無効化する機能も併せ持っている。個人の行動履歴が広告企業によってターゲッティング広告※のために収集されることが常態化している現代において、意図しない様々なトラッキングからユーザーを保護することの重要性は増しているものの、Google自身もまさにそれを行っているプレイヤーであることから、ユーザートラッキングに対するプライバシー保護機能をGoogleの製品であるChromeに期待することは難しい。トラッキング保護機能の充実は、非営利の組織であるMozillが開発の母体だからこそなし得るFirefoxならではの利点と言える※。
またFirefoxは、プライベートブラウズの技術の応用として、普段のWebブラウズ時から隔離されたCookieなどのセッション情報のセットを作業の文脈に応じて複数切り替えられるようにする「コンテナー」機能も備えている。プライベートブラウズは「普段のWebブラウズ」と「プライベートブラウズ」という2つの文脈の切り替えのみを行うが、コンテナーを使用することで、同じWebサービスに複数の異なるユーザーアカウントで並行してのログインまで可能となる。
※Webビーコン：Webページ内に埋め込んだスクリプトや画像などを通じて、ユーザーが特定のコンテンツを表示したり特定の操作をしたりしたことをサーバーへ通知する技術。
※フィンガープリンティング：画面解像度や特定の機能の有効無効など、ログイン情報に依らずに収集可能な情報に基づいてWebサイト側で個々の閲覧者を特定する技術。
※ターゲッティング広告：ユーザーのWebの使用状況を監視し、個人の趣味嗜好にマッチした広告を表示することで、無差別の広告よりも効果的な宣伝を行う技術。個人の普段の動向がWebサービスをまたいで筒抜けとなることから、プライバシーを脅かす物として忌避されることがある。
※Mozillaの非営利性：とはいえMozillaも活動のための収益は必要であり、近年は広告効果測定企業を買収して「ユーザーのプライバシーを保護しつつ広告効果も測定する」機能を追加するなど、プライバシーを最重要視する人からは懸念を抱かれる状況にもなってきている。
■脱XULの成果、性能の改善 拡張機能の断絶を生むこととなったXULアドオンの廃止以後、Firefoxの改善はそれ以前の遅れを取り戻すように急ピッチで進んだ。 まず直接的な変化として、Mozilla独自の仕様からWeb標準技術への置き換えが進んだ。XULやXBL、XPCOMといったMozilla固有の技術は、当時は不可能だったことを可能にした意義は大きかったが、新規の開発者が参加する上での障害となり、Firefox開発に関われる人を増やしにくい問題を生んでいたものの、拡張機能との互換性のためにはそれらを捨てることができずにいた。WebExensionsへの移行によって拡張機能の互換性を考慮する必要が無くなったことで、発展した最新のWeb標準技術を遺憾なく使用して、置き換え可能な部分を一般的なWeb標準技術での実装に置き換えられるようになった。外観上の差異はほとんどないように見えるものの、今や、実装のかなりの部分がXULアドオン廃止前のFirefoxからはかけ離れた状態となっている。 また、CSSのレンダリングの処理効率の向上や、3Dゲームエンジンの技術を応用した画面描画の処理効率向上など、次世代のレンダリングエンジン・Servoの開発の成果がGeckoへと取り入れられたことにより、性能面でも著しい改善が果たされた。ベンチマーク性能ではChromeのBlinkエンジンの後塵を拝するものの、それ以前にあった体感できるほどの遅さは大きく解消され、ChromeからFirefoxへ乗り換えて「快適になった」という声すら聞かれるほどに※、実用上充分なレベルにまで高速化されている。
※ChromeからFirefoxへの移行で生じる体感性能の差：実際の所、ブラウザーを長く使い続けた結果起こる履歴データベースの肥大化なども性能低下の一因であり、長く使い続けた環境から新環境に乗り換えること自体が劇的なユーザー体験の向上をもたらす面もある。
■理想と現実の狭間で Firefoxは開発母体が非営利の組織ということもあり、思想性の強いブラウザーと見られることがある。確かにそのような面はあるものの、実際には思想一辺倒で実用性を軽視しているわけではない。むしろ、MozillaはNetscapeから解き放たれて以後、理想と実用性の両立という難題に正面から向き合い続けていると言える。理想に走りすぎて実用性を疎かにしたブラウザーでは一般ユーザーの常用の選択肢とならず、Webサービスから「対象外」と切り捨てられ、社会に対して存在感も発言力も示せなくなるからだ。 ChromeほかChromium系ブラウザーが市場を席巻し、事実上の標準と見なされるようになった現在では、Firefoxも「Chromeに合わせる」ことが求められる場面が度々生じている。理想と実用の間でどのように落とし所を見つけ、存在感を示しながら生き残っていくことができるのか※。インターネットが、ビッグテックの都合ばかりに振り回されることなく、誰もが自由に使える開かれたものであり続けられるように。WebKitに由来しないエンジンを持つ最後の独立系ブラウザーベンダーであるMozillaの動向には、今後も注視し続ける必要がある。■
※Mozillaの生き残り方：この点で最大の懸念が収益源の確保である。Mozillaの最大の収益源は現在もGoogleからの広告収入となっているが、将来に渡っての安定財源ではないことから、有償サービスの自社運営を試みるなど別の収益源の模索が続いている。
ここまで、Webブラウザーに焦点を当てて語ってきたが、MozillaにはFirefox以外にもう1つ代表的なプロダクトがある。メールクライアントのThunderbirdである。ここでは、Netscape Communicator 4に搭載されたメールクライアント機能の直接の子孫にあたるThunderbirdについて改めて語ってみたい。
■Thunderbirdの誕生 2002年半ば、Mozillaブラウザー・スイートからはブラウザー部分のみならず、メールクライアント部分を再構築するプロジェクトも開始された。Minotaurの名でセス・スピッツァー※が個人的に立ち上げたプロジェクトは、先に世に出たPhoenixが注目を集めたことでMozilla内で正式なプロジェクトとなり、開発が本格化。2003年7月、Phoenixが商標の問題から名をFirebirdと改めたことを承け、対になるようにプロジェクトをThunderbirdと改称した※。
Firefox登場時の熱狂と比較すると、Thunderbirdの世間での扱いは穏やかだ。3ペイン型※メールクライアントという形式やE-mailという技術自体がその時点ですでに相当枯れた技術であったこと、そのためメールクライアントにはそれほどの発展性はないと見られていたこと※などが、その理由と言える。また、Thunderbird 1.0リリース前後の時期にはGoogleのGmailがサービスを開始。ブラウザー上で快適に動作する次世代のWebメールサービスが登場したことで、ローカルへのインストールが必要なメールクライアントは、まさに需要が減少していく過程にあった。
※セス・スピッツァー（Seth Spitzer）：Netscape時代にNetscape Communicator 4のメールクライアント・Messengerの開発を担当。Firefox 3.0までの開発にも関わった。
※Thunderbirdへの改称：これと近い時期に、Sunbird（カレンダー）、Songbird（メディア再生）などMozillaの技術に基づいたプロジェクトがいくつか開始された。Firebird、Thunderbirdに並んで韻を踏んだ形だったが、FirebirdがすぐにFirefoxに改称されたことで、他のプロジェクトは取り残された形となった。なお、Thunderbirdの名称はMozillaが商標を保有するため、Debianなどのパッケージリポジトリーには名称をIcedove（氷の鳩）と改めアイコンを変更した物が収録されている。
※3ペイン型：画面左にフォルダーツリー、右上にフォルダー内のメール一覧、右下に選択されたメールの内容が表示される形式。
※メールという媒体の発展性：当初はプレーンテキスト形式のみから始まったE-mailは、本文をHTMLファイルで提供するHTMLメールへと発展した。しかしセキュリティ脆弱性を突いた攻撃の的となってしまったことから、HTMLメールは一時退潮。E-mailという技術はそれ以上の発展が行われなくなっていった。
■拡張可能な メールクライアント 特に目立った特徴の無い、平凡でクラシックなメールクライアント。一般的なWindows用メールクライアントを狙った攻撃用HTMLメールの影響を受けない※メリットはあるものの、単に機能面だけで言えば、すでにその時点であった様々な競合メールクライアントに対する大きな優位性は無いのが実情だった。 そこでThunderbirdをThunderbirdたらしめたのも、拡張機能の存在だった。本体がカバーしきれない部分を自由度の高い拡張機能で補えることは、Firefoxゆずりのアドオンマネージャーを備えるThunderbirdならではの利点だった。
競合製品がすでに持っていた機能として、Mozillaブラウザー・スイートの頃よりカレンダー機能の搭載は望まれ続けていた。しかしながら、2001年よりMozilla Calendarとして開発プロジェクトが始まったものの、その成果が出るより前に、Mozillaによるブラウザー・スイートの開発は終了してしまう。プロジェクトは目標をFirefoxとThunderbird用の拡張機能開発と改め、後に、メールとより密に連携する拡張機能・Lightningとして、Thunderbird向けに集中することとなった。 2015年にはLightningはThunderbird 38で標準添付となり、すべてのThunderbirdユーザーが機能を目にすることとなった。その後、Firefoxに続いてのXULアドオン廃止によって拡張機能としてはプロジェクトを継続できなくなることから、バージョン78においてカレンダー機能を正式に統合。約20年の時を経てようやく、当初の目的が達成されたのだった。
プライバシー保護の観点では、送受信するメールを暗号化する機能のニーズも高かった。OpenPGPに基づいてメールを自動的に暗号化・復号する拡張機能・Enigmailは、2001年にMozillaブラウザー・スイート向けに開発を開始。その後はThunderbird用拡張機能として開発が継続していたが、こちらもXULアドオン廃止に伴って拡張機能としては維持できなくなることから、Enigmailは最終的に2020年、Thunderbird 78に統合されることとなった。
Webに比べて変化の速度が遅いメールの世界において、更新で機能が使えなくなることは、ユーザーの納得を一層得にくい。Thunderbirdの特定バージョンへの依存が激しくなりやすいXULアドオンの特性は、ここでも問題となった。FirefoxでFUELが提供された際、同様のにThunderbirdにも拡張機能向けのAPIセット・STEEL（Scriptable Thunderbird Easy Extension Library）が作成されたが、限られた機能しか持たなかったこともあり、拡張機能開発の主流にはならないままThunderbird 52で廃止。拡張機能開発の負担を軽減する望みはWebExensions APIへと引き継がれた。 WebExensions APIは、XULアドオンに比べて機能的な制約は大きい※ものの、Thunderbirdの更新後も安定して動作するため、効用は非常に大きい。Thunderbird 68でようやく利用可能となったWebExensions APIは、FirefoxのAPIセットからWebブラウザー固有の機能を除外し、メールの表示・編集などThunderbirdの各種機能に対応する機能を備えた形で、MailExtensionsとも呼ばれた。APIの拡充が続く間は移行期間としてXULアドオンに引き続き対応し続けたものの、バージョン78において一段落がついたことを以て、XULアドオンは完全廃止となった。
※WebExensions APIの制約：拡張機能をAPIベースで完全に再設計するコストを負担できない拡張機能が多くなると予想されたことと、運用傾向的に拡張機能の脆弱性の影響をFirefoxよりも受けにくいことなどから、ThunderbirdにおいてはWebExensions APIに対して「抜け穴」を作る余地が残された。この仕組みはExperimentsと呼ばれ、本来はWebExensions APIの提案用としてXULアドオン相当の自由度で新たなAPIを作成するための物である。この仕組みを用いて開発された拡張機能は、特定のバージョンのThunderbirdと密結合になるという、XULアドオンと同様の問題を抱えることとなる。
※攻撃の影響を受けない：この頃のWindows用メールクライアントではHTMLメールの表示にはIEのレンダリングエンジンが使われる事が多く、IEの脆弱性を突くHTMLによる攻撃が横行していた。ThunderbirdはGeckoエンジンを用いるため、その種の攻撃の影響を受けずに済んだ。
■続く改善 Thunderbirdとしての再生以後、拡張機能によらない基本性能の改善もあった。 Gmail以後のWebメール時代にThunderbirdが実用性を保つ上で、索引を使った全文検索による高速なメール検索機能は不可欠だった。実現のためには索引データベースを構築する必要があるため、簡易的なデータベース機能しか備えていなかったThunderbirdは、この機能に長らく対応できずにいた。Firefox 3.0においてブックマークと履歴の管理機能の強化のためにSQLite※が搭載されたことで、必要な技術要素が整い、Thunderbirdもバージョン3.0においてようやく全文検索機能を備えるに至った。 また、Thunderbirdが備えていたリモートアドレス帳機能はLDAPに基づく物で、閲覧専用という制限があった。CardDAV※に基づく読み書き自由なリモートアドレス帳が実現されたのはバージョン91で、バージョン1.0から約17年後のことだった。
目に見える部分での目立つ改善は限定的でも、目に見えない部分は変化している。Thunderbirdの登場から現在に至るまでで近年特に大きく変わったのは、Mozilla独自の様式に基づくC/C++での実装廃止の進行だ。 基盤層となるGeckoは可能な限りWeb技術の実装に注力し、それ以外はJavaScript製モジュールとしてGecko上に実装するのがFirefoxの現在の大まかな設計方針と言えるが、Thunderbirdについては、重要なモジュールがGecko寄りのC/C++での実装になっていることが多かった※。しかし、C/C++製モジュールの多さは新規に開発に関わる人を増やす上で単純にハードルとなる上、Gecko内部と密結合になっていることでGeckoそのものの抜本的改善を阻む一因にもなっていた。 今Thunderbirdは、そのような実装をGecko深部から引き剥がして、純然たるWeb技術ベースのソフトウェアに近付こうとしている。これには、まさしくThunderbirdの将来がかかっていた。そのことを理解するためには、Thunderbirdの開発体制の変遷を知る必要がある。
※SQLite：アプリケーション組み込み用の簡易的なデータベースライブラリー。データの読み書きに、本格的なデータベースと同様のSQLを使うことができる。
※CardDAV：WebDAVに基づいてアドレス帳の情報をやり取りする仕様。
※モジュールのC/C++での実装：Mozillaブラウザー・スイートの開発当時はまだJavaScriptエンジンの性能が高くなかったことから、各種メールプロトコルの実装や、ローカルに保存されたメールの処理など、実行時に速度が要求される箇所はC/C++で実装していた。Thunderbirdは開発の工数を少なく抑えるため、これらをそのまま使い続けていた。
■Thunderbirdの開発体制 Firefoxの開発の中心が一貫してMozilla Foundationとその完全子会社であるMozilla Corporationにあるのに対して、Thunderbirdの開発体制は度々流転を繰り返してきた。 Thundebrirdは当初は開発の中心地をFirefoxと同じくしていたが、MozillaのメインプロダクトはあくまでFirefoxであり、Thunderbirdの開発は傍流に留まっていた。Thunderbirdの開発体制を安定させるためとして、Mozilla Foundationは2007年、専門の子会社としてMozilla Messagingを設立しThunderbird開発の中心を移した。だが、Mozilla Messagingは組織としての独り立ちを模索したものの、独自の収益源を見出すには至れなかった※。Foundationは2011年、Corporation内の一事業であるMozilla Labsの配下にMozilla Messagingを吸収し、再び別の存続方法を模索することになる。 程なく、Firefoxはバージョン4.0のリリースを境にラピッドリリースの体制へ移行。Firefoxを開発の基盤とするThunderbirdもそれに追従する形でラピッドリリースへ移行したものの、Firefoxと完全に同じペースで開発を続ける事は難しく、その間目立った機能的な改善は無かった。FirefoxにESRが提供されるようになったことを承け、Thunderbird 17以降はFirefox ESRをベースに約1年に1回のリリースが行われる状態に戻ったが、新機能の開発はほぼ進まず、Firefoxの変更に追従する修正が主となっていた。 進歩の速いWebに食らいついていくために日々変わり続け、Webに影響を与える地位を狙いうるFirefoxと、すでに数十年前に進歩を終えたメールという仕組みを安定して扱えることが望まれ、革新的な展望は期待されないメールクライアント。Thunderbirdは変化の激しいFirefoxに追従することで手一杯になり、Firefoxは変化の遅いThunderbirdのための互換性維持が足枷となる。両者の隔たりはあまりに大きく、強力なライバル達を前にFirefoxの開発に集中したいMozillaにとって、Thunderbirdは扱いにくいプロジェクトとなっていた。 ThunderbirdがMozillaの一部であることは、FirefoxとThunderbirdどちらのためにもならない。MozillaはSoftware Freedom Conservancy※やThe Document Foundation※などへのThunderbirdの移管も視野に入れて検討を行ったものの、当面はMozilla配下に留め置く結論となった。だが、Firefoxに軸足を置くMozillaには、将来に渡ってのThunderbirdの居場所が無いことに変わりは無い。健全な独り立ちのために、本腰を入れる時が来ていた。 Mozilla FoundationおよびCorporationの運営下でのフルタイムの開発者の増員を経て、Foundationは2020年、改めて新たな子会社MZLA Technologies Corporationを設立。Mozillaからの独立を目指した再挑戦が始まった。 XULアドオンの廃止以後、レガシー技術の排除はFirefoxにおいても進められているが、Thunderbirdのそれは目的がやや異なる。Geckoとの結合が弱まり純然たるWeb技術ベースに近付くほど、ThunderbirdはFirefoxの開発の足手まといでなくなり、Mozillaから離れやすくなる。いつか来る独立の日のために、Thunderbirdの歩みはこれからも続く。
※Mozilla Messagingの苦戦：そもそもがメールという枯れた技術に関するプロダクトであること、Webメールサービスが普及しメールクライアントの需要が低迷していること、Mozilla全体としてソフトウェアそのものの使用料やサポート費用で収益を上げるモデルではないことなどから、これらの前提の上で独立した組織として運営していくことは難しかった。
※Software Freedom Conservancy：GitやSamba、Wineなどのプロジェクトを擁する非営利組織。各プロジェクトは会員として参加し、SFCからの支援を受ける形となっている。
※The Document Foundation：LibreOfficeを開発する非営利組織。ビジネス需要の高いThunderbirdにとっては有力な移管先の1つと考えられた。
■モバイル版Thunderbird MZLA Technologies Corporationは、Mozilla本体の強い非営利性に囚われず将来の収益の道を模索できるよう、Mozilla Messaging以上に高い独立性が認められている。モバイル版Thunderbirdはまさにその試みの1つだ。 モバイル版Firefoxがあるように、Thunderbirdにもモバイル版の登場は期待されていたが、実際の所、デスクトップ版Thunderbirdをモバイルに移植するのは非現実的であった。また、メールにおいては元々、IMAP※を用いることで複数デバイスから容易にメールを送受信できるため、敢えて移植する理由も弱かった。
とはいえ、IMAPで共有できるのはあくまでメールのみである。FirefoxがFirefox Syncを用いて複数デバイス間でユーザープロファイルを同期できるように、ThunderbirdもPCとモバイル端末上で設定情報や認証情報等を同期できれば、有用なのは間違い無い。 モバイル版Thunderbird実現にあたり、MZLA Technologies Corporationはデスクトップ版の移植でも、新規開発でもなく、第3の道として、既存のメールクライアントをThunderbirdへリブランディングする方法を取った。K-9 Mailプロジェクト※の成果を引き継いだのだ。 2024年現在、Thunderbird for Androidはバージョン8.0がリリース済みとなっている。現在の所は、デスクトップ版ThunderbirdからQRコードを使用してアカウント設定を引き継ぐことができるが、将来的にはFirefox Syncを用いた同期にも対応予定である。
※IMAP：Internet Message Access Protocol。メールの送受信のためのプロトコルの1つ。POP（Post Office Protocol）ではサーバー上のメールボックスが一時的な郵便受けに相当し、メールはローカルにダウンロードして保管するのが基本であるのに対し、IMAPはサーバー上に保管されたメールを正として、ローカルはそのキャッシュ扱いとなる点が大きく異なる。
※K-9 Mail：オープンソースのAndroid用メールクライアント。名称の由来はイギリスの長寿TVドラマシリーズ「ドクター・フー」に登場する犬型ロボット。
■法人利用 日本においてはThunderbirdは法人利用の事例が多い。筆者の業務上の顧客の中には、グループ会社も含めて数千から一万ほどのクライアントで運用されている例もある。これほどの規模の運用では個人の操作ミスによる損失を無視できないことから、誤送信事故の発生を防ぐ拡張機能が重宝されている。 時代の趨勢から、Microsoft 365のようなWebベースのソリューションへの移行例は増えているが、ローカル型クライアントならではの利点として、オフライン状態でメールを読み書きできることを重視する声も根強い。ローカル型クライアントは開発終了した物が多い中で、ビジネスを確実に支える足場になるものとして、Thunderbirdはまだまだ社会から求められ続けているのだ。■
ここまではWebブラウザーやFirefox、Thunderbirdといったプロダクトを軸に語ってきた。最後に、Firefoxに関わるコミュニティという「人」の視点でも、筆者の知る範囲のことをいくつか語っておきたい。
■開発コミュニティ 一般的な企業での製品開発は、社内でチームを編成して責任を持って行う所だが、オープンソースにおいては、開発はプロジェクト主宰者と開発者のコミュニティとの協同作業となる。Firefoxなどのように、プロジェクト主宰者に雇用された開発者が開発を主導する場合であっても、その点は変わらない。 開発者のコミュニティと言っても、具体的に組織化された何かがある場合は希だ。多くの場合、オープンソースに関わる個人の開発者はあくまで個人として活動している意識が強い。ここで言うコミュニティとは、共通の価値観に基づく仲間意識をゆるやかに共有する人々を指す。その中で、特定のプロジェクトに関わる人々を外から見て特に「Firefoxの開発コミュニティ」のように呼ぶ形である。 開発コミュニティの人々の動機は様々だ。Firefoxのファンとして開発に協力する人、Mozillaの思想に共感して自身と共通の目標のために協力する人、自社の利益のために開発に協力する人、等々。それぞれが個別の目的のために集まりつつ、一つのプロダクトを良くするために協力し合っている。 FirefoxやThunderbirdでは、伝統的にバグトラッキングシステム※のbugzilla.mozilla.org※が開発コミュニティの活動場所となってきた。しかし近年ではGitHubを利用する開発者が増加し、プロジェクト独自のシステムでのやり方よりも、GitHub式のやり方を好む人々が増えてきた。そのため、Mozillaは開発コミュニティの中心地をGitHubに移していく計画を発表している。
※バグトラッキングシステム：ソフトウェアの開発プロジェクトにおいて、発見された不具合や未実装の機能などの状況を記録・管理するための仕組み。GitHubのイシュートラッカーも、簡易的なバグトラッキングシステムである。
※bugzilla.mozilla.org：Mozillaが開発したバグトラッキングシステム「Bugzilla」の、Mozilla自身が運用しているインスタンス。ソフトウェアとしてのBugzilla自体はオープンソースであり、Mozilla以外のプロジェクトでも課題の記録・管理のために使われている例が多数あるため、Mozillaが運用している物を指す場合はこのように呼ぶ。
■翻訳コミュニティ Firefoxのように国際的なソフトウェアでは、ソフトウェアの表示テキストやWebページなどの各言語のリソースは、その言語を母語とする人々のボランティア活動により維持されていることが多い。そのような人々が形成するコミュニティを翻訳コミュニティと呼ぶ。2024年時点でFirefoxは103の言語で使用できるが、英語以外の言語はすべてが翻訳コミュニティの手による物だ。 MDN Web Docsの技術資料も、原本となる英語以外の言語版はコミュニティが翻訳を行っている。近年は機械翻訳の精度向上により、機械翻訳の結果をそのまま表示するケースも増えているが、技術文書といえど自然言語で書かれた文書の完全な機会翻訳は難しく、正確な情報を母語で得られるようにするために今も少なくない人々が貢献を続けている。
■ユーザーコミュニティ その技術や製品自体の知名度が低く、単純に使用すること自体にも知識や手助けが必要となる場面では、純然たるユーザー同士での互助的な動きが生じることがある。それがユーザーコミュニティである。 Mozillaにおいては、ソースコードが公開された1998年より運営されているMozillaZineが最も有名なユーザーコミュニティだ。MozillaZineでは独自にMozilla関係のニュース情報を提供したほか、フォーラムでユーザー同士の相互サポートが行われたり、技術的な知見をナレッジベースに集積したりもしていた。日本語圏においては、日本語版のMozillaZine.jpが役割を担っていた。 日本においては、より日本独自色の強いコミュニティとして「もじら組」もあった。もじら組はMozillaブラウザーの開発版の節目のリリースを記念して開かれたコミュニティイベント「Mozilla Party JP 1.0」をきっかけに立ち上げられ、日本語話者向けの情報やリソースを提供した。また、bugzilla.mozilla.orgの独自の日本語版であるBugzilla-jpの運営や、Mozillaプロジェクト本体で作業が難航していた国際化の問題の独自改修版ビルドを提供するなど、開発コミュニティとしての役割も一部担っていた。 MDN Web Docsに技術情報が集約されるようになり、support.mozilla.org（SUMO）でサポート情報を集積・提供するようになるなど、Mozilla公式の取り組みが発展していくに連れて、これらユーザーコミュニティの役割は次第に薄れていった。活動を停止したコミュニティもあるが、MozillaZineフォーラムなど一部のコミュニティは現在も運用が続いている。
■公式アフィリエイト Mozilla Foundationは世界各地域でのマーケティング活動や現地語での情報提供、現地のコミュニティ活動の支援などのために、公式アフィリエイト※として2004年にMozilla EuropeとMozilla Japanを、2005年にMozilla Chinaを設置した※。ここでは特に、日本に置かれたMozilla Japanについて語ろう。 Mozilla Japanは、Netscape日本法人最後の一人であった瀧田佐登子氏※を中心に設立された。当初は企業や行政など直接的にはコミュニティと接しにくい層に対する顔として振る舞うことや、アメリカにあるMozilla Foudnationと日本の既存ユーザーコミュニティとの橋渡し役に徹し、既存のユーザーコミュニティと連携して活動していくことが期待されたが、ボランティア活動ゆえの難しさのためユーザーコミュニティ主導の活動は縮小していき、次第にMozilla Japanに求められる役割が拡大していく。2006年には日本独自のプロモーション用マスコットキャラクターであるフォクすけ※を発表、2007年にはMozilla 24と題した大規模イベントを開催し、その後も開発者を対象としたイベントの主催など、自ら活動の旗振りを行うようになっていった。 しかしながら、2017年にはMozilla Foundationが各地のアフィリエイトの活動をより直接的に差配する方針へと転換したことを承け、諸権利をMozillaに返還して公式アフィリエイトの関係を終了。Mozilla Japanが管理していた各種ドメインは、元職員や関係者などによって構成される有志のユーザーコミュニティ※に移管された。 なお、法人自体は名称をWebDINO Japanへ改めた上で、特定のブラウザーに囚われずにインターネットの環境基盤に貢献する活動を継続している※。
翻訳コミュニティなど、Mozilla Japan設立以前から目的を持って自主的・積極的に活動していたコミュニティはその後も継続しているものの、それ以外のMozilla Japanの関与度合いが大きかったコミュニティ活動は、公式アフィリエイトの関係解消に伴って事実上終了した形となった物が多い。Firefoxのシェアや社会の中での注目度の低下もあり、日本語圏でのMozillaのコミュニティ活動は全体的に下火となっているのが現状である。
※公式アフィリエイト：組織としては独立しているが、Mozilla Foundationから公式にロゴなどのブランドの使用を許可された上で予算を割り当てられ、その地域でのオフィシャルの顔として振る舞うことが認められている組織。
※中国の公式アフィリエイト：中国語圏にはMozilla Chinaとは別にもう1つ、Mozilla Taiwanが存在するが、こちらは台湾現地コミュニティによって設立された非公式の法人である。
※瀧田佐登子（TAKITA Satoko）：東芝系列のグループ会社にてITエンジニアとしてのキャリアをスタート。東芝がNetscape製品をライセンス販売するにあたっての折衝役を経てNetscapeに転職し、サポートエンジニアとして勤務。この頃に「文字化け」の概念を英語圏に知らしめた。法人としてのNetscapeの消滅以後からMozilla Japan設立までの間は、日本最後にして唯一のNetscape法人サポート担当者として個人で業務を行っていた。現在もWebDINO Japanの代表を務める。
※フォクすけ：2000年代の「萌え擬人化」ではなく、いわゆる「ゆるキャラ」の文脈のキャラクター。デザインは筆者による。Mozilla Japanの公式アフィリエイトとしての関係終了後は、Mozilla Foundationに権利が移転されている。
※Mozillaの日本語コミュニティ：Mozilla Japanという公式アフィリエイトがなくなって以後のそれは、かつてのもじら組のように明確な組織体があるわけではなく、ドメインなどの管理権限を任された数名のボランティアを含む緩やかなコミュニティとなっている。
※WebDINO Japanの活動：瀧田氏はMozilla Japan当時から、Firefoxというブラウザーのプロモーションとは別に、IoT（Internet of Things）などの分野での普及・啓発や若年層への技術教育活動にも力を入れていた。Mozillaの公式アフィリエイトとのしての立場を離れて以後の活動の方が、瀧田氏にとって本懐だったと言える。
■オタク文化コミュニティともえじら組 Firefox 1.0がリリースされた前後の時期、Windows Meの不安定さ※を「ドジっ子」に例えて萌え擬人化※した「Meたん」を起点とした「OSたん」など、ソフトウェアやサービスの擬人化キャラクターを描くことが一部のイラスト創作者の間で流行していた。PixivなどのCGMサービス※の利用が広まる以前の世代のデジタルイラスト創作者達は、Webサイトの運営などを自分自身で行う必要があった関係で総じてIT知識に明るい傾向があり、使用するソフトウェアやサービスへの愛着をキャラクター化した結果であった。inugamix氏によるFirefox子・Thunderbird子も、そのような潮流の中に生まれた存在だ。 本書を刊行するもえじら組※は、2004年のFirefox 1.0リリースを記念して、Firefox子とThunderbird子のファンイラストを公開していたイラスト創作者達に筆者が連絡を取り、合作同人誌を制作するためのサークルとして活動を開始した。その後は筆者単独で活動を継続していたものの、商業連載「シス管系女子」※の負担増もあり実質的に活動休止状態となっていた。本書は、活動最盛期にFirefox子のコスプレにて売り子に協力していたつぴ氏との間で出た「Firefox子の写真集を記念に作っておきたい」というアイデアに端を発し、Thunderbird子のモデルを依頼するにあたって行った秋の「」氏との打ち合わせ中で出た「技術的な背景についても語る」案を取り込んで制作した物である。
もえじら組の活動最盛期は、筆者がMozilla Japanに半常駐の形でマーケティング活動に協力していた時期と重なっていた。しかし、2006年にMozilla Japan主導で行われた秋葉原でのプロモーション活動において、コミュニティメンバーの紹介により偶発的に参加したメイド衣装の女性達がメディア記事に大きく採り上げられた際、ユーザーコミュニティから「Firefoxにオタクのイメージが付く」と批判を受けたことから、炎上※の危険があると判断し、すでにもえじら組としての活動を公然と行っていた筆者がMozilla Japanに関わっていることは、後年まで自主的に非公表としていた※。 しかしそのような危惧とは裏腹に、2007年にはWindows 7の非公式キャラクター「窓辺ななみ」、2010年にSilverlightの台湾におけるキャラクター「藍澤光」、2011年にWindows Azureの公認キャラクター「クラウディア・窓辺」が発表されるなど、IT技術が公然と美少女キャラクター化される事例は相次いだ。その後も鉄道会社や地方自治体などで美少女キャラクターがプロモーション用に制作される事例※は増えており、筆者としては隔世の感を覚えるばかりである。
■これからのコミュニティ 2019年末から世界的に流行した新型コロナウィルス感染症の影響でコミュニティイベントの開催が多数見送られたこと、Firefox最盛期にコミュニティで活動していた人々のライフステージが変化したことなどもあり、日本におけるMozilla関連のコミュニティ活動には断絶が生じている。 その一方で、Firefox派生ブラウザーのFloorpを学生主導のチームが開発するなど、新たな取り組みも生まれている。しがらみに囚われずに若い人々が活動できるブルーオーシャンとして、Mozillaは今、格好の題材と言えるのかもしれない。■
※Windows Me：Windows 98以後、Windows XPが登場するまでの繋ぎ役として登場したOS。非常に不安定だったことで知られる。当時Microsoftに在籍していた方曰く、設計的にも混迷を極めていたとのこと。
※萌え擬人化：対象物をモチーフとした美少女キャラクターをデザインし描くこと。「萌え」は、性的興奮あるいは可愛らしい物への興奮を喚起された様を表す「燃え」の誤変換に由来する表現。
※CGM：Consumer Generated Media。ユーザーが投稿する文章や画像、動画、音声など、ユーザーが作成した情報を価値の中心とするサービスの総称。食べログなどのレビューサイト、クックパッドなどのレシピ共有サイト、YouTubeなどの動画共有サイトなどが代表的な例。
※もえじら組：名称はユーザーコミュニティ「もじら組」に由来し、Mozillaの萌え擬人化キャラクターを描くことから、このように命名された。
※シス管系女子：日経Linux誌にて2011年9月号より連載開始したLinuxシェルコマンド解説マンガ記事。日経Linux誌休刊後は日経ソフトウエア誌にて「ITエンジニア1年生のためのまんがでわかるLinux」として連載を継続中。
※炎上：インターネット上で批判・非難の声が拡散・増幅され収拾不能となること。
※自主的な非公表：当時よりMozilla Japanの方々には、筆者がMozilla Japanにおいてフォクすけを含むいくつかのデザインを手がけたことは公表して問題無いと言って頂けていた。非公表はあくまで筆者自身の判断であった。
※美少女キャラクターによるプロモーション：衣装・デザインが過剰に性的であるなどの批判を受ける事例はあるものの、漫画・アニメ調の美少女キャラクターを立てること自体は一般化しているのが現状である。
マイクロソフトへの挑戦 ネットスケープはいかにしてマイクロソフトに挑んだのか （毎日コミュニケーションズ刊、ヨシュア・クイットナー/ミシェル・スレイターラ著、安蒜泰樹訳）
Webの創世 World Wide Webはいかにして生まれどこに向かうのか （毎日コミュニケーションズ刊、ティム・バーナーズ＝リー著、高橋徹監訳）
Firefox 3 Hacks （オライリージャパン刊、江村秀之/池田譲治/下田洋志/松澤太郎/dynamis著）
擬人化たん白書（アスペクト刊）
Firefox子（画廊犬神堂） http://inu.imagines.jp/gallery/firefox.html
Thunderbird子（画廊犬神堂） http://inu.imagines.jp/gallery/thunderbird.html
WWW発明のバーナーズ・リー氏にナイトの称号（ITmedia NEWS） https://www.itmedia.co.jp/news/articles/0407/16/news055.html
ネットスケープ社が「Netscape Navigator」の無償配布開始 （INTERNET Watch） https://internet.watch.impress.co.jp/www/article/980123/freenn.htm
AOL、Netscapeを42億ドルで買収。Sunとも業務提携（PC Watch） https://pc.watch.impress.co.jp/docs/article/981125/aol.htm
オープンソースの誕生（Shuji Sado） https://shujisado.com/2017/05/17/612085/
resignation and postmortem.（nomo zilla） https://www.jwz.org/gruntle/nomo.html
辞職そして追悼。（YAMAGATA Hiroo: The Official Page） https://cruel.org/jwz/nomo.html
The Inside Track on Firefox Development （Inside Firefox、インターネットアーカイブ） https://web.archive.org/web/20111116060139/http://weblogs.mozillazine.org/ben/archives/009698.html
Success elicits change for maker of Firefox（The New York Times） https://www.nytimes.com/2007/05/21/technology/21iht-firefox.1.5799992.html
主要開発者が語るグーグルとFirefoxの深い関係（CNET Japan） https://japan.cnet.com/article/20111747/
Googleの技術者が語る「Firefoxへの深いかかわり」（ITpro） https://xtech.nikkei.com/it/article/NEWS/20060501/236661/
AppleのSafari開発の経緯を語った投稿（重箱の隅/X.com） https://x.com/mshk/status/1538557173156151296
Ancient Browser-Wars History: MD5-Hashed Posts Declassified （Eyes Above The Waves） https://robert.ocallahan.org/2018/01/ancient-browser-wars-history-md5-hashed.html
古代のブラウザ戦争の歴史：MD5ハッシュ化された投稿の機密解除 （outsider reflex） https://piro.sakura.ne.jp/latest/blosxom.cgi/mozilla/misc/2018-06-06_roc.htm
Browser and GUI Chrome (Jakob Nielsen's Alertbox、インターネットアーカイブ) https://web.archive.org/web/20120825022734/http://www.useit.com/alertbox/ui-chrome.html
Google Chrome Extensions（millennium） https://web.archive.org/web/20120302095051/http://www.bengoodger.com/2009/12/google-chrome-extensions/
Google Chrome Extensions（翻訳）（outsider reflex） https://piro.sakura.ne.jp/latest/blosxom/mozilla/extension/2009-12-16_google-chrome-extensions.htm
「Google Chrome」のリリース間隔が6週間→4週間に ～第3四半期公開のv94から実施（窓の杜） https://forest.watch.impress.co.jp/docs/news/1310474.html
新Webエンジン「Blink」—GoogleはなぜWebKitを捨てたか？ （ASCII.jp） https://ascii.jp/elem/000/000/778/778554/
XUL Planet（Internet Archive） https://web.archive.org/web/20090225221713/http://www.xulplanet.com/
Why Did Mozilla Remove XUL Add-ons? （Il y a du thé renversé au bord de la table !） https://yoric.github.io/post/why-did-mozilla-remove-xul-addons/
なぜMozillaはXULアドオンを廃止したのか？（翻訳） （outsider reflex） https://piro.sakura.ne.jp/latest/blosxom/mozilla/xul/2020-08-22_why-did-mozilla-remove-xul-add-ons.htm
Mozilla、オンラインサービス「Weave」を開発 （ITmedia エンタープライズ） https://www.itmedia.co.jp/enterprise/articles/0712/25/news044.html
Firefoxの同期機能「Weave 1.0」正式リリース Weaveサーバのバージョン1.0も同時公開（CodeZine） https://codezine.jp/article/detail/4888
mozilla-services/syncstorage-rs: Sync Storage server in Rust（GitHub） https://github.com/mozilla-services/syncstorage-rs
Thunderbird 78に未対応のアドオンのThunderbird 78対応の 現状と課題について（ククログ） https://www.clear-code.com/blog/2020/8/7.html
Inside a super fast CSS engine: Quantum CSS (aka Stylo) （Mozilla Hacks - the Web developer blog） https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-engine-quantum-css-aka-stylo/
超高速エンジンの内部：Quantum CSS（別名Stylo）- 前編（POSTD） https://postd.cc/inside-a-super-fast-css-engine-quantum-css-aka-stylo/
The whole web at maximum FPS: How WebRender gets rid of jank （Mozilla Hacks - the Web developer blog） https://hacks.mozilla.org/2017/10/the-whole-web-at-maximum-fps-how-web
グーグルに帝国解体の危機、米司法省がクローム売却も要求 （MIT Tech Review） https://www.technologyreview.jp/s/350500/googles-antitrust-gut-punch-and-the-trump-wild-card/
グーグル・ペイメントの禁止はMozillas Firefoxを殺すのか？（Tuta） https://tuta.com/ja/blog/will-ban-on-google-payments-kill-mozilla-firefox
Firefoxの開発元Mozilla、広告効果測定企業を買収 プライバシー保護への取り組みに疑問が湧く（AdGuard） https://adguard.com/ja/blog /firefox-privacy-ad-targeting-anonym.html
MozillaはFirefoxへのユーザーの愛を取り戻せるのか？ （YAMDAS現更新履歴） https://yamdas.hatenablog.com/entry/20240818/love-firefox-again
Mozilla Minotaur Project Formally Launched（MozillaZine） http://www.mozillazine.org/articles/article3000.html
Mozillaベースの軽量メールソフトMinotaur（スラド） https://srad.jp/story/03/04/03/0026256/
Thunderbird Time Machine: A Look Back At Thunderbird 0.1 （Thunderbird Blog） https://blog.thunderbird.net/2022/07/thunderbird-time-machine-2003-a-look-back-at-thunderbird-0-1/
Mozilla、「Thunderbird」の受け入れ先に関する調査を完了（窓の杜） https://forest.watch.impress.co.jp/docs/news/1058872.html
「Android版Thunderbird」にリブランド予定のメールアプリ 「K-9 Mail」がセキュリティ監査を完了（GIGAZINE） https://gigazine.net/news/20230721-thunderbird-android-k-9-mail-security-audit/
秋葉原でメイドさんがWebブラウザ「Firefox」を配布（ITpro） https://xtech.nikkei.com/it/article/NEWS/20060710/242844/render-gets-rid-of-jank/
情報へのアクセスの仕方の自由と多様性を尊んだW3CのWeb標準技術仕様の理想像に共感した僕は、1999年当時、それによく対応していたMozillaのブラウザーに魅せられました。そして今度は、Web技術ベースの拡張機能という仕組みによって、世界を誰かに変えてもらえるのを待つだけの立場から、僕自身もソフトウェアで世界を変えていける立場になれることを実感しました。また、開かれた開発体制を通じて開発の知見にアクセスできたことから、手を引かれるように技術を学ぶこともできました。世界を拡げてもらえたことで、僕はMozillaに一層の思い入れを持つようになっていきました。「もえじら組」の活動は僕にとって、Firefox子・Thunderbird子というinugamix氏の生み出したキャラクターへのファン活動であると同時に、技術以外の角度からのMozillaへのファン活動でもあると言えます。 本文に記したとおり、Firefox子を題材とした写真集の話自体はもえじら組の活動最盛期からあったのですが、なんやかやで有耶無耶になってしまっていました。「カメラが上手な人は大勢いるけれど、写真集を作るなら、Firefox子への思い入れがあるPiroが撮るのがいいと思う」とのつぴ氏の声に背中を押され、改めてカメラを手に取り本格的にコスプレ撮影に力を入れ始めたのは、2022年末のことでした。 「どうせならThunderbird子との合わせも！」ということで、コミケの更衣室につぴ氏が持ち込んでいたフォクすけのぬいぐるみを見付けて声をかけてくださったことからご縁ができていた、宇宙探査機「はやぶさ」のコスプレで知られる秋の「」氏にお声がけし、出演にご快諾をいただけたのも大変ありがたかったです。 2年間かけて撮りに撮った1万枚くらいの写真の中から選んだ180枚ほどの写真を詰め込んで、本書はどうにか形になりました。気が付けばもう、Firefox 1.0から20周年の節目の年。そこにギリギリ間に合わせる形でこうしてメモリアルな本を作れたことには、とても感慨深いものがあります。
本書制作中に慶応大学で「Ted Nelson 過去と未来を語る— ハイパーテキストを生んだ現代のダ・ヴィンチ」と題して開かれたシンポジウムにおいて、本書冒頭で名前を挙げたテッド・ネルソンまさにその人が、偽情報の意図的な流布が昔に比べて効率的且つ容易になっていることに、危機感を示したといいます。集権的な中央を持たず自由で多様な言論によって成り立つWebという仕組みは、負の側面として野放図なデマ拡大のリスクも孕んでおり、今それが現実になってしまっている、そんな感覚が僕にはあります。 Mozillaは大企業によるWebでのプライバシーの侵害と囲い込みによる多様性の喪失を課題として、それに抗うことを旗印にしましたが、さらに大きな脅威によってそれ以前の土台の部分から社会が危機に見舞われている今のこの状況下で、Mozillaの掲げるものの意義は、社会の支持を得られるのでしょうか。 これからWebは一体どのようになっていき、社会はこの問題をどう乗り越えていくのか。僕が共感した自由と多様性が今後も保たれて、10年、20年先の未来が明るいものとなっていることを願うばかりです。
Moezilla Historica
発行者： もえじら組 発行日： 2024年12月30日 著者： Piro/結城洋志 撮影協力： つぴ（モデル） 秋の「」（モデル）
https://piro.saura.ne.jp/moezilla/