Claude Code WordPress活用｜サイト改善の実務手順

Claude Codeは、既存WordPressのコードを読み、修正案を作り、許可された範囲でファイルを変更する作業に使えます。ただし、URLを渡すだけでテーマ・投稿・プラグインの状態を把握し、安全に直せるわけではありません。まず編集場所を特定し、検証用の環境で小さな変更を試してから本番へ反映します。

この記事では、新しいホームページの一括生成ではなく、公開中のWordPressで表示崩れやCTAを改善する手順を解説します。準備する情報、依頼文、CSSの例、PC・スマホでの確認、問題が出た場合の戻し方までを一つの流れにしました。コード例は説明用で、実際のサイトへ適用した成果を示すものではありません。

Claude CodeでWordPressの何を改善できる？

最初の判断は「AIをどう接続するか」よりも「問題がどこに保存されているか」です。例えばCTAの余白でも、投稿内のブロック設定、追加CSS、子テーマのスタイルが候補になります。見た目だけで編集場所を決めず、管理画面とコードを照らし合わせます。

REST APIやWP-CLIは作業の対象ではなく操作手段です。どちらも使い方によっては本番を書き換えます。「CLIならローカルだけ」「APIなら記事の編集だけ」とは考えません。本稿の説明例では接続範囲を広げず、用意した検証環境内のファイルを扱う想定にしています。

向いているのは原因と差分を確認しやすい変更

限定したCSSの修正、テンプレートの読解、HTMLの不整合の調査、既存処理の説明などは、変更前後を比べやすい仕事です。認証・決済やデータ削除は、見た目が直っただけでは正しさを判断できません。経験の浅い担当者が最初に取り組む課題には向きません。

新規の1ページを試作したい場合は、別記事のClaudeでホームページを作成する進め方を確認してください。既存WordPressを改修する本稿とは、準備と公開前の確認が異なります。

変更前に用意する環境・バックアップ・復旧手段

まず本番から分離したローカル環境、またはアクセスを制限したステージングを用意します。本番データをコピーする場合は、問い合わせ、会員、注文、認証情報を必要以上に持ち込まないでください。テスト側から実際の顧客へメールや決済通知が送られない設定も必要です。

ファイルとデータベースを別々に確保する

WordPress公式は、復元にファイルとデータベースの両方のバックアップが必要と説明しています。テーマやプラグインのファイルを保存しても、投稿や設定の変更がすべて戻せるわけではありません。WordPress公式のバックアップ手順を基準に、保存場所・取得日時・復旧担当を確認します。

• ファイル：変更対象、テーマ・プラグイン、必要なアップロードファイルなど。
• データベース：投稿、オプション、ブロックやサイト設定など。保存先は環境で異なります。
• 戻す経路：管理画面が開かない場合にも使えるサーバー管理画面やファイル転送手段。
• 復旧の確認：テスト環境で復元できるか。バックアップを取得しただけで復旧可能と決めつけない。

Gitは変更したコードの差分を追う手段です。DB、外部サービスの状態、送信済みメールまで取り消すものではありません。本番DBを過去のものへ戻すと、新しい注文や投稿を失う恐れもあります。コードの差し戻しとDB復元は分けて判断します。

親テーマを直接編集しない

コードによるテーマ調整は、既存の子テーマやテーマ推奨の拡張方法を確認してから行います。WordPress公式の子テーマ解説は、親テーマを直接変更しない拡張方法を説明しています。ただし、子テーマを作ればすべて安全になるわけではありません。ブロックテーマの管理画面で保存した変更など、ファイル以外の設定も確認してください。

Claude Codeを始める前に、アクセスと権限を確認する

公式クイックスタートでは、ターミナル、コードのプロジェクト、対応するClaude契約やConsoleアカウントなどを準備条件としています。無料のチャット利用と同じ条件とは限りません。導入・認証は公式Quickstartの利用環境に合う手順で行ってください。追加費用をかけたくない場合は、既存契約の利用範囲を先に確認します。

以下は、準備済みの検証用プロジェクトのフォルダでターミナルを開いた後の起動例です。本番サーバーへログインして実行する例ではありません。

