【実践検証】AIでWordPressサイトを壊さずに改善できるのか

既存のWordPressオンラインストアを使用

今回の検証では、数年前に美容用品やヘアケア商品を販売するために構築された、WordPressのデモストアを使用しました。

このストアでは、WooCommerceに加え、Astra、Elementor、CartFlowsなど、商品の表示からお問い合わせフォーム、決済処理まで、さまざまな機能を担うプラグインが使用されています。

こうした状況は、既存のWordPressサイトの保守・運用を手がける制作会社にとって珍しくありません。運用年数が長くなるにつれてプラグインが増え、デザインが古くなり、一部を変更すると別の機能に影響が及ぶ可能性があるため、更新作業も次第に難しくなります。

今回の目的は、サイトを一から作り直したり、既存のEC機能を置き換えたりすることではありません。改善できる部分を洗い出し、段階的に変更を加えていくことにしました。

検証開始時点で、ステージング環境は以下の構成になっていました。

ここで重要なのは、独自に開発されたコードが存在しなかったことです。今回は、Claudeに既存のPHPクラスを渡してリファクタリングを依頼できるようなケースではありません。サイトの機能の大部分は、サードパーティ製プラグインとその設定によって実現されていました。

そのため、サイトを改善するには、プラグイン間の依存関係や互換性を確認し、ほかの機能に影響を与えずに変更できる部分を見極める必要がありました。

Claude Codeを使ってサイトを調査

まず、Visual Studio CodeからSSH経由でKinstaのステージング環境に接続します。さらに、VS CodeにClaude Codeの拡張機能をインストールしてログインし、ClaudeがWordPressのファイルを確認したり、WP-CLIコマンドを実行したりして、サイトの構成や問題を直接調査できるようにしました。

そして、変更を加える前にステージング環境のバックアップを作成。改善前の状態を比較・検証できるよう、サイトの設定、各ページのレスポンス、エラーログを記録します。

接続が完了すると、Claude CodeからWordPressのインストール環境を調査し、テーマやプラグインのファイルを確認したり、ステージング環境でコマンドを実行したりできるようになりました。

ただし、最初からサイトの更新を依頼するのではなく、まずは変更を加えずに現状を調査するよう、以下の指示を与えました。

「WordPressのインストール環境を調査し、古い依存ライブラリ、独自開発のコード、互換性の問題、繰り返し発生しているエラー、段階的に改善できる箇所を特定してください。それぞれの調査結果について根拠を示し、実際に確認された問題と潜在的なリスクを区別してください。ファイルの変更、プラグインの更新、データベースの変更は行わないでください」

この調査によってサイトの構成を把握できましたが、特に注目すべき問題が見つかったのは、ログとデータベースを詳しく調べたときでした。

調査で明らかになった問題

Claudeによる調査では、ストアを閲覧するだけでは気づきにくい、保守・運用上の問題がいくつか見つかりました。

これらの調査結果から、いくつかの改善方法が考えられました。すべてを一度に更新することもできますが、それでは問題が発生した際に、どの変更が原因なのかを特定しにくくなります。また、決済処理やCartFlows、Elementorで作成したコンテンツに影響が及ぶリスクも高まります。

そこで今回は、ほかの機能から切り離して対応でき、改善効果を測定しやすい小さな問題から着手することにしました。

不要なプラグインの処理を削減

最初に着手したのは、WordPressの既成デザインをインポートする際によく使われるStarter Templatesプラグインに関する問題です。

今回のサイトでは、すでにストアの構築が完了しており、既存のページを表示するためにStarter Templatesのインポート機能を使用する必要はありませんでした。

しかし、インストールされていたバージョンでは、PHPのエラーログにメッセージを記録するコードが実行され続けていました。Claudeが調査したところ、以下のファイル内の処理が原因であることが判明しました。

wp-content/plugins/astra-sites/inc/lib/class-astra-sites-zip-ai.php

該当するコードは以下。

error_log( $zip_ai_path );

