AI CLIをタスクスケジューラから呼び出せば、ブログ記事は自動生成できます。

しかし、実運用で難しいのは「記事を1本生成すること」ではありません。認証エラーやタイムアウトが起きても、低品質な記事を公開せず、原因を追跡できる状態を作ることです。

Hiroが運用するブログ自動化基盤では、2026年7月21日に次の事象が同じ一日の中で発生しました。

  • 下書き生成からNotion保存、Git pushまで完了
  • Codex CLIが240秒でタイムアウトし、記事生成をスキップ
  • Gemini CLIの認証・互換性エラーからCodex CLIへ切り替え
  • AIスロップ検査が基準未達の記事を保存前に停止

成功例だけを見ると、AIブログ自動化は簡単に見えます。実際の運用では、止まり方を設計して初めて無人化できます。

この記事では、Hugo、Python、AI CLI、GitHub、Cloudflare Pagesを使い、初心者が小さく始める手順から、専門家が確認すべき障害対策、KPI、公開判定まで解説します。

AI CLIによるブログ生成・品質検査・Notion保存・Git公開の自動化フロー

AI CLIによるブログ自動化とは

AI CLIによるブログ自動化とは、Claude、Gemini、CodexなどのコマンドラインツールをPythonから呼び出し、記事生成やレビューを連続実行する仕組みです。

Hiroのリポジトリでは、PythonからAI APIを直接呼び出していません。ローカルPCまたはクラウドrunnerにインストールしたAI CLIを、subprocess経由で実行しています。

処理の流れは次のとおりです。

  1. 記事トピックを選ぶ
  2. AI CLIで下書きを生成する
  3. 別のAI CLIでレビューする
  4. 最終チェックを行う
  5. AIスロップ検査を通す
  6. Markdownファイルを保存する
  7. Notionへ記録する
  8. GitでコミットしてGitHubへpushする
  9. Cloudflare PagesがGitHubの更新を検知してビルドする

この構成では、記事生成、品質判定、保存、公開を別工程として観測できます。

「AIが回答した」と「記事が公開可能になった」は同じではありません。保存前に機械的な品質ゲートを置く必要があります。

Hiroの2026年7月21日の実行ログ

ここからは、generator/logs/generate.logと同日のGit履歴で確認できた一次情報を見ていきます。

成功例：認証エラーから切り替えてGit pushまで完了

「Cloudflare PagesでHugoブログを高速配信するメリット」というトピックでは、次の処理が記録されています。

19:42:39  トピック選択、Codex CLIで下書き生成開始
19:44:52  下書き生成成功
19:44:58  Gemini CLIによるレビュー失敗
19:47:38  Codex CLIへ切り替え、レビュー成功
19:51:10  最終チェック成功、Markdown保存
19:51:10  Notion保存成功
19:51:14  origin/mainへのgit push成功

Gemini CLIの失敗理由は、単純な「ログイン期限切れ」とは断定できません。ログには、利用中のクライアントが個人向けGemini Code Assistでサポートされなくなったことを示すIneligibleTierErrorが残っています。

したがって、対策も「再ログインする」だけでは不十分です。

確認項目は次の3つです。

gemini -p "接続テスト"
gemini --version
Get-Command gemini

そのうえで、利用資格、CLIの対応バージョン、非対話実行時のワークスペース信頼設定を確認します。

この実行では、Geminiの失敗後にCodexへ切り替えたため、レビュー以降の処理を続行できました。

停止例：240秒のタイムアウトで記事生成をスキップ

同日19時57分に選ばれた「HugoとWordPressの違いを不動産ブログ目線で比較」では、Codex CLIが次のエラーになりました。

draft: codex CLI failed:
CLI timeout after 240s

All draft CLIs failed;
skipping article generation

下書きを一つも取得できなかったため、システムは空ファイルや途中出力を記事として保存していません。

タイムアウト時に避けたい処理は、次の3つです。

  • 前回の記事を新しい記事として再保存する
  • 一部だけ生成された文章を公開する
  • 失敗したトピックを処理済みにする

下書きが取得できない場合は、非ゼロ終了コードで停止し、対象トピックとエラー内容を再実行キューへ残します。

