速さの理由を知る。安全の仕組みを知る。WordPress運用の「なぜ？」を解く技術コラム。

WordPressサイトをKUSANAGIに移行する方法

王文暁
BUILD
KUSANAGI
KUSANAGI
This entry is in the series KUSANAGI開発メンバーのエンジニアブログ

WordPress を運用するうえで、高速性・セキュリティ・安定性はとても重要です。

KUSANAGIは、WordPressに特化した超高速仮想マシン環境であり、サーバーの最適化やキャッシュ機能、SSL設定、PHPバージョン切替など多くの便利な機能を備えています。KUSANAGIのメリットについて、下のリンクを確認できます。

https://kusanagi.tokyo/edition_and_upgrade

これにより、KUSANAGI環境への移行は大きなメリットとなります。

以下では、非KUSANAGI環境からKUSANAGI環境へWordPressを移行する手順として、二つの方法を紹介します。

手動でファイルとデータベースを移行する方法

事前準備と注意

非KUSANAGI環境で稼働しているWordPressサイトがあります。

KUSANAGIの新環境はすでに構築済みで、SSHログインが可能です。

注意

１，デモンストレーションのため、新しいサイト名は「example」としています。

現行環境でデータベースをエクスポートする

mariadb-dump -u wp_old_username -p old_database_name > wp_old_dump.sql

wp_old_username: 実際のデータベースユーザー名
old_database_name: 実際のデータベース名

このコマンドを実行すると、SQLバックアップファイルwp_old_dump.sqlが作成されます。

WordPress サイトのファイルをアーカイブする

WordPress のルートディレクトリ（wp-config.php がある場所）で次のコマンドを実行します。

tar -zcvf ~/wp_old_files.tar.gz ./*

このコマンドを実行すると、サイト全体のファイルをまとめたアーカイブ wp_old_files.tar.gz がホームディレクトリに生成されます。

アーカイブとSQLをKUSANAGI環境へ転送する

scpツールか手動で転送します。

scp -i ./id_rsa ~/wp_old_dump.sql KUSANAGI_USER@KUSANAGI_HOST:~/
scp -i ./id_rsa  ~/wp_old_files.tar.gz KUSANAGI_USER@KUSANAGI_HOST:~/

id_rsa: KUSANAGI サーバーへアクセスする際に使用する秘密鍵
KUSANAGI_USER: サーバーのユーザー名（例: kusanagi）
KUSANAGI_HOST: サーバーのホスト名または IP アドレス

コマンドが成功すると、転送先サーバーのホームディレクトリ /home/kusanagi/ に以下のファイルが配置されます。

  • /home/kusanagi/wp_old_dump.sql
  • /home/kusanagi/wp_old_files.tar.gz

KUSANAGI環境で新規サイトを作成する（プロビジョニング）

 kusanagi provision \
  --wp \
  --wplang=ja \
  --email=xxx@example.com \
  --fqdn=example.com \
  example

--email: SSL管理者メールアドレス/--noemail:SSLを設定しない
--fqdn: 元々のサイトのドメイン名
example: プロファイル名（プロビジョニング名、任意に設定可能）

kusanagi provision を実行すると、最後に データベース名 / ユーザー名 / パスワード が自動生成されて表示されます、証明書の取得されます。これらの情報は後のデータベースインポート時に必要となるので、必ず控えておきましょう。

実行例


  [root@almalinux9 kusanagi]# kusanagi provision \
  --wp \
  --wplang=ja \
  --noemail \
  --fqdn=example.com \
  example
Target directory is /home/kusanagi/example.
--2026-08-17 13:08:33--  https://ja.wordpress.org/wordpress-latest-ja.zip
Resolving ja.wordpress.org (ja.wordpress.org)... 66.6.42.252, 2620:109:b00a::4206:2afc
Connecting to ja.wordpress.org (ja.wordpress.org)|66.6.42.252|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 38987659 (37M) [application/zip]
Saving to: '/tmp/wp_dl_dir.n8nx1L/wordpress.zip'
......
Success: Shuffled the salt keys.
Generated dbname: example
Generated dbuser: example
Generated dbpass: 3YSD-dpQb-Vwu--CYQH
Provisioning of example completed. Access example.com and install wp.
provision completed.

DNS 切替前に作業を進める都合で--noemailを指定した場合は、DNSを新サーバーへ切り替えたあとに、あらためて証明書を取得します。

kusanagi ssl --email xxx@example.com example

旧サイトのファイルを展開して配置する

１，プロビジョニングのファイルをバックアップします

まず、プロビジョニング時に自動生成されたWordPressファイルをバックアップしておきます。

mv /home/kusanagi/example/DocumentRoot /home/kusanagi/example/DocumentRoot_bak
mkdir /home/kusanagi/example/DocumentRoot

次に、先ほど転送した旧サイトのアーカイブファイルを解凍し、新しいDocumentRootに展開します。

tar -xvzf /home/kusanagi/wp_old_files.tar.gz -C /home/kusanagi/example/DocumentRoot

最後に、 ディレクトリとファイルの移動作業を行ったため、所有権とパーミッションを調整します。

chown -R kusanagi:www /home/kusanagi/example/DocumentRoot
find /home/kusanagi/example/DocumentRoot -type d -exec chmod 755 {} \;
find /home/kusanagi/example/DocumentRoot -type f -exec chmod 644 {} \;

データベースをインポートする

２，プロビジョニングのデータベースをクリアします

KUSANAGIプロビジョニングで自動生成されたデータベースを一度削除し、新しく作り直します。

mariadb -u root -p -e "DROP DATABASE example; CREATE DATABASE example CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;"

exampleの部分は実際のデータベース名に置き換えてください。

３，旧環境のデータをインポートします

旧環境からエクスポートしたSQLダンプをインポートします。

mariadb -u wp_new_username -p new_database_name < wp_old_dump.sql

wp_new_username: 新しいデータベースのユーザー名（kusanagi provision 実行時に生成されたもの）
new_database_name: 新しいデータベース名（kusanagi provision 実行時に生成されたもの）
wp_old_dump.sql: 旧環境から取得したバックアップファイル

wp-config.phpを調整する

wp-config.phpに記載されているデータベースの接続情報を新しい環境の値に変更する必要があります。

/** MySQL データベース名 */
define('DB_NAME', 'example');

