Claude Codeの定期タスクで毎日と毎週の仕事を自動化した｜「変更がなければ何もしない」が肝だった
経営データの更新を毎日、SEOの数値分析を毎週、自動で回しています。作ってみて分かったのは、処理内容より「動かない条件」をどう書くかで運用が決まるということでした。実際のタスク定義をもとに書きます。
結論：書くべきは処理内容ではなく「動かない条件」
定期タスクを2つ運用しています。
| タスク | 頻度 | 内容 |
|---|---|---|
| 経営データの更新 | 毎日 | スプレッドシートの最新値をダッシュボードに反映 |
| SEOの週次分析 | 毎週月曜 | GA4とSearch Consoleの数値を取得し、前週比を分析して次の一手を1つ提案 |
作ってから気づいたのは、タスク定義の大半が「やること」ではなく「やらないこと」の記述になったという点です。
定期実行は、毎回まじめに全部やると無駄が多く、しかも危険です。「変わっていないなら何もしない」「これはやらせない」を先に決めるほうが、運用が安定しました。
実例1：毎日のデータ更新
やることは「スプレッドシートの値をダッシュボードに反映する」だけです。
しかし定義の冒頭は、こう始まります。
1. 【更新時刻チェック（最重要・最初にやる）】
スプレッドシートの modifiedTime を取得する。
保存してある前回の値と同一なら、
他に何もせず「変更なし」とだけ報告して終了。
まず「動かなくていいか」を判断させています。
これを入れないと、毎日必ずデータを全部読み込み、全部再生成し、再公開まで走ります。中身が1文字も変わっていなくてもです。
効果は2つある
- 無駄な処理が消える — 変更がない日は数秒で終わる
- 意図しない更新が起きない — 再生成のたびに微妙な差分が出る、という事故が防げる
2つ目が地味に効きます。生成物は、実行するたびに完全に同じとは限りません。変更がないなら触らないのが、一番安全な状態でした。
セットで扱うものは明記する
このタスクでは、2つの成果物を同時に更新します。定義にこう書いています。
2つは同じマスターデータ・同じ更新判定を共有しているため、
必ずセットで扱う。
過去に片方だけ更新して、もう片方が古いまま公開されているという事故が起きました。人間でも起きるミスなので、タスク定義に明記して防ぐ形にしています。
実例2：毎週のSEO分析
こちらは判断を含む仕事です。数値を取り、前週と比べ、次の一手を提案します。
ここで重要だったのは、提案の量に上限をかけたことでした。
次の一手を1つだけ提案する（あれもこれも出さない。
理由と、期待できる効果の見込みを添える）
改善案は、頼めばいくつでも出てきます。しかし10個提案されても実行できません。 実行されない提案は、出力を読む時間を消費するだけです。
「やらない」判断も定義に書く
このタスクには、こういうルールを入れています。
A/Bテストは提案しない。
週70〜100セッションでは有意差が出ない。
週300セッションを安定して超えるまでは、
A/Bではなくコンテンツ追加で入口を増やすフェーズ。
数値が少ない段階でA/Bテストを提案されても、実行する意味がありません。「この条件を満たすまでは提案しない」を先に書いておくと、毎週同じ議論をしなくて済みます。
さらにこう書いています。
変化がなければ「変化なし」と正直に報告する。
無理に動きを見つけて施策を打たない。
定期タスクは毎週何かを報告しようとします。「今週は特にありません」と言える許可を明示的に与えておかないと、誤差を変化として読み始めます。
やらせないことを線引きする
一番はっきり書いているのがここです。
本番サイトへの公開は絶対にしない。
--dry-run までは実行してよい。公開は人間が行う。
数値を測り、分析し、提案するところまでが定期タスクの仕事です。外向きに影響が出る操作は含めていません。
自動化の設計では、取り返しがつかない操作を自動化しないのが原則だと考えています。公開・送信・削除・購入は、人間がボタンを押す形に残しておく。
生存確認を組み込む
これは最近追加しました。
別で運用している毎朝の自動処理が、認証切れで14日間止まっていたのに誰も気づかなかったという事故がありました。エラーがログにしか出ないので、成功と失敗の体感が同じだったためです。
そこで週次タスクの中に、他の自動処理が生きているかを確認する手順を追加しました。
~/.claude/scripts/automation-healthcheck.sh
⚠が出たら、その週の報告の冒頭に書く
（SEOの数字より先に報告する）
止まっている自動処理は、順位の変動より優先度が高いという判断です。定期タスクは必ず実行されるので、そこにチェックを寄生させると、確認漏れが起きません。
詳しくは自動化が静かに壊れる話に書きました。
つまずきやすい点
手順書を別ファイルにする
タスク定義に全部の手順を書くと、長くなって読みづらくなります。
当方では、タスク定義には「手順書: このファイルを見ろ」と場所だけ書き、詳細はプロジェクト側のREADMEに置いています。プロジェクトの仕様が変わったとき、直す場所が1か所で済みます。
失敗したときに状態を進めない
これは定期実行全般の原則です。
失敗したのに「次へ」と状態を進めてしまうと、失敗した回のぶんが飛びます。 復旧しても、その回は永久に処理されません。
失敗したら状態を進めない設計にしておくと、復旧したときに止まった位置から自動で再開できます。
通知が来ないことを「正常」と誤解しない
成功時だけ通知する作りだと、通知が来ないときに「何もなかった」のか「壊れている」のか区別できません。
沈黙は成功の証拠になりません。 生存確認を別に持つのは、このためです。
よくある質問
定期タスクで毎回すべての処理を実行する必要はありますか？
ありません。最初に「前回から変更があったか」を判定し、変更がなければ何もせず終了する形にすると、無駄な処理と意図しない更新の両方を防げます。データの更新時刻を保存しておき、前回の値と比較する方法が簡単です。
定期タスクに公開や送信までやらせてもいいですか？
取り返しがつかない操作は含めないほうが安全です。数値の取得・分析・提案までを自動化し、公開や送信は人間が判断して実行する形にすると、事故が起きても影響が内側にとどまります。
毎週の分析タスクが毎回同じような提案を出してしまいます。
提案の数に上限をかけ、「この条件を満たすまでは提案しない」というルールを定義に書いてください。また「変化がなければ変化なしと報告してよい」と明示すると、誤差を変化として読むことがなくなります。
まとめ
定期タスクの定義で時間をかけるべきは、処理内容ではありませんでした。
- 動かない条件を最初に書く（変更がなければ何もしない）
- 提案の量に上限をかける（実行できない数を出させない）
- やらせないことを明記する（公開・送信は人間が押す）
- 他の自動処理の生存確認を寄生させる
処理内容は後から直せます。しかし「毎日勝手に公開される」設計にしてしまうと、気づいたときには手遅れです。 最初に線を引いておくのが一番安く済みました。