AIで記事を量産して"落とさない"ための品質ゲート｜2段構えの中身を全部公開
当サイトはアフィリエイトプログラムを利用しており、紹介リンク経由での申込により報酬を得る場合があります。記事内で紹介するサービスには筆者が実際に使用しているものと、客観情報として比較掲載しているもの（未使用・PR表記あり）が含まれます。
AIに記事を書かせるところまでは、いまや誰でもできます。難しいのはその次です。
書かせたものを、人が読まずに公開してよいか。
このサイトは記事の生成から公開までを自動化していて、現在107本が公開されています（実測・2026年8月22日時点／稼働69日）。運用してみて分かったのは、AIは平気で「公開してはいけないもの」を書くということでした。断定できない効果を断定したり、実測していない数値を実測のように書いたり、「ここに画像を入れる」という指示文をそのまま残したり。
そこで入れているのが2段構えの品質ゲートです。この記事では、その設定の中身をそのまま公開します。
結論
品質ゲートは機械チェック（速い・安い・確実）とLLM審査（意味が分かる）の2段に分ける。1段目で形式の欠陥を弾き、2段目で法令と中身を見る。そして判定できなかったときは公開しない（安全側に倒す）。この3点だけで、事故はほぼ止まります。
なぜ1段では足りないのか#
チェック方法には得意・不得意があります。
| 方法 | 得意 | 不得意 |
|---|---|---|
| 機械チェック（文字列・正規表現） | 文字数、必須項目、禁止ワード。速くて無料 | 「なんとなく薄い」「事実が怪しい」は判定できない |
| LLM審査 | 法令違反、内容の薄さ、事実の妥当性 | 実行コストがかかる。判定がブレることがある |
だから順番が大事です。機械チェックで落とせるものを先に落とし、通ったものだけLLMに見せる。逆にすると、frontmatterが壊れているだけの記事にLLM審査のコストを払うことになります。
1段目：機械チェック（実際の設定）#
こちらは一瞬で終わります。実際に使っている設定です。
| チェック項目 | 基準 |
|---|---|
| 必須項目の存在 | タイトル・URL用のスラッグ・説明文の3つが揃っているか |
| 本文の長さ | 空白を除いて 1,800字以上 |
| 具体例の有無 | 「例えば」「実際に」「具体的に」といった語が本文にあるか |
| 禁止表現 | 「必ず稼げる」「誰でも確実に」「絶対に儲かる」「100%」「完全放置で月収」 |
ポイントは「具体例の語があるか」を機械的に見ていることです。乱暴な判定に見えますが、これが意外と効きます。一般論だけで水増しした記事には、この手の語がほとんど出てきません。中身の薄さは、語彙にわりと素直に出ます。
禁止表現のリストは、景品表示法の観点で危ない断定を並べたものです。5語しかありませんが、AIが書く「やりすぎた文章」はだいたいこのどれかを踏みます。
2段目：LLM審査（落とす7観点）#
機械チェックを通った記事だけ、LLMに「このまま自動公開してよいか」を判定させます。審査の観点は7つです。
| # | 観点 | 落とす例 |
|---|---|---|
| 1 | 景品表示法 | 根拠のない最上級・No.1、効果や収益の断定保証 |
| 2 | 薬機法 | 健康・身体・効能に関する不適切な断定 |
| 3 | ステマ規制 | 広告・PR性の不開示、デメリットが完全に欠落した推奨 |
| 4 | 事実妥当性 | ありえない数値、捏造された実体験、存在しない機能の断定 |
| 5 | 薄さ・価値不足 | 検索意図に答えていない、運営者固有の具体（手順・つまずき）が無い |
| 6 | E-E-A-T毀損 | 実測していない数値を実測のように断定している |
| 7 | 体裁 | 日本語の破綻、未完の文、指示文やプレースホルダの残骸 |
判定ルールは3つだけです。
- 重大な問題が1つでもあれば公開を止める
- 軽微な指摘だけなら公開する（ただし記録は残す）
- 迷ったら止める
4と6は、AIに書かせる以上どうしても出ます。とくに6の「実測していない数値を実測のように書く」は、放っておくと必ず起きます。読者にとっていちばん有害な種類の嘘なので、ここは厳しめに設定しています。
3つめのルール：「審査に失敗したときも止める」#
これがいちばん地味で、いちばん効いています。
LLM審査そのものが失敗することがあります。応答が返らない、JSONとして解釈できない形式で返ってくる、タイムアウトする。このとき「判定できなかった＝問題なし」として公開してしまう実装にすると、事故は必ず起きます。
そこで、次の3つのケースを全部「公開しない」に倒しています。
- 審査の実行自体が失敗した
- 返ってきた判定を解釈できなかった
- 判定は「公開可」だが、重大な指摘が同時に含まれている（＝矛盾している）
3つめは実際に起きるパターンです。LLMが「公開してよい」と答えながら、指摘欄には重大な問題を書いている。判定文よりも指摘の中身を信じる設計にしておくと、この矛盾で通り抜けられなくなります。
自動化の一般則として、曖昧な状態は必ず安全側に倒す。止まった記事は翌日また作ればいいだけですが、公開してしまった記事は取り返せません。
失敗談：読者に見えない欠陥で公開を止めていた#
ゲートを厳しくすると、今度は別の問題が起きます。止まりすぎるのです。
このサイトでは、記事の生成時に「あとで実際のスクリーンショットを差し込む箇所」を示すコメントをAIに残させていました。ところが誰も差し込まないまま溜まり、最終的に43記事・50箇所まで積み上がりました（実測）。
そしてこれが、2段目のゲートで毎回「プレースホルダの残骸」として重大判定を受け、公開を止め続けていました。
冷静に確認したところ、この印はHTMLのコメントとして書かれていたため、そもそも公開ページには一切出力されていませんでした。つまり読者への実害はゼロ。にもかかわらず、記事の公開だけが止まっていた。
対処はこうしました。
- 印は機械的に除去する（ビルド前に自動で消す）
- 消すだけだと「撮りたかった箇所」が失われるので、別の台帳に退避して記録を残す
- 撮影は後から台帳を見て、まとめてやる
読者に見えない欠陥で公開を止めるのは損、という判断です。ゲートは厳しくするだけでは機能しません。「何を落とし、何を通すか」を実害ベースで見直す作業が要ります。
運用してみて分かった3つのこと#
| 学び | 中身 |
|---|---|
| 形式の欠陥は機械に、意味の欠陥はLLMに | 混ぜると遅くて高い割に精度が上がらない |
| 落ちた理由を必ず残す | 何で落ちたか記録が無いと、同じ理由で毎日落ち続ける |
| ゲートも定期的に見直す | 一度作った基準は必ず現実とズレる。止まりすぎも異常のサイン |
とくに2つめです。ゲートは「止める」だけでは片手落ちで、なぜ止まったかを通知するところまで作って初めて回り始めます。理由が分からないまま毎朝ゼロ本、という状態がいちばん危ない。
自動化を毎日動かし続ける環境そのものについては常時稼働環境の作り方に、記事の自動投稿の仕組みはPythonで自動投稿を組む実録にまとめています。
まとめ#
- 品質ゲートは機械チェック→LLM審査の2段に分ける（順番が逆だと高くつく）
- 機械側は必須項目・文字数・具体例の語・禁止表現の4つで十分
- LLM側は景表法・薬機法・ステマ・事実・薄さ・E-E-A-T・体裁の7観点
- 判定できなかったときは公開しない。曖昧は必ず安全側へ
- ただし読者に見えない欠陥で止めない。止まりすぎもゲートの故障
AIに記事を書かせるより、書かせたものを止める仕組みのほうが価値があります。公開ボタンを自動化するなら、先にこちらを作ってください。