CursorがOriginでGitHubを置き換えようと狙う？

CursorがGitHub三種を移植、さらにAgentも同ページに詰め込む

2026年8月17日、Cursorの親会社AnysphereがOriginコードホスティングサービスのアーリーベータを公開。リポジトリ、PR、コード閲覧、GitHub双方向同期を一気に展開した。

Originは初日に四つを投入した。リポジトリ、PR、コード閲覧、GitHub双方向同期。すべての有料ユーザーが利用でき、エンタープライズ版は管理者が有効化する必要がある。新規リポジトリ作成はまず左の新しいCodebaseタブを開く。ユーザーが初めてリポジトリを作るとき、codebase全体に名前を付ける必要があり、その名前は全リポジトリのURLに書き込まれる（形式はcursor.com/codebase/あなたの名前）。CLIが対応するclone/pushコマンドを提示し、ローカルコードをpushすればOriginにホストされる。

GitHubリポジトリはCursorに同期でき、自ホストリポジトリの隣に並ぶ。リポジトリアイコンで「Cursorが自前ホスト」「GitHubから取り込み」を区別できる。同期は片方向ミラー——ソースはGitHubに残り、pushもGitHub経由、Cursor側は読み取り専用コピーをリアルタイム更新する。PR体験はGitHubを踏襲：タイムライン、commits、checks、ファイル変更、diff、コメント、マージがすべて揃う。Cursorでコメントを書けばGitHubへ書き戻され、GitHub上の返信も数秒でCursorに表示される。GitHubで自分にアサインされたPRレビューは、Cursor側で直接閲覧・マージでき、元のプラットフォームに戻る必要はない。

レイヤー下のつなぎ目となるのがAgents入口：コード、PR、Agent（Agent：タスクを自動実行するAIアシスタント）が同一ページに圧縮されている。

コード閲覧中にそのままCursorに質問でき、回答、コード修正、PR更新、新規ブランチpushまで実行可能。連携アプリ群にはVercel、Depot、Buildkiteが接続済み——Vercelが各PRのプレビューデプロイを担当し、DepotとBuildkiteがCIを回す。GitHub Actionsパイプラインはそのまま動作する。

OriginはGitHubをデータ基盤に降格させた

Originの本当の売りは、Agentが同一ページ内で「コード読む→コード書く→PR出す→プレビュー確認」まで完結できる点にある。

CursorはOrigin内でGitHubリポジトリの骨格を再現した：repos、PR、code browsing、GitHub同期——公式changelogはこれら4つを「the essentials」と位置付けている。だが再現は表面上の話に過ぎない。

Cursorは各repoにAgentを一つ紐付けている。repoページで任意のファイルを開けば、直接質問でき、コード修正、ブランチpush、PR更新まで可能。リポジトリはもはや人間の协作のための中立的な器ではなく、Agentの作業台になった。

GitHub同期は双方向で機能する。OriginはGitHubリポジトリのコピーを取り込み、閲覧・検索・pullはこのローカルコピーで処理。pushはGitHubへ戻る。そこがsource of truthだ。

PR同期は秒単位で双方向書き込み——Cursorで書いたコメントは即座にGitHubに現れ、逆にGitHubで自分にアサインされたレビューもCursorから直接マージできる。権限モデルはそのまま継承：同期されたリポジトリでGitHubを読める人は、Cursorでも読める。

フロントエンドが代理し、バックエンドがGitHubという設計により、GitHubはデータ基盤に降格し、Cursor自身のUIがデフォルト入口に昇格した。開発者が毎日開くのはgithub.comではなく、cursor.com/codebase/acme-corpになる。

リポジトリ、PR、Agentが同じタブに共存する。ウィンドウ切り替えが減るのは些細なことで、書き換えられるのは「コードがどこで書き換えられるか」という行為の帰属先だ。

