自分が見たものだけを検索する検索エンジン — Histerと個人インデックスの復権

個人検索エンジンは壊れたWeb検索への反動なのか、それともAIアシスタントの記憶を自分の手元に取り戻すための基礎工事なのか?

導入

2026年9月17日(日本時間では18日未明)、Hacker Newsのトップページに「Hister: あなたが訪れたページとあなたが保管するファイルのためのプライベート検索エンジン」が掲載され、741ポイントを集めた。リンク先はGitHubリポジトリasciimoo/histerである。リポジトリは2026年1月に作成され、Goで書かれ、ライセンスはAGPLv3だ。本稿の執筆のために参照した時点(10月18日)のGitHubスター数は6,074だった。

作者はスレッドに自ら現れ、「何でも聞いてほしい」と書いた。彼が明かした経歴が興味深い。彼の最初のフリーソフトウェア検索プロジェクトは、プライバシーを尊重するメタ検索エンジンSearxであり、メタ検索という概念の限界ゆえに別のアプローチを選んだという。メタ検索とは、結局のところ他の検索エンジンの結果を集めて見せる方式である。その結果そのものが劣化すれば、いくらプライバシーを守っても得られるものは減っていく。Histerは正反対の方向に舵を切る。Web全体を検索するのではなく、自分がすでに見たものだけを検索する。

同じプロジェクトは1か月前の8月18日にも「Hister – あなたが管理するプライベートな全文検索インデックス」というタイトルで497ポイントを得ている。1か月で再びトップページに上がり、ポイントはさらに高かった。スレッドには「数週間使っている」「仕事用マシンで1〜2か月動かしている」という利用報告がいくつも混じる。本稿はHisterというツールそのものよりも、このツールが触れた問いを追う。なぜ今、再び個人インデックスなのか。そしてその代償は何か。

現象分析 — Histerが実際にやっていること

READMEと公式ドキュメントで確認できる構造から整理する。Histerはクライアント・サーバ構成である。サーバがドキュメントを保存して検索し、クライアントがコンテンツを収集したり検索を実行したりする。すべてを1台のコンピュータで動かすこともできるし、複数のクライアントを1つのサーバに接続することもできる。クイックスタートの手順は、バイナリをダウンロードしてhister listenを実行し、127.0.0.1:4433を開いて、FirefoxまたはChromeの拡張機能をインストールするだけだ。

コンテンツの入口は5つある。ブラウザ拡張、ブラウザ履歴のインポート、ブックマークのインポート、監視対象のローカルディレクトリ、そしてWebサイトクローラである。ドキュメントがこれらの経路の違いをかなり正直に説明している点が目を引く。

ブラウザ拡張は、ページの読み込み後に現在のタブを読み取り、URL、タイトル、抽出したテキスト、レンダリング済みHTML、faviconを設定されたサーバへ送る。ページを新たにリクエストするのではなく、すでにレンダリングされた画面をそのまま取り込む。そのため、JavaScriptで描画されるページやログインしなければ見えないページも索引される。
履歴のインポートは事情が異なる。ブラウザの履歴DBにはURL、タイトル、訪問回数、タイムスタンプしかなく、ページの内容は含まれない。そのためHisterはURLの一覧を読んだうえで、クローラで現在のページを取得し直す。ドキュメントは、こうして索引された内容が当時見たものと異なりうると明記している。ページが変わった、消えた、ログインが必要になった、といった可能性があるからだ。

作者はスレッドで、拡張方式の利点を次のように説明した(直接の引用ではなく、コメントの要旨の要約)。拡張はWebサイト側から完全に不可視であり、CAPTCHA、ボット対策、認証の問題といった一般的なクローラが常に突き当たるボトルネックを、ブラウザとユーザーがすでに解決した状態で内容を得られるという。別のユーザーは、Instagramのような閉じたサイトを索引できる最初の「検索エンジン」かもしれないと反応した。

