Vane(Perplexica 2.0)Ollama と llama.cpp を使用したクイックスタート
ローカル LLM を活用したセルフホスティング AI 検索
Vane は、「出典付き AI 検索」領域において、より実用的な選択肢の一つです。これは、リアルタイムのウェブ取得とローカルまたはクラウド上の LLM(大規模言語モデル)を組み合わせた、セルフホスティング可能な回答エンジンであり、スタック全体をユーザーの管理下に置くことができます。
このプロジェクトは当初、Perplexica として知られていました。Vane への名称変更は単なる cosmetic(外見上の)な変更ではなく、ブランドの整理だけでなく、「クローン」という枠組みから脱却し、一般的な回答エンジンへと位置づけをシフトさせることを反映しています。

このスタックの有用な部分は UI だけでなく、推論とデータがどこにあるかにも関わります。2026 年の LLM ホスティング比較 では、ローカル、セルフホスティング、クラウド環境を統合し、Vane を他のランタイムやデプロイメントの選択肢と比較できるようにしています。
本記事では、技術的な読者が実際に気にする部分に焦点を当てます。システムの仕組み、最小限の Docker クイックスタート、Ollama および llama.cpp(直接または LM Studio を通じて)を用いたローカル推論での実行方法について解説します。また、FAQ の各トピックは、単に末尾にまとめるのではなく、文脈の中で回答しています。
Vane とは何か、AI 検索エンジンの仕組み
高レベルで言えば、Vane はチャット UI に検索と出典機能を組み合わせた Next.js アプリケーションです。そのコアアーキテクチャは、現代の AI 検索エンジンから期待されるものとおなじです。チャットと検索用の API ルート、取得を行うタイミングを決定するオーケストレーション、そして出典を意識した回答生成機能です。
UI でクエリ(問い合わせ)を提出すると、Vane は POST /api/chat を呼び出します。内部的なワークフローは意図的に構造化されています。
- まず質問を分類し、調査が必要かどうか、どのヘルパーを実行するべきかを決定します。
- 調査とウィジェットを並行して実行します。
- 最終的な回答を生成し、出典を含めます。
この「AI 検索エンジン」というラベルは重要です。これは単なるチャットフロントエンドではありません。決定的な違いは、取得拡張生成(RAG: Retrieval Augmented Generation)にあります。Vane は LLM のパラメータだけに依存するのではなく、外部コンテキスト(ウェブ結果とオプションでユーザーアップロード)を取得し、それを最終回答の基盤として利用します。そのドキュメントでは、ウェブ検索と「ユーザーアップロードファイルの検索」が調査の一部として明記されており、アップロードに対する意味論的検索には埋め込み(embedding)が使用されています。
出典は後から考えられたものではありません。Vane はモデルに対して使用した参照を引用するようプロンプトし、UI はそれらの出典を回答の横にレンダリングします。実際には、これが「役に立つ」AI 検索と、単に検索ボタンが付いただけの自信過剰な幻覚生成器を分ける点です。
ウェブ取得層の下部には、ほとんどのセットアップで SearxNG が配置されています。SearxNG は多数の検索サービスの結果を集約する無料のメタ検索エンジンであり、設計上、ユーザーを追跡したりプロファイルを作成したりしません。これは、通常単一のベンダーのインデックスと商業的なデータ契約を提供する有料検索 API とは、根本的に異なる哲学です。
Perplexica から Vane への歴史と名称変更
Perplexica は、Perplexity AI にインスパイアされたオープンソースでセルフホスティング可能な回答エンジンとして始まりました。いくつかの公開ガイドでは、まだこのプロジェクトを「以前は Perplexica として知られていた」と記述し、Vane を敵対的なフォークではなく継承者として扱っています。
名称変更は、アップストリームリポジトリで直接実装されました。マスターブランチのコミット履歴では、feat(app): rename to 'vane' というタイトルのコミットが 2026 年 3 月 9 日(SHA 39c0f19)に存在します。
「なぜ」よりも「どのように」の方が興味深いでしょう。その名称変更コミットは単なる README の修正ではありません。Docker イメージ名を itzcrazykns1337/perplexica から itzcrazykns1337/vane に変更し、コンテナのファイルシステムパスを /home/perplexica から /home/vane に調整し、プロジェクトのテキストとアセットもそれに応じて更新しています。
オープンソースの AI プロジェクトがなぜ改名されるのか疑問に思うなら、Vane はその典型的な要因を示す教科書的な例です。
- 商業ブランドとの名称の近さが混乱(そして時には法的リスク)を生む。
- プロジェクトの範囲が元の枠組みを超えて拡大する(「クローン」から「回答エンジン」へ)。
- 配布アーティファクト(Docker イメージ、ドキュメント、UI ラベル)に整合性のあるアイデンティティが必要になる。
また、エコシステムは一夜にして名前を変えるわけではありません。Docker Hub には、maintainer アカウントの下に両方のリポジトリ(itzcrazykns1337/vane と itzcrazykns1337/perplexica)が表示されています。したがって、リポジトリのブランド変更後も、古いブログ記事や compose ファイル、レジストリ参照で Perplexica という命名を使用しているものを見ることになります。
Docker クイックスタートと基本設定
Vane の公式 README は、驚くほど直接的です。単一のコンテナを実行するだけで、Vane とバンドルされた SearxNG 検索バックエンドが手に入ります。最小限の Docker クイックスタートは以下の通りです。
docker run -d -p 3000:3000 -v vane-data:/home/vane/data --name vane itzcrazykns1337/vane:latest
このイメージは「すぐに使える」パスとして位置づけられており、SearxNG が既に含まれているため、UI をテストするために外部の検索バックエンドを用意する必要がありません。設定は、http://localhost:3000 でウェブ UI を開いた後のセットアップ画面で行われます。
すでに SearxNG を実行している場合(ホームラボでは一般的です)、“slim” Vane イメージは、外部 SearxNG インスタンスへの SEARXNG_API_URL を指定することを期待します。README では、2 つの実用的な SearxNG 設定要件についても言及しています。JSON 出力を有効にし、Wolfram Alpha エンジンを有効にすることです。
docker run -d -p 3000:3000 \
-e SEARXNG_API_URL=http://your-searxng-url:8080 \
-v vane-data:/home/vane/data \
--name vane \
itzcrazykns1337/vane:slim-latest
Vane のアップデートもリポジトリ内で文書化されています。公式のアップデートワークフローは基本的に、最新のイメージをプルし、同じボリュームで再起動することで、設定を保持します。
docker pull itzcrazykns1337/vane:latest
docker stop vane
docker rm vane
docker run -d -p 3000:3000 -v vane-data:/home/vane/data --name vane itzcrazykns1337/vane:latest
一度実行すれば、Vane はブラウザの検索エンジンショートカットとして使用できます。カスタムエンジンを http://localhost:3000/?q=%s へ指向させるだけです。これは小さな機能ですが、「AI 検索」をアプリへの訪問ではなく、検索そのもののように感じたい場合、大きなインパクトがあります。
自動化と統合のために、Vane は API を提供しています。ドキュメントでは、設定済みのプロバイダーとモデルを検出するための GET /api/providers と、選択したチャットモデル、埋め込みモデル、ソース、および optimizationMode(speed, balanced, quality)で検索を実行するための POST /api/search について説明しています。
Ollama を使ったローカル LLM のセットアップ
Vane は、同じ UI で Ollama とクラウドプロバイダーの両方をサポートしており、「ベンダー」ではなく「接続」と「モデル」の観点で考えるなら、これが適切な抽象化です。
最も一般的な問題はモデルの選択ではなく、ネットワークです。Vane が Docker で実行され、Ollama がホスト上で実行される場合、コンテナ内部から見た「localhost」は、あなたが想像するものではありません。Vane は、コンテナから Ollama に接続するための OS 固有のベース URL を文書化しています。
Docker 接続の注意点
Vane のトラブルシューティングセクションでは、以下を明確に推奨しています。
- Windows および macOS:
http://host.docker.internal:11434 - Linux:
http://<private_ip_of_host>:11434
Linux については、Vane は Ollama がデフォルトで 127.0.0.1 にバインドされ、公開する必要があると指摘しています。README では、systemd サービスで OLLAMA_HOST=0.0.0.0:11434 を設定し、サービスを再起動することを提案しています。
これは Ollama 自身の serve 環境変数とも整合しており、OLLAMA_HOST はサーバーバインドアドレスを制御し、デフォルトは 127.0.0.1:11434 です。
モデルをウォームアップし、モデルを選択する
ローカル推論を実行する場合、コールドスタート(読み込み待ち)を感じます。Ollama には、モデルをロードしたままにするための 2 つの関連する仕組みがあります。
- サーバー設定としての
OLLAMA_KEEP_ALIVE。 /api/generateおよび/api/chatに対するリクエストごとに設定可能なkeep_aliveパラメータで、サーバーのデフォルトを上書きします。
Vane は、Ollama モデル用の独自の keep_alive 機能を追加しました(アプリがモデルがメモリに留まる時間を制御できるように)。この機能は Vane の v1.10.0 リリースノートに登場します。
モデル選択は、インターネット上で複雑になりがちな部分です。Vane スタイルの作業において、最も実用的な分割は以下の通りです。
- 指示調整(summarisation と synthesis 用)されたチャットモデル。
- アップロードと取得されたテキストの類似度検索用の埋め込みモデル。Vane の API ドキュメントでは、検索リクエストが明示的にチャットモデルと埋め込みモデルの両方を選択することが示されています。
Ollama 自体も埋め込みワークフローをサポートしており、CLI ドキュメントにも nomic-embed-text を使用した埋め込みの例が含まれています。
これはまた、クラウド API を使わずにローカルで AI 検索を実行するかどうかという FAQ に対する答えでもあります。Docker 上の Vane、ローカルの SearxNG、そしてハードウェア上の Ollama を使うことで、検索クエリとプライベートなドキュメントアップロードの両方を、ご自身のネットワーク境界内におくことができます。(もしクラウドプロバイダーに接続することに決めた場合は、データパスは当然変わります。)
llama.cpp を使ったローカル LLM のセットアップ
Vane を llama.cpp とペアリングする現実的な方法は 2 つあります。
- LM Studio をサーバー層として使用し(Vane がそれと通信するようにする)。
- llama.cpp 自身の HTTP サーバー(llama-server)を実行し、OpenAI 互換エンドポイント経由で接続する。
Vane は明示的に「ローカル OpenAI-API 互換サーバー」をサポートしており、通常の要件を指摘しています。127.0.0.1 ではなく 0.0.0.0 にバインドし、正しいポートを使用し、サーバーに存在するモデル名を設定し、サーバーが認証を強制しない場合でも API キーフィールドを空にしないことなどです。
LM Studio は、ローカルバックエンド(しばしば llama.cpp)の上にありながら OpenAI 互換 API を公開するため、ここで関連します。Vane v1.12.1 は特に、LM Studio プロバイダーの追加を注記しています。
LM Studio のドキュメントでは、サポートされている OpenAI 互換エンドポイントがリストされ、http://localhost:1234/v1(ポート 1234 を仮定)を使用したベース URL の例が示されています。これは重要です。Vane の観点からは、それは「ただの別の OpenAI スタイルのサーバー」だからです。
llama.cpp を直接実行することを好む場合、公式の llama.cpp HTTP サーバーは、OpenAI API 互換のチャット完了、レスポンス、埋め込みルートをサポートしており、サーバー機能の長いリスト(バッチ処理、モニタリング、ツール使用など)も備えています。
フラグを記憶しなくても、重要な部分は以下の通りです。
- サーバーは存在し、積極的に文書化されています。
- API 表面は、OpenAI スタイルのクライアントが通信するのに十分互換性があり、Vane がその「OpenAI 互換」接続パターンに必要とするものです。
最近リリースされたものと、現在変更されているもの
Vane が過去 1 年で何になったかを理解したいなら、熱狂的な話題ではなく、リリースノートとマスターブランチの履歴を追うべきです。
2026 年 4 月 10 日(オーストラリア/メルボルン)現在、リリースページで確認できる最新のタグ付き GitHub リリースは v1.12.1(2025 年 12 月 31 日)です。そのリリースノートでは、LM Studio プロバイダーの追加と、OpenAI 互換プロバイダーおよび JSON パース周りの関数呼び出しの修正が記載されています。
先行するリリースでは、より大きな変化が概説されています。
- v1.11.0(2025 年 10 月 21 日)では、新しいセットアップウィザードと再設計された設定システムが導入され、より広範なプロバイダーサポートと、単一コマンドでの Docker インストールパスが提供されました。また、動的なモデル取得と、様々な UI および開発者体験の改善が言及されています。
- v1.12.0(2025 年 12 月 27 日)はアーキテクチャのリセットです。ストリーミング、生成、プロバイダー固有の挙動のために LangChain を削除し、独自の実装に置き換えました。「プロバイダー」を「接続」に名称変更し、UI とコードのレンダリングを改善し、より多くの機能をプロジェクト独自の抽象化(以前の解析アプローチよりも改善された関数呼び出しを含む)に移しました。
- それ以前、v1.10.0(2025 年 3 月 20 日)では、ファイルアップロード(PDF、TXT、DOCX)が追加され、Ollama の
keep_aliveパラメータが追加され、保守性とフォーカスモード作成を改善するためのメタ検索エージェントクラスが追加され、自動画像およびビデオ検索機能が追加されました。
ブランディング面では、Vane への名称変更は 2026 年 3 月 9 日にマスターブランチにマージされました(feat(app): rename to 'vane')。コードベースの命名と Docker アーティファクトの両方が更新されました。
そして、プロジェクトは 2025 年 12 月のリリース後も進化を止めませんでした。2026 年 4 月 8-9 日のマスターブランチコミットには、「深い調査モードの更新、コンテキスト管理」と、新しい検索実行およびスクレイピング関連の変更が含まれています。つまり、「AI 検索エンジン」部分は、リリースタグの後ろで凍結されているのではなく、まだ積極的にイテレーションされています。