はじめに Amazon Web Services（AWS）には、あらゆる規模の組織のニーズを満たす SAP の導入パターンが複数用意されています。AWS では、 AWS patterns for Resilience に従って、SAP のワークロードは AWS リージョン内の複数のアベイラビリティゾーン（AZ）にまたがって展開することができます。 当社の標準的な推奨事項は、SAP システム（例：S/4HANA または ECC ）に複数の SAP アプリケーションサーバーがある場合、SAP システムの可用性と信頼性を全体的に向上させるために、これらのアプリケーションサーバーを異なる AZ に展開することです（図1参照）。 図1：マルチ AZ に分散した複数の SAP アプリケーションサーバーを持つ SAP アプリケーション 図1 は簡略化したアーキテクチャ図であり、(1) SAP ユーザーは SAP アプリケーションサーバーに接続し、(2)アプリケーションサーバーはデータベースサーバーに接続します。 SAP のクライアント／サーバーアーキテクチャでは、アプリケーション層のスケールアウト、つまり複数の SAP アプリケーションサーバーを追加することで、大規模な SAP ワークロードをサポートすることができます。 このアーキテクチャのトレードオフは、一部のワークロード（パフォーマンスが重要なバッチジョブなど）において、AZ  間のレイテンシがランタイムパフォーマンスに影響する可能性があることです（ SAP Lens for Well Architected – Performance recommendations for latency および  SAP ノート 3496343 （SAP サポートポータルへのアクセスが必要です）参照）。 このブログでは、この問題を軽減するために、データベースサーバーと同じ AZ でホストされているアプリケーションサーバー上でバッチまたはパフォーマンスが重要なワークロードを実行するソリューションについて説明します。 レイテンシーに関する SAP の推奨 ブログ “ End-to-End Observability for SAP on AWS： Part 2 – SAP Network Latency Monitoring “では、SAP アプリケーション層とデータベース層間の SAP ネットワークパフォーマンスの重要性について説明しました。 パフォーマンスの良い SAP システムのためには、SAP アプリケーション層（つまりアプリケーションサーバー）とデータベースサーバー間のネットワークレイテンシが以下の SAP の推奨に従っていることを確認することが重要です： SAP ノート 1100926 に従って、SAP アプリケーションサーバーとデータベースサーバー間のネットワーク遅延を 0.7 ミリ秒（ms）未満にすること（SAP サポートポータルへのアクセスが必要です） 同期データレプリケーションを使用した HANA システムレプリケーションのネットワークレイテンシ（データ損失をゼロにするために必要）を 1ミリ秒未満 にすること AWS for SAP におけるレイテンシの影響 一般的に、AZ 間ネットワークのレイテンシは、上記の SAP のネットワーク推奨値を遵守しています。 ただし、このレイテンシは時間の経過とともに変化し、リージョンや AZ ペアによっても異なります。 お客様は、 AWS Network Manager – Infrastructure Performance または  SAP の NIPING （SAP サポートポータルへのアクセスが必要）を使用して、AZ 間のネットワークレイテンシ（Inter-AZ ネットワークレイテンシとして知られている）と同じ AZ 内のネットワークレイテンシ（Intra-AZ ネットワークレイテンシ）を測定することができます。 AZ 間の地理的距離を考慮すると、AZ 内ネットワークレイテンシは AZ 間ネットワークレイテンシよりも低くなります。 したがって、AZ 間の高可用性を実現するために SAP ワークロードをアーキテクトする場合は、ネットワークレイテンシが最も低い AZ ペアで展開することをお勧めします。 パフォーマンスクリティカルな SAP ビジネスプロセスの例として、自動車、消費財、食品・飲料、製薬などの製造業で使用されるバックフラッシュプロセス（自動出庫）があります。 自動車業界では、バックフラッシュプロセスでは、生産オーダーが確定すると、部品表（BOM）とルーティングに基づいて、在庫から原材料や部品の必要量を自動的に差し引きます。 例えば、あるメーカーが 100 個の自動車エンジンを生産する場合、各エンジンに 4 個のピストン、8 個のバルブ、1 個のクランクシャフトが必要であれば、バックフラッシュプロセスは、手入力することなく、自動的に 400 個のピストン、800 個のバルブ、100 個のクランクシャフトを在庫から差し引きます。 これにより、効率的で正確な在庫管理が保証され、手作業によるデータ入力が削減され、生産進捗と材料使用に関するリアルタイムの最新情報が提供されます。 このバックフラッシュプロセスの動作が遅いと、製造ラインの生産性に影響が出ます。 バックフラッシュプロセス（トランザクション MFBF）に対する AZ 間ネットワーク遅延の影響を理解するため、図2 に示すテストを実行しました。このテストによると、データベースサーバーとは異なる AZ にあるアプリケーションサーバー 2 および 3 で実行した場合、RFC 実行時間のパフォーマンスが 4～10 倍低下しました。 図2：パフォーマンスクリティカルなジョブおよびトランザクションに対する AZ 間ネットワーク遅延の影響の比較 図 2 によると、AZ 間レイテンシは、長時間実行されるトランザクションや、大量のデータベース呼び出し （ラウンドトリップ）を行うタイムクリティカルなパフォーマンス要件のバッチジョブに大きな影響を与えます。 したがって、レイテンシがより低い AZ  内ネットワークに利点があるため、これらのジョブをデータベースサーバーと同じ AZ 内の SAP アプリケーションサーバーで実行することをお勧めします。 次のセクションで説明するソリューションは、障害が発生し、プライマリデータベースがある AZ から別の AZ に移動した場合でも、このプロセスを自動化するのに役立ちます。 SAP ネットワークのパフォーマンスを自動的に最適化 SAP のワークロードが適切に管理され、SAP アプリケーションサーバーに均等に分散されるように、SAP は以下のワークロード バランシングまたは分散メカニズムを提供しています： 表1：SAPの負荷分散メカニズム 図3 のように、高可用性を備えた SAP S/4HANA を実行し、複数の SAP アプリケーションサーバーがデータベースサーバーに接続している自動車関連企業の例を見てみましょう。 パフォーマンスクリティカルなバックフラッシュバッチジョブは、表 1 にあるように、SAP の負荷分散メカニズムを使用してアプリケーションサーバー 1 で実行されるように構成されています。 図3：パフォーマンスクリティカルなジョブ/トランザクションについて、プライマリーデータベースと同じ AZ にあるアプリケーションサーバーを指すように SAP の負荷分散メカニズムを調整する パフォーマンスクリティカルなトランザクション / ジョブ用のログオン / バッチ / RFC サーバーグループは、プライマリ DB と同じ AZ にあるアプリケーションサーバー 1 を指すように構成されています。 プライマリ DB からスタンバイ DB にデータベースサーバーがフェイルオーバーした場合、アプリケーションサーバー1 から実行されるパフォーマンスクリティカルなトランザクション/ジョブは、AZ 内のネットワークレイテンシーがわずかに高くなるため、パフォーマンスが低下します。 この問題を解決するには、ログオン / バッチ / RFC サーバーグループを調整し、代わりにアプリケーションサーバー 2 を指すようにする必要があります。 提案するソリューションは、データベースと同じ AZ にあるアプリケーションサーバーを指すように、SAP の負荷分散メカニズム（ログオングループ、バッチサーバーグループ、RFCサーバーグループ）を自動的に更新します。 これにより、データベースのフェイルオーバー / フェイルバックが発生した場合でも、パフォーマンスが重要なトランザクションとジョブは、データベースと同じ AZ 内のアプリケーションサーバーで処理されます。 図4 は、提案ソリューションのハイレベル アーキテクチャを示しています。 図3 にアプリケーションサーバーを追加したものと似ています。 このソリューションは SAP の ABAP 言語で開発されているため、 AWS SDK for SAP ABAP を活用し、以下のステップ 4 に従って、 Amazon Simple Notification Service（SNS） を介して、SAP システムを管理する IT チームにこの変更の通知を送信することができます。 図 4 : SAP サーバーグループの動的更新と AWS ABAP SDK による通知 マルチ AZ ネットワーク最適化ソリューションの構築 このソリューションは、SAP ABAP 言語を使用するため、ABAP スタックを使用するあらゆる SAP アプリケーションとの互換性を保証し、RISE with SAP を含む、SAP Netweaver ABAP アーキテクチャ上で動作するあらゆる SAP for AWS 環境にインストールすることができます。 重要な考慮事項 このソリューションは、SAP S/4HANA 2023 で正常にテストされました。 ログオングループと RFC サーバーグループ (RZ12) を変更するために、このソリューションは SMLG_MODIFY 関数モジュールを使用します。 バックグラウンド処理グループ（SM61）を変更するには、CL_BP_SERVER_GROUP クラスを使用します。 AWS SDK for SAP ABAP から通知機能を使用する場合は、 Getting Started with the AWS SDK for SAP ABAP Blog を参照してください。 サンプル ABAP コードは、 Multi-AZ Network Optimized Solution github にあります。 3 つのロードバランシングメカニズムのいずれかを使用することができます（例えば、バッチサーバーグループのみを更新し、ログオングループと RFC サーバーグループはそのままにしておくことができます）。 パフォーマンスが重要なバッチジョブや、大量の RFC 呼び出しを行うジョブは、バッチサーバーグループと RFC サーバーグループを更新して、これらのジョブがデータベースと同じ AZ にあるアプリケーションサーバーで実行されるようにするのが得策です。 以前の S/4HANA または SAP ECC のバージョンでソリューションを実装したい場合は、上記の両方の機能モジュールの可用性を確認し、最初に Non-Production システムでテストしてください。 AZ/DB 障害の検出 AZ および/またはデータベースに障害が発生すると、スタンバイ データベースインスタンスは 高可用性クラスタソフトウェアによってアクティブな役割に変更されます。 そのため、プライマリデータベースインスタンスのホスト名が変更されます。このホスト名は、ABAP の SQL クエリで確認できます。 図5 : ソリューションのワークフロー このソリューションでは、2つのテーブルを使用します： /AWSSAMP/MAZ_DB : SQL クエリで取得したプライマリデータベースのホスト名が含まれています。 /AWSSAMP/MAZ_CO : アプリケーションサーバーと定義されたログオン/サーバーグループのコンフィギュレーション情報が含まれています。 このテーブルは、プライマリデータベースに対するアプリケーションサーバーの AZ を決定します。 図 6 : それぞれのログオン/サーバーグループに割り当てられたアプリケーションサーバーを示す表 /AWSSAMP/MAZ_CO AZ /データベースの障害状況を検出するコード スニペットです。 この SQL 実行結果をテーブル /AWSSAMP/MAZ_DB に保存しておけば、次回プログラム実行時に、データベースのホスト名が前回実行時と変わっていれば、AZ やデータベースに障害が発生したと判断できます。 DATA: lv_hostname TYPE char20. lo_con TYPE REF TO cl_sql_connection, lo_stmt TYPE REF TO cl_sql_statement, lo_result TYPE REF TO cl_sql_result_set, lv_sql TYPE string, lt_data TYPE REF TO data. TRY. lo_con = cl_sql_connection=>get_connection( ). lo_stmt = lo_con->create_statement( ). lv_sql = |select host from M_DATABASE|. lo_result = lo_stmt->execute_query( lv_sql ). get REFERENCE OF lv_hostname into lt_data. lo_result->set_param( lt_data ). lo_result->next( ). lo_con->close( ). CATCH cx_sql_exception INTO DATA(err). MESSAGE err->get_text( ) TYPE 'E'. ENDTRY. DATA: lo_get_dbhost TYPE REF TO /AWSSAMP/CL_MAZ_GET_DBHOST. * Get a result of previous execution. SELECT * INTO TABLE lt_dbhost FROM ZTAWSMULTIDB. * Compare a current SQL execution with the previous execution LOOP AT lt_dbhost INTO ls_dbhost. * If it is different, Updating the current result to a temporary table. IF lv_hostname NE ls_dbhost-dbhost. ls_current_dbhost-mandt = '100'. ls_current_dbhost-dbhost = lv_hostname. * Update current Active DB Hostname into /AWSSAMP/MAZ_DB UPDATE /AWSSAMP/MAZ_DB FROM ls_current_dbhost. ENDIF. ENDLOOP. ログオン/ RFC サーバーグループの変更 ログオングループはトランザクションコード  SMLG   で変更でき、RFC サーバーグループはトランザクションコード RZ12 で変更できます。 SAP Netweaver ABAP スタックには、これら 2 つのグループを照会および変更するための SMLG_GET_DEFINED_SERVERS および SMLG_MODIFY 標準関数が用意されています。 サーバーグループを変更する前に、SMLG_GET_DEFINED_SERVERS 関数を呼び出して現在登録されている既存のアプリケーションサーバーを確認し、SMLG_MODIFY 関数を呼び出して既存のアプリケーションサーバーを削除して新しいアプリケーションサーバーをリストに登録します。 以下は、ログオンおよび RFC サーバーグループを変更するためのコード スニペットです。 GROUPTYPE 入力パラメータでグループのタイプを指定します。 例えば、’S’ は RFC サーバーグループを意味します。 SMLG_MODIFY 関数は、グループ内のアプリケーションサーバーの削除や挿入にも使用されるため、サンプルコード 2 に示すように、MODIFICATN パラメータに適切なタイプを入力する必要があります。 例えば、削除を行う場合は ‘D’ を入力します。 DATA: BEGIN OF ls_group, group_name TYPE char20, group_type TYPE char1, END OF ls_group. DATA: lt_group LIKE TABLE OF ls_group, lv_grouptype TYPE char1. DATA: lt_modi TYPE TABLE OF RZLLIMODIF, ls_modi TYPE RZLLIMODIF, lt_del_server TYPE TABLE OF RZLLIAPSRV. ls_modi-CLASSNAME = ls_group-group_name. ls_modi-GROUPTYPE = ls_group-group_type. * Function Modification Type * I. insertion of an item * D. deletion of an item * U. update of an item ls_modi-MODIFICATN = 'D'. ls_modi_erfc-CLASSNAME = ls_group-group_name. ls_modi_erfc-GROUPTYPE = ls_group-group_type. ls_modi_erfc-MODIFICATN = 'U'. INSERT ls_modi_erfc INTO TABLE lt_modi_erfc. * Get exisiting application servers in Logon/RFC server group * Sever Group Type * '' Logon Server Group * 'S' RFC Server Group CALL FUNCTION 'SMLG_GET_DEFINED_SERVERS' EXPORTING GROUPTYPE = ls_group-group_type GROUPNAME = ls_group-group_name TABLES INSTANCES = lt_del_server EXCEPTIONS no_group_found = 1 OTHERS = 2. * Change application servers in Logon/RFC server group. CALL FUNCTION 'SMLG_MODIFY' EXPORTING GROUPTYPE = lv_grouptype TABLES MODIFICATIONS = lt_modi ERFC_MODIFICATIONS = lt_modi_erfc EXCEPTIONS no_group_found = 1 OTHERS = 2. バッチサーバーグループの変更 バッチサーバーグループは、トランザクションコード SM61 で変更できます。 SAP Netweaver ABAP スタックには、これを表示および変更するための標準クラス CL_BP_SERVER_GROUP が用意されています。 変更が必要なグループに関する情報を取得するには、LOAD_DB メソッドを呼び出す必要があります。LOAD_DB メソッドは保護されたセクションとして宣言されているので、このクラスを継承した別のカスタムビジネスオブジェクト（CBO）クラスを作成します。 以下は、バックアグラウンド処理グループを変更するためのコード スニペットです。 クラス内の LOAD_DB メソッドと GET_LIST メソッドを呼び出して既存のアプリケーションサーバー リストを取得し、DEL_FROM_LIST メソッドを呼び出して既存のアプリケーションサーバー リストを削除し、ADD_TO_LIST メソッドを呼び出して新しいアプリケーションサーバーを登録します。 変更を確実に保存するには、SAVE_DB メソッドを呼び出します。 * /AWSSAMP/CL_MAZ_BP_GROUP Class Definition CLASS /AWSSAMP/CL_MAZ_BP_GROUP DEFINITION INHERITING FROM CL_BP_SERVER_GROUP. PUBLIC SECTION. METHODS : LOAD_SRV_LIST IMPORTING p_groupname TYPE char20, GET_SRV_LIST EXPORTING p_list TYPE BPSRVENTRY, DEL_FROM_SRV_LIST IMPORTING p_srv TYPE BPSRVLINE, ADD_TO_SRV_LIST IMPORTING p_srv TYPE BPSRVLINE, SAVE_SRV_LIST_DB. ENDCLASS * /AWSSAMP/CL_MAZ_BP_GROUP Class Implementation CLASS /AWSSAMP/CL_MAZ_BP_GROUP IMPLEMENTATION. * LOAD_SRV_LIST method to call LOAD_DB. To load a group information from DB. METHOD LOAD_SRV_LIST. TRY. CALL METHOD LOAD_DB EXPORTING i_name = p_groupname. CATCH CX_BP_HEALTH_DATA. MESSAGE 'Data Inconsistency Found.' TYPE 'E'. CATCH CX_UUID_ERROR. MESSAGE 'Error Class for UUID Processing Errors.' TYPE 'E'. ENDTRY. ENDMETHOD. * GET_SRV_LIST method to call LOAD_DB. To get servers for a list. METHOD GET_SRV_LIST. CALL METHOD GET_LIST RECEIVING o_list = p_list. ENDMETHOD. * DEL_FROM_SRV_LIST method to call DEL_FROM_LIST. To delete a server in a list. METHOD DEL_FROM_SRV_LIST. CALL METHOD DEL_FROM_LIST EXPORTING I_SRV_ENTRY = p_srv. ENDMETHOD. * ADD_TO_SRV_LIST method to call ADD_TO_LIST. To add a server in a list. METHOD ADD_TO_SRV_LIST. CALL METHOD ADD_TO_LIST EXPORTING I_SRV_ENTRY = p_srv. ENDMETHOD. * SAVE_SRV_LIST_DB method to call SAVE_DB. To save a list in a DB. METHOD SAVE_SRV_LIST_DB. TRY. CALL METHOD SAVE_DB. CATCH CX_BP_DATABASE. MESSAGE 'An Error Occurred While Attempting to Write to DB.' TYPE 'E'. ENDTRY. ENDMETHOD. ENDCLASS. ABAP プログラムを定期的に実行するバックグラウンドジョブを作成する トランザクションコード SM36 を使用してバックグラウンドジョブを作成すると、ABAP プログラム（ /AWSSAMP/MAZ_SOL ）を定期的（たとえば 5 分ごと）に実行できます。 ジョブの作成時に、 Edit > Start time メニューから実行間隔を設定できます。 図 7 : トランザクション SM36  のジョブ設定 上記の Multi-AZ ネットワーク最適化ソリューション は、1 時間以内に SAP シ ステムに適用し、テストすることができます。 また、 AWS SDK for SAP ABAP を使用して Amazon SNS サービスに通知を発行し、SAP チームに電子メールまたは SMS でアラートを通知する機能も含まれています。 まとめ 企業のビジネスプロセスの中核となる SAP ソリューションには、可用性と信頼性の高いアーキテクチャを用意することが重要です。そのため、AWS は、 SAP lens Well-Architected Framework – Select an architecture suitable for your availability and capacity requirements に従い、SAP アプリケーションを複数の Availability Zone にわたってアーキテクトすることを推奨しています。 SAP トランザクションとバッチジョブの最適なパフォーマンスを確保するために、データベースサーバーのフェイルオーバー時に SAP ログオングループ（トランザクション SMLG）、RFC サーバーグループ（トランザクション RZ12）、バッチサーバーグループ（トランザクション SM61）の自動切り替えを有効にすることができます。 これにより、パフォーマンスが重要なトランザクションとバッチジョブは、常にデータベースサーバーと同じ AZ のアプリケーションサーバー上で実行されます。 このブログでは、ビジネスクリティカルなトランザクションやバッチジョブの最適なパフォーマンスを確保しながら、マルチ AZ アーキテクチャで高可用性と高信頼性を実現するために、SAP for AWS のメリットをどのように活用できるかをご紹介しました。 詳細については、 Multi-AZ network optimized solution github page でサンプルコードをご覧ください。 何千ものお客様が AWS for SAP を選択する理由については、 AWS for SAP のページ をご覧ください。 SAP for AWS のディスカッションに参加する お客様のアカウントチームと AWS サポートチャネルに加えて、私たちは re:Post – A Reimagined Q&A Experience for the AWS Communityを立ち上げました。 弊社の AWS for SAP Solution Architecture チームは、AWS for SAP のトピックを定期的に監視し、お客様やパートナー様を支援するためのディスカッションや質問にお答えしています。 もしあなたの質問がサポートに関連したものでなければ、re:Post で議論に参加し、コミュニティのナレッジベースに追加することを検討してください。 翻訳は SAP Specialist SA 菅谷が担当しました。原文は こちら です。

はじめに アマゾン ウェブ サービス ジャパン（以下、AWS ジャパン）はファクトセット・パシフィック様（以下、FactSet ）との共催で 2024 年 11 月 19 日に、 資産運用会社向けイベントを開催しました。 本イベントでは、資産運用業務に携わる企業の方々 （ 96 名） にご参加いただき、データ活用及び生成 AI の最新情報を AWS ジャパン、お客様セッション、パートナーセッションを通じてご紹介いたしました。また資産運用業界内のネットワーキングを目的とした懇親会も実施しました。本記事では、イベント開催概要と当日の内容をご紹介いたします。 【開催概要】　　 開催日時： 2024 年 11 月 19 日（火） 開催場所： AWS ジャパン 目黒オフィス 参加者人数： 96 人 当日のアジェンダ 第一部をセミナー、第二部を懇親会と分けて開催いたしました。第二部の懇親会では登壇企業、参加者同士のネットワーキングを実施しました。 オープニング AWS ジャパン 金融事業統括本部 銀行営業本部長 金子 達也 イベント冒頭では、AWS ジャパン金融事業統括本部 銀行営業本部長 金子 達也より開会のご挨拶をいたしました。本イベント開催の目的について、資産運用業界のデータ駆動型意思決定の加速と共創の場（コミュニティ）の醸成、業界全体の成長促進であることを述べました。 最後に「 AWS は、データ分析および AI / ML 、生成 AI によりイノベーションを提供し、データ駆動型の意思決定を行う為の DX 推進をパートナーと共に支援します。また本イベントを通じて、資産運用業界のリーダーや革新的な企業と連携し、ナレッジシェアとベストプラクティス共有の場を作ることで、未来志向の解決策を共に模索することができ、持続可能な成長支援を行ってまいります」と結びました。 金融業界のイノベーションを支える AWS AWS ジャパン 金融事業開発本部長 飯田 哲夫 次に AWS ジャパン 金融事業開発本部長 飯田 哲夫が登壇し、クラウドにおけるデータ活用の広がりとして金融機関の事例を紹介し、資本市場を始めとした金融領域においてクラウドがビジネス変革を推進している要因について述べました。 資産運用業界では、データ・生成 AI の広がりとして、投資判断、運用アドバイスのパーソナライゼーション、アナリスト支援など、様々なユースケースが出てきており、金融サービスにビジネス価値をもたらしていることを解説しました。 また、AWS の活用は、責任共有モデルや第三者認証による評価からも安全なデータ管理の下で活用することができるため、AWS パートナーとの連携を通じて、業務のライフサイクル全体に渡ってご支援させていただくことについても紹介しました。 お客様、パートナーセッション お客様、パートナーセッションでは、ニッセイアセットマネジメント株式会社と FactSet 、株式会社ナウキャストの 3 社が登壇しました。 ニッセイアセットマネジメント株式会社 ニッセイアセットマネジメント株式会社 デジタルイノベーション・ヘッド 山田 智久氏 まずは、ニッセイアセットマネジメント株式会社デジタルイノベーション・ヘッドの山田 智久氏によるご登壇です。 生成 AI の活用として大きく 2 つの事例を発表いただきました。 1 つ目の事例は、 分析業務特化型 AI チャットボット です。投資先企業へのインタビューを行う前の調査業務を効率化するため、生成 AI （ Amazon Bedrock-Claude 3 Opus ）を活用した分析業務特化型 AI チャットボットを構築されました。これにより、統合報告書や ESG 関連書類からの情報抽出や、自社独自の評価観点に基づく情報整理などの分析作業効率が 3 ～ 5 倍に向上されたことや、利便性が認められ、他の運用部門への利用も拡大予定ということをお話いただきました。 2 つ目の事例は、自社ファンドへの投資を検討中の機関投資家などから会社概要やファンドの運用内容について照会を受け、回答を作成する Request for Proposal 業務（以下、RFP 業務）の改善に向けた取り組み事例 についてです。RFP 業務は処理すべき情報量が多いだけでなく、依頼元ごとにフォーマットや書き方が異なるため、資産運用会社にとって非常に業務負荷の高い作業です。そこで、RFP 業務の効率化を図るため、生成 AI（ Amazon Bedrock-Claude 3.5 Sonnet / Amazon Titan ）を活用し、担当部署の振り分け作業、回答作成作業の 2 つの業務で本格活用に向け PoC を開始しているとご説明されました。 また、事例とは別に、 資産運用会社同士で様々な業務への生成 AI 適用の検討を目的とした勉強会 を主催する取り組みについてもご発表いただき、複数社合同でナレッジ共有やディスカッションを通じて、生成 AI を活用したソリューションを具体的に検討していきたいと今後の展望についても語られました。 FactSet FactSet 日本アナリティクス担当ディレクター 若林大毅氏 続いては、FactSet 日本アナリティクス担当ディレクター若林大毅 氏にご登壇いただきました。 安全なデータプラットフォームの構築と、多様なデータの統合が重要な課題となっている状況下で、FactSet がどのように環境構築の支援を出来るかについてご説明いただきました。 FactSet の強みとして、 100 種類以上のデータセット や 80 以上のプロバイダー からのデータを統合し、 20 以上のカテゴリーのコンテンツ を保有し、資産運用の各種業務領域に求められるデータ統合、分析、配信を一気通貫で提供していることを挙げられました。さらに、API やデータ共有機能を使用することで、リアルタイムでのデータ更新や変換が可能となり、社内データと外部データをスムーズに統合することができるだけではなく、一般的なマーケットデータや企業独自のデータを統合する際にも、ポートフォリオの要因分析やシナリオ分析など、多角的な視点からデータを評価することができるようになることについてもご紹介いただきました。 また、昨今では FactSet の持つデータプラットフォームに生成 AI を連携させることで、異なる種類のデータの統合、分析、共有をより効率的に行うことができ、こうした強力なデータ管理体制と多様なデータ統合を実現することで、AI や ML 技術を活用した高度な分析環境の構築に繋がると述べました。 株式会社ナウキャスト 株式会社ナウキャスト データ & AI ソリューション事業責任者 片山 燎平氏 最後は、株式会社ナウキャスト データ & AI ソリューション事業責任者 片山 燎平氏によるご登壇です。 生成 AI を駆使し、 資産運用業務の効率化を目指した事例 、および 本格的な活用に向けたポイント についてご紹介いただきました。 生成 AI 活用事例のパートでは、3 つの事例についてお話いただきました。1 つ目は、膨大な決算短信・有価証券報告書から情報を抽出・要約する業務。2 つ目は、顧客専用の高精度書き起こしモデルを半自動で構築するサービスの提供。3 つ目は、JCB消費NOW における消費動向データに対し、LLM によるコメントレポートを生成する業務の試験的な導入についてです。 さらに、資産運用業務の効率化に向け生成 AI を様々にご活用いただく中で、企業における生成 AI の本格的な活用に向けたポイントとして ①埋め込み型のユースケース、②データ蓄積、③組織作り の 3 点が重要であると述べました。生成 AI がタスクをこなすために十分なデータを裏側で AI に与え、その機能を業務システムやサービスに埋め込むことで、シームレスに高付加価値の機能を利用することができます。それに伴い、これまで以上にデータ基盤構築の重要性が高まり、データを活用することができる組織作りが求められてくるとお話いただきました。 最後に「資産運用業界における生成 AI 技術は、単なる業務の自動化を超えて、より戦略的で価値の高い業務に集中できる環境を創出しつつあります。今後も、技術の進化と組織的なアプローチの深化が期待されます」と結びました。 ※JCB消費NOW： 株式会社ナウキャストが提供する匿名加工されたクレジットカード決済データをもとにした国内消費指数 懇親会 懇親会の様子 第二部の懇親会では、資産運用業務に携わる企業の方々とセッションに登壇いただいた方々によるネットワーキングを実施しました。この機会を通じて、普段は接点の少ない方々との意見交換が活発に行われ、新たなビジネスチャンスや関係性構築に繋がる可能性を秘めた有意義な時間となりました。 おわりに 本イベントを通じて、資産運用業務におけるデータ・生成 AI 活用がもたらす無限の可能性を目の当たりにしました。本イベントは、ご参加いただいた企業の皆様、そして共催の FactSet 様のご協力なくしては実現しませんでした。心より御礼申し上げます。今後も皆様に役立つ情報をセミナーやブログで発信していきます。どうぞよろしくお願い致します。

