Amazon Web Services ブログ

本投稿は、Senior Developer Advocate, Julian Woodの寄稿によるものです。 AWS Identity and Access Management（IAM）条件キーを使用して、AWS Lambda 関数のAmazon Virtual Private Cloud（VPC）設定を制御できるようになりました 。 IAM条件キーを使用すると、IAMポリシーステートメントが適用される条件をさらに絞り込むことができます。関数を作成および更新する権限を付与するときに、IAMポリシーで新しい条件キーを使用できます。 VPC設定の3つの新しい条件キーは、lambda:VpcIds、lambda:SubnetIds、そして、 lambda:SecurityGroupIds です。キーにより、ユーザーが1つ以上の許可されたVPC、サブネット、およびセキュリティグループに接続された関数のみをデプロイできるようにすることができます。ユーザーが許可されていないVPC設定で関数を作成または更新しようとすると、Lambdaは操作を拒否します。 LambdaとVPCの関係を理解する Lambdaの実行環境はすべて、Lambdaサービスが所有するVPC内で動作します。 Lambda関数は、Lambda API を呼び出すことによってのみ呼び出すことができます。関数が実行される実行環境への直接のネットワークアクセスはありません。 非VPC接続のLambda関数 Lambda関数がカスタマーアカウントのVPCに接続するように構成されていない場合、関数はパブリックインターネットで利用可能なすべてのリソースにアクセスできます。これには、他のAWSサービス、APIのHTTPSエンドポイント、またはAWS外のサービスとエンドポイントが含まれます。関数はVPC内のプライベートリソースに直接には接続できません。 VPC接続のLambda関数 Lambda関数を設定して、カスタマーアカウントのVPC内のプライベートサブネットに接続できます。 Lambda関数がカスタマーアカウントVPCに接続するように設定されている場合も、そのLambda関数は引き続きAWS LambdaサービスVPC内で実行されます。この場合、Lambda関数はすべてのネットワークトラフィックをカスタマーアカウント内VPC経由で送信し、このカスタマーVPCのネットワーク制御に従います。これらのコントロールを使用して、セキュリティグループ とネットワークACL を設定し関数が接続可能な範囲を制御できます。Lambda関数からの送信トラフィックは独自のネットワークアドレス空間から送信され、VPCフローログ を使用してネットワークを可視化できます。 パブリックインターネットを含むネットワークロケーションへのアクセスを制限できます。 カスタマーアカウント内のVPCに接続されたLambda関数は、デフォルトではインターネットにアクセスできません。関数にインターネットへのアクセスを許可するには、送信トラフィックをパブリックサブネットのネットワークアドレス変換（NAT）ゲートウェイ にルーティングできます。 Lambda関数を設定してカスタマーアカウント内のVPCに接続すると、AWS Hyperplane によって管理される共有Elastic Network Interface（ENI）が使用されます。この接続により、VPC-to-VPC NATが作成され、クロスアカウントに接続されます。これにより、Lambda関数からプライベートリソースへのネットワークアクセスが可能になります。 AWS Lambda サービスVPCからVPC-to-VPT NATを利用しカスタマーVPCへ Hyperplane ENIは、Lambdaサービスが制御し、カスタマーアカウント内のVPCに存在するマネージドネットワークインターフェースリソースです。複数の実行環境がENIを共有して、カスタマーアカウントのVPC内のリソースに安全にアクセスします。カスタマー側からのLambda実行環境(LambdaサービスVPC内)への直接のネットワークアクセスは出来ないことにご注意ください。 ENIはいつ作られるのか？ Lambda関数が作成されるか、そのVPC設定が更新されると、ネットワークインターフェイスの作成が行われます。関数が呼び出されると、実行環境は事前に作成されたネットワークインターフェースを使用し、そのインターフェースへのネットワークトンネルをすばやく確立します。これにより、コールドスタート時のネットワークインターフェースの作成と接続に関連していたレイテンシが削減 されています。 どのくらいの数のENIが必要か？ ネットワークインターフェイスは実行環境全体で共有されるため、通常、関数ごとに必要なネットワークインターフェイスはほんの一握りです。アカウント内の関数全体で一意のセキュリティグループとサブネットのペアごとに、個別のネットワークインターフェイスが必要です。同じアカウントの複数の関数が同じセキュリティグループとサブネットのペアを使用する場合、同じネットワークインターフェイスを再利用します。このように、複数の関数を備えているが、ネットワークとセキュリティの構成が同じである単一のアプリケーションは、既存のインターフェース構成の恩恵を受けることができます。 関数のスケーリングは、ネットワークインターフェイスの数に直接関係しなくなりました。Hyperplane […]

