AIが記事を書き、別のAIがレビューし、プログラムが「合格」と判定した。それでも、公開対象としてGitHubへpushされたのは記事ではなく、「本文を送ってください」という確認メッセージだった——。
これは仮定ではありません。Hiroが運営する auto-ai-blog で、2026年7月17日に実際に起きた処理事故です。
当日の処理は正常終了し、記事は保存され、Notionにも記録され、GitHubへのpushまで成功していました。さらに、誤った原稿を品質検査へ通すと、合格ラインと同じ8点を獲得しました。
この事故が示すのは、AI生成記事の安全性を「文章の採点」だけでは守れないという事実です。
必要なのは、次の3つを分離した公開設計です。
- 1件でも該当したら公開を止める重大条件
- SEO・読みやすさ・独自性を評価する品質スコア
- 機械では判断できない例外だけを確認する人間レビュー
この記事では、実行ログと現行コードの再検証結果をもとに、AI生成記事の誤公開を防ぐ7段階の品質ゲートを解説します。初心者でも、まずは下書き運用から始められる手順にしています。
AI生成記事はSEOで不利になるのか
AIを使っただけで、記事が一律に検索結果から排除されるわけではありません。
Googleは、コンテンツの作成方法よりも、正確性、品質、関連性、独自の付加価値を重視すると説明しています。一方で、検索順位の操作を目的として、読者への価値を追加せずに大量のページを生成する行為は、スパムポリシーに抵触する可能性があります。
したがって、問題は「AI生成か、人間執筆か」ではありません。
- 読者の疑問に答えているか
- 主張に根拠があるか
- 他の記事にはない経験や検証結果があるか
- 誤情報や危険な断定が含まれていないか
- 大量生成そのものが目的になっていないか
この5点が重要です。
参考：Google 検索の生成 AI コンテンツに関するガイダンス、Google 検索のスパムに関するポリシー
Hiroのサイトで起きたAI記事の誤公開事故
auto-ai-blog は、Windows上のPythonからAI CLIを呼び出し、記事生成、レビュー、Markdown保存、Notionへの記録、Git操作までを自動化しています。GitHubへpushされた変更は、別途Cloudflare Pagesのデプロイ対象になります。
2026年7月17日の実行ログには、次の記録が残っていました。
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へのフォールバックは成功しています。ログだけを見れば、生成からGitHubへのpushまで完了した正常な実行に見えます。
しかし、保存されたMarkdownのタイトルは次の内容でした。
最終チェックには記事本文が必要です
本文も完成記事ではありませんでした。
ご提示いただいた内容はブログ記事ではなく、出力先を確認するためのメッセージです。
次のいずれかを送ってください。
1. レビュー対象となる記事の全文
2. リポジトリ内にある対象記事のファイルパス
つまり、AI CLIの終了コードは成功でも、成果物は失敗していました。
なお、上記のログから確認できるのはGitHubへのpushまでです。この7行だけでは、Cloudflare Pagesのビルド成功や、公開URLでの表示までは証明できません。デプロイ完了は、別のビルドログやHTTPアクセスによって判定する必要があります。
この区別は重要です。
生成処理の成功
≠
成果物の成功
≠
デプロイの成功
≠
公開ページの表示成功
誤原稿が8点で合格した理由
generator/ai_slop_guidelines.json には、10項目の品質基準と次の合格ラインがあります。
minimum_score: 8
現行の generator/slop_guard.py は、本文に特定の語が含まれているかを中心に各項目を判定し、合計点が8点以上なら合格とします。
誤原稿を2026年7月22日に再評価した結果は、次のとおりでした。
score: 8
minimum_score: 8
passed: true
確認メッセージに「Hiro」「検証結果」「画像」「注意点」「限界」「差別化」などの語が含まれていたため、記事として成立していなくても複数の項目に一致したのです。
これは、品質基準そのものよりも判定方法の問題です。
「画像」という語がある
≠
画像Markdownが存在する
「検証結果」という語がある
≠
実測結果が提示されている
「Hiro」と書かれている
≠
Hiro固有の一次情報がある
同日、関連テストも再実行しました。
python -m pytest tests/test_slop_guard.py tests/test_generate.py -q
....... [100%]
7件のテストはすべて通過しています。ただし、この結果が保証するのは、既存テストに記述された動作だけです。現行テストには、今回の誤原稿を不合格にする回帰テストが含まれていません。
したがって、「テスト成功」と「誤公開対策済み」は分けて報告しなければなりません。
AI生成記事に潜む5つのリスク
1. 誤情報・架空の出典
AIは、存在しない統計、URL、製品仕様を自然な文章で生成することがあります。
料金、制度、法律、医療、税務、金融、製品仕様など、更新されやすい情報には次の項目をひも付けます。
- 出典URL
- ページタイトル
- 確認日
- 根拠となる該当箇所
- 自社計測の場合は計測条件と件数
「レビュー時間を80％削減した」と書くなら、比較前後の時間、対象記事数、計測期間が必要です。根拠がなければ削除するか、「削減できる可能性がある」と未検証であることを明示します。
2. 個人情報・認証情報の混入
入力に顧客名、メールアドレス、電話番号、APIキー、社内パスが含まれていると、そのまま記事へ混入する可能性があります。
少なくとも、次の形式は公開前に自動検査します。
- メールアドレス
- 電話番号
- APIキーやアクセストークン
- 秘密鍵
- ローカル環境の絶対パス
- 顧客番号や契約番号
検出時は自動修正せず、原稿を隔離してください。誤ったマスキングによって、別の機密情報が残る可能性があるためです。
3. 検索意図からの逸脱
「AI生成記事 リスク」で検索する読者が求めているのは、AIの歴史ではなく、誤情報、著作権、品質低下などをどう防ぐかという具体策です。
次の4カ所が、同じ検索意図に答えているか確認します。
- H1
- 導入文
- H2
- 結論とCTA
キーワードの出現回数だけを増やしても、検索意図への回答にはなりません。
4. 画像・CTA・リンクの欠落
レビューAIが文章を整える過程で、元記事の画像リンクやCTAを削除することがあります。
公開前には本文の意味だけでなく、次の件数差分を確認します。
入力画像数 == 出力画像数
入力必須リンク数 == 出力必須リンク数
指定CTA URL == 出力CTA URL
URLは存在するだけでなく、HTTP応答、リダイレクト先、リンク先の内容との関連性も確認します。
5. 処理成功と成果物成功の混同
AI CLIが終了コード0を返しても、次のような出力なら記事生成は失敗です。
- 質問や確認要求だけが書かれている
- 自己評価しかない
- 元のプロンプトが残っている
- タイトルと本文が一致しない
- 本文が極端に短い
- MarkdownではなくJSONエラーが保存されている
工程の成功ではなく、「完成記事として満たすべき成果物の契約」を検証する必要があります。
AI生成記事を安全に公開する7段階ゲート
ステップ1. 入力条件を固定する
最初に、AIへ渡す情報を構造化します。
原稿ID
トピック
想定読者
主要キーワード
補助キーワード
記事の目的
必要なH2
文字数の目安
保持必須の画像URL
保持必須のCTA URL
参照できる一次情報
入力が不足している場合は、AIを呼び出す前に停止します。
「不足情報を推測して書かせる」のではなく、「入力不足として終了する」ことが事故防止の第一歩です。
ステップ2. 完成記事の構造を検査する
記事として最低限必要な構造を、採点項目ではなく必須条件にします。
H1またはタイトルが1件ある
本文が最低文字数以上ある
H2が1件以上ある
導入と結論がある
指定画像が保持されている
指定CTAが保持されている
タイトルと本文の主要語が一致する
文字数は、全記事で一律に決める必要はありません。auto-ai-blog の現行設定は5,000〜7,000字ですが、検索意図へ十分に答えられる長さをカテゴリ別に検証する方が安全です。
最低文字数だけでなく、見出し数、本文段落数、コードや引用を除いた実質文字数も確認すると、長いエラーメッセージやプロンプトを記事と誤認しにくくなります。
ステップ3. 重大な公開停止条件を検査する
次の条件に該当した場合は、品質スコアに関係なく公開を止めます。
- 「本文を送ってください」などの確認要求
- システムプロンプトやレビュー指示の混入
- APIキー、秘密鍵、個人情報
- 出典のない効果保証や収益保証
- 医療・法律・投資に関する無条件の断定
- 必須画像またはCTAの欠落
- 本文ではなく自己評価のみの出力
- JSON解析、レビュー、保存の失敗
単語1個だけで止めると誤検出が増えるため、複合条件を使います。
本文が最低文字数未満
AND H2が0件
AND 確認要求を含む
AND 文末が質問または提出依頼
重大条件は critical_failures として、品質点とは別に保存します。
publishable = (
artifact_contract_passed
and not critical_failures
and fact_check_passed
and required_assets_preserved
and quality_score >= minimum_score
)
重要なのは、quality_score が高くても、critical_failures が1件あれば公開不可にすることです。
ステップ4. 事実・数字・引用を検査する
本文から次の要素を抽出します。
- 数字
- 日付
- 金額
- パーセント
- 固有名詞
- 引用文
- 外部URL
各主張を、次の状態に分類します。
verified：公式情報または実測ログで確認済み
qualified：条件や前提を併記
unverified：根拠を確認できない
unverified が残った原稿は自動公開しません。
AIに事実確認を依頼するだけでは不十分です。同じ誤情報を別のAIが承認する可能性があるため、公式情報、原文、自社ログとの照合を優先します。
実測値を掲載する場合は、少なくとも次の情報を一緒に保存します。
計測日
対象バージョン
実行環境
入力条件
対象件数
計測方法
生ログまたは保存先
既知の除外条件
これにより、後から数字だけが独り歩きするのを防げます。
ステップ5. SEO・読みやすさ・独自性を採点する
重大条件を通過した原稿だけを、品質採点へ進めます。
□ H1に主要キーワードが自然に含まれる
□ 導入で悩みと読後成果が分かる
□ H2が検索意図ごとに整理されている
□ 1段落が長すぎない
□ 手順に実行順序と確認方法がある
□ 数字に根拠がある
□ Hiro固有のログまたは検証結果がある
□ 反論、限界、失敗対策がある
□ 読後アクションがある
□ 類似記事との差別化が説明されている
ここで重要なのは、キーワードの有無だけで合否を決めないことです。
「検証」という単語があるかではなく、日付、条件、手順、結果がそろっているかを確認します。
独自性も、固有名詞の出現だけでは判断できません。次のいずれかが具体的に示されているかを確認します。
- 自社の実行ログ
- 実際に失敗した入力と出力
- 再現手順
- 修正前後の比較
- 他の環境では当てはまらない条件
- 検証できていない範囲
ステップ6. 不合格原稿を隔離して通知する
不合格原稿は削除せず、公開ディレクトリとは別の隔離領域へ保存します。
通知には、全文ではなく判断材料を載せます。
{
"article_id": "2026-07-17-topic-22",
"decision": "quarantine",
"failed_gate": "artifact_contract",
"critical_failures": [
"本文が最低文字数未満",
"H2が存在しない",
"確認要求を検出"
],
"detected_text": "レビュー対象となる記事の全文を送ってください",
"recommended_action": "入力とレビュー工程を確認して再生成",
"retry_count": 0
}
レビューAIが失敗した場合に、元原稿をそのまま公開する運用も危険です。レビュー不能、タイムアウト、解析失敗は、原則として安全側へ停止する「フェイルクローズ」にします。
ただし、低リスクな下書き保存まで止める必要はありません。「下書き保存は許可、一般公開は禁止」のように権限を分けます。
隔離時には、次の情報を同じ原稿IDでひも付けて保存すると調査しやすくなります。
入力プロンプト
生成直後の原稿
レビュー後の原稿
最終出力
使用したAIとモデル
終了コード
標準出力・標準エラー
各ゲートの判定結果
実行日時
ステップ7. 人間の判断を回帰テストへ戻す
人間が公開不可と判断したら、文章を直して終わりにしません。
- 問題の入力、出力、実行ログを保存する
- 公開できない理由を1文で記録する
- 機械判定できる条件へ変換する
- 失敗原稿を使った回帰テストを追加する
- 修正前にテストが失敗することを確認する
- 検出処理を修正する
- 修正後に失敗原稿が止まることを確認する
- 正常記事が誤停止しないことも確認する
- 一定期間は下書き運用で誤判定率を測る
今回の誤原稿なら、少なくとも次のテストが必要です。
「本文を送ってください」と要求する短文は、
品質キーワードを8項目含んでいても公開不可になる
正常系のテストも対にします。
確認要求という語を事例説明として含む完成記事は、
構造と必須条件を満たしていれば、その語だけでは公開不可にしない
これによって、人間レビューは毎回の全文校正ではなく、再発防止ルールを増やす作業へ変わります。
公開判定を1つの式にする
公開条件は、担当者ごとの感覚ではなく、機械で再現できる形にします。
公開可能 =
入力契約が有効
AND 記事構造が合格
AND 重大リスクが0件
AND 重要な事実が確認済み
AND 必須画像・CTAが保持
AND 品質スコアが基準以上
AND デプロイ後確認が成功
品質点が10点でも、APIキーが1件含まれていれば公開不可です。
逆に、重大リスクがなくても、根拠のない一般論しかない記事を自動公開する必要はありません。重大リスクと品質不足は、別の理由として記録します。
判定結果は、単純な passed: true だけではなく、少なくとも次の3種類に分けます。
publish：公開条件をすべて満たした
quarantine：重大条件または成果物契約に違反した
human_review：機械だけでは判断できない項目が残った
この3分類にすると、「不合格だから削除」「合格だから即公開」という極端な運用を避けられます。
初心者が導入するときの安全な順序
最初から完全自動公開を目指すと、誤判定の傾向が分かりません。次の3段階で移行します。
第1段階：下書き保存のみ
すべての記事を下書きへ保存し、人間が確認します。
この期間に記録するのは、公開可否だけではありません。
- どのゲートで止まったか
- 人間が判定を覆したか
- 確認に何分かかったか
- 同じ失敗が再発したか
最初の目標は、自動公開率を上げることではなく、失敗理由を分類できる状態にすることです。
第2段階：低リスク記事だけ自動公開
操作手順や自社ツールの使い方など、根拠を確認しやすいカテゴリから自動公開します。
医療、法律、税務、投資判断などは、人間レビューを残します。
カテゴリだけでなく、次の条件でも人間レビューへ切り替えます。
- 初めて扱うテーマ
- 外部の数字や引用が多い
- 料金や制度に関する記述がある
- ブランドや個人への評価を含む
- 未検証の主張が残っている
第3段階：公開後の監視まで自動化
公開直後に次を確認します。
- 公開URLが200を返す
- タイトルと本文が表示される
- 画像が取得できる
- CTAが指定URLを指している
noindexが意図せず付いていない- サイトマップへ反映されている
Git pushの成功を、公開成功の代わりにしてはいけません。
HTTPステータスが200でも、エラーページが200を返す構成があります。ステータスコードだけでなく、タイトル、H1、本文の一部、CTA URLなど、記事固有の値も照合してください。
よくある失敗と対策
AIを2回使えば安全だと考える
同じ入力を使うAI同士は、同じ誤りを引き継ぐ可能性があります。
文章改善はAIへ任せても、事実確認は公式情報や実測ログと照合します。
AIによるレビューは、独立した証拠ではありません。別モデルを使っても、参照する根拠が同じでなければ「意見を2回得た」だけになる場合があります。
人間が毎回全文を読む
全文確認を続けると、記事数に比例して作業時間が増えます。
構造、リンク、数字、禁止情報は機械で検出し、人間には該当箇所、前後の文章、根拠URL、変更差分だけを表示します。
ただし、機械判定の精度が測れていない初期段階では、全文確認を省略しません。十分な下書き運用を経てから、差分確認へ移行します。
不合格原稿を削除する
失敗原稿を削除すると、同じ事故を再現できません。
入力、出力、使用CLI、検出結果、実行時刻をセットで隔離し、回帰テストの教材にします。
隔離領域には認証情報が含まれる可能性があるため、公開リポジトリへそのまま保存してはいけません。アクセス制御、保存期間、マスキング方針も決めておきます。
自動再試行を無制限にする
入力不備による失敗は、再試行しても直らない場合があります。
一時的な通信エラー：最大2回再試行
認証エラー：再試行せず通知
入力不足：再試行せず隔離
品質不足：修正プロンプトで1回だけ再生成
重大リスク：自動修正せず人間確認
失敗理由ごとに再試行方針を分けます。
再試行時には、同じ原稿ID、試行回数、前回の失敗理由を残します。新しい処理として扱うと、無限再試行や重複公開を検出しにくくなります。
記事数だけを追う
生成本数が増えても、誤通過やリンク切れが増えれば資産とは呼べません。
公開本数ではなく、「品質を維持し、読者行動につながっている記事数」を追跡します。
AI記事レビューで追うべきKPI
| KPI | 計算方法 | 初期運用での見方 |
|---|---|---|
| 重大事故の誤通過件数 | 公開後に重大問題が見つかった件数 | 目標は0件 |
| 公開可能率 | 公開可能記事数 ÷ 生成記事数 | 低ければ入力や生成処理を改善 |
| 誤停止率 | 人間が公開可へ覆した件数 ÷ 隔離件数 | 高ければ検出条件が厳しすぎる |
| 人間レビュー率 | 人間確認件数 ÷ 生成記事数 | ルール改善に伴って低下するか確認 |
| 平均レビュー時間 | 総確認時間 ÷ 確認記事数 | 全文確認から差分確認へ移行できたか |
| 同一事故再発率 | 既知パターンの再発件数 ÷ 全不合格件数 | 回帰テストが機能しているか |
| リンク正常率 | 正常リンク数 ÷ 検査リンク数 | CTAや参照先の破損を検出 |
| インデックス率 | インデックス記事数 ÷ 公開記事数 | 低品質、重複、クロール障害を調査 |
| CTAクリック率 | CTAクリック数 ÷ 記事閲覧数 | 検索意図と提案内容の一致を確認 |
| 収益発生記事率 | 収益発生記事数 ÷ 公開記事数 | 収益導線の有効性を確認 |
初期値がない段階で、業界共通の目標値を置く必要はありません。最初の30〜50記事を基準値として記録し、改善前後を同じ条件で比較します。
ただし、個人情報、認証情報、危険な断定など、重大事故の誤通過件数だけは0件を目標にします。
KPIを集計するときは、記事カテゴリ、使用モデル、プロンプトのバージョン、ゲートのバージョンも記録してください。条件が変わったデータを混ぜると、改善効果を正しく比較できません。
この設計にも限界がある
品質ゲートを増やしても、すべての誤りを自動検出できるわけではありません。
特に次の原稿は、完全な無人公開に向きません。
- 医療、法律、税務、投資判断
- 災害や安全に関わる情報
- 新しい制度や頻繁に変わる料金
- 他者の著作物を多く引用する記事
- ブランド毀損につながる批評
- 初めて扱うテーマ
また、ゲートを厳しくしすぎると、正常な記事まで隔離されます。安全性だけでなく、誤停止率とレビュー時間も測りながら調整してください。
ルールベースの検査には、表記揺れや言い換えを見逃す限界があります。一方、AIによる意味判定には、同じ入力でも判定が変わる非決定性があります。そのため、重大条件には決定的な構造検査やパターン検査を使い、曖昧な品質評価にAIを使うなど、役割を分ける必要があります。
自動化によって生成・検査・投稿の作業量は減らせますが、検索流入や収益は保証されません。需要、競合、記事の独自性、商品との適合、サイト評価などの影響を受けます。
今日からできる30分の改善
過去に生成したAI記事を1本選び、次の順番で確認してください。
□ タイトルと本文が存在する
□ H2が1件以上ある
□ 入力トピックと内容が一致する
□ 確認要求やプロンプトが混入していない
□ 数字に出典、ログ、条件、確認日がある
□ 必須画像が保持されている
□ CTAの文言とURLが保持されている
□ 個人情報や認証情報がない
□ 高リスクな断定がない
□ 公開後のURLと表示を確認した
不合格なら、理由を1文で記録します。
公開不可：本文ではなく、入力を求める確認メッセージが保存されている
次に、その理由を機械条件へ変換し、同じ原稿を使った回帰テストを1件追加します。
最初の30分では、完璧な品質管理システムを作る必要はありません。
1. 過去の失敗原稿を1件選ぶ
2. 公開不可の理由を1文にする
3. 検出条件を1件決める
4. 失敗原稿が止まるテストを追加する
5. 正常原稿が通ることも確認する
この1件が、人間レビューを将来の記事にも効く自動化資産へ変える最初の一歩です。
人間レビューを減らしながら、誤公開を止める
AI生成記事のリスクは、誤字や不自然な文章だけではありません。
Hiroの実例では、AI CLI、最終チェック、保存、Notionへの記録、Git pushが成功したにもかかわらず、記事ではない確認文が成果物になりました。しかも、単語中心の品質検査では8点を獲得して合格しました。
同じ事故を防ぐには、次の順番でゲートを設計します。
- 入力条件を固定する
- 記事構造を必須検査する
- 重大な公開停止条件を分離する
- 事実・数字・引用を確認する
- 通過原稿だけSEOと独自性を採点する
- 不合格原稿を隔離して通知する
- 人間の判断を回帰テストへ戻す
完全自動化とは、人間を無条件に外すことではありません。
機械が得意な検査を先に行い、判断が必要な例外だけを人間へ送り、その判断を次回の停止条件へ変えることです。この循環が回れば、人間の時間を毎回の全文校正ではなく、事故の再発防止、独自情報の追加、収益導線の改善へ集中できます。
AI記事の生成・検査・公開を一つの運用にしたい方へ
AI記事を安全に運用するには、生成プロンプトだけでなく、入力管理、品質ゲート、隔離、再試行、デプロイ後確認、KPI計測まで設計する必要があります。
「記事生成はできたが公開が怖い」「毎回の全文確認から抜けられない」「自動化しても成果につながらない」という方に向けて、実装と運用を具体化したマニュアルを用意しています。
自動化は、不労所得や収益を保証するものではありません。それでも、検証結果をルールへ戻し、同じ作業と事故を減らす仕組みは構築できます。