Cursor Originが公開：新しいGitホスティングプラットフォームが実際に何をするのか、そしてGitHubを置き換えられるか

はじめに

8月17日は、デベロッパーインフラにとって異例なほど劇的な一日だった。

GitHubは、最初の影響記録から最終解決まで7時間47分にわたる大規模なグローバル障害を発生させた。障害の間、開発者たちはGitHub.comの主要サービス、API、プルリクエスト、リポジトリコンテンツ、認証関連システム、そしてGitHub Copilotにわたって問題を目にした。

ほぼ同時に、Cursorは自社のGitホスティングプラットフォームであるOriginの展開を開始していた。

そのタイミングは、ソーシャルメディアにとってあまりにも完璧すぎた。

開発者界隈の一方はGitHubのステータスページを更新していた。もう一方はCursorの新しいCodebaseタブのスクリーンショットを共有し、リポジトリを移行する時が来たと冗談を言い合っていた。

元記事はこの瞬間を、Cursorが「GitHubを一夜で倒した」と表現している。キャッチーな見出しではあるが、文字通りに受け取るべきではない。

Originが障害を引き起こしたわけではないし、アーリーベータのホスティング製品がGitHubの巨大なエコシステムを一日で消し去ったわけでもない。

実際に起きたことはもっと興味深い。Cursorが、主にAIコーディング環境であることから、ソース管理インフラストラクチャ層へと移行したのだ。

Originは現在、リポジトリを自らホストできる。つまり、Cursorは、エージェントがコードを書き、そのコードが最終的に置かれる場所がGitHubのままであるという現状に満足していないということだ。

Cursorは現在、リポジトリ、プルリクエスト、エージェント、そして開発ワークフローが一つのシステム内に存在することを望んでいる。

CursorのSpaceXによる買収は、すでに8月14日に完了していた。その3日後、Originは有料ユーザー向けにアーリーベータへと移行した。

Cursor版GitHubがついに登場

Originは、Cursor内のGitHubリポジトリの単なるキャッシュコピーではない。

Cursorはこれを次のように説明している：

コードを保存・共有するためのgitフォージ

現在のアーリーベータでは、Originは以下を行うことができる：

• リポジトリの作成とホスティング
• 標準Gitによるリポジトリのクローン
• 標準Gitによるプッシュとプル
• GitHubからのリポジトリミラーリング
• ブラウザでのコードの閲覧と検索
• コミット履歴の調査
• プルリクエストの作成
• プルリクエストのレビュー
• プルリクエストおよび個別の行へのコメント
• プルリクエストのマージ
• リポジトリへのアクセス管理
• サードパーティアプリケーションの接続
• Cursor Cloud AgentsとAutomationsのアタッチ
• Origin専用CLIの使用

これだけの機能があれば、Originは単なるプロトタイプではなく、本格的なGitホスティング製品となり得るだろう。

visualization layer.

この製品は依然として明示的にアーリーベータ版と表示されています。Cursorの発表記事によると、基本機能から開始し、後により多くのエージェントネイティブ機能を提供する予定です。

この境界線は、ベータ版をCursorが今年初めに示したより野心的なOriginビジョンと比較する際に重要です。

Originを利用できるユーザー

Cursorの現在のドキュメントでは、Originコードストレージについて次のように記載されています：

展開が段階的であるため、有料アカウントでもOriginがすぐに表示されない場合があります。Enterprise組織はオプトアウトも可能です。

Originはネームスペース所有者のプライバシーモードを継承します。つまり、チームは機密コードをこのサービスに置く前に、Cursorのプライバシー設定とリポジトリアクセス構成を確認する必要があります。

リポジトリの作成

基本的なセットアップは意図的に馴染みのあるものになっています。

ステップ1：Codebaseを開く

CursorのCodebaseワークスペースにアクセスします：

cursor.com/codebase

ステップ2：リポジトリを作成する

以下を選択します：

+ New

リポジトリ名を選択します。

Cursorはその後、Origin CLIのインストール、リポジトリのクローン、または既存のローカルプロジェクトのプッシュに必要なコマンドを表示します。

