Cursor Background Agentsとは？できないことも解説

プルリクエストを開いて、あとは待つ。クラウドのどこかで、10分前に起動したエージェントがリポジトリをクローンし、テストスイートを走らせ、あなたが別のファイルを編集している間にブランチへコミットを積み上げていく——。これが Cursor background agent のうたい文句であり、ある種の作業においては実際にその通りに機能します。問題が始まるのは、チームが2つ目のコーディングツールを使い始めた瞬間です。この記事では、background agent とは何か、本当に得意なことは何か、そして「それだけで十分かどうか」を決めるたった1つの境界線、つまり彼らがオーケストレーションするのは Cursor であってスタックの残りではないという点を説明します。

すでにチームが複数のランタイムを併用している場合——あるターミナルでは Claude Code、別のターミナルでは Codex、同僚のノートPCでは Gemini エージェント——正直な答えは、それらすべての上に位置するレイヤーが必要だということです。そのレイヤーが Sharkly、オールインワンのエージェント統括・管理プラットフォームです。background agent が輝く場面、そこで止まってしまう場面、そして中立のレイヤーがリクエストからリリースまでフリート全体を可視化する仕組みを順に見ていきます。

TL;DR

Cursor background agent は、隔離されたリモート環境で非同期に動作するクラウドホスト型のコーディングエージェントで、Cursor エディタまたは Slack から起動し、成果をブランチまたはプルリクエストとして残します。チーム全員が Cursor の中で作業しているなら非常に優れています。ただしオーケストレーションするのは Cursor 自身のエージェントなので、Claude Code や Codex、Gemini、あるいは別のマシンで動くエージェントを連携させることはできず、複数ランタイムを併用するチームに共通のレビューレイヤーを提供することもできません。Cursor が唯一のツールなら background agent を使いましょう。チームが複数のランタイムを動かし、それら全体でアサイン・コンテキスト・ human レビューを共有する必要があるなら、Sharkly のような中立のレイヤーを使ってください。

Cursor background agent とは実際何なのか

Cursor の background agent とは、ローカルのエディタセッションではなく、Cursor が用意したリモート環境で非同期に動作するコーディングエージェントです。この一言にすべてが集約されています。通常の Cursor エージェントは、あなたのマシン上のエディタ内で、あなたが見守る中で作業します。background agent はあなたのマシンを離れ、リポジトリをサンドボックス化されたクラウド環境にクローンし、あなたが別のことをしている間に独力で作業を進めます。

起動方法は Cursor 内から、あるいは Slack でエージェントにメンションする方法があります。後者なら、エディタを開かない同僚でもエージェントを動かせます。エージェントはタスクを読み、複数ファイルにまたがる変更を加え、ターミナルコマンドを実行し、依存関係をインストールし、テストを走らせ、作業内容をブランチへプッシュします。完了するとレビュー可能なブランチまたはプルリクエストが得られ、最後の仕上げを自分でやりたければエージェントの環境に入って手動で引き継ぐこともできます。

「background（バックグラウンド）」の狙いはスループットです。エージェントの作業中もあなたはブロックされません。3つの異なるイシューに対して3つのエージェントを同時に走らせ、自分は4つ目をコーディングし続けられます。エージェントオーケストレーションとは何かの解説記事を読んだことがあるなら、これは単一ベンダー型のオーケストレーションです。1つのツール、1つのクラウド、多数の並列実行です。

background agent が得意なこと

ここではこの機能の最良の姿を前提にします。実際に強力だからです。background agent が真価を発揮するのは次の場面です。

ローカルに負担をかけない非同期の並列実行。 自分のノートPCで複数のエージェントを同時に走らせると、ターミナルタブや git worktree、CPU の取り合いになります。background agent はその負荷を Cursor のクラウドへ移すので、並列化にローカルのコストはかかりません。以前これを手作業で組んでいたチーム向けに、複数の Claude Code エージェントを並列実行する方法の記事で DIY 版がいかに面倒かを見ています。background agent は Cursor 内部におけるそのセットアップ作業を丸ごと不要にします。

実行ごとに隔離された環境。 各 background agent は専用の環境を割り当てられるため、重複するファイルを編集する2つのエージェントが互いの状態を壊すことはありません。これは コーディングエージェント向けの git worktree と同じ安全設計を、クラウド上で実現したものです。環境は一度設定すれば——インストールコマンド、ベースイメージ、シークレット——以降のすべての実行がそれを継承します。

