OpenHandsとは？使い方とAgent Canvas移行を解説｜OSS自律コーディングエージェント2026

OpenHandsは、タスクを渡すと自分でコードを書き・コマンドを実行し・テストまで回すOSS（MITライセンス）の自律コーディングエージェントだ。商用のDevinとは逆に「中身を全部見せて、自分のサーバーで動かせる」立ち位置で、GitHubスターは82,000を超える。2026年6月には入り口を Agent Canvas へ切り替える方針を公表した。本記事は2026年7月27日時点の一次情報で、導入から本番運用までと、いま新しく触る人がどのルートを選ぶべきかを整理する。

AIコーディング全体の始め方とツールの地図は Vibe Codingとは？AIコーディングの始め方・ツール比較・実践ワークフロー2026 にまとめてある。本記事はその中の、自前で動かす自律エージェントの枝にあたる。

OpenHandsとは（前OpenDevin、SWE-Bench高スコアで話題）

OpenHandsは、自然言語でタスクを渡すと、人間のエンジニアのようにコードを読み書きし、ターミナルでコマンドを叩き、必要ならブラウザで調べながら目的を達成しようとするAIソフトウェアエンジニアだ。1行の補完ではなく、「Issueを解決して」「このバグを直して」といったタスク単位の依頼を丸ごと引き受ける。

2024年に「OpenDevin」という名前で始まり、商標上の配慮から「OpenHands」へ改称された。GitHubの組織名も All-Hands-AI から OpenHands へ移っている（旧URLはリダイレクトされる）。「OpenDevin 使い方」で探している人も、行き着く先はこのOpenHandsだ。話題になった理由は、実リポジトリのIssueを自力で直せるかを測る SWE-Bench Verified で70%超を出し、クローズドな商用エージェントと遜色ない水準をOSSで達成したことにある。

仕組み — Agent・Runtime・ツールのループ

OpenHandsはエージェント本体（頭脳）と、それが操作する実行環境（手足）を分けた設計だ。中核の CodeActAgent は「エージェントの行動をすべて実行可能なコードとして表す」考え方で、ファイル編集もコマンド実行もブラウザ操作も一貫したアクション空間で扱う。手を動かす先はDockerで隔離された Runtime（サンドボックス） で、Bash（シェル実行）・Editor（ファイル編集）・Browser（Web閲覧）がぶら下がる。ホストOSと切り離されているので、エージェントが暴走してもホストを直接壊すリスクを抑えられる。

テストの成否やコマンド出力を観測して次の判断材料にする。人間の試行錯誤と同じサイクルを自動化していると考えるとわかりやすい。

Agent Canvasへの移行とメンテナンスモード（2026年7月時点）

いま調べる人が最初に知るべきなのは、2026年6月に入り口そのものが切り替わったことだ。古い記事の手順をなぞると、メンテナンスモード入りが決まったコンポーネントを本番に組み込んでしまう。公式が2026年6月16日に公開した「Agent Canvas transition FAQ」（Issue #14841、文書の日付は6月3日）の方針は次のとおり。

・Agent Canvas が長期的な主系統——2026年6月3日にコミュニティ向けBETAとして公開。READMEのQuickstartも npm install -g @openhands/agent-canvas / docker run ghcr.io/openhands/agent-canvas を案内する形に変わった
・CLIのTUIはメンテナンスモード——「最低3か月間、2026年10月1日まで」維持。headlessモードとACPモードは無期限でフルサポート
・Local GUIもメンテナンスモード——「Agent Canvasが隔離された使い捨てサンドボックスに対応するまで」維持。期限は切られていない
・メンテナンスモードの中身——依存関係の更新・重大バグ修正・新しいLLMへの対応は入るが、新機能と軽微な更新は入らない
・コードは3つのリポジトリへ分割——エージェント本体とAgent Serverは OpenHands/software-agent-sdk（MIT・約932スター）、Agent Canvasは OpenHands/agent-canvas（MIT・約225スター）、自動化サーバーは OpenHands/automation

選び方は冒頭の図のとおり。これから長く使うなら Agent Canvas、CIやスクリプトに組み込むなら headless / ACP モード、使い捨てサンドボックスが要件なら当面 Local GUI、対話的なTUIに依存しているなら2026年10月1日を目安に移行計画を立てる。公式FAQによれば、Agent Canvasは ~/.openhands から既存の設定と会話履歴のほとんどを引き継ぐ。並行で立ち上げて引き継ぎを確かめてから旧環境を落とすのが安全だ。

# Agent Canvas をインストールして起動（Node.js 22.12.x 以降と uv が必要）
npm install -g @openhands/agent-canvas
agent-canvas

# フロントエンドとバックエンドを分けて起動することもできる
agent-canvas --frontend-only   # 静的フロントエンド + ingress のみ
agent-canvas --backend-only    # agent server + automation backend + ingress のみ

