WithCodeMedia-1-pc
previous arrowprevious arrow
next arrownext arrow

WithCodeMedia-1-sp
previous arrowprevious arrow
next arrownext arrow

Claude CodeでWordPressをカスタマイズする|子テーマ改修を実演

生徒

Claude CodeでWordPressのカスタマイズってできますか? テーマのPHPを触るのが怖くて…

ペン博士

できるよ。しかも怖い部分こそAIと相性がいい。子テーマの用意・変更前の確認・エラー時の切り分けを型にしておけば安全に進む。実際の改修を通しで見せるね。

WordPressのカスタマイズで手が止まる理由は、たいてい壊したときに戻せる自信がないことです。functions.phpを1文字間違えるとサイト全体が真っ白になります。

Claude Codeのようなコーディング支援AIは、この領域と相性が良いツールです。既存ファイルを読んで影響範囲を説明させたり、変更前にバックアップを取る手順ごと実行させたりできます。

この記事では、環境の準備から、実際の改修(記事下に関連記事を出す機能の追加)を通しで実演します。あわせて、AIに任せてはいけない範囲と、事故を防ぐ運用ルールも扱います。

  • WordPress改修でAIを使う利点と限界
  • 作業環境の準備(ローカル・子テーマ・バックアップ)
  • 最初に伝えるべき前提情報
  • 実演:記事下に関連記事を出す機能を追加する
  • 変更前に影響範囲を確認させる
  • エラーが出たときの切り分け
  • 本番へ反映する手順
  • AIに任せてはいけない範囲
  • セキュリティ上の注意点
  • チームで使うときのルール

目次

WordPress改修でAIを使う利点と限界

WordPress改修でAIを使う利点と限界

何ができて何ができないかを、最初に整理しておきます。

作業AIの適性理由
既存コードの読解と説明高いファイルを横断して追える
定型的なフックの追加高い書き方が決まっている
CSSの調整高い検証しやすい
エラーの原因特定高いログから絞り込める
デザインの良し悪しの判断低い目的と好みは伝えないと分からない
本番環境での実行任せない取り返しがつかない
プラグインの選定参考程度実際の相性は検証が必要

要点は、AIに手を動かさせる範囲と、人間が判断する範囲を分けることです。特に本番環境への反映は、必ず人間が確認してから行います。

作業環境の準備

作業環境の準備

安全に進めるための前提です。この3つが揃っていないなら、先に用意してください。

1. ローカル環境またはテスト環境

# 例:wp-env(WordPress公式のローカル環境)
npm -g install @wordpress/env
mkdir my-wp && cd my-wp
npx wp-env start
# → http://localhost:8888 で起動する

本番で直接試さないこと。これが最大の安全策です。ローカル環境なら、壊しても作り直せます。

2. 子テーマ

wp-content/themes/
├── parent-theme/          # 親テーマ(触らない)
└── parent-theme-child/    # ここで作業する
    ├── style.css
    └── functions.php

親テーマを直接編集すると、更新のたびに変更が消えます。子テーマを用意してから作業を始めてください。

3. バージョン管理

cd wp-content/themes/parent-theme-child
git init
git add .
git commit -m "改修前の状態"

Gitがあれば、どんな変更をしても1コマンドで元に戻せます。AIに作業させるうえで、これが最も効く保険になります。

最初に伝えるべき前提情報

最初に伝えるべき前提情報

AIは環境を知りません。最初に前提を渡すと、的外れな提案が減ります。

このプロジェクトはWordPressの子テーマです。前提を共有します。

環境:
- WordPress 6.7 / PHP 8.2
- 親テーマ:(テーマ名)
- 作業対象:wp-content/themes/(テーマ名)-child のみ
- 本番反映:私が手動で行う。あなたは本番に触らない

ルール:
- 親テーマのファイルは編集しない
- functions.php を編集する前に、必ず現在の内容を確認する
- 変更は1つずつ。複数の機能を同時に追加しない
- PHPの記述後は php -l で構文チェックを行う

まず、現在の子テーマの構成を確認して報告してください。

最後の一文が重要です。いきなり書かせるのではなく、現状を読ませてから始めると、既存コードとの衝突を避けられます。

実演:記事下に関連記事を出す

実演:記事下に関連記事を出す

実際の改修例です。同じカテゴリの記事を3件、本文の下に表示する機能を追加します。