本投稿は、AWS Lambda の Senior Developer Advocate, Chris Munns の寄稿によるものです。 AWS Lambda関数は、AWS Identity and Access Management（IAM）ロールやAmazon Virtual Private Cloud（Amazon VPC）、ネットワークインターフェイスなど、正常に実行するために他のAWSサービスのリソースを必要とすることがよくあります。関数を作成または更新すると、Lambdaはユーザーに代わって、関数の実行を可能にするのに必要なリソースをプロビジョニングします。ほとんどの場合、このプロセスは非常に高速で、関数を呼び出したり変更する準備はすぐにできます。ただし、この種のアクションで時間がかかってしまうこともあります。 リソースが作成または更新されているときの関数の現在の「状態」をより把握できるように、AWS LambdaのLambda APIアクションによって返される関数情報にいくつかの追加属性が含まれるようになりました。この変更は、関数の呼び出し方法やコードの実行には影響しません。 この投稿では、Lambda関数が到達する可能性のある多様な状態、それらに遷移する条件、およびLambdaサービスが関数をさまざまな状態に遷移させる方法について説明します。詳細については、AWS Lambdaのドキュメント、Lambda APIを使用した関数の状態のモニタリング をご覧ください。 Lambda関数の状態について Lambda関数が通過する主なライフサイクルは2つあります。これは、Lambda関数が初めて作成されるのか、それともすでに存在し更新されるのかによって異なります。フローに入る前に、関数の状態について説明します。 Pending Pendingは、すべての関数が作成されたときに通過する最初の状態です。Pending中にLambdaはリソースを作成または設定しようとします。関数はアクティブ状態のときにのみ呼び出すことができるため、関数を操作する呼び出しやその他のAPIアクションは失敗します。関数作成直後に関数の呼び出しや更新をするように構築された自動化処理は、関数がPendingからActiveに移行したかどうかを最初に確認するように実装する必要があります。 Active 関数の最初の作成中にリソースの構成またはプロビジョニングが完了した後、Activeになります。関数は、Active状態でのみ呼び出すことができます。 関数の更新中、状態はActiveに指定されたままですが、Activeな関数の更新の状態を表すLastUpdateStatusと呼ばれる別の属性があります。更新中、呼び出しは、更新操作が正常に完了するまで関数の以前のコードと設定内容にて実行され、更新完了後、新しいコードと設定が使用されます。 Failed Failed状態は、リソースの設定またはプロビジョニングのいずれかが失敗したことを表す状態です。 Inactive Lambdaサービスが設定されたリソースを回収するのに十分な時間アイドルになっている関数は、Inactive状態に移行します。Inactive状態の関数を呼び出すと、失敗し、それらのリソースが再作成されるまで関数はPending状態に設定されます。リソースの再作成に失敗した場合、関数はInactive状態に戻ります。 すべての状態について、StateReasonとStateReasonCodeの2つの属性が設定されています。どちらも問題のトラブルシューティングのために存在し、現在の状態に関する詳細情報を提供します。 LastUpdateStatusについて InProgress InProgress状態は、既存の関数で更新が行われていることを示します。関数がInProgress状態にある間、関数呼び出しは関数の以前のコードと設定にルーティングされます。 Successful Successful 状態は、関数の更新が完了したことを示します。関数が更新されると、次の更新までこの状態がセットされたままになります。 Failed Failed状態は、関数の更新が失敗したことを示します。変更は中止され、関数の以前のコードと設定がActive状態のままになり使用可能となります。 すべてのLastUpdateStatus値には、LastUpdateStatusReasonとLastUpdateStatusReasonCodeの2つの属性が設定されています。これらは、更新に関する問題のトラブルシューティングに役立ちます。 関数状態のライフサイクル ある状態から別の状態への関数状態の遷移は、関数に対して実行されるアクションに完全に依存しています。関数の状態から状態に手動で移動する方法はありません。 関数の状態のライフサイクル   すべての関数について、主要な状態のライフサイクルは次のようになります。 作成時に、関数はPending状態になります 必要なリソースが正常に作成されると、Active状態に移行します リソースまたは関数の作成が何らかの理由で失敗すると、Failed状態に移行します […]

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 今週も週刊AWSをお届けします。 毎日本当に暑い日が続きますね。さて初のオンライン開催となるAWS Summit Onlineまであと２週間少々になりました。オンライン開催ですので、全国どこからでも、涼しい部屋からご参加いただけますし、オンデマンド視聴でいつでも観ていただくことが可能になっています。セッション申し込みが開始になっていますので、ぜひサイトをチェックしてみてください。私は「Architecting and Building – ログデータ用のデータレイク＆分析環境をクイックに構築するには？」と「Amazon QuickSight BASIC ハンズオン ～ QuickSight の基本操作を 50 分で学ぶ～」を担当していますので、よろしければご覧になってください。 AWS Summit Online 2020 年 9 月 8 日 (火) ～ 9 月 30 日 (水) オンラインで開催 それでは、先週の主なアップデートについて振り返っていきましょう。

