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 は以下の根本的な変化を持ち込みます。
| 項目 | 従来の Durable Execution | Dynamic Workflows |
|---|---|---|
| ワークフロー定義 | 静的・全テナント共通 | テナント別に動的差し替え |
| デプロイ単位 | アプリ全体 | 1 テナントの 1 ワークフロー |
| アイドルコスト | コンテナ常駐分が発生 | ほぼゼロ |
| カスタマイズ | strategy パターンで分岐 | テナント別コードを直接配置 |
| 数 | 数十〜数百ワークフロー | 数百万のユニーク版 |
特に 「テナント別コードを直接配置できる」点が、受託の 「顧客ごとに違う業務フロー」にそのまま刺さります。これは Cloudflare Code Mode の MCP トークン最適化 で扱った「コードを動的に動かす」思想を、ワークフローレイヤーまで押し上げた形です。
受託マルチテナント SaaS の典型的な悩み
弊社が請ける SaaS 受託案件では、ほぼ毎回以下の悩みが顧客から出ます。
| 顧客の悩み | 旧アプローチの問題 |
|---|---|
| 大手顧客から「うちだけ承認フローを 3 段階にしてほしい」 | コードに if 文が増殖し、保守不能に |
| 業界別に通知タイミングが違う | テナント設定 JSON が肥大化し、全条件のテストが困難 |
| 「うちはこの SaaS と連携、他社はこの API」 | 連携先 SDK が全部同梱されてビルドサイズが膨張 |
| カスタマイズの SLA を別にしたい | 単一クラスタで隔離できず、ノイジーネイバー問題 |
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 のコストモデルは、受託の見積もり構造を根本から変える可能性があります。
| 項目 | 従来（Temporal Cloud / Step Functions） | Dynamic Workflows |
|---|---|---|
| アイドル時の月額 | テナント数 × ワーカー常駐費 | ほぼゼロ |
| 実行コスト | 状態遷移ごと | リクエスト + 実行時間 |
| 起動レイテンシ | 数秒〜（ワーカー起動） | 数十ミリ秒（Workers のコールドスタート） |
| テナント追加コスト | 線形に増加 | アクティブな分のみ |
特に 「夜間・週末はほぼ使わない業務 SaaS」で破壊的なコスト削減が見込めます。100 テナントのうち日中しかアクセスのない案件で、月額固定費を 70 〜 85% 削減できる試算が出ています。
これは Claude Code 運用コスト最適化 2026 で扱った “実使用に応じた課金” のさらに先で、「インフラ全体を実使用ベースに寄せる」設計です。
受託契約に書く「マルチテナントワークフロー条項」
Dynamic Workflows を受託案件に組み込むとき、契約書に明記すべき条項を整理します。
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| Tier 区分 | コア / テンプレート / テナント / エージェントの境界 | 自社カスタムが Tier 2 か Tier 3 か |
| デプロイ権限 | 誰が Tier 2/3 を変更できるか | 顧客側で変更可能にするか |
| テスト責任 | Tier 2/3 のテストカバレッジ責任 | ステージング環境の有無 |
| 障害時の影響範囲 | 1 テナントの障害が他テナントに波及しない保証 | SLA 計算の単位 |
| コスト按分 | テナント別の実コスト計上方式 | 月次レポートの粒度 |
| エージェント挙動の上限 | LLM 呼び出し回数・トークン上限 | 月次の予算アラート |
特に 「障害時の影響範囲」は、Dynamic Workflows の **「テナント別ランタイム」を活かして、「テナント A の障害は SLA 計算上テナント B に影響しない」**という条文が書けるようになります。これは従来の単一クラスタ SaaS 契約では書けなかった画期的な条項です。
価格モデル — マルチテナント受託パッケージ
Dynamic Workflows を組み込んだ受託パッケージの価格レンジは以下のとおりです。
| プラン | 初期 / 月額 | 対象 | 内容 |
|---|---|---|---|
| MT Starter | 200 万円 / 15 万円〜 | 5 テナント以下 | Tier 0/1 + 1 顧客分の Tier 2 |
| MT Standard | 600 万円 / 50 万円〜 | 6 〜 50 テナント | Tier 0/1/2 + テナント別ステージング |
| MT Enterprise | 1,500 万円〜 / 120 万円〜 | 50 テナント以上 | 全 Tier + エージェント運用 + 24h 監視 |
特に MT Standard は、「数十社の顧客にカスタムフローを提供したいが、1 社ずつコードフォークしたくない」という典型的な悩みに刺さるレンジです。
ハマりやすい 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 の 「カスタマイズと保守性のジレンマ」に対する強力な解です。受託の現場で 「顧客別カスタムを継続的に保守できる」ことは、案件の継続率と顧客満足度に直結します。
弊社では MT Starter / Standard / Enterprise の 3 段階で Dynamic Workflows を組み込んだマルチテナント SaaS 受託パッケージを提供しています。「既存 SaaS をマルチテナント化したい」「顧客カスタマイズで保守が破綻しそう」というご相談は お問い合わせフォーム からお気軽にどうぞ。
