コーディネーターエージェントは実際に何をするのですか？

計画と委譲、そして受け取りです。公式の説明では、コーディネーターは利用者に代わってエージェントを作成・管理し、作業に必要なだけ並列で実行します。英語の原文では thousands of subagents に委譲すると表現されています。実装そのものは委譲された側が行い、コーディネーター自身はコードを書きません。手元のマシンでのテストが要る場面では、コーディネーターがローカルエージェントを起動して、そちらで実行させます。つまり利用者が受け取るのは途中経過ではなく、確認すべき完成物です。

Cursor Projects の料金はいくらですか？

公表されていません。Projects を告知した公式ページには、料金の記載も、利用できるプランの条件の記載もありません。並列で動くエージェントの数が作業量に応じて変わる設計なので、従量の単価が分からないうちは月額の見通しを立てられません。社内展開を検討するなら、料金とプラン要件が公式に示されてから判断するのが安全です。先に試すとしても、個人または小さなチームの範囲に留め、消費の実績を見てから広げる順序をおすすめします。

ノート PC を閉じても作業は続きますか？

続きます。公式の説明は、Project がクラウド上の専用マシンで動くため、ノート PC を閉じても止まらないと明記しています。ただし例外があり、手元のマシンでの実行が必要なテストについては、コーディネーターがローカルエージェントを起動してそちらで走らせます。この部分は当然ながら手元の環境が使える状態であることが前提になります。クラウド側だけで完結する作業と、手元の環境に依存する作業が分かれている点は、運用を組むときに押さえておく価値があります。

Slack 連携ではどのようなことができますか？

公式が挙げているのは、コーディネーターに Slack チャンネルを監視させる使い方です。例として、バグ報告用のチャンネルをつなぐと、バグが届くたびに委譲を始める形が示されています。ほかにスケジュールでの実行と、自分の PR をすべて追跡する購読も挙げられています。共通しているのは、利用者のプロンプトを待たずに、検知した信号をもとに動き出せる点です。起動条件を人間の指示の外に置ける一方で、何を起動条件にするかの設計責任は利用者側に残ります。

既存の Cursor の使い方と何が変わりますか？

人間が置かれる位置が変わります。これまでは人間がタスクを切り、エージェントに渡し、結果を読み、次を決める流れでした。Projects ではその切り分けと配布をコーディネーターが担い、人間には完成物の確認が回ってきます。速くなるかどうかは、任せる作業の仕様をどれだけ具体的に書けるかで変わります。何を作るかが曖昧なまま委譲すると、並列で動いた分だけ確認の量が増えます。まずは仕様を文章で書き切れる作業から試すのが現実的です。

ツール導入

Cursor Projects とは — コーディネーターエージェントが実装を委譲する設計を読む

Cursor が 2026 年 9 月 10 日に公開した Projects は、自分ではコードを書かないコーディネーターエージェントが実装を委譲し、完成物を利用者に確認させる仕組みです。クラウド上の専用マシンでの実行、手元でのテストに使うローカルエージェント、Slack やスケジュールを起点にした自律起動まで、公式発表で確定している事実を整理し、委譲の構造を実運用している AI 駆動開発のクリエイティブスタジオの視点で要点を読み解きます。

Hayate/ バックエンドエンジニア·2026年9月15日公開·約 8 分で読めます

#Cursor#AI エージェント#マルチエージェント#AI 駆動開発#開発運用

Cursor Projects とは — コーディネーターエージェントが実装を委譲する設計を読む

2026 年 9 月 10 日、Cursor が Projects をベータとして公開しました。公式 Changelog は、同日から全ユーザーへ順次ロールアウトすると案内しています。

発表の中身を読むと、これは 1 つのエージェントを賢くする更新ではありません。作業を配る側のエージェントを新しく置くという、構造の変更です。公式の表現では、コーディネーターエージェントは自分ではコードを書かず、作業を計画し、実装するエージェントに委譲し、完成したものを利用者に確認させます。

AI コーディングツールの比較記事を読んでいると、話題はモデルの賢さや補完の精度に寄りがちです。今回の Projects は、その軸とは別のところを触っています。ツール選定の一般的な観点は AI コーディングツールの選び方にまとめていますが、この記事では Projects が持ち込んだ委譲の構造だけに絞って読み解きます。

公式発表で確定している事実

