本記事は、2024年5月9日に公開された Establishing an AI/ML center of excellence を翻訳したものです。 人工知能と機械学習（AI/ML）の急速な進歩は、業界を問わず変革の原動力となっています。 マッキンゼーの調査 によりますと、ファイナンスサービス業界（FSI）全体で、 生成AI は4,000億ドル（業界売上高の5％）以上の生産性向上をもたらすと予測されています。 ガートナー によりますと、2026年までに80％以上の企業がAI を導入する見込みです。Amazon では、イノベーションがカスタマーエクスペリエンスの向上とプロセスの効率化をもたらし、生産性を向上させると考えています。生成AI は事業変革の契機となるため、FSI の企業にとって、お客さまに最大の価値をもたらす 生成AI の可能性を特定 することが不可欠です。 業界を問わず企業は、生成AI の組織全体への導入における 無数の課題 、具体的には明確なビジネスケースの欠如、PoC を超えた拡大の難しさ、ガバナンスの欠如、適切な人材の確保などに直面しています。このような幅広い問題に対処する効果的なアプローチとして見受けられるものが、AI/ML CoE (Center of Excellence) の設立です。AI/ML CoE は、組織内のすべてのAI/ML の取り組みを調整・統括し、事業戦略と価値提供の橋渡しをおこなう集権型もしくは連合型の専門的なユニットです。ハーバード・ビジネス・レビューの調査によりますと、AI/ML CoE は米国の 大企業の37% で既に設立されています。企業が生成AI の導入を成功させるためには、事業部門や技術部門を超えた連携が重要性を増しています。 本記事は、 AI/ML のためのクラウド導入フレームワーク や Well-Architected Machine Learning Lens と併せて、生成AI の可能性を捉えるために効果的なAI/ML CoE を導入するガイドとなります。CoE のミッションの定義、リーダーシップチームの組成、倫理ガイドラインの統合、ユースケースの認定と優先付け、チームのスキルアップ、ガバナンスの導入、インフラストラクチャの構築、セキュリティの組み込み、オペレーショエクセレンスの実現などが含まれます。 AI/ML CoE とは何か? AI/ML CoE は、事業戦略や製品戦略に沿ったAI/ML のユースケースを特定し、異なる事業部門で共通する再利用可能なパターンを認識し、組織全体のAI/ML のビジョンを導入し、コンピューティングハードウェアとソフトウェアを最適に組み合わせたAI/ML のプラットフォームとワークロードを導入していくことについて、事業部門やエンドユーザーと連携していく役割を担います。CoE チームは、事業の専門知識と AI/ML の高度な技術力を組み合わせ、組織全体で相互運用性と拡張性のあるソリューションを開発・導入します。設計、開発、プロセス、ガバナンスの運用を網羅するベストプラクティスを確立し、実施することで、リスクを軽減し、事業、技術、ガバナンスのフレームワークが一貫して維持されるようにします。利用、標準化、拡張、価値提供のために、AI/ML CoE の成果は、公開ガイダンス、ベストプラクティス、教訓、チュートリアルといったガイダンスと、人材のスキル、ツール、技術ソリューション、再利用可能なテンプレートといった能力構築に大別されます。 AI/ML CoE を設立する利点は次のとおりです。 明確な道筋による市場投入までの時間の短縮 生成AI でのビジネスアウトカムによる投資対効果の最大化 リスク管理の最適化 チームのスキルアップの体系化 標準化されたワークフローやツールによる持続可能な拡張 イノベーションの取り組みの支援と優先付けの強化 効果的な AI/ML CoE を確立するための主要な構成要素を次の図に示します。 番号の付いた各構成要素について以下の章で詳しく説明します。 1. スポンサーシップとミッション AI/ML CoE を設立する基本的なステップは、経営層からのスポンサーシップを確保し、リーダーシップを確立し、ミッションと目的を定義し、リーダーシップを方向付けることです。 スポンサーシップの確立 意思決定プロセス、説明責任、倫理的・法的基準の遵守を確実にするために、リーダーシップの役割や体制を確立します。 エグゼクティブスポンサーシップ – AI/ML の取り組みを支持する経営層からの支援を確保します。 ステアリングコミッティ – AI/ML CoE の活動と戦略的な方向性を統括するために、主要なステークホルダーからなるコミッティを結成します。 倫理委員会 – AI/ML の開発と導入において、倫理的かつ責任あるAI の考慮事項に取り組む委員会を設置します。 ミッションの定義 ミッションを、顧客や製品に焦点を当て、組織の全体的な戦略目標と整合させることで、AI/ML CoE の役割を明確にできます。ミッションは、一般的にはエグゼクティブスポンサーが事業部門の責任者と連携して設定し、すべての CoE 活動の指針となるもので、以下の内容を含みます。 ミッションステートメント – AI/ML の技術を活用した顧客経験向上や製品差別化により事業便益を拡大するというCoE の目的を明確に示します。 戦略目標 – 組織全体の戦略目標に沿った、具体的かつ測定可能なAI/ML の目標を示します。 バリュープロポジション – 期待される事業上の価値について、コスト削減、収益向上、ユーザー満足度向上、時間短縮、市場投入の時間削減など、KPI (Key Performance Indicators) を定量化します。 2. 人材 ガートナーのレポートによりますと、生成AI に関する自身の技術力について、事業、機能、技術の各部門の 53% が「中級」と評価し、経営陣の 64% が「初級」と評価しています。事業のニーズに合わせてカスタマイズされたソリューションを開発することで、継続的な成長と学習の文化を育み、生成AI のスキルを開発しながら、AI とML の技術に関する理解を深められます。 トレーニングと活用支援 AI/ML CoE は、従業員にAI/ML の概念、ツール、技術を教育するために、トレーニングプログラム、ワークショップ、 認定プログラム 、ハッカソンを開発します。これらは、習熟度に合わせてカスタマイズ可能で、従業員がAI/ML を活用して課題を解決する方法を理解できるよう設計されます。加えて、CoE は、AI/ML のスキル向上を希望する従業員へのメンタリングの場を提供したり、一定の熟達度を認定するプログラムを開発したり、最新の技術や方法をアップデートできる継続的なトレーニングを実施します。 ドリームチーム バランスのとれたAI/ML のソリューションを実現するには、部門横断的な取り組みが不可欠です。業界、事業、技術、コンプライアンス、オペレーションの専門知識を組み合わせたAI/ML CoE を設置することで、イノベーションを推進します。企業の戦略目標の達成に、AI の多面的な可能性を活用します。AI/ML の専門知識を持った多様性あるチームには、次のような役割が含まれます。 プロダクトストラテジスト – すべての製品、機能、実験が、変革の戦略に合致していることを確認します。 AI リサーチャー – イノベーションを推進し、生成AI などの最先端技術を探求するために、この分野の専門家を採用します。 データサイエンティストと ML エンジニア – データの前処理、モデルのトレーニング、検証の機能を開発します。 ドメインエキスパート – 特定のアプリケーションやビジネスニーズを理解している事業部門の専門家と共同します。 オペレーション – KPI の策定、価値提供の実証、MLOps のパイプラインの管理をします。 プロジェクトマネージャー – プロジェクトを効率的に実施するプロジェクトマネージャーを任命します。 ナレッジシェアリング CoE、社内のステークホルダー、事業部門のチーム、外部のステークホルダーとのコラボレーションを促進することで、知識の共有や分野横断的なチームワークを実現します。AI/ML の取り組みによるインパクトを最大化するために、ナレッジシェアリングを促進し、ナレッジのリポジトリを構築し、部門横断的なプロジェクトを促進します。ナレッジシェアリングを促進する主な活動例は次のとおりです。 部門を超えたコラボレーション – 生成AI の専門家と事業部門の専門家とのチームワークを促進し、部門を超えたユースケースを生み出します。 戦略的パートナーシップ – 生成AI を専門とする研究機関、大学、業界のリーダーとのパートナーシップを検討し、それらの専門知識や見識を活用します。 3. ガバナンス リスク、コンプライアンス、セキュリティを適切に管理しつつ、AI/ML の取り組みで価値提供を拡大できるようガバナンスを確立する必要があります。さらに、AI の開発と拡大に伴うリスクとコストの変化にも注意を払う必要があります。 責任あるAI 公平性、説明可能性、プライバシーとセキュリティ、堅牢性、ガバナンス、透明性などの観点を取り入れることで、生成AI に関連する潜在的な倫理的ジレンマに対処できます。 倫理的完全性 を確保するため、AI/ML CoE はステークホルダーと協力し、AI/ML のライフサイクル全体にわたり、しっかりしたガイドラインとセーフガードを統合します。CoE は、 積極的なアプローチをとること により、倫理的なコンプライアンスを実現するだけでなく、信頼性を高め、説明責任を強化し、信憑性、有害性、データの悪用、知的財産に関する懸念などの潜在的なリスクを軽減します。 標準とベストプラクティス CoE は、卓越性への歩みを続け、共通の基準、業界を主導するプラクティス、ガイドラインの定義を支援します。データガバナンス、モデルの開発、倫理的な取り組み、継続的な監視を含む包括的なアプローチが含まれ、責任ある倫理的なAI/ML の実践のための組織のコミットメントを強化します。標準の例には以下が含まれます。 開発フレームワーク − AI の開発、導入、ガバナンスの標準フレームワークを確立することで、プロジェクト間で一貫性が保たれ、ベストプラクティスの採用と共有が容易になります。 リポジトリ – コードやモデルのリポジトリを一元化することで、コーディング規約のベストプラクティスや 業界標準のソリューション の共有を容易にします。それにより、チームは一貫したコーディング規約に基づいて、共同性、再利用性、保守性を向上することができます。 一元化されたナレッジハブ – データセットや研究成果を格納する一元的なリポジトリで、包括的なナレッジセンターとして機能します。 プラットフォーム – Amazon SageMaker のような、クリエーション、トレーニング、デプロイの中心的なプラットフォームで、主要なポリシーや標準を管理、拡張します。 ベンチマークとメトリクス – AI のモデルのパフォーマンスや事業価値を測定したり比較するための標準化されたメトリクスやベンチマークを定義します。 データガバナンス データガバナンス はAI/ML CoE の重要な機能で、データが責任ある信頼できる方法で収集、使用、共有されることを確認します。AI アプリケーションでは多くの場合で大量のデータを使用するため、データガバナンスは不可欠です。データの品質と完全性が、AI を活用した意思決定の正確性と公平性において重要となります。AI/ML CoE は、データの前処理、モデルの開発、トレーニング、検証、およびデプロイに関する ベストプラクティスとガイドライン を定義することを支援します。CoE は、データが正確、完全、最新であること、データが不正なアクセス、使用、開示から保護されていること、データガバナンスポリシーが規制や内部コンプライアンスを遵守していることを確認する必要があります。 モデルの監視 モデルのガバナンスは、企業がポリシーを導入し、モデルへのアクセスを制御し、アクティビティを追跡する方法を決定するフレームワークです。CoE は、モデルが安全で信頼でき、倫理的な方法で開発およびデプロイされていることを確認できるようにします。モデルのガバナンスポリシーは、組織の透明性に対するコミットメントや、顧客、パートナー、規制当局との信頼構築を示します。また、 Guardrails for Amazon Bedrock などのサービスを使用し、お客さまのアプリケーションの要件に合わせてカスタマイズされたセーフガードを提供し、責任あるAIのポリシーが実装されていることを確認できるようにします。 価値提供 AI/ML の取り組みの投資対効果、プラットフォームとサービスの費用、リソースの効率的かつ効果的な使用、継続的な最適化を管理します。そのためには、ユースケースに関連するKPI と、データの保存、モデルのトレーニング、推論に関連する支出を監視・分析する必要があります。さまざまな AI のモデルやアルゴリズムのパフォーマンスを評価し、費用対効果が高い、リソース最適化されたソリューションを特定することも含まれます。たとえば、推論には AWS Inferentia を、トレーニングには AWS Trainium を使用します。KPI とメトリクスの設定は、効果を評価する上で極めて重要です。KPI の例は次のとおりです。 投資対効果 (ROI) – 投資に対する財務的なリターンを評価することで、AI のプロジェクトへのリソース配分の正当性を示すことができます。 ビジネスインパクト – 収益の増加やカスタマーエクスペリエンスの向上などの具体的な事業上の成果を測定することで、AI の価値が検証されます。 プロジェクトの実施時間 – プロジェクトの開始から完了までの時間を追跡することで、業務の効率性や迅速性を示すことができます。 4. プラットフォーム AI/ML CoE は、事業部門や技術部門と連携し、エンタープライズグレードの拡張性を備えたAI プラットフォームの構築を支援します。それにより、事業部門全体でAI に対応したサービスや製品の運用が可能になります。また、カスタムのAI ソリューションの開発や、実務者がAI/ML 開発の変化に対応できるようにすることも支援します。 データおよびエンジニアリングアーキテクチャー AI/ML CoE は、技術部門と連携して、AI ソリューションの導入や拡張を加速する適切なデータフローやエンジニアリングインフラストラクチャーを整備します。 ハイパフォーマンスコンピューティングリソース – 複雑なモデルのトレーニングには、最新のNVIDIA H100 Tensor コア GPU を搭載した Amazon Elastic Compute Cloud (Amazon EC2) インスタンス などの強力な GPU が不可欠です。 データストレージと管理 – AWS Glue や Amazon OpenSearch Service などの堅牢なデータの保存、処理、管理のシステムを導入します。 プラットフォーム – クラウドプラットフォームを使用することで、SageMaker のように、AI/ML プロジェクトに柔軟性と拡張性がもたらされます。それにより、生成AI の実験、データの準備、モデルのトレーニング、デプロイ、監視にわたるエンドツーエンドのML 機能を提供できます。実験から本番稼働までの生成AI のワークロードを加速します。 Amazon Bedrock は、基盤モデル（FM）による生成AI アプリケーションの構築と拡張を容易にするフルマネージドサービスで、AI21 Labs、Anthropic、Cohere、Meta、Stability AI、Amazon などの主要なAI 企業の高性能なFM を選択できます。 開発ツールとフレームワーク – Amazon CodeWhisperer 、 Apache MXNet 、 PyTorch 、 TensorFlow などの業界標準の AI/ML のフレームワークやツールを使用します。 バージョン管理およびコラボレーションツール – Git リポジトリ、プロジェクト管理ツール、およびコラボレーションプラットフォームは、 AWS CodePipeline や Amazon CodeGuru のように、チームワークを促進します。 生成 AI フレームワーク – Amazon Bedrock で利用できる最先端の基盤モデル、ツール、エージェント、ナレッジベース、ガードレールを活用します。 実験プラットフォーム – Amazon SageMaker JumpStart のような、再現性やコラボレーションを実現する実験やモデル開発のためのプラットフォームを導入します。 文書化 – 実務者とチーム間の知識共有を促進するために、プラットフォーム内のプロセス、ワークフロー、ベストプラクティスの文書化を重視します。 ライフサイクルマネジメント AI/ML CoE で拡張性、可用性、信頼性、パフォーマンス、回復力を重視することは、AI/MLの取り組みを成功させたり適応させていくために重要となります。 MLOps などのライフサイクル管理システムの導入でデプロイや監視を自動化でき、信頼性、市場投入までの時間、オブザーバビリティが向上します。ワークフロー管理には Amazon SageMaker Pipelines 、実験の管理には Amazon SageMaker Experiments 、コンテナオーケストレーションには Amazon Elastic Kubernetes Service (Amazon EKS) などのツールを使用することで、AI/ML アプリケーションの柔軟な導入と管理が可能になり、さまざまな環境にわたる拡張性と移植性が促進されます。同様に、 AWS Lambda などのサーバーレスアーキテクチャを採用することで、需要に応じた自動スケーリングが可能になり、リソースの割り当てに柔軟性を持たせながら運用の複雑さを軽減できます。 AI サービスでの戦略的提携 ソリューションを購入するか開発するかのトレードオフを検討する必要があります。購入は、既製のツールを使用することでスピードと利便性を得られますが、カスタマイズ性に欠けます。一方で、開発は、カスタマイズされたソリューションが得られますが、時間とリソースが必要になります。プロジェクトの規模、期間、長期的な必要性に基づき、組織の目標と技術的な要件との整合を目指す必要があります。理想的には、解決すべき具体的な課題、組織の能力、事業成長の対象領域を徹底評価し、意思決定を行います。例えば、独自性を築けるものであるならば差別化のために開発し、コモディティ化された標準的なビジネスプロセスに基づくものであるならば購入して効率化します。 CoE は、 AWS Generative AI Competency Partners などのサードパーティAI サービスプロバイダーと提携し、その専門性と経験を活用することで、AI ベースのソリューションの導入と拡大を加速できます。このようなパートナーシップを通じ、CoE は最新のAI/ML の動向を把握し、最先端のAI/ML ツールやテクノロジーにアクセスできます。さらに、サードパーティのAI サービスプロバイダーは、新しいAI/ML のユースケースの特定や、効果的なAI/ML のソリューションの導入のガイダンスを提供できます。 5. セキュリティ 組織のデータ、AI/ML、生成AI のワークロードの全体に渡って、セキュリティとプライバシーの管理を徹底します。AI/ML のあらゆる側面で、脆弱性と脅威を特定・分類・是正・緩和するセキュリティ対策を統合します。 全体的な警戒 生成AI のソリューションの利用方法に基づいて、 セキュリティ対策の範囲を設定 し、 ワークロードの弾力性を設計 し、 関連するセキュリティコントロールを適用 します。暗号化技術、多要素認証、脅威検出、定期的なセキュリティ監査など、不正アクセスや侵害から確実にデータとシステムを保護する対策が含まれます。新たな脅威に対処するため、定期的な脆弱性評価と脅威モデリングが重要です。モデルの暗号化、セキュアな環境の使用、異常の継続的な監視など、敵対的な攻撃や悪用からの保護策も重要です。 Amazon GuardDuty のようなツールで、脅威検出のためにモデルの監視ができます。 Amazon Bedrock では、生成AI のアプリケーションの基礎モデルのカスタマイズに利用するデータを完全に制御可能です。転送中も保存中もデータは暗号化され、ユーザーの入力やモデルの出力は、モデルプロバイダーと共有されることはありません。 エンド・ツー・エンドでの安全 AI システムの3大構成要素（入力、モデル、出力）のセキュリティ確保は極めて重要です。ライフサイクル全体で、明確な役割、セキュリティポリシー、標準、ガイドラインを設けることで、システムの完全性と機密性を維持できます。 NIST 、 OWASP-LLM 、 OWASP-ML 、 MITRE Atlas などの 業界のベストプラクティスの対策 や業界のフレームワークの実装が含まれます。さらに、カナダの個人情報保護および電子文書法（PIPEDA）や欧州連合の一般データ保護規則（GDPR）などの要件を 評価し、導入 します。 Amazon Macie などのツールで、機密データを検出・保護できます。 インフラストラクチャー（データとシステム） 機密性の高いデータを扱うため、アクセスやプライバシーを保護する技術の 検討と導入 が不可欠です。最小権限でのアクセス、データリネージ、ユースケース関連データのみの保持、プライバシー侵害なくコラボレーションできる機密データの分類など、そうした技術が含まれます。これらをAI/ML 開発のライフサイクルのワークフローに組み込み、 安全なデータとモデリング環境 を維持し、プライバシー規制を遵守し、機密情報を保護する必要があります。AI/ML CoE の戦略に セキュリティ重視の対策 を組み込むことで、データ侵害、不正アクセス、敵対的攻撃に伴うリスクを軽減し、AI の資産と機密情報の完全性、機密性、可用性を確保できます。 6. オペレーション AI/ML CoE は、組織内での生成AI 導入における効率性と成長機会の最大化に注力する必要があります。この章では、ワークロードのパフォーマンスを維持しつつ、統合を成功させるためのいくつかの重要な側面について説明します。 パフォーマンス管理 効果を測るため、KPI やメトリクスの設定が極めて重要です。これらを定期的に評価することで、進捗状況を追跡し、傾向を特定し、CoE 内に継続的改善の文化を醸成できます。これらの洞察を報告することで、組織の目標との整合性が保たれ、AI/ML の取り組みの強化に向けた意思決定プロセスが明確になります。 Amazon Bedrock とAmazon CloudWatch の統合 などのソリューションは、メトリクスの追跡・管理と、監査用のカスタマイズされたダッシュボードの構築に役立ちます。 KPI の例としては、モデルの精度があります。ベンチマークに照らしてモデルを評価することで、AI が生成するアウトプットの信頼性を高めることができます。 インシデント管理 AI/ML のソリューションでは、異常なアクティビティを管理するため、継続的な制御と監視が必要です。それには、AI/ML のプラットフォーム全体で、理想的には自動化されたプロセスとシステムの確立が必要です。選定した監視ソリューションに合わせ、標準化されたインシデント対応の戦略を策定・実施する必要があります。正式な役割分担、監視対象のデータソースやメトリクス、監視システム、緩和やエスカレーション、根本原因分析などの対応措置などが含まれます。 継続的改善 生成AI のモデルの開発・テスト・導入のための しっかりとしたプロセス を定義します。堅牢なプロセスを定義・改良することで、生成AI のモデルの開発を効率化します。AI/ML のプラットフォームの定期的なパフォーマンス評価と、生成AI の機能の強化を行います。これには、ステークホルダーやエンドユーザーからのフィードバックの反映、生成AI の先行研究やイノベーションへの資源投入が含まれます。こうした取り組みで、継続的な改善を促し、CoE はAI のイノベーションの最前線を維持できます。さらに、アジャイル手法の導入、包括的な文書の管理、定期的なベンチマークの実施、業界のベストプラクティスの採用により、生成AIの取り組みをシームレスに実施します。 7. ビジネス AI/ML CoE は、事業部門全体の優先的な課題や機会を継続的に特定することで、事業変革を推進します。CoE は、事業課題や機会にAI/ML の機能を対応させ、価値あるソリューションの迅速な開発と導入を促進します。実際の事業ニーズへの対応を通じて、新製品、新収益源、生産性向上、業務最適化、顧客満足度向上など、段階的な価値創造を実現します。 AI 戦略策定 事業成果の実現を目指して、AI/ML や生成AI の技術導入によりどのように事業を変革できるかについて、複数年の説得力あるビジョンと戦略を確立します。3～5年といった戦略計画期間中に、AI/ML から得られる収益、コスト削減、顧客満足度向上、生産性向上、その他の重要業績指標における具体的な価値を定量化します。さらに、CoE は、AI/ML の導入による競争力強化と主要なプロセスやサービスの段階的改善を説明し、各事業部門の経営幹部からの賛同を得る必要があります。 ユースケース管理 CoE は、 最も有望なAI/ML のユースケースを特定、適格化、優先付け するために、全事業部門と継続的な対話を行い、最優先課題と機会を明らかにします。複雑な事業課題や機会は、CoE が事業部門のリーダーと連携して、AI/ML を活用したソリューションに適したものであるか明確化する必要があります。取り組みの成功指標を事業KPI と結び付け、期待される価値と懸念される導入の複雑さの関係を示します。事業価値と実現可能性に基づいて機会を評価し、有望なAI/ML のユースケースを優先付けてパイプラインをつくります。 PoC 本格的な開発に先立ち、 高付加価値 のユースケースについて、初期実現可能性を示す概念実証（PoC）プロジェクトでプロトタイプをつくります。PoC 段階の迅速なフィードバックループで、アプローチを小規模にして反復と改良をします。CoE は、事業部門のリーダーと連携しながら、事業指標・KPI に紐付くPoC の成功基準を明確に設定します。さらにCoE は、専門知識、再利用できる資産、ベストプラクティス、標準を提供します。 経営幹部との連携 透明性を確保するため、事業部門の経営層は、AI/ML の取り組みに関与し、定期報告を受けます。エスカレーションが必要な課題は、取り組みに精通した経営層が迅速に解決できます。 8. 法務 AI/ML や生成AI の法的環境は複雑で進化を続けており、組織に多数の課題や影響をもたらしています。データプライバシー、知的財産、責任、偏見などの問題について、AI/ML CoE 内で慎重に検討する必要があります。規制が技術の進化に追い付いていこうとしている中、CoE は法務チームとこの変化する状況に対応し、コンプライアンスを遵守した責任ある開発や導入を進めます。状況は変化し続けるため、CoE は法務チームと連携して、AI/ML のライフサイクル全体をカバーする包括的なAI/ML ガバナンスポリシーを策定する必要があります。事業側の関係者が意思決定に参画することや、ガバナンスのポリシーが遵守されていることを検証するためにAI/ML システムを定期的に監査やレビューすることが含まれます。 9. 調達 AI/ML CoE は、購入か開発かの戦略策定に向けて、独立系ソフトウェアベンダー（ISV）やシステムインテグレーター（SI）などの パートナーと協力 する必要があります。調達チームと連携して、選定から導入や管理を経て終了に至るまでのフレームワークを整備する必要があります。技術、アルゴリズム、データセットの取得が含まれます（MLモデルのトレーニングには信頼できるデータセットの調達が不可欠であり、また最先端のアルゴリズムや生成AI ツールの導入でイノベーションが促進されます）。こうしたことにより、事業に必要な機能の開発が加速されます。調達戦略では、持続可能で、拡張的で、責任あるAI を統合していくために、倫理的配慮、データセキュリティ、継続的なベンダーサポートを優先する必要があります。 10. 人事 AI/ML の人材管理と人材育成について、人事部門（HR）と提携します。技術を理解し、開発し、導入する人材を育成することが含まれます。人事部門は、技術と非技術の橋渡しを行い、横断的な共同を促進すると共に、新たな人材の採用、教育、プロフェッショナルとスキルの両面で成長の道筋をつくります。また、コンプライアンス研修を通じて倫理的な問題に対処し、最新の新興技術について従業員のスキルアップを図り、組織の持続的な成功を支える重要な役割における人材の影響を適切に管理します。 11. 規制とコンプライアンス AI/ML の規制環境は急速に進化しており、世界中の政府がAI のアプリケーションの採用拡大に向けたガバナンス体制の確立を進めています。AI/ML CoE は、ブラジルの一般個人データ保護法（LGPD）、カナダの個人情報保護および電子文書法（PIPEDA）、欧州連合の一般データ保護規則（GDPR）などの規制法や、ISO 31700、ISO 29100、ISO 27701、連邦情報処理標準（FIPS）、NIST プライバシーフレームワークなどの枠組みを常に注意を払い、必要な対応を講じ、順守していく集中的なアプローチが求められます。米国では、 規制措置 として、AI の導入拡大がもたらすリスクの軽減、生成AIの影響を受ける労働者の保護、消費者保護の強化などがあります。 EU AI 法 には、新たな評価およびコンプライアンス要件が含まれています。 AI 規制が具体化する中、組織は責任あるAI を経営層の優先事項と位置付け、AI/ML に関する明確なガバナンスポリシーとプロセスを策定・実施し、意思決定プロセスに多様なステークホルダーを関与させることが推奨されます。進化する規制により、AI/ML ライフサイクル全体をカバーする包括的なAI ガバナンスポリシーと、アルゴリズムにおける偏り、透明性、説明責任を確保するためのAI システムの定期的な監査・レビューが重視されます。標準に則ることで、信頼の向上、リスクの軽減、先端技術の責任ある導入が促進されます。 結論 AI/ML CoE を成功に導く道のりは、多面的な取り組みであり、俊敏性と協調性をもって運営しながら、献身的かつ戦略的な計画を立てる必要があります。人工知能と機械学習が急速なペースで進化し続ける中、AI/ML CoE の設立は、それらの技術を活用して変革のインパクトを生み出すために必要な一歩です。明確なミッションの定義から、イノベーションの促進、倫理的ガバナンスの実施に至るまで、重要な検討事項に焦点を当てることで、AI/ML の取り組みから価値を創出する土台を築くことができます。さらに、AI/ML CoE は単なる技術革新の拠点ではなく、継続的な学習、倫理的責任、部門横断的なコラボレーションの意識を組織に拡げる文化変革の起点ともなります。 このシリーズでは、AI/ML CoE のトピックを引き続き取り扱っていきますので、ご期待ください。AI/ML CoE の設立をご検討の際は、 スペシャリストにご相談 ください。 著者について Ankush Chauhan は、米国ニューヨークを拠点とするAWS のカスタマーソリューション担当シニアマネージャーです。Capital Markets のお客さまがクラウド・ジャーニーを最適化し、導入規模を拡大し、クラウドでの構築と発明がもたらす変革的価値を実現できるようサポートしています。また、生成AI を含むAI/ML ジャーニーを実現することにも注力しています。仕事以外では、ランニング、ハイキング、サッカー観戦を楽しんでいます。 Ava Kong は、AWS Generative AI Innovation Center の生成AI ストラテジストで、金融サービス分野を専門としています。ニューヨークを拠点に、様々な金融機関と緊密に連携し、最新の生成AI技術と戦略的洞察を組み合わせて、業務効率の向上、ビジネスアウトカムの促進、AI 技術の広範かつインパクトのあるアプリケーションを実証する様々なユースケースに取り組んでいます。 Vikram Elango は、米国バージニア州を拠点とするAWS のシニアAI/ML スペシャリスト・ソリューション・アーキテクトです。現在、生成AI、LLM、プロンプトエンジニアリング、大規模モデルの推論最適化、ML の企業全体への拡張に注力しています。大規模な機械学習アプリケーションの構築と導入のための設計と構想のリーダーシップで、金融・保険業界の顧客を支援しています。余暇は、家族と旅行、ハイキング、料理、キャンプを楽しんでいます。 Rifat Jafre en は、AWS Generative AI Innovation Center の生成AI ストラテジストで、生成AI を活用することで顧客が事業価値と業務効率を実現できるよう支援することに注力しています。彼女は、通信、金融、ヘルスケア、エネルギーなどの業界の多くの顧客に、機械学習のワークロードをオンボードしています。また、MLOps、FMOps、責任あるAI にも深く関わっています。 Arslan Hussain、David Ping、Jarred Graber、Raghvender Arni の支援、専門知識、指導に感謝しています。 翻訳者について 川口 賢太郎 (Kentaro Kawaguchi) は、プロフェッショナルサービスのシニアCS&Oアドバイザリーコンサルタントで、デジタル戦略立案とそれに即した組織の変革に注力しています。