起動後は http://localhost:8000 でUIを開く（Local GUIの3000番とは別ポートなので併用できる）。バックエンドはUIから追加でき、ローカル・リモート・クラウドを同じ画面で切り替えられる。以降で解説するCLI・Local GUIの手順は2026年7月時点でそのまま動作するが、新機能は入らない。

ACPでClaude Code・Codex・Geminiを動かす

Agent Canvasの公式説明は「OpenHands、Claude Code、Codex、Gemini、あるいは任意のACP互換エージェントを、ローカル・リモート・クラウドのバックエンドをまたいで動かす」と明記している。ACP（Agent-Client Protocol）はエージェントとクライアントのやり取りを標準化するプロトコルで、ACPを話せるエージェントは差し替え可能な部品になる。「OpenHandsかClaude Codeか」の二者択一ではなく、同じ管理画面から両方を使い分ける構成が取れる。Claude Codeは常駐サーバー上で走らせればノートPCを閉じても継続でき、CodexはOpenAI系モデル、Geminiはコスト効率重視の構成に向く。OpenHands本体（CodeActスキャフォールド）は標準で同梱される。

旧CLIの側でもACPモードは無期限フルサポートなので、IDEからOpenHandsをACPで呼ぶ使い方はTUIのメンテナンスモード入り後も使い続けられる。CIやIDE統合はTUIではなく headless / ACP を前提に設計しておく。

導入手順（CLI / Docker / Cloud）

どのルートでもエージェント本体の挙動は同じだ。挙動を見たいだけなら、app.all-hands.dev にGitHubまたはGitLabアカウントでサインインするのが最短で、Dockerもインストールも要らない。無料クレジットの範囲で、Issueを指定してPRまで作らせる流れを試せる。

CLI（ターミナルで使う）

uv（Pythonの高速パッケージマネージャ）で入れるのが推奨ルートだ。インストールスクリプトでネイティブバイナリも入れられる。

# uv でCLIをインストール（Python 3.12を指定）
uv tool install openhands --python 3.12

# 起動（初回はLLMの設定ウィザードが立ち上がる）
openhands

# もしくはインストールスクリプトで入れる
curl -fsSL https://install.openhands.dev/install.sh | sh

初回起動時にLLMプロバイダ・モデル・APIキーを対話形式で設定する。設定は ~/.openhands/settings.json に保存される。

Docker（Local GUIで使う）

CLIを入れているなら openhands serve で、裏でDockerイメージをpullしてGUIサーバーが立つ。ブラウザで http://localhost:3000 を開く。データは ~/.openhands に保存され、必要なディスクは概ね2GB程度だ。Dockerを直接叩くなら次の形になる（バージョンタグは利用時点の最新を公式リポジトリで確かめる）。

docker run -it --rm --pull=always \
  -e SANDBOX_RUNTIME_CONTAINER_IMAGE=docker.all-hands.dev/all-hands-ai/runtime:latest \
  -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.all-hands.dev/all-hands-ai/openhands:latest

-v /var/run/docker.sock:/var/run/docker.sock は、OpenHandsがサンドボックス用のコンテナをホストのDockerで起動するために要る。忘れるとランタイムが立ち上がらない。

Windowsでの使い方（Docker Desktop / PowerShell / WSL2）

サンドボックスがDockerに依存するので、Docker Desktop for Windowsが実質的な前提になる。Agent Canvasには README.windows.md というWindows専用のQuickstartがある。

# PowerShell / Windows Terminal で実行
$env:PROJECTS_PATH = Join-Path $HOME "projects"
New-Item -ItemType Directory -Force -Path $env:PROJECTS_PATH, (Join-Path $env:USERPROFILE ".openhands") | Out-Null

docker run -it --rm `
  -p 8000:8000 `
  -v "$($env:USERPROFILE)\.openhands:/home/openhands/.openhands" `
  -v "$($env:PROJECTS_PATH):/projects" `
  ghcr.io/openhands/agent-canvas:1

起動したら http://localhost:8000/canvas を開く。エージェントが触れるのは PROJECTS_PATH 配下だけなので、触らせたくないディレクトリを含めない。

旧来のCLI・Local GUIは、WSL2上でLinuxと同じ手順を踏むのが公式の推奨に沿った構成だ。

タスクの渡し方とモデル設定

使い方の基本は「タスクを書いて渡す→行動を観察する→必要なら介入する」のサイクルだ。対象ファイル・やること・完了条件を明示するほど精度が上がる。

tests/test_parser.py が失敗しています。
pytest tests/test_parser.py を実行して原因を特定し、
src/parser.py を修正して全テストを通してください。
修正後に差分を要約してください。

