AIでWordPress自動投稿してみた。Antigravityで下書きまでやる手順

WordPressのロゴ
WordPress。今回の自動投稿実験では下書き投稿先として使った。 出典: WordPress Foundation / GPL / Trademark applies

AIで記事を書けるなら、WordPressへの投稿もAIに任せたい。そう考えて実験しました。使った環境はAntigravityです。AIエージェントにファイルを読ませ、ターミナルでスクリプトを動かす。WordPressへ下書きを作るところまで試しました。

ただし「自動投稿」と書くと強めです。実際はAIに下書きを作らせて人間が公開ボタンを押すだけの、そこそこ地味な話です。真面目なタイトルで釣っておいて、中身は手作業が混ざっています。 先にネタバラシしておきます。

最初の企画では15記事を想定していました。ただ、今回この記事で正確に書ける実測は7記事です。7本を下書きに入れて、あとから混ざるとややこしいので全部ゴミ箱へ移しました。

この記事は成功談だけではありません。SiteGuard LiteにREST APIの削除を止められて、XML-RPCで消した話も入れます。非エンジニアが真似できるように、難しい言葉には必ず補足を付けます。

先にネタバラシ

AIでWordPressへ自動投稿することはできます。ただしおすすめは「自動で公開」ではありません。AIで記事ファイルを整える。WordPress REST APIで下書きに入れる。最後は人間がプレビューして公開する。この形が現実的です。

REST APIとは、外部のツールからWordPressへお願いを送るための窓口です。今回なら「このタイトルと本文で下書きを作ってください」と送ります。Application Passwordは、そのお願いを許可するための合鍵です。通常ログインのパスワードとは別に作るものだと考えると分かりやすいです。

実際の流れは、AntigravityでAIエージェントに作業を頼むところから始まります。記事のMarkdownをGutenberg HTMLへ変換して、JSON-LDとSEOチェックを作る。そこからNode.jsのスクリプトでWordPressへ下書き投入。この順番で進めました。

詰まったら止まらなくていいです。エラー文をそのままAntigravityのAIエージェントに貼ればいい。なんならこの記事のURLごと貼って、「この手順のどこで詰まっているか見て」と頼めばいい。笑。

この記事のポイント

– AI ブログ 自動投稿 WordPressの実験を2026年4月17日に行った記録

– 実測は7記事で、すべてWordPressの下書き止め

– 投稿はREST API、削除はSiteGuard Liteに阻まれたためXML-RPCを使用

– 非エンジニアは専門用語を覚えるより、エラーをAIエージェントへ渡すほうが早い

– 公開ボタンだけは人間が押す運用にしたほうが安全

※本記事は2026年4月17日時点の実験記録です。WordPress公式のREST API資料とApplication Password資料、XML-RPCのwp.deletePost資料、Google Search CentralのAIコンテンツ方針を確認して書いています。実サイトの認証情報は本文に載せません。

まず用語をほどく

非エンジニアがこの手順でつまずくのは、だいたい言葉です。REST API / JSON / Gutenberg / Application Password。横文字が出た瞬間に画面を閉じたくなります。でも中身はそこまで怖くありません。ここではざっくりこういう意味、くらいの粒度で進めます。

用語ざっくり言うと今回の役割
AntigravityAIエージェントが使える開発環境ファイル編集とコマンド実行の作業場
AIエージェント指示を受けて作業するAI記事作成、修正、エラー確認の相棒
Markdown文章を簡単な記号で書く形式記事の元原稿
GutenbergWordPressのブロックエディタWordPressへ入れる本文形式
REST APIWordPressへ外からお願いする窓口下書き作成や更新に使う
エンドポイントREST APIの送り先URL`/wp-json/wp/v2/posts`など
Application PasswordWordPressが発行する外部アプリ用の合鍵スクリプトからログインするために使う
JSON決まった形で書いたデータのメモタイトル、本文、ステータスをまとめる
draft下書き公開せずWordPress内に保存する状態
slugURLの最後に入る英数字記事ごとの識別名
XML-RPCWordPressの古い通信口REST API削除が止まった時の退避路

