MENU
現役看護師がClaude CodeでブログをAI化した実践記録

WordPress REST APIで自動投稿するときの注意点｜10のつまずきと解決策

AIと自動化の仕組み
この記事は 約25分 で読めます
目次
  1. WordPress REST API で自動投稿するときに起きる10のつまずき
  2. 認証まわりのつまずき（#1〜#4）
  3. #1 アプリケーションパスワードの認証エラー（401 Unauthorized）
  4. #2 セキュリティプラグインによる403
  5. #3 レンタルサーバーのREST API制限（海外IP遮断）
  6. #4 .env のキー名が違う
  7. frontmatter まわりのつまずき（#5〜#7）
  8. #5 categories が YAML リスト形式でない
  9. #6 frontmatter / 制作メモが本文に混入
  10. #7 カテゴリが重複生成された（YAMLクオート問題）
  11. SEOプラグイン連携のつまずき（#8）
  12. #8 SEO メタが反映されない（保護フィールド問題）
  13. メディア・アイキャッチのつまずき（#9）
  14. #9 アイキャッチが記事に紐づかない（featured_media = 0）
  15. 運用設計のつまずき（#10）
  16. #10 公開後に設定漏れが発覚（検査なし運用）
  17. つまずきを未然に防ぐチェックリスト
  18. 公開前チェック
  19. 公開後チェック
  20. よくある質問（FAQ）
  21. Q1: この記事のつまずきは C06「WordPress自動投稿」の記事と何が違うのか
  22. Q2: プログラミング未経験でもこの記事のつまずきに対処できるか

WordPress REST API で自動投稿を動かし始めたとき、最初の壁は「エラーが出て動かない」ではありません。もっと手前のところ——「動いたと思ったら何かがおかしい」という状態から始まります。

ステータスは publish になっているのに SEO メタが空のまま。カテゴリは設定したつもりなのに、管理画面を開くと謎の重複が増えている。アイキャッチは「アップロード成功」と表示されたのに記事には表示されない。

AIでブログ運営を自動化する5ステップ（ピラー記事）のStep 3 では REST API 自動投稿の基本フローを解説しました。Claude CodeでWordPress投稿を自動化する方法（C06）では7ステップの実装フローを順に解説しています。

この記事はそれとは別の切り口で作りました。「エラーが出た・何かおかしい」というときに、つまずきの名前から逆引きできる辞書として使ってもらうことを想定しています。

月25本・スクリプト30個超の実運用で遭遇した10件のつまずきを、症状・原因・解決・予防策の形で整理しました。

WordPress REST API で自動投稿するときに起きる10のつまずき

まず10件の一覧を提示します。自分の症状と近いものを見つけて、そのセクションに飛んでください。

# つまずき名 原因カテゴリ
1 アプリケーションパスワードの認証エラー（401） 認証設定
2 セキュリティプラグインによる403 プラグイン競合
3 レンタルサーバーのREST API制限（海外IP遮断） サーバー設定
4 .env のキー名が違う 認証設定
5 categories が YAML リスト形式でない frontmatter
6 frontmatter / 制作メモが本文に混入 frontmatter
7 カテゴリが重複生成された（YAMLクオート問題） frontmatter
8 SEO メタが反映されない（保護フィールド） SEOプラグイン
9 アイキャッチが記事に紐づかない（featured_media = 0） メディア
10 公開後に設定漏れが発覚（検査なし運用） 運用設計

C06（Claude CodeでWordPress投稿を自動化する方法）で紹介した「つまずき6選」（#4〜#9に対応）に、新規4件（#1〜#3・#10）を追加して10件に拡張しています。

認証まわりのつまずき（#1〜#4）

#1 アプリケーションパスワードの認証エラー（401 Unauthorized）

症状

requests.exceptions.HTTPError: 401 Client Error: Unauthorized

スクリプトを実行すると、投稿リクエストを送った瞬間に 401 が返ってくる。.env にパスワードは書いたのに認証が通らない。

原因

401 が出るケースはいくつかありますが、よく遭遇したのは以下の2パターンです。

パターンA：Base64エンコードが二重になっている

アプリケーションパスワードを使う場合、requests の HTTPBasicAuth に渡すと自動で Base64 エンコードされます。自前でエンコードしていた場合、Base64が二重になって認証が通りません。