エージェントはテストを実行して失敗内容を読み、原因箇所を直し、緑になるまでループして差分の要約を返す。GUIでは「何を考え」「どのコマンドを実行し」「何を観測したか」が一手ずつ表示されるので、意図しない方向に進んだら途中で止めて指示を上書きできる。

性能は接続するLLMでほぼ決まる。公式のOpenHands Index（独自の総合評価）による2026年6月時点の目安は次のとおり。

GUIのSettings画面かCLIの初回ウィザードで「Provider / Model / API Key」を指定する。Base URLやAPIバージョンは config.toml か環境変数で渡せる。計画・デバッグ・レビューは強いモデル、ルーチンな編集は安いモデルと使い分けるとコストを抑えられる。

SWE-Bench スコアで見るOpenHandsの実力

SWE-Bench Verifiedは、人手で検証済みの実リポジトリIssueを解かせ、正しくパッチを当てられた割合を測る。

スコアは「スキャフォールド」と「LLM」の掛け算で決まる。同じClaude Opusでも、CodeActを持つOpenHandsのほうが素朴なエージェントより高く出る。逆に、実力を引き出すには強いモデルが要る。OSSなので「どういう設定で何点出たか」を第三者が追試でき、数値が信頼できる根拠になっている。

より難度の高い SWE-Bench Pro では最上位でも数値が大きく下がる。スコアはベンチマーク上の数値で、実プロジェクトでの成功率を保証しない。レガシーコードや独自フレームワーク、ドキュメント不足のリポジトリでは体感が下がることが多い。「定型的なバグ修正やIssue対応は高い確率で自動化できるが、難所は人間のレビューが要る」という期待値で運用する。

Claude Code・Cursor・Cline・Aider・Codex CLIとの比較

判断軸は「自律度（どこまで丸投げできるか）」と「自己ホスト性」だ。

OpenHandsは「サーバーに常駐させ、タスクを丸ごと自律でこなさせる」方向に最も振り切っている。VS Code内のエージェント体験ならCline、エディタの快適さならCursor、ターミナルでの軽いgit連携編集ならAiderが向く。エディタ内での運用は Cline（クライン）の使い方 が、商用側の動向は GitHub Copilotがネイティブアプリ化、デフォルトモデルもPolarisへ が参考になる。実務では日常の細かい編集はCursorやClaude Code、まとまったタスクの自動化や監査が要る社内基盤はOpenHands、という併用が噛み合う。

本番運用（Self-hostedとEnterprise）

Self-hosted：OSS本体を自社サーバーやクラウドVMに立てれば、コードを外部に出さずに運用できる。個人〜小規模チームならこれで実用になる。

# サーバー上でGUIサーバーを常駐させる例（systemd等で管理する想定）
openhands serve --host 0.0.0.0 --port 3000

公開ネットワークに晒すなら、リバースプロキシ＋認証を前に置き、docker.sock をマウントするコンテナの権限に注意する。エージェントは任意コマンドを実行しうるので、ネットワーク到達範囲とシークレットの渡し方を絞る。

Enterprise：リポジトリ内の enterprise 提供物で、Kubernetes上のマルチユーザー運用、RBAC（ロールベースアクセス制御）、Slack・Jira・Linearとの統合が用意されている。「IssueをSlackから振って、エージェントがPRを返す」業務フローを組める。コア（MIT）とは別ライセンスなので、商用利用の条件は公式で確かめる。運用負荷をかけたくないなら、公式が管理する Cloud を選ぶ。

SDK（Pythonライブラリ）を使えば、エージェントの起動・タスク投入・結果取得をコードから制御でき、「Issueが立ったら初期パッチを起票する」「依存更新でテストが落ちたら自動修正を試みる」といったCIジョブを組める。自動化の度合いを上げるほど人間のレビューが抜けるリスクも上がるので、「エージェントはPRのドラフトまで、マージは人間が判断する」というガードレールを置く。行動ログが全部残るOpenHandsは、この境界線を引きやすい。

よくある落とし穴

プロジェクト固有の規約（命名・ディレクトリ構造・禁止事項）をMarkdownでリポジトリに置いておくと、エージェントがそれを参照して品質が安定する。最初の1回はCloudの無料クレジットか使い捨てリポジトリの小さなタスクで癖を掴み、自己ホスト、チーム運用へと段階的に広げるのが失敗の少ない進め方だ。

参考リンク

・OpenHands/OpenHands — GitHub公式リポジトリ（旧 All-Hands-AI/OpenHands）
・Agent Canvas transition FAQ — Issue #14841（メンテナンスモードの範囲と期限の一次ソース）
・OpenHands/agent-canvas — Agent Canvas リポジトリ
・OpenHands/software-agent-sdk — エージェント本体とAgent Server
・OpenHands公式ドキュメント（docs.openhands.dev）
・OpenHands Cloud（app.all-hands.dev）
・SWE-bench 公式リーダーボード