メモリがエージェントに届いていない理由
機能の裏でデフォルトエージェントが変更された
先ほど引用した一文は、2つのことを同時に示しています。メモリの適用範囲を「レガシーなCascadeエージェントのみ」に限定していること、そして、あなたが実際に使用しているエージェントが「新しいタブのデフォルトエージェントであるDevin Localエージェント」であるということです。
何かが壊れたわけではありません。より新しいエージェントがデフォルトになり、古い永続化メカニズムの1つが引き継がれなかっただけです。しかし、蓄積されたコンテキストが常に自分に付いてきていると思い込んでいた人にとって、その実質的な影響は無視できません。新しいタブを開いた瞬間、そのコンテキストは存在しないのです。
開発元もすでにメモリへの依存を非推奨としている
これはドキュメントと実態が矛盾しているケースではありません。エージェントの問題が発生する前から、Devin自身のガイドラインには永続的な知識をどこに置くべきかが明記されていました。
「推奨事項: Cascadeに確実に再利用させたい知識については、自動生成されたメモリに頼るのではなく、ルールとして記述するか、リポジトリの AGENTS.md に追加してください。ルールはバージョン管理が可能で、チームと共有でき、アクティベーションを明示的に制御できます。」また、機能比較表でもメモリの用途について率直に述べられています。「単発の事実はCascadeに記憶させ、永続的な知識にはルールまたは AGENTS.md を優先してください。」
したがって、移行ウィザードはデグレードに対する回避策ではありません。ドキュメントがそもそも推奨していた方法を実践するための支援ツールなのです。
トリガーが異なる4つの永続化メカニズム
「単にルールに移動する」だけでは済まない理由は、Devin Desktopが4つの仕組みを区別しており、持っている情報に応じて適切な移行先が異なるためです。
Rules（ルール）は「Cascadeにどのように動作すべきかを指示する（例：'npmではなくbunを使用する'）」もので、always_on、glob、model_decision、manual のいずれかでアクティブになります。「コーディング規約、スタイルガイド、プロジェクトの制約」に最適です。
AGENTS.mdは「ゼロ設定で場所ごとにスコープされたルール」を提供し、「ルート = always-on、サブディレクトリ = glob」として自動的にアクティブになります。「フロントマターなしのディレクトリ固有の規約」に最適です。
Workflows（ワークフロー）は「繰り返し実行するマルチステップタスク用のプロンプトテンプレート」で、「/[workflow-name] スラッシュコマンドによる手動実行のみ」でアクティブになります。「デプロイ、PRレビュー、リリースのチェックリスト」に最適です。
Skills（スキル）は「サポートファイル（スクリプト、テンプレート）とバンドルされたマルチステップの手順」であり、「モデルによって動的に呼び出されるか、@メンション」されます。ドキュメントでは「Cascadeが参照ファイルを必要とする複雑なタスク — ここに投資してください」と特に強調されています。
この最後の一行こそが、ウィザードがルールではなくスキルを明確なターゲットにしている理由です。
ドキュメント化されているアクティベーションモードのコンテキストコスト
大量のコンテンツをルールに移動しようとしているなら、まずこのコストに関する説明を読むべきです。Devinは各モードのコストを公開しているからです。
always_on は「ルールの全コンテンツをすべてのメッセージのシステムプロンプトに含める」ため、コストは「すべてのメッセージ」にかかります。model_decision は「システムプロンプトには説明（description）のみを含め、Cascadeがその説明を関連性があると判断したときにのみルールの全ファイルを読み込む」ため、コストは「説明は常に、全コンテンツはオンデマンド」となります。glob は「Cascadeがglobパターンに一致するファイルを読み込むか編集するとき」に適用され、コストは「一致するファイルが操作されたときのみ」です。manual は「システムプロンプトには含まれず」、@rule-name と入力したときにアクティブになります。
覚えておくべき2つの例外：「グローバルルールファイル（global_rules.md）とルートレベルの AGENTS.md ファイルはフロントマターを使用せず、常にオン（always-on）になります。」
厳格な文字数制限
移行の途中で多くの人が直面する制約がこれです。
「ワークスペースのルールファイルはそれぞれ12,000文字に制限されています。グローバルルールファイルは6,000文字に制限されています。」
グローバルルールは ~/.codeium/windsurf/memories/global_rules.md にある単一のファイルに保存され、「すべてのワークスペースに適用」され、常にオンで、上限は6,000文字です。ワークスペースルールは「ルールごとに1ファイル、それぞれ独自のアクティベーションモードを持つ」形式で、1ファイルあたり12,000文字、.devin/rules/*.md（推奨）または .windsurf/rules/*.md（フォールバック）に配置されます。また、ワークスペースルートにあるレガシーな単一ファイル .windsurfrules も引き続き読み込まれます。
つまり、グローバルファイルは最も容量制限が厳しく、かつ多くの人が最初に使おうとする場所です。1年分のメモリをそこに流し込もうとしても、収まりきりません。
よくある誤ったアプローチ
メモリが新しいエージェントにも引き継がれると思い込む。 最もよくある誤解であり、この記事が存在する理由でもあります。メモリはレガシーなCascadeエージェントにのみ適用されます。
Devinには永続的なコンテキストがないと結論づける。 これも逆の方向で間違っています。Rules、AGENTS.md、Workflows、Skillsはすべて永続化され、自動生成されたメモリよりも明確なアクティベーション制御が可能です。
すべてを global_rules.md に貼り付ける。 気持ちは分かります。1つのファイルで、常にオン、フロントマターを覚える必要もありません。しかし、これは6,000文字に制限されており、すべてのワークスペースのすべてのメッセージでコストが発生します。
すべてのルールを always_on にする。 安全に思える選択肢ですが、気づかないうちにコンテキストウィンドウを消費してしまいます。長いルールを安価に説明し、必要に応じて読み込むためにこそ model_decision が存在します。
メモリを1つずつ手動で移行する。 その必要はありません。このためのコマンド Devin: Open Cascade Migration Wizard が用意されています。
ルールを書類キャビネットのように扱う。 Devinのベストプラクティスでは、これに対して明確に注意を促しています。「ルールはシンプル、簡潔、かつ具体的に保ってください。長すぎたり曖昧だったりするルールはCascadeを混乱させる可能性があります」「一般的なルール（例：'良いコードを書く'）を追加する必要はありません」。プロジェクトの事実は動作の指示ではありません。それらをルールに入れてしまうと、ルールディレクトリが機能しなくなる原因になります。これは、スタイルがどこかに書かれているにもかかわらず why Devin forgets your coding style（Devinがコーディングスタイルを忘れてしまう理由）の背景にあるパターンです。
解決策：メモリを分類し、それぞれを適切な場所に配置する
ステップ1：メモリに実際に何が入っているかを確認する
ウィザードを実行する前に、手元にあるデータを確認しましょう。メモリは「会話中にCascadeが自動生成するコンテキスト」であるため、その内容は多種多様です。そして、その多様性こそが、単一の移行先が不適切である理由です。
読み進めながら、見つかったものを以下の4つのグループに分類してください。
動作（Behavior）。 「npmではなくbunを使用する」「早期リターンを優先する」など。これらはRules（ルール）になり、アクティベーションモードの選択は単なる形式的なものではなく、重要な決定になります。
場所固有の規約（Location-specific conventions）。 特定のディレクトリ内でのみ適用されるルール。これらは AGENTS.md ファイルになり、フロントマターを一切使わずにglobのような動作を実現できます。
サポートファイルを伴う手順（Procedures with supporting files）。 スクリプトやテンプレートを必要とする、複数ステップのプロセス。これらはSkills（スキル）であり、ドキュメントで投資が推奨されている領域です。
事実（Facts）。 なぜAPIのパスにバージョンが含まれているのか、社内用語の定義、どのサービスがどのキューを所有しているかなど。これらは4つのメカニズムのいずれにも綺麗に当てはまりません。これについては後ほど説明します。
ステップ2：ウィザードを実行し、残りをアクティベーションモード別に配置する
コマンドパレットを開き、Devin: Open Cascade Migration Wizard を実行します。これは、依存しているメモリを移行するための公式なルートであり、参照ファイルとバンドルされた手順のために構築された仕組みである「スキル」を対象としています。
ウィザードでカバーされないものについては、意図的に配置場所を決めます。
どこでも適用されるべき動作は ~/.codeium/windsurf/memories/global_rules.md に配置します。6,000文字の上限があり、フロントマターなしで常にオンになることを忘れないでください。
プロジェクトにスコープされた動作は、.devin/rules/*.md に配置します。これは .windsurf/ よりも「優先される」推奨の場所です。フロントマターで各ルールに trigger を指定してください。ファイルタイプのルールにはパターンを指定した glob を使用し、ファイル全体を読み込ませるよりも説明文のコストだけで済ませたい長いルールには model_decision を使用します。本当にすべてのメッセージに適用すべき短いリストにのみ always_on を残しておきます。
ディレクトリの規約は、関連するディレクトリの AGENTS.md に配置します。ルートレベルは常にオン、サブディレクトリは「そのディレクトリに対する自動glob」となります。
デバッグの手間を省くための2つの仕様：Devinは「親ディレクトリのルールを見つけるためにgitルートディレクトリまで」検索します。また、複数のフォルダが開いている場合、「ルールは重複排除され、最も短い相対パスで表示」されます。ただし、ルールを作成すると、それは「gitルートではなく、現在のワークスペースの .devin/rules ディレクトリに保存される」ため、どこに保存されたかを確認してください。
作業の際は、フォーマットのガイダンスに従ってください。Devinは長い段落よりも「箇条書き、番号付きリスト、マークダウン」を求めており、「XMLタグは、同様のルールを伝達しグループ化する効果的な方法になり得る」と述べています。
ステップ3：4つ目のグループの置き場所を作る
4つのグループのうち3つには、適切な移行先が見つかりました。しかし、4つ目のグループ（事実）にはそれがありません。ないものをあるように見せかけることが、ルールディレクトリを形骸化させる原因になります。
プロジェクトに関する事実は、指示ではありません。これらには自然なアクティベーションモードが存在しません。always_on はたまにしか必要としない情報に対して過剰なコストを支払うことになり、glob は事実には存在しないファイルパターンを必要とし、manual はルールが存在することを知っていて @メンション する必要があります。model_decision は比較的近いですが、事実そのものではなく、事実の説明を書く必要があります。一方で、グローバルファイルは6,000文字、ワークスペースルールは12,000文字の制限があり、その貴重な容量を背景知識に割くべきではありません。
メモリレイヤーであれば、アクティベーションモードなしでこれらを保持できます。なぜなら、エージェントはパターンが一致したときではなく、そのトピックが話題に上がったときにそれを読み取るからです。MemoryLake は3つのステップでセットアップできます。
ステップ1：APIキーを作成する
サインインし、ダッシュボードからAPIキーを生成します。これは特定のエージェントにスコープされていないため、この記事の冒頭で述べたような問題（Cascadeにのみ属し、Localエージェントには属さないといった性質）はありません。
ステップ2：最初のメモリをアップロードする
4つ目のグループ（事実）をアップロードします。アーキテクチャの決定とその理由、ドメイン用語、サービスの所有権、ワークアラウンドが存在する理由、これまでに何度も行ってきた修正指示などです。
動作はルールに、手順はスキルに残しておきます。これらのメカニズムはそれぞれの役割に適しており、ドキュメント化されたアクティベーションセマンティクスを持っています。MemoryLakeは、それらを持たない情報のための場所です。
ステップ3：AIとエージェントを接続する
Devin Desktopをこのストアに向けます。文字数の制限は動作の指示に充てられ、常時オンのルールセットは十分に短く保たれ、古いメモリを価値あるものにしていた知識は、タブがどのエージェントで開かれたかに依存しなくなります。これについては turning project docs into AI memory（プロジェクトドキュメントをAIメモリに変換する）で詳しく説明しています。
実務における変化
最初の変化は、エージェントの選択が「知識の有無」を左右しなくなることです。現状では、自動生成されたレイヤーが適用されるかどうかは、タブがCascadeかLocalかに依存しています。知識がタブに依存すべきではありません。
2つ目は、文字数制限が設計上の制約にならなくなることです。グローバルで6,000文字、ワークスペースルールごとに12,000文字という制限は、動作の指示だけであれば十分ですが、動作に加えて事実まで含めると窮屈になります。そして、事実はそこに置く必要がないのです。
3つ目は、バージョン管理のメリットが最終的にすべてに適用されることです。メモリよりもルールを推奨するDevinの根拠は、ルールが「バージョン管理可能で、チームと共有でき、アクティベーションを明示的に制御できる」点にあります。これらは優れた特性であり、背景にある事実も同様にその恩恵を受けるべきです。これは keeping team AI context when someone leaves（メンバー離脱時にチームのAIコンテキストを維持する）の背景にある懸念でもあります。
Devin Desktopのルールとスキルに関するベストプラクティス
- 手動で移行するのではなく、ウィザードを実行する。
Devin: Open Cascade Migration Wizardが公式に推奨されている移行ルートです。 - 各メモリを適切なメカニズムに対応させる。 動作はRulesへ、ディレクトリの規約は
AGENTS.mdへ、ファイルを伴う手順はSkillsへ。 triggerは慎重に選択する。 ドキュメントには各モードのコンテキストコストが公開されています。always_onはコストが高くなります。- 文字数制限を遵守する。 ワークスペースのルールファイルは1ファイルあたり12,000文字、グローバルファイルは6,000文字までです。
.windsurf/よりも.devin/を優先する。 こちらが推奨される場所であり、優先されます。なお、レガシーな.windsurfrulesも引き続き読み込まれます。- 新しいルールがどこに保存されたかを確認する。 必ずしもgitルートではなく、現在のワークスペースの
.devin/rulesに保存されます。 - ルールは短く具体的に保つ。 長すぎたり曖昧なルールは「Cascadeを混乱させる可能性」があり、一般的なアドバイスはすでにモデルに組み込まれています。
- システムルールは上書きではなく追加されることを理解する。 エンタープライズのシステムレベルのルールは「ワークスペースおよびグローバルルールとマージされ、ユーザー定義のルールを上書きすることはありません」。これらにはユーザーが削除できない「System」ラベルが表示されます。
結論
今すぐ実行すべき具体的なアクションはシンプルです。自動生成されたメモリはレガシーなCascadeエージェントにのみ適用され、新しいタブのデフォルトエージェントはそれらを永続化しません。そして、依存しているメモリをスキルに移行するための公式ウィザードが用意されています。これを実行しましょう。
より大きなポイントは、Devin自身のドキュメントが示している通りです。自動生成されたメモリは単発の事実には適していますが、確実に必要となる知識の土台としては不十分です。手元にある情報を分類し、動作や手順を適切なアクティベーションモードとともに適切な場所に配置し、背景となる事実は特定のエージェントに依存しないレイヤーに保持しましょう。