MemoryLake
すべての記事に戻る
Tutorial2026年8月14日·13 分で読了

コンテキストを失わずにPerplexity Spaces(現Projects)をCodexに移行する方法(2026年版)

このガイドが最後に執筆されて以来、2つの大きな変化がありました。まず、PerplexityはSpacesをProjectsに改称しました。ヘルプセンターの記事は現在「Projectとは何ですか?」から始まり、最終更新日は2026年7月30日となっています。そして、PerplexityはBrainをリリースしました。ドキュメントによると、これは「プロジェクト、人物、ファイルをモデル化する自己改善型のメモリシステム」です。一方で、Codexもバックグラウンドで生成され、ローカルマシンに保存される独自のメモリ(memories)を持っています。

これが、今回の移行における本当の問題を引き起こします。そしてそれは、人々が予想しているような問題ではありません。現在、双方にメモリが存在しますが、どちらのメモリもポータブル(移植可能)ではありません。PerplexityのBrainは、UI上で閲覧、読み取り、修正ができるグラフです。Perplexityのドキュメントにはその表示と編集について記載されていますが、エクスポートについては記載されていません。Codexのメモリは `~/.codex/memories/` に保存され、ドキュメントによると、これらはローカルに存在し、ChatGPTのWeb版のメモリとは別個のものであり、手動編集を主要なコントロール手段として依存すべきではないとされています。そのため、これら2つの派生レイヤー間で直接移動できるファイルは、どちらの方向にも存在しません。

移行できるのは、永続的なインプット(ファイル、指示、意思決定そのもの)です。本記事では、実際に何が移行でき、何を再構築する必要があるのか、および誰も言及しない重大な影響(Projectは共有ワークスペースであるのに対し、Codexのメモリはそうではないため、不注意な移行を行うと、チームの知識が静かに一人の個人のプライベートなメモに変換されてしまうこと)について詳しく解説します。

実際に移行できるもの

Projectが保持するものに関するPerplexity自身の説明(「検索会話、Computerタスク、ファイル、カスタム指示、接続されたツール、および作業中にPerplexityが構築するコンテキスト」)を基に、Projectをレイヤーごとに分解してみましょう。

ファイル:移行可能であり、最も簡単な部分です。 Perplexityは、個別の永続的なファイルアップロード、フォルダ、接続されたファイルソースからのインポート、さらにComputerがユーザーに代わって作成・管理するファイルをドキュメント化しています。本物のドキュメントであるものはすべて、本物のドキュメントとして取り出せます。Codex側では、これらはリポジトリ内、またはCodexが参照する任意のディレクトリ内のファイルになります。違いは、Projectのファイルがワークスペースに紐づいているのに対し、Codexはディスク上のファイルを読み取る点です。

カスタム指示:移行可能ですが、サイズ制限に注意が必要です。 Perplexityでは、「このProject内でComputerがどのように動作するかを指示する」ための「最大8,000文字」のProject指示と、設定内の「プロジェクトで実行されるすべてのクエリに使用される」コンテキスト指示を設定できます。これらを移行する自然な移行先は AGENTS.md です。Codexのドキュメントでも、メモリに頼るのではなく、そこに記述することを推奨しています。「必要なチームのガイドラインは AGENTS.md またはチェックインされたドキュメントに保持してください。メモリは役立つ想起レイヤーとして扱い、常に適用されるべきルールの唯一の情報源とはしないでください。」しかし、8,000文字はかなりの量です。その長さのほとんどは、通常、厳格なルールと背景説明の混在であり、常に読み込まれるファイルに含めるべきなのは厳格なルールのみです。

優先されるWebリンクとドメイン:移行先はありません。 Projectの設定では、「優先するWebリンクとドメインを追加および管理」できます。これはリサーチツールの検索設定であり、Codexには同等の設定項目はありません。もしそれらのドメインに実質的な意味がある場合(例:「このベンダーのドキュメントが公式である」「あのStack Overflowの回答は古い」など)は、その仕組みを再現しようとするのではなく、その理由をメモとして書き残してください。

デフォルトモードとオーケストレーターモデル:移行先はありませんが、失うものもありません。 Projectでは、デフォルトモード(SearchまたはComputer)と、デフォルトのComputerオーケストレーターモデルを設定できます。これらはPerplexity側の実行設定です。移行するものはありません。

