変更を確認し、反映を決める

Pull Request は提案書

Pull Request（よく PR と略します）は、「この変更を本番の流れに入れてよいですか？」という提案です。Agent が作業を終えると、この提案の形で返ってくることが多くあります。

まだマージしていなければ、main ブランチ（本番に近い本線）は変わっていません。安心して中身を読めます。

Origin 上で作った保管庫の PR は cursor.com/codebase の Pull Requests タブです。公式の画面は Activity（会話と状態）/ Commits / Checks / Files Changed の4つで、GitHub と同じ順で読めます。枝を Origin に送ったあと、保管庫の Code タブからも PR を開けます。GitHub から同期した保管庫なら、Cursor 上に出るのは GitHub の PR です。同期保管庫の origin/ で始まる枝は Origin 側だけに残り、GitHub の PR の先頭にはなりません（公式 Origin pull requests）。

Origin CLI で作る PR は既定が Draft です。確認できたら Ready にしてください。画面からも、Agent に『Ready にして』と頼んでもできます（公式 Origin CLI PR）。

Checks タブは先頭コミット向けです。push したのに古い結果のままなら、Agent に『PR を refresh して』と頼むか origin pr refresh です。通常は push で新しい版が作られるので、画面が追いついていないときだけ使います（公式 Origin CLI PR）。

はじめての方が見るチェックリスト

コードが読めなくても、次の点は確認できます。

• 意図した画面・文言だけが変わっているか
• 関係ないファイルまで大量に触っていないか
• 秘密情報（鍵、パスワード、個人情報）が入っていないか
• Agent の説明と、実際の差分の内容が一致しているか
• 『なぜこの変更が入ったか』が分からなければ `/cursor-blame`（AI の変更と依頼文を調べる。公式 Agent Skills）
• マージや push の前に先に読んでもらいたいなら `/review`（合うレビュー Agent を選ぶ。明示するなら `/review-bugbot` / `/review-security`。同じ差分のまま PR を出すと保管庫側は再実行を飛ばすことがある。Cursor 3.7+ / cursor.com/agents。CLI は公式では準備中）
• Desktop で手元の変更だけ先に読むなら `/agent-review`（Agent Review。PR の Bugbot とは別。設定は Agents、Cursor 3.11 以降は Git & PRs。when-desktop）
• 成果物（スクショ・動画・ログ）やプレビューがあれば、見た目と手順で確認する
• 本線より遅れている（behind）表示が出ていないか → 出ていたら Update branch で取り込んでから判断（pull-request-deep の behind 節）
• コンフリクト（競合）と表示されていないか → 出ていたら Agent に『main の最新を取り込んでコンフリクトを解消して』と依頼（自分で直すより安全なことが多い）
• 成果物が無い／『確認できなかった』と書かれている → 仕事場（環境）不足のサインかもしれない（第4章）

コピペ用：PR 確認メモ

確認のたびにゼロから考えなくて大丈夫です。次の型をメモや PR コメントに貼り、カッコ内だけ埋めてみてください。

• 意図どおり: （はい / いいえ）。ずれている点: （）
• 触ってほしくない範囲は無事か: （はい / 要確認）
• 秘密情報・個人情報が写っていないか: （はい / 怪しい）
• 成果物 or プレビューで見たこと: （）
• behind / コンフリクト: （なし / Update branch 済 / Agent に解消依頼）
• 次の一手: （マージ / 追加指示 / 人に相談）

成果物とリモートデスクトップ

Cloud Agent は、マージしやすい PR に加えて、デモ用の成果物（artifacts）としてスクリーンショット、動画、ログを残せます。公式では成果物は PR に紐づけられ、手元にブランチを落とさなくても検証しやすくなります。文言や見た目の確認なら、差分より先に成果物を見る方が早いことが多いです。

成果物がアップロードされると、ダッシュボードの実行イベントに `artifact_created` と出ます（environments-and-secrets の実行イベント節）。イベントが無いのに『確認した』と書かれているときは、環境不足やネットワーク制限を疑いましょう。

GitHub の PR 説明文に画像を自動で埋め込みたいときは、別設定の Allow posting artifacts to GitHub が必要です（このレッスン後半の成果物を PR 本文に載せる設定節）。Agent 画面や PR に紐づく成果物は見えているのに、GitHub 本文だけ空、というときはここを疑います。

Agent が動いているクラウド上のデスクトップを一時的に操作して、自分で画面を触って試す機能（remote desktop control）もあります。手元にブランチを落とさなくても、『動いたか』を体感で確かめられます。試し終わったら操作を返し、Agent に続きを任せます。

反映のしかた

問題なければ Merge（反映）します。チームによっては Approve（承認）が先に必要なこともあります。だめなら Close したり、追加コメントで Agent に修正させたりします。

スマホの Cursor アプリからも、差分確認やマージ操作が行えます。通勤中に確認し、大きな判断だけデスクで行う、といった使い方が現実的です。

