필사 모드: ワークフローエンジン2026 — Temporal・Inngest・Trigger.dev・Hatchet・Restate・DBOS・Airflow徹底比較(Durable Execution時代の地図)

プロローグ — なぜワークフローはtier-1インフラに戻ってきたか

2018年頃のワークフローエンジンは「データチームがcronの代替に使うAirflow」程度の扱いだった。バックエンドエンジニアが毎日眺める単語ではなかった。2026年5月の今、同じカテゴリが突然すべてのバックエンドチームのtier-1インフラに昇格した。理由は単純で — **AIエージェントがlong-running operationを既定にしてしまったからだ。**

LLM呼び出し1回が5秒で済んでいた時代は終わった。エージェントはツールを6回呼び、ユーザー承認を待ち、次のステップに進む前に別システムから結果をポーリングする。1サイクルが30秒、5分、場合によっては2時間。同時にretry・idempotency・replayがオプションではなく必須になる。モデルは1%の確率でthrowし、OpenAIとAnthropicのAPIは時々429を返し、ユーザーはその間にタブを閉じる。だから**「long-running・resumable・idempotent」という3条件を1度に解いてくれる**道具がそのままワークフローエンジンであり、2026年に再びこのカテゴリが核に戻ってきた。

この記事は2026年5月時点のワークフローエンジン12個 — Temporal・Inngest・Trigger.dev・Hatchet・Restate・DBOS・Cadence・Airflow・Prefect・Dagster・Argo・Conductor — の地図を一度に描く。何が同じで何が違うのか、AIエージェント・決済・ETL・オンボーディングという代表的ワークロードでそれぞれ何を選ぶべきか、そして韓国と日本の現場は何を動かしているのか。

第1章 · 2026年のワークフローエンジン地図

まず1行サマリー。**ワークフローエンジンは2つの陣営に分かれた。** 一方はバックエンドビジネスロジック陣営 — Temporal・Inngest・Trigger.dev・Hatchet・Restate・DBOS・Cadence・Conductor。もう一方はデータエンジニアリング陣営 — Airflow・Prefect・Dagster・Argo。両陣営とも「DAG実行」という概念は共有するが、主要ユーザー、インターフェース、運用モデルは大きく違う。

2026年5月時点の座標。

| エンジン | 陣営 | コアモデル | バックエンド | 主要SDK | ライセンス |

| --- | --- | --- | --- | --- | --- |

| Temporal | ビジネスロジック | Workflow as code・Event Sourcing | Cassandra・Postgres・MySQL・SQLite | Go・Java・TS・Python・.NET・PHP・Ruby | MIT |

| Inngest | ビジネスロジック | Event-driven・サーバーレス親和 | 自前 | TypeScript・Python・Go | Source Available |

| Trigger.dev v3 | ビジネスロジック | Task as code・Vercel風DX | Postgres・自前 | TypeScript | Apache 2.0 |

| Hatchet | ビジネスロジック | Postgresベースキュー + ワークフロー | Postgres | TypeScript・Python・Go | MIT |

| Restate | ビジネスロジック | Virtual Objects・決定論的実行 | 自前(Rust) | TypeScript・Java・Kotlin・Go・Rust・Python | BSL → Apache 2.0(4年後) |

| DBOS | ビジネスロジック | DB内蔵control plane | Postgres | TypeScript・Python | MIT |

| Cadence | ビジネスロジック | Temporal祖先 | Cassandra・MySQL | Go・Java | Apache 2.0 |

| Conductor(Orkes) | ビジネスロジック | JSON DSL・マイクロサービスorchestration | Redis・Cassandra・Postgres | 多言語HTTP | Apache 2.0 |

| Airflow 3 | データエンジニアリング | Python DAG・scheduler分離 | Postgres・MySQL | Python | Apache 2.0 |

| Prefect 3 | データエンジニアリング | Pythonicフロー・動的DAG | Postgres・SQLite | Python | Apache 2.0 |

| Dagster 1.10 | データエンジニアリング | Asset中心(DAGではなくasset) | Postgres・SQLite | Python | Apache 2.0 |

| Argo Workflows | データエンジニアリング | k8sネイティブ・YAML/CRD | etcd(k8s) | YAML・Python | Apache 2.0 |

主要な洞察3つ。

第一に、**ビジネスロジック陣営の爆発の方が大きい。** AIエージェント・決済・オンボーディング・サブスクリプションのようなlong-runningバックエンドロジックは、以前はBullMQやSQS + Lambdaのようなキューで解いてきたが、2024〜2026年にこのパターン自体が脆すぎるという合意が固まった。だからTemporal・Inngest・Trigger.dev・Hatchet・Restate・DBOSが一気に立ち上がった。

