Cursor Originとは？早期ベータの機能・CLIの使い方とGitHubとの違い【2026年9月】

Cursor Originとは、AIコードエディタのCursorが提供するGitホスティング（git forge）です。2026年6月16日の基調講演で発表され、2026年8月17日には有料プラン向けに早期ベータの提供が始まりました。「a git forge for the agentic era（エージェント時代のためのgit forge）」を掲げ、コードの保存・レビュー・共同作業を担う点でGitHubと同じ層に位置します。本記事では、発表と早期ベータで確定した事実、GitHubミラーの仕組み、Origin CLIでリポジトリを作ってpushするまでの手順、Origin APIの呼び出し例、エージェント前提で設計される理由、GitHub・GitLabとの違い、Graphite買収から続く垂直統合戦略、そして採用前にエンタープライズが確認すべき論点までを、公式ドキュメントに基づいて整理します。

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

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

2026年9月26日時点の提供状況は、Pro・Teams・Enterpriseの有料プラン向け早期ベータです。リポジトリ作成、git push・pull、GitHubからのミラー、コード閲覧と検索、プルリクエストのオープンとマージまでが使えます。一方で正式提供（GA）の日付と単体の料金は公式ページで確認できず、仕様も変わりうる段階にあります。

結論として、Originは「今すぐGitHubから移行する製品」ではありません。GitHubを信頼の源泉に残したままミラーで試せる設計のため、一部のリポジトリで併存検証を始め、GAと料金の公表を待って本格判断に移る進め方が現実的です。検討の軸は、自社がどの程度エージェント主導の開発に踏み込んでいるか、単一ベンダーへの依存をどこまで許容できるか、既存のGitHub/GitLab運用と併存しながら検証できるか、の3点に集約されます。

Cursor Originとは｜Gitホスティングの概要と公式発表で確定した事実

まず押さえるのは、憶測と確定情報の区別です。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」が示す製品コンセプト

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

waitlist受付から2026年8月17日の早期ベータ開始までの経緯

6月の発表時点でOriginは一般提供されておらず、利用にはwaitlist（順番待ちリスト）への登録が必要で、提供時期は「2026年秋（fall 2026）」と告知されていました。その後、公式changelog「Origin Code Hosting」で2026年8月17日に早期ベータの展開開始が告知されています。対象は全有料プランで、Enterprise組織では管理者がオプトアウトした場合を除きます。つまり「秋の提供」を待つまでもなく、有料プランの利用者は8月から実機を触れる状態になりました。ただし段階的なロールアウトのため、同じプランでも有効化のタイミングがずれる場合があります。

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

Originが担うのは、Gitリポジトリのホスティングに加え、その上に乗るレビューと共同作業の層です。これはGitHubやGitLabと同じレイヤーであり、ローカルのGitコマンドそのものを置き換えるものではありません。標準のgit clone・push・pullでアクセスでき、既存のGitワークフローを維持したままホスティング先として使う構図です。Cursorエディタ本体の機能や料金体系はCursorとは何かを整理した解説で扱っており、Originはそのエディタと同じアカウントで使うホスティング側の製品だと位置づけると理解しやすくなります。

料金・GA時期など2026年9月時点でも公式に未確定な情報の切り分け

早期ベータの対象プランは公開されました。しかし正式提供（GA）の日付、Origin単体の料金、対応リージョン、オンプレミス提供の有無は、2026年9月26日時点で公式changelogとドキュメントに記載を確認できません。コミット単位の課金を懸念する声もコミュニティで上がっていますが、これは公式情報ではなく推測にとどまります。導入判断では、公式の料金公開を待つ姿勢が安全です。この段階で何より避けたいのは、未確定情報を確定事実のように扱うことです。

2026年8月17日の早期ベータで使えるようになった機能と対象プラン

ここからは、早期ベータで実際に何ができるのかを公式ドキュメントに沿って確認します。発表時の構想と、いま手元で動く機能とは分けて読む必要があります。