依頼のしかた

記事ページの本文下に「関連記事」を表示する機能を追加してください。

要件:
- 同じカテゴリの記事を、公開日の新しい順に3件
- 現在表示中の記事は除外する
- 該当がない場合は何も表示しない
- アイキャッチ画像・タイトル・公開日を出す
- 出力はテンプレートパーツに分け、functions.phpにはフックだけ書く
- CSSは子テーマのstyle.cssに追記する

制約:
- プラグインは使わない
- クエリは1回に収める
- 表示位置は the_content フィルタの末尾

生成されるコードの例

<?php
/**
 * 記事下に関連記事を差し込む
 */
add_filter( 'the_content', function ( $content ) {
	// 単一記事ページの本文のみを対象にする
	if ( ! is_singular( 'post' ) || ! in_the_loop() || ! is_main_query() ) {
		return $content;
	}

	$categories = get_the_category();
	if ( empty( $categories ) ) {
		return $content;
	}

	$related = new WP_Query( [
		'category__in'        => wp_list_pluck( $categories, 'term_id' ),
		'post__not_in'        => [ get_the_ID() ],
		'posts_per_page'      => 3,
		'orderby'             => 'date',
		'order'               => 'DESC',
		'ignore_sticky_posts' => true,
		'no_found_rows'       => true,   // ページ送り不要なので高速化
	] );

	if ( ! $related->have_posts() ) {
		return $content;
	}

	ob_start();
	include get_stylesheet_directory() . '/parts/related-posts.php';
	$html = ob_get_clean();

	wp_reset_postdata();

	return $content . $html;
} );
<?php
/**
 * 関連記事の表示部分
 * @var WP_Query $related
 */
?>
<aside class="related-posts" aria-labelledby="related-heading">
	<h2 id="related-heading" class="related-posts__title">関連記事</h2>
	<ul class="related-posts__list">
		<?php while ( $related->have_posts() ) : $related->the_post(); ?>
			<li class="related-posts__item">
				<a href="<?php the_permalink(); ?>">
					<?php if ( has_post_thumbnail() ) : ?>
						<?php the_post_thumbnail( 'medium', [
							'class'   => 'related-posts__img',
							'loading' => 'lazy',
						] ); ?>
					<?php endif; ?>
					<span class="related-posts__name"><?php the_title(); ?></span>
					<time datetime="<?php echo esc_attr( get_the_date( 'c' ) ); ?>">
						<?php echo esc_html( get_the_date() ); ?>
					</time>
				</a>
			</li>
		<?php endwhile; ?>
	</ul>
</aside>

注目したいのがis_main_query()in_the_loop()の判定です。これが無いと、抜粋やウィジェットの中でも関連記事が出てしまいます。指示に含めなくても入ることが多いですが、必ず確認してください。

変更前に影響範囲を確認させる

コードを書かせる前に、既存への影響を説明させます。これで事故が大きく減ります。

このコードを追加する前に、次を確認して報告してください。

1. 既存のfunctions.phpに the_content フィルタを使っている箇所はあるか
2. あるなら、実行順序で競合しないか
3. 追加するCSSのクラス名が、既存のスタイルと衝突しないか
4. この変更で影響を受けるページの種類(記事・固定ページ・一覧など)
5. 元に戻す手順

確認結果を先に見せてください。コードの追加はその後で判断します。

既存サイトの改修では、この確認が特に効きます。他のフィルタと優先度が重なっていて表示順がおかしくなる、といった問題を事前に潰せます。

エラーが出たときの切り分け

エラー時の切り分け

PHPのエラーで画面が真っ白になった場合の対処です。慌てず順番に確認します。

<?php
/** エラー内容をログに出す(本番では表示しない) */
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
# 構文エラーの有無を確認する
php -l wp-content/themes/parent-theme-child/functions.php

# エラーログの末尾を見る
tail -n 30 wp-content/debug.log
以下のエラーが出ました。原因と修正方法を教えてください。

【エラーログ】
(debug.log の該当部分を貼る)

【直前に行った変更】
(追加したコードを貼る)

条件:
- 推測が複数ある場合は、確認方法とセットで挙げてください
- 修正は最小限の変更に留めてください

エラーログをそのまま渡すのが最短です。「動きません」だけでは原因を特定できません。ログ・変更内容・環境の3点を揃えて渡してください。