第二に、**データエンジニアリング陣営は安定期だ。** Airflowは2024年10月にAirflow 3.0が出てscheduler・executor分離を仕上げ、Prefectは3.0(2024 Q3)でdynamic DAGの決定版を出し、Dagsterはasset(資産)モデルで差別化を完成させた。新規参入がないわけではなく、カテゴリ内のポジションがほぼ固まったということだ。

第三に、**「Workflow as code」が標準的なデザインパターンになった。** 2018年のワークフローはJSON・YAML・ビジュアルエディタで定義されていた(Step Functions・Airflow DSL・Conductor JSON)。2026年のワークフローはGo・TS・Pythonコードで定義される。理由は単純で — IDEサポート・型安全性・テストの容易さ・diff可読性・コードレビューがすべて動くからだ。JSON DSLを残すConductorのような道具でさえSDKレイヤーを並走させる。

第2章 · Durable Executionとは — 再起動・再試行・冪等性・replay

エンジン比較に入る前に、このカテゴリをくくる単語 — **durable execution** — を解いておこう。短く定義すれば「ワークフローのすべての進行状態が外部ストレージに永続化されていて、プロセスが死んで蘇っても止まった場所から正確に続行する実行モデル」だ。この定義から導かれる4つの性質。

1. **再起動(crash resumption)** — workerプロセスがOOMで死んだりホストが再起動しても、新しいworkerが永続化されたイベントログを読み、同じワークフローを継続する。

2. **再試行(retries)** — ワークフロー内の各ステップ(activity・task)は失敗時に自動でretryされる。backoff・max attempts・timeoutは宣言的に設定される。

3. **冪等性(idempotency)** — 1つのワークフロー実行IDに対し、同じactivityが重複実行されても結果は同じであることが保証される。通常はワークフローID + step IDの組が冪等キーになる。

4. **再現(replay)** — ワークフローコードは決定論的(deterministic)でなければならない。同じイベントログを再生すれば同じ判断を下さねばならない。だからワークフロー内で`Math.random()`や`new Date()`を直接呼ばず、SDKが提供する決定論的バージョンを使う。

なぜこれが重要か。一般的なキュー + workerモデル(BullMQ・Sidekiq・SQS + Lambda・RabbitMQ)を思い浮かべよう。「ユーザー登録 → ウェルカムメール送信 → Stripe顧客作成 → Salesforce同期」という4ステップのオンボーディングワークフローを書くとする。事実上すべてのバックエンドチームがこのパターンを手書きしてきた。キューを4つ作り、各workerが次のステップにメッセージを投げ、失敗時はDLQに送り、運用者がDLQを覗いてreprocessする。動くが毎回作り直す。そして毎回同じバグに出会う。

- 「Stripe顧客は作成できたがSalesforce同期直前にworkerが死んだ — どこから再開する?」

- 「メールが2回送信された — 重複処理をどう防ぐ?」

- 「ワークフローIDごとの進行状態をどう可視化する?」

- 「オンボーディングが5ステップに増えたが、既存のin-flightワークフローはどのバージョンで終わらせる?」

Durable executionエンジンはこれをライブラリ・プラットフォームレイヤーで一気に解いてくれる。だから決済・オンボーディング・サブスクリプション・AIエージェントといった領域で爆発的に採用される。

第3章 · Temporal — カテゴリの標準

まずTemporalから。2019年、Maxim FateevとSamar Abbas — UberでCadenceを作った人達 — が独立して立ち上げた会社だ。実質Cadenceの第2世代。2026年5月時点で事実上の標準(de facto standard)であり、Snap・DoorDash・Datadog・Stripe・Coinbase・Box・Netflix(一部)・HubSpotがproductionで稼働させている。

コアモデルは単純で — **ワークフロー関数 = 決定論的コード。activity = 副作用(side effect)を持つコード。** ワークフロー関数内のすべての判断(分岐・sleep・signal待ち)はイベントログとして記録され、ワークフローコードはそのログをreplayして現在状態を復元する。だからワークフロー関数は外部呼び出しを直接行ってはならず、外部呼び出しはすべてactivityに委ねる。

Go SDKで書いた最小例。

package main

"context"

"time"

"go.temporal.io/sdk/workflow"

)

func OnboardingWorkflow(ctx workflow.Context, userID string) error {

ao := workflow.ActivityOptions{

StartToCloseTimeout: 10 * time.Second,

RetryPolicy: &temporal.RetryPolicy{

MaximumAttempts: 5,

InitialInterval: time.Second,

BackoffCoefficient: 2.0,

},

}

ctx = workflow.WithActivityOptions(ctx, ao)

if err := workflow.ExecuteActivity(ctx, SendWelcomeEmail, userID).Get(ctx, nil); err != nil {

return err

}

if err := workflow.ExecuteActivity(ctx, CreateStripeCustomer, userID).Get(ctx, nil); err != nil {

return err

}

if err := workflow.ExecuteActivity(ctx, SyncSalesforce, userID).Get(ctx, nil); err != nil {

return err

}

return workflow.Sleep(ctx, 24*time.Hour) // 決定論的sleep — 24時間後に再開

}

