Cursor Origin チュートリアル：CLI セットアップ、GitHub ミラーリング、プルリクエスト

Cursor Origin とは？

Cursor Origin は Git フォージです。リポジトリをホストし、GitHub プロジェクトをミラーし、プルリクエストやコード閲覧をサポートします。Origin のリポジトリは Cursor のクラウドエージェントや自動化とも連携します。

Cursor Origin と GitHub の違いは？

Origin は GitHub の全機能をカバーしていません。公開リポジトリはドキュメント化されておらず、ミラーでは GitHub Issues、GitHub Actions のワークフロー、および Actions のシークレットは対象外です。GitHub は公開リポジトリ、Issues、Actions、サードパーティアプリに対応するより広いプラットフォームのままであり、現時点では Origin はより狭いサービスです。

主な違いは、おなじみの Git ワークフローの下層にあります。Cursor はエージェントが生むブランチとコミットのボリュームに対応する独自のストレージ層を構築しました。Cursor はこの焦点を「エージェントスケール」と呼んでおり、多数のエージェントが同一リポジトリに対してブランチを切り、コミットし、プルリクエストを開くようなワークロードを指します。

Cursor はなぜ独自の Git ホストを作ったのか？

このストレージ設計が、既存ホストへの別インターフェース追加ではなく、新しい Git ホストを作った理由を説明します。

Cursor の Continuity に関するエンジニアリング記事は、既存の Git ホストを「複数サーバーにリポジトリを置き、過半数が合意したらプッシュをコミットする」仕組みとして説明しています。Cursor によれば、このモデルは短命なリポジトリが大量に存在する場合や、単一リポジトリへの頻繁なプッシュがある場合にコストが増大します。

Cursor Origin の Continuity ストレージはどう機能する？

Continuity（または「Cnt」）は Origin の背後にあるストレージシステムです。S3 互換のオブジェクトストレージに書き込み前ログをソース・オブ・トゥルースとして保持します。ローカルディスク上の Git リポジトリはウォームキャッシュであり、ログから再構築できます。

Continuity は Git の書き込みをオブジェクトとして保存します。画像：著者作成。

オブジェクトログが真の記録であるため、Cursor は混雑するリポジトリにリードレプリカを追加し、需要が落ちれば削除できます。Cursor のテストでは、レプリカを最大 100 台まで追加するにつれてリードスループットが向上しました。標準的な S3 上で最大毎秒 120 プッシュを処理したとのことですが、これらの数値は第三者のベンチマークで検証されていません。

ユーザーにとっての主な効果はより単純です。混雑するリポジトリは読み取り能力を増やせ、短命なリポジトリは各サーバーに恒久的なローカルコピーを持つ必要がありません。

誰が Cursor Origin にアクセスできる？

Origin は Pro、Teams、Enterprise プランで利用可能ですが、無料プランでは利用できません。アクセスは段階的に展開されるため、対象プランでも Codebase タブがすぐに表示されるとは限りません。Pro では個人の名前空間を所有し、自分のコードベース名を取得します。

Enterprise 管理者は組織向けに無効化できます。Cursor の概要では、最初のコードベース名はチームメンバーなら誰でも取得できるとされる一方、Codebase Settings ページではチーム管理者が取得する必要があると記載されています。セットアップ前にチーム内の権限を確認してください。

Cursor Origin CLI とは？

Origin には、認証、リポジトリ、プルリクエスト、アカウント設定のための独自のコマンドラインツールが同梱されています。

Cursor Origin CLI と Cursor Agent CLI の違い

Origin の CLI は Cursor の Agent CLI とは別バイナリで、origin として実行され、Agent CLI は agent として実行されます。

私は名前を混同しやすいと感じました。というのも、origin は Git のリモートの慣用名でもあるからです。本記事では「push to origin」は Git のリモートを意味し、「run origin」は CLI の実行を意味します。

Origin CLI はどのプラットフォームで使える？

Cursor は macOS、Linux、そして WSL 経由の Windows をドキュメント化しています。私の検証時点では、Windows はネイティブインストーラがなかったため WSL が前提でした。

Windows で進める場合は、CLI をインストールする前に Ubuntu ターミナルを開いてください。PowerShell でシェルインストーラを実行するのは同じセットアップにはなりません。

Cursor Origin CLI のコマンド

Cursor Origin CLI には現時点で 9 つのコマンドグループがあります。

多くのリポジトリ関連コマンドは、origin という名前の Git リモートから対象を読み取ります。 -R owner/repo オプションで対象を直接指定できます。これは複数のリポジトリに対して実行するスクリプトで有用です。 ruleset コマンドは既存のプッシュ／マージルールを表示するだけで、変更は行いません。

Cursor Origin CLI のインストールとログイン方法

Cursor はパッケージマネージャではなくシェルスクリプトで CLI を提供しています。コマンドは Cursor の インストールページにあります。

Cursor Origin CLI のインストール方法

インストールは次の 1 行です。

curl -fsSL https://downloads.cursor.com/origin/install.sh | sh

インストーラは origin を ~/.local/bin/origin に配置しました。チームでインストールスクリプトを実行前にレビューする運用なら、 sh へ直接パイプせず、まずスクリプトをダウンロードしてください。

