先に結論
3者は同じ background coding agent に見えても、主役のレイヤーが違います。
- OpenAI Agents SDK harness: OpenAI の runtime を軸に、sandbox agents / sessions / handoffs を使って自前 control plane を組みたい人向け
- Vercel Open Agents: web app + durable workflow + sandbox orchestration + GitHub integration を一体で持ちたい人向け
- OpenHands: SDK / CLI / GUI / self-host / enterprise を横断しながら、自社側で実行基盤を握りたい人向け
なので選び方はかなり単純です。
- PoC を最短で作り、OpenAI runtime を中心に伸ばす → OpenAI Agents SDK harness
- Vercel 上で background coding agent SaaS / internal tool を形にしたい → Vercel Open Agents
- self-host、VPC、OSS 拡張を重視する → OpenHands
細かい coding agent 比較は open-swe vs Claude Code vs Codex vs GitHub Copilot coding agent、framework の広い比較は Google ADK vs OpenAI Agents SDK vs LangGraph vs CrewAI、sandbox レイヤーを詰めたいなら AIエージェント向けSandbox比較 も合わせて読むと判断しやすいです。
なぜ今この比較が重要か
2026年4月時点の論点は、単なる「coding agent を動かせるか」ではありません。読者が本当に迷っているのは、agent control plane と sandbox execution plane をどこで分けるか です。
OpenAI Agents SDK は sandbox agents、manifest-defined files、sandbox client choice、resumable sandbox sessions を打ち出し、Vercel Open Agents は durable workflow と sandbox VM の分離を前面に出しています。OpenHands は SDK、CLI、Local GUI、hosted cloud、enterprise/VPC までレイヤーを広げてきました。
つまり今の比較軸は次の5つです。
- control plane を誰が持つか
- sandbox / VM を誰が持つか
- GitHub 連携をどこまで最初から持つか
- resume / recovery をどこで担保するか
- self-host と enterprise 制約にどこまで耐えるか
この整理がないまま導入すると、PoC は速いのに本番で詰まるか、逆に最初から重く作りすぎます。
比較表
| 比較軸 | OpenAI Agents SDK harness | Vercel Open Agents | OpenHands |
|---|---|---|---|
| 主な立ち位置 | lightweight runtime / SDK | reference app / durable workflow 基盤 | OSS ベースの AI-driven development 基盤 |
| control plane | 自前で組みやすい | Vercel workflow 主導 | SDK / Cloud / Enterprise で選べる |
| sandbox 実行 | sandbox agents と client 選択 | Vercel sandbox を分離運用 | ローカル / self-host / cloud で広い |
| resume / recovery | resumable sandbox sessions | workflow resume と sandbox hibernation | 実装形態次第だが self-host しやすい |
| GitHub 連携 | 自前実装寄り | 最初から強い | 使えるが構成次第 |
| web UI / app 層 | 自前で足す | かなり揃っている | GUI / Cloud がある |
| self-host 適性 | 中 | 低〜中 | 非常に高い |
| enterprise 導入 | OpenAI 中心組織向け | Vercel 中心組織向け | VPC / enterprise 制約に強い |
| 向いているチーム | OpenAI runtime を軸に独自化したい組織 | Vercel で速く productize したい組織 | OSS / self-host / 管理境界重視の組織 |
まず見るべき違い
OpenAI Agents SDK harness は「runtime を自分で組みたい」人向け
OpenAI Agents SDK の価値は、agent を完成品として渡すことではなく、少ない primitive で本番 runtime を組めること にあります。
公開情報ベースでは、主な要素は次の通りです。
- Agents
- Handoffs
- Guardrails
- Sandbox agents
- Sessions
- Tracing
特に今回効いているのは、sandbox agents を real isolated workspaces で動かせること、manifest-defined files を扱えること、sandbox client choice を持てること、resumable sandbox sessions を前提にできること です。
つまり OpenAI Agents SDK harness は、
- OpenAI モデルと runtime を中心に据えたい
- でも app 層や GitHub 連携は自社仕様で組みたい
- いずれ独自の control plane を持ちたい
という組織に噛み合います。
逆に、最初から web UI、auth、GitHub App、PR 生成、durable workflow まで揃った完成度を期待するとズレます。そこは自分たちで積む前提です。
Vercel Open Agents は「app と orchestration まで欲しい」人向け
Vercel Open Agents は単なる SDK ではなく、background coding agent を product として組むための参照実装 です。
README ベースでも、構成はかなり明快です。
- web app が auth、sessions、chat、streaming UI を担当
- agent は durable workflow として Vercel 上で動く
- sandbox VM は filesystem、shell、git、preview ports を持つ execution layer
- agent 自体は VM の中ではなく、外からツール越しに sandbox を操作する
この「agent execution と sandbox lifecycle を分離する」設計が本質です。
その結果、
- request lifecycle に縛られない
- sandbox を hibernate / resume できる
- model/provider と sandbox 実装を別々に進化させられる
- GitHub clone、branch 作業、auto-commit、auto-PR までつなぎやすい
という強みが出ます。
だから Vercel Open Agents は、Vercel を control plane に近い位置に置いて、background coding agent SaaS や社内ツールを短期間で出したい チームに向いています。
弱点も分かりやすく、Vercel と GitHub App の前提が強いこと、self-host の自由度では OpenHands に譲ることです。
OpenHands は「実行基盤を自社側で握りたい」人向け
OpenHands の強みは、単一の UI や SDK に閉じないことです。現時点の公開情報でも、次の層を持っています。
- composable な SDK
- Claude Code や Codex に近い体験の CLI
- laptop 上で動かせる Local GUI
- hosted の OpenHands Cloud
- VPC 展開まで含む Enterprise
さらに enterprise 側では multi-user support、RBAC、permissions、collaboration、self-hosted VPC まで射程に入っています。
ここが刺さるのは、
- OSS から始めたい
- でも最終的には社内 VPC や Kubernetes に載せたい
- CLI / GUI / SDK を混ぜて運用したい
- SaaS 依存を抑えたい
という組織です。
反対に、最速で polished な Vercel app を出すことが目的なら OpenHands はやや広く、導入判断の自由度が高いぶん設計責任も増えます。
5つの比較軸で選ぶ
1. PoC 最速で出したいか
PoC 最速だけを見るなら OpenAI Agents SDK harness が軽いです。primitive が少なく、sandbox agents や sessions まで OpenAI runtime の流れで乗せやすいからです。
ただし「PoC が速い」と「プロダクト化が速い」は別です。ログイン、GitHub 連携、チャット UI、長時間 run の再接続まで含めると、Vercel Open Agents のほうが近道になるケースが多いです。
2. Vercel に寄せたいか
Vercel をすでに使っているなら、Vercel Open Agents はかなり筋が良いです。durable workflow、sandbox snapshot、preview ports、GitHub App 連携が最初から同じ文脈にあります。
逆に Vercel 前提を持ちたくないなら、ここはそのまま制約になります。
3. self-host を優先するか
self-host、VPC、Kubernetes、社内権限制約が強いなら OpenHands が第一候補です。OpenAI Agents SDK でも自前構築はできますが、OpenHands は CLI / GUI / enterprise まで含めた運用物としての幅があります。
4. GitHub 連携をどこまで完成形で欲しいか
最初から repo clone、branch 作業、PR 生成まで寄せたいなら Vercel Open Agents が分かりやすいです。
OpenAI Agents SDK harness は GitHub 連携を組み込めますが、主語は runtime なので integration layer は自前設計寄りです。OpenHands は運用形態によって答えが変わるので、GitHub 一体感だけで見ると Vercel ほど直球ではありません。
5. enterprise の説明責任をどう作るか
- OpenAI Agents SDK harness: OpenAI runtime を軸に、自社ルールで説明責任を作る
- Vercel Open Agents: workflow と sandbox の分離設計で、app と運用境界を説明する
- OpenHands: self-host / RBAC / VPC を含めて、インフラ側から説明責任を作る
どれが強いかではなく、どの層で説明責任を持ちたいか が違います。
読者別の選び方
OpenAI 中心で独自基盤を育てるなら
OpenAI Agents SDK harness が本命です。OpenAI の runtime、guardrails、sessions、tracing を中心に据えながら、GitHub 連携や app 層は必要な分だけ積めます。
Vercel 上で background coding agent プロダクトを出すなら
Vercel Open Agents が最も自然です。durable workflow と sandbox orchestration の分離が最初から整理されていて、web app まで見えているからです。
self-host / enterprise 制約が重いなら
OpenHands が第一候補です。OSS から始めて、CLI / GUI / cloud / enterprise まで段階的に広げられます。VPC や RBAC が最初から重要なら、かなり現実的です。
どれが収益記事として一番強いか
比較メディアの文脈では、このテーマはかなり収益に近いです。理由は、読者が単なる技術好奇心ではなく、導入判断の直前 にいるからです。
特に相性が良い内部リンクは次です。
- Google ADK vs OpenAI Agents SDK vs LangGraph vs CrewAI
- AIエージェント向けSandbox比較
- GitHub Agentic Workflows vs Copilot coding agent vs OpenClaw cron
- open-swe vs Claude Code vs Codex vs GitHub Copilot coding agent
framework 比較、sandbox 比較、GitHub workflow 比較、coding agent 比較をこの1本に集められるので、回遊にも効きます。
迷ったらこの順で見る
- 最初の PoC を 1 週間で形にしたい → OpenAI Agents SDK harness
- Vercel 上で background coding agent app を作りたい → Vercel Open Agents
- self-host と enterprise 制約が最優先 → OpenHands
この3択でだいたい外しません。