Amazon Web Services ブログ

こんにちは。AWS ソリューションアーキテクトの上原(@pioho07)です。 AWS re:invent 2019開催から二週間経ち、徐々に興味のあるサービスを触り始めていらっしゃる方も多いのではないでしょうか。ちなみに自分はre:inventの前に発表があったAmazon CloudWatch Syntheticsというサービスが気になっています。外形監視をするマネージドサービスで単純なハートビートやGUI画面操作のチェックなどを行います。また、画面キャプチャを残したり各アセットのレスポンスの確認やアラームを上げるといったことができるので、さっそく自分のテストアプリへの監視を初めてみました。(まだプレビューで東京リージョンには来てない点ご注意ください) 本ブログでは本日、住友不動産六本木グランドタワービルにてFringe81様、BASE様、エブリー様、ディップ様、クルーズ様、アイアド 様、ファーストコンサルティング 様、Gunosy様の8社合同で開催したre:Invent 2019 Recapイベントの様子をレポートしていきたいと思います。 Re:invent 2019 Recapとは？ Recapイベントとは、毎年AWS re:Inventの前後に多数の新サービス・サービスアップデートが公開されるため、その内容を改めて振り返り、普段の業務のどういったところに使えるサービスなのかを復習できるイベントです。今後もAWS Loftなどの会場やオンラインでRecapイベントを開催していきますので、ご興味のある方はこちらをご確認の上ぜひご参加下さい。 https://aws.amazon.com/jp/about-aws/events/2019/reinvent-2019-recap/ 今回は住友不動産六本木グランドタワービルにオフィスを構えるFringe81様、BASE様、エブリー様、ディップ様で同じようなニーズがあり、Recapイベント+交流会という形で4社様と本ビル周辺にいらっしゃるお客様4社含めてAWS合同で開催いたしました。タイトルにあるビルシリーズって何？という方はビルシリーズ1発目のこちらのブログも是非御覧ください！(他にも麻布十番ビルでもビルシリーズを開催しました)。六本木にある本ビル最上階(43階)の素晴らしい会場をお貸しいただいたFringe81様ありがとうございました。 セッション 当日は8社で計30人以上のエンジニアの方々にお集まり頂きました。re:Invent 2019に参加されたBase 川口様からの熱い現地レポートLTが続きます。コンテナ周りのセッションに注目いただき、”現地でトリの人@toriclsにDMし「Containers Happy Hour」に参加でき、そこでAmazon ECS担当者と内部実装などを聞くことができてよかった”とおっしゃっていました。また、ExpoやJapanNightなども期待以上でおもしろかったそうです。 re:Inventに参加出来なかった方は、こちらの公式Youtubeにre:Inventのセッション映像が逐次アップロードされていくのでぜひ気になるサービスのDive Deepセッションやグローバル事例を確認してみて下さい。最先端の事例が集結しているので様々な学びが得られるはずです！ https://www.youtube.com/channel/UCdoadna9HFHsxXWhafhNvKw/videos ここからre:Invent 2019 recapに入ります。AWS ソリューションアーキテクトの加治・大倉・石見からre:Invent前後のアップデートの中で皆様のお役に立ちそうなものをピックアップしてご紹介しました。 当日の話を一部抜粋しますと、例えばコンテナ化に取り組まれている方々には以下のような嬉しいアップデートがありました。 Kubernatesを運用する上でEC2のレイヤーの管理から解放されたいというニーズから開発された、Amazon EKSのAWS Fargate対応https://aws.amazon.com/jp/blogs/news/amazon-eks-on-aws-fargate-now-generally-available/ Fargateをより安価に使いたい方にはFargate SpotやSaving Planが登場https://aws.amazon.com/jp/blogs/news/aws-fargate-spot-now-generally-available/ https://aws.amazon.com/jp/blogs/news/new-savings-plans-for-aws-compute-services/ AWS ECS Cluster Auto ScalingとECS Cluster Capacity Providerの登場によりECS on EC2がより楽に構築・運用できるようにhttps://aws.amazon.com/jp/blogs/news/aws-ecs-cluster-auto-scaling-is-now-generally-available/ Analytics周りでは一部プレビュー状態ではあるものの、今後の分析基盤を大きく変えうる大きなアップデートがありました。これらはそれぞれ「コンピュートとストレージ」「ホットストレージとウォームストレージ」を分離することで、各々を最適化できるよりクラウドらしい構成を目指しているのがポイントです。 Amazon RedshiftのRA3インスタンスとAQUAの登場によりパフォーマンスが非常に向上https://aws.amazon.com/jp/blogs/news/amazon-redshift-update-next-generation-compute-instances-and-managed-analytics-optimized-storage/ […]

