AgenticSeek を自宅マシンで動かす前に読む、ローカル完結型エージェントの構成と制約

Manus の月額課金ではなく電気代で済ませたい層に向けた道具

AgenticSeek が解こうとしているのは、自律エージェントを動かすたびに従量課金とデータ送信が発生する問題である。README はこれを Manus AI の完全ローカル代替と位置づけ、ファイル、会話、検索内容が端末から出ないことを売りにしている。想定読者は、検索クエリや作業ディレクトリの中身を外部サービスに渡したくない開発者、そして API キーを一切設定せずに済ませたい層だ。README には API キー欄が並んでいるが、直後に「ローカル LLM を動かすユーザーにとって API キーは完全に任意であり、それがこのプロジェクトの主目的だ」と明記されている。つまりクラウド事業者を併用する構成も許容しつつ、既定の想定は完全ローカルである。README 自身が「ゼロロードマップ、ゼロ資金」のサイドプロジェクトだと述べている点は、採用判断の前提として重い。サポート体制やリリースサイクルを期待して導入する種類のソフトウェアではない。

エージェント選択とタスク分解を司る Python 側の役割

リポジトリの主要言語は Python で、README が示す構成は大きく分けて三つに分かれる。ユーザーの入力を解釈してどのエージェントに渡すかを決める層、ウェブ検索を担う SearxNG、そして推論を担うローカル LLM サーバーである。README は「あなたが尋ねると、どのエージェントが適切かを自動で判断する」と説明し、旅行計画から複雑なプロジェクトまで大きなタスクを段階に分割して複数のエージェントで処理すると述べている。コーディングについては Python、C、Go、Java などのプログラムを書いてデバッグし実行できると記載されている。ここで注意したいのは、この自動選択の精度がそのまま推論モデルの能力に依存するという点だ。ルーティング自体もモデルの判断である以上、小さなモデルでは誤ったエージェントに流れる可能性がある。README はこの失敗率について何も数値を出していない。音声機能は「進行中」と明記されており、完成済みの機能として扱うべきではない。

SearxNG と Redis を Docker で束ねる構成

検索は SearxNG を Docker コンテナとして動かし、バックエンドがそこへ HTTP で問い合わせる形になっている。Redis も同梱サービスとして起動し、.env の REDIS_BASE_URL は redis://redis:6379/0 のまま変更しないよう指示されている。ここで最も事故が起きやすいのが SEARXNG_BASE_URL である。README は実行形態ごとに値を分けている。Web インターフェースでバックエンドを Docker 内で動かす場合（./start_services.sh full）は http://searxng:8080 を使い、SEARXNG_PORT を変更していてもコンテナ内部は常に 8080 であるためこの値は変わらない。一方、CLI モードでバックエンドをホスト上で動かす場合（uv run cli.py）は http://localhost:8080 を使い、SEARXNG_PORT を 8001 などに変えていればそのポートを指定する。README は searxng というホスト名は Docker 内部にしか存在しないため CLI からは解決できないと明言している。加えて .env はプロセス起動時に一度だけ読まれるので、変更後はバックエンドの再起動が必要になる。ブラウザから SearxNG を確認するときは必ずホスト側ポートを使う。

セットアップ手順と .env で実際に触るキー

前提として Git、Python 3.10.x、Docker Engine と Docker Compose V2 が必要とされている。Python は 3.10.x が強く推奨され、他のバージョンでは依存関係エラーが起きる可能性があると README は警告している。手順はまずリポジトリを取得して .env を用意する。git clone https://github.com/Fosowl/agenticSeek.git を実行し、cd agenticSeek の後、mv .env.example .env で設定ファイルを作る。次に .env を編集する。触るキーは SEARXNG_BASE_URL、SEARXNG_PORT、REDIS_BASE_URL、WORK_DIR、OLLAMA_PORT、LM_STUDIO_PORT、CUSTOM_ADDITIONAL_LLM_PORT、そして任意の各種 API キーである。WORK_DIR はエージェントが読み書きできる作業ディレクトリのパスで、ここに置いたファイルはエージェントから触れる状態になる。Docker の起動確認は docker info で行う。ローカル LLM を使う場合、OLLAMA_PORT は既定で 11434、LM_STUDIO_PORT は 1234 が例として示されている。API キー欄は空のままでも動作する想定だ。

