Cursor Originの使い方｜GitHub同期と移行手順

こんにちは。AIあれこれ散歩道、運営者のもっちゃんです。

Cursor Originの使い方を調べると、新規リポジトリ、GitHubミラー、PR、エージェント、切り離しといった言葉が一度に出てきます。便利そうに見える一方で、GitHubとどちらが正本になるのか、今のCIが動き続けるのか、不安になりますよね。

この記事では、2026年8月17日に公開された早期ベータの公式情報を基に、最初の始め方から移行前の確認まで順番に解説します。先に結論を言うと、既存のGitHub運用があるなら、まずミラーで小さく試し、チームの権限やCIまで確かめてから次を決めるのが安全です。

Cursor Originの使い方と基本機能

最初の章では、Cursor Originの役割、対象プラン、新規作成とGitHub同期の手順を見ていきます。Originだけで始める方法とGitHubを正本にしたまま試す方法は、似ているようで運用上の意味が違います。

Originでできること

Cursor Originは、Cursorの中でコードを保管し、閲覧、変更、プルリクエスト、コメント、エージェント作業をつなぐコードホスティング機能です。2026年8月17日の発表時点では早期ベータであり、完成済みの固定仕様ではありません。現在の位置付けは、Cursor公式のOrigin発表で確認できます。

使い始める経路は二つあります。一つはOriginに新しいリポジトリを作る方法。もう一つは、既存のGitHubリポジトリをOriginへミラーする方法です。新規作成では最初からOriginがコードの置き場所になります。ミラーでは、GitHubを正本として残したままOriginの機能を試せます。

コード画面だけを見ると、一般的なGitホスティングと大きく変わらないように感じるかもしれません。違いは、Cursorのエージェントがリポジトリ、ブランチ、PRの流れへ近い場所で作業できる点です。PRコメントへ対応し、変更を更新し、ブランチへ反映する一連の作業をCursor内で進められます。

Cursor Originの公式紹介ページでは、リポジトリを開いた画面からコードを読み、依頼内容をエージェントの変更へつなぐ流れが示されています。ここで覚えておきたいのは、Originが単独のコード置き場としても、GitHubを残した入口としても使えることです。導入時は見た目の便利さだけで決めず、今使っているレビュー、通知、デプロイの流れをどこへ残すかまで考えましょう。

ただし、エージェントへ依頼できることと、変更を無条件で採用してよいことは別です。生成された差分を人が読み、テスト結果を確認し、重要ブランチへの反映は承認後に行う仕組みを残してください。便利さの中心は「確認をなくすこと」ではなく、変更案ができるまでの往復を短くすることです。

利用条件と対象プラン

Originは、早期ベータの開始時点でCursorの有料プラン向けに案内されています。対象には個人向けとチーム向けの有料プランが含まれますが、契約名、提供地域、管理者設定、段階的な反映によって画面に表示される時期が違う可能性があります。

機能の入口が見当たらないときは、別のアカウントでログインしていないか、チーム管理者がOriginを無効にしていないか、現在の契約が対象かを順番に見ます。企業では、管理者が組織全体で利用を止める選択肢も案内されています。個人の画面だけで原因を決めず、チーム設定も確認しましょう。

料金については、Origin専用の独立した追加料金を公式資料で確認できませんでした。そのため「追加料金なし」と断定するのではなく、Cursor公式の料金とプランで契約内容を見たうえで、Origin画面に表示される条件を確認するのが現実的です。早期ベータ後に条件が変わる可能性もあります。

Cursor全体のプラン感を日本語で先に把握したい場合は、Cursorの料金と使える範囲を解説した記事も参考になります。ただし、リンク先はCursor for iOSを中心にした内容です。本記事ではOriginのコードホスティングに範囲を絞っています。

新規リポジトリを作る手順

新しい企画をOriginで始めるなら、CursorのCodebase画面から新規リポジトリを作成します。最初からOriginを正本にできるため、GitHubとの同期関係を考える必要がありません。一方で、チームがGitHubの課題管理、Actions、監査、外部アプリへ依存しているなら、作成前に代替手段を確認する必要があります。

公開範囲は、用途が決まっていなければプライベートから始めるほうが扱いやすいです。READMEだけの状態で一度クローンし、ブランチを作り、PRを開き、承認後にマージする流れを試します。いきなり本番コードを移すより、空に近いリポジトリで権限の見え方を確認できます。

CLIを使う場合は、Origin専用CLIで認証し、リポジトリ作成やクローンを行えます。コマンド操作に慣れていても、最初はWeb画面で作成結果と公開範囲を見てください。名前の打ち間違いより、誤ったチームや公開範囲へ作る事故のほうが影響が大きいためです。

作成後は、ローカルのremote URL、既定ブランチ、メンバー、保護ルールを記録します。READMEに秘密情報を書かず、APIキーや接続文字列は秘密情報管理へ置きましょう。初回PRで、レビュー必須や直接プッシュ禁止が期待どおり働くかも確かめます。