まず、一次情報で確認できる範囲を整理します。公式 Changelog に書かれていない内容は、この記事でも書きません。

項目	公式の説明
コーディネーター	自分ではコードを書かない。作業を計画し、実装するエージェントに委譲し、完成物を利用者に確認させる
並列の規模	利用者に代わってエージェントを作成・管理し、作業に必要なだけ並列で実行する
実行場所	Project はクラウド上の専用マシンで動き、ノート PC を閉じても止まらない
ローカルでの実行	手元のマシンでのテストが必要なとき、コーディネーターがローカルエージェントを起動する
イベント購読	Slack チャンネルの監視、スケジュール実行、すべての PR の追跡
提供状況	ベータ。2026 年 9 月 10 日から全ユーザーへ順次ロールアウト
料金・プラン要件	公式ページに記載がない

英語の原文で目を引くのは、委譲先の規模を "thousands of subagents" と表現している点です。日本語にすると数千のサブエージェントへの委譲になります。数の大きさそのものより、並列の数を人間が決めないという設計思想が読み取れる箇所です。

コーディネーターが「コードを書かない」ことの意味

公式が最初に説明しているのは、コーディネーターが自分では実装しない点です。ここは読み飛ばしやすいのですが、役割分担として見ると明確な選択があります。

計画する主体と実装する主体を分けると、計画側の文脈が実装の詳細で埋まりません。1 つのエージェントに計画も実装も持たせると、作業が進むほど会話の履歴が実装の細部で占められ、最初に決めた全体像が薄まります。実装を別のエージェントに出してしまえば、コーディネーター側には仕様と進捗だけが残ります。

この構造を図にすると次のようになります。

flowchart LR
  E["イベント<br/>Slack / スケジュール / PR"] --> C
  U["利用者の依頼"] --> C["コーディネーター<br/>計画・委譲・受け取り"]
  C --> A1["実装エージェント"]
  C --> A2["実装エージェント"]
  C --> L["ローカルエージェント<br/>手元でのテスト"]
  A1 --> C
  A2 --> C
  L --> C
  C --> R["利用者が完成物を確認"]

利用者から見ると、やりとりする相手が 1 つに減ります。並列でいくつのエージェントが動いているかを把握する必要はなく、受け取るのは確認すべき完成物です。

要点

委譲の構造では、人間の仕事が「作業を切って配る」から「上がってきたものを採用するかどうか決める」へ移ります。判断の回数は減りませんが、判断の対象が途中経過から成果物に変わります。

実行場所が 2 つに分かれている

Projects の説明でもう 1 つ具体的なのは、実行場所の扱いです。Project はクラウド上の専用マシンで動くため、ノート PC を閉じても作業は止まりません。一方で、手元のマシンでの実行が必要なテストについては、コーディネーターがローカルエージェントを起動してそちらで走らせます。

つまり作業は、クラウドで完結するものと、手元の環境に依存するものに分かれます。この分割は、Cursor の Self-Hosted Machines の考え方と地続きです。推論と計画はクラウド側、実行は環境を持っている側、という役割分担が共通しています。

運用の観点で先に決めておきたいのは、どの作業を「手元でしか通らない」と定義するかです。社内ネットワークからしか届かない依存、ローカルの認証情報、実機が要る検証。ここが曖昧なままだと、クラウド側で走らせた作業が最後のテストで止まり、止まった理由の切り分けに時間がかかります。

委譲を回している側から見た要点 1 — 介入は非同期になる

ここからは、コーディネーターが実装者に委譲する構造を実際に回している側の視点で読みます。私たちは Orca の orchestration で Claude Code と Codex を複数のワーカーとして動かしており、その運用で分かったことがあります。詳細は Orca orchestration で Claude と Codex を組ませた記録に書きました。

委譲を挟むと、途中で方針を変えたくなったときの伝わり方が変わります。人間が 1 つのエージェントと直接やりとりしているときは、誤った瞬間に止められます。委譲の層が入ると、指示は受信箱に投函される形になり、届くのは相手が次に確認したときです。書いている手を止める割り込みにはなりません。

この性質は、委譲を挟む仕組みに共通します。Cursor の公式ページには、途中で追加の指示をどう渡すか、割り込みが実装側にいつ届くかの記載がありません。実際に使うなら、ここは最初に確かめる価値がある挙動です。