本番へ反映する手順

ローカルで確認できたら本番へ反映します。この工程は人間が行います。

1. 本番のバックアップを取る(ファイル+データベース)
2. 変更したファイルだけを転送する(functions.php / parts/ / style.css)
3. 表示を確認する(記事・固定ページ・一覧・404)
4. エラーログを確認する
5. 問題があれば、バックアップから該当ファイルを戻す

FTPソフトを開いたまま作業するのがコツです。何かあれば即座に元のファイルを上書きして戻せます。

確認するページ見るポイント
記事ページ関連記事が正しく出るか
固定ページ余計な表示が出ていないか
カテゴリ一覧抜粋に混入していないか
記事が1件だけのカテゴリ何も出ないか(エラーにならないか)
スマホ表示レイアウトが崩れていないか

AIに任せてはいけない範囲

できる・できないではなく、任せるべきでない領域があります。

  • 本番環境での直接操作:取り返しがつかない。必ず人間が実行する
  • データベースの一括更新:SQLの実行は影響範囲が読みにくい
  • 認証・決済に関わる処理:セキュリティ上、自作しない領域
  • プラグインの一括更新・削除:依存関係の確認が必要
  • 顧客データを含む作業:個人情報を外部サービスに渡さない

特に最後は重要です。エラーログや設定ファイルを貼るときは、メールアドレス・APIキー・DBのパスワードが含まれていないかを必ず確認してください。

# 機密情報が含まれていないかチェックしてから貼る
grep -iE "password|api_key|secret|token|@.*\.(com|jp)" debug.log | head

セキュリティ上の注意点

公開前に見る5観点

生成されたコードをそのまま使う前に、最低限の観点を確認します。

観点確認すること使う関数の例
出力のエスケープ変数をそのまま出していないかesc_html / esc_url
入力の検証受け取った値を検証しているかsanitize_text_field
権限の確認誰でも実行できないかcurrent_user_can
nonceフォーム送信を検証しているかwp_verify_nonce
SQLの組み立て変数を直接埋めていないか$wpdb->prepare
<?php
// 危険:エスケープなしで出力している
echo '<a href="' . $url . '">' . $title . '</a>';

// 安全:用途に応じたエスケープを通す
printf(
	'<a href="%s">%s</a>',
	esc_url( $url ),
	esc_html( $title )
);

AIが生成するコードはエスケープを含むことが多いですが、必ずしも完全ではありません。公開前にこの5観点で目視確認してください。

チームで使うときのルール

複数人で運用する場合、決めておくべき事項を挙げます。

項目決めること
作業環境ローカル必須か、共有ステージングか
レビュー本番反映前に誰が確認するか
履歴変更内容をどこに記録するか
禁止事項本番での直接編集・DB操作の可否
機密情報ログや設定を貼る際のマスキング手順

最低限、本番での直接編集は禁止変更はGitに残すの2つだけでも決めておくと、事故の大半は防げます。

改修例をもう2つ

依頼の粒度をつかむために、よくある改修を2つ挙げます。要件の書き方が結果を左右します。

例1:投稿一覧に文字数を表示する

管理画面の投稿一覧に「文字数」の列を追加してください。

要件:
- 本文からタグを除いた文字数を表示する
- タイトルの右隣に配置する
- 並べ替えは不要
- 表示は投稿(post)のみ。固定ページには出さない

制約:
- 一覧の表示速度を落とさないこと
- 既存の列を削除しない
<?php
// 列を追加する
add_filter( 'manage_posts_columns', function ( $columns ) {
	$new = [];
	foreach ( $columns as $key => $label ) {
		$new[ $key ] = $label;
		if ( 'title' === $key ) {
			$new['char_count'] = '文字数';
		}
	}
	return $new;
} );

// 値を出力する
add_action( 'manage_posts_custom_column', function ( $column, $post_id ) {
	if ( 'char_count' !== $column ) {
		return;
	}
	$content = get_post_field( 'post_content', $post_id );
	$text    = wp_strip_all_tags( strip_shortcodes( $content ) );
	echo esc_html( number_format( mb_strlen( $text ) ) );
}, 10, 2 );

編集部で記事の分量を管理したいときに便利です。タグとショートコードを除いてから数える指定を入れないと、実際より多い数字が出ます。

例2:特定カテゴリだけ表示件数を変える