CI（継続インテグレーション。コミットごとに自動でテストとビルドを実行）とデプロイはエコシステムに任せる。OriginのAppsタブにはすでにVercel、Depot、Buildkiteの3社が接続済み：Vercelが各PRに自動でプレビュー環境を立て、マージで本番反映、DepotとBuildkiteがGitHub Actionsのワークフローを実行し、Buildkiteはさらに独自のnative pipelineも回す。公式は「with more coming soon」とだけ書き、スケジュールもGitHub Actions runnerやCodespacesの接続可否にも触れていない。Origin自体にはCI/デプロイ機能は存在しない——そのチェーンを専業ベンダーに外注し、「Origin内ワンクリックで接続済み」というパッケージにまとめている。

各repoのsettingsページから設計の重みが見える：GitHub同期ステータス、権限、接続済みappが確認でき、権限モデルはGitHubの読み書きアクセスを継承。Originは8月17日にアーリーベータとして全有料プランに開放、エンタープライズ組織は管理者がオプトアウト可能。まずは骨格から、Agent-native featuresはこれから。

OriginはGitHubのケーキを奪わない、ケーキの型を書き換えている

Originが初日にできることは、GitHubにすでに備わっている。だがchangelogの一行目には「designed for agent scale」とある。方向は明確だ——このホスティングの権限モデルは最初から人間向けに書かれていない。

多くの解説はここで止まる：Cursorがついに自前のGitHubを持った、と。だがOriginのchangelogはリポジトリ、PR、コード閲覧、GitHub同期の4つを最初の文に並べ、すぐ後に「Agent-native features ship soon」と続ける。先に届くのはGitHubに早已あった基礎部品、Agentネイティブ能力はまだ先。意図的に最もGitHubらしい部分を最初に出したアーリーベータは、布石を打っている。

判断点はここにある。Originの現在の権限体系——読み、書き、PRコメント、マージ——はほぼGitHubと一対一対応だ。だが初日から「Ask Cursor questions about code you're browsing」ボタンを全リポジトリページに埋め込んでいる。Agentは回答、コード修正、PR更新、ブランチpushの4つを同一ページでこなす。GitHubはこの4つをissues、PR、Actions、Codespacesの4製品に分散している。GitHubはコード閲覧者を人間と仮定しUIを人間の認知リズムで分割、Cursorはコード操作主体をAgentと仮定し操作界面を1枚のパネルに平坦化している。

Originの差別化は別の場所にある：AI Agent（タスクを自律実行できるAIプログラム）が人間と同等の「書く・直す・出す・マージする」権限を持つとき、Gitの権限モデルは作り直しになる。リポジトリはそのための器に過ぎない。

だからこそOriginはGitHub同期を「pushしてもGitHub側は元のまま」と設計した。AnysphereはGitHubユーザーを引っ越させる必要はなく、既存Cursorユーザーに選択肢を一つ増やせばいい：社内プロジェクトはOriginにホストし、元からあるOSSプロジェクトはGitHubに残す。アーリーベータは全有料プランに開放、ただしenterpriseは除外——この除外順序はターゲット顧客を物語る。企業内にGitHub代替品を導入できない開発チームに、まず個人有料ユーザーと企業外案件で試させる。

堀の観点から見ると、GitHubの壁垒はネットワーク効果——OSSプロジェクト、サードパーティ統合、CI（継続インテグレーション。コードpush後に自動でテストとビルドを実行）エコシステム。

Originの現在のCI統合（Vercel、Depot、Buildkite）は明確に「既存のGitHub Actions workflowsを回す」と書いている——新しいCIエコシステムを作っているのではなく、既成のGitHub Actionsチェーンに繋いでいる。

Vercelの経路は特に注目に値する：各PRに自動でプレビューデプロイが立ち、直接コメント可能、mergeで本番反映。これはGitHub PRレビューのサイクルを「diffを見る」から「動作するページを見る」へと圧縮し、フロントエンドプロジェクトのレビューコスト構造を書き換えた。

Originの売りはAgentワークフロー、リポジトリではない

Originは自らを「agent規模向けに設計」と位置付ける——リポジトリホスティングは土台に過ぎず、価値があるのはAIがその場でコードを書き、ブランチをpushし、PRをマージするという新ワークフローだ。

