Spegel - LLMを活用してWebページを再構成するターミナルブラウザ

 (simedw.com)
14 ポイント 投稿者 GN⁺ 2025-07-02 | 2件のコメント | WhatsAppで共有
  • SpegelはHTMLのWebページをLLMプロンプトに変換し、ターミナルでMarkdown形式として表示するブラウザ
  • ユーザープロンプトをもとにページをリアルタイムでカスタム変換でき、重要な情報だけを簡潔に表示するよう設定可能
  • 中核となる動作方式はHTMLクロール → LLMプロンプト処理 → Markdown変換と出力
  • TextualベースのTUIで直感的かつ軽量なターミナルUIを提供し、ビューとプロンプトは設定ファイルで簡単に管理・リアルタイム変更が可能
  • Lynx、Links2、Browshなど既存のターミナルブラウザと異なり、LLMを活用したユーザー向けコンテンツ最適化に特化している
  • pip install spegelで簡単にインストール可能で、オープンソースとしてさまざまな実験や拡張に適している

プロジェクト概要と特徴

  • Spegelはターミナルで動作するWebブラウザの一種で、HTMLをLLMに渡してユーザー定義のプロンプトでページを再構成する
  • 出力はMarkdownに変換され、TextualベースのターミナルUIで直感的に表示される
  • JSは非対応で、GETリクエストのみを処理するミニマル設計
  • LLMプロンプトのカスタマイズで多様な変換ビューをサポート（例: レシピ要約、主要アクションの強調など）

パーソナライズと活用例

  • プロンプトとビューをユーザー設定（~/.spegel.toml）で自由に管理
  • 例:
    • レシピから材料と主要ステップだけを抽出
    • 複雑な説明をELI5スタイルで簡単に変換
    • 必要に応じて複数のビューを同時に登録し、すばやく切り替え可能

動作方式

  • SpegelはHTMLを取得し、設定ファイルのプロンプトとともにLLMへ渡す
  • LLMの結果をMarkdownへ変換し、Textualを通じてターミナルにレンダリング
  • プロンプト・ビューは閲覧中でもリアルタイムに調整可能
  • 結果を行単位でストリーミングし、Markdownフォーマットの崩れを防ぐバッファ処理を実装

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

  • Lynx、Links2、BrowshなどはHTML構造そのものをターミナルに表示
  • SpegelはLLMベースの変換により、不要な情報を除去した最適化ビューの提供に特化
  • 現代のWebサイトはCSS・JS依存度が高く、ターミナル環境では煩雑になりがちだが、Spegelは中核コンテンツだけを抽出して集中しやすさとアクセシビリティを改善する

インストールと使い方

  • pipで簡単にインストール:
    pip install spegel
  • 実行:
    spegel <URL>
  • 設定ファイル（~/.spegel.toml）のカスタマイズが必要、サンプルはGitHubを参照
  • ソースコードとコントリビュート: https://github.com/simedw/spegel

参考事項

  • まだProof-of-Concept段階のため、一部に未完成の機能や粗い部分がある
  • POSTリクエストは未対応で、フォーム入力など今後の拡張アイデアを検討中
  • 既存のターミナルブラウザの代替というより、LLM+TUIベースのコンテンツ個別最適化を探る実験的な色合いが強い

関連記事