調査対象とした5つのエラーログには合計281行の記録があり、そのすべてが同じメッセージによるものでした。

さらに、このプラグインは、通常のストアページでもテンプレートのプレビュー機能に使用する6.5 KBのJavaScriptファイルを読み込んでいました。

どちらもサイトの動作に深刻な影響を及ぼす問題ではありませんが、同じメッセージが繰り返し記録されることで、エラーログから重要な情報を見つけにくくなっていました。また、フロントエンドで読み込まれるスクリプトも、訪問者にとって必要な機能を提供しているようには見えませんでした。

更新と無効化のどちらを選ぶか

Starter Templatesの新しいバージョンでは、問題のログ出力処理が削除されていたため、プラグインを更新すれば、この問題は解決できると思っていましたが、詳しく調べたところ、新しいバージョンでもプレビュー用スクリプトは引き続き読み込まれることが判明。一方、プラグインを無効化すれば、両方の問題を解消できます。

そこでClaudeは、変更を加える前に、ほかのプラグインや現在使用しているテーマが、サイトの動作時にStarter Templatesに依存していないかを確認します。その結果、既存のストアを表示するうえで必要な依存関係は見つかりませんでした。

ただし、無効化にはデメリットもあります。ElementorやブロックエディターからStarter Templatesのテンプレートライブラリを利用できなくなるため、編集担当者が新しいセクションの作成にこの機能を使用している場合は注意が必要です。既存のページの表示には影響しませんが、今後の編集作業に支障が出る可能性があります。

こうした影響を確認したうえで、MyKinstaの「サイト」画面の「プラグイン」タブから、ステージング環境のStarter Templatesを無効化しました。

改善結果

Starter Templatesを無効化する前後で、ステージング環境の状態を比較しました。

また、想定どおり、Starter Templates固有のエディター操作機能も表示されなくなりました。これにより、商品データや決済設定、既存のページコンテンツに手を加えることなく、最初の改善効果を確認できました。

今回の結果は、事前調査の重要性を示すものでもあります。必ずしも新しいコードを書く必要はなく、サイトで使われなくなったプラグインを特定し、不要な処理を取り除くだけでも改善につながることがわかりました。

テーマの更新によるPHP互換性エラーの修正

調査を進めるなかで、Claudeはさらに重大な問題を発見しました。ログインしていない状態でElementorのグローバル設定用URLにリクエストを送信すると、HTTP 500エラーが返されていたのです。

/wp-json/elementor/v1/globals

PHPのエラーログを調べたところ、AstraテーマのElementor互換性に関するコードに問題があることがわかりました。

astra/inc/compatibility/class-astra-elementor.php

以下が記録されていたエラーです。

Call to undefined method WP_Error::get_data()

この問題は、古いバージョンのAstraが、特定の形式のレスポンスを前提に処理を行っていたことが原因でした。

Elementorの該当URLにはアクセス権限による制限が設けられており、必要な権限を持たないリクエストに対しては、WordPressがWP_Errorオブジェクトを返すことがあります。

Astraの互換性に関する関数は、WordPressのrest_request_after_callbacksフィルターを通じて、このレスポンスを処理します。しかし、Astra 4.1.5では、正常なRESTレスポンスであることを確認せずにget_data()メソッドを呼び出そうとしていました。

WP_Errorにはこのメソッドが存在しないため、結果としてPHPの致命的なエラーが発生していました。

テーマのコードを直接修正せずに問題を解決

Claudeに、インストールされているAstraと、WordPressから入手できる新しいバージョンを比較するよう指示しました。その結果、Astra 4.14.1には、以下の条件分岐が追加されていることがわかりました。

if ( is_wp_error( $response ) || ! $response instanceof WP_REST_Response ) {
    return $response;
}

このコードでは、RESTレスポンスのデータにアクセスする前に、WordPressからエラーや想定外の形式のレスポンスが返されていないかを確認しています。