Brain:移行できません。 これが最も重要なレイヤーであり、移行パスが存在しないレイヤーです。Perplexityは、Brainが蓄積するもの(セッション、接続されたツール、ファイルやアーティファクト、ユーザーによる修正から学習し、その結果を「コンセプト、エンティティ、ワークストリーム(閲覧可能なウィキおよびあなたの世界のグラフ)」に整理し、各エントリが「ソースにリンクしているため、確認や修正が可能」であること)をドキュメント化しています。実行を重ねることで、何がまだ正しいかを強化し、何が変わったかを更新し、何が古くなったかをマークします。これは単なるドキュメントの山をはるかに超えるものです。構造化され、ソースにリンクされ、自己維持されます。そして、ドキュメントに記載されているそのインターフェースは、「設定」→「メモリ」でのエントリの表示、編集、削除のみです。Perplexityのドキュメントには、エクスポートに関する記載はありません。

Brainを乗り越えられない壁として扱う前に、公平を期すために2点補足します。まず、これは制限されています。ドキュメントによると、「Brainは、Computerを使用しているMaxおよびEnterprise Maxサブスクライバー向けにリサーチプレビューとして展開中」であるため、これを読んでいるかなりの人はそもそもこれを持っておらず、この問題全体をスキップできます。また、オプトアウトも可能で、「設定」→「メモリ設定」→「Brain」の下に専用のトグルがあり、Enterprise管理者向けの組織レベルのコントロールも用意されています。ワークスペースでBrainがオフになっている場合、Projectの知識はすでにファイルと指示だけになっているため、この移行作業は2時間で終わります。

Codexのメモリ:存在しますが、何も受け入れません。 移行先において、Codexは独自のメモリストアを維持しています。ドキュメントによると、これは ~/.codex/memories/ 以下のファイルであり、「以前のチャットからの要約、永続的なエントリ、最近のインプット、および裏付けとなる証拠」が含まれ、チャットがアイドル状態になった後にバックグラウンドで生成されます。これは config.toml 内の [features] memories = true で有効化されます。ドキュメントに記載されている3つの特性が、この移行のあり方を決定づけます。これらはローカルかつマシンごとです。ChatGPT Web版のメモリとは別個のものです(「ChatGPT WebはChatGPTのメモリを使用しますが、ローカルのCodexクライアントは別のローカルメモリストアを使用します」)。そして、生成はベストエフォートです。レート制限の残り割合が設定されたしきい値を下回るとメモリパスがスキップされることがあり、「チャット終了直後にメモリが更新されない場合があります」。このレイヤーに直接書き込んで初期データを流し込むことはできず、ドキュメントでは手動編集をコントロール手段としないようアドバイスしています。

どちらのドキュメントにも書かれていない影響。 PerplexityのProjectは、設計上コラボレーションを前提としています。「所有者(Owner)」「編集可能(Can edit)」「閲覧可能(Can view)」のロール、制限付きから組織全体に及ぶアクセス範囲、Enterprise以外のProjectでは最大5人、Enterprise所有のProjectでは最大9,999人の共同作業者をサポートしています。一方、Codexのメモリはマシンごと、個人ごとです。5人のProjectを1人のエンジニアのCodex環境に移行すると、知識のフォーマットが変わるだけでなく、所有者が変わってしまいます。他の全員がアクセス権を失い、誰にも通知は届きません。

手動移行の手順

ステップ 1:まず永続的なインプットを移動する

派生したデータに手を付ける前に、まずこの部分を行ってください。機械的な作業であり、これによって難しい部分を減らすことができます。

ファイルをエクスポートします。Projectの「Files」以下にあるすべてのもの、およびComputerが生成した成果物のうち、半年後にも必要になると思われるものを含めます。それらをCodexが実際に認識できる場所に配置します。コードベースに属するものであればリポジトリ内に、参照資料であればチェックインされた docs/ ディレクトリ内に配置します。Codexが参照していないフォルダにファイルを置いたままにしておくことは、「移行した」はずなのに何も引き継がれなかったと人々が首をかしげる最も一般的な原因です。

指示を2つに分割します。Projectの指示と設定レベルのコンテキストを取得し、各行を「常に保持すべきもの」と「有用な背景情報」に分類します。最初のグループは、必要なチームガイドラインをチェックインされたドキュメントに置くというCodex自身のガイダンスに従い、AGENTS.md になります。2番目のグループは、読み込む指示ではなく、参照するドキュメントになります。8,000文字すべてを AGENTS.md に貼り付けるのは避けてください。常に読み込まれるファイルが長すぎると、作業自体のコンテキストと競合し、重要なルールが薄れてしまいます。

