AWS IoT FleetWise による EV バッテリーモニタリングソリューションの構築 (Part1/2)

この記事は Building an EV Battery Monitoring solution with AWS IoT FleetWise (Part 1/2) を翻訳したものです。

はじめに

自動車メーカー、フリートオペレーター、自動車部品メーカーは、車両データがビジネスモデルを変革し、業務を最適化する可能性があることを認識しています。しかし、データドリブンなユースケースを実装するには課題があります。独自の車両データ形式、高いデータ取り込みのコスト、複雑な実装がイノベーションを遅らせる要因となっています。AWS IoT FleetWise は、自動車メーカーが車両データを簡単に収集、変換し、クラウドに転送できるようにするサービスです。転送後、お客様は AWS の広範な分析および機械学習サービスを使用して、車両データから価値を引き出すことができます。AWS IoT FleetWise の使用経験がない場合は、ブログ「 Generating insights from vehicle data with AWS IoT FleetWise 」から始めることを検討してください。AWS IoT FleetWise のユースケース、技術的な機能、論理的なアーキテクチャについて学ぶことができます。また、同じブログで、電気自動車（EV）バッテリーモニタリングソリューションも紹介しています。

この記事では、AWS IoT FleetWise を使用して EV バッテリーモニタリングソリューションを構築する手順を説明します。まず、AWS アカウント内のAmazon Elastic Compute Cloud (Amazon EC2) インスタンスに EV 用シミュレーションをデプロイします。次に、EV シュミレーターから CAN バス信号を収集、変換、転送、保存するように AWS IoT FleetWise を設定します。最後に、Amazon Timestream サービスを使用して、収集したデータを確認します。

使用例

リチウムイオン電池（LiB）は、EV の電力を蓄えるシステムに広く使用されています。EV のフリート運用では、バッテリーセルの継続的な監視と保護が重要な考慮事項となっています。

EV メーカーや運行会社にとって、過電流、過充電、過熱などのバッテリーに関する問題を検知・予測する能力は非常に重要です。例えば、バッテリーの交換をタイムリーに計画できるようになることで、車両運行の効率と安全性を向上させることができます。また、さまざまなシナリオでバッテリーの状態を評価することで、EV メーカーがバッテリーサプライヤーと協力してバッテリーの改善活動に取り組むことができるようになるという例もあります。

このブログの目的は、AWS IoT FleetWise を使用してバッテリー管理システム(BMS) パラメータを収集し、クラウドに転送する方法を示すことです。そのために、過電流検出のユースケースを例にして説明します。データが転送された後、データベースに保存され、モニタリング、アラーム、ML モデルのトレーニングに使用できるようになります。

ソリューションアーキテクチャ

以下の図は、本ソリューションのアーキテクチャを示したものです。また、このブログ記事は黄色の点線の範囲で示しており、ステップバイステップのウォークスルーに従って実装しています。アーキテクチャの残りの部分は、このブログシリーズのパート 2 でカバーします。

ソリューション・アーキテクチャ

ソリューションアーキテクチャの詳細については、このブログシリーズの過去編を参照してください。

実装のアプローチ

以下の実装例では、2 台の車両と 2 つのデータ収集キャンペーンを利用しています。

車両

車両は、それぞれ 1 台の Amazon EC2 インスタンスでシミュレートされます。EC2 インスタンスは、BMS をシミュレートするために CAN bus メッセージを生成するスクリプトを実行します。2 台の車両は、AWS IoT FleetWise が異なる車両でも統一的なアクセスが可能であることを実証するために、意図的に異なる CAN シグナルエンコーディングを使用しています。

補足：車両のシミュレーションは、過去に記録された CAN または OBD-II 信号をシミュレーション環境上で再現するために簡単に利用できます。これは AWS IoT FleetWise をベースとしたソリューションのプロトタイピングフェーズで有用です。例えば、お好みのツールを使って、車両から CAN データを記録することができます。一度記録した車両データは、AWS IoT FleetWise のテストのためにシミュレーション環境で利用することができます。GitHub リポジトリで、独自の車両データのシミュレーションについてより詳しく知ることができます。

データ収集キャンペーン

AWS IoT FleetWise のデータ収集機能を構成する方法を学ぶために、2 つのデータ収集キャンペーンを設定します。

