Vane（Perplexica 2.0）のOllamaとllama.cppによるクイックスタート
ローカルLLMによるセルフホステッドAI検索
Vaneは、「引用付きAI検索」分野でより実用志向の選択肢の一つです。ライブなWeb検索とローカルまたはクラウドのLLMを組み合わせつつ、スタック全体を自分自身の管理下におくセルフホスト型の回答エンジンです。
このプロジェクトは元々 Perplexica として知られており、Vaneへの名称変更は単なる装飾ではありません。ブランドの整理とともに、「クローン」であるという位置づけから離れ、一般的な回答エンジンへと移行する過程を反映しています。
スタックの有益な部分はUIだけでなく、推論やデータがどこに置かれるかでもあるため、2026年のLLMホスティング比較では、ローカル、セルフホスト、クラウドのセットアップを統合し、Vaneを他のランタイムやデプロイ選択肢と並べて比較できるようにしています。
この記事では、技術的な読者が実際に気にする部分に焦点を当てます。システムの動作原理、最小構成のDockerクイックスタート、そしてOllamaやllama.cpp（直接またはLM Studio経由）によるローカル推論での実行方法です。また、各FAQのトピックは記事の末尾に追記するのではなく、文脈の中で回答していきます。
Vaneは意図的に回答エンジンであり、再帰的なリサーチシステムではありません。この違いについて明確にする価値があります。セルフホスト型ディープリサーチシステム：12ツールの比較では、Vaneを12のセルフホスト型リサーチアーキテクチャと比較し、「複数の検索を実行する」と「ディープリサーチを実行する」が同じ意味ではない理由を説明しています。
Vaneとは何か、AI検索エンジンの仕組み
大まかなレベルで言えば、VaneはチャットUIに検索と引用を組み合わせるNext.jsアプリケーションです。コアなアーキテクチャ構成要素は、現代的なAI検索エンジンに期待されるものそのものです。チャットと検索用のAPIルート、検索を行うタイミングを決定するオーケストレーション、そして引用を考慮した回答生成処理です。
UIでクエリを送信すると、VaneはPOST /api/chatを呼び出します。内部では、ワークフローは意図的かつ構造化されています。
- まず、質問を分類し、リサーチが必要かどうか、そしてどのヘルパーを実行すべきかを決定します。
- リサーチとウィジェットを並列実行します。
- 最終的な回答を生成し、引用を含めます。
「AI検索エンジン」というラベルは重要です。なぜなら、これは単なるチャットフロントエンドではないからです。重要な違いは検索拡張生成（Retrieval Augmented Generation）です。VaneはLLMのパラメータだけに頼るのではなく、外部コンテキスト（Web検索結果やオプションのユーザーアップロードファイル）を取得し、それを最終回答の根拠とする材料として使用します。Vaneのドキュメントは、Web検索と「ユーザーアップロードファイルの検索」をリサーチの一部として明示しており、アップロードファイルのセマンティック検索には埋め込み（エムベッド）が使用されています。
引用は後付けのものではありません。Vaneはモデルに対し、使用した参考文献を引用するようプロンプトし、UIはそれらの引用を応答の横に表示します。実際には、これが「役に立つ」AI検索を、たまたま検索ボタンがあるだけ確信犯的なハルシネーション（誤情報の生成）マシンから区別しているものです。
ほとんどのセットアップでは、Web検索レイヤーの下に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では、保守者アカウント配下で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でWeb UIを開いた後のセットアップ画面で行います。
すでにSearxNGを運用している場合（ホームラボではよくあります）、Vaneの「slim」イメージは、SEARXNG_API_URLを使用して外部のSearxNGインスタンスを指すことを前提としています。READMEでは、実用的なSearxNG設定の期待値として、JSON出力の有効化とWolfram Alphaエンジンの有効化の2点も指摘しています。
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とクラウドプロバイダーの両方をサポートしています。「ベンダー」ではなく「コネクション」と「モデル」という観点で考える場合、これは適切な抽象化です。
Ollama チートシートには、モデルの選択やDockerのネットワーク問題に突き当たる前にOllamaを確認する際に役立つ、一般的なCLIコマンドやAPIの簡単な確認方法がリストされています。
最も一般的な問題はモデルの選択ではなく、ネットワークです。VaneがDocker内で動作し、Ollamaがホスト上で動作している場合、コンテナ内部から見た「localhost」は、あなたが想像しているような意味ではありません。Vaneは、コンテナからOllamaに接続するためのOS別ベースURLをドキュメント化しています。
Dockerとの接続に関する注意点
Vaneのトラブルシューティングセクションでは、明確に以下を推奨しています。
- WindowsおよびmacOS:
http://host.docker.internal:11434 - Linux:
http://<ホストのプライベートIP>: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スタイルの作業において、最も実用的な分割は以下の通りです。
- 指示チューニングされたチャットモデル（要約と統合のために）。
- アップロードや検索されたテキストの類似性検索のためのエムベッドモデル。VaneのAPIドキュメントは、検索リクエストがチャットモデルとエムベッドモデルの両方を明示的に選択することを示しています。
Ollama自体もエムベッドメントワークフローをサポートしており、CLIのドキュメントにもnomic-embed-textを使用したエムベッドメントの例が含まれています。
また、これはクラウドAPIなしでローカルにAI検索を実行するというFAQへの回答でもあります。VaneをDockerで、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はここで関連性ががあります。なぜなら、LM Studioはローカルバックエンド（しばしばllama.cpp）の上に位置しつつ、OpenAI互換APIを公開するからです。Vane v1.12.1は、LM Studioプロバイダーの追加を具体的に注記しています。
LM Studioのドキュメントは、サポートされるOpenAI互換エンドポイントをリストし、ベースURLの例としてhttp://localhost:1234/v1（ポート1234を前提）を示しています。これは重要です。なぜなら、Vaneの観点からは、それは「また別のOpenAIスタイルのサーバー」にすぎないからです。
llama.cppを直接実行する方が好みであれば、llama.cpp クイックスタート（CLIとサーバー）では、インストール、llama-cli、およびllama-serverをカバーしています。公式の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検索エンジン」部分は、リリースタグの後ろに凍結されているわけではなく、まだ積極的に反復されています。
