【2026年】Linux cron vs systemd timer 比較｜定期タスク管理の最適解

基本的な構文は以下の 6 つの要素で構成されます。最初の 5 つが時刻指定のフィールドであり、最後の要素が実行するコマンドです。各フィールドには文字列や数値だけでなく、ワイルドカードやリスト指定も可能です。例えば、* * * * * は毎分実行を意味し、これはシステム監視スクリプトなどで頻繁に使用されます。また、数字の範囲指定（1-5）やステップ値（*/10）の使用も可能で、これにより柔軟なスケジュール設定が行えます。

cron のフィールドは以下の通り定義されており、それぞれの制約を理解しておくことが誤作動防止につながります。

• 分 (Minute): 0 - 59
• 時 (Hour): 0 - 23
• 日 (Day of Month): 1 - 31
• 月 (Month): 1 - 12
• 曜日 (Day of Week): 0 - 7（0 と 7 は日曜）

これらのフィールドを組み合わせる際に、よくあるミスとして「曜日の指定が異なる」ことが挙げられます。例えば、Linux の標準的な cron では曜日が 0-6 の範囲で定義されることが一般的ですが、一部の GNU crontab 実装では 0 と 7 が両方とも日曜日として扱われます。また、/etc/crontab を編集する際は、ユーザー名フィールドが追加される点に注意が必要です。これは、誰の権限でタスクを実行するかを指定するためのものであり、root ユーザーで実行したい場合はここに root と記述します。

具体的な設定例として、毎日午前 2 時にバックアップスクリプト /home/admin/backup.sh を実行する場合の設定は以下のようになります。

0 2 * * * root /home/admin/backup.sh >> /var/log/backup.log 2>&1

この行の意味を分解すると、「分：0 時、時：2 時、日：毎月、月：毎日、曜：毎日」となり、結果として「毎日午前 2 時に実行」となります。また、標準出力と標準エラー出力をログファイルにリダイレクトする部分も重要です。>> /var/log/backup.log は結果をログに残し、2>&1 はエラー情報も含めて同じファイルに記録します。これにより、タスクの成否を後から確認することが可能になります。

Ubuntu 24.04 LTS や Debian 12 のような現行ディストリビューションでは、cron デーモンは通常 cronie パッケージとして提供されます。Fedora 41 では systemd との統合が強化されているため、単純な cron スクリプトでも systemd timer を経由して実行するパターンが増えています。ただし、既存のレガシーシステムや、特定のサードパーティ製ソフトウェアが依存している設定を変更しないためには、cron の構文を正しく理解し続ける必要があります。

cron の高度な運用テクニックと制限事項

cron を実務レベルで安定して運用するためには、基本的な時刻指定を超えた高度なテクニックを理解する必要があります。特に、スクリプトの実行時間が長時間に及ぶ場合や、重複実行によってリソースが枯渇するリスクを回避するための機構が必要です。最も一般的な手法は「ロックファイル」の活用です。flock コマンドを使用することで、あるプロセスが既に実行中であることを検知し、次の実行を待機させたりスキップしたりすることができます。これにより、バックアップ処理中に再度トリガーされることを防ぎます。

具体的には、cron のコマンド部分に flock を追加して記述します。例えば、スクリプトの実行開始時にロックを取得し、完了するまで他の実行をブロックする設定は以下のようになります。

• 例: 0 2 * * * root flock -n /var/lock/db_backup.lock /home/admin/db_backup.sh
• 説明: -n オプションは非ブロックモードを指定します。ロックが存在する場合、即座に失敗（スクリプト実行なし）として終了します。

このテクニックは、システムが長時間停止している場合や、ネットワーク遅延により処理が異常に長引いた場合に有効です。また、cron の設定ファイルには環境変数も定義可能です。PATH 変数を適切に指定することで、スクリプト内で呼び出すコマンドのパスを解決しやすくします。デフォルトでは PATH=/usr/bin:/bin が設定されていますが、専門的なツールを使用する場合はこれを拡張することが推奨されます。

cron には他にも高度な機能として特殊記述子（@reboot, @daily など）があります。これらは標準的な 5 フィールド形式の短縮版であり、頻出するスケジュールを簡潔に記述できます。

