Google Apps Scriptは、個人開発の小さな自動化に向いています。サーバーを用意しなくても、定期的にURLを取得する、スプレッドシートへ記録する、失敗時だけメールを送る、といった処理を始められます。この記事では、時間主導トリガーを使う前に決めておきたいことを作業ログとして整理します。
最初に決めること
いきなりコードを書く前に、何を、どれくらいの間隔で、失敗したらどう扱うかを決めます。取得先が外部サイトの場合、短すぎる間隔は相手に負荷をかけます。逆に長すぎる間隔では情報の鮮度が落ちます。個人メディアの運用なら、重要度に応じて30分、2時間、4時間のように板や対象ごとに分けると管理しやすくなります。
構成を4つに分ける
Trigger
時間主導トリガーは、毎分、数分おき、毎時、毎日などの単位で設定できます。ただし、実行時刻は完全に秒単位で固定されるわけではありません。厳密な時刻実行が必要な用途より、定期巡回や軽い通知に向いています。
Fetch
外部URLを取得する処理では、User-Agent、タイムアウト、HTTPステータス、文字コードを確認します。取得に失敗した場合に空データとして扱うのか、次回へ持ち越すのかを決めておくと、後から原因を追いやすくなります。
Store
取得結果は、スプレッドシート、D1、外部APIなどに保存できます。GAS単体で完結させるならスプレッドシートが手軽ですが、公開サイト側で使うデータならWorker APIへPOSTする方が整理しやすいです。保存時には重複判定のキーを決めておきます。
Notify
失敗したときだけメール通知する仕組みを入れると、普段は静かに動かせます。毎回通知すると慣れて見なくなるため、エラー時、取得件数が0件のとき、連続失敗したときなど、通知条件を絞るのがおすすめです。
トリガーは1つ作って終わりではなく、対象ごとの最終実行時刻を見て、実行するかどうかをコード側で判定すると柔軟です。これならGASのトリガー自体は5分おきにして、対象ごとに30分、2時間、4時間の間隔を持たせられます。
ログに残す項目
- 実行開始時刻と終了時刻
- 取得対象の名前
- 取得件数
- 新規保存件数
- HTTPステータスやエラー内容
- 次回実行予定の目安
ログは、問題が起きたときだけ見るものではありません。いつもどおり動いていることを確認するためのものでもあります。個人開発では監視サービスを入れないことも多いので、最低限の実行ログがあるだけで安心感がかなり変わります。
公開前チェックリスト
GAS定期処理の確認
- 取得間隔が短すぎない
- 重複データを保存しないキーがある
- 失敗時の通知条件が決まっている
- APIトークンをScript Propertiesに置いている
- 実行ログから件数とエラーを追える
GASは、本格的なジョブキューの代わりではありません。ただ、個人開発の初期に小さな巡回処理を試す道具としてはとても便利です。うまく回り始めた処理だけ、必要に応じてCloudflare Workers Cronなどへ移すと、無理なく育てられます。