AWS Fault Injection Service (FIS) が Amazon Application Recovery Controller (ARC) のゾーンオートシフトのリカバリーアクションをサポートするようになった ことをお知らせいたします。この統合により、障害を注入するイベントの作成とゾーンオートシフトのトリガーを同一実験内で行えるようになり、より包括的なテストが可能になりました。これにより、アベイラビリティーゾーン (AZ) の障害時にアプリケーションがどのように動作するかを観察できます。 アプリケーションを複数の AZ にデプロイすることは、AWS で可用性の高いアプリケーションを構築するための重要な戦略です。各 AZ は 障害分離境界 として機能し、デプロイ、ネットワークの問題、停電、人的ミスなどの障害は、その特定のゾーン内に封じ込められ、システム全体には影響を与えません。このマルチ AZ アプローチにより、1 つの AZ で問題が発生しても、アプリケーションは利用可能な状態を維持でき、より信頼性が高く、耐障害性のあるものとなります。 ゾーンシフトとゾーンオートシフト AZ に障害が発生した場合、 ゾーンシフト を復旧メカニズムとして使用し、AWS リージョン内の障害が発生した AZ から同じリージョン内の正常な AZ にトラフィックを移動させることができます。これにより障害を分離し、アプリケーションが別の AZ で顧客にサービスを提供し続けることができます。この機能をさらに強化するため、 ARC がサポートするリソースのリスト を拡張し、 Amazon EC2 Auto Scaling グループ 、 Amazon Elastic Kubernetes Service 、そしてクロスゾーンロードバランシングが有効または無効な Application Load Balancer および Network Load Balancer が含まれるようになりました。 ARC の ゾーンオートシフト は、復旧時間の最小化に役立ちます。AWS は、内部モニタリングシステムが顧客に影響する可能性のある AZ 障害を検出した場合、自動的にオートシフトを開始します。オートシフトは、ゾーンオートシフト用に設定された AWS リソースのトラフィックを、影響を受けたゾーンから一時的に移動させます。問題が解決すると、トラフィックは再びすべての AZ に分散されます。 AWS FIS AZ の可用性：電源の中断 お客様は、 AWS FIS を使用して、AZ 内のリソースと AWS サービスに障害を発生させることで、アプリケーションが AZ レベルのイベントにどのように応答するかを検証してきました。 AZ 可用性：電源の中断シナリオ は、複数の FIS アクションを組み合わせることで、AZ での完全な電源中断で予想される多くの症状を作り出します。このシナリオでは、単一の AZ 内の特定のリソースセットに対して、ゾーンのコンピューティングリソース (Amazon EC2、EKS、ECS) の停止、AZ 内でのコンピュートのスケーリングの禁止、サブネット接続の損失、 Amazon Relational Database Service (RDS) のフェイルオーバー、 Amazon ElastiCache のフェイルオーバー、 Amazon Elastic Block Store ボリュームの無応答化を引き起こすことで、一時的に「電源を切る」状態を作り出します。 AZ 中断のテストにおける一般的な落とし穴は、ネットワーク接続のブロックのみに焦点を当てることです。しかし、この方法はお客様が管理するネットワーク内のリソースにのみ影響を与えるにとどまり、ネットワーク構成とは独立して動作する AWS マネージドサービスには影響を与えません。FIS AZ シナリオは、リソースと AWS マネージドサービスの両方に対する中断をシミュレートすることで、より包括的なテストソリューションを提供します。 AZ の可用性：電源の中断シナリオは、アプリケーションの耐障害性をテストし改善するための大きな利点を提供します。このシナリオでは、マルチ AZ アプリケーションが実際の障害発生時にどのように動作するかを観察できます。この管理された実験を実行することで、アーキテクチャ、監視システム、運用手順における潜在的な弱点を発見できます。これにより、アプリケーションの耐障害性と全体的な信頼性が向上し、復旧時間の短縮が可能になり、災害復旧計画のコンプライアンス要件にも対応できます。 AWS FIS とゾーンオートシフトを組み合わせる 復旧戦略において重要な側面は、テストを行う能力です。ビジネスニーズに合わせてシステムがより急速に進化するクラウドでは、レジリエンステストが特に重要です。また、手順の有効性確認、チームの対応準備状況の評価、パフォーマンス指標の検証、潜在的な問題の特定にも役立ちます。 そのため、AZ の可用性：電源の中断シナリオが、ゾーンオートシフトとどのように連携するかをご紹介できることを嬉しく思います。これらの機能を組み合わせることで、障害発生時の AWS の動作をテストできるようになりました。つまり、影響を受けた AZ からトラフィックを自動的に移す動作を確認できます。この統合されたテストアプローチにより、AZ でのインフラストラクチャに障害が発生した際にアプリケーションがどのように動作するかをより包括的に把握できます。 ゾーンオートシフトのための AWS FIS 復旧アクション 今回のリリースでは、最初の 復旧アクション とともに、AWS FIS アクションの新しいカテゴリを導入しました。新しい AWS FIS 復旧アクションにより、ゾーンオートシフトを有効にしているお客様は、FIS AZ の可用性：電源の中断シナリオを実行して、AZ での完全な電源中断の想定される状態を再現し、実際の障害時に AWS がどのようにゾーンオートシフトを起動するかを実証できます。また、単純に正常な AZ からトラフィックを移すだけでは発見できない問題も発見できます。つまり、実際に AZ が使用不能になった時に初めて表面化するアプリケーションの隠れた依存関係がわかります。 復旧アクションを含む AWS FIS 実験テンプレートの作成 AWS FIS を使用してゾーンオートシフトをテストする 方法を見てみましょう。この記事では新しい統合機能について説明します。AZ の可用性：電源の中断シナリオを使用した実験を作成したことがない場合は、 AWS Fault Injection Service シナリオライブラリでカオスエンジニアリングを始めるための基礎 で、セットアップ方法の詳細な手順を参照してください。 開始するには、AWS FIS シナリオライブラリから AZ の可用性：電源の中断 シナリオを選択して、実験テンプレートを作成します。 アクションとターゲットを指定 の下に、ゾーンオートシフトが追加されているのが確認できます。下部には、新しいリカバリーアクション Start-ARC-Zonal-Autoshift とそのターゲット ARC-Managed-Resources が表示されています。 ゾーンオートシフトアクションの設定を見てみましょう。 アクションタイプ: ここでは、 aws:arc:start-zonal-autoshift アクションとともに、新しい ARC アクションタイプが表示されます。 次のあと開始: アクションは、実験開始後 5 分間待機するように FIS-Wait アクションで設定されており、イベント発生から一定時間が経過した状況をシミュレートしてからゾーンオートシフトを開始します。実際のイベントでは、症状が始まってから数分後にオートシフトがトリガーされることが予想されます。 ターゲット:   ARC-Managed-Resources という名前のターゲットが自動的に作成され、対象となるリソースを定義します。 Availability Zone identifier:  ゾーンオートシフトでトラフィックを移動させる AZ を選択します。また、 共有パラメータを編集 を使用することで、実験内のすべてのアクションに対して一貫した値で共有パラメータを設定できます。 Duration: 時間の値は、実験内の他のアクションが終了してトラフィックの移行を開始するタイミングと同時に、ゾーンオートシフトが終了するように設定されます。期間は、上記で説明したゾーンオートシフトをトリガーする前の 5 分間の待機時間を考慮して、 [ 障害継続時間 - 5 minutes] に設定されます。たとえば、実験の停止時間が 30 分の場合、ゾーンオートシフトの期間は 25 分に設定されます。 ARC-Managed-Resources ターゲット設定では、ゾーンオートシフトに含めるリソースを定義できます。デフォルトでは、アカウント内でゾーンオートシフトが有効化されている、サポート対象の AWS リソースが含まれます。これらのリソースは、 ゾーンシフトへオプトインされている 必要があります。 ターゲットメソッド:  デフォルトでは、 リソースタグ、フィルター、パラメータ オプションが選択されます。 リソースタグ: デフォルトでは、キー名が AzImpairmentPower 、キー値が RecoverAutoshiftResources のリソースタグが作成されます。これらのリソースタグを、実験対象とするゾーンオートシフト対応リソースに設定できます。 これまでの設定オプションは、他の FIS アクションと同様です。 aws:arc:start-zonal-autoshift アクションの新機能として、 リソースパラメータ が追加され、ターゲットとするリソースについてより柔軟な設定が可能になりました。 この新しいパラメータ群は、 ターゲットメソッド (リソース ID やリソースタグなど) に加えて、リソースを対象とするための Managed resource types と Zonal autoshift status を提供します。 Managed resource types: ゾーンオートシフトをサポートするリソース (Auto Scaling グループ、Application Load Balancer、Network Load Balancer、および/または EKS クラスター) から、ターゲットとするものを 1 つ以上選択します。 Zonal autoshift status: 対象とする管理対象リソースタイプは、ゾーンオートシフトが Enabled 、 Disabled 、またはその両方の状態にすることができます。デフォルトでは、 Enabled が事前に選択されています。このパラメータを Disabled に設定すると、ゾーンオートシフトは無効だがゾーンシフトにオプトインしているリソースを対象とすることができます。これにより、ゾーンオートシフトを有効にする前にアプリケーションの動作を事前に確認することができます。 FIS リカバリーアクション の詳細については、 AWS Fault Injection Service ユーザーガイド を参照してください。 料金と利用可能地域 AWS FIS は、使用した分だけ料金が発生します。前払い費用や最低料金はありません。アクションの実行時間と実験に含まれるアカウント数に基づいて課金されます。料金の詳細については、 FIS の料金ページ をご覧ください。 ゾーンオートシフトの使用自体に追加料金はかかりませんが、AZ からの切り替え時に追加のトラフィックを処理するために、複数のアベイラビリティーゾーンでリソースを事前にスケーリングするための追加コストや、 CloudWatch 、 データ転送 などの関連コストを考慮する必要があります。 FIS のリカバリーアクションは、FIS とゾーンオートシフトが利用可能なすべての AWS リージョンで利用できます。FIS が利用可能な AWS リージョンのリストについては、 FIS サービスエンドポイント をご覧ください。ゾーンオートシフトが利用可能なリージョンのリストについては、 ゾーンオートシフトの AWS リージョン提供状況 をご覧ください。 まとめ AWS Fault Injection Service の AZ の可用性: 電源の中断シナリオと ARC のゾーンオートシフトを組み合わせることで、AZ 障害に対するテストと復旧メカニズムの検証を同時に実行できます。この組み合わせたテストアプローチにより、インフラストラクチャの中断時におけるアプリケーションの動作をより包括的に評価できます。 AWS Fault Injection Service と ARC ゾーンオートシフト を使用して、アプリケーションのレジリエンステストを今すぐ始めましょう。本番環境に展開する前に、非本番ワークロードで小規模なテストから開始できます。 実践的な演習として、 AWS Fault Injection Service シナリオライブラリでカオスエンジニアリングの旅を始める というステップバイステップのガイドを試して、最初の実験をセットアップしてみてください。 耐障害性を維持し、テストを継続しましょう！ Daniel Cil Daniel Cil は南カリフォルニアを拠点とするシニアレジリエンススペシャリストソリューションアーキテクトです。AWS の業界別および戦略的なお客様が AWS クラウド上のワークロードに対して、耐障害性のあるアーキテクチャを設計し、レジリエンスのベストプラクティスを実装できるよう支援しています。 翻訳はソリューションアーキテクト 渡部 拓実 が担当しました。原文は こちら です。

本稿は、JFE 条鋼株式会社による AWS 移行の取り組みについて、主導された JFE 条鋼株式会社 神庭 公一様、JFE システムズ株式会社 齋藤 誠様、株式会社エクサ 中西 広行様より寄稿いただきました。 はじめに JFE 条鋼株式会社 (以下、JFE 条鋼) は、鉄鋼製品の中でも主に形鋼と鉄筋棒鋼を製造、販売する電炉メーカーです。電気炉を使用して鉄スクラップを主原料とした製品を製造する電炉業界は、資源リサイクルの担い手として持続可能な循環型社会に貢献する重要な役割を担っています。同社は、この精錬技術を活かした資源リサイクル事業も中核事業として展開しています。 電炉業界は、原材料となるスクラップ価格が短期間で変動する厳しい環境下において、競争力の維持・強化が求められています。このような状況下で操業効率化が急務となる中、データサイエンスの活用を検討しましたが、従来のオンプレミス環境では多額の初期投資が必要で、システムリソースの柔軟な拡張も困難でした。さらに、主要なサーバのメーカー保守終了が迫っており、システム基盤の見直しが必要な時期を迎えていました。 このような事業環境の中で、JFE 条鋼は、デジタルトランスフォーメーション (DX) による業務効率化と高度化を推進する方針を決定しました。特に、2035 年以降に予測される労働人口の大幅な減少を見据え、データドリブンで高頻度かつ自動的・自律的な業務プロセスを実現できる基盤が必要でした。そこで、最新のデータ分析サービスや機械学習機能を柔軟に活用でき、高度なデータ処理基盤を迅速に構築できる AWS への移行を選択しました。 プロジェクト体制とアプローチ このような課題認識のもと、AWS 環境構築、ネットワーク設計、アプリケーション移行など、多岐にわたる専門性が求められるプロジェクトを成功させるため、それぞれの強みを持つ 3 社での協業体制を構築しました。事業会社として JFE 条鋼は業務要件を熟知していることから全体統括と要件定義を担当し、基盤とネットワークについては AWS 環境構築の豊富な実績を持つ 株式会社エクサが基盤設計と SASE の導入を担当しました。また長年、基幹系業務システムの維持管理・保守を担当しており、当社環境を熟知している JFE システムズ株式会社が、その知見を活かしてアプリケーション移行と運用設計を担当しました。さらに、鉄鋼業に深い知見を持つ AWS の営業担当者とソリューション・アーキテクトが継続的にサポートし、当社の課題認識や取り組みの方向性を十分に理解した上で、適切な技術支援を提供したこともプロジェクトをスムーズに進められた要因となりました。 システム基盤のアーキテクチャ AWS 環境を長期的に運用していくためには、まず適切なガバナンス体制の確立が不可欠です。そこで、システム基盤の構築にあたり、最初のステップとして AWS Control Tower を採用しました。これにより、複数の AWS アカウントを一元的に管理し、セキュリティとコンプライアンスの基準を組織全体で統一的に適用できる環境を整えました。さらに、生産管理システムなどの基幹業務システムと、データサイエンス環境を明確に分離し、それぞれの特性に応じたセキュリティポリシーとガードレールを設定しました。基幹システムではセキュリティとガバナンスを重視した厳格な制御を行う一方、データサイエンス環境では分析業務に必要な柔軟性を確保し、セキュリティを担保しながらデータ活用促進を実現しました。 また、ネットワークについては SD-WAN (Software-Defined Wide Area Network) の導入により、拠点間通信の冗長化とインターネットアクセスの最適化を行いました。その結果、従来の専用線による接続と比較して、より柔軟で効率的なネットワーク構成となりました。 図 1 マルチアカウント基盤アーキテクチャ図 生産管理システムの移行 第一弾として 1 つの製造所の生産管理システムの移行を実施しました。そこでは、システムの可用性を確保するため複数の対策を講じました。 まず、アプリケーションサーバーについては、既存アプリケーションの特性を考慮し障害発生時にはスナップショットからの復旧とする構成を採用しました。また、データベースについては Amazon RDS のマルチ AZ 構成を採用し、障害発生時の自動フェイルオーバーを可能としました。 次に、BCP (事業継続計画) 対策として東京と大阪のリージョン間でのバックアップと定期的なデータ同期の仕組みを構築しました。AWS Backup を活用し、EC2 や RDS のスナップショットを日次で取得しリージョンをまたがって保管することで、広域災害にも対応可能な構成としました。 図 2 生産管理システムアーキテクチャ図 データ活用基盤の確立 JFE 条鋼では、AWS 移行を機にデータ活用の基盤を刷新し、製造現場のデータをリアルタイムで収集、分析し、業務改善に活用する環境を整備しています。 FA と IT の連携を実現するオープンなエッジコンピューティング基盤 EdgeCross を採用し、各製造設備からのデータを収集しています。収集したデータは、時系列データに最適化された Amazon Timestream に格納し、大規模な製造設備データの効率的な管理と高速な分析を行っています。これにより、製造プロセスの詳細な時系列分析や、設備の稼働状況のリアルタイムモニタリングなど、時間軸に沿った多様なデータ活用が可能となっております。 さらに、可視化基盤として Amazon QuickSight を採用し、製造ラインの稼働状況や KPI のリアルタイムモニタリングを行っています。このような取り組みにより、現場のオペレータから管理者まで必要な情報をタイムリーに確認できる環境を構築しました。 図 3 データ活用基盤アーキテクチャ図 得られた効果と今後の展望 生産管理システムの AWS 移行により、まずハードウェアの運用から解放され、システムの可用性も向上しました。特に、マルチ AZ 構成の採用やバックアップの自動化により、システムの信頼性が向上しました。また、データ活用の面では製造現場のデータをリアルタイムで分析し、業務改善に活用できる環境が整いました。 今後は、これらの基盤を活用し収集したデータを活用した予知保全や品質向上など、より高度なデジタル化を推進します。特に注力するのがプロセス全体の高速化です。従来の日次バッチ処理的な業務プロセスから脱却し、データ処理の高速化・高頻度化を進めます。これにより、サプライチェーンの変化や操業状況の変化にリアルタイムで対応できる体制を目指します。 また、操業により近い業務システムへの展開も段階的に進めます。まずは集計的な機能から着手し、実績を確認しながらより操業に近い領域へと範囲を拡大する計画です。現行システムと新システムが併存する中で、データの連携方式やユーザーインターフェース、運用方式の一貫性確保など、想定される課題に対しては AWS の機能を最大限活用して解決を図ります。 このような業務プロセスの改革とデータ処理の高度化を相互に連携させ、スパイラル的な進化を図ります。 まとめ このように、当社は AWS 移行プロジェクトを通じて、システム基盤の近代化と業務プロセスの革新を進めています。AWS を活用しセキュリティと利便性を両立する環境を構築し、生産管理システムの安定稼働とデータ活用基盤の整備を行いました。これにより、データドリブンな業務プロセスの基盤が整いました。 今後は、これらの基盤をさらに発展させ、予知保全や品質向上に向けたデータ分析を深化させ、データ処理の高速化・高頻度化を進めます。従来の日次バッチ処理的なプロセスから脱却し、よりリアルタイムな対応を可能とする業務プロセスへと進化させます。最終的には、人間の役割を「オペレーター」から「デザイナー」へと進化させ、より創造的な業務への転換を図ることで、持続可能な企業成長を実現します。 執筆者 神庭公一 JFE 条鋼株式会社 業務イノベーション推進部業務改革グループマネージャー 大学学部卒業後、鉄鋼会社にて生産管理、営業（輸出・国内）の業務の後、システム部門へ。2013年度に現会社に出向・移籍し、現在に至る。社内業務システムとそのインフラに関する企画・構築・運用全般を担当。 斎藤誠 JFE システムズ株式会社 産業ソリューション事業本部 鉄鋼関連事業部 関連企業第2開発部第3グループ 大学院卒業後、JFE システムズに入社。以降、JFE 条鋼担当システムエンジニアとして、業務システム開発、オンプレミスサーバの設計・構築を担当。2023 年から基幹業務システムの AWS リフトプロジェクトをリーダとして推進 中西広行 株式会社エクサ 基盤システム本部 基盤ソリューション部　第 ２ ソリューション室 大学卒業後、株式会社エクサに入社。以降、セキュリティソリューション、および、クラウドエンジニアとして、システム基盤の設計構築を担当。2023 年より、JFE 条鋼様 AWS マルチアカウント環境の構築運用、および、SASE 導入プロジェクトをリーダーとして推進

「Amazon Q CLI でゲームを作ろう」キャンペーンは、AIコーディングアシスタントを実際に体験し、 Amazon Q CLI を使って自分のペースで新しいゲームを作り出すための創造性と想像力を発揮する機会です。この学習機会は 2025 年 5 月 20 日から 6 月 20 日まで実施され、アジア太平洋、日本、中国地域の参加者のみが T シャツを獲得できます（対象国のリストは下記に記載）。 T シャツを獲得するために必要なステップは以下の通りです： 1: Amazon Q CLI を使ってゲームを作ろう 2: あなたが何をどのように作ったかについてブログを書くか、あなたの体験についての動画を録画して、ソーシャルメディアに投稿しよう 3: Amazon Q ブランドの T シャツをゲットしよう ステップバイステップガイド Step 1 : AWS Builder ID に登録し、 このリンク から独自の community.aws ユーザー名を取得してください。サポートが必要な場合や他の参加者とネットワークを構築したい場合は、 このリンク から Discord サーバーに参加してください。 Step 2 : Amazon Q CLI をマシンにインストールしてください。Ricardo Sueiras による Linux と Windows へのインストール方法ガイドがあります。また、 PyGame または他のゲームライブラリをラップトップにインストールしてください。 Step 3 : Amazon Q CLI とのチャットセッションを開始し、チャット内のプロンプトだけでゲームを作成しましょう。Amazon Q CLI の可能性を探るため、できるだけ革新的なゲームを作ってみてください。 Step 4 : 作成したものについてブログを書くか、ビデオを作成してください。ハッシュタグ #AmazonQCLI を付けて SNS で公開投稿をしてください。地域言語 (例 : 日本語) での投稿も歓迎します。オプションとして、コードを GitHub リポジトリにホストすることもできます。 Step 5 : Tシャツ 獲得フォーム に記入してください。 注：中国語、日本語、韓国語など、あなたの話す言語でゲームを作成できます。 始めるためのインスピレーションが必要ですか？ Derek Bingham（AWS シニアデベロッパーアドボケイト） が週末に息子と一緒に Amazon Q CLI を使ってゲームを作った ブログ や、 Haowen Huang（香港 シニアデベロッパーアドボケイト） による Amazon Q CLI を利用した Vibe Coding でゲームを作った ブログ をご覧ください。 Amazon Q CLI 関連の今後のAWSユーザーグループミーティングについては、近日中に更新されます。 この活動を楽しみ、新しいことを学び、プロセスを楽しんでいただければ幸いです。 どのようなクールなゲームが作られるか楽しみにしています。 Amazon Q CLI についてのフィードバックは、Discord のフィードバックチャンネルでお知らせください。 追加リソース Amazon Q CLI セルフサービスワークショップ 規約 AWS は、不完全、不正、または重複したエントリーを失格とする権利を有します。 プライバシー – 参加者情報は、景品の提供とプログラム分析の目的でのみ使用されます。 AWS は、予告なしにいつでもキャンペーンをキャンセル、変更、または中断する権利を有します。 景品は譲渡できず、現金価値はありません。 よくある質問 Tシャツを獲得できる対象国はどこですか？ : オーストラリア、バングラデシュ、ブータン、ブルネイ、カンボジア、中国、フィジー、香港、インド、インドネシア、日本、ラオス、マレーシア、モルディブ、ミャンマー、ネパール、ニュージーランド、パキスタン、パプアニューギニア、フィリピン、シンガポール、韓国、スリランカ、台湾、タイ、ベトナム 以前は APAC 地域にいましたが、別の地域に移動しました。T シャツをもらえますか？ : 残念ながら、いいえ。 T シャツはいつ届きますか？ : T シャツは毎週金曜日に発送が開始されますが、物流準備のため、その週の水曜日までに提出された応募のみが対象となります。 送料は支払いますか？ : いいえ。送料と税金は当社が負担します。一部の国では、配送が困難であったり、追加の通関料金が発生したり、税関に連絡する必要がある場合があります。そのような場合は、通関のために税関に連絡し、料金を負担する必要があります。 複数の応募に対して複数の T シャツをもらえますか？ : 参加者 1 人につき 1 枚の T シャツのみです。 Amazon の従業員は参加できますか？ : キャンペーンに直接関わる主催者または関連会社の従業員は参加資格がありません。 本記事は「 Build Games with Amazon Q CLI and score a T shirt  」を翻訳したものです。