「お知らせ」カテゴリの一覧ページだけ、表示件数を20件にしてください。
他のカテゴリと検索結果は既存のまま(10件)にします。

制約:
- pre_get_posts を使う
- 管理画面には影響させない
- メインクエリのみを対象にする
<?php
add_action( 'pre_get_posts', function ( $query ) {
	// 管理画面・サブクエリは対象外
	if ( is_admin() || ! $query->is_main_query() ) {
		return;
	}

	if ( $query->is_category( 'news' ) ) {
		$query->set( 'posts_per_page', 20 );
	}
} );

is_admin()is_main_query()の2行が事故を防ぐ決まり文句です。これが無いと管理画面の一覧まで20件になり、意図しない挙動になります。

改修内容使うフック難易度
一覧の件数を変えるpre_get_posts
本文の前後に要素を足すthe_content
headに要素を追加wp_head
管理画面の列を追加manage_posts_columns
保存時に処理を挟むsave_post
REST APIを拡張register_rest_route

プロンプトの型

依頼文の構造を固定しておくと、毎回の品質が安定します。5要素で書きます。

【目的】何のためにやるか(読者・運用上の理由)
【要件】実現したい挙動を箇条書きで
【制約】使ってよい手段・使ってはいけない手段
【対象】編集してよいファイル
【確認】完了時に何を確認すればよいか

特に制約が効きます。「プラグインを使わない」「クエリは1回」といった条件を書かないと、手軽な代わりに重い実装が返ってくることがあります。

  • 目的を書くと、要件の解釈がずれたときに正しい方向へ寄る
  • 対象ファイルを限定すると、想定外の場所を編集されない
  • 確認方法を書かせると、自分でテストする手間が減る
  • 1回の依頼で1つの機能に絞る。複数同時は切り分けが困難になる

既存サイトの調査に使う

新しい機能を足すより先に、引き継いだサイトの中身を把握したい場面があります。この用途はAIが特に役立ちます。

何が動いているかを一覧化する

この子テーマのfunctions.phpを読んで、次を表にしてください。

| 追加している機能 | 使っているフック | 影響範囲 | 削除した場合の影響 |

条件:
- 推測が入る場合は「要確認」と明記する
- 明らかに不要と判断できるものがあれば理由とともに挙げる

引き継ぎ案件では、誰が何のために書いたか分からないコードが残っていることがよくあります。まず棚卸しをしてから改修に入ると、余計な事故を避けられます。

使われていないCSSを探す

# style.cssのクラス名が、テンプレート内で使われているか調べる
grep -oE '^\.[a-zA-Z0-9_-]+' style.css | sort -u | while read cls; do
  name="${cls#.}"
  hits=$(grep -rl "$name" ../ --include="*.php" --include="*.html" | wc -l)
  [ "$hits" -eq 0 ] && echo "未使用の可能性: $cls"
done

機械的な判定なので、JavaScriptで動的に付与しているクラスは検出できません。候補を出したうえで、人間が最終判断してください。

表示速度のボトルネックを探す

このテーマのテンプレートを読んで、表示速度に影響しそうな箇所を挙げてください。

観点:
1. ループ内でクエリを発行している箇所
2. 毎回外部APIを呼んでいる箇所
3. 画像のサイズ指定が無い箇所
4. 条件分岐なしで全ページに読み込んでいるファイル

出力:該当箇所(ファイル名と行番号)→ 問題 → 改善の方向性
よくある問題症状対処の方向
ループ内のクエリ記事数に比例して遅くなる事前に一括取得する
外部APIの同期呼び出しTTFBが伸びるキャッシュを挟む
全ページで全JSを読込不要な通信が増える条件分岐で絞る
画像サイズ未指定CLSが悪化する属性を追加する

1つ目のループ内クエリは、記事が増えてから顕在化します。公開直後は問題なくても、数百記事になった時点で表示が重くなる典型例です。

バージョン管理と履歴の残し方

AIと作業すると変更のスピードが上がるぶん、何をいつ変えたかを見失いがちです。記録の型を決めておきます。

# 機能単位でコミットする
git add functions.php parts/related-posts.php style.css
git commit -m "記事下に関連記事を追加(同カテゴリ3件・the_contentフィルタ)"

# 本番反映した時点にタグを打つ
git tag -a deploy-20260901 -m "本番反映:関連記事機能"

