サーバーレスで「重い」AIバッチを回す憂鬱
「LambdaでAI推論を並列実行すれば、安くて速いバッチが作れる」というアプローチは、サーバーレス開発において広く知られています。しかし、プロジェクトがPoC（概念実証）から実運用フェーズに入り、処理対象がテキストデータ数千件から、画像を含むマルチモーダルデータ数万件にスケールした瞬間、この前提は通用しなくなることが実務の現場ではよく見られます。
Lambdaの「15分タイムアウト」の壁、同時実行数の制御不能によるAPIレート制限エラー、そしてリトライ処理でゾンビのように増え続けるCloudWatchログの山…。特に画像解析とLLM（大規模言語モデル）によるメタデータ生成を組み合わせたワークフローでは、個々の処理時間が予測しづらく、Lambda単体でのオーケストレーションは運用負荷の増大を招きがちです。
そこで今回の検証テーマは、AWS Step Functionsの「Distributed Map（分散マップ）」です。
「サーバーレス・オーケストレーションの決定版」とも謳われるこの機能は、果たして実運用における最適解となるのか、それともコスト増をもたらす要因となるのか。10万件の画像処理データを想定したケーススタディを通じて、その実力を論理的かつ批判的にレビューしていきます。
サーバーレスAIバッチの「壁」とDistributed Mapの登場
マルチモーダル処理がLambdaを殺す理由
従来のテキスト処理メインの時代なら、LambdaとSQS（Simple Queue Service）の組み合わせで十分運用可能でした。しかし、画像や音声を伴うマルチモーダルAIが当たり前になった今、その常識は通用しなくなっています。
例えば、「商品画像を読み込み、OpenCVで前処理し、OpenAIの最新ビジョン対応モデルでタグ付けを行う」というフローを想像してみてください。以前のモデルから現在はさらに高度な推論が可能な最新モデルへと進化していますが、Lambda単体でこれを扱うには構造的な限界があります。
- 依存ライブラリの肥大化: 画像処理ライブラリを含めるだけで、Lambdaのレイヤー容量制限（250MB）に肉薄します。これはコンテナイメージを使えば回避可能ですが、コールドスタートの遅延という別の課題を招きます。
- 実行時間の不確実性: 外部AI APIのレスポンス待ちは、モデルの性能向上に伴い計算量が増えるため、依然として数秒から数十秒、場合によってはそれ以上かかることがあります。Lambdaは「待っている時間」に対しても課金（実行時間×メモリ）が発生するため、コスト効率が極めて悪くなります。
- 状態管理の欠如: 「画像処理は成功したが、API呼び出しでタイムアウトした」といった部分的失敗の際、Lambda単体では「どこからリトライすべきか」の制御ロジックをアプリケーションコード内に複雑に組み込む必要があります。
これらを解決しようとLambda関数内で無理やりループ処理を書けば、15分のタイムアウト制限という「壁」に衝突します。かといって、小さなLambda関数をイベントで数珠繋ぎにするアーキテクチャは、エラーハンドリングが分散し、運用が複雑怪奇になりがちです。
オーケストレーターとしてのStep Functionsの進化
ここでStep Functionsの出番ですが、かつての「Map State（インラインマップ）」には同時実行数（最大40）や処理件数に厳しい制限があり、大規模バッチには不向きでした。このボトルネックを打破するために登場したのがDistributed Mapです。
これはS3上のCSVやJSONファイルを直接読み込み、最大1万並列で子ワークフローを実行できる強力な機能です。理論上は、数百万件のデータであってもサーバーレスアーキテクチャでさばける計算になります。しかし、カタログスペック上の数値と、実際の現場での使い勝手には乖離があるのが常です。次章から、その詳細な挙動と検証結果を見ていきましょう。
検証対象：AWS Step Functions Distributed Mapの実力
大規模並列処理に特化したアーキテクチャ
Distributed Mapが画期的なのは、「データの反復処理」をステートマシン自体から切り離した点にあります。2026年1月現在も、このアーキテクチャは大規模バッチ処理における推奨パターンとして確立されています。
従来のアプローチでは、入力配列をステートマシンのペイロードとして渡す必要がありましたが、これにはペイロードサイズ制限（最大256KB）という物理的な壁がありました。Distributed Mapでは、S3上のオブジェクトリストを直接ソースとして指定できます。つまり、リスト自体が何GBあろうと、Step Functions側で自動的に分割（バッチング）し、子ワークフローに渡してくれるのです。この仕組みにより、開発者はデータの分割ロジックを実装することなく、純粋なビジネスロジックに集中できます。
料金体系の構造的特徴
ここで最も注意すべきはコスト構造です。Step Functionsには「Standard」と「Express」の2つのワークフロータイプがあり、それぞれの特性を理解した使い分けが重要です。
- Standard: 状態遷移（State Transition）ごとに課金されます。実行履歴が全て残り、可視性が高いのが特徴です。
- Express: 実行時間とメモリ使用量で課金されます。安価ですが、履歴保持期間が短いという制約があります。
Distributed Mapを使用する場合、親フローはStandardで全体を管理し、子フロー（実際の処理部分）はExpressで組むのが定石です。例えば10万件の処理を行う際、全てをStandardで実行して状態遷移課金を積み上げるのは、コスト効率の観点から避けるべきです。
一方で、Expressワークフローにも考慮すべき点があります。それは「実行時間課金」です。AI推論のようにAPI待ち時間が発生する処理では、待ち時間中も課金され続けます。Lambdaのランタイムは進化を続けており（2026年1月には.NET 10のサポートなどが追加されています）、処理速度は向上していますが、外部API呼び出しに伴う待機時間は依然としてコスト要因となります。Lambda単体実行とStep Functions Express実行のコスト分岐点をどこに見極めるかが、アーキテクトやプロジェクトマネージャーとしての腕の見せ所になります。
実装レビュー：画像×テキスト解析パイプラインの構築
本記事では、実践的なユースケースとして以下のフローを想定します。
- Input: S3バケット内の商品画像（JPEG）10万枚のリスト
- Process A: 画像のリサイズとベクトル化（Lambda + OpenCV/PyTorch）
- ※PyTorchのような大容量ライブラリを使用する場合、Lambdaのデプロイパッケージ制限を回避するためコンテナイメージでの運用が一般的です。
- Process B: ベクトルデータを元にLLMでキャプション生成（Lambda + OpenAIの最新モデル）
- ※OpenAIのAPIは進化が速く、利用可能なモデルや機能が頻繁に更新されます。実装の際は必ず公式ドキュメントで最新の仕様をご確認ください。
- Output: 結果をDynamoDBに保存
Workflow Studioを用いたローコード定義の実際
AWSコンソールの「Workflow Studio」は、ドラッグ＆ドロップで構成を作れるため、プロトタイピングには非常に優秀です。Distributed Mapの設定も、GUI上で「データソース：S3」「バッチサイズ：10」といった具合に直感的に行えます。
ただし、詳細なエラーハンドリング（CatchやRetry）の設定を始めると、結局はASL（Amazon States Language）というJSONベースの定義ファイルを直接編集することになります。特にAI処理特有の「RateLimitExceeded」エラーに対する指数バックオフ設定などは、GUIよりもコードで管理した方が確実です。
開発体験とデバッグのしやすさ
ここで特筆すべきはRedrive機能です。10万件中、500件だけエラーになったとします。従来のバッチなら「失敗分だけ抽出して別ジョブで流す」という面倒な運用が必要でした。
Distributed Mapでは、コンソールから「失敗したアイテムのみ再実行（Redrive）」ボタンを押すだけです。これは開発中の試行錯誤において、劇的な工数削減につながります。AIモデルのパラメータ調整で何度も再実行が必要なシーンでは、この機能だけで導入価値があると言えるほどです。
パフォーマンスとコストの現実：10万件処理データ公開
ここからが本題の「Proof（証明）」フェーズです。10万件のダミーデータを処理するケースを想定し、パフォーマンスとコストの現実を分析します。
スループットとコールドスタートの影響
- 並列数設定: 最大並列数（MaxConcurrency）を1000に設定
- 処理時間: 約18分で完了（想定値）
Lambda単体でSQSトリガーを用いた場合と比較しても、スループット自体に大きな遜色はありません。しかし、Distributed Mapの真価は「外部APIとの親和性」と「並列数の精密制御」にあります。
特にOpenAIなどのLLMプロバイダーは、利用するモデル（最新の推論モデルや軽量モデルなど）によってレート制限（RPM/TPM）が厳格に定められています。2026年現在も、提供されるモデルのラインナップや仕様は頻繁に更新され、旧世代モデルの廃止や新モデルへの移行が急速に進んでいます。これに伴い、APIのレート制限ポリシーも変動することが珍しくありません。
Lambda + SQS構成では、Lambdaの同時実行数（Reserved Concurrency）で制御を行いますが、これはAWSアカウント全体のリミットと競合しがちです。Distributed Mapであれば、外部APIの仕様変更に合わせてMaxConcurrency: 50のようにバッチジョブ内だけの並列数を動的に、かつ即座に調整可能です。さらに、最新の運用トレンドとして推奨されているCloudWatchメトリクスを活用したパフォーマンス最適化と組み合わせることで、APIのスロットリングを回避しつつ、リソース効率を最大化する構成が容易に実現できます。
エラーハンドリングの堅牢性
意図的に5%の確率でAPIエラーが発生する状況を想定した場合の挙動を比較します。
- Lambda単体: DLQ（Dead Letter Queue）に送られたメッセージの解析と再処理スクリプトの実装が別途必要。
- Distributed Map: 自動リトライ機能により約3%は自動回復。残りの2%は「失敗リスト」としてS3に出力され、前述のRedrive機能でコードを書かずに復旧可能。
運用工数の観点では、Distributed Mapが圧倒的に有利です。特に大量データを扱うバッチ処理において、リカバリの手順が標準化されていることは、運用チームの負担を劇的に軽減します。
Lambda単体構成とのコスト比較
気になるコストですが、一般的な試算として以下のようになります（※us-east-1リージョン概算）。
| 項目 | Lambda + SQS構成 | Step Functions (Express) Distributed Map |
|---|---|---|
| コンピュート費用 | $15.00 | $15.00（Lambda実行費は同等） |
| オーケストレーション費用 | $0.40 (SQS/CloudWatch) | $10.50 (状態遷移/実行時間) |
| 開発・運用工数 | 3人日（リトライ実装等） | 0.5人日 |
| 合計TCO | 初期構築費高 / ランニング安 | 初期構築費安 / ランニング高 |
この結果は重要です。単純なAWS利用料だけ見れば、Distributed Mapを使うことでオーケストレーション費用は約25倍に跳ね上がります。
しかし、TCO（総保有コスト）の観点では評価が逆転する可能性が高いと言えます。複雑なエラーハンドリングの実装工数削減に加え、外部AIモデルの頻繁な世代交代（旧モデルの廃止や新機能追加）への追随コストを考慮する必要があるからです。
APIの仕様変更やモデル切り替えが発生した際、疎結合なワークフローであれば最小限の修正で対応できるため、長期的な運用負荷を大幅に低減できるでしょう。また、CloudWatch等の可観測性ツールとの連携強化も進んでおり、トラブルシューティングにかかる時間の短縮効果も見逃せません。目先のAWS利用料だけでなく、運用エンジニアの人件費やビジネス機会損失のリスクを含めた全体最適の視点で選定することが、ROI最大化を目指すプロジェクトマネジメントにおいて重要です。
導入の落とし穴と注意点
素晴らしい機能ですが、AI駆動開発においてハマりやすい落とし穴がいくつかあります。
ペイロードサイズ制限の制約
Step Functionsの入出力ペイロード制限は256KBです。マルチモーダルAI開発でやりがちな「画像データ（Base64エンコード文字列）を次のステートに渡す」実装は即座にエラーになります。
必ず「画像はS3に置き、パス（URI）だけを渡す」設計にしてください。Distributed Mapの子ワークフロー間でも同様です。大きなJSONレスポンスを返すLLMを使う場合も注意が必要です。必要であれば、結果も一度S3に書き出し、パスだけを返すラッパーLambdaを挟む必要があります。
ダウンストリームサービスへのDDoSリスク
「最大1万並列」は諸刃の剣です。設定ミスでMaxConcurrencyを指定し忘れると、1万個のLambdaが一斉に起動し、接続先のRDSや外部APIに過剰な負荷をかけます（DDoS攻撃と同様の状態になります）。
特にAI推論のエンドポイントはレート制限が厳しいことが多いので、最初はMaxConcurrency: 5程度から始め、徐々に上げていく「カナリアリリース的なバッチ実行」を強く推奨します。
CloudWatchログの洪水とコスト
ExpressワークフローでログレベルをALLにすると、膨大なログが出力されます。10万件処理すると、ログのIngestion（取り込み）費用だけでLambda実行費を超えることがあります。本番環境ではERRORのみにするか、サンプリングレートを下げる設定を忘れないでください。
結論：Distributed Mapは「買い」か？
結論として、AWS Step Functions Distributed Mapは、以下の条件に当てはまるプロジェクトにとって「買い」であると断言できます。
- データ量が数万件以上あり、処理時間が長時間に及ぶ大規模バッチである。
- 外部API（生成AIモデルやAIエージェント等）を利用しており、レート制限への対応や厳密な並列数制御、リトライ制御が必要不可欠である。
- 開発リソースが限られており、複雑な分散処理フレームワークを自作・保守する余裕がない。
特に2026年現在、Amazon BedrockをはじめとするAIマネージドサービスの拡充に伴い、複数のAIモデルやデータソースを組み合わせるワークフローは複雑化しています。こうした環境下で、AWS公式情報でも推奨されているCloudWatchメトリクスを活用した可観測性の確保や、エラーハンドリングの標準化を低コストで実現できる点は大きなメリットです。
逆に、処理が単純でエラー時のリカバリも「全件再実行」で済むような小規模バッチや、コストに極めてシビアなプロジェクト（リクエスト単位の利益率が低い場合）では、従来のLambda + SQS構成、あるいはAWS Batch（Fargate/EC2）の方が適しています。
AI駆動開発において、エンジニアは「モデルの精度」に注目しがちですが、ビジネス価値を担保するのはそれを支える「パイプラインの堅牢性」です。多少のAWS利用料増は、運用の安定性と将来的な機能拡張（AIエージェントの組み込みなど）への「安心料」として割り切り、運用で楽をする。それがプロジェクトマネージャーやアーキテクトの賢い選択と言えるでしょう。
あなたのプロジェクトでは、このトレードオフをどう評価しますか？
コメント