今日の世界では、サステナビリティ ( 持続可能性 ) があらゆる業界の企業の大きな関心事となっています。気候変動や天然資源の減少という課題に直面する中、組織にとって、環境への影響を減らすために積極的な措置を講じることは不可欠です。 廃棄物を削減 し、環境負荷を最小限に抑え、再生可能エネルギーへシフトすることで、私たちはサステナビリティを促進できます。これは、すべての人々と企業に関わる目標であり、より持続可能な未来を実現するための集団的行動の必要性を強調しています。 環境・社会・ガバナンス（ESG）投資は、より多くの投資家が財務リターンだけでなく、社会にポジティブな成果をもたらすことを求めるようになるにつれて勢いを増しています。この傾向は、より持続可能で責任ある事業慣行が企業の全体的なパフォーマンスとリスクプロファイルに関連しているという信念の高まりを反映しています。 特にコンタクトセンターは、データベースやコンタクトセンターソフトウェアをホストする専用のサーバー、コンタクトセンターの電話システム、エージェントのワークステーション、エージェントが所在する建物に電力を供給するためのエネルギー消費によって、カーボンフットプリントが大きくなります。したがって、コンタクトセンターソリューションを選択する際、 ESG 基準やより持続可能で責任ある事業を実施すれば、長期的な利益を得たり、企業の評判を向上させることができます。 このブログでは、 AWS が提供するフルマネージドでクラウドベースのコンタクトセンターサービスである Amazon Connect を使用してコンタクトセンター運用を構築するためのサステナビリティのベストプラクティスについて説明します。クラウドを活用し、リソース利用を最適化し、AWS のサステナビリティへの取り組みに沿うことで、組織がコンタクトセンター運用の環境への影響をどのように削減できるか説明します。 一般的なコンタクトセンター 論文 Markov Models and Their Use for Calculations of Important Traffic Parameters of Contact Center (Erik Chromy, Jan Diezka, Matej Kavacky) で示されている通り、従来のコンタクトセンターアーキテクチャは、通常、コンタクトセンター電話システム ( 構内交換機 (PBX) と自動着信呼分配 (ACD)) と、コンピュータ電話統合 (CTI) 、音声自動応答 (IVR) 、コールマネジメントシステム (CMS) 、音声録音 (VR) 、キャンペーンマネージャー (CM) などのコンタクトセンターシステムで構成され、これらはすべてデータセンターで稼働しています。さらに、ワークステーションと電話回線を備えたエージェントとスーパーバイザーの職場があります。 従来のコンタクトセンターのアーキテクチャ Markov Models and Their Use for Calculations of Important Traffic Parameters of Contact Center (Erik Chromy, Jan Diezka, Matej Kavacky) より引用 コンタクトセンターのデータベースやシステムをホストするデータセンターは、専用サーバーの電力供給、冷却、インフラストラクチャ、およびデータセンター運用に関連するその他の活動のためのエネルギー消費により炭素を排出します。電話の発信や受信のための PBX や IP-PBX システムを含むコンタクトセンターの電話システムも、そのエネルギー消費により炭素を排出します。アナログ PBX システムは、物理的なハードウェアと銅線配線の必要性により、通常より多くのエネルギーを使用し、 セットアップ の規模と複雑さに応じて 100W から 500W のエネルギー使用量となります。デジタルおよび IP-PBX システムはより省エネルギーで、エネルギー使用量は 50W から 200W の範囲です。 さらに、コンタクトセンターは通常、各エージェントに顧客とのやり取りを処理するための専用デスクトップコンピューターとモニターを提供しています。 Journal of Corporate Real Estate の Govil, M., & Panda, M. (2013) による「Sustainable Contact Centers: Strategies for reducing energy consumption and carbon emissions」によると、デスクトップ PC は 60W から 250W の電力を消費し、モニターはワークステーションの消費電力を 30% から 50% 増加させる可能性があります。 世界経済フォーラム の調査によると、世界のエネルギー関連の炭素排出量の 40% はコンタクトセンターのような施設を含む建物から発生しています。さらに、 従業員が集中型のコールセンターに通勤 することで、交通渋滞、炭素排出、大気汚染が増加しています。 Amazon Connect: サステナブルなコンタクトセンターソリューション 従来のオンプレミスのデータセンターで運用されるコンタクトセンターとは対照的に、Amazon Connect は AWS が提供するフルマネージドのクラウドコンタクトセンターサービスです。Amazon Connect のワークロードは、以下のレイヤーに分けることができます：電話、Amazon Connect インターフェース/API、コンタクトフロー/IVR、エージェントワークステーション、メトリクスとレポーティングです。これらは従来のコンタクトセンターにおける、CTI、IVR などのコンタクトセンターアプリケーションと対応しています。 Amazon Connect のアーキテクチャには、炭素の排出を削減できる複数のコンポーネントがあります。 Amazon Connect は、AWS の グローバルインフラストラクチャ 上で実行されるマネージドクラウドサービスとして、AWS クラウドのサステナビリティの利点を最大限に活用しています Amazon Connect は、同じ効率的なインフラストラクチャ上で実行されるマネージドな電話サービスを提供します。これにより、電話の発信と受信のための PBX や IP-PBX システムの必要性が排除され、それに伴う炭素排出量も削減されます WebRTC 通話により、PBX システムや専用のエージェントワークステーションが不要となり、コンタクトセンターのハードウェア要件が削減されます ブラウザベースのエージェントワークステーションにより、エージェントはコンタクトセンターのオフィスに集中する代わりに在宅勤務が可能になります エージェントがコンタクトセンターのオフィスに通勤する必要がなくなり、輸送による炭素排出量が削減されます。 Our World Data によると、自動車やバスを含む道路輸送は、世界の輸送による炭素排出量の 45.1% を占めています 効率的なインフラストラクチャと再生可能エネルギー AWS のインフラストラクチャ規模により、一般的なオンプレミスのデータセンターよりも高いリソース利用率とエネルギー効率が可能になります。最近の報告書「 How moving Onto the AWS Cloud Reduces Carbon Emissions (AWS クラウドへの移行による炭素排出量の削減 ) 」によると、AWS のインフラストラクチャはオンプレミスと比較して最大 4.1 倍効率的であり、AWS 上でワークロードが最適化された場合、関連するカーボンフットプリントを最大 99% 削減できると推定されています。 また AWS は冷却効率を継続的に革新し、時期に応じて異なる冷却技術を使用し、リアルタイムのセンサーデータを活用して変化する気象条件に適応しています。2019 年、Amazon（AWS を含む）は、2030 年までに消費する電力の 100% を再生可能エネルギーで賄うという野心的な目標を設定しました。Amazon は 7 年早く 2023 年にこの目標を達成し、Amazon が消費する電力の 100% を再生可能エネルギー源で賄っています。 よりサステナブルなコンピューティングと AI AWS クラウドへの移行により炭素排出量が削減される という調査結果にあるように、人工知能 (AI) は世界最大の課題に取り組むためのテクノロジーの使用方法を急速に変革しています。AI の利用拡大と同時に、その環境への影響を最小限に抑えることが重要です。AWS が委託し Accenture が実施した調査によると、AI ワークロードのカーボンフットプリントを削減する効果的な方法は、オンプレミスのインフラストラクチャから世界中の AWS データセンターに移行することです。 Amazon Connect は、顧客とのインタラクションのあらゆる段階に AI を組み込んでいます。顧客の声を認識し、顧客が何について電話をしているかを理解し、生身のエージェントの代わりに AI が顧客に対応したり、顧客との会話を分析して顧客の問題を見つけ出し、顧客の感情を認識したりします。Amazon Connect は、リアルタイムの通話分析や通話後のサマリーを行う Contact Lens や、生成 AI エージェントアシストとしての Amazon Q in Connect など、顧客とのインタラクションに生成 AI 機能を組み込んでいます。 これらの複雑な AI、特に生成 AI ワークロードの実行に関して、AWS は幅広いハードウェアの選択肢を提供しています。パフォーマンスとエネルギー消費を最適化するために、 AWS Inferentia2 のような 目的に特化したチップ を開発しました。これは、同等の EC2 インスタンスと比較して最大 50% エネルギー効率が高くなっています。AWS が AI 向けのより効率的なハードウェアへの投資を続けるにつれて、Amazon Connect のお客様は個別の努力を必要とせず、自動的に効率性の向上の恩恵を受けることができます。 クラウドのサステナビリティに関わるベストプラクティス Amazon Connect のクラウドサステナビリティの利点を活用することに加えて、組織は Amazon Connect ベースのコンタクトセンターアーキテクチャを最適化することで、サステナビリティ効果を最大限に享受できます。 AWS Well-Architected Framework の持続可能性の柱は、最適化のための 6 つの重要な領域に焦点を当てています：コンタクトセンターを配置するリージョン、需要に合わせた調整、ソフトウェアとアーキテクチャ、データ、ハードウェアとサービス、開発とデプロイメントプロセスです。これらの重要な領域におけるベストプラクティスに従うことで、コンタクトセンターはリソースの無駄を減らし、利用率を最大化し、運用をサポートするために展開される総コンポーネントを最適化することで、クラウドフットプリントを最小限に抑えるのに役立ちます。 より持続可能な地域に業務を誘導する Amazon Connect の導入において、組織はビジネスの優先事項とサステナビリティの目標の両方に基づいてリージョンを選択すべきです。ビジネスの優先事項、コンプライアンス、レイテンシー、コスト、顧客とエージェントの所在地、サービスの可用性に基づいて、選択可能なリージョンを検討します。 AWS のブログ記事「 How to Select a Region for Your Workload Based on Sustainability Goals (サステナビリティの目標に基づいてワークロードのリージョンを選択する方法) 」では、Amazon Connect で適切な AWS リージョンを選択するためのマーケットを起点に考える方法と場所を起点に考える方法について説明しています。マーケットを起点とする方法では Amazon の再生可能エネルギープロジェクト の近くにあるリージョンを選択できますし、場所を起点とする方法では公表されている 電力消費に対する炭素強度が低い リージョンを選択できます。 ユーザーの行動に合わせた調整 このサステナビリティのベストプラクティスは、実行される活動に使用されるリソースを最適化することに関するものです。使用されるリソースは、ユーザーの需要に応じて規模を調整する必要があります。 Amazon Connect では、ユーザーがコンタクトセンターに電話をかけたり、その他の方法で対話したりすると、需要に基づいてスケールアップ・スケールダウンし、過剰なプロビジョニングを回避します。 さらに、顧客は Amazon Connect で一般的な クラウドコンタクトセンターのアーキテクチャ を最適化して、自社のコンタクトセンターのニーズに合わせることができます。 設計時に、コンタクトセンターソリューションに必要のないサービスを削除することで、実行されるサービスが少なくなり、消費エネルギーが減少します。例えば、ソリューションにテキスト読み上げ機能が不要な場合、Amazon Polly を除外することで、このサービスに関連するエネルギー消費と炭素排出を削減できます。さらに、ソリューションにアウトバウンドキャンペーンが含まれていない場合、設計時に Amazon Pinpoint をアーキテクチャから除外できます。メールが不要な場合は、Amazon Simple Email Service についても同様です。 Amazon Connect 自体においても、 Cases 、 Tasks 、 Contact Lens 、 予測、キャパシティプランニング、スケジューリング などのオプション機能は、顧客のソリューションで必要とされない場合は有効化されません。機能が有効化されていなければ、実行されず、エネルギーを使用せず、炭素排出も発生しません。 Amazon Connect コンタクトセンターアーキテクチャの主要コンポーネントは、サーバーレスコンピューティングサービスである AWS Lambda を使用しています。AWS Lambda 関数はトリガーされた時のみ実行され、アイドル状態のリソースを回避します。上記のアーキテクチャ図のように、このサービスは効率を最適化するイベント駆動型アーキテクチャのために Amazon Kinesis や Amazon Lex などの他のサーバーレステクノロジーを活用しています。 AWS Lambda は、関数に割り当てられたメモリ量に比例して中央処理装置 (CPU) パワー、ネットワーク帯域幅、ディスク入出力を割り当てることでサステナビリティをサポートしています。必要な時のみコードを呼び出し、受信リクエストの割合に応じて自動的にスケールします。これにより、ワークロードの環境への影響を効果的に最適化し、最小限に抑えることができます。 データ Amazon Connect は最近、 ゼロ ETL 分析データレイクの一般提供 を発表しました。 この機能 により、複雑なデータパイプラインの構築と維持が不要になります。分析データレイクでは、レコードが重複排除されるため、保存するデータ量が少なくなり、使用するリソースも少なくて済みます。 AWS は、お客様がデータ管理戦略を最新化できるようにするツールとガイダンスを提供しています。これには、AWS のフルマネージド型のストレージサービスを使用して、アクティブな「ホット」データと非アクティブな「コールド」データセットを分離して保管することが含まれます。さらに、AWS はお客様のデータレプリケーションプロセスを最適化し、レプリケーションのサイズとスループット要件を削減することで、エネルギー消費と炭素排出量の削減を支援します。 従来のコンタクトセンターと Amazon Connect の比較概要 要素 従来のコンタクトセンター Amazon Connect インフラストラクチャ オンプレミスデータセンター、PBX システム AWS クラウドインフラストラクチャ エネルギーの効率性 低い効率性、高い排出量 最大4.1倍の効率性 拡張性 過剰にプロビジョンされうる固定されたインフラストラクチャ 実際の利用に基づいた柔軟なスケーリング 必要なハードウェア 専用のサーバーやワークステーション、電話 ブラウザベース、WebRTC による通話 リモートワークの可能性 限定的 完全にサポート通勤やビルによる排出量の削減 結論 この記事では、最適なサステナビリティの実践方法について議論し、お客様がカーボンフットプリントを削減できる Amazon Connect クラウドベースのコンタクトセンターを構築する方法を示しました。管理されたインフラストラクチャ、最適化されたハードウェア、サーバーレステクノロジー、再生可能エネルギーの組み合わせにより、現在そして将来にわたって、より低いカーボンフットプリントで優れた顧客体験を提供するための、より持続可能な基盤が提供され、結果としてより持続可能な顧客体験につながります。 さあはじめましょう: コンタクトセンターのカーボンフットプリントを評価し、クラウドと Amazon Connect がどのようにそれを削減できるか探りましょう コンタクトセンターを Amazon Connect に移行し、AWS で最適化を行った場合、ワークロードのカーボンフットプリントを最大 99% 削減できる可能性があります Amazon Connect の導入をサステナビリティを考慮して設計しましょう。ワークロードの配置、ユーザー行動との整合性、サーバーレスアーキテクチャ、データと利用率に関するベストプラクティスの推奨事項に従いましょう AWS および Amazon Connect チームと協力 して、組織の環境目標により適合した、より持続可能なコンタクトセンターソリューションの構築方法についてさらに議論しましょう これらのステップに従うことで、コンタクトセンターをよりサステナブルに、エネルギー効率が高く、環境に優しい運用に変革することができます。 Amazon Connect でカスタマーサービス体験を変革する準備はできましたか？ お問い合わせください 筆者について Nada Reinprecht は AWS のシニアソリューションアーキテクトで、業界を超えて革新的な技術ソリューションを作り出し、お客様の複雑なビジネス課題を解決することに情熱を注いでいます。AWS に入社する前は、Accenture や IBM などで働き、オーストラリア、米国、ヨーロッパ、英国のお客様向けにソリューションの設計と提供を行っていました。Nada はブッシュウォーキング、ヨガ、ランニングが大好きです。 Mike Cairns は AWS のシニアソリューションアーキテクトで、多様な業界にわたる複雑なビジネス課題を解決するための革新的なクラウドベースのソリューションの設計と実装の経験があります。彼は AWS サービスに関する深い技術的専門知識を活かし、組織のインフラストラクチャの近代化、運用効率の向上、新しいビジネス機能の開拓を支援しています。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

