世界を動かす技術を、日本語で。

Show HN: Spegel、LLMを活用してウェブページを再構成するターミナルブラウザ

概要

Spegel はHTMLをLLMで処理し、Markdownとしてターミナルに表示する 新しいWebブラウザ のPoC。 個人化要約 などの変換がプロンプトで簡単に実現可能。 Textual を使ったTUIで直感的な操作性。 従来のターミナルブラウザとは異なる 柔軟なカスタマイズ が特徴。 pip でインストールでき、GitHubで公開中。

Spegel:LLMで進化するターミナルWebブラウザ

  • Spegel は、 HTMLLLM (大規模言語モデル)で処理し、 Markdown としてターミナルに直接表示するWebブラウザのプロトタイプ。

  • JavaScript非対応、GETリクエストのみ対応、 カスタムプロンプト によるWebコンテンツ変換が可能。

  • Google Gemini 2.5 Pro Lite の登場で推論速度が大幅に向上、実用性が増加。

  • 個人化要約翻訳 など、従来はコストや時間がかかった変換作業が LLM で高速・簡単に実現。

  • プロンプト を自由に設定でき、 ELI5 (わかりやすく簡単に)や 重要点の強調 など、複数のビューを1ページ内で切り替え可能。

  • レシピ抽出 などの用途に特化した設定例も提供。

    • 例:レシピビュー設定
      • id: "recipe"
      • name: "Recipe"
      • hotkey: "7"
      • prompt: 材料と手順のみ抽出し、 メートル法 で出力、余計なコメントや栄養情報は省略

仕組み

  • HTML取得→LLMプロンプト処理→Markdown出力→Textualで描画 のシンプルなパイプライン。
  • プロンプトやビューは セッション中にリアルタイム編集 可能。
  • Textual によるTUI開発が容易で、UI要素の追加も直感的。
  • ストリーミング出力 時は、改行で区切られた完成行のみを描画し、Markdownパーサーの崩壊を防止。

他のターミナルブラウザとの違い

  • LynxLinks2Browsh などの伝統的なターミナルブラウザとは異なり、 LLMによる柔軟な内容変換 が特徴。
  • POSTリクエスト未対応 だが、フォーム要素独自UI生成の構想あり。
  • 現代的なWebサイト はCSSやJSに依存し、従来のターミナルブラウザでは扱いづらいが、Spegelは ノイズを除去し本質的な情報 を抽出。

使い方・導入方法

  • pip でインストール:
    • pip install spegel
  • コマンド実行例:
    • spegel simedw.com
  • 設定ファイル(~/.spegel.toml)のカスタマイズが推奨。
  • ソースコードやコントリビュート はGitHubで公開中:
    • https://github.com/simedw/spegel

まとめ

  • Spegel は、 LLM の力を活用した 新しいターミナルWebブラウジング体験 を提案。
  • 個人化・要約・抽出 など多様な用途に適応可能。
  • 開発初期段階 だが、今後の発展に期待。

Hackerたちの意見

これ、実はめっちゃクールだね。ブラウザの代わりになるわけじゃないけど、決定論的な検索とプロンプトを組み合わせた新しいウェブのブラウジング方法を実現できるかも。コマンドラインツールとして使った方が、もっと良さそうだね。次のステップとしては、複数の「タブ」を同時に使うことかな。例えば、タブ1にはニュースサイトAのストーリー、タブ2にはサイトBのカバレッジ、タブ3にはウィキペディアがあって、それを要約して参考文献を提供するみたいな。そこでの問題は、基盤となるモデルがこのタイプのワークフローをサポートできるかどうかだと思うけど、SOTAモデルでもそれは難しそうだね。

ありがとう。複数のタブやビューを同時に表示することを考えてたんだけど、同じソースからだけね。例えば、CLI用に最適化されたオリジナルコンテンツのタブと、ファクトチェック専用のタブを作るとか。Google検索やBraveを使って裏付けを取ることもできるし、面白い実験になりそうだね。

LLMを使って、質の悪いSEOのゴミを生成して、さらに別のLLMでそれを「要約」するってこと?新しい世界だね、これ。

最初の例が、クソレシピサイトからクソレシピをパースするってのが面白いね。即座にグッドだわ、ハハ、いいプロジェクトっぽい。

どうやら、レシピをランダムに変えて、材料やその量を完全に変えているみたいだね。これは、LLMが何かをよく表しているマイクロコスモスだと思うけど、コメントの人たちが考えているような感じとはちょっと違うかな。

