【2026 年版】Cursor Composer 2 完全ガイド｜Agent mode・8 並列・Slack/GitHub からのリモート起動を一次情報で整理

Cursor は 2025 年 10 月に Cursor 2.0 で並列エージェント基盤を整え、2026 年 3 月に専用コーディングモデル Composer 2 を投入し、4 月には Cursor 3 で「エディタからエージェント中心の作業環境」へと再設計されました。AI コーディングツールの議論は「補完が速いか」から「エージェントをいかに並列で走らせ、ターミナル以外からリモートで起動するか」へと大きく軸が動いています。

本記事では、Composer 2 の性能と価格、Agent mode（cloud VM × git worktree）の仕組み、最大 8 並列の Background Agent 運用パターン、Slack / GitHub / モバイルからのリモート起動、料金プラン、Claude Code・Cline との比較で Cursor を選ぶ判断軸までを、Cursor 公式ブログ・ドキュメント・チェンジログを一次情報として整理します。仕様は 2026 年 5 月時点のもので、最新は公式ドキュメントでも確認してください。

Key Takeaways:

• Composer 2 は 2026 年 3 月 19 日リリースの Cursor 専用コーディングモデルで、CursorBench 61.3 / Terminal-Bench 2.0 61.7 / SWE-bench Multilingual 73.7 という公式ベンチで Composer 1 を大きく上回り、価格は 入力 $0.50 / 出力 $2.50（100 万トークン） に再設計されました
• Agent mode はクラウド VM 上でリポジトリをクローンし、git worktree で各エージェントを隔離する仕組みで、コミュニティ事例では .cursor/worktrees.json で 1〜8 のタスク番号を割り当てる構成が広く共有されています（公式ドキュメントでは並列数の上限は明示されていません）
• Slack の @Cursor メンション、GitHub Issue、モバイル / Web（cursor.com/agents） からエージェントをリモート起動でき、エディタを開かないままタスクを投げて PR を待つワークフローが構成可能です
• 料金は Free / Pro $20 / Pro+ $60 / Ultra $200 の階段で、Composer 2 は Standard / Fast の 2 バリアントを使い分けることで体感速度とコストの両立が可能です
• Claude Code が「ターミナルで委任する CLI エージェント」なのに対し、Cursor は「エディタとクラウドを横断するエージェント基盤」であり、組織標準を Cursor にしつつ CI 上で Claude Code を併用する構成も成立します

Cursor Composer 2 とは — リリース時系列で押さえる全体像

Cursor Composer 2 とは、Cursor が独自に訓練したフロンティア級のコーディング特化モデルで、Cursor 2.0 で導入された Agent mode と並列エージェント基盤の上で動く中核モデルです（公式ブログ表記の "frontier-level at coding" に対応）。Anysphere 社（Cursor の開発元）が長期的なコーディングタスクに最適化して継続事前学習＋強化学習で仕上げており、ファイル横断のリファクタリング・テスト生成・実行・修正までを一連の流れで完結させる用途に振り切っています。

時系列で押さえると、現在の Cursor を構成する 3 つのマイルストーンが見えてきます。2025 年 10 月 29 日に Cursor 2.0 がリリースされ、エディタを「ファイルではなくエージェント」を中心としたインタフェースに再設計したうえで、ネイティブブラウザ・並列エージェント・改善されたコードレビュー機能などが揃いました。続く 2026 年 3 月 19 日に Composer 2 が公開され、Cursor 専用モデルがフロンティア級の性能と大幅な価格引き下げを同時に実現します。そして 2026 年 4 月 2 日にリリースされた Cursor 3 は、Agents Window を中心に「ローカル・クラウド・worktree・リモート SSH」を横断して並列エージェントを管理する、エージェントファーストの作業環境として再構築されました。

Cursor 自体の利用規模も急拡大しています。2025 年末から 2026 年初頭にかけて、複数の海外テックメディアが デイリーアクティブユーザーが 100 万人規模、年間収益（ARR）が 20 億ドル規模に達したと報じています（公式発表ではなく報道ベースのため、具体的な数値は時点と情報源により幅があります）。この規模の利用者基盤に対して、Anysphere が独自モデル（Composer 2）と並列エージェント基盤を提供している点が、本記事のテーマである 4 本柱（Composer 2 / Agent mode / 並列 / リモート起動）の前提です。

