アカウントと接続を用意する

最低限そろえるもの

ブラウザ / スマホだけで進める場合でも、次のものは必要です。会社の環境では、管理者に「Cursor の Cloud Agent を使いたい」と伝えて、代行してもらう場面もあります。

• Cursor アカウント（Cloud Agent が使えるプラン）
• 既存のプロジェクトなら GitHub アカウント（または会社が指定する GitHub Organization への招待）と、その保管庫を開ける権限
• GitHub がまだ無い／試作から始めたいなら Origin（Cursor の保管場所。早期ベータ）。保管庫ピッカーの Start from scratch から試せます
• 入口: Web なら cursor.com/agents。iPhone なら Cursor アプリ（iOS 26 以降、いまは英語表示）。Android は Web（必要なら PWA）

チームで初めて使うとき（管理者向け）

公式では、リポジトリから Cloud Agent を起動する前に、Cursor のチーム管理者が GitHub / GitLab / Bitbucket / Azure DevOps などのソース管理を Connect しておく必要があります。メンバー各自が GitHub にログインしているだけでは、組織の保管庫で Agent が動かないことがあります。

github.com 上の Organization 保管庫を使うとき、Connect 作業には Cursor のチーム管理者と GitHub Organization の管理者の両方が関わることが多いです（公式 GitHub 連携手順）。

はじめての方の役割は、『Cloud Agent を使いたいので、管理者に Integrations の Connect をお願いする』ことです。自分用の個人リポジトリだけなら、自分で Connect すれば足りることも多いです。

なぜ GitHub が出てくるのか

既存のプロジェクトを直すとき、Cloud Agent は接続されたソース管理上の保管庫をコピーして作業します。多くのチームではその置き場が GitHub です（公式には GitLab、Bitbucket Cloud、Azure DevOps なども選べます）。

Git コマンドを打てなくても、共有の置き場にプロジェクトがあること、Cursor がそのプロジェクトに入れることは必須です。会社の保管庫では、管理者がソース管理を先につないでないと、誰も Cloud Agent を起動できません。

まだ GitHub が無い、または試作だけ始めたいときは、GitHub 接続なしでも Cloud Agent を起動できます。保管庫ピッカーの Start from scratch（ゼロから始める）と、Cursor の Origin が公式の道です（くわしくはこのレッスン末尾の Origin 節）。

Cursor の GitHub アプリは、保管庫の読み取り、Pull Request の作成、Issue やレビューコメント、Checks（CI の結果）、Actions（ワークフローの状態や再実行）、ブランチ保護ルールの参照（本線へ入れる前に必要なレビューや Check を読み取る）、カスタムリポジトリロール（マージやレビュー選択の出し分け）、Organization のカスタムプロパティ（メタデータ）など、Agent と Bugbot が動くために必要な権限だけを公式が説明しています。はじめての方は『コードをコピーして PR を出す道具』と覚えれば十分です。

GitHub.com で IP 制限を使っているとき

会社が GitHub Organization の IP 許可リスト（allow list）でリポジトリへのアクセスを絞っている場合、Cursor の GitHub アプリが届くよう、管理者が GitHub 側で『インストール済み GitHub Apps による IP 許可リスト設定を有効にする』（Enable IP allow list configuration for installed GitHub Apps）をオンにするのが公式の推奨です。

設定場所の例: GitHub Organization → Settings → Security → IP allow list settings → 上記チェックをオン。Cursor GitHub アプリ側に IP リストが組み込まれており、Cursor が更新すると Organization 側も追従しやすい、という公式の説明です。

IdP 由来の allow list などで上記が使えないときは、公式の接続用 IP をリストへ足す方法もあります。その場合、git 用 egress プロキシを Cursor 側で有効化する必要があることがあり、Enterprise 向けのホスト型 egress を使うチームは利用開始前に Cursor 側（hi@cursor.com）へ依頼が必要です（詳しい人向け）。