お客様からのフィードバックと新しいベストプラクティスに基づいて、AWS Well-Architected Framework のセキュリティの柱をアップデートしました。この記事では、セキュリティの柱のホワイトペーパーと AWS Well-Architected Tool の変更点の概要を紹介し、新しいベストプラクティスとガイダンスについて説明します。 AWS は、お客様がセキュアで高パフォーマンス、耐障害性、効率的なインフラストラクチャを構築することを支援するために、Well-Architected Framework を開発しました。Well-Architected Framework は、運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化の5つの柱から成り立っており、お客様、パートナー、AWS 内の各チームからのフィードバックを受けて、定期的にフレームワークを更新しています。またホワイトペーパーに加えて、AWS Well-Architected Tool も用意されており、ベストプラクティスに照らし合わせてアーキテクチャをレビューすることもできます。

2020 年 8 月 18 日に新しいサービス Amazon Interactive Video Service (Amazon IVS) について、サービス概要と使い方を実演でご説明するほか、ゲストスピーカー様（株式会社ディー・エヌ・エー様）より現場での活用をご紹介していただくイベントを開催しましたので、その資料公開とともに内容をブログでお届けします。 Amazon IVS は、コンテンツの取り込み、処理、配信までの動画ワークフローを一括でまとめられるマネージド ライブストリーミング ソリューションです。汎用ストリーミングソフトウェアから Amazon IVS を介し、ウェブサイトやアプリへ低遅延のままライブストリームを配信できます。

AWS ヒーロープログラムは、たくさんの人が AWS スキルを身に付けることができるように支援しながら、AWS の知識を共有し、AWS について教えることにおいて期待をはるかに上回る活躍をする個人を厳選し、認定するプログラムです。これらのリーダーたちは、世界中のテクニカルコミュニティに大きな影響を与え、その取り組みは高く評価されています。 本日は、ギリシャおよびポルトガル初のヒーローを含めた最新の AWS ヒーローをご紹介したいと思います。 Angela Timofte – コペンハーゲン (デンマーク) サーバーレスヒーローの Angela Timofte 氏は、Trustpilot のデータプラットフォームマネージャーです。知識の共有、コーチング、およびパブリックスピーキングに情熱を傾ける Timofte 氏は、自らが模範となること、そして人々がその目標を達成するために必要なスキルを追求して身に付ける後押しをすることに全力で取り組んでいます。また、モノリシックなソリューションからのサーバーレスアプリケーションとイベント駆動のアーキテクチャを使用した移行を実行しながら、最新のテクノロジーを使用してスケーラブルなソリューションを構築することにも意欲的です。Timofte 氏はコペンハーゲンの AWS ユーザーグループの共催者で、AWS Summits、AWS Community Days、ServerlessDays などでたびたび講演を行っています。 Avi Keinan – テル・アビブ (イスラエル) コミュニティヒーローの Avi Keinan 氏は、DoIT International のシニアクラウドエンジニアです。AWS インフラストラクチャ、サーバーレス、セキュリティソリューションを専門とし、複雑な問題の解決に熱心に取り組み、他者を支援することに情熱を注いでいます。Keinan 氏は多数のオンライン AWS フォーラムとグループのメンバーで、複雑なソリューションとシンプルなソリューションの解決において、初心者と経験豊富なクラウドユーザーの両方を支援しています。また、YouTube チャンネルにも AWS 関連の動画を頻繁に投稿しています。 波田野裕一 – 東京 (日本) コミュニティヒーローの波田野裕一氏は、運用設計ラボ合同会社の創立者兼 CEO です。2014 年に 日本 […]