Anthropic は 5 月 22 日、次世代の Claude モデルである Opus 4 と Sonnet 4 をリリースしました。コーディング、高度な推論、次世代の有能な自律型 AI エージェントのサポートを目的として設計されたモデルです。どちらのモデルも Amazon Bedrock で一般提供を開始しました。開発者はモデルの高度な推論機能とエージェント機能の両方にすぐにアクセスできるようになりました。 Amazon Bedrock は Anthropic の最先端モデルで AI の選択肢を広げ、 エンタープライズグレードのセキュリティ と 責任ある AI 管理を備えた革新的なアプリケーションの自由な構築を実現します。どちらのモデルも、タスクプランニング、ツールの使用、エージェントの操作性を向上させることで、AI システムの可能性を拡張しています。 Opus 4 の高度なインテリジェンスを使用すると、大規模なコードベースのリファクタリング、リサーチの統合、部門を超えたエンタープライズオペレーションの調整など、長時間実行されるコンテキストの多いタスクを処理するエージェントを構築できます。Sonnet 4 は大規模な効率化に向けて最適化されているため、サブエージェントとして、またはコードレビュー、バグ修正、本番グレードのコンテンツ生成などの大量のタスクに適しています。 生成 AI を使用して構築する場合、多くの開発者は長期的なタスクに取り組みます。多くの場合、これらのワークフローには多段階のプロセス、大規模なコンテキスト全体の計画、長期にわたる多様なインプットの統合など、深く持続的な推論が必要となります。これらのワークフローのいい例として、大規模プロジェクトのリファクタリングやトランスフォーメーションを支援するデベロッパー AI エージェント があります。既存のモデルでも迅速かつ問題なく対応できるかもしれませんが、特にコーディング、調査、エンタープライズワークフローなどの分野では、一貫性とコンテキストを長期にわたって維持することは依然として困難な場合があります。 Claude Opus 4 Claude Opus 4 は、Anthropic の最も高度なモデルであり、最小限の監視で複雑なタスクを推論、計画、実行できる高度な AI エージェントを構築できるように設計されています。Anthropic ベンチマークでは、これが現代の市場で入手可能なコーディングモデルのうち、最良であることが示されています。これは、コンテキストの拡張、深い推論、適応型の実行が不可欠なソフトウェア開発シナリオに優れています。開発者は Opus 4 を使用して、プロジェクト全体でのコードの記述やリファクタリング、フルスタックアーキテクチャの管理、大まかな目標を実行可能なステップに分割するエージェントシステムの設計を行うことができます。 SWE-bench や TAU-bench などの エージェント中心のベンチマークやコーディングで優れたパフォーマンスを発揮する ため、多段階の開発ワークフローを処理するエージェントを構築する場合、自然な選択肢となります。例えば、Opus 4 は、プロセス全体を通して要件とアーキテクチャコンテキストを追跡しながら、技術文書の分析、ソフトウェア実装の計画、必要なコードの記述、反復的な改良を行うことができます。 Claude Sonnet 4 Claude Sonnet 4 は、パフォーマンス、応答性、コストのバランスを取ることで Opus 4 を補完するもので、大量生産ワークロードに適しています。コードレビューの強化、バグ修正の実装、即時のフィードバックループを使用した新機能開発など、日常的な開発タスク向けに最適化されており、パフォーマンスが向上しています。また、ほぼリアルタイムのアプリケーション向けの本番環境対応の AI アシスタントにも活用できます。Sonnet 4 は、Claude Sonnet 3.7 のドロップイン代替品です。マルチエージェントシステムでは、Sonnet 4 はタスク固有のサブエージェントとしてうまく機能します。対象を絞ったコードレビュー、検索と検索、またはより広範なパイプライン内での個別の機能開発などの処理を行うことができます。また、Sonnet 4 を使用すれば、高いスループットおよび開発者に合わせたアウトプットを維持しながら、継続的インテグレーションとデリバリー (CI/CD) パイプラインの管理、バグのトリアージの実行、API の統合などを実行できます。 Opus 4 と Sonnet 4 は、ほぼ瞬時の応答と、より深い推論のための拡張思考という 2 つのモードを備えたハイブリッド推論モデルです。インタラクティブなアプリケーションでは、ほぼ即時の応答を選択することができます。また、リクエストにおいてより詳細な分析と計画が必要になる場合は、拡張思考を有効にできます。思考は、ソフトウェアエンジニアリング、数学、科学研究などの分野での長期にわたる推論タスクに特に役立ちます。最大トークン数を設定するなどしてモデルの思考予算を設定することで、レイテンシーと回答深度の間のトレードオフをワークロードに合わせて調整できます。 開始方法 Opus 4 または Sonnet 4 の動作を確認するには、AWS アカウントで 新しいモデルを有効化 します。その後、Opus 4 のモデル ID anthropic.claude-opus-4-20250514-v1:0 と Sonnet 4 のモデル ID anthropic.claude-sonnet-4-20250514-v1:0 で Bedrock Converse API を使用して、コーディングを開始できます。メッセージをサポートするすべての Amazon Bedrock モデルで機能する、一貫した API が提供されるため、Converse API の使用をお勧めします。つまり、一度コードを書いたら、そのコードをさまざまなモデルで使用できるということです。 例えば、コードリポジトリの変更をマージする前にコードをレビューするエージェントを記述したとします。 Bedrock Converse API を使用してシステムプロンプトとユーザープロンプトを送信する、次のコードを記述します。次に、エージェントはストリーミングされた結果を消費します。 private let modelId = "us.anthropic.claude-sonnet-4-20250514-v1:0" // Claude に応答方法を指示するシステムプロンプトを定義します let systemPrompt = """ あなたは Swift、特に Swift 6 の同時実行に関する深い専門知識を持つシニア iOS デベロッパーだとします。あなたの仕事は、並行処理に関連するエッジケース、潜在的な競合状態、Task、TaskGroup、Sendable、@MainActor、@preconcurrency などの Swift 同時実行プリミティブの誤用の特定に焦点を当てたコードレビューを行うことです。 コードを注意深く見直し、同時実行環境で予期しない動作を引き起こす可能性のあるパターンやロジックにフラグを立てる必要があります。例えば、適切な分離なしに共有可変状態にアクセスすること、アクターの誤用、同時実行の境界を越える非 Sendable 型などです。 正確な技術用語を用いて理由を説明し、安全性、予測可能性、正確性を向上させるための推奨事項を提示してください。必要に応じて、慣用的な Swift 6 を使用して具体的なコード変更やリファクタリングを提案してください """ let system: BedrockRuntimeClientTypes.SystemContentBlock = .text(systemPrompt) // テキストプロンプトと画像を含むユーザーメッセージを作成します let userPrompt = """ 次の Swift コードで同時実行の問題がないか確認してください。 うまくいかない可能性があること、およびその修正方法を教えてください。 """ let prompt: BedrockRuntimeClientTypes.ContentBlock = .text(userPrompt) // テキストと画像の両方のコンテンツを含むユーザーメッセージを作成します let userMessage = BedrockRuntimeClientTypes.Message( content: [prompt], role: .user ) // ユーザーメッセージでメッセージ配列を初期化します var messages: [BedrockRuntimeClientTypes.Message] = [] messages.append(userMessage) // 推論パラメータを設定します let inferenceConfig: BedrockRuntimeClientTypes.InferenceConfiguration = .init(maxTokens: 4096, temperature: 0.0) // ストリーミングを使用して Converse API の入力を作成します let input = ConverseStreamInput(inferenceConfig: inferenceConfig, messages: messages, modelId: modelId, system: [system]) // ストリーミングリクエストを実行します do { // ストリームを処理します let response = try await bedrockClient.converseStream(input: input) // ストリームイベントをイテレーションします for try await event in stream { switch event { case .messagestart: print("AI-assistant started to stream"") case let .contentblockdelta(deltaEvent): // テキストコンテンツが到達したら処理します if case let .text(text) = deltaEvent.delta { self.streamedResponse + = text print(text, termination: "") } case .messagestop: print("\n\nStream ended") // ストリーミングされた応答から完全なアシスタントメッセージを作成します let assistantMessage = BedrockRuntimeClientTypes.Message( content: [.text(self.streamedResponse)], role: .assistant ) messages.append(assistantMessage) default: break } } 同僚の Dennis は、皆さんがすぐに使用を開始できるように、複数のユースケースとさまざまなプログラミング言語に対応する 幅広いコード例 をご用意しています。 Amazon Bedrock で今すぐご利用いただけます このリリースにより、開発者はフルマネージド型のサーバーレスサービスである Amazon Bedrock で、Anthropic が開発した次世代の Claude モデルにすぐにアクセスできるようになります。既に Amazon Bedrock で Claude を使用して構築している方でも、使用を開始したばかりの方も、このシームレスなアクセスにより、インフラストラクチャや複雑な統合を管理することなく、最先端の基盤モデルを使用した実験、プロトタイプ作成、拡張を迅速に実行できます。 Claude Opus 4 は、北米の米国東部 (オハイオ、バージニア北部) と米国西部 (オレゴン) の AWS リージョン でご利用いただけます。Claude Sonnet 4 は、北米の AWS リージョンだけでなく、APAC、欧州 (米国東部 (オハイオ、バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (ハイデラバード、ムンバイ、大阪、ソウル、シンガポール、シドニー、東京)、欧州 (スペイン)) でもご利用いただけます。 クロスリージョン推論 を通じて 2 つのモデルにアクセスできます。クロスリージョン推論は、地域内の最適な AWS リージョンを自動的に選択して、推論リクエストを処理するのに役立ちます。 Opus 4 を使用すると、最も困難な開発タスクに取り組むことができます。一方、Sonnet 4 はスピードと機能の最適なバランスを備え、ルーチンワークに優れています。 料金 と Amazon Bedrock でのこれらの新しいモデルの使用方法 について、今すぐご確認ください。 – seb 原文は こちら です。

このブログは 2024 年 5 月 16 日に Josh Hart, Kim Banga, Thomas Moore によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 アプリケーションはログファイルを生成し、アドホックレポート、コンプライアンス、または監査の目的で確実に保存する必要があります。時間が経つにつれて、このような比較的小さなログファイルのコレクションの量が増え、費用対効果の高いストレージとデータ管理が重要になります。これらのファイル内のデータにアクセスしてクエリを実行することも、データから洞察を得るのに役立ちます。 イベントログを生成するサービスの例としては、 AWS CloudTrail があります。CloudTrail は AWS アカウント内の API 呼び出しとユーザーアクティビティを追跡します。これらのログファイルは、セキュリティ監視、変更追跡、トラブルシューティングに役立ちます。ただし、CloudTrail のログは Amazon S3 バケットに個別のファイルとして保存され、各ファイルのサイズは通常 128 KB 未満です。CloudTrail のログファイルの数は、数週間、数か月にわたるアクティビティによって数千または数百万に増え、それに比例してストレージコストも上昇します。Amazon S3 では、ストレージコストを削減するために Amazon S3 標準 – 低頻度アクセス（ S3 Standard-IA ） や S3 Glacier Instant Retrieval などのストレージクラスを提供していますが、 請求可能な最小オブジェクトサイズは 128 KB で、オブジェクトごとの Amazon S3 ライフサイクル 移行料金がかかります。 S3 Intelligent-Tiering では、 128 KB 未満のオブジェクトを保存できますが、常に高頻度アクセス階層の料金が課金されます。また、大量の小さなファイルを低頻度アクセス階層に移行することには、多大なコストがかかる可能性があります。 本投稿では、 AWS Step Functions を使用して、小さなファイルの大規模なコレクションをより少ない大きなオブジェクトにコンパクション（または結合）するパターンについて説明します。コンパクションは、圧縮などのアーカイブ重視のソリューションに代わる、クエリに適した選択肢を提供します。また、S3 ライフサイクル移行コストを削減することで、アーカイブにも役立ちます（アーカイブ用のコンパクションに焦点を当てた s3tar や Java ベース のソリューションを参照）。さらに、多くの小さなオブジェクトをまとめてコンパクションすることで、128 KB の最小課金サイズを超えるほど大きくなります。加えて、アドホッククエリのパフォーマンスが向上し、既存のコードやツールを変更することなく、クエリをその場で実行できます。 コンパクションとアーカイブの比較 コンパクションという用語は、ファイルの形式や構造を変更せずに、複数のファイルを連結、集約、またはその他の方法で1つの大きなファイルにまとめることを指します。これは、アーカイブファイル形式（.zip や .tar など）を使用してデータを保存するアーカイブとは区別されます。 コンパクションとアーカイブのどちらを選択するかは相互に排他的ではありません。 要件やアクセスパターンに基づいて、圧縮されたデータをコンパクションしたり（例： gzip を使用）、コンパクションされたデータをアーカイブ用に圧縮したりすることができます。 コンパクション（集約）：データの分析的価値を維持し、クエリのパフォーマンスを向上させます。頻繁にデータのクエリや分析を行う必要がある場合に有益です。小さなファイルをより少数の大きなオブジェクトに統合し、その場でより効率的にクエリを実行できるようにします。これらの大きなオブジェクトが Amazon S3 のストレージコストをどのように削減できるかを実証します。コンパクションは、結合されるオブジェクトが意味的に同等である場合に最も効果的です。例えば、ログエントリのストリームや個別の JSON ラインは、ファイル構造を変更せずに集約できます。ただし、オブジェクトキーやメタデータに保存されている詳細情報は失われることに注意してください。集約は S3 ライフサイクルを通じた移行リクエストを減らすことができ、アーカイブに役立ちます。 アーカイブ：クエリの頻度が低い、またはクエリが不要な場合の長期保存に適しています。コンパクションをおこなうことによってさらにコストを最適化できる可能性があります。ファイルごとの JSON オブジェクトや異種のファイルタイプなど、ファイルに包括的な構造がある場合、アーカイブがより適しています。アーカイブ形式は、ディレクトリ構造や元のファイルに関するメタデータも保存できます。 ここで紹介するコンパクション方法は、軽量のサーバーレスパターンを使用してファイルの連結を調整します。 結果として得られる集約ファイルは、その場でクエリ可能な状態を維持します。これにより、データの分析的価値を保持しながら、ストレージコストを最適化し、クエリパフォーマンスを向上させることで、より費用対効果が高く迅速に洞察を得ることができます。 コンパクションの基準として Amazon S3 prefix を使用する S3 Standard Infrequent Access と S3 Glacier Instant Retrieval の請求対象オブジェクトの最小サイズは 128 KB で、小さなオブジェクトに対する過剰なライフサイクル移行料金からユーザーを保護するためのものですが、 大量の小さなログファイルを書き込みたい場合には課題となる可能性があります。コンパクションパターンは、この課題に対処する方法を提供します。また、このパターンはストレージクラス間でオブジェクトを移動する際の S3 ライフサイクル移行コストを回避します。 例えば： Standard ストレージクラスを使用するバケットに、1 KB の 10,000,000 個のオブジェクトがあるとします。 これらを S3 Standard に保存するコストは、1 か月あたり $ 0.23 です。 これらを S3 Standard-IA にそのまま保存する場合のコストは、1 か月あたり $ 16 です（ 128 KB × 10,000,000 × 0.0125 $ / GB ）。 これらを 1,000 個のオブジェクトにコンパクションすると、移行コストは $ 0.01 になり、ストレージコスト（ 1,000 個の出力ファイルに均等に分散されると仮定）は 1 か月あたり $ 0.13 になります。 これらの価格詳細は、執筆時点での US-East-1 リージョンに基づいています。最新情報については、 Amazon S3 料金表 を参照してください。 このトレードオフは、読み取りの粒度が低下することです。コンパクションパターンを使用すると、書き込みと同じ粒度（例えば、各個別のイベントではなく毎日のデータ）ではなく、コンパクションされた形式でのみオブジェクトを取得できます。 コンパクションの比率は、ソース S3 バケット内の prefix の粒度に依存します。例えば、 prefix が日付ごとに日単位の粒度で分割されている場合、各日に対して 1 つの圧縮された出力ファイルが生成されます。入力と出力の間で同じ粒度を維持することで、ソースデータと同じスキーマを使用して、コンパクションされたオブジェクトの効率的なクエリが可能になります。このパターンの例を次の図に示します： これらのより少数で大きなオブジェクトを S3 Standard-IA または S3 Glacier ストレージクラスに移行することで、ストレージコストを削減できます。その後、 ライフサイクルポリシー を使用して、追加料金なしで古い未コンパクションデータを削除することができます。 AWS Lambda と AWS Step Functions 分散マップを使用したオブジェクトのコンパクション このパターンのサンプル実装は GitHub で公開されています。詳細な説明とデプロイ手順については、 README に詳述されている手順に従ってください。この実装では、 AWS Lambda 関数を使用して複数の Amazon S3 prefix を反復処理し、各 prefix 内の小さなファイルの内容を読み取って結合し、それらを 1 つのファイルに集約して宛先バケットに書き込みます。 Lambda では消費したコンピューティング時間に対してのみ料金が発生するため、指定したスケジュールのみ実行する必要があるコンパクションプロセスに適したソリューションとなります。 AWS Step Functions は、アプリケーションコンポーネントの実行を簡単に調整できる完全マネージド型サービスです。Step Functions を使用することで、ファイルのコンパクション Lambda 関数の呼び出しを管理が容易なワークフローに調整できます。小さなファイルを保持するprefix 階層が複数あることを考えると、特定の prefix で発生するファイルのマージは他の prefix から完全に独立しているため、圧縮を並行して実行すると便利です。 Step functions の 分散マップ は、並列データ処理をオーケストレーションするための機能です。この実装例では、ファイルのコンパクションを並列化するために分散マップを使用しています。 このパターンを示す例を次の図に示します： 実行手順は以下の通りです： Amazon EventBridge のスケジュールルールを使用してワークフローをスケジュールします。 Step Functions ワークフローは、設定された日数後に開始されます。呼び出し間隔（日数で測定）が、次の実行でコンパクション対象となる小さなファイルが作成された期間に直接対応するのが合理的です。例えば、完全なソリューションを、30 日ごとに分散マップステートを呼び出すスケジュールルールと共にデプロイし、呼び出し前の 30 日間に作成された小さなファイルを（並列で）コンパクションすることができます。 要求された prefix 内のすべてのファイルをリストアップするために Lambda 関数が呼び出されます。このリストは分散マップステップへの入力として使用されます。 ソースリスト内の各 prefix に対して、その prefix 内のオブジェクトをコンパクションするために並列の Lambda 関数が呼び出されます。 コンパクションされたオブジェクトは、宛先バケット内の同じ prefix 構造に書き込まれます（実際には、これはソースと同じバケットでも構いません）。 注意：この実装例では、キー自体に識別情報が含まれていないことを前提としています。もしそうでない場合 （例えば、キーにオブジェクト内のレコードのID範囲が含まれている場合、例：101-200.json 、201-300.json など）、正しい名前でファイルを出力するか、識別情報をルックアップテーブルに保存するようにソリューションを修正してください。 ソリューションのパフォーマンスとコスト テスト実行では、単一の Lambda 関数の実行で、約 12 分間で 22,000 以上の小さなログファイルを順次コンパクションすることができました。ログファイルは各数 KB で、合計で約 250 MB でした。 複数の prefix に対して同時にコンパクションを実行するために分散マップステートを呼び出した場合、同じ総数のファイルが約 50 秒でコンパクションされました（ 1340 % の時間短縮）。 これは、個々の Lambda 関数の実行時間を最小化するために Step Functions の並列処理を使用することの利点を示しています。これは重要です。なぜなら、 Lambda の最大実行タイムアウトは 15 分だからです。並列処理を採用しない場合、 15 分以内に順次コンパクションできるファイルの最大数に常に注意を払う必要があります。 このソリューションは、大量の小さなデータファイルを持つ環境に対して効率的にスケールします。サーバーレスソリューションとして、基盤となるコンピューティングは AWS によって管理されるため、運用オーバーヘッドは最小限であり、圧縮の実行中に消費されたリソースに対してのみ支払いが発生します。 Step Functions は、関連する prefix のリストを特定してからコンパクションを完了するまでに必要な状態遷移に基づいて課金されます。前述の並列呼び出しテスト実行の場合、全体のコストは AWS 無料利用枠 でカバーされます。無料利用枠以外では、このソリューションは 1,000 個の prefix あたり1回の実行で $ 0.22 未満のコストがかかります。コンパクションを月 1 回実行する場合、年間合計は $ 2.64 です。詳細については、 Lambda と Step Functions の料金ページをご覧ください。 このパターンの効率性は、小さなファイルのサイズと数量だけでなく、ソースバケット内のパーティション全体にどのように分散しているかにも依存します。例えば、 prefix あたりの小さなファイルが少なすぎる場合、コンパクションプロセスのコストとパフォーマンスの向上は、結果としてコンパクションされたオブジェクトが数桁大きくなる場合ほど顕著ではありません。このソリューションを採用する前に、パーティショニング戦略を見直すことが重要です。 Amazon Athena を使用したコンパクションオブジェクトのクエリ実行時のパフォーマンス向上 小さなファイルを圧縮してアーカイブするのではなく、コンパクションをする理由は、データへのリアルタイムアクセスを可能にするためです。アーカイブベースのアプローチでは、クエリを実行する前にデータを解凍する追加のオーバーヘッドが発生します。これは、 CloudTrail を使用した必要に応じた分析や、データレイク内の頻繁にアクセスされないデータに適用されます。 Amazon Athena は、 S3 バケット内に保存された構造化および半構造化データ上で動作するサーバーレス SQL エンジンです。ログ分析の例を取ると、 Athena は必要に応じたクエリと分析に適しています。 Athena は、スキャンされたデータの GB 単位で料金が設定されています。 Athena の主要なパフォーマンス要因の 1 つは、 Amazon S3 内のオブジェクトのパーティション構造です。 コンパクションパターンを使用する際は、ソースデータの時間粒度に合わせてファイルを集約することが重要です（例えば、 Amazon S3 のパーティション構造が年/月/日の場合は日単位）。これにより、クエリ実行時にデータの過剰選択や破棄を防ぐことができます。ソースデータの粒度を超えてファイルをコンパクションすると、クエリパフォーマンスが非効率になり、コストが増加するリスクがあります。例えば、ソースデータが日単位でパーティション化されている場合（2024/02/01 など）、ファイルをコンパクションすべき最も細かいレベルは 1 日単位です。ソースデータの粒度よりも高いレベルでファイルをコンパクションすると、データを効果的にフィルタリングする能力を失うリスクがあり、これは大規模なデータセットに対して過剰選択、コスト増加、クエリパフォーマンスの低下につながります。詳細については、「 prefix を使用してオブジェクトを整理する 」を参照してください。 Athena のパフォーマンスに影響を与えるもう一つの要因は、ファイルのサイズです。多数の小さなファイルは、結果を計算する際にオーバーヘッドを追加する可能性があります。ここでコンパクションがクエリ実行時間を短縮できます。一般的に、ファイルサイズを数百 MB 程度にすることが推奨されます。Athena のクエリパフォーマンスの最適化に関する詳細については、「 Amazon Athena のパフォーマンスチューニング Tips トップ 10 」を参照してください。 以下の例では、1.4 GB のデータが 10,000 個のファイル（1 ファイルあたり 0.14 MB）に分割され、S3 バケット内で日単位でパーティション化されています。 1 日あたり数百の個別ファイルが存在する可能性があります。Athena を使用してこの生データにクエリを実行すると、クエリのパフォーマンスは次のようになります： 同じクエリをコンパクションされたバージョンのデータに対して実行すると、クエリ実行時間は約 66 % 短縮され、クエリの完了時間が短縮されることでクエリの同時実行性も向上します。コンパクションによってファイル数は 293 個（1 ファイルあたり 4.8 MB）に減少しました。以下のスクリーンショットは、スキャンされたデータ量が、圧縮されていないまたは別の形式に変換されていないデータと同じであることを示しています： データ量が増加するにつれて、実行パフォーマンスは線形的にスケールします。以下の例では、約 58 万 2 千個のオブジェクト（合計約 83 GB、1 ファイルあたり 0.14 MB）が 336 個のファイル（1 ファイルあたり 247 MB）にコンパクションされています。クエリを実行すると、同様のパフォーマンス向上が観察されます。以下のスクリーンショットの 1 枚目は、生データが 40 秒で取得されたことを示しています： 次のスクリーンショットは、コンパクションされたデータと改善されたクエリ実行時間 9.7 秒を示しています： 比較のため、同じ実行結果を以下の表に示します： データセット 1： Format Total objects Total size (GB) Average object size (MB) Execution time (s) Raw 10,000 1.4 0.14 16 Compacted 293 1.4 4.8 6.8 データセット 2： Format Total objects Total size (GB) Average object size (MB) Execution time (s) Raw 582,000 83 0.14 40.7 Compacted 336 83 247 9.7 コンパクションアプローチのもう一つの利点は、その実装がクエリエンジンに対して透過的であることです。スキーマとフォーマットが同じであるため、ソースバケットの「ホット」または生データと、「コールド」またはコンパクションされたバケットのデータの両方にまたがってクエリを実行し、結合やユニオンを行うことができます。これにより、最新のデータを保持しながら、集計プロセスを定期的または低頻度で実行することが可能になります。生データとコンパクションデータにまたがってユニオンを実行するクエリの例を、以下のスクリーンショットに示します： Athena を使用してアーカイブデータをクエリする方法の詳細については、ブログ「 Simplify querying your archive data in Amazon S3 with Amazon Athena 」を参照してください。 クリーンアップ GitHub リポジトリからソリューションをデプロイした場合は、予期せぬコストを避けるために 、必ず クリーンアップ手順 に従ってください。 結論 本投稿では、Amazon S3 上の小さなオブジェクトを効率的にコンパクションする方法を探り、ログデータのストレージコストを最適化する効果的な方法であることを示しました。AWS Step Functions を活用することで、数千の小さなオブジェクトを迅速かつ効率的にコンパクションできます。AWS Lambda を使用してコンパクションを実行することで、データコンパクションソリューションのコストを削減し、運用オーバーヘッドを軽減できます。 多数の小さなファイルを、一致する prefix 階層を持つ宛先バケット内のより大きなオブジェクトに集約する際、データのクエリのしやすさは維持されます。Amazon Athena でのコンパクションされたデータに対するクエリ時間は、より少ない数の大きなファイルをスキャンするオーバーヘッドが減少するため、50 〜 70 % 短縮される可能性があります。さらに、コンパクションされたオブジェクトを S3 Standard-IA や S3 Glacier ストレージ Tier に移行する際、このソリューションを定期的に実行することで、ストレージコストを最大 80 % 削減できます。 始めるには、このパターンの実装を示す GitHub 上の サンプルコード を確認してください。この例には、テストデータの生成方法と、お客様の環境でソリューションを試す手順が含まれています。 <!-- '"` --> Josh Hart Josh は Amazon Web Services の Principal Solutions Architect です。彼は英国の ISV のお客様と協力して、AWS での SaaS アプリケーションの構築と近代化を支援しています。 Kim Banga Kim は AWS の Solutions Architect で、英国とアイルランドのソフトウェア企業と協力して、AWS のサービスを最大限に活用してビジネス目標を達成できるよう支援しています。彼のバックグラウンドはクラウドネイティブ開発とマイクロサービスアーキテクチャであり、堅牢で安全でコスト最適化されたソリューションを構築するための最新のパターンを探求することに強い関心を持っています。 Thomas Moore Thomas は AWS の Senior Solutions Architect で、英国とアイルランドの ISV や B2B 組織と連携しています。AWS では、お客様のマルチテナント型 SaaS トランスフォーメーションを支援しています。彼は IT インフラストラクチャ、特に航空、小売、製造業界の企業組織で 10 年以上の経験があります。彼は自動化とサーバーレステクノロジーの活用に情熱を注いでいます。

