【設計】Cursor Origin は GitHub を置き換えない — 「正」を残したまま、レビューの場所だけ移す設計

この記事でわかること
- Origin は単体でコードをホストできる git forge で、その上で既存リポジトリの入口として GitHub ミラーが用意されていること
- ミラー経路では GitHub が「正」のままだという割り切りと、それが導入の判断を不要にしていること
- GitHub から同期して実測した「入ってくるもの/入ってこないもの」(PR は342本まるごと入るが、Actions のチェックとブランチ保護は入らない)
- 目玉の Code Tour が何をしてくれて、どこで無力になるのか(PR 本文が薄いと何も出ない)
- 「有料プランはデフォルトON」の正確な意味と、いま気をつけておくこと
GitHub で普段プルリクエストを回していれば読めます。手元で試す場合は Cursor の有料プラン(Pro / Teams / Enterprise)が要ります。
2026年8月17日、Cursor が Origin というコードホスティングを公開しました。ひとことで言えば GitHub の対抗馬です。
ただ、実際に触ってみたら「対抗馬」から想像するものとはだいぶ違いました。Origin 単体でコードをホストすることもできるんですが、既存のリポジトリを迎え入れるときは、GitHub を倒しにいかない。「正」を GitHub に残したまま、人が見る場所だけ持っていくという作りになっていました。ここがかなり巧いなと思ったので、自分のブログのリポジトリを実際に同期して確かめた話を書きます。
この記事の要点
- Origin は単体でコードをホストできる git forge。そのうえで、既存リポジトリの入口としてGitHub ミラーが用意されている
- そのミラー経路では GitHub が source of truth のままで、閲覧とレビューだけ Cursor 側に来る。この割り切りが巧い
- 同期すると PR は342本まるごと入ってくるが、Actions のチェックとブランチ保護は入ってこない
- 目玉の Code Tour(AIがレビュー観点を書く)は、PR 本文が薄いと何も出ない。書いた分だけ効く機能だった
- ローンチの3時間半後に GitHub が6時間42分落ちた。出来すぎているが、狙ったものではないらしい
- 有料プランはデフォルトON。ただし「勝手にコードがミラーされる」という意味ではない
ローンチの3時間半後に GitHub が落ちた
先に外堀から。Origin が有料ユーザーに配られ始めたのが月曜の朝で、その約3時間半後に GitHub のステータスページが赤くなりました。VentureBeat の記事によると、6時間42分の全体障害。プルリクエスト・Issue・API のエラー率が20%前後、アーカイブと raw ファイルのダウンロードで50%近く。SAML / OIDC / SCIM といったエンタープライズの SSO も落ちて、Copilot も巻き添えになっています。
GitHub の競合がローンチした日に GitHub が落ちる、というのはさすがに出来すぎなんですが、製品のローンチ日は何週間も前に決まるものなので狙ったものではなさそうです。Cursor の中の人が「もっと早く出すつもりだったけど GitHub が落ちてたので」と自分の会社のローンチを引用ポストしていて、そこがいちばん面白かったです笑
Cursor 公式のポストはいたって淡々としていて、「Origin が本日公開されました。高速で、使いやすく、Cursor と深く統合されています。GitHub からリポジトリを同期すればすぐ始められます」という内容でした。この最後の一文が、実はこの製品の設計そのものなんですよね。
とりあえず同期してみる
cursor.com/codebase を開くと Codebase というタブが増えていて、「Early Beta」のバッジが付いています。Pro プラン以上で使えて、無料プランでは出てきません。
ここで入口が2つあります。+ New で Origin 上に空のリポジトリを新規作成するか、Sync from GitHub で既存のリポジトリをミラーするか。
前者を選んだ場合、GitHub は一切登場しません。https://origin.cursor.com/{owner}/{repo}.git を remote にして普通に push すれば、それで Origin が正です。CLI なら origin repo create でも作れます。つまり Origin は、それ単体で git forge として成立しています。
今回は既存のブログのリポジトリで試したかったので後者を選びました。なのでここから先は、断りがない限り「ミラー経路」の話です。そして、個人的に一番おもしろかったのもこのミラー経路の設計でした。
やることは「Sync from GitHub」を押して、GitHub の組織とリポジトリを選ぶだけ。数分待つと、こうなります。

もう完全に見慣れた画面です。ファイルごとの最終コミットメッセージ、83ブランチ、Go to file、History。GitHub を使ったことがあれば説明が要りません。ここは差別化するところじゃない、という判断なんだと思います。
コード検索も普通に速いです。

