



WithCodeMedia-1-pc
WithCodeMedia-2-pc
WithCodeMedia-3-pc
WithCodeMedia-4-pc




WithCodeMedia-1-sp
WithCodeMedia-2-sp
WithCodeMedia-3-sp
WithCodeMedia-4-sp









生徒Claude CodeでWordPressのカスタマイズってできますか? テーマのPHPを触るのが怖くて…
ペン博士できるよ。しかも怖い部分こそAIと相性がいい。子テーマの用意・変更前の確認・エラー時の切り分けを型にしておけば安全に進む。実際の改修を通しで見せるね。
WordPressのカスタマイズで手が止まる理由は、たいてい壊したときに戻せる自信がないことです。functions.phpを1文字間違えるとサイト全体が真っ白になります。
Claude Codeのようなコーディング支援AIは、この領域と相性が良いツールです。既存ファイルを読んで影響範囲を説明させたり、変更前にバックアップを取る手順ごと実行させたりできます。
この記事では、環境の準備から、実際の改修(記事下に関連記事を出す機能の追加)を通しで実演します。あわせて、AIに任せてはいけない範囲と、事故を防ぐ運用ルールも扱います。

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

安全に進めるための前提です。この3つが揃っていないなら、先に用意してください。
# 例:wp-env(WordPress公式のローカル環境)
npm -g install @wordpress/env
mkdir my-wp && cd my-wp
npx wp-env start
# → http://localhost:8888 で起動する本番で直接試さないこと。これが最大の安全策です。ローカル環境なら、壊しても作り直せます。
wp-content/themes/
├── parent-theme/ # 親テーマ(触らない)
└── parent-theme-child/ # ここで作業する
├── style.css
└── functions.php親テーマを直接編集すると、更新のたびに変更が消えます。子テーマを用意してから作業を始めてください。
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件だけのカテゴリ | 何も出ないか(エラーにならないか) |
| スマホ表示 | レイアウトが崩れていないか |
できる・できないではなく、任せるべきでない領域があります。
特に最後は重要です。エラーログや設定ファイルを貼るときは、メールアドレス・APIキー・DBのパスワードが含まれていないかを必ず確認してください。
# 機密情報が含まれていないかチェックしてから貼る
grep -iE "password|api_key|secret|token|@.*\.(com|jp)" debug.log | head
生成されたコードをそのまま使う前に、最低限の観点を確認します。
| 観点 | 確認すること | 使う関数の例 |
|---|---|---|
| 出力のエスケープ | 変数をそのまま出していないか | 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つ挙げます。要件の書き方が結果を左右します。
管理画面の投稿一覧に「文字数」の列を追加してください。
要件:
- 本文からタグを除いた文字数を表示する
- タイトルの右隣に配置する
- 並べ替えは不要
- 表示は投稿(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 );編集部で記事の分量を管理したいときに便利です。タグとショートコードを除いてから数える指定を入れないと、実際より多い数字が出ます。
「お知らせ」カテゴリの一覧ページだけ、表示件数を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回」といった条件を書かないと、手軽な代わりに重い実装が返ってくることがあります。
新しい機能を足すより先に、引き継いだサイトの中身を把握したい場面があります。この用途はAIが特に役立ちます。
この子テーマのfunctions.phpを読んで、次を表にしてください。
| 追加している機能 | 使っているフック | 影響範囲 | 削除した場合の影響 |
条件:
- 推測が入る場合は「要確認」と明記する
- 明らかに不要と判断できるものがあれば理由とともに挙げる引き継ぎ案件では、誰が何のために書いたか分からないコードが残っていることがよくあります。まず棚卸しをしてから改修に入ると、余計な事故を避けられます。
# 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この習慣があると、半年後に「この処理は何のためにあるのか」を追えます。引き継ぎの際にも、コミット履歴がそのまま説明資料になります。
Claude CodeのようなAIツールでWordPressを改修する場合、鍵になるのは環境の準備です。ローカル環境・子テーマ・Gitの3点を先に揃えれば、壊しても戻せる状態で作業できます。指示を出す際は環境と制約を最初に共有し、コードを書かせる前に既存への影響を説明させると事故が減ります。エラーが出たらログ・変更内容・環境をセットで渡すのが最短の解決策です。本番への反映とデータベース操作は人間が担当し、生成コードはエスケープと権限確認の観点で必ず目視レビューしてください。
簡単なCSSの調整なら可能ですが、functions.phpの編集は推奨しません。生成されたコードが正しいかを判断できないと、問題が起きたときに対処できないためです。まずローカル環境と子テーマを用意し、壊しても戻せる状態で少しずつ試してください。
避けてください。PHPの記述ミス1つでサイト全体が表示されなくなります。ローカル環境で動作を確認し、ファイルの転送と表示確認は人間が行うのが安全です。どうしても本番で作業する場合は、事前にファイルとデータベースのバックアップを取ってください。
貼る前に内容を確認してください。ログにはファイルパスのほか、状況によってメールアドレスやAPIキーが含まれることがあります。必要な行だけを抜き出し、機密情報が含まれる場合は伏せ字にしてから渡してください。
動作はしますが、公開前に確認が必要です。特に、変数の出力にエスケープ処理があるか、実行権限の確認があるか、フォーム送信にnonce検証があるかの3点は必ず目視してください。動くことと安全であることは別の問題です。
可能性はあります。コードを追加する前に、同じフックを使っている箇所がないかをAIに確認させてください。特にthe_contentのような頻繁に使われるフィルタは、実行順序によって表示が変わります。追加後は主要なページを一通り確認するのが確実です。
AIを前提にした学習の進め方を、順序立てて解説した記事を用意しています。何をどの順で学ぶか迷ったときの地図としてどうぞ。

目的に合わせて選べる「AI副業」「AI転職」「AI活用」の3コースを用意。副収入・キャリアチェンジ・日常の生産性アップまで、あなたのゴールに合わせてAIを学べます。
会員登録はカンタン30秒で完了します。まずは公式LINEから、無料でAI学習をスタートしましょう!
WithCodeでWeb制作を習得後、フリーランスエンジニアとして活動。HTML/CSS・JavaScript・WordPress案件を中心に年間20件以上の制作実績を持つ。「難しい技術をわかりやすく」をモットーに、初心者〜中級者向けの技術記事を執筆。副業・フリーランス独立を目指す方に向けた情報発信に注力している。
公式サイト より
今すぐ
無料カウンセリング
を予約!