はじめての方の役割は、『Cloud Agent 用に Cursor の GitHub 連携が IP 制限でブロックされていないか』を管理者に確認してもらうことです。社内 GitHub Enterprise Server とは別の話です（GHES は別節を参照）。

権限でつまずいたときの見方

「Agent がリポジトリに入れない」「PR を作れない」ときは、だいたい権限か接続の問題です。コードの才能の問題ではないので、安心してください。

• 自分はそのリポジトリのメンバーか
• Cursor の GitHub アプリがそのリポジトリにインストールされているか
• 会社の SSO / 二要素認証の設定を済ませているか
• Organization 単位のインストールなら、GitHub の Organization 設定で Cursor アプリが見えるか（見えなければ github.com/apps/cursor から再インストール）
• 接続をやり直すときは cursor.com/dashboard/integrations の Disconnect Account から切り離し、あらためて Connect する
• clone はできるのに PR だけ Permission denied → Cursor アプリに Pull Request への write があるか、ブランチ保護で阻まれていないか（公式 GitHub 連携のトラブルシュート）
• マージや Approve の選択肢が想定と違う → 会社の GitHub カスタムリポジトリロールやブランチ保護の影響かもしれない（Cursor アプリは custom repository roles を参照して表示を決めます）
• Organization で定義したカスタムプロパティ（custom properties）がある → Cursor アプリは Organization のメタデータも参照し、フィルタや表示に使うことがあります（詳しい人向け）
• サブモジュールなど依存する別保管庫がある → その保管庫にも読み書き権限が必要です。Selected repositories では依存先の選び忘れに注意（repository レッスン）

『起動できない』ときの別チェック

接続はできているのに起動できないときは、次も疑います。ここも才能の問題ではなく、設定のスイッチが多いだけです。

• Cloud Agent が使える有料プランか（公式トラブルシュート: 無料プランだけでは起動できないことがある。Start / Pro など。Start はインド向けで Cloud Agent は使えるが、Bugbot / Automations / Cursor SDK / Auto は Pro 以上。Start の Cursor Models 枠は Grok 4.6 / 4.5 / Composer 2.5 のみで、高速モード（Fast）と Grok の努力レベル変更はできない。他社モデル用の Other Models 枠もない。公式 Models & Pricing）
• 課金は選択したモデルの API 料金（従量）で計上される。初回利用時に設定する利用上限（spend limit）を超えていないか。残量はエディタ設定と cursor.com/dashboard/usage の2枠（Cursor Models / Other Models）。CLI なら `/usage` で残量・プラン名・課金サイクルのリセット日も見える（公式 Models & Pricing / CLI changelog）
• Teams / Enterprise で他社モデルを選ぶと、API 料金に加えて Cursor Token Rate（100万トークンあたり $0.25）が乗る。Grok / Composer は対象外。Auto が他社モデルへ振り分けたときも同じ（公式 Team Pricing）
• Privacy Mode（Legacy）のままだとモバイル起動ができないことがある
• Slack から使うなら、Integrations で Slack も Connect 済みか
• Microsoft Teams（チャットアプリ）から使うなら、Integrations で Microsoft Teams も Connect 済みか。Cursor の Teams プランとは別物です

Slack をチームで使うときの準備（管理者向けのお願い）

個人の Connect だけでは、チャンネルごとに『どのリポジトリが既定か』が曖昧なままになりがちです。公開チャンネルで `@Cursor settings` から既定リポジトリを決めておくと、はじめての人も迷いにくくなります。

プロダクト名や『frontend』『api』など、会話に出やすい言葉があるなら、Dashboard → Cloud Agents の Routing Rules（キーワード → リポジトリ／環境）も一緒に整えると取り違えが減ります。

GitHub をつなぐと見える、もう一つの機能

