--- title: "Cursor Originとは？早期ベータでできること・CLIの使い方とGitHubとの違い【2026年9月】" url: "https://www.issoh.co.jp/tech/details/12630/" published: 2026-06-18 updated: 2026-09-30 categories: ["開発"] publisher: "株式会社一創" --- # Cursor Originとは？早期ベータでできること・CLIの使い方とGitHubとの違い【2026年9月】 Cursor Originは、AIコードエディタのCursorが提供するGitホスティング（git forge）です。2026年6月16日に紹介ページが「A git forge for the agentic era」の見出しで公開され、2026年8月17日に有料プラン向けの早期ベータが始まりました。リポジトリの作成、git push・pull、GitHubからのミラー、プルリクエストのレビューとマージまでがCursorの中で完結します。この記事では、2026年9月30日時点の公式ドキュメントをもとに、使える機能と対象プラン、GitHubミラーの仕組み、Origin CLIの手順、APIの認証、ストレージ設計、採用前に確認すべき点を整理します。 ## まとめ：Cursor Originの現状と判断の要点 - **提供状況**：早期ベータ。Start・Pro・Pro+・Ultra・Teams・Enterpriseの有料プランが対象で、無料プランでは使えません。展開は段階的です。 - **料金**：料金ページにOriginの項目はなく、単体の価格は公表されていません。 - **GitHubとの併用**：GitHubのリポジトリをミラーすれば、正本（source of truth）はGitHubに残ります。pushもGitHubへ流れるため、既存の運用を止めずに試せます。 - **まだ無いもの**：公式changelogは「Agent-native features ship soon」としており、エージェント専用の機能はこれからです。Issuesは同期されず、CIの連携先はDepot・Buildkiteの2つで、Originホストのリポジトリでしか使えません（Vercelはデプロイとプレビュー環境の連携です）。 - **判断**：本番の正本を移す段階ではありません。1つのリポジトリをミラーして閲覧・検索・クラウドエージェントの使い勝手を確かめ、規約とSLAの公表を待つのが妥当です。 ## Cursor Originの位置づけと早期ベータまでの経緯 Originは、GitHubやGitLabと同じ「コードを置き、レビューし、マージする」層の製品です。エディタやエージェントの機能ではなく、ホスティングそのものをCursorが持つ点が新しさです。公式ドキュメントは「Cursor’s git forge for storing and sharing code」と説明しています。 | 日付 | 出来事 | 出典 | | ----------- | ---------------------- | ----------------------- | | 2025年12月19日 | CursorがGraphiteの買収で合意 | Cursor公式ブログ | | 2026年6月16日 | 紹介ページを公開（待機リスト受付） | Wayback・Hacker News | | 2026年6月16日 | 初のカンファレンスCompileを開催 | cursor.com/compile | | 2026年8月14日 | SpaceXによるCursorの買収が完了 | Cursor公式ブログ | | 2026年8月17日 | 有料プラン向けに早期ベータを開始 | 公式changelog | | 2026年8月18日 | ストレージ層Continuityの設計を公開 | 公式ブログ「Git at any scale」 | 2026年6月16日時点の紹介ページは見出しと待機リスト（Join the waitlist）の受付だけで、機能の説明はありませんでした。8月のchangelogも「Agent-native features ship soon」としており、エージェント向けの機能はこれからです。導入を検討するときは、発表記事や報道ではなく [公式ドキュメント](https://cursor.com/docs/origin) の記述を基準にしてください。Cursor本体の機能や料金は [Cursorとは？AIコードエディタの機能・料金・使い方](/column/details/3020/) で扱っています。 ## 早期ベータで使える機能と対象プラン ### 使える機能とリポジトリの管理画面 ドキュメントに列挙されている早期ベータの機能は次のとおりです。リポジトリの一覧と操作は `cursor.com/codebase` にまとまっています。 - リポジトリの作成（Cursorのエージェントからも作成可能） - 標準のgitによるclone・push・pull - GitHubリポジトリのミラー - プルリクエストの作成・レビュー・マージ（Activity・Commits・Checks・Files Changedの4タブ） - コードの閲覧と検索 - リポジトリ設定とcodebase設定、Origin Appsの導入、Public APIによる独自連携 - Cursor Automationsとクラウドエージェントの接続 ミラーしたリポジトリのプルリクエストは双方向に同期します。Cursor側で付けたコメントはGitHubに投稿され、GitHub側の返信は数秒でCursorに表示されるとchangelogは説明しています。 ### 対象プランと有効化の条件 対象はStart・Pro・Pro+・Ultra・Teams・Enterpriseです（API仕様のGit HTTPS認証の節は、個人でpushできる条件にPro Studentも挙げています）。ただしミラーの手順ページは前提を「Pro、Teams、Enterprise」と書いたままで、これを引いて対象を3プランとする解説もあります。ページ間で表記が揃っていない状態です。個人のPro+・Ultraでミラーを使う予定なら、画面で確かめてから計画に入れてください。Cursorの個人プランの違いは [Cursor Proとは｜料金プラン・無料版との違い](/tech/details/7816/) を参照してください。 - 最初にcodebase名（URLの `{owner}` 部分）を確保する必要があり（概要ページは「チームメンバーなら誰でも」、codebase設定ページは「チーム管理者」と表記が割れています）、**ベータ中は変更できません**。 - legacy privacy modeのままのチームは有効化できず、先にPrivacy Modeへ切り替えます。 - 管理者はダッシュボードからいつでもチームのOriginを無効化できます。Enterprise組織は、管理者がオプトアウトすれば展開の対象外です。 ### ベータで未提供のものと連携先の制約 リポジトリ内でエージェントに質問・変更・PR更新・pushをさせる機能は入っていますが、changelogは「Agent-native features ship soon」と書いており、エージェント専用の機能はこれからです。連携先はVercel・Depot・Buildkiteの3つです。DepotとBuildkiteはどちらも既存のGitHub Actionsのworkflowを実行できますが、使えるのはOriginでホストしたリポジトリだけです。ミラーしたリポジトリのCIはGitHub側に残ります。 ## GitHubミラーとOriginホストで変わる正本と書き込み先 Originのリポジトリは2種類あり、どちらを選ぶかで「pushがどこに着地するか」が変わります。 | 項目 | Originホスト | GitHubミラー | | --------------- | ----------- | ------------------------------ | | 正本 | Origin | GitHub | | git pushの着地先 | Origin | GitHub（受理後にOriginが追従） | | プルリクエスト | Originのみに存在 | GitHubのPRを双方向同期 | | 同期されないもの | 該当なし | Issues、Actionsのworkflowとsecret | | Depot・Buildkite | 使える | 使えない | | 有効化に必要な権限 | 管理者か作成権限の付与 | GitHub側の管理者権限 | ミラーを有効にするには、Cursor GitHub appを対象のorgかアカウントに接続し、元リポジトリでGitHubの管理者権限を持っている必要があります。CLIでは `origin repo create-mirrored` でもミラーを作れ、GitHub Enterprise Serverからのミラーは `--github-enterprise-id` でアプリのUUIDを指定します。 ### GitHub障害時に使うorigin push local ミラーしたリポジトリでは、GitHubが落ちていても `origin/` で始まるブランチだけはOrigin側に書き込めます。通常の `git push origin` はGitHubへ向かうため、障害時は使えません。実行するチェックアウトの `origin` リモートは、GitHubではなく `https://origin.cursor.com/{owner}/{repo}.git` を指している必要があります。 ``` # Origin側だけに置く作業ブランチを作る git branch origin/my-state HEAD # 送信内容だけ確認する origin push local --dry-run # origin/* のブランチを /local エンドポイントへ送る origin push local ``` 初回実行で `origin-local` という名前のリモートが作られ、refspecは `refs/heads/origin/*` に限定されます。GitHubにある `origin/...` という名前のブランチは同期で取り込まれないため、Origin側の作業を上書きしません。gitでは `origin/main` がリモート追跡ブランチも指すため、ブランチは `git branch origin/my-state HEAD` のように名前を明示して作ります。制約も3つあります。 - `/local` はミラーしたリポジトリにだけ存在し、リポジトリ単位で有効化されます。 - Git LFSのbatchはフェイルオーバーしません。 - 初回同期が終わっていないリポジトリは、読み取りにもGitHubが必要です。 ミラーのままでは、App経由のAPIは書き込みだけでなくプルリクエストやレビューの読み取りも使えません。Originホストでも安定した外向きミラーでもない状態では、使えるスコープが読み取りの2つだけになり、それ以外は403で拒否されます。 ### Detach from GitHubによる正本の切り替え リポジトリ設定の Danger Zone にある「Detach from GitHub」を実行すると同期が止まり、OriginのコピーがOriginホストのリポジトリに変わります。以後のpushはGitHubへ流れません。GitHub側のリポジトリには影響しません。Migration APIのドキュメントも切り離しを「Permanently disconnects」とし、「not reversible through this API」と書いています。検証段階では実行しないでください。 ## Origin CLIの導入からプルリクエストのマージまでの手順 Origin CLI（`origin`）は、Cursorのエージェントを端末で動かす `agent` コマンドとは別のツールです。`agent` 側の使い方は [Cursor CLIの使い方｜agentコマンドの導入・非対話実行とCI連携の手順](/tech/details/17660/) で扱っています。 ### インストールとブラウザ認証 macOS・Linux・Windows（WSL）で同じコマンドを使います。バイナリは `~/.local/bin/origin` に置かれます。 ``` curl -fsSL https://downloads.cursor.com/origin/install.sh | sh # command not found: origin と出たらPATHに追加（zshの例） echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.zshrc source ~/.zshrc origin --version origin auth login # ブラウザで認証し、gitの認証ヘルパーも設定される ``` `origin auth login` がgitの認証ヘルパーを設定するため、以降の `git push` と `git pull` は追加設定なしで通ります。CIなど非対話の環境では、環境変数 `CURSOR_API_KEY` があればそのキーでログインします。 ### リポジトリ作成と初回push ``` # スラッシュなしの名前は自分のアカウントの名前空間に作られる origin repo create my-project cd my-project # 既存のローカルプロジェクト（コミット済み・originリモート未設定）へ移動 git remote add origin https://origin.cursor.com/{owner}/my-project.git git push -u origin main # 削除は必ず org/name の完全形で指定する origin repo delete {owner}/my-project ``` 個人アカウントで作ったリポジトリは常にPrivateです。チームのcodebaseで作る場合だけ、Internal（codebaseへのアクセス権を持つチームメンバー全員が閲覧可）かPrivateかを選べます。 ### GitHubと並行してpushする評価用設定 ミラーを使わずに試すなら、1つのリモートにpush先を2つ登録する方法を公式ドキュメントが案内しています。fetchはGitHubのまま、pushだけ両方に送られます。 ``` 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 git remote -v ``` この方法でOriginに届くのはpushしたブランチとその履歴だけで、pushしていないブランチやタグ、GitHubのプルリクエストは移りません。全履歴を持ち込みたい場合はミラーを使います。git側のリモート操作は [Gitコマンド一覧｜用途別早見表とよく使う基本コマンドの使い方](/tech/details/2787/) にまとめています。 ### origin prによるプルリクエストの作成からマージまで プルリクエストの操作は `origin pr` にまとまっています。`origin pr create` の既定の状態は `draft` なので、レビューに出すときは `ready` で切り替えます。 ``` git switch -c fix-ci git commit -am "Fix CI config" # 未pushのブランチをpushしてからPRを作成（既定はdraft） origin pr create --push -t "Fix CI" origin pr ready # draftをレビュー待ちに変える origin pr checks # CIの状態を確認 origin pr review --approve # 承認（レビュアー側） origin pr merge ``` `origin pr list --json number,title,status` でJSONを出力でき、`-q` でjq式による絞り込みも可能です。並行作業のためにブランチごとに作業ディレクトリを分けるなら、[Git Worktree（ワークツリー）とは｜使い方・削除とsubmodule併用の注意点](/tech/details/7018/) の手順がそのまま使えます。 ## Origin APIの認証とレート制限 Origin APIのベースURLは `https://api.cursor.com/v1/origin` で、Early Betaとして仕様変更がありうると明記されています。つまずきやすいのは認証です。**CursorのAPIキーはOriginのBearerトークンではなく**、そのまま `Authorization` ヘッダーに入れると通りません。 ### App JWTからinstallation access tokenを得る流れ 外部ツールからAPIを呼ぶには、codebase設定でInternal appを作り、次の順でトークンを得ます。 1. Ed25519の鍵ペアを手元で作り、公開鍵だけを登録する（1つのappにつき有効な鍵は最大10本）。 2. 秘密鍵でApp JWTに署名する。`alg` はEdDSA、`aud` は `origin-apps`、有効期間は約5分が推奨です。 3. ワークスペース管理者がappをインストールしてスコープと対象リポジトリを承認し、インストールレシート（JWT）の `sub` からinstallation IDを保存する。 4. App JWTで `POST /app/installations/{installationId}/access_tokens` を呼び、`oit_` で始まるinstallation access tokenを受け取る。 ``` # 1. 署名鍵を作る（公開鍵のPEMだけを設定画面に貼る） # macOS標準の /usr/bin/openssl（LibreSSL）はED25519非対応のことがあるためOpenSSL 3系を使う openssl genpkey -algorithm ED25519 -out origin-app-private.pem openssl pkey -in origin-app-private.pem -pubout -out origin-app-public.pem # 3. で得たトークンでopenのプルリクエストを最大100件取得 curl -s \ -H "Authorization: Bearer $ORIGIN_TOKEN" \ "https://api.cursor.com/v1/origin/repos/acme/checkout/pulls?state=open&pageSize=100" ``` installation access tokenの寿命は作成から最長15分で、署名したApp JWTより長くはなりません。5分のJWTから作れば最長5分です。ジョブで15分使いたいときは、JWTの `exp` を後ろにずらして署名します。ドキュメントは、GitHub Appのトークンと同じ間隔で使い回すと期限切れで失敗すると注意しています。レスポンスの `expiresAt` を読み、切れたら作り直す実装にしてください。個人の権限で一時的に叩くだけなら、`origin api` コマンドが認証を肩代わりします。 ### ポイント制のレート制限 レート制限は、主体ごとの1分間のポイント予算で管理されます。 | 主体 | 既定の予算 | | ------------------------- | ----------- | | installation access token | 3,000ポイント/分 | | App JWT | 6,000ポイント/分 | | Cursorユーザー・サービスアカウント | 600ポイント/分 | 読み取りの多くは1ポイント、通常の書き込みは5ポイント、リポジトリ作成やプルリクエストのマージは10ポイントです。超えるとHTTP 429と `Retry-After: 60` が返ります。1つのトークンを複数のジョブで共有するなら、ジッター付きのバックオフを入れておきます。残量は、ポイントを消費しない Get Rate Limit で確認できます。Git over HTTPSはREST APIとは別の予算で計測されます。 ## Continuityの設計：S3上のWALを正本にするGitストレージ Originの下で動くストレージ層はContinuityと呼ばれます。2026年8月18日の公式ブログ「[Git at any scale](https://cursor.com/blog/git-at-any-scale)」で、Vicent Martí氏が設計を公開しました。国内の解説記事ではほとんど扱われていませんが、「障害時にコードは失われないか」「CIが大量にcloneしても耐えるか」という採用判断の材料はここにあります。 ### GitHubのSpokesとの違いと正本の置き場所 GitHubが2013年ごろに開発したSpokesは、リポジトリの完全なコピーを複数台のNVMeディスクに置き、多数決で整合性を保ちます。コピー自体が正本なので、3つのうち2つが壊れるとpushを受け付けられません。Continuityは正本をS3互換のオブジェクトストレージ上の先行書き込みログ（WAL）に置き、各サーバーのNVMe上のリポジトリは「温めたキャッシュ」として扱います。 - pushは各pushを別オブジェクトとしてS3に保存し、永続化が終わるまで完了を返しません。全pushは線形化されます。 - どのサーバーがどのリポジトリを持つかの対応表は持たず、rendezvous hashingで配置先を決めます。ディスクに無ければWALから復元します。 - WALの更新はS3のcompare-and-swapで同期するため、どのサーバーがpushを受けても整合性は崩れません。 - 読み取りのたびにS3へETag付きの条件付きGETを送り、最新なら304が返ります（平均10ミリ秒未満）。レプリカ間のUDPのゴシップが欠けても、古いデータは返りません。 ### 公式が示したスループットの実測値 ブログは次の数値を挙げています。push数はCursor自身のモノレポ（everysphere）のグラフに対応する値で、レプリカ数は合成負荷試験の条件です。 | 条件 | 数値 | | ------------------------- | ----------------- | | S3 Standard上のpush | 最大120 pushes/s | | S3 Express One Zone上のpush | 300 pushes/s超 | | 合成負荷試験のレプリカ数 | 最大100（読み取りは線形に伸長） | push性能はS3への書き込みの遅延で決まり、Express One Zoneでは圧縮処理（compaction）が律速になるとしています。これはCursor社内の条件での値で、顧客向けの保証値ではありません。SLAの数字はまだ公表されていないため、可用性の要件がある組織は、この数値を契約上の根拠には使えません。 ## Origin・GitHub・GitLabの違い 比べるべきは機能の数ではなく、正本をどこに置き、周辺ツールをどこまで同じ場所で完結させるかです。 | 観点 | Cursor Origin | GitHub | GitLab | | ------- | ----------------- | ----------------- | ------------ | | 提供段階 | 早期ベータ | 一般提供 | 一般提供 | | 単体の料金 | 未公表 | 公表済み | 公表済み | | Issue管理 | ドキュメントに記載なし | Issues | Issues | | CI | Depot・Buildkite連携 | GitHub Actions | GitLab CI/CD | | 自社運用版 | ドキュメントに記載なし | Enterprise Server | Self-Managed | | AIとの統合 | Cursorのエージェント | GitHub Copilot | GitLab Duo | OriginはIssueとCIを自前で持たず、コード・プルリクエスト・エージェントを同じ場所に集める方向の製品です。Issue管理やCI/CDまで1つの製品にまとめたい組織には、現時点ではGitHubかGitLabが合います。オンプレミス運用が条件なら、選択肢は [GitHub Enterprise Serverとは？オンプレGitHubの機能・価格](/column/details/2959/) かGitLabのSelf-Managedです。GitHubとGitLabの比較は [GitHubとGitLabの違い｜料金・Free枠・CI/CD・セルフホストを比較](/tech/details/4219/) で、GitLab側のAIは [GitLab Duo Agent Platformとは？GA後の機能とGitLab Creditsの実費](/tech/details/10660/) で解説しています。 ## 採用前に確認すべきガバナンスの論点と向かない組織 ### 規約・データの扱いが製品として未整備な点 2026年9月30日時点で、Cursorのセキュリティページ、利用規約、Data Useのページには、いずれもOriginへの言及がありません。ドキュメントで確認できるのは「OriginはリポジトリのPrivacy Modeを名前空間の所有者（チームか個人）に合わせる」という一文までです。コードの保存場所（リージョン）や保持期間も書かれていません。一方、API仕様には名前空間単位の受信IP許可リストとSSH証明書認証局の設定項目があります。取引先との契約でコードの保管場所を指定されている場合は、ミラーでも閲覧用のコピーがOriginに置かれる点を法務と確認してから進めます。 ### 編集からホスティングまでを1社に寄せる依存 Cursorは2026年8月14日にSpaceXの傘下に入りました。エディタ、エージェント、コードレビュー、ホスティングを同じ会社に集めると、その1社の方針変更や障害が開発のすべてに波及します。Microsoft系（GitHub・VS Code・Copilot）から離れる手段としてOriginを選んでも、依存先が別の1社に移るだけです。分散を優先するなら、正本はGitHubかGitLabに残し、Originはミラーとして使う形にとどめます。 ### 向かない組織と、試す場合の最小構成 次に当てはまる組織は、GAと規約の公表を待つほうが安全です。 - オンプレミスや特定リージョンでのコード保管が契約上の条件になっている - Issues・GitHub Actions・Projectsを中心に開発プロセスを組んでいる - ホスティングにSLAの数値が必要（Originは未公表） 試す場合は、影響の小さいリポジトリを1つミラーし、閲覧・検索・クラウドエージェントがどこまで役立つかを見ます。GitHubのプルリクエストにAIのレビューコメントが欲しいだけなら、Originを使わずBugbotで足りると公式ドキュメント自身が書いています。Cursorのバージョンと更新内容は [Cursorの最新バージョン](/tech/details/9603/) で、Split PRsなどプルリクエスト周りの機能は [Cursor 3.3の変更点](/tech/details/12054/) で追えます。 ## よくある質問 ### Cursor Originはいつから使えますか？無料プランでも使えますか？ 2026年8月17日に早期ベータの段階展開が始まりました。対象はStart・Pro・Pro+・Ultra・Teams・Enterpriseの有料プランで、無料プランでは使えません。対象プランでもすぐに表示されない場合があります。 ### Cursor Originの料金はいくらですか？ 2026年9月30日時点で、単体の料金は公表されていません。Cursorの料金ページにもOriginの項目はなく、早期ベータは対象の有料プランの中で提供されています。 ### Cursor OriginはGitHubの代わりになりますか？ コードの保管、clone・push、プルリクエストのレビューとマージはできますが、Issueは同期されず、CIの連携先もDepot・Buildkite（Originホストのリポジトリのみ。ミラーではCIはGitHubに残ります）に限られます。現段階では、GitHubを正本に残したままミラーとして併用する形が現実的です。 ### Origin CLIとCursor CLIは同じものですか？ 別のツールです。Origin CLIのコマンドは `origin` で、リポジトリの作成、認証、`origin pr` によるプルリクエスト操作を担います。Cursorのエージェントを端末で動かすのは `agent` コマンドです。 ### Cursor OriginとGraphiteはどう関係していますか？ Cursorは2025年12月19日にGraphiteの買収合意を発表し、Graphiteは同じチームと製品で独立運営を続けるとしています。Originのドキュメントと早期ベータのchangelogには、Graphiteとの関係を説明する記述はありません。なお、APIのList Pull Requestsには `stackId` による絞り込みがあり、積み重ね型のプルリクエスト（スタック）を扱う項目はすでにあります。 ## 関連記事 - [Cursorとは？AIコードエディタの機能・料金・使い方を開発会社が解説](/column/details/3020/) - [Cursorの最新バージョンは3.18系｜バージョン確認とアップデート・更新頻度の実際](/tech/details/9603/) - [Cursor CLIの使い方｜agentコマンドの導入・非対話実行とCI連携の手順](/tech/details/17660/) - [GitHubとGitLabの違い｜料金・Free枠・CI/CD・セルフホストを比較【2026年版】](/tech/details/4219/) - [Git Worktree（ワークツリー）とは｜使い方・削除(remove/prune)とsubmodule併用の注意点](/tech/details/7018/) --- 出典: [Cursor Originとは？早期ベータでできること・CLIの使い方とGitHubとの違い【2026年9月】]()（株式会社一創）