Cursor Origin徹底解説 — 単位はPRではなく「change」、エージェント前提のコードホスティング

はじめに

Cursor が独自のコードホスティングサービス Origin を発表した。Hacker News で 269 ポイントを集め、同日中に日本語の検証記事が複数出るという反応の速さだった。

「また GitHub クローンか」と流したくなるニュースだが、実際に触った報告を読むと様子が違う。基本単位が Pull Request ではなく「change」という版付きの差分になっている。これは UI の趣味の問題ではなく、「コードを書く主体が人間からエージェントに移りつつある」という前提を、データモデルの層に埋め込んだ結果として出てきた差分だ。

本記事では、Origin が GitHub と何を変えたのかを CLI の挙動レベルまで追い、なぜ PR という単位がエージェント前提だと苦しくなるのかを整理する。そのうえで、現時点で導入判断にあたって確認すべき「まだ埋まっていない穴」も具体的に挙げる。

ローンチと、あまりに出来すぎたタイミング

Origin の提供開始は 2026年8月17日。有料プラン（Pro / Teams など）ユーザーに早期ベータとして順次展開され、エンタープライズ組織は管理者がオプトアウトできる形になっている。Cursor デスクトップに新設された Codebase タブが入り口で、リポジトリごとに cursor.com/codebase/<name> の URL が割り当てられる。

そして同じ 8月17日、GitHub が大規模障害を起こしている。13:40 UTC 前後から劣化が始まり、API Requests・Actions・Webhooks・Issues・Pull Requests が数分刻みで連鎖的に落ちていった。Web と API のエラー率はおよそ 20%、アーカイブや raw コンテンツのダウンロードに至っては約 50% が失敗していたと報告されている。16:59 UTC に主要 7 サービスの復旧が宣言されたが、Copilot はこの時点でもまだ Major Outage のままだった。

競合のコードホスティングが発表された当日に GitHub が数時間不安定になる、という絵面ができてしまった。VentureBeat がこの符合を見出しに取ったのも無理はない。もっとも、この偶然を抜きにしても Origin の設計は単体で検討に値する。

設計の核 — 「change」は PR と何が違うのか

GitHub の PR は、ブランチの上に積み上がったコミット列に対する参照だ。ブランチに push すればその PR の中身は書き換わる。「レビューしている対象」と「今のブランチの先端」は、常に同じものを指してしまう。

Origin はここを切り離す。ハンズオン記事によれば、origin pr create を実行した時点で head と base の SHA が記録される。以後の更新は origin pr refresh で新しい version snapshot として切られ、同一 SHA なら版は増えない。レビュアーは --change-version でどの版を見ているかを指定できる。

つまり、「レビュー中の版」と「最新版」が別物として並存する。エージェントが 10 分の間に 5 回コードを直しても、レビュー対象は静止したままにできる。GitHub で「レビューコメントを書いている最中に force-push されて行がずれた」という経験があるなら、この設計が何を解こうとしているかは伝わるはずだ。

周辺の既定値も、同じ方向を向いている。

draft が既定 — 作成時は自動的に draft になり、origin pr ready で初めて公開される。エージェントに大量の試行を切らせる前提なら、「とりあえず出す」がデフォルトでレビュー待ち行列を汚さないほうが自然だ
stackable が前提 — --stack-on で親 change の head を base に指定し、小さな変更を積み上げる。Graphite 系の stacked diffs の発想で、巨大な 1 本の PR を避ける
自動 snapshot — push を検知して version が切られるため、refresh を忘れても履歴が壊れない
Code Tour — Web UI の Changes タブに、Overview・Review focuses・セクション分割された diff が自動生成される。ファイル名順ではなく「理解する順」に diff を歩かせる仕掛けだ

Code Tour は特に思想がはっきりしている。エージェントが変更を量産したとき、律速になるのは人間のレビュー帯域だ。そこに LLM の解説を挿し込んで圧縮しにいっている。ただし前掲の検証記事も指摘するとおり、これは外部 LLM が生成した要約であり、もっともらしいが誤っている解説が混ざりうる点は割り引く必要がある。

エンジニアへの影響 — 今すぐ移行すべきか

結論から言えば、現時点では「GitHub を正本に置いたままミラーとして使う」以上の踏み込みは勧めにくい。理由は機能の欠落と、規約の空白の 2 つだ。