品質停止例：AIスロップ検査が保存前に拒否

同日18時22分、販促記事の生成後に次のエラーが記録されています。

AI slop validation failed:
score=6/8

failed=
一人称の具体エピソード
視覚的証拠
反論・限界・注意点
差別化

この原稿は文章として生成できていました。しかし、品質基準を満たさなかったため、Markdown保存とGit pushへ進んでいません。

Hiroのリポジトリにあるgenerator/ai_slop_guidelines.jsonでは、10項目のチェックと最低スコア8が設定されています。

主な検査項目は次のとおりです。

  • Hiro固有の実行データがある
  • 数字に根拠がある
  • 冒頭で読者が得られる結果を判断できる
  • 画像やログなどの視覚的証拠がある
  • 反論、限界、注意点がある
  • 読後の具体的な行動がある
  • 類似記事との差別化が明確である

文章が自然でも、検証可能な情報がなければ不合格にする設計です。

AI CLIブログ自動化を始める9ステップ

ステップ1：自動化する範囲を1本の記事に限定する

最初から複数サイト、SNS投稿、メルマガ、商品販売まで接続すると、失敗箇所を特定できなくなります。

最初の成功条件は、次のように限定してください。

入力：トピック、想定読者、主要キーワード
出力：Markdown記事1本
品質：必須チェックを通過
公開：GitHubへpush
確認：本番URLが200を返す

「収益を自動化する」ではなく、「検証済みの記事を1本公開する」までを最初の単位にします。

ステップ2：実行環境を準備する

Windowsでの基本構成は、Python、Hugo Extended、Git、AI CLIです。

python -m venv .venv
.\.venv\Scripts\Activate.ps1
pip install -r requirements.txt
pip install -r requirements-dev.txt

hugo version
git --version
codex --version

AI CLIは、スケジューラへ登録する前に単体実行します。

codex exec "テストとだけ回答してください"

確認するのは回答内容だけではありません。

  • コマンドがPATHから見つかるか
  • 非対話モードで入力待ちにならないか
  • 標準出力または出力ファイルを取得できるか
  • 終了コードが0になるか
  • 認証エラーが発生しないか

手動実行とタスクスケジューラでは、PATH、作業フォルダ、環境変数が異なることがあります。スケジューラ側では実行ファイルと作業フォルダを絶対パスで指定します。

ステップ3：生成条件を設定ファイルへ分離する

Hiroの2026年7月21日時点の設定では、次の値が使われています。

generation:
  min_chars: 5000
  max_chars: 7000
  cli_timeout_seconds: 240
  cli_priority:
    - codex

git:
  auto_commit: true
  auto_push: true

文字数やタイムアウトをPythonコードへ直接書くと、調整のたびに実装変更が必要になります。

設定ファイルには、少なくとも次を分離します。

  • 使用するAI CLIと優先順位
  • 文字数の範囲
  • タイムアウト秒数
  • 保存先
  • 自動コミットの有無
  • 自動pushの有無
  • 品質チェックの合格基準

240秒は万能な値ではありません。記事の長さ、CLIの応答時間、同時実行数を計測し、自分の環境に合わせて決めます。

ステップ4：AI CLIを終了コード付きで呼び出す

Pythonでは、成功、タイムアウト、CLI未検出、空出力を分けて扱います。

import subprocess

def run_cli(command: list[str], prompt: str, timeout: int = 240) -> str:
    try:
        result = subprocess.run(
            command,
            input=prompt,
            capture_output=True,
            text=True,
            encoding="utf-8",
            timeout=timeout,
            check=False,
        )
    except subprocess.TimeoutExpired as exc:
        raise RuntimeError(f"CLI timeout after {timeout}s") from exc
    except FileNotFoundError as exc:
        raise RuntimeError("AI CLIが見つかりません") from exc

    if result.returncode != 0:
        raise RuntimeError(result.stderr.strip() or "AI CLI failed")

    output = result.stdout.strip()
    if not output:
        raise RuntimeError("AI CLI returned empty output")

    return output

実際のCodex CLI連携では、長いプロンプトをコマンドライン引数に直接載せず、標準入力や一時ファイルを使う方が安全です。