5 月 21 日、クラウドアーキテクトとクラスター管理者が Kubernetes クラスター全体で組織全体の可視性を維持することを可能にする一元的なビュー、EKS ダッシュボードを発表しました。EKS ダッシュボードでは、複数の異なる AWS リージョンやアカウントにデプロイされたクラスターを統合ビューで監視できるので、クラスターインベントリの追跡とコンプライアンスの評価に加えて、バージョンアップグレードなどの運用アクティビティの計画が容易になります。 Kubernetes デプロイをスケールする組織では、可用性の向上、事業継続性の確保、またはデータ主権の維持を目的として、さまざまな環境にわたって複数のクラスターが実行されることがあります。ただし、このような分散型のアプローチでは、複数のリージョンやアカウントにまたがる分散型のセットアップで可視性と制御を維持することが困難になることがあります。現在、多くのお客様はサードパーティーのツールを使用してクラスターの一元的な可視化を行っていますが、ID とアクセスのセットアップ、ライセンスコスト、メンテナンスのオーバーヘッドなどの複雑さに対処する必要があります。 EKS ダッシュボードは AWS コンソール 内でネイティブダッシュボード機能を提供することで、このエクスペリエンスを簡素化します。ダッシュボードは、3 つの異なるリソース (クラスター、マネージドノードグループ、EKS アドオン) に関するインサイトを提供し、クラスター分布に関する集約インサイトをリージョン、アカウント、バージョン、サポートステータス、延長サポートの EKS コントロールプレーンの予測コスト、クラスターヘルスメトリクスに基づいて表示することができます。自動フィルタリングで特定のデータポイントをドリルダウンできるため、注意が必要なクラスターをすばやく特定して集中できます。 EKS ダッシュボードをセットアップする EKS コンソールのダッシュボードへは、AWS Organizations の 管理 アカウントと 委任された管理者 アカウントからアクセスできます。セットアッププロセスは簡単で、必要な操作は Amazon EKS コンソールの組織設定ページで信頼されたアクセスを一度有効にすることだけです。信頼されたアクセスは、 [ダッシュボード設定] ページからアクセスできます。信頼されたアクセスを有効にすると、管理アカウントでダッシュボードを表示できるようになります。セットアップと設定の詳細については、公式の AWS ドキュメント を参照してください。 EKS ダッシュボードのクイックツアー ダッシュボードには、Kubernetes クラスターのグラフィカルビュー、表形式、マップビューが表示され、高度なフィルタリングや検索機能を利用できます。データをエクスポートして、詳細な分析やカスタムレポートの作成を行うこともできます。 クラスターに関する主要な情報を表示する EKS ダッシュボードの概要。 クラスターの視覚化に役立つさまざまなウィジェットが用意されています。 マネージドノードグループは、インスタンスタイプ分布、起動テンプレート、AMI バージョンなどに基づいて視覚化できます。 世界中のすべてのクラスターを確認できるマップビューもあります。 EKS クラスターを超えて EKS ダッシュボードは Amazon EKS クラスターだけに限定されたものではなく、オンプレミスまたは他のクラウドプロバイダーで実行されている接続された Kubernetes クラスターを可視化することもできます。接続されたクラスターでは、ネイティブの Amazon EKS クラスターと比較してデータの忠実度に制限がある場合がありますが、この機能を使用すると、ハイブリッドまたはマルチクラウド環境を実行している組織で真に統合された可視性が得られます。 今すぐ利用可能 現在、EKS ダッシュボードは米国東部 (バージニア北部) リージョンで利用可能で、すべての商用 AWS リージョンのデータを集約できます。EKS ダッシュボードを使用するための追加料金はありません。詳細については、 Amazon EKS のドキュメント を参照してください。 この新機能は、お客様がインフラストラクチャの管理ではなくアプリケーションの構築とスケーリングに集中できるようにすることで、Kubernetes の運用を簡素化するという当社の継続的な取り組みを示しています。お客様がどのように EKS ダッシュボードを使用して Kubernetes の運用を強化しているかを見るのを楽しみにしています。 – Micah 原文は こちら です。

この記事は DoorDash の Vraj Shah と Chaitanya Hari との共著です。 DoorDash は、世界中の 30 か国以上で消費者と地元の好みのビジネスをつないでいます。Door Dash は、Dasher として知られる契約配達員からの大量の電話対応で大きな課題に直面していました。2023 年末時点で 3,700 万人以上のアクティブな消費者と月間 200 万人のアクティブな Dasher を抱える同社は、 Dasher により効率的なセルフサービス体験を提供することで、ライブエージェントの負担を軽減する必要性を認識しました。 この課題に対処するため、DoorDash のコンタクトセンターチームは、高水準の問題解決と顧客満足度を維持しながら、迅速かつ大規模に解決策をデプロイするために 生成 AI の力を活用したいと考えました。道路上にいる間はテキストよりも電話でのサポートを好む Dasher には、最小限の応答遅延で迅速で信頼性の高い支援が必要です。この低遅延要件は、 DoorDash が音声による効果的なセルフサービスソリューションを追求する上で重要な要素となりました。 ライブエージェントによる支援の必要性を減らすために、DoorDash は AWS Generative AI Innovation Center と協力してわずか 2 か月で、Dasher に低遅延のセルフサービス音声体験を提供するソリューションを構築しました。 このソリューションは、音声対応の会話型 AI サービスである Amazon Lex 、主要な AI スタートアップと Amazon からの基盤モデル (FM) を API を通じて利用可能にし、ユースケースに最適なモデルを選択できる完全マネージド型サービスである Amazon Bedrock 、そして大規模言語モデル (LLM) をデータソースに接続する完全マネージド型サービスの Amazon Bedrock のナレッジベース を使用しています。これは、フルサーバーレスアーキテクチャで、基盤となるインフラストラクチャを管理することなくペタバイト規模のワークロードを実行できる Amazon OpenSearch Serverless を使用しています。 このソリューションは 1 日数十万件の電話に対応し、2.5 秒以内に Dasher の質問に回答しています。また、自動テスト、会話分析、監視と可観測性、LLM ハルシネーションの防止と検出を含む運用機能も提供しています。 「私たちはDasherが最も一般的な質問や問題について、できるだけ迅速かつ効率的に支援を受けられるようにしたいと考えていました。それによって彼らの時間と労力を節約し、DoorDash のセルフサービス機能への信頼を高めることができます」 – Chaitanya Hari, Contact Center Product Lead at DoorDash. この記事では、AWS サービスを使用してコンタクトセンターに生成 AI エージェントをデプロイする方法を紹介します。 ソリューション概要 この記事では、Example Corp Hospitality Group という架空のホテルチェーンの例を使用します。以下は、顧客と LLM による自動エージェントとの対話の例です： 顧客 : こんにちは、家族旅行に最適な場所を探しています エージェント : Example Corp Family Getaways では、テーマパーク、国立公園、歴史的な名所などの人気観光スポット近くにある家族向けホテルやリゾートを提供しています。リゾートには広々とした宿泊施設、全年齢向けのアクティビティ、多様な食事オプションがあり、忘れられない家族の思い出を作ることができます。 顧客 : どこにありますか？ エージェント : Example Corp Family Getaways は、フロリダ州オーランド、カリフォルニア州アナハイム、バージニア州ウィリアムズバーグ、テネシー州ピジョンフォージ、テキサス州サンアントニオ、アリゾナ州スコッツデール、ミズーリ州ブランソン、ウィスコンシン州ウィスコンシンデルズ、ペンシルベニア州ハーシーなど、さまざまな人気の休暇先で家族向けリゾートを提供しています。 顧客 : ピジョンフォージが面白そうですね。 エージェント : ピジョンフォージのリゾートでは、ドリーウッドやその他の近隣のアトラクションの興奮を楽しみながら、大自然を体験する機会を家族に提供しています。宿泊客は室内ウォーターパーク、ミニゴルフコース、ファイヤーピット周辺での夜のスモア焼きを楽しむことができます。 顧客 : 子供向けメニューはありますか？ エージェント : テネシー州ピジョンフォージの Example Corp Family Getaways リゾートでは、ピザ、チキンナゲット、マカロニチーズなどのお気に入りを含む専用の子供向けメニューなど、家族向けの食事オプションを提供しています。 自分の AWS アカウントでソリューションをデプロイして、このサンプルソリューションを試すことができます。以下の図はソリューションアーキテクチャを示しています。 ソリューションの主要コンポーネントのデプロイとテストの手順を説明します： ソリューションが質問に回答するために使用するコンテンツを保存する Amazon Bedrock Knowledge Bases を設定する AWS CloudFormation スタック Amazon Lex ボットとコアとなる検索拡張生成（RAG）に基づく質問応答機能を実装する AWS Lambda 関数を作成する CloudFormation スタック （オプション）会話分析ダッシュボードを有効にするデータパイプラインをデプロイする CloudFormation スタック （オプション）LLM ハルシネーションの非同期検出機能を有効にする CloudFormation スタック （オプション）生成された回答と正解の回答を比較し、合格/不合格の評価と説明を提供するための自動テスト機能を利用できる Amazon SageMaker の Jupyter ノートブック 必要なすべてのものは、 GitHub リポジトリ でオープンソースとしても提供されています。 ※ 日本のお客様向けの補足事項 ： 本ソリューションは、英語のみに対応していますが、「RAGソリューションスタックのデプロイ」の実施後に、Amazon Lex の日本語追加を行い、Lambda 関数の該当コードにおけるプロンプトを日本語に修正することで、日本語による応対も簡易的に検証可能です。LLM として Anthropic の Claude 3 Haiku、Claude 3 Sonnet を選択した場合は、Lambda 関数コードの bedrock_utils/hotel_agents/anthropic.py と bedrock_utils/conversational_agents/anthropic.py のプロンプトを日本語に修正します。 前提条件 このアプリケーションに必要なリソースとコンポーネントを作成および管理するための権限を持つ AWS アカウントと AWS Identity and Access Management (IAM) ロールおよびユーザーが必要です。AWS アカウントをお持ちでない場合は、 「新しい AWS アカウントを作成して有効化する方法を教えてください。」 を参照してください。 このソリューションでは、Amazon Bedrock を使用して ナレッジベースから質問に対する回答を見つけます。次に進む前に、少なくとも以下のAmazon Bedrockモデルへのアクセスをリクエストしてください（既にアクセスが有効な環境ではこの作業は不要です）： Amazon Titan Embeddings G1 – Text Cohere Embed English v3 と Cohere Embed Multilingual v3 Anthropic の Claude 3 Haiku と Anthropic の Claude 3 Sonnet Amazon Connect と統合する場合は、ご自身のアカウントで利用可能な Amazon Connect インスタンスがあることを確認してください。まだない場合は作成できます。会話分析スタックをデプロイする場合は、Amazon QuickSight が 必要となるため、アカウント内で有効になっていることを確認してください。 執筆時点では、このソリューションは以下の AWS リージョンで利用可能です：アジアパシフィック（シンガポール、シドニー、東京）、カナダ（中部）、ヨーロッパ（フランクフルト、ロンドン）、米国東部（バージニア北部）、米国西部（オレゴン）。 Amazon Bedrock ナレッジベースのデプロイ Amazon Simple Storage Service (Amazon S3) をデータソースとして使用するナレッジベースには、CloudFormation スタックを使用できます。ナレッジベースをセットアップするには、以下の手順を実行します： AWS アカウントにサインインし、“Launch Stack” を選択して CloudFormation テンプレートをデプロイします 「次へ」をクリックし、スタック名を入力します（例：contact-center-kb）。 S3 bucket where you will store your content : 既存の S3 バケット名を入力します（例：contact-center-kb-{your-account-number}）。これはデモソリューションのコンテンツが保存される場所です。まだ S3 バケットがない場合は作成してください。 S3 prefix for your content (optional) : 何も入力しないでください。 Choose an embedding model : 埋め込みモデルを選択します（例：amazon.titan-embed-text-v2:0） Choose a chunking strategy (default, fixed-size, or none) : “Fixed-sized chunking” （固定サイズのチャンキング戦略）を選択します。 For fixed-size chunking, choose a maximum number of tokens per chunk : チャンクサイズを指定します。Amazon Titan 埋め込みモデルを使用する場合は “600” 、Cohere 埋め込みモデルの場合は “512” を入力します。これは約 1 ページ分のテキストに相当します。 For fixed-size chunking, choose an overlap percentage between chunks : チャンクのオーバーラップの割合として “10” を入力します。 Index Details : 4 つのエントリ（インデックス名、ベクトルフィールド名、メタデータフィールド名、テキストフィールド名）はデフォルト値のままにします。 「次へ」を選択します。 「スタックオプションの設定」ページの下部で、「AWS CloudFormation によって IAM リソースが作成される場合があることを承認します。」にチェックを入れ、「次へ」を選択します。 「確認して作成」のページで、「送信」を選択します。 スタックのデプロイには約 10 分かかります。 サンプルコンテンツのアップロードと ナレッジベースのテスト このソリューションのデモサンプルには、架空のホテルチェーン Example Corp Hospitality Group に関する質問に答えることができる LLM ベースのホテルボットが含まれています。このホテルチェーンのコンテンツを、ナレッジベーススタック用に指定した S3 バケットにロードする必要があります。 CloudFormation スタックによって使用される S3 バケットは、スタックの「出力」タブで確認できます。 AWS Command Line Interface （AWS CLI）または AWS Management Console のいずれかを使用して、 GitHub リポジトリの content セクション から以下のフォルダをアップロードします。PDF 版または Word 文書版（Word 版推奨）のいずれかを選択できます。 corporate family-getaways luxury-suites party-times seaside-resorts waypoint-inns 完了すると、S3 バケットの最上位レベルには、それぞれ単一の Word または PDF ドキュメントを含む 6 つのフォルダがあるはずです。 Amazon Bedrock コンソールで、ナビゲーションペインの「ナレッジベース」を選択します。 CloudFormation によって作成されたナレッジベースを選択して開きます。「1 つ以上のデータソースが同期されていません」というメッセージが表示されます。 データソースを選択し、「同期」を選択します。 同期プロセスは数分しかかかりません。 データソースが同期された後、ナレッジベースを開くと、マネジメントコンソールの右側で ナレッジベースによる質問回答をテストできます。必要なモデルが Amazon Bedrock の「モデルアクセス」ページで有効になっていることを確認してください。 LLM（ Anthropic の Claude 3 Haiku など）を選択し、質問を始めましょう！アップロードしたサンプル文書を読んで、質問のアイデアをいくつか考えてみるとよいでしょう。 ハルシネーション検出スタックのデプロイ（オプション） オプションの非同期ハルシネーション検出機能を使用したい場合は、このスタックをデプロイします。それ以外の場合は、次のセクションに進みます。この CloudFormation スタックは、非同期ハルシネーション検出が必要な RAG ベースのソリューションで使用できます。 “Launch Stack” を選択します 「次へ」をクリックし、スタック名を入力します（例：contact-center-hallucination-detection） Select an LLM : ハルシネーション検出を実行する LLM を指定します。執筆時点では、ハルシネーション検出に推奨される LLM が 8 つあります。デフォルト値の “Claude V3 Sonnet” を選択します。 Create a Customer-Managed Key? : オプションで、“Create a Customer-Managed Key?” で、 Amazon Simple Queue Service （Amazon SQS）キューと Lambda 関数の Amazon CloudWatch Logs ロググループを暗号化するための Amazon Key Management Service （AWS KMS）カスタマーマネージドキー（CMK）を作成します（本番環境では推奨）。 このスタックには2種類の Amazon CloudWatch アラームがあります： ERROR アラーム – ハルシネーション検出作業を実行する Lambda 関数のコードの問題に関するもの WARNING アラーム – Lambda 関数が実際にハルシネーションを検出した場合のためのもの どちらのアラームタイプもオプションですが、有効化することを推奨します。 Create CloudWatch ERROR alarms? : ERROR アラームを有効化する場合は “yes”、無効する場合は “no” を選択します。 Create CloudWatch WARNING alarms? : WARNING アラームを有効化する場合は “yes”、無効する場合は “no” を選択します。 Subscribe to CloudWatch ERROR alarms? : オプションで、ERROR アラームを通知を受け取るためのメールアドレスを設定できます。 Subscribe to CloudWatch WARNING alarms? : オプションで、WARNING アラーム通知を受け取るためのメールアドレスを設定できます。 「次へ」を選択します。 「スタックオプションの設定」ページで「AWS CloudFormation によって IAM リソースが作成される場合があることを承認します。」にチェックを入れ、「次へ」を選択します 「確認と作成」ページで、「送信」を選択します。 スタックのデプロイには約 1 〜 2 分かかります。 スタックが完了したら、CloudFormation スタックの「リソース」タブで作成されたリソースを確認できます。特に、 Lambda 関数のコードを確認してください。 アラーム通知用のメールアドレスを入力した場合は、サブスクリプションの確認を求めるメールリクエストを受け取るはずです。アラームが発生した場合に通知を受け取るには、メール本文の “Confirm subscription” をクリックしてください。 RAGソリューションスタックのデプロイ Amazon Connect と統合する場合は、アカウントでインスタンスが利用可能であることを確認してください。まだない場合は作成できます。Amazon Lex ボットと Lambda 関数をデプロイするには、以下の手順を完了します： “Launch Stack” を選択します 「次へ」をクリックし、スタック名を入力します（例：contact-center-rag-solution） Lex bot name : Amazon Lex ボットの名前を入力します（例：hotel-bot） Number of conversation turns for context : コンテキスト用に保持する会話ターンの数を指定します。これは異なるユースケースとデータセットに合わせて最適化できます。hotel-bot デモには、デフォルトの 4 を試してみてください。 Conversation logs group ARN : オプションで、Amazon Lex の会話ログ用に既存の CloudWatch Logs ロググループ ARN を指定します。会話分析スタックをデプロイする予定の場合は、これが必要になります。 まだロググループがない場合は作成してください 。 Number of AWS Lambda provisioned concurrency units (use 0 for no provisioned concurrency) : オプションで、Amazon Lex ボットハンドラー関数の Lambda Provisioned Concurrency 単位の値を入力します。ゼロ以外の数値を設定すると、Lambda コールドスタートを防ぐことができます。本番環境と内部テストに推奨されます。開発には、0 または 1 が推奨されます。 Create a Customer-Managed Key? : オプションで、Lambda 関数の CloudWatch Logs ロググループを暗号化するための KMS CMK を作成するオプションを選択します（本番環境で推奨）。 Connect instance ARN : Amazon Connect と統合する場合に指定します。Amazon Connect インスタンス ARN を入力します。 Connect contact flow name : Amazon Connect と統合する場合に指定します。スタックが作成する新しいコンタクトフローの名前を入力します。 Knowledge Base ID : 作成したナレッジベーススタックからナレッジベースIDを提供します。これは知識ベーススタックの「出力」タブで確認できます。 Knowledge Base S3 bucket : ナレッジベースで使用している S3 バケットを提供します（ナレッジベーススタックの「出力」タブで参照できます）。 SQS Queue Name : ハルシネーション検出スタックを作成した場合に、SQS キュー名を入力します。（ハルシネーション検出スタックの「出力」タブで参照できます） SQS Queue Encryption Key ARN : ハルシネーション検出スタック用に KMS キーを選択した場合は、KMS キー ARN を入力します。 「次へ」を選択します。 「スタックオプションの設定」ページで「AWS CloudFormation によって IAM リソースが作成される場合があることを承認します。」にチェックを入れ、「次へ」を選択します 「確認と作成」ページで、「送信」を選択します。 スタックの完了には数分かかります。 RAG ソリューションを試すには、Amazon Lex コンソールに移動し、hotel-bot ボットを開きます。ボットには英語言語セクションが 1 つあります。 ナビゲーションペインで「インテント」を選択し、このサンプルボットの意図を確認します。以下が含まれます： ホテルチェーンと様々なホテルブランドの質問に関連するインテント – Accommodations 、 Amenities 、 CorporateOverview 、 Locations 、 Parking などが含まれます。これらのインテントは Amazon Lex によって RAG ソリューションにルーティングされます。技術的には、このような種類のリクエストを FallbackIntent で処理することもできるため、これらのインテントは省略して RAG に転送することも可能です。しかし、これらのインテント（およびそのサンプル発話）を含めることで、Amazon Lex に各ドメインの言語に関する情報を付与し、speech-to-text エンジンを最適化して文字起こしの精度を向上させることができます。さらに、これらのインテントを含めることは会話分析にも役立ちます。 SwitchBrand – このインテントは、会話の途中でユーザーが「他のホテルはどうですか？」などと言えるようにすることで、会話のフローを改善するために設計されています。 Booking – これは、発信者をライブエージェントキューにルーティングする例を示しています。 SpeakToAgent – このインテントは、発信者が特にライブエージェントをリクエストする場合のためのものです。 Welcome 、 Goodbye 、 Help – これらの会話サポートインテントは、会話の開始と終了、またはボットができることを尋ねるためのものです。 FallbackIntent – これは、他のインテントに一致しない質問やリクエストのための標準インテントです。このサンプルソリューションでは、そのようなリクエストもRAG ソリューションにルーティングされ、LLM がナレッジベース内のコンテンツに基づいて回答できるようになっています。 SelectKnowledgeBase と SelectLLM – これらは、ユーザーが RAG ソリューションに異なるナレッジベースインスタンス（複数利用可能な場合）や異なる LLM を使用するよう指示することを可能にします。これらのインテントはテスト目的で設計されており、通常は本番環境以外のデプロイメントにのみ含めるべきです。Amazon Bedrock で利用可能な任意の LLM で RAG ソリューションをテストできます。また、必要に応じて会話の途中で別のナレッジベースや LLM に切り替えることもできます。 ToggleLLMGuardrails （LLMガードレールの切り替え）と ToggleLLMContext （LLMコンテキストの切り替え） – これらは、ユーザーがプロンプトベースの LLM ガードレールをオフまたはオンに切り替えたり、ナレッジベースからの情報取得を無効または有効にしたりすることを可能にします。これらのインテントはテスト目的で設計されており、通常は本番環境以外の環境にのみ含めるべきです。必要に応じて、会話の途中でこれらの設定をオフやオンに切り替えることができます。 Amazon Lex コンソールで「テスト」を選択して、ソリューションを試すことができます。 いくつかのサンプル会話を試してみてください。例えば： “We’re looking for a nice place for a family vacation” (「家族旅行に素敵な場所を探しています」) と尋ねると、ボットは Example Corp Family Getaways offers family-friendly resorts…” (「Example Corp Family Getaways では家族向けの宿泊施設を提供しています…」) と応答します。 “Where are they located?” (「どこにありますか？」) と尋ねると、ボットは “The Example Corp Family Getaways resort in Pigeon Forge, Tennessee is…” (「Example Corp Family Getaways には…に所在地があります」) と応答します。 “Tell me more about the one in Pigeon Forge” (「ピジョンフォージについてもっと教えてください」) と尋ねると、ボットは “The Example Corp Family Getaways resort in Pigeon Forge, Tennessee is…” (「テネシー州ピジョンフォージの Example Corp Family Getaways リゾートは…」) と応答します。 質問のアイデアについては、アップロードした サンプルドキュメント を参照してください。 ハルシネーション検出スタックをデプロイした場合は、テスト時に得た回答の評価を確認できます。ハルシネーション検出スタックの詳細ページの「リソース」タブで、「HallucinationDetectionFunctionLogGroup」エントリを選択します。これにより、Lambda ハルシネーション検出関数の CloudWatch Logs ロググループが開きます。ログステートメントを調査して、ハルシネーション検出プロセスがどのように機能しているかを確認できます。 Amazon Connect と統合している場合は、指定した Amazon Connect インスタンスに新しいコンタクトフローが作成されています。 音声でテストするには、電話番号を要求し、このコンタクトフローに関連付けて、電話をかけるだけです！ 会話分析スタックのデプロイ（オプション） このスタックは QuickSight を分析に使用するため、このスタックをデプロイする前に AWS アカウントですでに有効になっていることを確認してください。 “Launch Stack” を選択します CloudWatch Logs log group for Lex Conversation Logs : Amazon Lex 会話ログを保存している CloudWatch ロググループの名前（※ ARNではない点に注意）を入力します。これは、RAGソリューションをデプロイした CloudFormation スタックにも使用した CloudWatch Logs ロググループです。 Purge Source Logs? : ロググループからソースログストリームを削除するオプションを選択します。テストの場合は “no” を選択します。 Redact Sensitive Data? : 会話ログから機密データを編集するオプションを選択します。テストの場合は “no” を選択します。 List of PII entity types to redact : 個人を特定できる情報（PII）のエンティティタイプを設定します。ここでは、デフォルト値のままにしておきます。 Minimum confidence score for Amazon Comprehend redaction : PII の信頼スコアのしきい値を設定します。ここでは、デフォルト値のままにしておきます。 Allow unredacted application logs? : データパイプラインの Lambda 関数の編集されていないログを許可するオプションを選択します。テストの場合は “yes” を選択します。 Create a Customer-Managed Key (CMK)? : KMS CMK を作成するオプションを選択します。 作成された CMK は、会話データを格納するためにこのスタックが作成する S3 バケットのデータを暗号化するために使用されます。これにより、どの IAM プリンシパルがデータを復号化して表示できるかを制御できます。この設定は本番環境で推奨されます。 Create CloudWatch ERROR alarms? : Amazon Lex データパイプラインで、ERROR アラームを有効化する場合は “yes”、無効する場合は “no” を選択します。 Subscribe to CloudWatch ERROR alarms? : オプションで、ERROR アラームを通知を受け取るためのメールアドレスを設定できます。 Create CloudWatch WARNING alarms? : Amazon Lex データパイプラインで、WARNING アラームを有効化する場合は “yes”、無効する場合は “no” を選択します。 Subscribe to CloudWatch WARNING alarms? : オプションで、WARNING アラーム通知を受け取るためのメールアドレスを設定できます。 「次へ」を選択します。 「スタックオプションの設定」ページで「次へ」を選択します 「確認と作成」ページで、IAM 機能メッセージを承認し、「送信」を選択します スタックの完了には約 5 分かかるはずです。 以下の図はスタックのアーキテクチャを示しています。 Amazon Lex が CloudWatch Logs (1) に会話ログエントリを書き込むと、 Amazon Data Firehose によって取得され、S3 バケット (2) にストリーミングされます。その過程で、Lambda 変換関数 (3) がデータの JSON 構造を簡素化し、クエリ目的でよりユーザーフレンドリーにします。Lambda 関数は Amazon Comprehend (4) を使用して機密データを編集することもでき、オプションで CloudWatch Logs ロググループからエントリを消費する際に削除することもできます。 スケジュールベース (5 分間隔) で、 AWS Glue クローラー (5) が S3 バケットの新しいデータを検査し、 Amazon Athena (6) がデータへの SQL インターフェースを提供するために使用するデータスキーマを更新します。これにより、QuickSight (7) のようなツールがデータのほぼリアルタイムのダッシュボード、分析、視覚化を作成できるようになります。 QuickSightダッシュボードの設定（オプション） QuickSight ダッシュボードを作成する前に、Amazon Lex コンソールに戻り、ダッシュボード用のデータを生成するためにいくつかの質問をしてください。パイプラインがこの新しい会話データを処理して QuickSight で利用できるようになるまで約 5 分かかります。 QuickSight でダッシュボードと視覚化を設定するには、以下の手順を完了します。 QuickSight コンソールで、ユーザープロファイルアイコンを選択し、「QuickSight を管理」を選択します。 「セキュリティとアクセス許可」の、「QuickSight の AWS のサービスへのアクセス」の「管理」を選択します。 「Amazon S3」の下で、「S3 バケットを選択」を選択します。 会話分析スタックによって作成された S3 バケットへのアクセスを有効にします（12文字の一意の識別子が前に付いた「lex-conversation-logs」という名前になります）。書き込み権限を有効にする必要はありません。 「完了」を選択し、次に「保存」を選択します。 QuickSight メニューアイコンを選択して、QuickSight のメインページに戻ります。 ナビゲーションペインで「データセット」を選択します。 「新しいデータセット」を選択します。 データセットソースのリストから「Athena」を選択します。 データソース名を入力します（例：contact-center-analytics）。 「データソースを作成」を選択します。 「テーブルの選択」ウィンドウで、データベースを選択し、「lex_conversation_logs」テーブルを選択して、「データの編集/プレビュー」を選択します。 これにより、新しい QuickSight データセットが開きます。利用可能なさまざまな属性を確認し、テストからいくつかの結果を見ることができます。 データの表示速度を向上させるために、「クエリモード」に「SPICE」オプションを選択できますが、その場合、追加のテストに基づいてデータの更新を確認したい場合は、SPICEを更新する（または毎時自動更新スケジュールを設定する）必要があります。 現時点では、設定を「直接クエリ」のままにしておきます。 準備ができたら、「保存して視覚化」を選択します。 「新しいシート」ウィンドウでデフォルトを維持し、「作成」を選択します。 これにより分析ページが開き、視覚化の作成を開始できます。 自動テストノートブック（オプション） 自動テスト機能を試すには、SageMaker Jupyter ノートブックが必要です。または、Jupyter ノートブックをサポートする統合開発環境（IDE）やその他の環境でノートブックをローカルで実行することもできます。 Amazon SageMaker AI コンソールのナビゲーションペインの “Notebooks” を選択します。 「ノートブックインスタンスの作成」を選択します。 ノートブックに名前を付けます（例：contact-center-rag-testing）。 マルチスレッドテストを有効にするには、ml.m5.2xlarge（8 vCPU）やml.m5.4xlarge（16 vCPU）などの大きなインスタンスを選択することをお勧めします。使用していないときは停止することを忘れないでください。 プラットフォーム識別子のデフォルト設定（Amazon Linux 2、Jupyter Lab 4）を維持します。 「追加設定」の下で、「ボリュームサイズ（GB）」の設定を 50 GB に増やします。 「アクセス許可と暗号化」セクションの「IAMロール」で、ドロップダウンリストから「新しいロールを作成」を選択します（ロール作成ウィザードは使用しないでください）。 「IAMロールの作成」ウィンドウで、アクセスを提供したい S3 バケットを指定できます（このソリューションには必要ありません）。 「ロールの作成」を選択します。 「ノートブックインスタンスの作成」を選択します。 ノートブックインスタンスが利用可能になるまでには数分かかります。作成中に、Amazon Bedrock と Amazon Lex にアクセスするために必要なインラインポリシーを追加するためにIAM ロールを更新できます。 「ノートブックインスタンス」ページで、ノートブックインスタンス（例：contact-center-rag-testing）を開き、“IAM ロール ARN” の下のエントリを選択してロールを開きます。 次のインラインポリシー（GitHubリポジトリの notebooks/iam-roles フォルダで利用可能）を追加します。必要に応じてこれらのロールを修正して、リソースアクセスを制限できます。 bedrock-agents-retrieve.json bedrock-invoke-model-all.json lex-invoke-bot.json opensearch-serverless-api-access.json ノートブックインスタンスが起動した後、「Jupyter を開く」を選択してノートブックを開きます。 以下をノートブックインスタンスにアップロードします（必要に応じて、ファイルをローカルで圧縮し、圧縮アーカイブをアップロードして、SageMaker で解凍することもできます）。 bedrock_helpers.py – このスクリプトはノートブックの LLM インスタンスを設定します。 bedrock_utils – すべてのサブフォルダとファイルをアップロードし、フォルダ構造が正しいことを確認してください。 run_tests.ipynb – このノートブックはテストケースのセットを実行します。 generate_ground_truths.ipynb – 質問のセットが与えられると、このノートブックは潜在的な正解の回答を生成します。 test-runs – このフォルダにはExcelワークブックが含まれているはずです。 run_tests.ipynb ノートブックを開きます。 2 番目のセルで、bot_id と bot_alias_id の値を Amazon Lex ボットの値に置き換えます（これらは RAG ソリューションスタックの「出力」タブで確認できます）。 これらの値を更新した後、“Restart the kernel and run all cells” のアイコンを選択します。 ml.m5.2xlarge インスタンスタイプを使用している場合、 test-runs/test-cases-claude-haiku-2024-09-02.xlsx ワークブックの 50 のテストケースを実行するのに約 1 分かかるはずです。完了すると、ノートブックの test-runs フォルダに対応するテスト結果ワークブックが見つかるはずです。 数分後、会話分析ダッシュボードでもテスト結果を確認できます。 ソリューションをユースケースに適応させる このソリューションは最小限の作業で特定のユースケースに適応させることができます： Amazon Bedrock ナレッジベース のサンプルコンテンツを置き換える – S3バケットのコンテンツを置き換え、ユースケースに合ったフォルダ構造に整理します。置き換えたコンテンツ用に新しいナレッジベースを作成できます。 Amazon Lex ボットのインテントをユースケース用のインテントで置き換える – ユースケース用に有効にしたい対話を反映するように Amazon Lex ボットの定義を変更します。 bedrock_utils コードの LLM プロンプトを変更する – Amazon Lex ボット実行 Lambda 関数で、 bedrock_utils フォルダの LLM プロンプト定義を確認します。例えば、LLMベ ースのエージェントの役割に関するユースケース固有の定義を提供します。 必要に応じてボットハンドラーコードを変更する – Amazon Lex ボット実行 Lambda 関数で、 TopicIntentHandler.py 関数のコードを確認します。知識ベース検索では、このコードはトピックとしてサンプルホテルブランドを使用する例を提供します。このメタデータ検索クエリを、ユースケースに適したものに置き換えることができます。 クリーンアップ おめでとうございます！AWS サービスを使用して音声対応のコンタクトセンター生成 AI エージェントソリューションをセットアップするためのすべての手順を完了しました。 ソリューションを AWS アカウントにデプロイする必要がなくなった場合は、デプロイしたCloudFormation スタック、および作成した場合は SageMaker ノートブックインスタンスを削除できます。 結論 コンタクトセンター 生成 AI エージェントソリューションは、Amazon Bedrock、Amazon Bedrock Knowledge Bases、OpenSearch Serverless、Amazon Lex などのサービスを使用して、コンタクトセンターでの Q&amp;A 会話を自動化するためのスケーラブルで費用対効果の高いアプローチを提供します。 ソリューションコードはオープンソースとして提供されています。これを自分のソリューションの出発点として使用し、GitHub プルリクエストを通じて修正と機能を提供することで、より良いものにするのを手伝ってください。GitHub リポジトリを参照してコードを調査し、最新の変更についてはCHANGELOG を、最新のドキュメント更新については README を確認してください。 専門家のサポートについては、AWS Generative AI Innovation Center、 AWS Professional Services 、および AWS Partners がお手伝いします。 翻訳はソリューションアーキテクト新谷が担当しました。原文は こちら です。

