はじめに AWS Summit Japan 2026（6/25-26 @幕張メッセ）にご来場いただいた皆様、ありがとうございました。本ブログでは、建設・不動産業向けインダストリーブース（A057）の不動産パートの展示内容をご報告します。 不動産ブースのテーマ： 「不動産業の未来を、生成 AI で切り拓く ─ データと対話が変える、新しい不動産体験」 また、ブースの事前紹介は こちらの開催予告ブログ で公開しています。 不動産×AI ─ AI 時代のデータ戦略をどう描くか 不動産業界では、人口減少・空き家問題・人手不足といった構造的な課題が山積しています。これらに立ち向かうために、データと AI を組み合わせた業務変革が求められています。しかし、どれだけ優れた AI が登場しても、活用できるデータが整っていなければ課題解決は始まりません。今回のブースでは、不動産業の数ある業務の中でも 開発・流通・管理 という3つのフェーズに着目し、さらにそれらを横断する 意思決定・可視化 の視点を加えた4つの切り口で、業務課題を解決するためのデータと AI の活用方法をご紹介しました。 開発：オープンデータ× 自社データ活用。大量のデータを AI で解析し、エリア分析・将来予測 流通：自社の物件・顧客データを AI に提供。AI が自社システムにアクセスし、顧客体験をセルフサービス化 管理：設備データ・修繕履歴・IoT センサーを深く・継続的に蓄積。3D モデルや AI で解析・予測 可視化：データを横断的に可視化。Amazon Quick の生成 AI によるダッシュボード自動生成で、経営判断を加速 今、不動産業に求められるのは、ユースケースを正しく理解し、必要なデータを集め、求められる切り口で AI に活用させること。これが 2026 年における「AI 時代のデータ戦略」です。 ここからは、ブースで展示した各ソリューションをご紹介します。 展示① 都市・エリア分析 × AI エージェント「AI Urban Digital Twin」 概要 不動産業における 開発 フェーズにおいて「どこに」「何を」建てるかの意思決定を AI で支援するソリューションです。人口統計・地価・交通量・POI などの公開データと自社データを統合し、AI が都市特性を多角的に分析します。 本ソリューションには2つの側面があります。ひとつは、大量のオープンデータを事前に整形・統合し、3D 地図上にヒートマップや境界ポリゴンとして描画する可視化機能。もうひとつは、MCP（Model Context Protocol）で AI エージェントが不動産情報ライブラリ API や分析データベースにリアルタイムにアクセスし、「この地域の将来人口は？」などの自然言語クエリに即座に回答する対話型分析機能です。この2つを組み合わせることで、エリア分析を高速に実行し、不動産開発・用地選定の判断を加速します。 デモの見どころ エリアの開発ポテンシャル分析：生成AIが人口増加率・地価変動率・災害リスク・周辺施設の充実度など多角的な指標をもとにエリアをスコアリングし、地図上にエリアの状況を描画 開発企画の提案：エリア特性（人口分布・用途地域等）に基づき、住宅・オフィス・商業施設それぞれにおいて、周辺施設の状況などを踏まえた開発企画を AI が提案 将来予測の可視化：5年後・10年後・20年後の地価変動・人口予測をヒートマップで表示 データ取得・変換フロー 今回は、国土交通省が提供する「不動産情報ライブラリ」の情報を元に都市を分析するデモを作成しています。 不動産情報ライブラリは REST API として公開されており、以下の2種類の形式でデータを取得しています。 JSON API：市区町村・都道府県単位で取得。不動産取引価格（四半期別）など ベクトルタイル API（GeoJSON）：将来推計人口、用途地域、災害リスク、施設POI など 不動産情報ライブラリ API から取得したデータは、 AWS Lambda を利用して変換し、 Amazon S3 に CSV として蓄積します。この際、データは都市コードごとに分類され、さらにデータ種別（将来推計人口・用途地域・地価・災害リスク等）ごとのディレクトリに整理して格納されます。2次処理では Amazon S3 上の全データを読み込み、空間統合・スコアリングを行った結果を Amazon DynamoDB のテーブルへ書き込みます。処理の中では、取得した各種ポリゴンデータを約250m四方の正方形グリッド（メッシュ）に変換・割り当てし、メッシュ単位でデータを統合しています。それぞれのテーブルには以下のようなデータが格納されます。 AreaData：同一用途地域ごとにグルーピングしたエリア単位の分析結果 PredictionData：エリアごとの5年刻みの将来予測データ BoundaryData：地図描画に使用するエリアの境界ポリゴン ZoningData：用途地域データや建ぺい率・容積率の区域データ PropertyData：自社物件データ（所在地・緯度経度・物件属性） なぜ、2段階の処理でデータを取得しているかというと、データ量の問題があります。1都市あたり約 200 MB、1,000ファイル以上にも渡る取得結果をそのまま描画するのはパフォーマンスの懸念がありました。そこで、 Amazon DynamoDB にデータを整形して投入することで、地図描画時のパフォーマンスを確保しています。また、 Amazon S3 に生データを残すことで、処理ロジックを改良した際にいつでも再処理が可能な設計としています。 フロントアプリケーションの構成とデータの活用 Amazon DynamoDB に格納されたデータは、API を経由してフロントエンドに提供されます。各 Lambda 関数がそれぞれの Amazon DynamoDB テーブルにアクセスし、用途に応じた形でデータを返却します。また、MCP Chat Lambda は Amazon Bedrock と連携して自然言語での対話型分析を、Geodata Lambda は Amazon Location Service と連携して地図描画を実現しています。 フロントアプリケーションでは以下の機能が提供されます。 AI 都市診断機能 各テーブルから取得したエリア分析結果を地図上に可視化し、ユーザーにデータ参照体験を提供します。さらに Amazon Bedrock がデータを解釈し、人口動態・地価・災害リスク・周辺施設などを総合した都市分析レポートを生成します。 開発企画生成機能 用途地域・施設充実度・人口構成などのデータを元に、生成 AI が当該エリアに適した開発企画（住宅/商業/オフィス等）を提案し、顧客に新たなインサイトを提供します。 未来の可視化機能 将来予測データを元に、都市の5年後・10年後・20年後の人口・地価の変化をヒートマップで表示します。時間軸を切り替えることで、エリアの将来性を直感的に把握できます。 自社物件マッピング機能 自社保有物件を地図上にプロットし、エリア分析結果と重ねて表示します。これにより「自社物件がどのようなエリア特性の中に位置しているか」を一目で把握できます。さらに、エリアのスコアや将来予測と自社物件を掛け合わせ、生成 AI が「このエリアの物件は将来的に価値が上がるか」「周辺施設の充実度に対して賃料設定は適切か」といった分析を提供します。開発判断やポートフォリオ見直しの材料として活用できます。 その他にも、用途地域ポリゴンを地図上に重ねて表示する機能や、洪水浸水想定区域・液状化リスク・土砂災害警戒区域といった防災情報の可視化機能も備えており、開発候補地のリスク評価を地図上で直感的に確認できます。 AI チャット機能 大規模なバッチ処理によって大量のデータ処理と可視化を実現している一方で、不動産情報ライブラリ API を MCP（Model Context Protocol）サーバーとして構成し、生成 AI を利用した対話型分析機能も提供しています。こちらはバッチ処理済みのデータに加え、国交省 API からリアルタイムに最新情報を取得して回答できるため、「直近の取引事例は？」「このエリアの最新の地価公示は？」といった鮮度の高い問いかけにも対応します。バッチによる俯瞰的な可視化と、MCP によるリアルタイムな対話分析の両輪で、ユーザーの意思決定を支援します。 このように、大量のデータを高速に参照して地図上に描画する用途と、チャットのようにリアルタイムで短い問いに即座に応答する用途では、求められるデータパイプラインが異なります。前者にはバッチ処理による事前整形と Amazon DynamoDB への投入が、後者には MCP を通じた API のリアルタイム呼び出しが適しています。ユースケースに応じてパイプラインを分けることが、データと AI を組み合わせたソリューション設計において重要なポイントです。 展示② 不動産流通支援 AI エージェント「AI コンシェルジュ」 概要 不動産業における顧客接点は Web・電話・メッセージアプリと多岐にわたりますが、どのチャネルでも一貫した体験を提供できている企業はまだ少ないのではないでしょうか。その背景には、物件データベースや予約管理システムなど自社の業務システムが個別に存在し、チャネルが分断している現状があります。本展示では、生成 AI エージェントが自社の物件データベースや予約管理システムに直接接続し、電話でもチャットでも、物件提案から内覧予約までをシームレスに完結させるオムニチャネル体験をお見せしました。AI が自社システムのデータにリアルタイムにアクセスすることで、顧客はどのチャネルからでもセルフサービスで物件探しから予約まで完了できます。 デモでは、チャットで「目黒駅の 2LDK を探している」と伝えると、AI が条件を整理して物件を提案し、内覧日時をその場で確定する、という一連の流れをお見せしました。 デモの見どころ 電話とチャットのオムニチャネルな体験：同じ AI エージェントがチャットでも電話でも対応。チャネルを問わず一貫した顧客体験を提供 生成AIが既存システムと連携：顧客の発話内容に応じて、AI が自社システムの API（物件検索・予約管理等）を自律的に呼び出しデータを取得・入力 顧客体験がセルフサービスで完結：物件提案から内覧予約の確定まで、人間の介在なしに AI が一連の業務を完結。24時間対応 アーキテクチャの特徴 Amazon Connect Customer AI Agents は、 Amazon Connect Customer 上で動作する AI エージェント機能です。音声やチャットチャネルを通じて顧客と直接会話し、質問への回答だけでなく予約の作成・変更・キャンセルといったアクションまで自律的に実行できます。解決が難しい場合はシームレスに人間のオペレーターにエスカレーションします。この仕組みの軸は、自社システムの API をツールとして AI エージェントに読み込ませることにあります。プロンプトで定義されたルールに基づき、AI エージェントが顧客の希望に合わせて能動的にツールを起動し、自社の物件データベースから条件に合う物件を検索したり、予約管理システムに内覧予約を書き込む操作を自律的に実行します。人間が介在せずとも、データの参照と入力の両方を AI が行える点がポイントです。 この仕組みはチャットだけでなく電話でも同様に機能します。 Amazon Connect Customer がオムニチャネルの入口となるため、顧客がどのチャネルから問い合わせても同じ AI エージェントが同じツールを使って対応します。 本展示で扱う物件データ（PropertyData）は、展示①のエリア分析で使用しているものと同じデータです。展示①では「エリア × 自社物件」の俯瞰的な分析視点で活用しているのに対し、展示②では同じデータを顧客向けのセルフサービス体験として提供しています。 展示③ 施設管理 × AI × デジタルツイン 概要 展示①と同じ地図ベースのソリューションですが、扱うデータが異なります。展示①がオープンデータと自社物件データで「都市」を分析するのに対し、本展示では施設のセンサーから取得する稼働データや修繕履歴データを用いて「管理されている施設の状態」を可視化・分析します。 不動産管理のフェーズでは、開発・流通とは異なる課題があります。管理施設が数十〜数千棟に散在する中で「どの施設が最もリスクが高いか」を一元的に把握する手段がなく、台帳はExcelや紙・個別システムに分散しているため横比較ができません。修繕優先度の判断は熟練者の勘に依存し、退職とともに知見が消失します。さらに、設備状態の確認には毎回現地巡回が必要であり、劣化に気づかないまま放置された結果、発見時には既に状態が深刻化し、大規模修繕による膨大なメンテナンスコストが発生するリスクがあります。 デモの見どころ 地図上の施設状態マッピング：施設のセンサー稼働データ・修繕履歴を元に劣化ランクを算出し、地図上に色分けで表示。コンディションベースでメンテナンスの意思決定が可能に 生成 AI アシスタント：取得したデータが生成 AI に連携され、施設に関する質問への回答や劣化予測・修繕優先度の提案を自然言語で取得可能（例：「築40年以上でFCIがD以上の施設は？」） デジタルツイン（3D可視化）：これらの情報を建物の3Dモデル上にマッピングし、デジタルツインとして管理可能。現地に行かずに設備状態を空間的に把握 アーキテクチャの特徴 統合施設管理AIダッシュボードは、施設・設備の維持管理を支援するAIエージェント機能です。ダッシュボード上のチャットUIを通じて担当者と対話し、施設の劣化状況や修繕優先度に関する質問への回答だけでなく、修繕依頼の起票といったアクションまで実行できます。修繕依頼の作成にあたっては、プロンプトで定義されたルールに従って担当者に確認を求めたうえで書き込みを行います。 この仕組みの軸は、自社システムのAPIをツールとしてAIエージェント（Strands Agents SDK + Amazon Bedrock AgentCore ）に読み込ませることにあります。プロンプトで定義されたルールに基づき、AIエージェントが担当者の要望に合わせて能動的にツールを起動します。 Amazon DynamoDB の施設・設備・修繕データから条件に合う施設を検索し、 Amazon Neptune Analytics の知識グラフに対してopenCypherクエリを発行して施設間の関係性（同型設備の故障リスク伝播、業者依存度、類似施設のクラスタリング）を分析し、確認を経たうえで修繕依頼を書き込む操作までを実行します。人間が最終判断を担いつつ、データの参照と入力の両方をAIが行える点がポイントです。 Amazon Bedrock の基盤モデルは、テキストの対話だけでなく画像の解析にも活用されています。点検時にアップロードされた写真をマルチモーダル基盤モデルが解析し、ひび割れ・錆・水損・劣化といった問題点の検出、重要度評価、推奨対応、概算費用の目安を構造化データとして返します。対話エージェントによるデータの参照・入力と、画像解析による点検の効率化が、いずれも同一のAI基盤の上で提供されています。 本ソリューションで扱う施設データは、単一のデータ基盤（ Amazon DynamoDB ）を複数の視点で共有しています。ダッシュボードでは「地図 × 3Dデジタルツイン（ AWS IoT TwinMaker ） × KPI」という俯瞰的な管理視点でデータを活用するのに対し、AIエージェントでは同じデータを担当者向けの対話型セルフサービス体験として提供します。さらに、 Amazon DynamoDB Streams 経由で知識グラフ（ Amazon Neptune Analytics ）へ自動同期されるため、参照系（可視化）と実行系（修繕依頼の起票）のどちらの操作を行っても、俯瞰と対話の両方の視点で常に最新かつ一貫した情報にアクセスできる点が本アーキテクチャの特徴です。 展示④ Amazon Quick ─ データの見せ方を変え、新たなインサイトを得る ここまでの展示で使用したデータを Amazon Quick で可視化すると、地図や AI チャットとはまた異なる切り口が見えてきます。 Amazon Quick には自然言語からダッシュボードを生成する機能があります。例えば、展示①で取得したエリア情報に関しても、地価や取引状況に着目したダッシュボードとして生成し直すと、経営管理ダッシュボードとして生まれ変わります。 このように、不動産に関するデータは見せ方・使い方・その粒度によって、様々なインサイトを我々にもたらしてくれます。同じデータでも、地図上のヒートマップとして見れば開発判断に、ダッシュボードとして見れば経営判断に活用できる。データと AI の組み合わせ方次第で、不動産業の意思決定は大きく変わります。 まとめ 今回のブースでは、不動産ビジネスの 開発・流通・管理、そして 可視化 という4つの視点を通じて、「AI 時代のデータ戦略」をお伝えしました。 開発 ── 国交省のオープンデータと自社データを広く掛け合わせ、メッシュ単位で AI が俯瞰的に解析する 流通 ── 自社システムのデータに AI がリアルタイムにアクセスし、顧客と直接対話して業務を完結する 管理 ── 設備・修繕履歴という深いデータを長期的に蓄積し、AI が予兆を読み 3D で可視化する 可視化 ── すべてのデータを Amazon Quick に統合し、生成 AI でダッシュボードを自動生成。経営判断を加速する 生成 AI の時代、まず取り組むべきは派手な AI 機能の開発ではなく、自社のデータを整え、つなぎ、AI に渡せる状態にすること。その第一歩を一緒に踏み出しませんか。 ブースにお越しいただいた皆様、ありがとうございました。展示内容についてのご質問や、自社での活用についてのご相談がございましたら、お気軽に担当のソリューションアーキテクトまでお問い合わせください。 本ブログは、ソリューションアーキテクトの奈良、Fikko が執筆しました。 関連リンク ・ 【開催予告】AWS Summit Japan 2026 建設・不動産向けブース展示

