AI運用・自動化

AIに記事を毎日自動で書かせたら、公開前の検査で何回止まったか(実測)

この記事の料金・仕様は時点で各社の公式ページを確認したものです。

下書きの記事が複数の検査を順に通り、落ちると公開前に止まる流れのイラスト

記事自動生成の停止ログを集めて調べると、止まった理由の大半は数字の裏取りでした。公開前の検査が何を見ているかを、自サイトの記録から読み解きます。

結論

AI に記事を任せて、公開前に止める仕組みが気になる人は
書く役と止める役を分けると、間違いが読者に届く前に捕まります。止まった理由を段ごとに残しておけば、あとから原因を追えます。
自分の自動化にも検査を足したい人は
全体の手順をジョブとステップに分けて、順番に並べるところから始めると読みやすくなります。まずは自分のリポジトリの設定フォルダを開いてみてください。

この記事にはPR(広告)の表記があります。公式情報の確認日は2026年10月17日です。

記事自動生成の停止ログを8回分調べると、6回は数字の裏取りで止まっていました。 読み終わると、公開前の検査がどの順番で何を見るのかと、止まった理由の読み方が分かります。

記事生成から出荷までの流れ

記事は、下書きを作り、二種類の検査を通り、最後の出荷前検査を通って初めて公開に進みます。どこか一つで落ちれば、その回は公開されません。

図で見てほしいのは、落ちたときの行き先が、どの段でも「停止を記録」になる点です。

記事が公開に進むまで

  1. 1. 記事の下書きができた?
    はい → 裏取りと読みやすさの検査へいいえ → 記録なし
  2. 2. 裏取りと読みやすさの検査を通った?
    はい → 出荷前の検査へいいえ → 停止を記録して、その回は公開しない
  3. 3. 出荷前の検査を通った?
    はい → 公開へいいえ → 停止を記録して、その回は公開しない
出典: 各社の公式ページ(2026年10月17日確認)

各検査が見ているものを、表にまとめます。

検査見ているもの
裏取りの検査(check_claims)書いた数字が公式ページの本文にあるか。単位が合っているか
読みやすさの検査(check_reading)段落や文の長さ、英語の残り、図と本文の対応
出荷前の検査(deploy_gate)公開直前に、サイト全体の決まりをまとめて確かめる

ワークフローは一枚岩の大きな処理だと思われがちですが、実際は層になっています。公式の説明では、ワークフローがジョブを動かし、ジョブはステップの集まりです。

四枚のカードで、全体、きっかけ、作業のまとまり、一手順の順に並べました。

出てきた言葉の早見表

ワークフロー

自動化の手順書にあたる、全体の流れです。中でジョブを動かします。

イベント

ワークフローを動かすきっかけです。時刻の指定や、手で起動する形もあります。

ジョブ

同じ場所で動く作業のまとまりです。ほかに依存しなければ、並べて同時に走ります。

ステップ

ジョブの中の一手順です。上から順番に実行され、手順どうしでデータを渡せます。

出典: 各社の公式ページ(2026年10月17日確認)

自分で試せる一手があります。自分のリポジトリの .github/workflows フォルダを開いて、YAML(設定を人が読める形で書く書式)のファイルがあるか見てみてください。あれば、その中でジョブとステップを探せます。

つまり、自動化を作る人は、全体をジョブとステップに分けておくと、どの段で止まったかをあとから追いやすくなります。

出典: GitHub 公式ドキュメント(2026年10月17日確認)

停止回数と理由

2026年9月17日から10月8日に保存された停止ログは8回です。裏取りで6回、読みやすさで1回、出荷前検査で1回止まりました。

この8回のうち、そのまま公開に進んだ回は0回です。

ここが落とし穴です。8回とも停止ログなので、「8回中8回止まった」と書いても、止まる割合にはなりません。止まらなかった回の数は、このデータにありません。

10月8日時点の公開履歴では、公開済みの記事は3本でした。この3本は、上の8回とは別の記録です。

回ごとの理由を、ログの文面から表にしました。

日付と記事止まった理由
9月17日 Grok・DeepSeek・Mistral の比較出荷前の検査。記事の計測欄の形が決まりに合わず、一件の違反で止まった
9月25日 Notta・Otter・Fireflies の比較裏取り。単位を読み取れない数字を含む主張があった
9月29日 同じ題材のやり直し裏取り。ページ本文に見つからない数字が、結論の根拠とタイトルの欄に出ていた
9月30日 DeepL・Google・みらい翻訳の比較裏取り。無料の上限の数字がページ本文に見つからず、タイトル側でも使っていた
10月2日 OpenRouter・Together・Fireworks の比較裏取り。料金の数字がページ本文に見つからず、読みやすさの検査も同じ回に落ちた
10月6日 Open WebUI・AnythingLLM・LibreChat の比較裏取り。データベースの初期設定にあたる数字の単位を読み取れず、読みやすさも一か所落ちた
10月6日 Whisper・Notta・Rimo の比較裏取り。結論の文に、根拠の主張にない数字が入っていた。読みやすさも一か所落ちた
10月8日 Hugging Face・Replicate・fal の比較読みやすさ。長すぎる段落と、英語の月額表記が残った

表のとおり、裏取りで止まった回の中には、読みやすさの検査も一緒に落ちていた回がありました。数えるときは、ログの理由の欄に書かれた一つだけを最終的な停止理由にしています。

つまり、止まった理由の読み方は、「どの段の、どの決まりに合わなかったか」の二つが分かれば足ります。

検査が防ぐ不備

検査が止めたのは、ページに見つからない数字、読みにくい文章、全体の形の違反の三種類です。

一つ目は、公式ページの本文に見つからない数字です。無料の上限や料金が、結論やタイトルの欄にそのまま使われていた回がありました。検査は、その数字を「取得したページ本文に見つからない」と判定しました。

二つ目は、読みにくい文章です。長すぎる段落や、英語のままの月額表記が残ると止まります。10月8日は、書き直しのあとも英語の月額表記が残って止まりました。

三つ目は、全体の形の違反です。9月17日は、記事の計測欄が配列の形になっていないという違反で、出荷前に止まりました。

ここで防いでいるのは、間違いかもしれない数字や読みにくい文が、読者に届くことです。ただし、検査を通っても、内容が正しいという保証にはなりません。検査が見ているのは、決まりに合うかどうかです。

つまり、AI に記事を任せるなら、「書く役」と「止める役」を分けておくと、間違いが読者に届く前に捕まります。

測り方と限界

この数字は、Mac 上の自動公開の作業記録と Git の履歴から、2026年10月8日に集計したものです。GitHub Actions のログではなく、公式ページは言葉の説明にだけ使っています。

集計では、各回の結果ファイルから、止まった段、理由、失敗した検査の出力を読んで数えました。公開数は、公開履歴と Git の公開記録を照らし合わせています。

限界は三つあります。対象は8回の停止ログだけで、現在の停止率や公開率ではありません。

10月2日より前の記録には、読みやすさの検査の出力がありません。検査の種類が回によって違う可能性があるので、回どうしの単純な比較は避けます。

これは自サイトの運用記録の集計です。他社の自動化の傾向を示すものではありません。

覚えておくこと

この記事の要点は、次の三つです。

  • 記事の自動生成は、下書きのあとに検査の段を重ね、落ちた回は公開しません。
  • 8回の停止ログのうち、6回が数字の裏取りで止まりました。
  • 8回すべてが停止ログなので、止まる割合としては読めません。

出典

このサイトで測った元データ

関連記事