皆様、こんにちは。AWS Game Solutions Architect の篠原 聡志です。今回は、アプリストアを介さない独自の課金システムの実装方法について、モバイルゲームを題材に決済サービスの一例として Stripe を活用した実装例をご紹介します。Stripe を活用することで、複雑な決済処理をオフロードし、開発者側の負担を軽減することができます。このブログでは、モバイルゲームという実用的な例を通じて、Stripe を用いたストア外・アプリ外決済の実装方法を詳しくご紹介します。 背景 アプリストアの手数料体系と規制緩和の動きが、アプリ開発者とユーザーに大きな影響を与えています。Apple App Store や Google Play Store では、アプリの売上の 15%～30% がプラットフォーム手数料として徴収されてきましたが、近年 EU や米国を中心に外部決済サービスの利用を認める規制緩和が進んでいます。日本でも 2024年6月に「 スマートフォンにおいて利用される特定ソフトウェアに係る競争の促進に関する法律 」（通称、「スマホソフトウェア競争促進法」）が成立したことがあり、日本でもアプリ外・ストア外課金が広まっていくものと推測されています。この変化により、開発者は収益を増やし、ユーザーはより多様な決済オプションを得られる可能性が出てきました。ストア外・アプリ外課金には、開発者とユーザーの双方にとって重要なメリットとデメリットがあります。 メリット 開発者向け: 手数料の削減：プラットフォームへの 15〜30% の手数料が不要となり、収益性が大幅に向上します 価格設定の自由度：プラットフォームの価格テーブルに縛られず、柔軟な価格設定が可能になります 決済手段の多様化：クレジットカード、銀行振込、コンビニ決済など、これまで課金することができなかったユーザーに対して多様な決済手段を提供できます ユーザー向け: 価格低下：決済手数料が上乗せされない分安価にサービスが利用できます 決済手段の多様化：クレジットカード、銀行振込、コンビニ決済など、多様な決済手段を利用でき、ポイントバックなどの決済手段が提供する恩恵を受けることができます デメリット 開発者向け: 導入の複雑さ：自社で決済システムを構築・運用する必要があり、初期コストと運用コストがかかります セキュリティリスク：決済情報の管理や安全性確保の責任が開発者側に生じます ユーザー離脱のリスク：外部サイトへの遷移が必要なため、ユーザーが離脱する可能性があります ユーザー向け: 利便性の低下：アプリ内でワンタッチで完結していた決済が、外部サイトへの遷移を必要とするため、やや煩雑になります セキュリティへの不安：慣れ親しんだプラットフォームを介さない決済に不安を感じる可能性があります このようなメリットから、日本でもストア外・アプリ外課金を実装するゲームが増えていますが、デメリットにあるように独自環境故の課題についても注意が必要です。続いて、既存のゲームにストア外・アプリ外課金を実装する方法をご紹介します。 Stripe とは Stripe（ストライプ）はオンラインで完結できる決済サービスで、さまざまな業種で利用されています。本ブログで紹介するソリューションは決済サービスとして Stripe を利用することで複雑な決済処理を Stripe 側にオフロードすることでアプリ外決済基盤の構築を容易にしています。 Stripe を利用するメリット Stripe は Amazon EventBridge との連携に対応しており、AWS 上で構築するアプリ外決済基盤に対して決済情報を安全に連携することが可能です。 Stripe 側の設定でイベントの送信先に Amazon EventBridge を選択することができます。 日本国内ではポピュラーなクレジットカード・コンビニ決済・銀行振込などの決済方法が利用可能です。また、海外での決済にも対応しており、その国で多く使われている決済方法を利用できるようにすることでゲームの国際展開をサポートすることが可能です。詳しくは Stripe – 日本での決済:徹底ガイド 及び ビジネスに適した Stripe の決済手段 をご覧ください。決済手数料については Stripe 公式ページ をご覧ください。 実装方法 ストアを通さない課金の実装方法には、主に2種類あります： アプリケーション組み込み型: アプリ内でシームレスにストア外決済を実行 ストアを通じた配信が制限されるため、独自に公式サイトなどからの配信が必要 外部ストアページ連携型: アプリ外部のストアページで有償通貨を購入 既存のゲームワークロードに追加しやすい スマホソフトウェア競争促進法では、他の課金システムを利用することを妨げてはならない旨の記載がある一方、ウェブサイトからアプリを直接ダウンロードできるようにすることまでの義務付けが無いため、本記事では後者の外部ストアページ連携型について詳しく説明します。 モバイルゲームを題材としたストア外・アプリ外課金アーキテクチャ紹介 それでは、ここからはストア外・アプリ外課金の実際の実装のイメージを掴むためにモバイルゲームを題材とした AWS と Stripe を組み合わせるためのアーキテクチャを見ていきましょう。 以下が外部ストアページ連携型の基本的なアーキテクチャです。Amazon DynamoDB を一時的な課金情報のストアとして利用し、Amazon DynamoDB Streams による AWS Lambda の実行でゲーム内に課金情報を反映します。ゲーム内有償通貨付与の際は Amazon DynamoDB の付与済フラグを確認することでべき等性を担保しています。 基本的なアーキテクチャは以下の通りです： ユーザーがスマートフォンでストアページにログインします。 ログインにはゲーム内ユーザーIDを用います。 Stripe を通じて商品を購入します。 購入の際に Idempotent requests (べき等なリクエスト) を利用することで商品の重複購入を防ぐことができます。詳しくは API リクエストのベストプラクティス を御覧ください。 Stripe からの決済成功イベント( checkout.session.completed )が Amazon EventBridge に通知されます。 Amazon EventBridge のフィルタで checkout.session.completed が検知され、 AWS Lambda が実行されます。 下記は AWS Lambda を呼ぶ際の Event の一部です。 { "oblect":{ "client_reference_id": "123456789", # ユーザー ID "created": 1732268759, "customer_details": { "email": "hogehoge@fugagufa.hoge", "name": "SATOSHI SHINOHARA", }, "metadata": { "item_id": "1111", # ユーザーが購入したアイテムの ID }, "payment_intent": "pi_XXXXXXXXXXXXXXXXXXXXXX", "status": "complete", } } Amazon EventBridge は AWS Lambda 関数を呼び出し、決済成功のレコードを Amazon DynamoDB に一時保存します。 Amazon DynamoDB のテーブルは後述のゲームへの有償通貨付与方法にてご紹介します。 Amazon DynamoDB にデータが書き込まれると、Amazon DynamoDB Streams がトリガーされます。 Amazon DynamoDB Streams によって起動された AWS Lambda 関数が、課金情報を確認し、ゲームへの付与フラグがないことを確認します。 AWS Lambda 関数は対象のユーザー ID に対してゲーム内の状態を管理する Amazon Aurora の UserDB に対してゲーム内有償通貨を付与します。 同様に AWS Lambda 関数から課金履歴を管理する課金 DB と課金情報を永続管理する Amazon S3 に課金ログを保存します。 本アーキテクチャは一般的なゲームアーキテクチャと連携できるように汎用的な構成をしております。有償通貨を付与し課金 DB や課金ログに書き込みを行う AWS Lambda をカスタマイズすることで、Apple App Store や Google Play Store のフォーマットと合わせることができ、既存の課金 DB や課金ログとの結合が容易です。一方、ゲーム内の状態を管理するの UserDB は払い戻しの観点から Apple App Store と Google Play Store で購入した有償通貨を別々に保存するのと同様にストア外課金用のカラム追加が必要な点には注意してください。 ゲームへの有償通貨付与方法 ゲームへの付与方法は、既存のゲーム処理に合わせて選択することをおすすめします： Amazon DynamoDB Streams 方式 ゲームクライアントが API を実行する度にゲーム内有償通貨を取得する場合に適しています。この方式はリアルタイムでの通貨付与が可能ですが、ゲームクライアントとサーバー間でのデータ整合性に注意が必要です。 購入情報が Amazon DynamoDB に書き込まれると、Amazon DynamoDB Streams がトリガーされます。 トリガーされた AWS Lambda 関数が実行されます。 購入情報からゲーム内への付与状態を確認します。 ゲームのユーザー DB に有償通貨を付与します。 Amazon DynamoDB に付与済フラグを設定します。 Amazon DynamoDB のテーブルは下記となります。 user_id: PK。ゲーム内のユーザーを識別する ID stripe_pi: SK。決済を識別する Stripe の Payment Intents item_id: 購入したアイテムの ID name: 決済時に入力された氏名 email: 決済時に入力されたメールアドレス created_datetime: Stripe 側で記録された決済時間 distributed_datetime: ゲーム内にアイテムが付与された時間＋一定期間。TTL が設定されており一定期間経過したレコードは削除される。付与済フラグとしても利用する distributed_datetime に Time to Live(TTL) を設定することで、付与が完了したレコードを一定期間保持の後に削除し、Amazon DynamoDB のコストを削減しています。 ゲームサーバ駆動型 ゲームログイン時や特定のイベント（例: ゲーム内ストアページへの遷移）のみ有償通貨を取得する場合に適しています。この方式は特定のタイミングで複数の課金情報をまとめて処理できるためシステム負荷を軽減しやすく、ゲームクライアントとサーバー間でのデータ整合性を保ちやすいという利点があります。 ユーザーがゲームへのログインやゲーム内ストアページへの遷移を行います。 ゲームサーバが Amazon DynamoDB にゲーム内未反映の課金情報があるかを確認します。 未反映の課金情報がある場合、ゲームサーバがユーザー DB に有償通貨を付与します。 Amazon DynamoDB に付与済フラグを設定します。 Amazon DynamoDB のテーブルは Amazon DynamoDB Streams 方式と同様です。 まとめ Stripe を活用したストア外・アプリ外決済の実装により、アプリデベロッパーは収益を増やし、ユーザーには多様な決済オプションを提供することができます。ただし、実装には慎重な設計と、既存のゲームシステムとの整合性を考慮する必要があります。 本記事が、皆様のアプリ開発の一助となれば幸いです。 著者 篠原 聡志 ゲーム企業を経て AWS に入社。主にゲーム業界のお客様を担当しています。好きな AWS サービスは Amazon Bedrock、Amazon S3 です。趣味はリズムゲームと VR ゲームです。

2024 年 11 月 22 日より、クロスゾーン負荷分散を有効にした Application Load Balancer (ALB) の Amazon Application Recovery Controller (ARC) ゾーンシフト サポートを発表しました。これは、 以前に発表された クロスゾーン負荷分散を使用する Network Load Balancer (NLB) のサポートを補完するものです。ゾーンシフトは、クロスゾーン負荷分散が設定されているかどうかに関係なく、NLB と ALB の両方で使用できるようになりました。また、 Amazon EC2 Auto Scaling グループ (ASG) や Amazon Elastic Kubernetes Service (EKS) などの他のリソースでもゾーンシフトを使用できます。ブログ記事 「単一の アベイラビリティゾーンでのアプリケーション障害からの迅速な復旧」 では、ゾーンシフトの仕組みと、クロスゾーン負荷分散が無効になっている場合の関連するベストプラクティスの概要が説明されています。この記事では、クロスゾーン負荷分散を有効にした状態でゾーンシフトを使用する場合の運用上のベストプラクティスを紹介します。 概要 ALB または NLB のゾーンシフトの使用を開始するには、ロードバランサーの zonal_shift.config.enabled 属性を true に設定する必要があります。クロスゾーン負荷分散を使用する NLB では、target_health_state.unhealthy.connection_termination.enabled が false に設定されていることも確認する必要があります。この機能を有効にすると、1 つのアベイラビリティーゾーン (AZ) で障害が発生していることが判明したときに、ゾーンシフトを開始して影響を軽減できます。 ゾーンシフトは、クロスゾーン負荷分散が有効になっている場合、2 つのアクションを実行します。はじめに、指定された AZ のロードバランサーノードの IP アドレスが DNS から削除されるので、新しいクエリがそのエンドポイントで解決されなくなります。これにより、今後クライアントリクエストがそのノードに送信されなくなります。次に、他の AZ のロードバランサーノードに、障害のある AZ のターゲットにリクエストをルーティングしないように指示します。図 1 に示すように、ゾーンシフト中も残りの AZ ではクロスゾーン負荷分散が引き続き使用されます。 図 1 – AZ 1 でゾーンシフトが有効なクロスゾーン負荷分散を使用する Application Load Balancer AZ 障害が発生している間は、ロードバランサーの背後にある ASG のゾーンシフトを実行することもできます。ゾーンシフト中に 異常のあるインスタンスを置き換える ように ASG を設定した場合、障害のある AZ ではインスタンスが終了し、他の AZ では新しいインスタンスが起動されることがあります。また、EC2 Auto Scaling がゾーンシフト中にアプリケーションをスケールアウトし、影響を受けていない AZ で新しいインスタンスを起動する可能性もあります。これにより、AZ 間でキャパシティのバランスが崩れる可能性があります。 AZ 障害が復旧したと判断したら、シフトをキャンセルして AZ へのトラフィックをリバランスすることができます。クロスゾーン負荷分散は、ロードバランサーのゾーンシフトを終了するとターゲットごとに受信されるトラフィックの全体的な割合が減少するため、キャパシティが不均衡になった場合にリバランスをより安全に行うのに役立ちます。これは、図 2 に示すように、ロードバランサーがターゲットグループの各ターゲットにトラフィックを均等に分散するためです。 図 2 – クロスゾーン負荷分散が有効化された Application Load Balancer これとは対照的に、クロスゾーン負荷分散を無効した状態では、トラフィックが各 AZ に均等に分散されます。その後、ロードバランサーはそのゾーン内の利用可能なターゲットにリクエストを分散します。AZ 間のキャパシティの不均衡により、ロードバランサーのゾーンシフトを終了した後に、特定のインスタンスが他のインスタンスよりも多くの負荷を受ける可能性があります。これにより、過負荷が発生し、アプリケーションに影響が及ぶ可能性があります。たとえば、図 3 は AZ 2 のインスタンスが AZ 1 と AZ 3 のターゲットの約 2 倍のトラフィックを受信している様子を示しています。この構成では、target_group_health.dns_failover.minimum_healthy_targets.count を使用して、十分な数の正常なホストが利用できるようになるまで AZ がトラフィックを受け入れないようにすることが重要です。 図 3 – クロスゾーン負荷分散が無効化された Application Load Balancer クロスゾーン負荷分散は、ALBではデフォルトで有効であり、NLBでもオプションで有効にできます。これにより、ALB ターゲットグループの構成を大幅に変更しなくても、ゾーンシフトを活用できます。ALB の ゾーンオートシフト をデフォルト設定でオプトインすることもできます。AWS は、お客様に影響を与える可能性のある AZ 障害が社内のテレメトリで示されたときに、オートシフトを開始します。ゾーンオートシフトは、 加重ランダム ルーティングアルゴリズムと組み合わせて使用できます。これにより、イベント発生時の復旧時間を最小限に抑えることができ、ゾーンシフトの活用に必要な追加のオブザーバビリティが軽減されます。 単一 AZ の影響に対応するには、ゾーンオートシフトと自動ターゲットウェイト (ATW) の異常緩和が推奨されますが、これらのツールでは特定のインフラストラクチャにおけるグレー障害やシングル AZ アプリケーションの障害を検出できない場合があります。たとえば、ある特定の AZ にデプロイされたバグを含むアプリケーションデプロイや、少数のインスタンスに影響する少量のパケットロスによってアプリケーションエラーが発生し始めた場合などです。このような状況を検出するには、追加のオブザーバビリティを開発する必要があるかもしれません。次のセクションでは、クロスゾーン負荷分散を有効にして 単一AZ の障害を検出する方法を調べます。 クロスゾーン負荷分散を有効にしたゾーンシフトの AZ オブザーバビリティ リクエスト数、障害率、AZ ごとのレイテンシーなどのメトリクスを監視することは、AZ で障害が発生している可能性があるタイミングを判断するための前提条件であり、潜在的な影響を安全に軽減することができます。次の 3 つのシグナルは、ゾーンシフトをいつ使用するかを判断するのに役立ちます。 可用性またはレイテンシーへの影響を示す AZ ヘルスメトリクス あるAZ が、他の AZ と比較して、障害率またはレイテンシの点で外れ値である 障害率または高レイテンシーが、複数のインスタンスで発生している それでは、各 AZ におけるアプリケーションの状態に関するメトリクスの収集を開始する方法を見てみましょう。 AZ ヘルスメトリクスの作成 レジリエンスのためのオブザーバビリティのベストプラクティス の1つは、合成カナリアを使って顧客体験をモニタリングすることです。これらは早期警告の指標として機能するので、顧客に気づかれる前に問題を自分自身に知らせることができます。 「単一アベイラビリティーゾーンでのアプリケーション障害からの迅速な復旧」 の投稿では、図 4 に示すように、Amazon CloudWatch Synthetics を使用して ALB と NLB の ゾーンエンドポイント をモニタリングし、AZ ごとのメトリクスを生成しました。 図4 – 各 AZ の Application Load Balancer エンドポイントに対して実行される合成カナリア クロスゾーン負荷分散を有効にした場合でも、シンセティックは引き続きベストプラクティスです。ただし、ALB や NLB について各ゾーンのエンドポイントをテストしても、どの AZ のターゲットからも応答が得られる可能性があるため、それほど有用ではありません。代わりに ALB の場合は、 ALB ロードバランサーの Amazon CloudWatch メトリクス を使用して、特定の AZ のターゲットで障害率やレイテンシーが上昇しているタイミングを特定できます。 ALB ターゲットメトリクス には、2XX、3XX、4XX、5XX のカウントと TargetResponseTime のメトリクスがあります。これらのメトリクスはすべて、レスポンスを生成したターゲットの AZ を表す メトリクスディメンション として AvailabilityZone を備えています。 NLBの場合、 ターゲットメトリクス はほとんどがレイヤー4の情報であるため、アプリケーションの状態の変化を判断するのがより難しい場合があります。TCP_Target_Reset_count メトリクスをアプリケーションの正常性の代用として監視することもできますが、それでもまだ不十分な場合があります。NLB またはそのターゲットグループでクロスゾーン負荷分散が有効になっている場合は、ターゲットの AZ をメトリクスディメンションとして提供するカスタムサーバーサイドメトリクスを利用する必要があります。これを実現する方法の詳細については、 「カスタムメトリクスの公開」 と 「CloudWatch 埋め込みメトリクス」 を参照してください。 ロードバランサーの UnhealthyHostCount ターゲットメトリクスをモニタリングすることもできます。AZ 障害が原因でターゲットのヘルスチェックが不合格になった場合、これはその影響を直接示しています。このメトリクスに自動的に対応するには、NLB または ALB ターゲットグループの target_group_health.dns_failover.minimum_healthy_targets.count 属性を使用できます。これにより、正常なホストが少なすぎる場合に、ロードバランサーが AZ から自動的に移動するようになります。 ALB メトリクスまたはカスタムサーバーサイドメトリクスのいずれかを使用して、各 AZ の影響を警告する CloudWatch アラームを作成できます。この例では、クロスゾーン負荷分散を有効にした ALB メトリクスを使用しています。ターゲットからのレイテンシーが特定のしきい値を超えたとき、またはアベイラビリティが指定された値を下回ったときにアラームがトリガーされるように設定しています。 レイテンシーアラームは以下のメトリクスを利用します（図5）： 図5 – 目標応答時間メトリクスを使用して AZ ごとにレイテンシーアラームを定義する また、可用性アラームはメトリクス計算を使用して AZ の障害率を決定します （図6）： 図6 – AZ ごとの可用性アラームを定義するためのロードバランサー障害率の決定 最後に、図 7 に示すように、単一の AZ における可用性またはレイテンシーの影響を特定するように CloudWatch 複合アラームを設定します。 図7 – 障害率またはレイテンシーへの影響に関する CloudWatch 複合アラーム定義 次に、同じ ALB メトリクスを使用して各 AZ 間の障害率とレイテンシーを比較し、1 つの AZ がいつ外れ値になるかを調べます。 外れ値検出の実行 あるAZ がヘルスメトリクスの外れ値である場合は、その 障害分離境界 に問題があることを示す良い指標になります。 カイ二乗検定 や、 標準得点 、 四分位範囲 (IQR) 、 中央絶対偏差 (MAD) など、さまざまな外れ値検出アルゴリズムを使用してヘルスメトリクスを比較できます。もっと簡単に始めるには、66% のような静的な値を使用する方法があります。つまり、ある AZ が全故障の 66% を占めていれば、それは外れ値とみなされます。 図 8 は、メトリクス計算を使用して計算された CloudWatch メトリクス e1 を示しています。これにより、単一の AZ (この場合は us-east-1b) 全体の障害の割合が決定されます。このメトリクス値が 0.66 より大きい場合にアラームを設定できます。 図8 – ある AZ に属する障害の割合を決定する外れ値検出用メトリクスの作成 レイテンシーについては、データポイントにおける標準偏差を決定するために標準得点を使用します。正規分布データの 99.7% は標準偏差が3以内であるため、値が3を超えると値が外れ値であることを示します。この計算では p99 のレイテンシーを調べ、この AZ と比較している他の 2 つの AZ の平均値を使用して ( Metrics () 関数を使用 )、外れ値のレイテンシーが標準偏差を歪めないようにしています。図 9 は CloudWatch メトリクスの計算を使用した計算を示しています。このメトリクスが 3 を超えた場合のアラームを設定できます。 図9 – あるAZ におけるレイテンシーの標準得点を用いた外れ値検出 複数インスタンスによる影響の特定 ターゲットがヘルスチェックに失敗した場合、UnhealthyHostCount ターゲットメトリクスは、影響が複数のインスタンスによって引き起こされているかどうかを確認するのに役立ちます。構造化された CloudWatch ログを作成している場合は、 CloudWatch Contributor Insights を使用することもできます。このサービスは、インサイトルールの UniqueContributors メトリクスを使って、アプリケーションの障害やレイテンシーの原因となった要因を特定するのに役立ちます。図 10 は、Contributor Insights メトリクスの計算を使用した CloudWatch メトリクスの例を示しています。 図10 – あるAZ における障害の要因の数を算出するためのContributor Insights を使用した CloudWatch メトリクス このメトリクスに値が 1 を超えた場合のアラームを設定して（フリートのサイズによってはもっと大きい数値を使用することもできます）、複数のインスタンスでエラーが発生していることを示すアラームを設定できます。 すべてをまとめる これで、単一 AZ の影響の特定に役立つ 3 つの条件のアラームが表示されるようになりました。 特定の AZ における可用性またはレイテンシーの影響 特定の AZ が障害やレイテンシーにおいて外れ値となっている 複数のインスタンスで問題が発生している 最後の CloudWatch 複合アラーム ( 図 11 参照 ) では、これらの各アラームからの信号を組み合わせて、ゾーンシフトを使用して対応できる単一AZ の影響が発生したことを通知します。 図11 – 単一 AZ の影響を決定するための CloudWatch 複合アラームの定義 これらのAZごとのアラームをダッシュボードに追加して、運用担当者が単一 AZ の障害をすばやく特定できるようにすることもできます（図12）。 図12 – あるAZ で問題が検知されたことを示す CloudWatch ダッシュボード 結論 この投稿では、クロスゾーン負荷分散を有効にした状態でゾーンシフトがどのように機能するかを確認しました。また、単一の AZ でアプリケーションの状態への影響を監視するための運用上のベストプラクティスについても紹介しました。ゾーンシフトまたはゾーンオートシフトを開始するには、Amazon Application Recovery Controller の ドキュメント をご覧ください。 著者について Michael Haken Michael は AWS Strategic Accounts チームのシニアプリンシパルソリューションアーキテクトであり、お客様のイノベーション、ビジネスの差別化、カスタマーエクスペリエンスの変革を支援しています。15 年以上にわたり、金融サービス、公共部門、デジタルネイティブの顧客をサポートしてきました。Michael はバージニア大学 (UVA) で学士号を、ジョンズ・ホプキンス大学でコンピューターサイエンスの修士号を取得しています。仕事以外では、彼は農場で家族や犬と遊んでいます。 翻訳はソリューションアーキテクトの松本が担当しました。原文は こちら です。

航空業界において効率的な手荷物追跡システムは不可欠であり、乗客の所持品を適時かつ完全な状態で配送するのに役立ちます。手荷物の取り扱いと追跡の誤りは、フライトの遅延や乗り継ぎの欠航から、荷物の紛失や顧客の不満まで、一連の複雑な問題を引き起こす可能性があります。このような混乱は航空会社の評判を損ない、重大な財務的損失をもたらす可能性があります。 そのため、航空会社は正確で効率的、かつ信頼性の高い手荷物追跡システムの開発と導入に多大なリソースを投じています。これらのシステムは、ほぼリアルタイムでの手荷物位置情報の更新を通じて顧客満足度を向上させ、定時出発をサポートするために運用ワークフローを最適化するのに役立ちます。 手荷物追跡システムの重要な役割は、パッケージを効果的に追跡し、業務をデジタル化し、再ルーティングが発生したとしても是正措置を効率化する能力にあります。このシステムは、フライトの円滑な運用、乗客の満足度、および荷物の配布のタイムリーな管理を維持するための鍵となっています。 従来の手荷物追跡プロセス 手荷物追跡システムは、チェックインされた手荷物が航空会社と空港のインフラ内をどのように移動するかを監視するため、手動および自動のバーコードスキャンを使用します。手荷物追跡システムは、航空会社が提供する製品やサービスをサポートするため、図1に示されているように、複数の機能に細分化することができます。 図1手荷物追跡システムに求められる要件(ハイレベル） 手荷物の追跡は、顧客のチェックインから始まり、いくつかの段階を経て進行します。チェックインでは、バーコードまたは無線自動識別（RFID）技術を使用して、手荷物にタグが付けられ、乗客と関連付けられます。その後、手荷物は適切なピアまたはバッグステーションに仕分けられ、搬送されます。 仕分けゲートウェイは、TCP/IP、HTTP、または独自のメッセージングプロトコルを使用してバックエンドシステムと通信します。手荷物はまず保管場所である「バッグルーム」に運ばれ、その後空港スタッフによって航空機に積み込まれる「ピアエリア」に移動します。場合によっては、手荷物は航空機内のコンテナに仕分けられます。 航空機が目的地に到着すると、手荷物は機内から下され、手荷物受取所または次のフライトへと搬送されます。受け取られなかった手荷物は、必要に応じて手荷物サービスオフィスエリアへと移動されます。 このプロセス全体を通じて、正確でほぼリアルタイムの追跡を実現するため、各段階で手荷物のスキャンが行われます。手荷物の取り扱いを誤ったり、紛失したりした場合、この追跡情報が手荷物の回収に不可欠となります。 図2 従来の手荷物追跡システムアーキテクチャ 図2に示されているように、従来の手荷物追跡アーキテクチャは、RESTフレームワークまたはSOAPプロトコルのいずれかで実装される、アプリケーションプログラミングインターフェース（API）を広範に活用しています。ほとんどの航空会社がバックエンドとしてメインフレームを利用しているため、APIの使用には2つの主要な経路があります：メインフレームへの直接的なデータ送信、またはリレーショナルデータベースの更新です。 別個のオフラインプロセスがデータを取得して処理し、その後、他のAPIやメッセージキュー(MQ)を通じてメインフレームに送信します。デバイス情報を受信した場合、通常その情報は限定的であり、その情報をメインフレームに送信するために追加の呼び出しを調整する別のバックグラウンドプロセスが必要となる場合があります。 このような動きにともないフェイルオーバが発生した場合には人が介入する余地があり、サービス中断が発生する可能性があります。 モダナイズの必要性 従来の手荷物追跡システムは、以下の重要なビジネス上および技術上の課題により、大きく妨げられています： オンサイトおよびオンプレミスのインフラストラクチャにおける、大量の手荷物追跡データとテレメトリに対するスケーラビリティの欠如。 不規則な運航（IROPS）時におけるデータ量の急増への対応の課題。 バッグルーム、受取所エリア、ピアエリア、出発スキャンなど、空港内のネットワークの接続性に関する懸念。 ミッションクリティカルなシステムの継続性に影響を与える必要なレジリエンスの欠如。 モビリティデバイスに関連する手荷物追跡の規制要件の変更に迅速に適応できない。 キオスク、仕分けゲートウェイ、セルフサービス手荷物預け入れ、ベルトローダー、固定リーダー、アレイデバイス、IoTデバイスなどのシステムとの統合による包括的な追跡とデータ収集。 グローバルオペレーターの運用効率を阻害し乗客体験に影響を与えるレイテンシーの問題。 追跡デバイスの監視と保守の不足により、運用の中断とダウンタイムが発生する可能性。 サイバーセキュリティの脅威とデータプライバシーに関する懸念。 手荷物追跡データのほぼリアルタイムインサイトの欠如。これにより、情報に基づく意思決定と運用の最適化が妨げられる。 手荷物追跡システムのモダナイズは、航空会社にとって、これらの課題に対処するために極めて重要です。スケーラビリティ、信頼性、セキュリティを維持しながら、運用効率と乗客満足度を向上させることができます。先進的な技術を取り入れることで、航空会社は急速に進化する業界において競争力を維持し、成長をサポートする態勢を整えることができます。 ソリューション 図3は、従来の手荷物追跡プロセスにおける課題に対する解決策を示しています。 スキャナー、ベルトローダー、センサーなどのデバイスは、それぞれのデバイスゲートウェイと通信を行います。これらのゲートウェイは、効率的な通信とテレメトリのために、AWS IoT CoreとMQTTプロトコルを介してAWSクラウドに接続し、通信を行います。このデザインでは、特にネットワークの帯域幅と接続性が制限された環境において最適なパフォーマンスを提供できるため、MQTTを使用しています。 AWS IoT Greengrass エッジゲートウェイは、デバイス間およびシステム間通信のためのオンサイトメッセージング、ローカルデータ処理、エッジでのデータキャッシングをサポートしています。このアプローチにより、レジリエンス、ネットワークレイテンシー、ネットワーク接続性が向上します。これらのゲートウェイは、ローカル通信用のMQTTブローカーを提供し、必要なデータとテレメトリをクラウドに送信します。 AWS IoT Coreは、バックエンドシステムへのタイムセンシティブな配信よりも、信頼性の高いデータ配信が重要なシナリオで特に有用です。さらに、デバイスシャドウのような機能を提供しており、これによってダウンストリームシステムは、デバイスが切断されている場合でも、デバイスの仮想表現と対話することができます。デバイスが接続を回復すると、デバイスシャドウは保留中の更新を同期します。このプロセスにより、接続が不安定な場合の動作が解決されます。 AWS IoTルールエンジンは、AWS Lambda、Amazon Simple Storage Service（Amazon S3）、Amazon Kinesis、Amazon MSKなどの必要な送信先にデータを送信することができ、必要なデバイスのテレメトリデータと手荷物追跡イベントは、ほぼリアルタイムでのデータのストリーミングと一時的な保存のためにAmazon MSKへ、テレメトリデータの長期保存のためにAmazon S3へ、そして低レイテンシーイベントへの対応のためにLambdaへと送信されます。 このイベント駆動型アーキテクチャは、信頼性が高く、レジリエンシーがあり、柔軟で、ニアリアルタイムのデータ処理を提供します。必要な回復力を提供するために、AWS IoT CoreとAmazon MSKは複数のリージョンにわたって展開されています。また、Amazon MSKは Kafka MirrorMaker2 を使用して、リージョンのフェイルオーバー時の信頼性を向上させ、ダウンストリームのコンシューマーのオフセットを同期します。 手荷物追跡データは、中央の手荷物取扱いデータストアに保存される必要があります。これにより、ダウンストリームアプリケーション、レポーティング、高度な分析機能をサポートします。必要なテレメトリデータを取り込むために、このソリューションではLambdaを使用して、それぞれのMSKトピックをサブスクライブし、スキャンを処理してからAmazon DynamoDBにデータを取り込みます。DynamoDBは、ほぼゼロのRPO（目標復旧時点）とRTO（目標復旧時間）を必要とするマルチリージョンのミッションクリティカルなアーキテクチャに理想的です。 手荷物の積み込み時、ベルトローダーやハンドヘルドスキャナーなどのデバイスは、最小限のレイテンシーで双方向通信を必要とすることが多くあります。同様のIoTデバイスにデータを配信する必要がある場合、Lambdaは直接AWS IoT Coreにメッセージを配信することができます。 大量のデバイステレメトリと手荷物追跡データを収集するにあたり、このソリューションではAmazon S3Intelligent-Tieringを使用して、安全かつコスト効率よくこのデータを保存します。また、固定リーダー、ベルトローダー、ハンドヘルドスキャナーのほぼリアルタイムのデバイス分析を生成するために、AWS IoT AnalyticsとAmazon QuickSightを使用します。 図3に示されているように、このソリューションはAWS IoT Coreからの受信MQTTデータストリームを収集、処理、分析し、目的に特化したタイムストリームデータストアに保存するサービスも使用します。Amazon AthenaとAmazon SageMakerは、さらなるデータ分析と機械学習（ML）処理に使用されます。Amazon Athenaは、複雑なデータインフラストラクチャや管理を必要とせずに、標準SQLを通じて大規模なデータセットのアドホック分析とクエリに使用されます。Amazon SageMakerとの統合により、手荷物追跡のためのMLモデルを便利に開発することができます。 おわりに 本記事では、AWS IoT、Amazon MSK、AWS Lambda、Amazon S3、Amazon DynamoDB、およびAmazon QuickSightを使用することで、航空会社は従来のシステムの制限に対処する、スケーラブルで回復力があり、安全な手荷物追跡ソリューションを実装できることについて説明しました。AWSサービスを活用した近代化されたソリューションは、ほぼリアルタイムの追跡を確保し、正確な追跡、取り扱いミスの削減、紛失手荷物の効率的な回収を通じて、運用効率と乗客体験を向上させます。さらに、サイバーセキュリティの脅威、データプライバシーの懸念、規制コンプライアンスに対処しながら、情報に基づく意思決定と運用の最適化のためのデータ分析とレポートを可能にします。 このソリューションのコンポーネントについてさらに詳しく知るには、参考文献のセクションをご覧ください。また、お客様のビジネスの加速化についてご相談させていただくには、 AWS トラベル＆ホスピタリティコンピテンシーパートナー をご覧いただくか、AWSの担当者までお問い合わせください。 さらに詳しく知るには？ AWS for Travel and Hospitality IBM Travel and Transportation IBM Consulting on AWS Modernize Baggage Acceptance Messaging with Enhanced Efficiency and Security Use MSK Connect for managed MirrorMaker 2 deployment with IAM authentication Amazon Managed Streaming for Apache Kafka Best Practices Deploy a predictive maintenance solution for airport baggage handling systems with Amazon Lookout for equipment How to implement a disaster recovery solution for IoT platforms on AWS How to Eliminate the Need for Hardcoded AWS Credentials in Devices by Using the AWS IoT Credentials Provider How to Use Your Own Identity and Access Management Systems to Control Access to AWS IoT Resources IBM Consulting は、AWSプレミアティアサービスパートナーとして、お客様がAWSを活用してイノベーションの力を引き出し、ビジネス変革を推進することを支援しています。彼らは、トラベル＆ホスピタリティコンサルティングを含む17以上のコンピテンシーにおいて、グローバルシステムインテグレーター（GSI）として認められています。詳細については、IBMの担当者まで お問い合わせください 。 翻訳はソリューションアーキテクトの矢形が担当しました。原文は こちら です。 著者一覧 Neeraj Kaushikは、IBMのオープングループ認定ディスティングイッシュアーキテクトで、クライアント対応の職務において20年の経験を持っています。彼の経験は、旅行・運輸、銀行、小売、教育、医療、人身売買防止など、複数の業界にわたります。信頼されるアドバイザーとして、クライアントの経営陣やアーキテクトと直接協力し、技術ロードマップを定義するためのビジネス戦略に取り組んでいます。実践的なチーフアーキテクトとしてAWSプロフェッショナル認定ソリューションアーキテクトおよび自然言語処理の専門家として、複数の複雑なクラウド近代化プログラムとAIイニシアチブを主導してきました。 Venkat Gomathamは、AWSのシニアパートナーソリューションアーキテクトとして、AWSシステムインテグレーター（SI）パートナーの卓越を支援しています。彼は20年以上にわたりITアーキテクトおよび技術者として働き、イノベーションと変革をリードしてきました。AWSではモノのインターネット（AWS IoT）分野の主題専門家（SME）および技術フィールドコミュニティ（TFC）メンバーとして、自動車およびAI/MLの専門性を持って活動しています。 Subhash Sharmaは、AWSのシニアパートナーソリューションアーキテクトです。彼は、マイクロサービス、AI/ML、モノのインターネット（IoT）、およびブロックチェーンをDevSecOpsアプローチで活用し、分散型で、スケーラブルで、高可用性があり、セキュアなソフトウェア製品の提供において25年以上の経験を持っています。余暇には、家族や友人と過ごしたり、ハイキングをしたり、ビーチを散歩したり、テレビを見たりすることを楽しんでいます。 Vaibhav Ghadageは、IBMのAWS ITスペシャリストで、現在IBM Consultingで働いています。彼はAWSプロフェッショナル認定ソリューションアーキテクトであり、主にクラウドに焦点を当てて活動しています。

航空会社の予約、フライト追跡、リワードプログラム、手荷物追跡、機内エンターテインメントなどの重要な機能を扱うアプリケーションは、乗客の航空旅行体験を変革しています。これらのアプリケーションに障害が発生すると、乗客に不便をもたらすだけでなく、最悪の場合、収益と乗客の信頼を失うことにもなりかねません。大幅な遅延につながる障害が発生した場合、航空会社に対してペナルティが科される可能性もあります。 航空会社のアプリケーションをクラウドに移行することで、スケーラビリティの向上と災害復旧能力の強化により、システム障害を軽減することができますが、クラウド運用の管理には課題が伴う場合があります。これらの課題には、クラウドコンピューティングスキルの不足、レガシーシステムとの統合、旧式のインシデント管理プロトコル、オンプレミスインフラへの依存、そして旧式の監視ソリューションの使用といった要因が含まれます。 このブログでは、ある大手航空会社がクラウド運用を改善するために、ミッションクリティカルなアプリケーションを AWS Incident Detection and Response (IDR) に移行した方法について説明します。 AWS incident Detection and Responseとは？ AWS Incident Detection and Responseは、重要なワークロードに対してプロアクティブな対応とインシデント管理を提供します。AWS Incident Detection and Responseでは、AWSインシデント管理エンジニア（IME）が24時間365日体制でワークロードを監視し、インシデントを検知し、AWSサポートの専門家と連携して、問題の緩和と復旧に向けたガイダンスを提供します。 Observabilityの向上 ：アプリケーション層とインフラストラクチャ層の間で適切な可観測性を確保し、ワークロードの障害を検知できるようにします。 より迅速な解決 ：アラーム発生から5分以内にAWSインシデントマネージャーと連携し、事前に定義された対応計画に基づいてインシデントを管理することで、復旧を加速します。 AWSで発生するイベントのインシデント管理 ：AWSサービスイベントに関する最新情報、影響の見通し、および軽減計画の実装に関するガイダンスを提供します。 要害発生頻度の低減 ：復旧を加速するだけでなく、過去のインシデントから得られた教訓をランブック、可観測性、対応計画の改善に活かすことで、継続的な改善のメカニズムを提供し、障害の可能性を低減します。 どのようにIDRはアプリケーションのレジリエンスを向上するか？ インフラストラクチャの近代化イニシアチブの一環として、この航空会社は複数年にわたるクラウド移行の取り組みを開始しました。このイニシアチブの一環としてクラウドに移行されたアプリケーションの1つが、滑走路状態報告（FICON）アプリケーションでした。FICONは、パイロットと運航計画担当者に滑走路の状態に関する情報を提供します。このアプリケーションの可用性への影響や復旧の遅延は、フライトの遅延を引き起こし、航空会社の運航と乗客に直接的な影響を及ぼします。 FICONは、ほぼゼロの目標復旧時間（RTO）を持つグランドストップアプリケーションです。移行の一環として、この航空会社は、クラウド環境でのアプリケーションの可観測性の設定、重大なインシデントへの迅速な対応、そしてチームの復旧をガイドするためにアプリケーションのコンテキストを理解している専門家へのアクセスが必要でした。 これらのニーズに対応するため、お客様はアプリケーションをAWS Incident Detection and Responseに移行することを決定しました。移行プロセスは、信頼性と運用の優位性についてアプリケーションを評価することから始まりました。AWSの専門家は航空会社のアプリケーションチームと協力して、システムのアプリケーション層とインフラストラクチャ層全体の可観測性を向上させるための主要な性能指標を特定し、インシデント発生時に警告するためのAmazon CloudWatchアラームを作成しました。また、重大なインシデント発生時のエスカレーション用にアプリケーション担当者のリストを含むランブックも作成されました。 AWS Incident Detection and Responseは、可観測性の向上と早期インシデント検知を通じて、FICONアプリケーションの運用効率を向上させました。5分以内の応答時間は、厳格な目標復旧時間（RTO）とデータ復旧時点の目標（RPO）を考慮した航空会社のグランドストップアプリケーションにとって重要でした。AWS Incident Detection and Responseは、重大なインシデントに対する平均対応時間（MTTE）と平均復旧時間（MTTR）を改善しました。 運用の優位性における改善を示す事例として、FICONアプリケーションのAmazon CloudWatchアラームが作動しました。このアラームは、API Gatewayがリクエストを中継してからバックエンドからレスポンスを受信するまでの時間である、Amazon API Gateway統合レイテンシーを監視していました。アラームに応答して自動的にサポートケースが作成され、アラーム作動から2分以内にインシデントマネージャーが対応を開始しました。 インシデントマネージャーは会議ブリッジを開始し、航空会社とAWSチームとの共同トリアージとインシデント解決を促進しました。AWS Lambdaサポートチームが会議セッションに参加し、ログを確認した結果、AWS Lambdaが同時実行制限に達していたことを特定しました。エンジニアは迅速にLambdaの同時実行制限を引き上げて問題を解決しました。統合された監視と自動化された対応ワークフローにより、プロアクティブな対応と迅速な問題緩和が可能となりました。インシデント解決後、AWSインシデントマネージャーは、問題の原因と再発防止のための推奨事項を含む事後インシデントレポートを共有しました。推奨事項には、プロビジョニングされた同時実行性の有効化とLambdaの同時実行制限を監視する新しいCloudWatchアラームの作成が含まれていました。チームはまた、検知を改善するためのアラームのしきい値に関する推奨事項を提示し、それに応じてランブックを更新しました。 IDRは実際にどのような対応がなされるか？ 以下に示すように、AWS Incident Detection and Responseとの統合設定は、既存のアーキテクチャを変更する必要がありません。アプリケーションパフォーマンスモニタリング（APM）ツール（Amazon CloudWatch、Datadog、New Relicなど）からアラームを取り込むために、AWS Health Service Linked Roleへのアクセスを提供するだけで、AWS Incident Detection and Responseとの統合を簡単に設定できます。 アラームが発生した場合、AWS Incident Detection and Responseの自動化システムはAmazon Event Bridgeを通じてアラームを取り込み、AWSインシデントマネージャーとの連絡のために、お客様のアカウントでサポートケースを作成します。また、AWSサービスイベントに関する通知のため、お客様のアカウントのAWS Personal Health Dashboardも更新されます。AWS Incident Detection and Responseは、サードパーティのAPMから直接、またはWebhookを介してイベントの取り込みをサポートしています。AWS Incident Detection and Responseでワークロードを設定する方法の詳細については、AWS Incident Detection and ResponseユーザーガイドのGetting Startedセクションを参照してください。 AWS Incident Detection and Responseとシステムの連携 おわりに AWS Incident Detection and Responseは、チケット発券、手荷物取扱い、航空運航、空港運営、乗務員管理などの分野における重要なアプリケーションのインシデント管理プロセスを改善することができます。厳格なRPO（目標復旧時点）とRTO（目標復旧時間）の要件を持つアプリケーションは、このプロアクティブな対応から恩恵を受けることができます。ミッションクリティカルなシステムに影響を与える問題を適時に特定し、修復することで、運用の中断とお客様への影響を最小限に抑えることができます。 詳細については、 AWS Incident Detection and Responseユーザーガイド をご覧いただくか、AWSのアカウント担当者にお問い合わせください。 翻訳はソリューションアーキテクトの矢形が担当しました。原文は こちら です。 Naseer Sayyad Naseer Sayyadは、Amazon Web Servicesのシニアテクニカルアカウントマネージャーです。NaseerはAWSのエンタープライズ顧客と協力し、クラウド変革の過程で成功を収められるよう支援しています。クラウドコンピューティングと自動化に情熱を注いでおり、仕事以外では旅行と写真撮影を楽しんでいます。 Neel Sendas Neel Sendasは、Amazon Web Servicesのプリンシパルテクニカルアカウントマネージャーです。Neelは企業のお客様と協力して、ビジネス目標を達成するためのクラウドアプリケーションの設計、導入、スケーリングを支援しています。また、機械学習にも熱心で、製造業や物流業界向けの様々な機械学習のユースケースに取り組んできました。顧客支援以外の時間には、ゴルフとサルサダンスを楽しんでいます。 Temitope Baiyewu Temitope Baiyewuは、Amazon Web Servicesのシニアプロダクトマネージャーです。TemiはAWS Incident Detection and Responseの製品開発を主導しており、顧客がAWS上で重要なワークロードをより効率的に運用できるよう支援することに情熱を注いでいます。Temiは読書が大好きで、チェルシーFCの熱烈なファンです。

ライアンエアー（欧州最大の航空会社で1日3,330便以上を運航）は、2034年までに旅客数を2倍に増やす計画を立てています。そのため、最前線のスタッフに効果的な業務遂行に必要なツールを提供することが不可欠です。最近、Amazon Web Services (AWS)と協力して、新しい客室乗務員向けアプリを開発しました。 複雑なスケジューリングの課題 ライアンエアーは90以上の拠点に客室乗務員を配置し、欧州全域で1日最大3,300便を運航しています。客室乗務員は4人1組のチームで働き、自身の拠点で1日を始め終えます。通常のシフトでは最大800人の乗客をライアンエアーの便でお迎えします。 乗務員のスケジューリングは本社の運航計画チームが管理し、航空機の定時運航と各シフト終了時の乗務員の帰還を確実にする任務を担っています。訓練、休暇、天候による混乱などを考慮すると、スケジューリングがいかに複雑になるかがわかります。 ライアンエアーの事業規模が拡大し続けるにつれ、計画チームには最新の計画ツールを提供する必要があります。これにより、乗務員のスケジュール管理に必要な手作業のプロセスを削減できます。これまで客室乗務員は、スケジュール変更を要求する際にチケットを提出し、長い待ち行列で待つ必要がありました。運航チームは平均して月に8,000件ものシフト交代のリクエストだけを手作業で処理していました。 Working Backwardsアプローチ AWSでは、最も効果的な解決策は「Working Backwards(顧客の課題やニーズから逆算する)」ことで生み出されると考えています。そのため、ライアンエアーのようなお客様にAmazonの物流センターの見学や、エグゼクティブ向けブリーフィング、ビジョン策定ワークショップなどに参加していただき、同様のアプローチを体験していただいています。 ライアンエアーは2017年からAWSと協力関係を築いており、従業員アプリのインスピレーションは、ティルベリーにあるAmazonの物流センターの見学から得られました。見学中、物流と航空会社における複雑な業務での人員管理の類似点が明確になり、ライアンエアーチームは、Amazonのスタッフが従業員用モバイルアプリを使って仕事と生活をどのように管理しているかを体験しました。 「Amazonの従業員アプリを見たとき、私たちの乗務員にもこれが必要だと直感しました！」- ライアンエアー機内サービス部門ディレクター シネード・クイン 見学の後すぐに、ライアンエアーとAWSのチームは、Amazonの「Working Backwards」手法を用いて、客室乗務員のための革新的なソリューションについてブレインストーミングを行いました。ライアンエアーの機内サービス部門と人事部門は、AmazonのPeople Experience and Technology Solutions（PXT Solutions）チームと協力し、グローバルとローカルの両レベルでの人員管理の方法を検討し、ライアンエアーに最適なソリューションを見出しました。 構想から実現まで、PXT SolutionsチームのAmazonのプロダクトマネージャーとライアンエアーチームの間で継続的な連携が行われました。Amazonは、グローバルな従業員への変更展開や、組織全体でのオーナーシップ提供に関する自社の経験を共有しました。 2023年9月、シネード・クインのビジョンは、Ryanair Connectの立ち上げとして実現しました。このアプリは、ライアンエアーの客室乗務員が手のひらで簡単に仕事と生活を一元管理できるツールです。導入から4週間以内に、Ryanair Connectはライアンエアーの90以上の拠点と15,000人の客室乗務員に採用されました。 ライアンエアーのプロダクトマネージャー、ジョナサン・ドックレルは次のように語っています。「私の役割は、先を見通すことです。エンドユーザー（客室乗務員）や開発チームと密接に協力しながら、インパクトのある製品に仕上げていくプロセスを楽しんできました。以前に同様の経験をしたAmazonのプロダクトマネージャーにアクセスできたことが、このローンチの成功につながりました！」 Ryanair Connectは、AWSのサーバーレスサービスを使用して構築されており、数千人の客室乗務員からの需要に効率的に対応できるよう拡張可能です。イベントベースのアーキテクチャを採用し、ライアンエアーの基幹システムと統合されています。アクセスはAWS WAFとAWS Shield Advancedで保護されています。 客室乗務員の活躍を支えるRyanair Connect Ryanair Connectにより、客室乗務員は自分のスケジュールとフライトの詳細をほぼリアルタイムで確認できるようになりました。また、年次休暇やシフト交代のリクエストもより便利に行えるようになりました。 フライトスケジュールを予定通りに実施するため、予期せぬ事態に対応できるよう各シフトには常に待機中の客室乗務員がいます。ライアンエアーの運航チームは、その日に必要な待機乗務員の人数を確実に把握しています。待機中の乗務員は、アプリを使って待機勤務から外れることを申請でき、ビーチで過ごしたり家族と時間を過ごしたりすることができます。 おわりに Ryanair Connectアプリの成功を受けて、客室乗務員たちはさらなる革新を求めています。そこでライアンエアーチームは、客室乗務員の体験をさらに向上させ、業務を簡素化するためのロードマップを作成しました。この新しいロードマップには、生成AIの力をどのようにRyanair Connectに活用し、さらなる機能強化を図るかという検討も含まれています。 従業員が成長できるような適切なツールを提供し、企業文化を作ることは、多くの組織が目指す目標ですが、それを実現することは容易ではありません。ライアンエアーは2017年からAWSと協力関係を築き、信頼に基づいた強固な関係を発展させてきました。この協力を通じて、ライアンエアーは自社のビジネスの仕組みと将来の展望を共有してきました。 そして、AmazonとAWSは、150万人以上の従業員を抱えるまでに成長した経験から得た知見を共有しました。ライアンエアーが2034年までに3億人の旅客数を目指す中で、私たちは協力して、現在そして将来の従業員のニーズに応えるアプリを作り上げることができました。 AWSのクラウドサービスやソリューションを活用して従業員や顧客の体験を向上させる方法については、 AWS トラベル＆ホスピタリティ をご覧ください。 ビジネスの加速についてご相談は、AWSの担当者までお問い合わせください。 翻訳はソリューションアーキテクトの矢形が担当しました。原文は こちら です。 Shane Routley シェーン・ラウトリーは、AWSのシニアカスタマーソリューションズマネージャーとして、UKI（英国およびアイルランド）地域のエンタープライズ顧客のクラウド導入を支援しています。20年にわたるIT変革と製品管理の経験を持ち、顧客がビジネス価値を生み出すテクノロジーソリューションを提供できるよう支援しています。テクノロジーサービス、ヘルスケア、FMCG（日用消費財）業界での経験を持ち、現在は英国を拠点としています。

このブログでは、Java Messaging System (JMS) 2.0 API を使って書かれたプロデューサクライアントアプリケーションを使用して、Amazon MQ の ActiveMQ ブローカーの トランザクション機能 について説明します。JMS 2.0 API は使いやすく、前のバージョンに比べてインターフェースが少なくなっています。ActiveMQ の JMS 2.0 サポートの詳細に関しては、 ActiveMQ の JMS2.0 に関するドキュメント を参照してください。また、 JMS 2.0 の新機能 も合わせてご確認ください。 Amazon MQ は ActiveMQ 5.18 をサポートするようになりました。また、Amazon MQ では新しいセマンティックバージョニングシステムが導入され、マイナーバージョン (例: バージョン5.18) を表示し、同一のマイナーバージョン内の新しいパッチ (例: バージョン5.18.4) でブローカーを最新の状態に保つことができます。ActiveMQ 5.18 は、JMS 2.0、Spring 5.3.x のサポートと、いくつかの依存関係の更新とバグ修正が加えられています。詳細については、Active MQ 5.18.x リリースシリーズの リリースノート を参照してください。 概要 分散システムにおけるメッセージングパターン メッセージブローカーベースの分散メッセージングにメッセージングサービスを実装する多くの場合、発信と受信を切り離すファイア・アンド・フォーゲットメカニズムが伴います。このとき、プロデューサはメッセージをブローカーに送信し、ブローカーがコンシューマーへのメッセージ配信を保証する責任があります。非トランザクションの利用事例では、各メッセージは互いに独立しています。ただし、時にはメッセージのグループを 1 つのトランザクションの一部としてコンシューマーに配信する必要があります。つまり、グループ内のすべてのメッセージがコンシューマーに配信されるか、またはそれらのメッセージが全く配信されないかのいずれかを意味します。 ActiveMQ 5.18 では、JMS トランザクションと XA トランザクションの 2 つのレベルのトランザクションサポートを提供しています。 JMS トランザクションは、複数のメッセージをアトミックな単位として ActiveMQ ブローカーに送信する必要がある場合に使用されます。このトランザクション機能は、Session(JMS 1.xの場合)またはJMSContext(JMS 2.0の場合)オブジェクトでcommit()およびrollback()メソッドを呼び出すことで有効になります。すべてのメッセージが正常に送信された場合、commit() メソッドによってトランザクションをコミットし、メッセージがユニットとして処理されることを保証できます。また、送信プロセス中に問題が発生した場合は、rollback() メソッドによってトランザクションをロールバックして、メッセージの部分的な配信を防ぐことができます。このようなトランザクション機能は、データの整合性を維持し、複雑なメッセージング操作が確実に実行されるために重要です。トランザクションの動作の詳細については、 ActiveMQ FAQ – トランザクションの動作方法 を参照してください。 XA トランザクションは、2 つ以上のメッセージを ActiveMQ ブローカーと その他の分散リソースに対してトランザクション方式で送信する必要がある場合に使用されます。これは XA リソースとしてはたらく XA セッションを使って実現されます。XA トランザクションの詳細については、ActiveMQ FAQ の Should I use XA transactions FAQ を参照してください。 注文管理システムにおけるトランザクション利用事例 このブログ記事の例では、メッセージの受け渡しを管理するソフトウェアである「メッセージブローカー」として ActiveMQ を使用した Order Management System (OMS) アプリケーションのトランザクション機能について説明します。受注時に、OMS アプリケーションはメッセージ 1 をウェアハウスキューに送信してパッキングプロセス(商品の梱包作業)を開始します。次に、アプリケーションは内部の業務処理を実行します。このプロセスが成功した場合、アプリケーションはメッセージ 2 を出荷キューに送信して配送プロセス(商品の出荷作業)を開始します。内部の業務処理が失敗した場合、メッセージ 2 が出荷キューに配信されるのを防ぎ、メッセージ 1 をウェアハウスキューからロールバック(取り消し)する必要があります。 下のフローチャートは、この例で紹介しているトランザクション利用事例のロジックを示しています。 トランザクション利用事例を説明するフローチャート JMS クライアントは、トランザクションが commit または rollback されるまで、メッセージを両方ともメモリ内に保存します。これは、メッセージプロデューサークライアントとブローカー間のトランザクションセッションを維持することで実現されます。トランザクションセッションとは、メッセージ配信を保証するためにトランザクションを使用するセッションのことです。この例では、トランザクションセッションが次の文で作成されています。 JMSContext jmsContext = connectionFactory.createContext(adminUsername, adminPassword, Session.SESSION_TRANSACTED); この記事のサンプルでは、メッセージプロデューサーとブローカー間でのトランザクションセッションを示しています。ブローカーとメッセージコンシューマー間のトランザクションは示していません。開発者の皆様は、同様のパターンを使って実装できます。 ActiveMQ ブローカーの作成 Amazon MQ で ActiveMQ ブローカーを作成するには、以下の前提条件が必要です。 前提条件: AWS コマンドラインツール (CLI) をインストールします。 Java 11 以上 をインストールします。 AWS CLI を AmazonMQFullAccess 権限が付与された IAM プリンシパル (ユーザー/ロール) で設定します。 ブローカーを作成する (AWS CLI): 次のコマンドを実行して、ブローカーを作成します。これは、テスト専用の公開ブローカーを作成します。本番環境用のブローカーを作成する場合は、 Amazon MQ のセキュリティベストプラクティス を遵守してください。 aws mq create-broker \ --broker-name \ --engine-type activemq \ --engine-version 5.18 \ --deployment-mode SINGLE_INSTANCE \ --host-instance-type mq.t3.micro \ --auto-minor-version-upgrade \ --publicly-accessible \ --users Username =,Password =,ConsoleAccess = true <broker-name> はブローカーに付けたい名前に置き換えてください。 <username> と <password> は create-broker CLI ドキュメント に従って置き換えてください。コマンドを実行すると、コマンドラインにBrokerArn と BrokerId が出力されるので、その値をメモしてください。ブローカーの作成には約 15 分かかります。 次のコマンドを実行して、ステータスを取得します。 aws mq describe-broker --broker-id --query 'BrokerState' ブローカーの状態が Running になれば、次に進んでください。 次のコマンドを実行して、コンソール URL とその他のブローカーエンドポイントを取得します。 aws mq describe-broker --broker-id --query 'BrokerInstances[0]' 出力から ConsoleURL と SSL エンドポイントをメモしてください。 メッセージプロデューサークライアントの設定 このブログのサンプルコードでは、JMS 2.0 API を使って書かれた サンプルのメッセージプロデューサクライアント を使用して、ActiveMQ ブローカーにメッセージを送信しています。 トランザクションが成功した場合、プロデューサークライアントはメッセージを最初のキューに送信し、15 秒待機します。次に、メッセージを 2 番目のキューに送信し、さらに 15 秒待機します。最後に、トランザクションをコミットします。 トランザクションが失敗した場合、プロデューサークライアントは最初のメッセージを送信し、15 秒待機します。次に、コードで意図的な失敗を発生させ、トランザクションをロールバックさせます。15 秒の待機時間があれば、プログラムがトランザクション フローを進めている間にブローカー側のメッセージ数を確認できます。成功したトランザクションの場合でも、プロデューサーがコミットするまではメッセージはブローカーに送信されません。 サンプルクライアントをダウンロードして設定するには: Amazon MQ トランザクションサンプル Jar を GitHub リポジトリの指定のリンクから Jar ファイルをダウンロードします。 サンプルクライアントを実行するには、jar ファイルにカプセル化されたプログラムを実行する -jar オプションを付けて java コマンド を使用します。サンプルクライアントを実行するための構文は次のとおりです。 java -jar / username password ssl-endpoint first-queue second-queue message is-transaction-successful 使い方: <path-to-jar-file> – jar ファイルをダウンロードしたローカルマシン上のパス。 <jar-filename> – jar ファイル名。 <username> – ブローカーの作成時に選択したユーザー名。 <password> – ブローカーの作成時に選択したパスワード。 <ssl-endpoint> – 上記の手順で控えた SSL エンドポイント。 <first-queue> – トランザクション内の最初のキューの名前。 <second-queue> – トランザクション内の 2 つ目のキューの名前。 <message> – メッセージのテキスト。 <is-transaction-successful> – トランザクションが成功するかどうかをプロデューサークライアントに伝えるフラグ。 正常な取引のテスト ActiveMQ での正常なトランザクションをテストするには、次の手順を実行します。 ActiveMQ コンソールでキューとメッセージ数を確認する Amazon MQ コンソール にアクセスし、 ActiveMQ ブローカーを選択します。 Connections パネルから ActiveMQ Web Console にログインします。 Manage ActiveMQ broker をクリックします。 ブローカー作成時に作成したユーザーのユーザー名とパスワードを入力します。 トップナビゲーションバーで Queues をクリックします。 warehouse-queue と shipping-queue がリストに表示されていないことを確認します。 以下のコマンドを実行して、order1 のメッセージを両方のキューに正常に送信します: java -jar <path-to-jar-file>/<jar-filename> <username> <password> <ssl-endpoint> warehouse-queue shipping-queue order1 true 上記のコマンド説明にあるようにプレースホルダーを置き換えてください。このコマンドで、サンプルのプロデューサークライアントが最初のメッセージを warehouse-queue に送信し、次のメッセージをコンソールに出力して 15 秒待ちます。 Sending message: order1 to the warehouse-queue Message: order1 is sent to the queue: warehouse-queue but not yet committed. この 15 秒の待機中に、ブラウザを更新すると、warehouse-queue がリスト表示されますが、保留中またはエンキューされたメッセージはありません。15 秒後、プロデューサークライアントが 2 つ目のメッセージを shipping-queue に送信し、次のメッセージをコンソールに出力して 15 秒待ちます。 Sending message: order1 to the shipping-queue Message: order1 is sent to the queue: shipping-queue but not yet committed. この 15 秒の待機中に、ブラウザウィンドウを再度更新すると、shipping-queue がリストに表示されますが、warehouse-queue と同様に、保留中またはエンキューされたメッセージはありません。 最後に、プロデューサークライアントが両方のメッセージをコミットし、次のメッセージを出力します。 Committing Transaction for Message: order1 is now completely committed. ブラウザを更新すると、warehouse-queue と shipping-queue に保留中とエンキューされたメッセージがそれぞれ 1 つずつあることを確認できます。リストは次のようになります: shipping と warehouse キュー この手順を繰り返し、さらに成功したトランザクションをテストしてください。 失敗したトランザクションのテスト 各キュー内の保留中のメッセージとエンキューされたメッセージの最初の数をメモします。 次のコマンドを実行し、 false を渡して人為的な障害を導入します。 java -jar <path-to-jar-file>/<jar-filename> <username> <password> <ssl-endpoint> warehouse-queue shipping-queue failedorder1 false このコマンドにより、サンプルのプロデューサークライアントは最初のメッセージをwarehouse-queueに送信し、以下のメッセージをコンソールに表示して15秒間待機します。 Sending message: failedorder1 to the warehouse-queue Message: failedorder1 is sent to the queue: warehouse-queue but not yet committed. 15秒間の待機中にブラウザを更新し、warehouse-queueとshipping-queueのカウントが変更されていないことを確認してください。 最後にクライアントは人為的にエラーを発生させ、トランザクションをロールバックし、以下を表示します： Message: failedorder1 cannot be delivered because of an unknown error. Hence the transaction is rolled back. ブラウザを更新して、両方のキューのカウントが変更されていないことを確認してください。この例では、失敗したトランザクション後も各キューに1つずつメッセージがある状態から始まります。 コンソール上 shipping キューと warehouse キューのカウントが変更されていない 成功と失敗の両方の場合において、トランザクションの一部としてキューに送信されるメッセージは、クライアント側でインメモリに格納されることに注意してください。これらのメッセージは、トランザクションがコミットされた時にのみブローカーに送信されます。 クリーンアップ 次のコマンドを実行してブローカーを削除します aws mq delete-broker --broker-id まとめ この記事では、ActiveMQ バージョン 5.18 の Amazon MQ ブローカーを作成しました。また、Amazon MQ で導入された新しいセマンティックバージョニングについても学びました。ActiveMQ 5.18.x は JMS 2.0、Spring 5.3.x、および依存ライブラリの更新をサポートしています。最後に、ActiveMQ 5.18.x ブローカーのトランザクション機能を示しているサンプルアプリケーションを JMS 2.0 API を使用して作成しました。Amazon MQ の詳細については、 https://aws.amazon.com/amazon-mq/ をご覧ください。 このブログは、シニアテクニカルアカウントマネージャーの Paras Jain とシニアソリューションアーキテクトの Vinodh Kannan Sadayamuthu によって執筆されたものをソリューションアーキテクト三厨が翻訳しました。原文は こちら 。

アマゾン ウェブ サービス ジャパン（以下、AWS）は 2024 年 11 月 27 日に、「【Edtech Meetup】急成長サービスの秘訣と実践戦略」を AWS Startup Loft Tokyo にて開催しました。 近年、EdTech 分野はテクノロジーの進化と教育ニーズの変化により、急速に発展しています。 本イベントでは、EdTech スタートアップや教育業界の主要な企業から CxO・取締役の方々をお招きし、「急成長サービスの秘訣と実践戦略」をテーマにパネルディスカッションを行いました。パネルディスカッション後には、ライトニングトークや懇親会を行いました。 EdTech スタートアップ、教育業界など、総勢 80 名以上の方々にお集まりいただき、本 Meetup を通じて交流を深めていただきました。本ブログではそのレポートをお届けします。 オープニング AWS パブリックセクター統括本部 教育・研究事業本部 事業本部長 白石智良 イベント冒頭では、AWS パブリックセクター統括本部 教育・研究事業本部 事業本部長 白石智良がオープニングの挨拶を行いました。 「教育業界の DX の波の中で、どのようなことを実現できるのか。どのように教育業界をより良くしていけるのか、一緒にディスカッションを行えればと思っています。」と挨拶を行いました。 パネルディスカッション「 急成長サービスの秘訣と実践戦略 」 <ファシリテーター> AWS パブリックセクター統括本部 教育・研究事業本部 初等中等教育・EdTech 営業部 アカウントエグゼクティブ 尾島菜穂 <パネリスト> Classi 株式会社 取締役 プロダクト部 本部長 伊藤徹郎 氏 株式会社シンプルエデュケーション 代表取締役 平田直紀 氏 千株式会社 執行役員 CTO 竹澤有貴 氏 2 年間で 4200 校以上に普及。スピード感の秘訣 Classi 株式会社 の伊藤氏は、教育 ICT サービスの Classi が 2400 校に普及するまでには 8 年の歳月を要したのに対し、保護者連絡ツールの tetoru は 2 年間で 4200 校以上に普及したというスピード感のある成長の秘訣について、下記のように述べました。 「10 年前は学校に Wi-Fi さえない環境でしたが、コロナ禍を機に Classi のサービスが大きく広がるきっかけとなりました。一方、tetoru は Classi での経験を活かし、ネット・プロモーター・スコアなどのマーケティング指標を定期的に測定し、評判を重視しています。その結果、ユーザーの口コミによる拡散が進んでいます。」 「Classi は市場のニーズに応えるべく、次々と新機能を提供していましたが、一方で運用面で課題もありました。コロナ禍でサービスの接続性に問題が生じたことをきっかけに、より慎重なプロダクト開発を心がけるようになりました。この経験から生まれた tetoru も順調に成長を遂げています。」 「Classi の強みは営業力にあります。ICT 環境が整っていない学校に対しても、一から必要性を説得し、販売していきました。一方、tetoru はプロダクトの品質向上に注力しています。AWS の基盤を活用し、スケーラビリティを重視しているため、大雨や台風などによるアクセス急増時にも柔軟にスケーリングできる体制を整えています。」 口コミでサービスが広がるプロセスとは？ 4000 校の公立中学校・高校へ採点支援システム「 百問繚乱 」の導入が進んでいる、 株式会社シンプルエデュケーション の平田氏も同様に、口コミでサービスが広まるプロセスについて言及しました。 平田氏は、「会社に営業力が無い中での対応として、日本全国の先生にファンになっていただき、つい紹介したくなるプロダクト作りを心掛けてきました。先生が使いたくなるプロダクト作りに注力しています。同社はネット・プロモーター・スコア（NPS）で『10点』を目指すことにこだわり、多くの顧客から高評価を得ています。」と述べました。 「初期のユーザー獲得は困難でしたが、大阪の ICT イベントをきっかけに先生たちに無料で利用してもらい、どんなフィードバックも真摯に受け取り、サービスに取り入れました。その結果、3 年目にはサービスが軌道に乗り、それ以降は自然と広がるようになりました。百問繚乱においては、学校契約が増えていき最終的に教育委員会との契約となるケースがほとんどです。現在では、全国 約 13,000 校ある公立中学校・高校への導入が進み、今後は小学校も視野に入れています。」 「限られた営業リソースの中で、開発力に注力し、毎年スケーリングと成長を繰り返してきました。AWS の柔軟なリソースを活用することで、成長に伴う需要にも迅速かつ効率的に対応できています。」 「はいチーズ！」急激な伸びの要因は？ 保育園・幼稚園向け写真撮影販売サービスや、園業務支援 ICT サービスなど「 はいチーズ！ 」シリーズを提供する 千株式会社 竹澤氏は、コロナ禍でイベントが減少した時期を経て、子供たちの成長を記録しようという意識が業界の中で再び高まったと指摘しています。 「保育園のイベントは比較的固定されていることが多く、新たな需要を創出することは難しいものの、地域を巻き込んだ子育てイベントなどを提供することで需要を増やす工夫をしています。同社は『みんなの記憶を預かり、形にする』ことに注力しています。」と竹澤氏は述べました。 「『はいチーズ！』のビジネスは、印刷業界やカメラマンなど、現実世界でのリアルな取引が多い特徴があります。そのため、ICT の導入が進んでいない保育現場に適した営業アプローチが必要となっており、人的リソースの効果的な配分が重要になっています。」と続けて述べました。 このような背景により、竹澤氏は、DX が保育を含む教育業界にとって不可欠であると考えており、AI の活用などにも積極的に取り組む意向を示しています。開発への投資も今後さらに増やしていく方針を示されました。 竹澤氏は、「教育業界は、これまで営業力に重点を置いていた戦略から、プロダクト力を重視する方向へシフトしています。口コミなどを通じて、『プロダクトの力』で競争できる時代になってきた」とコメントしました。 パネルセッション終了後は、会場の参加者から質問を募りました。活発な質疑応答セッションとなり、パネリストからは自身のユニークな経験や業界の動向など、様々な観点から回答を行いました。 ライトニングトーク①「生成 AI を用いた新しい学びの体験を提供するまでの道のり」 パネルディスカッション終了後は、ライトニングトークへと続きました。 atama plus 株式会社 Engineering Management 室 VPoE 前田和樹 氏 atama plus 社は、個々の生徒の「得意」「苦手」「伸び」「つまずき」などのデータを分析し、パーソナライズされた学習プロセスを提供しています。ナレッジグラフを用いた学習体験を提供し、各生徒に最適なカリキュラムを作成しています。 従来の演習コンテンツでは、問題 → 解答 → 解説の流れを採用していましたが、生徒によっては解説を読むだけでは内容を理解できず、その結果、学習のモチベーションが下がったり、解答を丸暗記してしまったりすることがあります。この問題を解決するため、atama plus 社は生成 AI を活用した 新しいアプローチ を導入しました。 この新しいシステムでは、生成 AI を使用して長い解説文を分割し、チャット形式で提示します。学習者の理解度を対話的に測定し、理解が不十分な場合はさらに詳しい説明を提供します。生成 AI の使用に関する懸念に対しては、自社の解説を基に AI を制御することで、一定のガードレールを設けています。 atama plus 社は、開発過程から直営塾の生徒にインタビューを行い、ユーザーのニーズを反映させました。リリースから 1 ヶ月が経過した現在、限定的なリリースにもかかわらず利用実績は増加傾向にあり、75 %以上の生徒が AI ステップ解説によって理解が深まったと回答しています。 個別の反応としても、「ここまで鳥肌が立つ勉強法はない！」といった非常にポジティブなフィードバックを得ています。現在は一部の生徒に限定して提供し、有効性と価値の検証を行っている段階ですが、今後さらに改良を重ねて本格的な展開を目指しているとのことです。 ライトニングトーク② 一枚の授業風景写真から見えた、問題解決の糸口 ライフイズテック株式会社 サービス開発部 インフラ/ SRE グループ マネジャー 浅倉正芳 氏 ライフイズテック株式会社 は、「中高生ひとり一人の可能性を一人でも多く、最大限伸ばす」というミッションのもと、2010 年の創業以来、中高生向けの IT・プログラミング事業を展開しています。 同社の製品である「ライフイズテックレッスン」は、中学校・高校向けのプログラミング学習用 EdTech 教材です。2019 年秋にリリースされ、実際に Web サイトなどを作りながらプログラミングを学べる設計となっています。現在、全国 600 自治体、4,400 校、135 万人の中高生に導入されています。 技術面では、様々な AWS のサポートを活用してアプリケーションのアーキテクチャを構築しています。主に Amazon ECS コンテナと Amazon Aurora データベースを使用し、教材ファイルは Amazon FSx for OpenZFS に格納、学習進捗ログは Amazon DynamoDB で管理しています。また、AWS Cloud9 との連携機能も提供しています。 浅倉氏はこのようなサービスを提供する中で直面した問題とその解決に至った過程について述べました。 一つ目の問題は、「コスト」です。AWS Cloud9 の利用に関して、当初、デフォルト設定（生徒一人あたりAmazon EBS 10GB）で利用していたため費用が増大しました。そこで、教材ファイルの Amazon EBS（生徒一人あたり 1GB）を分離し、起動済みのインスタンスに動的にアタッチする方法に改善しました。 二つ目の問題は、AWS Cloud9 の接続問題です。Connecting という表示のまま開発環境が表示されないという問い合わせが増加し、原因の特定が難しかったため、サポートの方で手動で都度停止・起動を行っていました。 そんな問題の解決の糸口となったのは、一枚の授業風景写真でした。写真から、生徒が複数の端末やブラウザのタブで サービスを立ち上げていることが判明し、メモリ不足を引き起こしていたことが原因でした。そこで対策として、複数の端末で開かないよう注意書きを追加し、ブラウザの同じタブで開くよう修正をリリースしました。 浅倉氏は、実際に利用されている現場を見ることの重要性を強調し、現場の使い方から問題解決につながった事例を紹介しました。最後には「これからも AWS を活用したサービスで 教育業界を盛り上げていきましょう！」と述べました。 ライトニングトーク③ Education-JAWS のご紹介 Education-JAWS 大学一年生 栗栖 幸久 氏 社会人 前原 良美 氏 JAWS-UG (AWS User Group – Japan) は、日本の AWS を利用する人たちの集まり・コミュニティで、勉強会や交流会を実施しています。 今回栗栖氏・前原氏から紹介のあった Education-JAWS は、JAWS-UG の「教育に関する専門支部」として新しく設立されました。幼児、小学校、中・高等学校、専門学校・高専・大学、社会人まで、幅広い教育段階を対象としています。 Education-JAWS は、以下の 3 つの目標を掲げて活動しています： 教育現場でのクラウド利用増進 学生に外に出る機会を提供 クラウド利用の教育手法の発展 大学 1 年生の栗栖氏は、去年まで中等教育を受けていた立場から、教育現場の DX を間近で見てきた経験を共有しました。教育分野におけるクラウド活用には大きな可能性があり、まだ発展の余地があると指摘しました。 Education-JAWS は、教育現場でのクラウド活用方法や最新の知見を共有する場として機能しています。メンバーになることで、教育と AWS に関する最新情報をキャッチアップできる機会が得られます。 直近では、2025 年 1 月 11 日（土）に Education-JAWS 勉強会が開催予定となっています。ご興味のある方はぜひ Education-JAWS より、最新の情報をチェックしてください。 AWS ソリューションアーキテクトより、成長を支える AWS サービスのご紹介 AWS からは、パブリックセクター技術統括本部 教育・研究技術本部より、ソリューションアーキテクトの梅田昌太、大南賢亮、山本ひかるが登壇し、成長を支える AWS サービスについてライトニングトークを行いました。 山本からは「Amazon Bedrock アップデート」と題し、様々な基盤モデルが使用可能な AWS の提供する生成 AI ツールである Amazon Bedrock について、Anthropic 社の Claude モデルのアップデートや、生成 AI ワークフロー構築ツールである Amazon Bedrock Prompt Flows、責任ある AI を構築するための Amazon Bedrock ガードレール など、2024 年のメジャーなアップデートを 3 つピックアップしてご紹介しました。 詳細については下記リンクをご参照ください。 Amazon Bedrock ガードレール Amazon Bedrock Prompt フローを使用して生成 AI ワークフローを構築する end-to-end – Amazon Be… Anthropic の Claude 3.5 Sonnet モデルが Amazon Bedrock で利用可能に: Claude 3 Opu… Anthropic の Claude 3.5 Haiku モデルが Amazon Bedrock で利用可能に – AWS 梅田からは、「Redshift ML と SQL で今日から始める データを使った生成AIアプリケーション」というテーマで、既存アプリケーションへの生成 AI の組み込み方法や、データ活用の手法を紹介しました。 Amazon Redshift ML を活用することで、SQL クエリを使いながら Amazon SageMaker と連携した ML モデルの作成やトレーニングが簡単に行え、さらに Amazon Bedrock との統合により柔軟な生成 AI 開発が可能になったことを強調しました。 また、SQL と Redshift ML を用いることで、多くのエンジニアが馴染みやすい形でお客様データを活用した生成 AI アプリケーションの開発が容易になり、Zero-ETL 統合によってデータ準備も迅速化できる点が利点として挙げられました。 これらの技術を活用することで企業が独自の生成 AI アプリケーション開発にすぐ取り組めることを強調し、実践的なAI導入の可能性を示しました。 詳細については下記リンクをご参照ください。 Amazon Redshift | Redshift ML – Amazon Web Services Amazon Redshift ML と Amazon Bedrock の統合 – Amazon RedshiftAmazon Redshi… ゼロ ETL 統合 – Amazon Aurora と Amazon Redshift – AWS 大南からは、「年末までに改善する AWS のガバナンス＆セキュリティ」と題し発表しました。ガバナンスとセキュリティに関するタスクは幅広く、完全にカバーするのは難しい現状がある上で、AWS のベストプラクティス活用の重要性を強調しました。 AWS では、 AWS Startup Security Baseline 、 AWS Control Tower 、 AWS Trusted Advisor 、 AWS Well-Architected Framework 、 AWS Security Reference Architecture など、多くのガバナンス・セキュリティをカバーするサービス・ツールをご利用・ご参照いただけます。 特に AWS Trusted Advisor は、AWS ベストプラクティスに基づく推奨事項を提供し、コスト最適化、システム可用性、パフォーマンス向上、セキュリティ強化をサポートします。ガバナンスとセキュリティ課題へ AWS ベストプラクティス活用し、まずはできるところから取り組むことが大切です。最後は「年末までに是非 AWS Trusted Advisor の再点検を！」と締めくくりました。 最後に 最後はご登壇いただいた方々の記念写真、そして参加者の皆さんでの懇親会を行い、EdTech Meetup は幕を閉じました。活発な会話、議論が行われている様子が印象的で、参加者の皆さまに交流を深めていただける良い機会となりました。 また、過去の EdTech Meetup に関しましては、下記のブログをご参照ください。 【Edtech Meetup】Edtech スタートアップがグローバルに活躍するには？【開催報告】 | Amazon Web Service… 【Edtech Meetup】教育×AI ～生成系 AI によって教育はどう変わるのか～【開催報告】 | Amazon Web Servic… 教育分野のスタートアップが繋がる EdTech LT Night and Meetupを開催しました | Amazon Web Servic… AWS パブリックセクターは今後も、EdTech がイノベーションを加速させるための、さまざまなテクニカル・ビジネスセッションやコミュニティ活動を実施予定です。 ご関心を持たれた方は、お気軽に お問い合わせ ください。教育のイノベーションに取り組まれる皆さまのご参加をお待ちしております。 次回の EdTech Meetup も是非お楽しみに！ このブログは、 アマゾン ウェブサービス ジャパン 合同会社 パブリックセクター ソリューションアーキテクト 山本ひかるが執筆しました。

はじめに みなさんこんにちは。ソリューションアーキテクトの福嶋（ふくしま）です。2024 年 12 月 20 日に自動車業界のお客様を AWS にお招きして「セキュリティインシデント疑似体験 GameDay for Automotive 2024 」を開催しました。AWS Japan では、自動車業界の皆様にクラウドを活用してビジネスを加速して頂くことを目指し、毎年「AWS Autotech Forum」などのイベントを開催しています。今回は現場のエンジニアの方により実践的な情報の提供と経験値を積んでいただく場を提供するために、GameDay イベントを開催しました。年末のお忙しい時期ではありましたが32名のお客様にご足労いただきイベントにご参加いただきました。 イベントの様子 当日は、会社ごとに 2 名 ~ 4 名のチームに分かれてゲームに参加いただきました。。多くの方は CCoE として社内で活躍されているとのことで過去の GameDay イベントと比べても非常にレベルの高いものとなりました。 Game 終了後には 1 位のチーム、個人成績 1位の方に対して表彰させていただきました。チーム、個人で 1 位になられた方々は日々の業務ではセキュリティインシデントへの対応はしたことないとのことでしたが、「Game の中でどのようにセキュリティインシデントへの調査をするのかなどを身につけることができた。」「セキュリティルールを守らなければいけない手順としての理解だけでなく、どんな問題からシステムを守る必要があるのかがわかりセキュリティ意識が一段と高まった」とコメントをされていました。 Game 終了後、シナリオで何が起きていたのかを AWS の SA より解説させていただきました。解説セッションは参加必須ではありませんでしたが、みなさん熱心に聞かれていたのが印象的でした。また、終了後にアンケートを実施させていただきましたが、「普段の業務では行ったことがないログ分析でいい経験になり、今後に活かせる内容だった。」「自分で問題を解いていくという体験がよかった。」などのポジティブなお声を多く頂戴しました。このGameDayイベントで体験したセキュリティインシデント対応の重要性を踏まえ、より包括的な自動車業界のセキュリティ対策について学びたい方に向けて、以下のようなリソースも用意しています。 AWS Black Belt Online Seminar の公開について 昨今では自動車のサプライチェーン全体でのセキュリティ確保が重要となってきています。AWS 自動車チームでは、自動車に求められるセキュリティについてクラウドが担う範囲を整理するために AWS Black Belt Online Seminar を公開しました。WP29などの法規･ガイドラインについて整理し、AWS がどのように自動車業界に対して取り組んでいるのかをご説明しています。下記のリンクよりご視聴いただけます。 おわりに 今回参加されたみなさんは、普段からチーム内でコミュニケーションを活発に取られているようで Game においても適確な役割分担の元、Game を進めらていました。本番のシステムにおけるインシデント対応においても1人で対応することは難しくチームプレイと平常心が重要だと改めて感じるイベントとなりました。ご参加いただきました、みなさま改めましてありがとうございました。AWS 自動車チームでは、これからも自動車業界のみなさまに貢献できるようクラウド技術のご紹介や、各種イベントを実施いたします。積極的に活用いただけますと幸いです。 著者 福嶋 拓 国内 SIer を経て AWS に入社。主に自動車・製造領域のお客様を担当しています。好きな AWS サービスは AWS Lambda 、Amazon S3 です。趣味はキャンプとドライブです。

2024 年 12 月 10 日から 12 日まで、奈良県コンベンションセンターで開催された AXIES 2024 年次大会 に、アマゾン ウェブ サービス ジャパン合同会社 (AWS) が賛助会員として協賛・出展しました。本ブログでは、展示ブースや登壇セミナーの内容をご紹介します。 展示ブース：生成 AI 活用デモンストレーション AWS の展示ブースでは、GitHub でオープンソースとして公開している 生成 AI アプリケーションである Generative AI Use Cases JP (GenU) のデモンストレーションを実施しました。GenU は技術的知識がなくても即時に利用可能で、 Amazon Bedrock の生成 AI モデルに対応した実用的なアプリケーションです。高いカスタマイズ性を備え、研究論文の自動要約や教育関連文書の自動作成など、教育現場での実践的な活用が可能です。 参加者からは、 大学での活用事例に関心が寄せられました。ある大学では、GenU を活用して教職員向けの生成 AI アプリケーションを 1 ヶ月という短期間で内製開発しました。これにより会議録作成時間を 1/4 に削減するなど、業務効率化に大きな成果を上げています。 図 1: AWS の展示ブース 協賛セミナー 『 AI とデータ活用・分析のための データレイク とは』と題し、AWS パブリックセクター技術統括本部 シニアソリューションアーキテクトの櫻田武嗣が登壇しました。 セミナーでは、まずデータレイクの基本概念について解説しました。従来の データウェアハウス では目的に合わせて加工済みのデータを保存していましたが、データレイクではデータを「生」のまま保存し、将来のニーズに備えることができます。 Amazon Simple Storage Service (Amazon S3) を中核としたデータレイクでは、データを 3 箇所以上の アベイラビリティゾーン へ自動的に保管します。また、高いデータ耐久性や容量無制限のスケーラビリティなど、高い信頼性と拡張性を実現しています。 海外の活用事例として、 ポートランド州立大学での取り組み を紹介しました。同大学では卒業生の履修履歴データに機械学習を適用し、現役学生にお勧めのコースを提示する機械学習モデルを作成。学生の学位取得を効率的に支援し、中退者数の削減に寄与しています。また、モナシュ大学では学習管理システムを AWS に 12 週間で移行し、学内試験の 80 %を紙ベースからコンピュータベースに移行することで採点時間を 50 %削減、700 万ドルのコスト削減を実現しました。 国内事例としては、オンプレミスから AWS に移行し、初期費用だけでなく運用にかかる関連コストを含めた総コスト削減をした 近畿大学の事例 を紹介。職員はハードウェア起因の定期的なリプレース作業から解放され、学生向けサービスの企画など付加価値の高い業務に注力できるようになりました。また、東北大学での取り組みの事例についても紹介しました。東北大学も別のセッション内にてこの取り組みについて触れていました。 さらに、 AWS re:Invent 2024 で発表された AWS サービスとして、Amazon S3 の新しいデータ整合性検証の仕組みや Amazon FSx Intelligent-Tiering 、 AWS Transfer Family ウェブアプリケーション など、データレイクの運用をより効率的にする機能についても紹介しました。 図 2: データレイクの基本概念 ランチョンセミナー 『教育研究機関の様々なワークロードで活用される AWS 』をテーマに、AWS パブリックセクター技術統括本部からシニアソリューションアーキテクト 佐々木啓とソリューションアーキテクト 川戸渉が登壇しました。 AWS の生成 AI スタックは、3 層構造で体系化されています。まず基盤層では、2024年12月時点で最新の AI チップ AWS Trainium2 を搭載した Amazon Elastic Compute Cloud (Amazon EC2) Trn2 インスタンス が従来比 30-40 % 高いコストパフォーマンスを実現し、 Amazon EC2 UltraClusters による大規模分散学習環境を提供しています。さらに用途に合わせて GPU 、 AWS Inferentia を利用することもできます。これらのインフラには Elastic Fabric Adapter 、 AWS Nitro System などの AWS が独自開発しているテクノロジーが活用されています。 次の層では、基盤モデルを活用してアプリケーションを作るためのツール群を提供しています。Amazon Bedrock を通じて組織専用の基盤モデル活用環境を実現し、新たに発表された Amazon Nova (Micro / Lite / Pro / Canvas / Reel) による画像・動画生成機能も提供しています。セミナーでは、Nova Canvas で画像を生成し、 その画像から Nova Reel で動画を生成するデモンストレーションを行い、その革新的な生成能力に多くの参加者が関心を示しました。 最上位層では、実用的なアプリケーション群を展開しています。 Amazon Q Business による組織内データへの自然な問答、 Amazon Q in QuickSight によるデータ分析支援、 Amazon Q Developer による開発支援、さらに Amazon Q in Connect によるコンタクトセンター支援など、幅広いソリューションを提供しています。 図 3: AWS の生成 AI スタック AWS は研究データ管理において、二つの重要な取り組みを行っています。一つは、 オープンデータスポンサーシッププログラム です。このプログラムでは、公共性の高い研究データをオープンデータとして公開する際に、AWS が無償でストレージを提供します。もう一つは、国立情報学研究所が運営する研究データ管理サービスである GakuNin RDM への対応です。これらの取り組みにより、AWS は研究データのオープン化推進と、データ管理のコンプライアンス強化の両面を支援しています。 さらに、 AWS Data Exchange を通じてデータの流通と活用も促進しています。このように、AWS は教育研究機関に対して、研究データの公開、管理、活用を包括的に支援する先進的なクラウドソリューションを提供しています。 図 4: 研究データにおけるAWSの取り組み 今後の展望 AWS は教育・研究機関の デジタルトランスフォーメーション (DX) を継続的に支援していきます。教職員の業務効率化、カリキュラムの最適化、研究開発の効率向上など、先端技術の実装を通じて教育・研究機関が直面する様々な課題の解決を後押ししてまいります。 本ブログに関するお問い合わせは、 AWS 営業担当  までご連絡ください。 本ブログはパブリックセクターソリューションアーキテクトの川戸渉が執筆しました。

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 Amazon Bedrock Agents に関する新しい AWS Black Belt オンラインセミナーの資料及び動画 が公開されています。年末年始のお供にぜひご覧いただければと思います。 それでは、12 月 16 日週の生成AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ: 株式会社シスラボ様、市場調査・分析にかかる時間を Amazon Bedrock Agents の活用により 98.3% 削減 シスラボ様は、IT ソリューションの企画・立案からシステム導入後のアフターサポートまでサービスとして提供する中で、手作業による市場調査・比較表の作成などの業務に多くの時間がかかるといった課題を抱えていました。そこで、キーワードを指定するだけで、競合比較表を作成できるサービス “Marketing AI” を開発しました。 Amazon Bedrock Agents を通じてユーザーが入力したキーワードを Web 上で検索し、検索結果に基づいて Claude モデルが回答を生成します。Marketing AI の導入により、企画ごとに約 2 時間かかっていた業務を 98.3 % 減の 2 分に短縮することに成功したそうです。またサービス構築はわずか 3 名で約 1 カ月間という短期間で行いました。今後は、Marketing AI を正式な自社サービスとして展開していくそうです。 ブログ記事「Amazon Connect で実現する生成 AI を活用したセルフサービスの簡素化」を公開 24 時間 365 日のサポートを顧客に提供する セルフサービスのカスタマーサポート は、企業にとって重要な要素となっています。この記事では、セルフサービスに関する Amazon Connect の最新機能を詳しく説明しています。Amazon Q in Connect による生成 AI を活用したセルフサービス構築機能やパフォーマンス分析のためのダッシュボード機能も紹介してます。 ブログ記事「Amazon QuickSight の生成 AI アシスタンスを使用して小売データを分析する」を公開 このたび小売向けの生成 BI 機能を利用できるサンプルダッシュボードを DemoCentral で公開しました。本記事ではサンプルダッシュボードの使い方を解説しています。サンプルダッシュボードには Amazon Q in QuickSight の質疑応答機能が実装されており、自然言語による問い合わせと、それに応じたビジュアル生成・要約文生成を簡単に試せるようになっています。 ブログ記事「Amazon Verified Permissions と Amazon Bedrock Agentsを使用した安全な生成 AI アプリケーションワークフローを設計する」を公開 Amazon Bedrock Agents を活用したアプリケーションにおいて、ユーザー権限に基づいたきめ細かなアクセスコントロールを適用しようとすると、アクセスコントロールポリシーの管理方法を考える必要が出てきます。この記事では、Amazon Verified Permissions を Amazon Bedrock Agents から呼び出すことで、エージェントワークフローに対するポリシー管理を一元化する方法を紹介しています。 ブログ記事「生成 AI アプリケーションで使用するデータを保護するための効果的なデータ認可メカニズムの実装」を公開 RAG や AI エージェントなどを活用した生成 AI アプリケーションでは、データセキュリティが非常に重要です。このブログでは、機密データを生成 AI アプリケーションで利用する際のリスクと、データ認可の実装方法を紹介しています。Amazon Bedrock Agents で強固な認可を実装する方法として、セッション属性情報を AWS Lambda に渡す方法が紹介されています。 ブログ記事「責任ある AI に関する新しいツール、機能、リソースにより AI の信頼を促進する」を公開 この記事では、AWS re:Invent 2024 で発表された、責任ある AI に関する新しいツールや情報を紹介しています。例えば、 Amazon Nova は、データから有害なコンテンツを検出して削除し、不適切なユーザー入力を拒否するといった安全対策が搭載されています。このような LLM の安全性や開発プロセスにおける公平さ、説明可能性などの責任ある AI に関する情報は、このたび新しく追加された AI サービスカード にて説明されています。 ブログ記事「生成 AI を活用してプレイヤーやプレスのゲームレビューを分析する」を公開 この記事では、Amazon Bedrock を使用してゲームレビューのアップロード、処理、分析、要約を行うことができるサーバーレスソリューションの構築方法を説明しています。大量のレビューを処理するために Amazon Bedrock Batch Inference API を使用しているのが設計のポイントの 1 つです。サンプルコードは こちら で確認できます。 サービスアップデート Amazon Q Business の分析ダッシュボードにて会話のインサイトが表示可能に Amazon Q Business の分析ダッシュボード機能が強化され、会話の様々な側面を分析できるようになりました。今回追加された分析項目は、回答が見つからなかったクエリ、ブロックされたクエリ、エンドユーザーからのフィードバックの 3 つです。これにより、管理者はユーザー体験やデータの課題を特定し対処しやすくなりました。 Amazon Connect の Amazon Q のエージェント支援機能で 新たに 64 言語をサポート開始 Amazon Connect では、コンタクトセンターのエージェントに対して問い合わせに関する情報提供やレコメンデーションを行うチャット機能を Amazon Q を通じて利用することができます。これまで利用言語が限られていましたが、このたび日本語を含む新たな 64 言語をサポートするようになりました。これにより日本語によるチャット応答が可能になっています。 Amazon Q Business が SOC 準拠を達成 このたび Amazon Q Business が SOC（System and Organization Controls）準拠サービスとなりました。Amazon Q Business の SOC 認証により、お客様は今後、SOC 要件の対象となるユースケースで Amazon Q Business を使用できるようになります。サポートされているすべての AWS リージョンで SOC 準拠となっています。 Amazon Bedrock で Meta Llama 3.3 70B モデルが利用可能に Meta の Llama 3.3 70B モデルが、Amazon Bedrockで利用可能になりました。Llama 3.3 70B は、モデルの効率性とパフォーマンスが向上しており、少ない計算リソースで旧世代の上位モデルである Llama 3.1 405B と同等のパフォーマンスを提供します。現在、米国東部（オハイオ）リージョンで利用可能であり、米国東部（バージニア北部）および米国西部（オレゴン）リージョンではクロスリージョン推論を通じて利用可能です。 Amazon Bedrock で Stable Diffusion 3.5 Large モデルが利用可能に Stability AI の Stable Diffusion 3.5 Large (SD3.5 Large) が Amazon Bedrock で利用可能になりました。SD3.5 Large は テキストから高品質な 100 万画素の画像を生成可能なモデルです。 3次元や絵画などの多様なスタイルの画像生成に加えて、プロンプトへの忠実性も向上しています。現在、米国西部（オレゴン）リージョンの Amazon Bedrock で利用可能です。サンプルや詳細は こちらの記事 をご覧ください。 週刊生成AI with AWS の年内の投稿は本日で最後となります。いつもご覧いただきありがとうございました。 今年は、お客様の革新的な生成 AI 活用事例やサービスアップデートが盛りだくさんで、驚きと発見に満ちた激動の 1 年だったように思います。 来年もどうぞよろしくお願いします！ 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は生成 AI と毎日戯れており、特にコード生成と LLM エージェントに注目しています。好きなうどんは’かけ’です。

みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今週も 週刊AWS をお届けします。 re:Inventの時期の大量のアップデートも徐々に落ちついてきましたが、これまでのキャッチアップに間に合っていない方も多いかもしれませんね。2025年 1/28(火)から「 AWS re:Invent Recap – インダストリー編 」、2 /4(火)から「 AWS re:Invent Recap – ソリューション編 」 を開催予定ですので、こちらのご視聴もお勧めです。 それでは、先週の主なアップデートについて振り返っていきましょう。 2022年12月16日週の主要なアップデート 12/17(火) AWS IoT Greengrass v2.14 now supports a new lightweight edge runtime software, uses less than 5MB of memory AWS IoT Greengrass 2.14 にて、組み込み Linux 上で動作するリソース制約のあるデバイス向けに、軽量なランタイムエージェントをサポートする nucleus lite を提供開始しました。 開発者は特定のエッジデバイスの機能やアプリケーションのニーズに合わせて最適なオプションを柔軟に選択できます。 Amazon Connect now provides agent schedule data in analytics data lake Amazon Connectは、分析用データレイクに公開されたスケジュールデータを提供し、このデータからレポートやインサイトを簡単に生成できるようになりました。 分析用データレイクにあるエージェントのスケジュールデータから、給与計算のための勤務時間管理のレポート生成や、指定された期間にどれだけのエージェントが勤務予定でどれだけのエージェントが休暇を取得しているかの要約ビューの生成など、主要な運用上のユースケースを自動化できるようになりました。これらのレポートや洞察を生成するために、Amazon AthenaをAmazon QuickSightまたはお好みの他のビジネスインテリジェンスツールと共に使用することができます。 12/18(水) AWS Backup launches support for search and item-level recovery AWS Backup は Amazon EBS スナップショットとAmazon S3 バックアップの検索とアイテムレベルリカバリのサポートを発表しました。 この機能により、バックアップのメタデータを検索し、バックアップ全体から特定のファイルやオブジェクトを見つけ、一度に最大 5 項目までリカバリできるため、リカバリ時間を短縮できます。実行方法については、こちらの ブログ を参照ください。 AWS Resilience Hub now supports Amazon CloudWatch alarm detection for application resilience AWS Resilience Hub は、既存の Amazon CloudWatch アラームを自動的に検出してレジリエンス評価に統合するようになりました。これにより、アプリケーションのレジリエンスポスチャーをより包括的に把握できるようになります。 この新機能は、AWS Resilience Hub の推奨事項と現在の監視設定を組み合わせることで、アラーム管理を合理化し、評価の正確性を高めます。 AWS DataSync now supports configuration updates for all supported storage locations AWS DataSyncは、Amazon S3、Amazon EFS、Amazon FSx for Lustre、Amazon FSx for NetApp ONTAP、Amazon FSx for OpenZFS、Amazon FSx for Windows File Serverなど、すべてのサポートされているストレージロケーションの構成更新をサポートするようになりました。この機能強化により、主要なパラメーターを更新するためにロケーションを削除して新しいものを作成する必要がなくなり、直接ストレージロケーションを更新できるようになります。 12/19(木) AWS Glue Data Catalog offers advanced automatic optimization for Apache Iceberg tables AWS Glue Data Catalog は、Apache Iceberg テーブルの高度な自動最適化を提供します。 このアップデートには、削除ファイルの圧縮、ネストされたデータ型、部分的な進捗コミット、パーティション進化のサポートが含まれ、一貫してパフォーマンスの高いトランザクションデータレイクの維持が容易になります。 詳細はこちらの ブログ をご覧ください。 AWS IoT Device Management introduces high-throughput device connectivity status queries AWS IoT Device Management は、高スループットの接続状態クエリ API の一般提供を発表しました。これにより、開発者は監視と管理の目的で、IoT デバイスの最新の接続状態をクエリできるようになります。 Amazon AppStream 2.0 introduces Rocky Linux Application and Desktop streaming Amazon AppStream 2.0 は、CIQ の Rocky Linux をサポート開始しました。ISV や IT 部門は、AWS クラウドの柔軟性、拡張性、コスト効率を活用しながら、計算負荷の高いアプリケーションの実行に最適化された RPM Package Manager（RPM）互換の環境からストリーミング可能になり、Rocky Linux、Red Hat Enterprise Linux（RHEL）、Microsoft Windowsなど、より幅広い OS から柔軟に選択できるようになりました。 Introducing Stable Diffusion 3.5 Large in Amazon Bedrock Stability AI の Stable Diffusion 3.5 Large (SD3.5 Large) が Amazon Bedrock で利用可能になりました。SD3.5 Large は 81 億のパラメーターを備えた高度なテキストから画像を生成するモデルです。Amazon SageMaker HyperPod で訓練された強力なモデルにより、優れた精度と創造的な制御で、テキストから高品質の 100 万画素の画像を生成することができます。SD3.5 Large はオレゴンリージョンで利用可能です。 12/20(金) Amazon QuickSight Launches Unique Key for Dataset Amazon QuickSight は Unique Key for Dataset のリリースを発表し、ユーザーがデータのセマンティクスを定義できるようになりました。 このユニークキーは、QuickSight のビジュアル、特に集計されていないテーブルチャートのパフォーマンスを改善するために使用されます。この機能により、ビジュアルのレンダリング時間が 60% 短縮されることもあります。 詳細は こちら をご覧ください。 Amazon WorkSpaces Personal now supports AWS Global Accelerator Amazon WorkSpaces Personal は AWS Global Accelerator (AGA)と統合をサポートしました。AWS Global Network とエッジロケーションを経由するストリーミングトラフィックを最適化することで、WorkSpaces の接続パフォーマンスを強化します。 この機能は、エンドユーザーが長距離を越えて WorkSpaces に接続するお客様に特にメリットがあります。 AWS Billing and Cost Management now supports custom billing views for decentralized cloud cost management AWS Billing and Cost Management にて、カスタム請求ビューの一般提供を発表しました。カスタム請求ビューは、組織内の複数のアカウントにまたがるコスト管理データへのアクセスをメンバーアカウントに付与することを可能にします。 カスタム請求ビューにより、管理アカウントへのアクセスを許可することなく、AWS Cost Explorer の単一のビューを使用して、複数のAWSアカウントにまたがる関連コスト管理データへのアクセスをアプリケーションおよびビジネスユニットの所有者に提供できます。 それでは、また来週お会いしましょう！ 著者について 戸塚 智哉(Tomoya Tozuka) / @totozuka 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。

本稿は、2024 年 12 月 3 日に AWS Blog で公開された “Amazon Q Developer agent for transformation of VMware workloads” を翻訳したものです。 VMware ワークロードの移行と最新化のための Amazon Q Developer transformation capabilities のパブリックプレビューを発表できることを嬉しく思います。Amazon Q Developer は、アプリケーションのコーディング、テスト、アップグレードから、エラーの診断、セキュリティスキャンと修正の実行、AWS リソースの最適化、そして現在は移行やモダナイゼーションに至るまで、開発者や IT プロフェッショナルのさまざまなタスクを支援できます。Q Developer transform for VMware は高度な多段階の計画機能および推論機能を備え、モダナイゼーションチームが監督するドメインエキスパートの生成 AI エージェントによって、統一されたコラボレーティブな Web エクスペリエンスの下でエンタープライズワークロードの大規模な変革を加速します。 VMware ワークロード上で稼働する仮想マシン (VM) は、企業 IT インフラストラクチャの基本的な構成要素となっており、組織がアプリケーションを効率的にデプロイおよび管理するための柔軟でスケーラブルな基盤となっています。しかし、オンプレミスのワークロードのクラウドへの移行とモダナイゼーションには独自の課題が伴います。多くの場合、時間とコストがかかり、労働集約的でエラーが発生しやすいプロセスです。例えば、移行プロジェクトでは、アプリケーションを運用するためのクラウド環境を設定するための専門的なスキルが必要です。移行担当者は、オンプレミスのネットワーク構成を Amazon Virtual Private Cloud (VPC)、サブネット、セキュリティグループなどの AWS と同等のものに手動で変換する必要があります。さらに、事業継続性を確保するためには、何百台ものオンプレミス仮想マシンの依存関係を特定し、依存する VM をまとめて移行する必要があります。そのため、ビジネス目標を達成するために、移行とモダナイゼーションを促進するための移行に関する専門知識やツールを求めることがよくあります。 Q Developer による VMware ワークロードの変換は、18 年にわたる AWS の専門知識に基づいて構築されています。そのため、お客様は多くの熟練した専門知識を身に付ける必要がなく、ワークロード変換の旅を簡素化し加速するのに役立ちます。内部テストでは、AWS チームは Amazon Q Developer の変換機能を使用して 500 台の仮想マシン (VM) の VMware ネットワーク構成を変換し、VPC、Subnet、Transit Gateway、Internet Gateway などの AWS ネットワーク構成を 1 時間以内に生成しました。これは、従来の手作業によるアプローチで 2 週間かかっていた作業に比べて 80 倍の速さです。 イメージ 1: 変換ジョブの計画 生成 AI による自動化 オンプレミスの VMware ワークロードを Amazon EC2 に移行する場合、いくつかの課題があります。たとえば、基盤となるコンピューティング、ストレージ、ネットワークの構成は異なります。オンプレミスのハイパーバイザーからリソースを移行するには、ネットワークコンポーネントを含め、通常 vSphere などの環境内に存在するすべての基本的な要素を AWS で再作成する必要があります。Q Developer Transform for VMware エージェントを使用すると、お客様はコレクターまたはファイルインポートを使用してこれらのオンプレミスコンポーネントを棚卸しして発見し、VMware ワークロードのフットプリントを包括的に把握できます。 イメージ 2: ダッシュボード 一般的なエンタープライズの VMware ワークロードは何年も稼働しており、大規模かつ複雑な環境を形成しているため、クラウドへの移行には多大な労力がかかり、多くの場合、数か月にわたる手作業が必要になります。このような複雑さにより、リホスト・プロジェクトの完了に必要な労力のレベルが高くなるため、移行の優先順位が下がる可能性があります。大規模な移行では、しっかりとした計画を立てることで、ダウンタイムのリスクを抑え、より予測可能な結果を得ることができます。Q Developer transform for VMware の機能では、リソース効率の高いモダナイゼーションを実現するために、オンプレミスのインベントリ、依存関係、定められたビジネス目標、Q Developer エージェントによる VMware の専門知識に基づいて、生成 AI 主導の変革計画と推奨事項を提供します。 さらに、Q Developer transform for VMware は、コラボレーション機能を備えた AI 主導の Web エクスペリエンスを提供し、自律的な生成 AI エージェントとの自然言語によるチャットを可能にします。これにより、計画の作成、チームによる共同レビューと承認の促進、問題の迅速な解決が可能になります。これによって 1 か所でエンドツーエンドのエクスペリエンスを提供できるため、複数のサービスやツール間でのコンテキストの切り替えを最小限に抑えることができます。 Q Developer transform for VMware では、自動ネットワーク変換も提供され、複雑な VMware ネットワーク構成の分析とネイティブの AWS 構成への変換を AI エージェント主導で自動化できるため、特別な作業を数週間から数か月短縮できます。Q Developer エージェントは、移行ウェーブの計画、AWS ネットワーク設定などの生成されたアーティファクトと EC2 サイジングの推奨事項を組み合わせて、包括的な移行計画を作成します。この計画は編集可能で、AWS Application Migration Service (MGN) を使用してサーバー移行を開始する場合にも利用できます。 イメージ 3: 生成された Infrastructure as Code (IaC) コード VMware から EC2 への移行は長期間にわたって実行され得るため、場合によっては数か月かかることもあります。Q Developer transform for VMware には、ジョブの進捗状況を示すダッシュボードや、完了した作業結果の完全なコンテキストを示す作業ログなどのオブザーバビリティ機能もあります。作業ログには、プロジェクトのライフサイクル中に生成された中間アーティファクトも含まれるため、Q Developer エージェントまたは人間が下した決定を変革の包括的な履歴として提供できます。 イメージ 4:　作業ログ コストを削減し、イノベーション、セキュリティ、レジリエンスを強化する Q Developer transform for VMware は、VMware ワークロードを最適化されたコンピューティング、ストレージ、ネットワークアーキテクチャを備えた EC2 インスタンスに移行する際に、サードパーティの不要なライセンス料を削減することで、経済的なメリットももたらします。 イメージ 5: Amazon EC2 インスタンスの最適化 VMware ワークロードを Amazon EC2 ネイティブインスタンスに移行することで、200 を超える AWS サービスを使用してアプリケーション開発をモダナイズする機会が開かれます。これには、AI/ML やデータサービスを活用してインパクトのあるビジネスインサイトを得て、イノベーションを加速させることも含まれます。 Amazon Q Developer transformation capabilities は、コンプライアンスを念頭に置いて設計されており、すべての移行アクティビティの詳細な監査ログが提供され、コンプライアンス報告に役立ちます。 AWS IAM Identity Center を活用したきめ細かなアクセス制御原則を採用しており、権限のある担当者のみが移行データにアクセスしてタスクを実行できるようにしています。 始めてみましょう Q Developer transform for VMware を始めるには、 Amazon Q Developer Pro サブスクリプション が必要です。詳細なガイダンスについては、「 Q Developer transform for VMware 機能入門 」 または 入門ページ を参照してください。VMware NSX 環境からネットワーク設定をエクスポートする場合は、「 Exporting network configuration data with Import/Export for NSX 」ブログも参照してください。 まとめ このブログ記事では、Amazon Q Developer transform for VMware を使用することで、組織が生成 AI の力を引き出し、VMware ベースのワークロードをよりシンプルかつ自動化された安全な方法で Amazon EC2 に移行およびモダナイズできるようになることを強調しています。詳細については、Amazon Q Developer transform for VMware の 製品ページ をご覧ください。 この投稿の翻訳は Solutions Architect の有岡が担当させていただきました。原文記事は こちら です。 Rodney Bozo Rodney Bozoは、エンタープライズアプリケーション、移行、モダナイゼーションを専門とするソリューションアーキテクトリーダーです。IT 業界で 20 年以上働いており、高等教育機関、コンサルティング、ソフトウェア企業、クラウド企業での勤務経験があります。情報システム技術の修士号と経営学修士号を取得し、AWS や Microsoft の認定資格や Certified Information Systems Security Professional (CISSP) の資格など、さまざまな業界資格を取得しています。 Atul Modi Atul Modi は、ユーティリティコンピューティング、エッジコンピューティング、ワークロード変換の分野で 12 年以上の経験を持つ、AWS 移行および近代化グループのプロダクトリーダーです。AWSでは、Atulはソフトウェアの管理の簡素化だけでなく、生成 AIを活用したコンピューティングワークロードの変革にも注力しています。

本ブログは 2024 年 11 月 18 日に公開された「 Threat modeling your geneyfujiurarative AI workload to evaluate security risk 」を翻訳したものです。 生成 AI モデルがますますビジネスアプリケーションへ統合されるにつれ、それらがもたらす潜在的なセキュリティリスクを評価することが極めて重要になります。AWS は、AWS re:Invent 2023 で このトピックについてプレゼンテーションを行い 、何百ものお客様が新技術を安全に採用するため迅速な意思決定を維持することに役立ちました。このセッションに参加したお客様は、セキュリティリスクを評価し、構築するアプリケーションに対して高いセキュリティ基準を維持するための推奨アプローチをより深く理解することができました。本ブログでは、生成 AI ワークロードに対する効果的な脅威モデリングを実施するための主要なステップを再確認し、各段階で期待される典型的なアウトプットや検討結果を含む、さらなるベストプラクティスと例を紹介します。本ブログ全体を通して、 AWS Threat Composer tool を使用して作成した具体的な事例のリンクを提供します。 Threat Composer は、脅威モデルを文書化するために使用できる AWS のオープンソースツールで、追加費用なしで利用可能です。 本ブログでは、生成 AI ワークロードの脅威モデリングを行うための実践的なアプローチを扱い、脅威モデリングの基本を理解していることを前提としています。脅威モデリングの概要を知りたい方は、 このブログ をご確認ください。加えて、本ブログは生成 AI のセキュリティとコンプライアンスの考慮事項に関する 長編シリーズ のひとつです。 なぜ生成 AI に脅威モデリングを使用するのか？ 新しい技術にはそれぞれ、固有のセキュリティリスクを特定し軽減するうえで、独自の学習曲線があります。ワークロードへの生成 AI の採用も例外ではありません。大規模言語モデル (LLM) の使用は、ユーザーのプロンプトに基づいて高度にカスタマイズされた非決定論的な出力を生成できるため、潜在的な誤用や悪用の可能性をもたらし、新たなセキュリティ課題をもたらします。さらに、大規模でカスタマイズされたデータセットへのアクセスに依存しており、多くの場合、機微情報を含む可能性のある内部データソースを利用します。 LLM を活用することは比較的新しい実践であり、独特で微妙なセキュリティリスクと影響を伴いますが、LLM はより大きなワークロードの一部分に過ぎないことを忘れないことが重要です。システムの各パーツに脅威モデリングのアプローチを適用し、インジェクションや認証情報の侵害といった既知の脅威を考慮に入れることが重要です。AWS ブログシリーズ「生成 AI をセキュアにする」のパート 1 「 生成 AI セキュリティスコーピングマトリックスの紹介 」では、これらの微妙な点について優れた概要を提供し、組織での LLM の使用方法によってリスクがどのように異なるかを説明しています。 生成 AI における脅威モデリングの 4 つのステージ 簡単な復習として、脅威モデリングは、特定のシステムやアプリケーションにおけるセキュリティリスクを特定し、理解し、対処し、伝えるための構造化されたアプローチです。これは設計フェーズの基本的な要素であり、適切な緩和策を特定して実装し、できるだけ早期に基本的なセキュリティの決定を行うことを可能にします。 AWS では、脅威モデリングは AWS の開発者チーム向けアプリケーションセキュリティ (AppSec) プロセスを開始するために必要なインプットであり、開発者チームは セキュリティガーディアン からサポートを受けて、機能やサービスの脅威モデルを作成します。 専門家の Adam Shostack が考案した脅威モデリングへのアプローチを構造化する有用な方法は、 4 つの重要な質問に答えることです。これらの質問が生成 AI ワークロードにどのように適用するかを見ていきます。 何に取り組んでいるのか？ 何が問題になり得るか？ それについて何をするのか？ 十分な対応ができているか？ 何に取り組んでいるのか？ この質問は、ビジネスコンテキストとアプリケーションアーキテクチャについての詳細な理解を得ることを目的としています。求める詳細情報は、すでに生成 AI ソリューションの開発者によって作成された包括的なシステム文書の一部として捕捉されているはずです。この文書から始めることで、脅威モデリングのプロセスを効率化し、基本的なシステムの知識を再構築するのではなく、潜在的な脅威と脆弱性の特定に焦点を当てることができます。 アウトプットや検討結果の例 開発者は少なくとも、データフロー、前提条件、設計上の決定事項を含む、ソリューションの主要コンポーネントを把握する必要があります。これは潜在的な脅威を特定するための基礎となります。文書化すべき主要な要素は以下の通りです。 リクエストから応答までアプリケーションの主要なデータの流れを示すデータフロー図 (DFD) 。各コンポーネントまたは hop（訳者注 :hop とはデータがあるコンポーネントから別のコンポーネントへ遷移する、DFD の線の部分に該当します）で何が起こるかを詳細に説明します。 ユーザーがシステムとどのような対話をするか、またはモデルがシステムとどのようなやりとりをするかを、明確にした前提条件。例えば、RAG シナリオにおいて、モデルが他のシステムに保存されたデータを取得する必要がある場合、どのように認証を行い、そのデータをユーザーにとって適切な応答に変換するか、などを含みます。 ビジネスによって下された重要な設計上の決定事項の文書化。これには決定の背景にある根拠も含みます。 アプリケーションに関する詳細なビジネスコンテキスト。例えば、重要システムとみなされるかどうか、扱うデータの性質（機密性、完全性、可用性など）、アプリケーションの主要なビジネス上の懸念事項（データの機密性、データの整合性、システムの可用性など）を含みます。 図 1 は、Threat Composer が Application Information（アプリケーション情報） 、 Architecture（アーキテクチャ） 、 Dataflow（データフロー） 、および Assumptions（前提条件） のセクションでアプリケーションに関する情報を入力する方法を示しています。 図 1: 生成 AI チャットボットの例に関する Threat Composer のデータフロー図 何が問題になり得るか? この質問では、前の質問で収集したコンテキストと情報を使用し、アプリケーションに対する潜在的な脅威を特定します。可能性のある脅威を特定するために、既存の情報源を活用してください。特に採用する新技術に関連するものを重視してください。多くの場合、アプリケーションに適用できる具体的な例が含まれています。有用なリソースとしては、 OWASP top 10 for LLMs 、 MITRE ATLAS framework 、 AI Risk Repository などがあります。また、 STRIDE などの構造化されたフレームワークを活用することもできます。「何を構築しているのか ? 」という質問から得た情報から、最も関連性の高い STRIDE カテゴリを適用してください。例えば、アプリケーションがビジネスにとってリスクを許容できない重要なデータを扱う場合、まず情報漏洩の脅威について様々な角度から検討する必要があるかもしれません。 アプリケーションに対する潜在的な脅威は、脅威ステートメントの形式で記述・文書化することができます。脅威ステートメントは、脅威を文書化する際の一貫性と簡潔性を維持するための方法です。 AWS では、以下の構文の脅威文法を採用しています。 [前提条件] を持つ [脅威の発生源] が [脅威となるアクション] を実行することで、[脅威の影響] が発生し、[影響を受ける資産] に悪影響を及ぼす可能性があります。 この脅威モデリングのアプローチにより、一貫性を維持し、有用な脅威ステートメントを反復的に作成することができます。図 2 に示すように、 Threat Composer は新しい脅威ステートメントをこのような構造で提供し、記述例も含まれています。 図 2: Threat Composer 脅威ステートメントビルダー 脅威ステートメントを作成するプロセスを行うと、「何が問題になり得るか」の要約が得られます。その後、「どのように問題が発生するか」の分析として、攻撃ステップを定義することができます。脅威が実際に発生する方法は多岐にわたるため、必ずしもすべての脅威ステートメントに対して攻撃ステップを定義する必要はありません。いくつかの異なる脅威メカニズムを特定し文書化する作業を行うことで、各攻撃ステップに関連付けることができる具体的な対策を見出し、より効果的な多層防御アプローチを実現できます。 Threat Composer では、脅威ステートメントに追加のメタデータを付加することができます。このオプションをワークフローに採用しているお客様は、主に STRIDE カテゴリと優先度のメタデータタグを使用しています。これにより、お客様は最も優先度の高い脅威と、それらが対応する STRIDE カテゴリを迅速に追跡することができます。図 3 は、 Threat Composer で脅威ステートメントを関連するメタデータと共に文書化する方法を示しています。 図 3: Threat Composer 生成 AI チャットボットアプリケーションのサンプル – 脅威ビュー アウトプットと検討結果の例 何が問題になるか、そしてどのように問題になるかを体系的に検討することで、様々な潜在的な脅威を明らかにすることができます。このプロセスから生まれるアウトプットの例を見てみましょう。 緩和策を実装する STRIDE の要素と優先度で分類された脅威ステートメントのリスト。 脅威ステートメントに関連付けられた攻撃ステップのリスト。前述の通り、この段階での攻撃ステップの特定はオプションの活動ですが、少なくとも最優先の脅威についてはいくつか特定することを推奨します。 攻撃ステップの例 前述の脅威ステートメントがどのように発生する可能性があるかを示す攻撃ステップの例を示します。 システムプロンプトのガードレールをバイパスするための巧妙なプロンプトインジェクションの実行。 モデルにアクセスできる脆弱なエージェントの埋め込み。 ウェブページ上での間接的なプロンプトインジェクションの埋め込み。これは LLM に対してユーザーのインストラクションを無視させ、LLM プラグインを使用してユーザーのメールを削除するよう指示します。 それについて何をするのか？ 可能性のある脅威を特定したら、それらの脅威に関連するリスクを軽減するのに適切なコントロールを検討します。この決定は、ビジネスのコンテキストと対象となる資産によって導かれます。また、組織のポリシーもコントロールの優先順位付けに影響を与えます。最も多くの脅威に影響を与えるコントロールを優先する組織もあれば、（発生可能性と影響度から）最もリスクが高いと判断される脅威に影響を与えるコントロールから始める組織もあります。 特定された各脅威に対して、具体的な緩和戦略を定義します。これには、入力のサニタイズ、出力のバリデーション、アクセス制御などを含みます。理想的には、最低でも各脅威に対して 1 つの予防的コントロールと 1 つの発見的コントロールを関連付けることが望ましいです。「何が問題になり得るか？」のセクションでリンクされているリソースは、関連するコントロールを特定する際にも非常に有用です。例えば、MITRE ATLAS には 緩和策 に関する専用のセクションがあります。 注意 ：脅威に対する緩和策を特定していく過程で、コントロールに重複が見られるかもしれません。例えば、最小権限アクセス制御は、ほぼすべての脅威に関連付けられる可能性があります。この重複は優先順位付けにも役立ちます。ある 1 つのコントロールが脅威への緩和策の 90% に現れる場合、そのコントロールを効果的に実装することで、それらの脅威それぞれのリスクを低減することができます。 アウトプットと検討結果の例 各脅威に関連して、後で検索や再利用を容易にするために一意の識別子を持つ緩和策のリストを用意する必要があります。識別子付きの緩和策の例は以下の通りです。 M-001: SQL クエリ構造の事前定義 M-002: 既知のパラメータのサニタイズ（入力のフィルタリング） M-003: テンプレート化されたプロンプトパラメータとの照合 M-004: 出力がユーザーに関連していることの確認（出力のフィルタリング） M-005: LLM のコンテキストウィンドウの制限 M-006: モデルによって実行される高リスクアクションに対する動的な権限チェック（認証パラメータをプロンプトから分離する） M-007: アプリケーションのすべてのコンポーネントへの最小権限の適用 生成 AI ワークロードに関連するセキュリティコントロールの詳細については、生成 AI をセキュアにするシリーズのパート 3: 関連するセキュリティコントロールの適用 をご確認ください。 図 4 は、Threat Composer で完成した脅威ステートメントの例を示しており、それぞれに緩和策がリンクされています。 図 4: メタデータや関連付けられた緩和策を含む完成した脅威ステートメント 最初の 3 つの質問に答えることで、脅威モデルが完成します。文書には、データフロー図（DFD）、脅威ステートメント、[オプションの] 攻撃ステップ、および緩和策が含まれているはずです。 脅威サマリーの内訳を示す視覚的なダッシュボードを含む、より詳細な例については、Threat Composer の 生成 AI チャットボットの例 を参照してください。 十分な対応ができているか？ 脅威モデルは生きた文書です。本ブログでは、脅威モデルの作成が脅威に対する技術的コントロールを特定するのにどのように役立つかを説明してきましたが、脅威モデリングのプロセスがもたらす非技術的な利点も考慮することが重要です。 最後の活動として、脅威モデリング活動の両要素を検証する必要があります。 特定された緩和策の有効性の検証 ：特定した緩和策の中には新しいものもあれば、すでに導入されているものもあるかもしれません。いずれにせよ、セキュリティ対策が意図したとおりに機能しているかを継続的にテストし検証することが重要です。これには、ペネトレーションテストや自動化されたセキュリティスキャンが含まれる場合があります。AWS では、脅威モデルはパイプラインに組み込まれる自動テストケースへのインプットとして機能します。また、定義された脅威は、それらの脅威が十分に緩和されているかを確認するために、ペネトレーションテストの範囲を定義するためにも使用されます。 プロセスの有効性の検証 ：脅威モデリングは本質的に人間の活動です。ビジネス、開発チーム、セキュリティ機能の間での相互作用が必要です。アプリケーションの作成と運用に最も近い人々が脅威モデルの文書を所有し、セキュリティチーム（またはセキュリティガーディアン相当）のサポートを受けながら、頻繁に見直すべきです。これをどの程度の頻度で行うかは、組織のポリシーやワークロードの重要性によって異なりますが、脅威モデルの見直しを開始するトリガーを定義することが重要です。トリガーの例としては、脅威インテリジェンスの更新、データフローを大きく変更する新機能、システムのセキュリティ関連の側面（認証や認可、ログ記録など）に影響を与える新機能などが挙げられます。特に新技術を採用する場合は、脅威の状況が通常よりも速く進化するため、定期的にプロセスを検証することが重要です。 脅威モデリングプロセスの振り返りを行うことは、何がうまくいき、何がうまくいかなかったか、そして次回の脅威モデルを見直す時にどのような変更を行うかを検討し議論する良い方法でもあります。 出力例 このプロセスのステップにおける出力例は以下の通りです。 緩和策に基づく自動テストケースの定義 ペネトレーションテストの定義された範囲と、脅威に基づくテストケース アプリケーションの文書（データフロー図を含む）と共に保存される、生きた文書としての脅威モデル 脅威モデリング参加者からの教訓とフィードバック、および次回の改善に向けたレトロスペクティブの概要 まとめ 本ブログでは、生成 AI ワークロードに対する実践的かつプロアクティブな脅威モデリングのアプローチを探りました。取り上げた主要なステップは、ビジネスコンテキストとアプリケーションアーキテクチャの理解から、潜在的な脅威の特定、緩和戦略の定義、そしてプロセス全体の有効性の検証に至るまで、効果的な脅威モデリングを実施するための構造化されたフレームワークを提供しています。 このアプローチに従うことで、組織は生成 AI 技術を採用する際に高いセキュリティ基準を維持するための準備を整えることができます。脅威モデリングプロセスは、既知のリスクを緩和するだけでなく、組織が採用すべき重要なセキュリティ志向の文化も育成します。これにより、システムとデータのセキュリティとプライバシーを維持しながら、強力な技術の可能性を最大限に引き出すことができます。 生成 AI セキュリティのその他の領域についてさらに詳しく知りたい場合は、生成 AI をセキュアにするシリーズの他のブログをご覧ください。 パート 1 — 生成 AI をセキュアにする : 生成 AI セキュリティスコーピングマトリックスの紹介 パート 2 — 生成 AI ワークロードにおけるレジリエンス設計 パート 3 — 生成 AI をセキュアにする：関連するセキュリティコントロールの適用 パート 4 — 生成 AI をセキュアにする：データ、コンプライアンス、プライバシーに関する考慮点 著者について Danny Cortegaca Danny は、セキュリティスペシャリストソリューションアーキテクトであり、AWS Industries のテレコム部門のリーダーです。2021 年に AWS に入社し、世界最大規模の組織と協力して、複雑なセキュリティと規制環境への対応を支援しています。顧客とアプリケーションセキュリティについて話し合うことを好み、多くの組織が脅威モデリングを実践に取り入れることを支援してきました。 Ana Malhotra Ana は以前、AWS でセキュリティスペシャリストソリューションアーキテクトとして働き、AWS Industry の Healthcare and Life Sciences（HCLS）セキュリティリードを務めていました。現在は AWS を退職しています。元 AWS アプリケーションセキュリティエンジニアとして、人、プロセス、テクノロジーを含むアプリケーションセキュリティに関するあらゆる話題について語ることを好んでいました。余暇には、音楽やダンスで創造的な一面を発揮することを楽しんでいました。 Kareem Abdol-Hamid Kareem は、スタートアップ向けのシニアアクセラレーテッドコンピュートスペシャリストです。アクセラレーテッドコンピュートのスペシャリストとして、生成 AI、ハイパフォーマンスコンピューティング、大規模ワークロードに関する新しい課題に日々取り組んでいます。余暇にはピアノを弾き、ビデオゲーム「ストリートファイター」で競技を行っています。 翻訳はプロフェッショナルサービスの舘、藤浦が担当しました。

本記事は 2024 年 11 月 27 日に公開された “ Leverage powerful generative-AI capabilities for Java development in the Eclipse IDE public preview ” を翻訳したものです。 本日、世界中の Eclipse 開発者にとって画期的な一歩となるお知らせをいたします。Eclipse IDE における Amazon Q Developer のパブリックプレビューの提供を開始します。この統合により、最も人気のある開発環境の 1 つに、AI 駆動の開発機能が直接組み込まれることになります。この記事では、この革新的な機能の詳細と、従来の IDE と最先端の AI の融合がソフトウェア開発ライフサイクル全体でどのように開発タスクを強化するかについてご紹介します。 背景 この発表を書きながら、懐かしさと興奮が入り混じった感情を覚えます。Amazon Q Developer において Eclipse は最も要望の多い IDE の 1 つであり、その理由が私にはわかります。私と同世代の多くの開発者にとって、Eclipse は Java プログラミングの入り口でした。あの大容量の IDE をダウンロードし、インストールが終わるまで永遠とも思える時間を待ち、そしてワークスペースを見つめながら、その可能性に怖気付きながらも胸を躍らせていたことを覚えています。 Eclipse は 20 年以上にわたり、ソフトウェア開発の世界で多くの開発者に支持されてきました。J2SE の初期から現代の Java プラットフォームまで、その進化に寄り添ってきました。数多くの開発者にとって、Eclipse は単なる IDE を超えた、開発の旅路における信頼できる仲間でした。 しかし、時代は変化しています。ソフトウェア開発の状況は急速に進化しており、その革新の中心にあるのが生成 AI です。コーディング、テスト、アプリケーションのデプロイメントへのアプローチは、パラダイムシフトを迎えています。そして本日、慣れ親しんだ Eclipse と最先端の Amazon Q Developer の機能を組み合わせた、画期的な統合をお知らせできることを嬉しく思います。 Eclipse IDE 向け Amazon Q Developer プラグインの紹介 Amazon Q Developer は、ソフトウェア開発ライフサイクル全体を再考する、最も高機能な AI 搭載の開発支援アシスタントです。AWS を活用して、アプリケーションの構築、セキュリティ確保、管理、最適化をより容易かつ迅速に行うことができます。こうした原動力のあるツールを Eclipse に直接統合することで、我々は単に機能を追加するだけではなく、Java 開発者にとっての新たな可能性の世界を開きます。Java 開発の熟練者であれ、開発の旅を始めたばかりの方であれ、Eclipse IDE 向けの Amazon Q Developer は、コーディングを含むソフトウェア開発ライフサイクル全体のタスクを加速する、不可欠な生成 AI アシスタントとなるでしょう。 パブリックプレビューでは、Eclipse を利用する開発者はプロジェクトについて Amazon Q Developer とチャットを行い、インラインコード提案機能でコーディングを加速することができます。Amazon Q Developer のカスタマイズ機能を活用することで、チーム内部のツールやサービスに合わせた回答を得ることができ、ソフトウェア開発ライフサイクル全体での生産性を向上させながら、より迅速な開発が可能になります。パブリックプレビューで利用可能な機能について見ていきましょう。 インライン提案機能 インラインコード提案機能は、Amazon Q Developer の AI 機能を体験する優れた入り口です。文字をタイプすると、Amazon Q Developer はあなたのコード、コメント、命名規則を分析して、文脈を考慮した提案を提供します。なお、コードドキュメントが包括的で整理されているほど、Amazon Q Developer の提案はより正確で有用なものとなります。 チャット機能 Amazon Q Developer のチャットインターフェースは、様々な開発ニーズに対応する多目的ツールです。コードスニペットの提案を求めたり、プロジェクトについて質問したり、特定の機能の実装についてガイダンスを求めたりすることができます。例えば、Java で高速フーリエ変換を計算するサンプルコードを依頼したり、データベースクラスに UUID を使用する追加フィールドを実装する方法について助言を求めたりできます。 また、Amazon Q Developer とのチャットのやり取りにコードスニペットをシームレスに統合することもできます。コードの一部を選択し、エディタ上で右クリックして Amazon Q > Send To Prompt を選択することで、コードをチャットウィンドウに送り、コードについて具体的な質問をしたり修正を依頼したりでき、よりインタラクティブでコンテキストを考慮したコーディング体験が可能になります。 また、右クリックメニューを使用して、選択したコードスニペットの説明、リファクタリング、修正、最適化を Amazon Q Developer に依頼することもできます。 カスタマイズ機能 カスタマイズ機能により、Amazon Q Developer はチーム内部のライブラリ、プロプライエタリなアルゴリズム技術、企業のコーディングスタイルに準拠しながらソフトウェア開発を支援することができます。カスタマイズ機能は最初に管理者による設定が必要です。その後、IDE 内の Amazon Q Developer パネルのメニューから選択して使用できます。詳細については、 ユーザーガイドをご参照ください 。 まとめ Eclipse IDE 向け Amazon Q Developer プラグインのプレビューは、この信頼性の高いプラットフォームにおいて開発体験を大きく向上させるための重要な一歩を象徴しています。インラインコード提案やチャットなどの AI 駆動ツールを統合することで、Amazon Q Developer は開発者がより効率的に様々なプログラミングタスクに取り組むことを可能にします。レガシーコードの保守、新機能の開発、複雑な問題のトラブルシューティングなど、どのような作業においても Amazon Q Developer はワークフローを効率化し、最も重要な『優れたコードの作成』に集中することを可能にします。 利用を開始するには、Eclipse IDE に Amazon Q Developer プラグイン をインストールしてください。 このブログの翻訳はソリューションアーキテクトの三尾が担当しました。

12 月 16 日、Hewlett Packard Enterprise (HPE) とのコラボレーションを介して構築され、EC2 High Memory ファミリーに新しく追加される Amazon Elastic Compute Cloud (Amazon EC2) U7inh インスタンス の一般提供についてお知らせします。 AWS Nitro System 上に構築された Amazon EC2 U7inh インスタンスは、16 ソケットの HPE Compute Scale-Up Server 3200 上で実行し、他の EC2 インスタンスと同様に、完全に統合および管理されたエクスペリエンスを提供します。 第 4 世代 Intel ® Xeon ® スケーラブルプロセッサー (Sapphire Rapids) を搭載した U7inh インスタンスは、32 TB のメモリと 1920 個の vCPU をサポートします。このインスタンスでは、SAP HANA のような大規模でミッションクリティカルなデータベースワークロード向けに Amazon Web Services (AWS) クラウドの中で最高のコンピューティングパフォーマンス、最大のコンピューティングとメモリサイズを利用できます。 2024 年 5 月、最大 896 個の vCPU と最大 32 TB のメモリをサポートする U7i インスタンス がリリースされ、エンタープライズのお客様は、大規模でミッションクリティカルなインメモリデータベースを AWS に正常に移行し、AWS が提供する柔軟性、スケーラビリティ、信頼性、コストのメリットを活用できるようになりました。 お客様がビジネスアプリケーションのスケールを続けるにしたがって、SAP 認定とともに、リアルタイムのビジネスインサイトを生成するために追加の CPU とメモリと組み合わせたパフォーマンスが求められるようになりました。現在 HPE サーバーを使用してオンプレミスで運用している他のお客様からも HPE ハードウェアを引き続き使用しながらクラウドのメリットを活用するために AWS への移行する際に AWS がどのように役立つのかという質問が寄せられています。 新しい U7inh インスタンスの詳細な仕様を以下に示します。 インスタンス名 vCPU メモリ (DDR5) EBS 帯域幅 ネットワーク帯域幅 U7inh-32tb.480xlarge 1920 個 32,768 GiB 160 Gbps 200 Gbps 最大規模の U7i インスタンスに比べて、U7inh インスタンスは、1 つのインスタンスで最大 2 倍の vCPU と 1.6 倍の EBS 帯域幅を提供します。SAP HANA のような大規模インメモリデータベースワークロードを実行することや、HPE ハードウェア上で実行しているワークロードを AWS にシームレスに移行することが可能です。 U7inh インスタンスは、Amazon Linux、Red Hat Enterprise Linux、SUSE Enterprise Linux Server をサポートします。High Memory インスタンス上の SAP HANA ワークロードのオペレーティングシステムのサポートには、SUSE Linux Enterprise Server for SAP Applications 15 SP3 以上 と Red Hat Enterprise Linux 8.6/9.0 for SAP が含まれます。 U7inh インスタンスは、本番環境で Business Suite S/4HANA (SoH)、Business Warehouse on HANA (BW)、SAP BW/4HANA を実行するための SAP 認定を受けています。U7inh インスタンスは S/4HANA などのスケールアウト SAP HANA OLTP ワークロード向けにも認定されているので、さらに大規模な SAP HANA ワークロードに対応するために 1 つのクラスターに最大 4 つの U7inh インスタンス (128 TB) をデプロイできます。 移行方法の詳細については、「SAP HANA on AWS ガイド」の「 Migrating SAP HANA on AWS to an EC2 High Memory Instance 」と「AWS Launch Wizard for SAP ユーザーガイド」の「 AWS Launch Wizard for SAP 」を参照してください。 今すぐご利用いただけます Amazon EC2 U7inh インスタンスは、米国東部 (バージニア北部) と米国西部 (オレゴン) の AWS リージョン でご利用いただけます。 詳細については、 U7i インスタンスの製品ページ にアクセスしてください。フィードバックは、 AWS re:Post for EC2 、または通常の AWS サポートの担当者までお寄せください。 – Channy 原文は こちら です。

2024 年 11 月 21 日に 製造業の設計開発領域向けセミナー を開催いたしましたのでご報告致します。 近年、製造業の設計・開発領域においてもデジタルトランスフォーメーションが欠かせないものとなっており、デジタル活用による効率化・自動化を促進し、製品設計の期間短縮による新製品のマーケットへの迅速な投入による競争力の強化が求められています。設計・開発領域のデジタル化では AWS の仮想デスクトップを活用した CAD による設計、AWS の HPC を活用した CAE があり、それぞれの領域で新しいサービスをリリースしております。 本セミナーでは実際に AWS のクラウド HPC を活用されている製造業のお客様の事例として、三菱重工業株式会社様とウシオ電機株式会社様にご登壇いただきました。また、AWS からは Research and Engineering Studio on AWS (RES on AWS) / AWS Parallel Computing Service (AWS PCS) を紹介しました。このブログでは、当日のセッションの内容について簡単にご紹介いたします。 セッション内容 「製造業の設計開発領域向けセミナー オープニング」 アマゾンウェブサービスジャパン合同会社 自動車・製造事業開発本部 製造設計領域　担当部長　舛重 国規 AWS 舛重からは製造設計領域における CAE/CAD/PLM のモダナイゼーション、これからの研究開発組織のクラウド利用のあり方、クラウド導入・利用の選択肢、AWS の HPC、VDI 構築ソリューションの選択肢や SIEMENS 様、ANSYS 様との戦略的パートナーシップについてご紹介しました。 [ 資料 ] 「AWS と共に実現するカーボンニュートラル社会 (HPC on AWS の概念実証結果について) 」 三菱重工業株式会社 GTCC事業部 蒸気タービン技術部　田畑 創一朗 氏 三菱重工業 田畑様からは AWS 上で High Performance Computing (HPC) の概念実証 (PoC) を実施した結果を中心に講演いただきました。PoC ではクラウド上でスケーラブルな HPC リソースをすばやく構築できることと、従来のオンプレミス環境と比較して、コスト削減とリソース調達の柔軟性が得られることを実証いただきました。加えて、講演の中ではクラウドネイティブ HPC による設計最適化の可能性、実装の詳細と得られた知見を共有いただき、今後の設計探査への展望もお話いただきました。 「Simcenter X (Cloud HPC) 導入へむけて」 ウシオ電機株式会社 光プロセス事業部 EUV プロジェクト 要素技術開発チーム　信田 和彦 氏 ウシオ電機様では Simcenter STAR-CCM+ 導入時より Power on Demand ライセンスと計算用クラウド環境を整備されており、信田様からはシミュレーションの需要増加に伴い、計算環境の増強とコスト低減を目的として Simcenter X (Cloud HPC) の導入を検討された話を共有いただきました。講演では社内で最も計算負荷を要するシミュレーションモデルを使用し、従来の計算環境と Cloud HPC での並列化効率と運用コストを検証した結果を共有いただきました。 ※Simcenter X は AWS HPC/VDI を活用した Simcenter STAR-CCM+ の SaaS サービスです https://plm.sw.siemens.com/ja-JP/simcenter/cloud/simcenter-x/ 「Research and Engineering Studio on AWS の概要」 アマゾンウェブサービスジャパン合同会社 エンタープライズ技術本部　ハイテク・製造・自動車産業グループ 製造第一ソリューション部　吉廣 理 AWS 吉廣からは Research and Engineering Studio on AWS (RES on AWS) を紹介しました。RES on AWS は研究開発チームがクラウドの専⾨知識を必要とせずに、CAD や CAE などのワークロードを実⾏できる環境を管理および構築するための使いやすいウェブベースのポータルです。本セッションでは概要のご紹介と、デモを通して RES on AWS の使い方をご紹介しました。 [資料] 「AWS Parallel Computing Service (AWS PCS) による新しい HPC クラスタ管理方法」 アマゾンウェブサービスジャパン合同会社 エンタープライズ技術本部　西日本ソリューション部　森 啓 AWS 森からは 2024年 8月にリリースした AWS Parallel Computing Service (AWS PCS) を紹介しました。従来は AWS 上で HPC の検討をいただく場合、 AWS ParallelCluster や AWS Batch が選択肢でしたが、AWS PCS では学習コストを抑えて、マネージドな HPC クラスターを簡単に構築・運用することができるようになりました。インフラの管理負荷を軽減しつつ、柔軟性と拡張性を提供するソリューションとなっています。本セッションでは AWS PCS の基本的な機能の説明と、デモを通して PCS の使い方をご紹介しています。 [資料] 「クロージング」 アマゾンウェブサービスジャパン合同会社 自動車・製造事業開発本部 製造設計領域　担当部長　舛重 国規 最後に AWS 舛重から AWS Graviton プロセッサ の利用における二酸化炭素排出量削減効果、CAE での GPU 利用や機械学習・生成 AI の活用についてご紹介しました。また、皆様の現場の課題において、AWS を活用することで解決できる事がないか、AWS もお客様と一緒に考え、ソリューションを検討・支援させていただく旨をお約束しました。 おわりに 今回は AWS をご活用いただいている製造業のお客様から、クラウド HPC の活用事例を共有いただきました。AWS からは Research and Engineering Studio on AWS (RES on AWS)、AWS Parallel Computing Service (AWS PCS) をご紹介しました。AWS の製造業に対する取り組みは こちら にまとめています。AWS のコンピュートサービスに関連する今後のセミナー予定は こちら に掲載しています。今後も引き続き、様々な切り口からのセミナーを企画して参りますので、皆様のご参加を心待ちにしております。 このブログはソリューションアーキテクトの森が担当致しました。

本ブログは 2024 年 12 月 5 日に公開された「 Advancing AI trust with new responsible AI tools, capabilities, and resources 」を翻訳したものです。 生成 AI がさまざまな業界や私たちの日常生活にわたって革新を続ける中、責任ある AI の必要性がますます重要になってきています。AWS では、AI の長期的な成功は、ユーザー、顧客、そして社会からの信頼を得る能力にかかっていると考えています。この信念は、AI を責任を持って構築し使用するという私たちの長年のコミットメントの中心にあります。責任ある AI とは、リスクを軽減し、関連する基準や規制に適合させることにとどまりません。それは積極的に信頼を構築し、ビジネス価値を促進する AI の潜在能力を引き出すことです。責任ある AI への包括的なアプローチは、組織が大胆に革新し、変革的なビジネス成果を達成する力を与えます。 Accenture と AWS が実施した新たな共同調査 はこの点を裏付けており、責任ある AI がビジネス価値の重要な推進力であることを強調しています。製品品質、業務効率、顧客のロイヤルティ、ブランド認知度などを向上させるのです。調査対象企業のほぼ半数が、AI 関連の収益成長を推進する上で責任ある AI が重要であると認識しています。なぜでしょうか？責任ある AI は信頼を構築し、その信頼が AI の採用とイノベーションを加速させるからです。 信頼が AI 導入の礎となる中、私たちは AWS re:Invent 2024 で責任ある AI に関する新しいツール、機能、リソースの発表をお知らせします。これらは、私たちの AI サービスとモデルの安全性、セキュリティ、透明性を向上させ、お客様自身の責任ある AI の取り組みをサポートするものです。 AI のリスクを管理し、信頼と相互運用性を育むための積極的な取り組みを行う AWS は、主要なクラウドサービスプロバイダーとして初めて、 Amazon Bedrock 、 Amazon Q Business 、 Amazon Textract 、 Amazon Transcribe を対象とする AI サービスに関する ISO/IEC 42001 認証取得 を発表しました。ISO/IEC 42001 は、組織がライフサイクルを通じて責任を持って AI システムを管理するための要件を概説する国際的なマネジメントシステム規格です。ISO/IEC 42001 のような技術的な規格は、責任ある AI の開発と展開のための共通的なフレームワークを提供し、ますますグローバル化し AI ドリブンな技術環境における信頼性と相互運用性を育むために重要です。ISO/IEC 42001 認証を取得したということは、AWS が AI の開発、展開、運用に関連するリスクと機会を管理するために積極的な措置を講じていることを、独立した第三者が検証したことを意味します。この認証により、AWS はお客様が AI を活用して責任を持ってイノベーションを実現できるよう、AI サービスの提供に対するコミットメントを強化します。 Amazon Bedrock ガードレールでの安全対策を拡張し、透明性と安全性を改善する （訳者注：2024 年 12 月 20 日時点で、Amazon Bedrock ガードレールは英語のみをサポートしています） 2024 年 4 月に、 Amazon Bedrock ガードレール の一般提供を発表しました。これにより、生成 AI アプリケーションに対する安全性と責任ある AI チェックの適用が容易になりました。Amazon Bedrock ガードレールは、基盤モデル（FM）が提供するネイティブな保護機能に加えて、有害なコンテンツを最大 85% 以上ブロックし、検索拡張生成（RAG）や要約のユースケースにおいてコンテキストに基づくグラウンディングチェックを使用してモデルからのハルシネーションを含む応答を 75% 以上フィルタリングすることで、業界をリードする安全性の保護を提供します。これらの安全対策を実装する能力は、AI システムへの信頼構築において大きな一歩でした。FM の進歩にもかかわらず、モデルはまだハルシネーションを生み出す可能性があり、これは多くのお客様が直面している課題です。正確性が重要なユースケースでは、お客様は数学的に健全な技術と説明可能な推論を使用して、正確な FM の応答を生成する必要があります。 このニーズに対応するため、私たちは Amazon Bedrock ガードレールに新しい安全対策を追加しています。これにより、FM のハルシネーションによる事実誤認を防ぎ、検証可能な証明を提供することを目指しています。 Amazon Bedrock ガードレールの自動推論チェック （プレビュー）をローンチすることで、AWS は主要なクラウドプロバイダーとして初めて、生成 AI サービスに自動推論を統合しました。自動推論チェックは、健全な数学的・論理的アルゴリズムによる検証と推論プロセスを使用して、モデルが生成した情報を検証します。これにより、出力はハルシネーションや矛盾したデータにを基にせず、提供された事実に沿ったものとなります。プロンプトエンジニアリング、RAG、コンテキストに基づくグラウンディングチェックなどの他の技術と併用することで、自動推論チェックは LLM が生成する出力の精度を向上させるためのより厳密で検証可能なアプローチを追加します。ドメイン知識を構造化されたポリシーにエンコードすることで、会話型 AI アプリケーションがユーザーに信頼性の高い情報を提供することができます（訳者注：自動推論チェックを利用する過程で、組織のルール、手順、ガイドラインを構造化された数学形式にエンコードする自動推論ポリシーを作成できます。その後、これらのポリシーを使用して、LLM を利用したアプリケーションによって生成されたコンテンツがガイドラインと一致していることを確認できます。）。 以下の画像をクリックすると、Amazon Bedrock ガードレールにおける自動推論チェックのデモをご覧いただけます。 ビジネス価値の促進、意思決定の改善、カスタマーエクスペリエンスの向上を目的として、マルチモーダルデータを含むアプリケーションを使用する組織が増えるにつれ、コンテンツフィルターの必要性はテキストだけにとどまりません。Amazon Bedrock ガードレールは現在、画像コンテンツに対する マルチモーダルの有害性検出 （プレビュー）をサポートしています。これは組織が安全で関連性のある視覚的要素を保持しながら、望ましくない潜在的に有害な画像コンテンツを検出してフィルタリングするのに役立ちます。マルチモーダルでの有害性検出は、画像データ用の独自の安全対策を構築したり、エラーが発生しやすく退屈な手動評価に時間を費やしたりする必要性を軽減します。Amazon Bedrock ガードレールは、ユーザーとの信頼関係を構築するのに役立ち、責任を持って生成 AI アプリケーションを作成するのを支援します。 新しい Amazon Bedrock の評価機能により生成 AI アプリケーションの応答と品質を改善する より多くの汎用 FM が選択できるようになり、組織は現在、生成 AI アプリケーションを強化するための幅広い選択肢を持っています。しかし、特定のユースケースに最適なモデルを選択するには、組織が必要とする品質と責任ある AI の指標に基づいてモデルを効率的に比較する必要があります。評価は信頼性と透明性を構築する上で重要な部分ですが、新しいユースケースごとに多大な時間、専門知識、リソースを要するため、最も正確で安全な顧客体験を提供するモデルを選択することが困難になっています。 Amazon Bedrock Evaluations によりユースケースに最適な FM を評価、比較、選択できることでこの課題に対応します。現在、モデル評価に LLM-as-a-judge（プレビュー）を使用して、データセットに対して人間のような品質でテストを実行し、評価対象とする他のモデルを評価できます。Amazon Bedrock でホストされているさまざまな LLM から “judge“ を選択でき、正確性、完全性、有害性などの品質と責任ある AI の指標が用意されています。また、独自のプロンプトデータセットを持ち込んでデータを使用して評価をカスタマイズし、評価ジョブ間で結果を比較してより迅速に決定を下すことができます。以前は、人間によるモデル評価と、完全一致や他の従来の自然言語処理（NLP）指標を使用した自動評価のいずれかを選択する必要がありました。これらの方法は高速でしたが、人間の評価者との強い相関関係はありませんでした。現在、LLM-as-a-judge を使用することで、完全な人間ベースの評価よりもはるかに低コストで人間のような評価品質を得ることができ、最大数週間の時間を節約できます。多くの組織は依然として、最終的な評価を専門家の人間のアノテーターから得ることを望んでいます（訳者注：アノテーションとは分析対象データに対してラベルを付与することを指し、これを行う役割をアノテーターといいます）。このため、Amazon Bedrockは引き続き、独自の作業チームを利用する、または AWS がカスタム評価を管理する、人間ベースの評価のオプションを提供しています。 FM に最新の、また独自の情報を提供するために、組織は RAG を使用します。これは会社のデータソースからデータを取得し、プロンプトを強化してより関連性の高い正確な応答を提供する技術です。しかし、検索と生成のコンポーネントを最適化する複雑さのため、RAG アプリケーションの評価と最適化は困難な場合があります。これに対処するため、 Amazon Bedrock ナレッジベース に対する RAG 評価をサポートしました（プレビュー中）。この新しい評価機能により、データと LLM がすでに存在する環境で、RAG アプリケーションを便利かつ迅速に評価および最適化できるようになりました。LLM-as-judge の技術を活用した RAG 評価は、複数の評価用モデルと、コンテキストの関連性、コンテキストのカバレッジ、正確性、忠実性（ハルシネーションの検出）などの複数の指標を選択できます。このシームレスな統合により、定期的な評価が促進され、AI アプリケーション開発における継続的な改善と透明性の文化が育成されます。人間ベースの評価と比較してコストと時間の両方を節約することで、これらのツールは組織が AI アプリケーションを強化し、一貫した改善を通じて信頼を構築することを可能にします。 モデルと RAG の評価機能は、いずれも出力ファイルと AWS マネジメントコンソール 上で各スコアに対する自然言語の説明を提供します。スコアは解釈しやすいように 0 から 1 に正規化されています。非科学者でもスコアの導出方法を理解できるように、評価基準は評価用プロンプトとともにドキュメントに完全に公開されています。モデルと RAG の評価機能の詳細については、 ニュースブログ をご覧ください。 責任ある AI をコアとして構築された Amazon Nova の紹介 Amazon Nova は、最先端の知能と業界をリードするコストパフォーマンスを提供する、最先端の FM です。Amazon Nova FM には、データから有害なコンテンツを検出して削除し、不適切なユーザー入力を拒否し、モデル出力をフィルタリングするための組み込みの安全対策が搭載されています。私たちは、責任ある AI のディメンションを一連の設計目標として具体化し、初期のデータ収集と事前トレーニングからモデルのアライメント、そして展開後のランタイム緩和策の実装に至るまで、モデル開発ライフサイクル全体を通じて意思決定の指針としています。Amazon Nova Canvas とAmazon Nova Reel には、責任ある AI を用いて安全性、セキュリティ、知的財産のニーズをサポートするコントロールが付属しています。これには、ウォーターマークの付与、コンテンツモデレーション、そして C2PA サポート（Amazon Nova Canvas で利用可能）が含まれ、生成された画像にデフォルトでメタデータを追加します。誤情報の拡散、児童性的虐待のコンテンツ（CSAM）、化学・生物・放射線・核（CBRN）リスクに対抗する Amazon の安全対策は、Amazon Nova モデルにも適用されています。Amazon Nova がどのように責任を持って構築されたかについての詳細は、 Amazon Science ブログ をご確認ください。 責任ある生成 AI を推進するための新しいリソースにより透明性を強化する re:Invent 2024 で、Amazon の FM の透明性を高めるために、 Amazon Nova Reel 、 Amazon Canvas 、 Amazon Nova Micro, Lite, and Pro 、 Amazon Titan Image Generator 、および Amazon Titan Text Embeddings の新しい AWS AI サービスカードの提供を発表しました。これらのカードは、意図されたユースケース、制限事項、責任ある AI 設計の選択、および導入とパフォーマンス最適化のためのベストプラクティスに関する包括的な情報を提供します。Amazon の責任ある AI ドキュメンテーションの重要な構成要素である AI サービスカードは、公平さ、説明可能性、プライバシーとセキュリティ、安全性、制御性、正確性と堅牢性、ガバナンス、透明性に取り組む責任ある方法でサービスを構築するために私たちが行う開発プロセスを理解するための一元化されたリソースを、お客様と幅広い AI コミュニティに提供します。生成 AI が成長し進化し続ける中、技術がどのように開発、テスト、使用されるかについての透明性は、組織とその顧客の信頼を得るための重要な要素となるでしょう。 AI の透明性を促進するリソース として、全 16 の AI サービスカードをご覧いただけます（訳者注：最新のリソースを確認するには、上記 URL にアクセスした後、画面上部から英語に切り替えてください。日本語では最新の情報が表示されない場合があります）。 また、 AWS の AI の責任ある利用のガイド も更新されました。このドキュメントでは、AI に関する広範な学びと経験に基づいて、AI システムを責任を持って設計、開発、導入、運用するための考慮事項について説明します。これは、ビルダー、意思決定者、エンドユーザーを含む（ただしこれらに限定されない）多様な AI ステークホルダーと視点を念頭に置いて作成されました。AWS では、このような透明性の高いリソースをより広いコミュニティに提供し続け、最善の方法について繰り返しフィードバックを集めることに全力を注いでいます。 信頼を最優先に、画期的なイノベーションを提供する AWS では、AI への信頼を高め、あらゆる規模の組織が AI を効果的かつ責任を持って構築して使用できるようにすることに尽力しています。今週の re:Invent で責任ある AI のイノベーションが発表されました。Amazon Bedrock の新しい安全対策や評価手法から、最先端の Amazon Nova FM、ISO/IEC 42001 認証や新しい AWS AI サービスカードによる信頼と透明性の醸成まで、生成 AI で責任を持ってイノベーションを起こし、価値を引き出すのに役立つツール、リソース、組み込みの保護機能が豊富に用意されています。 次の新しいツールとリソースを是非お試しください。 AWS は ISO/IEC 42001 AI マネジメントシステムの認証を取得しました 数学的に正しい自動推論チェックにより、LLM のハルシネーションによる事実ミスを防ぐ (プレビュー) Amazon Bedrock Guardrails が画像サポートによるマルチモーダル毒性検出をサポートするようになりました (プレビュー) Amazon Bedrock の新しい RAG evaluation と LLM-as-a-judge 機能（リンク先は英語です） Amazon Nova と責任ある AI への私たちのコミットメント（リンク先は英語です） 責任ある AI を理論から実践に変える（AWS ウェブサイト） AWS AI Service Cards （訳者注：最新情報をご確認いただくためにリンク先の英語版のページをご確認ください） AWS の AI の責任ある利用のガイド（リンク先は英語です） 著者について Dr. Baskar Sridharan 博士は、AI/ML およびデータサービス・インフラストラクチャーの副社長で、Bedrock、SageMaker、そして EMR、Athena、Glue などの重要なデータプラットフォームを含む主要サービスの戦略的方向性と開発を統括しています。 Peter Hallinan は、責任ある AI の専門家チームと共に、AWS AI における責任ある AI の科学と実践に関するイニシアチブを主導しています。彼は AI（ハーバード大学博士号）と起業（Blindsight、Amazon に売却）に深い専門知識を持っています。彼のボランティア活動には、スタンフォード大学医学部の客員教授や、マダガスカルのアメリカ商工会議所の会長も含まれます。時間があれば、子供たち山に出かけ、スキー、クライミング、ハイキング、ラフティングを楽しみます。   翻訳はプロフェッショナルサービス本部の藤浦 雄大が担当しました。