• @reboot: システム起動時に 1 回だけ実行
• @yearly: 毎年 1 月 1 日 0 時 0 分（@annually と同じ）
• @monthly: 毎月 1 日 0 時 0 分
• @weekly: 毎週日曜日の 0 時 0 分
• @daily: 毎日 0 時 0 分
• @midnight: 毎日 0 時 0 分

システム起動時にのみ実行するスクリプト（例えば、ネットワーク設定の初期化）が必要な場合、@reboot を使用すると非常に便利です。ただし、この機能は /etc/crontab ではなくユーザーごとの crontab でよく使われます。また、メール通知機能も重要な要素です。[email protected] と記述することで、タスクの実行結果（標準出力）を指定されたメールアドレスに送信できます。

しかしながら、cron の運用にはいくつかの制限事項や注意点もあります。まず、システムがシャットダウンされている期間中に設定された時刻のタスクは実行されません。これは「anacron」によって補完される機能ですが、通常のスクリプトでは遅延処理が行われません。このため、サーバーが週次メンテナンスで数日間停止している場合、バックアップなどが欠落するリスクがあります。また、cron は基本的にユーザー権限で動作するため、root 権限が必要なタスクを設定するには /etc/crontab や sudo の設定を適切に行う必要があります。

さらに、ログ出力はデフォルトでは syslog に集約されますが、これは分散管理されるため、特定の cron スクリプトの履歴だけを追跡するのは困難です。また、cron デーモン自体が停止した場合や、crontab ファイルのパーミッションが誤って変更された場合にタスクが実行されなくなるトラブルも発生し得ます。これらのリスクを最小限に抑えるためには、定期的な設定の確認とログ監視の設定が不可欠です。

systemd timer の仕組みとユニットファイル作成

systemd timer は、cron と同様の目的を持ちつつも、その実装方式において根本的な違いがあります。これは systemd マネージャーの一部として動作し、他のシステムサービス（service）やソケットと密接に連携する設計となっています。systemd timer を設定するには、主に 2 つのファイルを作成する必要があります。「.timer」ファイルが時刻指定を担当し、「.service」ファイルが実際のタスク実行を担当します。この分離構造により、スケジュール管理と処理ロジックを明確に分けることができ、保守性が向上します。

まず、timer ユニットファイルの作成から始めます。通常、/etc/systemd/system/ ディレクトリに配置し、拡張子を .timer とします。ここで重要なのは OnCalendar 設定です。これは cron の 5 フィールド形式よりも柔軟で、人間が読みやすい自然言語に近い記述が可能です。例えば、「毎週月曜日の午前 10 時」を指定する際、cron では 0 10 * * 1 と数字だけで指定しますが、systemd timer では OnCalendar=Mon 10:00 と表記できます。これにより、設定ファイルの可読性が劇的に向上します。

具体的な systemd timer ユニットファイルの例を以下に示します。この設定では、毎朝 8 時に実行されるスクリプトを定義しています。

[Unit]
Description=My Daily Backup Timer
After=network-online.target

[Timer]
OnCalendar=*-*-* 08:00:00
Persistent=true
RandomizedDelaySec=60s

[Install]
WantedBy=timers.target

このファイルのポイントとして、After=network-online.target が挙げられます。これは、タスク実行前にネットワークが確実に確立されていることを保証する依存関係です。systemd timer は他のユニットとの順序制御が可能であり、バックアップのようなネットワーク依存タスクでは非常に有用です。また、OnCalendar にはワイルドカードも使用でき、*-*-* 08:00:00 は毎日 8 時を意味します。

次に、実際にスクリプトを実行する .service ユニットファイルを作成します。これは /etc/systemd/system/ ディレクトリに配置し、拡張子を .service とします。timer ユニットは Unit= セクションでこの service ファイルへのリンクを指定します。

[Unit]
Description=My Daily Backup Service
After=network-online.target

[Service]
Type=oneshot
ExecStart=/home/admin/backup_script.sh
User=admin
StandardOutput=journal
StandardError=journal

Type=oneshot は、タスクが終了したら systemd がそのプロセスを待機しなくてよいことを示します。これは通常のスクリプト実行に適しています。また、StandardOutput と StandardError を journal に設定することで、出力ログを systemd のジャーナルに記録させることができます。