# ❌ 自前でエンコードしている（二重エンコードになる）
import base64
credentials = base64.b64encode(f"{username}:{password}".encode()).decode()
headers = {"Authorization": f"Basic {credentials}"}

# ✅ HTTPBasicAuth に任せる（requests が自動でエンコードする）
from requests.auth import HTTPBasicAuth
auth = HTTPBasicAuth(username, app_password)
response = requests.post(url, auth=auth, json=payload)

パターンB：パスワードのスペース区切りをそのまま使っている

WordPress 管理画面でアプリケーションパスワードを発行すると、xxxx xxxx xxxx xxxx xxxx xxxx のようにスペース区切りで表示されます。このスペースは認証時に含めても除去しても、どちらでも正常に動きます。問題になるのは .env に貼り付けるときにコピーミスして半角スペースが全角になってしまうケースです。

.env の WP_APP_PASSWORD をコピーしてターミナルに貼り付け、目視で確認するのが確実です。

解決

  1. HTTPBasicAuth を使っているか確認（自前エンコードをやめる）
  2. .env の WP_APP_PASSWORD のスペースが半角かどうか確認
  3. WordPress 管理画面でアプリケーションパスワードを一度削除して再発行

予防策

  • HTTPBasicAuth に統一する。自前の Base64 エンコードは書かない
  • .env を設定したら python -c "from dotenv import load_dotenv; import os; load_dotenv(); print(repr(os.getenv('WP_APP_PASSWORD')))" で読み込み確認する

#2 セキュリティプラグインによる403

症状

requests.exceptions.HTTPError: 403 Forbidden

スクリプトから REST API にリクエストを送ると 403 が返ってくる。WordPress 管理画面からは問題なくログインできる。

原因

SiteGuard WP Plugin や All In One WP Security などのセキュリティプラグインが、スクリプトからの HTTP リクエストを不正なアクセスとみなしてブロックしているケースです。

SiteGuard の「ログインページ変更」機能が有効な状態でも、REST API エンドポイント（/wp-json/wp/v2/posts）へのアクセスに影響することがあります。また、WAF（Web Application Firewall）の設定が厳しいと、Python の requests ライブラリが送る User-Agent や、JSON ペイロードのサイズがトリガーになることもあります。

解決

ステップ1：セキュリティプラグインを一時無効化して切り分ける

まずセキュリティプラグインを無効化してからスクリプトを実行します。403 が解消されれば、プラグインが原因です。

ステップ2：ホワイトリストに IP を追加する（推奨）

スクリプトを実行しているマシンの IP アドレスを、セキュリティプラグインのホワイトリストに追加します。

SiteGuard の場合：
– 管理画面 → SiteGuard → IP許可リスト → スクリプトの実行元 IP を追加

All In One WP Security の場合：
– 管理画面 → WP Security → Firewall → ホワイトリストにIP追加

ステップ3：REST API アクセス制限の設定を確認

一部のセキュリティプラグインには「REST API アクセス制限」の設定があります。認証済みユーザーのみ許可、または特定のエンドポイントを許可リストに追加する設定を確認してください。

予防策

  • スクリプトの実行元 IP を事前にホワイトリストに登録してから運用を始める
  • 固定 IP 環境（VPS・自宅回線など）でスクリプトを実行する方が安定しやすい

#3 レンタルサーバーのREST API制限（海外IP遮断）

症状

ローカルマシンからは動くのに、GAS（Google Apps Script）や CI/CD 環境からスクリプトを実行すると 403 または タイムアウトが返ってくる。

原因

エックスサーバーには「WordPress セキュリティ設定」の中に「海外からのアクセスの制限」および「REST API への海外からのアクセスの制限」という設定があります。GAS は Google のサーバー（海外 IP）から実行されるため、この設定が有効だと REST API リクエストがブロックされます。

また、GitHub Actions や Cloudflare Workers のような外部サービスからスクリプトを実行している場合も同様です。

解決

エックスサーバーの場合：

  1. サーバーパネルにログイン
  2. 「WordPress セキュリティ設定」→ 対象ドメインを選択
  3. 「海外からのアクセスの制限」セクションで「REST API へのアクセスを制限する」のチェックを確認
  4. GAS や外部サービスから使いたい場合はこの制限を解除するか、IP を許可リストに追加

確認コマンド（ローカルから）：

curl -I https://your-site.com/wp-json/wp/v2/posts

200 が返れば REST API は有効。403 が返ればブロックされています。

予防策

  • スクリプトの実行環境（ローカル / GAS / 外部サーバー）と、サーバーのアクセス制限設定を最初にセットで確認する
  • GAS からの実行を想定している場合は、セットアップ時点でエックスサーバーの設定を確認する

#4 .env のキー名が違う

症状

ValueError: .env に不足があります: WP_BASE_URL, WP_USERNAME

.env ファイルに設定を書いたはずなのに「不足があります」と表示される。

原因

スクリプトが読み込む .env のキー名は3つに固定されています。

WP_BASE_URL
WP_USERNAME
WP_APP_PASSWORD

独自のキー名（BLOG_URL、WP_PASSWORD、WORDPRESS_USER 等）で書いていると、スクリプトがそれを見つけられずエラーになります。

解決

.env のキー名を規定の3つに統一します。

WP_BASE_URL=https://your-site.com
WP_USERNAME=your-wp-username
WP_APP_PASSWORD=xxxx xxxx xxxx xxxx xxxx xxxx

WP_SEO_PLUGIN はオプションで、使っている SEO プラグインに合わせて設定します（seopress / yoast / rankmath / none）。

WP_SEO_PLUGIN=seopress

予防策

.env を作成したら以下のコマンドで3キーの読み込みを確認する。

python -c "
from dotenv import load_dotenv
import os
load_dotenv()
print('WP_BASE_URL:', os.getenv('WP_BASE_URL'))
print('WP_USERNAME:', os.getenv('WP_USERNAME'))
print('WP_APP_PASSWORD:', 'SET' if os.getenv('WP_APP_PASSWORD') else 'NOT SET')
"

NOT SET が出たらキー名を修正します。

frontmatter まわりのつまずき（#5〜#7）

#5 categories が YAML リスト形式でない

症状

ValueError: 必須項目が不足しています: categories

frontmatter に categories は書いているのにエラーになる。または、カテゴリが設定されないまま投稿される。

原因

スクリプト（parse_post.py）は categories をリスト形式で読み込みます。以下のように文字列で書いていると、空リストとして処理されます。

# ❌ これはNG（文字列として読み込まれる）
categories: ブログ自動化

# ❌ これもNG（インライン配列はパースしない）
categories: [ブログ自動化]

parse_post.py の parse_front_matter() は LIST_FIELDS = {"tags", "categories"} として定義されており、- 項目名 の形式のみを受け付けます。

解決

# ✅ これが正しい形式
categories:
  - ブログ自動化

複数のカテゴリを設定する場合も同様です。

categories:
  - ブログ自動化
  - WordPress効率化

tags も同じ形式が必要です。

tags:
  - WordPress
  - REST API
  - Python

予防策

  • frontmatter テンプレートに最初からリスト形式で書いておく
  • 記事を書く前に frontmatter の categories と tags をリスト形式で入力する習慣をつける
  • C06（Claude CodeでWordPress投稿を自動化する方法）のfrontmatter サンプルをそのままコピーして使う

#6 frontmatter / 制作メモが本文に混入

症状

投稿が完了してサイトを確認すると、記事の先頭に --- と YAML テキストが表示されている。または、記事の末尾に「自己チェック」「タイトル案」「SEOタイトル案」などの制作メモが残っている。

原因

2つのパターンがあります。

パターンA：frontmatter の切り出し失敗

parse_front_matter() の正規表現パターンは ^---\n(.*?)\n---\n(.*)$ です。frontmatter の開始 --- と終了 --- の間にある内容が frontmatter として切り出されます。

frontmatter 内のフィールド値に --- が含まれていたり、frontmatter の前後に余分な改行があったりすると、切り出しが失敗して frontmatter が本文に残ります。

パターンB：制作メモが本文ファイルに書かれたまま公開

04_draft_v1.md の末尾に「自己チェック」「タイトル案」「品質審査前確認」などのメモを書いていた場合、これらがそのまま本文として投稿されます。

これは 2026-04-21 に実際に発生した公開品質事故です（ryman-nurse.com の複数記事で本文末に制作メモが残ったまま公開されました）。

解決

publish_post.py には check_production_meta_contamination() 関数が組み込まれており、公開前に16パターンの制作メモキーワードを検出します。

