OpenAgents Workspace 評価：複数マシンのコーディングエージェントを1つのURLに集める

「エージェントが散らばっている」問題を何で解こうとしているか

README が挙げる状況は具体的である。データベースを保守するエージェントはサーバー上に、マーケティングと Discord 対応のエージェントは別の場所に、コーディング中のエージェントは複数の端末に、それぞれ存在する。ユーザーからバグ報告が来たとき、その詳細を集めるのはマーケティングボット、ログを調べるのはインフラ担当エージェント、という連携をしたければ、現状は端末間のコピーと SSH でつなぐしかない。OpenAgents はここを2つの仕組みで置き換えると説明している。1つは全エージェントが同じ URL に現れる統一ワークスペース、もう1つはスレッド単位でエージェントを引き込み、ファイルとブラウザとコンテキストを共有させる協調の仕組みである。対象読者は、単一のエージェントを試す段階を終え、複数エージェントの運用に移った個人開発者か小規模チームだと考えられる。

Launcher とワークスペースという2層のアーキテクチャ

リポジトリの構成は、性格の異なる2つのコンポーネントに分かれている。1つは npm の @openagents-org/agent-launcher として配布される Launcher で、agn コマンドと TUI ダッシュボードを提供する。もう1つは workspace.openagents.org/abc123 のような URL で識別されるワークスペースで、README はこれを「Slack のようなもの、ただしエージェント用」と表現している。Launcher 側はローカルのランタイム導入、API キーの設定、ワークスペースへの接続、デーモンとしての常駐を担当する。ワークスペース側はスレッド、共有ファイル、共有ブラウザ、トンネルを提供する。つまりエージェントのプロセス自体は手元のマシンで動き続け、ワークスペースはそれらをつなぐハブとして機能する。README のアーキテクチャ図がこの分離を示しているが、ワークスペース側のサーバー実装やデータ保持の詳細は与えられた資料からは読み取れない。

agn create は設定を書くだけで、ランタイムは入らない

導入は install スクリプトから始まる。macOS と Linux は curl -fsSL https://openagents.org/install.sh | bash、Windows は irm https://openagents.org/install.ps1 | iex である。デスクトップアプリ版も macOS、Windows、Linux AppImage 向けにダウンロードリンクが用意されている。CLI の流れは次のとおり。

agn create <name> --type <type> --install agn connect <name> <workspace-token> agn env <type> --set LLM_API_KEY=sk-... agn up

ここで見落としやすいのが、README が明示している仕様である。agn create はエージェントの設定ファイルを書くだけで、ランタイムの導入は行わない。先に agn install <type> を実行するか、作成と同時に導入したい場合は --install を付ける必要がある。agn env はタイプ単位で資格情報を設定し、agn up でデーモンとして起動する。引数なしの agn はダッシュボードを開く。接続には workspace-token を渡す形式なので、ワークスペース側でトークンを発行する手順が前提になる。

対応エージェントの Supported、Beta、Preview という区別

README の対応表は、単純な「対応済み」の一覧ではない。OpenClaw、Claude Code、Codex CLI、Hermes Agent、Cursor、OpenCode、GitHub Copilot CLI、Gemini CLI、Amp が Supported として並ぶ。Cline は Supported (Beta)、DeepSeek Harness は Preview で dsh のヘッドレスモードに限定され、プレビュー版リリースに固定されていると書かれている。Aider は Beta で、README の注記によればプロバイダ解決、セッション、Git 安全性、インストール検出を含むオフラインのテストスイートは通っているが、実際のモデルプロバイダに対するエンドツーエンドの実行はまだ完了していない。Goose も Beta 扱いで CLI とヘッドレスに限られる。この区分は導入判断に直結する。Aider や Goose を本番のワークフローに組み込むなら、README が想定しているとおり利用者自身が検証を引き受けることになる。

共有ブラウザとトンネルが効く場面、効かない場面

ワークスペース内のエージェントは同じスレッド、同じファイル、同じブラウザを共有する。共有ブラウザはページを開き、要素をクリックし、スクリーンショットを撮り、フォームに入力できると説明されている。トンネルはローカルの開発サーバーを1コマンドで公開 URL に変換し、エージェントが作ったものを別の端末から確認できるようにする。@mentions でタスクを振ることも、エージェントが自発的に仕事を拾うこともできるとされている。ただし、この設計は「同じワークスペースに入れたエージェント同士」でしか成立しない。ワークスペースに接続していないエージェントや、そもそも Launcher が対応していない独自エージェントは、この共有の恩恵を受けられない。対応表に載っていないランタイムを使っているなら、OpenAgents は解決策ではなく追加の層になる。

代替手段との違い：手動オーケストレーションか、汎用ワークフロー基盤か

比較対象として素直なのは、tmux や複数ターミナルを人間が切り替えながら運用する現状のやり方である。この場合、コンテキストの受け渡しはコピー＆ペーストと SSH であり、エージェントは互いの存在を知らない。OpenAgents はここに共有スレッドと共有ファイルという中間状態を挟む点が異なる。もう1つの方向は、LangGraph や Temporal のようなワークフロー基盤でエージェント間の連携をコードとして記述するやり方だ。こちらは処理の順序と失敗時の再試行を明示的に設計できる代わりに、エージェントを追加するたびにグルーコードを書く必要がある。README が「グルーコード不要」と述べているのは、まさにこの後者への対比である。ただし OpenAgents は会話と共有状態の場を提供するもので、決定論的なパイプラインの保証を提供するわけではない。監査可能な実行順序が必要な用途では、ワークフロー基盤のほうが適している。

ライセンスとメンテナンスの見え方

ライセンスは Apache-2.0 で、README はベンダーロックインなし、アカウント必須ではないと述べている。ワークスペース作成用のリンクはアカウント登録なしで開ける形式になっている。ただしワークスペースが workspace.openagents.org 上のホスト型である以上、URL の可用性とデータの置き場所はホスト側の運用に依存する。Apache-2.0 はコードの利用条件を定めるもので、ホスト型サービスの継続やデータ管理を保証するものではない。この区別は導入前に自組織の基準で確認する必要があり、ここで法的な助言はできない。メンテナンス面では、launcher-v0.9.27 が 2026-09-06、v0.9.26 と v0.9.25 が 2026-08-31 にリリースされており、Launcher は短い間隔で更新されている。デフォルトブランチが develop である点も含め、追従する側は更新頻度を前提にバージョンを固定する運用を考えたほうがよい。

編集部の結論

導入を検討すべきなのは、複数のマシンや端末で Claude Code、Codex CLI、Cursor などをすでに走らせており、その間のコンテキスト受け渡しを手作業のコピーで埋めている開発者である。逆に、エージェントが1つしかない場合や、社内ネットワークから外部 URL への常時接続を許可できない環境では、agn の導入コストに見合わない。最初に確認すべきは、agn create が設定を書くだけでランタイムは入らないという点で、agn install <type> を先に実行するか --install を付ける必要があること、そして使いたいエージェントが Supported か Beta か Preview のどれに分類されているかである。Aider は README 上も Beta と明記され、実プロバイダに対する E2E が未完了とされているので、そこを自作の検証で埋められないなら手を出さないほうがよい。

公式情報源

1. License: Apache-2.0
2. openagents-org/openagents on GitHub
3. Project website
4. README
5. Releases