Cursor Gitホスティング「Origin」とは｜GitHub代替の狙いと2026年秋の動向

AIコードエディタのCursorが、2026年6月16日に独自のGitホスティング「Origin」を発表しました。Originは「a git forge for the agentic era（エージェント時代のためのgit forge）」を掲げ、コードの保存・レビュー・共同作業を担うGitHubの代替を志向するプラットフォームです。本記事では、発表時点で確定している事実、エージェントを前提とした設計の理由、S3やMCP拡張を含む技術アーキテクチャ、GitHub・GitLabとの違い、Graphite買収から続く垂直統合戦略、そして2026年秋の正式提供を見据えて開発チームやエンタープライズが今できる準備までを整理します。Cursor GitホスティングOriginの全体像と検討の要点を、一次情報に基づいて解説します。

まとめ：エージェント前提のGit基盤Originの位置づけと検討の要点

Originは、Cursorが2026年秋の提供開始を予定するGit互換のコードホスティングです。最大の特徴は、人間ではなく多数のAIエージェントが並列でコードを書き、レビューし、マージする状況を初めから前提に設計されている点にあります。GitHubが2008年に人間の開発者向けに設計されたのに対し、Originはエージェント時代の負荷とワークフローに合わせて作り直された「git forge」だと整理できます。

現時点での結論として、Originは「今すぐGitHubから移行する製品」ではなく、waitlist登録のうえで秋の正式提供と料金公開を待つ評価フェーズの対象です。検討の軸は、自社がどの程度エージェント主導の開発に踏み込んでいるか、単一ベンダーへの依存をどこまで許容できるか、そして既存のGitHub/GitLab運用と併存しながら検証できるか、の3点に集約されます。各論の根拠・手順・比較は本文で詳述します。

Cursor Gitホスティング「Origin」の概要と発表時点で確定している事実

まず、憶測と確定情報を分けて押さえます。Originは新製品であり、断片的な情報が流通しています。ここでは公式発表で確認できる事実だけを整理します。

2026年6月16日「Compile」基調講演でのOrigin発表内容

Originは、Cursorが初開催した「Compile」基調講演（2026年6月16日）で発表されました。公式アカウント @cursor_ai は「code storage and git hosting（コード保存とGitホスティング）を立ち上げる」と告知し、チームとエージェントがコードをホスト・レビュー・共同作業するための場所だと説明しています。発表は大きな反響を呼び、GitHub・GitLab・Bitbucketに続くGit基盤として注目されました。デモは買収先Graphiteの共同創業者Tomas Reimersが壇上で実施しています。

「a git forge for the agentic era」が示す製品コンセプト

製品ページに掲げられたタグラインは「a git forge for the agentic era」、補足コピーは「コードはどんなインフラの想定よりも速く動いている。Originはこの瞬間のために設計された」という趣旨の一文です。forge（フォージ）とは、リポジトリ本体に加えてレビューや共同作業の層まで含むホスティング基盤を指す呼称で、GitそのものよりもGitHubやGitLabに近い役割を持ちます。コンセプトは「人間向けに作られた基盤を、エージェント主体の開発に合わせて作り直す」という一点に集約されます。

waitlist登録のみ・正式提供は2026年秋という現在の提供状況

発表時点でOriginは一般提供されておらず、利用にはwaitlist（順番待ちリスト）への登録が必要です。正式提供（一般提供）の時期は「2026年秋（fall 2026）」と告知されています。つまり2026年6月時点では、製品の実機検証はできず、公式サイトもタグラインとwaitlist登録ボタンが中心の状態です。早期アクセス枠の配分方法も公開されていません。

コード保存・レビュー・共同作業を担うgit forgeとしての役割

Originが担うのは、Gitリポジトリのホスティングに加え、その上に乗るレビューと共同作業の層です。これはGitHubやGitLabと同じレイヤーであり、ローカルのGitコマンドそのものを置き換えるものではありません。Git互換であることが明言されているため、既存のGitワークフローを維持したままホスティング先として利用する構図が想定されます。

料金未公表など発表時点で未確定な情報の切り分け

料金体系、早期アクセスの具体的な条件、対応リージョン、オンプレミス提供の有無などは、いずれも発表時点で公開されていません。コミット単位の課金を懸念する声もコミュニティで上がっていますが、これは公式情報ではなく推測です。導入判断にあたっては、公式の料金公開を待つ姿勢が安全です。未確定情報を確定事実のように扱わないことが、この段階では最も重要です。

