用語は、体験のあとに読むので大丈夫

設定・使い方

1. 入口: cursor.com/codebase で Get Started。コードベース名（URL の {owner}）を決める。チームなら誰でも申請でき、そのあと管理者が保管庫の作成権限を付ける（公式 Origin）
2. ベータ中はコードベース名をあとから変えられない（公式 Origin）
3. 対象プラン: Pro / Teams / Enterprise。無料プランは対象外。段階公開のため、画面に出ないこともある
4. Privacy Mode（Legacy）のままでは有効化できない。管理者がダッシュボードからオフにできる
5. Origin のプライバシーはコードベース名の持ち主（チームまたは個人）の Privacy Mode に従う。保管庫を開く人ごとではない（公式 Origin）
6. コードベース設定から、管理者以外もアクセスを依頼できる。Private に切り替えた人は自動で管理者権限が残る（公式 Origin settings / codebase-settings）
7. 製品名 Origin と、git のリモート名 origin（共有場所の通称）と、Origin CLI（コマンド origin）は別物。コマンドは自分で入れなくてよい（公式 Origin CLI / git）
8. Agent に『Origin に置いて』と頼むと、CLI の導入から保管庫作成・push まで任せられる（公式 Origin create-repository）
9. Origin 上で作った保管庫の PR は Origin 側。GitHub から同期した保管庫の PR は GitHub 側（公式 Origin integrations）
10. Apps: Vercel（公開とプレビュー）、Depot / Buildkite（CI）は Origin 上で作った保管庫向け。GitHub 同期の保管庫の CI は GitHub 側のまま（公式 Origin settings）
11. 保管庫の Settings は General / Permissions / Rules and Protections / Apps。Apps のインストールはコードベース設定の Manage Apps（公式 Origin settings / codebase-settings）
12. Origin 上の PR がマージできないときは Settings の Rules and Protections（GitHub のブランチ保護の対応。公式 Origin settings）
13. git なしでも cursor.com/codebase で保管庫とコードを開ける（Find repo...）。緑の Code から clone URL（公式 Origin）
14. GitHub 同期をやめて Origin を正本にするときは Settings → General の Detach from GitHub。GitHub 側の保管庫は消えない（公式 Origin mirror）

設定・使い方

1. clone URL の例: https://origin.cursor.com/{owner}/{repo}.git（公式 Origin git）
2. GitHub から同期した保管庫では、この URL への git push は GitHub へ届き、Origin は写しとして追従する（公式 Origin git / mirror）
3. Origin 上で作った保管庫なら、同じ URL への push は Origin が正本

設定・使い方

1. Agent に『Origin に置いて』と頼むと、導入・サインイン・保管庫作成・リモート設定・push まで進められる（公式 Origin CLI / create-repository）
2. 手元で入れるなら公式の install スクリプトのあと origin auth login。git の認証も一緒に用意される
3. origin コマンドが見つからないときは、PATH に ~/.local/bin が無いことが多い（公式 Origin CLI）
4. PR の作成・確認・マージも origin pr。CLI の既定は Draft。条件が揃ったらマージは origin pr merge --auto（GitHub の auto-merge と同じ役割）。はじめての方は Agent に任せる（公式 Origin CLI PR）
5. Checks が古い先頭コミットのままなら origin pr refresh。通常は push で新しい版が作られるので、画面が追いついていないときだけ（公式 Origin CLI PR）
6. Rules and Protections の一覧は origin ruleset list。はじめての方は画面の Settings タブで十分（公式 Origin CLI）

設定・使い方

1. GitHub が一時的に使えないときや、Origin 側だけに残したい状態向け（公式 Origin git / mirror）
2. 詳しい人が origin push local すると origin-local という送り先（...git/local）ができる。他の枝はこれまでどおり GitHub へ（公式 Origin CLI）
3. 普段の Cloud Agent の PR は普通の枝名。GitHub 側に同名の枝があっても Origin は取り込まない（上書き防止）

設定・使い方

1. cursor.com/agents の保管庫ピッカーで Start from scratch を選ぶ
2. 依頼を送ると、裏側で Origin リポジトリが作られる（公式 changelog 2026-08-27）
3. 気に入ったら Create repo で名前と公開範囲（Private / Internal）を決めて残す
4. 公開 URL が欲しいときは Vercel アカウントをつないで Publish（公式 changelog 2026-08-27）。継続的なプレビューは Origin の Apps タブの Vercel
5. Origin の画面が出ないときは、GitHub 接続の本線で進む

設定・使い方

1. PR 画面（または Cursor for iOS のレビュー画面）で auto-merge をオンにします
2. 条件（Checks・承認・behind なし・コンフリクトなしなど）が揃うまでマージは始まりません
3. Agent に『マージできるまで続けて』と頼むのは Subscriptions の話で、auto-merge とは別です
4. Origin 上で作った保管庫の PR では、同じ役割が条件が揃ったらマージ（origin pr merge --auto / Agent に『条件が揃ったらマージして』。公式 Origin CLI PR）

設定・使い方

1. GitHub では Organization / 保管庫のブランチ保護。Cursor アプリはルールを読んでマージ可否を判断する
2. Origin 上で作った保管庫では Settings → Rules and Protections（マージ時・push 時の ruleset。公式 Origin settings）

設定・使い方

1. 保管庫の Settings → Rules and Protections（ベータ中は画面のラベルが変わることがある。公式 Origin settings）
2. マージ時と push 時の ruleset がある。一覧は origin ruleset list。はじめての方は画面で十分（公式 Origin CLI）
3. GitHub から同期した保管庫の保護は GitHub 側のブランチ保護のまま

設定・使い方

