やす研究所 AI Lab
戻る

Cursor Background Agents 完全ガイド 2026:寝てる間にPRが上がる新作法

Cursor Background Agents 完全ガイド 2026:寝てる間にPRが上がる新作法

Cursor 3.0 で本格化した Background Agents、もう使っていますか。

私は先月から「タスクを投げて MacBook を閉じる」運用を3週間ほど続けていますが、率直に言って、これは Composer や Agent モードとは別物の体験でした。コードを書く時間より、タスクをどう分解するかを考える時間のほうが長くなる。これが2026年の Cursor の新しい使い方らしいです。

この記事では、Background Agents を実務で動かすための具体的な手順、向いているタスクと向かないタスク、そして料金面で気をつけたい点までまとめます。読み終わる頃には、あなたも今日から「寝ている間に PR が積み上がる」開発スタイルに移行できるはずです。

結論:Background Agents は「並列で回す軽い修正」が最強

先に答えを書きます。

Background Agents の真価は、「自分が別の作業をしている裏で、独立した小〜中タスクを2〜4本同時に進める」 ところにあります。フォアグラウンドの Composer で大きな機能を書きながら、裏では Background Agents に「依存パッケージのアップデート」「テストの追加」「ドキュメントの更新」を投げておく。これだけで体感の生産性が変わります。

一方で、設計判断が必要な大きな機能開発や、本番DBに触る作業には向きません。理由は後半で詳しく書きますが、エージェントは VM 内で動くため、あなたの直感的な「あ、それやめて」が間に合わないからです。

向いているタスク・向いていないタスクの線引きをまず頭に入れてから、設定に進みましょう。

Cursor Background Agents とは何か(2026年版の定義)

まず公式の位置づけから。Cursor は2026年に入って 2.0、続いて 3.0 と立て続けにアップデートされ、インターフェース自体がエージェント中心に再設計されました。Background Agents はその中核機能のひとつで、リポジトリのクローンを Cursor 側のクラウド VM 上に立て、そこで自律的にタスクを実行し、完了したら PR を開く という仕組みです。

fork 元の VS Code にはこの概念がないので、ここが Cursor を選ぶ大きな理由になります。Windsurf の Cascade も agentic ですが、こちらはローカルの IDE 上で動くのが基本で、「ノートPC を閉じても進む」という性質ではありません。Cognition によると Devin の統合が段階的に進んでいるものの、2026年5月時点で完全には揃っていない状況のようです。

つまり今のところ、「laptop を閉じて寝て、朝起きたら PR レビューから始まる」 という働き方ができるのは、Cursor の Background Agents が一番現実的です。

Composer / Agent モードとの違い

この3つはよく混同されるので整理します。

ひとことで言えば、Background Agents は「あなたの集中を奪わない」エージェントです。逆に言うと、即時の方向修正ができないので、タスクの切り出しと指示の質がすべてになります。

Background Agents を動かす最短手順

ここから実践です。私が普段やっている手順を、そのまま書きます。

1. リポジトリを GitHub と連携する

Background Agents は Cursor のクラウド VM がリポジトリを clone する仕組みなので、まず GitHub 連携が必要です。Cursor の Settings → Integrations から GitHub App をインストールし、対象のリポジトリにアクセス権を与えます。プライベートリポジトリも問題なく動きました。

ここで一点だけ。組織のリポジトリだと管理者承認が要るケースがあるので、副業や個人開発のリポジトリで先に試すのをおすすめします。私も最初は個人の Astro サイトで挙動を確認してから本業に持ち込みました。

2. Background Agents パネルを開く

Cursor 3.0 では Agents Window が独立した UI として用意されています。コマンドパレット(Cmd+Shift+P)から「Background Agent」で検索すると、新規タスク作成のショートカットが出てきます。

初回は VM の起動に1〜2分かかりますが、2回目以降はキャッシュが効くので30秒前後です。これは想像以上に速く感じました。

3. プロンプトとブランチを指定する

ここが肝です。Background Agents に渡すプロンプトは、Composer に書くものよりさらに具体的にしてください。理由は単純で、途中で「それ違う」と止められないからです。

私が使っているテンプレートはこんな形です。

ブランチ: feature/update-tailwind-v4
ゴール: tailwindcss を v3 から v4 にアップデートする

手順:
1. package.json の tailwindcss を v4 系の最新に上げる
2. tailwind.config.js を新フォーマットに移行する
3. 既存の @apply / arbitrary value 利用箇所を確認し、壊れていれば修正
4. npm run build と npm run test が緑になることを確認
5. CHANGELOG.md に変更を1行追記