ステップ3：Codebaseネームスペースを慎重に選択する

ユーザーまたはチームが最初のOriginリポジトリを作成するとき、選択したコードベース名がリポジトリURLの一部になります。

URLは次の一般的なパターンに従います：

https://cursor.com/codebase/{owner}/{repo}

例：

https://cursor.com/codebase/acme-corp/example-repo

Cursorの現在のベータ版ドキュメントでは、ベータ期間中はネームスペースを変更できないと警告しています。慎重に選択してください。

Originは標準的なGitと互換性がある

最も重要な採用判断の1つは、Originが開発者にGit自体を放棄させる必要がないことです。

リポジトリでは、以下のような使い慣れた操作を使用できます：

git clone
git pull
git push

新しいブランチからプルリクエストを開くには、Cursorのドキュメントでは標準的なフローを提供しています：

git checkout -b my-change
git push -u origin my-change

ブランチがOriginに配置されると、Webインターフェースからプルリクエストを作成できます。

Cursor Cloud Agentsは、Originリポジトリに対してブランチの作成、コミット、プッシュ、プルリクエストの作成も行えます。

これは、Git互換のフォージを、すべてのローカル開発者ツールを一度に置き換えることなく導入できるため重要です。

プルリクエストがCursorに移行

すべてのOriginリポジトリにはプルリクエストが含まれます。

現在のPRインターフェースには、4つの主要なビューがあります：

• アクティビティ。
• コミット。
• チェック。
• 変更されたファイル。

レビュアーは差分を確認し、行にコメントを付け、レビューを残し、要求することができます。

レビュー担当者は、レビューとCI要件が満たされた後にマージします。

より大きな製品コンセプトは、開発者が毎回の変更において、以下の間を行き来する必要がないようにすることです：

Cursorエディター
→ Gitホスティングサイト
→ AIアシスタント
→ CIダッシュボード
→ エディターに戻る

Originは、リポジトリの閲覧とPR作業を、エージェントがすでに活動している同じCursor環境にもたらします。

「スタックPR、マージキュー、AI自動マージ」の主張について

元の記事では、Originの特に大胆な3つの機能を紹介しています：

1. スタックプルリクエスト
2. エージェント指向のマージキュー
3. AIによる自動マージ競合解決

これらのアイデアは、Cursorのより広いエージェントスケールのビジョンに適合します。

しかし、これらは現在のEarly Betaドキュメントが実際に約束している内容とは区別されるべきです。

現在明確に提供されている機能

Cursorは現在、以下をドキュメント化しています：

リポジトリ
標準的なGit clone/push/pull
GitHubミラーリング
コードブラウジング/検索
プルリクエスト
レビュー/コメント
チェック
手動マージ
競合の表示
権限
アプリ
自動化
クラウドエージェント
Origin CLI

現在のOriginベータ機能として明確に文書化されていないもの

現在のファーストパーティのOriginドキュメントでは、以下は一般提供としてリストされていません：

ネイティブなスタックPRワークフロー
Originマージキュー
AIによる自動マージ競合解決
Origin固有の構造化レビュー状態API
MCPサーバーとしてのOrigin

Cursorの発表文では、追加のエージェントネイティブ機能は後日提供されると明示されています。

したがって、これらは初期のデモコンセプト、ロードマップの方向性、またはより明確なリリースドキュメントを待っている機能として扱うべきであり、有料のOriginユーザー全員が今日頼りにできる機能ではありません。

GitHubにはすでにスタックPRとマージキューがある

比較にはGitHub側の修正も必要です。

GitHubは単一の巨大な人間が読むためのPRリストに限定されていません。

GitHubは現在、以下をドキュメント化しています：

• スタックプルリクエスト
• スタックを作成・管理するためのREST API
• GraphQLスタッククエリ
• マージキュー
• merge_groupワークフローイベント
• 自動マージ
• GraphQLによる構造化されたプルリクエストレビュー判定

これにより、GitHubがCursorが追求しているのと同じ製品意味で「エージェントネイティブ」になるわけではありません。

