Firefox向けアドオン開発者
結城 洋志（Piro）
1982年生まれ、大阪府出身。個人としてFirefox向けアドオン「Tree Style Tab」などを長年にわたり開発・公開している。2006年、現在も所属する株式会社クリアコードの設立に参画。業務ではFirefoxおよびThunderbirdの法人向け技術サポートに従事する傍ら、2011年より日経Linux誌にてLinuxコマンド操作解説漫画『シス管系女子』を連載。2015年に開始された、OSS開発者を継続的に増やすプロジェクト「OSS Gate」の運営にも関わる。
「Tree Style Tab（ツリー型タブ。以下、TST）」という、オープンソースのFirefox向けアドオンがあります。ブラウザのタブを垂直に配置し、開いたタブ同士の親子関係を「ツリー状」にインデントして表示できるこのツールは、20年近くにわたり国内外のパワーユーザーから利用されてきました。
作者はFirefox向けアドオン開発で知られる、結城洋志（Piro）さんです。現在もTSTの開発の手を止めることなく、これまでに1万1000回以上のコミットを重ねています。 長年にわたる開発の原動力は、やはり「理想のタブUI」を追い求めてのものなのでしょうか？ そう尋ねると、Piroさんの答えは意外なものでした。
「『何か理想的なUI像を持っていて、それを実現するために頑張っている』わけではありません。場合によっては、開発を終了してもいいと考えています」
ではなぜ、Piroさんは途方もない労力を割いてまで、メンテナンスを継続してきたのでしょうか？ 根底を貫いていたのは、自身の人生を大きく変えたOSSという文化への、ひとりのエンジニアとしての思いでした。
「Web標準」に魅入られて、Mozillaを使いたくなったけれど
――20年以上もタブに関わる拡張機能を開発し続けているというのは、やはりご自身の中に何か「理想のタブのあり方」が存在し、それに近づけるために開発を続けてこられたのでしょうか。
結城：実のところ「理想的なUI像があって、それを実現するために頑張っている」わけではありません。
僕が何かをつくるときの動機は、多くの場合「ここがこうなっていればいいのに」というささやかな不満を解消するためです。
現在のTSTのツリーUIも、その小さな不満解消を積み重ねる過程で、結果的に形成されたものに過ぎません。
――理想のUIが、あるわけではない。とはいえ、変則的なUIなら、例として、1行に収まらないタブを折り返させ、2行、3行にわたって表示させる「多段タブ」のような選択肢もあったかと思います。なぜ、TSTでは「ツリー型」に特化させているのでしょうか。
結城：結果的に、僕の認知スタイルに一番合っていたからでしょうか。
もともとは「iRider」というツリー型のUIを採用したIEコンポーネントブラウザを、「livedoor Reader」などを開発したmalaさんという方が「今までにない新しいインターフェースだ」として紹介しているのをネット上で見たのが発端です。
それを知った僕は「自分のスキルでも、同じようなUIを実装できるのではないか」と技術的な腕試しのつもりで、2005年、TSTの前身である「Tabbrowser Extensions（TBE）」というアドオンにタブのツリー表示機能を実装してみました。
あくまで腕試しのつもりだったのですが、実際に使用してみると、これが案外使いやすかったんです。
僕はブラウザで調べ物をしている途中でリンクに触れる際、新しいタブにてリンク先を開く癖があります。そして、開いたページで新たなリンクが出てきたら、またしてもそれを新しいタブで開く。連鎖的にタブを開くことを繰り返していると、気がつけば20個、30個とタブが爆発してしまいます。多い時では200個くらい、閉じていないタブが残り、「脇道にそれる前に見ていたのはどのページだったっけ ？」というのが分からなくなってしまうんですね。
しかし、ツリーUIであれば、インデントの位置を見るだけで、タブ同士の関係性が視覚的にパッと把握できます。「この調べ物の起点はここだったから、ここをクリックすれば元々調べていた部分にすぐ戻れるな」という具合に。
恐らく僕は、言語的に情報を処理するよりも、視覚的・空間的に物事を把握するという認知タイプの傾向が強いのだと思います。そして腕試しで偶然つくった機能が、僕のこの認知スタイルにフィットした。こうした理由から、現在もツリー型に特化したTSTを開発し続けています。
――前身のアドオンがもともとあったのですね。では、Firefoxの拡張機能を開発するようになった経緯について教えてください。まず、Mozilla製品との出会いは？
結城：始まりは高校時代に遡ります。
当時、僕は漫画やイラスト制作活動を行っており、その作品を発信するためのWebサイトをつくっていました。しかし、コンテンツを充実させていくうちに、ページの読み込みに時間がかかるという問題に直面しました。
そこで「2ちゃんねる」（現5ちゃんねる）の掲示板で「どうしたらいいか」とアドバイスを求めたところ、「CSSというものを使うといいよ」と言われ、その入門書として『スタイルシートWebデザイン』（※1）という本を薦められたんです。
この本が、僕にとって大きな転機になりました。
（※1）：スタイルシートWebデザイン : CSS2完全解説（すみけんたろう著 技術評論社, 1998.8）
――というと？
結城：それは技術書としては、非常に「思想が強い」本だったんですよ。「正しいWebの仕様とは、Web標準とは、こういうものだ」という原理原則を繰り返し示すような書籍でした。
そこに書かれていた、「テキストデータの『意味』と、それを画面上で表示するときの色や形・余白や文字の大きさといった『見せ方』を分けて定義することで、『画面に表示する』や『印刷する』といった利用の仕方以外にも『音声で読み上げる』のような全く別の可能性が拓けるようになる」という考え方に僕は大きな衝撃を受け、読み終える頃にはすっかり「Web標準信者」のようになっていました。
しかし、当時のブラウザは、仕様書にあるはずのCSSの機能をまだ正しく描画できないことが多かったのです。W3Cが定めるWeb標準の仕様に対して、ブラウザ側の実装が追いついていなかったんですね。
そんな中、当時の他のブラウザと比べて仕様に忠実で綺麗なレンダリングを実現していたのが、Mozillaの「Geckoエンジン」でした。また、ブラウザとしてのUI自体もXMLやCSS、JavaScriptというWeb標準の技術でつくられていると知り、「Web標準に基づいたサイトを閲覧できるソフトウェアが、Web標準の技術でできている。美しいな」と魅了され、Mozillaのブラウザを使うようになりました。
――そこから、なぜご自身で拡張機能の開発を？
結城：発端は、他の人がつくったアドオンを改修しようと思ったことでした。
2001年ごろ、僕は「Execute Applications」という、Mozillaブラウザの右クリックメニューを拡張するアドオンを使っていました。これは、リンク上などで右クリックを行うと、対象のサイトをInternet Explorerなどの別のブラウザですぐに開けるようになるアドオンでした。当時のWebサイト制作で「IEで表示崩れが起きていないか」を確認するのに重宝していたんです。
ですが当時のMozillaブラウザはまだまだ開発途上で、拡張機能は各バージョンへの依存が激しく、本体がアップデートされるたび、アドオンがすぐに動かなくなってしまうという事態が繰り返されていました。 自分としては、アドオン側のアップデートを待たずとも使い続けたい。幸い、WebサイトをつくっていたのでHTMLやCSS、JavaScriptの知識はある。そして、Mozillaブラウザの拡張機能は、そのWeb標準の技術でいじれる。
「ならば、自分で直してしまおう」……そう思って手を出し始めたのが、拡張機能開発の始まりです。
――そこから、どのようにTSTへと繋がっていくのでしょうか。
結城：プログラミングの初心者は、「最初につくったもの」を育てすぎてしまうことがあるものでして。
僕はExecute Applicationsを独自に改造して、「ContextMenu Extensions」というアドオンをつくりました。しかし、とにかくコードを書くのが楽しい時期だったため、「できそうだから」と思いついたものを何でもこのアドオンに追加してしまったんですね。
そのひとつが、ブラウザの「タブ」に対して抱いていた不満です。当時のMozillaブラウザ（Mozilla Application Suiteのバージョン0.9.5）ではようやく公式にタブ機能が実装されたのですが、当時は本当に「ただ、タブがあるだけ」というような状態でした。
タブの並べ替えも、リンクを隣のタブで開くことも、JavaScriptのポップアップをタブで開くことも、セッションの復元もできなかったんですね。
他の一部ブラウザでは当たり前にできるような機能も備わっていなかったため、ContextMenu Extensionsに、自分で独自のタブ機能を実装していったわけです。
――右クリックメニューの拡張を主旨としたアドオンに、そうした別の機能を次々に足した？
結城：はい。流石に分けた方がいいと思い、2002年に、タブに関連する機能だけをスピンアウトさせて独立したアドオンをつくりました。
それが、先ほど触れたTSTの前身・Tabbrowser Extensionsです。こちらでは、ユーザーからの要望によく対応して機能を追加したり、「プログラミングの『腕試し』をしたい」との気持ちがあったりして、それこそ「多段タブ」や、タブのグループ化、そしてツリー表示など、さまざまなタブの表示形式や機能を盛り込んで発展させていきました。
すると、アドオンが極度に肥大化してしまったのです。致命的だったのは、2006年。Firefox 1.5から2.0へアップデートされるタイミングでした。
このころ、Firefox本体にセッションの復元などが標準実装され、タブに関する機能が充実し始めました。それらが、TBEの独自の実装と完全に競合してしまったのです。競合した箇所が、まさに肥大化した実装の土台部分であったため、 仕様変更に合わせてコードを書き直すには、途方もないコストがかかる状態でした。
またしても、「育てすぎてしまった」わけです。結果、自分自身が本体を新しいFirefoxにアップデートできなくなるという「ロックイン」状態となりました。
結城：自分が便利に使うためにつくっていたはずなのに、自分の使わない機能の保守のせいで身動きが取れなくなる。これは完全に本末転倒でした。
ならばもう、使わない機能は捨てて改めて整理するしかない。それで、当時自分が主に使っていた「ツリー表示」だけに特化させたのが、現在のTree Style Tabです。
プロジェクト存続を最優先に、かつユーザーを「ロックイン」させないために
――TSTの開発においては、何に最もこだわっていますか？
結城：主眼に置いているのは、「プロジェクトのスコープの明確化と統制」、そして「過去に学んだGUIの原則論を忠実に守ること」の2つです。
――詳しく教えてください。
結城：まずスコープについて。お話しした通り、僕はTBEで野放図な多機能化を行った結果、「ロックイン」を経験してしまいました。
なので、TSTでは「ツリーに関係ない機能は入れない」というルールを設けて、対外的にも示すようになりました。
現在でも、ユーザーからは「タブの検索機能が欲しい」「フォルダ分け機能が欲しい」など、TSTにあらゆる機能を載せてオールインワン化してほしいという要望がたびたび寄せられます。しかし、そこに手を出せばまたメンテナンスが破綻してしまい得る。
そこで、機能拡張の要望があっても、ユーザーにはまず、その機能を持つ他のアドオンをTSTと組み合わせて使うよう案内する。他のアドオンとの連携部分で不具合が出たら、直す。このようにしてスコープを絞り込むことで、長く開発体制を維持できるように心がけています。
――では、「過去に学んだGUIの原則論を忠実に守っている」とのお話についてはいかがでしょうか。
結城：大学の授業や技術書で学んだマンマシンインターフェースの大原則など、いろいろとありますが、分かりやすい例を挙げると「Firefox本体のUIに徹底的に揃える」ようにしています。自分でも呆れそうになるほど、公式UIを真似しているんですよね。
こうしているのは、Firefoxのタブの操作に慣れた人が戸惑わずにTSTを使えるようにしたい、という理由が一番大きいです。ただ、それだけでなく、独自のUIをつくり込むことでユーザーを縛ってしまうのも嫌なんです。僕は、「ユーザーをTree Style Tabにロックインさせたくない」んですよ。
Firefox本体も進化し続けており、2025年のバージョン「136」では、タブを縦に並べられる「垂直タブ」が公式に導入されています。そうして本体が進化していく中で、ユーザーがもしもある日「TSTはもう要らないや」と思ったら、このアドオンをポイっと捨てて、公式の用意するタブ機能へ簡単に移行してしまえるのが理想なんです。
なのでタブの上にマウスカーソルを乗せたときのハイライトのされ方や、ドラッグして並べ替えるときの操作感などを、極力公式に揃えています。そうしておけば、「Firefox本体のタブからTSTに乗り換えるとき」や、「Firefox本体のタブにまた戻るとき」の移行コストや学習コストが小さく済むからです。
また、これには僕自身の心理的な負担を減らせるというメリットもあります。UIの配置を自分ひとりで決めると、その決断に対する責任をすべて負うことになります。ですが、迷った際にはとりあえず公式に合わせれば、考えなければならないことは減る。公式UIに追従している背景には、そうした側面もあるのです。
――徹底してFirefoxの仕様に追従・再現するのは、開発側としては大変な苦労があるのではないですか？
結城：もちろん、苦労はあります。公式の仕様が変わるたびに、毎回新しく追従のためのアップデートを行わなければなりませんから。
これまでの歴史の中で最も苦労したのは、2017年の「WebExtensions API」（※2）への移行です。
以前のFirefox拡張機能は、ブラウザの内部構造に直接アクセスして中身を書き換えるような仕組みでした。しかし、これだと何でもできてしまう分、セキュリティ上の懸念があるだけでなく、ブラウザの根本的な仕様を変更するたびに拡張機能が壊れてしまうため、Firefox自体の進化を妨げる原因になっていたんです。
そこでWebExtensionsでは、ブラウザのコア部分に触れさせないよう完全に隔離されたサンドボックス環境から、安全なAPIのみを経由してブラウザに影響を及ぼす形式へと、拡張機能の仕組みが刷新されました。
これにより、TSTは実質ゼロからのつくり直しを余儀なくされました。ブラウザの内部を直接いじれないという制限の中で、元の使い勝手を擬似的に再現しなければならなくなったからです。
どんな制約があったか一例を挙げると、まずFirefox本体の処理に「割り込む」ことが一切できなくなりました。以前は「ユーザーがリンクをクリックして新しいタブを開こうとした瞬間」に介入してツリー上の適切な位置にタブを配置していましたが、移行後は「タブが開かれた後」の事後報告を受け取ることしかできません。そのため、「どのタブから開かれたか」という限られた情報を頼りに親子関係を推測し、サイドバー上で後から動的にツリーを組み立てる仕組みへとつくり変えました。
また、サイドバー内ではFirefox公式のコンテキストメニューを呼び出せないという制約もありました。これを解決するため、公式と同じ見た目、同じような項目の並び順の右クリックメニューを、一から自作しています。
他に終わりのない課題として「パフォーマンスの改善」もあります。ユーザーの中には、極端な話、タブを3000個も開くような方もいらっしゃいます。そうなってくると、メモリ消費や動作速度が深刻な問題になります。
（※2）Google Chromeなど他の主要ブラウザでも採用されている、拡張機能を開発するための標準的な技術仕様。
――そのパフォーマンス面については、どのように工夫していますか？
結城：例えば、バージョン4.0（2024年）のアップデートで行ったのが、UIを「仮想スクロール」に切り替えるという改修です。
以前は、画面に見えていないタブや折りたたまれているタブも含めて、すべてのタブのHTML要素を裏側のDOMツリー上に保持していたため、タブが増えるほど無駄にメモリを食い潰す状態でした。そこで導入した仮想スクロールでは、画面に表示されている範囲と、その前後のわずかなタブだけを描画し、スクロールに合わせて中身を動的に入れ替えます。
これは、技術的には何十年も前からある手法です。ですが、TSTの歴史的な設計のしがらみもあって、導入するまでに17年もかかってしまった。とはいえ、これを導入したことで、メモリー消費が大きく減り、動作も一定程度軽くなりました。
――取り組みの数々に、長年の執念のようなものを感じます。この先もずっと、さまざまな工夫を凝らしながら、TSTをつくり続けていくつもりなのでしょうか。
結城：いえ、そのように心に決めているわけでもありません。
――え？
結城：もしもFirefox本体の垂直タブが進化して、アドオンからピンポイントでインデント表示などの挙動を変更できるAPIが提供されたら。あるいは、ARグラスなどが標準的なデバイスとなり、ツリー表示よりも優れたタブの視認方法が登場すれば、現在の形態のTSTは開発を終了していいと思っています。
ですが、現状ではまだそうしたものは登場していません。だから、最も自分に合っているUIのタブを使い続けるために、つくり続けている。それに過ぎません。
ただ、Tree Stye Tabに限らずですが、日常の不満を解消するためにOSSをつくり続けていることを通じて、伝えていきたいと思っていることはあります。
「壊れたドライヤー」と「OSS」が教えた自由
――OSSを通して伝えていきたいこと、ですか？
結城：はい。そもそも僕は、自分がITエンジニアになるだなんて思ってもいなかったんですよ。大学でも情報工学ではなくメディア系の学科に進み、サークル活動を通して漫画やイラストを描いていました。
かつての僕は、Webサイト制作ぐらいはできても、一定規模のソフトウェアに関しては「誰かがつくってくれた物をありがたく使わせていただくだけで、自分に手を出せる領域ではない」と考えていたのです。それが、OSSとの出会いによって徐々に変わっていきました。
昔話をさせてください。僕の父は中学校の技術・家庭科の教員で、どこからか壊れたドライヤーをもらってきては、自分で修理して使い始めるような人でした。家にははんだごて等の工具がいつも転がっていて、そうした環境で育った僕の中には「壊れたものは、直せるなら自分で直せばいい」という感覚が自然と根付いていました。
しかし時代が進んでソフトウェアに触れるようになると、その中身はクローズドなものが多く、専門的すぎて手が出せないと感じる機会が増えました。バグを見つけても、メーカーや開発者が直してくれるのを黙って待つしかない。その状況に、内心モヤモヤとしたものを抱えていました。
そんな中出会ったのが、ソースコードが公開されていた、ブラウザの拡張機能です。先ほどお話ししたExecute Applicationsです。そのソースコードを書き換えることができた瞬間、「なんだ、自分で直して使っていいんだ！」という、ある種の感動を覚えたんですね。「自分も本格的な、『動くもの』をつくる側になれるんだ」、と。
――幼少期の「ドライヤー修理」の感覚が、ソフトウェアの世界で再発見されたのですね。
結城：そうですね。
そうしてタブ機能をはじめとして、身の回りのソフトウェア環境を自分で改善できるようになっていきましたし、拡張機能開発を通して生まれた縁から、エンジニアという思ってもみなかった職業に就くことにもなりました。「ただ不満を抱えるだけ」という状態から、「つくる側」へと意識が転換したことで、僕の人生は大きく道が開けました。
自分が当事者としてアクションを起こすことで、世界を少しだけ良くできる。少し大きな話になりますが、一人ひとりがこうした、「自分の手で状況を改善できるんだ」という実感を持てるようになれば、世の中はもっと良くなっていくと思うんです。だからこそ、僕が体験したこの意識の転換を、より多くの人にも知ってもらえたら、と考えています。
それに、OSSに多くみられる開発手法であるバザール型開発には、特有の利点があります。例えば、僕は大学で受けたUIの授業で、「色覚多様性に配慮して、アイコンは色だけでなくシルエットで区別できるようにすべきだ」と学びました。しかし全ての人々が、そうした原則を知っているとは限りません。もしも特定のプロダクトの開発チームが一切こうした知見を有していない場合、どうしても「誰かにとっては不便なもの」が生まれてしまいます。
でもOSSなら、困っている当事者自身が「こう改善できるよ」と実例を示せるし、パッチを送って、みんなでより良いものへと育てていきやすい。最初から完璧にインクルーシブなものはつくれなくても、それに近づけることはできます。
だから、世の中に、「OSSの開発に関わる人」がもっと増えてほしいと思っています。そのために、僕は「OSS Gate」という取り組みを通じて、オープンソース開発に興味がある方の最初の一歩をワークショップなどで支援する活動も行っています。
僕がTree Style Tabの開発をOSSとして長く続けているのも、基本的には「自分が使うのに不便だから、自分で直している」のが理由ですが、それが結果的に「誰かを待つのではなく、当事者として自ら手を動かす」という考え方の、ひとつの実践例になっていればいいなとも思って取り組んでいます。
――お話を聞いていて思ったのですが、高校時代に「2ちゃんねる」でCSSを教えてくれた方との出会いも大きな転換点だったのでは？
結城：振り返ってみると、そうかもしれません。
あのユーザーがどこのどなただったのかなんて、今となっては分かりようがありません。ですが、あの掲示板でスタイルシートWebデザインという本を薦められたことが、僕をWeb標準の世界に導き、拡張機能開発へと走らせ、結果としてエンジニアへと至らせたわけですから。一体、どれほど僕の人生を変えたことか。
もしも今、オープンソースの世界に興味を持っていたり、プログラミングの最初の一歩で迷っていたりする人に対して、僕があの日の「名無しさん」のような役割を果たすことができたら。それ以上に嬉しいことはありません。
取材・執筆・編集：田村 今人
撮影：曽川 拓哉