ここで全部を暗記しなくて大丈夫です。作業中に迷ったら、表の言葉をAntigravityへ貼って聞けばいい。たとえばこうです。

REST APIとApplication Passwordの違いが分からない。
この記事の表を前提に、私が今やるべき操作だけ説明して。
専門用語は使ってもよいが、必ず一言で補足して。

このくらい雑でいいです。AIエージェントは、雑な相談を作業の形へ直すのがかなり得意です。

実施環境。今回はAntigravityで動かした

今回の作業場はAntigravityです。エディタやファイルを同じ画面で扱えて、ターミナルとAIエージェントも近い場所にある。非エンジニア寄りの運用でも試しやすいと感じました。

ターミナルとは、文字でパソコンに指示を出す画面です。黒い画面にコマンドを打つやつ。怖く見えますが、この記事ではほぼ決まった文章を貼るだけです。

項目今回の内容補足
作業環境AntigravityAIエージェントへ相談しながら進めた
サイトlisten-shachiku.comWordPressサイト
記事の元`web/articles/markdown/ja/`Markdown原稿を置く場所
変換後`web/articles/gutenberg/ja/`WordPressブロック用HTML
構造化データ`web/articles/schema/`Googleに内容を伝えやすくするJSON-LD
SEOチェック`web/articles/qa/`自前の採点レポート
投稿スクリプト`web/posts/tools/publish-wp-drafts.mjs`下書き作成用
削除スクリプト`web/posts/tools/delete-wp-drafts.mjs`今回はゴミ箱移動用

MCPという言葉も出ました。MCPはAIエージェントが外部サービスを操作するための接続口です。今回はWordPress用のMCPだけに頼らず、Node.jsのスクリプトからREST APIを叩く形にしました。Node.jsとはJavaScriptをパソコン上で動かすための実行役で、この記事では「投稿スクリプトを動かす係」くらいに思えば足ります。

📷 画像を追加
内容：Antigravityの画面 or AIエージェントのチャットUI（自分のスクリーンショットで可）
alt：AntigravityのUIキャプチャ
caption：AntigravityのAIエージェントに作業を頼む画面。詰まったらここへ貼ればいい

全体の流れ。手動コピペを消す

WordPressへ記事を手動投稿すると、意外と時間を使います。タイトルを入れる。本文を貼る。見出しを直す。カテゴリを選ぶ。タグを入れる。URLを確認する。画像を入れる。プレビューを見る。1本ならまだいいですが、7本や15本になると同じ作業を何度も繰り返すことになる。ここをAIとスクリプトに渡したかったわけです。今回の流れはこうです。

手順やること人間の役割
1Content Briefを作る記事の狙いを決める
2Markdown本文を書くAIの文章を読み直す
3Gutenberg HTMLへ変換スクリプトを実行する
4JSON-LDを作るFAQや筆者情報を確認する
5SEOチェックを出す点数より中身を見る
6REST APIで下書き投入`draft`で止める
7WordPressでプレビュー画像、リンク、見出しを見る
8問題なければ人間が公開公開は手動

大事なのは6番です。絶対に最初から公開しない。WordPress REST API公式でも投稿の`status`には`publish`や`draft`があり、今回のスクリプトは`draft`を指定しました。`publish`は公開、`draft`は下書き。この違いだけは覚えておくと事故が減ります。

原稿ファイルを用意する

まず記事の元になるMarkdownを用意します。Markdownは、見出しを`##`で書いたり、表を`|`で書いたりする軽い文章形式です。WordPressへ直接貼る前の原稿だと思えば大丈夫です。今回のファイル構成はだいたいこうです。

