Temporalとは｜ワークフローの仕組みと分散処理での使いどころ

Temporalとは｜コードで書くワークフローエンジン

Temporalのワークフローとは、複数ステップにまたがる業務処理を通常のコードで書き、その進捗・待機・再試行・失敗時の打ち消しをプラットフォーム側が履歴として管理してくれる仕組みです。サーバーが落ちても、途中から続きを実行できます。

Temporalは、ビジネスプロセスをコードとして記述し、その実行を最後まで保証することを目的としたプラットフォームです。YAMLやGUIで状態遷移を定義するタイプとは発想が違います。

公式ドキュメントは、ワークフローを「コードで定義されたビジネスプロセスであり、各ステップが通常の制御フローとして書かれたもの」と説明しています（Understanding Temporal）。if文もfor文もtry/catchも、言語そのものの構文がそのまま使えます。

Durable Execution（永続実行）とは

Durable Executionとは、実行の状態と進捗を失わずに保持し続ける仕組みです。

公式が掲げる保証は明快で、ワークフローはいったん開始されたら完了まで実行される、それが1秒でも1年でも変わらない、というものです。プロセスがクラッシュしても、Temporalは別のプロセスに処理を引き継ぎ、そのプロセスが実行状態を再構築してクラッシュ直前の地点から続きを走らせます。

ここが従来のジョブ基盤と決定的に違う点です。一般的なバッチやワーカーでは、落ちた瞬間の「どこまで進んだか」はアプリ側が自前でDBに書いて管理します。Temporalはその進捗管理をプラットフォーム側に寄せています。

WorkflowとActivityの役割分担

Temporalのコードは2種類に分かれます。

公式はActivityを「APIを呼ぶ、データベースに書き込むといった外部世界に触れる作業の単位」と定義しています。逆に言えば、副作用のあるものは全部Activity側へ追い出すのがTemporalの作法です。

この分け方さえ守れば、ワークフロー側は「24時間待ってからリマインドを送る」といった記述を、スケジューラも中間テーブルも使わずに1行で書けます。UPSIDERの技術ブログでも、請求メール送信から1日待機してリマインドを送る流れをコード1本で表現し、従来必要だったバッチ連携をなくした例が紹介されています（TemporalによるDurableなワークフロー開発）。

従来のジョブ基盤・バッチとの違い

ジョブキュー型の非同期処理は、1タスク単位では強いものの、「複数タスクをまたぐ状態」が苦手です。注文を受けて、在庫を確保して、決済して、失敗したら在庫を戻す。この一連の流れをキューだけで表現すると、状態はDBの中に散らばり、どこまで進んだかはログを追うしかなくなります。

Temporalは、その「流れ」自体を1つの関数として保持します。状態の置き場所がコードとEvent Historyに一本化される、と言い換えてもいいでしょう。

ミニFAQ：Temporalはジョブキューの置き換えですか？

単発タスクの並列処理だけならキューで十分です。置き換えの価値が出るのは、複数ステップにまたがる状態と、失敗時の巻き戻し（補償）が絡む場合です。

Temporalの仕組み｜Event Historyとリプレイ

Temporalの動作は、サーバー側（Temporal Service）とユーザー側（Worker）の分業で成り立っています。結論から言えば、サーバーは履歴とタスクの管理だけを行い、業務ロジックは一切実行しません。

Temporal Serviceの構成

公式ドキュメントでは、Temporal Serviceは次の4つのサービスで構成されると説明されています。

• Frontend Service：クライアントとワーカーからのリクエスト受付

• History Service：ワークフロー実行の履歴管理

• Matching Service：タスクキューとワーカーのマッチング

• Worker Service：内部的なバックグラウンド処理

永続化層にはCassandra、MySQL、PostgreSQL、SQLiteが使えます。運用形態は、自前でクラスタを構築するセルフホストと、マネージドのTemporal Cloudの2択です。検証段階では開発用のローカルサーバーから始めるのが手早いです。