作業がすでに発生している場所から起動できる。 Slack から background agent を起動できるため、Cursor を一度も開かないプロダクトマネージャーや同僚でもエージェントを走らせられます。「料金ページの壊れたリンクを直して」がメッセージ1通になり、ブランチが返ってきます。これは実質的な摩擦の削減です。

レビューへのきれいな引き渡し。 出力はブランチまたはプルリクエストなので、チームがすでに信頼している GitHub のレビューフローにそのまま乗ります。新たに確認すべき場所は増えません。エージェントの diff は、いつも diff が表示される場所に現れます。

Cursor を隅々まで標準化しているチームにとって、これは整然として強力なループです。作業を記述し、エージェントを起動し、プルリクエストをレビューし、マージする。あなたがそうなら、background agent だけで必要なオーケストレーションは足りているかもしれません。ここで読むのをやめても、心は晴れやかでしょう。

正直な境界線：彼らがオーケストレーションするのは Cursor であり、他のツールではない

ここがマーケティングがほとんど教えてくれない線引きです。background agent がオーケストレーションするのは Cursor です。Cursor のエージェントを、Cursor のクラウドで、Cursor または Slack から制御し、あなたの Git ホストへ着地させます。この文の構成要素はすべて Cursor の一部です。それは欠陥ではなく設計です。しかし、チームの現実が「全員が Cursor を使う」ではなくなった日、それは厳しい限界になります。

background agent は Claude Code や Codex、Gemini、OpenCode を実行しません。実行するのは Cursor のエージェントです。ワークフローに合うからとチームの半分がターミナルの Claude Code へ移っていたら、それらの実行はまったく別の世界に存在します。Cursor の background agent の作業と Claude Code の実行が並んで表示される共有タイムラインはありません。

background agent はツールをまたいだ単一のレビューレイヤーを提供しません。成果は GitHub のプルリクエストとして返ります。それ自体は問題ありませんが、別の場所で動くエージェントの進捗・ブロッカー・結果が同じ場所に届かないなら、あなたの「唯一の信頼できる情報源」は3つに分裂します。

background agent はランタイムをまたいだチームレベルのアサインを管理しません。「このタスクはこの担当者が、あのコンピュータ上の、このエージェントで実行し、受け入れ条件はこれ」という概念を持ちません。把握しているのはリポジトリとプロンプトだけです。誰が何を担い、何がブロックされ、何が human レビュー待ちなのかという、チームに必要なコーディネーションのレイヤーは、その守備範囲の外にあります。

これは Cursor を貶す話ではありません。読み手が誤って前提しそうな箇所で、ツールが「そうではないもの」を率直に述べておくべきなのです。background agent は単一ベンダーのオーケストレーション機能であり、混成フリート向けの中立のコーディネーションレイヤーではありません。Cursor しか使わないならこの境界線に触れることはありません。2つ目のランタイムを使った瞬間に、それは牙をむきます。

二者択一：単一ベンダーのオーケストレーションか、中立レイヤーか

選択は「良いツールか悪いツールか」ではありません。「どの形のオーケストレーションが自チームに合うか」です。ここで正直な二者択一を示します。

完全に Cursor の中で生きているなら Cursor background agent を使う。 エディタは1つ、エージェントは1つ、クラウドは1つ。チーム全員が Cursor でコードを書き、GitHub でレビューし、他のランタイムを追加する予定もない。そんな世界では、background agent はアイデアからレビュー済みブランチまでの最短経路であり、別のレイヤーを足すのは不要なオーバーヘッドでしかありません。

ランタイムを併用し、共通のレビューが必要なら中立レイヤーを使う。 片方に Claude Code、もう片方に Codex、そこに Cursor ユーザーが1〜2人混ざった瞬間、足りないのは「より多くのエージェント」ではなく「共有された記録」です。どのランタイムが作業したかに関係なく、ゴール・diff・議論・ human レビューを1つのタスクに保持する必要があります。それは個々のツールの内側ではなく、すべてのツールの上に位置するレイヤーの役割です。