Originがエージェント前提で設計される理由とGit本来の人間前提との差

Originの設計思想は、Gitとそのホスティングが「人間の作業ペース」を前提に作られてきた、という認識から出発しています。ここでは、なぜエージェント前提が必要になるのかを負荷の観点から整理します。

人間前提のGitワークフローが数時間〜数日単位である前提

従来の開発では、1人の開発者がブランチを切り、数時間かけてコードを書き、プルリクエストを出してレビューを待ちます。この一連のサイクルは時間〜日単位で進みます。GitHubのレビューUIやインラインコメント、マージボタンは、いずれも「人間が差分を読んで判断する」ことを前提に最適化されてきました。Originはこの前提自体を問い直しています。

数十〜数百エージェントが秒単位で並列処理する負荷プロファイル

一方、AIエージェントの働き方は根本的に異なります。数十〜数百のエージェントが、同一コードベースを同時にclone・branch・commit・rebaseし、それを秒単位で繰り返す可能性があります。これは人間中心のホスティングが想定してこなかった負荷プロファイルです。Originは「大量のエージェントが並列でclone・commit・rebase・review・失敗修正を行う」状況を初期前提として設計されている点が、既存基盤との決定的な違いです。

レビュー能力がコード生成速度に追いつかないボトルネック

AIでコード生成を加速したチームほど、人間のレビュー能力が同じ速度では拡張しないという壁に直面します。生成量が増えるほど、レビューと安全なマージが新たなボトルネックになります。Originは、AIが生成したPRをAIレビュアーへ振り分け、人間は行単位ではなく承認ゲートで監督する、という発想でこの問題に応えようとしています。Cursorが2025年にGraphiteを買収した狙いも、まさにこのレビュー律速の解消にありました。

エージェントを一級市民として扱う設計判断の具体的な意味

「エージェントを一級市民（first-class citizen）として扱う」とは、AIを人間向けシステムへ後付けするのではなく、AIの利用を前提に各機能を作る、という設計判断です。具体例として、人間向けにHTMLレンダリングされた差分ではなく、エージェントが効率的に解釈できる構造化された差分APIを基盤側に組み込む構想が挙げられます。人間が文書を毎回印刷して読むのに対し、機械が直接データを読む違いに近い発想です。

AIによるマージコンフリクト自動解決エンジンの位置づけ

Originには、コンフリクトの文脈や各エージェントの変更意図を解析し、多くのケースで人手を介さずマージを完了させるAI主導のコンフリクト解決エンジンが組み込まれると説明されています。Graphiteのstacked pull requestで培った複雑なマージ処理の知見が、この基盤になっています。ただし「ほとんどのケース」という表現は、最終的な承認は人間が担う設計を排除するものではありません。

Originの技術アーキテクチャ｜S3・NVMe・無限レプリカとAPI/MCP拡張

ここからは検討段階として、発表時のプレゼンで示されたアーキテクチャを整理します。数値は公式デモに基づくもので、独立した第三者ベンチマークではない点に留意してください。

信頼の源泉としてのS3オブジェクトストレージ採用

Originは、信頼の源泉（source of truth）としてS3オブジェクトストレージを採用すると説明されています。リポジトリの実体をオブジェクトストレージに置く構成は、耐久性とスケールを確保しやすい一方、低レイテンシのGit操作には工夫が要ります。Originはここに後述のNVMe層を組み合わせ、保存の堅牢さと操作の速さを両立させる狙いです。

NVMeベースGitファイルサーバと無限レプリカによる世界同期

S3を背後に置きつつ、前段にNVMeベースのGitファイルサーバを配置し、Cursorが「無限レプリカ（infinite replicas）」と呼ぶ仕組みで世界規模の同期と高速な自動フェイルオーバーを実現すると説明されています。地理的に分散したエージェントとチームが、低遅延で同じリポジトリにアクセスできる構成を志向するものです。これは、並列アクセスのスケールを物理層から支える設計と言えます。

22.6コミット/秒のデモ値が示すスループット設計の狙い

壇上デモでは、単一リポジトリで毎秒22.6コミットというスループットが示されました。1つのリポジトリに秒間20件超のコミットが集中する状況は、人間中心の開発ではほぼ起こらず、エージェント並列を前提とした数値です。この値は、Originが「どの程度の並列度を捌く想定か」を端的に示す指標として読むのが適切です。