AWS では、AWS 環境内のセキュリティイベントについて自動化による迅速な検知と対応をすることをお勧めしてます。自動化は、検知と対応の速度を向上させることに加えて、AWS で実行するワークロードを拡大するときにセキュリティ運用もスケーリングするのに役立ちます。これらの理由から、セキュリティの自動化は、Well-Architected フレームワークとクラウド導入フレームワークの両方、およびAWS セキュリティインシデント対応ガイドで概説されている重要な原則です。 このブログでは、AWS 環境内に自動セキュリティレスポンスメカニズムを実装する方法を学習します。このブログには、一般的なパターン、実装に関する考慮事項、およびソリューション例が含まれます。セキュリティレスポンスの自動化は、多くの分野にまたがる広範なトピックです。このブログの目標は、基本的な考え方を紹介し、セキュリティレスポンスの自動化の開始を支援することです。

多くの AWS ユーザーは、日々のアクティビティの骨の折れる作業に AWS ポートフォリオで利用できるマネージドサービスを活用しています。Amazon RDS はこれらのサービスの 1 つであり、リレーショナルデータベースのデプロイに最適です。RDS を使って、リレーショナルデータベースの管理と保守の管理費用を大幅に削減できます。 この記事では、あるリージョンから別のリージョンに実行されているデータベースインスタンスの Amazon RDS for Oracle でリージョン間の災害復旧 (DR) をセットアップする方法を示します。ソリューションは、Amazon EC2 インスタンスハブにインストールされた、Oracle GoldenGate を使用することです。そのインスタンスハブは、DDL レプリケーションを実行するために統合キャプチャモードで設定されたものです。 概要 次の要因に応じて、DR を実装する方法は複数あります。 目標復旧時間 (RTO) および目標復旧ポイント (RPO) DR サイトのセットアップと保守のコストと管理タスク 地理的多様性のための DR サイトの場所 Amazon RDS for Oracle は、マルチ AZ 配置オプションを提供し、データベース (DB) インスタンスの可用性と耐久性を強化しています。これは、多くの場合、一部の顧客ユースケースに効果的な DR ソリューションです。DR サイトを 2 つの異なるリージョンに分散する必要がある場合、DR にマルチ AZ を使用することはできません。ただし、前述の要因に応じて、このようなソリューションを実装する方法はいくつかあります。 ソリューションのアーキテクチャ ソリューションは、次のコンポーネントで構成されています。 GoldenGate […]

Amazon DynamoDB は、任意の規模で 1 桁のミリ秒のパフォーマンスを実現するために構築されたキーと値およびドキュメントデータベースです。これは、マルチリージョンでマルチマスターのフルマネージドデータベースで、組み込みのセキュリティ、バックアップとリストア、およびインターネット規模のアプリケーション用のメモリ内キャッシュを備えています。 この記事では、開始するために知っておく必要がある基本的な事項を確認します。テーブルを作成し、DynamoDB テーブルを設計するときの主な考慮事項について学習します。次に、いくつかのサンプル項目を挿入し、最後にそれらをクエリします。サンプル項目は実際の例で、AWS のオープンデータのレジストリからの Amazon Customer Reviews Dataset です。このガイドでは、データセットのビジネス要件および技術要件が DynamoDB 設計にどのように通知されるかについて説明します。この記事は読者に前提知識がないことを想定しています。 まず、ユースケースを分析しましょう。この記事のこのデータセットは、1 日数百万人のユーザーにサービスを提供している e コマースウェブサイトの本番レビューを表しています。特定の製品のレビューにすばやくアクセスし、投稿したすべてのレビューをユーザーが見られるようにしたい場合があるでしょう。 これらの条件は両方とも、大規模なデータセットへの高速アクセスを必要とします。DynamoDB は、それに対する完璧なソリューションです。 テーブルの作成 最初のステップは、テーブルを作成することです。 以下のスクリーンショットのプレビューに示すように、AWS マネジメントコンソール のサービスの検索で、DynamoDB を入力して選択します。 以下の画像に示すように、[テーブルの作成] を選択します。 テーブル名 には、product_reviews などの名前を入力します。ここで、重要な決定を行います。DynamoDB は、キーを使用して、複数のインスタンスにデータを整理および配布します。キータイプには、次の 2 つの基本的なタイプがあります。 – パーティションキー – これは、DynamoDB が内部ハッシュ関数に使用して、保存するアイテムの物理的な保存場所を決定する値です。 – ソートキー – これは、一致するパーティションキーを持つアイテムをソートするために使用します。複数の値を連結して、複合ソートキーを作成できます。 ホットキーを回避するために、データが可能な限り均等に分散されるパーティションキーを選択します。パーティションキーの設計とホットキーの回避の詳細については、ドキュメントの「ワークロードを均等に分散するためのパーティションキーの設計」を参照してください。DynamoDB でさらに読み取りを行い、hash と ranges キーを参照する場合、これらはパーティションキーおよびソートキーの以前の用語です。 DynamoDB テーブルには、テーブル内の各アイテムを一意に識別するプライマリキーが必要です。プライマリキー には以下の 2 つのタイプがあります。 – […]

