Cron式ビルダー

Cron式ビルダーとは

本ツールは Linux / Unix 系の定番ジョブスケジューラ cron の スケジュール式を、GUI から直感的に生成・解析できる無料オンラインツールです。 分・時・日・月・曜日の5フィールドをドロップダウンで選択すると、 画面上部に 0 9 * * 1-5 のような cron 式が即座に表示されます。 「解析モード」に切り替えれば、既存の cron 式を貼り付けて人間可読な説明と 次回実行予定を確認できます。入力データはすべてブラウザ内で処理され、 外部に送信されることは一切ありません。

Cron式の基本書式

Unix の crontab で採用されている標準の cron 式は、 スペース区切りの5フィールドで構成されます。

┌─────── 分      (0-59)
│ ┌───── 時      (0-23)
│ │ ┌─── 日      (1-31)
│ │ │ ┌─ 月      (1-12)
│ │ │ │ ┌ 曜日   (0-6, 0=日曜)
│ │ │ │ │
* * * * *

たとえば 0 9 * * 1-5 は「毎週月曜から金曜の朝9時ちょうど」、*/15 * * * * は「15分おき」を意味します。 本ツールは Unix 標準の 5 フィールドに絞って生成・解析します （秒フィールドや年フィールドを含む 6〜7 フィールド版には対応していません）。

特殊文字の意味

• * … ワイルドカード。そのフィールドの全値にマッチ
• , … 列挙。1,15 = 1日と15日
• - … 範囲。1-5 = 月曜〜金曜（曜日フィールド）
• / … ステップ。*/15 = 15分おき、0-30/5 = 0〜30分で5分おき

これらは組み合わせ可能で、0,15,30,45 のような列挙を*/15 と書き換えることで保守しやすくなります。

よくあるパターン

• 0 * * * * … 毎時0分（毎正時）
• */5 * * * * … 5分おき（監視ポーリング、ヘルスチェック）
• 0 0 * * * … 毎日 0:00（日次バッチ、ログローテーション）
• 0 9 * * 1-5 … 平日9:00（営業日の朝会スクリプト、レポート生成）
• 0 2 * * 0 … 毎週日曜の 2:00（週次メンテナンス、バックアップ）
• 0 0 1 * * … 毎月1日 0:00（月次レポート、請求処理）
• 0 0 1 1 * … 年1回 1月1日 0:00（年次の棚卸し）

Linux / macOS の crontab

伝統的な Linux・macOS のジョブは crontab -e で編集します。 このファイルに上記の cron 式とコマンドを記述すると、cron デーモンがスケジュール通りに実行します。

# 例: 毎日 2:00 に Docker の不要イメージを削除
0 2 * * * docker system prune -a -f

注意点として、crontab 内のコマンドは最小限の環境変数しか渡されません。 PATH が通っていないことが多く、/usr/local/bin/node のように 絶対パスで指定するか、ジョブ先頭に PATH=... を宣言するのが定石です。 また、出力が届かない（標準出力・標準エラーがメール送信される既定動作）ため、>> /var/log/myjob.log 2>&1 のように明示的にログに落とすことを推奨します。

Docker / Coolify での定期実行

コンテナ内で cron を動かす場合、PID 1 問題（cron がフォアグラウンドで動かない）や 環境変数の引き継ぎなど、いくつか落とし穴があります。 最近は Docker の標準機能で cron を動かすより、ホストの cron か外部のスケジューラからdocker exec / docker compose runでコマンドを叩く構成が推奨されます。

セルフホスト型 PaaS の Coolify は「Scheduled Tasks」機能を提供しており、 cron 式を UI から設定してコンテナ内のコマンドを定期実行できます。 式の書き方は本ツールで生成したものをそのまま貼り付けられます。

GitHub Actions の schedule

GitHub Actions のワークフローでは on.schedule.cron に cron 式を書けます。 ただし タイムゾーンは UTC 固定で、ユーザーのローカルタイムとは異なります。 日本時間の毎朝9時に動かしたい場合、0 0 * * *（UTC 深夜0時 = JST 9時）と書く必要があります。 また、GitHub Actions の schedule は負荷状況により数分〜数十分遅延することがあるため、 厳密なタイミング要求がある処理には不向きです。

# .github/workflows/daily.yml
on:
  schedule:
    - cron: "0 0 * * *"   # UTC 0時 = JST 9時
  workflow_dispatch:

workflow_dispatch を併記すると、スケジュールとは別に手動実行もできるようになり、 デバッグやリカバリ時に便利です。

よくあるつまずきポイント

• タイムゾーンの取り違え： cron 実行時のタイムゾーンはシステムの TZ 設定次第。GitHub Actions は UTC。 本ツールの「次の実行予定」はブラウザのローカルタイムで表示しています。
• PATH が通っていない： 手元のシェルと cron 環境は別物。node not found のようなエラーが出たら 絶対パスで書き直します。
• 日（DOM）と曜日（DOW）の両方を指定： Vixie cron（Linux標準）ではOR 解釈です。0 0 15 * 1 は 「毎月15日」または「毎週月曜」に実行されます。AND ではありません。
• 実行の重複： 前回のジョブがまだ走っているのに次の時刻が来ると、デフォルトでは新しいプロセスが並行起動します。 重複を避けたい場合は flock（Linux）やアプリ側のロック機構を組み合わせます。
• 夏時間（DST）： サマータイムのある地域では、時計の進み・戻しで 1 時間ジョブがスキップ／二重実行される場合があります。 日本標準時（JST）には DST がないので日本運用では気になりませんが、 多国籍環境では注意が必要です。

セキュリティとプライバシー

本ツールはサーバー API を一切呼びません。入力した cron 式、生成した cron 式、 次回実行予定の計算はすべてお使いのブラウザ内で完結します。 社内の未公開システムのジョブ設計を検討する用途でも、情報漏洩のリスクなくご利用いただけます。