早期ベータの対象はPro・Teams・Enterpriseの有料プラン

Originの公式ドキュメントでは、利用できるプランをPro・Teams・Enterpriseと明記しており、無料プランでは使えません。できることとして挙がっているのは、リポジトリの作成と管理、git clone・push・pullでのアクセス、GitHubリポジトリのミラー、プルリクエストの作成・レビュー・マージ、コードの検索と閲覧、Origin AppsとPublic APIによる連携、自動化とクラウドエージェントの接続、そしてOrigin CLIによるターミナル操作です。発表で示された大規模な並列処理向けの仕組みがどこまで早期ベータに入っているかは、ドキュメントからは読み取れません。

GitHubミラーとOriginホストで入れ替わる信頼の源泉の違い

Originのリポジトリには2種類あります。1つはCodebaseタブから新規作成するOriginホストのリポジトリで、この場合はOriginが信頼の源泉（source of truth）になり、GitHubを経由しません。もう1つはGitHubアカウントを接続して選んだリポジトリを自動でミラーする形で、こちらはGitHubが信頼の源泉のまま残り、Originは結果を写す側に回ります。ミラーしたリポジトリへのgit pushはGitHubへ送られ、GitHubが受け付けた後にOriginが更新される仕組みです。既存資産を動かさずに試せるのは後者で、評価の入口にはこちらを選ぶのが無難だと考えます。

プルリクエストの双方向同期と画面内でコードを読むエージェント統合

プルリクエスト画面では、タイムライン、コミット、チェックの状況、変更ファイルが表示されます。ミラーしたリポジトリではコメントが双方向に同期され、Cursor側で書いたコメントはGitHubに反映され、逆方向も数秒以内に届くと説明されています。加えて、閲覧中のコードについてエージェントに質問でき、エージェントが回答・変更・PR更新・ブランチのpushまで担う構成です。エディタ側でのPRレビューや並列エージェントの扱いはCursor 3.3のPRレビュー・並列エージェントの変更点で整理しており、Originはその流れをホスティング側まで延ばしたものと読めます。

Vercel・Depot・Buildkiteとの初日連携とベータで未提供の機能

changelogが挙げる連携アプリは3つです。Vercelはプルリクエストごとにプレビューデプロイを生成し、DepotとBuildkiteはGitHub Actionsのワークフローを実行する役割を持ちます。Vercel側の仕組みと料金はVercelの仕組みとできることの解説が参考になります。裏返すと、Origin自体にGitHub Actions相当のCIランナーを内蔵するという記述はchangelogにありません。CIを自前で持たないため、既存のActionsワークフローをどこで実行するかを検証前に決めておく必要があります。

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

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

人間前提のGitワークフローが数時間〜数日単位で回ってきた前提

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

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

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

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

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

エージェントを一級市民として扱う設計判断が差分APIに与える意味

「エージェントを一級市民（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による外部ツール連携の余地

Originは、APIに加えてMCP（Model Context Protocol）を通じて拡張可能だと説明されています。外部ツールやエージェントがホスティング・レビュー・マージの各ワークフローへ統合できる構図です。MCPはエージェントと外部リソースを接続する標準的なプロトコルで、たとえばClaude CodeとSerena MCPの統合のように、エージェントへMCP経由で外部機能を与える実例がすでに広がっています。GitHub側でも同じ役割をGitHub MCPサーバーのtoolsetが担っており、比較の土台はそろいつつあります。APIについては早期ベータの段階でOrigin APIのリファレンスが公開され、リポジトリ・プルリクエスト・チェック実行のエンドポイントを外から叩けるようになりました（呼び出し例は後述の手順の章に掲載）。

毎時約29.6万クローンのデモ値を規模の主張として読む際の注意点

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

Origin CLIの導入からリポジトリ作成・git pushまでを試す手順