何が入ってきて、何が入ってこないか
ここが実際に触らないとわからないところでした。ドキュメントに書いてあることと、見て確かめたことを並べます。
| 対象 | 同期 | 実際に見た挙動 |
|---|---|---|
| コミット履歴・ブランチ・タグ | 入る | 83ブランチがそのまま並ぶ |
| プルリクエスト | 入る(双方向) | クローズ済み342本。本文・コメント・bot のコメントまで丸ごと |
| Issues | 入らない | そもそもタブが存在しない |
| GitHub Actions のワークフローとシークレット | 入らない | PR の Checks 欄は「No checks」のまま |
| ブランチ保護 | 入らない | 「No rulesets protect this repository yet」。Origin 側で作り直す |
PR がここまで丸ごと来るのは正直びっくりしました。2年前の PR を開いたら、当時の Vercel bot と Cloudflare Pages bot のコメントまでテーブルごと再現されていて、しかも右側に「Previews」として当時のプレビュー URL が抜き出されていました。ただの表示ではなく、ちゃんと解釈しているんですよね。

一方で Checks とブランチ保護が来ないのは、移行を考えるなら地味に効いてきます。CI の結果が見えない PR 画面は、レビューの最終判断の場所にはできません。ここを埋めるのが後述のアプリ連携、という組み立てになっています。
設計の核心は、この1画面に出ている
リポジトリの Settings を開くと、こういう図が出てきます。

左が Origin で Mirror、右が GitHub で Source。真ん中に Synced。
これがミラー経路の設計そのものなんですよね。既存のリポジトリを持ってくるときに、GitHub を捨てさせない。 push 先は GitHub のままでいいし、権限も GitHub の read / write をそのまま写す。Origin 側でやるのは、見ることとレビューすること。PR のコメントだけは双方向に流れます。
なぜこれが巧いかというと、移行の意思決定を必要としないからです。ソース管理の乗り換えって、エンジニア組織がやる中でもかなりリスクの高いプロジェクトです。CI も、監査ログも、ブランチ保護も、ツールチェーンの全連携も、全員の手癖も一緒に動かすことになる。early beta の製品にそれを承認する決裁者はまずいません。
でも「読むための2枚目の窓」なら、承認する必要すらないんですよね。試してもタダだし、やめても何も壊れない。そのあいだに、エンジニアが1日の大半を過ごす画面だけが静かに移動する。
そして Settings の Advanced にはこれがあります。

「Detach from GitHub — このリポジトリを GitHub から切り離し、Cursor を source of truth にする」。ボタン1個です。
ミラーとして入り込んで、レビュー体験で気に入られたら、最後にこのボタンを押してもらう。導線としては非常にきれいだなと思いました。ちなみに隣の Delete repository のほうは「GitHub 側のリポジトリには影響しません」と書いてあって、そこは親切です。
目玉の Code Tour と、その正体
さて本題です。PR の差分ビューに Code Tour というタブがあります。押すと、AI がその PR の要約を書いてくれる。

自分の PR で試したら、こう出ました。
<title> だけ、Next.js の metadata template によるサイト名サフィックスを外しています。(中略)確認してほしい点は、ルート側の title.template が本当に %s | kt-tech.blog 相当であることと、記事以外のページがこれまで通りサフィックス付きになることです。「確認してほしい点」まで書いてくるのか、と最初は感心しました。しかもちゃんと日本語です。
ただ、ここで引っかかったんですよね。この PR、本文を書いたのは Claude なんです。AI が書いた説明を AI が要約しているだけなんじゃないか? と。
なので、AI が本文を書いていない古い PR で試しました。
| PR | 本文 | Code Tour の出力 |
|---|---|---|
| #536 | Claude が書いた長文(数値・表つき) | 日本語で要約し、「確認してほしい点」まで書く |
| #196 | 「#195 の対応」の2行だけ(差分は+12行ある) | No matching steps。何も出ない |
| #156 | 「PF関連の追加修正」 | Empty diff と言いながら、その下に2ファイルの差分を表示。ブランチ名から「likely a portfolio feature」と英語で推測 |

差分がちゃんとあるのに「diff が空なのでツアーは作れません」と言い、その真下に差分を出している。early beta らしいバグです。
で、これをどう受け取るかなんですが、自分はむしろ納得したというか。
つまり Code Tour は「PR 本文を書かなくても AI が説明してくれる」機能ではなく、「本文が書けているときに、レビュアー向けに整形し直してくれる」機能なんですよね。材料がなければ何も出ない。当たり前といえば当たり前なんですが、AI 機能の紹介記事だと「差分から自動で」と書かれがちなところなので、ここは自分で試してよかったなと思いました。
裏返すと、PR 本文をちゃんと書く(or エージェントに書かせる)運用とセットで初めて効く。そこが噛み合っているチームには相当効きそうです。
このあたりの機能は、Cursor が2025年12月に買収した Graphite の技術が入っています。スタックした PR を積んでレビューする、あの Graphite です。Origin を Compile 2026 のステージで発表したのも Graphite の共同創業者の Tomas Reimers で、開発も彼が率いています。差分ビューの「Files Viewed」のカウンタとか、いかにも Graphite の作法だなという感じがしました。
CI とデプロイはアプリで埋める
Actions が来ない代わりに、アプリ連携があります。初日に揃っているのは3つ。