GitHubを同期する手順

既存リポジトリでOriginを試す場合は、GitHubミラーが始めやすい経路です。GitHubとの接続を許可し、対象リポジトリを選ぶと、Origin側へコードが同期されます。この段階ではGitHubが正本です。普段の開発者がGitHub中心で作業を続けても、OriginでコードやPRを確認できます。

GitHub Appへ広い権限を与える前に、試験用リポジトリ一つへ限定できないか見ます。個人リポジトリと会社リポジトリを同じ感覚で許可せず、組織の管理者ルールに従ってください。不要になった接続を外す担当者と手順も、導入時に決めておくと安心です。

初回同期後は、OriginとGitHubでコミットID、既定ブランチ、直近PRを見比べます。表示されることだけで合格にせず、コメント、返信、更新コミットが期待どおり双方へ現れるか試します。同期には時間差が出る場合もあるため、更新直後に何度も同じ操作を繰り返さないようにしましょう。

ミラー中にGitHubを消したり、Originを独立させたりする必要はありません。まず日常の一部だけで使い、チームが困る点を見つけます。PRの見え方、通知、CI結果、ブランチ保護まで確認できれば、Originを本格利用するか判断しやすくなります。

PRとエージェントの活用

Originでは、コードを眺めるだけでなく、PRの作成、コメント、返信、変更の更新をCursorの作業につなげられます。レビューで「この条件もテストしてほしい」と指摘されたら、エージェントへ修正案を作らせ、差分とテスト結果を見てからPRへ反映する流れです。

依頼文には、対象ブランチ、変更してよいファイル、合格条件、実行するテストを明記します。「直しておいて」だけでは、必要以上に広い変更になるかもしれません。変更禁止のディレクトリ、追加してよい依存関係、公開してはいけない情報も先に伝えると、レビューしやすい差分になります。

エージェントが作ったコードは、作者名だけを見て通さず、通常の開発と同じ確認を行います。差分を読み、テストを実行し、外部通信先や新しい依存関係を見ます。PR本文には、変更目的、確認したテスト、未確認の点を残してください。あとで不具合を追う人が経緯をたどれます。

ほかのAIコーディング環境も比べたいなら、CodexをWindowsへ導入する手順が参考になります。GitHub中心の支援を続ける場合は、GitHub CopilotでClaude Opus 5を使う方法も確認できます。どの製品でも、人によるレビューと戻せるブランチ運用は共通して残したい部分です。

Cursor Originの使い方と安全な移行

後半では、GitHubミラー中の正本、Originを独立させる切り離し、権限、ブランチ保護、VercelやCI連携を確認します。特に切り離しは、単なる同期停止ではなく、コードの正本を変える操作として扱う必要があります。

ミラー中の同期範囲

GitHubミラー中は、GitHubが正本で、Originはそこから同期した状態です。PRのコメントや返信、変更の更新をOriginから扱えても、リポジトリの基準はGitHub側に残ります。この関係をチーム全員が同じ言葉で理解していることが大切です。

日常運用では、どちらの画面から作業を始めてもよい部分と、GitHubでしか行わない部分を決めます。たとえば、PRの最終承認、リリースタグ、保護ルール変更はGitHubへ寄せ、Cursorではコード閲覧と変更案作成を行う、といった分担です。

Origin AppsやWebhookを使いたい場合にも注意があります。公式API文書では、GitHubからミラーしたリポジトリはOrigin AppsとOrigin Webhookの対象外と案内されています。ミラーを選びながらOriginネイティブ向けの自動化まで同時に期待すると、設計が合わなくなります。

同期の確認は、画面にリポジトリ名が出るかだけでは足りません。小さなコミットを作り、PRを開き、コメントへ返信し、CI完了後にマージする一周を試しましょう。途中で情報が欠ける場所があれば、担当者がどちらの画面を見るかを手順へ追加します。

切り離し前の確認項目

GitHubミラーをOriginから切り離す操作は、設定のDanger Zoneにあります。実行するとOrigin側のコピーが独立し、Originが新しい正本になります。以後、OriginからGitHubへはプッシュされません。元のGitHubリポジトリは消えませんが、二つの履歴が別々に進み始めます。

この挙動は、Cursor Originの公式設定ガイドに明記されています。つまり、切り離しは「一時的に同期を止めるボタン」ではありません。チームのclone先、CI、デプロイ、バックアップ、外部連携がOrigin側へ向く準備を終えてから実行します。

切り離し直前には作業時間を決め、新しいマージを一時停止します。最終コミットIDを記録し、Origin側とGitHub側が同じ地点にあることを二人以上で確認します。途中のPRやローカルだけにあるブランチも確認し、置き去りになる変更をなくしてください。

切り離し後は二つのリポジトリが自動で同じ状態へ戻る前提にしないことが重要です。元GitHubを一定期間読み取り専用にする、移行案内をREADMEへ置く、古いremoteへプッシュしない保護を入れるなど、混乱を避ける準備をします。