Cursor を VS Code のフォークと位置づけて補完体験を中心に語る記事は多いですが、2026 年の文脈では 「エージェントの実行環境としての Cursor」 という視点で読み直す必要があります。同じく CLI ベースで進化を続ける Claude Code との関係は、Claude Code vs Cursor 徹底比較でも整理しています。AI コーディングツール全体の見取り図はAIコーディングツール徹底比較 2026を参照してください。

Composer から Composer 2 への進化 — ベンチマーク・価格・速度

Composer 2 の核心は、Composer 1 から大幅にスコアを伸ばしながら、推論コストを約 1/7 にまで圧縮した点です。Cursor 公式ブログによる Composer 1 との比較は以下の通りです。

ベンチマーク	Composer 2	Composer 1	改善幅
CursorBench	61.3	38.0	+23.3
Terminal-Bench 2.0	61.7	40.0	+21.7
SWE-bench Multilingual	73.7	56.9	+16.8

CursorBench は Cursor 内のリアルワールドな編集タスクを評価する独自ベンチで、Terminal-Bench はターミナル操作を伴うエンドツーエンドのタスク、SWE-bench Multilingual は多言語リポジトリでのバグ修正・機能追加タスクをそれぞれ測ります。Composer 2 は 3 種類の評価軸すべてで Composer 1 を大幅に上回り、特に複数ステップを連鎖させる長期タスクで安定性が増しています。Cursor 公式ブログは技術背景として「継続事前学習＋強化学習」を挙げており、複数ステップを跨ぐ長尺タスクへの対応力を強化したと公表しています。

価格面のインパクトはさらに大きい変化です。Composer 2 は Standard で入力 $0.50 / 出力 $2.50（100 万トークンあたり）、Fast で入力 $1.50 / 出力 $7.50 という設定です。Cursor 公式ブログ（cursor.com/blog/composer-2）によれば、Composer 1.5 が入力 $3.50 / 出力 $17.50 だったことを踏まえると、Standard は約 7 倍のコスト削減になります。Fast バリアントはレイテンシ重視のインタラクティブセッション向け、Standard はバックグラウンドで長く走らせるエージェントタスク向けと整理されており、両者で「知能の水準」は同等です。

速度面では、Cursor 公式発表として 200 トークン/秒台のスループットと 150ms 程度の time-to-first-token が複数の海外メディアで伝えられており、レイテンシ重視で設計されているのが特徴です。技術背景としては、Multi-Head Latent Attention（MLA）に最適化したカスタム GPU カーネル、ドラフトモデルによる speculative decoding、リポジトリ単位の prefix キャッシュという 3 段構えの最適化が組み合わさっていると公式が公表しています（具体的なドラフトモデルのサイズや先読みトークン数などのパラメータは公式技術レポート cursor.com/resources/Composer2.pdf を参照）。

実務的な使い分けの目安:

• Fast を選ぶ場面: チャットでの即応や Cmd/Ctrl+K のインライン編集など、開発者が画面を見て待っているとき
• Standard を選ぶ場面: Background Agent や並列エージェントで長尺タスクを任せるとき、コストを抑えてバッチ的に走らせたいとき
• 外部モデルを選ぶ場面: 数学的推論や難解な仕様の読解が必要なとき（Claude Opus 系・GPT-5 系などにフォールバック）

「Composer 2 が常に最適か」という問いに対する答えは「速度とコストでは強いが、外部フロンティアモデルに切り替えるべき局面も依然として存在する」です。Cursor のモデルセレクタの設計から、Composer 2 を主軸に必要に応じて外部モデルを使い分ける運用が想定されていると読み取れます。

Agent mode の仕組み — クラウド VM × git worktree

