WordPressをAIで運用する｜10年分の記事はどうなったか

WordPressをAIで運用するようになって、私のブログは一変しました。記事の投稿も、固定ページの修正も、画像の圧縮も、いまは店のパソコンに住んでいるAI（Claude）が、WordPressとサーバーの両方を直接さわって片づけています。

そしてついに、10年ほど使ってきたテーマ「STORK19」とお別れしました。壊れたわけではありません。いいテーマでした。ただ、AIと組ませると、どうにも話が噛み合わなかった。今日はそのあたりを、自作したテーマの中身まで含めて書いていきます。ちなみにこの記事も、AIが書いています。

WordPressをAIで運用するしくみ｜つないだのは4本の線

やったことを並べると、意外と地味です。すごいAIを1体入れたのではなく、AIが手を伸ばせる先を1本ずつ増やしていきました。いまつながっている線は、この4本です。

• WordPressのプラグイン「AI Engine」経由で、投稿・固定ページ・タグ・カスタムフィールドを操作する
• SSHでエックスサーバーに直接入り、画像の圧縮やファイルの操作をする
• Google AnalyticsとSearch ConsoleをMCPでつなぎ、記事ごとの検索の数字を読む
• 日々のネタ集めに使っている収集ツールとつなぎ、書く話題を拾う

4本目が地味に効いています。集めたネタの中から、うちのブログでまだ書いていない話題や、店の経験で上乗せできる話題をAIが拾ってくる。朝いちばんに「今日は何を書こう」から始めなくてよくなりました。

用語：MCPとは、AIが外部のサービスやデータに接続して、読んだり操作したりするための共通の規格です。コンセントの形が決まっているからどの家電でも挿せる、というのに近いイメージで、WordPressやSearch Consoleなど、つなぐ先ごとに専用の仕組みを作らずに済みます。

3本目の線のおかげで、公開した記事の答え合わせもAIがやります。タイトルが検索の結果で弱い記事、表示はされているのにクリックされない記事を見つけて、リライトの案まで出してくる。書いて終わりだった記事に、はじめて通知表が付くようになりました。

WordPress本体に入ってきたAI機能と、外部のAIをつなぐときの注意点は、以前まとめています。

便利なのは間違いありません。ただ、線を増やすほど、AIが触れる範囲も広がっていきます。

10年使ったSTORK19をやめたのは、AIが迷うからだった

STORK19は、10年ほど付き合ってきたテーマです。デザインは好きでしたし、いまも悪いテーマだとは思っていません。問題はテーマではなく、私とAIのあいだにありました。

旧テーマ時代の記事は、見出しも吹き出しも相談ボタンも、HTMLとCSSを記事ごとに手で書いて作っていました。人間が書くならそれで回ります。ところがAIに書かせると、毎回その装飾を一から再現しようとして、色がずれる、幅がはみ出す、相談ボタンが記事の中に何か所も散らばる。AIは悪くない。渡した地図が複雑すぎたんです。

項目	STORK19時代	自作テーマ
見出し・箱の装飾	記事ごとにHTMLとCSSで手書き	テーマの部品を選ぶだけ
目次	記事ごとに手作り	見出しから自動で作る
相談ボタン	本文に手書き（複数か所）	本文の下に1つだけ自動
著者の紹介	記事ごとに貼る	プロフィールから自動
構造化データ	記事ごとに書く	テーマがまとめて出す

表の右の列を見ると分かるとおり、テーマを作り直した狙いは「AIに書かせる量を減らすこと」でした。書く量が減れば、間違える場所も減る。私がやりたかったのは、AIが迷わず歩ける道を先に敷いておくことです。以下、これを「AIの通り道」と呼びます。

ここ、見落としがちです：AIを入れるためにテーマを替える必要は、本来ありません。いまのテーマのままでもAIで投稿はできます。ただ、装飾を記事ごとに手書きするタイプのテーマだと、AIの出力が崩れたときの手直しがすべて人間に返ってきます。替えるかどうかは、その手直しにかかっている時間で判断するのが損をしない考え方です。

私の場合は、その手直しの時間がテーマを作り直す手間を上回りました。それだけの話です。

ここまで書くと、必ず聞かれることがあります。「じゃあ、10年分の記事はどうなったの？」。当店の公開記事は3,561本、いちばん古いものは2014年6月のものです。12年分を道連れにするなら、そもそもテーマなど替えられません。