WorkerとTask Queue

重要なのは、ワーカーが「仕事を受け取る」のではなく「仕事を取りに行く」モデルだという点です。公式の表現では、ワーカーは仕事を受信しない、要求するのだ、とされています。

ワーカーはユーザー自身のインフラ上で動き、指定したTask Queue（処理の振り分け先となる待ち行列）をポーリングします。業務ロジックの実行そのものは、ユーザー側の環境で完結する構造です。

ただし「データがサーバーへ一切渡らない」という意味ではありません。ActivityやWorkflowの引数・戻り値はペイロードとしてEvent Historyに記録されます。Temporal Cloudを使う場合に機密情報をどこまで載せるかは、ペイロードの設計や暗号化（Codec Serverの利用など）とセットで検討する論点です。

Task Queueはルーティングの単位でもあります。重い処理専用のキュー、GPUを持つワーカー専用のキュー、といった分離が自然に書けます。

Event Historyとリプレイ

Event Historyは、そのワークフロー実行に起きたことすべてを順序付きで記録した永続ログです。Durable Executionの実体はここにあります。

復旧の流れはシンプルです。

1. ワーカーがクラッシュする

2. 別のワーカーが同じワークフロー実行を引き受ける

3. Event Historyを先頭から再生（リプレイ）し、過去のActivity呼び出しは記録済みの結果をそのまま返す

4. 履歴が尽きた地点＝クラッシュ直前の地点から、実際の処理を再開する

ワークフロー関数は何度も最初から実行し直されている、という事実がポイントです。これが次の制約に直結します。

決定論（determinism）という制約

ワークフローコードは決定論的でなければなりません。リプレイで状態を再構築する以上、同じ履歴からは必ず同じ分岐をたどる必要があるからです。

具体的に、ワークフロー関数の中で直接やってはいけないことは次のとおりです。

• システム時刻の取得（SDKが提供する決定論的な時刻APIを使う）

• 乱数生成、UUID生成

• 外部APIやDBへのアクセス

• グローバル変数や環境変数に依存した分岐

• 言語標準のスリープ（SDKのタイマーを使う）

UPSIDERの記事でも「Workflowの中では非決定的な処理を書いてはいけない」が重大な制約として挙げられ、乱数と現在時刻はActivityに切り出す必須ルールになったと述べられています。

導入初期のバグはだいたいここです。筆者の周辺でも、ワークフロー内でmap反復の順序に依存した分岐を書いてしまい、リプレイのたびに別の経路へ入るという事故が起きたことがあります。言語仕様レベルの「順序が保証されない処理」まで含めて洗い出す必要があります。

ミニFAQ：決定論を壊したかどうかは、どこで気づけますか？

多くのSDKにリプレイテスト用の機能があります。本番で取得したEvent Historyを手元のコードに食わせて再生し、差分が出ないかをCIで検証するのが確実です。デプロイ前の自動テストに組み込んでおくと、壊れたまま出荷する事故を防げます。

分散処理での使いどころ｜Sagaと補償処理

Temporalが最も効くのは、複数サービスにまたがる処理を、失敗前提で設計しなければならない領域です。

マイクロサービス構成では、サービスをまたぐトランザクションをDBのロールバックで片付けられません。代わりに使われるのがSagaパターンです。

Sagaパターンと補償アクション

Sagaは、長いトランザクションを「ローカルトランザクションの連鎖」として表現し、途中で失敗したら、それまでに成功したステップを打ち消す補償アクションを逆順に実行する考え方です。

Temporalでこれを書くと、補償処理が普通のtry/catchとdefer（あるいはfinally）の中に収まります。補償リストを配列に積んでおいて、例外が出たら逆順に実行する。たったそれだけで、分散トランザクションの巻き戻しが表現できます。

