Category: Messaging

この記事は、Dynamically personalize your in-product user experience using Amazon Pinpoint in-app messaging を翻訳したものです。 現在、多くの企業が、EメールやSMSなどのチャネルを通じた製品外へのメッセージと、ユーザーがモバイルやウェブアプリケーション内にいるときに表示される製品内へのメッセージの整合性を保つことに苦労しています。企業がターゲットとなる顧客にあるメッセージをEメールで送ったとしても、顧客がアプリケーションにアクセスすると、違うメッセージが表示される場合があります。これでは顧客が混乱してしまい、割引商品の購入など価値の高い行動を起こす可能性を下げてしまいます。アプリケーションに特定のメッセージをハードコーディングすることで回避することもできますが、これでは開発チームの時間を消費してしまい、モバイルやウェブのクライアントを新しくリリースする必要もあり、導入が遅くなります。 Amazon Pinpoint In-app messaing (アプリ内メッセージング) により、開発者は初期実装の後にクライアント側のコードを更新することなく、ターゲットに対し製品内のメッセージを動的に表示することができます。これにより、マーケティング担当者などの非技術者でも、開発チームから独立して対象の顧客へメッセージングすることができ、アプリケーション体験を変更することができます。また、対象顧客への製品外のメッセージングと同様の内容を、製品内へメッセージングすることができます。これにより、一貫したユーザーへのメッセージングが作成され、顧客が価値の高い行動を実行する可能性を高めることができます。

この記事は Amazon Elastic Container Service (ECS) Auto Scaling using custom metrics (記事公開日: 2022 年 5 月 23 日) の翻訳記事です。 導入 Amazon ECS を使用することで、クラスター管理のための独自のインフラストラクチャをインストール、運用、スケールする必要がなくなります。 お客様は、Amazon ECS 上で動作するマイクロサービスアプリケーションのデプロイとスケーリングに、水平スケーラビリティを採用しています。これは、Application Auto Scaling サービスを用いて、メトリクスデータに基づいて自動でスケールすることで実現できます。

AWS SaaS Factoryチームのシニアパートナーソリューションアーキテクト Raju Patel によって書かれた記事です。 モダンアプリケーションは、サービス統合、バッチ処理、またはワークフローオーケストレーションの一部として、キューイングに依存することがよくあります。キューは、システムの環境に拡張性と耐障害性を追加するうえ重要です。 これは、キューイング戦略をマルチテナントソリューションのワークロードにどのように適用するかを考える必要がある、Software-as-a-Service（SaaS）環境では特に当てはまります。SaaS アプリケーションのキューイングモデルを設計する際には、データの分離、パフォーマンス、および運用を考慮する必要があります。 多くの組織がアマゾンウェブサービス (AWS) 上で SaaS ソリューションを構築および運用する過程において、筆者は AWS SaaS Factory のパートナーソリューションアーキテクトとして彼らと連携をしてきました。特に、テナントの分離とスケーラビリティを考慮しつつ、俊敏性を高めるマルチテナントソリューションの構築において組織を支援することにフォーカスしています。 この記事では、Amazon Simple Queue Service (SQS) を利用して SaaS ソリューションを構築する際の一般的なシナリオをいくつか紹介します。ここでは、データ分離、スケーラビリティ、コンプライアンス要件が、キューイングモデルの選択にどのように関係するかを説明します。 本投稿には、マルチテナントソリューションでの SQS の利用について示すサンプルコードが含まれています。 SaaS におけるキューイングの課題 SaaS 環境におけるキューの役割について理解を深めるために、サンプルユースケースを見てみましょう。図 1 に示す概念図は、キューを使用する注文管理システムの一例です。 図 1 – キューを用いた注文管理と在庫更新のフロー 最初のフローは、注文、作成、確定、出荷の各サービスの統合を示しています。注文キューと出荷キューは、複数のテナントからメッセージを受信します。注文確定や注文出荷などのサービスは、Amazon Elastic Kubernetes Service (Amazon EKS) のコンテナで実行することも、AWS Lambda でサーバーレスで実行することもできます。 図 1 の 2 番目のフローは在庫の更新についてです。このフローでは、テナントがファイルをアップロードし、メッセージがキューに配置されて処理されます。バッチによる在庫更新プロセスでメッセージが取得され、ファイルから在庫テーブルにデータがロードされます。 キューの構成は比較的単純ですが、マルチテナンシーでは追加の考慮事項がいくつかあり、それらはキュー設計に影響を与える可能性があります。 たとえば、あるテナントが […]

この 2 部構成のブログシリーズでは、メールアドレスとドメイン名を使用してユーザー認証を行う方法を学習します。この方法では、静的な Web サイトへの資格情報を使用しないユーザーアクセスを制限します。 このブログシリーズの第 2 部では、認可メカニズムの実装方法を学習します。前回のブログ記事では、認証メカニズムの実装方法を学習しました。ブログ記事の第 1 部を読んだ場合は、序文をスキップして、前提条件を読んでください。