web/
  posts/
    briefs/
      d01-ai-auto-post-wordpress.md
    markdown/
      ja/
        ai-auto-post-wordpress.md
    gutenberg/
      ja/
        ai-auto-post-wordpress.html
    schema/
      ai-auto-post-wordpress.json
    qa/
      ai-auto-post-wordpress-seo-check.md
    images/
      ai-auto-post-wordpress-image-candidates.md
    tools/
      build-post-artifacts.mjs
      publish-wp-drafts.mjs
      delete-wp-drafts.mjs

Briefは設計メモです。どのキーワードを狙うか。誰に向けるか。どの見出しにするか。どんな体験談を入れるか。ここを先に決めておきます。

非エンジニア向けの記事なら、ここで「専門用語には補足を入れる」と書いておくのがかなり大事です。AIは指定しないと急に開発者向けの顔をして、REST APIを当然のように書いてきます。読者はそこで帰る。

今回ならBriefに近い考え方として、次を守りました。

  • 1つの専門用語に1つの言い換えを付ける
  • コマンドは何のために打つか先に書く
  • 認証情報は絶対に本文へ出さない
  • 公開ではなく下書き止めにする
  • 詰まった時のAIエージェント用コピペ文を入れる

百貨店の事務方で販促や運営支援をしていた頃も、説明を「分かる人向け」だけで作ると伝わりませんでした。商品や企画の説明は最初の一文で置いていかれると読まれない。AI自動投稿の記事も同じです。

ペルソナと禁句を先に決める

AIで記事を書くと、文章がそれっぽく整いすぎます。自分で読んでいても、どこかで見たことがある感じになる。そこでペルソナ設定を使います。

ペルソナとは「誰として書くか」の設定です。今回はYOSKとして書く。アラフォー・2児の父・百貨店の事務方から農業ITへ移った人間。ペーパードライバー歴10年超でスイフトの社用車をきっかけに運転復帰した人間です。この背景を入れると記事に一次情報が入って、ただのAI自動投稿ノウハウではなく自分がやった作業記録になります。

出したくない言葉も決めます。自分の場合はAIっぽく見える言い回しを避けたい。締めが急に営業っぽくなる文章や、断言の強すぎるタイトルは自分のサイトには合いません。

禁句リストを作る理由は、AIに文章の癖を戻させないためです。人間の編集者が赤字で直すところを、先にルール化しておく感じです。

生成物を作る。Gutenberg化とSEOチェック

Markdownを書いたら、WordPressへ入れやすい形へ変換します。ここで出てくるGutenberg HTMLは、WordPressのブロックエディタが読めるHTMLです。

普通のHTMLに見えますが`<!– wp:paragraph –>`のようなコメントが入ります。これは感想ではなくて、WordPressに「これは段落です」「これは見出しです」と知らせる目印です。

生成に使ったコマンドはこれです。

node web/posts/tools/build-post-artifacts.mjs

このコマンドで、Markdownから3つのものを作ります。

生成物保存先役割
Gutenberg HTML`web/articles/gutenberg/ja/`WordPressへ入れる本文
JSON-LD`web/articles/schema/`記事、FAQ、筆者情報の構造化データ
SEOチェック`web/articles/qa/`タイトルや本文やリンクやFAQの確認
画像候補`web/articles/images/`alt文、出典、ライセンスのメモ

JSON-LDとは、検索エンジンへ内容を伝えるための整理メモです。読者が直接読む文章ではありません。ただFAQや筆者情報を整理して渡すことで、記事の意味を機械にも伝えやすくなります。

Google Search Centralは、生成AIコンテンツでも正確性・品質・関連性を重視するよう案内しています。さらに、AIや自動化を使った場合は作成過程の背景を出すことも文脈になると説明しています。だからこの記事ではAIを使ったことを隠しません。むしろ工程ごと書きます。

📷 画像を追加
内容：Markdown → Gutenberg HTML 変換のフロー図（自作推奨）
alt：MarkdownからGutenberg HTMLへの変換フロー
caption：原稿ファイルをWordPressに渡せる形に組み直す流れ

