Khojとは？セルフホスト型AI第二の脳の実力｜pipとDockerの配布が419日前で止まっている件を実測

自分のノート・PDF・Markdownに対して自然言語で質問し、Webの情報も混ぜて答えを返す。それを自分のサーバーで動かせる——Khoj は「AI second brain（AIの第二の脳）」という表現でその体験を提供するOSSで、GitHubスターは 37,161（2026-09-07 時点）に達している。Obsidianプラグインとしても配布され、5万回以上ダウンロードされている。

ただし、READMEやドキュメントが説明する姿と、pip install khoj を実行したときに手に入るものは同じではない。実測すると、既定の配布経路が渡してくるのは 2025-07-15 に公開された版だった。419日前である。

RAGの仕組みそのものや、ベクトルDBの選び方を含む全体像は RAGとは？仕組み・構築・ベクトルDB選定までの2026年実装マップ にまとめてある。本記事はそのうちKhoj1本を、配布物を実際に取得して掘り下げる。

検証環境は macOS 14（Darwin 23.5.0）/ Apple Silicon (arm64)、Python は Homebrew の 3.12.x を使用した。

Khojとは——自分のドキュメントに質問できるセルフホスト型アシスタント

Khojが解こうとしている問題は明快だ。自分の手元にある文書は検索できるが、質問には答えてくれない。 Obsidianのノート、PDF、Markdown、Notionのページ。それらに対して「先月の設計判断はどうなっていたか」と聞ける状態を作る、というのがKhojの提供価値である。

構成要素を整理すると4層になる。

ここで押さえておきたいのは、Khojは単なるRAGライブラリではなくWebアプリケーションであるという点だ。依存関係を見ると django==5.1.10、django-unfold、django-apscheduler、psycopg2-binary が並ぶ。PostgreSQLを前提としたDjangoアプリで、管理画面もスケジューラも同梱される。「ライブラリを組み込む」のではなく「サーバーを1つ立てる」タイプのソフトウェアだ。

そしてライセンスは AGPL-3.0。これはOSI準拠のオープンソースだが、ネットワーク越しに利用させる場合にも改変ソースの開示義務が及ぶ強いコピーレフトである。自分と自分のチームのために社内で動かす分には論点になりにくいが、Khojを組み込んだ何かを外部へサービス提供する構成では、事前に条件を確認しておく必要がある。同じ「セルフホスト可能なRAG基盤」でも、Onyx AIとは｜旧Danswerの企業向けOSS RAG基盤・対応LLMと日本語利用を解説 のようにライセンス条件の異なる選択肢があるため、そこは要件次第で分かれる。

Khojの配布は経路ごとに版が違う——pipは419日前、Obsidianは2.0ベータ

ここが本記事の核心だ。Khojには複数の入り口があり、それぞれが渡してくるバージョンが揃っていない。実測した結果を並べる。

なぜ pip install khoj が1.42.10になるのか。 PyPIのプロジェクトメタデータで info.version が 1.42.10 を指しており、2.0系はすべて 2.0.0b29.dev12 のようなプレリリース版として公開されているためだ。pipは既定でプレリリースを候補に入れないので、安定版として最後に出た1.42.10へ着地する。全603リリースのうち、通常のバージョン番号（X.Y.Z）を持つ最後のものが1.42.10だった。

これは自分でも1コマンドで確認できる。

# pip が実際にどの版を選ぶかを、インストールせずに確認する（実測で動作を確認）
python3.12 -m venv /tmp/khojcheck && /tmp/khojcheck/bin/pip install -q --upgrade pip
/tmp/khojcheck/bin/pip install --dry-run khoj 2>&1 | grep -oE "khoj-[0-9][^ ]*" | head -2
# => khoj-1.42.10-py3-none-any.whl.metadata / khoj-1.42.10
/tmp/khojcheck/bin/pip install --dry-run --pre khoj 2>&1 | grep -oE "khoj-[0-9][^ ]*" | head -1
# => khoj-2.0.0b29.dev12-py3-none-any.whl.metadata

Dockerイメージも同じ日付で止まっている。 これはセルフホストを掲げるOSSでは見落としやすい点だ。GHCRはイメージ設定blobに作成日時を持っているので、pullせずに確認できる。

# ghcr.io のイメージがいつ作られたかを、pullせずに確認する（実測で動作を確認）
TOKEN=$(curl -s "https://ghcr.io/token?scope=repository:khoj-ai/khoj:pull&service=ghcr.io" \
  | python3 -c "import json,sys;print(json.load(sys.stdin)['token'])")