auto-merge と Subscriptions の使い分け

PR を出したあと、毎回『CI が緑になったら続けて』と書く代わりに、道具を組み合わせられます。混同しやすいので、役割だけ先に固定しましょう。

• `/autopilot`（最初から入っている Skill）: 開いた PR の指摘・コンフリクト・赤い Checks・残り仕事を見守って直す。マージまで任せたいときの最短入口（公式 Agent Skills）
• auto-merge（GitHub / スマホ）: あなたがオンにすると、Checks・承認・behind なし・コンフリクトなしなどの条件が揃ったタイミングで自動反映される。Agent は動かない。Origin 上の PR では同じ役割が『条件が揃ったらマージ』（origin pr merge --auto / Agent に『条件が揃ったらマージして』）
• Subscriptions（Agent）: レビューコメント・CI 結果・Slack 返信などを待って、同じ会話で Agent が自動再開し、直し続けられる。公式例: open a PR and keep it green until merge。GitHub の CI 待ちは Checks が全部終わるまで1つの結果で、pending の Check が1つでも全体が届かない。公式は action_required（要対応）で完了させる（follow-up-loop）
• `@cursor autofix`（Agent 作成 PR）: GitHub Actions の失敗だけを自動追従する別機能。Subscriptions より狭い範囲

マージまで任せるレシピ（/autopilot と3道具）

道具は別物ですが、組み合わせると『PR を出してからマージまで』をほぼ任せられます。いちばん簡単な入口は `/autopilot` です。

• ① いちばん簡単: チャットで `/autopilot`。開いた PR の指摘・コンフリクト・Checks を見守って直す（公式 Agent Skills）
• ② 起動時: この PR だけを待つ Subscriptions 付きで依頼（上のコピペ用、または `/subscribe`）。保管庫全体の待ちは通知が多くなりやすいので、マージ任せでは②は1 PR に絞る
• ③ PR 作成後: GitHub またはスマホで auto-merge をオン
• ④ 必要なときだけ: Agent 作成 PR で CI が赤いとき `@cursor autofix on`（Teams）

マージボタンがグレーのとき

Merge（反映）ボタンが押せない・グレー表示のときは、だいたい次のどれかです。Checks が赤、behind 表示、コンフリクト、必須レビュー未承認、ブランチ保護ルール、あなたにマージ権限がない。

このレッスン冒頭の図は、6つの原因を一覧にしたものです。Checks が緑でも、④⑤⑥（承認・保護・権限）で止まることがよくあります。auto-merge をオンにしても、条件が揃うまで反映は始まりません。

behind なら Update branch（pull-request-deep の behind 節）。コンフリクトなら Agent に解消依頼。CI 赤なら pull-request-deep の CI 3択図どおり。承認が足りないときはレビュアーを足すか、詳しい人に相談しましょう。Origin 上の PR でもコンフリクトは画面に出ます（公式 Origin pull requests）。

公式の GitHub 連携では、Cursor アプリがブランチ保護や必須チェックのルールを読み、マージ可能かどうかを判断します。表示が想定と違うときは、カスタムリポジトリロールの影響も accounts-setup で確認できます。Origin 上で作った保管庫では、同じ役割が Settings の Rules and Protections（マージ時・push 時の ruleset）です。GitHub 同期の保管庫は GitHub 側のブランチ保護のままです（公式 Origin settings）。

CI が赤くなったとき（Agent 作成 PR）

Cloud Agent が作った PR では、GitHub Actions の失敗を Agent が自動で直しにいくことがあります（いまは Teams 向け。個人プランは追従予定）。

自動追従（autofix）が走らない典型例は、公式 capabilities では次のとおりです。

• 人が後から push した
• あなたが追加メッセージ（follow-up）を送った
• 同じ Check が取り込み先（base）でも既に赤い
• 同じ PR で CI 失敗の自動修正が10回に達した

コミットの Verified（署名）

Cloud Agent が付けたコミットには、Cursor 側の署名が自動で付きます。GitHub / GitLab では Verified バッジとして見えます。はじめて見ると『誰かが特別な鍵を入れた？』と不安になることがありますが、正規の Cloud Agent 実行なら想定どおりです。

チームがブランチ保護で『署名付きコミット必須』にしていても、Agent の PR はそのまま条件を満たせます。追加の設定は不要です。

成果物を PR 本文に載せる設定

スクショなどの成果物は Agent 画面で見る以外に、GitHub の PR 説明文へ埋め込む設定もあります（Cloud Agents ダッシュボードの Allow posting artifacts to GitHub）。レビュー担当が GitHub だけ見て判断するチーム向けです。

埋め込まれた画像は、長い推測しにくい URL の公開リンクになります（GitHub の画像表示の仕組み上、認証なしで見られる形です）。画面に秘密情報や個人情報を映していないか、埋め込み前にもう一度確認しましょう。