Cursorが​自社で​コードを​預かり​始めた​ ──AIエージェント向けコードホスティング​「Origin」を​解説

2026年8月17日、AIコードエディタのCursorが「Origin」というコードホスティングを公開した。ソースコードの置き場所そのもの、つまりGitHubが担ってきた役割をCursor自身が提供する。有料プランの利用者には、順次自動で開き始めている。

結論から言うと、これは機能追加というより「預け先」の変更の話だ。そして預け先が変わると、これまで「うちは大丈夫」と説明してきた根拠のほうが先に古くなる。実際、Cursorの企業向けデータ取扱いドキュメントには本日時点で「コードの保存が必要な機能はCloud Agentsだけ」という一文が残ったままで、Originについては一言も触れられていない。

この記事で分かることは4つ。①8月17日に何が公開されたのか ②Originで実際にできること ③公式ドキュメント同士が食い違っている箇所と、その意味 ④導入を検討する前に確認すべき実務条件。

01 8月17日、​コードの​置き場所が​増えた​──GitHubが​止まっていた​日に

Cursorは2026年8月17日、Originを早期ベータとして公開した。同社の更新履歴には「Cursorがあなたのコードをホストできるようになった」と書かれている。提供対象は有料プラン（Pro／Teams／Enterprise）で、無料のHobbyプランでは使えない。企業向けのEnterprise組織については、管理者が明示的に停止していない限り対象に含まれる。

公開初日は、奇しくもGitHubが世界規模で停止していた日と重なった。GitHubの障害はプルリクエスト、Issues、Actions、Webhook、Copilotに及び、数時間にわたって開発現場を止めている。狙って合わせたわけではないだろうが、「コードの置き場所は一箇所でいいのか」という問いが最も刺さる日に出てきたことは確かだ。

Cursorはもともとエディタの会社だった。そこから、AIエージェントがコードを読み、書き、レビューし、マージするところまでを引き受ける方向に進んできた。Originはその線の先端にある。エージェントに仕事をさせるなら、コードが置いてある場所と作業する場所は近いほうが速い。そういう発想の製品だ。

02 Originとは​何か​──エディタの​会社が、​保管と​レビューまで​引き受ける

Originは、Cursorが提供するGitのホスティングだ。公式ドキュメントは自らをgit forge（gitフォージ）と呼んでいる。GitHubやGitLabと同じ種類のもの、と考えて差し支えない。

早期ベータの時点でできることは、公式ドキュメントによると次のとおり。

• リポジトリの作成（Cursorのエージェントに作らせることもできる）
• 通常のgitコマンドでの clone / push / pull
• GitHubにあるリポジトリのミラー（複製して同期し続ける）
• プルリクエストの作成・レビュー・マージ
• ブラウザ上でのコード閲覧と検索
• Vercel / Depot / Buildkite の接続
• 定期実行やイベント起動の自動処理（Automations）とクラウドエージェントの接続

注目すべきは最後の2つだ。Originに置いたリポジトリには、Cursorのクラウドエージェントを直接つなげられる。エージェントはブランチを切り、コミットし、pushし、プルリクエストを開くところまでやる。人間がGitHubを開いてエージェントの成果を取り込む、という往復が一段減る。

もうひとつ、既にGitHubを使っている組織向けに「ミラー」がある。GitHubのリポジトリをOriginに複製し、以後の変更を同期し続ける仕組みだ。この状態ではGitHubが正（source of truth）のままで、Originはあくまで複製にとどまる。プルリクエストは双方向に同期する。

03 ​「コードを​保存するのは​Cloud Agentsだけ」が​成立しなくなった

ここが今回いちばん重要な点だ。

Cursorの企業向けドキュメント「Privacy and Data Governance」には、セキュリティ審査のために読まれることを想定した説明が並んでいる。そこにこう書かれている。

Cloud Agents are the only feature that requires Cursor to store code.
（Cursorがコードを保存する必要がある唯一の機能は、Cloud Agentsです）

Cursor Docs「Privacy and Data Governance」より

そして続けて、こう案内している。

Cloud Agents are optional. If your security policy prohibits code storage, don't enable Cloud Agents. You can still use all other Cursor features.
（Cloud Agentsは任意です。コードの保存を禁じるセキュリティポリシーであれば、Cloud Agentsを有効にしないでください。他のCursorの機能はすべて使えます）

同上

つまり従来の説明はこうだった。Cursorに送られたコードはAIへの問い合わせのために一時的に処理されるだけで、保存されるのはクラウドエージェントが動いている間の暗号化コピーのみ。それが嫌なら、その機能だけ切ればいい。

Originはこの前提の外にある。コードをホストするというのは、置いたコードがそこに在り続けるということだ。一時的に処理して捨てる話ではない。にもかかわらず、本日（2026年8月19日）時点でこのページの本文にOriginという語は一度も出てこない。データの保管場所を選ぶ「データ所在地」の対象一覧にもOriginはなく、顧客管理鍵（CMEK）で暗号化される対象として挙がっているのも「埋め込みデータ」と「Cloud Agentのデータ」の2つだけだ。

Origin側のドキュメントで保存について触れているのは、次の一行だけだった。

Origin follows the Privacy Mode of the namespace owner.
（Originは、その名前空間の所有者のプライバシーモード設定に従います）

Cursor Docs「Origin」より

プライバシーモードは「コードを学習に使わせない」ための設定であって、「どこにどれだけ保管され、いつ消えるか」を定める設定ではない。保持期間、削除の手順、保管される地域についての記述は、現時点のOriginドキュメントには見当たらない。