Cursor の Agent mode は、ファイル探索・編集・ターミナルコマンド実行・テスト確認までをエージェントが自律的に進めるモードで、Composer 2 の能力を最大限に引き出す前提となるインタフェースです。

Cursor のチャットには大きく 3 つのモードがあります。Normal は提案ベースで、開発者が差分を確認して承認する従来型のコーディング体験です。Agent は自律的にファイルを読み書きしターミナルを叩く実行モードで、Composer 2 と組み合わせると複数ファイルを横断する大きなタスクをまるごと任せられます。Plan（Shift+Tab で切り替え）は計画モードで、コードベースを調査して質問を返し、.cursor/plans/ に承認済みプランを保存できる、設計フェーズに最適な動作です。Cursor 公式の Agent ベストプラクティスでも、いきなり Agent に投げるのではなく Plan mode で骨格を作ってから実装に進む ことが推奨されています。

Background Agent はこの Agent mode を「ローカル開発機ではなく、クラウド VM 上で走らせる」拡張です。タスクが起動すると Cursor は安全な VM を確保し、GitHub アプリ経由でリポジトリをクローン、開発者が指定したベース Ubuntu イメージ（または独自 Dockerfile）でビルド環境を整え、環境変数や Secrets を注入してから実装を開始します。VM はタスクごとに ephemeral checkout で消費され、終了時には自動的に解放されます。GitHub Actions のようにイベント起動型で動かしつつ、より対話的に進められるイメージです。

並列実行を支えているのが git worktree です。Cursor は同一リポジトリで複数のエージェントをローカルに並列で動かす際、git clone の代わりに git worktree add でブランチごとに独立した作業ディレクトリを切り、エージェントごとにファイル・依存関係・変更を分離します。これにより、「エージェント 1 が Foo.tsx を編集し、エージェント 2 が同じファイルを編集する」という書き込み競合（race condition）を構造的に防げるわけです。Cursor のドキュメントは、worktree がクローンより圧倒的に軽量でディスクも食わない点を強調しています。Background Agent（クラウド VM 側で動くケース）は VM 自体がリポジトリをクローンするため、worktree はローカル並列実行の話と区別して理解すると整理しやすくなります。

エージェントの挙動を制御する仕組みも複数用意されています。AGENTS.md（リポジトリトップに置く、コードベース全体のガイド）または .cursor/rules/（ファイルパターンごとに適用される細かい規約）に、プロジェクト固有のコーディング規約・スタックの好み・テスト戦略を書き込んでおくと、エージェントは毎回の対話でこれを参照します。「TypeScript では interface ではなく type を使う」「テストは Vitest で書く」「コミットメッセージは Conventional Commits に従う」といったチーム規約を集約すると、誰が Background Agent を呼んでも同じ品質の差分が返ってきます。さらに、/ トリガーで呼べる SKILL.md や、.cursor/hooks.json による自動ループ実行（テストパスまで繰り返す等）も用意されており、エージェントの「監督」をコードで定義できる設計です。

最大 8 並列の Background Agent — 使い分けパターン

Cursor 2.0 以降は、最大 8 並列で Background Agent を走らせる構成がコミュニティで広く採用されています。並列エージェントの最大数は公式ドキュメントで上限が明示されていませんが、コミュニティで共有されている .cursor/worktrees.json のセットアップでは 1〜8 のタスク番号を atomic な directory lock で取り合う実装が事実上のデファクトになっており（forum.cursor.com の関連スレッド参照）、本記事もこのコミュニティ事例を前提に話を進めます。

設定ファイルの骨格は次のようになります（Unix 系向けの抜粋）。

{
  "setup-worktree-unix": [
    "cp $ROOT_WORKTREE_PATH/.env .env",
    "mkdir -p $ROOT_WORKTREE_PATH/.cursor-parallel/$CURSOR_SESSION_ID",
    "for i in 1 2 3 4 5 6 7 8; do mkdir $ROOT_WORKTREE_PATH/.cursor-parallel/$CURSOR_SESSION_ID/$i 2>/dev/null && echo $i > .agent-id && break; done",
    "pnpm install"
  ]
}

