Dagu レビュー: オーケストレーションを仕事の中心にしないための単一バイナリ YAML エンジン

cron と Airflow の間にある空白を狙う

Dagu が解こうとしているのは、オーケストレーションそのものが主業務ではないチームの不便さだ。README は cron について「コマンドは実行するが依存関係もリトライも履歴もない」と書き、Airflow については「scheduler、metadata database、worker、Python 環境というプラットフォームを運用することになり、ジョブは @dag/@task のフレームワークコードとして書き直される」と説明している。Temporal には durable execution があるが、ビジネスロジックが SDK とプログラミングモデルの中へ移る、という指摘も添えている。

対象読者は、シェルスクリプトや Docker コンテナ、SSH 越しのコマンドがすでに手元で動いていて、そこにスケジュール、依存関係、リトライ、ログの置き場だけを足したい人だ。Dagu の主張は「ワークフローの構造はコードではなく設定である」という一点に集約される。順序、依存関係、リトライ、スケジュール、人手タスクをスクリプトの隣の YAML 1 枚に置き、実行するエンジンは単一プロセスに保つ。README 曰く「YAML を消せばスクリプトは以前とまったく同じように動く」。この可逆性が採用判断の軸になる。

単一バイナリとファイルベース状態という設計

アーキテクチャの要点は、外部 DBMS もメッセージブローカーも要求しないことだ。README の比較図では、従来型オーケストレータが Web サーバー、スケジューラ、ワーカー、PostgreSQL、Redis や RabbitMQ、Python ランタイムという「6 つ以上の管理対象サービス」を並べるのに対し、Dagu 側は dagu start-all の一行だけが描かれている。状態はローカルファイルに保存され、README はこれを「file-backed state」と呼び、メディア変換のような重い処理をワーカーで並列に流す際に外部データベースなしで済む利点として挙げている。

実行対象は Dagu Actions を通じて広がる。ネイティブに扱えるのはシェルコマンド、Docker コンテナ、Kubernetes Job、SSH 経由のリモートコマンドだ。ワークフローは Sub-DAG として再利用でき、並列実行と同時実行数の制御ができる。スケジューリングは cron 構文にタイムゾーン、重複実行ポリシー、catch-up window を組み合わせる。ログ、実行履歴、リトライ、通知、Webhook トリガーが 1 か所にまとまる。加えて組み込みの MCP サーバーがあり、ワークフローや実行の調査、Wiki ページの管理、変更の適用、実行の制御を行えると README は述べている。

ここで注意したいのは、ファイルベースの状態が単一ノードでは利点でも、複数ノードに広げた瞬間に共有ストレージの設計問題へ変わることだ。README は「ワーカーがマシン間で実行を分散する」と書くが、そのときファイル状態をどう共有するかの具体的な手順は与えられた材料からは読み取れない。スケールアウトを前提にするなら、この点は自分で確かめる必要がある。

インストールと起動、最初の YAML まで

導入経路は複数用意されている。macOS と Linux では curl -fsSL https://raw.githubusercontent.com/dagucloud/dagu/main/scripts/installer.sh | bash、Homebrew なら brew install dagu、npm なら npm install -g --ignore-scripts=false @dagucloud/dagu、Windows の PowerShell では irm https://raw.githubusercontent.com/dagucloud/dagu/main/scripts/installer.ps1 | iex が README に記載されている。

Docker の場合の例は docker run --rm -v ~/.dagu:/var/lib/dagu -p 8080:8080 ghcr.io/dagucloud/dagu:latest dagu start-all だ。ボリュームのマウント先が /var/lib/dagu で、これが状態の保存先になる。README はこのコマンドについて「ホストの Docker デーモンを公開しない」と注記している。つまりコンテナ内からホストの Docker を操作する構成はこの例だけでは完結しない。Docker ステップを本気で使うなら、ソケットのマウントや別の実行形態を自分で設計することになる。

起動は dagu start-all の一語で、これが Web UI とスケジューラをまとめて立ち上げる。README にはデモ環境として https://dagu-demo-f5e33d0e.dagu.sh が案内され、認証情報は demouser / demouser と書かれている。UI には Cockpit と呼ばれる実行一覧、Run Details、Step Logs、Wiki の各画面がある。ワークフロー定義の実例は docs.dagu.sh の examples に置かれていると案内されているが、README 本文には YAML の完全なサンプルは載っていない。構文の詳細はドキュメント側で確認する必要がある。

向かない場面: データ受け渡しと既存 DAG の移行

Dagu が構造を設定として扱う以上、ステップ間で複雑なデータを受け渡す処理は YAML の表現力との勝負になる。Airflow であればタスク間でオブジェクトを渡し、Python の制御構文で分岐を書ける。Dagu の README が示す範囲では、ステップはシェルコマンド、コンテナ、Kubernetes Job、SSH コマンドという実行単位であり、依存関係と並列度は YAML 側で宣言する。動的にタスクを生成するようなパイプラインや、前段の出力を構造化データとして後段に渡す処理が中心なら、YAML に押し込むより既存のオーケストレータのほうが素直だ。