しかし、技術的な違いが以下のようになるわけではないことを意味します：

GitHubにはこれらのプリミティブが全くない
vs.
Originにはすべてがある

より信頼できる違いは製品哲学です。

Cursorは、リポジトリインフラストラクチャを、コーディングエージェントの群れがすでに第一級のアクターとして活動している環境に直接埋め込むことを望んでいます。

GitHubミラーリングにより最初の一歩は低リスク

Originの最も実用的な移行機能は、劇的な置き換えスイッチではありません。ミラーリングです。

チームは接続できます

以下の内容を日本語に翻訳します：

GitHubからCursorへ、組織とリポジトリを選択し、Originミラーを作成します。

現在文書化されている同期内容は次のとおりです：

ミラーされたリポジトリでは、GitHubが当初は**情報の唯一の源泉（source of truth）**であり続けます。

Originリモートを通じたプッシュは引き続きGitHubに送信されます。プルリクエストはOriginからレビューでき、アクティビティはGitHubに同期されます。

これにより、チームは初日からリポジトリの権限を放棄する必要がないため、Originはテストしやすくなります。

プルリクエストは双方向に同期

Cursorの発表記事によると、ミラーされたリポジトリのプルリクエストは双方向に同期されます。

意図された動作は次のとおりです：

Cursorでコメント
→ GitHubに表示

GitHubで返信またはリアクション
→ Cursorに表示

GitHubでレビューが割り当てられる
→ Cursorから対応可能

Cursorは、これらの更新が数秒以内に反映されると述べています。

これにより、開発者は既存のGitHubコラボレーターが引き続きGitHubを使用しながら、Originのエクスペリエンスを評価できます。

これは、重要なモノレポを即座に新しいベータホストへ移行するよりも、現実的な移行戦略と言えるでしょう。

ワンボタンでOriginを情報の唯一の源泉に

最も強力な移行ステップは**GitHubからの切り離し（Detach from GitHub）**です。

ミラーされたリポジトリが最初に作成されたとき、関係は次のとおりです：

GitHub
= 情報の唯一の源泉

Origin
= 同期されたミラー

Cursorのリポジトリ設定には、Danger Zoneアクションが含まれています：

Detach from GitHub

切り離し後：

Origin
= 独立したホスト型リポジトリ
= 情報の唯一の源泉

Originリモートへのプッシュは、GitHubには送信されなくなります。

元のGitHubリポジトリは、切り離し操作によって削除または変更されることはありません。

この区別は重要です。

切り離しは同期動作を変更するだけで、GitHub側のコピーを消去するわけではありません。

ここでの「情報の唯一の源泉」の意味

コードベースには複数のクローンやミラーが存在し得ますが、開発プロセスでは通常、権威あるリポジトリが1つ必要です。

その権威が以下のような問いを決定します：

• どのリモートが新しいコミットを受け取るか？
• どのブランチが正規のmainか？
• プルリクエストはどこでマージされるか？
• デプロイはどのリポジトリからプルすべきか？
• 分岐後、どの履歴が権威あるものと見なされるか？

ミラーされたOriginリポジトリでは、その権威はGitHubから始まります。

切り離し後、CursorはOriginホスト型リポジトリの情報の唯一の源泉としてOriginを文書化しています。

これが、Originが補助的インターフェースではなくなり、そのプロジェクトの主要なGitホストになるポイントです。

OriginのアプリエコシステムはVercel、Depot、Buildkiteから始まる

Cursorはまた

OriginをデプロイメントおよびCIエコシステムに接続し始めました。

現在の公式インテグレーションは以下のとおりです。

Vercel

リポジトリのAppsタブからVercelを接続します。

Cursorによると、各プルリクエストはプレビューデプロイメントを受け取ることができ、チームはマージ前にテストやコメントを行うことができます。

Depot

DepotはOriginリポジトリのCIを実行でき、既存のGitHub Actionsワークフローを再利用できます。

Buildkite

Buildkiteは、ネイティブのパイプラインシステムに加えて、既存のGitHub Actionsワークフローも実行できます。

