ブログ記事自動生成システム|AI×人間レビューの半自動化開発事例

GAS×AIでブログ運用を半自動化した自社事例|外注ホームページの記事更新を継続させる仕組みの作り方

制作内容

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

「ホームページは作ったけれど、ブログ更新がいつの間にか止まってしまった」。BENTEN Web Worksでも同じ壁にぶつかり、GASと生成AIを組み合わせて、記事の本文ドラフトからWordPressへの下書き投稿までを補助する仕組み を作りました。

前提として、AIは下書き生成のサポート、品質判断は人間 という役割分担に振り切っています。

この記事では、その「blog_auto」と呼んでいる仕組みを、何を自動化し、何をあえて人間に残したか までセットで公開します。

システム概要

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

派手なAIライティングツールではなく、自分のサイトを長く育てるための社内基盤です。同じ仕組みを外部サイトの運用代行でも転用しています。

課題・依頼背景(Before)

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

「全部AIにやらせて自動公開」も検討しましたが、自社サイトの読み手はクライアント候補の事業者で、誤情報・トーンのズレ・的外れな構成が出た瞬間に信頼を失います。「キーワード選定・構成意図確認・最終公開判断は人間に残し、人がやらなくていい部分だけ自動化する」という線引きが必要でした。

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

最初に決めたのは「何を自動化しないか」です。

案A: 1モデルで一発生成して自動公開

最も軽い反面、品質のばらつきが大きく、結局「公開ボタンを押す手間」を「内容チェックの手間」に置き換えるだけ。誤情報の自動公開リスクも残ります。

案B: 人間の判断ポイントを4箇所残した「補助型」構成(採用)

人間の判断を意図的に4箇所残し、その間をAIに補助してもらう構成です。

  • 判断1(人間): キーワード選定。Search Consoleの実データ・自社サービスとの整合・読者像を見て決める
  • ステップA(AI): 構成案(H2/H3骨子)を生成
  • 判断2(人間): 構成案レビュー。意図と違う構成は破棄か書き直し
  • ステップB(AI): 承認した構成案から本文ドラフトを生成
  • 判断3(人間): 本文レビュー。事実誤認・トーンのズレ・薄い箇所を手で直す
  • ステップC(システム): WordPress REST APIで「下書き」として登録
  • 判断4(人間): 最終チェック→公開ボタンを押す

キーワード選定と構成意図確認も人間に残すことで、誤情報の自動公開リスクと的外れな量産リスクの両方を根元から消せます。半自動でも、書く前のゼロから設計する負荷が消えるだけで継続性は劇的に変わりました。

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

  • キーワード選定までAIに任せる: 自社サービスとの噛み合いがブレる
  • 画像生成の同梱: 別スキルに切り出し。確実に動く小さな仕組みを積み上げる
  • 自動公開: 信頼性を最優先するため見送り。品質基準を満たした記事だけ公開するという線を崩さない
  • 自社プロダクト化の前倒し: まず自社で1年回してから外販を検討する順番に

実装内容

AI構成案→AI本文→人間レビュー→WordPress下書きの半自動化フロー
AIに任せきりにしない、人間レビューを残した半自動化パイプライン

技術スタック

  • 実行基盤: Google Apps Script(Webhookトリガー+時刻トリガー)
  • 生成AI: Deepseek API(構成生成と本文生成で2段階呼び出し)
  • データ管理: Google Sheets(キーワードリスト、生成履歴、ステータス管理)
  • 投稿先: WordPress REST API(下書きステータスで投稿)

工夫した点

  • 人間の判断ポイントを設計図上で明示: 曖昧な箇所を残さない
  • コストとレイテンシのバランス: 構成案は軽いモデル、本文は重めのモデルで一度だけ
  • キーワードの一元管理: スプレッドシートにステータスを持たせ、人間の判断ポイントが見える形で進捗管理
  • 品質基準を満たさない下書きは公開せず破棄: スループット最大化より品質を優先
  • 横展開: 運用代行案件にも転用可能。ただし横展開先でもキーワード選定と最終チェックは必ず人間が担当する運用ルールをセットで提供

派手な機能は何も足していません。「下書きまで来たら人が読んで直す。意図と違ったら破棄する」という役割分担です。

成果

指標 Before After 意味
1本あたりの初稿準備時間 半日〜1日 30〜60分(人間のチェック・修正中心) 続けられる工数になった
構成案の発射台 毎回ゼロ 人間が選定したキーワードに対してAIが骨子提案 思考のスタートが軽い
公開フロー 全工程手作業 下書きまで自動/構成・本文・公開の3点で人間が判断 誤公開・的外れ記事の量産リスクなし
品質基準 個別判断 レビューを通らない下書きは破棄、公開はしない 量より「公開して恥ずかしくないか」を優先
横展開 なし 運用代行案件にそのまま流用(人間レビューの運用ルールセット) 自社事例が他社価値になる

数値以上に大きいのは、「今日は書く気力がない」という日でも、下書きが溜まっているから手が動く こと。気力ベースの運用から、仕組みベースの運用に切り替わりました。

私の働き様

β:検討プロセス(一人称で振り返り)

エピソード1:自動公開を選ばなかった理由(→ ちゃんと動く/ビジネスに寄り添う)

誤情報や不適切な表現が一度でも公開されると、積み上げた信頼が一気に毀損することを経験的に知っていました。「楽になる」と「ちゃんと動く」がぶつかったとき、迷わず後者を取るという線引きをここで決めています。

エピソード2:豪華な構成より小さく始めた理由(→ ちょうどいい/思考プロセス)

画像生成・SNS連携まで盛ろうと思えば無限に盛れます。でも最初から大きく組むほど、どこか1箇所が壊れた瞬間に全体が止まる。最小構成で1ヶ月運用してから、足りないところだけ後付けする順番にしました。

エピソード3:API選定を一度やり直した反省(→ 思考プロセス/ちゃんと動く)

初版は別のAPIで実装しましたが、運用に合わずDeepseekの2段階構成に組み替え直しました。「最初の設計が正解とは限らない」を素直に認めて作り直すのも、長く運用するための前提条件です。

α:コミュニケーション抜粋(自分の発言だけ)

社内案件のため、判断時に自分宛に書いたメモから引用します。

「自動公開はしない。下書きまで自動でいい。最後の責任は人が取れる仕組みを残す。」

「キーワード選定はAIに任せない。何のために誰に向けて書くかは、自社サービスの文脈を持っている人間にしか決められない。」

レビューを通らない下書きは公開せず破棄する。続けるために量を妥協していい、ではない。」

AIに任せる範囲と人間が責任を持つ範囲を、最初に握ることが信頼の土台になります。

学び・横展開

  1. 「自動化しないこと」を最初に握る: 人が責任を持つ場所を明示的に残す
  2. キーワード選定と最終チェックは人間に固定: AIには判断させない
  3. 小さく作って育てる
  4. 自社運用で実験してから外販

ブログ更新が止まったサイトや社内メディア運営でも、「下書きまで自動/キーワード選定と最終チェックは人」の構成は十分に効きます。「適当に量産する仕組み」ではなく「品質基準を満たしたものだけ公開する仕組み」として組むことが、長期に効く運用になります。

関連サービス

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

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

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

まずは無料相談から

IT担当がいない、業務を自動化したい、ホームページを改善したい。 どんな小さなお悩みでも、お気軽にご相談ください。

無料相談