Cursor Background Agentsをチームで使う前に：Bugbot・GitHub権限・remote環境を分ける基準

このテーマをもう少し広げて見るなら、法人導入前のAIコーディング権限設計：APIキー・非公開リポジトリ・人間承認フロー と Copilot Coding AgentにIssueを任せる前に：instructions・AGENTS.md・PRレビューを整える も合わせて確認してください。Cursor Background AgentsやBugbotを組織に入れる前に、APIキー、非公開リポジトリ、人間承認の境界を確認できる

3行まとめ

Agents

remote VMでbranchを切って作業。

Bugbot

PR diffをreviewして指摘する。

GitHub

read-write権限を前提に見る。

Security

auto-runとdata保持を確認する。

Cursorの非同期機能は、便利さと権限を同じ画面で見ます。

• Cursor Background Agentsは、remote VMで非同期に実装や修正を進める機能です。BugbotはPR diffをreviewして指摘する機能なので、同じ「AI agent」として混ぜない方が運用しやすくなります。
• Background AgentsはGitHub repoをcloneし、別branchで作業してpushします。導入前に、read-write権限、対象repo、submodule、IP allow list、merge前reviewを確認します。
• remote環境ではterminal commandのauto-run、internet access、secret、privacy mode、データ保持が論点になります。最初はtest repo、小さなtask、secretなしで始めます。

本文の事実確認には、Cursor公式docsのBackground Agents、Bugbot、Rulesを使っています。Xで見かけるCursor Background Agents、Bugbot、GitHub権限、PR reviewへの投稿は需要シグナルとして扱い、本文の根拠にはしていません。

この記事でわかること

Role

実装agentとreview botを分ける。

Repo

対象repoと権限範囲を決める。

Env

remote環境のinstall/startを固定。

Risk

auto-runと外部送信を確認。

先に役割を分けると、GitHub権限の説明がしやすくなります。

• Cursor Background AgentsとBugbotの使い分け
• GitHub read-write権限をどう説明するか
• .cursor/environment.json でremote環境をどう固定するか
• auto-run terminal commandsとinternet accessのリスク
• privacy mode、データ保持、secretの扱い
• 初週にどこまで導入すればよいか

CursorをIDEの補助として使う段階では、人が画面を見ながらAgentに指示できます。Background Agentsを使う段階では、作業場所がremote VMへ移り、agentが非同期にbranchを作って作業します。Bugbotを使う段階では、PR上でreviewコメントが返ります。

この3つは便利ですが、権限と責任範囲が違います。この記事では、Cursorの非同期機能をチーム導入する前に、実装agent、review bot、repo指示、remote環境、securityを分けて整理します。

前提知識

項目	内容	見方
Background Agent		非同期remote agentとして動く。
Bugbot		PR reviewでbugやsecurityを探す。
Environment		.cursor/environment.jsonで固定。
Rules		agent向けの指示をrepoに置く。

Cursorのagent機能は、IDE内操作とremote実行を分けて見ます。

Cursor公式docsでは、Background Agentsを、remote environmentでcodeをeditし、runできるasynchronous agentとして説明しています。Background Agent SidebarやBackground Agent Modeから起動でき、statusを見たりfollow-upを送ったり、必要なら人が引き継げます。

Bugbot docsでは、Bugbotをpull requestをreviewし、bugs、security issues、code quality problemsを見つけるAI code review機能として説明しています。PR更新ごとのautomatic reviewや、cursor review、bugbot run、cursor run のコメントによるmanual triggerが説明されています。

この記事の扱う範囲

項目	役割
Foreground Agent	IDEで人が見ながら進める通常のagent作業
Background Agents	remote VMで非同期に実装、修正、検証を進める
Bugbot	PR diffをreviewし、bugやsecurity issueを指摘する
GitHub integration	repo clone、branch作成、push、PR handoffの入口
.cursor/environment.json	install、start、terminals、snapshotなどremote環境の設定
Rules / AGENTS.md	agentへ渡すproject固有の指示

2026年5月31日時点で公開されているCursor公式docsを確認しています。導入時には、利用中のCursor plan、GitHub org policy、privacy mode、repo権限、secret管理を確認してください。

注意点

この記事は、Background Agentsに本番repoやsecretをいきなり渡すための記事ではありません。まずtest repoや小さなtaskで挙動を確認し、merge前に人間reviewを置く前提です。

まず3つの役割に分ける

項目	内容	見方
Foreground		人が見ながらIDEで進める。
Background		非同期で実装や修正を進める。
Bugbot		PR diffにreviewを返す。
Rules		共通指示と禁止操作を伝える。

