著者 Agentlas OSをVPSに自分でインストールする方法
Linux VPSにAgentlas OS v1.2.0を固定インストールする手順です。状態の保存先、Ollamaの接続方法、常駐プロセスや待ち受けポートがないアイドル時の実コストも確認できます。
Agentlas OS の実体
Agentlas OS は、専門エージェントをパッケージとしてディスク上に保持し、タスクごとに一時的なオーケストレーターを構成するオープンソースのエージェントランタイムです。Linux VPS に自分のユーザーアカウントでインストールして、セルフホストします。これはサービスではありません。デーモンも、待ち受けポートも、Web インターフェースも、リポジトリ内のコンテナイメージもありません。
この点が、このページの内容全体を決めます。多くのマルチエージェントシステムでは、エージェントを保持するスーパーバイザープロセスが常駐します。Agentlas はこの構成を逆にします。専門エージェントは停止中のファイルとして存在し、オーケストレーターはタスクの実行中だけ存在します。その結果、アイドル状態のハブが消費するのはメモリではなくディスク容量です。
このプロジェクトでは、オープンコアを Hephaestus と呼んでいます。コマンド、パス、環境変数では、この名前を使用します。リポジトリは agentlas-ai/Agentlas-OS で、ライセンスは Apache-2.0 です。主に Python で記述されています。
このプロジェクトは、率直に言ってどの程度初期段階ですか
リポジトリが作成されたのは 2026 年 6 月 4 日です。2026 年 8 月 12 日時点で、作成から約 10 週間が経過し、スターは約 1,150 個、フォークは 112 個です。実際の業務で利用するには、まだ新しいプロジェクトです。
重要なのは、経過期間よりもリリース頻度です。バージョン v1.1.103 は 2026 年 8 月 8 日に公開され、v1.2.0 は 2026 年 8 月 12 日にリリースされました。1.1 系だけでタグ付きリリースが 100 回を超えており、自動化によって 1 日に複数回公開されることもあります。この速度で開発が進むプロジェクトでは、火曜日から木曜日の間にも動作が変わる可能性があります。
そのため、リリースを固定してください。インストーラーはこの指定に環境変数を使用しており、以下のガイド全体でもその方法を使います。1 日に数回リリースされるプロジェクトをバージョン固定なしでインストールすると、その時間に main に存在していたものがそのままインストールされます。
VPS に必要なもの
バックグラウンドで動作するものがないため、要件は少数です。
- Linux VPS。Ubuntu 24.04 を基準にできます。インストーラーは
uname -sでオペレーティングシステムを検出し、Linux では macOS 以外の分岐を使用するため、ヘッドレス環境に対応しています。 - 環境に
curl、tar、gitがあり、動作する Python インタープリターも必要です。 raw.githubusercontent.comおよびgithub.comへの送信 HTTPS 接続。インストーラーはリリースアーカイブをダウンロードして SHA-256 を検証するため、外部へ接続できない環境にはインストールできません。- ホストハーネス。実際にモデルと通信するコーディングエージェントです。Claude Code、Codex、opencode、goose、Hermes の各アダプターに対応しています。
root は必要ありません。インストーラーが書き込むのはホームディレクトリと ~/.local/bin だけです。パスに書き込めない場合も中止せず、警告を表示します。環境自体をまだ選定中であれば、VPS でコーディングエージェントを実行するで、この構成の基盤となるベースイメージとアクセス設定を説明しています。
ピン留めしたリリースをインストールする
upstream の README には、main からスクリプトを直接 bash へパイプする 1 行のコマンドが記載されています。まずダウンロードして内容を確認してください。このスクリプトはシェル設定と、検出したすべてのエージェントハーネスに書き込むため、10 秒かけて確認する価値があります。
curl -fsSL -o install-all-runtimes.sh \
https://raw.githubusercontent.com/agentlas-ai/Agentlas-OS/main/scripts/install-all-runtimes.sh
less install-all-runtimes.sh
HEPHAESTUS_REF=v1.2.0 bash install-all-runtimes.shHEPHAESTUS_REF がピン留めに使用する値です。スクリプト内ではこの行が version="${HEPHAESTUS_REF:-v1.2.0}" になっているため、未設定のままにすると、今日は v1.2.0 がインストールされても、来週には別のバージョンになる可能性があります。明示的に設定すれば、10 月の再構築でも 8 月にテストしたものをインストールできます。
注意点が 1 つあります。上記のスクリプト URL は main を参照し、HEPHAESTUS_REF はスクリプトがダウンロードするランタイムのペイロードをピン留めします。これは別々のものです。両方をピン留めするには、main ではなくタグからスクリプトを取得します。その URL の main を v1.2.0 に置き換えてください。
実行が成功すると、書き込んだパスが出力されます。次の 2 行も含まれます。
Installed runner: /home/you/.agentlas/runtime/current/bin/hephaestus
Installed shell commands in /home/you/.local/bin (add ~/.local/bin to PATH to use them)この 2 行目を見落とす人が多くいます。新しい Ubuntu 環境では、~/.local/bin が PATH にないことが多いため、インストールが成功していても、すべての hep-* コマンドが command not found で失敗します。修正して確認してください。
echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc
hep-global statushep-global status は、グローバルルーターがインストールしたものと、検出したハーネスを報告します。これが実行されるなら、PATH は正しく設定されています。
状態の保存場所
ホームディレクトリ配下はすべてファイルで構成されるため、バックアップと移行が簡単です。
~/.agentlas/runtime/v1.2.0/にはランタイム本体が格納され、~/.agentlas/runtime/current/はアクティブなバージョンへのシンボリックリンクです。固定した2つのバージョンを並行して配置できます。~/.local/bin/にはシェルラッパーのhephaestus、hep-build、hep-network、hep-search、hep-storm、hep-cloud、hep-uploadが格納されます。~/.agentlas/networking/memory/には永続的なメモリであるplaybook-registry.json、playbook-candidates.jsonl、memory-events.jsonlが格納されます。~/.agentlas/networking/hub-agents/<slug>/memory/experience.sqliteには所有者ごとに分離されたエージェント単位の経験が格納されます。<project>/.agentlas/ontology-runtime.sqliteにはプロジェクト単位の状態が格納されるため、サーバーではなくリポジトリとともに移行できます。~/.cache/agentlas/pythonには Linux 上の Python キャッシュが格納されます。macOS では別のパスを使用し、インストーラーはunameでその分岐を選択します。
メモリのドキュメントには、Secret、未加工の認証情報、完全なトランスクリプトを、どのメモリスコープにも保存してはならないと明記されています。認証情報の値は gitignore 対象のローカルファイルに保存し、メモリには名前とパスだけを記録します。~/.agentlas とプロジェクトの .agentlas ディレクトリをバックアップしておけば、新しい VPS 上で環境を再構築できます。
接続できるモデルバックエンド
ここで構成全体の見方が変わります。Agentlas はモデル API を直接呼び出しません。呼び出すのはホストのハーネスです。
アーキテクチャ文書では、1 つのコアを各ハーネス向けに変換するランタイムアダプターについて説明しています。また、モデルの認証情報を管理するのはホストのランタイムであるとしています。Agentlas が提供するのは、ハーネスが読み込む 2 つの接続面です。1 つは AgentSkills ファイルで、もう 1 つは stdio 経由で通信する MCP (model context protocol) サーバーです。したがって、「Agentlas はどのモデルをサポートしていますか」という質問は、実際には「使用するハーネスはどのモデルをサポートしていますか」という意味です。答えは、Claude Code、Codex、opencode、goose、または Hermes から到達できるモデルであれば何でもよい、となります。
Codex 形式の TOML 設定で MCP サーバーを登録する例は次のとおりです。
[mcp_servers.hephaestus-network]
command = "~/.agentlas/runtime/current/bin/hephaestus"
args = ["mcp", "serve"]インストール時には、同じサーバーが ~/.cursor/mcp.json、~/.config/goose/config.yaml、その他のハーネス設定にも自動的に登録されます。1 台のホストで複数のサーバーを構成する場合は、VPS で MCP サーバーを実行するで stdio とプロセスモデルについて詳しく説明しています。
ローカルでホストする Ollama エンドポイントを指定する
ハーネスがモデル接続を管理するため、Agentlas からローカルモデルを使用するには、ハーネスが Ollama を使用するように設定します。Ollama はこの用途のために v0.15 で launch サブコマンドを追加しており、2026 年 8 月 11 日時点では v0.32.9 にも引き続き含まれています。環境変数を設定せずに、既存のハーネスをローカルモデル向けに構成できます。
ollama pull qwen3-coder:30b
ollama launch opencodeインストールしたハーネスに応じて、opencode を claude、codex、または droid に置き換えます。次に、リクエストをローカルランタイム経由で送信します。
~/.agentlas/runtime/current/bin/hephaestus route "summarise the failing tests" --runtime ollama正常に処理されると、選択したエージェントまたはチームの名前と receipt_id を含む JSON 形式の判定が返ります。有用な結果が返らない場合、通常の原因はコンテキスト長です。Agentlas のドキュメントでは、ルーティングの多いセッションには少なくとも 64k のコンテキストを持つモデルを推奨しており、例として qwen3-coder、gemma3、deepseek-r1 を挙げています。コーディングツールに関する Ollama 自身の指針でも、最低 64k が推奨されています。ルーティング判定では、プロンプトにエージェント一覧が含まれます。そのため、8k または 32k のコンテキストを持つモデルでは一覧が途中で切り捨てられ、適切に選択できません。
タグラインからは分からない注意点があります。Ollama、Gemma、DeepSeek には、独自のプラグインシステムやコマンドシステムがありません。そのため、/agentlas スラッシュコマンドは使用できません。ローカルモデル構成では、MCP サーバーと hephaestus route コマンドを通じてシステムを操作します。これは利用できる機能の明確な縮小です。一方で、モデルの重みを自分のサーバーに保持するための正直なトレードオフでもあります。
アイドル状態の specialist ハブに必要な RAM
何もありません。これが答えのすべてです。しかも、推測ではなく実際に確認できます。
借用した hub specialist は、プロセスではなくパッケージアーティファクトとして配置されます。specialist は agent.md と、JSON を格納した .agentlas/ ディレクトリで構成されます。routing-card.json にはトリガーと機能、memory-map.json には書き込み可能な範囲、mode-map.json には単独で実行するかチームで実行するかが定義されています。Hephaestus Network は、バックグラウンドサービスを必要としないプロセス内スケジューラーとして説明されています。タスクの実行中でないときは、次のコマンドで確認できます。
pgrep -af hephaestus
systemctl --user list-units --type=service | grep -i agentlas
du -sh ~/.agentlas最初の2つのコマンドは、アイドル状態のホストでは何も出力しません。常駐しているものがないためです。3つ目のコマンドが、待機中の hub によって発生する唯一のコストを表示します。それはディスク容量です。保持する specialist の数と、ランタイムに同梱される埋め込みモデルに応じて増加します。
したがって、メモリ使用量の問題は、完全にバースト時の使用量の問題です。バースト時の使用量は、ハーネスとモデルバックエンドによって決まります。ハーネスがホスト型 API と通信する場合、常駐コストは数百 MB 程度のプロセス1つです。重みを自分でホストする場合は、重みが主なコストになります。
The data behind this chart
[
{
"label": "Hosted API model",
"weights_gb": 0
},
{
"label": "gemma3:4b",
"weights_gb": 3.3
},
{
"label": "gemma3:12b",
"weights_gb": 8.1
},
{
"label": "gemma3:27b",
"weights_gb": 17
},
{
"label": "qwen3-coder:30b",
"weights_gb": 19
}
]これらは Ollama のモデルライブラリが公開しているダウンロードサイズです。ベンチマーク実行時の測定値ではありません。また、64k コンテキスト用の KV キャッシュが、上記の各数値に追加で必要になります。Agentlas のドキュメントで最初に挙げられているモデル qwen3-coder:30b は、コンテキスト分を除いても 19 GB の重みを必要とします。27B の Gemma バリアントでも 17 GB が必要です。これらの数値と比べると、Agentlas レイヤー自体は予算上ほとんど無視できます。
単一の harness の実行との比較
ホスト型 API に対して単一の harness を実行すると、VPS 上では 1 つのプロセスが動作します。Agentlas を追加しても、同じ 1 つのプロセスにファイルが加わるだけです。オーケストレーターは常駐する別のプログラムではありません。ディスク上のパッケージから組み立てた、より大きなプロンプトであり、処理後に破棄されます。
変化するコストはメモリではなくコンテキストです。複数の専門家カードとルーティングメタデータを読み込むオーケストレーターは、単純な harness よりタスクごとに多くのトークンを消費します。ホスト型 API では、これは RAM ではなく料金に直結します。ローカルの重みを使う場合は、プロンプトが長くなることで CPU の prefill に時間がかかるか、GPU の負荷が高くなります。
このため、このようなボックスのサイジング方針は、エージェントフレームワークではなくモデルの選択に基づきます。コーディングエージェント用 VPS の RAM と CPU のサイジングで詳しく説明しています。ここでも結論は同じです。実行する予定のバックエンドに合わせてプランを選び、その上で harness 用に数 GB の余裕を追加します。比較のために常時稼働する supervisor 構成を使う場合は、Omnigent のマルチエージェント harnessで coordinator を常駐させます。これは正反対のトレードオフであり、アイドル時のメモリ使用量に直接現れます。
障害時に表示される症状とメッセージ
クリーンインストール直後に hep-build: command not found になります。 インストーラーは ~/.local/bin に書き込みましたが、デフォルトの Ubuntu イメージでは PATH に含まれていません。インストーラーの最後の行にその旨が表示されましたが、画面を流れて見えなくなっています。上記の export を追加してください。
サーバーを再構築すると動作が変わります。 HEPHAESTUS_REF を設定していないため、インストーラーはその日に最新だったタグを使用しました。タグを固定し、ほかのバージョン番号と一緒にその固定値を記録してください。
ローカルモデルで誤った専門エージェントが選択されます。 モデルのコンテキストウィンドウがエージェントの一覧に対して小さすぎます。64k 以上のモデルに変更し、Ollama のコンテキスト長も同じ値に設定してください。デフォルト値はコーディングツールが必要とする長さより短くなっています。
ollama launch が認識されません。 このサブコマンドは Ollama v0.15 で追加されました。ディストリビューションのリポジトリにある古いパッケージには含まれていないため、現在の Ollama をインストールしてください。
想定していなかった harness にインストール内容が書き込まれます。 スクリプトは検出したすべての harness を設定し、~/.claude/、~/.codex/、~/.gemini/、~/.cursor/ などに書き込みます。共有のビルドサーバーで実行する場合は、事前にスクリプトを読み、対象とするディレクトリを把握してください。
現時点で導入すべきか
1 日に数回の自動リリースを行っている、開始から 10 週間のプロジェクトを本番ワークロードで運用するべきではありません。アーキテクチャは非常に興味深く、ライセンスは Apache-2.0 です。また、ファイルベースの設計のため、アンインストールは 2 つのディレクトリを削除するだけで済みます。これらの点から、試すコストは低い一方で、依存する場合のリスクは高くなります。
現時点では、v1.2.0 に固定し、再構築できるサーバーで実行し、~/.agentlas をバックアップに含めてください。固定するバージョンを変更する前に、変更履歴を再確認してください。この分野にある他の選択肢と、それぞれの成熟度を広く比較する場合は、セルフホスト型 AI エージェントの比較記事から始めるのが適しています。また、VPS で Hermes エージェントをセルフホストする方法では、Agentlas が適応するハーネスの 1 つを扱っています。
FAQ
Agentlas OS は VPS 上でサーバーとして動作しますか？
いいえ。リポジトリにはデーモン、待ち受けポート、コンテナイメージはありません。インストーラーは ~/.agentlas/runtime/ の下にランタイムを、~/.local/bin にコマンドラッパーを書き込みます。Hephaestus Network はバックグラウンドサービスではなく、プロセス内で動作するスケジューラーです。アイドル状態のマシンで確認できます。pgrep -af hephaestus は何も出力せず、有効化する systemd unit もありません。ここでいうセルフホスティングとは、コードと状態が自分のマシン上にあるという意味です。サービスが待ち受けているという意味ではありません。
アイドル状態の specialist で構成した hub は、どの程度の RAM を使用しますか？
使用しません。アイドル状態の specialist はプロセスではないためです。specialist は agent.md ファイルと、routing-card.json、memory-map.json などのメタデータを格納する .agentlas/ ディレクトリで構成されます。そのため、停止状態の hub が消費するのはディスク容量です。du -sh ~/.agentlas で測定できます。メモリを消費するのはタスクの実行中だけです。消費するのは harness プロセスとモデルバックエンドであり、Agentlas 層ではありません。
どのモデルを使用できますか。また、自分の Ollama を指定できますか？
Agentlas 自体はモデル API を呼び出しません。認証情報と接続はホストの harness が管理するため、対応モデルは harness が対応するモデルです。ローカルの重みを使用する場合は、claude、codex、または droid に置き換えて ollama launch opencode を実行します。これにより、環境変数を使わずに harness が Ollama サーバーへ接続するよう設定されます。コンテキスト長が少なくとも 64k のモデルを使用してください。たとえば qwen3-coder や gemma3 です。ルーティング用のプロンプトには agent の一覧が含まれるため、コンテキストウィンドウが小さいと大幅に切り詰められます。
どのバージョンをインストールすべきですか。また、ここでバージョンを固定する理由は何ですか？
12 August 2026 時点のタグ付きリリースである v1.2.0 をインストールします。インストーラーを実行する前に HEPHAESTUS_REF=v1.2.0 を設定してください。スクリプト自体のデフォルトは version="${HEPHAESTUS_REF:-v1.2.0}" です。これはメンテナーが次にタグ付けするバージョンを追跡します。通常よりもバージョン固定が重要です。プロジェクトは 1.1 系列で 100 を超えるリリースを公開しており、日によっては複数のリリースがありました。そのため、数週間後にバージョンを固定せず再ビルドすると、テスト済みのシステムとは異なるものになります。