[レポート]カスタマーサポートにおけるAI革命：予測型サービスシステムの構築に参加しました #SPS315 #AWSreInvent

AWS re:Invent 2025
2025.12.04
 はじめにこんにちは。AWS re:Invent2025 に参加しているオペレーション部shiinaです。

現地よりブレイクアウトセッション「カスタマーサポートにおけるAI革命：予測型サービスシステムの構築 #SPS315」のレポートをお伝えします。
 セッション概要タイトル

カスタマーサポートにおけるAI革命：予測型サービスシステムの構築 #SPS315

詳細
AWS がどのように生成系 AI を活用して、カスタマーサポートをアクティブからプロアクティブへと変革しているかを紹介します。

大規模言語モデルと AI エージェントが、顧客満足度と業務効率をどのように向上させているかを解説します。

内容には、スマートなケース振り分け、コンテキストを理解したサポート、問題の早期検知、責任ある AI 活用などが含まれます。

実際の成果を共有するとともに、AI の能力と人間らしい対応とのバランスの取り方について議論します。
スピーカー
Tipu Qureshi,Senior Principal Engineer, Amazon
Saurabh Saxena,Sr Principal, AWS, Amazon
Dwight Biddle,Associate Director of Software, WHOOP
レベル

300

 現在の AWS サポート皆さん、AWS サポートを一度はお世話になったことがある方は多いのではないでしょうか。
AWS サポートは、世界200都市に約15,000人のスタッフを要した体制となっています。

現在は主に以下に注力しています。
プロアクティブなガイダンスの提供
インシデント発生時の迅速な対応
継続的な改善サイクルの推進
reInvent でミッションクリティカルなワークロード向けの最上位プランとして「Unified Operations」を導入されることが発表されました。

クリティカルなインシデントに対して5分以内の応答を保証するなど、運用面での手厚いサポートを提供しています。
下記のアップデートブログもご参照ください。

https://dev.classmethod.jp/articles/support-transformation-ai-powered-operations/
 Agenda本セッションは３部構成で行われました。
1.AI を活用した AWS サポートの進化
2.カスタマーサクセスストーリー：Woop
3.AI と自動化でカスタマーサポートを高度化する取り組み
 1.AI を活用した AWS サポートの進化最初のセッションでは、AWS サポートにおける AI 活用と、そこから逆算して再設計されたサポートモデルについて解説されました。

ポイントは大きくつです。
クラウドワークロードの急速な複雑化
ゼロダウンタイムや高いレジリエンスを前提とした顧客ニーズ
リアクティブ → プロアクティブ なサポートへのシフト
過去 15 年間の AWS サポートの変遷を振り返りつつ、30 年以上のサポート経験を背景に、リアクティブからプロアクティブなサポートにどうシフトするかを話されていました。
 クラウドサポートが直面している課題2010 年頃の AWS サポートは、主にフォーラムやチケットベースの Q&A 型サポートだったそうです。

その後、Developer,Business,Enterprise Support プランが追加され、サポートのカバレッジと SLA が拡張されてきました。
現在のクラウド環境は次のような課題を抱えています。
大規模・分散アーキテクチャによるワークロードの複雑化
クラウドスキルの不足による設計・運用リスク
大量のセキュリティアラートや監視アラートによる「アラート疲れ」
移行プロジェクトの遅延、モダナイゼーションの停滞
これらを人手だけでさばくのは限界があり、AI と自動化を前提としたサポートモデルが必要になっているといった内容でした。
 顧客ニーズと AWS サポートの戦略次のような顧客側の要求は技術者としてもよく耳にしています。
計画・非計画を問わない「ゼロまたは限りなくゼロに近いダウンタイム」
リージョン障害や AZ 障害を前提にしたレジリエント設計
障害が顕在化する前に検知と対処を行うプロアクティブなガイダンス
AWS は WorkingBackwards（お客様から逆算）の原則に基づき、これらの要求から逆算してサポートを再設計しています。

具体的には、
事後対応ではなく、設計段階からレジリエンスをレビューする
障害の兆候をモニタリングし、顧客影響が出る前に検知・介入する
単なる Q&A ではなく、アーキテクチャや運用の「共設計」に踏み込む
といった方向となります。

ビジネスクリティカルワークロード向けに新しく導入されたのが、今回発表された「Unified Operations」という最上位サポートプランです。
 Unified Operations とプロアクティブサポートUnified Operations は、SRE チームに近い役割を AWS 側が担うようなプランです。

構成要素は以下の通りです。
専任のエンジニアリングチーム
テクニカルアカウントマネージャー（TAM）
インシデント・イベント・マネージャー
特徴的なのは運用レイヤーまで踏み込んだ伴走型サポートであることです。
ビジネスクリティカルなインシデントに対する 5 分以内の応答
事前に顧客環境を理解しているエンジニアによるトリアージ・エスカレーション
レジリエントなアーキテクチャ設計の伴走と、MTTR 短縮に向けた継続的な改善
位置づけとしては、従来の問い合わせ窓口としてのサポートから、SRE 的なプラクティスを提供するパートナーへの移行となります。

 AWS サポートにおける AI 活用AWS サポート内部の AI 活用について詳しく聞くことができました。