本稿は、2021年7月8日に Networking & Content Delivery で公開された “ Best practices for deploying Gateway Load Balancer ”を翻訳したものです。 はじめに re:Invent 2020 では、サードパーティの仮想アプライアンスのデプロイ、スケーリング、可用性の管理を簡単かつ費用対効果の高い方法で行うことができるサービスである　 Gateway Load Balancer（GWLB） の一般提供を開始しました。これらのアプライアンスには、 クラウド内のファイアウォール （FW）、 侵入検知および防止システム（IDS / IPS） 、ディープパケットインスペクションシステムが含まれます。発売以来、多くのお客様が　 AWSパートナー のファイアウォールを備えた GWLB を実稼働環境に導入してきました。このブログ記事では、GWLB を導入する際に考慮すべきベストプラクティスとして、最も一般的に使用される設計パターンと最適な構成設定に焦点を当てます。 長期間持続する TCP フローをサポートするために、TCP キープアライブまたはタイムアウト値を調整する 内部 VPC でのトラフィック検査のフロー対称性を維持するために、 AWS Transit Gateway で Appliance Mode を有効にする Cross-Zone Load Balancing（クロスゾーン負荷分散）を使用するタイミングを理解する アプライアンスと AZ の障害シナリオを理解する アウトバウンドトラフィック検査で、ワンアーム（*1）またはツーアーム（*2）のファイアウォールデプロイモードを選択する SSL/TLS トラフィック検査で、ワンアームまたはツーアームのファイアウォールデプロイモードを選択する *1 ワンアーム（One-Arm）は、アプライアンスを通信を仲介する機器に対して横付けに配置する構成を指します。 *2 ツーアーム（Two-Arm）は、アプライアンスを通信経路中に配置する構成を指します。 1. 長期間持続する TCP フローをサポートするために、TCP キープアライブまたはタイムアウト値を調整する 一部のアプリケーションや API リクエスト(データベースへの同期 API コールなど)には、長い非アクティブ期間があります。GWLB は TCP フローに対して350秒、非TCPフローに対して 120 秒の固定アイドルタイムアウトを設定しています。アイドルタイムアウトに達するか、フローの TCP 接続が閉じられると、そのフローは GWLB の接続状態テーブルから削除されます。これにより、クライアント側でフローがタイムアウトする可能性があります。既に終了したフローに対する後続の UDP パケットは、別の健全なファイアウォールインスタンスに送信される場合があります。削除されたフローに対する後続の非 SYNTCP パケットは、GWLB によりドロップされる可能性があります。以前と同じ5つのタプル(送信元/宛先IP、送信元/宛先ポート、プロトコル)を使用した新しい TCP 接続リクエストでも、以前とは異なるターゲットにルーティングされる可能性があります。一部のファイアウォールのデフォルトタイムアウトは 3600 秒(1 時間)です。この場合、GWLB のアイドルタイムアウトはファイアウォールのタイムアウト値よりも低くなり、ファイアウォールやクライアントに気づかれずに GWLB がフローを削除してしまいます。 これを防ぐには、下の図 1 に示すように、クライアント/サーバーのアプリケーション/オペレーティングシステム (OS) のいずれかで TCP キープアライブ設定を 350 秒未満に設定するか、ファイアウォールのタイムアウト設定を TCP フローでは 350 秒未満、非 TCP フローでは 120 秒未満に設定することをお勧めします。これにより、何も操作が行われなかったり、ファイアウォールが GWLB の前にセッションを削除したりしても、クライアント/サーバーはフローを維持できます。 図 1: クライアント/サーバー (アプリケーションまたは OS レベル) またはファイアウォールでキープアライブ値とタイムアウト値をそれぞれ設定する 例えば、Linux ディストリビューションでは、TCP キープアライブ設定の主要なパラメーターは tcp_keepalive_time です。これはクライアントまたはサーバーの OS レベルで変更できます。これは TCP キープアライブが送信されるまでの TCP 接続のアイドル時間を表します。 tcp_keepalive_time 間隔を次のように短縮する必要があります。 net.ipv4.tcp_keepalive_time = 60 #(or a value less than 350 seconds) Bash また、UDP などの非 TCP フローの場合、接続状態に関連するタイマーは通常アプリケーションレベルで実装されます。これは、オペレーティングシステムには通常、UDP プロトコル用の特定のタイマー設定がないためです。 2. 内部VPCでのトラフィック検査のフロー対称性を維持するために、AWS Transit Gateway で Appliance Mode を有効にする このベストプラクティスは、AWS Transit Gateway の GWLB のデプロイに適用されます。ディープパケットインスペクション用のステートフルファイアウォールを備えたアプライアンス VPC（インスペクション VPC、セキュリティ VPC、またはShared Services VPC とも呼ばれる）を介した VPC 間通信を有効にするには、お客様は Transit Gateway で Appliance Mode 機能を有効にする必要があります。 その理由は次のとおりです。下の図 2a に示すように、2 つの EC2 インスタンスが 2 つの異なる AZ の 2 つの異なる VPC にデプロイされているとします。インスタンスが AWS Transit Gateway を介して同じ AZ にない VPC アタッチメントを使用して相互に通信しようとすると、パケットのルーティングが非対称になります。同じ 2 つの通信ノードからのフォワードフローとリバースフローが 2 つの異なる AZ にある 2 つの異なるファイアウォールインスタンスに送信され、トラフィックが中断されます。これは、デフォルトでは、トラフィックが VPC アタッチメント間でルーティングされる場合、AWS Transit Gateway はトラフィックが宛先に到達するまで送信元と同じ AZ にトラフィックを保持するためです。 図 2a: アプライアンス VPC アタッチメントで Transit Gateway Appliance Modeが無効になっている場合の非対称トラフィックフロー (デフォルト動作) この問題を解決するために、AWS Transit Gateway に「Appliance Mode」機能が追加されました。下の図 2b に示すように、この機能により VPC アタッチメント間の対称的な双方向トラフィック転送が保証されます。つまり、フォワードフローとリバースフローは、そのフローの持続期間中、同じ AZ の同じファイアウォールインスタンスに送信されます。これにより、ファイアウォールは特定のフローの双方向を認識できるため、Appliance VPC 内のステートフルトラフィック検査機能が維持されます。 Appliance Mode の詳細については、 ドキュメント または このブログ投稿 をご覧ください。フローの安定性を確保するには、アプライアンス VPC に AWS Transit Gateway を 1 つだけ接続する必要があることに注意してください。AWS Transit Gateway はフロー状態情報を互いに共有しないため、複数の AWS Transit Gateway を 1 つのアプライアンス VPC に接続しても、フローの安定性は保証されません。 図 2b: アプライアンス VPC アタッチメントで Transit Gateway Appliance Mode が有効になっている場合の対称トラフィックフロー 特定のユースケース、たとえば下の図 2c に示すように、専用の集中型 Internet Egress Appliance VPC を使用したデプロイでは、VPC アタッチメント間の双方向のトラフィック転送は行われないため、Appliance Mode の有効化は任意です。ただし、Spoke VPC からの特定の AZ のワークロードが他のワークロードよりも多くの下りトラフィックを生成している場合は、それぞれの AZ のファイアウォールが飽和状態になっている可能性があります。トラフィックを両方の AZ のファイアウォールに均等に分散するには、アプライアンス VPC に接続された VPC アタッチメントで Appliance Mode を有効にします。 図 2c: 専用のInternet Egress アプライアンス VPC で Appliance Mode が無効 (デフォルト動作) 要約すると、Appliance Mode は AWS Transit Gateway の VPC アタッチメントではデフォルトで無効になっています。アプライアンス VPC 経由の VPC-to-VPC トラフィック検査では、アプライアンス VPC に接続された VPC アタッチメントで Appliance Mode を有効にする必要があります。ただし、専用の Egress VPC 経由でインターネット宛ての Spoke VPC から発信されるトラフィックを検査する場合、Appliance Mode の有効化は任意です。いずれの場合も、Appliance Mode を有効にすると、AWS Transit Gateway は AZ アフィニティ(*3)を維持しなくなり、トラフィックが AZ を通過できるようになります。 AWS データ転送料金の引き下げに関する 2022 年 4 月の発表 により、このシナリオでは AZ 間のデータ転送料金は発生しません。 *3: AWSリソースが特定のアベイラビリティーゾーン(AZ)に固定されること 3. Cross-Zone Load Balancing（クロスゾーン負荷分散） を使用するタイミングを理解する デフォルトでは、ロードバランサーは同じ AZ 内の登録済みアプライアンスにトラフィックを均等に分散します。この構成では、お客様は通常、ファイアウォールサービスの可用性とトラフィックの分散のために、GWLB の背後にある 1 つの AZ 内に複数のターゲットを登録します。1 台のターゲットアプライアンスがヘルスチェックに失敗した場合、GWLB は同じ AZ 内の他の正常なインスタンスにトラフィックをルーティングします。これにより、トラフィックが AZ 境界を越えないため、費用対効果の高いソリューションとなります。このセットアップは費用対効果が高くなりますが、特定の AZ 内のすべてのターゲットに障害が発生した場合、顧客は高可用性とトラフィック分散の両方の側面を失います。 高可用性とバランスのとれたトラフィック分散を実現するために、「クロスゾーン負荷分散」と呼ばれる機能を有効にする別のアプローチを選択するお客様もいます（下の図3 を参照）。この機能により、複数の AZ にまたがるアプリケーションのデプロイと管理が容易になります。クロスゾーン負荷分散を有効にすると、GWLB は、ターゲットがどの AZ にあるかに関係なく、登録されている正常なターゲットすべてにトラフィックを分散します。クロスゾーン負荷分散を有効にすると、トラフィックが AZ を通過するときに標準の AZ 間料金が発生します。 図 3: クロスゾーン負荷分散が有効 (デフォルトでは無効) の場合にフローがどのように分散されるかを示す、GWLB を使用したファイアウォールの典型的なデプロイ構成 4. アプライアンスと AZ の障害シナリオを理解する ファイアウォールサービスの可用性は、ファイアウォール障害と AZ 障害の 2 つのイベントによって影響を受ける可能性があります。他の AWS ロードバランサー ( Classic Load Balancer(CLB) 、 Application Load balancer(ALB) 、 Network Load Balancer(NLB) ) と同様に、GWLB は VPC で実行されるリージョンサービスであり、AZ 障害に対して回復力があります。ただし、GWLB エンドポイントは AZ リソースであるため、お客様は複数の AZ に GWLBエンドポイント を作成する必要があります (GWLBE として示されている上記の図 3 を参照)。また、他のロードバランサーとは異なり、このような障害イベントが発生した場合、GWLB はフロー管理の点で異なる動作をします（概要については以下の表1を参照してください）。 既存のフロー ターゲットに障害が発生すると、ALB や NLB などのロードバランサーは既存のフロー/セッションを終了し、リセットシグナルを送信します。ただし、GWLB は透過的なサービスであるため、フェイルオープンモード(*4)で動作します。つまり、本質的にステートフルな既存のフローは、タイムアウトするかクライアントによってリセットされるまで、障害が発生したターゲットに関連付けられ続けるということです。詳細は、 既存フローの AWS Gateway ロードバランサーのターゲットフェイルオーバー機能 の最近の機能強化を参照してみてください。 *4: ネットワークデバイスが故障した場合に、トラフィックをブロックせずに通過させる動作モードを指します。 新しいフロー ヘルスチェックの設定（間隔としきい値）に基づいて、ターゲットに異常のフラグが立てられると、GWLB は新しいフローを正常なターゲットに再ルーティングするまでに最大 50〜60 秒の遅延を追加します。新しいフローの再ルーティングを開始する最小時間は最大70秒です。これは、ヘルスチェックの 20 秒(最小間隔: 10 秒、最小しきい値: 2)と GWLB バックエンドが検出して再ルーティングするための 50 秒の合計です。 障害シナリオ クロスゾーン負荷分散 既存のフロー 新しいフロー AZ で 1 つの FW に障害が発生 無効 タイムアウトまたはクライアントからのリセットが必要 同じ AZ 内の正常なターゲットに送信 AZ で 1 つの FW に障害が発生 有効 タイムアウトまたはクライアントからのリセットが必要 同じ AZ または複数の AZ 内の正常なターゲットに送信 AZ ですべての FW に障害が発生 無効 少なくとも 1 つのターゲットが復元されるまでタイムアウトまたはドロップ 少なくとも 1 つのターゲットが復元されるまでタイムアウトまたはドロップ AZ ですべての FW に障害が発生 有効 タイムアウトまたはクライアントからのリセットが必要 AZ 全体の正常なターゲットに送信 AWS リージョンで 1 つの AZ に障害が発生 無効 / 有効 他の AZ を通過するフローは影響を受けません 他の AZ を通過するフローは影響を受けません 表 1: 上の表は、GWLB の既存のフローと新しいフローに関するさまざまな障害シナリオをまとめたものです 既存のフローまたは新しいフローに対する障害イベントの全体的な影響は、それらのフローを処理するファイアウォールインスタンスの数によって異なります。たとえば、10 のファイアウォールが稼働していて、1 つのファイアウォールがダウンすると、最大 70 秒以内にフローの 10 % に影響が及びます。 5. アウトバウンドトラフィック検査で、ワンアームまたはツーアームのファイアウォールデプロイモードを選択する GWLB は、ファイアウォール導入の 2 つの異なるモデルをサポートしています（下の図 5a と 5b を参照）。ワンアームとツーアーム（ファイアウォールがNATも実行可能）です。 ワンアームモード :下の図 5a に示すように、ファイアウォールはトラフィック検査のためだけにワンアームモードで展開され、NAT ゲートウェイは変換を行います。これは最も一般的な導入方法であり、NAT 機能をサポートするファイアウォールへの依存を排除します。また、NAT を NAT Gateway にオフロードすることで、ファイアウォールのパフォーマンスを向上させます。 図 5a: ワンアームファイアウォールの導入 — NAT Gateway が変換を実行している間、ファイアウォールはトラフィック検査専用です。 ツーアームモード :下の図 5b に示すように、ファイアウォールはツーアームモードで導入され、検査と NAT の両方を実行します。一部の AWS パートナーは、ファイアウォールに NAT 機能を提供しています。GWLB はこのような導入モードでシームレスに統合されます。GWLB で追加の構成変更を行う必要はありません。ただし、ファイアウォールネットワークは異なります。一方のネットワークインターフェースはプライベートサブネット上にあり、もう一方はパブリックサブネット上にあります。このモードには、ファイアウォールパートナーからのソフトウェアサポートが必要です。一部の GWLB パートナー（ Palo Alto Networks 、 Valtix ）はこの機能をサポートしていますが、このモードを使用する前に、選択した AWS パートナーに相談してください。 図　5b: 2アームの FW 展開 — ファイアウォール (ツーアームモード) は検査と変換の両方を実行します。 6.SSL/TLS トラフィック検査で、ワンアームまたはツーアームのファイアウォールデプロイモードを選択する GWLB は、トラフィックが暗号化されているかどうかに関係なく、透過的なサービスとして機能します。GWLB は TLS フローを終了したり、SSL オフロードを実行したりしません。代わりに、ファイアウォールで復号化とディープパケットインスペクションを実行する必要があります。このユースケースでも、GWLB は 2 つの異なるファイアウォール導入モードをサポートしています（下の図 6a と 6b を参照）。 ワンアームモード :下の図 6a に示すように、ファイアウォールはワンアームモードで展開され、GWLB は暗号化されたトラフィックを通過します。パケットインスペクションプロセス中、ファイアウォールは元の 5 タプル（送信元/宛先 IP、送信元/宛先ポート、プロトコル）を変更せずに復号化して再暗号化します。 図 6a: ファイアウォールは、ワンアームモードで、トラフィックをインターネットに送信する前に復号化して再暗号化します。その逆も同様です。 ツーアームモード :下の図 6b に示すように、ファイアウォールはツーアームモードで展開されます。トラフィックは暗号化されたファイアウォールに入り、インターネットに送信される前に復号化および検査されます。その逆も同様です。このモードでは、ファイアウォールの 2 つのアームにある 2 つのフローのうちの 5 タプルが一致する必要はありません。この機能をサポートする GWLB パートナーには、 Check Point 、 Palo Alto Networks 、 Trend Micro などがあります。 ただし、このモードを使用する前に、選択した AWS パートナーに相談してください。 図 6b: 2 アームモードのファイアウォールは、トラフィックをインターネットに送信する前に復号化および暗号化を行います。その逆も同様です。 まとめ この投稿では、サードパーティの仮想アプライアンスをより堅牢で、回復力があり、スケーラブルな方法でネットワークアーキテクチャに設計およびデプロイするのに役立つ、Gateway Load Balancer のベストプラクティスについて説明しました。Gateway Load Balancer を今すぐ開始するには、 このページ にアクセスしてください。 Gateway Load Balancer の詳細については、以下のブログを参照してください。 Gateway Load Balancer のデプロイパターン Gateway Load Balancerと AWS Transit Gateway による集中型検査アーキテクチャ Gateway Load Balancer を使用したネットワークトラフィック検査のスケーリング この投稿に関するフィードバックや質問がある場合は、 Amazon Elastic Compute Cloud(EC2) フォーラムで新しいスレッドを開始するか 、 AWS サポート にお問い合わせください。 この記事の翻訳はソリューションアーキテクトの長屋が担当しました。原文は こちら です。

クラウドコンピューティングの基本について学びたいと思ってはいるものの、何から手を付ければよいのか分からない。という方はいらっしゃいませんか？そのような方には、AWS 認定の中でも Foundational カテゴリ（基礎レベル）に分類される AWS Certified Cloud Practitioner (CLF: 以下、クラウドプラクティショナー) 認定の取得がお勧めです。AWS の認定資格なのだから、AWS を利用する人にしか関係ないのでは？と思われるかもしれませんが、実はそうではありません。この認定は、クラウドコンピューティングの基本的な概念を学ぶのにもご活用いただけます。 クラウドに関する知識の重要性 クラウドプラクティショナー認定の概要をご紹介する前に、クラウドコンピューティングへの注目の高まりについて確認してみましょう。 独立行政法人情報処理推進機構（IPA）が発行した『 DX 白書 2023 』によると、IT システムの開発技術としてパブリッククラウドを活用している・活用を検討していると回答した企業の割合は、合わせて 51.5% となっています（図表 5-22）。これは、SaaS（56.5%）やアジャイル開発（41.5%）などとともに活用の割合の高い開発技術となっています。また、第 5 部の第 2 章 2 節において、クラウド導入を進めるためには、まずは社内で方針をまとめて合意をとり、クラウドを利用する側（ビジネス部門）にも特定のスキルが求められることが説明されています。 これらから、DX を推進していく中で、クラウドというコンセプトは非常に身近な存在になっていくと言えます。また、IT 部門だけではなく、ビジネス部門も含めてクラウドを理解し、合意を得ながら活用を進める必要があります。そのため、クラウドに関する知識は、経営層なども含めた非技術者の方にも一般教養として求められ、DX の推進に伴ってその重要性も高まっていくでしょう。 Foundational カテゴリのクラウドプラクティショナー認定 それでは、クラウドに関する知識を学ぶにはどうすればよいでしょうか。 そのような方には、Foundational カテゴリ（基礎レベル）の AWS 認定がお勧めです。AWS 認定は複数のカテゴリに分かれているのですが、そのうち Foundational カテゴリは、AWS クラウドに関する事前の経験は不要であり、AWS やクラウドそのものの基本的な理解を問う知識ベースの認定となっています。そして、現在 Foundational カテゴリとして提供されている AWS 認定が、クラウドプラクティショナー認定です。 参照 : https://aws.amazon.com/jp/certification/ このような認定資格では、対象となる技術領域に関する知識が広く問われ、学習コンテンツも充実しているので、短期間で体系的に知識を習得できます。もちろん、実業務ではこれらの知識に加えて実践形式でも学びを深めていく必要がありますが、まずは一般教養としてクラウドのコンセプトを理解し、クラウド活用のスタート地点に立ちたい場合は、目標が明確で学習コンテンツが豊富な認定資格の取得は有力な選択肢となります。そして、AWS クラウドの事前の経験が不要で、AWS やクラウドの基本が学べるクラウドプラクティショナー認定は、クラウド未経験者を含むあらゆる方にお勧めです。 クラウドプラクティショナー認定の概要 それでは、クラウドプラクティショナー認定の概要について、 試験ガイド の内容を確認していきましょう。 まず、「受験対象者について」を見てみると、AWS クラウドの経験が 0~6 ヶ月までで、IT 以外のバックグラウンドを持つ方も対象としていることがわかります。そして、受験までに推奨される AWS の知識としては、AWS クラウドのコンセプトやセキュリティ、コンプライアンス、コスト、そして主要な AWS サービスが挙げられています。また、範囲外のトピックとしては、システムの設計や実装、トラブルシューティングなどが挙げられています。これらのことから、IT システムの設計や実装に関わる具体的な知識・経験が問われるというよりは、そもそものコンセプトやセキュリティ、コストの考え方が中心に問われることが読み取れます。これが Foundational カテゴリの特徴です。 続いて、「試験内容」について見てみると、選択形式の問題が 65 問出題されることがわかります。そして、大切なのは、その後に記載されている試験範囲とその割合です。本ブログの執筆時点では以下のようになっています（括弧内は出題割合）。 第 1 分野：クラウドのコンセプト（24％） 第 2 分野：セキュリティとコンプライアンス（30％） 第 3 分野：クラウドテクノロジーとサービス（34％） 第 4 分野：請求、料金、およびサポート（12％） ここから、技術面に主にフォーカスがあてられているのが第 3 分野のみで、その出題割合は 34％ となっていることが読み取れます。言い換えると、もちろん AWS に関連した出題というところは変わらないのですが、残りの 66% はクラウドのコンセプトやセキュリティ、コストといったトピックに主にフォーカスがあてられた出題となるということです。 もう少し詳細に出題範囲を確認してみると、第 1 分野では、AWS クラウドの利点や設計原則などに関する知識が問われます。これに正解するには、そもそもクラウドとは何か、を理解している必要があるでしょう。第 2 分野では、AWS におけるセキュリティやコンプライアンスといったコンセプトや、セキュリティに関する AWS サービスの概要が問われます。セキュリティやコンプライアンスの考え方は、AWS に限らずクラウド全般に適用できる部分も多いでしょう。第 3 分野は AWS 特有の知識について問われる部分が多いですが、代表的な AWS サービスの名前と概要を把握することは、特にこれから AWS を活用する予定がある方にとっては有益なものとなるでしょう。そして、最後の第 4 分野では、コストや請求、見積もりの考え方、ドキュメントや AWS サポートといったリソースについて問われます。こちらも第 2 分野と同様に、AWS に限らずクラウド全般に適用できる知識を多く得られることでしょう。 AWS でしか通用しないような、AWS 特有の設問ばかりというわけではなさそうだな。というイメージを持っていただけましたでしょうか。 クラウドプラクティショナー認定に向けた学習コンテンツ 最後に、クラウドの基礎や AWS の基礎を学ぶために AWS が公開している無料の学習コンテンツをいくつかご紹介します。 AWS 基礎（動画・テキスト形式の学習コンテンツ） 今からでも大丈夫！基礎から学ぶ AWS 入門 （約 30 分） Cloud for Beginners （約 3 時間） AWS Cloud Practitioner Essentials （約 7 時間） クラウドプラクティショナー認定の受験準備 Exam Prep Standard Course: AWS Certified Cloud Practitioner （4.5 時間の受験準備動画） AWS Certified Cloud Practitioner Official Practice Question Set （20 問の練習問題） 学習コンテンツに関してはこの他にも多数ありますので、ぜひご自身に合ったものを探してみていただければと思います。また、今後の業務での AWS 活用を見据えて、実際に AWS 環境をハンズオン形式で触りながら学習を進めたいという方には、AWS Cloud Quest という学習コンテンツがお勧めです。こちらについては 紹介記事 が公開されておりますので、ご興味をお持ちの方はそちらもご一読ください。 本ブログでは、今後、あらゆる方にとってクラウドのコンセプトを理解しておくことが重要になっていくことをお話しし、効率的に体系的な知識を得るための手段として、AWS 認定の Foundational カテゴリをご紹介しました。その後、当該カテゴリであるクラウドプラクティショナー認定について、その概要と試験範囲について確認し、最後に AWS で公開している無料の学習コンテンツをご紹介しました。この記事をお読みいただいた方がひとりでも、AWS 認定の Foundational カテゴリでは AWS だけでなくクラウド全般の知識を習得できるんだな、であれば自分もチャレンジしてみようかな。と思っていただければ幸いです。 本ブログは、Sr. Technical Instructor の生出が執筆し、Certification BDM の両角が監修しました。

こんにちは、元メーカー出身の Prototyping Engineer の鈴木です。 このページを開いていただいたみなさんは、きっと何らかの形で製造業に携わっていらっしゃると思います。 ものづくり白書2023 では、技能伝承に課題があることについて触れられていますが、みなさんの周りではいかがでしょうか。生成 AI はこの大きな課題を解決する可能性を秘めています。 この記事では、 AWS Summit Japan の製造業ブース内で展示される、プロセス製造業向け生成 AI のデモについてご紹介します。このデモはプロセス製造業を想定していますが、技能伝承は業態を問わない共通の課題のため、ぜひ多くの製造業に携わる方にこの記事を読んでいただき、また実際に AWS Summit Japan の会場まで足を運んでいただければ幸いです。 2024 年 6 月 20 日（木）、21 日（金）の 2 日間、幕張メッセ で開催されますので、ご登録がまだの方はぜひ こちらのページ にアクセスしご登録ください。 ベテラン技術者のKKDと生成 AI  ベテラン技術者の KKD（経験・勘・度胸）は、長年の実践から培われた高度な技能であり、製造現場の安定運用や高い生産性を実現する上で欠かすことができません。一方で近年は製造業就労人口の低下やベテラン技術者の退職により、その貴重なノウハウは失われつつあります。そんな中、生成 AI の登場により技能伝承の新たな可能性が見えてきました。 生成 AI は自然言語処理技術を活用し、大量のテキストデータを学習することで、人間のような対話や文章生成を可能にします。これにより、ベテラン技術者の知見を AI に参照させ、次世代の技術者育成や技能伝承に活用できるのではないかと期待されています。具体的には RAG と呼ばれる方法により、過去の生産記録やアラート対応記録などのレポートを検索・参照することで、期待される回答を AI に生成させることが可能です。 しかし、過去のレポートや文献には明示されていない現場のノウハウも多く存在するでしょう。トラブル発生時など、ベテラン技術者に直接聞いて、解決の参考にしたい場合も多くあると考えられます。 そこで重要になるのが、Human in the loop の考え方です。つまり、ベテラン技術者をループに組み込み、AI による技能伝承をサポートしてもらうのです（図１）。 図１: ベテラン技術者と生成 AI の協調によるノウハウ伝承 オペレータは現場から発報されたアラートを確認する。 オペレータは生成AIチャットボットに問い合わせする。チャットボットは過去のレポートを元に原因・対処方法と、推奨される現場への確認アクションを応答する。 オペレータは現地エンジニアにリモート通話で、AI から生成された応答を基に状況確認を依頼する。 現地エンジニアは実際の状況を確認後、対応作業を行う。もし原因究明や解決が困難な場合は、別途ベテラン技術者に通話に入っていただく。 対処が完了した場合、原因や対処法などをレポートに記載し保存する。 このような対応を繰り返すことで過去の対応履歴にベテランのノウハウが蓄積されていき、ベテラン技術者が退職された後においてもその知見をうまく活用することができるようになるでしょう。今回のデモでは、AWS のサービスを組み合わせることによって図１のしくみを実現します。 デモ このデモではミニチュアプラントを利用して、異常を擬似的に発生させます。実際に動作している様子は AWS Summit Japan 当日のブースにてご覧いただけます。 図２: ミニチュアプラント ミニチュアサイズですが、流量計や液面計（フロートスイッチ）、圧力計などを設置し、制御ループを組んで実際に計装しています。 図３: 流量計 図４: 液面計（フロートスイッチ） オペレータは過去のアラート事例について、生成 AI にチャット形式で相談することができます。ここでは原因と過去の対応策をもとに、生成 AI が現場オペレータへの確認事項を提案してくれています。このデモアプリでは、エラーコード（画像の例ではF060）を入力するだけで、原因や対策を出力してくれるように調整しています。 図５: 生成 AI チャット画面 AIチャットで解決できない場合や現場の状況確認が必要な場合、オペレータはすぐに現地エンジニアやベテラン技術者とリモートでビデオ通話を開始することができます。制御ループの設定値の変更やバルブ開閉など、実際に行った対応をコメントとして記録に残すことが可能です。この対応記録は、次回以降のアラート原因究明の際に AI が参照するデータソースとして利用されます。 図６: ビデオ通話画面 まとめ AWS Summit Japan の製造業ブースでは、生成 AI を活用したプロセス製造業向け技能伝承のデモを展示します。ミニチュアプラントを使用した実際の動作する様子や、技術的な内容について知りたい方は、ぜひ会場までお越しください。みなさまのご登録・ご来場をお待ちしています！ セッション・イベント登録はこちら 著者について 鈴木 毅洋 アマゾン ウェブ サービス ジャパン合同会社 Prototyping Engineer 計装メーカー R&D 部門、化学メーカー DX 部門を経て AWS Japan に入社。現在は AWS を用いてお客様と共にプロトタイピングの構築を支援しています。