1. はじめては Cloud machine。Team Pool は社内専用の作業場が必要なとき、管理者と検討する
2. 公式 Self-Hosted Machines: Team Pools は Enterprise。ワーカー認証はサービスアカウントの API キー
3. 画面に Team Pool が出ない／選べないときは、プランと管理者の Self-Hosted 許可を確認する
4. 会社がすでに Lambda / Cloudflare / Daytona / Modal / Namespace / Vercel / E2B / Tensorlake / Coder を使っているなら、その上に Team Pool の作業場を置ける（公式 Self-Hosted integrations）
5. Kubernetes の新規は anysphere/k8s-workers。待たせたくないときは --warm-idle で空き Pod を温めておける（詳しい人向け）。古い operator は非推奨
6. 使っていない作業場は休眠（hibernate）して、次の依頼で戻せる
7. 個人用 Skill は届かない。リポジトリの .cursor/skills/ か、ワーカーイメージへの焼き込み（公式 Agent Skills）

設定・使い方

1. Cloud Agent の画面確認は、隔離された作業用コンピュータのマウスとキーボードを使う（公式 capabilities）
2. Self-Hosted ではワーカー起動時に --computer-use。macOS は Cursor Computer Use にアクセシビリティと画面収録（Terminal や Cursor 本体ではない）
3. Linux の画面共有（--share-desktop）は見るだけ（view）か、マウスとキーボードも渡す（view_and_control、既定）。共有されるのはワーカーが作った隔離デスクトップ。クリップボードは渡らない（公式 computer use）
4. macOS 15 以降は画面収録の許可を定期的に聞き直すことがある。スクショが止まったらログイン画面の『1か月許可』を確認する
5. 会話の Browser カードはビルトインの子役。Desktop の @browser（エディタ内のブラウザ枠）とは別。Cloud の画面確認はコンピュータ操作

設定・使い方

1. チーム共有なら、リポジトリ直下に .cursor/hooks.json を置きます（Cloud Agent が拾うのはこちらです）
2. 個人用の ~/.cursor/hooks.json は手元の Desktop 向けです。Cloud Agent の VM には届きません
3. Enterprise では、ダッシュボードからチーム／組織向け Hooks も配布できます
4. Cloud Agent では、書き込み可能な環境になってから動きます（最初の読み取りだけの探索中は動きません）
5. Cloud Agent が使えるのは command-based（コマンド実行型）の Hooks だけです。prompt-based（プロンプト型）は Desktop 向けで、クラウド VM では動きません

設定・使い方

1. チームで共有するなら、リポジトリに .cursor/skills/{スキル名}/SKILL.md を置きます（個人用なら ~/.cursor/skills/）
2. ファイル先頭に name と description（いつ使うか）を書き、その下に手順を Markdown で書きます。name はフォルダ名と同じ（英小文字・数字・ハイフン）にしてください
3. 手早く作るなら、Agent チャットで /create-skill を使います。既存の Rules / スラッシュコマンドからなら /migrate-to-skills
4. 最初から入っている Skills の例: /autopilot（PR を見守って直す）、/cursor-blame（AI の変更理由を調べる）、/split-to-prs（大きな変更を小さな PR に分ける）、/canvas（会話の横に触って試せる画面を出す）、/review（合うコードレビュー Agent を選ぶ）、/shell（渡した文をそのままシェルで実行。コマンドを渡されたときだけ）（公式 Agent Skills）
5. Git にコミットして PR で入れると、Cloud Agent も含め同じリポジトリを触る Agent が使えます
6. 個人用の ~/.cursor/skills/ に置いた Skill も、Cursor に同期（synced）されていればモバイル起動や Cloud Agent から使えます（管理画面は Web 側）
7. 同期されるのは ~/.cursor/skills/ だけです。~/.agents/skills/ や未同期の手元 Skill は、Cloud Agent・Agents Window の Remote SSH・自前ワーカー（My Machines / Team Pool）にはコピーされません（公式 Agent Skills）
8. 互換のため .claude/skills/ と .codex/skills/（ホームの ~/.claude/skills/ / ~/.codex/skills/ も含む）も読み込みます。Claude や Codex 向けに置いた手順が、Cursor でも拾われやすいです（公式 Agent Skills）
9. 自前ワーカーで同じ手順を使いたいときは、リポジトリの .cursor/skills/ に置くか、ワーカーのイメージへ焼き込む（詳しい人向け）
10. Teams / Enterprise なら Customize → Skills から個人 Skill をチームの Default marketplace へ Publish できる。公開しても同僚は自分で入れる（作者には自動で付く）。自分の Cloud Agent だけなら同期で足りる（公式 Plugins）
11. 使うときはチャットで /スキル名 と入力するか、依頼内容が description に合うと Agent が自動で選びます
12. Desktop では、サイドバーの Customize → Skills で一覧を確認できます

設定・使い方

1. Slack: チャンネルで @Cursor 料金ページの誤字を直して のように依頼（Integrations で Slack 接続が必要）
2. Slack の便利オプション例: repo=組織/リポジトリ / env=環境名 / branch=dev / autopr=false（PR を自動作成しない） / model=opus
3. 同じスレッドへの @Cursor … は追記指示になります。別の新しい Agent なら @Cursor agent …
4. Microsoft Teams（チャットアプリ。Cursor の Teams プランとは別）: チャンネルで @Cursor に続けて依頼。Integrations で Connect が必要。repo= / env= / branch= / model= が使える。公式に Slack の autopr=false 相当は無いので、調査だけなら本文に『コード変更はまだしない』と書く
5. Microsoft Teams のチャンネルスレッドでは、同じスレッドへの @Cursor … が追記。個人チャットやグループチャットの続きは Open in Web / Open in Desktop
6. GitHub / Bitbucket: Issue や PR に @cursor この CI を直して とコメント
7. Linear: @cursor コマンド（Integrations で Linear 接続が必要）
8. GitLab / Azure DevOps: 公式の Cloud Agent 起動入口には PR コメントの @cursor はありません。cursor.com/agents（Web）や Desktop の Cloud、Slack、Microsoft Teams、API から起動します

