WordPressのAI自動投稿は、最初から「AIが書いて、そのまま公開する」仕組みにしない方が安全です。おすすめは、AIや自動化ツールに任せる範囲を「素材整理」「下書き作成」「下書き保存」までに絞り、公開前チェックと最終公開は人間が見る流れです。この記事では、WordPress REST API、MakeやZapierのような連携ツール、AI下書き生成を組み合わせる前に決めることを、公開事故を避ける順番で整理します。
結論から言うと、個人ブログや小さなメディアで最初に作るべきなのは、全自動公開システムではありません。作るべきなのは、記事ネタや構成案を受け取り、AIで本文のたたき台を作り、WordPressには「下書き」または「予約前の確認待ち」として保存し、公開前に事実、リンク、画像、権利、メタ情報を点検できる運用です。
AI Study Logでも、WordPress運用では記事台帳、公開状態、WordPress ID、URL、品質チェックをローカルで追う形にしています。これは、AIで大量に書くためというより、どの記事を公開したか、どの内部リンクを直すか、どのメタ情報を確認したかを後から追えるようにするためです。自動投稿でも同じで、速さよりも「どこで止められるか」を先に設計した方が、公開後の修正コストを減らせます。
この記事の前提: Make、Zapier、WordPress REST API、AI生成機能の料金、無料枠、機能、利用条件は変わることがあります。この記事では固定価格やキャンペーンを断定せず、2026年7月4日に公式ページで確認した範囲をもとに、読者が確認すべき判断軸を整理します。
キーワード、読者の悩み、参考にする公式情報、内部リンク候補を先に決めます。ここが曖昧だと、AIの下書きも一般論に寄りやすくなります。
AIには構成案、本文のたたき台、メタ説明文候補、公開前チェック項目を作らせます。未確認の価格や体験談は生成段階で断定させません。
WordPressへ送る場合は、まず下書きとして保存します。公開済み状態にしないことで、画像、リンク、メタ、権利の確認時間を確保できます。
公開前に人間が公式情報、リンク、画像、CTA、スマホ表示を見ます。自動化の価値は、確認を省くことではなく、確認漏れを減らすことです。
WordPress AI自動投稿は下書き保存から始める

「WordPress AI 自動投稿」と聞くと、キーワードを入れたら記事が公開まで進む仕組みを想像しがちです。ただ、実務ではそこまで一気に進めると、誤情報、重複記事、権利確認不足、リンク切れ、メタ説明文の不一致、画像の不備に気づきにくくなります。最初の安全な目標は、AIが作った本文をWordPressの下書きとして保存し、公開前チェックが終わるまで公開状態にしないことです。
WordPress REST APIの投稿エンドポイントでは、投稿本文、タイトル、スラッグ、カテゴリー、タグ、アイキャッチ画像、投稿ステータスなどを扱えます。ここで重要なのは、公開ステータスをいきなり公開にせず、下書きやレビュー待ちとして保存できる点です。WordPress側のアプリケーションパスワードは、通常のログインパスワードとは別に発行し、不要になったら取り消せるAPI用の認証情報として扱います。つまり、自動化の入口は作れますが、公開権限の扱いは慎重に設計する必要があります。
初心者が最初に決めるべき範囲は、次の4つです。
- AIに任せるのは、記事案、構成案、下書き本文、メタ説明文の候補までにする。
- WordPressへ送るステータスは、最初は公開ではなく下書きにする。
- 公開前チェックを通った記事だけ、手動公開または予約投稿へ進める。
- エラー時に投稿を止める条件を、本文生成より先に決めておく。
この順番にすると、AIの出力が多少荒くても、公開前に止める場所があります。逆に、AI生成、画像挿入、内部リンク、メタ設定、公開までを一度に自動化すると、どの段階で問題が混ざったのかを後から調べるのが難しくなります。
連携方法はノーコードとAPIを使い分ける