Amazon EC2 Mac インスタンスで、開発者が Apple の システム整合性保護 (SIP: System Integrity Protection) をプログラム的に無効化できるようになりました。ルートレスとも呼ばれるシステム整合性保護 (SIP) は、Apple が OS X El Capitan (2015 年、バージョン 10.11) に導入したセキュリティ機能です。ルートユーザーアカウントの権限を制限することで、害を及ぼす可能性のあるソフトウェアからシステムを保護するように設計されています。macOS では SIP が デフォルトで有効になっています。 SIP は、保護されたファイルやフォルダへの変更を防ぎ、システム所有のファイルやディレクトリへのアクセスを制限し、不正なソフトウェアによる起動ディスクの選択を阻止することで、システムを保護します。SIP の主な目的は、1 つのパスワード、または脆弱性だけでマルウェアがデバイスを完全に制御できるようになる恐れのある、無制限のルートアクセスに関連するセキュリティリスクに対処することです。Apple は、パスワードが弱い、または設定されていない管理者アカウントで操作を行っているユーザーが多いことを特に考慮して、この保護を実装することで macOS ユーザーのためのより高度なセキュリティレベルの確保を目指しています。 SIP は日常的な使用に対して優れたマルウェア防止機能を提供しますが、開発者の場合は、開発やテストの目的で SIP を一時的に無効化しなければならないことがあります。例えば、新しいデバイスドライバやシステム拡張機能を作成するときは、コードをインストールしてテストするために SIP を無効にする必要があります。さらに、SIP は、ソフトウェアが正常に機能するために必要な特定のシステム設定へのアクセスをブロックする場合もあります。SIP を一時的に無効化することで、macOS 用のプログラムを微調整するために必要な許可が付与されますが、これは承認されたメンテナンスのために金庫室の扉を一時的に無効化するようなものであり、永久に開いたままにしておくわけではないのを覚えておくことが重要です。 Mac で SIP を無効化 するには、マシンへの物理的なアクセスが必要です。マシンは、 リカバリモードで再起動 し、 csrtutil コマンドラインツールを使用して SIP を無効にしてから、再び再起動する必要があります。 これまで、EC2 Mac インスタンスでは標準の SIP 設定で作業を行う必要がありました。物理的にアクセスする要件とリカバリモードで起動する必要性は、SIP の Amazon EC2 コントロールプレーンや EC2 API との統合を困難にしていました。これからはその煩わしさがなくなります! Amazon EC2 Mac インスタンスで SIP を自由に無効化し、再度有効化できるようになりました。その方法をご紹介しましょう。 仕組み 私が Amazon EC2 Mac インスタンスを起動したとしましょう。Apple シリコン M2 プロセッサで動作する mac2-m2.metal インスタンスです。SIP の無効化または有効化は、新しい EC2 API: CreateMacSystemIntegrityProtectionModificationTask を呼び出すという簡単なものです。この API は非同期で、インスタンスの SIP ステータスを変更するプロセスを開始します。進捗状況は、もう 1 つの新しい EC2 API である DescribeMacModificationTasks を使用して監視できます。把握しておく必要があるのは、使用したいマシンのインスタンス ID だけです。 前提条件 Apple シリコンベースの EC2 Mac インスタンスや、より最近のマシンタイプでは、新しい EC2 API を呼び出す前に ec2-user ユーザーパスワードを設定し、macOS でそのユーザーの セキュアトークン を有効にする必要があります。これには、マシンに接続して、ターミナルに 2 つのコマンドを入力する必要があります。 # on the target EC2 Mac instance # Set a password for the ec2-user user ~ % sudo /usr/bin/dscl . -passwd /Users/ec2-user New Password: (MyNewPassw0rd) # Enable secure token, with the same password, for the ec2-user # old password is the one you just set with dscl ~ % sysadminctl -newPassword MyNewPassw0rd -oldPassword MyNewPassw0rd 2025-03-05 13:16:57.261 sysadminctl[3993:3033024] Attempting to change password for ec2-user… 2025-03-05 13:16:58.690 sysadminctl[3993:3033024] SecKeychainCopyLogin returned -25294 2025-03-05 13:16:58.690 sysadminctl[3993:3033024] Failed to update keychain password (-25294) 2025-03-05 13:16:58.690 sysadminctl[3993:3033024] - Done # The error about the KeyChain is expected.I never connected with the GUI on this machine, so the Login keychain does not exist # you can ignore this error. The command below shows the list of keychains active in this session ~ % security list "/Library/Keychains/System.keychain" # Verify that the secure token is ENABLED ~ % sysadminctl -secureTokenStatus ec2-user 2025-03-05 13:18:12.456 sysadminctl[4017:3033614] Secure token is ENABLED for user ec2-user SIP ステータスの変更 SIP ステータスを切り替えるためにマシンに接続する必要はありません。必要なのはマシンのインスタンス ID だけです。ノートパソコンでターミナルを開き、 AWS コマンドラインインターフェイス (AWS CLI) を使用して Amazon EC2 Mac のインスタンス ID を取得します。 aws ec2 describe-instances \ --query "Reservations[].Instances[?InstanceType == 'mac2-m2.metal' ].InstanceId" \ --output text i-012a5de8da47bdff7 次に、このままノートパソコンのターミナルを使って、 create-mac-system-integrity-protection-modification-task コマンドで SIP を無効にします。 echo '{"rootVolumeUsername":"ec2-user","rootVolumePassword":"MyNewPassw0rd"}' &gt; tmpCredentials aws ec2 create-mac-system-integrity-protection-modification-task \ --instance-id "i-012a5de8da47bdff7" \ --mac-credentials fileb://./tmpCredentials \ --mac-system-integrity-protection-status "disabled" &amp;&amp; rm tmpCredentials { "macModificationTask": { "instanceId": "i-012a5de8da47bdff7", "macModificationTaskId": "macmodification-06a4bb89b394ac6d6", "macSystemIntegrityProtectionConfig": {}, "startTime": "2025-03-14T14:15:06Z", "taskState": "pending", "taskType": "sip-modification" } } タスクが開始されたら、 aws ec2 describe-mac-modification-tasks コマンドでステータスを確認できます。 { "macModificationTasks": [ { "instanceId": "i-012a5de8da47bdff7", "macModificationTaskId": "macmodification-06a4bb89b394ac6d6", "macSystemIntegrityProtectionConfig": { "debuggingRestrictions": "", "dTraceRestrictions": "", "filesystemProtections": "", "kextSigning": "", "nvramProtections": "", "status": "disabled" }, "startTime": "2025-03-14T14:15:06Z", "tags": [], "taskState": "in-progress", "taskType": "sip-modification" }, ... インスタンスがプロセスを開始し、一連の再起動を行います。その間、インスタンスにはアクセスできなくなります。このプロセスは、完了するまで 60～90 分かかる場合があります。完了後、コンソールのステータスが再び利用可能になったら、いつものように SSH または EC2 Instance Connect 経由でマシンに接続 します。 ➜ ~ ssh ec2-user@54.99.9.99 Warning: Permanently added '54.99.9.99' (ED25519) to the list of known hosts. Last login: Mon Feb 26 08:52:42 2024 from 1.1.1.1 ┌───┬──┐ __| __|_ ) │ ╷╭╯╷ │ _| ( / │ └╮ │ ___|\___|___| │ ╰─┼╯ │ Amazon EC2 └───┴──┘ macOS Sonoma 14.3.1 ➜ ~ uname -a Darwin Mac-mini.local 23.3.0 Darwin Kernel Version 23.3.0: Wed Dec 20 21:30:27 PST 2023; root:xnu-10002.81.5~7/RELEASE_ARM64_T8103 arm64 ➜ ~ csrutil --status System Integrity Protection status: disabled. SIP を無効化する状況 SIP の無効化はシステムを潜在的なセキュリティリスクにさらすことになるため、慎重に行う必要があります。とは言うものの、この記事の冒頭で話したように、macOS 用のデバイスドライバやカーネル拡張機能を開発するときは、SIP の無効化が必要になるかもしれません。古いアプリケーションの中には、SIP が有効になっているときに正しく機能しないものもあります。 SIP の無効化は、Spotlight のインデックス作成を無効にするときにも必要です。Spotlight は、Mac 上のアプリケーション、ドキュメント、E メール、その他アイテムをすばやく見つけるために役立ちます。デスクトップマシンでは非常に便利ですが、サーバーの場合はそうでもありません。ドキュメントの変更に合わせてインデックスを作成する必要がない場合は、Spotlight を無効にすることで 一部の CPU サイクルが解放され、ディスク I/O が軽減されます 。 知っておくべきこと Amazon EC2 Mac での SIP の無効化については、他にも知っておくべき事柄がいくつかあります。 SIP の無効化は、API と AWS SDK 、 AWS CLI 、 AWS マネジメントコンソール を使用して実行できます。 Apple シリコンでは、設定がボリュームベースになっています。そのため、 ルートボリュームを置き換える 場合は、SIP を再度無効にする必要があります。Intel では設定が Mac ホストベースなので、この場合もルートボリュームを置き換えると SIP が無効化されます。 SIP を無効化した後でインスタンスを停止して起動すると、SIP が再び有効になります。インスタンスを再起動しても、インスタンスの SIP ステータスは変わりません。 EBS ボリューム間で SIP ステータスを引き継ぐことはできません。つまり、EBS スナップショットからインスタンスを復元した後や、SIP が有効になっているインスタンスから AMI を作成する場合でも、SIP は再び無効になります。 これらの新しい API は、 Amazon EC2 Mac が提供されているすべてのリージョン で利用でき、追加料金はありません。今すぐお試しください。 – seb 原文は こちら です。 ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載された内容に従って、お客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません)

5 月 20 日は、 AWS Product Lifecycle ページ をご紹介したいと思います。このページは、AWS 全体でのサービス可用性の変更に関する包括的な情報を提供する一元化されたリソースです。 新しい AWS Product Lifecycle ページは、すべてのサービス可用性情報を 1 つの便利な場所にまとめます。この専用リソースでは、1) 新規のお客様へのアクセス提供を終了するサービス、2) サポートの終了が発表されたサービス、3) サポート終了日を迎えたサービスの 3 つの主要変更カテゴリに関する詳細を把握できます。リストされている各サービスに固有のサポート終了日や推奨移行パスを確認し、関連ドキュメントへのリンクにアクセスできるため、サービスの移行をより効率的に計画できます。 AWS Product Lifecycle ページは、ワークロードに影響する可能性のある変更の最新情報を入手するために役立ち、サービス移行のより効率的な計画を可能にします。このリソースの一元的な性質により、サービスのライフサイクル情報を追跡するために必要な時間と労力が削減されるので、管理上のオーバーヘッドではなく、中核的なビジネス目標に集中できるようになります。 5 月 20 日の新しい AWS Product Lifecycle ページでは、以下のサービス変更と機能変更に関するアップデートをご覧いただけます。 2025 年の AWS サービス可用性アップデート 検討を重ねた結果、一部の AWS サービスと機能の可用性変更を発表することになりました。AWS では、サービスまたは機能のサポートを終了するという判断が、お客様の業務に大きな影響を与えることを理解しています。このような判断は、徹底した評価を経た上でのみ行われるものです。サポートの終了が必要な場合は、利用可能な代替サービスや機能に関する詳細なガイダンスと、移行のための包括的なサポートを提供します。 新規のお客様へのアクセス提供を終了するサービス 2025 年 6 月 20 日をもって、新規のお客様に対する以下のサービスまたは機能へのアクセス提供を終了します。既存のお客様は、引き続きサービスをご利用いただけます。 Amazon Timestream for LiveAnalytics サポートの終了が発表されたサービス 以下のサービスはサポート対象外となります。サービス固有のサポート終了日、詳しい移行情報については、個々のサービスドキュメントページをご覧ください。 Amazon Pinpoint AWS DMS Fleet Advisor AWS IQ AWS IoT Analytics AWS IoT Events AWS SimSpace Weaver AWS Panorama Amazon Inspector Classic Amazon Connect Voice ID サポート終了日を迎えたサービス 以下のサービスはサポート終了日に到達したため、アクセスできなくなりました。 AWS Private 5G AWS DataSync Discovery AWS Product Lifecycle ページ が利用可能になり、新しいページにはこの記事で説明したすべての変更が掲載されています。このページをブックマークするとともに、「 AWS の最新情報 」をチェックして、今後の AWS サービス可用性アップデートを確認することをお勧めします。この新しいリソースの使用方法の詳細については、 AWS または通常の AWS サポート連絡先に連絡して、影響を受けるワークロードの移行に関する具体的なガイダンスを受けてください。 – seb 原文は こちら です。

5 月 19 日は、AWS クラウドインフラストラクチャでの最新イノベーションを包括的に紹介する AWS Cloud Infrastructure Day をご紹介します。このイベントでは、コンピューティング、 人工知能と機械学習 (AI/ML) 、ストレージソリューション、ネットワーク機能、サーバーレス、アクセラレーテッドテクノロジー、およびグローバルインフラストラクチャの全体における最先端の進歩に焦点を当てます。 2025 年 5 月 22 日の午前 11 時 (米国太平洋夏時間) (米国東部夏時間の午後 2 時) から開催される 1 日限りの無料バーチャルイベント、AWS Cloud Infrastructure Day にぜひご参加ください。このイベントは、 LinkedIn Live 、 Twitter 、 YouTube 、 Twitch などの複数のプラットフォームで同時にストリーミングされます。 このイベントで予定されているハイライトをいくつかご紹介しましょう。 イベントのオープニングとして、 顧客を第一に考えるイノベーションという目標を掲げて Amazon Elastic Compute Cloud (Amazon EC2) がリリースされた 2006 年から AWS が辿ってきた道のりを、VP of EC2 Technology である Willem Visser が紹介します。Visser は、規模、キャパシティ、柔軟性に基づいてスタートアップワークロードとエンタープライズワークロードの両方をサポートするために、ほぼ 20 年の年月をかけてクラウドインフラストラクチャで達成されてきた進歩について語ります。 ストレージ機能やネットワーク機能といったサービスの並行的な進化など、AWS が完全なクラウドインフラストラクチャを創り出すためにコンピューティングインスタンスの域を超えた開発をどのように行ったのかを学ぶことができます。 GoDaddy の Principal Engineer である Todd Kennedy 氏は、GoDaddy の Graviton 導入ジャーニーと、Graviton から得たメリットを共有します。Kennedy 氏は、Rust ワークロードの Graviton への移行を明らかにする例も説明します。GoDaddy が 40% のコンピューティングコスト削減と、20% を超えるパフォーマンス向上を達成した方法を学びましょう。 このイベントでは、AWS クラウドインフラストラクチャに関連するさまざまなトピックを取り上げます。私が関心を持った興味深いトピックには、以下のようなものがあります。 エッジでの生成 AI – AWS のハイブリッドサービスとエッジサービス を使用して、データレジデンシー要件をきっかけとしたオンプレミスユースケースとエッジユースケースのための小規模言語モデル (SLM) を選択し、ファインチューニングして、デプロイする方法を学ぶことができます。 エージェント型 AI の監査性のためのサーバーレス – AWS Step Functions や AWS Lambda が不透明なエージェント型 AI システムの運用を透明かつ監査可能なワークフローに変換する方法を学ぶことができます。 アクセラレーテッドコンピューティング – サーバー、データセンター、 シリコンでの AWS のイノベーション を詳しく検証して、お客様が AI チップをどのように使用しているのかを学びます。生成 AI の使用を開始して、コストを削減する方法をご覧ください。 ネットワーク機能 – 物理的なファイバーネットワークからソフトウェア定義のネットワークまで、AWS のインフラストラクチャが比類のないパフォーマンスと信頼性を世界的な規模で実現する方法を学ぶことができます。このセッションでは、ハイブリッド環境のためのセキュアな接続ソリューションに重点を置きながら、最新のアプリケーションネットワークパターンについて説明します。 このイベントは、技術面での意思決定者や開発者に最適で、深い技術的インサイトと、最新の AWS クラウドインフラストラクチャソリューションの実践的なデモを提供します。 詳細については、イベントスケジュールを確認して、 AWS Cloud Infrastructure Day に登録してください。 – Channy 原文は こちら です。 ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載された内容に従って、お客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません)

