Devin DesktopがCascadeを削除 — リポジトリにないものはすべて消え去った (2026)

ここで重要となるのは、3つの異なるページから発信された、開発元による3つの公式声明です。

変更履歴には削除の日付と、会話の代替移行パスが記載されています。そこで示されている移行プロンプトはContinue in Devin Localであり、引き継がれるのは「会話」です。

Devin Localのドキュメントは、引き継がれないものについてより率直に述べています。「制限事項（Limitations）」の項目には以下のようにあります。

"Memories — Devin Localエージェントは、セッション間でメモリを保持しません。重要なメモリは、Devin: Open Cascade Migration Wizardコマンドを使用してスキルに移行してください。"

"Workflows — Devin Localエージェントではワークフローを利用できません。"

そして、「Memories」のページでは、それらのメモリがどこにあったのかを説明しています。

"Cascadeが自動生成したメモリは、それが作成されたワークスペースに関連付けられ、ローカルの~/.codeium/windsurf/memories/に保存されます。Cascadeは、関連性があると判断したときにこれらを取得します。あるワークスペースで生成されたメモリは別のワークスペースでは利用できず、リポジトリにもコミットされません。"

これら3つの声明を合わせて読めば、問題の構図は明らかです。メモリは1台のマシンにローカル保存され、1つのワークスペースにスコープが限定され、バージョン管理の対象外でした。これについて隠されていたことは何一つなく、すべてドキュメントに記載されています。しかしそれは、蓄積された知識が、誰も気に留めないディレクトリの中に「たった1つのコピー」としてしか存在していなかったことを意味します。

また、今週中に対応すべきことに影響するため、指摘しておくべきギャップがあります。変更履歴の移行手順は「会話」を対象としています。一方、MemoriesページとDevin Localの制限事項の両方に記載されているメモリの移行パスは、Devin: Open Cascade Migration Wizardという別のコマンドです。これは、変更履歴で「削除された」とされているエージェントの名を冠しています。本稿執筆時点では、Memoriesページは依然としてCascadeを現在形で説明しています。2つの異なるものに対する2つのパスが存在し、ドキュメントがリリースに追いついていません。大切なメモリがある場合は、ウィザードがまだ存在していると仮定する前に、それらが保存されているマシンを確認してください。

この削除は突然行われたわけではなく、その兆候はリリースノートの条件節に現れていました。7月29日には、Devin Local専用とマークされたモデルがCascadeのモデルピッカーで無効として表示され始めました。8月10日のリリースノートでは、「チームでCascadeが無効になっている場合に、Cascade固有の設定やカスタマイズオプションを非表示にする」と説明されていました。8月21日には、「Explain and Fix Problem（問題の説明と修正）」が「Cascadeが無効な場合」にDevin Localへ問題を送信するようになりました。全員に対してCascadeをオフにするリリースが行われるまでの6週間、変更履歴は「Cascadeがオフになっている世界」の挙動を説明し続けていたのです。

これを過剰に解釈してしまいがちですが、Devin Localが何を引き継ぎ、何を引き継がないのかを正確に整理しましょう。

Devin Localは、永続性のないツールではありません。ドキュメントにはその逆が書かれています。

"Devin Localエージェントは、永続的なコンテキストや再利用可能なワークフローを提供するためのルール、AGENTS.mdファイル、およびスキルをサポートしています。"

また、計画の成果物を安定した場所に書き出します。

"計画は~/.devin/plans/plan-<session>.mdにある永続的なMarkdownファイルに書き込まれるため、編集したり、後で戻ってきたり、新しいセッションに引き渡したりすることができます。"

つまり、率直なまとめとしては非常にシンプルです。Devin Localの永続性は「ファイルベース」だということです。ルール、AGENTS.md、そしてスキルはファイルであるため生き残ります。そして、そのほとんどはリポジトリ内のファイルです。計画もファイルとして生き残りますが、デフォルトではプロジェクト内ではなくホームディレクトリに保存されます。生き残らないのは、あなたではなく「エージェント」が何を保持すべきかを決定していた、唯一のメカニズムです。