このスクリプトは「セッションごとに .cursor-parallel/<session>/<n> というロックディレクトリを作り、最初に成功したエージェントがその番号を .agent-id として保持する」という仕組みです。エージェントへの初期プロンプトに「.agent-id を読んで、自分の番号に対応するサブタスクだけを実行せよ」と書き添えておけば、同じ指示で起動された 8 エージェントが衝突せずに別タスクを担当します。

実務で機能している運用パターンを 3 つ紹介します。

パターン 1: 同一タスクの多モデル並列実行。同じ実装課題に対して Composer 2 / Claude Opus 系 / GPT-5 系などを並列に当て、最も筋の良い差分を採択する、いわば AB テスト的な使い方です。1 つのエージェントに任せた結果に依存しなくなるため、難しいリファクタリングや初見のフレームワーク導入で効果的です。Cursor 自身も「複数モデルを同時に走らせて結果を比較する」ことを Agent best practices で推奨しています。

パターン 2: バグ修正・調査の仮説並列。「テストが落ちる原因を 3 つの仮説で並行調査」「パフォーマンス低下を異なる切り口で分析」のように、同じ問題に対する複数仮説を別エージェントに割り当てます。最初に当たりを引いたエージェントの結果が他より圧倒的に早く出ることもあり、原因特定の時間を体感で大きく短縮できます。

パターン 3: 大規模リファクタの水平分割。「20 個の API ハンドラを並列で Zod スキーマ化する」「30 個のコンポーネントを並列で新デザインに置き換える」など、独立性の高い修正を 4〜8 並列で分担する使い方です。.agent-id で担当範囲を分けることで衝突を回避し、合流時には worktree ごとに PR を切ってマージ順を制御します。

注意点として、「並列にしたい」と「並列にできる」は別物です。複数エージェントが同じファイルを触る並列構成では、最終的に手動でコンフリクト解決が必要になり、並列化のメリットが消えます。並列に向くのは「独立性が高く、エージェントごとに作業ファイルがほぼ重ならない」タスクです。並列導入の前に、タスクを 「ファイル単位で分割可能か」「テストで自動検証できるか」「マージ順序を決められるか」 の 3 観点でチェックすると失敗が減ります。

リモートトリガー — Slack / GitHub / モバイルから起動する

Background Agent のもう一つの真価は、Cursor のエディタを開かなくてもタスクを起動できる点にあります。Cursor は 2025 年 6 月にリリースした 1.1 バージョンで Slack からの Background Agent 起動を解禁し、その後 GitHub アプリ・モバイル・Web ダッシュボードからの起動も整備しました。

Slack @Cursor の基本構文は次のようなものです。

@Cursor fix the failing test in src/checkout/cart.test.ts

@Cursor in cursor-app, refactor the auth middleware to use the new session helper

@Cursor in marketing-site branch=staging autopr=false build a hero section variant for the A/B test

@Cursor with opus, investigate why webhook retries fail on Sundays

@Cursor list my agents

@Cursor settings

@Cursor でメンションすると Cursor の Slack ボットがスレッドを最初から読み、コンテキストを踏まえたうえでクラウド VM 上に Background Agent を起動します。in <repo> でリポジトリを明示、branch=<branch> で対象ブランチ指定、autopr=false で PR の自動作成を抑止、with <model> で使用モデルを指定できます。@Cursor list my agents は自分が起動した進行中のエージェント一覧を返し、@Cursor settings でデフォルトモデル・リポジトリ・ブランチを設定できます。Routing rules を設定しておけば、「#frontend チャネルでメンションされたら marketing-site をデフォルトリポジトリに」のような自動振り分けも可能です。

GitHub からのトリガーは 2 系統あります。1 つは Cursor の GitHub アプリを介して Issue を起点に Background Agent を起動するルートで、Issue のテンプレートに @cursor メンションを埋め込んでおくと、新しい Issue が作成された瞬間にエージェントが作業を始めます。もう 1 つは PR 自動レビュー（Bugbot）で、push 時に PR 全体を読み、改善提案・潜在バグの指摘・テスト追加の提案などをコメントとして返します。@cursor メンションに対する PR コメントベースの追加修正依頼も同様に動作します。