設定・使い方

1. Dashboard → Cloud Agents の Routing Rules で、キーワードとリポジトリ（または環境名）を対応づける
2. 例: frontend → acme/web-app、platform → 複数リポジトリ入りの環境名
3. メッセージ内の明示指定（repo= / in リポジトリ名）が最優先。その次に最近使ったリポジトリ、Routing Rules、チャンネル既定、個人既定の順で選ばれやすい

設定・使い方

1. 初回起動時の案内に従って上限を設定します
2. 上限に達すると起動できなくなります。ダッシュボードの Cloud Agents 設定で見直せます
3. Automations も Cloud Agent として同じ枠を使うことがあります（権限設定により個人枠かチーム枠かが変わります）

設定・使い方

1. 課金画面とエディタ設定に、Cursor Models と Other Models の2枠が出ます。同じ2枠は cursor.com/dashboard/usage でも見えます（公式 Models & Pricing）
2. ターミナル（CLI）なら /usage で残量（Auto / API）、従量の上限、プラン名、課金サイクルのリセット日が出ます（公式 CLI changelog）
3. Start（インド向け）は Cursor Models のみ。Grok 4.6 / 4.5 / Composer 2.5 は高速モード（Fast）なし。Grok の努力レベルは medium 固定で変えられません
4. 他社モデルや Fast、努力レベルの変更が必要なら Pro 以上です
5. Teams / Enterprise で他社モデルを選ぶと、API 料金に加えて Cursor Token Rate が乗ります（この次の用語）

設定・使い方

1. 入力・出力・キャッシュ分にも乗る。Auto が他社モデルへ振り分けたときや BYOK も対象（公式 Team Pricing）
2. Grok / Composer など Cursor 側のモデルは免除。他社モデルの利用量が想定より多いときは、この追加分も疑う
3. はじめての方は『他社モデルは表示料金より少し高く見える』と覚えれば十分。詳細は管理者の利用ダッシュボード

設定・使い方

1. モデル選択で Auto を選ぶ。Start（インド向け）には Auto が無いので、Grok / Composer を直接選ぶ（公式 Models & Pricing）
2. Teams / Enterprise では Auto の裏側が Cursor Router。Optimize For で Cost / Balance / Intelligence を選ぶ（この次の用語）
3. 課金は振り分け先モデルの定価。他社モデルなら Cursor Token Rate も乗る（公式 Cursor Router / Models & Pricing）

設定・使い方

1. モデル選択で Auto を選び、Optimize For から Cost（トークン節約）/ Balance（質・速さ・コスト）/ Intelligence（難しい仕事向け）を選ぶ（公式 Cursor Router）
2. Balance と Intelligence は Cost より利用枠を速く使う。いつでも切り替えられる
3. いま公式では Teams / Enterprise 向け。Enterprise は既定オフで、管理者がダッシュボードから有効化する
4. 振り分けが働くには Cursor Grok 4.6 が必要。Grok 4.6 を止めると Router が動かないことがある。モデルを止めすぎると振り分けの質も落ちる（公式 Cursor Router）
5. 振り分け先のモデル名は既定で隠す。表示は管理者設定。詳しい人は turn/model（environments-and-secrets）

設定・使い方

1. 依頼文に『PR を出してレビューと CI が通るまで続けて』のように待ち条件を書くか、/subscribe スキルで何を待つか伝えます
2. 定期ループなら /loop スキルも使えます（公式のビルトイン Skills）
3. 購読は1つの Agent 会話に紐づき、最大180日です。複数イベントが続けて来たときは1回にまとめられて起動することもあります
4. GitHub では1 PR だけ・保管庫全体・特定作者の PR の3段階で待ちの幅を選べます。マージ任せでは1 PR 指定が安全です
5. CI 待ちは、そのコミットの Checks が全部終わるまで1つの結果です。テストが緑でも黄色（pending）の Check が1つあると全体が届かず、Agent は起きません。公式の対処は pending のままにせず、GitHub の action_required（要対応）で完了させることです
6. CI の自動修正（autofix）とは別枠です。GitHub / Slack / Linear / タイマーなど、より広いイベント待ちです

設定・使い方

1. cursor.com/agents の入力で /goal のあとに目標を書きます。例: /goal （ページ名）の文言と見切れを直し、プレビューで確認できるまで続けて
2. 公式の例は /goal fix all flaky tests and make CI green（フレークテストを全部直して CI を緑にする）
3. 手順をいつも守らせたいときは Custom Mode（Skill をピン留め）と、定期確認なら /loop と組み合わせられます。CLI の Enter は1通だけ、ピン留めは ⌥ Enter
4. イベント待ち（レビューや CI）は Subscriptions です。/goal は『終わるまで追い続ける』、Subscriptions は『きっかけが来るまで休む』
5. 開いた PR を見守って直してほしいときは /autopilot。日をまたぐ目標は /goal（公式 Agent Skills）
6. /goal は順次公開中です。入力に出ないときは、新しいチャットで試してください（公式 Agent overview）

設定・使い方

1. Desktop: / から Skill を選び、⌥ Enter か『Use as Mode』
2. CLI: Enter は今の1通に付けるだけ。ピン留めは ⌥ Enter（公式 CLI using）
3. 外すまで手順を守らせたいときに使う。1通だけなら Enter で十分

設定・使い方