これは開発者がローカルのボードを使いこなせなくなったときに向き合う分岐と同じで、Vibe Kanban 代替ガイドで扱っています。単一ベンダーのオーケストレーションは、そのベンダーが物語のすべてでなくなるその瞬間まで快適です。

Sharkly の役割：あらゆるランタイムを包む中立レイヤー

Sharkly は Cursor や Claude Code、Codex、その他の実行ツールの代替ではありません。チームがすでに使っているツールの周囲に、共有されたタスク・コンピュータ・コンテキスト・制御・レビューのレイヤーを加えるものです。この一文が関係性のすべてなので、2度読んでください。Cursor はそのまま。background agent も適所でそのまま。Sharkly は、フリートが単一ベンダーより大きくなったときに、そのフリートを調整するものです。

役割分担は明確です。Cursor、Claude Code、Codex といったツールが実行を担います。Sharkly はそれらのツールをまたいで、チームレベルのアサイン、接続されたコンピュータ、タスクのコンテキスト、進捗、ブロッカー、結果、human レビューを管理します。エージェントは調査し、実行し、テストし、報告します。人間は方向性を定め、権限を与え、結果を受け入れます。自動化はチームの判断が必要なところで止まります。

具体的には、Sharkly のタスクは作業の主要な単位であり、ある作業に関するすべてを1か所に保持します。あなたが管理するコンピュータ上で、任意のランタイムで動くエージェントにタスクをアサインします。実行・ブロッカー・結果・フォローアップの議論は、プライベートなターミナルや単一ベンダーのクラウド、Slack スレッドに散らばるのではなく、タスクのタイムラインに戻ってきます。その実行が Claude Code でも Codex でも、来年導入する何かでも、あらゆる実行のゴール・diff・議論・レビューが一緒に保たれます。

しかも、何かを組み直す必要はありません。チームがすでに使っているツールをそのままに、実行をアサイン可能で追跡可能にします。モデルの利用はそれらのツールで設定済みのサブスクリプションまたは API キーを通じて継続されるので、自分のサブスクリプションを持ち込み、Sharkly がその上にコーディネーションを加えます。プラットフォームが初めてなら、Sharkly を知るで核となる考え方を解説しており、最初のタスクのウォークスルーでは最小構成の使い方を端から端まで示しています。Sharkly をダウンロードし、コンピュータを1台接続して実際の作業で試せます。

具体的な例

チームがチケット SH-312「公開 API にレート制限を追加し、テストでカバーする」を拾ったとしましょう。2つの形がどう扱うかを見てください。

background agent だけの場合、Cursor ユーザーが background agent を起動し、Cursor のクラウドで作業し、プルリクエストが返ってきます。それを行うのがその Cursor ユーザーである限りは問題ありません。しかしバックエンドのリードは Claude Code を使っており、厄介なミドルウェア部分を担当したいと思っています。すると SH-312 には Cursor のプルリクエストと、共有の拠り所を持たない別の Claude Code セッションが生まれます。レビューする人は記憶を頼りに両者を突き合わせるしかありません。

Sharkly なら SH-312 は1つのタスクです。ミドルウェア担当のエージェントはリードのコンピュータ上で Claude Code の下に動き、テストカバレッジ担当のエージェントは別のランタイムで動き、どちらも同じタスクに成果を返します。レビュアーは1か所を開くだけで全体像を見られます。各エージェントが何をしたか、何がブロックされているか、型チェックとテストに何が通ったか、何が人間の判断待ちか。フロントエンド、バックエンド、テストカバレッジが同時に進むのは、エージェント型コーディングの本当の意味で説明している並列開発のパターンです。人間が承認するか、変更を依頼するか、マージを決めます。ランタイムはそのままで、加わったのはコーディネーションです。

避けたいよくある失敗

• 「background」を「無監督」と取り違える。 そうではありません。background agent であれオーケストレーションレイヤーであれ、人間の承認は必要です。最終承認とリリースの判断は人間に委ね、マージ前に必ずすべての diff を読みましょう。
• 単一ベンダーのオーケストレーションを戦略そのもののように採用してしまう。 今日 background agent に標準化し、来四半期に Claude Code を追加すると、レビューの面をこっそり2つに分裂させたことになります。単一ランタイムの環境なのか混成フリートなのかは早めに決めましょう。
• 環境設定を省略する。 background agent の品質は、用意した環境の品質を超えません。曖昧な設定は不安定な実行を生みます。ベースイメージ、インストールコマンド、シークレットを固定し、すべての実行が同じ既知の状態から始まるようにしましょう。
• プルリクエストをコーディネーションレイヤーとみなす。 プルリクエストはレビューの面であって、アサインとコンテキストのレイヤーではありません。誰がタスクを所有し、何に依存し、なぜブロックされているかは diff には収まりません。

