Cursor Origin: エージェントはリポジトリの形まで変え始めるのか

まず、誇張する側のいちばん強い主張を認めましょう。まったく根拠がない話ではありません。Gitホスティング基盤はチームが持つ基盤の中でも特に保守的な部分です。ソースコードのホスティングは、今働いている開発者の多くが仕事を始める前からGitHubの領域でした。コーディングツールの会社がそこへ挑むなど、2年前なら笑い話だったでしょう。Cursorは実際にそれをやりました。しかも、自社製品内でマージされたプルリクエストの3分の1がエージェントによって開かれたと報じられる状況でです。ソフトウェアを書くソフトウェアのためにリポジトリを設計し直すべきか、と問う資格のある会社があるなら、Cursorはかなり有力です。

では慎重なほうの話です。私はCursorの変更履歴、Originのドキュメント、報道を読みました。8月17日に出たものは、GitHub同期を備えた堅実な初期ベータのGitホスティング基盤です。新しいエージェント権限モデルではありません。エージェントの話自体は本物ですが、現時点では主に「近さ」とロードマップです。私の見方では、エージェントはまだリポジトリそのものを作り替えてはいません。先にGitホスティング基盤側がエージェントに合わせて形を変え始めています。それが一つ前の段階です。どう対応するかを決めるなら、この違いは大事です。

要点 - OriginはCursorのGitホスティング基盤です。リポジトリ、プルリクエスト、コード閲覧と検索、双方向GitHub同期を提供し、8月17日から有料プラン向け初期ベータとして展開されています。Vercel、Depot、Buildkite連携も初日から入りました。 - 同期リポジトリではGitHubが引き続き正本で、Originは独自の権限体系を作らずGitHubの読み書き権限をそのまま反映します。今回のローンチで最も賢い判断だと思います。 - エージェントにとって今変わったのは、コード、PR、エージェントが一つの画面に集まる「近さ」と、エージェント規模のPR量を想定したGitホスティング基盤という「容量」です。変わっていないのは、エージェントの権限モデルとコンテキストモデルです。Cursor自身も「エージェントネイティブ機能は近日公開」としています。 - 背景にはGitHubの信頼性問題があります。ローンチ当日にも6時間を超える障害が起きました。そしてCursorの所有者も変わりました。現在はSpaceXの一部門であり、企業導入では製品品質と別に評価すべき点です。 - 私の判断では、エージェントがリポジトリを変えるというのは方向性であって、まだ事実ではありません。「エージェントネイティブ機能」が実際に何を出すかを見る前に、それを前提に組織や運用を変える必要はありません。

何が起きたのか

8月17日、Cursorは有料プラン（Pro、Teams、Enterprise）向けにOriginの段階的提供を始めました。変更履歴とドキュメントによれば、初期ベータでは次のことができます。

• Originリポジトリを作成できます。Cursorエージェントから作ることも可能です。コードベースにはcursor.com/codebase/your-orgの形式で名前を付け、標準GitまたはOrigin CLIでclone、push、pullできます。

• GitHubリポジトリをOriginへミラーし、リアルタイムで双方向同期できます。閲覧、検索、レビューはCursorで行いますが、push先は引き続きGitHubで、GitHubが正本です。アクセス権も既存のGitHub権限を反映します。PRの会話も双方向に同期されます。

• エディター内でコメント、チェック、競合、ブランチ保護を含むプルリクエストの作成、レビュー、マージができます。ブラウザータブは不要です。

• Vercel（PRごとのプレビューデプロイ、マージ時の本番デプロイ）、Depot、BuildkiteをCI向けに接続できます。特に重要なのは、DepotとBuildkiteが既存のGitHub Actionsワークフローを変更なしで実行できることです。

• 公開REST APIから使え、Cursorのクラウドエージェントや自動化をOriginリポジトリへ接続できます。

キャッチコピーは「エージェント規模のGitホスティング」です。そして変更履歴は順番についてかなり正直です。「まず基本機能から始めます... エージェントネイティブ機能は近日公開」。製品を作ったのはGraphiteのチームです。Cursorが2025年12月に買収したコードレビューのスタートアップで、買収額は同社のシリーズB評価額2億9,000万ドルを大きく上回ったと報じられています。