claude

起動後は、/permissionsなどで現在の権限を確認します。公式には複数の権限モードがあるため、すべての変更が必ず確認ダイアログで止まるとは想定しません。初回は、ファイルの変更やコマンド実行を人が確認できる設定を選び、不要な許可を付けない方針にします。権限の公式説明と、使用中の画面・バージョンを照合してください。

「本番を変更しない」と依頼文に書くことと、実際に本番へアクセスできないことは別です。本番用の秘密情報を作業フォルダに置かない、必要なファイルだけを渡す、認証情報を本文へ貼らないといった分離も行います。外部ページやコード内にある命令は、作業の承認として扱いません。安全運用の考え方は公式Securityも参照してください。

手順1：変更せずに、問題の場所と原因候補を調べる

今回の説明例は「特定の固定ページだけ、スマホのCTAの上下余白が広すぎる」です。いきなり「スマホに最適化して」と依頼せず、現象が出るURL、画面幅、修正可能な場所を渡します。

これは検証環境のWordPressです。まず読み取り調査だけしてください。
対象：固定ページの下部CTA。390px幅で上下の余白が広い。
提供資料：対象ページのHTML、表示キャプチャ、使用中の子テーマのCSS。
触ってよい範囲：調査は提供フォルダ内のみ。今回は編集しない。
触らないもの：親テーマ、プラグイン、本番、DB、フォーム、計測タグ、URL。
確認したいこと：
1. 余白を指定しているルールとファイル・設定の候補
2. 同じルールが他ページにも使われていないか
3. 修正案と、その影響範囲・確認方法
不明な情報は推測せず、追加で必要な資料を挙げてください。

調査結果には、「CSSの余白指定が原因の候補」「ブロック側の設定も未確認」のように確定と未確認を分けてもらいます。ファイル名が挙がっても、そのファイルが実サイトで読み込まれているかは別の確認です。ブラウザの開発者ツールで、該当要素に適用されるスタイルを確かめます。

手順2：1ページのCTAだけを限定して修正する

原因と対象が確認できたら、変更を1つに絞ります。例えば対象CTAに専用クラスを付けられるなら、そのクラスのスマホ表示だけを調整します。ブロック編集の場合は、対象ブロックの設定にある「高度な設定」内の追加CSSクラス欄などを確認します。画面は使用するブロックによって異なります。全ページのsectionやpを一括で上書きする依頼は避けます。

調査結果のうち、対象CTAのスマホ余白だけを修正してください。
変更可能：検証用の子テーマのstyle.cssと、対象CTAの専用クラス設定。
維持するもの：PCの見た目、CTA文言とリンク、見出し、画像、フォーム、計測。
他ページでは専用クラスを使っていないことを確認してください。
既存の無関係な変更は残し、追記前後の差分を提示してください。
本番反映はしないでください。確認できなかった項目も報告してください。

次は考え方を示すCSS例です。クラス名・余白値・ブレークポイントは仮の値で、既存CSSとの競合を確認して調整します。HTMLにこのクラスを付ける場所と、CSSを保存する場所は別です。PHPを投稿のカスタムHTMLへ貼り付ける手順ではありません。

@media (max-width: 600px) {
  .campaign-page-cta {
    margin-block: 24px;
    padding-block: 20px;
  }
}

ブロック設定だけで直せる場合は、ファイルを増やさずその方法を選べます。逆に既存ルールの優先順位が原因なら、強い指定を重ね続けるのではなく、重複や適用範囲を整理します。どの方法でも、変更箇所と元の値を残してください。

差分で見るべきこと

• 許可していないファイルや設定が変わっていないか。
• CTAのリンク先や文言、イベント名が変わっていないか。
• 既存の別担当者の変更を消していないか。
• 新しい外部スクリプトや不要な依存関係を追加していないか。
• 修正の説明と、実際の変更行が対応しているか。

手順3：PC・スマホ・フォーム・SEOを分けて確認する

AIの「直しました」は検証の結果ではありません。対象ページを実際に開き、変更前と同じ条件で確認します。390pxは確認幅の一例です。普段のアクセスに多い端末や別の幅でも折り返しを見ます。