セキュリティは私たちにとっての最優先事項であり、お客様にとっても重要な関心事となります。一方、セキュリティのコントロール（管理策）が妥当性をもって評価されなければ、不要な管理策の導入や、ビジネスの進展の妨げとなる場合もあります。本Blogでは、医療のビッグデータ活用をうながす 「医療分野の研究開発に資するための匿名加工医療情報に関する法律（次世代医療基盤法）」 の認定を参考として、セキュリティ責任共有モデルに基づく、管理策の在り方をお伝えいたします。 次世代医療基盤法の概要と認定事業者の責務 次世代医療基盤法は、健診結果やカルテ等の個々人の医療情報をプライバシーを配慮するための加工（匿名加工や仮名加工）を施すことで医療分野の研究開発での活用を促進し、医療情報の第三者提供に際して、あらかじめ同意を求める個人情報保護法の特例法です。こうした法律は医療情報をビッグデータとして有効活用することで医療分野のイノベーションを促進することと、その中で扱われる医療情報を安全に取り扱うということの両立をはかるものであり、より大きな社会的な責任をともなうことから加工を施す事業者（匿名加工医療情報作成事業者や仮名加工情報作成事業者。認定事業者といいます）がその責任を果たすための様々な要件、また事業者の認定を制度として位置づけています。こうした事業への認定を考えるお客様に対して、 「医療分野の研究開発に資するための 匿名加工医療情報及び仮名加工医療情報 に関する法律についてのガイドライン （次世代医療基盤法ガイドライン）」 が提供されており、求められているセキュリティ要件や考慮すべき事項が解説されています。 認定事業者の皆様がこうした事業を実際のシステム設計を踏まえて考えた場合、クラウドの価値を最大化することでより効果的かつ効率的なサービスを実現できる可能性があります。処理を行うデータの量にあわせてコンピューティングリソースを柔軟に拡張、伸縮するスケーラビリティの確保、また、データが投入されたイベントをきっかけとして加工処理を実施するといったサーバレスアーキテクチャの採用によってコスト効率を高めたシステムを設計することもできるかもしれません。 しかし一方で求められる様々なセキュリティ要件を評価する場合には、物理的な設備に対する要件も考慮すべき必要があります。例えば次世代医療基盤法では実地確認として認定における管理策の実施状況の評価を求めています。一方、クラウドを利用する場合、AWSのような事業者は実際に認定の対象となる事業者ではなく、また、AWS のデータセンターは複数の顧客をホストしているため、サードパーティーの物理的アクセスに幅広い顧客がさらされることになるため、顧客によるデータセンターのツアーは許可していません。 AWSの利用者である認定事業者の皆様はどのように評価すべきなのでしょうか。 第三者評価の活用とクラウドのインフラストラクチャ 次世代医療基盤法ガイドラインではすべてにおいて実地確認をもとめるものではなく、適切な要件の充足性が確認できる場合であれば実地確認に代えて書類確認のみを実施する場合もあることを規定しています。特に、クラウドサービスの利用に関して、”３省２ガイドラインに準拠し得ることが担保されているクラウドサービスを活用することも可能”であること、また、”当該クラウドサービスが「ISMAPクラウドサービスリスト」に登録されている場合には、主務府省においては、当該登録の状況も勘案した上で必要な確認”であることとしています。 AWSはISMAPの制度設立当初からISMAPの登録を維持しており、 IPAのISMAPポータルからその内容を確認 することができます。また、日本の医療情報ガイドラインのページでは、お客様の準拠を助けるための情報発信や AWSのパートナー各社による医療情報システム向け AWS 利用リファレンス のご紹介を行っています。 管理目的に注目して管理策を理解することの重要性 一方、こうしたセキュリティの要件を考える場合、本ガイドラインのようなクラウドの特性に応じた考え方などが示されていない場合もあります。まだまだ多くの規制要件やお客様の組織内のセキュリティポリシー等が技術の進歩にあわせた適切なアップデートが行われていない、という実情もあります。このような場合、管理策というのは何らかの目的を実現するための手段であることに着目する必要があります。例えばISO/IEC27001においても、定義されている詳細管理策は管理目的を実現するために組織がリスクアセスメントの結果として採用する選択肢です。もしも組織の実情にあわせた詳細管理策がなければ自ら詳細管理策を定義することも可能です。（実際にはなかなかそこまでの管理をする事業者は少ないと思いますが） 組織が具体的なコントロールを必要とするのは、何らかの達成したい目的があるためであり、目的を達成するための手段は対象となるシステムやサービス、組織のニーズや成熟度、適用しようとするテクノロジーによって異なる場合があります。健全にガバナンスを組織に根付かせるためには、管理目的にそった合理的な管理策を導入することや、逆に実情にあわない非合理な管理策を見直すプロセスを運用していくことになります。 AWSが提唱している Well Architected Framework では、原則中心のアプローチを提唱しています。これは一つ一つの管理策に過度に注目する前に、そもそも組織が何を実現したいか、という目的にフォーカスしたうえでリスクマネジメントを行うステップです。 Auditability（可監査性）と管理策の担い手 さらに、もう一つの観点として、実際にその管理策や評価を実施することが妥当なのか、有効なのか、ということにも着目する必要があります。監査の言葉に可監査性、という言葉があります。これは、情報システムが処理の正当性や内部統制を効果的に評価できる状態である、例えばログ等によりそのシステムを適切に評価できることを表します。一方、監査実務を考えると監査手続きを実施してもそれが本来求める管理目的に対しての妥当性を評価できない、というケースもあり得ます。次世代医療基盤法で考えれば、物理設備を評価する目的は、その設備や区域から情報への不正なアクセスが行われることへのリスクを評価することにあります。例えば以前にBlogでご紹介しましたが、 AWSのNitro Systemでは、AWSの従業員によるお客様コンテンツへのアクセスを仮想化基盤のレベルで制御 しています。さらには、お客様は、 AWS上のコンテンツを暗号化することが可能であり、お客様がそのような統制を実現することを支援 しています。仮想化基盤を管理するAWSの責任範囲と、仮想化基盤上にお客様のコンテンツ、ネットワーク空間、サーバインスタンスなどの情報資産を管理するお客様の責任範囲は分離されており、お客様は自らが管理目的を満たすための管理策の担い手となることができます。つまり従来の商用データセンターにおけるサーバやネットワークインフラストラクチャの管理業務は、AWSの上ではお客様がマネジメントコンソール上でコントロール可能なお客様固有の空間となります。 そのため、もしもデータへのアクセスや保護を目的として物理設備に対する監査をするならば、実効性の高い監査の計画は、お客様がマネジメントコンソールにアクセスする環境をどのように制限しているか、また、暗号化等の施策を適切に実施しているかに焦点をあてることとなります。 おわりに 本Blogでは、次世代医療基盤法やその中で取り扱われる物理設備の実地確認の要件を踏まえ、第三者の評価のもつ意味や責任共有モデルの紐解き方を再考いたしました。多くのコンプライアンスの議論において形骸化した管理策や監査要件が、現状と乖離していくケースがあります。そういった際は、そもそも何を管理したいのか、そしてその目的を達成することはお客様自らがオーナーシップを持つことができるかを最初に共有していくと、より建設的な議論ができるかもしれません。本Blogが皆様の一助になれば幸いです。 本Blogは以下の二名にて執筆いたしました。 セキュリティアシュアランス本部 本部長 松本照吾 シニアセキュリティソリューションアーキテクト 中島智広

みなさん、こんにちは。ソリューションアーキテクトの根本です。 今週も 週刊AWS をお届けします。 みなさんAWS Builders Online Seriesをご存知でしょうか？初心者を対象とした AWS の基礎を幅広く学ぶことができるオンラインイベントです。 7月18日（木）に「AWS 基礎」「生成 AI」「モダンアプリケーション開発」をテーマとして開催されますが、週刊AWSを執筆する下佐粉もオープニングセッションに登壇します。 もしご都合つけばぜひご参加ください！ イベントページ： https://aws.amazon.com/jp/events/builders-online-series/ それでは、先週の主なアップデートについて振り返っていきましょう。 2024年5月20日週の主要なアップデート 5/20(月) Amazon WorkSpaces Web is now called Amazon WorkSpaces Secure Browser Amazon WorkSpaces Webの名称がAmazon WorkSpaces Secure Browserに変更されました。Amazon WorkSpaces Secure BrowserはプライベートウェブサイトやSaaSウェブアプリケーション、インターネット閲覧などをリモートマシン経由で画面データをストリーミングすることで、ローカル端末にデータを送信せずにセキュアに利用することが可能なサービスです。今回の名称変更によるユーザーやリソースの管理方法の変更はありません。 AWS Resource Explorer now provides filtering on resources that support tags AWS Resource Explorerで新しいフィルターが利用できるようになりました。従来はtag:noneのフィルターを使うことでアカウント内のタグのないリソースを表示できましたが、このクエリは、タグ付けできないリソースを返す場合があります。今回のアップデートでresourcetype.support:tagsを使用して、タグ付け可能なリソースのみを検索することができます。詳細は ドキュメント もご確認ください。 Amazon QuickSight now supports GetClusterCredentialswithIAM for Redshift Data Sources Amazon QuickSightがGetClusterCredentialswithIAMを通じてIAMロールを使用したRedshiftデータソースへの接続をサポートするようになりました。この機能は以前にリリースされた Redshift RunasRole の機能拡張となります。これによりLakeFormationマネージドRedshiftデータ共有機能を使用して、こちらの ブログ で紹介するクロスアカウントのユースケースをサポートできるようになりました。詳細は ドキュメント をご確認ください。 5/21(火) Amazon Lightsail supports easy switching between dual-stack and IPv6-only instance bundles Amazon LightsailでIPv6専用バンドルとIPv4,IPv6をサポートするデュアルスタックバンドルの切り替えが簡単に行えるようになりました。以前はデュアルスタックバンドルからIPv6専用バンドルへの切り替えには新しいインスタンスを起動する必要がありました。今回のアップデートでIPv4アドレスを削除、追加することでこれらの切り替えが可能になりました。この機能は、Lightsailが利用可能なすべてのAWSリージョンのLightsailコンソール、CLIおよびAWS SDKで使用できます。 Amazon OpenSearch Service now supports OpenSearch version 2.13 Amazon OpenSearch ServiceがOpenSearch version 2.13をサポートしました。OpenSearch version 2.13ではパフォーマンス改善のほか、I/O 使用量をプロアクティブに監視してクラスタの耐障害性を高める機能、セマンティック検索などを使いやすくしAIを活用したアプリケーションで使いやすくする仕組みなどが追加されています。アップグレードに関する詳細は ドキュメント をご確認ください。 RDS Performance Insights provides fine grained access control RDS Performance Insightsでパフォーマンスデータに対する細かいアクセス制御が可能になりました。これまでPerformance Insightsのアクセス制御はアクションとリソースのレベルのみ対応していました。今回のアップデートにより”SQL統計の表示は許可するがSQLテキスト全体は表示を許可しない”など、機密性の高いディメンションへのアクセス制御を行うことが可能になります。詳細は ドキュメント をご確認ください。 Amazon Verified Permissions improves support for Cognito tokens Amazon Verified PermissionsでCognito グループに基づいたCedarポリシーを作成できるようになりました。Verified PermissionsはアプリケーションコードではなくオープンソースのCedarを利用して認可を実装できるサービスです。今回のアップデートによりCognitoトークンに基づいて、グループに紐づくCedarポリシーを評価してAPIやリソースへのアクセスさせることが可能になりました。また、レイテンシーとコストを削減するためにBatchisAuthorizedWithToken という新しい APIもサポートされています。これらの機能は、Amazon Verified Permissionsがサポートしているすべての AWS リージョンで利用できます。 Amazon RDS for Db2 introduces hourly licensing from IBM through AWS Marketplace AWS マーケットプレイス経由でAmazon RDS for Db2の時間単位のDb2ライセンスをサブスクライブできるようになりました。これまでRDS for Db2を利用するにはBring-Your-Own-License (BYOL)で既存のライセンスを使用する必要がありましたが、今回のアップデートによりワークロードのピーク制に合わせた柔軟な利用が可能になります。詳細についてはこちらの ブログ もご確認ください。 Amazon OpenSearch Service releases cross cluster alerting monitors Amazon OpenSearch Serviceがクロスクラスターモニタリングをサポートしました。OpenSearchのアラート設定時にはクラスターに定期的にクエリを実行するモニターを設定します。今回のアップデートによりモニターが複数のクラスターにクエリを行えるようになり、一元管理が可能になりました。この機能を含むOpenSearch 2.13 は、Amazon OpenSearch サービスを利用できる世界中のすべてのAWS リージョンで利用可能です。 5/22(水) AWS Lambda console now supports sharing test events between developers in additional regions AWS Lambdaのテストイベントの共有機能が、大阪を含む8つのリージョンで利用可能になりました。今回追加対象のリージョンではこれまで、テストイベントは作成した開発者しか利用できませんでしたが、今回の機能追加によりチームでのより効率的な開発が可能になります。この機能の詳細は ドキュメント もご確認ください。 Amazon SES launches Mail Manager to help manage complex inbound and outbound email workloads Amazon Simple Email Service (SES)にMail Managerの機能が追加されました。SESはメールの送受信をメールサーバの運用不要に簡単に実現できるサービスです。Mail ManagerはSESで企業のメール送受信の管理を一元的に行えるようにする機能で、メールの入力エンドポイント、トラフィックルーティングポリシー、アーカイブ機能など企業のEメール管理に必要な機能を提供します。また、Spamhaus、Abusix、Trend Microと共同で開発したメールセキュリティ機能も提供されます。この機能は東京を含む6つのリージョンで利用可能です。 ブログ も同時に出ているので、ご確認ください。 Amazon Security Lake now supports logs from AWS WAF Amazon Security LakeでAWS WAF ウェブ ACLのログがサポートされました。これにより、Web アプリケーションの潜在的な脅威や不審なアクティビティをより簡単に、一元的に監視および調査できます。Security Lakeが利用可能なリージョンについては こちら をご確認ください。 Amazon OpenSearch Service zero-ETL integration with Amazon S3 now available Amazon OpenSearch ServiceとAmazon S3のzero-ETL統合がGAしました。zero-ETLを使うことでOpenSearch ServiceにデータをコピーすることなくS3に保存されているデータに対して複雑なクエリや可視化を簡単に行うことが可能です。この機能は東京を含む13のリージョンのOpenSearch Service 2.13でGAしています。詳細は ドキュメント をご確認ください。 Amazon Redshift announces Snapshot Isolation as the default for new cluster creates and restores Amazon Redshiftで、新規に作成されるクラスターと、スナップショットからクラスターを復元した際のデフォルト設定がスナップショットアイソレーションに変更になりました。Amazon Redshiftには操作を直列に実行して厳密な正確性を保証する直列化可能分離と、同じテーブルで多くの操作を同時にできるスナップショットアイソレーションの２つの分離レベルをサポートしています。これまで、Provisionedは直列化可能分離、Serverlessはスナップショットアイソレーションとデフォルト設定が異なりましたが、今回これらを同じにすることで製品全体での一貫性を持たせます。もちろんこれまでの直列化可能分離に切り替えも可能です。この設定は、Amazon Redshift が利用可能なすべての AWS リージョンのプロビジョニング済みクラスターでデフォルトで有効になります。分離レベルの詳細は ドキュメント をご確認ください。 Amazon RDS Extended Support APIs are now available Amazon AuroraとAmazon RDSの延長サポート APIの提供を開始しました。自動延長サポートはMySQLとPostgreSQLのデータベースで新しいバージョンにアップグレードするまでの間、コミュニティがメジャーバージョンのサポートを終了したバージョンの重要なセキュリティ修正とバグ修正を提供する機能です。今回のAPIの追加により、この対象の管理をより簡単に、機械的に実施することが可能になります。Amazon RDS 延長サポート APIは、Aurora MySQL 互換バージョン2以上、Aurora PostgreSQL 互換バージョン11以上、RDS for MySQL 5.7以上、RDS for PostgreSQL 11以上でご利用いただけます。 5/23(木) New open-source AWS Advanced Python Wrapper driver now available for Amazon Aurora and Amazon RDS AWS Advanced Python Wrapper driverがAmazon RDSとAmazon AuroraのPostgreSQLおよびMySQL互換エディションでGAしました。このオープンソースのドライバーはPsycopgとMySQL Connector/Python ドライバーをラップしたものです。オープンソースのドライバーと比較して、スイッチオーバーとフェイルオーバーの時間を数十秒から1桁秒に短縮することが可能です。詳細については GitHubのプロジェクト をご確認ください。 5/24(金) Mistral Small foundation model now available in Amazon Bedrock Amazon BedrockでMistral AIのMistral Small 基盤モデルがGAしました。Mistral Small は、大量かつ低遅延の言語ベースのタスクに最適化された、非常に効率的な大規模言語モデルで費用対効果が高いです。詳細についてはこちらの ブログ もご確認ください。このモデルはバージニア北部リージョンで利用可能です。 Connect your Jupyter notebooks to Amazon EMR Serverless using Apache Livy endpoints Amazon EMR サーバーレスが Apache Livy のエンドポイントをサポートしました。これによりJupyter notebookを安全に接続しインタラクティブにデータのクエリ、探索、視覚化し、Spark ワークロードを実行できるようになったほか、Livy REST APIを使用したApache Sparkワークロードを管理できるようになりました。この機能は東京、大阪を含む24のリージョンでEMR リリースバージョン 6.14 以降でご利用いただけます。詳細は ドキュメント もご確認ください。 PostgreSQL 17 Beta 1 is now available in Amazon RDS Database Preview Environment Amazon RDS for PostgreSQL 17 Beta 1がAmazon RDS データベースプレビュー環境で利用可能になりました。RDSのプレビュー環境は、本番環境へのデプロイ前に新しいデータベースエンジンをテスト・評価するためのものです。PostgreSQL 17 Beta 1の詳細については コミュニティのリリース をご確認ください。 AWS Launches Console-based Bulk Policy Migration for Billing and Cost Management Console Access こちらの ブログ でもご紹介の通り、昨年よりAWS 請求、コスト管理、アカウントコンソール権限等できめ細やかな権限管理が可能になっています。今回Billing and Cost Managementの権限をこの新しい管理にまだ移行していないお客様向けに、影響を受けるポリシーを特定し、お客様の現在のアクセス状況に合わせて同等の新しいアクションを提案し、テストオプションを提供し、影響を受けるすべてのポリシーを組織全体に移行を支援する機能が提供されました。詳細は ドキュメント をご確認ください。これらの機能は AWS 中国リージョンを除くすべての AWS 商用リージョンでご利用いただけます。 それでは、また来週！ ソリューションアーキテクト 根本 裕規 (twitter – @rr250r_smr )

はじめに このブログ記事では、Just Energy 社が Amazon Connect を使用してクラウドベースのコンタクトセンターに移行した理由と、その移行が従来のコンタクトセンター基盤で直面していた課題の克服にどのように役立ったかを紹介します。Just Energy は、北米の大手電力および天然ガスの販売業者です。20 年以上の歴史を持つ Just Energy は、信頼性が高く手頃な価格のエネルギーを顧客に提供してきた実績があります。Just Energyには、1,200 人以上の従業員と 500 人の専任のカスタマーサービス担当者からなるチームがおり、比類のないカスタマーサービスの提供に取り組んでいます。カスタマーサービスの提供には、次のような顧客重視のさまざまなタスクが含まれます。 請求書、口座、サービスプランに関する顧客の質問への回答 住所や支払い方法などのアカウント変更の処理 支払い処理 サービス契約の更新 その他 Just Energy は、1 日あたり最大 25,000 件の電話を受けます。需要にこたえるためには、変化する顧客やエージェントのニーズに迅速に対応し、より多くのセルフサービスソリューションを提供する方法が必要でした。また、顧客満足度、ロイヤルティ、顧客維持率を向上させたいとも考えていました。 従来のコンタクトセンターにはどのような課題がありましたか？ 当社の従来のコンタクトセンターは、複数の物理的な場所とデータセンターにまたがってホストされている自己管理型のハードウェアシステムの集合でした。そのため、複数年の契約プロセスを経て、ベンダーの立ち上げを待たなければならず、システムに変更を加えることが困難で時間がかかりました。さらに、他のバックオフィスシステムとの統合は、しばしば費用がかかり、難しく、時には不可能でした。 具体的には、次のような課題に直面しました。 長い導入までの時間 : 従来のコンタクトセンターシステムでは簡単な変更を加えるのに数か月かかる場合があります。これは、契約プロセスが複雑で時間がかかることと、ベンダーの立ち上げ時間が遅かったことが原因でした。 高コスト： 従来のコンタクトセンターシステムを他のバックオフィスシステムと統合する場合、しばしば高額なコストが必要でした。これは、統合プロセスの複雑さ、スキルの不足、およびベンダーの費用が原因でした。 柔軟性の欠如 : 当社の従来のコンタクトセンターには柔軟性がありませんでした。そのため、市場や顧客のニーズの変化に適応することが困難でした。たとえば、新しい製品やサービスを追加したい場合、単純な変更を加える場合も、時間と費用のかかるプロセスを経なければなりません。 これらの課題により、従来のコンタクトセンターシステムを最新かつ効率的に維持することが困難になりました。その結果、クラウドベースのコンタクトセンターソリューションに移行することにしました。 コンタクトセンターを AWS に移行した理由を教えてください 従業員もビジネスも地理的に多様化し、複数の場所にいるお客様、従業員をサポートできるコンタクトセンターが必要になりました。人工知能、機械学習、リアルタイム分析などの最先端テクノロジーを活用して、サポートチームの機能を再定義したいと考えていました。クラウドの採用が、生産性、顧客体験の向上、最終的にはビジネスの成長につながることはわかっていました。 さまざまなクラウドコンタクトセンターソリューションを評価した結果、Amazon Connect を選択しました。当社にはスケーラブルで、強力なリアルタイム分析と機械学習機能を備え、他のビジネスシステムと簡単に統合できるソリューションが必要でした。また、Amazon Connect は従量課金制のサービスであり、使用した機能に対してのみ支払うという柔軟性があることも気に入りました。 Amazon Connect はビジネス成果の達成にどのように役立ちますか? Amazon Connect により、以前よりも迅速かつ簡単にコンタクトセンターに変更を加えることができます。サードパーティ企業と長期契約を結ぶ必要がなくなり、新しい機能や事業の追加を数か月ではなく数時間または数日で立ち上げることができるようになりました。これにより、お客様のニーズにより迅速に、より迅速に対応できるようになりました。 さらに、Amazon Connect を使用することでコストを最適化することもできました。高価なハードウェアやソフトウェアに投資する必要がなくなり、使用したリソースの分だけを支払います。これにより、経費を節約し、より良い顧客サービスの提供に集中できるようになりました。 また、 Amazon Connect Contact Lens も有効にしました。Contact Lens は、問題点や一般的な顧客ニーズを発見し、顧客体験を積極的に向上させるのに役立つ強力なツールです。 Amazon Connect に移行し、Just Energy は次のようないくつかのビジネス成果を達成してきました。 顧客満足度の向上 : Just Energy の顧客満足度スコアは Amazon Connect に移行してから 18% 向上しました。 コスト削減 : Just Energy は Amazon Connect に移行して以来、コンタクトセンターのコストを 12% 削減することができました。 エージェントの生産性の向上 : Amazon Connect に移行して以来、Just Energy のエージェントは 1 時間あたり 15% 以上多くの通話を処理できるようになりました。 俊敏性の向上 : Just Energy は Amazon Connect に移行して以来、より迅速かつ簡単にコンタクトセンターに変更を加えることができるようになりました。 現在は何に取り組んでいますか？ 当社では、ビジネス上のリスクや問題を特定し、セルフサービスを改善する機会を見つけるために、 Contact Lens による音声認識と自然言語処理を活用しています。また、スクリプトの順守、機密データの収集、顧客への挨拶などの評価スコア基準を自動的に入力する Contact Lens のエージェント評価機能 も試しています。これにより、エージェントの特定とコーチングに費やす時間を短縮でき、エージェントは可能な限り最高のカスタマーサービスの提供に集中できるようになります。 Contact Lens は、カスタマーサービスの向上とコスト削減に役立つと考えています。私たちは実験の結果に期待しており、将来的にその結果を皆さんと共有できることを楽しみにしています。 結論 Just Energyは、俊敏性の欠如、複雑な統合、コストのかかるオンプレミスソリューションに関する課題に直面していました。Amazon Connect の使用を決定したのは、スケーラブルで、強力なリアルタイム分析と機械学習機能があり、他のビジネスシステムとも簡単に統合できるからです。また、Just Energy は Amazon Connect は従量課金制のサービスであり、使用した機能に対してのみ支払うという柔軟性があることも評価しました。 世界中のお客様 がクラウドベースの仮想コンタクトセンター Amazon Connect をどのように使用してカスタマーサービス体験を向上させているかをご覧ください。 Just Energy について Just Energy は、電力と天然ガスを専門とし、エネルギー効率の高いソリューションや再生可能エネルギーを顧客に提供する小売エネルギープロバイダーです。現在、米国とカナダで事業を展開している Just Energy は、一般家庭および商業顧客にサービスを提供しています。Just Energy は、 Amigo Energy, Filter Group Inc., Hudson Energy, Interactive Energy Group, Tara Energy, terrapass の親会社です。 Billy Laney Billy Laney は Just Energy のソリューションアーキテクトです。エンタープライズアプリケーション開発に 18 年以上の経験を持つ Billy は、生活を楽にするソフトウェアの構築と設計に情熱を注いでいます。余暇には、旅行、サンドバレーボール、ゴルフ、セミプロのボウリングを楽しんでいます。 Michael Goligorsky Michael Goligorsky は、AWS のシニアソリューションアーキテクトです。フォーチュン 100 企業で 25 年以上エンタープライズ IT の経験を積んだ Michael は、クラウドコンピューティングにおける特に複雑な課題を、お客様と共に深く掘り下げ、創造的なソリューションを設計、構築することに情熱を注いでいます。余暇には、家族と一緒に世界中を旅しています。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 主にエンジニアの方向けのAWS公式ウェブマガジン、 builders.flash はご存じでしょうか？クラウドに関するベストプラクティスの解説や開発インタビューを掲載するウェブマガジンで、最近は世の中の興味の高まりを受けて生成AIに関係するトピックが増えてきています。執筆者はAWS社員はもちろん、社外の方に寄稿頂いたものもあります。今月公開された記事では、 生成 AI を活用したニュース 3 行要約を配信するシステムをマネージドに作成する (ニフティ株式会社様) Amazon Bedrockはリアルなカードゲームでも強い味方だった(ポーカー編)?! 無茶振りは生成AIに断ってもらおう~ブラウザに生成AIを組み込んでみた~ マルチモーダルな生成AI活用の入門編！-画像認識と画像生成 といった、生成AIを実用していくためのヒントになる記事があります。ウェブマガジンということもあり、AWSが普段公開しているお客様事例よりも少しカジュアルなトーンで、楽しく読んで頂けるようにしています。まだ見たことがないよ、という方はぜひ眺めてみてください（そして、気に入って頂けたらメールメンバーへの登録をお願いします！）。 それでは、5 月 20 日週の生成AI with AWS界隈のニュースをお届けしていきましょう。 さまざまなニュース カラクリ株式会社様がAWS Trainiumで学習したMoEモデル「KARAKURI LM 8x7B Chat v0.1」の公開を発表 カスタマーサポートDXを推進するカラクリ株式会社様が、AWSの機械学習トレーニングアクセラレーター AWS Trainium を利用してトレーニングしたモデルを公開しました。カラクリ株式会社様は、昨年AWSが発表した AWS LLM開発支援プログラム にご参加いたいた企業のひとつです。プレスリリースによれば、今回公開されたモデル「KARAKURI LM 8x7B Chat v0.1」は国産オープンモデルとしてベンチマークテストで最高点の評価を得ており、この開発に要したコストは約30万円、学習時間は12時間に抑えることができたとのことです。AWSは、カラクリ株式会社様のように独自のモデル開発にチャレンジするお客様と、公開モデルをビジネスに活用しようと考えるお客様の双方を支援していきたいと考えています。ご興味のある方は、ぜひご相談ください。 ブログ記事「Amazon Q in Connect向けナレッジベースの最適化」(日本語)を公開 Amazon Connectは、AWSが提供するクラウドベースのコンタクトセンターのサービスです。Amazon Connectには、Amazon Q in Connectという生成AIによって音声・チャットの双方について、オペレーターの方を支援する機能が搭載されています。このブログ記事では、Amazon Q in Connectが推奨事項を生成する仕組みや、その機能を最大限活用するためのコンテンツ最適化手法についてご紹介しています。 ブログ記事「Create a multimodal assistant with advanced RAG and Amazon Bedrock」を公開 現時点では英語の記事ですが、興味深い内容だったのでピックアップします。アプリケーションに組み込んだ生成AIからの出力を、自分達のデータに基づいた形にカスタマイズする手法のひとつとして、検索拡張生成(RAG)が広く知られています。しかしながら、単純なRAGアーキテクチャはテキストと画像など複数のデータが組み合わさった、マルチモーダルデータを扱いたい場合はうまく機能しないケースがあります。このブログ記事では、マルチモーダルデータに対応するためにmmRAG(マルチモーダルRAG)という手法を紹介しています。 ブログ記事「A generative AI use case using Amazon RDS for SQL Server as a vector data store」を公開 こちらも英語ですが、「こういうパターンもあるのか」という気づきがありました。こちらも検索拡張生成RAGに関する記事です。先にも書いたとおりRAGは基盤モデルの出力をカスタマイズする手法のひとつです。そのためのナレッジベースとなるベクトルデータベースとしてAmazon RDS for SQL Serverを使うパターンが記事の中で紹介されています。ユーザからの質問をAmazon Titan Embeddingsを使ってベクトル化し、DBで検索、その結果をAnthropic Claude 2で処理して応答するというシンプルな設計です。ベクトルデータベースの有用性を理解する助けになりますので、ぜひごらんください。 サービスアップデート Amazon Bedrockで基盤モデル “Mistral Small” が利用可能に Mistral AI社の基盤モデル、Mistral SmallがAmazon Bedrockを介してご利用いただけるようになりました。Mistral Smallは多くのテキストデータを低レイテンシーで処理することに最適化された効率的なモデルです。たくさんのテキストファイルに含まれた内容を一括処理するタイプのタスクに向いているとされており、例えば「大量に届いたメールに対して返信案を作成する」といったユースケースに適しています。 Amazon NeptuneがLlamaIndexをサポートしGraphRAGアプリケーションの構築が可能に 大規模言語モデル(LLM)を組み込んだアプリケーションを構築するときに利用されるオープンソースフレームワークのひとつに、 LlamaIndex があります。今回、LlamaIndexを利用してAWSのフルマネージドなグラフデータベースである Amazon Neptune をナレッジベースとした「グラフによる検索拡張生成(Graph RAG)」アプリケーションを開発できるようになりました。グラフは情報の関連性を記述することに優れています。検索拡張生成でグラフデータベースを利用すると、「自分に関係のあるニュースを教えて」といった、関連性にフォーカスしたユーザからのリクエストに適切に応答することが可能です。 ソリューションアーキテクト 小林 正人 (X – @maccho_j )

