cronで毎日LLMにタスクを投げて自動化する(日次サマリ生成)

※本ページには広告(アフィリエイトプログラム等)が含まれます。

※本ページには広告(アフィリエイトプログラム等)が含まれます。API の料金は 2026年8月16日時点の Anthropic 公式ドキュメントの記載、サーバーの出力は同日に運用中の VPS(Debian 12・メモリ 958MB)から採取した実測値です。

🎯 結論:日次サマリはバッチ API で半額になる。cron の落とし穴は 3 つ

結論から書きます。1 日 1 回のサマリ生成は即答が要らない処理なので、通常の API ではなくバッチ API に回すだけで料金が 50% 引きになります。コードの変更もほとんど要りません。

そして cron 側で踏むのは、だいたい決まった 3 つです。PATH・タイムゾーン・エラーの気づけなさ。ここを先に潰しておけば、あとは動き続けます。

  • バッチ API に回す → 全トークン 50% 引き、最大 24 時間で完了
  • 安いモデルで足りる → 要約は Haiku 4.5(入力 $1.00 / 1M)で十分なことが多い
  • ⚠️ cron の PATH は対話シェルと違う → コマンドは絶対パスで書く
  • ⚠️ 失敗しても誰も気づかないMAILTO か通知を必ず仕込む
  • メモリの見積もりを忘れる → ジョブのメモリは cron の枠として計上される(実測あり)

全体の流れ

3 ステップだけ

やることは単純です。①その日のデータを集める → ②API に投げて要約させる → ③通知先に流す。この 3 つをスクリプト 1 本にまとめて cron に登録します。

集めるデータを絞る

ここが費用に直結します。生ログを丸ごと投げると入力トークンが跳ね上がるので、集計してから投げるのが基本です。件数・上位パターン・異常値だけに絞れば、入力は数千トークンで収まります。

出力は短く指定する

どのモデルも出力単価は入力の 5 倍です。「3 行で」「箇条書き 5 つまで」と長さを指定しておくと、そのまま費用に効きます。

実際にいくらかかるか

モデル別の単価

モデル 入力($/1M) 出力($/1M)
Claude Opus 5 $5.00 $25.00
Claude Sonnet 5 $3.00 $15.00
Claude Haiku 4.5 $1.00 $5.00

日次サマリのような定型処理は、最上位モデルで回す理由がほとんどありません。Haiku 4.5 と Opus 5 では入力・出力とも 5 倍違います。

1 日 1 回なら月いくらか

入力 5 万トークン・出力 1,000 トークンのサマリを Haiku 4.5 で毎日回した場合を計算します。

項目 通常 API バッチ API(50% 引き)
入力 5 万トークン $0.050 $0.025
出力 1,000 トークン $0.005 $0.0025
1 日あたり $0.055 $0.0275
30 日 $1.65 $0.825

月 1 ドル未満です。費用より、止まったときに気づけるかどうかのほうが問題になります。

バッチ API に回す条件

バッチは多くが 1 時間以内、最大 24 時間で完了します。日次サマリなら十分許容できる範囲です。1 バッチあたり最大 10 万リクエストまで入り、結果は 29 日間取得できます。

⚠️ 結果の順序は保証されません。必ず custom_id で突き合わせてください。

⚠️ cron で踏む 3 つの落とし穴

1. PATH が対話シェルと違う

いちばん多い失敗です。手で叩けば動くのに cron では動かない、という現象はたいていこれです。

# NG: python も curl も見つからないことがある
0 6 * * * python /home/<user>/daily.py

# OK: 絶対パスで書く
0 6 * * * /home/<user>/venv/bin/python /home/<user>/daily.py

which python3 で確認した絶対パスをそのまま書いてください。PATH= を crontab の先頭で定義する手もあります。

2. タイムゾーン

cron はサーバーのタイムゾーンで動きます。手元の環境はこうなっています。

$ timedatectl | grep -i "time zone"
                Time zone: Asia/Tokyo (JST, +0900)

⚠️ API に渡す「昨日の範囲」を UTC で計算していると 9 時間ずれます。スクリプト側で日付を組み立てるときは、cron の起動時刻とデータの集計範囲が同じタイムゾーンかを必ず確認してください。集計が 1 日ぶんずれても、出力は普通に生成されるので気づきにくい種類の不具合です。

3. 失敗しても誰も気づかない

cron は黙って失敗します。MAILTO を設定しておけば、標準エラー出力がメールで飛びます。

MAILTO="[email protected]"
0 6 * * * /home/<user>/venv/bin/python /home/<user>/daily.py