WordPress側でApplication Passwordを用意する

ここは少し緊張するところです。でもやることは外部アプリ用の合鍵を作ることだけ。通常ログインのパスワードをスクリプトへ渡すのは避けたいので、WordPressのApplication Passwordを使います。WordPress公式の資料でも、Application Passwordはアプリケーション用のパスワードとして扱われています。手順はWordPress管理画面で進めます。

手順画面やること
1ユーザー自分のプロフィールを開く
2アプリケーションパスワード新しい名前を入れる
3追加発行された文字列を保存
4ローカルファイル認証情報を貼る
5Git管理絶対に公開しない設定にする

認証情報は記事本文に出しません。GitHubへ上げるのもダメです。ローカルだけに置くものだと思ってください。ローカルファイルの形は、たとえばこうです。

WP_API_USERNAME=your_user_name
WP_API_PASSWORD=xxxx xxxx xxxx xxxx xxxx xxxx

`your_user_name`はWordPressのユーザー名、`WP_API_PASSWORD`はApplication Passwordです。スペースが入った形で表示されることがあるので、そのまま扱う場合はスクリプト側で読める形に整えます。

ここで不安になったら、Antigravityへこう貼ってください。

WordPressのApplication Passwordを使ってREST APIへ下書き投稿したい。
認証情報は絶対に表示しない前提で進めたい。
私が確認すべきファイル名、Gitに含めない設定、テスト方法を順番に出して。

これで十分です。AIエージェントには、秘密を守る前提を先に書きます。

投稿スクリプトは何をしているのか

投稿スクリプトの役割は、WordPress管理画面で人間がやっていた入力を代わりに行うことです。今回使ったのは`publish-wp-drafts.mjs`。名前にpublishと入っていますが、実際の投稿ステータスは`draft`です。スクリプトはだいたい次の順で動きます。

順番処理非エンジニア向けの意味
1認証情報を読むWordPressへ入るための合鍵を確認
2Markdownを読むタイトルや説明文を取り出す
3Gutenberg HTMLを読む投稿本文を用意
4JSON-LDを読む構造化データを本文末へ付ける
5SEO点数を見る低すぎる記事は止める
6カテゴリを探すなければ作る
7タグを探すなければ作る
8同じslugの記事を探す既存下書きなら更新
9WordPressへPOSTする下書きとして保存

POSTとは、データを送る操作です。ここでは「この内容で記事を保存してください」というお願いになります。

REST APIの送り先はこういう形です。

https://www.listen-shachiku.com/wp-json/wp/v2/posts

`wp-json`がWordPressの外部連携用の入口で、`wp/v2/posts`が投稿記事を扱う場所です。WordPress公式のREST API Posts資料では、投稿作成に`POST /wp/v2/posts`を使います。

投稿の項目には`title`や`content`・`excerpt`や`status`があります。`categories`や`tags`も送れます。今回の考え方はこうです。

title   = 記事タイトル
slug    = URLの最後
content = Gutenberg HTMLとJSON-LD
excerpt = description
status  = draft

ここで`status = draft`が命綱です。`publish`にしてしまうと公開されます。非エンジニアが最初に試すなら、ここは絶対に下書きです。

実際に7記事を下書き投入した結果

今回、WordPressへ下書き投入した記事は7本です。すべてSEOチェックは100点。ただし100点は「自前チェックを通った」という意味で、検索順位を保証する点数ではありません。

slug操作Post ID状態
hustler-paper-driver-easy作成47draft
toyota-smooth-scary作成48draft
child-pickup-restart作成49draft
comeback-guide-10year-blank作成50draft
jimny-used-price-2026更新16draft
swift-company-car-paper-driver作成52draft
suzuki-ev-strategy-2026更新15draft