# 問題があれば直前の状態へ戻す
git revert HEAD
  • 1コミット1機能。まとめてコミットすると切り戻せない
  • コミットメッセージに「何を・どのフックで」を書く
  • 本番反映のタイミングでタグを打つ
  • AIが生成したコードであることは記録しなくてよい。動作と意図が分かれば十分

この習慣があると、半年後に「この処理は何のためにあるのか」を追えます。引き継ぎの際にも、コミット履歴がそのまま説明資料になります。


まとめ

Claude CodeのようなAIツールでWordPressを改修する場合、鍵になるのは環境の準備です。ローカル環境・子テーマ・Gitの3点を先に揃えれば、壊しても戻せる状態で作業できます。指示を出す際は環境と制約を最初に共有し、コードを書かせる前に既存への影響を説明させると事故が減ります。エラーが出たらログ・変更内容・環境をセットで渡すのが最短の解決策です。本番への反映とデータベース操作は人間が担当し、生成コードはエスケープと権限確認の観点で必ず目視レビューしてください。

よくある質問(FAQ)

プログラミングが分からなくても使えますか?

簡単なCSSの調整なら可能ですが、functions.phpの編集は推奨しません。生成されたコードが正しいかを判断できないと、問題が起きたときに対処できないためです。まずローカル環境と子テーマを用意し、壊しても戻せる状態で少しずつ試してください。

本番環境で直接作業させてもいいですか?

避けてください。PHPの記述ミス1つでサイト全体が表示されなくなります。ローカル環境で動作を確認し、ファイルの転送と表示確認は人間が行うのが安全です。どうしても本番で作業する場合は、事前にファイルとデータベースのバックアップを取ってください。

エラーログを貼っても大丈夫ですか?

貼る前に内容を確認してください。ログにはファイルパスのほか、状況によってメールアドレスやAPIキーが含まれることがあります。必要な行だけを抜き出し、機密情報が含まれる場合は伏せ字にしてから渡してください。

生成されたコードはそのまま使えますか?

動作はしますが、公開前に確認が必要です。特に、変数の出力にエスケープ処理があるか、実行権限の確認があるか、フォーム送信にnonce検証があるかの3点は必ず目視してください。動くことと安全であることは別の問題です。

既存のプラグインと競合しませんか?

可能性はあります。コードを追加する前に、同じフックを使っている箇所がないかをAIに確認させてください。特にthe_contentのような頻繁に使われるフィルタは、実行順序によって表示が変わります。追加後は主要なページを一通り確認するのが確実です。

あわせて読みたい関連記事

AI時代の学習ロードマップ

AIを前提にした学習の進め方を、順序立てて解説した記事を用意しています。何をどの順で学ぶか迷ったときの地図としてどうぞ。

AIスキルで、未来の自分をアップデート!

今なら完全無料でAIを学べる!WithAI

今なら完全無料でAIを学べる!

  • 動画や実践で楽しく学べる:初心者でも安心のカリキュラム
  • スマホ・PCどちらでもOK:好きな時間に学習できる
  • 料金は一切ナシ0円でAIスキルが身につく

目的に合わせて選べる「AI副業」「AI転職」「AI活用」の3コースを用意。副収入・キャリアチェンジ・日常の生産性アップまで、あなたのゴールに合わせてAIを学べます。

会員登録はカンタン30秒で完了します。まずは公式LINEから、無料でAI学習をスタートしましょう!

この記事を書いた人

WithCodeでWeb制作を習得後、フリーランスエンジニアとして活動。HTML/CSS・JavaScript・WordPress案件を中心に年間20件以上の制作実績を持つ。「難しい技術をわかりやすく」をモットーに、初心者〜中級者向けの技術記事を執筆。副業・フリーランス独立を目指す方に向けた情報発信に注力している。

– service –WithGroupの運営サービス

  • WithCode
    - ウィズコード -

    スクール

    「未経験」から
    現場で通用する
    スキルを身に付けよう!

    詳細はこちら
  • WithFree
    - ウィズフリ -

    実案件サポート

    制作会社のサポート下で
    実務経験を積んでいこう!

    詳細はこちら
  • WithCareer
    - ウィズキャリ -

    就転職サポート

    大手エージェントのサポート下で
    キャリアアップを目指そう!

    詳細はこちら

公式サイト より
今すぐ
無料カウンセリング
予約!

目次