コンテナワークロードを実行するときは、ソフトウェア脆弱性がリソースのセキュリティリスクをどのように引き起こすかを理解する必要があります。これまで、 Amazon Elastic Container Registry (Amazon ECR) イメージの脆弱性を特定することはできましたが、これらのイメージがコンテナ内でアクティブかどうかを判断したり、その使用状況を追跡したりすることはできませんでした。これらのイメージが実行中のクラスターで使用されているかどうかを把握できなかったため、実際のデプロイや使用パターンに基づいて修正を優先順位付けする能力にも限界がありました。 5 月 19 日より、 Amazon Inspector が脆弱性管理を強化する 2 つの新機能の提供を開始し、コンテナイメージをより包括的に確認できるようになりました。まず、Amazon Inspector が Amazon ECR イメージを実行中のコンテナにマッピングするようになりました。このため、セキュリティチームは環境内で現在実行されているコンテナに基づいて脆弱性の優先順位付けを行えるようになります。これらの新機能を使用することで、Amazon ECR イメージの脆弱性を分析するとともに、それらが現在実行中かどうか、コンテナ環境で最後に実行されたのはいつだったかに基づいて、検出結果に優先順位を付けることができます。さらに、クラスターの Amazon リソースネーム (ARN) を表示し、イメージがデプロイされている EKS ポッドまたは ECS タスクの数を確認することもできます。これは、使用状況と重大度に基づいた修正の優先順位付けに役立ちます。 次に、脆弱性スキャンのサポートを最小限のベースイメージ (scratch、distroless、Chainguard イメージなど) に拡張するとともに、 Go Toolchain 、 Oracle JDK および JRE 、 Amazon Corretto 、 Apache Tomcat 、 Apache httpd 、 WordPress (コア、テーマ、プラグイン)、 Puppeteer などの追加のエコシステムに対するサポートも拡張しました。これらの拡張は、チームが高度に最適化されたコンテナ環境でも堅牢なセキュリティを維持するために役立ちます。 Amazon Inspector は、コンテナ上で実行されているイメージを継続的に監視して追跡することで、どのコンテナイメージが環境内でアクティブに実行されており、それらがどこにデプロイされているかをチームが特定できるようにして、 Amazon Elastic Container Service (Amazon ECS) や Amazon Elastic Kubernetes Service (Amazon EKS) 内のコンテナで実行されている Amazon ECR イメージと、関連する脆弱性を検出します。このソリューションは、委任された管理者機能を用いて単一の AWS アカウント 、クロスアカウントシナリオ、および AWS Organizations の全体で Amazon ECR イメージを管理するチームをサポートし、コンテナイメージの実行パターンに基づく一元化された脆弱性管理を可能にします。 実際の動作を見てみましょう Amazon ECR イメージスキャン は、リポジトリの継続的な自動スキャン機能を提供するために Amazon Inspector と統合する 拡張スキャン を使用して、コンテナイメージ内の脆弱性を特定できるようにします。この新機能を使用するには、 Amazon ECR コンソール で拡張スキャンを有効にする必要があります。拡張スキャンは、「 Configuring enhanced scanning for images in Amazon ECR 」ドキュメントページの手順に従って有効化できます。 私は Amazon ECR 拡張スキャン機能を既に有効化しているので、追加のアクションは必要ありません。 Amazon Inspector コンソール のナビゲーションパネルにある [ 全般設定 ] に移動し、[ ECR scanning settings ](ECR スキャン設定) を選択します。ここでは、[ Last in-use date ](最終使用日) と [ Last pull date ](最終プル日) のいずれかを選択して [ Image re-scan mode ](イメージの再スキャンモード) を設定できます。ここではデフォルトの [ Last in-use date ](最終使用日) を使用し、[ Image last in use date ](イメージの最終使用日) を [14 days](14 日) に設定します。これらの設定により、過去 14 日の間に私の Amazon ECS または Amazon EKS 環境でイメージがいつ実行されたかに基づいて、Inspector がイメージを監視するようになります。これらの設定を適用すると、Amazon Inspector がコンテナで実行されているイメージに関する情報の追跡を開始し、その情報を脆弱性検出結果に組み込むようになるため、環境内のコンテナでアクティブに実行されているイメージに焦点を当てることができるようになります。 設定が完了したら、コンテナで実行されているイメージに関する情報が [ 詳細 ] メニューに表示されます。ここでは、EKS ポッドまたは ECS タスクの数とともに、最終使用日と最終プル日を確認できます。 [ Deployed ECS Tasks/EKS Pods ](デプロイされた ECS タスク/EKS ポッド) の数を選択すると、各イメージのクラスター ARN、最終使用日、タイプを確認できます。 クロスアカウントの可視性デモのため、2 つのアカウントに EKS ポッドがデプロイされたリポジトリを用意しました。[ Resources coverage ](リソースカバレッジ) メニューで [ Container repositories ](コンテナリポジトリ) に移動し、リポジトリ名を選択してから、[ Image tag ](イメージタグ) を選択します。以前と同様に、デプロイされた EKS ポッド/ECS タスクの数を確認できます。 デプロイされた EKS ポッド/ECS タスクの数を選択すると、それが別のアカウントで実行されていることがわかります。 [ 検出結果 ] メニューでは脆弱性を確認でき、そのうちの 1 つを選択すると、[ 影響を受けるリソース ] データで [ Last in use ](最終使用) 日と、脆弱性に関係する [ Deployed ECS Tasks/EKS Pods ](デプロイされた ECS タスク/EKS ポッド) を見つけることができます。これは、実際の使用状況に基づいて修正の優先順位付けを行うために役立ちます。 [ すべての検出結果 ] メニューでは、[ Account ID ](アカウント ID)、[ Image in use count ](使用中のイメージ数)、[ Image last in use at ](イメージの最終使用日) などのフィルターを使用して、アカウント管理内の脆弱性を検索できるようになりました。 主な機能と考慮事項 コンテナイメージのライフサイクルに基づく監視 – Amazon Inspector は、イメージのプッシュ日 (期間範囲は 14 日、30 日、60 日、90 日、180 日、または lifetime (ライフタイム))、イメージのプル日 (14 日、30 日、60 日、90 日、または 180 日)、停止期間 (Never (停止なし) から 14 日、30 日、60 日、90 日、または 180 日)、およびコンテナで実行されているイメージのステータスに基づいてイメージのアクティビティを判断できるようになりました。この柔軟性により、組織はその監視戦略をリポジトリイベントだけでなく、実際のコンテナイメージの使用状況に基づいてカスタマイズできるようになります。Amazon EKS と Amazon ECS のワークロードについては、最終使用、プッシュ期間、プル期間が 14 日に設定されており、これが新規のお客様のデフォルトになりました。 イメージランタイム対応の詳細情報 – 修正作業の優先順位付けを支援するため、Amazon Inspector の各検出結果には、コンテナでのイメージの最終実行日を示す lastInUseAt 日付と、イメージを現在使用しているデプロイされた EKS ポッド/ ECS タスクの数を示す InUseCount が含まれるようになりました。Amazon Inspector は、すべてのアカウントの Amazon ECR 最終プル日のデータと、Amazon ECS タスクまたは Amazon EKS ポッドコンテナで実行されているイメージのデータの両方を監視し、この情報を少なくとも 1 日 1 回更新します。Amazon Inspector はこれらの詳細情報をすべての検出結果レポートに統合し、 Amazon EventBridge とシームレスに連動します。検出結果は、ローリングウィンドウまたは固定範囲のオプションを使用する lastInUseAt フィールドに基づいてフィルタリングできます。また、過去 14 日、30 日、60 日、または 90 日間の最終実行日に基づいてイメージをフィルタリングすることも可能です。 包括的なセキュリティカバレッジ – Amazon Inspector は、単一のサービスを通じて、従来の Linux ディストリビューションと、最小限のベースイメージ (scratch、distroless、Chainguard イメージなど) の両方に対する統合脆弱性評価を提供できるようになりました。拡張されたカバレッジにより、複数のスキャンソリューションを使用する必要がなくなるのと同時に、従来のディストリビューションから高度に最適化されたコンテナ環境におよぶコンテナエコシステム全体で堅牢なセキュリティプラクティスを維持することができます。このサービスは、一元化されたプラットフォームを通じた包括的な脆弱性管理を提供することでセキュリティ業務を合理化し、あらゆるコンテナタイプの効率的な評価を可能にします。 強化されたクロスアカウント可視性 – 単一アカウント、クロスアカウント設定、AWS Organizations 全体でのセキュリティ管理が、委任された管理者機能を通じてサポートされるようになりました。Amazon Inspector は、同じ組織内のコンテナで実行されているイメージの情報を共有します。これは、ゴールデンイメージリポジトリを維持しているアカウントにとっては特に有用です。Amazon Inspector は、リソースが API を使用するアカウントに属している場合、イメージが実行されている Amazon EKS クラスターと Amazon ECS クラスターのすべての ARN を提供するため、複数の AWS アカウント全体に対する包括的な可視性が得られます。システムは、デプロイされた EKS ポッドまたは ECS タスクの情報を少なくとも 1 日 1 回更新し、アカウントが組織に参加または離脱するときも正確性を自動的に維持します。 利用可能性と料金 – 新しいコンテナマッピング機能は、 Amazon Inspector が提供されている すべての AWS リージョン で利用でき、追加料金はありません。使用を開始するには、 AWS Inspector ドキュメント をご覧ください。料金の詳細と提供されているリージョンについては、 AWS Inspector の料金表ページ を参照してください。 追記: AWS でのブログ記事の執筆は、常にチームとしての取り組みです。これは、記事のタイトルの下に 1 人の名前しか表示されない場合でも同様です。今回は、テクニカルガイダンスでの惜しみない援助と、専門知識を提供してくれた Nirali Desai に感謝の意を述べたいと思います。この包括的な概要をまとめることができたのは彼女のおかげです。 –&nbsp; Eli 原文は こちら です。 ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載されているとおりにお客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません)

みなさん、こんにちは。ソリューションアーキテクトの深見です。OpenSearch Magazine の第 2 号をお届けいたします。本号では Amazon OpenSearch Service の最近のアップデート情報と、先日リリースされました OpenSearch 3.0 をはじめ OSS の OpenSearch Project にまつわるアップデートからピックアップしてご紹介します。また Hot Topic として OpenSearch のクエリを最適化する手助けになる機能の１つである Query Insights についてご紹介します。 OpenSearch Magazine は、 Amazon OpenSearch Service およびオープンソース版 OpenSearch の最新動向をキャッチアップいただくべく開設されました。開設の経緯や Amazon OpenSearch Service の概要につきましては、「 OpenSearch Magazine 開設のお知らせ 」よりご確認いただけます。 マネージドサービスのアップデート 直近でリリースされた、 Amazon OpenSearch Service に関する注目のアップデートについてご紹介していきます。 Amazon OpenSearch Service が OpenSearch バージョン 2.19 のサポートを開始 2025 年 4 月 30 日に Amazon OpenSearch Service で OpenSearch 2.19 を利用できるようになりました。OpenSearch 2.19 でのアップデートの中から ２ つピックアップしてご紹介します。 まずは、ハイブリッド検索において RRF（Relative Range Factor) が利用可能になりました。RRF は複数の検索システムの結果を順位の逆数をもとに並び替えるアルゴリズムです。 具体的な数式は、システム $r$ における文書 $d$ の順位 $r(d)$ とハイパーパラメーターである $k$ を用いて次のように計算されます。 この数式の意味を見ていきましょう。 まず、合成したいクエリ（ハイブリッド検索の場合、全文検索とベクトル検索）ごとに検索を実施します。 合成したい複数のクエリごとのランキング結果がでると、ドキュメントごとの順位の逆数をスコアとします。 クエリごとのスコアをそれぞれのドキュメントについて足し合わせることで最終的なスコアとする、と言った流れになります。 ハイブリッド検索を用いる際にベクトル検索のスコアと全文検索のスコアではスケールが異なることから単純にそのスコアをもとに並び替えをしてしまうと検索結果にバイアスが加わってしまいます。しかし、全文検索のスコアは相対的な値でありクエリやドキュメントの母集団によって異なったスケールをもつ値になるためベクトル検索のスコアと組み合わせるには複雑な計算が必要になってしまいます。そこで、RRF ではそれぞれの検索結果の順位を利用することでバイアスを軽減しながら検索結果の統合とリランクが可能になります。 ハイブリッド検索を利用する際には多くの場面で利用されているアルゴリズムのため、待望のアップデートでありました。OpenSearch で利用する場合は search pipeline 上の reranker として設定することで利用できます。 PUT /_search/pipeline/rrf-pipeline { "description": "Post processor for hybrid RRF search", "phase_results_processors": [ { "score-ranker-processor": { "combination": { "technique": "rrf", "rank_constant": 40 } } } ] } こちらのブログ でも詳しく紹介されていますので、合わせてご確認ください。 次に紹介するのは、 ML inference search です。ML inference search を利用することで、検索を行うロジックの前後で ML モデルを呼び出すことでクエリのリクエストやレスポンスの内容を書き換えたりエンリッチしたりすることができる機能になります。非常に柔軟な検索クエリを別のコンポーネントを用意することなく実現できます。例えば、クエリ対象の文字列を Embedding モデルに渡してベクトルに変換したり、LLM にわたすことでクエリ文字列とは違う表現の文章でエンリッチした上で検索を実施するといったことが可能になります。 レスポンスプロセッサー は 2.18 で、 リクエストプロセッサー が 2.19 で利用可能になっています。 その他にも、後述のHot Topicで紹介する Query Insights dashboard など多くのアップデートがありました。詳細は、 リリースブログ や リリースノート をご覧ください。 Amazon OpenSearch Ingestion のガイド付きビジュアルパイプラインビルダーの導入 2025 年 4 月 22 日のアップデートにより、 Amazon OpenSearch Ingestion で UI 上からパイプラインの構築が可能になるビジュアルパイプラインビルダーが利用可能になりました。これまでは、OpenSearch Ingestion のパイプラインを作成する際にはブループリントをベースにリソース ARN などの各種パラメータをユーザーが手書きする必要がありました。このアップデートにより、UI 上に表示される候補からリソースを選択することで自動でブループリントに入力がされるようになり、簡単にパイプラインを構築できるようになりました。 詳細は、こちらの ブログ をご確認ください。 OpenSearch Project の最新動向 OpenSearch Project では、2025 年 5月 6 日に OpenSearch 3.0 がリリースされました！OpenSearch 3.0 では多数のアップデートや新機能が追加されていますが、ベースとなる検索クエリのパフォーマンス向上に注目いただきたいです。詳細はぜひこちらの ブログ をご確認いただきたいところですが、 OpenSearch Big5 ワークロード において 以前までの最新バージョンである 2.19 と比べて 約 24% 高速 であるという結果になっています。これは、OpenSearch のベースの検索ライブラリである Apache Lucene や Java ランタイムのバージョンアップや OpenSearch 内部のロジックの最適化が要因となっています。 他にも、生成AI 界隈で注目のまとである MCP が OpenSearch にも登場しました。OpenSearch の MCP 関連機能では、OpenSearch への検索をエージェントに行わせるために利用できる MCP 組み込みサーバーの機能とOpenSearch の中のエージェントから外部の MCP サーバーを利用するための MCP クライアントの両面の機能が登場しています。詳細は、 OpenSearch における MCP の紹介ブログ をご覧ください。 3.0 に関するアップデートの詳細は、 リリースノート や リリースブログ をご確認ください。OpenSearch 3.0 は2025 年 5月時点でまだマネージドサービスの OpenSearch Service では利用できませんが、今後のアップデートが楽しみですね！ Hot Topic : Query Insights を使ったクエリ最適化 今号のHot Topic として Query Insights と その機能を OpenSearch Dashboard の UI で利用できる Query Insights dashboard についてご紹介します。 OpenSearch を利用して検索のやログ監視といったワークロードを運用していると、クエリが遅く感じ改善しようとされることは少ないありません。もしくは、一定の期間についてリソース使用量がスパイクしているような場合、その原因を探索することが求められる場合もあります。そういった際に、どのようなメトリクスを見て改善方法や問題の原因を検討するのが良いでしょうか？そう言った際に利用できる機能の１つが Query Insights になります。 Query Insights を利用することで、クエリの実行時間、CPU使用率、メモリ使用量などの主要なメトリクスを基準に設定した上位 N 件のクエリを履歴として保持することができます。また、クエリでつかわれている API やその構造をもとに類似しているクエリをグルーピングしたうえで、その中の上位 N 件のクエリグループを表示することもできます。 レイテンシーやリソース使用量について影響の大きなクエリを見つけることで、クエリ自体の改善やパターンに基づく予防策の検討に役立てることができます。 このように重要なメトリクスを追跡できる Query Insights ですが、2.19 より OpenSearch Dashboard の UI 上から 確認することができるようになりました。 UI 上ではクエリの履歴とそれに紐づく各メトリクスを確認することができます。この画面ではレイテンシーを基準に上位 N 件のクエリを探索するといったように、それぞれの項目をもとに履歴を並べかえることが可能です。また、期間やコーディネータノード ID でのフィルタや検索も可能です。 クエリの詳細ページでは、実際にどのようなクエリが実行されたのかや、実行タイムスタンプ、CPUとメモリの使用量、フェーズレベルのレイテンシー、インデックス、ノード、シャードなどのメタデータが確認可能です。 設定画面からは、メトリクスごとに上位何件を追跡するのか、グルーピング、履歴の保持期間や保存先の index の設定が可能です。 このように管理者がクエリパフォーマンスを監視する場合でも、開発者が特定のクエリの問題を調査する場合でもダッシュボード上から簡単にクエリの履歴の探索が可能になります。クエリのパフォーマンスに関してお悩みの場合はぜひ Query Insights dashboard をのぞいてみてください。 セットアップ手順と使用方法については、 Query Insights dashboards を参照してください。 まとめ 本号では、Amazon OpenSearch Service の最新アップデートとして、バージョン 2.19 に関連して RRF 対応と ML Inference の機能、OpenSearch Ingestion の ビジュアルパイプラインビルダーをご紹介しました。また OpenSearch Project のアップデートから、3.0 のアップデートの中からパフォーマンスの向上についてと MCP の機能をピックアップしてご紹介しました。そして、OpenSearch のクエリパフォーマンスを改善するのに有効な Query Insights という機能について解説しました。 今号の内容は以上になります。また次回をお楽しみに！ OpenSearch Project のロードマップは、 OpenSearch Project サイト および Github 上で公開されています。OpenSearch のロードマップについてご興味がございましたら、是非これらの情報をご確認ください。 https://opensearch.org/blog/opensearch-project-roadmap-2024-2025/ https://github.com/orgs/opensearch-project/projects/206 著者について ソリューションアーキテクト 深見 修平 (Shuhei Fukami) 2021 年に AWS Japan に Solutions Architect として入社しました。現在は Analytics SAとして Amazon OpenSearch Service をはじめ、AWS Glue、Amazon SageMaker LakeHouse などの Analytics Service にまつわるお客様のデータ分析やビッグデータ処理にまつわるシステムの導入および活用を支援しています。

