【PHP脆弱性対策】 AWS Lightsail 2026年最新純正WordPressへのサーバー移行と独自カスタマイズ・Google連携の検証記録

24/10/2026 最終更新日時 : 25/10/2026 サイト管理者

2026年最新の Lightsail 純正環境とネットワーク構成

PHP脆弱性対応前から、Bitnamiはもうサポートしないから移行してくれと連絡が何度も来てましたが、面倒なので無視してました。今回、PHP脆弱性問題、世界中でハッキングがおこり、個人情報が流出しています。やべえもうやるしかないでしょ。ということで、
かつて主流だったBitnami仕様ではなく、2026年現在のスタンダードである「AWS Lightsail純正WordPress（非Bitnami）」をベースに移行しました。

もう、あんまり選択肢もないので、かんたんです。

イメージの作成

デフォルトでいいんですが、ここでBitnamiじゃなくてLightsailです。

もうできた時点で、WEBサーバー動いてますのでIPアドレスでアクセスできます。

静的アドレスの作成と割当

Lightsailの管理画面で「静的 IP アドレス」を新規作成し、対象のWordPressインスタンスに割り当てる。

DNSのWEBサーバードメインのアドレス変更

Route 53の管理画面に移動し、WEBサーバー用の独自ドメイン（the-world-star.com）のAレコードの値を、上記で作成した固定IPアドレス（例: 175.41.248.22）に書き換える。
Lightsailの「パブリック IPv6 アドレス（末尾49ad）」を確認し、AAAAレコードとして新規登録する。

ここまでは慣れてたのでサクサクっとやったのですが、もしかしたらウィザードの中に含まれてたかもしれません。

SSL対応

https、証明書の対応です。
手順: Lightsailの管理画面でウィザードを開始、「Lightsail Setup」に進みます。

  • Step 1: サードパーティードメインを指定する。お名前ドットコムでドメイン名を取得しているため。
  • Step 2: DNS設定画面で「サードパーティ DNS」を選択。お名前ドットコムでドメイン名を取得しているため。DNSはRoute53なんだけど。
  • Step 3-4: 画面の指示に従って「固定 IP アドレスの検証」および「ドメイン割り当ての管理」を続行する。
  • Step 5: Eメールアドレスを入力し、チェックボックスにチェックを入れて「証明書の作成」を実行する。

2. 注意事項

  • 2.1 IPv6確認: ウィザードはIPv4とIPv6の両方を強制検証するため、事前にRoute 53側へLightsailの「パブリック IPv6 アドレス（末尾49ad）」をAAAAレコードとして必ず登録しておくこと。登録がないと検証エラーでロックがかかる。
  • 2.2 DNSゾーンの新規作成禁止: Lightsail側に余計な「DNS ゾーン（空箱）」を作成させてはならない。既存のRoute 53のレコード構成（static. などのS3用レコード含む）を破壊する原因になる。
  • 2.3 過去の残骸（File exists）エラー対策: 過去の不要なCUI操作の残骸があると、最終処理で自動スクリプトが自滅する。失敗した場合は、SSHで以下の一行を実行してファイルを削除してから「セットアップを再開」すること。sudo rm -f /usr/bin/certbot コードは注意してご使用ください。

ここで大きくつまづきました。原因は何も調べすGeminiの言うとおりにしてみてたから…。Geminiは古い情報だという認識がなく、しっぱいしたら自分の知識を集めてやり抜こうとして泥沼になる。AIは古い情報で知ったかぶりします。これ注意。まぁ、コツは、全部AWS Lightsailのウィザドやヘルプに従うことです。

新サーバーへログイン

「WordPress管理者にアクセス」を押すと、右側に設定と手順が出ます。その通りにやればできます。

http://IPアドレスまたはURL/wp-admin/でアクセスできます。
初期ユーザーIDはuser、パスワードは「sshを使用して接続」してコマンドでしらべます。
tail -n 1 ~/application_credentials

All-in-One WP Migration によるデータインポート工程

新サーバー側の土台が整った段階で、旧環境からエクスポートした250MB超のバックアップデータを、移行プラグイン「All-in-One WP Migration」を駆使して新環境へと丸ごとインポート・完全復元しました。

画像はS3にあるのバックアップ不要でそのまま使えます。メディアライブラリ以外含めないチェックを入れて、ダウンロードします。

インポートは新しいサーバー側はインストールはすでにされてて、Activeにするだけです。こちらはPHPのアップロドの容量を512Mに変えたり、タイムアウト設定をしました。

事前準備：PHP容量制限とタイムアウトの拡張

250MBの バックアップファイルをインポートするため、新サーバーの php.ini を書き換えて上限を拡張します。ネイティブ版WordPress（Debian）の該当ファイルは以下にあります。

bash

/etc/php/8.2/apache2/php.ini

コードは注意してご使用ください。

【変更箇所】

ini

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

コードは注意してご使用ください。

設定後、Apache2を再起動して設定を反映させます。

bash

sudo systemctl restart apache2

コードは注意してご使用ください。

「Blogs prepared.」でフリーズ

インポートを開始するとプログレスバーは100%まで進むものの、その後の「Blogs prepared.」の画面から一向に進まなくなりました。

タイムアウトを疑いましたが、Apacheの追加エラーログ（/var/log/apache2/error.log）を確認したところ、原因は別のものでした。

ログ:

[Sat Oct 24 08:34:10 2026] [php:error] [pid 17655:tid 17655] [client xxx.xxx.xxx.xxx:5886] PHP Fatal error:  Trait "Automattic\\Jetpack\\Connection\\Traits\\WPCOM_REST_API_Proxy_Request" not found in /var/www/html/wp-content/plugins/jetpack/_inc/lib/core-api/wpcom-endpoints/class-wpcom-rest-api-v2-endpoint-email-editor-bootstrap.php on line 30, referer: http://xxx.xxx

インポート処理の最終段階で、バックアップデータに含まれていた Jetpackプラグインのファイル破損による致命的エラー（Fatal error） が発生し、処理が完全にストップしていました。

トラブルを引き起こした真の根本原因（複合要因）

今回のフリーズと移行の難航には、環境のミスマッチと手戻りによる以下の複合要因がありました。

  • PHPバージョンアップに伴う非互換（PHP 8.1 → 8.2）：
    移行元（PHP 8.1）から引っ張ってきた古いJetpackのコードが、新環境（PHP 8.2）の厳密な型チェックやクラス読み込み仕様と衝突し、Fatal errorを吐いた。
  • WP-CLIの巻き込み停止：
    安全にコマンドライン（WP-CLI）からプラグインを無効化しようとしたが、WordPressのコアが立ち上がる前にJetpackのエラーが発火するため、wp plugin コマンドすら巻き込まれて強制終了する状態に陥っていた。

解決策：SSHからプラグインを物理的に強制無効化して突破

一度インスタンスを削除して環境をまっさらに作り直して仕切り直した後、WP-CLIすら動かない状態だったため、SSHから直接Jetpackのプラグインディレクトリ名を変更し、システムに強制的に読み込ませない（物理的な退避）手法をとりました。

bash

user@stored-instance:~$ sudo mv /var/www/html/wp-content/plugins/jetpack /var/www/html/wp-content/plugins/jetpack_old

コードは注意してご使用ください。

ディレクトリ名を変更した瞬間、システムがエラーから解放され、止まっていたブラウザのインポート画面が即座に動き出しました。

インポート完了

無事にファイルの復元が最後まで走り切り、インポートが正常に完了しました。

新しいサーバー環境の仕様がクリアになっていない状態で、手探りでインストールを進めるのは手戻りの元であり、非常に危険です。
仕切り直して環境をクリーンにし、エラーログの根本（Fatal error）を特定した上で物理的に対処することが、崩壊した状況から生還するための最大の鍵となりました。

パーマリンクの設定

移行直後は、記事や固定ページにアクセスした際にルーティングの不整合で404エラー（ページが見つかりません）が発生してます。WordPress管理画面の「設定 ➡️ パーマリンク」から「変更を保存」を1回クリック。これにより新サーバー環境へ正しいリライトルールが書き込まれ、各記事へのリンクが一発で正常化しました。前回、web2.the-world-star.comとしてテスト運用の後、本ちゃん運用アドレスに変える手順をとって、リンクの書き換えに苦労したんですが、その場合もこの「設定 ➡️ パーマリンク」から「変更を保存」を1回クリックでいいと思っております。