このコードの面白い点は`workflow.Sleep(24*time.Hour)`が本当に24時間眠ることだ。workerプロセスがその間に死んで蘇ってもよく、インフラが再デプロイされてもよい。24時間後に同じワークフローIDで誰かが起こすと、SDKがイベントログをreplayしてこの行から続行する。**これがdurable executionの本質だ。**

Temporalの強み — 多言語SDK(Go・Java・TS・Python・.NET・PHP・RubyがGA)、7年間の本番事例、カテゴリ最大のコミュニティ、Temporal CloudのSLA。弱み — 自前バックエンド(Cassandra・Postgres・MySQL・SQLite)が必要で、決定論制約は最初直感的でなく学習曲線が急。価格も — Temporal Cloud基準で — activity呼び出しとイベント件数で課金されるため、大量トラフィックのワークロードでは請求書が急上昇する。

いつTemporalを選ぶか。**長期運用のミッションクリティカルなワークフロー**、**多言語ポリグロット環境**、**決済・精算・請求のような整合性が絶対必要なドメイン**、**既に運用人員がいて、インフラ自体を引き受けてもよい会社**。

第4章 · Inngest — TS親和・サーバーレス親和

Temporalが「多言語・自前インフラ」の極だとすれば、Inngestはその真逆の軸 — TypeScriptファースト・サーバーレス親和だ。2021年創業、本社サンフランシスコ。CEOのTony Holdstock-BrownはGraphCMS・SoundCloud出身。コア洞察は「Vercel・Cloudflare・AWS Lambdaで動くバックエンドは関数あたりの実行時間が短い。だからワークフローをサーバーレス親和的に再設計する必要がある」。

Inngestのモデルは**event-driven step function**だ。ワークフローをJS関数として書くが、各ステップ(`step.run`、`step.sleep`、`step.waitForEvent`)はInngestバックエンドが別途呼び出す単位だ。コードはこんな感じ。

export const inngest = new Inngest({ id: "my-app" });

export const onboarding = inngest.createFunction(

{ id: "user-onboarding" },

{ event: "user/signed-up" },

async ({ event, step }) => {

await step.run("send-welcome-email", async () => {

await sendWelcomeEmail(event.data.userID);

});

await step.run("create-stripe-customer", async () => {

await createStripeCustomer(event.data.userID);

});

await step.sleep("wait-1-day", "1d"); // 1日休眠、サーバーレス環境でも動く

await step.run("send-day-1-followup", async () => {

await sendDayOneFollowup(event.data.userID);

});

}

);

どう動くか。`step.run`が呼ばれるとInngestはコールバックを実行し、結果を自分のバックエンドに記録する。次のstepに到達すると関数は終了し、Inngestは別のHTTP呼び出しで同じ関数を再度呼ぶ。今度は同じワークフローインスタンスIDで。SDKは前のstepのキャッシュ結果を見て、次のstepだけを新たに実行する。**各呼び出しは短い — Vercel Edge FunctionやCloudflare Workersのような場所でもうまく動く。**

Inngestの強み — TSファースト、Vercel/Cloudflare親和、ローカル開発UIがよく出来ていて、価格のfree tierが手厚い(月50,000 step)。弱み — ポリグロットが弱く(TS・Python・Goのみ)、決定論制約はTemporalより緩い代わりにstep分割をうまく出来ないと性能が出ない。そして会社が比較的新しい(2021年)ためエンタープライズ採用のtrustはTemporalに及ばない。

いつInngestを選ぶか。**TypeScript単一スタックのSaaS**、**Vercel・Cloudflare・Netlify・Renderのようなサーバーレスホスティング**、**イベント中心でトリガーされるワークフロー**、**AIエージェントのような「少し長いがすごく長くはない」タスク**。

第5章 · Trigger.dev v3 — Vercel風DX

2022年英国ロンドン創業。最初はInngestに似たevent-drivenモデルだったが、2024年のv3で大きく作り直した。v3は**「task as code・自前workerコンテナ」**モデルだ。つまりユーザーがtaskコードを書くと、Trigger.dev自前インフラ(またはself-host)が隔離されたコンテナで実行する。だから関数あたりの実行時間制約がほぼなくなる(デフォルト1時間、最大24時間)。Vercel Functionsの60秒・5分の壁を回避する。