ただし実務の現場では、Sagaを「失敗したら逆順に戻すもの」と捉えると設計が歪みます。UPSIDERの登壇レポート（2026年4月27日開催のBackground Job Talk、発表者konn氏）では、Sagaを単なるロールバックではなく業務プロセスの状態遷移設計の手法として扱っている点が紹介されています（Temporalで実践するSagaとプロセスモデリング）。

請求・入金・消込の領域では、失敗しても単純に元へ戻すのではなく、別の状態へ遷移するほうが業務的に自然なケースが多い。だから「どの状態からどの状態へ遷移できるか」を先に整理する、という進め方です。この視点はドメイン駆動設計（DDD）の考え方とも噛み合います。

冪等性は補償処理の前提になる

補償アクションが成立する条件は、Activityが複数回実行されても結果が壊れないことです。

Temporalはリトライを前提にした仕組みなので、同じActivityが2回走る可能性を常に織り込む必要があります。金銭が絡む処理では、二重実行の防止が設計の中心になります。

実装上は、業務的な一意キー（注文ID＋ステップ名など）をActivity側に渡し、DBのユニーク制約や処理済みテーブルで弾くのが定番です。Temporalが渡すワークフローIDと実行IDも、冪等キーの材料として使えます。

長時間ワークフロー：タイマーとシグナル

「3日後に督促」「ユーザーの承認を最大30日待つ」といった処理は、Temporalの得意分野です。

タイマーで待機している間、ワーカーのメモリを占有しません。待機状態はサーバー側が保持し、時間が来たらタスクが配られます。外部からの割り込みはSignalで受け取り、現在の状態を外から問い合わせたいときはQueryを使います。

向くケースと向かないケース

ストリーム処理が中心ならApache Flink、イベントの配信基盤ならApache Kafkaのほうが素直です。Temporalは「オーケストレーション（指揮）」の道具であって、データ転送基盤ではありません。

Airflow・Step Functionsとの違い

ワークフローエンジンの選定で迷いやすい3つを並べます。

Airflowとの違い

AirflowはDAG（有向非巡回グラフ）でタスクの依存関係を定義し、スケジュール起動するのが基本モデルです。データ基盤のETL／ELTやMLパイプラインで広く採用されています。

対してTemporalは、起動のきっかけがイベント駆動で、1つの実行が長時間ステートを持ち続ける前提です。「毎日3時に動かす」ならAirflow、「申込ごとに1本立ち上がって2週間生きる」ならTemporal、と考えると外しにくいです。

Step Functionsとの違い

Step FunctionsはAWSのマネージドサービスで、Lambdaや各種AWSサービスの呼び出しを状態機械として組み立てます。GUIで可視化でき、インフラ運用が不要なのが強みです。

一方で、複雑な分岐やループをJSONベースの定義言語で書くと読みづらくなりがちで、ユニットテストも書きにくくなります。ロジックが込み入ってくるほど、普通のコードとして書けるTemporalの利点が効いてきます。AWS依存を許容できるか、という観点も含めて技術選定の評価軸を先に揃えておくのが安全です。

判断フロー（簡易版）

1. 処理が定時起動のデータパイプライン中心か → YesならAirflow系

2. 実行時間が数分以内で、AWS内のサービス連携が主か → YesならStep Functions

3. 1つの処理が数時間以上生き続け、途中で外部からの入力を待つか → YesならTemporal

4. 失敗時に「元に戻す」業務処理（補償）が複数ステップ必要か → YesならTemporal

5. 上のどれにも当てはまらず、単発の非同期実行だけか → キュー＋ワーカーで十分

実装・運用で詰まりやすいポイント

導入検証では動いたのに本番で詰まる、という典型パターンがいくつかあります。数値が決まっているものは先に押さえておくと設計がぶれません。

Event Historyの上限とContinue-As-New

公式のWorkflow Executionの上限によると、Event Historyには次の制限があります。

無限ループで監視し続けるようなワークフローは、この上限に素直にぶつかります。対処はContinue-As-Newです。現在の実行を終了し、必要な状態だけを引数として渡して新しい実行を開始することで、履歴をリセットできます。

