生成AIを組み込んだシステム開発において、「先月のAWS請求額が予測の10倍になっている」といった相談が実務の現場で寄せられることがあります。原因を調査すると、無限ループに陥ったLambda関数が、高価なLLM APIを叩き続けていたというケースが少なくありません。決して笑い話ではなく、生成AIを従来のWeb開発の感覚で組み込んだときに誰にでも起こりうる「事故」なのです。
「まず動くものを作る」プロトタイプ思考で、最新のツールを駆使して仮説を即座に形にすることは非常に重要です。しかし、Amazon BedrockとAWS Lambdaを組み合わせてAI機能を本番環境へ実装する際には、こうした落とし穴を回避するアーキテクチャ設計が不可欠になります。単に「動くもの」を作るだけでなく、技術の本質を見抜き「本番で事故らないシステム」を設計し、ビジネスへの最短距離を描く。それが、プロフェッショナルなエンジニアの流儀ではないでしょうか。
なぜ「いつものLambda」では失敗するのか：LLM連携の特殊性
普段、AWS Lambdaを使ってREST APIを構築しているエンジニアにとって、外部APIとの連携は日常茶飯事でしょう。データベースを叩く、決済サービスを呼ぶ、メールを送る。これらの処理は、長くても数秒、早ければミリ秒単位で完了します。しかし、相手がLLM（大規模言語モデル）となると、話は全く別次元になります。
従来のAPI連携とは異なる「不確実なレイテンシー」
生成AI、特にClaudeの最新モデルのような高度な推論を行うハイエンドモデルは、思考（推論）に時間を要します。複雑なプロンプトや長文の生成をリクエストした場合、レスポンスが返ってくるまでに30秒、あるいは1分以上かかることも珍しくありません。
従来のシステム設計では、レイテンシー（応答遅延）は「最小化すべき悪」でした。しかし生成AIにおいては、レイテンシーは「知能の代償」として受け入れなければならない特性です。この「いつ終わるかわからない処理」を、ステートレスで短命なLambda関数の中で同期的に待つこと自体に、アーキテクチャ上の無理が生じています。
トークン課金が生む「見えないコストリスク」
さらに厄介なのがコスト構造です。従来のAPIは「1リクエスト＝◯円」という課金体系が多いですが、BedrockのようなLLMは「入力トークン数 ＋ 出力トークン数」で課金されます。
もし、Lambda関数内でエラーハンドリングが不十分で、意図せず巨大なコンテキストを含むリクエストを再試行（リトライ）し続けたらどうなるでしょうか？ Lambdaの実行時間課金だけでなく、Bedrockのトークン課金も雪だるま式に膨れ上がります。経営者視点で見れば、これは許容できない財務リスクです。
ステートレスなLambdaとコンテキスト維持の矛盾
Lambdaは基本的にステートレス（状態を持たない）です。しかし、LLMとの対話はコンテキスト（文脈）が命です。「前の会話を覚えている」状態を作るために、毎回データベースから会話履歴を読み込み、プロンプトに含めて送信する。この処理自体が重くなり、Lambdaのメモリと実行時間を圧迫します。
「いつもの感覚」で同期的なAPI Gateway + Lambda構成を採用すると、システムは脆くなり、コストも跳ね上がります。ここからは、具体的なリスクを3つの観点で深掘りし、その対策を見ていきましょう。
リスク1：タイムアウトと「15分の壁」への対処
最初の壁は、物理的な時間の制約です。AWSのサーバーレスサービスには、それぞれ厳格なタイムアウト設定が存在します。これを知らずに実装を進めると、本番環境で「Gateway Timeout」の嵐に見舞われることになります。
Lambdaの実行時間制限とAPI Gatewayの29秒ルール
Lambda関数自体の最大実行時間は15分まで設定可能です。「なんだ、15分あればLLMの回答なんて余裕じゃないか」と思いましたか？ 問題は、Lambdaの前段にいるAPI Gatewayです。
REST APIモードのAPI Gatewayには、29秒というハードリミット（変更不可能な制限）があります。つまり、バックエンドのLambdaがどれだけ頑張って処理を続けていても、29秒以内にレスポンスを返さなければ、クライアント（フロントエンド）側には「504 Gateway Timeout」エラーが返されてしまうのです。
生成AIが長文を生成している最中に通信が切断される。ユーザー体験としては最悪ですよね。
同期呼び出しが招く「ゾンビプロセス」のリスク
さらに怖いのは、API Gatewayがタイムアウトして接続を切った後も、Lambda関数自体は処理を継続している可能性があることです（一般に「ゾンビプロセス」と呼ばれる状態です）。
ユーザーはエラー画面を見て、もう一度「送信」ボタンを押すでしょう。すると、裏側では新しいLambdaが起動し、前のLambdaもまだ動いている。二重、三重にBedrockへのリクエストが飛び、課金だけが発生し続ける。誰も幸せにならない状況です。
【対策】非同期処理パターンの導入と分離
この問題を解決する唯一の正解は、「待たない」ことです。
フロントエンドからのリクエストを受け取ったら、バックエンドは「受け付けました（HTTP 202 Accepted）」とだけ即答し、実際のAI処理はバックグラウンド（非同期）で行う。処理が終わったら、WebSocketやポーリングで結果をクライアントに通知する。この「リクエスト受付」と「処理実行」の分離こそが、生成AIアプリ開発の鉄則です。
リスク2：青天井になりかねないコストの暴走
2つ目のリスクは、従量課金のクラウドサービスを組み合わせる際、最も警戒すべき「コストの暴走」です。自動化されたプロセスが予期せぬ挙動を起こした場合、短時間で想定外の請求が発生するケースは珍しくありません。
無限ループによる再帰呼び出しの恐怖
最も危険なシナリオは、AIがAIを呼び出す構成や、エラー時の自動リトライ設定ミスによる無限ループです。
例えば、AIエージェントが「タスク未完了なら再実行」というロジックを持つ場合を想像してください。AIが「完了」と判定できない限り、Lambdaは繰り返し起動し、BedrockのAPIを呼び続けます。適切な停止条件やループ回数の上限（サーキットブレーカー）が実装されていない場合、一晩で数ヶ月分の予算を消費してしまうリスクがあります。
Lambdaの待機時間課金とBedrock利用料の二重苦
同期処理で実装した場合、Bedrockが回答を生成している数秒から数十秒の間、Lambda関数は待機状態となります。AWS Lambdaは処理中の待機時間も課金対象（メモリサイズ × 時間）です。
つまり、高価な生成AIモデルの利用料が発生している間、単に待機しているだけのLambdaにもコストがかかるという「二重課金」の状態です。これはリソース効率の観点からも最適化すべき課題と言えます。
【対策】ガードレール設定とコスト監視アラート
技術的な防衛策として、Amazon Bedrock Guardrailsの活用が有効です。これは主に有害なコンテンツや個人情報をフィルタリングする機能ですが、プロンプトインジェクションによる意図しない動作や、モデルの暴走的な出力を防ぐことで、結果的に無駄なトークン消費を抑制する効果が期待できます。最新情報は公式ドキュメントで確認することをお勧めします。
さらに、AWS Budgetsによる予算アラートの設定は必須です。「1日の利用料が設定額を超えたらアラートを通知する」だけでなく、異常なコスト急増を検知した場合にLambdaの同時実行数を制限して強制停止させるような、フェイルセーフな仕組みを開発環境の段階から組み込んでおくことを強く推奨します。
リスク3：スロットリングとクォータ制限の罠
3つ目のリスクは、システムがスケールした時に顕在化する「制限（クォータ）」の問題です。開発環境では問題なく動作していても、本番環境でユーザー数が増加した途端に壁にぶつかるケースは珍しくありません。
Bedrockの分間スループット制限（TPM/RPM）
Amazon Bedrockには、モデルごとに1分間あたりのリクエスト数（RPM：Requests Per Minute）とトークン数（TPM：Tokens Per Minute）の制限が設けられています。特に、Claudeの最新モデルなどの高性能なLLMは、軽量モデルと比較してデフォルトの制限が厳格に設定されている傾向があります。
マーケティングキャンペーンなどでユーザーアクセスが急増した際、この制限に達すると ThrottlingException が発生し、正常なレスポンスが返らなくなります。さらに、この制限はリージョン単位で適用されるため、同一アカウント内の他のサービスが同じモデルを使用している場合、互いにリソースを食い合ってしまう可能性もあります。
リトライストーム（再試行の嵐）による二次被害
ここで避けるべきなのが、「エラーが出たら即座にリトライする」という単純な実装です。スロットリングが発生しているということは、すでにAPIが手一杯の状態であることを意味します。そこで全クライアントが一斉にリトライをかけたらどうなるでしょうか？
さらに負荷が高まり、復旧しかけたシステムにトドメを刺すことになります。これを「リトライストーム」と呼びます。クラウドシステム全体で障害が拡大する原因の多くが、この制御されていないリトライ処理にあると言われています。
【対策1】エクスポネンシャルバックオフとジッターの実装
リトライを行う際は、Exponential Backoff（指数関数的バックオフ）とJitter（ジッター：ゆらぎ）を組み合わせるのが定石です。
1回目は1秒後、2回目は2秒後、3回目は4秒後……と待機時間を倍々に増やしていくのがExponential Backoffです。そこにランダムな時間（Jitter）を加えることで、リクエストのタイミングを分散させ、リトライストームを防ぎます。
Step Functionsを使用する場合、ステートマシンの定義（ASL）で Retry フィールドを設定する際に、BackoffRate（倍率）や IntervalSeconds（初期待機時間）、MaxAttempts（最大試行回数）を指定することで、このロジックを宣言的に実装可能です。コードを書かずに堅牢なリトライ戦略を構築できる点は、Step Functionsを採用する大きなメリットと言えるでしょう。
【対策2】SQSを活用した流量制御（スロットリング対策）
さらに堅牢な設計を目指すなら、Lambda関数の手前に Amazon SQS（Simple Queue Service） を配置するアーキテクチャが推奨されます。
リクエストを一度SQSキューに受け入れ（バッファリング）、Lambda関数が処理できるペースでキューからメッセージを取り出すことで、Bedrockへのリクエスト流量を制御します。これを「リーキーバケット（Leaky Bucket）」パターンと呼びます。
Lambdaの「予約された同時実行数（Reserved Concurrency）」を設定し、SQSのバッチサイズと組み合わせることで、BedrockのRPM制限を超えないように調整することが可能です。突発的なスパイクアクセスがあっても、キューが溢れた分を一時的に保持してくれるため、バックエンドのAIモデルを守りながらシステム全体の安定性を維持できます。
【解決策】堅牢なイベント駆動アーキテクチャの実装パターン
さて、ここまでリスクについて詳しく解説してきましたが、安心してください。これらの課題を包括的に解決するアーキテクチャ・パターンがあります。それが、AWS Step Functionsを中心としたオーケストレーションです。
Step Functionsによるオーケストレーションの採用
Step Functionsは、複数のAWSサービスをワークフローとして連携させるサービスです。なぜこれがBedrock連携において強力なソリューションなのか、理由は以下の通りです。
- 状態管理を任せられる: Lambdaはステートレスですが、Step Functionsはステートフルです。「AIの回答待ち」という状態を保持できます。
- 待機時間のコスト削減: Step Functionsの「Standardワークフロー」を使用し、
.waitForTaskTokenパターンなどを活用すれば、AIの処理を待っている間、Lambdaを停止させることができます。待機中のStep Functionsにはほとんどコストがかかりません。 - リトライ制御の簡素化: 指数関数的バックオフやエラーハンドリングを、コードではなく設定（JSON/YAML）で定義できます。コードがシンプルになり、バグが減ります。
「Lambdaは待たない」：ジョブ投入とポーリング/Webhookの分離
推奨するアーキテクチャは以下の通りです。
- API Gateway + Lambda (Frontend): ユーザーからのリクエストを受け取り、Step Functionsを実行開始（StartExecution）して、即座に実行IDを返却します。所要時間は数百ミリ秒。
- Step Functions:
- Task 1: Bedrockを呼び出すLambdaを実行（またはSDK統合で直接呼び出し）。
- Task 2: AIの応答をデータベース（DynamoDBなど）に保存。
- Task 3: 処理完了を通知（SNSやWebSocket API経由）。
- Client: 実行IDを使って定期的にステータスを確認（ポーリング）するか、WebSocketで完了通知を受け取る。
この構成なら、API Gatewayの29秒ルールに縛られることはありませんし、Lambdaが待機時間で課金され続けることもありません。
エラーハンドリングとデッドレターキュー（DLQ）の設計
Step Functionsを使えば、Bedrockがエラーを返した際に「3回までリトライし、それでもダメなら管理者へメール通知して終了」といった分岐も視覚的に設計できます。
処理に失敗したリクエストは、Amazon SQSのデッドレターキュー（DLQ）に送るようにしましょう。これにより、失敗したデータ（プロンプトなど）が消失するのを防ぎ、後から原因究明や再実行が可能になります。「データは資産」ですから、エラー時も捨ててはいけません。
運用フェーズでの「転ばぬ先の杖」チェックリスト
最後に、システムをリリースする前に確認してほしいチェックリストを共有します。これらをクリアしていれば、自信を持って「本番稼働」へと進めるはずです。
リリース前に確認すべきクォータ設定値
- Bedrockのモデルアクセス権: 使用するリージョンで対象モデルが有効化されているか？
- スループット制限: 想定ユーザー数に対し、TPM/RPMの上限緩和申請は済んでいるか？
- Lambdaの同時実行数: 他のシステムに影響を与えないよう、必要に応じて予約済同時実行数を設定しているか？
CloudWatch Logs/Metricsでの監視項目
- Bedrockのエラー率:
ThrottlingExceptionやModelTimeoutの発生頻度。 - トークン消費量: 入出力トークン数の推移（コスト直結）。
- Step Functionsの実行時間: 異常に長く実行され続けているフローはないか？
万が一の暴走を止める緊急停止手順（キルスイッチ）
- コスト異常検知時のアクション: AWS BudgetsのアラートでSlack通知が飛ぶようになっているか？
- 手動停止フロー: 暴走したStep FunctionsやLambdaを一括停止するスクリプトや手順書は用意されているか？
まとめ
生成AIの統合は、単なるAPIの実装ではなく、非同期処理と分散システムの設計力が問われるチャレンジングな領域です。しかし、今回解説した「タイムアウト対策」「コスト管理」「流量制御」の3つのリスクを理解し、Step Functionsを活用したアーキテクチャを採用すれば、恐れることはありません。
リスクを技術で制御し、ビジネス価値を生み出すAIシステムを構築する。それこそが、エンジニアの腕の見せ所であり、経営視点からも求められる真の価値です。皆さんのAIプロジェクトが成功し、より革新的なサービスが世に生まれることを期待しています。何か疑問があれば、ぜひチーム内で議論を深めてみてください。
コメント