Cursor が、自らコードをホストする機能を持ち始めました。2026 年 8 月 17 日に発表された Origin は、Cursor の中にリポジトリと pull request（PR）の作業面を置きます。さらに 2 日後の 8 月 19 日には、PR や Slack スレッドを監視する Subscriptions、長期目標を渡す /goal、隔離された仮想マシン（VM）で動くサブエージェントなど、クラウドエージェントをイベントから継続的に動かすための更新が発表されました。
ここで最初に解消しておきたい疑問があります。Origin は GitHub を置き換えるのでしょうか。答えは「置き換えない」です。 少なくとも GitHub から始めたリポジトリでは、push は引き続き GitHub に送られ、GitHub が source of truth（正とする情報源）のままです。Origin は GitHub と双方向に同期しながら、Cursor 内でレビューやエージェント作業を進めるためのもう 1 つの作業面です。
本記事では、Origin の公式発表と、クラウドエージェント更新の changelogに記載された範囲を整理します。製品として確認できることと、導入時にチームで決める運用を分けて見ていきましょう。
1. 何が発表されたのか
今回まとめて捉えたい発表は 2 件です。1 件目はコードを置く場所と PR の作業面、2 件目はその周囲でエージェントが動き続ける仕組みに関するものです。
| 発表日 | 更新 | 公式発表で確認できる中心機能 | 開発フローでの位置づけ |
|---|---|---|---|
| 2026 年 8 月 17 日 | Origin | コードホスティング、Codebase タブ、PR、GitHub との双方向同期、外部アプリ連携 | リポジトリとレビューの作業面 |
| 2026 年 8 月 19 日 | クラウドエージェント更新 | Subscriptions、/goal、隔離 VM のサブエージェント、作業中の Steering | イベントを受けて作業を継続する実行面 |
Origin だけを見ると「Cursor が GitHub の競合サービスを始めた」と読みたくなります。しかし公式発表は、GitHub から始めたものについて GitHub が source of truth であり続けると明記しています。2 件を一緒に見ると、狙いは保管場所の単純な置換よりも、コード、PR、イベント、エージェントの距離を縮めることだと理解しやすくなります。
FIXITCursor がコードをホストするなら、GitHub から移行する話ですか？
IrodoriGitHub 由来のリポジトリは違います。push は GitHub に向かい、GitHub が正のままです。
FIXIT置き換えではなく、同期された作業面が Cursor に増えるのですね。
Irodoriその理解が出発点です。そこを押さえると、PR とエージェントの更新も一本につながります。
2. Origin とは何か
Origin は、Cursor が early beta で提供するコードホスティングです。公式発表は「エージェント規模を前提に設計された」と説明しています。単に Git のリモートを用意するだけではなく、Cursor 内でリポジトリを作り、PR を読み、レビューからマージまで進める構成です。
Codebase タブが Origin リポジトリの入口になる
新しい Codebase タブが Origin リポジトリのホームです。+New からリポジトリを作成すると、ローカルのプロジェクトを clone / push するための CLI インストール手順が案内されます。
ここで公式発表から確認できるのは、リポジトリ作成と、ローカルから接続するための導線までです。ストレージ上限、対応リージョン、料金体系は今回の発表抜粋にありません。導入判断で必要なら、early beta の画面や最新の契約情報を別途確認してください。
すべてのリポジトリに PR がある
Origin の各リポジトリには PR 機能があります。差分のレビュー、コメント、マージを行え、画面には timeline、commits、checks、files changed が表示されます。
つまり、変更ファイルだけを見る簡易ビューではありません。変更に至る経過、コミット、チェック結果、ファイル差分を同じ PR の文脈で追える設計です。GitHub と同期したリポジトリの場合は、レビューの場が Cursor 側にも現れる、と捉えるとわかりやすいでしょう。
要点
Origin の重要点は「コードを保存できる」だけではありません。Cursor 内に PR のレビュー・コメント・マージまでの面があり、クラウドエージェントの作業結果を同じ場所で確認できることです。
Cursor の日常的な設定やルール整備から始めたい場合は、Cursor Rules の MDC ガイドも参照してください。Origin はコードを置く面、Rules はエージェントへプロジェクト固有の前提を渡す面であり、役割が異なります。
3. GitHub とはどういう関係か
ここが Origin を理解するうえで最も重要です。GitHub から始めたリポジトリでは、GitHub が source of truth のままです。公式発表は、push が引き続き GitHub に送られると明記しています。
「双方向同期」と「source of truth」は矛盾しません。双方向同期は、両方の画面で変更や会話を扱えるという意味です。一方、source of truth は、最終的にどちらを正として扱うかという意味です。Cursor 側で操作できることを、そのまま主系の移転と読み替えてはいけません。
| 観点 | Origin / Cursor 側 | GitHub 側 | 判断 |
|---|---|---|---|
| リポジトリ更新 | 同期された内容をリアルタイムに反映 | GitHub 由来では push の送信先 | GitHub が source of truth |
| コメント | Cursor で書くと GitHub に投稿 | GitHub でのリアクション・返信が Cursor に反映 | 会話は双方向同期 |
| PR の確認 | timeline・commits・checks・files changed を表示 | 同期先として PR の情報を保持 | Cursor からレビュー可能 |
| 既存 CI | 連携から既存 GitHub Actions を実行 | 既存 workflow を管理 | workflow の移設は必須ではない |
コメント同期も具体的です。Cursor でコメントすると GitHub に投稿され、GitHub でリアクションまたは返信すると Cursor に数秒以内に表示されます。レビュー参加者の一部が Cursor、別の参加者が GitHub を見ていても、会話を往復させられます。
ただし、同期されるからといって運用上の責任まで自動で一本化されるわけではありません。これは製品仕様ではなく運用提案ですが、チームでは「正式な監査や保護ルールの確認は GitHub」「エージェントへの追加指示と一次レビューは Cursor」のように、どの場で何を確定するかを決めておくと混乱を減らせます。GitHub が正であるという製品の前提に、チームの確認手順を重ねる考え方です。
注意
Origin を導入しても、GitHub 由来のリポジトリの正は GitHub から移りません。 「Cursor から操作できる」と「GitHub を廃止できる」を同じ意味にしないでください。
4. 連携アプリ：Vercel・Depot・Buildkite
Origin の発表で挙げられた連携アプリは、現時点で Vercel、Depot、Buildkite の 3 つです。Vercel は preview deployment を提供します。Depot と Buildkite を含む連携から、既存の GitHub Actions workflow を実行できます。Buildkite はネイティブのパイプラインにも対応します。
| 連携アプリ | 公式発表で確認できる内容 | 導入時に確認したい運用（提案） |
|---|---|---|
| Vercel | preview deployment を提供 | 誰が preview を確認し、どの時点で承認するか |
| Depot | 既存の GitHub Actions workflow を実行 | 既存 CI と Origin 側の実行結果をどこで確認するか |
| Buildkite | GitHub Actions workflow とネイティブ pipeline に対応 | 2 種類の経路を併用する場合の責任範囲 |
表の右列は公式の製品仕様ではなく、導入時の運用提案です。発表に書かれているのは連携の存在と上記の対応範囲までで、権限設定、失敗時の通知先、承認フローの詳細は今回の抜粋にありません。
既存の GitHub Actions を実行できる点は、GitHub が source of truth のままという説明とも整合します。Origin を使い始めるために、既存 CI を一度に別の仕組みへ移す必要がある、と公式発表からは読めません。まず既存 workflow を保ったまま Cursor 側の作業面を試す、という段階的な導入が可能です。
5. クラウドエージェントのイベント駆動化
Origin がコードと PR の面を整える一方、8 月 19 日の更新は、クラウドエージェントが「人に呼ばれたときだけ動く」状態から一歩進むための部品を追加しました。Subscriptions が変化を捉え、/goal が継続する目的を与え、隔離 VM のサブエージェントが作業を分け、Steering が実行中の方向修正を受け取ります。
Subscriptions：PR・Slack・時刻を契機にする
Subscriptions では、Cursor が PR を監視し、Slack スレッドを監視し、スケジュールされたタスクを実行できます。人が毎回プロンプトを入力するのではなく、監視対象の変化や時刻を仕事の入口にできるわけです。
ここで注意したいのは、公式 changelog が確認できる範囲です。「PR を監視できる」ことは書かれていますが、エージェントが作成した PR を自動購読する、CI 失敗を自動修正する、bot コメントへ自動対応する、とまでは今回の一次情報にありません。具体的な自動化を設計するときは、実際の設定画面で選べる契機と動作を確認してください。
/goal：単発の指示ではなく長期目標を渡す
/goal は、エージェントへ長期間維持する目的を与え、完了に至るまで取り組ませるコマンドです。通常のプロンプトが「この差分を直す」のような 1 回の依頼だとすれば、goal は「何を完了状態とするか」を継続的に保持させるためのものです。
運用上は、目標が長期間続くほど完了条件の曖昧さが効いてきます。これは公式仕様ではなく運用提案ですが、goal には成果物、確認方法、止めて人へ判断を戻す条件を含めると扱いやすくなります。目的だけを広く書くより、完了の判定材料をチーム側で用意する考え方です。
サブエージェント：隔離された VM とクリーンな文脈
サブエージェントは、それぞれ独自の VM で動けるようになりました。各サブエージェントには、クラウド環境内で隔離されたプロジェクトのコピーと、クリーンなコンテキストが与えられます。
この隔離は、複数の作業を分けるうえで重要です。同じ作業ディレクトリを複数プロセスが直接書き換える形とは異なり、各サブエージェントが自分のコピーを持ちます。ただし、どのように成果を統合するか、衝突をどう扱うかという詳細は今回の抜粋にありません。また、並列数に応じたリソース消費や料金も changelog では確認できません。根拠のない倍率を見積もりに使わず、契約画面と実測で確認してください。Cursor のコスト管理では、利用量を運用へ落とす基本的な考え方を整理しています。
Steering：作業を中断せず方向を調整する
Steering も改善されました。エージェントが作業している途中にメッセージを送っても、その作業を中断しません。追加メッセージは現在のアクションを途中で切るのではなく、次の tool call を待って届きます。
これは「即時割り込み」ではありません。今まさに実行中のアクションを止めるのではなく、次の境界で方向を調整する仕組みです。緊急停止が必要な操作と、次の手順から方針を変えたい追加指示は区別して扱う必要があります。
| 機能 | 担う役割 | 公式発表から確認できること | 過大解釈しないための境界 |
|---|---|---|---|
| Subscriptions | 契機 | PR・Slack スレッドの監視、scheduled task | 個別の自動修正動作までは記載なし |
/goal | 継続目的 | 完了に至るまで取り組む長期目標 | 完了条件の具体的な書式は記載なし |
| サブエージェント | 分担実行 | 独自 VM、隔離コピー、クリーンな context | リソース消費・料金の記載なし |
| Steering | 実行中の調整 | 次の tool call で follow-up を受け取る | 現在の action を即時停止するものではない |
チャットを起点にエージェントを動かす別の形は、GitHub Copilot の Slack・Teams 連携でも扱っています。Copilot の更新は人が会話内でメンションする入口、Cursor の Subscriptions はスレッド自体を監視対象にできる点が対照的です。ただし、両者の対応動作を一次情報以上に同一視しないでください。
6. 導入を考えるときの注意
Origin とイベント駆動の更新は、コード、レビュー、通知、実行を近づけます。そのぶん、早い段階で「製品が保証すること」と「自社が決めること」を分ける必要があります。
early beta として小さく試す
Origin は early beta です。2026 年 8 月 17 日から有料プランの全ユーザーへ順次提供されますが、一般提供済みの成熟機能と同じ前提で全リポジトリを一度に移す段階ではありません。
これは運用提案ですが、最初は影響範囲の小さいリポジトリで、次を確認するとよいでしょう。
- GitHub への push と Origin への反映が、チームの期待どおりに見えるか
- Cursor と GitHub の両方からコメントし、会話の同期を追えるか
- checks と preview deployment を誰がどこで確認するか
- Subscriptions の監視対象と、不要な反応を止める手順が明確か
- Steering で送った追加指示が、どの境界から反映されたか追えるか
上記は公式が定めた必須手順ではありません。early beta を評価するためのチェックリストです。
Enterprise は管理者がオプトアウトできる
提供対象は有料プランの全ユーザーですが、Enterprise 組織は管理者がオプトアウトできます。利用者の画面に見えない場合、段階的なロールアウトだけでなく、組織側の方針も確認対象です。
管理者に無断で迂回するのではなく、GitHub が正のまま維持されること、どの情報が Cursor 側へ同期されることを想定するか、外部アプリをどこまで接続するかを整理して合意を取ります。ここでの合意形成は運用提案ですが、管理者オプトアウト自体は公式発表にある製品仕様です。
自動化の前に責任の境界を決める
Subscriptions と /goal を組み合わせると、長く動く自動化を想像しやすくなります。しかし、誰が監視対象を登録し、出力を確認し、止めるかは changelog だけでは決まりません。
導入時には、少なくとも「契機の所有者」「goal の完了を確認する人」「PR をマージする人」「想定外の動作を止める人」を決めることを勧めます。これは製品仕様ではなく、チーム向けの運用提案です。クラウド上の複数エージェントを可視化して扱う考え方は、Orca エージェント IDE ガイドも比較材料になります。
Cursor を含む AI 開発ツールの導入範囲、権限、レビュー体制を整理したい場合は、AI 開発ツール導入支援で運用設計から伴走しています。自社の GitHub 運用を保ったままどこから試すべきか迷っている方は、お問い合わせからご相談ください。
7. まとめ
Origin は Cursor のコードホスティングですが、GitHub から始めたリポジトリでは GitHub を置き換えません。push は引き続き GitHub に送られ、GitHub が source of truth のままです。そのうえで、リポジトリはリアルタイムに同期され、コメント、リアクション、返信も両方向に反映されます。Cursor 内の PR 画面では timeline、commits、checks、files changed を確認し、レビューからマージまで進められます。
同時期に追加された Subscriptions、/goal、隔離 VM のサブエージェント、Steering は、PR・Slack・時刻などを入口に、長期目標へ向かうエージェントを動かすための部品です。ただし、自動修正の具体的な動作、リソース消費、料金など、今回の changelog にない内容まで補ってはいけません。
導入の現実的な第一歩は、GitHub を正とする既存運用を保ち、影響の小さいリポジトリで同期、レビュー、外部連携、イベント監視を確かめることです。Origin は early beta であり、Enterprise では管理者がオプトアウトできます。製品仕様とチームの運用提案を分けて評価すれば、「GitHub から移るか」という二択ではなく、「GitHub を正としたまま、Cursor 側にどの作業を寄せるか」という具体的な判断に変えられます。