/** データベースのユーザー名 */
define('DB_USER', 'example');

/** データベースのパスワード */
define('DB_PASSWORD', 'example');

動作確認とDNS切替を行う（本番化）

本番のDNSを切り替える前に、ローカル環境で新サーバーの動作を確認します。
利用しているパソコンのhostsファイルを編集します。

  • Windows: C:\Windows\System32\drivers\etc\hosts
  • macOS: / Linux: /etc/hosts

以下の設定を追加します。

xx.xx.xx.xx example.com

xx.xx.xx.xx: KUSANAGIサーバーのIPアドレス

ブラウザからhttp://example.comにアクセスし、ローカルでKUSANAGI環境のサイトを確認します。

ローカルでサイトの動作確認をします、管理画面とホームページ、詳細ページの表示をしっかり確認します。

（DNS 切替）本番化します

ローカル確認で問題がなければ、実際のDNSレコードをKUSANAGIサーバーに切り替えます。

DNS反映後、世界中から新しいKUSANAGI環境のWordPressにアクセスできるようになります。

その他

１，KUSANAGIプラグインが存在しない問題

KUSANAGI プラグインは、キャッシュや高速化など多くのパフォーマンス最適化機能を提供します。しかし、非KUSANAGI環境で稼働していたWordPressには、このプラグインが含まれていません。

この状態は、kusanagi update plugin コマンドで解消できます。

kusanagi update plugin --force example

example: プロファイル名
--force: 既存プラグインの有無やバージョンにかかわらず、強制的に上書きます

プラグインを利用して移行する方法

手動でファイルとデータベースを移行する方法のほかに、WordPress のプラグインを使って移行する方法もあります。代表的なものにAll-in-One WP MigrationやUpdraftPlus: WP Backup & Migration Pluginなどがあり、いずれも導入実績（インストール数）が多く、利用者の多い定番プラグインです。