これは、最も困難な移行コストの1つを削減するのに役立ちます。

リポジトリのストレージが移動しても、チームは同時にCI/CDスタック全体を書き直したいとは考えていません。

GitHub Actionsファイルは自動的にはOrigin CIにならない

重要なニュアンスがあります。

CursorのGitHubミラーリングドキュメントによると、GitHub Actionsのワークフローとシークレットは、GitHubプラットフォーム設定としてOriginにミラーリングされるわけではありません。

ただし、DepotやBuildkiteなどのサードパーティのOriginインテグレーションは、既存のGitHub Actionsワークフロー定義を実行できます。

これらの記述は共存できます：

GitHub Actionsプラットフォームの状態
→ リポジトリミラーリングでは移行されない

リポジトリ内のワークフローファイル
→ 対応するCIインテグレーションで解釈可能

チームは、本番リポジトリを切り離す前に、シークレット、権限、イベントトリガー、キャッシュ、デプロイメント認証情報、ブランチ保護をテストする必要があります。

OriginはCursorエージェントの下に配置されるよう設計されている

Originに関するより大きな戦略的論点は、エージェント統合です。

CursorのCloud Agentsは、完全な開発環境を備えた分離されたクラウド仮想マシン上で実行されます。

それらは以下のことができます：

• リポジトリのクローン作成。
• ブランチの作成。
• コードの変更。
• ビルドとテストの実行。
• 変更のコミット。
• ブランチのプッシュ。
• プルリクエストのオープン。
• 開発者のラップトップがオフラインでも実行を継続。

Originを使用すると、これらのエージェントは同じプラットフォームでホストされているリポジトリに対して直接作業できます。

ループは次のようになります：

目標
→ Cursorエージェント
→ Originリポジトリ
→ ブランチ
→ コード変更
→ テスト
→ プルリクエスト
→ レビュー
→ マージ

リポジトリは、エージェントワークフローの中心にある外部サービスである必要がなくなります。

自動化によりリポジトリがイベント駆動型になる

OriginはCursor Automationsとも統合されています。

現在のドキュメントには、次のようなリポジトリイベントがリストされています：

• ブランチへのプッシュ。
• プルリクエストのオープン。
• プルリクエストのプッシュ。
• 関連するPRイベント。

自動化により、これらのイベントのいずれかに応じてクラウドエージェントを起動できます。

例えば：

新しいPRがオープン
→ セキュリティレビューエージェントを実行

mainへのプッシュ
→ 変更を要約

PRが更新
→ 新しいコミットを検査

これは、現在すでに文書化されている「エージェントネイティブ」ストーリーの具体的な一部です。

Cursorの8月19日のエージェントアップデートでは、Cloud Agentsがイベントを購読し、CI修正やボットフィードバックなどの作業を目標が達成されるまで継続して進めることができるようになっています。

MCPについては？

ソース記事では、Originが「MCPをネイティブにサポート」しており、エージェントがAPIと同じくらい簡単にフォージを操作できると述べています。

製品全体としてのCursorは、エージェントを外部ツールやデータに接続するためにMCPを確実にサポートしています。

ただし、Origin自体を公開する現在のOriginドキュメントページは見つかりませんでした。

（源内容较长，以下为完整翻译）

仓库操作**的 MCP 服务器。

当前的 Origin 集成文档强调：

Origin CLI
Cloud Agents
Automations
Third-party apps

因此，稳妥的说法是：

Cursor 的代理生态系统支持 MCP，而 Origin 当前的 Early Beta 文档尚未明确宣传专用的 Origin MCP 接口。

随着 Cursor 推出其承诺的更多代理原生功能，这一情况可能会发生变化。

性能声明面向代理规模

Cursor 早期的 Origin 演示强调了对于人类开发团队而言显得过高的吞吐量数字。

报告的演示数据包括：

这些数字仍应视为供应商演示声明。

Cursor 当前的 Origin 文档并未发布这些数字的完整基准测试方法、生产 SLA、工作负载分布、百分位延迟表或独立验证。