答えは拍子抜けするほど単純で、1本も変換していません。新しいテーマの側に、古い書き方をそのまま読み取って今の見た目で描き直す層を用意しました。記事の中身は10年前のまま、見た目だけが新しくなっています。

用語：互換レイヤーとは、古い形式のデータを、新しい仕組みの側で読み替えて動かすための層のことです。差し込み口の形が変わったときに変換アダプターを挟むのと同じで、元のものには手を加えません。

この層のおかげで、いまも公開記事の54%にあたる1,934本が、旧テーマ時代の書き方のまま動いています。数えるまでは「もっと少ないはず」と思っていました。半分以上でした。

もちろん、全部を新しい書き方に変換するという手もありました。選ばなかったのは、3,561本を機械で書き換えるというのが、3,561回失敗する機会を作ることでもあるからです。本文に手を入れれば、崩れても誰も気づかない記事が必ず出ます。触らずに済むなら触らない。それがいちばん安全でした。

実際の切り替えは、この順で進めました。現状の監査を始めたのが2026年9月12日、本番を切り替えたのが9月15日の午前10時33分です。

1. どの記事が、どの古い書き方を使っているのかを全件数える（2026年9月12日）
2. 本番と同じ構成の環境を手元に作り、本番のデータを入れて表示を確かめる
3. 元に戻せる状態を先に用意してから、本番を切り替える（2026年9月15日）

監査から中3日です。急いだように見えますが、日程を詰められたのは2番目に時間をかけたからでした。テーマを替える工事で怖いのは、新しい部分ではありません。古い部分が黙って壊れることです。

自作テーマの中身｜AIに「書かせないもの」を決めた

自作したテーマは「PICICO Original Theme」と、機能をまとめたプラグイン「picico-core」の2つでできています。設計でいちばん時間をかけたのは、何を作るかより、何をAIに書かせないかの線引きでした。

つまりAIは、本文の中身だけを考えればいい。補足の箱も吹き出しもテーマの部品として用意してあり、AIは「ここは警告の箱」「ここは吹き出し」と部品の名前を選ぶだけです。AIの通り道の正体は、この部品の棚でした。

ただ、ここで一度つまずいています。最初に作ったAI向けの指示書は、「これを書くな」の一覧でした。手書きの相談ボタン禁止、色の指定禁止、自作のHTML禁止。AIはそれを完璧に守りました。そして出てきたのは、禁止事項をひとつも破っていないのに、吹き出しも補足の箱もゼロの、驚くほど素っ気ない記事でした。

考えてみれば当然です。「やってはいけないこと」しか書いていない指示書なら、何もしないのがいちばん安全なんですよね。禁止だけの指示は、AIを臆病にします。そこで指示書を作り直し、「大見出し1つにつき、箱か吹き出しを最低1つ置く」という下限を義務にしました。装飾は飾りではなく、読者が迷う場所に置く道しるべ、という位置づけです。

怒られないことを最優先にした新人が何もしなくなるのと、構図はまったく同じで……と、AIの指示書の話から新人教育論を語り始めるのは完全に脱線なので、戻ります。

権限を渡すだけでは回らない｜AIに持たせた5つの道具

テーマができて、AIの通り道も敷けた。これで回り始めたかというと、まだでした。足りなかったのは権限ではなく、道具のほうです。

気づいたきっかけは、我ながらひどい数字でした。2026年9月18日の1日で、その場かぎりの検査スクリプトを51本書かせています。記事が仕様どおりか、サイトが壊れていないか。同じことを確かめるのに、毎回ゼロから書き直していました。

つまり、間違いの発見が「目視」と「偶然」に頼っていたということです。実際、消したはずのプラグインのショートコードが本文に文字のまま残っている記事が、4本見つかりました。全記事の本文を総当たりして、ようやくです。読者にはずっと見えていました。

使い捨てをやめて、常設にした5つ

そこで、使い捨てをやめました。明日も同じ点検をするなら、それは道具にしたほうがいい。いま常設にしてあるのは、この5つです。

道具	やること
記事の検査	書いた記事が仕様どおりかを機械で判定する
サイトの健康診断	サイト全体を40ほどの項目で点検する
反映の道具	本番へ反映する手順そのものを一続きにする
記録の道具	エラーと、見つからなかったページの記録を残す
一括変更の道具	計画・承認・適用・取り消しの型で変える