Windowsではコマンド長の上限に当たりやすく、HiroのログにもThe command line is too long.というレビュー失敗が残っています。

ステップ5：生成・レビュー・最終確認を分離する

一度のAI呼び出しで、執筆と校正と事実確認を済ませようとすると、どこで品質が落ちたか分かりません。

処理を次の3段階に分けます。

draft       下書きを生成
review      構成、SEO、読みやすさ、論理を改善
final_check 数字、リンク、禁止表現、欠落項目を確認

各工程で次を記録します。

開始時刻
終了時刻
使用CLI
終了コード
処理時間
成功または失敗
フォールバック先
エラー概要

なお、Hiroの現在の実装では、下書き生成が全滅した場合は停止しますが、レビューまたは最終チェックだけが失敗した場合は、直前の原稿を使って次へ進むことがあります。

これは可用性を優先した設計です。誤情報の影響が大きい医療、法律、金融、価格情報では、レビュー失敗時も公開を止める方が適切です。

ステップ6：AIスロップ検査を保存前に実行する

品質検査は、Git pushの後では遅すぎます。記事ファイルを正式保存する前に実行します。

最低限、次を機械判定してください。

タイトルに主要キーワードがある
導入文で読者の問題と得られる結果が分かる
見出しが論理的な順序になっている
具体的な数値に根拠がある
実行ログまたは一次情報がある
失敗例と対策がある
反論または適用限界がある
読後アクションがある
画像リンクが欠落していない
禁止表現の過剰使用がない

AIによる採点だけに依存すると、判定自体が揺れます。文字列検査、リンク検査、見出し数、必須セクションの有無など、決定的に判定できる項目も併用します。

ステップ7：Notion保存とGit公開を別結果として記録する

Notion保存が成功しても、Git pushが成功したとは限りません。逆も同様です。

ログは一つの「成功」でまとめず、工程別に残します。

markdown_saved=true
notion_saved=true
git_commit_succeeded=true
git_push_succeeded=true
production_verified=false

Hiroの実装では、Notion保存に失敗してもエラーを記録してGit処理を続けます。一方、Gitのcommitやpushに失敗した場合は例外になります。

また、Notionへ渡すリンクが仮URLのままでは、保存成功でも利用者が本番記事へ移動できません。デプロイ後の実URLを生成し、Notion上のリンクまで確認してください。

ステップ8：Git push後に本番を検証する

git push succeededは、公開完了を意味しません。

Cloudflare Pagesでは、その後にチェックアウト、Hugoビルド、デプロイが実行されます。公開判定には次の確認を追加します。

$response = Invoke-WebRequest "https://example.com/posts/article-slug/" -UseBasicParsing
$response.StatusCode

合格条件の例は次のとおりです。

  • 本番URLがHTTP 200を返す
  • ページタイトルが生成記事と一致する
  • 本文が空ではない
  • 画像URLが読み込める
  • CTAリンクが目的ページへ遷移する
  • 下書き用の記号や仮URLが残っていない

デプロイには時間差があるため、30秒、60秒、120秒のように上限付きで再確認します。無限リトライは障害の発見を遅らせます。

ステップ9：手動運用から段階的に無人化する

導入順序は次の形が安全です。

  1. CLIを手動実行する
  2. Pythonから1記事だけ生成する
  3. 品質検査後に人間が確認する
  4. Git commitまで自動化する
  5. Git pushと本番確認を追加する
  6. タスクスケジューラへ登録する
  7. 失敗通知と再実行キューを追加する

最初から自動公開せず、まず「自動生成、手動承認」で誤りの傾向を集めます。

よくある失敗と対策

CLIが240秒でタイムアウトする

原因候補は、長すぎる入力、出力条件の過多、CLI側の混雑、ネットワーク、同時実行です。

対策は次の順で行います。

  1. プロンプトと入力資料の文字数を記録する
  2. 下書きとレビューを別リクエストに分ける
  3. ログから処理時間の中央値と95パーセンタイルを出す
  4. タイムアウトを超えた処理は保存対象から外す
  5. 同じ記事IDでの二重公開を防ぐ

単純にタイムアウトを長くすると、停止の検知が遅れるだけの場合があります。

認証済みなのに自動実行で失敗する

