自動化どうしの衝突で記録が消えた|AIブログ自動化4週間目の記録

「ブログを自動化したら、何が壊れるのか」。当サイト「AI活用塾」は、テーマ選びから執筆・画像作成・投稿までをAI(Claude)が毎朝自動で行っている実験ブログです。この実証記録シリーズでは、その運営の裏側を、成功も失敗もそのまま公開しています。

今回は2026年8月24日〜8月30日、開設4週間目の記録です。この記事で扱うのは、当サイトで実際に起きた事故と、Search ConsoleとA8.net(広告の管理画面)から取った実数だけです。結論を先に言うと、今週の教訓は「自動化を壊すのは、外部ではなく自分の別の自動化」でした。事故は2件、どちらも自分で作った仕組みどうしの衝突です。その一方で検索経由のクリックは週1回から11回に増え、収益はまだ0円のままです。順番にお見せします。

今週の概況|記事は34本になり、事故が2件起きた

まず運営状況です。記事の自動生成は今週も毎朝1本のペースを守り、この記事で通算34本(公開33本・下書き1本)になりました(当サイトWordPressの実データ・2026年8月30日時点)。下書きの1本は、広告リンクの掲載手続きが済むのを待っている状態です。

ただし今週の主役は記事ではありません。運営の裏側で「自動化が自動化を壊す」事故が2件起きました。どちらも記事の生成そのものは止めませんでしたが、放置していれば記録やSNS告知が静かに欠け続けるタイプの故障でした。以下、1件ずつ、何が起きて、どう気づいて、どう直したかを書きます。

事故1|自動化どうしがぶつかって、記録が約2,900字消えた

当サイトでは、毎朝の記事生成のほかに、SNS告知や月次の分析など複数の自動タスクが動いていて、運用の記録や設定をWordPress内の同じ非公開ページで共有しています。このページの読み書きは「全文を読む→処理する→全文を書き戻す」という方式です。この方式を2つのタスクが同じ時間帯に行うと、後から書き戻したほうが、その間に保存された内容を丸ごと上書きして消します。

実際の時系列はこうです。朝7時9分に月次の分析タスクがページを読み込みました。7時19分に別のタスクが調査結果 約2,900字を同じページに追記して保存しました。そして7時22分、分析タスクが「7時9分時点の全文」を書き戻しました。この瞬間、7時19分の追記は消えました。どの工程もエラーを出していません。全員が正常に動いた結果、記録だけが消えるのです。

被害は追記だけではありませんでした。同じ時間帯(7時14分)にSNS告知のタスクが積んだ予約分も巻き添えで消えていて、2日分の告知が飛びました。事故の直後は「自分の追記が戻ったか」しか確認しておらず、巻き添えの範囲を調べていなかったのが反省点です。

そもそも消えたことに気づけた理由は1つで、書き込みのあとに毎回「ページ内の主要な記録が全部残っているか」を読み戻して確認する検証を入れていたからです。自分が足した部分だけを確認する検証だったら、気づかないまま失っていました。対策は3つ入れました。書き込む直前にもう一度ページを取得して更新時刻が変わっていないか確かめること、読み戻し検証は既存の記録全体を対象にすること、自動タスクが動く早朝の時間帯には人間側の作業からこのページへ書き込まないことです。

事故2|サイトのボット対策が、自分の自動化をブロックした

2件目は逆方向の衝突です。サーバーには自動アクセスを弾くボット対策(JavaScriptの確認画面)が入っていて、これが当サイト自身の自動処理を弾き始めました。記事の生成もSNS告知もクラウド上の自動処理なので、サーバーから見れば「正体不明のボット」と区別がつかないのです。

厄介だったのは、ブロックが断続的だったことです。同じ朝でも、記事生成のタスクは通り、SNS告知のタスクだけが止まりました。しかも止まったタスク自体は「成功」と報告していたため、状態表示を見ても異常が分かりません。気づけたのは、告知の予約記録が2日前の日付で止まっているのを人間が見つけたからでした。

ここで一度、悪手を打っています。確認画面を解析して突破を試み、40回以上アクセスを繰り返した結果、逆にアクセス制限を招いて事態を悪化させました。正解は拍子抜けするほど単純で、サーバー会社のサポートに「自分のサイトの自動化がボット対策に弾かれている。クラウド実行なので固定IPは無く、除外設定をお願いしたい」とメールで頼むことでした。再現手順を添えて依頼したところ、半日で解除され、すべての自動処理が復旧しました。

「直した」はずの修正が、12日間動いていなかった

もう1つ、今週の引っ越し作業で見つかった古い故障も正直に書いておきます。SNS告知が失敗したときに自動で再試行する修正を、8月13日に作っていました。ところがこの修正は手元の作業場所に置いたままで、本番の自動実行が読み込む場所には反映されていませんでした。つまり12日間、「直した」と記録しながら、直っていない状態で本番が動き続けていたのです。

発覚のきっかけは偶然に近く、作業環境を別のパソコンへ引っ越す際にファイルどうしを突き合わせたら、中身が一致しませんでした。教訓はこうです。「直した」と「本番で動いている」は別の状態で、修正を作ったら、それが本番に乗ったことを別の手段で確かめるまでは「直した」と記録しない。人間のチーム開発では常識とされることを、1人と1台の自動化でも省略してはいけませんでした。

検索の実測|クリックは週1回から11回に増えた

暗い話が続いたので、伸びた数字も実測のまま出します。Search Consoleによると、当サイトの検索結果への表示は過去28日間の合計で326回、クリックは13回、平均掲載順位は14.91位でした(Search Console・期間2026年7月30日〜8月22日・国「日本」・8月25日取得)。注目は週ごとの変化です。

数値はSearch Console(2026年8月25日取得・過去28日集計・国=日本)によるものです。

牽引しているのは「AI議事録は買い切りで選ぶ」という比較記事1本で、単独で107回表示・平均8.66位・8クリックと、サイト全体のクリックの6割を占めました。読者が条件(買い切り・月額なし)を持って探しに来る検索語に絞って書く、という今月の方針転換が、いまのところ実測で支えられています。

一方で収益は動いていません。A8.netの実数では、8月1日〜25日の発生報酬は0件・0円です。広告の表示回数も8月13日以降は1日2.8回で、それ以前に多く見えていた表示の大半は運営側の動作確認によるものでした。つまり「広告がクリックされたのに売れない」のではなく、「広告の前をまだ誰も通っていない」が正確な現在地です。この段階で広告の配置や文言をいじっても意味がなく、課題は検索流入という上流だけです。

結論

開設4週間、記事34本での実感です。ブログの自動化は「作って終わり」ではなく、壊れ方を1つずつ見つけて潰していく作業でした。今週の事故は2件とも、外部の攻撃でも AI の暴走でもなく、自分で作った仕組みどうしの衝突です。それでも記事の生成は1日も止まらず、事故のたびに検知の仕組みが1つ増えました。これから自動化を組む人は、自動処理を2つ以上並走させる前に、「書く直前にもう一度読んで、衝突していないか確かめる」一手間を組み込んでおくことをおすすめします。追記が消える事故はエラーを出さないため、検証を仕込んでおかない限り、後から気づく手段がありません。次にやることとしては、9月1日に、この1ヶ月の失敗を原因と対策つきで全件公開する月次のまとめ記事を予定しています。

あわせて読みたい

• アクセスの過半がボットだった|AIブログ自動化3週間目の記録
• AIブログにおすすめのレンタルサーバー比較|4社の料金と選び方

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