コードはこんな感じ。

export const onboardingTask = task({

id: "user-onboarding",

maxDuration: 3600, // 1時間

run: async (payload: { userID: string }) => {

await sendWelcomeEmail(payload.userID);

const stripeCustomer = await createStripeCustomer(payload.userID);

await wait.for({ seconds: 86400 }); // 1日休眠

await sendDayOneFollowup(payload.userID);

return { stripeCustomer };

},

});

DXの核は**「Vercelのようにコードをpushすれば自動でビルドされトリガーに登録される」**点だ。別途workerプロセスを管理する必要がない(Trigger.dev Cloud使用時)。v3で導入されたもう1つの差別化点は**Realtime API** — ワークフローの進行状態をクライアントからリアルタイム購読できる。AIエージェントUI(ChatGPTのようにstepごとにprogressが流れる)を作るときに決定的な機能だ。

強み — DXがもっとも滑らかで(Vercel CLI調)、1時間のtaskをそのまま走らせられ、Realtime APIがあり、self-hostも可能(Apache 2.0)。弱み — TSのみ対応(Python・GoのSDKは2025年ベータだがproduction比率は低い)、そしてv2 → v3移行がほぼ書き直しに近く、v2ユーザーに負担を与えた。

いつTrigger.devを選ぶか。**TSフルスタックSaaS・インディ開発者・AIエージェントのサイドプロジェクト**、**Vercel風DXを望むチーム**、**task 1回の実行が5分〜1時間レンジ**、**そしてクライアントUIでtaskの進行をリアルタイムに見せる製品(AIエージェントUI・長い分析作業・コード生成器)**。

第6章 · Hatchet — Postgresベースの新鋭

Hatchetは2024年Y Combinator W24バッチ出身。創業者Alexander Belanger・Gabriel RuttnerはPorter出身のインフラエンジニア。コア論題は単純で — **「Postgresは既にキュー・メッセージブローカー・KV・トランザクションすべてうまくこなす。新しいインフラコンポーネント(Kafka・Redis・Cassandra)を入れず、Postgresをcontrol planeとして使おう」**。

Hatchetのモデルは2層構成だ。**タスクキュー(Hatchet Queue)** + **ワークフローエンジン(Hatchet Workflows)**。キューはPostgresの`SELECT ... FOR UPDATE SKIP LOCKED`の上で動く分散ジョブディスパッチャで、ワークフローはその上に積んだDAGエンジンだ。

TypeScript例。

const hatchet = Hatchet.init();

const onboarding = hatchet.workflow({

name: "user-onboarding",

on: { event: "user:signed-up" },

});

onboarding

.step({ name: "send-email" }, async (ctx) => {

await sendWelcomeEmail(ctx.input.userID);

return { sent: true };

})

.step({ name: "create-stripe", parents: ["send-email"] }, async (ctx) => {

return createStripeCustomer(ctx.input.userID);

})

.step({ name: "sync-salesforce", parents: ["create-stripe"] }, async (ctx) => {

return syncSalesforce(ctx.input.userID);

});

強み — Postgresさえあればself-hostが単純。RabbitMQ・Kafka・Redisすべて不要。throughputもよく(2026年5月時点単一ノードで毎秒1万+ task)、価格が非常に合理的(Hatchet Cloud free tierが手厚い)。弱み — 会社が2024年創業なのでproduction track recordが短い。SDKはTS・Python・Goがあるが、Java・.NETがない。そしてTemporalクラスの決定論的replayまでは行かない(タスク冪等保証はあるがコード決定論はユーザー責任)。

いつHatchetを選ぶか。**既にPostgresがあり、他のインフラコンポーネントを増やしたくないとき**、**self-host優先**、**AIエージェント・決済・オンボーディングのようなバックエンドビジネスロジック**、**Y Combinator新興をtrustするチーム**。

第7章 · Restate — Rustコアとシートと Virtual Objects

Restateは2023年ベルリン創業、Apache FlinkのPMCメンバーだったStephan Ewenが共同創業した。コアがRustで書かれ、デザイン哲学は — **「durable execution + actor modelを一度に解こう」**。コア抽象が**Virtual Object**だ — 分散状態を持つオブジェクトで、単一キーに対してはシリアル化された実行を保証しつつ、durableな状態と決定論的動作を一緒に提供する。

コードはこんな感じ。

const cart = restate.object({

name: "Cart",

handlers: {

addItem: async (ctx: restate.ObjectContext, item: string) => {

const items = (await ctx.get<string[]>("items")) ?? [];

ctx.set("items", [...items, item]);

},

checkout: async (ctx: restate.ObjectContext) => {

const items = (await ctx.get<string[]>("items")) ?? [];

const orderId = ctx.rand.uuidv4();

await ctx.run("charge", () => stripeCharge(items));

await ctx.run("ship", () => shipItems(items, orderId));

ctx.clear("items");

return orderId;

},

},

});