このように、systemd timer は cron とは異なり、単なる時刻指定だけでなく、システムの状態や依存関係を考慮してタスクを実行できる点が特徴です。Ubuntu 24.04 LTS（systemd 255）および Fedora 41（systemd 256）では、これらの機能がさらに強化されており、ネットワーク起動時の同期処理などもより細かく制御できるようになっています。

設定ファイルの作成後は、systemctl daemon-reload を実行して変更を反映させます。その後、systemctl enable <timer_name>.timer で有効化し、systemctl start <timer_name>.timer でテスト実行可能です。このように systemd timer は、モダンな Linux システムにおける標準的な定期タスク管理手法として確立されています。

systemd timer の高度機能：精度と依存管理

systemd timer には、cron では対応が困難な高度な機能が多数実装されています。特に、時刻のズレ補正や実行間隔のランダム化といった機能は、サーバーの負荷分散やシステムログの平準化に寄与します。これらは Linux システムを運用する上で、単なる自動化を超えて「安定性」を高める要素となります。

まず、「OnBootSec」機能について解説します。これはシステム起動から指定した時間の後にタスクを実行する設定です。例えば、OnBootSec=10min と記述すると、サーバーの再起動後 10 分経過した時点でタスクがトリガーされます。これは、システム起動時にネットワークサービスやファイルシステムが完全にマウントされるのを待ってからバックアップを開始したい場合などに有用です。cron ではこれを実現するには複雑なスクリプトロジックが必要ですが、systemd timer では設定だけで完結します。

次に、「RandomizedDelaySec」機能は、同じ時刻に多数のサーバーでタスクを実行する際に、負荷集中を防ぐために設計されています。RandomizedDelaySec=1h と指定すると、実際の実行時間は指定された時刻から ±1 時間の範囲内でランダムになります。これにより、例えば世界中に分散配置されたサーバーがすべて同一時刻にバックアップを開始することでネットワーク輻輳を引き起こすリスクを低減できます。2025 年以降のクラウド環境や大規模インフラ運用では、この機能は標準的なベストプラクティスとして推奨されています。

また、「Persistent=true」という設定も重要です。これは、設定された時刻にシステムがシャットダウン状態であった場合でも、システム起動後に遅延実行を行うことを保証します。cron はシステム停止中に落ちたタスクを逃しますが、systemd timer を使用すれば後から必ず実行されます。特に、メンテナンスウィンドウでサーバーを再起動する場合などに、この機能は重要な役割を果たします。

さらに、依存管理の観点では「WantedBy」や"After」を使用することで、他の systemd サービスとの順序制御が可能となります。例えば、データベースサービスが起動するまでバックアップを実行しないように設定できます。これは cron のスクリプト内で sleep 系のコマンドで擬似的に実現することも可能ですが、systemd 固有の依存管理はより堅牢です。

以下に、systemd timer の高度機能に関する主なパラメータを整理しました。

• OnBootSec: システム起動後から経過時間を指定
• OnCalendar: 具体的な日付・時刻を指定（自然言語対応）
• Persistent: シャットダウン中のタスクを起動後に実行補完
• RandomizedDelaySec: ランダムな遅延を追加して負荷分散
• AccuracySec: タスクの開始時間の精度を制御
• Unit: 関連する service ユニットを指定

これらの機能を組み合わせることで、cron では不可能な複雑なスケジューリングも実現可能です。例えば、「システム起動後 30 分以内に実行し、かつランダムに最大 15 分遅延させる」ような条件は、OnBootSec=30min と RandomizedDelaySec=15min を併用することで容易に記述できます。

また、2026 年に向けたシステム設計においては、これらの機能を活用して「自己修復型」の定期タスクを構築することが可能です。例えば、バックアップが失敗した場合、systemd のリトライ機能と組み合わせることで、自動的に再試行を行う設定も可能です。これにより、人的介入なしでシステムの健全性を維持するインフラ基盤の構築が可能となります。

ログ管理の違いとトラブルシューティング手法

cron と systemd timer を使い分ける際、重要な判断基準の一つが「ログ管理の仕組み」です。システム全体の監視や障害対応において、ログがどのように記録され、どこから取得できるかは、管理者の作業効率に直結します。cron は伝統的に syslog デーモン（rsyslog や syslog-ng）経由でログを出力し、システム全体のパラメータ設定ファイル /etc/rsyslog.conf などで管理されます。一方、systemd timer は systemd-journald を介してログを記録し、コマンドラインツール journalctl で一元管理します。