モバイル / Web からの起動は、cursor.com/agents から行えます。スマートフォンの Cursor アプリでも進捗を確認でき、外出先からタスクを起動して結果を確認するワークフローが構成可能です（「リファクタを 1 件投げて午後の会議までに PR を確認する」「障害対応で SSH もエディタも開けない状態から、まずバグ修正の調査を Background Agent に渡しておく」など）。

Bugbot の PR 自動レビュー機能は 2026 年 5 月時点ではベータ段階で順次提供されており、機能範囲・対応プランは変動する可能性があります。最新はCursor 公式ドキュメントを参照してください。

セキュリティ面で押さえておくべきは 3 点です。第一に、**クラウド VM はタスクごとに ephemeral（一時的・使い捨て）**であり、終了後に環境ごと破棄されます。第二に、GitHub アプリの権限スコープは導入時に明示的に設定され、リポジトリ単位で読み書き権限を絞れます。第三に、Privacy Mode を有効にすれば、Slack の外部チャネルや共有メンバーが多いチャネルにエージェント結果のサマリを表示しないようにできます。組織で導入する際は、GitHub アプリの権限・Slack の Workspace 権限・Cursor のチーム設定で「誰がどのリポジトリにエージェントを起動できるか」を整理しておくのが定石です。

料金プラン — Free / Pro / Pro+ / Ultra の 4 階層

Cursor の料金は Free / Pro $20 / Pro+ $60 / Ultra $200 の 4 階層プランに、フロンティアモデル利用分の従量課金が組み合わさる設計です。2026 年 5 月時点の構成は次の通りです。

プラン	月額	主な内容
Free（Hobby）	$0	Tab 補完の制限あり、月次のチャット利用枠は小規模
Pro	$20	$20 相当のフロンティアモデル利用枠を含む
Pro+	$60	$60 相当のフロンティアモデル利用枠を含む
Ultra	$200	優先キューと拡大された利用枠
Business / Enterprise	個別見積もり	SSO、組織管理、Self-Hosted Cloud Agents など

※ 2026 年 5 月時点。最新の料金・枠は cursor.com/pricing で確認してください。

各フロンティアモデルのリクエストは request equivalent という単位で消費され、入力・出力トークンに応じて重み付けされます。たとえば Claude Opus は Sonnet と比べて数倍速く枠を消費するため（具体的な倍率はCursor の使用量ドキュメントで公開されているモデル別の重み付け表を参照）、Composer 2 の Fast / Standard と外部フロンティアモデルを組み合わせる際は、「重い推論は Composer 2 Standard と外部モデルで分担し、補完と短いチャットは Composer 2 Fast に寄せる」のがコスト最適化の基本になります。

API 従量課金も併用可能で、サブスクリプション枠を使い切ったあとはトークン単価ベースの課金に切り替わります。Background Agent を本格運用する場合、最初の 2〜3 週間は metered spend のダッシュボードを見ながら、どのモデルがどれだけ枠を食うかをモニタリングするのが現実的です。Pro+ や Ultra への昇格判断は、Background Agent の典型的なトークン消費量から逆算すると、**「並列エージェントを常時 3〜4 つ走らせる運用が定着しているか」**が損益分岐の目安になります。

ツール比較 — Cursor を Claude Code・Cline と並べて選ぶ

Cursor は「エディタとクラウドを横断するエージェント基盤」というポジションにありますが、AI コーディングの市場には設計思想の異なる選択肢が並んでいます。代表的な 3 つを比較します。