手動方式が「データベース」と「ファイル」を別々に扱うのに対して、これらのプラグインはサイト全体を一つのファイルにまとめて書き出し、移行先で展開するという考え方をとります。コマンド操作に不慣れな場合でも、ほとんどの作業を WordPress の管理画面（GUI）だけで完結できるのが特徴です。

ここでは、代表的な移行プラグインであるAll-in-One WP Migrationを利用する方法を紹介します。

All-in-One WP Migration とは

All-in-One WP Migration は、WordPress サイトのデータベース・テーマ・プラグイン・メディアファイル・設定をまとめて 一つのファイル（.wpress 形式）に書き出し、別の環境にそのまま取り込めるプラグインです。

手動移行で必要だった以下の作業を、プラグインが自動で処理してくれます。

  • データベースのエクスポート／インポート（mariadb-dump などのコマンド操作が不要）
  • サイト URL やファイルパスの一括置換（ドメインが変わっても自動で調整）

つまり、手動方式の手順の大部分を肩代わりしてくれるのが、このプラグインの価値です。

旧環境でAll-in-One WP Migrationを使ってエクスポートする

まず、移行元のWordPress管理画面でAll-in-One WP Migrationをインストールし、有効化します。

有効化すると左メニューに項目が追加されるので、エクスポート画面を開き、エクスポート先として「ファイル」を選んで実行します。処理が完了すると .wpress 形式のバックアップファイルをダウンロードできます。

KUSANAGI環境で新しいWordPressサイトを作成する

kusanagi provision --wp --wplang=ja --email=xxx@example.com --fqdn=example.com example

fqdn: には移行先で利用するドメイン名を指定します。
example: サイト名（プロビジョニング名、任意に設定可能）

プロビジョニング完了後、ブラウザで新しいWordPressにアクセスし、初期設定を行います。

アップロードサイズの制限を調整する（重要）

インポートは、ブラウザから.wpressファイルをアップロードする形で行います。ここでつまずきやすいのがアップロードできるファイルサイズの上限です。

.wpressファイルは、サイトの内容によっては数百MBに達することがあります。一方で、サーバーは初期状態だとアップロードできるサイズをかなり小さく（数十MB程度に）制限していることが多く、そのままでは大きなファイルのアップロードが途中で失敗します。

ここで知っておきたいのは、アップロードの制限が「2段構え」になっているという点です。ファイルはブラウザ → Nginx（Web サーバー） → PHPという順に渡っていくため、NginxとPHPの両方で上限を引き上げないと、どちらか小さいほうで止まってしまいます。

Nginxの調整

Nginx 側で確認すべきは、サイズ上限とタイムアウトの2種類です。サイズが足りないと「413 Request Entity Too Large」、タイムアウトが足りないと「504 Gateway Time-out」などになります。

  • client_max_body_size: 受け取るデータのサイズ、この値が小さいと413が返る
  • client_body_timeout: リクエストボディ連続する読み込み時の待ち時間、この値が小さいと408が返る
  • send_timeout: クライアントへの連続するレスポンス送信時の待ち時間
  • fastcgi_read_timeout: PHPからの応答を待つ時間、タイムアウトすれば504になる

KUSANAGI では設定ファイルが分かれており、すでに定義済みの指令は、その定義元のファイルを修正しないと反映されません。指令ごとのと設定ファイルは次のとおりです。

設定項目設定ファイル備考
client_max_body_size/etc/opt/kusanagi/nginx/conf.d/{プロファイル名}.conf既存の値を変更
fastcgi_read_timeout/etc/opt/kusanagi/nginx/conf.d/fastcgi.inc既存の値を変更
client_body_timeout / send_timeout/etc/opt/kusanagi/nginx/conf.d/{プロファイル名}.wp.inc未定義のため追記
# {プロファイル名}.conf
client_max_body_size 512M;

# fastcgi.inc
fastcgi_read_timeout 600s;

# {プロファイル名}.wp.inc
client_body_timeout 600s;
send_timeout        600s;

{プロファイル名}.confと{プロファイル名}.wp.inc以外のファイルは、KUSANAGIの更新時に再生成されて元の値に戻る可能性があります。アップデート後は、上記の値が維持されているか必ず確認してください。