メールを受け取れない構成なら、スクリプトの最後に「成功した」ことを通知するほうが確実です。エラー通知は届かなければ気づけませんが、成功通知は届かないこと自体が異常の合図になります。

メモリの見落とし

ジョブのメモリは cron の枠に計上される

小さな VPS で見落としやすい点です。手元の環境で cron のメモリ使用量を見るとこうなります。

$ systemctl show cron -p MemoryCurrent --value
(約 164.9 MB)

cron 本体がこれほど食うわけではありません。cron が起動した子プロセスのメモリが、cron の cgroup として合算されているためです。物理メモリ 958MB の環境で 165MB は無視できない比率です。

重い処理を同時刻に並べない

手元の環境には cron が 18 本登録されています。ここで全部を 0 6 * * * のような同じ時刻に置くと、同時に立ち上がって OOM Killer を呼びます

分単位でずらすだけで解決します。0 610 620 6——この程度で十分です。

API 呼び出しはメモリより時間がかかる

LLM の応答待ちは数十秒に及ぶことがあります。タイムアウトを設定していないと、失敗したジョブがそのまま残り続けます。次回の起動と重なると二重実行になるので、タイムアウトと多重起動の防止はセットで入れてください。

cron と systemd timer

どちらを使うか

観点 cron systemd timer
設定の手軽さ 1 行で済む unit 2 つ必要
ログ メール頼み journalctl -u で追える
実行時間の制限 自前で実装 RuntimeMaxSec
多重起動の防止 自前で実装 標準で防止
停電・停止後の取りこぼし 実行されない Persistent=true で追いつく

実際には混在する

手元の環境は cron 18 本、systemd timer 10 本が同居しています。片方に寄せる必要はありませんが、どちらに何があるかは把握しておいてください。障害時に片方しか見ないと、原因を取り逃がします。

新規なら timer を勧める理由

LLM を呼ぶジョブは止まりやすく、遅いという性質があります。多重起動の防止と実行時間の上限が標準で付いてくるぶん、systemd のほうが後々楽です。

よくある質問

Q1. 日次サマリの API 費用はどれくらいですか?

結論:入力 5 万・出力 1,000 トークンを Haiku 4.5 で毎日回して、月 $1.65 です。バッチ API に回せば 50% 引きで 月 $0.825。2026年8月16日時点の公式価格での計算です。

Q2. なぜバッチ API のほうが安いのですか?

結論:即時性を諦める代わりに全トークンが 50% 引きになるからです。多くは 1 時間以内、最大 24 時間で完了します。日次サマリのように「翌朝までに出ていればいい」処理はこの条件を満たします。

Q3. cron で動かないのに手で叩くと動きます

結論:PATH が対話シェルと異なるためです。cron の実行環境は最小限の PATH しか持ちません。which python3 で確認した絶対パスをそのまま crontab に書いてください。

Q4. 集計が 1 日ずれます

結論:タイムゾーンの不一致です。手元の環境は Asia/Tokyo(JST、+0900)ですが、スクリプト側で UTC を使って「昨日」を計算していると 9 時間ずれます。出力自体は普通に生成されるので気づきにくい不具合です。

Q5. ジョブが失敗しても気づけません

結論:MAILTO を設定するか、成功通知を送ってください。エラー通知は届かなければ気づけませんが、成功通知なら届かないこと自体が異常の合図になります。systemd timer を使えば journalctl -u で追えます。

Q6. cron と systemd timer はどちらがいいですか?

結論:新規なら systemd timer を勧めます。多重起動の防止と実行時間の上限が標準で付き、ログが journal に入ります。LLM を呼ぶジョブは止まりやすく遅いので、この 2 つが効きます。手元の環境は cron 18 本と timer 10 本が混在しています。

まとめ

LLM で日次サマリを作る仕組みは、費用よりも「止まったときに気づけるか」が本題です。月 1 ドル未満で回るので、コストは早い段階で問題でなくなります。

  • 🎯 費用 → バッチ API で 50% 引き、Haiku 4.5 なら月 $1 未満
  • 🎯 cron の 3 大失敗 → PATH、タイムゾーン、通知なし
  • 🎯 小さい VPS → 同時刻に並べない(ジョブのメモリは cron の枠に乗る)

料金は改定されます。この記事の数値は 2026年8月16日時点のもので、サーバーの出力は同日に採取したものです。費用の詰め方はLLM API のコスト最適化、常駐と定期実行の設計はsystemd のユニットファイル、失敗の追い方はAI を使ったログの切り分けにまとめています。

読んで頂いて有り難うございます!