API・MCP拡張による外部ツールとエージェントの連携余地

Originは、APIに加えてMCP（Model Context Protocol）を通じて拡張可能だと説明されています。これにより、外部ツールやエージェントがホスティング・レビュー・マージの各ワークフローへ統合できる構図です。MCPはエージェントと外部リソースを接続する標準的なプロトコルで、たとえばClaude CodeとSerena MCPの統合のように、エージェントへMCP経由で外部機能を与える実例がすでに広がっています。Originがこの層を一級機能として持つことは、エージェント連携のしやすさに直結します。

毎時数十万クローンの数値を規模の主張として読む注意点

デモのスライドでは、毎時約296,000回のcloneと約81,000回のpush、加えて400ミリ秒未満のグローバル同期や10ミリ秒以内の自動フェイルオーバーといった値が示されました。ただしこれらはあくまで基調講演のデモ値であり、計測条件まで検証された第三者ベンチマークではありません。公式が正式な性能値を公開するまでは、過大評価も過小評価も避け、エージェント並列を狙う規模感の参考値として扱うのが妥当です。

Origin・GitHub・GitLabの違い｜ホスティング層の設計思想と対象ユーザー

導入判断には、既存プラットフォームとの位置づけ比較が欠かせません。ここでは設計思想・対象ユーザー・AI機能の入れ方という観点で違いを整理します。

対象ユーザーの違い（人間中心の協働か、エージェント中心か）

最大の違いは「誰のために作られたか」です。GitHubは人間の開発者の協働、GitLabはDevSecOpsを含む統合的な開発ライフサイクル管理を中心に据えてきました。対してOriginは、エージェントが主要な利用者になる前提で設計されます。同じGit互換のホスティングでも、最適化の起点が人間か機械かで、UIやAPIの優先順位が変わってきます。

レビュー・マージUIの設計思想と差分処理の前提差

GitHubの差分ビューは人間が読むために高度に作り込まれています。一方Originは、エージェントが解釈しやすい構造化差分を基盤に置く想定で、レビュー時の処理コストを下げる狙いがあります。GitHubとGitLabの差はCI/CDの統合度や運営思想にありますが、両者の比較軸についてはGitHubとGitLabにおけるCI/CD機能の違いが参考になります。Originはこの比較軸に「機械可読性」という新しい観点を持ち込みます。

AI機能の組み込み方の比較（Copilot・GitLab Duo・Origin）

AI機能の入れ方も三者三様です。GitHubはGitHub Copilotをエディタ補完として、GitLabはGitLab DuoをDevSecOpsライフサイクル全体の支援として展開し、いずれも既存基盤へAIを付加する形です。Originはこの逆で、ホスティング層そのものをエージェント前提で作り直し、AIを後付けではなく土台に据えます。GitHubも「Agent HQ」構想（GitHub Universe 2025発表）でエージェント統合を進めており、競争は始まったばかりです。

ホスティング層を整理する比較表（設立背景・対象・拡張性）

主要なGitホスティングを設計起点で整理すると、次の通りです。Originは提供前のため、公開情報に基づく方向性として記載します。

この表は方向性の整理であり、Originの確定仕様ではありません。正式提供後に料金・対応環境を加えて再評価する前提で参照してください。

選定時に効く判断基準（既存資産・規模・依存リスク）

選定では、既存のコード資産とCI/CD連携をどれだけ維持できるか、エージェント並列の規模が自社で現実的か、単一ベンダー依存をどこまで許容するか、が判断基準になります。例えば、エージェント活用がまだ限定的なチームでは、Originの並列スループットの恩恵は小さく、移行コストが上回ります。逆に背景エージェントを常用するチームほど、Originの設計が効いてきます。

Graphite買収から続くCursorの垂直統合戦略とコンテキスト連続性の狙い

Originは単独の製品ではなく、Cursorの一連の統合戦略の延長線上にあります。ここでは、その戦略的背景を読み解きます。

2025年12月のGraphite買収から続く統合の流れ

Cursorは2025年12月19日、コードレビューのGraphiteを買収する最終契約を発表しました。Graphiteは創業者Merrill Lutsky・Greg Foster・Tomas Reimersが立ち上げ、stacked pull requestワークフローで知られます。Originの技術はこのGraphite由来であり、買収から半年でホスティング層への展開に至った形です。買収時点で示された「コードを書く場と協働する場の境界をなくす」という構想が、Originとして具体化しました。

