「Git Push成功」で終わらせない｜AIブログ自動化を実行ログで監査する7ステップ

AIブログの自動化では、「記事ファイルが生成された」「Git Pushに成功した」というログだけで、処理全体を成功扱いしがちです。

しかし、その間にレビューが失敗し、未検査の原稿がフォールバック採用されているかもしれません。Notion APIが成功していても、本文の欠落や表示崩れまでは確認できません。

この記事を読むと、次のことができるようになります。

• 並行実行された複数の記事を正しく識別する
• レビュー失敗時に、どの原稿が採用されたか追跡する
• 品質基準未達の記事を公開前に止める
• Notion保存、Git Push、公開画面を段階的に検証する
• 初心者でも直近1記事から監査を始める

題材にするのは、このサイトで2026年7月23日に記録された実行ログです。通常記事はNotion保存とGit Pushまで進みましたが、並行していた別の販促記事はAIスロップ検査に失敗し、公開前に停止しました。

この画像は処理の概念図であり、実行成功を証明するスクリーンショットではありません。実行証拠として使うのは、以下に示す日時付きログ、保存状態、コミットIDです。

2026年7月23日の実行で何が起きたのか

確認対象は、リポジトリ内の次の情報です。

通常記事の生成処理

保存された記事は「PythonでPDF帳票から情報を抽出する方法｜実測ログ付き9ステップ実践ガイド」です。Gitコミットは 65144e9 で、確認時点ではローカルの HEAD と origin/main がこのコミットを指していました。

実行ログの主要部分を、読みやすいように抜粋すると次のとおりです。

17:43:34 draft: codex CLI succeeded
17:43:39 review: gemini CLI failed: Error authenticating
17:47:29 review: codex CLI succeeded
17:47:29 final_check: calling codex CLI
17:51:48 final_check: codex CLI failed: CLI timeout after 240s
17:51:48 Final check failed; using improved article
17:51:48 Saved post
17:51:49 Saved to Notion successfully
17:51:53 git push succeeded to origin/main

この記録から確認できるのは、「最終チェックを通過したこと」ではありません。

確認できるのは、最終チェックがタイムアウトし、システムがレビュー済み原稿を採用して保存・Pushしたことです。可用性のためのフォールバックは機能しましたが、最終品質が保証されたとはいえません。

並行していた販促記事の生成処理

同じ時間帯には、別の販促記事生成処理も動いていました。

不足項目としてログに記録されたのは、次の9項目です。

• Hiroまたはサイト固有の実体験・データ
• 一人称の具体的なエピソード
• 他者が書けない独自情報
• 根拠のある数字
• 冒頭で得られる便益
• 視覚的な証拠
• 反論・限界・注意点
• 読後のアクション
• 差別化

ここで、通常記事と販促記事を混同してはいけません。

通常記事はNotion保存とGit Pushまで進みました。AIスロップ検査で停止したのは、並行実行されていた別の販促記事です。

時刻だけでログを読むと、通常記事が品質検査に失敗したように見える可能性があります。最低でも job_id、記事タイトル、サイト名、ジョブ種別を照合する必要があります。

ステップ1：処理を工程単位に分解する

AIブログ生成を一つの大きな関数として扱うと、失敗地点も採用された成果物も追跡できません。

最低でも、次の工程に分けます。

1. トピック選択
2. ドラフト生成
3. 内容レビュー
4. 最終チェック
5. 品質ゲート
6. Markdown保存
7. Notion保存
8. Git commit・Push
9. 公開画面の確認

各工程では、次の情報を構造化して記録します。

timestamp
run_id
job_id
site_id
article_title
article_type
stage
attempt
tool
status
duration_ms
input_version
output_path
output_sha256
fallback_used
error_type
error_message

run_id と job_id は分けてください。

• run_id：自動化プログラムを1回起動した単位
• job_id：その中で生成する記事ごとの単位

同じ起動処理から通常記事と販促記事を並行生成する場合でも、job_id が異なればログを正しく分離できます。

ログ形式にはJSON Linesが扱いやすいでしょう。

{"timestamp":"2026-07-23T17:51:48+09:00","run_id":"run-20260723-174240","job_id":"article-027","stage":"final_check","tool":"codex","status":"timeout","duration_ms":240000,"fallback_used":"reviewed_article"}

自由文のログも人間には読みやすいのですが、KPI集計や自動監査には構造化ログが必要です。

ステップ2：失敗時に採用する原稿を明文化する

レビューAIやCLIは必ずしも成功しません。

今回の通常記事では、Geminiのレビューが認証エラーで失敗し、Codexへ切り替わりました。Codexのレビューは成功しましたが、その後の最終チェックは240秒でタイムアウトしています。

失敗後の挙動を、その場の判断に任せてはいけません。

今回の実装は、最終チェック失敗時にレビュー済み原稿を採用して公開工程へ進めました。これは実際に起きた挙動です。

一方、安全性を重視するなら、今後は「独立した品質ゲートに合格していること」を公開継続の条件にするべきです。実際の挙動と推奨設計を分けて記録してください。

{
  "review_status": "passed",
  "final_check_status": "timeout",
  "quality_gate_status": "not_verified",
  "fallback_used": "reviewed_article",
  "publish_decision": "manual_review_required"
}

さらに、採用した原稿のハッシュ値を記録すると、どの版をNotionやGitへ保存したのか後から照合できます。

Get-FileHash -Algorithm SHA256 ".\path\to\article.md"

ステップ3：AIスロップ検査を本当の停止条件にする

AIスロップ検査は、点数を表示するだけでは品質ゲートになりません。基準未達の記事が保存・公開工程へ進まないことまで確認して、初めて停止条件として機能します。

このサイトの設定ファイルには、次の10項目があります。

1. Hiroまたはサイト固有のデータ
2. 日時付き、または一人称の具体的な経験
3. 実行ログや検証結果などの独自情報
4. 根拠や出典を伴う数字
5. 冒頭で読者の便益が分かる
6. 禁止されているAI定型表現がない
7. 画像・グラフ・スクリーンショットなどの視覚情報
8. 反論・限界・失敗対策
9. 読後に実行できるアクション
10. 類似記事との差別化

最低合格点は8点です。

今回の失敗ログは score=1/8 と表示されていますが、設定上の検査項目は10個です。「1点、合格基準8点」という意味だとしても、分母が満点にも合格点にも見えるため、監査時に誤読されます。

ログ表記は次のように分けるのが安全です。

score=1
max_score=10
passing_score=8
passed=false

また、キーワードがあるだけで加点する仕組みには限界があります。

悪い例:
実際にテストしたところ成功しました。

これでは、何を、いつ、どの条件で確認したのか分かりません。

改善例:
2026年7月23日17時51分49秒の実行ログで、
記事保存後のNotion保存処理が成功したことを確認した。
ただし、APIの成功ログだけでは、Notion画面上の表示や
本文の完全一致までは確認できていない。

証拠として扱う記述には、最低でも次の要素を含めます。

• 実行日時
• 対象ジョブ
• 実行した処理
• 確認できた結果
• 確認できていない範囲

ステップ4：保存成功を3段階で検証する

「保存成功」というログは、保存内容の正しさまで証明しません。

レベル1：APIやコマンドが成功した

Saved to Notion successfully.
git push succeeded to origin/main

分かるのは、呼び出した処理が成功として終了したことです。

本文の欠落、表示崩れ、デプロイ失敗までは分かりません。

レベル2：保存先から再取得して照合する

Notion保存後は、作成・更新したページをAPIで再取得し、次を照合します。

• NotionページID
• 記事タイトル
• 本文の文字数またはハッシュ値
• 保存日時
• カテゴリ
• 公開URL
• コードブロック数
• 画像数

Git Push後は、古いリモート追跡情報を参照しないよう、先に fetch します。

git fetch origin main
git status --short
git log -1 --oneline
git rev-parse HEAD
git rev-parse origin/main
git ls-remote origin refs/heads/main

HEAD と origin/main が一致すれば、取得済みのリモート状態とローカルコミットが一致しています。git ls-remote でも同じコミットが返れば、サーバー側のブランチを直接確認できます。

ただし、未コミットの変更が残っている場合は、HEAD が一致していても作業ディレクトリの内容までPushされたとは限りません。git status --short も必ず確認してください。

レベル3：読者が見る画面を確認する

Notionではページを開き、見出し、表、コードブロック、画像が崩れていないか確認します。

ブログでは公開URLへアクセスし、次を確認します。

• HTTPステータスが200か
• ページタイトルが一致するか
• 本文の主要見出しが存在するか
• 画像が読み込まれるか
• 内部リンクと外部リンクが動くか
• front matterが本文へ露出していないか
• canonical URLが正しいか
• 対象コミットのデプロイが完了しているか

ログ上の成功はレベル1です。読者が見る画面まで確認して、初めて公開成功と判定できます。

ステップ5：失敗を原因別に分類する

すべての失敗を「AIが不安定だった」でまとめると、対策を誤ります。

2026年7月23日のログでは、少なくとも次の4種類を確認できます。

認証・利用資格エラー

17時43分のGeminiレビューは、プロンプトの内容ではなく認証・クライアント利用資格の段階で失敗しました。

確認対象は次のとおりです。

• CLIのログイン状態
• 利用しているアカウント
• 利用プラン
• CLIの対応状況
• トークンの期限
• 非対話実行で認証情報を読めるか

プロンプトを書き換えても、認証エラーは解決しません。

コマンド長超過

同日10時20分以降の別ジョブでは、Geminiレビューに The command line is too long が繰り返し記録されていました。

長文をコマンド引数として渡さず、標準入力または一時ファイルを利用します。

Get-Content -Raw ".\article.md" | reviewer-command

一時ファイルを使う場合は、処理終了後に削除できたか、ファイル名がログへ過剰に露出していないかも確認します。

タイムアウト

Codexのレビューや最終チェックでは、240秒のタイムアウトが発生しています。

対策は次の順で検討します。

1. 入力記事を見出し単位に分割する
2. 校正、事実確認、Markdown検査を別工程にする
3. 工程ごとにタイムアウト値を設定する
4. タイムアウト後の子プロセス残留を確認する
5. 同じジョブの二重実行を防ぐ
6. 再実行回数に上限を設ける
7. 再実行時にも同じ job_id と試行番号を記録する

呼び出し元がタイムアウトしても、子プロセスが動き続ける場合があります。確認せずに再実行すると、記事の二重保存や二重Pushにつながります。

品質基準未達

AIスロップ検査の失敗は、インフラ障害ではありません。生成された記事が公開基準を満たしていない状態です。

この場合は、同じプロンプトを無条件に再実行するのではなく、不足項目を具体的な修正指示へ変換します。

不足項目:
- 根拠のある数字
- 視覚的証拠
- 反論・限界
- 読後アクション

再生成指示:
- 実行日時、対象ジョブ、確認結果を明記する
- 実行ログの抜粋と時系列表を追加する
- 概念図と実行証拠を区別する
- 今回の検証結果を一般化できない条件を書く
- 読者が今日試せる確認手順を追加する

ステップ6：記事数ではなく品質KPIを追う

記事本数だけをKPIにすると、短時間で大量生成できる薄い記事へ最適化されます。

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

実績がない段階で、理想的な目標値を断定する必要はありません。

まず2週間、実測値と失敗理由を集めます。その後、「公開確認率100%」「フォールバック率5%未満」など、工程ごとの目標値を決めます。

フォールバック率が上昇しているのに公開本数だけ維持されている場合、表面上は正常でも内部の品質リスクが高まっています。

ステップ7：1記事分の証拠を一つにつなぐ

初心者が最初から監視ダッシュボードを作る必要はありません。

まず、直近1記事について次の情報を1行にまとめます。

記事タイトル | job_id | 生成結果 | レビュー結果 | 最終チェック | 品質点数 | 保存先 | commit ID | 公開確認

今回の通常記事を当てはめると、次のようになります。

PythonでPDF帳票から情報を抽出する方法
| job_id未記録
| Codex成功
| Gemini失敗→Codex成功
| 240秒タイムアウト
| 通常記事の点数はログ上で未確認
| Markdown・Notion
| 65144e9
| 公開画面は未確認

この1行だけでも、次の不足が見えます。

• job_id が記録されていない
• 通常記事の品質点数を追跡できない
• Notionの再取得結果がない
• 公開画面の確認結果がない
• フォールバック採用記事であることを公開状態と分離できていない

空欄を埋める仕組みを一つずつ追加すれば、監視システムを過剰に作り込まずに改善できます。

毎日使える運用チェックリスト

生成前

• AI CLIの認証状態を確認した
• Gitブランチと保存先を確認した
• 同じジョブが実行中でないことを確認した
• 記事テーマの重複を確認した
• run_id と job_id を発行した
• APIキーや個人情報をログへ出さない設定にした

生成後

• ドラフト生成結果を確認した
• レビューに使われたAIを確認した
• フォールバックの有無を確認した
• 採用原稿のバージョンとハッシュ値を記録した
• AIスロップ検査の点数と不足項目を確認した
• 保存されたMarkdownのパスを確認した
• Notionページを再取得した
• GitコミットIDを記録した
• リモートブランチへの反映を確認した
• 公開ページのタイトル、画像、リンクを確認した

翌日

• エラー件数を原因別に集計した
• タイムアウトした子プロセスが残留していないか確認した
• 同一記事の二重生成がないか確認した
• 公開後に修正した記事を記録した
• 不足が多かった品質項目を生成プロンプトへ反映した
• フォールバック率が上昇していないか確認した

