WordPressブログの企画、原稿作成、画像制作、入稿、公開後の確認まで、AIを組み込んで実際に運用してみました。
多くの工程はAIと進められました。一方で、公開の最終判断、公開済み記事の重要な変更、課金・権限・機密情報に関する判断は、人間側に残しています。
これはAIを信用できなかったからではありません。運用を続けるうちに、記事を大量生成することよりも、企画から評価までを安全に循環させる仕組みの方が重要だと分かったためです。
この記事では、ツール同士の一般的な接続方法ではなく、実際に3記事を公開するまでの流れ、途中で起きた失敗、完全自動公開を採用しなかった理由を紹介します。検索順位や収益などの成果はまだ評価途中であり、確認できた事実と未評価の項目を分けて記載します。
目指したのは記事の大量生成ではなく、安全な運用循環
今回試したのは、AIに文章だけを書かせる方法ではありません。
読者の需要を調べ、既存記事との重複を確認し、原稿を比較し、画像を作り、WordPressへ反映し、実画面を確認し、変更履歴を残すところまでを一つの運用として組み立てました。
実際の流れは次のとおりです。
- Search Consoleの実クエリと既存記事の差分から企画候補を選ぶ
- 企画書と共通取材資料を作る
- ChatGPTとClaudeが同じ資料から独立初稿を作る
- 両稿を比較し、相互レビューして合意稿にする
- アイキャッチ画像と必要な本文図解を作る
- WordPressへ新規下書きとして保存する
- タイトル、本文、画像、内部リンク、カテゴリー、公開状態を読み戻す
- Chromeのプレビューで表示崩れや画像の遅延読込を確認する
- 人間が公開を明示承認する
- WordPressで公開する
- 公開URLのtitle、H1、canonical、画像、リンクを再確認する
- Google Sheetsの記事台帳、公開ワークフロー、変更履歴を更新する
- Search Consoleで公開URLを検査し、必要な場合だけ登録リクエストを1回送る
- 完全な28日間とSearch Consoleの反映遅延後に成果を評価する
この14工程を回して分かったのは、AIが文章を生成できることと、記事を安全に公開・運用できることは別だという点でした。
ChatGPT、Claude、人間、各ツールの役割
一つのAIへすべてを任せず、担当を分けました。
| 担当 | 実際の役割 |
|---|---|
| 人間 | 企画の最終判断、公開承認、公開済み記事変更の承認、課金・権限・機密情報の判断 |
| ChatGPT / Codex | 全体進行、調査、独立原稿、画像制作、WordPress反映、変更前後の比較、読み戻し、管理記録 |
| Claude | 共通資料からの独立原稿、構成・文章レビュー、ChatGPT稿との比較、統合方針への承認 |
| WordPress連携ツール | 下書き作成、本文保存、画像設定、公開状態変更、公開後の読み戻し |
| Google Sheets | 記事台帳、公開ワークフロー、記事変更履歴の正本 |
| Search Console | 実クエリの需要確認、URL検査、公開後の検索実績評価 |
| GA4 | 記事閲覧と問い合わせ成功イベントの確認 |
| Make | 通常投稿には使わず、非稼働の変更検知・安全確認・ロールバック候補として保持 |
ChatGPTとClaudeには、最初から相手の原稿を見せませんでした。同じ共通取材資料から別々に書かせた後で比較したため、一方の表現へ引っ張られずに構成や不足を検討できます。
今回の原稿でも、ChatGPT版は結論と初心者向けの説明が明快で、Claude版は失敗と対処の一次情報が厚いという違いが出ました。比較レビュー後、Claudeからは、AIの万能感を強く出す導入を避けること、工程の重複を削ること、未確認の成果を断定しないことを条件に統合方針への承認を得ています。
この運用で実際に公開した3記事
高齢の親の通信環境を選ぶハブ記事
自宅、介護施設、空き家では必要な通信環境が異なります。そこで、状況別の判断順序を示し、既存の介護施設、空き家、固定電話、モバイル回線の記事へ案内するハブを作りました。
似た記事を一つへ統合したのではありません。ハブは全体像と判断順序、子記事は個別の実例や手順を担当させています。アイキャッチ1枚に加え、本文を理解しやすくする図解を2枚作成しました。
Contact Form 7の送信成功をGA4で計測する記事
自分のサイトでContact Form 7の送信成功をGA4へ送る構成を作り、その実測を記事にしました。
Google Site Kitの標準連携を使い、GA4リアルタイムでcontactイベントが1件、重複0件であることを確認しています。通常イベントへの反映後にはキーイベントとして扱えることも確認しました。
ここで断定できるのは計測が成立したことまでです。問い合わせ件数が増えたかどうかは、別の評価になります。
家族のデジタル遺品を整理するハブ記事
平時、長期入院時、死亡後を分け、パスワードそのものを家族へ渡さずにアカウントを引き継ぐ考え方を整理しました。
この記事も、既存のパスワード管理記事4本を統合せず、全体を案内するハブとして設計しています。公開後には、4本の子記事からハブへ戻る文脈リンクを各1本追加しました。
Search Consoleでは公開URLのテストが通り、パンくずリストが有効であることを確認しました。インデックス登録リクエストは、繰り返しても優先度が上がるものではないため、1回だけ送っています。
実運用で起きた4つの失敗
1. WordPressに空の下書きが作られた
WordPressへ下書きを作成した際、HTML変換結果が正しく渡らず、タイトルとカテゴリーだけで本文が空の下書きになりました。
ここでAIへ本文を再生成させると、比較とレビューを終えた合意稿とは違う文章になる可能性があります。そのため、合意済み原稿を直接保存し直し、本文を読み戻して復旧しました。
もし完全自動公開にしていたら、空の記事が公開される可能性がありました。保存できたことではなく、保存後の中身が期待どおりかを完了条件にする必要があります。
2. 遅延読込画像を不具合と誤認しかけた
公開前にページ全体を撮影したところ、本文図解が小さな代替画像のままになり、大きな空白に見えました。
しかし、通常どおり画面をスクロールすると実画像が読み込まれました。原因は画像の遅延読込であり、本文や画像設定の破損ではありませんでした。
画面の一つの状態だけを見て自動修正すると、正常な設定を壊すことがあります。表示上の問題は、実際の読者に近い操作でも確認する必要がありました。
3. 内部リンク追加でブロック境界が重複した
公開済みの子記事4本から新しいハブへ内部リンクを追加した際、2記事でWordPressのブロックコメント境界が一時的に重複しました。
変更後の本文を読み戻したことで発見し、該当箇所だけを最小修正しました。最終的には4記事すべてで、公開状態が維持され、ブロック境界が正常で、ハブへのリンクが1本だけ存在することを確認しています。
公開済み記事の変更では、見た目だけでなく編集データの構造も確認対象になります。
4. Search Consoleのプロパティ種別を取り違えた
当初、Search Consoleの対象をドメイン型プロパティだと想定して操作し、権限エラーになりました。実際に権限があったのは、URLプレフィックス型のプロパティでした。
エラーを権限不足と決めつけず、対象プロパティを確認して切り替えることで解決しました。AIが操作を続けられても、前提となる対象が正しいとは限りません。
アイキャッチだけでは足りなかった
最初はアイキャッチ画像を中心に考えていました。しかし、長い記事に画像が1枚だけでは、読者が判断の流れや情報の関係をつかみにくくなります。
そこで、画像枚数を先に決めるのではなく、文章だけでは理解しにくい場所へ図解を追加しました。具体的には、通信環境の判断フロー、デジタル遺品情報の階層、GA4計測の流れなどです。
装飾目的で画像を増やすのではなく、読者の判断を助ける場所に絞る。この考え方は、AIで画像を作れるようになっても変わりませんでした。
完全自動公開を採用しなかった理由
公開ボタンを人間側に残した理由は、次のとおりです。
- 同じ資料から作っても、AI原稿同士で主張、範囲、表現に差が出る
- 既存記事と似ていても、統合すべきとは限らない
- 初稿では必要な図解や内部リンクが不足することがある
- 空本文、ブロック境界、画像の遅延読込など、実画面で初めて分かる問題がある
- 公開済み記事の変更は検索流入と読者体験へ直接影響する
- 課金、権限、機密情報、公開判断はAIへ委ねない方が安全である
- 誤更新時に原因を追えるよう、承認、変更前後の状態、履歴が必要である
AIが信用できないから人間が全部作業する、という結論ではありません。AIには調査、制作、比較、検証、記録を広く任せつつ、影響の大きな判断だけを人間が持つ設計です。
Makeを通常の投稿経路から外した理由
当初は、外部サービスとWordPressを連携するためにMakeを検証し、大量データを使った確認も完了しました。
その後、WordPress操作には専用の連携手段を使えるようになりました。通常投稿でMakeを経由すると、経路、障害点、確認箇所、認証管理が一つ増えます。
追加価値より複雑性の方が大きいと判断し、Makeは通常投稿経路から外しました。ただし、検証済みのシナリオは削除していません。普段は動かさず、将来の変更検知、安全確認、ロールバック候補として保持しています。
自動化では、使えるツールをすべてつなぐことだけが正解ではありません。不要になった経路を減らすことも設計の一部です。
現時点で確認できた成果と、まだ言えない成果
現時点で確認できているのは、次の事実です。
- AIを使い、企画、競合調査、原稿比較、画像制作、WordPress反映、公開確認、管理記録まで一連の工程を実施できた
- 新規ハブ記事2本とGA4計測記事1本を、複数原稿の比較と人間承認を経て公開した
- 既存記事との役割分担を整理し、双方向の内部リンクを構築した
- Contact Form 7の送信成功をGA4で1件計測し、重複0を確認した
- 完全自動公開ではなく、重要判断を人間に残す運用を確立した
一方、次の項目はまだ断定できません。
- 検索順位が上がったか
- アクセスが増えたか
- 問い合わせや収益が増えたか
- 従来より作業時間を何％削減できたか
- この企画にかかった正確な時間と費用
公開直後の数値で記事を繰り返し直すと、どの変更が効いたのか分からなくなります。そのため、完全な28日間とSearch Consoleの反映遅延を待って評価します。
同じ運用を試すなら、最初に決めたいこと
ここからは実測結果ではなく、今回の経験から得た筆者の提案です。
最初から多数のサービスをつなぐより、まず「WordPressでは下書きまで」「公開は人間が承認」「公開後に実ページを読み戻す」という境界を決める方が重要です。
運用が安定してから、複数AIによる原稿比較、画像制作、記事台帳、変更履歴、公開後評価を追加できます。自動化の範囲より先に、止まる場所と確認方法を決めておくと、問題が起きたときに戻りやすくなります。
まとめ
AIを使うことで、WordPressブログ運営の多くの工程を実際に進められました。同時に、空下書き、画像遅延読込の誤認、ブロック境界の重複、対象プロパティの取り違えなど、文章生成だけでは見えない問題も経験しました。
今回たどり着いた役割分担は、次のとおりです。
- AI：調査、制作、比較、検証、記録
- 人間：目的、承認、公開、課金、権限、機密情報
AIブログ運営で重要なのは、何本の記事を自動生成できたかではありません。企画から公開後の評価までを、安全に循環させられるかです。
検索流入、問い合わせ、収益、作業時間への効果は、まだ評価途中です。公開から完全な28日間のデータがそろった後、Search ConsoleとGA4の実測結果をこの記事へ追記します。
コメント