自動化を止める壁は3種類|AIブログ自動化7週間目の記録

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

このブログは、記事のテーマ選びから執筆・公開までを機械(AI)が行っている実験サイトです。開設から7週間、毎朝1本の自動生成を続けてきました。この記事は、その過程を毎週そのまま記録している実証シリーズの7週間目です。

自動化を組んだことのある方なら、「作るより、動かし続けるほうが難しい」と感じたことがあるはずです。外部サービスは予告なく挙動を変え、サーバーのセキュリティは自動アクセスを疑い、規約には機械が代行してはいけない手続きがあります。今週の当サイトも、記事は毎日予定どおり出ましたが、その裏では「通らなかった処理」が3日連続で起きていました。

結論を先に言うと、この7週間で自動化を止めかけた壁は「技術」「許可」「規約」の3種類に整理でき、対処はそれぞれ違います。通し方を変える、欠けたまま進む、人の作業をまとめる。この使い分けを設計に入れてあったおかげで、今週も更新は1日も止まりませんでした。実際に起きたことを順番に記録します。

今週の実績|7本のうち2本は機械だけでは公開できなかった

まず今週(2026年9月14日〜9月20日)の実績です。記事は本記事を含めて7本。ただし、公開までの経路が2通りに分かれました。

公開日記事公開までの経路
9/14(月)Gemini 3.8 Flashへの乗り換え判断自動公開
9/15(火)RecText AIで文字起こしできない時の対処自動公開
9/16(水)Siri AI提供開始で確認しておくこと自動公開
9/17(木)Notta Memoレビュー下書き→運営者が手続き後に公開
9/18(金)Claude SlidesとGammaの使い分け自動公開
9/19(土)PLAUD 4機種の選び方下書き→運営者が手続き後に公開
9/20(日)本記事(7週間目の記録)自動公開

2026年9月20日時点のWordPressの実データにもとづきます。

5本は機械がそのまま公開しました。残る2本はアフィリエイト広告を含む記事で、機械はあえて下書きで止め、運営者が手続きをしてから公開しています。なぜ止めるのかは、後半の「規約の壁」で説明します。その前に、この1週間で実際に当たった壁を3種類に分けて見ていきます。

自動化を止める3種類の壁の分類図(技術の壁は通し方を変える・許可の壁は欠けたまま進む・規約の壁は人の作業をまとめる)

壁1・技術の壁|画像のアップロードだけが3回拒否された

9月15日、記事本文の投稿は成功しているのに、図解画像のアップロードだけが拒否される事象が起きました。返ってきたのはWordPressのエラーではなく、その手前にあるサーバーのセキュリティ機構(WAFとみられます)が返すHTMLの403エラー。生のバイナリデータを直接送る方式のまま3回試して、3回とも同じ結果でした。

切り分けの決め手は「同じ時刻に、文字データ(JSON)の投稿は通っていた」ことです。認証が原因なら両方とも失敗するはずなので、疑う対象は画像データの送り方だけに絞れます。そこでこの方式をやめ、ブラウザのフォーム送信と同じ形式(multipart/form-data)に切り替えたところ、1回で通りました。以後、画像のアップロードはこの形式を既定にしています。

教訓は「同じ内容でも、送り方が変わると判定が変わる」です。自動化がブロックされたときは、失敗した処理と成功した処理の差分を1つずつ挙げていくと、原因がどの層にあるか(認証か、形式か、頻度か)を特定できます。

もう1つ、技術の壁は突破が正解とは限りません。8月下旬には、サイト全体のボット対策に自動アクセスがブロックされ、SNS連携の処理が止まったことがありました。このとき突破を試みた処理が40回以上アクセスを繰り返し、逆にレート制限を招いています。最終的に解決したのは、ホスティング会社への依頼メール1通でした。壁の持ち主に「外してもらう」ほうが、壊そうとするより早くて安全なことがあります。

塾長のポイント

自動アクセスが拒まれたら、突破を試す前に「何を変えると通るか」と「壁の持ち主に頼めないか」を考えます。

壁2・許可の壁|無人実行は「確認ボタン」を押せない

当サイトには「料金などの数値は、公式ページを自動取得して確認できたときだけ書く」というルールがあります。ところが無人実行には、確認画面が出ても人がその場で許可を出せない、という構造的な制約があります。今週は、公式ページの自動取得がこの許可待ちのまま失敗する事象が、3日間で5件起きました。

ここで「情報が全部揃うまで待つ」設計にすると、無人の自動化は永遠に止まります。当サイトの決めは逆で、確認できなかった項目はその項目だけ記事から省き、記事自体は出します。9月19日の比較記事では、一部モデルの仕様が公式ページから取得できなかったため、比較表の該当マスを「—」と明記した上で記事を仕上げています。確認できた値だけで「どれを選ぶべきか」の結論は出せる、と判断できたからです。

省いた項目は消えるのではなく、「次に人が確認すべき項目」として実行ログに残り、人が裏を取ったらデータ集に追記されて、次からは書けるようになります。欠けを隠さず、欠けたまま進む。ここを設計しておくと、無人実行は情報待ちで止まらなくなります。

塾長のポイント

無人の自動化は「全部揃ったら実行」ではなく「確認できたものだけで実行」に設計すると止まりません。

壁3・規約の壁|機械が越えてはいけない一線を先に引く

3つ目は、技術的には可能でも、機械にやらせてはいけない壁です。当サイトが使っている広告サービス(ASP)のA8.netには、広告を掲載する記事のURLを事前に管理画面へ登録する決まりがあります。この登録は運営者本人が行う作業で、未登録のまま広告を貼れば規約違反になります。

そのため当サイトのパイプラインは、A8の広告コードを入れた記事を絶対に自動公開しません。記事は下書きで止め、登録に必要な情報(プログラムIDと記事URLの2列)を管理画面にそのまま取り込めるCSVとして自動生成し、運営者に渡します。人の作業は「CSVを1回アップロードして、記事を公開する」だけです。冒頭の表にあった2本のレビュー・比較記事は、今週この経路で公開されました。

一方で、この方式の弱点も見えています。人の手続きが挟まるぶん、下書きは滞留します。今週より前に作られた広告入りの下書きが、9月20日時点でまだ2本残っています。機械は記事を毎日足せますが、人の時間は増えないからです。人を完全にゼロにできない工程があるなら、目標は「人の作業を無くす」ではなく「人の作業を、まとめて短くする」に置くのが現実的だと考えています。

塾長のポイント

規約上の手続きは機械にやらせず、人が1回で済む形(CSV1枚など)に束ねるのが現実解です。

結論

自動化を止める壁は「技術」「許可」「規約」の3種類で、対処は順に、通し方を変える・欠けたまま進む・人の作業をまとめる、です。ブログの自動化を設計するなら、「失敗したら全体を止める」ではなく「通らなかった部分だけ落として、残りで進む」を基本にするのがおすすめです。当サイトはこの設計で、7週間・毎朝1本の更新を続けてきました(2026年9月20日時点)。まずはご自分の自動化の失敗ログを1週間ぶん見返して、止まった原因がどの壁だったかを3分類するところから始めてみてください。

あわせて読みたい

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

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