検索設定を文章として書き留めます。優先ドメインのリストは、どの情報源を信頼するかという判断を凝縮したものです。Codexはそのリストをそのまま取り込むことはできませんが、「XにあるベンダーのドキュメントがAPIの公式情報です。Yにあるものはすべてバージョン3より前のものであり、誤解を招く可能性があります」といった文章は読み取ることができます。この文章は、設定項目そのものよりもはるかにポータブルです。

コラボレーションの境界を明示的に記録します。Projectを閉じる前に、誰がアクセス権を持ち、誰が貢献していたかを記録する短いメモを書いてください。ロールのあるワークスペースから、ロールのないローカルストアに移行しようとしています。他に誰がこれに依存していたかを知ることで、チームのリソースを静かに削除してしまうことを防げます。

ステップ 2:Brainが導き出したものを再構築し、所有者を決定する

ここからはエクスポート手段がない部分です。幸いなことに、Brainのインターフェースは、まさにあなたが必要とする読み取り作業のために構築されています。「メモリ」を開き、「コンセプト」「エンティティ」「ワークストリーム」をブラウズし、各エントリの背後にあるソースをクリックして確認します。何が学習されたかを推測する必要はありません。ソース情報とともに表示されます。

1つのフィルターを使って作業を進めてください。「このツールが消えても、これは依然として真実か?」 プロジェクト、制約、人物、オープンループ、意思決定を説明するエントリは保持します。Computerがタスクをどのように処理したかを説明するエントリは、あなたの世界ではなくツールの実行に関するものであるため、スキップします。Perplexity自身もこの境界線を引いています。ドキュメントでは、「あなたの好み、興味、共有した事柄を保存する」Memoryと、「プロジェクト、人物、ドキュメント、意思決定、オープンループを接続されたグラフに整理する」Brainを区別しています。あなたが探し出そうとしているのは、意思決定とオープンループです。

次にそれらを配置します。ここで所有権の決定が必要になります。3つの選択肢がありますが、最悪なのは、意図せず3番目の選択肢に流れ着いてしまうことです。

チェックインされたドキュメントに置く。 書くのには時間がかかりますが、永続します。チームはアクセスを維持でき、知識はdiffでレビュー可能になり、リポジトリ内にあるためCodexもそれを読み取ります。これは、Codexのドキュメントが「常に適用されるべきもの」に対して推奨している方法です。

共有メモリレイヤーに置く。 文章ドキュメントよりも維持が容易で、全員がアクセスでき、複数のツールから読み取ることができます。詳細は以下で説明します。

Codex自身のメモリに蓄積させる。 これはデフォルトで発生し、補足としては問題ありません。しかし、自分が何を選択したかを理解してください。それは1台のマシンにローカルであり、ChatGPT Web版のメモリとは別個で、ベストエフォートのスケジュールで生成され、手動編集を想定していないストアです。チームの蓄積された知識の唯一の保管場所としては、バックアップも共有もない単一障害点(SPOF)になってしまいます。Codexのドキュメントは、これがその用途には適していないことを異例なほど率直に述べており、しばらく触れていない作業においてCodexがプロジェクトのコンテキストを忘れるという形で、そのギャップはすぐに表面化します。

何もしないことは4番目の選択肢であり、本当のリスクです。Brainは古いエントリをマークし、自身を最新の状態に保ちますが、うろ覚えの結論が詰まったフォルダはそうではありません。不完全な移行を行うと、記録されたように見えて実際には記録されていない知識が残ることになります。

より良い方法:どちらのツールでも使える単一のメモリレイヤー

具体的な話から一歩引いて見れば、パターンは明らかです。2つの優れたツール、2つの有能なメモリシステム、およびゼロの相互運用性。しかも、問題となっている知識は、実際にはどちらのツールに関するものでもありませんでした。それはあなたのプロジェクトに関するものです。ツールが変わるたびに、知識は手動で再構築されます。なぜなら、その知識を発見するのをたまたま助けてくれたツールの中に保存されていたからです。

MemoryLakeは、その両方の外部に位置するメモリレイヤーです。プロジェクトの永続的な知識を1か所にまとめ、現在使用しているどのアシスタントからでも読み取ることができます。Perplexityでリサーチし、Codexで構築し、双方がプライベートでエクスポート不可能なコピーを個別に維持する代わりに、同じメモリを読み取ります。セットアップは3つのステップです。

ステップ 1:APIキーを作成する

MemoryLakeにサインインし、APIキーを作成します。接続するすべてのツールに対して1つの認証情報を使用します。これが、次の移行を乗り切るための鍵となります。

