先に結論
private network 前提で AI coding agent を選ぶなら、先に見るべきは モデルの賢さ ではなく、どこでコードが実行され、どこに secrets と build outputs が残り、どこまで SaaS を許容するか です。
ざっくり整理するとこうです。
- Cursor self-hosted cloud agents: agent 体験を保ちながら、実行環境を自社ネットワーク側へ最も強く寄せやすい
- GitHub Copilot coding agent + self-hosted runners: GitHub 運用を残したまま、開発環境を自社インフラ側へ寄せやすい
- Claude Code: ローカル主導で進めやすく、proxy や Bedrock / Vertex 経由の企業導入に向く
- Codex: self-hosted worker 型ではないが、sandbox・approval・managed policy を含めた統制設計がしやすい
つまり、
- コード・build outputs・secrets を自社ネットワーク内に閉じ込めたい → Cursor self-hosted cloud agents
- GitHub ベースの標準運用を崩さずに自社実行環境へ寄せたい → GitHub Copilot coding agent
- まず開発者ローカル中心で導入したい → Claude Code
- private network より統制設計と approval policy を重視したい → Codex
監査性や承認フローも含めて広く見たいなら GitHub Copilot coding agent vs Claude Code vs Codex｜監査性・安全性・レビュー運用で選ぶ や Claude Code Auto Mode vs Codex approval policy vs GitHub Copilot｜AI coding agent の承認フロー比較 も合わせて読むと全体像がつかみやすいです。
なぜ今この比較が重要か
2026-03-25 に Cursor は Self-hosted Cloud Agents を発表し、AI coding agent の比較軸を一段変えました。ポイントは、コードと tool execution を SaaS 側の sandbox ではなく、自社ネットワーク内の worker で動かせる ことです。Cursor の changelog では、codebase、build outputs、secrets が internal machines に留まり、worker は outbound HTTPS で接続すると説明されています。
これで比較軸は単なる IDE 体験やモデル品質ではなく、次の5つになりました。
- agent 実行場所はどこか
- コード / build outputs / secrets がどこに残るか
- control plane と execution plane が分離されているか
- 監査・レビュー・承認をどう説明するか
- Platform チームがどこまで面倒を見る必要があるか
regulated な組織では、この差がそのまま導入可否に直結します。便利でも、データ境界の説明がつかないツールは通りません。
比較表
| 比較軸 | Cursor self-hosted cloud agents | OpenAI Codex | Claude Code | GitHub Copilot coding agent |
|---|---|---|---|---|
| 実行場所 | 自社インフラ上の worker | OpenAI のクラウド sandbox が中心 | ローカル端末 / 企業クラウド経由 | GitHub Actions 環境、self-hosted runners 可 |
| code / secrets を自社内へ留めやすさ | 非常に強い | 中 | 強い | 強い |
| control plane / execution plane 分離 | 非常に明確 | 中 | 中 | 中〜強 |
| GitHub 運用との親和性 | 強い | 強い | 中 | 非常に強い |
| 導入難易度 | 高い。Platform 前提 | 中 | 中 | 中〜高 |
| 監査・説明責任 | 強い | 強い | 中 | 非常に強い |
| 向いている組織 | 厳格な private network 前提 | 統制設計重視 | ローカル主導・段階導入 | GitHub 標準運用の企業 |
4つの違いを先に整理する
Cursor self-hosted cloud agents は「体験は cloud、実行は自社側」に最も寄せやすい
Cursor の self-hosted cloud agents は、いまの4択の中で最も execution plane を自社側へ移しやすい です。
公開情報では次が明示されています。
- worker は outbound HTTPS で Cursor cloud に接続する
- inbound ports や VPN トンネル不要
- コード、tool execution、build artifacts は 自社インフラ内の machine に残る
- Kubernetes 向けに Helm chart / operator まで用意される
ここが強いのは、SaaS の agent UX を使いつつ、実際の repo・cache・internal endpoints・secrets に触る部分は自社ネットワーク内に閉じ込めやすいことです。
つまり Cursor は、完全なオンプレ製品ではないが、実務上ほしいデータ境界にかなり近づける タイプです。
弱みも明確です。
- Platform チームの準備がいる
- worker fleet 管理まで考えると導入は重い
- control plane は Cursor 側に残る
なので、個人の試しやすさより 組織条件を満たしながら agent を本気導入したい企業向け と考えるのが正確です。
GitHub Copilot coding agent は self-hosted runners で現実解を作りやすい
GitHub Copilot coding agent 自体は GitHub サービス上の agent ですが、2025-10-28 の GitHub changelog で self-hosted runners 対応 が明示されています。Actions Runner Controller の scale set を copilot-setup-steps.yml の runs-on: に指定できるため、開発環境を自社インフラへ寄せやすくなりました。
これが意味するのは、次の現実解です。
- issue / PR / session logs / review は GitHub 上で管理する
- 実際の build・dependency access・internal package 参照は自社 runner で行う
- 既存の GitHub 標準運用を崩さず、private resource access を足せる
Cursor ほど「agent worker 全体が自社内」という形ではありませんが、GitHub を捨てずに private network 条件を満たしやすい のが強みです。
特に、すでに GitHub Actions self-hosted runners を運用している会社では導入ストーリーを作りやすいです。
Claude Code は self-hosted ではないが、ローカル主導の安全側に寄せやすい
Claude Code は Cursor のような self-hosted worker でも、Copilot のような self-hosted runner 連携でもありません。ただし、Claude Code Docs の enterprise deployment overview では、Anthropic 直利用だけでなく Bedrock / Vertex AI / Microsoft Foundry 経由、さらに corporate proxy や LLM gateway を通した構成が整理されています。
ここで重要なのは、Claude Code の価値が agent をどこで実行するか より、どの経路でモデル呼び出しを統制するか にあることです。
- 開発者ローカル端末で動かす
- 企業 proxy を通す
- Bedrock / Vertex など、既存クラウドのガバナンスへ寄せる
CLAUDE.mdや managed permissions で運用を揃える
つまり Claude Code は、ローカル主体のまま企業ネットワーク制約へなじませやすい ツールです。
逆に言えば、Cursor のように「自社クラウドに agent worker を置いて並列実行する」話ではありません。なので regulated な大規模組織で full self-hosted 的な期待を持つとズレます。
ただし、段階導入ではかなり強いです。
- まずはローカルで試せる
- proxy 経由に載せやすい
- Bedrock / Vertex へ逃がせる
- 開発者が対話的に使いやすい
このため、いきなり Platform チームを巻き込まず、private network 制約の中で小さく始めたい組織 には有力です。
Codex は self-hosted ではなく「統制設計」の選択肢
OpenAI Codex は、この4つの中では最も誤解されやすいです。Codex の cloud task は isolated cloud sandbox が基本で、OpenAI の紹介でも repo を preloaded した cloud container で作業すると説明されています。つまり、private network 起点で見た時に主役は self-hosted ではありません。
その代わり、Codex の価値は次にあります。
- sandbox mode
- approval policy
- managed policy
- enterprise admin setup
- Compliance API などの統制導線
要するに Codex は、データ境界そのものより、agent をどの権限でどこまで許すかを設計したい組織向け です。
private network が絶対条件なら第一候補にはなりにくいです。ただし、
- 一部コードはクラウド sandbox へ出せる
- その代わり承認・ログ・ポリシーは厳密にしたい
- 将来的に企業全体で標準化したい
という組織では候補になります。
どの制約ならどれを選ぶべきか
1. 「コード・secrets・build outputs を社外に出したくない」が最優先なら Cursor
Cursor self-hosted cloud agents が一番噛み合います。理由はシンプルで、比較対象の中で最も明確に execution plane を自社側へ置ける からです。
特に次の条件なら相性が良いです。
- internal package registry や private network endpoint がある
- build cache を社内に置きたい
- repo や secrets を public cloud sandbox に出したくない
- Platform チームが worker fleet を運用できる
2. GitHub 標準運用を崩したくないなら GitHub Copilot coding agent
既存のレビュー、PR、session logs、Actions 運用が強い会社なら GitHub Copilot が最も自然です。self-hosted runners を使えば internal packages や private network resource に触れやすくなり、レビュー導線も GitHub に残せます。
これは 完璧な self-hosted というより、最小変更で enterprise 条件を満たす現実解 です。
3. 小さく始めたいなら Claude Code
Claude Code は、Platform チーム主導の重い導入より まず現場の価値検証をしたい 時に強いです。
- 開発者ローカルで始める
- corporate proxy 経由へ載せる
- 必要なら Bedrock / Vertex に寄せる
この段階的な移行がしやすいので、private network 制約があるが、いきなり worker 基盤を作るほどではない組織に向きます。
4. ポリシー設計を主役にするなら Codex
Codex は self-hosted 目的ではなく、approval / sandbox / managed policy を標準化したい 組織向けです。
つまり判断軸はこうです。
- データ境界最優先 → Cursor
- GitHub 標準運用最優先 → GitHub Copilot
- 段階導入最優先 → Claude Code
- 統制設計最優先 → Codex
実務で見落としやすい論点
self-hosted でも control plane は SaaS のままなことが多い
Cursor が最も self-hosted に寄っていますが、それでも control plane は Cursor 側にあります。GitHub Copilot も GitHub サービスを使います。Claude Code も Anthropic 直利用やクラウドプロバイダ経由です。Codex は OpenAI クラウド sandbox です。
なので、要件定義では 完全オンプレか、execution plane だけ自社側ならよいか を最初に分けるべきです。
「private network 対応」と「ローカル実行」は同じではない
Claude Code はローカル主導で安全側に寄せやすいですが、それは Cursor の self-hosted cloud agents と同じ意味ではありません。
- Claude Code: ローカル / proxy / provider governance
- Cursor: worker 実行環境を自社側へ寄せる
- Copilot: runner を自社側へ寄せる
- Codex: policy と sandbox を主役にする
ここを混ぜると選定を間違えます。
Platform チームの負荷も比較軸に入れるべき
データ境界が強いほど、だいたい運用は重くなります。
- Cursor self-hosted は最も強いが最も重い
- Copilot self-hosted runners は中間
- Claude Code は始めやすい
- Codex は運用設計は重いが infra 自体は比較的シンプル
private network 比較では、セキュリティ条件を満たすか と同じくらい 誰がその仕組みを面倒見るか が重要です。
迷ったときの最終基準
- private network / self-hosted が主語 なら、最初に Cursor と GitHub Copilot を比較する
- 開発者ローカル中心で始めたい なら Claude Code を混ぜる
- 統制と承認設計を主役にしたい なら Codex を比較に残す
いちばんズレにくい結論はこれです。
コード・secrets・build outputs をできるだけ自社ネットワークに閉じ込めたいなら Cursor。GitHub 標準運用を崩したくないなら Copilot。小さく始めるなら Claude Code。ポリシー設計を主役にするなら Codex。