WP STAGING はどのように WordPress 移行を処理するか

WP STAGING | PRO の PUSH 処理を開始すると、Staging サイトからのデータ移行で本番サイトが壊れないようにするため、バックグラウンドでいくつかの手順と準備が行われます。

Staging サイトの移行を開始するときに区別すべき 2 つのことがあります:

  • ファイルベースのデータの移行
  • データベーステーブルの移行

ファイルの移行とデータベーステーブルの移行の違いを説明します。

Migrate WordPress

WordPress は設定のほとんどをデータベースと呼ばれる固有の場所に保存します。このデータは「テーブル」と呼ばれる単位で整理されています。ほとんどの Plugin も同様で、設定をこのデータベースに保存します。
Plugin はテキストファイル (テキスト文書のようなもの) を基にしており、データベースとそのテーブルとは分離されています。

ファイルは、ローカルコンピューターでファイルをコピーするのと同じように、ある場所から別の場所にコピーすることで転送できます。

Copy file data

データベースの内容とデータは Plugin ファイルからアクセスして要求できますが、データベース自体はファイルのように別の場所にコピーすることはできません。

シンプルなデータベースの説明

より理解しやすくするために、たとえ話で説明します。

想像してください。あなたはアパートか家に住んでいます。
そのアパートには好きな場所に置ける家具があります:

What is a database? Migration analogy explanation
データベースのたとえ

アパートがデータベースで、家具の種類はテーブルと呼ばれる単位で整理されたデータベースデータです。家具やテーブルデータは配置できますが、アパートやデータベース自体を別の場所に移動することはできません。少なくとも、極めて技術的な課題とずっと大きな機械なしには不可能です 😉

実際のケース例を見てみましょう – Plugin の PUSH

Staging サイトに新しい Plugin をインストールしたり、既存の Plugin を更新したとします。Plugin を更新しただけで設定を一切変更していない場合は、以下の手順に従って本番サイトに Plugin ファイルをコピーするだけで十分です:

  1. WP STAGING > Sites / Start に移動します。
  2. Push ボタンをクリックします。
  3. 新規・更新された Plugin が含まれる Plugin フォルダを選択するか、すべてのフォルダを選択します。
  4. すべてのデータベーステーブルの選択を解除します。

PUSH 処理を開始します…
完了!

WordPress Migration

本番サイトを訪問すると、Plugin が更新され、Plugin ファイルがコピーされていることが確認できます。

なぜ Plugin と Theme のファイルのみをコピーしたり、特定のデータベーステーブルを移行から除外することが有用なのでしょうか?
WooCommerce のショップ注文やサイトのユーザーコメントを考えてみてください。
Staging サイトを作成した後、新しいコメントや注文が発生する可能性が高いです。WP STAGING を使えば、移行処理を実行する前に特定のテーブルを除外し、これらのデータトランザクションが上書きされるのを防げます。

これにより、Staging サイトから本番サイトにデータベースデータが一切コピーされず、本番サイト上の設定・注文・コメント・その他のカスタムデータが上書きされなくなります。

Theme や Plugin の設定をコピーする必要がある場合はどうすればよいですか?

Plugin や Theme の設定を含む Staging サイトのすべてのデータを移行したい場合は、データベースから本番サイトにデータをコピーする必要があります — 例の家具を思い出してください。

技術的にはこれは決して簡単ではありません。データベースからデータを取得し、本番サイトのデータベーステーブルにコピーするだけでは不十分です。本番サイトにコピーする前に、データに対して複雑な検索・置換文字列操作を実行する必要もあります。これが複雑なのは、WordPress がデータの多くをシリアライズデータとして保存しているためです。

検索・置換の例:

Staging サイトへのパスを含むすべてのリンクは、本番サイトで使用する前に変換する必要があります:

https://hostname.com/stagingsite

は次のように変換されます:

https://hostname.com

Staging サイトのデータを本番サイトで使用できるようになる前に、これと似たもっと複雑な操作が数十回必要になります。すべてのステップを説明することは本記事の範囲を超えており、処理を理解するのに必要でもありません。

知っておくべき重要なことは、WP STAGING がこれらの検索・置換操作をすべて自動的に処理してくれることです!

では、データベースの PUSH の例に戻りましょう。

この例では、本番 WordPress サイトで使用されているデータベーステーブル wp_options に対して、単一のデータベーステーブル wpstg_options を移行するときに何が起きるかを示しています。

Staging サイトから本番サイトに、すべてのデータベーステーブルや特定のテーブルだけを PUSH すると判断したとき — 家具を 1 つの部屋から別の部屋へ移動するとき — 次のことが順番に発生します:

  1. すべての Staging テーブルが新しいテーブルにコピーされ、その名前は wpstgtmp_ という接頭辞が付きます。
    たとえば、wpstg(0)_options テーブルは wpstgtmp_options にリネームされます。
  2. 新しく作成されたデータベーステーブル wpstgtmp_options に対して、いくつかの検索・置換操作が実行されます。
  3. 本番テーブル wp_options は、何か問題が発生した場合に備えて Backup 用として wpstgbak_options としてコピーされます。これで、いつでもこのテーブルから本番サイトを復旧できます。
  4. wpstgtmp_optionswp_options を置き換えます。

以上です。本番サイトを再読み込みすると、すべての Plugin と Theme の設定が本番サイトに移行されていることが確認できます。

本記事で WP STAGING が舞台裏でどのように動作しているかを理解する助けになれば幸いです。

この記事が気に入りましたら、ご友人や同僚と共有してください。

Updated on 5月 23, 2026

Rene Hermenau

著者: Rene Hermenau

About the author: René Hermenau is the founder of WP STAGING. He works on WordPress backups, staging, migrations, database handling, and safe deployment workflows.