※本ページには広告(アフィリエイトプログラム等)が含まれます。
※本ページには広告(アフィリエイトプログラム等)が含まれます。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 6、10 6、20 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 を使ったログの切り分けにまとめています。
