電話を武器に変える Amazon Connect 活用の全貌

電話対応は価値提供の重要な要素なのに人手が足りない。
そんなスタートアップの課題に Nealle が Amazon Connect でどう挑んだか。運用改善から AI 活用まで、実践事例をお伝えします。

Transcript

1. NEALLE 電話を武器に変える Amazon Connect 活用の全貌 2026.06.25 AWS Summit Japan 2026 株式会社ニーリー 宮後 啓介 @miya10kei 1
2. 自己紹介 Keisuke Miyaushiro 宮後 啓介 株式会社ニーリー プラットフォーム本部 プロダクトAI開発 リーダー 2023年にニーリーにジョイン SREリードとしてサービスの信頼性やアジリティ向上の施策を実施。 2025年よりプロダクト/事業部門での生成AI活用を推進するチームを立 ち上げ活動中。 現在はCSS業務の効率化と新規プロダクトの立ち上げを実施中 @miya10kei 2
3. プロダクト紹介 BtoBtoCのVertical SaaS「Park Direct」を運営 モビリティプラットフォームを目指す 3
4. 目次 1. なぜ電話が重要なのか？ 2. なぜAmazon Connect（現：Amazon Connect Customer）なのか？ 3. ニーリーでの活用 4. Amazon Connect x AIのさらなる取り組み 4
5. 1. なぜ電話が重要なのか？ 5
6. １．なぜ電話が重要なのか？ 不動産業界において「電話」は必須チャネル １ • • クライアントにとって契約者対応の中核手段が電話であり、業務に組み込まれている 電話を提供しないと、そもそも顧客への価値提供が成立しない。 CS体験の「半分」を「電話」が担っている ２ • • テキストでは伝わらない不安や緊急性、感情の機微を捉えることができる 弊社では問い合わせの60%以上が電話によるもの 電話対応そのものが「差別化」・「価値創出のレバー」になる ３ • • • 電話対応の品質＝サービスの提供価値そのもの。 アウトソースすれば運営とシステムが分離し、CS体験の設計に手が届かなくなる 内製で電話を握っているからこそ、サービス全体の品質改善につながる 6
7. 2. なぜAmazon Connectなのか？ 7
8. ２．なぜAmazon Connectなのか？ コールセンターを構築する上で必要な機能のほとんどが揃っている １ • 着信・発信/チャット/ルーティング/IVR/オペレータ業務支援/通話録音/ワークフォース 管理/レポート分析/etc.. システム面でのスケーラビリティをほとんど気にする必要がない ２ • • スモールスタートから大規模化してもシステムがボトルネックにならない 気にするのはクォータ制限くらい AWSの各種サービス／外部SaaSとシームレスに連携することができる ３ • • AWS上に構築している既存システムとの連携が容易 多くの外部SaaSがAmazon Connect/AWSサービスとの連携をサポートしている 8
9. 3. ニーリーでの活用 9
10. ３．ニーリーでの活用 - Amazon Connect活用状況 利用開始 電話番号 コンタクトフロー キュー 2021年 (5年間) 26本 78本 31個 主な利用機能 コミュニケーション 音声通話 SMS オートコール フロー設計・ルーティング コンタクトフロー キュー管理 クイック接続 Lambda連携 分析・モニタリング リアルタイムダッシュボード 通話録音 文字起こし 感情分析 組み合わせサービス Amazon Connect AWSサービス：Lambda / Bedrock / RDS / DynamoDB / S3 / CloudWatch 外部SaaS：Media SMS / Zendesk / BaseMachina / Slack 10
11. ３．ニーリーでの活用 １ ドメイン特化型CS体制への再編 ２ Slackを組み合わせた待ち呼管理 ３ AI通話要約によるACW削減 ４ アウトバウンドのオートコール 11
12. 3. ニーリーでの活用 - ドメイン特化型CS体制への再編 - 12
13. ３．ニーリーでの活用 - ドメイン特化型CS体制への再編 チーム分けを行わず、全メンバーが全てのドメインの問い合わせに対応する体制だった • • • Before 受電毎に扱うドメインが変わり、コンテキストスイッチが頻発 ドメインが広いことで知識のキャッチアップに時間を要する SME/SVの責任範囲が広範化 SME CSR 問い合わせ エスカレーション SV エスカレーション CS 13
14. ３．ニーリーでの活用 - ドメイン特化型CS体制への再編 ドメイン領域でチーム分けをおこなうことで、扱う問い合わせを限定するように体制を変更 • • • After コンテキストスイッチの発生を最小化 扱うドメイン知識を限定することでキャッチアップを高速化 SME/SVはドメインをローテーションしていくことでキャリアステップを刻むことができる チームA（ドメインA担当） エスカレーション エスカレーション 担当チームに 振り分け チームB（ドメインB担当） 問い合わせ CS チームC（ドメインC担当） 14
15. ３．ニーリーでの活用 - ドメイン特化型CS体制への再編 - 電話番号/DTMF入力による振り分け クイック接続による電話転送 問い合わせの担当チームへの振り分けは、電話番号と DTMF入力を組み合わせておこなう。 担当外の問い合わせを受電した場合は、必要情報をヒ アリングの上で、担当チームに電話転送する。 ▪ 電話番号 • 050-XXXX-XXXX → チームAが受電 • 050-YYYY-YYYY → チームBが受電 ▪ クイック接続とは？ 受電したコンタクトを任意のエージェントやキューに 転送することができる機能 ▪ DTMF入力 • 「1」が選択されたら → チームAが受電 • 「2」が選択されたら → チームBが受電 ※ DTMF入力： 「〇〇の方は1を…」などで番号プッシュする仕組み 15
16. 3. ニーリーでの活用 - Slackを組み合わせた待ち呼管理 - 16
17. ３．ニーリーでの活用 - Slackを組み合わせた待ち呼管理 オペレーター接続までの待ち時間は CS 体験を大きく左右する！ ニーリーでは以下のモニタリング、アクションをおこなうことで待ち呼(※１)を最小化するよう運用している。 • 31キューを1分間隔でモニタリングし、「何名が何分間待っているか」をSlackに自動投稿(※２) • SMEが投稿をチェックし、次のアクションを行うことで待ち呼の解消に動く ◦ CSR への対応可否確認 ◦ CSR ステータス（Available / Offline / ACW等）の確認(※３) ◦ SME / SV 自らの受電判断 ※１：待ち呼：オペレータの応答を待ってキューに溜まっている呼（コール） ※２：普段の業務との親和性を踏まえてリアルタイムメトリクスではなくSlackで運用 ※３：NPT（Non-Productive Time）というカスタムステータスを作成し、CSRが受電不可を申告できるようにしている 17
18. ３．ニーリーでの活用 - Slackを組み合わせた待ち呼管理 - 対応可否確認 メトリクス取得 EventBridge Lambda AmazonConnect SME CSR 通知 モニタリング Slack 18
19. 3. ニーリーでの活用 - AI通話要約によるACW削減 - 19
20. ３．ニーリーでの活用 - AI通話要約によるACW削減 コールセンター業務の生産性指標の一つにACW(After Call Work)がある。 ACWは通話後の後処理にかかった時間を指し、ニーリーでは主に以下の作業を行っている。 • 通話内容の記録（毎回） → Amazon Connect x Bedrockを組み合わせて自動化 • Park Direct 管理機能でのデータ更新（必要に応じて） • 他チームへの対応依頼チケット起票（必要に応じて） 通話 保留 通話 ATT(Average Talk Time) 平均通話時間 後処理 ACW(After Call Work) 平均後処理時間 AHT(Average Handling Time) 平均処理時間 20
21. ３．ニーリーでの活用 - AI通話要約によるACW削減 【SEGMENTS】 文字起こし結果の書き込み Amazon Connect Amazon Kinesis Data Streams Contact Lens 文字起こし 結果取得 Lambda DynamoDB 【COMPLETED】 通話終了イベント 要約作成 Bedrock SQS Lambda 文字起こし＆要約 保存 分析 S3 要約を書き込み ニーリー社員 閲覧 Zendesk CSR/SME/SV 21
22. 3. ニーリーでの活用 - アウトバウンドのオートコール - 22
23. ３．ニーリーでの活用 - アウトバウンドのオートコール ニーリーでは次のように定型的に大量のCSに対して一括で電話連絡をおこなう業務が多く存在している。 • 駐車場閉鎖に関する連絡 • 料金改定に関する連絡 • 各種変更に伴う了承取得に関する連絡 • 督促に関する連絡 • etc.. 「Amazon Connect x AWSサービス x 外部SaaS」を組み合わせてオートコールの仕組みを構築することで、 オペレーターが「人にしかできない対応に集中」できるようにしている。 ※ 現在、Amazon ConnectにはAutomated Outbound Callingというオートコール機能がリリースされています😅 23
24. ３．ニーリーでの活用 - アウトバウンドのオートコール オートコール 実行 ニーリー社員 BaseMachina 架電 Lambda CS Connect 架電結果を 保存 Lambda 分析 RDS ニーリー社員 24
25. ４. Amazon Connect x AIのさらなる取り組み 25
26. ４．Amazon Connect x AIのさらなる取り組み ニーリーではAmazon Connect AI Agentを用いたボイスボットの活用にトライ中！ Amazon Connect AI Agentの主な特徴 1. Amazon Connect 専用のマネージド AI エージェントサービス ◦ 2. コンタクトセンター向けに最適化された、agentic AI による自律応対基盤 ナレッジに基づく自律会話 ◦ 社内ナレッジ(ドキュメント / FAQ / Bedrock Knowledge Bases)を参照しながら、CSと複数 ターンの会話を自律的に遂行可能 3. MCP 経由のツール実行 ◦ 4. 外部システムと接続し、駐車場検索やチケット起票などのツール実行が可能 オペレーターへのシームレスなエスカレーション ◦ ボットによる解決が困難な場合に、人間のオペレーターへ自動で引き継ぐことが可能 26
27. ４．Amazon Connect x AIのさらなる取り組み 技術面でのハードル • • • 音声品質 ◦ 自然な音声での応対は CS 体験を大きく左右する要素 ◦ 現状の Amazon Connect の Neural 音声では自然さに限界がある ◦ 3rd Party TTS(ElevenLabs 等)の利用には無制限 AI プランが必須となり、スモールスタート には不向き 音声認識 ◦ 発話内容を正確に聞き取れないと、CS にフラストレーションを与える要素になる ◦ 弊社検証では、日本語よりも英語のほうが認識精度が高い傾向が見られた ◦ 日本語特有の同音異義語・固有名詞への対応が今後の課題 応答速度 ◦ 会話中の無音区間は CS 体験を直接的に損なう ◦ ナレッジ検索や MCP 経由の API コールなど、遅延要因が複数重なる構造 ◦ 「いかに遅延を感じさせないか」が UX 設計の鍵 AWSの今後のアップデートに大いに期待しています！ 27
28. ４．Amazon Connect x AIのさらなる取り組み CS 体験を損なわない形での導入ハードル • • 人だからこそ拾えていたシグナルが拾えなくなる ◦ ボイスボットでは、人が自然と読み取っていた CSの不安や緊急性、感情の機微を捉えられ なくなる 「人間のオペレーターと話したい」というニーズは依然として根強い CS 体験を損なわない形での導入アプローチ • • • • 待ち呼が一定数発生したときの受け皿 ◦ オペレーターにつながるまでの待ち時間にボイスボットを活用 CS 自身が選べる導線の用意 ◦ DTMF プッシュ等で「ボイスボット / オペレーター」を CS が選択可能にする オペレータ接続前の一次ヒアリング ◦ 用件・契約情報などの定型情報をボイスボットが収集し、オペレータにスムーズに接続する 営業時間外の限定運用 ◦ 人が対応できない時間帯に絞って稼働することで、取りこぼし防止と運用負荷を最小化 28
29. まとめ 29
30. まとめ 電話は事業の武器になる！ • • 不動産業界において電話はCS体験の半分をになっている 他社がやりたがらないからこそ「差別化」・「価値創出のレバー」になる コールセンターを構築する場合、Amazon Connectは第一選択肢になる！ • • コールセンターを構築する上での必要機能がほとんど揃っている スモールスタートから大規模運用までシステムがボトルネックにならない 内製化しているからこそ電話対応は進化し続ける！ • サービス成長や現場の要望/負担に合わせた改善を行うことでCS体験・運営・システムを一体と なって進化させることができる 30
31. AWSへの要望 新機能の東京リージョンでの早期サポート • 東京リージョンがサポート外だと、自前で構築することになるので、今後の新機能は是非とも早 期サポートを！！ 全国の0ABJ番号のサポート • • アウトバウンドコールにおいて、0ABJ番号か050番号で応答率に差がでる 法的な規制があることは理解しつつ、お願いします🙏 Amazon Nova 2 Sonicの日本語サポート • ボイスボットを実現する上で、高品質な日本語音声モデルは重要！ 31
32. Thank you 32