自己チェック / 品質審査前確認 / 品質審査 / メタ情報案 / タイトル案 /
SEOタイトル案 / meta description案 / ディスクリプション案 /
v{数字}修正 / 修正メモ / 制作メモ / 編集メモ / 構成メモ /
タグ候補 / カテゴリ候補 / スラッグ案

これらのキーワードが本文に含まれていると、スクリプトは公開を中止してエラーを出します。

❌ 本文に制作メモが混入しています:
  - [自己チェック] L234: ## 自己チェック結果

回避方法：制作メモはドラフトファイルに書かない

ワークフローのルールとして、メタ情報案・自己チェック・修正メモは 04_draft_v1.md（本文ファイル）には書かず、04_meta_v1.md（非公開の別ファイル）に分離します。本文ファイルには公開される本文だけを置くのが原則です。

--allow-meta-keywords フラグを使うと強制的に公開できますが、これは事故対応用のフラグです。通常は使わないことをすすめます。

予防策

  • 04_draft_v{N}.md には本文のみ。制作メモは 04_meta_v{N}.md に書く
  • 公開前に本文ファイルをスクロールして末尾まで目視確認する
  • スクリプトが止まったときは「制作メモが混入しているかもしれない」を先に疑う

#7 カテゴリが重複生成された（YAMLクオート問題）

症状

WordPress 管理画面でカテゴリ一覧を開くと、同じ名前のカテゴリが2つ存在している。

ブログ自動化         （正しい）
"ブログ自動化"       （クオート付きで新規作成された）

記事はクオート付きのカテゴリに紐づいているため、カテゴリアーカイブが機能しない状態になっています。

原因

frontmatter でカテゴリ名をクオートで囲んで書いていたケースです。

# これが原因
categories:
  - "ブログ自動化"

旧バージョンの parse_post.py はクオートを取り除かずに WordPress に渡していたため、"ブログ自動化" という名前のカテゴリが新規作成されていました。

現在の parse_post.py には _strip_yaml_quotes() 関数が追加されており、パース時にクオートを自動除去します。

def _strip_yaml_quotes(value: str) -> str:
    if len(value) >= 2 and value[0] == value[-1] and value[0] in ('"', "'"):
        return value[1:-1]
    return value

ただし _strip_yaml_quotes() が修正される前に作成された記事、または古いバージョンのスクリプトを使っている場合は、クオート付きカテゴリが既に存在している可能性があります。

解決

既存の重複カテゴリを削除する：

  1. WordPress 管理画面 → 投稿 → カテゴリ
  2. クオート付きの不正なカテゴリ（"ブログ自動化" など）を確認
  3. 対象記事のカテゴリを正しいものに変更してから、不正カテゴリを削除

frontmatter のクオートを取り除く：

# ❌ クオートで囲まない
categories:
  - "ブログ自動化"

# ✅ クオートなし
categories:
  - ブログ自動化

--allow-new-categories を付けない安全運用：

publish_post.py はデフォルトで新規カテゴリの自動作成を禁止しています。WordPress に存在しないカテゴリ名を送るとエラーになる設計です。これはカテゴリの誤爆（タイポや名前違いで別カテゴリが量産される）を防ぐための安全装置です。

--allow-new-categories フラグを付けると新規作成が許可されますが、このフラグは「新しいカテゴリを意図的に作るとき」以外は使わないことをすすめます。

予防策

  • frontmatter の categories / tags はクオートなしで書く
  • --allow-new-categories は意図的な新規作成のときだけ使う
  • 月1回程度、WordPress のカテゴリ一覧を目視して重複がないか確認する

SEOプラグイン連携のつまずき（#8）

#8 SEO メタが反映されない（保護フィールド問題）

症状

スクリプトは正常終了して「✅ 公開が完了しました」と表示されるが、自動検査の結果に「❌ SEOタイトル」「❌ SEO説明文」が出る。WordPress 管理画面で記事を開くと、SEO プラグインのタイトル・説明文の欄が空のまま。

原因

SEOPress・Yoast SEO・RankMath のメタフィールドは「保護フィールド（protected field）」として設定されており、デフォルトでは WordPress REST API からの書き込みが拒否されます。

具体的なフィールド名は以下の通りです。

プラグイン タイトルフィールド 説明文フィールド
SEOPress _seopress_titles_title _seopress_titles_desc
Yoast SEO _yoast_wpseo_title _yoast_wpseo_metadesc
RankMath rank_math_title rank_math_description

スクリプト（build_seo_meta()）はこれらのフィールドに値を送っていますが、PHP 側でフィールドの登録がされていないと WordPress が受け付けません。

競合調査した上位9記事のうち、この問題に触れた記事はゼロでした。「REST API で SEO メタを自動投稿できる」という情報は見つけやすいですが、「なぜ反映されないのか」「どう解決するか」はほとんど書かれていません。

解決

WordPress 側で register_post_meta を使ってフィールドを登録し、REST API からの書き込みを許可します。

WPCode（旧 Code Snippets）プラグインを使う方法：

  1. WPCode プラグインをインストール・有効化
  2. 管理画面 → Code Snippets（または WPCode）→ 新規スニペット追加
  3. 以下の PHP コードを貼り付けて有効化

SEOPress を使っている場合：

add_action('init', function() {
    register_post_meta('post', '_seopress_titles_title', [
        'show_in_rest' => true,
        'single'       => true,
        'type'         => 'string',
    ]);
    register_post_meta('post', '_seopress_titles_desc', [
        'show_in_rest' => true,
        'single'       => true,
        'type'         => 'string',
    ]);
});

Yoast SEO を使っている場合：

add_action('init', function() {
    register_post_meta('post', '_yoast_wpseo_title', [
        'show_in_rest' => true,
        'single'       => true,
        'type'         => 'string',
    ]);
    register_post_meta('post', '_yoast_wpseo_metadesc', [
        'show_in_rest' => true,
        'single'       => true,
        'type'         => 'string',
    ]);
});

RankMath を使っている場合：

add_action('init', function() {
    register_post_meta('post', 'rank_math_title', [
        'show_in_rest' => true,
        'single'       => true,
        'type'         => 'string',
    ]);
    register_post_meta('post', 'rank_math_description', [
        'show_in_rest' => true,
        'single'       => true,
        'type'         => 'string',
    ]);
});

スニペットを有効化したあと、スクリプトを再実行すると自動検査で「✅ SEOタイトル」「✅ SEO説明文」が表示されるようになります。

SEO Simple Pack を使っている場合：

SEO Simple Pack は上記3プラグインの対応リストに含まれていません。現時点では WP_SEO_PLUGIN=none に設定して、公開後に表示される手動ガイドに従って管理画面で入力する運用になります。

WP_SEO_PLUGIN=none

none の場合、スクリプトは SEO フィールドを送らず、公開後に手動入力用のガイドを表示します。

SEO メタの自動生成（タイトル・説明文の Claude Code への自動生成依頼）については「AIでSEOタイトル・メタディスクリプションを作る方法」（準備中）で詳しく解説予定です。

予防策

  • ブログを新規に立ち上げる際は、最初に register_post_meta スニペットを登録してから投稿を始める
  • .env の WP_SEO_PLUGIN に使っているプラグイン名を正確に設定する（seopress / yoast / rankmath / none）
  • 公開後の自動検査（verify_published_post()）を必ず実行して、SEO 反映を確認する

メディア・アイキャッチのつまずき（#9）

#9 アイキャッチが記事に紐づかない（featured_media = 0）

症状

スクリプトの実行ログに「アイキャッチID : 1234」と表示されるが、公開された記事にアイキャッチ画像が表示されない。公開後の自動検査でも「❌ アイキャッチ」が出る。WordPress メディアライブラリには画像は存在している。

原因

2つのパターンがあります。

パターンA：featured_media: 0 を送っている

画像のアップロードには成功しているが、build_post_payload() が featured_media: 0 を payload に含めて送っている状態です。WordPress は featured_media: 0 を「アイキャッチなし」として処理します。0 を送ると既存のアイキャッチが削除される挙動もあるため、アイキャッチなしの記事を更新するときに意図せず消えることもあります。

パターンB：upload_media() と featured_media の設定が分離している

画像アップロードのレスポンスから media_id を取得する処理と、featured_media に設定する処理が分離していて、media_id が正しく渡されていないケースです。

解決

build_post_payload() 内で media_id > 0 のときだけ featured_media を payload に含めるようにします。

def build_post_payload(frontmatter, body_html, media_id, category_ids, tag_ids, seo_meta):
    payload = {
        "title": frontmatter["title"],
        "content": body_html,
        # ... 他のフィールド
    }
    # media_id が 0 または None のときは featured_media を送らない
    # （0 を送ると既存のアイキャッチが削除される）
    if media_id and media_id > 0:
        payload["featured_media"] = media_id
    return payload

また upload_media() は画像アップロードと alt テキスト設定をまとめて処理して、media_id を返す設計にします。

def upload_media(settings, image_path, alt_text):
    # 1. 画像をアップロードして media_id を取得
    media_id = _upload_image(settings, image_path)
    # 2. alt テキストを設定
    _set_alt_text(settings, media_id, alt_text)
    return media_id  # media_id を呼び出し元に返す

記事更新時にアイキャッチを変えない場合：

既存記事を更新するとき、アイキャッチ画像を変更しない場合は frontmatter["eyecatch"] を空にして、media_id = 0 のまま payload を組み立てます。featured_media が payload に含まれなければ、既存のアイキャッチは保持されます。

# 更新時にアイキャッチを変えない場合
eyecatch_val = frontmatter.get("eyecatch", "")
media_id = 0
if eyecatch_val:
    media_id = upload_media(settings, image_path, alt_text)
# media_id = 0 のときは build_post_payload 内で featured_media を送らない

予防策

  • 公開後の自動検査（verify_published_post()）で featured_image のチェックを必ず確認する
  • eyecatch フィールドが frontmatter に設定されているかを公開前に目視確認する
  • 更新時にアイキャッチを意図して消したい場合のみ featured_media: 0 を明示的に送る

運用設計のつまずき（#10）

#10 公開後に設定漏れが発覚（検査なし運用）

症状

記事は公開されたが、後日確認するとカテゴリが未設定、SEO メタが空、アイキャッチが表示されていない、ステータスが draft のままなど、複数の設定漏れが発覚する。1つの記事ではなく、複数記事で同様の問題がある。

原因

「公開できた＝設定が完了した」と認識したまま次の記事に進んでいる運用です。スクリプトが正常終了しても、個々の設定値が正しいかどうかは別の話です。

手動確認には限界があります。確認すべき項目（ステータス・カテゴリ・タグ・アイキャッチ・SEOタイトル・SEO説明文・ライブURL）を毎回すべて目視するのは、月25本の運用では現実的ではありません。

解決

verify_published_post() で7項目の自動検査を実行します。現在の publish_post.py には公開後の自動検査が組み込まれており、新規公開時に自動で実行されます。

def verify_published_post(settings, post_id, frontmatter):
    """
    公開済み記事の設定を自動検査する。
    チェック項目: ステータス, カテゴリ, タグ, アイキャッチ, SEO, ライブURL
    """
    data = requests.get(f"{base_url}/wp-json/wp/v2/posts/{post_id}", auth=auth).json()
    results = {
        "status":        data.get("status") == "publish",
        "categories":    len(data.get("categories", [])) > 0,
        "tags":          len(data.get("tags", [])) > 0,
        "featured_image": data.get("featured_media", 0) > 0,
        "seo_title":     verify_seo(...)["title"] not in ("（未反映）", ""),
        "seo_description": verify_seo(...)["description"] not in ("（未反映）", ""),
        "live_url":      requests.get(data["link"]).status_code == 200,
    }
    return results

実行後のログには以下のような検査結果が表示されます。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  自動検査結果
  ✅ 公開ステータス
  ✅ カテゴリ設定
  ✅ タグ設定
  ❌ アイキャッチ
  ✅ SEOタイトル
  ✅ SEO説明文
  ✅ ライブURL
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  ⚠️ ❌ の項目は WordPress 管理画面で確認してください

❌ が出た項目だけ管理画面で修正します。✅ が全項目に並んだら完了です。

品質審査ファイルとの連携：

ブログ記事制作のワークフローでは、05_review_v{N}.md（品質審査ファイル）に「合格」の判定がない記事は publish_post.py が公開を拒否します。記事の内容品質（テキスト面）と公開後の設定品質（メタ面）の両方を検査する二重構造になっています。

予防策

  • 公開後の自動検査結果を必ず確認してから次の記事に進む
  • ❌ が出た項目は当日中に修正する（翌日以降に先送りしない）
  • 月1回程度、既存記事を verify_published_post() で一括検査する（抜け漏れの定期確認）

