Conductor：マイクロサービスのワークフロー自動化を統合管理するOSSプラットフォーム

Conductor Oss Conductor

⚙️ DevOps & 自動化 agents automation

2026.03.31 1分

Conductor：マイクロサービスのワークフロー自動化を統合管理するOSSプラットフォーム - AIツール日本語解説 | AI Heartland

分散システムにおけるタスク実行の複雑性を軽減し、統一されたワークフロー定義で複数サービス間の連携を効率化。可視化とエラー対応の自動化を実現する。

この記事ではAIエージェントに特化して解説します。AIエージェント全般は AIエージェントフレームワーク比較2026年版をご覧ください。

概要

Conductorは、分散マイクロサービス環境におけるワークフロー実行を統一的に管理するOSSプラットフォーム。複数のサービスを跨ぐタスク実行の流れを定義・実行・監視し、エラー時の自動リトライや状態追跡を提供する。大規模分散システムでのタスク調整の複雑性を軽減することを目的として開発され、GitHubで31,000以上のスターを獲得している実績あるOSSだ。

Netflixが社内で開発・運用したシステムをOSS化したことで広まり、金融・eコマース・SaaS領域での採用実績がある。現在はconductor-oss組織がコミュニティ主体でメンテナンスを続けている。

データパイプライン系ツールとの違いが気になる場合は、Prefectのワークフロー管理解説記事も合わせて参照すると判断基準が整理できる。

Conductorのワークフロー実行フロー

sequenceDiagram participant C as クライアント
（REST API） participant S as Conductor Server participant Q as タスクキュー participant W1 as ワーカー1
（サービスA） participant W2 as ワーカー2
（サービスB） participant DB as データストア
（PostgreSQL） C->>S: ワークフロー起動リクエスト S->>DB: ワークフロー状態を保存 S->>Q: タスク1をエンキュー W1->>Q: ポーリング（タスク取得） Q-->>W1: タスク1を返却 W1->>W1: タスク実行 W1->>S: 実行結果を報告 S->>DB: 状態更新 S->>Q: タスク2をエンキュー W2->>Q: ポーリング（タスク取得） Q-->>W2: タスク2を返却 W2->>W2: タスク実行 W2->>S: 実行結果を報告 S->>DB: ワークフロー完了を記録 S-->>C: 完了通知

このシーケンス図が示す通り、ワーカーは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
    }
  ]
}

Conductorのワークフロー定義で押さえるポイント `taskReferenceName` はワークフロー内でタスクを一意に識別する名前で、入出力パラメータの参照に使われる。`${validate_order_ref.output.orderId}` のように後続タスクから参照できるため、命名は短く一貫性のある形式にしておくとデバッグが楽になる。`retryCount` と `timeoutSeconds` は本番稼働前に実際のサービスの応答時間を計測して設定すること。デフォルト値のままにするとタイムアウトエラーが頻発する原因になる。

競合との違い

Apache Airflow はデータパイプラインとバッチワークフロー向けのDAG中心設計であり、Conductorとは主要な対象ユースケースが異なる。頻繁に呼び出されるリアルタイムなマイクロサービス間連携にはConductorが適している。

比較軸	Conductor	Apache Airflow	Temporal	Prefect
主な用途	マイクロサービス連携	データパイプライン	分散トランザクション	データワークフロー
タスク粒度	小〜中	中〜大	小	中〜大
実行モデル	プル型ワーカー	スケジューラ型	コードベース	コードベース
オンプレミス適性	高	高	中	中
リアルタイム性	高	低	高	中

Temporal は分散トランザクション管理とアクティビティの信頼性に重点を置き、状態機械の確実な実行保証が強み。一方Conductorはワーカーのステートレスなポーリングモデルにより水平スケーリングが容易な設計となっている。

Prefect はモダンなデータワークフロー管理で、ダイナミックワークフローとクラウド統合が特徴。Pythonで完結するパイプライン構築ではPrefectの方が開発体験が優れている場面も多い。

こんな人におすすめ

Conductorの導入効果が出やすい環境 マイクロサービスを複数運用する開発チーム
サービス間のワークフロー連携を一元管理し、障害時のトレーシングを統一できるプラットフォームが必要な環境。複数チームが並行して独立したサービスを開発・デプロイしているような組織では、ワークフローの可視化だけでも運用コストが大幅に下がる。 分散システムの保守・運用を自動化したいエンジニア
手動でのサービス間調整を減らし、エラーリトライやタイムアウト管理を自動化したい要件。特に注文処理・決済フローのような「一部失敗時に全体を巻き戻したい」ケースでのエラーハンドリング自動化に効果的。 リアルタイム性が求められるタスク管理が必要なプロダクト開発者
バッチ処理ではなく、リクエストに応じたワークフロー実行が頻繁に起こるシステム。eコマース・金融・SaaSのような即時性が求められるドメインで採用実績がある。

実装の現実的な検討ポイント

Conductorはワークフロー層のオーケストレーションに特化しており、個々のマイクロサービス開発の負担軽減は行わない。既存のHTTP APIやメッセージキューに対応するワーカーの実装は別途必要。データベースなどの外部依存も多いため、運用負荷を見積もる際は監視・バックアップ体制の整備を含めて計画することが重要だ。

成熟したOSSプロジェクトとして金融・eコマース等の大規模企業での採用実績がある。導入前にコミュニティの活発性や自社システムへの適合性を十分検証することが推奨される。