制約:
- グローバル CSS のクラス名は変更しない
- 既存テストを削除しない
- 不明点があれば作業を止めて、何が必要かを PR description に書く

「不明点があれば止まる」を明示するのが地味に効きます。これを入れないと、エージェントは勝手な仮定で突き進む傾向があるので。

4. PR を確認してマージする

完了すると Cursor の Agents Window に通知が来て、GitHub 側に PR が立ちます。差分はあなたがレビューする必要があります。ここを省略してはいけません。

2026年の AI コーディング統計でも、開発者の75%は AI 生成コードをマージ前に手動レビューしているという報告があり、これは Background Agents でも同じです。むしろ、自分が書いていないコードなので、より丁寧に見るくらいでちょうどいい。

実際に試して効果が高かった3つのユースケース

3週間使ってみて、明らかに費用対効果が高かったタスクを3つ挙げます。

ライブラリのバージョンアップ

React、Next.js、Tailwind、Drizzle などのマイナー〜メジャーアップデート。手順がパターン化されていて、失敗してもロールバックが容易なので、Background Agents の独壇場です。

私の Next.js 14 → 15 移行は、プロンプトを書く時間込みで12分。エージェントの実行時間は約25分でした。自分でやっていたら半日コースの作業です。

テストカバレッジの追加

「src/utils/ 配下の関数にユニットテストを追加して」と投げると、関数シグネチャを読んで Vitest のテストを書いてくれます。テストはレビューが楽な部類なので、Background Agents との相性がいい。

リファクタリングの提案 PR

「barrel export を全部やめて named export 直 import に書き換える」みたいな、機械的だが量が多いリファクタ。これも裏で回しておけば、レビューだけで済みます。

逆に、外部 API の認証フロー設計や、本番DB のスキーマ変更みたいな**「失敗したら復旧コストが高い」タスク**は、フォアグラウンドの Composer で1ステップずつ approve する方が安全です。Background Agents で投げて怖い思いをしたことが1回あって、そこから線引きを変えました。

料金とクレジット消費の現実

お金の話もしておきます。Background Agents は Pro プラン($20/月)で利用可能ですが、通常のチャットよりクレジット消費が大きい のが現実です。VM を起動して長時間動かす分、当然と言えば当然なんですが。

私のざっくり感覚値だと、20〜30分のタスク1本で月のクレジットを5%前後消費しました。これを1日2〜3本回すと、月の半ばでクレジットが尽きます。

対策はシンプルで、以下の3つです。

Pro+ への一時アップグレードはサブスク管理画面から月単位で切り替えられるので、繁忙期だけ上げて落とす運用が現実的です。

詰まりやすい3つの落とし穴

最後に、私がハマった点を共有します。

ひとつ目は環境変数。Background Agents の VM には .env が clone されないので、ビルドに環境変数が必要なプロジェクトは Cursor 側の Secrets 設定に登録しておく必要があります。これを忘れると、エージェントが30分かけて「ビルドできません」という PR を立てて終わります。

ふたつ目はモノレポでの作業ディレクトリ指定。pnpm workspace や Turborepo を使っていると、エージェントがルートで npm install を試みて失敗することがありました。プロンプト内で「作業対象は apps/web/ 配下のみ」と明示するか、.cursor/rules/ にモノレポ構造を書いておくと安定します。

みっつ目は長すぎるタスク。1時間を超えるタスクを投げると、VM のタイムアウトに引っかかったことがありました。公式ドキュメントによると上限は変動するようですが、目安として40分以内に収まるように分割するのが安全です。

まとめ:今日から始める3つのアクション

Background Agents は、Cursor を「AI 補助つきエディタ」から「AI 開発プラットフォーム」に変える機能だと、3週間使って実感しました。フォアグラウンドの Composer と組み合わせると、文字通り並列に複数のタスクを進められます。

今日からあなたが踏める3ステップはこれです。

  1. 個人リポジトリで GitHub 連携を済ませる:本番に持ち込む前に挙動を確認する
  2. 「ライブラリのバージョンアップ」を1本投げてみる:成功体験が最も得やすいタスク
  3. .cursor/rules/ にプロジェクト固有の制約を書く:Background Agents は rules を読んでくれるので、ここに投資すると以後のすべてのタスクの精度が上がる

最初の1本は拍子抜けするほど簡単に PR が立ちます。そこから「何を任せるか・何は任せないか」の感覚を、自分の手で掴んでいってください。

参考リンク

この記事をシェア:
X で共有 Facebook で共有 Telegram で共有
次の記事
Claude Code Skills自作入門2026:SKILL.mdで専門化する実装手順