Cursor がコードホスティングに参入。Origin が全有料プランへ early beta で提供開始

要約

Cursor がコードのホスティングを始めました。「Origin」という名前で、2026-08-17 から全有料プランに early beta としてロールアウトされています。Enterprise 組織は管理者がオプトアウトできます。

公式は Origin を「エージェントのスケールに合わせて設計した」と位置づけています。初期スコープは意図的に絞られていて、リポジトリ、プルリクエスト、コードブラウジング、GitHub 同期の4点だけです。エージェントネイティブな機能は「まもなく」提供するとしています。

入口は新設の Codebase タブです。+New でリポジトリを作ると CLI のインストール手順が表示され、clone するか既存プロジェクトを push すれば Origin 上にコードが載ります。最初のリポジトリを作るときに codebase 名を決め、それが以降すべてのリポジトリの URL に入ります（cursor.com/codebase/<name>）。

**既存の GitHub リポジトリは併存できます。**GitHub を接続して org を選ぶと同期可能なリポジトリが一覧され、選んだものが取り込まれます。ここが重要なのですが、この同期は対称ではありません。Origin 側のコピーは real time で更新され、browse・search・pull に使えますが、push は GitHub に向かい、GitHub が source of truth のままです。リポジトリ名の横のアイコンで、Cursor がホストしているものと GitHub 由来のものを見分けます。同期はいつでも解除できます。

プルリクエストは各リポジトリに付きます。タイムライン、コミット、チェック、変更ファイルが見え、diff をレビューしてコメントを付け、マージできます。同期リポジトリの PR ではコメントが双方向に同期します。Cursor で書けば GitHub に投稿され、GitHub 側での返信やリアクションも数秒で Cursor に出ます。GitHub でアサインされたレビューを Cursor 側で完了してマージすることもできます。

アプリ連携も同時に始まっています。Vercel / Depot / Buildkite が利用可能で、Vercel を接続するとリポジトリの Apps タブ経由で PR ごとにプレビューデプロイが付きます。CI は Depot と Buildkite が担当し、両方とも既存の GitHub Actions ワークフローをそのまま実行できます。Buildkite はネイティブパイプラインも動きます。

何が変わったか

• Cursor 上でリポジトリをホストできるようになった（CLI 経由の clone / push）
• 新設の Codebase タブが Origin リポジトリの入口になった
• GitHub リポジトリを取り込んで real time 同期できる（push は GitHub 側、GitHub が source of truth）
• リポジトリごとに PR があり、レビュー・コメント・マージができる
• 同期リポジトリの PR コメントは Cursor と GitHub で双方向同期
• 閲覧中のコードにエージェントが質問へ回答し、変更・PR 更新・ブランチ push まで実行できる
• Vercel（PR プレビューデプロイ）、Depot / Buildkite（CI）と連携できる
• リポジトリ単位で同期状態・アクセス権・接続アプリを設定できる

業務インパクト（一般企業向け）

**コードの置き場所は、組織で最も動かしにくい決定のひとつです。**そこに選択肢が増えた、というのが今回の本質です。

ただし**「GitHub から Origin へ移行する」という読み方は、現時点では正確ではありません。**同期が非対称だからです。push は GitHub に向かい、GitHub が source of truth のままです。つまり Origin 側は「読める・検索できる・エージェントが触れるコピー」であって、正本ではありません。移行ではなく併用が、初期スコープで想定された入り方です。

この設計は妥当だと思います。コードホスティングの乗り換えは、リポジトリを移すだけでは終わりません。CI、デプロイ、権限管理、監査ログ、外部連携がすべてぶら下がっています。いきなり正本を移させないという判断は、導入のハードルを下げる方向に働きます。

では何のために使うのか。公式の言い方をそのまま取るなら「エージェントのスケールに合わせて設計した」ところにあります。コード、PR、エージェントが同じ場所にある、という状態を作るのが狙いです。これまでは、エージェントに作業させるたびにリポジトリを clone し、PR は GitHub で見る、という往復が必要でした。Origin はその往復をなくします。

**Enterprise 組織には判断が発生します。**early beta が全有料プランに配られるなかで、Enterprise だけは管理者がオプトアウトできる建て付けです。裏を返せば、何もしなければ有効になります。自社のコードが Cursor 側にコピーされる状態を許容するかは、セキュリティ部門の判断が要る種類の話です。同期は個々のユーザーが選んだリポジトリについて起きるので、組織として方針を決めないと、現場判断で同期が始まります。ここは早めに詰めておくべきでしょう。

もうひとつ実務的に効くのが、**「同期リポジトリを閲覧できるのは、そのリポジトリに read / write 権限を持つ人」**という点です。GitHub 側の権限がそのまま効く設計なので、権限モデルを二重管理する必要はありません。ここは導入判断の材料になります。

CI 連携が Depot と Buildkite の両方で既存の GitHub Actions ワークフローを実行できるのも見逃せません。CI を書き直さずに済むということです。CI の移植は移行コストの大きな部分を占めるので、そこを回避できる設計にしてある、と読めます。

副業・個人活用視点

個人で使うなら、まず**「GitHub を置き換えるものではない」**と理解しておくのが出発点です。有料プランなら今日から触れますが、正本を移す話ではありません。

実際に効くのは、エージェントに作業させる往復が減ることでしょう。コードを見ながら質問して、その場で変更させて、PR を更新して、ブランチを push するまでが同じ画面で完結します。個人開発では PR レビューの相手が自分しかいないことも多く、GitHub と Cursor を行き来する手間がまるごと消えるのは体感で分かる差になります。

Vercel 連携も個人利用と相性が良いです。PR ごとにプレビューデプロイが付く環境を、設定らしい設定なしで手に入れられます。個人開発でプレビュー環境を整えるのは面倒な部類の作業なので、Apps タブから接続するだけで済むなら使う価値があります。

一方で early beta である点は忘れないでください。「essentials から始めている」と公式が明言している段階です。エージェントネイティブな機能はこれからですし、初期スコープに入っていないもの（Issues、Wiki、Actions 相当、細かい権限設定）は現時点で存在しません。趣味のプロジェクトで試して、業務の正本は GitHub に置いたままが無難な入り方です。

案件として拾うなら、**「エージェント前提の開発フローをどう組むか」**が切り口になります。Origin の登場は、コードホスティングがエージェントの作業場として再設計され始めた、という流れの一例です。この流れを説明できると、ツール選定の相談に対して単なる比較表以上の話ができます。

発信のネタとしては、GitHub 同期の非対称性が具体的で書きやすいでしょう。「同期」と聞いて双方向を想像した人は、実際に触って初めて片方向だと気づきます。どこまでが Origin で完結し、どこから GitHub に戻るのかを実地で切り分けた記事は、導入を検討している人に読まれます。