「全工程成功」でも誤公開は起きる｜AI生成記事を守る7段階ゲートとレビューKPI

「ドラフト生成、レビュー、最終チェックがすべて成功した」

このログを見れば、記事は正常に完成したと思うはずです。

ところが、Hiroが運営する auto-ai-blog では、各CLIが正常終了したにもかかわらず、完成原稿ではなく「記事本文を送ってください」という確認メッセージが記事として保存されたことがありました。

原因は、処理の成否と成果物の品質を同じ「成功」として扱っていたことです。

AI生成記事の品質管理で必要なのは、毎回人間が全文を読むことでも、AIにもう一度「確認して」と頼むことでもありません。人間が行っている判断を、次の3種類に分解することです。

• 機械で即時判定できる公開条件
• 該当したら必ず停止する重大条件
• 判断が割れる場合だけ人間へ回す例外条件

この記事では、Hiroの auto-ai-blog で2026年7月17日に確認された誤保存事例をもとに、AI生成記事の人間レビューを自動化する7段階のゲートを解説します。

公開停止条件、失敗原稿の隔離、回帰テスト、運用KPIまで扱うため、「チェックリストを作ったが、結局すべて手作業で確認している」という状態から抜け出したい人に向いています。

この記事の一次情報と検証範囲

この記事は一般論だけで構成したものではありません。次のリポジトリ内データを確認したうえで、事例と対策を整理しています。

2026年7月17日の再検証では、誤保存されたMarkdownを現行の generator.slop_guard で評価し、score: 8、passed: true になることを確認しました。

また、次のコマンドを実行し、関連する7件のテストが通過することも確認しています。

python -m pytest tests/test_slop_guard.py tests/test_generate.py -q

ただし、テスト通過は「既存テストに書かれた条件どおり動く」ことを示すだけです。「確認メッセージを記事として保存しない」という要件まで保証するものではありません。

なお、記事内の2点の画像はフローを理解するためのイメージ図です。実際の障害を証明する一次情報は、本文に掲載する実行ログ、保存ファイル、評価結果です。

AI生成記事で人間レビューが必要な理由

AI生成記事には、次のようなリスクがあります。

• 誤情報や根拠のない数字を追加する
• 著作権やプライバシーに関わる内容を出力する
• 医療、金融、法律上の判断を断定する
• 誇大表現によってブランドの信用を損なう
• 検索意図と異なる文章を生成する
• 元原稿にあった画像やリンクを消す
• 記事ではなく質問、謝罪、確認文を出力する
• レビュー結果やプロンプトの一部を本文として残す

すべての記事を人間が最初から最後まで読む方法には限界があります。記事数に比例して確認時間が増え、担当者によって判断も変わるからです。

一方、AIに「問題がないか確認してください」と頼むだけでも不十分です。AIの返答が自然であることと、公開可能な記事であることは別だからです。

人間レビューの役割は、毎回文章を手直しすることではありません。公開してよい条件と、必ず止める条件を定義し、機械では判断できない例外だけを処理することです。

Hiroサイトで実際に起きた誤保存

2026年7月17日、Hiroの auto-ai-blog では、「物件情報入力を減らすためのデータ連携設計」というトピックの記事生成が実行されました。

実行ログには、次の記録が残っています。

05:27:39 Selected topic 22/50
05:28:54 draft: codex CLI succeeded
05:29:05 review: gemini CLI failed
05:29:48 review: codex CLI succeeded
05:30:25 final_check: codex CLI succeeded
05:30:25 Saved post
05:30:26 Saved to Notion successfully
05:30:29 git push succeeded to origin/main

Gemini CLIは認証エラーになりましたが、Codex CLIへのフォールバックに成功しています。その後、最終チェック、記事保存、Notion保存、Git pushまで完了しました。

ここで正確に区別したいのは、すべてのレビュー手段が成功したわけではないという点です。Gemini CLIは失敗しています。しかし、システム全体としてはフォールバック後に処理を継続し、最終的に保存とpushまで成功しました。

保存された記事のタイトルは、次の内容でした。

最終チェックには記事本文が必要です

本文も完成記事ではなく、次のような確認メッセージでした。

ご提示いただいた内容はブログ記事ではなく、
出力先を確認するためのメッセージです。

次のいずれかを送ってください。

1. レビュー対象となる記事の全文
2. リポジトリ内にある対象記事のファイルパス