PHPの調整

PHP側にも、アップロードに影響する設定が複数あります。

  • upload_max_filesize: 一つのアップロードファイルの最大サイズ
  • post_max_size: POSTリクエスト全体の最大サイズ
  • memory_limit: PHPが使用できるメモリ上限
  • max_execution_time: スクリプトの最大実行時間
  • max_input_time: リクエストデータの読み込みに許容される時間
  • request_terminate_timeout: タイムアウトした場合、PHPワーカープロセスは強制終了される

KUSANAGIの既存設定はPHPが/etc/opt/kusanagi/php.d/php.ini、PHP-FPMが/etc/opt/kusanagi/php-fpm.d/www.confにあります。しかし、これらのファイルはKUSANAGIのアップデート時に上書きされ、設定が元に戻る可能性があるため、直接編集せずに追加の設定ファイルを作成します。

/etc/opt/kusanagi/php.d/extensions/z-migration.ini

upload_max_filesize = 512M
post_max_size = 600M
memory_limit = 768M
max_execution_time = 600
max_input_time = 600

PHP-FPM側も追加の設定ファイルを作成します。

/etc/opt/kusanagi/php-fpm.d/z-migration.conf

request_terminate_timeout = 660

設定を反映する

設定ファイルを書き換えただけでは反映されません。NginxとPHP（php-fpm）を再起動して、変更を有効にします。

kusanagi nginx
kusanagi php

新しいWordPressでエクスポートファイルをインポートする

旧環境と同じように、新しい WordPressにも All-in-One WP Migrationをインストールして有効化します。

インポート画面を開き、旧環境で書き出した .wpressファイルをアップロードします。完了すると、新サイトの内容が旧サイトのデータで上書きされます。

注意：
１，インポート後はログイン情報も旧サイトのものに置き換わります。新環境で設定した管理者アカウントではなく、旧サイトのアカウントで再ログインしてください。その後、トップページ・詳細ページ・管理画面の表示を確認します。
２，All-in-One WP Migrationでインポートすると、移行元サイトのデータ、テーマ、プラグイン、メディアファイルなどが移行先へ反映されます。ただし、移行先WordPressに元々存在していたプラグインファイルが残る場合があります。

有料プランについて

個人サイトや一般的な企業サイトであれば、無料版でも問題なく移行できるケースが多いです。ただし、以下のような場合は有料プラン（拡張機能）の購入が必要になることがあります。

  • 移行を行う回数が多く、効率化したい場合
  • 自動バックアップまたはクラウドストレージへのバックアップを利用したい場合

まとめ

方法メリットデメリット
手動方式（ファイル＋DB）サイズ制限がない／細かく制御でき、トラブル時の原因調査がしやすいコマンド操作が必要。作業手順が多く、ミスが起きやすい。
プラグインを利用する方式管理画面から操作できる。小〜中規模サイトなら簡単に移行できる。大きなサイトではアップロード制限やインポート失敗が発生する場合がある／移行回数が多い場合は、有料プランが必要になることがある

小〜中規模のWordPressサイトであれば、All-in-One WP Migrationを利用した移行が手軽でおすすめです。

一方で、容量の大きいサイトや、トラブル時に原因をしっかり追いたいサイトでは、ファイルとデータベースを手動で移行する方法のほうが向いています。サイトの規模や運用方針に合わせて、使い分けるとよいでしょう。

参考

https://servmask.com/products/all-in-one-wp-migration-pro

KUSANAGIを、PCとスマートフォンから使えるAI開発環境にしてみました

by 相原 知栄子/ Chieko Aihara

Webサイト運用の課題解決事例100選 プレゼント

Webサイト運用の課題を弊社プロダクトで解決したお客様にインタビュー取材を行い、100の事例を108ページに及ぶ事例集としてまとめました。

・100事例のWebサイト運用の課題と解決手法、解決後の直接、間接的効果がわかる

・情報通信、 IT、金融、メディア、官公庁、学校などの業種ごとに事例を確認できる

・特集では１社の事例を3ページに渡り背景からシステム構成まで詳解

Webサイト運用 課題解決事例100選 プレゼント