目次
結論：WordPressこそAIに触らせる前に線を引く
Claude CodeでWordPressを触りたい、という相談が出てきます。
できます。ただし他のどんなサイトより慎重にやってください。
ファイルを1行間違えるだけで、サイト全体が「このサイトで重大なエラーが発生しました」の画面に置き換わります（環境によっては真っ白になります）。
静的なサイトなら「そのページだけ崩れる」で済むところが、全体停止になります。
ただし救いもあります。WordPress 5.2以降には「リカバリーモード」があり、管理者のメールアドレスに復旧用のリンクが自動で届きます。問題のテーマやプラグインを止めた状態で管理画面に入れるので、まずはメールを確認してください。
この記事では、実際にWordPressのサイトを複数運用している立場から、任せてよい範囲と、絶対に触らせない範囲を書きます。
最初に立場を明かします
書いている側の立場を先に示しておきます。ここを隠すと、話が偏って見えるからです。
| 使っているもの | |
|---|---|
| 代表が個人で運営しているサイト | 20個ほど。うち6割がWordPress |
| 自社サイトの運営 | 静的HTML |
| お客様に制作するホームページ | すべて静的HTML（WordPressは使わない） |
矛盾しているように見えると思います。
理由は単純で、自分で管理するなら手になじんだWordPressが速く、お客様に渡すなら壊れにくい静的HTMLが安心だからです。用途で道具を変えているだけです。
弊社は制作会社ですが、「静的HTMLに乗り換えましょう」とは言いません。
WordPressは見やすく、管理が楽で、何より不具合が起きたときにネット上に情報が多い。これは実務でかなり効きます。
確かにプラグインやログイン周りにセキュリティの穴はありますし、表示の速さでも劣ります。それでも、今うまく回っているものを壊してまで乗り換える理由にはなりません。
つまりこの記事は「WordPressをやめて静的HTMLにしましょう」という話ではありません。
書いている本人が、WordPressのサイトを12個ほど動かしています。その上で、AIに触らせるときの注意点を書きます。
100点を求めるなら静的HTML、80点でよいならWordPress
どちらを選ぶかで迷っている方のために、判断の軸だけ先に書いておきます。
| あなたの状況 | おすすめ | 理由 |
|---|---|---|
| WordPressも静的HTMLも触ったことがない | WordPress | いきなり静的HTMLから入るのは重い。情報も多く、詰まりにくい |
| すでにWordPressなどでサイトに慣れている | どちらでも | 新しく作るなら静的HTMLでもよい |
| プロに依頼して作ってもらう | 静的HTML | 更新の面倒を制作側が引き受けるなら、静的のほうが絶対によい |
| すでにWordPressで問題なく回っている | そのまま | 乗り換える理由がない |
考え方としては、この一文に尽きます。
デザイン、セキュリティ、表示の速さ、SEO。この4つで100点を取りにいくなら静的HTMLです。
一方、使いやすい上に80点を簡単に取れるのがWordPressです。
80点で足りる場面のほうが、実際には多いと思います。
もうひとつ、静的HTMLを選ぶ場合の前提があります。
専門職の方でない限り、更新や管理にはコーディングができるAIが必須レベルです。管理画面がないぶん、ファイルを直接触ることになるためです。
WordPressがAIにとって難しい理由
Claude CodeがWordPressを苦手とするわけではありません。
問題は、WordPressというものの作りにあります。
1. 画面に出るものが、ファイルだけで決まらない
静的なサイトなら、ファイルを見れば表示される内容がわかります。
WordPressは違います。記事も設定もデータベースの中にあり、ファイルと合わさって初めて画面ができます。
AIに渡しているのは基本的にファイルだけで、データベースの中身までは見えていません。
「ファイル上は正しいのに、表示が変わらない」ということが起きます。
2. 直したはずが、次の更新で消える
テーマやプラグインのファイルを直接書き換えると、更新のたびに元に戻ります。
AIに「ここを直して」と頼むと、素直に該当ファイルを書き換えることがあります。そのときは直りますが、次の更新で消えます。
3. 失敗すると全体が止まる
冒頭に書いたとおりです。
PHPというプログラムで動いているため、文法をひとつ間違えるとそこで処理が止まります。
壊した場所によりますが、全ページで読み込まれるファイル（functions.php など）を壊すとサイト全体が止まります。個別のページ用のファイルなら、そのページだけで済みます。
4. プラグイン同士がぶつかる
入れているプラグインの組み合わせによって、同じ操作でも結果が変わります。
一般的な手順どおりにやっても、そのサイトでは動かないことがあります。AIはそのサイト固有の事情を知りません。
やらせてよいこと、いけないこと
| 区分 | 内容 | 判定 |
|---|---|---|
| 安全 | 記事の下書きを書かせる | 問題なし |
| 書き出した記事データを分析させる 管理画面の「ツール → エクスポート」でファイルにできます | 問題なし | |
| 子テーマに入れる部品のコードを書かせる | 問題なし（貼るのは人） | |
| エラーの原因を一緒に考えさせる | 問題なし | |
| 条件つき | ローカル環境（自分のパソコン内の複製）で改修させる | 可。本番とは別物として扱う |
| 子テーマのファイルを編集させる | バックアップがあるなら可 | |
| 公式の窓口（REST API）を通じて記事を投稿させる | 可。ただし下書き保存までが安全 | |
| 危険 | 本番サイトのファイルを直接書き換えさせる | やらない |
| データベースを直接操作させる | やらない | |
| 親テーマ・プラグイン本体を編集させる | やらない | |
| 管理画面を自動操作させる | やらない |
危険の欄の1つ目が、いちばん取り返しがつきません。
「本番のファイルをAIに直させる」は、戻す手段を用意しないまま高所作業をするようなものです。
依頼するときの言い方
WordPressの場合、同じ依頼でも言い方で結果が変わります。
安全な言い回しの例を挙げます。
| 危ない言い方 | 安全な言い方 |
|---|---|
| ヘッダーに電話番号を追加して | 子テーマに追加するコードを書いてください。ファイルは変更しないでください |
| この不具合を直して | 原因の候補を挙げてください。直す前に、何をどう変えるか先に説明してください |
| プラグインを整理して | 使っていなさそうなプラグインを一覧にしてください。停止も削除もしないでください |
| 記事を投稿して | 下書きとして保存してください。公開はしないでください |
共通しているのは「作らせるが、反映はさせない」という形です。
コードを書いてもらい、貼るのは自分。一覧を出してもらい、消すのは自分。この一手間で事故がほぼ消えます。
何をするつもりかを言わせてから動かすと、間違った方向に走り出す前に止められます。
WordPressは走り出してから止めるのが難しいので、ここは特に効きます。
安全にやるための3つの準備
この3つが揃っていないなら、本番サイトには触らせないでください。
1. 戻せること
バックアップです。
ファイルとデータベースの両方が必要です。片方だけでは戻りません。
そして戻せることを一度は試しておいてください。
取ってあるつもりで、いざというときに戻せないバックアップは珍しくありません。
2. 本番以外で試せること
自分のパソコンの中に同じものを作るか、テスト用のサイトを用意します。
そこで先に試し、うまくいったものだけ本番に持っていきます。
面倒に見えますが、真っ白になった本番サイトを前にして焦るより、はるかに楽です。
3. 触ってはいけない場所を決めておくこと
Claude Codeには、特定のファイルへの書き込みを拒否する仕組みがあります。
サイトのフォルダに .claude/settings.json というファイルを作り、次のように書いておきます。
{
"permissions": {
"deny": [
"Edit(wp-content/themes/親テーマ名/**)",
"Edit(wp-content/plugins/**)",
"Edit(wp-config.php)"
]
}
}
これで親テーマ・プラグイン本体・設定ファイルには、指示を間違えても書き込めなくなります。
「親テーマ名」の部分は、実際に使っているテーマのフォルダ名に置き換えてください。
指示で「触らないでね」と伝えるだけでは足りません。まず設定で書いておいてください。
拒否ルールが効くのは、AIが直接ファイルを読み書きしようとしたときです。
AIが書いたスクリプト経由の操作や、サーバーへ接続しての操作までは止まりません。
そして何より、この書き方で守れるのは手元のパソコンにあるファイルだけです。本番サーバー上のファイルは、この設定では保護できません。
いちばん確実な線引きは、本番サーバーの接続情報をAIに渡さないことです。
この準備を自分でやるのが不安な場合は、環境ごとお作りすることもできます。
子テーマという言葉が出てきたら
WordPressをAIに触らせる話には、必ず子テーマという言葉が出てきます。
知らないと指示が通らないので、ここだけ押さえてください。
見た目のもとになる「テーマ」の上書き用として作る、別のテーマです。
元のテーマは触らず、変更したい部分だけを子テーマ側に置きます。こうすると元のテーマが更新されても、変更が消えません。
先に書いた「直したはずが次の更新で消える」は、子テーマを使わずに元のテーマを直接書き換えたときに起きます。
「子プラグイン」という仕組みはありません。
プラグイン本体を書き換えた場合は、子テーマにしていても更新で消えます。プラグイン側をどうしても変えたいなら、フックを使うか、自分用の小さなプラグインを別に作る必要があります。
AIに依頼するときは、「子テーマに追加してください。親テーマは触らないでください」と毎回添えてください。
これを言わないと、素直に元のファイルを書き換えることがあります。
真っ白になったときの戻し方
起きてしまった場合に備えて、手順を書いておきます。慌てないことが一番大事です。
- 管理者メールを確認する。リカバリーモードのリンクが届いていれば、そこから管理画面に入って止められます
- 直前に何を変えたか思い出し、その変更を元に戻す。原因は直前の1手であることがほとんどです
- それでも直らなければ、プラグインを一時的に全部止める。サーバーのファイル管理画面で
wp-content/pluginsフォルダの名前をplugins_offに変えるだけで、全部止まります。表示が戻ったら名前を戻し、原因のプラグインを1つずつ探します - それでも駄目なら、使用中のテーマのフォルダ名を変える。
wp-content/themes/の中にTwenty系の標準テーマが入っていることを先に確認してから行ってください。標準テーマがあれば自動で切り替わりますが、無い場合はより深刻なエラーになります - ここまでで直らない場合に、バックアップから戻す
先に「今の壊れた状態」を別名でコピーして残してください。上書きしてしまうと、原因調査もできず、失敗したときに戻る場所も消えます。
そのうえで、まずはファイルだけを戻します。データベースまで戻すと、バックアップを取った後に書いた記事・受け取ったお問い合わせ・注文がすべて消えます。通販サイトや会員サイトは特に注意してください。
3と4は、管理画面が開かない状態でもファイル操作だけでできます。
つまりサーバーのファイルを触る手段を確保しておく必要があります。使っているサーバーの管理画面から操作できるか、契約時に確認しておいてください。
本当に真っ白になってから初めて手順書を読むと、まず間に合いません。
テスト用のサイトでわざと壊して、戻せることを確認しておくのが理想です。1回やっておくだけで、落ち着き方がまるで違います。
実際に使っている場面
以上を踏まえると、任せて効くのはこのあたりです。
| 場面 | やり方 |
|---|---|
| 記事の下書き | 構成から書かせて、人が直して投稿する |
| 複数サイトの棚卸し | 各サイトの記事一覧を書き出して、重複や古い記事を洗い出す |
| エラーの調査 | エラーの文言を渡して、原因の候補を挙げてもらう |
| 部品のコード作成 | 子テーマに貼る短いコードを書かせる。貼るのは人 |
| 設定の説明 | プラグインの設定項目が何をするものか教えてもらう |
共通しているのは、AIが直接サイトを触っていないことです。
考える・書く・調べるところまでを任せ、反映する操作は人がやる。この形が結局いちばん速く、事故もありません。
1サイトなら自分で見て回れます。
サイト数が増えるほど、どこに何を書いたか把握しづらくなります。横断して調べる作業は、AIに任せると一気に楽になります。
静的HTMLとの違い
参考までに、AIに任せるという観点での違いを書いておきます。
| WordPress | 静的HTML | |
|---|---|---|
| AIが状況を把握できるか | データベースが見えず、把握しづらい | ファイルがすべてなので把握しやすい |
| 失敗したときの影響 | サイト全体が止まることがある | 崩れる範囲が見た目に限られ、影響が読みやすい |
| 元に戻す手間 | ファイルとデータベースの両方 | ファイルを戻すだけ |
| 更新で上書きされるか | あり（子テーマで回避） | なし |
| 記事を書く画面の使いやすさ | 専用の編集画面がある | 基本的に無い（別途用意が必要） |
| 機能を後から足せるか | プラグインで足せる | 作り込みが必要 |
| 詳しくない人が更新できるか | 管理画面から更新できる | ファイルを触る必要がある |
上の4行だけを見れば静的HTMLの勝ちですが、下の3行はWordPressの勝ちです。
AIに任せやすいかどうかは判断材料のひとつでしかありません。それだけでWordPressをやめる理由にはなりません。
冒頭に書いたとおり、代表個人のサイトは6割がWordPressのままです。使いやすいから残しています。
静的HTMLにするなら、ダッシュボードを作ってください
最後に、静的HTMLを選ぶ方へのおすすめを1つ書きます。
これはWordPressから移った人ほど、必ずぶつかる問題です。
WordPressには管理画面があり、記事の一覧も、アクセス数も、プラグインの状態も、開けば見えます。
静的HTMLはすべてがコードの中だけで管理されます。何本記事があるのか、どのページが読まれているのか、目で見て確認する場所がありません。
ここが、移った人が一番不便を感じる部分です。
表示は速くなった、セキュリティも安心になった。でも今の状態が分からない。
AIに管理画面を作らせる
そこでおすすめしたいのが、自分用のダッシュボードをAIに作らせることです。
WordPressのプラグインが担っていた役割を、自分で用意してしまう発想です。
| 載せると便利なもの | 解決する不便 |
|---|---|
| 記事の一覧（タイトル・公開日・カテゴリ） | 何本あるか、いつ書いたかが一目で分かる |
| アクセス数（ページごとの表示回数） | どのページが読まれているか分かる |
| リンク切れの一覧 | 移動・削除したページの取りこぼしに気づける |
| 更新が止まっているページ | 古くなった情報を放置しなくなる |
凝ったものにする必要はありません。1枚のページで十分です。
そして、こういうものを作るのはAIが得意な部類の仕事です。「サイト内の記事を全部読んで、タイトルと公開日の一覧ページを作って」と頼めば形になります。
速さもセキュリティも、日々の実感としては伝わってきません。
一方で「今どうなっているか分からない」は、毎日じわじわ効いてきます。ここを埋めておかないと、結局WordPressに戻りたくなります。
よくある質問
Claude CodeでWordPressの記事を自動投稿できますか
公式のAPIを使えば技術的には可能です。
ただし下書き保存までにとどめることをおすすめします。公開まで自動にすると、内容を確認しないまま世に出ます。取り消しても、その間に読まれた分は戻りません。
レンタルサーバーのファイルを直接触らせても大丈夫ですか
おすすめしません。
どうしても必要なら、直前にバックアップを取り、触ってよいフォルダを限定してからにしてください。うまくいったように見えても、後から不具合が出ることがあります。
プラグインで似たことができませんか
記事作成の補助であれば、AI連携のプラグインもあります。
使い分けの目安は、「WordPressの中だけで完結するか」です。中だけならプラグインのほうが手軽で、複数サイトを横断したり手元のファイルと突き合わせたりするならClaude Codeが向きます。
結局、WordPressと静的HTMLはどちらがよいのですか
初心者が自分で作るならWordPress、プロに依頼するなら静的HTML。これが弊社の答えです。
すでにWordPressで問題なく回っているなら、そのままで構いません。乗り換えは目的ではありません。
まとめ
- Claude CodeでWordPressは触れる。ただし壊れると全体が止まるので線引きが要る
- 難しいのはAIの能力ではなく、データベースが見えない・更新で上書きされる・プラグインがぶつかるというWordPressの作り
- 本番のファイル直編集とデータベース操作はやらせない
- 準備は3つ。戻せる・本番以外で試せる・触らせない場所を設定で決める
- 考える・書く・調べるまでを任せ、反映は人がやるのが結局いちばん速い
- 依頼は「作らせるが、反映はさせない」形にする。先に説明させると走り出す前に止められる
- 依頼時は毎回「子テーマに追加、親テーマは触らない」と添える
- 複数サイトの横断作業はAIが特に効く
- 復旧手順は平常時に一度試しておく。本番で初めて読むと間に合わない
- AIに任せやすいのは静的HTMLだが、それだけでWordPressをやめる理由にはならない
- 今WordPressで回っているなら、乗り換えなくてよい。不具合時に情報が多いのは実務で効く
- 完全な初心者はWordPressから。プロに依頼するなら静的HTMLのほうがよい
- 4つ（デザイン・セキュリティ・速さ・SEO）で100点を狙うなら静的HTML、80点を簡単に取るならWordPress
- 静的HTMLにするならダッシュボードをAIに作らせる。これが無いと状況が見えず続かない
道具はどちらか一方に決める必要はありません。
弊社も、お客様のサイトは静的HTMLで作り、代表個人のサイトは6割がWordPressのままです。用途で選べばよいだけです。
そして今動いているものを、わざわざ壊さないでください。
乗り換えを勧める記事は多いですが、うまく回っているWordPressを静的HTMLに作り替えて得られるものは、思っているより小さいです。