ブログ記事の生成から予約公開までを自動化した自社事例｜人の承認が詰まった箇所を機械の検査に置き換えた経緯

自社サイトの記事更新を「続けられる仕組み」に変えた話

「ホームページは作ったけれど、ブログ更新がいつの間にか止まってしまった」。BENTEN Web Worksでも同じ壁にぶつかり、生成AIを使って、記事の構成・本文の作成からWordPressへの予約公開までを自動で進める仕組みを作りました。社内では「blog_auto」と呼んでいます。

最初からこの形だったわけではありません。作った当初は、キーワード選定・構成・本文・公開の4か所で人が判断し、AIには下書きだけを任せる設計でした。運用を続けるうちに、人の確認待ちが更新の詰まりどころになり、確認の一部を機械の検査に置き換えてきました。

この記事では、当初の設計、運用で変えたところ、変えた結果として公開記事に見つかった問題と、その対処までを順にお話しします。

システム概要

• 対象: 自社サイト bentenweb.com のブログ記事
• 規模感: 個人事業（運用は私一人）
• 目的: 「記事を書く時間がない」を理由に更新が止まらない仕組みづくり

派手なAIライティングツールではなく、自分のサイトを長く育てるための社内基盤です。

課題・依頼背景（Before）

• 構成案で力尽きる: 見出し設計に毎回30分以上かかっていました
• 本文の初稿に時間がかかる: ゼロから1本を書くのに半日〜1日
• 公開作業が地味に重い: 画像設定・カテゴリ選定で集中力が削られます
• 更新が止まる→順位が下がる→書く気が失せる悪循環

一方で、自社サイトの読み手はクライアント候補の事業者です。誤った情報や、根拠の無い実績が載った記事を出せば、信頼をそのまま失います。「楽にする」と「信頼を落とさない」を両立させる線引きが必要でした。

提案・解決アプローチ（思考プロセスを見せる）

当初の設計: 人の判断を4か所に残した補助型

最初に作ったGoogle Apps Script版は、WordPressに下書きとして登録するところで止める設計にしました。

• 判断1（人）: キーワード選定
• 構成案の生成（AI）
• 判断2（人）: 構成案のレビュー
• 本文ドラフトの生成（AI）
• 判断3（人）: 本文のレビュー。事実誤認・トーンのずれを手で直す
• WordPressへ下書き登録（システム）
• 判断4（人）: 最終チェックをして公開ボタンを押す

この形でも、ゼロから書き始める負担はなくなりました。1本の初稿準備は、当初の目安で半日〜1日から30〜60分（人が読んで直す時間を含みます）ほどになりました。

運用で変えたこと1: 予約公開まで自動にし、人の判断をキーワード承認に寄せた

2026年3月に、GitHub Actionsで毎朝動く版へ作り替えました。ここで記事は3日おきの予約公開まで自動で進むようになり、人の判断は「どのキーワードで書くか」の承認に集約しました。

運用で変えたこと2: 承認待ちが律速になった

ところが、今度はそのキーワード承認が詰まりました。候補は週次のSEOレポートから毎週届くのに、承認されないまま溜まり、生成の仕組みは毎朝正常終了しているのに記事が1本も増えない、という状態が起きています。調べると、止まっていたのは生成ではなく承認でした。承認が通れば翌日に記事ができ、3日おきに公開されます。

そこで承認そのものを機械に判定させる仕組みを作り、今は判定結果を記録して人の判断と答え合わせをする段階で動かしています。判定を本番に使うと、承認から公開まで人の目が一度も入らなくなります。その前に、公開直前で記事そのものを検査する仕組みが要ると判断しました。

あえて採用しなかった選択肢

• 当初の4か所の確認をそのまま続ける: 確認待ちで更新が止まり、仕組みを作った目的に反します
• 承認の自動化を先に本番化する: 公開前の歯止めが無いまま流すことになるため、順番を入れ替えました
• 一般論だけの記事で本数を稼ぐ: 上位の記事と差がつかず、サイトの信頼にもつながりません

実装内容

技術スタック

• キーワード候補: Google Apps Script（週次のSEOレポート）＋ Google Sheets（候補と承認状況の管理）
• 記事生成: GitHub Actions 上の Node.js（TypeScript）。毎朝起動
• 生成AI: DeepSeek API。構成は推論の重いモデル、本文は軽いモデルの2段階で呼び出します
• 投稿先: WordPress REST API（予約投稿。3日おきに公開日を割り当て）
• 既存記事の書き直し: 別の夜間処理。評価が基準に届いた版だけを公開します

工夫した点