非同期であることを前提にすると、書き方が変わります。判断が要る分岐は仕様の段階で先に潰しておくか、作業を小さく刻んで報告の回数を増やす。委譲の粒度は、任せられる量ではなく、途中で気づける間隔で決めるほうが安全です。

FIXIT

数千のエージェントに任せられるって、それ全部見られるの？

Hayate

見ません。見るのは上がってきた成果物だけです。だから仕様の書き方が要になります。

FIXIT

えっ、途中で「やっぱり違う」って気づいたら？

Hayate

委譲を挟むと、止めるのが一拍遅れます。刻んで報告させるほうが結局は速いです。

要点 2 — 沈黙の中身は 1 つではない

委譲したエージェントから連絡が来ない状態には、複数の中身があります。まだ作業中で正常な場合、判断を仰ぎたくて止まっている場合、プロセスが落ちている場合。手元の運用では、この 3 つがどれも起きました。

外から見える見た目は、どれも同じ沈黙です。区別するには、完了報告のほかに質問や状況報告の経路が要ります。経路がなければ、呼び出し側が画面を読みに行って状態を解釈することになり、委譲で減らしたはずの手間が戻ってきます。

Cursor Projects については、コーディネーターがどの粒度で進捗を見せるか、委譲先が判断を仰ぐ経路を持つかが公式ページに書かれていません。試すときに見るべきは、並列数の上限ではなく 止まったときに何が見えるか です。長時間の自動実行を前提にする機能ほど、ここが運用の成否を分けます。

要点 3 — イベント購読は起動条件の外部化

Projects でもう 1 つ大きいのは、イベントを起点にできる点です。公式は、コーディネーターに Slack チャンネルを監視させる、スケジュールで実行する、すべての PR を追跡する、の 3 つを挙げています。例として示されているのは、バグ報告用の Slack チャンネルをつなぐと、バグが届くたびに委譲を始める形です。

これは、起動条件を人間の指示の外に置く変更です。従来はプロンプトを打った瞬間が起点でした。イベント購読では、検知した信号が起点になります。

効き方がはっきりするのは、起点が明確で、やることが定型に近い作業です。バグ報告から再現手順の整理まで、依存関係の更新に追随する変更、PR に対する定型の確認。逆に、何を作るかの判断そのものが仕事の中心にある作業では、起点を自動化しても人間の確認量は減りません。

注意

起動条件を外部化すると、誤って起動したときの費用も自動で発生します。料金体系が公表されていない段階では、購読を広く張る前に、消費が見える範囲で試してください。

料金とプラン要件は公表されていない

社内展開を考えるうえで避けて通れないのが費用ですが、Projects を告知した公式ページには料金の記載がありません。利用できるプランの条件についても記載がありません。

並列で動くエージェントの数が作業量に応じて変わる設計なので、単価が分からないうちは月額の見通しを立てられません。チームでの利用を検討するなら、公式が料金とプラン要件を示してから判断するのが安全です。先に触ってみる場合も、個人または小さなチームに範囲を絞り、実際の消費を見てから広げる順序をおすすめします。

Cursor をチームへ展開する手順そのものは Cursor を中規模チームに導入する手順に整理しています。新機能の可否判断より先に、どの作業を任せるかの合意が要る点は変わりません。

FIXIT の運用 — 委譲は「配る量」より「戻す間隔」で設計する

私たちは AI 駆動開発のクリエイティブスタジオとして、複数のコーディングエージェントを並列で走らせる体制を実務で回しています。難所のレビューは上位モデルに寄せ、数で回す調査は軽いモデルに振り分ける、といった使い分けも同じ枠組みの中にあります。

その運用で分かったのは、委譲の設計で決定的なのは並列数ではないということです。どれだけ配れるかより、どれだけの間隔で戻ってくるか。 戻る間隔が長いほど、方針のずれが大きくなってから発覚します。並列数を増やせば、ずれたまま進んだ作業が同時に増えます。

もう 1 つは、仕様を書く力がそのまま成果に出ることです。実装を委譲する構造では、人間が触れるのは入口の仕様と出口の成果物だけになります。曖昧な仕様を配ると、曖昧な成果物が並列で戻ってきます。エージェントが速くなるほど、仕様を書き切れるかどうかの差が広がります。