restate.endpoint().bind(cart).listen();

ここで`ctx.run("charge", ...)`が決定論的冪等実行単位だ。`ctx.rand.uuidv4()`もreplay時に同じ値を返す。`ctx.get`/`ctx.set`はオブジェクトキー単位でdurableな状態保存。

強み — actor modelが自然(IoT・ゲーム・セッション管理によく合う)、Rustコアのおかげでレイテンシが低く(2026年自前ベンチでp99 5ms未満)、self-host運用が単純(単一バイナリ + RocksDB)。弱み — actorパラダイムに慣れる必要がある。SDKはTS・Java・Kotlin・Go・Rust・Pythonに増えたが、コミュニティはTemporal・Inngestより小さい。そしてライセンスがBusiness Source License(4年後Apache 2.0)なのでOSS純粋派には気になる部分だ。

いつRestateを選ぶか。**状態を持つワークフロー(カート・セッション・ゲームマッチメーカー・IoTデバイスstate machine)**、**低レイテンシワークフロー**、**単一バイナリself-hostを望むチーム**、**Rustインフラ親和組織**。

第8章 · DBOS — Postgres = control plane

DBOSは2022年MIT・Stanford・CMUのDB研究者達が共同創業した(Mike Stonebraker・Matei Zaharia・Joe Hellerstein がアドバイザー)。論題は非常に挑発的で — **「伝統的OSの役割をDBが代替できる。Postgresをcontrol planeに使えば、ワークフロー・メッセージング・KV・トランザクションをすべて一度に解ける」**。

DBOSのコードモデルはデコレータベース。

from dbos import DBOS, WorkflowContext

@DBOS.workflow()

def onboarding(ctx: WorkflowContext, user_id: str) -> None:

DBOS.invoke(send_welcome_email, user_id)

customer = DBOS.invoke(create_stripe_customer, user_id)

DBOS.sleep(86400) # 1日休眠

DBOS.invoke(send_day_one_followup, user_id, customer.id)

@DBOS.communicator()

def send_welcome_email(user_id: str) -> None:

smtp_send(user_id)

内部的に`@DBOS.workflow()`は関数実行をPostgresトランザクション + 永続イベントログで包む。関数が死ねば次のworkerが同じワークフローIDで起こし止まった場所から続行する。**すべての進行状態がPostgresに住む。** だから別途ワークフローバックエンドがない — あなたのPostgresがそのままワークフローエンジンだ。

強み — Postgresさえあればよい(別途インフラ0個)、軽量(ワークフローエンジンがライブラリ)、学術的デザインの正統性。弱み — 会社・製品が新規、throughputがPostgres 1インスタンスに縛られる(2026年時点単一ノードで1000〜3000 wf/s、パーティショニング時さらに上がるが運用複雑)、ポリグロットが弱い(TS・Pythonのみ)。

いつDBOSを選ぶか。**すべてのワークロードを1つのPostgresに集めたいとき**、**研究・実験・小規模SaaSでインフラコンポーネント数を0に近く維持**、**TS/Python単一スタックチーム**。

第9章 · Cadence — Uberの祖先、Temporalの親

Cadenceは2017年Uberが作りオープンソース化した。創業者Maxim・Samarが2019年Temporalに分岐した後、CadenceはUber社内運用チームが継続維持している。2026年でもUber内部で日次数十億ワークフロー実行を回す。APIとデザインはTemporalと非常に似ている(同じ人達が2度目に作ったのがTemporalなので当然だ)。

違いは — CadenceはTemporalより保守的。SDK多様性がTemporalに及ばず(Go・Javaが主力)、新機能リリース速度が遅い。代わりにUber内部で検証された7年+のtrack recordがある。外部ユーザーはほぼTemporalに移ったが、Uber・Coinbase一部・HashiCorp一部が今もCadenceを動かしている。

いつCadenceを選ぶか。**Uberのような超大規模運用チームがあり自前運用を好むところ** — 事実上ほとんどの新規採用はTemporalに行く。

第10章 · Airflow / Prefect / Dagster — データエンジニアリング陣営

ビジネスロジック陣営を見たのでデータエンジニアリング側に視線を移そう。この陣営の座標はAirflow・Prefect・Dagsterの3強だ。

**Airflow 3.0(2024.10 GA)**。Airbnbが2015年に作りApacheへ寄贈したデータワークフローエンジン。2026年5月時点でデータエンジニアリングの事実上の標準。Airflow 3.0で最大の変化は — scheduler・DAG processor・executorが完全に分離されmulti-tenant運用が容易になった。Task SDKが分離されworkerがより軽くなった。Astro・MWAA(AWS Managed)・Cloud Composer(GCP)がマネージドオプションを提供する。

