この記事ではAIエージェントに特化して解説します。AIエージェント全般は AIエージェントフレームワーク比較2026年版 をご覧ください。
概要
Conductorは、分散マイクロサービス環境におけるワークフロー実行を統一的に管理するOSSプラットフォーム。複数のサービスを跨ぐタスク実行の流れを定義・実行・監視し、エラー時の自動リトライや状態追跡を提供する。大規模分散システムでのタスク調整の複雑性を軽減することを目的として開発され、GitHubで31,000以上のスターを獲得している実績あるOSSだ。
Netflixが社内で開発・運用したシステムをOSS化したことで広まり、金融・eコマース・SaaS領域での採用実績がある。現在はconductor-oss組織がコミュニティ主体でメンテナンスを続けている。
データパイプライン系ツールとの違いが気になる場合は、Prefectのワークフロー管理解説記事も合わせて参照すると判断基準が整理できる。
Conductorのワークフロー実行フロー
このシーケンス図が示す通り、ワーカーはConductorサーバーをポーリングしてタスクを取得する「プル型」アーキテクチャを採用しており、ワーカー側からサーバーへの接続設定だけで済むため、既存マイクロサービスへの組み込みが容易だ。
主な機能
- ワークフロー定義と実行管理：JSON形式でワークフローを定義し、複数のマイクロサービスにまたがるタスク実行を順次または並列で制御
- 状態追跡と可視化：実行中のワークフローの進捗をリアルタイムで監視し、各タスクの実行状態をダッシュボードで確認
- エラーハンドリングと自動リトライ：タスク失敗時の自動リトライ、フォールバック処理、タイムアウト管理を内蔵
- タスク キューイング：実行待ちのタスクをキューで管理し、ワーカープロセスが必要に応じてポーリングして処理
- 動的ワークフロー：実行時に条件分岐やループ、判定結果に基づく動的なタスク追加が可能
- レート制限と優先度制御：タスク実行の頻度や優先順位をカスタマイズして負荷を調整
- 外部システムとの連携：HTTPコール、データベースクエリ、メッセージキュー等への直接呼び出しをサポート
技術スタック
- 言語：Java（バックエンド）
- フレームワーク：Spring Boot（コアサービス）
- データストア：Elasticsearch（ワークフロー履歴の検索）、PostgreSQL/MySQL（メタデータ管理）
- コンテナ化：Docker対応、Kubernetes環境で運用可能
導入方法
CLIを使用した起動
npm install -g @conductor-oss/conductor-cli
conductor server start
このコマンドでConductorサーバーと組み込みUIが起動される。UIは http://localhost:8080 でアクセス可能。
Dockerを使用した起動
docker run -p 8080:8080 conductoross/conductor:latest
このコマンドでConductorサーバーと組み込みUIが起動される。
ワークフロー定義のJSON例
タスク定義とワークフロー定義はREST APIで登録する。以下はシンプルな2タスクのワークフロー定義の例：
{
"name": "order_processing_workflow",
"version": 1,
"tasks": [
{
"name": "validate_order",
"taskReferenceName": "validate_order_ref",
"type": "SIMPLE",
"retryCount": 3,
"timeoutSeconds": 30
},
{
"name": "charge_payment",
"taskReferenceName": "charge_payment_ref",
"type": "SIMPLE",
"retryCount": 2,
"timeoutSeconds": 60
}
]
}
taskReferenceName はワークフロー内でタスクを一意に識別する名前で、入出力パラメータの参照に使われる。${validate_order_ref.output.orderId} のように後続タスクから参照できるため、命名は短く一貫性のある形式にしておくとデバッグが楽になる。retryCount と timeoutSeconds は本番稼働前に実際のサービスの応答時間を計測して設定すること。デフォルト値のままにするとタイムアウトエラーが頻発する原因になる。
競合との違い
Apache Airflow はデータパイプラインとバッチワークフロー向けのDAG中心設計であり、Conductorとは主要な対象ユースケースが異なる。頻繁に呼び出されるリアルタイムなマイクロサービス間連携にはConductorが適している。
| 比較軸 | Conductor | Apache Airflow | Temporal | Prefect |
|---|---|---|---|---|
| 主な用途 | マイクロサービス連携 | データパイプライン | 分散トランザクション | データワークフロー |
| タスク粒度 | 小〜中 | 中〜大 | 小 | 中〜大 |
| 実行モデル | プル型ワーカー | スケジューラ型 | コードベース | コードベース |
| オンプレミス適性 | 高 | 高 | 中 | 中 |
| リアルタイム性 | 高 | 低 | 高 | 中 |
Temporal は分散トランザクション管理とアクティビティの信頼性に重点を置き、状態機械の確実な実行保証が強み。一方Conductorはワーカーのステートレスなポーリングモデルにより水平スケーリングが容易な設計となっている。
Prefect はモダンなデータワークフロー管理で、ダイナミックワークフローとクラウド統合が特徴。Pythonで完結するパイプライン構築ではPrefectの方が開発体験が優れている場面も多い。
こんな人におすすめ
サービス間のワークフロー連携を一元管理し、障害時のトレーシングを統一できるプラットフォームが必要な環境。複数チームが並行して独立したサービスを開発・デプロイしているような組織では、ワークフローの可視化だけでも運用コストが大幅に下がる。 分散システムの保守・運用を自動化したいエンジニア
手動でのサービス間調整を減らし、エラーリトライやタイムアウト管理を自動化したい要件。特に注文処理・決済フローのような「一部失敗時に全体を巻き戻したい」ケースでのエラーハンドリング自動化に効果的。 リアルタイム性が求められるタスク管理が必要なプロダクト開発者
バッチ処理ではなく、リクエストに応じたワークフロー実行が頻繁に起こるシステム。eコマース・金融・SaaSのような即時性が求められるドメインで採用実績がある。
実装の現実的な検討ポイント
Conductorはワークフロー層のオーケストレーションに特化しており、個々のマイクロサービス開発の負担軽減は行わない。既存のHTTP APIやメッセージキューに対応するワーカーの実装は別途必要。データベースなどの外部依存も多いため、運用負荷を見積もる際は監視・バックアップ体制の整備を含めて計画することが重要だ。
成熟したOSSプロジェクトとして金融・eコマース等の大規模企業での採用実績がある。導入前にコミュニティの活発性や自社システムへの適合性を十分検証することが推奨される。
2026-10-11 に実測で確かめ直した
本記事の対象リポジトリを 2026-10-11 に clone して、ライセンスの実体・更新状況・規模を測り直した。 紹介文やバッジではなく、リポジトリの中身を直接読んだ値だ。
# ① 浅く clone する
git clone --depth 1 https://github.com/conductor-oss/conductor /tmp/conductor
# ② 直近のコミット日を見る → 2026-10-08
git -C /tmp/conductor log -1 --format=%ad --date=short
# ③ ライセンスの実体と規模を見る → Apache-2.0 / 4,362 ファイル
head -3 /tmp/conductor/LICENSE* 2>/dev/null; git -C /tmp/conductor ls-files | wc -l
③が肝心で、ライセンスは Apache-2.0だった。バッジや README の記述ではなく LICENSE ファイルの中身を読んでいる。
| 確認項目 | 2026-10-11 の実測 | 確認方法 |
|---|---|---|
| ライセンス | Apache-2.0 | head -3 LICENSE* でファイル本文を読む |
| 直近コミット | 2026-10-08（3日前） | git log -1 --date=short |
| 規模 | 追跡ファイル 4,362 本 | git ls-files \| wc -l |
参照ソース
・conductor-oss/conductor（GitHub） — 本記事が 2026-10-11 に測り直した対象
・LICENSE — ライセンスの実体（手順③で読んだファイル）
・Conductor 公式ドキュメント
・Conductor OSS - 公式サイト
・Netflix Technology Blog - Conductor紹介記事