ここで大事なのは、公開していないこと。全部下書きです。作成と更新が混ざっているのは、同じslugの記事が既にWordPress側にあったからです。

slugとはURLの最後に入る識別名です。同じslugがあれば既存の下書きを更新する。なければ新規作成する。この動きにしておくと、同じ記事を何度も増やしにくくなります。

ただし、既に公開済みの記事を勝手に上書きすると危ない。そのためスクリプトでは、既存記事が公開済みならスキップする設計にしています。

投稿後に見る場所

下書きができたら、WordPressのプレビューを見ます。ここを飛ばすとAI自動投稿は事故ります。確認するのは記事本文だけではありません。見出しや画像。リンクとカテゴリ。タグ。URL。本文末のJSON-LDまで確認します。

確認項目見る理由OKの目安
タイトル長すぎると読みにくい画面内で自然に読める
slugURLが変だと共有しにくい英数字で意味が分かる
見出しH2とH3の流れを見る目次だけで内容が追える
本文AIっぽい言い回しを見る自分の声として読める
画像表示崩れを見るaltと出典が入っている
内部リンク404を避けるクリックして遷移する
外部リンク出典の確認公式情報へつながる
FAQ重複や薄さを見る具体的に答えている
JSON-LD壊れた文字列がないかそのまま貼られていない

AIで作った文章は、きれいに見えるほど危ないときがあります。何も引っかからず読めるのに、具体的な経験が薄い。

そこで自分は、ペーパードライバー体験と2児の父としての送迎目線を意識的に入れるようにしました。百貨店の事務方での販促・運営支援の経験も、必要な場所だけに入れています。

車の記事なら、ただの車種紹介で終わらせない。スイフト社用車で運転復帰した話 のように、運転が苦手な人がどこで怖くなるかまで書く。この一次情報がないとAI記事は似た顔になります。

2児の父としての目線は 子供の送迎で運転再開する記事 に、トヨタ車の操作感でヒヤッとした体験は スムーズすぎて怖かった話 に分けました。記事ごとに体験を散らすと、サイト全体で一人の人間が書いている感じが出ます。

📷 画像を追加
内容：WordPress管理画面でApplication Password発行している画面のスクリーンショット
alt：WordPressのApplication Password発行画面
caption：通常パスワードとは別の合鍵を作る。スクリプト用に必要

削除で詰まった。SiteGuard Liteに止められた話

下書きを入れたあと、ユーザー判断としてWordPress上から全部消すことにしました。理由はシンプルで、リライト途中の記事と下書きが混ざるとややこしいからです。

最初はREST APIのDELETEで消そうとしました。DELETEはデータを消す操作で、WordPress公式のREST API Posts資料にも投稿削除は`DELETE /wp/v2/posts/<id>`とあります。

ところがSiteGuard Liteに止められました。SiteGuard Liteはセキュリティ系のプラグインで、外部からの危ない操作を止める役割があります。

次にREST APIで`status`を`trash`へ変える方法も試したのですが、WordPress側で受け付けられませんでした。`trash`は通常の投稿ステータスとして指定できる値ではなかったからです。

最終的にはXML-RPCの`wp.deletePost`を使いました。XML-RPCはREST APIとは別の古い通信口です。WordPress公式のコードリファレンスでは、`wp.deletePost`は投稿IDを受け取り、削除に成功するとtrueを返す形で説明されています。今回の結果はこうでした。

詰まった箇所起きたこと対応
REST API DELETESiteGuard Liteに止められた別ルートを検討
status=trashWordPressに拒否されたステータス更新ではなく削除へ
XML-RPC`wp.deletePost`が通った7記事をゴミ箱へ移動

ここは笑い話にしておきたいところです。AIで下書きを作れたと思ったら、消すところでプラグインに門前払いされました。ちゃんと守ってくれている、とも言えます。ただ非エンジニアがここで一人で悩むのはきつい。こういうときこそAntigravityへ貼ればいいです。

