環境が温まっていてもクラウドエージェントがコールドスタートする理由
ビルドはマシンを準備するものであり、モデルを準備するものではない
ビルドに実際に何が含まれているかを確認してみましょう。ドキュメントでは、開発環境を「ラップトップ上のセットアップと同様のもの：クローンされたリポジトリ、インストールされた依存関係、シークレット、起動コマンド、ネットワークアクセス」と説明しており、これらは .cursor/environment.json、エージェントによるセットアップ、保存されたスナップショット、または Dockerfile を通じて構成されます。ビルド機能は、エージェントが「リポジトリと依存関係が準備された状態で開始」できるように、事前にその環境を準備します。そして、エージェントは常に最新のビルド成功状態から開始されます。依存関係の更新によって環境が破損した場合、失敗したビルドがアクティブになることはありません。
このリストにあるすべての項目はインフラストラクチャです。知識（ナレッジ）に該当するものは一つもありません。インストールコマンドはビルド作成時に1回実行され、起動コマンドはセッションごとに再実行されます。これはサービスやコンテナにとってはまさに正しい設計ですが、エージェントが「今スプリントで課金モジュールに破壊的変更を加えてはならない」と知っているかどうかとは、まったく無関係です。
Cursorは環境の重要性について率直に述べています。「エージェントの能力は、それが実行される環境の能力に依存する」、「環境のセットアップは、クラウドエージェントの有効性を向上させるための最も重要なステップである」。これは事実であり、ビルド機能はそれを低コストで実現します。ただ、これは人々が3回目のクラウド実行で同じ間違いを繰り返した後に抱く疑問とは、異なる問いに答えているだけなのです。
トリガーがブリーフィングのすべてである
ローカルセッションには会話があります。しかし、クラウドエージェントには多くの場合、会話がありません。ドキュメント化されているエントリーポイントには、Cursor Desktop、cursor.com/agents の Cursor Web、iOSアプリまたはAndroid PWA、Slackの @cursor コマンド、GitHubやBitbucketのプルリクエストやインシデントでの @cursor メンションコメント、Linear、そしてAPIが含まれます。
これらの大部分に共通している点に注目してください。エージェントは、誰かが1つのメッセージを書くことによって起動されます。多くの場合、エディタの前に座っていない状態で、時にはコードを書いていないチームメンバーによって起動されます。そのメッセージがブリーフィングのすべてになります。エージェントがリポジトリの内容以外に知ることができるのは、その1文と、エージェント自身が読み取るファイルだけです。Linearのチケットからスマートフォンで書かれた1文は、ローカルセッションで20分間エージェントと会話してきた内容に比べれば、極めて薄いブリーフィングです。
これが、ローカルでの物忘れないしは失敗の感じ方が異なる理由でもあります。ローカルでは、エージェントが文脈を見失っていることに気づけば、再度説明することができます。しかし、クラウド実行ではその場に気づく人がいないため、誤解がそのままプルリクエストとして提出されてしまいます。
ルールは唯一の知識チャネルであり、そのうちの1つの形式はサイレントに失敗する
トリガーが薄いため、永続的な知識はすべてリポジトリ内に存在する必要があります。Cursorのルールに関するドキュメントにも明記されています。「大規模言語モデルは、補完（completion）間でメモリを保持しません。ルールはプロンプトレベルで永続的かつ再利用可能なコンテキストを提供します」。ルールには、ドキュメント化されている4つの形式があります。バージョン管理下の .cursor/rules にある .mdc ファイルとしてのプロジェクトルール、Cursor環境全体でグローバルなユーザールール、TeamおよびEnterpriseプランのダッシュボードから管理されるチームルール、およびプロジェクトのルートにある AGENTS.md（ネストされたファイルもサポートされ、より具体的なものが優先されます）です。
ここに罠があります。同じドキュメントからの引用です。「.cursor/rules 内のプレーンな .md ファイルは、description、globs、および alwaysApply を指定するフロントマターがないため、ルールシステムによって無視されます」
警告も、エラーも、ログへの記録もありません。ルールのように見え、ルールディレクトリに置かれ、機能しているように読めるファイルが、実際には無視されているのです。これは、ルールの形式がプレーンなMarkdownであった他のツールから移行してきたチームにとって、最も手痛い打撃となります。そして、最も防ぎたい場所、すなわちクラウド実行において、それが不可視になります。セッションを監視している人がいないため、規約ファイルがロードされなかったことに誰も気づきません。4つの適用モード（alwaysApply: true、インテリジェントな適用のための description、特定ファイル用の globs、または手動での@-メンションを必要とする設定なし）と合わせて確認しておく価値があります。手動適用に設定されたルールは、クラウドエージェントの実行時に自動的にロードされることはありません。
クラウドでの作業においては、さらに2つの制約が重要になります。ドキュメントでは、ルールを500行未満に抑え、大きなルールは構成可能な小さなピースに分割することを推奨しています。これは、常にロードされるチャネルが意図的に狭く設計されていることを意味します。また、globs でスコープされたルールは、一致するファイルが処理対象になっている場合にのみコンテキストに入ります。これは適切ですが、エージェントがどのファイルを操作するかを決定するまでは、領域固有の知識が不可視であることを意味します。
ドキュメントには永続化されるものがリストアップされているが、メモリはその中にない
ここからは慎重に説明したい部分です。Cursorのクラウドエージェントのドキュメントには、環境、スナップショット、ビルド、.cursor/hooks.json からのフック、マルチリポジトリワークスペース（「エージェントはワークスペース全体を検査し、協調的な変更を行うことができる」）、モデル選択（「クラウドエージェントは厳選されたモデルを使用する」で、選択可能なコンテキストウィンドウサイズを含む）、およびエージェントが使用した環境とビルドをバージョン履歴とともに表示するダッシュボードがカバーされています。
しかし、個別のエージェント実行間でコンテキスト、状態、またはメモリが永続化されることについては説明されていません。同様に、ルールに関するドキュメントにもメモリ機能についての記述はなく、執筆時点で cursor.com/docs/agent/memories は404エラーを返します。したがって、正確な主張は「Cursorにはメモリがない」ということではなく、「実行間で知識を引き継ぐためのドキュメント化されたメカニズムはルールファイルであり、ドキュメントのどこにも、エージェントの2回目の実行が1回目の実行からリポジトリ内のもの以外の何かを継承することは保証されていない」ということです。
ドキュメント化されている内容に基づいて計画を立ててください。もしあなたのチームが、クラウドエージェントが先週のことを覚えているというドキュメント化されていない前提に依存しているなら、その前提にはドキュメントの裏付けがなく、その兆候は実行間の不整合として現れるでしょう。これは、Cursorが以前のセッションを忘れてしまう理由で説明したローカルな問題のクラウド版です。
人々が試みること
より長いルールファイルを書く。 自然なアプローチですが、500行のガイドラインと衝突します。一定のサイズを超えると、常にロードされるファイルはテキストの壁となり、モデルの注意を引くために実際のタスクと競合することになります。また、その中のすべての内容は、関連性があるかどうかにかかわらず、実行ごとにコスト（トークン）が発生します。
トリガーコメントにコンテキストを含める。 1回の実行には有効です。しかし、チケットを作成する人がプロジェクトのすべての制約を把握し、それを忘れずに再記述する必要があるため、エージェントに委任する目的が損なわれます。また、次のチケットには引き継がれません。
環境に追加する。 知識をセットアップとしてエンコードしようとする試みです。インストールスクリプトが cat する README や、起動コマンドが echo するファイルなどです。環境は依存関係やサービスのためのものです。そこを経由する知識は脆弱であり、レビュー時に不可視になります。
代わりにすべてをローカルで実行する。 最も安全な回答であり、最もコストがかかる方法です。チームメンバーが自分のマシンを持たずに Slack や PR のコメントから作業をトリガーできるという、クラウドエージェントが存在する理由そのものを放棄することになります。
ルールがロードされていると仮定する。 極めて一般的であり、プレーンな .md の罠がそれをさらに悪化させます。チームは、ファイルがコンテキストにまったく入っていないにもかかわらず、モデルのデバッグを行ってしまいます。モデルを責める前に、ルールが実際に適用されたかどうかを確認してください。この失敗パターンは、Cursorがプロジェクトルールを忘れてしまう理由で説明されています。
より多くのエージェントを起動する。 並列のクラウドエージェントは、問題を解決するどころか増幅させます。それぞれが独自の薄いブリーフィングから開始され、他のエージェントがどのような結論を出したかを誰も知りません。このパターンは、マルチエージェントメモリでカバーされています。
解決策：プロジェクトの知識をクラウドからアクセス可能な場所に置く
構造的な問題は、クラウドエージェントには正確に2つの入力（トリガーとリポジトリ）しかなく、そのうちの1つは単なる1文であるということです。ルールファイルは、すべての実行においてコンテキストに含める必要がある最小限の項目を処理します。しかし、ルールファイルに保持できないのは、増大し続けるプロジェクトの知識です。意思決定、却下されたアプローチ、奇妙なコードがなぜ正しい選択肢であったのかを示す制約などです。これらの資料は、常にロードされるファイルに含めるには大きすぎ、終了したローカルセッションに残しておくには貴重すぎます。
MemoryLake は、エージェントが常に持ち歩く必要のあるファイルではなく、必要に応じてクエリできる知識の「家」を提供します。接続されたすべてのエージェントが読み取れるメモリレイヤーにより、PRコメントからトリガーされた実行でも、チームがすでに決定した事項を検索できます。セットアップは3つのステップです。
ステップ 1: APIキーの作成
MemoryLake にサインインし、APIキーを作成します。接続するすべてのエージェントで1つの認証情報を共有します。クラウド実行は複数のインターフェースからトリガーされるため、インターフェースごとの設定を避けるためにこれが重要になります。
ステップ 2: 最初のメモリのアップロード
ルールファイルには載せきれない知識をロードします。アーキテクチャの決定とその背後にある理由、試したものの断念したアプローチとその理由（これは最も価値の高いカテゴリです。これがないと、薄いブリーフィングを受け取った新しいエージェントが、自信満々にそのアプローチを再提案してしまうためです）、コンテキストなしでは恣意的に見える制約、誰も書き留めようとしなかったために人々の頭の中にだけ存在する規約などです。エージェントが実用的な情報を取得できるように、エントリーは短く、1つのアイデアにつき1つにまとめてください。
ステップ 3: AIとエージェントの接続
エージェントを接続します。MemoryLake は MCP および API 経由でアクセス可能です。そのため、Claude Code、Codex、OpenClaw などの MCP ネイティブエージェントは MCP サーバーを指定することで接続でき、その他のツールは API を通じて同じメモリを読み取ることができます。ルールは、すべての実行でコンテキストに含めるべき一握りの項目という、本来の狭い役割を果たし続けます。それ以外のすべては検索可能になるため、薄いトリガーが薄いブリーフィングを意味することはなくなります。初めて MCP 側をセットアップする場合は、MCPを使用したクロスAIメモリのセットアップで手順を解説しています。
率直な限界についても触れておきます。MemoryLake はクラウド実行を監視しているわけではないため、誰かが書き留めない限り、エージェントが学んだことをキャプチャすることはできません。また、強制力を持つレイヤーでもありません。モデルが何を決定しようとも必ず遵守すべきルールがある場合は、フックや CI チェックに含めるべきであり、それこそが .cursor/hooks.json の役割です。そして、ルールファイルを完全に置き換えるものでもありません。両者は異なる役割を担っており、どちらか一方に両方の役割を期待することは間違いです。
実務における変化
薄いトリガーが薄い成果物を生み出すことがなくなります。 チケットを作成する人が、すべての制約を覚えている必要はもうありません。これこそがクラウドエージェントの本来の約束であり、エージェントがアクセス可能な場所に制約が置かれて初めて実現します。
クラウド実行とローカル実行が収束します。 現在、同じリクエストであっても、長い会話の後にエディタで実行したか、Slackメッセージから実行したかによって、異なる成果物が生成されることがよくあります。双方が同じメモリを読み取るようになれば、実行環境の差は関係なくなります。これは、コンテキストが1台のマシンに留まり続けるのを防ぐことにもつながります。
ルールファイルが短くなり、その結果、品質が向上します。 参照用の知識を「常にロードされるチャネル」から外すことは、単に整理整頓のためだけではありません。これにより、500行のガイドライン内に収めることができ、常に適用されるべき真に重要なルールと競合するノイズを減らすことができます。
繰り返される修正指示が繰り返されなくなります。 クラウドエージェントを使っていて最も落胆するのは、3回目の実行で、1回目の実行時に修正したはずの間違いを繰り返すのを見ることです。これは、修正内容がセッション内に留まっており、セッションが終了してしまったために起こります。一度書き留めておけば、それ以降のすべての実行で利用可能になります。
レビューが短くなります。 エージェントが作成したプルリクエストに対するレビューコメントのほとんどは、コードの品質に関するものではなく、エージェントが持っていなかったコンテキストに関するものです。コンテキストを移行させることで、レビューの手間の大部分が解消されます。
クラウドエージェントのコンテキストに関するベストプラクティス
今すぐ `.cursor/rules` 内のプレーンな `.md` ファイルを監査してください。 description、globs、および alwaysApply を指定するフロントマターがないファイルは、サイレントに無視されます。これは5分でできるチェックですが、特に他のツールから移行したリポジトリでは高い確率で問題が見つかります。これは、WindsurfからCursorへの移行で説明されているのと同じ移行の罠です。
各ルールがどのモードを使用しているかを把握する。 常にロードする必要がある最小限のセットには alwaysApply: true を、領域固有のルールには globs を、インテリジェントな適用には description を使用します。@-メンションを必要とする手動ルールは、無人のクラウド実行では自動的にロードされません。これらはローカル専用として扱ってください。
エージェントはリポジトリ以外のことは何も知らない前提でトリガーを書く。 実際、何も知らないからです。ゴールと受け入れ基準を明記し、背景情報は検索可能なレイヤーから提供させるようにします。
実行がうまくいかない場合は、環境ダッシュボードを使用する。 ドキュメントによると、ダッシュボードにはエージェントが使用した環境とビルドがバージョン履歴とともに表示されます。ある実行がその前の実行と異なる挙動を示した場合、モデルが変更されたと仮定する前に、異なるビルド上で実行されていなかったかを確認してください。
必須の制約は文章ではなくフックに記述する。 クラウドエージェントは .cursor/hooks.json からコマンドベースのフックを実行します。すべての変更において真であるべき制約は、提案ではなく強制力を持たせるために、フックに記述すべきです。
シークレットをメモリに入れない。 環境のシークレットは環境設定に属します。メモリレイヤーは知識を保持するものであり、認証情報を保持するものではありません。
結論
ビルド機能は真の改善であり、価格設定（無料、8月17日からデフォルトで有効、エージェントはコールドマシンではなく常に最後のビルド成功状態から開始）についても文句のつけようがありません。今、残されたギャップについて議論する価値がある理由は、ビルド機能によって「言い訳」が通用しなくなったからです。クラウドエージェントの起動に4分かかっていた頃は、遅さこそが問題であるように感じられました。しかし、数秒で起動したエージェントが、先月却下した設計を即座に提案してくるのを見れば、速度が本質的な問題ではなかったことは明らかです。
解決策は、ルールファイルを長くすることではありません。クラウドエージェントには2つの入力があり、そのうちの1つは単なる1文であり、チームが知っているそれ以外のすべての情報は、もう1つの入力から検索可能である必要があると認識することです。Cursorがマシンを事前準備するようになったのと同じように、知識を事前準備（プリウォーム）しましょう。