サステナビリティを意識したミニチュア倉庫のデモを作ってみた !
Author : 佐藤 賢太, 戸塚 智哉, 豊原 任
ビルダーのみなさま、こんにちは !
「持続可能な社会の実現へ向けて、IT 技術者として何ができるのだろう」と考えたことはありませんか ?
私も以前「サトケンさん、IoT を使って何かサステナビリティの実現に貢献できることってどんなものがありますかね ?」と相談されたことがあり、それがきっかけで、AWS サービスを活用してサステナビリティに取り組むデモの開発に挑戦することになりました。
デモの題材を検討する上では、AWS ソリューションライブラリ を参考にしました。builders.flash でもこれまで何度か紹介されている AWS ソリューションライブラリでは幅広い業界およびテクノロジーのユースケースで AWS および AWS パートナーによって構築されたソリューションが紹介されており、クロスインダストリーのカテゴリー内には「持続可能性」のソリューションライブラリが公開されています。
今回は、持続可能性のソリューションライブラリの一つである「Guidance for Smart and Sustainable Buildings on AWS」を参考に、可視化したデータから省エネルギー化の洞察を得て、電力、費用及び温室効果ガス (GHG) 排出量の削減を実現するソリューションの実装例を紹介します。
可視化の過程では各種の AWS サービスを活用し、センサーデータを AWS IoT サービス及び AWS Lambda で収集、リアルタイム分析用に Amazon Timestream に保存し、可視化に Amazon Managed Grafana を活用する構成で実現します。また、AWS Well-Architected フレームワーク 持続可能性の柱 に基づき構成をレビューすることで、システム自体の環境負荷の軽減にも取り組みます。
本記事では、現実の建物環境を再現したミニチュアモデルおいて、室温や空気の質をデータに基づいて適切に管理することで省エネルギーにつながる過程を紹介します。室温・空気の質はセンサーで計測し、室温をコントロールするためにヒーターを用い、空気の質をコントロールするためにドアの開閉を行います。空気の質の変化は、炭酸水によって CO2 濃度を変化させ、人の出入りを擬似的に表現するようにしました。
目次
2. ソリューションの検討
2-1. Guidance for Smart and Sustainable Buildings on AWS のご紹介
2-2. デモのシナリオの検討
2-3. アーキテクチャ設計
2-3-1. 概要
2-3-2. AWS Well-Architected フレームワーク持続可能性の柱のレビュー
ご注意
本記事で紹介する AWS サービスを起動する際には、料金がかかります。builders.flash メールメンバー特典の、クラウドレシピ向けクレジットコードプレゼントの入手をお勧めします。
このクラウドレシピ (ハンズオン記事) を無料でお試しいただけます »
毎月提供されるクラウドレシピのアップデート情報とともに、クレジットコードを受け取ることができます。
1. サステナブルなビル管理を題材とした背景
本題に進む前に、サステナブルなビル管理を題材とした背景を説明します。
気候変動は我々の世代で最も重要な問題の一つです。気候変動の影響を最小限に抑えるため、世界 196 カ国が 2021 年の国連気候変動枠組条約締約国会議 (COP21) における パリ協定 に合意し、世界の平均気温の上昇を産業革命前から 1.5℃ 未満に抑えるために取り組んでいます。この目標の実現のためには、2030 年までに GHG の排出量を半減し、2050 年までに実質ゼロにする必要があると言われています。
2019 年、Amazon と Global Optimism は 2040 年までにネットゼロカーボン (GHG 排出量実質ゼロ) を達成することを約束する The Climate Pledge を共同で立ち上げました。多くの企業においても顧客、従業員、投資家の要求や政府の規制、競争上の優位性を確保するために温暖化対策の目標を対外的にコミットメントとして掲げ、現在 The Climate Pledge には 400 を超える企業が署名し、パリ協定よりも 10 年早い 2040 年までの GHG 排出量の実質ゼロを目標実現に取り組んでいます。
GHG は様々な事業活動により排出されますが、ビルの運用に起因する GHG 排出量は世界全体の 28% を占める と言われていて、サステナブルなビル管理の実現は排出量削減のインパクトが大きな領域です。
以上を踏まえて、次の 2 つの理由でスマート x サステナブルビル管理ソリューションのデモ開発に取り組むことにしました。
1 つめの理由は、自宅やオフィスビルによる空調などのエネルギー使用量は誰もが身近なトピックのためイメージしやすい点です。
2 つ目の理由は、AWS はサステナブルなビル管理における課題に対するソリューションガイダンス「Guidance for Smart and Sustainable Buildings on AWS」を公開しているためガイダンスのレファレンスアーキテクチャを参考に素早くデモを実装できる点です。
2. ソリューションの検討
2-1. Guidance for Smart and Sustainable Buildings on AWS のご紹介
では、Guidance for Smart and Sustainable Buildings on AWS について紹介します。
こちらのガイダンスでは、リアルタイム及び過去の履歴データからサステナブルなビル管理を実現する気づきを得るためにビルのシステム、設備やセンサーを統合する方法が示されています。
空調や水、電力、太陽エネルギーなどの運用に伴うデータは AI/ML を用いて処理され、データを保存、分析、可視化することで、ビルのどの部分がどのように環境負荷を排出しているのかを、インフラとオペレーションを横断して把握することができるようになります。
お客さま自身も追加で各拠点のネットワークにセンサーをデプロイし、迅速にどのビルが最も環境負荷を排出しているのかをみることができるようになります。
アーキテクチャ図の各ステップの説明は以下の表に記載します。
| ステップ 1 | 電力、ガス、水や廃棄物など建物の運用に伴う公共料金の請求書を Amazon API Gateway 経由で取り込み、Amazon Textract で変換します (参照: Guidance for Utility Bill Processing on AWS)。このデータは分析の用途としてデータレイクに蓄積します。 |
| ステップ 2 | ビル管理システム (BMS) プラットフォームからのデバイステレメトリーを AWS IoT Core でクラウドに取り込みます。リアルタイムテレメトリを AWS IoT SiteWise へ送ると同時に、Amazon Kinesis Data Firehose 経由でデータレイクにも蓄積します。 |
| ステップ 3 | デバイスセンサーデータを AWS IoT Greengras 上にデプロイされた AWS IoT SiteWise Edge にて収集、処理し、 AWS IoT SiteWiseへ直接送ります。 |
| ステップ 4 | Amazon AppFlow や AWS DataSync で BMS と Enterprise Resource Planning (ERP) に接続します。そうすることで、設備の属性やビルの空間モデルを Building Information Modeling (BIM) platform システムから収集することが可能になります。AWS Lambda を用いて設備データを選択したビルのメタデータ標準に準拠するため修正します。 |
| ステップ 5 | Amazon Simple Storage Service (Amazon S3) にデータを保存し、データレイクを構築し、技術的なメタデータをAWS Glue Data Catalog に保存します。 AWS Step Functions を用いて AWS Glue の抽出、変換、ロード (ETL)ジョブ全体のオーケストレーションを実現し、AWS Lake Formation で詳細なアクセスコントロールを管理します。 |
| ステップ 6 | デバイスの計測データを Amazon Timestream または AWS IoT SiteWise に集め、メトリクスを計算してアラームを生成します。 |
| ステップ 7 | アセットの属性と関係を Amazon Neptune で管理、または拠点とアセットのデジタルツインを AWS IoT TwinMaker で作成します。環境のインタラクティブな 3D ビューを構築し、AWS IoT SiteWise からのリアルタイム計測値をオーバーレイで表示します。 |
| ステップ 8 | Amazon Athena 経由で structured query language (SQL) のアクセスを提供し、埋め込み可能で機械学習 (ML) を活用したダッシュボードを Amazon QuickSight または Amazon Managed Grafana で構築します。 |
| ステップ 9 | Amazon SageMaker からデータレイクに接続し、オンサイト側でのリアルタイム推論用の ML モデルをトレーニングし、AWS IoT Greengrass にデプロイします。モデルの出力はオンサイト設備の制御または新規のメトリクスとして標準のアーキテクチャに取り込みます。 |
| ステップ 10 | 全体のシステムの健全性とパフォーマンスを Amazon CloudWatch でモニタリングします。 |
2-2. デモのシナリオの検討
次に、ガイダンスを参考に、以下の内容を満たすデモのシナリオを検討します。
- センサーデータの収集と保存と可視化を行う
- データから省エネルギー化の洞察を得る
- 電力、費用及び GHG 排出量の削減を実現する
ミニチュアモデルでは、リファレンスアーキテクチャの中にあるセンサー情報を取得する方法をデモンストレーションします。ミニチュアモデルからの発展としては「Creating sustainable, data-driven buildings」で紹介されているような人感センサーなどを用いた「人の占有率に基づく空調制御」や、エネルギー使用効率の劣化を早期に検知する「故障検知」も出来ると思います。
どんなデモシナリオが良いかと頭を悩ませながら散歩をしていたところ、立ち寄った近所のコンビニでアイデアが生まれました。その日は冬の 10℃ を下回る寒い日で、コンビニ内では暖房が効いていて暖かく、一方で換気のためにドアは全開になっていました。室内の温度を快適に保ちつつ、空気の質を良くするという観点では空調も換気は重要ですが、ドアを全開にしているため常に熱が外に出ていくため、空調のエネルギー効率は悪くなります。
そこで「常にドアを全開で換気するのではなく、普段はドアを閉じて空気の質をモニタリングして適切なタイミングで換気をすることで空調のエネルギー効率を上げられるのではないか」と考えました。
「空気の質」の計測方法としては、厚生労働省の「冬場における『換気の悪い密閉空間』を改善するための換気の方法」に二酸化炭素排出量を 1000ppm 以下に抑える旨の記載がありました。今回のデモシナリオでは CO2 濃度をモニタリングし、CO2 濃度が 1000ppm を上回る前に換気を実施することで暖房のエネルギー効率を上げることを実演することにしました。
なお、本デモシステムはデータに基づくビル管理のアプローチにより、エネルギー使用量・コスト・および環境への影響の軽減に貢献できることを目的としており、すべての稼働中のビルに適用できることは想定していません。
2-3. アーキテクチャ設計
2-3-1. 概要
今回のアーキテクチャ概要を説明します。
- Amazon の物流拠点 (FC) をイメージし、青梅 FC と千葉みなと FC の 2 つのミニチュアビルの模型を作成します。ミニチュア模型にヒーターを設置し、SwitchBot プラグで消費電力を計測します。Raspberry Pi 上に CO2 濃度と温度を計測するセンサーを取り付け、AWS IoT Greengrass をインストールし、AWS IoT Core に接続してデータを送ります。
- SwitchBot プラグで計測する消費電力は SwitchBot 側のサービスとして収集され、API 経由で取得することができます。Amazon EventBridge ルール を定期的に実行し、AWS Lambda にて消費電力データを収集します。
- センサーからの測定値は AWS IoT Core で収集します。
- 参考情報として、各 FC 拠点の天候データを OpenWeatherMap から収集します。
- リアルタイムで時系列データを分析するのに適した Amazon Timestream にデータを保存します。
- 可視化の手段としては Amazon Managed Grafana でダッシュボードを作成します。
- Amazon CloudWatch で全体のシステムの健全性やパフォーマンスをモニタリングします。
構成を検討する過程では、前述のソリューションガイダンスを参考にしつつ、今回のデモの要件に合わせて取捨選択や採用するサービスを変更しています。
2-3-2. AWS Well-Architected フレームワーク持続可能性の柱のレビュー
アーキテクチャを設計する上で、このシステム自体の環境負荷をできるだけ軽減する目的で AWS Well-Architected フレームワーク 持続可能性の柱 の観点でレビューを行いました。
みなさんはクラウドでシステムを構築する際の意思決定の長所と短所を理解するのに役立つ AWS Well-Architected Tool というものがあるのをご存知でしょうか。フレームワークは 6 つの柱により構成され、信頼性、安全性、効率性、費用対効果、持続可能性に優れたシステムを設計・運用するためのアーキテクチャのベストプラクティスを学ぶことができます。サービスを構築される際、サステナビリティ観点だけではなく、他の 5 つの柱に関してもチェックを行っていただきたいと思っています。
このような各柱ごとにいくつか質問があり、それに答えて行く形で自身のサービスが柱に沿って構築できているか確認をすることができるようになっています。
たとえばこの画面は、持続可能性の柱の大項目 SUS-1 のワークロードにリージョンを選択する方法を示しています。
本デモはオレゴンリージョンを選択していますが、その理由は持続可能性を考慮しているためで、再生可能エネルギー使用率 が 100 % となっていることかつ、地域電力網の GHG 排出量が低いところで選定しているためです。
実ソリューションで構築する場合は、利用ユーザーが主にどこにいるのかによってネットワークレイテンシーが発生するため、システムの利便性などとトレードオフになりますので注意が必要です。詳しくは「持続可能な目標に基づくワークロードのためのリージョンの選び方」を参照してください。
クリックすると拡大します
今回はすべての項目をご紹介はせず、本デモで検討した内容の一部をご紹介します。
たとえば、大項目の SUS-2 には、「ワークロードインフラストラクチャを動的にスケールする」というチェックがあります。解説としては「クラウドの伸縮性を利用してインフラストラクチャを動的にスケールすることにより、需要に合わせてクラウドリソースを供給し、ワークロード容量の過剰なプロビジョニングを回避します。」とされていますが、本デモでは AWS IoT Core、AWS Lambda、Amazon Timestream、Amazon Managed Grafana のように基本的にマネージドかつサーバーレスのサービスを活用することで、常時起動しているインスタンスよりも伸縮性に優れた構成が取れており、過剰にプロビジョニングはされない構成となっています。過剰にプロビジョニングはされていないため、問題ないと判断しています。
また SUS-4 には、「不要または冗長データの削除」とチェックは「不要なデータや重複するデータを削除し、データセットの保存に必要なストレージリソースを最小限に抑えます。」との解説がありますが、こちらもまずは不要なデータが発生しないように重複データを持たないテーブル構成や全体アーキテクチャにしています。また開発を進めていくと古くなって使用しないデータが発生してくると思いますが、それらについてもシステムに対して問題がないか議論の上、不要に保管しておくことなく削除するようにしています。また、Timestream のデータ保持ポリシーを見直して、指定した保持期間を超えたデータは自動で削除されるようにしています。
このようにシステムを構築したら、一つずつチェックをしておくことが非常に重要な考え方になります。
上記に述べているようなデータベースの観点だけでなく、ストレージ、ネットワーク、コンピュートの観点で持続可能な AWS インフラストラクチャの最適化のブログシリーズも参考になると思います。
- 持続可能な AWS インフラストラクチャの最適化、第一部 : コンピュート編
- 持続可能な AWS インフラストラクチャの最適化、第二部 : ストレージ編
- 持続可能な AWS インフラストラクチャの最適化、第三部 : ネットワーキング編
- 持続可能な AWS インフラストラクチャの最適化、第四部 : データベース編
ではいよいよデモシナリオの実装に入っていきます !
3. 実装
3-1. ミニチュアビル
Amazon は、数千の施設を世界的に運営し、サステナブルな建物について取り組んでいます。例えば、FC や配送センターの屋上に太陽光発電システムを設置したり、AWS の米国の新しいデータセンターの設計基準では、20% 少ない低炭素コンクリートの使用を求めたりしています。そのポリシーを受け継いで、ミニチュアビルの製造で何かできないか、チームでディスカッションを重ねました。
既製品のミニチュア商品を購入するのが一番手間はかかりませんが、実験シナリオを実現する上で必要となる、ヒーターや Raspberry Pi を設置するスペースを備え、換気のためにドアを開閉できる商品が見つかりませんでした。
検討した結果、ホームセンターで木の端材 (木材加工時に生まれる余った部分) を購入し、過去の日曜大工で余った部品も活用し、ミニチュアビルを作ることになりました。屋上芝生に仕立てたのも、自宅の庭の人工芝の端材であり、もったいない精神 (Frugality) の集大成です。また、実験ができるように、天井にエアコンに見立てた爬虫類ペット用のヒーターを付け、随時通気できるように蝶番を付けたドアも製作しました。
3-2. データ収集
今回のデモでは、温度、湿度、気圧センサーとして HiLetgo 社製の BME280 を、CO2 濃度センサーとして MH-Z19C を採用しています。デバイスには Raspberry Pi 4B に AWS IoT Core Greengrass Core ソフトウェア をインストールして両センサーから取得した値を加工して、 AWS IoT Core に Publish するコンポーネントを作成しています。
今回各センサーからの収集に外部モジュールを活用する際、メインのロジックだけでなくそれらも合わせてデプロイしたり、コンポーネントのバージョン管理の煩雑さを緩和できる AWS IoT Greengrass Development Kit (GDK) を使った開発を行いました。はじめは GDK を使わずに開発をしており、バージョンの整合性が合わない際の対処など本来かけたい部分とは違うところの工数がかかってしまっていましたが、GDK を使うことでそこが大幅に解消されました。
センサーデータは AWS IoT Core のルールエンジンで AWS Lambda に流すようにして、そこでは Amazon Timestream へマルチメジャーレコードとして保存 するように加工しています。
AWS IoT Core から直接 Amazon Timestream への書き込みは、現時点ではシングルメジャーでの保存となり、可視化する Amazon Managed Grafana でのクエリが煩雑になります。一般的に拠点で複数センサーを同じ時系列で扱いたいシーンは多く存在すると思います。その際はマルチメジャーレコードでの保存をおすすめします。
クリックすると拡大します
電力値に関しては、SwtichBot プラグを活用して直接 そのプラグが有する機能でアップロードしてくれているため、そのデータを API を使った Amazon EventBridge で 5 分間隔で AWS Lambda からデータを取りに行く仕組みにしています。また、外気温については、その地区の外気温が分かればいいので、OpenWeatherMap API からこちらも Amazon EventBridge で 10 分間隔で AWS Lambda の中で各拠点分の天気データを取得して Amazon Timestream のそれぞれのテーブルに保存するようにしています。
各拠点の緯度経度や拠点にあるセンサー ID の情報などが Amazon DynamoDB にマスターデータとして管理されており、各データ取得の際に参照するような仕組みになっています。
センサーは配線が絡むので、ケースで覆い、仮想拠点に配置するデバイスがこれで完成です。
3-3. リアルタイムデータ可視化
さて、ミニュチュアハウスの消費電力量と各種センサーデータが貯まる仕組みができたので、Amazon Managed Grafana でダッシュボードを作成してデータを可視化します。
まずは完成したダッシュボードをご覧ください。
ダッシュボードの構成を説明します。
- 全体の KPI を把握するため、全施設の合計消費電力量と、消費電力に起因する GHG (二酸化炭素換算) 排出量及びコストを表示する
- どの拠点の環境負荷及びコストが高いか分析できる様にするため、1. のデータの拠点別の内訳を表示する
- 温度や CO2 濃度が適切に保たれているかを分析するため、拠点ごとの消費電力と各センサーデータの時系列と最新のデータを表示する。閾値を超えた場合の色を変えるなアラートを表示してアクションを起こせるようにする
- 外気温とエネルギー消費量の関係を確認できるようにするため、拠点所在地の気温データを表示する。暖かい時間帯ではヒーターの消費電力量は寒い日に比較して小さくて済むはず、などエネルギー使用量との相関を分析できる。
次に、ダッシュボードからいくつかピックアップして パネル を作成する方法を解説します。 パネルは、Grafana のダッシュボードに 1 つ以上含まれる基本的な視覚化の構成要素です。
消費電力量の算出は、電力 (Watt) の時系列データから、1 時間あたりの平均値を消費電力量 (Watt Hour) として拠点ごとに算出します。全拠点の合計を表示する場合は拠点のデータを合算して Gauge グラフで表示し、拠点別に表示する場合は stat グラフで表示しました。
WITH binned_query AS (
SELECT bin(time, 1h) as time
, avg(ELECTRIC_CURRENT) AS "wattHour"
, LOCATION
FROM $__database.$__table
WHERE $__timeFilter
group by bin(time, 1h), LOCATION
order by time desc
)
SELECT sum (wattHour) as "PowerUsage"
FROM binned_query
クリックすると拡大します
次に、エネルギー消費量をベースに、購入したエネルギーの生産に伴う排出量を計算します。
企業は、GHG Protocol に基づいてこれらのスコープ 2 の排出量を報告する際には、ロケーション基準とマーケット基準で報告することができます。GHG Protocol によると、ロケーション基準手法では、電力が消費される場所においての電力網の平均炭素強度を反映します (ほとんどの場合は電力網の平均排出係数を用います。)
マーケット基準手法では、排出量は事業者が意図的に選択した (または選択肢がない場合の) 電力購入の契約に基づいて計算されます。本ダッシュボードではロケーション基準で算出します。
ロケーション基準で算出するデータソースとして、日本では環境省が公開している 算定方法・排出係数一覧 などのデータソースもありますが、国や特定の地域に縛られないデータソースとして、今回は Electricity Maps の推定値を活用します。なお、2023/08/12 時点の東京の炭素強度は 1kWh あたり 545g でした。
クリックすると拡大します
以上を踏まえ、1 kWh あたりの GHG 排出量を計算して、Gauge グラフで表示します。
WITH binned_query AS (
SELECT bin(time, 1h) as time
, avg(ELECTRIC_CURRENT) AS "wattHour"
, LOCATION
FROM $__database.$__table
WHERE $__timeFilter
group by bin(time, 1h), LOCATION
order by time desc
)
SELECT sum (wattHour) / 1000 * $CarbonIntensity as "CO2 Emissions"
FROM binned_query
クリックすると拡大します
コストの計算は事業者の電力契約などによって異なるため、経済産業省の資源エネルギー庁の「2023年6月の電気料金、なぜ値上がりするの？いくらになるの？」の記事にある「東京都の標準的な家庭における電気料金」から 1kWh あたり 29 円で仮置きで設定しました。
温度や CO2 濃度に関しては時系列と最新のデータを表示し、閾値の表示とアラートを設定の上、Slack や電話で通知を送るように設定しました。今回のデモのオペレーションでは CO2 や温度の状況をモニタリングし、温度が低い場合にヒーターのスイッチを入れ、CO2 濃度が高い場合にドアを開けて換気を実施します。
さあ、準備ができましたのでいよいよ実験してみます !
4. 実験の結果検証
寒い冬の日に、青梅 FCと千葉みなと FC の 2 つのミニチュア建物を使って実験を行いました。どちらの現場でも、温度を望ましい範囲 (摂氏 18 度以上) に保つためにヒーターを ON / OFF します。
2 つのサイトの違いは、青梅 FC はドアを全開にして常に換気を行っているのに対し、千葉みなと FC は CO2 ppm が 800 ppm を超えた場合にのみドアを開放しておくという点です。
両方のミニチュア建物に炭酸水の入ったカップを置き、人間が CO2 を排出するような形を擬似的に作り 、換気をしなくても CO2 濃度が上昇するようにしました。炭酸水のカップをいれる際、こぼしてまうとセンサーが台無しになってしまうので、慎重に設置しました。
実験では、千葉みなと FC と青梅 FC を比較し、千葉みなと FC ではドアが閉まり熱気と CO2 が内部に滞留するため、気温と CO2 濃度の上昇が速いことを確認しました。
千葉みなと FC のドアを開けると新鮮な空気が入ることによりすぐに CO2 濃度が下がることを確認し、再度ドアを閉めました。青梅 FC は CO2 濃度は低いままですが、常にドアが開いているため気温上昇のペースは千葉みなと FC よりも遅いです。温度がしきい値を超えた場合、ヒーターを OFF にしました。
下の図に示すように、全体として千葉みなと FC は青梅 FC よりもヒーターを OFF にする時間が長く、その結果、エネルギー使用量が少なくなり、それに伴う GHG 排出量とコストも削減されました。
クリックすると拡大します
デモの様子はこちらの動画をご覧ください。
5. まとめと今後やりたいこと
いかがでしたでしょうか。今回の記事では AWS 上のスマートで持続可能な建物に関するガイダンスを参照してサステナビリティを意識した施設管理ということで、仮想のミニチュア倉庫を作成して、その倉庫での温度、湿度、気圧、二酸化炭素濃度、電力を収集して、消費電力量から電気代や、二酸化炭素排出量をリアルタイムでダッシュボードにて可視化について述べました。
主に AWS IoT Greengrass、AWS IoT Core、AWS Lambda、Amazon DynamoDB、Amazon Timestream、Amazon EventBridge、Amazon Managed Grafana といった、マネージドサービスで構成されており、リージョンに関しても再生可能エネルギー使用率 100 % のオレゴンリージョンを採用し、持続可能性の柱に沿ったアーキテクチャになっています。
電力効率のよい空調管理が二酸化炭素排出量を削減できるという仮説のもと構築し、実際の動作をデモ動画にてご紹介しました。
昨今サステナビリティを意識しはじめている企業が増えてきており、電力や GHG 排出量の可視化のご相談をうける頻度も多く感じます。AWS を活用すると、各サービスを組み合わせて簡単にこのようなソリューションを構築することが可能になっています。
現時点ではまずはリアルタイムの可視化ダッシュボードを構築しましたが、長期データ分析のために Amazon QuickSight での BI ダッシュボードの構築や、デジタルツインでの可視化や、カメラデータの取り込み、エッジデバイスのクラウド側からの制御などを予定していますので、ご期待ください。
6. 参考
筆者プロフィール
佐藤 賢太
アマゾン ウェブ サービス ジャパン合同会社
ソリューションアーキテクト
これからクラウドを使い始める企業のお客様をソリューションアーキテクトとして技術面で支援しています。また、クラウドを最適に活用して IT のサステナビリティを高めることと、AWS テクノロジーを活用してお客様のサステナビリティ目標実現へ向けた課題解決の支援も行っています。
プライベートでは 2 児の父として、子供たちとのプロギングや家族旅行の時間を楽しんでいます。
戸塚 智哉
アマゾン ウェブ サービス ジャパン合同会社
ソリューションアーキテクト
製造・小売業界のお客様中心にご支援しているソリューションアーキテクトです。IoT やデータ活用領域で、お客様の課題や解決策を引き出すワークショップを提供し、ビジネスを加速させることを得意としています。また昨今では、サステナビリティと IoT を絡めた技術的なご支援を行うことが多く様々な業界のお客様と関わっています。
プライベートでは、パデルというテニスに似た新しいスポーツに熱中しています。
豊原 任
アマゾン ウェブ サービス ジャパン合同会社
ソリューションアーキテクト
金融業界のお客様をソリューションアーキテクトとして技術面で支援しています。IT とサステナビリティの両方のメリットを提供するソリューションを、お客様と一緒に作っていきたいと考えています。
プライベートでは、地域コミュニティの顧問を 10 年以上続けており、積極的にコミュニティの環境改善と円滑なコミュニケーションを手伝っています。
AWS を無料でお試しいただけます