Cursor background agent と中立オーケストレーションレイヤーの比較

これは優劣の表ではなく、役割分担として読んでください。

どちらの列も「間違い」ではありません。各行の答えがほぼ左列に収まるなら background agent が合っています。特に共有記録とランタイム横断の行で右列に流れるなら、単一ベンダーのオーケストレーションはもう手に負えないものになっています。

重要なポイント

• Cursor background agent は、エディタまたは Slack から起動するクラウドホスト型の非同期コーディングエージェントで、成果をブランチまたはプルリクエストとして残します。
• 得意なのは、ローカルコストなしの非同期並列実行、実行ごとの隔離環境、摩擦の少ない起動の入口、GitHub レビューへのきれいな引き渡しです。
• 境界線は設計上のものです。オーケストレーションするのは Cursor のエージェントであり、Claude Code や Codex、Gemini ではなく、複数ランタイムのチームに共通のレビューレイヤーも提供しません。
• チーム全員が Cursor の中で生きているなら background agent を使ってください。複数のランタイムを動かし、共通のアサイン・コンテキスト・レビューが必要なら中立レイヤーを使ってください。
• Sharkly は Cursor の代わりではなく、Cursor と並んで動きます。ツールはそのまま、サブスクリプションは自分のものを使い、リクエストからリリースまでのすべての実行を1つのタスクに集約できます。

次の一歩はわざと小さくしてあります。コンピュータを1台接続し、エージェントを1つ作り、退屈な作業を1つアサインしてみてください。各概念の詳細は docs.sharkly.ai のドキュメントで扱っています。

FAQ

Cursor background agent を一文で表すと？ Cursor が用意したリモート環境で非同期に動作し、エディタまたは Slack から起動して、リポジトリをクローンし、変更を加え、コマンドを実行し、成果をブランチまたはプルリクエストとして返すコーディングエージェントです。

background agent は通常の Cursor エージェントとどう違うのですか？ 通常のエージェントはあなたが見守る中、ローカルのエディタセッションで作業します。background agent はあなたのマシンを離れ、クラウドで独力で作業するため、あなたはブロックされず、同時に複数を動かせます。

Cursor background agent は Claude Code や Codex を実行できますか？ いいえ。background agent が実行するのは Cursor 自身のエージェントです。チームが Claude Code や Codex を使っているなら、それらの実行は別々に行われるため、複数ランタイムのチームにはすべてのツールの上に中立レイヤーが必要になります。フリートのその側面については複数の Claude Code エージェントを実行する方法のガイドをご覧ください。

Sharkly を使うために Cursor を置き換える必要がありますか？ いいえ。Sharkly は Cursor やその他の実行ツールの代替ではありません。すでに使っているツールの周囲に、共有されたタスク・コンテキスト・レビューのレイヤーを加えるもので、Cursor とその background agent はこれまでどおり動作し続けます。

オーケストレーションレイヤーを上に足すべきでないのはどんなときですか？ チーム全体が Cursor の中で作業し、他のランタイムを追加する予定もないなら、background agent だけで必要なオーケストレーションは足りているかもしれません。中立レイヤーを足すのは、複数のツールを動かし、それらをまたぐ1つの共有記録が必要なときだけです。

Sharkly を使うとモデルの支払い方法は変わりますか？ いいえ。サブスクリプションはご自身のものを持ち込みます。モデルの利用は接続したツールで設定済みのサブスクリプションまたは API キーを通じて継続され、モデルのクォータはチームが接続したプランと API アカウントに依存します。

大規模な移行なしに中立レイヤーのアプローチを試すには？ 最小構成のワークフローから始めましょう。コンピュータを1台接続し、エージェントを1つ作り、リスクの低いタスクを1つアサインするだけです。最初のタスクのウォークスルーで手順を追って説明しています。