ChatGPTからWordPress投稿はどこまで自動化できる？WPVibeを実運用して分かった「消せた作業・残した作業」

WordPressで記事を書いていると、本文を書く以外の作業が意外と多くありませんか。

記事を作る。WordPressへ移す。見出しやリンクを確認する。アイキャッチをアップロードする。カテゴリやタグを設定する。公開日時を決めて予約する。

1本なら大したことがなくても、更新を続けると、この「最後の反映作業」が地味に重くなります。

効率家ラボでは現在、ChatGPTを記事制作の中心に置き、Google Docs、GitHub、WPVibe、WordPressを組み合わせて運用しています。狙ったのは「AIに記事を量産させること」ではありません。自分が判断しなくてもよい機械的な作業を、どこまで会話の中から消せるかです。

実際に続けてみると、WordPress管理画面で行っていた作業のかなりの部分は減らせました。一方で、完全自動化を目指すほど逆に失敗や再実行が増える工程もありました。

先に結論を書くと、今の私にとって最も効率が良いのは「全部を自動化すること」ではありません。

面倒なWordPress操作はAIへ任せる。しかし、記事の判断、本文の正本、アイキャッチのFINAL確認、公開判断は人間側に残す。この分け方が、いちばん手戻りが少なくなりました。

この記事では、2026年現在の実運用をもとに、ChatGPT＋WPVibeでどこまでWordPress投稿を自動化できたのか、逆に何をあえて残しているのかを整理します。

かなり自動化できた。でも「ChatGPT→WordPress」だけにはしていない

今の制作フローを極端に単純化すると、理想はこうです。

ChatGPT

↓

WordPress

しかし、実際の効率家ラボはそうしていません。

ChatGPTを作業の入口にしつつ、GitHub Issueに進行状態を残し、Google Docsを本文の正本にし、WordPressへの実操作だけをWPVibeへ任せています。

現在のイメージは次の通りです。

ChatGPT

├→ GitHub Issue：現在状態・判断・次作業

├→ Google Docs：記事本文の正本

└→ WPVibe

↓

WordPress：公開物の正本

さらに、アイキャッチ画像だけは少し特殊です。

ChatGPT側でFINAL画像を作っても、そのPNGファイルを現在のWPVibeのupload_mediaへAI側からそのまま渡すfile引数はありません。自動経路を維持する場合は、Google Docsに置いた画像から取得できるWPVibeが取得できる一時的な画像URL（contentUri）を使っています。

つまり、Google Docsは「仕方なく挟んでいるだけの中継サービス」ではありません。本文の正本として必要なうえ、今は画像搬送でも役割を持っています。

現在の効率家ラボ記事制作フロー

まず、今の流れを工程ごとに整理するとこうなります。

表を見ると、完全自動ではありません。ただし、人間がやることはかなり「判断」に寄っています。

逆に、WordPress管理画面で行う定型操作は、かなりChatGPT＋WPVibe側へ移せました。

ChatGPT＋WPVibeで消せたWordPress管理画面の作業

以前のWordPress運用では、記事が完成しても最後に管理画面を開き、本文を貼り、設定を入れ、画像をアップロードし、公開日時を指定する必要がありました。

現在は、本文と公開条件が固まった後なら、ChatGPTとの会話から次のような作業を進められます。

• WordPress下書きの作成
• タイトル、本文、抜粋、スラッグなどの反映
• 既存カテゴリやタグの設定
• アイキャッチのメディア登録とfeatured image設定
• 公開前の状態確認
• 予約日時の設定

WPVibeの公式案内でも、ChatGPTからWordPressの記事作成・編集・公開・予約などを行えるとされています。

私の運用でも、これらの機械的な作業のためだけにwp-adminを開く場面は大きく減りました。

ここで重要なのは、「何回クリックが減ったか」という架空の時短値を出すことではありません。私が減らしたかったのは、記事を書き終えた後に別画面へ移り、同じ内容をもう一度入力する作業です。

記事制作の会話の延長で反映まで進められるようになったことの方が、体感としては大きな変化でした。

なぜGoogle Docsを残しているのか

「そこまでChatGPTでできるなら、Google Docsも消せばいいのでは」と思うかもしれません。

私も最初は、できるだけ経路を短くした方が効率的だと考えていました。

しかし、今はGoogle Docsを残しています。理由は3つあります。

1つ目は、記事本文の正本にするためです。

ChatGPTの会話は、企画、調査、修正、失敗した案まで混ざります。一方でGoogle Docsには、今採用している本文だけを置けます。「現在の原稿はどれか」が明確になります。

2つ目は、チャットをまたいで再開しやすくするためです。

長い記事制作では、途中で別チャットへ移ることがあります。そのとき本文が会話の中だけにあると、どこまで確定したかをもう一度探す必要があります。Google Docsに原稿があれば、新しい会話からでも同じ本文を起点に再開できます。

3つ目は、WordPressとは別に原稿を残すためです。

