Claude CodeとOpenHandsを比較する — OSSエージェントの提供面と使い分け

Claude CodeとOpenHandsの違いは「製品」か「構成部品」か

Claude CodeはAnthropicが提供するコーディングエージェントで、Claudeモデルの上で動きます。OpenHandsはオープンソースのコミュニティ発の取り組みで、ブラウザークライアント(Agent Canvas)、Python製のSDK、マネージドのCloud、企業向けのEnterpriseといった複数の部品で構成されています。同じ「ターミナルで動くコーディングエージェント」でも、片方は完成した製品、もう片方は組み合わせて使う一式という違いがあります。

もう一つの軸はモデルの選び方です。OpenHandsは初回起動時にLLMプロバイダーとAPIキーを設定させ、モデルを自分で選びます。Claude CodeはClaudeサブスクリプションかAnthropic Consoleのアカウントで認証し、モデルはClaude系に固まります。

この記事では、提供面・認証とモデル選択・承認モデル・非対話実行の4点を突き合わせ、最後に使い分けの早見表を置きます。OSSのCLI型エージェントとの比較はOpenCodeとの比較にあります。

まず、4軸の違いを1枚に並べます。各行の詳細は後続の節で扱います。

提供面の違い — OpenHandsは5つの部品に分かれる

OpenHandsの公式ドキュメントは、使い方を次のように整理しています。

CLIは機能完成済みで、主に安定性のために保守されます。ブラウザー側の開発の中心はAgent Canvasです。旧来のDockerベースのLocal GUIは非推奨で、Agent Canvasへの移行が案内されています。

Claude Code側の提供面は、ターミナル・IDE拡張・デスクトップアプリ・ブラウザーの4つです。CIではGitHub ActionsやGitLab CI/CDから呼び出せます。OpenHandsが「エージェントの実行基盤とクライアントを分けて配る」構造なのに対し、Claude Codeは「エージェント本体を各面に載せる」構造です。

CLIの入口はどちらも openhands と claude の1コマンドで、ここでは差が出ません。差が出るのは、バックエンドをどこに置くかを選べるかどうかです。Agent CanvasのバックエンドはローカルマシンのほかDocker・VM・Modal・OpenHands Cloudから選べます。Claude Codeのクラウド実行やWeb版は、Anthropicが提供する経路が前提になります。

認証とモデル選択の違い

OpenHandsはLLMを自分で持ち込む

OpenHands CLIは初回起動で、LLMプロバイダーとAPIキーの設定に進みます。設定は ~/.openhands/settings.json に保存され、会話履歴は ~/.openhands/conversations に残ります。OpenHands Cloudで認証済みなら、openhands login で設定を取得する道もあります。

SDKのほうは、LiteLLMがサポートするプロバイダーのAPIキーを使います。ドキュメントには次の3つの入手経路が並んでいます。

• プロバイダーに直接契約したAPIキー(AnthropicやOpenAIなど)
• OpenHands Cloudのクレジットで得るOpenHands用のLLMキー
• ChatGPT PlusまたはProのサブスクリプションでのログイン(SDKの LLM.subscription_login())

Claudeを使う場合も、SDKの例ではモデル名に anthropic/ を前置きする形で指定します。つまりOpenHandsにとってClaudeは、選べるモデルのうちの一つです。

export LLM_API_KEY="your-api-key"
export LLM_MODEL="anthropic/claude-sonnet-4-5-20250929"

上は公式のSDK手順に沿った環境変数の例で、モデル名は例示です。CLIには --override-with-envs があり、LLM_API_KEY・LLM_MODEL・LLM_BASE_URL の環境変数で保存済みの設定を上書きできます。

Claude Codeは公式アカウントで完結する

Claude CodeにはPro・Max・Team・Enterpriseのいずれか、またはConsoleのアカウントが必要です。無料のclaude.aiプランには含まれません。企業のクラウド利用向けに、Amazon Bedrock・Google Cloudのエージェントプラットフォーム・Microsoft Foundry経由の経路もあります。認証の詳細はClaude Codeのログイン方法にまとめています。

この設計の効きどころは運用の単純さです。サブスクリプションを契約すれば、APIキーの発行やモデルの選定なしに使い始められます。反対に、Claude以外のモデルへ差し替える選択肢はありません。

OpenHandsからClaude Codeを動かすこともできる

ここは見落とされやすい点です。Agent Canvasは、組み込みのOpenHandsエージェントのほかに、Agent Client Protocol(ACP)経由の外部エージェントも動かせます。対応するのはClaude Code・Codex・Gemini CLIで、Claude Codeの既定コマンドは npx -y @agentclientprotocol/claude-agent-acp です。

認証はサブスクリプションのログインかAPIキーの2通りです。同じマシンでAgent Serverが動く場合、Claude CodeのログインはmacOSのキーチェーンか、Linuxなら ~/.claude/.credentials.json から自動検出されます。両方ある場合はログインが優先され、環境変数のAPIキーは使われません。クリーンなクラウドサンドボックスにはログインが無いため、APIキーが必要になります。