まず機能面。Origin には Issues がなく、GitHub Actions 相当の実行基盤も自前では持っていない。CI は Buildkite や Depot を Apps 経由で接続する構成になる。既存の .github/workflows の YAML 資産は持ち込め、結果は origin pr checks で確認できるが、実行そのものは外部に依存する。加えて origin pr review --request-changes が未実装で、変更要求は origin pr thread（list / reply / resolve / reopen）にコメントを残し、承認を保留してマージを止める運用になる。リポジトリは Internal / Private のみで公開設定にはできず、CLI はネイティブ Windows 非対応（macOS / Linux、WSL は可）だ。

運用上の落とし穴もある。既存リポジトリに Origin を足すとき、リモート名を origin にすると Git の tracking が変わってしまう。git remote add cursor https://origin.cursor.com/... のように別名を切り、以後 git push cursor main と行き先を明示するのが安全だ。ツール名の origin と Git の慣習的リモート名 origin が衝突するのは、正直なところ命名の失敗だと思う。

そしてもう一つ、デフォルト値の危うさが報告されている。draft のうちは設定なしで「Mergeable: no」とブロックされるが、ready にすると checks が一つもない状態で「CI passing: yes」と表示される。本番につながる App を接続する前に、ruleset で承認必須を先に設定する順序が要る。origin pr merge --auto による自動マージまで含めると、ガードの設定漏れがそのまま本番反映につながりかねない。

より重いのは規約面だ。本記事の執筆にあたって Cursor の公開ドキュメント（Data Use & Privacy および Privacy and Data Governance）を確認したが、2026年8月19日時点で、Origin およびコードホスティングに言及した記述は見当たらなかった。既存の記載は Privacy Mode（オンで学習利用なし、Enterprise はデフォルトオン）やコードベースインデックス、ファイルキャッシュの扱いについてのものだ。

これは「危険だと確認された」という話ではなく、「Origin ネイティブに置いたコードの保持期間・学習利用・サブプロセッサについて、まだ明示的な取り決めが公開されていない」という状態を指す。GitHub からミラーしたリポジトリは GitHub 側の規約が正本として効き続けるため、この空白の影響を受けにくい。

したがって実務的な落としどころはこうなる。受託案件のコード、顧客データを含むテストフィクスチャ、規制対象のコードは、当面ミラーモードに留める。 Origin ネイティブへの完全移行は、Origin 固有のデータ規約が公開されてから判断すればいい。逆に、個人の実験リポジトリやエージェントに大量に試行させるサンドボックスであれば、version snapshot と stacked change の使い勝手を今のうちに評価しておく価値は十分にある。

まとめ

Origin は 2026年8月17日、有料プラン向けの早期ベータとして提供開始。奇しくも同日、GitHub が半日近い大規模障害を起こした
基本単位は PR ではなく、head/base の SHA を記録した版付きの change。version snapshot により「レビュー中の版」と「最新版」を分離できる
draft 既定・--stack-on による stackable・Code Tour という設計は、いずれも「エージェントが変更を量産し、人間のレビュー帯域が律速になる」前提から逆算されている
一方で Issues なし、Actions 相当の実行基盤なし、request changes 未実装、公開リポジトリ不可と、欠落は多い。ready 後に checks ゼロで「CI passing: yes」になる挙動には ruleset での先回りが要る
執筆時点で Cursor の公開データ規約に Origin への言及がないため、業務コードはミラーモードに留めるのが妥当

Origin が本当に面白くなるのは、diff をテキストではなく構造として扱い、コンフリクトを意味的に解決できるようになった段階だろう。今回のリリースはそこまで届いていない。ただ、「レビュー対象を版として静止させる」という一点だけでも、エージェントに書かせる開発の実感にはかなり近い。GitHub がこの単位を追ってくるかどうかが、次の見どころになる。

今日のその他のニュース

Docker Desktop が docker container cp の脆弱性 CVE-2026-17106 を修正 コピー先ディレクトリ外への書き出しを許す destination-escape の脆弱性。CI やスクリプトで docker cp を使っている環境は更新を優先したい。Enhanced Container Isolation 有効時に kind クラスタが再起動後に復帰しないバグも同時に修正。

Mojo がオープンソース化 Python 互換を掲げる高速言語 Mojo がついに OSS 化。性能面の評価とは別に、クローズドであること自体が採用の最大の障壁になっていた言語なので、エコシステム形成の転換点になりうる。

Flutter 3.44 リリース、dart2wasm は dart2js の 2.6〜4.4倍 Android の Hybrid Composition++、iOS/macOS での Swift Package Manager デフォルト化、Impeller の Vulkan 改善を含むメジャーリリース。同週の「WebAssembly Week」では CHIP-8 エミュレータのベンチマークで dart2wasm が dart2js の 2.6〜4.4倍という実測も出た。SPM デフォルト化はビルド構成に影響しうる。