今回再現したエラーに対しては、これが適切な修正方法でした。古いテーマの互換性に関するファイルを直接書き換えることもできましたが、サードパーティ製テーマのコードに独自の変更を加えることになります。その場合、今後テーマを更新した際に、変更内容が上書きされる可能性があります。

そこで今回は、Astraの公式アップデートを適用する方法を選びました。

テーマの更新でエラーは解消されたのか

今回再現したリクエストについては、エラーが解消されました。

更新後も、未認証のリクエストでは該当URLにアクセスできませんが、これは正常な動作です。重要なのは、PHPの致命的なエラーで処理が停止するのではなく、WordPressが適切な認証・権限エラーを返すようになったことです。

WooCommerceを再構築せずにストアのデザインを刷新

テーマの更新が完了したところで、次はストアのデザイン改善に取りかかります。元のデザインには、Astra標準の青系のアクセントカラー、Latoフォント、角ばったボタン、シンプルなWooCommerceの商品一覧レイアウトが使用されていました。また、サイトのブランドイメージに合わない、大きなWhatsApp注文用バッジも表示されていました。

今回は、商品カタログや既存のEC機能には手を加えず、デザインだけを刷新するようClaudeに指示しました。

Claudeは、まずAstraとElementorの設定を調べ、既存の配色がどこで使用されているかを確認しました。そのうえで、バーガンディ（#7B2342）、エスプレッソ（#211A16）、アイボリー（#F7F2EC）を基調とする新しいカラーパレットを導入。見出しにはCormorant Garamond、本文にはJostを採用しました。

さらに、ボタンの角を丸くし、文字と背景のコントラストも改善しました。例えば、メインのアクセントカラー上に表示する白い文字のコントラスト比は、3.98:1から9.72:1に向上。通常のテキストに求められるWCAGのAAA基準を上回る結果となりました。

また、AstraやWooCommerceのファイルを直接変更せずに独自のCSSを読み込めるよう、Claudeはwp-content/mu-plugins/に小さなMUプラグインを作成しました。

新しいCSSでは、商品カードの角を丸くし、画像の縦横比を統一。控えめなホバーエフェクトを加え、カテゴリー名を見やすくしたほか、商品名にはセリフ体、価格にはバーガンディを採用しました。

CSSはWooCommerceの既存の商品一覧のHTML構造に合わせて指定したため、ストア内のほかの商品一覧にも変更が反映されました。

ただし、最初からすべてがうまくいったわけではありません。ClaudeがWhatsAppの注文ボタンのデザインを変更した際、新しいデザインと並んで、元の黒と緑のバッジがそのまま表示されてしまいました。

スクリーンショットを確認したClaudeは、WooCommerceの既存のCSSが、画像を非表示にするために追加したCSSルールよりも優先されていることを突き止めます。また、プラグインによってWhatsAppのリンクが商品画像と商品情報の間に挿入されていることもわかりました。

そこでClaudeは、CSSセレクタと商品カードのレイアウトを調整。ボタンを商品情報の下に移動し、大きなバッジを小さなカプセル型のボタンに置き換えました。

この手法をほかのWordPressサイトにも応用

今回の検証では、運用開始から数年が経過したオンラインストアを対象としましたが、同じ手法はほかのWordPressサイトの保守・運用にも応用できます。

開発者や制作会社が実践する際の流れはシンプルです。まず既存のサイトを調査し、改善すべき問題に優先順位をつけます。バックアップを作成したうえで、ステージング環境で変更を加え、影響を受ける機能が正常に動作することを確認してから、次の作業に進みます。

また、AIへの指示の出し方も重要です。最初からサイト全体の刷新を依頼するのではなく、まずは実際に発生している問題の特定、依存関係の調査、個別に検証できる改善策の提案を依頼するのが効果的です。

Kinstaでは、ステージング環境、SSHアクセス、MyKinstaでのプラグインとテーマの管理機能、バックアップ機能を利用できます。これらを組み合わせることで、公開中のサイトに直接手を加えることなく、AIを活用した調査や改善を安全に進められます。