ここでは早期ベータが有効になったアカウントで、Originを実際に触るまでの手順をまとめます。コマンドは2026年9月26日時点の公式ドキュメントに記載のものです。早期ベータのため名前や引数が変わる可能性があり、実行前に各リンク先で最新の記載を確かめてください。

install.shでOrigin CLIを入れPATH設定とブラウザ認証を済ませる

Origin CLIのインストール手順では、macOS・Linux・Windows（WSL）の共通手順としてインストーラを実行し、バイナリを ~/.local/bin/origin に配置する方式が案内されています。シェルが origin コマンドを見つけられない場合はPATHの設定が必要です。次の例はzshの場合で、bashなら ~/.zshrc を ~/.bashrc に置き換えます。

# Origin CLIのインストール（macOS・Linux・WSL共通）
curl -fsSL https://downloads.cursor.com/origin/install.sh | sh

# originコマンドが見つからない場合はPATHに追加（zshの例）
echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.zshrc
source ~/.zshrc

# 導入の確認とログイン（ブラウザで認証が開く）
origin --version
origin auth login

# CLI自体の更新
origin update

origin auth login はブラウザで認証を行い、Originにアクセスできるアカウントで以後のgit pushとgit pullを通すための手順です。認証に失敗する場合はこのコマンドをもう一度実行し、インストール後に「command not found: origin」と出る場合はPATHの設定漏れを疑います。なお、このOrigin CLIはホスティングを操作する道具で、エディタのエージェントをターミナルから動かすCursor CLIのagentコマンドとは別物です。名前が似ているため、社内手順書では両者を書き分けておくと混乱を防げます。

origin repo createで新規リポジトリを作りローカルからpushする

新規のリポジトリは origin repo create で作れます。スラッシュを含まない名前を渡すと自分のアカウント配下に作成され、削除で指定するのは「組織名/リポジトリ名」の完全形です。作成後はOriginでのgit操作のドキュメントにあるHTTPSのURLをリモートに登録してpushします。

# 自分のアカウント配下にリポジトリを作成
origin repo create my-project

# まだリモートを持たないローカルリポジトリから初回push
cd my-project
git remote add origin https://origin.cursor.com/{owner}/my-project.git
git push -u origin main

# 別の場所へのクローン
git clone https://origin.cursor.com/{owner}/my-project.git

# 不要になったリポジトリの削除は完全形で指定
origin repo delete {owner}/my-project

ここで注意したいのは、リモート名の origin と製品名のOriginが重なる点です。すでにGitHubを origin として登録済みのリポジトリで同じ git remote add origin を実行すると、Gitは「remote origin already exists」で止まります。既存リポジトリでは次の併存設定を使うか、git remote add cursor-origin … のように別名で登録してください。

既存のGitHub運用を残したままOriginへ同時pushする併存設定

GitHubと並行して評価する場合、公式ドキュメントは1つのリモートに複数のpush先を持たせる方法を示しています。Gitの仕様上、push先を明示的に追加するとfetch用のURLはpushに使われなくなるため、GitHub側のURLも併せて追加する必要があります。

# 既存のoriginリモートにpush先を2つ登録する
git remote set-url --add --push origin https://github.com/acme/checkout.git
git remote set-url --add --push origin https://origin.cursor.com/acme/checkout.git

# fetchはGitHub、pushはGitHubとOriginの両方になっていることを確認
git remote -v

この設定なら、開発者の手元の操作は git push のまま変わらず、GitHubを本番の置き場に残して並行検証できます。ただしCIやブランチ保護がGitHub側にしか無い状態で、Origin側だけでマージする運用を始めると、どちらが正か分からなくなります。併存期間中は「マージはGitHubで行い、Originは閲覧とエージェント連携の検証に使う」といった役割分担を先に決めておくのが安全です。

GitHub障害時にorigin push localで作業ブランチを退避する

