この記事の内容(10項目)

自動化を作るときは、「どの条件で動かすか」から考えがちです。私もこのサイトの記事制作や公開確認を自動化するとき、最初は次の作業へ進む条件を中心に作っていました。

ところが、実際の運用で困ったのは、動かなかったときより、止まるべき場面で先へ進みそうになったときでした。広告の提携待ち、申請済みか分からない画面、同じ週の記事数、公開後の表示差。どれも通常の処理だけを考えていると見落とします。

そこで、開始条件とは別に「この状態なら何もしない」という停止条件を先に決めました。今は、次の五つを通らない処理は公開や送信へ進めません。

先に結論

自動化を安全に続けるには、成功時の流れより先に、次の停止条件を決めておくと整理しやすくなります。

  1. 必要な入力や根拠がない
  2. 記録と画面表示が食い違う
  3. 同じ処理を実行済みか分からない
  4. 上限や対象範囲を超えている
  5. 実行後の照合と復元方法がない

停止は失敗ではありません。判断材料が揃うまで、外部へ影響を出さないための正常な動作です。

1. 必要な入力や根拠がなければ止める

記事を公開する場合、本文が完成しているだけでは足りません。このサイトでは、出典、実際に確認した範囲、PR表記、広告の掲載条件を確認してから公開します。

AIで文章を作ると、空欄があっても自然な文で埋められてしまいます。そのため「不明な情報を補完して先へ進む」より、必要な材料がなければ下書きのまま止めるほうが安全です。

たとえば、本人しか確認できない使用感が必要なのに、まだ試していない場合。公式ページで機能は確認できても、「使いやすかった」「時間が減った」とは書きません。記事は実測待ちとして残します。

停止条件は、次のように具体的に書きます。

出典URLがない → 公開しない
本人実測が必要な項目に記録がない → 体験表現を書かない
広告記事にPR表記がない → 配信ファイルを作らない

2. 記録と画面表示が食い違ったら止める

外部サービスでは、操作直後に一覧へ反映されないことがあります。こちらの記録では申請済みでも、画面では未申請に見える場合があります。

このとき、画面だけを見てもう一度送信すると、重複申請になるかもしれません。反対に、記録だけを信じると、最初の操作が完了していなかった可能性も残ります。

このサイトの運用では、申請済みの本人記録と管理画面が食い違った場合、すぐに再送しません。一定時間待ち、別の一覧や通知で状態を確認します。

大切なのは、どちらかを都合よく正しいと決めないことです。「食い違いを検出した」という状態を残し、次の確認時刻を決めます。

3. 実行済みか分からなければ止める

自動処理は速いため、同じボタンやAPIを二回実行すると、同じ投稿、同じメール、同じデータが重複して作られます。

対策として、実行前に本文や入力データから同一性を確認する印を作ります。このサイトのThreads投稿用コネクタでは、投稿本文のハッシュを記録し、同じ本文をもう一度送ろうとした場合に止める設計にしました。

画面操作の場合も、送信後のURL、受付番号、時刻などを記録します。記録がないのに完了画面も確認できない場合は、推測で再実行せず、人が状態を確認します。

同じ入力の完了記録がある → 再実行しない
実行結果が不明 → 自動再試行しない
一意の投稿IDや受付番号を確認できた → 完了として記録する

4. 上限や対象範囲を超えたら止める

一件の処理が正しくても、繰り返すうちに利用量や費用の上限へ近づくことがあります。自動化では、1回だけでなく一日・一か月の処理量も見ます。

たとえば、無料枠で試すなら、使える回数や利用量を超える前に止める。外部へ送信する処理なら、許可した宛先と件数を超えたら止める。このように、費用や誤送信を防ぐための境界を決めます。

記事制作の件数目標は、この上限とは別です。このサイトでも固定の件数上限を外しました。件数だけでは止めず、根拠や確認が足りない記事を公開しないようにしています。

対象範囲も同じです。A系サイトから別テーマのサイトへリンクしない、許可したドメイン以外へ送客しない、といった境界を先に固定します。

5. 実行後の照合と復元方法がなければ止める

「アップロードが終わった」は、公開確認の完了ではありません。

このサイトでは、配信前に旧版を残し、公開後にページの応答、タイトル、リンク、PR表記、配信ファイルの一致を確認しています。問題があれば直前版へ戻せる状態を作ってから切り替えます。

自動化する処理には、次の三つをセットで考えます。

  • 実行前に何を残すか
  • 実行後に何と何を照合するか
  • 失敗時にどこまで戻すか

復元できない処理なら、自動実行せず下書きや確認画面で止めます。メール送信ではなく下書き作成、データ削除ではなく対象一覧の作成に変える方法もあります。

そのまま使える停止条件メモ

新しい自動化を考えるときは、次を一枚にまとめます。

【実行する処理】

【必要な入力・根拠】
不足していたら何も変更せず終了する

【重複を見分ける印】
処理ID、受付番号、本文ハッシュ、更新日時など

【画面と記録が食い違った場合】
再送せず、確認時刻と確認担当を残す

【回数・件数・対象範囲の上限】

【実行後に照合するもの】

【失敗時の復元方法】

【最後に人が判断する操作】

この欄を埋められない処理は、まだ無人実行へ進めない、と決めます。

どこまで自動化するか

自動化は、最後まで一気に動かさなくても役に立ちます。

記事なら、出典一覧の作成、リンク検査、公開ファイルの生成までは自動化し、外部送信の直前で止められます。申請なら、対象記事と条件の照合、入力内容の準備まで進め、送信は人が確認できます。

停止条件を書けたら、本番のメールや顧客情報をつなぐ前に、一件だけ試します。このサイトでは匿名データをMakeへ送り、請求書の経路だけを通ることを確認しました。

外部アプリを接続せず、Webhookと分岐を試した手順から、入力と実行履歴の確認へ進めます。接続先の権限を増やす前に、まず匿名データ一件で試してみてください。

GASのままでよいか迷う場合は、GASとMakeの使い分けへ。公開作業の検査は、AI記事の公開前チェックとサイト公開直後の確認で分けています。

まとめ

自動化を作るときは、「条件が揃ったら動く」だけでは足りません。

入力不足、状態の食い違い、重複の可能性、上限超過、復元不能。この五つで止まれるようにすると、止まった理由を人が確認してから再開できます。

最初に作るのは、便利な処理より停止条件のメモでもよいと思います。いま自動化したい作業を一つ選び、「実行結果が分からないとき、再実行してよいか」から書いてみてください。

出典・関連資料

この記事の確認情報

最終確認日:2026年9月18日

確認に使ったもの

  • A系サイト運用で発生した未提携案件の公開停止と申請状態の不一致
  • Threads本文の重複防止、公開前バックアップ、公開後照合の実装記録

参照した公式情報

リンクは新しいタブで開きます。