念のため補足すると、これは「規約がない」という意味ではない。Cursorには全社的な暗号化（転送時TLS 1.2以上、保存時AES-256）もデータ処理契約もある。問題は、企業の情報システム部門が審査のときに読む文書のほうが、製品の実態に追いついていないことだ。「コードを保存する機能はこれだけです」という一文を根拠に社内稟議を通した組織にとって、その根拠は先週までのものになっている。

こうした「発表ページと製品ドキュメントで話が食い違う」現象は、AI各社の発表を日々追うなかで繰り返し見てきたものでもある。新機能が出たとき、多くの記事は発表側の言葉をそのまま伝える。実務で効いてくるのは、たいてい更新されなかった側の文書のほうだ。

関連記事 ｜ 発表と公式ドキュメントが正反対だった例Grok Botとは何か ──AIチームメイトに「クラウドのPC」を渡して24時間働かせる、SpaceXAIの新アプリを解説 →

04 乗り換える​前に​見ておく​実務条件──ミラーで​来る​もの、​来ない​もの

Originに移す・併用する判断をする前に、公式ドキュメントから読み取れる条件を並べておく。どれも早期ベータ時点のもので、今後変わる可能性がある。

GitHubからミラーしても、全部は来ない。 同期されるのはgitの履歴・ブランチ・タグ・コード・プルリクエスト（双方向）まで。Issues と、GitHub Actionsのワークフローおよびシークレットは同期されない。課題管理とCI/CDはGitHubに残る。「Originに移したから障害時も平気」とはならない構成になりやすい。

CIの接続先が、リポジトリの生まれで変わる。 DepotとBuildkiteはOriginで作ったリポジトリでのみ動作し、GitHubからミラーしたリポジトリでは使えない。ミラーの場合はCIをGitHub側に置いたままにする。

「切り離す」と正が入れ替わる。 ミラーの同期をやめる操作（Detach from GitHub）は設定画面の危険操作エリアにあり、実行するとOriginが正となり、以後のpushはGitHubに流れなくなる。GitHub側のリポジトリ自体は消えないが、どちらが本物かが変わる。

名前空間は先に取った者勝ちで、ベータ中は変更できない。 リポジトリのURLに入る組織名にあたる部分（codebase name）は、一度確定すると早期ベータの間は変更・更新ができないと明記されている。しかも取得できる人の範囲について、公式ドキュメント内で記述が食い違っている。概要ページは「チームの誰でも取得できる（Any team member can claim the codebase name）」、設定ページは「チーム管理者が取得する（A team admin claims the codebase name）」となっている。どちらが実際の挙動かはベータ中に変わる可能性があるが、少なくとも「気づいた誰かが先に取ってしまえる」前提で動いたほうが安全だ。

確認項目	早期ベータ時点の条件
対象プラン	Pro / Teams / Enterprise。無料のHobbyは対象外（Individualは月20ドルから、Teamsは1人あたり月40ドル、Enterpriseは個別見積もり）
ミラーで同期されるもの	git履歴・ブランチ・タグ・コード・プルリクエスト（双方向）
ミラーで同期されないもの	Issues、GitHub Actionsのワークフローとシークレット
CI連携	Depot / Buildkite はOrigin作成のリポジトリのみ。ミラーはGitHub側にCIを残す
切り離し	Detach from GitHub で正がOriginへ移る（設定の危険操作エリア）
名前空間	ベータ中は取得後に変更・更新不可。取得権限の記述は公式内で不一致
プライバシー設定	名前空間所有者のプライバシーモードに従う。旧設定のままのチームは有効化できない

05 今​日​決める​こと──急いで​移す理由は​ないが、​止める​判断は​要る

エンジニアでなくても、意思決定として確認できることがある。

• 自社のチームがCursorの有料プランを使っているか。使っているなら、Originは既に有効化できる状態にある
• Enterpriseを契約しているなら、管理者側で機能を停止できる。使わせるのか、当面止めるのかを決める
• 「コードは外部に保存されない」と説明して導入した経緯があるなら、その説明の根拠になった文書を読み直す
• 名前空間を、誰がいつ取得するかを先に決める（ベータ中は取り直せない）
• 試すなら、まずミラーで並走させる。GitHubを正のままにしておけば、判断を後に回せる

急いで移す理由は、少なくとも今日の時点では見当たらない。逆に、知らないうちに使い始められる状態にはなっている。この非対称が、今回いちばん実務に効く。

06 まとめ──発表文の​隣に、​去年から​ある​文書を​置いて​読む

Originは、AIエージェントに仕事をさせる前提でコードの置き場所を作り直そうという製品だ。エージェントがコードを読んで直してプルリクエストまで出すのなら、置き場所と作業場所は近いほうがいい。その方向自体は筋が通っている。

一方で、コードをどこに置くかは、機能の便利さだけで決める話ではない。今回のように、製品が先に動いて、説明のほうが後から追いつくことがある。新しい道具を評価するときは、発表文の隣に、その会社が去年から置いている文書を並べて読む。差分が出たところが、いま自分たちの確認すべき場所になる。

区分	内容
今日できること	有料プランでのリポジトリ作成／GitHubからのミラー／プルリクエストのレビューとマージ／コードの閲覧と検索／Vercel・Depot・Buildkiteの接続／クラウドエージェントと自動処理の接続
まだ確認できないこと	Originに置いたコードの保持期間・削除手順・保管地域の明記／企業向けデータガバナンス文書への反映／顧客管理鍵（CMEK）の対象かどうか／名前空間を取得できる権限の正確な範囲