Projects の設計は、この 2 点を利用者側に残しています。並列の数は自動で決まりますが、何を任せるかと、どの間隔で確認するかは人間の側の仕事です。

試すなら、仕様を文章で書き切れる作業から

Cursor Projects は、AI コーディングツールの競争軸が「1 回の生成の質」から「委譲と確認の設計」へ移りつつあることを示す更新です。同じ方向の動きは、Cursor の Self-Hosted Machines や Orca の worktree ごとの並列実行にも現れています。

最初の一歩としておすすめするのは、仕様を文章で書き切れる作業を 1 つ選んで委譲してみることです。依存関係の更新への追随、定型のリファクタリング、再現手順の整理。任せた結果より先に、仕様を書く工程で自分が何に詰まったかを記録してください。そこが、委譲を前提にした体制へ移るときに最初に埋めるべき差になります。

ツールの導入と定着を体系立てて進めたい場合は AI 開発ツール定着支援をご覧ください。自社の開発フローに委譲の仕組みをどう組み込むかは、お問い合わせから個別にご相談いただけます。

よくある質問

Q. Cursor Projects とは何ですか？: Cursor が 2026 年 9 月 10 日にベータとして公開した機能で、同日から全ユーザーへ順次ロールアウトされています。中心にあるのはコーディネーターエージェントです。公式の説明では、コーディネーターは自分ではコードを書かず、作業を計画し、実装するエージェントに委譲し、完成したものを利用者に確認させます。Project はクラウド上の専用マシンで動くため、ノート PC を閉じても作業は止まりません。1 つのエージェントを賢くする更新ではなく、作業を配る側のエージェントを置く構造の変更だと読むのが実態に近いです。
Q. コーディネーターエージェントは実際に何をするのですか？: 計画と委譲、そして受け取りです。公式の説明では、コーディネーターは利用者に代わってエージェントを作成・管理し、作業に必要なだけ並列で実行します。英語の原文では thousands of subagents に委譲すると表現されています。実装そのものは委譲された側が行い、コーディネーター自身はコードを書きません。手元のマシンでのテストが要る場面では、コーディネーターがローカルエージェントを起動して、そちらで実行させます。つまり利用者が受け取るのは途中経過ではなく、確認すべき完成物です。
Q. Cursor Projects の料金はいくらですか？: 公表されていません。Projects を告知した公式ページには、料金の記載も、利用できるプランの条件の記載もありません。並列で動くエージェントの数が作業量に応じて変わる設計なので、従量の単価が分からないうちは月額の見通しを立てられません。社内展開を検討するなら、料金とプラン要件が公式に示されてから判断するのが安全です。先に試すとしても、個人または小さなチームの範囲に留め、消費の実績を見てから広げる順序をおすすめします。
Q. ノート PC を閉じても作業は続きますか？: 続きます。公式の説明は、Project がクラウド上の専用マシンで動くため、ノート PC を閉じても止まらないと明記しています。ただし例外があり、手元のマシンでの実行が必要なテストについては、コーディネーターがローカルエージェントを起動してそちらで走らせます。この部分は当然ながら手元の環境が使える状態であることが前提になります。クラウド側だけで完結する作業と、手元の環境に依存する作業が分かれている点は、運用を組むときに押さえておく価値があります。
Q. Slack 連携ではどのようなことができますか？: 公式が挙げているのは、コーディネーターに Slack チャンネルを監視させる使い方です。例として、バグ報告用のチャンネルをつなぐと、バグが届くたびに委譲を始める形が示されています。ほかにスケジュールでの実行と、自分の PR をすべて追跡する購読も挙げられています。共通しているのは、利用者のプロンプトを待たずに、検知した信号をもとに動き出せる点です。起動条件を人間の指示の外に置ける一方で、何を起動条件にするかの設計責任は利用者側に残ります。
Q. 既存の Cursor の使い方と何が変わりますか？: 人間が置かれる位置が変わります。これまでは人間がタスクを切り、エージェントに渡し、結果を読み、次を決める流れでした。Projects ではその切り分けと配布をコーディネーターが担い、人間には完成物の確認が回ってきます。速くなるかどうかは、任せる作業の仕様をどれだけ具体的に書けるかで変わります。何を作るかが曖昧なまま委譲すると、並列で動いた分だけ確認の量が増えます。まずは仕様を文章で書き切れる作業から試すのが現実的です。