背景
AWS Summit Japan 2026 のセッション「TBSテレビ『ラヴィット！』大規模配信の裏側と AWS サーバーレス設計」で、TBSテレビ メディア技術局 未来技術革新事業部の亀田さんが Kustamie というインタラクティブ配信プラットフォームの技術設計を話してくれた。数万人規模の双方向配信という条件で、低遅延映像とリアルタイムインタラクションを安定させながら、集中アクセスから API・DB・バックエンドを守る設計の話だった。
TBSテレビは日本の民放キー局のひとつで、『ラヴィット!』は月曜から金曜の朝 8 時に放送している朝の情報バラエティ。公式は「日本一明るい朝番組」と言っている。「ラヴィット!忘年会'25」は番組 IP を使った年末特別 LIVE 配信で、2025 年に活躍したメンバーがこたつを囲んで 1 年を振り返り、視聴者もオンラインで参加できる形にした。
これは単なる映像配信ではなく、番組として初めて試みた視聴者参加型イベントだった。視聴者は見るだけでなく、出演者にまつわる企画・インタラクション・クイズにリアルタイムで参加する。特定時間に集中アクセス・リアルタイムチャット・インタラクション制御・映像配信をまとめて捌くオンラインイベントとして作られていた。
セッションの良かった点は、大規模配信で起きがちな問題を個別に切り出して話していたところだ。映像ストリームと業務 API の責務分離、Lambda のキャパシティプランニング、実際のユーザー行動モデリング、多段キャッシュ、同期パスのスリム化、小モデルを使った高頻度コンテンツモデレーション。それぞれ具体的な数値と設計判断がついていた。
Kustamie の概要
TBS Tech Portal によると、Kustamie は開発中の「番組・イベント双方向参加アプリ」だ。普通の VOD や単純なライブプレイヤーとは違い、生放送やイベントで起きがちな一方通行の状況に対して、クイズ・リアクション・マルチアングル配信などのインタラクション機能で出演者と参加者の双方向交流を強め、「参加している感」を高めることを目的にしている。
Kustamie が同時に捌かなければいけない行動は複数ある。視聴者がイベントページを開く、番組情報とインタラクションコントロールを取得する、リアルタイムチャットに入る、低遅延映像を見る、タイミングを合わせて企画に参加する。これらが配信前後に集中して発生する。映像配信・リアルタイムインタラクション・業務 API・状態管理・コンテンツモデレーションを同じイベント体験の中に収め、数万人が同時参加しても安定させるのが技術的な問題だった。
アーキテクチャの全体像
Kustamie の通信は大きく 2 本に分けられている。
ひとつはイベント情報の系統。クライアントが Amazon API Gateway を通じて複数の Lambda に接続し、Lambda から ECS のアプリケーションサービスを呼ぶ。バックエンドは ElastiCache と Amazon RDS / Aurora Serverless v2 で状態を持つ。番組メタデータ・参加状態・インタラクションコントロール定義など、比較的構造化された業務データを扱うパスだ。
もうひとつは映像・音声・リアルタイムインタラクションの系統。クライアントは WebSocket で IVS Chat に接続し、映像ストリームは Amazon IVS Low-Latency / Real-Time を通る。ECS が IVS に interactive data を注入することで、クライアントは映像のタイムラインに合わせてインタラクションイベントを発火できる。
この分割が後の最適化の前提になっている。コメント・弾幕・映像配信といった高頻度リアルタイムデータを API Gateway + Lambda + RDS のパスに流さず、IVS / IVS Chat のマネージド fan-out に任せた。API パスに残るデータは変化頻度も一貫性要件も低くなるので、キャッシュと非同期化を入れる余地が生まれる。
アーキテクチャで少し珍しいのは、API Gateway の後ろに Lambda があり、さらにその後ろに ECS がある構成だ。薄い Lambda + 厚い ECS という設計で、Lambda が認証・パラメータ検証・レート制限・軽量オーケストレーションを担い、ECS が重い業務ロジックと DB 接続プールを持つ。Lambda が Aurora に直接接続する際の接続管理問題を避けられる代わりに、サービス間呼び出しが一回増える。
最初の問題点
大規模配信に向けて最初に出てきた問題は、既存のクライアント API がキャッシュを前提に設計されていなかったことだ。スライドでは API Gateway が Regional endpoint を使っていて、Edge-Optimized type の方が適切だと指摘していた。ただ、Edge-Optimized endpoint と「キャッシュ」は別の話で、Edge-Optimized は主に TLS termination とエントリポイントを CloudFront エッジに置くもの。バックエンドへのリクエストを実際に止めるのは API Gateway stage cache か自前の CloudFront キャッシュ設定の方だ。
ユーザーが日本に集中していて API も ap-northeast-1 にデプロイされているなら、Regional endpoint が本質的に Edge-Optimized より劣るとも言いにくい。本当に問題なのは、数万人が短時間にクライアントを開いたとき、番組メタデータや参加入口状態の GET リクエストが毎回 Lambda・ECS・RDS まで通り抜けてしまうことだ。
もっと直接的な問題もある。配信参加 API のレスポンスが最長 12 秒に達していた。複数の直列内部呼び出し・Aurora Serverless v2 のバースト時スケールアップ遅延・VPC Lambda のコールドスタート・外部コントロールプレーン API 呼び出し、このあたりが重なった結果だろう。スライドでも「多数の内部 API コールによるサーバー間通信のオーバーヘッド」と明示していた。また、体系的な負荷テストをそれまで実施していなかったため、高負荷下での挙動が事前に把握できていなかったと正直に話していた。
Lambda のキャパシティプランニング
API Gateway + Lambda の容量を考えるときは、少なくとも 3 つの指標を同時に見る必要がある。
ひとつはAPI Gateway の throttle rate。デフォルトは region / account レベルで 10,000 req/s で、申請すれば引き上げられる。
ふたつめはLambda concurrent executions。Little’s Law で近似できる。
$$ \text{concurrency} = \text{requests per second} \times \text{duration in seconds} $$毎秒 10,000 リクエストで 1 件あたり 0.1 秒なら、定常並行数は 1,000 になる。Lambda のデフォルト account concurrency limit とちょうど一致する。
みっつめが一番見落とされやすいLambda のスケーリングレートだ。実行時間が短くても RPS が高い関数は、定常並行数は小さく見えても、ランプアップ段階でスケーリングレートに引っかかる。コールドスタート中の init も concurrent slot を使うので、インスタンスが実際にリクエストを処理する前から容量を食われる。
短い関数で起きる誤算
スライドで 2 つのケースが示されていた。
関数が 0.1 秒で終わり、リクエスト量が 10,000 req/s のケース。並行数は 1,000 でスケーリングレートも 10,000 req/s、デフォルト設定で耐えられる。
関数が 0.05 秒で終わり、リクエスト量が 20,000 req/s のケース。並行数は同じく 1,000 でデフォルトの並行クォータ内に収まる。しかしスケーリングレートは 20,000 req/s が必要になり、デフォルト能力を超えてスロットリングが起きる。
ポイントは「平均実行時間が短いほど良い」ではないことだ。短い関数 + 高 RPS の組み合わせはプレッシャーをスケーリングレートに転嫁する。Little’s Law で定常容量を見ているだけだと、この問題は隠れやすい。
スライドでの対策は並行クォータを 2,000 に引き上げることだった。ただし AWS の Lambda スケーリングレートの公式な説明は account concurrency quota と単純には比例しないので、実際の現場ではクォータ事前申請・Provisioned Concurrency の利用・Lambda に飛び込むリクエスト量の削減・超高頻度のホットパスを常駐サービスに移す、といった手段を組み合わせることが多い。
負荷テストの設計
負荷テストツールは k6 を選んだ。スクリプトが JavaScript / TypeScript で書けるのでエンジニアがレビューしやすく、Go のランタイムなのでリソース効率も良い。AWS Prescriptive Guidance も k6 を負荷テストツールのひとつに挙げている。
テストの構成は、プレッシャーをかけるアカウントと Kustamie のアカウントを分けた。管理ノードは t3.medium、大規模 worker は c6i.2xlarge を使用。100 から 5,000 VU の中規模テストはローカル PC で実行でき、5,000 から 60,000 VU の大規模テストは EC2 worker クラスタを起動する。
アカウントを分ける理由は分離だ。負荷テストが生む CloudWatch Logs・コスト・IAM ロール・サービスクォータを本番アカウントに混入させない。スクリプトを誤って書いてしまっても影響範囲を抑えやすい。
k6 の出力が示していた点も参考になった。http_req_duration の p95 は綺麗に見えても、iteration_duration の max は数十秒になっていることがある。サーバーレスアーキテクチャでは平均値や p95 だけでは不十分で、ロングテールこそがユーザーが体感するひっかかりになる。
シナリオのモデリング
このスライドはセッション全体の中でも特に参考になった。負荷テストは固定 RPS を叩くのではなく、実際にユーザーが配信に入ってくる曲線をシミュレートした。
Kustamie のシナリオ設定は、待機配信開始時点ですでに最大 VU の 10% がオンライン、その後 30 分の待機配信期間に VU が指数的に増加し、本編開始時に最大値に達する、というものだった。この曲線は過去の類似イベントのデータから作ったもので、感覚値ではないらしい。
配信やイベント系プロダクトのトラフィックはたいてい線形に伸びない。開始 30 分前はコアなファンだけで、5 分前から一般ユーザーが入り始め、開始の数十秒前に集中アクセスが来る。この指数的な末尾が Lambda のスケーリングレート・API Gateway throttle・DB 接続プール・外部 API rate limit のすべてにぶつかる。この曲線を再現しなければ、本当の問題は出てこない。
負荷テストの結果
E2E テストの結果はシンプルだった。リクエスト量が毎分 60 万回、平均 10,000 RPS を超えたあたりから 4xx エラーが増え始めた。API Gateway のデフォルト throttle rate とぴったり一致する数字だ。
Lambda 側にエラーが見られなかったので、問題は API Gateway 層で起きていると判断した。スライドでも正直に書いてあったが、API Gateway の標準メトリクスは 4xx が見えても具体的なエラー種別は区別できない。正確に切り分けるにはアクセスログを有効にして、ステータス・requestId・エラーメッセージ・スロットリング関連のコンテキストを記録する必要がある。
最終的に 2 種類のクォータを申請した。API Gateway の throttle rate を 30,000 RPS、Lambda concurrent executions を 50,000 に引き上げた。Lambda の 50,000 は一見過剰に見えるが、指数増加の末尾・コールドスタート・短い関数のスケーリング・安全マージンを考えると、定常並行数だけのために確保した数字ではないとわかる。
大規模サーバーレスシステムでは、サービスクォータを本番後の後付け作業にしてはいけない。デプロイ前のチェックリストに入れて、テストアカウントと本番アカウントで揃えておく。
多段キャッシュ
パフォーマンス改善の最初の手は多段キャッシュだった。
1 段目はAPI Gateway stage cacheで、GET リクエストのみに適用する。ヒットするとリクエストは API Gateway 内で完結し、Lambda すら起動しない。番組メタデータ・UI 設定・インタラクションコントロール定義のような、読み取り頻度が高く短い TTL で許容できるデータに向いている。
2 段目はLambda global variables。Lambda 実行環境が再利用されるとき、ハンドラ外部で宣言した変数は再初期化されないので、設定・ID マッピング・JWT 公開鍵・初期化コストが高いクライアントオブジェクトをキャッシュできる。インスタンス間では共有されないし、コンテナはいつ回収されるかわからないので、強一致が必要な状態を置くのは危険だ。
3 段目はECS + ElastiCache for Valkey。アプリケーションサービス側で RDS クエリを遮断する。Valkey は Redis 7.2 とほぼ互換で、AWS は Redis のライセンス変更を受けて Valkey への推進を強めている。性能面での選択でもあるが、ライセンスとコストの要因もある。
多段キャッシュの原則はシンプルで、リクエスト元に近いほどヒット時のバックエンド節約が大きい。API Gateway stage cache は Lambda・ECS・DB をまるごとスキップする。Lambda global cache は後段サービス呼び出しを省く。ElastiCache は RDS クエリを省く。
キャッシュの無効化がそれほど難しくないのは、最初から高頻度リアルタイムデータを IVS Chat に逃しているからだ。API パスに残るデータは大半があらかじめ用意されているか、変化が予測可能なもの。TTL ベースの失効で大半のシナリオはカバーできる。
非同期化と 150ms
最大の改善は非同期化だった。配信参加 API のレスポンスが最大 12,000ms から平均 150ms 前後に下がった。約 80 倍の改善だ。
発想はシンプルで、「ユーザーがすぐ必要なものだけを同期パスに残す」。同期パスは API Gateway から Lambda に入り、Step Functions Express Workflow で UserID 生成・IVS Token 生成・SQS へのエンキューを完了させる。ユーザーがすぐ視聴を始めることに関係しない処理は、SQS 経由で非同期パスに流し、Lambda と ECS がバックグラウンドで消費する。
パラメータを調整したわけではなく、「何を同期完了させるべきか」を再定義した。ユーザーがすぐ配信に入るには UserID と IVS Token が必要なので同期で返す。登録レコード・関連状態・履歴の書き込みなどは後回しにできる。
IVS Realtime Token の扱いも重要なポイントだ。スライドでは IVS の API call rate が 50 TPS で上限変更不可と書いてあった。60,000 ユーザーが集中して入ってきたとき、一人ひとりが IVS API を直接呼ぶと即座にコントロールプレーンの制限に当たる。だからトークンは Lambda がローカルで署名発行する。秘密鍵で生成する JWT なので、rate limit のある API 呼び出しを検証可能なローカル暗号演算で置き換えるパターンだ。S3 presigned URL や CloudFront signed URL / cookies も同じ発想だ。
Step Functions で Express Workflow を選んだのも理にかなっている。このフローは高頻度・短時間なので、Standard Workflow のような長時間の持続化と完全な実行履歴は必要ない。コストと遅延の面で Express の方が軽量なオーケストレーションに向いている。ワークフローの並行上限に達したとき、呼び出し側の Lambda でリトライを実装しているというのも、マネージドサービスを使う構成ではよくある現実的な対処だ。
AI チャットモデレーション
Kustamie はチャットコンテンツのモデレーションに Amazon Nova Micro を使っている。フローはこうだ。ユーザーのメッセージが WebSocket 経由で IVS Chat に入ると同時に、Data Firehose 経由でバックエンドストレージに流れ、そこから Lambda がトリガーされて Bedrock を呼ぶ。モデルが違反と判定したらシステムが状態を更新し、IVS Chat に delete message リクエストを送る。
これは後置審査で、事前審査ではない。つまりメッセージはまず表示されてから、非同期で判定・削除される。数秒分の安全余白を犠牲にする代わりに、チャット体験のリアルタイム性を保つ設計だ。バラエティ番組のようなシナリオでは後置審査で許容できることが多い。ただし子ども向けコンテンツや政治系配信・金融系カスタマーサポートなど、リスクが高い場合は事前審査や人間によるレビューを入れるかどうかを改めて考える必要がある。
Firehose の役割は転送だけではない。バラエティ配信の弾幕は番組の盛り上がりと連動して波を打つので、直接逐次処理すると Bedrock 呼び出しのピーク値が上がり、モデルの遅延がユーザー体験に直接出てくる。非同期のストリーム処理はこの種の高頻度・短遅延許容タスクに向いている。
Nova Micro の呼び出し
Nova Micro の呼び出しサンプルでは、入力が複数メッセージの JSON 配列で、出力も対応する順序の構造化配列だった。categories が配列で表現されているのは、ひとつのメッセージが複数の違反カテゴリに同時に引っかかる可能性があるため。空配列なら問題なし。language フィールドで言語識別も一緒にやっている。
注目したのはバッチ処理の部分だ。サンプルでは 5 件を 1 バッチにして全体のレイテンシが 1.6 秒だった。1 件あたり平均 320ms になるが、それだけではなくコストとスループットの意味もある。システムプロンプトは 1 回送ればいいし、ネットワークリクエストと Bedrock のルーティングコストも分散できる。後置審査なら数件溜まってからまとめてモデルを呼ぶのは合理的なトレードオフだ。
Nova Micro がこのシナリオに合っているのは、タスクの性質が高頻度・低複雑度のテキスト分類だからだ。複雑な推論も長いコンテキスト生成も必要ない。何より安くて遅延が低い。大規模弾幕シナリオで大きなモデルを 1 件ずつ判定させるのは過剰だろう。
モデル選定の比較
スライドではいくつかの候補が比較されていた。
Amazon Comprehend Trust and Safety は言語サポートが問題だ。コンテンツ安全分類には向いているが、当時は英語のみのサポートで日本語のバラエティ配信には対応できなかった。
Bedrock 上のサードパーティサーバーレスモデル (Claude など) は多言語能力に優れているが、発表者の評価では応答速度が遅いとのことだった。Kustamie のシナリオでこの判断に現実的な根拠があるのはわかる。Nova Micro は AWS 自前の小モデルで、遅延とコストが高頻度分類に向いている。ただしこの比較には明らかな欠落がある。精度のデータが示されていない。
コンテンツモデレーションは速度だけで語れない。日本語の弾幕には同音異義・ネットスラング・引用・皮肉・方言・絵文字の組み合わせが出てくる。小モデルがこうしたエッジケースでどのくらい誤判定・見逃しをするかは、実データで評価しないとわからない。Kustamie のようなバラエティ後置審査なら「速い・安い・だいたい OK」で許容できるかもしれないが、リスクが高い業務に同じ判断を持ち込むのは早計だ。
AWS Summit という場での文脈も影響している。システム全体が AWS 上にあって Nova を選べば IAM・監視・課金・社内説明がシンプルになる。AWS の自社イベントで AWS 製 foundation model を選ぶのは、ある意味自然な流れでもある。
映像モデレーションの構想
映像モデレーションは「構想」という言葉が使われていたので、まだ実装済みではない機能だ。IVS の映像ストリームから定期的にスナップショットを取り、Nova Lite のようなマルチモーダルモデルに渡して判定し、結果を主催者に通知するというアイデアだ。
映像モデレーションはチャットより難しい。チャットは離散イベントなので 1 件ずつ検査できる。映像は連続ストリームなのでサンプリングしかできない。頻度を上げるとコストが上がり、下げると短い違反を見逃す。1 フレーム/秒なら継続的なコンテンツはほぼ漏らさないが、3 時間の配信で 10,800 フレームになる。1 フレーム/30 秒はコストが抑えられるが、長めに続く問題しか検出できない。
複合画面も判定を難しくする。ゲーム画面・実況ウィンドウ・配信者のカメラ・テキストオーバーレイが同時に映っているとき、モデルはどこが主コンテンツでどこが背景情報かを理解しなければならない。単体フレームのスナップショットは時間的な文脈を失う点も問題だ。レースカーのクラッシュ・ゲームの戦闘・実際の暴力は単一フレームでは似た視覚信号を持っていても意味はまったく違う。
だからスライドで「自動停止」ではなく「主催者への通知」を選択しているのは正しいと思う。映像の誤判定はコメントを 1 件誤削除するより影響が大きく、人間が最終判断をするのはここでは必要な設計だ。
まとめ
TBS のセッションを 3 層に整理するとこうなる。
大規模配信基盤として、Amazon IVS が低遅延映像基盤とリアルタイムインタラクションの重い部分を担ったことで、チームは映像インフラを自前で構築する必要がなかった。
API パフォーマンスとして、API Gateway stage cache・Lambda global variables・ElastiCache for Valkey が多段キャッシュを形成し、SQS と Step Functions Express がコストの高い処理を非同期パスに移した。前者はバックエンド呼び出しを減らし、後者はユーザーが感じるレスポンスタイムを短くした。
AI 安全機能として、Nova Micro が高速チャット審査を担い、Nova Lite は将来の映像モデレーション構想に組み込まれている。共通点は「生成 AI を使った」ことではなく、小モデルを高頻度・低複雑度・バッチ処理可能・短遅延許容の分類タスクに当てたことだ。
スライドの最後に Kustamie が 2026 年秋に beta 版を提供予定と書いてあった。つまり「ラヴィット！忘年会'25」は限定規模の実験に近い位置づけで、長期安定運用の公開サービスとはまだ距離がある。
印象に残った点
セッション全体の技術的な価値は、大規模インタラクティブ配信をいくつかの管理しやすい境界に分解していたところだと思う。
責務の分離が最初にある。映像・チャット・イベントメタデータ・バックグラウンド書き込みがそれぞれ別の経路を通り、リアルタイムデータは IVS / IVS Chat に、変化が遅いデータは API パスに置いた。これによってキャッシュと非同期化が自然に成り立った。複雑な無効化機構でなんとかしようとしていない。
実際のユーザー行動で負荷テストを作ったこともよかった。固定 RPS や線形ランプは、定常状態が安定して見えることしか証明できない。配信系で本当に危険なのは開始直前の指数的増加だ。過去の活動データを k6 シナリオに変換することで、API Gateway throttle・Lambda スケーリングレート・外部 API rate limit が事前に露見した。
同期パスの切り直しも印象的だ。12 秒から 150ms への改善は、サーバーを大きくして得たものではなく、UserID と IVS Token を同期で返して残りを SQS に流すという設計変更で得た。多くのシステムの性能問題は「実行が遅い」のではなく、「待たなくていいことを同期で待っている」ことが多い。
コントロールプレーンの制限をアーキテクチャ上の制約として扱ったことも学べるところだ。IVS の API が 50 TPS で上限変更不可なら、全ユーザーにリアルタイムでコントロールプレーンを呼ばせることはできない。Lambda がローカルでトークンを署名発行するのは、制限のある外部 API をローカル暗号演算で代替するパターンで、他にも応用できる考え方だ。大規模 AWS アーキテクチャではクォータ・rate limit・コールドスタートは後から考える話ではなく、設計の最初から置いておく制約だ。
小モデルを適切な場所に使ったこと。Nova Micro は「AI ができますよ」のデモではなく、高頻度・単純・バッチ可能・非同期許容の分類タスクを担わせている。遅延・コスト・「だいたい十分」のバランスで選んでいる。ただし精度データはなかった。クラウドベンダーのケーススタディはどうしても成功パスを強調する。自分のシステムに適用する前に、誤判定率・見逃し率・コスト・運用複雑度を別途評価する必要がある。
CheerChen です。