Manusが復元について実際に公開した内容
ここに引用されている内容はすべて、Manusヘルプセンターの「サービス変更（Service Change）」に関する記事から直接引用したものです。サードパーティによる要約や、Manusが公開していない数値は一切含まれていません。
復元期間に終了日はなく、ファイルだけが唯一の鍵
「8月25日午前8:00より、サービス変更の影響を受けるユーザーは、以前に保存したバックアップパッケージを使用して、アカウントとタスクを復元できます。」
公開済みのサイトについて、Manusは期限を設けないことが意図的であることを明言しています。公開されていたWebサイトは、削除開始から「ユーザーが能動的にデータを復元するまで（復元ポータルは8月25日午前7:59に開設）アクセスできなくなります。復元のタイミングはユーザーに委ねられているため、固定された終了日はありません。」
この柔軟性の裏返しとして、バックアップ期間は完全に終了しています。紛失したファイルについて、ドキュメントではまずクラウドドライブのごみ箱やバージョン履歴を確認するよう指示した上で、次のように述べています。「ファイルが本当に紛失または破損している場合は、データバックアップ期間内に新しいバックアップを作成してください。データバックアップ期間が終了すると、新しいバックアップは作成できません。」また、ダウンロードフォルダを整理する際についやってしまいがちな操作に対する注意書きもあります。「バックアップファイルを変更、名前変更、または移動しないでください。使用できなくなる可能性があります。」
復元は1回限り
この一文は復元に関する記事に2回登場します。これは通常、ベンダーがユーザーに見落とされることを警戒しているサインです。「復元は1回しか完了できません。」
前後の段落を読むと、これが思ったほど過酷ではない理由と、唯一の救済措置がどこにあるかが分かります。「データ復元は、複数のバックアップパッケージのアップロードに対応しています。アップロード後、コンテンツの重複を排除して統合し、最も完全なタスクデータのセットを復元します。データ復元は1回しか実行できません。復元を進める前に、バックアップパッケージが正しく、最新バージョンが含まれていることを慎重に確認することを強くお勧めします。」
つまり、ファイルが1つに制限されているわけではありません。制限されているのは「完了した」復元が1回限りということであり、復元したいものはすべてそのアップロードに含める必要があります。救済の余地は狭いながらも存在します。「パッケージの検証に失敗した試行は、完了した復元としてはカウントされないため、完全なセットで再試行できます。」アップロードが拒否された場合は、試行回数は消費されません。間違ったセットで復元が成功してしまった場合が、アウトです。
2つのパッケージ、および失敗の主な原因となる4GB分割
バックアップでは、役割の異なる最大2つのアーカイブが作成されました。「アカウントデータバックアップ（Account Data Backup）」は「10MB以下の小さなもので、メールの添付ファイルとして送信」され、これを作成できたのはType Cユーザーのみでした。これらのユーザーにとって、このファイルへの依存度は絶対的です。「アカウントデータバックアップがないと、タスクデータを復元できません。」
「タスクデータバックアップ（Task Data Backup）」は容量の大きいファイルで、Manusはその内容を「タスク、生成されたファイル（Webサイトやスライドなど）、および設定データが含まれます」とシンプルに説明しています。
そして、最も混乱を招いている制約がこれです。「1つのデータパッケージの上限は4GBです。例えば、合計8GBの場合は2つの4GBバックアップパッケージに分割されます。」復元側では、これが厳格な要件となります。「エクスポートに複数のファイルが含まれている場合は、番号のないメインパッケージと同じエクスポートの番号付きのすべてのpartパッケージを一緒にアップロードしてください。不完全なパッケージセットは復元できません。」
エクスポートが12GBだった場合、3つのファイルが存在することになり、これら3つすべてを同じ操作でアップロードする必要があります。
アカウントタイプによって適用される手順が異なる
Manusは影響を受けるアカウントを3つのタイプに分類しており、復元ルートはタイプによって異なります。存続したアカウントの場合：「Type AおよびBユーザー：アカウントは影響を受けず、通常通りManusを使用し続けることができますが、削除されたタスクデータ、Manusが生成した成果物（アーティファクト）、および連携済みのコネクタは、後でバックアップファイルを使用して自分で復元しない限り、取り戻すことはできません。」
削除されたアカウントの場合：「Type Cユーザー：アカウントは削除されたままであり、ログインすることはできません。Manusのサービスを利用するには、新しいアカウントを作成する必要があります。」彼らの手順は、まずアカウントを作成し、その後にタスクデータを復元する流れになります。
チームにはさらに3つの制約が加わります。「チームの所有者（オーナー）のみがチームデータを復元する権限を持っています。チームメンバーがチームデータの復元を開始することはできません。」誰も行わなかった場合：「チーム所有者が復元を実行しない場合、チームデータを取得することはできず、メンバーはアクセスできなくなります。」そして、自己流で進める前に二度読みすべき指示がこれです。「この目的のために新しいチームを作成しないでください。元のチームのバックアップパッケージを、新しく作成したチームに復元したり統合したりすることはできません。」個人アカウントとチームの両方を持っている人は、「2つの別々のアカウント復元操作とデータ復元操作を完了する」必要があります。
何が変わり、何が変わらないのか
復元されるものは明確に定義されています。タスク、Webサイトやスライドを含む生成されたファイル、および設定データです。公開済みのサイトは自動的に復旧します。「タスクデータバックアップを復元すると、公開されていたWebサイトは自動的にオンラインに戻ります。」サードパーティ製コネクタは半復元の状態で戻ります。「データ復元によってサードパーティ製コネクタも復元されますが、トグルを手動でオンに戻す必要があります。」
復元されないものも同様に明確に定義されており、バックアップガイドの次の一文に集約されています。「バックアップは、生成された時点のデータのスナップショットをキャプチャするだけであり、新しいタスクを自動的に同期することはありません。」パッケージはエクスポートした時点で凍結されています。最後のエクスポートから削除期間までの間に作成されたものは含まれておらず、どのような復元操作を行ってもそれらが魔法のように現れることはありません。
第3のカテゴリーが存在し、これについてはManus自身が線を引いています。バックアップを作成できなかったチームメンバーは、「プレーンテキストのエクスポートを介してタスクデータの読み取り可能なコピーをエクスポートできますが、これはバックアップとは異なり、タスクデータのインポートや復元には使用できません」と案内されていました。
これは、2つの異なる形式の説明として捉えてください。一方は人間が読めてどこでも再利用できますが、ベンダーの復元ツールは受け付けません。もう一方は復元ツールには受け入れられますが、それ以外の用途には役に立ちません。今回のイベントにおいて、第3の形式 — つまり、ツールがあなたの働き方について学習した記録を、あなたと別のシステムの両方が利用できるような形式 — は生成されませんでした。タスクアーカイブにそのようなデータは含まれていません。プレーンテキストのエクスポートにも含まれていません。パッケージに最初から入っていなかったため、そこから取り出すことはできません。これは、通常の利用においてManus loses your project history（Manusがプロジェクト履歴を忘れてしまう問題）が発生したときに現れるギャップと同じものです。
人々が誤解しがちなポイント
「期限がない＝急ぐ必要はない」 本当に重要だった期限はすでに過ぎています。バックアップファイルは、Manus自身の言葉を借りれば「データを復元する唯一の手段」であり、再生成は不可能です。また、ファイルの名前変更や移動を行うと「使用できなくなる可能性があります」。
「とりあえず復元してみて、どうなるか見てみよう」 無料（ノーカウント）なのは検証エラーの場合だけです。復元が完了してしまえば、その1回は消費されます。ドキュメントでは、進める前にパッケージが「正しく、最新バージョンが含まれていること」を確認するよう求めています。
「チームの誰かがやってくれるだろう」 チームデータを復元できるのは所有者（オーナー）だけです。所有者自身のアカウントが削除されていた場合は、まず所有者自身のアカウントを復元する必要があります。
「バックアップはアカウントのコピーである」 それはタイムスタンプ付きのスナップショットに過ぎません。
「まずは代替ツールを選ばなければ」 これまで持っていたものを復元することと、永続的な知識を次にどこに置くかを決めることは、異なる時間軸で動く2つの別々の決定です。順序を間違えると、結局どちらも中途半端に終わってしまいます。
解決策：再利用可能な半分を、単一の復元機能に依存しない場所に保管する
復元によって成果物（アーティファクト）は戻ってきます。しかし、それらの成果物を優れたものにした部分 — 何度も推敲した指示書（ブリーフ）、不採用にした情報源とその理由、チームが実際に受け入れているフォーマットなど — は、どのアーカイブ形式にもフィールドが存在しないレイヤーに存在します。そのレイヤーは、特定のベンダーのエクスポートツールに依存しない場所に置いておく価値があります。
それこそが MemoryLake の目的です。あなたが所有する「記憶（メモリー）レイヤー」であり、アシスタントやエージェントは、各ベンダーの独自のアーカイブ形式ではなく、APIを介してここから情報を読み取ります。セットアップは3つのステップで完了します。
ステップ 1: APIキーを作成する
サインインし、ワークスペースの設定からAPIキーを作成します。これはアシスタントやエージェントが使用する認証情報であり、特定のツールではなくあなた自身に紐づいているため、後でツールを切り替えても無効になりません。
ステップ 2: 最初の記憶（メモリー）をアップロードする
成果物ではなく、まずは再利用可能な「半分」から始めましょう。最終的に優れたアウトプットを生み出した実用的な指示書。信頼しないと決めた情報源。チームの命名規則やフォーマットのルール。繰り返し発生する制約（ターゲット層、トーン、成果物に絶対に含めてはならない2つの要素など）。ファイルはそのままの形で取り込まれ、MemoryLakeはマルチモーダルなファイルにも対応しているため、ルールが埋め込まれたスライド資料やスプレッドシートを直接投入できます。
ステップ 3: AIとエージェントを接続する
実際に使用しているアシスタントを接続します。それ以降、永続的な情報は、その時たまたま使っているツールの中で再構築するのではなく、1つの場所から読み取られるようになります。ツールが変更されたり、買収されたり、アーカイブからの復元を求められたりしても、そのレイヤーはツールの内部に存在しないため、一切影響を受けません。
2つの率直な限界をお伝えしておきます。MemoryLakeは、Manusのタスクを復元したり、バックアップパッケージを読み取ったり、復元ツールと対話したりすることは一切できません。そのプロセスは完全にManus側で完結するものであり、このセクションは今回の復元ではなく、「次回」に向けた対策について述べています。また、これはアーカイブの代わりにはなりません。ファイルや成果物は、依然としてバックアップに保管する必要があります。
実務において何が変わるのか
現時点では、作業の順序が変わります。まずパッケージセットを検証し、1回だけ復元を実行し、その後、再利用可能なレイヤーをどこに置くかを個別に決定します。
今後1年間で、サービス変更に伴うコストが変わってきます。今回発生したイベントは、明確な期間、2つのパッケージタイプ、公開された復元ルート、サポートチャネルが用意されており、異例なほど手厚くドキュメント化されていました。しかし、ほとんどの混乱はもっと厄介です。ツールの機能廃止、プランの変更、ワークスペースの移行、買収の完了などです。エクスポートさえしていれば、成果物レベルではこれらすべてを乗り切ることができます。しかし、失われ続けるのは「蓄積された理解」のレイヤーです。なぜなら、それらは通常エクスポートすらできないからです。アーカイブと記憶（メモリー）レイヤーがなぜ異なるオブジェクトなのかについては、what makes memory persistent（記憶を永続化させるものとは）を参照してください。
また、ツールを切り替える際の再構築の手間も変わります。永続的な情報がすでにツールの外部にある場合、代替ツールの評価は、ゼロから教え直すのではなく、すでに知っている情報をそのツールに示すだけで済みます。これは、carrying context between tools（ツールの枠を超えてコンテキストを持ち運ぶ）の背景にある議論と同じであり、Manusを使い続けるかどうかにかかわらず当てはまります。
復元を試みる前のベストプラクティス
まず、同じエクスポートからすべてのファイルを特定する。 番号のないメインパッケージと、すべての番号付きpartファイルです。不完全なセットは復元できず、一部のファイルが欠けている状態で実行すると、貴重な1回の試行が無駄になってしまいます。
名前の変更、移動、解凍は一切行わない。 ドキュメントには、ファイルを変更すると使用できなくなる可能性があると記載されています。ファイル名には触れず、1つのフォルダにコピーしてください。
タイムスタンプを自分の作業の記憶と照らし合わせる。 最後のデータエクスポートが、重要視している作業よりも前の日付である場合、その作業はパッケージに含まれておらず、復元しても戻ってきません。後で気づくよりも、事前に知っておく方が確実です。
一致するアカウントにサインインしていることを確認する。 Manusはログイン中のアカウントに対してバックアップを検証するため、不一致があると「アカウント情報不一致（Account Information Inconsistent）」エラーでプロセスが停止します。関連するエラー（「バックアップを検証できませんでした（Backup couldn't be verified）」や「[permission_denied] HTTP 403」など）の公開されている解決策は、一度サインアウトし、バックアップが属するアカウントで再度サインインして再試行することです。
チームを所有している場合は、1回ではなく2回の復元を計画する。 自身のアカウントが削除されていた場合はまず個人アカウントを復元し、その後にチームを復元します。復元先として新しいチームを作成しないでください。
復元後にコネクタを再度有効にし、確認する。 復元によってコネクタは戻りますが、トグルはオフのままになります。そのため、一見正常に見える自動化が実際には何も動作していない可能性があります。
記憶が新しいうちに、再利用可能な「半分」を書き留めておく。 この章を終える前に、20分ほど時間を取って、どのパッケージにも含まれていなかった指示書、ルール、不採用になったアプローチを記録しておきましょう。これこそが、今回のイベントから学び、再発を防ぐことができる唯一の部分です。チームの知識が複数のアシスタントに分散している場合は、auditing what each one actually remembers（各AIが実際に何を記憶しているかを監査する）から始めるのが適切です。
結論
Manusは期限を取り払いましたが、制約は残しました。準備ができればいつでも復元できますが、チャンスは1回限りです。そのため、ボタンを押す前にすべての準備を行う必要があります。完全なパッケージセットを集め、ファイル名はそのままにし、エクスポート日を確認し、正しい人物がサインインしていることを確認してください。
そして、もう一方の「半分」は別個に扱いましょう。タスクやファイルはパッケージに含まれていたため回収可能でした。しかし、それらの周囲に構築された「理解」はパッケージには含まれていませんでした。これは解決可能な問題ですが、それを紛失したツール自体の外部でしか解決できません。