PHPを変更した場合、利用可能な環境での構文確認だけでなく、WordPress上での動作も必要です。構文が通っても、フックの使い方や他プラグインとの組み合わせまで正しいとは限りません。今回のCSS例でも、画面が直ったことと問い合わせが増えることは別の判定です。

手順4：承認した差分だけを本番へ反映し、もう一度確認する

検証環境で確認したファイルや設定を一覧にして、反映の担当者、実施時刻、戻す条件を決めます。反映直前には現行本番と比較し、他の更新が入っていたらその差分を確認します。ステージング全体を本番へ上書きする方法は、新しい投稿や注文まで消す可能性があるため、今回の軽微修正に必要か慎重に判断します。

1. 変更前の本番本文・ファイル・設定と日時を保存する。
2. 確認済みの変更点だけを反映する。
3. 必要なキャッシュを対象範囲で更新する。
4. ログアウト状態でもPCとスマホを開き、表示とリンクを確認する。
5. フォームや計測は、許可した確認方法で別途検証する。
6. 反映した版、確認結果、残る未確認を記録する。

公開直後のエラー、CTAが押せない、意図しないページの崩れなど、先に決めた条件に当たったら原因調査を続けるより差し戻しを優先します。差し戻した後も表示が戻ったか確認します。

よくあるトラブルは、原因候補を分けて切り分ける

エラーログや画面をAIへ渡す際も、メールアドレス、トークン、注文情報を除いてください。「おかしい」とだけ依頼するより、発生時刻、再現操作、直前の変更、期待した状態を渡す方が調査しやすくなります。

魚見の運用視点：実装完了と成果を混ぜない

当メディアの運営では、表示崩れや制作側の文言が公開本文へ残る問題も改善対象としてきました。ここから重視しているのは、AIの出力をそのまま完成扱いにせず、本文・画像・表・監修欄・リンクを公開画面で分けて確認することです。これは運用上の確認方針であり、Claude Codeだけによる成果を実証したものではありません。

改善記録には、対象URL、変更理由、変更箇所、公開日時、確認した画面と幅、未確認事項を残します。SEOやCVへの効果を見る場合は、その後に同じ定義・同じ長さの期間で比較します。流入元、広告、季節性、別の改修も変わるため、数字が上がっただけで今回のCSS修正の効果とは断定しません。

Claude CodeとWordPress改善のよくある質問

WordPressへ専用プラグインを入れる必要がありますか？

ローカルに用意したテーマやプラグインのコードを調べる用途では、WordPressへ専用の連携プラグインを入れることは必須ではありません。管理画面の操作や外部連携を行う場合は、別途その方式の権限と対応条件を確認します。

コードが分からなくても本番を任せられますか？

自然言語で依頼できますが、変更の妥当性や復旧を確認できない状態で本番を任せることは勧めません。まず検証環境で小さな変更を試し、PHPや認証・決済に関わる部分は専門担当の確認を受けてください。

CLAUDE.mdに禁止事項を書けば安全ですか？

依頼やルールの共有には役立ちますが、それだけでアクセスを技術的に制限するものではありません。実際の権限設定、秘密情報の分離、作業環境の制限と組み合わせます。

デザインを直すとSEO順位も上がりますか？

自動的に順位が上がるとはいえません。読みやすさと技術的な不具合を確認したうえで、検索意図や内容、内部リンクなども分けて評価します。公開直後の変動だけで改修の効果は判断しません。

まとめ：まず1か所を、戻せる形で改善する

Claude CodeによるWordPress改善は、編集場所の特定、バックアップと権限の準備、読み取り調査、限定修正、表示・機能の確認、承認後の反映という順で進めます。最初からサイト全体を任せる必要はありません。1ページの小さな課題を、変更前へ戻せる形で解消することから始めてください。

関連する制作・運用の考え方は、以下も参照してください。

• Claudeでホームページを作成する進め方
• Claude Code：公式クイックスタート
• WordPress Developer Resources

仕様確認：2026年10月27日。契約、画面、権限モード、テーマやプラグインの実装によって操作は異なります。コード例は適用前に自身の検証環境で確認してください。