2024年1月31日から3日間開催された IIFES (Innovative Industry Fair for E x E Solutions) にて、 パトライト社 のブースで Amazon Monitron とパトライト社製のネットワーク制御信号灯 NHV シリーズ との連携による現場改革の事例が紹介されました。このソリューションによって、設備異常の予知を逃さずに、より確実に現場の対応を実現できるようになります。展示物はパトライト社と AWS の協力で制作され、このブログでは両社によるユースケースとデモの作り方を紹介させていただいています。現場で Amazon Monitron による予知保全を検討されているお客様に参考になれば幸いです。 IIFES では、ブースにご来場されたお客様は「予知/予防保全」「人手不足での巡回点検削減」「遠隔監視」用途でラインの変更不要で設置できる点に興味を示していただきました。 予知保全の異常検知を見逃さない現場へ Amazon Monitron とは、回転機器の温度や振動データを Amazon Monitron センサーが収集し、機械学習を使って分析し、潜在的な障害を検知してダウンタイム発生を削減するために役立てるサービスです。パトライト社製の信号灯と組み合わせることで、設備の異常検出の見える化を実現できます。この展示で紹介した事例では、設備の異常状態を信号灯の色と音声で工場の現場に知らせています。Amazon Monitron サービスからはアプリとメールで通知することができますが、お客様によって業務用にスマートフォンを持たなかったり、メールを常に確認できない状況だったりします。工場で多くの実績を持っていて、現場の運用に欠かせないパトライト社製の信号灯を利用することで、ビジュアルや音声による通知を行うことができ、より確実な設備保全につながります。 NHV シリーズと AWS の IoT サービスとの親和性 パトライト社製信号灯 NHV シリーズは、パソコンなど追加の機器を必要とせずに、Ethernet ネットワーク経由で直接に AWS IoT Core と連携できる特徴を持っています。数ステップの簡単な設定で AWS IoT Core と接続できるので、導入が極めてシンプルです。また、Text to Speech 機能によって、光と音だけではなく、AWS IoT Core 経由で送信したテキストを読み上げることができ、より直感的にわかりやすい警告を現場の作業員に伝達することができます。 デモ構成の紹介 ここからは、今回の展示で実装したデモの構成のテクニカルな面を紹介します。仕組みとしては、Amazon Monitron のデータストリームから設備異常の予知結果を取得して、AWS IoT Core 経由でリアルタイムに信号灯に送信する構成になっています。サーバレスコンピューティングサービスである AWS Lambda によって Amazon Monitron から送られる設備異常の予知の状態変化イベントをキャッチして、AWS IoT Core 経由で信号灯に適切な表示状態と発声する文章を送信しています。 Amazon Monitron のデータ連携 Amazon Monitron には Amazon Kinesis Data Streams に計測値と状態変化のイベントを送信する機能があります。この機能を使って、発生するイベントを AWS Lambda が処理しリアルタイムにアクションを起こすか、自社の設備保全管理システムにデータを連携したり、さらなる分析のために Amazon S3 に蓄積することができます。今回のデモでは、AWS Lambda からリアルタイムに AWS IoT Core 経由で信号灯に状態変化を連携しました。 AWS Lambda でのイベント処理 今回のデモでは、状態変化を表す assetStateTransition というイベントタイプを解析して、イベント内の newState 値を参照して信号灯にアクションを送信します。Amazon Monitron が送信するイベントの詳細は「 Amazon Monitron Kinesis データエクスポート v2 」をご参照ください。以下、Python 言語のコードの例を表します。 def process_assetStateTransition(monitron_event): monitron_payload = monitron_event['eventPayload'] new_state = monitron_payload['assetState']['newState'] if new_state == 'HEALTHY': set_nhv_state_healthy() elif new_state == 'WARNING': message = "{} に警告が発生しました。".format(monitron_payload['assetName']) set_nhv_state_warning(message) elif new_state == 'NEEDS_MAINTENANCE': set_nhv_state_maintenance() elif new_state == 'ALARM': message = "{} にアラートが発生しました。".format(monitron_payload['assetName']) set_nhv_state_alarm(message) else: print("Got event.") monitron_event 変数は Amazon Monitron の v2 スキーマ形式 のイベントを受け入れ、 assetStateTransition イベントが発生した時に、 eventPayload 要素には今回解析の対象となる assetState がセットされます。 assetState の newState の値に合わせて適切な信号灯の色を設定する制御ロジックを呼び出します。例えば、 newState が HEALTHY の場合は、 set_nhv_state_healthy を呼び出し、 WARNING の場合は、 set_nhv_state_warning を呼び出します。 また、特定の newState の時だけに（この例では WARNING と ALARM ）、信号灯にメッセージを発声させるためにアセット名を含んだ警告メッセージ message を生成して、色制御のロジックのパラメータとしてそのメッセージ引き渡します。 信号灯のカラー設定と発声 NHV シリーズは追加のサーバを設けずに、直接 AWS IoT Core と連携できます。利用する機能は AWS IoT Device Shadow と MQTT 通信です。Device Shadow とは、デバイスが常時に接続していなくても、クラウド側にデバイスのプロパティのコピー (シャドウ) を保存して、お互いの値の変更が双方向に伝搬させる仕組みです。この機能によって、信号灯の色の状態変更が可能です。また、MQTTトピック経由で、色の状態の変更だけではなく、信号灯のボタンの操作イベントの取得や、信号灯への Text to Speech のテキストの送信も可能です。今回のデモでは、Device Shadow を使って、 newState の値に合わせて信号灯の色の状況を変更しています。 以下は、状態の変化に応じて信号灯に色の変更やテキストの発声を指示するコードの例です。 def set_nhv_state_healthy(message=None): payload = { "state" : { "desired" : { "led_green" : 1, "led_yellow" : 0, "led_red": 0 } } } iot.update_thing_shadow( thingName = "NHV_IoT_Thing", # NHV's Thing Name in AWS IoT Core payload = json.dumps(payload).encode("utf-8") ) if message != None: speech_json = { "speech": [ { "text": message, "lang": "jp" } ] } iot.publish( topic="NHV/Subscribe", # NHV's Subscribe Topic in AWS IoT Core payload=json.dumps(speech_json).encode("utf-8") ) このコード例では、正常な状態を設定するもので、そのために緑色だけを点灯させて、他の黄色と赤は消灯になるように、Device Shadow の desired 要素に “led_green” を “1” に設定し、他は led_ 要素を “0” にしています。 desired 要素は AWS IoT Device Shadow の仕様で定められていて、led_green などの led_ 関連の要素は NHV の仕様で定められています。 また、Device Shadow のアップデートをかけた後に、発声するメッセージがあれば、そのメッセージを IoT トピック経由で信号灯の Text to Speech 機能に送信することで、信号灯から音声が流れます。 まとめ このブログでは IIFES のパトライト社のブースで紹介された Amazon Monitron と信号灯 NHV シリーズとの連携によって、生産設備の予知保全の異常通知を現場が逃さないように信号灯の色と音声の通知が有効であると紹介しました。また、参考に今回のデモの構成の詳細な動作を説明しました。 今から始める 自社の現場への導入にご興味のある方は、AWS またはパトライト社までお問い合わせください。 AWS のサービスに関するお問い合わせは、「 AWS に問い合わせする 」からお願いします。 パトライト社製品に関するご質問は、 パトライト社 のサイトからお問い合わせください。 著者について シャルノ ミカエル エンタープライズ技術本部 小売・消費財 第一ソリューション部 ソリューションアーキテクト AWS では消費財のお客様の製造ソリューションに限らず、スマートファクトリー関連の活動をしています。今回の展示物のデータ連携の開発を担当させていただきました。

2024 年 4 月に公開された AWS Black Belt オンラインセミナーの資料及び動画についてご案内させて頂きます。 動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画は「 AWS サービス別資料集 」に一覧がございます。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご覧ください。 Amazon QuickSight 埋め込みオプションとタイプのご紹介 Amazon QuickSight の埋め込み機能を使うことで、アプリケーションやウェブポータルに Amazon QuickSight のインタラクティブなダッシュボードやビジュアル、コンソール、さらに機械学習を利用した自然言語クエリ機能を組み込むことができます。本セッションでは、QuickSight 埋め込みのオプションとタイプについてご紹介し、概要とそれぞれの実装方法を解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS を用いたデータ活用を検討されている方 Amazon QuickSight の埋め込み機能をご利用予定の方 ダッシュボードの作成をご経験されている方 Amazon QuickSight のマルチテナンシー・データアクセス制御機能の知識をお持ちの方 本 BlackBelt で学習できること Amazon QuickSight の埋め込みオプションとタイプの概要とそれぞれの実装方法について理解する QuickSight Embedding SDK を活用してきめ細かなアプリケーションとの連携を実現する方法を理解する スピーカー 守田 凜々佳 ソリューションアーキテクト AWS の言語系 AI サービス AWS には、機械学習の専門知識不要で簡単に利用できる AI サービスが複数あります。本セミナーでは、AWS がご提供する AI サービスのうち、音声やテキストなど、言語に関連する AI サービスについて、基礎的な内容をまとめてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 テキストや音声を扱える AWS の言語系 AI サービスを網羅的に学びたい方 ビジネス部門・技術部門問わず、業務やサービスに AI を活用したい方 (※機械学習の深い専門知識は不要です ) 本 BlackBelt で学習できること 音声・テキスト・チャットボット・検索を扱う AI サービス群の概要・用途・特徴的な機能・料金体系 言語系 AI サービスを組み合わせたアプリケーションの構築例 (※本セミナーでは、生成 AI はサービスの組み合わせ例の一部として登場します ) スピーカー 安藤慎太郎 ソリューションアーキテクト AWS Systems Manager Patch Manager AWS Systems Manager (SSM) は統合的な AWS 環境の運用をするためのツールとして進化しており、多くの機能を持っています。本セッションでは、AWS Systems Manager の数ある機能のうち、 Patch Manager についてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS の運用をされている方や、これから運用される予定の方を想定しています。 本 BlackBelt で学習できること 本セッションを通じて、 AWS Systems Manager Patch Manager の機能とユースケースをご理解いただくことができます。 スピーカー 小野 卓人 ソリューションアーキテクト AWS Key Management Service Part.2 発展編 AWS Key Management Service (AWS KMS) は、暗号化操作に使用される暗号鍵を簡単に作成および管理できるマネージドサービスです。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS 環境における様々な暗号化ユースケースに関心をお持ちの方 AWS Key Management Service をご利用予定の方 AWS Key Management Service についてより理解を深めたい方 本 BlackBelt で学習できること 本セッションでは、暗号化の様々なユースケースに焦点を当て、AWS KMS を利用した様々な暗号化の仕組み、暗号化を支える鍵管理の仕組み、そして、AWS KMS での暗号鍵の保管や管理の信頼性についての仕組みを学んでいただけます。 スピーカー 平賀 敬博 セキュリティソリューションアーキテクト Amazon S3 Express One Zone 2023 年の AWS re:Invent で発表された Amazon Simple Storage Service (Amazon S3) の新しいストレージクラスである、Express One Zone についてユースケースを絡めながら詳しく紹介します。Express One Zone を使う上でのメリットや注意点を学ぶことができます。 資料（ PDF ） | 動画（ YouTube ） 対象者 新しいストレージクラス、S3 Express One Zone に興味を持つ方 Amazon S3 のパフォーマンス向上に興味、もしくは課題を持つ方 本 BlackBelt で学習できること S3 Express One Zone の特徴、詳細、ユースケース、料金 スピーカー 吉澤 巧 ソリューションアーキテクト 今後の Black Belt オンラインセミナー また、現時点で予定されている今後の Black Belt オンラインセミナーについては以下の通りです。 公開月 タイトル 登壇予定者 2024-06 AWS Cost Explorer テクニカルアカウントマネージャー 加須屋悠己 2024-07 Amazon Location Service ソリューションアーキテクト 稲田大陸  

API による通信ネットワークへのアクセス アプリケーション・プログラミング・インターフェース(API)は、現代のソフトウェア設計において不可欠な要素であり、マイクロサービスアーキテクチャの基盤です。過去1年間、世界中の通信事業者は、ネットワークを強化し、ネットワークサービスへのアクセスを可能とする API を提供することで、通信ネットワークのオブザーバビリティ（可観測性）とプログラマビリティを向上してきました。GSMA のOpen Gateway イニシアチブの下で、通信事業者はこれらの API 定義の標準化を進めており、これらのAPIを使用するアプリケーションは、さまざまな接続プロバイダーや地域間で移植可能になっています。アプリケーション開発者（デベロッパー）がこれらの API を使用して、アプリケーションに追加できる機能の例には次のようなものがあります。1) 電話番号に関連付けられたSIMカードが最後に変更された時刻の確認(SIM Swap API)、2) 電話番号を確認することによるモバイルネットワークへの端末の シームレスな認証 (Number Verification API)、3) ローミングの状況など、ユーザー端末の接続状況の確認 (Device Status API)、4) アプリケーションクライアントとサーバー間のデータフローに対して、安定したレイテンシ(ジッターの低減)やスループットの要求 (Quality on Demand API)、5)アプリケーションをホストするのに最適なエッジクラウドノードの発見 (Edge Discovery Service API) など、その他にも多数あります 1。 アプリケーション開発者は、これらのAPIと他のソフトウェアコンポーネントを組み合わせて、“ネットワーク対応” のアプリケーションを構築し、これまで不可能だった新しいアプリケーションを作成することができます。長年にわたり、AWS はグローバルにクラウドインフラストラクチャとサービスを構築し、アプリケーション開発者やお客様に API を通じて提供してきました。AWS は、通信事業者とのパートナーシップを通じて、AWS のアプリケーション開発者に通信事業者のネットワーク API を提供しています。これらのアプリケーション開発者は既に240以上の AWS サービスから数千の AWS API を使用しており、今後はこれらの通信のネットワーク API を使ってアプリケーションを構築し、AWS でホストすることができるようになります。 AWS が通信事業者とアプリケーション開発者を支援する方法 このコラボレーションにより、AWS は通信事業者とアプリケーション開発者の両方を支援しています。1つ目に、AWS はフリクションレスで魅力的な開発体験を提供しています。AWS には、その豊富で幅広いサービスポートフォリオを使ってアプリケーションを構築する大規模な開発者コミュニティがあります。テレコムネットワーク機能を API を通して提供することは、AWS ユーザーに馴染みのあるアプリケーション開発体験を維持しつつ、新しい機能を提供するものです。AWS がアプリケーション開発者に提供する価値としては、複数の接続プロバイダへのアクセス、簡素化された開発体験、API の抽象化によるアプリケーションの移植性です。2つ目に、AWS は通信事業者に新しい販売チャネルを創出しています。API を通して提供される新しいネットワークサービスの構築に加えて、通信事業者は幅広い普及のための新しいチャネルを求めています。AWS は、スタートアップから中小企業、大企業、公共セクター企業まで、さまざまな業界に対応する大規模な開発者コミュニティへのチャネルを提供します。3つ目は、このコラボレーションは、 API を提供する通信事業者と、それを利用してアプリケーションをホストするアプリケーション開発者の両者に対して、グローバルへのリーチを創出します。多くの通信事業者は国内で事業を行っているのに対し、アプリケーション開発者、アプリケーション、そしてその利用は複数の地理的領域にまたがります。AWS はデベロッパーに、異なる接続プロバイダや国にまたがってアプリケーションの移植性を促進する、一貫性のある標準化された API エクスペリエンスをグローバルに提供します。 ネットワーク API を利用して AWS で構築されているアプリケーション すでに AWS のサービスを利用している AWS のお客様やアプリケーション開発者は、通信事業者のこれらの API を自社のアプリケーションに統合し始めています。初期のアプリケーションはさまざまな業種に及んでおり、通信事業者が開発しているさまざまな API を使用しています。以下にいくつか例を挙げます。 自動運転 ：Unmanned Life 社は、配送、監視、データ収集のための自律型ドローンのオーケストレーションプラットフォームを提供します。彼らのプラットフォームは、Amazon Elastic Kubernetes Service (Amazon EKS) 、Amazon Relational Database Service ( Amazon RDS ) 、およびその他の AWS サービス上に構築されています。ドローンのリモート制御にはネットワークパフォーマンスが重要であるため、Unmanned Life 社は Quality on Demand API を使用して帯域幅と遅延の保証をオンデマンドでリクエストし、ドローンのシームレスな運用を保証しています。 Industrial XR ：Holo-Light 社は、デジタルツイン、リモートメンテナンス、コラボレーションデザインに使用される、XRデバイスに高品質の没入型ストリーミングを提供する産業用拡張現実（XR）ソフトウェアを専門としています。レンダリングには GPU を搭載した Amazon Elastic Compute Cloud (Amazon EC2) 、ストレージには Amazon Simple Storage Service (Amazon S3) を利用して構築し、XR サービスの低レイテンシーストリーミングとエンドツーエンドのパフォーマンスを実現しています。Holo-Light 社は、Quality on Demand API を使用してネットワークパフォーマンスを制御し、プレミアムなユーザーエクスペリエンスを提供します。 金融サービス ：Terralogiq 社は、利用者のオンボーディングやクレジット申請などのプロセスを合理化する企業向けの金融サービスソリューションを提供しています。Terralogiq 社は Amazon EC2、データ抽出には Amazon Textract、顔認識には Amazon Rekognition を利用しています。Terralogiq 社はユーザーセキュリティに重点を置き、SIM Swap API と番号検証のための Number Verification API を活用してエンドユーザーを詐欺から保護し、シームレスな認証体験を保証します。銀行業でも同様の用途が見られます。 ゲーム ：Gamium 社は、ネイティブデジタル決済と、ゲームと仮想的なソーシャル環境におけるデジタル ID 間の安全な取引のためのクラウドプラットフォームを提供します。Gamium 社のプラットフォームは、AWS Fargate や Amazon RDS などのサービス上に構築されています。Gamium 社は、Number Verification API と SIM Swap API を活用して、ユーザー認証の簡素化、不正防止の強化、安全なデジタル取引を実現しています。 世界中の通信事業者との提携 私たちは世界中の通信事業者とともに、彼らのネットワークから提供されるネットワーク API を、より多くのアプリケーション開発者やお客様に届ける取り組みを続けています。 Verizon 社のテクノロジー・プロダクト開発担当シニアバイスプレジデントである Srini Kalapala 氏は “ Verizon のネットワーク API は、世界中の企業やアプリケーション開発者に最先端のネットワーク機能を導入し、Verizon の 5G ネットワークの大きな可能性を示し、企業内のデジタル変革を加速し、イノベーション、成長、収益性を促進しています ” と述べています。“ AWS を通じてこれらの API を導入することで、グローバルレベルのアプリケーション開発者は Verizon が提供するネットワークの価値と機能に簡単にアクセスできるようになります。この AWS との連携は、2023 年に紹介したネットワーク API の PoC（技術的概念実証）の基礎となっています。これらのコラボレーションでは、Edge Discovery Service API と Quality on Demand API の具体的なユースケースが浮き彫りになりました。この分野のリーダーとして AWS との緊密なコラボレーションを継続できることを楽しみにしています ” Telefonica 社の CDO（最高デジタル責任者）である Chema Alonso 氏は次のように述べています。“ Open Gatewayにより、アプリケーション開発者はプログラム可能なネットワークのあらゆる機能を活用して、ビジネスクリティカルなアプリケーションを構築できます。CAMARA 標準仕様により、ネットワーク API は非常に使いやすくなり、地域のプライバシー法への自動的な準拠を保証します。AWS は、すべての通信事業者で API を一貫して使用できるようにするための理想的なプラットフォームであり、世界で最高のアプリケーション開発者環境の 1 つとして利用できます”。 T-Mobile 社のテクノロジーイノベーション・インダストリーパートナーシップ担当上級副社長である Mark McDiarmid 氏は次のように述べています。“ 2022年にネットワークAPIへのアクセスを提供開始して以来、T-Mobile はアプリケーション開発者と企業がイノベーションの限界を押し広げることを可能にしてきました。そして今では、AWS 開発者コミュニティにもリーチできることを嬉しく思います。アプリケーション開発者が Quality on Demand API を通じてより一貫したネットワークパフォーマンスを活用しているか、またはビデオ通話ネットワークスライシング機能（米国のライブスタンドアロン5Gネットワークで利用できる唯一のプログラム）を活用しているかに関わらず、T-Mobile はアプリケーション開発者がネットワーク API を活用して明日に向けたソリューションを構築する際の障壁を取り除いています。” Orange Group の最高技術責任者で Orange Innovation Networks 社のシニアバイスプレジデントである Laurent Leboucher 氏は次のように述べています。“ AWS が通信事業者と協力して Orange の Network API を公開したことを歓迎します。これにより、世界中のアプリケーション開発者がネットワーク対応アプリケーションをサポートする貴重な機会が得られます。このことは、本番稼働中のOrange Mobile Private Network on AWS Cloud によってすでに実証されている市場と、自律型ネットワークにおける我々の継続的なコラボレーションに対して、インパクトのある共同イノベーションをもたらすと信じています。” Liberty Global 社のモバイル＆クラウド担当マネージングディレクターである Madalina Suceveanu 氏は、次のように述べています。“ 新しいパートナーシップを活用してアプリケーション開発者と通信ネットワークをより緊密に連携させ、開発者がこれまで不可能だった方法で顧客のニーズを満たすアプリケーションを作成できるようにできることを嬉しく思います。Liberty Global では、固定回線および5Gスタンドアロン（SA）モバイルネットワークを活用して、魅力的なユースケースを開発しています。その一部は Mobile World Congress 2024 で紹介されています。この AWS とのパートナーシップは、今後大きな役割を果たすでしょう。通信事業者、グローバルなクラウドベースのプロバイダー、アプリケーション開発者、標準化団体が協力してエコシステムを推進し、世界規模での運用を確実にするために、この取り組みを継続することが不可欠です。” AWS の使命は、アプリケーション開発者が世界中にデプロイできる強力なアプリケーションを簡単に構築できるようにすることです。私たちは、より高度で多様な機能をアプリケーション開発者に提供するために継続的に努力しています。世界中の通信事業者が開発、提供している ネットワーク API は、通信事業者のネットワーク対応アプリケーションを構築するための新機能の 1 つで、AWS アプリケーション開発者が利用できるようになります。ネットワークが成熟し、開発者コミュニティで API が運用されるようになるにつれて、世界中のより多くの通信事業者と協力できることを楽しみにしています。 1 Linux Foundation’s CAMARA API Repositories 著者について Dr. Ishwar Parulkar Ishwar Parulkar 博士は、アマゾンウェブサービスのテレコムおよびエッジクラウドのチーフテクノロジストです。この役職では、AWS テクノロジー戦略の策定、新しいクラウドサービスの定義、AWS のエッジクラウドサービスと次世代の通信ネットワークおよびサービスを実現するためのイニシアチブの主導を担当しています。 AWS に入社する以前は、Parulkar 博士は Cisco 社の Distinguished Engineer であり、通信ルーティング、モバイルパケットコア、スモールセル、ネットワークオーケストレーション製品を担当するビジネスユニットのチーフアーキテクトでもありました。彼はモバイルエッジコンピューティングと 5G に関する業界全体のイニシアチブの創設メンバーであり、クラウドテクノロジーが通信分野を変革できるという確信から 2016 年に AWS に入社しました。Cisco 社に入社する前、Parulkar博士はSun Microsystems 社の Distinguished Engineer として、業界初のマルチコアプロセッサシステムや最初のコンピューティング仮想化プラットフォームなど、データセンターのコンピューティングインフラストラクチャの設計を主導しました。彼はApple 社でキャリアをスタートし、Mac デスクトップ/ラップトップ製品ラインと、iPhone 革命の種を蒔いたニュートンPDAテクノロジーに携わりました。 Parulkar 博士は、ヴァンダービルト大学で修士号を、南カリフォルニア大学で博士号を取得しています。南カリフォルニア大学の産業諮問委員会のメンバーとして数年間務めました。彼は数十件の特許を保有し、IEEE/ACM ジャーナル/カンファレンスで25 以上の論文を発表し、ネットワーキングとコンピューティングに関する IEEE/ACM カンファレンスのプログラム委員会メンバー/議長を務めました。2017年、Parulkar 博士は、通信ネットワークとデータセンターコンピューティングの分野における卓越性と多大な貢献により、インド国立工学アカデミーの外国人フェローに選出されました。   原文は こちら です。 翻訳はソリューションアーキテクトの鈴木 浩之が担当しました。

