WP Staging Desktop を使うと、実際の WordPress サイトを自分のコンピューター上で開発、テストできます。ローカルでの作業が完成したら、WP Staging Pro がリリース済みのバックアップと復元のワークフローを通じてそれを展開できます。ローカルサイトから .wpstg backup を作成し、それを展開先の WordPress サイトにアップロードして、そこで復元します。
これはバックアップを基盤とした完全な展開ワークフローです。直接プッシュ（ダイレクトプッシュ）ではなく、バックアップの復元によって展開先のファイルとデータベースの内容が置き換えられる場合があります。作業を始める前に、必ず展開先の新しいバックアップを作成してください。
このガイドの内容
- 要点（TL;DR）
- 方向性を理解する: Free と Pro の違い
- このワークフローが変更するもの
- 前提条件
- ステップ1: ローカルでの変更内容を確認する
- ステップ2: 展開先の本番サイトをバックアップする
- ステップ3: ローカルの Desktop サイトからバックアップを作成する
- ステップ4: ローカルサイトのバックアップをダウンロードする
- ステップ5: 展開先を準備する
- ステップ6: ローカルサイトのバックアップをアップロードする
- ステップ7: 復元内容を確認して開始する
- ステップ8: 完了を待つ
- ステップ9: 本番サイトを検証する
- ステップ10: 完了またはロールバック
- バックアップ展開と直接プッシュの比較
- よくある問題
- よくある質問
要点（TL;DR）
本番の展開先の新しいバックアップを作成し、ローカルの Desktop サイトから .wpstg backup を作成してダウンロードします。そのローカルサイトのバックアップを、WP Staging Pro が動作する展開先にアップロードし、復元の範囲を確認してから復元を実行します。WP STAGING が展開先に合わせてドメイン参照を更新します。Desktop からの直接プッシュは現在もテスト中です。
警告: ローカルサイトのバックアップを復元すると、より新しい本番のファイルやデータベースの内容が上書きされる場合があります。古いローカルデータベースを、稼働中のストア、会員制サイト、その他ライブデータを受信しているサイトに対して復元しないでください。
このガイドを通じて、ソースおよびローカルサイトとは、自分のコンピューター上で WP Staging Desktop の中に構築した WordPress サイトを指します。展開先および本番とは、展開を受け取る別ドメインのライブ WordPress サイトを指します。
方向性を理解する: Free と Pro の違い
Free と Pro の境界は、2つのドメインが一致するかどうかではありません。それは、ワークフローの方向と、バックアップがどこへ向かうかによって決まります。
| ワークフロー | 展開先 | 必要なもの |
|---|---|---|
| ダウンロードしたバックアップを Desktop にインポートする | 任意のローカルドメイン | WP Staging Desktop Free |
| ローカルサイトから作成したバックアップを展開する | 別のライブまたは本番ドメイン | 任意の WP Staging Pro プラン |
| リモートのバックアップ URL から直接復元する、または本番データをプルする | 接続されたローカルワークフロー | Developer または Agency |
| Desktop からの直接プッシュ | 本番 | 未リリース、テスト中 |
WP Staging Desktop Free は、ダウンロードした .wpstg backup をローカルサイトに復元します。そのローカルサイトは mysite.local や client.local など、任意のローカルドメインを使用できます。復元はバックアップの元のドメインに限定されず、Desktop がローカルドメインの検索と置換を自動的に実行します。
ローカルで作成したバックアップを別のライブまたは本番ドメインへ展開するのは外向き（アウトバウンド）の方向であり、これには WP Staging Pro が必要です。Free と Pro のどちらになるかは、ワークフローの方向と展開先によって決まります。Desktop Free はバックアップをローカル開発環境にインポートします。WP Staging Pro はローカルで作成したバックアップを別のライブドメインへ展開します。
Developer および Agency プランは、これに加えて接続型のワークフローを提供します。リモートのバックアップ URL からの直接復元、本番への接続とプル、そして WP STAGING CLI です。これらは知っておくと役立つ背景情報ですが、このガイドの基本的なダウンロードファイルによる展開には必要ありません。
このワークフローが変更するもの
復元は、バックアップの内容を展開先に書き込みます。始める前に、それがライブサイトにとって何を意味するのかを理解してください。
- 展開先は、バックアップの復元に含まれるファイルを受け取ります。
- 展開先は、復元に含まれるデータベースの内容を受け取ります。
- 復元中に、WordPress の URL とドメイン参照が展開先に合わせて更新されます。
- 展開先では、ローカルコピーの作成後に作られたコンテンツが失われる場合があります。
- 復元はコンテンツのマージ（統合）ではありません。
- 展開先のログイン情報は、復元されたデータベースに含まれる認証情報になる場合があります。
- キャッシュ、パーマリンク、連携機能、メール、スケジュールされたタスクは、復元後に確認する必要があります。
復元の範囲は、バックアップの範囲に従います。ローカルサイトでバックアップを作成する際に、どのコンポーネント（ファイル、データベース、またはその両方）を含めるかを選択します。復元はそのバックアップに含まれる内容を適用します。この選択が展開先で何が上書きされるかを決めるため、バックアップのコンポーネントは慎重に選んでください。
警告: ローカルサイトで取得したデータベースを復元すると、より新しい本番の投稿、注文、ユーザー、設定、送信データが置き換えられる場合があります。復元の範囲を理解するまで、先に進まないでください。
前提条件
展開する前に、次のすべてが揃っていることを確認してください。
- WP Staging Desktop 上で動作するローカルサイト。
- テスト済みで承認されたローカルの変更内容。
- ローカルサイトで完全な .wpstg backup を作成できること。
- 別のライブドメインへ展開するための有効な WP Staging Pro プラン。
- 現在のライセンスフローに従って、展開先にインストールおよび有効化された WP Staging Pro。
- 展開先への管理者アクセス。
- アップロードしたバックアップ、その展開、およびロールバック用バックアップに十分な、展開先のディスク容量。
- 本番サイトのメンテナンス時間帯。
- 作業開始前に作成した、展開先の新しいバックアップ。
WooCommerce ストア、会員制サイト、LMS プラットフォーム、フォーム、フォーラム、その他の動的なサイトの場合は、計画のステップをもう1つ追加してください。
ローカルデータベースを復元する前に、ライブの取引やユーザー生成コンテンツをどのように保護するかを計画してください。ローカルコピーの作成後に本番が変化している場合、完全なデータベース復元によってそれらの新しい変更が削除される可能性があります。
ステップ1: ローカルでの変更内容を確認する
何かをパッケージ化する前に、これから展開する内容を正確に確認してください。
- WP Staging Desktop からローカルサイトを開きます。
- ブラウザと WordPress 管理画面でサイトを確認します。
- プラグイン、テーマ、PHP の互換性、設定、コンテンツが正しいことを確認します。
- 実際のバックアップと復元のオプションに基づいて、展開にファイル、データベース、またはその両方を含めるかを決めます。
- 展開後に再度検証が必要となる、本番専用の連携機能や認証情報を記録します。
このワークフローはコンテンツを置き換えるものであり、選択した変更のみをマージするものではありません。バックアップに含まれる内容の完全な状態を復元するものとして展開を計画してください。
ステップ2: 展開先の本番サイトをバックアップする
最初にロールバックポイントを作成します。このステップは、展開用バックアップの作成やアップロードよりも前に行う必要があります。
展開先の WordPress サイトで WP STAGING > Backup & Migration を開き、完全なバックアップを作成して、完了するまで待ちます。コピーをダウンロードするか、展開をロールバックする必要が生じたときにアクセスできる場所に保存されていることを確認してください。
続行する前に、次を確認してください。
- バックアップが正常に完了したこと。
- バックアップに必要なファイルとデータベースが含まれていること。
- そのバックアップが、展開前の復元ポイントとして明確に識別できること。
- そのバックアップに対して復元操作が利用できること。
警告: 展開先のバックアップが失敗した場合は、続行しないでください。検証済みのロールバックポイントがなければ、展開に失敗したときに稼働中の本番サイトへ戻る手段がなくなる可能性があります。
ステップ3: ローカルの Desktop サイトからバックアップを作成する
次に、展開したいローカルの状態をパッケージ化します。
- WP Staging Desktop からローカルサイトを開きます。
- その WordPress 管理画面を開きます。
- WP STAGING > Backup & Migration を開きます。
- Create Backup（バックアップを作成）を選びます。
- 計画した復元範囲が意図的に異なる場合を除き、サイト全体のバックアップを作成し、必要に応じてコンポーネントのチェックボックスをそのままにします。
local-deployment-2026-07-18のような分かりやすい名前を付けます。- Start Backup（バックアップを開始）をクリックし、バックアップの作成が完了するまで待ちます。
このバックアップは、展開先で復元されるローカルの状態を表します。完了すると、Your Backups（バックアップ一覧）に表示されます。
ステップ4: ローカルサイトのバックアップをダウンロードする
バックアップをローカルマシンから移動し、展開先にアップロードできるようにします。
- Your Backups 一覧で、完了したバックアップを見つけます。
- その Actions（操作）メニューを開きます。
- Download（ダウンロード）を選びます。
- .wpstg ファイルをコンピューターに保存します。
- ダウンロードが完了し、ファイルが0バイトでないことを確認します。
このガイドでは、プランに依存しない Pro のファイルワークフローを意図的に説明しているため、ダウンロードした .wpstg ファイルが以降のすべての手順で使われる経路となります。
Developer および Agency プランでは、サポートされている場合、リモートのバックアップ URL から直接復元するなど、接続型またはリモートのワークフローを使用できます。ダウンロードファイルによる手順はどの WP Staging Pro プランでも機能するため、このガイドではその経路を使用しません。
ステップ5: 展開先を準備する
破壊的な操作が行われる前に、本番サイトを準備します。
- 展開先を適切なメンテナンス状態にします。
- コンテンツの入力やその他の展開を一時停止します。
- 稼働中のコマースサイトや会員制サイトでは、新しい注文、サブスクリプション、登録、コメント、送信を停止するか、それらを考慮に入れます。
- アップロード、展開、ロールバック用バックアップに十分なディスク容量があることを確認します。
- 展開先で WP Staging Pro が有効になっていることを確認します。
- ステップ2で作成した展開先の新しいバックアップが利用可能であることを確認します。
- 展開先の URL を記録します。
警告: 次のステップは展開先のデータを置き換える場合があります。バックアップをアップロードする前に、ライブサイトの責任者全員と展開の時間帯を確認してください。
ステップ6: ローカルサイトのバックアップをアップロードする
ダウンロードしたバックアップを展開先に転送します。
- 展開先で WP STAGING > Backup & Migration を開きます。
- Upload Backup（バックアップをアップロード）を選びます。
- ダウンロードしたローカルサイトの .wpstg ファイルを選択します。
- アップロードと検証が完了するまで待ちます。
- バックアップが展開先のバックアップ一覧に表示されることを確認します。
まずは、ここで示す標準的なブラウザアップロードを使用してください。ファイルが大きい場合やアップロードが完了しない場合は、別のホストへの移行ガイドで代替の転送方法を参照してください。リモートのバックアップ URL からのインポートは Developer および Agency の機能であるため、このガイドでの既定の経路ではありません。
ステップ7: 復元内容を確認して開始する
これは展開先を上書きするステップです。確定する前に、落ち着いて確認してください。
- 展開先の一覧で、アップロードしたローカルサイトのバックアップを特定します。
- Actions > Restore（操作 > 復元）を開きます。
- 復元画面に表示される、正確なファイルとデータベースの範囲を確認します。
- 選択したソースが、別のバックアップではなくローカルの展開用バックアップであることを確認します。
- ステップ2で作成した展開先のバックアップがまだ存在することを確認します。
- 復元が始まる前に表示される、上書きの警告を読みます。
- これらすべての確認が完了してから、復元を開始します。
警告: データベースの内容を復元すると、より新しい本番の投稿、注文、ユーザー、設定、送信データが置き換えられる場合があります。ローカルコピーの作成後に本番が重要な変更を受け取っている場合は、いったん停止して再評価してください。
これはバックアップの復元であり、直接プッシュではありません。何もマージされず、ローカルで加えた変更のみを選択的に同期することもありません。
ステップ8: 完了を待つ
復元を、明確な結果が出るまで実行させます。
- 復元画面がジョブをバックグラウンドで継続できると示していない限り、ブラウザとサイトを利用可能な状態に保ちます。
- 同時に別のバックアップ、復元、プラグイン更新、または展開を開始しないでください。
- WP STAGING が Finished Successfully（正常に完了）として示す成功の状態を待ちます。
- 復元がエラーを報告した場合は、何かを再試行する前に、正確なメッセージを記録してください。
復元にかかる時間はバックアップのサイズと展開先のサーバーによって異なるため、想定できる決まった所要時間はありません。
ステップ9: 本番サイトを検証する
訪問者に再公開する前に、展開先を体系的に確認していきます。
- ホームページと主要なフロントエンドのページが読み込まれる。
- WordPress 管理画面へのログインが機能する。
- サイト URL とホーム URL が展開先のドメインを使用している。
- パーマリンクが機能する。
- 混在コンテンツ（mixed content）の警告なく HTTPS が機能する。
- プラグインとテーマが想定どおり有効になっている。
- メディアファイルが読み込まれる。
- フォームが機能する。
- トランザクションメールが正しく設定されている。
- スケジュールされたタスクと cron が実行されている。
- キャッシュと CDN がクリアされている。
- 検索エンジンでの表示設定が本番用に正しく設定されている。
- アナリティクスと同意管理ツールが機能する。
- 決済ゲートウェイと webhook が本番環境を指している。
- WooCommerce のチェックアウトが、意図しない実際の注文を発生させることなく機能する。
- ローカル専用の開発プラグイン、メールキャッチャー、デバッグ設定、テスト用認証情報が残っていない。
必須の確認が完了するまで、展開先をメンテナンスモードのままにしておきます。
ステップ10: 完了またはロールバック
検証で判明した内容に基づいて判断します。
検証が成功した場合:
- メンテナンスモードを解除します。
- コンテンツの入力と取引を再開します。
- ログ、フォーム、メール、チェックアウト、主要ページを監視します。
- 通常の保持ポリシーに従って、展開前のバックアップとローカルの展開用バックアップの両方を保管します。
検証が失敗した場合:
- 展開先の WP STAGING > Backup & Migration に戻ります。
- ステップ2で作成した、展開先の新しい展開前バックアップを復元します。
- 展開先を再度確認します。
- 再試行する前に、本番から離れた場所で展開用コピーを調査します。
警告: 失敗した復元を、本番に対してやみくもに繰り返さないでください。まず展開前のバックアップにロールバックし、その後、ライブトラフィックを処理していないコピー上で原因を突き止めてください。
バックアップ展開と直接プッシュの比較
このガイドは、リリース済みのバックアップを基盤とした方法を説明しています。それが直接プッシュとどう異なるかを明確にしておく価値があります。直接プッシュは、別の未リリースの機能です。
| バックアップベースの展開 | 直接プッシュ |
|---|---|
| WP Staging Pro で現在利用可能 | 未リリース、テスト中 |
| .wpstg backup を作成、転送、復元する | 将来予定されている接続型のプッシュワークフロー |
| 明示的な復元と上書きの確認が必要 | リリースされるまで頼らないこと |
| 管理された形でのサイト全体の展開に適している | 将来の範囲を前提としてはならない |
WP Staging Desktop からの直接プッシュは、リリース後に別途ドキュメントが提供されます。それまでは、上で説明したリリース済みのバックアップベースの方法を使用してください。
よくある問題
バックアップのアップロードが大きすぎる
- 展開先のアップロードと PHP の制限を確認します。
- 利用可能なディスク容量を確認します。
- ブラウザアップロードが完了しない場合は、別のホストへの移行ガイドで代替の転送方法を使用します。
- 大きなアップロードを無理に通すために、サーバーのセキュリティを広範に弱めないでください。
アップロード後にバックアップが表示されない
- ファイルが .wpstg 拡張子を使用していることを確認します。
- アップロードが完了したことを確認します。
- バックアップ一覧を更新します。
- 現在のドキュメントがサポートしている場合に限り、ドキュメントに記載されたバックアップディレクトリと権限を確認します。
復元が失敗する
- 何かをする前に、まずエラーメッセージを保存します。
- ディスク容量とサーバーログを確認します。
- プラグインのバージョンとバックアップに互換性があることを確認します。
- 失敗の原因を理解せずに、本番に対して繰り返し再試行しないでください。
- 一般的な復元の失敗については、バックアップと復元のトラブルシューティングガイドを参照してください。
ログインができなくなる
- 復元されたデータベースが展開先の認証情報をローカルサイトのものに置き換える場合があるため、完全なデータベース復元の後はローカルサイトの管理者ログインを使用してください。
- ロックアウトされた場合は、WordPress 管理者パスワードを手動でリセットする手順に従ってください。
パーマリンクが404を返す
- Settings > Permalinks（設定 > パーマリンク）を開き、既存の構造を保存してリライトルールを再生成します。
リダイレクトまたは混在コンテンツの問題
- Settings > General（設定 > 一般）で、展開先の WordPress アドレスとサイトアドレスを確認します。
- ページキャッシュ、オブジェクトキャッシュ、CDN、ブラウザキャッシュをクリアします。
- HTTPS が機能していること、およびドメインの置換が完了したことを確認します。
新しい本番データが失われている
- 完全なローカルデータベースの復元により、ローカルコピー作成後に作られた本番データが置き換えられた可能性があります。
- それ以上の変更を止めます。
- ステップ2で作成した展開前のバックアップからのロールバックを検討します。
- 自動的なマージによる復旧はないため、展開前のバックアップを唯一の復帰手段として扱ってください。
よくある質問
Desktop サイトを本番に展開するには WP Staging Pro が必要ですか？
はい。Desktop Free は、ダウンロードしたバックアップを任意のローカルドメインのサイトに復元できます。ローカルで作成したバックアップを別のライブまたは本番ドメインへ展開するには、WP Staging Pro が必要です。
Developer または Agency は必要ですか？
ここで説明するダウンロードファイルによるバックアップ展開には必要ありません。Developer と Agency は、リモートのバックアップ URL からの復元、本番のプル、接続型の同期、そして WP STAGING CLI を追加します。
これは直接プッシュですか？
いいえ。これはリリース済みの、バックアップと復元による展開ワークフローです。Desktop からの直接プッシュは現在もテスト中です。
WP STAGING はローカルドメインを本番ドメインに変更しますか？
WP STAGING は、復元中に必要なドメインの検索と置換を実行します。展開後は、展開先の WordPress の URL、HTTPS、キャッシュ、連携機能を検証してください。
新しい注文や本番のコンテンツは保持されますか？
保持されると想定しないでください。ローカルデータベースを復元すると、ローカルコピーの作成後に作られた注文、ユーザー、投稿、送信データ、設定、その他の本番データが上書きされる場合があります。新しい本番バックアップを作成し、復元の範囲とメンテナンス時間帯を慎重に計画してください。
選択した変更だけを展開できますか？
現在のバックアップと復元の画面が明示的に提供する範囲の制御（バックアップに含めるコンポーネントの選択など）のみを使用してください。このワークフローはコンテンツのマージではなく、このガイドは未リリースの直接プッシュを説明していません。
ロールバックできますか？
はい。展開前に展開先の新しいバックアップを作成して検証していれば可能です。展開したサイトが検証に失敗した場合は、その展開前のバックアップを復元してください。