ミラー型のリポジトリでは、pushは常にGitHubへ向かいます。そのためGitHubが止まっている間はpushできません。この場面のために、ドキュメントでは origin push local が用意されています。チェックアウト中のリモートがミラー型のOriginリポジトリかを確かめたうえで、末尾に /local が付いたURLのリモートを作成または更新します。取得と送信の対象を refs/heads/origin/* に絞り、手元の origin/* 形式のブランチをOrigin側のコピーだけに送る仕組みです。

# 送信内容を確認するだけ（pushはしない）
origin push local --dry-run

# origin/* 形式のローカルブランチをOrigin側のコピーだけに送る
origin push local

# --remote で別のリモート名を指定する場合
origin push local --remote cursor-origin

対象になるのは origin/ で始まる名前のブランチに限られます。通常の作業ブランチをそのまま退避できるわけではないため、障害時の手順として使うなら、ブランチ命名規則を事前に合わせておく必要があります。

Origin APIのBearer認証でプルリクエスト一覧を取得する例

Origin APIのベースURLは https://api.cursor.com/v1/origin で、Bearer認証を使います。トークンは、Ed25519の秘密鍵で署名する短命のApp JWT、プレフィックスが oit_ で有効期間が最大15分のインストールアクセストークン、個人APIキーから作るCursorユーザーアクセストークンの3種類です。次はプルリクエスト一覧を取る例です。

# 環境変数にトークンを入れておく（値はリポジトリに書かない）
export ORIGIN_TOKEN="oit_xxxxxxxx"

# acme/checkout のプルリクエスト一覧を取得
curl -s \
  -H "Authorization: Bearer $ORIGIN_TOKEN" \
  https://api.cursor.com/v1/origin/repos/acme/checkout/pulls

同じリファレンスには、リポジトリの取得と作成、プルリクエストの作成、チェック実行（check-runs）の作成などのエンドポイントが並んでいます。インストールトークンの既定のレート制限は、毎分3,000ポイントという設定です。リファレンス自体に「Early Beta and subject to change」と明記され、一部はPreview扱いのため、連携を作る場合はOpenAPI仕様を更新のたびに確認する前提で設計します。

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発表）でエージェント統合を進めており、競争は始まったばかりです。

GitHub・GitLab・Originのホスティング層を整理する比較表

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

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

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

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

当社の判断としては、採用を検討してよいのは「エージェントが起票するPRが週に数十件を超え、レビュー待ちが開発速度を律速している」「GitHubを信頼の源泉に残したミラー運用で検証できる」の2条件がそろう場合です。反対に、CIをGitHub Actionsに深く組み込み、ブランチ保護や監査ログの要件をGitHub側で満たしているチームは、GAと料金が出るまで見送る場面だと考えます。

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

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

2025年12月のGraphite買収からOrigin早期ベータへ続く統合の流れ

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

編集・レビュー・ホスティングをCursor1社で揃える三層構造の中身

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

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

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

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

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

Microsoft依存（GitHub・VS Code・Copilot）から離れる側面

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

早期ベータから正式提供までの間に開発チームが進める評価と準備の手順

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

早期ベータの試用範囲とGAまでの公式changelogの追い方を決める

有料プランを契約していれば、最初の一歩はwaitlist登録ではなく早期ベータの試用に変わりました。まずGitHubミラーで検証用のリポジトリを1つ選び、閲覧・PR同期・エージェント連携の使い勝手を確かめます。あわせて、公式changelogとドキュメントの更新を担当者が定期的に確認する体制を作ります。GAの日付と料金が判断材料の大半を占めるため、試用は小さく始め、本格評価は情報が揃ってから行う段取りが現実的です。

自社のエージェント運用度と並列度のボトルネックを測る評価軸の設定

Originの恩恵は、自社がどれだけエージェント主導の開発に踏み込んでいるかに比例します。背景エージェントによるPR自動生成や自律的なテスト・修正サイクルをどの程度運用しているかを棚卸しし、「並列度がボトルネックになっているか」を評価軸に設定します。測る指標は、週あたりのエージェント起票PR数、PR作成からマージまでの中央値、コンフリクトで差し戻された件数の3つが扱いやすいでしょう。並列度が低い段階では、移行の優先度は高くありません。

並行作業を前提としたGit運用の見直しとgit worktreeの導入

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

単体料金・GA時期など未確定要素を踏まえた契約・ツール統廃合の判断保留

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

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

Originを評価する際も、既存のGitHubやGitLab運用を止める必要はありません。GitHubミラーを使えばGitHubを信頼の源泉に残したまま検証でき、Originホストのリポジトリを試す場合も前述の同時push設定で本番運用を現行のまま維持できます。併存期間を設ければ、性能・運用性・コストを実データで比較したうえで本格判断に移ることが可能です。CI/CDの実行場所やブランチ保護の置き場所を含めた併存設計に迷う場合は、一創のDevOps・CI/CD導入支援でGit運用とパイプラインの整理からご相談いただけます。

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

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

編集からホスティングまでの単一ベンダー依存とロックインの評価

編集・レビュー・ホスティングを一社（Cursor）に集約することは、開発体験の一貫性という利点と引き換えに、単一ベンダー依存というリスクを生みます。価格改定や仕様変更、サービス継続性の影響が一点に集中するため、撤退時の代替手段とデータ可搬性について、あらかじめ評価が必要です。Gitの履歴そのものは標準のcloneで取り出せますが、PRのコメントやレビュー履歴まで持ち出せるかは、Origin APIの範囲で確認することになります。

コード資産の保存リージョンとデータ主権・コンプライアンスの確認

Originは信頼の源泉としてS3を採用するため、コードがどのリージョンに保存され、誰が管理するかはコンプライアンス上の確認事項になります。Cursorは法人向けでSOC 2 Type IIに準拠したAWS基盤で運用していると公表していますが、Origin固有の保存リージョンや日本リージョンの可否は未公表です。規制業種では、データ主権や保管場所の要件を満たせるかが採否の分岐点になります。Enterpriseでは管理者が早期ベータをオプトアウトできるため、要件の確認が済むまでは組織として無効にしておく選択も取れます。

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

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

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

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

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

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

よくある質問

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

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

2026年8月17日から、Pro・Teams・Enterpriseの有料プラン向けに早期ベータとして段階的に提供されています。無料プランでは使えず、Enterprise組織では管理者がオプトアウトしている場合も使えません。発表時に「2026年秋」とされていた正式提供（GA）の具体的な日付は、2026年9月26日時点で公式に確認できないため、公式changelogの続報を確認してください。

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

Originはコードのホスティング・レビュー・共同作業を担うGit互換の基盤で、GitHubと同じレイヤーに位置づけられます。設計上はGitHubの代替を志向していますが、早期ベータではGitHubを信頼の源泉に残すミラー運用が用意されており、置き換えよりも併用から始める作りです。CIはDepotやBuildkiteの連携で動かす形のため、GAと料金が出た後に併存検証の結果で評価するのが適切でしょう。

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

早期ベータはCursorの有料プラン（Pro・Teams・Enterprise）に含まれる形で提供されており、Origin単体の料金は2026年9月26日時点で公表されていません。コミット単位の課金などの懸念がコミュニティで語られていますが、これらは公式情報ではなく推測です。導入コストの試算は、公式の料金公開を待ってから行うことをおすすめします。

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

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

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

OriginはGit互換で、https://origin.cursor.com/{owner}/{repo}.git 形式のURLに対して標準のgit clone・push・pullが使えます。事前にOrigin CLIで origin auth login を済ませておく必要があります。外部連携としては、Bearer認証のOrigin APIが早期ベータで公開済みで、発表時にはMCPによる拡張にも対応すると説明されました。MCPの具体的な対応範囲は、GA後の公式ドキュメントで確認してください。

関連記事

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