必要なものは3つです。Originを利用できるCursorアカウント、変更できないcodebase名を決める担当者、そして最初に試す1リポジトリを用意します。
Cursor Originとは、コードの保存・共有、標準gitでのpush／pull、Pull Request、コード検索をCursor内で扱うgitフォージです。2026年10月19日時点ではearly betaとして提供されています。
GitHubをすぐ廃止する必要はありません。GitHubを管理元に残したミラー運用から始められ、2026年10月13日公開のApp Marketplaceでは20以上の連携アプリが案内されています。
手順1：Originの公式情報を時系列でつかむ
最初に押さえるべきなのは、Originそのもの、App Marketplace、Cloud Agentsの更新を混同しないことです。Originはコードを置くgitフォージ、MarketplaceはOriginへ外部ツールをつなぐ仕組み、Cloud Agentsの更新はエージェント実行環境の改善です。近い時期に発表されていますが、役割もbetaの対象も同じではありません。
| 日付 | 公式発表 | 確認できる内容 | 読者が区別する点 |
|---|---|---|---|
| 公開日表記なし 参照日：2026年10月19日 |
Origin公式ページ／ドキュメント | gitフォージ、early beta、対象プラン、リポジトリ作成、GitHubミラー、PR、コード検索、チーム共有 | Origin本体の仕様 |
| 2026年8月18日 | Git at any scale | 大規模なGitホスティングを支える設計上の課題と、Cursorが開発したGitストレージシステム「Continuity」の考え方 | 製品機能一覧ではなく技術背景 |
| 2026年10月13日 | Origin App Marketplace | 20以上のアプリ連携と、一般の開発ツール提供者からの公開申請受付 | 申請すれば即時掲載ではなく、Cursorの審査と承認がある |
| 2026年10月16日 | Cloud Agent Canvases and Environment Improvements | Canvasのリンク共有、Environments APIのbeta、1環境最大300リポジトリ、大規模環境の読み込み5倍高速化 | 300リポジトリはOriginの保存上限ではなくCloud Agent環境の上限 |
Cursorの技術記事「Git at any scale」は、Gitが分散型の仕組みでありながら、企業開発では中央ホストへの依存が大きいこと、packfileを前提としたGitホスティングを大規模に運用する難しさを説明しています。記事に登場するContinuityは、S3互換のオブジェクトストレージ上のwrite-ahead logを中心にしたCursorのGitストレージシステムです。
ただし、技術記事にある性能値はCursor自身の説明です。第三者ベンチマークとして扱うべきではありません。また、Originを「実験ではない」とする同記事の表現は設計姿勢を示すもので、early betaの終了、正式提供、SLAを意味するものではありません。
手順2：OriginでできることをGit操作と共有に分ける
Cursor公式のOriginドキュメントは、Originを「コードを保存・共有するためのgitフォージ」と説明しています。gitフォージとは、Gitリポジトリのホスティングに、Pull Request、レビュー、検索、権限管理、外部連携などを組み合わせた開発基盤です。
early betaで公式に確認できる主な機能は次のとおりです。
| 領域 | Originでできること | 実務上の意味 |
|---|---|---|
| リポジトリ | Originリポジトリを新規作成する。Cursorエージェントからの作成にも対応 | 人間がWeb UIから作る方法と、エージェントのタスク内で作る方法がある |
| Git操作 | 標準gitでclone、push、pullする | 独自の版管理方式へ置き換えるのではなく、通常のGitクライアントを使える |
| GitHub併用 | GitHubリポジトリをOriginへミラーする | 既存のGitHub運用を管理元として残しつつ、Originの閲覧・検索・エージェント機能を試せる |
| レビュー | Pull Requestの作成、レビュー、マージ | OriginホストのリポジトリではOrigin上のPRを扱える |
| コード把握 | ブラウザでコードを閲覧・検索 | チームのcodebaseから対象リポジトリやコードを探せる |
| 共有・権限 | Cursorチームと共有し、リポジトリ設定とcodebase設定を管理 | チーム所有と個人所有で可視性・共有方法が変わる |
| 自動化 | Origin Apps、automations、Cloud AgentsをOriginリポジトリへ接続 | CI、レビュー、セキュリティ、エージェント実行をリポジトリの流れへ組み込める |
チーム所有と個人所有では共有方法が違う
チーム所有のリポジトリは、作成時にInternalまたはPrivateを選びます。Internalはcodebaseへアクセスできるチームメンバーに見え、Privateは直接またはcodebase権限でアクセスを付与されたメンバーだけが見られます。個人アカウント配下で作るリポジトリは常にPrivateで、初期状態では本人だけに表示されます。個人リポジトリを共有する場合は、リポジトリのSettingsからCollaboratorsを招待します。
「Cursorのチームなら自動的に全リポジトリが見える」と一括りにせず、所有者、可視性、codebase権限、リポジトリ個別権限を確認してください。
手順3：対象プランとearly betaの条件を先に確認する
Originの製品ページは、early betaを「全有料プラン」で利用できると案内しています。より細かな公式ドキュメントの対象プラン欄では、現行のPremium、Super、Ultra、Teams、Enterpriseと、旧Start、Pro、Pro+、Ultraが対象です。FreeとPlusでは利用できないと明記されています。Plus（月額8ドル）は有料プランですが対象外で、料金ページの比較表でも「Code hosting via Origin」が付くのはPremium以上・Teams・Enterpriseです。製品ページの「全有料プラン」にPlusは入らない点に注意してください。
短い告知文だけで自社プランを推測せず、実際の契約名とドキュメントの列挙を照合するのが安全です。プラン名や提供条件は更新される可能性があるため、導入時にも公式ページを再確認してください。
有効化前に止まりやすい2条件
- codebase名：リポジトリURLの所有者部分に使うnamespaceです。beta期間中は、取得後に変更・更新できません。検証用の仮名を勢いで確保せず、組織で使い続けられる名称かを先に決めます。
- Privacy Mode：Originはnamespace ownerのPrivacy Modeに従います。legacy privacy modeのチームはOriginを有効化できず、利用するにはPrivacy Modeへの切り替えが必要です。
codebase名を誰が取得できるかは公式の説明がそろっていません。Originの概要ドキュメントは「チームの誰でも取得できる」、設定ドキュメントは「チーム管理者が取得して有効化し、管理者以外は同じ画面からアクセスを申請できる」と書いています。有効化後は管理者がリポジトリを作成し、Permissionsで他のメンバーにアクセスやリポジトリ作成の権限を渡します。管理者はダッシュボードからチームのOrigin利用を無効化することもできます。誰が名称を確保し、誰が権限を管理するかを事前に決めておくと、試行時の混乱を避けられます。
料金・容量・正式提供日は未確認
2026年10月19日時点で今回確認した公式ページには、Origin単体の料金、追加料金の有無、ストレージ容量、Originリポジトリ数、GitHubミラー数、ファイルサイズ、SLA、early betaの終了日、正式提供の開始予定日は示されていません。なお、Cursorの料金ページの比較表では「Code hosting via Origin」がPremium以上・Teams・Enterpriseのプランに含まれる機能として載っています。ただし、Origin固有の追加料金の有無や容量の上限は書かれていないため、「対象プランなら追加料金なし」「容量は無制限」「正式版は近い」とは判断できません。
同様に、10月16日に発表された「最大300リポジトリ」はCloud Agentの1環境が扱える数です。Originに保存できるリポジトリ数の上限として引用しないでください。
手順4：公式ドキュメントの順番で1リポジトリを始める
最初の検証では、既存運用への影響を把握しやすい1リポジトリに絞ると判断しやすくなります。以下はOriginのリポジトリ作成ドキュメントに沿った開始順です。
- 対象プランとPrivacy Modeを確認します。
- チーム内の担当者がCursorのcodebase画面を開き、Get Startedを選びます。
- セットアップ画面に従い、変更できないcodebase名を取得します。
- 管理者がcodebase settingsで、検証担当者へ必要なリポジトリアクセスを付与します。
- 新しいコードを置くならNew、GitHubの既存コードを残すならSync from GitHubを選びます。
- 新規作成ではRepo Nameを入力します。チーム所有ならInternalまたはPrivateも選び、Create Repoを実行します。
- 作成後にリポジトリを開き、Codeボタンからclone先を確認します。ローカルから標準gitでclone、push、pullできることを確かめます。
- コード閲覧、検索、Pull Request、メンバー権限の流れを、実際のチーム手順と照らします。
既存のローカルプロジェクトを新規Originリポジトリへつなぐ
Origin上に空のリポジトリを作り、既存のローカルプロジェクトを初回pushする場合は、公式ドキュメントに次の例があります。すでにGitHubで管理しているプロジェクトは、この手順でremoteを置き換えず、後述のGitHubミラーを選んでください。
cd your-project
git remote add origin https://origin.cursor.com/{owner}/{repo}.git
git push -u origin main動作環境：標準gitが使える端末です。最初にgitを操作する前に、Origin CLIを入れてorigin auth loginでサインインしてください（サインインするとgitの認証設定も済みます）。{owner}と{repo}は、作成したOriginリポジトリの値に置き換えます。すでにoriginというremoteがある場合や、既定branchがmainではない場合は、そのまま実行せず現在の設定を確認してください。
注意：本番環境で使用する前に、必ずテスト環境で動作確認してください。
コードがすでにGitHubにある場合、公式ドキュメントは空のOriginリポジトリへ手作業でコピーするのではなく、ミラーを案内しています。codebase画面でSync from GitHubを選び、GitHub organizationとリポジトリを指定して同期を確定します。前提としてCursor GitHub Appの接続と、対象GitHubリポジトリの管理者権限が必要です。
エージェントから作る場合も権限は同じ
CursorエージェントにOriginリポジトリの作成を依頼することもできます。エージェントはOrigin CLIの導入、サインイン、リポジトリ作成、remote設定、pushまでをタスク内で進められます。ただし、使う権限はCursorアカウントと同じです。人間のアカウントにOrigin code storageへのアクセスがなければ、エージェントに頼んでも作成は成功しません。
手順5：GitHubを残すか、Originを管理元にするか決める
GitHubとの違いを理解する近道は、「どちらが勝つか」ではなく「どこを管理元にするか」で比べることです。Originには2つの置き方があり、挙動が異なります。
| 判断点 | Originホスト | GitHubミラー |
|---|---|---|
| コードの管理元 | Originがsource of truth | GitHubがsource of truth、Originはmirror |
| 作り方 | codebase画面のNewから作成 | Sync from GitHubでorganizationとrepoを選択 |
| Origin remoteへのpush | Originへ反映 | GitHubへ送られ、GitHubが受け入れた後にOriginが更新 |
| Cloud AgentのPR | Origin Pull Requestを作成 | GitHub Pull Requestを作成 |
| 主な用途 | Originをコードホストとして試す | GitHubを残し、Originの閲覧・検索・エージェント作業を重ねる |
GitHubとの3つの違い
1つ目は、Cursorと同じcodebaseでエージェント作業までつなぐ設計です。Originではリポジトリ作成、コード閲覧・検索、PR、automations、Cloud AgentsをCursorのチームと結び付けます。一方、GitHubミラーを選べば、保存・PRの管理元をGitHubに残したまま、その履歴をOrigin側で利用できます。
2つ目は、ミラーが「GitHubの全機能コピー」ではないことです。公式のGitHubミラードキュメントでは、Git履歴、branch、tag、Originで閲覧・検索できるコード、Cursor内でレビューできるGitHub PR、継続的な更新が同期対象です。GitHub Issues、GitHub Actionsのworkflowとsecretは含まれません。IssuesとCI設定はGitHubに残ります。また、GitHub側でoriginまたはorigin/...という名前のbranchは、Origin専用の作業branchを上書きしないよう同期されません。
3つ目は、連携アプリがOrigin向けのMarketplaceとして用意され始めた段階であることです。2026年10月13日時点で20以上のアプリが案内されましたが、ミラーとOriginホストで動作条件が同じとは限りません。たとえばOrigin Appsの公式ドキュメントでは、DepotとBuildkiteはOriginホストのリポジトリだけに対応し、GitHubミラーではCIをGitHub側に残すと説明されています。
まずミラーが向くチーム
- GitHub IssuesやGitHub Actionsを継続して使う
- 既存の保護ルール、監査、外部連携を一度に変えたくない
- Originのコード検索やCloud Agentsを先に評価したい
- PRの管理元をGitHubに残したまま、Cursor側の操作感を確認したい
ミラーを解除する場合は、Origin側のSettingsからDetach from GitHubを選びます。同期が止まり、Originのコピーが独立したOriginホストのリポジトリへ変わります。Originが管理元になり、以後のOrigin remoteへのpushはGitHubへ流れません。元のGitHubリポジトリ自体は影響を受けない、と公式ドキュメントは説明しています。
手順6：App Marketplaceでつながる範囲を確認する
2026年10月13日のOrigin App Marketplace発表では、デプロイ、CI、コードレビュー、セキュリティ、監視、プロジェクト管理の6領域で20以上のアプリが案内されました。公式ページ上の分類は次のとおりです。
| 領域 | 掲載アプリ | Originで担う役割 |
|---|---|---|
| デプロイ | Cloudflare、Netlify、Render、Spacelift、Vercel | リポジトリの変更とデプロイ工程を接続 |
| CI | Buildkite、CircleCI、CloudBees、Depot、EngFlow、Namespace、RWX | buildやcheckの結果を開発フローへ返す |
| コードレビュー | CodeRabbit、Greptile、Tenki | PRコメントやreviewを連携 |
| セキュリティ | Artemis Security、Semgrep、Socket Security、Upwind | セキュリティ検査やcheckを連携 |
| 監視 | Sentry | 監視情報を開発の流れへ接続 |
| プロジェクト管理 | Linear | 開発タスクとリポジトリ作業を接続 |
公式の表現は「20以上」です。ページに並ぶ名前を機械的に数えた値を恒久的な掲載件数として固定せず、導入時にはMarketplaceの現行画面を確認してください。また、個別アプリの料金、対象プラン、サポート条件は、この発表ページだけでは確認できません。
自社アプリも申請できるが、承認制
同日から、開発者向けツールを作る一般のチームもOriginアプリを公開申請できるようになりました。公式の申請順は4段階です。
- 自分のnamespaceでアプリを作ります。開発中はnamespace内のPrivateとして扱います。
- Origin APIを使って実装します。アプリはapp JWTとinstallation access tokenで認証し、webhook eventを受け取り、check run、PRコメント、reviewを書き戻せます。
- アプリをPublicへ変更し、アプリのページからslug、推奨tag、demo videoを添えて申請します。動画にはinstall、uninstall、主要な製品フローを含めます。
- Cursorが申請をレビューし、承認した後にMarketplaceへ掲載します。
「公開申請の受付開始」は、無審査で即日掲載されるという意味ではありません。APIの仕様もearly beta中に変わり得るため、連携を作る側はOrigin APIの公式リファレンスと変更履歴を実装時に再確認する必要があります。
手順7：Cloud Agentsの10月16日更新を別枠で評価する
2026年10月16日のCloud Agents更新は、Origin Marketplaceとは別の発表です。ただし、OriginリポジトリへCloud Agentsを接続して使うチームには関連します。
- Canvas：Cloud Agentが作業の一部としてinteractive canvasを作れるようになり、完成したCanvasはリンクを送ってチームと共有できます。
- Environments API：エージェントが動くcloud environmentをプログラムから作成・管理するAPIがbetaになりました。
- 環境規模：Cloud Agentの1環境で最大300リポジトリを扱えると案内されています。
- 読み込み：大規模環境は5倍速く読み込まれると発表されています。
数値の読み方には注意が必要です。公式発表は「大規模環境」の定義、比較対象、測定条件、絶対時間を示していません。そのため「すべての環境が必ず5倍速い」とは書けません。Canvasの共有条件は、発表ページからリンクされた公式ドキュメントに書かれています。共有リンクを開けるのは同じチームのメンバーだけで、閲覧は読み取り専用です。共有するにはチームに入っていること、有料プラン（Premium以上・Teams・Enterprise・旧Pro／Pro+／Ultra）、データ保存を許すPrivacy Modeが必要で、Legacy Privacy Modeでは共有できません。管理者は組織全体で共有をオフにできます。リンクの有効期限は公式ドキュメントにも書かれていません。
手順8：自社で試す際の合格条件を先に決める
early betaを評価するときは、機能の有無だけでなく、今のGitHub運用をどこまで残せるかを確認します。日数で区切ったロードマップではなく、次の判定を順番に通す方法が現実的です。
判定A：管理元を決める
新規の検証用コードならOriginホスト、既存の本番コードならGitHubミラーから始める、という分け方が考えられます。重要なのは、チームがどちらをsource of truthとして扱うかを文書化することです。ミラー時にOrigin remoteへpushしても、処理はGitHubへ流れます。担当者がこの挙動を理解していないと、「どちらへ反映されたか」が曖昧になります。
判定B：同期されない資産を洗い出す
GitHub Issues、GitHub ActionsのworkflowとsecretはOriginミラーの同期対象ではありません。CI、issue管理、secret、branch保護、監査、通知について、現行運用のどこをGitHubに残すかを一覧にします。Originの機能だけを見て移行可否を決めず、リポジトリ外の運用資産まで含めて確認してください。
判定C：使うアプリを実リポジトリ方式で確認する
Marketplaceに名前があることと、自社の置き方で使えることは別です。OriginホストかGitHubミラーか、必要な権限は何か、外部サービス側の契約が必要か、checkやreviewがどこへ返るかを個別に確かめます。2026年10月19日時点で公式に確認できない料金やサポート条件は、各アプリの公式情報で確認するまで未確定として扱います。
判定D：戻し方と権限を確認する
ミラーを解除するとOriginが管理元になるため、単なる表示切替ではありません。検証終了時にミラーを維持するのか、detachするのか、Origin利用を無効化するのかを決めます。同時に、Internal／Private、個人所有／チーム所有、管理者／一般メンバーの見え方をテストします。
【要注意】試行時に起きやすい4つの誤解
誤解1：early betaでもGitHubをすぐ置き換えられる
❌ 避けたい判断：「OriginはGitHub代替」と決め、既存リポジトリを一括で移す。
⭕ 確認すべき判断：GitHubミラーで管理元をGitHubに残し、コード検索、PRレビュー、Cloud Agent、必要なAppの動作から評価します。公式はOriginをgitフォージと説明していますが、GitHubの全機能を置き換えるとは説明していません。
誤解2：ミラーならGitHubの全データが複製される
❌ 避けたい判断：Issues、Actions、secretまでOriginへ移る前提で運用を切り替える。
⭕ 確認すべき判断：同期されるGit履歴、branch、tag、コード、PRと、同期されないIssues、Actions workflow、secretを分けます。CI設定はGitHub側に残ります。
誤解3：最大300リポジトリはOriginの保存上限である
❌ 避けたい判断：Cloud Agents更新の数値を、Originの契約やストレージ上限として見積もる。
⭕ 確認すべき判断：300はCloud Agentの1環境が扱えるリポジトリ数です。Origin自体のリポジトリ上限やストレージ容量は、2026年10月19日時点で今回確認した公式ページからは確定できません。
誤解4：Marketplace掲載とCanvasリンクの条件は一律である
❌ 避けたい判断：掲載アプリはすべてGitHubミラーでも動き、Canvasリンクは社外へ匿名共有できるとみなす。
⭕ 確認すべき判断：アプリごとの対応方式を確認します。公式ドキュメントでは、Canvasの共有リンクを開けるのは同じチームのメンバーだけ（読み取り専用）です。社外の人や匿名の閲覧者には共有できない前提で使い方を決めます。
次に読むAIgent Labの既刊記事
Originを単独機能として見るだけでなく、Cursorのエージェント運用とリポジトリ作業の接点から読むと、試す範囲を決めやすくなります。
- Cursor Agentの使い方｜Cloud Agentの設定・料金・実力【2026年10月】 — Originリポジトリへ接続できるCloud Agentを含め、Cursor Agent全体の設定と使い分けを確認できます。
- Cursor Rollouts/Security Reviewとは｜設定と使い所【2026年9月】 — リポジトリへ変更を展開する際のレビューと安全確認を整理しています。
- worktrunkとは｜git worktree管理CLIの使い方【2026年10月】 — 複数作業を並行するgit worktree運用を、Origin導入とは別のローカル作業レイヤーから確認できます。
よくある質問
Cursor Originとは何ですか？
Cursorが提供する、コードを保存・共有するためのgitフォージです。リポジトリ作成、標準gitのclone／push／pull、GitHubミラー、Pull Request、コード閲覧・検索、Cursorチームでの共有、Origin AppsやCloud Agentsとの接続に対応します。2026年10月19日時点ではearly betaです。
Cursor OriginはGitHubの代わりになりますか？
用途次第です。OriginホストではOriginを管理元にできますが、公式はGitHubの全機能を置き換えるとは説明していません。GitHubミラーではGitHubを管理元に残せるため、既存チームは併用から評価できます。
GitHubミラーでは何が同期されますか？
公式ドキュメントでは、Git履歴、branch、tag、Originで閲覧・検索できるコード、CursorでレビューできるGitHub PR、継続更新が対象です。GitHub Issues、GitHub Actionsのworkflowとsecretは含まれません。
どのCursorプランで使えますか？
製品ページは全有料プランで利用可能と案内しています。詳細ドキュメントではPremium、Super、Ultra、Teams、Enterpriseと、旧Start、Pro、Pro+、Ultraが対象です。FreeとPlusでは利用できません。契約名が変わる可能性もあるため、開始時に公式の対象プラン欄を確認してください。
Origin App Marketplaceには何がありますか？
2026年10月13日の発表では、デプロイ、CI、コードレビュー、セキュリティ、監視、プロジェクト管理向けに20以上のアプリが案内されました。Cloudflare、Vercel、Buildkite、CircleCI、CodeRabbit、Semgrep、Sentry、Linearなどが掲載されています。
自社の開発ツールをMarketplaceへ出せますか？
申請できます。namespace内でPrivateアプリを作り、Origin APIで実装し、Publicへ変更してslug、推奨tag、demo videoを添えて申請します。Cursorのレビューと承認後に掲載されるため、自動掲載ではありません。
「最大300リポジトリ」はOriginの上限ですか？
いいえ。10月16日の公式発表にある最大300リポジトリは、Cloud Agentの1環境が扱える数です。Origin自体のリポジトリ数やストレージ容量の上限は、2026年10月19日時点で今回確認した公式ページでは案内されていません。
Originの追加料金と正式提供日は決まっていますか？
2026年10月19日時点で、Origin単体の料金、追加料金の有無、early betaの終了日、正式提供の開始予定日は、今回確認した公式情報では確認できません。対象プランの案内と、Origin固有の追加料金の有無は分けて考える必要があります。
ここまでの要点
- Cursor Originとは、コード保存・共有、標準git、PR、検索、チーム共有をCursorへまとめるgitフォージです。
- 2026年10月19日時点ではearly betaで、対象プランの詳細とFree／Plusの除外は公式ドキュメントで確認できます。
- 既存GitHubリポジトリは、GitHubをsource of truthに残したミラー運用から始められます。
- GitHub Issues、GitHub Actionsのworkflowとsecretはミラー対象ではありません。
- 2026年10月13日のApp Marketplaceでは20以上の連携アプリと一般申請の開始が発表されました。
- 2026年10月16日の最大300リポジトリと5倍高速化はCloud Agent環境の更新であり、Originの保存上限ではありません。
- codebase名はbeta中に変更できないため、名前、管理者、管理元、同期対象外、戻し方を決めてから1リポジトリで検証します。
運営元 Uravation よりAIエージェントを構想から本番運用まで進める順番と、体制・KPIの決め方をまとめた資料を無料で公開しています。 AIエージェント導入ロードマップを受け取る（無料）
参考・出典
- Origin | Cursor Docs — Cursor（参照日：2026年10月19日）
- Cursor · Origin — Cursor（参照日：2026年10月19日）
- Git at any scale — Cursor、2026年8月18日（参照日：2026年10月19日）
- Origin App Marketplace — Cursor、2026年10月13日（参照日：2026年10月19日）
- Cloud Agent Canvases and Environment Improvements — Cursor、2026年10月16日（参照日：2026年10月19日）
- Create an Origin repository | Cursor Docs — Cursor（参照日：2026年10月19日）
- Mirror a GitHub repository | Cursor Docs — Cursor（参照日：2026年10月19日）
- Origin Apps | Cursor Docs — Cursor（参照日：2026年10月19日）
CursorやAIエージェントを、自社のリポジトリ権限・レビュー・CI運用に合わせて試したい方へ
Uravationでは、AIエージェント導入の研修・コンサルティングを行っています。現在の開発フローを残した検証範囲の整理からご相談いただけます。