from airflow.decorators import dag, task

from datetime import datetime, timedelta

@dag(schedule="@daily", start_date=datetime(2026, 1, 1), catchup=False)

def daily_etl():

@task

def extract():

return fetch_from_source()

@task

def transform(data):

return clean_and_aggregate(data)

@task

def load(transformed):

write_to_warehouse(transformed)

load(transform(extract()))

daily_etl()

**Prefect 3.0(2024.09 GA)**。PrefectHQが作ったPythonicワークフローエンジン。Airflowの静的DAG制約(コンパイル時にグラフ固定)を解くためdynamic DAGを採用した。つまりワークフロー内のランタイム条件によりDAGが変わりうる。3.0で最大の変化は — 自前Postgres・SQLiteバックエンドを使う簡略化されたself-host体験、そしてtransactional保証強化。

**Dagster 1.10(2025 Q3)**。Elementlが作ったasset(資産)中心ワークフローエンジン。他の2道具が「どのtaskがいつ動くか」を定義するなら、Dagsterは「どのasset(テーブル・ファイル・モデル)がどう更新されるか」を定義する。だからデータlineage・観測性が一級。1.10ではSoftware-Defined Assetモデルがより精緻になり、dbt・Snowflake・Databricks統合が一級になった。

3つの道具の分岐点。

- **Airflow** — もっとも大きなコミュニティ・エコシステム・統合。短所は動的DAGが難しく、運用が重く、scheduler負荷の問題があった(3.0で緩和)。

- **Prefect** — Pythonic、dynamic、学習曲線が滑らか。短所はAirflowより統合ライブラリが少ない。

- **Dagster** — assetモデル・lineage・観測性。短所は学習曲線が急(asset抽象を初見で理解しづらい)、単純なcron代替には過剰。

いつ何を選ぶか。**既にデータチームがあってAirflow運用ノウハウがあれば → Airflow維持**。**新しいデータチーム、Pythonic DXを重視 → Prefect**。**データlineage・観測性・asset中心思考 → Dagster**。

第11章 · Argo Workflows — k8sネイティブ

Argo WorkflowsはIntuitが作ってCNCFに寄贈したKubernetesネイティブワークフローエンジン。すべてのワークフローstepがk8s Podで実行され、ワークフロー定義がCRD(Custom Resource Definition)だ。MLパイプライン・CI/CD・データ処理によく使われる(Argo CDとは別プロジェクトだが同じ会社の製品群だ)。

apiVersion: argoproj.io/v1alpha1

kind: Workflow

metadata:

generateName: ml-training-

spec:

entrypoint: pipeline

templates:

- name: pipeline

steps:

- - name: preprocess

template: preprocess-data

- - name: train

template: train-model

- - name: evaluate

template: evaluate-model

- name: preprocess-data

container:

image: my-org/preprocess:latest

command: [python, preprocess.py]

- name: train-model

container:

image: my-org/train:v2

command: [python, train.py]

resources:

limits:

nvidia.com/gpu: 1

強み — k8sネイティブ、各stepがコンテナで言語/ランタイムに依存しない、ML/CI/CD親和。弱み — YAMLで表現が急速に複雑化し、コードベースのワークフローよりデバッグが難しい。そしてstep開始にPod startupオーバーヘッドがあり、短いtaskが多いワークフローには非効率。

いつArgoを選ぶか。**既にk8sを動かしておりすべてのインフラをk8s上に統一したいとき**、**stepが独立コンテナのML/CI/データpipeline**、**YAMLで定義が自然な単純DAG**。

第12章 · Conductor — Netflix → Orkes

Conductorは2016年Netflixが作りオープンソース化したマイクロサービスorchestrationエンジン。2022年に元創業者達がOrkesを立ち上げ、Conductorのエンタープライズ版とCloudをリリースした。モデルはJSON DSL — ワークフローをJSONで定義し、各stepはworkerがHTTPポーリングで取得して実行する。

{

"name": "user_onboarding",

"version": 1,

"tasks": [

{

"name": "send_welcome_email",

"taskReferenceName": "send_email_ref",

"type": "SIMPLE"

},

{

"name": "create_stripe_customer",

"taskReferenceName": "stripe_ref",

"type": "SIMPLE"

},

{

"name": "wait_one_day",

"taskReferenceName": "wait_ref",

"type": "WAIT",

"inputParameters": {

"duration": "1d"

}

}

]

}