この 2 部構成のブログシリーズでは、メールアドレスとドメイン名を使用してユーザー認証を行う方法を学習します。この方法では、静的な Web サイトへの資格情報を使用しないユーザーアクセスを制限します。 この最初のブログでは、認証メカニズムの実装方法を学びます。第 2 部のブログ記事では、認可メカニズムを実装してソリューションを完成させる方法を学習します。

ダイナミックかつ急速に変化する世界で消費者のニーズを満たすために、組織は先を見越しつつリアルタイムに対応できるサプライチェーンプラットフォームを確立する必要があります。モノのインターネット（IoT）、人工知能と機械学習（AI / ML）、クラウドベースのプラットフォームなどの急速な技術開発による進化を活用することで、サプライチェーン全体でデータを捉え、人の介入を最小限に抑えて自動制御でイベントに対応できるスケーラブルなグローバルプラットフォームを構築できます。 このブログシリーズの 1 本目では、AWS がこれらの技術を用いいかにして、顧客のサプライチェーンにおける課題解決を支援をしているか紹介します。まずは図 1 に示すような動的なサプライチェーンを構築するために必要とされる、基本的な構成要素に焦点を当てます。これにより、混乱や無駄を最小限に抑え、顧客の SLA コンプライアンスを保証します。今後のブログでは、より具体的なユースケースとソリューションについて詳しく解説していく予定です。

ドキュメントの要約は、M&E 業界における重要なユースケースの一例です。記事の見出しの作成からプッシュ通知用の短文要約の作成まで、自動化された文書要約ソリューションは、コンテンツプロバイダーが消費者とより効果的にエンゲージメントを築くのに役立ちます。従来、要約作業は手作業で行われていました。しかし、特に最近のユーザー作成コンテンツの爆発的な増加により、それは必ずしも実用的ではありません。最新の自然言語生成（NLG）モデルは、高品質の文書要約を自動生成することができます。そして、 Amazon Web Services（AWS）パートナーからのソリューションは、これらのモデルの使用を容易にします。AWS パートナーである Hugging Face 社の Transformers ライブラリと Amazon SageMaker – ML を併用すれば、すべてのデータサイエンティストと開発者が、これらのモデルをこれまで以上に簡単に利用できるようになります。このブログ記事では、Amazon SageMaker を使用して、Hugging Face ライブラリを使用した最先端の文書要約ソリューションをデプロイする方法について説明します。

エージェントの時間の半分近くは、顧客との通話やチャットから離れ、CRM や業務別ソリューションなどの外部アプリケーションのタスクに費やされています。多くの場合、企業は口頭での指示、電子メール、外部アプリケーションのメモなど、さまざまな方法でこれらのタスクをエージェントに割り当てます。このため、これらのタスクの追跡、測定が困難になります。エージェントはタスクを完了するために異なるアプリケーション間を移動しなければならないため、どれが最優先事項であるかを把握するのに苦労します。そして、エージェントはタスクやフォローアップ項目を追跡するために、記憶や手書きのメモに頼ることがよくあります。これにより、生産性が低下し、顧客に影響するタスクが完全に失われるリスクも増大します。Amazon Connect Tasks を使用すると、企業やコンタクトセンターのマネージャーは、エージェントの効率性の向上、反復作業の自動化、コストの削減といった課題に対処できます。

このブログは 2022 年 3 月 7 日に Ilir Iljazi (senior cloud solutions architect) によって執筆された内容を日本語化した物です。原文はこちらを参照して下さい。 分散アーキテクチャでは、アプリケーションログを保存する必要がある場合が多く、AWS のお客様では、Amazon S3 バケットを介して保存されることがよくあります。ログには、ランタイムトランザクション、error / failure のステータス、またはアプリケーションのメトリクスや統計に関する情報が含まれている場合があります。これらのログは、後にビジネスインテリジェンスで使用され、有用な洞察を提供し、ダッシュボード、分析、およびレポートを生成するために使用されます。アプリケーションによっては、ログファイルは信頼できる唯一の情報源として機能し、ガバナンスや監査目的には不可欠です。そのため、高い可用性と耐久性を保証して、ログを永続的に保存する必要があります。多くのお客様は、ログを様々な形式で Amazon S3 に直接書き込むことを選択しますが、Amazon Kinesis などの AWS サービスを介してログをストリームすることを好むお客様もいます。 このブログ記事では、Amazon S3 Glacier ストレージクラスに何百万ものログファイルをアーカイブする際の、コストに関する考慮事項を説明します。Amazon S3 Glacier ストレージクラス（Amazon S3 Glacier Instant Retrieval、Amazon S3 Glacier Flexible Retrieval、Amazon S3 Glacier Deep Archive）は、データアーカイブと長期バックアップ用の、セキュアで耐久性があり、非常に低コストの Amazon S3 クラウドストレージクラスです。Amazon S3 Glacier ストレージクラスにオブジェクトを移行するために、Amazon S3 は […]

今回のブログでは、 AWSジャパン・パブリックセクターより、「米 連邦歳入庁や州政府機関が、クラウドを用いて納税・収税まわりの業務を改善している取り組み」について紹介します。ご不明の点、「Contact Us」までお問合せください。（以下、AWS Public Sector Blog へ掲載された「Taxes, governments, and great experiences using the cloud」と題された投稿の翻訳となります。）