実際に移行できるもの
まずは、Manus 自身の言葉を借りて、Manus が提供するものから見ていきましょう。
読み取り可能な形式は「プレーンテキストのエクスポート」です。ヘルプセンターはその制限について、異例なほど率直に説明しています。「チームメンバーはプレーンテキストのエクスポートを介してタスクデータの読み取り可能なコピーをエクスポートできますが、これはバックアップとは異なり、タスクデータのインポートや復元には使用できません。」
復元可能な形式は「バックアップパッケージ」です。タスクデータバックアップには「タスク、生成されたファイル（ウェブサイトやスライドなど）、および設定データが含まれます」。また、これは作成した瞬間の状態で固定されます。「バックアップは生成された時点のデータのスナップショットのみをキャプチャし、新しいタスクを自動的に同期することはありません。」そして、これは Manus 専用の成果物です。復元パスはそれを Manus に戻すだけであり、他のツールに移行することはできません。
したがって、率直なインベントリ（目録）は以下のようになります。
きれいに移行できるもの。 あなたが作成したファイル（ドキュメント、スライド、サイト、データセットなど）。読み取り、コピー、貼り付けができるすべてのもの。ご自身で管理している場所に保管していた、自作の指示書。
書き直すことで移行できるもの。 ナレッジベースのエントリ。数ヶ月にわたって Manus に与えてきた恒常的な設定。長いタスクスレッドから Manus が吸収したプロジェクトの背景。これらはすべて読み取り可能な形式で存在しますが、インポート可能な形式では存在しません。
まったく移行できないもの。 構造化された状態としてのタスク履歴。ドキュメントに手動で再有効化する必要があると記載されている、承認済みコネクタの設定。Manus が指示されたのではなく、推測したすべての内容。
Codex 側には、完全に無料で得られるメリットが1つと、それをあてにする前に知っておくべきことが1つあります。
無料のメリットは AGENTS.md です。Codex は作業を開始する前にこれを読み込みます。これはプレーンな Markdown なので、テキストエディタで書けるものであれば何でも Codex が読み取ります。これが、書き直す必要のあるすべてのものの着陸地点となります。
知っておくべきこと：Codex にはインポーターがありますが、Manus はそのソースに含まれていません。ドキュメントによると、「デスクトップアプリは Claude Code、Claude Cowork、または Cursor からインポートできます。Codex CLI は Claude Code または Cursor からインポートできます。」Manus から移行する場合、インポーターを使って手順をスキップすることはできません。移行は設計上、手動で行う必要があります。だからこそ、急ぐのではなく、意図を持って慎重に行う価値があるのです。
手動移行の手順
手順は2つあり、その順序が重要です。まだ可能なうちに Manus から資料を取り出し、それを Codex が実際に指示を組み立てる方法に合わせて整形します。
ステップ 1: 読み取り可能なコピーを取り出し、バックアップではなく「ソース素材」として扱う
タスクデータをプレーンテキストとしてエクスポートし、必要な生成ファイルをダウンロードします。そして、手に入れたものを「ここにある文のうち、どれが 指示（instructions） で、どれが 成果物（artifacts） か？」という具体的な問いを持って読み進めます。
成果物は出力結果です。これらはチームがファイルを保管している場所に保管してください。これらはコンテキストではありません。
指示とは、何十ものタスクにわたるあなた自身のプロンプトの中に埋もれている文のことです。繰り返し行った修正、何度も言い直したルール、「いいえ、私たちはいつもこのように行います」といったこだわりなどです。これらこそが移行の対象です。これらを抽出するツールは存在しないため、自分で読み解く必要があります。
2つの注意点があります。第1に、Manus のナレッジベースにもエントリを保存している場合は、それらを個別にエクスポートし、エクスポートデータに含まれていると思い込まずに照合してください。knowledge base limit（ナレッジベースの制限）により、多くのチームが時間の経過とともにエントリを整理しており、何が入っているか覚えていないことがよくあります。第2に、アカウントの削除を計画している場合は、操作を行う前に復元の仕組みを理解してください。現在のサービス変更における復元には no deadline but exactly one attempt（期限はありませんが、試行は1回限り）というルールがあり、プレーンテキストのエクスポートはバックアップパッケージの代わりにはなりません。まだ読んでいない場合は、backing up Manus data before deletion（削除前に Manus データをバックアップする）をお読みください。
ステップ 2: Codex が実際に読み取るレイヤーに、Codex が読み取る順序で書き込む
Codex はファイルから指示を組み立てますが、その組み立てルールは非常に具体的であるため、不適切な場所に置かれたファイルは単に使用されません。
グローバルレベルでは、「Codex のホームディレクトリ（CODEX_HOME を設定していない限り、デフォルトは ~/.codex）において、Codex は AGENTS.override.md が存在すればそれを読み込みます。存在しない場合は AGENTS.md を読み込みます。Codex はこのレベルで最初の空でないファイルのみを使用します。」つまり、ディレクトリではなく、1つのファイルのみです。
プロジェクトレベルでは、「プロジェクトのルート（通常は Git のルート）から開始して、Codex は現在の作業ディレクトリまで下っていきます。パスに沿った各ディレクトリで、AGENTS.override.md、次に AGENTS.md、そして project_doc_fallback_filenames にあるフォールバック名を確認します。Codex は1つのディレクトリにつき最大1つのファイルを含めます。」
その後、マージされます。「Codex はルートから順にファイルを連結し、空行で結合します。現在のディレクトリに近いファイルほど、結合されたプロンプトの後半に表示されるため、以前のガイダンスを上書きします。」
移行における実用的な影響が2つあります。1つは、Manus 時代の一般的なルールはルートに置き、具体的なルールはより深い階層に置くことです。深い階層の方が優先されるためです。もう1つは、上限に注意することです。「Codex は空のファイルをスキップし、結合されたサイズが project_doc_max_bytes（デフォルトは 32 KiB）で定義された制限に達すると、ファイルの追加を停止します。」1年分の蓄積された Manus のコンテキストを1つのルート AGENTS.md に流し込むと、後続のファイルが気づかないうちに上限を超えて切り捨てられる可能性があります。ドキュメント自体も、「上限に達した場合は、制限を引き上げるか、ネストされたディレクトリに指示を分割する」ことを推奨しています。
最後に、Codex 独自の「メモリー（memories）」をどう扱うかを決めます。これらは存在し、オプトイン（選択制）となっています。「ローカルの Codex メモリーはデフォルトでオフになっています。」これを有効にすると、~/.codex/memories/ の下に「要約、永続的なエントリ、最近の入力、および以前のチャットからの裏付けとなる証拠を含む」ファイルが作成されます。これは便利ですが、ドキュメントにはそれが「何ではないか」が明確に記載されています。「これらのファイルは生成された状態として扱ってください。トラブルシューティング時や Codex ホームディレクトリを共有する前にこれらを検査することはできますが、手動で編集することを主要なコントロール手段として依存しないでください。」アンド、必要なルールがどこに属すべきかについても明記されています。「必要なチームガイダンスは AGENTS.md またはチェックインされたドキュメントに保管してください。メモリーは便利な想起レイヤーとして扱い、常に適用されるべきルールの唯一のソースとはしないでください。」
つまり、Codex のメモリーは、移行された Manus のコンテキストの保存先ではありません。保存先は AGENTS.md です。
より良い方法：どちらのツールにも依存しないレイヤーにコンテキストを保持する
ステップ1と2を行えば、動作する Codex のセットアップが完了します。しかし、同時に、すでに一度経験した構造的な問題が残ることになります。今書き直したすべての内容が、特定のツールのファイル規則に従って特定のレポジトリに保存され、次の移行の際にも再び手動での書き直しが必要になるという問題です。
これこそが、Manus のエクスポートから得られる本当の教訓です。移行が苦痛である理由は、Manus が不親切だからではありません。ドキュメントは丁寧であり、エクスポート機能も本物です。問題は、「ツールが学習したこと」にポータブルな形式がなかったため、読み取ることはできても、移動させることができなかった点にあります。両方のツールの外部に存在するメモリーレイヤーが、それを可能にします。MemoryLake は3つのステップでセットアップできます。
ステップ 1: API キーを作成する
サインインし、ダッシュボードから API キーを生成します。これは、エージェントがメモリーを読み書きするために使用する認証情報です。Manus にも Codex にも紐づいていません。ここが重要なポイントです。このストレージは、現在使用しているツールよりも長生きします。
ステップ 2: 最初のメモリーをアップロードする
ここに、手動移行のステップ1で抽出した資料を保存します。プロジェクトの背景、恒常的なルール、決定事項とその背後にある理由、チームが使用する定義や名称など、プレーンテキストのエクスポートから抽出した、成果物ではなく「指示」にあたるすべての内容です。
これらすべてをルートの AGENTS.md に貼り付けるのではなく、この方法で行ってください。AGENTS.md は常に適用されるべきルールのために残しておき、蓄積され成長し続けるコンテキストの本体はここに置きます。そうすれば、32 KiB の制限を争う必要はありません。
ステップ 3: AI とエージェントを接続する
Codex をこのストレージに向ければ、次にどのツールを使用するようになっても、同じ知識を利用できます。移行期間中にチームの一部が Manus に残り、一部が Codex に移行する場合（これは一般的で合理的な構成です）でも、両者が同じレイヤーを読み取るため、数ヶ月にわたって認識がズレていくのを防ぐことができます。
実務における変化
最初の違いは2週目に現れます。完全に手動の移行では、2週目は書き留めるのを忘れていたルールに気づく時期です。なぜなら、Codex が古いセットアップでは決して行わなかった動作をするからです。外部レイヤーを使用していれば、2週目は忘れていた3つのルールを追加するだけで、全員にそれが適用されます。各自が自分のローカルファイルを修正する必要はありません。
2つ目の違いは、サイズの上限です。AGENTS.md ファイルは優れていますが、容量は有限です。常に適用されるべき指示はそこに置くべきです。しかし、クライアントの詳細情報、過去の決定事項、用語集、奇妙な回避策が存在する理由といったロングテールな情報は、制限なく増え続けるため、すべてのプロンプトに連結されるファイルに含めるべきではありません。
3つ目は、次の移行です。Codex はチームが使用する最後のツールではありません。今日の移行にコストがかかるのは、コンテキストが誰も移動できない形式でロックされていたからです。プレーンテキストのエクスポートからではなく、ストレージから再度移行を行うのであれば、それは一大プロジェクトではなく、半日の作業で済みます。
Manus から Codex への移行におけるベストプラクティス
- 他の変更を行う前にエクスポートする。 最初にプレーンテキストのエクスポート、次に成果物、最後に削除の決定を行います。エクスポートは読み取り可能ですが復元はできないため、これは作業用のコピーであり、セーフティネットではありません。
- エクスポートデータはコンテンツではなく「指示」を読み取る。 価値があるのは、Manus が生成した出力ではなく、あなたが Manus を修正した文の中にあります。
- 常に正しいルールにはルートの
AGENTS.mdを、具体的なルールにはネストされたファイルを使用する。 深い階層のファイルは後から表示され、以前のガイダンスを上書きします。 project_doc_max_bytesに注意する。 デフォルトの 32 KiB は十分な容量に見えますが、1年分のコンテキストを貼り付けるとすぐに上限に達します。意図的に制限を引き上げるか、ディレクトリ間で分割してください。- Codex のメモリーをコントロール手段として扱わない。 ベンダー自身の説明にあるように、これらは生成された状態です。必要なルールは
AGENTS.mdまたはチェックインされたドキュメントに記述してください。 - コネクタを手動で再有効化し、それぞれを検証する。 Manus のドキュメントには、承認済みコネクタは自動的には復元されないと明記されており、Codex に接続したものについても同様です。
- プロジェクト知識の正規のコピーを、両方のツールの外部に1つ保持する。 2つのレポジトリの2つのファイルに同じ段落を貼り付けていることに気づいたら、その段落は別の場所に置くべきです。仕組みについては、Turning project docs into AI memory（プロジェクトドキュメントを AI メモリーに変換する）で解説しています。
結論
Manus から Codex への移行は手動であり、今期中にツールによってこれが変わることはありません。Codex のインポーターは Claude Code、Claude Cowork、Cursor を読み込み、Manus のエクスポートは設計上、インポート可能ではなく読み取り可能であるためです。
あなたが変えられるのは、「それをもう一度行うかどうか」です。ファイルを移行し、成果物を移行し、書き直せば指示も移行できます。蓄積されたコンテキストこそがコストのかかる部分であり、そのコストを繰り返し支払うのを防ぐ唯一の方法は、その時点で流行しているツールの内部にコンテキストを保存するのをやめることです。