> ## Documentation Index > Fetch the complete documentation index at: https://docs.replit.com/llms.txt > Use this file to discover all available pages before exploring further. # 別のワークスペースへプロジェクトを手動でコピーする > 稼働中のアプリを別のワークスペースやアカウントに手動でコピーする：コードをコピーし、新しいアプリをセットアップし、ダウンタイムを最小限に抑えてユーザーを新しいアプリに向け、元に戻す方法を把握する このガイドでは、アプリを別のワークスペースやアカウントに手動でコピーする手順を説明します。コードをコピーし、新しいアプリをセットアップし、データをコピーしてから、ユーザーを新しいアプリに向けます。 何も移動または削除されません。古いプロジェクトはそのままの場所に残り、2つのコピーは同期されません。作業が完了したら、古い方を残すか削除するかを選択できます。 組み込みのワンクリック転送を探していますか？[チームへのアプリの転送](/ja/teams/identity-and-access-management/transfer-app-to-teams)を参照してください。このガイドは、そのオプションが利用できない場合、またはアカウント間でコピーする必要がある場合に使用してください。 ## 開始前に 以下が必要です： * 古いプロジェクトと新しいワークスペースまたはアカウントの両方へのアクセス。 * 最終的な切り替えのための約1時間の集中作業時間。それより前のステップは数日にわたって行うことができます。 * アプリにカスタムWebアドレスがある場合は、そのドメインを管理している場所へのアクセス。 自動的にコピーされず、最も時間がかかる2つの要素があります：**データベース**と**Webアドレス**です。このガイドでは両方を扱います。 ワークスペース管理者が[ソースコードエクスポートの禁止](/ja/teams/enterprise-privacy-settings#ban-source-code-export)を有効にしている場合、プロジェクトをZIPとしてダウンロードすることはできません。開始前にワークスペース管理者に相談してください—管理者は手動コピーが許可されているかどうか、コードとデータベースを移動する方法を確認できます。 ## ダウンタイムを計画する 2つ目の店を開いてから最初の店を閉めることを想像してください。古い店が閉まっていて、新しい店がまだ開いていない短い時間があります。その間、誰もあなたのアプリを使用できません。 **アプリはどのくらいオフラインになりますか？** 通常15分から60分です。これは、データベースが保持するデータ量と、Webアドレスの更新速度によって異なります。 **データは失われますか？** データベースをコピーした後に誰かが古いアプリにデータを追加した場合のみです。これを防ぐために、最終コピーを作成する*前に*古いアプリをオフラインにします。このガイドはその順序で構成されています。 **元に戻せますか？** はい。古いプロジェクトは削除されません。何か問題が発生した場合は、古いアプリを再度公開すれば、以前とまったく同じように動作します。 **いつ行うべきですか？** アプリを使用する人が少ない時間を選んでください。可能であれば事前にユーザーに知らせてください。 ## ステップ1：コードを新しいプロジェクトにコピーする 方法を1つ選択してください。このステップの間、古いアプリは稼働し続けます。どちらの方法もコードを運びますが、GitHubは常にコミット履歴を運び、ZIPは`.git`フォルダを含む場合のみ履歴を運びます： | | GitHub経由 | ZIPファイル経由 | | ------------ | ------------------------------- | ------------------------------------------------------------ | | **コードファイル** | コミットしてプッシュしたファイルのみ | 未コミットの変更を含む、ディスク上のすべて | | **コミット履歴** | リモートの完全な履歴 | ZIPに`.git`フォルダが含まれる場合は完全な履歴。インポート制限を下回るために`.git`を除外した場合は履歴なし | | **依存関係フォルダ** | `.gitignore`に従う | 除外される（`node_modules`、`.venv`、`build`など）；インポート時に再インストールされる | | **要件** | 両方のReplitアカウントに接続されたGitHubアカウント | なし | | **継続的な同期** | 両方のコピーが同じリポジトリにプッシュ・プルできる | なし—1回限りのスナップショット | | **最適な用途** | 長期的にGitでバックアップしたいプロジェクト | 迅速な1回限りのコピー | ### GitHub経由 古いプロジェクトで[Gitペイン](/ja/features/workspace-tools/git-interface)を開き、GitHubリポジトリを接続してから、コミットしてプッシュします。コードを公開したくない場合は、プライベートリポジトリを使用してください。 新しいワークスペースが別のReplitアカウントに属している場合、そのGitHubアカウントにリポジトリへのアクセス権が必要です。プライベートリポジトリの場合は、そのGitHubアカウントをコラボレーターとして追加するか、共有GitHub組織を使用してください。 新しいアカウントにサインインし、[replit.com/import](https://replit.com/import)を開き、**GitHub**を選択し、GitHubアカウントを接続して、リポジトリを選択します。トラブルシューティングについては[プロバイダーからインポートする](/ja/build/import-from-providers)を参照してください。 新しいプロジェクトを開き、ファイルとコミット履歴が存在することを確認します。Replitはインポート中に依存関係をインストールし、実行コマンドを設定します。 GitHubはコミットしてプッシュしたものだけを受け取ります。`.gitignore`に一致するファイルと未コミットの変更は残ります。シークレット値やデータベースダンプをリポジトリにコミットしないでください。 ### ZIPファイル経由 古いプロジェクトで、ファイルツリーの上部にある三点メニューを選択し、**Download as zip**を選択します。 ダウンロードが成功し、ファイルが200 MB未満であれば、次のステップに進んでください。 200 MBを超えるZIPファイルは正常にダウンロードできる場合があります。ただし、[ZIPインポート](/ja/build/import-from-providers#limitations)は200 MBを超えるファイルを拒否するため、Replitはそれを使って新しいプロジェクトを作成できません。ダウンロードが失敗するか、ZIPが200 MBを超える場合は、より小さいものを作成してください： 1. 古いプロジェクトで**Shell**ツールを開きます。 2. 次のコマンドを貼り付けてEnterキーを押します。これは`project.zip`というファイルを作成し、Replitが自力で再構築できるフォルダを除外します： ```bash theme={null} zip -r project.zip . -x ".cache/*" "node_modules/*" ".venv/*" "venv/*" ".pythonlibs/*" "build/*" "target/*" ".next/*" "__pycache__/*" ``` 3. サイズを確認します。次のコマンドを貼り付けてEnterキーを押します。これはMB単位のサイズ（150 MBの場合`150M`など）を表示します： ```bash theme={null} du -h project.zip ``` 4. サイズが200 MBを超える場合は、編集履歴を除外してファイルを小さくします。両方の行を貼り付けてEnterキーを押します： ```bash theme={null} rm project.zip zip -r project.zip . -x ".cache/*" ".local/*" ".git/*" "node_modules/*" ".venv/*" "venv/*" ".pythonlibs/*" "build/*" "target/*" ".next/*" "__pycache__/*" ``` ZIPを200 MB未満に縮小する必要がある場合のみ、`.local`と`.git`を除外してください。これらの除外は、古いプロジェクトからどちらのフォルダも削除するわけではありません。ただし、`.git`を含まないZIPには、プロジェクトのコミット履歴が含まれません。履歴を保持する必要がある場合はGitHubの方法を使用してください。 5. ファイルツリーで`project.zip`を見つけ、その横の三点メニューを選択して、**Download**を選択します。 `.cache`フォルダには、キャッシュされたシークレット値を含むReplitの内部状態が保持されています。手動で作成するZIPファイルからは常にこれを除外してください。プロジェクトに他の大きな生成フォルダがある場合は、除外リストに追加してください。 新しいアカウントにサインインし、[replit.com/import](https://replit.com/import)を開き、**ZIP**を選択して、ファイルをアップロードします。 新しいプロジェクトを開き、ファイルが存在することを確認します。ZIPに`.git`フォルダが含まれている場合、コミット履歴も一緒に取り込まれています。より小さいアーカイブコマンドを使用した場合、新しいプロジェクトはコミット履歴なしで始まります。Replitはインポート中に除外された依存関係を再インストールします。 ## ステップ2：新しいアプリをセットアップする 古いアプリはまだ稼働しています。このステップでは、データの*テストコピー*を使って新しいアプリを完全に動作させ、後の最終切り替えを迅速に行えるようにします。 シークレット値（APIキー、パスワード）は古いプロジェクトから外部に出ません。両方のプロジェクトで[Secrets](/ja/core-concepts/project-editor/app-setup/secrets)ツールを開き、それぞれを手動でコピーします。デプロイメントシークレットも含めてください。 新しいプロジェクトの**Tools → Connectors**から各インテグレーションを再接続します。App Storage、コラボレーター、その他すべてについては[コピーされないものを再作成する](#re-create-what-doesnt-copy-over)を参照してください。 新しいプロジェクトを[公開](/ja/features/publishing/overview)します。独自の`replit.app`Webアドレスと、独自の空の本番データベースが作成されます。まだカスタムドメインは接続しないでください。 以下の[データベースをコピーする](#copy-the-database)に従い、新しいプロジェクトの**本番**データベースをターゲットとして使用します。これにより、テストできる実際のデータが得られます。ステップ3では、このコピーを最新のデータに置き換えます。 新しいアプリを`replit.app`アドレスで開き、ユーザーと同じように使用します。先に進む前に、不具合があれば修正してください。この時点ではまだユーザーに影響はありません。 ## ステップ3：ユーザーを新しいアプリに切り替える これがダウンタイムのある部分です。一度の作業でまとめて行ってください。 古いプロジェクトで**Publishing**ツールを開き、**Unpublish**を選択します。アプリはこれでオフラインになります。この時点から誰も新しいデータを追加できないため、次に作成するコピーは完全なものになります。 以下の[データベースをコピーする](#copy-the-database)に従い、新しいプロジェクトの**本番**データベースをターゲットとして使用します。このコピーには最新のすべてのデータが含まれます。 アプリがカスタムドメインを使用している場合：古いプロジェクトで**Publishing → Domains**を開き、ドメインを切断します。新しいプロジェクトで**Publishing → Domains**を開き、[接続](/ja/features/publishing/custom-domains#connect-a-domain-you-already-own)します。Replitから求められた場合は、ドメインプロバイダー（例：GoDaddyやNamecheap）でレコードを更新してください。 新しいアドレスが全員に反映されるまで数分から数時間かかることがあります。それまでの間、一部の訪問者にはエラーが表示される場合があります。 アプリが`replit.app`アドレスのみを使用している場合は、代わりに新しいアドレスをユーザーに共有してください。 Webアドレスを開き、新しいアプリがデータとともに読み込まれることを確認します。アプリはオンラインに戻りました。 ## データベースをコピーする コードのコピーはデータベースに影響しません。データはPostgreSQLの`pg_dump`と`pg_restore`ツールでコピーします。これらは両方のプロジェクトのShellで利用できます。ステップ2とステップ3はどちらもここを参照します。コマンドは毎回同じです。変わるのは*ターゲット*だけです。 `pg_dump`を実行した後に書き込まれたデータはコピーに含まれません。ステップ3の最終コピーでは、まず古いアプリをオフラインにしてください。 古いプロジェクトで**Shell**ツールを開きます。次のコマンドを貼り付けてEnterキーを押します。これはファイルツリーに`backup.dump`というファイルを作成します： ```bash theme={null} pg_dump -Fc "$DATABASE_URL" --no-owner --no-privileges -f backup.dump ``` これは**開発**データベースをエクスポートします。稼働中のデータは通常、代わりに**本番**データベースにあります。それをエクスポートするには： 1. **Database**ツールを開き、本番データベースを選択して**Settings**を開きます。 2. 接続文字列をコピーします。 3. 上記のコマンドで、引用符を保持したまま`"$DATABASE_URL"`を接続文字列に置き換えます。 見つからない場合は[接続の詳細](/ja/features/data-and-storage/connection-details)を参照してください。 古いプロジェクトのファイルツリーで、`backup.dump`の横の三点メニューを選択してダウンロードします。次に、ファイルツリーの**Upload files**オプションを使って新しいプロジェクトにアップロードします。 GitHub経由でコードをコピーした場合は、ダンプをコミットしないでください。データがリポジトリに入らないように、別途移動してください。 新しいプロジェクトで**Shell**ツールを開きます。次のコマンドを貼り付けてEnterキーを押します： ```bash theme={null} pg_restore --clean --if-exists --single-transaction --no-owner --no-privileges --exit-on-error -d "$DATABASE_URL" backup.dump ``` このままでは、新しいプロジェクトの**開発**データベースにインポートされます。これはステップ2で必要なものです。 ステップ3の最終コピーでは、代わりに**本番**データベースが必要です。新しいプロジェクトで**Database**ツールを開き、本番データベースを選択して**Settings**を開き、接続文字列をコピーして、`"$DATABASE_URL"`の代わりに使用してください。 これはターゲットデータベース内の一致するオブジェクトを削除してから、データを読み込みます。出力なしで終了すれば成功です。 `pg_restore`がロールまたはポリシーのエラーで失敗する場合、データベースは新しいプロジェクトにまだ存在しないカスタムPostgreSQLロールを使用しています。[サポートに連絡](https://replit.com/support)してください。 新しいプロジェクトが[レガシーNeon開発データベース](/ja/features/data-and-storage/development-and-production#legacy-development-database)を使用している場合、公開フローは**現在の開発データで本番データベースをセットアップする**オプションを提供します。これは、公開時点で開発データベースにあるものをコピーします。テストには適していますが、最終切り替えには上記の手順を使って最新のデータを取得してください。 ## コピーされないものを再作成する プロジェクトの設定の残りはファイルシステムの外に存在します。各要素を新しいプロジェクトで再作成してください： | 項目 | 対応方法 | | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Secrets** | シークレット値は古いプロジェクトから外部に出ません。新しいプロジェクトの[Secrets](/ja/core-concepts/project-editor/app-setup/secrets)ツールで、デプロイメントシークレットも含めて再度追加してください。 | | **Account Secrets** | 新しいプロジェクトで[リンク](/ja/core-concepts/project-editor/app-setup/secrets#manage-account-secrets)してください。新しいプロジェクトが別のアカウントに属している場合は、まずそのアカウントに追加してください。 | | **App Storage** | バケットは移動しません。同じアカウント内では、[既存のバケットを追加](/ja/features/data-and-storage/object-storage#bucket-access-management)してください。アカウント間の場合は、オブジェクトをダウンロードして新しいバケットにアップロードしてください。 | | **Connectors** | 新しいプロジェクトの**Tools → Connectors**から各インテグレーションを再接続してください。[インテグレーションの概要](/ja/features/integrations/overview)を参照してください。 | | **Deployments** | コピーは非公開状態です。[ステップ2](#step-2-set-up-the-new-app)のように、新しいワークスペースから[公開](/ja/features/publishing/overview)してください。 | | **Custom Domains** | 古いデプロイメントからドメインを削除し、新しいデプロイメントにリンクして、DNSレコードを更新してください。[ステップ3](#step-3-switch-your-users-to-the-new-app)で説明されています。 | | **Collaborators** | 新しいワークスペースでコラボレーターを再度招待し、[アクセス](/ja/teams/identity-and-access-management/groups-and-permissions)を設定してください。 | | **Agent history** | Agentの会話と[チェックポイント](/ja/features/version-control/checkpoints-and-rollbacks)のロールバックは古いプロジェクトに残ります。チェックポイントのコミットはGit履歴とともに移動しますが、コピーからそれらにロールバックすることはできません。 | ## 問題が発生した場合 古いプロジェクトはまだそこにあります。元に戻すには： 1. 古いプロジェクトで**Publishing**ツールを開き、**Publish**を選択します。 2. カスタムドメインを移動した場合は、同じ方法で元に戻します。 アプリはオフラインにした時点のデータで再び稼働します。何も失われていません。 ## クリーンアップ 新しいアプリが正常に動作していることを確認するため、1週間ほど待ってください。その後： * 両方のプロジェクトとデバイスから`backup.dump`を削除してください。各コピーにはデータの完全なエクスポートが含まれています。 * 必要に応じて、古いプロジェクトを削除してください。 ## 関連リソース * [チームへのアプリの転送](/ja/teams/identity-and-access-management/transfer-app-to-teams)：チームワークスペース間またはチームワークスペースへプロジェクトを移動するための組み込み転送機能 * [プロバイダーからインポートする](/ja/build/import-from-providers)：サポートされているすべてのインポートソース * [共有データベースを使用する公開済みアプリを修正する](/ja/features/data-and-storage/shared-database-migration)：`pg_dump`と`pg_restore`のトラブルシューティングの詳細