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