Cursorを全部agentとして扱わず、作業段階で分けます。

CursorのAI機能をチームで扱う時は、まず役割を3つに分けます。

役割	向く作業	注意点
Foreground Agent	人が見ながら実装、修正、質問	操作ごとの判断を人が見やすい
Background Agents	非同期の小さな修正、docs更新、bugfix候補	remote VM、GitHub push、auto-runを伴う
Bugbot	PR diff review、security/code quality指摘	実装ではなくreview補助として扱う

この3つを混ぜると、「Cursorに任せた」としか言えなくなります。実務では、実装を任せたのか、PR reviewを任せたのか、repoのrulesを読ませたのかを分けて記録します。

Background Agentsに向くtask

Background Agentsに向くのは、入力と完了条件が短く書けるtaskです。たとえば、docsの古い記述修正、小さなUI bug、test追加、型エラー修正、依存更新の下準備です。大きな設計変更や複数team調整が必要な変更は、最初から任せるには重すぎます。

Bugbotに向くtask

BugbotはPR reviewに向いています。diffを読み、bug、security issue、code quality problemを指摘する役割です。実装agentではないため、「PRを読んで危険な点を挙げる」補助として扱います。

Background Agentsは非同期実装に使う

Prompt

taskを投げてagentを起動。

Remote

isolated Ubuntu machineで実行。

Branch

別branchに変更をpush。

Handoff

statusを見て人が引き継ぐ。

非同期agentは、任せるtaskの粒度が品質を左右します。

Cursor公式docsでは、Background Agentsがisolated ubuntu-based machineで動き、internet accessを持ち、packagesをinstallできると説明されています。GitHubからrepoをcloneし、別branchで作業し、handoffしやすいようにrepoへpushします。

この仕組みは、IDEのchatとは違います。人が画面を見ながら一手ずつ承認するのではなく、remote環境でagentが作業を進めます。だからこそ、taskの粒度と終了条件が大事です。

よい依頼の形

• 対象repoとbranchを明確にする
• 変更してよい範囲をfileやdirectoryで絞る
• 実行してほしいtest commandを書く
• 触ってはいけないfileを書く
• PR本文に残してほしいsummary、tests、risksを書く

避けたい依頼の形

「この機能をいい感じに改善して」「全部直して」のような依頼は、Background Agentsには大きすぎます。remote agentは進められますが、レビュー側が意図を追いにくくなります。

判断基準

Background Agentsに渡すtaskは、1つのPRでreviewできる大きさにします。taskが大きい場合は、調査、実装、test追加、docs更新を分けます。

BugbotはPR reviewに限定する

Diff

PR diffを分析する。

Comments

説明と修正案を残す。

Manual

commentで手動triggerできる。

Verbose

必要時に詳細logを出す。

Bugbotは実装agentではなく、review補助として扱います。

Bugbotは、PR上で動くreview補助です。Cursor公式docsでは、PR diffをanalyzeし、explanationやfix suggestion付きのcommentを残すと説明されています。automatic reviewはPR updateごとに動き、manual triggerはPR commentで実行できます。

Bugbotを実装agentの代わりに扱うと期待値がずれます。Bugbotは「修正PRを作る人」ではなく、「PRの危ないところを見つける補助」として扱います。

review観点を固定する

観点	Bugbotに期待すること
bug	条件分岐、null、race、edge caseを拾う
security	injection、secret、auth、permissionを拾う
quality	重複、複雑さ、保守しづらさを指摘する
explanation	なぜ問題か、どう直すかを説明する

人間reviewを外さない

Bugbotが指摘しないから安全、とは言えません。AI reviewは、追加の目として使います。人間review、test、CI、security checkを置き換えないようにします。AI reviewと人間reviewの分担は、AIコードレビューをPRに入れる前にでも整理しています。

GitHub権限はread-write前提で見る

項目	内容	見方
Clone		repoをcloneして作業する。
Branch		別branchへpushする。
Submodule		依存repoの権限も確認。
Allow list		IP allow listがある組織は調整。

Background Agentsは、repoへ書き込める前提で導入判断します。

Background AgentsはGitHub repoをcloneし、別branchへpushしてhandoffしやすくします。公式docsでは、対象repoと依存repo/submoduleにread-write privilegesをgrantする必要があると説明されています。

この時点で、単なるread-only連携ではありません。GitHub Appがrepoへ書き込める権限を持つため、導入前に対象repo、対象org、submodule、branch protection、IP allow listを確認します。