本記事は 2024年1月4日に公開された ” Custom Post-launch actions and Deployment scripting using AWS Systems Manager and Amazon CodeWhisperer ” を翻訳したものです。 このシリーズの パート 1 では、 AWS でのブルー/グリーンのテストとデプロイ について学びました。これは、デプロイが失敗した場合のロールバックプロセスを簡略化することで、アプリケーションの可用性を高め、デプロイのリスクを軽減するための重要な戦略です。 AWS Application Migration Service (AWS MGN) による継続的なレプリケーション機能と、事前定義済みの起動後アクションを利用することでデプロイプロセスを簡素化する方法を紹介しました。 パート 2 では、さらに深く掘り下げて、制御と効率性を最大限に高める方法を説明します。具体的には、カスタマイズした起動後アクションと、 Amazon CodeWhisperer を利用したテスト/移行スクリプトを紹介します。CodeWhisperer は Generative AI を利用したコーディング支援ツールとして機能し、統合開発環境 (IDE) 内でコンテキストに応じたコードの提案をリアルタイムに行います。CodeWhisperer は、特定のプログラミングタスクの内容についての自然言語によるコメントに基づいてコードを提案をしてくれます。これにより、ソフトウェア開発プロセスが合理化されるだけでなく、既製のコードスニペットを使用できるようになります。これらのスニペットは、シンプルな英語のコメントと一致しているので、内容を簡単に受け入れたり、詳しく調べたり、必要に応じて修正して正確に実装したりすることができます。 この機能を使うことで、柔軟性を維持しつつ AWS リソースの管理をより細かく制御できるようになります。これにより、マネージメントコンソールを使うのではなく、プログラム的なアプローチで AWS リソースを操作することができるため、独自のニーズに対してより効率的かつ信頼性の高いデプロイが行えるようになります。ソフトウェア開発のペースが速いような開発において、この機能は非常に効果的なツールとなります。 検証に パート 1 と同じ環境を用いる場合、AWS MGN テストインスタンスがすでに起動されているようでしたら、改めて動作確認をするために、一度ソースサーバーを切断し状態を白紙に戻すことを検討してください。 ソリューション概要 AWS Application Migration Service (AWS MGN)、Amazon CodeWhisperer、 Amazon EC2 などの AWS サービスを使用すると、次のことが可能になります。 カスタマイズした AWS MGN 起動後アクションを新規に作成します。 起動後アクションが作成されたら、ブルー (移行元) バージョンのインスタンスを AWS MGN に新たに接続します。これは、起動後アクションの変更が、 新しく追加されたソースサーバーにのみ適用 されるため必要となるステップです。 テストインスタンスを作成したら、グリーン (移行先) バージョンの Amazon EC2 インスタンスに対して様々な AWS サービスや機能を追加して試します。 これを実現するために、Amazon CodeWhisperer を用いて記述した boto3 Python スクリプトを使用します。このスクリプトにより、グリーン (移行先) バージョンのインスタンスに　AWS サービスをアタッチする、分かりやすく反復可能なレシピが作成できます。 最後のステップでは、 パート 1 で説明したように、リソースの削除やグリーン (移行先) バージョンのインスタンスのカットオーバープロセスの完了などを行います。 ターゲットアーキテクチャ 次の図は、当ソリューションのアーキテクチャを示しています。 図 1: Amazon CodeWhisperer とカスタマイズした AWS MGN 起動後アクションを使ったブルー/グリーンデプロイテストソリューションのアーキテクチャ カスタマイズした AWS MGN 起動後アクションの設定 ブルー (移行元) バージョンのインスタンスへの MGN エージェントのインストール Amazon CodeWhisperer を用いた boto3 Python スクリプトの作成 コマンドラインからのスクリプトの実行 AWS MGN にてカットオーバープロセスを完了 Amazon Route 53 で DNS ルーティングを更新 詳しい説明 1. カスタマイズした AWS MGN 起動後アクションの設定 最初のパートでは、MGN でカスタマイズした起動後アクションを新たに作成するために必要となる初期設定について説明します。 図 2: AWS MGN マネージメントコンソール、起動後テンプレートのセクション AWS MGN サービスページの [起動後テンプレート] タブを使用して、カスタマイズした AWS MGN 起動後アクション作成します。図 2 に表示されている通り、テンプレートに加えられた変更は、新しく追加されたソースサーバーにのみ適用されます。 図 3: AWS MGN 起動後テンプレート、新規アクションの追加 [アクションを作成] ボタンを選択し、表示されるプロンプトの入力をします。Systems Manager ドキュメントとして、事前定義済みの起動後テンプレートとしては提供されていない、様々なユースケースで利用できるドキュメントが選択できます。 注 : 目的の Systems Manager ドキュメントがリストにない場合は、 独自のドキュメント を作成できます。 図 4: ロードバランサーと Auto Scaling グループを作成する Systems Manager ドキュメント ターゲットアーキテクチャの構成に合わせて、[AWS Migration – CreateLoadBalanceAutoScaleGroup] ドキュメントを選択します。ドキュメントの詳細情報を表示するには、選択したドキュメントの横にある [Systems Manager で表示] ボタンを選択します。 注 : Systems Manager では、 ドキュメントを検索 したり、頻繁に使用するドキュメントをお気に入りに追加してアクセスしやすくすることができます。 図 5: カスタマイズした AWS MGN 起動後アクション。選択した SSM ドキュメントに応じて様々な依存関係が必要となります 設定したい SSM ドキュメントを選択したら、必要なパラメータ項目を入力して設定プロセスを完了します。設定が必要なパラメータは、選択した SSM ドキュメントによって異なります。AWS MGN には、各アクションの実行優先順位を指示するオーダー機能のような標準的な機能が含まれています。 図 6: アクションの作成が正常に完了したことを示すメッセージ カスタマイズした AWS MGN 起動後アクションが正常に作成されたら、ブルー (移行元) バージョンのインスタンスに MGN エージェントをインストールし、テストインスタンスを起動して、カスタムアクションがグリーン (移行先) バージョンのインスタンスに適用されていることを確認します。 2. ブルー (移行元) バージョンのインスタンスへの MGN エージェントのインストール パート 1 のセクション 5 の説明の通りに AWS MGN エージェントをインストールし、移行を開始します。 図 7: AWS MGN コンソールに表示される MGN サーバー移行のライフサイクル 最初のデータレプリケーションが完了すると、AWS MGN のライフサイクルは [テストの準備完了] に移行します。 [テストおよびカットオーバー] のドロップダウンメニューを選択し、テストインスタンスを起動します。AWS MGN は 自動的に変換サーバーをプロビジョニングし、グリーン (移行先) バージョンのテストインスタンスを生成します。 [起動後のアクション] のステータスで、選択した起動後アクションが正常に動作したかを確認することができます。AWS MGN エージェントや起動後アクションにてエラーが発生した場合は、 「起動エラーのトラブルシューティング」 を参照してください。 テストインスタンスを起動したら、カスタマイズした起動後アクションによりデプロイされたリソースや機能を確認するなど必要に応じてテストを行い、最終的には当ブログの最後に記載するカットオーバープロセスに進むことができます。 次のセクションでは、グリーン (移行先) バージョンのインスタンスに　AWS サービスをアタッチする別の方法として、スクリプトを使用する方法について説明します。 3. Amazon CodeWhisperer を用いた boto3 Python スクリプトの作成 このセクションでは、Amazon の Generative AI を利用したコーディング支援ツールである、CodeWhisperer を活用して、グリーン (移行先) バージョンの インスタンスに対して様々な AWS サービスや機能をアタッチするといった、シンプルで反復可能なプロセスを構築することに焦点を当てます。CodeWhisperer を IDE で利用することで、リアルタイムにコードの提案がなされるため、素早くスクリプトを構築することができます。 まず、IDE（このブログでは VS Code）を開き、 CodeWhisperer ユーザーガイド：セットアップ に従ってセットアップを完了させます。 図 8: VSCode にて新規 Python ファイルを作成 コマンドラインから実行することで、AWS リソースの操作を行えるような boto3 Python スクリプト を作成します。左側の DEVELOPER TOOLS パネルで、CodeWhisperer 自動提案がオンになっていることを確認できます。CodeWhisperer が提案するコードは、ライトグレーの部分となります。 図 9: ライトグレーの部分が Amazon CodeWhisperer による提案コード Amazon CodeWhisperer は、ユーザーがスクリプトを記述するときに、コードの一部をオートコンプリートするよう提案します。矢印キーを使用してこれらのオプションを選択し、Tab キーを押してオプションを選択し、コードを貼り付けることができます。 ここでは、Amazon EC2 インスタンスに接続するための Amazon Elastic Load Balancer と ターゲットグループ を作成し、 HTTP トラフィックのポート 80 へのアクセスを許可するようにセキュリティグループを更新 し、 Elastic IP アドレス と AWS Auto Scaling グループ を追加するスクリプトを用意します。これらのリソースにより、インスタンスへのネットワークトラフィックの送信をテストし、AWSの自動スケーリングと負荷分散機能をテストできます。その他、好きなサービスや機能を追加することができます。 図 10: ターゲットグループを作成するための Amazon CodeWhisperer による提案コード CodeWhisperer を用いて、ロードバランサーやターゲットグループを作成するスクリプトを生成しました。この要領で、他のリソースを追加したり、デタッチしたりすることもできます。 4. コマンドラインからのスクリプトの実行 スクリプトが完成したら、コマンドラインからスクリプトを実行できます。 図 11: コマンドラインからスクリプトを実行 ここで示したスクリプトが、ユースケースに適した完全なスクリプトではないかもしれませんが、ポイントは、Amazon CodeWhisperer によるオートコンプリートの提案を通じて、開発プロセスを加速できる、という点となります。例えば、HTTPS トラフィックの要件がある場合には、同様に Amazon CodeWhisperer を用いてスクリプトを作成するか、または「AWSDocs-Configure-SSL-TLS-AL2」などの SSM ドキュメントを使用して、起動後アクションを設定する方法もあります。 import boto3 # Enter your AWS credentials here. # You can find these credentials in the AWS Management Console. aws_access_key_id = input("Enter the aws access key id: ") aws_secret_access_key = input("Enter the aws secret access key: ") region_name = input("Enter the region name: ") # Start the session with your AWS credentials # and the region you want to work with. session = boto3.Session(aws_access_key_id=aws_access_key_id, aws_secret_access_key=aws_secret_access_key, region_name=region_name) #Enter your Amazon EC2 instance id and subnet id here. #You can find the instance id and subnet id in the AWS Management Console. instance_id = input("Enter the instance id: ") subnet_id1 = 'subnet-000000000000000' subnet_id2 = 'subnet-000000000000000' ec2 = boto3.client("ec2") sg_id = 'sg-04cadfeb375c5a30e' # Allocate a public IP address for the instance. eip = ec2.allocate_address(Domain="vpc") ec2.associate_address(InstanceId=instance_id, PublicIp=eip["PublicIp"]) vpc_id = ec2.describe_instances (InstanceIds=[instance_id])["Reservations"][0]["Instances"][0]["VpcId"] #Here, you create a target group for the instance and a load balancer. #The target group is used to route traffic to the instance. elbv2 = boto3.client("elbv2") target_group = elbv2.create_target_group( Name="target-group111", Protocol="HTTP", Port=80, VpcId=vpc_id, HealthCheckProtocol="HTTP", HealthCheckPort="80", HealthCheckPath="/", HealthCheckIntervalSeconds=30, HealthCheckTimeoutSeconds=5, HealthyThresholdCount=5, UnhealthyThresholdCount=2, Matcher={ "HttpCode": "200" } ) response = elbv2.register_targets( TargetGroupArn=target_group["TargetGroups"][0]["TargetGroupArn"], Targets=[ { "Id": instance_id }]) response = elbv2.create_load_balancer( Name="load-balancer-xxxxxx", Subnets=[subnet_id1,subnet_id2], SecurityGroups=[sg_id], Scheme="internet-facing", Tags=[ { "Key": "Name", "Value": "load-balancer" }]) #Lastly, you create a listener for the load balancer. #The listener is used to route traffic to the target group. elbv2.create_listener( LoadBalancerArn=response["LoadBalancers"][0]["LoadBalancerArn"], Protocol="HTTP", Port=80, DefaultActions=[ { "Type": "forward", "TargetGroupArn": target_group["TargetGroups"][0]["TargetGroupArn"] }]) #You can view the output of your instance using the public IP address provided. print(f'The public IP address of the instance is {eip["PublicIp"]}. You may now test the instance.') 5. AWS MGN にてカットオーバープロセスを完了 テストが完了したら、AWS MGN ライフサイクルの [テスト準備の完了] に戻るか、 [カットオーバーの準備完了] としてマークできます。 図 12:「カットオーバーの準備完了」に進める、または「テストの準備完了」に戻す 6. Amazon Route 53 で DNS ルーティングを更新 このシリーズの パート 1 では、ブルー/グリーンデプロイにおいて Amazon Route 53 で DNS ルーティングを使用し、必要に応じてトラフィックをブルー (移行元) バージョンとグリーン (移行先) バージョンの間で切り替える方法を学びました。これには、ネットワークトラフィックを誘導するように Route 53 のエイリアスレコードを更新することが含まれます。 クリーンアップ このブログに関連する追加料金が発生しないように、次のようなリソースを必ずクリーンアップしてください。 EC2 インスタンス すべての AWS MGN ソースサーバーを切断 Elastic IP ELB とターゲットグループ テストに関連するすべてのブロックストレージ、データベース、その他のストレージ まとめ このシリーズのパート 2 では、カスタマイズされた起動後アクションを作成する方法について説明しました。 また、Amazon の Generative AI を利用したコーディング支援ツールである、CodeWhisperer を利用する方法についても説明しました。様々な言語でスクリプトを作成し、AWS のリソースにサービスや機能をアタッチしたりデタッチしたりして、反復可能なテスト方法を作成するために、どのように役立つかを確認しました。 翻訳はソリューションアーキテクト 小宮山 裕樹 が担当しました。原文は こちら です。

本記事は 2024年1月4日に公開された ” Accelerating Blue/Green Deployments with AWS MGN Post-Launch Actions ” を翻訳したものです。 多くのお客様においてクラウド適用への方向転換が進んでおり、AWS に移行することによるメリットの認識が高まっています。 IDC が発表したホワイトペーパー には、AWS に移行したお客様は、運用コストを 51% 削減し、IT スタッフの生産性を 62% 向上させ、ダウンタイムを 94% 削減できるという数字がでています。このような状況の中、AWS は 2008 年以来、様々な組織におけるワークロードのクラウド移行を支援してきました。これは他のどのクラウドプロバイダーよりも長い実績であり、その中で多くのことを学びました。トレーニングや認定などの組織的な側面から、開発者が新しいサービスの使用方法を学ぶなどの技術的なハードルまで、AWS は移行における様々な障壁を軽減するために大きな進歩を続けています。 このブログでは、 ブルー/グリーンデプロイ の実装にフォーカスを当てた、合理的かつ効率的なサーバー移行プロセスに触れていきます。特にオンプレミス環境からクラウドへのサーバーの移行は複雑で時間がかかり、エラーが発生しやすい場合があります。従来の移行アプローチでは、多くの場合、古い環境と新しい環境をシームレスに切り替える柔軟性が欠けています。そこで、 AWS Application Migration Service (AWS MGN) と、それに関連する AWS サービスを中心に、ブルー/グリーンデプロイの原則を取り入れながら、移行プロセスをシンプルに、そして迅速化することを狙います。自動化とカスタマイズされた移行後アクションを活用することで、オペレーション負担が軽減され、ダウンタイムが最小限に抑えられ、AWS へのシームレスな移行が可能になります。これにより、企業はインフラストラクチャをモダナイズし、ブルー/グリーンデプロイを採用できるようになり、アプリケーションやサービスを安全で効率的に更新することができるようになります。 ソリューションの概要 このブログでは、主に Application Migration Service (AWS MGN) で作業し、サーバー移行のライフサイクルと MGN の 起動後アクション 機能に焦点を当てます。このソリューションでは、2 つのサーバーをブルー (移行元) バージョンとグリーン (移行先) バージョンとします。そして、2 つのリージョンで Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを使用してブルーからグリーンに移行する方法を示します。データセンターの既存のサーバーや別クラウドをソースインスタンスとして使用することもできます。 グリーン (移行先) バージョンのテストサーバーに AWS Systems Manager (SSM) エージェントが自動的にインストールされるよう MGN コンソールで起動後アクション機能を有効化します。次に、ブルー (移行元) バージョンのインスタンスに MGN レプリケーションエージェントをインストールし、初期同期が完了したら、 Amazon Elastic Compute Cloud (Amazon EC2) を使用してグリーン (移行先) バージョンの MGN テストインスタンスを起動します。テストフェーズでは、AWS のサービスや機能をグリーン (移行先) バージョンのインスタンスにアタッチし、AWS 上に構築することの利点を確かめます。テスト完了後は、MGN を用いてカットオーバーのプロセスにシームレスに進めたり、必要に応じて1つ前のプロセスに戻したりすることができます。 当シリーズの パート 2 では、このブログの内容を基に、カスタマイズした起動後アクションを作成したり、AWS の Generative AI サービスの 1 つである Amazon CodeWhisperer を利用したboto3 Python スクリプトの作成について記載します。これらを活用すれば、反復可能な移行プロセスの実現に向けて、ニーズに合わせたカスタマイズが可能となります。 ターゲットアーキテクチャ 次の図は、当ソリューションのアーキテクチャを示しています。 図 1: 提案する MGN ブルー/グリーンテストソリューションのアーキテクチャ MGN 起動後アクションのセットアップ MGN 起動後アクションの選択と設定 MGN 起動後アクション設定の完了 ブルー (移行元) バージョンのインスタンスの状態確認 ブルー (移行元) バージョンのインスタンスへの MGN エージェントのインストール 移行状態の確認 Amazon Route 53 で DNS ルーティングを更新 詳しい説明 1. MGN 起動後アクションのセットアップ 最初のパートでは、MGN で起動後アクションを使用可能にするために必要となる初期設定について説明します。 図 2: MGN 起動後テンプレート AWS コンソールを開き、グリーン (移行先) バージョンのインスタンスを起動するリージョンを選択します。 MGN を検索してサービスを開き、左側のタスクバーの [設定] で [起動後アクション] を選択します。 [編集] を選択し、 Systems Manager エージェントのインストール をトグルで有効化し、希望するデプロイオプションを選択します。 2. MGN 起動後アクションの選択と設定 次に起動後アクションの選択と設定を行います。 図 3: MGN 起動後アクションの選択と設定 選択できる 事前定義済みの起動後アクション は多数あります。まず、リストから希望のアクションを選択し、 カードビュー の横にある [編集] を選択します。これにより、選択したアクションを設定してアクティブ化できます。このデモでは、 「Create AMI from Instance」 を使用し、グリーン (移行先) バージョンのインスタンスから AMI を作成する処理を自動化します。 図 4: Systems Manager 向けの IAM ロールを選択 必要に応じて Systems Manager 向けに新しい IAM ロールを作成して、AWS アカウント内のアクセスと権限を制御します。Systems Manager 向けのロールを作成する方法の詳細については、 AWS Systems Manager のドキュメント を参照してください。 3. 起動後アクション設定の完了 機能が正常に設定され有効化されたことを確認して、起動後アクションの設定を完了します。定義済みのアクションの編集プロセスが完了したら、 [アクションを保存] を選択します。カードビューで新しいアクションを見つけ結果を確認することで、このプロセスが正常に終了したことを確認できます。なお、グリーン (移行先) バージョンのテストインスタンス起動後に取得された AMI を見つけることで正常に処理されたことを再確認できます。 4. ブルー (移行元) バージョンのインスタンスの状態確認 次に、ブルー (移行元) バージョンのインスタンスの状態を確認します。 図 5: AWS コンソールでブルー (移行元) バージョンの Amazon EC2 インスタンスを確認する EC2 のマネージメントコンソールのダッシュボードで、ブルー (移行元) バージョンの Amazon EC2 インスタンスの情報を確認できます。このブログの設定では Amazon EC2 インスタンスには、Apache Web Server、PHP、および MariaDB がインストールされています。 データベースエンドポイントは事前設定済みで、WordPress 経由のサンプル Web ページが作成されており、後工程にて、ブルー (移行元) バージョン側の変更をグリーン（移行先）バージョンに反映させる流れを検証します。 　 図 6: SSH 経由でブルー (移行元) バージョンのインスタンスに接続 — 接続方法を EC2 のマネージメントコンソールにて確認 SSH 経由でインスタンスに接続 し、必要な依存関係がインストールされていることを確認します。ブルー (移行元) バージョンのインスタンスで実行されている WordPress サイトにアクセスし、現状の表示内容を確認します。 EC2 のパブリック IPv4 アドレスにアクセスすると、WordPressサイトのブルー (移行元) バージョンが表示されます。 図 7: 移行の対象となるサンプル Web アプリケーションのブルー (移行元) バージョン 5. ブルー (移行元) バージョンのインスタンスへの MGN エージェントのインストール 次に MGN エージェントをインストールし、移行を開始します。 図 8: MGN コンソール内の MGN レプリケーションエージェントのインストール手順 AWS コンソールで MGN サービスを開き、 [ソースサーバーへの移動] → [サーバーの追加] → 表示されるプロンプトの入力を完了すると、インストーラーのダウンロードとインストールのためのコマンドが生成されるため、コピー＆ペーストしてソースサーバー (ブルーバージョン) に MGN レプリケーションエージェントをインストール します。 図 9: MGN レプリケーションエージェントのインストールの成功メッセージ 図 10: MGN コンソール、移行元サーバーの状態を表す移行メトリクス MGN のダッシュボードには、サーバー移行に関連するメトリクスが表示されます。 図 11: MGN のデータレプリケーションの状態 MGN レプリケーションの詳細な動作状況については、MGN コンソールの [ソースサーバー] でソースサーバー名を選択し、 [イベントとメトリクス] → [AWS CloudTrail イベント履歴を表示] までスクロールすることで見れます。 図 12: MGN サーバー移行のライフサイクルはテストの準備完了を示している ネットワーク帯域幅の計算ツールを使えば、初回のレプリケーションが完了するまでの待ち時間を見積もることができます。レプリケーションが完了すると、グリーン (移行先) バージョンとなるテストインスタンスを起動できます。 では、MGN コンソールからテストインスタンスを起動しましょう。 図 13: [テストおよびカットオーバー] のドロップダウンからのテストインスタンスを起動 [テストインスタンスを起動] を選択します。MGN ライフサイクルプロセスが「テストの準備完了」から「テストが進行中」に移行します。 図 14: MGN により Amazon EC2 の変換サーバーが自動的にプロビジョニングされる MGN により自動的にプロビジョニングされた 変換サーバー が Amazon EC2 のコンソールに表示されます。これにより、グリーン (移行先) バージョンのテストインスタンスが生成されます。 しばらくすると、ローンチの準備が整います。MGN のライフサイクルプロセスで、起動後アクションのステータスが 「進行中」 であることを確認する必要があります。もしそうでない場合は、ソースサーバー内の [起動後設定] タブを選択して、アクションが設定されていることを確認してください。Amazon EC2 コンソールに戻り、新しく起動したグリーン (移行先) バージョンのテストインスタンスを確認します。 図 15: 起動後アクションが実行され MGN テストインスタンスとして起動されたグリーン (移行先) バージョンのインスタンス 図 16: グリーン (移行先) バージョンのテストインスタンスのパブリック IP を開く ６. 移行状態の確認 MGN エージェントにより移行が正常に行われていることを確認した上で、MGN の継続的なレプリケーション機能も見ていきます。 グリーン (移行先) バージョンのテストインスタンスが起動したため、いくつかのテストを実行します。インスタンスへのトラフィックのルーティング、同時アクセス、加重ルーティングの実行、自動スケーリンググループによるスケールアップまたはスケールダウンの試行、そして、さまざまなサービスや機能のアタッチなどが考えられます。これは例えば、 Elastic IP 、 ターゲットグループ 、 ロードバランサー を追加し、セキュリティグループを更新してインスタンスに安全にアクセスできるようにしてみるといった内容です。 次に、ブルー (移行元) バージョンを更新して、MGN がデータを継続的にレプリケーションしていることを確認してみます。ブルー (移行元) バージョンのウェブアプリにログインし、テキストを「Blue」から「Green」に変更してみます。 図 17: ブルー (移行元) バージョンのインスタンスのウェブアプリ UI の変更 MGN の継続的なレプリケーション機能 によるレプリケーションが完了した後にグリーン (移行先) バージョンのインスタンスを起動することで、ブルー (移行元) バージョンへの変更がグリーン (移行先) バージョンに自動的に反映されていることが確認できます。 図 18: グリーン (移行先) バージョンのインスタンスのパブリック IP を開く、ブルー (移行元) バージョンへの変更は、MGNの継続的なレプリケーション機能によって行われる これでパート 1 は終わりです。 パート 2 では、カスタマイズした起動後アクションや Amazon CodeWhisperer によるスクリプト作成など、テストと移行をより詳細に制御できるように新機能や複雑さを追加していきます。 図 19: 「カットオーバーの準備完了」に進める、または「テストの準備完了」に戻す 7. Amazon Route 53 で DNS ルーティングを更新 ブルー/グリーンデプロイメントにおいては、レコード更新による DNS ルーティングが一般的なアプローチとなります。ロールバック時に、必要に応じて DNS がブルー環境とグリーン環境の間でトラフィックを切り替える必要があります。DNS ホストゾーンを Amazon Route 53 で管理していると、エイリアスレコードを更新し、トラフィックをブルー環境からグリーン環境に誘導できます。 以下の図は、Amazon Route 53 が DNS ホストゾーンを管理する方法を示しています。エイリアスレコードを更新することで、トラフィックをブルー環境からグリーン環境に誘導できます。 図 20: 一般的な移行 — ブルー/グリーンデプロイでの Amazon Route 53 の DNS 管理 あるいは、加重ルーティングを使用することもできます。Amazon Route 53 では、この方法により、グリーン環境に向けられたトラフィックの割合を定義できます。また、グリーン環境が本番トラフィックの負荷全体を処理するまで、重みを徐々に調整できる柔軟性も備えています。このアプローチにより、カナリアデプロイが容易になり、本番トラフィックのごく一部を新しい環境に導入してテストとエラー監視を行うことができます。問題が発生した場合に影響範囲を制限することができます。デプロイメントで問題が発生した場合は、DNS レコードを更新してトラフィックをブルー環境に戻すことでロールバックを実行できます。正式なカットオーバーが実行されるまで、トラフィックはブルー環境に戻されます。 図 21: 段階的な移行 — DNS 加重ルーティングを活用したデプロイの制御 クリーンアップ このブログに関連する追加料金が発生しないように、次のようなリソースを必ずクリーンアップしてください。 EC2 インスタンス すべての MGN ソースサーバーの切断 テストに関連するすべてのブロックストレージ、データベース、その他のストレージ まとめ このブログでは、AWS Application Migration Service を活用して ブルー/グリーンデプロイを実行する方法について説明しました。これには、Systems Manager を用いた事前定義済みの起動後アクションの利用も含まれます。また、異なるリージョンにある Amazon EC2 インスタンスを介して AWS への移行をシミュレートし、MGN の継続的なレプリケーション機能を検証しました。これをさらに一歩進め、実際のオンプレミスサーバーを用いてテスト移行を行うことは、このブログの内容の理解を深めるための優れた方法です。 パート 2 では、カスタマイズした起動後アクションを使用する方法と、Amazon Generative AI 機能の 1 つである Amazon CodeWhisperer を活用して boto3 Python で移行スクリプトを記述する方法を説明します。 翻訳はソリューションアーキテクト 小宮山 裕樹 が担当しました。原文は こちら です。

生成 AI は急速に基盤となるテクノロジーになりつつあり、データ合成や画像の生成、設計の最適化、プロセスシミュレーション、操業データからの洞察などを通じて、製造における大きな進歩を推進しています。Capgemini の 最近の調査 によると、製造業の大多数は生成 AI に関心があるだけではなく、55% がその可能性を積極的に探求しており、さらに 45% がパイロットプロジェクトに移行しています。この1年で、Amazon Web Services（AWS）の何千ものお客様が AWS と協力して生成 AIプロジェクトを立ち上げ、自動車および製造セクター全体で 80 を超える実用的なアプリケーションを生み出しました。この勢いの高まりは、業務効率を高め、イノベーションを促進する上で、生成 AI が果たす重要な役割を浮き彫りにしています。 ハノーバーメッセ 2024 では、AWS ブースの来場者に、製品設計の変革、生産プロセスの強化、サプライチェーン管理の改善など、業務の最適化とイノベーションの加速に向けた生成 AI の機能を体験いただきました。AWS と AWS パートナーは、 Amazon Bedrock 、 Amazon CodeWhisperer 、 Amazon Q などのサービスと、 AWS IoT SiteWise 、 Amazon Lookout for Vision 、 AWS Supply Chain などの産業用途向けサービスとを組み合わせた 25 件以上のデモンストレーションを行い、製造業が生成 AI ベースのアプリケーションを効果的に構築およびスケーリングする方法を簡単に理解できるようにしました。これらのライブデモは、AWS クラウドテクノロジーとパートナーソリューションが産業変革の未来への足がかりとなり、製造業が生成 AIの利点をどのように活用できるかを参加者に示しました。 このブログ記事では、製造業界における生成 AI の最新トレンドと、ハノーバーメッセ 2024 での事例について深く掘り下げています。実際のユースケースを探り、AWS のサービスと AWS パートナーソリューションを活用した大手メーカーの説得力のある成功事例を紹介しています。これらは、生成 AIがどのように現場での迅速なトラブルシューティングと意思決定を促進し、設備停止の平均復旧時間 (MTTR) を劇的に短縮し、生産性と製品品質をかつてないほど向上させることを示しています。 製造における生成 AI 採用の動向 生成 AI が勢いを増し、業務効率の向上とイノベーションが加速するにつれて、製造業の状況は急速に変化しています。ハノーバーメッセ 2024 では、製造業の具体的なビジネス成果を推進する上での生成 AI の役割を示すお客様事例や新たなユースケースとともに、さまざまな分野で生成 AI の影響力が高まっていることが紹介されました。このイベントでは、産業の複雑な課題をより効果的に管理することを目的とした、生成 AI と Industrial IoT(産業向け IoT) や デジタルツイン などの既存テクノロジーとの統合が強調されました。その可能性は広く認識されていましたが、業界固有の独自のトレーニングデータの必要性や既存の IT インフラとの統合など、これらのテクノロジーを大規模に実装する際の課題についても議論されてきました。こうしたハードルはあるものの、生成 AI の影響は、設計や生産準備、製造やエンジニアリングに至るまで、産業活動のバリューチェーン全体にわたって変革をもたらすと考えられています。 ここで、1つのテーマが浮かび上がってきています。それは、生成 AI の力を最大限に活用するには、堅実な最新のデータ戦略が必要だということです。 IDC によると、IT リーダーの 83% が、ビジネスデータを活用して生成 AI モデルを Fine-Tune することは競争上の大きな優位性をもたらすと回答していますが、それに必要な産業データアーキテクチャの開発を開始している組織は 30% にすぎません。AWS は、すでに製造業のデータが管理されているクラウド上に生成 AI をホストすることで、この統合を促進しています。これにより、オペレーションの俊敏性と意思決定プロセスを大幅に強化できる強力な AI ツールに簡単にアクセスできるようになります。 製造業が生成 AI 活用を深く探究するなか、セキュリティとプライバシーの懸念は依然として最優先事項です。 最近の調査 によると、データ管理、知的財産、ブランドへの影響、規制上の課題、および高いインフラストラクチャコストに関する懸念から、これらのテクノロジーを完全に採用することをためらっている企業もあります。AWS は、機密データを保護し、インフラストラクチャの経費を削減する安全なクラウド環境を提供することでこれらの懸念に対処し、生成 AI アプリケーションの開発と展開に適したプラットフォームとなっています。このセキュリティ対策により、製造業のお客様は自信を持って生成 AIソリューションを検討、実装できるようになり、重要なビジネス資産を保護しながらイノベーションを推進できます。AWSを利用することで、お客様は主要な基盤モデルへのアクセス、独自のデータでのカスタマイズを AWSの信頼あるセキュリティ、アクセス制御の元で利用でき、様々なサービスと連携することができます。 ハノーバーメッセで紹介された業界固有の生成 AI ユースケース ハノーバーメッセでの AWS のメインショーケースでは、製造のさまざまな側面にわたる生成 AI のインパクトのあるアプリケーションがいくつか紹介され、長年にわたる業界の課題に対する革新的なソリューションが提供されました。 インタラクティブな在庫動向分析: AWS ブースのメインショーケースである「 e-Bike Smart Factory 」では、製造業のお客様のサプライチェーンの専門家が行うような複雑な在庫分析を、生成AIを活用して直感的な自然言語で実行する方法が示されました。 Amazon Q in AWS Supply Chain を搭載したこのツールを使用すると、サプライチェーン管理におけるデータドリブンな意思決定をより迅速に行うことができます。 診断支援とトラブルシューティング: 「e-Bike Smart Factory」では、AWS は Amazon Bedrock と AWS IoT SiteWise も活用して、架空の電動自転車メーカーが、機器の問題を迅速に診断して解決するための 生成 AI アシスタント によって製造現場の生産性をどのように向上させたかを紹介しました。このシステムは、自然言語処理を使用して、マニュアルや標準運用手順書（SOP）などの複雑な技術文書や、リアルタイムの IoT データストリーム、その他のシステムデータを解析し、技術者が問題を簡単に特定して対処できるようにしました。 高度な欠陥検出: e-Bike Smart Factory では、 Amazon SageMaker Studio を使用して、製造業のお客様が高度な画像合成技術を実装して Amazon Lookout for Vision で機械学習モデルをトレーニングして 欠陥検出 を行う方法を紹介しました。この生成 AI アプリケーションでは、ロバストな合成画像のデータセットが作成され、製造上の欠陥を正確に分類・検出するモデルの能力が向上します。 メンテナンスとオペレーターへの作業指示: さらに、製造における生成 AI のユースケースを紹介する専用キオスクがありました。最初のユースケースでは、製造業のお客様がメンテナンスやオペレーターへの作業指示書などのシナリオで大規模言語モデル (LLM) を、Retrieval Augmented Generation (RAG) を使用してどのように活用できるか、また LLM を使用してプログラマブルロジックコントローラー (PLC) プログラムを要約したり、構造化テキストを作成したりする方法を示しました。生成 AI ワークロードをデプロイする場合のセキュリティとコストに関する事項を考慮して、このデモでは Amazon SageMaker Canvas を使用して、さまざまな LLM 間のパフォーマンスと精度の違いに焦点を当てました。 製品ライフサイクルの可視性: AWS 生成 AIキオスクの 2 番目のユースケースでは、ナレッジグラフと生成 AI テクノロジーを使用するインテリジェントなデジタルスレッドが取り上げられました。これは多くの場合、製造組織の製品ライフサイクル全体にわたる、可視性の低下、知識のギャップ、継続的な改善の困難につながる知識の分散という課題に対処することを目的としています。このデモでは、ナレッジグラフと生成 AI を組み合わせてエンタープライズシステム全体の異なるデータソースを統合し、製品ライフサイクル全体でトレーサビリティ、アクセシビリティ、コラボレーション、アジリティを促進する方法を示しました。 さらに、多くの AWS パートナーが、製造業における生成 AIの革新的なアプリケーションを紹介し、このテクノロジーが産業活動全体の効率性、可視性、最適化をどのように促進するかを実証しました。 Tulip は、コンポーネント志向のスイートにノーコードのアプリ、AI、エッジ接続を組み合わせた最前線の運用プラットフォームを展示しました。これにより、ガイド付きオペレーション、生産の追跡、リアルタイムのオペレーション可視化を通じた、プロセスをより迅速にデジタル変革を実現できます。Tulip はハノーバーメッセ 2024 で、Amazon Bedrock などのサービスを活用して生成 AI 機能を構築し、現場の作業者に力を与えるという、 AWSとの戦略的コラボレーション契約 も発表しました。これにより、Tulip のプラットフォームは LLM やその他の生成 AI テクノロジーを活用して、状況に応じた指示の提供、文書作成の自動化、問題の分析、現場での知識共有の合理化が可能になります。Tulip は、AWS の高度な AI/ML 機能を統合した AI アシスタントによって、工場での生産性、品質、従業員のエンゲージメントを強化し、人間の労働力をさらに高めることを目指しています。 Bosch Digital Twin Industries は、複数のセンサーデータ、物理学ベースのAIアルゴリズム、センシング、インサイトと自動化を組み合わせた規範的な資産管理を通じて、 重要な資産のパフォーマンスを最適化するソリューション を紹介しました。同社の生成 AI チャットボットは、ユーザーマニュアル、操作マニュアル、自然言語処理を活用して、現場のエンジニアや保守エンジニアに障害、原因、対処法、トラブルシューティングガイダンスに関する関連情報を提供します。チャットボットは、Amazon Bedrock のナレッジベース、Claude 3 の Sonnet モデル、マニュアルからの情報抽出用の Amazon Textract 、ベクターデータベースとして OpenSearch を使用して構築された、接続されたコンポーネントとその関係を示すナレッジグラフを作成します。ユーザーがプロンプトを入力すると、システムは類似性検索を通じて関連情報を取得し、ランク付けし、関連するコンポーネント接続を取得し、Bedrock 経由で LLM を呼び出します。さらに、最適な動作条件の維持、障害対策、根本原因分析、相互依存コンポーネントの確認、分解/組み立て手順、停止の予防などについての洞察を提供します。 Bosch Digital Twin のデモダッシュボード Matterport は、建物を包括的なデジタルモデルに変えるデジタルツインプラットフォームを紹介しました。彼らのデモでは、生成 AIを搭載したデジタルツインが、リアルタイムの IoT データインサイトと予知保全機能を一元的に視覚化することで、工場の運営を最適化する方法が示されました。この「単一の画面」アプローチでは、さまざまなセンサーからのテレメトリを統合し、知識ベースや履歴情報から得た知見を空間の背景に表示します。これにより、手作業を減らし、障害解決を簡素化し、予知保全の取り組みを強化できます。このデモでは、Matterport の仮想空間にマッピングされたテレメトリの 3D 空間ビジュアライゼーションを利用して、 Amazon Monitron による状況に応じた予知保全を例示しました。また、生成 AI や Amazon Bedrock などのサービスが、さまざまなナレッジベースに保存されている関連情報にアクセスして、より包括的でインテリジェントな洞察を実現する方法についても説明しました。 MongoDB は、リアルタイムのテレメトリデータ収集、音響診断のためのベクトル検索、Amazon Bedrockを使用した生成 AI を組み合わせて、機械の駆動系の状態に関するリアルタイムの自然言語レポートをユーザーに提供するデモを紹介しました。このソリューションでは、ベクトル検索を利用して音響データを分析して問題を検出し、その後、生成 AIを使用して現在の状況、トラブルシューティングガイダンス、ベストプラクティスを説明するレポートを生成します。これらのレポートには、検索拡張生成 (RAG) アーキテクチャを追加して、オペレーターノート、PDF マニュアル、独自の標準運用手順書 (SOP)、およびその他のデータソースを組み込むことができます。これにより、MongoDB は各顧客のデータコンテキストに合わせた豊富なレポートを提供できるようになり、製造現場での業務をスピードアップできます。 MongoDB のベクター検索と Amazon Bedrock を使用した音響診断と自然言語レポート Siemens グループの Mendix は、Amazon Bedrock を利用した生成 AI アプリケーションのデモンストレーションを行いました。このデモでは、Mendix Marketplace の Mendix Amazon Bedrock Connector を使用して高度な AI 機能を統合することで、企業がプロセスを合理化し、顧客満足度を高める可能性を示しました。これにより従来の複雑さが解消され、エコシステム内での生成 AI の統合を推進します。 生成 AI を活用した自然言語ベースのアプリケーション構築 ハノーバーメッセ 2024 での生成 AI のさまざまなユースケースとデモンストレーションは、このテクノロジーが生産業務にもたらす変革の可能性を示しました。インタラクティブな在庫分析や高度な欠陥検出から、インテリジェントなデジタルスレッドや予知保全まで、その用途は製造バリューチェーン全体に及んでいます。デモンストレーションでは、生成 AI がどのように製造業の可視化、データ主導の意思決定、プロセスの最適化、イノベーションの推進を可能にするかが示されました。AWS for Industrial 機能を生成 AI、ML、産業 IoT にまたがるだけでなく、クラウド内にある他システムのデータも統合することで、製造業のお客様は業務効率、生産性、俊敏性を新たなレベルに引き上げることができます。これらの実例が示すように、先進的な製造業のお客様は、クラウドベースの生成 AIソリューションの力を活用して長年にわたる産業上の課題を解決することで、すでに具体的なビジネス成果を実現しています。 生成 AI が製造業のビジネス成果をどのように促進できるか ハノーバーメッセ 2024 のメインステージに焦点を当てたセッションで、AWSの人工知能担当 Principal Strategist の Danny Smith 氏は、 生成 AI テクノロジー がどのように製造部門に統合され、大きなビジネス成果をもたらしているかを説明しました。彼は、クラウドに強固なデータ基盤を構築することが、高度な人工知能技術の時代に製造業のお客様が競合他社を上回るためにいかに役立つかを強調しました。McKinsey & Company の 最近の調査 によると、生成 AI は 経営幹部にとって最優先事項 であり、その潜在価値は年間 2.6 兆ドルから 4.4 兆ドルにのぼります。こうした可能性はあるものの、製造業はデータサイロの特定と解消、データの実用化、データ活用による成長と収益性の向上といった継続的な課題に取り組んでいます。 セッションでは、業界の専門家が、顧客体験の向上（チャットボット、パーソナライゼーションなど）、従業員の生産性の向上（コード生成、コンテンツ作成など）、ビジネスプロセスの最適化（データから洞察を取得、サイバーセキュリティの確保）を通じて、生成 AI がもたらすこれらの課題への解決策を示唆しました。この分野で活発に行われている生成 AI プロジェクトには、ガイド付きメンテナンス、ジェネレーティブスタイリング、生産計画会議の効率化、製品アシスタントなどがあり、テクノロジーの多様な用途を紹介しています。注目すべきケーススタディでは、生成 AIツールを使用してメンテナンス技術者の業務を迅速化し、知識の取得を容易にし、修理の精度を向上させ、ダウンタイムを削減する方法が示されました。 データがすでに存在するクラウドに生成 AI を導入することで、製造業のお客様は一元化されたデータストレージとリアルタイム処理機能を活用でき、即時の意思決定と業務の調整が容易になります。また、クラウドは機密データの保護と規制遵守の確保に不可欠な、強固なセキュリティ対策と国際基準への準拠が可能です。このセキュリティと、従来のオンプレミス環境と比較してクラウドインフラストラクチャのコスト削減が相まって、生成 AI はあらゆる規模の製造業のお客様にとってより利用しやすく、経済的に実行可能なものとなっています。 Danny Smith による生成 AI 活用のセッションスライド Danny は、AI イニシアチブをビジネス成果につなげるために、品質、パフォーマンス、コストのトレードオフのバランスを取ることの重要性を強調しました。AWS は、Amazon Bedrock、Amazon SageMaker、 AWS Inferentia などの特殊なハードウェアを含む、包括的な生成 AIテクノロジースタックを提供しています。また、生産性をすぐに向上させるために Amazon Q Developer から始めて、ハッカソンを通じて仮説検証を進めるよう製造業のお客様に勧めました。長期的な戦略として、 AWS Generative AI イノベーションセンター では、ユースケースを特定し、PoC (概念実証) を通じて製造業のお客様を成功に導くためのスコーピングワークショップを開催しています。 生成 AIを使用して AWS でアプリケーションの構築を開始する方法 実際のアプリケーションを中心とした顧客事例 複数の大手グローバル企業はすでにこれらの生成 AI ソリューションを実装しており、AWSのテクノロジーのメリットと変革の可能性を示されています。 KONE では Amazon Bedrock を使用してフィールド技術者に生成 AI アシスタントを提供し、膨大な技術文書ライブラリを活用してカスタマーサービスを強化しています。このツールは問題の診断と解決にかかる時間を大幅に短縮し、全体的な顧客満足度と業務効率を向上させます。 「Amazon Bedrock のおかげで、生成 AIを使って業界のユースケースを迅速に革新することができました。AWS の生成 AI機能は、複雑な技術文書やケースライブラリを活用して現場でのカスタマーサービスをスピードアップする、技術者向けの AI アシスタントのプラットフォームです」— KONE CIO Amy Chen BMW グループ は Amazon QuickSight の Amazon Q による対話的なダッシュボード生成を活用して、リージョンのサプライチェーン管理を強化しています。このツールを使うと、技術に詳しくないユーザーでも高度な分析や可視化ダッシュボードを迅速に作成できるため、市場の変化への対応力が向上し、戦略的意思決定が容易になります。 「Amazon Q を搭載した Amazon QuickSight の新しいオーサリングエクスペリエンスは、データ参照のために手を止めることなく計算を実行し、ビジュアルをすばやく作成し、ビジュアルプレゼンテーションを改良して正確なエクスペリエンスが得るために自然言語を使用できるため、時間を大幅に節約できます。リージョンのスペシャリストは、迅速な対応でビジネスユーザーに貢献し、重要な意思決定をより迅速に行うことができます」— BMW Group Data engineering and analytics expert Christoph Albrecht Merck & Co. は生成 AI を活用して、医薬品製造における不具合品流出を 50% 以上削減しています。メルクは生成 AI で欠陥画像を合成することで、MLモデルの欠陥特定能力を高め、製造プロセスを最適化し、命を救う医薬品の入手可能性を確保しています。 「私たちは、生成 AI アプローチと、GAN（敵対的生成ネットワーク）や変分オートエンコーダーなどの生成モデルを使用して、トレーニングデータが限られている複雑な欠陥の合成欠陥画像データを開発しています。得られた知見は、不良品の根本原因を理解し、プロセスを最適化し、さまざまな製品ラインにわたる全体的な不具合品流出を 50% 以上削減するのに役立ちました」— Merck & Co. ITアーキテクチャ担当アソシエイトディレクター Nitin Kaul Vivix Vidros Planos は、Mendix と Amazon Bedrock を活用したバーチャル技術者を活用して、新人技術者の研修とトレーニングプロセスを加速しています。このAIアシスタントは、パーソナライズされた問題解決の指示をリアルタイムで提供し、トレーニング時間を大幅に短縮し、業務効率を高めます。 「生成 AI のおかげで、技術者のトレーニングプロセスを数年かかっていたものが、わずか数か月に短縮できました。これにより、多くの新入社員を採用した場合でも、メンテナンス業務を効率的に拡大できます」— Vivix Vidros 産業変革マネージャー Aristotle Third Neto 結論 生成 AI は、業務を合理化し、製品の品質を高め、サプライチェーン管理を改善する革新的なソリューションを提供し、製造業を変革していることは間違いありません。ハノーバーメッセ 2024 で、AWS と AWS パートナーは、製造業のお客様が生成 AI の力を活用し、今までにない洞察を得て、プロセスを最適化したり、イノベーションを推進する方法を紹介しました。AWS は、Amazon Bedrock、Amazon SageMaker、Amazon Q、AWS Inferentia などのツールにより、生成 AIアプリケーションを既存のオペレーションに統合することをこれまで以上に容易にする幅広いテクノロジースタックを提供しています。 しかし、生成 AIの可能性を最大限に引き出すには、強固なデータ戦略、クラウドテクノロジーとのシームレスな統合、そして AI イニシアチブをビジネス成果につなげる取り組みが必要です。AWS の安全なクラウド環境と産業向けの目的に特化したソリューションを活用することで、製造業のお客様は目に見えるビジネス成果をもたらす生成 AIアプリケーションを自信を持って探し、実装することができます。 生成 AIを AWS で採用することで、急速に発展するこの業界でビジネスを常に先取りし続ける強力な新機能を活用できます。始めるには、 AWS Generative AI イノベーションセンター にアクセスして、お客様固有の業務課題に合わせた生成 AIソリューションの特定、実装、展開を AWS がどのように支援できるかをご確認ください。また、 AWS 生成 AIコンピテンシーパートナー と連携して、生産性、品質、作業現場での作業員に役立つことができる、専門的な生成 AIソリューションを見つけることもできます。 この投稿は「 The Transformative Impact of Generative AI in Manufacturing at Hannover Messe 2024 」をAWS Japan SAの岩根 義忠が翻訳しました。 著者紹介 Sophie Pagalday は、特定業界向けのサービスのポートフォリオを拡大する産業・製造部門の AWS のシニア製品マーケティングリーダーです。彼女は製品マーケティングのキャリアのほとんどを産業オートメーション、物流、サプライチェーンの分野で過ごし、エンタープライズワークマネジメントシステムからロボット工学に至るまでの幅広いテクノロジーに焦点を当ててきました。 Sophie は、お客様の理解者として、お客様が直面している課題や、当社のサービスがお客様の目標達成にどのように役立つかを伝える方法について、絶え間なく学んでいます。 Dimitrios Spiliopoulos は AW S のワールドワイド・プリンシパル IIoT GTM スペシャリストです。 LinkedIn の Top Voice であるだけでなく、インダストリアル IoT とスマートマニュファクチャリングに関する執筆や講演を定期的に行い、世界中の産業界のお客様やパートナーと連携しています。AWS で 3 年間、IoT と製造に関連するさまざまな役職を歴任してきました。彼は IoT 分野と製造部門での功績が認められ、 Manufactur.com の Top 100 製造セクター・アドボケイト賞や Onalytica の Who is Who in IoT 賞など、複数の賞を受賞しています。また、2018 年から IE ビジネススクールで IoT の非常勤教授を務めています。エッジ、IoT、デジタルツイン、AI、サステナビリティ、Industory 4.0 に関する洞察を共有することが大好きです。Linkedinで、気軽にフォローしたり、つながってください: https://www.linkedin.com/in/spiliopoulosdimitrios/

AWS Summit シーズンは世界中で盛り上がりを見せています。先週は ベンガルール 、 ベルリン 、 ソウル でイベントが開催され、ブログを執筆している私の同僚の Channy が基調講演の 1 つを行いました。 5月13日週のリリース 私が注目したいくつかのリリースをご紹介します。 Amazon S3 で複数の HTTP エラーコードについての料金が請求されなくなります – 自分が開始していない Amazon S3 API リクエストについて料金が請求され、その結果 AccessDenied エラーが発生した旨の報告を お客様から受けました 。 Amazon Simple Storage Service (Amazon S3) サービスチームは、そのような API リクエストについて課金しないようにサービスを更新しました。当然ながら、料金については正確にご理解いただく必要があります。そのため、 「最新情報」の記事で詳細をお読みください 。 Amazon EC2 C7i-flex インスタンスのご紹介 – これらのインスタンスは、C6i インスタンスと比較して、 最大 19% 優れた料金パフォーマンス を実現します。C7i-flex インスタンスを使用することで、コンピューティングを多用するワークロードの大部分について、極めて簡単に料金パフォーマンスの恩恵を受けることができます。新しいインスタンスは、AWS でのみ入手可能な第 4 世代のインテル Xeon スケーラブルカスタムプロセッサ (Sapphire Rapids) を搭載しており、C7i と比較して 5% 低い料金を提供します。 Application Load Balancer がインターネットクライアント向けに IPv6 のみのサポートを開始 – お客様は Application Load Balancer を使用することで、IPv6 のみを使用して接続できるクライアントのために、IPv4 なしでロードバランサーをプロビジョニングできるようになりました。接続するために、クライアントは Application Load Balancer に割り当てられている AAAA DNS レコードを解決できます。Application Load Balancer は、ロードバランサーとターゲット間の通信のために依然としてデュアルスタックです。この新しい機能を使用すると、IPv4 を必要としないクライアントについての IPv4 の料金を回避しながら、アプリケーションのターゲットのために IPv4 と IPv6 の両方を柔軟に使用できるようになります。 Amazon VPC Lattice が TLS パススルーのサポートを開始 – Amazon VPC Lattice の TLS パススルー の一般提供の開始を発表しました。これにより、お客様は既存の TLS または mTLS の実装を使用して、エンドツーエンドの認証と暗号化を有効にすることができます。このリリース以前は、VPC Lattice は HTTP および HTTPS リスナープロトコルのみをサポートしていました。これにより、TLS が終了し、HTTP ヘッダーの情報に基づいてリクエストレベルのルーティングと負荷分散が実行されます。 Amazon DocumentDB と Amazon OpenSearch Service のゼロ ETL 統合 – この新しい統合により、OpenSearch API を使用して Amazon DocumentDB (MongoDB 互換) ドキュメントで、あいまい検索、コレクション間検索、多言語検索などの高度な検索機能が提供されます。 AWS マネジメントコンソール で数回クリックするだけで、Amazon DocumentDB から Amazon OpenSearch Service にデータを同期できるようになりました。これにより、データを抽出、変換、ロードするためのカスタムコードを記述する必要がなくなります。 Amazon EventBridge でイベントバス用のカスタマーマネージドキー (CMK) のサポートを開始 – この機能により、AWS 所有のキー (デフォルトで使用されます) の代わりに独自のキーを使用してイベントを暗号化できます。 CMK のサポート により、イベントのセキュリティをよりきめ細かく制御できるようになりました。これにより、会社のセキュリティ要件とガバナンスポリシーを満たすことができます。 AWS のお知らせの詳細なリストについては、「AWS の最新情報」ページをご覧ください。 AWS のその他のニュース 興味深いと思われる追加のニュース項目、オープンソースプロジェクト、Twitch の番組をいくつかご紹介します。 E メールレピュテーション管理の 4 つの柱 – Dustin Taylor は、 Amazon Simple Email Service (SES) の Manager of Anti-Abuse and Email Deliverability です。Dustin は、ドメインと IP レピュテーションの管理についての Amazon SES アプローチを深掘りする注目すべき記事を書きました。高いレピュテーションを維持することで、受信者の受信箱が最適に保たれます。記事では、Amazon SES がネットワークレピュテーションを保護し、高品質の E メールを一貫して配信できるようにする方法について概説されています。大規模に E メールを送信していない場合でも、一読の価値があります。私は多くのことを学びました。 Build On Generative AI – 生成人工知能 (AI) のあらゆるトピックを取り上げる人気の 毎週の Twitch 番組 のシーズン 3 が盛り上がりを見せています。 私の同僚の Tiffany と Darko が生成 AI のさまざまな側面について話し合い、ゲストスピーカーをお招きして、そのデモをご紹介します。毎週月曜日、午前 9 時 (US PT) にストリーミング配信されます。 AWS のオープンソースに関するニュースと最新情報 – 私の同僚である Ricardo がこちらの Open Source Newsletter を毎週 執筆して、AWS コミュニティからの新しいオープンソースプロジェクト、ツール、およびデモを紹介しています。 今後の AWS イベント AWS Summits – クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントに参加しましょう。次のいずれかの最寄りの都市でご登録ください: 香港 (5 月 22 日)、 ミラノ (5 月 23 日)、 ストックホルム (6 月 4 日)、および マドリッド (6 月 5 日)。 AWS re:Inforce – 米国ペンシルバニア州で 6 月 10～12 日に開催される AWS re:Inforce で、2 日半にわたる生成 AI 時代の没入型クラウドセキュリティ学習に参加しましょう。 AWS Community Days – 世界中の AWS のエキスパートユーザーや業界リーダーが主導する技術的なディスカッション、ワークショップ、実践ラボを特徴とする、コミュニティ主体で開催されるカンファレンスにぜひご参加ください: 中西部 | コロンバス (6 月 13 日)、 スリランカ (6 月 27 日)、 カメルーン (7 月 13 日)、 ナイジェリア (8 月 24 日)、 ニューヨーク (8 月 28 日)。 今後開催されるすべての AWS 主導の対面イベントおよび仮想イベント と、 デベロッパー向けのイベント をご覧ください。 5月20日週はここまでです。5月27日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください! — seb この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