ハードウェア要件という最大の制約

このプロジェクトの実用性を決めるのはソフトウェアではなく GPU メモリである。README は「十分なハードウェアがあれば API キーは空のままでよい」と書き、逆に「あなたのハードウェアがローカルで LLM を動かせないなら」という条件節を Troubleshooting の案内とともに置いている。つまりローカル推論が動かない環境では、このツールの中心的な利点が成立しない。Ollama や LM Studio のポート番号は設定できても、モデルを載せる VRAM を設定で増やすことはできない。もう一つの制約は Python 3.10.x への固定である。より新しいインタプリタを使いたい開発者にとって、これは環境を分ける手間を意味する。検索についても、SearxNG を別プロセスとして立てる必要があり、単体バイナリを叩けば済む話ではない。Docker が使えない環境、たとえば制限の厳しい社内端末では、この構成自体が組めない。

クラウド API 併用型のエージェントフレームワークとの違い

比較対象として分かりやすいのは、OpenAI や Anthropic の API を前提に組み立てられたエージェントフレームワークである。あちらは推論をすべて外部に委ねるため、モデルの能力は事業者の最新版に追従でき、必要なハードウェアはほぼゼロに近い。代わりに、送信した内容は事業者側を通り、利用量に応じた課金が発生する。AgenticSeek はこの関係を反転させる。推論を手元に置くことで送信と課金をなくし、その代償としてハードウェア投資とモデル品質の頭打ちを受け入れる。README が .env に OPENAI_API_KEY や DEEPSEEK_API_KEY、OPENROUTER_API_KEY などの欄を用意しているのは、この二つの方式が排他ではないことを示している。ただし README はこれらを「任意」としか説明しておらず、併用時のルーティングやフォールバックの挙動については記述がない。ハイブリッド構成を前提に設計判断を下すには、現状の README だけでは材料が足りない。

GPL-3.0 であることの実務的な意味

ライセンスは GPL-3.0 である。これは寛容ライセンスではなくコピーレフト型であり、AgenticSeek を組み込んだり改変したりしたものを配布する場合、その配布物にも同じライセンス条件が及ぶ。社内ツールとして自組織内で使うだけなら配布には当たらないが、改変版を顧客に納品する、あるいは SaaS として外部に提供するといった使い方を検討しているなら、法務確認は避けられない。ここで断っておくと、これは法的助言ではなく、ライセンス識別子から読み取れる一般的な性質の説明である。加えて README が「ゼロロードマップ、ゼロ資金」のサイドプロジェクトだと自ら述べている点は、保守コストの見積もりに直結する。アップグレードの互換性保証やセキュリティ修正の期限を前提にできないため、導入するならフォークして自組織で面倒を見る覚悟が要る。依存関係が Python 3.10.x に寄っていることも、長期的には自前で維持する側の負担になる。

編集部の結論

導入を検討すべきなのは、ワークステーションに十分な VRAM があり、検索クエリや作業ファイルを外部に出したくない開発者だ。逆に、ノート PC しか持たない、あるいはモデル品質を最優先したい場合には向かない。最初に確認すべきは、Python 3.10.x が用意できるか、Docker Compose V2 が入っているか、そして .env の SEARXNG_BASE_URL を CLI 実行なら http://localhost:8080、Docker 内バックエンドなら http://searxng:8080 のどちらにすべきかという一点である。ここを取り違えると検索だけが静かに失敗する。

公式情報源

1. Fosowl/agenticSeek on GitHub
2. Issues
3. License: GPL-3.0
4. Project website
5. README