記事の検査は、タイトルの字数、見出しの順番、内部リンクが生きているかまで見ます。この記事も、書き上げてから同じ検査にかけました。健康診断は40ほどの項目があり、表示の裏で出ているエラー、一覧ページで読み込む必要のない部品、転送の設定が全部つながっているか、といった項目が並んでいます。

反映の道具は、引数を付けずに走らせると差分を見せるだけで止まります。実行すると、退避から転送、再確認、健康診断までが一続きになる。手順を覚えている人間が要らなくなったのは、この道具からでした。

AIは、見えないものを直せない

5つのうち、この4番目だけは作った理由が違います。便利だから作ったのでは、ありませんでした。

切り替えのあと、エラーが出ていないかを調べようとして、手が止まりました。エラーの記録も、閲覧の記録も、1行も残っていなかったのです。共用のサーバーではよくある話ですが、調べる手段が無いことに、調べようとして初めて気づきました。

AIは、見えないものを直せません。権限より先に必要なのは「目」のほうでした。というわけで、記録を残す仕組みそのものを作らせています。

効き目はすぐに出ました。もう存在しない予約ページの古いアドレスに、2026年に書いた記事3本がリンクしたままになっていたのです。今までなら、全記事の本文を総当たりしない限り見つかりませんでした。いまは、行き止まりに当たった人がいれば記録に残ります。

3,500本を一度に変えないための型

5番目の一括変更の道具は、いちばん慎重に作りました。単純に、怖いからです。計画を立て、承認をもらい、適用し、いつでも取り消せる。この4段階の型に押し込みました。

• 計画は下見だけ。対象の一覧を出すところまでで、データベースには何も書かない
• 適用には私の承認の言葉が要る。AIの判断だけでは動かない
• 変える前に、対象の本文を全部退避する
• 記事の更新日は変えない

この型で、今日は2件やりました。いまはもう使われていないトラックバックの受付が481本で開いたままだったので、これを閉じたのが1件。本文の先頭に、記事タイトルと同じ見出しが二重に置かれていた385本から、その1行を消したのが1件です。どちらも見た目は変わりません。昔の自分の書き癖の後始末でした。

そして、ここがいちばん細かくて、いちばん効いた点です。この道具は、記事の更新日を変えません。3,000本の更新日が一斉に今日の日付になると、検索エンジンに渡すサイトマップの更新日と、「2年以上更新していない記事」の絞り込みが、同時に壊れます。その1点のために、普通の更新処理を使わない作りにしてあります。

確かめ方も決めました。適用の前と後で、全記事の本文から指紋のような短い符号を作り、変わったのが対象の385本だけであることを突き合わせます。元の本文は履歴に残るので、気に入らなければ編集画面から私が自分で戻せます。

使い捨てを51本書かせて、やっと分かったのがこれでした。AIに仕事を任せるというのは、判断を預けることではなく、確かめ方を先に作っておくことです。

全部AIが書くブログ運用の落とし穴は？

ここまで良い話ばかりでしたが、困ったことも当然あります。ひとつ目は、AIの提案をそのまま採用したこと。2026年9月17日、出てきた改善策を2つ採用して、2つとも実測で否定されました。

1つ目の案は「あと一歩で検索結果の1ページ目に届く記事を直す」。理屈は通っています。ところが該当した113件を開いてみると、マウスの寿命だのゲームだのの雑記ばかりで、手を入れても修理の相談にはつながりませんでした。

2つ目は「同じ検索語で自分の記事どうしがぶつかっているのを整理する」。こちらも教科書どおりです。ぶつかっていた語をたどってみたら、正体は順位チェックツールの自動アクセスでした。整理すべき実害が、そもそも存在していません。

メモ：検索の管理画面に出てくる数字には、人の検索ではないアクセスが混ざることがあります。順位チェックツールの巡回がその代表で、表示回数だけが妙に多いのにクリックが0のままの語は、これを疑うと説明がつくことがあります。

2つに共通していた原因は、ひとつです。データを見る前に提案したこと。一般論として正しい施策でも、このサイトに当てはまるとは限りません。

AIは、聞けば必ず何か答えます。答えない、という選択をしてくれません。だから「一般論として正しいこと」を、まるでこのサイトの事実であるかのように差し出してきます。止められるのは、数字を持っている人間のほうだけです。