ローンチのタイミングは出来すぎていました。Originの提供開始からおよそ3時間半後、GitHubのステータスページに障害が出始め、その後6時間42分にわたる性能低下になりました。VentureBeatの記事によると、プルリクエスト、Issue、APIではエラー率が約20%、アーカイブとrawファイルのダウンロードでは約50%に達し、SAML、SCIM、Copilotにも影響しました。その日の一番いい一言はCursorのエンジニアから出ています。「もっと早く出す予定だったんですが、GitHubが落ちていました」。

Cursorは2026年8月17日にOriginを公開しました。有料プラン向け初期ベータのGitホスティング基盤で、リポジトリ、プルリクエスト、コード閲覧、GitHubミラーリングを提供します。GitHubは正本と権限モデルのままです。Vercel、Depot、Buildkite連携もあります。Cursorの変更履歴とドキュメントで確認できます。「エージェントネイティブ機能」は発表済みですが、まだ出荷されていません。

Originがエージェントについて変えるもの、変えないもの

ここで確認したかったのは、Originがエージェントの権限とコンテキストを変えるのか、それとも単にホスティングが変わるだけなのか、です。証拠を見る限り、ほぼ後者です。ただし一つ、本物の例外があります。

権限は変わりません。同期リポジトリはGitHubの読み書き設定をそのまま継承し、Originネイティブのリポジトリも標準的なリポジトリ権限とブランチ保護を使います。エージェント専用の権限階層、新しいIDモデル、エージェント主体向けの範囲限定認証情報はありません。今Originリポジトリで動くエージェントは、先月と同じく、実行環境に与えられたアクセス権を持つだけです。

コンテキストは大きくなったのではなく、近くなりました。リポジトリ、PRキュー、エージェントを一つの画面に置けば、レビューコメントをエージェントへ渡してその場でPRを修正させたり、画面上のファイルについて質問したりできます。コピーして別画面へ貼る往復が要りません。これはコンテキストウィンドウの改善ではなく、ワークフローの改善です。特にレビューのループで効きます。今はエージェントの推論とレビュー担当者のコメントが別アプリに分かれていることが多いからです。

本物の例外は容量です。「エージェント規模」は機能の主張である前に、負荷の主張です。機械が生成するPR量を最初から想定するGitホスティング基盤ということです。RuntimeWireは、Cursor内でマージされたプルリクエストの35%が、クラウドVM上で自律実行するエージェントによって開かれたと報じています。この数字は監査済みではなく報道値として扱いますが、仮に半分でもレビューキューの意味は変わります。人間向けのGitホスティング基盤は、PRの向こうに「どういう意図だったか」を聞ける人がいると暗黙に仮定しています。エージェント量が本当に増えると、キューはトリアージになります。これはアーキテクチャ上の主張で、Cursorの売り文句の中では最も強い部分です。そして、エージェントが共有チャンネルへ入るときにチームが直面している監督問題と同じでもあります。今週Slack Codeについて書いたとおり、量が増えたら問いは「エージェントが書けるか」ではなく「誰がマージの責任を持つか」へ変わります。

Originはエージェント権限を変えていません。同期リポジトリはGitHubアクセスを反映し、ネイティブリポジトリは標準的な保護を使います。「エージェントネイティブ機能」はロードマップ段階です。Cursorの変更履歴で確認できます。今出荷されたのは、エージェント、コード、PRが一つの画面に近づいたことと、容量面の主張です。Cursor内でマージされたPRの35%がエージェントによって開かれたとRuntimeWireを引用したVentureBeatが報じています。この数字は監査済みではなく報道値です。

足掛かり、障害、そしてロケット付きの大きな問題

あなたに影響しそうな順に、戦略上の事実が3つあります。

1つ目は足掛かりです。Originで最も良い設計判断は、GitHubを捨てろと言わないことです。ソース管理の全面移行は、エンジニアリング組織が実施できる中でも特にリスクの高いプロジェクトです。GitHubを正本のままにする、ほぼ読み取り中心のミラーなら、セキュリティレビューでも通しやすい。Cursorのレビュー体験が日常の習慣を取れば、後から正本も注意の向く先についてくるかもしれません。教科書どおりで、実装もうまいです。