cron のログは通常 /var/log/syslog や /var/log/cron に記録されます。しかし、これは syslog デーモンに依存するため、設定ファイルの編集や権限の設定が誤っているとログが出力されない可能性があります。また、ユーザーごとの cron ログは個別に管理される場合があり、特定のタスクの履歴を特定しにくいという側面があります。トラブルシューティングの際には、まず grep コマンドで該当ログを検索することから始めます。

sudo grep CRON /var/log/syslog

このコマンドにより、cron デーモンの実行記録を確認できます。しかし、systemd timer の場合は journalctl を使用することで、より詳細かつ構造化された情報を取得できます。例えば、特定の timer ユニットのログをフィルタリングするには以下のようにします。

• 該当ユニットの履歴確認: sudo journalctl -u mytimer.timer
• 実行された service のログ確認: sudo journalctl -u mytask.service
• リアルタイム監視: sudo journalctl -f -u mytimer.timer

systemd timer のログ管理は、journalctl を介して日時や優先度（info, warning, error）ごとに整理されるため、エラー発生時の原因特定が容易です。特に systemd 255 や 256 では、ログの構造化データ（JSON など）の出力もサポートされており、外部の監視ツールとの連携がスムーズです。

トラブルシューティングの手順として、以下のステップを推奨します。

1. 状態確認: systemctl status <timer>.timer で現在のステータスを確認
2. 直近の実行履歴: systemctl timer-list または journalctl -u <timer> で実行時刻を確認
3. エラーログ解析: journalctl -u <service> --since "1 hour ago" で直近の失敗ログを検索
4. パーミッション確認: ユーザーやファイルへの権限が正しいか確認

これにより、cron の場合よりも早く問題点に切り込めます。また、systemd timer は OnCalendar の構文エラーがあった場合、起動時に警告を出力するため、設定ミスにも早期に対応可能です。

ただし、ログの保存期間については systemd-journald の設定ファイル /etc/systemd/journald.conf で管理されます。ディスク容量が枯渇しないよう、適切なローテーション設定が必要です。一方、cron のログは syslog の設定で管理されるため、両者のバランスを考慮した設定が求められます。2025 年以降の運用では、これらログの可視化を自動化し、異常検知に繋げるシステム構築も一般的となっています。

anacron との関連性および大規模移行ガイド

「anacron」は、cron の欠点を補完するために設計されたツールです。特に、PC やノートパソコンのように常時稼働していない環境や、メンテナンスでシャットダウンされる期間があるサーバーにおいて重要です。cron はシステム停止中に落ちたタスクを逃しますが、anacron はそれを記憶し、次回の起動時に実行します。この機能は、デスクトップ Linux のユーザーや、頻繁に再起動するテスト環境では必須の機能と言えます。

anacron を使用すると、ファイル /etc/anacrontab に設定を行います。これは cron の構文と似ていますが、日付フィールドに @daily, @weekly, @monthly などの記述が標準的に対応しています。また、ランダム遅延（RANDOM_DELAY）のデフォルト値も設定されており、多数の anacron タスクが同時に起動するのを防ぎます。

cron から systemd timer への移行は、レガシーなシステムを現代的な環境へアップデートする際に頻繁に発生します。この移行においては、単なる構文変更だけでなく、ログ管理や権限設定の変更も伴います。以下の移行ガイドを参考にしてください。

• ステップ 1: 既存の cron 設定を抽出し、crontab -l で確認
• ステップ 2: cron のスケジュールを systemd timer の OnCalendar 形式に変換
• ステップ 3: 実行スクリプトを systemd service ユニットに定義
• ステップ 4: ログ出力先を syslog から journal に統一
• ステップ 5: 依存関係（After, Wants）を設定し、起動順序を制御

移行プロセスでは、並行して両方のシステムを動作させる期間を設け、ログの整合性を確認することが重要です。特に、/var/spool/cron ディレクトリ内の設定は、systemd timer のユニットファイル作成後に削除または非有効化します。これにより、二重実行や競合状態を防げます。