運用設計で見落としやすい5つのポイント

1．成功ログだけで完了扱いしていないか

Notion APIの成功と、Notion画面上での表示成功は別です。Git Pushの成功と、Webサイトへのデプロイ成功も同じではありません。

保存先からの再取得と、公開画面の確認を分けて記録します。

2．フォールバックが品質低下を隠していないか

フォールバックは処理停止を防ぎますが、頻発すると品質問題を見えにくくします。

「公開できた記事数」だけでなく、「どの段階の原稿を採用したか」を記録してください。

3．並行ジョブを混同していないか

複数記事を同時生成する場合、同じログファイルへ時系列で書くだけでは不十分です。

run_id、job_id、記事タイトル、サイト名、ジョブ種別をすべてのログ行へ付けます。

4．タイムアウト後のプロセスを確認しているか

呼び出し元がタイムアウトしても、子プロセスが動き続ける可能性があります。

再実行前に、子プロセス、ロックファイル、保存済み成果物、既存コミットを確認します。

5．品質検査をキーワードゲームにしていないか

「Hiro」「ログ」「検証」という単語があるだけでは、一次情報とはいえません。

一次情報として扱う記述には、少なくとも次の4要素が必要です。

• いつ実行したか
• 何を実行したか
• どの結果を確認したか
• どこまで確認できていないか

反論：人間が毎回読めば自動検査は不要では？

記事数が少ない間は、人間による全文レビューのほうが確実です。

しかし、件数が増えると、確認項目の抜けや判断のばらつきが生じます。自動検査の目的は、人間を完全に置き換えることではありません。

• 明確な基準違反を自動で止める
• 人間が確認すべき記事を絞る
• 同じ基準で継続的に測定する
• 失敗傾向を数値化する

事実関係、法的表現、医療・金融情報、引用、著作権、個人情報については、自動検査に合格しても人間による確認を残すべきです。

今回の検証で確認できないこと

今回確認できたのは、特定のローカル環境における2026年7月23日の処理結果です。

次の点は、実行ログだけでは証明できません。

• Notionへ本文が完全な状態で保存されたか
• Notion画面で表やコードブロックが正しく表示されたか
• Git Push後に公開サイトのビルドが完了したか
• 公開ページで画像やリンクが正常に動作したか
• 最終チェックで検出されるはずだった問題が残っていないか
• AIスロップ検査の点数が記事の事実性や有用性を正しく表しているか

また、記事内の概念図は処理の理解を助けるためのもので、実行証拠ではありません。厳密な視覚証拠が必要なら、秘密情報をマスクした実行画面、Notion再取得結果、公開ページ、対象コミットの画面を追加する必要があります。

品質は、次の3層で管理します。

1. Markdownや必須項目の機械検査
2. 実行ログと保存先の照合
3. 人間による重要箇所と公開画面の確認

この運用の差別化ポイント

一般的なAIブログ自動化の記事は、「生成AIを使えば記事作成を効率化できる」という説明で終わりがちです。

この運用で重視するのは、AIを使ったことではありません。

• どの工程が失敗したか
• 失敗後にどの原稿を採用したか
• 公開を止める条件は何か
• 成功ログをどこまで再検証したか
• 確認できなかった範囲はどこか

認証エラー、コマンド長超過、240秒タイムアウト、品質基準未達も含めて残すことで、読者や運用担当者が結果を再検証できます。

今日できる最小アクション

まず、直近1記事について次の表を作ってください。

次に、実行ログから各欄を埋めます。

空欄が残った部分が、現在の自動化で追跡できていない工程です。まず1記事を、生成開始から公開画面まで追える状態にしてください。

まとめ：増やすべきなのは記事数ではなく「追跡可能な成功」

2026年7月23日の通常記事生成では、Geminiレビューの認証エラーと、Codexによる最終チェックの240秒タイムアウトが発生しました。

システムはレビュー済み原稿をフォールバック採用し、Markdown保存、Notion保存、Git Pushまで進めました。ただし、最終チェック通過、Notion画面の正常表示、公開サイトへの反映までは実行ログだけで証明できません。

一方、並行していた別の販促記事は、AIスロップ検査で score=1/8 と判定され、公開前に停止しました。

AIブログ自動化に必要なのは、「絶対に失敗しないAI」ではありません。

必要なのは、失敗箇所を特定し、採用した成果物を記録し、品質基準未達の記事を止め、公開画面まで追跡できる仕組みです。

記事本数を増やす前に、まず直近1記事について、生成、レビュー、最終チェック、品質検査、保存、Push、公開確認の証拠を一つにつないでください。