WordPressは公開物の正本です。しかし、下書き作業やサイト側の設定変更と、原稿そのものは分けておいた方が扱いやすいと感じています。

そのため、Google Docsは「画像搬送のためだけに残っているサービス」ではありません。

むしろ、本文の正本という役割が先にあり、その既存経路を画像搬送にも使っている、という方が実態に近いです。

最後まで残った難所は、FINALアイキャッチ画像の受け渡し

本文のWordPress反映はかなり素直になりました。

一方、何度か手間取ったのがアイキャッチ画像です。

効率家ラボでは、ChatGPT側でアイキャッチを作り、内容・文字・キャラクター・ロゴを確認してからFINALを確定します。FINAL承認後は、WordPress側の都合で画像を作り直さない運用にしています。

問題は、その「確定済みPNGをどうWPVibeへ渡すか」でした。

現行のWPVibeのupload_mediaは、画像そのものではなくURLを受け取ります。WPVibe側がそのURLから画像を取得し、WordPressのメディアライブラリへ追加する仕組みです。

そのため、ChatGPT内にある生成済みPNGを、そのままローカルファイルとしてupload_mediaへ渡すことはできません。

過去にはGoogle Driveの通常URLを使おうとして、画像ではなくDriveの確認用HTMLがWordPressへ添付されてしまったこともありました。

現在は、その失敗を避けるため、Google Docs上の画像から取得できる一時的なcontentUriを使う経路を標準にしています。

FINAL PNG

↓

Google Docsに配置

↓

画像contentUriを取得

↓

WPVibe upload_media

↓

WordPressメディア＋アイキャッチ設定

見た目には一手多いですが、すでに本文の正本としてGoogle Docsを使っているため、今のところは「自動処理を維持しながら安定して渡す」方法として成立しています。

実はGoogle Docsを使わない「手動1回」の経路もある

ここは今回調べ直して、認識を少し更新した部分です。

現在のWPVibeには、対応するChatGPTなどの環境で、画像をチャット内へドラッグ＆ドロップしたり、端末から選択したりするアップロードパネルがあります。

その場合は、おおまかに次の流れです。

FINAL画像

↓

人がチャット内のアップロードパネルへ渡す

↓

WPVibeが一時アップロードURLを発行

↓

upload_media

↓

WordPress

この方法なら、「画像搬送のためだけにGoogle Docsへ置く」工程は省けます。

ただし、これは完全自動化ではありません。

ChatGPTが生成したFINAL画像を、そのままAI側からWPVibeへ手渡すのではなく、人間が1回ファイルを選ぶ、またはドラッグ＆ドロップする必要があります。

そのため今の選択肢は、実質的に3つあります。

• 理想：ChatGPT生成FINALを、そのままWordPressへ自動で渡す
• 現在の自動系：Google DocsのcontentUriを経由する
• 現在の簡略系：人がWPVibeのアップロードパネルへ1回渡す

「Google Docs中継を消せるか」だけなら、手動アップロードを許容すれば消せます。

しかし、私が今やりたいのは単にサービス数を減らすことではありません。記事制作の会話から、できるだけ途切れずにWordPress反映まで進めることです。

その条件では、まだGoogle Docs経由にも意味があります。

WPVibe 1.19のSVG対応で、この問題は解決したのか

ちょうどWPVibe 1.19でSVG対応が追加されたため、「これで画像搬送も楽になるのでは」と確認しました。

結論から言うと、ロゴやアイコンにはかなり便利そうですが、今回のFINALアイキャッチPNGの問題を直接解決する変更ではありませんでした。

SVGとは何か

SVGは、ざっくり言えば「ピクセルの集まり」ではなく、線や図形をデータとして記述する画像形式です。

PNGやJPEGのような普通の画像は拡大すると粗くなりますが、SVGはロゴやアイコンのような単純な図形なら、サイズを変えてもきれいに表示しやすいのが特徴です。

一方で、SVGは画像というよりコードに近い性質も持つため、安全性の確認が必要です。

WPVibe 1.19では、SVGをWordPressのメディアライブラリやテーマ素材として扱えるようにし、保存前に危険なスクリプトや外部参照などを除去する仕組みが追加されています。

何が楽になるのか

効率家ラボで考えると、SVG対応が効きやすいのは次のような素材です。

• サイトロゴ
• アイコン
• シンプルなイラスト
• テーマ内で使うベクター素材

たとえば、正規ロゴがSVGで用意されていれば、WordPress用にPNGへ変換して持つ必要を減らせる可能性があります。

逆に、ChatGPTで作る記事アイキャッチは、写真や複雑な背景、人物・キャラクター、文字などを含むPNGやWebPが中心です。

SVG対応が増えても、ChatGPT内の生成済みPNGをupload_mediaへ直接渡せるようになったわけではありません。

つまり、WPVibe 1.19は「扱える画像形式を広げたアップデート」であって、「ChatGPT生成ファイルをAI側からWordPressへ直接受け渡す経路を作ったアップデート」ではありません。

正常系7 callsでも、失敗すると26 callsまで膨らんだ

