Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
監視オペレータはもういらない?~Amazon Connectを用いたスペシャリスト自動手配シス...
Search
toyo-da01
July 27, 2022
Technology
0
4
監視オペレータはもういらない?~Amazon Connectを用いたスペシャリスト自動手配システムの内製開発~
CODT2022登壇資料。運用オペレーションにAmazon Connectを組み込んだユースケースの紹介。
toyo-da01
July 27, 2022
Tweet
Share
More Decks by toyo-da01
See All by toyo-da01
Amazon Connect コンタクトフローの大量移管?!
da01toyo
0
5
AWS ハッカソン体験記~ゲーム開発で得られたAWSスキル紹介~
da01toyo
0
8
UTM (統合脅威管理; FortiGate) on AWSを構築するにはどんなネットワーク設定??
da01toyo
0
37
悪用厳禁! SQLインジェクションやってみた!
da01toyo
0
5
業務効率化したいのに時間がない??OSSとLambdaを用いたツールのスピード開発術
da01toyo
0
8
普通のやり方だとできない!?💦 Amazon Connect x Lambdaのレア?な連携のご紹介!
da01toyo
0
11
CI/CD ツール導入で達成した、開発と運用の協力関係強化とストレスフリーなリリースプロセスの実現に迫る!
da01toyo
0
8
CI / CDって具体的にどう動いている??
da01toyo
0
2
優良な技術サイトを「お気に入り」で終わらせないためのWebアプリケーション開発
da01toyo
0
3
Other Decks in Technology
See All in Technology
Yamla: Rustでつくるリアルタイム性を追求した機械学習基盤 / Yamla: A Rust-Based Machine Learning Platform Pursuing Real-Time Capabilities
lycorptech_jp
PRO
4
170
なぜ私はいま、ここにいるのか? #もがく中堅デザイナー #プロダクトデザイナー
bengo4com
0
1.2k
Node-REDのFunctionノードでMCPサーバーの実装を試してみた / Node-RED × MCP 勉強会 vol.1
you
PRO
0
130
Connect 100+を支える技術
kanyamaguc
0
140
作曲家がボカロを使うようにPdMはAIを使え
itotaxi
0
370
Github Copilot エージェントモードで試してみた
ochtum
0
130
Node-RED × MCP 勉強会 vol.1
1ftseabass
PRO
0
170
Oracle Cloud Infrastructure:2025年6月度サービス・アップデート
oracle4engineer
PRO
2
310
2025-06-26 GitHub CopilotとAI駆動開発:実践と導入のリアル
fl_kawachi
1
220
2025-06-26_Lightning_Talk_for_Lightning_Talks
_hashimo2
2
110
Fabric + Databricks 2025.6 の最新情報ピックアップ
ryomaru0825
1
150
BrainPadプログラミングコンテスト記念LT会2025_社内イベント&問題解説
brainpadpr
1
180
Featured
See All Featured
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
GraphQLとの向き合い方2022年版
quramy
49
14k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
Speed Design
sergeychernyshev
32
1k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.8k
Reflections from 52 weeks, 52 projects
jeffersonlam
351
20k
Rails Girls Zürich Keynote
gr2m
94
14k
Scaling GitHub
holman
459
140k
How GitHub (no longer) Works
holman
314
140k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.5k
How STYLIGHT went responsive
nonsquared
100
5.6k
Java REST API Framework Comparison - PWX 2021
mraible
31
8.7k
Transcript
監視オペレータはもういらない? ~Amazon Connectを用いたスペシャリスト自動手配システムの内製開発~
/18 本セッションの対象およびゴール 1 ◼こんな方向けのセッション • クラウドを用いた業務改善に興味がある方 • Amazon Connectに関心がある方 •
運用業務の稼働削減を考えている方 etc. ◼ゴール • クラウドを用いた業務改善の一例を知ってもらう • Amazon Connectの使い方・構築概要を知ってもらう ◎既存の運用業務体制を見直すきっかけになれたら、幸いです、、!
/18 今回の発表で焦点を当てるケース 4 ITシステムの運用では、次のような構成を取っている会社も多いのでは? 監視オペレータ(一次措置) 日中 夜間 スペシャリスト ① ②…
24時間365日 体制 サービスA サービスB : ① ②…
/18 今回の発表で焦点を当てるケース 4 ITシステムの運用では、次のような構成を取っている会社も多いのでは? 監視オペレータ(一次措置) 日中 夜間 スペシャリスト ① ②…
24時間365日 体制 サービスA サービスB : ① ②… こちらの業務を、 効率化できるのでは? ※当社の取り組みをご紹介
/18 監視オペレータの業務棚卸し 5 監視オペレータ(一次措置) スペシャリスト ① ①アラート確認&種類判別 ②フロー確認 ③エスカレーション(エスカレ)判断 ②
③ ① ② ③ ① ② ③ 静観 組織A エスカレ 組織B エスカレ いずれも迅速に対応可 ① ② ③ 一次 措置 日中帯の場合
/18 監視オペレータの業務棚卸し 5 監視オペレータ(一次措置) スペシャリスト ① ①アラート確認&種類判別 ②フロー確認 ③エスカレ判断 ②
③ ① ② ③ ① ② ③ 静観 組織A エスカレ 組織B エスカレ ① ② ③ 一次 措置 夜間帯の場合 業務時間外は気づかない、、 気づかない恐れあり Aさん Bさん … Aさん Bさん …
/18 監視オペレータの業務棚卸し 6 監視オペレータの業務フロー ~ ~ アラート メトリクス確認 フロー確認 エスカレ
判別 一次措置 or 静観 エスカレ ①実施 アラート 内容引継ぎ エスカレ先確認 エスカレ ②実施 アラート 内容引継ぎ スペシャリスト ◼ 課題 監視オペレータは、 ①システム・アラートごとにエスカレ先を確認 ②電話に出てもらえない+再度次の担当者を確認 ※時間帯問わずだが、②は夜勤帯は特に顕著な負担 ◼ 業務改善を目指すシステム構築の要件 ①毎回エスカレ先を確認しなくてよい ②電話に出てもらえない+勝手にリダイレクト ※エスカレーションのたびに実施される
/18 一度、考えるポイント① 課題と要件は理解ができる、、 内製でシステムを開発できるか?? ◼懸念点 7 開発難易度 導入時間 コスト クラウドサービスのAmazon
Connectが、 選択肢に挙げられます、、!
/18 Amazon Connect?? 電話サービスもクラウドで実現ができます、、! Amazon Connect: AWSのコンタクトセンターサービズであり、コンタクトセンターシステムや 自動受付システムを構築・運用することができます。 8 ◼メールやチャットでのコミュニケーションが増えてきたが、電話によるコ
ミュニケーションの重要性も見直されています。 ◼テレワーク環境の整備において、社内外で会社代表電話番号への着信対応を 行えるようにしたい。
/18 ~ ~ シンプルなUIで、電話の転送フローを構築することができます。 ※Amazon Connectは初期制約が若干多いので、構築時はご注意ください、、! 終了 Amazon Connect?? ~
~ 9
/18 ~ ~ エスカレ業務の効率化 10 エスカレ業務へのAmazon Connectの適用 エスカレ ①実施 エスカレ先確認
エスカレ ②実施 各番号ごとの スペシャリスト Amazon Connect どちらのサービスのエスカレ ですか? XXの場合は1を、YYの場合は 2を押してください。 自動音声サービス サービスXX組織 自動転送サービス サービスYY組織 Connect番号に 電話 自動フロー 一つの電話番号にかけるだけで、各サービスにおける電話でエスカレ先を設定できる →監視オペレータのエスカレ業務の効率化につながる これまで Amazon Connect 適用後
/18 監視オペレータの業務棚卸し 監視オペレータ(一次措置) スペシャリスト ① ①アラート確認&種類判別 ②フロー確認 ③エスカレ判断 ② ③
① ② ③ ① ② ③ 静観 組織A エスカレ 組織B エスカレ ① ② ③ 一次 措置 システムの従来の運用体制 再掲載
/18 一度、考えるポイント② 監視オペレータの業務で効率化できる部分は、 エスカレ業務のみでしょうか?? 11 他のAWSサービスと組み合わせると できることがさらに広がります!
/18 監視オペレータの業務棚卸し 監視オペレータ(一次措置) スペシャリスト ① ①アラート確認&種類判別 ②フロー確認 ③エスカレ判断 ② ③
① ② ③ ① ② ③ 静観 組織A エスカレ 組織B エスカレ ① ② ③ 一次 措置 システムの従来の運用体制 再掲載
/18 監視オペレータの業務棚卸し 監視オペレータ(一次措置) スペシャリスト ① ①アラート確認&種類判別 ②フロー確認 ③エスカレ判断 ② ③
① ② ③ ① ② ③ 静観 組織A エスカレ 組織B エスカレ ① ② ③ 一次 措置 システムの従来の運用体制 再掲載
/18 監視オペレータの業務棚卸し 12 監視オペレータの業務フロー ~ ~ アラート メトリクス確認 フロー確認 エスカレ
判別 一次措置 or 静観 エスカレ ①実施 アラート 内容通知 エスカレ先確認 エスカレ ②実施 アラート 内容通知 スペシャリスト AWS Lambda Amazon Connect ◼ ねらい 監視オペレータが担う業務をシステム化 ①アラート確認 →システムのアラートメール機能に代替 ②エスカレ先に電話をかける →サーバー代替サービス(AWS Lambda) で Amazon connectをキックする
/18 AWS LambdaからAmazon connectで電話 13 システムからのAmazon Connectで電話をかけるには、 AWS Lambdaで実現することができます。 AWS
Lambda Amazon Connect 登録した電話番号 ```python import boto3 connect = boto3.client('connect’) response = connect.start_outbound_voice_contact( DestinationPhoneNumber = 電話したい電話番号, ContactFlowId = ************, InstanceId = *************, SourcePhoneNumber = *************, Attributes={ ‘message‘: 流したい音声, } ) ※は、Amazon Connect設定時に決まる番号になります ``` ◼ 工夫を加えられる点 ①電話したい電話番号をDBで管理 番号をDBで管理することで、変更を生じた際に安 全に変更することができる ②流したい音声 各アラームごとに設定する音声を変更することで、 電話を受けた方はいち早く何のサービスであるか を把握できる
/18 苦労したこと 14 システムからの呼び出しでは、 一番目の方が出られなかったときに次の担当者に回すことに一苦労しました、、 AWS Lambda① Amazon Connect スペシャリスト(1)(2)…
◼ 当初の想定 Amazon ConnectのUIで転送フローを用いれば、電話に出られなかった場合に転送される →結果としては、転送フローの正しい挙動として、一度電話に出ると転送される形だった ② ①電話をするLambda ②電話に出たか確認+①をリトライさせるLambda ◼ 実施したこと Amazon Connectに対応したかどうかを確認するLambdaを同時に実施させた、、! →結合はAWS StepFunctionsを用いました
/18 Tips その他にも、実際に監視オペレータ業務をシステムに代替してみると、 電話を受けるスペシャリストの方々に対して、次の要件が見つかりました、、! 15 電話を受ける方々での課題 解消した方法 ①同じアラートで数分で何度も呼び出しがかかる ②出たとしても対応不可か選択する余地が欲しい ③電話される人を増やしたい、順番を変更したい
④特定期間中(メンテナンスなど)は、 アラート架電を抑止したい ①電話した時刻のタイムスタンプを保存 →30分以内であれば、再架電しない ②電話時に押す番号で対応できる・できないを決める ③番号をDBで管理する →DBに登録者を増やす・取り出す順番を変更する ④各サービスごとに電話をするかどうかのスイッチ →Yesであれば電話する。Noであればメールなどになる
/18 AWS Cloud Region ap-northeast-1 Amazon SES Amazon WorkMail Reciving
Rules① Region us-east-1 16 Reciving Rules② Amazon Connect Amazon S3 AWS Lambda AWS Step Functions workflow スペシャリスト AB… If accepted 社内ML Amazon DynamoDB ① ② ③ アーキテクチャ
/18 当社で導入した結果 17 当社 (関連組織)の運用では、 ◼ エスカレーション効率化を使用しているサービスは4つ ◼ 監視オペレータ業務をシステムに代替して、運用しているサービスは7つ ①サービスごとの連絡網確認
②電話 (出なかった場合、①に) 計:5-10分/件 × エスカレ(10-15件/週)= 数時間/週 自組織で24時間365日警報を監視して保守者を配置するのは不可能かつ非効率だった システム構築で監視体制を構築しなくても、安全かつ効率的に運用ができている。 ※サービスの水平スケーリング・担当者入れ替えも容易、、!
/18 まとめ 18 本セッションでは、 ITシステム運用で監視オペレータの業務改善に焦点を当てました。 ◼ 従来の監視オペレータの業務で各サービスごとに連絡する電話番号が多い →クラウドサービスのAmazon Connectを用いれば、簡単に構築できる ◼
監視オペレータの業務をシステムに代替(監視オペレータの稼働を削減できるかもしれません*) →Amazon ConnectのほかにAWSサービスを用いることで構築できる。 ※一次措置などが定型業務でない部分では、使えないのでケースに合わせた推奨 既存の運用業務体制を見直すきっかけになっていただけたら、幸いです、、!
ご視聴、ありがとうございました