YouTube動画で、Claude Projectsという機能が紹介されており、これに似た機能として、Cursor Projectsがあるということだった。これらの機能は大規模ソフト開発向きの機能とのことで、私にはあまり関係がないようにも思えるが、私が契約しているプランでも、Cursor Projectsが使えるということだったので調査し比較してみた。
調査方法は、まず、ChatGPT-6を用いて調査を行なった後、Grok Botにも質問を行って進めた。
注）本記事の内容は正確性を保証するものではありません。
（2026年10月19日 追記）YouTube動画を追加しました。 https://youtu.be/n3ZQQgQPmuo
2つのProjectsの比較 — AIが「作業をする」から「仕事を管理する」時代へ
最近、Claude Projectが使えるようになったというニュースがあったため、Cursor Projectと比較したいと思います。多分、私には縁遠いもののように思いますが、深掘りできるようならブログ記事にしたいと思います。これらについてあらためて解説し、比較表を作成してください
（以下、ChatGPT-6の回答）
調べたところ、今回のニュースは、単なる「プロジェクト管理機能」の追加ではありません。
- Cursor Projects：2026年9月10日発表
- Claude Projects（新版）：2026年9月17日発表
両社とも、複数のAIエージェントを使い、長期間にわたる仕事をまとめて進める新しい仕組みを発表しています。
特に興味深いのは、ユーザーが個々のAIに作業を指示するのではなく、仕事全体の目的を与え、AIが必要な作業を分担・調整するという方向性です。
これは、従来のチャット型AIから一歩進んだ使い方です。
結論からいうと、現時点では両者ともソフトウェア開発との結び付きが強く、一般的な個人利用には少し大がかりです。
しかし、ブログ記事にする価値は十分にあります。特に、Grok BotのSupervisorを使った複数Botの管理や、OpenAIのWork、Dotsなどと比較すると、AIの進化の方向性を説明する興味深い記事になりそうです。
1. そもそも、何が新しくなったのか？
ここで注意したいのは、ClaudeのProjects自体は以前から存在していたことです。
従来は、チャット、資料、指示などを整理するためのワークスペースでした。
新版では、1つの仕事を複数の実行スレッドに分け、Claudeが並列作業の進行を調整します。
コーディネーター役のAIが仕事を計画し、複数のエージェントに実装を任せ、完成した成果をユーザーに届けます。
クラウド上で動作し、定期的な作業や外部イベントに応じた実行にも対応します。
両製品が目指しているのは、AIとの関係を次のように変えることです。
※図は概念的な説明です。ClaudeとCursorの内部構成が完全に同一という意味ではありません。
2. Claude ProjectsとCursor Projectsの比較表
今回の比較対象は、従来型のClaude Projectsではなく、2026年9月に発表された新版です。
| 比較項目 | Claude Projects（新版） | Cursor Projects |
|---|---|---|
| 提供元 | Anthropic | Cursor |
| 発表日 | 2026年9月17日 | 2026年9月10日 |
| 主な目的 | 複数の仕事をAIが管理・遂行 | 大規模なソフトウェア開発をAIが管理 |
| 想定ユーザー | 当面は開発者中心。一般業務への拡大も予定 | ソフトウェア開発者・開発チーム中心 |
| 指示方法 | プロジェクト全体の目的を伝える | コーディネーターに目的を伝える |
| 管理役のAI | コーディネーター | コーディネーター |
| 作業担当 | 複数のスレッドとサブエージェント | 複数のエージェント |
| 並列実行 | 対応 | 対応 |
| 長期的な情報保持 | 共有メモリとLibrary | 共有ファイル・蓄積される作業情報 |
| クラウド実行 | 対応 | 対応 |
| PCを閉じた後も処理継続 | 対応 | 対応 |
| ローカルPCでの実行 | 今後の拡張予定 | 必要に応じてローカルエージェントを利用 |
| 定期・イベント駆動 | 今回の新版発表ではCursorほど明確ではない | スケジュール、Slack、PRなどに対応 |
| 途中経過の確認 | メインチャットと各スレッド | コーディネーターのチャットとエージェント |
| GitHubなどのコード管理 | リポジトリ連携・PR作成 | リポジトリ連携・PR管理 |
| 文書作成 | 公式に対応例あり | 可能な作業もあるが開発中心 |
| 一般利用への広がり | 比較的大きいと予想 | 開発用途が中心と予想 |
| 提供状況 | 一部のPro・Maxユーザー向けベータ | 有料プランで提供 |
| 注意点 | 並列作業で利用枠を早く消費 | 並列作業の利用量とクラウドへのコード保存 |
特に重要な違いは3つ
① Claudeは、一般業務への展開を予定している
Claudeの新版Projectsは、まずClaude Codeで提供され、今後はClaudeのチャット、Cowork、Team、Enterpriseにも展開される予定です。
つまり、将来的にはプログラミング以外の仕事をまとめて管理する仕組みになる可能性があります。
② Cursorは、自動化の仕組みが具体的
Cursorには「Subscriptions」という機能があります。
例えば、Slackのバグ報告を監視し、新しい報告が入ると、コーディネーターが修正作業をエージェントに任せます。
単に複数のAIを動かすだけではなく、外部の出来事をきっかけに仕事を開始できます。
③ 両者とも、単にチャットを保存する仕組みではない
従来型のProjectsは、資料や指示を蓄積することに主眼がありました。
新版では、進行中の仕事、作業結果、判断の経緯などを引き継ぎながら、長期間の活動を継続することに重点があります。
3. Claude Projectsの特徴を詳しく見る
新版のClaude Projectsでは、ユーザーが1つの大きな目標を与えます。
例えば、
「ブログの過去記事を分析し、古くなった情報を洗い出し、更新案を作成してほしい」
という指示を与えた場合、将来的な活用イメージとして次のような進め方が考えられます。
- Claudeが仕事全体を分析し、必要な作業を分割する。
- 複数のスレッドが記事の調査、情報の検証、修正案の作成などを並列に進める。
- コーディネーターが結果を取りまとめ、必要なら追加調査する。
- 最終的に更新案をユーザーへ提示する。
ここで大切なのは、ユーザーが作業の分け方を細かく指定する必要がないことです。
また、Claudeは作業方法やプロジェクトに関する情報を共有メモリに蓄積します。
プロジェクトに登録した資料や、AIが生成した成果物はLibraryに収集されます。
ただし、上記のブログ作業は応用例です。ブログの巡回やCMSへの反映まで、そのまま実行できることを確認したわけではありません。
制約
2026年10月18日時点で、新版は一部のClaude Pro・Maxユーザーを対象に段階的に提供されています。
現在のClaude Projectsには無料利用枠もありますが、無料で使える従来型Projectsと、新しい複数エージェント型Projectsを混同しないことが重要です。
4. Cursor Projectsの特徴を詳しく見る
Cursor Projectsは、ソフトウェア開発をかなり強く意識しています。
特徴的なのは、コーディネーターが自分でプログラムを書くのではなく、実装担当のエージェントを作成・管理する点です。
公式発表では、必要に応じて非常に多くのサブエージェントへ作業を委任できると説明しています。
Subscriptions機能が面白い
例えば、次のような設定が考えられます。
| きっかけ | AIが行う作業 |
|---|---|
| Slackにバグ報告 | 調査・修正を担当エージェントに委任 |
| 毎朝8時 | 指定された定期作業を開始 |
| GitHubにPRが作成される | PRに関連する処理を開始 |
| CIでエラーが発生 | エラーを分析し、対応作業を進める |
ユーザーからの指示を待つだけでなく、登録したイベントに反応して自動的に作業を始めるわけです。
もう一つ重要なのは、Cloud Agentsの利用です。
作業はクラウド上の専用環境で進み、必要に応じてローカル側のエージェントを起動できます。
したがって、開発用のMacを常時起動していなくても進行できる作業があります。
ただし、Mac内の機器やローカルネットワークを使う工程は別です。
「Cloud Agentsの利用」とは具体的にはどういうことですか
Cursor Projectsにおける「Cloud Agentsの利用」とは？
Cloud Agents（クラウドエージェント）とは、自分のMacではなく、Cursorが用意したクラウド上の実行環境で、AIがプログラムの作成・修正・テストなどを行う仕組みです。
通常、Cursorを使ってプログラムを開発する場合、Mac上のCursorアプリで作業します。
一方、Cloud Agentsを使うと、AIがクラウド上のコンピューターで作業を進めます。
通常のCursorとの違い
| 項目 | 通常のCursor（ローカル） | Cursor Cloud Agents |
|---|---|---|
| 作業場所 | 自分のMac | クラウド上の実行環境 |
| プログラムの編集 | Mac内のファイル | クラウドに取得したファイル |
| コマンドの実行 | Macのターミナルなど | クラウドのターミナル |
| テストの実行 | Mac上 | クラウド上 |
| Macの電源 | ローカル処理には必要 | クラウド作業には不要 |
| Mac内のファイル | 直接操作できる範囲がある | 原則として直接アクセスできない |
| 自宅LANの機器 | Macからアクセス可能 | 原則として直接アクセスできない |
| 作業結果 | Mac内のファイルに反映 | GitHubのPRなどで受け取る |
例えば、Mac miniに置いてあるPythonプログラムを修正するとします。
通常のCursorでは、Mac mini上でファイルを編集し、テストします。
Cloud Agentsでは、GitHubなどからプログラムをクラウド上に取得し、そこで修正とテストを行います。
完成した変更はGitHubのプルリクエスト（PR）などを通じて確認・取り込みできます。
つまり、Cloud Agentsは、AIが単にクラウドのAIモデルを使うという意味ではなく、AIの作業場所そのものがクラウドになる点が重要です。
5. 利用料金と利用条件
料金も比較しておきます。いずれも米ドル、税別です。
| 項目 | Claude Projects（新版） | Cursor Projects |
|---|---|---|
| 無料で試せるか | 新版は対象外 | 対象外 |
| 利用の基本条件 | Pro・Maxの対象ユーザー | Cloud Agents対応の有料プラン |
| 関連プラン料金 | Pro：月額20ドル、Max：月額100ドルから | Premium：月額30ドル、Super：月額100ドルなど |
| 利用料金の仕組み | Claudeの契約プランの利用枠を消費 | モデル・プラン別の利用枠や追加クレジットを消費 |
| 大量の並列実行 | 利用枠を早く消費する可能性 | 利用枠の消費増加に注意 |
| 追加API契約 | 通常の新版Projects利用に必須とは案内されていない | 通常のProjects利用に別途API契約は不要 |
| 利用上の制約 | ベータ提供対象が限定される | Cloud Agents利用条件・プライバシー設定に制約 |
注意したいのは、Cursorの料金体系が変更されている点です。2026年10月時点の公式料金表では、Grok・Cursor・Xを含む契約体系が案内されています。一方、以前のCursor Proなどの契約も継続しており、適用される料金や利用枠が異なります。
両者とも、プログラム開発を大量に任せるなら、利用枠の管理が非常に重要です。
6. 個人ユーザーには使い道があるのか？
私の評価では、現時点での実用性は次のようになります。
| 活用場面 | Claude新版 | Cursor |
|---|---|---|
| 複数資料の調査・整理 | 将来的に有望 | 開発外では使いにくい |
| ブログ記事の作成・更新 | 将来的に有望 | 技術的に工夫すれば可能 |
| Home Assistantの設定開発 | 可能性あり | 比較的相性がよい |
| Pythonなどのプログラム開発 | 適している | 特に適している |
| ソフトウェアの継続保守 | 適している | 特に適している |
| CarPlayニュースの収集・整理 | 一般業務への展開待ち | 専用の仕組み作りが必要 |
| 複数AIによる長期プロジェクト | 有望 | 有望 |
| 手軽な日常の質問・相談 | 過剰な仕組み | 過剰な仕組み |
評価は公式に保証された対応表ではなく、現時点の設計と提供範囲から判断したものです。
Home Assistantで使うとしたら
例えば、Home Assistantで次のような仕事を頼む場面です。
「家庭の電力データから家電の稼働を推定する仕組みを改善し、センサー定義、ダッシュボード、テストを整備する」
Cursor Projectsなら、複数のプログラムや設定ファイルを対象として、調査・修正・テストを分担させるような使い方が考えられます。
ただし、現在のHome Assistantが自宅のMac mini上の仮想環境で動いている場合、クラウドエージェントから直接アクセスできるとは限りません。ローカルエージェントとの連携や適切なアクセス制御が必要です。
実際の設定変更を伴う用途では、最初は変更案だけを作らせ、人間が承認する運用が安全です。
7. ブログ記事にするなら、Grok Botとの比較が面白い
私は、この点を掘り下げることをおすすめします。
Claude ProjectsとCursor Projectsを比較するだけでは、読者に「開発者向けの難しい機能」という印象を与えてしまうかもしれません。
しかし、Grok BotのSupervisor方式と比較すると、違いが分かりやすくなります。
| 比較項目 | Grok Bot （Supervisor方式） | Claude Projects（新版） | Cursor Projects |
|---|---|---|---|
| 全体を管理するAI | Supervisor Bot | コーディネーター | コーディネーター |
| 作業担当 | 用意した専門Botなど | 必要に応じて実行スレッドを作成 | 必要に応じてエージェントを作成 |
| 仕事の分担 | Bot構成と指示の 設計に依存 | AIが分担を調整 | AIが分担を調整 |
| 長期情報の保持 | Botの設定や保存情報を 活用 | 共有メモリ・Library | 共有コンテキスト |
| 自動実行 | Botのオートメーションなど | 新版Projects自体の定期実行仕様は要確認 | Subscriptionsを搭載 |
| 主な得意領域 | 幅広い個人・業務タスク | 当面は開発中心、拡大予定 | ソフトウェア開発 |
| 主な管理対象 | Botとその作業 | プロジェクト全体 | プロジェクト全体 |
Grok Botは設定されたBotが役割を担う仕組みを作りやすい一方、ClaudeやCursorの新版Projectsでは、作業に応じて実行担当を増やす仕組みが製品の中心にあります。
ただし、Grok Botの具体的な自律性やSupervisorの処理能力は、その構成によって変わります。
この表は機能構造の比較であり、性能比較ではありません。
8. 評価
今回のニュースは、単に便利な新機能が増えたという話ではありません。
AIへの指示が「何を作ってほしいか」から「どんな仕事を達成してほしいか」へと移行していることを示す発表です。
ただし、将来性と現在の実用性は分けて考える必要があります。
- Claude Projects：今後、文書作成や調査など一般業務まで拡張されれば、個人ユーザーにも魅力的。
- Cursor Projects：継続的なプログラム開発を行わない限り、現時点では利用する必要性が低い。
- Grok Bot：専門Botを使って日常的な監視・調査などを行う目的なら、引き続き比較する価値がある。
主な公式資料
- Anthropic：新版Projectsの発表（2026年9月17日）
- Claude：Projectsの説明と提供条件
- Cursor：Projectsの発表（日本語）
- Cursor：Projectsの公式ドキュメント
- Cursor：最新の料金とモデルの説明
以降、Grok Botによる調査結果を紹介する。
2つのProjectsを比べてみた ― AIが“現場監督”になる新機能
（調査日：2026年10月18日。どちらもベータ版で、仕様は今後変わる可能性があります。日付は特記のない限り各社公式の表記（米国時間）です。）
はじめに：同じ「Projects」でも、昔の Claude Projects とは別物
2026年の秋、AI開発ツールの2社がそろって「Projects」という新機能を出しました。
- Cursor Projects：2026年9月10日にベータ公開
- Claude Projects（Claude Code の新しいプロジェクト）：2026年9月17日にベータ公開。
10月9日（日本時間10月10日未明）に「待機リストに登録していた Pro・Max ユーザー全員に開放」と発表
ややこしいのは、Claude には2024年から 同じ名前の「プロジェクト」 があったことです。昔のプロジェクトは、資料と指示を入れておく「フォルダ」のようなもので、無料プランでも5個まで作れます。今回のニュースは、それを 「会話の中でAIが作業を割り振る仕組み」に作り直した新バージョン のことです。Anthropic 自身も記事のタイトルを「Projects redesigned: from folder to conversation（フォルダから会話へ）」としています。
最近のニュースで「Claude Project が使えるようになった」と言われているのは、この 10月9日の待機リスト全員開放 の告知を指していると考えられます（推定。ほかに該当しそうな発表は見つかりませんでした）。
Claude Projects（新バージョン）とは
ひとことで言えば、「Claude にひとつの会話で頼むと、Claude が仕事を小分けにして、何人もの作業員（スレッド）に同時にやらせ、結果をまとめて報告してくれる」 仕組みです。
- まとめ役（コーディネーター）と作業員（スレッド）。 プロジェクトの会話に依頼を書くと、Claude が「これは別スレッドでやる」「これはその場で答える」と振り分けます。各スレッドは、それぞれが一人前の Claude Code です。
- 基本はクラウドで動く。 パソコンを閉じてもスレッドは動き続けます。スマホから様子を見たり指示したりもできます。
9月23日（米国時間）には、自分のパソコンでスレッドを動かす機能（Remote Control 経由）も追加されました。 - 記憶を共有する。 「リリースは金曜に延期」「このブランチを使う」などを覚えさせると、プロジェクトのメモリー（MEMORY.md などのファイル）に残り、後から始まるスレッドも読みます。指示文は最大1万6000字まで設定できます。
- ライブラリ。 アップロードした資料と、スレッドが作ったファイルが一か所に集まります。
- コード以外にも使える。 GitHub のリポジトリを付けずに、契約書や問い合わせ記録の束を読ませて分析させる使い方も公式に例示されています。
- 定期実行。 「毎週やって」と頼むと、Claude が「ルーティン」を作ってプロジェクト内で定期的に動かします。
- 注意点。
- 使えるのは claude.ai/code、デスクトップアプリの Code タブ、スマホアプリです。
ターミナル版や VS Code 拡張では使えません。 - コードを扱うには github.com のリポジトリと「Claude GitHub App」のインストールが必要です。
- 新しいプロジェクトは、初期設定ですべてのスレッドが最上位モデル（Opus）で動くので、利用枠を早く使い切ります。新しく作れるスレッドは1日200個までです。
- Team・Enterprise プランはまだ対象外で、待機リストも残っています。
- 使えるのは claude.ai/code、デスクトップアプリの Code タブ、スマホアプリです。
Cursor Projects とは
考え方は Claude とよく似ています。「まとめ役のエージェントと話すだけで、まとめ役が計画を立て、何体ものエージェントに並行して作業させる」 仕組みです。
- まとめ役は自分でコードを書かない。 計画と割り振りに徹するので、作業中でもこちらの指示にすぐ反応できる、と説明されています。
- クラウドが基本、必要なときだけ手元で。 Cursor の Cloud Agents の上で動くので、ノートパソコンを閉じても止まりません。手元の機械で試す必要があるときだけ、まとめ役がローカルのエージェントを起動します。
- 共有コンテキスト。 プロジェクトごとにファイル群を持ち、クラウドと手元のどの機械でも同期されます。
あるエージェントが見つけた「このサービスのテスト方法」は、後のエージェントも使えます。 - 購読（Subscriptions）で自分から動く。 Slack のチャンネル、決まった時刻（例：毎朝8時）、GitHub のプルリクエストや CI を見張らせると、指示を待たずに作業を始めます。
- 大規模な実績をうたう。 公式ブログでは「何千ものサブエージェントに仕事を任せられる」「Projects を主に使う人は、マージしたプルリクエストが6倍に増えた」と紹介されています（Cursor 社内の数字）。
- その後の更新。 10月5日の週のリリースノートでは、まとめ役が別のエージェントの記録を読んだり、メッセージを送ったりできるようになりました。
比較表
| 項目 | Claude Projects（新バージョン） | Cursor Projects |
|---|---|---|
| ひとことで | Claude が会話の中で作業を小分けにし、並列のスレッドに任せてまとめる | まとめ役のエージェントが計画を立て、並列のエージェントに任せてまとめる |
| 公開日・状態 | 2026/9/17 ベータ開始 （一部の Pro・Max から）。 10/9 に待機リスト登録者全員へ開放。現在も段階展開中のベータ | 2026/9/10 ベータ開始、「全ユーザーへ順次展開」 |
| 誰向けか | 主に開発者。ただしコード以外の資料分析も公式例にある | 開発者（機能開発・移行作業・保守の「庭仕事」） |
| 動く場所 | クラウドが基本。Remote Control で自分のパソコンでも動かせる（9/23追加） | クラウドが基本。手元での確認が必要なときだけローカルのエージェントを起動 |
| 複数エージェント | ○ まとめ役と並列スレッド。スレッドの中でさらにサブエージェントも使える。 新規スレッドは1日200個まで | ○ まとめ役と並列エージェント （「何千ものサブエージェント」とうたう） |
| 記憶・文脈の引き継ぎ | プロジェクトのメモリー（MEMORY.md など）、指示（最大1万6000字）、ライブラリ | 共有コンテキスト（クラウドとローカルで同期されるファイル群） |
| 自分から動く仕組み | ルーティン（定期実行）。プルリクエストの CI 失敗やレビューコメントで自動的に起きて修正 | Subscriptions：Slack チャンネル、スケジュール、プルリクエスト・CI を見張って自動で動く |
| 必要なプラン・料金 | Claude Pro（月20ドル、年払いなら月17ドル）または Max（月100ドルから）。 Team・Enterprise は未対応。 無料プランは不可（Claude Code が含まれないため） | Cloud Agents を含むプラン：Premium（月30ドル）以上、Teams、Enterprise、旧有料プラン。 Free・Plus・旧 Hobby は不可 |
| 料金のかかり方 | プランの利用枠を消費（並列なので速く減る）。 超えた分は追加クレジットを有効にした場合のみ課金 | プランの共有利用枠（週ごとに回復）を消費。Claude などの他社モデルは API 定価で別途課金（推定：まとめ役に他社モデルを選ぶと別料金になる） |
| 必要なもの | github.com のリポジトリと Claude GitHub App（コードを扱う場合） | GitHub の接続（作業するリポジトリを選ぶ） |
| 日本語 | 公式ドキュメントとヘルプに日本語版あり。 画面と会話が日本語で使えるかは未確認（推定：会話は日本語で可能） | 公式ドキュメントに日本語版あり。 会話が日本語で使えるかは未確認（推定：可能） |
| 典型的な使い方 | 複数リポジトリへの一斉修正、大きな機能開発や移行、バグ報告を流し込み続ける保守、資料の束の継続分析 | 複数のプルリクエストにまたがる機能開発、数百件規模の移行、デザインの統一や品質維持の自動監視 |
私のプランとの関係
Cursor Projects：追加料金なしで試せる立場です。
- X の Premium サブスクリプション（月30ドル）に Cursor Premium が含まれていて、Premium は Projects の対象プランです。
- ただし、条件が二つあります。
- 作業させる GitHub のリポジトリが必要です。
- 並列で何体も動くので、Grok Bot などと共有している週ごとの利用枠を早く使い切りやすくなります（推定）。
- Claude や GPT など他社のモデルを選ぶと、API の定価で別料金になります。
正直なところ。
- どちらも、何十件ものプルリクエストを並行して進めるような、プロの開発チーム向けの道具です。
- 私の規模の開発（ブログ用のスクリプトや Home Assistant の設定）なら、普段の AI エージェントか Codex で十分間に合います。
- それでも試すなら、今の契約のまま動かせる Cursor Projects で、小さなリポジトリをひとつ題材にするのが現実的です（推定）。
- 特に面白そうなのは、「毎朝◯時に点検して、問題があれば直す」といった購読（Subscriptions）の機能です。
出典
Claude Projects
- Anthropic「Projects redesigned: from folder to conversation」（2026/9/17）：https://claude.com/resources/articles/projects-redesigned （日本語ページ：https://claude.com/ja/resources/articles/projects-redesigned）
- Claude Code Docs「Let Claude coordinate ongoing work with Projects」：https://code.claude.com/docs/en/claude-projects （日本語版：https://code.claude.com/docs/ja/claude-projects）
- Claude ヘルプセンター「プロジェクトとは何ですか？」（旧プロジェクトと新バージョンの説明）：https://support.claude.com/ja/articles/9517075
- @ClaudeDevs の投稿（2026/10/9、待機リスト全員に開放）：https://x.com/ClaudeDevs/status/2108621476538781878 と、続く投稿 https://x.com/ClaudeDevs/status/2108621479164412232
- @ClaudeDevs の投稿（2026/9/23、自分のパソコンで動かす機能を追加）：https://x.com/ClaudeDevs （投稿 ID 2102893178273874102）
- Claude の料金ページ：https://claude.com/pricing
- 報道：The Verge（2026/9/17）https://www.theverge.com/ai-artificial-intelligence/997134/anthropic-claude-code-projects ／ heise online（2026/9/18）https://www.heise.de/en/news/Claude-Code-Anthropic-turns-Projects-into-a-task-distributor-11458342.html ／ Fyve（日本語、2026/10/10）https://fyve.co.jp/claude-code/articles/claude-code-projects-who-can-use
Cursor Projects
- Cursor 公式ブログ「Introducing Projects」（2026/9/10）：https://cursor.com/blog/projects
- Cursor Docs「Projects」：https://cursor.com/docs/agent/projects （日本語版：https://cursor.com/ja/docs/agent/projects）
- Cursor Cloud Agents のリリースノート：https://cursor.com/docs/release-notes/cloud-agents
- Cursor の料金ページ：https://cursor.com/pricing
具体的な開発例
公式の例と、実際に試した人の報告を集めました。数字は出典に書かれているものだけを載せています。
（最後の3つは、あなたの環境で利用する場合の例をBotが推定したもの）
| 製品 | 何をした・何を作ったか（規模） | 出典の種類 | 出典 |
|---|---|---|---|
| Cursor | 機能開発：まずエージェントが仕組みを調べて共有コンテキストに記録し、まとめ役が計画を立てて、部品ごとの実装とテストを並行で任せる。 完成したら手元の機械で動かして確認し、リリース後も同じ Project でログを見張ったりバグ報告に対応したりする | 公式 | https://cursor.com/blog/projects |
| Cursor | 移行作業：新しいフレームワークへの乗り換えや、スタイルの仕組みの置き換えを「数百件のプルリクエスト」にわたって進めた（Cursor 社内）。 最初は1件ずつ念入りに確認し、安定してきたら確認を減らして任せる | 公式 | https://cursor.com/blog/projects |
| Cursor | デザインの統一を保つ「庭仕事」：新しいプルリクエストをすべて点検し、デザインの共通部品にすべきものを切り出し、同じ間違いを2回見つけたらチェックのルールを追加する。 「1日20〜100件のプルリクエストを扱う見込み」 | 公式 | https://cursor.com/blog/projects |
| Cursor | Slack のバグ報告チャンネルを見張る：Slack をつないでバグ報告用のチャンネルを指定すると、バグが投稿されるたびに修正を任せる | 公式 | https://cursor.com/docs/agent/projects |
| Cursor | 家庭用サーバーで動く ioBroker（スマートホーム用ソフト）のアダプターを作った：3日間、5回の作業、約14時間で、エージェント20体、タスク32件、プルリクエスト5件（うち4件をマージ）。 任せる仕組みはうまく働いたが、利用者が下した判断がメモの書き直しで消えたり、承認していない初期設定が「承認済み」扱いになったりする問題も報告 | 利用者報告 | https://forum.cursor.com/t/i-tested-the-projects-beta-for-three-days-what-worked-and-where-decisions-got-lost/172974 |
| Cursor | 空のリポジトリに仕様書を貼って、小さな自前のデータ保管アプリ「Data Vault」を作らせた：まとめ役が仕様を共有コンテキストに保存し、作業役を1体起動して全体を作らせ、プルリクエストができたら知らせると返答 | 利用者報告 | https://flaviocopes.com/cursor-projects/ |
| Claude | アプリの購入手続きの応答速度（p75）を改善する：目標を設定し、各エンドポイントの計測、最適化の試行、プルリクエスト作成を並列のスレッドで行う | 公式 | https://claude.com/resources/articles/projects-redesigned |
| Claude | 古い v1 エンドポイントを廃止する：API・ウェブ・スマホアプリのリポジトリをつなぎ、リポジトリごとにスレッドを立てて呼び出し側を移行し、テストしてプルリクエストを出す。 どれから先にマージすべきかも教える | 公式 | https://claude.com/resources/articles/projects-redesigned |
| Claude | ドキュメントの例：すべてのサービスに新しいチェック設定を適用（リポジトリごとにスレッドとプルリクエスト）、docs/spec.md に書かれたものを作る、非推奨のデータベース用ライブラリからの移行。コード以外では、問い合わせ記録をアップロードして「よくある連携ミス上位10件」を探す、契約書の束に質問し続ける | 公式 | https://code.claude.com/docs/ja/claude-projects |
| Claude | ウェブサイト一式を作らせた（2026/9/26〜28）：10スレッドでプルリクエスト11件、約2万3000行。 所要約20時間（うち約7時間は夜間）、トークン約1億9000万。 結果は「8割の下書き」で、スレッド間の担当の隙間や実データでしか出ないバグがあり、SSH でしか入れないサーバーへの公開でつまずいた | 利用者報告 | https://arte.itlibra.com/en/articles/claude-code-projects-hands-on |
| Claude | ウェブアプリの機能開発を1週間試した：並列のスレッドがお互いの変更を把握しきれず、URL の配線漏れや、どこにも飛ばないボタンなどの小さな抜けが多発した。 「作業は速いが、完成品を信頼するまでに時間がかかる」 | 利用者報告 | https://mitch-asser.kit.com/posts/i-don-t-like-claude-code-projects-at-least-for-now |
| Cursor | （推定・あなたの例） ブログ用データベースのスクリプトの保守：roompine のブログ用データベースの更新スクリプトを GitHub に置き、毎週のスケジュールで点検させる。 リンク切れや取得失敗があれば、修正のプルリクエストを出させる | 推定（あなたの例） | ― |
| Cursor | （推定・あなたの例） Home Assistant のダッシュボード改修：設定ファイルのリポジトリで、カードの追加などを作業役に分担させる。 ただし Home Assistant は自宅の LAN 内にあってクラウドから届かないので、動作確認は Mac mini のローカルのエージェントで行う形になる | 推定（あなたの例） | ― |
| Claude | （推定・あなたの例） ブログ記事の点検（コード以外の使い方）：リポジトリなしで記事の下書きや読み辞書をライブラリにアップロードし、読み間違えやすい語や事実確認の候補をスレッドに洗い出させる。 | 推定（あなたの例） | ― |
読み取れること：公式の例は、大規模な開発チーム向けの使い方が中心です。一方、利用者の報告では、個人の小さな開発でも「寝ている間に進む」効果は出ています。ただ、出てくるのは下書き段階のものです。判断の記録が消えたり、スレッドの間で抜けが出たりするので、人の確認が欠かせない、という点で報告は一致しています。
記憶の引き継ぎはどうなっているか
どちらも、エージェント同士が「ファイル」で記憶を受け渡すという考え方は同じです。違うのは、何がどこまで公式に説明されているかです。Claude は、記憶の置き場所の名前、上限、いつ読み込まれるかまで細かく書いています。Cursor の公式説明は「プロジェクトごとにファイル群があり、すべての機械で同期される」という程度で、細部は利用者の報告から分かる部分が多いです。
共有されるものの一覧
| 製品 | 共有物 | 記録される内容 | 誰がどう書くか | どう読まれるか |
|---|---|---|---|---|
| Claude | プロジェクトメモリー（MEMORY.md を目次にした複数のファイル） | 要件、決めたこと、落とし穴、利用者の好み（報告の頻度、同時に動かすスレッド数など） | Claude が書く。 「覚えて」「忘れて」と頼むと書き換え、好みは自分の判断でも保存する。 利用者は設定の「メモリー」で読む・直す・消すことができる | クラウドのスレッドは開始時に MEMORY.md を読み、ほかのファイルは必要なときに開く。まとめ役も、全履歴ではなく直近の会話・直近のスレッド・メモリーをもとに動く。 自分のパソコンで動かすスレッドには、メモリーのファイルは読み込まれない |
| Claude | プロジェクトの指示（最大1万6000字） | 目的、作業する場所（ブランチ、プルリクエストの名付け方）、完了前の確認方法、足りないものがあったときの対応、承認が必要な操作 | 利用者が設定画面で書く。 Claude に変更を頼むこともできる | 新しいスレッドすべてと、まとめ役に送られる。 自分のパソコンのスレッドにも届く。 変更が届くのはそれ以降の新しいスレッドだけ |
| Claude | ライブラリ （資料置き場） | 利用者が追加したファイル・フォルダ・Google ドライブのフォルダと、スレッドが作ったファイル | 利用者が追加する（1回で100ファイル・2GBまで、1ファイル480MBまで。 フォルダは先頭の100ファイル・200MBまで、フォルダは合計10個まで）。 スレッドは成果物をここに置く | クラウドのスレッドが /mnt/project-files から読む。アップロードはコピーなので、手元のファイルを直しても自動では反映されない |
| Claude | リポジトリの CLAUDE.md・スキル・権限設定 | リポジトリごとのルール（組み立てのコマンドなど） | 利用者（またはエージェント）がリポジトリにコミットする | クラウドのスレッドが、プロジェクトのすべてのリポジトリを複製して開始時に読み込む。 権限のルールなどが効くのはリポジトリが1つのときだけ（複数のときは効かない） |
| Claude | スレッドからの報告 | 各スレッドの完了報告 | スレッドが完了時に自動で報告する | まとめ役が読むのは報告だけで、途中の一歩一歩は見ない。 全文はスレッドを開けば利用者が読める |
| Cursor | 共有コンテキスト（プロジェクトごとのファイル群。画面上の名前は「Context」） | 調査結果、成果物、コードの仕組みについて分かったこと、利用者の作業の好み（例：あるサービスのテスト方法） | エージェントが作業しながら書き足す（公式）。 利用者の報告では、まとめ役が「Project Notes」（今の作業の短い目次と、終わった作業の保管庫）を書き、そのたびにファイル全体を書き直していた。 利用者が直接編集できるかは公式の記述がない（推定：同期されるフォルダなので見ることはできる） | クラウドと手元の、そのプロジェクトのエージェントが使うすべての機械で同期される（公式）。 9/14の週から、まとめ役が作るクラウドの作業役は、まとめ役の Context を自分のものとして使う。 プロジェクトの外へ移すと別の Context に戻る。 いつ読み込まれるかは公式の記述がない |
| Cursor | GitHub の通知の受信箱（Context の中のフォルダ） | プルリクエストや CI などのイベント（イベント ID と時刻付き） | 購読（Subscriptions）で自動的に届く | まとめ役が受け取る。 ※この項目は利用者の報告によるもので、公式の記述はない |
| Cursor | リポジトリの AGENTS.md / .cursor/rules | 作業のルール。 クラウド専用の準備やテストの手順 | 利用者がリポジトリにコミットする（/create-rule で作ることもできる） | クラウドのエージェントは AGENTS.md を読む（公式）。.cursor/rules は「常に適用」「パスで適用」「関連すれば適用」を選べる。Projects 専用の扱いは公式の記述がない（推定：作業役は通常のクラウドエージェントと同様に読む） |
| Cursor | 作業役の記録 | 各エージェントの作業ログ | 自動で残る | 利用者は作業役を開いて読める。 10/5の週から、まとめ役も利用者が @ で指名したエージェントの記録を読み、メッセージを送れるようになった |
長所と短所
| 製品 | 長所 | 短所 |
|---|---|---|
| Claude | ・置き場所の役割が分かれている （決めたことはメモリー、守らせるルールは指示、資料はライブラリ） ・メモリーは利用者が画面で読んで、直して、消せる ・指示には上限が明記されていて、新しいスレッドすべてに確実に送られる ・まとめ役は全履歴ではなくメモリーをもとに動くので、会話がどれだけ長くなっても続けられる | ・頼んだ好み（「同時に2つまで」など）は守ろうとする約束事で、強制ではない。 厳密にしたいなら指示に書く必要がある（公式） ・自分のパソコンで動かすスレッドはメモリーを読まない（公式） ・アップロードはコピーなので、手元で直したら上げ直しが必要（公式） ・まとめ役はスレッドの途中経過を見ない（公式） ・利用者の報告では、並列のスレッドがお互いの変更を把握しきれず、つなぎ目に抜けが出た ・取り扱いに注意が必要な情報を持つリポジトリを混ぜると、記憶がプロジェクト全体で共有されてしまう、という指摘もある |
| Cursor | ・クラウドと手元のどの機械でも同じファイルが同期されるので、ローカルで動かす作業役とも記憶を共有できる（公式） ・エージェントが自分で学んだことを書き足していくので、使うほど賢くなる設計（公式） ・利用者の報告では、まとめ役に記憶を任せる方式は「ばらばらのチャットを並べるより良い」と評価され、作業役49回の完了報告もすべてまとめ役に届いていた | ・読まれ方、上限、利用者が編集できるかが公式に明記されていない ・利用者の報告（3日間の試用）では、Project Notes が111回書かれたのに、明示的に読まれたのは1回だった ・同じ報告では、まとめ役がメモを丸ごと書き直すため、利用者が早くに出した承認が2回の書き直しの後に消え、翌日また「未解決」として戻ってきた ・まとめ役の誤った認識が「作業ルール」として Context に書かれ、次のエージェントがそれを読んだ例もあった ・「誰が決めたか（利用者か、エージェントか）」が記録されず、承認していない初期設定が「承認済み」扱いになった ・プロジェクトを書き出す機能はなく、決定の記録に ID や時刻も付いていなかった ・対策として、利用者の間では、書き足すだけで過去を書き換えない decisions.md をリポジトリに置き、日付・決めた人・理由を記録するよう勧められている |
評価（推定）：Claude のほうが仕組みは分かりやすく、「何を覚えさせたか」を自分で確かめやすいと思います。
Cursor は記憶の自由度が高い分、大事な決定は自分でリポジトリのファイル（たとえば decisions.md）に残しておくほうが安心です。
この章の出典
- Claude Code Docs「プロジェクト」（メモリー、指示、ライブラリ、リポジトリから読み込まれるもの、制限事項）：https://code.claude.com/docs/ja/claude-projects （英語版：https://code.claude.com/docs/en/claude-projects）
- Anthropic「Projects redesigned」（共有メモリーとライブラリ）：https://claude.com/resources/articles/projects-redesigned
- BuilderWithin（記憶の共有と、取り扱い注意のリポジトリについての指摘）：https://builderwithin.com/articles/claude-code-projects-coordinator-threads/
- Mitch Asser（スレッド間の連携不足の報告）：https://mitch-asser.kit.com/posts/i-don-t-like-claude-code-projects-at-least-for-now
- Cursor Docs「Projects」（共有コンテキスト）：https://cursor.com/docs/agent/projects
- Cursor Cloud Agents のリリースノート（9/14の週「Cloud workers share the Project’s Context」、10/5の週の @ 指名）：https://cursor.com/docs/release-notes/cloud-agents
- Cursor Docs「Rules」（
.cursor/rules、AGENTS.md）：https://cursor.com/docs/rules ／ Cloud Agents の準備手順（AGENTS.mdにクラウド専用の手順を書く）：https://cursor.com/docs/cloud-agent/setup - Cursor フォーラム「I tested the Projects beta for three days」（Project Notes が111回書かれて1回読まれた件、ほか）：https://forum.cursor.com/t/i-tested-the-projects-beta-for-three-days-what-worked-and-where-decisions-got-lost/172974 （詳しい記事：https://dev.to/lutz_leonhardt/cursor-projects-a-plan-rewritten-111-times-and-read-once-4j77）
利用枠を使い切ったらどうなるか
どちらも並列で何体も動くので、普通のチャットより利用枠の減りが速いです。使い切ったときの挙動は、Claude は Projects 専用の説明が公式ドキュメントにあります。Cursor にはプラン全体の説明しかなく、Projects の作業役が途中でどうなるかは書かれていません。
| 製品 | 項目 | 挙動 | 根拠 |
|---|---|---|---|
| Claude | 枠の種類 | 5時間ごとの枠（使い始めから5時間で回復）に加え、有料プランには週ごとの上限がある。 チャット、Claude Code、Projects はすべて同じ枠を使う | 公式（料金ページの FAQ） |
| Claude | 動いているスレッドとまとめ役 | 5時間または週の上限に達すると、止まらずに待つ。「Service is busy」と表示されたまま自動で再試行し続け、枠が回復したら自動で再開する。 その結果、放っておいた作業が次の枠を使い始める | 公式（Claude Code Docs「A thread hit the usage limit」） |
| Claude | 待たせたくないとき | スレッドの「Stop」を押すか、プロジェクトを一時停止すれば、次の枠を使わずに済む | 公式 |
| Claude | 定期実行（ルーティン）が起動したスレッド | 例外で、待たない。上限エラーでそのターンが止まり、枠が回復した後にこちらからメッセージを送る必要がある | 公式 |
| Claude | 追加クレジット （usage credits） | アカウントで有効にしたときだけ、上限を超えて API の標準料金で続く。 スレッドが勝手に有効にすることはない | 公式（Claude Code Docs、料金ページ） |
| Claude | プランに含まれないモデルを使った場合 | 追加クレジットが無効だと「Additional usage credits are required」というエラーで止まる。 有効にしてから再送すると続く（例：Pro では最上位モデル Fable が追加クレジット扱い） | 公式（Claude Code Docs、料金ページ） |
| Claude | 1日200スレッドの上限 | すべてのプロジェクトを合わせて、新しく作れるスレッドは1日200個まで（強制）。 「同時に2つまで」のように会話で頼んだ制限は努力目標で、強制ではない。200個に達したときの挙動は公式の記述なし（推定：新しいスレッドを作れなくなる） | 公式（上限のみ） |
| Claude | 何もしていないとき | 動いているスレッドも、見張り中のプルリクエストも、新しいメッセージもなければ、枠は減らない。 ただし、見張り中のスレッドは CI の失敗やレビューコメントで目を覚まし、また枠を使う | 公式 |
| Cursor（X の Premium） | 枠の種類 | 週ごとの共有枠が1つ。Cursor（エディタ、コマンドライン版、Cloud Agents）、Grok Bot、Grok アプリが同じ枠を使う。 枠で使えるのは Cursor 自社のモデル（Grok 4.7/4.6/4.5、Composer 2.5）だけ。 余った分は翌週に繰り越さない | 公式（Cursor の料金と利用枠のヘルプ） |
| Cursor | 使い切ったとき（全体） | エディタに通知が出る。 選べるのは、①週の回復を待つ、②前払いクレジットで続ける、③上のプランにする、の3つ。 品質や速度を落として続けることはない（遅いモデルに切り替わって続く仕組みはない） | 公式（「Requests are never downgraded in quality or speed」） |
| Cursor | 前払いクレジット | 自動チャージがオフなら、週の枠と購入済みのクレジットを使い切った時点で、追加の利用が止まる。 オンなら、残高が設定額を下回ると自動で買い足して、同じ単価で続く。 月の追加利用の上限額を決めておくと、そこで止まる（クレジットが残っていても止まる）。 クレジットの有効期限は購入から365日 | 公式 |
| Cursor | 他社モデル （Claude、GPT など） | 最初の1回から前払いクレジットで払う （週の枠は使わない）。 まとめ役を Auto や Grok にしていても、作業役（サブエージェント）が他社モデルを名指しで使えば、他社モデルの料金になる | 公式（サブエージェントの説明） |
| Cursor | 動いている作業役・まとめ役 | 途中で使い切ったときの挙動は公式の記述なし。 分かっているのは、利用枠が足りないと作業役（サブエージェント）が起動できず、そのモデル名を示すエラーが出ること（8/31の週の修正）。 推定：新しい作業役は始まらず、動いている作業も次のターンから止まる | 公式（リリースノート）と推定 |
| Cursor | 購読（Slack、スケジュール、プルリクエスト） | 枠がないときの挙動は公式の記述なし。 推定：きっかけのイベントが来てもエージェントが起動できないか、自動チャージがオンならクレジットで動く | 推定 |
| Cursor | 利用者の報告 | 大きなリポジトリで単純な指示を1つ出しただけで、まとめ役が何体も並列で起動し、すぐに上限に達して作業も終わらなかった（9/22）。 Cursor の担当者は、それが今の仕様だと回答し、「1タスクにつきエージェント1体にして、頼むまで並列にしない」とルールに書くよう助言した。 組み込みの上限額の設定は「要望として受け付けた」とのこと | 利用者報告と担当者の回答（Cursor フォーラム） |
| Cursor | Grok と Grok Bot への影響 | 枠を共有しているので、Projects で使い切ると Grok Bot も止まる。 「使用上限に達しました」と表示されて返事をしなくなる。 Grok アプリの有料機能も止まるが、無料の範囲のチャットと音声は使える | 公式（Grok Bot の FAQ、Grok の FAQ） |
| Cursor | いつ回復するか | 毎週。 次の回復日時は grok.com/dashboard の「Usage」（エディタの設定画面にも同じ表示）で確認できる | 公式 |
| Cursor | ドキュメントの食い違い | Cloud Agents の説明ページには「API 料金で課金され、最初に上限額を設定するよう求められる」という古い書き方が残っていて、X サブスクリプションの説明と合わない（推定：旧プラン向けの記述） | 公式（食い違いの指摘は推定） |
あなたの場合（推定）：Cursor Projects を試すと、Grok Bot（アシスタントたち）と同じ週の枠を使います。
並列で動きすぎると、その週は Grok Bot が止まるおそれがあります。
試すときは、次の3つをしておくと安心です。
- 最初に「1タスクにつきエージェント1体、頼むまで並列にしない」とルールに書く
- 自動チャージをオフにしておく
- 他社モデル（Claude など）を使わない
この章の出典
- Claude Code Docs「プロジェクト」（Usage and cost、Troubleshooting の「A thread hit the usage limit」「Additional usage credits are required」）：https://code.claude.com/docs/en/claude-projects （日本語版：https://code.claude.com/docs/ja/claude-projects）
- Claude の料金ページ（5時間の枠、週の上限、追加クレジット）：https://claude.com/pricing
- Cursor「Models & Pricing」（週の共有枠、使い切ったとき、前払いクレジット）：https://cursor.com/docs/models-and-pricing
- Cursor ヘルプ「Usage and limits」：https://cursor.com/help/models-and-usage/usage-limits ／「Usage-based charges」：https://cursor.com/help/account-and-billing/overages ／「Spend limits」：https://cursor.com/help/account-and-billing/spend-limits
- Cursor Docs「Subagents」（作業役が他社モデルを使うときの課金）：https://cursor.com/docs/subagents ／「Cloud Agents」（Billing の記述）：https://cursor.com/docs/cloud-agent
- Cursor Cloud Agents のリリースノート（8/31の週の、作業役が起動できないときのエラー）：https://cursor.com/docs/release-notes/cloud-agents
- Grok Bot の FAQ（使用上限で返事をしなくなる）：https://cursor.com/help/grok-bot/faqs
- SpaceXSI Docs「Usage limits」：https://docs.x.ai/x-subscription/usage-limits ／「Grok Bot on The X Subscription」：https://docs.x.ai/x-subscription/grok-bot ／ Grok の FAQ（上限に達したら有料機能が止まり、無料の範囲は使える）：https://docs.x.ai/grok/faq
- Cursor フォーラム「Issue in New Feature called projects」（2026/9/22）：https://forum.cursor.com/t/issue-in-new-feature-called-projects/172589
セッション管理の違い
どちらも「まとめ役の会話」が1本あり、その下に作業役のセッション（Claude では「スレッド」、Cursor では「エージェント」）がぶら下がる二層構造です。
Claude は、スレッドの状態分け、一時停止、保管（アーカイブ）、削除まで、Projects 専用の説明がそろっています。
Cursor は Projects のページの説明が短く、作業役の扱いは Cloud Agents 全般の説明やリリースノートから読み取る部分が多いです。
比較表
| 項目 | Claude Projects | Cursor Projects |
|---|---|---|
| セッションの単位 | プロジェクトの会話（まとめ役）1本と、スレッド（作業役。それぞれが独立した Claude Code のセッションで、自分専用の文脈を持つ）。 スレッドの中でさらにサブエージェントも使える | まとめ役との会話1本と、まとめ役が起動するエージェント（Cloud Agents の作業役）。 まとめ役は自分ではコードを書かない |
| まとめ役の寿命 | 「プロジェクトが続く限り続く」と明記。 全履歴ではなく、直近の会話・直近のスレッド・メモリーをもとに動くので、文脈の管理を利用者がする必要はない | 「数か月にわたる作業の文脈を保つ」とうたう。 会話が長くなると自動で要約する（9/30に不具合が直り、選んだ文脈の上限に近づくと要約される）。 手動で /summarize を送ることもできる（担当者の回答） |
| 作業役の文脈があふれたとき | スレッドは自動で圧縮する。 あふれると「Claude ran out of context on this turn」と表示され、新しいセッションで続くか、新しいスレッドを頼む | 公式の記述なし（推定：通常の Cloud Agents と同じく、それぞれの作業役が自分の文脈を持つ）。 担当者は「重い作業は作業役に回せば、それぞれ新しい文脈で始まる」と回答 |
| 作業役の作り方 | 会話に書けば Claude が振り分け、新しいスレッドを立てるか、既存のスレッドに回す。 「提案だけして待って」と頼むこともでき、そのときは提案の一覧からボタンで開始する | まとめ役が必要な数だけ自動で起動する。 プロジェクトの外の既存エージェントも、@ で指名すればまとめ役が記録を読んでメッセージを送れる（10/5の週から） |
| 作業役と直接話す | ○ スレッドを開いて、手順を読む、直接指示する、承認に答える、Stop や Esc で止めることができる。 承認はそのスレッドの中でしかできない（まとめ役に「進めて」と言っても届かない） | ○ まとめ役が起動したエージェントを開いて、経過を追ったり直接話したりできる。 利用者の報告では、まとめ役以外の作業役にはターミナルがなかった |
| 状態の見え方 | 「概要」の画面で、レビュー待ち／あなた待ち／作業中／マージ待ち／待機中／解決済み、に分けて表示 | チャット欄の下に、エージェント、プルリクエスト、購読の一覧が出る（利用者の報告）。 購読は入力欄の上の「Listening」から一覧できる（公式） |
| 終わった作業役 | 「解決済み」にする（利用者が手動で、マージ後に Claude が、または1週間動きがなければ自動で）。 あとから再開もできる。 スレッドは別のプロジェクトへ移したり、単独に切り出したりできない | Cloud Agents として保管と保管解除（保管中は読めるが、新しい実行はできない）、完全削除ができる。 作業役をプロジェクトの外へ移すこともでき、その場合は別の Context に戻る |
| プロジェクトの一時停止・保管・削除 | 一時停止：全スレッドと会話を止め、新しいスレッドもルーティンも動かない。 保管：サイドバーから隠し、スレッドも保管され、ルーティンも止まる。 削除：スレッド・メモリー・ファイルごと完全に消える（GitHub のブランチやプルリクエストは残る） | Projects 専用の一時停止・保管・削除の説明は公式に見当たらない。 チーム管理者は Projects を無効にできる |
| クラウドの作業環境 | ターンの合間に作業環境が一時停止し、続きで再開する。 再開できないと新しく複製し直すので、コミットしていない変更が失われることがある（長い作業は途中でコミットとプッシュを頼むのが推奨） | 作業環境が別の機械に移されても、「再接続中」と表示して同じ環境とファイルのまま続く（9/14の週の修正） |
| 手元の機械で動かす | まとめ役に頼むと、Remote Control 経由で自分のパソコンのフォルダでスレッドを動かす。 デスクトップアプリの設定をオンにするか、 claude remote-control を動かしたままにする（Claude Code v2.1.280以降が必要） | まとめ役が「ローカルのエージェント」を起動する。 自分の機械で agent login と agent worker start を実行して接続しておく（「止めるまで接続したまま」と公式） |
| パソコンを閉じたり、スリープしたりしたとき | クラウドのスレッドは続く。 自分のパソコンのスレッドは、起きている間だけ動き、スリープ中は一時停止、アプリを閉じると止まる。 スリープを防ぐ設定もある | クラウドの作業役は続く（公式）。 手元のエージェントがスリープ中にどうなるかは公式の記述なし（推定：手元の作業プロセスが止まれば、その作業役も止まる）。 利用者の報告では、Linux では手元での実行がすぐには動かなかった |
| 何もしていないときと自動で起きる仕組み | 何もしなければ枠も使わない。 見張り中のプルリクエストで CI の失敗やレビューコメントがあると、スレッドが起きる。 ルーティンはプロジェクト内のスレッドとして定期的に動く | 購読（Slack、スケジュール、プルリクエスト、CI）で起きる。 成功が続く CI や、自分のプッシュでは起きないよう改善された（8/31の週）。 既定ブランチの CI 購読は、1回起きたら閉じる（9/7の週） |
| 同時に動かせる数 | 固定の上限はない。 会話で頼む制限は努力目標。 新しく作れるスレッドは1日200個まで（強制） | 「作業に必要なだけ並列で」「何千ものサブエージェント」とうたう。 サブエージェントの入れ子には上限があり、サブエージェントが起動したサブエージェントは、さらに起動できない |
| 入れ子の上限に当たったとき | 公式の記述なし | 作業役を作れないとき、まとめ役に本当の理由（入れ子の上限など）が伝わるようになった（9/14の週）。 その後に別の作業役へ引き継ぐかなどの挙動は公式の記述なし |
| 使える端末 | claude.ai/code（ウェブ）、デスクトップアプリの Code タブ、iOS と Android のアプリ。 ターミナル版、VS Code、JetBrains では使えない。 デスクトップアプリでは、あなた待ちやエラーを通知 | デスクトップの Agents Window、ウェブ（cursor.com/agents）、iOS と iPad のアプリ（英語のみ）、Android はブラウザのアプリとして使う。 同じ仕組みの上で動くので、どこで始めた作業もすべての端末に出る |
| 履歴と記録 | スレッドの記録はプロジェクト内に残る。 共有の機能はない（プロジェクトは本人専用）。 保存期間は Anthropic のデータ利用の説明に従う（Projects 専用の期間は未確認） | エージェントの URL で会話・変更・成果物を見られ、チームの人は読むだけなら可能。 Projects を書き出す機能はない（利用者の報告）。 保存期間は未確認 |
長所と短所
| 製品 | 長所 | 短所 |
|---|---|---|
| Claude | ・状態分け（あなた待ち、レビュー待ちなど）がはっきりしていて、どこを見ればよいかが分かる ・一時停止、保管、削除がそろっていて、一時停止で全部まとめて止められる ・動きのないスレッドは1週間で自動的に片付く ・まとめ役は全履歴に頼らないので、会話が長くなっても破綻しにくい設計 ・自分のパソコンで動かすときの条件（起きている間だけ）が明記されている | ・ターミナル版や VS Code からは使えない ・スレッドの移動や統合ができず、共有もできない ・作業環境を再開できないと、コミットしていない変更が失われることがある ・承認は各スレッドの中でしかできず、まとめ役にまとめて任せられない ・自分のパソコンのスレッドは、スリープで止まり、メモリーも読まない |
| Cursor | ・どの端末でも同じ作業が見え、iPhone の通知やロック画面の表示で追える ・クラウドの作業環境が移されても、ファイルを失わずに再接続する ・既存のエージェントを @ で指名して巻き込める ・購読の無駄な起動を減らす改善が続いている | ・Projects 専用の一時停止、保管、削除の説明が見当たらない ・手元のエージェントのスリープ時の挙動や、記録の保存期間が書かれていない ・利用者の報告では、Linux で手元での実行がすぐには動かなかった、まとめ役が受け取った完了報告がチャット画面に出ない、書き出す機能がない、といった粗さがある ・まとめ役の要約は一度不具合があった（9/30に修正済み） |
評価（推定）：セッションを「管理する」道具としては、今のところ Claude のほうが整っている。
Cursor は、普段から Cloud Agents やスマホのアプリを使っている人には自然に感じられそうですが、Projects としての取り扱い説明はまだ薄い印象です。
この章の出典
- Claude Code Docs「プロジェクト」（スレッドの状態、解決済み、一時停止・保管・削除、自分のパソコンで動かす、制限事項）：https://code.claude.com/docs/en/claude-projects （日本語版：https://code.claude.com/docs/ja/claude-projects）
- Claude Code Docs「Remote Control」：https://code.claude.com/docs/en/remote-control
- Cursor Docs「Projects」：https://cursor.com/docs/agent/projects ／「Cloud Agents」：https://cursor.com/docs/cloud-agent ／「Agents Window」：https://cursor.com/docs/agent/agents-window
- Cursor Docs「Subagents」（入れ子の上限）：https://cursor.com/docs/subagents ／「My Machines」（手元の機械の接続）：https://cursor.com/docs/cloud-agent/self-hosted/my-machines ／「Cursor for iOS」：https://cursor.com/docs/cloud-agent/mobile ／ API（保管・保管解除・削除）：https://cursor.com/docs/cloud-agent/api/endpoints
- Cursor Cloud Agents のリリースノート（8/31、9/7、9/14、10/5の各週）：https://cursor.com/docs/release-notes/cloud-agents
- Cursor フォーラム「Projects Context」（まとめ役の要約、
/summarize、9/30の修正）：https://forum.cursor.com/t/projects-context/173023 - Cursor フォーラム「I tested the Projects beta for three days」（Linux での手元実行、ターミナル、書き出し機能がない件）：https://forum.cursor.com/t/i-tested-the-projects-beta-for-three-days-what-worked-and-where-decisions-got-lost/172974
ChatGPT-6とGrok Botの調査結果には違いが見られ、「定期・イベント駆動」の項目で、ChatGPT-6は、「Cursor Projectsではスケジュール、Slack、PRなどに対応しているが、Claude ProjectsではCursorほど明確ではない」と回答しているのに対し、Grok Botは、「Claude Projectsでは、ルーティン（定期実行）。プルリクエストの CI 失敗やレビューコメントで自動的に起きて修正」と回答している。他に細かな違いが多数見られるので、複数の調査を併用すべき。
今回、ChatGPT-6による調査のほかに、Grok Botによる調査を併用した。Grok Botによる調査にはあまり期待していなかったが、ChatGPT-6による調査では拾えなかった部分（実務レベルでの詳細仕様・問題点、利用者の生の声など）を確認することができ、調査を併用する場合の調査員として有能であることが分かった。
Claude Projectsの方が、仕組みとしてしっかりしていると感じられるが、どちらにも細かな改善点が多数残っているようであり、AI間、AIとユーザー間で、思い違い（認識ずれ）を継続的に洗い出す仕組みも必要と感じた。例えば、AIが認識している内容を定期的に報告（表形式レポートや図解による報告）させ、共有すべき情報に齟齬が生じていないか、共有漏れがないかを、AI及びユーザーがチェックする仕組みである。