OpenHands Agent Canvasを自分の開発環境に置く判断
コーディングエージェント向けのセルフホスト型コントロールセンター。Claude Code、Codex、ACP互換エージェントをローカル・リモート・クラウドの各バックエンドで実行。
ひと目でわかる
- これは何？
- OpenHands Agent Canvasが提供するエージェント接続、実行場所、外部サービス連携をREADMEの記載から整理します。
- 誰に向いている？
- ローカル、Docker、VM、クラウドを使い分けながら開発エージェントを常時動かしたいチームに候補になります。導入前にNode.js 22.12以降、uv、Docker利用時のPROJECTS_PATH、エージェントのファイル権限を確認し、localhost:8000で隔離したプロジェクトを実際に開けるかを先に試してください。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
Agent Canvasが解決する範囲
OpenHandsのREADMEはAgent Canvasを、コーディングエージェントと自動化を扱うセルフホスト型の開発者向けコントロールセンターとして説明しています。OpenHands本体を標準で動かせるほか、Claude Code、Codex、Gemini、Agent-Client Protocolに対応するエージェントを利用できる、と記載されています。ここでの価値は単一のチャット画面ではなく、実行バックエンドを選び直せる管理面にあります。
想定される利用場面は、日常の修正作業、GitHub issueの分解、Slackへ送るレポートの生成です。READMEが挙げる機能はプロジェクトの設計意図を示しますが、各エージェントの品質や処理時間を保証するものではありません。採用判断では、担当するリポジトリと自動化の失敗時に誰が止めるかを分けて考える必要があります。
バックエンドを切り替える設計
エージェントは手元のマシンだけでなく、Dockerコンテナ、VM、社内インフラ、OpenHands CloudやEnterpriseの環境にも接続できます。複数の場所を同じフロントエンドから選ぶ構成なので、ノートPCを閉じても継続させたい処理と、手元で対話しながら進めたい処理を区別できます。
一方で、接続先が増えるほど認証、ネットワーク、作業ディレクトリの境界が運用課題になります。READMEにはセキュリティ強化のためSELF_HOSTING文書を参照するよう案内があります。導入時は、どのバックエンドがどのリポジトリを見られるか、実行ログがどこに残るかを構成図と実測結果で記録してください。
自動化と連携の置き場所
Agent Canvasの自動化はSlack、GitHub、Linear、Notion、Datadogなどとのワークフローを想定し、スケジュールまたはWebhookイベントを起点に実行できます。コードレビューや依存関係更新のような定型作業では、入力イベント、エージェントが変更できる範囲、出力先を一つの流れとして定義できる点が使いどころです。
連携先を増やすこと自体が運用品質を上げるわけではありません。最初の検証ではテスト用issueを作り、生成されたタスク、Slack通知、失敗時の再実行条件を確認します。書き込み権限を与える前に読み取り専用で動かし、Webhookの重複や同じissueへの再処理も観察対象に含めるべきです。
3つの起動方法と境界
READMEのQuickstartには、サンドボックスなしでnpmから起動する方法、Dockerサンドボックスを使う方法、ソースから動かす方法があります。npm版はNode.js 22.12.x以降とuvが前提で、`npm install -g @openhands/agent-canvas`の後に`agent-canvas`を実行します。フロントエンドだけ、バックエンドだけに分ける起動も記載されています。
Docker版では`PROJECTS_PATH`を作成し、`$HOME/.openhands`とプロジェクト領域をコンテナへマウントしてポート8000を公開します。READMEはサンドボックスなしの場合、エージェントがインストール先のファイルシステムへ完全アクセスすると警告しています。初回は不要な秘密情報がない検証用ディレクトリで、マウント範囲と変更ファイルを確認してください。
実務で先に測る項目
ブラウザの入口はnpm版とソース版が`http://localhost:8000`、Docker版は`http://localhost:8000/canvas`です。初回テストでは、指定したバックエンドが画面に現れるか、会話から対象プロジェクトを選べるか、エージェントが作成した差分を追跡できるかを順に見ます。READMEに書かれていないモデル別の性能や同時実行数は未確認として扱います。
検証コマンドは起動ログ、利用したイメージ版、Node.jsとuvの版を保存できる形にします。Dockerであれば`docker run`のマウント指定を見直し、終了後にホスト側へ何が残ったかを比較します。CloudやEnterpriseを選ぶ場合も、セルフホスト版と同じ権限や保存場所だと仮定せず、公式文書の該当説明を別途確認します。
採用を決める条件
READMEとメタデータからは、MITライセンス、mainブランチ、2026年8月27日の更新、85,445 stars、11,175 forks、602件のopen issuesが確認できます。starsは利用規模の参考にはなりますが、保守体制や安全性の証明ではありません。ライセンスの実ファイル、依存関係、利用する第三者エージェントの条件は導入対象として個別に確認します。
向いているのは、複数のエージェント実行場所を試し、ワークフローをGitHubやSlackのイベントに結び付けたい開発チームです。単一PCで限定的な補完だけを求める場合は構成が大きくなる可能性があります。まずDockerで一つのテストリポジトリを扱い、権限、差分、通知、停止手順の4点を確認できた時点で本番範囲を決めるのが妥当です。
追加の確認として、同じissueをローカルバックエンドとDockerバックエンドで処理し、作業ディレクトリの差分、実行ログ、通知結果を並べます。バックエンドを変えても人間の承認箇所が失われないことを確かめ、設定を戻してエージェントを停止できることまで確認します。
編集部の結論
ローカル、Docker、VM、クラウドを使い分けながら開発エージェントを常時動かしたいチームに候補になります。導入前にNode.js 22.12以降、uv、Docker利用時のPROJECTS_PATH、エージェントのファイル権限を確認し、localhost:8000で隔離したプロジェクトを実際に開けるかを先に試してください。
コミュニティノート