検索側の機能は、フィールドフィルタ、フレーズ検索、ワイルドカード、否定、エイリアス、結果の優先度を扱えるクエリ言語と、任意で有効化できるセマンティック検索に分かれる。セマンティック検索はデフォルトで無効である。有効にすると、ドキュメントのテキストを重なりのあるチャンクに分割して外部の埋め込みモデルでベクトル化し、検索時にはクエリも埋め込んで最も近いチャンクを取得し、キーワード検索の結果とマージして再ランキングする。埋め込みエンドポイントはOpenAI互換であればよく、ドキュメント上のデフォルトはローカルのOllamaのアドレスとqwen3-embedding:8bモデルである。

そして3つ目のインタフェースがある。Web UI、ターミナル(TUIとCLI)に加えて、MCPエンドポイントがある。AIアシスタントがHisterのインデックスを直接検索し、保存されたプレビューを取得できるようにする経路だ。作者の自己紹介でもREADMEの冒頭段落でも、この点が前面に置かれている。「Webインタフェース、ターミナル、あるいはMCPで接続したAIアシスタントから再び見つけられる」。

スレッドの利用報告は、この構造がどこで効くのかを示している。jjiceは仕事用マシンで1〜2か月動かしてきたが、普段は見ないものの、必要なときに先月分のブラウザ履歴を漁る作業を解消してくれると書いた。ただし初期には除外ルールをかなり積み上げる必要があったと付け加えている(直接の引用ではなく、コメントの要旨の要約)。YehoshaphatはHisterをデフォルトの検索エンジンにしており、外が必要なときだけ!!プレフィックスでKagiに渡すという。RobGRはすべてのページを索引せず、拡張で特定のページだけを選んで入れているが、本当の価値は自分が忘れるほど古いものが溜まったときに出てくるだろうと述べた。

深層分析 — なぜ今、そして何を代償に

かつてブラウザがやっていたこと

返信が多くついた枝の一つがjval43のコメントである。Google Chromeは2008年の時点で、訪れたすべてのページの全文検索をオフラインで提供しており、誰も覚えていないが目玉機能だった、そして2013年ごろに消えた、という内容だ(直接の引用ではなく、コメントの要旨の要約)。返信でxd1936が根拠のリンクを探して貼った。デジタルフォレンジックのブログdfir.blogの2013年10月2日の記事は、Chrome v30で「History Index YYYY-MM」というSQLiteファイル群が削除されたと記録している。これらのファイルにはユーザーが訪れたほとんどのWebサイトのテキストが含まれており、Chromeはそれをオムニボックスのサジェストに使っていた。引用されたコミットメッセージは「全文インデックス機能はもはや何にも使われていない」としてTextDatabaseを削除すると書いている。

他の返信も似た記憶を持ち寄った。Google Desktop、Mac版のIE5、Chromium以前の時代のOpera。TeMPOraLは、今やどのブラウザも開いているタブ、ブックマーク、履歴からまともに探してくれないとこぼした。消えた理由については、技術的制約だという推測と、広告の載らないオフラインページが会社の利益と合わなかったのだという皮肉が交錯したが、どちらもスレッド内では確認されていない。

ここから読み取れるのは「新しい発明」への熱狂ではなく、「失われた機能」の復元への欲求である。個人の全文インデックスは技術的にはずっと前から可能であり、実際に大手ブラウザに組み込まれていた。それが抜けた穴を、13年後に個人プロジェクトが埋めている。

AIアシスタントが代わりに覚えてくれればよいのでは

スレッドで最も直接的な反論は361994752のコメントだ。数か月前に読んだものが見つからないとき、ChatGPTに「数か月前にx、yについて読んだのに見つからない」と聞くと、驚くほど正確な答えが返ってくるという(直接の引用ではなく、コメントの要旨の要約)。このコメントについた2つの返信が、本稿の問いを正確に切り分ける。cobertosは、それが可能になるにはすでにブラウジング履歴がChatGPTにある必要があるのではないかと問い、HisterにはMCPサーバがあるのでそうしたワークフローも可能であり、AIが失敗したときに人間が直接見られる形でデータを持っておくことが要点だと述べた。rglullisはもっと短く、それは問題を解決したのではなく、OpenAIへの依存を増やして痛みの場所を移しただけだと書いた。

