Home Temporal社ブログ解説: From AI Hype to Durable Reality — AIエージェントに分散システムの規律を
投稿
キャンセル

✍️ Temporal社ブログ解説: From AI Hype to Durable Reality — AIエージェントに分散システムの規律を

投稿日 05/04/2026
投稿者 0h-n0
23 分読了時間

本記事は From AI Hype to Durable Reality — Why Agentic Flows Need Distributed-Systems Discipline (Temporal Blog) の解説記事です。

ブログ概要（Summary）

Temporal社のKevin Martin氏は、AIエージェントの本番運用における成功はモデルの高度さではなく、分散システムの基盤設計に依存すると主張している。本ブログでは、Temporalの「Durable Execution（永続実行）」パターンをAIエージェントワークフローに適用することで、リトライ・タイムアウト・イベントソースド履歴・シグナル/クエリといった分散システムの定番パターンを透過的に実現し、脆弱なエージェントフローを本番品質に変換する手法が解説されている。OpenAIがChatGPTの画像生成にTemporalを採用した事例も紹介されている。

この記事は Zenn記事: AIエージェントのエラー回復設計 リトライ・サーキットブレーカー・チェックポイント実践 の深掘りです。

情報源

技術的背景（Technical Background）

AIエージェントの本番運用には、LLM API呼び出し・外部ツール連携・マルチステップワークフローという3つのレイヤーが存在し、各レイヤーで障害が発生し得る。Zenn記事で解説されたリトライ・サーキットブレーカー・チェックポイントは、これらの障害に対する実装パターンであるが、各パターンを個別に実装・管理する負担は大きい。

Temporal社は、これらの耐障害パターンをインフラストラクチャレベルで透過的に提供するDurable Executionプラットフォームを開発している。アプリケーションコードにリトライロジックやチェックポイント管理を直接記述する代わりに、Temporalのワークフローエンジンがそれらを自動的に処理する。

Martin氏によれば、AIシステムは本質的に「偽装された分散システム」であり、GPU/ノード間の並列処理、データパイプラインの一貫性、オーケストレーション協調、オブザーバビリティといった古典的な分散コンピューティングの課題を解決する必要がある。

実装アーキテクチャ（Architecture）

Durable Executionの7つの学び

Martin氏は、AI＋Temporal統合から得られた7つの重要な知見を報告している。

1. AIシステム = 偽装された分散システム

プロダクションAIには、モデル訓練だけでなくGPU並列化・データパイプライン整合性・オーケストレーション・オブザーバビリティの解決が必要であり、これらはすべて分散システムの古典的課題である。

2. Durable Executionによる耐障害性

Temporalが提供する耐障害プリミティブは以下の通りである。

プリミティブZenn記事の対応パターンTemporalでの実現
自動リトライ指数バックオフ付きリトライRetryPolicy設定で宣言的に定義
タイムアウト—schedule_to_close_timeout
イベントソースド履歴チェックポイント回復ワークフロー履歴の自動記録・リプレイ
スケジュール—Cron Workflow
シグナル—外部イベントによるワークフロー通知
クエリ—ワークフロー状態の外部問い合わせ

3. ポリグロット対応

Python、Java、Go、TypeScript、.NET、Ruby、PHPといった複数言語のワーカーをTemporalが統一的に協調させる。エージェントのツール呼び出しが複数言語にまたがる場合でも、単一のワークフローで管理できる。

4. Nexusによるビジネスワークフロー統合

Temporal Nexusは、エージェントワークフローと従来のビジネスワークフローを単一の制御プレーンで統合する。共有の永続性・トレーシング・アラートにより、AI処理と非AI処理の境界を意識せずに運用できる。

5. クラッシュ耐性のある会話

シグナルとクエリにより、プロセス障害を経ても会話状態が保持される。イベントリプレイによりコンテキストが自動復元される。これはLangGraphのチェックポイント機構と概念的に同等であるが、Temporalはアプリケーションコード側でのチェックポイント管理を不要にする点が異なる。

6. 開発速度の向上

Durable Executionにより、ボイラープレートなリトライロジック・チェックポイント管理・障害回復コードが不要になり、開発者はプロンプト設計とモデル選択に集中できる。

