GitHubでは無理だった——Cursor Originがエージェント時代の新Gitフォージを発表した理由

こんにちは。もるふぉです。

Cursorのエージェントを並列で走らせた翌朝、PR一覧が真っ赤に染まっていたことはありませんか。

マージ衝突、CIの失敗、レビューが追いつかない通知の山——エージェントが仕事をすればするほど、人間の処理が後ろに積み上がっていくあの構造です。

Cursorは2026年6月16日、サンフランシスコのイベント「Compile」で、その詰まりをGit層から解体しにくるGitフォージ「Origin」を発表しました。

なぜGitHubでは足りないのか、この記事で構造から整理します。

Cursor Originとは何か

いきなりデモの数値から話すと、発表ではOriginのスループットとして22.6コミット/秒、世界同期400ms未満という公称値が示されました。

「それ、GitHubと何が違うの？」——ここが本題です。

Cursor Originは、Cursorが新たに構築するGitホスティングサービスです。

公式タグラインは "A git forge for the agentic era"——エージェント時代のGitフォージ、という言い切り。

毎時数十万規模のクローン・プッシュをさばく構成、S3バックアップによる自動フェイルオーバーといった性能・冗長性の指標もあわせて発表されています（Cursor発表値。第三者検証はこれからの段階です）。

「エージェント時代のGitフォージ」というコンセプト

ポイントは「人間のためのGit」ではなく「エージェントのためのGit」だと宣言したところです。

git worktreesを使って複数のブランチに同時にコミットする使い方を想定し、ホスティング側がそれを前提に設計されています。

ここが既存のGitサービスとの根本的な出発点の違いです。

GitHubとの設計思想の根本的な違い

GitHubは2008年に「人間がPRを出して、人間がレビューする」前提で作られたサービスです。

これは悪い話ではなく、当時はそれが正解でした。

Originはその前提を「複数のエージェントが並列で書き、必要に応じて人間がゲートをかける」へ書き換えにきています。

設計の出発点が違う、というのはつまり、後付けのプラグインでは埋まらないということでもあります。

なぜGitHubでは足りないのか——Cursor Originが解決する3つの問題

Cursor 2.0以降は、git worktreesを使って複数のエージェントを並列で動かせます。

便利な反面、既存のGit運用には構造的な負荷がかかります。

エージェントが並列でコミットすると、マージ衝突が発生し続ける

エージェントを5本同時に走らせると、同じファイルに別々の変更が乗ることが普通に起きます。

GitHubのPRフローは「人間が1人ずつ出す」前提なので、衝突解消が下流に積み上がる。

エージェントの生産性を上げるほど、人間がコンフリクトを直す時間が増える——皮肉な構造です。

これはちょうど、工場の自動化ラインを入れたのにピッキング作業だけ手作業のままにした状態に似ています。

速くなった分だけ人の詰まりが目立つ。

Originはここを「並列前提のマージ戦略」で吸収する設計だと説明されています。

CIが落ちても、結局人間が直すことになっている

エージェントがコードを書き、CIが回り、テストが落ちる。

落ちたら誰が直すか——今はほぼ人間です。

エージェントは「落ちたから次のタスクへ」と進んでしまうので、CIの赤が積み上がる。

Originはエージェントがビルド失敗を受け取り、修正コミットを自律で投げ戻すループを前提にしています。

GitHub ActionsとAgent HQで似たことをやろうとしているのは事実ですが、Cursor側は「ホスティング層に組み込む」と一段下のレイヤーで設計してきました。

アドオンで近づけるのと、最初からその前提で作るのとでは、設計の堅さが変わります。

人間向けの差分表示がエージェントには重い

GitHubのDiffビュー、人間が読む分には完成度が高いです。

ただ、エージェントが差分を解釈するとき、HTMLのレンダリング結果ではなく構造化された差分情報のほうが効率的に扱えます。

人間で言えば、文書を読むのに毎回印刷してから読んでいるようなものです。

Originはエージェント向けの差分APIを一級市民として組み込む設計で、私はここがAPIスループットに直結する違いになると読んでいます。

ここまでが「なぜGitHubではなくOriginなのか」の構造的な理由です。

続いて、CursorがなぜわざわざGit層まで降りてきたのか——その戦略的な背景が見えてきます。

Cursor Graphite買収とOriginで見えた縦統合戦略

Cursor Originは単体で意味があるわけではありません。

Cursorは2025年12月にコードレビューSaaSのGraphite買収を発表しており、Compileではその統合戦略を改めて示しました。

これで縦のラインが揃います。

編集（Cursor）→レビュー（Graphite）→ホスティング（Origin）の3層

3層が同じ会社の中で揃うと、エージェントが書いた「意図」をPRやコミットメッセージの先まで持ち越せるようになります。

GitHubに出した瞬間に文脈が切れる、という今の構造的損失が消える設計です。

エディタからGitホスティングまで、「Cursorの文脈」が一本の糸で通る。

想像してみてください——エージェントが書いた変更の意図が、レビュー画面でも、次のエージェントの参照先でも、そのまま生きている状態を。

エージェントの文脈がコードの外に漏れない設計

エージェントが「なぜこの変更をしたのか」を、コードコメントだけでなく構造化メタデータとしてGitに持たせる。

レビュー側もそれを読む。

次のエージェントもそれを参照する。

文脈が3層を貫通するわけです。

これがOriginの本当の狙いだと、私は読んでいます。

Cursor Origin登場でエンジニアの実務はどう変わるか

今すぐ使えるわけではない（Fall 2026・ウェイトリスト段階）

Originの提供は2026年秋予定です。

現状はウェイトリストのみで、価格・早期アクセス枠の詳細は未公開。

GitHubから今すぐ移行する話ではありません。

GitHub側も「Agent HQ」構想（GitHub Universe 2025発表）で独自の道を進めており、エージェント統合の競争は始まったばかりです。

移行を急ぐより、エージェント前提の開発設計を始める時期

Originを待つ間に、今のGitHub上でも始められることが3つあります。

1つ目は、Composerの並列実行を試して自分のリポジトリで衝突がどこで起きるかを把握すること。

「どこが詰まるか」が分かれば、Originが来たときの移行判断が格段に速くなります。

2つ目は、ブランチ戦略を「人間1名前提」から「エージェント複数前提」へ書き換えてみること。

これは設計の習慣を変える話なので、ツールが変わる前にやっておく価値があります。

3つ目は、CI失敗時の自律修正をどこまでエージェントに任せるか、ガードレールの設計を始めること。

Originが前提にしている「エージェントが修正コミットを自律で投げ戻す」を、今の環境で部分的に試しておく、ということです。

秋にOriginが来たとき、この3つをやっていた人とそうでない人で、移行コストがかなり変わるはずです。

まとめ——CursorがGitのレイヤーに降りてきた意味

Cursor Originの発表で、Cursorはエディタからレビュー、そしてGitホスティングまで一気通貫で降りてきました。

「AIエージェントがコードを書く」の次に来るのは「AIエージェントがGitを使う」だった——という流れが、Origin発表でようやく言語化されたと感じます。

エディタとGitフォージが同じ文脈を共有するのが当たり前になったとき、PRレビューの意味そのものが変わるはずだと、私は見ています。

エージェント前提の開発フローを、今のうちに少しずつ手元で試しておくことが、秋の移行判断を楽にする一番の近道です。

最後まで読んでくれてありがとうございます。

よければXもフォローしてもらえると嬉しいです → X(@morphox_ai)