観点	Cursor	Claude Code	Cline
インタフェース	エディタ統合（VS Code フォーク）＋ Slack / GitHub / モバイル	ターミナル CLI	VS Code 拡張機能
主要モデル	Composer 2（自社）＋ 外部フロンティアモデル	Claude Sonnet / Opus / Haiku	ユーザーが API キーで選択
並列実行	git worktree で最大 8 並列、Slack から起動可	複数セッション可、worktree 利用は手動	単一セッションが基本
エージェントの「居場所」	クラウド VM（Background Agent）＋ ローカル	ターミナル（ローカル中心、CI 連携可）	ローカル（拡張機能内）
料金モデル	月額 $20 〜 $200 階段＋従量	プラン込み or API 従量	拡張機能は無料、API 料金は自前
強み	補完体験＋エージェント基盤の統合度、Slack からの起動	CLI ネイティブで CI/CD・スクリプト連携が自然、MCP 拡張	API キー直接利用で完全に開放的、コスト管理が透明

Cursor を選ぶシナリオは次のような場面です。エディタでの補完体験を維持したまま、長尺タスクは Background Agent に任せたい。Slack やモバイルからエージェントを起動して、エディタ非接続時にも仕事を動かしたい。複数エージェントを git worktree で並列実行し、ベストな結果を採択するワークフローを試したい。チームに非エンジニアメンバー（PdM・デザイナー）がいて、Slack ベースでエージェントを呼べる体験を提供したい。

Claude Code を選ぶシナリオはターミナルネイティブの作業フローが中心で、CI/CD パイプラインや GitHub Actions にエージェントを組み込みたい、MCP を介して社内 DB や API にエージェントを接続したい、エディタを乗り換えずに既存環境（VS Code・JetBrains・Vim）と併用したい、といった文脈です。設計思想の違いはClaude Code vs Cursor 徹底比較、Claude 自体のエージェント基盤としての位置付けはClaude Agent SDK 実装ガイドを参照してください。

Cline を選ぶシナリオは、API キーを自分で管理しコスト・モデル選択を完全コントロールしたい、Cursor のような独自モデルにロックインされたくない、VS Code を素のまま使い続けたい、といった場面です。Cursor を主軸にしつつ「コスト透明性が必要な検証案件には Cline」を併用するチームも増えています。AI コーディングツール全体の比較はAIコーディングツール徹底比較 2026、観点別の早見表はAIコーディングツール比較表 2026で詳しく整理しています。

3 ツールの選定は「チーム全体に効く基盤として何を採るか、補助線としてどれを足すか」の組み合わせ問題です。Cursor を採用しても Claude Code を CI に組み込む構成は十分に成立し、その逆も同様です。Cursor は「エディタ中心＋ Background Agent ＋ Slack 起動」というカバレッジが広いため、組織横断の標準ツールとして採用するチームが増えています。AI コーディングが組織の開発速度に与える影響はAIコーディングで開発速度が変わる理由と落とし穴でも分析しています。

導入手順とベストプラクティス — 6 ステップで本格運用へ

Cursor の本格運用は、インストール → GitHub 接続 → Slack 連携 → ルール整備 → worktree 設定 → AGENTS.md の 6 ステップで完成します。

1. Cursor のインストール: cursor.com からデスクトップアプリをダウンロードし、Pro プラン（または上位プラン）で初期設定を済ませる。アカウントは GitHub / Google で SSO 可能
2. GitHub アプリの接続: Settings → Integrations → GitHub から Cursor の GitHub アプリをインストールし、Background Agent で読み書きさせるリポジトリを選択する
3. Slack 連携: ワークスペース管理者が Settings → Integrations から Slack アプリを接続し、対象チャネルで /invite @Cursor を実行。@Cursor settings でデフォルトリポジトリ・ベースブランチ・モデルを設定
4. .cursor/rules/ の整備: プロジェクトのコーディング規約、テスト方針、コミットルール、許可するコマンドのホワイトリストを書く。「pnpm install は許可、rm -rf は要承認」のような粒度でハードガードを入れておく
5. .cursor/worktrees.json の設定: 並列エージェントを使う前提なら、依存関係のインストール・環境変数のコピー・.agent-id 取得を含むセットアップスクリプトを用意する
6. AGENTS.md の整備: リポジトリのトップに、コードベースの構成・主要ディレクトリの意味・テスト実行コマンド・デプロイフローなどエージェントが知っておくべき高レベルの情報を 1 ファイルにまとめる