そういうことを、決定論的にやってくれる拡張機能もあるよ。LLMに頼らずにね。例えば、Chromeの「Recipe Filter」とか。レシピを検出したら、ページが読み込まれたときにポップアップが表示されるだけなんだ。

提案: -pオプションを追加してみては?: spegel -p "製品レビューだけを抽出" > REVIEWS.md

もう少しシンプルなモデル(LSTMベースのものでもいいかも)を使って、DOMを歩きながら出力すべきチャンクだけを抽出して、ブラウザで見れるデータ構造に集めるってのはどうかな。これに対してトレーニングデータを生成するのは簡単そうだし、著者が直接使えるように書いたLLMベースのツールチェーンを使えばいいと思う。

残念ながら、現代のウェブでは、JSでコンテンツが読み込まれる場合、DOMをただ歩くだけではダメなんだ。JSが読み込まれた後でしかDOMを歩けないし、そのリクエストが全部終わるまで待たなきゃいけない。その時点では、もうブラウザレンダラーを使ってるからね。

中にLLMがあるの、めっちゃいいね。SEOマシンを回避する素晴らしい方法だし、最近のGoogleのライティング最適化にも対抗できる。レシピから余計な部分を取り除くのは、LLMの素晴らしい使い方だと思う。これからもっと増えてくるんじゃないかな、LLMを使ったフィルタリングが。HTMLからレシピを読むだけで済むのはいいけど、SEOがすべてを武器競争に変えちゃったからね。

LLMを通じてウェブをブラウジングするのに、毎分何百万ものトークンを消費するコストが好き?

LLMは余計なものを追加し、余計なものを取り除く。誤解は一切なし。

みんな、HTMLは始まりに過ぎないってことに気づいてないね。ウェブページをビューにレンダリングできるなら、モデルが受け入れるどんな入力でもレンダリングできるよ。PDFをこのビューに。画像のZIPファイルをこのビューに。巨大なJSONファイルをこのビューに。何でもありだよ。ここでの製品はビューであって、HTMLの入力じゃないんだ。

HTMLをMarkdownに変換するためにpandocを使って、そこからLLMに要約させるのはどう?

毎回訪問するたびにページを再構築する必要があるかどうかを判断できるくらい賢かったらいいのに。ウェブの中には、誰かが一度訪れてマークダウンに書き直して、その後はきれいにしたバージョンをお互いに提供できる場所がたくさんあるよね。毎回の再構築が不要になるんだ。

著者は「自分のプロンプトを使ったパーソナライズされたビューのため」と言ってるけど、デフォルトのプロンプトの出力をキャッシュするのもまだ役立つと思うよ。

ユーザーそれぞれに異なるニーズがあって、トピックに関する前知識も違うから、たとえ「生」の超クリーンなソース形式でも、ほとんどのユーザーには最終的に違った調整がされるだろうね。でも、IPFSみたいなグローバルな共有冗長P2Pキャッシュ(「生」データの)があれば、処理能力を節約したり、可用性やデータ保存に役立つかもしれないね。

もし目標が毎回の訪問でより一貫したレイアウトを持つことなら、最後のページのマークダウンを保存して、それをモデルにワンショットの例として送ることができると思う。

キャッシュヘッダーは、サーバーがクライアントに対して、どのくらいの時間キャッシュしても安全かを伝えるために存在してるよ。クライアント側でキャッシュヘッダーを尊重するキャッシュレイヤーを追加するように更新できるかもね。

うわぁ、素敵なプロジェクトでクールだけど、ちょっと怖いね。これは「バブル」が「内部から」閉じられて、カスタム(またはクラウド、偏った)LLMがその「バブル」を焼き付ける場所だ。究極のバラ色(または赤、青、黒…)のメガネだね。

私も似たようなことをやったことがあるけど、Chromeの拡張機能を使ったよ。基本的には、すべてのウェブページに対して、HTMLをローカルのLLM(実際には地下室のサーバーにあるけど)に渡してる。内容がクリックベイトっぽいか、面白い詳細を失わずに要約できるかを考えさせて、もしそうならページの上に小さなアイコンを表示して、クリックすると要約が見れるようにしてる。次の計画は、ハイパーリンクを再構築して、ホバーしたときにページの要約を表示するか、もしくはハイパーリンクをその内容をもっと示すように書き換えることかな(HNの投稿タイトルについての文句はもう言わないよ…)。でも、私のマシンはあまり性能が良くないから、うまくいくかどうか、ページ上のリンクをどう優先するかはわからないんだ。