XserverのWordPress運営をAIで効率化｜任せた作業と人が決めたこと

運営しているブログのアイキャッチを、15記事分いっぺんに差し替えました。といっても、WordPressの管理画面はほとんど開いていません。XserverへSSHで接続して、WP-CLIの操作ごとAIに進めてもらったからです。で、一連の作業の最後に自分が見ていたのは、できあがった画像ファイルではなく、各記事の公開ページに出る og:image のほうでした。

画像を作って、アップロードして、投稿のアイキャッチに設定する。そこまで全部通っても、公開ページのOGPが古いままなら、SNSでシェアされたときに前の画像が出てしまう可能性があります。なのでこの作業、「設定した」の時点ではまだ途中で、「反映を確かめた」までいって、ようやく終わります。

この確認を15記事分繰り返すうちに、WordPress運営でAIをどう使うかの線引きが、自分の中ではっきりしてきました。作業を実行できるだけでは足りなくて、実行したあとの状態を再取得して、完了を確認できる作業ほど任せやすいんです。

実行後の状態を再取得できる作業から任せる

下書きの投入、画像の登録、アイキャッチの設定、内部リンク候補の抽出、文章校閲、公開後の確認はAIと相性がよい。記事で何を伝えるか、最終的に公開するかは運営者が決める。

SSHとWP-CLIで15記事のアイキャッチを差し替えた手順

手順は記事ごとに同じで、5工程の繰り返しでした。差し替える前のアイキャッチは、黒い背景に青いネオンを載せたものが多くて、サイト全体が少し暗い印象です。書いているのは経理、AI活用、WordPress運営の話です。業務ブログとして中身が伝わる明るい雰囲気にして、画像だけ見ても記事ごとの違いが分かるデザインへ変えることにしました。このブログのテーマはAIと一緒に自作したJournalで、記事もアイキャッチも同じXserver上で管理しています。

記事ごとにやることは同じで、この繰り返しでした。

記事のタイトルと本文を確認する
記事ごとに方向性を変えて画像を生成する
画像をXserverへ転送する
wp media import でメディアへ登録し、altなどの情報を設定する
_thumbnail_id を更新し、公開ページの og:image まで確認する

これを15記事分、繰り返しました。管理画面から手でやるなら、画像を保存して、メディアへアップロードして、投稿の編集画面で設定して、公開ページを確認して。これを記事の数だけやり直すことになります。SSHでXserverへ入ってWP-CLIを使える環境だったおかげで、この一連の操作はまとめてAIに渡せました。

まとめて渡せた理由は、画像の作りやすさではない

ただ、まとめて渡せた理由を「画像作成が簡単だから」と読まれると、そこは違うんです。添付IDにアイキャッチID、公開ページのOGPと、終わったかどうかを外から確かめる材料が最初からそろっていたからこそ、渡せた作業でした。

WordPress運営でAIに任せやすかった作業の共通点

WordPressにAIを使うと聞くと、記事本文の自動生成が真っ先に浮かぶと思います。ただ、このブログで実際に負担が減ったのは、本文を書く前後に散らばっている細かな運営業務のほうでした。

XserverへSSHで入ってWP-CLIが使える状態なら、投稿もメディアもコマンドで操作できます。しかも、操作したあとの状態を、同じ方法で引き出して確かめられます。任せやすさの差は、ここで生まれていました。

作業ごとの範囲と、完了をどう確かめるか

作業	AIが進められる範囲	完了の確認方法
投稿一覧の取得	タイトル、slug、公開状態の一覧化	WordPressから再取得する
下書き投入	タイトル、本文、抜粋の登録	登録後の投稿を再取得して比較する
メディア登録	画像のアップロード、alt設定	添付IDとメディアURLを確認する
アイキャッチ設定	投稿への画像設定	アイキャッチIDと `og:image` を確認する
内部リンク	関連記事の候補出しと挿入	リンク先と本文の文脈を確認する
文章校閲	表記ゆれや読みにくい箇所の検出	指摘内容を人が採否判断する
記事の主張・公開判断	材料整理と編集の補助	運営者が最終判断する

15記事を一気に進められたのも、表でいうと右端の列、つまり完了の確認方法が先に埋まっていたからです。裏を返せば、そこが埋まらない作業は、AIが「終わりました」と言ってきても鵜呑みにはできない、ということでもあります。

下書きを入れた記事は、そのまま公開できるのか

下書きの投入も、任せやすさでいえば筆頭クラスです。ローカルでタイトルと抜粋、Gutenberg向けのブロックHTMLを用意して、Xserverへ転送し、WP-CLIで下書きとして登録してもらいます。登録後の編集URLまで返してもらえば、管理画面を開いて本文を貼り付ける工程が丸ごと消えます。

この投入までは、本当に速く進みます。ただ、「正しく登録された」と「このまま公開できる」のあいだには、まだ距離がありました。

AIに頼めるのは、見出しの整理、文のねじれの修正、読みにくい段落の分割あたりまでです。次の3点だけは、自分の目で確かめる必要がありました。

実際に経験した内容と文章がずれていないか
読者に持ち帰ってほしい判断が明確か
一般論だけでなく、このブログで公開する意味があるか

古い記事のリライトでは、ここが特に効いてきます。文章をきれいに直すだけだと、元の記事に入っていた経験や迷いまで一緒に薄まってしまうことがあるんです。なので、構成や表現は大きく動かしてもらいつつ、事実と主張だけは先に自分で決めておくようにしました。この分け方なら、がらっと書き換えても記事の中身までは消えませんでした。

内部リンクと校閲で頼んだ範囲

内部リンクの候補出しは、公開済み記事のタイトルとslugを一覧にして渡しておくと頼みやすくなります。会計ソフトの記事からAPIの記事へ、AI前提の内部統制の記事から経費精算AIの記事へ、WordPressテーマの記事からブログ運営の記事へ。こういう具合に、内容のつながりを拾って提案してくれます。

校閲で頼んでいたのも似た形の仕事で、表記ゆれ、長すぎる文、見出しと本文のずれ、メタディスクリプションの長さ、読みにくい箇条書きといった箇所を見つけてもらいます。

とはいえ、候補に挙がったリンクが、読者にとって本当に必要かどうかは別の問題です。リンク先が読者のいまの疑問を補えるかどうかは、本文を読みながら自分で判断しました。

完了の条件まで入れた依頼文の書き方

依頼文には、どの状態になれば完了かを書いておきます。「アイキャッチを設定して」とだけ頼むと、完了の基準が曖昧なまま作業が始まってしまうからです。実際の依頼は、こういう文面にしていました。

この記事に合うアイキャッチを作成し、WordPressへアップロードして、投稿ID 7152のアイキャッチに設定してください。設定後は、添付IDとアイキャッチIDを取得し、公開ページの og:image に新しい画像が反映されていることまで確認してください。投稿の公開状態は変更しないでください。

この文面だと、画像ができた時点でも、WordPressへ登録できた時点でも、まだ終わりではありません。公開ページへの反映まで確認できて、はじめて完了です。冒頭で書いた「反映を確かめた」がゴール、というのはこの意味なんです。

下書きの投入も同じ考え方で、登録後にタイトル、抜粋、本文、公開状態を再取得して、ローカルの原稿と一致しているかを照合するところまで、1回の依頼に含めてしまいます。