前編ではOriginが何か、どうセットアップするかを書きました。後編は、載せてみて引っかかったところです。いちばん大きいのはPull Requestの内部モデルで、単位がchange（版付きの差分）になっていること。あとはremote名の罠、Settingsの中身、CIとレビューの組み立て。実際にリファクタリングのchangeを1本流した記録と、この方向性を自分がどう見ているかも残します。
前編はこちら: https://qiita.com/Kinopee/items/639d401573c09ab24667
確認した時点のCLIは 2026.08.15-22-58-04-922a05a です。確認の直後、2026年8月17日にOriginは初期ベータとして正式リリースされ、公式ドキュメントも公開されました。変化が速い時期なので、細部は手元でも確かめてください。
違いはGitではなく、差分の単位にある
GitHubの基本単位は、ブランチにコミットが積もったPull Requestです。Originの基本単位はchange（版付きの差分）で、CLIもその言葉で揃っています。
origin pr create は、作った瞬間にheadとbaseのSHAを取って最初のversionにします。あとの更新はコミットが載るだけではなく、origin pr refresh がSHAを取り直して新しいversion snapshotを切ります。同じなら書き込みません。レビューは --change-version で「どの版を見たか」を固定できます。
エージェントが短時間に何度も直すと、GitHubではPull Requestが動き続けます。Originは「いまレビューしている版」と「最新版」を分けられます。公式コピー "a git forge for the agentic era" のいちばん具体的な実装は、ここです。
origin pr create のbaseの既定は、--stack-on の親のheadです。依存する小さなchangeを積む前提が、コマンドに埋まっています。エージェントが並行して枝を出すなら、巨大な1本より、層に分けて下からマージする方が合います。Graphite由来のstacked diffsが、そのままOriginのPull Requestモデルです。
新規changeの既定はdraftです。GitHubはopenが普通です。origin pr ready でレビュー可能にし、--undo でdraftに戻せます。試行を大量に切るなら、最初からレビュー待ちにしない方が自然です。
人が画面を開かなくても回せるように、origin pr / origin api / origin pr checks --watch / origin pr merge --auto が先に揃っています。条件を満たしたら人がボタンを押さなくてもマージできます。CIは本体に無く、Appsに出しています。ホストは差分とマージに集中し、実行は外のAPI前提です。
全部揃っているわけではありません。origin pr review --request-changes は、ヘルプに not supported by Origin yet とあります。IssueやGitHub Actions相当の実行基盤も、ホスト側にはありません。GitHubでもGraphiteやauto-mergeで近いことはできます。Originはそれが既定のモデルです。
既存リポジトリを載せるときの落とし穴
Originの空リポジトリ画面は、次のように案内します。
git init -b main
git remote add origin https://origin.cursor.com/owner/repo
git add .
git commit -m "Initial commit"
git push -u origin main
これは新規プロジェクト向けの手順です。すでにGitHubを origin にしているリポジトリでは、git remote add origin ... が error: remote origin already exists で止まります。ここで git remote set-url origin ... に書き換えてしまうと、普段のpush先がGitHubからOriginへ変わります。自分はGitHubの origin をそのまま残し、Origin用に別名で cursor を足しました。
git remote add cursor https://origin.cursor.com/owner/repo.git
git push cursor main
git push -u cursor main とすると、ローカル main の追跡先が cursor/main に切り替わります。普段の git push / git pull をGitHubのままにしたいなら、追跡先は戻した方が安全です。
git branch --set-upstream-to=origin/main main
もうひとつ、origin pr はリポジトリをgitの origin remoteから推測します。remote名が origin のままGitHubを指していると、OriginのPull Requestを扱うつもりがGitHub側を見にいきます。Origin向けにはリポジトリとremoteを明示します。
origin pr create -R owner/repo --remote cursor
日常のpushも、行き先を明示する形になります。
git push origin main # GitHub
git push cursor main # Origin
Gitで運ぶのはコミットとブランチとタグだけです。この方法では、GitHub側のIssueやPull Requestの議論は来ません。正式リリースで入ったGitHubミラーリングを使うと、同期済みリポジトリではPRが双方向に同期されます（Cursorでのコメントが GitHubへ投稿され、GitHub側の返信も数秒でCursorに出ます）。それでもIssueとGitHub Actionsのワークフロー・シークレットは同期対象外です。また、ミラーリングはGitHubを正本のままにして閲覧とレビューをCursorへ広げる機能で、pushもGitHubを経由します。この記事の「Cursorホストのリポジトリへ別remoteでpushする」形とは役割が違います。
画面は3タブ
Web UIは Code、Pull Requests、Settings です。Settingsの中は、試した時点では General、Apps、Rules and Protections でした。リリース後の公式ドキュメントでは、これに権限（Permissions）を加えた4項目になっていて、権限とルールと保護のUIは再設計中と明記されています。権限タブでは、リポジトリの公開範囲（Internal / Private）とアクセスできるメンバーを管理します。いずれにせよ、GitHubより項目は少ないです。
少ないのはホスト側の機能です。代わりに、Cursor標準機能への入口が埋め込まれています。Codeタブの上部にはファイル検索と並んで + Automation ボタンがあり、CursorのAutomations（定期実行やトリガーでエージェントにプロンプトを実行させる機能）を、このリポジトリを対象にその場で作れます。画面のあちこちに出る Ask Cursor（⌘I）は、見ているコードやdiffについてその場でエージェントに質問する入口です。IssueやActionsが無い代わりに、エージェントの起動面がホストへ直接生えている、と読んだ方がしっくりきます。
Generalで触れるのは、デフォルトブランチ、マージ後にheadブランチを消すかどうか、リポジトリ削除です。Danger Zoneの文言は "Removes this repository from Cursor for your team" で、チーム空間のリポジトリという前提が見えます。
AppsはGitHub Actionsの代わりではない
Origin本体に、GitHub Actions相当の実行基盤はありません。Appsは、外のCIやデプロイをOriginに繋ぐ場所です。GitHubのApps / 連携に近い層です。
Internalの + New は、自分用の連携（Webhookや社内ツール）を作る入口です。Suggestedに出ていたのは次の3つでした。
CI用はBuildkiteとDepotです。リリース文によると、どちらも既存のGitHub Actionsワークフローを実行でき、Buildkiteはネイティブパイプラインも書けます。.github/workflows のYAML資産を持ち込めるので、CIの書き直しは必須ではありません。ひとつ制約があり、DepotとBuildkiteが使えるのはOriginでホストされているリポジトリだけです。GitHubからミラーリングしたリポジトリでは使えず、CIはGitHub側で実行します。
VercelはPRごとのプレビューデプロイと、マージ時の本番デプロイです。Webアプリ向けで、デスクトップアプリのリポジトリなら入れる理由はありません。
Installで権限を渡し、Viewで説明を見ます。試した時点ではApps用のドキュメントがほぼ見つかりませんでしたが、正式リリースで公式の説明が出ました。GitHubを正本にして、CIもGitHub Actionsのままなら、Appsは空で問題ありません。
Rules and ProtectionsはGitHubのRulesets
マージ方法と、ブランチ保護（ruleset）が同じ画面にあります。
上段はマージの形です。Allow merge commits は履歴を残してマージコミットを作り、Allow squash merging はブランチのコミットを1つにまとめて入れます。両方オンでも、片方だけ残しても構いません。
下段のrulesetが、GitHubでいうRulesets / Branch protectionです。「どのブランチに、いつ、何を満たさないと拒否するか」を決めます。違反するとmergeやpushが止まります。CLIでは一覧と詳細の参照だけできて、作成と編集はWeb画面です。
origin ruleset list -R owner/repo
New rulesetを開くと、適用タイミングが2つあります。MergingはPull Requestをマージするとき、Pushingはブランチへ直接pushするときです。force-pushや削除の制限は、Pushing側で別rulesetを作る形です。
対象ブランチは Default branch、All branches、Custom です。Default branchは、そのリポジトリのデフォルト（自分の場合は main）だけです。All branchesにすると、作業ブランチまでレビュー必須になります。Customは releases/* のようなパターンで、パターンを1つ以上Addしないと作成できません。名前を "Protect default branch" にするなら、対象はDefault branchにします。
マージ前に要求できる条件は、承認の件数、CODEOWNERS の所有者承認、指定したCIの成功、対象ブランチの最新取り込みです。CIの繋ぎ方は次の節で書きます。
EnforcementのActiveはすぐ拒否し、Disabledは保存だけして効かせません。下書きに使えます。
PRごとのチェックはAppsとrulesetで組む
GitHubの「PRにchecksが並び、通らないとマージできない」に相当する仕組みは、Originでは部品を組み合わせて作ります。流れは4段で、AppsでCIを繋ぎ、結果がchangeのchecksに載り、rulesetで必須化し、マージはmerge-when-readyに任せる、です。
CIの供給源はAppsです。既存のGitHub Actions YAMLはDepotでもBuildkiteでも動かせて、Buildkiteはネイティブパイプラインも書けます。結果はCLIから見えます。
origin pr checks -R owner/repo # CI状況
origin pr checks --watch # 終わるまで待つ
origin pr view --checks # マージ可否とCIサマリ
必須化はrulesetの「Require status checks to pass」です。UIの文言が "Selected checks must pass" なので、一度CIが報告してからでないと、選ぶ対象が出ないはずです。順番は、Appsを入れる、pushして1回流す、rulesetでcheckを選ぶ、になります。「Require branch to be up to date」も併せると、古いbaseで通ったCIをすり抜けさせません。
レビューは「Require approving reviews」で承認数を縛ります。マージを --auto にしておくと、checksと承認が揃った時点で入ります。日常のループはこうなります。
git checkout -b feat/x
git push cursor feat/x
origin pr create -R owner/repo --remote cursor --fill
origin pr ready # draftをレビュー可能に
origin pr checks --watch
origin pr merge --auto # 条件が揃ったらマージ
GitHubと感覚が違うのは、修正要求（request changes）がまだ無いことです。指摘は origin pr thread（list / reply / resolve / reopen）で残して解決状態を管理し、承認しないことでマージを止める運用になります。
注意は二つ。一人運用のリポジトリで「承認1件必須」にすると、自己承認できるかどうか（未確認）でマージ不能になるおそれがあります。GitHubが正本でCIもGitHub Actionsのままなら、Origin側にchecksを組むと同じCIを二重に流すことになります。Origin上でchangeを回し始めるまでは、組まなくてよいと思っています。
組む順番にも一つだけこだわりがあります。Vercelのように本番デプロイ権限を持つAppを繋ぐなら、承認必須のrulesetを先に作ってからにします。merge-when-readyとデプロイ連携が揃った構成では、マージがそのまま本番反映になり、途中に人間の判断が残る場所はrulesetだけだからです。rulesetが空のままAppを入れると、誰も途中で止めない経路がその瞬間に成立します。
Appsは未導入なので、checksがどんな名前で載るか、draft中もCIが走るかは確認していません。導入したら最初の1本で確かめてください。
実際にchangeを1本流してみた
机上の理解で終わらせないために、このリポジトリで実際にリファクタリングを1件やり、OriginへPull Requestを出しました。題材は、本体最大のファイル（727行）から、セッションのライフサイクルと無関係な純粋テキスト処理を別の型へ切り出すリファクタリングです。挙動は変えず、ローカルで306件のテストが通ることを確認してから進めました。
手順はGitHubとほぼ同じで、違和感はありません。ブランチを切ってコミットし、git push cursor <branch>（1.6秒）でOriginへ送り、origin pr create（3.1秒）でPull Requestにしました。作成の応答に、前の節で書いたモデルの違いがそのまま出ます。
Created pull request #1 in kinopee/interpreter-openai.
Status: draft
Version #1: cdbb87d... <- 6affc8d...
宣言どおり既定はdraftで、作成した瞬間にversion 1としてheadとbaseのSHAが刻まれました。ここから、事前の理解を裏付けたり裏切ったりする挙動が3つありました。
1つ目はversionの切られ方です。同一SHAのまま origin pr refresh しても版は増えません（unchanged; latest version remains #1、と返ります）。ここまではドキュメントどおりですが、その後テストを1件足してpushしたら、refreshを呼ぶ前にversion 2ができていました。pushをサーバー側が検知して自動でsnapshotしています。エージェントがrefreshを呼び忘れても版の履歴が壊れない設計で、versionは「手で管理するもの」ではなく「勝手に積もるもの」でした。
Versions:
#1 cdbb87defbf5 ← 6affc8d542b4
* #2 ced866f66504 ← 6affc8d542b4
2つ目はdraftの強さです。rulesetをひとつも作っていないのに、origin pr view --checks は Mergeable: no を返し、blockerは change-is-draft でした。「作った瞬間のchangeはマージ対象ではない」が、設定ではなくモデル側で強制されています。
3つ目はその裏返しです。origin pr ready でdraftを外した瞬間、Mergeable: yes になりました。checksは1件も報告されていないのに CI passing: yes です。何も無ければ通過扱い、という判定なので、素のOriginはready後のマージを何も止めません。前の節で書いた「本番につながるAppを入れる前にrulesetを組む」は、この挙動を見て確信に変わりました。
細かい罠もひとつ拾いました。--remote cursor は pr create だけのオプションで、refresh や view には無く、Unknown argument で弾かれます。remote名を origin 以外にしている場合、以降のコマンドは -R owner/repo で毎回リポジトリを明示することになります。
Changes画面は素のdiffではなくCode Tourで開く
Webでこの changeを開いて、いちばん驚いたのがChangesタブです。素の差分の前に、Code Tourという自動生成の解説が付いていました。変更の概要（Overview）、レビューで確認すべき点（Review focuses）、そして差分を「切り出した型」「セッション側の統合」「テスト」という意味のまとまりで並べ直したセクションが続きます。ファイル順ではなく、理解する順にdiffを歩かせる構成です（画像はChromeの翻訳機能で日本語にしてあります。
内容の正確さも確認しました。「macOSのみのリファクタで挙動は不変、定数は maxLength へ改名、Windows側の同等ロジックには触れていない」という要約は、PR本文と差分の両方を読まないと出てきません。en-esは語窓、他は末尾非空白scalar窓で切り詰める、という実装の要点まで拾っていました。Review focusesには「移動が純粋な引っ越しであること」「2箇所の呼び出しが新しい型を呼ぶこと」「テストはリネーム中心で、新規は空白のみのエッジケース1件」と書かれていて、レビュアーが最初の5分でやることが画面に出ている状態です。ファイルごとの既読管理（Files Viewed）やAsk Cursorボタンもあり、レビューを人間が最後まで読み切る前提のUIになっています。
GitHubにもCopilotのPR要約はあります。あちらは後付けの機能です。OriginはChangesタブの既定の開き方がこれで、エージェントがPRを量産すると人間の注意が希少資源になる、だからdiffを人間の読める形へ圧縮するのはホストの仕事だ、という設計思想がそのまま画面になっています。version snapshotがレビュー対象を静止させ、Code Tourが読み方を案内する。どちらも同じ「人間のレビュー帯域」への投資です。
ひとつ警戒も書いておきます。エージェントが書いたコードをAIが解説する構図なので、tourだけ読んで差分を読まないレビューが起こり得ます。要約はもっともらしく間違えることがあるので、tourは索引として使い、承認の根拠は差分そのものに置くべきです。
流してみた実感
全体の所要は、pushからPull Request作成まで数秒。version snapshotとdraft制御とCode Tourは、何も設定せずに動きました。gh に慣れていれば学習コストはほぼ無く、違いはツールの操作ではなく、モデルとレビュー画面が後ろで勝手に正しく動くところに出ます。流してみた実感は、そこにあります。
エージェント前提という設計をどう見るか
ここまで書いた違いを、自分がどう受け取ったかも残しておきます。
changeの節で見た設計は、ばらばらの機能に見えて、全部同じ問題への対策です。エージェントの開発ループは修正の頻度が高く、人間のレビューが追いつきません。GitHubのPull Requestだと「レビューしている間にdiffが変わる」が常態化して、レビューが動く標的を追いかける形になります。
Originはversionでレビュー対象を静止させ、draft既定でレビュー待ちの列を守り、stackで巨大な1本への合流を避け、Code Tourでdiffの読み方を先に用意し、merge-when-readyで人がボタンを押す工程を外しました。ボトルネックになる人間のレビュー帯域へ、複数の角度から同時に投資しています。エージェント時代のレビューはこうあるべき、という答えとして筋がいいと思います。特にversion snapshotは、レビューを動き続けるブランチから切り離した点で、いちばん効いている発明です。
GitHubでも近いことはできます。gh とauto-mergeとmerge queueを組み、レビューにGraphiteを載せれば、大部分は再現できます。Originの差は「それが既定であること」で、既定の力は大きいものの、単体では乗り換えの理由として弱いです。「エージェント数十本の同時負荷に耐える」という肝心の部分も、公表されているのはデモの域で、自分では検証できていません。request changesが未実装のように、レビューのプリミティブ自体まだ欠けています。リリース文自身も、今日の初期ベータに入っているのは基本機能で、エージェントネイティブな機能は「まもなく」だとしています。CIが本体になくApps頼みなのも、エージェントループの要（CI失敗、修正、再実行）が外部依存だということです。
象徴的な反応も見かけました。Cursorコミュニティの中で、OriginにVercel Appを入れて本番デプロイまで通し、デプロイの鍵をOriginに預けて回すのが勝ち筋だ、と楽しげに報告している人がいました。changeを作り、checksが通り、origin pr merge --auto でマージされ、Vercelが本番へ出す。人間がどのボタンも押さずにコードが本番へ届く経路は、もう動いています。注目したいのは、鍵がOriginに集まることを、コミュニティ側が警戒ではなく強みとして語っている点です。Appsを入れるとは、Cursorに外部サービスの鍵を預けることなので、これは裏返せばそのまま信頼の問いになります。
これは私見ですが、本当の差別化はchangeモデルそのものより、エージェントを一級の主体として扱う権限と監査に出ると思っています。Appの権限を本番とpreviewで絞れるか、本番デプロイの手前に人間の承認を挟めるか、どのエージェントの操作が引き金だったかを追えるか。GitHubはここが人間アカウント前提で、botは接ぎ木です。Cursorはエディタ、エージェント、レビュー（Bugbot）、ホストまで縦に持っているので、鍵を預かる側の作り込みができればGitHubに無いものになります。ただ、今回見た画面とCLIには、その部分はまだ現れていません。
並行エージェントが数本なら、GitHubと工夫で足ります。数十本を常時回すようになって初めて、この構造の差が効いてきます。changeモデルはその入口で、方向は正しいが証明はこれから。触ったあとの正直な感想は、そこにあります。
どこから使い始めるか
自分の順番は決めてあります。まずremoteを足して控えにする。Origin上でchangeを回したくなったらDepotを入れて1回流す。rulesetにstatus checksと承認を足す。以後は origin pr merge --auto に任せる。ここまでやって初めて、GitHubと同じ「チェックが通らないとマージできない」状態になります。
正本をGitHubからOriginへ移す判断は、稼働実績とAppsの安定を見てからで遅くありません。
前編はこちら: https://qiita.com/Kinopee/items/639d401573c09ab24667