本記事は 2024年6月11日に公開された ” Simplify global security inspection with AWS Cloud WAN Service Insertion ” を翻訳したものです。 AWS Cloud WAN は、データセンターやブランチオフィス、 Amazon Virtual Private Cloud (Amazon VPC) VPC を接続する広域ネットワーク (WAN) の構築・運用に使用できるマネージド型の WAN サービスです。ネットワークポリシーを使用して、ネットワーク管理とセキュリティタスクを一元的に設定・自動化し、グローバルネットワークの完全な可視性を得ることができます。 サービス開始 以来、グローバルネットワークの作成とリソース間の接続を容易にする機能により、AWS Cloud WAN の認知度は高まっています。しかし、この接続性を重視したことに伴い、AWS ネイティブまたはサードパーティのファイアウォールを使用する際のセキュリティ検査機能の必要性が高まっています。お客様は、ネットワークの検査と保護の方法を求めており、AWS Cloud WAN を使用した安全なグローバルネットワークの設計に関するガイダンスを必要としています。お客様の理解を深めていただくため、AWS Cloud WAN を使用した安全なグローバルネットワークの設計方法について、すでにいくつかの ブログ記事 を公開しています。 従来のセキュリティ検査アプローチにおける課題 既存の検査アーキテクチャパターンには多くの利点がありますが、特に AWS Cloud WAN で大規模に展開する際に、お客様はいくつかの課題に直面してきました。 インスペクションセグメントが共有されているため、Classless Inter-Domain Routing (CIDR) を使用する VPC ルートは、各 VPC アタッチメントをネクストホップとして、インスペクションセグメントのルートテーブルに動的に伝播されます。そのため、それぞれのファイアウォールにトラフィックをルーティングするためには、新しく追加された VPC ごとに、AWS Cloud WAN のインスペクションセグメントルートテーブルに静的ルートを設定する必要がありました。 マルチリージョンネットワークのための AWS Cloud WAN による最適なルーティングの実現 で説明されているような、マルチ AWS リージョンの地域分散型検査アーキテクチャは複雑さを伴います。 1 つのグローバルインスペクションセグメントでは、既存のソリューションで各リージョンのファイアウォールを経由してトラフィックを強制的にルーティングする方法がありませんでした。各 AWS リージョンでトラフィックを検査するという要件を満たし、対称的なルーティングを維持するために、顧客は各リージョンまたはエッジロケーションに固有のグローバル共有インスペクションセグメントを作成する必要がありました。 それぞれの共有インスペクションセグメントは、コアネットワークごとのセグメントの クォータ としてカウントされます。 このブログ記事では、AWS Cloud WAN Service Insertion (Service Insertion) という新機能について説明します。この機能を使用すると、中央ポリシードキュメントを使用して AWS および他社のネットワークおよびセキュリティサービスを AWS Cloud WAN に組み込むことができ、運用の簡素化を実現できます。この機能を使用することで、シンプルなポリシーステートメントを定義するか AWS マネジメントコンソールを使用して、VPC 間、インターネットエグレス、ハイブリッド環境のトラフィックをネットワークまたはセキュリティアプライアンスに容易に振り分けることができます。また、この機能は、East-West (VPC 間) および North-South (インターネットエグレス) のセキュリティ検査のためにインスペクション VPC にデプロイされた AWS Network Firewall や Gateway Load Balancer などの AWS サービスへのポリシーベースのトラフィック誘導もサポートしており、セキュリティインフラストラクチャを AWS Cloud WAN デプロイメントの他の部分とシームレスに統合できます。 Service Insertion のメリット お客様は AWS Cloud WAN を使用して一元化されたセキュリティアーキテクチャをデプロイすることで、セキュリティリソースを統合し、管理の負担を軽減し、セキュリティインフラストラクチャのコストを削減できます。セキュリティ検査機能には、East-West、North-South、またはハイブリッド環境の保護が含まれます。 Network Service Insertion のためのルーティングの簡素化： お客様は、VPC 間、VPC からインターネット、またはオンプレミスへのトラフィックを、ネットワークファイアウォールやロードバランサーなどのネットワークアプライアンスを経由させる必要がよくあります。AWS Cloud WAN Service Insertion により、複雑なルーティング設定を作成・管理したり、サードパーティの自動化ツールを使用したりすることなく、VPC にデプロイされたネットワークやセキュリティアプライアンスに対象のネットワークトラフィックを簡単に転送できます。 マルチリージョンのセキュリティ検査の容易なデプロイ： ほとんどの AWS Cloud WAN のお客様は、リージョン拡張や災害復旧のユースケースに対応するため、マルチリージョンネットワークをデプロイしています。Service Insertion 機能により、マルチリージョンのデプロイが簡素化され、複雑なマルチリージョンネットワーク設定を必要とせずに、リージョン内およびリージョン間のトラフィックをセキュリティインフラストラクチャ経由に振り分けることができます。 主要な概念 このブログ投稿では、 AWS Cloud WAN のコンポーネント であるグローバルネットワーク、コアネットワーク、コアネットワークポリシー、アタッチメント、コアネットワークエッジ、ネットワークセグメントについて理解していることを前提としています。 上記で説明した概念に加えて、このブログ記事で説明するアーキテクチャを理解するためには、AWS Cloud WAN Service Insertion 機能の新しいコンポーネントである Network Function Group (NFG) を理解することが重要です。 Network Function Group (NFG) NFG は、内部的には、NAT、ファイアウォール (AWS Network Firewall や Gateway Load Balancer、またはサードパーティサービス)、侵入検知・防止システム、データ損失防止など、グローバルな AWS Cloud WAN ネットワークの一部として展開される特殊なネットワークやセキュリティ機能を指すコアネットワークアタッチメントの集合で構成される単一のセグメントです。 NFG を使用すると、AWS Cloud WAN に接続された VPC やオンプレミスネットワークにデプロイされたネットワーク機能 (Network Function) を使用して、同一セグメント間または異なるセグメント間のトラフィックを自動的に制御できます。ネットワーク機能が存在するコアネットワークアタッチメント (VPC、Site-to-Site VPN、Connect、Transit Gateway ルートテーブル) のセットを含む NFG を指定できます。さらに、トラフィックをネットワーク機能にリダイレクトする必要があるセグメントまたはセグメントペアを指定できます。AWS Cloud WAN は、それぞれの NFG に対して指定されたコアネットワークアタッチメントを通じて、セグメント間のネットワークトラフィックを自動的にリダイレクトします。このリダイレクトは、コアネットワーク上の同一リージョン (リージョン内) およびクロスリージョン (リージョン間) のトラフィックの両方で機能します。AWS Cloud WAN の コアネットワークポリシードキュメント を使用して、以下のように主要な設定項目を指定できます： 1 つまたは複数のネットワーク機能を表す NFG。 NFG の一部であるコアネットワークアタッチメント。 ネットワーク機能を使用して制御する必要がある、セグメント間またはセグメント内のトラフィックを持つセグメント (シナリオ 2 のアタッチメント)。 Cloud WAN のネットワークセグメントと NFG の主な違いを理解することも重要です。 コアネットワークセグメント コア Network Function Group (NFG) セグメントは独立したルーティングドメインで、セグメント内外のルーティングを完全に制御しながらアタッチメントを関連付けることができます。例えば、セグメント内でルートの追加や削除、セグメント間でのルートの共有が可能です。 NFG は独自のルートテーブルを持ち、これらのルートはポリシードキュメントの Service Insertion 設定に基づいて（ネクストホップの転送先とともに）自動的に伝播されます。これらのルートを確認することはできますが、NFG 内でのルートの追加、削除、共有はできません。 Cloud WAN セグメントにアタッチメントを関連付けると、VPC の CIDR やダイナミックルートが、それぞれのセグメントルートテーブルに伝播されます。 NFG にアタッチメントを関連付けても、VPC の CIDR やダイナミックルートは NFG ルートテーブルに伝播されません。 トラフィックを制御するために、NFG は以下の セグメントアクション を導入します。 ‘ send-via ‘: NFG のアタッチメントを介して、同一セグメントまたは異なるセグメント間のワークロード間のトラフィックを、ネクストホップを上書きして制御します。 ‘single hop’ : 優先されるソースまたはデスティネーションリージョンを使用して、トラフィックは単一の中間アタッチメントを通過します。使用するリージョンのリストを設定でき、優先的に使用するリージョンを設定することもできます。 ‘dual-hop’ : トラフィックは、ソースとデスティネーションの両方のコアネットワークエッジに挿入されたアタッチメントを通過します。このオプションでは、インスペクションアタッチメントは、Service Insertion が有効化された各セグメントのすべてのリージョンに配置される必要があります。 ‘ send-to ‘: NFG のアタッチメントを介して、セグメントに関連付けられたワークロードからのエグレストラフィックを、デフォルトルート (0/0, ::/0) を使用してインターネットまたはハイブリッドに転送するために使用します。 これらの概念の詳細については、 AWS Cloud WAN ドキュメント をご参照ください。 図 1: Service insertion NFG アーキテクチャ ここでは、以下の 3 つのシナリオに焦点を当てます。 リージョン内、セグメント間のインスペクション リージョン間、セグメント間のデュアルインスペクション リージョン間、セグメント間のシングルインスペクション シナリオ 1 – リージョン内、セグメント間のインスペクション 次の図 (図 2) は、シナリオ 1 を示しています。このシナリオでは、同一リージョン内の異なるセグメントにあるアタッチメントが、インスペクションアプライアンスを介してのみ相互に通信する必要がある場合を示しています。たとえば、開発チームが本番環境にエンジニアリング変更をプッシュする必要がある場合です。Prod VPC (10.1.0.0/16) と Dev VPC (10.11.0.0/16) は同じリージョン (リージョン 1) にありますが、それぞれ Prod セグメントと Dev セグメントに関連付けられています。Inspection VPC 1 (100.64.1.0/24) も同じリージョンに存在します。 図 2: リージョン内、セグメント間のインスペクション 同一リージョン内の Prod VPC 1 から Dev VPC 1 へのトラフィックパスに NFG を挿入するために必要なステップを見ていきましょう： Step 1: 以下に示すサンプルポリシーを使用して、InspectionNFG Network Function Group (NFG) を作成します。 "network-function-groups": [ { "name": "InspectionNFG", "require-attachment-acceptance": false } ], Step 2: 以下に示すサンプルの アタッチメントポリシー を使用して、Inspection VPC 1 アタッチメントを InspectionNFG NFG に関連付けます。 "attachment-policies": [ { "rule-number": 100, "condition-logic": "or", "conditions": [ { "type": "tag-exists", "key": "stage" } ], "action": { "association-method": "tag", "tag-value-of-key": "stage" } } ] Step 3: segment-actions を設定してネットワーク機能 (すなわち Inspection VPC 1) をトラフィックパスに組み込む前に、Inspection VPC 1 アタッチメントが作成され、InspectionNFG に関連付けられていることを確認する必要があります。以下に示すサンプルの AWS CLI を使用してアタッチメントを作成できます。 aws networkmanager create-vpc-attachment \ --core-network-id "<core-network-id>" \ --vpc-arn "<vpc-arn>" \ --subnet-arns "<subnet1-arn>" "<subnet2-arn>" \ --tags Key=stage,Value=InspectionNFG Step 4: Inspection VPC 1 アタッチメントを作成し、Inspection NFG に関連付けたので、以下に示すサンプルの segment-actions を使用して、セグメント間トラフィックに InspectionNFG NFG を組み込みます。 "segment-actions": [ { "action": "send-via", "segment": "prod", "mode": "single-hop", "when-sent-to": { "segments": "*" }, "via": { "network-function-groups": [ "InspectionNFG" ] } } ], “when-sent-to ” の配下の “segments”: “*” はすべてのセグメントを意味します。つまり、Prod と他のセグメント (例えば、Dev、Test、Stage、QA など) の間で送信されるすべてのトラフィックが対象となります。”*” は、分離されたセグメントに対してセグメント内でのサービス挿入も提供します。 Inspection VPC 1 ネットワーク機能を通信経路に組み込むと、Prod セグメントと Dev セグメント間 (または、コアネットワークに存在する他のセグメント間) のすべてのトラフィックは、タグキー stage とタグ値 InspectionNFG を持つコアネットワークアタッチメントを使用して、Inspection VPC 1 のファイアウォールを経由して自動的に経路制御されます (図 3)。AWS Cloud WAN は以下の処理を行います: すべてのワークロードセグメントからのルートを、適切なワークロードアタッチメントにリダイレクトするネクストホップとともに、InspectionNFG ルートテーブルに伝播します。同一リージョン内で伝播されるルートは、そのネクストホップがローカルの NFG アタッチメントにリダイレクトされます。 注意： 後述のシナリオで説明するリージョン間ルーティングの場合、異なるリージョンからのルートは、ユーザー設定またはシステムデフォルトで設定された優先リージョンの NFG アタッチメントにネクストホップがリダイレクトされます。 ポリシーで指定されたすべてのセグメントペアについて、対応するワークロードセグメントルートテーブルにルートを伝播し、ネクストホップをローカルの NFG アタッチメントとして設定します。 図 3: リージョン内のセグメント間インスペクショントラフィックフロー Packet walkthrough: 以下のステップでは、同一リージョン内の Prod VPC 1 のリソースが Dev VPC 1 のリソースと通信する際のパケットの流れについて説明します。 (A) Prod VPC 1 のリソースが Dev VPC 1 のリソースへの接続を開始すると、Prod VPC 1 のルートテーブルを参照します。パケットはデフォルトルートエントリにマッチし、ターゲットとしてコアネットワークの Amazon リソースネーム (ARN) が指定されているため、パケットはコアネットワークにルーティングされます。 (B) パケットがコアネットワークに到達すると、Prod VPC 1 は Prod セグメントに関連付けられているため、Region 1 をエッジロケーションとして Prod セグメントのルートテーブルを参照します。パケットは Dev VPC 1 CIDR エントリにマッチし、Inspection VPC 1 アタッチメントがターゲットとなっているため、パケットは Inspection VPC 1 にルーティングされます。 (C) Inspection VPC 1 のファイアウォールが、設定されたセキュリティポリシーに基づいてトラフィックを検査し許可した後、パケットはコアネットワークに戻されます。 (D) パケットがコアネットワークに到達すると、Inspection VPC 1 は InspectionNFG に関連付けられているため、Region 1 をエッジロケーションとして InspectionNFG ルートテーブルを参照します。パケットは Dev VPC 2 CIDR エントリにマッチし、Dev VPC 1 アタッチメントがターゲットとなっているため、パケットは Dev VPC 1 にルーティングされます。 戻りトラフィックは、同じパスを逆方向にたどります。 シナリオ 2 – リージョン間、セグメント間のデュアルインスペクション 次の図 (図 4) はシナリオ 2 を示しています。シナリオ 2 はシナリオ 1 と似ていますが、Prod VPC と Dev VPC が異なるリージョンに配置されている点が異なります。Prod VPC 1 (10.1.0.0/16) はリージョン 1 に配置され、Prod セグメントに関連付けられています。一方、Dev VPC 2 (172.25.0.0/16) はリージョン 2 に配置され、Dev セグメントに関連付けられています。 異なるセグメント間のアタッチメント間を流れるトラフィックを検査する必要性に加えて、各 AWS リージョンを個別の保護された環境として扱う必要がある場合もあります。これを実現するために、各リージョンには独自の Inspection VPC があり、リージョン 1 には Inspection VPC 1 (100.64.1.0/24)、リージョン 2 には Inspection VPC 2 (100.64.2.0/24) があります。シナリオ 1 (Step 1-3) と同様に、InspectionNFG NFG を作成し、両方の Inspection VPC を InspectionNFG に関連付けます。 図 4: リージョン間、セグメント間のデュアルインスペクション 以下に示す segment-actions モードの dual-hop を使用して、リージョン間、セグメント間のトラフィックパスに InspectionNFG NFG を挿入します。これにより、各リージョンの Inspection VPC にトラフィックを振り分けすることが可能になります。 "segment-actions": [ { "action": "send-via", "segment": "prod", "mode": "dual-hop", "when-sent-to": { "segments": "*" }, "via": { "network-function-groups": [ "InspectionNFG" ] } } ], Inspection VPC 1 と Inspection VPC 2 のネットワーク機能を通信経路に挿入すると、Prod セグメントと Dev セグメント間 (または、コアネットワークに存在する他のセグメント間) のすべてのクロスセグメントトラフィックは、タグキー stage とタグ値 InspectionNFG を持つコアネットワークアタッチメントを使用して、それぞれ Inspection VPC 1 と Inspection VPC 2 のファイアウォールを経由して自動的にルーティングされます。これを図 5 で示します。 図 5: リージョン間、セグメント間のデュアルインスペクションのトラフィックフロー Packet walkthrough: 以下のステップは、Prod VPC 1 のリソースが Dev VPC 2 のリソースと通信する際のパケットの流れについて説明します。 (A) Prod VPC 1 のリソースが Dev VPC 2 のリソースへの接続を開始すると、Prod VPC 1 のルートテーブルを参照します。パケットはターゲットとしてコアネットワーク ARN を持つデフォルトルートエントリに一致し、パケットはコアネットワークにルーティングされます。 (B) パケットがコアネットワークに到着すると、Prod VPC 1 が Prod セグメントに関連付けられているため、Region 1 をエッジロケーションとして Prod セグメントのルートテーブルを参照します。パケットは、ターゲットとして Inspection VPC 1 アタッチメントを持つ Dev VPC 2 CIDR エントリに一致し、パケットは Region 1 の Inspection VPC 1 にルーティングされます。 (C) Inspection VPC 1 のファイアウォールが、設定されたセキュリティポリシーに基づいてトラフィックを検査し許可した後、パケットはコアネットワークに戻されます。 (D) パケットがコアネットワークに到着すると、Inspection VPC 1 が InspectionNFG に関連付けられているため、Region 1 をエッジロケーションとして InspectionNFG ルートテーブルを参照します。パケットは、ターゲットとして Inspection VPC 2 アタッチメントを持つ Dev VPC 2 CIDR に一致し、パケットは Region 2 の Inspection VPC 2 にルーティングされます。 (E) Inspection VPC 2 のファイアウォールが、設定されたセキュリティポリシーに基づいてトラフィックを検査し許可した後、パケットはコアネットワークに戻されます。 (F) パケットがコアネットワークに到着すると、Inspection VPC 2 が InspectionNFG に関連付けられているため、Region 2 をエッジロケーションとして InspectionNFG ルートテーブルを参照します。パケットは、ターゲットとして Dev VPC 2 アタッチメントを持つ Dev VPC 2 CIDR エントリに一致し、パケットは Dev VPC 2 にルーティングされます。 戻りトラフィックは、同じパスを逆方向にたどります。 シナリオ 3 – リージョン間、セグメント間のシングルインスペクション リージョンペアの場合、Service Insertion により、セグメント間のトラフィック検査を行うリージョンを選択できます。リージョン間およびセグメント間のトラフィック検査に使用するリージョンを選択するために、デフォルトで 順序付きリスト を使用します。以下に示す segment-actions モードの single-hop を使用して、リージョン間およびセグメント間のトラフィックパスに InspectionNFG NFG を挿入します。 "segment-actions": [ { "action": "send-via", "segment": "prod", "mode": "single-hop", "when-sent-to": { "segments": "*" }, "via": { "network-function-groups": [ "InspectionNFG" ] } } ], 図 6 に示すように、Region 1 と Region 2 のペアにおいて、Region 1 は us-east-1、Region 2 は us-west-2 であり、 順序付きリスト に従って、Region 1 (us-east-1) がインスペクションのデフォルトリージョンとして選択されています。そのため、Prod VPC と Dev VPC 間のすべてのリージョン間トラフィックは、インスペクションのために Region 1 の Inspection VPC 1 を経由してルーティングされます。 図 6: リージョン間、セグメント間のシングルスペクションのトラフィックフロー Packet walkthrough: 以下のステップでは、Prod VPC 1 のリソースがシングルインスペクションを使用して Dev VPC 2 のリソースと通信する際のパケットの流れについて説明します。 ステップ (A) から (C) は、シナリオ 2 で説明したものと同じですが、以下の点が異なります。 (D) パケットがコアネットワークに到着すると、Inspection VPC 1 が InspectionNFG に関連付けられているため、リージョン 1 をエッジロケーションとして InspectionNFG ルートテーブルの検索を行います。パケットは Dev VPC 2 CIDR エントリと一致し、リージョン 2 をエッジロケーションとして InspectionNFG ルートテーブルの検索を実行するように要求します。 (E) リージョン 2 をエッジロケーションとして InspectionNFG ルートテーブルの検索を行います。パケットは、Dev VPC 2 アタッチメントをターゲットとする Dev VPC 2 CIDR エントリに一致し、Inspection VPC 2 ではなく、パケットは Dev VPC 2 にルーティングされます。 戻りトラフィックは、同じパスを逆方向にたどります。 考慮事項 NFG はグローバルな性質を持ち、コアネットワークに属するどの AWS リージョンからでもアタッチメントを追加できます。たとえば、コアネットワークが 3 つの AWS リージョン (us-east-1、eu-west-1、ap-west-1 など) にまたがって運用されている場合、これら 3 つのリージョンのいずれからでも、単一の NFG にインスペクションまたはファイアウォール VPC を追加できます。 NFG は、コアネットワークごとの AWS Cloud WAN セグメントの クォータ から、1 つのグローバルセグメントを消費します。 ワークロードセグメントと NFG の両方で、すべてのアタッチメントタイプ (VPC、VPN、connect、transit gateway) がサポートされています。 このブログ投稿の執筆時点では、動的アタッチメント (VPN、connect、transit gateway peering) を通じて NFG にアドバタイズされた動的ルートは、NFG ルートテーブルにインストールされません。また、Service Insertion を機能させるためには、デフォルトルート (0/0、::/0) を動的アタッチメントを通じて NFG にアドバタイズする必要があります。詳細については、AWS Cloud WAN のドキュメントを参照してください。 コアネットワークごとに複数の NFG がサポートされていますが、セグメントペア内のインサーションごとに単一の NFG のみが許可されます。アタッチメントはセグメントまたは NFG のいずれかに関連付けることができますが、両方に関連付けることはできません。通常、ワークロードアタッチメント (ワークロード VPC) はセグメントに関連付けられ、インスペクション VPC (ファイアウォール、侵入検知システム、侵入防止システムアプライアンスをホスト) は NFG に関連付けられます。 同じコアネットワークで複数の NFG を設定できます。ただし、同じセグメントまたはセグメントペアに複数の NFG を挿入することはできません。 同じセグメントに接続されたリソース間のトラフィックを検査する必要がある場合は、該当するワークロードセグメントの分離モードを有効にします。この設定により、挿入が必要なネットワーク機能をバイパスすることなく、セグメントに関連付けられたアタッチメント間の直接接続を防止します。 AWS Cloud WAN の アプライアンスモード は、Service Insertion とは独立しており、VPC 内のセキュリティインフラストラクチャを通じてステートフルインスペクションを確実に行いたい場合に必要です。特定のネットワークフローの双方向のトラフィックが同じアベイラビリティーゾーンに、そして結果として同じセキュリティアプライアンスにステートフルインスペクションの目的で転送されるようにするには、インスペクション VPC アタッチメントでアプライアンスモードを有効にする必要があります。 AWS Cloud WAN は IPv4 と IPv6 の両方をサポートしています。 通常の AWS Cloud WAN の料金 以外に、Service Insertion の使用に関する追加料金はありません。 業界をリードするパートナー AWS Cloud WAN Service Insertion のローンチにおいて、業界をリードするパートナー企業と協力できたことを嬉しく思います。パートナー企業の素晴らしい取り組みとコメントをご紹介します： Aviatrix ブログ Check Point ブログ Cisco ブログ F5 ブログ Fortinet ブログ Netskope ブログ Palo Alto Networks ブログ 1 ブログ 2 まとめ このブログ記事では、AWS Cloud WAN Service Insertion について説明しました。これは、中央のポリシードキュメントを使用して AWS および他社のネットワークとセキュリティサービスを AWS Cloud WAN にシームレスに挿入できる新機能です。この機能を使用すると、シンプルなポリシーステートメントを定義するか、コンソールを使用することで、VPC 間または VPC とオンプレミス間のトラフィックをネットワークまたはセキュリティアプライアンスを通じて簡単に制御できます。また、この新機能を使用したリージョン内およびリージョン間のインスペクションアーキテクチャについても説明しました。詳細については、 AWS Cloud WAN のドキュメントをご参照ください。 更新情報: 2024 年 6 月 28 日: 図 5 とそれに続くパケットの説明に修正を加えました。 2024 年 11 月 25 日: 業界をリードするパートナーとして Fortinet が追加されました。 著者について Pratik Mankad Pratik は、AWS の Network Solutions Architect です。彼はネットワーク技術に情熱を持ち、お客様の問題解決を支援するためにイノベーションを生み出すことを愛しています。彼はソリューションの設計と技術的なガイダンスの提供を通じて、お客様やパートナーが技術的・ビジネス的な目標を達成できるよう支援することを楽しんでいます。 Shridhar Kulkarni Shridhar は Amazon Virtual Private Cloud（VPC）チームの一員であり、AWS Cloud WAN サービスのプロダクトマネジメントをリードしています。彼は、クラウド、SAAS、モバイル、SD-WAN、仮想化、WAN 最適化、SDN、データネットワーキング（L1-L7）、VoIP、ケーブル、FTTH、x86 ハードウェアプラットフォームに関する専門知識を持つ、強力で多様な技術的バックグラウンドを有しています。また彼は、世界中のクラウド、エンタープライズ、サービスプロバイダー、中小企業の顧客向けに最先端のハイテク製品やサービスを提供してきた実績があり、コンピュータサイエンスの修士号と UCLA アンダーソン経営大学院のMBAを取得しています。 Rizwan Mushtaq Rizwan は AWS の Principal Solutions Architect です。彼はお客様が AWS サービスを使用して革新的で耐障害性が高く、コスト効率のよいソリューションを設計することを支援しており、ウィチタ州立大学で電気工学の修士号を取得しています。 翻訳は Solutions Architect の疋田 洋一が担当しました。原文は こちら です。