Perplexity SpacesからCodexへの移行のためにMemoryLake APIキーを作成する
Perplexity SpacesからCodexへの移行のためにMemoryLake APIキーを作成する

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

上記のステップ2で抽出したもの(意思決定、制約、オープンループ、その背後にある理由)に加えて、プロジェクトを説明する参照ファイルをアップロードします。検索時にテキストの壁ではなく実用的な結果が返されるよう、エントリは短く事実に基づいたものにし、1つのエントリにつき1つのアイデアに留めてください。あるアプローチを なぜ 却下したかに関するエントリは、何を選択したかに関するエントリの2倍の価値があります。なぜなら、却下されたアプローチは、新しいアシスタントが再び提案してくる可能性が最も高い部分だからです。

Perplexity Projectの意思決定と制約をMemoryLakeにアップロードする
Perplexity Projectの意思決定と制約をMemoryLakeにアップロードする

ステップ 3:AIとエージェントを接続する

ツールを接続します。MemoryLakeはMCPおよびAPI経由でアクセスできるため、MCPネイティブのエージェント(Codex、Claude Code、OpenClawなど)はMCPサーバーを指定することで接続し、それ以外はAPIを介して同じメモリを読み取ります。Codexはローカルメモリにその得意分野(このマシンでの最近の作業の想起)を任せ、永続的な知識はチームメイトや他のツールもアクセスできる場所に保管されます。

ローカルメモリを維持しながらMCP経由でCodexをMemoryLakeに接続する
ローカルメモリを維持しながらMCP経由でCodexをMemoryLakeに接続する

正直な限界:MemoryLakeはBrainをインポートしません。Brainにはドキュメント化されたエクスポート機能がないためです。結論を一度手動で再入力する必要があり、それが実際のコストとなります。また、MemoryLakeはリサーチツールではありません。Perplexityの機能を代替するものではなく、Perplexityが発見を助けてくれた後に、あなたが結論づけた内容を保持するものです。

実務における変化

移行が「再構築」ではなくなります。 この移行でコストがかかるのは、ファイルや指示ではありません。それらは1時間で終わります。コストがかかるのは、メモリグラフを読み取り、その結論を再入力することです。ツールに依存しないレイヤーに対してこれを行うことで、次の移行コストもわずか1時間になります。

チームの知識がチームの知識であり続けます。 これが目立たないながらも大きな勝利です。ProjectはEnterpriseで最大9,999人の共同作業者をサポートしますが、Codexのメモリは1台のマシンしかサポートしません。代わりに共有レイヤーに配置されたものはすべて、そもそもProjectを価値あるものにしていた特性を維持します。

リサーチと構築が別々のメモリではなくなります。 多くの人が実際に陥っているパターンは、あるツールでリサーチし、別のツールで実装し、同じコンテキストを2回説明することです。双方が読み取れる単一のレイヤーがあれば、2回目の説明は不要になります。これは、AIへのコンテキストの再説明をやめる方法で取り上げられているのと同じ問題です。

ベンダーの変更が大ごとではなくなります。 SpacesはProjectsになりました。Brainはリサーチプレビューとして登場しました。Codexのメモリは設定可能であり、有効にしない限りオフです。知識がツールの外部にあれば、これらはすべて単なるドキュメントの更新に過ぎませんが、ツール内部にあれば大慌てで対応することになります。

Perplexity Projectから移行するためのベストプラクティス

解約する前にBrainを読み取ってください。 グラフへのアクセスは、プランへのアクセスとともに終了します。両方がまだ利用可能なうちに読み取りを行い、同じタイミングでProjectのファイルも確認してください。Space内で見つからないと感じられたコンテンツは、通常はまだそこに存在しており、単に検索されていなかっただけです。

ソースリンクを活用してください。 すべてのBrainエントリは、その背後にあるセッション、ファイル、またはソースにリンクしています。エントリが重要そうに見えるものの曖昧な場合は、リンク先を確認してください。通常、ソースには保持する価値のある具体的なバージョンが含まれています。

必要なルールはチェックインされたファイルに保持してください。 Codexのドキュメントに直接記載されている通りであり、どのメモリレイヤーを採用する場合でも適用されます。常に適用されるべきルールは、想起レイヤーではなく、AGENTS.md またはドキュメントに属します。

Codexのメモリが即座に表示されると期待しないでください。 生成はチャットがアイドル状態になった後にバックグラウンドで行われ、レート制限の負荷がかかっている場合はスキップされることがあり、ドキュメントにはメモリが「チャット終了直後に更新されない場合がある」と記されています。セッション直後に存在しないのは正常な動作であり、バグではありません。