Amazon SageMaker Ground Truth は、機械学習 (ML) 用の高精度なトレーニングデータセットをすばやく構築できるよう支援します。Ground Truth で、サードパーティおよび独自のラベル付けを行う人間の作業者に簡単にアクセスでき、一般的なラベル付けタスク用のビルトインのワークフローとインターフェースも提供できるようになります。さらに、Ground Truth では自動データラベル付けを使用して、ラベル付けのコストが最大 70% 削減します。自動データラベル付けとは、人間がラベルを付けたデータから Ground Truth をトレーニングし、サービスが独自にデータにラベルを付けることを学習するものです。 セマンティックセグメンテーションとは、画像内の個々のピクセルにクラスラベルを割り当てるなどのコンピュータービジョン ML の手法です。たとえば、移動中の車両が撮像した動画フレームで、クラスラベルに車両、歩行者、道路、信号機、建物、背景を含めることが可能です。画像内のさまざまなオブジェクトの位置を高い精度で理解することができるため、自律走行車やロボットの知覚システムの構築によく使用されます。セマンティックセグメンテーション用の ML モデルを構築するには、まずピクセルレベルで大量のデータにラベルを付ける必要があります。しかし、このラベル付けプロセスが複雑で、熟練したラベル付けの作業者とかなりの時間を要します。画像を正確にラベリングするのに最大 2 時間もかかる場合もあります。 Ground Truth ではセマンティックセグメンテーションのラベリングユーザーインターフェイスに自動セグメント機能を追加し、ラベル付けスループットと精度を向上し、かつ作業者の疲労を軽減することを目指しました。自動セグメント化ツールでは、最小限の入力だけで画像内の関心対象の領域に自動的にラベルを付けることができるため、タスクが簡素化します。これで、自動セグメントからの結果出力を受け入れる、元に戻す、または修正することができます。次のスクリーンショットは、ツールバーの自動セグメント化機能部分を強調し、画像内の犬をオブジェクトとしてキャプションしたことを示しています。この犬に割り当てられたラベルは Bubbles です。 この新機能で、セマンティックセグメンテーションタスクの作業が最大 10 倍早くなります。多角形をきっちり描画したり、ブラシツールを使って画像内のオブジェクトをキャプションする必要はなく、オブジェクトの最上部、最下部、左端、右端の 4 つの部分を描画するだけです。Ground Truth はこれら 4 つのポイントを入力すると、Deep Extreme Cut (DEXTR) アルゴリズムを使用して、オブジェクトの周りにぴったりとフィットするマスクを生成します。次のデモは、このツールでより複雑なラベル付けタスクのスループットを高速化する方法をご紹介しています。 まとめ この投稿では、セマンティックセグメンテーションと呼ばれるコンピュータービジョン ML の手法の目的と複雑さについてご紹介しました。自動セグメント化機能を使えば、作業者による最小限の入力で画像の関心領域のセグメンテーションを自動化でき、セマンティックセグメンテーションのラベリングタスクが高速化します。 いつものように、AWS では皆さんのフィードバックをお待ちしています。コメント欄よりご意見やご質問をお送りください。 著者について Krzysztof Chalupka は Amazon ML Solutions Lab […]