ただし、anacron の移行においては注意が必要です。anacron は特定のユーザー（通常 root）のみで動作し、システム起動時に処理を実行する設計です。systemd timer を使用すれば、この機能は Persistent=true と同等の効果が得られるため、anacron 自体の使用を減らすことも可能です。しかし、既存の anacron スクリプトが複雑なロジックを持っている場合は、一旦 systemd 側で再実装を検討します。

2026 年時点での Linux インフラでは、anacron を使わずに systemd timer の機能だけでカバーすることが推奨される傾向にあります。これにより、管理コストを削減し、システム全体の整合性を高めることができます。特に Ubuntu 24.04 LTS や Fedora 41 では、systemd のロジックが強化されているため、移行後のパフォーマンスも期待できます。

cron と systemd timer の徹底比較表

ここで、cron と systemd timer を包括的に比較する表を提示します。この比較は、システム管理者や開発者が自社の環境に最適なツールを選択するための基準となります。機能の多さだけでなく、学習コストや運用負荷といった観点からも評価を行います。

1. 基本機能と設定難易度

この表から、cron はシンプルで直感的である一方、systemd timer は設定項目が豊富で構造的であると読み取れます。初心者には cron が扱いやすいですが、中級者以上は systemd timer の柔軟性を活用できます。

2. 機能比較と運用特性

この比較表は、運用上の違いを明確に示しています。特にログ管理の統一性や、シャットダウン補完機能の有無は、システム安定性を担保する上で重要な判断材料です。

3. セキュリティと権限制御

systemd timer は、環境変数の管理やユーザー権限の指定においてより細かく制御が可能です。これにより、セキュリティポリシーに準拠したタスク実行が容易になります。

4. 今後のサポートと互換性

2025 年以降の Linux ディストリビューションでは、systemd timer がデフォルト推奨となるケースが増えています。特に、新しいディストリビューションでの新規プロジェクトでは systemd timer の採用が有利です。

2026 年時点での最適解選び方とユースケース別推奨案

2026 年に向けて Linux システムを運用する際、cron と systemd timer をどう使い分けるべきかという問いは、環境の特性によって答えが変わります。ここでは、具体的なユースケース別に最適な選択を提案します。単にどちらが優れているかではなく、「どの状況でどちらを使うのが最も効率的か」を考えることが重要です。

まず、「シンプルで即座に動かしたい場合」には cron が推奨されます。特に、システム起動時の初期設定や、ネットワーク依存の少ないスクリプトを実行する場合です。また、既存のレガシーシステムを維持・保守する際にも、cron の変更リスクは低く抑えられます。例えば、特定のサードパーティ製バックアップツールが cron でのみ動作するように設計されている場合、無理に systemd timer に移行する必要はありません。

次に、「システム全体の統合と監視が重要な場合」には systemd timer が最適解です。特に、ログを syslog ではなく journal で一元管理したい場合や、他のサービスとの依存関係を明確に定義したい場合に有効です。例えば、「データベース起動後にバックアップを実行する」ようなタスクは、systemd の After=database.service を使用することで、より堅牢な実装が可能です。また、ログ分析ツールが systemd journal と連携している環境では、その方が運用コストを下げられます。

ユースケース別推奨リスト

• 単発のバックアップスクリプト: cron（@daily 利用）
• 複雑な依存関係があるタスク: systemd timer
• システム起動時の初期化: cron（@reboot）または systemd timer（OnBootSec）
• ログ集中管理が必要な環境: systemd timer
• シャットダウン補完必須: systemd timer（Persistent=true）または anacron
• クラウドサーバーの負荷分散: systemd timer（RandomizedDelaySec 活用）
• スクリプト実行時間の制御: cron（flock 利用）または systemd timer（ExecStartPre 等）

このように、タスクの複雑さや環境要件によって選択は変わります。また、Ubuntu 24.04 LTS や Debian 12 のような最新ディストリビューションでは、systemd のバージョンが比較的新しく、timer の機能も安定しているため、積極的に systemd timer を採用する傾向にあります。

さらに、「混合運用」という選択肢もあります。すべてのタスクを systemd timer に移行せず、重要なシステムタスクのみを移行し、単純な定期タスクは cron で維持するという手法です。これにより、移行リスクを抑えつつ、メリットの大きい部分から改善できます。2026 年時点では、このようなハイブリッド運用も十分に許容される範囲内ですが、将来的には systemd timer への完全移行が主流となる見込みです。