依存する前にマシンの境界を確認してください。 Codexのメモリはローカルかつマシンごとであり、IDE拡張機能は接続されたホストのストアを使用します。2台のコンピュータで作業する場合は、2つの別個のメモリが存在すると想定してください。

共同作業者に伝えてください。 Projectに共同作業者がいた場合、移行によって彼らが使用していたナレッジベースへのアクセス権が失われます。これは、黙って進めるべき副作用ではなく、事前に相談して決定すべき事項です。

結論

かつてのこの移行作業は、「Spacesのコンテンツをエクスポートしてどこかに貼り付ける」というものでした。しかし、移行元と移行先の双方が、互いに引き渡すことのない派生メモリを維持するようになったため、もはやそれだけでは終わりません。ファイルと指示は1時間で移動できます。Brainの結論は、あなたがそれを読み取って再入力するスピードでしか移動できず、Codex의メモリには初期データを流し込むことすらできません。

ですから、読み取り作業は一度だけ行い、その出力をどちらのツール内部でもない場所(チェックインされたドキュメント、共有メモリレイヤー、理想的にはルールが常に適用されるべきかどうかに応じてその両方に分割して)に配置してください。そうすれば、次の改称、次のリサーチプレビュー、次の新しいツールが登場したとき、それらはスケジュールを組んで取り組むプロジェクトではなく、単にニュースとして読むだけの出来事になります。もし移行先が別のエージェントである場合は、Perplexity SpacesからClaude Codeへの移行でそのルートをカバーしており、ChatGPTのメモリからCodexへの移行では、同じ移行先に対するもう一つの一般的な移行元についてカバーしています。

よくある質問

Perplexity SpacesとProjectsは同じものですか?

はい、Perplexityが改称しました。Spacesに関するヘルプセンターの記事は、現在Projects(「進行中の取り組みに関するすべてを1つのハブにまとめる、Perplexity内の永続的で共有可能なワークスペース」)について説明しており、最終更新日は2026年7月30日となっています。また、Projectsには、Brainを活用したメモリ設定やComputerタスクのサポートなど、Spacesにはなかった機能も含まれています。

Brainが学習した内容をエクスポートすることはできますか?

Perplexityのドキュメントには、「設定」→「メモリ」において、コンセプト、エンティティ、ワークストリームに整理されたBrainのエントリを表示、編集、削除する方法が記載されており、各エントリはソースにリンクされています。エクスポートパスについてはドキュメント化されていません。実質的には、グラフを読み取り、保持したい結論を再記録することを意味します。ソースリンクがあるため、思ったよりも早く作業できます。

Codexには、Projectをインポートできるメモリがありますか?

Codexにはメモリ(memories)がありますが、インポート機能はありません。これらはチャットからバックグラウンドで生成され、ローカルの ~/.codex/memories/ に保存されます。ドキュメントでは、手動編集を主要なコントロール手段として依存しないようアドバイスしています。意図的にCodexに知識を与えるには、AGENTS.md またはチェックインされたドキュメントに配置してください。これは、Codex自身のドキュメントが「常に適用されるべきもの」に対して推奨している方法です。

移行後もチームメイトはアクセスできますか?

Codex側にはアクセスできなくなります。PerplexityのProjectにはロールとアクセス範囲があり、Enterprise以外のプランでは最大5人、Enterprise所有のProjectでは最大9,999人の共同作業者をサポートしています。一方、Codexのメモリはローカルかつマシンごとです。Projectが共有されていた場合は、チェックインされたドキュメントや共有メモリレイヤーなど、共有可能な移行先を計画してください。そうしないと、チームのリソースが1人の個人のローカルファイルに変換されてしまいます。

Brainを持っていません。この移行はより簡単になりますか?

かなり簡単になります。Brainは、Computerを使用しているMaxおよびEnterprise Maxサブスクライバー向けにリサーチプレビューとして展開中であるとドキュメントに記載されており、専用のトグルがあります。これがなければ、Projectはファイル、指示、会話だけで構成されているため、このガイドの最初のステップが作業の大部分を占めることになります。

両方のツールを使い続けるべきですか?

通常はそれが正しい選択です。これらは異なる役割を担っており、Perplexityのリサーチにおける強みは、Codexのコーディングエージェントとしての強みとは重複しません。持続不可能なのは、同じプロジェクトの知識を両方のツールで、どちらもエクスポートできない2つのプライベートなフォーマットで維持することです。双方が読み取れる1つの共有レイヤーを持つことで、両方のツールを低コストで運用できるようになります。