【PR】この記事には広告リンクが含まれています。
WordPressの自動投稿で最も怖いのは、コードが止まることより、もっともらしい未確認情報がそのまま公開されることです。文章が自然でも、本人が使っていないサービスを「実際に使った」と書く、確認していない金額を具体的に入れる、古い公式URLを残す、広告リンクの属性やPR表記を落とす、といった問題は読者から見えにくく、公開後の信頼を損ないます。
筆者の運用では、実体験DB、一次情報マニフェスト、記事本文、公開後のWordPress再取得を記事IDでつなぎ、品質ゲートを通過した記事だけを公開キューへ入れています。2026年8月には、未解決マーカーの検査が注意事項として書かれた正常な文章まで止める誤検知がありました。判定条件を狭めてテストし直した経験から、品質ゲートは厳しいだけでなく、根拠と文脈を正しく区別できることが重要だと分かりました。
結論：品質ゲートは「根拠・構造・リンク・公開結果」の4層にする
公開前検査を一つの巨大な正規表現へまとめると、何を保証しているのか分からなくなります。実体験の根拠、記事構造、外部・内部リンク、WordPress反映結果の4層に分け、各層で重大エラーと警告を定義します。
重大エラーは公開を止めます。使用可のEXP IDがない、一人称の数字が根拠と一致しない、slugが重複している、広告リンクが未取得、公開予定の内部リンクが404、といった状態です。警告は、表記ゆれや見出しの長さなど、公開可否を直ちに左右しない項目へ限定します。
- 根拠ゲート：実体験IDと一人称表現を照合
- 構造ゲート：本文長、見出し、SEO、画像を検査
- リンクゲート：公式・内部・広告リンクを検査
- 公開ゲート：WordPressのstatusと表示を再取得
【実体験】厳しすぎる文字列検査が正常記事を止めた
当時の検査では、保留を示す特定の単語が本文中に存在すると公開停止する仕組みでした。しかし記事内で「この種の保留表現を残さない」と注意点を説明しただけでも、同じ単語が含まれるため停止しました。未解決状態と、未解決状態を避ける説明文を区別できていなかったのです。
応急処置では本文の表現を変え、その後、HTMLコメント、行頭の明確な保留記号、属性内の置換前値など、実際のプレースホルダーに近い形だけを検出するように修正しました。修正後は当時のテスト41件を通しました。ただし、テスト件数は将来の安全を保証する数字ではなく、変更時点の確認結果です。
最初に実体験DBを候補選定の入口にする
記事テーマを検索キーワードだけから作ると、書きやすい一般論へ流れやすくなります。品質ゲートの前段では、本人が実際に使った商品・サービス、行った手続き、失敗、改善、金額、判断理由を実体験DBから抽出し、事実確認済みかつ使用可の情報だけを候補にします。
記事ごとに最低1件のEXP IDを必須にし、0件ならキーワード需要が高くても公開候補へ進めません。未体験の比較記事を作らず、同じ実体験を別の検索意図へ展開する場合も、既存記事と結論や手順が重ならないかを確認します。
一次情報マニフェストに使える事実と禁止表現を分ける
一次情報マニフェストは、記事ID、使用するEXP ID、出所、使ってよい事実、使ってよい数字、本人の判断、禁止表現をまとめた台帳です。本文生成前に作ることで、原稿が根拠から離れていないかを後から機械的に確認できます。
禁止表現も重要です。たとえば未使用サービスを使ったと書く、すべての人に同じ結果になると断定する、未確認の処理時間や収益を補う、といった禁止事項を先に明示します。不明点は「確認できない」と扱い、自然な文章にするために記憶を補完しません。
一人称・体験表現を全文から抽出する
本文から「私は」「筆者は」「実際に」「使った」「確認した」「感じた」「おすすめ」といった表現を抽出し、周辺文をマニフェストへ照合します。表現だけでなく、同じ文や近接文にある数字、日付、件数、金額も確認します。
一般情報を書く場合は、本人の体験と混ぜず「公式では」と出所を明示します。公式仕様を筆者の操作結果のように書かないこと、本人の一例を普遍的な正解へ広げないことが大切です。根拠が見つからない一人称文は削除するか、一般情報として書き直します。
本文構造とSEO項目を機械検査する
構造ゲートでは、実質本文8,000〜10,000字、本文中のH1なし、H2構成、導入、FAQ、まとめ、カテゴリ、タグ、slug、メタディスクリプション、アイキャッチ、alt、SEO・OGを確認します。文字数だけを満たすための繰り返しは避け、検索意図への回答、実体験、公式補足、判断基準、手順、失敗回避を順に配置します。
タイトルとH1はWordPressテーマが出力するため、本文HTMLにH1を入れません。slugは英数字とハイフンに限定し、既存投稿と下書きの両方で重複を検索します。画像は16:9で、ファイル名、alt、Drive IDを記事IDへ紐付けます。
広告記事はPR・属性・計測を一組で確認する
広告リンクがある記事では、冒頭500字以内のPR表記、提携済み案件、取得済みの有効URL、rel=”sponsored nofollow”、A8の計測ピクセルを一組で検査します。リンク先の案件と記事本文が一致しているかも確認します。
過去には広告リンクの飛び先を取り違える失敗があり、表示テキストだけでは判断できないことを経験しました。CTAのhref、リダイレクト先、計測ピクセル、案件IDを記事単位で照合し、未提携案件や置換前URLは除外します。詳しい確認手順はA8.netの商品リンクで飛び先を間違えない方法でも整理しています。
公式リンクは現行ページと確認日を分けて記録する
公式情報は執筆時点でページが存在し、内容が記事の主張を支えているかを確認します。URLが200でも内容が移転案内やトップページだけなら十分ではありません。404や410は現行ページへ差し替え、競合記事の要約を公式根拠の代わりにしません。
確認日は「公式情報を確認した日」と分かる文脈で管理します。一人称の経験日と混在すると数値検査が誤判定しやすいため、調査タブにURL、確認日、使える事実、更新性を分けて保存します。
内部リンクは公開済みページだけに限定する
内部リンクは読者の次の疑問へ答え、収益記事へ自然につなぐために使います。公開前の記事へリンクすると、公開順のずれで404になるため、公開済みURLだけを本文へ入れます。リンク先タイトル、slug、HTTP状態、記事内容との関係を確認します。
同じアンカーテキストを機械的に繰り返すのではなく、文脈に合わせます。自動投稿の全体手順はGASでWordPressを自動投稿した実例、品質方針の全体像はAIとApps Scriptで品質を落とさない運用ルールへつなげます。
重大エラーと警告を明確に分ける
すべてを重大エラーにすると、正常な記事が止まり続け、運用者が検査を無視するようになります。逆に警告ばかりでは誤公開を防げません。読者への虚偽、法令・金銭情報の誤り、広告表示の欠落、公開不能につながる問題を重大エラーにします。
表記ゆれ、見出しの長さ、補助的なタグ不足は警告として修正できます。ゲートのルールを変更した場合は、過去に止めるべきだった例と通すべきだった例の両方で回帰テストします。
- 重大：EXP IDなし、根拠なし一人称、slug重複、広告未提携、404内部リンク
- 重大：本文や画像が欠落、statusがpublishでない
- 警告：表記ゆれ、タグ数、見出しの冗長さ
- 手動確認：画像内文字、スマホ表示、CTAの違和感
公開後ゲートでWordPressの実データを照合する
公開前に合格しても、WordPress反映時の変換や通信失敗は残ります。投稿後にREST APIで同じ投稿を再取得し、status、slug、title、content、featured_media、categories、tags、SEO・OGを予定値と比較します。
その後、公開URLがHTTP 200で表示されることを確認します。週4本なら4本すべてを個別に照合し、1本でも不一致なら週全体を完了と報告しません。筆者の運用では、URL・公開状態・時刻・サムネイルの個別確認を完了条件へ追加しました。
品質ゲートを運用する順番
検査順は、安く早く失敗を発見できる項目から始めます。実体験IDがない記事へ詳細なリンク検査や画像生成を行うと無駄が増えるためです。
- 実体験DBの事実確認済み・使用可を確認
- 一次情報マニフェストを作成
- 本文生成後に一人称と数字を全件照合
- 構造・SEO・PR・広告属性を検査
- 公式・内部・広告リンクを確認
- アイキャッチを目視確認
- WordPressへ公開し、APIと公開ページを再確認
品質指標を本数だけにしない
週4本という公開本数は運用量の目標ですが、記事品質を表す数字ではありません。重大エラー0、使用EXP ID、実質本文長、公開済み内部リンク、広告検査、公開後照合といった条件を同時に持ちます。1本足りないからといって条件を緩めず、別の実行可能候補へ差し替えます。
公開後は30日・60日・90日の評価日を設定できますが、GSCやGA4が未接続なら計測済みと記録しません。データが取得できるようになった時点で、表示回数、クリック、読了や収益を記事別に確認します。
一般情報の割合を増やしすぎない
公式情報は記事の正確性に必要ですが、公式ページを長く言い換えるだけでは、本人の実体験を記事資産へ変える目的から外れます。各見出しで、体験から得た判断や失敗回避を中心にし、公式情報は適用条件や現在の仕様を補う範囲にします。
体験が薄い部分を一般論で埋めて8,000字へ伸ばすのではなく、操作順、確認資料、判断した理由、失敗時の復旧、対象外の範囲を掘り下げます。それでも中心的な実体験が不足するなら公開候補を変えます。
公開後の指摘をゲートへ戻す
本人が公開後に見つけた文字被り、リンク違い、説明の違和感は、その記事だけ直して終わらせず、再発条件を品質ゲートへ追加します。画像なら安全余白と目視確認、リンクなら案件IDと到達先、文章なら禁止表現やマニフェスト項目へ戻します。
過去の失敗を検査ルールとテストケースへ変えることで、週次運用のたびに同じ確認を口頭で依頼する必要が減ります。ゲート変更後は既存の正常例が止まらないことも確認します。変更理由も記録します。
競合調査は体験の代わりにしない
検索上位記事は、読者が期待する論点、見出し、用語、更新時期を把握するために使います。しかし、競合の記事にある手順や評価を本人の体験へ置き換えてはいけません。競合調査で見つけた事実は公式一次情報へ遡り、記事内では公式情報として扱います。
差別化は、競合より多くの一般論を並べることではなく、本人がどこで詰まり、何を直し、どの範囲を確認できたかを具体化することです。検索需要があっても、実体験の中心が作れないテーマは保留します。
生成時と公開時に二重検査する
原稿生成直後の検査では、マニフェスト照合、構成、リンク候補、広告候補を確認します。公開直前の検査では、その後の編集で根拠なし表現が増えていないか、リンクや画像が確定値へ変わったか、WordPress下書きが最新版かを確認します。
二重検査は同じ処理を無意味に繰り返すのではなく、対象時点が違います。生成時は文章品質、公開時は配置・接続・反映値を重視します。最終編集後に検査結果を使い回さないことが重要です。
変更履歴と承認者を残す
自動修正が入った場合、記事ID、変更前後、理由、実行時刻、検査結果を残します。一人称の数字を削除した、公式URLを差し替えた、広告属性を追加した、といった変更が追えると、公開後の違和感を調査しやすくなります。
本人の公開前承認を不要とする運用でも、AI検査済みと本人の公開後確認を区別します。本人が差し替えたアイキャッチや修正した表現は、その連絡を受けて管理表へ反映します。確認していない状態を承認済みにしません。
公開停止後の差し替え候補を用意する
重大エラーが直ちに解消できない記事を無理に公開すると、週次本数のために品質基準を下げることになります。記事制作プランには使用可の実体験がある予備候補を持ち、事実関係が未確定の候補は別テーマへ差し替えます。
差し替え時も、本文を短く作って穴埋めするのではなく、同じ品質ゲートを通します。公開予定を30本程度持つ目的は量産ではなく、実体験の強さ、収益性、競合性、内部リンク効果を見ながら安全に選び直せる余地を作ることです。
検索意図と実体験の対応を確認する
実体験があるだけでは、検索者の疑問に答える記事になるとは限りません。候補化した実体験から、読者が知りたい結果、手順、判断基準、失敗回避を整理し、主要キーワードの検索意図と対応させます。体験にない比較軸を無理に増やさず、足りない一般情報は公式一次情報で補助します。
既公開記事と同じ体験を使う場合は、主質問を変えます。本記事は品質ゲートの設計に集中し、複数記事のエラー分離や公開後ステータス確認の詳細は別記事へ分けます。タイトルだけを変え、同じ結論や見出しを繰り返す候補はカニバリとして見送ります。
数字の根拠を文章単位で管理する
数字は読者の理解を助けますが、もっともらしい誤情報にもなります。金額、件数、日付、所要時間、割合、順位を抽出し、本人の実績、公式仕様、計算例のどれかを付けます。本人の実績ならEXP ID、公式仕様ならURLと確認日、計算例なら前提と式を記録します。
一人称を含む文に数字がある場合は、特に厳しく確認します。根拠が見つからなければ、事実を損なわない範囲で「複数」「一定期間」などの非数値表現へ直します。読者に有用だからという理由で未確認数字を補いません。
法令・税務・社会保険は更新性を高く設定する
法令、税率、保険料率、申請期限、制度名は変更されるため、一般的なWordPress仕様より確認頻度を高くします。記事ブリーフで法令確認を必須にし、公開前に国税庁、日本年金機構、協会けんぽ、自治体などの現行ページを確認します。
本人の経験が正しくても、現在の制度説明が古ければ記事全体の信頼性を損ないます。体験した日と公式情報の確認日を分け、「当時こうだった」と「現在こう案内されている」を混同しない書き方にします。
リンク検査はステータスコード以外も見る
404・410は明確な失敗ですが、200でも目的の情報が消え、トップページへ転送されている場合があります。公式ページのタイトルと本文に必要な項目があるかを確認します。短縮URLや計測URLは最終到達先のドメインと案件を確認します。
内部リンクは自サイトの公開記事に限定し、アンカー文とリンク先の検索意図が合うかを見ます。リンク数をノルマとして増やさず、読者が次に必要とする2〜3本へ絞ります。
画像品質は自動検査と目視を組み合わせる
画像ファイルの存在、形式、縦横比、寸法、altは機械検査できます。一方、文字欠け、意味不明な文字、主役の分かりにくさ、スマホでの視認性、既存画像との使い回し感は目視が必要です。公開用初回画像と、公開後に本人が差し替える強化版を別管理する場合は、用途を混同しません。
アイキャッチは記事内容と一致し、一覧で小さく表示されても主題が伝わるものにします。altは画像の内容を簡潔に説明し、キーワードを不自然に詰め込みません。
テストデータに通過例と停止例を入れる
品質ゲートのテストには、明確に止めるべき原稿だけでなく、同じ単語を説明文で使う正常原稿も含めます。通過例がないと、条件を厳しくするほど安全に見え、誤検知が増えます。過去に実際に起きた誤検知を回帰テストへ残すと、同じ修正事故を防げます。
広告属性、PR表記、slug、内部リンク、画像、SEO項目についても、1項目だけ欠けた最小ケースを作ります。エラーメッセージには記事IDと不足項目を含め、どこを直せば再検査できるか分かるようにします。
検査結果を管理表へ同期する
記事ブリーフにはマニフェストと構成、記事生成管理には本文長・EXP ID・禁止表現・リンク・画像、最終確認には重大エラー数と公開可否を残します。処理キューへ入れるのは、これらが同じ記事IDで合格した後です。
公開後は投稿ID、URL、公開日、status、確認時刻を関連表へ反映します。一部の表だけ公開済みだと、次回候補選定で未公開と誤認するため、検証合格をきっかけに同期します。同期に失敗した場合は公開自体を取り消すのではなく、公開済み事実を保持して管理更新を再試行します。
Googleの人向けコンテンツ方針との関係
Google検索セントラルは、人の役に立つことを主目的にした有用で信頼できるコンテンツを案内し、実際の経験や深い知識が明確かを自己評価の観点に挙げています。品質ゲートは検索順位を保証する仕組みではありませんが、経験の出所と読者価値を点検する助けになります。
自動化の目的を投稿本数だけにすると、既存情報の言い換えが増えます。本人が行った判断、失敗、改善、確認できた範囲を中心にし、分からないことを分からないと書く方が、長期的な記事資産として信頼されやすいと考えています。
公開可否の最終ルール
公開判定は「重大エラー0」を必須とし、警告は修正可能なものを直した上で記録します。EXP IDが1件以上あっても、記事の中心的な体験主張を支えられなければ候補を差し替えます。一般情報だけで本文を埋めた記事は公開対象にしません。
WordPressへ送る直前に、本文、メタ、slug、カテゴリ、タグ、画像、広告、内部リンクの確定値をスナップショットとして保存します。公開後はその値と再取得結果を比較し、合格した記事だけを公開済みへ移します。
よくある質問
Q. AIが書いた文章をすべて止める仕組みですか？
いいえ。作成手段ではなく、記事内の事実、体験表現、出典、構造、リンク、公開結果を検査します。
Q. 文字数が8,000字なら合格ですか？
文字数は条件の一つです。実体験の根拠、検索意図への回答、重複、広告、リンク、表示も合格する必要があります。
Q. 公式URLが200なら使えますか？
記事の主張を直接支える現行ページかを確認します。トップページや移転案内だけでは根拠として不十分です。
Q. 誤検知したら検査を外すべきですか？
検査目的を残したまま、文脈を区別できる条件へ狭め、通す例と止める例で回帰テストします。
WordPressの運用基盤を整える
自動投稿では、REST APIへの到達性、画像アップロード、公開ページの安定表示まで含めて確認できるサーバー環境が必要です。筆者が実際に使っているエックスサーバーの内容は、公式ページで確認できます。
確認した公式情報
制度や仕様は変更される可能性があるため、2026年9月19日に以下の現行ページを確認しました。
まとめ
WordPress自動投稿の品質ゲートは、禁止語を探すだけの仕組みではありません。実体験DBをテーマ選定の入口にし、一次情報マニフェストで使える事実と禁止表現を定義し、全文の一人称・数字を照合します。さらに構造、広告、リンク、画像、公開後のWordPressデータまで層ごとに確認します。
筆者の運用では、誤検知を経験したことで、厳格さと正確さの両方が必要だと分かりました。止めるべき記事は確実に止め、正常記事は根拠を保ったまま通す。その境界をテストと記録で改善し続けることが、自動化と信頼性を両立する方法です。