本記事は、2024 年 12 月 4 日に公開された Build generative AI applications quickly with Amazon Bedrock in SageMaker Unified Studio を翻訳したものです。翻訳は Solutions Architect の 濱野谷(yoshiehm@) が担当しました。 生成 AI アプリケーションの構築は、組織にとって大きな課題となっています。専門的な ML の知識、複雑なインフラストラクチャ管理、そして複数のサービスの適切な連携が必要だからです。これらの課題に対応するため、生成 AI アプリケーションの開発とカスタマイズのための統合環境である Amazon Bedrock in SageMaker Unified Studio を紹介します。以前は Amazon Bedrock Studio として知られていた Amazon Bedrock in SageMaker Unified Studio は、 Amazon SageMaker Unified Studio に統合されました。Amazon SageMaker Unified Studio は、 Amazon Bedrock 、 Amazon SageMaker 、 Amazon Redshift 、 Amazon Glue 、 Amazon Athena 、 Amazon Managed Workflows for Apache Airflow (MWAA) などの AWS サービスを、包括的なデータ・ AI 開発プラットフォームに統合しています。このブログ記事では、Amazon SageMaker Unified Studio 環境における Amazon Bedrock in SageMaker Unified Studio とその生成 AI 機能に焦点を当てます。 複数のリージョンや国にまたがってグローバルに展開する小売サイトを考えてみましょう。セールスアナリストたちは日々、次のような課題に直面しています。データドリブンな意思決定を行う必要がありますが、膨大な情報量に圧倒されています。データベースに保存された販売取引や収益指標などの構造化データと、様々なチャネルから収集された顧客レビューやマーケティングレポートなどの非構造化データがあります。これらのアナリストは、SQL (構造化クエリ言語) の専門知識や RAG (Retrieval Augmented Generation) の専門知識がないため、両方のソースからのインサイトを効果的に組み合わせることに苦労しています。 この記事では、社内の誰もが Amazon Bedrock in SageMaker Unified Studio を使用して、販売実績データを分析する生成 AI チャットエージェントアプリケーションを素早く作成する方法をご紹介します。ビジネスチームは、このチャットエージェントとの簡単な会話を通じて、コードを書いたり複雑なデータパイプラインを管理したりすることなく、構造化データと非構造化データの両方から価値のあるインサイトを引き出すことができます。次の図は、 Amazon Bedrock in SageMaker Unified Studio を使用した AI アシスタントの概念アーキテクチャを示しています。 ソリューションの概要 Amazon Bedrock in SageMaker Unified Studio に作成した AI チャットエージェントアプリケーションは、構造化データと非構造化データの両方の分析結果を組み合わせることができます。 構造化データの場合 : Amazon Athena の販売記録に接続し、自然言語を SQL クエリに変換します 非構造化データの場合 : Amazon Titan Text Embeddings と Amazon OpenSearch を使用して、カスタマーレビューやマーケティングレポートに対してセマンティック検索を実現します Amazon Bedrock in SageMaker Unified Studio のインターフェースは、両方のソースからの結果をシームレスに組み合わせ、基盤となるデータ構造やクエリ言語をユーザーが理解する必要なく、包括的なインサイトを提供します。次の図は、ユーザーの初期操作から最終的なレスポンスまでのワークフローを示しています。ユーザーインタラクションフローの詳細については、関連する GitHub リポジトリ をご確認ください。 ソリューションアーキテクチャ 前図のアーキテクチャは、 Amazon Bedrock in SageMaker Unified Studio がどのようにデータフローを調整するかを示しています。ユーザーが自然言語インターフェースを通じて質問を投げかけると、チャットエージェントは、Amazon SageMaker Unified Studio の Amazon Bedrock 機能を通じて Amazon Athena の構造化データをクエリするか、Amazon Bedrock のナレッジベースを検索するか、または包括的なインサイトを得るために両方のソースを組み合わせるかを判断します。このアプローチにより、営業、マーケティング、製品、サプライチェーンのチームは、技術的な専門知識に関係なく、効率的にデータ駆動型の意思決定を行うことができます。たとえば、このチュートリアルを終えると、「今四半期のトップ 5 の売れ筋商品と、それぞれの主要な顧客の苦情を教えてください」や「衣料品の北米市場に影響を与えたサプライチェーンの問題はありましたか？」といったプロンプトでデータをクエリできるようになります。 以下のセクションでは、Amazon SageMaker Unified Studio プロジェクトのセットアップ、ナレッジベースの作成、自然言語クエリインターフェースの構築、およびソリューションのテストについて説明します。 Amazon SageMaker Unified Studio のセットアップ Amazon SageMaker Unified Studio は、すべてのデータとツールを使用できる分析と AI のためのブラウザベースのウェブアプリケーションです。Amazon SageMaker Unified Studio では、 AWS Identity and Access Management (IAM) の認証情報、 AWS IAM アイデンティティセンター を通じた IdP の認証情報、または SAML 認証情報を利用できます。 Amazon DataZone の AWS Management Console にアクセスすることで、ドメインの Amazon SageMaker Unified Studio の URL を取得できます。Amazon SageMaker Unified Studio をセットアップするには、 管理者ガイド の手順に従ってください。 生成 AI アプリケーションの構築 Amazon SageMaker Unified Studio は、生成 AI を探索し構築するためのツールを提供します。まずはプロジェクトを作成する必要があります。 Amazon SageMaker Unified Studio を開き、ページ上部の Generative AI playground を選択します。 ここでは、 chat インターフェースを通じて、さまざまな基盤モデル (FM) を探索、試行、比較することができます。 同様に、 Image &amp; video playground で画像と動画のモデルを試すことができます。 チャットエージェントの作成を開始するには、チャットプレイグラウンドウィンドウで Build chat agent を選択します。アプリを構築する前に、新しいプロジェクトを作成します。 Create project を選択してください。 プロジェクト名を入力します。次に、利用可能なプロファイルから Generative AI application development を選択します。このプロファイルには、生成 AI アプリケーション開発で Amazon Bedrock コンポーネントを使用するために必要なすべての要素が含まれています。 Continue を選択します。 次の画面では、すべての設定をデフォルト値のままにしておきます。 Continue を選択して次の画面に進み、 Create Project ボタンを選択してプロジェクトの作成プロセスを開始します。プロジェクトのセットアップが完了するまで数分かかります。 プロジェクトを作成したら、生成 AI アプリケーションの構築を開始します。 前提条件 Amazon SageMaker Unified Studio で Amazon Bedrock のアプリケーションを作成する前に、AWS アカウントでいくつかのリソースをセットアップする必要があります。これにより、セールス分析アプリケーションが依存するバックエンドインフラストラクチャとサービスがプロビジョニングされます。これには、構造化された売上データのクエリを可能にするために、 Amazon API Gateway 、 AWS Lambda 関数 、Amazon Athena のセットアップが含まれます。 必要な AWS リソースをデプロイします： 任意の AWS リージョンで AWS CloudFormation スタックを起動します： スタックのデプロイ後、CloudFormation の出力タブから API Gateway URL の値 TextToSqlEngineAPIGatewayURL をメモしてください。 AWS Secrets Manager コンソールに移動し、シークレット &lt;StackName&gt;-api-keys を見つけます。 シークレットを取得 を選択し、以下のプレーンテキスト文字列から apiKey の値をコピーしてください。 {"clientId":"default","allowedOperations":["query"],"apiKey":"xxxxxxxx"} 後で Amazon Bedrock in SageMaker Unified Studio を設定する際に、これらの値が必要になります。 3 つのサンプルデータファイルをダウンロードします。これらのファイルには、生成 AI モデルによって生成された合成データが含まれており、ナレッジベースの構築に使用する顧客レビュー、顧客アンケートの回答、世界のニュースが含まれています： product-reviews.txt – ユーザーからの製品ごとのレビュー survey-response.txt – アンケートを通じて収集したユーザーフィードバック world-news.txt – 最近の業界および経済ニュース API 設定をダウンロードします： openapi_schema.json 。このファイルは、売上データを照会する関数のセットアップ時に使用します。 以上です！これらのリソースが準備できたら、セールス分析アプリケーションを作成できます。以降のセクションでは、これらのファイルをいつ、どのように使用するかを詳しく説明します。 チャットエージェントの指示設定 Amazon Bedrock in SageMaker Unified Studio のチャットエージェントアプリケーション に移動します。ドロップダウンからモデルを選択します (これは後で変更可能です – データと機能をサポートしていることを確認してください)。チャットエージェントの指示フィールドに以下を入力します： You are a Sales Analytics agent with access to sales data in the "sales" database, table "sales_records". Your tasks include analyzing metrics, providing sales insights, and answering data questions. Table Schema: - region, country: Location data - item_type: Product category - sales_channel: Online/Offline - order_priority: H/M/L/C - order_date, ship_date: Timing - order_id: Unique identifier - units_sold: Quantity - unit_price, unit_cost: Price metrics - total_revenue, total_cost, total_profit: Financial metrics. Use Amazon Athena SQL queries to provide insights. Format responses with: 1 SQL query used 2 Business interpretation 3 Key insights/recommendations You can also access sales-repo which contains details on products categories, customer reviews, etc. Error Handling: - If the user's query cannot be translated into a valid SQL query, or the SQL is invalid or fails to execute, provide a clear and informative error message. この指示により、AI アプリケーションは販売分析エージェントとして機能し、与えられた販売データスキーマに基づいて、製品レビューやその他の販売関連データにアクセスしながら、構造化された応答を提供します。 このアプリケーションでは、非構造化データを処理するためのナレッジベースと、構造化データを照会するために Amazon Athena を使用する関数という 2 つの主要なコンポーネントを作成します。これらのコンポーネントは連携して、生成 AI アプリケーションの情報処理と取得を行います。 ナレッジベースの作成 ナレッジベースを使用すると、アプリケーションでカスタマーレビューやニュース記事などの非構造化データを分析できます。 現在のチャットエージェント画面で Data セクションを選択します。 Create new Knowledge Base を選択し、新しいナレッジベースの名前を入力します。また、チャットエージェントがこのナレッジベースの目的を理解できるように、簡単な説明を入力する必要があります。 This contains product-specific reviews from users, user feedback gathered via survey, and recent industry and economic news ナレッジベースのデータソースを設定するには、ローカルファイルを使用するか、Web クローラーを設定するという 2 つのオプションがあります。Web スクレイピングは、アクセス権のある公開 Web ページからコンテンツを自動的に抽出します。ツールに Web サイトの URL を追加すると、これらのサイトをクロールし、定義されたすべての URL からナレッジベースを作成します。このプロセスにより、複数の Web ソースから効率的に情報を収集して構造化し、必要に応じた包括的なデータセットを構築できます。 この記事では、前述の非構造化データを含むファイル ( product-reviews.txt 、 survey-response.txt 、 world-news.txt ) をアップロードします。 Click to upload を選択し、3 つのファイルをアップロードします。パース設定はデフォルトのままにしてください。 埋め込みモデルとして、 Amazon Titan Text Embeddings V2 または他の埋め込みモデルを選択します。 ベクトルストアとして OpenSearch Serverless を選択します。 これらの選択を行った後、 Create を選択してナレッジベースを作成します。 ナレッジベースの作成が完了したら、 Select Knowledge Base ドロップダウンからアプリケーション用のナレッジベースを選択します。 この非構造化データは、生成 AI アプリケーションのナレッジベースを強化するために使用され、カスタマーレビュー、アンケート回答、ビジネス分野に関連する最新ニュースに基づいて、情報を処理しインサイトを提供できるようになります。 非構造化データの接続が正しく機能していることを確認するために、このサンプルプロンプトをアプリケーションに送信してください。生成 AI システムは非決定論的であるため、応答は毎回同じにはならないことに注意してください。 プロンプト: What is the customer sentiment surrounding our Office Supplies products? 期待されるレスポンス: Based on the customer reviews and feedback, the sentiment surrounding our Office Supplies products is mixed. While there are many positive reviews praising the product selection, store environment, and helpful staff, there are also a significant number of negative reviews citing issues like: Poor product quality (e.g. flimsy materials, inconsistent paper quality, adhesive issues) Frustrating in-store experiences (e.g. long wait times, rude staff, messy/disorganized stores) Problems with online ordering and apps (e.g. filters not working properly, payment issues, logging out repeatedly) To improve customer sentiment, we should focus on addressing these common pain points through better quality control, more efficient inventory management and staffing, and improving the online/app user experience. 関数の作成 このセクションでは、Amazon API Gateway と連携してデータベースにクエリを実行する関数を作成します。このクエリは Lambda 関数に転送され、Lambda 関数では Amazon Athena を使用して SQL クエリを処理し、 Amazon Simple Storage Service (Amazon S3) からデータを取得します。これらの AWS インフラストラクチャは、CloudFormation テンプレートの一部としてすでにデプロイされています。構造化データセットには、2010 年から 2017 年までの製品の注文情報が含まれています。この過去のデータにより、関数は 7 年間にわたる売上傾向、製品パフォーマンス、その他の関連指標を分析することができます。このアプリケーションは、この関数を使用して構造化データ分析機能を統合し、すでに組み込まれているレビューやニュースからの非構造化データと共に、具体的な売上データに基づくインサイトを提供できるようにします。 Amazon Bedrock in SageMaker Unified Studio のチャットエージェントアプリケーションで、画面上の Functions セクションを展開します。 Create New Function を選択します。 関数の名前を入力し、説明を記入します。 関数スキーマについては、 Import JSON/YAML を選択します。先ほどダウンロードした openapi_schema.json ファイルから API スキーマをインポートします。 重要：インポート後、スキーマ内の API エンドポイント URL を変更する必要があります。CloudFormation スタックの出力 TextToSqlEngineAPIGatewayURL から取得した実際の値に置き換えてください。このステップにより、関数がアプリケーションの適切な API エンドポイントに正しくリンクされます。 Authentication method で、 API Keys (Max. 2 Keys) を選択し、以下の詳細を入力します： Key sent in: Header Key name: x-api-key Key value: Amazon Secrets Manager の apiKey の値を入力します。 Create を選択し、関数の作成が完了するまで待ちます。 関数の作成が完了したら、 Functions ドロップダウンからアプリケーション用の関数を選択します。 構造化データへの接続が正常に機能していることを確認するために、以下のサンプルクエリをアプリケーションに送信してください。生成 AI システムは非決定論的であるため、応答は毎回同じにはならないことに注意してください。 プロンプト: List all the regions that we do business in. 期待されるレスポンス: Based on the query to get distinct region values from the sales_records table, the regions where we do business are: Europe Australia and Oceania North America Central America and the Caribbean Sub-Saharan Africa Middle East and North Africa Asia アプリケーションの共有 アプリケーションを構築した後、Amazon SageMaker Unified Studio を通じて組織内の他のユーザーと共有することができます。 アプリケーションインターフェイスの右上隅にある Share を探して選択します。 共有ダイアログで、エイリアスでユーザーを検索し、 Invite を選択して共有リストに追加します。 必要なユーザーをすべて追加したら、共有ダイアログからアプリケーションの URL をコピーし、任意の通信手段を使用して追加したユーザーに URL を送信します。 注意 : リンク共有をオンにすると、リンクを持っている人は誰でもアプリを購読して使用できるようになります。特定のユーザー名を追加した場合、それらのユーザーのみがアプリを閲覧でき、「共有された生成 AI アセット」セクションに表示されます。 共有アプリケーションを使用するには、有効な Amazon SageMaker Unified Studio のアクセス認証情報が必要です。アクセスに問題が発生した場合は、AWS 管理者に連絡してください。 使用例 以下の例では、グローバルな小売サイトがこのソリューションを使用して、販売分析プロセスを変革し、価値のあるインサイトを抽出する方法を示します。このアプローチの効果を示す 3 種類のクエリを見ていきましょう： 売上実績を理解するための構造化データの分析 インサイトを抽出するための非構造化カスタマーフィードバックの分析 包括的なビジネスインテリジェンスのための両データソースの組み合わせ 以下の例では、セールスアナリストが基本的な会話形式のクエリを通じて、価値のあるインサイトを抽出する方法を紹介します。 生成 AI システムは非決定論的であるため、応答は毎回同じにはならないことに注意してください。生成 AI システムは誤った情報を生成する可能性もあるため、応答の正確性を評価する際は注意が必要です。また、構造化データソースはダウンロード時にランダムに生成されるため、結果が必ずしも一致するとは限りません。Amazon S3 の CSV データソースにアクセスして、結果を手動で評価することができます。この例では Anthropic Claude 3 Sonnet モデルを使用しましたが、他のモデルも試してみることをお勧めします。 構造化データの例 クエリ可能な特徴量カラムは以下の通りです: Region (地域)、Country (国)、Item Type (商品タイプ)、Sales Channel (販売チャネル)、Order Priority (注文優先度)、Order Date (注文日)、Order ID (注文 ID)、Ship Date (出荷日)、Units Sold (販売数)、Unit Price (単価)、Unit Cost (単位コスト)、Total Revenue (総収益)、Total Cost (総コスト)、Total Profit (総利益)。このデータは 7 つの地域と 100 以上の国をカバーしており、以下の商品タイプが含まれています: ベビーフード、飲料、シリアル、衣類、化粧品、果物、家庭用品、肉類、オフィス用品、パーソナルケア用品、スナック、野菜。 プロンプト 1: What region accounts for our highest revenue, and how much revenue is that? 予想される応答 1: The region that accounts for our highest revenue is "Sub-Saharan Africa" with a total revenue of $356,724,250.12. プロンプト 2: Which 3 item types account for our most units sold? 予想される応答 2: The 3 item types that account for our most units sold are: Beverages with 504,905 units Personal Care with 475,724 units Vegetables with 471,276 units 非構造化データの例 以下の例では、非構造化データを照会するために使用できる自然言語プロンプトをいくつか紹介します。これらのクエリの目的は、テキストデータを照会して質問に回答し、共通のテーマを特定することです。 クエリ可能なデータには、ユーザーからの製品固有のレビュー、アンケートを通じて収集したオンラインとオフラインのフィードバック、最近の業界や経済ニュースが含まれます。 プロンプト 1: Search our customer surveys to see if customers seem to prefer our online or offline shopping experience 予想される応答 1: Based on the customer survey results from the knowledge base, there seems to be a preference for the in-store/offline shopping experience over the online experience (website and mobile app). The in-store reviews frequently mention positive aspects like helpful staff, clean stores, good product selection and organization. In contrast, the online reviews cite many issues with the website and mobile app like slow loading times, crashes, poor search functionality, and difficulties during checkout. While there are some positive online reviews as well, the negative experiences seem more prevalent for the online channels compared to the offline in-store experience. プロンプト 2: Were there any major world events in 2016 affecting the sale of Vegetables? 予想される応答 2: Based on the search results from the knowledge base, there were a few major events in 2016 that may have impacted vegetable sales: In July 2016, an extended drought in California's Central Valley resulted in reduced vegetable production, affecting supply chains for major retailers across North America. In April 2016, Morocco's innovative desert greenhouse project began operations, introducing new competition in the Mediterranean vegetable market and affecting prices in Southern Europe. In June 2016, India's successful implementation of cold chain infrastructure reduced vegetable spoilage by 35%, stabilizing prices across South Asian markets. So the drought in California likely reduced vegetable supply and increased prices in North America, while the new greenhouse operations in Morocco introduced more competition in Europe. However, improved cold chain logistics in India helped stabilize vegetable prices in that region. データ結合の例 以下は、構造化データと非構造化データの両方のソースに対してクエリを実行し、その結果をシームレスにビジネスインサイトとして組み合わせることができる、自然言語プロンプトの例です。 プロンプト 1: Do customers seem to prefer our online or offline shopping experience? Gather data from both customer surveys and number of units sold on different sales channels (online and offline), and try to identify a trend to see if the data corroborates these reviews. 予想される応答 1: Based on the customer reviews from the knowledge base, there seems to be a preference for the in-store/offline shopping experience over online shopping. Common complaints for online included slow websites, technical glitches, poor search functionality, and issues during checkout. In contrast, the in-store experience received more positive reviews praising helpful staff, clean stores, and good product selection. The overall sales data shows that the Offline sales channel had higher total revenue ($698.9M) and units sold (2.69M) compared to Online ($628.4M revenue, 2.36M units). This data corroborates the customer review sentiments, indicating customers may prefer the offline/in-store experience for our products and services. However, it is important to note that both channels received a mix of positive and negative reviews. To improve the overall customer experience, we should analyze the specific issues raised in the reviews and look for ways to enhance both the online and offline channels based on that feedback. プロンプト 2: Can you identify any major events that may have affected the sales revenue of Baby Food? What about any product reviews that may reflect the trends in revenue? Use order dates and news article publishing dates as you look for trends. 予想される応答 2: Based on analyzing the sales revenue data for the Baby Food item type and searching relevant unstructured data sources, here are some major events that appear to have impacted sales revenue: In November 2015, Japan introduced stricter quality control standards for imported baby foods (source 5). This appears to have disrupted supply chains in Asia and may have driven the spike in revenue that month as companies rushed to get products into Japan before the new standards took effect. In August 2016, Mexico reported a breakthrough in avocado cultivation that increased yields by 25% (source 3). This improved supply of a key baby food ingredient and may have contributed to the high revenue in late 2016 by lowering costs for manufacturers. In April 2014, Australia had a wheat shortage due to drought conditions, impacting costs for grain-based baby food products (source 2). This aligns with the low revenue on 4/26/2014 as manufacturers likely passed along higher costs to consumers. The unstructured data sources provided helpful context around supply chain disruptions, ingredient shortages and surpluses, major agricultural events, and changes in trade policies - all of which appear to have impacted baby food sales based on the timing of these events correlating with fluctuations in revenue in the structured data. クリーンアップ これらの手順でデプロイしたリソースをクリーンアップするには、まず CloudFormation スタックを 削除 します。その後、Amazon SageMaker Unified Studio プロジェクトから Amazon Bedrock のリソースを削除し、Amazon SageMaker Unified Studio の ドキュメント に従ってドメインを削除できます。 まとめ この記事では、Amazon Bedrock in SageMaker Unified Studio が、生成 AI アプリケーション開発を複雑な技術的な作業から、シンプルなポイント＆クリックの操作に変えることをご紹介しました。従来のアプローチでは、専門的な ML の知識と多大な開発時間が必要でしたが、Amazon Bedrock in SageMaker Unified Studio を使用することで、さまざまなスキルレベルのユーザーが、数週間ではなく数時間で本番環境対応の AI アプリケーションを作成できるようになります。 主なメリットとして、コーディングの専門知識がなくても、誰でも高度な生成 AI アプリケーションを構築できます。事前に構築されたコンポーネントにより、価値の実現までの時間を短縮でき、一元管理によってエンタープライズガバナンスを維持できます。さらに、統一された使いやすいインターフェースを通じて、組織のデータに安全にアクセスできます。この同じアプローチは、営業分析以外にも、チームが企業データと大規模言語モデルを組み合わせた AI アプリケーションを迅速に構築する必要があるシナリオにも適用できます。これにより、組織全体で生成 AI を真に利用可能にします。 組織の AI 機能を変革する準備はできましたか？ステップバイステップのガイドに従って最初の生成 AI アプリケーションの構築を始めるか、 Amazon Bedrock in SageMaker Unified Studio にアクセスしてビジネスニーズに合ったソリューションをさらに探索してください。 著者について Ameer Hakme は、ペンシルベニア州を拠点とする AWS ソリューションアーキテクトです。北東地域のインディペンデント・ソフトウェア・ベンダー (ISV) と協力し、AWS クラウド上でスケーラブルでモダンなプラットフォームの設計と構築を支援しています。AI/ML および生成 AI のエキスパートとして、お客様がこれらの最先端テクノロジーの可能性を引き出せるよう支援しています。余暇にはバイクに乗ったり、家族と質の高い時間を過ごすことを楽しんでいます。 Adam Gamba は、AWS のソリューションアーキテクトであり、アナリティクスおよび AI/ML スペシャリストを目指しています。コンピュータサイエンスのバックグラウンドを持ち、テクノロジーを活用して実世界の問題に対するソリューションを構築することに強い関心を持っています。ニュージャージー州出身で、現在はバージニア州アーリントンを拠点としており、ロッククライミング、ピアノ演奏、料理、地元の美術館やコンサートに行くことを楽しんでいます。 Bhaskar Ravat は、ニューヨークを拠点とする AWS のシニアソリューションアーキテクトで、AI の変革的な可能性に深い関心を持っています。AI が日常生活や人間の経験全般にどのような影響を与えるかを探求することに情熱を注いでいます。お客様のソリューション構築やサポートを行っていない時は、4 冊の本を同時に読んでいます。 Kosti Vasilakakis は AWS のプリンシパルプロダクトマネージャーです。元データサイエンティストからプロダクトマネージャーに転身し、現在は Amazon Bedrock in SageMaker Unified Studio のリーダーとして、企業が高品質な生成 AI アプリケーションをより迅速に構築できるよう支援しています。AI の急速な進歩に感銘を受け続けており、その民主化に携われることを楽しみにしています。仕事以外では、個人の生産性向上のための自動化コードを書いたり、テニスをプレイしたり、家族と自然の中で過ごしたりしています。

本ブログは 2025 年 2 月 14 日に公開された Blog “ Introducing the AWS Trust Center ” を翻訳したものです。 Amazon Web Services (AWS) において、信頼を獲得することは単なる目標ではなく、私たちのあらゆる意思決定を導く中核的なリーダーシップ原則の一つです。AWS の CISO として、この信頼獲得への取り組みが私たちの文化、サービス、そして日々のお客様とのやり取りをどのように形作っているかを直接目の当たりにしてきました。お客様が他のプロバイダーではなく AWS を選ぶ理由は、最も安全なインフラストラクチャとサービスを提供し、データ保護の方法を正確に伝えることを信頼しているからです。 その情報をさらに見つけやすくするため、AWS はクラウドでの資産保護へのアプローチを共有する新しいオンラインリソース「 AWS Trust Center 」を立ち上げました。AWS Trust Center は、私たちのセキュリティ対策、コンプライアンスプログラム、データ保護管理を紹介し、私たち AWS が日々お客様の信頼を獲得するためにどのように取り組んでいるかを示す透明性を持った情報源です。 信頼の基盤の上に構築 セキュリティは Day 1 (創業当初) から AWS の最優先事項です。2006 年に AWS を立ち上げた時、利用可能な最も安全なクラウドコンピューティング環境としてインフラストラクチャを設計しました。既存のオンプレミスインフラストラクチャと同レベルのセキュリティを提供するだけでは不十分だと認識していました。お客様の信頼を獲得するためには、世界で最もセキュリティを重視する組織の厳格な業界基準を上回る必要がありました。AWS は日々の意思決定においてセキュリティを常に強化し続けています。Trust Center により、AWS がお客様のワークロードを保護し、データを守り、コンプライアンス目標の達成をどのように支援しているかを理解しやすくなります。 Trust Center は、情報への容易なアクセスが信頼を構築・維持するという考えに基づいています。データセンターの管理に関する情報を探す場合でも、コンプライアンス認証を確認する場合でも、共有責任モデルを確認する場合でも、必要なセキュリティとコンプライアンスの情報を一箇所で見つけることができるようになりました。 セキュリティとコンプライアンスの単一情報源 Trust Center では、物理的なデータセンターからクラウドインフラストラクチャ、そしてクラウドサービスのポートフォリオに至るまで、あらゆるレベルでのセキュリティアプローチに関する情報を見つけることができます。セキュリティサービスとツールに関するドキュメントを含め、AWS がクラウドをどのように保護し、お客様がその中でワークロードをどのように保護できるかを理解するのに役立ちます。また、グローバルに維持している認証や証明を含むコンプライアンスプログラムに関する情報も見つけることができます。これは、監査人や規制当局にコンプライアンスを証明する必要がある規制産業で働くチームにとって価値があります。 Trust Center はデータ保護とプライバシー対策に関する情報を強調しています。お客様はデータの保護方法や暗号化の管理方法について学ぶことができます。さらに、お客様がデータにアクセスできる人とその状況について懸念していることを理解しています。最小権限の原則を核とする オペレーターアクセス制御 に関する詳細情報を統合しました。 AWS Key Management Service (AWS KMS) や Amazon Elastic Compute Cloud (Amazon EC2) などの主要サービスのゼロアクセス設計、お客様の承認を暗号的に強制する転送アクセスセッション (FAS) の使用、そしてグローバル監視システムについて学ぶことができます。 Trust Center は、サービスの健全性とセキュリティイベントに関する情報を見つけるための中心的な場所を提供し、運用の優秀性を維持するために必要な情報を得ることができます。セキュリティ速報を常に最新の状態に保ち、リアルタイムのサービス健全性状態を確認できます。セキュリティ上の懸念を報告したり、独自のセキュリティ評価を実施したりする必要がある場合、それらのプロセスを見つけやすくしました。リソースはアクセスしやすいように整理され、クラウドセキュリティポスチャについて情報に基づいた決定を下すために必要な契約、ドキュメント、リソースへの直接リンクが提供されています。 お客様のセキュアなイノベーション推進を支援 私が Trust Center で最も素晴らしい点は、お客様の障壁を取り除く方法です。詳細なセキュリティ情報、コンプライアンス文書へのより簡単なリンク、そして運用上の洞察が今や指先一つで得られるため、より迅速に行動し、自信を持ってイノベーションを起こすことができます。 AWS サービスの革新と拡大を続ける中で、最新のセキュリティ情報で Trust Center を強化することに取り組んでいます。これはクラウドとサービスとともに進化し、常に更新されるリソースです。お客様の信頼を維持することは、今日構築したものだけでなく、私たちのコミットメントと実績を通じて、信頼できるセキュリティパートナーとしての価値を証明することです。それが AWS のお客様へのコミットメントであり、AWS Trust Center が表すものです。 ぜひ本日から AWS Trust Center をご覧ください。AWS は日々お客様の信頼を獲得し続けるよう努めてまいります。 このポストに関する質問がある場合は、 AWS サポート にお問い合わせください。 Chris Betz Chris は AWS の CISO です。セキュリティチームを監督し、リスク管理とビジネス目標に沿ったセキュリティ態勢の整合を目的としたセキュリティポリシーの開発と実装を主導しています。Chris は 2023 年 8 月に Amazon に入社し、それ以前は主要企業で CISO およびセキュリティリーダーシップの役割を担っていました。バージニア州北部で家族と暮らしています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