生产团队应先测试自己的工作负载，再将阶段演示的吞吐量视为有保障的服务容量。

代理已在 Cursor 自身的 PR 中占据很大比例

代理规模 Git 基础设施的论证并非纯粹假设。

Cursor 在 2 月表示，内部合并的拉取请求中超过 30% 是由在云端沙盒中自主运行的代理创建的。

到 6 月，Cursor 自己的工程文章表示：

我们超过 40% 的 PR 来自云端代理

源文章引用了 35%–40% 的中间数值。

随着代理采用率的提高，确切比例随时间发生了变化。

更重要的趋势是明确的：

2026 年 2 月：
>30%

2026 年 6 月：
>40%

Cursor 的内部软件开发工作流已经产生了足够多的代理编写 PR，使仓库协调成为严重的基础设施问题。

为什么代理生成的 PR 会改变工作流

传统仓库工作流假设人类节奏。

开发人员可能会：

1. 创建一个分支。
2. 工作数小时。
3. 推送多个提交。
4. 打开 PR。
5. 等待审查。
6. 解决评论。
7. 合并。

代理集群可以以不同方式运作。

十个或一百个代理可以同时：

• 克隆同一仓库。
• 创建分支。
• 修改重叠文件。
• 运行 CI。
• 推送提交。
• 打开拉取请求。
• 响应审查评论。
• 修复失败。

瓶颈发生了转移。

编写代码初稿可能变得廉价。

协调、验证、审查以及安全合并大量同步变更变得更加困难。

这就是 Origin 瞄准的基础设施问题。

GitHub 是为人类构建的——但也在适应

源文章对比了“2008 年 GitHub 工作流”与代理原生的 Origin。

历史框架是有用的，但当前的产品对比更为细致。

GitHub 一直在持续添加

自動化のプリミティブには以下が含まれます：

• マージキュー。
• スタック型プルリクエスト。
• Copilotコーディングエージェント。
• GraphQLおよびREST API。
• ウェブフック。
• GitHub Actions。
• ルールセット。
• 自動レビューおよびマージ機能。

つまり、問題はGitHubが開発を自動化できるかどうかではありません。

明らかにそれは可能です。

戦略的な問題は、リポジトリと人間のコラボレーションを中心に設計されたプラットフォームが、現在の主要な製品アイデンティティがソフトウェア作業を行うAIエージェントであるプラットフォームと同じくらい迅速に適応できるかどうかです。

Originは、その答えに新しいフォージの余地が残されているというCursorの賭けです。

GitHubの障害により、ローンチは実際以上に劇的に見えた

GitHubの8月17日の障害は現実的で深刻なものでした。

公式のインシデントは次の期間に及びました：

13:28 UTC
から
21:15 UTC

合計で：

7時間47分

この間、ステータス更新ではウェブ/APIトラフィックおよびリポジトリコンテンツへのアクセスでかなりのエラー率が報告され、Copilotも劣化していました。

ローンチの偶然の一致が、抗いがたい物語を生み出しました：

GitHubがダウン
+
CursorがGitホスティングをローンチ
=
CursorがGitHubを置き換える

しかし、運用面ではそうではありませんでした。

実際、Origin自身のGitHubミラーリングパスは、GitHubがソース・オブ・トゥルースであり続ける限り、依然としてGitHubに依存しています。

そして、Cursorのより広範なエージェントも外部のソースコントロールプロバイダーに依存することがあります。

したがって、GitHubの障害は、すべてのCursorワークフローが影響を受けずに継続することを自動的に実証するものではありません。

本当の教訓は集中リスクについてです：あるソースコントロールプラットフォームが開発に深く組み込まれている場合、長時間の障害はリポジトリの閲覧以上のものに影響を及ぼします。

Microsoftの株価スクリーンショットは因果関係を証明しない

元の記事では、Originのストーリーの隣にMicrosoftの株価スクリーンショットも掲載されており、当日の株価が約3.2%下落したことを示しています。

これは目を引く対比です。

しかし、これだけで次のように結論づけるには不十分です：

Originがローンチ
→ Microsoftが1000億ドル以上を失った

