Amazon Bedrockバッチ推論を活用した10,000人規模のユーザー分析アーキテクチャ

参考になった

レビュー投稿日の情報になります

株式会社ユーザベース / keyamin

メンバー / フルスタックエンジニア・プロダクトエンジニア / 従業員規模: 1,001〜5,000名

最終更新日2026/03/02投稿日2026/03/03

利用機能	ツールの利用規模	ツールの利用開始時期	事業形態
バッチ推論, ガードレール	5,001名以上	2025年11月	B to B

利用機能	バッチ推論, ガードレール
ツールの利用規模	5,001名以上
ツールの利用開始時期	2025年11月
事業形態	B to B

アーキテクチャ

アーキテクチャの意図・工夫

コールバックパターンによる非同期ジョブ管理

バッチ推論は完了まで数時間かかることがあります。定期的にステータスを確認するポーリング方式では無駄なAPI呼び出しとコストが発生するため、Step FunctionsのWAIT_FOR_TASK_TOKENを使ったコールバックパターンを採用しました。 Bedrockジョブ完了時にEventBridgeがイベントを検知してLambdaをトリガーし、LambdaがStep Functions に対しSendTaskSuccessを呼び出します。

Map 状態による並列処理

週次数千件のデータを効率よく処理するため、Step FunctionsのMap状態で並列実行する構成を採用しました。週次バッチが500件単位でJSONLファイルに分割してS3にアップロードし、Lambdaがファイル一覧を取得してMapに受け渡します。

導入の背景・解決したかった問題

導入背景

NewsPicksの法人事業では、「週間レポート」や「学びのコレクション」といった法人専用機能の中でAIを活用した価値提供を行う機能を開発していました。週間レポートでは、法人プラン会員のうち対象者およそ7,000人に対して記事閲覧傾向の分析をLLMで行う機能を開発していました。

ツール導入前の課題

週次で約7,000人分のデータをLLMでまとめて処理する必要がありました
- 1人あたり、inputは2000token、outputは300tokenが目安
オンデマンド推論のクォータ（当時のAmazon Bedrock Claude Sonnet 4では20万token/分）では全員の分析に数時間かかる見込みでした
加えてオンデマンド推論ではリトライやスロットリング対策の実装により複雑度が増す懸念がありました

どのような状態を目指していたか

10,000件規模でもクォータを意識せずにまとめて推論を行いたい
非同期のバッチジョブで推論したい
- 日曜日にジョブ開始し、月曜朝までに終わっていれば問題ないくらいの温度感でした
炎上リスクのあるような問題のある出力はエンドユーザーに届く前に除外されるようにしたい

比較検討したサービス

OpenAI API
Anthropic Claude API
Amazon Bedrockのオンデマンド推論

比較した軸

性能やスループットが安定しているか
社内のLLM利用セキュリティガイドラインに則っており、スムーズに導入できるかどうか

選定理由

AWS利用料金とまとめて請求してもらえる
既存のAWSインフラとの親和性が高い
AWS環境では、CloudTrailやCloudWatchのログを監視する仕組みやOktaとの統合が既に確立されていたため、セキュリティポリシーを満たしていることを説明しやすかった

導入の成果

現状コスト、エラー発生率、推論にかかる時間について想定内で運用できています。バッチ推論の使用により、今回の規模だと年間およそ30万円程度のコスト削減になりました。元々期待していた週間レポートへのアクセスも1.5~2倍程度に増え、一定の効果を実感できています。

導入時の苦労・悩み

(主にAmazon Bedrockのバッチ推論やガードレールを使用するにあたって)

最小レコード制約への対応

バッチ推論には1ジョブあたりの最小レコード数制約がありました（当時は100件）。週次数千件を500 件単位で分割すると、最終バッチが最小件数を満たさない可能性がありました。

解決策: 最小件数未満の端数は前バッチにマージするロジックを実装しました。

出力品質の担保

大量バッチ処理では推論失敗、ガードレールの違反、出力された文字列のJSONフォーマットエラーなど多様な失敗パターンが発生します。特にバッチ推論ではガードレールを入力パラメータで直接指定できず、品質担保の仕組みを独自に構築する必要がありました。

解決策:

StepFunctionsビルトインの機能を活用し、最大4回の自動リトライ機構を実装しました。
Bedrock ガードレールのApplyGuardrail APIを使用して出力に対して個別にチェックを行うようにしました。
これまでは出力が期待したJSONスキーマになっているかを個別ロジックでバリデーションしていましたが、最近Structured outputs機能が発表されたため、入力でJSONスキーマを指定するだけで出力フォーマットが保証されるようになりました。

プロンプトキャッシュの非対応

Bedrockのコスト削減手法としてプロンプトキャッシュも一般的ですが、バッチ推論とは併用できません。今回のユースケースではプロンプトキャッシュを使用した方が料金は安くなりましたが、バッチ推論の運用面のメリットを選択しました。

導入に向けた社内への説明

上長・チームへの説明

最初はバッチ推論やプロンプトキャッシュを知らず、愚直にオンデマンド推論で実装する方針だったため、機能に対して想定よりコストがかかる点がネックでした。しかしバッチ推論を使用すればモデル使用料金が半額になるため解決しました。
当時社内LLM利用セキュリティガイドラインでClaudeの利用が一部制限されていました。こちらは上述の通り、AWSのサービスであることでログ監視、IAM Roleによる権限管理ができていることをスッと説明でき、スムーズに許可がおりました。

活用方法

よく使う機能

バッチ推論: 大量の推論をまとめて行う、非同期で良い、という今回のユースケースにマッチしているため活用しています。
ガードレール: 問題のある出力をエンドユーザーに届く前に除外するため、API経由で活用しています。
Cost Explorer: アプリケーション推論プロファイルの使用やバッチ推論ジョブへのタグ付けにより、機能・ユースケースごとに個別にモデル使用料を確認することが可能です。毎週確認している他、異常検出機能も活用してモニタリングしています。

ツールの良い点

AWSエコシステムとの親和性の高さ: StepFunctionsによりオーケストレーションできたり、結果をEventBridgeで受信できたりと、既存システムがAWS上で動いていればシームレスに統合できます。コストもCost Explorerで確認でき、アプリケーション推論プロファイルを使用することでユースケース別のコストも確認できます。
コスト50%削減: 大量の推論を行うユースケースでは、オンデマンド推論と比較して半額になるインパクトが非常に大きいです。
スロットリングを気にしなくてよい: AWS側でスケジューリング・実行を管理するため、大量リクエスト時のスロットリング対策が不要です。

ツールの課題点

最小レコード数の制約: 1ジョブあたり最小 100レコードが必要で、小規模バッチの場合にマージ処理などのワークアラウンドが必要になります。
プロンプトキャッシュ非対応: バッチ推論とプロンプトキャッシュは併用できないため、システムプロンプトが大きいユースケースではオンデマンド推論でプロンプトキャッシュを活用する方がコスト効果が大きいです。
所要時間の予測が困難: バッチ推論の完了までの時間が数分〜数時間と幅があり、SLAの設計が難しいです。

今後の展望

Structured outputsのようなアップデートは今後も多く出てくると思うので、継続的にキャッチアップしてアーキテクチャを改善していきたいです。
現在エラー発生時は500件単位でまとめてリトライしていますが、より最適化するのであればリトライはオンデマンド推論で個別に行うようにしたいです。
今後対象者が増えたり、同じAWSアカウント上で他の機能でもバッチ推論を使用する場合、バッチ推論の並列数が増えるため、同時に実行可能なバッチ推論数の考慮が必要です。Claude Sonnet 4.6では100件がデフォルトクォータなので、ジョブ実行時にアカウントで実行中の推論一覧を取得して制御したり、EventBridgeなどを活用してジョブ実行状況をDynamoDBで一元管理するのが良さそうです。
- StepFunctionsのMapでは最大同時実行数を指定できるので、ここでクォータを超えない範囲で指定することが可能です。例えば20並列を指定したMapに30個のアイテムが投入された場合、まず20個が処理され、終わって空きがでたところから残り10個が処理されます。
- バッチ推論では他にも1ファイルあたりの最大行数、ファイルあたりの最大容量、ジョブあたりの最大容量などのクォータがあるため注意が必要です。

株式会社ユーザベース / keyamin

メンバー / フルスタックエンジニア・プロダクトエンジニア / 従業員規模: 1,001〜5,000名