AIの応答自体は不自然ではありません。入力された内容だけでは記事を完成できないと判断し、追加情報を求めています。

事故の原因は、その応答をシステムが「正常な完成記事」として保存したことです。

なぜ8点で合格したのか

Hiroサイトでは、Notion由来のAIスロップ防止基準を generator/ai_slop_guidelines.json に保存しています。

2026年6月26日に取得された設定は、次の内容です。

• チェック項目：10項目
• 合格ライン：8点
• レビュー役割：5種類
• 役割：編集長、専門家、SEO、画像品質、法務・リスク

チェック項目には、Hiro固有のデータ、具体的なエピソード、根拠のある数字、視覚的証拠、限界、読後アクション、差別化などが含まれます。

誤保存された記事を現行の generator.slop_guard で再評価した結果は、次のとおりでした。

score: 8
minimum_score: 8
passed: true

不合格だったのは、次の2項目です。

一人称の具体エピソード: false
読後アクション: false

ほかの8項目は合格しました。

たとえば、確認文に含まれていた「Hiro」「検証結果」「画像」「注意点」「具体的な手順」といった語が、複数の評価条件を満たしました。「2026年」などの日付は根拠のある数字として判定され、記事ではなくても合格点へ到達できる構造でした。

この事例が示しているのは、合計点だけでは重大事故を止められないということです。

点数制レビューと公開停止ゲートを分ける

記事品質には、加点方式が向いている項目と、合否方式にすべき項目があります。

画像がなくても成立する記事はあります。しかし、「本文が存在しない」「確認メッセージで終わっている」という状態は、ほかの評価が高くても公開できません。

重大条件を合計点へ混ぜず、独立した公開停止ゲートにすることが誤公開対策の出発点です。

公開可否は、次のように判定します。

公開可能 =
  入力が正常
  AND 記事構造が正常
  AND 重大条件に該当しない
  AND 画像・リンクの差分が許容範囲内
  AND 高リスク主張の確認が完了
  AND 品質スコアが基準以上

どれか1つでも false なら、公開ではなく隔離へ進めます。

AI生成記事の人間レビューを自動化する7ステップ

ステップ1：正常な記事の構造を定義する

最初に、「品質が高い文章」ではなく「記事として成立している状態」を定義します。

最低限、次の条件を機械検査できるようにします。

H1見出しが1つある
導入文がある
H2見出しが2つ以上ある
本文が最低文字数を超えている
箇条書きまたは手順がある
タイトルと本文のテーマが一致している
質問や確認依頼だけで終わっていない
front matter以外に本文がある

「魅力的」「専門的」といった抽象語だけでは、自動判定が安定しません。「H2が2つ以上」「本文2,000字以上」のように、観測可能な条件へ変換します。

最低文字数は記事の目的によって調整してください。FAQなら短くても成立しますが、実務手順の記事で300字しかなければ、入力欠落や生成失敗を疑うべきです。

ステップ2：重大な公開停止条件を決める

次に、1件でも該当したら公開しない条件を定義します。

「記事本文を送ってください」などの確認要求が含まれる
「作成してよいでしょうか」で終わる
レビュー結果や自己評価だけが出力されている
元記事にあった画像リンクが減っている
出典のない金額、割合、件数が追加されている
個人情報や認証情報が含まれている
医療・金融・法律上の判断を無条件に断定している
プロンプトやシステムメッセージが混入している

単語の一致だけに依存すると、正常な記事まで止める可能性があります。構造、文字数、文末などを組み合わせて判定します。

たとえば、「確認してください」という語があるだけでは不合格にしません。次の条件が同時に成立した場合に隔離します。

本文が最低文字数未満
AND H2がない
AND 末尾が質問または提出依頼
AND 「記事本文を送ってください」が含まれる

複合条件にすることで、「公開前に内容を確認してください」と説明する正常記事の誤停止を減らせます。

ステップ3：入力と出力の対応を検証する

AIの出力が自然でも、入力に答えていなければ失敗です。

生成前後で次の値を記録します。

• トピック名
• 対象読者
• 記事の目的
• 指定キーワード
• 元原稿の文字数
• 出力原稿の文字数
• 元画像リンク数
• 出力画像リンク数
• 必須見出しの有無
• 使用したモデルまたはCLI
• 処理開始・終了時刻
• フォールバックの有無
• プロンプトまたは入力データの識別子

今回の事故なら、「トピックは物件情報のデータ連携なのに、出力は記事提出を求める確認文」という不一致を検知できます。

最初の実装では、タイトル、冒頭、H2見出しから主要語を抽出し、元トピックとの一致を確認します。一致度が閾値を下回った場合は、自動公開せず隔離します。

意味の一致をAIだけで判定すると評価が揺れるため、トピック中の必須語、カテゴリ、想定読者など、ルールで確認できる値も併用してください。

ステップ4：事実・数字・引用を個別に検査する

読みやすさと事実性は別々に確認します。

数字を検出したら、その近くに次のいずれかがあるかを調べます。

• 出典URL
• 調査主体
• 実行ログ
• 測定日
• 測定条件
• 「設定値」「試算」「実測」の区分

「精度99%」「売上が3倍」「月10万円」のような数字は、根拠がなければ公開停止候補です。

ただし、「URLがあるから正しい」とは限りません。リンク先へアクセスできるか、そのページが主張を実際に裏付けているか、情報が古くなっていないかも確認する必要があります。

引用では、次の項目を記録します。

引用元
引用範囲
取得日
原文からの改変有無
引用を使う理由

法務、医療、金融など影響の大きい分野では、出典URLがあっても自動公開せず、人間レビューを必須にする方が安全です。

ステップ5：SEOと読みやすさを採点する

重大条件をすべて通過した記事だけを、点数制の品質評価へ進めます。

SEOでは、次の項目を確認します。

• H1に主要キーワードが自然に含まれる
• 導入文で読者の悩みと得られる結果が分かる
• H2が検索意図ごとに整理されている
• 同じキーワードを不自然に繰り返していない
• タイトルと本文が同じ検索意図に答えている
• 見出しだけで記事の流れを把握できる
• 関連記事やサービスへの導線が自然に配置されている

読みやすさでは、一文が長すぎないか、同じ接続詞が続いていないか、段落が大きすぎないかを確認します。

初期値として、一文が100〜120文字を超えたら分割候補にできます。ただし、これは業界共通の合格基準ではありません。文字数だけで強制分割すると意味が壊れるため、修正候補の抽出にとどめます。

ステップ6：失敗原稿を隔離し、例外だけ通知する

検査に失敗した記事をすぐに削除してはいけません。原因を分析できるよう、公開領域とは別の場所へ隔離します。

保存する情報は次のとおりです。

原稿ID
トピック
生成日時
使用モデル
元の入力
生成された出力
失敗したゲート
検出箇所
品質スコア
再試行回数
フォールバック履歴
公開状態
人間の判定結果

通知文には、原稿全文ではなく、判断に必要な情報を載せます。

判定：公開停止
理由：確認メッセージを検出
該当箇所：「次のいずれかを送ってください」
構造：H1なし、H2なし、本文486字
画像：入力0件、出力0件
トピック一致：不一致
推奨処理：入力データを確認して再生成

これなら、人間は全原稿を読まずに「再生成」「修正して公開」「破棄」を選べます。

公開経路では、レビューが失敗しても処理を続けるフェイルオープンではなく、安全側で止まるフェイルクローズを採用します。

レビュー成功 ＋ 必須条件合格 → 次のゲート
レビュー失敗                 → 隔離
タイムアウト                 → 隔離
JSON解析失敗                 → 隔離
入力欠落                     → 隔離

ステップ7：人間の判断をルールへ戻す

人間レビューで見つかった失敗を、その場の修正だけで終わらせないようにします。

次の順番で改善します。

1. 失敗した入力と出力を保存する
2. 同じ事故を再現するテストを作る
3. 公開ゲートへ検出条件を追加する
4. 正常記事を誤って止めないか確認する
5. 隔離環境で一定期間検証する
6. 問題がなければ本番の公開経路へ反映する

今回の事例なら、「品質スコアが8点でも確認メッセージである」という原稿を回帰テストへ追加します。

期待結果は次のとおりです。

quality_score >= 8
article_structure_valid = false
meta_response_detected = true
publishable = false

Python風の擬似コードにすると、公開条件は次のようになります。

def can_publish(article, source):
    structure = validate_structure(article)
    risks = detect_blocking_risks(article)
    assets = compare_assets(source, article)
    quality = evaluate_quality(article)

    return (
        structure.passed
        and not risks.blocking_hit
        and assets.images_preserved
        and quality.score >= quality.minimum_score
    )

このサイクルを続けると、人間レビューは原稿を毎回修正する作業から、判定基準を育てる作業へ変わります。