大型株のテクノロジー株は多くの理由で動きます。

原因を特定する証拠がなければ、株価の動きはOriginへの直接的な反応ではなく、当日の市場状況として扱うべきです。

したがって、この記事はMicrosoftの時価総額の変化をCursorのローンチに帰属させるものではありません。

今日、本番リポジトリを移行すべきか？

ほとんどのチームにとって、答えは次のとおりです：

一度にすべてではありません。

Originはまだアーリーベータです。

より安全な道は、段階的に評価することです。

ステップ1：重要でないリポジトリから始める

以下を選択してください：

• 内部ツール。
• プロトタイプ。
• 小規模なサービス。
• 低リスクのライブラリ。

本番プラットフォーム全体をデプロイするリポジトリから始めないでください。

ステップ2：最初にGitHubからミラーリングする

GitHubをソース・オブ・トゥルースとして維持します。

以下を評価してください：

• 同期の鮮度。
• PRの動作。
• コード検索。
• アクセス制御。
• Cursorエージェントワークフロー。
• CI統合。

これにより、ロールバックパスが得られます。

ステップ3：プルリクエストの同期をテストする

両側でコメントとレビューを作成します。

以下を確認してください：

• Cursor → GitHubの同期が機能すること。
• GitHub → Cursorの同期が機能すること。
• レビュー割り当てが正しく維持されること。
• チェックが正しく表示されること。

ステップ4：CIを慎重に再構築する

Vercel、Depot、

またはBuildkiteを使用している場合は、それらを接続して以下を確認します：

• シークレット。
• 必須チェック。
• プレビューデプロイメント。
• ブランチルール。
• デプロイメントゲート。

GitHub Actionsのプラットフォーム状態が自動的に移行されるとは想定しないでください。

ステップ5：エージェントを本番環境に対してテストする

ミラーリングされたリポジトリ上でCloud Agentsを実行します。

測定する項目：

• クローンの信頼性。
• プッシュの信頼性。
• PRの作成。
• CI修復ループ。
• 権限の動作。
• 長時間実行タスクの完了。

ステップ6：プライバシーとアクセスを確認する

チェック項目：

• リポジトリの可視性。
• チームの権限。
• Cursor Privacy Mode。
• 組織の管理者コントロール。
• 外部アプリのアクセス。

リポジトリホストは、セキュリティ境界の一部になります。

ステップ7：ワークフローが証明された後にのみ分離する

以下を使用します：

設定
→ 一般
→ デンジャーゾーン
→ GitHubから分離

チームが意図的にOriginを権威あるものとすることを決定した場合のみ実行してください。

分離後、OriginへのプッシュはGitHubに反映されなくなります。

Originを今すぐテストする価値がある場合

チームがすでにCursorを頻繁に使用している場合、Originは特に魅力的です。

適したチームの例：

• 多数のCursor Cloud Agentsを実行している。
• エージェント作成によるPRを大量に生成している。
• リポジトリの閲覧とエージェント作業を1つのインターフェースで行いたい。
• イベント駆動型のエージェントワークフローを試したい。
• すでにVercel、Depot、またはBuildkiteを使用している。
• 移行を検討する前に、手間のかからないGitHubミラーを希望する。

Cursorがすでにエンジニアリングワークフローの中心にある場合、統合の利点は最も大きくなります。

GitHubが依然としてより安全なデフォルトである場合

GitHubは、以下に依存するチームにとって、より保守的な選択肢であり続けます：

• 成熟したパブリックなオープンソースエコシステム。
• GitHub Issues。
• GitHub Actionsのインフラストラクチャ。
• マーケットプレイスの統合。
• 既存のエンタープライズガバナンス。
• 複雑なルールセット。
• 確立された監査プロセス。
• 広範な外部コントリビューターの熟悉度。
• Originではまだ利用できない多数の統合。

OriginのEarly Betaドキュメント自体も、GitHub固有のプラットフォーム機能の一部がリポジトリミラーリングでは移行されないことを認めています。

コードホストは単なるGitオブジェクトストレージではありません。それはエコシステムです。

