AIとApps Scriptでブログを自動化しても品質を落とさない運用ルール【実体験】

2026年8月29日

【PR】この記事には広告リンクが含まれています。

AIで記事を書き、Google Apps ScriptからWordPressへ送れば、ブログの更新作業はかなり減らせます。しかし、キーワードだけを渡して一般論を量産すると、実体験のない一人称、古い制度、別案件へ飛ぶ広告リンク、未公開の内部リンク、文字が重なったアイキャッチまで自動で公開される危険があります。

筆者は、エックスサーバーとSWELLで運営する「ひとり社長の道具箱」で、WordPressの非公開下書き、アイキャッチ、週次公開をApps Scriptへつなぎました。2026年8月12日にはART-007を投稿ID41として自動公開し、成功1件・失敗0件を確認しました。その後、最大4本を個別処理する仕組みへ広げ、2026年8月15日にART-008からART-011までの4本を公開しました。

うまくいった理由は、AIの文章力だけではありません。実体験ID、一次情報、広告、内部リンク、slug、画像、公開後の再取得を品質ゲートへ入れ、「処理が終わった」と「記事が公開された」を別の判定にしたからです。この記事では、その運用ルールをコードの考え方と一緒に解説します。

AIブログ自動化の品質は、生成前・公開前・公開後で守る

品質管理を本文の校正だけにすると、公開事故を止められません。自動化では、次の3段階へ分けます。

生成前：実体験、使用可能な事実、禁止表現、検索意図を確定する
公開前：本文、リンク、画像、SEO、広告、カテゴリを機械検査する
公開後：WordPressから同じ投稿を再取得し、status、slug、本文、画像を照合する

生成前が弱いと、文章として自然でも事実ではない記事になります。公開前が弱いと、リンク切れやH1重複、PR表記漏れが残ります。公開後が弱いと、APIが成功を返しても下書きのまま、画像なし、別slugという状態を見逃します。どれか一つだけでは不十分です。

【実体験】最初の自動公開は品質ゲートで一度止まった

筆者がART-007を自動公開したとき、最初から一直線に成功したわけではありません。品質ゲートが、記事に必要な実体験の紐付け不足を検知して停止しました。EXP-019を正しく紐付け、再検査してから公開しています。

結果は、WordPress投稿ID41、成功1件、失敗0件でした。ここで確認したのはApps Scriptの実行完了だけではありません。WordPress側の公開状態、URL、本文、アイキャッチ、管理表の更新まで照合しました。自動化の価値は、止まらないことではなく、危険な状態で止まれることにあります。

この経験から、最大4本をまとめて処理するときも、バッチ全体を一つの成否にしませんでした。1記事ずつ品質を確認し、1本が失敗しても残りを継続できる設計にしています。失敗した記事だけをブロックし、原因を記録して次回へ回します。

GoogleはAI利用より、読者へ価値を足したかを見ている

Google Search Centralは、生成AIが調査やオリジナルコンテンツの構成に役立つ一方、読者へ価値を加えず大量ページを作る行為は、スケールドコンテンツの不正利用に当たる可能性があると案内しています。問題の中心は、AIを使ったかどうかだけではなく、検索順位の操作を目的に独自価値のないページを増やしたかどうかです。

同じ公式案内では、人のために作られ、信頼できる情報、実際の経験、明確な作成主体を重視する考え方が示されています。自動化を使った場合は、どのように作成し、なぜ自動化が役立ったかを説明することも、読者の理解に役立つ場合があります。

そこで当サイトでは、検索キーワードから記事テーマを直接作りません。最初に筆者の操作記録、数字、失敗、判断理由を抽出し、その実体験で答えられる検索意図を後から選びます。検索需要は順位付けに使いますが、体験のないテーマを作る根拠にはしません。

ルール1：記事ごとに一次情報マニフェストを作る

一次情報マニフェストは、その記事で使える体験の許可リストです。記事ID、実体験ID、出所、使ってよい事実、数字、本人の判断、使ってはいけない表現を記録します。

たとえばこの記事では、エックスサーバーとSWELLを実際に利用していること、ART-005で下書き・画像までの自動化を運用したこと、ART-007を投稿ID41で公開したこと、最大4本を個別処理したことが使えます。一方、検索順位や収益が上がったという結果は確認されていないため書けません。

マニフェストがない場合は、記事を生成しないルールにします。AIへ「自然な体験談を入れて」と指示すると、文脈上もっともらしい一人称を補完する可能性があります。書ける事実を限定し、足りなければ別テーマへ差し替えるほうが安全です。

ルール2：一人称と数字を機械的に照合する

本文中の「筆者」「私」「当サイト」といった一人称を抽出し、その文に含まれる数字を一次情報マニフェストへ照合します。根拠のない数字が一つでもあれば重大エラーとします。

数字だけを検査する理由は、AIが具体性を高めるために時間、金額、件数を補いやすいからです。「数分で終わった」「毎月必ず成功した」「売上が増えた」といった表現は読みやすくても、記録がなければ体験談として使えません。数字のない評価表現も、本人の判断として登録されているか確認します。