curl -s -H "Authorization: Bearer $TOKEN" \
  -H "Accept: application/vnd.oci.image.index.v1+json" \
  "https://ghcr.io/v2/khoj-ai/khoj/manifests/latest" | head -c 200
# 続けて manifest -> config blob をたどると "created" が得られる
# => latest: 2025-07-15T21:42:42Z / dev: 2025-01-10T16:55:56Z

つまり README が「Self-hostable」と掲げ、ドキュメントが 2.0 系の機能を説明していても、docker pull と pip install の既定経路は 2025年7月の姿を返す。一方でObsidianプラグイン利用者は 2.0.0-beta.28 を使っている。同じKhojについて話していても、見ている製品が違うという状況が生じる。

Khojのセルフホストでつまずく2点——Python 3.13の壁とC++のソースビルド

配布版が古いことは、機能の古さだけでなくインストールの通りにくさとして表面化する。実際に入れようとすると2つの壁に当たった。

1つ目はPythonのバージョン。 khoj は 1.42.10 も 2.0.0b29.dev12 も、メタデータの requires_python が <3.13,>=3.10 である。Python 3.13は2024年10月、3.14は2025年10月のリリースなので、いま普通に用意される処理系ではこの上限に引っかかる。3.12系を明示的に用意する必要がある。

2つ目はC++のソースビルド。 1.42.10 は依存に llama-cpp-python==0.2.88 を厳密固定している。このバージョンをPyPIで確認すると、公開されているファイルは llama_cpp_python-0.2.88.tar.gz（sdist）の1つだけで、ホイールが1つも無い。したがってどのプラットフォームでも必ずソースからコンパイルされる。

ホイールが1つも無いことは、PyPIのファイル一覧を引けばインストール前に確認できる。

# 依存がソースビルドを強制するかを、インストール前に確認する（実測で動作を確認）
curl -s https://pypi.org/pypi/llama-cpp-python/0.2.88/json \
  | python3 -c "import json,sys; d=json.load(sys.stdin); print([f['packagetype'] for f in d['urls']])"
# => ['sdist']   ← bdist_wheel が1件も無い＝必ずコンパイルされる

実際に pip install khoj を実行すると、依存の解決を終えたあと Building wheel for llama-cpp-python (pyproject.toml): still running... が延々と続く。C++コンパイラとCMakeが必要で、完了までに相当な時間がかかる。

実際に入れてみた結果——インストールは通るが、コマンドは動かない

本記事では実際に pip install khoj を最後まで走らせた。結果は次の通りだった。

・インストールは成功する。llama-cpp-python の wheel ビルドは完走し、pip show khoj は Version: 1.42.10 を返した。依存は torch・sentence-transformers・onnxruntime・opencv-python などを含めて140パッケージ超が入る
・Pythonモジュールとしては正常。python -c "import khoj" は 0.9秒で完了する
・しかし khoj コマンドは動かなかった。khoj --version を実行すると、バージョンを表示する前にDjangoのマイグレーションが走り、django.db.utils.OperationalError: connection to server at "localhost" (::1), port 5432 failed: Connection refused で停止する。khoj --help も同様で、180秒待っても出力が返らなかった

これは不具合ではなく設計である。KhojはPostgreSQL（pgvector拡張）を前提としたDjangoアプリなので、CLIの起動時点でDBへの接続とマイグレーションが必要になる。ただし利用者から見ると、pip install が成功したのに --version すら通らないという体験になるため、「pipで入れたら使える」という期待とはズレる。実際にはPostgreSQLの用意が先行タスクになる。

この点でも、README が掲げる「Get started - free」という導線と、既定の配布経路が要求する準備（Python 3.12の用意 → C++ビルド → PostgreSQLの起動）の間には距離がある。Docker Composeを使えばDBごと立ち上がるが、その latest イメージが2025-07-15である点は前述の通りだ。

興味深いのは、開発中の2.0系ではこの依存が外れていることだ。依存リストを比較すると差がはっきり出る。

ソースビルドを要求する依存は開発側では既に外されているのに、その改善が安定版として配布されていない——という構図になっている。同時に、LLM SDKのピンも大きくずれている。anthropic==0.52.0 は2025年半ばのSDKであり、== の厳密固定なので利用者が勝手に上げることもできない。SDKのバージョンは呼び出せるモデルやAPI形式に直結するため、これは機能面の制約でもある。