つまり両者は二者択一とは限りません。OpenHandsをブラウザー側の操作画面や実行基盤として使い、中身のエージェントにClaude Codeを選ぶ構成が成立します。OpenHandsのIDE連携も同じACPの仕組みで、openhands acp をZed・VS Code(コミュニティ拡張)・JetBrainsなどが子プロセスとして起動します。ただしIDE連携は公式に実験的と明記されています。

承認モデルの違い

エージェントに何を勝手にやらせるかは、日々の運用で最も効く設定です。

OpenHands CLIの承認は3段階です。既定は毎回確認を求めます。--always-approve はすべての操作を確認なしで実行し、--llm-approve はLLMベースのセキュリティ解析で承認を判断します。

Claude Codeの権限モードは、default(初回利用ごとに確認)・acceptEdits(作業ディレクトリ内のファイル編集を自動承認)・plan(読み取り中心で探索)・auto(バックグラウンドの安全確認つきで自動承認)・bypassPermissions(確認をスキップ)などです。許可・確認・拒否のルールをツール単位で細かく書ける点は、OpenHandsのフラグ式より粒度が細かい設計です。実行環境の隔離も含めた比較はAIコーディングエージェントのサンドボックス実装比較にあります。

ここで押さえたいのは、実行場所の分離との組み合わせです。OpenHandsはDockerやVM、Cloudのサンドボックスにバックエンドを置く前提の選択肢が主要な経路として並んでおり、承認を緩めても実行環境の側で影響範囲を絞れます。ローカルのnpmやnpxで動かすバックエンドは、Docker利用時と違ってマシン上のファイルにそのまま触れます。公式もエージェントが触れるファイル・シークレット・ネットワークだけを接続するよう注意を出しています。

非対話実行とCI連携の違い

CIやスクリプトから呼ぶ使い方は、両者とも用意されています。

# OpenHands: 非対話モード。JSONLでイベントを出力
openhands --headless --json -t "Add unit tests" > output.jsonl
 
# Claude Code: -p で非対話実行し、許可ツールを限定
claude -p "Find and fix the bug in auth.py" --allowedTools "Read,Edit,Bash"

OpenHandsの --headless はタスクを --task か --file で必ず渡す必要があり、常に always-approve で動きます。公式は「この設定は変えられず、--llm-approve も使えない」と警告しています。CIに載せるなら、実行環境の側で影響範囲を絞る設計が要ります。

Claude Codeの -p は、--allowedTools で使えるツールを絞れます。--output-format json を付ければ、コストの見積もりを含む結果が返り、--json-schema で構造化出力も取れます。GitHub Actions用のアクション(claude-code-action)も公式に用意されており、PRやissueのコメントで @claude と呼び出す運用まで含めて選べます。

OpenHands側の長所は、SDKでエージェント自体を組める点です。openhands-sdk と openhands-tools をpipで入れ、LLM・Agent・Conversation を組み合わせて自作のエージェントを書きます。Claude側で近い位置にあるのはAgent SDKとManaged Agentsですが、こちらはClaudeモデルが前提になります。

MCPと拡張の違い

MCPはどちらも使えます。OpenHands CLIは openhands mcp add <name> --transport http <url> の形で、http・sse・stdioの3種を登録できます。--header で認証ヘッダーを付けられ、--auth oauth の指定もあります。list・get・remove・enable・disable の管理コマンドが揃っています。

openhands mcp add my-api --transport http \
  --header "Authorization: Bearer your-token" \
  https://api.example.com/mcp

Claude Code側のトランスポート対応や設定ファイルの違いはAIコーディングエージェントのMCP対応状況の比較に譲ります。OpenHandsにもリポジトリ向けの AGENTS.md とスキルの仕組みがあり、拡張の考え方は近い形です。Claude Code側は CLAUDE.md・Skills・サブエージェントで同じ役割を担います。

使い分け早見表

よくある質問

OpenHands CLIとClaude Codeを別々に入れると設定は衝突するか

OpenHandsの設定と会話履歴は ~/.openhands、Claude Codeのログインは ~/.claude 側と、置き場が分かれています。別々のCLIとして入れて並行利用しても、互いの設定ファイルを上書きする形にはなりません。

WindowsでOpenHands CLIを使えるか

OpenHands CLIはネイティブのWindowsを公式にはサポートしておらず、WSL(Windows Subsystem for Linux)のターミナルで実行する前提です。Claude CodeはネイティブのWindowsにインストールする手順が公式にあります。

OpenHands CLIのインストールに必要な環境は何か

推奨は uv tool install openhands --python 3.12 で、Python 3.12以降とuvが必要です。実行バイナリ版のインストールスクリプトとDocker経由の起動も用意されています。

まとめ

Claude Codeは、Claudeに固定する代わりに、認証・権限・各提供面が1つの製品として揃っているエージェントです。OpenHandsはモデルも実行基盤も選べる代わりに、CLI・Canvas・SDK・Cloudのどれを軸にするかを自分で決める必要があります。

判断軸は2つに絞れます。使うモデルをClaudeに固定してよいか、そして実行環境を自前で持ちたいか。固定してよく、手軽さを取るならClaude Code。モデルを切り替えたい、あるいはSDKでエージェントを組みたいならOpenHands。両者はACP連携でつながるので、OpenHandsを画面と実行基盤に、Claude Codeを中身にする構成も選択肢に入ります。