「半年くらい前に読んだ、あの設定項目の話が書いてある記事」をもう一度開きたい。そう思って Ctrl+H を押したものの、ブラウザ履歴の検索窓に何を入れても目的のページが出てこない——エンジニアであれば、一度は経験したことのある詰まり方ではないでしょうか。ブックマークに入れておけばよかった、と後悔したところで、そもそも読んだ時点では「後で必要になる」とは思っていないのが厄介なところです。
この問題が解けないのには構造的な理由があります。一般的なブラウザの履歴検索が見ているのは、ページのタイトルと URL だけです。しかし私たちの記憶に残っているのは、たいてい本文の中身のほうです。「タイムアウトの単位が秒じゃなくてミリ秒だと書いてあった」というレベルの記憶は、タイトルにも URL にも含まれていません。ブックマーク管理ツールを導入しても、「登録する」という能動的な操作が必要な限り、登録し忘れたページは最初から検索対象になりません。
この課題に対して「訪問したページとローカルに置いてあるファイルの全文を、自分が管理するサーバーに索引化してしまう」というアプローチを取るのが、Go で書かれた OSS の Hister（asciimoo/hister）です。ブラウザ拡張が訪問ページを自動で拾い、独自のクエリ言語で絞り込み、さらに MCP 経由で AI アシスタントからも同じインデックスを検索できる、というのが特徴です。
本記事では、Hister の索引の仕組み、クエリ言語とルール、MCP 連携、類似 OSS との違い、そして導入判断で確認したいポイントを整理します。本記事は README・公式ドキュメント・GitHub API の取得値といった公開情報に基づく整理であり、動作検証やインストール作業に基づくものではありません。記載しているスター数などの数値は 2026 年 9 月 2 日時点のものです。
Histerとは｜訪問ページとローカルファイルを全文検索するOSS
Hister は、公式ドキュメントで次のように定義されています。
Hister is a private, self hosted search engine for pages you visit and files you keep.
「自分が訪問したページと、自分が持っているファイルのための、プライベートかつセルフホストな検索エンジン」ということです。ここで押さえておきたいのは、Hister が「ブックマーク管理ツール」ではなく検索エンジンとして設計されている点です。この位置づけの違いが、後述する類似 OSS との比較でも一貫した軸になります。
README では機能が 8 項目にまとめられています（出典: asciimoo/hister README）。
機能 | 内容 |
|---|---|
Privacy focused | テレメトリなし、必須のクラウドサービスなし。ローカルまたは自分が管理するインフラで動作する |
Full text indexing | タイトルと URL だけでなく、訪問ページとローカルファイルの本文を検索対象にする |
Automatic browser indexing | Firefox / Chrome 拡張で新しく訪問したページを保存する |
Powerful queries | フィールドフィルタ・フレーズ・ワイルドカード・否定・エイリアス・結果優先度を利用できる |
Optional semantic search | 自分で設定した embeddings エンドポイント経由で意味検索を行う |
Crawler and browser import | Web サイトのクロールと、既存のブラウザ履歴の取り込みに対応する |
Web, terminal, and MCP clients | ブラウザ・TUI・コマンドライン・AI アシスタントから検索できる |
Multi user support | 共有サーバー上で、ユーザーごとに文書と検索結果を分離する |
「自分が見たページだけを検索する」という設計思想
公式ドキュメントは Hister の対象ユーザーを「自分が重要だと考える情報から、検索可能なナレッジベースを作りたい人」と表現しています。Web 全体を対象にするのではなく、Web ページ・ブラウザ履歴・ローカルファイル・クロール結果を 1 つのコレクションに集約し、そこだけを検索対象にするという考え方です。
アーキテクチャはクライアント / サーバー構成です。公式ドキュメントには「サーバーが文書を保存・検索し、クライアントがコンテンツの収集または検索の実行を担う」と記載されています。本体プログラムはサーバーとクライアントの両方の役割を持ち、ブラウザ拡張はクライアント専用として動作します。1 台の PC ですべてを完結させることも、複数のクライアントから 1 台のサーバーに接続することも可能です（出典: What Hister Is - Hister Documentation）。
同時に、公式ドキュメントは Hister がホスト型サービスではなく、自分で管理するシステムであることを明言しています。サーバーの運用責任はユーザー側にあるという前提は、採用判断のうえで重要な出発点になります。
Web UI・ターミナル・MCPという3つの入口
Hister は検索の入口を 3 系統用意しています。ブラウザから使う Web UI、ターミナルから使う TUI とコマンドライン、そして MCP 経由で接続した AI アシスタントです。同じインデックスに対して、用途に応じた経路を選べる構成になっています。
ターミナルクライアントは hister search で起動し、検索・履歴・ルール・追加のタブを切り替えて操作します。マウス操作、セマンティック検索、プレビューペインにも対応していると記載されています（出典: Terminal Client - Hister Documentation）。MCP 経路については、のちほど詳しく取り上げます。
Searxの作者が作った"逆方向"の検索エンジン
Hister の作者は Adam Tauber 氏（GitHub アカウント: asciimoo）です。GitHub のプロフィールには "Author of Hister, Searx, Colly and a bunch of smaller projects" と記載されています。Searx はプライバシー重視のメタサーチエンジンとして知られ、その派生である SearXNG も広く使われています。
Searx が「Web 全体を、プライバシーを保ちながら検索する」ツールであるのに対し、Hister は「自分が見たページだけを、自分のサーバーで検索する」ツールです。同じ作者が、検索の対象範囲について正反対の方向からアプローチしている点は、プロジェクトの立ち位置を理解するうえで補助線になります。
Histerの基本情報とプロジェクトの健全性
採用判断で最初に確認したいのは、プロジェクトが現在も動いているかどうかです。GitHub API から取得した値を整理します。
リポジトリの基本データ（2026年9月2日時点）
項目 | 値 |
|---|---|
リポジトリ | |
説明 | Your own search engine |
主言語 | Go |
ライセンス | AGPL-3.0 |
スター数 | 3,523 |
フォーク数 | 161 |
最終プッシュ | 2026-09-01 |
最新リリース | v0.18.0（2026-08-23 公開） |
公開状態 | public |
いずれも 2026 年 9 月 2 日時点の値です。あわせて、archived（アーカイブ済み）・fork（他リポジトリのフォーク）・private・disabled のいずれも false であることを確認しています。つまり Hister はアーカイブされていない現役のプロジェクトであり、他リポジトリのフォークでもないオリジナルのリポジトリです。最終プッシュが記事執筆の前日にあたる点からも、開発は継続していると読み取れます。
一方で、最新リリースが v0.18.0 であり、まだ 1.0 に到達していないバージョン系列である点は押さえておく必要があります。破壊的変更やインターフェースの変更が発生する可能性を織り込んだうえで採用可否を判断するのが妥当でしょう。配布バイナリとリリースノートは releases/latest で確認できます。
AGPL-3.0が社内利用・社外提供に与える影響
ライセンスは AGPL-3.0（README の表記では「AGPLv3 or any later version」）です。AGPL は GPL の条件に加えて、改変したソフトウェアをネットワーク越しにユーザーへ提供する場合にも、そのソースコードを提供する義務が生じる点が特徴のライセンスです。
したがって、判断が分かれるのは次のような使い方です。
- 自分の PC やチーム内サーバーに、改変せずそのまま設置して使う: 一般的には論点になりにくい使い方です
- Hister を改変し、その改変版を社外のユーザーがネットワーク越しに利用できる形で提供する: AGPL の条項が直接効いてくる領域です
- 自社プロダクトのコンポーネントとして組み込み、SaaS として提供する: 影響範囲の検討が必要になる領域です
ライセンスの具体的な解釈と自社への適用可否は法務判断が必要な領域であり、本記事の範囲を超えます。少なくとも「MIT ライセンスの OSS と同じ感覚で製品に組み込む」ことはできない、という前提で検討を始めてください。なお比較対象として後述する ArchiveBox と Shiori は MIT、Karakeep と Linkwarden は Hister と同じ AGPL-3.0 です。
Histerの全文検索インデックスはどう作られるか
Hister の中心にあるのは「どうやってインデックスに文書を貯めるか」という部分です。公式ドキュメントによれば、収集経路は大きく 4 つに分かれます。
収集経路1: ブラウザ拡張による自動インデックス
もっとも Hister らしい経路が、ブラウザ拡張による自動収集です。README のクイックスタートでは、リリースページからバイナリをダウンロードして hister にリネームし、Linux / macOS では実行権限を付与したうえで起動する手順が示されています。
./hister listen
Windows では PowerShell で .\hister.exe listen を実行します。起動後は http://127.0.0.1:4433 を開き、Firefox または Chrome の拡張機能をインストールする流れです。README には「ローカルの個人利用では設定は不要（No configuration is required for a local personal setup.）」と明記されており、単一バイナリで動く Go 製ツールらしい導入手順になっています。
拡張機能をインストールすると、新しく訪問したページが自動でサーバーに送られてインデックス化されます。「後で必要になるかもしれないから登録しておく」という判断そのものが不要になる、というのがこの設計の要点です。README のプライバシーに関する記述では、ブラウザ拡張がインデックス対象のページ内容を送る先は「自分が設定した Hister サーバーのみ」であり、例外はページのファビコン取得だけであると説明されています。
収集経路2: ブラウザ履歴・ファイル・Linkwardenからのインポート
拡張機能を入れた時点より前に訪問したページは、当然ながらインデックスに入っていません。そこで用意されているのが既存データのインポート機能です（出典: Importing Documents - Hister Documentation）。
- ブラウザ履歴:
hister import browser [BROWSER] [DB_PATH]で取り込みます。引数を省略すると自動検出が働きます。対応ブラウザとして Firefox / Chrome / Brave / Safari / Edge / Vivaldi / Opera / Ladybird が挙げられています。--start-dateで期間を、--min-visit Nで訪問回数の下限を指定できます - ファイル:
hister import file [INPUT...]で取り込みます。Hister の JSON エクスポート、7z アーカイブ内の JSON、HTML / HTM、PDF・DOCX・Markdown・Org mode、テキスト、ディレクトリ（再帰）に対応しています - Linkwarden:
hister import linkwarden INSTANCE_URLで既存のブックマークを移行できます。2 回目以降は差分取り込みになると記載されています
すでに Linkwarden を利用中のユーザーにとって、移行経路が公式に用意されている点は、乗り換え・併用を検討する際の判断材料になります。
収集経路3: クローラでドキュメントサイトを丸ごと索引する
「訪問したページ」だけでなく、特定のサイトをまとめてインデックスに入れる経路もあります。hister index URL... が基本形で、--recursive を付けるとリンクをたどって再帰的にクロールします。
再帰クロールに名前付きジョブを組み合わせる公式の例が次のものです。
hister index --recursive --job-id example-docs \
--allowed-domain docs.example.com \
--max-depth 4 --delay 1 \
https://docs.example.com
--job-id で指定した名前のジョブが存在しなければ新規作成、既に存在すれば再開になります。公式ドキュメントは「作成コマンドと継続コマンドを同一にできるため、スクリプトの中で扱いやすい」と説明しています。クロールの範囲は --max-depth / --max-links / --allowed-domain / --exclude-domain / --allowed-pattern / --exclude-pattern で制御し、--delay や --timeout でリクエスト間隔とタイムアウトを調整します。取得バックエンドは http / chromedp / bidi から選べるため、JavaScript で描画されるドキュメントサイトにも対応できる構成です。
社内 wiki や普段参照しているフレームワークのドキュメントを丸ごとインデックスに入れられる、という点が「訪問ページの検索」を超えた使い道につながります。
収集経路4: ローカルディレクトリの索引
4 つめの経路が、ローカルディレクトリの継続的な索引です。設定ファイルの indexer.directories に対象を書きます。公式の設定例は次のとおりです。
indexer:
directories:
- path: '~/notes'
filetypes: ['txt', 'md']
patterns: ['doc_*']
excludes: ['*secret*']
- path: '~/Documents/wiki'
label: 'wiki'
- path: '/path/to/project'
label: 'project'
filetypes: ['go', 'py', 'js']
filetypes で拡張子を、patterns と excludes でファイル名のパターンを絞り込み、label でラベルを付けられます。ラベルは後述するクエリ言語の label: フィルタで検索条件として使えるため、「Web で読んだ記事」と「手元のメモ」を同じ検索窓から扱いつつ、必要なときだけ片方に絞る、といった運用が可能になります。
なお、監視対象のファイルを削除した場合、既定ではインデックス上の文書は残ります。削除に追随させたい場合は delete_on_remove: true の設定が必要である旨が公式ドキュメントに記載されています。
索引データの保存構造とディスク消費の目安
自動で貯まっていく仕組みである以上、ディスク消費は無視できない論点です。公式ドキュメントは「1 ページの保存に平均で約 100KB のディスク容量を必要とする」と記載しています。単純計算では 1 万ページで約 1GB、10 万ページで約 10GB という規模感になります。
保存先である app.directory の配下は次のように構成されています（出典: Data Storage and Lifecycle - Hister Documentation）。
ファイル / ディレクトリ | 内容 |
|---|---|
| 検索対象のコンテンツと全文検索インデックス |
| 圧縮された HTML プレビュー |
| 圧縮されたファビコン |
| ユーザー・セッション・履歴・クロールジョブ・バージョン差分 |
| セマンティック検索用データ（SQLite 利用時） |
| ルールとエイリアス（シングルユーザーモード時） |
| 認証キー |
運用上とくに注意したいのは、公式ドキュメントが「文書には自動的な有効期限も、文書数の上限も、ディスククォータも存在しない」と明記している点です。保持期間の設計、ストレージ監視、削除スケジュールの適用はすべて運用者の責任になります。
削除については、hister delete を実行すると検索対象の文書、参照されなくなった HTML / ファビコン、セマンティックチャンク、関連する結果履歴が削除されます。一方で、ソースエントリ、バージョン記録、クロールジョブ、ログ、エクスポート、バックアップは削除されないと記載されています。完全なバックアップを取るには Hister を停止したうえで app.directory と設定ファイルをアーカイブする必要があり、PostgreSQL を使っている場合はデータベースのバックアップを別途行う必要があります。
クエリ言語とルールで検索精度をコントロールする
インデックスに大量の文書が自動で貯まる設計である以上、「絞り込む力」が実用性を左右します。Hister が独自のクエリ言語とルール機構を持っているのはそのためです。
フィールドフィルタと複合クエリ
公式ドキュメントに挙げられているフィールドフィルタは次のとおりです（出典: Query Language Guide - Hister Documentation）。
title: / text: / url: / url_re: / domain: / label: / language: / metadata.KEY: / type: / visits: / added: / updated: / user_id:
これらを組み合わせた公式の複合クエリ例が次のものです。
title:encryption "end-to-end" domain:(signal.org|whatsapp.com) -deprecated
公式ドキュメントはこのクエリを「タイトルに encryption を含み、"end-to-end" というフレーズを含み、signal.org または whatsapp.com のドメインに属し、deprecated を含まないページを探す」と説明しています。1 行で 4 つの条件を重ねられることが分かります。
ワイルドカード・否定・エイリアスで絞り込む
構文の要素は次のように整理できます。
要素 | 記法 | 公式ドキュメントの例 |
|---|---|---|
フレーズ |
|
|
ワイルドカード |
|
|
否定 |
|
|
選択（OR） |
|
|
ソート |
|
|
正規表現 |
|
|
ソートに指定できるのは relevance / date / visits / domain です。visits で並べ替えられるということは、「何度も開き直したページ」を上位に持ってくる操作ができるということでもあります。ブックマークにタグを付ける手間をかけなくても、クエリ側で絞り込めるかどうか——ここが、タグ運用を前提とするツールとの実用上の分かれ目になります。
Skip / Priority / Versioning / Alias の4ルール
クエリが「検索時の絞り込み」だとすると、ルールは「インデックスに入る前後の制御」にあたります。公式ドキュメントは 4 種類のルールを説明しています（出典: Rules - Hister Documentation）。
- Skip rules: マッチした URL をインデックスに保存しません。広告ネットワークやログインページの除外に使います
- Priority rules: マッチした文書を検索結果の上位に押し上げます。個人 wiki や社内ドキュメントなど、信頼できる情報源を優先する用途です
- Versioning rules: 再インデックス時にコンテンツの変更を追跡します。プライバシーポリシー、ドキュメントの更新、ニュース記事の変化を監視する用途です
- Aliases: クエリのショートカットです。
"gh": "domain:github.com"を定義しておけば、gh nodejsと書くだけでドメイン指定が展開されます
ルールはシングルユーザー構成ではデータディレクトリ内の rules.json に保存され、ユーザー管理を有効にした場合はユーザーごとの複製がデータベースに保存されます。
ノイズ源をインデックスに入れない設計
自動収集の副作用として、広告配信ドメインやログインページ、計測パラメータ付きの重複 URL がインデックスに紛れ込みます。Skip rules はこれを入口で止めるための仕組みです。公式ドキュメントには ^https://ads.example.com、.*?utm_source=、^https?://(login|mail).example.com/ といったパターン例が挙げられています。
パターンは Go の正規表現構文で、先読み・後読みは使えません。制約として明記されているのは次の点です。
- アンカリングにはスキームを含める必要がある（
^https://foo.comのように書く） - URL のフラグメント（
#以降）はマッチ前に除去される - クエリ文字列のパラメータは元の順序が保たれる（
utm_*は例外） - 末尾の
$アンカーは、クエリ文字列を含む URL にはマッチしない
正規表現に慣れていれば扱いやすい一方、アンカリング規則を知らないとルールが意図どおりに効かない可能性があります。導入初期にルールを組む段階では、公式ドキュメントの制約事項を先に読んでおくほうが安全です。
MCP連携でAIアシスタントから自分のインデックスを検索する
Hister が類似 OSS ともっとも異なるのが、MCP（Model Context Protocol）エンドポイントを本体機能として持っている点です。AI アシスタント側から、自分の閲覧履歴とローカルファイルのインデックスを検索させられます。
エンドポイントと提供される3つのツール
エンドポイントは POST /mcp で、トランスポートは Streamable HTTP です。提供されるツールは 3 つです（出典: MCP Integration - Hister Documentation）。
ツール | 役割 |
|---|---|
| インデックス済みの文書と閲覧履歴を検索する。セマンティック検索の併用も可能 |
| URL を厳密に指定して、保存済みのプレビューを取得する |
| インデックス済みページや開いた結果の履歴にアクセスする（非公開モードでは認証が必要） |
クライアント側の設定例として、公式ドキュメントには次の JSON が示されています。Claude Desktop と Cursor で同じ構造を使えると記載されています。
{
"mcpServers": {
"hister": {
"url": "http://127.0.0.1:4433/mcp",
"headers": {
"Authorization": "Bearer <your-access-token>"
}
}
}
}
「以前読んだ記事の内容を踏まえて要約させる」「手元のメモと訪問済みドキュメントを横断して根拠を探させる」といった使い方が、この経路で成立します。
アクセストークンの発行と認証方式
認証方式は 3 通りが説明されています。
- 静的アクセストークン:
Authorization: Bearer <your-access-token>またはX-Access-Tokenヘッダーで渡します - マルチユーザーモードの個人トークン: プロフィールページ、または
hister update-user <username> --regen-tokenで生成します - パブリックモード:
app.public: trueを有効にすると未認証アクセスを許可します（ただしget_historyは制限されたままです）
ここは慎重に設計したい部分です。MCP エンドポイントを開くということは、接続先の AI アシスタントに自分の全閲覧履歴への検索経路を渡すということでもあります。ローカル完結の構成なのか、外部のクライアントから接続させるのか、パブリックモードを使うのかによってリスクの性質が変わります。「便利そうだから公開しておく」という設定は選ばないほうがよいでしょう。
プロンプトインジェクションへの扱い
MCP でインデックスを検索させる構成には、インデックス済みコンテンツを経由したプロンプトインジェクションのリスクが伴います。悪意のあるページを一度訪問しただけで、その本文が後から AI アシスタントに読み込まれる可能性があるためです。
公式ドキュメントはこの点に触れており、「インデックスされたすべてのタイトル、URL、メタデータ値、文書本文、履歴フィールドは信頼できないソースデータである」として、これらの値に trust: "untrusted" および trust_scope: "all values in fields" のマーカーを付与すると説明しています。HTML は明示的に要求された場合かレンダリング済みプレビューとしてのみ返され、不可視の制御文字は除去されます。ただし公式ドキュメント自身が「消費する側のモデルは、レンダリング前に HTML をサニタイズする必要がある」と注記している点も見落とせません。
サーバー側が対策を組み込んでいるとはいえ、最終的な安全性はクライアント側の扱いにも依存する、という前提で構成を考える必要があります。
セマンティック検索とマルチユーザー運用の設定
ここまでの機能はローカル 1 台で完結しますが、意味検索やチーム利用を視野に入れると設定の検討範囲が広がります。
セマンティック検索を有効にするときの設定と外部送信の範囲
セマンティック検索は任意機能で、設定ファイルの semantic_search セクションで有効化します。公式の設定例は次のとおりです。
semantic_search:
enable: true
embedding_endpoint: 'http://localhost:11434/v1/embeddings'
embedding_model: 'nomic-embed-text'
embedding_timeout: 300
dimensions: 768
max_context_length: 512
chunk_overlap: 50
max_embedding_batch_size: 8
query_prefix: 'search_query: '
document_prefix: 'search_document: '
similarity_threshold: 0.5
result_limit: 10
semantic_weight: 0.4
max_embedding_concurrency: 2
embedding_endpoint の既定値が localhost:11434 である点から分かるとおり、OpenAI 互換の embeddings エンドポイントを想定した設計です。Ollama などをローカルに立てて使う構成が素直でしょう。semantic_weight はキーワード検索と意味検索のウェイト調整に、similarity_threshold は類似度のしきい値に対応します。
ここで必ず押さえておきたいのが、外部送信の範囲です。README には「任意のセマンティック検索は、あなたが選んだ embeddings エンドポイントに文書テキストを送信する」と明記されており、リモート連携を有効化する前にプライバシー概要とセマンティック検索の設定ドキュメントを確認するよう案内されています。テレメトリなし・クラウド不要というプライバシー特性は、セマンティック検索を外部 API に向けた時点で前提が変わります。この機能を使うかどうかは、閲覧履歴という性質のデータをどこまで外に出せるかという判断とセットになります。
マルチユーザー運用とデータベース選択
チームの共有サーバーに置く場合は、app.user_handling によるユーザー管理の有効化が起点になります。ユーザーごとに文書と検索結果が分離され、ルールもユーザーごとの複製がデータベースに保存されます。
データベースは既定でアプリケーションディレクトリ配下の SQLite（db.sqlite3）ですが、server.database に PostgreSQL の DSN を指定することもできます。server セクションには address / base_url / database / max_batch_body_size / oauth / oauth_only といったキーがあり、OAuth・OIDC プロバイダとの連携も設定可能です。個人利用からチーム利用へスケールさせる想定が、設定項目のレベルで用意されている構成といえます。
設定ファイルの探索順と環境変数オーバーライド
設定ファイルの探索順は公式ドキュメントで次のように定義されています。
--configで指定したパス- 環境変数
HISTER_CONFIGのパス - カレントディレクトリの
./config.yml - プラットフォーム別のデフォルト位置（Linux / macOS / Windows）
さらに HISTER__<SECTION>__<KEY>=value 形式の環境変数で個別の設定値を上書きできます（例: HISTER__APP__LOG_LEVEL=debug）。コンテナ環境やオーケストレーション下での構成管理を想定した仕組みで、設定ファイルを書き換えずに環境ごとの差分を吸収できます。
類似OSSとの違い｜Karakeep・ArchiveBox・Linkwardenとの比較
「訪問したページを貯めて後から探す」という領域には、既に広く使われている OSS が複数あります。Hister を採用するかどうかは、これらとの位置づけの違いを理解できているかで決まります。
5つのOSSの基本データ比較
以下は GitHub API から取得した 2026 年 9 月 2 日時点の値です。
リポジトリ | スター数 | 言語 | ライセンス | 最終プッシュ | 中心となる目的 |
|---|---|---|---|---|---|
asciimoo/hister | 3,523 | Go | AGPL-3.0 | 2026-09-01 | 訪問ページ・ローカルファイルの全文検索 |
karakeep-app/karakeep | 28,719 | TypeScript | AGPL-3.0 | 2026-08-31 | AI 自動タグ付けによるブックマーク整理 |
ArchiveBox/ArchiveBox | 28,223 | Python | MIT | 2026-09-01 | ページの完全アーカイブ（保全） |
linkwarden/linkwarden | 19,658 | TypeScript | AGPL-3.0 | 2026-09-01 | 協働型ブックマーク管理 |
go-shiori/shiori | 11,619 | Go | MIT | 2026-07-10 | 軽量なブックマーク管理 |
スター数では Karakeep と ArchiveBox が Hister の 8 倍前後という差があります。エコシステムの成熟度、日本語を含む情報量、トラブル時に参照できる先行事例の多さという観点では、この差は無視できません。一方で、5 つのプロジェクトは目的が異なるため、スター数だけで優劣を判断できる関係にはありません。差分を 3 つの軸で整理します。
「登録して貯める」か「訪問して貯まる」か
もっとも大きな差は収集の起点です。Karakeep・Linkwarden・Shiori は、いずれもユーザーが URL を登録することを前提としています。ArchiveBox も URL リスト・履歴・ブックマークの取り込みという形で、「保存対象を指定する」ところから始まります。
対して Hister は、ブラウザ拡張によって訪問しただけでインデックスに入る構成を標準としています。「後で必要になるかどうか」を訪問時点で判断しなくてよい、という点が設計思想の中心にあります。冒頭で挙げた「登録し忘れたページは検索できない」という問題に、収集フェーズで対処しているわけです。
裏を返せば、この設計は「意図的に選んだページだけを整理された状態で保管したい」というニーズには噛み合いません。すべての訪問ページが入ってくる前提のため、Skip rules によるノイズ制御とディスク容量の監視が運用の一部になります。整理された小さなコレクションを求めるなら Linkwarden や Shiori、網羅的なインデックスを求めるなら Hister、という分かれ方になります。
アーカイブ目的（ArchiveBox）と検索目的（Hister）の違い
ArchiveBox は Web アーカイバであり、HTML・JavaScript・PDF・メディアなど複数形式でページを永続的に保存することが主眼です。リンク切れ対策としての「保全」が目的であり、検索は副次的な位置づけになります。
Hister は逆に、「保存した内容を全文で引き当てる」ことが主眼です。独自のクエリ言語、Priority rules による結果順位の制御、セマンティック検索といった機能が検索側に集中しているのはそのためです。HTML プレビューは保存されますが、ArchiveBox のような多形式アーカイブは行いません。
「10 年後にも同じ見た目で読めるように保存したい」なら ArchiveBox、「読んだ内容を思い出せるように引き当てたい」なら Hister、という切り分けになります。両者は排他ではなく、目的が違うため併用も成立します。
AI連携の方向が逆（Karakeepの自動タグ付け vs HisterのMCP検索提供）
Karakeep も AI を使いますが、方向が逆です。Karakeep は LLM を整理に使います。登録したブックマークに自動でタグを付け、要約を生成し、後から探しやすくするというアプローチです。
Hister は LLM を整理に使うのではなく、MCP エンドポイントを提供して AI アシスタント側からインデックスを検索させる方向の連携を持っています。AI がインデックスの利用者になる、という構図です。2026 年 9 月 2 日時点の各公式ドキュメントの記載を確認する限り、MCP エンドポイントを本体機能として備えているのは、比較した 5 つのうち Hister のみです。
したがって、次のように整理できます。
- 貯めたものを AI に整理してほしい → Karakeep の方向
- 貯めたものを AI に検索させたい → Hister の方向
「AI コーディングツールから、自分が過去に読んだ技術記事と手元のメモを横断検索させたい」という要件があるなら、この差は決定的です。
Histerの導入判断で確認したいポイント
最後に、公式ドキュメントに記載されている事実をもとに、採用前に確認しておきたい論点を整理します。
セキュリティとデータ管理で自分が負う責任範囲
公式ドキュメントは、ユーザー側の責任範囲を明示しています。
論点 | 公式ドキュメントの記載 |
|---|---|
暗号化 | インデックスされたデータは選んだサーバーに保存され、Hister による暗号化は行われない。必要ならディスク暗号化を使い、信頼できないネットワーク越しに接続する場合は HTTPS を使う |
データ保持 | 文書に自動的な有効期限も総容量クォータもない。保持ポリシー・保存上限・削除・バージョニング・バックアップはユーザーが設定する |
ディスク消費 | 1 ページあたり平均約 100KB。監視は運用者の責任 |
公開範囲 | 既定のサーバーアドレスは |
外部送信 | セマンティック検索を有効化すると、文書テキストが指定した embeddings エンドポイントへ送信される |
ライセンス | AGPL-3.0。改変版をネットワーク越しに提供する場合はソース開示義務が生じる |
成熟度 | 最新リリースは v0.18.0（2026-08-23）で、1.0 未満のバージョン系列 |
閲覧履歴は、扱いを誤ると影響の大きい種類のデータです。「自分のサーバーに置くから安全」ではなく、「自分のサーバーに置くから、暗号化・アクセス制御・バックアップの責任も自分にある」と読み替えるのが正確です。
向いているケースと慎重に判断したいケース
ここまでの整理を踏まえると、判断の目安は次のようになります。
向いていると考えられるケース
- 技術ドキュメントや記事を大量に読み、「読んだ内容を思い出せない」ことが実務のボトルネックになっている
- ブックマーク登録という能動的な操作が続かず、既存のブックマーク管理ツールが形骸化している
- 社内 wiki や公式ドキュメントサイトをクロールして、自分のメモと横断検索したい
- AI コーディングツールや AI アシスタントから、自分の情報資産を検索させたい
- 単一バイナリのサーバーをローカルまたは自分の VPS で運用する体制がある
慎重に判断したいケース
- 保存物を「リンク切れに備えて完全な形で永続保存」したい（ArchiveBox のほうが目的に合致します）
- チームで共有・注釈・コレクション管理を行いたい（Linkwarden の主眼に近い領域です）
- 訪問ページの自動収集そのものが、組織のセキュリティポリシー上許容されない
- 1.0 未満のバージョン系列を業務クリティカルな基盤に組み込むことに抵抗がある
- 自社プロダクトへの組み込みや SaaS 提供を想定しており、AGPL-3.0 の扱いに判断が必要
まず確認するなら公式デモとクイックスタートから
導入判断の次のステップとしては、公式が用意している デモ環境 で検索 UI とクエリ言語の挙動を確認するのが最短です。自分の環境に置く段階に進むなら、クイックスタート がブラウザ拡張の設定まで含めた手順を案内しています。そのうえで、運用設計に直結する Data Storage and Lifecycle と Configuration Reference を読むと、必要なディスク容量とバックアップ方針の見積もりが立てられます。
まとめ
Hister は、訪問した Web ページ、ブラウザ履歴、クロール結果、ローカルファイルを 1 つの全文インデックスに集約し、独自のクエリ言語・ルール・MCP 経由で引き当てるための、Go 製のセルフホスト型検索エンジンです。ブックマーク管理ツールとの最大の違いは、収集が「登録」ではなく「訪問」を起点とする点にあります。
採用を判断する軸は、次の 4 つに集約できます。
- 自動収集を求めるか、選別された保管を求めるか（Hister か、Linkwarden / Shiori か）
- 完全アーカイブが目的か、全文検索が目的か（ArchiveBox か、Hister か）
- AI に整理させたいか、AI に検索させたいか（Karakeep か、Hister か）
- 暗号化・容量監視・バックアップ・公開範囲の運用責任を負えるか
なお、Hister は GitHub Trending にもランクインしており、同時期に注目を集めた他のリポジトリとあわせて俯瞰したい場合はGitHub Trending 週間ランキング（2026年第36週）で一覧として扱っています。ランキング記事がトレンド全体の俯瞰を担うのに対し、本記事は Hister 単体の仕組みと採否判断に絞った内容です。
本記事は README・公式ドキュメント・GitHub API の取得値に基づく整理であり、動作検証に基づくものではありません。スター数 3,523、フォーク数 161、最終プッシュ 2026-09-01、最新リリース v0.18.0 という数値は、いずれも 2026 年 9 月 2 日時点のものです。リポジトリはアーカイブされておらず、フォークでもないオリジナルのプロジェクトとして開発が継続しています。最新の状況は asciimoo/hister と 公式ドキュメント でご確認ください。
関連情報
社内の情報検索基盤やセルフホスト環境の設計・構築をご検討中の場合は、お問い合わせフォーム からご相談いただけます。要件が固まる前の技術選定の段階からご相談を承っています。
OSS や自動化まわりの知見を活かせる案件をお探しのエンジニアの方は、フリーランス向けサービス Workee のサービスページをご覧いただけます。