ルールフォルダ自体は、優先順位（.devin/rulesが優先、.windsurf/rulesがフォールバック、レガシーなルートファイルも引き続き読み込み）を含め、移行を無傷で乗り越えました。リポジトリ内でどれが実際に優先されているか整理できていない場合は、merging your Windsurf and Devin rule foldersで統合手順を解説しています。ルールがより多くの役割を担うようになった今、この作業の価値は1週間前よりも高まっています。

また、変わらないもう一つの事実は、開発元自身の推奨事項です。これはMemoriesページにずっと掲載されていました。

"Cascadeに確実に再利用させたい知識については、自動生成されるMemoriesに頼るのではなく、ルールとして書き出すか、リポジトリ内のAGENTS.mdに追加してください。ルールはバージョン管理可能で、チームと共有でき、有効化のタイミングを明示的に制御できます。"

このアドバイスは、製品の仕様変更を生き延びるためではなく、検索の信頼性を高めるために書かれたものでした。しかし結果として、その両方において正しいアドバイスであったことが証明されました。

世間の反応は、「Cascadeユーザーは急いでDevin Localに移行する必要がある」「教訓はエディタのリリースノートを常にチェックすることだ」というものです。どちらも事実ですが、本質的に興味深い部分ではありません。

まず避けるべきなのは、これを「1つのベンダーが1つの機能を廃止しただけ」と捉えることです。これはここ数ヶ月で発生した、まったく同じパターンの3番目の事例であり、他の2つはこのベンダーとは何の関係もない開発元によるものです。

Kilo Codeのドキュメントには、以下の通知が掲載されています。

"Kilo Codeのメモリバンク機能は非推奨となり、AGENTS.mdに移行されました。"

その移行手順は、メモリバンクの内容をプロジェクトのAGENTS.mdに移動することであり、そのファイルに関する説明で理由が明かされています。

"AGENTS.mdは、ソフトウェアプロジェクトにおけるAIエージェントの挙動を設定するためのオープンスタンダードです... この標準は、複数のAIコーディングツールによってサポートされています。"

OpenHandsは逆の方向からアプローチし、同じ場所にたどり着きました。その永続メモリ機能は存在しますが、ドキュメントでは「オプトイン方式で、デフォルトではオフ」と説明されており、これがなければ「エージェントは既存のAGENTS.mdベースのガイダンスを保持し、プロンプトは変更されない」とされています。リポジトリファイルがデフォルトであり、エージェントが管理するメモリは「オンにするもの」なのです。

3つの独立したチーム、3つの製品が、1つの結論に収束しました。すなわち、「プロジェクト知識の耐久性のあるコンテナはリポジトリ内のファイルであり、エージェント側に蓄積されるストアは、非推奨になったり、オプションになったり、削除されたりするレイヤーである」ということです。これは、どの製品に対する批判でもありません。自動生成されるストアは、わざわざ書き留めないような事柄をキャプチャしてくれるため、純粋に便利です。しかし、それは特定のエージェントの実装に紐づいており、それこそが製品チームが変更を加える対象そのものなのです。

次に避けるべきなのは、ウィザードがそこを指し示していたからといって、「スキルが解決策だ」と結論づけることです。スキルとは、モデルが関連性があると判断したときに呼び出す「手順」です。「リリースの実行方法」を置くには適していますが、「再配信セマンティクスの問題で、3月に別のキューライブラリを却下した」といった経緯を置くには不向きです。Why agent skills aren't memoryではその違いを解説していますが、移行パスが一方を他方に統合するよう促している現状において、この区別は極めて重要です。

