本数より先に「出さない条件」を決めた
AI に記事を書かせて自動で公開する仕組みは、作るだけなら難しくありません。難しいのは、出すべきでない記事を止めることです。
私たちの自社サイトは 2026-06-20 に、広告の審査で「価値の低いコンテンツ」として不承認になりました。それとは別に、過去には別の媒体で収益を永久に止められたこともあります。理由は、生成した記事を大量に投稿したことでした。
この経緯があるので、今回の仕組みでは本数を最大にすることを目標にしませんでした。目標は「関門を通った記事だけが、毎日決まった本数ずつ、止まらずに出続ける」ことです。同じ考えで、関門を通していない既存の記事 646 本は公開から外し、下書きに戻しました。削除はしておらず、控えも残しています。
公開前に置いた8つの関門
関門は1つでも落ちたら、その記事は出しません。
| # | 見るもの | 落ち方の例 |
|---|---|---|
| 1 | 分量（日本語は字数・英語は語数。コード囲みは数えない） | 短い下書き |
| 2 | 独自性（一次情報・実測・比較表・検証のどれか）＋外部の出典は実際に取得できたものだけ | 出典が取れない＝「取れなかった」と書いて止める |
| 3 | 架空の数字・利用者・使った人の感想や評価が無い | 元の記録に無い数字（小さい数と西暦だけ免除） |
| 4 | 既存の記事と題名・題材が重ならない（自社の他サイトも含む） | 言い換えだけの記事 |
| 5 | 辛口レビューで食い違いが出ない | 書いた側とは別のレビュー役に見せる |
| 6 | 身元に関わる語と社内の置き場所 | 社内のファイルの置き場所がコード引用に混ざる |
| 7 | 広告の表記と必須ページへの導線 | 出来上がりのページのバイトで見る |
| 8 | 公開後の実測（200・正規URL・サイトマップ掲載・本文の語が実バイトにある） | 出したのに表に出ていない |
関門 7 と 8 は、原稿ではなく出来上がったページの実バイトを見ます。原稿の段階では正しくても、組み上がったページで抜けることがあるからです。関門 8 は公開した後の確認で、「出した」と「表に出ている」を別のこととして扱っています。
設計で効いた3つの判断
1. 書く工程と出す工程を分ける。 先に数本書いて未来の日付で予約しておき、1日1本ずつ出します。書く工程が1日失敗しても、予約済みの記事があるので公開は途切れません。
2. 落ちた理由を書き手に返して直させる（上限2回）。 関門で落ちた下書きを捨てるだけにすると、予約が埋まらず、結局公開が途切れます。それでは止める機能はあっても、仕組みとしては未完成です。
3. 終了コードを3つに分ける。
0=やった / 1=違反・やれなかった / 2=確認できなかった
「確認できなかった」を 1 に混ぜると、存在しない事故を探しに行くことになります。0 に混ぜると、見ていないものを「問題なし」として通してしまいます。どちらに丸めても判断を誤るので、別の値にしました。
わざと落として、止まることを確かめた
関門は「置いた」だけでは効いている証拠になりません。そこで試験を 28 件用意し、通る側だけでなく、各関門にわざと落とす負のテストを付けました。
公開前の仕上げとして、関門を全部通った記事に、元の記録に無い数字を1つだけ混ぜて流しました。結果は、関門3が元の記録に無い数字を2個（47391, 8241）挙げて止め、記事は置かれず、終了コード 1 で死活の一覧に出ました。他の関門は通ったので、狙った1つの関門だけで落ちることも確かめられました。
そのうえで本番に1本公開し、関門8の5項目がすべて通ることを実測しました。
自分たちで作った関門の誤検知も、実測で見つかりました。「試験が 5/5 通った」という件数を、星の評価だと読んで落としていたのです。原因は [1-5]/5 という形をそのまま当てていたことでした。評価だと分かる語と一緒のときだけ落とすように直しました。評価に使う記号（二重丸・丸・三角・ばつ印）も、1種類だけなら掛け算の記号に当たってしまうので、2種類以上そろったときだけ落とす形にしています。止める側の仕組みも、誤って止めていないかを同じように確かめる必要があります。
期限つきで本数を増やすときは、戻す条件を機械に数えさせる
審査に向けて本数を増やすときも、関門は一切緩めません。増やすのは「1日に出す本数」だけです。
戻す条件（例: 関門を通った記事が20本公開されたら元に戻す）は、人の記憶に頼らず、仕組みが数えて自動で判定するようにしました。毎回の実行で「N/20本」をログと日次の1行に出しているので、今どこまで来ているかが毎日見えます。
業務に置き換えると
自社の業務に自動化を入れるときに、点検できる項目を挙げます。
- 「AIで記事を自動投稿する」を入れるなら、本数の前に出さない条件を決めたか。その条件が本当に効くことを、わざと落とす試験で確かめたか。
- 自動化の良し悪しを「何本出たか」ではなく、「出すべきでないものを止められたか」で見ているか。
- 書く工程と出す工程が分かれていて、どちらかが止まった日でももう片方は続く作りになっているか。
- 「確認できなかった」を「問題なし」や「失敗」に丸めず、別の結果として扱っているか。
- 期限つきの例外（今だけ本数を増やす）について、戻す条件を機械が数えているか。人は戻し忘れます。
この記事は、TechAthletes が自社のサービスを作る中で記録した実測をもとに書いています。業務への導入のご相談は 仕事の窓口 で受け付けています。