商品を購入する前に、新しい服が自分にどのように似合うかをすばやく確認できたらいいのに、と思ったことはありませんか？あるいは、リビングに置いた家具はどう見えるか、気になったことはありませんか？本日、このような商品画像生成の課題に対応する Amazon Nova Canvas の新しい Virtual try-on 機能を紹介できることを嬉しく思います。さらに、スタイルの一貫性を向上させるための 8 つの新しいスタイルオプションが、text-to-image ベースのスタイルプロンプトに追加されました。これらの機能により、Nova Canvas AI を活用した画像生成機能が拡張され、顧客体験を向上させるリアルな製品の視覚化や、定型化された画像の作成作業がこれまでになく簡単になります。 今すぐ使い始める方法を簡単に見てみましょう。 Getting started まず、通常の方法で Nova Canvas モデルにアクセスできることを確認します。 Amazon Bedrock コンソール で [モデルアクセス] を選択し、 アカウントの Amazon Nova Canvas を有効にして 、ワークロードに適したリージョンを選択していることを確認します。モデルアクセスの有効化方法については、ブログ「 Amazon Bedrock のモデルアクセスの有効化や制限値の引き上げができない時の対応方法 」をご覧ください。すでに Nova Canvas にアクセスして使用している場合は、新機能が自動的に利用可能になるので、すぐに使い始めることができます。 Virtual try-on 最初のエキサイティングな新機能は Virtual try-on です。この機能を使用して、2 枚の写真をアップロードして Amazon Nova Canvas に依頼すると、現実的な仕上がりとなるようにそれらの画像が合成されます。これらの画像は、アパレル、アクセサリー、家具、および、多様な衣類を含む、様々な種類のその他の製品の写真が想定されます。たとえば、ソース画像として人物の写真、参照画像として衣服の写真を指定すると、Amazon Nova Canvas が同じ人が衣服を着ている新しい画像が作成されます。これを試してみましょう。 私はまず、2 つの画像を選択することから始めました。服の交換にぴったりだと思うポーズをしている私の写真と、AWS ブランドのパーカーの写真を 1 枚選びました。 Nova Canvas への入力画像は、最大 410 万ピクセル（2,048 x 2,048 に相当）であることに注意してください。(詳細要件は Amazon Nova ユーザーガイド(英語) を参照) 必要に応じて、これらの制限に合わせて画像のサイズを調整してください。また、この記事で取り上げた Python コードを実行したい場合は、Python 3.9 以降と Python パッケージ boto3 と pillow がインストールされていることを確認してください。 このパーカーを私の写真に適用するには、Amazon Bedrock ランタイムの invoke API を使っています。この API のリクエストとレスポンス構造の詳細については、 Amazon Nova ユーザーガイド(英語) をご覧ください。コードは単純で、必要な推論パラメータはごくわずかです。私は "VIRTUAL_TRY_ON" という新しい taskType を使用しました。次に、 virtualTryOnParams オブジェクトを使用して必要なパラメータをいくつか設定し、ソースイメージと参照イメージの両方を含め、必要な設定を指定しました。どちらのイメージも Base64 文字列に変換する必要があることに注意してください。 import base64 def load_image_as_base64(image_path): """Helper function for preparing image data.""" with open(image_path, "rb") as image_file: return base64.b64encode(image_file.read()).decode("utf-8") inference_params = { "taskType": "VIRTUAL_TRY_ON", "virtualTryOnParams": { "sourceImage": load_image_as_base64("person.png"), "referenceImage": load_image_as_base64("aws-hoodie.jpg"), "maskType": "GARMENT", "garmentBasedMask": {"garmentClass": "UPPER_BODY"} } } Nova Canvas はマスキングを使用して画像を操作します。これは、マスキングテープを使用してペイントしたくない領域を保護するのと同様に、AI 画像生成で画像の特定の領域または領域に焦点を合わせながら、他の領域は保存できるようにする手法です。 マスキングには、3 種類のマスキングモードを使用できます。 maskType を適切な値に設定することで選択できます。今回は、日本語で衣料品を示す言葉である "GARMENT" タイプを使っているので、同時に、体のどの部分をマスクしたいかを指定する必要があります。私は "UPPER_BODY" を使用していますが、特に足をターゲットにしたい場合は "LOWER_BODY" や、 "FULL_BODY" 、 "FOOTWEAR" など他のものを使用してもかまいません。オプションの全リストは Amazon Nova ユーザーガイド(英語) を参照してください。 次に invoke API を呼び出し、これらの推論引数を渡して、生成されたイメージをディスクに保存します。 # Note: 上記の inference_params 変数が以下で参照されています。 import base64 import io import json import boto3 from PIL import Image # Create the Bedrock Runtime client. bedrock = boto3.client(service_name="bedrock-runtime", region_name="us-east-1") # Prepare the invocation payload. body_json = json.dumps(inference_params, indent=2) # Invoke Nova Canvas. response = bedrock.invoke_model( body=body_json, modelId="amazon.nova-canvas-v1:0", accept="application/json", contentType="application/json" ) # Extract the images from the response. response_body_json = json.loads(response.get("body").read()) images = response_body_json.get("images", []) # Check for errors. if response_body_json.get("error"): print(response_body_json.get("error")) # Decode each image from Base64 and save as a PNG file. for index, image_base64 in enumerate(images): image_bytes = base64.b64decode(image_base64) image_buffer = io.BytesIO(image_bytes) image = Image.open(image_buffer) image.save(f"image_{index}.png") 非常にエキサイティングな結果を得ました！ このように、私は AWS ブランドのパーカーを着ることができ、誇りに思います！ "GARMENT" mask type に加えて、 "PROMPT" や "IMAGE" マスクも使用することができます。 "PROMPT" では、ソース画像と参照画像も提供する必要がありますが、ソース画像のどの部分を置換するかを自然言語のプロンプトで指定します。これは、Nova Canvas の "INPAINTING" と "OUTPAINTING" タスクの仕組みと似ています。独自のイメージマスクを使用する場合は、 "IMAGE" mask type を使用し、マスクとして使用する白黒画像を指定します。黒はソースイメージで置き換えたいピクセルを示し、白は維持したいピクセルを示します。 この機能は小売業者にとって特に便利です。これを利用して、購入前に商品の見た目を確認することで、顧客がより適切な購入判断を下せるようになります。 Style options アニメのスーパーヒーローになったらどんなふうになるのだろうといつも思っていました。以前は、Nova Canvasを使って自分の画像を操作できましたが、それを適切に行うには、優れたプロンプトエンジニアリングスキルに頼らざるを得ませんでした。 現在、Nova Canvasには事前にトレーニングされたスタイルオプションが付属しており、それを画像に適用して、お好みの芸術的スタイルに沿った高品質の結果を得ることができます。3Dアニメーションファミリーフィルム、デザインスケッチ、フラットベクターイラスト、グラフィックノベル、マキシマリズム、ミッドセンチュリーレトロ、フォトリアリズム、ソフトデジタルペインティングなど、8つのスタイルが用意されています。 それらの適用は、Nova Canvas API に追加のパラメーターを渡すのと同じくらい簡単です。例を試してみましょう。 「3D アニメーションファミリーフィルム」スタイルを使って AWS のスーパーヒーローのイメージを生成したいと思います。そのためには、 "TEXT_IMAGE" という taskType と、 text と style の 2 つのパラメータを含む textToImageParams オブジェクトを指定します。 text パラメータには、作成したい画像を説明するプロンプトが含まれています。今回は「大きな AWS ロゴとケープが付いた黄色い衣装のスーパーヒーロー」と指定しています。 style パラメータは、定義済みのスタイル値の 1 つを指定します。ここでは "3D_ANIMATED_FAMILY_FILM" を使用していますが、全リストは Amazon Nova ユーザーガイド(英語) に記載されています。 inference_params = { "taskType": "TEXT_IMAGE", "textToImageParams": { "text": "a superhero in a yellow outfit with a big AWS logo and a cape.", "style": "3D_ANIMATED_FAMILY_FILM", }, "imageGenerationConfig": { "width": 1280, "height": 720, "seed": 321 } } 次に、前の例と同じように invoke API を呼び出します。(ここでは簡潔にするためにコードを省略しています)。そしてその結果は？さて、皆様ご判断いただければと思いますが、AWS のスーパーヒーローが、私の好きな色を、私が思い描いていた 3D アニメーションのファミリーフィルムのスタイルにあわせて着ています。とても満足していると言わざるを得ません。 本当に素晴らしいのは、コードとプロンプトをまったく同じにしたまま、スタイル属性の値を変更するだけで、まったく異なるスタイルの画像を生成できることです。これを試してみましょう。 style を PHOTOREALISM に設定しました。 inference_params = { "taskType": "TEXT_IMAGE", "textToImageParams": { "text": "a superhero in a yellow outfit with a big AWS logo and a cape.", "style": "PHOTOREALISM", }, "imageGenerationConfig": { "width": 1280, "height": 720, "seed": 7 } } そして、その結果は印象的なものとなりました！私が説明したとおりのフォトリアリスティックなスーパーヒーロー。これは前に生成されたアニメスタイルとは全く異なるものとなり、必要な作業は、1 行のコードを変更することだけでした。 知っておくべきこと 利用可能なリージョン – Virtual try-on とスタイルオプションは、US East (N. Virginia)、Asia Pacific (Tokyo)、 Europe (Ireland) の Amazon Nova Canvas で利用いただけます。Amazon Nova Canvas の既存ユーザーは、新しいモデルに移行しなくてもすぐにこれらの機能を使用できます。 料金 – Amazon Bedrock 料金ページ をご覧ください。 Virtual try-on は簡単に試すことができます。 nova.amazon.com (http://nova.amazon.com/) へアクセスし、人物と衣服の画像をアップロードして、様々な服の着せ替えを楽しんでください！ 始める準備ができたら、Nova Canvas ユーザーガイドを確認するか、AWS コンソールにアクセスしてください。 Matheus Guimaraes | @codingmatheus Matheus Guimaraes Matheus Guimaraes (@codingmatheus) は .NET と microservice のスペシャリストで、インターナショナル キーノートスピーカーです。また、AWS の開発者支援者25 年以上技術に携わってきた彼は、ジュニアゲームプログラマーから CTO、スタートアップの創設者まで、さまざまな役職を歴任してきました。Matheus は、あらゆる規模の企業のシステムの近代化と拡張を支援し、デジタルトランスフォーメーションを主導し、クラウドネイティブアーキテクチャを設計してきました。現在、彼は講演、ブログ、ビデオを通じて専門知識をグローバルに共有し、業界で他の企業の成長を支援することに情熱を注いでいます。テクノロジー以外にも、彼はゲーマー、スイマー、ミュージシャンであり、創造性とコードの強力な融合を信じています。

本稿は、2024年4月15日に AWS Cloud Operations Blog で公開された “ Automate incident reports from AWS Systems Manager Incident Manager ” を翻訳したものです。 システムの信頼性を維持し、予期せぬインシデントに迅速に対応するためには、効果的なインシデント管理が最も重要です。AWS Systems Manager の機能である Incident Manager は、自動対応機能を提供することで、これらのインシデントの緩和と復旧を支援します。以前の Incident Manager に関するブログでは、エスカレーションメカニズムの設定、対応計画の作成、AWS Systems Manager Automation ランブックを使用した修復の自動化について説明しました。詳細については、 AWS Systems Manager Incident Managerで連絡先、エスカレーションプラン、対応プランを作成する をご覧ください。 インシデントライフサイクルの一環として、組織がインシデントの過去データを収集し、振り返って事後分析を行うことが重要です。お客様は AWS SDK を使用して、これらすべてのインシデントに関する情報をプログラムで収集してエクスポートすることができます。お客様からは、このレポート生成プロセスを自動化し、これらのレポートを一元化された場所に定期的にエクスポートする方法についてよく質問を受けます。 このブログでは、スケジュールに従って Incident Manager のレポートを生成し、Amazon Simple Storage Service (Amazon S3) に保存する方法を説明します。これらのレポートは、関係するリソース、頻発する問題、修正に要する時間などに基づいてインシデントを確認し、並べ替えるのに役立ちます。これらは、運用エンジニア、システム管理者、IT マネージャーに重要な気づきを与えます。過去のデータを掘り下げることで、アプリケーションやインフラストラクチャの異常を発見できます。 前提条件 このウォークスルーを行うには、以下の前提条件が必要です AWS アカウント シングルアカウントまたはマルチアカウント、マルチリージョンで設定された Incident Manager ワークフロー このソリューションは、以下のサービスによって実現されています。 AWS CloudFormation Amazon S3 AWS Identity and Access Management (IAM) AWS Systems Manager の機能である Automation AWS Systems Manager の機能である State Manager AWS Systems Manager の機能である Incident Manager 図1: Incident Manager レポート生成ソリューション CloudFormation テンプレートは GitHub リポジトリ にホストされています。CloudFormation は、このソリューションで使用される必要なコンポーネントをデプロイします。これには、S3 バケット、Automation ランブック、State Manager アソシエーション、必要な IAM 権限が含まれます。Automation は Incident Manager API に接続して必要な情報を抽出し、CSV ファイル形式で S3 バケットにアップロードします。 ソリューションを実行するたびに、新しいレポートが生成されます。オプションとして、スケジュールでソリューションを実行することを選択した場合、CloudFormation テンプレートは、CloudFormation スタックの作成時にパラメータとして指定されたスケジュールで実行される State Manager アソシエーションを作成します。 Automation ランブックには、Python スクリプトを実行してレポートを生成および保存する  aws:executeScript アクションが含まれています。Python スクリプトは ListIncidentRecords API を呼び出して、現在のリージョンのすべてのインシデントを取得します。次に、スクリプトはインシデントごとに  ListRelatedItems API を実行して、関連するすべてのアイテムを取得します。収集したインシデントは CSV ファイルに保存され、 IMReport-{Current Date}-{Time in UTC} の形式で名前が付けられます。この CSV ファイルは、ダウンロード用の S3 バケットにアップロードされます。さらに、このソリューションをカスタマイズして、各レポートを S3 へアップロードした時に SNS 通知を送信することができます。詳細については、 Amazon S3 イベント通知 を参照してください。 ソリューションの手順 単一のアカウントまたはマルチアカウントおよびマルチリージョンのインシデント管理では、インシデントはすべてのアカウントとレプリケーションセットリージョンに複製されます。したがって、目的のアカウントとリージョンに CloudFormation テンプレートをデプロイして、インシデントとそれに関連するアイテムを取得できます。 ソリューションのデプロイ CloudFormation テンプレート をダウンロードします。 レポートを生成したい AWS アカウントの CloudFormation コンソール に移動します。 Create Stack で、with new resources (standard) を選択します。 Prepare template で、Choose an existing template を選択し、Template source で Upload a template file を選択します。Choose file をクリックし、ステップ 1 でダウンロードしたテンプレートを選択します。 Next をクリックします。 Stack name に、スタック名 ( 例: incident-manager-reporting ) を入力します。 Parameters エリアで以下の操作を行い、Next をクリックします。 ‘RunOnSchedule’ にて、定期的にレポートを生成する場合は true を選択し、レポートを手動で生成する場合は false を選択します。 false を選択した場合、この CloudFormation テンプレートをデプロイした後、 Generating OnDemand reports セクションを参照して、Automation ランブックを手動で実行する必要があります。 ‘AssociationSchedule’ ( RunOnSchedule が true に設定されている場合のみ必要 ) では、CRON 式を入力します。デフォルトでは、毎週日曜日の 02:00 AM UTC に自動で実行されます。サポートされている CRON 式の詳細については、 リファレンス を参照してください。 Configure stack options ページで I acknowledge that AWS CloudFormation might create IAM resources. を選択し、Next をクリックします。 Review and create ページで、Submit をクリックします。 テンプレートがデプロイされた後、図 2 に示されているように Outputs を選択して以下の値を確認してください。 AWSSystemsManagerAutomationExecutionRole S3Bucket SystemsManagerAutomationDocument 図2：CloudFormation の出力リソース オンデマンドレポートの生成 注意 – CloudFormation テンプレートをデプロイする際に `RunOnSchedule` パラメータを true に設定した場合は、このセクションをスキップして S3 コンソールからレポートをダウンロード のセクションに進んでください。 Systems Manager Automation に移動します。 Execute runbook をクリックします。 Owned by me を選択し、Outputs で確認した SystemsManagerAutomationDocument の Value に表示されていたランブック名 (incident-manager-reporting-SystemsManagerAutomationDocument-*) を選択します。Next をクリックします。 図 3: Automation ランブック Simple execution を選択します。 Input parameters エリアの AutomationAssumeRole には、 図 4 に示されているように CloudFormation スタックから出力された AWSSystemsManagerAutomationRole の Value を入力します。S3BucketName には、CloudFormation スタックから出力された S3Bucket の Value を入力します (これがデフォルト値になります)。 図 4: Automation Assume Role と S3 Bucket の入力 Execute をクリックします。 Automation ランブックがアカウントのすべてのインシデントに関する情報を収集します。図 5 に示されているように、Executed steps で Step ID をクリックし、 OutputPayload の Amazon S3 バケットと CSV ファイル名を確認します。 図 5: Systems Manager Automation の出力 S3 コンソールからレポートをダウンロード S3 console に移動し、バケットを見つけて IM Report CSV をダウンロードします。図 6 に示されるように、ファイル名にはレポートが生成された日時 (UTC) が含まれています。 図 6: レポートファイルの IMReport CSV をダウンロード 図 7: Incident Manager レポートファイルの例 クリーンアップ CloudFormation で作成したリソースをクリーンアップする: S3 バケット内に生成されたオブジェクトを手動で削除 AWS S3 コンソールを開き、CloudFormation で生成された S3 バケットを見つけます。 すべてのオブジェクトを選択し、Delete をクリックします。 削除を確定するには、テキスト入力フィールドに permanently delete と入力します。 ‘Delete objects’ をクリックします。 CloudFormation スタックを削除 Open the AWS CloudFormation コンソール を開き、ナビゲーションペインで Stacks を選択します。 作成した CloudFormation スタックを選択し、 Delete をクリックした後、確認画面で Delete をクリックします。 まとめ このブログ記事では、Incident Manager API と AWS Systems Manager Automation および State Manager Association を使用して、全てのインシデントとそれに関連するアイテムをスケジュールに従って定期的に保存するレポート生成ソリューションについて説明しました。このソリューションでは以下のことができます: レポート生成の自動化: 手作業は不要 – プロセスを合理化し、レポートを Amazon S3 に安全に保存します。 貴重な傾向の発見: 頻繁に発生する問題、脆弱なリソース、解決時間を特定します。 効率と安全性の向上: ボトルネックを事前に解消し、再発を防止し、クラウド環境を最適化して最大限の回復力を実現します。 著者について: Ali Alzand Ali は、Amazon Web Services の Microsoft スペシャリストソリューションアーキテクトです。Ali は、グローバルな顧客と連携し、Microsoft ワークロードの AWS クラウドへの移行、近代化、最適化を支援しています。専門は、AWS Systems Manager、Amazon EC2 Windows、PowerShell です。仕事以外では、バーベキュー、アウトドア活動、さまざまな食べ物に挑戦することを楽しんでいます。 Raviteja Sunkavalli Raviteja Sunkavalli は、Amazon Web Services のシニアクラウドサポートエンジニアです。Ravi は、グローバル顧客のクラウド移行と集中運用の効率化をサポートしています。専門は、AWS Systems Manager と EC2 Windows サービスです。テクノロジー以外では、クリケットをプレーしたり、新しいレシピに挑戦したりすることを楽しんでいます。 翻訳は SA 渡邊が担当しました。 TAGS: AWS Systems Manager , Cloud Operations , Operations Integrations , Systems Manager Automation , Systems Manager Incident Manager