EV バッテリーパックの電流とバッテリーセルの温度を連続的かつ低頻度（1 秒のサンプリングレート）で監視するデータ収集キャンペーンです。簡単のため、この例ではバッテリーセル1個を利用します。
複数のバッテリー管理システム（BMS）信号の高分解能（サンプリングレート 50 ms）スナップショットを収集する条件付きデータ収集キャンペーン。このキャンペーンは、シャント電流（信号 EVBatterySample.BMS.BatteryPack01.ShuntPlusCurrent_a で表される）が 450 アンペア以上、すなわち過電流シナリオの場合にのみデータを収集する。

AWS IoT FleetWise の論理データモデルの紹介

AWS IoT FleetWise に基づくソリューションを展開するには、車両フリートからのデータ収集、変換、転送を構成します。AWS IoT FleetWise は、それを実現するための API を提供しています。これらの API は、AWS マネジメントコンソール、AWS SDK、または AWS CLI を使用して呼び出すことができます。

このブログで使用する API のほとんどは、CRUD（Create, Read Update, Delete）のパラダイムを利用しています。例えば、API アクションの CreateCampaign を使用して新しいデータ収集キャンペーンを構成したり、 UpdateCampaign を使用してキャンペーンのステータスを変更したりすることができます。

CRUD 操作は、AWS IoT FleetWise の論理データモデルのこれらの主要な要素を参照しています。FleetWise : Signal Catalog、Vehicle Model、Campaign、Vehicle、Fleet、DecoderManifest。以下の図では、これらの要素を紹介し、その関係を説明しています。

AWS IoT FleetWise の論理データモデル

AWS IoT FleetWise の API を使用して、これらの論理データモデルのそれぞれの要素を作成する方法については、このブログのガイドに従ってください。

このブログでは、AWS IoT FleetWise の API を利用するために、AWS CLI を使用します。また、AWS IoT FleetWise を管理するために、AWS IoT FleetWise Management コンソールを使用することができます。

ソリューションのデプロイ

AWS CloudShell を開く

このリンクをクリックして、AWS CloudShell（ブラウザベースのシェル）を開いてください。AWS のリージョンを AWS IoT FleetWise がサポートするリージョン（例：フランクフルト、バージニア北部）に変更されていることを確認してください。

リポジトリのクローン

本ブログのリソースが入った GitHub リポジトリを、以下のコマンドを実行してクローンしてください。

git clone https://github.com/aws-samples/aws-iot-fleetwise-evbatterymonitoring

Amazon EC2 のキーペアを作成

以下のコマンドを実行して、新しい Amazon EC2 キーペアを作成し、保存してください。後ほど、車両シミュレーションを行う Amazon EC2 インスタンスへの SSH 接続を確立するために使用します。

aws ec2 create-key-pair --key-name fleetwiseblogec2key | \ 
jq -r .KeyMaterial > fleetwiseblogec2key.pem 

chmod 0600 fleetwiseblogec2key.pem

車両シミュレーション用ソリューションのデプロイ

このステップでは、AWS CloudFormation スタックをデプロイして、2 台の車両のシミュレーションをセットアップします。このスタックは、あなたの AWS アカウントに必要なリソースをプロビジョニングします。

このソリューションを展開すると、Amazon EC2、AWS IoT、Amazon Timestream サービスなど、AWS のコストが発生する場合があります。意図しないコストを避けるために、AWS CloudFormation スタックを削除することによって、これらのリソースを削除することを忘れないでください。スタックを削除する手順は、このブログの最後にあります。

ディレクトリを変更してください。

cd aws-iot-fleetwise-evbatterymonitoring

スタックをデプロイしてください。

aws cloudformation deploy \ 
--template-file simulatedvehicle/ec2simulation/template.yaml \ 
--stack-name vehiclesimulation —disable-rollback \ 
--parameter-overrides Ec2KeyPair=fleetwiseblogec2key IoTCoreRegion=$AWS_REGION \ 
--capabilities "CAPABILITY_NAMED_IAM"

AWS CloudFormation スタックのデプロイが実行される間（約 20 分）、本ブログのガイドを進めてください。スタックのデプロイに問題が発生した場合は、トラブルシューティングガイドをご検討ください。

AWS CloudShell の “Actions”メニューの “New tab”機能で、次のステップのための新しいタブを作成することができます。