同じ GitHub 接続のうえで、Bugbot（Pull Request の自動レビュー）が動くチームもあります。これは『実装して PR を出す Cloud Agent』とは別の役割です。公式の料金ページでは、Start プランに Bugbot・Automations・Cursor SDK は含まれません（Cloud Agent 自体は Start でも使えます。Start はインド向け）。Start のモデルは Cursor Models 枠（Grok 4.6 / 4.5 / Composer 2.5）だけで、Fast と Grok の努力レベルは変えられません。

いまの公式の既定は Incremental Review です。前回の Bugbot レビューからの差分だけを読みます。毎回 PR 全体を読ませたいときは、管理者が Bugbot Automations でオフにします。すでに付いている PR コメントも読むので、同じ指摘を重ねにくくなります。push する前に自分で先に読んでもらうなら、チャットの `/review`（または `/review-bugbot`）です。同じ差分のまま PR を出すと、保管庫側は再実行を飛ばすことがあります（公式 Bugbot）。

cursor.com/automations には、Bugbot のほか Security Agents（PR 直前の Security Reviewer と、保管庫を定期で読む Vulnerability Scanner）や PR Routing & Approval（レビュアー回し・低リスク承認。Bugbot / Security の指摘が人の確認を要する場合は承認しない）など、Cursor が管理する Agent も並んでいます。チームで有効化するかは管理者の判断です。

はじめての方は、『直して』と頼む相手が Cloud Agent、PR にレビューコメントを残す側が Bugbot などの自動レビュー、と分けて覚えると混乱しにくいです。この学習パスの本線は Cloud Agent です。

GitHub Enterprise Server（社内 GitHub）を使うとき

多くのチームは github.com 上の GitHub を使いますが、会社によっては GitHub Enterprise Server（GHES、社内に置いた GitHub）を使うこともあります。接続の入口や管理者の作業は GitHub.com とは別です。

• 接続: Dashboard → Integrations の GitHub Enterprise 行から、社内 GitHub のベース URL を登録
• 推奨バージョン: GitHub Enterprise Server v3.8 以降（公式）
• 必要な権限: Cursor のチーム管理者 ＋ GHES 側の Organization 管理者（ネットワーク許可も要ることが多い）
• ネットワーク（管理者向け）: Cursor から GHES へ届くよう IP 許可リストやプロキシ設定が必要なことが多い。GHES の前段にプロキシがある場合、Cursor の GitHub アプリ連携が認証付きの GitHub REST / GraphQL API をブロック・書き換えしないことも必要です（アプリ登録時や Webhook 後の PR 状態・Checks 参照など）。公式には接続用 IP 一覧のほか、Enterprise 向けに AWS PrivateLink（AWS 上の GHES や NLB 背後向け）や Cloudflare Tunnel（インバウンド不要の outbound-only モデル向け）などの選択肢もある
• はじめての方の役割: 『社内 GitHub Enterprise Server を Cursor に接続したい』と、URL と Organization 名を管理者に伝えること

会社の GitHub Organization を守りたいとき

Cursor は、Agent を動かす人ごとに『そのリポジトリを開けるか』を毎回確認します。それでも会社では、『社員が個人の Cursor チームから社内リポジトリを触ってしまう』不安が残ることがあります。

Protected Git Scopes（保護する Git 範囲）は、GitHub Organization（や GitLab の group / namespace）を、自社の Cursor 組織だけに閉じる設定です。Cloud Agent・Automations・Bugbot が、許可した Cursor チーム以外からその保管庫を使えなくなります。

• 設定場所: Dashboard → Integrations（Teams / Enterprise）
• 必要な権限: Cursor のチーム管理者 かつ GitHub Organization の owner / admin（GitLab なら Owner）
• はじめての方の役割: 『社内 Organization を Protected Git Scopes で閉じたい』と管理者に伝えること

GitLab / Azure DevOps を使うチーム向け

この学習パスは GitHub を例にしていますが、公式には GitLab や Azure DevOps Services でも Cloud Agent を動かせます。接続の前提と起動の入口は、GitHub とは少し違います。