手動シェルとスケジューラでは、ユーザー、PATH、ホームディレクトリ、信頼済みフォルダが異なることがあります。

対策として、実行前に次をログへ残します。

whoami
Get-Location
Get-Command codex
Get-Command gemini
codex --version
gemini --version

トークンやAPIキーそのものはログへ出してはいけません。

レビュー失敗後に低品質な原稿が公開される

フォールバックは、処理を止めないための機能です。しかし、品質基準を下げる機能にしてはいけません。

レビューに失敗して下書きを採用する場合でも、最後に同じ品質ゲートを通します。高リスク分野では、レビュー失敗をそのまま公開停止条件にします。

Git pushは成功したのに記事が見えない

主な原因は、Hugoのビルド失敗、front matterエラー、保存先の誤り、Cloudflare Pagesのブランチ設定、デプロイ待ちです。

確認順序は次のとおりです。

git status
git log -1 --oneline
hugo --gc --minify

その後、Cloudflare Pagesのデプロイ結果と本番URLを確認します。

AI CLIブログ自動化で追うべきKPI

記事数だけをKPIにすると、低品質な投稿を増やす方向へ最適化されます。

最低限、次の指標を記録します。

KPI計算方法見る理由
無人完了率人間の介入なしで本番確認まで完了した件数 ÷ 全実行件数自動化の実効性
下書き失敗率下書き生成失敗件数 ÷ 下書き実行件数CLIと入力設計の健全性
タイムアウト率タイムアウト件数 ÷ AI CLI実行件数性能劣化の検知
フォールバック率代替CLIを使った件数 ÷ 全実行件数特定CLIへの依存度
品質拒否率品質ゲートで停止した件数 ÷ 生成完了件数プロンプト品質の監視
公開成功率本番URL確認成功件数 ÷ push件数デプロイまで含む信頼性
公開後修正率公開後に修正した記事数 ÷ 公開記事数品質ゲートの不足検知
記事当たり介入時間人間の確認・修正時間 ÷ 公開記事数実際の時短効果
検索流入Search Consoleのクリック数・表示回数SEO成果
CTA到達率CTAクリック数 ÷ 記事閲覧数収益導線の機能確認

初期目標値は、外部の成功例をそのまま使わず、自分の最初の20〜30回を基準値にします。その後、タイムアウト率、修正率、介入時間を月単位で改善します。

AI CLI自動化の限界と反論

「AI CLIを使えばブログを完全放置できる」という主張には注意が必要です。

第一に、CLIの認証方式や提供条件は変わります。2026年7月21日のログでも、Gemini CLIのクライアント互換性に関するエラーが発生しました。

第二に、AIは自然な文章で誤情報を生成できます。複数AIによるレビューも、一次資料の確認を代替しません。

第三に、記事数と収益は比例しません。検索需要、競合、サイト評価、CTA、商品との整合性がなければ、記事を増やしても売上にはつながりません。

第四に、Hiroの現在の実装は、レビューや最終チェックが失敗しても直前の原稿を採用する場合があります。可用性を優先できる一般記事には使えますが、誤りの影響が大きいテーマでは公開停止へ変更すべきです。

AI CLI自動化は収益を保証する仕組みではありません。人間の作業時間と介入回数を減らし、検証可能なデジタル資産を継続運用するための基盤です。

今日から実行するチェックリスト

まずは1記事だけ、次の順序で試してください。

  • AI CLIを単体実行する
  • 入力、出力、成功条件を決める
  • 240秒など上限付きのタイムアウトを設定する
  • 下書き、レビュー、最終確認を分ける
  • 空出力と非ゼロ終了コードを失敗にする
  • 一次情報、失敗例、反論を品質条件へ入れる
  • Markdown保存前にAIスロップ検査を行う
  • Notion保存とGit pushを別々に記録する
  • push後に本番URLのHTTP 200を確認する
  • 無人完了率と公開後修正率を計測する

最初の目標は「毎日大量に投稿すること」ではありません。

タイムアウトしたら保存しない。品質基準を下回ったら公開しない。認証エラーが出たら原因と切り替え先を記録する。この3つを再現できれば、AI CLIブログ自動化の土台はできています。