コマンドワークフロー
重いプラットフォームを導入せずに本番ワークフローを動かす。
Dagu は、シェルスクリプト、コンテナ、SSH タスク、HTTP 呼び出し、エージェント CLI を、リトライ、ログ、キュー、Web UI 付きの YAML ワークフローに変えます。
コマンドワークフローはここまで小さくできる
name: nightly-ops
schedule: "0 2 * * *"
steps:
- id: extract
run: python scripts/extract.py
- id: transform
run: ./bin/transform
retry_policy:
limit: 3
depends: [extract]
- id: notify
run: ./scripts/slack-success.sh
depends: [transform]セルフホストの単一バイナリ
外部 DB やブローカー不要
Git で読みやすい YAML
ローカル、キュー、分散実行に対応
一目で比較
Dagu が選ばれる理由
デプロイ
Dagu
単一バイナリとローカルファイルで開始。
一般的な代替手段
DB、ブローカー、Web サーバー、スケジューラが必要になりがち。
ワークフロー記述
Dagu
普段のコマンドを YAML から呼ぶ。
一般的な代替手段
専用 SDK やフレームワークへの書き換えが必要なことが多い。
導入のしやすさ
Dagu
1 本のスクリプトから段階的に始められる。
一般的な代替手段
価値が出る前に大きな移行が必要になりやすい。
詳細
それぞれの強みと向き不向き
運用の現場にちょうどいい設計
多くのチームに必要なのは巨大なデータ基盤ではなく、依存関係、リトライ、出力の取得、履歴、失敗した処理の再実行です。
- 既存スクリプトをそのままスケジュールできる
- 定義は YAML なのでレビューしやすい
- 必要になるまで 1 台で始められる
小さなランタイムで必要な制御を持つ
Dagu は運用負荷を小さく保ちながら、ジョブが重要になったときに必要な制御を備えます。
- リトライ、依存関係、タイムアウト、ログ、履歴
- 確認と手動実行のための Web UI
- コマンド、Docker、HTTP、SSH、SubDAG、エージェントを実行
AI エージェントの実行にも自然に合う
AI エージェントは最終的にコマンドとして動きます。Dagu はその周囲にスケジュール、依存関係、リトライ、監査性を与えます。
- Claude、Codex、Gemini などをワークフローステップとして実行
- 承認や検証をエージェント出力の前後に置ける
- モデルを変えてもオーケストレーション層はそのまま
FAQ
Dagu を導入する前によくある質問
Dagu が軽量と言われる理由は何ですか？
Dagu は単一のセルフホスト型バイナリとして動作し、状態をローカルファイルに保存します。開始時に DB、ブローカー、別のコントロールプレーンは不要です。
既存のスクリプトはそのまま使えますか？
はい。シェル、バイナリ、Docker、HTTP、SSH などをそのままステップとして実行でき、アプリケーションの作り直しは不要です。
ローカル実行専用ですか？
いいえ。ローカルから始めて、キュー実行や coordinator-worker 構成へ拡張できます。
次の一歩
まず 1 つのワークフローから。
Dagu をインストールし、不安定なスクリプトやエージェントタスクを 1 つ YAML に移して、実際の実行履歴を見て判断できます。