ChatGPT APIでWordPress記事作成を自動化する方法｜開発・運用で分かった注意点

※PR・広告を含みます

私はWordPressの記事作成ツールを実際に運用し、生成速度よりも「誤った記事を公開しない仕組み」の方が重要だと分かりました。ChatGPT APIは下書きを作る工程には使えますが、検索意図、事実、文章、リンク、公開日時まで一度に任せると、誤情報や重複を止めにくくなります。

現在の運用では、APIで生成した文章をまず下書きとして保存し、品質検査を通った投稿だけを人が確認します。この記事では、その構成と失敗から直した点を、WordPressへ実装する順番で説明します。

APIキーは外部へ表示せず、サーバー側またはローカル設定で読む
AIの出力をそのまま公開せず、構造化された下書きとして扱う
重複、事実、HTML、広告リンク、投稿状態を保存前後に検査する

【ガチ実践】ChatGPTより優秀なCodexで初心者でも約3000円のAI社員を作り出して完全自動化できる方法教えるで！

目次閉じる

私が使っている記事作成パイプライン
APIキーの優先順位と扱い
本文生成で失敗したときに確認する順番
重複と不自然なキーワード連結を保存前に止める
WordPressへ保存するときの保護項目
公開前のチェックリスト
公式情報
まとめ

私が使っている記事作成パイプライン

一つの長い指示で記事作成から投稿までを任せるのではなく、候補選定、調査、構成、本文、検査、保存を分けます。途中で問題が見つかった場合は「失敗」だけで終わらせず、何が原因で下書きにしたかを記録します。

工程	ツールが行うこと	人が確認すること
キーワード候補	既存投稿との文字列・検索意図照合	本当に別の記事が必要か
調査	候補URLと要点の整理	一次情報か、日付が現在も有効か
構成	見出し案と必要要素の作成	不自然な用語連結や重複見出し
本文	下書き生成	事実、文法、体験、断定の強さ
WordPress保存	投稿本文とメタ情報を保存	投稿状態、日時、公開表示

APIキーの優先順位と扱い

複数の生成サービスを使う場合は、どのAPIを使ったかが曖昧にならないよう、優先順位を一か所で決めます。私のツールでは、OpenAI、Gemini、Claude、Cursorの順に判定し、入力済みの最優先キーだけを使います。OpenAIのキーがあるのにCursorへ流れる、といった分岐を防ぐためです。

APIキーは記事本文、ログ、エラー文へ出しません。OpenAI公式も、APIキーをブラウザーなどのクライアント側へ公開せず、環境変数またはキー管理サービスからサーバー側で読み込むよう案内しています。

本文生成で失敗したときに確認する順番

HTTPの成功・失敗だけでなく、応答が完了状態かを見る
本文が空でないか、途中で切れていないかを確認する
見出しと本文を分けて解析し、H2直下の説明不足を検出する
不自然なタイトル、存在しない用語、定型的な導入を止める
理由をログに出し、同じキーワードを無限に再試行しない

以前は「本文生成に失敗しました」だけが表示され、APIエラーなのか、空本文なのか、品質検査で止めたのか分かりませんでした。現在は、通信エラー、再試行可能、候補なし、品質不合格を分けて表示するようにしています。

重複と不自然なキーワード連結を保存前に止める

「AI」「アフィリエイト」「Codex」のような複数語を、そのまま一つの製品名のようにつなげると、不自然なタイトルになります。候補語は、主題、手段、製品名、検索目的に分けてから文章にします。日本語表記と英語表記も同じ概念として正規化し、「ティックトック」と「TikTok」を別記事として扱わないようにします。

タイトルが違っても、結論や見出しが近ければ重複候補です。逆に同じ製品名を扱っていても、検索導線と自動化の担当範囲のように、結論と見出しが分かれていれば別記事として扱えます。

WordPressへ保存するときの保護項目

更新対象は投稿本文と、必要な投稿メタだけに限定します。既存投稿を直すときは、投稿ID、スラッグ、日時、ステータス、著者、カテゴリ、タグ、アイキャッチを保存前後で比較します。トップページや固定ページを記事修正処理から更新しないよう、WordPress RESTの書き込み先も投稿エンドポイントに限定しています。

アフィリエイトリンクは本文内に残しても、ツール自身が計測URLへアクセスしてはいけません。リンク切れ確認、OGP取得、短縮URL展開の対象からASP計測URLを外し、保存された文字列だけを検査します。