レンゴー株式会社について レンゴーは、たゆまぬ意識改革とイノベーションを通じて、あらゆる産業のすべての包装ニーズに対し、総合的なソリューションでお応えする「GPI=ゼネラル・パッケージング・インダストリー」です。物流と暮らしの豊かさを支え、より良い社会、持続可能な社会の実現を目指して取り組んでいます。 はじめに データ活用が企業の競争力を左右する時代において、多くの企業がデータ駆動組織への転換を模索しています。私たちレンゴーも例外ではなく、長年にわたりデータ活用の拡大に取り組んできました。しかし、その道のりは順調とは言えませんでした。思うような成果が得られない中、私たちはAWSとパートナー企業（ 株式会社JSOL ）の協力を得て、自社の課題に特化した研修プログラムを開発しました。このアプローチが功を奏し、社内でのデータ活用の取り組みに変化の兆しが見え始めています。本稿では、同様の課題に直面している企業の皆様に向けて、私たちの取り組みと経験から得た気づきを共有します。 データ活用を妨げる三つの課題 レンゴーは、製紙業界が直面する厳しい経営環境と2024年問題として知られる物流危機への対応を迫られていました。業界全体が原材料コスト上昇、環境規制強化、デジタル化による紙需要減少という三重苦に直面する中、データ活用による業務変革が不可欠との判断に至りました。そして、2021年から2023年にかけて、全社で使用する汎用データ基盤の構築に取り組みました。各工場から収集したデータをデータ基盤に集約し、Amazon QuickSightを使って可視化できる分析基盤を構築しました。 技術的な基盤は整ったものの、実際のデータ活用は思うように進展しませんでした。データは蓄積されているにもかかわらず、それを業務改善や意思決定に活かすという段階に至らなかったのです。インフラ構築だけではデータ駆動組織への転換は実現しないという問題に直面しました。私たちはこの問題を引き起こす要因として、「ソフトスキル」「ハードスキル」「ツール」の3つの観点があると仮説を立てました。 (1) 業務部⾨⾃らデータを活⽤する⾵⼟の醸成（ソフトスキル） データ基盤の整備は進んでいたものの、データ活用は情報システム本部や一部の研究開発部門にとどまり、業務部門にまで浸透していませんでした。特に顕著だったのは、現場においてデータを活用して業務効率化を図るという発想自体がないことでした。多くの現場担当者は長年培われた経験や勘を頼りに業務を遂行しており、既存の業務プロセスに特段の課題を感じていませんでした。「今までもうまくいっているのだから」という意識が強く、変革の必要性を実感できていなかったのです。 この状況を打開するためには、データ活用によって得られる具体的なメリットを現場レベルで理解してもらう必要がありました。更に、データを活用して業務改善に取り組むモチベーションを喚起し、継続的な改善に取り組む文化を醸成することが求められていました。 (2) データ分析スキルの取得（ハードスキル） もちろん、データ活用に対する意欲を持つ社員は一定数存在しています。しかし、自身の業務に課題を感じ、改善意欲を持つ担当者がいても、普段の業務に求められるスキルセットと、データ分析に必要なスキルセットとの間には大きな乖離があります。製造現場や営業部門など、それぞれの専門分野では高い能力を持つ社員でも、データ分析については未経験であることがほとんどでした。 この問題を解決するためには、データ分析について基礎から体系的に学ぶ機会を提供することが不可欠でした。担当者一人ひとりが、自らの業務課題とデータ活用を結びつけられるよう、机上の知識の取得するだけでなく、実践的なスキルを習得できるプログラムを構築することが求められていました。 (3) QuickSightの認知度向上（ツール） 業務部門の中でも、一部の部門はデータからレポートを作成する業務を担っていましたが、そういった部署においてもデータ活用は進んでいませんでした。データ分析ツールとしてQuickSightが導入されていたにもかかわらず、従来と変わらずExcel等の表計算ソフトを用いて手作業でレポートを作成していました。　こうした状況の背景には、BIツールの提供する価値や機能が十分に理解されていないという問題がありました。多くの社員はBIツールを「難しい専門家向けのシステム」と捉え、自分たちの業務とは関係ないものだと認識していました。 この問題を解決するためには、まずBIツールを活用するメリットを実感してもらう必要がありました。また、自部門の業務に直結するユースケースを示し、ツールの基本的な操作方法を習得してもらうことで、「自分たちにも使える」という認識を持ってもらうことが重要でした。 目指すべき姿と自社にカスタマイズされた教育プログラムの開発 レンゴーの中期経営計画においても、DXによる価値創出が重要な戦略として位置づけられていました。この目標を実現するためには、組織全体でデータ活用の文化を醸成し、個々の社員が目的意識を持ってデータを活用し、業務改善に取り組む体制になっていることが必要不可欠です。 図1　デジタイゼーション・デジタライゼーションとデジタルトランスフォーメーション（DX) しかし、前述した「ソフトスキル」、「ハードスキル」、「ツール」の三つの課題を解決するためのノウハウは社内にありませんでした。そこで私たちは、AWSが提供している無償の データ活用ワークショッププログラム に着目し、これをベースとして研修プログラムを作成することを検討しました。しかし、AWS の担当者からプログラムの内容をヒアリングする中でプログラムを適用するだけでは、人手とコンテンツのカスタマイズ性の面で、当社特有の課題に対応できない可能性があることがわかりました。そこで、データ活用に対して専門知識を持つパートナー企業を交え、３社共同で研修プログラムの開発に取り組むことを決断しました。そして、研修を前述した3つの課題に対し、それぞれの会社が強みを発揮できる内容に構成しました。 (1) Working Backwards を使用した課題解決手法の習得（ソフトスキル） 研修プログラムの核となる特徴として、Amazonが社内で実践している課題解決のフレームワーク「Working Backwards」を取り入れました。この手法は、目標から逆算して必要なステップを明確化するアプローチで、データ活用においても非常に効果的です。その際、架空のシナリオではなく、現実の課題を題材とすることで、研修の実効性を高めることを目指しました。研修の中で参加者が自部門で実際に直面している課題を題材とし、その課題を解決するために最適なダッシュボードがどのようなものかを検討します。そして、研修期間内に、QuickSightでダッシュボードを作成するところまで実践します。 このアプローチを取ることで、参加者は、課題解決のプロセスを体系的に学ぶことができるだけでなく、データ分析の有用性を体感できます。そして、研修終了時には、明日から実務で使える具体的な成果物を持ち帰ることができるため、学びを即座に実践に移す橋渡しとなります。 (2) データ分析関連の知識を網羅的に学ぶことができるコンテンツの開発（ハードスキル） 初学者でもついていけるような研修プログラムを設計する為、私たちはJSOLに協力を依頼しました。JSOLを選定した理由は主に二つあります。一つ目は、同社が データ活用支援 において豊富な実績を持っていたことです。そして、二つ目の理由は、レンゴーの汎用データ基盤の構築をJSOLが担当していたという点です。データの構造や特性を熟知しているパートナーであれば、より実践的な研修内容を構築できると考えました。 そして、JSOL主導で統計学の基礎知識から始まり、データ分析の手法、そして効果的なダッシュボードデザインの実践に至るまで、データ分析プロセス全体を網羅する包括的な研修コンテンツを作成しました。このコンテンツを設計する際に意識したことは、①「データ分析の経験がまったくない社員でも無理なく参加できること」と、②「データ分析に必要な知識を網羅的に習得できること」の２つです。単なる概念理解にとどまらず、実務で即座に活用できる知識の習得を重視しました。 (3) 実データを使用したQuickSightハンズオンの実施（ツール） レンゴーではコスト効率の高さとAWS環境との親和性を評価し、Amazon QuickSightをBIツールとして導入してます。ダッシュボードを作成する為には、受講者にQuickSightのスキルを習得してもらう必要がありました。そこで、架空のデータではなく、レンゴー社内に実際に蓄積されている業務データを活用することにこだわりハンズオンコンテンツを作成しました。また、ハンズオン手順書についても、初心者が躓きやすいポイントを予測し、詳細な操作ガイドと補足説明を作成するなど、レンゴー社員の視点から理解しやすいコンテンツ作成を意識しました。 このアプローチには二つの重要な狙いがありました。一つ目は、参加者に「実際の業務でどのようにデータを活用するか」の具体的なイメージを掴んでもらうことで、二つ目が新たに必要なデータセットが生じた際に、情報システム部門に相談する方法を知ってもらうことです。データ分析をしたいが「誰に相談すればいいのかわからない」という心理的障壁を取り除くことを目指しました。 全社に向けてデータ活用研修を開催 今回開発した研修プログラムを、2024年11月から2025年1月の3ヶ月間にわたり、東京と大阪の2会場で開催しました。そして、計6日間のカリキュラムに、異なる業務部門から20人が参加しました。この6日間の内訳について掘り下げて説明します。 　　 図2 研修の様子 (1) データ分析の基礎固め         最初の2日間では、統計学の基礎知識やAmazonの「Working Backwards」の学習、そして基本的なQuickSightのハンズオンを通じて、データ分析の土台を固めました。加えて、２日目が終了した時点で、参加者に対し「自部門が抱える実際の課題」を見つけてくるという宿題を課しました。 図 3 研修に使用したコンテンツ (2) 実業務に直結するダッシュボードイメージ作成 3日目は、各参加者が持ち寄った業務課題に対して議論を展開しました。課題の本質を掘り下げた上で、課題を解決するためのダッシュボードを手書きで作成しました。この作業を通して、効果的な可視化方法等をダッシュボード設計の基本原則を実践を通して学んでもらいました。 図 4 ダッシュボード作成ワークショップ (3) QuickSightを使用したダッシュボード作成 4日目と5日目は、手書きで設計したダッシュボードイメージをAmazon QuickSightを使用したインタラクティブなダッシュボードへと具現化する作業に取り組みました。その際、質問をリアルタイムで受け付ける体制を取り、参加者の疑問をその場で解消するよう努めました。 図 5 ダッシュボードイメージ (4) 成果報告会 研修の集大成として6日目には、各部門の上席者を招いた成果報告会を開催しました。参加者が自らが特定した業務課題と課題を解決するために作成したダッシュボードについて発表を行い、自部門の上長に対し成果を共有しました。この報告会は、学びの成果を組織全体に波及させる重要な機会となりました。 図 6 成果報告会の様子 研修がもたらした組織変革の兆し 研修終了時には、研修に参加した20人全員が、自部門の課題解決に直結する実用的なダッシュボードを完成させました。基礎から体系的に学べるカリキュラムにしたことで、6日間という長期間かつ高密度の研修にもかかわらず、一人のリタイアも出しませんでした。さらに喜ばしいことに、研修終了後も社内にデータ活用の土壌が着実に育ちつつあります。具体的には次の３つの成果を得る事ができました。 (1) 参加者主導によるダッシュボードの全国展開 研修プログラムの最も顕著な成果として、参加者が自部門でのデータ活用の推進役となり、実際の業務改善に直結するダッシュボードが全国展開という事例が挙げられます。特に注目すべきは「取り組み状況検索」と名付けられた分析ダッシュボードの開発と普及です。このダッシュボードは、これまで各営業担当者が個別に時間をかけて調査・集計していた情報を一元的に可視化し、即座にアクセスできるようにしたものです。この成功事例は、当初私たちが懸念していた「研修で終わり」という状況に陥らなかったことを如実に示しています。この研修の主要な狙いの一つであった「データを活用する土壌の醸成」が実際に起こった結果だと認識しています。 (2) QuickSight ユーザーの増加 研修プログラムの効果は、具体的な数字としても明確に表れています。研修終了から3ヶ月という短期間のうちに、Amazon QuickSightのAuthor権限（ダッシュボードを自ら作成・編集できる権限）を持つユーザーが100名以上も増加しました。この数字は、単なるツール導入の成功を超え、「自らデータを分析し、可視化する」という行動変容が組織内で広がりつつあることを示しています。また、来期以降も同研修を実施する予定であることを踏まえると、この増加傾向が一時的なものではなく、今後も継続して拡大していく見込みです。 (3) データ収集・蓄積依頼の増加 研修終了後には、データ活用の基盤となるデータの収集・蓄積プロセスにおいても、変化が見られています。これまでレンゴーでは、情報システム部門が主導して「重要と思われるデータ」を特定し、業務部門に対してその活用を提案するという「プッシュ型」のアプローチが一般的でした。しかし研修実施後、この流れは完全に逆転し、業務部門から情報システム部門へのデータ収集依頼が殺到するという「プル型」の状況へと変化しました。現在では、情報システム部門が全てに対応しきれないほどの要件が寄せられており、業務部門と綿密な対話を重ねながら優先度を設定し、段階的に対応を進めている状況です。この変化は、データ活用の価値が業務部門に深く理解され、自らの業務課題解決のためにデータを積極的に活用しようという意識が広がった結果だと言えるでしょう。 これまでに述べた様々な成果から、レンゴー社内においてデータ活用を行う文化が着実に醸成されつつあると判断しています。しかし、私たちはこれを通過点に過ぎないと認識しています。真のデータドリブン組織への変革は一朝一夕に成し遂げられるものではなく、継続的な取り組みが不可欠です。そのため、今回紹介した研修プログラムは単発の施策ではなく、来期以降も継続して実施していく予定です。この活動を継続・拡大していくことで、レンゴー全体のデータ活用促進とDX推進をさらに加速させ、中期経営計画で掲げたDXによる価値創出の実現に向けて着実に前進していきます。 まとめ 本稿では、レンゴーがデータ活用を全社的に拡大するために取り組んだ包括的なアプローチについてご紹介しました。データ駆動組織を作るためには、「ソフトスキル」「ハードスキル」「ツール」という３つの要素全てを同時に、そして継続的に推し進めることが必要です。この認識のもと、私たちはAWSとパートナー企業であるJSOLの協力を得て、三つの観点を網羅する包括的な研修プログラムを構築しました。私たちの取り組みはまだ始まったばかりですが、すでに具体的な成果が表れ始めています。この経験が、同様の課題に直面している他の企業の皆様にとって、データドリブン経営への道筋を考える一助となれば幸いです。 図 7 社内広報（表紙） 著者について レンゴー株式会社 情報システム本部 情報システム第一部 課長代理　平田　匡人（Tadahito Hirata） SIer、事業会社にてシステム企画構想から運用保守まで約15年従事。特にアフターサービス分野、グローバルシステム構築に強みを持つ。現在は、段ボール・紙器・軟包装事業の基幹システム運用保守とDX案件に従事。データ分析分野においては、データ分析人材育成のプロジェクトリーダーとして推進している。

映画スタジオのように、膨大な量のビデオファイル、スクリプト、アニメーションアセットを扱う会社を想像してみてください。これらのファイルは Amazon FSx for Lustre などの高性能ファイルシステムに格納されます。Amazon FSx for Lustre は、世界で最も普及している高性能ファイルシステム上に構築された完全マネージド型の共有ストレージです。各ファイルには POSIX 情報などのメタデータがあります。スタジオのプロジェクトが増えるにつれて、ファイルやディレクトリの数も増えます。ファイルの検索や、ファイルへのアクセス、ディレクトリ内の一覧表示を実施する必要がある場合、システムはこのメタデータをすばやく取得して管理する必要があります。しかしながら、従来のファイルシステムでは、ファイル数が特に数百万または数十億に増加すると、メタデータ操作が大幅に遅くなる可能性があります。この速度低下がボトルネックとなり、ファイルの取得が遅れ、チームの生産性が低下する可能性があります。これは、厳しい締め切りの中で作業する場合に非常に重要です。 FSx for Lustre は、CPU と GPU を最大容量で使用し続け、TB/秒のスループットと数百万 IOPS に達する高速ストレージを必要とするアプリケーション向けに設計されています。何千ものコンピューティングインスタンスから同じファイルやディレクトリへ同時アクセスをサポートしながら、ファイル操作において一貫性のあるミリ秒未満のレイテンシーを提供することは、多くのワークロードを実現に結びつきます。FSx for Lustre は、 図 1 に示すようにオブジェクトストレージサーバ (OSS) を使用して複数のノードにファイルを分散します。そのため、ストレージ容量とスループットのバランスをとるために、各読み取りまたは書き込み操作はクラスター全体で並列化されます。FSx for Lustre は専用のメタデータサーバ (MDS) を使用してメタデータ操作をサポートします。 図 1. スケーラブルなメタデータ機能以前の FSx for Lustre 構成図 ファイルシステムのメタデータパフォーマンスは、ファイルシステムが 1 秒あたりに作成、一覧表示、読み取り、削除できるファイルやディレクトリの数を決定します。メタデータを集中的に使用するワークロードでは、多数の小さなファイルの作成、処理、操作が必要となることが多くあります。FSx for Lustre は、プロビジョニングされたストレージ容量に基づいて、デフォルトのメタデータパフォーマンスレベルを自動的に提供します。スケーラブルなメタデータ機能がリリースされる以前は、デフォルトよりも多くのメタデータ操作を必要とするユーザーは、より大きなファイルシステムを作成するか、データを複数のファイルシステムに分割する必要がありました。スケール可能なメタデータのリリースにより、ユーザーはプロビジョニングされたストレージとは独立して、利用可能なメタデータ IOPS を最大 15 倍まで増やすことができるようになりました。これにより、最もメタデータを集中的に使用するワークロードでも利用が可能になります。さらに、この機能は 図 2 に示すように、ファイルシステムの作成時に有効にすることも、ファイルシステムの作成後に有効にすることも可能で、特定のファイルシステムに対してメタデータ操作専用の IOPS の量を増やすことができます。 図 2. スケーラブルなメタデータ機能を備えた&nbsp;FSx for Lustre 構成図 ワークロードやユースケース この新機能により、データ管理が合理化され、機械学習（ML）、電子設計自動化（EDA）、財務分析リスクシミュレーションなど、メタデータを多用するワークロードを必要とするユースケースの効率が向上します。EDA における基礎設計や、研究者がプロジェクト作成中にデータセットの名前を変更するといった作業負荷は、メタデータを多用する性質上、ファイルシステムに大きな負荷をかけます。 MDTest を使用してこれらの操作の上限をテストできます。 メタデータパフォーマンス 特定のワークロードに FSx for Lustre ファイルシステムを導入するには、パフォーマンスを最適化する上でメタデータ IOPS がどのように重要な役割を果たすかを理解する必要があります。 図 3a に示すように、自動モードの FSx for Lustre はファイルシステムのストレージ容量に基づいてメタデータ IOPS を自動的に割り当てるため、プロセスが簡素化されます。このアプローチでは、IOPS の数とストレージのサイズが相関関係にあるため、手動で調整しなくても大半のワークロードで適切なレベルのパフォーマンスが得られます。たとえば、1,200 GiB のストレージを備えたファイルシステムは自動的に 1,500 のメタデータ IOPS を受け取りますが、大規模なシステムでは 12,000 GiB を超える容量の場合、最大 12,000 メタデータ IOPS にスケールアップします。 一方、 ユーザープロビジョニングモード では、よりきめ細かい制御が可能です。ストレージ容量に関係なく、必要なメタデータ IOPS の正確な値を手動で指定できます。このモードは、自動モードでは対応しきれないメタデータ IOPS を要するワークロードに適しています。 図 3a. ファイルシステムのメタデータパフォーマンス FSx for Lustre は、 図 3b に示すように、ファイルの作成、削除、ディレクトリ操作などにメタデータ操作を分類し、それぞれ 1 秒あたりの処理レートが異なります。これは、数百万にも及ぶファイルシステムの IOPS とは異なります。たとえば、ファイル削除の操作はプロビジョニングされた IOPS ごとの 1 秒あたりの処理レートが 1 であるのに対し、ファイル作成やファイルを開く操作は 1 秒あたりの処理レートが 2 となります。プロビジョニングされた IOPS の値を、ワークロードが必要とする特定の種類の操作に合わせれば、FSx for Lustre はメタデータを効率的に処理できるようになります。この最適化は、ファイルシステム全体のパフォーマンスを向上させるだけでなく、ストレージや運用上のニーズの拡大に応じたスケーラビリティもサポートします。 図 3b. ファイルシステムのメタデータパフォーマンス 前提条件 この操作手順では、次の前提条件を満たす必要があります。 AWS アカウント FSx for Lustre ファイルシステムの作成および変更 Slurm を利用した既存の AWS ParallelCluster の使用 AWS ParallelCluster での Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの作成 Lustre クライアントのチューニングに関する理解 Linux コマンドラインの実践的な知識 Amazon CloudWatch ダッシュボードの作成 メタデータパフォーマンスの設定方法 新しい FSx for Lustre ファイルシステムを作成する場合、 図 4a に示すように、メタデータパフォーマンスを自動モードとして定義する新しいオプションがあります。この場合、IOPS はファイルシステムの容量 (24 TiB のストレージあたり 12,000 メタデータ IOPS) に基づいて自動的に定義されます。または、 図 4b に示すように、ユーザープロビジョニングモードとして定義することもできます。この場合、ユーザーはメタデータ IOPS の値に 1,500、3,000、6,000、あるいは 192,000 メタデータ IOPS までの 12,000 の倍数を指定できます。ユーザーは、 AWS マネジメントコンソール 、 AWS Command Line Interface (AWS CLI), 、または AWS Software Development Kits (SDKs) を使用して、メタデータパフォーマンスを向上させる機能を持った FSx for Lustre ファイルシステムを作成できます。 図 4a. メタデータ設定の自動モード 図 4b. メタデータ設定のユーザープロビジョニングモード テストの実行 このセクションの目標は、さまざまなワークロードシナリオにおける標準のメタデータ設定とスケールされたメタデータ設定のメタデータパフォーマンスを比較することです。また、これらのテストをお客様の AWS アカウントで再現する手順についても説明します。 図 5 は、コンソールで作成されたファイルシステムの例を示しています。この特定のファイルシステムは 12 TiB のストレージで構成されており、1,500 MB/秒のスループット (125 MB/秒) と 192,000 のメタデータ IOPS を実現しています。この構成は、スループット要件は低くメタデータ操作が集中するアプリケーション向けに調整されています。 図 5. 192,000 メタデータ IOPS で作成されたファイルシステム このテストシナリオでは、2 組の大規模ファイルシステムを作成しました。いずれも P250 と P1000 のスループット構成で、一方はスケールされたメタデータを持たないサイズが 12 TiB のファイルシステム、もう一方は 192,000 IOPS のスケールされたメタデータを持つサイズが 12 TiB のファイルシステムです。 AWS ParallelCluster を使用して、この HPC ベンチマークを実行するためのクラスターを構築しました。以下の設定の c5.9xlarge インスタンスタイプのクライアント EC2 インスタンスが 200 個あります。 Instance type: c5.9xlarge Operating Systems: Amazon Linux 2 Linux Kernel: 5.10.219-208.866.amzn2.x86_64 mpi version: Open MPI 4.1.6 lustre version: 2.12.8_198_gde6dd89_dirty ENA driver: 2.12.0g Ranks for job: 800 ParallelCluster: 3.10.1 Lustre クライアント側のパラメータ sudo lctl set_param osc.*OST*.max_rpcs_in_flight=32 sudo lctl set_param mdc.*.max_rpcs_in_flight=64 sudo lctl set_param mdc.*.max_mod_rpcs_in_flight=50 sudo lctl set_param osc.*.max_dirty_mb=64 Lustre パフォーマンス設定の詳細については、 FSx for Lustre パフォーマンスガイド とオンラインの Lustre ドキュメント を詳しく調べてください。 テストツールとして、このシナリオではオープンソースの MDTest を使用してメタデータの I/O シミュレーションを行います。 MDTest のインストールと実行 次のコマンドは、OpenMPI ライブラリとコンパイラを使用してユーザーの PATH と LD_LIBRARY_PATH で実行しました。 $ git clone https://github.com/hpc/ior.git $ cd ior $ ./bootstrap $ ./configure --prefix=/opt/parallelcluster/shared $ make all $ make install この時点で、トラブルシューティングを行ったり、テストを積極的に監視したりしたい場合に備えて、MDTest を起動するためのインタラクティブジョブを実行しています。 $ srun --nodes=200 --ntasks-per-node=32 --time=12:00:00 --pty bash -i EC2 インスタンスが利用可能になった時点で、そのテストを実施するために、自分の UID がフルアクセス権限を持つサブディレクトリを作成しました。 (例) $ sudo mkdir -p /fsx/mdTestFiles $ chown 1000:1000 /fsx/mdTestFiles 次に、ジョブを実行します。このジョブは 3 回繰り返され、ワークロードの平均を確認できます。 $ mpirun --mca plm_rsh_num_concurrent 800 --mca routed_radix 800 --mca routed direct --map-by node --mca btl_tcp_if_include eth0 -np 800 /opt/parallelcluster/shared/bin/mdtest -F -v -n 4000 -i 3 -u -d /fsx/mdtestFiles MDTest オプションの説明 : -F: ファイルのみでテストを実行 (ディレクトリを含まない) -v: 詳細出力 -n 4000: ランクごとに create/stat/read/remove を行うディレクトリやファイルの数 -i 3: テストを実行する反復回数 -u: 各ランクに固有の作業ディレクトリ -d: ジョブのルートディレクトリ 図 6 は単一メタデータターゲット (MDT) を持つ 12 TiB のファイルシステムで実行された最初のジョブの出力例を示しています。 図 6. MDTest 実行時の出力例 このセクションでは、先の図における単一メタデータターゲット (MDT) 12 TiB の FSx for Lustre ファイルシステムの最初のテストで確認されたことを詳しく説明します。ファイル作成 (create) は、1 つのプロセスイベントで 1 ファイルずつ作成されます。これは小さな書き込みワークロードと解釈できます。統計 (stat) の観点から見ると、これは Lustre にとってコストのかかる操作になる可能性があり、ツリーウォークや大規模な “ls -l” がどのように動作するかを表しています。ファイルの読み取り (read) は読み取りワークロードであり、ファイルの削除 (remove) はファイルシステムからファイルを完全に消去することです。メタデータサーバへの負荷は、イベントごとに異なります。 図 7 はクライアントの数とキャパシティを同じ条件に保ちながら、異なるファイルシステムタイプで実施した複数回の実行結果を包括的にまとめた表になります。 図 7. MDTest の結果 上の表は、それぞれメタデータ IOPS が 12,000 と 192,000 のファイルシステムのパフォーマンスの違いを示しています。パフォーマンスの違いは操作タイプに関連しており、メタデータ IOPS が高いほどすべてのテストで改善が見られます。ワークロードの要件によって FSx for Lustre のメタデータ IOPS を高める明確な方法があります。 ファイルシステムのメタデータメトリクスの監視 ファイルシステムの稼働時には、CloudWatch メトリクスを使用してメタデータのパフォーマンスを監視し、増加するワークロード要件に対応するため、必要に応じてパフォーマンスをスケールアップすることができます。FSx for Lustre の監視は、システムの安定性を維持し、発生する可能性のある問題に迅速に対処するために不可欠です。CloudWatch は監視の中心的なツールとして機能し、FSx for Lustre からリアルタイムのメトリクスを継続的に収集して処理します。CloudWatch アラームを設定すると、異常時やパフォーマンスのしきい値に超えたときに、管理者は Amazon Simple Notification Service (Amazon SNS) を通じて即座に通知を受け取ることができ、潜在的な問題を軽減するための対応が可能になります。 FSx for Lustre は、デフォルトで 1 分間隔でメトリクスデータを CloudWatch に自動的に送信し、これらのメトリクスは raw バイトで報告されます。CloudWatch とその機能の詳細については、 CloudWatch ユーザーガイド を参照してください。 FSx for Lustre は、そのメトリクスを CloudWatch の FSx 名前空間に発行します。新しいスケーラブルメタデータ機能により、 図 8a、8b、8c に示すような 新しいメトリクス を利用して、メタデータ操作の詳細を確認できるようになりました。新しいメトリクスには DiskReadOperations や DiskWriteOperations 、 FileCreateOperations 、 FileOpenOperations 、 FileDeleteOperations 、 StatOperations 、 RenameOperations があります。これらのメトリクスからより詳細なデータが利用可能になるため、 FileSystemID (特定のファイルシステム用) と StorageTargetID (特定の MDT – メタデータターゲット用) を使用してデータを絞り込むことができます。 図 8a. CloudWatch ダッシュボードにおける新しいメタデータメトリクス 図 8b. CloudWatch ダッシュボードにおける新しいメタデータメトリクス 図 8c. CloudWatch ダッシュボードにおける新しいメタデータメトリクス FSx for Lustre のスケーラブルなメタデータ用の AWS CloudFormation テンプレートをダウンロードするにはこちらを利用してください : 料金 このソリューションを試す場合、費用が発生します。このソリューションでは EC2 インスタンス、FSx for Lustre ファイルシステム、および CloudWatch ダッシュボードを実行しています。 料金の詳細は、 FSx for Lustre 、 EC2 インスタンス 、および CloudWatch の料金ページで確認できます。 クリーンアップ 今後の確認に備えて、必要なすべてのパフォーマンスの実行をバックアップします。 FSx for Lustre ファイルシステムと関連するコンピューターリソースを削除して、そのプロジェクトの課金を終了してください。CloudFormation ページよりダッシュボードを削除して、アカウントから削除してください。 必要に応じて ParallelCluster を管理してください。コストを節約するために、不要になったら削除してください。 まとめ この新機能の影響は広範囲に及び、特に要求の厳しい AI/ML や HPC ワークロードを実行している組織にとって重要です。これらのワークロードでは、多くの場合、膨大な数の小さなファイルの作成、処理、操作が行われ、メタデータパフォーマンスに大きな負荷がかかります。Amazon FSx for Lustre ではメタデータパフォーマンスをスケールすることで、ユーザーはワークロードを 1 つのファイルシステムに統合できます。これは、ワークロードを分割せずにワークロードをより大規模に実行すること、メタデータパフォーマンスを容易に向上させ変化するパフォーマンス要件に適応すること、メタデータパフォーマンスをストレージ容量から切り離してリソースの使用を最適化することで実現されます。 このブログは 2025 年 2 月 21 日に Tom McDonald (Senior Workload Storage Specialist) によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 この記事を読んでいただきありがとうございました。 翻訳はクラウドサポートエンジニアの奥野が担当しました。 <!-- '"` --> TAGS: Amazon FSx for Lustre , AWS Cloud Storage , High-Performance Computing (HPC) , machine learning Tom McDonald Tom McDonald は AWS の Senior Workload Storage Specialist です。Atari 400 やテープの再プログラミングから始まり、Tom はあらゆるストレージサービスのパフォーマンス向上に長年関心を持ち続けてきました。資源開発分野でファイルシステムや高性能コンピューティングの 20 年以上の経験を持つ Tom は、コミュニティやガイダンスを通して多くの方を支援することに情熱を持っています。

AWS の生成 AI コスト最適化に関する全 5 回構成 シリーズ の 4 回目のブログでは、前回までの議論を踏まえて AWS の生成 AI を活用したアシスタントである Amazon Q の価値を最大化することに焦点を当てます。以前の記事では、 Amazon EC2 と SageMaker AI による AI モデル構築のコスト最適化 と Amazon Bedrock で基盤モデルを使用する際のコスト最適化 について説明しましたが、今回は Amazon Q を利用する際のコスト最適化戦略を探ります。適切な料金プランの選択、戦略的ユーザー管理の実装から、コンテンツのインデックス作成の最適化やコスト予測可能性の向上まで、機能性とコスト効率のバランスを取るのに役立つ実践的なアプローチを紹介します。生成 AI を活用したアシスタントとして Amazon Q Business を使用する場合でも、開発者の生産性を高めるために Amazon Q Developer を使用する場合でも、これらのベストプラクティスは、Q の利用について情報に基づいた意思決定を行うのに役立ちます。 Amazon Q を理解する: Business と Developer Amazon Q Business は、情報の検索、コンテンツの生成、およびタスクの自動化を支援するように設計された AI 搭載アシスタントです。利点として、迅速な対応による生産性の向上、コンテキストを踏まえた回答、安全なデータアクセスによる意思決定の強化やビジネスツールとのシームレスな統合などがあります。生成 AI のニーズに応えて Amazon Q Business を採用するケースが増えるにつれ、投資収益率（ROI）を最大化するには、コスト最適化戦略を理解することが重要になります。 Amazon Q Developer は、リアルタイムのコード提案システムと自動タスク実行を通じてソフトウェア開発を促進し、生産性の向上と開発期間の短縮を実現しています。このツールにより、開発ライフサイクル全体にわたる迅速なオンボーディング、コード品質の向上やセキュリティ統合が可能になります。Amazon Q Developer は、あらゆる規模のビジネスに対応できるようにユーザー単位の価格を設定しており、JetBrains、VS Code、Visual Studio や Eclipse などの IDE と統合できます。Amazon Q Developer について言えば、先日、私たちはコスト最適化の機会を見つけるのに役立つ魅力的な新しいコスト最適化推奨機能を発表しました。この機能は、自然言語での会話を通じ、インスタンスのライトサイジング、Savings Plans やリザーブドインスタンスの購入やアイドル状態のリソースの終了などのコスト最適化の機会を見つけるのに役立ちます。これは、コードの作成中にリソースの使用を最適化し、コストを最適化するための効率的な方法となります。 図 1. Amazon Q によるコスト最適化分析 それでは、メイントピックである Amazon Q のコストを最適化するための実践的なヒントに戻りましょう。 料金プランの選択 始めに決めることは、適切な料金プランを選択することです。Amazon Q Business には、Amazon Q Business Lite と Amazon Q Business Pro の 2 つの料金プランがあります。 Amazon Q Business の料金 をご覧ください。ビジネス要件に合わせてプランを慎重に選択することで、最大 85% のコスト削減を実現できます。Amazon Q Business Lite の料金は、ユーザー 1 人につき 1 か月あたり $3 です。安全なデータアクセスや権限に応じた応答などの基本機能を提供します。応答の最大サイズは 1 ページまでとなります。（訳注：1 ページのサイズは ドキュメント 参照）Amazon Q Business Pro は、ユーザー 1 人につき 1 か月あたり $20 です。すべての Amazon Q Business Lite 機能に加えて、Amazon Q Apps、コンテンツ作成ツールや最大 7 ページの長い応答が含まれます。Amazon Q Business Pro のユーザーは、Q in QuickSight (Reader Pro) を使用して構造化データに関するインサイトを得たり、一般的なサードパーティアプリ用のカスタムプラグインやマネージドプラグインを使用したり、画像ベースの応答を受け取ったりすることもできます。 Amazon Q Business 料金プランの変更 Amazon Q Developer にも、Amazon Q Developer 無料利用枠と Amazon Q Developer Pro の 2 つの料金プランがあります。 Amazon Q Developer の料金 をご覧ください。無料利用枠では、Amazon Q Developer を簡単に使い始めることができます。無料利用枠には、コードの提案、CLI の補完、CLI の統合がありますが、 高度な機能への 1 ヶ月あたりのアクセスが制限されています。Amazon Q Developer Pro は 1 か月あたり $19 で、無料利用枠のすべての機能に加えて、エンタープライズアクセス制御、コードベースのカスタマイズやクエリ作成、コード変換などの高度な機能に対する制限の緩和が含まれます。 料金プランの決定は、より高い料金プランを無条件で選択するのではなく、ユースケースとユーザーニーズを分析して決定する必要があります。これにより、ユーザーが実際に利用する機能に見合った料金プランとなるためコスト効率を維持できます。 戦略的ユーザー管理 Amazon Q Business と Amazon Q Developer のユーザーアクセスを管理することは、コストの最適化と業務の効率化にとって非常に重要です。これは、サービスの料金がユーザーごとに設定されているためです。厳格なユーザー管理手法を導入することで、その機能を本当に必要とするユーザーだけがアクセスできるようにし、非アクティブなユーザーやたまにしか使用しないユーザーによる不必要なライセンスコストを防ぐことができます。ユーザーアカウントを定期的に監査し、離職したユーザーのアクセス権を削除し、使用パターンが最小限であるユーザーにはライセンスの必要性を再評価する必要があります。さらに、ユーザーを役割とニーズに基づいて適切な権限階層とグループに分割することで、データアクセスをより適切に制御し、セキュリティコンプライアンスを維持し、リソースの浪費を防ぐことができます。ユーザー管理に対するこの戦略的なアプローチは、ユーザーのコストを削減するだけでなく、サービスの使用状況をより適切に監視するのにも役立ちます。 コンテンツインデックスの最適化 Amazon Q Business は、データソースの接続による検索拡張生成（RAG）をサポートしています。 Amazon Q Business データソースの接続 を参照してください。インデックス作成プロセスは単位時間ごとの料金設定で、1 つのアベイラビリティーゾーンのスターターインデックスを作成するか、3 つのアベイラビリティーゾーンにまたがってエンタープライズインデックスを作成できます。インデックス作成の時間と頻度を最小限に抑えることは、インデックス作成コストにプラスの影響を与えます。インデックス費用の例については、 Amazon Q Business の料金ページ の「価格設定の例」セクションの例 3 から 5 を参照してください。インデックス作成コストを管理するうえで重要な 2 つの手段は、「同期モード」と「同期実行スケジュール」です。 同期モードには 2 つのオプションがあります。「Full sync」 を選択すると、Amazon Q は以前の同期ステータスに関係なく、すべてのコンテンツを同期してインデックスを作成します。「New, modified, or deleted content sync」を選択すると、Amazon Q は新規、変更、削除されたコンテンツのみを同期します。データを段階的に追加または変更する場合は、コストを最小限に抑えるために 「New, modified, or deleted content sync」 を選択する必要があります。データソースに大きな変更を加える必要がある場合は、「Full sync」 を選択して同期を 1 回実行するとよいでしょう。その後、「New, modified, or deleted content sync」に戻す必要があります。 「「Sync run schedule」では、インデックス作成の頻度を設定できます。選択できる項目は、時間単位、日単位、週単位、月単位、またはカスタム（cron 式）です。接続されているデータソースが更新される頻度と、ソリューションに必要なデータのインデックス作成頻度に基づいて、インデックス作成頻度を最適化する必要があります。この設定の実行頻度が高すぎると、予期しないコストが発生する可能性があります。 結論 Amazon Q Business と Amazon Q Developer の最大の利点の 1 つは、予測可能なコスト構造です。コアビジネスの目標に焦点を当てながら、経費を正確に予測できます。この予測可能性とフルマネージド型のサービスを組み合わせることで、インフラストラクチャの管理を気にすることなく価値の提供に集中できます。 ここまで、料金プランの選択、ユーザー管理やコンテンツインデックスの最適化を通じて、Amazon Q Business と Amazon Q Developer のコストを最適化するための主な要素について説明してきました。次回のブログでは、AI ソリューションと連動するサービス (ストレージ、ベクトルデータベース、データ転送やレポート) のコスト最適化戦略について説明します。費用対効果が高くスケーラブルな AI アプリケーションを構築するための重要なインサイトをお見逃しなく。 翻訳はテクニカルアカウントマネージャーの加須屋 悠己が担当しました。原文は こちら です。 Adam Richter Adam Richter は、AWS OPTICS のシニア最適化ソリューションアーキテクトです。この役職では、Adam は AI コスト最適化と FinOps プラクティスを専門としています。Amazon Q Business や Amazon Q Developer などの顧客向け機能に貢献したほか、AWS re:Invent やその他の業界プラットフォームでの講演を通じてオピニオンリーダーとしての役割を果たしてきました。 Bowen Wang Bowen は AWS 請求およびコスト管理サービスのプリンシパルプロダクトマーケティングマネージャーです。彼女は、財務およびビジネスリーダーがクラウドの価値とクラウドファイナンス管理を最適化する方法をよりよく理解できるようにすることに重点を置いています。以前のキャリアでは、テック系スタートアップの中国市場への参入を支援しました。

