体験が先、用語はあとで大丈夫。
4章で一周から仕組みへ。

困ったときの索引

うまくいかない症状から、戻るとよいレッスンを選べます。サイト内検索ならレッスン見出しまで横断できます（例:Builds、Subscriptions、auto-merge）。

一致する症状がありませんでした。サイト内検索か用語集、最初のレッスンから探してみてください。

• Agent がリポジトリに入れない→ GitHub の接続や権限が足りないことが多いです。まだ GitHub が無いなら Origin / Start from scratch の道もあります該当の節へ
• PR 作成だけ Permission denied と出る→ Cursor GitHub アプリの Pull Request への write 不足、ブランチ保護、または古いインストールの可能性があります。Integrations の再接続も試してください該当の節へ
• GitHub の設定に Cursor アプリが見えない→ Organization レベルで未インストールのことがあります。github.com/apps/cursor から入れ直すか、管理者に Organization インストールを依頼してください該当の節へ
• マージ後だけ Slack などに通知したい→ Automations の Pull request merged トリガーを使います。open / push トリガーと混同しやすいので、Draft と Ready の節を参照してください（フォーク PR でも merged は例外的に動くことがあります）該当の節へ
• diff 上のレビュー指摘なのに Automation が動かない→ GitHub では Comment added（PR 全体へのトップレベルコメント）と PR review comment（差分のインライン指摘）が別トリガーです。行コメント対応なら PR review comment を選んでください該当の節へ
• レビューの会話を解決したときだけ Automation を動かしたい→ 差分の行についてのスレッドを解決／未解決にしたタイミングは Review thread updated です。新しいインライン指摘そのものは PR review comment です該当の節へ
• GitHub Issue にラベルが付いたときだけ動かしたい→ Pull request label changed は PR 専用です。Issue 用は Issue label changed を選びます（PR ではないチケット向け）該当の節へ
• Approve / Request changes したときだけ Automation を動かしたい→ まとめてレビューを提出したタイミングは PR review submitted です。diff 上の行コメントだけなら PR review comment、会話欄への返信だけなら Comment added です該当の節へ
• Checks は緑だが CI 失敗の Automation が動かない→ GitHub では CI completed（Checks の完了）と Workflow run completed（Actions ワークフロー実行の完了）が別トリガーです。見ている失敗がどちらか確認し、Automations の Draft/Ready 節を参照してください該当の節へ
• GitHub Issue にコメントしたときだけ Automation を動かしたい→ PR 向けの Comment added ではなく Issue comment を選びます（PR ではないチケット向け）。Issue ラベルだけなら Issue label changed です該当の節へ
• Automation が毎回 PR を出してしまう→ Prompt に品質バー（いつ PR を開く／コメントだけ／何もしないか）が書けていないことが多いです。Automations の『はじめて向きの具体例』節を参照してください該当の節へ
• MCP 経由で想定外の操作がされた→ MCP は接続したサーバーの道具をすべて使えます。信頼できるサーバーだけ接続し、Prompt と Trigger の範囲を絞ってください該当の節へ
• Agent が docker compose や docker run で止まる→ Cloud Agent の VM はコンテナ内で動くため、複雑な Docker 構成では fuse-overlayfs や iptables-legacy などの追加設定が必要なことがあります。environments-and-secrets のネットワーク制限節を参照してください該当の節へ
• Tailscale で社内サービスには届くが exit node にならない→ Cloud Agent では Tailscale を userspace networking モードで使う公式例が多く、VM を tailnet の exit node にはできません。社内リソースへ届けば十分なことが多いです該当の節へ
• Remote Control が使えないと言われる→ Privacy Mode（Legacy）のまま、PC がスリープ中、クラウドデータ保存がオフ、または Teams / Enterprise で管理者が Dashboard → Cloud Agents → Self-Hosted で Remote Control を許可していない可能性があります。Remote SSH ワークスペースなら Git remote なしでも使えます（when-desktop の Remote Control 節）該当の節へ
• Move to Cloud と Remote Control のどちらを使えばいいか分からない→ Move to Cloud は手元の作業をクラウド VM へ移す操作。Remote Control は会話の指揮だけクラウドへ移し、ファイル編集やテストは手元 PC で動かし続けます。when-desktop の Move to Cloud とのちがい節を参照してください該当の節へ
• Agent に Cursor Cloud MCP の道具が無い / 調べられない→ チーム管理者が Dashboard の MCP 設定で組み込みの Cursor Cloud MCP を無効にしていることがあります。詳しい人に有効化を依頼するか、実行 URL と症状を伝えて手動で調査してください該当の節へ
• GitLab で MR が Approved になったときだけ Automation を動かしたい→ GitHub の PR review submitted ではなく、GitLab の Pull request approved（マージリクエスト承認）トリガーを選びます（automations の GitLab / Bitbucket 節）該当の節へ
• Bitbucket で PR が Approved になったときだけ Automation を動かしたい→ GitHub の PR review submitted ではなく、Bitbucket Cloud の Pull request approved トリガーを選びます（automations の GitLab / Bitbucket 節）該当の節へ
• 起動時に Cloud machine / Team Pool / My Machines のどれを選べばいいか分からない→ はじめては Cloud machine で問題ありません。手元 PC の未保存ファイルを触りたいときは My Machines か Desktop の Remote Control、社内ネットワーク内だけで動かしたいときは Team Pool を詳しい人と検討します（first-cloud-agent の実行先の選び方節）該当の節へ
• 会社の Lambda / Cloudflare / Daytona で Agent を動かしたい→ Cursor が用意する Cloud machine が本線です。Team Pool は Enterprise 前提で、会社がすでに使っているサンドボックス（AWS Lambda、Cloudflare、Daytona、Modal、Namespace、Vercel、E2B、Tensorlake、Coder）の上にも置けます。Kubernetes の新規は anysphere/k8s-workers。待たせたくないときは `--warm-idle`。使っていない作業場は休眠できます（when-desktop の Cloud だけでかなり行ける節）該当の節へ
• 自前ワーカーの画面を見せたいが、マウスは渡したくない→ Linux の `--share-desktop` は見るだけ（view）か、マウスとキーボードも渡す（view_and_control、既定）を選べます。共有されるのはワーカーが作った隔離デスクトップで、クリップボードは渡りません。macOS の `--share-desktop` はありません（when-desktop の Cloud だけでかなり行ける節。公式 computer use）該当の節へ
• Mac の自前ワーカーでスクショが急に止まった→ macOS 15 以降は画面収録の許可を定期的に聞き直すことがあります。ログイン画面の『1か月許可』を確認し、Cursor Computer Use（Terminal や Cursor 本体ではない）にアクセシビリティと画面収録が付いているかも見てください（when-desktop の Cloud だけでかなり行ける節。公式 computer use）該当の節へ
• CLI で Skill を1通だけ使いたいのに、ずっと効いたままになる→ CLI の `/` メニューで Enter は今の1通に付けるだけ、⌥ Enter が Custom Mode（ピン留め）です。Desktop の ⌥ Enter / Use as Mode と同じピン留めです（prompting の /goal 節）該当の節へ
• Skill やプラグインをどこから入れればよいか分からない→ Desktop ならサイドバーの Customize がまとめて扱う画面です。プラグイン・Skill・MCP・サブエージェント・Rules・コマンド・Hooks を自分 / 作業場 / チームで絞れます。コミュニティは cursor.directory（rules-and-skills の Skill の作り方節）該当の節へ
• 依存リポジトリやサブモジュールで clone が止まる→ 作業対象の保管庫だけでなく、取り込んでいる別保管庫にも読み書き権限が必要です。GitHub なら Integrations の Manage Connections → Selected repositories に依存先が含まれているか、GitLab なら Manage → Sync Repos で依存先も同期されているか、管理者に確認してください（repository レッスンの依頼例テンプレあり）該当の節へ
• 個人用 Skill がモバイルで効かない→ リポジトリの `.cursor/skills/` に入っていない個人用 Skill は、Cursor に同期（synced）されていないとモバイル起動から使えません。同期されるのは `~/.cursor/skills/` だけです。`~/.agents/skills/` はコピーされません。Web で同期状態を確認するか、チーム共有ならリポジトリへ PR で入れてください該当の節へ
• Cloud Agent や My Machines で個人用 Skill が効かない→ `~/.agents/skills/` や未同期の手元 Skill は Cloud Agent・Remote SSH・自前ワーカーには届きません。同期は `~/.cursor/skills/` だけ。自前ワーカーならリポジトリの Skill か、イメージへの焼き込みです（公式 Agent Skills）該当の節へ
• Claude や Codex 向けに置いた Skill が Cursor で出ない→ Cursor は `.claude/skills/` と `.codex/skills/`（ホームの `~/.claude/skills/` なども含む）も読みます。出ないときはフォルダ名と SKILL.md を確認。Cloud Agent へ届く同期はこれまでどおり `~/.cursor/skills/` だけです（公式 Agent Skills）該当の節へ
• Teams で他社モデルの利用量が想定より多い→ Teams / Enterprise では他社モデルに Cursor Token Rate（100万トークンあたり $0.25）が API 料金の上に乗ります。Grok / Composer は対象外です。Auto が他社モデルへ振り分けたときも同じです（公式 Team Pricing）該当の節へ
• チームで Remote Control の設定が見つからない / 使えない→ Teams / Enterprise では管理者が Dashboard → Cloud Agents → Self-Hosted で Remote Control を有効にする必要があります。オンにするとチームの self-hosted worker 利用も一緒に有効になり、オフだとメンバーは Remote Control も手元セッションの引き継ぎもできません該当の節へ
• Agent が終わったのに気づかない→ iPhone ではターン終了のプッシュ通知と、Live Activities / Dynamic Island で最大8件まで追えます。通知が来ないときは OS の通知許可と Cursor アプリの通知設定を確認してください該当の節へ
• スマホでファイルを直接編集したい→ モバイルアプリは IDE ではなく、変更されたファイルの差分ビューが中心です。細かい編集は Agent への追記指示か、Desktop のファイルツリーで行います該当の節へ
• スマホに Rules や Automations の設定画面がない→ モバイルは司令塔と確認向けで、Automations / Rules / Skills の管理は Web（または Desktop）にあります。ただしリポジトリの `.cursor/rules` や AGENTS.md、`.cursor/skills` は Agent が読むので、Git に入っていればモバイル起動でも効きます。個人用 Skill も Cursor に同期済みなら使えます。rules-and-skills のモバイル節も参照してください該当の節へ
• 起動直後、まだファイルが変わらない→ 最初の数ターンは読み取り専用の探索になることがあります。書き込み可能な環境に切り替わってから本格的に直し始めます。agent-lifecycle の ACT 2 を参照してください該当の節へ
• Hooks が最初の数ターンだけ効かない→ Cloud Agent は読み取り専用の探索が終わり、書き込み可能な環境になってから Hooks が動き始めます。rules-and-skills の Hooks 節を参照してください該当の節へ
• 依頼があいまいで結果がブレる→ 完了条件や制約がまだ書けていないのかもしれません該当の節へ
• PR の意味が分からない→ 提案と反映のちがいがまだ曖昧なときです該当の節へ
• キーワードは分かったが、どのレッスンを読めばよいか分からない→ /search でレッスン見出し・用語・困ったとき索引を横断検索できます。結果が「見出し」なら、その節へ直接ジャンプします該当の節へ
• レッスン名は覚えていないが、見出しのキーワードだけ分かる→ /search?q=（キーワード）で見出し単位のヒットを探してください（例: Builds、Squash、autofix）該当の節へ
• いま自分が学習パスのどこにいるか分からない→ 学習地図（/learn）のロードマップで現在地が分かります。琥珀が次にやるレッスン、ティールが済です。済は完了ボタンか「次へ」で進んだときだけ付きます該当の節へ
• スクショや動画の見方が分からない→ 成果物（artifacts）の確認順を見直してみましょう該当の節へ
• Agent は完了したのにスクショや動画が無い→ 実行イベントに artifact_created が無いことが多いです。環境不足・ネットワーク制限・依頼に成果物の指定が無い、を疑い、environments-and-secrets の実行イベント節を参照してください該当の節へ
• ダッシュボードに artifact_created と出たのに PR に画像が無い→ 成果物は Agent 画面にはあるが、PR 本文への埋め込みは Allow posting artifacts to GitHub 設定が必要です。review-and-merge の成果物を PR 本文に載せる設定節を参照してください該当の節へ
• Agent は PR を出したと言うのに GitHub に PR が見えない→ 実行イベントに pr_created が無く pr_creation_failed があることが多いです。権限・ブランチ保護を確認し、差分が残っていれば手動 PR も検討してください該当の節へ
• setup_started のあと setup_completed が出ない→ まだ準備中か、直後に setup_failed になることが多いです。数分待ってからイベント一覧を再確認し、失敗なら Builds タブや setup ログを開いてください該当の節へ
• Builds タブに Skipped がたくさん並んでいる→ 公式では変更が無い定期チェック（Recurring）だけが Skipped として記録される正常な状態です。手動（Manual）や設定変更（Configuration change）は必ず install が走ります。main に新しいコミットや環境設定の変更があると Success の Recurring Build が走ります該当の節へ
• Secrets や環境設定を変えたのに Build が始まらない→ Configuration change として数分以内に Build が走ることが多いです。Builds タブで進行中か確認し、急ぎなら Trigger build で手動実行できます。Secrets 追加後は新しい Agent 実行を始める必要もあります該当の節へ
• Builds タブの Recurring / Configuration change の表示が分からない→ 公式の4種類のきっかけ（trigger）表示です。Skipped が出るのは Recurring（定期チェック）だけ。Manual・Configuration change・Agent-requested は必ず install が走ります該当の節へ
• 意図と違う変更が返ってくる→ 追加指示の書き方を少し整えると改善しやすいです該当の節へ
• テストやビルドが失敗する→ 実行環境や Secrets が足りないことがあります該当の節へ
• Automations がコードを直さない / PR を出さない→ リポジトリ範囲が未指定のことが多いです該当の節へ
• 毎回同じ説明を繰り返している→ Rules / Skills を整えると楽になります該当の節へ
• スマホアプリで Agent を起動できない→ Privacy Mode（Legacy）のままか、iOS 26+ / プラン要件を確認してみてください。Legacy から Privacy Mode へ切り替えたあと戻せない点も公式にあります該当の節へ
• iPad で差分やレビューが見づらい→ 横画面ではチャットとレビューを並べて開けるレイアウトがあります。初回起動レッスンの iPad 節を参照してください該当の節へ
• 外出先から手元 PC の作業を続けられない→ Remote Control 未設定か、PC がスリープしていることがあります該当の節へ
• Agent が外部 API やパッケージ取得で止まる→ ネットワーク制限（allowlist）や環境の通信設定を疑ってみましょう該当の節へ
• 同僚が自分の Agent に追記指示できない→ チームの follow-ups 設定か、相手のリポジトリ権限を確認してください該当の節へ
• 同僚が Agent の URL を開けない→ Agent は起動した Cursor チームのメンバーに見えますが、チームのメンバーであるだけでは開けません。相手が別チームのワークスペースを見ている、Integrations 未接続、リポジトリ権限不足のいずれかが多いです（Cursor は開いたときに閲覧者の GitHub 権限も確認します）該当の節へ
• GitHub はつながっているのに同僚の Agent が inbox に出ない→ 複数の Cursor チームにいるとき、Agent を起動したチームと相手が今見ているチームが違うことがあります。起動時のチームと相手のワークスペースが一致しているか確認してください該当の節へ
• GitHub 接続がおかしくなった / 再接続したい→ cursor.com/dashboard/integrations の Disconnect Account から切り離し、あらためて Connect してください。PR だけ Permission denied ならアプリ権限やブランチ保護も確認該当の節へ
• PR の Deployments（デプロイ）が分からない→ Checks の横に、プレビューや本番反映の状態が出ることがあります。pull-request-deep の PR タブの説明と、初回起動レッスンのモバイル節を参照してください該当の節へ
• CI が一時的な失敗で、再実行だけしたい→ GitHub の PR 画面から Actions / Checks を再実行できることがあります。Cursor GitHub アプリは PR から CI 再実行を扱う権限も持ちます。直しが必要なら `@cursor CI を直して` も使えます該当の節へ
• CI が赤いが、再実行・調査・修正のどれを選べばいいか分からない→ 一時的なら PR 画面から再実行、原因が分からなければ新しい Agent に調査だけ、直してほしければ Fix with Agent か `@cursor`。pull-request-deep の Checks 節の3択を参照してください該当の節へ
• PR が behind（本線より遅れている）と表示される→ 本線（main）に新しい変更が入ったあと、PR のブランチが古いままです。GitHub やスマホアプリの Update branch（ブランチ更新）で取り込むか、Agent に追記指示してください該当の節へ
• コンフリクト（競合）と表示されてマージできない→ 本線と PR の両方が同じ箇所を変えています。自分で直すより Agent に『main の最新を取り込んでコンフリクトを解消して』と頼む方が安全なことが多いです該当の節へ
• Update branch したら Checks がまた赤くなった→ 本線の最新を取り込んだあと、CI が再実行されて一時的に失敗することがあります。behind / コンフリクトが解消されていれば、pull-request-deep の3択図どおりに再実行・調査だけ・修正依頼を選んでください該当の節へ
• auto-merge / Subscriptions / autofix の違いが分からない→ auto-merge は GitHub の自動反映、Subscriptions は Agent がイベント待ちで再開、autofix は Agent 作成 PR の CI 自動修正です。開いた PR を見守る近道は `/autopilot`。review-and-merge の3道具の節で役割を確認してください該当の節へ
• auto-merge をオンにしたのにマージされない→ auto-merge は『条件が揃ったら自動反映』であり、Checks・承認・behind・コンフリクト・権限のどれかが未達のままです。3道具の節で auto-merge の役割を確認し、未達条件はマージブロック図を上から順に確認してください該当の節へ
• マージボタンが押せない / グレーになっている→ Checks が赤、behind 表示、コンフリクト、必須レビュー未承認、ブランチ保護、またはマージ権限がない可能性があります。review-and-merge のマージブロック図を上から順に確認。behind なら Update branch、コンフリクトなら Agent に解消依頼、CI 赤なら pull-request-deep の3択、承認不足ならレビュアーを足すか詳しい人へ該当の節へ
• Checks は緑なのにマージできない→ CI が通っていても、必須レビュー未承認・ブランチ保護・マージ権限不足で止まることがあります。review-and-merge のマージブロック図の④⑤⑥を確認してください該当の節へ
• マージや Approve のボタンが出ない / 選べない→ 会社の GitHub カスタムリポジトリロールやブランチ保護の影響かもしれません。Cursor アプリは custom repository roles を参照して表示を決めます。権限は管理者に確認してください該当の節へ
• レビューコメントを Agent に直してほしい（スマホでも）→ PR に `@cursor 未解決のレビューコメントを直して` と書くか、Cursor for iOS のレビュー画面から Agent に戻れます。follow-up-loop のレビューコメント節を参照してください該当の節へ
• PR 出したあと毎回『CI が緑になったら続けて』と書きたい→ Subscriptions（サブスクライブ）で、レビューや CI を待って Agent が自動で再開できます。依頼に『PR を出してレビューと CI が通るまで続けて』と書くか、`/subscribe` スキルを使います該当の節へ
• マージまで丸ごと任せたい（自分で毎回『続けて』と書きたくない）→ いちばん簡単な入口は `/autopilot` です。Subscriptions で直し続け、PR で auto-merge をオンにすると、条件が揃えば自動反映されます。review-and-merge のマージまで任せるレシピ節を参照してください該当の節へ
• レビューコメントが何件も来たのに Agent が1回しか動かなかった→ 公式の coalesce（まとめ起動）です。短い間に複数イベントが来ると1回にまとめられ、Agent は PR やスレッドを読み直してから動きます。follow-up-loop の Subscriptions 節を参照してください該当の節へ
• 保管庫全体を待たせたら Agent が動きすぎる→ GitHub の Subscriptions は1 PR・保管庫全体・特定作者の PR を選べます。マージまで任せるレシピでは1 PR 指定が安全です。保管庫全体は要約通知向けに使い分けましょう該当の節へ
• Agent が待たなくなった / 購読が切れた→ Subscriptions は最大180日で、条件が満たされたとき Agent 自身が解除することもあります。長期タスクは区切りを決めて新しい Agent を起動するか、依頼文に期限を書いてください該当の節へ
• ダッシュボードに mcp_auth_error と出た→ MCP サーバーの認証に失敗した公式イベントです。その MCP の道具だけスキップされ、実行自体は続きます。Integrations で再接続するか、起動時の MCP 選択を見直してください該当の節へ
• ダッシュボードに setup_failed と出た→ 環境のセットアップ（install / start など）が失敗した公式イベントです。setup ログや Builds タブの失敗 Build を確認し、環境設定を直してください該当の節へ
• Agent は動いたのに PR が無い / pr_creation_failed→ PR 作成に失敗した公式イベントです。GitHub 連携の PR 権限・ブランチ保護・対象ブランチを確認し、差分が残っていれば手動 PR か再依頼を検討してください該当の節へ
• Slack で質問して返信が来たら Agent に続けてほしい→ Subscriptions で Slack スレッドの返信を待てます。依頼文に待ち条件を書くか、`/subscribe` で『このスレッドの返信を待って続けて』と伝えます該当の節へ
• 外出先で赤い CI を調査させたい→ アプリや Web から新しい Agent を起動し、『失敗している CI を調査して（まだ直さない）』と頼めます。既存 PR なら Fix with Agent か `@cursor` も使えます該当の節へ
• 会社の SSO でモバイルアプリにログインできない→ 組織で SSO が必須の場合、iOS アプリでも SSO 経由でサインインします。会社アカウントの手順に従い、Privacy Mode（Legacy）からの切り替えも必要なことがあります該当の節へ
• Slack で @Cursor しても反応がない→ Slack 連携未設定、またはチャンネル既定リポジトリが無いことがあります該当の節へ
• Slack で別のリポジトリを触ってしまう→ チャンネル既定や Routing Rules と違う保管庫を触らせたいときは、メッセージで repo= かリポジトリ名を明示します該当の節へ
• 調べてほしかっただけなのに PR まで作られた→ Slack なら autopr=false、または依頼文に『コード変更はまだしない』と書くと防げます該当の節へ
• GitHub のコメントで Agent が動かない→ GitHub アプリ未接続か、メンションが @cursor になっていないことがあります該当の節へ
• Agent が起動直後に止まる / 利用できない→ 有料プラン（Start 以上）・選択モデルの API 料金（従量）に対する利用上限（spend limit）・Privacy Mode（Legacy）を疑ってみましょう。公式トラブルシュートでも有料プランが前提です該当の節へ
• 無料プランのまま Cloud Agent が使えない→ 公式では Cloud Agent は有料プラン（Start / Pro など）が必要です。プラン変更か、チーム管理者に利用可否を確認してください該当の節へ
• Start プランなのに Automations / Bugbot が使えない→ Start は Cloud Agent 自体は使えますが、Bugbot・Automations・Cursor SDK・Auto は含まれません。手動の Cloud Agent で一周を回し、Grok / Composer を直接選んでください。自動化と Auto は Pro 以上（公式 Models & Pricing。Start はインド向け）該当の節へ
• Start プランで Fast や努力レベルが選べない→ Start の Cursor Models 枠（Grok 4.6 / 4.5 / Composer 2.5）は高速モード（Fast）なし。Grok の努力レベルは medium 固定です。他社モデル枠（Other Models）もありません。変更は Pro 以上（公式 Models & Pricing）該当の節へ
• Start プランで Auto が選べない / 出ない→ Start には Auto が含まれません（Bugbot / Automations / Cursor SDK と同じ）。Grok 4.6 / 4.5 / Composer 2.5 を直接選んでください。Auto は Pro 以上。Optimize For の3モード（Cursor Router）は Teams / Enterprise（公式 Models & Pricing / Cursor Router）該当の節へ
• Optimize For や Cost / Balance / Intelligence が出ない→ Cursor Router の3モードはいま公式では Teams / Enterprise 向けです。Enterprise は既定オフで、管理者がダッシュボードから有効化します。個人の Start / Pro では Auto があっても Optimize For が無いことがあります（公式 Cursor Router）該当の節へ
• Auto にしたら利用量が想定より速い→ Balance と Intelligence は Cost より利用枠を速く使います。難しい仕事向けです。はじめては Cost。課金は振り分け先モデルの定価で、他社モデルなら Cursor Token Rate も乗ります（公式 Cursor Router / Models & Pricing）該当の節へ
• Teams で Auto / Cursor Router が動かない（Grok を止めた）→ 公式では振り分けが働くために Cursor Grok 4.6 が必要です。Grok 4.6 を止めると Router が動かないことがあります。モデルを止めすぎると振り分けの質も落ちます（accounts-setup の Auto 節。公式 Cursor Router）該当の節へ
• Cloud Agents の Secrets タブが見えない→ Cloud Agent 設定の権限不足が多いです。登録は管理者に依頼し、値は別経路で渡しましょう該当の節へ
• Secrets を入れたのに Agent が使えない→ 追加直後は反映されないことがあります。新しい実行を始めるか、正しい Cursor チームに登録されているか確認しましょう該当の節へ
• Automation の実行ログに MCP 認証エラー→ MCP の OAuth や接続が切れています。その MCP だけスキップされ実行は続くので、Integrations で再接続するか、不要なら MCP ツールをオフにしましょう該当の節へ
• Automations が一度も動かない→ Trigger が Draft 専用のまま、または Slack が非公開チャンネルだけ、といった設定ずれが多いです該当の節へ
• 『センスよく直して』と頼んでも毎回ブレる→ 完了条件が弱いときです。5要素か Design Mode で具体化してみましょう該当の節へ
• プレビューやテストまで Agent が進まない→ 実行環境のセットアップ不足が多いです。詳しい人への依頼文の型を使ってみてください該当の節へ
• スクショや短い動画が付いてこない / 『確認できなかった』と返る→ 仕事場でアプリを起動・ログインできる状態になっていないことが多いです該当の節へ
• Environment ready（with warnings）と出る→ スナップショットの期限切れや読み込み失敗で、既定の土台に戻っていることがあります該当の節へ
• Agent の起動だけがいつも長い→ Cloud Agent Builds が未有効、または Build 失敗で古い準備に頼っている可能性があります。Environments の Builds タブを確認してみてください該当の節へ
• main の最新が Agent に反映されていない気がする→ Cloud Agent Builds の Update stale builds がオフ、または Staleness threshold 内で Build 時点の main に固定されている可能性があります。Builds タブを確認してみてください該当の節へ
• Build が赤（失敗）のまま残っている→ install コマンドや Dockerfile の設定ミスの可能性があります。Builds タブで失敗 Build のログを開き、Trigger build / Test build で直したあと成功するまで待ちます。Agent 実行は最後に成功した Build が使われ続けます該当の節へ
• 環境セットアップが Secret 追加待ちで止まっている→ Agent が request-environment-setup-actions で『Secret を足してほしい』と記録していることがあります。setup_failed ではなく setup_started のまま止まることもあります。Secret 名だけを管理者に伝え、値は別経路で渡したあと、新しい実行を始めるか続きを頼んでください該当の節へ
• setup_started のあと setup_failed も setup_completed も出ない→ Secret 追加などユーザー操作待ちで request-environment-setup-actions が記録されていることがあります。会話と実行イベント節を確認し、Secret 対応後に続きを頼んでください該当の節へ
• 環境を直したあとスナップショットを残したい→ Agent 主導セットアップ後にスナップショット保存を頼むか、Cursor Cloud MCP の take-environment-snapshot / check-environment-snapshot を Agent に使わせます。管理者への依頼文の型にも含まれています該当の節へ
• AWS IAM 連携で、長時間動かすと AWS 接続が切れた→ 公式では STS の一時認証情報は1時間で失効し、Agent が再開するときは失効15分前から自動更新されます。install 中や長いターンのあいだに切れたように見えるときは、OIDC / AWS IAM 節を確認してください該当の節へ
• Dockerfile を少し直すたびに全部ビルドし直している気がする→ 公式では Dockerfile ビルドはレイヤーキャッシュを使い、変更した層だけ再ビルドされます。毎回ゼロからではないので、Build ログでどの層がキャッシュされたかを見ると安心です該当の節へ
• 社内 API にだけ届けたい（パブリックには出したくない）→ 許可リストだけでは足りないことがあります。公式の Cloud Environment Setup では Tailscale（userspace networking）や Cloudflare Tunnel（cloudflared）の例があります。詳しい人に『プライベート接続が必要』と伝えてください該当の節へ
• Cloudflare Tunnel で社内 HTTP API に届かない / 401 になる→ Cloudflare Access を使う社内ホスト名なら、Secrets に CF_ACCESS_CLIENT_ID / CF_ACCESS_CLIENT_SECRET を入れ、リクエストに CF-Access-Client-Id / CF-Access-Client-Secret ヘッダーを付ける公式例があります。許可リストにもそのホスト名が必要です該当の節へ
• Dockerfile でプロジェクト全体を COPY している / Build が重い→ 公式ではプロジェクト全体を Dockerfile で COPY しません。Cursor がワークスペースを管理し、正しいコミットを checkout します。システム依存だけ Dockerfile に書き、ソースはリポジトリ側に任せましょう該当の節へ
• environment.json の Dockerfile パスが効かない→ 公式では build.dockerfile と build.context は `.cursor` フォルダ基準です。リポジトリルートの Dockerfile を指すなら context に `..` などの特別値を使います。install コマンドはプロジェクトルートで実行される点も確認してください該当の節へ
• team follow-ups で『誰が追記したか』を Hook で区別したい→ エージェントメタデータの turn/user-id と owner/user-id を比べる公式例があります。認証情報ではなくログ・監査用です該当の節へ
• Automation から起動した Agent かどうか分からない→ エージェントメタデータの agent/source が AUTOMATIONS のとき、Automation 起動です。ダッシュボードの Automation ID も workspace/automation-id で読めます（詳しい人向け）該当の節へ
• Auto を選んだのにどのモデルが動いたか知りたい→ Teams / Enterprise では Cursor Router が振り分け先を既定で隠します（結果で判断する公式の勧め）。管理者設定で表示するか、詳しい人は turn/model（Auto という文字列ではありません）。入口は accounts-setup の Auto 節（公式 Cursor Router）該当の節へ
• エージェントメタデータの turn/user-id が読めない（404）→ turn/ 配下はコーディングターンが動いている間だけ存在します。ターンとターンのあいだは消えるので、Hooks ではターン中だけ読む前提にしてください該当の節へ
• モバイル起動なのに agent/source に iosApp が無い→ inbox の `source: iosApp` は UI 表示用です。メタデータ API の agent/source は WEBSITE / API / SLACK / AUTOMATIONS など別の公式キーです該当の節へ
• turn/id と agent/id のどちらをログに付けるか迷う→ agent/id は Cloud Agent 全体（bcId）、turn/id はいまのコーディングターンだけの ID です。公式例では両方タグ付けします該当の節へ
• メタデータ API が 403 / 429 を返す→ 403 はこの実行では読み取り不可（再試行しない）。429（rate_limited）や 503（saturated・同時接続過多）は Retry-After を見てバックオフ再試行です（429 は1分120回・20件バースト上限。ソケット同時接続は最大8）該当の節へ
• メタデータ API が 500 / 502 / 504 を返す→ 500（host_error）や 502 / 504（backend_unreachable）は一時障害としてバックオフ再試行です。403 だけは致命的で再試行しません該当の節へ
• Build が失敗した原因を自分では読めない→ Agent に『Cursor Cloud MCP で最新の失敗 Build を調べて』と頼めます。list-environment-builds と environment-build-logs、直したら trigger-environment-build で Test build、という公式の流れがあります該当の節へ
• 実行 URL はあるが、どこで止まったか分からない→ Agent に run-info → get-events の順で調べさせるのが公式の診断の入口です。setup_failed / pr_creation_failed / mcp_auth_error などの kind を確認し、該当ログへ進みます該当の節へ
• Subscriptions で待っているのに Agent が再開しない→ ① 待ち条件がまだ満たされていない（CI が赤い・Checks が黄色（pending）・レビュー未承認など）② 購読が180日で切れた／Agent が解除した ③ フォローアップがキューに残っている（Cursor Cloud MCP の get-message-queue で確認。いま実行中のメッセージは含まれません）。follow-up-loop の Subscriptions 節に3段階の切り分けがあります該当の節へ
• get-message-queue が空なのに Agent が再開しない→ キューが空でも、CI が赤い・Checks が黄色（pending）・必須レビューが未承認など、Subscriptions の待ち条件がまだ満たされていないと Agent は起きません。PR の Checks とレビュー状態を確認してください該当の節へ
• テストは緑なのに CI 待ちの Agent が起きない→ GitHub の CI 待ちは Checks が全部終わるまで1つの結果です。人が承認するまで黄色（pending）の Check が1つあると全体が届きません。pending のままにせず、GitHub の action_required（要対応）で完了させる公式の対処があります。要対応でも必須 Check ならマージは止まります（follow-up-loop の Subscriptions 節。公式 capabilities）該当の節へ
• multi-repo でどの保管庫が読み込まれているか知りたい→ エージェントメタデータの workspace/repo-urls を読むと、主リポジトリが先頭で残りがソートされた一覧が取れます（詳しい人向け）該当の節へ
• 同僚の Agent の会話が見えない→ Cursor Cloud MCP でも一般メンバーは自分の実行中心です。同僚の実行を見るには、相手が URL を共有し、あなた自身が GitHub 等の保管庫へアクセスできる必要があります。チーム管理者でも他人の会話を自由に見られるわけではありません該当の節へ
• Secrets を変えたのに Build が走った→ 環境設定や Secrets の保存は新しい Build のきっかけになります（公式）。意図どおりなら成功を待ち、Builds タブでログを確認してみてください該当の節へ
• ログインが必要な画面を Agent が確認できない→ ログイン用 Secrets（必要なら 2FA の共有秘密）が未設定のことがあります該当の節へ
• 個人の Cursor から社内リポジトリで Agent が動いてしまい不安→ Protected Git Scopes で Organization を自社 Cursor チームに閉じると防げます該当の節へ
• Team Owned に上げたら Webhook や MCP が動かなくなった→ 実行アカウントが変わったため、API キー再発行やサービスアカウント向けの再接続が必要なことが多いです該当の節へ
• モノレポで Secrets の名前がぶつかる / 別アプリの鍵が混ざる→ 接頭辞付きのユニークな名前で Secrets にまとめ、各アプリから参照する形が公式の推奨です該当の節へ
• API キーが会話やコミットに見えてしまった→ Secrets の種類が Environment Variable のままかもしれません。漏れたくない値は Runtime Secret にします該当の節へ
• ネットワーク制限を入れたらスクショや動画が PR に付かなくなった→ 成果物のアップロード先ホストを許可リストへ足す必要があることがあります（ワイルドカードは避けます）該当の節へ
• Slack に Agent の差分やコード断片が出て困っている→ 『外部チャンネルへの Agent 要約表示』のセキュリティ設定をオフにできることがあります該当の節へ
• PR のコミットに Verified が付いていて不安 / 意味が分からない→ Cloud Agent の署名コミットです。正規の Agent 実行なら想定どおりです該当の節へ
• Secrets のどれを選べばいいか分からない→ 漏れたくない値は Runtime Secret。読ませてよい設定は Environment Variable。ビルド時だけは Build Secret です該当の節へ
• チーム共通のトーンや禁止事項を毎回書いている→ Rules の三層（個人 / チーム / リポジトリ）のうち、共有したい約束はチームかリポジトリへ置きましょう該当の節へ
• Automations の部品が多すぎて何から決めればいいか分からない→ まず Trigger（きっかけ）と Prompt（完了条件・禁止・出力先）の2つから決めると進めやすいです該当の節へ
• clone / commit / push のちがいが分からず開発者と会話できない→ Git の旅路（4語）を図で一度通すと追いつきやすいです該当の節へ
• Agent の会話やコードがクラウドに残るのが不安→ 会話は長く残りやすく、使わない環境スナップショットは90日で消えます。Enterprise なら保持ポリシーを管理者に確認できます該当の節へ
• Automation の PR 作者が cursor になっていて誰の変更か分からない→ Team Owned では PR が cursor 名義になります。Private / Team Visible は作成者の GitHub アカウントです該当の節へ
• マージで Squash と Merge のどちらを選べばいいか分からない→ Squash は変更を1つにまとめて本線へ入れる方式です。チームのルールが不明なら、詳しい人に確認するか、いったん Squash で問題ないか聞いてみましょう該当の節へ
• 差分は良さそうなのに、自分で画面を触って確かめたい→ Agent 画面の remote desktop control で、クラウド上のデスクトップを一時的に操作できます。review-and-merge と agent-lifecycle の ACT 3 を参照してください該当の節へ
• Webhook の URL が Automations 画面で見えない→ Webhook トリガーは Automation を一度保存して初めて URL と API キーが発行されます該当の節へ
• Slack 起点の Automation が文脈不足で的外れ→ Read Slack channels ツールをオンにすると、返信前に公開チャンネルを読めるようになります該当の節へ
• 社内 GitHub（Enterprise Server）で Cursor が接続できない→ GitHub.com とは別の Enterprise Server 接続が必要です。ネットワーク許可と管理者登録を確認してください該当の節へ
• github.com なのに Agent がリポジトリに入れない→ Organization の IP 許可リストで Cursor の GitHub アプリがブロックされていることがあります該当の節へ
• GitLab / Bitbucket なのに Automations が PR で動かない→ フォークから開いた PR ではソース管理トリガーが動きません。自社リポジトリ上のブランチから PR を開いているか確認してください該当の節へ
• Azure DevOps なのに Automations の PR トリガーが選べない→ 公式では Azure DevOps は Automations 非対応（ロードマップ上）です。Cloud Agent は Web / Desktop から起動し、自動化は予定・Webhook など別 Trigger を検討してください該当の節へ
• GitLab Free なのに Connect が進まない→ 公式 GitLab 連携は Premium または Ultimate が必要です。Project access token が Free プランでは使えません該当の節へ
• Azure DevOps の Connect が途中で止まる→ 初回接続時に Microsoft Entra ID の管理者同意（admin consent）が必要なことが多いです。Cursor チーム管理者と Azure AD 管理者の両方に依頼してください（accounts-setup の GitLab / Azure DevOps 節）該当の節へ
• GitLab / Azure DevOps の PR に @cursor と書いても Agent が動かない→ 公式の Cloud Agent 起動入口では、PR / Issue コメントの @cursor は GitHub と Bitbucket だけです。GitLab / Azure DevOps は cursor.com/agents や Desktop の Cloud から起動してください該当の節へ
• Sentry や PagerDuty 連携の Automation が一度も動かない→ Integrations 未接続、または Trigger のイベント種別（作成だけ／すべて）が実際の通知と合っていないことがあります該当の節へ
• Automation の Memories が変な方向に誘導する→ 誤ったメモが残っています。ツール設定 UI から Memories を編集・削除するか、信頼できない入力向け Automation では Memories をオフに検討してください該当の節へ
• スマホから PR のレビュアーを足したい / 変えたい→ iOS アプリの PR レビュー画面からレビュアーの追加・変更ができます。差分ビュー中心ですが、マージや auto-merge の切り替えも同じ画面から行えます該当の節へ
• リポジトリの Hook が Cloud Agent で動かない→ prompt-based 設定か、sessionStart / beforeMCPExecution など Cloud 非対応の種類かもしれません。command-based の `.cursor/hooks.json` か、書き込み可能になるまで待ってから再確認してください該当の節へ
• PR に cursor のコメントが付いたが、自分の Automation ではない→ Bugbot や Security Agents など、Cursor 管理の Agent、または Team Owned の Automation の可能性があります。Automations レッスンの『Cursor が用意している Agent』節を参照してください該当の節へ
• PR を開いていないのに push しただけで Automation を動かしたい→ ソース管理トリガーの Push to branch（ブランチへの push）を選び、対象ブランチ名を指定します該当の節へ
• チーム全員がリポジトリから Cloud Agent を起動できない→ Cursor チーム管理者がまだ GitHub などのソース管理を Connect していないことがあります。個人の接続だけでは足りない場合があります該当の節へ
• 定期 Automation が毎回ピッタリの時刻に動かない→ スケジュール起動は遅れることがありますが、指定時刻より前には始まりません。cron の解釈や負荷で数分ずれることは想定内です該当の節へ
• multi-repo で長時間の仕事を任せたい→ 公式では multi-repo 環境では長期実行（Long running agents）がまだ使えません。単一リポジトリで任せるか、保管庫ごとに Agent を分けてください該当の節へ
• 古い資料に Background Agents と書いてある→ Cloud Agent の旧称です。機能の説明は agent-lifecycle 以降の Cloud Agent レッスンを正とします該当の節へ
• 同じリポジトリなのに前回と挙動が違う→ 環境の解決順（environment.json / 個人 / チーム）や Environment ready の警告で土台が変わったことがあります。Agent 画面でリポジトリ名にカーソルを載せ、使った環境を確認しましょう該当の節へ
• Automation が Fork pull requests not supported で止まる→ フォークから開いた PR ではソース管理トリガーが動きません。自社リポジトリ上のブランチから PR を開く運用にしてください該当の節へ
• Automation の PR が別リポジトリに開かれた→ 予定や Slack 起点では PR 作成の向け先が Automation 設定のリポジトリになります。ソース管理トリガーなら PR の保管庫へ向きます。設定の Repository を確認してください該当の節へ
• Agent が CI 失敗を何度も直し続ける→ Agent 作成 PR では GitHub Actions の自動修正（autofix）が走ることがあります。止めたいときは PR に `@cursor autofix off`、再開は `@cursor autofix on`。全体で止めるなら Dashboard → Cloud Agents → My Settings の Automatically fix CI Failures も確認してください該当の節へ
• 自分でコミットを足したあと autofix が動かなくなった→ 公式では Agent 作成 PR でも、人が後から push すると自動の CI 修正追従は止まります。PR に `@cursor please fix the CI failures` と頼ぶか、Subscriptions で『CI が通るまで続けて』と依頼してください該当の節へ
• 追加メッセージを送ったあと autofix が動かなくなった→ 公式では、Agent 作成 PR でもあなたが follow-up を送ると自動の CI 修正追従は止まります。PR に `@cursor please fix the CI failures` と頼むか、Subscriptions で『CI が通るまで続けて』と依頼してください該当の節へ
• 本線でも同じ Check が赤いのに autofix が動かない→ 公式では、取り込み先（base）でも同じ Check が既に失敗している PR では autofix の自動追従は走りません。本線側の失敗を先に直すか、PR に明示依頼してください該当の節へ
• autofix が10回で止まった→ 公式では、同じ PR で CI 失敗の自動修正が10回に達すると autofix は止まります。PR に `@cursor please fix the CI failures` と頼むか、Subscriptions で続けて依頼してください該当の節へ
• 機能ブランチの environment.json が効かない→ Build の土台は環境の既定ブランチ（多くは main）の `.cursor/environment.json` が使われます。機能ブランチだけに追加したときは commit & push してから、そのブランチで Agent を起動してください該当の節へ
• ダッシュボードに update script と表示される / install がどこか分からない→ 公式では install スクリプト（旧称 update script）に名称が変わっています。`.cursor/environment.json` の install フィールドと、Builds タブの手順が同じものです該当の節へ
• ガイド付きセットアップが進んでいるか分からない / 止まっているように見える→ 公式では Agent 主導セットアップ中、共有ターミナルで install の進捗を一緒に見られます。依存の install 中は待ち時間が長く見えることがあります該当の節へ
• AWS へ長期の API キーを Secrets に置きたくない（IAM 連携）→ 公式では `CURSOR_AWS_ASSUME_IAM_ROLE_ARN` と External ID を使う IAM ロール連携があり、OIDC トークンと組み合わせて長期鍵を避けられます。詳しい人向けです該当の節へ
• Microsoft Teams から Cursor / Automations を使いたい→ チャットアプリの Microsoft Teams は、Cursor の Teams プランとは別です。Dashboard → Integrations で Microsoft Teams を Connect し、チャンネルで `@Cursor` と依頼します。Automations の Trigger 一覧に Teams 専用は少ないので、日常の依頼は @Cursor、定期実行は予定や PR が分かりやすいです（公式 Microsoft Teams）該当の節へ
• Microsoft Teams で @Cursor しても反応がない→ Integrations 未接続、Microsoft Teams 側に Cursor アプリ未導入、Privacy Mode（Legacy）のまま、またはソース管理未接続が多いです。accounts-setup の Microsoft Teams 節を参照してください該当の節へ
• Microsoft Teams の個人チャットで追記できない→ 公式ではチャンネルのスレッドだけ `@Cursor` 追記です。個人チャットやグループチャットの続きは Open in Web / Open in Desktop です（公式 Microsoft Teams）該当の節へ
• 個人プランで autofix が自動で動かない→ 公式では CI の自動修正（autofix）はいま Teams 向けです。個人プランでは Subscriptions で『CI が通るまで続けて』と依頼するか、PR に `@cursor please fix the CI failures` と明示してください。3道具の節で autofix と Subscriptions の違いも確認できます該当の節へ
• stdio の MCP だけ Cloud Agent で動かない→ Cloud Agent では SSE や mcp-remote 方式は使えません。HTTP MCP を検討するか、stdio コマンドが実行環境で動くよう環境を整えてください該当の節へ
• GitHub が無いのに Cloud Agent を始めたい→ 保管庫ピッカーの Start from scratch（ゼロから始める）と Origin が公式の道です。accounts-setup の Origin 節を参照してください。画面に出ないときは GitHub 接続の本線で進みます該当の節へ
• Origin や cursor.com/codebase の画面が出ない→ Origin は早期ベータで、Pro / Teams / Enterprise 向けです。段階公開、Privacy Mode（Legacy）、管理者がオフ、のいずれかが多いです。出ないときは GitHub 本線で進めてください該当の節へ
• Start from scratch を選んだあとの保管庫が分からない→ 依頼を送ると裏側で Origin のリポジトリが用意されます。残すときは Create repo で名前と公開範囲を決め、cursor.com/codebase から開けます（first-cloud-agent の Start from scratch 節）該当の節へ
• Origin で作った変更の PR が GitHub に無い→ Origin 上で作った保管庫の PR は Origin 側です。GitHub から同期した保管庫だけ GitHub の PR になります（repository の Origin 節）該当の節へ
• 大きな目標を1回で任せたいのに、途中で終わったように見える→ Agent は通常、送った1通を新しい仕事として読みます。終わるまで追い続けてほしいときは `/goal` で目標を渡します（prompting の /goal 節）該当の節へ
• 作業中に追加したら Agent が途中で止まった / 途中の作業が壊れた→ cursor.com/agents では Send now（または Enter 2回）で、いまの一手を止めずに次の道具呼び出しで方向を変えられます。ターンのあとまで待たせるなら Tab でキュー（follow-up-loop の作業中の追加指示節）該当の節へ
• サブエージェント同士が同じファイルを壊す / 親の変更を新鮮な環境で試したい→ 子は既定では親と同じ作業コピーを共有します。衝突を避けたいときは『それぞれ別環境で走らせて』と頼んでください（first-cloud-agent の起動中に見ること節。公式 Subagents）該当の節へ
• 会話に Explore / Bash / Browser のカードが出た。自分で作った子なのか分からない→ 設定不要のビルトインサブエージェントです。保管庫探し・長いコマンド出力・画面操作の途中ノイズを親の会話から外します。自分で作る必要はありません。Desktop の `@browser` や Cloud のコンピュータ操作とは別です（first-cloud-agent の起動中に見ること節。公式 Subagents / Browser）該当の節へ
• Browser と @browser とコンピュータ操作のどれを使えばいいか分からない→ 会話の Browser カードはビルトインの子役（途中ノイズを要約）。Desktop の `@browser` はエディタ内のブラウザ枠でページ確認。Cloud Agent の画面確認はコンピュータ操作です（when-desktop の Cloud だけでかなり行ける節。公式 Browser / Subagents）該当の節へ
• 手元の会話を止めずに、次の仕事だけクラウドで動かしたい→ Desktop / CLI なら `/in-cloud` です。次の依頼だけ別 VM・別枝のクラウド子 Agent になります。会話ごと移す `&` や Move to Cloud とは別です（when-desktop の /in-cloud 節。公式 Subagents）該当の節へ
• 機能や移行など大きな仕事を1つの Agent に詰め込んでいる→ 1つの Cloud Agent や `/goal` は1本の仕事向きです。1回のチャットで終わらない仕事は、左ナビの Projects（コーディネーター）が計画して複数 Agent に振り分けます。公式の使い方は機能づくり・移行・日常の手入れです（when-desktop の Projects 節）該当の節へ
• Projects や左ナビのコーディネーターが出ない→ Projects はベータで段階公開です。すぐ出ないときは、これまでどおり1つの Cloud Agent と Automations で進めてください（公式 changelog 2026-09-10）該当の節へ
• Automations と Projects のどちらを使えばいいか分からない→ Automations は決まったきっかけで同じ型の Cloud Agent を起動します。Projects はコーディネーターが大きな仕事を計画し、複数 Agent に振り分け、学びを共有します。公式の使い方は機能づくり・移行・日常の手入れです該当の節へ
• 1回で終わる文言修正なのに Projects を開いてしまった→ Projects は1回のチャットで終わらない仕事向けです。小さな修正は1つの Cloud Agent、決まったきっかけの繰り返しは Automations です（when-desktop の Projects 節）該当の節へ
• GitHub から同期した Origin 保管庫で Depot / Buildkite が動かない→ 公式 Origin settings では Depot / Buildkite は Origin 上で作った保管庫向けです。GitHub 同期の保管庫の CI は GitHub 側のままです該当の節へ
• 試作を公開したいが、プレビュー URL の出し方が分からない→ Start from scratch のあとは Vercel アカウントをつないで Publish できます。残した Origin 保管庫なら Apps タブの Vercel でプッシュや PR のプレビューもつながります（公式 changelog 2026-08-27 / Origin settings）該当の節へ
• Origin の PR で、GitHub と同じ確認画面が見つからない→ Origin 上で作った保管庫の PR は Activity / Commits / Checks / Files Changed の4タブです。GitHub 同期なら GitHub の PR を Cursor 上で読みます（公式 Origin pull requests）該当の節へ
• Origin と git の origin と origin コマンドのちがいが分からない→ 製品名 Origin は Cursor の保管場所、git の origin は共有場所の通称、origin コマンドは Origin CLI（Agent CLI の agent とは別）です。git-mental-model の見分け節を見てください該当の節へ
• origin コマンドが見つからない / agent コマンドと混同した→ Origin CLI（origin）と Cursor Agent CLI（agent）は別物です。はじめての方は自分で入れず、Agent に『Origin に置いて』と頼んでください（公式 Origin CLI）該当の節へ
• GitHub 同期の保管庫で origin/ の枝から PR が出ない→ 名前が origin/ で始まる枝は Origin 側だけの作業場です。GitHub の PR の先頭にはなりません。普段の Cloud Agent の PR は普通の枝名です（公式 Origin git / pull requests）該当の節へ
• GitHub の Issue や Actions が Origin に無い→ 公式の同期対象は git の履歴・枝・タグと、Cursor 上で読める GitHub PR です。Issue と GitHub Actions は GitHub 側のままです（公式 Origin mirror）該当の節へ
• GitHub 同期をやめて Origin を正本にしたい→ 保管庫の Settings → General の Danger Zone で Detach from GitHub します。同期が止まり Origin が正本になります。GitHub 側の保管庫は消えません（公式 Origin settings / mirror）該当の節へ
• 手元で git を打てないのに Origin へ置きたい→ Agent に『Origin に置いて』と頼むと、CLI の導入から保管庫作成・push まで任せられます。Start from scratch でも裏側で Origin の保管庫が用意されます（公式 Origin create-repository）該当の節へ
• Origin の PR がマージできない / グレーのまま→ Origin 上で作った保管庫では Settings の Rules and Protections（GitHub のブランチ保護の対応）を疑います。GitHub 同期なら GitHub 側のブランチ保護です。コンフリクトも Origin の PR 画面に出ます（公式 Origin settings / pull requests）該当の節へ
• Origin の Apps を保管庫の Settings で探せない / インストールできない→ 保管庫の Apps タブは接続済みの表示です。インストールはコードベース設定の Manage Apps です（公式 Origin settings / codebase-settings）該当の節へ
• Origin の PR が Draft のまま Ready にならない→ Origin CLI で作る PR は既定が Draft です。画面で Ready にするか、Agent に『Ready にして』と頼んでください（公式 Origin CLI PR）該当の節へ
• git を使わず Origin のコードや保管庫を見たい→ cursor.com/codebase で Find repo... から開けます。緑の Code から clone URL も取れます。git コマンドは不要です（公式 Origin）該当の節へ
• PR を出したあと毎回『続けて』と書きたくない（指摘・CI・コンフリクト）→ チャットで `/autopilot` と打つと、開いた PR の指摘・コンフリクト・赤い Checks を見守って直せます。Subscriptions を自分で組み立てるより短いです（公式 Agent Skills）該当の節へ
• 差分の意図が分からない / なぜこの変更が入ったか知りたい→ `/cursor-blame` で AI が書いた変更と、そのときの依頼文を調べられます。確認チェックリストのあと、残す／戻すを決めましょう（公式 Agent Skills）該当の節へ
• ついでが増えて PR が大きすぎる→ `/split-to-prs` で大きな変更を小さな PR に分けられます。ついで案件は次の PR に回すのが安全です（公式 Agent Skills）該当の節へ
• 個人用 Skill をチームのみんなに配りたい→ Teams / Enterprise なら Customize → Skills から Default marketplace へ Publish できます。公開しても同僚は自分で入れます。その保管庫だけなら `.cursor/skills/` への PR の方が分かりやすいです（公式 Plugins）該当の節へ
• Origin の Checks が古いコミットのまま / 更新されない→ Checks は先頭コミット向けです。push したのに古い結果なら Agent に『PR を refresh して』と頼むか origin pr refresh。通常は push で新しい版が作られます（公式 Origin CLI PR）該当の節へ
• Origin の保管庫がチームの人から見えない / 権限が分からない→ Origin のプライバシーはコードベース名の持ち主の Privacy Mode に従います。コードベース設定からアクセスを依頼できます。Private に切り替えた人は管理者権限が残ります（公式 Origin / codebase-settings）該当の節へ
• 言葉だけではイメージできない / 触って試せる見本が欲しい→ `/canvas` で会話の横に触って試せる小さな画面を出せます。コード変更ではなく理解用の見本です（公式 Agent Skills）該当の節へ
• 画面のラフや構成図の画像が欲しい→ Agent に『ラフ画像を作って』と頼むと、文章や参考画像から画像を作れます。Design Mode は既存画像に印を付ける側です（公式 Agent overview）該当の節へ
• チームの Hex Canvas や Atlassian Canvas の開き方が分からない→ プラグインに付いている共有ひな型です。Customize からインストール済みプラグインの Canvas を開きます。自作の見本だけなら `/canvas`。自分の Canvas をリンクで渡すのは Shared Canvases（公式 Plugins / Canvases）該当の節へ
• 同僚に Canvas を見せたいがチャット履歴を渡せない→ Canvas のツールバーで Publish し、リンクをコピーして送ります。ダッシュボードの Shared Canvases は自分が公開したものだけです。同僚の Canvas はリンクをもらって開きます（公式 Canvases）該当の節へ
• ダッシュボードの Shared Canvases に同僚の Canvas が出ない→ 公式では、ダッシュボードに並ぶのは自分が Publish したものだけです。同僚の分は共有リンクをもらってブラウザで開きます。閲覧は読み取り専用です該当の節へ
• Canvas の共有リンクが作れない / Publish が出ない→ Shared Canvases は有料プランかつチーム所属が必要です。Free、チーム外の Pro、Privacy Mode（Legacy）、管理者オフ、のいずれかが多いです（公式 Canvases）該当の節へ
• Canvas の見た目を『センスよく』と頼んでもブレる→ Canvas 上でも Design Mode で部品を選んで印を付けられます。ブラウザの Design Mode と同じ考え方です（公式 changelog Canvas Design Mode）該当の節へ
• Bugbot が毎回 PR 全体を読んで同じ指摘を繰り返す→ いまの公式の既定は Incremental Review（前回からの差分だけ）です。フル差分のままならオフになっていないか確認します。同じ指摘が続くときは、既存コメントを読む公式の動きと Autofix の別枝も切り分けます。push 前なら `/review`（公式 Bugbot）該当の節へ
• Bugbot が新しい差分しか見なくて、前からある問題を見逃す→ 既定の Incremental Review です。PR 全体を毎回読ませたいときは Bugbot Automations でオフにします（公式 Bugbot）該当の節へ
• Cursor Bugbot の Check が失敗していないのに指摘コメントがある→ 指摘があるときの既定の結論は neutral（中立）です。ブランチ保護で Check を必須にしても、指摘そのものではマージを止めません。未解決を失敗扱いにする設定は組織によっては別（公式 Bugbot）該当の節へ
• Bugbot が勝手に直して別ブランチを作った→ Bugbot Autofix です。指摘を Cloud Agent が直します。CI が赤のときの `@cursor autofix` とは別です。個人設定でオフ／新しい枝／既存枝を選べます（公式 Bugbot）該当の節へ
• /review-bugbot したあと、PR 側の Bugbot が動かない→ 同じ差分なら、保管庫側の Bugbot は再実行を飛ばして『すでに読んだ』とコメントすることがあります。差分を変えて push すると改めて読みます（公式 Bugbot）該当の節へ
• .cursor/rules を書いたのに Bugbot が無視する→ プロジェクト Rules（*.mdc）は Bugbot には効きません。レビュー用は `.cursor/BUGBOT.md` です。使われたルールを見るなら `cursor review verbose=true`（公式 Bugbot）該当の節へ
• 同じ型の Canvas 報告を毎回ゼロから頼んでいる→ いつ使うか・欄・数字の取り方・単位を Skill に書いておくと、短い依頼で同じ形が再現されます（公式 Canvases）該当の節へ
• Skill をカテゴリ分けしたい / 特定のファイルのときだけ出したい→ フォルダをネストして整理できます。名前は SKILL.md があるフォルダです。対象ファイルは paths（新規。古い globs も通る）で絞れます（公式 Agent Skills）該当の節へ
• メンバーが Skill を Publish できない→ 管理者の Allow Members to Publish がオフだと、新規公開は管理者だけです。既に公開した作者は更新・非公開はできます（公式 Plugins）該当の節へ
• Bugbot のレビューが遅い / 利用量が多い→ 従量課金の Bugbot なら Effort（Low / Default / High / Smart）を疑います。速さや費用を優先するなら Low / Default（公式 Bugbot）該当の節へ
• Bugbot が浅い指摘ばかりで取りこぼす→ Effort が Low / Default だと見つかりにくいことがあります。High か Smart（いつ詳しく読むかを文章で指定）を管理者に確認してください（公式 Bugbot）該当の節へ
• チームのレビュー約束を毎回 PR に書き直している→ PR に `@cursor remember （覚えさせたいこと）` と書くと、学習したルールとして以降の Bugbot レビューに入ります。長い約束は `.cursor/BUGBOT.md`（公式 Bugbot）該当の節へ
• チームが IntelliJ / PyCharm なのに Cursor Desktop が必要か分からない→ JetBrains IDE の AI Chat から Cursor の Agent を ACP で使えます。Cursor Desktop に移さなくても依頼できます。有料プランと AI Assistant プラグイン（2025.1+）が前提です（公式 JetBrains）該当の節へ
• Bugbot がオンなのに、同じ指摘がもう1本の Automation からも来る→ Bugbot と Marketplace の find bugs 系など自作 Automation は別系統です。お互いのコメントを読み合わないので、同じ PR で重ねると重複します。一般的なバグ探しは Bugbot に任せ、自作はドキュメントやトリアージなど別の仕事に絞りましょう（公式 Bugbot / Automations）該当の節へ
• 低リスクなのに PR Routing が承認してくれない→ Bugbot Review Context や Security Review Context がオンだと、その指摘が人の確認を要する場合は自動承認しません。完全なコードレビューの代わりでもありません（公式 PR Routing & Approval）該当の節へ
• Security Agents の定期スキャンと PR レビューのちがいが分からない→ Security Reviewer は PR / MR の直前。Vulnerability Scanner は保管庫を予定で読む側です。どちらも cursor.com/automations の Security Agents から設定します（公式 Security Agents）該当の節へ
• /review と /agent-review のどちらを打てばいいか分からない→ Desktop の手元変更を読むのが `/agent-review`（Agent Review）。PR や Cloud Agent 向けに先に読んでもらうのが `/review` / `/review-bugbot` / `/review-security` です。まだ PR が無いかで切り分けます（公式 Agent Review / Bugbot）該当の節へ
• Desktop の Agent が変な方向に進んだ。ファイルを戻したい→ Checkpoints です。チャットのタイムラインから戻り地点を見て Restore します。会話は消えず、ファイルだけ戻ります。Git のコミットとは別です。Cloud Agent なら『戻して』と追記するか PR を閉じます（when-desktop の Checkpoints 節）該当の節へ
• ターミナル（CLI）の会話を Cloud Agent に渡したい→ メッセージの先頭に `&` を付けると Cloud Agent へ引き継げます。続きは cursor.com/agents やスマホです（公式 CLI。first-cloud-agent の他の起動場所）該当の節へ
• 手元の変更を PR 前に読んでもらいたい / Agent Review の設定場所が分からない→ チャットの `/agent-review` か Source Control タブです。設定は Cursor Settings → Agents → Agent Review。Cursor 3.11 以降は Git & PRs → Pull Requests に移ります（公式 Agent Review）該当の節へ
• Team Pool が選択肢に出ない / 選べない→ 公式では Team Pools は Enterprise プランが前提です。Teams だけでは足りないことがあります。はじめては Cloud machine。社内専用の作業場が必要なら管理者に Self-Hosted / Enterprise を確認してください（公式 Self-Hosted Machines）該当の節へ
• APPROVAL_POLICY.md を同じ PR で直したのに、PR Routing が甘く承認してくれない→ 公式では、同じ PR で承認ポリシーや ROUTING.md を変えても、その PR の審査を甘くする材料には使いません。本線の版を見るか、人の確認にします（公式 PR Routing & Approval）該当の節へ
• いきなりファイルを直されるのが怖い / 先に調べたい→ Desktop / CLI なら Ask Mode（Shift+Tab または `/ask`）でファイルを変えずに調べられます。Cloud Agent なら調査だけテンプレや Slack の autopr=false が同じ役割です（公式 CLI / prompting）該当の節へ
• 大きな仕事をいきなり実装させて外れた→ Plan Mode です。先に計画を見て直してから作ります。Shift+Tab または `/plan`。作ってから直すより、戻して計画を練り直す方が早いことが多いです（公式 Plan Mode）該当の節へ
• Shift+Tab を押したら入力のモードが変わった / Plan と Ask のちがいが分からない→ 仕事の進め方は Agent（実装）・Plan（計画してから作る）・Ask（調べるだけ）に加え、再現バグ向けの Debug があります。小さな修正は Agent。先に方針を見たいなら Plan。触られたくないなら Ask。原因が分からない再現は Debug（公式 Plan Mode / Debug Mode / CLI）該当の節へ
• 再現できるのに原因が分からない / Agent が当てずっぽうで直して外れる→ Desktop / CLI なら Debug Mode（モード選択、Shift+Tab、または `/debug`）です。仮説とログから原因を絞ってから直します。Cloud Agent には同じ画面が無いので、再現手順つきで『ログを足して原因を特定してから直して』と依頼します（公式 Debug Mode。prompting）該当の節へ
• 残りの利用量やプランのリセット日が分からない→ エディタ設定と cursor.com/dashboard/usage に Cursor Models / Other Models の2枠が出ます。CLI なら `/usage` で残量・プラン名・課金サイクルのリセット日も見られます（公式 Models & Pricing / CLI changelog）該当の節へ
• CLI で sudo パスワードを聞かれた / AI にパスワードが見えるか心配→ 伏せ字の入力が出ます。パスワードは sudo へ直接渡り、モデルには見えません（公式 CLI overview。when-desktop の CLI 安全な作業場節）該当の節へ
• ターミナルを閉じたら CLI の Agent が止まった→ 手元のマシン上で続けたいなら `agent persist`（`/detach` で離れ、`agent persist attach` で戻る）。クラウドの作業場へ渡すならメッセージ先頭 `&`（公式 CLI changelog。when-desktop）該当の節へ
• agent persist と `&` のどちらを使えばいいか分からない→ persist は同じパソコン上で切断しても続ける起動。`&` は Cloud Agent（クラウド VM）へ引き継ぎます。席を離れてクラウドで続けたいなら `&`（公式 CLI。when-desktop / first-cloud-agent）該当の節へ
• CLI がいま開いている枝を直接いじって困る→ 別コピーで走らせる worktree です。CLI は `agent --worktree`。Desktop は `/worktree` か Agents Window。取り込みは `/apply-worktree`（公式 Worktrees / CLI。when-desktop）該当の節へ
• 昨日の CLI 会話を続きから開きたい / どのコマンドか分からない→ 履歴から再開するのは `agent resume`（いちばん新しい会話）か `agent ls`（一覧）。動かしたまま離れる `agent persist` とは別です（公式 CLI using。when-desktop の resume 節）該当の節へ
• agent persist と agent resume のちがいが分からない→ persist は同じ実行を切断しても続ける起動。resume は終わった／閉じた会話を履歴から開き直します。クラウドへ渡す `&` はどちらとも別です（公式 CLI using。when-desktop）該当の節へ
• CLI の会話が長くて重い / コンテキストがいっぱい→ `/summarize`（別名 `/compress`）でこれまでのやり取りを要約して空きを作ります。別の方針を試すなら `/fork`（公式 CLI using / slash commands）該当の節へ
• CLAUDE.md と AGENTS.md のどちらに書けばよいか分からない→ CLI はどちらも Rules として読みます。Cloud Agent の起動手順は AGENTS.md、方針・禁止は `.cursor/rules`。Claude Code から来たチームが CLAUDE.md を置いていることがあります（公式 CLI using。rules-and-skills）該当の節へ
• Desktop でコマンド実行の確認が多すぎる / 毎回聞かれる→ 公式のおすすめは Auto-review です。Settings → Agents → Approvals & Execution。許可した操作はすぐ、箱の中で走らせられるコマンドは sandbox、それ以外だけ確認します（when-desktop の Run Modes 節）該当の節へ
• Ask Every Time（毎回聞く）が見つからない / 選べない→ Cursor 3.5 で廃止され、新規では選べません。同じ動きが欲しければ Allowlist の許可リストを空にします（公式 Run Modes。when-desktop）該当の節へ
• Run Everything にしたら何でも通って怖い→ Run Everything は確認ゼロです。sandbox も分類も使いません。はじめては Auto-review。確認を残したいなら Allowlist（公式 Run Modes）該当の節へ
• Cloud Agent なのにコマンド承認が出ない→ 正常です。Run Modes は手元 Agent 向けです。Cloud Agent は専用の作業用コンピュータの中で動くので、コマンドごとに聞きません。確認は終わったあとの要約・差分・成果物です（公式 Run Modes。first-cloud-agent）該当の節へ
• Auto-review がグレーアウト / 選べない→ 分類に使う小さなモデル（Claude 4.5 Haiku または GPT-5.4 Mini）がチームで全部止められていることがあります。詳しい人に Team Settings → Models を確認してもらい、Cursor を再起動してください（公式 Run Modes）該当の節へ
• permissions.json と sandbox.json のちがいが分からない→ permissions.json は Auto-review に『いつも確認してほしいこと』を日本語で書くメモ。sandbox.json は箱の中でどこまで触れるかの設定です。最初はどちらも不要です（公式 Run Modes。when-desktop）該当の節へ

