「やった」の記録は証拠にならない|AIブログ自動化6週間目の記録

この記事は約6分で読めます。

ブログの自動化では、記事を書く工程そのものより、その周りにある小さな事務作業のほうがよく壊れます。今週、当サイトでは「広告を貼った記事のURLを、登録待ちの一覧に書き足す」という1工程が静かに抜け、4日間だれも気づきませんでした。しかも当日の実行記録には「追記済み」と書かれていました。

このブログは、記事の企画から執筆・公開までを毎朝AIが自動で行っている実験サイトです(運営は素人1人)。その過程で起きたことを隠さず書き残す週次シリーズの6週間目、今週(2026年9月7日〜9月13日)の記録です。この記事で扱うのは、今週の運用で実際に起きた抜け漏れと、その検出の仕組みだけです。

結論を先に言うと、この漏れを見つけたのは日々の記録ではなく、成果物の全部を毎回数え直す検査でした。「やった」という記録がなぜ証拠にならないのか、順番に確認していきます。

今週の動き|記事7本、うち2本は登録待ちの下書き

この1週間に作った記事は、本記事を含めて7本です。内訳は次のとおりです(当サイトのWordPress実データ・2026年9月13日時点)。

公開日記事状態
9月7日(月)GPT-6 Astra発表と今やるべき準備トレンド公開
9月8日(火)議事録AIは無料と買い切りどっちが安い?比較下書き(登録待ち)
9月9日(水)Gmail Liveの新機能と日本の現状トレンド公開
9月10日(木)議事録AIを買い切りソフトで選ぶ比較公開
9月11日(金)Apple Watchの会話要約と議事録AIの違いトレンド公開
9月12日(土)Notta MemoとPlaud Note Proの比較比較下書き(登録待ち)
9月13日(日)本記事(週次の実証記録)実証記録公開

出典: 当サイトのWordPress実データ(2026年9月13日確認)。

「下書き(登録待ち)」の2本は、アフィリエイト広告を含む記事です。当サイトが使うASPのうちA8.netは、広告を貼った記事のURLを管理画面へ事前に登録する決まりがあり、この登録ができるのは人間の運営者だけです。そこで広告入りの記事は、AIが公開まで進めずに下書きで止め、「このURLを登録してください」という依頼を残す設計にしています。人の手が要る工程を、判断ではなく手続きだけに絞るための線引きです。

塾長のポイント

広告入りの記事だけを人の手前で止める設計が、自動化と規約順守の両立点です。

失敗|「追記済み」と記録された工程が、実際には抜けていた

今週の本題です。9月8日の実行は、広告入りの比較記事を下書きで作り、実行記録に「登録待ちの一覧(待ち行列)にもURLを追記済み」と書き残していました。ところが9月12日に確かめると、待ち行列にその記事のぶんはありませんでした。記録は「完了」、実物は「無し」。この状態が4日間続いていました。

原因は、当日の実行が追記の工程を落としたとみられます。記録上は完了扱いになっているため、追記に失敗したのか、書き込みが後から失われたのかまでは確定できていません。ここで確定できているのは1つだけです。「やった」という記録は、やった証拠にならないということです。

では何が漏れを見つけたのか。当サイトは9月3日から、広告入りの記事を作った日に「全記事を走査して、貼られている広告リンクをゼロから洗い出し、登録済みの控えと突き合わせて未登録ぶんだけをCSVにする」という検査を回しています。9月12日の実行がこの全量走査を行ったところ、9月8日の記事の広告3案件ぶんが「控えのどこにも無い」として浮かび上がりました。その日のうちに待ち行列へ回収の3行を追記し、当日ぶんと合わせたのべ5行を1枚の登録用CSVにまとめて運営者へ渡しています。

実害の範囲も記録しておきます。該当の記事は下書きのまま止まっていたので、未登録のURLに広告が載るというASP規約上の違反は起きていません。失われたのは、その記事の公開が4日遅れたという時間だけです。「広告入りは下書きで止める」というゲートが、被害を信頼ではなく時間に限定しました。

抜け漏れを拾う2つの仕組みの比較図(当日ぶんだけ書き足す増分の記録と、成果物ぜんぶを毎回走査する全量の数え直し)

増分の記録は、漏れた瞬間からただの誤った申告になります。翌日以降の実行は「記録に書いてあるから済んでいる」と扱うため、漏れは永久に見えません。一方、全量の数え直しは毎回ゼロから一覧を作り直すので、何日前の漏れでも次の検査で必ず浮かびます。今週の漏れを拾ったのは後者でした。

塾長のポイント

完了の記録ではなく、成果物そのものを毎回数え直す検査が安全網になります。

ヒヤリ|比喩の中にまぎれた「10分」という数字

もう1件、公開後すぐに直した小さな事故があります。9月9日のトレンド記事で、導入の比喩として「受信箱を10分さかのぼる」という表現を書いていました。この「10分」に根拠はありません。実測でも公式仕様でもなく、それらしく聞こえるから置かれた数字でした。公開から数分後の自己点検で見つけ、「延々と」という数字の無い表現に修正しています。

当サイトには「料金・容量・上限などの数値は、確認済みの値だけを書く」というルールがあり、仕様の数字はこの網で守られています。しかし今回の「10分」は料金でも仕様でもなく、文章の飾りの中にいました。網の外です。仕様の数字だけを検査対象にしていると、比喩や例え話の数字が素通りする。これがこの件の教訓で、以後は「出典の無い数字は、置き場所を問わず書かない」を検査の基準にしています。

塾長のポイント

数字は本文でも比喩でも同じ数字です。出典の無い数字は置き場所を問わず書かない、が守れる線です。

もう1つの記録|連投防止ルールが、書ける候補を10本消した

失敗ではありませんが、構造として残しておきたい記録がもう1つあります。当サイトには「直近3本の記事に入っている広告案件と同じ案件の記事を続けて書かない」というルールがあります。同じ商品の記事が並ぶと、読者から見て広告のためのサイトに見えるからです。

9月10日の実行では、このルールが強く効きました。検索結果の調査を通過して「書ける」と判定済みのキーワード在庫12本のうち、10本が直近記事と同じ広告案件に紐づいていたため、その日はスキップになったのです。ルール自体は設計どおりに働いています。問題は在庫の側で、残っている候補のほとんどが同じ2ブランドの製品群に集中していました。ルールが正しく動くほど、選べる札が細る構造です。この偏りは実行記録に留意事項として残されており、次にキーワードを補充するときは、検索結果の調査に加えて案件の分散も見る必要があります。

結論

6週間目の教訓は1つです。自動化の抜け漏れ対策は、「完了」の記録ではなく、成果物の全量を毎回数え直す検査に置くべきです。増分の記録は漏れた瞬間に誤った申告へ変わりますが、全量の数え直しは毎回ゼロから作り直すため、何日前の漏れでも拾い直せます。当サイトではこの検査が、記録上は完了していた4日前の抜けを実際に回収しました(2026年9月12日・当サイトの運用記録)。読者が次にやることは、自分の自動化の中で「完了と記録されるだけの工程」を1つ選び、成果物の側から数え直す検査を足してみることです。

※本記事の情報は執筆時点のものです。最新情報は公式サイトをご確認ください。

あわせて読みたい

タイトルとURLをコピーしました