こんにちは、Amazon Connect ソリューションアーキテクトの梅田です。 2026年 4 月号 はお読みいただけましたでしょうか。今月は、6月25日と26日に AWS Summit Japan 2026 が開催予定となっており、AWS Village では Amazon Connect Customer に関する出展を行います。皆様とお会いできることを楽しみにしています。 今月はアップデート 情報に加え、AWS Summit の Amazon Connect Customer 関連セッションに関する情報をお届けします。皆様のお役に立つ内容があれば幸いです！今月は 以下の内容でアップデート情報をお届けします。 AWS Summit Japan 2026 Amazon Connect Customer 関連セッション 2026 年 5 月のアップデート一覧 AWS Contact Center Blog のご紹介 今月のアップデートに関するよくある質問 1. AWS Summit Japan 2026 Amazon Connect Customer 関連セッション AWS Summit Japan 2026 では、今年も Amazon Connect Customer のお客様導入事例や、ユースケースを元にした最新機能のご紹介についてのセッションを行います。皆様のコンタクトセンター改革のヒントとなる情報をご提供いたしますので、是非ご参加ください。最新のセッション情報、およびご登録については AWS Summit Japan ページをご覧下さい。 日付 時刻 タイトル 6/25(木) 11:30～12:10 AI ネイティブで実現する、妥協なき顧客体験 — Amazon Connect Customer － 6/25(木) 12:20～12:50 JRE GO — 予約体験の再設計と内製開発 6/25(木) 12:30～13:10 Amazon Connect Customer で実現する進化したコンタクトセンター — Agentic AI が変える顧客体験 — 6/25(木) 16:30～17:10 パーソナライズでビジネス成長を実現するコンタクトセンターへ ― AI エージェントが顧客を知り、先回りする― 6/26(金) 13:40～14:10 東京電力におけるコンタクトセンター変革 － CX 向上に向けた AI 活用の取り組み－ 2. 2026 年 5 月のアップデート一覧 Amazon Connect Customer のタスクは何日先までスケジュールできますか？最長90日先までの登録に対応しました – 2026/05/29 Amazon Connect Customer で、最長90日先までのタスクをスケジュール登録できるようになりました。組織が長期にわたるフォローアップ作業の計画、ルーティング、および追跡を行えるようになります。例えば、自動車修理の請求を管理する保険チームでは、査定員の訪問、部品の在庫確認、修理完了後のフォローアップのために将来のタスクをスケジュールでき、それぞれのタスクは関連する請求のコンテキストを保持したまま、適切なタイミングで適切なチームにルーティングされます。タスクのスケジュール登録は、StartTaskContact API、フロー、またはエージェントワークスペースから行えます。この機能は、Amazon Connect Customer が提供されているすべての商用リージョンおよび AWS GovCloud（米国）リージョンで利用可能です。 管理者ガイド Amazon Connect Customer のタスク Amazon Connect Customer のコンタクト後の要約は日本語に対応していますか？日本語を含む8言語ファミリーが新たに追加されました – 2026/05/28 Amazon Connect Customer の生成 AI を活用したコンタクト後の要約が、日本語を含む8つの言語ファミリー（ポルトガル語、フランス語、イタリア語、ドイツ語、スペイン語、中国語、日本語、韓国語）に対応しました。コンタクト後の要約は、音声・チャット・メールチャネルにわたる顧客との会話の簡潔で構造化された概要をエージェントやマネージャーに提供し、トランスクリプト全体を読む必要をなくします。この拡張により、会話で使用された言語で要約が自動的に生成されるため、エージェントはコンタクト後の作業をより迅速に完了でき、マネージャーは複数の言語でコンタクトを確認できるようになります。例えば、グローバルなサポート組織では、フランス語、ドイツ語、日本語で対応した通話の要約を自動生成し、スーパーバイザーがすべての地域のサービス品質を把握できます。この機能は、Amazon Connect Customer のコンタクト後の要約が提供されているすべての AWS リージョンで利用可能です。 管理者ガイド 生成 AI を活用したコンタクト後の要約の表示 Amazon Connect Customer のステップバイステップガイドを自然言語で作成できますか？ノーコード UI ビルダーに AI アシスタントが搭載されました  – 2026/05/28 Amazon Connect Customer アシスタントが UI ビルダーに統合され、コンタクトセンターのマネージャーが自然言語を使用してビューを作成・変更できるようになりました。例えば、「評価フィールドとコメントフィールドを含んだフィードバックフォームを作成」と説明するだけで、対応する UI コンポーネントが自動生成されます。生成されたものはレビューしてから公開でき、ステップバイステップガイドやワークスペースページのビュー作成に必要な時間と専門知識を最大70%削減できます。マネージャーは会話形式のプロンプトを使用して、ビューの作成、条件付き UI によるレイアウトの設定、コンポーネントプロパティの設定、スタイルの適用を、手作業に頼らずに行えます。アシスタントはコンポーネントの推奨、オプションの説明、問題のトラブルシューティングも行い、構築作業を迅速化します。この機能は、米国東部（バージニア北部）、米国西部（オレゴン）、カナダ（中部）、アフリカ（ケープタウン）、アジアパシフィック（ソウル）、アジアパシフィック（シンガポール）、アジアパシフィック（シドニー）、アジアパシフィック（東京）、欧州（フランクフルト）、欧州（ロンドン）、AWS GovCloud（米国西部）の各 AWS リージョンで利用可能です。 管理者ガイド Connect assistant in the UI builder Amazon Connect Customer で AI エージェントによるセルフサービス対話の品質を自動評価できますか？生成 AI を使用した自動評価が可能になりました – 2026/05/27 Amazon Connect Customer で、マネージャーが生成 AI を使用してセルフサービスの対話を自動的に評価し、カスタマーエクスペリエンスを向上させるための集約されたインサイトを取得できるようになりました。マネージャーは評価フォーム内で「お客様の問題はすべて AI エージェントによって解決されたか?」など、自然言語でカスタム評価基準を定義できます。生成 AI はこの基準を使用してセルフサービス対話の質を評価し、会話の文字起こしからの関連する参照ポイントとともに、評価の詳細な推論を提供します。管理者は、これらのインサイトのまとめや個々の問い合わせについて、セルフサービス対話の記録や文字起こしと合わせて確認し、AI エージェントのパフォーマンスを向上させる機会を特定できます。この機能は、米国東部（バージニア北部）、米国西部（オレゴン）、アジアパシフィック（ソウル）、アジアパシフィック（シンガポール）、アジアパシフィック（シドニー）、アジアパシフィック（東京）、欧州（フランクフルト）の AWS リージョンで利用可能です。 管理者ガイド セルフサービス対話のパフォーマンス評価 Amazon Connect Customer のエージェントログイン/ログアウトレポートにきめ細かなアクセス制御は適用できますか？タグベースアクセスコントロールに対応しました – 2026/05/26 Amazon Connect Customer のエージェントログイン/ログアウトレポートで、タグベースのアクセスコントロールがサポートされるようになりました。データアクセスに関するコンプライアンスおよび規制要件を満たすために、きめ細かなアクセス制御を適用できます。コンタクトセンター管理者は、リソースタグを使用して、特定のエージェントのログインおよびログアウト情報を閲覧できるユーザーを制御できます。例えば、エージェントに「Department: Customer Service」というタグを付けると、カスタマーサービスのチームマネージャーのみがこれらのエージェントのログイン/ログアウト情報を確認できるようになります。この機能は、Amazon Connect Customer が提供されているすべての AWS 商用リージョンおよび AWS GovCloud（米国西部）リージョンで利用可能です。 管理者ガイド タグベースのアクセス制御 Amazon Connect Cases でエージェントがケースの関連項目を編集・削除できますか？エージェントワークスペースからの直接操作に対応しました – 2026/05/15 Amazon Connect Customer Cases で、関連項目の編集と削除、およびエージェントワークスペースからのケースの直接削除が管理者の介入なしで行えるようになりました。エージェントは、コメントを更新したり、間違ったケースに関連付けられている連絡先のリンクを解除したり、誤って開かれたケースを削除したりできます。また、注文、返品、請求書などのカスタム関連項目を作成・編集・削除して、追加のケースコンテキストを把握することも可能です。この機能は、米国東部（バージニア北部）、米国西部（オレゴン）、カナダ（中部）、欧州（フランクフルト）、欧州（ロンドン）、アジアパシフィック（ソウル）、アジアパシフィック（シンガポール）、アジアパシフィック（シドニー）、アジアパシフィック（東京）、アフリカ（ケープタウン）の各 AWS リージョンで利用可能です。 Amazon Connect Customer でエージェントが自分のパフォーマンス評価だけを確認できますか？自己評価の表示専用権限が追加されました – 2026/05/14 Amazon Connect Customer で、他のエージェントの評価を公開せずに、エージェントが自分のパフォーマンス評価のみにアクセスできる権限がサポートされるようになりました。エージェントはフィードバックを確認してパフォーマンスを向上させることができます。この権限により、エージェントは自分が評価を受けたコンタクトを検索し、通話録音やトランスクリプトと並べて評価を確認したり、確認後に承認を送信したりできます。例えば、複数のコンタクトにまたがる顧客の問題を調査するために部署全体の連絡先を閲覧する権限をエージェントに付与しつつ、評価については自分のものだけを確認できるように設定できます。同僚の機密性の高いパフォーマンスデータをエージェントが閲覧できない状態を確保しながら、運用上の柔軟性を提供します。この機能は、Amazon Connect Customer が提供されているすべての AWS リージョンで利用可能です。 管理者ガイド 評価とコーチングの権限 Amazon Connect Customer の Cases と Customer Profiles をカスタムエージェントアプリケーションに埋め込めますか？SDK による統合が可能になりました – 2026/05/12 Amazon Connect Customer で、カスタムエージェントアプリケーションに Cases と Customer Profiles を埋め込めるようになりました。エージェントは問題解決のために既に使用しているツールに加えて、ケースの詳細や顧客のコンテキストにアクセスできるようになります。デベロッパーは Amazon Connect SDK を使用してネイティブの Connect 環境をカスタムアプリケーションに取り込むことができるため、これらの機能をゼロから構築して保守する必要がなくなります。この機能は、Amazon Connect Customer が提供されているすべての AWS リージョンで利用可能です。 管理者ガイド / デベロッパーガイド カスタムアプリケーションへの統合 Amazon Connect SDK（GitHub） Amazon Connect Customer のアフターコンタクトワーク時にステップバイステップガイドを自動起動できますか？ACW 用デフォルトガイドが追加されました – 2026/05/08 Amazon Connect Customer で、アフターコンタクトワーク（ACW）のデフォルトガイドがサポートされるようになりました。コンタクトセンターの管理者は、エージェントが ACW 状態になったときに手動操作なしでステップバイステップガイドを自動的に起動できます。処理コードの記録、ケースの更新、フォローアップアクションの完了など、必要なラップアップタスクをエージェントが自動的に実行できるようにすることで、コンタクト後のワークフローを標準化し、対応時間を短縮できます。ACW 中にエージェントが手動で正しいアプリケーションに移動する必要がなくなるため、コンタクトセンター業務全体において一貫性の向上、エラーの削減、エージェントの生産性向上が期待できます。この機能は、米国東部（バージニア北部）、米国西部（オレゴン）、カナダ（中部）、アフリカ（ケープタウン）、アジアパシフィック（ソウル）、アジアパシフィック（シンガポール）、アジアパシフィック（シドニー）、アジアパシフィック（東京）、欧州（フランクフルト）、欧州（ロンドン）、AWS GovCloud（米国西部）の各 AWS リージョンで利用可能です。 管理者ガイド Amazon Connect のフローブロック: ビューを表示 Amazon Connect Customer のアウトバウンドキャンペーンは複数タイムゾーンの顧客に適切な時間帯で配信できますか？複数の連絡先情報からのタイムゾーン検出に対応しました – 2026/05/07 Amazon Connect Customer のアウトバウンドキャンペーンで、主要な連絡先フィールドだけでなく、顧客プロファイルのすべての電話番号と住所を使用して顧客のタイムゾーンが検出されるようになりました。これまでは主要な電話番号のみが使用されていたため、複数のタイムゾーンにまたがる顧客を見落とす場合がありました。プロファイルの連絡先情報が複数のタイムゾーンにまたがっている場合は、検出されたすべてのタイムゾーンにおいて設定済みの時間帯に含まれる場合にのみ配信し、重複がない場合はプロファイルをスキップします。例えば、顧客に東部標準時の市外局番の携帯電話番号と太平洋標準時の市外局番の事業用電話番号があり、キャンペーンが午前9時から午後5時まで配信されるように設定されている場合、メッセージは両方のタイムゾーンが許可された時間帯に含まれる東部標準時午後12時から午後5時（太平洋標準時午前9時から午後2時）にのみ配信されます。この機能は、Amazon Connect アウトバウンドキャンペーンが提供されているすべての AWS リージョンで追加費用なしで利用可能です。 管理者ガイド アウトバウンドキャンペーンの配信時間設定 Amazon Connect Customer Cases で重複する顧客プロファイルが統合されたときケースも自動的にまとまりますか？アイデンティティ解決との連携に対応しました – 2026/05/05 Amazon Connect Customer Cases で、重複する顧客プロファイルが統合される際にケースが自動的に再度関連付けられるようになりました。これにより、エージェントは常にそれぞれの顧客の完全なケース履歴を確認できます。同じ顧客が異なるチャネルを通じて連絡したり、異なる連絡先情報を提供したりすることで複数のプロファイルが作成される場合があります。Amazon Connect Customer Profiles のアイデンティティ解決がそれらの重複を検出して統合すると、関連付けられたすべてのケースが Cases によって統合プロファイルに自動的にまとめられます。エージェントは複数のプロファイルを検索したり、顧客の履歴を手動でまとめたりする必要がなくなりました。この機能は、米国東部（バージニア北部）、米国西部（オレゴン）、カナダ（中部）、欧州（フランクフルト）、欧州（ロンドン）、アジアパシフィック（ソウル）、アジアパシフィック（シンガポール）、アジアパシフィック（シドニー）、アジアパシフィック（東京）、アフリカ（ケープタウン）の各 AWS リージョンで利用可能です。 管理者ガイド Amazon Connect Cases 3. AWS Contact Center Blog のご紹介 Amazon Connect Customer: 中国への発信におけるコンプライアンスのベストプラクティス (日本語翻訳) グローバルにビジネスを展開する企業にとって、中国（国番号 +86）への発信における通信規制への準拠は避けて通れない課題です。規制に適合しない設定のままアウトバウンド発信を行うと、通話切断やサービス停止、さらには中国への発信機能そのものの利用制限といった深刻な影響を受ける可能性があります。本記事では、Amazon Connect Customer を使用して中国へコンプライアンスに準拠した発信を行うための 5 つのベストプラクティス（承認済み DID 番号の設定、禁止番号タイプの排除、レート制限の実装、発信者 ID の設定、番号検証の実装）を紹介します。 4. 今月のアップデートに関するよくある質問 Q. Amazon Connect Customer とは何ですか？ Amazon Connect は、Amazon の運用実績に基づいて構築されたエージェンティック AI ソリューションのファミリーになりました。2026年4月に、Amazon Connect Customer（カスタマーエクスペリエンス）、Amazon Connect Decisions（サプライチェーン）、Amazon Connect Talent（採用）、Amazon Connect Health（ヘルスケア）の4つのソリューションに拡張されました。( Amazon Connect について ) コンタクトセンター領域を担う Amazon Connect Customer は、音声・チャット・メール・タスクなど複数のチャネルを一つのプラットフォームに統合し、AI を中核に据えたクラウドコンタクトセンターソリューションです。料金プランは、すべての AI 最適化機能がチャネル料金に含まれる「Amazon Connect Customer」（旧 Unlimited AI）がデフォルトです。従来のアラカルト型プランは「Amazon Connect Customer Basic」として既存顧客向けに提供されていますが、今後の新しい AI 機能は Connect Customer で提供されるため、Customer Basic からの移行が推奨されます。( Amazon Connect Customer について / Amazon Connect Customer の料金 ) Q. Amazon Connect Customer Tasks とは何ですか? Amazon Connect Customer Tasks は、音声・チャット・メールと同じように優先順位付け、割り当て、追跡、自動化ができる作業項目です。エージェントはエージェントワークスペース上でタスクを受け取り、フォローアップの電話、保険請求の処理、ケースの更新など、コンタクト対応以外の業務を管理できます。タスクは手動で作成するほか、コンタクトフロー内のアクション、ルール、StartTaskContact API から自動生成することも可能です。ルーティングプロファイルによりキューへの振り分けや優先度の設定ができ、今月のアップデートでは最長90日先までのスケジュール登録にも対応しました。（ Amazon Connect Customer Tasks ） Q. Amazon Connect Customer のステップバイステップガイドとは何ですか？ ステップバイステップガイドは、エージェントワークスペース上でエージェントに対して業務手順を段階的に案内する UI コンポーネントです。管理者はノーコードの UI ビルダーでフォーム、ボタン、テキストなどのコンポーネントを組み合わせてガイドを作成し、コンタクトフローでトリガー条件を設定できます。エージェントが通話を受けた際やアフターコンタクトワーク（ACW）に入った際に自動的に表示され、処理コードの入力、ケース作成、顧客情報の確認などを標準化された手順で実行できます。今月のアップデートでは、ACW 状態でデフォルトガイドを自動起動する機能と、AI アシスタントによる自然言語でのガイド作成（作成時間を最大70%削減）が追加されました。（ ステップバイステップガイド ） Q. Amazon Connect Customer にはどのようなレポートがありますか？ Amazon Connect Customer は以下のレポート・分析機能を提供しています。 リアルタイムメトリクス : キューやエージェントの現在の状態（待ち呼数、対応可能エージェント数、サービスレベルなど）をリアルタイムに表示します。 履歴メトリクス : 指定した期間のコンタクト数、平均処理時間、放棄率などを集計し、トレンド分析に活用できます。 ダッシュボード : キューとエージェントのパフォーマンスを視覚的に一覧でき、カスタムウィジェットやカスタムメトリクスの作成も可能です。 ログイン/ログアウトレポート : エージェントの勤務時間を追跡し、タグベースのアクセスコントロールによりチームマネージャーごとに閲覧範囲を制限できます。 会話分析（Conversational Analytics） : 音声・チャット・メールのコンタクトに対してリアルタイムおよびコンタクト後の分析を提供します。自動文字起こし、感情分析、コンタクトの自動分類、PII（個人識別情報）の墨消し、生成 AI によるコンタクト後の要約生成、テーマ検出などの機能を備えています。 分析データレイク : コンタクトデータを Amazon Athena や Amazon Quick で直接クエリ・分析でき、複雑なデータパイプラインを構築することなくカスタムレポートを作成できます。今月のアップデートでは、ログイン/ログアウトレポートへのタグベースアクセスコントロールが追加されました。 Q. Amazon Connect Customer の Identity Resolution(アイデンティティ解決)とは何ですか？ アイデンティティ解決は、Amazon Connect Customer Profiles の機能で、同じ顧客が異なるチャネルや連絡先情報で作成した複数のプロファイルを自動的に検出・統合する仕組みです。今月のアップデートにより、プロファイルが統合される際に Amazon Connect Cases のケースも自動的に統合プロファイルに再関連付けされるようになりました。エージェントは複数のプロファイルを検索する必要なく、常に顧客の完全なケース履歴を確認できます。( Amazon Connect Customer Profiles , Identity Resolution ) Q. Amazon Connect Customer Cases とは何ですか？ Amazon Connect Customer Cases は、顧客との応対履歴をケースとして作成・追跡・管理する機能です。エージェントはエージェントワークスペース内でケースの作成、ステータスの更新、関連するコンタクトやタスクの紐づけを一画面で行えます。ケースにはカスタムフィールドを定義でき、テンプレートを使って業種や業務に応じた構造化が可能です。コンタクトフローからケースを自動作成するルールも設定できます。今月のアップデートでは、エージェントがワークスペースから関連項目の編集・削除やケースの直接削除が可能になったほか、Amazon Connect Customer Profiles のアイデンティティ解決によりプロファイル統合時にケースが自動的に再関連付けされるようになりました。（ Amazon Connect Customer Cases ） Q. Amazon Connect Customer のアウトバウンドキャンペーンとは何ですか？ アウトバウンドキャンペーンは、Amazon Connect Customer Profiles のセグメントに基づいて、音声・SMS・メールなど複数チャネルで顧客にプロアクティブにアプローチする機能です。そして、ジャーニー（複数ステップのワークフロー）を設計し、顧客の行動や属性に応じたパーソナライズされたアウトリーチを実行できます。セグメントビルダーで対象顧客を定義し、ビジュアルフローデザイナーでマルチチャネルジャーニーを構築します。配信ガードレールやエンゲージメント設定により、適切な時間帯・頻度でのコミュニケーション管理も可能です。今月のアップデートでは、顧客プロファイルのすべての電話番号と住所からタイムゾーンを検出し、複数タイムゾーンにまたがる顧客にも適切な時間帯で配信できるようになりました。（ アウトバウンドキャンペーン ） 今月のお知らせは以上です。皆さんのコンタクトセンター改革のヒントになりそうな内容はありましたでしょうか？ぜひ、実際にお試しいただき、フィードバックをお聞かせいただけますと幸いです。 AWS Summit Japan 2026 にもぜひご登録の上、ご来場ください。会場でお待ちしています！Amazon Connect Customer の最新情報は毎月このブログでお届けしていますので、来月号もお楽しみに。 著者プロフィール   梅田　裕義（Hiroyoshi Umeda） アマゾンウェブサービスジャパン合同会社 シニア Amazon Connect ソリューションアーキテクト 2020年12月入社。コンタクトセンター領域を専門に、Amazon Connect Customer を活用した顧客体験の向上や業務効率化の技術支援を行っています。AI によるセルフサービスの導入、オムニチャネル対応、分析基盤の構築などコンタクトセンターが抱える課題解決に幅広く取り組んでいます。

