Cloudflare Dynamic Workflows — マルチテナント受託SaaS の耐障害ワークフロー設計 2026

2026 年 5 月、InfoQ が Cloudflare Ships Dynamic Workflows, Bringing Durable Execution to Per-Tenant and Per-Agent Code を公開し、Cloudflare が MIT ライセンスで Dynamic Workflows ライブラリを公開しました。Dynamic Workers をベースに、テナント・エージェント・リクエスト単位でワークフローコードを動的に差し替えることができ、数百万のユニーク・ワークフローをアイドル時ほぼゼロコストで稼働できる仕組みです。

マルチテナント SaaS の開発では、「テナントごとに異なる業務ロジック」をどう扱うかが繰り返し論点になります。本記事では、Dynamic Workflows を受託開発の文脈で運用するための設計指針、コスト構造、契約条項、落とし穴を整理します。

何が新しいのか — テナント別 Durable Execution

これまでの Durable Execution（Temporal / AWS Step Functions / Inngest 等）では、ワークフロー定義は事前にデプロイされた静的コードでした。テナントごとに分岐したい場合は、巨大な if 文か、テナント ID をキーにした strategy パターンを書くしかありませんでした。

Dynamic Workflows は以下の根本的な変化を持ち込みます。

特に 「テナント別コードを直接配置できる」点が、受託の 「顧客ごとに違う業務フロー」にそのまま刺さります。これは Cloudflare Code Mode の MCP トークン最適化 で扱った「コードを動的に動かす」思想を、ワークフローレイヤーまで押し上げた形です。

受託マルチテナント SaaS の典型的な悩み

SaaS の受託開発では、以下のような要望が繰り返し持ち込まれます。

Dynamic Workflows はこれらすべてに対して **「テナント専用コードを置く」というシンプルな解を提供します。受託の現場では、「カスタマイズの度合いを契約金額に直接マッピングできる」**メリットが大きいです。

受託で組む 4 階層のワークフロー設計

Dynamic Workflows を受託案件に組み込む場合、変更頻度と影響範囲を軸に 4 階層へ分けて考えると整理しやすくなります。

[Tier 0: コア共通ロジック]
  ├ 認証・認可・課金・ロギング
  ├ 全テナント共通・SLA 99.95%
  └ 変更は四半期に 1 回

[Tier 1: 業界別テンプレート]
  ├ EC / 医療 / 金融 / 製造の標準フロー
  ├ 同業界の複数テナントが共有
  └ 変更は月次

[Tier 2: テナント別カスタム]
  ├ 顧客固有の承認フロー・通知
  ├ Dynamic Workflows で個別配置
  └ 変更は週次〜随時

[Tier 3: テナント別エージェント]
  ├ 顧客固有の AI エージェント挙動
  ├ プロンプト・モデル選択・接続先 MCP
  └ 変更は日次

特に Tier 2 と Tier 3 は、これまで「やります」と契約しても保守が破綻しがちな領域でした。Dynamic Workflows は **「テナント別の隔離されたランタイム」を提供するので、「他テナントへの影響リスクなしに変更を入れられる」**という運用メリットがあります。

これは PostgreSQL RLS によるマルチテナント設計 で扱ったデータ層の隔離と対になる、実行ロジック層の隔離です。両方を組み合わせることで、SOC 2 / ISO 27001 のテナント隔離要件を、コード・データの両面で満たすことができます。

コストモデル — アイドル時ほぼゼロの破壊力

Dynamic Workflows のコストモデルは、受託の見積もり構造を根本から変える可能性があります。

特に 「夜間・週末はほぼ使わない業務 SaaS」では効きが大きくなります。従来型はテナント数に比例してワーカー常駐費が積み上がるのに対し、Dynamic Workflows は実際にリクエストが来た分しか課金対象にならないためです。削減幅はテナント数・稼働時間帯・1 実行あたりの処理時間で大きく変わるので、既存構成の実測値を当てはめて試算する必要があります。

これは Claude Code 運用コスト最適化 2026 で扱った “実使用に応じた課金” のさらに先で、「インフラ全体を実使用ベースに寄せる」設計です。

受託契約に書く「マルチテナントワークフロー条項」

Dynamic Workflows を受託案件に組み込むとき、契約書に明記すべき条項を整理します。

特に 「障害時の影響範囲」は、Dynamic Workflows の **「テナント別ランタイム」を活かして、「テナント A の障害は SLA 計算上テナント B に影響しない」**という条文が書けるようになります。これは従来の単一クラスタ SaaS 契約では書けなかった画期的な条項です。

ハマりやすい 5 つの落とし穴

最後に、Dynamic Workflows を受託で運用するときの落とし穴を共有します。

落とし穴 1: Tier 2 が肥大化して「擬似フォーク」になる

テナント別コードを置けるからといって 「全部 Tier 2 で書く」と、結局フォーク運用と同じ保守地獄に陥ります。Tier 1 のテンプレート化を半年に 1 回見直し、Tier 2 から逆輸入できるパターンを抽出します。

落とし穴 2: テナント別ランタイムのデバッグが難しい

「テナント A だけ動かない」事象のデバッグは、全テナント共通コードよりも難易度が高いです。テナント ID を含む構造化ログ + 分散トレーシングを Tier 0 で必ず仕込みます。

落とし穴 3: アイドルコストゼロにテストコストを忘れる

実行時コストは安くても、全テナントに対する CI テストは別問題です。契約毎にテスト対象テナントを限定し、月次でローテーションする設計にします。

落とし穴 4: エージェント挙動の予算が外しやすい

Tier 3 でテナント別 LLM 挙動を持たせると、1 テナントの異常呼び出しで月予算を消化します。テナント別の月次トークン上限を Tier 0 で必ず enforce します。

落とし穴 5: Cloudflare ロックインが進む

Dynamic Workflows は Cloudflare 専用です。「ワークフローを別 Cloud に移植する」コストは線形ではないため、契約に「移植可能性は保証しない」条項を入れ、顧客の認識を合わせます。

まとめ — 「テナント別コード」を受託の標準にする

Cloudflare Dynamic Workflows は、マルチテナント SaaS の 「カスタマイズと保守性のジレンマ」に対する強力な解です。受託の現場で 「顧客別カスタムを継続的に保守できる」ことは、案件の継続率と顧客満足度に直結します。

ただし導入の可否より先に決まるべきなのは、どのカスタマイズを Tier 1 のテンプレートに寄せ、どこから先を Tier 2 に落とすかの線引きです。ここはテナント数、カスタムの重なり具合、既存コードに分岐がどう入り込んでいるかで答えが変わり、それに応じて必要な体制も期間も別物になります。既存 SaaS のマルチテナント化を検討中で、この線引きから一緒に詰めたいという方は お問い合わせフォーム にご相談ください。現在テナント別の分岐がどのファイルまで散らばっているかが分かる状態だと、最初の議論が一段深いところから始められます。

Sources

• Cloudflare Ships Dynamic Workflows, Bringing Durable Execution to Per-Tenant and Per-Agent Code（InfoQ）
• PostgreSQL RLS によるマルチテナント設計（GH Media）
• Cloudflare Code Mode の MCP トークン最適化（GH Media）
• Claude Code 運用コスト最適化 2026（GH Media）