AWS CLI 入力ファイルの作成

本ブログの可読性を高めるため、AWS CLI コマンドの入力を JSON 形式で提供することにします。アカウントとリージョンに特化した JSON ファイルを作成するには、以下のコマンドを実行します。

cd ~/aws-iot-fleetwise-evbatterymonitoring/cloud 
./prepare_templates.sh
cd cli-inputs

AWS IAM ロールの作成

まず、Amazon Timestream データベースに書き込むための正しい権限を持つ、AWS IoT FleetWise サービス用の AWS Identity and Access Management (IAM) ロールを作成します。

aws iam create-role --role-name AWSIoTFleetWiseServiceRole\
    --assume-role-policy-document file://1_setup/trustpol.json

aws iam create-policy --policy-name AWSIoTFleetwiseIAMUserPolicy \
                      --policy-document file://1_setup/policy.json

aws iam attach-role-policy --cli-input-json file://1_setup/policy_attach.json

必要な権限の詳細については、AWS IAM ロールポリシーをご確認ください。

AWS IoT FleetWiseの初期設定

このステップでは、以前に作成した IAM ロールと Amazon Timestream データベースおよびテーブル名で AWS IoT FleetWise を構成します。AWS IoT FleetWise を使用する前に、利用する AWS リージョンに対して以下のコマンドを一度実行する必要があります。

aws iotfleetwise register-account \
    --cli-input-json file://1_setup/account_registration.json

# Check if registration is successfull
aws iotfleetwise get-register-account-status

入力ファイルである account_registration.json を確認することで、初期設定の詳細を知ることができます。詳しくは RegisterAccount API をご覧ください。

シグナルカタログの作成

シグナルカタログは、標準化された車両信号の定義です。新しいシグナルカタログを作成するには、以下のコマンドを実行してください。

aws iotfleetwise create-signal-catalog
　　　　　　　　--cli-input-json file://2_signal_catalog/create-signal-catalog.json

入力ファイル create-signal-catalog.json を確認することで、シグナルカタログの構造について学ぶことができます。詳細は CreateSignalCatalog API を参照してください。

車両モデルマニフェストの作成

AWS IoT FleetWise の車両モデルの概念を確認します。車両モデルの目的は、同じタイプの複数の車両で一貫したデータ構造を維持し、車両のフリートからデータを処理できるようにすることです。AWS IoT FleetWise では、車両データを指す「シグナル」という用語を使用します。

例えば、フリートオペレーターは、EV と電動スクーターの2種類の車両を保有している場合があります。EV とスクーターは、共通のデータ（「車両信号」とも呼ばれる）を生成することがあります。例えば、「現在の車速」です。しかし、EV は、スクーターには適用できない信号（例えば、タイヤの空気圧など）を生成することがあります。EV と電動スクーターのデータスキーマを区別するために、フリートオペレーターは AWS IoT FleetWise で 2 つの車両モデルを作成することができます。

モデルマニフェストは、特定のタイプの車両から収集されるデータのスキーマを正式に記述します。ファイル vehicle-model1.json および vehicle-model2.json にあるモデルマニフェストの例を確認してください。

新しく作成されたモデルマニフェストは、使用する前にアクティブにする必要があります。一度アクティブにすると、それ以降モデル・マニフェストは変更することはできません。2 つの車両モデルのモデルマニフェストを作成およびアクティベートするには、次のコマンドを実行してください。

# Model 1 
aws iotfleetwise create-model-manifest 
　　　　　　　　--cli-input-json file://3_model_manifest/vehicle-model1.json 
aws iotfleetwise update-model-manifest —status ACTIVE —name blog-modelmanifest-01 

# Model 2 
aws iotfleetwise create-model-manifest \
    --cli-input-json file://3_model_manifest/vehicle-model2.json 
aws iotfleetwise update-model-manifest —status ACTIVE —name blog-modelmanifest-02

詳細は、CreateModelManifest のドキュメントをご参照ください。

両モデルのシグナルには重複がありますが、特定のモデルでのみ利用可能なシグナルもありますので、ご注意ください。たとえば、「EVBatterySample.BMS.Relay01.Status」は、最初のモデルでのみ利用可能で、2 番目のモデルでは利用できません。これは、共通の信号への一貫したアクセスを提供しながら、異なる車種の車両群をどのようにモデル化できるかを示すためのものです。