実運用で使える公開ゲートの順番

原因を切り分けやすくするには、次の順番で検査します。

入力検証
  ↓
記事構造の検証
  ↓
重大リスクの検出
  ↓
画像・リンクの差分検証
  ↓
事実・数字・引用の検証
  ↓
SEO・読みやすさの採点
  ↓
公開または隔離
  ↓
公開後の表示確認

各段階の合格条件と失敗時の処理は、次のように整理できます。

CLI succeeded が示すのは、コマンドが終了コード0で結果を返したことです。記事品質、保存内容、公開ページの表示まで保証するものではありません。

次の3つを別々に記録してください。

処理成功：CLIが正常終了した
品質合格：記事構造、根拠、重大条件が基準を満たした
公開成功：正しい本文、画像、CTAを公開URLで確認できた

画像リンクを確実に保持する方法

画像リンクの保持は、AIによる目視レビューより、生成前後の差分検査に向いています。

Markdown画像だけを抽出し、元原稿のURLが出力原稿にも存在するか確認します。

import re

IMAGE_PATTERN = re.compile(r"!\[[^\]]*]\((https://image\.pollinations\.ai/[^)]+)\)")

def extract_image_urls(markdown):
    return IMAGE_PATTERN.findall(markdown)

source_images = set(extract_image_urls(source_markdown))
output_images = set(extract_image_urls(output_markdown))

missing_images = source_images - output_images

if missing_images:
    raise ValueError(f"画像リンクが削除されました: {sorted(missing_images)}")

件数だけを比較すると、元画像を削除して別の画像を追加した場合に見逃します。URLの集合差分まで確認してください。

URLのクエリ文字列には & や %20 が含まれるため、AIや整形処理が勝手にデコード、短縮、再生成していないかも確認します。

レビュー自動化で追うべきKPI

公開本数だけを追うと、誤公開を増やしても成果が伸びたように見えます。品質と運用コストを分けて測定してください。

1. 自動通過率

自動通過率 = 人間確認なしで公開できた記事数 ÷ 全生成記事数

高すぎる場合はゲートが緩い可能性があります。低すぎる場合はルールが厳しすぎるか、生成品質に問題があります。

最初から目標値を決め打ちせず、隔離運用で基準値を取得してから改善します。

2. 誤通過率

誤通過率 = 公開後に重大修正または削除した記事数 ÷ 自動公開記事数

最優先で下げたいKPIです。

確認メッセージ、個人情報、根拠のない高リスク主張を含む記事が1本でも公開された場合は、平均品質スコアより先に原因を調べます。

3. 誤停止率

誤停止率 = 人間が公開可能と判断した隔離記事数 ÷ 隔離記事数

この値が高いと、担当者の確認作業が増えます。検出条件が単語一致に偏っていないか、複合条件が厳しすぎないかを確認します。

4. 人間レビュー時間

記事1本あたりの確認時間と、1週間の総確認時間を記録します。

自動通過率が上がっても、人間がログ、差分、出典を毎回手作業で調べているなら、レビューを十分に自動化できていません。

5. 再発率

再発率 = 過去に対策した原因で再び失敗した件数 ÷ 全失敗件数

人間が一度修正した問題が繰り返される場合、判断がテストやゲートへ反映されていません。

6. 復旧率と再試行コスト

次の値も記録します。

• 自動再生成で復旧した割合
• 1記事あたりの再試行回数
• レビューのタイムアウト率
• モデル別の失敗率
• 1記事あたりの生成・レビューコスト
• 隔離から公開までの所要時間

モデルを増やすほど安全になるとは限りません。認証エラー、タイムアウト、出力形式の違いも増えるため、フォールバック後の品質検査が欠かせません。

7. 公開後品質

検索表示回数、クリック率、平均掲載順位、CTAクリック率、問い合わせ率も追います。

機械検査を通過したことと、読者に役立つことは同義ではありません。公開ゲートは事故を減らす仕組みであり、検索成果や売上を保証するものではないからです。

よくある失敗と対策

AIを2回通せば安全だと思う

生成AIによる再レビューは有効ですが、同じ入力欠落や前提誤りを引き継ぐ可能性があります。

構造、リンク数、禁止パターン、入力との一致といった決定的な条件は、AIの感想ではなくコードで検査します。

8点以上なら公開する

合計点方式では、本文がないという重大事故を、ほかの加点で埋め合わせられます。

品質スコアと必須条件を分離し、必須条件にすべて合格した記事だけを次へ進めます。

失敗時に直前原稿を自動公開する

Hiroサイトで確認した処理では、レビューに失敗した場合にドラフト、最終確認に失敗した場合に直前の改善原稿を採用する経路があります。

可用性を維持する設計としては理解できますが、前段階の原稿が安全であるとは限りません。フォールバック後も、構造検査と重大リスク検査を必ず通す必要があります。

テストが通れば安全だと思う

テストは、書かれている条件について動作を確認します。まだテストに含まれていない事故までは防げません。

本番で起きた失敗を再現テストへ追加し、同じ入力で公開が停止することを確認してください。

AI生成画像を視覚的証拠として扱う

説明用のAI画像は、概念を理解しやすくする図としては利用できます。しかし、処理の成功、性能、障害原因を証明するものではありません。

視覚的証拠として使うなら、次のような実データを掲載します。

• 個人情報をマスクした実行ログのスクリーンショット
• 公開前後の差分
• 品質ゲートの判定JSON
• 隔離された原稿の一覧
• 公開URLで画像とCTAを確認した記録

説明用画像と一次証拠を明確に区別してください。

完全自動化できないケースと限界

次の領域では、人間レビューを残す方が現実的です。

• 医療、金融、法律、安全に関わる助言
• 他者の権利や評判へ影響する記述
• 公開前情報や個人情報を扱う記事
• ブランドの公式見解になる文章
• 根拠資料が非公開で機械検証できない主張
• 皮肉、文化的配慮、社会的文脈が大きく影響する表現

自動検査にも誤検知と見逃しがあります。

キーワード検出は導入しやすい反面、文脈を十分に理解できません。AI判定は文脈を扱いやすい一方で、結果が一定しないことがあります。一次情報そのものが間違っていれば、複数のAIが同じ誤りを通す可能性もあります。

そのため、ルールベース検査、AIレビュー、人間判断を組み合わせます。人間をゼロにするのではなく、人間が対応する件数を減らし、その判断を次の自動化へ戻す設計が適しています。

初心者向けの導入手順

最初から7段階すべてを実装する必要はありません。次の順番なら、小さく始められます。

今日：3つの停止条件を追加する

現在の自動投稿処理へ、次の条件を追加します。

1. H1とH2が存在し、本文が最低文字数を超えている
2. 「記事本文を送ってください」「作成してよいでしょうか」だけで構成された原稿を公開しない
3. 元原稿の画像URLが出力原稿から1つでも消えていたら停止する

今週：失敗原稿を1本テストにする

過去の失敗記事を1本選び、次の記録を作ります。

失敗内容：
検出できなかった理由：
公開を止める条件：
正常記事を誤停止しない条件：
追加する回帰テスト：

その原稿をテストデータとして保存し、品質点が高くても公開不可になることを確認します。

来週：隔離運用を始める

いきなり自動公開へ接続せず、1週間は判定結果だけを記録します。

確認する項目は次のとおりです。

• 正常記事を止めていないか
• 確認文や短すぎる記事を検出できたか
• 画像リンクの差分を正しく検出できたか
• 人間が判定を覆した理由は何か
• どのゲートで失敗が集中したか

誤停止条件を調整したあと、重大条件から段階的に本番へ適用します。

まとめ：人間レビューを原稿修正からルール改善へ変える

Hiroサイトの事例では、処理成功、品質合格、公開成功を別々に判定する必要がありました。

処理成功：CLIが正常終了した
品質合格：記事構造、根拠、重大条件が基準を満たした
公開成功：正しい本文、画像、CTAを公開URLで確認できた

この3つを分離すれば、「実行ログは成功しているのに記事が壊れている」という事故を検知できます。

実装の順番は次のとおりです。

1. 正常な記事構造を定義する
2. 重大な公開停止条件を決める
3. 入力と出力の対応を確認する
4. 事実、数字、引用を個別に検査する
5. 通過原稿だけSEOと読みやすさを採点する
6. 失敗原稿を隔離して例外だけ通知する
7. 人間の判断を回帰テストとルールへ戻す

AI生成記事の人間レビューは、全文を読み続ける作業から始める必要はありません。

まず、過去に起きた重大事故を1つ選び、その事故を止める条件と回帰テストを作ってください。その小さなゲートが、記事生成を単なる大量出力から、失敗するたびに改善できる自動化資産へ変える最初の一歩になります。