運用時のベストプラクティスは次のチェックリストにまとめられます。

• Plan mode で骨格を作ってから Agent mode に切り替える: 計画と実装を分けるだけで、後戻りが大幅に減る
• .cursor/rules/ は短く保つ: スタイルガイド全体を貼らない。コマンド・パターン・参照すべき canonical な例の場所だけを書く
• タスクを切ったら新しい会話を始める: 長い会話はノイズが蓄積する。前回の文脈は @Past Chats で参照できる
• テストを Verify ループの中核に置く: pnpm test がパスしたら成功、という基準を .cursor/hooks.json に埋め込み、エージェントが自動で再試行できるようにする
• 並列エージェントは「独立タスク」だけ: 依存があるタスクを並列にしない。並列にするなら結合点をテストで保護する
• Bugbot を PR レビューに必ず挟む: 人手レビューの前にエージェントレビューを 1 段かませると、形式的な見落としが激減する
• Privacy Mode を組織標準に: 個人のサマリが Slack の他チャネルに出ない設定をデフォルトにすると、機密性とトレーサビリティのバランスが取れる

トラブルシューティング — 4 つの典型症状と対処

Composer 2 の応答が遅いときは、まず Fast への切り替えを試します。それでも遅い場合は、長期化した会話のコンテキストを /clear（または新規チャット）で整理し、不要なファイルがコンテキストに積まれていないかを @Folders などで確認します。リポジトリ全体をコンテキストに乗せるような粒度の指示を避け、関係するモジュールに範囲を絞るのも有効です。

並列エージェントがマージコンフリクトを起こす場合は、.agent-id で担当範囲が正しく分離されているかをまず確認します。同じファイルを別エージェントが触る構成になっていれば、それは「並列化に向いていないタスク」のサインです。worktree 単位で PR を切り、マージ順序を明示的に管理する（依存があるなら直列に流す）か、タスクを再分割します。

Slack から起動できない症状は、@Cursor がスレッドに招待されているか、Workspace 管理者が Cursor の Slack アプリを承認済みか、対象リポジトリで GitHub アプリが有効になっているかを順に確認します。OAuth トークンが期限切れになっている場合は、Cursor のダッシュボードから Slack / GitHub の再連携を行うと復旧します。

Background Agent が長時間応答しないケースでは、Cursor のダッシュボードからエージェントのログを開きます。多くは「依存関係のインストールで詰まっている」「テストが無限ループ気味になっている」「外部 API へのアクセスで Rate limit に当たっている」のいずれかで、ログから原因が特定できます。タイムアウトに達した場合はエージェントが自動終了し、Slack スレッドにエラーが通知されます。

よくある質問 — Cursor Composer 2 に関する 6 つの疑問

まとめ — Cursor は「エディタとクラウドを横断するエージェント基盤」になった

Cursor は 2025 年 10 月の 2.0、2026 年 3 月の Composer 2、4 月の Cursor 3 を経て、エディタ統合型の AI コーディングツールから、エディタ・クラウド・Slack を横断するエージェント基盤へと進化しました。Composer 2 は性能・速度・コストのバランスが大きく改善し、Agent mode と git worktree は最大 8 並列の Background Agent を現実的な運用パターンに引き上げ、Slack / GitHub / モバイルからのリモート起動はエディタを開かないままタスクを動かす体験を可能にしました。

組織として導入する場合は、.cursor/rules/ でコーディング規約と許可コマンドを定義し、.cursor/worktrees.json で並列基盤を整え、Slack 連携と GitHub アプリで非エンジニアメンバーを含む全員がエージェントを呼べる導線を作るのが基本構成です。Claude Code・Cline と排他で語るのではなく、Cursor を主軸にしつつ補助線として組み合わせる視点で全体設計を見直すと、AI コーディングの投資対効果が大きく変わってきます。

関連記事

• Claude Code vs Cursor 徹底比較
• AIコーディングツール徹底比較 2026
• AIコーディングツール比較表 2026
• Claude Agent SDK 実装ガイド
• AIコーディングで開発速度が変わる理由と落とし穴