もうひとつの境界は既存資産の移行コストだ。すでに Airflow で運用している DAG があるなら、Dagu へ移す作業は書き直しに近い。README の主張は逆方向、つまり Airflow に移すとジョブが @dag/@task として書き直されるという痛みを出発点にしている。どちらに転んでも、移行は一方向の書き換えを伴う。Dagu が向くのは、まだ cron と手作業で回している段階のチームであり、すでに大規模な DAG 群を抱えているチームではない。

三つ目はスケールの前提だ。README は「1 台で 1 日あたり数千のワークフロー実行」と書きつつ、「実際の容量は CPU、メモリ、ディスク、ワークフローの形に依存する」と留保している。この数字は保証ではなく目安として読むべきで、高頻度の短命ジョブを大量に流す用途では、ファイル状態への書き込みがボトルネックになる可能性を自分で検証する必要がある。

Airflow と Temporal との設計上の違い

比較対象として README が名指しするのは Airflow と Temporal、そして cron だ。Airflow との違いは運用対象の数にある。Airflow は scheduler、metadata database、worker、Web サーバー、Python 環境を別々に運用する。Dagu はそれらを単一プロセスに畳み、状態をファイルに置く。ジョブの書き方も変わる。Airflow ではジョブが Python のフレームワークコードになり、Dagu では実行するスクリプトはそのままで、順序と依存関係だけが YAML に出る。

Temporal との違いは durable execution の置き場所だ。Temporal はビジネスロジックを SDK の中に移すことで耐久性を得る。Dagu はロジックを外に残し、実行の記録とリトライをエンジン側で持つ。トレードオフは明確で、Temporal のほうがプロセスをまたいだ状態復元や長時間実行の扱いは強い。Dagu はその代わりに、既存スクリプトへの侵襲性をゼロに近づけている。

cron との違いは機能の有無そのものだ。cron には依存関係もリトライも履歴もない。Dagu はそこに DAG、リトライ、実行履歴、Web UI、通知、Webhook トリガーを足す。cron の置き換えとしては素直だが、cron が動いていた環境の権限やログ収集の仕組みは別途引き継ぐ必要がある。

MCP サーバーと人手タスクという最近の拡張

README は組み込みの MCP サーバーを挙げ、ワークフローや実行の調査、Wiki ページの維持、変更の適用、実行の制御ができると説明している。リポジトリのトピックにも mcp、mcp-server、mcp-gateway、ai-agents、human-in-the-loop が並ぶ。ここから読み取れるのは、Dagu が単なる cron 代替から、エージェントや人手承認をワークフローに組み込む方向へ機能を広げているということだ。

ただし、与えられた材料には MCP サーバーの具体的な設定方法やプロトコルの詳細は含まれていない。ツール名、認証方式、どの操作がどの権限で実行されるのかは README からは分からない。エージェントから実行を制御できるという性質は、裏を返せばワークフロー実行の権限管理が新しい論点になることを意味する。この機能を採用の決め手にするなら、ドキュメント側で権限モデルを確認してからにすべきだ。

人手タスクも同様で、README は機能として名前を挙げるが、承認フローの定義方法やタイムアウトの扱いは本文には書かれていない。機能の存在と、運用に耐える設計かどうかは別の話である。

ライセンスとメンテナンスの見え方

ライセンスは GPL-3.0 だ。これは寛容ライセンスではなくコピーレフトであり、Dagu を組み込んだ配布物の扱いに影響しうる。社内利用に留めるのか、顧客に配布する製品に同梱するのかで条件が変わる。ここでは法的助言はできないので、配布形態が決まっているなら法務の確認を先に通すべきだ。特に、Dagu を呼び出すだけの別プロセスとして使うのか、バイナリを同梱するのかで結論が変わりやすい。

メンテナンスの活発さについては、リポジトリ情報からは v2.16.3 が 2026-09-09 に、helm-dagu-2.0.4 が同日に、v2.16.2 が 2026-09-02 にリリースされていることが読み取れる。Helm チャートが本体と別のバージョン系列で管理されている点は、Kubernetes に載せる際にチャートとアプリのバージョン対応を確認する手間が生じることを示す。

アップグレードのコストは、状態がファイルベースであることと無関係ではない。バージョン間でファイル形式やディレクトリ構成が変わる場合、単一バイナリを差し替えるだけでは済まない可能性がある。README には移行手順の記載がないため、アップグレード前にリリースノートとドキュメントを確認する必要がある。運用対象が少ないことは導入の利点だが、その分だけ状態の互換性は自分で追うことになる。

編集部の結論

既存のスクリプトや runbook がすでに動いていて、cron では依存関係・リトライ・履歴が足りないチームには Dagu が向く。Airflow の DAG をすでに運用している、あるいはステップ間でデータを渡す複雑なパイプラインを Python で書きたいチームには向かない。導入前に確認すべきは、GPL-3.0 の下で自社の配布形態がどう扱われるか、そしてワーカーを複数ノードに広げたときにファイルベースの状態がどこまで耐えるかだ。まずは dagu start-all を 1 台で動かし、既存スクリプトを 1 本 YAML に移して、失敗時のリトライとログが期待どおり残るかを自分の環境で確かめるのが最初の一歩になる。

公式情報源

1. dagucloud/dagu on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases