Agentlas OS: 常駐スペシャリストと使い捨てオーケストレータという設計

エージェントを「プログラム」ではなく「資産」として扱うという主張

README の中心にあるのは、エージェントをモデルやマシンに紐づいた一時的な設定ではなく、持ち運べる資産として扱うという立場だ。キャッチコピーとして「We are Agent Trust. Your agent is not a program. It is an asset.」を掲げ、作成したエージェントは特定のモデルワークスペースやコンピュータに縛られず、別のマシンで Agentlas OS を入れてサインインすれば Agent Cloud から取り戻せる、と説明している。

この主張が効いてくるのは、同じ業務エージェントを Claude Code でも Codex でも使いたい、あるいはノート PC とデスクトップの両方で同じ振る舞いをさせたいという場面である。ホスト側の設定ディレクトリにエージェント定義を直接書き込む運用では、ホストを乗り換えるたびに定義を作り直すことになる。Agentlas OS はその定義をホストの外側、すなわち ~/.agentlas と Agent Cloud に置く。対象読者は、複数の LLM ホストを併用していて、その間でエージェントの定義が散らばることに手間を感じている開発者だ。

ハブに常駐させ、タスクごとにオーケストレータを立てる

リポジトリの説明文は「keep specialist agents in a hub, spin up a temporary orchestrator per task」という構成を明示している。専門エージェントはハブ側に常駐させ、タスクが発生したときだけ一時的なオーケストレータを起動して、そのタスクの間だけ専門エージェント群を束ねる。タスクが終わればオーケストレータは破棄される。

常駐する側と使い捨てる側を分ける利点は、専門エージェントの定義と検証済みの状態を再利用しつつ、タスクごとの編成を毎回作り直せる点にある。トピックに ochestration (原文の綴り) や multi-agent-systems、a2a、mcp が並んでいることから、エージェント間の連携とツール接続を想定した構成だと読み取れる。ただし、オーケストレータがどう専門エージェントを選び、失敗時にどう再編成するのかという内部ロジックは、与えられた README の範囲では確認できない。ここは採用判断の前にリポジトリ本体を読む必要がある部分だ。

既存の LLM ホストに相乗りするインストール経路

配布形態はデスクトップアプリと、既存ホストへコマンド面を追加するインストーラの二本立てである。README が最初に示すのは後者で、いま使っている LLM にそのまま貼り付けるためのプロンプトを載せている。プロンプトは、実行前にインストーラ本体を取得して読ませ、書き込み先が ~/.agentlas、~/.local/bin、および各ホストのプラグイン/コマンドアダプタディレクトリ (例: Claude Code なら ~/.claude) に限られることを確認させてから実行させる、という手順になっている。

シェルから直接叩く場合のコマンドは次のとおり。

curl -fsSL https://raw.githubusercontent.com/agentlas-ai/Agentlas-OS/main/scripts/install-all-runtimes.sh | HEPHAESTUS_INSTALL_GLOBAL_ROUTER=1 bash

環境変数 HEPHAESTUS_INSTALL_GLOBAL_ROUTER=1 を付けると、ホストのグローバル指示ファイル (例: ~/.claude/CLAUDE.md) にルーティングブロックが追記され、規模の大きいタスクを Agentlas のエージェント網から人員配置できるようになる。README はこのブロックについて「not secret and you can read/quote it back to me」と述べており、秘密情報ではないと明言している。付けたくない場合は環境変数を外し、後から hephaestus global install で追加できる。

インストール後はホスト側の再起動かプラグインの再読み込みが必要になる可能性があり、README もインストーラの検証出力を確認したうえで /agentlas build が使える状態かを判断するよう促している。

グローバル指示ファイルへの追記をどう扱うか

このインストーラで最も判断を要するのは、HEPHAESTUS_INSTALL_GLOBAL_ROUTER=1 によるグローバル指示ファイルへの書き込みである。~/.claude/CLAUDE.md のようなファイルは、そのホストにおけるすべてのセッションの振る舞いに影響する。追記されるのはルーティングのためのブロックであり、README はそれを読んで引用できると説明しているが、チームで共有している指示ファイルに自動で行が足される運用を許容できるかは別の話だ。

README が用意している逃げ道は明確で、環境変数を付けずにインストールし、必要になった時点で hephaestus global install を実行する。この順序なら、ルーティングブロックの中身を先に確認してから導入を決められる。パイプでシェルに流す形式のインストーラは一般に敬遠されやすいが、この README はスクリプトの URL を先に開いて読むことを推奨しており、その姿勢自体は妥当だ。とはいえ、書き込み先の一覧はあくまで README の記述であって、実際の挙動を保証するものではない。実行前に scripts/install-all-runtimes.sh を自分で読む作業は省かないほうがよい。