各task typeにはSIMPLE(workerポーリング)・HTTP(REST直接呼び出し)・FORK_JOIN(並列)・SWITCH(分岐)・DECISIONなどがある。Netflix内部ではコンテンツエンコーディングパイプライン・決済・プッシュ通知のような大規模非同期ワークロードを回した。

強み — 言語独立(JSON DSLなのでどの言語でもworkerになる)、ビジュアルエディタ、Netflix運用検証。弱み — JSONで定義が長くなるとコードレビューが難しく、Workflow as code時代の流れに逆行する。Orkesはこれを補おうとコードSDKを追加したが、基本モデルは依然JSON。

いつConductorを選ぶか。**多言語マイクロサービス環境で言語独立orchestrationが必要**、**ビジュアルエディタを運用者に提供したいとき**、**Netflix流大規模非同期パイプライン**。

第13章 · どのエンジンを選ぶべきか — ワークロード別決定木

12個のエンジンを一度ずつ見たので、ワークロード別に誰が似合うかをマッピングしよう。

AIエージェント / LLMパイプライン

もっとも熱いワークロード。1サイクルが5秒〜30分の間で可変で、外部API(OpenAI・Anthropic・Replicate・ツール呼び出し)依存が大きく、retry・idempotencyが必須、クライアントUIで進行状態を見せる必要がある。

- **1位 — Trigger.dev v3またはInngest**。TSファースト、Realtime API(Trigger)、step model(Inngest)がLLM step分割と自然に合う。

- **2位 — Temporal**。Python・Go SDKでLLM呼び出しをワークフローで包みやすく、replayデバッグが強力。

- **3位 — Hatchet**。Postgres単一インフラが魅力的なら。

決済 / 精算 / 請求

整合性・監査・再現可能性が絶対的なドメイン。retryポリシー・重複決済防止・イベントログがコア。

- **1位 — Temporal**。7年のproduction検証、決定論的replay、多言語SDK。Stripe・Coinbase・DoorDashがproductionで回すドメイン。

- **2位 — Cadence**。Temporal祖先なので同じモデル、Uber内部決済運用。

- **3位 — Restate**。Virtual Objectモデルが口座・財布のような状態を持つ決済に自然。

ETL / データエンジニアリング

バッチ・スケジュール・依存関係管理・dbt/Snowflake/Databricks統合がコア。

- **1位 — Airflow**。標準、もっとも大きな統合ライブラリ。既にデータチームがあるならほぼ自動選択。

- **2位 — Dagster**。asset中心モデル、lineage・観測性が必要なとき。

- **3位 — Prefect**。Pythonの小規模チーム、dynamic DAGが必要なとき。

ユーザーオンボーディング / サブスクリプション / 通知

順序のあるstep、1〜30日休眠、イベントトリガー。

- **1位 — Inngest**。event-drivenモデルがもっとも自然。

- **2位 — Trigger.dev**。TS単一スタックなら。

- **3位 — Temporal**。既にTemporalを回しているなら。

ML学習 / 推論パイプライン

GPUノード・コンテナ隔離・k8s親和。

- **1位 — Argo Workflows**。k8sネイティブ、コンテナstep、GPUリソース宣言。

- **2位 — Dagster + ModalのようなGPUバックエンド結合**。

- **3位 — Temporal**。学習自体より学習orchestrationメタワークフロー。

マイクロサービスorchestration(多言語)

言語多様、JSON DSLが自然、ビジュアルエディタ必要。

- **1位 — Conductor(Orkes)**。JSON DSL、多言語worker。

- **2位 — Temporal**。SDK多様性で解けるなら。

小規模SaaS · インフラコンポーネント最小化

Postgres以外のインフラを増やしたくないインディ・小規模チーム。

- **1位 — Hatchet**または**DBOS**。両方Postgresがcontrol plane。

- **2位 — Inngest Cloud**(別途インフラ0個)。

第14章 · 韓国・日本の導入事例

理論は十分見た。実際productionで誰が使うか — 韓国・日本の事例を集めよう。

トス(Toss · 韓国)

トスは2023〜2024年に決済・送金・証券のような整合性が絶対必要なドメインでTemporal導入を増やした。公開発表(2024 SLASHトスカンファレンス)でトス証券は注文・約定・精算パイプラインの一部をTemporalに移しつつretry・idempotencyをライブラリ化した事例を共有した。2026年5月時点でトスグループ内の複数チームがTemporal Cloudまたはself-host Temporalを回す。データエンジニアリング側は別途Airflow。

Uber Eats Japan

Uber本陣のCadenceがUber Eats Japanバックエンドにも敷かれている。注文・配車・決済ワークフロー一部がCadence上で動く。2024年後半のUber内部発表では一部ドメインをTemporalにマイグレーション中という言及があった。

