実際に移行できるもの
Spaceは4つの要素で構成されており、移行先での扱いはそれぞれ大きく異なります。
スレッドはドキュメントとして、1つずつ移行します。 スレッドを開き、共有またはその他のオプションメニューから、PDF、Markdown、またはDOCXにエクスポートします。推奨するのはMarkdownです。エクスポートには、プロンプト、回答、フォーマット、そして後でリサーチを再利用するために重要なソースリストを含む引用ブロックが含まれます。Space全体をワンアクションでエクスポートする公式な方法はありません。Spaceを一括エクスポートし、Notionにプッシュするブラウザ拡張機能も存在し、実際に動作しますが、これらはPerplexityアカウントへのアクセス権限を要求するため、安易に行うのではなく慎重に判断する必要があります。
アップロードされたファイルは移行されません（すでに手元にあるはずです）。 Spaceに添付したPDFやドキュメントは、まだローカルディスクにあるか、あるべきです。Perplexityからわざわざ取り出そうとするのではなく、それらをリポジトリに再アップロードするかコピーしてください。
カスタム指示はほぼそのまま移行できます。 Spaceの指示は、トーン、深さ、優先すべき事項についてのディレクティブとしてすでに書かれています。そのほとんどは、軽い編集でCLAUDE.mdにマッピングできます。ただし、引用スタイルや回答の長さに関する部分は、移行後は不要になることがほとんどです。なぜなら、あなたはもう回答を求めているのではなく、コードを求めているからです。
探索プロセスは移行されませんし、移行すべきではありません。 40個のスレッドのうち30個は、「正しい質問は何か」を模索するためのものでした。それらの価値は、残りの10個を生み出したことにあります。40個すべてをエクスポートすると、Claude Codeに古い推論の山を渡すことになり、その一部は最終的な結論と矛盾し、すべてがコンテキストを圧迫することになります。移行が失敗するのは、情報を失うからではなく、持ち込みすぎるからです。
あらかじめ指摘しておくべき非対称性があります。Perplexityのメモリはスレッドを中心に構成されています。各会話は独立したコンテナであるため、Space内のコンテンツが他のスレッドに自動的に反映されることはありません。一方、Claude Code의 メモリはファイルシステムを中心に構成されており、プロジェクト内にあるものを読み込みます。単にツール間でテキストを移動するだけでなく、「会話形式の知識」を「ファイル形式の知識」に変換しているのです。以下に説明するのは、すべてその変換プロセスです。
手動での移行手順
ステップ 1: 重要なスレッドのみをエクスポートする
エクスポートを始める前に、Space内を整理（トリアージ）します。各スレッドについて、次の1つの質問を自分に投げかけてください。「これは自分が支持する結論を含んでいるか、それともすでに終わった検索か？」 前者のみをエクスポートし、後者はスキップします。
具体的には、決定事項を確立したスレッド（「ライセンスの関係でこのライブラリを使用する」など）、再度引用したい比較証拠を収集したスレッド、構築を制約するドメインの事実（レート制限、フォーマット、規制要件など）を含むスレッド、そして間違えた後にその原因を突き止めたスレッドを残します。最後のカテゴリは最も価値があり、最も捨てられがちです。
残すスレッドごとに、スレッドを開き、共有またはその他のオプションメニューからMarkdownを選択します。プロンプト、回答、フォーマット、そしてソースリスト付きの引用が取得できます。引用は残しておいてください。リサーチをやり直すのではなく移行する最大の理由は、ソース情報が一緒に付いてくるからです。
Spaceに数十個の残すべきスレッドがある場合、サードパーティの一括エクスポートツールの出番です。ただし、慎重に検討してください。それらはアカウントへのアクセスを必要とし、ブラウザ拡張機能にPerplexityアカウント内のすべてを読み取る権限を与えることになります。個人のリサーチSpaceであれば問題ないかもしれませんが、クライアントの秘密保持契約（NDA）下にあるものの場合は、手動でスレッドをエクスポートし、余計なリスクを排除してください。
一括エクスポートがあるからといって、トリアージをスキップしないでください。トリアージの目的はエクスポートの手間を省くことではなく、持ち込んだものすべてが後でClaude Codeの注意を引くために競合するのを防ぐことです。
ステップ 2: エクスポートしたファイルをClaude Codeが実際に読み込めるファイルに変換する
エクスポートした未加工のスレッドは、プロジェクトドキュメントとして有用ではありません。スレッドはトランスクリプト（対話の記録）です。不完全な質問、長い回答、それを修正するフォローアップ、また別の回答。Claude Codeはこれらをすべて読み込み、間違った部分を重視してしまう可能性があります。
そのため、凝縮してください。関連するスレッドのクラスターごとに、リポジトリ内（docs/research/などが適しています）に以下のような構成で1つのMarkdownファイルを作成します。
- 最初に結論を1〜2文で、プロジェクトに関する事実として記述します。
- 除外された選択肢があれば記述します。「Xを評価したが、Yの理由で却下した」と書いておくことで、エージェントが3週間後に悪気なくXを再提案するのを防げます。
- 証拠を凝縮し、エクスポートした引用ブロックからのソースリンクを添えます。
- 日付と、それがどのツールから得られたものかを記載します。リサーチは陳腐化するため、日付入りのファイルにすることで判断が可能になります。
次に、Claude Codeにそれを認識させます。プロジェクトのルートにあるCLAUDE.mdは自動的に読み込まれるファイルです。コンテンツそのものではなく、ポインタ（参照先）をここに記述します。
```markdown
リサーチのコンテキスト
意思決定とその証拠は docs/research/ にあります。src/auth/ 以下のコードを触る前に、 docs/research/auth-approach.md を読んでください。 そこに記録されている決定事項を、報告なしに再検討しないでください。 ```
リサーチ内容をインラインでそのまま流し込むよりも、この方法が優れている理由は2つあります。第1に、CLAUDE.mdはすべてのセッションで読み込まれるため、ポインタとルールだけに留めておけばタスクあたりのコストはほぼゼロですが、4,000語のリサーチ内容をそのまま流し込むと、すべてのリクエストでコスト（トークン）が発生します。第2に、@pathインポートを使用すれば、常にではなく、実際に必要なときにだけ特定のファイルを読み込ませることができます。
個人の好みはプロジェクトファイルではなく ~/.claude/CLAUDE.md に記述し、プロジェクト用のファイルはコミットしてチーム全体が同じコンテキストを引き継げるようにします。Claude Codeに最初のバージョンのファイルを下書きさせたい場合は、/initを実行するとリポジトリからスケルトンが生成され、/memoryを実行するとメモリファイルを直接編集できます。
そして、期待値を正しく設定してください。これにより知識は利用可能になりますが、記憶されるわけではありません。Claude Codeは依然として各セッションを新鮮な状態で開始し、長いセッションではコンテキストを圧縮します。そのため、適切なファイルが配置されていても、セッション間でプロジェクトのコンテキストを忘れてしまうことがあります。ファイルは最低限の土台であり、ゴールではありません。
より良い方法：リサーチとコードを統合する単一のメモリレイヤー
ステップ2で実際に行ったことを見てみましょう。あるツールのフォーマットから別のツールのフォーマットへ手動でリサーチ内容を変換し、その結果を2番目のツールしか読み取れない場所に保存しました。
これからの6ヶ月間を想像してみてください。あなたは再びPerplexity（またはそれに代わる何か）でリサーチを行い、Claude CodeやCodex、あるいは10月に発表される新しい何かで開発を行うでしょう。それぞれの組み合わせで、独自の変換が必要になります。知識は不変ですが、それを取り巻くツールは変化します。
両方のツールからアクセスできるレイヤーに知識を保持することで、この変換ステップが不要になります。MemoryLakeは、ツールの下に位置するメモリレイヤーです。リサーチノート、決定事項、ソースドキュメントを一度保存すれば、Claude CodeはMCP経由でそれらを読み込み、他のツールはAPI経由で同じストアを読み込むことができます。リサーチは、移行が必要な「Perplexityの遺物」ではなく、ツールがクエリを送信する対象になります。
トレードオフについて公平に言うと、docs/ と CLAUDE.md の組み合わせには確かなメリットがあります。プレーンテキストであり、バージョン管理下にあり、プルリクエストでレビューでき、セットアップなしで動作します。コードベースに属するものについては、この方法を維持してください。一方、メモリレイヤーが真価を発揮するのは、リポジトリの形に収まらない知識（プロジェクト横断的なリサーチ、クライアントのコンテキスト、3つのリポジトリにまたがる決定事項など）や、まだ選んでいない将来のツールからその知識を読み取れるようにする場合です。
ステップ 1: APIキーを作成する
キーを生成し、約30秒で最初のリクエストを実行します。コミットや同期される設定ファイル内にインラインで記述するのではなく、環境変数やシークレットマネージャーに保存してください。
ステップ 2: 最初のメモリをアップロードする
リサーチの実際の土台となっているドキュメント、画像、ファイルを投入します。エクスポートしたスレッド、SpaceにアップロードしていたPDF、決定事項ドキュメントなどです。単なる要約だけでなく、可能な限りソース自体をアップロードしてください。要約にしてしまうと、重要だったはずの但し書き（注意点）が消えてしまいがちです。
ステップ 3: AIとエージェントを接続する
Claude、Codex、OpenClaw、その他のAIエージェントに、MCPまたはAPI経由でメモリへのアクセス権を与えます。Claude CodeはMCPサーバーをサポートしているため、これはコードの書き換えではなく、設定の追加だけで済みます。MCPクライアントを持たないリサーチツール（Perplexityなど）については、API経由で必要な情報を取得してプロンプトやワークフローに注入することで、双方向のやり取りが可能になります。
実務における変化
最初の変化は、「認証について何を決めたっけ？」という疑問に対し、コードを書いているそのツール内で、ソースが添付された回答が得られるようになることです。わざわざ別の製品を開いてスレッドのリンクを読みに行く必要はありません。
2つ目の変化は、却下された選択肢が却下されたまま維持されることです。リサーチから構築への引き継ぎ後に最もよくある失敗は、あなたが1週間かけて除外したライブラリを、エージェントが自信満々に提案してくることです。なぜなら、その除外の経緯はPerplexityのスレッドにあり、コードはここにあるからです。決定とその理由がストアにあれば、そのようなことは起こらなくなります。
3つ目は、多くの人が予想していない方向性です。これは逆方向にも機能します。実装に関する決定が同じレイヤーにあれば、次のリサーチプロセスは、あなたが記憶している内容からではなく、コードベースが実際に何を行っているかという事実から開始できます。
そして実用面では、次のツールの切り替えにも耐えられます。Cursorに移行することになっても、あるいはチャット製品に戻ることになっても、知識は1つの場所にあり、ツールは単なるクライアントになります。
移行のベストプラクティス
インポートする前に凝縮する（後回しにしない）
すべてを移行してエージェントに整理させたくなるのが人情です。しかし、エージェントはそれをうまく処理できません。エクスポートされたデータにはどれが最終決定かを示すマークがないため、古い回答も最終的な回答と同じ重みで扱ってしまいます。40個の対話記録よりも、よく書かれた10個の結論ドキュメントの方がはるかに優れています。また、文章にまとめることで、実際には支持できない結論がどれであるかに気づくことができます。
引用を残す
リサーチをやり直すよりも移行する方が優れている理由は、ソース情報が引き継がれるからです。整理整頓のためにエクスポートから引用ブロックを削除してしまうと、主張だけが残り、証拠が失われます。その結果、誰かに指摘されたときに、また検索ボックスに戻る羽目になります。Markdownエクスポートにはソースリストが含まれています。そのまま残しておいてください。
すべてに日付を入れ、何が古いかを明記する
変化の激しいAPIに関するリサーチは、ある一時点のスナップショットにすぎません。ファイルに日付を入れ、何かが変更されたと知ったときは、新しいドキュメントを横に追加するのではなく、既存のファイルを編集してください。日付のない、矛盾する2つのドキュメントが存在することは、特定の日付時点で正しいと明記された1つのドキュメントが存在することよりも悪質です。
指示と知識は別の場所に保管する
CLAUDE.mdはルールとポインタのためのものであり、毎セッション読み込まれるため、短く保つ必要があります。リサーチは知識であり、長く、時折関連するものであり、無条件に読み込むにはコストがかかります。これらを混ぜてしまうと、リクエストごとにコストがかかる肥大化したファイルになり、それでもすべてを収めることはできなくなります。
結論
Perplexityはスレッドを1つずつPDF、Markdown、またはDOCXにエクスポートする仕様であり、公式なSpaceの一括エクスポート機能はありません。また、Claude Code側にもインポーターはありません。そのため、確実なアプローチは手動かつシンプルなものです。Spaceを整理して検索プロセスではなく結論を抽出し、それらを引用付きのMarkdownとしてエクスポートし、各クラスターを決定事項から始まる日付入りのドキュメントに凝縮し、インラインで貼り付けるのではなくCLAUDE.mdからそのフォルダを参照させます。
慎重に検討すべき選択は、その知識をその後にどこに置くかです。リポジトリ内に置けば、このツールのこのプロジェクトに役立ちます。双方が読み取れるメモリレイヤーに置けば、次のプロジェクトや次のツールにも役立ちます。これは思った以上に重要なことです。なぜなら、リサーチには1週間かかったかもしれませんが、ツールの選択はリサーチ内容が陳腐化する前に変わる可能性があるからです。