1. Desktop のサイドバーから Customize を開く（公式 Customize）
2. 自分 / この作業場 / チームで絞り、Marketplace から入れる
3. チームのリーダーボード（よく使われているプラグイン・Skill・MCP）から1クリックで足せる
4. コミュニティのプラグインや MCP は cursor.directory

設定・使い方

1. チャットで /autopilot と打つか、『この PR を見守って直して』と頼む（公式 Agent Skills）
2. Subscriptions（イベント待ちで再開）や auto-merge（条件が揃ったら反映）とは別。/autopilot は Agent が直し続ける入口
3. 1通の小さな修正は5要素のまま。日をまたぐ目標は /goal。1回のチャットで終わらない機能づくりは Projects

設定・使い方

1. チャットで /cursor-blame と打ち、調べたいファイルや PR を伝える（公式 Agent Skills）
2. コードが読めなくても、『誰のどの依頼で入ったか』を先に把握してから、残す／戻すを決められる

設定・使い方

1. チャットで /canvas と打ち、『（機能名）の流れを触って試せる画面にして』と頼む。ダッシュボード・分析・監査・報告も向く（公式 Canvases / Agent Skills）
2. 開き方: 返信末尾のカード、コマンドパレットの Open Canvas、Agents Window の新しいタブ。ワークスペースの Canvas 一覧からも戻れる
3. コード変更の依頼ではなく、理解のための見本です。本番の画面を直したいときは、これまでどおり5要素で依頼します
4. 同僚に見せたいときは Shared Canvases（ツールバーの Publish → リンクをコピー）。ダッシュボードに出るのは自分の分だけ。プラグイン側の Hex / Atlassian Canvas とは別物です

設定・使い方

1. 『（ページ名）のボタン配置のラフ画像を作って。他ファイルは触らない』のように頼む（公式 Agent overview）
2. Design Mode は既存の画像やプレビューに印を付ける機能です。画像生成は新しい絵を作る側です
3. できた画像をそのまま本番に載せない。方向が合ってから、5要素で実装を依頼します

設定・使い方

1. Customize でプラグインを入れ、付属の Canvas を開く（公式 Plugins）
2. 例: Hex Canvas（データの可視化）、Atlassian Canvas（Jira / Confluence の Issue・プロジェクト・文書のリアルタイム表示）
3. 会話の横に自作の見本を出したいだけなら /canvas。自分の Canvas を同僚にリンクで渡すのは Shared Canvases（Publish → リンクをコピー）で、プラグインのひな型とは別です

設定・使い方

1. Canvas のツールバーで Publish（更新も同じ場所）。リンクをツールバーからコピーして、見てもらいたい人へ送る（公式 Canvases）
2. チームのメンバーならブラウザで開ける。閲覧は読み取り専用。ダッシュボードの Shared Canvases に出るのは自分が公開したものだけ。同僚の分はリンクをもらう
3. 有料プラン（Pro / Teams / Enterprise）かつチーム所属が必要。Free は共有を作れない。Pro でもチームに入っていれば共有できる
4. データ保存を許す Privacy Mode が必要。Privacy Mode（Legacy）では共有できない。管理者はチーム設定の Shared Canvases でオフにできる
5. 共有リンクはブラウザで全画面表示できる（公式 changelog Canvas Design Mode）。見せるときは全画面が向く

設定・使い方

1. cursor.com/agents で、作業中に追加文を書いて Send now（または Enter を2回）
2. いまのターンが終わってから読ませたいときは Tab でキューに入れます
3. Desktop のエディタ側では Enter がキュー、Cmd+Enter（Windows は Ctrl+Enter）がすぐ送る。すぐ送ると直前の自分のメッセージに追記されます（公式 Agent overview）
4. Agents Window にも順次公開。CLI では Enter で舵を切り、もう一度 Enter でターンを止めます

設定・使い方

1. 既定は共有。同じファイルを同時に直すと上書きしやすい（公式 Subagents）
2. 依頼例: 『バグ探しのサブエージェントを複数、それぞれ別環境で走らせて』
3. iOS では子の会話がサブエージェントカードとして出ます。Explore / Bash / Browser は設定不要のビルトイン

設定・使い方

1. カードが出ても自分で作った子ではありません。Agent が必要と判断したときに自動で使います（公式 Subagents）
2. ページ確認を自分で頼むなら Desktop は @browser。Cloud Agent の画面確認はコンピュータ操作（公式 Browser / capabilities）
3. iOS ではサブエージェントカードをタップして子の会話を追えます
4. 自分で役割を分けたいときは /create-subagent（.cursor/agents/）

設定・使い方

1. Agents Window で /in-cloud と打ってから、次の依頼を送る
2. 開いた PR をクラウド側で見守るなら /autopilot でもクラウドの子が動けます
3. クラウドの子が使う MCP は cursor.com/agents のチーム設定。手元の MCP ではありません（公式 Subagents）

設定・使い方

1. 左ナビの Projects から開く（ベータ。段階公開のため、すぐ出ないこともある）
2. 向く仕事: 機能づくり、移行、品質やバグ報告の日常の手入れ。向かない仕事: 1通で終わる小さな修正
3. コーディネーターはクラウドのコンピュータで動くので、ノート PC を閉じても進む（公式 changelog / ブログ 2026-09-10）
4. 手元のテストが必要なときだけ、コーディネーターが Local Agent を起動する
5. 共有のファイルに調査結果や『こう直す』の学びが残り、次の Agent も同じやり方を使える
6. Slack チャンネル監視・予定・PR フォローもコーディネーターに頼める（1つの Agent の Subscriptions や Automations とは別物）

設定・使い方

1. ダッシュボードの実行画面やイベント一覧で mcp_auth_error を確認します
2. Integrations で該当 MCP を再接続するか、起動時の MCP 選択から外します
3. 不要な MCP は Automation の Tools からオフにすると、再発を防げます