つまずきを未然に防ぐチェックリスト

10件のつまずきを「公開前」「公開後」に分類した実用チェックリストです。

公開前チェック

# チェック項目 確認方法 対応つまずき
1 .env の3キーが正しいか python -c "from dotenv import load_dotenv; import os; load_dotenv(); print(os.getenv('WP_BASE_URL'))" #3・#4
2 セキュリティプラグインのIP設定 実行元IPがホワイトリストにあるか管理画面で確認 #2
3 サーバーのREST API制限 エックスサーバーの「WordPress セキュリティ設定」を確認 #3
4 register_post_meta スニペットが有効か WPCode（Code Snippets）の管理画面でスニペットが「有効」になっているか確認 #8
5 categories がリスト形式か frontmatter の categories: の下に - カテゴリ名 があるか目視 #5
6 制作メモが本文に混入していないか parse_post.py を実行して check_production_meta_contamination() の結果を確認 #6
7 frontmatter のクオートを取り除いたか categories / tags の値がクオートで囲まれていないか確認 #7
8 eyecatch パスが正しいか frontmatter の eyecatch フィールドに正しいパスが入っているか目視 #9

公開後チェック

# チェック項目 確認方法 対応つまずき
9 7項目自動検査がすべてパスするか publish_post.py 実行後の「自動検査結果」を確認 #10
10 ライブURLにアクセスできるか 自動検査の ✅ ライブURL を確認 #10
11 SEO メタが反映されているか 自動検査の ✅ SEOタイトル / ✅ SEO説明文 を確認 #8
12 アイキャッチが表示されているか サイトをブラウザで開いて目視確認 #9

よくある質問（FAQ）

Q1: この記事のつまずきは C06「WordPress自動投稿」の記事と何が違うのか

C06（Claude CodeでWordPress投稿を自動化する方法）は実装フロー型の記事で、「7ステップの処理を順に実装する」という読者を想定しています。C06のつまずき6選は「実装中に遭遇した問題」として紹介しています。

この記事（C10）は逆引き辞書型です。「すでに動いているが何かがおかしい」「エラーメッセージが出た」というときに、症状から原因と解決策を引けることを目的にしています。C06のつまずき6選を基盤に、C06では触れていない4件（#1認証401・#2セキュリティプラグイン403・#3サーバーREST API制限・#10公開後検査なし運用）を追加して10件に拡張しました。

両記事は補完関係にあります。「自動投稿を初めて作る」はC06を、「動かしていて何かおかしい」はこの記事を参照してください。

Q2: プログラミング未経験でもこの記事のつまずきに対処できるか

対処できます。コードを自分で書く必要はありません。

この記事のつまずきに対処するのに必要な操作は主に2種類です。

  1. 設定変更：.env のキー名を直す・frontmatter のフォーマットを直す・管理画面でIP許可リストに追加するなど、テキストの書き換えや管理画面の操作
  2. PHP スニペットの貼り付け（#8のみ）：WPCode プラグインにコードをコピー＆ペーストする操作

コマンドの実行はコピー＆ペーストで対応できます。エラーメッセージが出たら Claude Code に「このエラーはどういう意味ですか？」と貼り付けて聞くのが最速の解決策です。

私自身、非エンジニアのまま月25本・スクリプト30個超を運用しています。「コードを書かない」ではなく「Claude Code にコードを書かせる」スタンスで、エラーへの対処も「エラーを貼り付けて聞く」の繰り返しです。

この記事で紹介した10件のつまずきは、私が実際に遭遇して詰まったものです。特に「SEO メタが反映されない」「アイキャッチが消える」あたりは、動作の仕様を知らないと原因の見当がつかないので時間を取られました。

同じところで詰まっている人の参考になれば、と思っています。運用していて新しいつまずきが出てきたら、随時この記事に追記していきます。

REST API のつまずきと解決の詳細プロセスは、note の有料記事で公開しています（500円）。

note：WordPress自動投稿【コード公開】

AIと自動化の仕組み
Python REST API WordPress トラブルシューティング 自動投稿
よかったらシェアしてね！
  • URLをコピーしました！
  • URLをコピーしました！

この記事を書いた人

hide1022のアバター hide1022

関連記事

目次