• 公開前の検査（公開前ゲート）: 生成した記事を、①既存の記事と検索意図が重ならないか、②自社のサービスにつながる説明ができるか、③一次情報があるか、の3条件で判定します。一次情報として認めるのは、掲載の許可を得た実績事例と私自身のメモだけです。LLMには「通してよい根拠」を出させ、その根拠が本文に実在するかはプログラム側で確かめます
• 段階的な切り替え: 公開前ゲートは、今は判定を記録する段階で動かしています。ただし実績事例を入れた記事は、この段階でも③に通らなければ下書きで止まります。全記事を止める段階への切り替えはまだ行っていません
• 黙って止まらない: 下書きで止めた記事、予約公開がWordPress側で実行されなかった記事は、運用チャンネルに通知します。予約公開の確認は、記録上の状態ではなく実際のURLが開けるかで見ています
• 同じ記事を二度出さない: キーワードから決まるURLで照合し、同じキーワードの記事を重ねて公開しません

運用で見つかった問題と対処

公開前ゲートを作った段階で、その部品を使って公開済みの記事148本を全数監査しました。結果、出典の無い他社事例や成果の数値、架空の顧客事例を事実のように書いた記事が30本見つかっています。自動生成した記事が中心でした。

人が本文を読まずに公開する経路を開いた以上、AIが書いた「それらしい事例」を止める仕組みが無かったということです。予約公開に切り替えた時点で、本文の確認の代わりになる検査を同時に置くべきでした。

対処として、該当する記事は下書きに戻す、該当の文を削除する、掲載の許可を得た実際の事例に差し替える、のいずれかで直しています。あわせて、新しく生成する記事には上の③（一次情報）の条件を入れ、実際の経験が無いテーマでは記事を出さない方向に設計を変えました。この条件で全記事を止める段階へは、判定の記録を数回確かめてから切り替える予定です。

成果

数値以上に大きいのは、「今日は書く気力がない」という日でも更新が止まらないことです。その代わり、人が読まない分だけ機械の検査を厚くする必要があることも、監査ではっきりしました。

私の働き様

β：検討プロセス（一人称で振り返り）

エピソード1：人の確認を外す前に、代わりの検査を置く（→ ちゃんと動く／ビジネスに寄り添う）

予約公開に切り替えたことで更新は続くようになりましたが、本文を読む人がいなくなった分の穴は、監査で30本という形で表に出ました。いま承認の自動化を本番に上げずにいるのは、同じ穴をもう一度開けないためです。公開前の検査を先に動かし、記録を見てから次へ進む順番にしています。

エピソード2：「動いている」と「記事が増えている」は別物（→ 思考プロセス／ちゃんと動く）

生成の処理は毎朝正常終了しているのに、キーワードの承認が止まっていて記事が1本も増えない時期がありました。予約公開がWordPress側で実行されず、記録上は完了のまま公開されていなかったこともあります。それ以来、画面上の「成功」ではなく、記事が実際に開けるかで確認するようにしました。

エピソード3：最初の設計を正解にしない（→ ちょうどいい／思考プロセス）

4か所で人が確認する当初の設計は、慎重さとしては正しかったと思います。ただ、一人で運用すると確認待ちがそのまま更新の止まりどころになりました。どこを人に残し、どこを機械に任せるかを、運用の記録を見て直していくほうが、長く続く形になります。

α：コミュニケーション抜粋（自分の発言だけ）

社内案件のため、判断のときに残した自分の発言から引用します。

> 「SEOはじっくり成果が出るまでやり続けるしかない。なのでやめない。」

（承認の自動化で手間がどれだけ減るかを試算した結果、効果が小さいと分かったときの判断です。仕組みを畳むのではなく、時間軸を長く取ることにしました。）

> 「ダメ。一般論だけになっているから、必ず経験的な要素を入れた上で生成してほしい。」

（既存記事の書き直し案が一般論ばかりだったときの指摘です。それ以降、書き直しでは実際の経験か許可を得た事例を入れることを公開の条件にしました。新しい記事にも同じ条件を検査として入れています。）

学び・横展開

1. 人の確認を外すなら、代わりの検査を同時に置く: 外してから気づくと、直す範囲が公開済みの記事全体に広がります 2. 詰まりどころは記録で探す: 「生成が止まっている」と思った原因が、実際は承認待ちでした 3. 一次情報の無い記事は出さない: 実際の経験や許可を得た事例が無いテーマは、本数より信頼を優先します 4. 切り替えは段階を踏む: 判定を記録する段階で答え合わせをしてから、止める段階へ進めます

ブログ更新が止まったサイトや社内メディアの運営でも、「生成と公開は仕組みに任せ、公開前の検査と定期的な監査で品質を守る」構成は応用できます。ただし、どこまで自動にするかはサイトの性格と運用体制で変わるので、最初は人の確認を多めに残し、記録を見ながら減らしていくのがおすすめです。

関連サービス

「派手な記事生成ツールではなく、自分のサイトの更新を続けられる仕組みを相談したい」という方は、以下のサービスをご覧ください。

• 情シス代行サービス: WordPressの運用・改修・自動化基盤の整備まで月額制でお任せいただけます → /services/it-outsourcing/

ビジネスに寄り添う改修を相談したい方は、まずは無料相談からお声がけください。