設定・使い方

1. ダッシュボードの実行イベントで setup_started を確認します
2. このあと setup_completed か setup_failed が続くのを待ちます
3. 長く止まるときは Builds タブや setup ログを開きます

設定・使い方

1. ダッシュボードの実行イベントで setup_completed を確認します
2. setup_started と揃っていれば、install / start の準備は通過しています
3. このあと PR や成果物のイベント（pr_created / artifact_created など）を見ます

設定・使い方

1. ダッシュボードの実行画面で setup_failed を確認します
2. 同じ画面または Builds タブで setup ログを開き、install や start コマンドのエラーを探します
3. 直せないときは、詳しい人に『setup_failed が出た。ログは（実行 URL）』と伝えます

設定・使い方

1. ダッシュボードの実行画面で pr_creation_failed を確認します
2. GitHub 連携の権限（PR write）とブランチ保護、対象ブランチ名を確認します
3. 会話の要約や差分は残っていることが多いので、手動で PR を作るか、権限修正後に Agent に再依頼します

設定・使い方

1. ダッシュボードの実行イベントで artifact_created が出ているか確認します
2. 出ていれば Agent 画面の成果物欄や PR の説明文（設定次第）を開きます
3. 出ていなければ、環境不足・ネットワーク制限・依頼に『スクショを残して』が無い、を疑います

設定・使い方

1. cursor.com/dashboard/cloud-agents の My pull requests 付近でオンにします
2. PR だけを見るレビュー担当向けです。Agent 画面には元から出ます
3. 埋め込まれた画像は公開 URL になるので、秘密情報が写っていないか確認してからオンにします

設定・使い方

1. Builds タブで各 Build の種類列を確認します
2. Skipped が出るのは Recurring だけです（変更が無い定期チェック）
3. 手動の Trigger build は Manual として必ず install が走ります

設定・使い方

1. ダッシュボードの実行イベントや会話で、セットアップ待ちのメッセージが出ていないか確認します
2. Secret 名だけを伝え、値は別経路で管理者に渡します
3. 対応後は新しい Agent 実行を始めるか、Agent に続きを頼みます

設定・使い方

1. 環境直しの依頼に『動いたらスナップショットを保存して』と書きます
2. check-environment-snapshot で保存完了を確認する流れも公式にあります
3. 普段は詳しい人や Agent 主導セットアップが担当し、自分で道具名を覚える必要はありません

設定・使い方

1. スナップショット保存を頼んだあと、完了まで待つ必要があるときに Agent が使います
2. 自分で道具名を覚える必要はなく、『保存が終わったか確認して』と伝えれば十分です

設定・使い方

1. Automation の実行 URL やログに automation ID があるとき、詳しい人が診断に使います
2. はじめての方は、実行 URL と『いつ・何を期待したか』を伝えるだけで十分です

設定・使い方

1. 環境や Build のトラブル時に、Agent に『run-info でいまの実行を確認して』と頼めます
2. 画面に cursor-cloud-run-info のように接頭辞が付くことがありますが、同じ道具です
3. 自分で道具名を覚える必要はなく、実行 URL と症状を伝えれば十分です

設定・使い方

1. 会話の要約だけでは分からないとき、run-info のあとに get-events を使う流れが公式です
2. setup_started のまま止まる・PR が無い・成果物が無い、などの切り分けに使います
3. 実行イベントの節とセットで読むと分かりやすいです

設定・使い方

1. Automations や Subscriptions で『待っているのに動かない』とき、キューに残っているかを調べる道具です
2. いま実行中のメッセージはキューに含まれません。待ち行列のスナップショットなので、時点によっては空のこともあります
3. キューが空なのに再開しないときは、CI が赤い・Checks が黄色（pending）・レビュー未承認など『待ち条件がまだ満たされていない』ことが多いです。pending の Check は GitHub の action_required（要対応）で完了させる公式の対処があります（follow-up-loop の Subscriptions 節）
4. run-info → get-events のあと、フォローアップ待ちの切り分けに使う、と覚えれば十分です

設定・使い方

1. Teams 向けの自動追従（autofix）を、自分の Agent 全体で止めたいときにオフにします
2. 1 PR だけ止めるなら @cursor autofix off、再開は @cursor autofix on でも切り替えられます
3. 個人プランでは自動追従自体がまだ使えないことがあります。そのときは Subscriptions や PR コメントでの明示依頼が代替です
4. 自動追従しない典型例: 人が後から push、あなたが追加メッセージを送った、base でも同じ Check が赤、同じ PR で10回に達した

設定・使い方

1. include_events を付けると、他の実行のダッシュボードイベントもまとめて見られます
2. コードを変えたか・PR を開いたかなどの差分メタデータも取れる、と公式にあります
3. 1回の呼び出しで最大50件まで、と公式にあります。それ以上はページングが必要です
4. 一般メンバーは自分の実行中心。チーム管理者は権限のある範囲で他メンバーの実行も見られます

設定・使い方

1. 公式の診断の流れでは run-info → get-events → environment-info のあとに使います
2. 起動元・状態・日付・コード変更の有無・PR 作成の有無・アーカイブ済みかなどで絞れる、と公式にあります
3. 一般メンバーは自分の実行中心。詳しい人が『同じ環境で他に失敗実行はある？』と調べるときに使います

設定・使い方

1. はじめての方は名前だけ知れば十分です。『長期の API キーを Secrets に置きたくない』とき詳しい人へ相談のきっかけになります
2. Agent に『OIDC トークンの公式手順に従って AWS に接続して』と頼む流れも公式にあります
3. トークンは約5分で失効します。メタデータを認証情報として転送しない、という公式の注意があります
4. AWS 以外にも GCP Workload Identity Federation、Azure 連携、Vault など OIDC 対応の検証先で使えます

