2026年9月12日

ロリポップ！マネージドクラウドでWordPressをデプロイする手順と設定の考え方

サーバー・ホスティング

ロリポップ！マネージドクラウドでWordPressを運用するなら、「手元（ローカル）で作ったテーマやプラグインだけをコードとして送り、記事データや画像は本番側を正とする」という線引きを最初に決めておくと、デプロイでの事故がぐっと減ります。この記事では、コンテナ型サービスの特徴を踏まえたデプロイの考え方、事前に管理画面で確かめる項目、テーマ・プラグインとデータベースの送り方、公開後の確認までを順に説明します。

なお、ロリポップ！マネージドクラウドの画面構成や提供機能、プランの内容は更新されることがあります。本文の手順は一般的な流れを示したもので、具体的なメニュー名や接続方法は公式マニュアルで確認してください。本文は執筆時点（2026年10月現在）の情報をもとにしています。

ロリポップ！マネージドクラウドの特徴とデプロイへの影響

ロリポップ！マネージドクラウドは、GMOペパボが提供するコンテナ型のマネージドクラウドです。アクセスの増減に応じてコンテナが起動・停止する仕組みで、一般的な共用レンタルサーバー（ロリポップ！レンタルサーバー）とは別のサービスです。名前が似ているため、ネット上の手順記事を読むときは、どちらのサービスの話かを最初に見分けてください。

コンテナ型であることは、デプロイの設計に次のような形で影響します。

サーバー上で直接ファイルを書き換える運用は向かないことがある: 共用サーバーの感覚でFTPソフトから本番のファイルを1つずつ上書きすると、どの状態が正しいのか分からなくなりがちです。変更は手元で行い、まとめて送る流れにしておくほうが管理しやすくなります。
ファイルの保存先と永続化の範囲を確認する: アップロードした画像やプラグインが書き込むキャッシュが、どこに、どの範囲で保存されるかはサービスの仕様に依存します。作業前に公式の説明でファイルの扱いを確認しておきます。
課金がコンテナの稼働と関係する: 料金はコンテナの起動状況にも関係する仕組みのため、重い処理を繰り返す設定（頻繁な外部監視、無駄なcron処理など）は見直しておくと安心です。料金の詳細は公式サイトで確認してください。

また、公式のサポートはサービス自体の不具合が対象で、WordPressの使い方やテーマ・プラグインのカスタマイズはサポート対象外とされています。デプロイ手順は自分で管理できる形にしておく必要があります。

デプロイ前に決めておくこと

何を「コード」として送るか

WordPressのファイルは、性質の違う3種類に分けて考えます。

コード: 自作テーマ（子テーマ）、自作プラグイン、mu-plugins。手元で編集し、Gitで管理して本番へ送るもの。
データ: データベース（投稿・固定ページ・設定・ユーザー）と wp-content/uploads の画像。本番で日々増えるため、手元から上書きしてはいけないもの。
環境ごとの設定: wp-config.php のデータベース接続情報や認証用キー。環境ごとに値が違うため、Gitに入れず各環境で個別に持つもの。

この線引きをしておくと、「テーマを更新したら本番の記事が古い状態に戻った」「手元の接続情報で本番を上書きして真っ白になった」といった典型的な失敗を避けられます。

本番とは別に確認用の環境を持つ

いきなり本番に送るのではなく、同じサービス内に検証用のプロジェクトを用意するか、手元のDocker環境などで同じPHPバージョンを再現してから送るのがおすすめです。PHPのバージョン違いは、プラグインが動かない原因として特に多いものです。

事前に管理画面で確認する項目

作業を始める前に、管理画面と公式マニュアルで次の情報を控えておきます。項目名は画面の更新で変わることがあるため、目的に合う項目を探してください。

PHPのバージョン: 手元の開発環境と合わせます。WordPress本体の推奨PHPバージョンは WordPress.org の要件ページで確認できます。
データベースの接続情報: ホスト名、データベース名、ユーザー名、パスワード。wp-config.php を作るときに使います。
SSHやGitなどの接続手段: 公開鍵の登録画面があるか、接続先のホスト名・ポート・ユーザー名は何か。プロジェクトの種類によって使える手段が違う場合があるので、WordPressプロジェクトで利用できる方法を確認します。
公開ディレクトリのパス: WordPress本体がどのディレクトリに置かれているか。送り先のパスを間違えると、反映されないか、別の場所にファイルが散らばります。
バックアップの手段: サービス側のバックアップ機能の有無と復元方法。無い場合や範囲が限られる場合は、自分でデータベースとファイルを取得する手順を用意します。

SSH接続を使う場合、鍵は手元で作り、登録するのは公開鍵だけです。秘密鍵をサーバーやチャットに貼り付けたり、Gitリポジトリに入れたりしないでください。

# 手元で鍵を作る例（ファイル名は分かりやすいものに）
ssh-keygen -t ed25519 -f ~/.ssh/lolipop_mc -C "deploy@example"

# 管理画面に登録するのは .pub のほう
cat ~/.ssh/lolipop_mc.pub

テーマ・プラグインを送る手順

1. 手元でGit管理しておく

自作テーマやプラグインのディレクトリをGitで管理し、本番に送る前にコミットしておきます。目的は「どの版を送ったか後から分かる状態」にすることです。送る版にタグを付けておくと、問題が出たときに一つ前の版へ戻しやすくなります。

.gitignore には、ビルド前のソースだけに必要な node_modules や、環境ごとの設定ファイルを入れておきます。

2. 本番のバックアップを取る

送る前に、本番のデータベースと wp-content のバックアップを取ります。サービスのバックアップ機能を使うか、SSHが使える環境ならWP-CLI（使えるかどうかは環境で確認）でデータベースを書き出します。

# SSHで接続した先でWP-CLIが使える場合の例
wp db export ~/backup-$(date +%Y%m%d-%H%M).sql

3. 差分を送る

SSHとrsyncが使える場合は、テーマのディレクトリ単位で差分を送るのが扱いやすい方法です。最初は --dry-run で何が転送・削除されるかを確認し、内容に納得してから本番の転送を行います。

# 送り先のホスト名・ユーザー名・パスは管理画面の情報に置き換える
rsync -avz --dry-run --delete \
  -e "ssh -i ~/.ssh/lolipop_mc" \
  ./wp-content/themes/my-child-theme/ \
  user@ssh.example.jp:/path/to/wordpress/wp-content/themes/my-child-theme/

末尾のスラッシュの有無で「ディレクトリの中身を送る」か「ディレクトリごと送る」かが変わります。上の例は中身を同名ディレクトリへ送る指定です。--delete は送り先にだけあるファイルを消すため、パスを間違えると大事なファイルが消えます。テーマ単位など狭い範囲に限って使ってください。

rsyncが使えない場合は、SFTPでテーマのディレクトリをまるごと置き換える方法になります。その場合も、上書き前に本番側のディレクトリを別名で残しておくと、戻すのが簡単です。

Gitを使ったデプロイ機能が用意されている場合は、それを使うほうが「どのコミットが本番にあるか」を追いやすくなります。対応状況と手順は公式マニュアルで確認してください。

4. 有料プラグインやサードパーティ製プラグインの扱い

配布されているプラグインは、Gitに入れて送るより、本番の管理画面から通常どおりインストール・更新するほうが、ライセンス認証や自動更新との相性がよい場合が多いです。どちらで管理するかをプラグインごとに決めて、両方から同じプラグインを書き換えないようにします。

データベースを初回だけ移すとき

手元で作ったサイトを初めて公開する場合だけ、データベースも移す必要があります。この作業は本番の既存データを置き換えるので、公開前の1回限りにとどめ、公開後は手元から本番のデータベースを上書きしないでください。

手元でデータベースを書き出す（wp db export やphpMyAdmin）。
URLを本番のものに置き換える。WP-CLIの wp search-replace はシリアライズされたデータも考慮して置換するため、テキストエディタでの一括置換より安全です。
本番のデータベースに取り込み、wp-config.php を本番の接続情報で作る。
画像（wp-content/uploads）を転送する。

# 手元で、本番URLに置き換えたダンプを作る例
wp search-replace 'http://localhost:8080' 'https://www.example.com' \
  --all-tables --export=prod.sql

--export を付けると手元のデータベースは書き換えず、置換後の内容をファイルに出力します。取り込み先の環境でWP-CLIやphpMyAdminのどちらが使えるかは事前に確認してください。

wp-config.phpの扱い

wp-config.php は環境ごとに作り、Gitには入れません。認証用キー（AUTH_KEY など）は WordPress.org の秘密鍵サービスで新しく生成し、手元と本番で使い回さないようにします。

本番では、エラーを画面に出さない設定にしておきます。

// 本番用 wp-config.php の一部（例）
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );
define( 'DISALLOW_FILE_EDIT', true ); // 管理画面のテーマ・プラグインファイル編集を無効化

DISALLOW_FILE_EDIT を入れておくと、本番の管理画面からテーマのファイルを直接書き換えて手元と食い違う、という事態を防げます。

デプロイ後の確認

送ったあとは、次の順で確認します。

トップページ、投稿ページ、固定ページが表示されるか（ブラウザのキャッシュを避けるため、シークレットウィンドウで確認）
管理画面にログインでき、テーマが意図したものになっているか
お問い合わせフォームの送信、検索、ログインなど動きのある機能
ブラウザの開発者ツールのコンソールにエラーが出ていないか
キャッシュ系プラグインを使っている場合は、キャッシュを削除してから再確認

表示が崩れた・真っ白になった場合は、送ったテーマを直前の版に戻すのが最も早い復旧手段です。そのためにも、手順2のバックアップと手順1のタグ付けを省かないでください。

まとめ

ロリポップ！マネージドクラウドはコンテナ型で、共用レンタルサーバーとは別のサービス。手順を調べるときはどちらの話かを見分ける。
「コード（テーマ・プラグイン）」「データ（DB・画像）」「環境設定（wp-config.php）」を分け、送るのはコードだけにする。
SSH・Git・公開ディレクトリのパス・バックアップ手段は、作業前に管理画面と公式マニュアルで確認する。
送る前に本番のバックアップを取り、rsyncなら --dry-run で確認してから実行する。
データベースの移行は初回公開時だけ。wp search-replace でURLを置き換える。