• GitLab: 連携には Premium または Ultimate が必要（Free では Project access token が作れず Connect できません）。接続後は Manage → Sync Repos で保管庫を同期します
• GitLab Self-Hosted: Cursor の Teams / Enterprise プランが必要です
• Azure DevOps: dev.azure.com の Azure DevOps Services のみ（Server は非対応）。公開ベータ段階です。初回 Connect では Microsoft Entra ID の管理者同意（admin consent）が必要なことが多く、Cursor チーム管理者と Azure AD 管理者の両方が関わります
• 起動入口: 公式 Cloud Agent の PR コメント @cursor は GitHub と Bitbucket だけです。GitLab / Azure DevOps は cursor.com/agents、Desktop の Cloud、Slack、Microsoft Teams、API から起動します
• Azure DevOps の Automations（PR トリガーなど）は公式ではまだ非対応です。Bugbot のレビュー依頼は PR コメントで `cursor review` または `bugbot run`（Cloud Agent の @cursor とは別）

GitHub がまだ無いとき（Origin / ゼロから始める）

公式 Origin（cursor.com/docs/origin）は Cursor の Git 保管場所です。GitHub をつなぐ前でも、ここで保管庫を作れます（早期ベータ）。cursor.com/codebase で保管庫を探し（Find repo...）、コードを見たり、PR を開いたりできます。git コマンドは不要です。はじめての方は『GitHub の代わりに、Cursor の中に保管庫を置ける』と覚えれば十分です。

cursor.com/agents の保管庫ピッカーで Start from scratch（ゼロから始める）を選ぶと、依頼した内容の置き場として Origin のリポジトリが裏側で用意されます（公式 changelog 2026-08-27）。

名前が似ていて迷いやすいので、先に3つを分けます。製品名の Origin は Cursor の保管場所。git の origin は『共有場所』の通称（中身は GitHub のことも Origin のこともある）。origin コマンドは Origin CLI で、Cursor Agent CLI（agent）とは別です。はじめての方はコマンドを自分で入れず、Agent に『Origin に置いて』と頼んでください（公式 Origin CLI / create-repository）。見分けの図は git-mental-model にあります。

• 有効化: cursor.com/codebase で Get Started。コードベース名（URL の {owner}）を決める。チームなら誰でも申請でき、そのあと管理者が保管庫の作成権限を付ける。ベータ中は名前をあとから変えられない（公式 Origin）
• 対象: Pro / Teams / Enterprise。無料プランは対象外。段階公開のため、画面に出ないこともある
• Privacy Mode（Legacy）のままでは Origin を有効化できない。管理者がダッシュボードからオフにすることもできる
• Origin のプライバシーはコードベース名の持ち主（チームまたは個人）の Privacy Mode に従う。開く人ごとではない（公式 Origin）
• コードベース設定から、管理者以外もアクセスを依頼できる。Private に切り替えた人は自動で管理者権限が残る（公式 Origin settings / codebase-settings）
• 新規: New で Repo Name と公開範囲（Internal＝チームのコードベースを見られる人 / Private＝個別に権限を付けた人）を決めて Create Repo。Agent に『Origin に置いて』と頼んでも作れる（公式 Origin create-repository）
• 既存の GitHub 保管庫: Sync from GitHub（GitHub 側の管理者権限が必要）。同期した保管庫では GitHub が正本、Origin は写し。Issue と GitHub Actions は同期されない（公式 Origin mirror）
• Origin 上で作った保管庫の PR は Origin 側。GitHub から同期した保管庫の PR は GitHub 側（公式 Origin integrations）
• 保管庫の Settings は General / Permissions / Rules and Protections / Apps。チーム全体の権限や Apps のインストール（Manage Apps）はコードベース設定。プライベートな Origin Apps を作り、Public API で Origin 向けの連携を足す道もある（詳しい人向け。公式 Origin）
• Apps: Vercel は公開と PR プレビュー。Depot / Buildkite は Origin 上で作った保管庫の CI。GitHub 同期の保管庫では CI は GitHub 側のまま。Apps タブに無いときはコードベース設定の Manage Apps（公式 Origin settings）
• Origin 上の PR がマージできないときは Settings の Rules and Protections（GitHub のブランチ保護の対応。公式 Origin settings）
• GitHub 同期をやめて Origin を正本にしたいときは、保管庫の Settings → General の Danger Zone で Detach from GitHub。GitHub 側の保管庫は消えない（公式 Origin settings / mirror）
• 気に入ったら Create repo で名前を付けて残す。Automations も Origin の保管庫を GitHub と同じように対象にできる