設定・使い方

1. team follow-ups で『所有者』と『このターンを送った人』が違うことがあります。turn/user-id と owner/user-id を比べる用途が公式例にあります
2. turn/id はいまのコーディングターンの ID で、agent/id（bcId）とは別物です
3. turn/model はこのターンで実際に動いたモデル名です（Auto を選んでも、実際に動いた名前が入ります）
4. turn/started-at はターン開始の Unix 秒です。turn/ 配下はコーディングターン中だけ存在し、ターン間は消えます（404）。Hooks ではターン中だけ読み、ターンをまたいでキャッシュしないでください
5. agent/source は WEBSITE / API / SLACK / AUTOMATIONS など、メタデータ API の起動元です（モバイル inbox の source: iosApp 表示とは別の公式キー）
6. agent/name はダッシュボード表示名、agent/runtime は Cursor 管理 VM では常に managed です
7. owner/service-account-id は Team Owned の Automation など、サービスアカウント名義のときに入ります。owner/team-id は所有チーム ID です
8. workspace/automation-id は agent/source が AUTOMATIONS のとき、どの Automation かを示します
9. workspace/repo-urls は主リポジトリが先頭で、残りはソートされた複数行の一覧です
10. OIDC トークンと同じローカルソケットから読みます。メタデータを鍵の代わりに使わない、と公式は注意しています
11. 403 は致命的（再試行しない）、429 / 503（saturated）/ 500 / 502 / 504 は Retry-After を見てバックオフ再試行（429 は1分120回・20件までのバースト上限あり。ソケット同時接続は最大8）。起動直後にソケットが無いときも再接続を試します
12. owner/user-email と turn/user-email も読めますが、許可リストには変わりにくい owner/user-id を使うのが公式の推奨です
13. ソケットに届くプロセスは全キーを読めるので、メタデータを秘密情報の代わりにしないでください
14. Cloud Agents API や SDK で外から付ける metadata タグとは別物です（VM 内の実行メタデータ）
15. プレビュー段階の公式機能です。はじめての方は詳しい人が Hooks を書くときの話として知れば十分です

設定・使い方

1. ダッシュボードの実行イベントで pr_created を確認します
2. 出ていれば GitHub / スマホの PR 一覧を開きます
3. 出ていなければ pr_creation_failed や会話の要約を見て、手動 PR も検討します

設定・使い方

1. Team Owned に昇格すると、実行の『だれ』が個人からサービスアカウントへ変わります
2. Webhook の API キー再発行や、個人 OAuth の MCP をサービスアカウント向けに付け替える必要がよくあります
3. Cursor Cloud MCP でも、サービスアカウントは一般メンバーと同じ閲覧ルール（自分の実行中心）に従います

設定・使い方

1. Desktop や Agent の入力で /automate と打ち、続けて『毎週月曜に変更要約を Slack へ』のように書きます
2. 出てきた Trigger / Prompt / Tools を確認し、cursor.com/automations で保存して有効化します
3. コードを直す自動化なら、リポジトリ範囲を忘れずに指定します

設定・使い方

1. cursor.com/automations の Bugbot から保管庫ごとに有効化する。PR コメントで cursor review または bugbot run でも手動起動できる
2. 既定は Incremental Review（前回の Bugbot レビューからの差分だけ）。フル差分に戻すときは Bugbot Automations でオフ（公式 Bugbot）
3. push する前にチャットで /review または /review-bugbot を走らせると、同じ観点を先に確認できる。同じ差分のまま PR を出すと、保管庫側の Bugbot は再実行を飛ばすことがある（Cursor 3.7+ / cursor.com/agents。CLI は公式では準備中）
4. Cloud Agent は Start でも使えるが、Bugbot / Automations / Cursor SDK は Pro 以上（公式 Models & Pricing。Start はインド向け）

設定・使い方

1. チャットで /agent-review。または Source Control タブから本線との差分全体を読む（公式 Agent Review）
2. 設定: Cursor Settings → Agents → Agent Review。Cursor 3.11 以降は Git & PRs → Pull Requests に移る
3. 自動（コミットのたび）か手動。深さは Quick（速さ）と Deep（複雑な変更）。.cursor/BUGBOT.md は読む。プロジェクト Rules（*.mdc）は効かない

設定・使い方

1. Agent が大きな変更をする前に自動で作られます（公式 Agent overview）
2. チャットのタイムラインの Checkpoints を開いて中身を見てから Restore。直前の依頼の Restore Checkpoint、またはメッセージにカーソルを載せた + からも戻せます
3. 戻るのはファイルだけです。会話のメッセージは消えません。恒久的な履歴は Git / PR 側です
4. Cloud Agent の『戻して』依頼や PR の差し戻しとは別。手元 Desktop 向けです（when-desktop）

設定・使い方

1. チャット入力で Shift+Tab を押して Plan にする。または /plan。CLI は --plan / --mode=plan（公式 Plan Mode / CLI）
2. 流れ: 確認の質問 → 保管庫を調べる → 計画 → あなたが直す → 作る。複雑な依頼では Plan を勧めてくることもある
3. 計画は既定ではホームに保存。チームで残すなら Save to workspace。外れたら追記で継ぎ足すより、戻して計画を直してやり直す（公式 Plan Mode）
4. Cloud Agent に Plan ボタンが無いときは『まず計画を出して。実装は OK と言ってから』（prompting）

設定・使い方

1. チャット入力で Shift+Tab を Ask まで回す。または /ask。CLI は --mode=ask（公式 CLI）
2. Cloud Agent（ブラウザ / スマホ）に Ask が無いときは、調査だけテンプレや Slack の autopr=false（prompting）