OriginはまだGitHubの完全な代替品ではない

現時点で最も正確な説明は次のとおりです：

Originは本物のGitホスト
+
GitHubミラー
+
PR/レビューサーフェス
+
エージェント統合リポジトリレイヤー

しかし、まだ以下ではありません：

すべてのGitHub機能のドロップイン代替品

この違いは移行計画にとって重要です。

チームはすでにコードを完全にOriginでホストできます。

しかし、それはGitHub Issues、Actions設定、シークレット、マーケットプレイスアプリ、ポリシー、パブリックコミュニティワークフロー、エンタープライズプロセスがすべて自動的に移行されることを意味するものではありません。

より重要な競争はシステム・オブ・レコードを巡るもの

ソース記事の最終的な主張は、その見出しよりも強いものです。

Cursorは単にリポジトリストレージについてGitHubと競争しているわけではありません。

ソフトウェア開発の成果が権威を持つ場所を競っているのです。

従来のスタックでは：

開発者
→ IDE
→ GitHub
→ CI
→ デプロイ

Cursorの新しいスタックでは：

人間の目標
→ Cursorエージェント
→ Origin
→ PR
→ 自動チェック
→ デプロイメント統合

もし

エージェントが変更の主要な生産者となる時代において、それらのエージェントを調整するリポジトリプラットフォームは、エディタと同様に戦略的に重要になる可能性がある。

だからこそ、**GitHubからのデタッチ（切り離し）**は、ローンチ当日のジョーク以上に重要なのだ。

ミラーは便利だ。

しかし、新たな真実の源（ソース・オブ・トゥルース）を持つことは、プラットフォームの転換を意味する。

よくある質問

Cursor Originとは何か？

OriginはCursorのGitホスティングおよびコード共有プラットフォームです。初期ベータ版では、リポジトリのホスティング、標準的なGitのclone/push/pull、GitHubリポジトリのミラーリング、コードの閲覧・検索、プルリクエストの作成・マージ、Cursorエージェントおよび選択したサードパーティアプリの接続が可能です。

Cursor Originは無料ユーザーも利用できますか？

いいえ。Cursorの現在のドキュメントによると、OriginのコードストレージはPro、Teams、Enterpriseプランで利用可能で、無料プランでは利用できません。ロールアウトは段階的に行われるため、対象ユーザーでもアクセスが遅れる場合があります。

OriginはGitHubを完全に置き換えられますか？

Originは、リポジトリをGitHubからデタッチした後、そのリポジトリの真実の源（ソース・オブ・トゥルース）になることができますが、現在のところGitHubプラットフォーム全体を機能ごとに完全に置き換えるものではありません。GitHub Issues、GitHub Actionsのプラットフォーム設定、シークレット、多くのエコシステム統合は自動的には移行されません。

Cursor OriginはGitHubとの同期をサポートしていますか？

はい。OriginはGitHubリポジトリをミラーリングでき、Git履歴、ブランチ、タグ、閲覧可能なコード、双方向に同期されるプルリクエストを含みます。リポジトリがミラーリングされている間、GitHubは真実の源であり続け、Originを通じたプッシュはGitHubに反映されます。

「GitHubからのデタッチ」とはどういう意味ですか？

GitHubの同期を停止し、OriginのミラーをスタンドアロンのOriginホスト型リポジトリに変換します。Originが真実の源となり、以後OriginリモートへのプッシュはGitHubに反映されなくなります。既存のGitHubリポジトリはそのまま残ります。

OriginはスタックPRとAIマージキューをすでにサポートしていますか？

Cursorの現在の初期ベータ版ドキュメントでは、ネイティブなスタックPRワークフローやOriginマージキューは一般提供機能として記載されていません。ローンチでは、追加のエージェントネイティブ機能が近日中に提供されると述べられています。したがって、以前のデモやロードマップでの主張は、現在文書化されているベータ版と混同すべきではありません。

OriginはAIでマージコンフリクトを自動的に解決しますか？