デコーダーマニフェストの作成

デコーダマニフェストには、特定の車両の信号に対するデコードルールが記述されています。デコーダーマニフェストを作成し、有効化するには、以下のコマンドを実行してください。

# Decoder manifset 1 
aws iotfleetwise create-decoder-manifest 
    --cli-input-json file://4_decoder_manifest/decoder-manifest1.json 
aws iotfleetwise update-decoder-manifest —status ACTIVE —name blog-decodermanifest-01 

# Decoder manifest 2 
aws iotfleetwise create-decoder-manifest 
    --cli-input-json file://4_decoder_manifest/decoder-manifest2.json 
aws iotfleetwise update-decoder-manifest —status ACTIVE —name blog-decodermanifest-02

入力ファイルの decoder-manifest1.json と decoder-manifest2.json を確認することで、モデルマニフェストについて学ぶことができます。

“EVBatterySample.BMS.BatteryPack01.ShuntPlusCurrent_a” という信号のエンコーディングが、最初のデコーダーマニフェストと 2 番目のデコーダーマニフェストで異なっていることに注意してください。これは、AWS IoT FleetWise が車両モデルからデコードの抽象化をすることを示しています。これにより、車両信号への一貫したアクセスを提供しながら、異なるエンコーディングを処理することができます。

詳細については、CreateDecoderManifest API をご確認ください。また、ImportDecoderManifest API と DBC ファイルを使用してデコーダマニフェストを作成することもできます。

ビークルを作成する

車両は車両モデルのインスタンスであり、物理的な車両を表しています。車両を作成するには、以下のコマンドを実行してください。

aws iotfleetwise create-vehicle --cli-input-json file://5_vehicle/vehicle01.json 
aws iotfleetwise create-vehicle --cli-input-json file://5_vehicle/vehicle02.json

入力ファイル vehicle01.json と vehicle02.json を確認することで、車両について学習することができます。詳細は、CreateVehicle API をご確認ください。

フリートを作成し、車両をフリートに関連付ける

AWS IoT FleetWise では、特定の車両またはフリート（車両の集合）に対してキャンペーンのターゲットを設定することができます。サンプルのフリートを作成し、両方の車両をフリートに関連付けるには、次のコマンドを実行してください。

aws iotfleetwise create-fleet --cli-input-json file://6_fleet/fleet.json 
aws iotfleetwise associate-vehicle-fleet —fleet-id blog-fleet Filter 
　　　　　　　　--vehicle-name blog-vehicle-01 
aws iotfleetwise associate-vehicle-fleet —fleet-id blog-fleet 001 
　　　　　　　　--vehicle-name blog-vehicle-02

入力ファイル fleet.json を確認することで、フリートについて知ることができます。詳細は CreateFleet と AssociateVehicleFleet のAPIを確認してください。

データ収集キャンペーンを開始する

このセクションでは、車両データ収集のための 2 つの典型的なユースケースを実装します。このために、2 つのデータ収集キャンペーンを作成します。

AWS IoT FleetWise でデータ収集キャンペーンを開始するには、CreateCampaign API を呼び出して新しいキャンペーンを作成し、UpdateCampaign API を呼び出してそのキャンペーンを承認します。キャンペーンを承認することで、AWS IoT FleetWise にデータ収集キャンペーンとデコーダーの設定を車両に送信するように指示します。この設定に基づき、AWS IoT FleetWise Edge Agent はデータの収集、変換、AWS への転送を開始します。

それでは、個々のキャンペーンについて見ていきましょう。

キャンペーン1：バッテリーパックの電流とセル温度を継続的に収集する

このキャンペーンでは、時間ベースの収集スキーマを使用します。つまり、Edge Agent は車両データを継続的に収集し、指定された時間内でクラウドに転送します。このキャンペーンを作成するには、次のコマンドを実行してください。

aws iotfleetwise create-campaign \. 
　　　　　　　　--cli-input-json file://7_campaign/continious-monitoring-campaign.json 

# Please wait 15 seconds before running the next command to allow for campaign creation to complete 
aws iotfleetwise update-campaign —action APPROVE\ 
　　　　　　　　--name continious-monitoring-campaign

このキャンペーンの詳細については、continious-monitoring-campaign を参照してください。