Amazon RDS の Online Seminar を開催致します。
全3回に渡り、Amazon RDS の最新情報をご説明させて頂く予定です。
オンラインでの開催ですので、気軽にご参加頂ければと思います。

はじめに みなさんこんにちは、ソリューションアーキテクトの福嶋、渡邊です。AWS では 2018 年・2019 年と実施してきた自動車業界向けクラウドテクノロジーカンファレンス「AWS Autotech Forum」を夏と冬の2日間に拡大し、「AWS Autotech Forum 2020 Online #1」を8/7にオンラインにて開催させていただきました。オンライン開催第一回目となる今回は、MaaS、自動運転開発、コネクテッドカー、エッジコンピューティング、マップ／ロケーションサービス等の分野において、先進的な取り組みを志向する企業のビジネスリーダー、エンジニアの方々に向けて、お客様の新たなビジネスをご支援させていただく中で学んできた、汎用的に利用可能なプラクティスやテクノロジーの活用シーンを AWSのソリューションアーキテクトからご紹介させていただきました。 オープニング 自動車業界における AWS の取り組みとお客様事例 ソリューションアーキテクト安藤から皆様の新しいビジネスの企画立案に役立てていただくために、 AWS の活用事例や取り組みについてご紹介しました。 テクノロジートレンドの CASE (Connected/Autonomous/Shared/Electric) はすでに多くのお客様が取り組まれており、ビジネストレンドである MaaS への注目度も日増しに高まっています。 MaaS にはエマージングビジネスの側面と企業間アライアンスによる新プラットフォームビジネスの側面があり、AWS を活用いただくことで「価値創出への集中」「最新技術の活用」「試行錯誤の繰り返し」といったメリットをご享受いただけます。 セッションの中では実際に、 AWS をご活用いただいている企業の事例や CES 2020 において Amazon と AWS が共同で発表した自動運転で走行する電気自動車におけるカーシェアリングサービスのコンセプトデモを例に AWS をご利用いただくことによるメリットがどのようなビジネス効果を生み出しているかをご説明しました。 登壇資料: 自動車業界における AWS の取り組みとお客様事例 MaaS関連セッション AWS Connected Mobility Solution (CMS) のご紹介 ソリューションアーキテクト高野からは、コネクテッドモビリティのシステム開発に関する AWS […]