設定・使い方

1. Desktop はモード選択か Shift+Tab。チャット / CLI は /debug（公式 Debug Mode / CLI）
2. 症状・期待と実際・再現手順を書く。Agent が出した手順どおりに再現する。必要なら何度か試す
3. ログは手元の Cursor 拡張のデバッグサーバーへ送る。ブラウザ / スマホの Cloud Agent には同じ画面は無い（prompting の Debug 節）

設定・使い方

1. チャットで /sandbox を開くか、起動時に --sandbox enabled / disabled（公式 CLI overview）
2. 箱の中のネットワークは、許可した先以外には出にくい公式の動きです
3. sudo が必要なときは伏せ字のパスワード入力が出ます。パスワードは sudo へ直接渡り、モデルには見えません

設定・使い方

1. agent persist で開始。離れるときは /detach。戻るときは agent persist attach（公式 CLI changelog）
2. 一覧は agent persist list、止めるときは agent persist stop。persist の実行の中で前の会話を続けるなら agent persist --resume
3. ターミナルを閉じて終わった会話を履歴から開くのは agent resume / agent ls（用語: agent resume）
4. 席を離れてクラウド VM で続けたいときは、メッセージ先頭の &（first-cloud-agent）

設定・使い方

1. CLI は agent --worktree（省略形 -w）。置き場は ~/.cursor/worktrees/（公式 CLI using）
2. Desktop は Agents Window で worktree に入れるか、チャットの /worktree。取り込みは /apply-worktree、不要なら /delete-worktree
3. 複数モデルを同時に試す /best-of-n も、それぞれ別の worktree。セットアップは .cursor/worktrees.json。信頼していない作業場ではセットアップは走らない（公式 Worktrees / CLI changelog）

設定・使い方

1. いちばん新しい会話は agent resume、起動時の --continue、チャットの /resume（公式 CLI using）
2. 一覧から選ぶなら agent ls。既定はすべての作業場。Left/Right でこの作業場だけに切り替え
3. 特定の会話は --resume チャットID。persist の実行を切断しても続けるのは agent persist

設定・使い方

1. チャットで /summarize（公式 CLI using / slash commands）
2. 別の方針を試したいときは /fork（別名 /branch /duplicate）で会話のコピーを作る

設定・使い方

1. リポジトリ直下に CLAUDE.md があれば CLI が読む（公式 CLI using）
2. Cloud Agent 向けの起動手順はこれまでどおり AGENTS.md。方針・禁止は .cursor/rules

設定・使い方

1. Cursor Settings → Agents → Approvals & Execution（公式 Run Modes）
2. 迷ったら Auto-review。全部任せる Run Everything はリスクを承知したときだけ
3. Cloud Agent（ブラウザ / スマホ）は専用 VM なので Run Modes は使わない。コマンド承認は出ない

設定・使い方

1. Settings → Agents → Approvals & Execution で Auto-review（公式 Run Modes）
2. いつも確認してほしい操作は Agent に頼むと permissions.json に日本語で書いてくれる
3. 分類に使う小さなモデル（Claude 4.5 Haiku または GPT-5.4 Mini）がチームで全部止められているとグレーアウトし、Allowlist になる

設定・使い方

1. 既定はオン。フル差分に戻すときは cursor.com/automations の Bugbot で Incremental Review をオフ
2. 同じ指摘が続くときは、既存の PR コメントを読む公式の動きも確認する。オフにしていないのに全体を読むなら、前回レビューが無い初回 push のことが多い

設定・使い方

1. Bugbot Automations で Autofix を設定。個人設定はチーム既定より優先（公式 Bugbot）
2. おすすめは新しい枝へ直す。既存の PR 枝へ直接入れる設定もある（同じ PR で最大3回）
3. 従量課金がオンで、Privacy Mode（Legacy）ではないことが必要。GitHub には Cursor Bugbot Autofix という別の Check が出ることがある

設定・使い方

1. リポジトリ直下に .cursor/BUGBOT.md を置く（常に読む）。変更したファイルの親フォルダにある同名ファイルも足される（公式 Bugbot）
2. どのルールが使われたか見るときは、PR に cursor review verbose=true または bugbot run verbose=true
3. チームの約束を覚えさせたいときは、PR に @cursor remember （覚えさせたいこと）。学習したルールとして以降のレビューに入る（公式 Bugbot）

設定・使い方

1. 従量課金の Bugbot プランだけで選べる（公式 Bugbot）。取りこぼしが多いときは High、速さや費用を優先するときは Low / Default
2. Smart は『いつ Low / Default / High にするか』を文章で書いて、状況に合わせて切り替える

設定・使い方

1. cursor.com/automations の Security Agents から設定。課金はチームの利用プール（個人枠は消費しない）。Teams / Enterprise 向け（公式 Security Agents）
2. Security Reviewer は PR / MR のきっかけ。Vulnerability Scanner は予定（cron）。どちらも内蔵チェックのオン／オフと、少なくとも1つの Tool / MCP が必要
3. push 前に自分で先に読んでもらうなら /review-security（または /review）。Cursor 3.7+ と cursor.com/agents。CLI は公式では準備中

設定・使い方

1. cursor.com/automations の PR Routing & Approval から設定。レビュアー指名と自動承認は別スイッチ（公式 PR Routing & Approval）
2. Bugbot Review Context / Security Review Context をオンにすると、その Check の終わりを待ってから判断する。指摘が人の確認を要する場合は承認しない
3. フォルダごとの約束は APPROVAL_POLICY.md。全体の回し方は .cursor/approval-policies/ROUTING.md（詳しい人向け）
4. 同じ PR で APPROVAL_POLICY.md や ROUTING.md を変えても、その PR の審査を甘くする材料には使わない。本線の版を見るか、人の確認にする（公式 PR Routing & Approval）