キャンペーン2：複数のバッテリー管理システム（BMS）信号の高解像度（50 ms サンプリングレート）スナップショットを条件付きで収集します。

このキャンペーンの使用例としては、生産前の車両群のバッテリーパックに潜在する問題の分析が挙げられます。解析を行うために、車両の品質エンジニアは、複数の信号（例えば、特定のバッテリーセルの温度推移）の高解像度スナップショットを必要とする場合があります。しかし、車両エンジニアは過電流イベントが発生した場合のデータにしか興味がないと仮定しましょう。

このユースケースを実装するには、条件ベースの収集スキーマを持つキャンペーンを作成します。Edge Agent は、定義した式を評価します（たとえば、$variable.`EVBatterySample.BMS.BatteryPack01.ShuntPlusCurrent_a` > 450.0 など）。この式が true と評価された場合のみ、Edge Agent は車両データを収集し、クラウドに転送します。

このキャンペーンを作成するには、以下のコマンドを実行してください。

aws iotfleetwise create-campaign\
　　　　　　　　--cli-input-json file://7_campaign/conditional-snapshot-campaign.json

# Please wait 15 seconds before running the next command to allow for campaign creation to complete
aws iotfleetwise update-campaign —action APPROVE\
　　　　　　　　--name conditional-snapshot-campaign

このキャンペーンの詳細については、conditional-snapshot-campaign.json を確認することで知ることができます。

ソリューションのテスト

シミュレーションのデプロイと AWS IoT FleetWise サービスの作成に成功しました。今度は、ソリューション全体の動作を確認します。以下の手順に従ってください。

ステップ 1: シミュレーション車両に接続する

このステップでは、車両をシミュレートしている Amazon EC2 インスタンスに接続します。その後、2 つのソフトウェアコンポーネントの出力を確認します。Edge Agent と CAN バスシミュレーションスクリプトです。以下のステップを完了してください。

1. スタックの出力を取得する

aws cloudformation describe-stacks \ 
　　　　　　　　--stack-name vehiclesimulation \ 
　　　　　　　　--query "Stacks[0].Outputs[?OutputKey=='Ec2Instance1SSH'].OutputValue" \ 
　　　　　　　　--output text

“None”と出力された場合、スタックのデプロイがまだ完了していないことを意味します。数分後に再試行してください。スタックデプロイメントに問題が発生した場合は、トラブルシューティングガイドを参照してください。

2. Amazon EC2 インスタンスに SSH 接続する

上記のスタック出力から SSH コマンドをコピー＆ペーストし、実行してください。インスタンスに接続するか聞かれますので、“yes”で確定してください。

ssh -i ~/fleetwiseblogec2key.pem ubuntu@<Vehicle1EC2PublicIPアドレス>

3. CAN メッセージの表示

システムサービスとして実行される車両シミュレーションスクリプトによって生成された CAN データを表示してください。

candump vcan0

Ctrl-C コマンドで出力モードを終了することができます。

4. Edge Agent の出力を見ることができます。

sudo journalctl -fu fwe@0

“Failed to receive VIN from Engine ECU”というエラーメッセージは無視してかまいません。

ステップ2：Amazon Timestream で収集した車両データを確認する

このステップでは、Amazon Timestream テーブルに保存されているデータ収集キャンペーンの結果を確認します。

1. Amazon Timestream コンソールを開く

AWS マネジメントコンソールから“Amazon Timestream” サービスに移動するか、このリンクをクリックしてください。次に、“クエリエディタ“ メニューを選択します。

Amazon Timestream コンソール

2. キャンペーン1 : “バッテリーパックの電流とセル温度を継続的に収集 “で収集した車両データの確認

クエリのテキストフィールドに、以下のサンプルクエリを入力し、Run を選択します。

SELECT time, vehicleName, measure_name, measure_value::double, VehicleVIN
FROM "FleetWiseDatabase"."FleetWiseTable"
WHERE campaignName = 'continious-monitoring-campaign' AND
      time between ago(15m) and now()
ORDER BY time DESC LIMIT 10

これで、以下の例のように収集した車両データを表示することができます。

EVBatterySample.BMS.BatteryPack01.ShuntPlusCurrent_a という信号の CAN メッセージは、2 台とも異なる方法でエンコードされていますが（車両 1と車両 2の DBC ファイルを参照）、車両データには統一した名前でアクセスして分析することができます!