コンタクトセンターにおける予期せぬサービス中断は、深刻な影響を及ぼす可能性があります。エージェントがシステムにアクセスできない、顧客が接続の問題に直面する、そしてサポートチームがサービスの迅速な復旧に追われることになります。このようなシナリオは極端に思えるかもしれませんが、現代のコンタクトセンター運営においては、このような状況に対する机上演習が不可欠です。 このブログ記事では、Amazon Web Services (AWS) が提供する AI を活用したクラウドコンタクトセンターソリューション、 Amazon Connect 向けのいくつかの机上演習を紹介します。これらは、コンタクトセンターの移行に際しての様々なシナリオの確認や、予期せぬ事態に備えたプロセスと手順の更新に役立つはずです。 机上演習とは 机上演習は、企業規模を問わず重要な取り組みです。机上演習は、サイバー攻撃、自然災害、システム障害などの危機に対する対応計画をテストでき、体系的に管理された環境を構築するのに役立ちます。演習では、企業のシニアエグゼクティブ、部門長、危機管理チームなどの主要な利害関係者が参加し、戦略的な議論と意思決定プロセスに関わることが必要です。潜在的な脅威や混乱に対処する訓練を通して、企業は緊急時対応手順の不足やずれを特定し、コミュニケーションや連携を改善、実際の事態が発生した際の各チームの役割をしっかりと理解することができます。 また、机上演習は組織のリスク管理戦略を改善し、組織のレジリエンスを高め、予期せぬ課題に直面した際に、自信をもって迅速かつ効果的に対応する能力を構築し、最終的には企業の業務継続と評判を保護することに役立ちます。 1) Amazon Connect サービスの中断 シナリオ : Amazon Connect で一時的なサービス停止が発生し、特定のリージョンでコンタクトセンターでの通話の発信や受信ができなくなりました。顧客がサポートエージェントに連絡できず、エージェントも通話を処理するためのシステムにアクセスできません。 主な方針 : 事象が自身の Amazon Connect インスタンスに限定されているのか、複数のリージョンに影響しているのかを確認します AWS PHD でサービスの問題を確認します CloudWatch メトリクス を使用して、潜在的な原因（接続性の問題、API 制限など）を調査します エンドユーザーとステークホルダーに対して、停止の状況と復旧予想時間を通知する方法を決定します 代替システムへの通話の転送や、異なるリージョンの使用など、回避策を実施します 2) 品質低下または遅延発生 シナリオ : 顧客通話の一部で高い遅延と音声品質の低下が発生し、顧客体験の悪化につながっています。この問題は、特定の地域のエージェントと顧客との間の通話に影響を与えているようです。 主な方針 : Amazon Connect の音声メトリクスと Amazon CloudWatch を使用してネットワークパフォーマンスを調査します SIP トランキングや電話統合など、関係する第三者システムの状態を確認します 問題が地域のインフラまたはネットワーク輻輳に関連しているかを特定します Amazon Connect Voice Analytics ツールや CloudWatch Logs などの診断ツールを使用して音声品質をテストします AWS サポートに連絡する際、サポートのトラブルシューティングに役立つよう、 HAR ファイル/コンソールログを準備します(参照: https://repost.aws/ja/knowledge-center/support-case-browser-har-file ) 3) コンタクトフローの設定ミス シナリオ : 新しく更新されたコンタクトフローにより、顧客が正しい部署にルーティングされない状況が発生しています。意図したエージェントにつながらず、顧客との接続が切断されたり、誤ったキューに転送されたりしています。 主な方針 : CloudWatch メトリクス で「ContactFlowErrors」と「ContactFlowFatalErrors」を確認します 影響を受けたコンタクトを特定し、 CloudWatch のコンタクトフローログでエラーに関する詳細情報を確認します コンタクトフローを確認し、設定ミス（不適切な条件、誤ったキューへのルーティングなど）を特定します 設定変更が問題の原因である場合、機能を復旧するためのロールバック計画またはホットフィックスを実施します 変更後にコンタクトフローをテストし、問題が解決されたことを確認します チームとエンドユーザーに変更内容を文書化して伝達します 4) Amazon Connect インスタンスの動作が遅い シナリオ : Amazon Connect インスタンスにおいて、エージェントのログインにかかる時間、コールのルーティング、管理ダッシュボードのパフォーマンスに遅延が発生しています。これは顧客とエージェントの両方の体験に影響を与えています。 主な方針 : Amazon CloudWatch を使用してシステムのパフォーマンスとリソース使用状況を監視します 同時使用のスパイクや Amazon Connect のサービス制限を確認します 問題が高トラフィック量または設定エラーに関連しているかを特定します 関連リソースのスケールアップや使用パターンの調整など、是正措置を講じます 5) AWS Lambda 関数のタイムアウト シナリオ : カスタム統合（例：データベースからの顧客データの取得）に使用される Lambda 関数がタイムアウトし、通話処理に遅延を引き起こし、その結果、通話の切断や情報取得の遅延が発生しています。 主な方針 : Lambda 関数 のログを確認し、タイムアウトが発生している理由（例：遅いデータベースクエリ、関数のロジックエラー）を特定します Amazon Connect の外部で Lambda 関数を手動でテストし、パフォーマンスの問題を確認します Lambda のタイムアウト設定を変更し、関数のコードを調整してパフォーマンスを改善します Lambda 関数が AWS サービスの制限に達していないか、リソースの制約に抵触していないかを調査します 6) CRM (Customer Relationship Management) 統合の問題 ( 例：Salesforce、ServiceNow) シナリオ : Amazon Connect から発信された通話で、CRM への顧客データの取り込みが失敗し、エージェントが顧客対応時に必要な情報にアクセスできない状況が発生しています。 主な方針 : Amazon Connect と CRM システム間の API 統合が機能しているか調査する CRM または Amazon Connect の統合に関する最近のアップデートや変更で問題の原因となった可能性があるものを確認する 両システム間の認証と承認の設定（API キー、IAM ロールなど）を確認する Amazon Connect と CRM 間の接続を手動でテストし、エラーがないかログを確認する 7) ルーティングプロファイルの設定ミス シナリオ : エージェントが誤ったルーティングプロファイルに割り当てられており、その結果、間違ったキューからの通話を受信したり、まったく通話を受信できない状態になっています。 主な方針 : ルーティングプロファイル を確認し、正しいエージェントに割り当てられていることを確認します キューに配置されるメンバーとスキルが適切に設定され、通話が適切にルーティングされるようにします 異なるエージェントでルーティングロジックをテストし、通話が正しくルーティングされることを確認します 設定の不一致を調整し、システムの改善状況を監視します 8) 高い通話放棄率 シナリオ : コンタクトセンターで異常に高い通話放棄率が発生しています。顧客がエージェントに到達する前に、またはキュー待機中に電話を切ってしまっています。 主な方針 : Amazon Connect のメトリクスを使用してキューの長さと待ち時間をモニタリングし、許容範囲を超えていないか確認します コンタクトフローの設定を確認し、推定待ち時間が顧客に明確に伝えられているか検証します エージェントの稼働状況にボトルネックがないか、またはシステムが過負荷になっていないか確認します 待ち時間を短縮し、より正確な待ち時間予測を提供するために IVR やルーティング戦略を調整します 9) エージェントの認証失敗 シナリオ : エージェントが Amazon Connect インスタンスにログインできない状態です。アイデンティティプロバイダー（例：AWS IAM Identity Center 、Active Directory）の設定ミスが原因と考えられる認証エラーが発生しています。 主な方針 : Amazon Connect とアイデンティティプロバイダーの連携が有効な状態を維持しているか確認します エージェントのログインに影響を与える可能性のある IAM ロール 、ポリシー、またはセキュリティ設定の最近の変更を確認します 認証やアクセス許可のエラーについて CloudWatch Logs を確認します 問題がアカウント固有のものかシステム全体に及ぶものかを切り分けるため、異なるアカウントでエージェントのログインをテストします 10) 顧客データの不整合 シナリオ : Amazon Connect または統合されたシステム (AWS Lambda、Amazon DynamoDB など)に保存されている顧客データが、顧客とのやり取りの中で一貫性を持っていません。例えば、以前のケースメモや顧客の設定が次の通話でエージェントに表示されないなどの問題が発生しています。 主な方針 : データ統合のプロセス(Lambda、DynamoDB、Salesforce など)が正しく機能していることを確認します 通話中にリアルタイムで顧客データが正しく取得、保存、更新されていることを確認します 不整合の原因となる可能性のあるデータ同期の問題を調査します エージェントのデータ取得の一貫性を確保するための修正を実装し、将来のデータの不一致に備えてログ記録とエラー処理を見直します 11) マルチチャネル体験の品質低下 シナリオ : 顧客のマルチチャネル体験（音声、チャット、メール）が低下し、顧客が異なるチャネル間で一貫性のない対応を受けています。 主な方針 : Amazon Connect と他のチャネルとの統合を確認します 各チャネルのコンタクトフローが正しく設定されており、顧客データがチャネル間で共有されていることを確認します（例：音声からチャットへ、またはその逆にコンテキストを受け渡せているか） すべてのチャネルの CloudWatch メトリクスを監視し、特定のチャネルのパフォーマンスが低下していないか確認します 各チャネル（音声、チャット、メール）を個別にテストし、品質低下の性質を確認します チャネル間のエスカレーションオプション（例：チャットから音声通話への転送）を実装し、顧客のコンテキストがチャネル間で保持されることを確認します まとめ このブログ記事では、Amazon Connect の 11 種類の多様な机上演習シナリオを紹介し、コンタクトセンター環境で発生する可能性のある一般的な問題のトラブルシューティングと解決に向けた包括的なアプローチを紹介しました。それぞれの課題に対処するための詳細な手順を確認することで、みなさまが Amazon Connect の機能を効果的に管理するための貴重な知見を得られることを願っています。 これらの演習は問題解決技術を強化するだけでなく、安定的な運用を維持するための事前計画、テスト、継続的なモニタリングの重要性も示しています。コンタクトセンターのマネージャーであれ、技術専門家であれ、これらのシナリオを練習することで、実際の問題に自信を持って効率的に取り組むために必要なレジリエンスと専門知識を身につけることができます。 そして、継続的にこのような演習を通じて改善することで、Amazon Connect 環境の堅牢性を維持し、優れた顧客体験の提供を保つことができます。 Renato Gentil Renato は、アイルランドを拠点とする AWS での 7 年以上の経験を持つシニアテクニカルアカウントマネージャーです。4 つの AWS 認定資格を保有しており、世界中のさまざまな顧客と大規模なレジリエンスプロジェクトに取り組み、机上演習やインシデント管理プロセスを通じてレジリエンスの改善を支援しています。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

数万人の顧客が Amazon DynamoDB の グローバルテーブル を最終的整合性で正常に使用していますが、さらに強力なレジリエンスに対する新たなニーズが出てきています。多くの組織は、DynamoDB の複数アベイラビリティゾーンアーキテクチャと最終的整合性のグローバルテーブルが要件を満たすことを見出していますが、決済処理システムや金融サービスのような重要なアプリケーションには、さらに高い要求があります。 これらのアプリケーションでは、顧客は稀なリージョン全体のイベント時にゼロ目標復旧時点 (RPO) を要求します。つまり、アプリケーションが任意のリージョンから最新のデータを読み取れるようにする必要があります。マルチリージョンアプリケーションは、場所に関係なく常に同じデータにアクセスする必要があります。 6 月 30 日より、Amazon DynamoDB グローバルテーブルの新機能として、マルチリージョン強整合性 (MRSC) がご利用いただけるようになりました。これにより、ゼロ RPO (目標復旧時点) を実現できます。この機能は、 2024 年の AWS re:Invent でプレビュー として初めて発表され、グローバル規模で高い耐障害性を備えたアプリケーションの構築を簡素化します。 以下は、既存の空の DynamoDB テーブルから MRSC を有効にする方法です。 次の手順で、既存の空の DynamoDB テーブルに対して MRSC を有効にできます。あるリージョンでアプリケーションの処理が中断された場合でも、MRSC レプリカを保持する別のリージョンにトラフィックをリダイレクトすることで、最新のデータを用いて処理を継続できることが保証されます。 はじめに この新しい機能の使い方を順を追ってご説明します。 MRSC を利用開始するには、データが含まれていない既存の DynamoDB テーブルからグローバルテーブルを作成する必要があります。既存のテーブルに移動し、 グローバルテーブルタブ を選択して、 レプリカの作成 を選択します。 MRSC の可用性アーキテクチャでは、3 つの AWS リージョンが必要です。MRSC は、3 つのフルレプリカを構成することも、2 つのレプリカとウィットネスで構成することもできます。ウィットネスには、必要な可用性を確保するための変更データのみが複製され、テーブルデータ全体のコピーは保持されません。 次のスクリーンショットは、2 つのレプリカとウィットネスで MRSC を構成する方法を示しています。代わりに 3 つのフルレプリカで MRSC を構成するには、 リージョン 2 をウィットネスとして構成する のチェックを外すことで設定できます。 既存のテーブルをプログラムで更新する必要がある場合は、次のプロンプトを使用して、必要なコマンドを生成するために Amazon Q CLI を利用できます。 &gt; ねえ Q! us-east-1 リージョンの 「demo-mrsc」という DynamoDB テーブル を、us-east-2 リージョンにまたがるマルチリージョン強整合性 (MRSC) 対応に更新し、us-west-2 リージョンにウィットネスを構成します その後すぐに、Q CLI は次のコマンドを返してきます。 &gt; マルチリージョン強整合性を有効にするには、適切なパラメータを指定して、update-table コマンドを使用して DynamoDB テーブルを更新する必要があります。以下のように実行します: aws dynamodb update-table \ --table-name demo-mrsc \ --replica-updates '[{"Create": {"RegionName": "us-east-2"}}]' \ --global-table-witness-updates '[{"Create": {"RegionName": "us-west-2"}}]' \ --multi-region-consistency STRONG \ --region us-east-1 処理が完了したら、MRSC グローバルテーブルのステータスを確認できます。DynamoDB グローバルテーブルに ウィットネス が設定されていることを確認できます。ウィットネスは、マルチリージョン強整合性による高い耐障害性を維持しつつ、コストを削減します。 次に、アプリケーション内で ConsistentRead を使用することで、強整合性を持ってデータを読み取ることができます。以下は Python の例です: import boto3 # 使用するリージョンに合わせて DynamoDB クライアントを設定する dynamodb = boto3.resource('dynamodb', region_name='us-east-2') table = dynamodb.Table('demo-mrsc') pk_id = "demo#test123" # リージョン間で強整合性を保った読む response = table.get_item( Key={ 'PK': pk_id }, ConsistentRead=True ) print(response) 最も強力なレジリエンスを必要とするオペレーションには、 ConsistentRead=True を使用できます。最終的な整合性で問題ないような重要度の低い処理では、このパラメータを省略することで、パフォーマンスの向上とコストの削減が期待できます。 知っておくべき追加情報 以下の点にご注意ください: 可用性 — Amazon DynamoDB のマルチリージョン強整合性機能は、以下の AWS リージョンで利用できます: 米国東部 (オハイオ、バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (大阪、ソウル、東京)、ヨーロッパ (フランクフルト、アイルランド、ロンドン、パリ) 価格設定 — マルチリージョン強整合性の料金は、既存のグローバルテーブルの料金体系に従います。DynamoDB は最近、グローバルテーブルの料金を最大 67% 削減し、これまで以上に高耐障害性のアーキテクチャを手頃な価格で利用できるようになりました。詳しくは、AWS Database Blog の Amazon DynamoDB がオンデマンドスループットとグローバルテーブルの料金を引き下げ の記事をご覧ください。 アプリケーションの最高レベルの耐障害性を実現し、どのリージョンにおいても常に最新のデータを読み取れる、常時稼働のアプリケーションを構築する方法については、 Amazon DynamoDB グローバルテーブル のページをご覧ください。 開発をお楽しみください! — Donnie 原文は こちら です。

6 月 30 日、 AWS Graviton4 プロセッサと最新の第 6 世代 AWS Nitro Card を搭載した Amazon Elastic Compute Cloud (Amazon EC2) C8gn ネットワーク最適化インスタンスの一般提供が発表されました。EC2 C8gn インスタンスは最大 600 Gbps のネットワーク帯域幅を提供します。これは、EC2 ネットワーク最適化インスタンスの中でも最高レベルの帯域幅です。 C8gn インスタンスは、セキュリティおよびネットワーク仮想アプライアンス (仮想ファイアウォール、ルーター、ロードバランサー、プロキシサーバー、DDoS アプライアンス)、データ分析、密結合クラスターコンピューティングジョブなど、要求が最も厳しいネットワーク集約型ワークロードを実行するために使用できます。 EC2 C8gn インスタンスの仕様 C8gn インスタンスは、最大 192 個の vCPU と 384 GiB のメモリを提供し、Graviton3 ベースの EC2 C7gn インスタンス よりも最大 30% 優れたコンピューティングパフォーマンスを実現します。 C8gn インスタンスの仕様は次のとおりです。 インスタンス名 vCPU 数 メモリ (GiB) ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) c8gn.medium 1 2 最大 25 最大 10 c8gn.large 2 4 最大 30 最大 10 c8gn.xlarge 4 8 最大 40 最大 10 c8gn.2xlarge 8 16 最大 50 最大 10 c8gn.4xlarge 16 32 50 10 c8gn.8xlarge 32 64 100 20 c8gn.12xlarge 48 96 150 30 c8gn.16xlarge 64 128 200 40 c8gn.24xlarge 96 192 300 60 c8gn.metal-24xl 96 192 300 60 c8gn.48xlarge 192 384 600 60 c8gn.metal-48xl 192 384 600 60 C8gn インスタンスは、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI)、または AWS SDK を使用して起動できます。 現在 C7gn インスタンスを使用している場合は、新しい C8gn インスタンスでも同様の vCPU/メモリ比率が提供されるため、ネットワーク集約型ワークロードの C8gn インスタンスへの移行を簡単に行えます。詳細については、一連の Graviton リソース をご覧ください。これらは、Graviton インスタンスタイプへのアプリケーションの移行を開始するために役立ちます。 また、「 Level up your compute with AWS Graviton 」ページにアクセスして、Graviton 導入ジャーニーを開始することもできます。 今すぐご利用いただけます Amazon EC2 C8gn インスタンスは、本日から米国東部 (バージニア北部) リージョンと米国西部 (オレゴン) リージョンでご利用いただけます。2 つのメタルインスタンスサイズが提供されるのは、米国東部 (バージニア北部) リージョンのみです。これらのインスタンスは、 オンデマンド 、 Savings Plans 、 スポットインスタンス 、または ハードウェア専有インスタンス および 専有ホスト として購入できます。 Amazon EC2 コンソール で C8gn インスタンスをぜひお試しください。詳細については、「 Amazon EC2 C8g Instances 」ページをご確認ください。ご意見やご要望がありましたら、 EC2 の AWS re:Post 、または通常の AWS サポート窓口までお寄せください。 – Channy 原文は こちら です。

本ブログはユーザックシステム株式会社様と Amazon Web Services Japan 合同会社が共同で執筆いたしました。 みなさん、こんにちは。AWS アカウントマネージャーの藤川です 。 昨今、多くのお客様から生成 AI の活用についてご相談いただくようになりました。ISV(独立系ソフトウェアベンダー)/SaaS業界のお客様においても、生成 AI を活用した新しい製品・サービス開発の取り組みが増えてきています。 企業の業務プロセスの自動化・効率化を支援するユーザックシステム株式会社様（以下、ユーザックシステム様）は、 Amazon Bedrock を活用し、従来は自動化が困難であった非定型の受注業務に生成AI を活用することによって自動化に成功しました。本記事では、生成AIを活用した受注業務における効率化の取り組みについてご紹介します。 お客様の状況と検証に至る経緯 ユーザックシステム様は、20年以上にわたり受注業務の効率化に取り組んできました。同社のRPA(Robotic Process Automation)ソリューション「Auto ジョブ名人」により、定型的な業務の自動化は着実に進展していました。 しかし、「得意先や担当者ごとに対応が異なる」「処理に人の判断が必要」といった非定型業務は、依然として人手に依存せざるを得ない状況が続いていました。特に食品卸業界では、FAXやメールでの注文書のやり取りが主流であり、これらを確認して社内システムに入力する作業に多大な工数を要していました。 また、取引先や社内システムごとに独自のルールが存在するため、受注担当者が一人前になるまでに約1年の経験が必要でした。さらに「昨今の人手不足も相まって、受注業務における生産性向上は喫緊の課題となっていました」とユーザックシステム様は当時を振り返ります。 ソリューション／構成 この課題を解決するため、ユーザックシステム様は「Knowfa 受注AIエージェント」の開発に着手しました。このシステムは、生成AIとRPAを組み合わせることで、非定型の受注業務の完全自動化を目指すソリューションです。(プレスリリースは こちら ) システムの処理フローは以下の通りです。 注文担当者が、お客様からのFAX や電子メールで届いた注文書の画像をシステムに登録する システムが注文書の画像を分析し、文字や数字を自動的に読み取る (例：商品名、個数、お客様情報など) システムは読み取った情報を使って、過去の注文データベースから類似の注文内容を探し出す(例：同じお客様の過去の注文や、似た商品の注文履歴など) システムは 2 で読み取った注文内容と 3 の過去のデータを照らし合わせて、注文内容を判断する (例：商品コード、注文数の確認など) 導入効果 Knowfa 受注AIエージェントの導入により、以下のような顕著な効果が得られました。 AIエージェントが判断業務を担い、人はチェック業務だけに専念する役割分担を確立。これまでRPAで対応できなかった受注業務の80%自動化に成功。 Amazon Bedrockのセキュリティや信頼性により、気密性の高いデータを扱うエンドユーザーにとって安心材料に。 また「AWSのサーバーレスアーキテクチャとマネージドサービスの活用により、エンジニア3名とプロジェクトマネージャー1名という少人数体制でも、約4ヶ月という短期間でβ版開発を実現できました」と、技術面でのメリットを説明します。 今後の展望 今後の展開について、ユーザックシステム様は次のように意欲を示しています。 「現在はFAX注文書を中心に対応していますが、今後はメールやその他の受注業務への展開も計画しています。Amazon Bedrock エージェントを活用し、AIエージェントの自律性を高めながら、対応可能な業務の範囲を拡大していきたいと考えています」 ユーザックシステム株式会社 : 上野 真裕様（中央） Amazon Web Services Japan : アカウントマネージャー 藤川 高志朗（左端）、ソリューションアーキテクト 呉 敏禎（右端）

みなさん、こんにちは！製造業のお客様を中心に技術支援を行っているソリューションアーキテクトの山田です。 AWS Summit Japan 2025 が開催され、製品設計・エンジニアリング分野の展示「CAD や CAE で使用するデスクトップワークステーション環境をクラウド化して最適化〜Research and Engineering Studio on AWS〜」において、多くの関心をいただきました！ 今回の展示では、 Research and Engineering Studio on AWS (RES) による CAD（コンピューター支援設計）/CAE（コンピュータ支援エンジニアリング） 環境のクラウド化と、その環境上で Amazon Q Developer を活用した CAE アプリケーションによる流体解析のデモを実施いたしました。従来の製品設計・CAE 解析プロセスがどのように効率化されるのかをご紹介します。 従来の課題と RES による解決 研究・開発環境の課題 研究とエンジニアリングにおけるイノベーションの阻害要因として以下のような例が挙げられます。 海外の設計チームとデータ共有や打ち合わせが難しく、各拠点でバラバラに作業することになり、同じような問題を何度も解決する無駄が発生する ワークステーションの設定やソフトウェアのインストール、ライセンス管理などに時間を取られ、本来の設計・解析業務に集中できない 手持ちのワークステーションでは大規模な CFD（計算流体力学）解析ができず、「もっと高性能なコンピューティングリソースが欲しい」と思っても簡単には増強できない Research and Engineering Studio on AWS (RES) とは RES は、研究開発チームがクラウドの専門知識を必要とせずに研究者とエンジニアがワークロードを実行できる環境を管理および構築するためのオープンソースの使いやすいウェブベースのポータルです。 図1 RESアーキテクチャ 管理者にとってのメリット インストール、設定、管理が楽になる ハードウェア調達を待つ必要なし、数分で環境構築完了 各拠点への CAD 環境配布も仮想環境で一括管理（図2） 仮想環境により設計拠点に捉われずに CAD 環境の展開やバージョンアップなどのメンテナンスも容易 プロジェクト全体の AWS 使用状況とコストを一元的に監視・管理（図3） 既存の ID 認証システム（ AWS マネージド AD サービス ）と統合でき、セキュリティとガバナンスを一元管理 エンドユーザーにとってのメリット Web ポータルにログインしてタスクに集中できる 最適なコンピュータ環境を使用することで開発の時間を短縮（図4） AWS リソースの管理を習熟する必要は無い 自宅でも出張先でも、どこからでも同じ環境にアクセス可能 大規模解析の時だけ高性能 GPU、普段は低コスト環境で無駄なし 共有データにアクセスできる環境でチーム間の共同作業が可能 図2 Virtual Desktops 図3 Virtual Desktop Dashboard 図4 選択できる高性能な仮想サーバ(Amazon EC2 インスタンス)一例 RES の使用開始方法 GitHub のAmazon Web Servicesリポジトリ にホストされている RES ソースコードをダウンロードします。 RESの起源となる事例 – Amazon Lab126の事例 – Amazon Lab126 は、カリフォルニア州サニーベールに拠点を置く、 Amazon の研究所です。このラボには Amazon Devices のハードウェア、ソフトウェア、運用チームが含まれており、Amazon Echo や Amazon Kindle など 知名度の高い製品を開発しています。 Amazon Lab126 では、老朽化した、コストのかかるオンプレミスの CAE 環境を使用していました。そのためエンジニアリングチームが必要とするスケーラビリティと使いやすさを提供できませんでした。 AWS ベースの CAE 機能を有効にするために、Amazon Lab126 は、最も多くの I/O 集中型ワークロード向けに Amazon FSx for Lustre を使用しました。また、 AWS Backup を使用してクラスターの耐障害性を高める新しいスケールアウトコンピューティングフレームワークを作成しました。 これにより、CAE ジョブの実行を3倍高速化し、新規ユーザーを数週間ではなく1日足らずでオンボーディングすることが可能になりました。必要に応じて新しい CAE クラスターを起動でき、製品設計の革新を推進することができました。 デモ：RES 環境での Amazon Q Developer を活用したCFD（計算流体力学）解析業務支援 アーキテクチャ 図5 RES 環境での Amazon Q Developer を活用した CFD 解析 アーキテクチャ 想定ユーザー例：若手エンジニア 想定ユーザープロファイル ： 学歴・基礎知識：機械工学科卒業、CFD 理論は学習済み 実務経験：CAD 基本操作可能（FreeCAD 等）、流体力学基礎知識あり プログラミング：Python 基礎レベル CFD 経験：学生時代に OpenFOAM を少し触った程度 課題 ： 学生時代の簡単な CFD と実務レベルのギャップが大きい 多機能・高機能な CAE ソフトは使い方がよくわからない 上司から「バイクフレームの空力解析やって」と言われたが、実務経験なし 社内に CFD 専門家がいない（または忙しくて教えてもらえない） Amazon Q Developer による設計プラン作成 Amazon Q Developer（生成 AI 会話アシスタント）とのチャットやり取りで設計目標等を相談し、設計プランドキュメントを作成してもらいます。 図6 バイクフレーム CFD 解析 設計プランドキュメント例 Amazon Bedrock Knowledge Bases による RAG 活用 市販 CAE アプリケーションのユーザーガイドは web で一般公開されているケースが少なく、ソフト購入者のみが見れるケースが一般的です。従って生成 AI モデルで十分に学習済みではないため、Amazon Q Developer が自律的に判断して Amazon Bedrock Knowledge Bases で必要な CAE アプリケーションのマニュアルもしくはドキュメントを RAG（検索拡張生成） 検索して操作ガイドや解析自動実行 Java マクロファイルなどを作成してユーザーに提示します。 2 つの利用方法 1. GUI 操作ガイド CAE アプリケーションの GUI 画面で操作を行っていきたい場合は、Amazon Q Developer が生成した詳細な操作ガイドに従って操作していきます。 図7 バイクフレーム CFD 解析 CAE アプリケーション GUI 操作ガイド例 2. Java マクロ自動実行 CAE でユーザーサブルーチンでカスタマイズしたり自動化するなどの目的でコードを書く必要がある場合（マクロ機能の実行イメージの場合）には、Amazon Q Developper にコードを生成させて利用するようなユースケース（マクロファイルの実行ボタンを押すだけで自動解析実行が行われるイメージ）も考えられます。 図8 バイクフレーム CFD 解析 CAE 自動化コード例 赤字で示された箇所のような、パラメータの数値を変更するだけで様々なバリエーションの解析が自動実行できます。 図9 バイクフレーム CFD 解析 メッシュ分割、流速分布図 CAE アプリケーションを実行時に、ハイスペックな EC2 インスタンスに変更して処理することで、シミュレーション時間を大幅に短縮できます。 RES と同じ AWS 上に構成した HPC （ハイパフォーマンスコンピューティング） クラスタで処理させて、これまで実現できなかった大規模で高精度な解析にチャレンジすることも可能です。 図10 並列処理による解析時間の変化 まとめ AWS Summit Japan 2025 の展示「CAD や CAE で使用するデスクトップワークステーション環境をクラウド化して最適化〜Research and Engineering Studio on AWS〜」では、RES による CAD/CAE 環境のクラウド化と、Amazon Q Developer を活用した CFD（計算流体力学）解析業務支援のデモを通じて、製品設計・エンジニアリング分野における以下のような革新的な変化を実現できることを示しました。 技術面での革新 専門知識の民主化 : 若手エンジニアでも高度な CFD 解析を実行可能 学習コストの削減 : 生成 AI による対話的な学習とガイダンス 自動化の推進 : Java マクロによる解析プロセスの自動化 運用面での改善 迅速な環境構築 : 数分でのワークステーション起動 柔軟なリソース管理 : 需要に応じたスケーリング コスト最適化 : 使用量ベースの課金とリソース管理 組織面での効果 グローバルコラボレーション : 地理的制約を超えた共同作業 知識の共有 : チーム間での専門知識の共有促進 イノベーションの加速 : 技術的制約の解消による創造性の向上 AWS の様々なサービスと組み合わせてどんどん機能拡張させていくことが可能ですが、まずは初めの一歩として、RES 環境での Amazon Q Developer 活用による製品設計・エンジニアリング分野でのデジタルトランスフォーメーションを推進し、競争力の向上を実現していきましょう。 著者プロフィール 山田 航司 (Koji Yamada) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 製造業のお客様を中心にクラウド活用の技術支援を担当しています。好きな AWS のサービスは Amazon Bedrock です。 愛読書は「大富豪トランプのでっかく考えて、でっかく儲けろ」です。

私がシアトルを訪れるたびに空港で最初に出迎えてくれるのは、 レーニア山 です。 Amazon Web Services (AWS) で最も革新的なプロジェクトがこの山にちなんで名付けられていることをご存知でしたか? Project Rainier は、米国内の複数のデータセンターで AI モデルをトレーニングするために、世界で最も強力なものとなることが期待されるコンピュータを作成する新しいプロジェクトです。Anthropic は、現在最も大規模なトレーニングクラスターの 5 倍の計算能力を備える高度な Claude モデル バージョンを開発する予定です。 Project Rainier を支える主要テクノロジーは、 AWS がカスタム設計した Trainium2 チップ です。このチップは、複雑な AI モデルのトレーニングに必要となる膨大なデータ処理に特化しています。大規模なシステム全体での超高速な通信とデータ共有を可能にする、新しいタイプの Amazon EC2 UltraServer と EC2 UltraCluster のアーキテクチャ内で、何千個もの Trainium2 チップが接続されることになります。 チップからソフトウェアに及ぶテクノロジースタックのあらゆるコンポーネントを設計し、最大限の効率性と信頼性のためにシステム全体を最適化することを可能にする、 Project Rainer での AWS の垂直統合 に関する詳細をご覧ください。 6 月 23 日週のリリース 私が注目したリリースをいくつかご紹介します。 Amazon FSx for OpenZFS のための Amazon S3 アクセス – Amazon S3 Access Points を通じて FSx for OpenZFS ファイルデータにアクセスし、分析することができます。このため、ファイルシステムからデータを移動しなくても、AWS の AI/ML サービスや分析サービスとシームレスに統合できるようになります。FSx for OpenZFS データを S3 に保存されているかのように扱うことができるため、Amazon Bedrock、Amazon SageMaker、AWS Glue や、その他の S3 ベースのクラウドネイティブアプリケーションを含めたさまざまなアプリケーションのために S3 API 経由でデータにアクセスすることが可能になります。 Amazon S3 の Apache Iceberg テーブル向けの sort および z-order コンパクション – 新しい sort および z-order コンパクションを使用して、クエリパフォーマンスの向上とコスト削減を実現できます。S3 Tables では、sort コンパクションが定義された列順序に基づいてデータファイルを自動的に整理し、z-order コンパクションは効率的な複数列のクエリのためにメンテナンス API 経由で有効化できます。 Amazon CloudWatch 調査 – 異常の特定、関連するシグナルの表面化、および修復手順の提案に役立つ Amazon CloudWatch の AI 駆動の調査機能を使用することで、AWS 環境内での運用上のトラブルシューティングを迅速化することができます。この機能は、CloudWatch データウィジェット、複数の AWS コンソール、CloudWatch アラームアクション、または Amazon Q チャットを通じて開始でき、チームコラボレーションと Slack や Microsoft Teams との統合を可能にします。 Amazon Bedrock ガードレールの Standard ティア – 新しい Standard ティアを使用することで、AI コンテンツの安全対策を強化できます。このティアは、最大 60 の言語全体でのコンテンツフィルタリング機能とトピック拒否機能の改善、誤字等の表記ゆれ検出の向上、プロンプト攻撃に対する保護の強化を実現します。この機能では、有害コンテンツのブロック、モデルハルシネーションの防止、個人を特定できる情報 (PII) のリダクション、自動推論チェックによる事実に基づく主張の検証を行うためのセーフガードを設定できます。 プライベートホストゾーン向けの Amazon Route 53 Resolver エンドポイント – プライベートホストゾーンのサブドメイン向けの新しい Route 53 DNS 委任機能を使用することで、AWS とオンプレミスインフラストラクチャ全体での DNS 管理を簡素化できます。この機能は、インバウンドとアウトバウンド両方の Resolver エンドポイントで活用できます。ネームサーバーレコードを使用してオンプレミスインフラストラクチャと Route 53 Resolver クラウドサービス間でサブドメイン権限を委任できるため、複雑な条件付き転送ルールが不要になります。 Java 変換向けの Amazon Q Developer CLI – 新しい Amazon Q Developer Java 変換コマンドラインインターフェイス (CLI) を使用して、Java アプリケーションのアップグレードを自動化し、スケールすることができます。この機能は、Java バージョン 8、11、17、または 21 からバージョン 17 または 21 へのアップグレードをコマンドラインから直接実行します。このツールは選択的な変換オプションを提供するため、変換計画から特定のステップを選択し、ライブラリのアップグレードをカスタマイズすることができます。 新しい AWS IoT Device Management マネージド統合 – 新しいマネージド統合機能を使用することで、複数のメーカーやプロトコル全体でのモノのインターネット (IoT) デバイス管理を簡素化できます。この機能は、デバイスが直接接続するか、ハブまたはサードパーティークラウド経由で接続するかにかかわらず、それらデバイスを制御するための統合インターフェイスを提供します。この機能には、事前構築された Cloud-to-Cloud (C2C) コネクタ、デバイスデータモデルテンプレート、および ZigBee、Z-Wave、Wi-Fi プロトコルをサポートする SDK が含まれていますが、カスタムコネクタやデータモデルを作成することも可能です。 AWS のお知らせに関する詳細なリストについては、「 AWS の最新情報 」ページをご覧ください。 AWS のその他のニュース AWS サービス用のさまざまな Model Context Protocol (MCP) サーバー がリリースされました。皆さんが関心を持つと思われる MCP サーバー関連のチュートリアルをいくつかご紹介します。 AWS costs estimation using Amazon Q CLI and AWS Cost Analysis MCP – Amazon Q CLI と AWS Cost Analysis MCP サーバーを併用することで、AWS ベストプラクティスに従う高度なコスト分析を実行できます。詳しい例とステップバイステップの手順を使用して、基本的な設定と高度なテクニックを説明します。 Supercharging AWS database development with AWS MCP servers – MCP の背後にある中核的概念について学び、新しい AWS MCP サーバーが自然言語プロンプトを通じてデータベース開発を加速する方法を実証できます。 Create your own MCP server with C# and .NET with Amazob Q CLI – Amazon Q CLI を MCP クライアントとして使用して、C# MCP サーバーを構築し、テストするためのローカル開発環境を設定することで、AI 駆動のアプリケーションを作成、反復、改善する能力を強化します。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS re:Invent – 今すぐ登録して、一足先に最適な学習パスを選択し、移動手段と宿泊先を予約して、皆さんのチームとともに学び、つながり、楽しみましょう。若手のプロフェッショナルならば、 All Builders Welcome Grant プログラム に申し込むこともできます。このプログラムは、経済的な障壁を取り除き、クラウドテクノロジーへの多様な道のりを創り出すように設計されています。 AWS NY Summit – コンピューティング、ストレージ、生成 AI における最新かつ最新鋭の AWS テクノロジーに焦点を当てた Swami の基調講演からインサイトを得ることができます。ニュースブログチームもエキサイティングなニュースをいくつか用意しています。直接参加できない場合でも、 グローバルライブストリームに登録 して参加することが可能です。また、最寄りの都市で 7 月と 8 月に開催される予定の Summit の日付も確認しておきましょう。 AWS Builders Online Series – 太平洋時間帯の地域を拠点としているならば、AWS でワークロードを構築、移行、デプロイするために役立つ基本的な AWS 概念やアーキテクチャ上のベストプラクティスを学び、実践的なデモに参加することができます。 近日開催されるすべての対面イベントと仮想イベント をご覧いただけます。 6 月 30 日週のニュースは以上です。7 月 7 日週の Weekly Roundup もお楽しみに! – Channy 原文は こちら です。

6 月 25 日より、 Amazon S3 Access Points を Amazon FSx for OpenZFS ファイルシステムにアタッチして、 Amazon Simple Storage Service (Amazon S3) に格納されているかのようにデータにアクセスできるようになりました。この新機能を使用すると、S3 と連動する Amazon Web Services (AWS) の幅広い 人工知能 (AI)、 機械学習 (ML)、 分析 サービスやアプリケーションで使用するデータとして FSx for OpenZFS 内のデータにアクセスできます。ファイルデータは引き続き FSx for OpenZFS ファイルシステムに格納されます。 組織は数百エクサバイトのファイルデータをオンプレミスで保存しており、このデータを AWS に移動して、優れた俊敏性、信頼性、セキュリティ、スケーラビリティを実現し、コストを削減したいと考えています。ファイルデータの AWS への移動後に、組織がそのデータをさらに活用したいと考えるのはめずらしいことではありません。例えば、多種多様な AWS 生成 AI サービスと機械学習サービス を使用して、エンタープライスデータで 生成 AI アプリケーションを強化したり、機械学習モデルをトレーニングしたりすることを考えます。また、新しい AWS アプリケーションで独自のファイルデータを使用する柔軟性も求めています。ところが、AWS データ分析サービスとアプリケーションの多くは、Amazon S3 に保存されたデータをデータレイクとして使用するように構築されており、移行した後で Amazon S3 と連動するツールをデータソースとして使用できます。これまで、これには Amazon FSx for OpenZFS ファイルシステムと Amazon S3 バケット間でデータをコピーするためのデータパイプラインが必要でした。 FSx for OpenZFS ファイルシステムに Amazon S3 Access Points をアタッチすると、ファイルプロトコルと Amazon S3 API 操作の両方を経由する統合アクセスが維持され、データの移動やコピーが必要なくなります。 GetObject 、 PutObject 、 ListObjectsV2 などの S3 オブジェクト操作を使用したファイルデータの読み取りや書き込みが行えます。1 つのファイルシステムに数百個の S3 Access Point をアタッチでき、各 Access Point にはアプリケーション固有の許可を設定できます。これらの S3 Access Point は、S3 バケットにアタッチされる S3 のアクセスポイントと同様のきめ細かなアクセス許可コントロールをサポートします。これには、 AWS Identity and Access Management (IAM) アクセスポイントポリシー や パブリックアクセスブロック のほか、 仮想プライベートクラウド (VPC) へのアクセスを制限するなどのネットワークオリジンコントロールが含まれます。データはそのまま FSx for OpenZFS ファイルシステムに格納されるため、引き続き ネットワークファイルシステム (NFS) を使用してデータにアクセスし、既存のデータ管理機能からメリットを得ることができます。 S3 API を使用することで、データが S3 に格納されているかのように Amazon FSx for OpenZFS ファイルシステム内のファイルデータを使用して、 検索拡張生成 (RAG) ワークフローのために Amazon Bedrock で生成 AI アプリケーションを強化し、 Amazon SageMaker で ML モデルをトレーニングして、 Amazon Athena &nbsp;と AWS Glue で分析や ビジネスインテリジェンス (BI) を実行できます。また、データを移動したりリファクタリングしたりすることなく、 Apache Spark や Apache Hive などのオープンソースツールを使用してインサイトを生成することも可能です。 始めましょう S3 Access Point は、 Amazon FSx コンソール 、 AWS コマンドラインインターフェイス (AWS CLI) 、または AWS SDK を使用して作成し、Amazon FSx for OpenZFS にアタッチできます。 まず、 Amazon FSx for OpenZFS ファイルシステムのドキュメントページ にある手順に従ってファイルシステムを作成します。次に、Amazon FSx コンソールで [アクション] に移動し、 [S3 Access Point を作成] を選択します。&nbsp;標準設定をそのまま変更せずに作成します。 作成の進行状況は、Amazon FSx コンソールで監視できます。 利用可能になったら、新しい S3 Access Point の名前を選択し、Access Point の概要を確認します。概要には自動生成されたエイリアスが含まれています。このエイリアスは、通常 S3 バケット名を使用する場所ならどこでも機能します。 バケットスタイルのエイリアスを使用すると、S3 API 操作経由で FSx データに直接アクセスできます。 ListObjectsV2 API を使用してオブジェクトを一覧表示する GetObject API を使用してファイルを取得する PutObject API を使用してデータを書き込む データには引き続き NFS 経由でアクセスできます。 S3 API 経由で FSx データにアクセスする以外にも、S3 内のデータを処理する幅広い AI、ML、分析サービスを使用してデータを活用できます。私の例を挙げると、私の旅行サポートアプリケーションリポジトリである WhatsApp-Powered RAG Travel Support Agent: Elevating Customer Experience with PostgreSQL Knowledge Retrieval から取得した 航空会社のカスタマーサービス情報が含まれる PDF をデータソースとして使用して、 Amazon Bedrock のナレッジベース を作成しました。 Amazon Bedrock のナレッジベースを作成するため、「 ナレッジベースの Amazon S3 に接続する 」ユーザーガイドの接続ステップを実行しました。データソースとして Amazon S3 を選択し、S3 ソースとして S3 Access Point エイリアスを入力してから、ナレッジベースを設定して作成しました。 ナレッジベースが同期されるとすべてのドキュメントが表示され、 ドキュメントソース が S3 になっていることがわかります。 最後に、ナレッジベースに対してクエリを実行し、コンテキストに即した回答を提供するために Amazon FSx for OpenZFS ファイルシステムのファイルデータが正常に使用されたことを確認しました。そうすることで、データの移動を必要としないシームレスな統合が行われたことがわかります。 知っておくべきこと 統合とアクセスコントロール – Amazon FSx for OpenZFS ファイルシステム向けの Amazon S3 Access Points は、S3 エンドポイント経由での標準 S3 API 操作 (GetObject、ListObjectsV2、PutObject など) をサポートし、AWS Identity and Access Management (IAM) の許可とファイルシステムユーザー認証によるきめ細かなアクセスコントロールを使用します。S3 Access Point には、S3 バケット名を使用してデータにアクセスするための自動生成された Access Point エイリアスが含まれています。Amazon FSx リソースへのパブリックアクセスはデフォルトでブロックされます。 データ管理 – データは Amazon FSx for OpenZFS ファイルシステムに留まるものの、Amazon S3 内にあるかのようにアクセスできるため、データを移動またはコピーする必要がなくなります。ファイルデータは引き続き NFS ファイルプロトコル経由でアクセスできます。 パフォーマンス – Amazon FSx for OpenZFS ファイルシステム向けの Amazon S3 Access Points は、S3 バケットアクセスと同様に、数十ミリ秒範囲のファーストバイトレイテンシーを実現します。パフォーマンスは Amazon FSx ファイルシステムのプロビジョンドスループットに合わせてスケールし、最大スループットは基盤となる FSx ファイルシステムの設定に基づいて判断されます。 料金 – Amazon FSx の標準料金に加えて、S3 Access Points 経由のリクエストとデータ転送に対する Amazon S3 料金が請求されます。詳細については、「 Amazon FSx for OpenZFS の料金 」ページをご覧ください。 Amazon FSx for OpenZFS システムへの Amazon S3 Access Points のアタッチは、Amazon FSx コンソール、AWS CLI、または AWS SDK を使用して今すぐ開始できます。この機能は、米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン)、欧州 (フランクフルト、アイルランド、ストックホルム)、およびアジアパシフィック (香港、シンガポール、シドニー、東京) の各 AWS リージョン でご利用いただけます。 –&nbsp; Eli 原文は こちら です。

本ブログは 2025 年 6 月 17 日に公開された Amazon News “ AWS rolls out 3 key security capabilities at re:Inforce, helping customers simplify and scale ” を翻訳したものです。 新しいツールにより、お客様はデジタル資産をより適切に保護できるようになります。また、重要なセキュリティ問題の特定し、サイバー攻撃から防御するなど、さまざまな対策が可能になります。 重要なポイント AWS は生成 AI 時代の新たな脅威に対応するため、3 つの強化されたセキュリティサービスを導入します AWS Security Hub は、チームが重要な問題を一元的に特定し対処するのに役立ちます AWS Shield の新しいプロアクティブなネットワークセキュリティ分析により、攻撃者に悪用される前にセキュリティギャップを発見して修正することが容易になります Amazon GuardDuty は、拡張脅威検出機能をコンテナベースの環境にも拡張し、検出されにくい複雑な攻撃パターンを特定します Amazon Web Services (AWS) は 2025 年 6 月 16 日 〜 18 日に、米国ペンシルベニア州フィラデルフィアで開催された AWS re:Inforce において、あらゆる規模のお客様がデジタル防御を強化するための新しいセキュリティ機能群を発表しました。 AWS の年次クラウドセキュリティカンファレンスである AWS re:Inforce では、世界中のセキュリティ専門家、パートナー、ビルダーが集まり、生成 AI 時代における新たなセキュリティ課題への対応について議論を交わしています。 組織がますます高度化するサイバー脅威に直面する中、AWS は本日 (2025 年 6 月 17 日) に、セキュリティ管理を簡素化しながらより包括的な保護を提供することを目的とした 12 の新機能を発表しました。以下はその主要な 3 つのサービスです。 AWS Security Hub：システムへのアクティブな脅威を迅速に特定し優先順位付けするためのサポート AWS Security Hub は、お客様が最も重要なセキュリティ問題を特定し、迅速に対応してリスクを軽減するのに役立ちます。これは「セキュリティコマンドセンター」のような役割を果たし、異なるタイプのセキュリティアラートと脆弱性の間の関連性を明らかにします。これにより、セキュリティチームはクラウドシステムへのアクティブな脅威を迅速に特定し、優先順位を付けることができます。すべての情報を一箇所にまとめることで、Security Hub は組織のセキュリティ状態をより明確に把握できるようにし、複数のセキュリティツールから手動で情報を収集する必要性を取り除きます。AWS Security Hub は本日から AWS のお客様向けにプレビュー版として利用可能です。 AWS Shield：お客様のオンラインシステムを事前に保護 AWS Shield は、ネットワークセキュリティの設定ミスや弱点を事前に発見することで、ウェブサイトやオンラインアプリケーションの保護方法を強化しています。このサービスは、お客様のセキュリティリソースのマップを作成し、SQL インジェクション (ハッカーがウェブサイトフォームを通じてデータにアクセスしようとする攻撃) や分散型サービス拒否 (DDoS) 攻撃 (攻撃者が偽のトラフィックでウェブサイトを過負荷にしてクラッシュさせる攻撃) などの一般的な攻撃に対する脆弱性を特定します。AWS Shield は、重要度別に問題を強調表示するわかりやすいダッシュボードと、問題を迅速に修正するためのステップバイステップの手順を提供します。お客様は、最も高性能な生成 AI を搭載した業務用アシスタントである Amazon Q を使用して、複雑なセキュリティ設定をナビゲートする代わりに、簡単な会話を通じてガイダンスを得ることもできます。 Amazon GuardDuty：コンテナベースのアプリケーション向け拡張脅威検出の提供 AWS は Amazon GuardDuty 拡張脅威検出の機能拡張を発表し、Amazon Elastic Kubernetes Service (Amazon EKS) で実行されるコンテナベースのアプリケーションを保護できるようになりました。GuardDuty はお客様のシステム全体のさまざまなセキュリティシグナルを接続し、検出されにくい高度な攻撃パターンを検出します。EKS 監査ログ、ランタイム動作、AWS アクティビティを監視することで、GuardDuty は複雑な多段階攻撃を特定できます。これらの改善された検出機能により、セキュリティチームは潜在的な問題の調査に費やす時間を減らし、実際の脅威に対処する時間を増やすことができ、ビジネス運営への影響を軽減します。 セキュリティの課題が進化し続ける中、AWS はお客様が潜在的なリスクに先んじて対応できるよう取り組んでいます。例えば、AWS はすべてのタイプの AWS アカウントにおいて、すべてのルートユーザーに対して 100% の多要素認証を強制しています。本日発表された新しいセキュリティ機能により、お客様はより深い可視性を得て、セキュリティ運用を効率化し、クラウド環境をより効果的に保護することができます。 イノベーションを促進するセキュリティ機能を構築し、組織が迅速にスケールする自信を与えるガードレールを作成することで、AWS はお客様が少ない労力でより強固なセキュリティポスチャを構築できるよう支援し、より多くのリソースを成長に集中させることを可能にしています。 これらのセキュリティトピックと AWS re:Inforce で議論されている内容について詳しくは、リンク先をご覧ください。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

はじめに みなさんこんにちは。ソリューションアーキテクトの光吉です。2025 年 5 月 20 日にヘルスケア・ライフサイエンスと半導体業界のお客様を AWS にお招きして「ハイテク製造・ヘルスケア・ライフサイエンス業界向けセキュリティインシデント疑似体験 GameDay 」を開催しました。今回はそのイベントのご紹介や当日の雰囲気をお伝えし、セキュリティへの取り組みを知って頂ければ幸いです。 AWS GameDayとは AWS GameDay は、AWS ソリューションを利用してチーム単位で現実世界の技術課題を実際に体験し取り組む、AWSが提供するユニークなトレーニングプログラムですです。実践的なクラウドスキルを楽しみながら習得でき、特に今回のセキュリティインシデント疑似体験 GameDay はクラウドセキュリティに特化したプログラムとして評価いただいています。 このプログラムの特徴は、実際のAWS環境で発生しうるセキュリティインシデントをシミュレーションし、参加者がチームとなって対応するという点です。例えば、不正アクセスの検知、データ漏洩インシデントの調査、マルウェア感染への対処など、現実世界で直面する可能性のある様々なセキュリティ課題に取り組みます。 参加者は、Amazon GuardDuty、AWS CloudTrailといった実際のAWSセキュリティサービスのログを SIEM on Amazon OpenSearch Service というソリューションから確認し、インシデントの検知から対応までを体験します。このハンズオン形式の学習により、座学だけでは得られない実践的なスキルと経験を積むことができます。 この AWS GameDay の魅力の一つは、ゲーミフィケーションの要素を取り入れている点です。チーム間で競い合いながら学習を進めることで、参加者のモチベーションを高く保ちつつ、効果的な学習を実現しています。さらに、チームでの協力が必要となるため、組織内のコミュニケーション能力の向上にも役立ちます。 セキュリティインシデントへの対応は、実際に発生してから学ぶのでは遅すぎます。AWS GameDayは、安全な環境で事前に経験を積み、実際のインシデント発生時に適切に対応できる体制を整えるための貴重な機会となっています。多くの企業がクラウド環境でのビジネスを展開する現代において、このような実践的なセキュリティトレーニングの重要性は、ますます高まっているといえるでしょう。 AWS GameDay の流れ、イベントの様子 さて、今回は9社、57名の方々に参加いただきました。多くは情報システム部に所属する皆さまでセキュリティの意識も高く真剣に取り組んでいただいておりました。皆様は3から4名ごとにチームに分かれてインシデントが発生したというシナリオを元に実際の AWS 環境にログインいただき制限時間2時間の中で調査を行っていただきました。具体的には外部向け Web サービスを AWS で公開していたが脅威を検知したにもかかわらず原因がわからないというシナリオでゲームは進行します。 実際の AWS GameDay の様子 各チームの進行状況は得点として可視化されてリアルタイムに確認ができる 最終結果 – 優勝チームの紹介 ゲーム本編が終了いたしましたら結果発表となります。今回最も得点を獲得した優勝チームは第一三共株式会社の皆様（梅田 新さま、岡本 康希さま、髙市 伸宏さま、岡本 敦之さま）が率いるチームでした。おめでとうございました。 第一三共株式会社の皆様からはコメントを頂戴しています。 イベントに関するご感想 高度なログ解析を体験することができる、大変有意義で楽しいイベントでした！本物に近いインシデントのストーリーを通じて、ログや検知の重要性を真剣に学ぶことができました。 普段に行っていたセキュリティ設定やベストプラクティスの意味を、改めて深く理解することができました。 チームでの協力や、他チームとの競い合いを通じて、本当に楽しい切磋琢磨を体験することができました。また機会があればぜひ参加させていただきたいです！イベントの開催ありがとうございました！ 工夫された点 時間が限られていることから手分けして課題に取り組み、スタックした場合にはペアまたはモブで解決に当たりました。普段からモブで作業をしているチームワークが発揮できたと思います。 表彰の様子(おめでとうございます！) 解説とパートナーソリューションについて 表彰後、今回のシナリオで実際に何が起きていたのかを AWS から解説させていただきました。インシデントの検出にはまずは Amazon GuardDuty が効果的であり、根本原因と被害範囲の調査のためにはしっかりと必要なログを保管し、いつでも取得できるような状態にしておくことが肝要です。今回は AWS のサービスだけでインシデントの調査を行っていただきましたが、こういった実際に起きうるインシデントに対して有用なサービスは他にもあります。そこで今回は AWS のパートナーである3社にも登壇いただき、パートナーソリューションについても紹介いただく場を提供させていただきました。 Splunk 2003年の創業以来、Splunkは、お客様が組織内のデータの広大かつ深遠な迷宮を探索するお手伝いをしています。 Splunkが目指すのは、より安全でレジリエントなデジタル世界を創造することです。Splunkは、組織の運営と安全を支えるセキュリティ運用、IT運用、エンジニアリングの各チームを支援することで、この目標に着実に近づいています。現在、世界最大級の大規模かつ複雑な環境を運用する多くの組織が、ミッションクリティカルなシステムを保護するためにSplunkを活用しています。 サイバーセキュリティクラウド 株式会社サイバーセキュリティクラウドは、「世界中の人々が安心安全に使えるサイバー空間を創造する」をビジョンに掲げ、Webアプリケーションのセキュリティサービスや脆弱性管理、クラウドセキュリティに関するサービスを提供する、日本発のセキュリティメーカーです。当社が提供する『CloudFastener（クラウドファスナー）』は、AWSに対応したフルマネージド型のセキュリティサービスです。脅威検知、脆弱性管理、データ保護などの支援を、お客様の環境や組織体制に応じて柔軟に提供し、ガバナンス・ポリシーの策定から復旧・修正対応まで、AWS環境におけるセキュリティ運用をワンストップで包括的にサポートします。 KnowBe4 Know Be4は、世界で70,000社以上に採用されているセキュリティ意識向上トレーニングとフィッシング訓練のグローバルリーダーです。ヒューマンリスクマネジメントプラットフォーム（HRM+）は、従業員のセキュリティに関する人的な脆弱性と強みを可視化し、個別に最適化されたトレーニングを提供。これにより、効果的にセキュリティ意識を向上させ、行動変容を促します。 トレーニングコンテンツは34ヶ国語以上に対応。多様なビジネス環境に対応し、「人的」セキュリティを強化することで、強固なセキュリティ文化の構築を支援します。 GameDayの後 さて、それでは実際に運用しているサービスに今回の経験を活かしていただくにはどうすればよいでしょうか。 今回体験いただいた Amazon GuardDuty、AWS CloudTrail や SIEM on Amazon OpenSearch Service を導入するのも良さそうですし、紹介いただいたパートナーソリューションを導入したりといった施策を進めるのも良さそうです。ただ、現実のサービスはゲームの状況よりも複雑です。単にサービスやソリューションを導入するのではなく、運用しているサービスの現状を把握し、必要な手立てを認識する必要があります。 そこで AWS では AWS Well-Architected Framework (W-A) をご用意しています。W-A はAWSがクラウドを10年以上の運用してきた経験や数多くのお客様とのやりとりをもとに作りあげた クラウド設計・運用のベストプラクティス集です。優れた運用効率、セキュリティ、信頼性、パフォーマンス効率、コストの最適化、持続可能性という 6つの柱に基づいて設計されており、気になる要素だけ利用いただくことも可能です。今回であればセキュリティの柱を利用して、まずは運用しているサービスの状況把握をしてみるのはいかがでしょうか。 AWS ではこれからもヘルスケア・ライフサイエンス、そして半導体業界の皆さまに貢献できるよう、クラウド技術のご紹介や各種イベントを実施いたします。積極的に活用いただけますと幸いです。 このブログはアマゾン ウェブ サービス ジャパン合同会社のソリューションアーキテクト光吉 隆雄が執筆しました。

こんにちは。ソリューションアーキテクトの疋田です。 2025 年 5 月 14 日に「 Apache Iceberg on AWS ミートアップ ～話題のIcebergをAWSで徹底活用～ 」と題したイベントを開催しました。ご参加いただきました皆様には、改めて御礼申し上げます。 本セミナーでは、AWS における Iceberg の活用についてさまざまな角度からご紹介しました。Iceberg 活用の全体像に加えて、マネージドな Iceberg のストレージである Amazon S3 Tables Bucket 、既存データレイクからの移行における考え方、リアルタイムデータ処理を実現するストリーミングワークロードの実装方法、更には機械学習における活用まで、幅広いトピックをご紹介しました。本ブログでは、その内容を簡単にご紹介しつつ、発表資料を公開致します。 すでに Iceberg を活用されている方も、これからはじめる方も是非ご確認下さい！ セッションの紹介 Apache Iceberg on AWS アマゾン ウェブ サービス ジャパン合同会社 Principal Big Data Architect 関山 宜孝 資料ダウンロード 本セッションでは、Apache Iceberg の概要と主要なユースケース、AWS 上での利用方法についてご紹介しました。Iceberg は大規模なデータセットの分析に利用できるオープンテーブルフォーマットであり、様々な規模のデータを効率的かつ便利に扱う仕組みをもちます。異なるツール間を繋ぐ共通的なテーブル仕様としても機能し、幅広いユースケースに活用できます。AWS はオープンソースの Iceberg をより便利に利用するための仕組みをワンストップで提供しています。 Amazon Data Firehose や AWS Glue Zero-ETL によって、個別のデータパイプラインを実装しなくても様々なデータストアから Iceberg テーブルにデータを取り込むことができます。また、AWS Glue Data Catalog のテーブル最適化によりフルマネージドで Iceberg テーブルをメンテナンスすることができ、パフォーマンスとコストを継続的に最適化できます。AWS で Iceberg を活用することで、オープンソースの Iceberg を最大限活かしながら、データの取り込みやテーブルのメンテナンスをより簡単に実現できます。 Amazon S3 Tables – テーブルバケットと汎用バケット アマゾン ウェブ サービス ジャパン合同会社 Senior Storage Specialist Solutions Architect 焼尾 徹 資料ダウンロード 本セッションでは、AWS で Apache Iceberg を活用する際のストレージの選択肢である、 Amazon S3 Tables バケット と Amazon S3 汎用バケット について、汎用バケットの特徴を振り返りながら深掘りしました。S3 Tables は、表形式のデータに最適化された新しいバケットタイプで、Iceberg の仕組みをフルマネージドに提供します。S3 Tables によって、テーブルの内部的な仕組みを意識することなく、安全かつ効率的に Iceberg を利用できます。一方で、汎用バケット上での Iceberg の活用は歴史があり、カスタマイズ性が高く、Amazon S3 やIceberg の機能をフル活用できます。AWS では、それぞれのストレージをユースケースに応じて使い分けることができます。 Apache Iceberg 移行アプローチの勘所 アマゾン ウェブ サービス ジャパン合同会社 Analytics Specialist Solutions Architect 疋田 宗太郎 資料ダウンロード 本セッションでは、既存のデータレイクを Iceberg へ移行する際のアプローチについてご紹介しました。 Iceberg への移行を検討する際は、まず移行を通じて実現したい目的を確認し、それに基づいて移行後の構成を設計することが大切です。 Glue Data Calotag は Hive テーブルと Iceberg の両方を同時に管理できるため、全てのデータを一度に移行する必要はなく、移行の効果が大きいテーブルから段階的に実施できます。データパイプラインを Iceberg へ移行する際の対象は大きく分けてデータ取り込み / 変換ジョブ、テーブルデータ、コンシューマー側のツールの 3 つの要素が挙げられます。それぞれについて、データ規模、ファイル形式、更新頻度、移行方式、書き込み処理の扱い、移行前後のデータの検証、コストなどのポイントを抑えながら移行を計画していくことが重要です。 Apache IcebergとAWSで実現するストリーミングワークロード アマゾン ウェブ サービス ジャパン合同会社 Analytics Specialist Solutions Architect 深見 修平 資料ダウンロード 本セッションでは、Iceberg を活用したストリーミングワークロードに焦点を当てて AWS のサービスをどのように活用できるかご紹介しました。Iceberg のスキーマが柔軟に変更できる点や、データ品質を担保するための Write-Audit-Publish (WAP) の仕組み、Merge-on-Read (MOR) による性能最適化など、ストリーミングデータを扱うのに適した利用方法をご紹介しました。AWS での実装オプションとしては、 AWS Glue 上での Apache Spark Structured Streaming, Amazon Managed Service for Apache Flink 上での Apache Flink など多様な連携方法が利用できます。特に、Amazon Data Firehose は幅広いデータソースから Iceberg テーブルへのマネージドなデータの取り込みが可能です。また、プレビュー中の MySQL や PostgreSQL から Iceberg テーブルへの CDC 連携機能を使用すると、データベースの変更をニアリアルタイムで Iceberg テーブルへと取り込むことができます。 三菱UFJ銀行 金融市場領域におけるApache Iceberg / PyIcebergの可能性 株式会社三菱 UFJ 銀行 市場企画部市場エンジニアリング室 福田 晃平 氏 資料ダウンロード 最後は株式会社三菱 UFJ 銀行 (以下、三菱 UFJ 銀行)における、金融時系列テーブル管理における Iceberg と PyIceberg 活用の取り組みについて紹介しました。三菱 UFJ 銀行の市場部門では、伝統的な機械学習や生成 AI におけるモデルガバナンスとデータガバナンスを効果的に実現するため、特徴量のデータ品質管理やバージョン管理を実現するための仕組みを必要としていました。それらのデータはレコードレベルの更新や、スキーマ構造の柔軟な変更といった要件にも対応していく必要があります。 これらの要件に対応できるツールとして、Iceberg の活用に注目しました。Iceberg は、タグやブランチによるバージョン管理など、先述した特徴量のガバナンスに必要な多くの機能を備えています。しかしながら、日次時系列データのようにユースケースによっては〜数千万レコード程度のそれほど大きくないデータもあり、大規模なデータを扱う分散処理の仕組みを必ずしも必要としないことがあります。また、データサイエンティストのスキルセットとしても、JVM 系言語のスキルセットがない場合も多く、より慣れ親しんだツールによる活用を必要としていました。一方で、データやモデルのガバナンスはデータ規模に依存せずデータサイエンス共通の課題でもありました。 そこで、PyIceberg の検証を行うことにしました。PyIceberg は Python で Iceberg を操作するためのライブラリであり、Python のランタイムさえあれば簡単に Iceberg を操作できます。特徴量データの管理に求められる要件の PyIceberg での実現可能性を検証した結果、PyIceberg 単体ではテーブルメンテナンスなどに限界があるものの、AWS Glue の マネージドな機能で補完することで、 Amazon SageMaker AI や Glue、 AWS Lambda を組み合わせた堅牢な ML データ管理基盤を構築できることが示されました。 これらの検証結果を踏まえて、PyIceberg を活用してモデルガバナンスとデータガバナンスを実現しながら、データサイエンティストが伸び伸びと開発できるワークフローを整備していく展望が示されました。 まとめ 今回は、AWS での Iceberg の活用をテーマに、様々なセッションを用意させていただきました。本イベントをきっかけに、Iceberg を利用いただくことで、皆様のデータ分析ワークロードが少しでも楽になり、幸せになることを願っております。今後も、お客様のシステム運用を少しでも効率化できるように、このようなイベントを企画し、情報発信を継続していきます。AWS のサービスを利用することをご検討いただいているお客様がいらっしゃいましたら、無料で個別相談会を開催しておりますので、 こちらのリンク からぜひお申し込みください。 アマゾン ウェブ サービス ジャパン 合同会社 ソリューションアーキテクト 疋田

2025 年 6 月 9 日、AWS 目黒オフィスにて消費財業界向け Amazon Q in QuickSight ワークショップを開催いたしました。本イベントには 22 社 50 名の方々にご参加いただき、生成 AI を活用したデータ分析の新しい可能性について、実践的な学びの場を提供することができました。 イベントの背景と目的 近年、企業の意思決定においてデータ活用は不可欠となっています。しかし、多くの企業が膨大なデータから迅速に意思決定につながるインサイトを得ることに苦心し、データ分析の専門知識を持つ人材の不足に直面しています。さらに、システム部門はダッシュボード作成に十分な工数を割くことができず、ビジネス部門は分析スキルの不足や情報の複雑さにより、効果的にデータ活用ができないという現状があります。これらの課題に対し、生成 AI 技術を活用した BI ツールが新たなソリューションとして注目を集めています。本ワークショップでは、AWS の最新サービスである Amazon Q in QuickSight を通じて、生成AI x BI のデータ分析アプローチを体験していただく機会を設けました。 セッション内容 生成 AI x BI の概要説明とデモ ワークショップの最初のセッションでは、データ分析における生成 AI の可能性と Amazon Q in QuickSight の機能について解説を行いました。自然言語でのダッシュボード作成、データの解釈に関する Q&amp;A 機能、そしてデータストーリーの自動生成という 3 つの機能について、消費財業界向けのサンプルデータを用いたデモを実施しました。システム部門ユーザーとビジネス部門ユーザーそれぞれの視点から、具体的な活用シーンを紹介し、生成 AI と BI の融合がもたらす具体的なビジネス価値について説明しました。 ハンズオン 続くセッションでは、参加者の皆様に実際の Amazon Q in QuickSight を使用したダッシュボードの作成とデータ分析を体験していただきました。消費財業界の受注・出荷データを用いて、テーブル形式のビジュアルや時系列の積み上げ棒グラフなど、様々な形式のデータ可視化を自然言語での指示で作成しました。参加者は「受注金額が一番多い日」や「発注者ごとの出荷金額」といった具体的な問いかけを行い、Amazon Q in QuickSight が即座に適切なビジュアルと回答を提供する、これまでにない分析体験を得ることができました。 ユースケースディスカッション ディスカッションパートでは、参加者は実際の業務課題に基づいたデータ分析ダッシュボードの設計に取り組みました。このセッションでは、現場の具体的な課題からスタートし、生成 AI を活用した解決策の提案まで、段階的なアプローチで議論を深めていきました。 まず個人ワークでは、現場で直面している課題を具体的なストーリーとして言語化することに注力しました。参加者は「○○部署の A さんが××を見れなくて『XYZ できない』と困っている」という形式で課題を特定し、その可視化に必要な条件を 5W1H の形式で整理しました。 続くダッシュボード設計のフェーズでは、各参加者が具体的なラフスケッチを作成しました。ダッシュボードを端的に表現するタイトルの設定、ビジュアルの効果的な配置、フィルター機能の活用方法、KPI の視覚化方法など、実用的な観点から設計を進めました。特に今回は、生成 AI の活用を前提として、自然言語での問いかけとそれに対する期待する描画内容を具体的に検討し、Amazon Q in QuickSight の特徴を活かしたアイディアを考えていただきました。 グループディスカッションでは、各参加者が自身のダッシュボード案を説明し、活発な質疑応答が行われました。議論は特定した現場の課題、提案するダッシュボードの概要、生成 AI の活用方法、実装における工夫点など、多岐にわたりました。各グループで選出された代表者による全体発表では、実務に即した具体的な提案が共有され、参加者全員で知見を深めることができました。 懇親会 セッション終了後の懇親会では、参加者同士の交流を深めながら、各グループから提案されたダッシュボードのアイデアについて投票を行いました。参加者からの投票ではアルフレッサ伊賀様が、AWS メンバーからの投票ではアクタス則武様のアイデアが選出されました。両者とも、実務における課題を踏まえた実践的な提案として高く評価されました。 お客様の声 ワークショップ全体を通じて、他のお客様との交流による新しい知見の獲得や、BI と生成 AI の具体的な活用シーンの理解、実践的なハンズオン体験について、多くの好評の声をいただきました。特に、今後の活用領域として売上・業績予測や複数データの横断分析、自然言語による簡易作成機能への期待が寄せられ、具体的な業務適用への検討意欲も高まりました。 おわりに 本ワークショップは、生成 AI を活用したデータ分析の可能性と実用性について、参加者の皆様に具体的なイメージを持っていただく貴重な機会となりました。今後も、お客様のビジネス課題解決に貢献できるよう、より実践的で価値のある機会を提供してまいります。ご参加いただいた皆様に心より御礼申し上げます。

本記事は 2025 年 6 月 5 日に公開された “ Access Claude Sonnet 4 in Amazon Q Developer CLI ” を翻訳したものです。 Amazon Q Developer が CLI で Claude Sonnet 4 のサポートを開始し、追加コストなしで高度なコーディングと推論機能を開発プロセスに導入できるようになりました。この最新モデルは、SWE-bench でのエージェント型コーディングにおいて最先端の 72.7% のスコアを記録しており、コーディングにおいて優れた性能を発揮しています（詳細については Claude 4 の発表 をご覧ください）。強化されたコーディングと推論機能により、複雑なコードの分析、日常的な開発タスクの最適化、バグ修正の実装、bash コマンドの実行、新機能の開発を、高速なフィードバックループとより正確な応答で支援します。 Claude Sonnet 4を活用するために、Amazon Q Developerでは特定のClaude Sonnetモデルを簡単に選択できるようになっており、CLIでより柔軟な操作が可能になっています。 Claude Sonnet 4: バランスの取れたインテリジェンスを持つ高性能モデル Claude Sonnet 3.7: 拡張された思考能力を持つ高性能モデル Claude Sonnet 3.5: 高性能インテリジェントモデル Claude モデルの機能と比較の詳細については、 Anthropic モデル概要 を参照してください。 このブログ記事では、Q Developer CLI で Claude Sonnet 4 をモデルとして選択する方法を説明し、簡単なデモを紹介します。 Claude Sonnet 4 の選択方法 Amazon Q Developer CLI の最新バージョン（ v1.11.0 以降）に更新してください。インストール手順については、 Amazon Q for command line のインストール を参照してください。Claude Sonnet 4 には以下のオプションでアクセスできます： アクティブなチャット中に /model コマンドを使用して claude-4-sonnet を選択 q chat --model claude-4-sonnet で新しいチャットを開始 q settings chat.defaultModel claude-4-sonnet でデフォルトモデルとして設定 --model パラメータと設定でサポートされているモデル名は以下の通りです： claude-3.5-sonnet claude-3.7-sonnet (デフォルト) claude-4-sonnet モデル選択の優先順位 Q Developer CLI は以下の順序でモデルを選択します： 現在のセッションでのモデル選択（ /model または --model による） 設定でのユーザー構成設定 システムデフォルト（ Claude 3.7 Sonnet ） 主要な動作 Q Developer CLI エージェントは、特定のモデルが選択されていない場合、Claude 3.7 Sonnet をデフォルトとします。アクティブなチャットセッション中は、 /model コマンドを使用してモデル間をシームレスに切り替えできます。チャットの継続性はセッション間で維持され、会話が再開されたときにシステムは以前に選択されたモデルを保持します。Claude Sonnet 4 を好む場合、ユーザー設定でデフォルトモデルとして設定すると、すべての新しいチャットセッションに自動的に適用されますが、必要に応じて特定のモデル選択で設定を上書きできます。 図 1: セッションで読み込まれたモデルを表示する Q Developer CLI Claude Sonnet 4 と Q Developer CLI の実際の動作 Q Developer CLI で Claude Sonnet 4 に切り替えた後、その機能を実際のコーディング例で探ってみましょう。こちらがデモンストレーションで使用するプロンプトです。 以下の機能を持つ Python コマンドライン to-do リストアプリを作成してください： - 説明と優先度（low/medium/high）付きのタスクを追加 - インデックスでタスクを完了としてマーク - 優先度、次に挿入順でタスクをソート表示 - 完了ステータスを表示（[x] 完了、[ ] 保留中） - 空のタスクと無効なインデックスのエラーハンドリング - タスクはメモリ内のみに保存 このアプリケーションを実装するコードを提供してください。 図 2: Claude Sonnet 4 の動作を示す Q Developer CLI インターフェイス 上記のデモンストレーションでは、Claude Sonnet 4 を使用した Q Developer CLI が、プロンプトで提供された要件を超えて、引用された説明を含む高度なコマンド解析、包括的なエラーハンドリング、型ヒントで強化されたクリーンなオブジェクト指向設計を実装しました。インターフェイスには、明確なエラーメッセージと列挙型（enum）を使った、シンプルで見やすい優先度の管理、タスクを明確に表現するフォーマットされた出力などを備えた、有用なガイダンスシステムが特徴です。 さらに、Claude Sonnet 4 を使用した Q Developer CLI は、実用的なエラーハンドリングの例と明確な使用方法を含む to-do アプリケーションの README ドキュメントも生成し、プロンプトの要件を構造化された使いやすいアプリケーションに変換しました。 まとめ Claude Sonnet 4 が利用可能になったことは、Amazon Q Developer の機能における重要な進歩を意味します。複雑なコードリファクタリングから効率的なドキュメント作成まで、Claude Sonnet 4 は複雑なタスクも日常的な開発作業も効率的に実行する手助けをします。 複雑なタスクに Claude Sonnet 4 を選択するか、特定のニーズに他のモデルを使用するかにかかわらず、Amazon Q Developer はあなたの好みに適応し、作業の進め方の効率性を維持しながら AI アシスタンスを最適化します。 Amazon Q Developer の最新バージョン（ v1.11.0 ）が CLI に登場し、強化されたモデル機能と選択オプションであなたの開発をサポートします。インストール手順については、 Amazon Q for Command line のインストール を参照してください。 Amazon Q Developer の機能と価格の詳細については、 Amazon Q Developer 製品ページ をご覧ください。 翻訳はApp Dev Consultantの宇賀神が担当しました。 著者について Kirankumar Chandrashekar は、Amazon Q Developer に焦点を当てた AWS の生成 AI スペシャリストソリューションアーキテクトです。AWS クラウドサービス、DevOps、モダナイゼーション、Infrastructure as Code の深い専門知識を持ち、Amazon Q Developer を使用して顧客の開発プロセスの向上を支援しています。Kirankumar は複雑な顧客の課題を解決することに情熱を持ち、音楽、料理、旅行を楽しんでいます。

Amazon Nova は、Amazon Bedrock で利用できる、最先端のインテリジェンスと業界をリードするコストパフォーマンスを実現する新世代の基盤モデルで、4 つの理解モデル、2 つのクリエイティブコンテンツ生成モデル、1 つの Speech-to-Speech モデルが含まれます。Amazon Nova 理解モデルは、テキスト、画像、動画入力を受け入れてテキスト出力を生成するモデルで、機能、品質、スピード、コストについて幅広い選択肢を提供します。 この記事では 、Amazon Nova 理解モデルのプロンプトエンジニアリングの ベストプラクティス に従って、パフォーマンスを最適化する方法を紹介します。 Amazon Nova 理解モデルの特徴 Amazon Nova モデルには様々なニーズに合うように設計された 4 つの理解モデルが含まれています。 Amazon Nova Micro – 非常に低コストで最小レイテンシーのレスポンスを提供するテキストのみのモデルです。 Amazon Nova Lite – 非常に低コストのマルチモーダルモデルで、画像、動画、テキストの入力を高速で処理できます。 Amazon Nova Pro – 幅広いタスクの精度、速度、コストを最適に組み合わせた、高性能のマルチモーダルモデルです。 Amazon Nova Premier – 複雑なタスクに最適なマルチモーダルモデルであり、コスト効率の高いアプリケーション向けのカスタムモデルを蒸留するための教師にもなります。 各モデルの料金の詳細については、 Amazon Bedrock の料金ページ をご覧ください。 Amazon Nova 理解モデルのプロンプトエンジニアリング モデルを効果的に導いて品質の精度を向上させるため、明確な指示で構造化されたプロンプトを反復的に改善することが重要です。ユースケースに最適なプロンプトを開発できるように、次の要素を検討することをお勧めします。 プロンプトのユースケースの定義する タスク – モデルが具体的に何をするか ロール – モデルが想定すべきロール 応答スタイル – 出力の構造やトーン 指示 – モデルが順守すべきガイドライン 思考連鎖を利用するか モデルの応答を制限する明確で強い指示を与える Step-by-Step で考えることで構造的思考を促す フォーマットと構造 ##Task##、##Context##、##Example## のように、区切り文字を使用してプロンプトのセクションを分ける JSON、YAML、Markdown などの出力形式を指定する DO、DO NOT、MUST など、強い指示や制限を使用する 事前入力(prefill)して、前書きを省略したり指定した形式で出力することを誘導する Amazon Nova 理解モデルのプロンプト例 議事録を要約する以下の例を考えてみましょう。ベストプラクティスに従って Amazon Nova Pro のプロンプトは以下のシステムプロンプトから始まります。ここでは temperature を 0.2、 topP を 0.9 にしています。 あなたは会議議事録の分析と要約に長けた経験豊富なエグゼクティブアシスタントです。あなたの主な責任は、複雑な議論を明確で実行可能な要約にまとめることです。 以下の指示に従ってください。 ##INSTRUCTIONS## 1. ##NOTES## にある会議議事録を読んで理解してください 2. すべての出力を ##OUTPUTS## というセクションにマークダウン形式で入れてください。 3. 会議議事録を 5 文以内に要約してください。これを「全体概要」というセクションに入れてください。 4. 特定の人向けのアクションアイテムと、完了する必要があるものを数値で挙げてください。このリストを「アクションアイテム」というセクションに入れてください。 5. 該当する場合は、次回の会議でさらに詳しく議論する必要があるトピックをリストアップしてください。これを「次回の会議のトピック」というセクションに入れてください。 ユーザプロンプトには、以下の SF 風の架空の議事録を用意しました。最後に ##OUTPUTS## という文字列を事前入力して、前書きの省略とマークダウン形式での出力を誘導しています。 ##NOTES## ミーティング開催日:2050 年 3 月 5 日 ミーティング時間:午後 2 時 場所:銀河間本部会議室 3B 出席者: - キャプテン・スターダスト - ドクター・クェーサー - レディ・ネビュラ - サー・スーパーノヴァ - ミス・コメット 午後 2 時 5 分にキャプテン・スターダストが招集したミーティング 1. 最新のチームメンバー、コメットさんの紹介 2. プラネット・ゾグへの最近のミッションについての議論 - キャプテン・スターダスト：「全体的には成功だったが、ゾギアンとのコミュニケーションは難しかった。私たちは語学力を向上させる必要があります。」 - クエーサー博士：「同感です。すぐにゾギアン-英語辞書の作成に取り掛かります。」 - レディ・ネビュラ：「ゾギアンの料理は文字通りこの世のものとは思えませんでした！船でゾギアンのフードナイトをすることを検討すべきだ。」 3. セクター7における宇宙海賊問題への取り組み - サー・スーパーノバ：「この海賊に対処するには、もっと良い戦略が必要だ。彼らは今月、すでに 3 隻の貨物船を略奪しました。」 - キャプテン・スターダスト：「その地域でのパトロールを増やすことについて、スタービーム提督と話そう。 - クエーサー博士:「船が海賊に発見されないようにするのに役立つ新しいクローキング技術の開発に取り組んできました。プロトタイプを完成させるにはあと数週間かかります。」 4. 毎年恒例の銀河間ベイクオフのレビュー - レディ・ネビュラ：「私たちのチームがコンペティションで2位になったことを報告できてうれしいです！私たちのマーシャン・マッド・パイは大ヒットでした！ - コメットさん：「来年は1位を目指しましょう。ジュピターゼリーの秘密のレシピがあって、それが勝つかもしれないと思う。 5. 次回のチャリティ募金活動の計画 - キャプテン・スターダスト：「インターギャラクティック・チャリティ・バザーのブースには、クリエイティブなアイディアが必要です。」 - サー・スーパーノバ：「『ダンク・ザ・エイリアン』のゲームはいかがですか？エイリアンの格好をしたボランティアに水風船を投げてもらうこともできます。」 - クエーサー博士：「勝者には賞品がもらえる『あの星の名前』トリビアゲームを作れるよ。」 - レディ・ネビュラ：「皆さん、素晴らしいアイディアですね。物資を集めてゲームの準備を始めましょう。」 6. 今後のチームビルディング・リトリート - コメットさん：「ムーン・リゾート・アンド・スパでのチームビルディング・リトリートを提案したいです。最近のミッションを終えて、絆を深め、リラックスする絶好の機会です。」 - キャプテン・スターダスト:「素晴らしいアイディアですね。予算を確認して、実現できるか見てみます。」 7. 次回の会議の議題項目 - ゾギアン英語辞典の最新情報 (クエーサー博士) - クローキング技術の進捗報告 (クエーサー博士) - セクター 7 (キャプテン・スターダスト) でのパトロール強化の結果 - 銀河間チャリティーバザーの最終準備 (全て) 会議は午後 3 時 15 分に延期されました。次回の会議は、2050 年 3 月 19 日午後2時に会議室3Bで開催される予定です。 銀河間本部。 ##OUTPUTS## 以下は Amazon Nova Pro の出力になります。マークダウン形式で出力され、各アクションアイテムの明確な担当者も特定しています。 ### 全体概要 会議では、新しいチームメンバーの紹介、プラネット・ゾグへのミッションの議論、宇宙海賊問題への取り組み、銀河間ベイクオフのレビュー、チャリティ募金活動の計画、チームビルディング・リトリート、そして次回の会議の議題項目について話し合われました。 ### アクションアイテム 1. クエーサー博士：ゾギアン-英語辞書の作成を開始する。 2. キャプテン・スターダスト：スタービーム提督とセクター7でのパトロール増加について話し合う。 3. クエーサー博士：新しいクローキング技術のプロトタイプを完成させる。 4. 全員：銀河間チャリティーバザーのブースのための物資を集める。 5. キャプテン・スターダスト：ムーン・リゾート・アンド・スパでのチームビルディング・リトリートの実現可能性と予算を確認する。 ### 次回の会議のトピック 1. ゾギアン英語辞典の最新情報 (クエーサー博士) 2. クローキング技術の進捗報告 (クエーサー博士) 3. セクター 7 でのパトロール強化の結果 (キャプテン・スターダスト) 4. 銀河間チャリティーバザーの最終準備 (全て) Function calling 生成 AI エージェントの台頭により Tool use(function calling) は 大規模言語モデル （LLM）にとって最も重要な機能のひとつとなりました。ジョブに適したツールを低レイテンシーで正しく選択するモデルの能力が、エージェントを使ったシステムの成功と失敗の分かれ目になる場合があります。 Amazon Nova 理解モデルの Tool use は構造化された API の呼び出しをサポートしており、ツール設定スキーマによるツールの選択をサポートしています。また、これらのツールをいつ発動させるか、させないかを決定するメカニズムも提供しています。 以下の例では、 ツール設定スキーマを渡してツールを呼び出しています。Amazon Nova 理解モデルではツールを呼び出す際に Greedy Decoding を使用するように、 temperature 、 topP 、 topK を 1 に設定することが推奨されています。 Converse API を使用する場合は、 temperature 、 topP は、 inferenceConfig 属性で指定し、 topK は additionalModelRequestFields 属性で指定します。これによりモデルはツールの選択において最高の精度を持つようになります。Greedy Decoding パラメータやその他のツールの使用例については、 Tool use (function calling) with Amazon Nova で詳しく説明されています。 tool_config = { "tools": [{ "toolSpec": { "name": "get_recipe", "description": "構造化されたレシピ生成システム", "inputSchema": { "json": { "type": "object", "properties": { "recipe": { "type": "object", "properties": { "name": {"type": "string"}, "ingredients": { "type": "array", "items": { "type": "object", "properties": { "item": {"type": "string"}, "amount": {"type": "number"}, "unit": {"type": "string"} } } }, "instructions": { "type": "array", "items": {"type": "string"} } }, "required": ["name", "ingredients", "instructions"] } } } } } }] } input_text = "チョコレートラバケーキのレシピを教えてください" messages = [{ "role": "user", "content": [{"text": input_text}] }] # 推論パラメーターを指定 inf_params = {"topP": 1, "temperature": 1} # additionalModelRequestFields でモデル固有の推論パラメータ (topK=1) を指定 response = client.converse( modelId="us.amazon.nova-lite-v1:0", messages=messages, toolConfig=tool_config, inferenceConfig=inf_params, additionalModelRequestFields={"inferenceConfig": {"topK": 1}} ) まとめ Amazon Nova 理解モデルは、Amazon Bedrock で利用可能な高性能かつコスト効率に優れた次世代基盤モデルです。4 つの理解モデルは、機能、品質、スピード、コストに応じて選択できます。Amazon Nova 理解モデルのパフォーマンスを最適化するには、明確な指示で構造化されたプロンプトを反復的に改善すること、Tool use において Greedy Decoding を使用する設定を行うことが推奨されます。また、これらの手法を活用することでより安価なモデルでも十分なパフォーマンスを発揮しコスト最適化に寄与する可能性があります。

はじめに アマゾン ウェブ サービス (以下、AWS) は、2025年6月30日に Amazon Connect の機能として Amazon Connect Global Resiliency（以下、ACGR）を 日本で一般提供開始 しました。これにより、AWS アジアパシフィック（東京）リージョンで Amazon Connect インスタンスをご利用されているお客様が、AWS アジアパシフィック（大阪）リージョンのインスタンスに設定を同期し、フェイルオーバーできるようになりました。日本国内にある2つの AWS リージョン間で Amazon Connect Global Resiliency を利用することによって、地域的な災害や障害が発生した場合のダウンタイムを最小限に抑えることができます。また、データを日本国内に保持しながら、コンタクトセンターの可用性を高めることができます。 本ブログでは Amazon Connect が備えている信頼性について改めて解説した上で、ACGR の機能概要と利用にあたりお客様にご理解いただきたい事項、日本で利用可能なACGR の機能についてご紹介します。ACGR の詳細な解説については、 管理者ガイド をご参照ください。 Amazon Connect の信頼性 Amazon Connect は、AWS グローバルインフラストラクチャ上にデプロイされるオムニチャネルのクラウドコンタクトセンターです。AWS グローバルインフラストラクチャは、AWS リージョンとアベイラビリティーゾーンを中心に構築されています。AWS リージョンは、低レイテンシー、高スループット、高い冗長性を備えたネットワークによって接続された、物理的に独立した複数のアベイラビリティーゾーンを提供します。アベイラビリティーゾーンは、単一または複数のデータセンターインフラストラクチャよりも可用性が高く、耐障害性に優れ、スケーラブルです。 Amazon Connect は、サービスを提供している各 AWS リージョンにおいて、3つ以上のアベイラビリティーゾーン (AZ) に冗長な専用ネットワーク経路を持つ、複数の通信事業者と接続しています。特定のコンポーネント、データセンター、または AZ 全体に障害が発生した場合、影響を受ける箇所は自動的にシステムから除外されます。これにより、お客様に一貫した品質の体験を提供することが可能です。 Amazon Connect に接続する各通信事業者は、アクティブ/アクティブ構成で複数の AZ に接続されています。これにより、ネットワーク経路や AZ 全体の障害がお客様の体験に影響を与えることはありません。また、異なる通信事業者の複数電話番号を利用するデザインにすることで、万一通信事業者に障害が発生した場合でもお客様は別の電話番号を利用してコンタクトセンターに問い合わせることが可能になり、影響を最小限に抑えることができます。詳細については Amazon Connect の耐障害性 をご覧下さい。 図１．単一リージョンのテレフォニーとソフトフォンのアーキテクチャ（出典： Amazon Connect 管理者ガイド ） マルチリージョンの Amazon Connect デプロイメントを検討されるお客様はまず、シングルリージョン/マルチ AZ デプロイメントではお客様のニーズを満たせない理由を明確にし、理解することが重要です。次に、お客様の災害復旧やビジネス継続性に関する要件が、運用やコンプライアンス、その他の規則や規制に関連し、マルチリージョンを必須要件としているかなどを 、AWS のソリューションアーキテクトと議論してください。また、お客様の本番環境で ACGR をご利用いただくには、 AWS Well-Architected Framework の Amazon Connect Custom Lens を確認することが前提条件となります。Well-Architected Framework のレビューを実施することで、ACGR の必要性を確認することができます。 ACGR の機能概要 ACGR は、Amazon Connect に地理的なテレフォニー（電話通信）の冗長性を提供し、予期しないリージョンの機能停止や中断が発生した場合に、インバウンドトラフィックとエージェントを別のリージョンの Amazon Connect インスタンスに分散する柔軟なソリューションを提供します。お客様は複数の AWS リージョンに Amazon Connect をデプロイし、どのリージョンで着信コールを受信し、エージェントが対応するかを API によって制御できます。 コンタクトセンターのお客様は、フェールオーバー後も同一の電話番号を使用して問い合わせが可能です。 コンタクトセンターのエージェントは、フェールオーバー後もログインし直すことなく業務継続が可能です。 ソースインスタンスとレプリカインスタンスは、自動的に双方向で設定を同期します。 これらの機能を理解するために、以下ではいくつかの概念と関連用語を解説します。 トラフィック分散グループ (TDG) トラフィック分散グループ (TDG) は、異なる AWS リージョンにある Amazon Connect インスタンスをリンクするリソースです。ACGR の使用を開始すると、デフォルトの TDG が1つ作成されますが、事業部別窓口などのユースケースに基づいて TDG を追加することもできます。TDG では、トラフィックやエージェントログインの分散を割合 (%) で指定します。コンタクトセンターの管理者はTDG ごとの割合を操作することで、お客様の問い合わせトラフィックをルーティングするリージョンと、エージェントがログインするリージョンを変化させることができます。 図２．トラフィック分散グループ（出典： Amazon Connect Global Resiliency Workshop ） グローバルサインイン ACGR により、コンタクトセンターのエージェントは業務開始時に1度サインインするだけで、どのリージョンを利用しているかを意識することなく、現在アクティブなリージョンを利用してお客様の問い合わせに対応できます。管理者が API を使用して TDG のエージェントログイン先を変更した場合、エージェントが再ログインすることなくアクティブなリージョンに切り替わります。これは、エージェントが ACGR に対応するオプションを有効化したカスタム CCP を利用している場合、またはエージェントワークスペースを使用している場合に有効です。 図３．グローバルサインイン（出典： Amazon Connect Global Resiliency Workshop ） グローバル設定管理 (GSM) ACGR の利用を開始する際は、API を使用してソースインスタンスのレプリカを作成します。これにより、グローバル設定管理サービスは初期レプリケーションプロセスとして、AWS リージョン間で Amazon Connect 設定を複製します。この最初のステップが正常に完了すると、複製されたリソースに対して行われた変更は、ソースまたはレプリカインスタンスのいずれであっても、リージョン間で継続的に双方向で同期されます。同期対象のリソースは こちら を参照してください。レポート、ルール、ビューなどのデータや設定は対象外です。また Amazon Connect が連携している Amazon Lex や AWS Lambda、Amazon S3 上のデータも同期の対象外です。対象外の設定やデータのうち運用に必要となるものは、お客様の責任において設定やデータの複製を実施いただく必要があります。 図４．グローバル設定管理（出典： Amazon Connect Global Resiliency Workshop ） ACGR の監視と運用 ACGR の運用は、お客様と AWS の共同責任です。AWS は2つの AWS リージョンでフェイルオーバーするためのインフラストラクチャを提供する責任があります。お客様は、インスタンス設定を最新の状態に保ち、お客様ごとのビジネス要件に基づいてトラフィックとエージェントの分散を管理する責任があります。また、インスタンスを監視しシステム状態とパフォーマンスにおける異常や、通常と異なる動作を発見する仕組みを準備することが求められます。さらにお客様は、独自の事業継続プロセス (BCP) および標準運用手順 (SOP) において、フェールオーバーの承認プロセスや判断基準を定義しておく必要があります。 ACGR の運用にあたっては、Amazon Connect インスタンスのモニタリングと、ACGR のモニタリングも必要となります。インスタンスのモニタリングでは、アクティブな通話数やコンタクトフローのエラーなどにより、Amazon Connect の健全性を確認します。ACGR のモニタリングは、設定のミラーリングプロセスを確認することで、ACGR 自体の健全性を確認します。これらの監視にあたっては、 Amazon CloudWatch や AWS CloudTrail を活用することができます。 日本における ACGR 利用上の注意事項 AWS アジアパシフィック (大阪) リージョンの Amazon Connect は、AWS アジアパシフィック (東京) リージョンのビジネス継続性を確保するために、音声、チャット、タスクのチャネルを利用することが可能です。2025年6月30日時点では、アジアパシフィック (大阪) リージョンにおいて以下の機能はサポートされていません。 Amazon Lex Amazon Connect Contact Lens Amazon Q in Connect Amazon Connect Customer Profiles Amazon Connect Cases アプリ内通話、ウェブ通話、ビデオ通話機能、および画面共有機能 予測、キャパシティプランニング、スケジューリング Amazon Connect アウトバウンドキャンペーン このため TDG による分散は、通常時が東京100％ / 大阪0%、フェールオーバー時は東京0% / 大阪100% という設定で運用されることになると想定しています。これ以外の設定で東京と大阪を同時に利用する場合、お客様およびエージェントごとの体験に差異が生じる恐れがあります。また、フェールオーバー時に継続利用可能な電話番号は、2025年6月30日時点で TFN (料金無料通話番号)をサポートします。 まとめ ACGR の一般提供開始により、地理的に離れた場所での災害対策を必要とするお客様や、国内でデータを保存する要件のあるお客様のニーズにお応えすることが可能になります。ACGR の利用を開始するには、AWS のアカウントチーム、テクニカルアカウントマネージャー、または Amazon Connect ソリューションアーキテクトにお問い合わせください。詳細なセットアップの方法や、切り替えテストの手順、ベストプラクティスについては、 Amazon Connect Global Resiliency Workshop を参照してください。