WordPressとAIをつなぐ方法は、大きく分けると3つあります。MakeやZapierのようなノーコード自動化ツールを使う方法、WordPress REST APIを直接呼び出す方法、WordPress内のプラグインやテーマ機能を使う方法です。どれが正解というより、作業者の技術力、記事数、確認フロー、予算、エラー時の止め方で選びます。
| 方法 | 向いている人 | 最初に任せる範囲 | 注意点 |
|---|---|---|---|
| Make | 複数ステップの分岐やデータ整形を見ながら組みたい人 | スプレッドシートやフォームから記事案を受け取り、AI下書きを作ってWordPress下書きへ保存 | 公式料金ページでプラン、実行回数、利用条件を確認する。承認済み affiliate ではないため、本記事では公式確認導線に留める。 |
| Zapier | アプリ連携を短時間で組み、既存SaaSとの接続を優先したい人 | フォーム、カレンダー、ドキュメント、AI生成、WordPress投稿をつなぐ試作 | AI機能やタスク課金の扱いは変更される場合がある。2026年6月15日にAI関連料金の変更案内があったため、固定金額で判断しない。 |
| WordPress REST API | 開発者、または細かい公開条件や検証ログを自分で制御したい人 | 投稿作成、下書き保存、アイキャッチ設定、メタ情報の同期、readback検証 | 認証情報、権限、エラー処理、ログ保存を自分で管理する必要がある。アプリケーションパスワードの保管に注意する。 |
| WordPressプラグイン中心 | 管理画面内で完結したい人 | 下書き補助、SEO補助、内部リンク補助、予約投稿 | プラグインを入れすぎると役割が重複し、テーマやSEOプラグインと干渉することがある。 |
AI Study Logの運用経験では、最初からプラグインや自動化を増やすより、記事台帳、制作ルール、リンク管理、信頼ページ、公開後の確認手順を先に固めた方が安定します。これは自動投稿でも同じです。ツールを選ぶ前に、「何を入力にするか」「AIがどこまで書くか」「WordPressにどのステータスで送るか」「公開前に誰が何を見るか」を決めておくと、MakeでもZapierでもAPIでも設計がぶれにくくなります。
選定基準はツール名より先に決める: 1本だけ試す段階なら、管理画面で流れを見やすいことが重要です。記事数が増えた段階では、実行履歴、失敗時の通知、リトライ、承認フロー、ログの保存、料金の見通しが重要になります。さらに開発者がいる場合は、REST APIで投稿状態やメタ情報を細かく制御する価値が出ます。初心者向けの正解と、運用が育った後の正解は同じではありません。
公開前チェックを自動化フローに組み込む

WordPress AI自動投稿で一番危ないのは、本文がそれらしく見えることです。AIの文章は整って見えても、価格、無料枠、サービス名、手順、規約、比較表、リンク先の状態が古いことがあります。とくにAI/SaaS記事では、料金、プラン名、無料枠、AI学習への利用、連携できるアプリ、キャンペーンの有無が変わりやすいため、公開前チェックをワークフロー内に入れる必要があります。
最低限の公開前チェックは、次の順番で見ると漏れを減らせます。
- 事実確認: 料金、無料枠、機能、制限、規約、セキュリティ、プライバシーを公式ページで確認する。
- 本文確認: AIが使っていないツールを体験談のように書いていないか、保証表現や煽りがないかを見る。
- リンク確認: 公式リンク、内部リンク、CTAリンクが読者の次の行動に合っているかを見る。
- 画像確認: アイキャッチ、本文図解、alt、キャプション、権利、商標、人物表現を確認する。
- メタ確認: SEOタイトル、メタディスクリプション、OG説明文、スラッグ、カテゴリーを確認する。
- 公開状態確認: 下書き、予約、公開、noindex、canonical、アイキャッチ表示を公開前後で読み返す。
このチェックを人間が毎回ゼロから思い出すのは大変です。そのため、スプレッドシート、Markdownの品質レポート、Notion、Google Sheetsなどにチェック項目を置き、自動化ツールから「チェック待ち」の状態を更新できるようにします。AIが本文を作るところだけでなく、チェック項目を作るところまで自動化しておくと、公開前の確認が作業者の記憶に依存しにくくなります。
公開まで全自動にしない方がよい例: 医療・法律・金融に近い内容、企業の内部資料を扱う記事、価格や契約条件を比較する記事、他社ロゴや人物画像を含む記事、アフィリエイト導線がある記事、検索上位を狙って短時間で量産する記事です。これらは、AI下書きまでは便利でも、最終判断を自動化すると読者にも運営者にもリスクが残ります。
実務シナリオ別に自動化レベルを決める

