こんにちは、Amazon Connect ソリューションアーキテクトの梅田です。 2024 年 12 月のアップデートまとめ はお読みいただけましたでしょうか。2025年のアップデートをお届けする最初のブログ更新となります。本年も Amazon Connect の最新情報や有益な情報をお届けできるよう努めてまいります。 今月も アップデート 情報を中心に以下の内容をお届けします。皆さんのお役に立つ内容があれば幸いです！ 注目のアップデートについて 2025 年 1 月のアップデート一覧 AWS Contact Center Blog のご紹介 1.注目のアップデートについて 注目#1: Amazon Connect Contact Lens launches new real-time dashboard (Amazon Connect Contact Lens が新しいリアルタイムダッシュボードをリリース) 注目#2: Amazon Connect Contact Lens dashboards now provide configurable groupings and filters (Amazon Connect Contact Lens のダッシュボードに、設定可能なグループ化とフィルタが表示されるように) Amazon Connect のダッシュボード機能に、コンタクトセンター運用の効率化を支援する2つのアップデートがありました。1つ目のアップデートでは、Amazon Connect Contact Lens に新しいダッシュボードが追加され、エージェントのリアルタイム監視機能が大幅に強化されました。エージェントのステータス、経過時間に応じた強調色表示や、コンタクトのライブモニタリング、割り込み機能など、スーパーバイザーの迅速な状況把握とアクションをサポートする機能が実装されています。さらに2つ目のアップデートでは、ダッシュボードのカスタマイズ機能が拡充され、ウィジェットレベルでのフィルタリングやグループ化、メトリクスの追加・削除が可能になりました。これにより、各ビジネスのニーズに合わせた詳細な分析や、キューの着信や応答状況の把握、顧客対応のパフォーマンス測定がより柔軟に行えるようになります。これら2つのアップデートにより、コンタクトセンターのリアルタイム監視と分析機能が格段に向上し、より効果的な運用管理が可能となりました。これらのダッシュボードのカスタマイズ機能は、Amazon Connect が提供する6つのダッシュボード (会話型分析ダッシュボード、キューおよびエージェントパフォーマンスダッシュボード、フローパフォーマンスダッシュボード、日中予測パフォーマンスダッシュボード、エージェントパフォーマンスの評価ダッシュボード、アウトバウンドキャンペーンのパフォーマンスダッシュボード) で利用可能です。詳細な設定方法は 管理者ガイド を参照してください。 2. 2025年1月のアップデート一覧 Amazon Connect Cases now provides more granular search capabilities and customizable case list views (Amazon Connect Cases がより詳細な検索機能とカスタマイズ可能なケースリストビューの提供を開始) – 01/31/2025 Amazon Connect Cases では、エージェントとスーパーバイザーがエージェントワークスペース内でカスタムフィールド値を使用したケースのフィルタリングが可能になりました。これにより、検索結果の絞り込みや関連するケースの検索が容易になります。ユーザーは、業務に応じて、カスタムカラムの追加、既存カラムの非表示または再配置、ページあたりのケース数の調整を行うことで、ケースリストビューと検索結果のレイアウトをカスタマイズすることもできます。これらの機能強化により、ユーザーはケースリストビューを自らの業務スタイルに合わせてカスタマイズし、ケース管理のワークロードをより効率化することが可能です。  関連リンク 管理者ガイド ワークショップ Amazon Connect now supports agent time off scheduling up to 24 months in the future (Amazon Connect で最大 24 か月先までのエージェントの休暇スケジュールがサポートされるようになりました。) – 01/31/2025 Amazon Connect Forecasting, capacity planning, and scheduling に、エージェントが最大 24 か月先の休暇をスケジュールできる機能が追加されました。これにより、マネージャーとエージェントは事前に休暇を計画しやすくなり、エージェントは 休暇を最大 24 か月前 に予約できるようになります。さらに、スケジュールグループの事前に承認された休暇期間（グループ手当）を一度に最大27か月分までアップロードできるようになりました。これらの制限の引き上げにより、エージェントは個人の時間をより柔軟に計画できるようになり、マネージャーは将来の人員配置のニーズを把握できるようになり、より効率的なリソース配分の計画が可能になります。 関連リンク 管理者ガイド Amazon Connect now provides daily headcount projections in capacity plan downloads (Amazon Connect でダウンロードされるキャパシティプランに日次の人員予測が含まれるようになりました) – 01/22/2025 Amazon Connect Forecasting, capacity planning, and scheduling でキャパシティプランをダウンロードした際に日次の人員予測(日次メトリクスシート)が含まれるようになり、人員配置の要件をより高い精度で確認できるようになりました。週次と月次の予測は既に以前からキャパシティプランに含まれていましたが、今回のリリースで日単位の人員要件を最大 64 週先まで確認できるようになります。このようにきめ細かく確認できるので、季節性に配慮し、日レベルでさまざまな想定縮小率を適用しながら、雇用する人員数などの人員配置と雇用に関する重要な決定を簡単に行えるようになります。この機能は、Amazon Connect エージェントのスケジューリングが利用可能なすべての AWS リージョン で利用できます。 関連リンク 管理者ガイド Amazon Connect agent workspace now supports audio optimization for Citrix and Amazon WorkSpaces virtual desktops (Amazon Connect エージェントワークスペースが、Citrix および Amazon WorkSpaces 仮想デスクトップのオーディオ最適化をサポートするように) – 01/21/2025 Amazon Connect エージェントワークスペースは、Citrix および Amazon WorkSpaces 仮想デスクトップインフラストラクチャ (VDI) 環境からカスタマーサービスエージェントのローカルデバイスに音声をリダイレクトする機能をサポートするようになりました。音声リダイレクトにより、仮想デスクトップで処理される音声通話の音声品質が向上し、遅延が軽減され、エンドカスタマーとエージェント両方のエクスペリエンスが向上します。 関連リンク 管理者ガイド Release Notes Amazon Connect outbound campaigns can connect a call with an agent in under 2 seconds (Amazon Connect アウトバウンドキャンペーンで 2 秒以内にエージェントに電話をつなげることが可能に) – 01/18/2025 自動通話分類をサポートしながら、キャンペーンコールに出たお客様を利用可能なエージェントに 2 秒未満でつなぐように Amazon Connect アウトバウンドキャンペーン を設定できるようになりました。この機能強化は、組織が米国の電話消費者保護法 (TCPA) などのテレマーケティングの法律に関する規制コンプライアンスをサポートするのに役立ち、カスタマーエンゲージメントとエージェントの生産性も向上します。通話分類では、機械学習 (ML) を使用して通話の結果が自動的に分類されるので、エージェント入力が不要になります。そのため、エージェントの生産性が向上し、カスタマーエンゲージメントの効率が上がります。アウトバウンドコールのパフォーマンスを最適化するために、Amazon Connect の ベストプラクティス に従って接続レイテンシーを短くすることをお勧めします。Amazon Connect アウトバウンドキャンペーンは、米国東部 (バージニア北部)、米国西部 (オレゴン)、アフリカ (ケープタウン)、アジアパシフィック (シドニー)、カナダ (中部)、欧州 (フランクフルト)、欧州 (ロンドン) の AWS リージョンで利用できます。 関連リンク 管理者ガイド Amazon Connect now offers a public preview of persistent agent connections for faster call handling (Amazon Connect で通話処理を高速化する永続的なエージェント接続のパブリックプレビューの提供を開始) – 01/17/2025 Amazon Connect で、エージェントと Amazon Connect 間のオープンな通信チャネルを維持できるようになり、お客様との接続の確立にかかる時間を短縮できるようになりました。コンタクトセンターの管理者は、会話の終了後も永続的に接続を維持するようにエージェントのユーザープロファイルを設定できます。こうすると、その後の通話がつながるまでの時間が短縮されます。Amazon Connect の永続的なエージェント接続により、お客様がエージェントとつながるまでの時間が短くなるので、アウトバウンドキャンペーンの通話において米国の電話消費者保護法 (TCPA) などのテレマーケティングの法律に関するコンプライアンス要件を容易にサポートできるようになります。このプレビューは Amazon Connect を利用できるすべての AWS リージョン で対応しており、Amazon Connect サービスの利用と関連する電話料金の標準価格以上の追加料金はありません。 関連リンク 管理者ガイド Release Notes Amazon Connect Screen Recording now available in AWS GovCloud (US-West) (Amazon Connect の画面録画が AWS GovCloud (米国西部) で利用可能に) – 01/17/2025 Amazon Connect の画面録画が AWS GovCloud (米国西部) で利用できるようになり、政府および公共部門のお客様に対象が拡大されたことを発表いたします。この機能は、品質保証の目的でお客様とやり取り中にエージェント画面を録画できるようにするもので、以前は Amazon Connect が稼働するすべての商用 AWS リージョンで利用できました。今回の発表により、AWS GovCloud (米国) のお客様にもこの同じ強力な機能が提供されるようになります。 Amazon Connect の画面録画は、コンタクトセンターが品質保証プロセスの強化を目指すのに有用なツールです。スーパーバイザーや品質保証チームは、お客様とやり取り中のエージェントデスクトップのアクティビティをキャプチャして、エージェントのパフォーマンス、手順の遵守、改善の機会について洞察を深めることができます。この機能は、組織が高水準なカスタマーサービスを維持し、規制を確実に遵守し、エージェントのトレーニングや開発に関連する分野を特定するのに役立ちます。 関連リンク 管理者ガイド Amazon Connect Contact Lens launches new real-time dashboard (Amazon Connect Contact Lens が新しいリアルタイムダッシュボードをリリース) – 01/16/2025 Amazon Connect Contact Lens に新しいダッシュボードが追加され、1 つのインターフェイスから数回クリックするだけで、エージェントのアクティビティをリアルタイムで監視し、お問い合わせのリッスン、お問い合わせへの割り込み (引き継ぎ)、エージェントの状態の変更などのアクションをすぐに実行できるようになりました。このダッシュボードを使用すると、カスタム定義の期間 (週ごとなど)、概要グラフ、時系列グラフなどを使用して、リアルタイムおよび履歴の集計パフォーマンス、傾向、インサイトを表示および比較できます。お問い合わせ処理後にエージェントがどれくらいの時間稼働していたかを追跡し、特定のステータスでの時間を色分けして表示できるようになり、すぐに対応する必要があるライブのお問い合わせをリッスンすることができるようになりました。たとえば、エージェントがエラー状態の場合は自動的に赤色で強調表示し、ステータスを利用可能に戻すために追加の支援が必要なエージェントをすばやく視覚的に示すことができます。このダッシュボードは、Amazon Connect が提供されているすべての AWS リージョン で利用できます。 関連リンク 管理者ガイド Release Notes Amazon Connect Contact Lens dashboards now provide configurable groupings and filters (Amazon Connect Contact Lens のダッシュボードに、設定可能なグループ化とフィルタが表示されるように) – 01/16/2025 Amazon Connect Contact Lens ダッシュボードでは、ウィジェットレベルのフィルタとグループを定義したり、列を並べ替えたりサイズを変更したり、新しいメトリクスを削除または追加したりできるようになりました。これらのダッシュボードを使用すると、カスタム定義の期間 (週ごとなど)、概要グラフ、時系列グラフなどを使用して、リアルタイムおよび履歴の集計パフォーマンス、傾向、インサイトを表示および比較できます。特定のウィジェットをさらにカスタマイズして、ビジネスニーズに最適なダッシュボードを作成できるようになりました。たとえば、キューに入れられたお問い合わせ、平均キュー応答時間、および放棄されたお問い合わせを組み合わせ、最も重要なキューでフィルター処理した 1 つの折れ線グラフを作成できます。これにより、お問い合わせの量の増加が待機時間と顧客放棄率の両方にどのように影響するかをすばやく確認できます。これらのダッシュボードは、Amazon Connect が提供されているすべての AWS リージョン で利用できます。 関連リンク 管理者ガイド Release Notes Amazon Connect Contact Lens launches agent performance evaluations for email contacts (Amazon Connect Contact Lens がメールでの問い合わせに関するエージェントのパフォーマンス評価を提供開始) – 01/10/2025 Amazon Connect でのメールに対するエージェントのパフォーマンスを評価できるようになりました。これにより、マネージャーは、単一の使いやすいウェブインターフェイスで複数のコンタクトチャネル (音声、チャット、メール、タスク) 全体でのエージェントのパフォーマンスを評価し、エージェントの経時的なコンタクトセンター全体で集約されたインサイトを得ることができます。今回のリリースにより、マネージャーはメールスレッドとメールでのやり取りのその他の詳細 (処理時間など) を 1 つの UI で確認することで、エージェントのパフォーマンスを評価できます。コンタクトセンターでは、パブリック API を使用して、サードパーティのシステムからのデータ (CSAT、販売量、顧客維持率など) をメール問い合わせのパフォーマンス評価に組み込むこともできます。これにより、マネージャーはエージェントのパフォーマンスに関する包括的なインサイトを得ることができます。Contact Lens のパフォーマンス評価が既に利用可能なすべての AWS リージョン で利用できます。 関連リンク 管理者ガイド Release Notes Amazon Connect Contact Lens now provides free trials for conversational analytics and performance evaluations (Amazon Connect Contact Lens が会話分析とパフォーマンス評価向けに無料トライアルの提供を開始)　- 01/09/2025 Amazon Connect Contact Lens は、会話分析とパフォーマンス評価を初めて使用するユーザー向けに無料トライアルの提供を開始しました。音声向け会話分析を初めてご使用のお客様は、最初の 2 か月間にわたって、1 か月あたり 最初の 100,000 分の音声通話について、無料トライアルを利用して無料でご使用いただけます。さらに、Contact Lens のパフォーマンス評価を初めて使用するお客様には、最初のパフォーマンス評価を提出した日から 30 日間の無料トライアルが提供されます。無料トライアルにより、初めてご利用になるお客様は、追加費用をかけずに、コンタクトレンズの会話分析と評価を自分の環境で試験的に利用できます。この Contact Lens の無料トライアルは、Contact Lens をサポートしているすべての AWS リージョンで利用できるようになります。 関連リンク 管理者ガイド Release Notes 3. AWS Contact Center Blog のご紹介 Improving customer engagement with modern voice experiences （英語記事） デジタル時代における顧客サービスの革新的な進化について、クラウド技術とAIを活用した次世代の IVR (自動音声応答)システムを紹介します。 Amazon Connect などのクラウドベースのソリューションにより、従来の固定的なメニュー方式から、より自然で個別化された顧客対応が可能になり、顧客満足度の向上とビジネス効率の改善を実現しています。この記事では、クラウド技術を活用した最新のコンタクトセンターソリューションと、AI 技術を組み合わせた会話型 IVR システムの具体的なメリットや導入事例について詳しく解説しています。 Amazon Connect を提供する AWS が 2024 Gartner Magic Quadrant for Contact Center as a Service のリーダーに選出 （日本語翻訳） Gartner が発表した2024年の Contact Center as a Service（CCaaS）部門の Magic Quadrant において、AWS が2年連続でリーダーに選出されました。AWS の提供する Amazon Connect は、Capital One や Intuit など多数の大手企業に採用されており、AI を活用した革新的なクラウドコンタクトセンターソリューションとして高い評価を受けています。この記事では、Amazon Connect の Gartner Magic Quadrant での評価について解説しています。 今月のお知らせは以上です。皆さんのコンタクトセンター改革のヒントになりそうな内容はありましたでしょうか？ぜひ、実際にお試しいただき、フィードバックをお聞かせ頂けますと幸いです。 シニア Amazon Connect ソリューションアーキテクト 梅田 裕義

本記事は、2024 年 11 月 25 日に公開された “ Working with AWS AppSync Events: Serverless WebSockets for Pub/Sub ” を翻訳したものです。 AWS AppSync は、アプリケーションをイベント、データ、AI モデルに接続することを簡素化し、管理します。新しく追加された AWS AppSync Events により、開発者はサーバーレス WebSocket 経由で、それらのサブスクライブしたクライアントに対して任意のイベントソースからの更新を配信することで、リアルタイムの体験を作成できます。AWS AppSync Events は、GraphQL に縛られないスタンドアロンな Pub/Sub サービスを提供します。 この記事では、リーダーボードというシンプルで実用的なユースケースから始めます。ただし、今後の記事では、様々な認証方式、データの拡張、イベント API が役立つその他のシナリオについても紹介していきます。 アプリケーションの概要 一時リーダーボードは、その名の通り、データを永続化しないリーダーボードです。これは短時間で終了するゲームでよく使われますが、過去に何が言われたかよりも、その瞬間に何が言われたかが重要な、大量のメッセージの行き来するチャットアプリでもこのアーキテクチャは当てはまります。 このソリューションを自分で実装したい場合は、コードと導入手順を このリポジトリ からクローンできます。 以下のスクリーンショットに示されているように、このアプリケーションは 単一のページから 、ユーザーがリアルタイムですべてのプレーヤーの位置情報の更新を サブスクライブすることができる ようになっています。外部ソースからイベントが投稿されるのをシミュレートするため、「シミュレートスコアリング」ボタンが含まれており、 「シミュレートスコアリング」ボタンをクリックすると 一定の間隔で一連の更新が配信されます。 アーキテクチャがシンプルであることが重要なポイントです。認可サービス、API、データベースは必要ありません。ウェブアプリケーション内で直接イベント API を利用しているだけなのです。 フルスタックアプリケーションの作成 AWS コンソールでこれを設定する方法が最も簡単ですが、この記事では AWS CDK の L1 コンストラクタを使用して Event API を作成する方法を示します。 さらに、AWS 上でフルスタックアプリケーションを構築する際、AWS Amplify Gen 2 は TypeScript ファーストな開発環境を提供することで優れており、必要に応じて CDK L2 および L1 の構成要素に移行することができます。 AWS Amplify は Publish/Subscribe の簡素化のために使用されますが、イベント API を使うには必須ではありません。 Amplify Gen 2 でフロントエンドリポジトリを初期化するには、次のコマンドを実行してください。 npm create amplify そのコマンドは、AWS CDK と Amplify JavaScript ライブラリを自動的にインストールするだけでなく、開発者が AWS バックエンドを追加/変更できる amplify ディレクトリも生成します。 次に、 auth フォルダと data フォルダを削除しても構いません。これらは、このプロジェクトでは必要とされない Amazon Cognito と AWS AppSync GraphQL の設定を参照しています。 最後に、 amplify/backend.ts を更新して、不要なサービスの記述を削除します。 import { defineBackend } from '@aws-amplify/backend' const backend = defineBackend({}) AWS CDK を使用したイベント API の作成 AWS Amplify を使って、フルスタック CDK プロジェクトを作成しています。Amplify は複数の AWS サービスを抽象化していますが、AWS が提供するサービスの幅が広いため、CDK コンストラクタを利用してフォールバックするサービスも多数あります。これにより、開発者はこれらのコンストラクタが追加されるとすぐに、コード内で AWS サービスを使い始めることができます。 この機能を活用するため、 AWS AppSync の API を作成するために使用される L1 コンストラクトをインポートします。 はじめに、アプリケーションを構成する最小単位の要素をすべて含む個別のリソーススタックを作成します。 amplify/backend.ts ファイルに、次の行のコードを追加してください。 const customResources = backend.createStack('custom-resources-leaderboard') これは単にサービスをグループ化するために使用できる論理的なコンテナです。 本ガイドの目的に沿ったイベント API は、3 つの部分に分かれています。 API そのもの API が発行とサブスクリプションに使用できる名前空間 API を保護するために必要な認証メカニズム import { AuthorizationType, CfnApi, CfnApiKey, CfnChannelNamespace, } from 'aws-cdk-lib/aws-appsync' // previous code... // new code const cfnEventAPI = new CfnApi(customResources, 'cfnEventAPI', { name: 'realtime-leaderboard', eventConfig: { authProviders: [{ authType: AuthorizationType.API_KEY }], connectionAuthModes: [{ authType: AuthorizationType.API_KEY }], defaultPublishAuthModes: [{ authType: AuthorizationType.API_KEY }], defaultSubscribeAuthModes: [{ authType: AuthorizationType.API_KEY }], }, }) new CfnChannelNamespace(customResources, 'cfnEventAPINamespace', { name: 'default', apiId: cfnEventAPI.attrApiId, }) const cfnApiKey = new CfnApiKey(customResources, 'cfnEventAPIKey', { apiId: cfnEventAPI.attrApiId, description: 'realtime leaderboard demo', }) AWS AppSync Events は最近リリースされたため、現時点では L1 コンストラクトのみが利用可能です。より簡潔なコンストラクト (L2) は現在開発中です。L2 が利用可能になれば、この記事を更新します。 この API イベントが認証に API キーを使用していることに注目してください。これは開発目的とテストには適していますが、 ドキュメント では、AWS Identity and Access Management (IAM)、Amazon Cognito、OIDC、AWS Lambda の権限を含む認証モードの使用方法も示されています。 バックエンドリソースの作成の最後のステップは、解決された値をフロントエンドアプリケーションに渡すことです。幸いなことに、Amplify の JavaScript ライブラリは、必要な値が設定されたフォーマットで渡されている限り、イベントへの接続、公開、サブスクライブが簡単にできるようにアップデートされています。 amplify/backend.ts ファイルの最後に、次のコードを貼り付けてください。 backend.addOutput({ custom: { events: { url: `https://${cfnEventAPI.getAtt('Dns.Http').toString()}/event`, api_key: cfnApiKey.attrApiKey, aws_region: customResources.region, default_authorization_type: AuthorizationType.API_KEY, }, }, }) バックエンドをデプロイする準備ができました。これにより、プロジェクトのルートに amplify_outputs.json ファイルが作成され、フロントエンドを構成するために必要な出力が含まれます。 AWS アカウントを設定していない場合は、Amplify の こちらのガイド に従って認証情報を設定してください。 次のコマンドを実行してデプロイします。 npx ampx sandbox # npx ampx sandbox --profile your-profile-name AWS Amplify を利用したイベント API への接続、公開、サブスクライブ このプロジェクトの リポジトリ は、すでに Amplify で構成されています。これは components/configureAmplify.tsx ファイルに示されており、 app/layout.tsx ファイルで利用されています。 あとは、フロントエンドから関連するメソッドを呼び出して、バックエンドが機能することをテストするだけです。 設計上、AWS AppSync Events は Amplify ライブラリを必要としません。ネイティブの WebSocket プロトコルを使用して クライアントを構成 することが可能です。Amplify は単に、ボイラープレートを防ぐための便利なソリューションを提供するだけです。 app/page.tsx ファイルでは、バックエンドで作成した default という名前のチャネルへの接続を設定する必要があります。また、クライアントでセグメントを作成することもできます。この動作を確認するため、 useEffect 内で次のコードでアプリケーションに接続します。 const channelConnect = async () => { try { const channel = await events.connect('/default/leaderboard') channelRef.current = channel channel.subscribe({ next: handleNewData, error: (err) => console.log(err), }) } catch (e) { console.log('Error connecting to channel: ', e) } } Amplify の events.connect 関数は、 default/leaderboard チャネルへの接続を確立するために使用されます。これにより、そのチャネルからの受信データをサブスクライブできるようになります。 「Simulate Scoring」ボタンをユーザーがクリックするたびに、イベントを発行します。これは同じページから発生していますが、Lambda 関数や他のシステムやアプリケーションからも簡単に追加できます。 データの公開には events.post 関数が使用され、 app/page.tsx ファイル内の次のコードで示されているように、ランダムなプレーヤーが選択され、ランダムなスコア更新が与えられ、イベント API に投稿されます。 const handlePublish = async () => { for (let i = 0; i <= 10; i++) { const randomItem = leaderboardData[Math.floor(Math.random() * leaderboardData.length)].id const randomScore = Math.floor(Math.random() * 20) await events.post('/default/leaderboard', { id: randomItem, score: randomScore, }) await new Promise((resolve) => setTimeout(resolve, 100)) } } まとめ この記事では、AWS AppSync Events がグリーンフィールドとブラウンフィールドの両方のアプリケーションで使用できるシンプルな Pub/Sub ソリューションを提供することを説明しました。また、Amplify Gen 2 を使用して L1 コンストラクタを導入し、開発者が新しく発表された機能を IaC でよりすばやく使用できるようになることを紹介しました。 このアプリケーションはシンプルなデモンストレーションではありましたが、AWS AppSync Events は、ゲームやライブオークションなど大規模なユーザが見込まれるサービスにまで適用できることに注意が必要です。 月 250,000 件のリアルタイムイベント API 操作を無料で利用できます。AWS AppSync Events の詳細については、 ドキュメントページ をご覧ください。価格に関する詳細は、 価格ページ をご確認ください。 翻訳は Solutions Architect の 吉村 が担当しました。