AWSジャパン・パブリックセクターより、寄稿記事の掲載のお知らせです。隔月で刊行されている雑誌『行政＆情報システム』の“「行政におけるパブリック・クラウド」特集号”にAWSパブリック・セクターメンバーが執筆した記事が掲載されています。 記事の全文をお読みいただくには、発行者である「行政情報システム研究所」宛にバックナンバーの購入をお申し込みをいただくか、もしくは、こちらのリンクより、150円で記事単位でのダウンロードが可能です。　今回のAWSメンバーからの寄稿記事は 「公共機関で実践されるクラウドセキュリティのベストプラクティス」と題されています。 本文中でも引用されている数字として、富士キメラ総研によると、2019年度の公共クラウド市場は前年比22.0%増の925億円となり、2023年度には2,368億円に 達すると予測されています。 今回の寄稿の問題意識は、次のようなものです。「＞行政情報システムのクラウド化を検討する上でもっとも大きな検討事項となるもの、それはセキュリティです。行政機関の立場から見れば、クラウドは外部のサービスとして位置付けられ、利用そのものに心理的なハードルが存在しました。また、これまでの技術文書やガイドラインがオンプレミスを前提として記述されているため、クラウドを利用する時に考慮すべき事項が明確化されていませんでした」──こうした問題意識のもと、今回の寄稿では、「クラウドを活かしたセキュリティ向上のためのペストプラクティスを紹介」しています。 以下に、掲載記事の概要・要点を幾つかご紹介します。 寄稿の４つの要点：クラウドで「システム」と「データ」を守り、「第三者評価」を活用し「サービス」を継続 今回の寄稿は、「①クラウドでシステムを守る」「②クラウドでデータを守る」「③クラウドでサービスを継続する」「④クラウドで第三者評価を活用する」──の４つの章立てで構成されています。 ①クラウドでシステムを守る ──行政情報システム全体のセキュリティを確保するためには、クラウド環境のセキュリティに留まらず、オンプレスミスからクラウドまでの流通経路を考慮し、システム全体でセキュリティを高める必要があります。そのための手法として、クラウドへの接続には、インターネットを利用した通信に加え、１）VPN（Virtual Private Network）や専用線を利用して閉域ネットワーク環境を構築する、２）他のユーザからのアクセスを許容しないプライベートなネットワーク空間を構築する──等の手法を紹介しています。 ②クラウドでデータを守る ──システム全体のセキュリティ確保をユーザとクラウド事業者とで責任分担し、各々の役割を相互に共有する実装モデルである、『責任共有モデル』 という考え方を紹介しています。併せて、１）クラウド事業者が提供するストレージサービスでは、ファイルを配置するだけで自動的に複数の拠点で冗長化され、耐久性が向上すること、２）また、そのファイルに対して誰にどのようなアクセス権限を付与するかなどのきめ細かな権限設定を行うことができること、３）機密性の高いデータに関しては暗号化機能を提供できること──などが、説明されています。 ③クラウドでサービスを継続する ──システム全体の可用性を高め、万が一の障害時においても事業を継続するためには、できる限り単一障害点を作らないことがベストプラクティスです。１）AWSはユーザからの課題や要望に対して不断のサービス改善を実施しており、それらに基づいて『Well-Architectedフレームワーク』 と呼ばれるシステム設計上のベストプラクティスを提供していること、２）AWSでは、データセンター、仮想インスタンスのレベルにおいて冗長構成をとることが可能であること、３）AWSが提供するサービスの多くはインフラストラクチャー管理、セキュリティコントロール、コンプライアンスコントロール、コストの最適化などをサービスとして提供する『マネージドサービス』の形態をとっていること──などが、説明されています。 ④クラウドで第三者評価を活用する ──クラウドを利用するにあたり、最後の課題となるのが“漠然とした心理的なハードル”です。「クラウドはユーザの物理的な管理下にないため説明責任が果たせない」との論調が存在します。こうした心理的なハードルを払拭し、ユーザがクラウドを利用する際の説明責任を果たす方法として、第三者評価の活用があります。「政府情報システムにおけるクラウドサービスの利用に係る基本方針」では、「クラウドサービスの情報セキュリティ機能の実態を利用者が個別に詳細に調査することは困難」としており、「パブリック・クラウドに関しては、第三者による認証や各クラウドサービスの提供している監査報告書を利用することが重要である」と示しています。併せて、日本では「政府情報システムのためのセキュリティ評価制度（ISMAP）」が2020年に制定され、施行されました。　ISMAPの２つのメリットに関し、１）現場の担当官によるクラウド事業者に対する評価を本制度に委ねることができる、２）クラウドを前提としたシステム調達の仕様策定において、「ISMAPクラウドサービスリストに掲載されているクラウドサービスの中から選択することを原則とする」と表記することで、安全で信頼できるクラウド事業者の選定が実現できる──旨、説明しています。 ❖４つのコラムにより、「閉域接続」「データ廃棄」「マイナンバー等の特定個人情報の扱い」「データセンターの冗長化」を例示 また、今回の寄稿では、具体的な例示を伴った解説を心がけるために、以下、４つの「トピック」をコラム形式で盛り込んでいます。 【トピック#1】　総合行政ネットワーク（LGWAN）を介したクラウドへの閉域接続：　北九州市と日立製作所による、行政事務のデジタル化やデータ利活用、クラウド利活用を目的とし、日立製作所が提供している「地域IoT連携クラウドサービス」を活用して、LGWANから専用線で閉域接続されたバーチャルプライベートクラウド上に構築した行政文書目録検索や通知文書閲覧システムの実証実験に関し、紹介しています。 【トピック#2】　クラウド上での安全なデータの廃棄：昨今の情報漏洩に端を発したデータ廃棄についても、オンプレミスとクラウドではアプローチが異なることを説明しています。統制の一例として、「ユーザはストレージ領域をデフォルトで暗号化」「データを削除する際は、併せて当該領域の暗号鍵を削除」等の手法を紹介し、「クラウドではデータへのガバナンスがユーザに取り戻され、第三者が適切に廃棄したかという証明問題からそもそも解放される」旨、例解しています。 【トピック#3】　クラウド上での個人情報や特定個人情報の保護：　社会保険診療報酬支払基金が、社会保障・税番号制度の導入に伴い、「医療保険者等向け中間サーバー等における資格履歴管理、情報提供ネットワークシステムを通じた情報照会・提供及び本人確認に関する事務」においてマイナンバー等の特定個人情報を扱うことから、実際のシステム構築に際し、「アプリケーションやデータを統制するユーザの責任と、インフラストラクチャーを統制するクラウド事業者の責任を区別して整理」した事例に関し、紹介しています。 【トピック#4】　クラウドを活用したデータセンターの冗長化：　政府CIO補佐官等ディスカッションペーパーによる「パブリック・クラウドを利用した情報システムにおける計画・構築時の基本的な考え方」では、大規模災害対策について、オンプレミスでの「データセンターの2重化、データバックアップの遠隔地保管等を予算の制約内で検討」との考え方に対し、クラウド利用時の考え方として「広域の大規模災害発生時においてもサービスを継続できるよう、マルチアベイラビリティゾーン、マルチリージョンを活用した設計とする（多大な追加コストは不要）」との対比を示しています。   以上の章立てとコラムの構成に基づき、寄稿の最終段落は　“クラウドを活かしたセキュリティ向上は制度面、実装面、技術面においても、十分な検討を経て成熟期を迎えています。「クラウドこそがセキュリティを高めるための解決策である」と言われる日も遠くはないと私たちは考えています”──と、結ばれています。 ぜひご一読をいただければ嬉しいです。   ❖Read More ： AWS Blog:　AWSも参加した調査研究として（社）行政情報システム研から「パブリッククラウド活用」の報告書が発表されました　──　同月号の『行政＆情報システム』で特集されている「調査報告書」に関して、AWSからも概要を紹介しています。 日本の公共部門の皆様へのご案内 今後ともAWS 公共部門ブログ（英語版）で AWS の最新ニュース・公共事例をフォローいただき、併せまして、「農水省DX室」「気象庁の衛星ひまわり8号のデータセット」や「情報処理推進機構（IPA）」など日本の公共機関との取り組みを紹介したAWSジャパン・パブリックセクターチームの過去の投稿に関しても、ぜひご覧いただければ幸いです。 ＊　＊　＊　＊ このブログは、アマゾンウェブサービスジャパン株式会社 パブリックセクター 統括本部長補佐（公共調達渉外担当）の小木郁夫が執筆しました。 Tags: Government /政府、Public-Sector / 公共部門

  発表内容 AWS Contact Center Intelligence (CCI) ソリューション がご利用いただけるようになったことを発表します。これは、お客様が AI をコンタクトセンターに簡単に統合できるようにするサービスの組み合わせで、AWS パートナーネットワーク（APN）パートナーを通じて提供します。 AWS CCI には、セルフサービス、ライブコール分析、エージェントアシスト、コール後分析のソリューションがあり、既存のワークフローに AI をすばやくデプロイしたり、まったく新しいワークフローを構築したりできます。 料金とリージョンごとにご利用いただけるかどうかについては、使われている基本サービス (Amazon Comprehend、Amazon Kendra、Amazon Lex、Amazon Transcribe、Amazon Translate、および Amazon Polly) に応じて異なります。 AWS Contact Center Intelligence とは? AWS CCI は、顧客とのやり取りの前、最中、後に、AI を活用したソリューションをコンタクトセンターに提供することを以前申し上げました。 同僚の Swami Sivasubramanian (AWS の Amazon Machine Learning 担当副社長) は、次のように述べています。 「コンタクトセンターのお客様が、機械学習の専門知識がなくても、機械学習機能の恩恵を簡単に受けられるようにしたいと考えています。APN テクノロジーおよびコンサルティングパートナーと提携して AWS Contact Center Intelligence ソリューションを市場に投入することにより、お客様は、クラウドベースの機械学習サービスのメリットをより簡単に実現すると同時に、専門的なデベロッパーを雇って既存のコンタクトセンターへ ML 機能を統合する手間と必要性を省くことができます」 […]