用語が分からないときは、用語集 もご利用ください。

パス完了のセルフチェック

全部に Yes がつけば、開発者との会話にもついていける水準です。焦らず、ひとつずつ確認してみてください。

• 初回起動直後は読み取り専用の探索で、すぐにはファイルが変わらないことがあると知っている
• ブラウザまたはスマホから Cloud Agent を起動できる
• Slack、Microsoft Teams の @Cursor、GitHub / Bitbucket の @cursor、Linear の @cursor からも頼めることを知っている
• チャットアプリの Microsoft Teams と Cursor の Teams プランは別物だと知っている
• GitLab / Azure DevOps は Web か Desktop の Cloud から起動し、PR コメントの @cursor は公式の入口ではないと知っている
• Azure DevOps Connect では Entra admin consent が必要なことが多いと知っている
• Slack では repo=（またはリポジトリ名）で作業先を明示できる
• 調査だけのとき autopr=false や『コード変更はまだしない』が使える
• 依頼文に背景・対象・変更・制約・完了条件を入れられる
• 成果物（スクショ/動画）と PR の Files changed で、意図せぬ変更に気づける
• PR 確認メモで、マージ / 追加指示 / 相談のどれかを選べる
• Agent URL を共有するとき、相手の Integrations 接続とリポジトリ権限が必要だと説明できる（Cursor は閲覧者の権限も確認する）
• Agent は起動した Cursor チームのメンバーに見えるが、メンバーであるだけでは開けないと知っている（複数チームにいるときはワークスペース一致も確認）
• モバイルでは実行ごとに MCP を選び、サーバーの追加・管理は Web だと知っている
• Rules / Automations の設定画面は Web だが、リポジトリの Rules・Skills・AGENTS.md はモバイル起動でも Agent が読むと知っている
• 個人用 Skill も Cursor に同期済みならモバイル起動から使えると知っている
• `~/.agents/skills/` や未同期の手元 Skill は Cloud Agent や自前ワーカーには届かないと知っている
• Agent のコミットに Verified が付くのは署名コミットだと知っている
• リポジトリ / ブランチ / コミット / マージを、短く自分の言葉で説明できる
• 環境と Secrets が Agent の品質を左右すると説明できる
• 漏れたくない API キーは Runtime Secret にすると説明できる
• Secrets の3種類（Runtime / Environment Variable / Build）を図で思い出せる
• 会話は長く残りやすく、使わない環境スナップショットは90日で消えると知っている
• スクショが付かないとき、仕事場（環境）不足を疑える
• 会社の Organization を閉じたいとき、Protected Git Scopes を管理者に頼める
• Rules の三層（個人 / チーム / リポジトリ）を説明できる
• Automations を『トリガー付き Cloud Agent』として、`/automate` か Marketplace から下書きできる
• Automations の4部品（Trigger / Prompt / Tools / Repo）を挙げられる
• Push to branch で PR なしの push をきっかけにできると知っている
• Team Owned の PR が cursor 名義になることがあると知っている
• Team Visible の Automation PR は作成者の GitHub 名義だと知っている
• Squash merge が変更を1つにまとめて反映する方式だと知っている
• Git の旅路（clone / commit / push / merge）を図で説明できる
• Team Owned に上げるとき、Webhook / MCP の見直しが必要だと知っている
• Webhook Automations は保存後に URL が発行されると知っている
• Privacy Mode へ切り替えたあと Legacy Privacy Mode には戻せないと知っている
• Cloud Agent は手元 PC がオフラインでもクラウド側で続き、並列実行もできると知っている
• Cloud Agent は Local Agent と同じ Agent の基本で、作業場だけクラウド VM だと知っている
• iOS アプリは cursor.com/agents と同じバックエンドにつながり、inbox が端末間で揃うと知っている
• Background Agents は Cloud Agent の旧称だと知っている
• Memories は MEMORIES.md として Automation 実行をまたいで残ると知っている
• チーム利用では管理者のソース管理 Connect が全員の前提だと知っている
• github.com の Organization 接続には Cursor 管理者と GitHub org 管理者が両方関わることが多いと知っている
• GitHub 連携で PR 作成だけ Permission denied のとき、PR write 権限・ブランチ保護・アプリ再インストールを疑える
• Pull request merged トリガーで、マージ後だけ Automations を動かせると知っている
• GitHub の Comment added（トップレベル）と PR review comment（diff インライン）を別トリガーとして選べる
• PR review submitted（Approve / Request changes 提出）と PR review comment を別トリガーとして選べる
• GitLab / Bitbucket の Pull request approved と GitHub の PR review submitted を別トリガーとして選べる
• CI completed（Checks）と Workflow run completed（Actions）を別トリガーとして選べる
• Cloud Agent の Hooks は書き込み可能な環境になってから動き始めると知っている
• ACT 2 の最初は読み取り専用の探索で、サイクル図の step 2〜3 どおり書き込み前に状況把握があると知っている
• Agent 画面でリポジトリ名にカーソルを載せると、使った環境を確認できると知っている
• Secrets の登録は Web の Cloud Agents 設定が正で、タブが無いときは権限を疑える
• Secrets 追加後は新しい Cloud Agent 実行を始めると反映されやすい
• Automations はコンテキスト窓を選べず、常にモデルの最大窓で動く
• Team Owned Automations の利用料はチームプールに計上され、作成者個人枠を消費しないと知っている
• Cloud Agent の Hooks は command-based のみで、prompt-based は動かないと知っている
• Automations の PR 作成は、ソース管理トリガーなら PR のリポジトリ、それ以外は Automation 設定のリポジトリへ向く
• Android では Chrome の Install App（PWA）で Agents をホーム画面から開けると知っている
• フォークから開いた PR では Automations のソース管理トリガーが動かないと知っている
• Fork pull requests not supported の意味と、自社リポジトリ上のブランチから PR を開く回避策を知っている
• Automations でリポジトリなし / 単一 / multi-repo を使い分けられると知っている
• multi-repo 環境では長期実行（Long running agents）がまだ使えないと知っている
• Agent 作成 PR の CI 自動修正を `@cursor autofix off` で止められると知っている
• Dashboard → Cloud Agents → My Settings の Automatically fix CI Failures で autofix 全体を止められると知っている
• Teams 以外では autofix の自動追従がなく、Subscriptions や `@cursor please fix the CI failures` が代替だと知っている
• autofix が自動追従しない4条件（人の push・追加メッセージ・base でも赤・10回上限）を説明できると知っている
• 機能ブランチだけの `.cursor/environment.json` は commit & push 後にそのブランチから起動すると反映されやすいと知っている
• install スクリプトは旧ダッシュボード名 update script と同じものだと知っている
• 個人用に保存した環境で試してからチーム環境へ広げられると知っている
• ガイド付きセットアップでは共有ターミナルで install の進捗を見られると知っている
• Dockerfile 変更時はレイヤーキャッシュで変更層だけ再ビルドされると知っている（詳しい人向け）
• Dockerfile でプロジェクト全体を COPY しない公式前提を知っている（詳しい人向け）
• environment.json の build.dockerfile / build.context は `.cursor` 基準だと知っている（詳しい人向け）
• Cloudflare Tunnel で社内 API へ届けるとき CF_ACCESS の Secrets 例があると知っている（詳しい人向け）
• 複雑な Docker 構成では fuse-overlayfs などの追加設定が必要なことがあると知っている（詳しい人向け）
• Remote Control は Local と Remote SSH ワークスペースで使え、Git remote なしでもよいと知っている
• Remote Control のセッションは自分のアカウントと手元 PC に紐づき、他人は操作できないと知っている
• Move to Cloud と Remote Control の目的のちがいを説明できる
• 起動時に Cloud machine / Team Pool / My Machines から選べると知っている
• 迷ったらまず Cloud machine を選べばよいと知っている
• Team Pool は公式には Enterprise プランが前提だと知っている
• 依存リポジトリやサブモジュールにも読み書き権限が要る場合があると知っている
• Selected repositories では Manage Connections で依存保管庫も追加依頼できると知っている
• Teams / Enterprise では管理者が Remote Control を許可している必要があると知っている
• Self-Hosted Machines でコンピュータ操作を使うには --computer-use が必要だと知っている（詳しい人向け）
• macOS の画面操作は Cursor Computer Use にアクセシビリティと画面収録を許可すると知っている（詳しい人向け）
• Team Pool は会社の Lambda / Cloudflare / Daytona などの上にも置けると知っている（詳しい人向け）
• 使っていない Team Pool の作業場は休眠できると知っている（詳しい人向け）
• 自前ワーカーでは個人用 Skill が届かず、リポジトリかイメージ焼き込みが必要だと知っている
• Tailscale の userspace networking では VM を tailnet の exit node にできないと知っている（詳しい人向け）
• AWS IAM 連携の STS 認証情報は1時間で失効し、Agent 再開時に自動更新されると知っている（詳しい人向け）
• AWS IAM ロール連携（CURSOR_AWS_ASSUME_IAM_ROLE_ARN）で長期の AWS キーを避けられる公式例があると知っている（詳しい人向け）
• Cloud Agent の MCP は HTTP / stdio のみで、SSE や mcp-remote は使えないと知っている
• Bugbot / Security Agents / PR Routing が Cursor 管理の Agent で、自作 Automations とは別だと知っている
• Cloud Agent Builds が起動前に install を済ませる仕組みだと知っている
• Update stale builds で main のコードの新しさを調整できると知っている
• Build 失敗時は Builds タブのログを見て、Agent 本体は成功 Build が使われ続けると知っている
• 環境や Secrets の保存で Build が走ることがあると知っている
• pre-warmed Build から ACT 2 に入ると起動が速く感じることがあると知っている
• Builds に Cloud Agent とは別の追加課金はないと知っている
• /search でレッスン見出し・用語・困ったとき索引を横断検索し、見出しヒットから該当節へ直接ジャンプできると知っている
• 学習ロードマップ（/learn）の「次にやる」と「済」で、自分がどこにいるか確認できる
• Automations の MCP は信頼できるサーバーだけ接続し、Prompt に品質バー（PR / コメント / 何もしない）を書ける
• GitHub Issue へのコメントだけをきっかけにするなら Issue comment トリガーを選べる
• Automations の Memories は、Slack / Webhook など信頼できない外部入力があるときはオフも検討できる
• iOS アプリの PR レビュー画面からレビュアーを追加・変更できると知っている
• PR の Deployments タブやモバイルレビューで、プレビュー・反映状態を確認できると知っている
• PR が behind のとき Update branch（ブランチ更新）で本線を取り込めると知っている
• コンフリクト表示のとき Agent に解消を依頼できると知っている
• マージボタンがグレーのとき、behind・コンフリクト・CI・承認・権限のどれを疑うか分かる
• Checks が緑でも、承認・保護・権限でマージできないことがあると知っている
• Checks の前に behind とコンフリクトを確認する順番を説明できる
• Update branch 後に Checks が再実行されて赤くなることがあると知っている
• レビューコメントの解決を PR コメントやモバイルから Agent に頼める
• 外出先から新しい Agent に赤い CI の調査だけを頼める（Fix with Agent とは別入口）と知っている
• CI が赤いとき、再実行・調査だけ・修正依頼の3択を選べる
• 会社で SSO が必須のとき、iOS アプリでも SSO 経由でサインインすると知っている
• iPhone の Live Activities と Dynamic Island で Agent の進捗を追えると知っている
• GitHub 接続済みなら Integrations の Manage Connections で保管庫を追加できると知っている
• 初回 Cloud Agent 利用時に spend limit を設定することがあると知っている
• Cloud Agent の課金は選択モデルの API 料金（従量）で計上されると知っている
• Cloud Agent は有料プラン（Start 以上）が前提だと知っている
• Start プランは Cloud Agent は使えるが、Bugbot / Automations / Cursor SDK / Auto は Pro 以上だと知っている
• Start の Cursor Models 枠は Fast なし・Grok の努力レベル固定だと知っている
• Teams / Enterprise では他社モデルに Cursor Token Rate が乗ると知っている
• Auto は Cursor が依頼ごとにモデルを選ぶ選び方だと知っている
• Cursor Router の Optimize For は Cost / Balance / Intelligence だと知っている
• Cursor Router が働くには Grok 4.6 が必要だと知っている
• Security Reviewer は PR 直前、Vulnerability Scanner は保管庫の定期スキャンだと知っている
• PR Routing は Bugbot / Security の指摘が人の確認を要する場合は自動承認しないと知っている
• 同じ PR で APPROVAL_POLICY.md を変えても、その PR の審査を甘くしないと知っている
• Bugbot と find bugs 系 Automation を同じ PR で重ねると指摘が重複すると知っている
• 従量課金の Bugbot では Effort（Low / Default / High / Smart）があると知っている
• PR の `@cursor remember` で Bugbot に約束を覚えさせられると知っている
• チームが JetBrains IDE なら ACP で Cursor の Agent を使えると知っている
• Subscriptions で PR レビューや CI を待って Agent に続けてもらえると知っている
• auto-merge（GitHub の自動反映）と Subscriptions（Agent の待ち再開）は別機能だと説明できる
• Subscriptions と auto-merge を組み合わせてマージまで任せる手順を説明できる
• GitHub の Subscriptions で1つの PR・保管庫全体・特定作者の PR を待てると知っている
• マージ任せレシピでは1 PR 指定の Subscriptions が安全だと知っている
• mcp_auth_error は MCP 認証失敗で、その MCP だけスキップされると知っている
• setup_failed は環境セットアップ失敗、pr_creation_failed は PR 作成失敗の公式イベントだと知っている
• artifact_created は成果物アップロード成功の公式イベントだと知っている
• pr_created は PR 作成成功、pr_creation_failed は PR 作成失敗の公式イベントだと知っている
• setup_started / setup_completed が揃えば仕事場の準備は成功したと知っている
• Builds タブの Skipped は変更なしの正常記録だと知っている
• Build trigger の4種類と、Skipped が Recurring だけであることを知っている
• Cursor Cloud MCP で Build ログを Agent に調べさせられると知っている
• request-environment-setup-actions でセットアップ待ちを記録できると知っている
• take-environment-snapshot で動いた環境を保存できると知っている
• check-environment-snapshot でスナップショット保存の完了を確認できると知っている
• run-info → get-events が Cursor Cloud MCP の診断の入口だと知っている
• batch-fetch-details の include_events で他の実行のイベントも調べられると知っている
• batch-fetch-details は1回最大50件まで、と知っている
• get-message-queue で未処理のフォローアップ待ちを確認できると知っている
• get-message-queue が空でも、Subscriptions の待ち条件が未達なら Agent は再開しないと知っている
• GitHub の CI 待ちは Checks が全部終わるまで1つの結果で、pending の Check が1つでも全体が届かないと知っている
• pending の Check は GitHub の action_required（要対応）で完了させると、待ちが進むと知っている
• list-cloud-agents で同じ環境の他の実行を Agent に一覧させられると知っている
• list-cloud-agents の archived フィルタでアーカイブ済み実行を除いて調べられると知っている
• OIDC トークンは Secrets に長期鍵を置かない代替で、メタデータは認証情報ではないと知っている
• agent/source と turn/model がエージェントメタデータで読めると知っている
• turn/id と agent/id（bcId）が別物だと知っている
• inbox の source: iosApp 表示と agent/source メタデータキーは別物だと知っている
• VM 内のエージェントメタデータと API/SDK の metadata タグは別物だと知っている
• turn/ 配下のメタデータはコーディングターン中だけ存在し、ターン間は消えると知っている
• モバイルアプリは cache-first で一度読んだ会話はオフラインでも開けると知っている
• setup_started のまま止まるとき、Secret 追加待ちを疑える
• Allow posting artifacts to GitHub で PR 説明文へ成果物を埋め込めると知っている
• Team Owned の Automation はサービスアカウント名義で動き、PR 作者が cursor になりうると知っている
• `/subscribe` や `/loop` で待ち条件を Agent に伝えられると知っている
• `/goal` で終わるまで追い続ける目標を渡せることを知っている
• CLI の Custom Mode は Enter が1通、⌥ Enter がピン留めだと知っている
• Desktop の Customize がプラグイン・Skill・MCP をまとめて扱う画面だと知っている
• Customize のチームリーダーボードからよく使うプラグインを1クリックで足せると知っている
• `/autopilot` で開いた PR の指摘・コンフリクト・Checks を見守って直せることを知っている
• `/cursor-blame` で AI の変更と依頼文を調べられることを知っている
• `/canvas` で会話の横に触って試せる見本を出せることを知っている
• Shared Canvases は Publish したリンクをコピーして渡し、ダッシュボードは自分の分だけだと知っている
• Canvas 上でも Design Mode で部品を選べると知っている
• Bugbot の Incremental Review がいまの既定で、前回からの差分だけを読むと知っている
• Bugbot Autofix は指摘を直す Cloud Agent で、CI の `@cursor autofix` とは別だと知っている
• Cursor Bugbot の Check は指摘があっても既定では中立だと知っている
• Bugbot の約束は `.cursor/BUGBOT.md` で、プロジェクト Rules（*.mdc）は効かないと知っている
• マージ前に `/review` でコードレビュー Agent を先に走らせられると知っている
• Desktop の手元変更を読むのは `/agent-review` で、PR の Bugbot とは別だと知っている
• `/review-bugbot` した同じ差分では保管庫側の Bugbot が再実行を飛ばすことがあると知っている
• 同じ型の Canvas 報告は Skill に欄と数字の取り方を書いて再現できると知っている
• ラフや構成図は画像生成、既存画像への印は Design Mode だと知っている
• Skill の `paths` で対象ファイルを絞れると知っている
• Allow Members to Publish がオフだと新規公開は管理者だけだと知っている
• プラグインの Canvas（Hex / Atlassian）が共有ひな型だと知っている
• Teams なら個人 Skill を marketplace へ Publish できると知っている
• Origin の Checks が古いままなら refresh を疑える
• Origin のプライバシーはコードベース名の持ち主の Privacy Mode に従うと知っている
• 作業中の追加指示は Send now / Enter 2回で、いまの一手を途中で止めないと知っている
• Desktop では Enter がキュー、Cmd+Enter（Windows は Ctrl+Enter）がすぐ送ると知っている
• Desktop のすぐ送りは直前の自分のメッセージに追記されると知っている
• CLI の Enter は舵切りで、Desktop の Enter（キュー）とは違うと知っている
• Desktop の Agent が外れたとき Checkpoints でファイルだけ戻せることを知っている
• Checkpoints は会話を消さず、Git のコミットとも別だと知っている
• CLI のメッセージ先頭 `&` で Cloud Agent へ引き継げると知っている
• CLI の `/sandbox` でコマンドを箱の中で走らせられると知っている
• CLI の sudo パスワードはモデルに見えないと知っている
• `agent persist` は手元で切断しても続ける起動で、クラウドへ渡す `&` とは別だと知っている
• 昨日の CLI 会話は `agent resume` か `agent ls` で履歴から開けると知っている
• CLI の会話が重いときは `/summarize` があると知っている
• CLI はプロジェクト直下の CLAUDE.md も Rules として読むと知っている
• 手元の枝を守りたいときは `--worktree` か `/worktree` だと知っている
• Desktop のコマンド確認は Run Modes（おすすめは Auto-review）だと知っている
• Ask Every Time は廃止され、空の Allowlist が同じ動きだと知っている
• Cloud Agent は Run Modes を使わず、コマンド承認は出ないと知っている
• 先に調べるなら Ask（Cloud なら調査だけ）、大きな仕事は Plan で計画を見てから作ると知っている
• 再現できるのに原因が分からないときは Debug Mode（Cloud なら再現手順つきの調査）だと知っている
• Cloud Agent には Debug Mode の画面が無く、再現手順つきの調査依頼で代用すると知っている
• Shift+Tab または `/plan` / `/ask` / `/debug` でモードを切り替えられると知っている
• 残りの利用量は cursor.com/dashboard/usage か CLI の `/usage` で見られると知っている
• 計画が外れたら Checkpoints で戻して Plan を直してから作り直すと知っている
• `.claude/skills/` や `.codex/skills/` も Cursor が読むと知っている
• 会話の Explore / Bash / Browser カードは設定不要のビルトインだと知っている
• 会話の Browser カードと Desktop の `@browser`、Cloud のコンピュータ操作は別だと知っている
• Linux の `--share-desktop` は見るだけ（view）か操作も渡す（view_and_control）だと知っている
• 子 Agent は既定では親と同じ作業コピーを共有し、隔離は『それぞれ別環境で』と頼むと知っている
• 手元会話を止めずに次の仕事だけクラウドへ渡すなら `/in-cloud` だと知っている
• 大きな仕事は左ナビの Projects（コーディネーター）に計画と振り分けを任せられると知っている
• Projects の公式の使い方は機能づくり・移行・日常の手入れだと知っている
• Projects は Automations や1つの Cloud Agent とは別物だと知っている
• GitHub がまだ無いときは Origin / Start from scratch から試作できると知っている
• Origin 上で作った保管庫の PR は Origin 側に出ると知っている
• Origin の Apps（Vercel / Depot / Buildkite）は Origin 上で作った保管庫向けだと知っている
• 製品名 Origin と git の origin と Origin CLI は別物だと知っている
• GitHub 同期の origin/ 枝は Origin 側だけで、GitHub の PR にならないと知っている
• GitHub 同期をやめるときは Detach from GitHub で、GitHub 側は消えないと知っている
• Origin 上の PR がマージできないときは Rules and Protections を疑える
• 保管庫の Settings とコードベース設定（Manage Apps）が別だと知っている
• Origin CLI の PR は既定が Draft で、確認後に Ready にすると知っている
• cursor.com/codebase で git なしに保管庫とコードを開けると知っている
• 来週まわす小さな改善テーマを1つ決められる