Cursor Origin Early Beta：使える機能と、まだ見えないこと

最初の2か月間、Cursor Originはキャッチコピーとメール登録フォームだけの存在だった。それが2026年8月17日、CursorのコードホスティングとしてEarly Betaに入った。ただし、先に押さえておきたい点が2つある。GitHubから同期したリポジトリの正本はあくまでGitHubであり、有料ユーザーからは提供状況にばらつきがあるとの報告も出ている。

Cursor Originはもう使える？

Cursor Originは2026年8月17日からEarly Betaとして提供されており、対象はすべての有料Cursorプランだ。ただしEnterprise組織は例外となる。同じchangelogによると、管理者が利用対象から外すことができる。プロダクトのランディングページにも、「Early beta」の案内からベータ版へのリンクが用意されている。

とはいえ、全ユーザーに同時に見えているわけではないようだ。8月17日から18日にかけてのr/cursorのローンチスレッドでは、有料ユーザーから告知と実際のアカウント状況の差を指摘する声があった。

「まだウェイトリスト登録しか表示されません。」— u/NerdyGuy117、r/cursor

「Teamsプランですが、まだアクセスできません。」— u/Darkoplax、r/cursor

こうした報告を見る限り、対象アカウントすべてへ即時開放する方式ではなく、段階的なロールアウトと考えるのが自然だ。有効化されたアカウントではCodebaseタブにOriginリポジトリが表示される。対象プランなのに何も表示されない場合は、まだそのアカウントにベータ版が届いていない。

発表当時には、r/cursorのあるコメント投稿者がプロダクトページを「情報がない。メール入力欄だけのスプラッシュページだ」と評していた。(u/One-Poet7900)

Early Betaで使えるOriginの機能

ベータ版で提供される機能は大きく4つで、詳細は以下の表のとおりだ。changelogによれば、リポジトリはCursorの新しいCodebaseタブに置かれる。リポジトリ名はURLの一部になり、Cursorの例ではcursor.com/codebase/acme-corpとなる。作成時は+Newを選び、名前を付け、CLIをインストールしてから、クローンまたは既存ローカルプロジェクトのpushを行う流れだ。

プルリクエストではタイムライン、コミット、チェック結果、変更ファイルを確認できる。差分レビュー、コメント、マージもエディタを離れずに実行可能だ。アイコンで、CursorがホストするリポジトリとGitHubから同期されたリポジトリを見分けられる。

GitHub同期は「移行」ではなくライブミラー

OriginのGitHub同期は、GitHubを置き換える第2の正本を作る機能ではない。GitHubを接続し、組織とリポジトリを選ぶと、Cursor側にリアルタイムで同期されるコピーが作成される。changelogによれば、同期されたリポジトリへの読み取りまたは書き込み権限を持つユーザーはCursorで閲覧でき、あとからリポジトリごとに設定画面から接続解除することも可能だ。

Cursorコミュニティでは、ベータ開始前から次の問いが繰り返されていた。

「OriginはGitHubやgitの代替なのですか？」— u/sn2006gy、r/cursor

ベータ版の設計を見る限り、答えは明確だ。GitHubで始まったリポジトリでは、push先は引き続きGitHubであり、Originのコピーは閲覧、検索、pullのために使う。Cursorのchangelogにも、GitHubが正本であり続けると明記されている。

管理主体がCursorへ移るのは、Origin内でネイティブに作成したリポジトリだけだ。

Origin内のエージェントとCI連携

changelogによると、Originリポジトリにアクセスできるエージェントは、コードに関する質問への回答、変更の実施、プルリクエストの更新、ブランチのpushを行える。ローンチの数か月前には、r/cursorのあるユーザーが生じるボトルネックを端的に表現していた。「コードレビューがひどいボトルネックになっている。」(u/calloutyourstupidity)