AI は以下のような用途で活用されています。
大量のインシデント・メトリクス・構成情報を前提としたトラブルシューティング
顧客固有のアプリケーションコンテキストを踏まえたインサイトの提供
自律エージェントによる一次対応・原因特定・修復案の提示
以下のコンテキストが重要となってくるため、情報を踏まえて意思決定できる AI が必要になるという説明でした。
どのサービスがどのように連携しているのか（依存関係グラフ）
どのリソースがビジネス的にクリティカルか
過去にどういう障害が起き、どう解決されたか
AI は顧客向けだけではなく、AWS サポートエンジニアの内部オペレーション（ナレッジ検索、インシデント分析など）にも組み込まれていることを知ることができました。
 2.カスタマーサクセスストーリー：WHOOP次に、ウェアラブルデバイスとサブスクリプションサービスを提供する WHOOP 社の事例が紹介されました。
https://www.whoop.com/
2025年5月に、新しいハードウェアとサブスクリプションのローンチがあり、トラフィック急増とグローバルスケールを前提にしたインフラが必要となり、Unified Operations を実施したそうです。

結果として、ローンチ当日は 100% 可用性を維持しつつ、高い成長ペースをそのまま受け止めることができた事例を聴くことができました。

ローンチ後も、Unified Operations は継続的に運用を支えており、マネージドサービスの MSK Express への移行事例が紹介されました。

SLO 改善とコスト最適化の両面で効果が得られたとのことでした。
 3.AI と自動化でカスタマーサポートを高度化する取り組みAI と自動化をどう組み合わせてサポートをスケールさせるか解説されました。
 コンテキストと評価への投資AI ベースの問題解決ではコンテキストと**評価（Evaluations）**が中核になる、という点です。
コンテキスト
インフラ構成（IaC・タグ・依存関係グラフ）
アプリケーションの役割・クリティカル度
過去のインシデントや変更履歴
評価（Evaluations）
そのエージェント／ワークフローが、実際に問題解決に貢献しているかを測る仕組み
成功率、MTTR への寄与、誤検知・過少検知などの指標
複雑な障害に対応するには、とにかくスケールする問題解決フレームワークが必要であり、そのために AI と自動化が活用されているという内容です。

 構造化された標準作業手順書（SOP）と決定論的ワークフロー従来のサポートは、Wiki やドキュメントに書かれた作業手順書に強く依存していました。

これは運用においては多いのではないでしょうか。
これに対し、AWS では次のような方向に舵を切っているとのことです。
人間が読むための文書中心 → エージェントが実行できる構造化された作業手順書
あいまいな手順 → 完全性と再現性を重視した決定論的ワークフロー
具体的には以下のプロセスです。
自然言語で手順・ワークフローを記述
それをモデル化して、分岐条件や前提条件を明確にしたフローへ変換
統合テストしやすい形に落とし込む
 標準作業手順書（SOP）の評価と検証本当に役に立つかを検証するため、AWS では IaC 化された検証環境を活用しています。
CloudFormation 等で再現可能なテスト環境を構築
想定インシデントを発生させ、ワークフローを自動実行
期待する修復が行われるかを自動評価

これはコストのかかるプロセスですが、一度作り込んでしまえばグローバルに再利用できるため、スケールするという考え方です。

また、症状から根本原因へ到達するために、以下のようなデータ構造・アルゴリズムも取り入れています。
サービス・リソース間の依存関係を表現したグラフ構造
ページングや閾値設定などを含めた確率行列モデル
根本原因推定
複数サービスにまたがるような複雑な障害でも、解決時間を短縮できるとのことでした。

MCP を用いて、ツールや標準作業手順書を AI から呼び出しやすい形で表面化させている点にも触れられていました。

 エージェント実行とデータのリッチ化エージェントによる自動実行の精度向上のために、過去インシデントログやナレッジベースを継続的に取り込んでいます。

MCP のレイテンシや精度に関する課題に対しては、モデルのファインチューニングが有効と紹介されていました。
 マルチチャネルのサポートとオーケストレーションAWS サポートは、AWS マネジメントコンソール、Slack など複数チャネルからアクセスできます。

バックエンドでは以下が組み合わさって動いています。
社内の専門家（人間）
AI エージェント
MCP 経由で接続された各種ツール／標準作業手順書
重要なのがオーケストレーションレイヤーです。
リクエスト内容に応じて、どのエージェント（または専門家）をアサインするかを決定
単一エージェントで完結しないケースでは、複数エージェントを協調動作させる
必要に応じて複数エージェントにブロードキャストし、結果を整合・統合してからユーザーに返す
このような制御を行うことで、ハイブリッドな問題解決を実現しています。

さらにサポート向けの技術スタックとして、以下が紹介されました。
Amazon Connect：コンタクトセンター基盤としての音声・チャット連携
Amazon Bedrock：基盤モデルを利用したエージェント構築
MCP：エージェントとツール、外部システムをつなぐコンテキスト・実行レイヤー

また、AWS DevOps エージェントも例として取り上げられました。

必要に応じてサポート担当者へシームレスにエスカレーションできるよう設計されているので、AI に任せきりにせず、人間と連携可能な形としてる点が特徴と説明がありました。
 最後にテクニカルサポートを担当している私の立場から、特に刺さったのは AWS サポートが問い合わせ窓口から SRE 的な運用パートナーへシフトしているという話でした。

本セッションではリソース依存関係、インシデント履歴といったコンテキストを AI に渡しつつ、標準作業手順書（SOP）と評価指標をセットし、資産化することがポイントであることが学べました。

また、LLM を入れること自体よりも、ナレッジをどう構造化して、どう継続的に評価・改善するかという設計が本質であることがわかりました。

困ったときに聞く相手ではなく、プロアクティブ運用の土台として AI を使う考え方を知ることもできた点が良かったです。
#SPS315

#AWSreInvent