re:Invent 2024: ScepterとAWSがメタン排出削減のビッグデータ活用
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Scepter, Inc. uses big data to reduce methane emissions (AES301)
この動画では、ScepterとAWS、ExxonMobilの3社が協力して構築した大気モニタリングプラットフォームについて解説しています。衛星やHigh-altitude pseudo satellites、IoTセンサーなど複数のデータソースから大気中のメタンを検知し、AWS上で構築されたFusionプラットフォームでデータを統合・分析します。特にメタンの漏洩検知では、時間当たり10kgという高感度な検出が可能で、検知から5分以内にユーザーへアラートを送信できます。ExxonMobilは2030年までにPermian盆地でのNet Zero達成を目指しており、このプラットフォームを活用して排出削減に取り組んでいます。また、メタン以外にもNO2やPM2.5など様々な大気汚染物質の監視にも応用可能な技術であることが示されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
ScepterAirプラットフォーム：大気モニタリングの革新
皆様、本日のプレゼンテーションにご参加いただき、ありがとうございます。今日は少人数での開催となりますので、資料の説明が終わった後に、ご質問がございましたらお気軽にお声がけください。本日は多くの内容をカバーする予定ですが、きっと興味深い内容になると思います。私はScepterのPhilip Fatherと申します。本日は、AWSのChantz Thomas氏とExxonMobilのEmily Reidy氏という2人の同僚と共にプレゼンテーションを行わせていただきます。大気のモニタリングと、それを実現するための魅力的なプラットフォームの構築について、ご説明させていただきます。
プレゼンテーションは複数のパートに分かれています。まずは私からScepterについてご説明し、その後Chantz氏から、私たちがどのようにプラットフォームを構築し、協力して何を達成したかについてお話しいただきます。そして、ExxonMobilのEmily氏には、プラットフォームのお客様として、またメタン検知のユースケース開発にご協力いただいた立場から、お話しいただく予定です。
目に見えない大気汚染物質の可視化と影響
私たち3名は本日、ビッグデータ、データ分析、クラウドコンピューティング、そして新しい宇宙経済における進歩についてお話しさせていただきます。これらの分野の発展により、グローバルかつリアルタイムでの大気モニタリングが可能になりました。私たちが実際に行っているのは、目に見えないものを可視化することです。では、なぜ目に見えないものを可視化する必要があるのでしょうか？大気中には、検知して定量化できれば、商業市場や政府にとって重要な様々な元素、ガス、粒子状物質が存在しています。
具体例をいくつかご紹介させていただきます。なぜ二酸化窒素を可視化する必要があるのでしょうか？大気汚染、特にNO2は、広範な研究により、うつ病との強い関連性が実証されています。年間約2,100万人、つまり人口の8～9%がうつ病に苦しんでいます。もしNO2がうつ病の引き金になっていることがわかれば、薬に頼る前に、実は呼吸している空気が原因かもしれないと気づくことができます。製薬会社や保険業界は、このようなデータに大変興味を持っています。
もう一つの例として、PM2.5と地表オゾンについてお話しします。これら2つの物質は、農作物の生産性と健康状態を著しく阻害することが判明しています。光合成を妨げ、その他の悪影響も引き起こします。推定によると、これらのガスや粒子状物質が通常値より1%増加するだけで、農業生産に関連して世界で50億ドルもの経済的損失が発生する可能性があります。これが、私たちがこれらを把握する必要がある理由であり、製薬会社や保険会社がこれらの情報を知りたがる理由なのです。
メタンと二酸化炭素について考えてみましょう。今日はメタンについてより詳しく話し合うためにここに集まっているからです。私たちは皆、メタンと地球温暖化について、そしてそれが地球上の問題にどのように寄与しているかを知っています。メタン漏れを修復し、制御下に置くための取り組みを進めていますが、グローバルなリアルタイムプラットフォームがありませんでした。そこでScepterはAWSと協力してこの課題の解決に取り組みました。この点についてはChantzが後ほど詳しく説明します。また、このプラットフォームのアンカーカスタマーであり、メタンについての知見を提供してプラットフォームの立ち上げを支援してくれたExxonMobilのスポンサーシップも得ています。
これは、目に見えないものを可視化するという私たちの取り組みの一例です。ここに見えているのはメタンプルームです。通常では見ることができませんが、高度なデータ分析とモニタリングを通じて、プルームを検出するだけでなく、漏れている量を定量化することができます。
このプルームは恐らく時間当たり15kgのメタン漏れで、小規模から中規模の間くらいだと思います。私たちはプルームを検出し、さらに地理的位置を特定して、施設との関連付けを行います。これが重要な理由は、ExxonMobilと協力して、検出から修復までの5段階のプロセスを開発し、ワークフローに組み込んでいるからです。
私たちのプロセスは、まず検出を行い、次に定量化して規模を把握します。それが今ご覧いただいているものです。その後、Amazon Cloudの高度なセキュリティ環境を通じてデータを処理し、情報提供を行います。ExxonMobilのコマンド・コントロールセンターに情報を送るか、現場の携帯アプリに直接プッシュすることができます。情報提供後、クラウドを通じてさらにデータを共有し、漏れを解消します。ExxonMobilは私たちが提供する全ての情報を基に漏れを修復し、その後、規制当局が関与している場合は、漏れが修復されたことを認証して規制当局に報告する態勢を整えています。
このFusionプラットフォームを構築したことで、この5段階のプロセスは検出だけでなくワークフローへの組み込みも可能になり、私たちはこの成果を誇りに思っています。ExxonMobilのリーダーシップと彼らが作り上げた枠組みの下で、私たちは廃棄物管理のような隣接産業にも展開し、埋立地やその他の場所からのメタン排出についても理解を深めることができています。
多層的なデータ収集とFusionプラットフォームの構築
では、具体的にどのように実現しているのでしょうか？その仕組みを詳しく説明すると、2段階のプロセスになります。まず第1段階は、大気を監視する何千ものセンサーから、垂直方向の高度に沿ってデータを取り込むBig Dataプロセスです。すべてのセンサーが同じように作られているわけではなく、各層で異なる現象が起きていることがわかります。私たちは、空気層の監視に対してマルチセンサー・マルチドメインのアプローチを採用しています。地上のセンサー、空中のセンサー、ドローン、私たちが革新的に開発した成層圏プラットフォームからの情報、そして衛星（現在稼働中の衛星や、将来打ち上げる可能性のある衛星）からのデータを取り込んでいます。
この第1段階は、異なるセンサーからBig Dataキューブを作成する正規化のステップで、AWSはこの実現に大きく貢献してくれています。このデータキューブが正規化されると、次はデータの融合を行う段階に入ります。商用顧客が求める製品に応じて、関連するデータセットと融合させていきます。メタンの検出に関しては、超局所的な風のデータと融合させています。先ほどご覧いただいたプルームが蛇行していたのは、おそらくPermianで7ノットの風が吹いていたからです。この融合プロセスでは、高度なデータ分析とおそらくAIを活用して、より高度な製品を開発し、定期収益ベースで販売しています。
では、空気層のセンサーについてもう少し詳しくお話ししましょう。現在、私たちは一部の無料センサーを活用して運用しています。具体的には、政府やNGOが設置したセンサー（気象観測や科学的な目的で設置されたもの）を活用しています。誰かがアルゴリズムを書いて、それらをメタン検出用に転用できるようにしました。短波長赤外線センサーなどがその例です。現在、私たちはこの無料データを活用し、より高度な数学的処理を行い、衛星や地上のプラットフォームからのデータを融合プラットフォームに集約しています。
現在、私たちは無料データから洞察を生み出しています。実際、大規模なFederatedデータカタログを持っており、現在これらのセンサーからデータを取り込み、データアルゴリズムを作成しています。そして、ユースケースに応じて、必要な場合は独自のセンサーで補完しています。実際に、ハイパースペクトルセンサーを使用しており、現在は成層圏で運用しています。ハイパースペクトルパッケージを組み立て、すでにPermianで6回ほど飛行させており、非常に低いレベルまでの検出が可能です。時間当たり10kgのメタンまで検出できます。無料センサーには基本的に3つの制限があり、そのために私たちは独自のセンサーを飛ばしています。これらの制限には以下が含まれます：
時として、カバレッジのギャップが制限となることがあります。世界の特定の地域はカバーしているものの、他の地域にギャップが生じる場合があります。これは、私たちの顧客が多国籍企業やグローバル企業であり、全体像を把握したいと考えているためです。また、読み取りのタイミングも制限となります。地上センサーは15分ごとに読み取りが可能ですが、衛星は数日おき、おそらく3日に1回か週に1回の読み取りとなるため、この時間的な次元の違いを調整する必要があります。
また、検知閾値レベルにも違いがあります。地上のセンサーは1時間あたり1kgのメタンを検知できますが、効果的な定量化はできません。一方、衛星は1時間あたり400〜500kgのメタンしか検知できないため、大規模な排出源のみを捉えることができます。私たちはこれら3つの異なる次元を調整し、数学的・分析的にギャップを埋める必要がありました。ある時点で、独自にカスタマイズしたセンサーを飛ばし、すべてを統合することを決定しました。現在、私たちは成層圏プラットフォームでの検知を航空モニタリングへと拡大し、沖合の石油プラットフォームからの漏洩を検知・定量化するためのプラットフォームを完成させています。
これはExxonMobilとの共同プロジェクトで、沖合施設が全メタン漏洩の20〜30%を占めていることが分かっており、この理解をより深める必要があります。これが私たちの進化の方向性であり、現在の取り組み方です。 成層圏プラットフォームに関して、私たちは地域レベルでメタンを特別にモニタリングできる短波長赤外線のハイパースペクトルセンサーを最初に実現しました。このプラットフォームを完成させ、現在は地域データの提供から始めてグローバルへと進化させています。
このユースケースでは、これまで複数のミッションで使用されてきた既存のセンサーを採用し、高度60,000フィートの熱環境に適応させて改良しました。このセンサーは以前から航空機で使用されていましたが、気球が動き回るため3軸ジンバルに搭載しました。気球は高度を変えることで操縦でき、特定の場所に留まることができますが、このプラットフォームの利点は、まだ調査が必要なメタン漏洩のもう一つの特性である間欠性を明らかにできることです。漏洩はオンオフを繰り返しますが、その場所に留まることができれば、この特性を捉え、漏洩の全体像をより正確に評価できます。航空機による観測では、飛行時に漏洩が止まっていれば見逃してしまいます。
このプラットフォームで素晴らしい成果を上げており、AWSとのもう一つのイノベーションポイントは、システムのレイテンシーを解消したことです。データ分析は上手くできると分かっていましたが、Starlinkを使用していても、大量のデータを生成するセンサーに対して通信容量が限られているという課題がありました。Edge Computingを活用し、低レイテンシー環境でデータを移動させることでイノベーションを実現しました。従来のインバージョンモデリングでは1〜2週間かかっていた漏洩の検出を、10分以内に短縮することができました。
衛星に関しては、私たちのコンステレーションの設計は完了しており、成層圏キャンペーンから多くを学び、航空キャンペーンからもさらに学ぶことを期待していますが、そこではセンサー群によるアプローチを取ります。衛星側では、地球上のどの場所でも50分ごとに観測できるように再訪時間を短縮しています。これにより、単なるB2Bだけでなく、消費者にも触れるB2B2Cの市場アプリケーションが開かれ、ユースケースの観点からも非常に興味深いものとなっています。 これはメタン検知を超えた取り組みとなっています。
リアルタイムデータがもたらす新たなビジネス機会
美容・化粧品業界について見てみましょう。グローバルなリアルタイムデータ収集があれば、多国籍で世界的なマーケティング展開を行う企業と協力できます。美容・化粧品分野では、健康上の懸念事項であるメラノーマとの関連性があります。地上レベルのオゾン量、PM2.5の詳細な成分、気象データ（特に気温と湿度）、そして肌の毛穴サイズの代替指標がわかれば、価値のある洞察を生み出せることが実証研究や方程式で示されています。
L'Orealを例に考えてみましょう。彼らのアプリで、ユーザーが白人、ラテン系、アジア系のいずれかであることがわかれば、それが肌の毛穴径の代替指標となります。メラノーマ指数を作成して実行し、体への大気汚染が危険なレベルに達した時に通知を送ることができます。そして、大気汚染の悪影響を取り除くために、Walgreensで彼らのボディウォッシュを購入するよう推奨することができます。彼らは大気汚染の悪影響に対抗するために数億ドル規模の製品を発売しています。これは、グローバルなリアルタイムデータが実際に収益を生み出すのに役立つ例であり、単なるモニタリングやコンプライアンスだけでなく活用できることを示しています。
リアルタイムアプリケーションのもう一つの例は保険業界で、動的なリスク配分と評価に向かって進んでいます。2月に実施された保険が6月の災害をカバーするというような従来の形式ではありません。火山噴火、強風、嵐、洪水といったイベントが発生しており、保険業界はイベント発生中やイベント直前に動的な配分を行う方向に進んでいます。私たちのデータセットは気象データセットと組み合わせることで、この取り組みに貢献できます。
最後に、私たちのプラットフォームについてさらに詳しくお話しすると、AWSとの関係について非常に満足しています。ScepterAirプラットフォームやその他の取り組みの機能を構築する上で、彼らは素晴らしいパートナーでした。環境、スケーラビリティの特性、そして何千ものセンサーを取り込む能力があったため、私たちは彼らのIoTグループを活用しています。多くの場合、センサーを取り込むためのAPIがすでに作成されているか、コードの半分が用意されているため、より迅速に実装することができます。前述のように、メタンのユースケースでは顧客と機密データベースを共有する必要があったため、セキュリティは極めて重要でしたが、AWSはセキュリティと信頼性の確保において素晴らしい仕事をしています。
この関係から発展したのは、AIとエッジコンピューティングを使用してデータフローのレイテンシーを削減する機能です。低レイテンシーは、低検出性や精度の閾値を上回る最も重要な特性の一つとなっています。人々は低レイテンシーを求めています - 今すぐ、より早く答えが欲しいのです。そして、AIやその他の手段を通じて精度を補うことができます。私たちはこの特性に取り組んできたことを非常に嬉しく思っています。また、AWS Marketplaceで4つほどの製品を公開していることも嬉しく思っており、今後数ヶ月で世界最大の大気情報データベースを構築するために、共に迅速に前進していくことを楽しみにしています。
AWSを活用したScepterAirプラットフォームの技術詳細
それでは、Chantzに引き継ぎたいと思います。 私はAWS Professional Servicesに所属するChantzです。私たちは、Scepterのチームと共に大気観測というミッションを加速・強化するために展開している技術者チームです。今日お話しする内容は非常に具体的なものになります。
メタンのユースケースについて見ていき、この数年間の取り組みから得られた教訓をお伝えしたいと思います。また、私たちが何を目指しているのか、なぜこれを追求しているのか、そしてPhilipが説明したような指標をどのように得ているのかについてもお話しします。
まず、地上レベルから始めましょう。West TexasやEast New Mexicoにある天然ガスの中継地点にあるタンク群を想像してください。過酷な環境下で何千もの貯蔵タンクと、それらを結ぶ何百万マイルもの配管があります。そのような設備は劣化する可能性があり、漏れが発生することがあります。このような漏れが何千、何百万という規模で長年にわたって発生すると、大気中のメタン濃度の上昇につながり、大気の健全性に問題を引き起こすことになります。
これは、個々の現象に注目したミクロな視点です。これから、現場でのメタン漏れというこの個別の現象に対して、私たちのプラットフォームがどのようにアプローチしているのかを、一つ一つ掘り下げてご説明します。まず全体像を把握するために、大気中のメタン濃度が急速に上昇している様子を見てみましょう。NOAAのこの図表が示すように、メタン濃度は昔からこれほど高くはありませんでした。グローバルスケールで見ると、私たちは危険なレベルである2000 ppbに近づきつつあります。これは過去40年間のデータですが、すでに400 ppb以上も上昇しています。産業革命以前は、この数値は現在の2～3分の1程度で長年安定していました。
この現象に対する人間の影響は明らかです。メタンの放出をある程度抑制できれば、比較的早期に効果が現れる可能性があります。メタンは大気中での半減期が短く、より深刻な温室効果をもたらします。赤外線を吸収する性質は、検出の観点からは素晴らしい特徴です。赤外線スペクトルにおけるその特徴的な指紋から、メタンの位置を特定し、定量化することができるのです。しかし、赤外線ランプの下のフライドチキンのように、メタンは熱を非常に効率よく吸収し、CO2以上に強力な温室効果をもたらします。CH4は大気中で約10年の分解サイクルを持つため、私たちの生涯のうちに、コストニュートラルな形で大気の温暖化と健全性に影響を与えられる大きな機会が存在するのです。
それでは、この仕組みを実現しているソフトウェアとハードウェアについてお話ししましょう。このダイアグラムは、最も抽象的な視点から全体を見渡し、私たちが行っていることをシンプルに理解できるようにしています。左右の赤い部分が入力と出力を表しています。左側には環境からの刺激や検知可能な要素があり、右側には分析結果やインサイト、実際の対策案といった出力が示されています。その間には、このプレゼンテーションを通して繰り返し登場する3つの緑の柱があります。また、取り込みフェーズ、処理フェーズ、提供フェーズという表記も見ることができます。
まずは基礎から始めたいと思います。これはScepterの特定のユースケースだけでなく、多くの構築作業において不可欠なものです。もしあなたが新規に始める場合や、クラウドの原則を活かすためにアーキテクチャを見直そうとしている場合は、このスライドをよくご覧になることをお勧めします。私たちが使用した手法であるLanding Zone Acceleratorについて示しています。これについてはオンラインで詳しい資料が公開されており、Scepterが動作する堅牢で安全な環境を構築するための指針となりました。下部の緑色の部分では、マルチアカウントアーキテクチャの例を示しており、セキュリティ態勢を強化するための明確な論理的分離を実現しています。アイデンティティを管理するための管理アカウント、ログと監査用のアカウント、そして図では1つのアプリケーションアカウントしか示していませんが、実際にはCI/CDパイプラインの異なるフェーズごとに多くのアカウントを持っています。上部では、規制要件やパフォーマンス要件を満たすために重要なサービスをいくつか挙げています。監視には、Conformance Packs、AWS Control Tower、AWS Configを使用しています。
さらに、中央にはNetwork Firewallがあります。ログ記録については、Amazon CloudWatchによるアプリケーションレベルのログと、AWS CloudTrailによるAWSサービスレベルのログの両方を実施しています。右端にはAWS Key Management Serviceがあり、保存時および転送時の暗号化を簡単に実装できるようになっています。
さらに構築方法の詳細に踏み込んでみましょう。このダイアグラムは、開発者の視点から見た構造を示しており、アプリケーションの視点まで層ごとに掘り下げています。簡略化されていますが、多くの開発者が科学的要素、エンジニアリング要素、サービス提供要素に取り組みながら、このプラットフォームを世界に展開していく様子がわかります。最上部では、コードの速度と正確性を向上させるためにAmazon Q Developerを活用した開発環境があり、機能や機能の一部に対応する複数のブランチがあります。これらは、アプリケーション全体にマッピングされる可能性のある中央リポジトリまたは複数のリポジトリにフィードされます。
3番目の層に降りると、アプリケーションを構成する論理コンポーネントが見えてきます。CDKとCloudFormationを使用して論理的な分離を作成し、インフラストラクチャ・アズ・コードを使用してアプリケーションをデプロイできるようにしています。図に示されているように、これらのスタックは1対1または多対1でマッピングでき、取り込み、処理、提供の各フェーズにおいて、下部の同じ色分けで示されているアプリケーション自体の構成のデプロイと維持を行います。
それでは、最初の柱であるデータ取り込みについて掘り下げ、ユースケースに踏み込んでいきましょう。ソフトウェアアーキテクチャだけでなく、ハードウェアについても説明していきます。この図は、先ほどPhilipが少し触れていた、私たちが取り込んでいるデータを示しています。左側には、現在の主要なデータソースがあります。NASAやESAなどの政府機関が運用する衛星からのデータで、AWS Registry of Open Dataを通じて素早くアクセスできます。中央には矢印の数は少ないものの太くなっています。これは、HAPSミッション、つまり成層圏気球による高高度疑似衛星からのデータが頻度は低いものの、大容量であることを示しています。
この気球の下部に搭載されたカメラは、Scepterを差別化する独自の大量のデータを提供します。下部には小さな矢印が多数あり、これは大気を測定する何百何千ものIoTセンサーを表しています。これらのセンサーは、石油・ガス田のメタン生成地域に設置された柱の上で測定を行います。Philipが説明したように、これらは非常に頻繁にデータを取得しますが、カバーする範囲は非常に限定的です。衛星やHAPS機からはより広範囲のカバレッジを得られますが、これらの広範なIoTセンサーネットワークによって、地上センサーを使用して生産現場の非常に具体的で頻繁な情報を得ることができます。これらすべてのデータは右側の最初の柱、つまりデータ取り込みに流れ込みます。
ここで、独自データにおける重要な差別化要因となるハードウェアについて説明したいと思います。エキサイティングな要素として、成層圏や宇宙空間を含めましたが、クラウドは右下の赤いボックスにしか入っていません。この図は、私たちが独自のミッションを飛行させる際の仕組みを示しています。左側がHAPSで、レイテンシーを考慮して、HAPS機にStarlink端末を搭載することができました。画像を蓄積して1日の終わりに一度の大きな低速ダウンリンクを待ったり、ミッション終了までハードドライブの回収を待ったりする代わりに、Starlinkノードを通じてデータをリアルタイムで送信し、地上局を経由してインターネットからAWSに直接送ることができます。これにより、Philipが紹介した分単位のレイテンシーを実現しています。
この場合、リンクは印象的ですが、数百の分光バンドを持つハイパースペクトルデータを全てStarlinkを通じてインターネットにダウンリンクするには十分な帯域幅がありません。そのため、気球上にオンボードロジックを作成する必要がありました。
このオンボードロジックは、メタンを素早く検出してユーザーにアラートを届けながら、データ信号を削減・圧縮するように設計されました。これを実現するために、HAPS機のオペレーターと協力して、センサーからストリーミングされる生データを処理し、不要な部分を除去して処理を適用し、Starlink接続を通じて送信するコンテナ化されたシステムを作成しました。 この方法により、通常なら完全なファイルとして数十分かかるダウンリンクを2分以内に収めることができます。これは重要なポイントです。なぜなら、私たちのセンサーは2分単位でデータを取得するからです。2分のケイデンスに遅れを取ると、データを破棄するか、その日の終わりまで配信を遅らせるか、あるいは目標としている分単位のリアルタイム検出を妨げるバックログが蓄積されてしまうことになります。
これを実現するために、私たちは配信されるデータ量を大幅に削減しました。図の左下のタイムラインは、車両からAWSまでのパスを示しており、これは先ほど説明したダウンリンクを表しています。2分以内、多くの場合それ以下の間隔を維持しながら、現場でメタンを正確かつ高感度に検出するのに十分なデータの精度を保ちつつ、データ生成に追いつくことができています。図の右側はAWSからユーザーインターフェースまでのフローを示しており、3分以内にユーザーへデータを処理して届けます。これにより、カメラでメタン漏れを捉えてから、スマートフォンにアラートとして、あるいはユーザーインターフェースで解釈可能な画像として表示されるまでの時間が5分以内となります。これは、メタンの蓄積に寄与する多くの漏れに大規模に対処することを可能にする応答速度です。
データ提供方法とユーザーインターフェースの設計
処理を表す中央の緑の柱についてより詳しく説明したいと思います。左上には、センサーを搭載した車両があります。このセンサーは、スマートフォンのカメラと少し似ています。XとY軸があり、定期的に2次元フレームを撮影します。ただし、これらの次元の使い方が異なります。横方向の次元はスマートフォンと同様に空間情報を表すピクセルとして機能しますが、Y軸はスペクトルを表すために使用します。赤外線のこのウェッジ全体でどれくらいの明るさがあるかを見たいのです。そして、特定のフィンガープリントがあれば、それがメタンであると判断できます。そのフィンガープリントを特徴付けて定量化することで、私たちと地面からの反射光との間にどれだけのメタンがあるかを判断できます。
これにより、先ほどPhilipのスライドで見たような、メタンの高低を示すヒートマップを作成し、定量化することができます。例では、センサーが生成する多くのスライスの1つを示しており、暗くなった領域が左側に傾いたピークとして表示されています。この低い透過率があるとき、アルゴリズムを適用して、1平方メートルあたりのモル数のような濃度測定値を求めたり、風のデータを使用して1時間あたりのキログラム数を計算したりすることができます。これにより、現場のオペレーターに優先順位付けや潜在的な漏出の緩和のための具体的で実用的なデータを提供することができます。
これらの漏出を検出すると、部分的に処理されたデータが画面に表示され、紫色の領域が赤外線でのメタンの吸収を示します（疑似カラーを適用）。緑の矢印は右向きの風向を示しています。プルームを解釈すると、左側に最も濃いメタン濃度の高い発生源があり、地面近くの乱流層とともに右側へと渦を巻いているのが分かります。これを特定し、そのデータに対して1時間あたりのキログラム数の算出を行うことができます。
成層圏から宇宙、そして地上まで進んできて、メタン漏れがある場合に何が存在するかを把握できました。 しかし、それを実用的なものにするにはさらにいくつかのステップを完了する必要があります。次のスライドでは、それについて説明し、どのように組み立てられているかについてご紹介したいと思います。
これらのステップを説明するために、プレゼンテーションのフェーズ3に進みましょう。このダイアグラムをご覧いただくと、システムに入ってくるPlumeやRawデータ、その他のセンサーからのデータをどのようにカタログ化しているかがわかります。カタログの中核となっているのは、STACつまりSpatioTemporal Asset Catalog仕様で、これは地理空間データを整理し、世界中の多くのユーザーがアクセスできるようにする統合ソリューションとして普及しています。このデータベースはAmazon Aurora上のPostgreSQLで動作し、最終的にAWS Lambdaを使用した一時的なエンドポイントを通じて、そしてAmazon API Gatewayを介して提供されます。
データベース内部には、仕様で定義された論理階層があり、ミッションや特定のセンサーを表すCollectionから始まり、各Collectionの中に何千ものItemが含まれる構造になっています。つまり、Catalogから始まり、Collection、そしてItemという階層構造です。これらすべてに特定の空間情報が含まれ、さらに設定可能なメタデータセットがあり、エンドユーザーに漏洩の深刻度や対応方法について正確な情報を提供できるようになっています。
私たちが話してきた処理の柱、真ん中の緑の柱は多くの基盤サービスの上に構築されています。大規模な並列処理にはAWS Lambdaを使用しています。先ほど述べたSTACデータベースはAmazon Auroraで動作しており、マネージド型で最適化されたPostgreSQLインスタンスを利用できます。また、開発のスピードアップとシステムのコストパフォーマンスを最大化するために、多くのオープンソースライブラリを活用しています。これにより、将来的にScepterの大規模な開発者ベースを維持し、Scepterのカスタマーやプロジェクトの貢献者との相互運用性を容易にしています。
次に、最後の緑の柱、つまりサービング部分に移りましょう。データやアラートをカタログで整理・インデックス化した後、それを人々に届ける必要があるからです。この段階については、非常に複雑で、数年かけて苦労して確立してきたため、詳細な説明は省きますが、リアルタイム環境での複雑な情報の整理が現在どのように行われているか、そしてこのサービングシステムをどのような方向に発展させようとしているのかについて、概要をお話しします。
このスライドでは、3種類のデータ提供方法を示しています。1つ目は自動的な方法で、Amazon SNSを使用して、一定の信頼度でPlumeと思われるものを検出した時点で即座にアラートを送信できます。これをScepterのレビューと品質保証チームに送ることも、西テキサスのExxonチームに直接送って検査と漏洩の緩和を行うこともできます。対話性と複雑さのレベルを上げると、他の提供方法として、データや発見事項を大量に取り込むためのプログラマティックなアクセスを提供するAPIがあります。これにより、Exxonのようなエンドユーザーは、既存の大規模で高価なGISシステムや、機密性の高いアルゴリズム、統合が必要なデータセットなどの既存の投資を活用し続けることができます。
最後に、現在Exxonが実際に使用しているユーザーインターフェイスについてご説明します。これは稼働中のウェブサイトで、赤で示された多くのオープンソースコンポーネントを使用しています。AWSが開発したCloudScape Design SystemからMapLibreやReactを使用したウェブサイトのデザインまで、さらにAmazon Location Service、Amazon CloudFront、Amazon Cognitoなど、セキュアでスケーラブルなアプリケーションを構築するためのAWSサービスも活用しています。これを視覚的に説明すると、左側にユーザーインターフェイスを支えるコンポーネントが表示されています。最前面にCloudFront、そしてReactやMapLibreによって構造化されたアプリケーション、その下にLocation Serviceなどのシステムがあり、地図を含む基盤として機能しています。
右側には、アプリケーションのスクリーンショットが表示されており、左側にデータが表示されています。青い円はメタンを検知するIoTセンサーの位置を示しています。また、黄色い線で示された基礎データは、パイプラインの位置を示しており、衛星が事故や漏れを検知する可能性のある場所を表しています。さらに、インターフェイスの標準的な機能により、地図上のデータを空間的・時間的に検索して探索することができます。SNSからAPIを経てユーザーインターフェイスに至るまでの全体的な考え方は、データを精製して、できるだけ多くの人々が使いやすく、価値のあるものにすることです。
これらのユーザーには、この問題を研究しているExxonMobilのデータサイエンティストや、あるいは現場で今朝最も深刻な状況がどこにあるのかを直感的に把握する必要のある作業員などが含まれます。
最後に、この勢いをどこに向けていくのか、今後の展開についてお話ししたいと思います。Amazon Bedrockを通じてLarge Language Modelの可能性を検討しており、ユーザー体験をより簡単に、より信頼性の高いものにするか、あるいはその体験を変革して地理空間機能を追加し、ユーザーが通常よりも迅速に作業を行えるようにすることを目指しています。より短期的に重要なのはAmazon SageMakerです。Philipが言及したように、私たちのデータであれ、パブリックソースから得たデータであれ、感度を可能な限り低くすることを目指しています。私たちは、自社のデータや他社のデータからメタンプルームをより深く、より正確に探索するカスタム コンピュータビジョンモデルを作成するため、Amazon SageMakerを積極的に活用しています。
衛星コンステレーションへの移行には大きな作業が伴います。Philipから説明があったように、この作業は進行中です。私たちには相当な規模のコードベースがありますが、将来的に衛星を管理し、収集スキームを最適化し、漏れや事故が地球上のどこかで発生していることを発見した際にリアルタイムで対応し、場合によっては収集計画を変更できるようにするための準備作業が必要です。これらすべて - 範囲とスケールの拡大、自動化と精度と感度の向上 - を組み合わせることで、大気の健全性を監視し確保するためのより頻繁で正確なシステムの実現に向けて前進していきます。
最後にもう一度詳しく見ていきますと、このような模式図のシナリオに戻ります。メタンガスの漏れが発生した場合、ScepterAirプラットフォームは、単独または複数のセンサーからリアルタイムで自動的にこれを検知し、信頼性の高いアラートを生成して、現場または遠隔で対応可能な担当者に通知することで、タイムリーな漏洩対策を可能にします。そして、これにより、大気環境の未来に潜在的なインパクトを与えることができるのです。
ExxonMobilのメタン排出削減への取り組み
では次に、ExxonMobilのEmily Reidyからお話を伺います。ありがとうございます。この物語の最終章として、エンドユーザーの視点からお話しさせていただきます。先ほどご紹介がありましたように、私はEmily Reidyと申します。ExxonMobilのメタン排出研究チームのメンバーとして、石油・ガス事業におけるメタン排出の検知、定量化、削減のための技術開発に重点的に取り組んでいます。
ExxonMobilでは、私たちが「and」方程式と呼んでいるものに焦点を当てています。つまり、世界のエネルギー供給を継続しながら、同時に排出量を削減するにはどうすればよいかということです。このグラフは、パリ協定が締結された2016年を基準とした総排出量の推移を示しています。協定以降、ExxonMobilはScope 1およびScope 2の排出量を大幅に削減してきており、さらなる削減計画も進行中です。当社は、運営するすべての資産について2050年までにネットゼロを達成する目標を掲げており、特にテキサス西部とニューメキシコにまたがるPermian盆地では、目標年を2050年ではなく2030年に設定しています。これは全ての温室効果ガスを対象としていますが、その大部分はメタンの管理に関連しています。
メタンには大きな課題があります。上のグラフは、2つの石油・ガス盆地における航空調査の結果を示しています。各検知は排出量で示されており、このセンサーの検知限界である時間当たり10kgから、まれに発生する大規模な排出事象による数千kg/時まで及びます。私たちはこの全範囲にわたって適切に測定する必要があります。どのセンサーが最適かという質問に対する答えは、「すべてのセンサーを常時使用する」ということです。私たちは複数のセンサーを組み合わせて使用しています。数日に1回の頻度で広域をカバーできる衛星は、検知限界は高めですが、まれに発生する大規模な排出事象を捕捉するのに役立ちます。グラフの中程では、時間当たり10～20kgを測定できる航空機やHigh-altitude pseudo satellitesによる航空調査を使用しています。さらに、このグラフの範囲を超えて、より局所的な時間当たり1～10kgの領域では、連続モニタリングのような現場レベルのセンサーやサイト全体を調査できるドローンを使用しています。さらに小規模な排出については、ハンドヘルドカメラを使用して個別の機器のモニタリングも行っています。
これらの異なる種類のデータを使用する際の課題の1つは、それぞれが異なる頻度で異なる種類のデータを生成することです。そのため、これらの異なるデータタイプと収集時間に対応できるデータフュージョンプラットフォームが必要となります。連続モニタリングは15分ごとにデータを提供し、衛星は数日ごと、航空調査は大量のデータを提供しますが、年に数回程度しか実施できません。また、データを迅速かつ正確に処理できる必要があります。Philipが言及したように、これらの排出イベントは断続的で、自然に開始・停止したり、特定のプロセスに関連付けられたりします。何かが起きていることをすぐに把握できないと、すでに停止してしまった排出イベントを確認するために作業員を派遣してしまう可能性があります。現場スタッフの時間を効率的に使い、問題を正確に解決できる地域に派遣できるようにしたいと考えています。
データフュージョンプラットフォームはまた、グローバルに拡張可能である必要があります。ExxonMobilは6大陸で事業を展開しており、メタン排出モニタリングにより多くの異なるデータが生成されることになります。テストベースンからよりグローバルなモニタリングへと積極的に拡張できる必要があります。また、これは柔軟で目的に適したものでなければなりません。メタンは規制環境が進化している分野であり、報告にさらに多くの測定を組み込む全般的な動きがあります。これがまだ確定している段階なので、あらゆる報告に対応できるよう、すべての測定データに簡単にアクセスできる必要があります。
データフュージョンプラットフォームの実用と今後の展望
現在の排出アラートワークフローでは、これらの異なるデータセットをすべて活用しています。衛星、連続モニター、航空調査、ドローンやUAVなど、これらすべての観測データがCenter for Operations and Methane Emissions Tracking（COMET）に送られます。COMETのオペレーターは、これらの観測データをタンク圧力やフロー値を含む社内のモニタリングプロセスデータと組み合わせています。これらすべてを使用して状況を把握し、適切な現場担当者に警告を発し、排出が発生していると思われる場所について適切な情報を提供しています。
SCEPTERのようなデータセットがあれば、COMETのスタッフの運用負担を軽減できます。すべてのアラートが全く同じ形式になり、異なる時間に入ってくる異なる種類のデータを統合することを心配する必要がなくなります。アラートが発生した場合、全く同じ方法で入ってくるため、彼らは得意とする業務、つまり社内データとの組み合わせや、排出を軽減するために必要な情報を持って適切な現場担当者に警告を発することに集中できます。
データフュージョンプラットフォームの要件を簡単にまとめると、異なるデータタイプを取り込むことができる柔軟性が必要で、現場担当者を適切なタイミングで適切な場所に派遣できるよう、自動化された迅速な処理が必要です。また、グローバルな資産全体で安全にスケールアップでき、明確なアクションにつながるアラートと通知を生成できる必要があります。SCEPTERのようなデータフュージョンプラットフォームは、現在のモニタリングおよび緩和の取り組みと合わせて、2030年までに運営資産でNet Zeroを達成するという目標を含め、メタン排出量を効率的に削減するのに役立ちます。以上で私の発表を終わります。質問の時間が取れるかもしれませんが、もし取れない場合は、私たち3人は外にいますので、お気軽に声をかけてください。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion