Cursor Projectsは数ヶ月にわたりコンテキストを維持する —— ファイルが運ばない限り、次のエージェントには何も伝わらない (2026)

リリースのエントリーでは、そのスコープについて具体的に書かれています。Cursorは、Projectsについて「機能開発、マイグレーション、あるいはアプリ全体の構築など、より大きな規模の作業に取り組むことができます。数ヶ月にわたる作業のコンテキストを維持し、数千のサブエージェントにタスクを委譲し、プロンプトなしで定期的な作業を実行します」と説明しています。

コーディネーターは意図的にコーダーではない設計になっています。「プロジェクト内のコーディネーターエージェントは、自身でコードを書くことはありません。作業を計画し、それを実装するエージェントに委譲し、完成した作業をあなたの確認のために持ち帰ります。」また、それはあなたがいない場所で実行されます。「プロジェクトはクラウド上の専用のコンピューターで実行されるため、ラップトップを閉じても停止しません。」そして、Slackチャンネル、スケジュール、または一連のプルリクエストを監視して、自律的に作業を開始することもできます。

コンテキストにとって最も重要なセクションは、発表の中でCursorが「共有コンテキスト（Shared context）」と題した部分です。

「各プロジェクトは、そのエージェントが使用するすべてのクラウドおよびローカルマシン間で同期される一連のファイルを維持します。エージェントは、調査結果や成果物に加えて、コードベースについて学んだことや、あなたがどのように作業を進めたいかという好みを書き加えます。」

そして、その仕組みを明らかにする例が続きます。「たとえば、あるエージェントがサービスのテスト方法を解明した場合、将来のすべてのエージェントがその指示を利用できます。共有コンテキストはプロジェクトとともに成長し、コーディネーターは時間の経過とともにより効果的になります。」

この例をよく読んでみてください。このメリットは本物ですが、条件付きです。将来のすべてのエージェントがその指示を利用できるのは、エージェントがそれをファイルに書き込んだからです。知識が伝わったのは、エージェント同士が繋がっていたからではありません。書き残されたから伝わったのです。

Cursorのサブエージェントに関するドキュメントには、もう半分の真実がはっきりと書かれています。

「サブエージェントはクリーンなコンテキストから開始します。サブエージェントは以前の会話履歴にアクセスできないため、親エージェントはプロンプトに関連情報を含めます。」

これが、このモデルのすべてを2文で表したものです。サブエージェントはプロンプトとチェックアウト（ファイル群）を受け取ります。履歴は受け取りません。親エージェントが何を含めるかを決定し、親エージェントの寿命を超えて生き残るのは、プロジェクトの同期されたファイルセットです。

シングルエージェントが保持できる容量が変わるわけではありません。Cursorがサブエージェントを隔離する理由は、予算（コンテキスト制限）にあります。「各サブエージェントは独自のコンテキストウィンドウを持っています。長時間の調査や探索タスクが、メインの会話のスペースを消費することはありません。」コードベースの探索、シェルコマンド、ブラウザ制御のための3つの組み込みサブエージェントが存在するのは、これらの操作がノイズ多いためであり、Cursorの説明によれば「中間出力はサブエージェント内に留まります。親エージェントは最終的な要約のみを確認します」とのことです。

したがって、設計上、次のステップに到達するのは「要約」です。3時間前にすでに下した決定を、エージェントが自信満々に再導出するのを見たことがある人なら、その設計がもたらす結果を身をもって知っているはずです。以前執筆したコーディングエージェントが実際に読んでいるものに関する記事では、シングルエージェントの側面からこの境界線について解説していますが、Projectsはそれをワーカーの数だけ掛け合わせます。

また、共有ファイルセットが完全な記録になるわけでもありません。Cursorはこの点でも慎重です。8月19日のリリース（Projectsのローンチとは別のエントリー）では、独自の仮想マシン上で動作するサブエージェントが導入されました。「サブエージェントは独自の仮想マシン上で実行できるようになりました。それぞれが、独自のクラウド環境でクリーンなコンテキストを持つプロジェクトの隔離されたコピーを受け取ります。」そして、サブエージェントのドキュメントはデフォルトの挙動について警告しています。「サブエージェントはデフォルトで親エージェントのチェックアウトを共有します。複数のサブエージェントが同時にファイルを編集すると、お互いの変更を上書きしてしまう可能性があります。」

変わるのは、プロジェクトの「永続的な部分」がどこに存在するのかという点です。Projectsが登場する前は、長期にわたる取り組みは、開きっぱなしにしていたチャットと、手動で管理していた一連の指示ファイルの中に存在していました。Projects以降は、伝達手段としてのチャットは消え去り（それぞれがクリーンに開始される何百ものチャットが存在することになります）、ファイルセットが唯一のチャネルへと昇格します。これはより優れたアーキテクチャです。しかし同時に、プロジェクトのメモリの品質は、誰かがわざわざ書き残したものの品質と完全に一致することを意味します。

これはCursorだけの話ではありません。このカテゴリ全体がたどり着いた結論です。KiroのCrewのドキュメントでは、「隔離されたコンテキストで並行して実行される」サブエージェントについて説明されています。FactoryはカスタムDroidを、「独自のシステムプロンプト、モデル、ツールポリシーを持ち、Droidが新鮮なコンテキストウィンドウで集中タスクを委譲する」サブエージェントと定義しています。Zencoderのサブエージェントパイプラインは、「並行実行とクリーンなコンテキスト隔離のために、異なるモデル、コンテキスト、スキルを持つ隔離されたサブプロセスを生成」します。Warpはポータビリティに関して逆のアプローチを取り、「Rules、Skills、MCPサーバー、およびCodebase Contextは、アプリ、CLI、クラウドで同様に適用される」と述べています。これは逆方向からの同じ結論です。つまり、永続的なレイヤーは宣言されたものであり、会話によるものではないということです。これは彼らの誰かを批判しているわけではありません。4つのチームがそれぞれ独立して、新鮮なコンテキストが継承されたコンテキストに勝ると判断し、4チームすべてが、永続化させるべき部分の提供をユーザーに委ねているのです。

「コーディネーターが覚えているから、書き残す必要はない」 コーディネーターが維持するのはファイルセットです。口伝の歴史を維持するわけではありません。サブエージェントが学習し、要約して削ぎ落とした内容は、ファイルに書き残されない限り、そのサブエージェントの実行終了とともに消え去ります。

「数千のサブエージェントは、コードベースに対する数千の視点を意味する」 それは、数千回のクリーンなスタートを意味します。幅広さは並列処理から生まれ、継続性は記述されたレイヤーから生まれます。以前執筆したなぜ長いコンテキストはメモリではないのかに関する記事でも、モデルレベルで同様の区別を行っています。

「これはClaude Codeのサブエージェントと同じ問題だ」 惜しいですが、同じ対象ではなく、区別する価値があります。Claude Codeのサブエージェントがメモリを共有しない問題は、単一のセッションがファンアウトして戻ってくることに関するものです。一方、CursorのProjectは、あなたが目にすることのないマシン上で数ヶ月にわたって実行される「機能、マイグレーション、またはアプリ全体」といった一連 of 作業にスコープが絞られています。影響範囲が異なり、解決策も異なります。同様に、Cursorのクラウドエージェントがコンテキストを忘れる問題は単一のリモート実行を対象としていますが、本件はすべての実行よりも長生きするレイヤーに関するものです。

「プロジェクトこそが、チームの知識を蓄積すべき場所だ」 一部はその通りです。しかし、プロジェクトはあくまでプロジェクトにスコープされています。チームが2週間かけて議論した慣習（なぜ別のデータベースを却下したのか、どのサービスがマイグレーションを担当するのか、リリースにおける「完了」の定義は何かなど）は、機能ごとの事実ではありません。それらは、それらを浮き彫りにしたプロジェクトよりも長生きするものであり、次のプロジェクトや、あなたの隣の人が使うあらゆるツールから読み取れる必要があります。

目的は、アーキテクチャに抗うことではありません。プロジェクトをまたぐ推論を、プロジェクトごとのファイルセットに保持させようとするのをやめることです。

ステップ 1：作業の成果物とプロジェクトの決定事項を切り離す

プロジェクトが蓄積するものを精査し、次の1つの質問で各アイテムを分類してください。「この機能がリリースされた後も、これは真であり続けるか？」。「テスト用に決済サービスを立ち上げる方法」はこの作業の成果物であり、まさにCursorが配置する場所に属します。「オーナーなしで依存関係を追加しない」は決定事項であり、次のプロジェクトでも、エディタでも、3ヶ月後のコードレビューでも同様に真であり続けます。

成果物はプロジェクトに配置します。決定事項は、プロジェクトが読み取るレイヤーに配置します。

ステップ 2：ルールだけでなく、その理由も記録する

「ここではリポジトリパターンを使用する」と読み取ったコーディネーターは、それに従いますが、理由はわかりません。「負荷がかかるとレガシーアダプターが接続をリークし、本番環境で問題が発生したため、ここではリポジトリパターンを使用する」と読み取ったコーディネーターは、そのルールが適用されなくなるタイミングを判断できます。これが指示ファイルと決定記録の違いであり、毎回書き直すのではなく、プロジェクト間で記録を引き継ぐ価値がある理由です。

ステップ 3：すべてのインターフェースからアクセスできる単一のアドレスを記録に与える

Cursorはプロジェクトファイルを「エージェントが使用するすべてのクラウドおよびローカルマシン間で」同期するため、プロジェクト内のポータビリティは解決されます。しかし、プロジェクト間、あるいはチーム内の他のツール間でのポータビリティは解決されません。決定記録をアドレス指定可能な場所に置き、プロジェクトのファイルセットがそこを指すようにすれば、同じ文章を4つの場所で管理する必要はなくなります。以前執筆したプロジェクト文書をAIメモリに変換するに関するメモでは、この分類プロセスについて詳しく説明しています。

共有決定レイヤーこそが、MemoryLakeの存在意義です。推論が存在する唯一の場所であり、コーディネーター、ローカルエージェント、そしてこれらを一度も見たことがない次のプロジェクトから読み取ることができます。

ステップ 1：APIキーを作成する

サインインし、ワークスペースの設定を開き、APIキーを生成します。これは、エージェントやエディタが同じレイヤーを読み取るために使用する資格情報です。一度作成すれば、作業するすべてのインターフェースで利用可能になります。

ステップ 2：最初のメモリをアップロードする

すでに2回以上説明した決定事項から始めましょう。アーキテクチャの決定とその理由、レビューサイクルを生き残った慣習、コードからは明らかではない制約などです。コーディネーターがドキュメントをロードすることなく行動できるよう、各エントリーは十分に短く保ちます。

ステップ 3：AIとエージェントを接続する

実際に使用しているツール（エディタ、ターミナルエージェント、クラウド実行環境など）を接続し、同じ推論がそれぞれに届くようにします。サブエージェントは依然としてクリーンに開始されますが、プロジェクトの決定事項がすでに目の前にある状態でクリーンに開始されるようになります。

最初の違いは、プロジェクトが終了したときに現れます。終了したプロジェクトの中で徐々に古くなっていくファイルセットの代わりに、推論はすでに次のプロジェクトが読み取る場所に存在し、成果物は本来あるべき場所に留まります。

2つ目の違いは、コーディネーターが権限を委譲するときに現れます。Cursorのモデルでは、親エージェントがプロンプトに何を含めるかを決定します。永続的な事実が、親エージェントが引用できるレイヤーに存在する場合、その決定はより簡単かつ一貫したものになり、5月に解決したはずの質問に対してサブエージェントが3つの異なる答えを導き出すような事態を防ぐことができます。

3つ目の違いは、最悪の日に現れます。バグレポートのチャンネルに対してプロンプトなしで実行されているプロジェクトは、最終的にあなたが取らなかったであろうアクションを実行する可能性があります。その後に役立つ問いは、「それは何を基準に動作していたのか」ということです。恒久的な決定事項が要約から再構築されるのではなく、記述され、バージョン管理されていれば、その問いに答えることができます。AIが記憶していることを監査することは、それを可能にする実践方法です。

履歴を持たない読者のために書く。 すべてのサブエージェントがその読者です。「議論した通り」で始まるエントリーは、誤読される原因になります。

「常に真であること」と「現在真であること」を分ける。 スプリントの状態はプロジェクトに属します。恒久的な決定事項は、その下のレイヤーに属します。これらを混在させると、スプリントが終了した瞬間にそのレイヤーが崩壊します。

却下された選択肢を記録する。 エージェントが何かを再提案するのを防ぐ最も安価な方法は、却下された事実とその理由を一度書き残しておくことです。

エージェントがコードベースについて書いた内容を読み直す。 Cursorは、エージェントが「コードベースについて学んだことや、あなたがどのように作業を進めたいかという好み」を追加すると述べています。これは本当に有用な仕組みですが、同時に推論でもあります。最初の数回のエントリーは下書きとして扱い、新しいチームメイトのオンボーディングノートを修正するのと同じように修正してください。

引き継ぎには情報の欠落が伴うと仮定し、コストを抑える。 エージェント間のチャネルを広げることはできません。そこを通る情報が、会話の書き起こしではなく「結論」であることを確認することはできます。

Cursor Projectsは本格的なエンジニアリングの成果であり、そのコンテキストモデルは誠実なものです。サブエージェントはクリーンに開始され、親エージェントが必要なものを提供し、プロジェクトの同期ファイルが生き残ります。その結果は、言葉にするのは簡単ですが、見落とされがちです。すべてのワーカーがゼロから開始するアーキテクチャにおいて、記述されたレイヤーは「あれば便利」なものではありません。それは、今日起こることと来月起こることの間のすべての帯域幅そのものなのです。

Projectsはベータ版であり、すべてのユーザーに展開されています。もしあなたがコーディネーターに数ヶ月に及ぶ作業を任せようとしているなら、最もレバレッジの高い1時間はプロンプトの作成ではありません。本来ならエージェントが覚えていると期待してしまうような決定事項を、書き残すことに費やす時間です。