最後に、「学習コスト」についても考慮する必要があります。systemd の理解にはある程度の知識が必要ですが、その分、システム管理のスキル向上にもつながります。若手エンジニアや新規プロジェクトでは、systemd timer を基準に設計を進めることで、将来的な技術負債を減らすことができます。

よくある質問（FAQ）

Q1. cron と systemd timer の両方を同時に使うことは可能ですか？ はい、可能です。ただし、同じタスクを重複して実行しないように注意が必要です。一般的には、片方のみを使用することを推奨しますが、移行期間中などは両立させることがあります。設定ファイルの管理を分けることで混乱を防げます。

Q2. systemd timer を使う場合、cron デーモンは停止すべきですか？ 必ずしも停止する必要はありませんが、システムリソースの節約と管理コスト削減のために、使用しない場合は無効化（disable）するのが推奨されます。Ubuntu 24.04 では cron はデフォルトで有効なため、手動で調整することがあります。

Q3. @reboot の機能は systemd timer でも実現できますか？ はい、OnBootSec=0 または Unit.file で WantedBy= を設定することで実現可能です。systemd timer ではより柔軟に起動後の遅延制御を行えるため、cron よりも優れている場合があります。

Q4. cron のログはどこで確認できますか？ 通常 /var/log/syslog または /var/log/cron で確認できます。システムによってファイルパスが異なる場合があるため、rsyslog の設定を確認してください。systemd timer は journalctl -u <name> で確認します。

Q5. systemd timer は Linux カーネルのバージョンに依存しますか？ systemd デーモンのバージョンに依存します。U[bun](/glossary/bun-runtime)tu 24.04 LTS（systemd 255）や [Fedora](/glossary/dora-fine-tuning) 41（systemd 256）など、比較的最近のディストリビューションであれば問題なく動作します。古い Linux では機能制限がある可能性があります。

Q6. cron のロックファイル（flock）は systemd timer でも使えますか？ はい、可能です。ExecStartPre に flock を記述して実行前処理として使用できます。また、systemd には RuntimeMaxSecs で実行制限をかける機能もあるため、代替手段も用意されています。

Q7. anacron は systemd timer のどの機能に相当しますか？ anacron の「シャットダウン中のタスク補完」は、systemd timer の Persistent=true に相当します。ただし、anacron はユーザーレベルで動作するスクリプトを管理する仕組みであるため、完全に 1:1 で置き換えられるとは限りません。

**Q8. cron を systemd timer に移行する際、最も気をつけるべき点は？ ログ出力先と権限設定です。cron のログは syslog ですが、systemd は journal です。また、cron では /etc/crontab 内のユーザー指定が重要ですが、systemd では User= 属性で管理するため、設定ファイルを注意深く変更する必要があります。

Q9. systemd timer のエラーが発生した場合はどうすればよいですか？ まず journalctl -u <timer>.timer でログを確認し、OnCalendar や Unit の記述ミスがないか検証します。また、依存する service ファイルが有効化されているかも確認してください。

Q10. 2026 年までに cron はサポートされなくなるでしょうか？ 現時点では、POSIX 準拠として永続的にサポートされる見込みです。しかし、新しい機能の開発は systemd timer に集中しており、将来的には systemd timer が標準的になることは間違いありません。

まとめ

本記事を通じて、Linux の定期タスク管理における cron と systemd timer の違いと、それぞれの適切な使い分けについて解説しました。両者は競合するのではなく、それぞれが持つ特性を活かして運用することが重要です。

• cron はシンプルでレガシー対応に強く、学習コストの低いツールです。
• systemd timer はモダンな Linux システム向けで、ログ管理や依存制御に優れています。
• 2025 年以降 の最新環境では、systemd timer の採用が推奨されるケースが増えています。
• anacron はシャットダウン補完が必要な場合に考慮すべき要素です。
• ログ管理 では syslog（cron）と journal（systemd）の違いを理解することが重要です。

最終的には、運用するシステムの規模や既存環境の状況に合わせて最適な選択を行う必要があります。しかし、2026 年に向けた長期的な視点では、systemd timer を活用したモダンなインフラ設計が推奨されます。