設定・使い方

1. Automations の Tools で Request reviewers をオンにする
2. Prompt に『差分の（領域）に詳しい人を指名して』など、指名の基準を書く
3. GitHub 上では cursor 名義でレビュアー指名が行われます

設定・使い方

1. cursor.com/automations で Automation を作成し、Trigger に Pull request approved を選ぶ
2. GitHub だけを使うチームなら PR review submitted を使い、GitLab / Bitbucket では approved を選ぶ
3. 承認後にだけ動かしたい後続処理（Slack 通知、追加チェックなど）向け

設定・使い方

1. 閲覧の前提: 起動した Cursor チームのメンバーに見える ＋ 相手自身の Integrations 接続 ＋ そのリポジトリへの権限（チームのメンバーであるだけでは開けない。複数チームにいるときは起動時のチームと相手のワークスペースが一致しているか確認）
2. 追記の許可: ダッシュボードの Cloud Agents セキュリティで、無効 / サービスアカウントのみ / 全員
3. 『全員』は他人の Secrets で動く Agent に指示できる設定なので、慎重に選びます

設定・使い方

1. リポジトリ直下（またはサブフォルダ）に AGENTS.md を置きます
2. 見出し例: Cursor Cloud specific instructions（起動コマンド、確認手順、触ってほしくない範囲）
3. 長くなりすぎたら、詳細は別ファイルへリンクする形でも大丈夫です
4. Rules（いつも守る約束）と併用できます。手順の『やり方』は AGENTS.md、方針は Rules、と分けるチームもあります

設定・使い方

1. Cloud Agents ダッシュボードまたは Desktop の Agents Window でガイド付きセットアップを開始します
2. GitHub / GitLab / Azure DevOps / Bitbucket を接続し、対象リポジトリを選びます
3. install に必要な Secrets の名前だけを渡します（値はチャットに書かない）
4. Agent が動いているあいだ、共有ターミナルで install の進捗を見られます（公式）
5. 検証と Build が成功したら環境を保存し、できれば .cursor/environment.json をリポジトリへコミットします

設定・使い方

1. Agent 主導セットアップのあと、ダッシュボードでスナップショット保存を選べます
2. 長期間使わないと期限切れになることがあります。そのときは既定の土台に戻り、警告付きで起動することがあります
3. 戻したい版があるときは、環境の Version history から復元します（自動では古い版に切り替わりません）

設定・使い方

1. Cloud Agents ダッシュボード → Environments → 対象環境 → Builds タブで履歴とログを確認します
2. 新しい環境は Builds が既定でオンです。古い環境は Enable Builds または Run setup agent から有効化できます
3. 新しい Build が失敗しても、最後に成功した Build が使われ続けます（公式）
4. install / start / terminals の3種コマンドの役割分担は、実行環境レッスンの Builds 節を参照してください
5. main のコードの新しさは Builds タブの Update stale builds と Staleness threshold（既定24時間）で調整できます
6. Build が失敗したときは Builds タブでログを開き、必要なら失敗した Build から Agent を起動して再現できます（Agent 本体は最後に成功した Build を使い続けます）
7. 環境設定や Secrets を変えると新しい Build が走ることがあります。Builds タブで Trigger build / Test build、進行中のキャンセル、特定 Build からの Agent 起動も選べます
8. 有効（active）な Build は pre-warmed コピーで待機し、毎回 clone と install から始めにくくなる（公式）
9. Builds 自体に追加課金はなく、Cloud Agent の利用に含まれる（公式）

設定・使い方

1. Dashboard → Integrations（Teams / Enterprise）で保護する範囲を追加・解除します
2. 設定できるのは、Cursor のチーム管理者 かつ Git 側の owner / admin です
3. 個人のリポジトリ権限があっても、保護された Organization は許可された Cursor 組織以外からは使えません
4. はじめての方は、設定そのものより『閉じたい Organization 名』を管理者に伝える役割です

設定・使い方

1. GitHub Organization → Settings → Security → IP allow list settings でチェックをオン
2. Cursor の GitHub アプリが Organization の IP 制限でブロックされているときの第一候補です
3. 使えない場合は、公式の接続用 IP をリストへ足す方法もあります（詳しい人向け）

設定・使い方

1. Cloud Agents ダッシュボードの Secrets で種類を選びます
2. API キーやトークン → Runtime Secret（旧称 Redacted Secrets）
3. 公開 URL やフラグなど、Agent に読ませてよい設定 → Environment Variable
4. Dockerfile のビルド時だけ必要な鍵 → Build Secret（実行中の Agent には渡りません）
5. 注意: Runtime Secret でも、リモートデスクトップの Terminal からは見えることがあります

設定・使い方

1. チーム管理者向け: Dashboard の Rules / Commands / Hooks で追加します
2. 効く範囲: チームメンバーの全リポジトリ（組織の共通トーンや禁止事項向け）
3. プロジェクト固有の約束はリポジトリの .cursor/rules/*.mdc へ。自分だけの好みは個人 Rules へ

設定・使い方

1. 特別な設定は不要です。Cloud Agent のコミットは自動で署名されます
2. ブランチ保護で『署名必須』でも、Agent の PR はそのまま満たせます
3. 人が手元で作った未署名コミットとは別物です

設定・使い方

1. 会話履歴: 既定は無期限（見返し・再開のため）
2. 環境スナップショット: 未使用が90日続くと自動削除（起動・再開で期限が延びる）
3. Enterprise: チーム設定で会話を90日上限にできる場合あり（早期アクセス）
4. 会話の明示削除は Delete Agent API など。スナップショットはオンデマンド削除ではなく90日ルール