Docker Composeで一発、という体験を求めるなら、同じセルフホスト系でも配布が追随している選択肢を先に見るほうが早い。RAGFlowとは｜高精度な文書解析でRAGを組むOSSエンジンの使い方・Docker導入・GraphRAG や、既存のファイル基盤の上にRAGを載せる Nextcloud AIとは｜Context Chatで自前文書をRAG、ローカルLLM完結のセルフホストAI基盤 は、その観点での比較対象になる。

クラウド版とセルフホストの線引き——どちらが「本体」なのか

Khojにはホスト版（app.khoj.dev）がある。実測すると khoj.dev・app.khoj.dev ともHTTP 200を返し、稼働している。

ここで重要なのは、セルフホストとクラウドで更新の速度が構造的に違うということだ。クラウド版は運営側が任意のコミットをデプロイできるので、リポジトリの最新に近い状態を保てる。一方セルフホストの利用者は、PyPIかコンテナイメージという公開された配布物を待つしかない。その配布物が419日前で止まっている以上、両者の差は開き続ける。

これはOSS一般に当てはまる構図で、Khoj固有の問題ではない。ただし 「Self-hostable」を最初の売り文句に置いているOSS では、この差の意味が重くなる。セルフホストを選ぶ理由の多くはデータを外に出したくないという要件であり、その要件を持つ利用者ほど古い版に固定されるからだ。

判断の分かれ目を整理する。

・クラウド版で足りるなら：更新の追随を気にせず使える。ただしデータは外部へ渡る
・セルフホストが要件なら：既定の pip install / docker pull では2025年7月の版になる。--pre でプレリリースを取るか、リポジトリから直接ビルドするかを選ぶ必要がある
・プレリリースを本番に置けるか：2.0.0b29.dev12 は開発版であり、安定版として検証された配布物ではない。本番投入の可否は組織のリスク許容度に依存する

Khojを選ぶか——判断材料の整理

最後に、実測値を並べて位置づけを確認する。

Khojが噛み合うケースは、Obsidianを主戦場にしていてプラグイン経由で使う場合、あるいはクラウド版で要件が満たせる場合だ。この2つの経路は2.0系が届いており、配布の遅れの影響を受けにくい。

慎重に見るべきケースは、サーバーを立てて長期運用したい場合である。既定の配布経路が419日前で止まっており、その版はC++のソースビルドを要求し、LLM SDKも2025年半ばのバージョンに厳密固定されている。--pre を使えば開発版は取れるが、それは安定版として検証された配布物ではない。

なお、この「リポジトリは動いているのに配布が届かない」という型は、Khojだけの現象ではない。同じ2026-09-07に別途実測したターミナル向けAIコーディングツール Aider でも、mainに実装済みの改善がPyPIへ207日届いていなかった。OSSの健全性を「スター数」や「最終コミット日」だけで測ると、この型の問題は見えない。 見るべきは、レジストリが安定版として指しているバージョンと、その公開日である。

まとめ——Khojは動いているが、既定の入り口だけが古い

Khojは止まったプロジェクトではない。master は2026-08-02まで更新され、Issueも直近に立っている。開発版では llama-cpp-python へのソースビルド依存が外され、LLM SDKも新しくなっている。

問題はその成果が既定の配布経路に届いていないことだ。pip install khoj は2025-07-15の1.42.10を、docker pull ghcr.io/khoj-ai/khoj:latest は同じ日付のイメージを返す。419日前の姿である。一方でObsidianプラグイン利用者は2.0.0-beta.28を、クラウド版利用者はさらに新しい状態を使っている。

したがってKhojを評価するときの問いは「Khojは良いか」ではなく、「自分が使う入り口は、どの版のKhojを渡してくるか」になる。Obsidianとクラウドなら2.0系が届く。セルフホストを選ぶなら、既定経路が渡す版の日付を確認したうえで、--pre かソースビルドかを意識的に選ぶ必要がある。

参照ソース

・khoj-ai/khoj（GitHub 公式リポジトリ） — ★・ライセンス・既定ブランチのコミット・Issue/PR件数の一次ソース
・khoj（PyPI） — 安定版とプレリリースのバージョン・公開日時・requires_dist・requires_python の一次ソース
・Khoj 公式ドキュメント（docs.khoj.dev） — セルフホスト手順とクライアントの仕様
・llama-cpp-python 0.2.88（PyPI） — 配布ファイルがsdistのみであることの一次ソース