はじめに
OSSのAIコーディングエージェント「OpenHands」は、GitHub上で 78.9k star を集める人気プロジェクトです（2026年7月時点、公式リポジトリで確認）。Aider・Kilo CLIのような「エディタに寄り添うCLIエージェント」とは違い、OpenHandsはDockerコンテナの中でサンドボックス実行まで面倒を見てくれる「フルスタックな自律エージェント基盤」です。
この記事では、公式ドキュメントに沿ってOpenHandsをセルフホストする手順を確認しつつ、その公式セットアップが要求している権限がどれくらい強いか を実際のコマンドで検証します。「動かしてみた」で終わらせず、これから自宅サーバーやオンプレ環境にOpenHandsを置こうとしている人が事前に知っておくべきリスクを整理するのが狙いです。
この記事で学べること
- OpenHandsの公式セットアップ手順（Docker直接実行 / uv経由のCLI起動）
- なぜセットアップに
/var/run/docker.sockのマウントが含まれているのか - 自宅サーバー・共有環境で動かす際に検討すべき権限分離の考え方
対象読者
- OSSのAIコーディングエージェントをセルフホストしたい方
- Docker Sock を人の設定ファイルでよく見かけるが、意味を深く考えたことがない方
前提環境
- Docker Engine（Docker Desktop または Docker Engine + Compose v2）
- Linux / macOS（Windowsも公式にサポート対象）
TL;DR
- OpenHandsは MIT ライセンス（
enterprise/配下のみ別ライセンス）で、SWE-Bench Verifiedで 72.8%（Claude Sonnet 4.5使用）を記録している実力派エージェントです（OpenHands Software Agent SDK論文）。 - 公式のDocker起動コマンドは
-v /var/run/docker.sock:/var/run/docker.sockを含み、ホストのDockerデーモンをそのままエージェントコンテナに渡す 構成になっています。 - これは「エージェントがタスクごとに使い捨てサンドボックスを生成する」ための設計ですが、裏を返すと エージェントを乗っ取られた場合、ホスト全体への到達性を持つ ことも意味します。個人の検証用マシンならまだしも、共有サーバーに気軽に置くのは避けたほうがよい設定です。
OpenHandsとは何か
OpenHands（旧OpenDevin）はAI駆動の自律ソフトウェア開発エージェントで、MITライセンスで公開されています（LICENSEファイルで確認。enterprise/ ディレクトリ配下のみ別ライセンス）。Claude・GPT・Geminiなど任意のLLM APIキーを持ち込んで利用でき（BYOK）、ローカルLLM（Ollama等）とも接続できます。
2025年11月公開のOpenHands Software Agent SDK論文によれば、SWE-Bench Verified（実際のGitHub Issueをどれだけ解決できるかを測るベンチマーク）で以下のスコアを記録しています。
| モデル | SWE-Bench Verified |
|---|---|
| Claude Sonnet 4.5 | 72.8% |
| GPT-5（reasoning=high） | 68.8% |
| Claude Sonnet 4 | 68.0% |
| Qwen3 Coder 480B A35B | 65.2% |
出典: OpenHands Software Agent SDK（arXiv:2511.03690v1）
セットアップしてみる
方法1: Docker直接実行
公式ドキュメントに記載されているコマンドはこちらです。
docker run -it --rm --pull=always \
-e AGENT_SERVER_IMAGE_REPOSITORY=ghcr.io/openhands/agent-server \
-e AGENT_SERVER_IMAGE_TAG=1.26.0-python \
-e LOG_ALL_EVENTS=true \
-v /var/run/docker.sock:/var/run/docker.sock \
-v ~/.openhands:/.openhands \
-p 3000:3000 \
--add-host host.docker.internal:host-gateway \
--name openhands-app \
docker.openhands.dev/openhands/openhands:1.8
起動後は http://localhost:3000 にアクセスし、LLMプロバイダー・モデル・APIキーを設定する画面が表示されます。
方法2: uv経由のCLI起動
Docker Desktop不要でCLIから起動したい場合は、uv（Pythonパッケージマネージャ）経由でインストールできます。
uv tool install openhands --python 3.12
openhands serve # 通常起動
openhands serve --mount-cwd # カレントディレクトリをマウントして起動
どちらの方式でも、システム要件としてDocker（Docker Desktop）が前提になっている点は変わりません。
導入時に検討したいこと
- 個人の検証用マシン・使い捨てVM であれば、公式手順どおりで問題になりにくいでしょう。
-
共有サーバー・本番に近い環境 に置く場合は、以下を検討する価値があります。
- OpenHands専用のDockerホスト（他のワークロードと分離した実行環境）を用意する
-
docker.sockを直接渡す代わりに、Docker socket proxy（アクセス可能なAPIを制限するプロキシ）を経由させる - LLM APIキーやプロジェクトのシークレットは、OpenHandsが動くホストとは別で管理する
公式ドキュメント自体もDocker Desktopのサポートを前提にしているため、この構成を変えるには自分でネットワーク・マウント設定をカスタマイズする必要があります。導入前にリスクを把握したうえで、自分の環境に合った権限分離を選ぶのがよいでしょう。
著者視点の発見ポイント
実際にコマンドを1行ずつ読み解いていくと、Docker直接実行の手順に含まれる次の1行が気になりました。
-v /var/run/docker.sock:/var/run/docker.sock
これは「ホストマシンのDockerデーモンのソケットを、そのままコンテナ内にマウントする」という設定です。OpenHandsはこの経路を使って、タスクごとに使い捨てのサンドボックスコンテナ（コード実行環境）をホスト上に生成しています。エージェント本体のコンテナ自体はrootlessでも、docker.sockを持っている時点で実質的にホストのDockerを操作できる＝ホスト上で任意のコンテナを起動できる ことになります（これは "Docker outside of Docker" と呼ばれる一般的なパターンで、CI/CDのDockerビルドエージェントなどでもよく使われる構成です）。
通常のCI環境であれば、実行されるジョブは信頼されたリポジトリのコードに限られます。しかしAIエージェントの場合、入力に含まれる指示（プロンプトインジェクションを含む）に応じて、エージェント自身が予期しないコマンドを組み立てて実行する可能性がある 点が異なります。docker.sockへのアクセスを持つエージェントが不正な指示に従ってしまった場合、単なるサンドボックス内実行にとどまらず、ホスト上の他のコンテナやボリュームにまで影響が及ぶ余地が生まれます。
これは「OpenHandsが危険」という話ではなく、便利なセルフホスト系AIエージェントほど、裏側でホストへの強い権限を要求しがち という一般的な傾向として捉えるべきポイントです。実際、本サイトで先日扱ったCVE-2026-2256（AIエージェントのシェル実行を拒否リストだけで守ろうとして破られた事例）とも根は同じで、「エージェントに何をどこまで触らせるか」という設計判断が問われています。
まとめ
- OpenHandsはSWE-Bench Verified 72.8%（Claude Sonnet 4.5）を記録するMITライセンスの自律コーディングエージェントで、Docker直接実行 or
uv tool install openhandsの2通りで手軽にセルフホストできる - ただし公式のDocker起動コマンドは
docker.sockをコンテナにそのまま渡す構成になっており、これはエージェントにホストDockerの操作権限を与えることを意味する - 個人の検証用途を超えて共有環境に置くなら、専用ホストの分離やsocket proxyの導入を検討したほうがよい
参考リンク
- OpenHands 公式リポジトリ — スター数・ライセンスの確認
- OpenHands ローカルセットアップ手順 — Docker実行コマンドの引用元
- OpenHands Software Agent SDK（arXiv:2511.03690v1） — SWE-Bench Verifiedスコアの出典