3つ目は、これを「ロックイン」の物語として捉えることです。部分的にはそうですし、whether AI memory is a feature or lock-in（AIメモリは機能か、それともロックインか）は、どのベンダーに対しても投げかけるべき正当な問いです。しかし、ロックインとは通常、データを外部に取り出せないことを意味します。今回のケースでは、ファイルは常に読み取り可能であり、ドキュメント化されたパスに沿って、あなた自身のディスク上に存在していました。問題はアクセス権ではなく、ワークスペースのフローにおいて、それらのファイルを2台目のマシンや2人目のチームメンバーが見える場所に移動させる仕組みが一切なかったことです。

これらすべてを実践に移すには、整理作業が必要です。一度これを行っておけば、次の機能廃止の際にも慌てることはありません。

Step 1: 廃止されたストアに実際に何が保持されているかを確認する

どこに何を配置するかを決める前に、蓄積された内容を読み込んでください。Cascadeのメモリは、それを生成したマシンのドキュメント化されたディレクトリに、ワークスペースごとに保存されています。それらを開き、各エントリを3つのバケットに分類します。「恒久的な指示（例：npmではなくbunを使用する）」、「理由を伴う意思決定（例：マイグレーションの都合によりORMの使用をやめた）」、あるいは「数ヶ月前に完了したタスクに関する一時的なメモ」です。

自動生成されたストアに蓄積されるものの大部分は3つ目のバケットであり、だからこそ、これらの機能廃止は人々が予想するほど痛手を伴いません。しかし、本当に価値があるのは2つ目のバケットです。そして、ルールファイルに「なぜ（理由）」を書き込む人はいないため、現在リポジトリ内のどのファイルもこの情報を保持していません。

Step 2: 恒久的な指示をルールレイヤーに送る

1つ目のバケットは、開発元が推奨する場所に配置します。.devin/rules/内のルール、またはリポジトリのAGENTS.mdです。どちらもDevin Localによって読み込まれ、バージョン管理され、同じコンベンションに従う他のツールからも読み込まれます。各エントリは1〜2文にとどめ、適用すべき頻度に合致するアクティベーションモードを持つファイルに記述してください。

名前の付け方に関する注意点です（正しく設定するのは簡単ですが、間違えてもエラーは出ません）。Devin DesktopのドキュメントではAGENTS.mdとagents.mdの両方が認識されるとされていますが、同じコンベンションを読み込む他のツールでは大文字のファイル名が必須となる場合があります。共有リポジトリでは、AGENTS.mdを使用してください。

Step 3: 特定の製品インターフェースに依存しない、理由の「家」を作る

2つ目のバケットには、行き先がありません。ルールファイルは不適切なコンテナです。ルールはすべてのセッションで読み込まれるため、履歴で埋め尽くすとコストが高くなります。また、ルールの目的は簡潔かつ命令的であることです。スキルも、前述の理由から不適切です。

そのコンテンツには、特定のエディタの外部にあり、別のツールを使っているチームメンバーもアクセスできる、クエリ可能な場所が必要です。これこそが、一連の機能廃止が指し示し続けているレイヤーであり、3つのベンダーのいずれも提供していない唯一のものです。

MemoryLakeは、意思決定の「理由」を保管する場所です。エディタの外部に位置し、MCPやAPIを介して、要求してきたあらゆるエージェントに情報を提供します。そのため、今日記録した決定事項は、次のエージェントインターフェースが廃止された後でも参照可能です。ルールやAGENTS.mdは、Devin Local'sのドキュメントに記載されている通りリポジトリ内に留まります。共有レイヤーは、それらのファイルが本来担うべきではない部分を保持します。

Step 1: APIキーを作成する

キーを生成し、約30秒で最初のリクエストを実行できます。整理を始める前にこれを行っておけば、古いメモリを読み進めながら、それぞれの理由を保存する場所を確保できます。

Step 2: 最初のメモリをアップロードする

2つ目のバケットのエントリを1つずつ処理していきます。それぞれの決定について、何が選ばれ、何が却下され、その理由は何だったのかを書き留めます。アーキテクチャのメモ、インシデントの報告書、ベンダーの比較表などのサポートドキュメントも、同じ場所に保存します。