以下の例のように、ダッシュボードのサンプルを Amazon Managed Grafana を使って、車両データの可視化の実験を行うことをお勧めします。

3. キャンペーン2によって収集された車両データを確認する

特定のセル温度の統計情報をクエリしてみましょう。以下のクエリを入力し、 Run を選択します。

SELECT vehicleName, measure_name,
       hour(time) as hour, minute(time) as minute,
       max(measure_value::double) as MaxTemperature,
       min(measure_value::double) as MinTemperature
FROM "FleetWiseDatabase"."FleetWiseTable"
WHERE campaignName = 'conditional-snapshot-campaign'
      AND measure_name = 'EVBatterySample.BMS.BatteryPack01.Cell001.CellTemperature'
      AND (time between ago(10m) and now())
GROUP by vehicleName, measure_name, hour(time), minute(time)
ORDER by vehicleName,hour(time), minute(time)

以下の例のように、集計された車両データを見ることができます。キャンペーンの設定により、バッテリーパックのシャント電流が 450 アンペアを超えた場合のみデータが転送されます。19:42 と19:43 の時は、シャント電流が 450 アンペア以下だったので、データは転送されませんでした。

Amazon Timestream Query Languageのリファレンスガイドに、提供された例を使用して以下のようなAmazon Managed Grafanaダッシュボードを作成し、車両データで独自の実験を実行することをお勧めします。

クリーンアップ

Amazon EC2 インスタンスへの SSH セッションを終了したことを確認してから、作業を続けてください。AWS CloudShell で以下のコマンドを実行し、作成したリソースを AWS アカウントから削除してください。

aws cloudformation delete-stack —stack-name vehiclesimulation 
sh ~/aws-iot-fleetwise-evbatterymonitoring/cloud/automation/fleetwise-cleanup.sh

まとめと次のステップ

AWS IoT FleetWise を使用して CAN バス信号の収集、変換、送信、保存を実装する方法と、Amazon Timestream を使用してこれらの信号を確認する方法について学びました。このブログシリーズの次のパートでは、保存されたデータを分析するために AWS サービスを使用する方法について紹介します。

詳しくは、AWS IoT FleetWise のウェブページをご覧ください。

謝辞

Geoffrey Phillips (Senior Software Development Engineer) は、AWS CloudFormation テンプレートと CAN Interactive Generator ライブラリの主要な部分を提供してくれました。

執筆者について

Andrei Svirida は、Amazon Web Services のシニアスペシャリストソリューションアーキテクトです。彼は、あらゆる規模や業種の企業がデータドリブンなビジネスになることを可能にすることに情熱を注いでいます。そのために、IoT、アナリティクス、データエンジニアリングを中心に、AWS のお客様が AWS 上で安全でスケーラブルなソリューションを設計・構築できるよう支援しています。AWS 入社以前は、KUKA AG で IoT デリバリー責任者、Deutsche Telekom AG で社内コンサルティングの VP として勤務していました。コンピュータサイエンスのバックグラウンドを持ち、18 年以上の業界経験があります。

Suvendu Rath は、Amazon Web Services のシニアエンゲージメントマネージャーです。IoT、AI/ML、データエンジニアリングを中心に、AWS の顧客が初期から最終成果物までプロジェクトを支援することに情熱を注いでいます。AWS に入社する前は、BMW AG でソフトウェアプロジェクトリードとして、また自動車/航空電子産業でソフトウェアエンジニアとして働いていました。電気工学のバックグラウンドを持ち、自動車や航空電子工学の分野で 15 年以上の業界経験を持っています。

Katja Kroedel は、Amazon Web Services の IoT Specialist Solution Architect です。AWS の顧客と連携し、IoT 分野におけるクラウドの導入、移行、戦略に関するガイダンスを提供しています。テクノロジーに情熱を持ち、AWS IoT FleetWise のような革新的なサービスをクラウド上で構築し実験することを楽しんでいます。Katja はコンピュータエンジニアリングのバックグラウンドを持ち、修士論文から始まり、ドイツのジェネラリストソリューションアーキテクトとして、中小規模の顧客がクラウドについて成長し学ぶのを支援するなど、AWS 内で既に様々な役割を担ってきました。

このブログはソリューションアーキテクトの渡邊翼が翻訳しました。

Amazon Web Services ブログ