ただし、ここが設計の難所でもあります。UPSIDERの登壇でも、Continue-As-Newの活用は長期稼働ワークフローで必須としつつ、ワークフロー先頭の再実行や「送信済み」管理と組み合わせた設計が必要だと指摘されています。履歴をリセットした結果、通知が二重に飛ぶといった事故はここで起きます。

4種類のタイムアウトを使い分ける

Activityのタイムアウトは4種類あり、役割が違います（公式ドキュメント）。

公式の整理では、Schedule-To-CloseかStart-To-Closeのいずれかは必ず指定する必要があります。実務でまず置きたいのはStart-To-Closeです。これを入れていないと、ワーカーが無言で死んだときの検知が遅れ、処理が長時間止まったままになりかねません。

数分以上かかるActivity（大きなファイルの変換、外部システムの一括同期など）は、Heartbeatを併用して進捗を報告させると、途中で落ちても検知が早くなります。

ワークフローのバージョニング

稼働中のワークフローがある状態でコードを変更すると、リプレイ時に履歴と新コードが食い違って実行が壊れます。数か月生きるワークフローを運用するなら、避けて通れない問題です。

各SDKにはバージョニング用のAPI（GetVersionやpatchといった名称）があり、「この実行は旧ロジック、新しく始まる実行は新ロジック」と分岐させられます。ワーカー側にバージョンを紐づけて段階的に切り替える仕組みも用意されています。

運用ルールとしては、長期ワークフローのコード変更は必ずバージョニング前提でレビューする、を決めておくのが確実です。

ローカル開発と可観測性

開発用のローカルサーバーを立てればWeb UIが付いてきます。各ワークフロー実行のイベント履歴がそのまま読めるので、「どのActivityで何回リトライしたか」が一目で分かります。障害調査の体験はかなり良い部類です。

本番では、ワーカー側のメトリクスとトレースをOpenTelemetryで拾っておくと、Temporal UIの履歴とアプリ側のログが突き合わせやすくなります。

ミニFAQ：Temporal Cloudとセルフホスト、どちらから始めるべきですか？

検証はローカル、本番の初手はCloudという順が無難です。セルフホストはCassandraやPostgreSQLを含むクラスタ運用が必要で、Kubernetesの運用体制がないチームには負荷が重くなります。自前運用に切り替えるのは、コストや要件がはっきりしてからでも遅くありません。

導入状況とフリーランス案件での位置づけ

日本での採用事例

国内でも、決済・請求領域を中心に採用例が見られます。以下は公開されている事例の一例であり、国内全体の採用状況を網羅したものではありません。

本記事執筆時点で確認できる範囲では、2026年4月27日にUPSIDER・LayerX・メルカリの3社合同で「Background Job Talk 〜 Temporal活用と独自実装の舞台裏編〜」が開催され、Temporalを使った請求基盤のプロセスモデリング、メッセージキュー型の非同期処理からの移行、内製ワークフローエンジンの設計といったテーマが共有されました。

この並びから読み取れるのは、Temporalが「新しもの好きが触る技術」から「お金が動く基幹処理で検討される選択肢」の側に移ってきている、という点です。ただし採用企業数そのものはまだ限られており、Airflowのように案件要件として頻出する段階ではありません。

公開案件での現れ方

本記事執筆時点（2026年10月）で、首都圏中心の主要フリーランスエージェント数社の公開案件検索ページを「Temporal」で絞り込んだ範囲では、スキル名として前面に出る募集はほとんど確認できませんでした。公開案件が少ない領域のため、件数を数えて語れる段階になく、あくまで観測ベースの目安として読んでください。

公開案件に出ていないことは、非公開案件や社内の技術スタックに存在しないことを意味しません。

現実的な現れ方は次のパターンです。

• Go言語またはJavaでのマイクロサービス開発案件の、歓迎スキル欄

• 決済・請求・与信など、ステートフルな基幹処理を扱うプロダクトのバックエンド募集

• ジョブ基盤・非同期処理基盤のリプレイス案件

いずれも中心にあるのはTemporal単体の知識ではなく、分散システムの設計経験です。バックエンドフリーランスの単価相場で言えば、言語スキルよりレイヤー（どこまで設計を任せられるか）で評価が分かれる領域にあたります。

自分の経験でどのくらいの単価を狙えるかが気になる方は、無料のフリーランスエンジニア単価診断で現在の市場単価の目安を確認できます。単価を体系的に上げる考え方は「【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？」で整理しています。

スキルの持ち方

Temporalだけを覚えても単体では売りになりにくい、というのが正直なところです。効くのは組み合わせです。

イベント駆動アーキテクチャの設計判断ができ、冪等性と再試行を前提に実装でき、そのうえでTemporalという道具も使える。この順序で積むと、ジョブ基盤リプレイスの相談が来たときに提案側へ回れます。

学習ロードマップ

ゼロから業務で使える水準まで、週に5〜10時間を充てられる想定で4段階に分けます。

ステップ1：概念の理解（1〜2週間）

Durable Execution、Workflow、Activity、Task Queue、Event Historyの関係を押さえます。公式ドキュメントのEvaluateセクションを一通り読むのが近道です。

ステップ2：ローカルで動かす（1〜2週間）

開発用サーバーを立て、使い慣れた言語のSDKでHello Worldから始めます。SDKは.NET、Go、Java、PHP、Python、Ruby、Rust、TypeScriptの8言語に対応しています。Web UIでEvent Historyを眺めながら、1つのActivity呼び出しが何イベントになるかを目で確認すると理解が早まります。

ステップ3：失敗を作って壊す（2〜3週間）

ワーカーを途中でkillして復旧を確認する。わざと決定論を壊してリプレイエラーを出す。タイムアウトを短くしてリトライの挙動を見る。この「壊して直す」工程を飛ばすと、本番で初めて挙動を知ることになります。

ステップ4：Sagaを1本書く（2〜4週間）

3ステップ程度の補償つきワークフローを書き、途中失敗時に逆順で打ち消されることを確認します。ここまで来れば、設計レビューの場で意見が言える水準です。

導入前チェックリスト

提案や技術選定の場で、そのまま使える確認項目として整理しました。

まとめ

Temporalは、失敗しても止まらない業務プロセスをコードとして書くための基盤です。定時バッチの置き換えではなく、長期・ステートフル・補償ありの処理に対して効きます。

要点を整理します。

• Durable Executionの実体はEvent Historyとリプレイ。ワーカーが落ちても続きから走る

• Workflowは決定論的に、副作用はすべてActivityへ。最初の事故はここで起きる

• Airflowは定時バッチ、Step FunctionsはAWS内の状態遷移、Temporalは長期の業務プロセス

• Sagaは「逆順ロールバック」ではなく状態遷移の設計手法として捉えると、業務に馴染む

• Event Historyは51,200イベント／50MBが上限、10,240イベント／10MBで警告。長期実行はContinue-As-New前提

• Activityにはタイムアウトを設定する。Start-To-CloseとSchedule-To-Closeのいずれかは必須で、実務ではStart-To-Closeを置くとワーカー死亡時の停止を防ぎやすい

• 公開案件での指名はまだ少ない。Go・マイクロサービス・決済基盤の文脈で価値が出る

次の一歩としては、ローカルサーバーを立てて3ステップの補償つきワークフローを1本書くところまでをおすすめします。壊して直す経験まで含めて1〜2か月あれば、設計の議論には入れます。

参照した一次情報は以下です。

• Understanding Temporal（Temporal公式ドキュメント）

• Workflow Execution の上限（Temporal公式ドキュメント）

• Activity の失敗検知とタイムアウト（Temporal公式ドキュメント）

• TemporalによるDurableなワークフロー開発（UPSIDER Techblog）

• Temporalで実践するSagaとプロセスモデリング（UPSIDER Techblog）