Step 3: AIとエージェントを接続する

Devin Local、Claude、Codex、およびその他のエージェントに、MCPまたはAPI経由でアクセスを許可します。誰かが「なぜこの規約が存在するのか」と尋ねたとき、単にルールを繰り返すのではなく、その理由が添付された形で回答が返ってきます。

1つ目の変化は、機能の廃止が緊急事態ではなくなることです。ベンダーがエージェントインターフェースを削除しても、リポジトリと共有レイヤーを確認すれば、どちらもそこに残っています。

2つ目は、整理作業が一度きりで済むことです。Cascadeのメモリから取り出したものはすべて、次のツールが初日から読み取れる形式になっているため、「移行」と「再導入」の間に生じるギャップが解消されます。

3つ目は、新しいマシンや新しいチームメンバーが、あなたと同じスタートラインに立てることです。Cascadeのメモリはワークスペース限定かつローカルだったため、2回目のチェックアウト時は空の状態から始まりました。リポジトリファイルとクエリ可能な共有レイヤーの組み合わせには、そのような非対称性はありません。これは、Devin losing task context between sessions（セッション間でDevinがタスクコンテキストを失う問題）が常に帰着していたのと同じ問題です。

4つ目は、ルールファイルが長くなるのではなく、短くなることです。理由を置く場所が決まれば、ルールは1行の命令文で済むようになります。これこそが、アクティベーションモードのシステムが本来想定していた設計です。

リリースノートの条件節を読む。 「Cascadeが削除されました」の前に、6週間にわたって「Cascadeが無効な場合」という表現が使われていました。機能がオフになっていることに関する記述は、通常、仮定の話ではなくスケジュールを意味します。

バージョン管理されていないものはすべて、唯一のコピーとして扱う。 自身のディスク上のドキュメント化されたパスは、バックアップでも引き継ぎ資料でもありません。重要な情報でありながらコミットされていない場合、それは世界に1つしか存在しません。

移行ウィザードに情報アーキテクチャを決定させない。 ガイド付きフローは、移行先が用意しているコンテナにコンテンツを移動させます。それは便利ですが、そのコンテナが適切であることと同義ではありません。

指示はファイルに保持し、理由はファイルから除外する。 恒久的な指示は、毎セッション読み込まれるルールレイヤーに属します。履歴は、必要に応じて取得できる場所に置くべきです。

ツール間でファイル名の大文字・小文字を確認する。 あるベンダーの大文字・小文字を区別しないマッチングは、別のベンダーにとっては静かな無視につながります。大文字のAGENTS.mdは、このコンベンションを読み込むすべての場所で認識されます。

自動生成されるレイヤーは変更されるものと想定する。 今年、3つのベンダーにわたって、このレイヤーは非推奨になり、オプションになり、そして削除されました。

Devin Desktopの変更履歴は、Cascadeの削除を2026年9月8日のリリースとしており、ドキュメントには、代替となるエージェントがセッション間でメモリを保持しない一方で、ルール、AGENTS.md、スキル、および永続的な計画ファイルを完全にサポートしていることが明記されています。これらはすべてドキュメント化されており、筋が通っています。今回浮き彫りになったのは、ほとんどのチームがプロジェクトの意思決定の背景をどこに置くかを決めていなかったということです。彼らはエージェントにローカルディレクトリへそれを蓄積させ、その結果を「機能」として扱っていたのです。

解決策は地味ですが、永続的です。恒久的な指示はリポジトリに置きます。これは、ベンダーが何ヶ月も前からそうするように言ってきたことです。その背後にある理由は、単一の製品インターフェースに依存しない、クエリ可能な場所に置きます。そうすれば、次に何かを廃止するリリースノートが出ても、月曜日を意思決定の再構築に費やすことなく、軽い興味を持ってその段落を読むだけで済むようになります。