WPVibeのFreeプランは、現在100 tool calls／rolling 24時間です。公式FAQでは、WordPressへの実操作がカウント対象で、接続・サイト一覧などは対象外、失敗したactionもカウントされないと説明されています。

だから当初は、「とにかくcall数を減らした方がいい」と考えがちでした。

しかし、実運用では単純なcall数最小化が必ずしも効率化になりませんでした。

私の運用ログでは、完全新規記事の正常例で推定7 metered calls、retry 0で終わったケースがあります。

一方、画像搬送でbase64取得のやり直し、Google Drive URLによる誤添付、削除と再アップロードなどの復旧が連鎖したケースでは、推定26 metered callsまで膨らみました。

この差から、今は考え方を変えています。

「1 callでも減らす」より、「一度で成功しやすい既知の経路を使う」。

必要な確認を削って失敗率を上げるより、失敗・確認・再実行まで含めた総作業量を減らす。

現行の運用では、完全新規記事のWordPress反映を通常6〜8 metered calls程度、条件付き処理を含めても9〜10程度に収めることを目安にしています。これはWPVibe公式の平均値ではなく、私の運用Runbook上の目安です。

この考え方は、call制限がなくても同じです。

自動化のために例外処理や独自スクリプトを増やしすぎれば、今度は保守する仕組みが増えます。自動化率は上がっても、運用全体が楽になるとは限りません。

自動化した方がよかった工程、あえて人に残した工程

実際に運用してみて、自動化との相性が良かったのは「入力内容が決まっていて、結果も確認しやすい作業」です。

たとえば、完成した本文を下書きに反映する、既知のカテゴリを設定する、承認済みのアイキャッチをfeatured imageにする、予約日時を設定する、といった作業です。

逆に、人間に残した方がよいと感じているのは「正解が1つではない判断」です。

記事テーマを本当に書くか。

一次体験をどう表現するか。

本文の主張に違和感がないか。

アイキャッチをFINALとして採用するか。

その状態で公開してよいか。

ここまで自動化してしまうと、減るのは作業ではなく確認機会かもしれません。

私が目指しているのは、人間を工程から消すことではなく、人間が「クリック作業」ではなく「判断」に時間を使える状態です。

WordPress管理画面を触らなくなったこと自体より、この役割分担の方が大きな成果でした。

現時点で残っている「最後の中継」は何か

現状で最も分かりやすく残っている中継は、AI生成したFINAL画像を自動でWordPressへ渡す部分です。

本文はGoogle Docsを正本としているため、Docsが残ること自体は問題ではありません。

しかし、画像については理想を言えばこうしたいところです。

ChatGPTでFINAL画像確定

↓

その同じファイル参照をWPVibeへ渡す

↓

WordPressへアップロード

↓

featured image設定

現行のupload_mediaがURL入力だけでなく、ChatGPT側の添付ファイル参照や安全なファイル参照を直接受け取れるようになれば、今のcontentUri中継はさらに短くできそうです。

あるいは、現在のrequest_uploadに、人間が再選択しなくてもChatGPT側の確定済みファイルを渡せる仕組みがあれば、同じ目的を達成できます。

これはWPVibeに必ず実装される機能という意味ではありません。現在の実運用から見て、「ここがつながれば一段短くできる」という私の整理です。

まとめ：ChatGPTからWordPress投稿はかなり自動化できる。ただし、全部消す必要はない

ChatGPT＋WPVibeを使うと、WordPress記事制作のかなりの部分を会話ベースで進められます。

効率家ラボでは、企画・調査・本文作成から、WordPress下書き、アイキャッチ設定、公開準備、予約投稿まで、以前より管理画面を直接触らずに進められる範囲が広がりました。

ただし、完全自動ではありません。

Google Docsは本文の正本と再開性のために残しています。アイキャッチは人間がFINALを承認します。そしてAI生成PNGをWPVibeへ完全自動で直結する経路は、現時点ではまだありません。

一方で、Google Docsを画像搬送に使いたくないなら、WPVibeのチャット内アップロードパネルを使い、人が1回画像を渡す方法もあります。

どちらが正しいというより、何を減らしたいかの違いです。

私の場合は、サービス数やcall数の最小化ではなく、失敗と再実行を含めた総作業量を減らすことを優先しています。

その結果、今の答えはこうなりました。

自動化できる作業は任せる。

正本は外に残す。

人間は最後の判断だけする。

ブログ運営では、「どこまで自動化できるか」より、「どこを自動化すると本当に楽になるか」を決める方が重要でした。

参考にした公式情報

• WPVibe公式：ChatGPTとの接続・投稿操作
• WPVibe公式：チャット内の画像アップロード
• WPVibe公式：SVG対応
• WPVibe公式：料金・tool call仕様

関連記事

• OpenClaw＋Codex＋DiscordからChatGPT中心へ移った理由
• ChatGPT Projectsを長期利用して決めた整理・引き継ぎルール
• 2017年のブログ外注と2026年のAI共同運営を比較