ローンチ時に提供されたアプリは、Vercel、Depot、Buildkiteの3つだ。リポジトリのAppsタブからVercelを接続すると、すべてのPRにテスト・コメント用のプレビューデプロイが作成され、マージ時には本番環境へデプロイされる。DepotとBuildkiteは既存のGitHub Actionsワークフローを実行し、Buildkiteはネイティブパイプラインも実行する。ここで区別すべきなのは、GitHub同期リポジトリでは既存のGitHub側CIを維持できる一方、Originがネイティブホストするリポジトリで接続できるのは現時点でこの3アプリだけという点だ。

エージェント運用を取り巻く部分について、changelogは触れていない。エージェントによるpushに対する認可制御や監査ログ、リポジトリごとの上限、コストの詳細はいずれも未公開だ。Cursor以外で自前のコーディングエージェントを動かしているなら、リポジトリへpushする仕組みに対しても、コーディングエージェント向けLLMを選ぶ基準と同じ観点が当てはまる。

ベータ版でまだ明らかになっていない点

• リポジトリサイズ、ストレージ、同時実行数の上限は公開されていない。SLAや可用性目標もない。
• Origin固有の料金体系は未発表だ。現時点での商用面の説明は「有料プランに含まれる」だけで、追加料金、クォータ、将来の無料枠には触れられていない。
• Origin固有のデータ取り扱い条件もない。Cursorのsecurity pageにはSOC 2認証が記載されているが、発表時に問われた学習データと保持期間について、ホスト型リポジトリに特化した回答は公開されていない。
• Compileステージで示された数値、すなわち1リポジトリで毎秒22.6コミット、「1時間あたり数十万件のクローン」は、依然としてデモ上の主張にとどまる。独立したCursorガイドは未検証としており、ローンチ記事では、広く繰り返された「296,000超のクローン」という数字から元の時間単位が抜け落ちたと指摘している。

CursorがOrigin固有の条件を公開するまでは、6月時点のこの反応が導入判断における現実的な制約であり続ける。

「完全なGit履歴をCursorに預ける可能性はゼロです。」— u/fintechbass、r/cursor

今試すべき人、待つべき人

ベータ版が終わっても残る論点は、リポジトリのホスト移転が管理主体の移転を意味することだ。同じスタック型PRの比較では、PRスレッドのようなGit以外のレビュー情報は「git pushでは移動しない」と注意を促している。そのため、現行の選択肢ではOriginが最も元に戻しにくい。この比較ではさらに、Cursorが2025年12月19日にスタック型PR企業Graphiteを買収する最終契約を発表したこと、GraphiteチームがCursor内でOriginを開発していること、Graphiteはgraphite.comで引き続き独立運営され、年払いではユーザー1人あたり月額$20〜40のスタッキング向けプランが掲載されていることも記録している。

Cursor OriginはGitHubの代替になる？

ならない。GitHubから同期したリポジトリはGitHubを正本として維持し、pushもGitHubに届く。Originはネイティブホスティングの選択肢と、その上に重なるレビュー画面を追加するものだ。

Cursor OriginはCursorプランに含まれる？

Early Betaはすべての有料Cursorプランで利用できる。Origin単体の料金、クォータ、無料枠の予定は発表されていない。

Cursor Originはスタック型プルリクエストに対応している？

ベータ版ではドキュメントに記載がない。独立した比較によれば、Originでのスタック型ワークフローはGraphite買収から期待されているものであり、公開済みの機能ではない。

Cursor Originをセルフホストできる？

8月17日のchangelogにもOriginのプロダクトページにも、セルフホスティングの選択肢は記載されていない。OriginリポジトリはCursorがホストし、Enterprise管理者にできるのは利用自体を完全に無効化することだけだ。

大規模にコーディングエージェントを動かすにはOriginが必要？

不要だ。独立したCursorガイドは、エージェントごとに別のworktreeを用意し、差分を小さく保ち、一次レビュー用ボットを使うことで、GitHubやGitLabでも現在このレビューのボトルネックに対処できるとしている。

関連記事：Cursor Router explained