モデル非依存と Agent Cloud 依存は別の話である

バッジには Claude Code、Codex、Gemini、Antigravity、Cursor、DeepSeek、GLM、Ollama が並び、特定のモデル提供者に固定されないことを売りにしている。ローカル優先 (local-first) という説明もあり、Ollama が選択肢に入っている点はその表れだ。

ただし、モデル非依存であることと、Agent Cloud に依存しないことは別である。README は、作成したエージェントを別のマシンで取り戻すために Agentlas OS のインストールとサインインが必要だと明記している。つまりエージェントの持ち回りという中心的な価値は、Agent Cloud という所有者スコープのクラウド領域に乗っている。完全にオフラインで完結させたい場合、この機能は使えない。ローカル優先という言葉がどこまでを指すのか、クラウド側に何が保存されるのかは、README の記述だけでは判別できない。ここは採用前に自分で確認すべき境界である。

既存のエージェント定義管理との違い

比較対象として分かりやすいのは、エージェント定義をリポジトリ内のファイルとして置き、Git でレビューする運用だ。この方式では、エージェントの変更が差分として残り、誰がいつ何を変えたかが追える。モデルやマシンに依存しないという点でも、ファイルをリポジトリごと複製すれば済む。

Agentlas OS のアプローチはこれと逆で、定義をホストの外のハブと Agent Cloud に集約し、タスクごとに一時的なオーケストレータを生成する。得られるのは、ホストをまたいだ同一性と、タスクごとの編成の作り直しやすさだ。失うのは、定義そのものを差分レビューの対象にしやすさである。エージェントの変更をプルリクエストで承認する統制を重視するチームにとっては、クラウド側に定義が置かれる構成は受け入れにくい可能性がある。逆に、個人や小規模チームで、複数ホストを行き来しながら同じエージェントを使いたい場合には、この集約は手間を減らす方向に働く。どちらが優れているという話ではなく、定義をコードとして扱うか資産として扱うかの選択だ。

リリース間隔とライセンスが示す運用コスト

直近のリリースは v1.2.42 が 2026-09-05、v1.2.43 が 2026-09-06、v1.2.44 が同日 03:21 と、2 日足らずで 3 版が出ている。活発である一方、この間隔は更新の追従コストを見積もる材料になる。インストーラがホストのグローバル指示ファイルやプラグインディレクトリに書き込む設計である以上、更新のたびにそれらの領域が書き換わる可能性を想定しておきたい。バージョンを固定して運用するのか、都度追従するのかを先に決めておかないと、ホスト側の設定が知らないうちに変わる事態になり得る。

ライセンスは Apache-2.0 で、リポジトリの LICENSE ファイルとバッジの両方に記載がある。商用利用や改変を含む許容的な条件だが、特許に関する条項や再配布時の表示義務など、具体的な条件は LICENSE 本文を自分で確認する必要がある。ここで法的な助言はできない。ホームページは agentlas.cloud、デスクトップ版の配布も同ドメインで行われており、オープンソース部分とホスト型サービスの境界は、コードを読むまで確定しない。

編集部の結論

既存の LLM ホスト (Claude Code、Codex、Cursor など) をすでに使い、そこで動かすエージェントをモデルやマシンから切り離して持ち回りたい開発者に向く。逆に、エージェント定義をリポジトリ内のテキストとして Git 管理したい場合や、Agent Cloud へのサインインを避けたい閉域環境には向かない。導入前に確認すべきは 3 点で、第一に scripts/install-all-runtimes.sh が実際に書き込むパスが ~/.agentlas、~/.local/bin、および各ホストのプラグイン/コマンドアダプタディレクトリに収まっていること、第二に HEPHAESTUS_INSTALL_GLOBAL_ROUTER=1 を付けた場合に ~/.claude/CLAUDE.md などグローバル指示ファイルへ追記されるルーティングブロックの文面、第三に v1.2.42 から v1.2.44 まで 2 日足らずで 3 版が出ているリリース間隔が自分の更新運用に耐えるかどうかである。ルーティングブロックの内容に納得できない場合は環境変数を外し、後から hephaestus global install で追加する経路を選べる。

公式情報源

1. agentlas-ai/Agentlas-OS on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases