こんにちは。ソリューションアーキテクトの齋藤です。三井物産株式会社(以下、三井物産) デジタル総合戦略部 デジタルテクノロジー戦略室では、先端技術の調査・検証、および、先端技術をてこにした新規事業の企画や事業性検討（R&D）を行っております。また、本 R&D 活動の中で創出されたソリューションやプロダクトを、事業本部と連携して社内外へ展開しています。本ブログは、三井物産がどのように AWS 上で生成 AI を活用し、三井物産グループ内における入札業務に活用可能なソリューションの開発につなげたか、三井物産 デジタル総合戦略部 デジタルテクノロジー戦略室 伊藤友貴 氏 から寄稿していただいたものです。 背景 AWS : 入札書解析業務に生成 AI を活用するに至った際の背景を教えてください。 三井物産 伊藤様 : 三井物産は総合商社ということもあり、国内公共事業、大規模プロジェクト（都市開発, 風力発電など）海外事業の入札案件に参加することが頻繁にあり、このとき数百ページにおよぶ入札書の内容を確認しますが、ここにビジネスとして下記の課題がありました。 海外事業での入札の場合、入札仕様書が英語記載のため担当者が理解するのに熟練者でも 30 〜 40 時間がかかる。 正確に案件を理解するために、入札書に記載されている事業の業界知見が必要になる。 担当者が 3〜5 年周期で異動があり、知見が引き継がれないケースがある。 元々、三井物産では上記ビジネス課題を解決するために、自然言語処理を用いたソリューション開発に関する取り組みをしていました。最初の顧客として、弊社グループ企業である三井物産スチール株式会社の協力を得て、継続的フィードバックをもらいながら取り組んでおり、本プロジェクトの、いちツールとして生成 AI を活用しています。 AWS : どのような要件が、ユーザー（入札担当者）から上がりましたか ? 三井物産 伊藤様 : 商社の業務として、公共入札に参加することがあります。発注者から入札広告が行われたら、担当者は数百ページにおよぶ入札書類を読み込み、その内容を社内外の関係者に確認します。その後、発注者へのカウンター（回答）案を作成必要があります。通常入札書類の読み込みには 30 〜 40 時間程度必要とします。担当者は、入札書類から必須で確認すべき項目（金額, 契約期間, 納品日, 条件など）を把握することができて、抽出された項目が入札書類のどの文書を参照して抽出されたかを自身で把握できるようにしたいと要望が上がりました。 AWS : 三井物産様のような総合商社が入札するプロジェクトは、公共事業など数 10 億円から数 100 億円になる大規模案件になる場合が多いと予想しています。さっそくではありますが、入札書解析システムのソリューションについて説明していただいてもよろしいでしょうか ? 三井物産 伊藤様 : 全体アーキテクチャは下記の通りです。 入札書解析システム アーキテクチャ ソリューション 三井物産 伊藤様 : 入札書解析システムは、AWS のフルマネージド型のサービス を中心としたアーキテクチャで構成されています。対象の入札書を Amazon S3 にアップロードすると、自動で解析業務が実行されます。AWS Fargate は、Amazon S3 に格納されている入札書を取得し、大規模言語モデルの Legal-RoBERTa-large を用いて、入札業務に必要な項目を抽出します。Legal-RoBERTa-large で抽出された項目は、そのままでは使用することが出来ず、さらに細かく分割する必要があります。これに、AI21 Labs が開発した大規模言語モデルである、Jurassic-2 Ultra を、Amazon Bedrock 上で使用しています。分割された項目は Amazon DynamoDB に保存されます。 担当者は、WEB UI を通じて、入札書の解析結果を確認することができます。 入札書解析システム UI 本システムで工夫した点は以下です。 入札書から抽出された項目で、契約期間日、引渡日、特記事項など、入札担当者が必ず確認する必要がある項目にフラグを指定することができます。 Legal-RoBERTa-large で抽出した項目が多数あるので、AWS Fargate から、Amazon Bedrock が提供する API を通じて Jurassic-2 Ultra を並列で呼び出し、入札書解析の処理時間を短くすることができます。 なお、本取り組み成果にの一部ついては、2024 年 5 月に開催の Web データマイニング分野のトップ会議、 The Web Conference 2024 の DEMO Track にて発表されました。 Why AWS ? AWS : 入札書解析システムに、AWS が採用された決め手を教えてください。 三井物産 伊藤様 : まず、AWS 技術者の数です。他社と比較して、使える技術者の多さ、学習教材の多さもポイントです。これは、構築委託をする場合、パートナー選定時における幅広い選択肢につながりました。又、Amazon Bedrockを採用することで、複数 LLM の試行錯誤を簡単に実施することが可能です。最終的に、Jurassic-2 Ultra を採用しましたが、Claude を初めとする他 LLM の検証も並行して実施しました。 導入効果と今後の展望 AWS : 入札書解析システムの導入効果および今後の展望について教えてください。 三井物産 伊藤様 : 導入効果として大きく 3 つあります。 システム導入後には入札書の解析時間が、今までより 70 % 短縮することに成功しました。これは年間で 2,000 時間分の作業時間になります。 33 時間 → 21.2 時間、約 12 時間削減（入札業務 経験豊富） 96 時間 → 30.4 時間、約 65 時間削減（入札業務 経験少なめ） AWS のフルマネージド型のサービス を採用することにより、OS やミドルウェアの開発・保守などの運用費削減にもつながりました。 AWS のフルマネージド型のサービス を採用することにより、システム全体に拡張性を持たせられるので、使用量に応じて柔軟にスケーリングが可能です。 今後の展望として、まずは三井物産事業部内に横展開、その後は社外への販売を検討しています。既存の仕組みを継承しつつ、顧客の要件に応じてフロントエンドをカスタマイズすることで、開発コストおよび期間が 10 分の 1 になり、より価値あるサービスを顧客へ提供していくことを目指しています。 著者について 伊藤 友貴 2020年東京大学大学院工学系研究科博士後期課程修了。博士（工学）。 大学院では主にAI・テキストマイニング・解釈可能な AI に関する研究に従事。この研究は AI およびデータ解析分野のトップ会議 AAAI や ICDM 等にに採択。 博士課程終了後、三井物産に入社。入社後は新規事業立上げを見据えた自然言語処理に関する R&D や社会実装に従事。本取組成果の一部は Web 分野のトップ会議 WWW に採択。

re:Invent 2023 で プレビュー として発表された、最大 32 TiB の DDR5 メモリと 896 個の vCPU を搭載する Amazon Elastic Compute Cloud (Amazon EC2) U7i インスタンスが利用可能になりました。カスタム第 4 世代インテル Xeon スケーラブルプロセッサ (Sapphire Rapids) 駆動のこれらのハイメモリインスタンスは、SAP HANA、Oracle、SQL Server などの大規模なインメモリデータベースをサポートするように設計されています。仕様はこのようになっています。 インスタンス名 vCPU メモリ (DDR5) EBS 帯域幅 ネットワーク帯域幅 u7i-12tb.224xlarge 896 12,288 GiB 60 Gbps 100 Gbps u7in-16tb.224xlarge 896 16,384 GiB 100 Gbps 200 Gbps u7in-24tb.224xlarge 896 24,576 GiB 100 Gbps 200 Gbps u7in-32tb.224xlarge 896 32,768 GiB 100 Gbps 200 Gbps 新しいインスタンスは、大規模なインメモリワークロードに対して最高のコンピューティングコストパフォーマンスを実現し、大手クラウドプロバイダーのどの SAP 認定仮想インスタンスよりも高いメモリ容量とコンピューティング能力を提供します。 AWS Nitro System のおかげで、インスタンスのメモリを余すことなく使用できます。こちらは 32 TiB インスタンスの例です。 前世代 の EC2 ハイメモリインスタンスと比較すると、U7i インスタンスは 135% を超えるコンピューティングパフォーマンス、最大 115% のメモリパフォーマンス、および 2.5 倍の EBS 帯域幅を提供します。拡大された帯域幅により、1 時間以下で 30 TiB のデータを EBS からメモリに転送できるため、データのロードとキャッシュ更新がこれまでにない速さで行われるようになります。インスタンスは、フローあたりの帯域幅を 25 Gbps にする ENA Express もサポートしており、インスタンス間の P99.9 レイテンシーを 85% 削減します。 各 U7i インスタンスは、最大 128 の汎用 (gp2 および gp3) またはプロビジョンド IOPS (io1 および io2 Block Express ) EBS ボリュームのアタッチメントをサポートします。io2 Block Express ボリュームは、それぞれ最大 64 TiB まで拡張でき、最大 32 Gbps で最大 256,000 IOPS を提供できるため、U7i インスタンスに最適です。 インスタンスは、本番環境で Business Suite S/4HANA、Business Warehouse on HANA (BW)、SAP BW/4HANA を実行するための SAP 認定を受けています。詳細については、 Certified and Supported SAP HANA Hardware および SAP HANA to AWS Migration Guide を参照してください。 AWS Launch Wizard for SAP を読むこともお勧めします。 知っておくべきこと 以下は、新しいインスタンスについて知っておきたい事柄です。 リージョン – U7i インスタンスは、米国東部 (バージニア北部)、米国西部 (オレゴン)、およびアジアパシフィック (ソウル、シドニー) の各 AWS リージョンでご利用いただけます。 オペレーティングシステム – サポートされているオペレーティングシステムには、Amazon Linux、Red Hat Enterprise Linux、SUSE Linux Enterprise Server、Ubuntu、Windows Server が含まれます。 より大規模なインスタンス – お客様のニーズに応えるため、AWS では、より優れたコンピューティング能力を備えたさらに大規模なインスタンスの年内提供にも取り組んでいます。 – Jeff ; 原文は こちら です。

本ブログはコネヒト株式会社様と Amazon Web Service Japan が共同で執筆いたしました。 みなさん、こんにちは。AWS ソリューションアーキテクトの瀬高です。 昨今、生成 AI が盛り上がりを見せていますが、特にユースケースとして多い RAG (Retrieval Augmented Generation) に関する事例をご紹介します。 RAG とは生成 AI モデルと外部の独自情報をかけ合わせる技術となっており、ビジネスで既に活用しているデータやドキュメントを活かした回答精度の向上や、事実に基づかない回答をする「ハルシネーション」のリスク軽減ができる点から注目されています。(RAG の詳細は こちら ) この記事では 2023 年 12 月に コネヒト株式会社様 で取り組んでいただいた Amazon Bedrock と Amazon OpenSearch Service を活用し、質問検索の体験向上について 1 ヶ月という短い期間で検証をしていただいた事例となります。 本取り組みは コネヒト株式会社様による開発者ブログ にて、詳細に解説いただいています。あわせて御覧ください。 お客様の状況と検証に至る経緯 コネヒト株式会社様は、 ママリ というママ向け Q&A アプリ/ 情報サイトを AWS 上で実装、運営しており、2022年より Amazon OpenSearch Service を利用したサービス内質問の検索機能を提供していました。 その中でも、プレミアムユーザー向けの機能である、質問の人気順ソート機能が大きな加入要因となっている点から、利用者の検索体験をより良いものにすることで、プレミアム会員の価値向上を目指したいという考えがあり、生成 AI とのかけ合わせによる検索体験の向上を検証することになりました。 今回の検証について 今回は Amazon OpenSearch Service を利用した全文検索システムを提供しているという点を活かし、実際に利用しているデータのベクトル化を行い、ベクトル検索と全文検索を1ヶ月という短期間で比較検証を行い、ベクトル検索の優位な点を検証されていました。 ベクトル検索を実行するために必要なベクトルデータは Amazon Bedrock の埋め込みモデルによって生成しています。Amazon Bedrock から利用できるモデルの中には単語やテキスト、画像などを AI や言語モデルが使いやすい数値ベクトルへ変換するために用いられる「埋め込みモデル」と言われるモデルがあります。今回はコンテキスト長や対応言語の観点から、 Titan Embeddings を利用してベクトル化を行っています。 次にベクトルデータを格納する Amazon OpenSearch Service 内に全文検索とベクトル検索、両方に対応したインデックスを作成しました。 インデックスを作成する前にドメインを作る必要があります。ドメインの作成方法については こちら をご参照ください。 検証では opensearch-py というライブラリを用いて Python でインデックスを作成しており、bulk 関数を用いてデータを登録しています。 データの登録が終わり、下記の 5 つのケースについて検証を実施しています。 ケース1. クエリが一つの単語で構成される場合 ケース2. クエリが複数の単語で構成される場合 ケース3. クエリに固有名詞を含む場合 ケース4. クエリに誤字を含む場合 ケース5. クエリに文章を使用した場合 検証結果としては、固有名詞を含むクエリなどは苦手とする一方、 誤字を含むクエリでは本来入力しようとした情報を踏まえた検索結果の返却や、文章をクエリとする検索では全文検索以上にユーザーが求める検索結果が返る可能性がある ことがわかりました。 検証の結果と今後について マネージドサービスである Amazon OpenSearch Service の活用や、Amazon Bedrock による API を通した既存テキストデータの埋め込みデータへの変更、全文検索とベクトル検索の比較という内容を1ヶ月という短期間で構築、検証結果を得ることができました。 検証結果については、全文検索にも固有名刺を含むケースや単語が確実に含まれている質問を出したいケースなど優れた点がありつつも、誤字や曖昧表現にも強く自然言語などをもとに高い精度で検索ができる、ベクトル検索の特徴を活かした検索ができる場面があることがわかりました。 コネヒト株式会社様は 全文検索とベクトル検索の検索スコアを統合し、両者のメリットを活かすハイブリッド検索のプロトタイピングにも取り組んでいくとのことで、今後更に検索体験の向上に向けた取り組みを行っていくとのことです。 CTO の永井様からは “Amazon Bedrock と Amazon OpenSearch Service を利用することでよりユーザの意図に沿った検索結果を返すことができ、検索体験の改善につながる手応えがありました” とのコメントもいただいたいます。 他の RAG 実装アプローチについて コネヒト株式会社様は RAG を実装するために、既存のデータを埋め込みモデルを利用してベクトルデータに変換するアプローチを採用されました。 それ以外にも、AWS では RAG を実装する方法がいくつかございますので、その整理をしてこの記事を結びたいと思います。 今回は2番の方法に該当しますが、Amazon OpenSearch Service 以外にも Amazon RDS for PostgreSQL や Amazon Aurora (PostgreSQL 互換) をデータストアに使うこともできます。1、 3、4番のように検索サービスやマネージドのレベルが高い Amazon Kendra や ナレッジベース 、 Amazon Q Business という仕組みを活用していく手段も用意されており、データやドキュメントを用意するだけで RAG 環境を構築することが可能な方法もあります。(Amazon Q Business は 2024 年 5 月執筆時点で日本語に未対応です。) プロダクトの検索体験向上にご興味があり、どの方法が良いかわからない場合は、ご支援させていただきます。担当営業までお気軽にお問い合わせください。 まとめ 今回は既存の OpenSearch 上のデータと生成 AI を組み合わせることで、利用者の検索体験向の向上を目指したお客様の挑戦についてご紹介いたしました。 全文検索の仕組みだけでなく、新たなユーザーの検索体験につながる結果も得られており、今後の生成 AI 活用も期待ができると思われます。 また、今回のようなベクトル DB を構築する以外にも AWS 上で RAG を構築する方法が複数ある点についても触れさせていただきました。 構築方法でご不明な点があればお問い合わせいただければと思います。ぜひお試しください。 ソリューションアーキテクト 瀬高 拓也 (X – @stktky )

概要 これは、AWS の SAP 環境における End-to-End 監視の概要に関するブログシリーズの第 2 回目です。 第 1 回は こちら をご覧ください。 ネットワークのパフォーマンスは、通常、企業のビジネスプロセスを実行する SAP のようなエンタープライズアプリケーションにとって重要です。SAP ブログ “ SAP Netweaver ABAP のネットワークパフォーマンス分析 ” では、SAP の 3 層ソフトウェアアーキテクチャ (つまり、プレゼンテーション層、アプリケーション層、データベース層) が、プロトコルと API の組み合わせを使用して相互に通信する方法について説明されています。 ネットワークのパフォーマンスが遅いと、データの処理に大幅な遅延が生じ、ユーザーへのレスポンスタイムも遅くなります。ネットワークトラフィックの混雑により、パケットロスが発生し、階層間の通信が完全に失敗する可能性があります。これにより、データの損失や破損が発生し、SAP アプリケーションとそのユーザーに深刻な影響を及ぼす可能性があります。一般的に高速なデータベースの応答時間は 100 マイクロ秒程度ですが、ネットワークの応答時間は約 300 マイクロ秒となります。つまり、ネットワーク時間が応答時間全体の 75 % を占めることになります。 AWS クラウド内で SAP のネットワークパフォーマンスを最適化および監視する方法について説明します。まず、SAP サーバ間のネットワークパフォーマンスから始めましょう (図 1 の赤い枠線の部分)。 SAP サーバ間のネットワークパフォーマンス SAP はクライアントとサーバーのエンタープライズアプリケーションで、ユーザーが日々の業務を実行するためにログインする SAP アプリケーションサーバーと、SAP データを格納するデータベースなど、複数のコンポーネントで構成されています。 以下の図は、顧客のネットワーク (オンプレミス) の SAP ユーザーが、サイト間 VPN や AWS Direct Connect と呼ばれる専用リンクなどの WAN (広域ネットワーク) 接続を通して、AWS Cloud 上で実行されている SAP アプリケーションにアクセスする様子を示しています。 図 1 : AWS クラウドで実行されている SAP アプリケーションへのオンプレミス接続を示すアーキテクチャ図 ミッションクリティカルワークロード向けの AWS グローバルインフラストラクチャ はじめに、 AWS のグローバルインフラストラクチャ について理解しましょう。 AWS には、リージョンという概念があります。リージョンとは、データセンターを集約させた世界中の物理的な場所を指します。 論理的なデータセンターのグループを Availability Zone (AZ) と呼びます。 各 AWS リージョンは、地理的な区域内に最低 3 つの、独立した、物理的に分離された AZ で構成されています。 他のクラウドプロバイダーが 1 つのデータセンターを 1 つのリージョンとして定義することが多いのとは異なり、すべての AWS リージョンにはマルチ AZ 設計が備わっており、お客様に優れた利点があります。各 AZ には、独自の電源、冷却システム、物理的セキュリティが備わっており、冗長化された超低レイテンシーのネットワークで接続されています。ワークロードが AZ 間で分割されている場合、お客様はさまざまな問題 (停電、落雷、トルネード、地震など) から保護され、より高い絶縁性が確保されます。AZ は互いに数キロメートル離れた場所にあり、距離の上で十分に分離されていますが、それでもすべての AZ が 100 km 以内にあります。高可用性を求める AWS のお客様は、さらに高い耐障害性を備えるため、複数の AZ 上で実行されるようにアプリケーションを設計することができます。その上、AWS インフラストラクチャの各リージョンは、セキュリティ、コンプライアンス、データ保護に関する最高レベルの要件を満たしています。 AWS のリージョンとアベイラビリティーゾーンのモデルは、 Gartner から高可用性が必要なエンタープライズアプリケーションを実行するための推奨アプローチとして認められています。 SAP のネットワークレイテンシ要件 最適なパフォーマンスを得るために、SAP はネットワークに関する推奨事項を示しています。 SAP アプリケーションサーバーとデータベースサーバー間のネットワーク レイテンシは、 SAP Note 1100926 で示されているとおり、0.7 ミリ秒 (ms) 未満である必要があります。 データロスゼロ (セロ) を実現するために必要な、データの同期レプリケーションによる HANA システムレプリケーションのネットワーク レイテンシは、 1 ms 未満 である必要があります。 SAP は、ローカルの SAP システムで使用されているネットワーク インフラストラクチャの健全性を測定するツールとして、 NIPING を提供しています。 NIPING はクライアント/サーバー ツールとして実行され、ネットワーク レイテンシと帯域幅を測定するために使用できます。 上記を踏まえて、AWS の北バージニア リージョン (us-east-1) の 6 つの AZ 間 (AZ 間) および同じ AZ 内 (AZ 内) のネットワークレイテンシを見てみましょう。 各 AZ に 1 つずつ、計 6 つの EC2 インスタンスを作成し、NIPING を使ってテストを実行します。AZ1 をベースラインとします。 図 2 : NIPING を使用したネットワーク待ち時間の測定に使用した EC2 インスタンス NIPING の結果は、AZ1 から AZ2-AZ6 までの AZ 間のネットワーク遅延を 0.7 ms の閾値に対して相対的に示しています。 AZ1 内の AZ 内ネットワーク遅延も 0.7ms の閾値を下回っています。 図 3 : AWS バージニア北部リージョン (us-east-1) における NIPING を使用したネットワーク待ち時間 ( 2023 年 7 月 ) 上記のように、NIPING ツールを使用すると、AZ 間および AZ 内のネットワーク遅延を監視および測定できます。ただし、EC2 インスタンスを複数実行する必要があります。そこで、AWS Network Manager を使用すれば、この測定の代替手段となります。 AWS Network Manager – Infrastructure Performance AWS Network Manager は、AWS でのネットワーク管理と監視を助けるツールと機能を提供します。 Network Manager は、接続管理、ネットワーク監視とトラブルシューティング、IP 管理、ネットワークセキュリティとガバナンスを簡単に行えるようにします。 特に、 AWS Network Manager – Infrastructure Performance に注目したいと思います。 インフラストラクチャパフォーマンスを使用すると、ほぼリアルタイムと過去 45 日間の AWS リージョン間、AZ 間、または AZ 内の AWS グローバルネットワークパフォーマンスを、指定された期間のネットワーク待ち時間で監視できます。 ネットワーク待ち時間を最大 5 分間隔で監視でき、過去 45 日間のトレンドも確認できます。 さらに、これらの待ち時間メトリクスを Amazon CloudWatch に公開し、さらなる監視、分析、アラートを行うこともできます。 これにより、ネットワークのパフォーマンスが SAP やその他の実行中のアプリケーションに影響を与えるかどうかを容易に評価できます。 インフラストラクチャパフォーマンスの利用は無償であり、EC2 インスタンスのプロビジョニングも必要ありません。 AWS の北バージニア (us-east-1) リージョンを使用し、アベイラビリティーゾーン (AZ) 間 (Inter-AZ) および同一 AZ 内 (Intra-AZ) のネットワーク遅延を分析してみましょう。 AWS コンソールから Network Manager を選択し、Infrastructure Performance を選択してください: 図 4 : AWS Network Manager – Infrastructure Performance サービス ネットワーク遅延監視をセットアップするのは簡単で手軽です。「Inter-Availability Zone」を選択し、以下の例では AZ1 を基準として、他の 5 つのアベイラビリティーゾーンを選択します。 図 5 : Inter-Availability Zoneと監視対象の各 us-east-1 AZ の選択 次に、適切な期間 (この例では 1 週間) と監視間隔 (5 分) を選択します。 : 図 6 : 監視期間の選択 AZ1 (use1-az1) から他の 5 つのアビリティーゾーンへの AZ 間レイテンシーは、上記の NIPING の結果と一致しています: 図 7 : AZ 間ネットワークレイテンシモニタリング 同様に、6 つのすべての Availability Zone 内で Intra-AZ ネットワーク待ち時間のテストを繰り返し、平均ネットワーク待ち時間が 0.3 ms 未満であり、0.7 ms の閾値をはるかに下回っていることを示しています。 図 8 : AZ 間ネットワークレイテンシモニタリング 上の例では、AZ1 をベースラインとして使用しました。AZ2 をベースラインとして、その後 AZ3 などと、他の AZ ペア間で上記の遅延テストを繰り返し、推奨事項を満たす AZ を特定してください。 リージョン間のネットワークレイテンシについてはどうでしょうか? AWS バージニア北部リージョン (us-east-1) と他の米国内の AWS リージョン、オハイオ (us-east-2)、北カリフォルニア (us-west-1)、オレゴン (us-west-2) とを比較してみましょう。 図 9 : リージョン間ネットワークレイテンシモニタリング この場合、地理的な距離が短いため、us-east-1 (バージニア北部) と us-east-2 (オハイオ) 間のネットワーク遅延が最も低いことが観測されます。 Amazon CloudWatch による AZ レイテンシのモニタリング 以下の手順に従って、「AggregateAWSNetworkPerformance」CloudWatch メトリクスをサブスクライブし、AZ 間の待ち時間監視用のダッシュボードを作成してください。 CloudWatch ダッシュボードの作成 ネットワーク待ち時間が特定のしきい値を超えた場合に、アラートも作成して送信できます。AWS Network Manager – Infrastructure Performance は無料でご利用いただけますが、CloudWatch 監視には料金がかかります。料金については Amazon CloudWatch 料金 をご確認ください。 図 10 : AZ 間モニタリング用の CloudWatch ダッシュボード Infrastructure Performance では、トランジットゲートウェイ、NAT ゲートウェイ、VPC エンドポイント、Elastic Load Balancing、Amazon EC2 ネットワークインターフェイスなど、VPC ネットワーキングリソースを通過するパスのパフォーマンス指標は考慮されません。 また、SAP アプリケーション/オペレーティングシステム/データベースのオーバーヘッドの影響があるため、SAP アプリケーションから観測されるネットワークレイテンシーも Infrastructure Performance では考慮されません。 詳しくは、 AWS ドキュメント の Infrastructure Performance に関する説明をご確認ください。 信頼性と可用性を考慮した SAP の設計 複数のサーバー (つまり、複数の SAP アプリケーションサーバー、SAP Web ディスパッチャー) がある場合、信頼性と可用性を高めるため、これらのサーバーを可用性ゾーン間で分散することをお勧めします。これにより、追加のネットワーク待ち時間の影響を上回ります。 SAP を高可用性で設計する場合 (つまり、データベースの複製を行う場合)、最適なパフォーマンスを確保するには、ネットワーク待ち時間が他より短いアベイラビリティーゾーンのペアを選択してください。ネットワーク待ち時間は時間の経過とともに変化し、リージョンとアビラビリティーゾーンのペアによっても異なることに注意してください。 パフォーマンス要件が極めて高いバッチジョブの場合は、データベースサーバーと同じアベイラビリティーゾーン内の SAP Application Server で実行するようにスケジュールすることをお勧めします。 クロスリージョン災害復旧 (DR) の要件がある場合、AWS リージョン間のネットワークレイテンシーと対応する地理的距離を考慮して、DR の二次リージョンを決めてください。 詳細については、 SAP Lens AWS ウェルアーキテクトフレームワーク ドキュメント を参照してください。 RISE with SAP では、AWS は、すべての AWS リージョンで Short-Range DR と Long-Range DR の両方をサポートする初めての クラウドプロバイダーです。Short-Range DR は 1 つのリージョン内の 2 つの AZ 間での DR を提供し、Recovery Point Objective (RPO) はゼロ、つまりデータロスはありません。これは、地理的に離れた AZ 間の高速で低レイテンシのネットワーク リンクによるシンクロナスなデータレプリケーションをサポートする AWS のマルチ AZ インフラストラクチャに対する SAP の確信の証しです。 長距離 DR とは、2 つの AWS リージョン間でのディザスタリカバリであり、RPO は 30 分です。お客様は、DR オプションを選択するか、短距離 DR と長距離 DR の両方を SAP RISE の構成の一部として組み合わせることができます。 オンプレミスユーザーと AWS Cloud 間のネットワークパフォーマンス 図 11 : オンプレミスと AWS 間の WAN 接続 オンプレミスと AWS Cloud 間の WAN 接続は、顧客が SAP システムにアクセスできることを確保する上で重要です。 WAN 接続の信頼性、可用性、パフォーマンスを維持するには、監視が重要な部分を占めます。 Amazon CloudWatch は、サイト間 VPN 接続と AWS Direct Connect の両方の監視を提供します。サイト間 VPN の場合、少なくとも VPN トンネルの状態、送受信されたデータ量を監視することをおすすめします。使用可能な監視指標の詳細は、AWS ドキュメント サイト間 VPN 接続の監視 と CloudWatch での Direct Connect の監視 を参照してください。 RISE with SAP SAP RISE on AWS を実行している場合、ユーザーを AWS Cloud に接続するための WAN 接続が必要になります。この場合、次の図のように、あなたの AWS アカウントと SAP RISE によって管理される AWS アカウントを AWS Transit Gateway で接続できます。詳細とその他の接続オプションについては、AWS ドキュメント SAP RISE on AWS Connectivity を参照してください。 図 12 : AWS 上の SAP RISE 顧客のための WAN 接続例 AWS グローバルアクセラレータによるネットワークレイテンシの削減 地理的に分散したリモートユーザーが SAP システムにアクセスしようとする場合はどうでしょうか。例えば、ヨーロッパのユーザーがインターネットを介して AWS シンガポールリージョンの SAP システムにアクセスすると、ネットワークのパフォーマンスが予測できず、ユーザー体験が低下する可能性があります。 1 つの選択肢は、 AWS Global Accelerator を利用することです。AWS Global Accelerator は、トラフィックを AWS のグローバルネットワークバックボーンを通すことで、アプリケーションの可用性とパフォーマンスを向上させます。ユーザーが AWS Global Accelerator に接続すると、トラフィックは自動的にネットワークレイテンシーが最も低い最適な AWS エンドポイントにルーティングされます。さらに、 Accelerated Site-to-Site VPN を利用することで、AWS Global Accelerator も使用しながらデータを暗号化することができ、ユーザーに対して最適なセキュリティとネットワークパフォーマンスを提供することができます。 図 13 : AWS アクセラレーテッドサイト間 VPN 経由で SAP にアクセスするリモートユーザー リモートの SAP ユーザーに AWS Global Accelerator が有益かどうかを判断するには、 AWS Global Accelerator Speed Comparison ツールを使用して様々な AWS リージョンへのネットワーク待ち時間を測定できます。このツールを SAP ユーザーの場所で実行すると、AWS Global Accelerator がネットワークトラフィックを最も近い AWS エンドポイントに向けるため、既存のインターネット接続と待ち時間を比較できます。複数回テストを実行すると結果が異なる場合があることに注意してください。ダウンロード時間は、お使いの最終回線ネットワークの品質、容量、距離など、Global Accelerator 以外の要因によって変動する可能性があります。 図 14: AWS Global Accelerator を使用した場合と使用しない場合のネットワーク遅延の比較 Amazon CloudFront を使用した SAP Fiori のパフォーマンスの向上 Amazon CloudFront は、コンテンツ配信ネットワークサービスで、SAP Fiori などの Web コンテンツを、エッジロケーションのグローバルネットワーク全体にキャッシュすることで低遅延と高速の転送が可能です。CloudFront にキャッシュされた SAP Fiori のコンテンツをユーザーがリクエストすると、CloudFront はリクエストを最も近いエッジロケーションにルーティングし、そこからコンテンツを直接ユーザーに配信します。これにより遅延が減り、ユーザーエクスペリエンスが向上します。 SAP Fiori を使用したグローバルな SAP システムを運用し、地理的に分散したユーザーが利用している場合は、Amazon CloudFront を利用するメリットがあります。 AWS Global Accelerator と Amazon CloudFront の詳細な比較については、この AWS ブログ を参照してください。 結論 ネットワークのパフォーマンスチューニングと監視は、時間のかかる作業です。AWS Network Manager – Infrastructure Performance を使えば、リージョン間、アベイラビリティーゾーン内外を問わず、AWS のグローバルインフラストラクチャのネットワーク待ち時間を簡単に監視できます。 この情報を使うことで、AWS Cloud 上で SAP アプリケーションの最大のネットワークパフォーマンスを引き出すための最適な配置を決められ、ミッションクリティカルな SAP ワークロードを継続的に監視し、問題が発生したときにはトラブルシューティングが行えます。 Amazon CloudWatch を使うと、SAP にとって重要なネットワーク コンポーネントを単一の観点から監視できます。 AWS Network Manager と Amazon CloudWatch を組み合わせると、AZ 間、AZ 内のネットワーク レイテンシーと、お客様のネットワークから AWS クラウドへの WAN 接続を監視できます。 AWS Cloud へのエンドユーザー接続を改善するため、AWS Global Accelerator または Amazon CloudFront を検討できます。 前者はルーティング機能により、後者はキャッシュ機構により、それぞれアプリケーションの可用性とパフォーマンスを改善します。 AWS 製品ドキュメント https://docs.aws.amazon.com/index.html から、 AWS 上の SAP 、 Network Manager – Infrastructure Performance 、 Amazon CloudWatch 、 AWS Global Accelerator 、 Amazon CloudFront の詳細を確認できます。 クレジット Derek Ewell と Spencer Martenson のブログへの貢献に感謝いたします。 翻訳はPartner SA 松本が担当しました。原文は こちら です。

本記事は 2023/09/11に投稿された Introducing the Advanced JDBC Wrapper Driver for Amazon Aurora を翻訳した記事です。 翻訳はソリューションアーキテクトの Kenta Nagasue が担当しました。 現代のモダンアプリケーションには、スケーラビリティと耐障害性が求められています。その中でも最も重要なのがスケーラビリティで、アプリケーションの規模によっては、数百万人のユーザーにオンデマンドで対応できる能力が必要とされます。 e コマース、金融サービス、ゲームなどのステートフルアプリケーションでは、高可用性のデータベースが不可欠です。 2015年の Amazon Aurora リリース以降、お客様は Aurora クラスターでリレーショナルデータベースを実行できるようになりました。このクラスターは1つのライターノードと最大15個の低レイテンシーなリーダーノードで構成されています。これにより、アプリケーションは読み取りを大幅にスケーリングできるようになりました。 しかし、マルチインスタンスをサポートするデータベースと同様に、開発者は特別なイベントに対処するため、スイッチオーバーやフェイルオーバーなどの複雑なアプリケーションロジックを構築する必要がありました。 複雑なエンドポイントロジックをアプリケーションに実装する代わりに、スイッチオーバーやフェイルオーバーなどを処理する機能が、 Advanced JDBC (Java Database Connectivity) Wrapper Driver に用意されています。さらに、このドライバーは AWS Secrets Manager または AWS Identity and Access Management (IAM) を使った認証処理も統合しています。 Advanced JDBC Wrapper Driver は Apache 2.0 ライセンスのオープンソースプロジェクトとしてリリースされています。プロジェクトの詳細は GitHub で確認できます。 この記事では、Advanced JDBC Wrapper Driver のいくつかの機能の使い方について詳しく説明します。 Advanced JDBC Wrapper Driver の機能 Advanced JDBC Wrapper Driver は、ネイティブの PostgreSQL または MySQL の JDBC ドライバーを”ラップ”し、基盤となるドライバーへの関数呼び出しの前にフェイルオーバーと認証の機能を追加します。API の実行にネイティブドライバーを使用することで、コードの複雑さを減らし、機能追加に集中できます。 Aurora は単一インスタンスではなく、DB インスタンスのクラスターを提供します。各接続は特定の DB インスタンスによって処理されます。Aurora クラスターに接続する際、指定するホスト名とポートは、エンドポイントと呼ばれる仲介ハンドラーを指します。Aurora はこのエンドポイント機構を使ってこれらの接続を抽象化しています。 以下のセクションでは、このドライバーが軽減するいくつかの課題について説明します。 スイッチオーバー スイッチオーバーとは、リーダーがライターに昇格することを指します。これは、ライターの設定変更によりライターが再起動する必要がある場合に発生します。 クライアントには、クラスターのライターエンドポイントまたはリーダーエンドポイントに接続するオプションがあります。通常はライターエンドポイントに接続します。このエンドポイントは現在のライターインスタンスを指しています。クラスターのパラメーター変更やフェイルオーバーによりクラスターが再起動すると、リーダーの1つが新しいライターに昇格します。この際、クラスターライターエンドポイントが更新され、DNS でインスタンスエンドポイントが新しいライターを指すよう変更されます。DNS の伝播に時間がかかるため、この変更に最大30秒かかる可能性があります。通常、アプリケーションにはデータベースが一時的に利用できなくなった後の再接続ロジックが必要です。Advanced JDBC Wrapper Driver には、自動的に検出して接続を新しいライターに切り替える機能が組み込まれています。Aurora データベース内のトポロジー情報を利用することで、ドライバーは約6秒で切り替えを行えます。 IAM との統合 IAM を使うと、AWS でどのユーザがサービスとリソースにアクセスできるかを管理し、細かいアクセス許可を一元管理でき、AWS 全体のアクセスを分析して許可を最適化できます。IAM はトークン(パスワード)を自動的に定期的に変更することで、セキュリティを強化します。 アプリケーション内で IAM トークンの取得と使用のロジックを記述することも全く問題ありませんが、トークンの取得とキャッシングを扱う必要があるためアプリケーションが複雑になります。このドライバーにはその機能が組み込まれているので、スイッチオーバー時でも、アプリケーションはこれらの複雑さを考慮する必要がありません。IAM ポリシーの作成と、IAM データベースアクセス用の使い方の詳細については、「 IAM データベースアクセス用の IAM ポリシーの作成と使用 」を参照してください。 Secrets Manager との統合 Secrets Manager を使えば、資格情報をまとめて保存・管理できます。資格情報を管理することで、セキュリティ要件に応じて定期的に資格情報を更新(ローテーション)できます。Secrets Manager には、接続認証に使うユーザー名とパスワードを保存できます。この機能を有効にすると、ドライバーは Secrets Manager から資格情報を取得し、接続認証に使用します。 ソリューションの概要 Advanced JDBC Wrapper を使わない場合、データベースに接続してクエリを実行する典型的な Java コードは以下のようになります。 while(true) { try (Connection connection = DriverManager.getConnection(DB_URL, DB_USERNAME, DB_PASSWORD)) { try (PreparedStatement preparedStatement = connection.prepareStatement("SELECT SUM(a) FROM IntegerOverflowTest;")) { try (ResultSet resultSet = preparedStatement.executeQuery()) { resultSet.next(); long l = resultSet.getLong(1); System.out.println("sum(a) -> " + l); } }catch (SQLException ex){ /* * catch exceptions relative to the select and handle them  * if the exception is connection closed then reconnect and try again */ } }catch (SQLException ex){ /* * catch and handle connection errors here */ } スイッチオーバーが原因で接続に失敗した場合、新しいライターがオンラインになるまで接続は失敗します。Advanced JDBC Wrapper Driver を使わない場合、DNS の伝播を待つ必要があり、アプリケーションはおよそ30秒間ライターに接続できなくなります。 一方、Advanced JDBC Wrapper Driver を使えば、再接続を自動で試みます。初期接続時に、ドライバーはクラスターのトポロジーを読み取り、インスタンスエンドポイントを取得します。そのため、接続が失敗した場合でも、ドライバーはクラスター内の全インスタンスの IP アドレスを認識しています。ユーザーアプリケーションで接続が失敗すると、ドライバーはインスタンスをポーリングし、接続を試みます。接続が確立されると、新しいトポロジーを読み取り、新しいライターの IP アドレスを取得して接続します。この一連の処理がドライバー内で行われるため、ユーザーアプリケーションは接続の切断や失敗を認識することはありません。ドライバーは例外をスローし、接続が新しいサーバーに切り替わったことをユーザーアプリケーションに通知します。処理中のトランザクションで障害が発生した場合、トランザクションは失敗し、リトライする必要がある事を示す例外がユーザアプリケーションに投げられます。その為、ユーザーアプリケーションではこの例外を適切に特定し、処理するための小さな変更が必要になります。 接続 URL は、PostgreSQL JDBC ドライバーの場合は jdbc:aws-wrapper:postgresql: 、MySQL JDBC ドライバーの場合は jdbc:aws-wrapper:mysql: となります。Advanced JDBC Wrapper Driver は jdbc:aws-wrapper で始まる部分を受け取り、次の部分からラップする基盤ドライバーを判別します。 以下のコードは、Aurora PostgreSQL クラスターに接続し、フェイルオーバーを設定する方法を示しています。 properties.setProperty(PropertyDefinition.PLUGINS.name, "auroraConnectionTracker,failover,efm"); while( true ) { try (Connection connection = DriverManager.getConnection("jdbc:aws-wrapper:postgresql://" + WRITER + "/read_db", properties)) { try (Statement statement = connection.createStatement()) { try (ResultSet rs = statement.executeQuery("select 1")) { while (rs.next()) ; } } catch (FailoverSuccessSQLException ex) { /* we can safely ignore this error the connection was re-established create the statement again and execute the query. */ } catch (TransactionStateUnknownSQLException ex) { // ignore this as well since we aren't really in a transaction } } catch (FailoverFailedSQLException ex) { /* At this point the driver was unable to re-establish the connection so just loop and get a new connection. */ } catch (SQLException ex) { /* any number of exceptions above, handle as normal */ } try { Thread.sleep(1000); } catch (InterruptedException e) { //ignore } } インスタンスエンドポイントを使って新しいライターを探索し、通常はドライバーが障害を検知してから約6秒で再接続できます。DNS キャッシュを待つ必要がないので、はるかに高速な再接続が可能になっています。 前提条件 Advanced JDBC Wrapper Driver は、 Java Proxy Pattern を利用して実装されています。つまり、ネイティブの PostgreSQL または MySQL ドライバーを依存関係として追加する必要があります。 Advanced JDBC Wrapper Driver を使用するアプリケーションの作成 次のセクションでは、Advanced JDBC Wrapper Driver を使用するアプリケーションを作成するための手順を説明します。 Maven の依存関係追加 Maven を使ってビルドする場合は、pom.xml ファイルに以下の Maven の依存関係を追加してください。 <dependency> <groupId>org.postgresql</groupId> <artifactId>postgresql</artifactId> <version>42.6.0</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.31</version </dependency <dependency> <groupId>software.amazon.jdbc</groupId> <artifactId>aws-advanced-jdbc-driver</artifactId> <version>2.2.3</version> </dependency> IAM プラグインを使用したい場合は、以下も追加する必要があります。 <dependency>     <groupId>software.amazon.awssdk</groupId>     <artifactId>rds</artifactId>     <version>2.20.49</version> </dependency> Secrets Manager プラグインを使用したい場合は、以下も追加してください。 <dependency>     <groupId>software.amazon.awssdk</groupId>     <artifactId>secretsmanager</artifactId>     <version>2.20.88</version>     </dependency> <dependency>     <groupId>com.fasterxml.jackson.core</groupId>     <artifactId>jackson-databind</artifactId>     <version>2.15.2</version>     </dependency> コードを更新する 正しい依存関係を追加した後、Advanced JDBC Wrapper Driver を使うためにアプリケーションにいくつかの変更が必要です。 接続 URL は、PostgreSQL の場合は jdbc:aws-wrapper:postgresql 、MySQL の場合は jdbc:aws-wrapper:mysql にする必要があります。URLの最初の部分で AWS Advanced JDBC Wrapper がロードされ、2番目の部分でどの基盤ドライバーをロードしてプロキシ(Java Proxy Pattern)するかを指示します。 ドライバー機能を指定する 使用したいドライバーの機能を決定します。Advanced JDBC Wrapper Driver はプラグインを使って JDBC メソッドを実行します。プラグインは、JDBC メソッド呼び出しの前後に追加のロジックを加えるための拡張可能なコードモジュールと考えられます。Advanced JDBC Wrapper Driver には、いくつかの組み込みプラグインがあります。これは、 wrapperPlugins ドライバープロパティで設定します。詳細は「 Connection Plugin Manager Parameters 」を参照してください。デフォルト設定は auroraConnectionTracker,failover,efm です。 auroraConnectionTracker プラグインは、フェイルオーバー発生時に障害ノードへのオープン接続をすべて閉じるようにします。failover プラグインは、実際のフェイルオーバーの検知と再接続を処理します。efm プラグインは、フェイルオーバー時の再接続時間を減らすため、積極的にホストを監視します。 Secrets Manager との統合 AWS には Secrets Manager というサービスがあり、秘密情報を安全に保存できます。Advanced JDBC Wrapper Driver にはプラグインが用意されており、ユーザー名とパスワードの値を Secret に保存し、認証時に USER と PASSWORD の値として取得することができます。 必要な設定は、 REGION_PROPERTY 、 SECRET_ID_PROPERTY 、 PLUGINS の3つのプロパティのみです。 以下のコードブロックが例となります: public static void main(String[] args) throws SQLException {     /* Set the AWS Secrets Manager Connection Plugin parameters and     the JDBC Wrapper parameters.     */     final Properties properties = new Properties();     REGION_PROPERTY.set(properties, "us-east-2");     SECRET_ID_PROPERTY.set(properties, "secretId");     // Enable the AWS Secrets Manager Connection Plugin.     PLUGINS.set(properties, "awsSecretsManager");     // Try and make a connection:     try (final Connection conn = DriverManager.getConnection(CONNECTION_STRING, properties);          final Statement statement = conn.createStatement();          final ResultSet rs = statement.executeQuery("SELECT * FROM employees")) {       while(rs.next()){         System.out.println(rs.getString()...);       }     }   } IAM 認証の統合 Advanced JDBC Wrapper Driver は、 IAM 認証 をサポートしています。IAM データベース認証を使用する場合、ホスト URL はカスタムドメインや IP アドレスではなく、有効な Amazon エンドポイントでなければなりません。例: db-identifier.cluster-XYZ.us-east-2.rds.amazonaws.com IAM 認証には AWS Java SDK RDS v2.x が CLASSPATH に別途含まれる必要があります。AWS Java SDK RDS はランタイム依存関係であり、解決されなければなりません。AWS SDK を使う場合は、 AWS_ACCESS_KEY_ID と AWS_SECRET_ACCESS_KEY を設定して認証する必要があります。 IAM データベース認証は、特定のデータベースエンジンに限定されています。制限事項と推奨事項の詳細については、「 MariaDB、MySQL、および PostgreSQL の IAM データベース認証 」を参照してください。 IAM 認証の設定 IAM 認証を設定するには、以下の手順を実行します。 Amazon RDS コンソールで、 既存のデータベース もしくは 新規作成のデータベース に対して IAM データベース認証を有効化 します。 IAM データベース認証用の IAM ポリシーを設定します。 IAM データベース認証を使ってデータベースアカウントを作成します。選択したプライマリ DB インスタンスに接続します。 MySQL データベースの場合、以下のコマンドで新しいユーザーを作成します。 CREATE USER example_user_name IDENTIFIED WITH AWSAuthenticationPlugin AS 'RDS'; PostgreSQL データベースの場合、以下のコマンドで新しいユーザーを作成します。 CREATE USER db_userx; GRANT rds_iam TO db_userx; Advanced JDBC Wrapper Driver で IAM 認証を使うには Advanced JDBC Wrapper Driver で IAM 認証を使う場合のサンプルコードは次の通りです: public class AwsIamAuthenticationPostgresqlExample {   public static final String POSTGRESQL_CONNECTION_STRING =       "jdbc:aws-wrapper:postgresql://db-identifier.XYZ.us-east-2.rds.amazonaws.com:5432/employees";   private static final String USERNAME = "john_smith";   public static void main(String[] args) throws SQLException {     final Properties properties = new Properties();     // Enable AWS IAM database authentication and configure driver property values     properties.setProperty(PropertyDefinition.PLUGINS.name, "iam");     properties.setProperty(PropertyDefinition.USER.name, USERNAME);     // Attempt a connection     try (Connection conn = DriverManager.getConnection(POSTGRESQL_CONNECTION_STRING,     properties);         Statement statement = conn.createStatement();         ResultSet result = statement.                     executeQuery("select aurora_db_instance_identifier()")) {       System.out.println(Util.getResult(result));     }   } } クリーンアップ この記事を通して作成した Aurora クラスターの IAM 認証情報、Secrets Manager の認証情報がある場合は、必ず削除するようにしてください。 まとめ Advanced JDBC Wrapper Driver は、AWS の IAM や Secrets Manager と Aurora が提供するクラスター構成を利用して、認証とフェイルオーバーのソリューションを実現しています。さらに、Aurora の機能を活用することで、フェイルオーバー時間を大幅に短縮できます。このドライバーにはまだ多くの機能があり、今後の投稿で紹介していく予定です。続報をお待ちください！ それまでの間、この投稿に対するコメントをお寄せいただき、 GitHub プロジェクト を訪れて詳細と例を確認してください。 著者について Dave Cramer はAmazon Web Services のシニアソフトウェアエンジニアです。また、PostgreSQL JDBC ドライバのメンテナーとして、PostgreSQL の主要な貢献者でもあります。彼の情熱はクライアントインターフェースとクライアントとの連携にあります。

5月20日週、 Amazon Web Services (AWS) の VP for AI Products である Matt Wood 博士が、ロサンゼルスの AWS Summit で基調講演を行いました。Matt とゲストスピーカーは、生成 AI、開発者ツール、基盤となるインフラストラクチャにおける最新の進歩について話し、これらが一体となってビルダーが実現できる事柄を変えていく方法を紹介しました。 この基調講演は YouTube で視聴 できます。 LA Summit での発表には、2025 年までに世界中の 200 万人に無料の AI スキルトレーニングを提供するという Amazon’s AI Ready イニシアティブ の一環としての 2 つの新しい Amazon Q  コースが含まれていました。これらのコースは Amazon Q 学習プラン の一部になっています。しかし、5月20日週の出来事はこれだけではありません。 5月20日週のリリース 私が注目したいくつかのリリースをご紹介します。 LlamaIndex による Amazon Neptune のサポート – Amazon Neptune に保存されたナレッジグラフと、 Amazon Bedrock で利用できる大規模言語モデル (LLM) のような LLM を使用してアプリケーションを構築するための人気のオープンソースフレームワークである LlamaIndex を組み合わせることで、Graph Retrieval Augmented Generation (GraphRAG) アプリケーションを構築できるようになりました。詳細については、 Amazon Neptune Graph Store に関する LlamaIndex ドキュメント をお読みください。 AWS CloudFormation が DeleteStack API 向けに DeletionMode と呼ばれる新しいパラメータをローンチ – スタックとスタックリソースの削除には、 AWS CloudFormation DeleteStack API を使用することができます。しかし、空ではない Amazon Simple Storage Service (Amazon S3) バケットを削除しようとするときなど、特定のスタックリソースが原因で DeleteStack API が正常に完了しない場合があります。このようなシナリオでは、DeleteStack API が DELETE_FAILED 状態になる可能性があります。このローンチにより、新しい DeletionMode パラメータに FORCE_DELETE_STACK 値を渡して、こういったスタックを削除できるようになりました。詳細については、 DeleteStack API ドキュメント をお読みください。 Amazon Bedrock での Mistral Small の提供開始 – Amazon Bedrock で Mistral AI からの Mistral Small 基盤モデル (FM) の一般提供が開始されました。これは、最近行われた 3 月の Mistral 7B と Mixtral 8x7B、4 月の Mistral Large の発表に続くものです。Mistral AI が開発した Mistral Small は、大規模かつ低レイテンシーの言語ベースのタスク向けに最適化された、きわめて効率的な大規模言語モデル (LLM) です。詳細については、 Esra の記事 をお読みください。 エジプト、カイロの新しい Amazon CloudFront エッジロケーション – この新しい AWS エッジロケーションにより、 Amazon CloudFront が提供するすべてのメリットを利用できるようになります。CloudFront は、低レイテンシーと優れたパフォーマンスで静的/動的コンテンツ、API、ライブ/オンデマンド動画を配信する、高度に分散されたセキュアでスケーラブルなコンテンツ配信ネットワーク (CDN) です。エジプトのお客様は、新しいエッジロケーションを通じて配信されるデータのレイテンシーが、平均で最大 30% 改善されることを期待できます。AWS エッジロケーションの詳細については、 CloudFront エッジロケーション をご覧ください。 Amazon S3 との Amazon OpenSearch Service ゼロ ETL 統合 – この Amazon OpenSearch Service 統合は、Amazon S3 データレイク内にある運用ログをクエリするための新しい効率的な方法を提供することで、データを分析するためにツールを切り替える必要をなくします。これは、Amazon VPC フローログ、AWS WAF ログ、Elastic Load Balancing (ELB) といった AWS ログタイプ向けの追加設定不要なダッシュボードをインストールすることで開始できます。詳細については、 Amazon OpenSearch Service 統合ページ と Amazon OpenSearch Service Developer Guide を参照してください。 AWS からの発表の完全なリストについては、「AWS の最新情報」ページをご覧ください。 AWS のその他のニュース こちらは、皆さんが興味を持つかと思われるその他のニュースと Twitch 番組です。 Build On Generative AI – twitch.tv/aws で、毎週木曜日の午後 2 時 (米国太平洋時間) に配信中です。私の同僚である Tiffany と Mike が生成 AI のさまざまな側面に関するディスカッションを行い、デモを紹介するゲストスピーカーをお招きします。 ショーノートとエピソードの完全なリストについては、community.aws をご覧ください 。 Amazon Bedrock Studio ブートストラッパスクリプト – 皆さんのフィードバックにお応えしました! Amazon Bedrock Studio の使用を開始するために必要な AWS Identity and Access Management (IAM) のロールとアクセス許可のセットアップで苦労したことがあるならば、これからは Bedrock Studio ブートストラッパスクリプト を使用して、アクセス許可の境界、サービスロール、プロビジョニングロールの作成を自動化できるようになります。 今後の AWS イベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 AWS Summits – AWS Summit シーズンがやってきました! クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントに参加しましょう。最寄りの都市でご登録ください。日程は、 ドバイ (5 月 29 日)、 バンコク (5 月 30 日)、 ストックホルム (6 月 4 日)、 マドリッド (6 月 5 日)、 ワシントン DC (6 月 26～27 日) です。 AWS re:Inforce – ペンシルバニア州フィラデルフィアで開催される AWS re:Inforce (6 月 10～12 日) にご参加ください。AWS re:Inforce は、AWS セキュリティソリューション、クラウドセキュリティ、コンプライアンス、アイデンティティに焦点を当てた学習カンファレンスです。セキュリティツールを構築している AWS チームとつながるとともに、AWS のお客様と交流して、それぞれのセキュリティジャーニーについて学びましょう。 AWS Community Days – 世界中のエキスパート AWS ユーザーと業界リーダーがリードするテクニカルディスカッション、ワークショップ、ハンズオンラボが盛り込まれたコミュニティ主導のカンファレンスにぜひご参加ください。日程は、 中西部 | コロンバス (6 月 13 日)、 スリランカ (6 月 27 日)、 カメルーン (7 月 13 日)、 ニュージーランド (8 月 15 日)、 ナイジェリア (8 月 24 日)、 ニューヨーク (8 月 28 日) です。 近日開催されるすべての対面イベントと仮想イベントを閲覧することができます。 5月27日週はここまでです。6月3日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください。 –  Antje この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

5月24日は、 Amazon Bedrock で Mistral AI からの Mistral Small 基盤モデル (FM) の一般提供が開始されたことをお知らせします。これは、最近行われた 3 月の Mistral 7B と Mixtral 8x7B 、4 月の Mistral Large の発表に続くものです。これからは、Amazon Bedrock で Mistral AI からの 4 つの高性能モデルである Mistral Small、Mistral Large、Mistral 7B、および Mixtral 8x7B にアクセスできるようになり、モデルの選択肢がさらに広がります。 Mistral AI が開発した Mistral Small は、大規模かつ低レイテンシーの言語ベースのタスク向けに最適化された、きわめて効率的な大規模言語モデル (LLM) です。Mistral Small は、分類、カスタマーサポート、テキスト生成など、一括で実行できる単純なタスクに最適です。このモデルは、コスト効率性に優れた価格で、非常に優れたパフォーマンスを提供します。 以下は、知っておく必要がある Mistral Small の主要機能です。 検索拡張生成 (RAG) 特化 – Mistral Small は、最大 32,000 トークンに拡張できるロングコンテキストウィンドウでさえも、重要な情報が保持されることを確実にします。 コーディング能力 – Mistral Small は優れたコード生成、レビュー、およびコメント能力を備えており、主要コーディング言語をサポートしています。 多言語機能 – Mistral Small は、英語に加えて、フランス語、ドイツ語、スペイン語、およびイタリア語でもトップクラスのパフォーマンスを提供します。これ以外にも、その他数多くの言語をサポートしています。 Mistral Small の使用開始方法 Mistral Small の使用を開始するには、まずこのモデルにアクセスする必要があります。 Amazon Bedrock コンソール に移動して、 [モデルアクセス] 、 [モデルアクセスを管理] の順に選択します。 [Mistral AI] セクションを展開し、 [Mistral Small] を選択してから、 [変更を保存] を選択します。 これで、Mistral Small モデルにアクセスし、Amazon Bedrock で使用を開始できるようになりました。 [ベースモデル] テーブルを更新して、現在のステータスを表示します。 以下のテンプレートを使用してモデルに対するプロンプトを構築し、準最適出力を取得します。 <s>[INST] Instruction [/INST] <s> は文字列の先頭 (BOS) に置く特別なトークンで、 [INST] と [/INST] は標準文字列であることに留意してください。 分類例を表示するために、以下のプロンプトを試してみます。 プロンプト: <s>[INST] Classify the following email to determine if it is spam or not.Only respond with the exact words "Spam" or "Not spam". 🎉 Limited time offer! Buy 2, Get 1 Free! Offer ends today! Don't miss out the CHANCE TO SAVE, please click on the link below: https://bit.ly/buy-2-get-1-free [/INST] Mistral 7B、Mixtral 8x7B、および Mistral Large はすべて、この E メールを「Spam」として分類します。 Mistral Small も、大規模なモデルと同様にこのメールを正確に分類できます。テキストプロンプトからの Bash スクリプトの生成、ヨーグルトを作るためのレシピの生成など、同じようなタスクをいくつか試してみましたが、これらからも良い結果が得られました。このため、こういったタスクには、Mistral Small が Amazon Bedrock 内の Mistral AI モデルの中で最も効率的でコスト効率性に優れたオプションになります。 Mistral Small は多言語タスクにも長けています。英語に加えて、フランス語、ドイツ語、スペイン語、イタリア語でも優れたパフォーマンスを発揮します。サステナビリティに関する文章を 2 つ提供するように依頼して、ドイツ語に対するモデルの理解度をテストします。 プロンプト: <s>[INST] Geben Sie mir zwei Sätze zum Thema Nachhaltigkeit. [/INST] 出力: 1.Nachhaltigkeit bedeutet, die Bedürfnisse der heutigen Generation zu befriedigen, ohne die Möglichkeiten künftiger Generationen zu gefährden. 2.Ein nachhaltiger Lebensstil umfasst den bewussten Umgang mit Ressourcen, wie Wasser, Energie und Rohstoffen, sowie den Schutz von Umwelt und Klima. Diese Sätze sollten Ihnen einen guten Überblick über das Thema Nachhaltigkeit geben. Mistral Small のプログラム的な操作 Amazon Bedrock API を用いて Mistral Small をプログラム的に操作するには、 AWS コマンドラインインターフェイス (AWS CLI) と AWS Software Development Kit (SDK) を使用できます。Python で以下のコードを使用します。このコードは、AWS SDK を使って Amazon Bedrock Runtime API を操作するもので、「空の色は何色ですか?」とたずねています。 import argparse import boto3 from botocore.exceptions import ClientError import json accept = "application/json" content_type = "application/json" def invoke_model(model_id, input_data, region, streaming): client = boto3.client('bedrock-runtime', region_name=region) try: if streaming: response = client.invoke_model_with_response_stream(body=input_data, modelId=model_id, accept=accept, contentType=content_type) else: response = client.invoke_model(body=input_data, modelId=model_id, accept=accept, contentType=content_type) status_code = response['ResponseMetadata']['HTTPStatusCode'] print(json.loads(response.get('body').read())) except ClientError as e: print(e) if __name__ == "__main__": parser = argparse.ArgumentParser(description="Bedrock Testing Tool") parser.add_argument("--prompt", type=str, help="prompt to use", default="Hello") parser.add_argument("--max-tokens", type=int, default=64) parser.add_argument("--streaming", choices=["true", "false"], help="whether to stream or not", default="false") args = parser.parse_args() streaming = False if args.streaming == "true": streaming = True input_data = json.dumps({ "prompt": f"<s>[INST]{args.prompt}[/INST]", "max_tokens": args.max_tokens }) invoke_model(model_id="mistral.mistral-small-2402-v1:0", input_data=input_data, region="us-east-1", streaming=streaming) すると、以下の出力が得られます。 {'outputs': [{'text': ' The color of the sky can vary depending on the time of day, weather,', 'stop_reason': 'length'}]} 今すぐご利用いただけます 現在、Mistral Small モデルは米国東部 (バージニア北部) リージョンの Amazon Bedrock でご利用いただけます。 詳細については、 Mistral AI in Amazon Bedrock 製品ページ をご覧ください。料金の詳細については、 Amazon Bedrock の料金ページ を参照してください。 Amazon Bedrock で Mistral Small の使用を開始するには、 Amazon Bedrock コンソール にアクセスし、「 Amazon Bedrock User Guide 」を参照してください。 — Esra 原文は こちら です。

はじめに 自動車アプリケーションをクラウドに接続して IoT (モノのインターネット)データを交換することで、自動車に多くの利点をもたらすことができます。安全に認証を行なった接続は、リアルタイムの診断や予防保全のためにクラウドに継続的な遠隔計測データを送信して車両の監視を行う OEM メーカーにとって不可欠です。ソフトウェア、インフォテイメント、マップなどの車載ナビゲーションサービスへの OTA アップデートを OEM が提供できると、車両を修理工場に持って来てもらわなくとも最新の状態に保つのに役立ちます。さらに、クラウドからリアルタイムの交通渋滞や駐車情報などのナビゲーションデータにアクセスすることで、利用者は最適な経路を選択でき、より良い運転体験を得られます。したがって、車載アプリとクラウド間で安全にデータを交換するメカニズムを持つことが、利用者と自動車 OEM の両方にとって重要です。 概要 このブログでは、IoT デバイスからデータを送受信するために、iOS アプリを AWS IoT Core に安全に接続する方法を紹介します。AWS IoT での認証方法はさまざまで、 AWSMobileClient と統合された AWS Cognito ユーザープール の利用や、 X.509 証明書の使用などが可能です。しかし、グローバルに展開されたユーザー数が多数になるアプリケーションの場合、これらの認証方式では現実的ではなくなる可能性があります。Cognito ユーザープールではユーザー毎のプロビジョニングが必要になるため、スケーラビリティの問題が生じるかもしれません。一方、X.509 証明書の場合は、大規模な環境でキーの配布と更新が課題となります。したがって、グローバルなアプリデプロイのためには、他の大規模展開に適した認証方式を評価する必要があります。 従来、車両モジュールでは Bluetooth Low Energy (BLE) を使用してモバイルアプリにテレメトリデータを送信していました。ここから、テレメトリデータの分析のためにクラウドハイパースケーラーに安全に接続する必要があります。これは、 AWS IoT SDK for iOS を使用して実現できます。この SDK には、iOS アプリから AWS IoT Core と簡単に対話できるようサポートするライブラリセットが含まれています。このブログでは、MQTT over WebSocket プロトコルを使って iOS アプリを AWS IoT に接続する方法について説明します。これにより、ユーザーはアプリを配布する際に個別の X.509 証明書を発行する必要がなくなります。 AWS IoT Core は、自動車業界の顧客が IoT アプリケーションの開発と管理で幅広く利用されている、多機能で強力なサービスです。AWS IoT Core には、自動車業界の顧客に次のことを支援する機能がいくつかあります。1/ AWS IoT Jobs を使用した車両向けの Over-The-Air ファームウェアやソフトウェアのアップデート、2/ 車両の診断データの収集と分析、3/ 接続された車両、アプリケーション、顧客のデータを保護するための認証と認可機能。Amazon Cognito Identity Pools は、モバイルや Web アプリケーションが特定の AWS リソースにアクセスするためのゲストユーザーアクセスを提供することを目的としています。これにより、非認証ユーザーに限定的なアクセスを許可できます。具体的に、Cognito Identity Pools は、アプリケーションがユーザー認証を必要とせずに、許可されたリソースに事前に定義された権限でアクセスできるように一時的な AWS 認証情報を取得できるようにすることで、ゲストアクセスをサポートしています。このようなゲストアクセスに、顧客が実装するボット検出などの制御を組み合わせることで、より機密性の高いデータや機能へのアクセスは制限しつつ、アプリケーションの一部をログインしていないゲストでも利用できるようになります。全体として、ゲストユーザーアクセスは Identity Pools の重要な機能であり、アプリケーションのアクセシビリティとセキュリティを両立させるのに役立ちます。 前提条件 ブログで説明する認証ソリューションの前提条件は以下の通りです。 動作する iOS アプリケーション Amazon Cognito および AWS IoT Core の基本的な知識 Amazon Cognito で作成されたユーザープール ソリューション概要 図 1 – iOS アプリを AWS IoT サービスに認証および接続するためのハイレベルアーキテクチャ 手順 Amazon Cognito ユーザープールの初期設定については、 新しいユーザープールを作成する のステップ 7 までを参照してください。ユーザープールを作成したら、以下の手順に従って iOS アプリケーションを統合できます。 ステップ 1: アプリを Amazon Cognito に統合する 1.1 ユーザープールの名前 (図 2 を参照) セットアップガイドで作成したユーザープールを参照してください。このブログ記事では example-user-pool を使用します。 図 2: 作成したユーザープールにアプリを統合 1.2 ホストされた認証ページ (図 3 参照) ユーザー登録/ログインフローには、 Cognito が提供する UI と OAuth 2.0 サーバー を使用できます。この機能を有効にすると、Cognito が提供する UI と OAuth 2.0 エンドポイントのドメインを構成できるドメインペインが表示されます。 このシナリオでは、独自のカスタムフロントエンド UI を使用するため、チェックボックスを選択を外した状態のままにします。この項目は、ユーザープール名のテキストボックスの下にあります。下図を参照してください。 図 3: ホストされた認証ページ 1.3 初期アプリクライアント （図 4 を参照） OAuth 2.0 標準では、Public と Confidential の 2 種類のクライアントタイプが定義されています。アプリのクライアントに最適な設定は、作成するアプリの種類によって異なります。Public client または Confidential client のデフォルト設定を選択できます。あるいは、必要に応じて設定をカスタマイズすることもできます。 この例では、「Public client」を利用します。 アプリクライアント名には、example-app-client を利用します。 クライアントシークレットについては、この例のアプリケーションでは認証を使用する必要がないため、デフォルトの Don’t generate a client secret  オプションを選択したままにします。 図 4: app clientの設定 次のデプロイステップに進む準備ができたら、 Next を選択してください。 ステップ 2: レビューと作成 選択内容を確認し、すべて正しければ (図 5 を参照) 、ページの下部にある Create user pool を選択します。 図 5: ユーザープールの確認と作成 Amazon Cognito の ユーザープールページ内で、作成したユーザープールを確認できます （図 6 を参照） 。 図 6: User pool 注意: ユーザープールの作成後は、「user pool ID」と「app Client ID」を次のセクションのステップ 2 で利用するために保存してください。ID の見つけ方については、この 資料 を参照してください。 AWS IoT との iOS 統合 次のステップは、テレメトリデータを送信するために iOS アプリを AWS IoT に接続することです。このサンプルでは、Xcode v15.1 で Swift プログラミング言語 (v5.9.2) を使用して、 AWS SDK for iOS で AWS IoT に接続します。 Step 1: 開発 IDE に AWS IoT モジュールをインストールする iOS プロジェクトに AWS IoT フレームワークを追加するには、 CocoaPods を利用するか、AWS IoT モジュールを手動でインストールしてください。 これで、AWS IoT に接続するためのクライアントライブラリが追加されます。 関数ヘッダに import 文を追加してください。 Import AWSIoT Step 2: AWS 認証情報を Amazon Cognito Identity Pool と AWSIoTDataManager を使用して初期化する AWS Cognito で Identity Poolを作成し、pool ID を取得します。 Amazon Cognito コンソールで、左側のパネルから Identity pools を選択し、 Create identity pool を選びます。 認証済みアクセスのボックスをチェックしてください。 Authentication provider の項目を開き、 Cognito タブを選択して進んでください。 Create a new IAM role を選択してください。注記: 初期の最小限の許可と identity poolとの信頼関係を持つIAM ロールを作成します。ID プールを作成した後、IAM コンソールで許可を追加します。 前の手順で作成した ユーザープール ID と アプリケーションクライアント ID を入力してください。 Identity プール名 に testpool と入力し、 次へ をクリックしてください。 Create Identity Pool を選択します。 Edit identity pool を選択します。ID プールの ID を控えてください (例: us-east-1:xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxx)。 AWS Mobile SDK の CognitoCredentialsProvider クラスを使用して、認証情報プールから AWS の認証情報を取得します。 let session = try await Amplify.Auth.fetchAuthSession() if let identityProvider = session as ? AuthCognitoIdentityProvider { let identityId = try identityProvider.getIdentityId().get() print("Identity ID: \(identityId)") } Step 3: AWS IoT で認証するためのクライアント ID の取得 AWS IoT にクライアントを識別するための一意のクライアント ID を生成します。 これは、 getIdentityId() メソッドを使用して AWSCredentialsProvider オブジェクトから取得できます。 Step 4: 前のステップで取得した認証情報を使用して AWSIoTDataManager のインスタンスを作成します。このマネージャーが MQTT 接続を処理します。 let iotEndPoint = AWSEndpoint( urlString: "wss://a123456789012-ats.iot.us-west-2.amazonaws.com/mqtt" ) let iotDataConfiguration = AWSServiceConfiguration( region: AWSRegionType.uswest2, endpoint: iotEndPoint, credentialsProvider: CredentialsProxy() ) AWSIoTDataManager.register(with: iotDataConfiguration !, forKey: "MyAWSIoTDataManager") let iotDataManager = AWSIoTDataManager(forKey: "MyAWSIoTDataManager") Step 5: WebSocket を使用して AWS IoTにMQTT 接続を作成 AWSIoTDataManager を使用して、AWS IoT プラットフォームエンドポイントへの WebSocket 接続を作成します。 エンドポイントは、利用している AWS リージョンに依存します。たとえば、xxxxxxxxxx- ats.iot.us-east-1.amazonaws.com エンドポイント情報は IoT Core コンソールの設定ページから取得できます (図 7 を参照)。 図 7: IoT コンソールのデバイスデータエンドポイントの位置 AWS IoT のパブリッシュとサブスクライブ機能を利用するには、AWS IoT コンソールで必要な IAM ポリシーを作成し、Amazon Cognito Identity にアタッチする必要があります。次の手順を参照してください。 IoT ポリシーを作成するには、IoT Core コンソールに移動し、左側のナビゲーションペインから [Secure] を選択してから、ドロップダウンメニューから [Policies] を選択します。次に [Create] をクリックします。以下の myIOTPolicy ポリシーは、すべてのトピックに対する完全なアクセス権を許可します。 図 8: publishとsubscribeを許可するIoT Policy Cognito ID にポリシーをアタッチするには、まず AWSMobileClient から Cognito Identity Id を取得します。 AWSMobileClient.default().getIdentityId(); 次に、次の AWS CLI コマンドで、 myIOTPolicy ポリシーをユーザーの Cognito Identity Id に割り当てる必要があります。 aws iot attach-principal-policy --policy-name 'myIOTPolicy' --principal '<YOUR_COGNITO_IDENT Step 6: テスト トピックへのパブリッシング/サブスクリプション (オプション) AWS IoT コンソールページの MQTT テストクライアントで、 トピックにパブリッシュするセクション に移動し、モバイルアプリにメッセージをパブリッシュします。 メッセージを受信するために、MQTT のトピックに購読します。 AWS IoT コンソールを開きます。 ナビゲーションペインで [Test] を選択してください。 「Subscribe to a topic」で「#」を入力すると、すべてのトピックに購読できます。 Subscribe を選択してください。 この時点で、テレメトリ接続のための iOS アプリと IoT の統合を設定しました。 クリーンアップ 本ブログで説明した推奨ソリューションに従った場合、AWS アカウントへの不要な課金を避けるため、以下のステップを実行してください。 Amazon Cognito ユーザープール example-user-pool とクライアントアプリ example-app-client を削除します。 Amazon Cognito > Userpools > ユーザープールを削除 をクリックします。これによりクライアントアプリとユーザープールが削除されます。 identity poolの  testpool を削除します。 Amazon Cognito > identity pools > 対象の identity poolを選択 > delete AWS IAM ロール testrole を削除する IAM > ロールに移動し、作成したロールを削除します 利点 この解決策のお客様へのメリットは以下のようなものが含まれます。 このソリューションは、iOS アプリケーション、特に自動車業界のアプリケーションを AWS IoT Core に接続する際に、スケーラブルかつシンプルな認証を可能にします。個別のユーザープロビジョニングや X.509 証明書の管理が大規模な場合は困難になりますが、この必要性を回避します。 代わりに、 Amazon Cognito Identity Pools を利用して、ログインなしで一時的かつ限定的なゲストアクセスを提供します。 このソリューションは、iOS アプリのための総合的で安全な IoT 統合を提供するため、いくつかの AWS サービスを使用しています。 AWS IoT SDK for iOS は、AWS IoT Core とシームレスに対話するためのライブラリを提供します。 この解決策は、自動車メーカーが IoT のユースケース、例えば車両のソフトウェアアップデート、使用状況に基づく保険モデル、車両の診断、接続された車両、アプリケーション、ユーザーデータのセキュリティ確保に役立つために利用できます。 まとめ 自動車アプリケーションをクラウドに安全に接続することは、自動車メーカーがリモート診断、OTA (Over-the-Air) アップデート、より正確な車両ナビゲーションなどの最新の自動車機能を実現するための重要な課題です。このブログ記事では、自動車メーカーが AWS Cognito Identity Pools を使用して AWS IoT Core に接続する iOS アプリに、よりスケーラブルかつ安全な認証メカニズムを実現する方法を示しました。この記事では、Cognito Identity Pools と iOS アプリを統合する方法、WebSocket 経由で AWS IoT Core との MQTT 接続を確立する方法、IoT トピックのパブリッシュ/サブスクライブに適切な IAM ポリシーを設定する方法を説明しています。全体として、このアーキテクチャにより、自動車用の iOS アプリと AWS クラウドの間で双方向に IoT データを交換するためのセキュアでスケーラブルな接続が実現できます。Amazon Cognito の実践的な経験を積むには、 このワークショップ を参照してください。また、AWS IoT Core に接続するエンドツーエンドのモバイル iOS アプリを構築するには、 このガイド を参照してください。 Chirayu Parikh Chirayu Parikhはペンシルベニア州コレッジビルに拠点を置くシニアテクニカルアカウントマネージャーです。彼はAWSエンタープライズサポートの自動車戦略産業組織に所属し、大手自動車メーカーのクラウドジャーニーをサポートしています。AWSに入社する前は、10年以上にわたってエンタープライズネットワーキングソリューションの顧客をサポートしていました。 Vanshaj Kochar Vanshaj Kocharは、自動車および製造業界向けビジネスユニットのソリューションアーキテクトであり、AWSクラウド上で安全で、スケーラブルで、堅牢なクラウドソリューションを構築するお客様をサポートしています。電子工学および組み込み工学の経験を持ち、自動車およびIoT技術分野のコミュニティにも積極的に貢献しています。また、AWSEducateイニシアチブにも関わり、カナダの大学生にクラウドスキルを身につけてもらう活動も行っています。 この記事は Chirayu Parikh と Vanshaj Kochar によって書かれた Connecting and Authenticating Automotive iOS App to AWS IoT Core の日本語訳です。 この記事は シニア プロトタイピング ソリューション アーキテクトの市川 純が翻訳しました。

株式会社第一興商 は、業務用カラオケシステム「DAM」の開発・運用を手掛けています。グループ全体で 3,300 名ほどの従業員が所属しています。通信カラオケ機器は各市場向けのモデルとして BOX 向け、ナイト店向け、ホテル向け、エルダー向けなど多くの機種をサポートしております。 同社では、このようなカラオケ機器に関する問い合わせ対応のために、営業向けの社内ヘルプデスクを設置しています。ヘルプデスクは 日勤交代制の 12 名体制で、機器の不具合や状況確認に関する 1 日平均 300 件の問い合わせに対応しています。 一方でヘルプデスクでは、問い合わせ内容を手作業で CRM に入力する必要があり、作業負荷と内容のばらつきが課題となっていました。具体的には、実際のカラオケ機器を操作しながら問い合わせに回答するため、リアルタイムにメモを取ることができません。そして受電を優先しているため CRM への記録が後回しとなり、結果として録音データを聞き直して入力する場合もあります。加えて、記録内容は個人の文章能力に依存しており、必要な情報が含まれていないこともありました。 検証内容 このような課題を解決するため、第一興商では AWS のサービスを活用した以下の検証を実施しました。 ヘルプデスクの録音データを Amazon Simple Storage Service (Amazon S3) にアップロード Amazon Transcribe を使用して文字起こし Amazon Bedrock の Claude 2 を使用して通話内容を要約   そして、要約された内容とヘルプデスク担当者が手動で入力した内容を比較し、①修正なし、②少量の修正が必要、③修正が必要、の 3 段階で評価、①と②を合格として検証しました。 また今回の検証は、入社 1 ヶ月の社員を中心に実施しました。AWS を利用するのは初めてのメンバーでしたが、約 3 週間で検証作業を完了することができました。 検証結果 その結果として、検証データ 58 件のうち 約 90 % が「一定の要約品質基準を満たす」という良好な結果が得られました。少量の修正が必要な箇所はあったもの、作業負荷の大幅な軽減が期待できます。第一興商の執行役員である関澤様からは「AWS の技術が『多種多様の問い合わせを行う営業現場とヘルプデスクの会話』を見事に要約し、精度に驚きを実感した」とコメントをいただきました。 また今回の検証にあたって、複数部署に対して現状の運用をヒアリングした上で、多くの録音データを聞く必要がありました。結果として、他部署の業務内容や発生する不具合を知ることができるという、新入社員にとっても思わぬメリットもありました。 今後の展望 第一興商では今回の検証結果を受けて、ヘルプデスク業務における生成 AI 機能の導入が進んでいます。今後はこの要約内容を FAQ システムと統合し、さらなる業務の効率化を図っていく予定です。 並行して、Amazon Bedrock に関する 2 つの検証を続けています。1 つ目が入力 Prompt の改良です。Prompt に詳細な情報を追加することで、精度は 95 % を超え、また出力形式を指定することが可能になりました。これによりシステム連携が容易になります。2 つ目に Claude 3 Haiku の検証です。Claude 2 よりも料金を 90 % 以上削減しながらレスポンスまでの時間を短縮できる見込みです。 またこの技術を活用してヘルプデスクの文字起こしだけでなく、会議の議事録などに生成 AI を導入し、時間を節約していきたいと考えています。これにより、本業であるカラオケの開発や企画などに、一層力を注ぐことができます。 まとめ 今回の検証を通して、Amazon Bedrock と Amazon Transcribe を使用した通話音声要約ソリューションが、ヘルプデスクの作業軽減に繋がることを確認できました。第一興商では、今後も AWS の先進的なテクノロジーを活用し、本業であるカラオケ機器の開発や企画により一層注力していく考えです。

本記事は、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 博士は、通信ネットワークとデータセンターコンピューティングの分野における卓越性と多大な貢献により、インド国立工学アカデミーの外国人フェローに選出されました。   原文は こちら です。 翻訳はソリューションアーキテクトの鈴木 浩之が担当しました。