この対立は「人間対AI」ではない。争点は記憶の原本を誰が持っているかである。汎用チャットボットが「どこで読んだっけ」に答えられるのは、その文章が公開Webにあり、学習データや検索対象に含まれているからだ。自分がログインして見た社内Wiki、有料記事、閉じたSNSのフィードはその範囲外である。Histerの拡張がレンダリング済みのページをそのまま取り込むという設計は、まさにその空白を狙っている。そしてMCPエンドポイントは、そうして蓄積した原本を好きなAIアシスタントに「貸し出す」形だ。原本は自分のサーバに、推論は好きなモデルに。これがHisterがAIと競う代わりに選んだ配置だと読める。この解釈は筆者の分析であり、作者がこのような言葉で説明したわけではない。

ただし、この配置にも新しいリスクが付きまとう。HisterのMCPドキュメントはこの点を隠していない。索引されたタイトル、URL、本文、履歴フィールドはすべて信頼できないソースデータであり、ページの中にAIを狙った指示文が含まれている可能性があると書く。ツールの応答はソース由来の値をuntrusted_contentの下に置き、各レコードにtrust: "untrusted"を付け、不可視の制御文字を除去する。そのうえで「こうした制御はリスクを減らすが、すべてのモデルがプロンプトインジェクションに抵抗することは保証できない」とし、読み取り専用の取得以外の操作にはユーザーの確認を求めるよう勧めている。自分が見たすべてのページをAIにつなぐということは、自分が見たすべてのページの書き手がそのAIに話しかけられるようになる、ということでもある。

ローカルファーストの3つのコスト

ローカルで自分で動かすという選択にはコストが伴う。スレッドとドキュメントで確認できることを、ストレージ、プライバシー、鮮度の3軸に分けて見ていく。

ストレージ。 データライフサイクルのドキュメントは、ページ1件の保存に平均で約100KBかかると書く。単純計算で1万ページなら約1GB、10万ページなら約10GBになる(筆者の算術であり、ドキュメントはページ内容によってばらつきが大きいと注意している)。より重要なのは上限がないことだ。ドキュメントは、自動的な有効期限も、最大ドキュメント数も、ディスク全体のクォータもないと明言し、ストレージの監視、バックアップ、削除スケジュールはサーバ運用者の責任だと言い切っている。抑える方法も書かれている。HTMLプレビューを無効にし、ノイズの多いURLをスキップするルールを設定し、バージョン記録は必要なページにだけ適用せよ、というものだ。個人インデックスは、インストールした瞬間に小さなデータ運用業務になる。

プライバシー。 「プライベート」という言葉は「外に出ない」という意味であって、「安全だ」という意味ではない。ドキュメントは、索引されたデータはHisterによって暗号化されないと明記し、必要ならディスク暗号化を、信頼できないネットワークを越えるときはHTTPSを使うよう求めている。拡張のドキュメントは、レンダリングされたページには個人的な情報や機微な情報が含まれうること、非公開のアカウントページも送信されうることを警告している。デフォルト設定では認証も要求しない。つまりHisterを起動した瞬間、自分の銀行の画面も医療ポータルも社内システムも、1つのディレクトリに平文の全文インデックスとして集まりうる。セマンティック検索をリモートの埋め込みAPIで有効にすれば、そのテキストは再び外へ出ていく。スレッドでcomputatorが、ディストリビューションのパッケージではないプログラムやブラウザ拡張を入れること自体をためらうと書いたこと、そして返信がネットワークアクセスを遮断したコンテナ、AppArmor、systemdのハードニングといった隔離策を提案したことは、この文脈で読むべきだ。