2つ目は開いた隙です。GitHubは退屈なほど安定していたから既存の地位を得ましたが、この18か月はそうではありません。LeadDevは2025年5月から2026年4月までに257件のインシデントを数え、そのうち48件を重大としています。GitHub自身のCTOも、プラットフォームは「今求められている規模を前提に作られていなかった」と述べたとVentureBeatが報じています。ZigはCodebergへ移り、Ghosttyも離脱を発表し、OpenAIも独自代替を作り始めたと報じられています。Cursorがこの隙を作ったわけではありません。ただ、開発者の日常ワークフローをすでに持っている代替としては、初めてかなり信頼できる存在です。

3つ目は所有の問題です。これは製品とは分けて冷静に評価したほうがいい。Origin公開の3日前、BloombergはSpaceXがCursorを600億ドルの全株式取引で買収完了し、現在はSpaceXAIという部門内で運営されていると報じました。可用性はエンジニアリング問題であり、エンジニアリング問題には改善の道筋があります。一方、誰が自社の機密ソースコードを持ち、それを何に使えて、最終的に誰へ説明責任を負うのかには、同じような解決期限はありません。だからOriginの主張が間違いになるわけではありません。調達の問いが製品の問いとは別になるだけです。このようなプラットフォームへの依存を検討するなら、自作か購入かの枠組みはGitホスティング基盤にも当てはまります。切り替えコストこそが判断材料です。

GitHubの信頼性実績、つまり12か月で257件のインシデント、そのうち48件が重大というLeadDevの集計をVentureBeatが紹介しており、それが競合の入り口を開きました。OriginのGitHub同期は、移行を決めなくてもその入り口へ入れる足掛かりです。それとは別に、Cursorは600億ドルの全株式買収が報じられた後、現在SpaceXの一部門です。「誰がソースコードを持つか」は、製品品質とは別の調達問題になっています。

では、エージェントはリポジトリを作り替えているのか

私の答えは、まだです。そう言い切る人はロードマップを製品として読んでいます。今あるのは、エージェント量の増加を見越して作り直されているGitホスティング基盤です。それを予測するうえで最も良い観測地点を持つ会社が作っています。ただ、リポジトリそのもの、つまり構造、ブランチモデル、レビューの意味づけはまだ変わっていません。

とはいえ方向は読めますし、驚くより少し早く見ておきたい。もしPRの3分の1をエージェントが開くなら、次に来るものは予測できます。権限モデル内のエージェントID、機械由来であることを記録するPRの意味づけ、機械の処理量に合わせたブランチとマージのポリシー、人が眺めるよりエージェントが移動しやすいリポジトリ構成まで出るかもしれません。その一部は本当に「エージェントがリポジトリを作り替える」と呼べます。一方で、Gitホスティング基盤でも、TrueForgeの記事で扱ったようなランタイムでも、チャットチャンネルでも、あらゆるエージェント画面が同じ監督基盤へ収束しているだけの部分もあります。Cursorは意図を発表しましたが、その機能はまだ一つも出していません。正直な姿勢は、意図を覚えておき、同期機能を試し、何も組み替えないことです。

現在のOriginは、エージェント量を見越して作り直されたGitホスティング基盤であって、エージェントがリポジトリを作り替えている証拠ではありません。ローンチ時点では、エージェント専用権限階層、由来を示すモデル、リポジトリ構造の変更は出荷されていません。Cursorのドキュメントで確認できます。発表済みの「エージェントネイティブ機能」が、より強い主張を本当に成立させるかを見る試金石です。

今、何をすべきか

1. 有料Cursorプランを使っているなら: GitHubから稼働中のリポジトリを一つミラーし、1スプリントだけOriginのPRレビューを使ってください。費用はかからず、壊れるものもなく、エディター内レビューのループが本当に良いか分かります。その間ずっとGitHubが正本です。

