Pascalは習慣や友人関係について書き、ページからページへとリンクをつないでいくうちに、ひとつの構造が見えてきました。心をつかまれたのは、笑ってしまうほど小さな仕組みです。文章の一節をページにすると、その言葉がリンクになり、新しいページがサイドバーで親ページのすぐ下に現れる。Notionは、そのページをどこかに整理しろとも、どこに属するのか説明しろとも言いませんでした。ページを作ること自体が、つながりを決めていたのです。

PascalがEleanorに出会ったのは、2021年のリスボンでした。Horseはまだ影も形もありません。その1年後、自分の会社WebScapeでChrome用のコマンドパレットを作っていたMartijn Verboveが、Pascalに「タブは壊れている」と言いました。それなら、なぜタブを直さずに、タブを前提にしたものを作っているのか。Pascalがそう尋ねると、Martijnは笑ってこう言いました。「自分を何様だと思ってるの？Googleか？」

笑える質問でした。もっともな質問だったからです。タブは、気の利いた再デザインを待っている、取り外し自由な部品ではありませんでした。ブラウザがページとページのつながりを捨てたときに現れたもの、それがタブだったのです。きちんと直すなら、ナビゲーションそのものを考え直し、そのうえで何年もかけて答えを作り上げることになります。これこそ、Pascalがやりたかった種類の無茶なプロジェクトでした。

Pascalは過去へさかのぼりました。ブラウザがこれから何になるべきかを決める前に、どの古い決断がタブを避けられないものに感じさせたのかを見ておきたかったのです。

最初のブラウザ、WorldWideWebは、Webをつながりあった文書の集まりとして扱っていました。いくつものページを同時に開き、デスクトップ上の書類のように動かせたのです。ブラウザを操作しているというより、Webそのものを直接さわって作業している感覚でした。ちょっとつついてみてください。下のウィンドウは今でも動きます。

次に、Line Mode BrowserがWebをターミナルで動くようにしました。ターミナルが一度に表示できる文書はひとつだけ。だからブラウザには、アドレスと、現在のページと、戻る・進むためのコマンドが必要になりました。こうした操作は、マシンの限界に対する現実的な答えだったのです。

Mosaicは、そのモデルをグラフィカルなウィンドウに持ち込みました。上にツールバー、その下にアドレス、残りを埋めるのは現在のページひとつ。マシンにはもうターミナルの限界はありませんでしたが、ナビゲーションの形は残りました。のちのブラウザは、いくつもの「現在のページ」を手の届くところに置いておくために、タブを加えました。タブは窮屈さをやわらげましたが、ページどうしのつながりを取り戻しはしませんでした。

それこそが、もっと根の深い問題でした。URLはすばらしい住所ですが、住所は、なぜそこへ行ったのかまでは教えてくれません。「戻る」と「進む」は一本の線をたどり直せますが、実際の仕事が一本の線のように進むことはめったにありません。タブはページを残しておきながら、そのページを役立つものにしていた道のりを捨ててしまいます。

過去への旅から戻ってくると、Notionのアイデアがぴたりとはまりました。URLはページの住所のままでいい。ブラウザがそのページをどう見せるかまで、URLが決める必要はないのです。ブラウザは、人がどのリンクを開いたのか、そしてどのページからそれを開いたのかを、もう知っていました。すべてのページをタブに押しつぶす代わりに、そのつながりを目に見える形で残しておけるはずでした。

こうして生まれたのがTrails®です。リンクを開くと、新しいページは、そこへ導いたページのすぐ下に現れます。ブラウズを続けるとTrails®は縦に伸びていき、作業の順番をそのまま残します。整理を二度やらされることはありません。今いらないものは折りたたんでおけばいい。すべてが、あるべき場所に残ります。

最初のプロトタイプが証明できたのは、アイデアそのものだけ。ほかはほとんど何も証明できませんでした。Google Docsはまともに動かない。クリックの反応が遅いこともある。拡張機能もパスワードマネージャーもなく、ほかにもたくさんのことが、見事なまでに未完成のままでした。

周りの人たちはPascalに、Chromeのように動くものにしろと言いました。Pascalは、もう少しでやめてしまうところでした。でもChromeは、Chromeであることにかけてはすでに見事です。その劣化コピーを作るなんて、みんなの時間をまさに英雄的なスケールで無駄にするだけだったでしょう。

Eleanorには、守る価値のある部分が見えていました。ぎこちないプロトタイプを自分の普段使いのブラウザにして、この風変わりなナビゲーションは「慣れ」よりも大切だと言い続けたのです。途中でうまくいかなかったところは、彼女が見つけました。彼女の判断が、アイデアに製品になるまでの時間を与えました。ほかの人たちもHorseを使い始めると、Eleanorは、頑固な実験をひとつの会社に変えていく手助けをしました。

最初、EleanorとPascalはHorseを「リサーチのためのブラウザ」と呼んでいました。あるテーマをたどった道筋を画面に残しておくブラウザを説明するには、それがいちばんわかりやすい言い方だったのです。Eleanorはオックスフォード大学Wadham Collegeの卒業生で、カレッジがWebサイトでHorseを紹介してくれました。この早い段階での後押しのおかげで、リスボン生まれの風変わりな新しいブラウザがうれしい注目を集めることができました。EleanorとPascalは、今もそのことに心から感謝しています。