みなさん、こんにちは。ソリューションアーキテクトの杉山です。今週も 週刊AWS をお届けします。 2025 年 6 月 5 日 14:30 – 19:00 に、目黒のオフィスでイベント AWS Marketplace Solution EXPO Spring 2025 を開催します。SaaS・ソフトウェア ソリューション ベンダー 兼 AWS Marketplace パートナー 11 社が集まるイベントとなっており、様々な最新のソリューションを情報収集したい方などにおすすめです。Okta Japan株式会社、クラウドストライク合同会社、Snowflake合同会社、Splunk Services Japan 合同会社、ゼットスケーラー株式会社、株式会社セールスフォース・ジャパン、Datadog Japan 合同会社、データブリックス・ジャパン株式会社、トレンドマイクロ株式会社、New Relic株式会社、パロアルトネットワークス株式会社 の 11 社 (50 音順) にご登壇いただくイベントです。是非ご登録の上ご参加ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2025 年 5 月 19 日週の主要なアップデート 5/19(月) Amazon Inspector が ECR コンテナイメージの使用状況追跡機能を強化 Amazon ECR で管理しているコンテナイメージが Amazon ECS や Amazon EKS のどの環境で実行されているか追跡できるセキュリティ機能を、Amazon Inspector で提供を開始しました。アクティブに使用されているコンテナイメージ、イメージを最後に使用した時期、どのクラスターがイメージを実行しているかを特定できます。これにより、実行中のワークロードに関連する最も重要な脆弱なイメージを特定しやすくなり、セキュリティの対応と修復までの時間を短縮できます。 AWS CloudWatch Synthetics がカナリアの安全なアップデートと自動再試行を追加 お客様のウェブサイトをモニタリングできる CloudWatch Synthetics が、2 つの新機能「カナリアの安全なアップデート」と「カナリアの自動再試行」を提供開始しました。「カナリアの安全なアップデート」は、更新を適用する前にテストを実施できます。新しくリリースされたランタイムとカナリアの互換性、また、構成やコードの変更との互換性を確認でき、影響を抑えたカナリアの更新が可能です。「カナリアの自動再試行」は、誤警報を減らすのに役立ちます。持続的な問題と一時的な障害を区別することで、より信頼性の高いモニタリング結果を提供し、不必要な中断を防ぎます。 DynamoDB local が AWS CloudShell で利用可能 AWS CloudShell で DynamoDB local を利用できるようになりました。DynamoDB local を使用すると、ローカル開発環境で DynamoDB を利用した開発やテストを実行でき、料金発生を抑えられるメリットがあります。DynamoDB local は既存の DynamoDB API 呼び出しを利用でき、既存のソースコードの影響を最小限に抑えられます。CloudShell で dynamodb-local エイリアスコマンドを実行すると DynamoDB local を起動できます。プログラムコードで DynamoDB Local に接続するために、「Endpoint_url=’http://localhost:8000’」といった形でエンドポイントを指定します。 5/20(火) Amazon RDS for Oracle で Oracle マルチテナントアーキテクチャを使用するデータベース向けに AWS Secrets Manager による認証情報管理をサポート Amazon RDS for Oracle で、複数のプラガブルデータベース (PDB) を稼働する Oracle マルチテナントアーキテクチャを使用する際に、 AWS Secrets Manager による認証情報管理ができるようになりました。定期的なパスワードローテーションを自動化し、IAM を使用して権限のあるユーザーへのアクセス制御を行い、アプリケーションコード内の平文パスワードの使用を AWS Secrets Manager から認証情報を取得するプログラム呼び出しに置き換えることによるセキュリティ向上、といったメリットがあります。 Amazon CloudWatch Application Signals が EKS ワークロードの自動監視サポートを導入 CloudWatch Application Signals で、EKS ワークロードの自動監視機能をサポートしました。Amazon CloudWatch EKS アドオンをインストールして設定することで、CloudWatch 上の APM を EKS にセットアップできるようになりました。CloudWatch Application Signals 内の事前構築された標準ダッシュボードで EKS アプリケーションのパフォーマンスに関する指標を確認できるようになります。 Amazon EC2 High Memory インスタンスが米国東部 (オハイオ) リージョンで利用可能 18 TB のメモリを搭載した Amazon EC2 High Memory U-1 インスタンス (u-18tb1.112xlarge) が米国東部 (オハイオ) リージョンで利用可能になりました。Amazon EC2 High Memory インスタンスは、本番環境での Business Suite on HANA、SAP S/4HANA、Data Mart Solutions on HANA、Business Warehouse on HANA、および SAP BW/4HANA の実行について SAP による認定を受けています。詳細は こちらのブログ をご確認ください。 5/21(水) AWS Transfer Family が SFTP 向けの ML-KEM 量子耐性鍵交換を提供開始 AWS Transfer Family で SFTP を利用する際に、米国国立標準技術研究所 (NIST) によって標準化された量子後暗号アルゴリズムである ML-KEM (FIPS-203) をサポートしました。「今収集し、後で復号する」脅威に対して長期的な機密性を必要とするデータファイルの転送を保護します。この発表により、古典的な楕円曲線ディフィー・ヘルマンと量子耐性 ML-KEM 鍵交換を組み合わせた量子後 (PQ) ハイブリッドセキュリティポリシーを、AWS Transfer Family SFTP エンドポイントと OpenSSH、Putty、JSch などの PQ アルゴリズムをサポートするクライアント間で使用できるようになりました。 Amazon EKS ダッシュボードの複数リージョン、Organizations 全体のサポート EKS のダッシュボードが、複数の AWS リージョンとアカウントにわたる Kubernetes インフラストラクチャの一元的な可視性を提供する新機能の一般提供を開始しました。AWS リージョンやアカウントを切り替えることなく、Kubernetes インフラストラクチャ全体を可視化できるようになり、クラスター、マネージドノードグループ、EKS アドオンに関する集約された洞察を得ることができます。これには、特定の Kubernetes バージョンを実行しているクラスター、サポートステータス、今後のサポート終了自動アップグレード、マネージドノードグループの AMI バージョン、EKS アドオンバージョンなどが含まれます。 AWS Cost Anomaly Detection が AWS User Notifications を通じて高度なアラート機能を実現 AWS Cost Anomaly Detection が AWS User Notifications (Amazon EventBridge 経由) と統合して、高度なアラート機能を作成できるようになりました。お客様はサービス、アカウント、またはその他のコスト要素に基づいた高度なアラートルールを設定し、予期しない支出の変化をより迅速に特定して対応することができます。メール、AWS Chatbot、AWS Console Mobile Application などから通知先を設定できます。 5/22(木) Anthropic の Claude 4 基盤モデルが Amazon Bedrock で利用可能 Anthropic の Claude モデルの次世代版である Claude Opus 4 と Claude Sonnet 4 が Amazon Bedrock で利用可能になりました。これらのモデルはコーディングに優れ、AI エージェントが何千もの情報源を分析し、長時間実行タスクを実行し、高品質のコンテンツを作成し、複雑なアクションを実行することを可能にします。この 2 つのモデルは、ほぼ即時の応答を行うモードと、より深い推論のための extended thinking モードを利用できます。料金については、これまで提供しているモデルと同様です。Claude 3.7 Sonnet と Claude Sonnet 4 が同一、同様に Claude 3 Opus と Claude Opus 4 が同一となっています。また、新しい Claude 4 モデルの名前は、数字が末尾につくように変更されています。間違えがちなので留意しましょう。詳細は こちらのブログをご参照 ください。 Amazon Managed Service for Prometheus がクエリインサイトとコントロール機能を開始 Amazon Managed Service for Prometheus は、高コストな PromQL クエリを特定し、その実行を制限する機能を提供するようになりました。Amazon Managed Service for Prometheus ワークスペースに対して発行されるクエリの種類を監視および制御できるようになります。Amazon Managed Service for Prometheus は、クエリを実行したときに処理されるサンプル (データ) の数によって料金が上下する従量課金が含まれています。多くのデータを取得するクエリを特定することで、改善のアクションをしやすくなりました。 AWS が EC2 パブリック DNS 名の IPv6 サポートを発表 EC2 パブリック DNS 名で、 IPv6 グローバルユニキャストアドレス (AAAA レコード) を解決できるようになりました。これまでは、EC2 パブリック DNS 名は IPv4 アドレス (A レコード) に解決されていました。そのため、IPv6 を採用するお客様は、IPv6 のみの Amazon EC2 インスタンスにアクセスするために DNS 名の代わりに特定の IPv6 アドレスを使用するか、Amazon Route 53 を使用してホストゾーンを作成してカスタムドメインを使用していました。EC2 パブリック DNS 名の IPv6 サポートにより、お客様は IPv6 のみの Amazon EC2 インスタンスに簡単にアクセスできるようになりました。 Amazon Aurora が クロスリージョン グローバルデータベース スイッチオーバー時間を通常 30 秒未満に短縮 Amazon Aurora は、より高速な グローバルデータベース クロスリージョン スイッチオーバーを提供しました。通常 30 秒未満でスイッチオーバーが可能です。グローバルデータベースでは、単一の Aurora クラスターが複数の AWS リージョンにまたがることができ、リージョン全体の障害からの災害復旧を提供します。スイッチオーバーは事前に計画された切り替えに利用する機能となっており、事前の切り替えテストなどのシナリオで利用する機能です。 5/23(金) CloudWatch Database Insights が Aurora Limitless PostgreSQL のサポートを追加 CloudWatch Database Insights が Amazon Aurora PostgreSQL Limitless データベースをサポートしました。Database Insights は、事前構築されたダッシュボード、推奨アラーム、および自動テレメトリ収集を使用して、データベースフリートの健全性を監視し、根本原因分析を行うことができます。Aurora Limitless データベースで Database Insights を有効にして、Limitless シャードグループ全体でのデータベース負荷の分散状況の監視を開始できるようになりました。 Amazon ECS がコンテナ終了理由メッセージを 1024 文字に増加 Amazon ECS はコンテナ終了理由メッセージの長さを 255 文字から 1024 文字に拡張しました。この強化により、コンテナが失敗した際により多くのなエラーメッセージを提供することで、より効果的なデバッグが可能になります。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 気づけば 5 月も終盤ですが、もう少し生成 AI のイベントが続きます！ 5 月 27 日（火）：ナウいフロントエンド開発 ~ 生成 AI と協調するには ~ 5 月 28 日（水）：Coding Agent at Loft #1 ~ Cline with Amazon Bedrock で 爆速開発体験ハンズオン ~ 大阪開催 6 月 25 日 (水)、26 日 (木) に開催される AWS Summit Japan 2025 もあと 1 ヶ月を切りました。登録は こちら から！ 4 月に発表した「 AWS ジャパン生成 AI 実用化推進プログラム 」も非常に多くの申し込みをいただいています。引き続き募集中ですのでよろしくお願いします。 先週は、Claude ユーザー待望の Claude 4 Sonnet/Opus が Amazon Bedrock で使えるようになるといった注目が高いアップデートがありました。 それでは、5 月 19 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「AI イノベーションを加速する NVIDIA Blackwell GPU を搭載した新しい Amazon EC2 P6-B200 インスタンス」を公開 5 月 15 日に NVIDIA B200 を搭載した Amazon EC2 P6-B200 インスタンスの一般提供を開始しました。Amazon EC2 P6-B200 は特に、強化学習 (RL) と蒸留を用いた基盤モデルの大規模な分散 AI トレーニングおよび推論、マルチモーダルのトレーニングと推論、HPC アプリケーションに適しています。本記事ではインスタンスの特徴や仕様を紹介しています。 ブログ記事「Amazon Bedrock で 基盤モデルを使用する際のコスト最適化」を公開 生成 AI の推論コストの管理と最適化は、従来のクラウドコスト管理と同じくらい重要です。本記事では、Amazon Bedrock でコスト最適化を行う様々な方法を紹介しています。料金オプション、モデル選択、ナレッジベースの最適化、プロンプトキャッシュや自動推論について触れています。 ブログ記事「Strands Agents – オープンソース AI エージェント SDK の紹介」を公開 5 月 16 日に Strands Agents というAI エージェント構築のためのオープンソース SDK をリリースしました。Strands Agents は、わずか数行のコードで AI エージェントの構築や実行を行うことができます。本記事では、Strands Agents の仕組みやサンプルコード、デプロイ方法を紹介しています。まずはサンプルコードを是非実行してみてください！ ブログ記事「AWS Transform for VMware の新機能」を公開 5 月 15 日に AWS Transform for VMware が一般提供開始されました。これは、大規模な VMware モダナイゼーションを簡素化するエージェント型 AI サービスです。本記事では、実際の操作方法を画像付きでステップバイステップで紹介しています。実際にテストを行ったパートナー様の声も掲載していますので是非ご覧ください。 ブログ記事「AWS Transform for .NET: .NET アプリケーションを大規模にモダナイズするための初のエージェント型 AI サービス」を公開 .NET アプリケーションをモダナイズする機能は、これまで Amazon Q Developer 変換機能 でプレビューで提供されていましたが、今回 AWS Transform for .NET というサービスとして一般提供が開始されました。これまでの移植機能に加えて、プライベート NuGet パッケージを使用するプロジェクトをサポートする機能などいくつかの新機能が追加されています。本記事では操作画面のスクリーンショット付きで移植方法と新機能を紹介しています。 ブログ記事「AWS Transform によるメインフレームと VMware ワークロードモダナイゼーションの加速」を公開 AWS Transform for Mainframe は、メインフレームワークロードを大規模にモダナイズするための初のエージェント型 AI サービスです。IBM z/OS アプリケーションのモダナイゼーションを数年から数ヶ月に短縮します。本記事にて、各機能や設定方法を紹介しています。 ブログ記事「開発生産性向上とガバナンスの両立を目指した、Cline with Amazon Bedrock と LiteLLM 活用のコツ」を公開 5 月 13 日に「Coding Agent Workshop ~ 開発生産性向上とガバナンスの両立を目指した、Cline with Amazon Bedrock活用のコツ ~」というイベントを開催しました。本ブログはイベントで提供した内容をまとめたものです。AIコーディング支援エージェントの導入時に考慮すべきガバナンスについて、AWSサービスとオープンソースツールを組み合わせたアプローチ例を紹介しています。 ブログ記事「ライフサイエンスのイノベーションをAWSのAIエージェントで加速」を公開 ヘルスケア・ライフサイエンス業界全体でエージェント開発の民主化を促進するため、AWS はヘルスケア・ライフサイエンス分野向けの オープンソースAIエージェントツールキット を開発しました。本記事では、ツールキットのはじめ方やアーキテクチャの解説をしています。ツールキットには創薬研究エージェントや臨床開発エージェント等が含まれています。 ブログ記事「IoT@Loft #26 関西発 IoT × 生成 AI が描く新たな未来 【開催報告＆資料公開】」を公開 5 月 15 日に 第 26 回 IoT@Loft 「関西発 IoT× 生成 AI が描く新たな未来」を開催しました。本ブログでは、イベントの内容を紹介し、各登壇者の発表資料を公開しています。生成 AI と IoT の融合による新たな可能性について、お客様 3 社と AWS がセッションした様子が紹介されています。 サービスアップデート Amazon Bedrock Data Automation がビデオからのカスタムインサイト生成に対応 Amazon Bedrock Data Automation（BDA）がビデオのカスタムブループリントに対応し、標準出力では取得されない情報を抽出・生成することができるようになりました。自然言語の指示によって、生成する内容や出力データタイプを指定することが可能です。例えば、広告配置のためにテレビ番組を分析するユーザーは、カスタムブループリントを使用してシーンを要約したり、映っているオブジェクトを検出し製品ロゴを識別したりすることが可能です。 Amazon Bedrock Agents の CloudWatch メトリクスを発表 Amazon Bedrock Agents に対する包括的な CloudWatch メトリクスサポートを提供しました。これにより、開発者はエージェントベースのアプリケーションをより高い可視性で監視、トラブルシューティング、最適化できるようになりました。メトリクスには呼び出し回数、レイテンシー測定、トークン使用量、エラー率などが含まれお客様が本番環境でのエージェントのパフォーマンスをより良く理解するのに役立ちます。Amazon BedrockがサポートされているすべてのAWSリージョンで現在利用可能です。 Anthropic Claude 4 基盤モデルが Amazon Bedrock で利用可能に Anthropic Claude モデルの次世代版、Claude Opus 4 と Claude Sonnet 4 が Amazon Bedrockで利用可能になりました。これらのモデルは特にコーディングに優れており、複雑で長時間にわたるタスクやエージェントワークフローにおいて高いパフォーマンスを発揮します。Opus 4 と Sonnet 4 はどちらもハイブリッド推論モデルで、深い推論のための拡張思考モードをサポートしています。Claude Opus 4 は、米国東部（オハイオ、バージニア北部）および米国西部（オレゴン）リージョンで利用可能です。Claude Sonnet 4 は米国東部（オハイオ、バージニア北部）、米国西部（オレゴン）、アジアパシフィック（ハイデラバード、ムンバイ、大阪、ソウル、シンガポール、シドニー、東京）、および欧州（スペイン）リージョンにて呼び出し可能です。どちらもクロスリージョン推論を通じてアクセスできます。詳しい特徴は ブログ や ガイド を参照ください。 Amazon Bedrock モデルが AWS GovCloud (US) で FedRAMP High および DoD IL-4/5 承認を取得 Anthropic Claude 3.5 Sonnet v1 と Claude 3 Haiku、および Meta Llama 3 8B と 70B モデルが、AWS GovCloud (US) リージョンの Amazon Bedrock において、FedRAMP High および国防総省クラウドコンピューティングセキュリティ要件ガイド (DoD CC SRG) インパクトレベル (IL) 4 および 5 の承認を取得しました。さらに、Amazon Bedrock の各機能（エージェント、ガードレール、ナレッジベース、モデル評価）も承認されました。連邦政府機関、公共部門の組織、およびFedRAMP High コンプライアンス要件を持つ企業は、Amazon Bedrock を使用して Anthropic と Meta の高性能な基盤モデル (FM) にアクセスできるようになりました。 次世代版 Amazon SageMakerが新たなリージョンで利用可能に 次世代版 Amazon SageMaker が欧州（ストックホルム）リージョンで利用可能になりました。サポートされているリージョンの一覧は こちら からご覧いただけます。 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は生成 AI と毎日戯れており、特にコード生成と LLM エージェントに注目しています。好きなうどんは’かけ’です。

こんにちは。元自動車メーカー生産技術出身で AWS ソリューションアーキテクトへ転身し、普段は製造業のお客様の技術支援をしている、岩根です。本記事では、きたる 2025 年 6 月 25 日 (水) と 26 日 (木) の 2 日間、幕張メッセで開催される AWS Summit Japan 2025 のブース予告をお届けします。製造業に関する展示は Hall 7 の AWS Expo 内にある AWS Industries Pavilion にあります。その中でも「スマート製造」に焦点を当て、詳しい内容をご紹介します。 ブース概要 スマート製造の取り組みとして、製造データの収集と可視化に取り組まれるお客様が「どこから手を付けてよいのか」「ハードルが高いのでは？」と言う声をいただくことが多いです。今回スマート製造ブースでは、 三菱電機株式会社様ご協力 のもと、FA 機器を用いて、e-Bike (電動自転車)のフレームの塗装工程を再現しています。そして、そこから得られるデータを可視化したうえで、データ活用の事例として、生成 AI エージェントを用いたトラブルシューティングのデモをご覧いただけます。 図1：製作中のデモブース よくある課題 今回のデモで想定する課題は以下のようなものです。 製造オペレーションの最適化 設備トラブルの早期解消 設備の予知保全 品質問題の未然防止 これらを始めるためにデータを活用したいが、どこから手を付けてよいのかわからない このブースの注目ポイント 産業用ロボットを用いた e-Bike の模擬塗装ブースを展示し、実機から得られるデータをニアリアルタイムで可視化します 設備トラブルや品質トラブル発生時に、トラブルシュートまでの手順や、事後の予備品発注などの事務作業をアシストするAIエージェントをデモします トラブル発生時には、設備のどの箇所で起きたトラブルかを視覚的に理解できるように、デジタルツインで故障箇所をアノテーションします 三菱電機様とのパートナーシップにより、三菱電機製ロボットや制御機器を活用した実用的な展示を行います このブースでは、上記のように実機を用いて、そこで発生するデータの収集と可視化ダッシュボード、設備や品質トラブルの際のトラブルシューティングをアシストする AI エージェントを展示します。これら動くデモにより、自社のデータ活用のイメージを持っていただくことができます。 AWSサービス AWS IoT Greengrass ：制御機器の OPCUA Server からデータを収集し、クラウドに送信するために利用しています AWS IoT SiteWise ：収集した製造データを構造化し、時系列に保存するために利用しています AWS IoT TwinMaker ：デジタルツインで故障箇所をアノテーションするために使っています Amazon Managed Grafana ：ニアリアルタイムのダッシュボードを実現しています Amazon Bedrock ：AIエージェントの機能実現のために使っています デモでご紹介予定のシナリオ 工程における平時のオペレーションに必要な情報は、ニアリアルタイムのダッシュボードとして Grafana を用いて可視化しています。異常時のオペレーションで紹介する予定のシナリオはいくつかありますが、ここでは設備にトラブルが起きたときを想定したシナリオをご紹介します。 設備トラブルをダッシュボードで発見する（図2） ダッシュボードから該当のトラブルを開くと、AI エージェントの画面になる（図3） 機器から得られた情報を元に、考えられるトラブルの想定原因と対処方法をAIエージェントが提案する。また、DigitalTwin 上に、原因箇所をアノテーション表示する 対処方法をオペレータが実施したら、実施完了を AI エージェントに連絡する 交換部品の在庫数を AI エージェントが確認し、発注有無をオペレータに確認する オペレータが発注を依頼すると、AI エージェントが ERP と連携して部品発注を行う 図2：ニアリアルタイムダッシュボード 図3：AIエージェントによるトラブルシューティング アーキテクチャ 以下がデモ予定のアーキテクチャとなります。Edge Gateway として AWS IoT Greengrass をデプロイした Windows/Linux PC を置き、PLC の OPCUA Server ユニットから情報を収集しています。エッジ⇔クラウド間はデバイス証明書を用い、通信も暗号化するなどセキュリティ対策も実施しています。AI エージェントは Agent for Amazon Bedrock を使って実現しています。 図4：アーキテクチャ 著者紹介 岩根 義忠 (Yoshitada Iwane) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 自動車メーカーの生産技術開発部門を経て AWS Japan に入社し、エンタープライズ事業本部でソリューションアーキテクトとして活動中。前職でソフトウェア開発のアジャイル/スクラムに出逢い、自部門での導入やスケールを主導したことにより、モダンな開発手法やクラウドに目覚める。 趣味はバイクの他にギター演奏、自分の部屋の飾り付けなど。二児の父だが二人とも実家を出ているため、現在は妻と気楽な二人暮らし。栃木県那須塩原市在住。 &nbsp;

2025 年 5 月 15 日に開催したウェビナーでは、2025 年 4 月にラスベガスで開催された NAB Show 2025 における AWS 展示の振り返りを行いました。AWS 展示では従来の放送を超えた新しいエンターテインメント体験の創出をテーマに、スポーツエンターテインメント、ファンエンゲージメント、没入型技術、ラジオ/ポッドキャストなどの多面的なソリューションを提案しました。F1 シミュレーターを使用したeスポーツ体験や、放送局向けのクラウドベースのソリューション、さらにコンテンツ制作からビジネス支援まで幅広い業務の革新を可能とする Amazon Nova や Amazon Bedrock などの最新 AI サービスを展示しました。 NAB Show 2025 では、次の 6 つのソリューションエリアで、AWS が提供するメディア &amp; エンターテインメント向けソリューションの最新アップデートや機能強化と共にデモ展示を行いました。 [ライブクラウドプロダクションと放送] クラウドネイティブの制作ワークフロー、eスポーツレースの活性化、AI を活用したレース自動ハイライト [コンテンツ制作とポストプロダクション] 編集ソリューション、AI 支援型アセット作成、レンダリング自動化 [ラジオとポッドキャスト] クラウドベースのラジオ自動化、ポッドキャスト制作ソリューション、AI を活用したコンテンツ強化 [ファンエンゲージメント] 没入型視聴体験、インタラクティブなデータ可視化、デジタルヒューマンコミュニケーション [マルチチャネル収益化] パーソナライズ広告、バーチャルプロダクトプレイスメント、コンテキスト広告 [イノベーション事例] 生成 AI アプリケーション、ゲームとインタラクティブ体験、データサイエンスとアナリティクス、メディアオペレーション自動化 また、NAB Show 期間中にはAWS主催のセッションとして “ How to build entertainment breakthroughs using generative AI and the cloud ” と題し、AWS M&amp;E の General Manager の Samira Panah Bakutiar と、Prime Video、PBS、COSM の代表者が集まり生成 AI とクラウドを活用したトレンド、実践事例を紹介するセッションを行いました。本メディアセミナーではそのセッションの振り返りも行いました。 &nbsp; NAB Show 2025 – AWS 展示概要 – 新たな視聴体験を実現するコンテンツ制作（ライブクラウドプロダクションと放送、コンテンツ制作とポストプロダクション、ラジオとポッドキャスト） アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 井村 紀彦 [ 資料 、 動画 ] 視聴者体験を革新的に進化させるコンテンツ制作ソリューションをご紹介します。従来の一方向の放送から、よりイマーシブでインタラクティブな体験へと変化する視聴者ニーズに応える最新技術をデモ展示の内容に基づき解説します。West Hall ロビーで展開されるeスポーツレーシングチャレンジを通じて、クラウドベースのライブプロダクション、AI によるリアルタイム分析、視聴者参加型の体験の実現方法を紹介します。さらに、プロダクションコントロールルーム、ポストプロダクション環境、ラジオ/ポッドキャストスタジオなど、実践的なデモ環境を通じて、次世代の放送制作ワークフローの全体像をご説明します。 &nbsp; NAB Show 2025 – AWS 展示概要 – コンテンツの収益化を強化するファンエンゲージメントと生成 AI/データ活用（ファンエンゲージメント、マルチチャネル収益化、イノベーション事例、セッション振り返り） アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 金目 健二 [ 資料 、 動画 ] コンテンツの価値最大化を実現する AWS の最新テクノロジーを活用し、ファンエンゲージメントの強化とデータドリブンな収益化戦略について解説します。Amazon Nova と Amazon Bedrock によるマルチモーダルな生成 AI により、パーソナライズされたコンテンツ生成やインタラクティブな視聴者体験が実現します。イマーシブでパーソナライズされたデジタル体験の事例を通じて、ファンエンゲージメントと新たな収益機会の創出を可能にする、視聴者との深い関係性を構築し持続可能な収益化を実現する AWS のソリューションを紹介します。 &nbsp; おわりに 本ブログでは、2025 年 5 月 15 日に開催されたメディアセミナー 2025 Q2 ～ NAB Show 2025 の recap ～について紹介しました。今回セミナーに参加いただいた皆さま誠にありがとうございました。引き続き業界の皆様に役立つ情報を、セミナーやブログで発信していきます。どうぞよろしくお願い致します。 &nbsp; 参考リンク AWS for Media &amp; Entertainment AWS Media &amp; Entertainment Blog (日本語) AWS Media &amp; Entertainment Blog (英語) AWSのメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 このブログは SA 金目、井村が担当いたしました。