2件のコメント

 
GN⁺ 2025-07-02
Hacker Newsのコメント

  • この技術は本当に興味深いアイデアだと思う。ブラウザを完全に置き換えるものではないが、決定的な検索とプロンプトを組み合わせることで、Webブラウジングのまったく異なるやり方を生み出せそうだ。コマンドラインツールの形で提供されるとさらにしっくり来る気がする

    • 次の段階としては、複数の「タブ」を同時に扱う機能を想像している。たとえばタブ1にニュースAの報道、タブ2にニュースB、タブ3にWikipediaを入れて、こうした資料を要約し参照リンクを生成する形だ。ただ、こういうワークフローを支えるのに十分安定したモデルが本当にあるのかは疑問だ。最新のSOTAモデルにも限界があるように感じる

    • 上のような、複数メディアの報道を一覧して要約し、参照を提供する機能は、実質的に Ground News がやっていることだと思う。私は彼らとは無関係で、単にKurzgesagtの動画でスポンサーとして言及されているのを見ただけだ。UIには明確な違いがあり得る

    • 複数のタブ/ビューを同時に表示するとしても、同じソース内に限定してやることを考えている。たとえば一方のタブにはCLIに最適化した元の表現、もう一方のタブにはfact-checking（GoogleやBraveで内容の根拠を探すこと）だけに集中させるやり方だ。こういう実験はとても面白そうだ

    • LLMベースのSEOスパムを全力で作り、別のLLMがそれを雑に要約してまた吐き出す構図だと見ればよい。実に素晴らしい未来だと思う

  • 有名なレシピサイトからレシピだけを抽出する例が最初に出てくるのが、いかにも古典的な場面だと感じた。個人的にはこういうプロジェクトはすぐに勧めたくなる。とても気の利いたプロジェクトという印象だ

    • またしてもLLMブームが、すでに存在していたものを再解釈して、ずっと悪く、しかも非決定的にした例だと思う。schema.org/Recipe のような標準構造はもともと存在していた

    • レシピ抽出の過程で内容や材料、分量などがランダムに変形される点が興味深い。LLMの特性がこうしたミクロコスモスの中で非常によく表れていると思う。ただし、ほとんどのコメントが期待している方向とはまったく違う

    • すでにLLMなしで決定的な方法によりレシピだけを抜き出してくれる拡張機能がある。たとえばChromeのRecipe Filter拡張は、ページ内のレシピを認識するとポップアップで表示してくれる

  • LLMが間に入ることで、最近のGoogleのSEO最適化された文章トレンドやSEO構造自体を迂回できる点が気に入っている。不要な部分をすべて取り除いてレシピだけを選り分けるのは、LLMに本当に向いている事例だと思う。今後はLLMをフィルターとして積極的に活用する事例がもっと出てくる予感がする。もちろんHTMLからレシピだけをそのまま抜き出せるなら理想的だが、SEO戦争があまりに激しく、現実的には不可能になっている状況だ

    • LLMは不要な要素を除去するためのものだと言うが、LLMが予測不能にレシピを変えてしまう可能性がある点は考える必要がある。エラーを許容できない環境で、こうした確率的ソフトウェアを信頼するのは理解しがたい

    • 数年前からこういう未来を予想していた。すでに検索内蔵のLLMツールはあり、複数の検索をつないで処理する機能は本当に強力だ。ただ、Spegelはまったく別のやり方だ。未来の広告ブロッカーは、小さく効率的なローカルLLMになると思う。たとえばタイムラインを時系列順に並べ替える、UIを変更する、特定の項目だけを表示する、といったさまざまな変形が可能だ。質の低いコメントを自動で隠すこともできるだろうし、LLMが間でプロキシやエージェントとして動けば全部可能だ。こうした流れは広告主にとってかなり不都合に感じられるだろうと思う

    • Webブラウジングの過程でLLMが毎分数百万トークンを処理しなければならないかもしれない点、つまりそれだけ計算コストが大きいことも考える必要がある

    • LLMが不要なものを作り、LLMがまた不要なものを取り除く、しかも互いに誤解なく回っていく循環構造だという気がする

  • より複雑でないモデル（LSTMベースでさえ可能だと思う）でDOMをなめて必要な部分だけを選び、直接ブラウザに表示するためのデータ構造として収集すれば可能性はあると思う。すでに作者のLLMベースのツールチェーンを活用すれば、学習データも簡単に作れそうに感じる

    • ただし、JSでコンテンツが遅れてレンダリングされる現代のWebでは、DOMだけを走査するのには限界がある。JSがすべて読み込まれ、すべてのリクエストが終わって初めて必要なデータが得られることもあり、その場合は結局ブラウザレンダラーを動かすのと大差ない

  • 多くの人はhtmlが出発点にすぎないことを見落としているようだ。Webページを別の視点（view）に変換できるなら、実際にはモデルが受け取るあらゆる入力を変換できる。PDF、画像入りのzip、大きなjsonなど、何でもview化できる。結局重要なのはhtml入力ではなく、出力されるviewだ

  • spegelに -p オプションを追加する提案

    spegel -p "extract only the product reviews" > REVIEWS.md

    のように、プロンプトベースで欲しい情報だけを抽出する機能だ

  • ページごとに毎回新しくrewriteするのではなく、1回の訪問でMarkdownに変換し、そのきれいな版を共有すれば、計算の再構築を減らせるのではないかと思う

    • 各ユーザーごとに必要性や事前知識が異なるので、どれだけきれいな共通資料を作っても、結局は個人ごとの手直しが残ると思う。ただ、P2Pキャッシュ（IPFSなど）のようなグローバル重複キャッシュは、データ保存、可用性確保、資源節約に役立つかもしれない

    • キャッシュヘッダーは、サーバーがクライアントにどれくらい長くキャッシュしてよいかを知らせるためのものだ。クライアント側にも、こうしたヘッダーを順守するキャッシュ層を追加するとよいのではないかと思う

    • 一貫したレイアウトが目標なら、最後のページのMarkdown結果を例としてモデルに一緒に渡す方法（one-shot example）にも可能性がある

    • このプロジェクトは「個人向けプロンプトベースのビュー」という目的があるのだから、少なくともデフォルトプロンプトの結果はキャッシュして使ってもよいのではないかと思う

  • 本当に素晴らしいPOCだと感じたし、普段使っているChrome拡張の「reader view」と非常に似ている部分がある
    reader view拡張リンク

  • アイデアがとてもすばらしく、アクセシビリティの面でも大きな可能性があると思う

    • ただしやはりLLMは非決定的なので、アクセシビリティは何よりも信頼性と予測可能性が担保されるべき領域だという点が問題だ

  • 引退した私のAIエージェントがWebページをリアルタイム変換してくれることを実演した古い動画がある
    HNをMy Little Ponyに変換するデモ（動画）
    だいたい37秒あたりから結果が見られる
    オープンソースのChrome拡張も作ってあるので、興味があれば ChromeGPT を参照してほしい
 
laeyoung 2025-07-04

spegel -p "extract only the product reviews" > REVIEWS.md

このオプションさえ使えればいろいろ使い道を思いつくんですが、まだないみたいでした。