11月11日、Cloud Native Nowが「Why AI Workloads Are Driving a New Wave of Serverless Event-Driven Design」と題した記事を公開した。AIワークロードの特性がサーバーレス・イベント駆動アーキテクチャへの移行を加速させている技術的な背景と、実装上の具体的な指針について詳しく論じている。
「LLMをリクエストハンドラに直結する」という失敗パターン
記事はある典型的な失敗から始まる。チームがLLM呼び出しをHTTPリクエストハンドラに直接組み込む。デモは5人のユーザーで動作するが、本番環境は1週間以内に壊れる。モデル呼び出しに40秒かかり、APIゲートウェイが先にタイムアウトし、クライアントがリトライし、そのリトライが誰も回答を受け取れなかったリクエストのトークン費用を2倍にする。
この問題の根本はインスタンスサイズではなく、システムの形状にある。解決策はキューファーストのイベント駆動設計だ。なぜそうなのか、4つの圧力要因から整理する。
圧力1：同期APIはモデルのレイテンシを吸収できない
従来のWeb設計はレスポンスが数百ミリ秒で返ることを前提にしている。しかしマルチステップのエージェント処理、長文書の要約、バッチ埋め込みジョブは30秒から数分かかる。
Amazon API Gatewayにはインテグレーションタイムアウトの制限が存在し、AWSはその制限緩和の理由としてLLMワークロードへの対応を明示的に挙げている。ただし緩和には代償がある——アカウントレベルのスロットル枠を削る必要があり、同一アカウントの他のAPIにも影響が及ぶ。さらにLambdaには1呼び出しあたり15分という上限がある。
※編集部の考察：元記事に「2024年6月」という緩和日付の記載があるかは確認が取れないため、具体日付の表記は外している。AWSの公式制限についてはAmazon API Gateway quotasも参照されたい。
イベント駆動設計はこの待機依存を断ち切る。APIはリクエストを検証してジョブレコードを書き込み、SQS・Pub/Sub・Service Bus・KafkaといったキューにイベントをパブリッシュしてジョブIDとともに202を1秒以内に返す。ワーカーが非同期でジョブを処理し、Webhook・WebSocket・ポーリングで結果を届ける。クライアントの接続断が処理の成否を左右しなくなる。
圧力2：アイドル状態のGPUは高くつく
元記事が引用するレポートによると、AWS・Azure・GCP上の約23,000のKubernetesクラスターを対象とした調査では、**平均GPU使用率はわずか5%**だ。CPUでも8%にとどまる。
5%使用率では20倍のGPU容量を使わずに払い続けている計算になる。同レポートではアイドル状態のH100のオンデマンドコストを月約8,850ドルと試算している。ただし、最も最適化されたフリートでは49%の使用率を達成しており、改善の余地は大きい。
※編集部の考察：元記事がこのデータをCast AIの2026年レポートとして引用しているかどうか、版次・発行時期の詳細は元記事本文で確認していただきたい。編集部では出典の独自補足は行っていない。
AIトラフィックはバースト性が高い——夜間のドキュメント取り込み、業務時間中のコパイロット、週次レポート生成は長い空白時間を挟む。KubernetesならKEDA（Kubernetes Event-driven Autoscaling）でキュー深度に応じてワーカーをスケールさせる手法が有効だ。CPUよりもキュー深度の方が正直なシグナルになる。GPUバウンドなワーカーはCPUから見ればアイドルに見えても、実際には飽和している場合があるためだ。
圧力3：リトライのバグが請求書を膨らませる
これが最もエンジニアに刺さる部分だ。
モデルAPIはリクエスト数とトークン数でスロットリングする。10万件のドキュメントを1件あたり20,000入力トークンで処理する夜間ジョブを考える——合計2億トークン、$3/百万トークンの仮定で**$6,000になる。リトライのバグで各ドキュメントが3回再処理されると$18,000**だ。さらに悪いことに、スロットリングが同じクォータを共有するユーザー向けトラフィックに波及し、バッチのバグが本番障害になる。
対策は以下の3点をセットで実装することだ：
- 最大同時実行数をイベントソースマッピングに設定し、クォータを超えないようにする
- デッドレターキュー（DLQ）に3回受信失敗後にルーティングする
- 冪等性キー（ドキュメントIDとプロンプトバージョンのハッシュなど）を必ずメッセージに付与する
SQS標準キューはat-least-once配信なので重複は必ず発生する。冪等性キーがなければ同じトークンを二重に払うことになる。
圧力4：ステートフルなワークフローエンジンで脆弱なチェーンを置き換える
エージェントパイプラインは検索・モデル呼び出し・ツール呼び出し・場合によっては人間の承認をチェーンする。これを1つのFunctionの中で実行すると、ステップ6の失敗がステップ1〜5に費やしたコストを無駄にする。
AWS Step Functions、Azure Durable Functions、Temporalのようなワークフローエンジンはステップ間で状態を永続化するため、リトライは中断点から再開できる。Step FunctionsのStandardワークフローは最大1年間実行を継続できる。ローン審査や医療記録が審査者を数日待つようなケースに対応できる。
ただし課金モデルに注意が必要だ。Standardワークフローはステート遷移ごとに課金されるため、10,000件のループ内でモデルを呼び出す設計は費用が積み上がる。タスクの性質が許す場合はバッチ処理を検討すべきだ。
Serverlessが適さない場面
記事は過度な推奨を避けて冷静に線引きしている。LambdaはGPUを提供しない（執筆時点）。セルフホストのモデルサービングには依然としてGPUインスタンスか管理された推論エンドポイントが必要だ。
Serverlessが活きるのはモデルの「周辺」——インジェスト、オーケストレーション、ルーティング、ガードレールチェック、後処理だ。RAGアプリケーションのドキュメントストレージ・チャンク分割・埋め込み・インデキシングはその好例で、S3・マネージドナレッジベース・サーバーレスベクトル検索でGPUなしに実装できる。
また、イベント駆動システムは静かに失敗する点にも注意が必要だ。2つのキューの間でメッセージが消えてもエラーは出ない。すべてのホップにコリレーションIDを伝播させ、エラーレートだけでなくキューエージとDLQの深さをアラートの対象にすることを推奨している。
リリース前の3つのチェック
記事が示す実践的チェックリストをそのまま紹介する：
- モデルを呼び出す同期パスをすべて洗い出し、p99レイテンシとゲートウェイタイムアウトを比較する
- バッチジョブと共有モデルクォータの間に必ずキューと同時実行数の上限を挟む
- 課金対象の呼び出しをトリガーするすべてのメッセージに冪等性キーを付与する
これを実装したチームは、AIのレイテンシ・スロットリング・コストを「インシデント」ではなく「設定値」として扱えるようになる、と記事は締めくくっている。
詳細はWhy AI Workloads Are Driving a New Wave of Serverless Event-Driven Designを参照していただきたい。