WordPressの下書きをREST APIで削除しようとしたらSiteGuard Liteに止められました。
公開済み記事は触りたくありません。
下書きだけを安全にゴミ箱へ移したいです。

以下を順番に確認してください。
1. REST APIでできること
2. SiteGuard Liteが止めていそうな理由
3. XML-RPCを使う場合の注意点
4. 実行前に人間が確認すべきPost ID
5. 間違って公開記事を消さないための安全策

エラー文:
ここにエラーを貼る

コピペ可です。なんならこの記事のURLごと貼ってよし。公開後なら、このURLを一緒に投げてください。

この記事の手順に沿って、私のWordPress自動投稿のエラーを一緒に見て。
記事URL: https://www.listen-shachiku.com/lab-notes/ai-auto-post-wordpress/
今やりたいこと: 下書きだけを作る。公開はしない。
今起きていること: ここにエラー文を貼る。

AIエージェントに頼むときは、公開しない・削除対象を確認する・認証情報を表示しない、の3つを先に書く。これだけで危ない返答が減ります。

トラブル別の見方

自動投稿で出るエラーは、だいたい種類が決まっています。英語のエラー文を見ても焦らなくていいです。まず分類します。

エラーざっくり意味最初に見る場所
401 Unauthorizedログインできていないユーザー名とApplication Password
403 Forbidden権限やプラグインで止められたユーザー権限、SiteGuard Lite
404 Not Found送り先が見つからないURL、サイトURL、REST APIの有効性
400 Bad Request送ったデータが変JSON / status / meta / カテゴリ
fetch failed通信できないネットワーク、実行環境、URL
invalid_param指定できない値がある`status`や`meta`の中身
duplicate slug同じslugがある既存記事を更新するか確認

これも覚えなくていいです。エラー文とこの表を一緒にAIへ貼る。それで次の一手はだいたい出ます。

非エンジニアが危ないのは、エラーを見て適当に設定を触ることです。特にセキュリティプラグインを一時停止するときは慎重にしたい。自分だけの検証環境ならまだしも、本番サイトでは戻し忘れが怖いです。

AI記事のSEOで気をつけたこと

AIでWordPressへ自動投稿できると、つい量を増やしたくなります。でも量だけ増やすとサイトが薄くなります。以前15記事を一気に作ったときも、文章がやや淡白でした。

今回は1記事ずつリライトして、画像候補・Gutenberg化・SEOチェックまで回す形にしました。自動化するほど人間が見るべき場所を減らしてはいけません。逆です。作業が早くなるぶん、確認の密度を上げるべきです。

Google Search Centralは生成AIを使うこと自体を問題にしているわけではありません。一方で多数ページを価値なく作る使い方はスパムポリシーに触れる可能性があります。つまりAIで作ったかどうかより、読者にとって役に立つかどうかが問われます。今回の自分なりの基準はこうです。

チェック見ること
一次情報自分が実際にやった操作が入っているか
時点2026年4月17日時点など確認日があるか
出典公式情報へリンクしているか
読者非エンジニアが置いていかれないか
失敗詰まった箇所も書いているか
下書き公開前に人間の目が入るか
AI感短文連発や定型句が残っていないか

SEOは見出しだけでやるものではありませんが、見出しはかなり大事です。非エンジニア向けなら、見出しだけ読んでも作業の順番が分かるようにしておく。

本文の呼吸も見ます。「です。」「ます。」が短く続くと、手順書としては読めても記事として硬くなります。だから説明が続くところは少し長めに書き、操作の箇所だけ表や手順で切ります。

画像配置はどうするか

画像も自動化したくなります。ただWEBから画像を使うなら出典とライセンスが必要で、公式サイトの画像は参照には使いやすくても、再アップロードできるかは別問題です。

今回の運用では、画像候補ファイルを作りました。どの画像をどこに置くか。altに何を書くか。出典をどう書くか。自作図解にするなら何を図にするか。ここを先にメモしておきます。