本記事は 2026 年 6 月 5 日 に公開された「 Adding LINE Messenger to your AWS omnichannel fallback solution 」を翻訳したものです。 本記事では、既存のオムニチャネルフォールバックソリューションに LINE Messenger を統合して拡張する方法を説明します。アーキテクチャの変更点、デプロイ手順、テスト手順についても取り上げます。元のソリューションは Amazon API Gateway 、 AWS Lambda 、 Amazon Simple Email Service (Amazon SES) 、 AWS End User Messaging で構築されており、SMS、WhatsApp、メールを横断して自動フォールバック機能付きでメッセージを配信します。 本記事が拡張対象とする元のオムニチャネルフォールバックソリューションについては、 Enhancing Message Reach: An Omnichannel Approach Using WhatsApp, SMS, and Email with AWS を参照してください。 LINE Messenger を選ぶ理由 LINE は日本、台湾、タイで広く使われているメッセージングプラットフォームであり、主要市場での月間アクティブユーザー数は 1 億 8,100 万人、うち日本だけで 1 億人に達します ( LY Corporation FY2025 Q3 業績データ )。DAU/MAU 比率は 84% (日本では 88%) と高く、毎日活発に利用されているため、医療分野の予約リマインダー、EC の注文・配送通知、小売のプロモーションキャンペーンなど、タイムリーなコミュニケーションに適したチャネルです。 APAC には KakaoTalk (韓国)、WeChat (中国)、Zalo (ベトナム)、Viber (フィリピン) といった各国で人気のメッセージングプラットフォームが存在しますが、LINE は日本・台湾・タイの 3 市場で同時に強い存在感を持っており、これらの国々を対象としたマルチチャネルメッセージング戦略に高い効果をもたらします。オムニチャネルフォールバックソリューションに LINE を追加することで、各市場のユーザーが好むチャネルでリーチできるようになります。LINE はプライマリチャネルとしてもフォールバックチャネルとしても利用でき、他のチャネルで実装済みのフォールバック・ブロードキャストのパターンをそのまま活用できます。 費用について: LINE Messaging API の料金は国やプランによって異なります。各チャネルの詳細は LINE Messaging API 、 Amazon Simple Email Service (Amazon SES) 、 Amazon End User Messaging の料金ページをご覧ください。 アーキテクチャの概要 フォールバックソリューションに LINE を追加することで、単一の API エンドポイントから 4 つの主要メッセージングチャネルをカバーできます。既存の複雑さを増やさずにリーチを広げられる点が特長です。LINE の統合は既存チャネルと同じイベント駆動型のサーバーレスパターンに従います。次の図はアーキテクチャへの主な追加点を示しています。 図 1: LINE Messenger を追加した更新後のオムニチャネルアーキテクチャ (新規コンポーネントをハイライト表示) 既存のアーキテクチャに 2 つの要素を追加するだけで、LINE ユーザーにリーチできます。 LINE Messaging API の統合 – Primary Handler Lambda と Secondary Handler Lambda に send_line モジュールが追加され、Push Message エンドポイントを通じて LINE Messaging API でメッセージを配信します。 AWS Secrets Manager の統合 – LINE チャネルの認証情報 (アクセストークンとチャネルシークレット) は AWS Secrets Manager に安全に保存され、Lambda 関数がキャッシュを活用して取得します。 LINE 統合の仕組み LINE Messenger の統合は既存のメッセージ処理パイプラインを拡張する形で実装されているため、メール、SMS、WhatsApp と同じ信頼性の高いフォールバック動作が LINE でも利用できます。以下のセクションでは、システムが LINE メッセージとフォールバックシナリオをどのように処理するかを説明します。 LINE メッセージの送信 LINE をプライマリまたはフォールバックチャネルとしてメッセージを送信する場合、LINE 固有の処理を含む同じパターンに従います。 API Gateway がリクエストを受信し、Primary Amazon Simple Queue Service (Amazon SQS) キューに追加します。 Primary Handler Lambda がチャネルを “line” と検出し、 send_line モジュールを呼び出します。 send_line モジュールが Secrets Manager から LINE の認証情報をキャッシュ付きで取得し、LINE Messaging API の Push Message エンドポイントにリクエストを送信します。Push Message API はユーザーが先にメッセージを送ることなく LINE ユーザーへのメッセージ送信を可能にします。リクエストボディには受信者の LINE ユーザー ID (ユーザーが LINE 公式アカウントをフォローした際に割り当てられる一意の識別子) を含む to フィールドと、配信するメッセージオブジェクトを格納した messages 配列が含まれます。モジュールは LINE API を呼び出す前に、受信者の LINE ユーザー ID が期待されるフォーマット (大文字の ‘U’ に続く 32 文字の小文字 16 進数文字) と一致するか検証します。不正な受信者 ID のリクエストは早期に拒否され、外部 API に到達しません。 Lambda 関数がメッセージのステータスを Amazon DynamoDB テーブルに記録します。 フォールバックが設定されている場合、Lambda 関数はメッセージをフォールバックキューにエンキューします。このエンキューは LINE API 呼び出しが成功 (HTTP 200) した場合でも失敗 (200 以外のレスポンス、タイムアウト、または例外) した場合でも実行されます。DynamoDB には成功時に delivered 、失敗時に failed としてメッセージステータスが記録されます。Secondary Handler は DynamoDB を確認し、ステータスが delivered でない場合にフォールバックチャネルで送信します。 Secondary Handler が DynamoDB のステータスを sent_fallback に更新します。 LINE と他チャネルの違い 項目 メール SMS WhatsApp LINE API Amazon SES SendEmail API AWS End User Messaging SendTextMessage API AWS End User Messaging Social SendWhatsAppMessage API LINE Messaging API Push Message API 認証 IAM ロール IAM ロール IAM ロール Secrets Manager 経由のチャネルアクセストークン 外部メッセージ ID のマッピング 不要。 SES は配信コールバックで同じメッセージ ID を返します。 不要。 SMS は配信コールバックで同じメッセージ ID を返します。 必要。 WhatsApp は配信 Webhook で異なるプラットフォームメッセージ ID を返すため、内部の AWS メッセージ ID へのマッピングが必要です。 不要。 配信コールバックがないため、メッセージ ID の紐付けは不要です。 認証情報の保存 IAM (自動) IAM (自動) IAM (自動) Secrets Manager (手動) 配信追跡 SES 配信イベント経由の非同期処理 (SNS コールバックが DynamoDB を更新) End User Messaging イベント経由の非同期処理 (SNS コールバックが DynamoDB を更新) End User Messaging イベント経由の非同期処理 (SNS コールバックが DynamoDB を更新) なし。LINE API からの 200 レスポンス時に即時 delivered に設定。LINE Messaging API には配信 Webhook なし。 LINE は AWS ネイティブの IAM 認証ではなく独自の認証を持つ外部 API を使用します。そのため、認証情報の管理には IAM ではなく AWS Secrets Manager を使用する必要があります。詳細は LINE Messaging API ドキュメント を参照してください。 LINE はビジネス向けに 2 種類のメッセージングプロダクトを提供しています。LINE Messaging API と LINE Official Notification です。 LINE Messaging API は本ガイドの対象であり、双方向の会話型メッセージングをサポートし、モバイルオーダー、ロイヤルティプログラム、カスタマーエンゲージメントなど多くの業種で広く採用されています。LINE には LINE Official Notification (LINE 通知メッセージとも呼ばれる) という別サービスもあり、配送状況通知や予約リマインダーといった一方向のトランザクション通知向けに設計されていますが、ビジネス認証が必要です。 LINE Official Notification はメッセージごとの配信完了イベントを提供しますが、LINE Messaging API にはその機能がありません。Messaging API では HTTP 200 レスポンスが LINE によるメッセージ受け付けを示しており、これが利用可能な最も詳細な配信シグナルです。 LINE Messaging API チャネルの作成 LINE 統合でメッセージを認証・送信するには LINE Messaging API チャネルが必要です。手順は以下のとおりです。 LINE Developers Console にサインインします。アカウントをお持ちでない場合は 個人 LINE アカウント を作成し、対応する iOS/Android/PC アプリをダウンロードします。LINE メッセージの受信テストに必要です。 プロバイダーを作成します (会社名または組織名)。 そのプロバイダーの下に新しい Messaging API チャネルを作成します。 チャネル作成後、LINE Official Account Manager ページから Messaging API を有効化します。 チャネル設定から以下の情報を控えます。 チャネルアクセストークン (Messaging API タブで [Issue] を選択) チャネルシークレット ([Basic settings] タブ) Messaging API 設定で Auto-reply と Greeting messages を無効にします。 デプロイとテスト リポジトリには、CDK スタックのデプロイ、AWS Secrets Manager での LINE 認証情報の設定、個人の LINE ユーザー ID の取得、インテグレーションテストスイートの実行まで、手順を詳しく説明したデプロイガイドが含まれています。テストスイートは設定済みのチャネルを自動的に検出し、対応するテストを実行します。デプロイとテストの詳細については、 リポジトリ のデプロイガイドを参照してください。 セキュリティに関する考慮事項 本ソリューションを本番環境にデプロイする前に、以下の考慮事項をワークロードとコンプライアンス要件に照らして確認してください。 最小権限の IAM サンプルの Lambda 実行ロールは、DynamoDB、Amazon SQS、AWS Secrets Manager のアクセス許可を特定のリソース ARN にスコープしています。Amazon SES ( ses:SendEmail 、 ses:SendTemplatedEmail )、SMS ( sms-voice:SendTextMessage )、WhatsApp ( social-messaging:SendWhatsAppMessage ) の送信アクションは、このサンプルでは特定の送信 ID、電話プール、WhatsApp ビジネスアカウントを設定可能な状態にするため、シンプルに resources: [“*”] で付与しています。本番環境では API がサポートする範囲でさらにスコープを絞ってください。SES は ID レベルの ARN (例: arn:aws:ses:region:account:identity/example.com ) をサポートし、End User Messaging SMS はプールおよび電話番号 ARN をサポートします。このコードを適用する際は、サポートされているすべての項目にリソースレベルのスコープを維持し、本番デプロイ向けの AWS Well-Architected セキュリティの柱と Lambda 実行ロールのガイダンスを確認してください。 LINE 認証情報のローテーション LINE チャネルアクセストークンは有効期限が長く、LINE Developers Console からの手動発行・ローテーションのみサポートされています。プログラムによるローテーション API はありません。組織のキーローテーションポリシー (例: 90 日ごと) に沿って定期的にトークンをローテーションし、Secrets Manager のシークレットを新しい値に更新してください。また、キャッシュされた認証情報が更新されるよう、Lambda のコールドスタートを強制してください (スタックの再デプロイまたは Lambda 環境変数の更新による)。 データ保護と個人情報の保持 本ソリューションは、LINE ユーザー ID、電話番号、メールアドレスなどのメッセージメタデータと受信者識別子を Amazon DynamoDB に保存します。DynamoDB は保存時の AWS マネージド暗号化を使用し、Secrets Manager は AWS Key Management Service (AWS KMS) を使用します。また、LINE API へのすべての送信呼び出しは HTTPS で行われます。メッセージテーブルでは Point-in-time recovery が有効です。 本サンプルでは DynamoDB の Time-to-Live (TTL) 属性を設定していないため、レコードは無期限に保持されます。本番環境では、保持ポリシーに合った TTL 属性 (例: expiresAt) を追加し、テーブルの RemovalPolicy.RETAIN 設定がお使いの環境に適切かどうかを確認してください。LINE ユーザー ID、電話番号、メールアドレスは、日本の個人情報保護法 (APPI)、EU の GDPR をはじめとする各種規制において個人情報に該当します。サービス提供地域ごとの保持義務、データレジデンシー要件、データ主体からのアクセスおよび削除リクエストへの対応プロセスを検討してください。 まとめ オムニチャネルフォールバックソリューションに LINE Messenger を追加することで、メール、SMS、WhatsApp、LINE という重要な 4 つのメッセージングチャネルで顧客にリーチできるようになりました。統合は既存チャネルと同じサーバーレス・イベント駆動型のパターンに従っているため、デプロイと運用がシンプルです。LINE はプライマリチャネルとしてもフォールバックチャネルとしても利用でき、地域の好みに合わせたメッセージング戦略を柔軟に構築できます。次のステップとして、他の地域向けメッセージングサービスを追加してリーチをさらに拡大することを検討してください。また、リッチメッセージ、クイックリプライ、Flex Messages など LINE の高度な機能を活用することで、より魅力的なカスタマーインタラクションを実現できます。 リソース GitHub リポジトリ Enhancing Message Reach: An Omnichannel Approach Using WhatsApp, SMS, and Email with AWS LINE Developers ドキュメント AWS CDK ドキュメント 著者について Rommel Sunga シンガポール拠点の AWS シニア Solutions Architect。AWS End User Messaging と Amazon Simple Email Service を専門とし、スケーラブルで信頼性の高いコミュニケーションソリューションの構築をお客様と共に取り組んでいます。クラウドベースのメッセージングアーキテクチャの専門知識を活かし、組織のカスタマーエンゲージメント向上を支援しています。 Katsuya Matsuoka 日本拠点の AWS Solutions Architect。メディア業界のお客様を担当しており、レイクハウスアーキテクチャを含むデータ分析を中心に取り組んでいます。 Pavlos Ioannou Katidis Amazon Simple Email Service (SES) と AWS End User Messaging を専門とする AWS シニアスペシャリスト Solutions Architect。スケーラブルで回復性の高いソリューションの設計を得意とし、大規模コミュニケーションシステムやオムニチャネルフレームワークの構築に注力しています。幅広く採用されている AWS ワークショップ、ブログ、技術ソリューションを執筆し、生成 AI を活用した社内ツールの開発でプロセス効率化と生産性向上に貢献しています。re:Invent では、耐障害性の高い通知システム、ワンタイムパスワードの実装、大量メッセージングのベストプラクティスをテーマに登壇。テニス、ウォーキング、個人のコーディングプロジェクトを楽しんでいます。 この記事は Kiro が翻訳を担当し、Solutions Architect の Katsuya Matsuoka がレビューしました。