導入前の確認表

確認	内容
repo	どのrepoへinstallするか
permission	read-writeが必要な理由を説明できるか
branch	agent branchをどう扱うか
protection	main branchへの直接pushを防げるか
submodule	依存repoにも権限が必要か
IP allow list	orgでGitHub IP allow listを使っているか

branch protectionを前提にする

Background Agentsがbranchへpushできても、mainへ直接入る運用にしません。PR作成、CI、human review、required approvalを前提にします。agentが作ったbranchは、reviewされるまでは候補です。

environment.jsonでremote環境を固定する

項目	内容	見方
Install		依存関係を入れるcommand。
Start		machine起動時の準備。
Terminals		dev serverやwatchを起動。
Dockerfile		system dependencyが必要な時。

環境差でagentが迷わないよう、remote setupをrepoに残します。

Background Agentsはremote machineで動くため、localでは動くのにremoteでは動かない、という差が出ます。Cursor公式docsでは、advanced caseとしてremote environmentを自分でsetupし、snapshotを取り、runtime settingsを設定できると説明されています。

.cursor/environment.json には、install command、start command、terminalsなどを置けます。repoへcommitすることが推奨される場合もあります。これにより、agentが毎回同じ環境で作業しやすくなります。

environment.jsonで分けるもの

項目	役割
install	dependency installやbuild準備を行う
start	machine起動時に必要なserviceを起動する
terminals	dev server、watch、compilerなどを走らせる
Dockerfile	system dependencyが必要な時に使う
secrets	dev環境に必要なsecretを渡す

公式docsでは、install command後のdisk stateがcacheされ、processは残らないと説明されています。開発serverのように生きていてほしいものはterminalsへ分けます。

secretは後から足す

remote環境でsecretが必要な場合、Cursor docsではencrypted-at-restで保存され、background agent environmentへ提供されると説明されています。ただし、初回からsecretを渡す必要はありません。まずsecretなしで動くtaskから始め、必要になったらscopeを絞って追加します。

auto-runとinternet accessのリスクを見る

項目	内容	見方
Commands		terminal commandsを自動実行する。
Internet		外部siteへ接続できる。
Injection		prompt injectionで誘導される可能性。
Exfiltration		codeやsecretの持ち出しを警戒。

background agentはforeground agentより自動実行の影響が大きくなります。

Cursor公式docsでは、Background Agentsがterminal commandsをauto-runし、testsをiterateできると説明されています。foreground agentではtoolごとにuser approvalが必要でも、Background Agentsでは自動実行が前提になります。

これは便利ですが、riskも変わります。agentがinternet accessを持ち、commandを自動実行できるなら、prompt injectionや悪意あるdependencyに誘導され、codeやsecretを外部へ送るような攻撃を考える必要があります。公式docsも、auto-runningがdata exfiltration riskをintroduceすると説明しています。

riskを下げる初期設定

対策	内容
小さいtask	変更範囲をdirectory単位で絞る
no secrets	初回はsecretを渡さない
test repo	本番repoの前に検証repoで試す
branch only	mainへ直接入れない
logs	agentが何を実行したか確認する
rules	禁止操作と報告形式をrepoに残す

Rulesを明文化する

CursorのRules docsでは、project rulesやAGENTS.mdをagent instructionsとして使えることが説明されています。Background Agentsにも、禁止操作、test command、PR本文の形式、外部送信禁止、secretの扱いを明文化します。

privacy modeとデータ保持を確認する

項目	内容	見方
Retention		数日程度の保持が必要。
Privacy		privacy modeでの扱いを確認。
Prompts		改善利用の有無を確認。
Secrets		KMS暗号化と環境変数を確認。

remote agentへ渡す情報は、IDE内のchatより広い前提で見ます。

Cursor公式docsでは、Background Agentsが数日程度のdata retentionを必要とすると説明されています。また、Privacy Modeでも利用でき、codeはagent実行のために保持されると説明されています。

privacy modeの扱いは、導入前に説明します。特に、privacy mode disabledで開始したagentは、途中でenabledにしても完了までdisabledのまま続くと説明されています。これは運用上の見落としになりやすい点です。

確認する項目

項目	確認内容
privacy mode	orgやrepoでの設定
retention	remote agentが必要とする保持期間
prompts	product improvementに使われるか
dev environment	環境情報の扱い
secrets	encrypted-at-restとscope

この確認は、法務やsecurity reviewのためだけではありません。team memberが「どのrepoをagentへ渡してよいか」を判断するためにも必要です。

