Cursorは2026年8月17日、Gitホスティング「Origin」の早期ベータを有料プランへ段階的に開放した。これまでコードを書く場所とエージェントが動く場所だったCursorは、Gitリポジトリを保管し、プルリクエスト（PR）を処理する場所にも踏み込む。狙いはGitの互換性そのものではない。エージェントがコードを読み、変更し、チェックを受け、PRを更新する往復をCursor内でつなげられるかが、今回の早期ベータの判断材料になる。
ただし、これは完成版や一般提供ではない。Freeは対象外で、Pro、Teams、Enterpriseでもアクセスは順次開くため、対象プランならすぐ表示されるとは限らない。Enterpriseでは管理者がオプトアウトでき、Cursorは今後「agent-native features」を提供するとしている。
有料プランへ段階開放されたコード保管機能
Originではリポジトリを作成し、標準Gitでclone、push、pullできる。コードの閲覧・検索、PRの作成、レビュー、マージに対応し、チーム内で共有できる。GitHubの既存リポジトリはミラーとして取り込めるため、いきなり保管先を切り替えずに試せる設計でもある。
Cursor AgentはOriginリポジトリを新たに作成できる。既存のOriginリポジトリではCloud Agentがcloneしてbranchを切り、変更をcommitしてpushし、PRを開ける。AutomationsはpushまたはPRイベントを起点にCloud Agentを実行できる。Vercelのほか、DepotとBuildkiteとの連携も用意した。
ただしDepotとBuildkiteはOriginネイティブのリポジトリだけを対象にする。GitHubミラーのCIはGitHub側に残るため、初期提供の中心はコードの保管と閲覧、PR処理、GitHub同期である。エージェント向けの機能がすべて揃ったわけではない。
APIで扱える操作と積み上げPR
Originネイティブのリポジトリには、https://api.cursor.com/v1/originをベースURLとするREST APIがある。リポジトリやコミットを読み書きし、チェックとPRを更新できる。アプリ導入もAPIで扱い、エージェント向けにはllms.txtを公開した。Origin AppsはEd25519鍵で短命JWTに署名し、導入アクセストークンへ交換する。Git HTTPS用のトークンは最長15分で失効する。
権限はコード内容からPR、レビュー、チェックまで用途別に分かれる。installation access tokenの既定上限は1分当たり3000ポイント、App JWTとuser/team service-account API keyは同600ポイントである。大半のreadは1ポイント、通常のwriteは5ポイント、リポジトリ作成とPR mergeは10ポイントを消費するため、エージェントを増やせば無制限に操作できる仕組みではない。
APIとGit操作で同じ短命トークンを使えるため、アプリは許可されたリポジトリだけをcloneし、変更をpushしてPRやチェックを更新できる。短命トークンと細かなスコープは、常時動くエージェントに恒久的な広い権限を渡さずに済む設計である。
PR作成APIはparentPullNumberを受け取り、依存する変更を積み上げPRとして連結できる。マージAPIはスタックの根から指定したPRまでをまとめてマージする。レビュー単位を細かく分けながら、順序を保って統合するための操作だが、この機能はOriginネイティブのリポジトリに限られる。
Webhookは重複し得るat-least-once方式で配信し、通信エラーと429、5xxでは最大6回再試行する。待機時間は30秒から始まり、1分、2分、4分を経て8分まで延びる。一方、push webhookには完全なcommit listが入らず、PRコメントのthread IDに対する専用のthread/resolution APIもない。自動化を組む側は、この不足分を前提に設計する必要がある。
GitHubミラーは移行路であり、GitHubを正本に残す
GitHubミラーはGit履歴からブランチ、タグまでを継続同期する。コードはOriginで閲覧・検索でき、PRは双方向に同期する。だが、GitHub IssuesとGitHub Actionsのworkflow、secretは同期しない。ミラーへのpushはGitHubへ通り、GitHubが正本のままだ。
この分離があるため、既存プロジェクトは保管先を変えずにOriginを試せる。ただし、OriginがGitHubを置き換えたわけではない。GitHubからのミラーはOrigin Appsを導入できず、APIで指定すれば403となる。Webhookも送られず、PR merge APIはミラーを拒否する。ミラー段階では、エージェントに任せる操作とCIをGitHub側に残すことになる。
ミラーをdetachすればOriginが正本へ変わるが、GitHub側のリポジトリには影響しない。移行の可否は、Gitの同期だけで決まらない。IssuesやCIの運用をどこへ置くかに加え、アプリが操作できる範囲を作り直す必要がある。
7万件超の競合はOriginの性能値ではない
Cursorが別途公表したエージェント群の実験では、旧ハーネスは停止までに7万件超のマージ競合を生んだ。新ハーネスでは4時間全体で1000件未満となり、旧実験で最も混雑したファイルでは1173のエージェントが7771件の競合を起こした。新実験における1ファイル当たりの最大は47件だった。
この数値はOriginのベンチマークではない。Originが競合を自動解消する性能を示すものでもない。それでも、並列エージェントの運用ではコードを生成することより、同じリポジトリの変更をどう分け、確認し、統合するかで詰まる場面があることは分かる。Originの積み上げPRと権限スコープは、こうした調整作業を支える。短命トークンとイベント再試行も、エージェントを安全に動かすための土台になる。
GitHubの規模に対し、一体運用で差を作れるか
GitHubは2025年に1億8000万人超の開発者を抱え、月平均4320万件のPRがマージされた。コミットは年間でほぼ10億件、コードのpushは月平均8219万件に達し、2025年8月だけでもコミットは約1億件を記録した。GitHub自身も2026年4月、Copilot cloud agentがPRをすぐ開かずにbranch上で作業し、diffを確認してからPRへ進める機能を有料プランへ提供した。「エージェントに対応する」ことだけではOriginの差にはならない。
Cursorが試されるのは、ホスティングとCursor Agentを一体で運用したとき、既存のGitHub中心の作業よりレビューと統合を扱いやすくできるかどうかだ。Cursorは早期ベータについて、大量並列時の処理量やサービス水準の保証値を示していない。まずは利用拡大の速度に加え、ネイティブ連携の範囲、安定性、チームが権限と変更を管理できるかを確かめる必要がある。