最初にHorseを使ってくれた人たちは、足りない便利機能があっても受け入れてくれました。Trails®が、ほかでは手に入らないもの、つまり目に見える文脈を返してくれたからです。荒削りな部分は、哲学ではありませんでした。ただの、まだ残っている作業でした。だからEleanorとPascalは、その作業をやりました。

2024年、HorseはProduct HuntのGolden Kitty Awardsにたどり着きました。Bootstrapped & Small Teams部門で2位を獲得し、Product HuntはPascalをMaker of the Yearに選びました。賞は金色の猫の姿で届きました。ふたりの人間と、「無理のない仕事量」へのいささか怪しい敬意で作られたインディーのブラウザには、まさにうってつけです。その瞬間が何を意味していたのか、EleanorとPascalは、まだその渦中にいるうちに書き残しました。

評価されたのは最高にうれしいことでした。でも、それで拡張機能が魔法のように現れるわけではありません。

Horseを使う人たちは、すでに1PasswordやBitwardenといったパスワードマネージャーに、デジタルな暮らしを預けていました。HorseはElectronの上に作られていて、Electronはまだ、そうしたツールが頼る拡張機能の仕組みを動かせませんでした。それを変えるために必要なアップストリームの作業はSam Maddockが書いていましたが、これほど大きな変更には、それがどれほど重要なのかをElectronチームに知ってもらう必要がありました。

そこでEleanorとPascalは、Help Extend Horseというキャンペーンを作りました。お願いはひとつだけ。Samのプルリクエストを訪ねて、応援を加えてください。寄付もコードの貢献もいりません。必要としている人がいることを、見逃しようがないほどはっきり示すだけです。

3日もしないうちに、それはElectron史上もっとも多くの賛成票を集めたプルリクエストになりました。Pieter Levelsの後押しで、話はさらに遠くまで届きました。Electronチームはその土台をマージし、Electronのエコシステム全体で、この新しい種類の拡張機能が可能になりました。

でも「可能になった」は、ゴールではなくスタートでした。拡張機能への対応は、拡張機能がまだ視野になかったころにHorseが置いていた前提の奥深くまで食い込んでいました。2025年から、Pascalは1年以上かけて、Trails®を犠牲にすることなくその土台を作り直しました。最初の拡張機能をきちんと出せるようになるまでに、コードベースは2倍以上に膨らみました。

2026年7月、Horse 3.3で、検証済みの拡張機能が初めて動きました。安定版のHorseは現在7つの拡張機能に対応していて、その中には、ユーザーが最初から求めていたパスワードマネージャーも含まれています。Samの作業からHorseで動く拡張機能までの道のりは、ニュースの記事で追いかけています。

ADHDがこの物語に登場するのは、もっとあとのことです。Pascalは1996年にADHDの診断を受けていますが、ADHDについての理論からHorseを始めたわけではありません。時間がたつにつれ、Horseを使い続けてくれた人たちの多くが、自分にはADHDがあること、そしてタスクの道筋が画面に残っていると戻りやすいことを、EleanorとPascalに伝えてくれるようになりました。その傾向から、ふたりはHorseをいちばん必要としているのが誰なのかを理解していきました。見える文脈がなぜ助けになりうるのかは、ADHDのページで説明しています。

今では、Google Docsはちゃんと動きます。Horseにはパスワードマネージャーが入っていて、検証済みの拡張機能にも対応しています。リンクを開くのに、ちょっとした信仰心はもういりません。ブラウザとしての普通の仕事は、ちゃんと普通にこなせるようになりました。そしてTrails®は、今も堂々と別物です。

EleanorとPascalは今、リスボンを拠点にフルタイムでHorseを作っています。Eleanorはマーケティングと運営を担当し、Pascalはブラウザの設計と開発を担当しています。Horseの代金を払ってくれるのはユーザーです。だから、ふたりだけの会社の指揮系統は、すばらしく短くて済みます。命令はただひとつ、「Horseを使う人のために、最高のブラウザを作れ」。

Horseは、あなたが何を閲覧しているかを追跡しません。ブラウザはあなたの一日について多くを知ることができても、その作り手は何ひとつ知らずにいられるべきです。

上の写真は、2026年に東京ディズニーシーで撮ったものです。以前この「Horseについて」のページに載せていた、同じ場所で撮ったEleanorとPascalの写真から2年後になります。色がおそろいになったのは偶然です。

ブラウザのナビゲーションを変えるのに何年もかかったのは、問題が本当に大きかったからです。EleanorとPascalは、無難に見えるところまでアイデアを縮めたりはしませんでした。Horseが、仕事の記憶力が桁違いにすぐれた、ちゃんとしたブラウザになるまで、作り続けたのです。

「壊れている」は、「不可能」と同じ意味ではありませんでした。ただ、惚れぼれするほど大量の仕事が必要だった。それだけのことです。