最小構成の始め方

項目	内容	見方
Test repo		本番repoの前に試す。
Small task		docsや軽微なbugから始める。
No secrets		初回はsecretなしで動かす。
Review gate		merge前に人間reviewを必須にする。

最初はremote agentの成功条件を小さくして確認します。

最初は、Background AgentsとBugbotを同時に全repoへ入れません。1つのtest repo、1つの小さなtask、secretなし、human review必須で始めます。

最初の構成

.cursor/
  environment.json
AGENTS.md

environment.json にはinstall commandと必要ならterminalsを置きます。AGENTS.md には、agent向けの禁止操作、test command、PR本文の形式、変更範囲を書きます。

最初のtask例

• 古いdocsのリンクを直す
• failing testを1つだけ直す
• type errorを1つのpackage内で直す
• storyやsnapshotを追加する
• lint warningを限定範囲で直す

この程度のtaskなら、agentのbranchを人間がreviewしやすく、remote環境の不足も見つけやすくなります。

導入初週の進め方

1. 1日目

   test repoでGitHub連携を確認。

2. 2日目

   environment.jsonを作る。

3. 3日目

   small taskをbackground agentへ渡す。

4. 5日目

   Bugbotを1repoで試す。

5. 7日目

   auto-runとprivacyのreview。

初週は広げるより、説明できる運用にすることを優先します。

導入初週は、成功体験を急ぐ週ではなく、運用を説明できる週にします。GitHub権限、remote環境、auto-run、privacy、review gateを順番に確認します。

日	やること	完了条件
1日目	test repoでGitHub連携を確認	read-write権限とbranch運用を説明できる
2日目	.cursor/environment.json を作る	install/start/terminalsの役割が分かれる
3日目	小さなtaskをBackground Agentへ渡す	branch、diff、test結果をreviewできる
5日目	Bugbotを1repoで試す	automatic/manual triggerとcomment品質を見る
7日目	security reviewを行う	auto-run、internet access、privacy、secretの扱いが決まる

拡大する条件

• agent branchが人間reviewしやすい
• environment setupが再現できる
• secretなしでも価値が出ている
• Bugbot指摘の扱い方が決まっている
• branch protectionとCIが効いている

この条件を満たしてから、対象repoを増やします。

FAQ

Agent or Bugbot?

実装かreviewかで分ける。

GitHub?

read-writeの理由を説明する。

Secrets?

初回は渡さず後で検討。

Rules?

repo固有の指示を明文化する。

迷ったら、何が自動で実行され、どこへpushされるかを見ます。

Background AgentsとBugbotはどちらから入れるべきですか

PR reviewの補助が目的ならBugbotから、小さな実装taskを非同期に進めたいならBackground Agentsからです。いきなり両方を全repoへ入れるより、目的を分けて試します。

GitHub read-write権限は必須ですか

Background Agentsはrepoをcloneし、別branchで作業してpushするため、公式docsではread-write privilegesが必要と説明されています。導入時は、対象repoと権限範囲を説明し、branch protectionとhuman reviewを前提にします。

secretを渡してもよいですか

必要になってからscopeを絞って渡します。初回はsecretなしで動くtaskに限定します。secretが必要な場合は、誰が管理し、どのtaskで使い、logsに出ないかを確認します。

Bugbotの指摘は必ず直すべきですか

必ずではありません。Bugbotはreview補助です。指摘ごとに、直す、見送る、誤検知として記録する、の判断を人間が行います。必要ならverbose modeで詳細logやrequest IDを確認します。

他のagent導入基準にも使えますか

使えます。remote実行、repo write権限、auto-run、secret、human reviewの考え方は、Cursor以外にも共通です。企業向けの権限設計は、AIコーディングエージェント導入ガイドでも整理しています。

---

次に読むなら

参照した主な情報源

• Cursor Docs: Background Agents

https://docs.cursor.com/background-agent

• Cursor Docs: Bugbot

https://docs.cursor.com/bugbot

• Cursor Docs: Rules

https://docs.cursor.com/en/context

• Cursor Docs: Background Agents API Overview

https://docs.cursor.com/background-agent/api/overview

次に読むなら

更新履歴

1. 2026年5月31日

   Cursor公式docsのBackground Agents、Bugbot、Rulesを確認して初版を作成しました。

導入時には公式docsと利用中のCursor planを確認してください。

• 2026年5月31日: Cursor公式docsのBackground Agents、Bugbot、Rulesを確認し、初版を作成しました。