LINE / LINE Yahoo

LINEは自前ワークフローエンジンを長く回してきたが、2024年から一部ドメインでArgo WorkflowsとAirflowを導入する流れがLINE Engineeringブログに公開された。メッセージング・プッシュ通知のような大規模非同期ワークロードは自前キューシステム(LINE Async)が依然1軍だが、決済・精算側の新規プロジェクトでTemporal検討が進行中という非公式報告がある。

メルカリ(日本)

メルカリはデータエンジニアリング側でAirflowを標準として回す(Mercari Engineeringブログに多数公開)。バックエンドビジネスロジックは自前マイクロサービス・gRPC中心なのでTemporalクラスの道具導入は限定的だが、一部ドメイン(C2C決済・検索インデックス)でApache Beam・Argoと自前ワークフローライブラリを組み合わせる。

ZOZO(日本)

ZOZOは検索・推薦インデックスパイプラインでArgo Workflowsを回す(ZOZO Techブログ)。k8s上にすべてのデータ・MLパイプラインが統一された稀な事例。

CyberAgent(日本)

CyberAgentはゲーム・メディア・広告子会社が多く道具多様性が高い。広告入札ドメインでTemporal導入、ゲームバックエンド一部にCadence、データ分析はAirflow・Dagster混用。発表資料がもっとも豊富な日本企業の1つ。

第15章 · まとめ — 2026年のワークフローエンジンを見る5つの視点

1. **AIエージェントがカテゴリを再びtier-1インフラに引き上げた。** 5秒〜30分の間のlong-running・resumable・idempotent作業がすべてのバックエンドの日常になり、キュー + workerの手書きはもう答えではない。

2. **Workflow as codeが標準になった。** JSON・YAML DSLはビジュアルエディタが必要な特殊領域(Conductor・Argo)に残り、それ以外ではGo・TS・Pythonコードが一級市民。IDE・型・テスト・diff・レビューがすべて動くので当然の帰結。

3. **2つの陣営の境界が次第に薄れる。** ビジネスロジック陣営とデータエンジニアリング陣営は依然分離しているが、AI/MLパイプラインが両者の間にグレーゾーンを作った。TemporalでML orchestrationを書くチームも、Dagsterでバックエンドビジネスワークフローを書くチームも増えた。

4. **インフラコンポーネント最小化がシグナル。** Hatchet・DBOSの人気は「Postgresさえあればすべて済む」というthesisの台頭だ。Kafka・Redis・Cassandraを別途運用する負担を減らそうとする流れ。Restateのような単一バイナリself-hostも同じ文脈。

5. **選択は結局チームの形に左右される。** Temporalがもっとも「正しい」答えの場合が多いが、TS単一スタックSaaSにはInngest/Trigger.devが自然で、k8s陣営にはArgoが似合い、データチームにはAirflowが標準だ。「最高のエンジン」より「今のチームに合うエンジン」が正解。

2018年の我々はcron + キュー + workerですべてを処理していた。2026年の我々はその上にdurable executionという1層を載せた。次の1行を書く前に — このワークフローが1年後にも動くなら、それはワークフローエンジンの仕事だ。

参考 / References

- Temporal Documentation — https://docs.temporal.io

- Temporal Cloud — https://temporal.io/cloud

- Cadence Workflow — https://cadenceworkflow.io

- Inngest Documentation — https://www.inngest.com/docs

- Trigger.dev v3 Documentation — https://trigger.dev/docs

- Hatchet Documentation — https://docs.hatchet.run

- Restate Documentation — https://docs.restate.dev

- DBOS Documentation — https://docs.dbos.dev

- Apache Airflow — https://airflow.apache.org

- Airflow 3.0 Release Notes — https://airflow.apache.org/blog/airflow-3.0.0

- Prefect Documentation — https://docs.prefect.io

- Dagster Documentation — https://docs.dagster.io

- Argo Workflows — https://argoproj.github.io/argo-workflows

- Netflix Conductor / Orkes — https://orkes.io

- Conductor OSS — https://conductor-oss.github.io/conductor

- Y Combinator W24 — Hatchet — https://www.ycombinator.com/companies/hatchet

- Stephan Ewen on Restate — https://restate.dev/blog

- DBOS Founders Paper(Stonebraker et al.) — https://www.dbos.dev/papers

- Toss SLASH Conference — https://toss.tech/slash

- Mercari Engineering Blog — https://engineering.mercari.com

- LINE Engineering Blog — https://engineering.linecorp.com

- ZOZO Tech Blog — https://techblog.zozo.com

- CyberAgent Developers Blog — https://developers.cyberagent.co.jp

- "Designing Data-Intensive Applications"(Kleppmann) — durable execution理論背景