画像候補理由
アイキャッチ自作フロー図商標リスクを避けやすい
本文1AntigravityからWordPressへの流れ手順が一目で分かる
本文2WordPress下書きチェック表公開前確認に使える
本文3エラーをAIへ貼るテンプレート記事独自の価値になる

自作図解は少し手間ですが、検索から来た読者にとって分かりやすい。さらに著作権の心配が少ないので、今回のような手順記事では自作図解のほうが合います。

AI生成画像を使う場合も、生成した画像であることを管理メモに残したいです。GoogleのAIコンテンツ方針でも、AIや自動化を使った背景を読者に分かる形で示すことが文脈になると触れています。

📷 画像を追加
内容：WordPressの下書き一覧画面（10本入った状態のスクショ）
alt：WordPress管理画面の下書き一覧
caption：下書きまで入れたら、あとはプレビュー確認して公開ボタンを押すだけ

非エンジニア向けの実行手順

ここからは、実際に自分が動かすときの順番として書きます。前提はWordPressの管理者権限とApplication Passwordがある状態で、認証情報はローカルの安全なファイルに置きます。

1. Antigravityでフォルダを開く

まずAntigravityで作業フォルダを開きます。今回なら`claude-code-learning`のようなローカルリポジトリです。リポジトリとはファイル一式を管理している作業場所で、Gitという履歴管理の仕組みと一緒に使われることが多いです。非エンジニアなら「記事とスクリプトの入ったフォルダ」くらいに思っておけば足ります。

2. AIエージェントに状況を説明する

最初の指示は長めでいいです。

WordPressへAI記事を下書き投稿したい。
公開は絶対にしない。
Markdown原稿からGutenberg HTML、JSON-LD、SEOチェックを作りたい。
その後、REST APIでWordPressへdraftとして投稿したい。
私は非エンジニアなので、専門用語には一言補足を付けて。
危ない操作は実行前に止めて。

これで方向が決まります。「公開しない」を最初に書くのがポイントです。

3. 原稿を置く

Markdown原稿を`web/articles/markdown/ja/`へ置きます。ファイル名はslugと合わせます。今回ならこうです。

ai-auto-post-wordpress.md

slugが`ai-auto-post-wordpress`なら、ファイル名も同じにする。ここがずれると、生成スクリプトが見つけられないことがあります。

4. 生成スクリプトに記事を登録する

`build-post-artifacts.mjs`のarticles配列に記事情報を入れます。配列とは、記事情報を並べたリストのことです。ここで指定するのはslugとMarkdownの場所。カテゴリ・キーワード・画像候補も同じ場所に入れます。

非エンジニアが一人で触ると不安なら、ここはAIエージェントに任せていいところです。貼る指示はこれで足ります。

新しい記事をbuild-post-artifacts.mjsのarticles配列へ追加したい。
slugはai-auto-post-wordpress。
Markdownはweb/articles/markdown/ja/ai-auto-post-wordpress.md。
カテゴリはlab-notes。
mainKeywordsはAI、WordPress、自動投稿。
既存記事の書き方に合わせて追加して。

5. 生成物を作る

次にターミナルでこのコマンドを動かします。

node web/posts/tools/build-post-artifacts.mjs

コマンドとは、パソコンに出す短い指示です。これは「記事ファイルから投稿用の生成物を作って」と頼んでいます。成功するとGutenberg HTMLとJSON-LDが作られて、SEOチェックと画像候補も同時に出てきます。

6. SEOチェックを読む

SEOチェックは点数だけ見ないほうがいいです。100点でも文章が薄ければ公開しない。特に見るのは禁句と本文の呼吸、そして内部リンク・外部リンク・FAQです。

自分が今回気にしたのは、短い文の連発です。「です。」「ます。」で細切れになると読み心地がAIっぽくなる。手順の場所は短くてもよいですが、体験談や判断の理由は少しゆっくり書いたほうが自然です。

7. 投稿スクリプトを確認する

いきなり投稿スクリプトを動かす前に、文法チェックをします。文法チェックとは、スクリプトの書き方が壊れていないかを見る作業です。

node --check web/posts/tools/publish-wp-drafts.mjs

問題がなければ、下書き投稿を実行します。

node web/posts/tools/publish-wp-drafts.mjs

このとき、スクリプト内の`status`が`draft`になっているかを必ず見ます。不安ならAntigravityへこう聞きます。

publish-wp-drafts.mjsを実行する前に、公開されない設定になっているか確認して。
statusがdraftか、公開済み記事を上書きしない安全策があるかを見て。
認証情報は表示しないで。

8. WordPressでプレビューする

下書きができたら、WordPress管理画面で開きます。プレビューURLが出る場合はそこから見ます。プレビューでは、実際の読者の画面として読みます。表が横に飛び出していないか。画像のaltが入っているか。見出しだけで作業が追えるか。FAQが検索意図に答えているか。

ここで修正があれば、Markdownへ戻します。WordPress上で直接直すとローカル原稿と差が出ます。長期運用ではローカルのMarkdownを正としておいたほうが管理しやすいです。

やってはいけないこと

便利になるほど、危ない操作も近くなります。自分用のルールはかなり単純です。

NG理由
最初から`publish`で投稿誤字やリンク切れがそのまま公開される
認証情報を記事やチャットへ貼る外部に漏れると危険
公開済み記事を自動更新意図せず内容が変わる
出典不明画像を再アップ著作権やライセンスが危ない
AI本文を読まずに通す事実誤認や薄い表現が残る
セキュリティプラグインを雑に止めるサイト防御が弱くなる
エラーを見ずに連打同じ失敗を増やす

特に公開済み記事の扱いは慎重にします。下書きなら直せますが、公開済みの記事は読者にも検索エンジンにも見えています。自動化の対象にするなら、別のスクリプトと確認フローを用意したほうがいいです。

この記事自体も実験記録にする

この記事はAI自動投稿のやり方を書いた記事で、そしてこの記事自体も同じ制作フローで作っています。Briefを書く。Markdownを書く。Gutenberg化・SEOチェック・画像候補作成まで進める。この流れです。

メタな話ですが、ここが面白いところです。AIを使ったブログ運営の実験を、AIを使って記事にしている。しかも作業場はAntigravity。詰まったらAIエージェントに聞く。

もう、分からなかったらAIエージェントに聞け笑、でいいと思っています。

もちろん最後の責任は人間です。でも非エンジニアが一人でREST APIのエラー文を読み解く必要はありません。エラー文を読む。原因を分ける。次の確認を出す。この部分はAIエージェントにかなり任せられます。人間は公開するかどうかを判断して、消してよいか、認証情報を出していないかを確認する。役割分担はそれでいいです。

次に整えたいこと

今回の仕組みはまだ完成形ではありません。下書き投入はできたし削除もできました。ただ、運用としてはまだ改善できます。

次にやること目的
1記事ずつWordPressへ下書き投入まとめて入れて混乱するのを防ぐ
画像の実アップロード外部画像URLのままにしない
自作図解のテンプレート化手順記事の分かりやすさを上げる
プレビュー確認表の固定化公開前の見落としを減らす
Search Console後の振り返り実際の流入からBriefを直す
公開日は人間が決めるサイト全体の流れを守る

特に画像は次の課題です。WEBから使う場合は出典とライセンスを確認する、不安なら自作図解にする、やむなくAI生成画像を使うときは生成物として管理メモを残す。このあたりを運用ルールとして固めたい。

記事の量産はできます。でも、公開する記事は1本ずつ見たいです。以前まとめて作ったときに薄くなった反省があるので、ここは急がないほうがいいと感じています。

コメント

タイトルとURLをコピーしました