Cursor Origin は、もう使える。 2026年6月16日に「Fall 2026提供予定」として発表されたGitHub対抗のGitフォージは、2026年8月17日に早期ベータとして提供が始まった。ウェイトリストは終了し、対象はPro・Teams・Enterprise の有料プラン(無料プランは対象外)。ただし出荷されたのはリポジトリ・PR・コード閲覧・GitHub同期までで、発表時の目玉だった「マージ衝突の自動解決」は含まれていない。本稿は発表翌日(2026-06-17)に公開した記事を、2026年9月4日に公式CLIの実測を加えて全面更新したものだ。
2026.09.01-22-54-12-04810e3 を、未ログイン状態で叩いた実記録(2026-09-04 実測)。サブコマンドに ruleset(merge-time / push-time)が並ぶ一方、repo list と git エンドポイントは有料プランのログインが無いと exit=1 / HTTP 403 で止まる。AIコーディング全体の見取り図(どのツールをどう使い分けるか)は Vibe Codingとは?AIコーディングの始め方・ツール比較・実践ワークフロー2026 をご覧ください。
- 2026年8月17日に早期ベータで提供開始。 ウェイトリストは終了し、公式ページの表記も "Early beta now available on all paid plans" に変わった(2026-09-04 実測)。
- 対象は Pro・Teams・Enterprise のみ。無料プランでは使えない。 公式ドキュメントはさらに「アクセスは段階的に開放される」と明記しており、プラン条件を満たしても即日使えるとは限らない。
- 出荷されたのは「普通のGitフォージ」。 リポジトリ・PR・コード閲覧・GitHub双方向同期までで、発表時の目玉だったマージ衝突の自動解決は changelog にも公式ドキュメントにも記載がない。changelog 自身が「エージェントネイティブ機能はまもなく」と書いている。
- CLIは実在し、公開情報より広い。
ruleset(merge-time / push-time)・ssh-key・api(gh api相当)が実装済み。ただしmacOSとLinuxのみで、Windowsビルドは配布されていない(公式インストーラを読んで確認)。 - Issue管理は無い。CIも自前ではない。 Depot・Buildkite を接続して既存の GitHub Actions ワークフローを動かす方式で、GitHubの全面代替にはまだ距離がある。
本記事は発表翌日に公開して以来、同じ項目を定点観測してきた。2026-07-31 の時点ではまだウェイトリストのままで、その16日後に前触れなく出荷された。当初アナウンスされた「Fall 2026」より早い。
| 確認項目 | 2026-06-16 発表時 | 2026-07-31 実測 | 2026-09-04 実測 |
|---|---|---|---|
| 提供状況 | 未開始 | 未開始(変化なし) | 早期ベータで提供中(2026-08-17 開始) |
| 入手方法 | ウェイトリスト登録 | ウェイトリスト登録 | 有料プランなら即利用可(段階開放あり) |
| 提供時期 | Fall 2026 | Fall 2026(具体日未公表) | 前倒しで出荷済み |
| 対象プラン | 未公開 | 未公開 | Pro / Teams / Enterprise(無料プラン不可) |
| Origin単体の料金 | 未公開 | 未公開 | 未公開(有料プランに同梱) |
| マージ衝突の自動解決 | 売り文句として提示 | 未提供 | 出荷物に記載なし |
cursor.com/origin の文面自体も入れ替わっている。7月末まで置かれていた "Join the waitlist" は消え、2026-09-04 時点では "Early beta now available on all paid plans" と表示される。
30秒で理解する
まず全体像を箇条書きで押さえる。各項目は後続のH2で一次・二次ソースとともに展開し、出典の種類(公式/参加者報告/報道/未確認)を明記する。
・Cursorは2026年6月16日、GitHub対抗のGitフォージ「Origin」を発表した。公式サイト cursor.com/origin のキャッチコピーは “A git forge for the agentic era”(エージェント時代のためのGitフォージ)
・同じステージで「Graphiteを買収した」ことも告知され、Originの開発はGraphite出身エンジニアが主導していると複数の参加者が報告している
・Originは「Git互換」で、複数のAIエージェントが同時にクローン・ブランチ・コミット・リベース・レビューする負荷を前提に設計されたと説明された
・主要な売り文句はAPI/MCP拡張・マージ衝突の自動解決・CI失敗のエージェント解決。ライブデモでは単一リポジトリ22.6コミット/秒(公称)が示されたとされる
・その後2026年8月17日に早期ベータで出荷された。対象はPro・Teams・Enterpriseで、無料プランは対象外。Origin単体の料金は公開されていない
・ただし出荷物にマージ衝突の自動解決は含まれていない。changelogは「エージェントネイティブ機能はまもなく」と書いており、発表時の目玉はまだ実装待ちである
AIコーディングの全体像(どのツールをどう使い分けるか、エージェントに任せる範囲の決め方)は上記のピラー記事に整理してある。本記事はその応用として「コードのホスティング基盤がエージェント前提でどう作り直されようとしているか」を追う位置づけだ。
Cursor Origin とは(公式定義・発表日)
Cursor Originは、Cursor(開発元Anysphere)が発表したコードホスティング基盤、いわゆる「Gitフォージ(git forge)」だ。フォージとはGitリポジトリのホスティングに加え、ブランチ管理・レビュー・CIといった共同開発の機能を束ねた基盤を指す言葉で、GitHubやGitLabがその代表格にあたる。Originはそこに正面から挑む。
公式に確認できる事実は限られているが、はっきりしている。公式ページ cursor.com/origin に掲げられたキャッチコピーは次の一文だ。
A git forge for the agentic era.(エージェント時代のためのGitフォージ)
同ページには「Code is moving faster than any infrastructure was built to handle.(コードは、どんなインフラが想定していたよりも速く動いている)」という説明が添えられている。この一文は2026-09-04時点でも変わっていない。変わったのはその下だ。発表当時あった “Join the waitlist”(ウェイトリストに参加)のボタンは姿を消し、いまは “Early beta now available on all paid plans”(早期ベータを全有料プランで提供中)と書かれている。公式サイト上で、Originは「これから提供される製品」から「いま使える製品」に変わった。
発表のタイミングも整理しておく。発表は2026年6月16日、Cursorのステージイベントで行われた。発表を実況した参加者のポストによれば、Originは「3つの大きな変更」のうちの2番目として披露された。発表を伝えた一人、開発者のswyx氏は次のように書いている。
Cursor/Graphite's @TomasReimers just announced Origin / @cursor_ai's long awaited Git competitor, scalable for agent workloads, extensible with api and mcp, and built in merge conflicts and co failure agent resolution.(Cursor/GraphiteのTomas Reimersがいま、Originを発表した。Cursorの待望のGit競合で、エージェントワークロードにスケールし、API・MCPで拡張可能、マージ衝突とCI失敗のエージェント解決を内蔵している)
この投稿者は当初「Git competitor」と表現したが、後に「GitHub competitor(GitHubの競合)」が正確だと自己訂正している。GitそのものではなくGitHubという「ホスティング基盤」への対抗である、という整理だ。本記事もこの理解に沿う。
発表現場の写真からも、Originがこの日の主役の一つだったことがうかがえる。ステージのスクリーンには製品名「ORIGIN」が大きく映し出された。
発表の現場は、サンフランシスコで開催されたイベント「Compile」だ。会場に居合わせたMorgan Linton氏が、その様子をLinkedInに動画付きで公開している。同氏は投稿で “Cursor just announced they are releasing a competitor to GitHub called Origin”(CursorがGitHubの競合「Origin」を発表した)と書き、これを「初めての言及(the very first mention)」だと紹介している。下の動画はその発表の瞬間を捉えたものだ。
動画内では、登壇者がOriginを「エージェントネイティブなGitプラットフォーム」と説明し、API・MCP・サードパーティアプリでの拡張性、スケーラビリティ、ユーザーのデータ主権といった論点に触れている。いずれも前述の参加者ポストと整合する内容で、発表の一次的な裏取りになる。なお動画はあくまで発表現場の記録であり、製品の実機デモや仕様確定を示すものではない点は変わらない。
「Git」はバージョン管理の仕組みそのもの、「GitHub」はそのGitリポジトリをクラウドでホストし共同開発機能を載せた製品。Originが挑むのは後者であって、Gitを置き換えるものではない。Originは「Git互換」をうたっており、既存のgitコマンド・ワークフローはそのまま使える前提で語られている。
なお、Cursor自体の歩み(Composerシリーズや複数エージェント並列実行など)は別記事でも追っている。たとえば Cursorが「Composer 2」をリリース、AI開発効率が大幅向上 で扱ったComposer系の進化がその流れにあたる。Originは、その「複数エージェント並列」の発想をエディタの外側、ホスティング層にまで広げた延長線上にあると読める。
なぜGitHub代替を狙うのか
CursorがホスティングというGitHubの牙城に踏み込む背景には、「AIエージェントの並列運用」という前提条件の変化がある。これは公称・報道・観察を分けて考える必要がある領域だ。
まず、Cursorが公式ページで掲げる論理はシンプルだ。コードの生成速度がインフラの想定を超えた、というものである。人間が1人でコミットしていた時代と、複数のエージェントが同時に同じコードベースを編集する時代とでは、ホスティング基盤にかかる負荷の性質が違う——という主張だ。発表を伝えた別の参加者、Ray Fernando氏の実況はこの点を端的に示している。
Tomas Reimers on stage to talk about the 2nd big thing. Graphite was acquired by Cursor. Just announced Origin which is their Agent Native Git platform. Can keep up with the new agentic demand. Wow!!(Tomas Reimersが2番目の大きな発表のため登壇。GraphiteはCursorに買収された。彼らの「エージェントネイティブGitプラットフォーム」Originをいま発表した。新しいエージェント需要に追従できる)
ここで使われた “Agent Native Git platform”(エージェントネイティブなGitプラットフォーム)という表現が、Originの立ち位置を最もよく表している。後付けでエージェント対応を足したのではなく、最初からエージェントが主役のユーザーとして設計された、という主張だ。
背景には業界全体の文脈もある。報道(The Information)によれば、GitHub側の幹部が社内で「CursorやAnthropicのツールがGitHubを時代遅れにしかねない」と警告したと伝えられている。AIコーディングの主導権が、IDE・エージェントを握るプレイヤーへ移りつつあるという見立てだ。Cursorはエディタで開発者の作業時間を押さえており、その「上流」を握ったまま「下流」のホスティングまで取りに行こうとしている——と読むと、今回の発表の戦略的な意味が見えてくる。
タイミングの観点も無視できない。同じ報道は、GitHubが運用面の課題に直面している時期にCursorが参入機会を見いだした、という構図を描いている。プラットフォームの乗り換えは普段なら起きにくいが、既存基盤への不満が高まっている局面では、新興プレイヤーが食い込む余地が生まれる。ただしこれはあくまで報道ベースの見立てであり、GitHubの実際の安定性やシェアの変動を示す確定データではない。Originがこの「機会」を実際に物にできるかは、提供開始後の品質と移行体験にかかっている。ここでも、発表段階の物語と実証データを混同しないことが重要だ。
Originが本当にGitHubを脅かすかは、早期ベータが出た2026-09-04時点でもまだ判断できない。出荷されたのはホスティングの基本機能までで、Issue管理・Marketplace相当・移行ツールは揃っていないからだ。ここで言えるのは「Cursorがホスティング層に実際に参入した」ことまでで、本記事は勝敗の予測はしない。
GitHub側のエージェント統合戦略(Agent HQ構想)と比べると、両社の方向性の違いがよく分かる。GitHubは「あらゆるエージェントを既存のGitHub上に束ねる」アプローチで、GitHubはこれを「Agent HQ」構想として打ち出している。対してCursorは「エージェント前提のホスティング基盤を自前で作り直す」アプローチで、土俵そのものを動かしにきている。
発表時に掲げられた機能の一覧(2026年6月)
発表およびライブデモで言及された主要機能を、出典の種類とともに一覧化する。いずれも発表・参加者報告ベースで、公式ドキュメントによる詳細仕様は未公開である点に注意してほしい。
| 領域 | 掲げられた内容 | 出典・確度 |
|---|---|---|
| 基盤の性格 | 「エージェント時代のためのGitフォージ」。Git互換のコードホスティング | 公式サイト(確認済み) |
| スケーラビリティ | 複数エージェントの並列クローン/コミット/リベースに耐える設計 | 発表・参加者報告 |
| 書き込み性能 | 単一リポジトリで22.6コミット/秒(公称・デモ値) | 参加者報告(要再現検証) |
| 拡張性 | APIとMCP(Model Context Protocol)で拡張可能 | 発表・参加者報告 |
| マージ衝突 | エージェントが生む衝突の自動解決を内蔵 | 発表・参加者報告 |
| CI連携 | CI失敗をエージェントが解決する仕組み | 発表・参加者報告 |
| ストレージ | S3バックエンドの「無限レプリカ」。発表スライドは公称 296,064 clones/hr・81,360 pushes/hr | 発表スライド(公称) |
| 可用性 | <400ms ワールドワイド同期・<10ms 自動フェイルオーバー(いずれも公称) | 発表スライド(公称) |
| リポジトリ管理 | ホスティング・セキュリティレビュー・自動テスト・更新管理を企図 | 報道(The Information) |
発表スライドには、Originの公称スケーラビリティ指標が並んでいた。下の写真がその実物だ。
発表当時、公式サイトで直接確認できたのは「Gitフォージである」という性格づけとウェイトリストの存在のみだった。残りは発表ステージでの言及、参加者の実況ポスト、あるいは事前の報道に依拠している。この表がどこまで実現したかは、後述の「早期ベータで実際に出荷されたもの」で答え合わせをする。とくに22.6コミット/秒のような数値は、デモという統制された環境での公称値であり、実運用での持続的なスループットを保証するものではない。記事として扱う際は「公称」と明記するのが妥当だ。
書き込みスループットのデモは発表参加者の間でも話題になった。開発者のNick Dobos氏のポストが象徴的だ。
Lmfao cursor origin supports 22.6 commits a second (in a single repo).(笑、Cursor Originは単一リポジトリで毎秒22.6コミットを捌くらしい)
数字のインパクトが先行している段階であり、これがどんな条件下での値なのか(コミットサイズ、並列クライアント数、永続化の保証レベルなど)は公式の技術資料が出てから検証すべき論点だ。
GitHub との対比表
現時点で語られている範囲で、GitHubとCursor Originを並べてみる。Origin側は「発表内容ベース」であり、確定仕様ではない。確定していない項目は「未公開」と明記する。
| 項目 | GitHub | Cursor Origin(発表時点) |
|---|---|---|
| 提供状況 | 一般提供中(長年の実績) | 早期ベータで提供中(2026-08-17〜/有料プラン限定) |
| 設計思想 | 人間中心。後からエージェント機能を追加(Agent HQ等) | エージェントネイティブ(最初からエージェント前提) |
| Git互換 | あり | あり(と説明) |
| 並列書き込み負荷 | 通常のチーム開発を想定 | 多数エージェントの並列を主眼に設計(公称) |
| マージ衝突対応 | 手動解決が基本 | 自動解決を内蔵(と説明) |
| CI/CD | GitHub Actions等の成熟したエコシステム | CI失敗のエージェント解決を掲げる(詳細未公開) |
| 拡張 | REST/GraphQL API・Marketplace・MCP対応 | API・MCP拡張(仕様未公開) |
| エコシステム | Issue/PR/Projects/Pages/Packages等が成熟 | 未公開(ホスティング中核以外の範囲は不明) |
| 料金 | 無料枠+有料プラン体系が確立 | 未公開 |
| OSS可否 | 製品自体はクローズド | 未公開 |
この表を見ると、現状の比較は「成熟した実績」対「設計思想の主張」という非対称な構図になっていることが分かる。GitHubには十数年積み上げたエコシステム(Actions、Marketplace、Issue/PR運用文化)があり、Originにはまだそれがない。一方でOriginは「エージェント前提」という設計の新しさを武器にしている。どちらが優位かは、Originのエコシステムがどこまで揃うか、そして既存リポジトリの移行がどれだけ滑らかかにかかってくる。
GitHub側の動向は GitHub Copilot、インタラクションデータ利用ポリシーを更新 のような運用ポリシーの変化も含めて追える。Originを評価する際の「対抗馬の現在地」として参照すると、比較の解像度が上がる。
発表内容の「確度」で切り分けた早見表
同じ「Originの機能」でも、公式が明言したものと、参加者報告や公称デモ値では確度が違う。導入検討の材料にするなら、この区別を持っておきたい。
| 項目 | 内容 | 確度 |
|---|---|---|
| Gitフォージであること | cursor.com/origin が “A git forge for the agentic era” と明示 |
公式 |
| Fall 2026 提供・ウェイトリスト | 公式サイトの記載(→実際は2026-08-17に前倒しで出荷) | 公式・後に更新 |
| Graphite買収 | 同じステージで告知 | 公式 |
| Graphite出身エンジニアが開発主導 | 複数の参加者が報告 | 参加者報告 |
| 単一リポジトリ 22.6コミット/秒 | ライブデモで提示されたとされる公称値 | 公称値(第三者検証なし) |
| マージ衝突の自動解決・CI失敗のエージェント解決 | 売り文句として提示 | 公称(実物未公開) |
| 料金・SLA・セルフホスト可否 | 言及なし | 未確認 |
AIエージェント前提の設計(Agent Nativeの中身)
Originの核心は「Agent Native(エージェントネイティブ)」という設計思想だ。これが何を意味するのか、発表で語られた範囲を整理する。
従来のGitホスティングは、基本的に「人間が、たまにコミットする」前提で最適化されてきた。プッシュの頻度はせいぜい1人あたり1日数回〜数十回で、マージ衝突は人間がレビューしながら手で解く。ところがエージェント並列運用では、数十〜数百のエージェントが同じリポジトリに対して同時にブランチを切り、コミットし、リベースし、PRを出す。この負荷は従来の前提を大きく外れる。
発表で示された設計上の対応は、大きく次の3点に整理できる。出典は発表・参加者報告だ。
・並列書き込みのスケール:多数のエージェントが同時に書き込んでも詰まらないよう設計。デモでは単一リポジトリ22.6コミット/秒(公称)を提示した
・マージ衝突の自動解決:エージェントが並列作業で必然的に生む衝突を、人手を介さず解消する仕組みを内蔵すると説明された
・CI失敗のエージェント解決:CIがコケたとき、その修正をエージェントに回して自律的に直させる流れを想定している
下図は、Originが想定する「エージェント並列ワークフロー」の概念を整理したものだ。1つのリポジトリに対して複数エージェントが同時に作業し、衝突とCI失敗をプラットフォーム側が吸収する構図を表す。
(Origin)"] --> A1["Agent A
ブランチ/コミット"] R --> A2["Agent B
ブランチ/コミット"] R --> A3["Agent C
ブランチ/コミット"] A1 --> MC["マージ衝突
自動解決"] A2 --> MC A3 --> MC MC --> CI["CI実行"] CI -->|失敗| FR["CI失敗を
エージェントが解決"] FR --> CI CI -->|成功| M["メインへ統合"] M --> R
拡張性の面では、APIとMCP(Model Context Protocol)への対応が掲げられた。MCPは、AIエージェントが外部ツールやデータソースに接続するための共通規格で、Cursorをはじめ各社が採用を進めている。OriginがMCPで拡張できるということは、エージェントがホスティング基盤そのものを「ツールとして」操作する設計を意識している、と読める。ただし具体的なAPIエンドポイントやMCPの対応範囲は、公式ドキュメントが出るまで未確認だ。
マージ衝突の自動解決もCI失敗の自律修正も、発表段階では「掲げられた機能」であって、実運用での精度・安全性は未知数だ。とくに自動マージは、誤った解決が静かに混入するリスクと隣り合わせで、ここは提供開始後に最も検証されるべき領域になる。発表の言葉をそのまま「できる」と書かないのが安全だ。
Graphite買収とCursorエコシステム
今回の発表で見逃せないのが、Originが「Graphiteを買収した」という告知と同じステージで披露された点だ。Graphiteはコードレビュー(スタックドPR、レビュー効率化)を手がけるスタートアップで、報道によればOriginの開発はGraphite出身エンジニアが主導している。発表者のTomas Reimers氏自身がGraphiteの共同創業者として知られる人物だ。
この組み合わせから、Cursorが描くエコシステムの輪郭が見えてくる。編集・レビュー・ホスティングを縦に束ねる構想だ。下図に整理する。
(エディタ・編集)"] ED --> CM["Composer
(エージェント並列実行)"] CM --> GR["Graphite由来
(レビュー)"] GR --> OR["Origin
(ホスティング・統合)"] OR --> API["API / MCP
(外部連携)"] OR --> ED
つまりCursorは、開発者がコードに触れる入口(エディタ)を押さえたうえで、その下流にあたるレビューとホスティングまで自社で取りに行こうとしている。コミュニティの一部はこれを「Cursor for everything(何もかもCursorで)」と表現した。GitHubが長年握ってきた「コードが集まる場所」というポジションを、Cursorがエディタ起点で奪いに来た——という構図だ。
編集・レビュー・ホスティングが別々のサービスだと、エージェントは境界をまたぐたびに文脈を失う。同じ会社が縦に統合すれば、エディタで生まれた意図をレビューやマージまで途切れず引き継げる可能性がある。Originの「エージェントネイティブ」は、この縦統合とセットで初めて意味を持つ設計だと読める。
なお、Cursorとそれ以外のAIコーディング環境(CLI型のClaude CodeやCodex CLI)との立ち位置の違いは、 Claude Code vs Cursor徹底比較2026年版:CLI派とIDE派、どちらを選ぶべきか で整理している。Originの登場は、この「どのエコシステムに乗るか」という選択に、ホスティング層という新しい論点を加えることになる。
Cursor Origin の対応プランと有効化手順(早期ベータ)
ここからが2026年9月4日の更新分だ。まず「自分は使えるのか」に答える。
公式ドキュメントは対象プランを次の一文で明示している。無料プランは対象外だ。
Origin code storage is available on Pro, Teams, and Enterprise plans. It is not available on free plans.(Originのコードストレージは Pro・Teams・Enterprise プランで利用できます。無料プランでは利用できません)
注意したいのは、changelog の「全有料プランに本日から提供」という表現と、ドキュメントの記述に温度差がある点だ。ドキュメントは続けて “Access opens in stages, so you may not see Origin immediately after it becomes available for your plan.”(アクセスは段階的に開放されるため、自分のプランが対象になった直後にOriginが見えるとは限らない)と書いている。つまり「有料プラン=即日使える」ではない。表示されなくても障害とは限らない、という前提で待つのが正しい。
有効化の手順自体は短いが、一度きりで後戻りできない選択が含まれる。
・①コードベース名を確保する:チームの誰か1人が cursor.com/codebase で「Get Started」を選び、コードベース名を決める
・②その名前がURLの一部になる:https://cursor.com/codebase/{owner}/{repo} の {owner} に入る。GitHubのorg名に相当する
・③ベータ中は改名できない:ドキュメントは “During the beta, you can’t change or update your namespace after it’s claimed.” と明記している
名前空間はチーム単位で一度しか決められず、ベータ期間中は変更・更新ができない。個人の思いつきで確保すると、その名前が全リポジトリのURLに残り続ける。チームで使う予定があるなら、誰が・どの名前で確保するかを先に合意してから踏むこと。もう一点、プライバシーモードは「名前空間の所有者(チームまたは個人)の設定に従う」仕組みで、レガシーなプライバシーモードのチームはOriginを有効化できないとドキュメントに記載がある。
早期ベータで実際に出荷されたもの(CLI実測)
「掲げられた機能」と「出荷された機能」を突き合わせる。ここが本記事の更新の核心だ。
まず公式CLIを実際に導入した。インストーラは公式ドキュメントに載っている次の1行で、2026-09-04時点で実行して動作を確認している。
curl -fsSL https://downloads.cursor.com/origin/install.sh | sh
このインストーラは読む価値がある。中身を確認したところ、プラットフォーム別にSHA256をスクリプトへ焼き込んでから検証している(curl | sh としては堅い作りだ)ほか、公開情報に出てこない事実がいくつも読み取れた。
・対応OSは macOS と Linux のみ。*) fail "unsupported OS: $os (mac and linux only)" と書かれており、Windowsビルドは配布されていない(WSL経由なら動く見込みだが、公式の明言はない)
・Linuxは glibc のみ。musl は明示的に拒否される(fail "musl libc is not supported yet (glibc only).")。Alpineベースのコンテナでは動かない
・チャンネルが2系統ある。stable と latest があり、ORIGIN_INSTALL_CHANNEL 環境変数で切り替わる。実行時点の stable は 2026.09.01、latest は 2026.09.03 のビルドだった
・配布物の内部名は co。CDN上のパスは /co/<version>/<platform>/co.tar.gz で、展開後も origin の隣に co という旧名のハードリンクが残る。スクリプトのコメントは「公開の入口だけが origin/」と説明している
導入した origin --version は 2026.09.01-22-54-12-04810e3 を返した。そして origin --help が見せるサブコマンドは、changelogの説明より明らかに広い。
| サブコマンド | 役割 | changelogでの言及 |
|---|---|---|
repo | リポジトリの作成・一覧・閲覧・クローン・削除、GitHubミラーの作成 | あり |
pr | PRの操作 | あり |
auth | ログイン、git認証の設定(auth setup-git)、状態確認 | 言及なし |
ruleset | マージ時・プッシュ時のルールセットの参照(GitHubのブランチ保護に相当) | 言及なし |
ssh-key | Originアカウントに登録するSSH鍵の管理 | 言及なし |
api | api.cursor.com/v1/origin への認証付きリクエスト(gh api 相当) | 言及なし |
push local | forge-local リモートを設定し refs/heads/origin/* を /local エンドポイントへ送る | 言及なし |
とくに ruleset と api は重要だ。ルールセットが実装されているということは、Originが「置くだけの箱」ではなくブランチ保護まで含むフォージとして設計されていることを意味する。また api のヘルプが接続先を api.cursor.com/v1/origin と明記していることから、REST APIは確かに存在する。ただしエンドポイント一覧を含む公開APIリファレンスは見つけられなかったため、外部から叩ける範囲は未確認とする。
未ログインでどこまで進めるか(実測)
ここが本記事の限界でもある。筆者はCursorの有料プラン契約を持っていないため、リポジトリを作成して実際にpush/PRまで試すことはできていない。代わりに、認証がどこで止まるかを実測した。
| 実行したコマンド | 結果 | 終了コード |
|---|---|---|
origin --version | 2026.09.01-22-54-12-04810e3 | 0 |
origin auth status | Not logged in. Run `origin auth login` to sign in. | 1 |
origin repo list | Error: Not authenticated. Run `origin auth login` or set CURSOR_API_KEY. | 1 |
origin api /repos | 同上(未認証で拒否) | 1 |
git ls-remote https://cursor.com/codebase/<owner>/<repo> | HTTP 403 | 128 |
分かったことが3つある。1つ目は、エラーメッセージが CURSOR_API_KEY 環境変数での認証に触れていること。ブラウザログイン以外にトークン認証の経路があり、CI用途を想定していると読める。2つ目は、gitのエンドポイントがGitHubのような専用ホストではなく、Webと同じ cursor.com/codebase/{owner}/{repo} であること(git.cursor.com は名前解決すらしない)。未認証だと /info/refs が 307 で authenticator.cursor.sh のSSOへ飛ばされる。3つ目は、未認証時はすべて fail-closed で、部分的に読める・書けるといった穴は観測されなかったことだ。
リポジトリ作成・push・PR作成・GitHub同期の実挙動・ルールセットの効き方は、有料プランのアカウントが必要なため本稿では検証していない。同期の遅延やマージの挙動について本記事が数値を書いていないのは、測っていないからだ。他媒体が「数秒で同期される」と書く場合、それがchangelogの引き写しなのか実測なのかは切り分けて読むことをすすめる。
発表時の目玉は、まだ出ていない
出荷物を発表時の売り文句と突き合わせると、はっきりした欠落がある。
| 2026年6月の発表で掲げられた内容 | 2026年8月17日の出荷物での扱い |
|---|---|
| リポジトリのホスティング | 出荷済み |
| PR・コードレビュー | 出荷済み(GitHubと双方向同期) |
| マージ衝突の自動解決 | 記載なし(changelog・公式ドキュメント・製品ページのいずれにも "conflict" の語が無い) |
| CI失敗のエージェント解決 | 記載なし。CIはDepot・Buildkiteの接続で既存のGitHub Actionsを動かす方式 |
| API・MCPでの拡張 | APIはCLIから存在を確認。MCPは公式ドキュメントに記載を確認できず |
| 単一リポジトリ22.6コミット/秒 | 記載なし(出荷時の公式3面から数値が消えている) |
changelog自身が “Agent-native features ship soon.”(エージェントネイティブ機能はまもなく出荷)と書いており、Cursorも現状を「まだ基礎部分」と位置づけている。つまり2026年9月4日時点のOriginは、「エージェント時代のためのGitフォージ」という看板に対して、まだ普通のGitフォージの段階にある。発表時の22.6コミット/秒という数値も、出荷後の公式資料からは静かに姿を消した。撤回の告知は無く、単に触れられていないだけなので、発表時のデモ公称値として扱い、現在の性能指標として引用しないのが妥当だ。
早期ベータの制約と、いま未確認の領域
中立に読むために、2026年9月4日時点で分かっていないことを明示しておく。出荷されたことで埋まった項目もあるが、実務判断に効く空白はまだ残っている。
・マージ衝突の自動解決・CI失敗のエージェント解決:出荷物に記載なし。実装時期も未告知
・Issue管理:早期ベータの機能一覧に含まれない。GitHubのIssue運用をそのまま移すことはできない
・既存リポジトリの移行手段:GitHub「同期(ミラー)」は出荷されたが、これはGitHubを正とし続ける機能で、PR履歴・ラベル・権限ごとOriginへ引っ越す「移行」とは別物。移行パスは依然として未公開
・リポジトリ容量・レート制限:上限値の記載を確認できず
・ベータ終了後の課金:Origin単体の価格・有料プランへの同梱が続くかは未公開
・公開APIリファレンス:CLIから api.cursor.com/v1/origin の存在は確認できたが、エンドポイント一覧のドキュメントは見つけられなかった
・MCP対応:発表時の売り文句だが、公式ドキュメントでの記載を確認できていない
・性能値:22.6コミット/秒は2026年6月のデモ公称値で、出荷後の公式資料には無い。第三者再現検証もない
・Windows対応:公式インストーラは mac と linux のみを受け付ける。Windowsネイティブの配布は確認できない
・学習データの扱い:ホストしたコードがモデル学習に使われるかという論点について、Origin固有の明示は確認できていない(プライバシーモードは名前空間所有者の設定に従う、との記載のみ)
これらは「ない」と断定できるものと、「まだ公表されていない」ものが混在している。本記事では前者(Issue管理・Windows配布・conflictの記載)は出荷物を確認したうえで書き、後者は「未確認」と明示して分けた。
とりわけ実務で効くのが「移行手段」の有無だ。既存のGitHubリポジトリを、Issue・PR履歴・CI設定・権限まで含めてどこまで持ち込めるかは、Originを採用できるかどうかの分水嶺になる。コードだけならgit remoteの付け替えで済むが、チームの運用資産(レビュー履歴、ラベル、自動化)はそう簡単には動かない。発表ではこの移行体験について具体的な説明がなく、ここが空白のままだと、いくら設計が優れていても乗り換えのハードルは高いままになる。提供開始時に最初に確認すべき項目として挙げておきたい。
業界インパクト
Originの発表は、AIコーディングの主導権争いが「エディタ」から「コードが集まる場所」へと広がりつつあることを示している。整理すると、いま3つの陣営が異なるアプローチで重なり合っている。
・GitHub(Microsoft):既存の巨大プラットフォームの上に、あらゆるエージェントを束ねるAgent HQ構想を載せる「統合」路線
・Cursor(Anysphere):エディタ起点で、レビュー(Graphite)・ホスティング(Origin)まで縦に取りに行く「自前エコシステム」路線
・Anthropic / OpenAI:Claude CodeやCodexのようなエージェント本体・CLIで、どのホスティングにも乗れる「ツール中立」路線
Cursorがホスティングまで踏み込んだことで、開発チームは「どのエディタを使うか」だけでなく「どのプラットフォームにコードを置くか」という、より重い意思決定を意識せざるを得なくなる。ホスティングはロックインが強く効く領域だけに、ここでの選択は数年単位の影響を持つ。
一方で、GitHubの優位は依然として大きい。Actions・Marketplace・Issue運用文化・既存リポジトリの慣性は一朝一夕には動かない。CursorのClaude/Codexとの関係も注目点だ。CursorはエディタとしてClaudeやGPT系モデルを使えるが、ホスティングで自社路線を強めれば、ツール中立を掲げるAnthropic・OpenAIとの距離感が微妙に変わる可能性もある。Claude Code側でもGitHub連携の動きは続いており、ホスティング層の主導権争いは1社の問題では収まらない。
いま「試す」段階には入ったが、「乗り換える」段階ではない。有料プラン契約があるなら、(1) チームでコードベース名を合意してから確保する(ベータ中は改名不可)、(2) まずGitHub同期で読み取り側だけ繋いで挙動を見る(同期はGitHubを正とするので既存運用を壊さない)、(3) Issue管理と移行手段が埋まるまで正となるリポジトリは動かさない——の3点を推奨する。changelogが「エージェントネイティブ機能はまもなく」と書いている以上、Originの本命はまだ出ていない。
まとめ
Cursor Originは、2026年6月16日に「エージェント時代のためのGitフォージ」として発表され、当初の予告(Fall 2026)より早く2026年8月17日に早期ベータで出荷された。対象は Pro・Teams・Enterprise で、無料プランは対象外。アクセスは段階的に開放されるため、条件を満たしていても即日見えるとは限らない。
ただし出荷されたのは、リポジトリ・PR・コード閲覧・GitHub双方向同期というフォージの基礎部分だ。発表時の目玉だったマージ衝突の自動解決は出荷物のどこにも記載がなく、CIも自前ではなくDepot・Buildkiteの接続で既存のGitHub Actionsを動かす方式、Issue管理に至っては機能一覧に無い。changelog自身が “Agent-native features ship soon.” と認めている。看板の「エージェント時代のため」を実現する部分は、まだこれからである。
一方でCLIを実際に導入すると、公開情報より広い実装が見えた。ブランチ保護に相当する ruleset、SSH鍵管理、gh api 相当の api サブコマンドがすでに存在する。配布はmacOSとLinux(glibc)限定で、Windowsビルドは無い。リポジトリの実操作は有料プランが要るため本稿では未検証だが、未認証時の挙動はすべてfail-closedだった。
次の節目は、エージェントネイティブ機能の出荷と、GitHubからの「移行」(同期ではなく)パスの提示になる。この2つが埋まって初めて、GitHubの実質的な代替になり得るかを判断できる。本記事は発表当日から同じ項目を追い続けており、今後も公式情報が出た時点で更新していく。
参照ソース
・Cursor Changelog「Origin Code Hosting」(2026-08-17) — 早期ベータ提供開始の一次発表。日本語版 /ja/changelog/origin-code-hosting と内容を突き合わせ、節構成・記述に欠落が無いことを確認済み
・Cursor Docs「Origin」 — 対応プラン(Pro/Teams/Enterprise・無料プラン不可)、段階的開放、名前空間がベータ中は変更不可、プライバシーモードの扱い
・Origin CLI 公式インストーラ(downloads.cursor.com/origin/install.sh) — 対応OS(mac/linuxのみ・musl非対応)、SHA256検証、stable/latestチャンネル、内部名 co。2026-09-04に取得・実行して確認
・Cursor Origin 公式ページ(cursor.com/origin) — キャッチコピー “A git forge for the agentic era”、2026-09-04時点の表記は “Early beta now available on all paid plans”
・swyx 氏のポスト(@swyx) — 発表内容の実況、API/MCP・マージ衝突・CI失敗解決の言及
・Ray Fernando 氏のポスト(@RayFernando1337) — “Agent Native Git platform”、Graphite買収との同時発表
・Nick Dobos 氏のポスト(@NickADobos) — 22.6コミット/秒(公称・デモ値)
・Morgan Linton 氏の投稿(LinkedIn・@morganlinton) — 発表現場(SF・Compile)の動画、Originの初出言及
・The Information(VFF経由まとめ) — Origin開発の事前報道、リポジトリホスティング・セキュリティレビュー・自動テスト・更新管理、Graphite出身チーム主導