権限とブランチ保護

コードの置き場所を選ぶときは、機能数より先に、誰が見られ、誰が変更でき、誰が保護ルールを変えられるかを確認します。Originではプライベートまたは組織内向けの公開範囲、Rules、Protectionsが用意されています。名称が似ていてもGitHubと設定項目が同じとは限りません。

管理者は少人数に限定し、開発者には担当リポジトリで必要な権限だけを付けます。退職、異動、外部協力の終了時に権限を外す手順も必要です。チーム単位で付与した権限と個人へ直接付けた権限が混ざると追いにくいため、付与経路を決めておきましょう。

重要ブランチでは、直接プッシュを避け、PR、レビュー、必要なチェックを通してからマージします。管理者だけが迂回できる設定を残す場合も、いつ誰が使ったか分かる記録を残してください。緊急修正を理由に日常的な迂回が増えると、保護ルールが形だけになります。

エージェント用の権限も、人の管理者権限と同じ範囲にしないほうが扱いやすいです。作業対象を限定し、秘密情報へ触れず、公開や削除の直前に人が承認する流れを作ります。誤った変更が入っても、ブランチを戻し、監査できる状態を保ってください。

VercelとCIの連携

Originの公式連携には、Vercel、Depot、Buildkiteが案内されています。Vercelはデプロイ、DepotとBuildkiteはビルドやCIへつなぐ選択肢です。ただし、選んだリポジトリ方式によって利用できる連携が違います。

Cursor Originの公式連携ガイドでは、DepotとBuildkiteのOrigin連携はOriginホストのリポジトリ向けに案内されています。GitHubミラー中は、既存のGitHub側CIをそのまま保つ考え方です。ミラーを作った直後にGitHub Actionsを止める必要はありません。

デプロイ連携は、テスト用環境から始めます。PRごとのプレビューが作られるか、失敗結果がどこへ表示されるか、マージ前に必須チェックとして扱えるかを確認してください。本番の環境変数や秘密情報を移す前に、ダミー値で接続経路を試します。

独自の自動化にはOrigin APIとOrigin Appsを使えます。認証ではEd25519で署名したJWTから短命のインストールトークンを取得します。秘密鍵をソースコード、ブラウザ、ログへ置かず、サーバー側の秘密情報管理で扱ってください。権限スコープと対象リポジトリも必要最小限にします。

APIは早期ベータであり、変更される可能性があります。実装前にCursor Origin APIの公式文書を読み、トークン期限、必要スコープ、Webhook、ミラーの制約を確認しましょう。失敗時の再試行には上限を設け、同じ書き込みが重複しない仕組みも用意します。

連携テストでは、成功だけでなく失敗も起こします。テストを一つ落としたPRがマージを止めるか、期限切れトークンで処理が安全に止まるか、連携を解除したあとに書き込みが続かないかを確かめます。正常時より、異常時の動きが運用の安心を左右します。

よくある質問（FAQ）

Q1. Cursor Originは無料プランで使えますか？

A. 2026年8月20日の確認時点では、早期ベータは有料プラン向けに案内されています。契約名や提供条件は変わる可能性があるため、ログイン中のプランとOrigin画面の表示を確認してください。

Q2. ミラーするとGitHubリポジトリは消えますか？

A. 消えません。ミラー中はGitHubが正本で、Origin側に同期されたコードを閲覧し、PRやエージェント機能を使えます。まず試験用リポジトリで同期範囲と権限を確かめましょう。

Q3. ミラーを切り離すとどうなりますか？

A. Origin側のコピーが独立し、Originが正本になります。OriginからGitHubへのプッシュは止まり、二つの履歴が別々に進みます。元GitHubは残りますが、簡単な一時停止として実行しないでください。

Q4. GitHub Actionsはそのまま使えますか？

A. GitHubミラー中は、GitHubを正本として既存のGitHub側CIを続ける運用が基本です。Originネイティブへ移る場合は、Vercel、Depot、Buildkiteなどを含め、別のCIとデプロイ経路を先に試してください。

Q5. 新規作成とGitHubミラーはどちらがおすすめですか？

A. 新しい小規模企画ならOriginネイティブも候補です。既存のGitHub運用、CI、外部アプリがあるなら、まずミラーで試すほうが戻り道を残せます。実際の一周を試してから正本変更を判断しましょう。

まとめ Cursor Originの使い方

Cursor Originの使い方で最も大切なのは、機能を触る前にコードの正本を決めることです。新規リポジトリはOriginネイティブで始められます。既存GitHubがある場合は、GitHubを正本にしたミラーから試せます。

まずは試験用リポジトリ一つで、接続、PR、コメント、CI、権限削除まで一周してください。そこでチームの手順に合うと分かれば対象を少しずつ増やせます。切り離しや本番デプロイは、その一周が終わってから判断するのが安心ですよ。