本記事は、2024 年 11 月 22 日に公開された “ Building RAG-based applications with AWS Amplify AI Kit and Neon Postgres ” を翻訳したものです。 現代のアプリケーション開発は、優れた開発体験 (DX) を提供するツールだけでなく、入門から本番環境への道のりの間の適切なバランスを含むようになりました。この考え方が、 Amplify AI kit のリリースの背景にあります。大規模言語モデル (LLM) との対話やプロンプトからコンテンツを生成するなどの一般的な AI タスクを抽象化することで、開発者は市場投入までの時間を短縮し、ボイラープレートコードの作成を避けることができます。 この記事では、入門の段階を超えて、Amplify のデフォルトのデータベースモデルではなく、 Neon からサーバーレス Postgres データベースを使用して製品データを取得します。そうすることで、検索拡張生成 (RAG) を使用して LLM と対話するために必要なコードを簡素化します。 アプリケーションの概要 アプリケーションの利用者にとって魅力的なのは、既存の製品と競合するのではなく、AI を活用して既存の製品を強化するためにどのように使用されるかです。それをわかりやすく説明するシンプルで効果的な方法は、顧客が対話できるチャットボットを作成することです。実際のシナリオでは、顧客が自分で買い物をするのを妨げることはありませんではなく、自然言語を使用して購入へ導くものです。 アーキテクチャ的に言えば、ユーザーが当サイトを訪問するたびに、LLM 対応のボットとチャットできます。これらのモデルは一般的なデータで学習されていますが、製品情報も反映できることが望ましいです。製品情報はいつでも変更される可能性があるため、データベースにアクセスして最新情報を引き出すことが重要です。一般情報に加えて特定の情報にもアクセスできる機能を持つのが強力であり、 Tools (「function-calling」とも呼ぶ) によってこの機能が実現されます。 覚えておく必要がある重要な概念は、LLM がツールを使用することを選択した場合、ユーザーに代わってデータにアクセスするわけではないということです。LLM は単に、ユーザーのプロンプトに基づいて、最適なツールを伝えているだけです。その後、アプリケーションが呼び出す関数を決定します。 その関数からのレスポンスは、LLM に送り返され、エンドユーザーに対して自然な言語表現として整形されます。 想像できるように、このパターンを自分で調整するのは面倒なだけでなく、エラーにつながる可能性があります。幸いなことに、この複雑な作業は Amplify AI kit がデフォルトで行ってくれます。 具体的には、本プロジェクトでは Amazon Bedrock の Claude 3.5 Haiku を使用します。Amplify を使えば、データベースの 1 つに対応するツールを指定できます。本プロジェクトの場合、製品情報を含む Neon Postgres データベースが該当します。 Neon でサーバーレス Postgres データベースを作成 既存のデータソースに 接続できる ことは、開発者がデフォルトのデータベースである Amazon DynamoDB 以外で、Amplify の Schema 自動生成機能を使って、デフォルトのデータベースである CRUD 操作を自動的に生成できることを意味します。 Neon データベースのセットアップは簡単です。アカウントを作成すると、プロジェクトの作成を求められます。 Neon は Git のようにブランチベースのプロジェクトをサポートしています。これらは main ブランチのコピーです。私の場合、 dev/mtliendo という名前のブランチを作成するオプションがあります。これは推奨されますが、必須ではありません。いずれの場合も、ブランチの接続文字列は、次のセクションで必要になるのでコピーしておく必要があります。 デフォルトのデータベースは設定されましたが、まだテーブルは含まれていません。つまり、テーブルスキーマがまだ定義されていません。SQL を書く方法を知らない方は、がっかりするかもしれません。幸いにも、Neon の「Generate with AI」機能がこの問題を解決します。やりたいことを LLM に伝えると、レスポンスが生成されます。 SQL エディターで、次のように記述します。 Create a table schema called “Products”. Each product has a random id, an “updated at” field that is a date-time, a “created at” field that is a date-time, a “price in cents” field that is a number, a “name”, and a “description”. プロンプトを実行した後、次のレスポンスが表示されました。 CREATE TABLE Products ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), updated_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP, created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP, price_in_cents INTEGER NOT NULL, name VARCHAR(255) NOT NULL, description TEXT ); その後、コードを変更してするオプションがあり、構文が問題なければコマンドを実行できます。 設定が期待どおりに行われたことを確認するには、サイドバーの「Tables」リンクをクリックすると、スキーマを確認できるほか、 データを格納 できます。 このプロジェクトでは、データベースにいくつかのアイテムを追加しました。また、次のセクションでデータベース接続文字列をコピーしておく必要があるので、忘れずにコピーしてください。接続文字列はサイドバーの「Overview」セクションにあります。 AI Kit による Amplify Gen 2 の強化 AWS Amplify は、フロントエンドアプリケーションを AWS で動作するバックエンドに接続する最も簡単な方法です。NextJS などの JavaScript フレームワークを使用したアプリがすでに作成されている場合は、プロジェクトのルートで次のコマンドを実行して初期ファイルを生成することができます。 npm create amplify これにより、Amplify の依存関係がインストールされ、 amplify ディレクトリが作成されます。そのディレクトリのコードを変更する前に、Amplify AI kit に必要な他の依存関係をいくつかインストールします。 npm i @aws-amplify/ui-react @aws-amplify/ui-react-ai これらは、このあとすぐに利用する UI コンポーネントです。 まず、Amplify に products テーブルを含むデータベースを検査させ、バックエンドで利用できるようにします。最初のステップは、接続文字列を秘密鍵として保存することです。このシークレットは、 AWS Systems Manager の Parameter Store に保存されます。幸いなことに、Amplify にはシンプルな方法が用意されています。 ターミナルで次のコマンドを実行してください。 npx ampx sandbox secret set SQL_CONNECTION_STRING これにより、 SQL_CONNECTION_STRING という環境変数が設定され、その値の入力を求められます。そこで、Neon からコピーした接続文字列を貼り付けてください。そして、Enter キーを押してください。 この節では、ローカルマシンに AWS Amplify が既に設定済みであることを前提としています。Amplify の設定が必要な場合は、 ドキュメント の手順を参照してください。 シークレットを保存したら、Amplify にデータベースの内部を調べさせて、フロントエンドアプリケーションで利用できる CRUD 操作を作成するよう指示できます。 npx ampx generate schema-from-database --connection-uri-secret SQL_CONNECTION_STRING --out amplify/data/schema.sql.ts このコマンドを実行すると、 amplify/data フォルダに schema.sql.ts ファイルが作成されます。このファイルは Amplify によって管理されているため、修正しないでください。このコマンドを実行した後、ファイルの内容は次のスクリーンショットのようになります。 Amplify はこのファイルを使用して、Postgres データベースを a.model メソッドで機能する形式にマッピングします。 Amplify がこの機能をサポートするために裏で何をしているのかを知りたい場合は、 ドキュメントを確認してください 。 import { type ClientSchema, defineData, a } from '@aws-amplify/backend' import { schema as generatedSqlSchema } from './schema.sql' const sqlSchema = generatedSqlSchema.setAuthorization((models) => [ models.items.authorization((allow) => [allow.authenticated().to(['read'])]), ]) const schema = a.schema({ chat: a .conversation({ aiModel: a.ai.model('Claude 3.5 Haiku'), systemPrompt: 'You are a helpful assistant, that focuses on selling and upselling merchandise', tools: [ a.ai.dataTool({ name: 'MerchQuery', description: 'Search for questions regarding merchandise, shopping apparel, and item prices.', model: a.ref('items'), //! This refers to the name of our table modelOperation: 'list', }), ], }) .authorization((allow) => allow.owner()), }) const combinedSchema = a.combine([sqlSchema, schema]) export type Schema = ClientSchema<typeof combinedSchema> export const data = defineData({ schema: combinedSchema }) Neon データベースをアプリケーションに組み込んだので、 amplify/data/resource.ts ファイルにインポートし、Amplify AI kit のチャットボット/対話エンジン機能と組み合わせることができます。このファイルで何が行われているかを説明します。 4 行目: ここでは、Neon の products テーブルに対する認証ルールを割り当てています。この場合、サインインしたユーザーのみが read 操作を実行できます。 8 行目: chat という識別子を作成しています。これは、最低限 LLM の名前とそのふるまいを指示するプロンプトを受け取る 会話 ボットです。モデル名は型付けされており、インテリセンスで利用可能であることに注意が必要です。 13 行目: ツールを与えることでボットを強化しています。名前と説明は自分で定義できますが、 model は Neon データベースの名前を参照する必要があります。現在サポートされている modelOperation は list のみです。 22 行目: DynamoDB テーブルがサインインしたユーザーの会話履歴を追跡しています。 これらすべての要素を組み合わせることで、データベース内の項目を認識できる大規模言語モデルと安全に対話できる、フルマネージドなソリューションが実現します。 ソリューションをテストするために、次のコマンドを実行して AWS バックエンドをデプロイします。 npx ampx sandbox 一度デプロイすると、Amplify の設定を読み込み、クライアントサイドアプリケーションに適用して、Amplify が提供する設定、UI コンポーネント、フックを利用することができます。 import { generateClient } from 'aws-amplify/api' import { Schema } from '@/amplify/data/resource' import { useEffect } from 'react' import { Amplify } from 'aws-amplify' import awsconfig from '@/amplify_outputs.json' import { withAuthenticator } from '@aws-amplify/ui-react' import { AIConversation, createAIHooks } from '@aws-amplify/ui-react-ai' import '@aws-amplify/ui-react/styles.css' Amplify.configure(awsconfig) const client = generateClient<Schema>() const { useAIConversation } = createAIHooks(client) 一度設定すれば、チャット、会話状況の認識、ストリーミング、ロード状態、認証を備えたフロントエンド全体を、約 20 行のコードで構築できます。 function Home() { const [ { data: { messages }, isLoading, }, handleSendMessage, ] = useAIConversation('chat') return ( <div className="flex justify-center items-center m-10 max-w-screen-md"> <AIConversation avatars={{ user: { username: 'Focus Otter' } }} messages={messages} handleSendMessage={handleSendMessage} isLoading={isLoading} variant="bubble" welcomeMessage="Hello! I'm your helpful storefront assistant. Feel free to ask me questions about my merch!" /> </div> ) } export default withAuthenticator(Home) 上記のコードを、この投稿の最初のスクリーンショットと比較してみてください。Amplify AI kit の新しい AIConversation コンポーネントは、多様なプロパティを設定可能にしながら、フルチャット UI を提供します。これにより、特定のニーズに合わせてさらにカスタマイズできます。 まとめ この投稿では、検索拡張生成（RAG）を使ってLLMとの会話をサポートするフルスタックアプリケーションを構築する際の複雑さについて説明しました。そして、AWS Amplify の新しい AI kit が、定型的な部分を抽象化することによって、この経験を大幅に簡素化し、開発者がアプリケーションを真に差別化する部分に集中できるようにする方法を見てきました。これまで見てきたように、セットアップが簡単だからといって拡張性が犠牲になることはありません。Neon から Postgres データベースを作成し、我々のツールと一緒に使うことでそれを証明しました。 Amplify AI kit は、スケーラブルでセキュアなフルスタック・アプリケーションを構築するための新たな一歩です。自身のアプリケーションで Amplify AI kit を使い始めるには、 ドキュメント を参照して、今すぐ始めましょう。 翻訳は Solutions Architect の 吉村 が担当しました。

こんにちは！アマゾンウェブサービスジャパン合同会社で、製造業のお客様を支援しているソリューションアーキテクトの森です。 2025年 1月 29日にオンラインセミナー「AWS re:Invent Recap – インダストリー編 製造業編」を開催致しました。 製造業のお客様のクラウド活用はエンジニアリングチェーン、サプライチェーン、サービスチェーンなど様々な領域で進んできています。昨年から注目されている生成 AI の活用も各領域で進んでおり、re:Invent 2024 でも関連するセッションが多数公開されました。本セミナーでは、製造業でクラウドの活用をご利用・ご検討いただいているお客様を幅広く対象として、 re:Invent 2024 で発表された最新の事例及びサービスを分かりやすくご紹介しています。セミナーの開催報告として、AWS の製造業におけるフォーカス領域である、プロダクトエンジニアリング、スマート製造、スマート製品＆サービス、サプライチェーンのパートでご紹介した内容や、当日の資料・動画などを公開します。 re:Invent 2024 製造業向けサマリー アマゾンウェブサービスジャパン合同会社 シニア事業開発マネージャー　舛重 国規 [ 資料 ] AWSの製造業領域における取り組みは、プロダクトエンジニアリング、スマート製造、スマート製品＆サービス、サプライチェーンの各領域において、横断的に生成 AI・機械学習の技術を組み合わせて展開されています。 re:Invent 2024 の Keynote では Amazon CEO Andy Jassy による、Amazon での AI 活用事例、製造業各社による生成 AI 活用の事例が紹介されました。また、AWS 独自の産業データファブリック (IDF) フレームワークを中核とした、製造業向けソリューションの展開や、Expo ホールでの e-Bike スマートファクトリーのデモを通じて、製品品質向上や生産効率化への具体的なアプローチを紹介しました。組み込みソフトウェア開発においては DevOps アプローチの導入など、製造業のデジタル変革を促進する様々な取り組みが紹介されました。 プロダクトエンジニアリングに関わるサービスおよび事例アップデート アマゾンウェブサービスジャパン合同会社 シニアソリューションアーキテクト　吉廣 理 [ 資料 ] このセッションでは、プロダクトエンジニアリング関連の最新動向と事例をご紹介しました。CAD、CAE、PLM の 3つの主要ワークロードにおけるクラウド活用の利点として、リソースの柔軟な調整による無駄のない投資、並列処理による計算時間の短縮、HPC に最適化された EC2 インスタンスの提供などを例にあげています。事例として、Autodesk 社の 3D Generative AI 基盤モデル開発、Iveco グループのバーチャルエンジニアリング、サムスンエレクトロニクスの半導体工場設計、Astera Labs の半導体設計、Realta Fusion の核融合開発など、様々な業界のお客様の取り組みが紹介されていました。また、 AWS Parallel Computing Service (PCS) や Research and Engineering Studio on AWS (RES) などのサービスが紹介され、プロダクトエンジニアリングの効率化と高度化を支援する AWS の取り組みを紹介しました。 スマート製造に関わるサービスおよび事例アップデート アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト　岩根 義忠 [ 資料 ] 製造業は労働力不足、技術伝承、カーボンニュートラルの対応、品質向上など、様々な課題に直面しています。このセッションでは、特にこれらの中から、労働力不足と技術伝承の課題に注目し、 AWS IoT SiteWise を中核とした産業データファブリック (IDF) のアプローチを紹介しました。成功事例として Total Energies のバイオガスサイトを 1ヶ月で IoT SiteWise に接続して OT/IT の統合を進めた取り組み、Gousto のデータ駆動型 食品工場の取り組み、Rehrig Pacific Company の製造プロセス最適化、フォルクスワーゲンのデータプラットフォーム構築の事例を紹介しました。これらの事例から データ統合とその活用において、スモールスタートで始めて改善を重ねていく手法の有効性を強調しました。また、 AWS Outposts によるハイブリッドクラウド活用や、IoT SiteWise の新機能である生成 AI アシスタントなど、AWS サービスを活用した具体的なソリューションについてもご紹介しました。 サプライチェーンに関わるサービスおよび事例アップデート アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト　水野 貴博 [ 資料 ] このセッションでは製造業のサプライチェーンに関する最新動向と事例を紹介しました。サプライチェーン管理において、データの統合とリアルタイムな可視化、AI や機械学習の活用による予測精度の向上、そして管理全体の状況が一目で分かるコントロールタワーの構築が重要なトレンドとなっていることを紹介しました。具体的な事例として、自動車業界における企業間データ連携の Catena-X における BMW と AWS との協業の取り組み、Moderna の医薬品サプライチェーン最適化、北米トヨタのデジタルトランスフォーメーションの取り組みを紹介しました。サプライチェーンに関連する AWS Professional Service のコンサルティングメニューとして倉庫自動化最適化支援 (WAO) を、AWS サービスのアップデートとして AWS Supply Chain の機能拡張（Amazon Q 対応および QuickSight との統合）をご紹介しました。 スマート製品＆サービスに関わるサービスおよび事例アップデート アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト　村松 謙 [ 資料 ] このセッションではスマート製品サービスに関する最新トレンドと事例をご紹介しました。IoT デバイスの市場規模は急速に拡大しており、2030年までに世界で 55億台に達する見込みで、エッジ AI 市場も 2026年までに 380億ドルの規模に成長すると予測されています。re:Invent 2024 ではブリヂストン、LGエレクトロニクス、KONE、富士通など様々な企業が AWS のサービスを活用して、製品開発、運用保守、顧客サービスの向上等で成果を上げていることを紹介されました。また AWS からは、GitLab への Amazon Q Developer 機能の統合や AWS IoT SiteWise の新機能など、スマート製品&サービス分野に関連するサービスのアップデートについても紹介しました。特に AI やエッジコンピューティングの活用が、製造業のデジタルトランスフォーメーションにおいて重要な役割を果たしていることが強調されていました。 おわりに 本セミナーでは AWS re:Invent 2024 における製造業のプロダクトエンジニアリング、スマート製造、スマート製品＆サービス、サプライチェーン領域における最新の事例を紹介しました。また、お客様とデジタルトランスフォーメーションを推進する AWS の取り組みやサービスアップデートを紹介しました。データの活用や処理の高度化、自動化などによって、現在の業務をより効率的に行うことができる可能性はあります。中長期的な視点でのロードマップを検討する際、クラウドの効果的な活用が鍵となります。DX やクラウド利用に関してAWSにぜひご相談ください。お客様と共にソリューションを検討し、ご支援をさせていただきます。 本ブログは事業開発マネージャーの舛重国規、ソリューションアーキテクトの吉廣 理、岩根義忠、水野貴博、村松 謙、森 啓が執筆しました。 AWS の製造業に対する取り組みを紹介するウェブサイトもございます。 こちら も是非ご参照ください。

概要 2025 年 3 月 6 日に、AWS 上のデータベース移行に関する新たな視点をご提供する特別セミナー、「AWS で実現するデータベース マイグレーション戦略」を開催いたします。本セミナーでは、AWS Vice President の Jeff Carter が、オンプレミスの Oracle Database からの移行体験を共有し、実際に達成したビジネス価値と運用効率化についてお話しする予定です。 このブログでは、このセミナーの登壇者である Jeff Carter のこれまでのキャリアと、本セッションでご紹介する Amazon.com の移行について少しだけ触れたいと思います。 このセミナーのお申し込みは、 こちら から。 Jeff Carter Jeff Carter は、Amazon Web Services のデータベース製品およびサービスのポートフォリオを担当する Vice President です。このロールには、商用 (Oracle、SQL Server) およびオープンソース (Postgres、MySQL、MariaDB) データベースを提供するリレーショナルデータベースサービス (RDS) のほか、Graph データベースの Neptune、Redis ベースのサービスである ElastiCache と MemoryDB、DocumentDB や Timestream などの purpose-built databases も含まれます。 この役職に就く前の Jeff は、eCommerce Foundation (eCF) team チームの一員として、Amazon.com のビジネスに 5 年間携わっていました。そして Amazon.com での最初の 2 年半の間、「データウェアハウス」を担当するビッグデータテクノロジーチームを率い、コンシューマー組織のデータベースからの移行を進めました。この移行には、「世界最大級」の Oracle データウェアハウスを AWS サービスに置き換えることや、Amazon.com ウェブサイトと倉庫ネットワークを運営していたトランザクション処理システムを Oracle から AWS のテクノロジー (7,500 システム) に移行するプロジェクト「Rolling Stone」が含まれています。Jeff は、このプロジェクトを主導し、プロジェクトを成功に導いた経験を持つデータベース移行のエキスパートです。 Amazon.com の移行プロジェクト Amazon.com は創業以来、エンタープライズ規模のデータ管理に 5,000 以上のOracle Database を活用してきました。しかし、急速な成長に伴い、データベース管理の複雑さ、プロビジョニングの煩雑さ、キャパシティプランニングの困難さなど、多くの課題に直面していました。さらに、ライセンスの費用は、ビジネスの持続可能性の観点からも変革が必要な状況でした。この状況に対して、Jeff の指揮のもと、移行プロジェクトがスタートしました。 プロジェクトでは、AWS の技術コアチームを編成し、各システムに最適な AWS サービスの選定を行いました。例えば、クリティカルなサービスには Amazon DynamoDB 、安定したスキーマが必要なサービスには Amazon Aurora を採用するなど、目的に応じて最適なサービスを選択しました。また、経営層からのスポンサーシップなど技術以外のマネジメント業務もプロジェクトを円滑に進めるための重要な要素でした。 そして、2019 年、Amazon.com は 5,000 以上の Oracle Database の AWS への移行プロジェクトが無事完了しました。この移行によって様々な効果を確認することができています。 移行が完了した時の動画が こちら です。 セミナーのご案内 この度、本プロジェクトを主導した Jeff Carter を招き、特別セミナーを開催いたします。 Jeff が 実際に経験した Oracle Database 移行について、戦略から実践方法について具体的にご説明いたします。 コスト最適化、パフォーマンス向上、運用効率化を実現するデータベースモダナイゼーションなど、第一人者から直接学べる貴重な機会です。ぜひご参加ください。 日時：2025 年 3 月 6 日（木） 14:00 – 17:00 JST （受付開始 13:30) 場所：アマゾン ウェブ サービス ジャパン合同会社 〒141-0021 東京都 品川区上大崎 3-1-1 目黒セントラルスクエア 21F アジェンダ 14:00-14:50 基調講演： データベースモダナイゼーション戦略と成功事例 *逐次通訳あり (Jeff Carter, VP/Amazon Relational Databases) 14:50-15:40 Oracle Database Migration Journey & Oracle Database@AWS Introduction 15:40-16:00 休憩 16:00-16:30 移行ベストプラクティスと顧客事例 16:30-17:00 Meet AWS Expert/AWS Sales このセミナーのお申し込みは こちら スピーカー Jeff Carter は、Amazon Web Services のデータベース製品およびサービスのポートフォリオを担当する Vice President です。 矢木 覚は、AWS のシニアデータベーススペシャリストとして、データベースのクラウド化における技術的な課題解決を支援しています。 内山 義夫は、AWS のシニアデータベーススペシャリストとして、データベースのクラウド化における技術的な課題解決を支援しています。

みなさん、こんにちは。ソリューションアーキテクトの西村です。 今週も 週刊AWS をお届けします。 2025年3月6日(木) 14:00-17:00に「 AWS で実現するデータベースマイグレーション戦略 」というイベントが開催されます。先日発表されたOracle Database@AWSは、今後 Oracle の有力な移行先になる一方で、AWS には他にも様々なデータベースサービスを提供しており、AWS 上の Oracle データベース移行に関する新たな視点をご提供する特別セミナーです。そして基調講演では、AWS Vice President の Jeff Carter が、オンプレミス Oracle データベースから Amazon DynamoDB への移行した際のビジネス価値と運用効率化体験の講話も予定しており、Oracle データベースを AWS 上に移行することを検討されている方は、気づきを得られる絶好の機会と思います。ぜひご参加ください！ それでは、先週の主なアップデートについて振り返っていきましょう。 2025年2月10日週の主要なアップデート 2/10(月) Amazon Redshift Serverless announces reduction in IP Address Requirements to 3 per Subnet Amazon Redshift Serverless でサブネットごとに必要な IP アドレス数が3つに削減されました。Amazon Redshift Serverless ワークグループ(ワークグループ)を作成する際や、Redshift Processing Units(RPU) のワークグループを更新する際、サブネットに少なくとも9つの空き IP アドレスが必要でした。今回の対応により Enhanced VPC Routing(EVR) を有効にせずにAmazon Redshift Serverless を使用する場合は、Amazon VPC の各サブネットで空き IP アドレスが3つあれば良くなり、Amazon VPC サブネットネットワークの空き IP アドレスを心配する必要がなくなります。 Amazon CloudWatch now provides lock contention diagnostics for Aurora PostgreSQL Amazon CloudWatch Database Insights で、Aurora PostgreSQL 向けにロック競合を分析する機能を提供するようになりました。この機能により、Database Insights コンソールでロック状況を可視化でき、ブロッキングセッションと待機セッションの関係が表示され、ロック競合の原因となっているセッション、クエリ、オブジェクトを素早く特定できます。ロック競合診断機能は、CloudWatch Database Insights の Advanced モードでのみ利用可能です。 Amazon EFS now supports up to 10,000 access points per EFS file system Amazon Elastic File System (Amazon EFS) は、ファイルシステムごとのアクセスポイントの制限を 1,000 から 10倍の 10,000 に引き上げました。このリリースにより、共有データセットへのアクセスを管理するのがさらに簡単になり、単一の EFS ファイルシステムで数千人のユーザーへのアクセス管理をシームレスにスケーリングできるようになります。新しい EFS アクセスポイントの制限は、すべてのファイルシステムに自動的に適用されます。 2/11(火) Amazon DynamoDB now supports auto-approval of quota adjustments Amazon DynamoDB のアカウントレベルとテーブルレベルのスループットクォータの調整リクエストに対して、 AWS Service Quotas  を通して数分以内に自動承認を受けることができるようになりました。今までは、調整リクエストを行う際、Service Quotas では調整対象の Amazon DynamoDB の割り当てと目的の値を指定した上で、AWS サポートがリクエストを確認し、承認して調整を行っていました。今回のリリースによって、数クリックで、自動的に承認され、調整を行うようになり、調整が完了するまでの時間削減へつながります。 AWS Secrets and Configuration Provider now integrates with Pod Identity for Amazon EKS AWS Secrets and Configuration Provider (ASCP) が Amazon Elastic Kubernetes Service (Amazon EKS) Pod Identity と統合されました。ASCP は業界標準のKubernetes Secrets Store CSI Driver のプラグインで、Kubernetes ポッド内で実行されるアプリケーションが AWS Secrets Manager からシークレットを簡単に取得できるようにします。これまで ASCP は IAM Roles for Service Accounts (IRSA) を認証に使用していましたが、新しい任意のパラメータ「usePodIdentity」を使えば、IAM 認証に IRSA または Pod Identity を選択できます。今回統合により、ASCP と EKS Pod Identity の両コンポーネントの長所が組み合わされ、Amazon EKS 環境におけるシークレット管理が効率的かつ安全に行えるようになります。 2/12(水) Amazon Elastic Block Store (EBS) now adds full snapshot size information in Console and API Amazon Elastic Block Store (Amazon EBS) で、EBS スナップショットのフルスナップショットサイズが表示されるようになりました。EBS スナップショットはインクリメンタル方式で、ボリュームの複数のスナップショットを時間の経過とともに取得した場合、各スナップショットには新しく追加されたブロック、もしくは変更されたブロックのみが格納され、変更されていないブロックは以前のスナップショットからの参照されます。そのスナップショットに直接格納されているブロックと、以前のスナップショットから参照されているすべてのブロックを合わせた、スナップショットを構成するすべてのブロックの合計サイズが表示されます。これは、新しく変更されたブロックのサイズのみを指す、「インクリメンタルスナップショットサイズ」とは異なることにご注意ください。 AWS AppSync enhances resolver testing with comprehensive context object mocking AWS AppSync でリゾルバーおよび関数のユニットテスト中に、ID 情報、スタッシュ変数、エラー処理を含むコンテキストオブジェクトのすべてのプロパティを包括的にモックできるようになりました。開発者は、テスト環境でリゾルバースタッシュ (ctx.stash) とエラートラッキング (ctx.outErrors) にアクセスして検証することにより、効率的に関数とリゾルバーをテストでき、さらに ctx.identity に関連する呼び出し側の情報のみを含めることで、ID のモッキングが簡単になりました。これにより、リゾルバーのテスト結果の可視性が向上し、開発者がリゾルバーの実装をより効果的にトラブルシューティングして最適化できるようになります。 2/13(木) Amazon EC2 M7g instances are now available in additional regions Amazon Elastic Compute Cloud (Amazon EC2) M7g インスタンスが大阪リージョンで利用可能となりました。高いコンピューティング性能を提供する AWS Graviton3 プロセッサを搭載しており、従来のEC2インスタンスと比較して最大 60% のエネルギー消費量を削減し、最大 30Gbps のネットワーキング帯域幅と、Amazon Elastic Block Store (EBS) への最大 20Gbps の帯域幅を提供します。 Amazon RDS for PostgreSQL supports minor versions 17.3, 16.7, 15.11, 14.16, 13.19 Amazon Relational Database Service (RDS) for PostgreSQL で、最新のマイナーバージョンの 17.3、16.7、15.11、14.16、および 13.19 をサポートしました。pg_active 2.1.4、pg_cron 1.6.5、pg_partman 5.2.4などの PostgreSQL エクステンションの更新も含まれています。 AWS Network Load Balancer now supports removing availability zones ネットワークロードバランサー(NLB) でアベイラビリティーゾーン (AZ) を削除する機能がリリースされました。この機能のリリース前は、既存の NLB に AZ を追加することはできましたが、AZ を削除することはできませんでした。この機能を使用することで、ELB API、CLI、またはコンソールを使用して有効なサブネットのリストを更新することで、NLB から AZ を削除できます。AZ を削除すると、 NLB のゾーナル Elastic Network Interface(ENI) が削除され、潜在的に中断を引き起こす可能性があります。この機能を安全に使用する方法については、 ドキュメント と AWSブログ を参照してください。 2/14(金) AWS CloudTrail network activity events for VPC endpoints are now generally available AWS CloudTrail で VPC エンドポイントのネットワーク アクティビティに対するサポートが開始されました。VPC エンドポイントのネットワーク アクティビティ イベントにより、ネットワーク内のリソースにアクセスしている対象の詳細を確認できるため、データ境界内での悪意のある行為や不正なアクションを特定し対応する能力が向上します。Amazon S3、Amazon EC2、AWS Key Management Service (AWS KMS)、AWS Secrets Manager、AWS CloudTrail の 5 つの AWS サービスについて、VPC エンドポイントのネットワーク アクティビティ イベントを有効にすることが可能です。 AWS Lambda adds application performance monitoring (APM) for Java and .NET runtimes via Application Signals AWS Lambda が Java と .NET のマネージドランタイムで Amazon CloudWatch Application Signals をサポートするようになりました。Amazon CloudWatch Application Signals はアプリケーションパフォーマンスモニタリング(APM)ソリューションで、Lambda を使用して構築したサーバーレスアプリケーションの健全性とパフォーマンスを簡単に監視できます。今までは、Python と Node.js のマネージドランタイムの Lambda 関数でApplication Signals のサポートをしていましたが、今回のリリースにより、Java 11、Java 17、Java 21、および .NET 8 Lambda のマネージドランタイムを使用した Lambda 関数で Application Signals を有効にできるようになりました。 ところで、AWS の BI サービスである Amazon QuickSight に生成 AI アシスタントである Amazon Q の機能が追加され、自然言語で質問や分析ができるのはご存じでしょうか？その生成 AI の機能を簡単に試していただけるデモサイトが こちら にあります。Amaon Q in QuickSight は正式な日本語サポートはまだですが、すでにかなり日本語を解釈するようになっています。デモサイトには日本語のサンプル質問文もありますので、ぜひ試してみてください! それでは、また来週！ 著者について 西村 忠己(Tadami Nishimura) / @tdmnishi AWS Japan のソリューションアーキテクトとして、小売・消費財業種のお客様を担当しています。データガバナンスの観点から、お客様がデータ活用を効果的に行えるようなデモンストレーションなども多く行っています。好きなサービスは Amazon Aurora と Amazon DataZone です。趣味は筋トレで、自宅に徒歩０分のトレーニングルームを構築して、日々励んでいます。

2025 年 2 月 17 日更新：日本語フルサポートではないので正式にアナウンスはされていませんが、日本語でプロンプトできるようになっています。 DemoCentral も、全て日本語のサンプル質問に置き換えました！日本語の解釈において不備がある場合は、ぜひ QuickSight Community にお知らせいただけると、今後の改善リストに追加され対応されます。 Amazon QuickSight は AWS が提供するクラウドネイティブの統合型 Business Intelligence(BI) サービスです。サーバーレスのため、運用管理の負担が少ないだけでなく、ビジネスユーザーがデータから多くのインサイトを得られる機能を提供しています。Amazon QuickSight は継続的に機能強化を続けており、2024年4月には、生成 BI 機能である Amazon Q in QuickSight が一般提供が開始されました。Amazon Q in QuickSight により、ビジネスアナリストやビジネスユーザーは自然言語を使用して簡単にビジュアルを作成したり、データから洞察を得ることができます。 このたび、小売向けの生成 BI 機能を利用できるサンプルダッシュボードを DemoCentral 上の こちら で公開しました。本記事ではサンプルダッシュボードの使い方を解説します。 BI ダッシュボードにおける生成 BI 機能のニーズ AWS では、小売り業界で頻繁に使われる可視化パターンを盛り込んだ Amazon QuickSight のダッシュボードとして、以前よりDemoCentral の こちら で公開しています。経営層、商品企画者、店長、マーケターなどの活用シーンで、売上が目標に達しているかを、時系列、商品、販売チャネルといった観点で分析してインサイトを得ることができ、 こちら の記事で解説しています。 実際にダッシュボードが利用される状況を考えてみると、ダッシュボードにはない分析をしたい場合があります（ダッシュボードからの気付きにより新たな仮説や疑問が生じるので、悪いことではありません）。ダッシュボードを作成するビジネスアナリストではなく、参照がメインの経営層や店長などのビジネスユーザーにとっては、都度ビジネスアナリストにダッシュボードの作成を依頼せずにすぐに知りたいというニーズは大いにあり得ます。また、ふわっとした仮説や疑問に対してダッシュボードを作成することも現実的ではありません。 整理すると、以下のニーズとなります。 ダッシュボードにない分析をしたい ダッシュボード開発に時間をかけたくない ダッシュボード操作（フィルターなど）の教育に時間をかけたくない（または、操作を覚えるのが面倒） このような、完成度の高いダッシュボードをはじめから用意せずにスモールスタートでデータ活用を始めたい、というニーズに対して、Amazon Q in QuickSight の生成 BI を使用したマルチビジュアル質疑応答エクスペリエンスが有効です。ダッシュボードで表現されていないデータに対して自然言語で質問をすると、ビジュアルと文章による回答が返されます。 サンプルダッシュボードの概要 サンプルダッシュボード は 4つのタブから構成されており、メインとなるのが一番左の 売上分析 タブです。 図1 : 売上分析 タブ こちらは、売上全体の状況を商品カテゴリと販売チャネルの観点から分析することを狙いとして、表1 に示す 3 つのパートに分かれています。 パート 説明 関心のあるユーザー（例） 全体 達成率、上位の店舗や部門、年間遷移を把握するための可視化 経営層 部門、店舗：概要 部門→商品や、地域→店舗、についての売上を分析するための可視化 店長、商品企画者 部門、店舗：明細 部門（商品）や店舗についての明細を分析するためのピボットテーブル 同上 表1 : 売上分析 タブの構成説明 前述した以前からあるダッシュボードと比較するとシンプルな作りになっていますが、スモールスタートでデータ活用を始めているという想定です。例えば、レビューデータはあるものの、マーケターから分析のニーズが出てきていないためビジュアル化されていません（一旦どういったデータがあるかだけ レビューデータ タブに表示しています）。 Amazon Q in QuickSight によるダッシュボードにはない分析の実施 サンプルダッシュボードには、Amazon Q in QuickSight の質疑応答機能が実装されています（※1）。DemoCentral では、埋め込みのエクスペリエンスとして実装されており、ページ上部に質問バーを表示する形式と、全画面でフル表示する 2 つのオプションがあります。 質疑応答の利用については、 Qサンプル質問①② タブにて、質問していただけるサンプル質問を用意しています（※2）。ダッシュボードにある店舗と商品に対しての掘り下げや比較といった詳細分析に加えて、レビューの分析を、自然言語で問い合わせて洞察を得ることができます。 以下は、店舗同士の売上達成率を比較したい場合の問い合わせと回答です。売上達成率の全体、各店舗、月毎の遷移が右側でビジュアル化されているのと、左側でそれらを要約した文章が生成されています。 図2 : Amazon Q in QuickSight の質疑応答機能の例 – 店舗同士の売上達成率を比較 期待するビジュアルが得られない場合は、より直感的なビジュアル形式を選択することもできます。以下の例は、商品部門名別売上高を 2019 年の 1 月と 2 月で比較した問い合わせと回答です。増減を直感的に把握するため、表形式から水平棒グラフに変更しています。 図3 : Amazon Q in QuickSight の質疑応答機能の例 – 商品部門名別売上高の比較 ビジュアルの表示形式だけでなく、 推奨インサイト を確認することもできます。サンプル質問を参考に、色々と試してみてください。 （※1）機能の詳細については、 こちらのブログ にて紹介されています。 （※2）生成 BI 機能は 2025 年 2月時点でまだ日本語を正式サポートしていませんが、できるだけ正確な回答を受け取ることができるようになっています。 実際の問い合わせやフィードバックに基づくダッシュボードの充実化 Amazon Q in QuickSight の質疑応答機能を利用するには、トピックというデータセットのコレクション定義を設定する必要があります。トピックには、ユーザーが実際にした質問や、フィードバックの状況を参照することができます。回答の精度を高めるためにレビューして、設定をアップデートして精度を高めることができます。 質疑応答機能を充実化する以外にも、頻繁に問い合わせされているものについてはダッシュボードに追加することもできます。問い合わせをしなくても欲しい情報を素早く入手できるようになるので、新たな仮説や疑問が生じて、Amazon Q in QuickSight で問い合わせる、というデータ分析のサイクルができるかもしれません。 図 4 : トピックの管理者は Suggested Questions タブより多く問い合わせられている質問を確認できる 今回紹介しているサンプルダッシュボードは、スモールスタートでデータを活用を始めているという想定で以前よりあるサンプルダッシュボードと比較するとシンプルな作りであることを説明しました。例えば以下のような問い合わせから、以前よりあるサンプルダッシュボードのシート作成のきっかけとすることで、シンプルなダッシュボードをビジネスユーザーの実際のニーズに合わせて充実化することができます。 店舗同士の比較に関する問い合わせ → 自店vs類似店 シート作成へ 返品に関する問い合わせ → 返品調査 シート作成へ レビューに関する問い合わせ → 商品レビュー シート作成へ まとめ 本記事では、BI ダッシュボードにおける生成 BI 機能のニーズと、先日公開された小売向けの生成 BI 機能を利用できる Amazon QuickSight によるサンプルダッシュボードの紹介と問い合わせ例、そしてダッシュボードの充実化方法について紹介しました。 本記事では紹介しませんでしたが、Amazon Q in QuickSight は、自然言語でダッシュボードを作成やビジュアルの変更、関数などの計算フィールドの作成機能も提供しています。ビジネスユーザーだけでなく、ビジネスアナリストも含めたデータ分析をAmazon QuickSight は包括的に支援しています。 図 5 : Amazon Q in QuickSight によるデータ分析の促進イメージ 是非、サンプルダッシュボードを触れていただき、生成 BI によるデータ分析の可能性について体験してみてください！ 更新履歴 2024/12/17　新規作成 2025/2/17　DemoCentral の日本語サンプルに置き換えに合わせてアップデート — 本ブログは、ソリューションアーキテクトの平井が作成しました。

このブログは 2024 年 11 月 9 日に Ganesh Shenoy によって執筆された内容を日本語化したものです。原文は こちら を参照して下さい。 イントロダクション 水の不足は、広範囲に及ぶ影響を伴う緊急のグローバルな課題です。人口の増加、気候変動の影響、そして都市化の進行により、多くの地域で淡水資源への需要が供給を上回り続けています。効率的な水管理は、長期的な持続可能性とレジリエンスにとって極めて重要です。 水効率の重要性 水は、エネルギー生産、農業から製造業、家庭での利用に至るまで、現代社会の事実上あらゆる側面を支える重要な資源です。しかし、水の使用効率が悪いと、次のような重大な経済的および環境的コストにつながる可能性があります。 水供給の逼迫と水不足のリスク 水を大量に消費する産業の運営費の増加 水の処理と配水のためのエネルギー消費量の増加 生態系の劣化と生物多様性の損失 干ばつと気候変動の影響の深刻化 水の使用量を最適化し、効率化対策を実施することで、組織は水の使用量を削減し、コストを削減し、環境管理に貢献できます。 水を大量に使用するインダストリーにフォーカスする 特定のインダストリー、例えば発電、石油・ガス抽出、公益事業の運営などは、特に水を大量に使用します。例えば、熱電発電所は冷却システムに膨大な量の水を必要とします。2020 年の米国では、電力セクターは 47.5 兆ガロン の水を使用しました。同様に、石油・ガス産業の採掘で岩盤を破砕する手法でも、大量の水が必要です。米国で最も生産性の高い油田の 1 つである パーミアン盆地 は、この傾向を示しています。そこでのフラッキング用の水使用量は、2011 年の 1 つの井戸あたり約 120 万ガロンから 2016 年には1井戸あたり約 1,100 万ガロンに増加しました。これらのセクターで水使用効率を改善することで、大きな経済的および環境的利益を得ることができます。 水使用効率に関する AWS ガイダンスの紹介 組織の水使用効率化の取り組みを支援するため、Amazon Web Services (AWS) は、クラウドベースのテクノロジーを使用して水使用量データを収集、監視、最適化するための包括的なガイダンスを作成しました。このガイダンスは以下の詳細なフレームワークを提供します。 インダストリー活動や水道事業において、IoT デバイスやゲートウェイを使用して水使用量のテレメトリデータを収集します。 AWS IoT SiteWise または AWS IoT Core を使用してデータを取り込み、 Amazon Timestream や Amazon S3 などのホットおよびコールドデータストアに生のテレメトリデータを保存します。 AWS Lambda や AWS Glue などのサーバーレスサービスを使用してデータを処理および変換します。 可視化とレポート用に最適化されたデータストアに処理済みデータを保存します。 水の使用量と効率を監視するためのリアルタイムダッシュボードとカスタムアプリケーションを構築します。 予測や異常検出などの高度な分析を可能にし、水の消費を最適化し、潜在的な問題を特定します。 積極的な水管理のための通知とアラートを設定します。 AWS のデータ管理、分析、および機械学習 (ML) 機能の力を活用することで、水を多用するインダストリーは以下のような利点を引き出すことができます。 運用コストの削減 : 水の使用を最適化することで、企業は水の調達、処理、廃棄に関連する費用を最小限に抑え、大幅なコスト削減につながります。 環境の持続可能性の向上 : 効率的な水管理は、業界の水のフットプリントを削減し、より持続可能な未来に貢献し、水不足のリスクを軽減します。 規制遵守の改善 : 環境規制の増加に伴い、このガイダンスは企業が水管理基準を遵守し、規制当局に透明性を提供することを支援します。 データドリブン型意思決定の利用 : このガイダンスは、企業が予測や予測モデリングなどの高度な分析の力を活用し、水の使用と最適化に関する情報に基づいたデータドリブン型の決定を下せるようにします。 AWS の水使用効率ガイダンスは、発電、石油・ガス抽出、公益事業運営などの水を多用する産業が持続可能な水管理の実践を実施するためのロードマップを提供しています。 まとめ 効率的な水の使用は、長期的な持続可能性、コスト削減、環境管理にとって極めて重要です。AWS の水使用効率ガイダンスは、組織がクラウドコンピューティングとデータドリブン型の技術の力を活用して、水管理の実践を最適化するのに役立ちます。 次のリンクにアクセスして、 AWS Guidance for Water Use Efficiency をご覧ください。 参考情報 AWS Water Stewardship Commitment Sustainability at Amazon 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。 TAGS: analytics , AWS for Industrial , machine learning Ganesh Shenoy Ganesh Shenoy は、スウェーデンのストックホルムに拠点を置く AWS のソリューションアーキテクトで、中小企業をサポートしています。彼は、持続可能なクラウドの実践を推進しながら、データドリブンの意思決定を可能にするクラウドソリューションの設計を専門としています。 北欧のお客様と提携して、ビジネスの成長と環境責任を推進するソリューションを構築します。

本稿は、塩野義製薬株式会社による、従来型の解析環境の問題を根本解決する “オンデマンド計算環境” の開発について、当該の内製開発をリードされた、データサイエンス部 髙市 伸宏 様より寄稿いただきました。 1. イントロダクション 塩野義製薬は、1878年に創業して以来、“常に人々の健康を守るために、必要な最もよい薬を提供する” ことを掲げて活動を続けています。近年ではSHIONOGI Group Vision (2030年Vision) として、“新たなプラットフォームでヘルスケアの未来を創り出す” ことを目指して、革新的なヘルスケア製品・サービスをグローバルに創出し、社会課題に挑戦する試みを進めています。 その中でデータサイエンス部は、高度データ活用技術を通じたソリューション創出や業務プロセスの変革を推進する立場にあり、その目的のために、各種の計算基盤を保有し、稼働させてきました。また、その基盤環境は一定の統制のもとで全社に開放し、全社での活用をしてまいりました。 本ブログでは、その計算基盤環境を、クラウドネイティブで革新的な環境へと作り替えた取り組みをご紹介します。 2. 背景 Python言語やR言語といったオープンソース言語による統計解析や機械学習といったデータ解析は、今や多くの企業のデータサイエンス活動として見られるようになりました。その環境は、一般的には比較的大きな計算資源を持つ計算機を解析環境として設け、多くのユーザーで共用することによって、望むデータ解析の実現と、ガバナンスと、コスト効率が図られます。 しかし、この方式には以下のようなリスクがあります。 共用している計算機の障害発生により、多くのユーザーの解析が停止する ユーザー同士の操作が、同一計算機上で互いに干渉する 多数のユーザーの操作により、GPU等の計算資源の奪い合いが発生する 多様化するタスク、データモダリティに対して、柔軟に対応できない 上記の事象はすべて、発生すればするほど、本来果たすべきデータサイエンス活動の速度を、時には極端に落としてしまうことになります。よって、前述のリスクを根本のレベルから回避していくことが会社としては必要であり、課題でした。 この課題の根本にあるギャップ (理想像とのギャップ) は、要約すれば、解析環境の “スケール性”、“独立性”、“柔軟性” でした。一方でAWSクラウドには、使い方次第で、これらに対応できる各種のサービスが設けられていました。よって、従来の解析環境を単純に移行する (“リフト” する) のではなく、AWSクラウドに “シフト” することで、その利点を的確に引き出せば、根本的な解決が図れるものと捉えました。 図1 従来型環境のリスクと、解決方針 3. 開発の方針 まず設計の思想として、解析環境の共有という方針からの脱却を図りました。すなわち、解析環境はユーザー個人単位に分割して、ユーザー個人が、必要な時に、必要なだけの計算資源を持つ解析環境を、セルフサービスで (“オンデマンド” で) 得られるようにする、という方針を取りました。さらに、その解析環境は、多種多様なタスクに対応できるよう、複数種類をあらかじめ用意しておく方針を取りました。 このような方針を取ることで、計算機の共用により発生していた課題 (障害等による検討のストップ、ユーザー操作同士の干渉、計算資源の枯渇、自由度の不足) の、根本的な解決を図ることとしました。 そしてこのセルフサービスによる払い出しは、 AWS Service Catalog を核として構成することで非常にシンプルな実現が図れるため、それを採用することとしました。 AWS Service Catalogは、組織が承認したクラウドリソースやアプリケーションをあらかじめカタログ化しておき、ユーザーが安全かつ簡単に利用できるようにするサービスです。今回は、解析環境のテンプレートを Service Catalog 上に複数種類用意しておき、ユーザーが必要なときに必要なだけ払い出せるようにしました。そしてこのように、AWS Service Catalogを核として構成する一連の仕組みを、我々は独自に、“AWSオンデマンド環境” と呼称することとしました。 図2 開発方針 4. ソリューションの概要 この “AWSオンデマンド環境” では、以下の事項が実現しました。 ユーザーは、事前申請により得た権限範囲で、数種類の個人用解析環境を、自由に払い出すことができる ユーザーは、CPU性能、GPU性能、ディスク容量などの性能を、自身のタスクに応じて、自ら指定できる ユーザーは、セキュリティグループのようなインフラ知識を全く意識することなく、極めて簡単に払い出すことができる 自身が払い出した個人用解析環境は、ユーザーが自らの意思で削除することができる ユーザーの権限は、 AWS IAM Identity Center に基づく権限セット (許可セット) によって円滑な付与を実現しました。AWS Service Catalogによって払い出す個人用解析環境の定義は、あらかじめ S3 (Amazon Simple Storage Service) のバケットに配置した AWS CloudFormation テンプレートからのデプロイにより実現します。そのデプロイのアクションは、デプロイに使用するIAMロールを指定する機能である、AWS Service Catalogの起動制約 (Launch Constraints) を利用することで、ユーザーの権限を不必要に大きくすることに由来する事故を防ぎ、安心して、解析環境のデプロイ・削除が可能な仕組みを実現しています。 図3 AWS アーキテクチャ図 さらに、個人環境払い出しに使用するCloudFormationテンプレートには、バリデーションチェック付きの入力欄 (パラメタ) を設けておくことで、必ず一定の基本タグが与えられるようにしました。 一方で、払い出しの事前には値が決まらず、払い出しの瞬間にルールベースで値が決定するタグについては、まずそのルールを Amazon EventBridge ルールとして実装し、タグの付与は AWS Lambda の関数として実装しました。AWS Service Catalog由来の払い出し実行のイベントを引き金に、Amazon EventBridge ルール経由で、当該の Lambda 関数が起動するようにすることで、追加のタグが必ず付与されるようにしました。 これらの方法の組み合わせにより、払い出しの背景情報を持つ一定のタグが一貫して入るようにすることで、多数の社内ユーザーによる利用実績データを、乱れなく蓄積することも実現しました。 図4 タグ付け戦略図 5. 各種の成果 この “AWSオンデマンド環境” の実現により、従来法が抱えていた課題を根本的に解決したことに加えて、金銭的コスト、時間的コストのいずれも、従来法に比較して改善しました。特に時間的コストは、個人用解析環境を得るまでの時間がそれまでの1万分の1となり、飛躍的に向上しました。 さらに今回の仕組みは、解析環境を個人の単位に分割したものであるため、大きな試行錯誤を行ったとしても他ユーザーへの影響が原理的に発生せず、しかも個人解析環境は、従来法では到底考えられなかった、個人解析環境の破棄が可能になりました。これは、これまでは取り入れることができなかった “スクラップ＆ビルド” の考えを、データサイエンスに取り入れることを可能にしました。 図5-1 各種成果の図 図5-2 各種成果の図 また、確立したこの “AWSオンデマンド環境” からは、複数の機械学習モデルや、それを組み込んだアプリケーションが生まれ、社内デプロイまで到達するものも生まれました。 さらに当環境は、データサイエンス部だけでなく社内の他部門からの利用も受け付けており、現在では合計8部門の50名超のユーザーまで拡大して、各種の活用が見られています。 利用部門からは、“混雑に関係なく、いつでも、任意の性能の解析環境が得られる”, “個人専用の環境であり、他ユーザーへの影響が発生しないので、思い切った検討ができる”, “必要が無くなった際だけでなく、環境を壊してしまった際に、リスク無く捨てられる点が大きい。安心してチャレンジできる” といった、多数の声が得られています。 この “AWSオンデマンド環境” からは、これまでに累計500回を超える解析環境の払い出しがなされており、今もなお多数の仮説・検証サイクルの高速な実行を実現しています。 6. まとめと今後の展望 AWS Service Catalogを中心技術に、計算基盤環境を、クラウドネイティブで革新的な環境へと作り替えた取り組みを、具体的なエピソードを交えてご紹介させていただきました。 今後もこの環境は、MLOpsなどを志向した拡張機能の付与にも挑みつつ、それらの活動を通じ、AWSクラウドの力の最大限に活用して、より一層の成果の創出に取り組んでまいります。 執筆者 髙市 伸宏 塩野義製薬株式会社 DX推進本部 データサイエンス部 データエンジニアリングユニット コンピュータサイエンスグループ 2011年に大学院卒業後、塩野義製薬に入社。CMC研究本部で原薬製造法の研究開発 (プロセス化学研究) に従事。2019年よりデータマネジメント管轄部門に異動し、2021年よりデータサイエンス部に所属。主な担当業務はデータマネジメントや解析システム構築・運営にかかる企画立案と推進、新規技術導入検討など。クラウドコンピューティングを得意とする。

本記事は 2025 年 2 月 7 日に公開された “ Learning AWS best practices from Amazon Q in the Console ” を翻訳したものです。 AWS を活用するオペレーター、管理者、開発者、その他多くのユーザーは、 AWS コンソールを利用する際に、権限の不足や AWS Lambda のコードのバグなど、さまざまな課題や一般的な問題に直面します。AWSは、コンソールを利用するユーザーが直面するこれらの課題を軽減するために、 Amazon Q をリリースしました。 Amazon Q は、コードの作成、質問への回答、コンテンツの生成、問題の解決、 AWS リソースの管理、およびアクションの実行を支援する、AWS の生成 AI を活用したアシスタントです。 Amazon Q の一機能として Amazon Q Developer があります。AWS マネジメントコンソール、AWS コンソールモバイルアプリケーション、AWS のウェブサイト、AWS のドキュメントサイト、および AWS Chatbot と統合されたチャットチャネルで、Amazon Q Developer と対話しながら AWS サービスについて学べます。Amazon Q Developer に AWS タスクのベストプラクティス、推奨事項、ステップバイステップの手順、および AWS リソースやワークフローの設計について質問できます。 このブログ記事では、Amazon Q Developer を活用して、コンソール上でコードスニペットを生成したり、ワークロードを設計したり、コストを分析したりする方法など、さまざまなトピックをインタラクティブに解決するためのベストプラクティスを紹介します。 前提条件 これらの例を実際に試すには、以下の前提条件が必要です。 AWS アカウントを保持していること AWS コンソールへのアクセス権限があること  Amazon Q へのアクセス権限があること 概要 以下は、コンソールでの Amazon Q Developer の活用方法の例です: 特定の AWS サービスについて学び、それらのサービスを効果的に活用するためのベストプラクティスを探る AWS Software Development Kit (SDK) または AWS Command Line Interface (CLI) を使用してタスクを自動化するコードスニペットやスクリプトを生成する ワークロードを設計し、最適化する コストを理解する 注意 – コンソールの Amazon Q は、その非決定的な性質により、以下の例で示されているものとは異なる出力を生成する場合があります。 開始するには、 AWS コンソールにサインイン し、図 1 に示すように右側のパネルの Amazon Q アイコンをクリックして Amazon Q Developer サービスにアクセスします。必要に応じて認証を行います: 図 1: Amazon Q Chat にアクセスする AWS サービスとベストプラクティスを Q を使って学ぶ このセクションでは、Amazon Q を活用して AWS サービスについて学ぶ方法と、AWS のサービスを適切に利用するためのベストプラクティスの概要を紹介します。 AWS サービスを学ぶ 初学者でも経験豊富なユーザーでも、Amazon Q を使えば AWS の機能を発見し、必要なときにいつでも役立つ情報を得ることができます。 たとえば、メトリクスに基づいてコンピュートインスタンスを自動的にスケーリングする方法を学びたい場合、コンソールで Amazon Q に質問できます。 サンプルプロンプト: I need to set a autoscaling group for EC2 instances with this requirement, if CPU utilization goes above 50% for 5 minutes then it should add new instance and if CPU utilization drops below 50% for 5 minutes then it should delete 1 instance. （日本語訳: 以下の要件で EC2 インスタンスのオートスケーリンググループを設定する必要があります。 CPU 使用率が 5 分間 50% を超えた場合は新しいインスタンスを追加する。 CPU 使用率が 5 分間 50% を下回った場合は1つのインスタンスを削除する。） 図 2: 特定のメトリクスとしきい値に基づくコンピュートインスタンスの自動スケーリングに関する、ユーザーのプロンプトと Amazon Q からの応答 Amazon Q は、プロンプトで提供された要件に基き、 Auto Scaling グループ を設定するためのすべてのステップを提示します。 AWS サービスについて具体的な質問をする コンソールの Amazon Q は、ベストプラクティスを考慮しながら、ビジネス価値を提供するシステムを運用する際にも役立ちます。自然言語のプロンプトを使用して、 AWS サービスを使うときのベストプラクティスを学べます。 サンプルプロンプト: I am using API Gateway for REST APIs. I have configured timeout for requests. I would like to learn additional best practices to reduce and handle long running requests. （日本語訳: REST API に API Gateway を使用しています。リクエストのタイムアウトを設定しましたが、長時間実行されるリクエストを減らし、適切に処理するための追加のベストプラクティスを学びたいです。） 図 3: コンピュートコストの削減に関する、ユーザーのプロンプトと Amazon Q からの応答 図 3 に示すように、 Amazon Q は Amazon API Gateway での長時間実行リクエストを最適化するさまざまな方法を要約します。例えば、タイムアウトの実装、可能であれば長時間実行の操作を非同期呼び出しにすることや、その他いくつかの最適化の方法を提示します。 AWS SDK または AWS CLI を使用してタスクを自動化するコードスニペットやスクリプトの生成に Q を活用する 開発者やシステム管理者は、ドキュメントを調べる時間をかける代わりに、Q を使用してタスクを自動化するコードスニペットやスクリプトを生成できます。 S3 からデータを読み取る AWS Lambda 関数の作成方法 例えば、開発者が Amazon S3 バケットからデータを読み取る AWS Lambda 関数を作成したいが、どのように始めればよいかわからない場合、 Amazon Q が支援します。 図 4: Lambda 関数の作成手順に関するユーザーのプロンプトと Amazon Q の応答 図 5: Lambda 関数の作成に関するサンプルコードを含む Amazon Q の応答 図 4 および 5 に示すように、 Amazon Q は Lambda 関数の作成方法について、参考用のサンプルコードを含むステップバイステップの手順を返します。 AWS CLI を使用して S3 バケットにファイルをアップロードする方法 開発者や IT プロフェッショナルが AWS CLI を頻繁に使用しているものの、タスクを実行するための適切なコマンドを見つけるのに苦労している場合、 Amazon Q は非常に役立ちます。 サンプルプロンプト: How do I upload a file to an S3 bucket using the AWS CLI? （日本語訳: AWS CLI を使用して S3 バケットにファイルをアップロードするにはどうすればよいですか？） 図 6: S3 バケットへのファイルアップロード用の CLI コマンドに関する、ユーザーのプロンプトと Q からの応答 図 6 に示すように、 Amazon Q は S3 バケットにファイルをアップロードするための CLI コマンドを返します。さらに、アップロードされたことを確認するためのコマンドも提案しています。 他のサービスの使用を自動化するコードを記述するために Console-to-Code を活用する Console-to-Code はコンソールでの操作を記録し、生成 AI を使用して好みの言語でコードを提案します。現在、 CLI コマンド、 CDK Java 、 CDK Python 、 CDK TypeScript 、 CloudFormation JSON/YAML をサポートしています。 例えば、開発者が Amazon EC2 インスタンスと Amazon RDS データベースインスタンスを含む CloudFormation YAML を生成したい場合、開発者は Amazon EC2 と Amazon RDS のコンソールに移動し、右側で Console-to-Code アイコンを選択し、「 記録を開始 」を選択します。 以下の図に示すように、 Amazon EC2 インスタンスと Amazon RDS DB インスタンスを起動したら、記録を停止し、 CloudFormation YAML テンプレートをそのままダウンロードします。 図 7: Amazon EC2 と Amazon RDS データベースインスタンスの起動を記録する Console-to-Code 図 8: Console-to-Code の記録から Infrastructure-As-Code を生成する 図 9: Console-to-Code の記録から生成された CloudFormation YAML テンプレート ワークロードを設計し最適化するために Q を活用する このセクションでは、Amazon Q を活用して新しいワークロードを設計し、既存のワークロードを最適化することに焦点を当てます。 ワークロードの設計 ここで、開発者が以下の要件を持つ新しい金融サービスアプリケーションを構築したいと考えています: アーキテクチャはサーバーレスかつイベント駆動であること 入金や出金などの機能を提供すること 低コストで効率的な AWS サービスを使用すること 1秒あたり数千のリクエストに達する可能性があるトラフィックスパイクにスケールすること REST API をサポートすること 以下のプロンプトをコピーしてチャットウィンドウに貼り付け、 Amazon Q Developer に問い合わせてみましょう: サンプルプロンプト: How can I build a new financial services application with the following requirements: it should be serverless and event driven, must provide functionality as deposits and withdrawals, It should use low-cost efficient AWS services, It should scale with traffic spikes that can reach thousands of requests per second, and lastly it should support REST APIs. （日本語訳: 以下の要件を持つ新しい金融サービスアプリケーションを構築するにはどうすれば良いですか？サーバーレスでイベント駆動であること、入金と出金などの機能を提供すること、低コストで効率的な AWS サービスを使用すること、1秒あたり数千のリクエストに達する可能性があるトラフィックスパイクにスケールすること、そして REST API をサポートすること。） Amazon Q はこのワークロードの設計方法について回答を提供します。以下が Amazon Q から受け取ったサンプル回答です: 図 10: アーキテクチャについての Amazon Q からの応答 Amazon Q は以下のように回答しました: ご説明いただいた要件を持つ新しい金融サービスアプリケーションを構築するために、以下の AWS サービスとアーキテクチャをお勧めします: サーバーレスおよびイベント駆動アーキテクチャ: コアアプリケーションロジックには AWS Lambda を使用し、サーバーのプロビジョニングや管理なしでコードを実行できるようにします。 AWS Lambda を、REST API 用の Amazon API Gateway 、データベース用の Amazon DynamoDB 、イベント駆動メッセージング用の Amazon SNS/SQS などの他のサーバーレスサービスと統合します。 入金と出金機能: 顧客口座情報と取引詳細を保存するデータベースとして Amazon DynamoDB を使用します。 入金と出金のロジックを、 Amazon API Gateway または Amazon SNS/SQS からのイベントによってトリガーできる AWS Lambda 関数で実装します。 低コストで効率的な AWS サービス: 消費したコンピュート時間に対してのみ課金される AWS Lambda と、リクエストごとの料金モデルを提供する Amazon DynamoDB を活用します。 REST API のコストを低く抑えるために、リクエスト毎の料金モデルを提供する Amazon API Gateway を活用します。 低コストで可用性が高く、スケーラブルなメッセージング機能のために Amazon SQS と Amazon SNS の使用を検討します。 スケーラビリティとハイパフォーマンス: AWS Lambda や他のサーバーレスサービスは、1 秒あたり数千のリクエストのトラフィックスパイクを処理するために、自動的にスケールします。 Amazon API Gateway のキャッシュ機能、 Amazon DynamoDB の自動スケーリング、 Amazon SQS のメッセージバッチ処理などの機能を使用することで、さらにパフォーマンスを最適化できます。 REST API のサポート: RESTful API を公開するために、 AWS Lambda のアプリケーションロジックを Amazon API Gateway と統合します。 Amazon API Gateway は、ルーティング、認証、スロットリングを含む API 管理を処理します。 開始するには、以下の AWS ドキュメントの確認をお勧めします: サーバーレスアプリケーションのための AWS Lambda サーバーレスアプリケーションの構築のための Amazon API Gateway NoSQL データベース用の Amazon DynamoDB メッセージング用の Amazon SNS および Amazon SQS 他にご質問がありましたらお知らせください！ 出典: Key AWS services – Financial Services Industry Lens Harnessing the scale of AWS for financial simulations | AWS HPC Blog RPC と REST の違いはなんですか？ – AWS 上記のように、 Amazon Q は提供された要件に基づいてアーキテクチャの推奨サービスと、それらのサービスへのリンクも提供しました。 ワークロードの最適化 ここで、開発者や IT プロフェッショナルが AWS に Amazon EC2 を中心としたアーキテクチャを運用しており、Server-1-demo という名前のインスタンスをデプロイしているケースを想定します。そして、その環境を、コスト削減のために最適化したいと考えているとします。 前のセクションと同様に、コンソール内の Amazon Q チャットで新しいチャットウィンドウを開き、以下のプロンプトを入力します: サンプルプロンプト: Based on the current CPU utilization of my EC2 Server-1-demo, what do you recommend I do to cost optimize? （日本語訳: 現在の CPU 使用率を考慮して、EC2 Server-1-demo のコストを最適化するにはどうすればよいですか？） その結果、 Q は以下のような応答を提供します: 図 11: Amazon Q からの最適化に関する応答 図のとおり、 Amazon Q は Server-1-demo の CPU 使用率のコンテキストを考慮し、 AWS Graviton などの活用を含む推奨事項を提示しました。なお、AWS Graviton は Amazon EC2 で実行されるクラウドワークロードに最高の価格性能を提供するように設計されたインスタンスタイプです。 コストを理解するためにQ を活用する コンソールで Q を活用するもう一つの方法は、コストの分析です。開発者や IT プロフェッショナルは Amazon Q を使用して AWS Cost Explorer からコストデータを取得・分析できます。AWS のコストについて質問すると、実際の AWS アカウントのコストを反映した回答を、自然言語で受け取れます。 それでは、新しい Amazon Q のコンソールチャットウィンドウを開き、以下のプロンプトを試してみましょう: サンプルプロンプト: Show me the breakdown of EC2 costs by instance type for the last 30 days. （日本語訳: 過去 30 日間の EC2 コストをインスタンスタイプ別に表示してください。） 図 12: 過去1か月の EC2 コストの内訳に関する Amazon Q からの応答 図 12 に示されているように、Amazon Q Developer は過去 30 日間の EC2 インスタンスタイプごとの詳細な内訳を提供しました。 では、別の例を試してみましょう: サンプルプロンプト: What was my cost breakdown by service for the past three months? （日本語訳: 過去 3 か月間のサービス別コスト内訳を教えてください。） 図 13: 過去 3 か月間の支出分析に関する Amazon Q からの応答 図 13 に示すとおり、 Amazon Q は総支出に対する割合を含む詳細なコスト内訳を提供し、 AWS の使用状況とコストを簡単に理解できるようにします。この機能により、最もコストの高いサービスを素早く特定し、時間の経過に伴う支出傾向を追跡できます。最も正確な情報を得るには、定期的に AWS Cost Explorer でコストデータを確認してください。この機能の詳細については、 この機能をより詳しく説明しているブログ をご確認ください。 コンソールでの Amazon Q の活用に関するベストプラクティス 前のセクションでは、 AWS アプリケーションのアーキテクチャとアカウント管理のために Amazon Q の機能を活用する例を紹介しました。いずれの場合も、 Amazon Q に与える入力は出力の品質に直接影響します。ツールがシナリオや回答すべき内容を理解できるよう、質問は簡潔で明確で、必要な詳細情報を含んでいる必要があります。生成 AI チャットボットに効果的な入力を行うための推奨方法のことを「プロンプトエンジニアリング」といいます。以下のベストプラクティスに従うことで、 Amazon Q の使用時に、より良い結果を得ることができます: Q に実行してほしいタスクを指定する：概念の説明、サービスの比較、メリットとデメリットの列挙、 CLI コマンドの生成、コードスニペットの生成、シナリオに対するアーキテクチャオプションの提案など。 コンテキストを提供する：なぜこの概念を知る必要があるのか？どの部分のアプリケーションやアーキテクチャにその知識を適用するのか？ 図 14: より良い回答を提供するために Amazon Q が追加の詳細を求めている この例では、シナリオの形式で返すよう指定しました。また、シナリオについて知りたいサービスと、シナリオのエッジケース（インスタンス作成後）を指定しました。 Amazon Q は私たちの質問を要約し、要求に応じてシナリオと関連情報を提供しました。 一連の質問を複数の質問に分割する 一度に1つのタスクについて尋ねる 最初の回答で終わらず、その情報を使用して質問を続け、 Q がより充実した回答を提供できるようにする 図 15: Amazon Q がチャットのコンテキストを使用して回答を提供している このシナリオでは、提供された入力だけでは Q が十分な回答を生成できなかったため、追加の詳細な情報を求め、それらを回答のコンテキストとして考慮しました。 アカウントのセキュリティに関する質問には注意してください。コンソールの Amazon Q は、アカウントのセキュリティに関する回答を提供しない場合があります。 入力できる文字数は最大 1000 文字までです。これも、入力を簡潔にする必要がある理由の1つです。 新しいトピックを開始する場合は、新しい会話を作成してください。不要なコンテキストは、新しい状況に対する Q の回答の具体性を低下させます。 図 16: Amazon Q はセキュリティに関するヒントを提供しません。新しい会話を作成してください。最大文字数は 1000 文字です。 まとめ このブログ記事では、 AWS の生成 AI 搭載アシスタントである Amazon Q が、開発者、 DevOps エンジニア、アーキテクトの生産性向上とスタートアップ時間の短縮のために AWS コンソールでどのように活用されているかを様々な観点から探りました。 Amazon Q は AWS コンサルタントとして機能し、 AWS サービスの理解とベストプラクティスの実装、コードスニペットの生成や CLI コマンドの自動化など、様々なタスクについてアドバイスを提供します。特定のニーズに基づいて新しいワークロードを設計し、既存のワークロードを強化する機能について、詳細な例を用いて実証しました。また、 AI アシスタントから質の高い応答を引き出すための明確で簡潔なプロンプトの作成である、プロンプトエンジニアリングの重要性についても説明しました。コンソールでの Amazon Q の機能を活用することで、 AWS ユーザーはワークフローを効率化し、クラウドジャーニーを加速させることができます。経験豊富なクラウドアーキテクトであっても、これから始める方であっても、この AI 搭載アシスタントはパートナーとして、 AWS の領域をナビゲートし、新しいレベルの効率性を引き出すお手伝いをします。この記事で説明したベストプラクティスに従って、 Amazon Q の可能性を探求し続け、実験してください！ 翻訳はApp Dev Consultantの宇賀神が担当しました。 著者について Brendan Jenkins Brendan Jenkins は、エンタープライズの AWS のお客様に技術的なガイダンスを提供し、ビジネス目標の達成を支援する Amazon Web Services (AWS) のテックリードソリューションアーキテクトです。 DevOps および機械学習技術を専門分野としています。 Renu Yadav Renu Yadav は Amazon Web Services (AWS) のソリューションアーキテクトで、エンタープライズレベルの AWS のお客様に技術的なガイダンスを提供し、ビジネス目標の達成を支援しています。 Renu は DevOps を専門分野とする学習への強い情熱を持っています。この分野での専門知識を活かし、 AWS のお客様のクラウドインフラストラクチャの最適化とソフトウェア開発およびデプロイメントプロセスの効率化を支援しています。 Maria Mendes Maria Mendes はソリューションアーキテクトで、2022年から CSC SA チームの一員として中小企業のお客様と働いています。 Maria の日常業務は、アーキテクチャのレビュー、 AWS サービスのベストプラクティスガイダンスの提供、お客様とのワークショップの実施、複数のお客様が参加する AWS イベントでの講演活動などです。彼女は幅広い分野に精通したソリューションアーキテクトであり、また AWS 内の DevOps サービスに焦点を当てた技術フィールドコミュニティのメンバーでもあります。

2025 年も 2 月になり、落ち着きが戻ってきた今日この頃ですが、2024 年の re:Invent で行われた新しいエキサイティングなリリースや発表に追いつこうとしている人がまだ大勢います。2025 年の初めから世界中で何百もの re:Invent re:Cap イベントが開催されており、複数のオプションを提供し、関心のあるリリースを発見して詳細を掘り下げることができるようにする対面式の AWS 公式終日イベントに加えて、コミュニティイベントやバーチャルイベントも行われています。 1 月、私は幸運にも AWS EMEA re:Invent re:Cap の共同司会者を務めることができました。このイベントは、エキスパートとともにデモ、ホワイトボードセッション、ライブ Q&A をほぼ 4 時間に渡って行ったライブストリーム配信でした。見逃した場合でも大丈夫。 オンデマンドで視聴 できるようになりました! このイベントにはすばらしいチームが参加し、何千人もの人々がバーチャル体験を通して楽しく学びました。ぜひ視聴してみてください。どの re:Invent re:Cap イベントにも参加できていない同僚と共有することもお勧めします。 韓国チームも独自のバーチャル re:Invent re:Cap イベントの主催で大成功を収めました。これも オンデマンドで視聴 できます。韓国語を話すなら、このイベントをぜひご覧ください。 見るより読むほうが好きならば、すばらしいオプションがあります。 community.aws にアクセスすることで、あらゆる分野全体のリリースを取り上げたすべてのスライドが含まれる、完全な公式 re:Invent re:Cap デックをダウンロードできます。 また、このサイトではこれから開催される世界中の対面式 re:Invent re:Cap コミュニティイベント のすべてを確認でき、今からでもお近くの都市のコミュニティイベントに参加する機会を得られます。 とは言っても、皆さんご存知のとおり、新しいリリース、発表、更新は re: Invent で終わるわけではありません。さらに多くのリリース、発表、更新が毎週行われています。毎週月曜日に読み、前週の AWS ニュースハイライトを把握できる Weekly Roundup シリーズがあるのはこのためです。 では、2 月 3 日週私が注目したリリースをご紹介しましょう。 2 月 3 日週の AWS リリース AWS Step Functions を使用しているなら、これらのニュースに興味を持つかもしれません。 Distributed Map 向けの新しいデータソースと出力オプション – Distributed Map は、大規模な並列ドキュメント処理に最適です。これからは、JSON ファイルと CSV ファイルに対する既存のサポートに加えて、JSONL ファイル、およびセミコロンやタブで区切られたファイルも処理できるようになります。また、FLATTEN などの新しい出力変換を使用して、コードを追加することなく結果セットを統合することもできます。 ステートマシンとアクティビティの AWS アカウントあたりのデフォルトクォータが 100,000 に増加 – 登録済みのステートマシンとアクティビティの数に対するこれまでの AWS あたりのデフォルトクォータは 10,000 であったため、この増加によってその数が 10 倍になりました。 Amazon Q Developer にもいくつかの更新があります。 Amazon Q Developer Pro ティアサブスクリプションのための新しいシンプル化されたセットアップエクスペリエンス – スタンドアロンアカウント、または AWS Organizations メンバーアカウントの Amazon Q Developer サブスクリプションを、2 ステップセットアップを使用して Amazon Q コンソール から作成できるようになりました。 Amazon Q Developer がすべての AWS 商用リージョンでのコンソールエラーのトラブルシューティングに対応 – Amazon Q Developer は、コンソールでの Amazon Elastic Compute Cloud (Amazon EC2) 、 Amazon Elastic Container Service (Amazon ECS) 、 Amazon Simple Storage Service (Amazon S3) 、 AWS Lambda 、および AWS CloudFormation 使用時における一般的なエラーの診断に役立ちます。アイデンティティ許可の問題、誤った設定などを特定することが可能です。これまで、この機能はいくつかのリージョンに限定されていましたが、すべての AWS 商用リージョンで利用できるようになりました。 その他のさまざまな AWS サービスからのリリースで、今週私の目に留まったものもいくつかご紹介します。 AWS CloudFormation がスタックリファクタリングを導入 – CloudFormation スタックの分割、1 つのスタックから別のスタックへのリソースの移動、同じスタック内にあるリソースの論理名の変更を行えるようになりました。この機能は柔軟性を大幅に向上させ、組織やアーキテクチャ内の変更に対応し続けることを可能にします。これには、既存スタックのリソースライフサイクル管理の合理化、命名規則変更の常時把握、その他の状況などが含まれます。スタックは、 AWS コマンドラインインターフェイス (CLI) または AWS SDK を使用してリファクタリングできます。 AWS Config が 4 つの新しいリリースタイプのサポートを開始 – AWS Config は AWS 環境全体でのリソースの監視に最適で、企業ポリシー、セキュリティポリシー、およびコンプライアンス要件との整合性の確保に役立ちます。4 つの新しいリソースタイプが追加されたことで、 Amazon VPC のパブリックアクセスのブロック設定、これらの設定内で設けられた例外、および S3 Express One Zone バケットポリシーとディレクトリバケット設定を監視できるようになります。 VSS を使用した EC2 インスタンス上の Microsoft SQL Server の自動復旧 – Volume Shadow Copy Services (VSS) と呼ばれる新しい機能を使用して、Microsoft SQL Server データベースの実行中にそのデータベースを Amazon Elastic Block Store (EBS) スナップショットにバックアップできるようになりました。バックアップ後、 AWS Systems Manager Automation ランブックを使用して希望に応じた復旧時点を設定すると、ダウンタイムなしで VSS ベースの EBS スナップショットからデータベースを自動的に復元します。 その他の更新 AWS Security Token Service (AWS STS) グローバルエンドポイントに対する今後の変更 – アプリケーションのレジリエンシーとパフォーマンスの向上を支援するため、AWS では AWS STS グローバルエンドポイント (https://sts.amazonaws.com) に対する変更を行っています。お客様が対応する必要のあるアクションはありません。2025 年初頭を皮切りに、STS グローバルエンドポイントへのリクエストは AWS でデプロイされたワークロードと同じリージョン内で自動的に処理されます。例えば、アプリケーションが米国西部 (オレゴン) リージョンから sts.amazonaws.com を呼び出す場合、呼び出しは米国東部 (バージニア北部) リージョンではなく、米国西部 (オレゴン) リージョンでローカルに処理されます。これらの変更は今後数週間内にリリースされ、2025 年中盤までにデフォルトで有効になっている AWS リージョンに順次導入される予定です。 今後予定されている AWS とコミュニティのイベント AWS Public Sector Day London (2 月 27 日) – 公共部門のリーダーやイノベーターとともに、AWS が政府、教育、ヘルスケアの分野でデジタルトランスフォーメーションをどのように実現しているのかを探りましょう。 AWS Innovate GenAI + Data Edition – 生成 AI とデータイノベーションに焦点を当てた無料のオンラインカンファレンス。このカンファレンスは、APJC および EMEA (3 月 6 日)、北米 (3 月 13 日)、大中華圏 (3 月 14 日)、ラテンアメリカ (4 月 8 日) の複数の地域で開催されます。 今後開催される追加の AWS 主導の対面イベント と デベロッパー向けのバーチャルイベント をご覧ください。 おすすめの本をお探しですか? Amazon の VP 兼 CTO であるワーナー ヴォゲルス博士は、皆さんに読んでもらいたい おすすめの本のリスト を毎年の始めに公開しています。今年のリストは特にすばらしいと思います! 2 月10 日週のニュースは以上です。 AWS のお知らせの詳細なリストについては、「 AWS の最新情報 」ページをご覧ください。 次回をお楽しみに :) Matheus Guimaraes | @codingmatheus 原文は こちら です。

本記事は 2025 年 1 月 31 日に AWS Public Sector Blog で公開された Data dissemination for public sector on AWS を翻訳したものです。翻訳はソリューションアーキテクトの川戸渉が担当しました。 組織が情報に基づいた意思決定を行い、イノベーションを促進するためには、データの共有が不可欠です。 アマゾン ウェブ サービス (AWS) は、大規模なデータを安全に配信するためのさまざまなツールとサービスを提供しています。 公共の利益のためにオープンデータの公開、ビジネス目的でのプライベートデータセットの収益化、さらには社内での協業などの用途で、AWS は必要なインフラストラクチャとサポートを提供します。 AWS のクラウドサービスを活用することで、組織はチームや AWS パートナー、ユーザーとの安全なデータ共有が可能になり、価値のある洞察を得て成長につなげることができます。 AWS のデータ共有機能は、単なる要件の充足にとどまらず、今日のデータ駆動型環境における戦略的優位性の確保を実現します。 Open Data on AWS データ共有の利点が広く認識されるようになり、オープンデータの取り組みへの注目が高まっています。 AWS は、 Open Data on AWS プログラムを通じてこの動きをサポートしています。 Registry of Open Data on AWS では、幅広いデータセットが保管・公開されており、 AWS オープンデータスポンサーシッププログラム を活用することでストレージコストを抑えることもできます。 Registry of Open Data on AWS には、行政データ、科学研究、ライフサイエンス、気候、衛星画像、地理空間情報、ゲノムデータなど、さまざまなオープンデータセットが登録されています。 Open Data on AWS は、Registry of Open Data on AWS を通じてコラボレーションとイノベーションを促進しています。データプロバイダーは AWS の信頼性の高い安全なインフラストラクチャを使用してデータセットを公開でき、研究者や開発者は、データをダウンロードや保存することなく、価値あるデータに簡単にアクセスして分析やアプリケーション開発に活用できます。AWS オープンデータスポンサーシッププログラムにより、価値の高いデータセットを公開する際のストレージ費用を AWS が負担します。また、データプロバイダーと利用者の双方が、データセットに関連するノートブックや分析結果、引用文献などの情報をレジストリページで共有できます。 Open Data on AWS の利点: グローバルな影響力: Open Data on AWS では、世界中のユーザーがデータセットにアクセスでき、グローバルな協業と発展が可能になります。 成長とイノベーションの加速: AWS にデータを保存することで、各種 AWS サービスを使用した迅速なデータ処理・分析が可能になります。これにより、データから洞察を得ることができます。 コンピューティング、分析、機械学習など、 AWS の幅広いサービスを活用することで、クラウド上で効率的かつ大規模なデータ分析を実現できます。 AWS Data Exchange AWS Data Exchange は、AWS 上でサードパーティのデータを簡単に検索、購読、利用できるサービスです。 認定データプロバイダーのデータ製品カタログを提供しており、組織はサードパーティデータのライセンス取得、取り込み、管理といった一般的な課題に悩まされることなく、必要なデータに素早くアクセスできます。 AWS Data Exchange は、データ製品の発見から購読、配信までを一貫して提供する完全なエンドツーエンドサービスです。 Open Data on AWS からのデータセット を含むさまざまなデータセットのインポートが可能で、 購読 や データアクセス権限の管理 を効率的に行えます。また、データプロバイダーが AWS Marketplace でデータ製品を 公開して収益化する ためのプラットフォームも提供します。 この統合的なアプローチにより、調達から収益化までのデータ取引の全プロセスが AWS エコシステム内で効率化されます。 AWS Data Exchange を利用する最大の利点の一つが、配信の効率化です。 データプロバイダーは他のデータカタログと同様に、自社のデータ製品を容易に公開できます。プロバイダーはデータを掲載・販売でき、利用者はこれらのデータセットを自社のアプリケーションやワークフローで検索、購読、使用できます。 AWS マネジメントコンソール や API を通じて必要な製品を購読でき、個別のライセンス契約や複雑なデータ転送プロセスの管理が不要となるため、データ共有が効率化されます。 AWS Data Exchange は AWS の規模とセキュリティを活用することで、信頼性が高く一貫性のあるデータ配信を実現しています。 AWS 経由の直接配信により、高い可用性と耐久性が確保され、 AWS の包括的なセキュリティ管理とコンプライアンス認証の恩恵も受けられます。これにより、プロバイダーは知的財産を安全に保護でき、利用者は受け取ったデータの真正性と最新性を確認できます。 AWS Data Exchange はデータの売買をより円滑にします。 標準化された従量課金制の料金モデル により、利用者は必要なデータを容易に購入・使用できます。これにより、価値あるデータへのアクセスが容易になり、あらゆる規模の組織がサードパーティデータを自社のアプリケーションや分析に活用できるようになります。結果として、イノベーションの促進とビジネス価値の向上につながります。 AWS Data Exchange の利点: 豊富なデータコレクション: 世界中の 300 以上のプロバイダーによる 3,500 以上のデータセットにアクセスできる一元化されたデータリポジトリを提供します。 データ収集の効率化: データ収集プロセスを一元化し、迅速化します。 単一の API で複数のプロバイダーからのデータ取り込みを一元管理できます。 AWS サービスとのネイティブ統合: AWS の分析サービスや 機械学習モデルとシームレスに連携し、データからの迅速な洞察の抽出を可能にします。 また、AWS の認証とガバナンスもサポートしています。 Storage Browser for Amazon S3 AWS は、 Storage Browser for Amazon S3 の一般提供を 2024 年 12 月 1 日に開始しました。この機能により、開発者はカスタマイズ可能なファイルブラウザをアプリケーションに直接組み込むことができ、個人ファイルの管理や小規模な共同作業が必要なケースで特に威力を発揮します。 オープンデータポータルや研究プラットフォームと統合できるため、 Amazon Simple Storage Service (Amazon S3) バケットに保存された大規模なオープンデータセットへの簡単なアクセスが可能になります。例えば、科学系の研究機関では研究データの共有に活用でき、データセット全体をダウンロードすることなく、他の研究者が価値ある情報への閲覧やアクセスが可能になります。 これにより、オープンサイエンスとグローバルな研究協力が促進されます。 このツールを使用することで、ユーザーはアプリケーション環境を離れることなく、Amazon S3 バケット内のデータへのシームレスなアクセス、表示、操作が可能になります。 Storage Browser for Amazon S3 は一般的なファイル操作をサポートし、アプリケーションのブランディングに合わせたカスタマイズが可能なため、ビジネス用途から一般消費者向けまで幅広いアプリケーションに対応できます。 Amazon S3 データアクセスをアプリケーションに直接統合することで、ユーザー体験と生産性が大幅に向上し、Amazon S3 保存ファイルの管理のために別の管理画面を行き来する必要もなくなります。 この機能により、アプリケーションワークフロー内でのクラウドストレージの利便性が向上します。今日から、 Storage Browser for Amazon S3 をはじめてみましょう 。 Storage Browser for Amazon S3 の利点: アプリケーションとの統合: アプリケーションに直接組み込みが可能で、直感的なユーザー体験を提供します。 データ移動の削減: Amazon S3 のデータへの直接アクセスにより、大規模データセットのコピーや移動が不要になります。データセット全体のコピーやダウンロードを必要とする従来の方式と比べ、はるかに効率的です。 リアルタイムアクセス: アプリケーション内で Amazon S3 データのリアルタイムな閲覧、検索、操作が可能です。データ転送のリクエストと待機が必要な他の方法と比べ、より迅速な作業が可能です。 Build-your-own (BYO) Lens on AWS 独自ソリューションである Build-Your-Own (BYO) Lens on AWS を活用することで、組織独自の視点でデータを解析できる仕組みを構築できます。カスタマイズされた基盤を開発することで、チーム間のスムーズなデータ共有が可能になります。組織の専門知識、経験、対象分野への理解を活かすことで、より深い洞察を得ることができます。BYO Lens on AWS は組織固有のニーズ、優先事項、意思決定プロセスに合わせてカスタマイズでき、得られた洞察を迅速に実行に移せます。 BYO Lens on AWS は、データの準備、分析、可視化という３つの基本ステップで構成されています。 AWS の各種サービスを活用することで、これらの基本ステップを容易に実装できます。 Amazon QuickSight 、 AWS Glue 、 Amazon Athena 、 AWS Lambda などのサービスにより、特定のニーズに合わせたデータを加工が可能です。また、 Amazon S3 などのデータストレージ特化型サービスにより、複数のデータソースを統合できます。 AWS のサービスはスケーラブルに設計されているため、BYO Lens on AWS のワークフローで大量のデータを処理できます。 BYO Lens on AWS のワークフローは高度なセキュリティを備えており、カスタムデータ配信レンズで生成されたデータや得られた洞察の機密性、完全性、可用性を確保します。 これらの AWS サービスは、共通データワークフローの中で次のように組み合わせて使用できます。 データ取り込み: データ配信側でユーザーが情報を要求する際に連携して機能します。さまざまなカスタムデータソースを生データとして Amazon S3 に格納し、 Amazon S3 イベント通知 と Amazon EventBridge で自動的にアプリケーションに送信できます。処理用の計算アプリケーションに生データが送信されると、データ変換が開始されます。 データ配信とセキュリティ: ユーザーは Amazon Route 53 で管理されているドメインにアクセスし、 Amazon CloudFront / Amazon S3 によりコンテンツが配信されます。 カスタム BYO Lens on AWS は AWS WAF により、クロスサイトスクリプティング、SQL インジェクション、その他の一般的な攻撃から保護されます。 データ配信: コンテンツから呼び出された API リクエストは Amazon API Gateway に送られ、 Amazon Cognito が発行したトークンを使用してリクエストの認可が行われます。 認可が成功すると、AWS Lambda はこれらの API リクエストの実行と応答を管理し、データの配信、変換、取り込みのワークフローをシームレスにつなぎます。 データ変換: ETL (抽出・変換・ロード) 処理には AWS Glue を活用し、処理後のデータは Amazon S3 に格納されます。 この ETL 処理の過程で、 AWS Glue Data Catalog によってデータカタログが自動生成されます。ユーザーからのリクエストを受けた際は、 AWS Lambda を介して Amazon Athena が起動され、データカタログを参照しながら Amazon S3 上のデータに対して SQL クエリを実行します。クエリの実行結果は、 AWS Lambda、 Amazon API Gateway、 Amazon CloudFront という一連の流れを通じてユーザー側に戻されます。 BYO Lens の利点: 完全なコントロール: システムアーキテクチャ、データソース、データ変換、配信ワークフローを完全にコントロールできます。これにより、既存システムとの連携やユーザー体験のカスタマイズが可能となります。 AWS サービス選択の柔軟性: マネージドサービスに縛られることなく、要件に最適な AWS サービスを自由に選択できます。 セキュリティ/データガバナンス: 独自の基盤構築により、データガバナンス、アクセスポリシー、セキュリティ対策をきめ細かく管理できます。また、組織内の各チームに対して、アーキテクチャ内の特定サービスへのアクセス権限をより詳細なレベルで設定できます。 カスタマイズ: 組織のビジュアルアイデンティティとユーザーニーズに沿った、独自のユーザー体験、ブランディング、インターフェースを実現できます。これにより、より統一感のあるブランド体験を提供できます。さらに、 AWS 環境内の既存のデータパイプライン、分析ツール、その他のビジネスシステムとのデータ連携を円滑に行い、効率的なサービスエコシステムを構築できます。 図 1. BYO Lens on AWS におけるデータ配信の一般的なデータワークフロー。 主要なコンポーネントには Amazon Route 53、Amazon CloudFront、Amazon S3、Amazon API Gateway、AWS Lambda、Amazon Cognito、Amazon DynamoDB、Amazon Athena、AWS Glue、Amazon Elastic Kubernetes Service (Amazon EKS)、Amazon Elastic Container Service (Amazon ECS)、Amazon EventBridge が含まれています。 まとめ AWS は、Open Data on AWS、AWS Data Exchange、Storage Browser for Amazon S3、Build-your-own (BYO) Lens on AWS など、データ配信のための包括的なツールとサービスを提供しています。 これらのソリューションにより、公開データセットから商用データ製品まで、さまざまなデータ共有のニーズに対応でき、組織は大規模なデータを安全かつ効率的に配信することができます。 Open Data on AWS はオープンデータの取り組みを支援し、AWS Data Exchange はサードパーティのデータ製品の発見と利用を促進します。 Storage Browser for Amazon S3 はアプリケーションへのファイルブラウザの組み込みを可能にし、BYO Lens on AWS はカスタマイズ可能なデータ解析基盤を提供します。これらはいずれも、AWS の強固なインフラストラクチャとセキュリティ機能を活用しています。 その他の参考資料 Improving customer experience for the public sector using AWS services Storage Browser for Amazon S3 を使用して、アプリケーションを通じてユーザーをデータに接続 著者について Austin Park は、連邦文民機関を支援するアマゾン ウェブ サービス (AWS) のソリューションアーキテクトです。 ストレージを専門としており、AWS のツールを使ってシンプルなプロセスを効率化し、お客様が可能性を最大限に引き出せるようにすることに情熱を注いでいます。 Raaga N.G は、連邦文民機関を支援するアマゾン ウェブ サービス (AWS) のソリューションアーキテクトです。 アナリティクスを専門としており、複雑な問題を解決し、顧客が目標を達成できるよう支援することに情熱を注いでいます。 Rayette Toles-Abdullah は、アマゾン ウェブ サービス (AWS) の連邦文民機関を支援するプリンシパルソリューションアーキテクトです。 デジタルトランスフォーメーション、企業戦略、システムインテグレーション、クラウド運用、ガバナンス、アプリケーションモダナイゼーションを専門としています。

本記事は 2024 年 5 月 21 日に公開された “ How 20 Minutes empowers journalists and boosts audience engagement with generative AI on Amazon Bedrock ” を翻訳したものです。 この投稿は 20 Minutes の Aurélien Capdecomme と Bertrand d’Aure との共著です。 月間 1900 万人の読者を持つ 20 Minutes は、フランスの主要メディアです。このメディアは主に若く活発な都市部の読者を対象に有用で関連性が高く、アクセスしやすい情報を提供しています。毎月約 830 万人の 25 歳から 49 歳までの人々が情報を得るために 20 Minutes を選んでいます。 2002 年に設立された 20 Minutes はニュースを、印刷物、ウェブ、モバイルプラットフォームを通じて、毎月フランス国民の 3 分の 1 以上 (39%) に届けています。 20 Minutes の技術チームとして、私たちは組織のウェブおよびモバイル製品の開発と運用、そして革新的な技術イニシアチブの推進に責任を負っています。数年にわたり機械学習と人工知能 (AI) を積極的に活用し、デジタル出版のワークフローを改善し、読者に関連性がありパーソナライズされた体験を提供してきました。生成 AI の到来、特に大規模言語モデル (LLM) の登場により、私たちは現在 AI バイデザインの戦略を採用し、新しい技術製品を開発するたびに AI の適用を評価しています。 私たちの主要な目標の 1 つは、ジャーナリストに最高級のデジタル出版体験を提供することです。私たちのニュースルームのジャーナリストは、内製でカスタムしたデジタル編集体験である Storm を使ってニュース記事に取り組んでいます。 Storm は サーバーレス コンテンツ管理システム (CMS) である Nova のフロントエンドとして機能しています。これらのアプリケーションは、私たちの生成 AI の取り組みの中心となっています。 2023 年、私たちは生成 AI が肯定的な影響を及ぼす可能性のあるいくつかの課題を特定しました。これには記者向けの新しいツール、視聴者の関与を高める方法、そして広告主が私たちのコンテンツのブランドセーフティを自信を持って評価できるようにする新しい方法が含まれます。これらのユースケースを実装するために、私たちは Amazon Bedrock を利用しています。 Amazon Bedrock は、 AI21 Labs 、 Anthropic 、 Cohere 、 Meta 、 Stability AI 、 Amazon Web Services(AWS) などの有力な AI 企業から、単一の API を通じて高性能な基盤モデル (FM) を選択できるだけでなく、セキュリティ、プライバシー、責任ある AI を備えた生成 AI アプリケーションを構築するために必要な幅広い機能を提供するフルマネージドサービスです。 このブログ記事では、生成 AI を使ってデジタルパブリッシングの課題に取り組んでいるさまざまなユースケースについて概説しています。私たちは実装の技術的側面に踏み込み、基盤モデルプロバイダーとして Amazon Bedrock を選択した理由を説明します。 課題と使用事例の特定 昨今のペースの早いニュース環境では、デジタル出版社にとって課題と機会の両方が存在します。 20 Minutes では、技術チームの主要な目標の 1 つは、ジャーナリストのための新しいツールを開発することです。これらのツールは反復作業を自動化し、報道の質を向上させ、より広範な読者層に到達できるようにします。この目標に基づき私たちは生成 AI が肯定的な影響を与えることができる 3 つの課題とそれに対応するユースケースを特定しました。 最初のユースケースは、デジタル出版プロセスの一環としてジャーナリストが行う反復的な手作業を自動化して最小限に抑えることです。ニュース記事の作成の中核は、調査、執筆、編集作業に関わります。しかし記事が完成した後、記事の要約、カテゴリ、タグ、関連記事などのサポート情報とメタデータを定義する必要があります。 これらのタスクは面倒に感じられるかもしれませんが、 検索エンジン最適化 (SEO) にとって重要であり記事の読者層の拡大にもつながります。これらの反復作業の一部を自動化できれば、ニュース編集室での時間を主要な記者業務に集中させつつ、コンテンツの読者層を拡大できる可能性があります。 2 つ目の使用例は、 20 Minutes でニュース通信社の記事をどのように再発行しているかです。ほとんどのニュース機関と同様に、 20 Minutes は フランス通信社 (AFP) などの ニュース通信社 に加入し、国内外のニュースを配信するフィードを購読しています。 20 Minutes のジャーナリストは読者層に関連する記事を選び、編集方針とわれわれの読者が慣れ親しんだ独自のトーンに合わせて書き直し、編集、拡張します。これらの記事を書き直すことは、検索エンジンが重複したコンテンツを低く評価するため、 SEO にも必要不可欠です。この作業にはパターンがあるため、再発行プロセスを簡素化し、その時間を短縮するために AI ベースのツールを構築することにしました。 私たちが特定した 3 つ目の最終的な使用例は、公開したコンテンツのブランドセーフティについての透明性を高めることです。デジタル出版社である 20 Minutes は、潜在的な広告主に対してブランドセーフな環境を提供することを約束しています。コンテンツは広告やマネタイズに適しているかどうかに基づいて、ブランドセーフである、またはブランドセーフではないと分類されます。広告主やブランドによって、適切と見なされるコンテンツの種類が異なります。例えば一部の広告主は、軍事紛争などの取り扱いが難しい話題に関するニュースコンテンツの横に自社のブランドが表示されるのを望まない可能性があり、薬物やアルコールに関するコンテンツの横には表示されたくないと考える広告主もいるかもしれません。 Interactive Advertising Bureau (IAB) や Global Alliance for Responsible Media (GARM) などの組織は、コンテンツのブランドセーフティを分類するための包括的な ガイドライン や フレームワーク を策定しています。これらのガイドラインに基づき、 IAB などのデータプロバイダーは、 20minutes.fr などのウェブサイトを定期的にクロールしブランドセーフティスコアを算出することでデジタル出版社のブランドセーフティを自動評価しています。 しかしながらこのブランドセーフティースコアはサイト全体のものであり、個々のニュース記事については細かく分けられていません。大規模言語モデル (LLM) の推論能力を考慮し、業界標準のガイドラインに基づいた記事ごとの自動ブランドセーフティー評価を開発することにしました。これにより広告主に対して 20 分のコンテンツのブランド安全性をリアルタイムで細かく提供できるようになります。 私たちの技術ソリューション 20 Minutes では 2017 年から AWS を使用しており、可能な限りサーバーレスサービスの上にシステムを構築することを目指しています。 デジタルパブリッシングフロントエンドアプリケーションの Storm は、 React と Material Design を使って構築されたシングルページアプリケーションで、 Amazon Simple Storage Service (Amazon S3) と Amazon CloudFront を使ってデプロイされています。当社の CMS バックエンド Nova は、 Amazon API Gateway と複数の AWS Lambda 関数を使って実装されています。 Amazon DynamoDB は 20 Minutes の記事の主要なデータベースとして機能しています。新しい記事や既存の記事の変更は DynamoDB Streams によってキャプチャされ、 AWS Step Functions の処理ロジックを呼び出し、 Amazon OpenSearch に基づく検索サービスに送られます。 私たちは、 AWS PrivateLink を使用して Amazon Bedrock を統合しています。これにより、パブリックインターネットを経由することなく、 Amazon Virtual Private Cloud (VPC) と Amazon Bedrock の間に プライベート接続 を作成できます。 Storm で記事を作業する際、ジャーナリストは Amazon Bedrock を使って実装されたいくつかの AI ツールにアクセスできます。 Storm はタイトル、リード文、本文、画像、ソーシャルメディアの引用などのさまざまなコンテンツブロックを組み合わせて完全な記事を作成できるブロックベースのエディターです。 Amazon Bedrock を使えば、ジャーナリストは記事の要約提案ブロックを生成し、それを直接記事に配置することができます。記事全文をコンテキストとした単一のプロンプトを使って要約を生成しています。 Storm CMS はジャーナリストに記事のメタデータの提案も行います。これには適切なカテゴリ、タグ、さらにはテキスト内リンクの推奨が含まれます。他の 20Minutes コンテンツへの参照リンクは、検索エンジンが関連する内部および外部リンクを多く含むコンテンツをより高くランク付けするため、ユーザーエンゲージメントを高めるのに重要です。 これを実装するため、 Amazon Comprehend と Amazon Bedrock を組み合わせて記事のテキストから最も関連性の高い用語を抽出し、OpenSearchの内部の分類データベースに対して検索を行っています。その結果に基づいて、 Storm は他の記事やトピックにリンクすべき用語のいくつかを提案し、ユーザーはそれらを受け入れるか拒否することができます。 ニュース速報は AFP などのパートナーから受信次第、 Storm で利用可能になります。ジャーナリストはこれらの速報を閲覧し 20minutes.fr で再掲載するものを選択できます。すべての速報は掲載前にジャーナリストによって手作業で加工されます。加工のために、ジャーナリストはまず Amazon Bedrock の LLM を使って記事の書き直しを行います。この際、低い temperature のsingle-shot プロンプトを使用し、 LLM に記事の解釈を変更せず、文字数と構造をできるだけ維持するよう指示します。書き直された記事は他の記事と同様に Storm でジャーナリストが手作業で編集します。 新しいブランドセーフティー機能を実装するため、 20minutes.fr に掲載される新しい記事すべてを処理しています。現在、記事のテキストと IAB のブランドセーフティーガイドラインの両方をコンテキストに含む single-shot プロンプトを使用し、 LLM から感情評価を得ています。その後レスポンスを解析し、感情を保存し、各記事に対して広告サーバーがアクセスできるようにパブリックに公開しています。 教訓と展望 20 Minutes で生成 AI のユースケースに取り組み始めたとき、機能を繰り返し改良し、本番環境に導入できるスピードの速さに驚きました。 Amazon Bedrock の統合された API のおかげで、モデルを簡単に切り替えて実験し、各ユースケースに最適なモデルを見つけることができます。 上記のユースケースでは、全体的な高品質、特にフランス語のプロンプトを認識し、フランス語の完了を生成する能力が優れているため、 Amazon Bedrock 上の Anthropic の Claude を主要な大規模言語モデルとして使用しています。20 Minutes のコンテンツはほぼ完全にフランス語なので、この多言語対応能力は私たちにとって非常に重要です。適切なプロンプトエンジニアリングが成功の鍵であり、完了品質を最大化するために Anthropic のプロンプトエンジニアリングリソース を熱心に活用しています。 ファインチューニング や 検索拡張生成 (RAG) などのアプローチに頼らなくても、ジャーナリストに本当に価値を提供するユースケースを実装できます。当社のニュース編集室のジャーナリストから収集したデータに基づくと、当社の AI ツールは 1 記事あたり平均 8 分の時間を節約できます。毎日約 160 本のコンテンツを発行していることから、これはすでに大きな時間の節約となり、ジャーナリストはニュースを読者に報じることに集中できるようになります。 このようなユースケースの成功は、技術的な取り組みだけでなく、製品、エンジニアリング、ニュース編集室、マーケティング、法務チームとの緊密な協力にも依存しています。これらの役割から代表者が集まり、 AI 委員会を構成しています。この委員会は、20 Minutes における AI の透明性と責任ある利用を確保するための明確な方針とフレームワークを確立しています。例えば、AI の利用はすべてこの委員会で検討・承認される必要があり、AI で生成されたコンテンツはすべて人間による検証を経てから公開されます。 私たちは、デジタルパブリッシングに関しては生成 AI がまだ初期段階にあると考えていますが、今年はプラットフォームにさらに革新的なユースケースをもたらすことを期待しています。現在、 Amazon Bedrock でファインチューニングされた LLM を展開し、当社の出版物のトーンと声を正確に合わせ、ブランドの安全性分析機能を更に改善する作業を行っています。また、Bedrock モデルを利用して既存の画像ライブラリにタグ付けを行い、記事の画像に関する自動提案を行う予定です。 なぜ Amazon Bedrock か？ 複数の生成 AI モデルプロバイダを評価し、上記のユースケースを実装した経験に基づいて、 Amazon Bedrock を当社のすべての基盤モデルニーズの主要プロバイダとして選定しました。この決定に影響を与えた主な理由は次のとおりです: モデルの選択: 生成 AI の市場は急速に進化しており、AWS のアプローチは複数の主要モデルプロバイダーと協力することで、 単一の API を通じて大規模で成長し続ける基盤モデルにアクセスできることを保証しています。 推論パフォーマンス : Amazon Bedrock は低レイテンシーかつ高スループットの推論を実現します。オンデマンドと プロビジョニングされたスループット により、サービスはすべてのキャパシティのニーズを確実に満たすことができます。 プライベートモデルアクセス : AWS PrivateLink を使用して、Amazon Bedrock エンドポイントへのプライベート接続を確立し、パブリックインターネットを経由せずに推論のためのデータを送信することで、完全にデータを制御できます。 AWS サービスとの統合: Amazon Bedrock は AWS Identity and Access Management (IAM) や AWS Software Development Kit (AWS SDK) などの AWS サービスと緊密に統合されています。その結果、新しいツールや規約に適応することなく、既存のアーキテクチャに Bedrock を迅速に統合することができました。 まとめと今後の展望 このブログ記事では、 20 Minutes が Amazon Bedrock 上の生成 AI を活用して、ニュース編集室の記者をサポートし、より広範な読者層に到達し広告主にブランドの安全性を透明化する方法を説明しました。これらのユースケースでは、生成 AI を活用して記者に今日からより多くの価値を提供し、将来の有望な新しい AI ユースケースの基盤を築いています。 Amazon Bedrock の詳細を知るには、ドキュメント、ブログ記事、その他の顧客の成功事例などの Amazon Bedrock リソース を参照してください。 翻訳はソリューションアーキテクトの紙谷が担当しました。原文は こちら です。 著者について Aurélien Capdecomme は 20 Minutes の最高技術責任者であり、 IT 開発およびインフラストラクチャチームを率いています。効率的で最適化されたアーキテクチャの構築に 20 年以上の経験を持ち、サーバーレス戦略、スケーラブルなアプリケーション、 AI イニシアチブに強い焦点を当てています。彼は 20 Minutes でイノベーションとデジタル変革戦略を実施し、デジタルサービスのクラウドへの完全移行を監督しました。 Bertrand d’Aure は 20 Minutes のソフトウェア開発者です。技術者として訓練を受けた彼は、 20 Minutes のアプリケーションのバックエンドを設計・実装しており、特に記者がストーリーを作成するためのソフトウェアに重点を置いています。その他にも彼は執筆プロセスを簡素化するために、ソフトウェアに生成 AI の機能を追加する役割を担っています。 Dr. Pascal Vogel は Amazon Web Services のソリューション アーキテクトです。彼は EMEA 地域の企業顧客と協力し、サーバーレスと生成 AI に焦点を当てたクラウドネイティブソリューションを構築しています。クラウド愛好家の Pascal は、新しいテクノロジーを学び、クラウドの旅路で変革を遂げたいと考える同じ志を持つ顧客と交流することを愛しています。

本ブログは 株式会社ｉｉｍｏｎ  様と アマゾン ウェブ サービス ジャパン合同会社が共同で執筆いたしました。 みなさん、こんにちは。AWS アカウントマネージャーの尾形です。 昨今、多くの企業で SaaS (Software as a Service) を導入するケースが増加し、 SaaS 市場が拡大してきております。一方で SaaS を提供する側には、お客様に自社サービスを効果的に使っていただくために、利用するユーザーのアクティビティデータを基にした営業活動やカスタマーサポートを実現し、日々サービスの改善が求められています。 本記事では AWS 上で 自社 SaaS データ分析基盤を構築し、「提供している様々な機能を、より多くの SaaS ユーザーに活用してもらうこと」 や 「 SaaS ユーザーのデータに基づく営業活動の推進」 を実現された ｉｉｍｏｎ 様の事例をご紹介します。同社は Amazon QuickSight 、 Amazon Athena 、 Amazon Data Firehose などを利用して SaaS データ分析基盤を構築されています。 ｉｉｍｏｎ 様の状況と経緯 ｉｉｍｏｎ 様は、主に不動産仲介業務の効率化を目的としたデジタルトランスフォーメーション（DX）ツール「速いもんシリーズ」を提供しています。開発の背景として、不動産仲介の業務において広告業務や顧客対応時の作業など事務業務が全業務の約 50% 程度を占めるため、これらの作業を自動化・効率化することで、不動産仲介店舗の従業員が営業活動に集中できると考えました。 速いもんシリーズ 「速いもんを導入した不動産仲介店舗に、より多くのサービス機能を使いこなして業務を自動化・効率化していただくために、ｉｉｍｏｎ 様は「速いもんシリーズ」のサービス利用状況のアクティビティデータを営業活動に活用していました。しかし当時は、エンジニアがサービス利用状況のアクティビティデータ抽出を実施し、その後に営業が手動でデータを分析していたので、エンジニアによるアクティビティデータ抽出の工数及び営業によるデータ分析の工数が発生しました。そこでエンジニア及び営業の負担にならないアクティビティデータ分析基盤の構築は重要課題でした。 また、サービスを導入する不動産仲介店舗が増加することに伴い、店舗毎のサービス機能の利用数にばらつきが発生し、カスタマーサポートのチームが全ユーザーに対して、高い質のサポートを提供することが困難な状況でした。カスタマーサポートチームは、サービス導入後のチャーンレート (解約率) は重要な指標のため、前述の状況を改善したいと考えました。そこで、ユーザーのサービス利用状況のアクティビティデータを業務に活かせないか検討しました。 ソリューション / 構成内容 「速いもんシリーズ」は、サービスを利用するユーザーが機能を利用した頻度やクリック数などのアクティビティデータを収集しています。 データ分析基盤の構成 それらのアクティビティデータはリアルタイムでサービスから送られています。そこで Amazon Data Firehose を利用することにより、リアルタイムで送られるデータを一定期間バッファリングした後に Amazon S3 に保存しています。 Amazon S3 にデータを保存する際に工夫している点は 2 つあります。 Parquet 形式でデータ保存 Amazon Athena の検索に用いるパーティションを「日付」のみ使用 1 については、JSON 形式も検討しましたが、データ量が多くなると分析時の読み込みに時間がかかる懸念がありました。そこで、データの圧縮効率が高く、ストレージ容量の節約も実現できる Parquet 形式を採用しました。 2 については、「何をクリックしたのか」と「場所」のデータをペアで入れているため、それらもパーティションに含めることを選択肢として検討しました。しかし、取得するデータ量、流入するデータの偏り等が当初は不明だったため、後からでも変更できるようにシンプルな「日付」のみにしました。 Amazon S3 に保存されたデータは、 Amazon Athena で検索し、BI ツールの Amazon QuickSight に読み込ませています。 Amazon QuickSight は全社員が閲覧できるように設定しており、工夫している点が 2つ あります。 Amazon QuickSight の認証方式を営業 / カスタマーサポートとエンジニアで分ける Amazon QuickSight インメモリエンジンの SPICE の利用を用途にあわせて絞る 1 については、営業やカスタマーサポートが Amazon QuickSight を利用する場合、各営業向けに発行した ID・パスワードを利用して直接ログインする方式にしました。一方で、エンジニアは IAM ユーザーを用いた認証方式にしました。これは、エンジニアが日頃 IAM ユーザーを利用しているため、 Amazon QuickSight 用のユーザー認証より利便性が高いと判断したためです。 2 については、SPICE の利用により Amazon QuickSight のパフォーマンスを向上させることが可能ですが、対象期間の全てのデータを読み込む必要があったため、SPICE を活用しての差分更新が難しい状況でした。また、高頻度にデータが生成されるたびに Amazon Athena で対象期間の全てのデータをスキャンすると、コストが高くなる懸念もありました。これらの懸念を SPICE の利用が必要な Amazon QuickSight のダッシュボードを絞ることで払拭できました。 また、 Amazon QuickSight では、ユーザーの料金が従量課金であり、上限価格も決まっているため、利用するユーザーが増加した場合でもコストを抑えて利用することが可能です。そのため、全社員が Amazon QuickSight を利用できる運用にすることができました。 導入効果 データ分析基盤を導入することで、下記の 3 つの効果を得ることができました。 •これまでのデータ活用は 1 ヶ月で数回程度の頻度に留まっていたが、 導入後は毎日データを活用 するように変化 •データを活用したカスタマーサポートによって、ユーザーによる サービス機能の利用数が 2 倍に増加 •カスタマーサポートチームがユーザーの 解約リスクを発見する時間を 8 割程度削減 し、 サービス利用の継続率 99％ に貢献 上記の結果、サービスを導入する店舗が増加する中でも、効率的かつ質の高いカスタマーサポートの提供や営業活動を実現することができました。 今後、サービスを導入する不動産仲介店舗が増加し、流入するデータ量が増加しても、AWS サービスを組み合わせたデータ分析基盤で、アクティビティデータを元にした適切なサービス提供のための分析が可能であると考えています。また、全社員が Amazon QuickSight を利用可能になった結果、データ分析における新たな観点や切り口の発見にも繋がっています まとめ 今回は Amazon QuickSight 、 Amazon Athena 、 Amazon Data Firehose などを用いて、データ分析基盤を構築した事例を紹介しました。 データ分析基盤を構築し、営業やカスタマーサポートの業務に活用することで、「提供している様々な機能を、より多くの SaaS ユーザーに活用してもらうこと」や「 SaaS ユーザーのデータに基づく営業活動」を実現しました。これにより、サービス導入後のチャーンレート (解約率) の改善や営業による売上向上に繋がっております。 また、今回の株式会社ｉｉｍｏｎ 様の取り組みは AWS Japan 主催の SaaS イベント AWS SaaS Builders Forum – Tech Leaders Meetup でも発表いただきました。 SaaS のデータ分析に対してデータ分析基盤を導入することにご関心のあるお客様は、ぜひ AWS までお問い合わせください。 本ブログの執筆はアカウントマネージャー 尾形 龍太郎及びソリューションアーキテクト 文珠 啓介が担当しました。

本記事は、2023年9月25日に公開された Designing a Cloud Center of Excellence (CCOE) を翻訳したものです。 多くの企業は、クラウド・センター・オブ・エクセレンス (CCOE) がクラウドへの移行や、より広範なデジタルトランスフォーメーションを加速させることができると認識しています。これらの CCOE はさまざまな形態をとりますが、それは各企業が克服すべき独自の課題を持っているためです。それでもなお、CCOE の活用には一定のパターンやアンチパターンが存在します。このブログ記事では、CCOE の目的、その構成と運営方法、そしてそれによって期待される影響について明確にすることを目指します。 なぜ CCOE を設立するのか？ まず、 CCOE はクラウドへの移行やデジタルトランスフォーメーションを進める上で必須のものではありません。その設置は組織の判断によるものであり、多くの組織的な意思決定と同様に、さまざまな要因に依存します。特に重要なのは、企業が変革の過程で直面する課題の種類ですが、セキュリティ戦略、中央集権化と分散化、人事方針、スキル、さらには組織内の政治的要素も考慮されます。 成功したデジタルトランスフォーメーションを主導した同僚たちとの会話から、CCOE と呼ばれるグループを持たない企業もあれば、その名前のグループはあるものの、単にクラウド関連の意思決定に関与するリーダーの緩やかな集まりに過ぎないケースもあることが分かりました。 CCOE は、多くの企業が従来のデータセンター中心でウォーターフォール型の働き方から、クラウド中心で俊敏性を重視したデジタルな働き方へ移行する際に直面する共通の課題に対する部分的な解決策です。その名が示す通り、CCOE は主にクラウドへの移行に焦点を当てており、必ずしも広範な変革全体を対象とするわけではありません。CCOE が典型的に対処する課題は以下の通りです： クラウド移行は、企業内の人々が不安を感じるために停滞することがよくあります。クラウドは彼らにとって新しく、クラウドを活用する深いスキルが不足しています。また、クラウドに関する誤った情報が広く流布し、人々を不安にさせています。CCOE は、クラウドを推進し、正確な情報を提供し、移行が成功するために必要な重要なスキルを供給することで、この問題を解決します。 企業内では全員が「日常業務」を抱えており、新しい取り組みに時間を割く余裕がありません。CCOE はクラウド移行専任チームとして、その優先順位と成功指標を明確化し、移行プロセスに集中します。 クラウド移行の初期には、多くの技術的・アーキテクチャ的・ビジネス的な意思決定が必要です。特に重要なのは、セキュアなランディングゾーンを構築してセキュリティ体制を確立し、その中で企業のアプリケーションを展開できるようにすることです。CCOE はこれらの初期の意思決定を行い、企業が適切な方向へ進むよう導きます。 CCOE は、組織のクラウド移行に推進力を与え、初期段階で技術的にガイドし、リスクを軽減します。変革の過程で必要となる技術的、文化的、組織的、プロセス的な変更を促進し、移行を可能にする初期の専門知識を提供します。万能の解決策ではありませんが、その目標は、移行の速度と品質を向上させることにあります。 CCOE は一時的な組織か永続的な組織か？ CCOE の目的はクラウドへの移行を促進することであり、移行は有限のタスクであるため、CCOE は一時的なチームとして考えるのが最適です。初期段階に必要な専門知識を提供しますが、最終的には IT 組織のほぼ全員がクラウドスキルを習得する必要があります。また、CCOE はクラウドのプロセスとパターンを構築しますが、クラウドが「新しい標準」（つまり、企業の将来のあらゆることを支える技術基盤）となるため、最終的には IT 組織全体がクラウドの使用に優れるようになります。CCOE は、IT 部門がクラウド中心の組織に変革するためのイネーブラーとして機能します。 これは混乱を招きやすい概念です。多くの人々は、CCOE を企業に代わってクラウドプラットフォームを管理する永続的な部門として誤解して捉えることがあり、これは「クラウドプラットフォームエンジニアリング」と呼ばれることもあります。しかし、時間の経過とともに、「クラウドプラットフォームエンジニアリング」は単なるプラットフォームエンジニアリングとなり、組織として最適な形で IT 組織に統合されます。CCOE にセキュリティチームの代表者がいたとしても、クラウドセキュリティは最終的にセキュリティの一部となり、IT セキュリティチーム内に配置されるべきです。 危険なのは、クラウド関連のタスクのために別個のサイロを作ることです。最終的に、企業のプラットフォームのほとんどまたはすべてがクラウド上にあると想定すると、IT の管轄は単にクラウド、エッジデバイス/エンドユーザーデバイス、およびそれらに関連するアプリケーションとデータで構成されることになります。 長期的な IT 組織は、IT に最適な組織構造を採用するべきです。 CCOE はクラウドガバナンスを行うのか？ IT ガバナンスには複数の側面があり、“はい”とも“いいえ”、とも言えます。一つは、投資、優先事項、支出、プロジェクト監視に関するガバナンスです。このようなガバナンスは通常 CCOE の業務範囲外となります。多くの場合、ビジネス上の優先事項は、使用する技術プラットフォームに依存せず、クラウドガバナンスは IT ビジネスガバナンスとは分離されていません。ビジネスの優先事項はあくまでビジネスの優先事項です。 一方で、コンプライアンス、標準、およびセキュリティに関連するガバナンスもあります。CCOE の役割には、この種のクラウドガバナンスに対する初期的なアプローチを作成することが含まれます。特に興味深いのは、そののガバナンスのほとんどを自動化し、それによってクラウドを利用するすべての人々を支援する点です。 具体的には、CCOE はクラウドで機能的な能力を構築するチームに役立つアーキテクチャパターンを開発を支援します。また、CI/CD (継続的インテグレーションと継続的デリバリー) のための初期ツールチェーンを組み立てたり、モニタリングを設定したり、セキュリティコントロールやポリシー適用をクラウドに導入します。さらに、クラウドコスト管理に関する初期的な意思決定を支援します。 CCOE は「有効化によるガバナンス」を実践し、明確なガードレール（安全策）を整備することで、組織がクラウドを安心して利用できる環境を創出します。 CCOE が担当しないことは何か？ 理論的に CCOE に入れることができるが、そうすべきではない関連機能とは何でしょうか？ そして、将来的に CCOE が不要になったとき、 IT 組織の他の部分でどのような機能が継続するのでしょうか？ ほとんどの組織は、プラットフォームエンジニアリングチーム (クラウドを活用して、デリバリーチーム (DevOps チーム) がソフトウェアを作成および提供するために使用できるセルフサービスプラットフォームを提供するチーム) を必要とします。プラットフォームエンジニアリングチームは、クラウド環境におけるポリシーの実施や管理、つまり将来的には“継続的コンプライアンス”と“継続的監査”となるものを担います。CCOE は初期段階でプラットフォームエンジニアリングを行う場合もありますが、これは最終的にはより広いエンジニアリング組織の一部となります。 非常に大規模で複雑な移行プロジェクトの場合、プロジェクトマネジメントオフィス (PMO) が必要となるかもしれません。主に文化的な理由から、これを CCOE とは別組織として維持することをお勧めします。CCOE は管理者や組織者ではなく、支援者と考えるべきです。CCOE は専門知識をしますが、業務を指示して管理する役割ではありません。 デジタルトランスフォーメーション (DX) には、組織の非常に上層部での連携が必要です。ここで言葉を慎重に選んでいるのは、クラウド移行自体が継続的な上層部での連携を必要とするのではなく、より包括的な変革、すなわちビジネスをデジタル企業として再定義し、組織全体にわたる文化的変革を実現することが本質的に重要だからです。これは通常、CCOE の責任範囲ではなく、組織の上層部の継続的な関与が必要となります。むしろ、このような変革を推進するには、従来型のCoEよりも、柔軟な方向性決定のメカニズムの方が適している可能性が高いでしょう。 現代の変革には、AI を中心としたアプローチやデータ駆動型の要素が不可欠です。これらの活動にはテクノロジーが深く関与していることは明白です。AI は比較的新しい分野であるため、何らかの CoE が必要になる可能性があります。このような専門知識は組織のどこに位置づけられ、変革においてどのような役割を果たすべきでしょうか。これらの点については、今後のブログ記事でさらに詳しく解説していく予定です。 CCOE に必要なスキルは何か？ CCOE には、その目標を達成するため、あるいは CCOE 設立の契機となった課題を克服するために必要なスキルが求められます。クラウド移行の推進を妨げる主な要因が技術的なものである場合、適切な技術的役割が複数存在します。セキュリティが大きな懸念事項である場合は、セキュリティスキルを確保してください。移行を加速させる最良の手段が企業全体での技術的または事業的な啓蒙活動である場合、それらが CCOE に必要な重要なスキルとなります。コンプライアンスや報告の初期体制を確立することが重要な場合も、同様の考え方が適用されます。 おわりに CCOE は、多くの企業がクラウド移行における一般的な障害を克服するために用いるツールです。これは、最終的にはより広範なIT組織に吸収される一時的なチームとして考えるのが最適です。一時的とはどのくらいの期間でしょうか？それは移行の規模と速度によって異なります。組織構造はデジタルトランスフォーメーションの進行に伴い変化する可能性が高く、CCOE はその変化を定義し推進する役割を果たします。しかし、CCOE の目的は移行を加速することであるため、長期的なクラウド運用に必要なすべてのスキルを備えようとして、過度に複雑化したり長時間を費やしたりするのは得策ではありません。私は実用的なアプローチを提案します。移行に直面している課題は何か？これらの課題を解決するために CCOE が持つべきスキルと責任の範囲は何か？これらの課題を克服することで、移行からより迅速なビジネス成果を得るにはどうすればよいか？このように考えることで、あなたの CCOE を定義することができます。 著者について Mark Schwartz はアマゾンウェブサービスのエンタープライズストラテジストであり、『The Art of Business Value』および『A Seat at the Table: IT Leadership in the Age of Agility』の著者です。AWS 入社前は、米国国土安全保障省の一部である US Citizenship and Immigration Service の CIO、Intrax の CIO、そして Auctiva の CEO を務めていました。彼は Wharton で MBA、Yale でコンピュータサイエンスの学士号 (BS) と哲学の修士号 (MA) を取得しています。 翻訳者について 鈴木 香緒莉は、プロフェッショナルサービスのアソシエイトアドバイザリーコンサルタントで、デジタル戦略立案とそれに即した組織の変革に注力しています。 CCoE や AI CoE などの xCoE の組成支援などに従事しています。

本稿は、2025年1月17日に AWS Media & Entertainment Blog で公開された “ Configure live captions with SyncWords and AWS Elemental Media Services ” を翻訳したものです。 コンテンツクリエーター、プロデューサー、または放送者にとって、ライブストリーミング用に迅速かつ正確な文字起こし、吹き替え、または翻訳を提供することは困難な場合があります。しかし、必要な最先端のサービスを構成して、時間とお金の両方を節約する方法について説明します。 はじめに 世界中の消費者は、外国語で作成されたコンテンツを含め、これまで以上に多くのコンテンツにアクセスできます。消費者の中には、もともと難聴者向けに設計されたキャプション/字幕 (以下、キャプション) や、視力の弱い人向けの音声解説などのアクセシビリティサービスに依存している人もいます。 これ以外にも、キャプションは聴覚や視力に関係なく、さまざまな環境でも役立ちます (たとえば、音声が適さない公共の場など) 。また、より多くのコンテンツにこのようなアクセシビリティサービスを提供するよう放送局に義務付ける法律も制定されています。 キャプションや外国語の翻訳を提供するビデオオンデマンド (VOD) コンテンツには、多くのワークフローとソリューションがあります。今では、手間をかけずにライブストリーミングで同じことを行うための新しい簡単な方法もあります。Amazon Web Services (AWS) Elemental Services とライブキャプションサービス ( SyncWords ) を設定して、AI が生成する自動ライブキャプションと吹き替え (複数言語への翻訳を含む) を有効にする方法を説明します。 コンテンツ制作者、プロバイダー、放送局がライブ放送で直面する課題は、カメラキャプチャから画面表示までの時間が非常に速いため、正確でタイムリーなキャプションを生成することです。 現在、これを実現する1つの方法は、トランスクリプターに音声を聞いてもらい、話されていることをタイプして、それをメディアワークフローに反映させることです。これにはコストがかかり、人為的ミスが発生しやすく、テキストと音声の同期が困難になる可能性があります。 ライブ放送中、キャプションの表示は通常、ビデオ/オーディオよりも4〜8秒遅れます。一方、単語や文章の一部のスペルを間違えたり、完全に見落とされたりすることがあります。これらの問題により、エンドユーザーエクスペリエンスが低下します。例としては、プレゼンターがあるストーリーから別のストーリーにすばやく移動するライブニュースがあります。アクセシビリティサービス (キャプションなど) が数秒遅れると、動画が次のニュース記事に移ってから数秒後に、記事に関するテキストが表示されることがあります。 アクセシビリティサービスのユーザーに優れたエクスペリエンスを提供するには、タイミングと正確さが重要な要素です。これは、外出先や騒がしい環境でキャプションや字幕付きのライブストリーミングを視聴するモバイル視聴者に特に当てはまります。 タイミングと正確性の課題に加えて、放送局はライブキャプションを放送に挿入する際に大きなハードルに直面することがよくあります。多くの場合、ビデオ投稿段階の上流には専用のハードウェアが必要です。また、ソフトウェアベースのエンコーダーを使用して、 EIA-608 、 テレテキスト 、 digital video broadcasting (DVB) 字幕 などの特定のTVプロトコルにしたがってトランスポートストリームにユーザーデータを挿入する場合もあります。 ソリューション しかし、解決策はあります。 AWS Elemental MediaLive と AWS Elemental MediaPackage と SyncWords では、正確で同期された翻訳済みのキャプションを実現するための効率的なアプローチが提供されています。HTTP live streaming (HLS) のマニフェストの構造を活用することで、放送局は AI 機能をライブストリームにシームレスに統合できます。これにより、面倒なハードウェアが不要になり、プロセス全体が合理化されます。 AWS Elemental Link ( エンコーディングデバイス) 、AWS Elemental MediaLive、 SyncWords の AI キャプションサービス 、AWS Elemental MediaPackage を使用して、ライブキャプション用のクラウド中心のワークフローを設定する方法について説明します。 前提条件 このワークフローでは MediaLive サービスと MediaPackage サービスを使用します。AWSコンソールを使用してこれらのサービスのセットアップに精通していることを前提としています。そうでない場合は、 「AWS Elemental MediaLive の開始方法」 および 「AWS Elemental MediaPackage の開始方法」 を参照してください。 また、SyncWords のアカウントを持っていることも確認する必要があります。SyncWords に直接お問い合わせいただくか、 AWS マーケットプレイス で購入してください。 ワークフローの概要では、AWS Elemental Linkを示しています。これは、ビデオの暗号化とキーローテーションを備えた、高い弾力性と組み込みのセキュリティを備えたビデオの転送に最適な小型のハードウェアデバイスエンコーダーです。この例では、コントリビューションのソースフィードが Link に接続され、ソースストリームがエンコードされ、イーサネット接続を介して MediaLive に直接プッシュされます。Link の使用は必須ではありませんが、ソースをMediaLiveの入力として表示するためのプラグアンドプレイ機能を備えているため、使用するには最適なユニットです。 MediaLive で受け付けられるその他の入力は、MediaLive ユーザーガイドの 「セットアップ：入力の作成」 セクションにあります。 図 1: ワークフローの概要 設定 このサンプルワークフローは、MediaLive、SyncWords、および MediaPackage サービスで構成されています。 AWS マネジメントコンソール にログインし、AWS Elemental MediaPackageにアクセスして開始してください。 ステップ 1: まず MediaPackage でチャネルを作成します (ここでは v2 を使用) 。 チャネルグループを作成します。 次に、チャネルを作成します。MediaPackage v2 チャネルを作成するときは、SyncWords からのストリームアクセスを許可するカスタムチャネルポリシーを作成する必要があることに注意してください。 Publishing HLS streams from SyncWords Live to your AWS MediaPackage v2 Channel のポリシーを定義する方法について説明します。 チャネル内で、[ Create endpoint ] ボタンをクリックして HLS Origin エンドポイントを作成します。これは、SyncWords からストリームがプッシュされる先のエンドポイントです。 エンドポイントの[ Settings ]ページに、ステップ 2 で SyncWords HLS 出力を設定するために必要な MediaPackage HLS インジェストエンドポイント URL が表示されます。それを書き留めておいてください。 HLS Origin エンドポイントの[ Segment settings ] で [ Use audio rendition group ] ボックスが選択されていることを確認します。 注: MediaPackage v1 で設定する場合、カスタムチャネルポリシーを設定しないため異なります。代わりに、ステップ 2 で SyncWords HLS 出力を設定するときに、MediaPackage v1 HLS インジェストエンドポイントの URL、ユーザー名、およびパスワードを使用してください。 ステップ 2: SyncWords チャネルを設定します。 SyncWords のアカウントにログインします。 [ Services ] または [ Events ] に移動し、[ Create Service ] または [ Schedule an Event ] をクリックします。ここでは、図 2 に示すように、サービス設定を使用しています。 Service Nameを入力し、[ Create Service ] をクリックします。 図 2: SyncWords の [ Create Service ] 設定のスクリーンショット [ HLS Push」タイプとして、MediaLive が HLS をストリーミングするための入力エンドポイントを作成します。これにより、SyncWords サービスエンドポイントにアクセスするための一意の URL エンドポイント、ユーザー名、およびパスワードが自動的に生成されます。 注:ステップ 3 で MediaLive を設定するときは、URL、ユーザー名、およびパスワードの設定が必要になります。 MediaLiveからこのエンドポイントにストリーミングすると、接続ステータスが [ Not Connected ] から [ Connected ] に変わります。 図 3: SyncWords の [ Input Media ] 設定のスクリーンショット [ Transcript ] セクション (図4) で、Transcript Type を [ Automated (AI) ] に設定します。次に、ソースオーディオの認識に使用する Speech Engine とソース言語を選択します。必要に応じて、音声エンジンが問題を起こす可能性のあるカスタム用語 (名前や略語など) には、Add Dictionary を使います。 [ More Options ] で追加の設定を選択します。注:オプションは、選択した Speech Engine によって異なる場合があります。 図 4: SyncWords の [ Transcript ] 設定のスクリーンショット [ Translations ] セクション (図5) に、翻訳したい言語を追加します。これにより、エンドユーザークライアントにキャプションとして表示される出力言語が定義されます。MT Engine のドロップダウンリストから、希望する翻訳エンジンを選択します。 吹き替えオーディオトラックを作成したい言語の [ Audio ] ボックスを選択し、必要な吹き替え音声設定 (方言、性別、話者、話率) を選択します。 吹き替えトラックとミックスするオリジナル音声の音量を 0～50 の間でパーセンテージで設定します。 自動翻訳の精度を上げるには、カスタム用語集を追加し、ソース言語、ターゲット言語、カスタム用語集の各フィールドに入力します。翻訳が難しい用語や、ターゲット言語に翻訳されたバージョンがない用語には、用語集が必要になることがあります。用語集プリセットも作成できます。その方法については、 「 How to Create a Translation Glossary 」 で説明されています。 図 5: SyncWords の [ Translations ] 設定のスクリーンショット [ Outputs ] セクションで HLS 出力を作成します (図 6)。ドロップダウンから [ AWS MediaPackage ] と[ v2 ] を選択します。 MediaPackage v2 チャネルの [ Settings ] ページから HLS インジェストエンドポイント URL をコピーします (ステップ 1 を参照) 。 バッファサイズを設定します。注:翻訳を含むストリームでは、言語によって単語の順序が異なるため (ドイツ語では動詞が文の末尾にあることが多い) 、翻訳を処理するには少なくとも一文が必要です。 図 6: SyncWords の [ HLS Output ] 設定のスクリーンショット [ Save ] をクリックします (ボタンが [ Saved ] に変わります) 。必須の設定が欠けている場合は、[ Some data is invalid. ] という警告が表示され、感嘆符の付いた赤い円がその設定場所を示します。スクロールして探す必要があるかもしれません。 これで SyncWords サービスの設定が完了し、開始する準備が整いました。 ステップ 3: HLS を SyncWords チャネルにプッシュするために MediaLive チャネルを設定します。 MediaLive の入力とチャネルを作成します。 HLS 出力グループを追加し、[ Credentials (optional) ] セクションで [ Create parameter ] を選択します。URL、ユーザー名、パスワードにはステップ 2 で SyncWords が自動生成した設定値を使用します。 パラメータに名前を付けます。MediaLive チャネルが作成されると、このパラメータは AWS Systems Manager パラメータストアに自動的に保存されます。MediaLive チャネルをステップ2で作成したSyncWordsチャネルのソースとして受け入れるには、認証情報が必要です。 図 7: AWS Elemental MediaLive の [ HLS output group ] 設定のスクリーンショット MediaLive チャネルで HLS グループと HLS 出力のセットアップを続けます。設定が完了したら、 Create channel ボタンをクリックします。 ステップ 4: サービスの開始と監視: MediaLive チャネルを起動し、SyncWords サービスの設定で [ Start Service ] をクリックします。MediaLiveチャネルの状態が [ Running ] に変わり、SyncWords GUI の接続ステータスが [ Connected ] になるのを待ちます。注:起動フェーズには数分かかる場合があります。 MediaPackage Origin エンドポイントセクションの [ Preview ] リンクをクリックして、出力を監視してください。チャネルが実行されると、字幕と音声言語のリストが表示されます。お好みの再生クライアント (通常は再生クライアントの右下隅にあります) でキャプションと吹き替え言語トラックを選択してください。 注：SyncWords ライブワークフローでスタンドアロン字幕ファイル (SRT または VTT) が必要な場合は、ライブサービスがアーカイブされると、SyncWords Liveダッシュボードで直接利用できるようになります。 クリーンアップ 不必要なリソースの使用とコストを避けるために、使用していない MediaLive と SyncWords のチャネルを停止または削除します。 まとめ 字幕やキャプションのようなアクセシビリティサービスは、より多く、より質の高いものが求められています。AWS Elemental Media Services と SyncWords の AI キャプションおよび翻訳サービスを使用して、ライブキャプションや吹き替えオーディオトラックを作成することで、コンテンツを充実させることができます。 実際にお試しいただきライブ放送のクラウド環境における文字起こし、翻訳、吹き替えの効率的な実装を確認ください。 また、キャプションと翻訳の精度の高さ、エンドユーザーへのタイムリーな表示にもご注目ください。 AWS の担当者 にご連絡いただければ、当社がどのようにお客様のビジネスを加速させることができるかご説明致します。 参考リンク Multi-language automatic captions and audio dubbing made possible for live events with AWS Media Services and SyncWords Amazon Cloudfront – Content Delivery Network (CDN) AWS Elemental Live – Live streaming encoder Automated Captions and Translations Using AWS Elemental AWS Media Services AWS Media & Entertainment Blog　(日本語) AWS Media & Entertainment Blog　(英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 翻訳はソリューションアーキテクトの金目, 井村が担当しました。原文は こちら をご覧ください。

本稿は、2024年12月19日に AWS Media & Entertainment Blog で公開された “ Delivering low-latency captions and voice translation for live sports, news, and OTT platforms with SyncWords and AWS ” を翻訳したものです。 本稿は、SyncWords の VP of Business Development and Strategy である Giovanni Galvez と共同執筆しました。 お客様からクラウドの自動音声認識 (Automatic Speech Recognition : ASR) テクノロジーを活用しながら、特にスポーツ中継やニュースのライブ配信で、低遅延でキャプションを実現する最善の方法について問い合わせがありました。AWS と SyncWords は、この課題に取り組み、生放送用のキャプションの埋め込みと音声翻訳を生成するために、 Secure Reliable Transport (SRT) プロトコルと SyncWords を使用して、安全で低レイテンシーのキャプション埋め込みワークフローを可能にしました。これらはハードウェアを追加することなく実現されています。 以前のブログでは、 HTTP Live Streaming (HLS) ワークフローをデプロイする生放送向けのキャプションと字幕の作成を自動化するために開発された Amazon Web Services (AWS) と SyncWords の実装方法について紹介しています。 Multi-language automatic captions and audio dubbing made possible for live events with AWS Media Services and SyncWords と Translate live sports automatically to reach international fans with AWS Media Services and SyncWords は、これらの実装を紹介しており、このブログを読む前に読んでおくと、より理解が深まります。 次のワークフロー図は、SyncWords の SRT ベースのソリューション、映像伝送のための AWS Elemental MediaConnect 、映像処理の AWS Elemental MediaLive 、オリジンおよびパッケージングサービスの AWS Elemental MediaPackage 、配信のための Amazon CloudFront  を使用した、自動化された低レイテンシーのキャプション埋め込みと音声翻訳のデプロイを示しています。 SyncWords は SRT の取り込みと出力をサポートし、クラウド内の動画処理ワークフローのための AWS Media Services とネイティブに統合されたクラウドベースの安全なキャプションおよび音声埋め込みソリューションをユーザーに提供します。 MediaLive が SRT Caller 入力 をサポートしたことで、SyncWords のキャプション付きのライブストリームを MediaLive に直接取り込むことができます。すべてのコンポーネントが同じ AWS リージョンにあり、MediaConnect が他のワークフロー要件に必要ない場合は、MediaConnect をバイパスできる可能性があります。以下は、MediaLive SRT Caller 入力を使用した簡略化されたワークフロー図です。 MediaConnect とシームレスに連携し、 AWS グローバルネットワーク を活用することで、クラウドベースの自動音声認識 (ASR)、SyncWords による費用対効果の高いキャプション埋め込みおよび音声翻訳サービスを利用できるようになり、また、MediaConnect による安全で低レイテンシーな伝送により、キャプション付ストリームを世界中の顧客やビジネスパートナーに配信できるようになります。   このワークフローを AWS にデプロイすると、次のような利点があります。 1. 複数の解像度とコーデックのネイティブサポート CEA-608 / CTA-708 キャプションプロトコルを使用して、SD、HD、および UHD (4K) 解像度のキャプションを SRT ストリームに挿入できます。HEVC および AVC ビデオコーデックと互換性があります。キャプションデータをエレメンタリービデオストリームに挿入するときにトランスコーディングは必要なく、1 秒未満で処理されます。  2. Amazon Elastic Kubernetes Services (Amazon EKS) によるスケールするキャプション処理 SyncWords のキャプションと音声翻訳サービスは AWS のサービス上に構築されており、Amazon EKS を用いて自動的にスケーリングします。また、二重パイプラインの冗長性をサポートするためにMediaLive と統合されています。お客様は、オンプレミスハードウェアの管理やプロビジョニングを負担することなく、キャプションサービスに集中できるようになります。サービスの冗長性とスケーラビリティは、高品質で信頼性の高いライブ体験を顧客に提供します。 3. MediaConnectと SRT を使った収益化 放送局は MediaConnect と SRT プロトコルを最大限に活用し、母国語を話す世界中の視聴者に向けてニュースやスポーツのキャプション付きライブストリームを安全に伝送し収益化することができます。さらに、 MediaConnect Entitlements を使用して、世界中のビジネスパートナーや顧客にコンテンツを配信できます。 まとめ このブログでは、AWS サービスと SyncWords を使用して、回復力のある低レイテンシーの SRT ストリーミングワークフローでライブイベントの自動キャプションを有効にする方法について説明しました。AWS を使用したライブイベントパイプラインの作成方法は、 AWS でのライブストリーミング ソリューションを参照してください。さらに、AWS Media Services を使い始めることに興味がある場合は、 製品ページ をご覧ください。ライブイベントにキャプションソリューションを統合するためのドキュメントについては、 SyncWords  をご覧ください。 参考リンク AWS Media Services AWS Media & Entertainment Blog　(日本語) AWS Media & Entertainment Blog　(英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 翻訳はソリューションアーキテクトの金目, 石井が担当しました。原文は こちら をご覧ください。

このブログ記事は Security Specialist Solutions Architect の Bryant Pickford と Sr. Cloud Infrastructure Architect の Umesh Kumar Ramesh、Sr. Product Manager の Kevin Lee によって書かれました。 2024年12月2日：この投稿は WAFV2 への移行を反映するように更新され、AWS WAF Classic のパートナーマネージドルールからパートナーマネージドルール（wafv2）への 1:1 のマッピングする内容が追加されています AWS WAF Classic のサポートは、2025 年 9 月 30 日に終了します。 2019 年 11 月、Amazon はより使いやすく豊富な機能を提供する AWS Web アプリケーションファイアウォール (WAF) の新しいバージョンを立ち上げました。この投稿では AWS WAF Classic から新しい AWS WAF に移行する方法をいくつかご紹介します。 AWS WAF のマネージドルール は AWS WAF で最も強力な機能の 1 つです。サービスでルールを直接作成または管理する必要なく、アプリケーションを保護するのに役立ちます。新しいリリースには、他の拡張機能とAWS WAF用の新しいAPIのセットが含まれています。 この作業を開始する前に、 AWS WAF がどのように機能するか を復習することをお勧めします。既に AWS WAF に精通している場合はスキップしてください。AWS WAF を初めて使用する、AWS WAF を展開するためのベストプラクティスを知りたい場合は、 AWS WAFを実装するためのガイドライン を読むことをお勧めします。 AWS WAFで変更されたもの こちらが AWS WAF の変更点のまとめです。 AWS Managed Rules for AWS WAF： 一般的な Web の脅威に対する保護を提供し、VPN、プロキシ、および TOR ネットワークに由来するボットとトラフィックをブロックするための Amazon IP reputation list と Anonymous IP list が含まれています 新しい API (wafv2)： 2 つではなく単一の API セットを使用して、すべての AWS WAF リソースを構成できます ( WAF および WAF-regional ) 簡素化されたサービス制限： Web ACL 毎により多くのルールを提供し、より長い正規表現パターンを定義できます。条件ごとの制限は排除され、Web ACL キャパシティユニット (WCU) に置き換えられました ドキュメントベースのルールライティング： JSON 形式のルールを Web ACL に直接書き込み表現できます。個々の API を使用して異なる条件を作成し、それらをルールに関連付け、コードを大幅に簡素化し、保守可能にする必要はなくなりました ネストと完全な論理操作のサポート： 複数の条件を含むルールを含むルールを書くことができます。また、[ a および not ( b または c ) ]などのステートメントを作成して、論理操作をネストすることもできます IP セットの可変 CIDR 範囲サポート： ブロックする IP 範囲を定義する柔軟性が高まります。新しい AWF WAF は IPv4 は /1 から /32、IPv6 は /1 から /128をサポートしています チェーン可能なテキスト変換： 受信トラフィックに対するルールを実行する前に、複数のテキスト変換を実行できます 改良されたコンソール体験： 視覚的なルールビルダーの機能と、より直感的なデザインを備えています Condition タイプの AWS CloudFormation サポート： JSON で書かれたルールは YAML 形式に素早く変換できます より高いクォータ： Web ACL 毎のルール、長い正規表現パターン、および条件ごとの制限を置き換える Web ACL キャパシティユニット (WCU) 設定可能なタイムウィンドウ： レートベースルールにおいて、リクエスト集約のためのタイムウィンドウの設定ができるようになりました。お客様は以前からサポートされていた 5 分に加えて、1 分、2 分、10 分のタイムウインドウを選択できるようになりました より低いレートベースの制限： レートベースルールにおいて、しきい値を低く設定できるようになりました。お客様は以前の最低 100 リクエストと比較して、評価ウィンドウ毎に最低で 10 リクエストから、レートベースルールを構成できるようになりました 多くの変更が導入されましたが、あなたがすでによく知っている概念と用語は同じままです。以前の API は AWS WAF Classic にリネームされました。 AWS WAF Classic の下で作成されたリソースは、新しい AWS WAF と互換性がないことに注意してください。 Web ACL キャパシティユニットについて Web ACL キャパシティユニット (WCU) は、2019 年 11 月に AWS WAF に導入された新しい概念です。WCU は Web ACL に関連付けられたルールを実行するために、必要な動作リソースを計算および制御するために使用される測定値です。WCU は Web ACL に追加できるルールの数を視覚化および計画するのに役立ちます。Web ACL が使用する WCU の数は、追加する ルールステートメント によって異なります。各 Web ACL の最大 WCU は 1,500 であり、ほとんどのユースケースで十分な量です。WCU がどのように機能するか、 各タイプのルールステートメントがどのように WCU を消費するか を十分に理解されておくことをお勧めします。 新しいAWS WAFへの移行を計画します AWS WAF Classic から新しい AWS WAF に移行するために役立つ 新しい API とウィザードを発表しました。AWS WAF Classic の下で Web ACL を解析し、展開した新しい AWS WAF の下に同等の Web ACL を作成する CloudFormation テンプレートを生成します。このセクションでは、ウィザードを使用して移行を計画する方法について説明します。 始める前に知っておくべきこと 最初に、Migration ウィザードは既存の Web ACL を調べます。Web ACL に関連付けられた変換ルール、IPセット、正規表現パターンセット、文字列マッチフィルター、およびアカウント所有のルールグループを調査して記録します。ウィザードを実行しても、既存の Web ACL の構成またはその Web ACL に関連するリソースを変更・削除することはありません。終了すると、新しい AWS WAF で使用するために変換された同等の Web ACL、ルールセット、フィルター、およびグループを含む CloudFormation テンプレートが S3 バケット内に生成されます。新しい AWS WAF で Web ACL を再現するには、テンプレートを手動で展開する必要があります。 次の制限に注意してください。 同じアカウントにある AWS WAF Classic のリソースのみが移行されます IP セットや正規表現パターンセットなど、共有リソースを参照する複数の Web ACL を移行すると、新しい AWS WAF の下で複製されます レートベースのルールに関連する条件は引き継がれません。移行が完了したら、ルールと条件を手動で再作成してください AWS マーケットプレイスで入手したマネージドルールは引き継がれません。一部のパートナーは、新しい AWS WAF で購読できる同等のマネージドルールを用意しています Web ACL との紐付けの設定は引き継がれません。これは意図的に行われ、移行が本番環境に影響を与えないようにしました。すべてが正しく移行されていることを確認したら、Web ACL をリソースに再度紐付けてください Web ACL のログはデフォルトで無効になります。切り替える準備ができたら、ロギングを再度有効化してください CloudWatch アラームを設定している場合は引き継がれません。 Web ACL が再作成されたら、再度アラームをセットアップする必要があります Migration ウィザードを使用して AWS WAF のセキュリティオートメーション を移行できますが、バックグラウンドで使用される Lambda 関数を変換しないためお勧めしません。代わりに、新しいソリューション（バージョン 3.0 以降）を再配置します。こちらは新しい AWS WAF と互換性があるように更新されています。 パートナーマネージドルールとのマッピング AWS マーケットプレイスのパートナーマネージドルールを AWS WAF Classic で使用するお客様のために、一部のセラーは新しい AWS WAF で同等のマネージドルールグループをリリースしています。移行中、次のマッピングガイダンスを使用して、新しい環境でこれらに再登録する必要があります Cyber Security Cloud Managed Rules for AWS WAF – HighSecurity OWASP Set: AWSManagedRulesCloudSecurityOWASPSet にマップします F5 Bot Detection Signatures for AWS WAF: AWSManagedRulesF5BotProtection にマップします F5 Web Application CVE Signatures for AWS WAF: AWSManagedRulesF5CVE にマップします F5 Rules for AWS WAF – API Security Rules: AWSManagedRulesF5APISecurityRules にマップします AWS WAF – Web Exploits Rules by F5: AWSManagedRulesF5WebExploitsOWASP にマップします Fortinet Managed Rules for AWS WAF – API Gateway: AWSManagedRulesFortinetAPISecurity にマップします Fortinet Managed Rules for AWS WAF – Complete OWASP Top 10: AWSManagedRulesFortinetOWASPTop10 にマップします 他のルールセットについては、AWS マーケットプレイスのセラーに新しい AWS WAF での提供を確認してください。移行には手動での対応が必要ですが、新しい AWS WAF は、より堅牢でスケーラブルで管理可能なソリューションを提供します。 AWS Firewall Manager と Migration ウィザードについて Migration API とウィザードの現在のバージョンは、AWS Firewall Manager が管理するルールグループを移行しません。Firewall Manager が管理する Web ACL でウィザードを使用する場合、関連するルールグループは引き継がれません。ウィザードを使用して Firewall Manager が管理する Web ACL を移行する代わりに、新しい AWS WAF のルールグループを再作成し、既存のポリシーを新しいポリシーに置き換えることができます。 注意 ：過去には、ルールグループは Firewall Manager の下に存在していた概念でした。ただし最新の変更により、AWS WAF の下にルールグループを移動しました。機能は同じままです 新しい AWS WAFに移行する Web ACL を AWS WAF Classic から新しい AWS WAF に移行するために、 Migration ウィザード を使用して実行可能な AWS CloudFormation テンプレートを作成します。このテンプレートは、AWS WAF ルールと対応するエンティティの新しいバージョンを作成するために使用されます。 1.新しい AWS WAF コンソールから、 Switch to AWS WAF Classic を選択して AWS WAF Classic に移動します。ウインドウの上部にメッセージボックスがあります。メッセージボックスの migration wizard のリンクを選択して、移行プロセスを開始します 図1：Migration ウィザードを開始 2. 移行するWeb ACLを選択します 図2：移行する Web ACL を選択 3. Migration ウィザード用の新しい S3 バケットを指定して、生成する AWS CloudFormation テンプレートを保存します。S3 バケット名は接頭辞 AWS-WAF-Migration- から始める必要があります。例えば AWS-WAF Migration-helloworld のように名前を付けます。デプロイするリージョンにテンプレートを保存します。例えば us-west-2 に Web ACL がある場合、us-west-2 に S3 バケットを作成し、Stack を us-west-2 にデプロイします。 Auto apply the bucket policy required for migration を選択して、API が S3 バケットにアクセスするために必要な権限を構成するために、移行に必要なバケットポリシーを適用します。 移行できないルールを処理する方法を選択してください。 Exclude rules that can’t be migrated（移行できないルールを除外する） 、 Stop the migration process if a rule can’t be migrated（ルールを移行できない場合は移行プロセスを停止する） のどちらかを選択します。ウィザードがルールを移行する能力は、前述の WCU 上限の影響を受けます。 図3：移行オプションを構成 注意： 必要に応じて次のコードを実行して、必要なアクセス許可を構成するために、以下のポリシーで手動で S3 バケットをセットアップできます。これを行う場合は Use the bucket policy that comes with the S3 bucket（S3 バケットに付属するバケットポリシーを使用する） を選択します。 <bucket_name> および <customer_account_id> をあなたの情報に置き換えることを忘れないでください 全ての AWS リージョン（waf-regional）の場合： { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "apiv2migration.waf-regional.amazonaws.com" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::<BUCKET_NAME>/AWSWAF/<CUSTOMER_ACCOUNT_ID>/*" } ] } Amazon CloudFront（waf）の場合： { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "apiv2migration.waf.amazonaws.com" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::<BUCKET_NAME>/AWSWAF/<CUSTOMER_ACCOUNT_ID>/*" } ] } 4. 構成を確認し Start creating CloudFormation template を選択して、移行を開始します。AWS CloudFormation テンプレートを作成するには、Web ACL の複雑さによりますが、約 1分ほどかかります 図4：CloudFormation テンプレートを作成 5. 完了したら、生成されたテンプレートファイルを確認して、そうしたい場合は変更することができます。（例えばルールを追加することができます）続行するには Create CloudFormation stack（CroudFormation スタックの作成） を選択します。 図5：テンプレートを確認 6. AWS CloudFormation コンソールを使用して、Migration ウィザードによって作成された新しいテンプレートをデプロイします。 Prepare template から Template is ready を選択します。 Template source では Amazon S3 URL を選択します。デプロイする前に、テンプレートをダウンロードしてレビューして、リソースが期待通りに移行されていることを確認することをお勧めします。 図6：スタックを作成 7. Next を選択し、ウィザードの先に進みスタックを展開します。正常に作成されたら、新しい Web ACL を確認してリソースに関連付けることができます。 図7：移行を完了 移行後の考慮事項 移行が正しく完了したことを確認した後、新しい AWS WAF 機能のいくつかを活用するために構成を再検討することをお勧めします。 例えばアプリケーションのセキュリティを改善するために、Web ACL に AWS Managed Rule を追加することを検討してください。AWS Managed Rules は 3 つの異なるタイプのルールグループ を備えています。 ベースライン ユースケース別 IPレピュテーションリスト ベースラインルールグループは、悪意のある入力がアプリケーションに入力される前に停止したり、管理ページへのアクセスを防ぐのに役立つなど、さまざまな脅威に対する一般的な保護を提供します。ユースケース別のルールグループは、多くの異なるユースケースと環境に追加の保護を提供し、IP レピュテーションリストはクライアントのソース IP に基づいて脅威インテリジェンスを提供します。 また、古いルールの一部を再検討し、ルールを書き換えたり古いルールを削除したりすることで、最適化することを検討するべきです。例えば OWASPトップ 10 Web アプリケーションの脆弱性ホワイトペーパー から AWS CloudFormation テンプレートを展開してルールを作成した場合、AWS Managed Rules に置き換えることを検討するべきです。ホワイトペーパー内で見つかった概念は依然として適用されており、独自のルールを書くのに役立つ場合がありますが、テンプレートによって作成されたルールは、AWS Managed Rule に置き換わっています。 JSON を使って新しい AWS WAF で独自のルールを書くことについては、 Protecting Your Web Application Using AWS Managed Rules for AWS WAF ウェビナーをご視聴ください。それに加えて、 サンプル JSON/YAML を参照することができます。 移行後に CloudWatch メトリクスを再訪し、必要に応じてアラームを設定します。アラームは Migration API によって引き継がれておらず、メトリクス名も変更された可能性があります。また、 ロギングの構成を再度有効にする 必要があり、以前の Web ACL で持っていた可能性のあるフィールドの編集も必要です。 最後に、この時間を使用してアプリケーションチームと協力し、セキュリティポスチャを確認してください。アプリケーションによって頻繁に解析されているフィールドを調べ、それに応じて入力をサニタイズするルールを追加します。アプリケーションのビジネスロジックがそれらを処理できなかった場合、これらのケースをキャッチするためのエッジケースを確認し、ルールを追加します。また、リソースアソシエーションを新しい Web ACL に変更する際に、少し混乱がある可能性があるため、スイッチするときにアプリケーションチームと調整する必要があります。 AWS WAF を使用してコスト効率の高い Web アプリケーションを保護するための詳細については、 Cost-effective ways for securing your web applications using AWS WAF のブログをチェックしてください。 結論 この投稿が AWS WAF Classic から、新しい AWS WAF への移行を計画するのに役立つことを願っています。 AWS Managed Rule などの新しい拡張機能を備えており、独自のルールを作成する柔軟性を提供するため、新しいAWS WAFエクスペリエンスを探索することをお勧めします。 このブログは「 Migrating your rules from AWS WAF Classic to the new AWS WAF 」という記事の翻訳となります。 翻訳は Senior Solutions Architect の森が担当しました。

Amazon Web Services (AWS) は、ポスト量子暗号 (PQC:Post-Quantum Cryptography) への移行を進めています。AWS の他のセキュリティおよびコンプライアンス機能と同様に、PQC は 責任共有モデル の一部として提供されます。つまり、一部の PQC 機能はすべてのお客様に対して透過的に有効化されますが、他の機能はお客様が要件を満たすために選択して実装できるオプションになります。この移行は、インターネットなどの信頼されていないネットワークを介して通信するシステムから段階的に行われます。 暗号解読可能量子コンピュータ (CRQC: Cryptographically Relevant Quantum Computer) と呼ばれることもある大規模な量子コンピュータの脅威は、現在使用されている公開鍵暗号アルゴリズムを解読できる可能性があることです。これらのアルゴリズムは、ほとんどの通信プロトコルとデジタル署名スキームで使用されています。過去 8 年間、AWS は他の業界リーダー、政府機関、学術機関とともに、量子コンピューティングに対して耐性のある新しい公開鍵暗号アルゴリズムの提唱、研究、提案に取り組んできました。お客様は AWS が行う暗号化処理によってデータを保護しているため、私たちは早期から対策に着手し、将来的な PQC への移行における労力と影響を最小限に抑えました。AWS で使用されている公開鍵暗号を解読できるほど強力な量子コンピュータが現在存在する証拠はありませんが、私たちはそれを待っているつもりはありません。将来におけるお客様のデータのセキュリティを守るため、今のうちから対策を講じることを選びました。 この投稿では、AWS が PQC への移行の道のりがどこまで進んでいるかを簡潔にご紹介し、今後の方向性についてお伝えします。 過去 5 年間、私たちは米国国立標準技術研究所 (NIST) が評価中の PQC アルゴリズムの初期バージョンを、オープンソースライブラリと重要なセキュリティサービスの両方で展開し、お客様が PQC への移行によるパフォーマンスへの影響をテストできるようにしてきました。例えば、アルゴリズム実装のオープンソースライブラリ ( AWS-LC )、TLS 実装 ( s2n )、および AWS Key Management Service (AWS KMS) 、 AWS Secrets Manager 、 AWS Certificate Manager (ACM) などのコアセキュリティサービスには、2019 年から NIST PQC 提案アルゴリズムの鍵カプセル化の実装が含まれています。 2024 年 8 月 13 日、 NIST は 3 つの新しいポスト量子暗号 (PQC:Post-Quantum Cryptography)の暗号アルゴリズムを連邦情報処理標準 (FIPS) として発表しました 。これは、2016 年に開始された NIST の量子コンピュータ PQC 標準化プロセスの結果です。AWS の従業員も、この 3 つの新 FIPS 標準を含む多くの暗号化スキームの提案に携わっています。 FIPS 203, Module-Lattice-based Key-Encapsulation Mechanism Standard (ML-KEM) 、当初 CRYSTALS-Kyber という名前で提出されたモジュール格子ベースの KEM FIPS 204, Module-Lattice-based Digital Signature Standard(ML-DSA) 、当初 CRYSTALS-Dilithium として提出されたモジュール格子ベースのデジタル署名アルゴリズム FIPS 205, Stateless Hash-Based Digital Signature Standard(SLH-DSA) 、SPHINCS+ として始まったステートレスハッシュベースの署名方式 多くのお客様は、量子コンピュータ時代における安全な暗号化の標準化プロセスを注視してきました。これには、米国政府の Commercial National Security Algorithms (CNSA) Suite 2.0 の PQC 採用に関する要件や、欧州委員会の Recommendation on a Coordinated Implementation Roadmap for the transition to Post-Quantum Cryptography が含まれます。 第 1 ラウンドのPQCアルゴリズムが標準化されたことから、私たちは長期的なサポートのためにそれらを実装し始めることができます。暗号化操作を代行するサービスとオープンソースツールに依存しているお客様に、シームレスな移行を提供するために、PQC を実装するアプローチは次のとおりです。 AWS は今後数年にわたり、PQC への移行に多層的なアプローチを取ります。同時に進行するワークストリームは次のように定義しています。 ワークストリーム 1 : 既存システムの棚卸し、新しい標準の特定と開発、テスト、移行計画を行います。最初の一連のアルゴリズム標準は公開されましたが、PQC を特定のアプリケーションやプロトコルに統合するための互換性確保のため、追加の標準が今後公開される予定です。 ワークストリーム 2 : AWS に送信されるお客様データの長期的な機密性を確保するため、公開 AWS エンドポイントに PQC アルゴリズムを統合します。 ワークストリーム 3 : ソフトウェア、ファームウェア、文書の署名などの機能に使用される、新たなポスト量子の長期的な Root of Trust (信頼の起点) をお客様がデプロイできるよう、AWS 暗号化サービスに PQC 署名アルゴリズムを統合します。 ワークストリーム 4 : サーバーやクライアント証明書の検証など、セッションベースの認証に、ポスト量子署名を使用できるよう、AWS サービスに PQC 署名アルゴリズムを統合します。 ワークストリーム 1 この取り組みは、私達が現在進めている移行計画の外観であると捉えています。すでに私たちの全体的な戦略に反映されており、お客様のニーズに基づいて移行の優先順位付けを行っています。 お客様と同様に、私たちも暗号化を使用しているすべての場所を確認し、どの実装を移行する必要があり、優先順位をつける必要がありました。重要な決定の 1 つは、転送中 (in transit) の暗号化により重点を置き、保管中 (at rest) のデータの暗号化にはあまり重点を置かないことでした。公開鍵 (非対称) 暗号は、転送中の暗号化の基盤となるものです。なぜなら、信頼されていないネットワーク上で双方が共有秘密鍵のネゴシエーションを可能にするためです。しかし、現在広く使われている伝統的な公開鍵アルゴリズムが、暗号解読可能量子コンピュータ (CRQC) の実現により危険にさらされています。業界全体の現在の合意に基づけば、256 ビットの対称鍵暗号化に対する暗号解読可能量子コンピュータのリスクは、緩和する必要はありません。AWS の保管中のデータは 256 ビットの対称鍵暗号化で暗号化されているため、既存のお客様データを再暗号化したり、将来のデータを暗号化するために使用する対称アルゴリズムやキーを変更する必要はないと考えています。 対称暗号化キーやアルゴリズムの安全性は、暗号解読可能量子コンピュータによる暗号解読の脅威に晒されていませんが、公開鍵アルゴリズムを使用して共有対称鍵をネゴシエーションする場合があり、その際に対称鍵が危険にさらされる可能性があります。AWS で最初に PQC に移行する公開鍵暗号の用途は、まさにこの場合です。つまり、お客様と AWS サービスの公開エンドポイント間で共有対称鍵のネゴシエーションをする場合です。お客様が AWS サービスと通信するためのネットワークは、多くの場合 AWS やお客様のどちらの管理下になく、悪意のある第三者がデータを盗聴し、将来的に量子コンピュータを使って暗号を解読する可能性があります。ワークストリーム 2 では、この計画についてより詳しく説明しています。 次に AWS で PQC に移行するのは、長期的な Root of Trust (信頼の起点) として機能する公開鍵ペアを作成する機能です。これは通常、ソフトウェア、ファームウェア、ドキュメントにデジタル署名を適用するために使用されます。このような公開鍵ペアは、簡単に更新できないため、将来数年間にわたってデジタル署名の用途で有効である必要があります。人工衛星、ゲーム機、その他の IoT デバイスのファームウェアを考えてみてください。デバイスの寿命期間中に公開鍵ペアと署名アルゴリズムのコードを更新することが難しい場合があります。ワークストリーム 3 では、この計画をより詳しく説明しています。 AWS における公開鍵暗号の最後の領域は、一時的な Root of Trust (信頼の起点) として機能するキーペアを作成する機能を提供することです。これは通常、単一のトランザクション、Web セッション、または他の一時的なメッセージにデジタル署名を適用するために使用されます。この使用例の最も一般的な例は、デジタル証明書が TLS セッションでサーバーまたはクライアントを認証するために使用される方法です。ワークストリーム 2 と 3 が TLS セッションでのセッション鍵のネゴシエーションとデジタル署名のリスクを処理すると想定されるかもしれません。では、保護する残りの部分は何でしょうか? 実は、公開鍵暗号を利用してメッセージを交換する際には、広範囲のインターネットインフラストラクチャにおける標準と相互運用性に大きく依存します。業界がこれらの標準に合意し、相互運用性をテストするには時間がかかるため、このワークストリームが完了するまでに時間がかかります。ワークストリーム 4 では、この計画についてより詳しく説明しています。 AWS がどのように暗号化に関連するインベントリを作成し、PQC への移行計画を立てたかについて説明しました。暗号化の処理を AWS に全面的に任せていない場合、お客様は準備として何をすべきでしょうか? すべてのアプリケーションや業界に当てはまる単一のアプローチはありませんが、私たちが貢献したり、作業の一部として利用したりした推奨事項に関するより詳しい情報が記載されている関連するリソースをいくつかご紹介します。 CISA Quantum-: Migration to Post-Quantum Cryptography CISA Quantum-Readiness: Migration to Post-Quantum Cryptography CISA Strategy for Migrating to Automated Post-Quantum Cryptography Discovery and Inventory Tools ETSI TR 103 619 Migration strategies and recommendations to Quantum Safe schemes 組織全体の暗号技術/暗号システムの棚卸しを行って、PQC 移行の優先順位を付けることは、数年にわたる取り組みが必要かもしれません。しかし、短期的には次の 2 つの戦術的な対策を検討することをお勧めします。まず、ソフトウェアの更新バージョンを配布する機能を確保することです。これは、脆弱性管理やソフトウェアライフサイクル管理の観点から、組織にとって重要な機能です。この機能は、 AWS コマンドラインインターフェース (AWS CLI) と AWS SDK の新しい ポスト量子バージョンを公開した際に採用する必要があります。また、AWS サービスと通信するために TLS やその他の暗号化実装を使用するサードパーティ製品を更新する必要があるかもしれません。これにより、AWS が提供する PQC を活用できるようになります。 次に、組織全体で TLS 1.3 を採用する全社的な取り組みを開始することを強くお勧めします。TLS 1.3 および以降のバージョンは、従来からある公開鍵暗号を使ってセキュリティとパフォーマンスを改善しているだけでなく、PQC を使用できるようになることが義務づけられています。最近クライアントとサーバーで TLS 1.2 に更新した場合でも、システムを PQC の将来に備えるための作業が残っています。 ワークストリーム 2 お客様は、公開鍵暗号に基づくプロトコルを使用してクラウドサービスと通信します。これらのプロトコル (TLS など) は、お客様の通信の機密性が保たれ、転送中に改ざんされないことを保証するのに役立ちます。お客様の長期的な機密性の必要性を保護するために、私たちは量子コンピュータに対する長期的な対策として組み合わせた新しい鍵共有方式を先駆けて導入しました。この新しい方式は、 楕円曲線ディフィー・ヘルマン (ECDH) という従来からある鍵交換アルゴリズムと、新しく標準化された ML-KEM アルゴリズムなどのポスト量子鍵カプセル化方式を組み合わせたものです。得られた 2 つの鍵を組み合わせることで、ネットワークトラフィックを暗号化するためのセッション通信鍵が確立されます。攻撃者がこの新しい鍵共有方式によって提供される機密性を破るには、これらの公開鍵プリミティブ (ECDH と ML-KEM) の両方を解読する必要があります。 AWS は、 オープンソースの FIPS-140-3 検証済み暗号ライブラリ AWS-LC で ML-KEM を実装 することで、ポスト量子暗号の展開の第一歩を踏み出しました。AWS-LC は AWS 全体で使用されている中核的な暗号ライブラリです。このワークストリームに関連して、HTTPS エンドポイントを持つ AWS サービス全体で使用されているオープンソース TLS 実装 s2n-tls でも使用されています。 Internet Engineering Task Force (IETF) は現在、ポスト量子暗号を組み込んだ TLS プロトコル標準の最終化を進めています。この標準が完成すれば、AWS は s2n-tls を新しい仕様に合わせて更新します。IETF 標準に基づく s2n のバージョンに AWS-LC からの ML-KEM 実装を統合できれば、この s2n バージョンを HTTPS ベースのインターフェースを提供するすべての AWS パブリックエンドポイントに展開を開始します。これは、AWS SDK や AWS CLI を通じてアクセスされる大半の AWS サービスを表します。SFTP、IPsec、SSH などの他のインターフェースを提供する AWS サービスについては、IETF などの標準化機関がそれらのプロトコルの実装ガイダンスを公開次第、ML-KEM サポートを追加します。 AWS マネージドサービスエンドポイントを PQC over TLS に移行する一環として、 Elastic Load Balancing (ELB) 、 Amazon API Gateway 、 Amazon CloudFront など、ワークロードのサーバー側 TLS 終端を提供するサービスも有効化されます。これにより、これらのサービスで使用している同じデジタル証明書を使用でき、AWS がサーバー側で ML-KEM による TLS セッションのネゴシエーションを行います。これにより、既存の証明書を、未だ定義されていない PQC 標準のものに置き換えずとも、TLS セッションの長期的な機密性が提供されます。 ML-KEMへの移行をより円滑に進めるため、AWS は National Cybersecurity Center of Excellence (NCCoE) Migration to Post-Quantum Cryptography 、 Linux Foundation’s Post Quantum Cryptography Alliance 、 Rust TLS Project など、主要な業界イニシアチブと協力しています。これらのパートナーシップは、テクノロジー分野全体で PQC ソリューションの異なる実装間のシームレスな相互運用性を確保するのに不可欠です。 ワークストリーム 3 多くのお客様は、ファームウェア、オペレーティングシステム、プリインストールされたサードパーティーのアプリケーションを含むシステムを製造しています。これらのコンポーネントは、公開鍵ベースのルート認証で暗号署名されており、エンドユーザーにサービスを提供する際のシステムのセキュリティと真正性を維持しています。セットトップボックスに接続しているスマート TVのように、インターネットに接続されずに 10 年以上稼働するシステムもあります。 さらに、一部のお客様は、製造時にハードウェアに直接ルート証明書を埋め込む必要があります。この処理は、元に戻したり更新したりすることはできません。10 年以上の稼働を想定したデバイスでは、量子コンピュータが暗号解読に使えるようになった場合でも、これらの初期のルート証明書のセキュリティを堅牢に保つ必要があります。 コードや文書に署名するために長期間有効な Root of Trust (信頼の起点) を提供する必要性に対処するため、AWS は ML-DSA という新しいデジタル署名アルゴリズムを採用します。ML-DSA は、量子コンピュータを持つ攻撃者に対しても安全であると考えられています。AWS は最初に AWS Key Management Service (AWS KMS) の機能として ML-DSA を提供し、お客様が AWS KMS で使用される FIPS-140-3 Level 3 検証済みのハードウェアセキュリティモジュール (HSM) 内で PQC 鍵を生成し、署名操作の Root of Trust (信頼の起点) として使用できるようにします。この統合は、PQC ロードマップにおける重要なマイルストンを示すものであり、お客様に長期的なセキュリティニーズに対する安全でポスト量子の Root of Trust (信頼の起点) と認証を確立する機能を提供します。 この長期的な視点は、PQC を早期に実装することの重要性を強調しています。これにより、長期間オフラインであっても、システムの全運用期間中にわたってセキュリティが確保されるようになります。Amazon は AWS KMS のこの機能を使って自社の Root of Trust (信頼の起点) を保護しますが、皆様にもこの機能を活用して同様の対策を検討していただくことをお勧めします。 ワークストリーム 4 ワークストリーム 2 では、通信チャネルを介してデータを共有する際のデータの機密性に対するリスクから保護するために PQC を展開する方法について議論しました。ストーリーを完結するには、ポスト量子の世界において、通信チャネル経由でサーバーとクライアントの身元の真正性を保護する方法が必要になります。 デジタル署名は、今日のTLS や SSH などのネットワークプロトコルにおいて、エンドポイントの認証に使われています。お客様は、信頼できる認証局 (CA) から発行された証明書を使用しています。この証明書は、デジタル署名を使って公開鍵をアイデンティティにバインドしており、サービスとクライアントのエンドポイントを認証するために使われます。現在利用可能な PQC 標準 (ML-DSA など) の一部は、証明書と組み合わせて実装することで、量子コンピュータ時代のリスクに対処できます。しかし、認証局とデジタル証明書を使用するシステムの間での相互運用性テストと、さらなる標準化が進まない限り、この作業を開始することはできません。この遅れの主な理由は、署名付きメッセージの受信者が、現在、広く信頼された証明書をどのように検証しているかにあります。たとえば TLS プロトコルでは、証明書チェーンを提示するサーバーに接続するクライアントは、サーバーが本物かどうかを判断するために、各証明書に埋め込まれた PQC 署名をすべて検証する必要があります。これらの署名の形式と、証明書の発行・管理プロセスは、 Certificate Authority (CA) Browser Forum によって規定されています。CA Browser Forum のブラウザベンダー企業と証明書発行メンバーは、誰もが TLS セッションで広く信頼された証明書を安全に使えるようにするために、PQC が証明書の発行と検証にどのように機能するかを決定する必要があります。Amazon Trust Services は証明書発行者(訳者注 : 日本では一般に認証局/CAと呼称)であり、CA Browser Forum のメンバーです。私たちは、相互運用性テストを早めるためにこれらの標準の推進に関与しています。 広く信頼された証明書のための PQC の話がまとまりつつありますが、 AWS Private CA サービスは、ML-DSA などの PQC アルゴリズムを使用して、プライベート用の証明書を発行できます。プライベート用の証明書は、CA ブラウザフォーラムが公開するルールに厳密に従う必要がないためです。プライベート証明書を使用するお客様は、クライアントとサーバーの両方のソフトウェアを制御できるため、PQC 認証スキームのクライアントとサーバーの両方を自由に実装できます。ワークストリーム 3 が完了し、AWS KMS で署名操作に ML-DSA が使用可能になると、AWS Private CA はプライベートネットワークで PQC を採用する準備のできたお客様向けに、証明書発行の一部として PQC を提供することを検討します。オープンソースの AWS-LC と s2n ソリューションは、必要に応じてお客様がクライアントとサーバーで PQC 証明書の検証機能を実装するために利用できます。 結論 この投稿では、責任共有モデルにおいて AWS が PQC に移行する方法について説明しました。また、PQC 移行戦略の作成方法と、AWS がその戦略のどの部分を提供するかについてのガイダンスを提供しました。業界が新しい暗号化アルゴリズムへの移行を行う中で、新しい課題と機会が生まれるでしょう。PQC 移行に関する追加情報、ブログ投稿、および定期的な更新については、 AWS Post-Quantum Cryptography ページ を引き続きご覧ください。 AWS のポスト量子暗号について詳しく知りたい場合は、 post-quantum cryptography team にお問い合わせください。 この投稿に関する意見がある場合は、下のコメントセクションにコメントを投稿してください。この投稿に関する質問がある場合は、 AWS Security, Identity, & Compliance re:Post で新しいスレッドを立てるか、 AWS サポートに連絡 してください。 Matthew Campagna Matthew は Amazon Web Services の暗号化の専門家であり、シニア・プリンシパル・エンジニアです。同社全体の暗号化ソリューションの設計とレビューを管理し、ポスト量子暗号への移行を指導しています。余暇には、通勤と睡眠を行っています。 Melanie Goldsborough Melanie は AWS のシニアセキュリティスペシャリストで、20 年以上にわたるインテリジェンスとテクノロジーの経験を持っています。彼女は公的機関を中心としたセキュリティサービスのグローバル販売戦略を立案しています。Melanie の専門分野は、コンテンツ開発、経営層とのエンゲージメント、そして顧客やパートナーの世界規模でのセキュリティ実践の向上に向けたプログラムの実行です。 Peter M. O’Donnell Peter は AWS のプリンシパルソリューションアーキテクト(SA)で、セキュリティ、リスク、コンプライアンス分野の戦略アカウントチームの専門家です。9.5 年間にわたって AWS の SA を務め、データ保護、暗号化、ID 管理、脅威モデリング、コンプライアンス、セキュリティ文化、CISO とのエンゲージメントなどのセキュリティ関連トピックについて、同社の大規模かつ最も複雑な戦略的なお客様のサポートを行っています。 本ブログは Sr. Security Solutions Architect の勝原 達也が翻訳しました。原文は こちら を御覧ください。

この記事は 「 AWS Brings the Power of Generative AI to Ecommerce with the AI Shopping Assistant 」（記事公開日： 2024 年 11 月 26 日）の翻訳記事です。 自宅のリノベーションを計画しているとしましょう。たとえば、新しいデッキを増設したり、地下室を居心地の良い隠れ家に変えたりするといったものかもしれません。 PC を開いて建築資材を注文できるオンライン小売店に行ってみると、何百ものネジ、数十種類の木材、数え切れないほどの選択肢に直面するばかりです。エキサイティングな計画として始まったものが、今では選択肢にあふれたページを無限にスクロールしても、どの商品が自分の計画に最適かわからないので、面倒な作業のように感じます。 PC を閉じようとしたときに、生成 AI を搭載したショッピングアシスタントのアイコンを見つけました。 「デッキを作ろうとしているようですね。 お手伝いしましょうか？」 と訊かれます。数分後、必要なものはすべてショッピングカートに入っています。最初から最後まで正確に最適なものを提案してくれます。 AWS 提供のデモの一つである AI ショッピングアシスタント は、お客様固有のニーズに合わせてカスタマイズされた推奨商品を提示するなど、生成 AI がデジタル空間での案内役としてどのように機能するのかを確認していただけます。 小売業者が顧客向けにパーソナライズされたシームレスな体験を提供できるように設計されたこのアシスタントは、顧客がより迅速かつ自信を持って意思決定を行えるようにします。 AI ショッピングアシスタントは、選択肢を最も関連性の高いものだけに絞り込むことで、悩ましい選択の苦労を軽減して購入へと導き、ショッピングをより満足のいく体験に変えます。 また、小売業者が顧客と関わり、購入を手助けする新しい方法を見出してくれるので、購買意欲と実際の購買行動とを橋渡しします。 「ちょっと立ち寄ってみたくなる」 AI ショッピングアシスタントのいるオンラインショッピングサイト 多くの顧客にとって、適切な商品をすばやく見つけることが、ショッピング体験の成否を左右します。 AI ショッピングアシスタントは、自然言語処理と生成 AI を使用して、デッキに最適なネジの特定や特殊な電子部品の検索など、それぞれの買い物客の特定のニーズに合わせて、パーソナライズされた提案を用意します。AI アシスタントは幅広い商品詳細にアクセスできるので、店舗スタッフが店頭で案内するように、気の遠くなるような迷路のような選択肢を関連性の高いものだけに絞り込み、より魅力的なオンラインショッピング体験を実現します。 他の優れたアシスタントと同様、お薦めの関連商品を提示してリクエストに応えるだけではありません。 この「ちょっと立ち寄ってみる」ことで、プロジェクト固有のツールから補完的な商品まで、顧客は当初考えてもいなかった商品を見つけられるという意外な体験ができます。 こうしたパーソナライズされた提案のおかげで、買い物かごはより多くの商品でいっぱいになり、アップセルやクロスセルの機会を生み出します。これにより、客単価が引き上がると同時に顧客にとってより楽しいショッピング体験を提供することができます。 AI ショッピングアシスタントの仕組み AWS 上に構築された堅牢、かつ柔軟なアーキテクチャに支えられた AI ショッピングアシスタントは、複数の顧客タッチポイントにわたってパーソナライズされた効率的なサービスを提供します。 舞台裏でどのように機能するかを見てみましょう。 ユーザーインタラクションとフロントエンドアクセス : 顧客は Amazon CloudFront でホストされているシームレスなウェブベースのインターフェースを通じて AI アシスタントにアクセスします。 認証が完了すると、顧客は商品を調べては質問をしたり、固有のニーズに合わせてカスタマイズされたガイダンスを受けたりできます。 AppSync によるデータ統合と管理 : GraphQL API 統合レイヤーである AWS AppSync は、AI アシスタントのサービス間のデータフローを調整します。 このレイヤーは、顧客からのクエリの処理、 Amazon Bedrock とのやりとりの管理、 Amazon DynamoDB の更新などを行う AWS Lambda 関数を調整して、レコメンデーションが関連付けられているようにします。 生成 AI とセマンティック検索機能 : Amazon Bedrock はアシスタントの顧客クエリを解釈する能力を強化し、生成 AI を活用して正確な応答を提供します。 Amazon OpenSearch Service にベクトル化されたエントリとして保存された商品カタログデータのおかげで、リアルタイムなセマンティック検索と AI アルゴリズムに適したレコメンデーション提示の両方の機能を実現できるため、ショッピング体験をより楽しいものにします。 対話履歴によるパーソナライズ : Amazon DynamoDB には対話履歴が保存されるため、AI アシスタントは過去のやり取りを思い出し、各顧客のジャーニーや好みに合わせた回答を提供できます。 このアーキテクチャにより、小売業者は E コマースの Web サイトから店舗のキオスクまで、さまざまなプラットフォームに AI ショッピングアシスタントを導入して、進化し続ける顧客のニーズに対応できます。 以下の図は、これらのサービス間の連携の概要を視覚的に示しており、今日の小売需要を満たすアシスタントのスケーラビリティと柔軟性を示しています。 AI ショッピングアシスタントで小売戦略を強化しましょう AI ショッピングアシスタントは、小売業者が顧客と関わったり、サポートする方法を刷新し、オンラインや実店舗を問わず、パーソナライズされた効率的な新しいショッピング体験を提供できるよう支援します。希望に完璧に合った商品へと買い物客をシームレスに誘導し、関連するアドオンを提案し、購入決定までの負担が軽減できることを想像してみてください。これらすべてが、各顧客固有のニーズや好みに合わせたデジタルアシスタントによって実現されます。 次に何が待ち受けているのか、一緒に探求していきましょう。 この AI 主導のソリューションを御社のビジネスに合わせてカスタマイズする 方法 について、当社のチームにご相談ください。 生成 AI が小売戦略をどのように変革しているかについては AWS が re:Invent で発表した「 RCG 204 – Building an AI-powered shopping assistant 」と NRF で発表した NRF 2025 (ブース #5438) が参考になります。 AI ショッピングアシスタントがどのように顧客体験を向上させ、インテリジェントでパーソナライズされた小売の未来を提供することができるのかをご覧ください。 著者について Yuri Chamarelli Yuri Chamarelli は、デンバーオフィスをベースとするアマゾンウェブサービスのシニアスペシャリストソリューションアーキテクト (AWS) です。生成 AI のスペシャリストとして、お客様が AWS を使用して構築し、最先端のソリューションを提供できるよう支援することに注力しています。 Yuri は IoT と機械学習システムで 14 年以上の経験を持つ制御エンジニアです。 また、さまざまな業界の事業変革や事業オートメーションプロジェクトで複数の顧客を支援してきました。 Pat Reilly Pat Reilly は、シアトルオフィスをベースとするアマゾンウェブサービスのシニアスペシャリストソリューションアーキテクト (AWS) です。 生成 AI のスペシャリストとして、15 年以上にわたる機械学習と分析の経験を活かして、お客様が Amazon Bedrock を使用してエージェントワークロードを構築できるよう支援しています。 サッカーが好きな Pat は、休日にはサッカー場にいることが多いです。 本ブログは CI PMO の村田が翻訳しました。原文は こちら 。