本稿は、2025 年 5 月 16 日に Migration &amp; Modernization Blog で公開された “ New Capabilities in AWS Transform for VMware ” を翻訳したものです。 はじめに AWS Transform for VMware の一般提供を発表できることを嬉しく思います。これは VMware ワークロードのモダナイゼーションを加速するために特別に構築された最初のエージェント型 AI エクスペリエンスです。アプリケーションの検出、依存関係のマッピング、移行計画、ネットワーク変換、Amazon Elastic Compute Cloud (EC2) インスタンスの最適化を自動化し、手作業の労力を削減してクラウド導入を加速します。これは VMware モダナイゼーションにおける最も複雑な課題のうちの 2 つに対応します：VMware ネットワーク設定を AWS ネイティブの構成要素に変換すること、そしてスムーズな切り替えのための依存関係を考慮した移行ウェーブのオーケストレーションです。この投稿では、現在利用可能な AWS Transform の機能について説明します。 前提条件 サービスへのフェデレーションのための AWS Identity and Access Management (IAM) Identity Center のセットアップ AWS Organizations のセットアップ VMware discovery アカウントとして機能する AWS アカウント。このアカウントにはすべての検出データが含まれます。このアカウントは AWS 組織の一部である必要があります。 VMware infrastructure provisioning アカウントとして機能する AWS アカウント。このアカウントは、変換されたリソースがデプロイされます。discovery アカウントと同じである必要はありませんが、本番移行には別のアカウントが推奨されます。このアカウントは AWS 組織の一部である必要があります。 開始方法 – AWS Transform の有効化 AWS コンソールで AWS Transform を検索します。次に Get Started を選択します。 図1. AWS Transform メインページ 暗号化キーを指定し、 Enable AWS Transform を選択します。デフォルトの暗号化またはカスタム暗号化を選択できます。 図2. AWS Transform 暗号化 Manage Users を選択します。 図3. Manage Users を選択 IAM Identity Center にあるユーザーまたはグループを AWS Transform に追加できます。 図4. AWS Transform にユーザーを追加する ユーザーは Web アプリケーション URL を使用して AWS Transform に直接アクセスできます。 図5. AWS Transform の URL エンドツーエンドの移行ワークフロー AWS Transform for VMware は、お客様が希望する変換アプローチを選択できる柔軟なエクスペリエンスを提供します。このサービスは、特定の移行シナリオに対応するように設計された 4 つの異なるワークフロータイプを提供します。このモジュラー設計により、お客様は VMware から AWS への移行の特定の側面（ネットワーク変換、サーバー移行、または包括的なエンドツーエンド移行）に集中できます。 以下のワークフローオプションから選択できます： End-to-End Migration – ディスカバリー、ウェーブプランニング、VPC 設定、ネットワークデプロイメント、サーバー移行を通じてお客様を案内する包括的なワークフロー Network Migration Only – ネットワーク変換に焦点を当て、VPC 設定とデプロイを処理 Network and Server Migration – ネットワーク設定とデプロイをサーバー移行機能と組み合わせたもの Discovery and Server Migration – お客様によるディスカバリーの実行、ウェーブプランの生成、およびサーバー移行の実行 図6. AWS Transform チャットインターフェイス ニーズに最適な VMware 移行ジョブタイプを選択します： 図7. VMware 移行用の AWS Transform ジョブオプション AWS Transform for VMware は AWS Application Migration Service (MGN) と統合されており、AWS Transform コンソールから直接 MGN 移行ライフサイクル全体を管理できます。この統合により、すべての MGN 関連タスクのための一元化されたインターフェイスを提供することで、移行プロセスを合理化します。AWS Transform 内で、以下のことができます： MGN エージェントをインストールしてソースサーバーを追加 カットオーバー前にアプリケーションの機能を確認するためのテストインスタンスの起動 移行状況の追跡 カットオーバーの実行 図8. AWS Transform ワークフロー AWS Transform for VMware は、ソースサーバー全体への自動エージェントデプロイメントのために MGN Connector を統合しています。MGN Connector はソース環境内の自動化サービスとして機能し、効果的に動作するために特定のコンポーネントを必要とします。これには、AWS Secrets Manager に保存された管理者資格情報、ソースサーバー上のサポートされているオペレーティングシステム、および TCP ポート 1500 と 443 を介した MGN Connector からソースサーバーへのネットワーク接続が必要です。 MGN Connector のデプロイメントは、必要な IAM ロール、ポリシー、ネットワークコンポーネントを確立し、AWS Systems Manager、AWS Secrets Manager、MGN サービスアクセスの権限を設定する AWS CloudFormation テンプレートを使用して自動化できます。 AWS Transform コンソール内で、ユーザーは既存のコネクタを選択するか、新しいコネクタを作成し、管理者資格情報を含む適切な AWS Secrets Manager シークレットに関連付けることで MGN Connector を構成できます。AWS Transform はまた、ソースサーバーに手動でレプリケーションエージェントをデプロイするオプションも提供します。 エージェントは MGN Connector または手動インストールを通じてデプロイされると、サービスは設定タスクを管理し、AWS Transform インターフェイスを通じてデプロイメントステータスの更新を提供します。要件と MGN 機能に関する最新かつ詳細な情報については、公式の AWS Application Migration Service ドキュメント を参照してください。 図9. AWS レプリケーションエージェントのインストール方法 AWS Transform インターフェイスから直接テストインスタンスを起動できます。このサービスはエクスポート可能なインベントリファイルを提供し、要件に応じてダウンロード、レビュー、変更してから AWS Transform にアップロードし直すことができます。インターフェイスはレプリケーションステータスの可視性を提供し、アプリケーションを「正常」、「遅延」、「停止」に分類し、ソースサーバーとその移行進捗の詳細なモニタリングを可能にします。 図10. テストインスタンスの起動 AWS Transform ダッシュボードでは、ウェーブ、アプリケーション、サーバー、ネットワークという 4 つの主要カテゴリを通じて移行の進捗を追跡できます。インターフェイスは移行メトリクスを単一のビューにまとめ、チームが複数の同時移行を監視できるようにします。ダッシュボードは単一のインターフェイスに移行ステータスデータを集中させることで、複数の AWS コンソールをナビゲートする必要性を減らします。 図11. AWS Transform ジョブダッシュボード ネットワーク作成 AWS Transform for VMware Migrations では、RVTools エクスポート (.csv と .xlsx の両方) と VMware NSX エクスポートを使用して、AWS でのネットワークトポロジーをモデル化およびデプロイできます。RVTools のみを使用すると、既存の VMware ネットワークに一致する VPC を構築できます。NSX を使用する場合、既存の NSX ネットワークを AWS にシームレスに変換して移行できます。VMware NSX 設定データは、オープンソースの Import/Export for AWS ユーティリティを使用して VMware 環境から効率的にエクスポートできます。NSX データのインポートにより、AWS Transform はセキュリティグループも構築できます。AWS Transform は CloudFormation と AWS Cloud Development Kit (CDK) の両方でネイティブな AWS ネットワーク設定を生成します。AWS Transform にネットワーク設定を自動的にデプロイさせることもできます。これは、ターゲットアカウントで生成された CloudFormation コードを実行することで達成されます。また、生成された CloudFormation または CDK コードをダウンロードして既存のビルドプロセスに統合することで、手動でデプロイするオプションもあります。 ネットワーク設計モデル Hub-and-spoke – Hub-and-spoke モデルでは、AWS Transform for VMware は VPC、AWS Transit Gateway、および AWS Transit Gateway アタッチメントをデプロイし、すべての VPC 間の通信を可能にします。 Isolated VPC – Isolated VPC モードは、Transit Gateway またはアタッチメントをデプロイせずに VPC を作成します。つまり、VPC は互いに分離されたままになります。分離された VPC は、顧客が既存の AWS インフラストラクチャを持っている場合に最も頻繁に使用されます。AWS Transform は VPC を作成し、それらを既存のネットワークにアタッチします。分離された VPC を使用すると、重複する IP 範囲を別々の非相互接続環境に移動でき、移行完了後に後でリンクすることができます。また、AWS Transform を使用して AWS を災害復旧サイトとして設定する場合にも効果的で、クリーンな分離と段階的な統合のための柔軟性を提供します。 クロスリージョン移行のサポート AWS Transform はクロスリージョン移行をサポートしており、コントロールプレーンはバージニア北部 (us-east-1) またはフランクフルト (eu-central-1) のいずれかに存在し、以下にリストされているリージョンのいずれかをターゲットに移行できます。 米国 バージニア北部 (us-east-1) オレゴン (us-west-2) アジア太平洋 ムンバイ (ap-south-1) ソウル (ap-northeast-2) 東京 (ap-northeast-1) シンガポール (ap-southeast-1) シドニー (ap-southeast-2) カナダ 中部 (ca-central-1) ヨーロッパ フランクフルト (eu-central-1) ロンドン (eu-west-2) パリ (eu-west-3) 南アメリカ サンパウロ (sa-east-1) MAP 2.0 タグ付けサポート AWS Migration Acceleration Program (MAP) は、数千のエンタープライズ顧客をクラウドに移行した AWS の経験に基づいた包括的で実績のあるクラウド移行プログラムです。MAP は、コストを削減し自動化して実行を加速するツール、カスタマイズされたトレーニングアプローチとコンテンツ、AWS パートナーネットワークのパートナーからの専門知識、グローバルパートナーコミュニティ、および AWS 投資を提供します。 タグとは、 AWS リソースにユーザーが適用するキーと値のペアで、そのリソースに関するメタデータを保持するためのものです。タグの例としては、名前、環境、ビジネスオーナー、またはあなたが追跡する必要があるその他の情報などが挙げられます。MAP の利点の 1 つは、一度限りの移行コストを相殺するのに役立つ AWS 投資であり、サービスクレジットの形でお客様に提供されます。クレジットの適格性は MAP 2.0 タグ付け によって追跡され、移行したリソースに特定のタグを活用します。AWS Transform がなければ、これは移行後に覚えておく必要のある手動のステップです。AWS Transform では、 MPE ID を入力するだけで、移行したすべてのリソースに自動的にタグが付けられます。 図12. MAP 2.0 タグ付けサポート 料金 現在、評価と変換を含む主要機能を AWS のお客様に無料で提供しています。これにより、初期費用なしで移行とモダナイゼーションの旅を加速できます。 結論 AWS Transform for VMware が一般提供を開始しました。これは、VMware ワークロードの AWS 上でのモダナイゼーションを簡素化し加速するために設計された画期的なエージェント型 AI を活用したサービスです。このツールはアプリケーションの検出、依存関係マッピング、ネットワーク変換、EC2 インスタンスの最適化という複雑なプロセスを自動化し、手作業の労力と移行リスクを大幅に削減します。私たちのパートナーは数ヶ月間このサービスをテストしてきました。以下は、そのうちの 2 社が顧客に対して見ている効果です。 「AWS Transform for VMware は、手戻りを減らし、コンサルティングの必要性を最小限に抑え、従来の知識のギャップを埋めることで、クライアントのクラウド移行プロセスを大幅に加速できます。内部テストに基づくと、AWS Transform for VMware は AWS への VM 移行時間を少なくとも 50% 削減できることがわかっています。現在、より迅速な移行と、ビジネスにとって価値主導の成果をさらに引き出すために、AWS Transform を私たちのツールに統合しています。」 – Neil Redmond, Managing Director | Accenture 「AWS Transform for VMware は VM の検出とワークロードの評価を自動化することで、移行計画を劇的に加速しました。このエージェント型 AI サービスは 100% の検出精度を達成し、リソース使用率、依存関係マッピング、およびインフラストラクチャの適切なサイジングに関する重要な洞察を提供しました。AWS Application Discovery Service および Migration Hub との統合は、当社の複雑な移行ニーズにとって特に価値があり、顧客の資産におけるアプリケーション依存関係をより良く理解するのに役立ちました。ディスカバリーのタイムラインを 50% 削減し、評価フェーズだけで 2 倍から 3 倍の加速を実現しました。私たちは、お客様のクラウドジャーニーを加速し続ける中で、インフラストラクチャモダナイゼーション提供の中核として AWS Transform を活用することを楽しみにしています。」 – Stefan Buchman, Head of Solutions | Slalom さらに読む VMware モダナイゼーションについてさらに詳しく知り、 VMware 移行の旅を始める方法を探ってください 。 AWS Transform for VMware のインタラクティブデモをチェックしてください。 ユーザーガイド を使用して、今すぐ自分のアカウントで AWS Transform の機能の探索を開始してください。 Patrick Kremer Patrick Kremer は、インフラストラクチャの移行とモダナイゼーションに特化したシニアスペシャリストソリューションアーキテクトです。Patrick は 2022 年に AWS に加わり、20 年間の VMware 経験を活かして、お客様が AWS ソリューションへ移行するのを支援しています。彼は教育とブログ執筆に情熱を持つ AWS 認定ソリューションアーキテクトプロフェッショナルです。 Pedro Calixto Pedro Calixto は AWS のシニアソリューションアーキテクトであり、ワークロードの移行とモダナイゼーションを専門としています。彼は、企業がオンプレミス環境を AWS 内で拡張、移行、保護するのを支援すること、そして AWS サービスを使用したアプリケーションのモダナイゼーションを加速することに重点を置いています。 Paul Cradduck Paul Cradduck は、テクノロジーとイノベーションへの生涯にわたる情熱に突き動かされ、約 20 年の経験を持つ経験豊富な IT プロフェッショナルです。AWS のシニアスペシャリストソリューションアーキテクトとして、スケーラブルなクラウドネイティブソリューションを中心に、組織のオンプレミスワークロードのモダナイズと移行を支援しています。深い好奇心と実践的なアプローチで知られる Paul は、常に最新の新興テクノロジーを探求し、学び、洞察を共有することに熱心です。彼はオハイオ州シンシナティで妻の Kathryn と 3 人の娘 Arlo、Isla、Zuri と暮らしています。 この投稿の翻訳は Solutions Architect の澤が担当させていただきました。原文記事は こちら です。

みなさんこんにちは。ソリューションアーキテクトの中島です。 本記事では 2025/04/17 に開催された 小売・消費財のお客様向けのデータ分析基盤イベント の様子を皆様にお伝えさせていただきます。 イベントの目的 本イベントは「データ分析を始めたいが、まず何から始めたらいいのか分からない。」「データ分析業務を進めているが技術だけでなくさまざまな障壁があり苦労している。」というお客様の声にお応えすべく企画されました。 そのため、以下 2 つを主題としてイベントを実施しました。 先行企業の経験からデータ活用の実践方法を学ぶ データ活用アイデアソンの結果をお持ち帰りいただきデータ活用の第一歩を踏み出していただく また、本イベントは AWS ではなくお客様の事例登壇が主体であるという点もユニークです。 当日のアジェンダ このイベントでは前半にユーザー企業様の事例登壇をしていただき、後半それをインプットにダッシュボードを描いてみるという構成になっておりました。 それでは以降詳細をご共有いたします。 大丸松坂屋百貨店 林 直孝氏 「カスタマーデータドリブン経営の勘所」 デジタルトランスフォーメーション（DX）が叫ばれる現代、実際の現場ではどのようにデータを活用し、ビジネス変革を進めているのでしょうか。大丸松坂百貨店 林氏による講演から、J.フロント リテイリンググループがどのようにデータドリブン経営に取り組み、成果を上げているかをお伝えします。 大丸松坂屋百貨店 林 直孝氏 J.フロントリテイリングの事例から見えた小売業におけるデータドリブン変革の重要ポイント データ活用の目的を明確にする（顧客のライフタイムバリュー最大化） グループ内の壁を越えてデータを統合し、顧客理解を深める データ活用のためのフレームワーク（DAPCサイクル）を構築する 実践を重視したデジタル人財育成プログラムを展開する 技術とともに「マインドセット」の変革も推進する 戦略 J フロントリテイリング (以降、JFR) 様は大丸松坂屋百貨店様と PARCO 様を擁する持株会社として、「価値共創リテーラー」を目指しています。同社の DX 戦略は単なるデジタル化ではなく、従業員体験 (EX) と顧客体験 (CX) を向上させることに焦点を当てています。 JFR 様では若い世代のお客様から支持の高い PARCO と幅広い年齢層向けの大丸松坂屋という異なる業態を持つ強みを活かし、顧客のライフタイムバリューの最大化を図っています。 データ活用の原点 データ活用の原点となったのは、PARCO での興味深い顧客行動の発見です。データ分析により、複数のショップを利用する顧客の方が、単一ショップのみの利用者よりも翌年の再来店率が高いという事実が判明しました。この発見は PARCO と大丸松坂屋の双方をご利用になるお客様の方が、どちらか一方を利用するお客様よりも LTV が高いお客様ではないか？という仮説につながり、実際にデータ分析を行いそれが実証され、グループ間データ統合の重要性を示す根拠となりました。 グループデータの統合と活用 ライフタイムジャーニーに寄り添ったお客様固有のサービスを提供していくことが重要であると考えられているため、世代ごとに利用の違う PARCO・大丸松坂屋百貨店、両社のアプリ等から収集したデータを統合し分析する環境を構築されていました。これにより、お客様のライフステージに応じた長期的な関係構築が可能になっています。 DAPC サイクルとデジタル人材育成 データ活用を組織的に進めるため、JFR グループのパルコでは「DAPC サイクル」を回すことで組織としての CRM を実行していました。 JFR グループとして複数の事業会社のデータを活用してこのサイクルを回すための課題の一つとしてグループ共通のデータを駆使できるデータアナリストやデジタルデザイナー人財の育成が 必要でした。 JFR では 2022 年から本格的な デジタル人財育成プログラム を開始し、2030 年までにグループ内で 1,000 名のデジタル人財育成を目標に掲げています。このプログラムの特徴は、 徹底した実践重視のアプローチ です。受講者は実際の業務データを使用し、3 ヶ月間で約 50〜60 時間のカリキュラムを受講します。プログラム中に作成した ダッシュボードなどのツールは、修了後もそのまま業務で活用 できます。また育成されたデジタル人財は後続メンバーの育成にも関わり、組織全体のデジタルリテラシー向上に貢献しています。 技術スキルだけでなく、「完成度が 60% でもまずやってみる」「スピードを重視する」などのアジャイルなマインドセットも重視されています。 独自の「花伝書」を作成 し、 デジタル文化の定着 を図っています。 データアナリスト育成講座の卒業生の手で「JFR グループ データ活用ポータル」が構築され、現場での意思決定に活用されています。コア人財の育成と現場への還流によって、DAPC サイクルも機能しはじめました。 まとめ 大丸松坂屋百貨店様のご登壇は、小売業におけるデータ活用の重要性と、それを実現するためのテクノロジー・組織・人財の三位一体の取り組みの重要性を示されていました。特に、AWS 基盤を活用した統合データ基盤の構築と、それを活用できる人財の育成に注力している点は、多くの企業様にもご参考になると思います。 オイシックス・ラ・大地株式会社 中野 高文氏 「食の課題をデータで解く 〜ゼロから構築した分析基盤と成果〜」 オイシックス・ラ・大地（以下、オイシックス）様のご登壇では、実際にビジネスインパクトを出すための実践的なデータ基盤構築と活用のアプローチが示されました。ご登壇では、同社がデータ活用を進める中で直面した課題とその乗り越え方をご紹介いただきました。 オイシックス・ラ・大地株式会社 中野 高文氏 オイシックス様の事例から見えたデータ基盤導入を確実に前に進めるための重要ポイント 活用テーマ: ROI 説明可能なテーマから着手する トップダウン: 経営層の巻き込みが成功を後押し ボトムアップ: 現場の知見が DWH 品質を決める 内製化: 改善スピードを担保するためには不可欠 アジャイル: 完璧を目指さず使いながら育てる データ基盤導入の壁 データ活用を成功させる上での課題を 4 つ挙げていただきました。まず、データ基盤構築には高額な投資が必要ですが、具体的な ROI が見えにくく経営層の承認を得るのが困難 です。また、データに関する経験不足から判断に自信を持てない経営層も多くいます。次に、 システム側が作ったツールが現場のニーズに合わない という事業部とデータチームの連携不足があります。データ基盤はビジネスナレッジの塊であり、現場を理解せずに構築することはできません。さらに、一度構築したデータ基盤は 放置すると品質が劣化 するため、継続的な監視と改善が必要です。最後に、最初から完璧な設計を目指す ウォーターフォール型アプローチよりも柔軟な対応が必要 で、初期は外部パートナーの活用が効率的ですが、長期的には内部人材の育成が重要です。 Data Cuisine によるデータ活用の成果 こうした課題を解決しながら、オイシックス様は AWS サービスを一気通貫で活用するアーキテクチャを選択し、Data Cuisine を構築されていました。既存システムとの連携のしやすさ、サービス間のオーケストレーションの容易さ、複数クラウド管理の負担回避が主な理由です。 オイシックス様ではデータ基盤の構築により複数の重要な成果が得られました。まず業務効率が劇的に改善され、データアナリストが手作業から解放されて 本来の分析業務に集中できる環境 が実現しました。この変化は単に作業時間の短縮だけでなく、専門人材の 職場満足度向上 にも大きく貢献しています。次に、構築したデータ基盤は販売計画システムの中核として組み込まれ、過去実績に基づく計画立案、在庫数決定などの 重要なビジネスプロセスを支え ています。さらに、経営層が気にする売上に貢献する形で、様々な販売チャネルで パーソナライズされた商品提案が可能 になりました。 5 つの成功ポイント オイシックス様が先述の課題をどのように乗り越え、データ基盤構築を成功させたか 5 つのポイントを発表くださいました。 1. 活用テーマを先に決める: 「完全なデータを集める」には膨大なコストと時間がかかるため、まずビジネス目的を明確にしました。オイシックス様では「生産者とお客様のマッチング」と「需要予測」を優先テーマとし、そこから必要なデータを特定しました。これにより効率的な基盤構築が可能になりました。 単なる生産性向上だけでは ROI が見えづらいため、具体的なビジネス価値と紐づけることが投資説得にも効果的 でした。 2. トップダウンでの推進: 大規模プロジェクトには経営層の継続的サポートが不可欠です。オイシックス様では事業部門とシステム部門両方の執行役員の協力を得て推進しました。 プロジェクト途中で経営体制が変わり支援者がいなくなった 時期は苦戦したため、経営層が交代しても継続的に支持されるよう、 定期的な成果報告と次の展望を示し続けることが重要 でした。 3. ボトムアップでの巻き込み: オイシックス様では 事業部兼務のデータアナリストとエンジニアを配置 し、日々の業務から得られる 現場の声を直接システムに反映 しました。例えば「この受注データは除外すべき」「この数値は別ロジックで計算する必要がある」といった現場特有のルールを把握できたことがシステムの実用性を高めました。また、一度構築したら終わりではなく、日々発生する新しいデータの品質維持にも現場の協力が不可欠だという認識が重要でした。 4. 内製化の推進: 初期段階では社内にスキルを持つ人材がおらず、パートナー企業に依存していましたが、段階的に内製化を進めました。経験からわかったのは、パートナーは初期構築には有効でも、ビジネス特有の ドメイン知識が必要な改善 や、日々増加する 要求への迅速な対応 には 内部人材が不可欠 だということです。データ基盤が活用され始めると、事業部からのリクエストが急増しますが、その多くはビジネスコンテキストの深い理解が必要なため、継続的に内製化を進めてきました。これにより変化するビジネスニーズに素早く対応できる体制が整いました。 5. アジャイルな進め方: 実際にデータ基盤を使い始めてみると 要件が次々と変わる ことに気づきました。そこで、小さな価値を早期に提供しながら改善を繰り返す アジャイルアプローチ に転換しました。また、一から完璧に作るより、 既存ロジックを継承 しつつ 徐々に改善 する方が、 現場の混乱も少なく効率的 だったという教訓を得ています。 まとめ オイシックス様が目指す「こだわりの生産者とお客様をデータでつなぐプラットフォーム」の実現には、数々の課題がありました。しかし、明確な目的設定、経営層の巻き込み、現場との協働、内製化推進、アジャイル開発という 5 つのアプローチで乗り越え、データ基盤をビジネスの中核に据えることに成功されています。これらの知見は、同様の課題に直面する多くの組織にとって参考になるでしょう。 データ活用アイデアソン 「事例講演を聞き参考になった」、「データ活用に課題感を持っている」お客様にデータ活用の一歩を踏み出していただくべく、現状の課題を仮説し、ダッシュボードのスケッチを描くアイデアソンを実施いたしました。 データ活用アイデアソンはご説明を含めて 70 分 で実施しました。 実質的なワークは上記 1, 2 にあたる個人ワーク (50分) でしたが、この短い時間でも 20 以上のダッシュボードのアイデアが生まれました。 短い時間にも関わらず、ご参加いただいた方全員がダッシュボードを描くことができたのは、皆様の集中力と前向きに取り組んでいただいた結果だと思います。 グループワークでは皆様のダッシュボードの見どころを 1 分 という短い時間でご共有いただき、懇親会での決勝戦に進むアイデアを選定いただきました。私はグループを回らせていただき皆様のアイデアを拝見いたしましたが、どのアイデアも素晴らしく甲乙つけ難かったかと思います。 懇親会 (アイデアソン決勝戦) 懇親会ではユーザー企業様同士でネットワーキングしながらダッシュボードに投票していただくワールド・カフェ形式で実施しました。「このアイデアのいいところはなんだろうか」とユーザー企業様同士で会話しながらワイワイと投票していただきました。 ユーザー企業様の投票で決める「お客様賞」には株式会社 PALTAC 村田さんが選ばれました。おめでとうございます！ 村田さんの勝因は「日頃から事業部側と会話することが多い」とのことでした。 事業部の課題感をしっかり捉えたダッシュボードがユーザー企業様の心を掴んだ結果となりました。 また、AWS メンバーの投票で決める「AWS 賞」にはクオール株式会社 北嶋さんが選ばれました。おめでとうございます！ 北嶋さんは「日頃からデータ分析を業務としており、今回は目的に合わせてどれだけシンプルにできるかを心がけた」とのことでした。 シンプルかつ効果的なダッシュボードが AWS メンバーを唸らせた結果となりました。 お客様の声 本セミナー全体の CSAT (お客様満足度) 4.52 / 5 となりご満足いただける内容になったのではと一安心しております。ユーザー企業様登壇では「他社事例が大変勉強になった」「リアルな内容で良い時間になった」と嬉しいお声をいただいています。またアイデアソンについては「色々な方のアイデアが見れて良かった」「もっと時間が欲しかった。今回は複数社合同だったが自社のみでの開催も可能か？」とイベント後にも活用いただけそうなお声をいただき大変嬉しいです。 最後に ご登壇くださった大丸松坂屋百貨店 林氏、オイシックス・ラ・大地 中野氏に心より感謝申し上げます。お二方の素晴らしいプレゼンテーションは、多くの企業様に勇気と情熱を与えるものでした。また、3 時間という長時間にも関わらず、懇親会まで積極的にご参加いただいた皆様にも御礼申し上げます。本イベントが皆様のデータ活用の一助となれば幸いです。 これからも、AWS 小売・消費財チームはユーザー企業様間の情報共有・議論の場をご提供し、1 つでも多くのお客様ビジネス課題の解決をご支援させていただく所存です。今後ともご期待ください！ 著者 中島 佑樹 西日本の小売・消費財のお客様をメインで担当するソリューションアーキテクト。社会人博士を修了したことをきっかけに AIML を得意分野としている。Amazon Bedrock Agents の BlackBelt や Blog を執筆。