Microsoft Teams から使うときの準備

チャットアプリの Microsoft Teams と、Cursor の Teams プラン（有料のチーム契約）は別物です。ここではチャットアプリの話です。

公式の Microsoft Teams 連携では、チャンネルで `@Cursor` に続けて依頼すると Cloud Agent が動き始めます。Cloud Agent 概要の番号付き入口（Web / iOS / Slack / GitHub など）とは別ページの案内です。会社が Slack ではなく Microsoft Teams を使っているときの本線、と考えてください。

Automations の Trigger 一覧に Microsoft Teams 専用の種類はまだ少ないです。日常の『直して』は `@Cursor`、毎週の要約などは予定や PR トリガーで作ると分かりやすいです。

• 接続: Dashboard → Integrations の Microsoft Teams を Connect → Microsoft Teams に Cursor アプリを入れる → Cursor に戻ってソース管理・従量課金・Privacy Mode を確認（公式 Microsoft Teams）
• Privacy Mode（Legacy）は非対応。Cloud Agent は実行中に一時的なコード保管が必要なので、Privacy Mode へ切り替える案内が出ます
• 起動カードから Open in Web / Open in Desktop / Switch repository が選べます。チャンネルのスレッドでは `@Cursor` 追記、個人チャットやグループチャットの続きは Web / Desktop
• `@Cursor help` でいま使えるコマンド。切断は `@Cursor unlink` または `@Cursor disconnect`

Auto と Cursor Router（モデルの選び方）

起動時にモデル（AI の頭脳）を選べることがあります。Auto は『この依頼に向くモデルを Cursor が選ぶ』選び方です。自分で Grok や他社モデルの名前を固定しません。はじめての方は、モデル名を全部覚える必要はありません。

公式 Models & Pricing では、Start プラン（インド向け）に Auto は含まれません。Bugbot / Automations / Cursor SDK と同じです。Start では Cursor Models 枠の Grok 4.6 / 4.5 / Composer 2.5 を直接選びます。

Teams / Enterprise では、Auto の裏側が Cursor Router です（公式 Cursor Router）。依頼の種類と難しさから、その回に向くモデルへ振り分けます。自分でモデル名は指定せず、Optimize For（何を優先するか）だけ選びます。

• Cost: これまでの Auto に近い。トークン（利用量）を抑える
• Balance: 質・速さ・コストのバランス。日常の依頼向け
• Intelligence: 難しい仕事向けの強いモデルへ寄せる。常に最上位モデルを固定するより安くなりやすい、という公式の説明
• Balance と Intelligence は Cost より利用枠を速く使う。いつでも切り替えられる
• 課金は振り分け先モデルの定価。他社モデルなら Cursor Token Rate も乗る（公式 Models & Pricing）
• 振り分け先の名前は既定で隠す（結果で判断する公式の勧め）。表示はチーム管理者がオンにできる。詳しい人は turn/model（environments-and-secrets）
• いま公式では Teams / Enterprise 向け。Enterprise は既定オフで、管理者がダッシュボードから有効化する。振り分けが働くには Cursor Grok 4.6 が必要。Grok 4.6 を止めると Router が動かないことがある。モデルを止めすぎると振り分けの質も落ちる（公式 Cursor Router）