WordPress AI自動投稿は、使い道によって危険度が変わります。たとえば、社内メモをもとに自分用の下書きを作るだけなら比較的低リスクです。一方で、価格比較、レビュー、アフィリエイト、医療・法律・金融に近い話題、他社の権利が絡む画像を含む記事は、AI生成後の人間確認が必須です。以下のように、使い道ごとに「AIに任せる最初の作業」と「人間が確認する点」を分けて考えると安全です。
| 使い道 | 最初にAIへ任せること | 人間が必ず確認すること | おすすめの投稿状態 |
|---|---|---|---|
| ブログ記事の構成案 | 検索意図、見出し案、読者の不安、FAQ候補の整理 | 競合と似すぎていないか、読者の次の行動が明確か | WordPressには送らず、台帳や下書きファイルに保存 |
| 記事本文のたたき台 | 見出しごとの初稿、表の下書き、CTA候補の作成 | 事実、公式情報、未検証表現、重複、読みやすさ | 下書き |
| 公開前チェックリスト | 記事タイプに応じた確認項目の生成 | チェック項目が実際の記事内容に合っているか | 下書きまたはレビュー待ち |
| 内部リンク候補 | 関連記事、アンカーテキスト、リンク位置の候補出し | リンク先が公開済みか、読者の文脈に合うか | 下書き |
| メタディスクリプション | 80〜120字程度の自然な説明文案 | 本文と一致しているか、誇張や未確認主張がないか | 下書き |
| アイキャッチや図解の指示 | 画像コンセプト、alt、キャプション案 | 文字化け、権利、商標、人物表現、本文との一致 | 公開前に手動確認 |
| 定期更新メモ | 古い料金・機能・リンクの確認タスク化 | 公式ページで最新情報を読んだか | 公開済み記事の更新候補 |
| アフィリエイト記事 | 読者の不安、比較軸、公式リンク候補の整理 | 承認状況、リンク種別、開示、nofollow/sponsored、誇張表現 | 承認前は公式リンクまたは内部リンク |
この表のポイントは、AIを使うかどうかではなく、どの時点で止めるかです。低リスクな構成案やチェックリスト作成は自動化の効果が出やすい一方で、公開、価格断定、商品推薦、権利判断、個人情報を含む入力は、人間の確認を残すべきです。
もう一つ大切なのは、入力データの扱いです。ブログ運用では、公開予定のキーワードだけでなく、顧客名、社内資料、未公開キャンペーン、広告費、売上、個人情報が混ざることがあります。外部のAIや自動化ツールへ送ってよい情報かどうかは、記事制作の便利さとは別問題です。実務では、公開済み情報、公式ページ、匿名化したメモ、一般化した作業例だけを入力に使い、社内限定情報や個人情報は入れない運用から始める方が安全です。
記事の種類によっても判断は変わります。ノウハウ記事なら、AIが作った手順を自分の環境で再確認する必要があります。比較記事なら、各サービスの公式ページを読み直す必要があります。レビュー記事なら、使っていない機能を「試した」と書かない線引きが必要です。収益記事なら、案件承認、リンク種別、開示、nofollow/sponsored、読者の不安解消が必要です。自動化フローは、これらの違いを一律に扱わず、記事タイプごとに止める条件を変えるべきです。
アフィリエイト導線も同じです。MakeやZapierは自動化記事と相性がよいサービスですが、この記事のローカル台帳では承認状態が「not_applied」です。そのため、本文には生のアフィリエイトURLもMyLinksProスラッグも入れず、公式ページ確認と既存の内部比較記事への導線に留めます。承認前に収益リンクのように見せると、あとで差し替えが必要になるだけでなく、読者にも不誠実です。
次に確認すること: 自動化ツール選びで迷う場合は、まず既存の比較記事でZapierとMakeの違いを確認し、実際に組む前に公式料金ページで最新の無料枠・実行回数・AI機能の扱いを見てください。
1本テストから小さく運用を始める

WordPress AI自動投稿を始めるなら、最初の目標は「毎日10本公開」ではなく「1本だけ安全に下書き化し、公開前チェックまで通す」ことです。1本でうまくいかない仕組みは、10本に増やすと問題も10倍になります。逆に、1本の流れで入力、AI出力、下書き保存、画像、メタ、公開前チェック、公開後readbackを記録できれば、次の改善点が見えます。
最初のテストは、次の手順で十分です。
- 入力を決める: キーワード、読者の悩み、記事タイプ、参考にする公式情報、内部リンク候補を1行ずつ用意する。
- AIで構成案を作る: 顕在ニーズ、潜在ニーズ、失敗リスク、公開前チェックを含めた見出し案を作る。
- WordPressには下書きで保存する: タイトル、本文、スラッグ、カテゴリー、アイキャッチ候補を入れても、公開状態にはしない。
- 公開前チェックを行う: 事実、リンク、画像、メタ、CTA、権利、noindex/canonical、スマホ表示を確認する。
- 公開後に読み返す: 公開URL、メタ description、OG画像、アイキャッチ、本文画像、ローカルパス混入、リンク切れを確認する。
- ログを残す: WordPress ID、URL、公開日時、Search Console登録状態、次回の改善日を台帳に残す。
この手順は地味ですが、自動化の土台になります。AI Study Logのように記事台帳と下書きフォルダを分けておくと、どの記事が新規、下書き、公開済み、再確認待ちなのかを追いやすくなります。WordPressだけを見ていると、なぜその記事を作ったのか、どの公式情報を確認したのか、どのCTAを避けたのかが残りにくいため、自動化するほど外部の台帳が効いてきます。
公開後はURLがHTTP 200で開けるかを確認します。下書きURL、プレビューURL、ログイン中だけ見えるURLを台帳に残すと、あとで検証できません。
meta description、OG description、canonical、noindexの状態を読み返します。本文が良くても、検索結果やSNSで出る説明がずれていると読者の期待と合いません。
アイキャッチと本文画像がWordPressメディアURLになっているかを見ます。ローカルファイル、仮画像、文字化けしたAI画像、本文内に不要なサムネイルが残る状態は公開完了にしません。
公開直後にSearch Console登録、2週間後に初期クエリ、1か月後にタイトルやメタ、3か月後に本文と内部リンクを見直す予定を残します。
無料で始めてよい人: 月に数本の下書き補助、構成案作成、公開前チェックの抜け漏れ防止を試したい人は、まず公式の無料枠や試用条件を確認し、小さなテストで十分です。
有料化を検討する人: 複数サイト、複数担当者、毎週の更新、複数アプリ連携、エラー通知、履歴管理、承認フローが必要になったら、有料プランやAPI直接連携を比較する段階です。
まだ自動化しない方がよい人: 記事制作ルール、公式情報の確認方法、画像権利チェック、メタ確認、内部リンク方針が未整備なら、先に運用ルールを作った方が安全です。
よくある質問