Origin CLI の「command not found」エラーの対処

インストール後にシェルが origin を見つけられない場合は、ディレクトリを PATH に追加してください。

echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.zshrc
source ~/.zshrc

~/.zshrc を bash なら ~/.bashrc に置き換えてください。マシンごとに 1 回の対応で済みます。

インストールとログインの確認

origin --version と origin --help を実行してインストールを確認し、その後 origin auth login で Cursor のブラウザサインインフローを開きます。

WSL での検証出力は次のようになりました。

Origin CLI のバージョンとヘルプ出力。画像：著者作成。

ヘッドレス環境では、CLI は代わりに URL を出力します。ログイン時には Git のクレデンシャルヘルパーも設定されるため、Origin のリモートは別の Git トークンなしで動作します。後で origin auth status を実行してセッションを確認してください。

ブラウザなしで Cursor API キーを使う

CI やスクリプトでは、origin auth login --api-key <key> を実行するか、CURSOR_API_KEY を設定してから origin auth login を実行します。キーはコミットされたファイルに含めないでください。CURSOR_AUTH_TOKEN は別物で、ベアラートークンを想定しています。

Cursor Origin リポジトリの作成、クローン、プッシュ方法

サインイン後は、Web か CLI のどちらからでもリポジトリを作成できます。プッシュは標準の Git コマンドを使います。

origin repo create でリポジトリを作成する

cursor.com/codebase から New を選択し、名前を入力して Internal または Private の可視性を選びます。

CLI では origin repo create my-project がアカウントの名前空間を使います。チームの名前空間にするには origin repo create acme/my-project のようにオーナーを含めます。任意の --default-branch フラグで、サーバーのデフォルト（main）を変更できます。

origin repo clone acme/my-project は、CLI に保存されたログイン情報を使って HTTPS 経由でリポジトリをクローンします。

最初のコミットを Origin にプッシュする

最初のプッシュ後、リポジトリは Codebase に表示されます。

リポジトリをプッシュし、Codebase に表示。動画：著者作成。

新規の空リポジトリなら、クローンしてファイルを追加し、プッシュします。

git clone https://origin.cursor.com/{owner}/{repo}.git
cd {repo}
echo "# {repo}" > README.md
git add .
git commit -m "Initial commit"
git push -u origin main

WSL の /mnt 配下で .git/config.lock のパーミッションエラーが出る場合は、代わりに ~ 配下にクローンしてください。私の検証ではそれで解消しました。

プッシュ後、Codebase を開いてコミットが表示されることを確認します。Code タブにはファイルツリーとコミット履歴が表示されます。 T を押すと Go to file が開き、検索フィールドでコード検索もできます。

既存の Git リポジトリを Origin にプッシュする

すでに履歴のあるプロジェクトでは、まず git remote -v を実行してください。以下のコマンドは、すでに origin という名前のリモートがない場合にのみ適用されます。

git remote add origin https://origin.cursor.com/{owner}/{repo}.git
git push -u origin main

origin がすでに GitHub を指している場合は、既存の URL を置き換えずに cursor など別名のリモートを使ってください。Origin CLI のコマンドはその名前からリポジトリを推測しないため、実行時に -R owner/repo を渡してください。

Cursor Origin で GitHub リポジトリをミラーする方法

ミラーは既存の GitHub プロジェクトを Origin にコピーし、両サービスを接続し続けます。

Cursor Origin の GitHub ミラーリング要件

Origin へのアクセス、リポジトリの所有組織またはアカウントに接続された Cursor GitHub アプリ、およびそのリポジトリの GitHub 管理者権限が必要です。書き込み権限だけでは不十分です。

Cursor Origin の GitHub ミラーを開始する

cursor.com/codebase から Sync from GitHub を選択し、組織とリポジトリを選んで確定します。CLI の代替は origin repo create-mirrored owner/repo で、詳細は Cursor の ミラーリングドキュメントにあります。

Cursor Origin が GitHub からミラーする内容

Origin は Git データをミラーしますが、GitHub のすべての機能をミラーするわけではありません。

GitHub Actions は 引き続き GitHub 上で動作します。Depot と Buildkite の連携は Origin にホストされたリポジトリに適用され、ミラーには適用されません。

GitHub がソース・オブ・トゥルースのままの場合

リポジトリがミラーされている間、Origin 経由のプッシュは GitHub に伝播されます。リポジトリの Settings にある Detach from GitHub を実行すると、GitHub のリポジトリを変更せずに Origin 側のコピーをスタンドアロンにできます。

Cursor Origin でプルリクエストを作成・レビューする方法

Origin のプルリクエストは、他の Git ホストと同じブランチ、プッシュ、レビューの流れを使います。 弊社の プルリクエストの仕組みガイドでその流れを解説しています。

ブランチの作成と変更のプッシュ

作業ブランチを作成してプッシュします。

git checkout -b my-change
echo "Example change" >> README.md
git add README.md
git commit -m "Add example change"
git push -u origin my-change

Git の作業はここまで。次のコマンドは Origin の担当です。

