新智元報道
今日、世界中のプログラマーが一斉に「不条理劇」を経験した。
アメリカ東部時間午前9時40分、GitHubが全面麻痺し、Copilotも連鎖して全線機能停止に陥った。
丸7時間にわたり、コアサービスの麻痺状態は3時間にも及び、プログラマーたちは仕事が止まり、コードはプルできず、AIツールも使えない状態になった。
折しも今日、Cursorが正式にGitHubへ宣戦布告した！
正式にSpaceXAIに合併した後、 прежняяチームが新たな「コードホスティングプラットフォーム」Originを発表した。
Originとは何か、要点をまとめると以下の通りだ：
- 位置づけ：Agent時代に特化して設計されたGitコードホスティングプラットフォーム。Cursorエディターと深く統合されている。
- コア機能：スタック型プルリクエスト（PR）、マージキュー、マシン可読なレビュー状態、MCPプロトコル対応、イベント駆動型自動化。
- 互換性：GitHubとの双方向リアルタイム同期を実現し、既存のワークフローはそのまま維持できる。
本日より、Originのベータ版はPro/Teams/Enterpriseの有料ユーザー全員に開放される。
もともとCursorはVS Codeを打倒しようとしているだけだと思われていたが、今のところGitHubこそが真の「最終的な獲物」であることが明らかになった。
ほぼ同時刻、米国マイクロソフトの株価は3％以上下落し、瞬時に1120億ドル超が蒸発した。
Cursor版Github、ついに公開
Originは「Cursorのクラウドにコードのコピーが保存されている」わけではなく、完全なgitホスティングプラットフォームである。
初期ベータ版でも、その対応範囲は非常に広い：
リポジトリの作成、標準的なgitを使ったclone/push/pull、GitHubからのリポジトリ同期、ブラウザー上でのコードの閲覧と検索、PRの作成、レビュー、マージ、権限管理などが可能だ。
GitHubのコアとなる一連の操作を、最初から作り直したことになる。
使い方も非常にシンプルで、新しいCodebaseタブで「+New」をクリックしてリポジトリを作成する。
ページにはCLIのインストール方法や、ローカルプロジェクトをプッシュする手順がそのまま表示される。
初回にcodebaseにつける名前は、各リポジトリのURLの一部になる。例えば cursor.com/codebase/acme-corp のようになる。
AIによる自動マージ、人間のレビューすら不要に
GitHubと同様に、Originでも各コードリポジトリにPRが存在する。主な注目機能は以下の3点だ。
スタック型PR
スタック型PRは、大きな変更を複数の小さなPRに分割し、依存関係に従ってスタックすることを許可する。Originは可視化された依存関係図でこれを表示する。
これはAgentにとって極めて重要だ。Agentは本来的に大量のコードを一括で変更することを好み、一度に50ファイルを変更することも日常茶飯事だ。すべてを1つのPRに詰め込むと？人間のレビュアーは関連ページを見ただけで頭を抱えるだろう。スタック型PRはこの問題を分解してくれる。
マージキュー
あるリポジトリで10個のAgentがそれぞれコードを変更し、それぞれがPRを提出し、CIがすべてグリーンになったとしよう。
問題はここだ：どれを先にマージするのか？1つマージした後、残り9つのテスト結果は信用できるか？
従来のGitHubでこの状況を処理するのは非常に苦痛で、マージコンフリクトやCIの再実行、何度もrebaseを繰り返すことになる。Originのマージキューは自動的に並べ替えとコンフリクトの検出を行い、メインブランチが常にCIグリーンであることを保証する。
さらに驚くべきは、数十ファイルにまたがるコンフリクトブランチに対して、Originはマージレイヤーに直接組み込まれたAIエンジンで自動的にコンフリクトを解決し、人間の介入すら不要にする点だ。
マシン可読なレビュー状態
GitHubのレビュー状態は本質的に人間が見るためのもので、緑のチェックマークとコメント欄のテキストに過ぎない。
AgentがPRをマージできるかを判断するには、コメントの内容を解析するしかない。Originはレビュー状態を構造化されたAPIにする。Agentが直接読み書きでき、推測する必要がない。
ボタン一つでGitHubから完全移行
最も重要なのは、古いプロジェクトを移動させる必要もなく、OriginはGitHubリポジトリの直接ミラーリングをサポートしている点だ。
gitの履歴、ブランチ、タグがすべて引き継がれ、PRは双方向で同期することも可能だ。
同期した直後は、GitHubが依然として権威あるデータソース（source of truth）となる。
簡単に言えば、同じコードは複数の場所に存在できるが、最終的な決定権を持つものが一つなければならない。意見が分かれた時にどれを正とするか、CIはどこから引くのか、本番デプロイはどれを適用するのか。
過去20年間、世界中のほとんどのチームにとっての「権威あるデータソース」はGitHubに握られていた。
今、Originはこの構図を完全に覆した。
「Detach from GitHub」をクリックするだけで、Originが主導権を握り、真の「コードの本拠地」になるのだ！
これはつまり、GitHubの上にCursorの皮を被せたわけではない。彼らは本当に自身の「基盤」を構築しているのだ。
今回、OriginはさらにAppエコシステムを接続し、第一弾としてVercel、Depot、Buildkiteを導入した。
Vercelは各PRのプレビューデプロイの自動生成を担当。DepotとBuildkiteはCIを担当し、この2つはGitHub Actionsの既存のworkflowをそのまま実行できる。
Agentを走らせるための基盤
これだけでなく、OriginはMCPをネイティブでサポートしており、AgentはAPIを呼ぶのと同じようにプラットフォーム全体（forge）を駆動でき、IDEに限定されない。
性能のデータについて言及しよう。これはAgentのために提示されている。
1時間に296,000回のclone、81,000回のpush、1秒間に22.6回のcommit、世界的な同期の遅延は400ミリ秒未満、自動フェイルオーバーは10ミリ秒。
1秒間に22回のcommit。一聴すると馬鹿げているように思えるが、Agentの軍団にとっては必要十分な数字だ。
コードを書く主力は人間ではなくなった
CursorがOriginを開発した根本的な理由は、GitHubがAgentのスピードに追いつけなくなっているためだ。
今年3月、Truellはある社内数字を公表した：CursorでマージされたPRのうち、35%〜40%がクラウド上の仮想マシンでAgentが自律的に完成させたものだという。
言い換えれば、Agent自身がブランチを切り、自らコミットし、自らPRを出している。
対照的に、GitHubの2008年に設計されたワークフローは、本質的に「人」のために作られた。
一人がコードを書き終え、一二人にレビューを依頼し、マージの順番を待つ。そのリズムは時間単位、あるいは日単位である。
だが当然、Agentはこのリズムには従わない。十数個が一斉に一つのリポジトリに殺到し、その時間のスケールは秒単位だ。
Originはこの現実のために構築された。
コード、PR、そしてAgentが同じ場所にいる。Cursorでコードを書いている間、Agentは直接コードを修正し、PRを更新し、ブランチをプッシュできる。別のプラットフォームへジャンプして操作する必要はない。
では、あなたは今日移行すべきか？
慌てる必要はない。短期的には、どのチームもコアプロジェクトをGitHubから完全に移行させることはないだろう。
もし既にCursorのクラウドAgentを使ってバックグラウンドタスクを動かしているのなら、Originを試してみる価値はある。
しかも移行コストはほぼゼロだ。リポジトリの設定で「Detach from GitHub」をクリックするだけで、主従が入れ替わる。
SpaceXAIの研究員は真正面から挑発した：GitHubが落ちたなら、Originを見てみよう！
GitHubがダウンしたその日、Cursorは扉を開いて客を迎えた。
次回GitHubがダウンした時、あなたはもう復旧を待つ必要がないかもしれない。
参考資料：
https://x.com/cursor_ai/status/2089399057659596847?s=20
https://cursor.com/changelog/origin-code-hosting
編集：桃子 摩西