Amazon RDS for PostgreSQL が、バージョン 11.5 以降および 10.10 以降で、高速データのインポートおよびエクスポート方法であるトランスポータブルデータベース機能をサポートするようになりました。RDS PostgreSQL インスタンスから別の PostgreSQL インスタンスに PostgreSQL データベースをインポートする必要がある場合は、pg_dump や pg_restore などのネイティブツールを使用するか、\copy コマンドを使用してデータをターゲットテーブルにロードできます。トランスポータブルデータベースを使用すると、こうした従来のツールよりもはるかに高速にデータを移動することができます。この機能は、データベースごとの物理的な転送メカニズムを提供する pg_transport と呼ばれる新しい拡張機能を使用します。物理的な転送では、最小限の処理でデータベースファイルをストリーミングすることにより、最小限のダウンタイムでデータをより高速に移動できます。 この記事では、pg_transport の一般的なユースケースと、AWS CLI と psql ユーティリティを使用して RDS PostgreSQL 環境でこれを設定および使用する方法について説明します。 pg_transport のユースケース 多くのお客様は、RDS PostgreSQL で独自の SaaS またはマルチテナントおよびエンタープライズアプリケーションを実行しています。これは、Amazon RDS により、AWS での PostgreSQL デプロイの設定、操作、スケーリングが簡単になるためです。単一の RDS PostgreSQL インスタンスに複数のデータベースを配置して、さまざまな顧客やアプリケーションにサービスを提供するのは一般的なことです。このような環境では、トランスポータブルデータベースが役立ちます。 以下のようなユースケースに最小限のダウンタイムで対処できます。 リソースの管理や分離を改善するために、RDS インスタンス間でデータベースを移動する。たとえば、SaaS プロバイダーであれば、特定の容量に達した場合、顧客データを異なる構成 (より大きなインスタンスタイプ、プロビジョンド IOPS、または異なるインスタンスファミリー) に移動する必要があります。 セキュリティおよびコンプライアンスの理由でデータを再編成する。たとえば、ある AWS アカウントの […]

  概要 共有ファイルシステムの使用は、多くのコンピューティングインフラストラクチャにとって重要なコンポーネントです。Linux システムの場合は通常、ネットワークファイルシステム (NFS) を使用して、Linux ホストからマウントされます。ユーザーはホームディレクトリにデータを保存でき、ファイルシステム全体で他のユーザーとデータを共有できます。Amazon Elastic File System (Amazon EFS) は、Linux ホストの場合にこの用途を利用できるクラウドネイティブサービスです。 Amazon EFS は、お使いのファイルに可用性と耐久性の高いバッキングストアをもたらしますが、ファイルが誤って削除された場合やファイルの以前のバージョンを復元する必要がある場合に備えて、ファイルシステムのバックアップを作成するのも役立ちます。AWS Backup を使用すれば、Amazon EFS ファイルシステムのバックアップを一元的に管理、自動化でき、リカバリポイントを復元できます。 この記事では、CloudFormation スタックを起動し、Amazon EFS ファイルシステムと AWS Backup のボールトを作成して Amazon EFS バックアップを安全に保存する方法を説明します。その後、EFS ファイルシステムのバックアップについて取り上げ、特定の復旧ポイントからバックアップを復元する方法についても説明します。 Amazon EFS Amazon EFS は、オンプレミスリソースだけでなく AWS でも実行できるシンプルでスケーラブルでフルマネージド型の伸縮自在な NFS ファイルシステムを提供します。オンデマンドでエクサバイト単位にまで伸縮自在に拡張できるように構築されており、ファイルを追加、削除すると自動的に拡大および縮小するため、成長に対応するために容量をプロビジョンしたり管理したりする必要はありません。 EFS は、幅広いユースケースに対応しています。可能な範囲で最高のスループットが求められる、高度に並列化されスケールアウトされたワークロードから、シングルスレッドで低レイテンシ―が必要なワークロードまで、広範囲にわたります。 以下の Amazon EFS のユースケースを検討してください。 リフトアンドシフト方式のエンタープライズアプリケーション ビッグデータ分析 ウェブ配信とコンテンツ管理 アプリケーションの開発とテスト メディアとエンターテインメントのワークフロー データベースのバックアップ コンテナストレージ AWS […]

