なぜタスクコンテキストはDevinのセッションを越えて残らないのか
Knowledgeのスコープはタスクではなくコードベース
これは下流のすべてを決定するため、再確認する価値があります。Knowledgeは「Devinがすべてのセッションで参照できる指示やアドバイスのコレクション」です。ドキュメントに記載されている例は、すべて永続的なリポジトリレベルの素材です。「コード準拠のプラクティス、デプロイのワークフロー、PRの命名規則、テストのワークフロー、独自のツールとの対話方法など」です。
これらの中に「先週の火曜日にこのバグについて突き止めたこと」は含まれません。タスクレベルの発見はストレージのスコープ外であるため、意図的に昇格させるか、別の場所に書き込まない限り永続化されません。
ピン留めされていないKnowledgeはトリガーされた時のみ使用される
2番目に大きな原因であり、多くの人が見落としがちな設定の詳細です。「Knowledgeは、設定したトリガーに基づいて取得されます。トリガーが具体的であるほど（例：どのファイル、リポジトリ、またはタスクの種類にKnowledgeが適用されるか）、取得の精度が向上します。」
また、ベストプラクティスのリストには次のようにあります。「Devinがセッションでの作業中にいつでもKnowledgeノートを取得できるようにしたい場合は、すべてのリポジトリにピン留めしてください。そうでない場合は、その情報がそのコンテキストでのみ関連する場合、特定のリポジトリにピン留めできます。Knowledgeがピン留めされていない場合、トリガーされたときにのみ使用されるため、トリガーの説明が明確であることを確認してください。」
つまり、作成したもののピン留めしていないKnowledgeノートは、トリガーの説明の背後に隠れています。その説明が曖昧な場合、トリガーが起動しない可能性があります。ノートは存在していても、セッションに届いていません。これは、why agents ignore the instruction files you wrote（エージェントが作成した指示ファイルを無視する理由）で説明されているのと同じ種類の失敗です。
ここには非常に便利な機能があり、あまり活用されていません。「Devinはセッション中に使用したKnowledgeを教えてくれます。これはセッションチャットの'Accessed Knowledge'（アクセスされたKnowledge）で確認できます。」これは「本当に私のノートを読んだのか？」という疑問に対する直接的な答えです。何かを疑う前に、まずここを確認してください。
自動生成されたKnowledgeは出発点であり、記録ではない
Devinは自動でセットアップを行います。「Devinは、接続されたリポジトリの既存のREADME、ファイル構造、およびコンテンツに基づいて、リポジトリのKnowledgeを自動的に生成します。」
これは便利ですが、KnowledgeベースがREADMEの記述（多くのリポジトリでは一部古くなっているもの）から始まることを意味します。ドキュメントに記載されている最初のベストプラクティスは、まさにこれです。「自動生成されたKnowledgeを確認し、(a) 網羅性 と (b) 正確性 を検証してください。」
このステップをスキップすると、自信に満ちて取得可能でありながら、わずかに間違っているコンテキストが残ることになります。これは、使用されてしまうため、空のストレージよりも悪影響を及ぼします。
Devinは専用ファイルを読み込み、通常の .md はスキップする
正確で、見落としがちなルールがあります。「Devinは、.rules、.mdc、.cursorrules、.windsurf、CLAUDE.md、AGENTS.md などのコードベース内の専用ファイルに基づいて、Knowledgeを自動的にプルおよび更新します。Devinは、.md などのより一般的なファイルタイプを自動的にプルすることはありません。」
これには2つの影響があります。第一に、規約が docs/engineering-standards.md にある場合、Devinはそれを自動的にプルしません。ドキュメントの推奨事項は、これを修正することです。「コードベースに一元化された専用のドキュメントファイルがない場合は、専用のファイル拡張子を使用して設定することを強くお勧めします。」
第二に（これは嬉しい驚きですが）、他のツールで使用している CLAUDE.md、AGENTS.md、または .cursorrules がすでにリポジトリにある場合、Devinはそれらを読み込みます。別のエージェントのために作成した指示ファイルが、すでにここで役立っています。
リポジトリへのアクセス権がない＝Knowledgeもなし
明白な注意点として記載されています。「Devinにリポジトリへのアクセス権を与えない場合、関連するKnowledgeは生成されません。」特定のリポジトリがDevinにとって白紙の状態のように感じられる場合は、他の何よりも先にアクセス権を確認してください。
よく試されるアプローチ
すべてのセッションの開始時にDevinに再説明する。 効果はありますが、毎回同じコストを支払うことになります。これは how to stop re-explaining context to AI（AIへのコンテキストの再説明を止める方法）で説明されているループです。
すべてのタスクの発見事項をKnowledgeに書き込む。 気持ちは分かりますが、コードベースレベルのストレージがタスクレベルのノイズで満たされ、本来そこにあるべき情報の取得精度が低下します。
すべてをすべてのリポジトリにピン留めする。 確実に取得できますが、無関係なコンテキストがすべてのセッションに入り込みます。これは、より細かい設定ができるダイヤルを大雑に回すようなものです。
自動生成されたKnowledgeを未確認のまま放置する。 最も一般的な近道ですが、古いREADMEを信頼性の高そうなガイダンスに変換してしまいます。
リポジトリ内に notes.md として決定事項の実行ドキュメントを保持する。 合理的な直感ですが、拡張子が間違っています。Devinは一般的な .md ファイルを自動的にプルしません。
コーディングの好みが自動的に実行間で引き継がれると仮定する。 Knowledgeに存在し、アクセス可能であれば引き継がれます。これは why Devin forgets coding style（Devinがコーディングスタイルを忘れる理由）の背景にあるケースです。
解決策：永続化すべき情報を昇格させ、タスクの推論をクエリ可能に保つ
やるべきことは2つあります。コードベースレベルの素材に対してKnowledgeを適切に機能させること、そしてタスクレベルの推論にセッション以外の居場所を与えることです。
今すぐ自動生成されたKnowledgeを確認する。 ドキュメントの指示通り、網羅性と正確性を検証してください。廃止したシステムについて説明しているものはすべて削除します。古いエントリも、正しいエントリと同じ確信度で取得されてしまいます。
各ノートについて、ピン留めするかトリガーにするかを決定する。 常に適用すべきですか？すべてのリポジトリにピン留めしてください。1つのリポジトリでのみ関連しますか？そこにピン留めしてください。本当に状況に応じたものですか？トリガーのままにしておき、適用されるファイル、リポジトリ、またはタスクの種類を指定して、起動するのに十分具体的なトリガー説明を記述してください。
専用のドキュメントファイルがない場合は作成する。 AGENTS.md は優れたデフォルトです。Devinはこれを自動的にプルし、他のエージェントも読み取ります。すでに CLAUDE.md や .cursorrules を管理している場合は、それらもリストに含まれているため対応済みです。
フィードバックループとして「Accessed Knowledge」を使用する。 セッション後、Devinが実際に何を使用したかを確認します。期待していたノートがリストにない場合、問題は書き方ではなく、トリガーまたはピン留めにあります。
白紙のように感じられるものについては、リポジトリのアクセス権を確認する。 アクセス権がなければ、Knowledgeは生成されません。
これでコードベースレベルのコンテキストは信頼できるようになります。しかし、ドキュメントが明示的にKnowledgeの対象外としているカテゴリ、すなわち「タスクレベルの推論」がまだ残っています。前回の実行で何を試してなぜ失敗したか。途中で発見した制約。評価して却下したアプローチ。これらすべてをKnowledgeに昇格させるのは誤りです。それらはコードベースレベルではなく、本来あるべき情報の取得精度を低下させます。
そこで役立つのが MemoryLake です。リポジトリレベルのストレージとは別に、エージェントがクエリするレイヤーにタスクとプロジェクトの推論を保持します。セットアップは3つのステップです。
ステップ 1: APIキーを作成する
MemoryLake にサインインし、APIキーを作成します。接続するツール間で共通の認証情報1つで済みます。
ステップ 2: 最初のメモリをアップロードする
1つの主張につき1つの短いエントリ。自律型エージェントを使用する際に、最も早く投資回収できるカテゴリは以下の通りです。
試して却下されたことと、その理由。 エージェントが自律的に作業する場合、最も価値の高いエントリクラスです。これがないと、3回目の実行で、1回目の実行ですでに否定されたことを再検証することになり、余計な時間を費やすことになります。
実行を超えて存続する実行からの発見。 「ステージングのシードデータには2024年以降の行がないため、日付範囲テストはローカルでは合格し、そこでは失敗する。」これはコードベースレベルのアドバイスではなく、一回限りのものでもありません。
タスクの途中で初めて明らかになった制約。 レート制限、ドキュメントと異なる挙動をする依存関係、誰も書き留めていなかった順序の要件など。
決定事項と、その背後にある制約。 規約はKnowledgeに入れることができます。しかし、その議論は、取得して推論できる場所に属します。
ステップ 3: AIとエージェントを接続する
使用するツールを接続します。MemoryLakeはMCPおよびAPI経由でアクセスできるため、Claude Code、Codex、OpenClawなどのMCPネイティブエージェントはMCPサーバーを指定することで接続し、他のアシスタントはAPIを介して同じメモリを読み取ります。
3つの率直な制限事項。MemoryLakeはDevin's Knowledgeに書き込むわけではなく、その代替品でもありません。Knowledgeはコードベースレベルのコンテキストに適した場所であり、適切に設定する必要があります。MemoryLakeは、あなたやエージェントが書き込んだ内容のみを保持するため、ステップ2は実際の作業を伴います。また、コンプライアンスを保証するものではありません。取得可能なコンテキストは、強制される設定ではありません。
実践における変化
3回目の実行で1回目の実行を繰り返さなくなる。 却下されたアプローチが書き留められているため、自律型エージェントがセッションを費やしてそれらを再発見する必要がなくなります。
Knowledgeがクリーンに保たれ、取得精度が鋭く維持される。 コードベースレベルのストレージにコードベースレベルの素材のみを置くことで、トリガーの説明がより少なく、より関連性の高いものに一致するようになります。
「Accessed Knowledge」が有益な情報になる。 ストレージがゴミ捨て場になっていなければ、何が使用されたかを見るだけで意味のある情報を得られます。
指示ファイルが2つの役割を果たす。 AGENTS.md や CLAUDE.md はDevinのKnowledgeに自動的に供給され、他のエージェントにも読み取られるため、1つのファイルで複数のツールに対応できます。
タスクの推論がツールの変更を越えて存続する。 自身のシステムについて学んだことはDevin固有のものではありません。これは episodic memory for AI agents（AIエージェントのエピソード記憶）でカバーされている形態です。
DevinのKnowledgeとタスクコンテキストのベストプラクティス
Knowledgeはコードベースレベルに保つ。 これがドキュメントに記載された目的です。タスクの発見事項は別の場所に置かないと、ストレージの品質が低下します。
常に適用すべきものはピン留めする。 ピン留めされていないKnowledgeはトリガーされたときのみ使用されます。これはドキュメントに記載された動作であり、回避すべきバグではありません。
具体的な名前を指定したトリガー説明を書く。 ファイル、リポジトリ、またはタスクの種類。具体的なトリガーほど取得精度が向上します。ドキュメントに直接そう書かれています。
自動生成されたKnowledgeを信頼する前に確認する。 README、ファイル構造、リポジトリのコンテンツから派生したものであり、これらは古くなります。網羅性と正確性を検証してください。
専用のファイル拡張子を使用する。 .rules、.mdc、.cursorrules、.windsurf、CLAUDE.md、または AGENTS.md を使用し、自動的にプルされない通常の .md は避けてください。
重要なセッションの後に「Accessed Knowledge」を確認する。 最も手軽な診断方法ですが、ほとんどの人は一度も開きません。
却下された事項はすぐに記録する。 アプローチが除外された瞬間こそ、その理由が頭の中に完全に残っている唯一の瞬間です。
環境に関するものには日付を入れる。 ステージングの癖やレート制限は変化します。日付のないエントリは、将来の誤った回答につながります。これは what AI memory is and isn't（AIメモリとは何か、何ではないか）における一般的な問題です。
結論
DevinのKnowledgeシステムはセッション間でコンテキストを永続化しますが、その境界線についてドキュメントは正確に記述しています。それはタスクレベルではなくコードベースレベルのコンテキストのためのものであり、ピン留めしない限り設定したトリガーによって取得され、確認することが前提の素材から自動生成され、一般的な .md ファイルではなく専用ファイルからプルされます。
これらを適切に設定すれば、リポジトリレベルの課題は解決します。その後、タスクレベルの推論（却下事項、タスク途中の発見、環境の制約、各決定の背後にある議論）を独自のカテゴリとして扱い、エージェントがクエリできるレイヤーに保持します。これが、すべての実行を「優秀な新入社員」として開始するエージェントと、すべての実行を「初日の新入社員」として開始するエージェントの違いです。