7. Durable ToolsによるMCP統合

MCP（Model Context Protocol）ツールをTemporalワークフローとして実装することで、既存のワーカーフリートを活用した水平スケーリングが追加インフラなしで実現される。

Weather Agent実装例

Martin氏は、MCP＋Temporalの統合例としてWeather Agentの実装を示している。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

from temporalio import workflow, activity
from temporalio.common import RetryPolicy
from datetime import timedelta

# リトライポリシーの宣言的定義
# Zenn記事の指数バックオフ + ジッタに相当
retry_policy = RetryPolicy(
    initial_interval=timedelta(seconds=1),
    backoff_coefficient=2.0,
    maximum_interval=timedelta(seconds=30),
    maximum_attempts=3,
)


@activity.defn
async def make_nws_request(url: str) -> dict:
    """National Weather Serviceへのリクエスト

    Temporalが自動でリトライ・タイムアウトを管理する。
    アプリケーションコードにリトライロジックは不要。
    """
    async with httpx.AsyncClient() as client:
        response = await client.get(url)
        response.raise_for_status()
        return response.json()


@workflow.defn
class GetAlertsWorkflow:
    """気象アラート取得ワークフロー

    Temporalのワークフローとして定義することで：
    - 各Activityの実行が自動でチェックポイントされる
    - 障害時はActivity単位で自動リトライ
    - プロセスクラッシュからもワークフロー履歴で復元
    """

    @workflow.run
    async def run(self, state: str) -> str:
        url = (
            f"https://api.weather.gov/alerts"
            f"?area={state}&status=actual&limit=5"
        )
        # schedule_to_close_timeout でタイムアウトを設定
        # retry_policy でリトライ戦略を宣言的に定義
        data = await workflow.execute_activity(
            make_nws_request,
            url,
            schedule_to_close_timeout=timedelta(seconds=40),
            retry_policy=retry_policy,
        )
        alerts = data.get("features", [])
        if not alerts:
            return f"{state}に有効なアラートはありません。"

        return "\n".join(
            f"- {a['properties']['headline']}"
            for a in alerts[:5]
        )

この実装では、Zenn記事で個別に実装した3つのパターンが以下のように置き換えられている。

Zenn記事のパターンTemporal実装
retry_with_backoff() 関数RetryPolicy の宣言的設定
CircuitBreaker クラスTemporalのタイムアウト + Activity失敗ハンドリング
LangGraph MemorySaverTemporalのイベントソースド履歴（自動）

Production Deployment Guide

AWS実装パターン（コスト最適化重視）

TemporalベースのエージェントワークフローをAWSにデプロイする場合の推奨構成を示す。

トラフィック量別の推奨構成:

規模月間ワークフロー数推奨構成月額コスト主要サービス
Small~3,000 (100/日)Temporal Cloud + Lambda$100-200Temporal Cloud + Lambda Workers
Medium~30,000 (1,000/日)Temporal Cloud + ECS$400-1,000Temporal Cloud + ECS Fargate Workers
Large300,000+ (10,000/日)Self-hosted + EKS$2,000-5,000EKS + Temporal Server + PostgreSQL

Small構成の詳細 (月額$100-200):

  • Temporal Cloud: Serverless ($25/月 base + ワークフロー数に応じた従量課金)
  • Lambda Workers: 1GB RAM ($40/月) — Activity実行
  • Bedrock: Claude 3.5 Haiku ($80/月) — LLM推論
  • CloudWatch: 基本監視 ($5/月)

Medium構成の詳細 (月額$400-1,000):

  • Temporal Cloud: ($100-200/月)
  • ECS Fargate Workers: 0.5 vCPU × 2タスク ($120/月)
  • Bedrock: Claude 3.5 Sonnet ($400/月)
  • ElastiCache Redis: cache.t3.micro ($15/月) — セッションキャッシュ
  • ALB: ($20/月)

コスト削減テクニック:

  • Temporal Cloud利用でインフラ管理コスト削減
  • Lambda Workers で低トラフィック時のコスト最適化
  • Bedrock Batch API 使用で50%削減（非リアルタイム処理）
  • Prompt Caching有効化で30-90%削減

コスト試算の注意事項:

  • 上記は2026年4月時点のAWS ap-northeast-1リージョン料金に基づく概算値です
  • Temporal Cloud料金は公式サイトで最新版を確認してください
  • 実際のコストはワークフロー複雑度、Activity実行時間により変動します

Terraformインフラコード

Small構成 (Temporal Cloud + Lambda Workers)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69

# --- Lambda Worker for Temporal Activities ---
resource "aws_iam_role" "temporal_worker" {
  name = "temporal-worker-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action = "sts:AssumeRole"
      Effect = "Allow"
      Principal = { Service = "lambda.amazonaws.com" }
    }]
  })
}

resource "aws_iam_role_policy" "bedrock_and_logs" {
  role = aws_iam_role.temporal_worker.id
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect   = "Allow"
        Action   = ["bedrock:InvokeModel"]
        Resource = "arn:aws:bedrock:ap-northeast-1::foundation-model/anthropic.claude-*"
      },
      {
        Effect   = "Allow"
        Action   = ["logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents"]
        Resource = "arn:aws:logs:ap-northeast-1:*:*"
      }
    ]
  })
}

resource "aws_lambda_function" "temporal_activity_worker" {
  filename      = "temporal_worker.zip"
  function_name = "temporal-agent-activity-worker"
  role          = aws_iam_role.temporal_worker.arn
  handler       = "worker.handler"
  runtime       = "python3.12"
  timeout       = 300
  memory_size   = 1024

  environment {
    variables = {
      TEMPORAL_HOST      = var.temporal_cloud_host
      TEMPORAL_NAMESPACE = var.temporal_namespace
      TEMPORAL_TASK_QUEUE = "agent-task-queue"
      BEDROCK_MODEL_ID   = "anthropic.claude-3-5-haiku-20241022-v1:0"
    }
  }
}

# --- Secrets Manager (Temporal Cloud API Key) ---
resource "aws_secretsmanager_secret" "temporal_api_key" {
  name = "temporal-cloud-api-key"
}

# --- CloudWatch Alarm (Workflow Failure Rate) ---
resource "aws_cloudwatch_metric_alarm" "workflow_failure" {
  alarm_name          = "temporal-workflow-failure-rate"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = 2
  metric_name         = "WorkflowFailureRate"
  namespace           = "TemporalAgent"
  period              = 300
  statistic           = "Average"
  threshold           = 0.1
  alarm_description   = "ワークフロー失敗率が10%を超過"
}

セキュリティベストプラクティス

  • Temporal Cloud接続: mTLS証明書による認証、API Keyの Secrets Manager管理
  • IAMロール: 最小権限（Bedrock InvokeModelとCloudWatch Logsのみ）
  • ネットワーク: VPC PrivateLink経由でTemporal Cloudに接続
  • 暗号化: Temporal Cloud側でペイロード暗号化（Codec Server）を有効化
  • 監査: CloudTrail + Temporal Cloud監査ログの統合

運用・監視設定

CloudWatch Logs Insights クエリ:

1
2
3
4
5
6

-- ワークフロー実行時間の分析
fields @timestamp, workflow_id, duration_ms, status
| stats avg(duration_ms) as avg_duration,
        pct(duration_ms, 95) as p95,
        pct(duration_ms, 99) as p99 by bin(5m)
| filter status = "FAILED"

Temporal メトリクス監視（Prometheus/Grafana）:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

# Temporal SDK が自動でエクスポートするメトリクス
# temporal_workflow_completed_total
# temporal_workflow_failed_total
# temporal_activity_execution_latency
# temporal_workflow_task_schedule_to_start_latency

# CloudWatchへのカスタムメトリクス送信
import boto3

cloudwatch = boto3.client('cloudwatch')

cloudwatch.put_metric_data(
    Namespace='TemporalAgent',
    MetricData=[{
        'MetricName': 'WorkflowCompletionRate',
        'Value': completed / total * 100,
        'Unit': 'Percent',
    }]
)

コスト最適化チェックリスト

アーキテクチャ選択:

  • ~100 ワークフロー/日 → Temporal Cloud + Lambda ($100-200/月)
  • ~1000 ワークフロー/日 → Temporal Cloud + ECS ($400-1,000/月)
  • 10000+ ワークフロー/日 → Self-hosted EKS ($2,000-5,000/月)

リソース最適化:

  • Lambda Workers: メモリ最適化（128MB刻みで調整）
  • ECS: Spot Fargate使用で最大70%削減
  • Temporal Cloud: Actions数削減（不要なSignal/Queryを排除）
  • Activity: 短い実行でheartbeat間隔を最適化
  • Workflow: Continue-as-newで履歴肥大化防止

LLMコスト削減:

  • Bedrock Batch API: 非リアルタイム処理で50%削減
  • Prompt Caching: システムプロンプト固定部分をキャッシュ
  • モデル選択: 簡易タスクはHaiku、複雑タスクはSonnet
  • トークン制限: max_tokens設定

監視・アラート:

  • Temporal Cloud Dashboard: ワークフロー成功率/失敗率
  • AWS Budgets: 月額予算（80%警告）
  • CloudWatch: Activity実行時間異常検知
  • Cost Anomaly Detection: Bedrock費用スパイク検知

パフォーマンス最適化（Performance）

ブログで言及されているOpenAIのChatGPT画像生成におけるTemporal採用事例は、Durable Executionのスケーラビリティを実証するものである。Martin氏によれば、「Temporalは非同期操作を管理し、個々のステップがクラッシュしても信頼性を確保する」とのことである。

Temporalのパフォーマンス特性として以下が挙げられる：

  • ワークフロー再開レイテンシ: イベントリプレイにより、障害からの復旧はミリ秒単位
  • スケーラビリティ: ワーカーの水平スケーリングにより、ワークフロー数に比例したスループット
  • 永続性: PostgreSQL/Cassandraバックエンドによる確実な状態保存

運用での学び（Production Lessons）

Martin氏がブログで強調する運用上の教訓は以下の通りである。

  1. リトライロジックの手書きをやめよ: 指数バックオフ付きリトライを毎回実装する代わりに、RetryPolicyで宣言的に定義する。Zenn記事のretry_with_backoff()関数は教育的価値があるが、本番環境では Temporal のような基盤に委譲するのが推奨される

  2. チェックポイント管理を手動で行うな: LangGraphのMemorySaver/PostgresSaverは有効だが、Temporalのイベントソースド履歴はアプリケーションコード側の意識なく自動的にチェックポイントを取得する

  3. 障害回復をアプリケーション層で解決するな: サーキットブレーカーやDLQの実装は有用だが、Temporal のWorkflow Timeout + Activity RetryPolicy でインフラ層から同等の保護を提供できる

学術研究との関連（Academic Connection）

Temporalの Durable Execution は、以下の学術的概念と密接に関連する。

  • イベントソーシング（Event Sourcing）: Martin Fowler が体系化したパターン。Temporalはワークフローの全履歴をイベントとして記録し、リプレイにより任意の時点の状態を復元する
  • Sagas パターン（Garcia-Molina & Salem, 1987）: 長時間トランザクションを補償アクション付きのステップに分割するパターン。Temporalワークフローは Saga の実装基盤として利用される
  • 分散合意（Paxos/Raft）: Temporal Server 内部での状態管理に使用される分散合意アルゴリズム

まとめと実践への示唆

Temporal社のブログは、AIエージェントのエラー回復をアプリケーション層の実装パターンからインフラ層の透過的な保護へと昇華させるアプローチを提示している。Zenn記事で解説されたリトライ・サーキットブレーカー・チェックポイントの各パターンは、Temporal の RetryPolicy・Timeout・Event Sourced History によって宣言的かつ自動的に実現される。

実務者にとっての選択は、「自前実装による完全な制御」と「プラットフォーム委譲による運用負荷軽減」のトレードオフである。小規模なエージェントではZenn記事のパターンをPythonで直接実装するのが適切だが、マルチステップ・マルチサービスの本番パイプラインではTemporalのようなDurable Executionプラットフォームの採用を検討する価値がある。

参考文献

blog tech_blog
Temporal durable execution AI agent retry fault tolerance distributed systems MCP workflow
この投稿は CC BY 4.0 でライセンスされています。
最近の更新
目次