対策として、効果を測る手立てのほうを先に作りました。検索の数字を毎月自動で集めておいて、何かやったら翌月それで答え合わせをする。提案の前に、そのサイトの実データで裏を取る。順番を入れ替えただけです。

ふたつ目は、AIに何でもできるわけではないこと。サイトのタグを棚卸ししたとき、記事の数より多い5,290個のタグがあり、5回以上使われているのは440個だけでした。表記ゆれをまとめる作業はAIが一気に片づけたのに、不要なタグを消す段階で、削除の操作だけが権限で止められました。最後の削除は、管理画面から手作業です。

みっつ目は、AIが操作した結果を人間が確かめないと、たまに状態がずれること。予約投稿にしていた記事の本文をAIが直したら、記事の公開状態が意図と違うものになっていたことがありました。いまは「AIが何かを更新したら、必ず読み戻して確認する」を運用のルールにしています。

注意：AIにサーバーやWordPressの操作権限を渡すなら、先にバックアップを取れる状態を作ってください。AIは指示どおりに素早く動くぶん、間違った指示も同じ速さで実行します。上書きしたファイルや消したデータは、元に戻せないことがあります。

よっつ目がいちばん大事で、AIは店頭で起きたことを知りません。たとえば「Macのデータ移行は店頭で1〜2時間、中身の量によっては半日仕事」という数字は、私が伝えない限り記事に入りません。AIが書く記事の差は、結局のところ人間がどれだけ一次情報を渡したかで決まります。

AIに任せきりにしたときに何が起きるかは、ラジオ局の実験をもとに以前書きました。

同じような仕組みを自分の仕事に入れたい方向けに、店では事業者向けのAI業務自動化サポートもやっています。

よくある質問

WordPressの記事をAIに書かせても検索で評価されますか？

書き手がAIかどうかより、読者の役に立つ独自の情報があるかどうかで評価されます。Googleも、AIを使って作ったこと自体ではなく、内容の質を見ると説明しています。どこにでも書いてある情報をまとめただけの記事は、AIが書いても人が書いても埋もれます。

今のWordPressテーマのままでもAIで記事を投稿できますか？

投稿自体はできます。ただ、見出しや箱の装飾を記事ごとにHTMLで手書きするタイプのテーマだと、AIがその装飾を毎回再現する必要があり、崩れたときの手直しが増えます。装飾をテーマ側の部品として選べる環境のほうが、AIとの相性は良くなります。

テーマを替えたら、過去の記事は全部作り直しになりますか？

必ずしも作り直しにはなりません。当店は公開記事3,561本のうち、1本も本文を変換していません。新しいテーマの側に、古い書き方を読み取って描き直すしくみを用意すれば、記事はそのままで見た目だけを新しくできます。本文を書き換えるほうが、崩れても気づけない記事が出るぶん危険です。

AIにサーバーの操作まで任せても大丈夫ですか？

渡す権限の範囲と、バックアップの有無しだいです。読む権限から始めて、書き込みや削除は人間の確認を挟めるようにしておくと事故を防げます。当店の環境でも、削除の操作が権限で止められた場面がありました。

まとめ｜AIの通り道を敷いたら、ブログが回り始めた

WordPressをAIで運用して分かったのは、AIの賢さより、AIの通り道のほうが結果を左右するということでした。10年使ったテーマを手放したのも、4本の線を1本ずつつないだのも、全部その通り道を敷くための工事です。

同じことを試してみたい方のために、やってよかった順番を5つだけ書いておきます。上から順にやると、たぶん事故が減ります。

1. 読む権限から渡す。書き込みと削除は、慣れてからでいい
2. ルールを1枚のファイルに書き、AIが毎回最初に読む場所に置く。「なぜそうするか」も書く。理由の無いルールは、破られるか、逆に守りすぎて何もしなくなる
3. 使い捨ての点検スクリプトを書かせない。明日も同じ点検をするなら、常設の道具にする
4. 一括変更は「計画・承認・取り消し」の型で行う。元に戻せない変更をさせない
5. 測ってから動く。効果を確かめる手立てを、施策より先に作る

記事を書くのはAI。店頭で見たことを渡すのは私。この分担に落ち着いてから、ブログは毎日の店の仕事の延長で回るようになりました。AIをお店の仕事にどう入れるか迷っている方は、店頭でも気軽に話しかけてください。