制度上の期限や料金は、本人の体験ではなく公式情報へ紐付けます。たとえばApps Scriptの割当やWordPress REST APIの項目は、GoogleとWordPressの公式ドキュメントを正本にします。本人の経験と一般仕様を同じ段落で混ぜないことが大切です。

ルール3：本文を作る前に検索意図を1つへ絞る

同じ実体験から複数の記事を作ることはできます。ただし、検索意図を分けます。自動投稿の作り方、403エラーの直し方、週4本の運用設計、品質ゲートの作り方は関連しますが、読者の困りごとは同じではありません。

この記事は「AIで自動化すると品質が落ちそう」という不安へ答えます。REST APIの接続コードそのものは中心にしません。接続方法を知りたい読者は「Google Apps ScriptでWordPressを自動投稿する方法」へ送ります。

記事ごとに結論、体験、手順、失敗、検査項目を変えれば、同じ運用の一部を使っても重複を抑えられます。逆に、見出しだけ言い換えて同じ本文を展開すると、読者にも検索エンジンにも新しい価値がありません。

ルール4：公式情報の確認日と役割を分ける

公式情報は、事実を補強するために使います。WordPress REST APIのPostsエンドポイントでは、title、content、excerpt、slug、status、featured_mediaなどの項目が扱えます。Apps ScriptのUrlFetchAppは外部のHTTP・HTTPSリクエストに使えます。

ただし、公式仕様を並べるだけでは、当サイトで記事を書く意味が薄くなります。公式情報は「何が可能か」、実体験は「どこで止まり、どう直し、何を完了条件に変えたか」を担当させます。

価格、割当、セキュリティ、API仕様は変わる可能性があります。記事ブリーフへ確認日を残し、公開時に再確認します。GoogleのApps Script割当は変更されることがあり、上限超過時には例外が発生するため、固定値を記事へ焼き付ける場合は特に注意します。

ルール5：未解決マーカーは「状態」で検知する

公開前の品質ゲートでは、未入力メモや保留表示を止めます。ただし、単語が本文に含まれるだけで停止すると、正常な説明文まで誤検知します。

筆者の運用では、注意事項として書かれた言葉と、実際の未解決状態を分けるよう判定を修正しました。HTMLコメント、囲み記号、行頭の保留表示、リンク属性内の仮値など、プレースホルダーとして残っている形を検知します。

品質ゲートは厳しいほどよいわけではありません。誤検知が多いと、運用者が検査を無効化したくなります。実際に止めたい事故の形をテストへ落とし、正常な文章は通す必要があります。

ルール6：広告リンクは案件IDから挿入する

広告リンクを本文生成時にAIへ自由入力させると、別案件のURL、古いリンク、計測ピクセル漏れが起きます。提携済み、正式リンク取得済み、有効URLの案件だけを案件マスターへ登録し、記事は案件IDを参照します。

A8.netの広告リンクには、広告であることを示すrel属性を付け、発行された計測ピクセルを保持します。記事冒頭にはPR表記を置きます。リンク先が確認できない場合や未提携案件は、別の広告へ置き換えず、その導線自体を除外します。

当サイトでは、エックスサーバーを実際に使ってWordPressを運用しています。自動化の接続基盤として使った経験があるため、この記事から関連する開設記事へ送客できます。

エックスサーバーの公式サイトを見る

ルール7：内部リンクは公開済みURLだけ使う

記事制作プランに関連テーマがあっても、リンク先が未公開ならURLは存在しません。未公開記事のslugを予測して入れると、404になります。公開済みURLだけを内部リンク管理へ登録し、未公開候補は地の文として自然に読めるようにします。

この記事では、実際に公開済みの自動投稿記事、週4本運用記事、REST API 403解決記事へつなげます。接続で403になった場合は「エックスサーバーでWordPress REST APIが403になる原因と直し方」を確認してください。

公開後は、新記事から既存記事へのリンクだけでなく、既存のハブ記事から新記事へ戻すリンクも検討します。新規記事を孤立させないことが、読者の回遊とサイト構造の両方に役立ちます。

ルール8：1記事失敗しても残りを止めない

4記事を一つの大きな処理で送ると、先頭のエラーで全件が止まる可能性があります。記事IDごとに処理を分け、各記事をtry/catchで囲みます。成功、失敗、エラー理由、WordPress投稿IDを個別に記録します。

ただし、継続処理はエラーを無視することではありません。失敗した記事は公開対象から外し、管理表の許可された状態へ更新します。エラー記録自体が入力規則に反して二次エラーにならないよう、状態値と詳細メッセージの列を分けます。

バッチ全体の結果は、対象件数、公開件数、失敗件数を集計します。「処理完了」とだけ表示すると、一部失敗を見落とします。公開件数が4未満なら、その理由と対象IDが分かるログを残します。

