なぜすべてのクラウド実行は最初からやり直されるのか
新しいセッションは契約であり、失敗ではない
Warpはこの保証を、リファレンスとクイックスタートの2箇所で述べています。クイックスタートではさらに明示的な表現が使われています。「各実行は、以前の実行から状態が引き継がれない、新しく隔離されたセッションとして開始されます。すべての実行は追跡可能であり、Ozウェブアプリで確認できます。」
実行モデルの残りの部分は、それが単に都合が良いからではなく、なぜ望ましいのかを説明しています。「実行は人間の介入なしに自動的に行われます。」そして「スケジュールされた実行が失敗しても、将来の実行はブロックされません。各実行は独立しています。」独立性こそが、無人スケジュールを安全にする特性です。先週の破損した状態を引き継いだ実行は、誰も見ていないところで、それを静かに、永遠に伝播させてしまうからです。
したがって、隔離は意図的なものです。欠けているのは隔離ではなく、チャネルです。つまり、ある実行が結論を保存し、次の実行がそれを読み取ることを許可する場所です。
環境は再現性であり、想起ではない
最初に目を向けるべき場所は「環境（Environment）」ですが、ここでほとんどのチームが1日を無駄にします。Warpの定義は、それを1文で排除しています。「環境は、エージェントがタスクをどのように実行するかを記述するものであり、何をするかを記述するものではありません。」
環境は、Dockerイメージ、エージェントがクローンする1つ以上のリポジトリ、セットアップコマンド、環境変数、およびAgent Secretsをグループ化したものです。その目的は「同一性」です。「クラウドエージェントが実行されるたびに、同じコンテナ、リポジトリ、セットアップを提供します。」そして、扉を閉ざす一文が続きます。「これらの設定が合わさることで、実行ごとに新しいワークスペースが作成されます。」
これはビルド環境としてはまさに正しい設計ですが、記憶（メモリ）としては完全に間違っています。毎回同じスタートラインに立つことは、知識の蓄積とは真逆です。「環境が明示的にデータを永続化しない限り」という条項は本物ですが、それは独自の永続化（データベース、エージェントがコミットするリポジトリ、外部ストアなど）を自分で構築することを意味しており、環境自体が何かを記憶しているわけではありません。
Warpは隣接するスロットとして、実行ごとのコンテキスト（per-run context）を挙げています。これは「Slackスレッド、PRのメタデータ、CIログなど、タスク固有のデータを提供します。」これはトリガーのペイロードであり、ストアではなく、それを受信した実行のスコープに限定されます。
ハンドオフは3つの前提条件のもとで実行を再開する
次に人々が見つけるメカニズムが「ハンドオフ（Handoff）」であり、これはその役割を実に見事に果たします。クラウド間ハンドオフ（Cloud-to-cloud handoff）を使用すると、完了した実行に対してフォローアップを送信できます。Warpは、それに何が伴うかを正確に説明しています。「ハンドオフは、受信側エージェントがその作業について読むだけでなく、作業を再開できるだけの十分な状態を保持します。」フォローアップは「同じ会話」に着信し、「以前のセッションのリポジトリの変更（追跡対象および未追跡）は、エージェントがフォローアップに回答する前に復元されます。」実行のアイデンティティ（ID、タスク、作成者、環境、スケジュールトリガー、統合ソース）もすべて維持されます。
しかし、これは特定の1つの実行を手動で継続するものであり、実務上重要となる3つの条件があります。
実行が十分にクリーンに終了していること。「実行は、成功、失敗、またはキャンセルなどの終端状態（terminal state）である必要があります。」また、「ユーザーの入力や承認を待っているブロックされた実行は、クラウド間ハンドオフを介して継続することはできません。」エージェントの会話モデルより前の、非常に古い実行も継続できません。
スナップショットが存在すること。実行は「各セッションの終了時にワークスペースのスナップショットをキャプチャ」します。もしキャプチャされなかった場合（Warpは一時的なストレージエラーを例に挙げています）、「実行は継続されますが、復元されたワークスペースの状態は伴いません。」警告はより率直です。「ファイルにスナップショットがない古いクラウド実行はハンドオフできません。代わりに新しい実行を開始してください。」
そして所有権による制限があること。「ローカルからクラウドへのハンドオフから発生したクラウド実行は、それを作成したユーザーのみが継続でき、他のチームメンバーは継続できません。」Warpはまた、ハンドオフは「ベストエフォート」であると指摘しています。変更をクリーンに適用できない場合、エージェントはどれが失敗したかを報告し、残りの処理を継続します。
これらはハンドオフを非難しているわけではありません。単に、人間が1つの実行を延長することを決定するものであり、スケジュールが学習していくものとは形状が異なるというだけです。
Warp独自の回答が存在し、それはリサーチプレビュー中である
Warpは欠けているレイヤーを構築中であり、それを過小評価も過大評価もしないために、その現状を正確に把握しておく価値があります。
Agent Memoryは、「Warp上に存在し、組み込みのWarp Agent、Claude Code、Codex、および今後追加されるその他のサポートされているすべてのエージェントハーネスで共有される永続的なメモリシステム」と説明されています。これには明示的にバックグラウンド作業も含まれます。「ローカルエージェントとクラウドエージェントの両方に対応 - Warpのインタラクティブなローカルエージェントとバックグラウンドのクラウドエージェントをサポートします。」メモリは自動的に抽出されます。「会話が終了すると、Warpは永続的な事実、学習内容、結果を抽出し、それらをメモリとして書き込みます。」そして「新しい知識は既存のメモリとマージされるか、衝突した場合は上書きされます。」これは個人、エージェント、チームのストアに整理され、各メモリは「どこから来たのかを記録」し、「メモリへのすべての変更が記録されるため、チームはメモリが時間の経過とともにどのように変化したかを検査できます。」作成と取得はバックグラウンドで実行されるため、「トークンを消費したり、アクティブなタスクにレイテンシを追加したりすることはありません。」
これは非常によくできた設計であり、起源（プロベナンス）と監査可能性が備わっているのは一般的ではありません。これら2つの特性がどれほど重要な役割を果たすかについては、なぜメモリの起源（プロベナンス）が重要なのかを参照してください。
制約となるのはそのステータスです。「Agent Memoryはリサーチプレビュー（research preview）段階にあり、デザインパートナーのチームごとに有効化されます。」アクセスをリクエストするためのウェイトリストが用意されています。また、サードパーティのハーネスを実行している場合に注意深く読むべきカバレッジの制限もあります。「サードパーティのハーネスは、クラウドエージェントとして実行されている場合にカバーされます。」そして「（リサーチプレビュー期間中、サードパーティのハーネスをローカルで実行することはサポートされていません。）」プログラムによるAPIアクセスやセルフホスティングは、現在提供されておらず、今後提供予定とされています。
したがって、正確な要約は「Warpにはメモリレイヤーがない」ということではありません。「Warpにはメモリレイヤーがあり、まさにこの問題をターゲットにしているが、現時点ではデザインパートナーであることに依存している」というのが正確なところです。
よく試されるアプローチ
状態をリポジトリにコミットする。 動作はしますし、一部のタスクにおいてはこれが正解です。エージェントが追記していくチェックイン済みの台帳は、耐久性があり、レビュー可能で、差分（diff）も確認できます。しかし、これは実行のたびにコードではないファイルに対してプルリクエストを作成することを意味し、リポジトリをまたいだ共有には役立ちません。
スケジュールをより具体的にする。 「すでに処理したものはスキップする」という指示は、一見良さそうに見えますが実行できません。なぜなら、新しいセッションには過去に何を処理したかの記録がないからです。
手動でフォローアップを連鎖させる。 毎週の実行を次の実行へとハンドオフします。これは確かにワークスペースの状態を引き継ぎますが、サイクルごとに人間の介入が必要になり、スケジュールの意味がなくなります。また、前述のスナップショットや所有権の条件に阻まれます。
環境が何かを保持していると仮定する。 前述の通りです。環境は「どのように（how）」であり「何を（what）」ではないと定義されており、実行ごとに新しいワークスペースを構築します。
Warpのクラウドエージェントにはメモリが一切ないと結論づける。 実行モデルだけを読めばそう思ってしまうのも無理はありませんが、それは間違いです。Agent Memoryは設計上、クラウドエージェントをカバーしています。正確な表現をするなら、「現在はリサーチプレビュー中であり、デザインパートナーのチームに限定されている」ということです。
スケジュールをオフにする。 最もよくある結末であり、最も多くの努力を無駄にする選択肢です。
解決策：セッションより長生きする、各実行の読み書き場所を提供する
Warpが特定したつなぎ目は正確です。状態が実行の境界を越えるのは、セッションの外部にある何かがそれを保持している場合のみです。したがって、セッションの外部にメモリレイヤーを配置し、各実行の開始時にそこから読み取り、終了時にそこに書き込めるようにします。
MemoryLake はそのレイヤーです。あなたが所有し、API経由でアクセスする1つのストアであるため、実行がスケジュール、Slackのメンション、またはキーボードの前の人間によってトリガーされたかどうかにかかわらず、同じ知識を利用できます。手順は3つです。
ステップ 1: APIキーを作成する
サインインし、ワークスペースの設定からAPIキーを作成します。これをAgent Secretとして保存することで、イメージに埋め込むのではなく、実行時に注入されるようにします。これがWarpのシークレット管理メカニズムの本来の用途です。
ステップ 2: 最初のメモリをアップロードする
実行が何度も再導出しがちな「結論」をあらかじめインプットしておきます。イシュートリアージの場合：どのイシューがすでに重複と判断され、その理由は何か、どの報告者に特定のフォローアップ質問が必要か、チームがどのラベルを終端状態として扱うか。依存関係の作業の場合：すでに試みられて断念されたアップグレードとその理由。クリーンアップジョブの場合：一見不要に見えて実は必要なファイル。ファイルはマルチモーダルなものも含めてそのまま投入できるため、運用手順書の図や所有権のスプレッドシートを直接入れることができます。
ステップ 3: AIとエージェントを接続する
実行している他のツールと並行してWarpを接続します。そして、プロンプト内で読み書きを明示的に指示します。「このタスクについて以前の実行がどのような結論を出したかを確認することから始め、将来の実行が二度と頭を悩ませる必要がないように、今回の結果を記録して終了すること。」スケジュールのプロンプトこそが実行間で永続する唯一のものであるため、この指示が耐久性のある部分となります。
3つの率直な制限事項があります。これはWarpの隔離モデルを変更するものではありません。すべての実行は依然として新しいセッションから開始されますが、それは良いことです。また、ワークスペースの状態を復元するものでもありません。リポジトリの変更はハンドオフの役割であり、MemoryLakeが保持するのは知識であり、差分（diff）ではありません。そして、環境の代わりになるものでもありません。イメージ、リポジトリ、セットアップコマンドは元の場所に残ります。
これによって実務で何が変わるか
最初の変化は、スケジュールされたエージェントが同じことを繰り返さなくなることです。2回目の実行は1回目が結論づけた内容を読み取り、全体ではなく差分（デルタ）に対して動作します。
2番目の変化は、実行履歴が単に「存在する」だけでなく「役に立つ」ものになることです。Warpはすべてを保持します。「スケジュールを削除すると、将来のすべての実行が即座に停止します。以前の実行とそのセッション履歴は、検査やレビューのためにアクセス可能なまま残ります。」そして「変更は将来の実行にのみ適用されます。過去の実行とそのセッション履歴は変更されません。」これは優れた監査証跡ですが、検索メカニズムとしては不十分です。なぜなら、次の実行のためにそれを読み取るものが何もないからです。メモリレイヤーは、文字起こしのアーカイブをエージェントが参照する知識へと変える役割を果たします。
3番目の変化は、複数のエージェントを実行するときに現れます。Warp自身の設計も、共有エージェントに紐づくチームストアでこれを示唆していますが、同じ論理が外部レイヤーにも適用されます。トリアージエージェントとレビューエージェントが同じ1つのストアを読み取ることで、お互いに矛盾した行動をとるのを防ぐことができます。これは、マルチエージェントシステムのための共有メモリで説明されている一般的なケースです。
スケジュールされたクラウドエージェントのベストプラクティス
1年間無人で実行されることを想定してプロンプトを書く。 プロンプトはすべての実行を生き残る唯一の要素です。そのため、最初に何を読み取るべきか、報告する価値があるかどうかをどのように判断するか、そしていつ停止すべきかを明記する必要があります。
知識とワークスペースの状態を分離する。 リポジトリの変更はハンドオフの領域です。結論、決定事項、除外事項はストアに属します。これらを混同すると、誰もレビューできない台帳が出来上がってしまいます。
整理せずにストアを肥大化させない。 「永続的な事実、学習内容、結果」を抽出するというWarpのモデルは、真似すべき優れたフィルターです。文字起こしではなく、決定事項とその理由を記録してください。エージェントにどの程度のメモリを与えるべきかでは、その上限についてさらに詳しく説明しています。
起源（プロベナンス）を記録する。 Warpは、エージェントがストアの目的を理解できるように、アタッチメントごとに指示を要求します。「エージェントが各ストアの目的を把握できるように、すべてのアタッチメントに指示が必要です。」外部でも同じ規律を適用してください。どの実行がその結論を出したかを記録しておくことで、誤った結論を追跡して削除できるようになります。
実行のアイデンティティを慎重に選択する。 Warpのデフォルトでは、実行はスケジュールの作成者として実行されますが、クラウドエージェントのアイデンティティはアプリとして認証されます。この決定は、誰がエージェントのプルリクエストをレビューできるかに影響します。これはメモリとは別の問題ですが、同時に間違えやすいポイントでもあります。
スケールさせる前に、スケジュールの影響範囲（ブラスト半径）を監視する。 実行はチームの共有クレジット残高に課金され、介入なしに実行されます。メモリレイヤーは、調査対象を絞り込むことで各実行のコストを削減します。これは測定する価値のある副次的メリットです。
スタックに適合する場合は、Agent Memoryのウェイトリストに参加する。 チームが対象であれば、ネイティブなクロスハーネスストアを持つことは素晴らしいことです。ただし、今四半期の計画をリサーチプレビュー段階の機能に依存して構築することは避けてください。
結論
Warpは最初からルールを提示していました。すべての実行は新しいセッションから開始され、セッションの外部にある何かが保持しない限り、境界を越えるものはありません。これは無人自動化にとって正しい設計ですが、1つのギャップを残しています。それは、ある実行が次の実行のために結論を残しておく場所です。
Warpは、クラウドエージェントをカバーし、デザインパートナーチーム向けにリサーチプレビュー中であるAgent Memoryによって、そのギャップを埋めようとしています。それが一般公開（GA）されるまでは、Warp自身の文が説明しているのと同じメカニズム、すなわち「各実行の開始時に読み取られ、終了時に書き込まれる外部ストア」を使用することになります。新しいセッションと、蓄積された知識。この2つが対立するのは、知識がセッションの内部に存在する場合だけです。