プロダクトの順序を見れば優先度が読める。リポジトリ、PR、コード閲覧、GitHub同期は「基本盤」、公式はessentialsと呼ぶ；agentネイティブ機能はship soonとされ、告知の最後に置かれている。

元のリポジトリはGitHubに残し、Cursor側はミラーを維持、書き込みはGitHubへのみ戻る。并存は移行ハードルを下げ、まずは地盘を固め、後で刈り取る。

ホームページにはSOC 2 Certifiedバッジが掲げられているが、SOC 2は企業全体のセキュリティをカバーするもので、リポジトリ単位のAgent操作の監査粒度は別問題。Origin告知にはAgent操作ログへの言及も、「ブランチpushごとに人間確認を必須とする」仕組みへの言及もない。

GitHubから移ってくる企業にとって、このコンプライアンス部分は宙に浮いたまま。Code ReviewとCLIはすでに別プロダクトラインとして独立しており、Originは明らかにこれらの能力を同一ブラウザフローに取り込みに行く：コード読み、コード書き、コードまとめ。

トラック統合はすでに始まっている。GitHubのCopilotがリポジトリと深く紐づいているのも同方向のシグナル。CursorはOriginでagent-firstコードホスティングの位置取りを行い、エディタの外にもう一つの戦線を引く。

検証ポイント：Origin告知の「Agent-native features ship soon」がいつ具体的機能を出すか。3ヶ月以内にAgentが自動でコードを書き、PR提出までのend-to-endフローを出せば、ポジショニング判断は成立；曖昧なままなら、OriginはGitHubの同期ミラーレイヤーに留まる。

もう一つの観察点はセルフデプロイオプションの動き。Anysphereのホームページには現時点でSOC 2のみ掲載、FedRAMPやセルフデプロイへの言及はない。金融・政企顧客の調達にはこれらの资质が必要。「企業組織管理者は無効化を選択できる」は既存顧客への退出権であり、新しいデプロイモデルではない。

GitHub同期の双方向性は仕込まれたフックだ：企業はすぐにはリポジトリを移さず、両侧并立が続く。Origin告知の「GitHub stays the source of truth」は現状記述であり、約束ではない。AnysphereはAgent機能成熟後にユーザーがより多くの日常操作をCursor側に移すことを賭けている。

実践チェックリスト：Originを5ステップで検証する

Originはすでに全有料版にアーリーテストを開放、エンタープライズ版は管理者が有効化する必要がある。下記の手順は情報源にすべて入口が明記されている。

本番リポジトリをいきなり移さないこと。CodebaseタブのUI案内に従い、既存プロジェクトと重複しない小さなリポジトリを新規作成し、ローカルのテスト用プロジェクトをpush、clone、push、PRフローを一通り確認する。CursorのこのステップでCLIコマンド群が提示されるのでそのまま実行、URLはcursor.com/codebase/あなたの名前という形式になる。

すでにGitHubリポジトリを持っている人は、「托管」より先に「同期」を試す。CodebaseタブでGitHubに接続、組織を選び、いくつかのリポジトリを同期。2点を確認：ファイルを一つ変更し、Cursor側が数秒以内に更新されるか；CursorのPRにコメントを書いたとき、GitHub側にも同期されるか。公式が約束する「秒単位」双方向同期は目視で検証可能。

3番目はアプリ連携。Vercel統合はAppsタブから直接クリックでき、各PRにプレビューデプロイが立ち、マージで本番反映。CI側はDepotとBuildkiteの二者択一、既存のGitHub Actionsワークフローをそのまま回せる。ここまでできれば、「コード—Agent—デプロイ」最短経路が走る。

Originが本当に売りたいワークフロー「Agentが代わりに書き、PRを自動で出し、マージで自動デプロイ」は、情報源によればApps拡張に骨格はできあがっているが、Agent側は予告段階。チェックリスト4は現能力を検証、5は未来を注視する。その中間の差分は公式リリース待ちで判断する。チーム管理者はバックエンドでデフォルト無効化になっていないか先に確認しておくこと。