実際に移行されるもの
Devin がリポジトリから学習した内容は、移行する必要はありません。 これを最初に明確にしておくことで、作業量を大幅に削減できます。Devin のドキュメントによると、既存の README や接続されたリポジトリのファイル構造・コンテンツから Knowledge が自動的に生成され、CLAUDE.md や AGENTS.md などのエージェント指示ファイルから Knowledge が取得・更新されます。Knowledge ノートが README の言い換えである場合、それはすでに Claude Code が読み取るリポジトリ内に存在しています。
Devin に直接入力した内容こそが、代替不可能な部分です。 他のどこにも存在しないノート（デプロイの順序、独自ツールの癖、特定のディレクトリがアクセス禁止である理由など）は、Cognition のウェブアプリ内に存在します。Devin のドキュメントでは、Knowledge を「Devin がすべてのセッションで参照できる指示やアドバイスのコレクション」と説明し、その作成、トリガー、ピン留めの方法を説明しています。しかし、エクスポート機能については記載されておらず、回避策もありません。読み取ってコピーするしかありません。
トリガーはテキストと同じくらい重要です。 これは多くの人が見落としがちな部分です。Devin の取得は条件付きです。「Knowledge は設定したトリガーに基づいて取得されます。トリガーが具体的であるほど（例：どのファイル、リポジトリ、またはタスクの種類に Knowledge が適用されるか）、取得の精度が向上します。」ノートとトリガーが合わさることで、スコープ定義されたルールになります。トリガーのないノートは、すべてのセッションに読み込ませるか、完全に忘れてしまうだけの単なる文章になってしまいます。回収する際は、両方のカラムを回収してください。
ピン留めもスコープ情報です。 Knowledge ノートは、すべてのリポジトリにピン留めすることも、特定のリポジトリにピン留めすることもできます。これは Claude Code のメモリ階層に直接マッピングされるため、作業を進めながら書き留めておきましょう。どこにでもピン留めされているノートは個人または組織レベルの指示になり、1つのリポジトリにピン留めされているノートはそのリポジトリのコミットされた指示になります。
移行先で Claude Code が提供するもの。 CLAUDE.md ファイルは、すべてのセッションの開始時に読み込まれ、広範なものから具体的なものへと解決されます。まず組織管理のファイル、次に個人設定用の ~/.claude/CLAUDE.md、そしてチーム用にコミットされたプロジェクトの ./CLAUDE.md または ./.claude/CLAUDE.md、最後にプライベートなプロジェクトごとのノート用の ./CLAUDE.local.md です。作業ディレクトリより上の階層にあるファイルは起動時にすべて読み込まれ、サブディレクトリ内のファイルは Claude がそのディレクトリのファイルを読み取るときに読み込まれます。条件付きの読み込みには .claude/rules/ があり、ルールファイルに paths: フロントマターを持たせることで、Claude が一致するファイルに触れたときにのみコンテキストに入ることができます。これは、Claude Code において Devin のトリガーに最も近い構造的代替手段です。
始める前の2つの率直な注意点。 Devin の Knowledge は実際に機能している本物の機能であり、この移行が面倒なのは、壊れたものから逃げるのではなく、機能しているものを離れるからです。また、Claude Code もメモリシステムではありません。そのドキュメントには、指示ファイルは「厳格な設定ではなくコンテキスト」であり、厳格な準拠は保証されないと明記されています。ルールを毎回確実に適用する必要がある場合、ドキュメントはより良い文章を書くことではなく、フック（hooks）の使用を推奨しています。
手動移行の手順
ステップ 1: アクセス権を失う前に Knowledge を回収し、出自ごとに分類する
サブスクリプションが有効なうちに、Knowledge リストを開き、すべてのノートをスクラッチファイルにコピーします。その際、ノートのテキスト、トリガー、ピン留め先の3つの情報を記録してください。この移行における他のすべてのステップは後からやり直せますが、これだけは不可能です。
次に、各ノートをその出自に応じて以下の3つのグループに分類します。
リポジトリから派生したもの。 README の言い換え、ディレクトリ構成、package.json に書かれているテストコマンドなど。これらは削除してください。Claude Code はリポジトリを読み込み、/init を実行すると、見つかった内容から初期の CLAUDE.md を生成します。これらをそのままコピーすると、ファイルが長くなり、指示への準拠率が低下します。
自分が作成し、現在も有効なもの。 デプロイの順序、特定のフラグが必要なツール、今期は誰もリファクタリングすべきではないモジュールとその理由など。これらが移行の対象です。
自分が作成したが、すでに無効なもの。 どの Knowledge コレクションにもこれらがあります。廃止されたサービスに関するノートや、修正済みのバグに対する回避策などです。指示ファイルに古いルールを残しておくことは、それを失うことよりも悪影響を及ぼします。なぜなら、Claude はそれに従ってしまうからです。どれがどれであるかを覚えている今のうちに、意図的に削除してください。
この作業を行う際、便利な手がかりがあります。Devin のセッションには、アクセスした Knowledge が表示されます。そのため、最近のセッションを見れば、実際にどのノートが機能しているかがわかります。1ヶ月間取得されていないノートは、トリガーの設定が不適切か、すでに不要になっている可能性が高いため、3つ目のグループの候補になります。
ステップ 2: ノートを CLAUDE.md およびパススコープのルールとして再構築する
記録したスコープに従って、残ったノートを配置します。すべてを1つのファイルにまとめる必要はありません。
- すべてのリポジトリにピン留め（個人用） →
~/.claude/CLAUDE.md。あなたの習慣や好みのワークフロー。短くまとめてください。マシンのすべてのプロジェクトで読み込まれます。 - すべてのリポジトリにピン留め（チーム全体の標準） → 各リポジトリのプロジェクト
CLAUDE.md、またはチームが中央でデプロイしている場合は組織の管理ポリシーファイル。 - 1つのリポジトリにピン留め → そのリポジトリのルートにある
./CLAUDE.md。コミットすることで、チームメンバーも再発見することなくその指示を引き継ぐことができます。 - 特定のファイルまたは特定のタスクでトリガー →
.claude/rules/内のファイルで、それらのファイルに一致するpaths:フロントマターを設定します。これは Devin のトリガーが機能していた方法に最も近いものです。paths: ["src/api/**/*.ts"]とすると、Claude が API レイヤーで作業するときにのみそのルールが読み込まれ、それ以外の場合はコンテキストから除外されます。 - プライベートかつプロジェクト固有 →
./CLAUDE.local.md（gitignored）。
ここで、トラブルを防ぐための2つの技術的な詳細があります。Claude Code のドキュメントでは、CLAUDE.md あたり200行未満に抑えることを推奨しています。ファイルが長くなると、より多くのコンテキストを消費し、指示が守られる一貫性が低下するためです。したがって、ステップ1での仕分けは単なる整理整頓ではなく、結果を機能させるための重要なプロセスです。また、リポジトリにすでに Devin が読み取っていた AGENTS.md がある場合は、重複させないでください。@AGENTS.md を使ってそれをインポートする CLAUDE.md を作成し、その下に Claude 固有の指示を追加することで、両方のツールが1つのソースを読み取るようにします。
最後に、今回避した非対称性に注目してください。Devin は最初からリポジトリのエージェントファイルを読み取っていました。Claude Code は、新しいインタラクティブフローを有効にして /init を実行すると、Devin Desktop のセットアップから .devin/rules/ ファイルを読み取ることができ、/import を使用してサポートされているエージェントの設定を移行できます。しかし、どのツールも読み取ることができないのは、ウェブアプリ内にのみ存在していた Knowledge です。ここでの教訓は Devin に限ったことではありません。ベンダーの UI に保存された知識は、いつか手動でコピーすることになる知識であるということです。
より良い方法：1つのメモリレイヤー、どちらのエージェントでも
ベンダーのナレッジストアをファイルに変換するために1時間を費やしました。これらのファイルは、バージョン管理可能、レビュー可能、grep可能、ポータブルであり、真の改善と言えます。しかし、来期に Codex を追加したり、チームメンバーがリリースノートを作成する際に ChatGPT で同じコンテキストを使用したいと考えたりした場合に、再び同じことを行わなければならない状況を想像してみてください。1つのツールしか読み取れない場所から、もう一度コピーすることになります。
解決策は、永続的な素材をすべてのシスタントが読み取れる1つのストアに保持し、指示ファイルはコーディングエージェントが常に目の前に置いておく必要がある短く厳格なルールという、本来の得意分野に特化させることです。
MemoryLake はそのためのメモリレイヤーです。ルールの背後にある決定、インシデント履歴、ソースドキュメントを1つの場所にまとめ、Claude や Codex などの MCP 対応ツールから直接、また API を通じて ChatGPT から読み取ることができます。ルールはリポジトリに残り、その理由は1つの製品のデータベースに閉じ込められなくなります。
ステップ 1: API キーを作成する
キーを生成し、約30秒で最初のリクエストを送信します。セッションに貼り付けるのではなく、環境変数やシークレットマネージャーに保存してください。
ステップ 2: 最初のメモリをアップロードする
移行したばかりのノートの背後にあるドキュメント、画像、ファイルを投入します。デプロイ順序の元となったランブック、ディレクトリへのアクセスを禁止する原因となったインシデントの報告書、アーキテクチャの決定事項、かつて文書化したベンダーの API の癖などです。1行の要約バージョンではなく、ソース自体をアップロードしてください。1行の要約バージョンは、あなたが先ほど1時間かけて再構築したものです。
ステップ 3: AI とエージェントを接続する
Claude、Codex、OpenClaw、およびその他の AI エージェントに、MCP または API を介してメモリへのアクセス権を付与します。Claude Code は、CLAUDE.md ファイルと並行して、MCP 経由でストアを直接読み取ります。ChatGPT の場合は、API を介して必要な情報を取得し、プロンプトまたはモデルを呼び出すワークフローに注入します。
実務における変化
最初の違いは、ルールとともに理由も引き継がれることです。「ステージングへのデプロイ前にマイグレーションを実行する」というルールは、誰かが不要だと判断するまで従われます。「ステージングへのデプロイ前にマイグレーションを実行する —— 順序が狂ったデプロイにより、3月にステージングが2回ダウンしました。報告書を参照してください」というルールは、新しいエンジニアの判断を乗り越えて生き残ります。
2つ目の違いは、CLAUDE.md を短く保てることです。指示ファイルにおける最大の葛藤は、有用なものはすべて常に読み込まれるファイルに入れたい一方で、常に読み込まれるファイルは大きくなるほど効果が薄れるという点です。詳細情報を取得（retrieval）できるようになれば、ファイルには厳格な制約のみを保持し、それ以外は保持しないようにできます。これは、セッションごとにコードベースを再読み込みするエージェントが、すでに知られていることから始めずに毎回コードベースを読み直してしまう問題の解決策でもあります。
3つ目の違いは、次の移行が容易になることです。今回の移行では、UI からのコピーに1時間かかりました。次回は、知識が移行元のツール内部に存在しないため、設定を変更するだけで済みます。
また、これは Claude Code がすでに備えている機能とも調和します。Claude Code の自動メモリ機能は、ビルドコマンドやデバッグの洞察をリポジトリごとに独自に蓄積し続けます。その境界線を知っておく価値はあります。そのストアはマシンローカルであり、ドキュメントによると、ファイルはマシン間やクラウド環境間で共有されません。したがって、ローカルの便利なレイヤーとしては優れていますが、信頼できる唯一の情報源（system of record）としては不十分です。これこそが、まさに求めている役割分担です。
エージェントプラットフォームを離れる際のベストプラクティス
アクセス権があるうちに回収する
Knowledge、メモリ、保存されたコンテキストは、サブスクリプションが失効する直前まで表示されますが、失効した後は1分たりとも表示されません。まずコピーを行い、整理は後で行いましょう。これが移行プロセス全体の中で唯一、期限のあるステップです。
テキストだけでなくトリガーも記録する
取得条件は重要な情報です。Devin が決済モジュールに触れたときに実行されたノートは、パススコープのルールになります。条件を忘れてしまった同じノートは、すべてのセッションにおけるノイズになるか、無関係として削除してしまうルールのいずれかになります。両方のカラムをコピーしてください。
移行の過程で削除する
移行は、誰かがすべてのルールを新鮮な目で読み直す唯一の機会です。これを活用してください。古い指示は、存在しない指示よりも悪影響を及ぼします。なぜなら、エージェントはそれに従い、あなたは1ヶ月間そのことに気づかないからです。
理由は取得可能な場所に、ルールは読み込まれる場所に配置する
2行のルールは CLAUDE.md に記述します。インシデント報告書、RFC、およびそれを生み出したベンダーのスレッドは、エージェントが説明や再検討を必要とするときに取得できるストアに配置します。両方を指示ファイルに詰め込むと、ファイルが800行に達し、従われなくなる原因になります。
指示ファイルが強制力を持つと期待しない
Claude Code 自身のドキュメントでも、指示ファイルは強制的な設定ではなくコンテキストであると明記されており、毎回必ず実行する必要がある処理にはフック（hooks）の使用を推奨しています。移行しようとしているルールが重要なもの（例：main に直接プッシュしない、常にリンターを実行するなど）である場合は、フックや CI チェックとして実装し、指示ファイルにはそれが存在する理由を説明させてください。
結論
Devin から Claude Code への移行は一方通行のコピーであり、その理由は敵対的なものではなく構造的なものです。Devin の Knowledge は CLAUDE.md や AGENTS.md を含むリポジトリのファイルから取得しますが、Devin から外部へ取得する手段はありません。リポジトリから派生したものは、すでに Claude Code が参照する場所に存在します。ウェブアプリに直接入力した内容と、それをスコープ定義していたトリガーやピン留めは、アクセス権があるうちに手動で回収する必要があります。
もう一方の手で削除キーを持ちながらその回収を行い、スコープごとに再構築します。個人設定は ~/.claude/CLAUDE.md に、チームの標準はコミットされた CLAUDE.md に、ファイル固有のルールは paths: フロントマターを持つ .claude/rules/ に、プライベートなノートは CLAUDE.local.md に配置します。ファイルは短く保ちましょう。そして、それらのルールの背後にある理由をアシスタントが読み取れる1つのストアに配置することで、次回プラットフォームを変更する際には、すべてを再発掘するのではなく、単にツールを変更するだけで済むようになります。