イノベーションとアジリティは、デジタル環境で優位に立ち続けるための重要な鍵であり、そのため企業はますますクラウドサービスの力を活用しようとしています。しかし、多くの組織が直面する大きな障害は、インターネット上で機密データを送受信することによるリスクです。この課題を認識し、本ブログでは、SAP Private Link が SAP Business Technology Platform (BTP) 内で AWS の標準サービスを安全かつプライベートに利用できる経路を提供する方法を探っています。このアプローチによりセキュアで制御されたネットワーク環境でイノベーションを促進することができます。 概要 AWS と SAP BTP 間のプライベート接続には、特にセキュリティに関して、いくつかの利点があります。SAP Private Link との統合により、これらの既存の AWS の機能が拡張され、セキュリティが強化されます。これには、データプライバシーが向上した AWS の AI サービスの利用、アプリケーションに対して保護されたアクセスを持つ安定したストレージの提供、制御されたネットワーク環境内での信頼できるメッセージング/通知の処理、保護された Queue を介した第三者ソリューションとの統合、外部データベースへのインターネットへの公開を行うことなくアクセスできることが含まれます。実際のコード例から、詳細を示していきます。このサービスは 2023 年 9 月 7 日に一般提供開始 され、詳細と一般情報については、「 SAP Private Link Service を使って SAP BTP サービスを AWS サービスに接続する方法 」をご覧ください。 図 1 に示されたアーキテクチャは、SAP BTP で提供される機能を Amazon Simple Storage Service (S3) などの AWS サービスを活用して拡張する方法の概略を示したものです。現時点では 多数の追加サービス が組み込まれており、今後さらに多くの統合が予想されます。一般的なユースケースとしては、ドキュメント管理、テキストと音声認識、IoT と AI/ML テクノロジーを使った予知保全、イベント管理などがあります。サンプルコードでは、Amazon S3 バケットを読み取り、それらを UI5 アプリに一覧表示できる基本的な SAPUI5 アプリケーションのワーキングプロトタイプを提供しています。 この例の焦点は、SAP BTP と AWS サービス間の統合の基礎を示すことにあります。 アーキテクチャ概要: 図 1：SAP Private Link による一般的な SAP BTP と AWS の統合 上記のアーキテクチャの主要コンポーネントは以下の通りです: 企業の ID プロバイダー (IdP) – 省略可能な要素ですが、ほとんどの企業は社内ユーザーを SAP BTP に認証するために企業の ID プロバイダーを使用しています。 SAP Identity Authentication Service (IAS): SAP のクラウド ID プロバイダー。この場合は、企業の ID プロバイダーを SAP BTP に連携させるために利用します。 UI5 アプリ: ユーザーがビジネス機能を実行するために利用するアプリケーション。フロントエンドコンポーネントであり、バックエンド (CAP アプリ) とやり取りしてビジネスロジックを処理します。 CAP アプリ: CAP とは Cloud Application Programming の略で、Node.js ベースの SAP BTP 推奨のプログラミング フレームワークです。これは、BTP と AWS コンポーネント間の操作を調整する中核のコンポーネントです。 SAP BTP Credential Store: 資格情報を安全に管理し、SAP BTP サービス (この場合は CAP アプリケーションなど) と統合する BTP サービス。今回のシナリオでは、AWS サービスとのやり取りに必要な一時的トークン (STS) を提供するために IAM が使用するキーとシークレットを格納します。 Config: 上記の概要図でのジェネリックなコンポーネント。このコンポーネントは、アプリケーションが AWS とやり取りするために必要な構成情報が格納されています。可能性としては、DB テーブル、User-provided instance、MTA Extension ファイル、環境変数などが考えられます。今回の例では、AWS リージョンと S3 エンドポイントを格納する User-provided instance を使用しています。 SAP Private Link: AWS PrivateLink と通信し、接続に必要なサブコンポーネント ( Elastic Network Interface 、VPC エンドポイント) を作成するサービス。これは BTP と AWS 間のプライベート接続用のトンネルを定義するサービス インスタンスです。最終的に、BTP から AWS にアクセスするために、アプリケーションが使用する URL によって表されます。 AWS サービス: これらは、SAP BTP が利用するサービスです。サポートされるサービスのリストについては、 SAP のドキュメント を参照してください。 私たちの事例では、アプリケーションが S3 バケットにアクセスします。 Identity and Access Management (IAM) と AWS Security Token Service (STS) は、AWS のセキュリティアーキテクチャにとって不可欠な要素ですが、アクセスと認証の異なる側面を担っています。 IAM は、AWS サービスとリソースに対する細かな権限を中央で管理するように設計されています。IAM を使用すると、管理者は誰または何 (ユーザー、アプリケーションなど) が特定の AWS リソースにアクセスできるかを定義でき、そのアクセスの範囲も指定できます。IAM では、IAM ユーザーアクセスキーのような、一貫したアクセスニーズに対応する永続的な認証情報の仕組みを提供しています。 一方、STS はリソースへのアクセスを直接管理するものではありません。代わりに、一時的で権限の限られた認証情報を発行します。これらの認証情報は、あらかじめ定義された IAM ロールまたはユーザーから権限を引き継ぎます。STS は特に、短期間のアクセスが必要な場合や、AWS の認証情報を永続的に手渡すことなく権限を付与する必要がある場合に有利です。主な例として、SAP BTP アプリなどのサードパーティアプリケーションに一時的に特定の AWS リソースへのアクセス権を付与することがあげられます。 要するに、IAM はアクセス権限の定義に注力する一方で、STS は権限に基づいて一時的な認証情報を発行することに集中しています。 上の図からは、次のようなアプリケーションの流れが見て取れます: ユーザーが BTP アプリの URL にアクセスします。 BTP は IAS 経由で企業の ID プロバイダーに認証をアウトソースし、ユーザーはクレデンシャルと多要素認証の入力にリダイレクトされます。トークンが BTP に返されます。 ユーザーが UI5 アプリにアクセスします。 UI5 アプリは AWS サービス (Amazon S3、Amazon SNS、Amazon SQS、AWS Lambda など) へのアクセス許可が必要です。 CAP アプリは BTP の資格情報ストアからキーとシークレットを取得します。 アプリはサービス構成情報を、MTA 拡張ファイル (デプロイ時)、環境変数、ユーザー提供のサービス、またはアプリケーション DB にて取得できます。 CAP アプリは、IAM キーとシークレットを使用して、AWS STS の AssumeRole API を呼び出し、一時的な資格情報を要求します。 CAP アプリはキー、シークレット、セッショントークンを使用して、AWS サービスにアクセスします。 ビジネスシナリオの例 – ドキュメント管理 SAP ビジネステクノロジープラットフォーム上で動作するカスタムアプリケーションが、ドキュメントやファイルの保存や取得のために Amazon S3 を利用するのが一般的なビジネスシナリオです。 これにより、Amazon S3 バケットに耐障害性と低コストのドキュメント管理を実現し、複数のアプリケーション (SAP ビジネステクノロジープラットフォームと AWS の両方) からアクセスできるようになります。 基本的なシナリオ: このケースでは、ユーザーが BTP アプリケーションと対話し、ファイル (金融取引の書類添付、検査のための図面、資産メンテナンスの写真など) をアップロードする必要があります。BTP アプリケーションはファイルを処理し、Amazon S3 にアップロードします。そして、ファイルの場所をアプリケーションデータベースに記録し、ファイルの取得に使用されます。 高度なシナリオ: このシナリオは、AWS サービスとやり取りするための AWS Lambda 関数を利用することで更に拡張できます。 BTP アプリは、保存が必要なドキュメントとファイルのメタデータ (つまり文書番号、場所、作成日付や担当者名など) を Lambda に送信します。 次に Lambda 関数は、 ・ファイルを Amazon S3 に保存し、 ・メタデータと S3 ファイルへの参照を Amazon DynamoDB に保存します。 添付ファイルにアクセスするには、BTP が必要なファイル (ID など) への参照を送信し、Lambda が必要なファイルと関連するメタデータを返します。 このアプローチにより、この Lambda 関数を他のアプリケーション (サードパーティアプリと AWS ネイティブアプリを含む) 間で再利用できるようになります。 前提条件 : 必要なサービス/コンポーネント SAP BTP: BTP サブアカウント (評価版または正式版): BTP サブアカウントの評価版または正式版を設定します。手順は SAP のドキュメントに従ってください。 プライベートリンク権利 ( プライベートリンクのセットアップ ): プライベートリンク権利を取得し、SAP ドキュメントの「プライベートリンクのセットアップ」のセクションに従って設定します。 Cloud Foundry ランタイム権利: SAP のドキュメントに記載された手順に従って、Cloud Foundry ランタイムを有効化します。 Cloud Foundry スペース: SAP のドキュメントの手順に従って、リソースとアプリケーション用の専用の Cloud Foundry スペースを確立します。 認証情報ストア権利: SAP のドキュメントに従い、認証情報を安全に管理するための認証情報ストアの権利を取得します。 Business Application Studio: Business Application Studio をセットアップします。あるいは、好みに応じて Visual Studio や他の互換性のある IDE を使用することができます。 AWS: AWS アカウント : 必要なサービスを利用するための有効な AWS アカウントが必要です。 S3 バケット: オブジェクトを格納する S3 バケットを指定します。 IAM ロール: AWS 内のアクションとリソースに対するアクセス権限を定義する Identity and Access Management (IAM) ロールを作成します。 シークレットキーを持つ IAM ユーザー: 認証に必要なシークレットキーを持つ IAM ユーザーを設定します。 サービス / コンポーネントのセットアップ: AWS – S3 バケットの作成 : AWS ドキュメントに従って、S3 バケットを作成します。 Amazon S3 の「アクセスポイント」セクションから、アクセスポイントを設定します。 AWS – IAM ユーザーの作成 : AWS ドキュメントに従って、IAM ユーザーを作成します。 AWS ドキュメントに従って、必要なアクセスキーを取得します。 AWS – IAM ロールを作成する 「 カスタム信頼ポリシーによる IAM ロールの作成 」の手順に従って IAM ロールを作成し、 カスタム信頼ポリシー を付与してください。 アカウント “123456789012” とユーザー “youruser” の例における 信頼ポリシー のサンプル { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "s3.amazonaws.com", "AWS": "arn:aws:iam::123456789012:user/youruser" }, "Action": "sts:AssumeRole" } ] } S3 バケットの読み取りや、必要な他のアクションを許可する 許可ポリシー を付与します。 自分のロール → 許可 → 許可の追加 をクリックします 下に許可ポリシーの例を示します。必要に応じてカスタマイズしてください。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::specific-bucket-name", "arn:aws:s3:::specific-bucket-name/*" ] } ] } BTP – Private Link サービスインスタンス (ソース SAP-samples ) 始めるには、以下のコマンドを実行して SAP Private Link サービスインスタンスを作成します: # Adjust the region in the service name if using a different region cf create-service privatelink my-privatelink -c '{"serviceName": "com.amazonaws.eu-east-1.s3"}' 注意 : このコマンドは Cloud Foundry CLI で実行する必要があります。まだインストールしていない場合は、Cloud Foundry CLI をダウンロードしてください。 代替的な方法として、BTP Cockpit を使用して Private Link サービスインスタンスを作成する場合は、サブアカウントをクリックしてから「Instances and subscriptions」をクリックします。 「サービス名」を入力し、「作成」をクリックしてください。 BTP – ユーザープロビジョニングサービスを作成する リージョンおよびバケットが保存される場所の追加設定を定義するためのユーザー提供サービスを作成します: #  adapt the properties according to your setup cf cups my-service-config -p '{"region": "eu-east-1"}' 上の例では、リージョンが定義されています。この値は後に CAP アプリケーションで取得されます。 これらのパラメータを定義する 1 つの方法は、ユーザーが提供するサービスを使うことです。ハイレベルなアーキテクチャの手順 6 で説明したように、これらの値は、さまざまな場所に保存できます。 BTP – 認証情報ストアのセットアップ 初期設定 ( SAP ヘルプ ): SAP ドキュメンテーションに詳しく記載されている必要なパラメータを設定し、初期設定から始めます。 認証情報ストアの作成 ( SAP ヘルプ ): SAP ドキュメンテーションに沿って、認証情報を管理および安全に保管する認証情報ストアを設定します。 ネームスペースの作成 ( SAP ヘルプ ): SAP ドキュメンテーションの手順に従い、リソースを隔離および分類するためのネームスペースを定義します。 AWS シークレットキーを使ったパスワードの作成 ( SAP ヘルプ ): SAP ドキュメンテーションの方法に従い、AWS シークレットキーを利用してパスワードを生成します。 手順に沿ったコードサンプル SAP BTP サブアカウント内の ビジネスアプリケーションスタジオ を起動し、標準の Node.js CAP アプリケーションを開始してください。注: サンプルアプリケーションを作成する際は、プロダクティビティツールを利用することもできます。詳細については、SAP サポートを参照してください。 下に示されている index.html ページでは、基本的なウェブアプリケーションのインターフェースを提示しています。 「Load Buckets」ボタンがクリックされると、loadBuckets() 関数がトリガーされます。 この関数が起動すると、/catalog/Buckets API エンドポイントに GET リクエストを送信し、バケットに関連するデータを取得します。 データが取得されると、ページ内の指定されたコンテナにバケットごとにフォルダを動的に生成して表示します。 各フォルダはバケットを視覚的に表し、その ID と作成日を表示します。 <! DOCTYPE HTML > < html > < head > < meta http-equiv = " X-UA-Compatible " content = " IE=edge " /> < meta http-equiv = " Content-Type " content = " text/html;charset=UTF-8 " /> < title > App </ title > </ head > < body > < h1 > Business Application </ h1 > < h1 > Buckets </ h1 > < button class = " button " onclick = " location.href= ' /catalog/ ' " > Catalog </ button > < br /> < button class = " button " onclick = " location.href= ' /catalog/$metadata ' " > Metadata </ button > < br /> < button class = " button " onclick = " loadBuckets() " > Load Buckets </ button > < div id = " folder-container " > </ div > < script > function loadBuckets ( ) { // Make a GET request to the API fetch ( '/catalog/Buckets' ) . then ( response => response . json ( ) ) . then ( data => { // Create a folder for each bucket in the data const folderContainer = document . getElementById ( 'folder-container' ) ; data . value . forEach ( bucket => { const folder = document . createElement ( 'div' ) ; folder . classList . add ( 'folder' ) ; folder . innerHTML = ` <i class="fa fa-folder"></i> <p> ${ bucket . id } </p> <small> ${ bucket . created } </small> ` ; folderContainer . appendChild ( folder ) ; } ) ; } ) . catch ( error => console . error ( error ) ) ; } </ script > </ body > </ html > HTML 下記の srv/catalog-service.cds ファイルは、CAP アプリケーションのバックエンドコンポーネントとして機能します。 その中に「 Buckets 」という名前のエンティティがあり、 id 、 name 、 created というフィールドで構成されるデータ構造を定義しています。 このエンティティのデータは、同梱の catalog-service.js スクリプトから取得されます。 さらに、{ CatalogService as my } のようなインポートエイリアスが catalog-service からの関数やエンティティを参照するために使用されています。CatalogService は /catalog パスにマッピングされており、getBuckets() 関数が “Buckets” エンティティの配列を返すようになっています。 このセットアップは、本質的に CAP アプリケーションのデータモデルとサービスエンドポイントを確立し、バケット関連データの取得を可能にします。 using { CatalogService as my } from './catalog-service'; service CatalogService @(path : '/catalog') {    entity Buckets {      key id: String ;      name: String ;      created: DateTime ;   }    function getBuckets() returns array of my.Buckets ; } srv/catalog-service.js ファイルは、AWS バケット情報を取得および管理するためのバックエンドロジックを形成しています。これは srv/catalog-service.cds データモデルに付随しています。 この JavaScript コードは、主に S3 バケットサービスなど、様々な AWS サービスと対話するために AWS SDK のインポートに依存しています。 主な関数である getBuckets() は、いくつかのタスクを行います: 構成収集: まず getConfig() を介して必要な構成を取得します。この構成には、プライベートリンクサービスのホスト名、ユーザーが指定したリージョンの詳細、クレデンシャルストアからの長期アクセスキーが含まれます。 STS 資格情報: これらの構成を利用して、getSTSCredentials() 関数を使って AWS のセキュリティトークンサービス (STS) から一時的なセキュリティ認証情報を取得します。 S3 クライアントの初期化: 取得した一時的な認証情報を使って、getS3Client() 関数で S3 クライアントを初期化します。このクライアントはプライベートリンクホストエンドポイントを使用するため、AWS のプライベートネットワークを経由して接続します。 バケット一覧: 最後に、ListBucketsCommand を呼び出して S3 バケットの一覧を取得します。成功した場合はバケットをコンソールに記録して返し、失敗した場合は発生したエラーをキャプチャしてログに記録します。 このコードは、複数の機能を統合しています。AWS の STS によるセキュアでの短期認証情報の発行、S3 サービスによるバケット操作、そしてユーザーが提供したデータと内部サービスの両方から取得した設定に依存しています。 import  { fromIni } from "@ aws-sdk/credential-provider-ini"; import { ListBucketsCommand, S3Client } from "@ aws-sdk/client-s3"; import cfenv from 'cfenv'; import { readCredential, readCredentialValue } from './lib/credStore.js'; import AWS from 'aws-sdk'; import Config from './config.js'; export default async function() {    this.on('READ', 'Buckets', async (req) => {      const buckets = await getBuckets();      return buckets ;   }); const getBuckets = async () => {    const config = await getConfig();   //Getting temporary STS credentials    const STScredentials = await getSTSCredentials(config, 'arn:aws:iam::6205:role/S3Read', 'MySession');   // Calling getS3Client    const s3Client = getS3Client(config, STScredentials);       const command = new ListBucketsCommand({});    try {    const { Owner, Buckets } = await s3Client.send(command);    console.log(    ` ${ Owner.DisplayName } owns ${ Buckets.length } bucket ${      Buckets.length === 1 ? "" : "s"   }:`   );    console.log(` ${ Buckets.map((b) => ` • ${ b.Name } `).join("\n")} `);    return Buckets ;   } catch (err) {    console.error(err);    return [] ;   }   };   async function getConfig() {      const config = new Config();          // Private-link      const myPrivatelinkCreds = await getCfEnv().getServiceCreds('my-privatelink');      const host = myPrivatelinkCreds.hostname.replace(/^\ * \./, '');      config.setEndpointHostname(host);     // Getting region defined in user-provided, Can be used for more params as needed        const s3ServiceCredentials = await getCfEnv().getServiceCreds('my-service-config');      config.setRegion(s3ServiceCredentials.region);          //Credential Store      const credaccessKeyId = await credStore.readCredential('app', 'password', 'accessKeyId');      const credsecretAccessKey = await credStore.readCredential('app', 'password', 'secretAccessKey');      config.setAccessKeyId(credaccessKeyId.value);      config.setSecretAccessKey(credsecretAccessKey.value);      return config ;   }    function getSTSCredentials(config, roleArn, roleSessionName) {     // Set the AWS region and credentials using long-term access and secret keys      AWS.config.update({        region: config.getRegion(),        accessKeyId: config.getAccessKeyId(),        secretAccessKey: config.getSecretAccessKey()     });         const sts = new AWS.STS();         const assumeRoleParams = {        RoleArn: roleArn,        RoleSessionName: roleSessionName     };         return new Promise((resolve, reject) => {        sts.assumeRole(assumeRoleParams, (err, data) => {          if (err) {            reject(err);         } else {            const credentials = data.Credentials ;            resolve({              accessKeyId: credentials.AccessKeyId,              secretAccessKey: credentials.SecretAccessKey,              sessionToken: credentials.SessionToken           });         }       });     });   }          function getS3Client(config, credentials) {     // Set the AWS region and credentials using the temporary credentials      AWS.config.update({        region: config.getRegion(),        credentials: {          accessKeyId: credentials.accessKeyId,          secretAccessKey: credentials.secretAccessKey,          sessionToken: credentials.sessionToken       }     });          // Set the S3 endpoint      const endpoint = `https://bucket.${ config.getEndpointHostname()} ` ;      const s3Endpoint = new AWS.Endpoint(endpoint);     // Create a new instance of the S3 service client      const s3Client = new AWS.S3({ endpoint: s3Endpoint });      return s3Client ;   }       function getCfEnv() {      return cfenv.getAppEnv();   } } 概要 SAP Private Link for AWS は、SAP BTP と AWS サービス間のプライベート接続を提供します。 このブログに含まれるステップとコードスニペットは、SAP BTP の提供するビジネスプラットフォームと AWS の提供するイノベーションサービスの両方を活用し、SAP Private Link と一時的な認証情報を利用したセキュアな認証を用いて、この環境を実装するための基盤となります。 これで、このブログのコード例を使用して、BTP アプリケーションと AWS を安全に接続することができます。 SAP PrivateLink for AWS の詳細については、 SAP BTP で Amazon Web Services を利用する方法 のガイドをご覧ください。 翻訳は Partner SA 松本が担当しました。原文は こちら です。

2024/4/22-26にドイツ ハノーバーで開催された世界最大規模の製造業展示会Hannover Messe 2024。AWSブースには多くのお客様が来場され、日本からのお客様には私たち AWS Japanの製造業担当スペシャリスト、営業、ソリューションアーキテクト等も現地でご説明しました。 このブログでは現地でのご説明を再現する形で、AWSブースの概要とソリューション、そして日本のお客様から反響をご紹介します。ITに関わっているかただけでなく、製造業の現場で活動されている方もぜひご覧ください。 AWSブース全体像 写真1: AWSブース全景 これがAWSブースの全景です。中央上部のデータレイクが、製造業の5つの技術エリアである「Production & Asset Optimization（生産と資産の最適化）」「Smart Products（スマートプロダクト）」「Supply Chain（サプライチェーン）」「Engineering &Design（エンジニアリングとデザイン）」「Sustainability（サステナビリティ）」とつながっていることを示しています。中央には e-Bike（電動自転車）の製造ラインを再現した、スマートマニュファクチャリングのデモがあり、各エリアではこのデモを実装しているAWSサービスやパートナー様のプロダクトを解説するキオスクが用意されています。AWSが提供するキオスクが14であるのに対して、Siemens様をはじめとするパートナー様のキオスクは35あります。AWS上で提供される各種パートナーの製造業向けソリューションにについての解説も活発に行われていました。 スマートマニュファクチャリング: e-Bikeデモ 写真2: e-Bikeデモ全景 最も目立っていたこのデモは、e-Bikeのフレームの、溶接、塗装、外観検査を行う実際の生産ラインを模しています。この中でパートナーのソリューションとAWSのサービスをどう組み合わせて生産ラインをデジタル化していくのか具体的に示していました。 写真3: Monitron センサー 写真4: Monitron ゲートウェイ 写真2 の手前のコンベアをよく見ると、モーターに黄色い機器が取り付けられています(写真3)。これが Amazon Monitron のセンサーです。モーターの振動と温度のデータを取得して、機械学習により予知保全を可能とします。これは工場等へ設置しやすいよう無線(bluetooth)で通信し、電池で駆動します。写真4がゲートウェイデバイスで、これでセンサーからの情報を収集しアラートを通知します（写真2 の右側、黒いAWSのロゴの下の方に設置しています）。eBikeデモ全体(写真2)の上部右側の画面に表示されているのが、Monitronが取得した振動情報を表示したダッシュボードです。Amazon、Amazon Business、あるいはパートナー様から購入でき、容易に予知保全を実現できるMonitronは多くの日本のお客様の注目を集めていました。 写真5: デジタルツインによるテレメトリデータの表示 eBikeデモ全体(写真2)の上部左側のダッシュボードは生産ラインの3Dイメージにオーバーレイして、溶接ステーション、塗装ステーション、そしてライン全体のリアルタイムテレメトリデータが表示されており、リモートからでも工場の様子を視覚的に理解できます。このデジタルツインは、Matterport社のプロダクトで生成した3Dイメージと、 AWS IoT TwinMaker によって実現しています。 写真6: e-Bikeデモの全景　溶接・塗装ステーション側（写真2の反対側） 反対側に回ると右側に溶接ステーション、左に塗装ステーションがあります。これらのロボットアームや、レーザー距離計から得られたデータは、OPC UAやMQTTといった標準のプロトコルで AWS IoT GreenGrass がインストールされたゲートウェイデバイスに送られます。 写真7: e-Bike生産ラインの機器状態および生産性ダッシュボード さらにそのデータはゲートウェイから AWS IoT SiteWise に送られ、写真6の上方右側の Amazon Managed Grafana(AMG) によって作られたダッシュボードに表示されます。ダッシュボードではこれらの機器のリアルタイムテレメトリに加え、生産台数や生産速度などの情報を表示しています。 生成AIを活用した問題解決チャット画面例（写真6の上方左側に表示されている） 写真6の上方左側のダッシュボードには、アラームと、生成AIを活用した問題解決のためのチャット画面が表示されています。これはロボットハンドでエラーが発生した際に、生成AIを使用してオペレータに対して原因や対応方法を指示している画面です。実際はハンディ端末などに表示することを想定しており、用意された質問（「根本原因はなにか？」など）を選ぶことで期待する情報を引き出せるようになっています。生成AIを使ってオペレータによる対応の迅速化を支援することは生産ラインの停止時間短縮につながるため、直接的な効果が期待できそうだとの声を複数伺いました。このデモの詳細については ブログ「 The Transformative Impact of Generative AI in Manufacturing at Hannover Messe 2024 」で動画を紹介していますのでご覧ください。 写真8: 外観検査ステーション 最後が外観検査です。カメラで撮影した画像を使って塗装や溶接の不具合を検出します。これはコンピュータビジョンを使って欠陥製品を検出するDenali社の Automated Quality Inspectionソリューションによって実現しています。このソリューションは Amazon Lookout for Vision(L4V) を利用しており、製造ラインでの検査高速化のため、L4Vのモデルをクラウド上でなくエッジ（工場内）で動作することで低遅延の処理を実現しています。Lookout for Visionは数十枚程度の画像で正常/異常を判定する機械学習モデルを作成できるという点も、来場者の方の注目を集めていました。 以上が e-Bike スマートマニュファクチャリング デモの全体像と個々の技術要素の概要でした。より詳しい解説と動画がブログ「 Hannover Messe 2024: AWS Unveils Purpose-Built “e-Bike Smart Factory“ Showcase 」にありますのでこちらもご覧ください。 生産と資産の最適化: 生成AI 写真9: 装置のマニュアルを読み取って生成AIで解説 写真10: フィッシュボーンチャートを読み取って生成AIで解説 生産と資産の最適化エリアに設置された生成AIのキオスクでは、e-Bikeデモで紹介した生産ラインのアラートの原因究明の仕組みについて解説していました。ロボットアームのマニュアル群を検索し、その結果を Amazon Bedrock （基盤モデルとして Claude 3 Sonnetを使用）でサマリして表示、オペレータとコミュニケーションできるように実装しています。ここではフィッシュボーンチャートを Claude 3 で解説するデモも行っていました。 写真11: デジタルスレッドの概念 写真12: ナレッジグラフによるデジタルスレッドのデモ さらに興味を持っていただいていたのは「Digital Thread（デジタル スレッド=デジタルの系）」です。デジタルスレッドはPLM(Product Lifecycle Management)、ERP(Enterprise Resource Planning)など、製造業の多様なシステムに分散している情報を紐づける概念です。このデモでは、 Amazon Neptune （マネージドのグラフデータベース）を用いたナレッジグラフによるデジタルスレッドを構築しています。ナレッジグラフの検索には一般的に特別な問い合わせ言語が必要ですが、Amazon Bedrockを使用することで、自然言語で検索できる仕組みを紹介していました。このアーキテクチャや実装方法は「 Guidance for Digital Thread Using Graph and Generative AI on AWS 」および ワークショップ用コンテンツ としてでも動画付きで公開しています。 ハノーバーメッセでのAWSの生成AI展示に関してはブログ「 The Transformative Impact of Generative AI in Manufacturing at Hannover Messe 2024 」にも詳しい情報がありますので、ぜひご覧ください。 スマートプロダクト: コネクテッド プロダクト 写真13: 生成AIと機械学習を用いた PPE検出と危険モニタリングのデモ スマートプロダクトのエリアでは、工場や倉庫などに設置するカメラで、作業員の安全装具(PPE)の装着状況や作業員が危険な状況にいるかどうかを、映像を元に判定する展示がありました。カメラでは機械学習モデルを動かし、人が写っている場合のみ画像をクラウド側へ送ります。クラウド側では送られた画像に対して2つの処理を行っています。一つは Amazon Rekognition を使って「転倒」「事故車両」などキーワードベースの物体認識を行うもの。もう一つはAmazon BedrockのClaude 3 を使って、安全装具の装具状況を事前に定めた書式の文章で報告しています。事前学習により決まった物体を認識するAIはこれまでも利用されてきましたが、生成AIを追加で使うことによって追加学習することなく事故の状況を推測して自然言語で説明できるということが来場者の注目を集めていました。 エンジニアリングとデザイン: 製品の設計とシミュレーション 写真14: エンジニアリングとデザイン キオスク エンジニアリングとデザイン（製品の設計とシミュレーション）エリアでは、大きく3つの展示がありました。まず、Simens様、Ansys様、Dassault Systems様などパートナー様のプロダクトとAWSのサービスを組み合わせてシミュレーションの環境を迅速かつセキュアに構築・管理する際の、リファレンスとなるアーキテクチャ（中央）が紹介されています。そして右側には昨年11月に発表した Reasearch and Engineering Studio on AWS (RES) のデモが展示されており（右）、エンジニアが必ずしも計算環境構築のスキルを持たずとも、様々なシミュレーションの環境を容易に切り替えて設計開発を行えることを紹介していました。さらには、機械学習を使ってシミュレーション量を減らすデモを紹介していました（左）。同様のユースケースはブログ 「 Using machine learning to drive faster automotive design cycles 」にも記載されています。 サステナビリティとサプライチェーン ハノーバーメッセでは、環境問題とサステナビリティに関して強い関心をお持ちのお客様が多くブースを訪れていました。AWSのサステナビリティのエリアでは、次のようなデモやガイダンスを紹介していました。 企業が持つ多様な情報から、カーボンフットプリントに関する情報を集約し、可視化するためのフレームワークである「 Guidance for Building a Sustainability Data Fabric on AWS 」 バッテリーの循環型経済 (Battery Circular Economy) 実現のため、利用者から生産者までを含めて状況の可視化を実現するデモである「Battery Circular Economy Networkデモ」 写真15: Guidance for Building a Sustainability Data Fabric on AWSのデモ 写真16: Battery Circular Economy Networkデモ サステナビリティに関連してサプライチェーンも注目されていました。企業は、スコープ 1（直接排出）、スコープ 2（購入エネルギーからの間接排出）、スコープ 3（その他すべての間接排出）の炭素排出量を可視化するために、サプライヤーやパートナーからサステナビリティに関するデータやコンプライアンス成果物を要求・収集・監査する必要があります。AWSからはガイダンスとしてその実装例を紹介すると同時に、AWSのマネージドサービスである AWS Supply Chain も展示しており、ドキュメントの要求や管理といった機能で注目を集めていました。 写真17: AWS Supply Chainの画面イメージ（Amazon Qを使った自然言語による分析を行っている） 写真18: AWS Supply Chainのハイレベルアーキテクチャ AWS Supply Chain はサプライチェーンの状況を可視化し在庫リスク等を分析するサービスです。製品の生産実績、サプライヤからの供給実績の可視化に加え、機械学習を使用した需要・供給予測も可能であり、季節変動など多様な条件を指定することで、状況に適した予測も可能です。会場では今後実装予定の自然言語を使った分析（Amazon Qを使用）のデモも展示されていました。AWS Supply Chainならではの特徴としては、複数の既存ERPデータソース（SAPやデータレイク上のファイル）に対し、後付けで、かつ従量課金で利用可能であるため、既存環境への影響を小さくしつつ迅速に分析を試すことができるという点がありますが、多くのお客様が強い関心を示されていました。 ハノーバーメッセでのサステナビリティの展示についてはブログ「 ハノーバーメッセ2024でサステナビリティが主役に 」でも詳しく述べていますのでご覧ください。 まとめ ハノーバーメッセ2024 AWSブースの様子を体感いただけましたでしょうか。このブログではAWSのサービスを中心にご紹介しましたが、製造業でのAWSについてはこちらのブログでも引き続き情報提供していきますので、今後もご注目ください！ 日本のお客様向けには、6/20-21に幕張メッセで開催されるAWS Summit Japan にて、製造・自動車業界向けの実機デモを多数展示する他、お客様事例を交えたブレイクアウトセッションも予定しています。 こちらから無料で登録可能 です。ぜひご参加ください。 今回の内容についてより詳しく知りたい場合は、本ブログのURLを添えて担当営業または こちらのフォーム よりお問い合わせください。 このブログは製造業担当のソリューションアーキテクトマネージャ 大村幸敬 が担当しました。

本記事は、2024年5月17日に公開された  Binary logging optimizations in Amazon Aurora MySQL version 3 を翻訳したものです。 MySQLの バイナリログ (binlog)は、MySQLサーバ上のデータベースの変更を”イベント”と呼ばれる論理フォーマットでキャプチャするために使用されます。これらのデータベース変更には、DCL(CREATE USERやGRANTなど)、DDL(CREATE TABLE、ALTER TABLEなど)、DML(INSERT、UPDATE、DELETEなど)が含まれます。そのような変更がMySQLでコミットされると、サーバは 2-phase commit(2PC)を用いてトランザクションのバイナリログイベントをストレージエンジンのコミットをアトミックに永続化します。ACID (原子性、一貫性、独立性、永続性)準拠とデータベース変更のログ記録によって、他のMySQLサーバ(ReadReplica)への論理レプリケーションを容易にし、データベースの復旧プロセスを支援し、フルデータベースバックアップの上に論理的な変更を再適用することで特定の時点までデータベースインスタンスを復元できるようになります。 しかし、この ACID 準拠を強制すると、書き込みの量の増加、データベース復旧時間の長期化、高い並列度でクエリが実行されている環境でのロック競合など、追加の負荷がかかる可能性があります。特定時点への復元(PITR)やReadReplicaを使った水平スケーリングの場合、バイナリログをデータベースサーバに論理的に適用する必要があり、大量の書き込みワークロードの下ではレプリケーションラグが発生し、目標復旧時間(RTO)が長くなる可能性があります。例えば、DDL文をReadReplicaやスタンバイデータベースサーバに複製する必要がある場合、完了するまでその他のログイベントの適用がブロックされます。 2015年に Amazon Aurora MySQL互換エディション がリリースされると、お客様はこれらの要件を満たすためにバイナリログを利用する必要がなくなりました。カスタムビルドされた Amazon Aurora ストレージアーキテクチャでは、レプリケーション、リカバリ、PITRがすべて透過的にストレージレイヤで処理され、バイナリログを有効にする必要がありません。これらの革新的な技術により、リカバリ時間やACID準拠を犠牲にすることなく、高い並行ワークロードをアベイラビリティーゾーンやAWS リージョン間でミリ秒のレプリケーションラグでスケーリングできるようになりました。 この記事では、Amazon Aurora MySQLでのバイナリログの使用例、これまでにAmazon Aurora MySQLに追加されたバイナリログ機能の強化、さらにはMySQLネイティブのバイナリログ機能のサポートについて説明します。 バイナリログの使用例 Amazon Aurora MySQLでは、高可用性や水平スケーラビリティのためにバイナリログは必要ありませんが、以下のようなバイナリログを利用したユースケースがあります： Amazon Aurora MySQL に移行する場合、バイナリログレプリケーションを利用して、Amazon Aurora MySQL を MySQL データベースインスタンスのレプリカとして構成することで、ダウンタイムを最小限に抑えた移行を行うことができます。詳しくは、 Amazon Aurora MySQL DBクラスタへのデータ移行 を参照してください Amazon RDS Blue/Green デプロイメント では、論理的なバイナリログレプリケーションを使用して、メジャーバージョンアップグレードなどの本番システムへの変更を最小限のダウンタイムで行う Amazon Aurora zero-ETL integration with Amazon Redshift 、または Maxwell や Debezium などのツールを使用して、Aurora MySQLデータベースクラスタからキャッシュ、データウェアハウス、データレイクなどの他のソースにデータベースの変更をストリーミングする Spirit や gh-ost などのオンラインスキーマ変更ツールを使用すると、アプリケーションへの影響を最小限に抑えながら、本番システムにスキーマ変更をデプロイする バイナリログ機能の向上 Amazon Aurora MySQLチームは、長年にわたるお客様の使用事例とフィードバックに基づき、追加のコミュニティ機能のサポートを通じてバイナリログ機能を追加し、スケーラビリティの高い分散Auroraストレージを活用して Amazon Aurora MySQL におけるバイナリロギングの実装を最適化してきました。以下の各リリースでは、4つの主要な領域でバイナリロギングの効率とパフォーマンスを改善するために様々な変更が行われています。 Binary log replication consumer threads Amazon Aurora MySQL バージョン 2.10 で、 binary log I/O cache を導入しました。binary log I/O cache は、書き込みDBインスタンス上の循環キャッシュ内に最新のバイナリログ変更イベントを保持することで、Aurora ストレージレイヤからの読み取り I/O を最小限に抑えることを目的としています。この I/O 待ち時間の改善により、レプリケーションコンシューマスレッドが変更ログイベントを取得する速度が向上し、特に高い同時実行書き込みワークロード下で、フォアグラウンドトランザクションとバイナリログコンシューマが アクティブなバイナリログファイルのロックを競合する可能性を低減します。これらの改善の詳細については、 Introducing binlog I/O cache in Amazon Aurora MySQL to improve binlog performance を参照してください。 前述したように、バイナリログの一般的なユースケースの1つは、Aurora MySQL データベースクラスタからデータウェアハウスなどの他のソースにデータベースの変更をストリーミングすることです。Amazon Aurora MySQL バージョン 3.05 では、Amazon Aurora zero-ETL integration with Amazon Redshift をリリースしました。この機能により、ペタバイト単位の transactional データに対して Amazon Redshift を使用したリアルタイムアナリティクスとマシンラーニング (ML) が可能になります。トランザクションデータが Aurora に書き込まれてから数秒以内に、そのデータを Amazon Redshift で利用可能にし、抽出、変換、ロード (ETL) 操作を実行する複雑なデータパイプラインを構築およびメンテナンスする必要がなくなります。Amazon Aurora zero-ETL integration with Amazon Redshift を使用すると、 Maxwell や Debezium などのツールを使用して変更データキャプチャインフラストラクチャをセットアップおよび構成する必要がありません。Amazon Aurora MySQL が自動的に変更データキャプチャインフラストラクチャをセットアップ、構成、管理し、変更をAuroraストレージレイヤから直接Amazon Redshiftデータウェアハウスにストリーミングします。 Binary log replication applier threads Amazon Aurora MySQLバージョン3.05では、Amazon Aurora MySQLのバイナリログレプリカにインメモリ リレーログ キャッシュを導入しました。この改善により、 リレーログ キャッシュを有効にしていないデータベースクラスタと比較して、バイナリログレプリケーションのスループットが最大40%向上します。この機能強化は、シングルスレッドのバイナリログレプリケーションを使用する場合、または GTID auto-positioning を有効にしてマルチスレッドレプリケーションを使用する場合に自動的に有効になります。 Amazon Aurora MySQL バージョン 3.06 以降では、2 つ以上のセカンダリインデックスを持つ大きなテーブルのトランザクションをレプリケートする際に、バイナリログレプリケーションのパフォーマンスを向上させる最適化を導入しました。この機能は、Aurora MySQL バイナリログレプリカでセカンダリインデックスの変更を並列に適用するバックグラウンドスレッドのプールを導入し、レプリケーションアプライヤスレッドですでに利用可能な replica_parallel_workers を補足します。この最適化に関する詳細については、 バイナリログレプリケーションの最適化 を参照してください。 DML throughput and latency バイナリログのコミットプロセスを最適化するために、MySQL は バイナリロググループコミット など、イベントの順序に影響を与えず、より効率的にバイナリログに変更を書き込むための最適化を多数実装しています。しかし、この同期ポイントは、高い書き込みスループット作業負荷を持つDBインスタンスに競合領域をもたらす可能性があります。 Amazon Aurora MySQL バージョン3.03.1では、 Amazon Aurora MySQL enhanced binary log (拡張バイナリログ)を導入しました。Amazon Aurora MySQLの拡張バイナリログは、バイナリログの変更イベントの順序をAuroraストレージレイヤにオフロードすることで、コミット順序やコミットされたトランザクションの耐久性を犠牲にすることなく、データベースエンジンがAurora分散ストレージをフルに活用してこの競合を減らすことを可能にします。 Amazon Aurora MySQL拡張バイナリログ(binlog) の紹介で概説したテストに基づくと、これらの最適化は、拡張バイナリログを有効にしていないデータベースクラスタと比較して、高い同時書き込みワークロードで最大40%のスループット向上をもたらしました。 Binary log recovery トランザクションをコミットするとき、バイナリログイベントは、アクティブなバイナリログファイルに正しい順序で書き込まれ、永続化されなければなりません。大量のバイナリログデータを生成するトランザクションの場合、起動時のバイナリログリカバリプロセスでは、トランザクションに関するメタデータを収集するために全バイナリログファイルをスキャンし、これを使ってストレージエンジン(InnoDB)データとの整合性を確保する必要があります。バイナリログファイルのサイズが大きい場合、このプロセスに数分以上かかる可能性があり、バイナリログリカバリ時間に比例して影響を与えます。 上記の Amazon Aurora MySQL 拡張バイナリログは、MySQL バイナリログリカバリプロセスのリカバリ時間も改善します。拡張バイナリログでは、Aurora 分散ストレージレイヤの最適化により、時間のかかるバイナリログファイルのスキャンを避けることができます。 これらの改善により、バイナリログリカバリ時間を最大 99% 短縮でき、数分かかっていたものが数秒で完了するようになります。以下の表に、リカバリ時間をまとめています。 Transaction size Binlog Recovery Time (Seconds) Total Engine Recovery Time (Seconds) Community Binlog Enhanced Binlog Percent Improvement Community Binlog Enhanced Binlog Percent Improvement 1 GB 303.42 0.47 99.85% 332 26 92.17% 5 GB 1,296.39 0.50 99.96% 1318 34 97.42% 50 GB 15,879.49 0.61 100% 15904 21 99.87% 詳細については、 Amazon Aurora MySQL enhanced binary log (binlog) を参照してください。 Additional MySQL support これまで説明してきたAmazon Aurora MySQL の最適化に加えて、バージョン1と2ですでに利用可能だった機能に加えて、MySQL コミュニティの機能のネイティブサポートが追加されました。 Amazon Aurora MySQL バージョン3.01.0では、バイナリログレプリケーションフィルタのサポートを追加しました。レプリケーションフィルタを使用すると、バイナリログファイルに書き込まれる内容とレプリカに適用される内容を設定できます。この機能は、特定のテーブルやデータベースをレプリカDBインスタンスにのみレプリケートするなどの使用例で役立ちます。レプリケーションフィルターの詳細については、 Aurora MySQL でレプリケーションフィルタを構成する をご覧ください。 MySQL 8では dynamic privileges が追加され、SESSION_VARIABLES_ADMIN データベース特権の下で、一部の制限されたセッション変数が利用可能になりました。Amazon Aurora MySQL バージョン3では、この特権を持つユーザは以下のことがセッションレベルで可能になります。 sql_log_bin を変更できるようになりました。これは、バイナリログに記録したくない操作、例えばアーカイブジョブやバイナリログ消費者に複製したくないDDL文を実行する場合に便利です。Amazon Aurora MySQL バージョン2ではネイティブで sql_log_bin を設定できませんでしたが、バージョン2.12で mysql.rds_disable_session_binlog mysql.rds_enable_session_binlog のストアードプロシージャが追加されました さらに、セッションレベルで binlog_format を変更できるようになりました。バイナリログには ROW、MIXED、STATEMENT の3つの形式があります。ほとんどのユースケースでは、各行の変更イベントをログに記録する ROWベースのロギングが推奨されます。しかし、アーカイブや データパージ時の一括 UPDATE/DELETE 操作では、ログが肥大化する可能性があります。もう1つの一般的なユースケースは、 pt-table-checksum などのオープンソースツールを使用する場合で、これには binlog_format を statement に設定する必要があります。binlog_format を使えば、これらの操作でネイティブにセッションレベルのバイナリログ形式を変更できます。Amazon Aurora MySQL バージョン2ではネイティブでセッションレベルの binlog_format を設定できませんでしたが、バージョン2.12で mysql.rds_set_session_binlog_format のストアドプロシージャが追加されました Amazon Aurora MySQL バージョン3.04では、 mysql.rds_gtid_purged ストアドプロシージャが追加されました。 gtid_purged システム変数は、サーバ上のどのバイナリログファイルにも存在しない、サーバ上でコミットされたすべてのトランザクションの GTID で構成される GTID セットです。これは主に、2つの MySQL データベースサーバ間のバイナリログレプリケーションの自動ポジショニングを設定する際に使用され、ユーザがレプリケーションを簡単に設定できるようになります。MySQL の GTID の詳細については、 Global Transaction Identifiers を使用したレプリケーション を参照してください。 まとめ この投稿では、過去数年間にAmazon Aurora MySQLで行われたバイナリロギングの最適化と改善について説明しました。これらの継続的な改善により、変更データを利用する新しいユースケースや、データベースのパフォーマンスとリカバリ時間を改善することができました。 Amazon Aurora MySQLの新しいリリースと機能の詳細については、 リリースノート を参照し、 RSSフィード を購読してください。 Amazon Aurora MySQL のバイナリロギングの詳細については、 Aurora MySQL バイナリロギングの設定 を参照してください。 Amazon Aurora MySQL バージョン3へのアップグレードの詳細については、 Aurora MySQL バージョン3 および Amazon Aurora MySQL バージョン3へのアップグレード を参照してください。 About the Author Marc Reilly is a Senior Database engineer on the Amazon Aurora MySQL team.       翻訳は、Principal Database SA, Aurora Product の 星野が担当しました。

生成 AI は、問題解決と支援において前例のない機能を提供し、顧客とのやり取りに革命をもたらしています。この革新的な技術は、エージェントが顧客を迅速にサポートすることで満足度を高められるコンタクトセンターの分野で特に変革をもたらします。生成 AI は、人間のようにテキストを分析して生成することで、コンタクトセンターが解決と対応を自動化し、エージェントが複雑な問い合わせをより正確かつパーソナライズして処理できるよう支援します。 ボストンコンサルティンググループ (BCG) の調査 では、生成 AI がカスタマーサービスに及ぼす大きな影響が明らかになり、その導入により効率が 30% ~ 50% 向上する可能性があることが示唆されています。 この変革をサポートするために、AWS は Amazon Q を提供開始しました。Amazon Q は企業のシステムにあるデータや専門知識を使用して、ビジネスに合わせて調整でき、会話、問題の解決、コンテンツの生成、アクションの実行を提供する生成 AI 搭載アシスタントです。Amazon Q は Amazon Connect 内で直接利用でき、同様の支援機能をコンタクトセンターに提供できます。 このブログ記事では、Amazon Q in Connect とその仕組み、生成 AI による機能を使用してナレッジベースを最適化し、効果を最大化する方法について学びます。 Amazon Q in Connect とは Amazon Q in Connect は、Amazon Connect の音声チャネルとチャットチャネルの両方でリアルタイムのエージェントアシスタンス機能を提供します。生成 AI を活用した推奨応答、アクション、詳細情報へのディープリンクにより、エージェントは顧客からの問い合わせの聞き取りと解決により多くの時間を費やすことができ、回答の検索や検索に費やす時間を減らすことができます。この機能は、組織の独自のナレッジベースのコンテンツを活用して総合的な回答を生成し、エージェントは音声またはチャットで顧客に返信できます。また、顧客からの問い合わせを解決するために取るべき手順をエージェントに概説して案内することもできます。 仕組み Amazon Q in Connect は、複数の 機械学習 (ML) ツールを使用して、回答や解決策を考え出しエージェントを支援します。まず、何千時間ものコンタクトセンターの記録を使用してトレーニングされた機械学習モデルを使用して、顧客の意図を判断します。顧客がどのような支援を必要としているかを理解すると、Amazon Q はナレッジベースをスキャンして、セマンティックマッチングと呼ばれるプロセスによって、エージェントをサポートするための関連文書を探します。このプロセスは、文書を統合し、顧客の質問に答える最も重要な部分を選び出します。 次に、特定された問題、会話の要点、およびドキュメントからの情報を取り出して、 Amazon Bedrock に渡します。ここでは、Amazon Q が具体的な指示 ( プロンプトエンジニアリング ) を行い、 Amazon Bedrock はエージェントにとって実際に役立つ回答とソリューションを作成します。これらすべてのステップで、機械学習と大規模言語モデルがリアルタイムで連携し、エージェントが必要な支援を受けられるようにするため、他の AWS サービスとの統合を自分で構築する必要はなく、コンタクトセンターで生成 AI 機能を簡単に有効にできます。 会話中の内容をモニタリングし、リアルタイムにエージェントを支援するだけでなく、エージェントは検索バーに手動で質問を入力して Amazon Q in Connect に支援を求めることもできます。これにより、エージェントはナレッジベースを調査し、文書を探したり解析する必要なく、自然言語での会話で必要な回答を得ることができます。エージェントはコンタクトの対応中でも対応していないときでも手動検索機能を使用できます。そのため、アフターコール作業 (ACW)、バックオフィス作業、またはフォローアップタスクを行うエージェントも Amazon Q in Connect を利用できます。 図1. Amazon Q in Connect の仕組み コンタクトセンター業務のニーズの理解 Amazon Q in Connect のコンテンツをより最適化するには、コンタクトセンター内の具体的なニーズと一般的な問い合わせ内容を深く理解することが不可欠です。これらを理解することで、ナレッジベースに含めるべきコンテンツの特定に役立つだけでなく、顧客がエージェントに質問する内容とコンテンツを一致させることができます。 Amazon Connect には、コンタクトセンターを深く掘り下げるのに役立つ Contact Lens などの機能が用意されています。Contact Lens はコンタクトセンターの会話分析機能を備えているため、Amazon Connect 内でネイティブに、顧客との会話の書き起こし、生成 AI を活用した問い合わせの要約の作成、顧客センチメントの分析、主要なコンタクト要因の発見、機密データの除外などを行うことができます。 Contact Lens からの洞察を定期的に確認することで、Amazon Q in Connect が顧客から問い合わせを受けている重要なトピックに効果的に対応できるようになります。特に重要な機能は テーマ検出 で、顧客とのやり取りから浮かび上がる共通のテーマやトピックに関する価値のある洞察が得られます。 テーマ検出を活用することで次のことが可能になります。 一般的な問い合わせの特定 : よくある質問や顧客から寄せられる問題を特定できます。これにより、顧客の質問に対応できるようコンテンツを調整するのに役立ちます。 顧客の感情の理解 : 顧客の問い合わせ中の感情を測定することで、顧客の不満や、エージェントがさらなる支援を必要とする可能性のある領域をより深く理解できます。これにより、どのコンテンツを最初に更新すべきかを優先順位付けできます。 新たなトレンドの発見 : 新規または増加している顧客のニーズや質問を特定して、事後ではなく事前にナレッジベースに反映することができます。これにより、エージェントを支援する新しいコンテンツの優先順位付けに役立ちます。 顧客とエージェントに最大の効果をもたらすためには、コンテンツを定期的に見直して更新し、関連性が高く、最新で、包括的であるよう維持する必要があります。トピックに関する正確な情報がなければ、Amazon Q in Connect は適切なガイダンスを提供できません。 さらに、エージェントからのフィードバックを統合することも、ナレッジベースを洗練させる上で重要です。エージェントは、受け取ったレコメンデーションに「役に立った」または「役に立たなかった」のアイコンを使用して直接フィードバックを提供できます。これにより PutFeedback API をトリガーし、推奨事項が役に立ったかどうかが示され、 AWS CloudTrail で追跡することができます。このフィードバックは、追加の情報や明確化によってコンテンツのリソースと効果をさらに向上させ、エージェントと顧客の両方にとってより価値のあるコンテンツになる可能性がある点について、独自の視点を提供します。 ナレッジベースのコンテンツの最適化 Amazon Q in Connect を最大限に活用するには、コンテンツを最適化することが重要です。人間が理解するのが難しいコンテンツは、AI に対しても同じ課題をもたらし、エージェントを支援する能力に影響を与えます。既存のコンテンツを改良して Amazon Q in Connect で利用しやすくするための戦略をいくつかご紹介します。 コンテンツの構造化 適切に構造化されたコンテンツは、Amazon Q in Connect がエージェントに的確な回答を提供するのに役立ちます。長いセクションを 1 つのアイデアを中心とする短く焦点を絞った段落に分割し、必要に応じて箇条書きや番号付きリストを使用して複雑なプロセスを明確なステップに分割することを検討してください。 言葉遣いをシンプル・明確に 複雑な語彙や文構造を使わずに、明確かつ簡潔に書くようにし、大まかで曖昧な記載は避けてください。Amazon Q in Connect とエージェントにとっては、平易でわかりやすい文章の方が理解しやすくなります。 ビジュアルに補足説明を付加 ドキュメンテーションで参照されている画像、チャート、グラフなどのビジュアルを補足する説明文を用意してください。Amazon Q in Connect がビジュアルの内容をより適切に解釈できるように、キャプションや要約を文書に追加することが重要です。 一般的でない用語の定義と関連付け 各コンテンツ内であなたのビジネス固有の略語、略語、一般的でない用語を初めて使う際、その定義を含めてください。またこれらの用語を、Amazon Q in Connect が理解しやすくするため、説明するフレーズと関連付けてください。 例の利用 特定のユースケースのコンセプトは、必ず例を使って説明してください。これらの詳細を十分に提供することで、Amazon Q in Connect のお客様のビジネスやエージェントの期待される対応、行動の理解度に影響します。 表を避ける 可能な限り、コンテンツ内に表やスプレッドシートを使用しないでください。Amazon Q in Connect がこの情報を理解しやすくするためには、表形式のデータではなく、段落または箇条書きで記述するのが最適です。 Amazon Q in Connect を活用するその他のベストプラクティス 矛盾した情報を避ける 以前のバージョンを含むすべての文書ではなく、最新バージョンの文書のみを提供してください。Amazon Q in Connect は、選択した設定に基づいて (例:1 時間ごと)、またはカスタム統合の一部として実装した設定に基づいて、ナレッジソースと同期します。同じコンテンツが複数のドキュメントで利用されている場合は、記載が詳細含め一貫していることを確認してください。これにより、Amazon Q in Connect は、一貫性のある正確なレコメンデーションを提供できます。 コンテンツのセグメンテーション 膨大な情報の管理は、特にさまざまな事業部門が特定のコンテンツへのアクセスを必要とする場合、ますます困難になります。エージェントと Amazon Q in Connect の双方にとって、ナレッジベースを整理して効率的に保つことが重要です。これは、コンテンツセグメンテーションを活用することで実現できます。 UpdateSession API を活用すると、顧客タイプ、キュー、基幹業務などのカスタム条件に基づいてタグを使用してコンテンツを除外できます。これにより、より正確なフィルタリングが可能になり、そのインタラクションについてわかっている情報に基づいて関連情報のみをエージェントに提示できます。 結論 Amazon Q in Connect のナレッジベースの最適化は、顧客とのやり取りとそのサポートを強化するための継続的な取り組みです。明確でアクセスしやすいコンテンツを作成し、コンタクトセンターのニーズを理解し、ベストプラクティスを実装することに集中することで、Amazon Q in Connect がエージェントを強化するための強固な基盤を築くことができます。俊敏性を保ち、常に最新情報を入手し、ナレッジベースを動的に進化しつづけるリポジトリを実現して、エージェントや Amazon Q in Connect のような生成 AI 機能を活用しましょう。 Amazon Q in Connect の利用開始に役立つリソース Amazon Q in Connect が実際に動作する様子を見たいですか? Amazon Q in Connect がエージェントの優れたカスタマーエクスペリエンスの提供にどのように役立つかについてデモ をご覧ください。 Amazon Q in Connect をインスタンスで有効化する方法を学びたいですか?  Amazon Connect 管理者ガイドには、Q を Connect で有効にする方法とその機能に関する全体的な概要が記載されています。詳細については「 インスタンスで Amazon Q in Connect を有効にする 」を参照してください。 Amazon Q in Connect のハンズオンを試したいですか? Amazon Q in Connect ワークショップ で、アクティベーション方法、ドメインの設定方法、コンテンツの接続方法、AI が生成したレスポンスやソリューションをエージェントに提供する方法を学びましょう。 Amazon Q in Connect でどのようなコンテンツがサポートされているかを知りたいですか? Amazon Q in Connect は、お持ちのさまざまなファイルタイプの取り込みをサポートしています。詳細については、「 サポートされているコンテンツタイプ 」を参照してください。 Amazon Connect でカスタマーサービス体験を変革してみませんか。 こちらからお問い合わせ ください。 著者紹介 Alex Schrameyer (代名詞 he/him) は、インディアナ州インディアナポリスに拠点を置く AWS のエージェントエクスペリエンス担当ワールドワイドソリューションアーキテクトリードです。卓越したエージェント体験こそが優れたカスタマーサービスの基礎であると考え、エージェントが優れた能力を発揮し、お客様に喜んでもらえる環境を作ることに重点を置いています。アレックスは世界中を旅するのが好きで、あなたの地元の野球場やテーマパークでも見かけるかもしれません。 Freddy Jimenez (代名詞 he/him) は、イリノイ州シカゴを拠点とする Amazon Connect を専門とする AWS のシニアソリューションアーキテクトです。さまざまな業界のお客様と協力して、Amazon Connect を活用してカスタマーエクスペリエンスに変革をもたらしています。彼はコンタクトセンターの技術分野の深い専門知識を持ち、運用や専門サービスの経験も豊富です。フレディは、走ったり、旅行を通じて新しい目的地を見つけたり、ミニチュアゴールデンドゥードルとのひとときを大切にすることに喜びを見出しています。 Prescott Wright (代名詞 he/him) は、モンタナ州ボーズマンを拠点とする Amazon Q in Connect のプリンシパルプロダクトマネージャーです。サービスとしてのコンタクトセンター (CCaaS) ソリューションの開発に 10 年以上携わってきた経験を持つ彼は、エージェントが優れたカスタマーサービスを提供できるようにするツールの提供に情熱を注いでいます。トレイルランニング、スキー、子供たちとキャンプをしながら美しいモンタナの荒野を探索することが彼の楽しみです。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

  CPU を絶えず 100% の最大使用率で実行するアプリケーションはほとんどありません。ウェブアプリケーションを例にとってみましょう。使用率は需要が高い期間と低い期間で変動するのが一般的ですが、サーバーのコンピューティング能力をフルに活用することはめったにありません。 お客様が現在 AWS クラウドで実行している多くの一般的なワークロードの CPU 使用率。(出典: AWS ドキュメント ) このようなワークロードを実行する簡単かつコスト効率性に優れた方法の 1 つは、2023年 8 月にリリースされた Amazon EC2 M7i-Flex インスタンス を使用することです。これらは、Amazon EC2 M7i インスタンスの低価格バリアントで、最も一般的なサイズの汎用コンピューティングに同一の次世代仕様を提供するとともに、常に最大限のコンピューティング能力を使用する必要がない場合により低い料金設定と優れたパフォーマンスを提供するという追加のメリットがあります。このため、同じパフォーマンスベンチマークを満たしながら運用コストを削減したい場合の優れた第 1 選択肢になります。 この柔軟性にはお客様から大きな反響をいただいたため、AWS は5月14日、同じような料金/パフォーマンスのメリットを提供し、コンピューティング集約型ワークロードのコストを削減する Amazon EC2 C7i-Flex インスタンスをリリースして、Flex ポートフォリオを拡大しました。これらは Amazon EC2 C7i インスタンスの低価格バリアントで、ベースラインレベルの CPU パフォーマンスを提供し、95% の確率で最大限のコンピューティングパフォーマンスにスケールアップする機能を備えています。 C7i-flex インスタンス C7i-flex は、 large から 8xlarge までの 5 つの最も一般的なサイズを提供し、 Amazon EC2 C6i インスタンスよりも 19% 優れた料金パフォーマンスを実現します。 インスタンス名 vCPU メモリ (GiB) インスタンスストレージ (GB) ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) c7i-flex.large 2 4 EBS のみ 最大 12.5 最大 10 c7i-flex.xlarge 4 8 EBS のみ 最大 12.5 最大 10 c7i-flex.2xlarge 8 16 EBS のみ 最大 12.5 最大 10 c7i-flex.4xlarge 16 32 EBS のみ 最大 12.5 最大 10 c7i-flex.8xlarge 32 64 EBS のみ 最大 12.5 最大 10 C7i-flex と C7i の選択基準 C7i-flex と C7i は、どちらも Amazon Web Services (AWS) 以外では利用できないカスタム第 4 世代インテル Xeon スケーラブルプロセッサが搭載されたコンピューティング最適化インスタンスです。これらは、他のクラウドプロバイダーが使用する同等の x86 ベースのインテルプロセッサよりも最大 15% 優れたパフォーマンスを提供します。 どちらも DDR5 メモリを使用し、メモリと vCPU の比率が 2:1 であるため、ウェブサーバーやアプリケーションサーバー、データベース、キャッシュ、Apache Kafka、および Elasticsearch などのアプリケーションの実行に最適です。 では、これらのどちらか一方を使用する理由は何でしょうか? 以下は、どちらのインスタンスが適切かを判断するときの 3 つの考慮事項です。 使用パターン EC2 flex インスタンスは、すべてのコンピューティングリソースをフル活用する必要がない場合に最適です。 コンピューティングリソースを効率的に使用するため、5% の料金パフォーマンス向上と、5% の料金削減を実現できます。通常、flex インスタンスはほとんどのアプリケーションに適しているため、コンピューティング集約型ワークロードには C7i-flex インスタンスを第 1 選択肢にすべきです。 その一方で、アプリケーションが常に高い CPU 使用率を必要とする場合は、C7i-flex の代わりに C7i インスタンスを使用する必要があります。おそらく、バッチ処理、分散分析、ハイパフォーマンスコンピューティング (HPC)、広告配信、高度にスケーラブルなマルチプレイヤーゲーム、動画エンコードなどのワークロードには、C7i インスタンスの方が適切です。 インスタンスサイズ C7i-flex インスタンスは、ワークロードの大半で使用される最も一般的なサイズを提供しており、最大サイズは 8xlarge です。 より高度な仕様が必要な場合は、大型の C7i インスタンスを検討してください。これには、 12xlarge 、 16xlarge 、 24xlarge 、 48xlarge に加えて、 metal-24xl および metal-48xl サイズの 2 つのベアメタルオプションが含まれます。 ネットワーク帯域幅 大きいサイズは、より広範なネットワーク帯域幅と Amazon Elastic Block Store (Amazon EBS) 帯域幅も提供するため、要件によっては、サイズがより大きい C7i インスタンスの 1 つを使用する必要があるかもしれません。C7i-flex インスタンスは、最大 12.5 Gbps のネットワーク帯域幅と最大 10 Gbps の Amazon Elastic Block Store (Amazon EBS) 帯域幅を提供し、これはほとんどのアプリケーションに適しています。 知っておくべきこと リージョン –  AWS サービス (リージョン別) にアクセスして、希望するリージョン内で C7i-flex インスタンスが利用可能かどうかを確認してください。 購入オプション – C7i-Flex および C7i インスタンスは、オンデマンド、Savings Plan、リザーブドインスタンス、およびスポットの形式でご利用いただけます。C7i インスタンスは、専有ホストおよびハードウェア専有インスタンス形式での利用も可能です。 詳細については、 Amazon EC2 C7i and C7i-flex instances をご覧ください。 — Matheus Guimaraes 原文は こちら です。