FAQでは、ツール名よりも公開判断の線引きを確認します。AI自動投稿は、作業を速くする仕組みである前に、どの情報を入力し、どの状態でWordPressに保存し、どの条件を満たしたら公開してよいかを決める運用です。迷う場合は、公開まで自動化するのではなく、下書き保存とチェック項目の自動生成だけに範囲を戻してください。
AIを使うこと自体が問題なのではなく、読者の役に立たない量産、未確認情報、重複、誇張、隠しテキスト、架空レビューのような作り方が問題です。AIで下書きを作っても、公式情報を確認し、独自の判断軸や実務例を入れ、公開前に人間が確認するなら、運用補助として使えます。
おすすめしません。少なくとも、事実確認、リンク確認、画像確認、メタ確認、読者に不要な保証表現の削除は必要です。料金、無料枠、規約、セキュリティ、アフィリエイト条件が関わる記事では、AIの文章だけで公開判断をしないでください。
短く試したいなら、既存アプリ連携が見つかりやすい方から始めてかまいません。分岐や整形を視覚的に組みたい人はMake、普段使っているSaaSとの接続をすぐ試したい人はZapierが候補になります。ただし、プラン、実行回数、AI機能の扱いは公式料金ページで最新情報を確認してください。
最初から直接APIにする必要はありません。認証、権限、エラー処理、ログ保存、公開状態の制御を自分で管理できるなら柔軟ですが、初心者はノーコード連携で下書き保存だけ試す方が安全です。直接APIを使う場合も、アプリケーションパスワードは必要最小限に扱い、漏えい時に取り消せるようにしておきます。
完全公開まで自動化するなら、低リスクで、公式情報の変動が少なく、画像や権利の問題がなく、公開後にすぐ差し戻せる内容に限るべきです。それでも最初は予約投稿やレビュー待ちにし、公開後readbackで本文、メタ、画像、リンクを確認する運用を残すのが無難です。
記事本文テンプレートより先に、入力項目、公開前チェック、メタ説明文、画像alt、内部リンク、公開後ログのテンプレートを作るのがおすすめです。本文だけ自動化しても、確認作業が手作業のままだと、公開前に止める力が弱くなります。
公開してよい合図: 公式情報の確認日が残っている、WordPressには正しいカテゴリーとスラッグで保存されている、アイキャッチと本文画像がWordPressメディアURLになっている、CTAが承認状態に合っている、meta descriptionとOG descriptionが本文の約束と一致している。この5つがそろってから公開へ進めます。
公開を止める合図: AIが未確認の価格や機能を断定している、外部ツールに送ってよいか迷う情報が含まれている、画像内の日本語が読みにくい、リンク先が公式情報や読者の次行動に合っていない、公開後に何を測るか決まっていない。この状態では、記事本文が整っていても下書きに戻します。
WordPress AI自動投稿は、うまく使えば下書き作成、チェックリスト化、内部リンク候補、公開後の改善ログづくりをかなり軽くできます。ただし、最初に自動化すべきなのは公開ボタンではなく、下書き作成と確認漏れ防止です。1本のテストで、AI出力、WordPress下書き、公開前チェック、公開後readback、台帳更新まで通してみると、自分のブログで自動化してよい範囲と、まだ手動に残すべき範囲が見えてきます。最後に、失敗したステップ、手直しにかかった時間、次回も人間が見る項目を1行ずつ残してください。その記録が、次に自動化する範囲を決めるいちばん現実的な材料になります。公開本数を増やすのは、この記録を見てからで十分です。あわせて、公開後に見直す日付と想定検索クエリも残しておくと、AIで作った記事を放置せず改善できます。これで次回の判断も速くなります。慣れてきたら、公開後のクリックや検索クエリも見ながら、次に自動化する工程を一つずつ増やしてください。