編集・レビュー・ホスティングを同一企業で揃える三層構造

Cursorは、編集（CursorとComposer）、レビュー（Graphite）、ホスティング（Origin）という三層を同一企業で揃えました。これにより、エージェントが書いた変更の「意図」を、PRやコミットメッセージ、レビュー画面まで途切れさせずに引き継げる構図を狙っています。レビュー層のAI活用という観点では、Claude Codeによるコードレビューの実践のように、編集とレビューを近接させる動きが業界全体で進んでいます。

stacked pull requestワークフローがOriginに与える素地

Graphiteのstacked pull requestは、依存関係のある複数の変更を積み重ねて並行管理する手法です。これは、多数のエージェントが相互に依存する変更を同時に進める状況と相性が良く、Originのマージ設計の素地になっています。複雑なマージシナリオを扱ってきた実績が、AI自動コンフリクト解決の現実味を支えています。

エディタからGitまで貫くコンテキスト連続性の狙い

三層統合の本質は「コンテキスト連続性」にあります。エージェントが「なぜこの変更をしたか」を、コードコメントだけでなく構造化メタデータとしてGitに残し、レビュアーも次のエージェントもそれを参照できる状態を目指します。現状はGitHubへpushした瞬間に文脈が途切れがちですが、Originはこの断絶を埋めることを狙っていると読めます。

Microsoft依存（GitHub・VS Code・Copilot）からの脱却という側面

戦略には競争上の側面もあります。GitHub、VS Code、GitHub CopilotはいずれもMicrosoft傘下で、Cursorはこの三者と競合します。ホスティングをGitHubに依存し続けることは、競合への依存を意味します。Originは、編集からホスティングまでを自社で押さえる垂直統合であり、Microsoft依存からの脱却という意味合いを併せ持ちます。一部の企業にとっては、これがガバナンス上の論点にもなります。

正式提供を待つ間に開発チームが今できる評価・準備の進め方

判断段階として、2026年秋の提供までに何ができるかを具体化します。重要なのは、未確定要素を残したまま過度に前のめりにならないことです。

waitlist登録と秋の正式提供までの情報収集の進め方

現時点でできる最初の一歩はwaitlist登録です。そのうえで、公式の料金公開・対応環境・早期アクセス条件の発表を継続的に追う体制を作ります。秋までに確定する情報が判断材料の大半を占めるため、登録だけ済ませて評価は情報が揃ってから行う、という段取りが現実的です。

自社のエージェント活用度を測る評価軸の設定

Originの恩恵は、自社がどれだけエージェント主導の開発に踏み込んでいるかに比例します。背景エージェントによるPR自動生成や自律的なテスト・修正サイクルをどの程度運用しているかを棚卸しし、「並列度がボトルネックになっているか」を評価軸に設定します。並列度が低い段階では、移行の優先度は高くありません。

並行作業を前提としたGit運用の見直しポイント

エージェント前提への移行を見据えるなら、まず現行のGit運用を並行作業に強い形へ整える価値があります。例えば、複数の作業を同一マシンで並行させるgit worktreeによる並行作業の運用は、Originを待たずに今のリポジトリで試せる改善です。こうした下地づくりは、将来どのホスティングを選んでも無駄になりません。

料金・GA時期など未確定要素を踏まえた意思決定の保留

料金体系と正式提供時期が未公開である以上、Origin前提での契約見直しやツール統廃合の意思決定は保留が妥当です。失敗パターンは、発表直後の話題性だけで移行計画を確定させ、後から料金や制約が判明して手戻りすることです。確定情報が出るまでは、選択肢を狭めない判断を心がけます。

既存GitHub/GitLab運用を止めない併存検証の考え方

Originを評価する際も、既存のGitHubやGitLab運用を止める必要はありません。Git互換であるため、一部のリポジトリや実験的プロジェクトで併存検証を行い、本番運用は現行のまま維持するのが安全です。併存期間を設けることで、性能・運用性・コストを実データで比較してから本格判断に移れます。

エンタープライズがOrigin採用前に確認すべきガバナンス・移行・依存の論点

大企業ほど、機能の魅力だけでなくガバナンスと移行の論点が採否を左右します。ここはコンサルティングの現場で特に問われる観点です。

単一ベンダー依存とロックインのリスク評価

編集・レビュー・ホスティングを一社（Cursor）に集約することは、開発体験の一貫性という利点と引き換えに、単一ベンダー依存というリスクを生みます。価格改定や仕様変更、サービス継続性の影響が一点に集中するため、撤退時の代替手段とデータ可搬性をあらかじめ評価しておく必要があります。