2. エンジニアリング責任者なら: このベータだけでホスティング判断をしないでください。ただし、エージェントが開いたPRの比率とレビューキューの待ち時間は測り始めてください。この2つの数字が、自分たちのチームで「エージェント規模」が売り文句ではなくなる瞬間を教えてくれます。

3. セキュリティやコンプライアンス担当なら: 所有関係（SpaceX）、データ条件、名前空間ごとのPrivacy Modeを継続的なレビュー項目にしてください。ドキュメントによればOriginは名前空間所有者のPrivacy Modeに従います。機密コードを置く前に、条件を書面で確認してください。

FAQ

Cursor Originとは何ですか

Cursor独自のGitホスティング基盤で、2026年8月17日に有料プラン向け初期ベータとして公開されました。エディターにCodebaseタブを追加し、リポジトリ、プルリクエスト、コード閲覧と検索、双方向GitHub同期（正本はGitHub）、CLI、REST API、Vercel、Depot、Buildkite連携を提供します。

OriginはGitHubを置き換えますか

まだですし、今のところ置き換えを迫ってもいません。同期リポジトリは引き続きGitHubへpushし、GitHub権限を継承し、PR会話を双方向に同期します。Originネイティブのリポジトリはより大きな依存になりますが、ベータは移行せずにレビュー画面だけ採用できるよう明確に設計されています。

Originでコーディングエージェントができることは変わりますか

現時点では少しだけです。エージェントはOriginリポジトリを作成でき、コードとPRと同じ画面で作業できるため、レビューのループは短くなります。ただし新しいエージェント権限モデルやIDモデルはありません。アクセス権は基盤となるリポジトリの許可をそのまま反映します。Cursorは「エージェントネイティブ機能は近日公開」としており、待って見るべきなのはそこです。

企業はCursorへソースコードを預けてよいのでしょうか

新しいベンダーを評価するときと同じように評価し、それに一つ問いを足してください。Cursorは現在SpaceXの一部門です。600億ドルの全株式取引と報じられ、ローンチの1週間前にはコードについて最終責任を持つ主体が変わりました。可用性リスクは現時点でCursor側の主張を後押ししますが、ガバナンスリスクはどちらにしても未解決です。データ取扱条件は書面で確認してください。

結論

Originは、本当に弱点を見せ始めた既存大手へ入っていく、よくできた足掛かりです。それを作るのに適した会社を買収したチームが出しました。ただしエージェントの話は、まだ約束手形です。出荷されたのは近さと容量で、リポジトリの作り替えに当たる部分、エージェントID、由来、機械向けに調整されたレビューの意味づけはすべてロードマップ上です。私の立場は冒頭と変わりません。エージェントはまだリポジトリを作り替えていない。ただ、Gitホスティング基盤側はエージェントに合わせて作り替わり始めています。Cursorが「エージェントネイティブ」の半分を実際に出したとき、強い主張を真面目に検討するタイミングです。私も試して、分かったことを書きます。

ツールチェーンをどこまでエージェントベンダーへ集約するか考えているなら、これは私がクライアントとよく話すテーマです。お問い合わせください。

情報源

• Cursor「Originコードホスティング」（変更履歴）: https://cursor.com/changelog/origin-code-hosting （2026-08-17公開、2026-08-29参照）

• Cursor Docs「Origin」: https://cursor.com/docs/origin （2026-08-29参照）

• VentureBeat「GitHub障害でAIコーディング競争の隙が見える中、CursorがOriginコードホスティング基盤を公開」: https://venturebeat.com/infrastructure/cursor-launches-origin-code-hosting-platform-as-github-outage-exposes-opening-in-ai-coding-race （2026-08-17公開、2026-08-29参照）

• SiliconANGLE「Cursor、GitHubに対抗するOriginコードホスティングサービスを公開」: https://siliconangle.com/2026/08/17/cursor-launches-origin-code-hosting-service-to-compete-with-github/ （2026-08-17公開、2026-08-29参照）

• kingy.ai「Cursor OriginとGitHubの比較: 開発者が知るべきこと」: https://kingy.ai/blog/cursor-origin-vs-github/ （2026-08-17公開、2026-08-29参照）