現在のOriginのプルリクエストドキュメントによると、Originはマージコンフリクトを表示し、ユーザーがマージ前に解決できるようにします。CursorのCompileデモに関する以前の公開情報では、AIによるコンフリクト解決のアイデアが説明されていましたが、これは初期ベータ版の文書化された保証として扱うべきではありません。

CursorはGitHubの障害を受けてOriginをローンチしたのですか？

その証拠はありません。Cursorは8月17日にOriginのロールアウトを開始しましたが、その日はGitHubが大規模な障害に見舞われた日であり、非常に目立つ偶然の一致が生じました。Originはそれ以前にすでに発表・デモが行われていたため、障害が製品を一夜にして生み出したわけではありません。

関連ツール

• Cursor Origin: Cursorの公式Gitホスティング、リポジトリ、PR、GitHubミラーリング、およびエージェント統合のドキュメント。
• Origin CLI: OriginリポジトリワークフローのためのCursorのコマンドラインインターフェース。
• [Cursor

Cloud Agents](https://cursor.com/docs/cloud-agent): Originリポジトリに対して直接作業できるクラウドホスト型コーディングエージェント。

• Cursor Automations: Originリポジトリのアクティビティに反応する、イベント駆動型およびスケジュール型のエージェントワークフロー。
• Git: GitHubとOriginの両方で使用される分散バージョン管理システム。
• GitHub: Originがミラーリングおよび同期できる、確立されたGitホスティングおよびコラボレーションプラットフォーム。
• Vercel: プルリクエストのプレビュー展開のためにOriginが接続できるデプロイプラットフォーム。
• Buildkite: Originと統合され、既存のGitHub Actionsワークフローを実行できるCI/CDプラットフォーム。

関連リンク

• Cursor: Origin Code Hosting: 8月17日の公式発表と、現在のアーリーベータの適用範囲。
• Mirror a GitHub Repository: GitHub同期に関する公式ドキュメント。同期される内容とされない内容、およびデタッチについて。
• Origin Pull Requests: 公式のPRワークフロー、レビュー、チェック、コンフリクト、およびミラーリングされたGitHub PRの動作。
• Origin Integrations: Automations、Cloud Agents、Vercel、Depot、Buildkiteに関する公式ドキュメント。
• Cursor: Cloud Agents Lessons: 2026年6月までにCursor内部のPRの40%以上がCloud Agents由来となったというCursor自身のレポート。
• GitHub Merge Queue Documentation: マージキューがすでにサポートされていることを示すGitHub公式ドキュメント。
• GitHub Stacked Pull Requests: スタックPRとマージキューとの統合に関するGitHub公式ドキュメント。

まとめ

Cursor Originは、もはやCursor内の単なるGitHubブラウザではなく、本格的なGitホスティングプラットフォームとなった。アーリーベータでは、リポジトリのホスティング、標準Gitの使用、GitHubのミラーリング、双方向のプルリクエスト同期、コードブラウズ、レビュー管理、CI/デプロイアプリの接続、そしてCursorエージェントがOriginホスト型リポジトリに対して作業を行うことが可能である。

元の記事では、いくつかのエージェントネイティブ機能がすでに展開されているかのように誇張されている。現在の公式ドキュメントでは、ネイティブのスタックPR、Originのマージキュー、自動AIコンフリクト解決、またはOrigin MCPサーバーは、一般提供されているアーリーベータ機能としてはまだ記載されていない。Cursor自身も、さらなるエージェントネイティブ機能が今後追加されると述べている。

GitHubの8月17日の障害により、Originは異例なほどの劇的なローンチの瞬間を迎えたが、それはGitHubが一夜にして置き換えられたことを意味するものではない。ほとんどのチームにとって賢明な道は、まず重要ではないリポジトリをミラーリングし、同期とCIをテストし、Originが安全にソース・オブ・トゥルースとなり得ることが証明された後にのみデタッチすることである。

本当の競争上の変化は、Cursorが「GitHubを殺した」ことではなく、Cursorが現在、開発ワークフローの全体を所有しようとしていることにある。

AIエージェントがソフトウェアを作成、レビュー、そして出荷するリポジトリレイヤー。