コード資産の所在とデータ主権・コンプライアンス確認

Originは信頼の源泉としてS3を採用するため、コードがどのリージョンに保存され、誰が管理するかはコンプライアンス上の重要な確認事項です。Cursorは法人向けでSOC 2 Type IIに準拠したAWS基盤で運用していると公表していますが、Origin固有の保存リージョンや日本リージョンの可否は未公表で、正式発表で確認すべき項目です。規制業種では、データ主権や保管場所の要件を満たせるかが採否の分岐点になります。

オンプレミス要否とGitHub Enterprise運用との対比

セキュリティポリシー上、外部SaaSを避けてオンプレミス運用を求める企業も少なくありません。例えばGitHub Enterpriseのオンプレミス運用のように自社サーバーで完結させる選択肢があります。Origin自体のオンプレミス提供の可否は未公表ですが、Cursorは法人向けでも現時点ではAWS上のクラウド提供のみでオンプレミス展開には対応していないと公式に明記しており、当面はクラウド前提で要件を整理しておくのが実務的です。

エージェント自動マージにおける監査証跡と承認ゲート設計

AIが自動でマージを行う前提では、「誰が・何を・なぜ承認したか」の監査証跡が不可欠です。エージェントの変更意図がメタデータとして残る設計は監査に有利ですが、最終承認を人間の承認ゲートに集約する運用設計を併せて検討する必要があります。自動化と統制のバランスが、エンタープライズ採用の鍵になります。

移行コストと既存CI/CD・周辺ツール連携の確認

移行判断では、既存のCI/CDパイプラインやIssue管理、セキュリティスキャンなど周辺ツールとの連携が維持できるかを確認します。GitHub ActionsやGitLab CIに深く依存した運用では、Originへの移行コストが大きくなりがちです。Git互換であっても、ホスティング固有の連携機能まで含めた総コストで評価することが重要です。

よくある質問

Cursor Originについて、現時点で多く寄せられる疑問を、発表済みの事実に基づいて整理します。未公表の項目は、その旨を明記しています。

Cursor Originはいつ使えるようになりますか？

正式提供（一般提供）は2026年秋が予定されています。2026年6月の発表時点では一般には提供されておらず、利用にはwaitlist（順番待ちリスト）への登録が必要です。早期アクセスの具体的な条件や枠の配分方法は公開されていないため、公式の続報を確認してください。

Cursor OriginはGitHubの代替として使えますか？

Originはコードのホスティング・レビュー・共同作業を担うGit互換の基盤で、GitHubと同じレイヤーに位置づけられます。設計上はGitHubの代替を志向していますが、現時点では未提供であり、料金や連携機能の詳細も未公開です。今すぐ移行する製品というより、秋の提供開始後に併存検証で評価する対象と考えるのが適切です。

Cursor Originの料金はいくらですか？

料金体系は発表時点で公表されていません。コミット単位の課金などの懸念がコミュニティで語られていますが、これらは公式情報ではなく推測です。導入コストの試算は、公式の料金公開を待ってから行うことをおすすめします。

Cursor OriginとGraphiteはどう関係していますか？

Originの技術は、Cursorが2025年12月19日に買収を発表したコードレビュー企業Graphiteに由来します。Graphiteのstacked pull requestワークフローや複雑なマージ処理の知見が、Originのレビュー・マージ設計の基盤になっています。発表デモはGraphite共同創業者のTomas Reimersが担当しました。

Cursor Originは既存のGitやMCPと連携できますか？

OriginはGit互換であると説明されており、既存のGitワークフローを前提に利用できる構図です。加えて、APIとMCP（Model Context Protocol）による拡張に対応するとされ、外部ツールやエージェントがホスティング・レビュー・マージの各工程に統合できる想定です。具体的な対応範囲は正式提供後の公式ドキュメントで確認してください。

関連記事

• GitHub Copilotの機能と活用：Originと対比されるMicrosoft陣営のAIコーディング支援を理解する一助になります。
• GitLab DuoのAI機能：DevSecOpsライフサイクル全体へAIを組み込むGitLabのアプローチと比較できます。
• Cursor Proの主な機能：Origin提供元であるCursor本体の有料プランと位置づけを把握できます。
• gitコマンド一覧：Origin互換の前提となるGitの基本操作を確認できます。