Origin CLI でプルリクエストを作成する

リポジトリ関連コマンドは、origin という名前の Git リモートから対象を推測します。origin pr create を実行するか、-R owner/repo を渡してリポジトリを直接指定します。既定では draft が作成されます。レビュー可能にするには --status open を付けます。

Cursor Origin のプルリクエストをレビューする

CLI には origin pr list、 origin pr view、 origin pr diff、 origin pr checks が含まれます。CI アプリを設定していない場合、origin pr checks は No checks reported. と表示し、私の検証では終了コード 1 を返しました。

この終了コードは set -e を使うシェルスクリプトでは重要です。Checks タブが空でもプルリクエスト自体に問題がないのにスクリプトが停止し得るためです。

4 つのタブで行うプルリクエストレビュー。画像：著者作成。

Web ビューでは、すべてのプルリクエストに Activity、Commits、Checks、Files Changed の 4 つのタブがあり、レビュアーのリクエスト、インラインコメント、マージボタンも備わっています。Web ページはマージコンフリクトを表示し、origin pr status --conflict-status はターミナルからそれを報告します。

ターミナルからは origin pr merge も可能です。Origin にホストされたリポジトリで作成したプルリクエストは Origin 上に留まり、ミラーされたリポジトリでの活動は GitHub に送られます。

Cursor Origin のチームアクセスとリポジトリ権限

Origin の権限はコードベースとリポジトリの 2 つのレベルに存在します。

Codebase 設定と リポジトリ設定の違い

Codebase 設定はチーム全体に適用され、Origin を有効化できるユーザー、リポジトリの作成、アプリのインストールを管理します。リポジトリ設定は 1 つのリポジトリに限定され、General、Permissions、Rules and Protections、および Apps をカバーします。ただし Cursor のドキュメントでは Permissions と Rules 画面が再設計中である旨が警告されています。

チームメンバーが Origin を使えるのに特定のリポジトリだけ開けない場合は、チーム全体の設定ではなく、そのリポジトリの権限を確認してください。

Internal と Private リポジトリ

アクセスが制限されるリポジトリには 2 種類あります。

• Internal リポジトリは、コードベースにアクセスできるチームメンバーに表示されます。
• Private リポジトリは、直接またはコードベース権限を通じてアクセスが付与されたメンバーのみに表示されます。リポジトリを private に切り替えると、変更を行ったユーザーは管理者のまま残ります。

Cursor Origin のリポジトリアクセスを確認する方法

origin repo list コマンドは、現在のアカウントから見えるすべてのリポジトリを表示します。特定のリポジトリに誰がアクセスできるかを確認するには、Settings の Permissions を開いて確認します。

Cursor Origin のベストプラクティス

Origin を扱う際に特に重要な点が 3 つあります。

• リポジトリを削除または再設定する前に、完全な owner/repo 値を確認し、リモートを点検してください。

• 対象を検証するまで -y の使用は避けてください。

• Cursor の権限ページの記載に矛盾があるため、アクセス変更を自動化する前に現行ドキュメントを確認してください。

Cursor Origin と GitHub の比較：機能

Origin は Cursor のエージェントワークフローと結びついており、GitHub はより広いリポジトリエコシステムをカバーします。

Git ホスティング、プルリクエスト、CI/CD

各セクションの繰り返しは避け、機能分担の短いバージョンを示します。

この表で文脈が必要なのはエージェントの行です。

エージェントワークフローにおける Cursor Origin と GitHub

両プラットフォームともエージェントがリポジトリに対して作業できます。Origin はそのループを Cursor 内に保持し、GitHub は Agents パネルと Copilot ツール（一般提供の CLI を含む）で提供します。

Cursor Origin、GitHub、両方を使う判断基準

• Origin を使うのは、リポジトリがInternalまたはPrivateで、エージェント作業の大半がすでに Cursor 内で行われ、デプロイや CI が Vercel、Depot、Buildkite で運用できる場合。
• GitHub を主ホストに維持するのは、プロジェクトが公開である、Issues と Actions が日々のワークフローの一部である、またはチームが GitHub のアプリマーケットに依存している場合。
• 両方使うのは、ソースリポジトリを移さずに Origin のコード閲覧とエージェントワークフローを利用したい場合。ミラーにより、プッシュやプルリクエストの活動は GitHub に紐づいたまま、同じコードを Origin でも利用できます。

まとめ

WSL の新規セットアップから、GitHub と同じブランチ、コミット、プッシュの流れで Origin のプルリクエスト作成まで行えました。CLI は Git の使い方自体を変えず、Origin との差はホスティング、権限、ミラーリングの周辺で表れました。

使ってみて、私は Origin を GitHub の代替ではなく補完として捉えます。既存リポジトリにとって、GitHub を権威源のままにできるミラーリングが最も実用的な入り口です。公開プロジェクトや Actions を多用するワークフローは、現時点で移行する理由が乏しいでしょう。

関連資料として、Cursor Automations のガイドでは既存リポジトリに対して動作するエージェントタスクを扱っています。GitHub とは何か、どう使うかのガイドでは GitHub のワークフローをより詳しく説明しています。