注目したいのが Depot の説明文で、「Runs your Actions workflows without GitHub」と書いてあります。既存の GitHub Actions のワークフローを、書き換えずにそのまま走らせる、と。Buildkite も同じくワークフロー互換で、独自のパイプラインを上に乗せられる。Vercel は PR ごとのプレビューとマージ時の本番デプロイです。
つまり Cursor は「ビルドを書き直せ」とは一言も言っていないんですよね。ここも「承認が要らない」設計の一部です。
あと Automations という機能があって、push や PR のイベントでクラウドエージェントを起動できます。エージェントが Origin のリポジトリをクローンして、ブランチを切って、コミットして、PR を出すところまでやる。コードとPRとエージェントが同じ画面にいるというのが、Cursor 側の一番の売り文句です。
なぜ Cursor がコードホスティングを作るのか
背景の数字がわりと説得力あるなと思ったので、いくつか引いておきます(いずれも VentureBeat の記事経由)。
- Cursor 内でマージされた PR の 35% は、クラウド VM で自律的に動くエージェントが開いたもの
- GitHub の Octoverse 2025 では、月あたりのマージ済み PR が 4,320万件で前年比 +23%
- 一方 DORA の2025年レポートでは、AI の利用はデリバリのスループットとは正の相関、安定性とは負の相関
コードを書くことはもうボトルネックではなくて、レビューして統合するところが詰まっている。そして PR の3分の1が人間ではなくソフトウェアから来るようになると、レビューキューは「会話」ではなく「スケジューリング問題」になる。人間のために作られた forge はその前提で設計されていない、というのが Cursor の主張です。
この主張自体は、わりと筋が通っていると思うんですよね。
GitHub 側の事情もあります。LeadDev の集計では2025年5月から2026年4月までにインシデントが257件、うち major が48件。ざっくり週1です。Zig は2025年11月に Codeberg へ移り、Ghostty も今年4月に離脱を表明しています。
気をつけておくこと
ここは短めに、でも書いておきます。
「デフォルトON」の正確な意味。 changelog には「有料プランの全ユーザーに本日から。ただしエンタープライズは管理者がオプトアウトできる」と書かれています。オプトインではなくオプトアウトです。ただし誤解しやすいんですが、これはOrigin という機能が使える状態になるという意味で、リポジトリが勝手にミラーされるわけではありません。自分のケースでも、Sync from GitHub を自分で押すまで一覧は空でした。とはいえ、組織として「自社のコードを新しいホストに置いていいか」を判断していない状態で、押せば置ける状態になっているのは事実なので、そこは分けて考えたほうがよさそうです。
データまわりの規約がまだ無い。 保持期間、保管場所、学習への利用、サブプロセッサ、移行ツール。このあたりが現時点で公開されていません。製品ページは契約ではないので、正本を置く場所としてではなく、GitHub の上に乗る便利レイヤーとして扱うのが今のところ妥当かなと思っています。幸い、アーキテクチャがすでにそうなっているので、そう使う分には何も無理をしていません。
持ち主が変わったばかり。 SpaceX による Anysphere(Cursor の運営元)の買収が8月14日に完了して、Cursor は SpaceXAI という部門の下に入りました。Origin のローンチはその3日後です。エディタとホスティングとモデルを同じ会社が持つ構図になったので、コードの取り扱いをどう決めるのかは、これから見えてくる話だと思います。ちなみに cursor.com の入力欄でモデル名を見たら Cursor Grok 4.6 High Fast になっていて、ああそうかという感じでした。
で、乗り換えるべきか
乗り換えるかどうか、という問いの立て方がそもそも Origin の設計に合っていないんだと思います。乗り換えなくていいというのがこの製品の一番の主張なので。
自分の結論としては、こんな感じです。
- 試すのはコストがほぼゼロ。 ミラーなので壊れないし、やめても GitHub 側は無傷
- 効くのは、PR 本文がちゃんと書かれているチーム。 Code Tour もエージェント連携も、そこに乗っかる機能
- 正本を移すのはまだ早い。 ブランチ保護も CI も作り直しになるし、何よりデータの規約が出ていない
- 個人のリポジトリなら、レビュー画面を1枚増やすくらいの気持ちで置いておくのがちょうどいい
個人的に一番おもしろかったのは、機能そのものより「GitHub を正に残す」と最初に決めたところでした。倒しに行かないことで、導入の判断を不要にしている。強い製品の作り方だなと思います。
そのうえで、Danger Zone にちゃんと「Detach」ボタンが置いてあるわけで...。そこまで含めて設計だな、というのが率直な感想です。
参考リンク
更新履歴
- 公開。
- Origin は単体でもコードをホストできる点を追記。ミラー経路の話を製品全体の性質として書いていたのを修正。