鮮度。 個人インデックスは、自分が見た瞬間のスナップショットである。作者は、元のページが変わったり消えたりしても検索できるよう、抽出した内容とオフラインプレビューを保存すると説明した。これは長所であり限界でもある。同じURLを再訪すると現在の内容が以前の値を上書きし、変更履歴を残すには別途バージョンルールを設定する必要がある。逆に履歴のインポートは過去のURLを今あらためて取得するので、当時見たものではなく今残っているものを索引する。結局のところ、個人インデックスが正確に答える問いは「このテーマの最新情報は?」ではなく、「あのとき見たあれはどこにあったか?」である。

展望と示唆

スレッドで目立つパターンは、「自分も似たものを作った」というコメントの多さだ。bradrn、sbeckeriv(3つ目のバージョンだという)、tombert、taudeがそれぞれのツールを紹介し、Zotero、ArchiveBox、Karakeep、Betula、recoll、histreといった既存ツールの名前も次々に挙がった。taudeは、ブラウザ履歴のSQLiteをcronで走査し、特定のルールに合うページをMarkdownに変換してObsidianのVaultに入れ、LLMで分類までさせるパイプラインを説明しつつ、これが本当に有用なのか、知識収集のヤク毛刈りにすぎないのか確信がないと書いた(直接の引用ではなく、コメントの要旨の要約)。需要ははっきりしているが標準的な答えがないため、各自が作り直している状態である。

反対側の声もある。ozimは、キュレーションしたノートから投資に見合うリターンを得たことがなく、忘れても生活や仕事に影響のないものはそのまま忘れると書いた。elestorは使ってみたがCPUとバッテリーの消費のためにやめたとし、別のマシンでセルフホストするのが前提なのかと尋ねた。こうした反応は、個人インデックスが誰にとっても必要なインフラではないことを思い出させる。思い出す頻度の低い人にとっては、保存と運用のコストだけが残る。

名前の問題もある。作者は、Histerという名前が米国の登録商標と衝突しており、相手側から名称変更を求められたと明かした。別のユーザーは、histre.com側が書面を送ったという話をDiscordで見たと書いている。作者は、法的にはあまりに似ていると判断されているとして、候補を集めて投票にかけるつもりだと述べた。本稿が扱う時点以降に名前が変わったかどうかは確認していない。

示唆をまとめるとこうなる。第一に、個人インデックスの競争相手はGoogleではなく「AIアシスタントの記憶機能」である。どちらも「あのとき見たあれ」を見つけると約束するが、原本を誰が握るかが違う。第二に、MCPのような標準的な経路ができたことで、個人インデックスは独立した製品ではなく、AIアシスタントの外部記憶装置として位置づけられるようになった。HisterがMCPをREADMEの冒頭段落に置いたことは、その方向性を示している。第三に、その代償として、プライバシーは「クラウドに送らない」から「自分で運用する」へと意味を変える。暗号化、認証、保存期限、プロンプトインジェクション対策をユーザー自身が決めなければならない。

結論

Histerが741ポイントを集めたのは、検索エンジンとしての技術的な新しさというより、多くの人が共有する小さな挫折を正確に突いたからだと思われる。確かに読んだのに、もう一度見つけられないページ。ブラウザはかつてそれを解決し、そしてやめた。Web検索はそのページを再び出してくれず、AIアシスタントは自分がログインして見たものを知らない。

SearxからHisterへと移ってきた作者の軌跡は、それ自体が一つの診断である。他人のインデックスをどれほどプライバシーに配慮して包んでも、そのインデックスが自分に合わなければ意味がない。だからインデックスを自分の側に持ってくる。その瞬間、ストレージとセキュリティと鮮度の責任も一緒に移ってくる。

あなたが最後に「確かにどこかで見たのに」とつぶやいたのはいつだったか。そのページをもう一度見つけてくれるとしたら、あなたはそれを誰に任せるだろうか。検索企業か、AIアシスタントか、それともディスク暗号化とバックアップを自分で面倒見なければならない自分自身か。

出典: