ウェブで見つけた情報をあとから探し直せない、という悩みは意外と根深い。ブックマークだけでは足りず、ブラウザ履歴も断片的で、ローカルに置いた資料とネット上で読んだページが別々に埋もれていく。GitHubで公開されている Hister は、その散らばった記憶をまとめて引ける「自分専用の検索エンジン」を掲げるプロジェクトだ。しかも、単なるローカル検索ではなく、ブラウザ拡張、terminal、web UI、MCP 経由のAI連携まで含めて見せているのが面白い。個人向けの検索が、ただの便利機能ではなく、情報の持ち方そのものを変える段階に来ている、と感じた。
元記事によると、Hister は「Your own search engine」と名乗るプライベート検索エンジンで、主に自分が訪れたページや手元にあるファイルを対象に全文検索できる。特徴は、タイトルやURLだけを拾うのではなく、ページ本文やファイルの中身まで索引化する点だ。あとで探したい情報を、見出しの雰囲気やサイト名ではなく、実際にその場で目にした言い回しから引き当てられる。
使い方も、かなり具体的に案内されている。最新リリースからバイナリを落として hister にリネームし、Linux や macOS では実行権限を付けて ./hister listen を起動する。Windows なら PowerShell で .\hister.exe listen だ。サーバーを起動したままにしておく必要があり、その状態で http://127.0.0.1:4433 を開く。そこから Firefox か Chrome 用の browser extension を入れ、拡張機能を有効にした状態でWebページを閲覧すると、その内容が Hister に取り込まれる。実際に一度訪れたページの一部フレーズを検索して、最初の索引結果を確認する流れになっている。
README では、初期設定はローカルの個人利用なら不要だとしている。ただし、何を取り込むかは選べる。すでにある browser history を読み込んだり、local directories を index したり、ファイルを import したりできる。導入方法も binary だけではなく、Homebrew、Docker、Nix が用意されている。
機能面では、プライバシー重視を前面に出している。telemetry も mandatory な cloud service もなく、Hister を自分のローカル環境か、管理権限を持つ infrastructure 上で動かす想定だ。検索クエリには field filters、phrase、wildcard、negation、aliases、result priorities などが使える。さらに optional semantic search もあり、意味ベースで文書を探したい場合は embeddings endpoint を自分で設定する。加えて、crawler や browser import でサイトを取り込めるうえ、web、terminal、MCP clients から検索できる。複数ユーザーで共有する server でも、それぞれの文書と検索結果を分けて保持できるとしている。
プライバシーの説明はやや細かい。browser extension は、ファビコンのダウンロードを除けば、インデックス化するページ内容を自分が指定した Hister server に送るだけで、そのサーバー側に documents と search indexes が保存される。semantic search を使う場合だけは、選んだ embeddings endpoint に文書テキストが送られるので、その設定は事前に確認すべきだとしている。
README の最後では、開発環境にも触れている。必要なのは Go 1.26、npm、そして CGO の依存関係に必要な C compiler。リポジトリを clone して ./manage.sh build でビルドし、web app をホットリロード付きで触るなら npm run serve:app を使う。Vite の development server と Go backend を air で自動再ビルドする構成らしい。参加方法としては IRCNet の #hister と Discord が案内され、バグや提案は issue tracker、セキュリティ報告は SECURITY.md を見よとしている。ライセンスは AGPLv3 以降だ。
Hister でまず目を引くのは、検索対象を「自分がすでに見たもの」に絞っていることだ。これは一般的なWeb検索の代替ではない。むしろ、Google では探し直しにくい情報、たとえば一度読んだ技術記事の一節、社内の資料、ローカルに置いたメモを、あとから再発見するための道具に見える。私はこの割り切りがかなり良いと思う。情報が多すぎる今、必要なのは「世界中から最適解を探す検索」より、「自分の履歴の中から確実に引き戻す検索」だからだ。
しかも、全文を索引化するのは大きい。タイトルやURLだけでは、記憶に残っている断片的な文言から辿れないことが多い。たとえば「そのページで見た一文」を覚えているのに、サイト名もドメインも思い出せない、という場面はかなりある。Hister はそこを狙っている。履歴を整理するというより、閲覧体験そのものを“検索可能なデータ”に変えているわけで、ブックマークの上位互換というよりは、個人向けの索引装置に近い。
Hister の面白さは、単にプライバシー重視のローカル検索で終わっていない点にもある。web UI だけでなく terminal からも引けるし、MCP 経由でAI assistant にもつなげる。ここには、検索が人間のためだけの機能ではなくなりつつある現実が透けて見える。文書を探すのが人間で、結果を要約したり再利用したりするのがAI、という役割分担は今後ますます増えるはずだ。Hister はその接点を最初から用意している。
ただし、ここは少し慎重に見たほうがいいと思う。semantic search は便利そうに見える一方で、embeddings endpoint を自分で用意する必要がある。つまり「勝手に賢くなる」わけではなく、意味検索を使いたければ外部連携の設定と、そのリスクを引き受ける必要がある。README も、その場合は送信先を確認するよう促している。プライバシーを売りにするプロジェクトほど、便利さを足そうとした瞬間に設計の境界が見えてくる。Hister はその境界を隠していない。
もう一つ気になったのは、Hister が browser extension による自動取り込みと、crawler によるサイト収集の両方を持っていることだ。これによって、単なる「自分の履歴検索」から一歩進み、個人が自分なりに集めた情報空間を作る道具になっている。ブラウザで触れたページだけではなく、必要に応じてサイト全体を取り込めるなら、仕事や趣味で追いかけているテーマを自前のライブラリとして育てやすい。
一方で、ここには運用の難しさもある。どこまでを取り込むか、どこから先はノイズとみなすか、誰が使うか、保存期間はどうするか。こういう問題は、検索機能そのものよりも先に、データを貯め続ける仕組みを持つと必ず出てくる。Hister が multi user support を備えているのも、個人ツールとしてだけではなく、共有サーバーで使われる場面を意識しているからだろう。私は、これは「便利」より「責任」に近い機能だと思う。検索が強くなるほど、保存された情報の扱いも重くなる。
Hister を見ていると、検索エンジンというより、検索可能な記憶の保管庫に近い印象を受ける。ウェブで見たもの、ローカルに置いたもの、履歴として残ったものを、同じルールで引けるようにする。これは地味だが、日常の生産性にはかなり効くはずだ。特に、情報を集める人、調べ物の多い人、後で再利用する前提で読む人に向いている。
同時に、こうした道具が広がるほど、検索の主戦場は「外の世界」から「自分の持ち物の中」に移るのではないかとも思う。何かを知るためにまずWebを開くのではなく、自分が過去に触れた断片から引き出す。そのとき必要なのは巨大な公開検索ではなく、正確で、速くて、保存先を自分で決められる索引だ。Hister はその方向をかなり素直に形にしている。派手さはないが、使い込むほど価値が出るタイプのソフトウェアだと感じた。
