10月29日、Datadogが「Default to serverless for AI agents, then let production data decide what moves」と題した記事を公開した。AIエージェントのワークロードにサーバーレスをデフォルトの実行モデルとして採用し、本番データをもとに配置を最適化する方法について詳しく紹介されている。
AIエージェントはほとんどの時間、待機している
Datadogがこの記事で指摘する核心的な事実は、AIエージェントの計算リソースのほとんどは遊んでいる、という点だ。
3万5,000件以上の本番コーディングエージェントセッションを分析した研究によると、セッション全体のうちLLMやツール呼び出しが実際に動いていた時間の中央値は**わずか20%**。残り80%はステップ間の待機時間で、その間もサンドボックスはリソースを確保したままだった。
常時稼働型のコンピュートを用意すれば、この80%のアイドル時間にも課金が発生する。サーバーレスであれば、リクエストが来たときだけリソースが確保され、需要がなければゼロにスケールダウンする。Datadogはこれを根拠に「AIエージェントにはまずサーバーレスをデフォルトとして検討すべき」と主張している。
ワークロード配置の判断：実行プロファイルを作る
記事が提案する最初のステップは、実行プロファイル（Execution Profile） の作成だ。これはエージェントのワークロード特性と実行要件をまとめたもので、「常時稼働が必要か、オンデマンドで十分か」を判断する材料になる。
プロファイルに含めるべき主な項目：
- トリガーと到着パターン
- 同期・非同期・ストリーミングの応答パターン
- ピーク到着レートとバースト持続時間
- ピーク時の同時実行数
- レスポンスタイム目標（最初の出力または完了までの最大許容時間）
- 1回の実行あたりの「アクティブ計算時間」と「合計経過時間」
この2つの比率が特に重要な指標だ。アクティブ計算時間が合計経過時間に対して低い比率であれば、オンデマンド実行が適している。高い比率かつ安定した到着頻度であれば、専用ワーカーの方が経済的になる可能性がある。
日次平均だけを見ると判断を誤る点も記事は強調している。「1日1,000イベント」は平均すると1分未満に1件で小さな常時稼働ワーカーで十分に見えるが、実際には全1,000件が夜間バッチで一気に到着するケースでは、そのワーカーは処理しきれない。ピーク到着レートとバースト持続時間を分析して判断する必要がある。
長時間・再開可能なエージェントには「Durable Serverless Workflow」
単一の関数呼び出し内で完結するエージェント実行であれば、そのままFunctionやサーバーレスコンテナで動かせばよい。問題は、複数ステップにまたがる長時間実行や、人間の承認待ちなど途中でポーズが必要なケースだ。
こうした用途向けに記事が推奨するのがDurable Serverless Workflow（耐久性のあるサーバーレスワークフロー）だ。構成要素は以下の3つ：
- オーケストレーター：進捗を記録し、各ユニットの実行可否を判断
- サーバーレス実行プリミティブ（Functions、サーバーレスコンテナ、マネージドジョブ）：実際の処理を実行
- 外部ストア：実行プロセスが終了しても残すべきデータを保持
ワークフローは「Bounded Unit of Work（境界付き作業単位）」に分割し、各ユニットに入力・出力・完了/失敗条件を定義する。ステップ完了後やポーズ後にオーケストレーターが進捗をチェックポイントとして記録することで、失敗時も最初からやり直す必要がなくなる。また、リトライ時に外部副作用（メール重複送信、二重課金など）が発生しないよう各ステップを設計することも重要だ。
具体的なサービスとしては、AWS Step Functions・Google Cloud Workflows（ステートマシンや外部ワークフロー定義でステップを調整）、Azure Durable Functions・AWS Lambda（アプリケーションコードでステップと待機を表現）が挙げられている。
LangChainやVercel AI SDKなどのエージェントフレームワークを使っている場合、記事は「外部のDurableオーケストレーターがワークフロー状態・スケジューリング・再開を担い、エージェントフレームワークは各ステップ内のモデル・ツール操作を担う」という役割分担を推奨している。Datadogの調査では、エージェントフレームワークの採用率は2025年から2026年にかけてほぼ倍増したとされており、この設計判断は多くのチームに関係する。
コスト比較は「成功1件あたりのコスト」で
オンデマンド vs ウォームキャパシティ vs 専用ワーカーのコスト比較では、「1回の呼び出しコスト」ではなく「成功1実行あたりのコスト」で比較することを記事は強調している。
例として挙げられているのは以下のケースだ：
- 研究エージェントが1日100回実行を開始
- 80回は完了レポートを生成（成功）
- 15回は失敗（計算・オーケストレーションコストが発生）
- 5回は承認待ちで放棄
- 合計コストは12ドル
この場合、成功1件あたりのコストは12÷80＝0.15ドル。100回すべてで割ると0.12ドルになるが、これは失敗分のコストを隠してしまう。
コスト比較に含めるべき項目は、計算時間・オーケストレーション遷移・状態ストレージ・ネットワーク転送・テレメトリーデータ。モデルやツールの費用は配置によって変わらなければ除外できるが、リトライや失敗で追加呼び出しが発生する場合は含める必要がある。
本番データが出たら、問題のあるステップだけ動かす
本番稼働後は、エージェントの挙動を継続的に監視し、実行プロファイルと比較することでアーキテクチャ変更の判断材料とする。
ここで記事が注意を促しているのは、レイテンシの原因を特定してから配置を変えるという順序だ。例えば、不要なリトリーバル呼び出しやモデルのターン数がレイテンシの大半を占めているなら、ワーカーをウォームにしても解決しない。一方、コールドスタートが応答時間予算の大部分を消費しているなら、ウォームキャパシティが有効だ。
DatadogのAPMとAgent Observabilityを使うと、エージェント実行のレイテンシ内訳を単一トレースで確認でき、問題がステップレベルなのかオーケストレーション層なのかを区別できるとしている。
詳細はDefault to serverless for AI agents, then let production data decide what movesを参照していただきたい。