Amazon DocumentDB チームは、AWS re:Invent 2019 で皆様と直接お会いしてフィードバックやユースケース、次に構築してほしいサービスなどのご希望を伺い、楽しい時間を過ごすことができました。私にとっての re:Invent の見どころは、FINRA と フルフィルメント by Amazon (FBA) による、2 つのお客様導入事例のプレゼンテーションでした。どちらにも、Amazon DocumentDB への移行に至るまでのそれぞれの遍歴や、開発者の効率性を向上しながらアプリケーションのスケーリングを高速化した方法についてお話しいただきました。 このブログ記事では、re:Invent 2019 からの Amazon DocumentDB 録画セッションについてまとめていきます。 DAT372 – データベースを Amazon DocumentDB へ移行する Amazon DocumentDB のシニアスペシャリストソリューションアーキテクトである Jeff Duffy が、顧客戦略および Amazon DocumentDB への移行の際の検討事項の概要についてお話しします。セッションには、リレーショナルおよび非リレーショナルソース、移行のフェーズ (検出/計画/テスト/実行)、クラスターサイジング、および移行ツーリングについてのディスカッションが含まれます。セッションの目玉となったのは、FINRA が XML を利用して、どのようにしてリレーショナルデータベースから Amazon DocumentDB へ移行したかについての講話でした。アプリケーションから必要とされる変換レイヤーがないため、FINRA は Amazon DocumentDB によって JSON をデータベースでネイティブに使用し、よりスピーディーな移行を行えています。また、FINRA は Amazon DocumentDB がどのように SLA とセキュリティ要件の高い基準を満たしたかについても説明しています。 […]

こんにちは。AWS ソリューションアーキテクトの石見(@kazuya_iwami)です。 先週開催されたAWS re:invent 2019から一週間経ち、徐々に興味のあるサービスを触り始めていらっしゃる方も多いのではないでしょうか。ちなみに自分はre:invent直前に発表されたAmazon Transcribeの日本語対応に惹かれて持っている音源を片っ端から文字起こししてみたところです。 本ブログでは先日、住友不動産麻布十番ビルにてC Channel様、Retty様、エウレカ様、メタップス様の4社合同で開催したre:Invent 2019 Recapイベントの様子をレポートしていきたいと思います。 Re:invent 2019 Recapとは？ Recapイベントとは、毎年AWS re:Inventの前後に多数の新サービス・サービスアップデートが公開されるため、その内容を改めて振り返り、普段の業務のどういったところに使えるサービスなのかを復習できるイベントです。今後もAWS Loftなどの会場やオンラインでRecapイベントを開催していきますので、ご興味のある方はこちらをご確認の上ぜひご参加下さい。 https://aws.amazon.com/jp/about-aws/events/2019/reinvent-2019-recap/ 今回は住友不動産麻布十番ビルにオフィスを構えるC Channel様、Retty様、エウレカ様、メタップス様で同じようなニーズがあり、Recapイベント+個別相談会+交流会という形で4社様とAWS合同で開催いたしました。タイトルにあるビルシリーズって何？という方は他のビルでも開催したこちらのブログを是非！ オシャレな会場を貸していただいたエウレカ様、Retty様ありがとうございました。 セッション 当日は4社で計50人程のエンジニアの方々にお集まり頂きました。AWS 平田のre:Invent紹介から始まり、C Channel Tonny様、Retty 小迫様、エウレカ 金子様、メタップス 阿多様から今後のビルイベントへの思いをお話頂きました。 “同じビルでもあまり交流がなかった4社だったが、今回の合同イベントを通じて交流が持てて嬉しい。今後もこういった取り組みを続けていきたい” エウレカ CTO 金子様 そしてre:Invent 2019に参加されたエウレカ 山本様、原田様からの熱い現地レポートLTが続きます。印象に残ったのはDynamoDBやコンテナのセッションだそうです。 re:Inventに参加出来なかった方は、こちらの公式Youtubeにre:Inventのセッション映像が逐次アップロードされていくのでぜひ気になるサービスのDive Deepセッションやグローバル事例を確認してみて下さい。最先端の事例が集結しているので様々な学びが得られるはずです！ https://www.youtube.com/channel/UCdoadna9HFHsxXWhafhNvKw/videos ここからre:Invent 2019 recapに入ります。AWS ソリューションアーキテクトの石見・上原からre:Invent前後のアップデートの中で皆様のお役に立ちそうなものをピックアップしてご紹介しました。 当日の話を一部抜粋しますと、例えばコンテナ化に取り組まれている方々には以下のような嬉しいアップデートがありました。 Kubernatesを運用する上でEC2のレイヤーの管理から解放されたいというニーズから開発された、Amazon EKSのAWS Fargate対応 https://aws.amazon.com/jp/blogs/news/amazon-eks-on-aws-fargate-now-generally-available/ Fargateをより安価に使いたい方にはFargate SpotやSaving Planが登場 https://aws.amazon.com/jp/blogs/news/aws-fargate-spot-now-generally-available/ https://aws.amazon.com/jp/blogs/news/new-savings-plans-for-aws-compute-services/ AWS ECS Cluster […]