ルール9：status=publishのあとに同じ投稿を再取得する

WordPressへstatus=publishを送信し、HTTPエラーがなかっただけでは公開完了にしません。保存後の投稿IDを使って同じ投稿を再取得し、次を確認します。

statusがpublishである
slugが指定値と一致する
公開URLが返っている
本文にH1が残っていない
アイキャッチIDとaltが一致する
SEOタイトル、メタディスクリプション、OG画像が一致する
カテゴリとタグが想定どおりである
広告リンクと内部リンクが取得できる

筆者は、全記事のURL、公開状態、時刻、サムネイルを個別に確認し、1本でも未公開なら「4本公開完了」と報告しない運用へ変えました。処理ログより、公開サイトとWordPressが返す状態を正本にします。

ルール10：アイキャッチを本文と別の品質項目にする

記事本文が合格でも、アイキャッチが弱いとクリックされません。自動生成画像では、文字被り、読めない日本語、同じ構図の使い回し、旧デザインの再利用が起きやすいため、画像を独立した品質項目にします。

当サイトでは、記事テーマごとに人物、業務シーン、色、主役となる視覚要素を変え、画像内の文字を避けています。タイトル文字はWordPress側のカード表示に任せることで、画像内テキストとの重なりを防ぎます。1600×900のPNG、alt、OG画像まで一致を確認します。

公開後には、記事ページだけでなく、トップページ、関連記事カード、SNSシェア時の縮小表示も見ます。大きな画面で美しくても、サムネイルでは主題が見えない画像があります。人物の顔と一つの象徴物が小さくても判別できる構図が扱いやすいです。

ルール11：認証情報は記事・シート・ログに残さない

WordPressのユーザー名、アプリケーションパスワード、APIキーを記事本文やスプレッドシートへ保存しません。Apps Scriptのプロパティなど、実行環境の秘密情報を扱う仕組みへ分けます。

ログには、URL、投稿ID、処理結果、エラー種別を残し、認証ヘッダーや完全なレスポンスを無条件で出力しません。エラー本文に秘密情報が含まれる可能性もあるため、公開用の安全なメッセージへ整形します。

WordPressのApplication Passwordsは連携専用に発行し、不要になったら個別に失効できる形が扱いやすいです。通常のログインパスワードを外部スクリプトへ渡さず、HTTPSを使い、権限を必要最小限にします。

ルール12：管理表は記事IDを共通キーにする

記事マスター、実体験DB、記事ブリーフ、競合調査、WordPress下書き、最終確認、実行ログを別々に持つ場合、タイトルではなく記事IDで結びます。タイトルは改善で変わりますが、記事IDは変えません。

記事IDから、使用した実体験ID、一次情報ID、案件ID、内部リンク、WordPress投稿ID、公開URL、30日・60日・90日の評価日を追えるようにします。どの事実を使って公開したか分かれば、後のリライトで数字を更新しやすくなります。

状態値も統一します。「候補」「実行可能」「合格」「非公開下書き」「公開済み」「ブロック」など、入力規則に存在する値だけを使います。詳細なエラーは状態列へ押し込まず、次の処理やエラー列へ記録します。

AIへ任せる作業と任せない判断

工程	AI・自動化へ任せる	根拠が必要な判断
テーマ選定	候補の採点、重複確認	使用可能な実体験があるか
調査	公式情報・競合の収集	制度・価格の正本、確認日
構成	検索意図に沿う見出し	体験で答えられる範囲
執筆	文章化、表、FAQ、要約	一人称、数字、評価表現
公開	API送信、画像、SEO設定	品質ゲート、公開後再取得
改善	データ集計、候補抽出	リライトや導線変更の判断

人が毎回ゼロから文章を書く必要はありません。一方、本人が経験していないことを体験談へ変換する権限はAIへ渡しません。不明点を想像で補うより、「確認できない」と明示するか、そのテーマを使わないほうが長期的な信頼を守れます。

公開後の検証も品質ゲートに含める

公開前の本文が正しくても、WordPress側で画像、カテゴリ、タグ、SEO、OGが欠けることがあります。そのため、公開APIの成功レスポンスだけで完了にせず、投稿IDを使って再取得し、公開状態と設定値を照合します。公開URLにもアクセスし、404や表示崩れがないかを確認します。

筆者の運用では、全記事についてURL、公開状態、公開時刻、アイキャッチを確認できたときだけ完了にします。4本のうち3本だけ公開されていれば、バッチ処理は終了していても4本完了ではありません。成功件数と失敗件数を記事ID別に残すことで、未公開の1本だけを直せます。

公開後の確認は、すべてを目視で読み直すことではありません。機械検査でslug、H1、広告属性、画像ID、カテゴリ、タグ、SEOを照合し、人はタイトルの見え方、アイキャッチのクリック感、体験表現の違和感、CTAの自然さを5〜10分で見ます。機械と人の確認範囲を分けることで、件数を増やしても重要な判断を残せます。