同時に、画像などのメディアアセットを外部管理している「WP Offload Media（S3連携）」についても、移行時点で新しいサーバー側からS3バケットへの接続が正常に維持・認識されており、メディアライブラリの画像データもトラブルなく引き継がれていることを実機で確認しています。

Offload Media Liteプラグイン S3への画像のアップロードの設定

これは修正が必要でした。なんだか、「全然ご完成がないのでwp-config.phpを書き換えるよ、気をつけてな」みたいな警告が出てたとと思います。


1. 現象

移行直後、新規画像のURLが wp-content/uploads/...（ローカル）のままになり、S3（static）へ転送されない。

2. 原因

移行に伴い、wp-config.php 内のAWSアクセスキーやプラグイン設定（AS3CF_SETTINGS）が初期化されていた。

3. 対策手順

① wp-config.php への認証情報追記

/var/www/wp-config.php の /* That's all, stop editing! Happy publishing. */ より上に設定を追記。

php

define( 'AS3CF_SETTINGS', serialize( array(
    'provider' => 'aws',
    'access-key-id' => 'YOUR_AWS_ACCESS_KEY_ID',
    'secret-access-key' => 'YOUR_AWS_SECRET_ACCESS_KEY',
) ) );

② Webサーバーの再起動

sudo systemctl restart apache2

4. 特定ファイルのみのS3同期

無料版プラグインの制限で過去ファイルの一括同期ができないため、WP-CLIとAWS CLIを組み合わせて本日作成された15枚の画像（Screenshot-from-2026-10-25*）のみをアップし直し。

テーマ・プラグインの独自カスタマイズ実機検証

長年の運用の中でテーマやプラグインに直接施してきた「かゆいところに手が届く独自カスタマイズコード」について、2026年の新環境（WordPress 7.1純正環境）でどのように引き継がれているかを1つずつ実機で検証しました。

結果として、インポートプラグインによる完全上書き復元と、本家テーマの劇的な進化が噛み合ったことで、「一切の手動修正を行うことなく（All is ok）、全ての理想通りの挙動を維持・クリアしている」という最高の結果となりました。

① 「前の記事」「次の記事」の同一カテゴリ制限（next-prev.php）

かつてテーマをアップデートした際は、記事下部のナビゲーションが全カテゴリから最新記事を拾ってしまうため、ファイル内の引数を手動で書き換える必要がありました。しかし、WEBコンソールから実際のファイルを開いて目視確認したところ、初期状態のままで既に以下のフック引数が true に設定されていました。

php

$in_same_term = apply_filters( 'lightning_prev_next_post_in_same_term', true );

コードは注意してご使用ください。

これはテーマ（Lightning）のバージョンアップに伴い、「前後記事の表示は同じカテゴリーを優先する」という仕様に本家側がデフォルトで追いついたことを意味します。最新記事の下部を確認すると、他カテゴリの記事が混ざることなく、同じカテゴリーの過去記事へと美しくリンクされています。

② サイドバー「最近の投稿」のカテゴリ絞り込み

サイドバーの「最近の投稿」欄やカテゴリートップの画像表示、さらに functions.php 内の各種フィルターフック（アーカイブ表示の短縮や日本語スラッグの自動変換など）は、テーマの標準機能の進化やプラグイン・データの引き継ぎにより、追加の手動修正なしで正常に稼働しています。

他、色々見てみたけど、自作コードは全部入ってまして、勝手に引っ越ししてくれました。なんか、そういうふうに作ってたかな？ちょっと不安ですが、今の所前と同じように動いています。

Google関連ツール（Site Kit / AdSense）の移行後挙動

  • Google Site Kit： サーバー移行に伴い認証トークンがリセットされるため、管理画面から再サインイン（再連携）することで即座にデータ計測が復旧します。
  • Google AdSense： 独自ドメイン、広告コード、ads.txt により紐づいているため、DNS切り替え後に正常表示が確認できれば再設定は不要です。

総括

2026年仕様の最新Lightsail純正環境へのサーバー移行は、インポート処理からその後のカスタマイズ検証まで、手動修正ゼロですべての設定がクリーンに引き継がれる大成功の結果となりました。

カテゴリー
サーバー
タグ
前の記事
目次自動表示がされてない問題解決 プラグイン=Table of Contents Plus
24/09/2023