12月3日、AWS は Contact Lens for Amazon Connect を発表しました。これは、機械学習（ML）によって実現される Amazon Connect の機能セットであり、重要な顧客フィードバックを特定し、顧客体験を改善するために、顧客との会話の内容、感情、傾向を理解する手段をコンタクトセンターのスーパーバイザとアナリストにもたらします。Amazon Connect は、Amazon の受賞歴のあるカスタマーサービスを支えるのと同じテクノロジーが用いられたオムニチャネルクラウドコンタクトセンターサービスです。 Intuit、GEアプライアンス、Capital One、Dow Jonesなどの企業は、Amazon Connectを使用して数千のエージェントを容易にスケーリングしながらコンタクトセンターを低コストで運営しています。   コンタクトセンターは毎日大量の顧客との会話を行うため、何百万時間もの通話が記録されます。企業は、これらのコールの正確なトランスクリプト（会話の文字起こし）を取得し、すべてのコールを検索して、問題、共通のテーマ、エージェント・コーチングの機会を特定できるようにしたいと考えています。既存のコンタクトセンター分析サービスを使用できますが、これらのツールはコストが高く、トランスクリプトの提供に時間がかかり、必要な精度が不足しています。そのため、顧客の問題を迅速に検出し、エージェントに実用的なパフォーマンスフィードバックを提供することが困難になります。また、既存のツールがリアルタイム分析を提供できないため、通話中に不満を感じた顧客が電話を切る前にそのようなコールをスーパーバイザが特定して支援することができなくなります。このような課題に対して、企業の中には時間をかけてデータサイエンティストやプログラマを雇い、機械学習技術を適用してカスタムアプリケーションを管理していくところもあります。   Contact Lens for Amazon Connectは、これらの課題に対処し、コンタクトセンターのスタッフが数クリックで機械学習のパワーを簡単に利用できるような従来の枠を超えるエクスペリエンスの一部として、機械学習の分析セットを簡単に有効にできる機能を提供します。Contact Lens for Amazon Connectの使用は簡単です。問い合わせフロー設定で分析するコールを設定するには、「通話記録動作の設定」ブロックの「Contact Lens for Amazon Connect」オプションをチェックします。設定が完了すると、Contact Lens for Amazon Connectは指定されたコールの分析を自動的に開始します。ここをクリックして、プレビューにサインアップできます。   それでは、顧客との会話の分析にContact Lens for Amazon Connectがどのように役立つのかを見てみましょう。   1. 問い合わせ検索の強化:   Amazon Connectの問い合わせの検索ページでは、日付範囲、エージェントのログイン、電話番号、キューなどの条件に基づいて履歴の問い合わせを検索できるようになりました。Contact Lens for Amazon Connect では、指定されたすべてのコールは、最先端の機械学習技術を使用して自動的に文字起こしされ、自然言語処理エンジンを使用して感情を抽出し、検索用にインデックス化されます。したがって、コンタクトセンターのスーパーバイザおよびアナリストは、問い合わせの検索ページから、コール中に顧客やエージェントが言及した単語やフレーズに基づいて問い合わせが特定できるエクスペリエンスをすぐに使用できるようになります。コールで話された内容に基づいて問い合わせを検索できるため、組織は顧客に影響を与えている問題を深く掘り下げることができます。たとえば、ある組織は、自社製品の1つに対して最近発売されたプロモーションコードが機能していないことに気付きました。顧客がこの問題について問い合わせのどの部分で言及したかを検索することで、問題の重大度を把握し、プロモーションコードが失敗した状況を正確に診断することができました。 […]