※本記事は、ITUが主催し50以上の国連パートナーおよびスイス政府と共催するAI for Goodの一環として開催されたワークショップ「Embedding workflows for Earth Observation tasks」の内容を基に作成されています。本ワークショップでは、地球観測（EO）アーカイブの急速な増大という課題に対し、基盤モデルを用いてタスクに関連する情報を保持したEO埋め込みを生成する手法が示されました。これらの埋め込みによって、最大2桁小さい軽量デコーダーの利用が可能となり、学習・推論の高速化を実現します。
登壇者は、Horizon EuropeプロジェクトEvoLandおよびEmbed2Scaleの主任研究者であり、ドイツ航空宇宙センター（DLR）所属のConrad M Albrecht氏、ならびにIBM Researchのリサーチソフトウェアエンジニアを務めるIsabelle Wittmann氏です。モデレーターは、ミラノ工科大学教授のMaria Antonia Brovelli氏、UNICEFのClimate and Environment Data Unit所属のRohini Swaminathan氏が務めました。
AI for Goodは、革新的なAIアプリケーションの発掘、スキルと標準の構築、パートナーシップの推進を通じて、グローバルな課題解決に取り組むプラットフォームです。詳細情報およびコミュニティへの参加については、Neural Networkプラットフォーム（https://aiforgood.itu.int/neural-network/ ）をご覧ください。
本記事はワークショップの内容を要約しております。なお、本記事の内容は原著作者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの動画をご視聴いただくことをお勧めいたします。
1. セッション概要と書籍紹介
1.1 AI for GoodとGEO AI Discovery Seriesの位置づけおよび登壇者紹介
Anna： AI for Goodへようこそ。本プラットフォームは、国際電気通信連合（ITU）が主催する、行動志向でグローバルかつインクルーシブな国連のAIプラットフォームであり、50以上の国連姉妹機関と提携し、スイスと共同で開催されているものです。AI for Goodの目標は、AIの可能性を解き放ち、人類に資することです。本日のセッションでは、ライブビデオウォール機能を活用して質問やコメントをお寄せいただき、議論を活発にしていただければと思います。それでは本日の最初のスピーカーをお迎えしましょう。
Rohini： 皆さん、こんにちは。本日のセッション「Embedding workflows for Earth Observation tasks（地球観測タスクのための埋め込みワークフロー）」へようこそ。私はRohini Swaminathanと申しまして、UNICEFのClimate and Environment Data Unitに所属しています。GEO AI Discovery Seriesの新エピソードをご紹介できることを大変光栄に思います。このシリーズは2022年初頭に開始され、すでに4年以上が経過しています。これまでウェビナー、ハンズオンワークショップ、複数のGEO AIコンペティションといった形で40以上のエピソードを開催してきました。現在のシリーズの焦点は、地理空間大規模言語モデル（geospatial large language models）と、地理空間データへのAI適用における実践的スキル構築を目的としたハンズオンワークショップにあります。これらはシリーズのキュレーターであるMaria Brovelli教授と、ITUの共同コーディネーターであるAndrea Manaraのリーダーシップのもとで進められてきました。過去のエピソードを見逃された方も、YouTubeまたは現在ご視聴中のニューラルネットワーク上で全ての録画をご覧いただけます。それでは、本日のイベントをモデレートしてくださるMaria教授をお迎えします。
Maria： Rohiniさん、ありがとうございます。皆さん、こんにちは。本日もお越しいただきありがとうございます。簡単に自己紹介させていただきますと、私はPolitecnico di MilanoのGIS教授で、Geoinformatics Engineering課程に所属しており、またRoma La Sapienzaの博士課程およびData Science and Earth Observation学院のメンバーでもあります。ISPRSの地理空間情報委員会副会長、International Society of Digital Earthの副会長、国連グローバル地理空間情報管理アカデミックネットワーク理事会のメンバーといった役職も務めています。本日のエピソードも非常にエキサイティングなものになりますし、何より誇りに思っているのは、これがオール女性のエピソードであるという点です。スピーカーも女性をお迎えしています。
1.2 書籍『Introduction to Geospatial AI』の概要と無料公開
Maria： ウェビナーを始める前に、皆さんに広くご関心を持っていただけそうなものを一つご紹介させてください。先日、私たちは書籍を出版しました。主な貢献者はGordana JakimovskaとMiro Govedaricaで、それぞれBanja Luka大学とNovi Sad大学の教授です。彼らと私の共著で『Introduction to Geospatial AI』というタイトルで出版しました。序文はJGIM共同議長の一人であるMuhammad Deelan博士に執筆いただき、レビューはレオン大学のFlor Alvarez TaboadaおよびNovi Sad大学のMilan Radjic教授にお願いしました。
この書籍の内容は地理空間AIへの入門として位置づけられていますが、既にAIに精通しており地理空間について少し学びたい方にも、逆に地理空間に詳しくAIについて新たに学びたい方にも使っていただける構成になっています。重要なのは、本書が誰でも無料でダウンロードできるという点です。スライドにダウンロード先のリンクを掲載していますので、そちらからアクセスしてください。最初にページを開くとキリル文字で表示されますが、これはBanja Luka大学が出版しているためです。英語に切り替えれば全ての情報を英語で閲覧できます。
これは第一版ですので、皆さんのお役に立てればと願っていますが、もし誤りや間違いを見つけられた場合はぜひご連絡ください。書籍の品質をさらに向上させていきたいと考えています。
1.3 本ワークショップのテーマ設定
Maria： さて、本日の本題に入りましょう。今回ご紹介する内容は、まさに時宜を得たトピックです。現在私たちが直面している問題の一つに、地球観測アーカイブが急速に増大しているという課題があります。問題は、このデータをいかに効率的に扱い、いかに効率的に管理するかということです。本日のワークショップは、この問いに対する一つの答えを提示するものになります。
具体的には、基盤モデル（foundation models）がタスクに関連する情報を保持しながら、どのように地球観測（Earth Observation, EO）埋め込みを生成できるのかを示していきます。これらの埋め込みによって、軽量なデコーダーを使用することが可能となり、最大で2桁（100倍）小さいモデルで済むようになり、学習と推論の両方を加速できます。ワークショップの最後では、TerraTorchとNeuCoBenchを統合した完全なワークフローを示し、生成された埋め込みを即座に評価する流れをご覧いただきます。非常に時宜を得た、エキサイティングな内容です。
それでは本日のスピーカーをご紹介します。本日のスピーカーはIsabelle Wittmannさんです。Isabelleさん、こんにちは。IBM Research Zurichのリサーチソフトウェアエンジニアで、Global Climate and Sustainabilityチームに所属しています。ETH Zurichで統計学の修士号を取得されており、実は私もそこで数年間教える機会を持つことができました。彼女の研究は、地球観測の基盤モデル、表現学習、そして大規模衛星データのためのデータ圧縮技術に焦点を当てています。Isabelleさん、ようこそ。それでは、フロアをお譲りします。
Isabelle： ご丁寧なご紹介をありがとうございます。本日ここに参加できることを大変嬉しく思います。それでは早速、本題に入っていきましょう。画面を共有させていただきます。スライドが表示されていますでしょうか。
Maria： はい、見えています。完璧です。
2. 地球観測データの課題と埋め込みワークフローの動機
2.1 EOデータが抱える障壁と埋め込みによる抽象化レイヤーの役割
Isabelle： それではキックオフさせていただきます。ご紹介いただいた通り、本日のテーマは「地球観測タスクのための埋め込みワークフロー」です。非常にハンズオン中心のセッションとなり、TerraTorchを使った作業や、NeuCoBenchによる埋め込みのベンチマーキングを実際に行っていきます。ただし、それらの実技に入る前に、なぜこのトピックが今これほど重要で、地球観測の未来にとってこれほど有望なのか、その動機づけをお話ししたいと思います。
EOデータを日常的に扱っていらっしゃる方であれば、これからお話しするペインポイントにきっと共感していただけると思います。まず、EOデータは非常に大容量です。そのため、データを扱う上で、ダウンロード、保存、転送のいずれの場面でも頻繁にボトルネックとなります。次に、EOデータの利用にはドメイン知識が要求されます。地理空間データを扱い始めようとする新しい人にとっては、この点が大きな参入障壁となっています。そして、EOデータは非常に高次元です。時間的にも空間的にも複雑であるため、スケールさせることが難しく、新規参入者にとっても扱いにくい性質を持っています。
このような状況の中で、現在私たちが目にしている一つの有望な転換が、地球観測埋め込み（Earth Observation embeddings）への移行です。埋め込みとは何かと言えば、それは生データの上にある抽象化レイヤーです。生データに含まれる潜在的にマルチモーダル・マルチテンポラルな情報を、より効率的かつ前処理された形で要約し、よりコンパクトで再利用可能なフォーマットへと抽象化します。これによって、この埋め込みレイヤーを共有するだけで作業が可能になり、以前ほどのドメイン知識を必要とせず、扱いやすくなります。さらに、軽量なデコーダーを上に載せることもできます。これまでのセッションでTerraやAlpha Earthについて聞かれた方は、EO埋め込みの可能性についてすでに素晴らしい解説をお聞きになっているかと思います。
2.2 埋め込みワークフロー全体像とエンコーダー・デコーダー分離の設計思想
Isabelle： しかし、本日のフォーカスはEO埋め込みプロダクト単体ではなく、その背後にある埋め込みワークフロー全体です。なぜなら、誰でもアクセスしやすい形で前処理済みのEO埋め込みプロダクトが提供されるのは素晴らしいことですが、それだけで完結する話ではないからです。埋め込みに関する研究には、さまざまな埋め込みワークフローという広がりがあります。
「ワークフロー」という言葉で私が包括的に指しているものは、まず埋め込み生成そのものです。表現を生成し、異なるタイプのタスクや異なるタイプの埋め込みに適応しうるエンコーダーを研究する領域です。次に、保存形式に関する数多くの問いがあります。誰もが扱えるように、埋め込みをどのように保存し、共有し、配布するかという問題です。さらに、どのようなデコーダーがあり、埋め込みの品質をどのようにベンチマークするか、という論点もあります。
EO埋め込みとその背後のワークフローの両方に通底する一般的な前提は、表現の生成、つまり重いエンコーディングと、より軽量なデコーディングを常に分離するという考え方です。これによって、はるかに軽量なワークフローが可能となり、より速くイテレーションを回せるようになります。
2.3 セグメンテーションタスクでの推論速度比較とEmbed2Scaleプロジェクト
Isabelle： 最後にもう一つ、動機づけの例をお示ししたいと思います。これはセグメンテーションタスクの例で、本質的にはフル基盤モデルのワークフローと、埋め込みワークフローの比較になります。右側にあるのが従来のフルワークフローで、これについてはこの後改めて詳しく見ていきますが、非常に重いバックボーンを動かす構成です。一方、左側が埋め込みワークフローで、同じバックボーンから事前計算された埋め込みを利用し、その上に軽量なデコーダーだけを載せています。当然、推論時にパラメータ数がはるかに少ないため、こちらの方がはるかに高速に動作することがわかります。このように、埋め込みワークフローがもたらす実践的なメリットは具体的に存在します。
ここで動機づけはひとまず置いて、本日ご紹介する内容の背後にいるチームについても簡単に触れさせてください。私はIBM所属ですが、私たちは「Embed2Scale」という、より大きなEUプロジェクトの一員として活動しています。このプロジェクトでは、まさに本日お話しするようなテーマの研究を行い、埋め込みワークフローのためのツールを構築し、気象データやEOデータのための新しい埋め込み手法を研究しています。本日の発表は、このプロジェクトに参加している多くの素晴らしいパートナーの代表として私がお話ししているに過ぎません。皆さんへ向けてその全パートナーをご紹介させていただきます。
3. EO AI研究の進化と埋め込み研究の地形
3.1 個別タスク学習からGeoFMを経て埋め込みワークフローへの発展
Isabelle： それでは、導入の続きとして、地球観測研究において過去数年間にどのような進化が起きてきたのかを、もう少し深く見ていきたいと思います。最初の大きなマイルストーンは、個別のダウンストリームタスクへのAI適用です。これは典型的な単位で、手元の特定のタスクにモデルをフィットさせるというものでした。具体的には、ラベルと生の入力データがあり、学習済みの手法を訓練して未知のデータに対してラベル、例えばセグメンテーションマスクや分類ラベルを推論させるという流れです。これは最初の重要なステップであり、大量のラベル付きデータを活用し、ターゲット変数を手動でモデリングするよりもはるかに効率的な学習を可能にしました。
その後、数年前から地理空間基盤モデル（Geospatial Foundation Models, GeoFM）が台頭してきました。その根底にある考え方は、大量のラベルなしデータで事前学習を行い、EOデータ全般、そしてモデルが処理することになるであろう典型的なデータの理解を獲得させるというものです。マスキングや別の形式の再構成タスクといった教師なしの方法で訓練することで、非常に良い理解を持ったバックボーンが得られます。このバックボーンをさまざまなダウンストリームタスクに適用すれば、よりラベル効率的に学習を進められます。具体的には、バックボーンの上にデコーダーを載せ、より少ないラベル数で特定タスクに適応させ、セグメンテーションマスクなどのターゲットを予測することになります。
しかし、ここで重要なのは、典型的なワークフローでは常に生データからラベルへと進むという点です。ファインチューニングにおいてもバックボーンを使い、画像をバックボーンに通して推論を行います。多くの場合エンコーダーをフリーズせず、ファインチューニング中にバックボーン内のパラメータも更新されます。これは大きなオーバーヘッドです。重いバックボーンをダウンロードしなければなりませんし、フルファインチューニングではバックボーンを通して推論を行い、場合によってはそこのパラメータも調整しなければなりません。
そこで埋め込みの可能性として浮上するのが、この重いステップを取り除くことです。事前学習済みエンコーダー、つまり既存のGeoFMや、最近見られるAlpha EarthやTesseraのような新しい埋め込みモデルを使って埋め込みを生成します。そうすれば生データはもはや必要なく、埋め込みをダウンロードするだけで済み、手元のダウンストリームタスクのラベルを使って直接デコーダーを訓練できます。私はこれをダウンストリームタスクあたりの効率という観点で整理しています。埋め込みワークフローではデータダウンロードを取り除けますし、軽量なデコーダーだけで済むためラベル効率も高く、GeoFMワークフローのハードルを克服できる可能性があります。ここでの可能性は、性能をどんどん押し上げ、右上の隅、つまり最高の効率と最高の性能の方向へと、埋め込みワークフローをどこまで押し上げられるか、そしてどれほど多様なユースケースに使えるかを探っていくことにあります。
3.2 埋め込み研究の三系統（GeoFM埋め込み、Embedding Fields、Location Encoders）とタスク別研究動向
Isabelle： 現在の研究状況について、すでにシリーズで取り上げられた他のトークとも結びつけて簡単にご紹介します。地理空間埋め込みには現在、いくつかのタイプがあります。左側にあるのが、基本的に地理空間基盤モデルの埋め込みです。これは先ほど私が紹介した内容に非常に近く、本質的には事前学習済みの視覚特徴抽出モデルから得られる埋め込みです。マスキングで事前学習されたモデル、あるいはマルチモーダルや対照学習で事前学習されたモデルがその対象で、現在見られるもののほとんどはTransformerモデルです。これらのモデルはパッチ埋め込みを生成し、与えられた入力に大きく依存します。つまり、与えた入力データ、すなわち1枚の画像や複数の時系列点の表現としての埋め込みが常に得られ、後者では埋め込み空間においても複数の時間ステップが生成されます。この研究分野はコンピュータビジョンから強く影響を受けており、関連した発展を遂げています。
より最近では、埋め込みフィールド（Embedding Fields）という潮流があり、Alpha EarthとTesseraがこれを推し進め、明示的にこの考え方の下に構築されています。ここでの基本的なアイデアは、空間的・時間的に一貫性のある埋め込みプロダクトのグローバルマップを得ることです。Alpha EarthとTesseraは異なる側面に焦点を当てていますが、主な違いは大量の入力データを使い、この埋め込みプロダクトを得ようとしている点です。つまり、埋め込みレイヤーとして得たいわけで、しばしば時間的に集約された、たとえば1年間のグローバルスナップショットといった形になります。また、空間的・時間的一貫性により高い焦点が置かれています。
もう一つの研究分野として、ロケーションエンコーダー（Location Encoders）があります。これはより粗いスケールで動作するもので、全体像を提示するためにここに記載していますが、本日はあまり時間を割きません。ロケーションエンコーダーの考え方は、座標から埋め込みへのマッピング、あるいは陰的ニューラル表現を得ることです。これらのプロダクトはしばしば一回限りの静的プロダクトで、座標とさまざまな画像やモダリティとの間で対照学習の損失を取って訓練されます。
タスクとユースケースに関して最後に触れたい点は、これらのアプローチは異なるユースケースを持ち、研究の進み方も異なるということです。古典的なGeoFMの分野は密なマッピング、つまりセグメンテーションのユースケースや変化検出といった領域に強く焦点を当ててきました。PIO、Geo-Bench、そして現在のGeo-Bench 2のように、標準化されたベンチマーキングへの収束も見られます。一方、埋め込みフィールドはより新しい分野で、ローショット方式でベンチマークされるのが一般的です。少数のラベルを用意し、線形プローブのような非常に軽いヘッドを上に載せて訓練するか、教師なしクラスタリングを行うといった形です。これまでのところ、密な畳み込みデコーダーを埋め込みフィールドの上に載せるという方法はあまり探求されていません。同様に、ロケーションエンコーダーもゼロショットや弱教師あり、つまりラベル付きの線形MLPデコーダーを使うという形が中心です。
3.3 TerraMindでの3条件比較実験と性能・効率トレードオフの実証
Isabelle： 密なセグメンテーションタスクに関連して、現在どのような性能が見られているか、そしてGeoFM分野で一般的なフルファインチューニングワークフローとどう比較されるか、最初の印象をお伝えするために一つお見せしたいものがあります。ここで示しているのはTerraMindの比較で、セグメンテーションタスクのベンチマーキングを3つの設定で比較しています。
一番右の点が標準的な設定で、バックボーンをアンフリーズしたものです。これはたとえばGeo-Benchがベンチマークしている形式です。真ん中ではTerraMindをフリーズ状態で使いつつ、それでも重いUNetデコーダーを載せています。そして左側が埋め込みワークフローで、TerraMindから1回だけ抽出した埋め込みを使用しており、これはこのケースでは最終層の埋め込みです。その上に軽量な数層の畳み込みデコーダーだけを訓練しています。
ここから見えてくるのは、性能におけるトレードオフです。性能はやや低下します。これはモデルが適応・学習する柔軟性が低いためです。しかし、パラメータ効率は劇的に向上します。このケースでは最大で200倍効率的になります。また埋め込みサイズも小さくなります。パッチ埋め込みのため、最大で4倍コンパクトです。例えば、本日この後使用する基盤モデルのtinyやsmallバリアントを使えば、この比率はさらに大きくなります。これは、たとえば10メートル解像度の埋め込みフィールドと、基盤モデルから得られるパッチ埋め込み（こちらにも一定の圧縮率があります）との重要な違いでもあります。
4. TerraTorchの設計思想とアーキテクチャ
4.1 TerraTorchの概要と埋め込みワークフロー対応のための機能拡張
Isabelle： それでは時間を確認しつつ、次のパートであるTerraTorchデモへ進みたいと思います。TerraTorchをご存知ない方のためにご説明しますと、これはコミュニティツールキットで、もともとIBMが導入・維持してきたものです。基盤モデルとのインタラクションをより容易にし、ファインチューニングワークフローを非常にシンプルなノーコード・ローコード方式で実現することを目的としています。そして今回、私たちはTerraTorchを拡張し、埋め込みワークフローをよりよく取り込めるようにしました。
もともとTerraTorchは、GeoFMで見てきたような「生入力画像からラベルへ」というパイプラインを常に備えていました。しかし、今回新たに機能を追加し、先ほどご紹介した二つのステップに、より柔軟にワークフローを分割できるようにしました。つまり、まず埋め込みを生成し、その埋め込みをダウンストリームタスクに用いるという流れを、できるだけスムーズに行えるようにしたのです。
埋め込みの抽出は、多くの異なるフォーマットで可能です。GeoParquet、GeoTIFF、集約された埋め込みのためのオーバービューテーブル、あるいは密なパッチ埋め込みを保持したい場合には個別の埋め込みファイルといった選択肢が用意されています。そして、生成した埋め込みは分析など他の用途に使うこともできますし、「ラベルが手元にあるのでダウンストリームタスクのワークフローに直接使いたい」と思った場合には、埋め込みを再び読み込み、これまでGeoFMで統合されていたワークフローと非常に似た形で利用できます。つまり、その上にデコーダーを訓練するだけでよく、先ほどお見せした結果を実質的に再現できるわけです。
4.2 PyTorch・TorchGeo基盤のレイヤー構造とTerraTorch Tasksの仕組み
Isabelle： TerraTorchの内部構造について、もう少し詳しく見ていきます。TerraTorchはPyTorchの上に構築されており、PyTorchやTorchGeoが提供するボイラープレートのセットアップを活用しています。これは、TerraTorchが取り込んでいるバックボーンの基盤としても機能しています。そしてその上に、ファインチューニングワークフローを効率的に行うための機能群を載せています。
ここでの主要なコンポーネントがTerraTorch Tasksです。たとえばセグメンテーションタスクがあれば、そのタスク向けに用意されたタスクを使うことになります。タスク側には必要な機能がすでに備わっており、ユーザーは時間軸や使用するデータのフォーマット・種類に応じて、データモジュールを柔軟に差し替えて利用できます。同様に、デコーダーやバックボーンも自由に入れ替え可能で、「どのバックボーンがどれくらいの性能を出すのか」「どの程度のデコーダー容量が必要なのか」といった実験を柔軟に行えます。
4.3 Identity Backboneによる既存ワークフロー再利用と多様な出力形式
Isabelle： 埋め込み生成タスクは、このインフラにそのまま組み込まれています。新たに用意した埋め込み生成タスクは、本質的にはPyTorchのpredictワークフローです。データセットに対して一度だけ実行すれば、すべての埋め込みが格納された出力フォルダが生成されます。利用できるバックボーンは、これまでも利用可能だったものすべてです。集約戦略もさまざまに選べます。先ほども触れた通り、密な埋め込みをそのまま取ることもできれば、入力画像全体に対して1つの埋め込みを得たい場合にはMean Poolingを指定することも、Max Poolingを使うことも、バックボーンからCLSトークンを取り出すこともできます。これらすべてが可能です。
そして、ここで一つの小さな工夫を取り入れています。それがIdentity Backboneです。埋め込みを生成した後、他のすべてのダウンストリームタスクのワークフローは、埋め込みをロードする形でそのまま適用できるようになっています。つまり、埋め込みを使う場合には、実質的にバックボーンの部分をスキップする、というわけです。これによって、これまでGeoFMで用いてきた仕組みをほぼそのまま再利用しながら、ヘビーなエンコーダーステップを取り除いた埋め込みワークフローへとシームレスに移行できる構造になっています。
5. TerraTorchデモ：埋め込み生成パイプライン
5.1 環境セットアップとHLS Burn Scarsデータセットの構造
Isabelle： ここまでの説明で、デモを始める準備がほぼ整いました。これから何を行うかを簡単にまとめますと、まず埋め込みを生成します。題材はHLS Burn Scarsデータ、正確にはその一部のサブセットです。本質的には、スライド右側に示しているプロット、つまり埋め込みのPCAマップを再現することを目指します。そして二つ目のパートでは、生成した埋め込みを使ってHLS Burn Scarsのワークフローを実行し、手元のラベルにフィットさせていきます。
それでは画面を切り替えます。ブラウザが見えていると思います。本日は皆さんに沿って実習していただけるよう、GitHubリポジトリを用意しました。このリポジトリは自己完結的になっており、ワークショップ中も、終了後に戻って復習する際にも使えます。リンクは皆さんと共有されているはずですが、見つからない場合はこちらでもお見せします。リポジトリ名は「embed2scale-AI-for-good-tutorial-2026」です。
私は完全に空のフォルダから始めます。まずsetupファイルに従って手順を進めていきます。最初にすることはリポジトリのクローンです。これでローカルに用意でき、いくつかのデータサンプルも含まれています。例えば、これから使うHLS Burn Scarsデータのサンプルがいくつか入っており、追加でデータをダウンロードする必要がない自己完結的な構成にしています。クローンしたフォルダに入り、環境を構築します。インストールしたいのはTerraTorchライブラリと、後ほど使うNeuCoBenchです。pip環境を使うこともできますし、より高速なUV環境を使うこともできます。これは好みでお選びください。環境を有効化し、コマンドに従ってTerraTorchとNeuCoBenchをインストールします。
一つ細かな工夫として、NeuCoBenchリポジトリにはCSVファイルが含まれているのですが、自動でプルされないようにするコマンドを実行します。これで、NeuCoBenchリポジトリをクローンする際に軽量に済みます。最後にrequirementsをインストールします。setupファイルに戻ってこの手順をご自身のペースで進めていただいてかまいません。私は説明を続けます。もしTerraTorch のインストールに問題がある場合、GDALが入っていない可能性があります。その場合は、setupファイルのこのセクションを参照してください。さらに、後で使うNeuCoBench用のラベルもこのタイミングでダウンロードしておきます。これで、本日のすべてのチュートリアルを進める準備が整いました。
リポジトリ構造について簡単に説明しますと、私は3つのパートそれぞれに対応する番号を付けています。これによって、どのファイルがパート1、パート2、パート3のものか一目でわかります。scriptsはデータダウンロード用のスクリプト、dataは先ほど触れたサンプルデータ、workflowsにはノーコードスクリプトの大半が入っています。ここにはノーコードのTerraTorchワークフロー用のconfig YAMLファイルや、後でNeuCoBenchを実行するためのbashスクリプトが含まれています。
それでは、notebooksフォルダに移動してJupyter notebookを起動します。最初に開くのは埋め込み生成のノートブックです。ダウンストリームのノートブックは、ローカルで埋め込みが生成されていることを前提としているからです。これらの例は、公式のTerraTorchの例に非常に近く対応しています。公式版ではフルデータを使い、埋め込み生成もColabで実行可能です。ただ今回は、生成した埋め込みを別のワークフローでも再利用したいため、ローカルで実行できるGitラッパーを用意しました。これによって、すべてが1つのColab環境内に閉じ込められず、ローカルに埋め込みを置いておけるため、扱いやすいと考えています。
なお、ライブデモ中に小さな問題が発生しましたが、本質はカーネルの問題で、Jupyter notebookで仮想環境のカーネルが認識されていなかったというものでした。setupファイルに従ってカーネルを登録し直すことで解消できます。これに気づくきっかけをくださった視聴者の方、本当にありがとうございました。
使用するデータについて補足しますと、HLS Burn Scarsデータセットはフルバージョンへのリンクも記載しています。すでにご存知の方もいらっしゃるかもしれません。今回は24サンプルを含めており、このデータは6バンド・512×512ピクセル、そして焼け跡領域を示すバイナリマスクを伴います。本質的にはセグメンテーションタスクです。本日のために行った工夫として、通常であれば訓練・検証・テストの分割を設定できますし、Burn Scarsの場合はそれがあらかじめ定義されていますが、今回は24サンプル全てを訓練・検証・テストすべてに使います。デコーダーの訓練時も同様です。これはあくまでパイプラインの見た目を理解することが目的であり、本番では正しい分割を使い、ホールドアウトデータで性能を判定する必要があります。
5.2 データモジュール設定と正規化統計値の重要性
Isabelle： それではノートブックに入っていきます。必要なのはデータモジュールと埋め込み生成タスクですので、それらをTerraTorchからインポートします。構造としては、紹介したサブセットをdataとして使い、結果はresultsフォルダ内の埋め込みに書き出します。
データモジュールの設定は他のTerraTorchチュートリアルと非常に似ています。すでに自分のデータ用にうまく動くデータモジュールをお持ちであれば、それを埋め込み生成にもそのまま使うことができます。データモジュールの一般的な構造として、設定可能な標準項目があり、特に訓練ではメモリに応じてバッチサイズを変えたり、リソースに応じてワーカー数を変えたりすることが重要になります。
今回はBurn Scarsデータに適しているためSegmentation Data Moduleを使い、ここでバイナリタスクであることも設定します。これは埋め込み生成では使用されない入力期待値ですが、入力として受け取るのでここで設定しておきます。重要なのは出力ディレクトリの指定です。これは実際にはoutput pathに当たります。読み込むデータのほうはデータモジュールが利用する入力データです。今回扱うデータは、ラベルか生入力データかを示すサフィックスで構造化されているため、その情報もデータモジュールに渡します。マージされる側がイメージデータ、マスクがターゲットラベルとして指定されます。これらがバイナリのセグメンテーションマスクとなります。
そしてここで強調すべき重要な点があります。バックボーンから埋め込みを生成する際は、当然バックボーンをフリーズして使用します。推論して埋め込みを取り出すだけで、学習ステップは含まれません。だからこそ、他のファインチューニングワークフロー以上に重要になるのが、入力データのレンジがバックボーンが知っているレンジ、つまり訓練されたレンジに合致しているかという点です。今回のケースでは、HLSデータを元の0〜10000のレンジから線形に0〜1にスケーリングしています。さらに、TerraMind事前学習時の値を同じ0〜1のレンジで抽出しました。本質的には、データが0〜1のレンジにあることを前提として、バックボーンであるTerraMindが訓練されたmeanおよび標準偏差の正規化値を渡し、データを適切なレンジに前処理してもらいます。
これでpredictモードでデータモジュールをセットアップします。今は学習や訓練を行いたいわけではなく、predictデータローダだけが必要だからです。データを少し確認してみましょう。データモジュールにはpredictデータセットが含まれているので、それを呼び出してサンプル数を確認します。リポジトリに含めた24サンプルと一致しています。プロット関数を使って最初の数サンプルを見てみると、すでに把握している通りのデータが見えます。左側に生入力画像、データモジュール内ではプロットに使うRGBインデックスが定義されていて、6バンドHLSデータの場合、RGBは最初の3チャンネルですが順序が異なるため、どこからRGBチャンネルを取得すればよいかを指定しています。右側にマスクが表示されます。Burn Scarsデータは、多くの場合、視覚的に焼け跡を明確に確認できるという良さがあります。大規模な焼け跡もあれば、画像の真ん中にあるような小さなものもあります。
5.3 Embedding Generation Taskの設定項目（バックボーン、レイヤー、プーリング、出力形式）
Isabelle： これでデータモジュールの準備は完了です。要するに、データを提供してくれるプラグアンドプレイのデータモジュールができたわけです。残るは埋め込み生成タスクの初期化です。ここではTerraTorchで利用可能な任意のバックボーン、つまり世の中の事前学習済みGeoFMのほとんどを使うことができます。今回はTerraMindを使うので、TerraMind smallを初期化します。実際にどう行うかの例が複数ご覧になりたい場合は、TerraTorchに例がありますし、TerraMindの埋め込みを生成したいとわかっている場合は、TerraMindのGitHubをGoogle検索すれば例がいくつか見つかります。設定可能な項目について、より詳細な解説もそちらにあります。
本日のケースでは、S2L2Aモダリティのみを初期化します。TerraMindはマルチモーダルモデルですが、入力として持っているのは6バンドのHLSだけなので、S1データなど他のモダリティの埋め込みは行いません。そして非常に重要な点として、backbone_pretrained=Trueを必ず設定してください。これを設定しないとアーキテクチャがランダムに初期化されてしまいます。当然ながら、私たちは事前学習済みの重みをロードしたいわけです。さらに、S2L2Aは通常12チャンネルですが、今回はHLSのLandsat-Sentinelプロダクトに対応する6バンドを期待するようバックボーンに伝え、データモジュールから渡される6バンドとバックボーンが期待するバンド数の整合を取ります。別のモデルや別のモダリティのデータを使いたい場合は、ここを差し替えることになります。
埋め込み生成タスクを構築する際には、ここからが本格的な設定の楽しいところです。出力フォーマットや集約方法など、さまざまな設定を行えます。必要な引数を見ていきます。まずバックボーンを渡し、埋め込み抽出元のバックボーンを選びます。次に出力フォーマットを設定します。いくつかの選択肢があります。先ほど触れた通り、TIFFはGeoTIFFファイル、Parquetは入力サンプルごとに個別のGeoParquetを得る形式で、入力画像ごとに個別のParquetが生成されます。Joint Parquetも可能で、これは集約を行う場合に特に適しており、サンプルごとの行と、集約されたmean埋め込みなどを持つ単一のParquetファイルが得られます。後ほど見ていただきますが、NeuCoBench向けに調整された出力タイプもあります。
次に出力パス、つまり埋め込みを保存する場所を指定します。続いて抽出対象のレイヤーです。先ほどお見せした性能比較は最終層の埋め込みでしたが、最終層を取得したい場合は-1を渡します。これはデフォルトでもあるので、コメントアウトしても構いません。ただし、ここを変えることもできます。たとえば中間層を複数取りたい場合は、-4も追加するといった指定が可能です。これにはバックボーンのアーキテクチャの知識が少し必要です。今回のTerraMind smallの場合、Transformer層は12層なので、12層から抽出できます。範囲外のインデックスを指定しても問題なく、その分は埋め込みが得られないだけです。たとえば36を渡しても、12層のTransformerの範囲外なので無視されます。負の数でも絶対値でも指定でき、2, 4, 12のように指定して中間の2層と最終層を取得することもできます。
そしてembedding_poolingをnoneに設定します。これによって、密なパッチ埋め込みが得られます。出力情報を実行すると、適切な重みがロードされたことや、GeoTIFFを選択したため、自動的に重要なステップとしてパッチ埋め込みが空間グリッドにリシェイプされるという情報が表示されます。つまり、GeoTIFFに保存される空間的なパッチ埋め込みが得られます。
5.4 モデル出力形状の診断と埋め込み生成の実行
Isabelle： 実際に埋め込み生成をキックオフする前に、出力フォーマットを少し検査することもできます。これは診断目的なので通常は不要です。何をしているかというと、データローダから最初のバッチを取得し、初期化したタスクを通して実行します。先ほどタスクで行ったのは、本質的にはバックボーンとreshape neckをつないでモデルを構築することでした。これは基本的にモデリングパイプラインです。画像をパイプラインに入力し、モデルを通して実行すると、出力が得られます。これは埋め込み生成タスクが実際に保存するものでもあります。
今回のケースでは、バッチサイズが4なので、6バンド・512×512ピクセルの画像4枚を入力すると、空間的にリシェイプされたパッチ埋め込みが得られます。具体的には、16×16ピクセルのパッチを使うため32×32の空間グリッドが得られ、Transformer次元は今回smallモデルなので384、これが埋め込みの次元になります。
これを確認した上で、実際の生成を開始します。事前の検査ステップは必須ではなく、データモジュールとモデルを渡してTrainerのpredictステップを実行するだけで、埋め込みが生成・保存されます。右側を見て期待通りに動作しているか確認しましょう。出力フォルダとしてembeddingsを指定したので、その下にTerraMindのサブフォルダがあり、レイヤーを1つ指定したので最終層に対応するlayer 0の出力があります。configファイルもあり、これが何を意味するか正確に教えてくれます。今回の場合、layer 0フォルダは最終層の埋め込み、つまり-1を指定したため、12層目のTransformer層の埋め込みです。ここに追加情報があるので、後で戻ってきたときに、このフォルダの埋め込みが何を表しているかを正確に把握できます。
5.5 異なるバックボーン（Prithvi Tiny、ResNet DINO）への切り替えとPCA可視化比較
Isabelle： 時間の関係でノートブックの残りは少し駆け足で進めます。次に行うのは、もう2つのバックボーンでの再実行です。今はTerraMind smallですが、別のバックボーンからの埋め込みと比較したいので、次はPrithvi tinyを使います。変更が必要なのは2点だけです。まず正規化統計量です。データモジュールをPrithvi訓練時に使われた正規化統計量で更新します。次にモデル引数を変えます。バックボーンの識別子としてPrithvi tinyの名前を使い、pretrained=Trueを維持します。Prithviはモデルが入力画像サイズも知る必要があるので512を指定し、6つのHLSバンドであることを伝え、出力フォルダ名を変更します。これだけで再実行できます。右側を見ると、Prithvi埋め込み用の出力フォルダが新たに生成され、GeoTIFF出力なので入力画像ごとに個別のTIFFファイルが得られます。
さらにもう1回、ResNet DINOバックボーンでも実行します。こちらは正規化された入力を期待せず、スケーリングのみで済むため、デフォルト値を渡して正規化をスキップし、ResNetバックボーンに対しては事前学習済みのSSL（Self-Supervised Learning）を使って埋め込みを取得します。これでResNetの埋め込みも生成されます。
これらが揃ったところで、埋め込みを読み込み、PCAプロットで比較します。プロット用のコードは少し長く見えますが、見やすい出力を出すためのもので、詳細はあとでご確認いただけます。確認してみると、出力形状の説明とまさに同じものが見えてきます。得られているのは密なパッチ埋め込みです。入力解像度と比較して粗くなっており、16×16の入力パッチを1つの埋め込みに要約するためです。これが解像度が異なる理由です。CNNバックボーンの場合は、さらに粗い解像度になっています。
PCAマップについて、TerraMind smallの場合は384次元の埋め込みなので、その上に3次元のPCAを計算しています。たとえば焼け跡の例を見ると、すべての埋め込みがこれを捉えていることが、視覚的にもよくわかります。形は異なるものの、いずれの埋め込みでも、入力中の異常な領域が表現されています。これこそが、ダウンストリームのワークフローで活用される性質そのものなのです。
6. TerraTorchデモ：埋め込みを用いたダウンストリームタスク
6.1 埋め込み入力データモジュールの構築とSegmentation Task設定
Isabelle： それでは、このノートブックを閉じてダウンストリームタスクへ移っていきます。その前に、急ぎの質問がないか確認したいと思います。
Rohini： 急ぎの質問は見当たりません。Isabelleさん、このパートを締めくくる前に、全体の主なステップを簡単にまとめていただけますでしょうか。
Isabelle： もちろんです。良いポイントですね。要点を整理しますと、まず手元のデータに合わせてデータモジュールを設定するという点です。すでにあるTerraTorchの例を確認して、ご自身のデータがすでに設定済みかどうか、あるいはどう設定するのがベストかをチェックしてください。これは単なるデータローダの設定です。これが済めば準備完了で、あとは試行錯誤を始められます。二つ目のステップは、埋め込み生成タスクを使うことです。設定をいろいろ変えてみるだけで埋め込みが得られます。要点はこの2点に集約されます。
Maria： ありがとうございます。ところで、Yan Sommerさんから一つ質問が来ています。「埋め込みの結果ピクセルサイズを何らかの方法で変更できるのでしょうか。それとも使用するモデルに紐づくものですか」とのことです。
Isabelle： 使用するモデルに紐づきます。ただし、変更といっても粗くする方向であれば可能です。空間方向の集約として、空間的なmean埋め込みを取るといったことができ、入力画像全体に対して1つの埋め込みを得るような形になります。まだ統合されていない機能としては、中間的な選択肢があります。つまり、デフォルトでより粗いダウンサンプリングを行うようなものです。必要であればissueを立てていただければ対応可能です。逆により高い解像度に上げることは難しく、なぜなら、埋め込みからより高解像度の埋め込みへとどう移行するかを何らかの形で定義しなければならないからです。ダウンサンプリングは可能ですし、より柔軟な仕組みを取り込むことも歓迎します。アップサンプリングはモデリング上の決定が必要となるため、簡単ではありません。
Maria： ありがとうございます。Cinnamon Tazariさんからもコメントが届いていますね。「ノートブックについて、Jupyterカーネルを作成した仮想環境に変更する必要があるかもしれません。カーネルがPython 3として表示されており、必要なパッケージがそこにインストールされていない可能性があります」とのことです。
Isabelle： ありがとうございます。最初に起きた問題の解決に大変助かりました。そう、これはまさに最初に私が直面した問題に対するコメントですね。今はすでに解消されています。本当にありがとうございました。
Maria： ありがとうございます。他に質問は見当たりませんので、先へ進んでいただいて大丈夫です。
Isabelle： いい流れですね。それではここでもカーネルを再度切り替えておきます。ダウンストリームタスクのワークフローについて、簡単にお見せします。今日はすべてのステップを丁寧に追う時間はありませんが、Mariaさんが触れてくださったように、次回のTerraTorchチュートリアルが、調整・適応可能な部分をさらに深く掘り下げる絶好の機会になります。ここで主に持ち帰っていただきたいメッセージは、埋め込みが手元にあれば、これまでと非常に似たことができるということ、そしてTerraTorchを使ってさまざまな種類のデコーダーを構築できるということです。これは本質的にツールボックスとして使えるもので、コードをたくさん書く必要はなく、設定を変えるだけで済みます。たとえば、デコーダー層を何層にするか、どの種類の損失関数を使うか、埋め込みの上にどの種類のデコーディングを行うかといったことを試せます。これらをパイプライン全体をゼロから書かずに、できるだけ効率的に行えるようにするのが目的です。
具体的な手順をお見せします。冒頭で必要なデータが揃っているかチェックをしています。基本的に先ほどとよく似ていて、データモジュールを初期化するところから始めます。ただし今回は生データではなく、埋め込みをロードするデータモジュールです。埋め込みのパスや、データに付与されている埋め込みのサフィックスを渡します。さらに訓練用には、ランダムフリップやローテーション変換、デフォルトのto-torchデータ型変換などを設定できます。残りは他のデータモジュールと同様に標準的な設定項目です。
簡単なプロットを再度確認できます。今回は埋め込みを読み込んでいるので、入力プロットも埋め込みのPCAになります。マスクは変わっておらず、生データのときと同様にラベルマスクを使います。これはHLS Burn Scarsを生データのワークフローで使う場合と同じ扱いです。
次にセグメンテーションタスクを設定します。今回はデコーダーパイプラインを構築し、セグメンテーション出力を生成するように学習させます。非埋め込みワークフローとの違いは、事前学習済みの基盤モデルバックボーンの代わりに、Identity Backboneを渡すことだけです。それに加えて、埋め込みを扱っていることをパイプラインに知らせるためのフラグと、マスクの元の出力サイズに関する設定を2つ与えます。その他は標準的な設定です。デコーダーの設定では、デコーダーのサイズを指定し、デコーダーが最初に受け取る次元として、埋め込み次元である384を伝える必要があります。あとは学習率、オプティマイザ、損失関数を設定します。これらの設定の詳細については、タスクごとの種類、たとえば分類タスクなのかセグメンテーションタスクなのかに応じて、TerraTorch上の詳しいノートブックを参照していただくのが良いと思います。
6.2 PyTorch Trainerによる学習実行とパイプラインの再利用性
Isabelle： それでは実行してみましょう。TerraTorchは学習コンポーネントとしてPyTorchのものをすべて活用しています。したがって、通常のPyTorch Trainerを設定するだけで、実際の学習・ロギング・関連機能をすべて代行してくれます。これによって、学習ループを自分で書く複雑さがすべて取り除かれます。
学習の準備ができたら、ここではサブセットが非常に小さいため、デモ目的としていくつかのエポックを設定します。24サンプルしかないので、実際の勾配ステップ数は多くなく、これは純粋にパイプラインに慣れるための実行です。今回はバリデーションステップもスキップして、より軽量にしています。バリデーションデータセットが訓練データセットと同じだからです。trainer.fitを呼ぶだけで訓練が始まります。今すでに20エポック中の3エポック目に入っています。少し時間をかけて進めますが、訓練が終われば結果をお見せできます。
ここに見えているのは実は未学習のモデルの結果です。少し待っている間に説明しますと、testを呼び出すことで、データモジュールのテストデータセットを用いて性能を直接評価でき、後で出力を確認することもできます。時間の都合上、ここでデモは締めくくりますが、皆さんはこのまま続けて、ご自身で結果を分析していただけます。
それでは、いったんここで止めてプレゼンテーションに戻ります。これでTerraTorchデモのまとめに入ります。改めてのテイクアウェイメッセージとして、埋め込み生成には埋め込み生成タスクを使い、これはTerraTorchで使ったことのある他のセグメンテーションタスクとプラグアンドプレイで連携します。つまり、同じデータモジュールや設定をそのまま使えるということです。そして埋め込みが手元にあれば、セグメンテーションタスクや分類タスクなど他のタスクをそのまま使って、埋め込みを読み込みデコーダーを構築できます。この流れこそが、本パートのデモを通じてお伝えしたかった再利用性の核心です。
7. 質疑応答1：圧縮トレードオフ・ハイパースペクトル・解像度
7.1 デコーダー縮小による推論速度と意味情報保持のトレードオフ
Maria： デモ環境の再起動を待つ間、いくつか質問を扱いましょう。Rohiniさんがすでに質問をお持ちのようですが、なければ私から一つ一般的なものをお聞きします。要点をまとめますと、埋め込みによってデコーダーが最大100倍小さくなるという話がありました。実務的な観点で、この削減は推論速度と、保持される意味情報の豊かさとのトレードオフにどのように影響しますか。特に、サブシーズナルな変化検出のような複雑なタスクではどうでしょうか。これは一般的な質問で、今お見せいただいていた内容に直接結びつくものではありません。
Isabelle： とても良い質問ですね。正直に申し上げると、私たちはまさにこのトレードオフをよりよく理解し始めたばかりというところです。現状わかっていることとして、トレードオフは確かに存在します。たとえば先ほどお見せしたタイプのセグメンテーションタスクのいくつかでは、性能の低下が観察されました。そして他のタイプのタスクにも同じことが当てはまるはずだと考えています。特に、パッチ埋め込みがそのタスクにどれほど適しているか事前に十分に把握できていない場合は、その分の情報を失ってしまう可能性があるからです。
ですので、これは今後さらに研究を進めて、より深く理解していくべき領域だと考えています。ただ確実に言えるのは、トレードオフは存在するということです。万能の解決策ではありませんし、もし非常に正確な細部にこだわる必要があるのであれば、生データに立ち戻る方が常に良い選択になることもあり得ます。一方で、埋め込みワークフローはむしろ、すでに性能が飽和しているタスクや、既に良い性能が見えているタスクで、処理を高速化し、シンプルにするためのものといえるでしょう。
7.2 ハイパースペクトル画像への適用と埋め込み解像度の可変性
Maria： ありがとうございます。Rohiniさん、何か質問は集まっていますか。
Rohini： 今のところ質問は来ていません。
Maria： では私から短くもう一つお聞きします。今お話を伺っていると、Sentinel-1、Sentinel-2のデータについて議論していますが、ハイパースペクトルデータはまだ扱っていないという理解で正しいですか。それともハイパースペクトル画像も使われていますか。
Isabelle： 私自身、ハイパースペクトル埋め込みにはまだあまり取り組んでいません。これはトレードオフというよりも、バックボーン次第という側面が強いです。ハイパースペクトルデータをエンコードするバックボーンがあれば、それがどの程度うまく機能するかを理解するのは非常に興味深いと思います。ただ個人的には、これまでSentinel-1とSentinel-2のデータのエンコーディングを中心に作業してきました。
Maria： わかりました。Rohiniさん、もう一つ質問はありますか。なければ次のパートに進めます。
Rohini： 申し訳ありません、少し接続の問題がありました。戻ってきていますが、進めていただいて大丈夫です。最後にまた質問の時間を取れればと思います。
Isabelle： 大変ありがとうございます。少し休止をいただいたうえで再開させていただきます。皆さんに簡単にお伝えしておきたいのは、似たようなトラブルに遭遇された方への対処方法です。先ほど私がやっていたのは、setupファイルに戻ってカーネルを登録するという操作でした。Jupyter notebookで仮想環境が認識されないという、カーネル側の問題が発生することがあります。これを行うとすぐに解消し、登録されたカーネルが上部に表示されるようになります。同様の問題が起きた方はsetupに戻って同じ手順を試してみてください。
Isabelle： ここで、TerraTorchデモを締めくくる前に、ノートブックの主なステップを改めて整理させてください。一つ目はデータモジュールの設定で、これはご自身のデータローダとして使えるよう設定するだけです。すでに似たデータ用のデータモジュールがあれば、それを埋め込み生成にもそのまま使えます。二つ目は埋め込み生成タスクで、設定をいじることで埋め込みが得られます。要点はこの2点だけです。
Maria： Yan Sommerさんから一つ質問が来ています。「埋め込みのピクセルサイズは、なんらかの方法で変更できるのでしょうか、それとも使用するモデルに紐づくものですか」とのことです。
Isabelle： 使用するモデルに紐づきます。ただし、より粗くする方向であれば変更可能です。空間方向の集約として、空間的なmean埋め込みを使えば、入力画像全体に対して1つの埋め込みを得られます。今は統合されていませんが、要望があればissueを立てていただければと思います。中間的なオプション、つまりデフォルトでより粗いダウンサンプリングを得るような選択肢の追加です。逆により高い解像度に上げることはできません。これは、埋め込みからより高解像度の埋め込みへとどう移行するかを何らかの形で定義しなければならないためです。ダウンサンプリングは可能ですし、より柔軟な仕組みを取り込むことも歓迎します。アップサンプリングはモデリング上の決定が必要なため、容易ではありません。
8. NeuCobenchの設計とタスク群
8.1 NeuCobenchの設計思想と線形プロービングによる軽量評価
Isabelle： それでは次のパートへ移ります。ここまで埋め込みワークフローについて、生成からデコーディングまでをかなり詳しく見てきましたが、研究上もっとエキサイティングなのは品質をどう判断するかという点だと考えています。つまり、埋め込みを実際にどうベンチマークすべきかという問いです。これに取り組むために、私たちはNeuCoBenchという、埋め込みのための非常に軽量なベンチマーキング基盤を開発してきました。
パイプライン全体をお見せしますが、設計思想として完全にモデル非依存（model agnostic）にすることを目指しました。実はNeuCoBenchの動機は、むしろ圧縮の観点から始まっています。私たちはもともと、EOデータの圧縮や圧縮モデルにも踏み込みたいと考えていました。ニューラル圧縮器を使うことも、GeoFMエンコーダーを使うことも、非学習ベースの手法を使うこともできます。手法は問いません。本質的に必要なのは入力データのコンパクトなエンコーディングだけで、その時点からNeuCoBenchが介入し、評価を開始します。
固定サイズの埋め込みが与えられると、NeuCoBenchはその上で一連のタスクを線形プロービング（linear probing）の構成で実行します。これは非常に軽量な仕組みで、CPUのみでローカル実行することも可能ですし、リソースもあまり消費しません。たとえば訓練のセットアップやハイパーパラメータ最適化のセットアップに組み込むといった使い方もできます。
現在のタスクセットは画像全体に対するタスクで構成されています。入力データキューブに対して、データキューブごとのラベルや回帰ターゲットがあるという形式で、現状は主に回帰タスクとなっています。具体的なターゲットタスクとしては、特定の土地被覆率、雲被覆、画像中の平均バイオマスなどです。そして多数の分割（splits）にわたって線形プローブを実行し、タスクごとの性能を判断できる仕組みになっています。
具体例で全体像を示しますと、TerraMindの埋め込みを使う場合、まずTerraMindをマルチテンポラルかつマルチモーダルな入力データに対して走らせ、小さな埋め込みを得ます。そしてその埋め込みから、各種タスクに対してどれだけの情報が直接アクセス可能かをチェックします。これによって、たとえばあるタスクは比較的容易で素直に解けるが、別のタスクはより難しい、ということが見えてきます。
そして、これを使ってできる非常にクールなことの一つが、昨年私たちが実施したような、チャレンジモードでの運用です。本質的には、ユーザーに埋め込みを提出してもらうだけでチャレンジを成立させられます。フルファインチューニングのベンチマーキングに伴う重い処理をすべて取り除き、参加者はコンパクトな埋め込みを提出するだけ、こちらはタスク上で数分程度で実行する、という非常に軽量な形式で運営できます。これが初の埋め込み中心のチャレンジ形式となり、大変な成功を収めました。多くのチームが参加してくださり、彼らが考え出したさまざまな手法を見ることができたのは本当に素晴らしい経験でした。
8.2 評価対象タスク群と難易度の差異
Isabelle： より理解を深めていただくために、チャレンジでもサポートしていたオリジナルのデータタスクについてお話しします。これらは主に5つの基盤データセットに基づいており、そこからさまざまなダウンストリームタスクを構築しています。たとえば土地被覆タスクは2種類あり、一つは森林被覆に関するもの、もう一つは農業被覆に関するものです。雲タスクは最も時間的な性格が強いタスクで、4つの時刻ステップを用います。ここで予測したいのは平均雲被覆です。したがって埋め込みは、本質的に各画像時点での雲被覆を理解した上で、時間方向にうまく要約していなければなりません。
そしてバイオマスタスクですが、これはやや難易度が高めです。理由としては、ラベルが一般的に疎であり、ノイズも大きい点が挙げられます。ここでは平均バイオマスを予測します。
8.3 評価指標（R²・F1・Signal-to-Noise品質スコア）とベストプラクティス
Isabelle： 結果に踏み込む前に、スコアの定義について少し時間を取って整理させてください。NeuCoBenchの評価や出力を見るときに、皆さんと同じ前提に立てるようにしておきたいからです。
一歩引いて見ますと、評価したい入力データの埋め込みが手元にある状態から始まります。これを各タスクに分割します。たとえば土地被覆タスクに関連する全ての埋め込みを取り出し、利用可能な全ラベルを使って、ランダムな訓練・テスト分割を繰り返し、訓練分割上で学習し、ホールドアウトのテスト分割上で性能を評価します。
分類タスクか回帰タスクかに応じて、R²スコアやF1スコアを使います。これを多数の分割（fold）にわたって行うことで、安定した測定値を得て、入力信号がタスクに対して埋め込みからどの程度活用できるかを評価できます。
タスク全体を横断する集約スコアとしては、精度（accuracy）と品質（quality）という2つの指標を見ています。精度は、扱った全タスクおよび各タスクで切った全分割における、テスト分割上の平均精度です。たとえばR²の意味での平均精度になります。これに加えて、性能の頑健性を測るため、シグナル・トゥ・ノイズの品質スコアを使います。これは同じく基礎となる精度スコアを使うのですが、スコアの変動に対するシグナル・トゥ・ノイズの形で構成しています。本質的には、低い分散で安定して高いスコアを達成する手法を高く評価し、ときどき高いスコアを出すが分散が大きい、あるいは一貫性がない手法にはペナルティを与えます。これを0〜100%として読めるスケールに調整しています。
手法を比較するとき、あるいはNeuCoBenchをチャレンジ形式で運用するときに、比較可能性を担保するために採用しているベストプラクティスがいくつかあります。まず、埋め込みサイズの上限を固定します。チャレンジでは1024を上限とし、すべての埋め込みはそのサイズ以下とすること、もしそれより小さい場合は1024までパディングして、比較可能な埋め込みサイズの構成にすることを定めました。クロスバリデーション分割やエポック数も固定します。
ランキングは品質スコアに基づきますが、チャレンジ向けに追加で「タスク難易度の重みづけ」も導入しています。スコアを、そのタスクがどれほど識別力があるか、すなわちどれほど結果のばらつきを生み出すかに応じてスケールあるいは重みづけします。識別力が高いタスクほど高い重みを与え、横断的に見て一般的に難しい、あるいは手法間の差異が小さく洞察を生みづらいタスクの重みを下げます。出力テーブルには両方の指標が含まれるため、純粋なmean qualityとそのランキングだけを見るか、タスク難易度重みづけを併用するかを選択できます。
8.4 チャレンジモードの運用とベースライン結果から得られた知見
Isabelle： ベースラインで観察された結果を簡単にご紹介します。全体として非常に大きなばらつきが見られます。集約された埋め込みの興味深い点として、いくつかの埋め込みはかなり苦戦する一方で、より新しく高度なGeoFMはそれらに対してより高いスコアを出します。これは私たちの直感にも合致します。
ここで一点注意していただきたいのが、たとえば時間的なタスクについて、現時点ではすべて時間ステップに対するmean poolingにとどまっているということです。したがって、より高度な時間的集約戦略を探究する余地が残されています。
平均性能からタスク単位の結果に踏み込むと、たとえば右側の土地被覆タスクははるかにずっと容易であることがわかります。多くのモデルがこの種のセマンティックなタスクで高いスコアを出します。一方、すでに申し上げた通りバイオマスは、どのエンコーディング手法にとっても格段に難しいタスクです。
すべてオープンソース化されています。NeuCoBenchのGitHubリポジトリでどのように作業を進めるかは、すぐ後にご紹介します。これを使ってローカルで実行できますし、基礎となるデータセットもダウンロードしてご自身の手法をエンコードし、その上でテストできるよう公開されています。
9. NeuCobenchデモと統合エンドツーエンドワークフロー
9.1 NeuCobench実行と出力分析
Isabelle： それでは概要に戻ります。フルスクリーンモードに切り替えて、ここからはNeuCoBenchの評価実行を見ていきます。チュートリアルの構成上、Part 2のNo Code NeuCoBench Benchmarkingに進んでいただくと、必要なスクリプトがworkflows配下にあらかじめ用意されています。リポジトリには、要求される形式の埋め込みが入ったサンプルファイルも一つ含めてあります。これはdata/neucobench-embeddings/terramind配下に置いてあります。評価対象としたい全データに対して自分で埋め込みをエンコードする必要を省くためで、というのも対象は1万サンプル以上になるからです。あらかじめTerraMind tinyで全データをエンコード済みのファイルを用意しておいたので、それを使ってNeuCoBench評価を実際に実行する手順を試せます。
ご覧いただいているのが、私たちがクローンしたNeuCoBenchリポジトリです。現時点ではまだパッケージ化されていないため、本日のようにクローンして直接扱う使い方が前提となります。必要なコードはすべてbenchmark配下にあり、実行方法や設定方法に関する情報はREADMEに詳しく記載されています。本日は時間の都合上、すでにworkflows配下にスクリプトを用意しておきました。
実行に必要な指定はシンプルで、まず必要なデータへのパスを与えるだけです。冒頭の準備段階でラベルはすでにダウンロード済みです。先ほどお見せした評価対象の埋め込み、つまりTerraMind tinyの埋め込みファイルを指定し、出力ディレクトリと手法名を渡します。そしてconfigファイル内で、先ほどご紹介した全ハイパーパラメータを設定します。バッチサイズ、エポック数、対象タスクの種類などが定義されたconfigを使います。本日はさらに軽量にするため、タスクのサブセットを使う構成にしています。
実行の準備が整ったところで、初回のみファイルを実行可能にする必要があります。その後にNeuCoBenchスクリプトを実行します。出力を見ると、各タスクのターゲットラベルをロードしていることがわかります。埋め込みファイルからの読み込みも行われ、その下ではすでにベンチマーキングが開始されています。タスクごとに、設定したランダム分割を実行します。今回の構成では40分割（または50分割）で評価を回します。線形プロービングが非常に軽量であるため、極めて高速に進行することが確認できます。
出力フォルダが生成され、今回のケースでは指定したパスに作られます。このフォルダに入って、観測された性能を理解し、さらに掘り下げて確認できます。たとえば最初のbiomassタスクに入ると、サマライズされた性能スコアが見えます。具体的にはmean R²、R²の標準偏差、そしてシグナル・トゥ・ノイズの品質スコアです。さらに深く理解できるよう、可視化された出力もあります。4分割や40分割にわたるtrainとvalidationの曲線も得られ、訓練がどの程度安定していたかを確認できます。
さらに踏み込んで、もし性能が良くなかった理由を理解したい場合には、散布図まで確認できます。後ほどテスト対象すべての手法に対してこれらの出力を望まないのであれば、無効化することも可能です。先ほどの実行を見るとベンチマーキングはすでに完了しており、全タスクの実行が終わるとサマリーファイルが生成されます。サマリーファイルは、本質的に各タスクのスコアと平均スコアをまとめたもので、これが今回テストした全タスクにわたるmean R²に相当します。これは先ほどお見せしたバーチャート、つまり平均性能を取得しているチャートと対応しています。
これで、NeuCoBenchの使い方と結果の読み解き方の最初のステップを一通りご覧いただいたことになります。
9.2 TerraTorchとNeuCobenchの統合ワークフロー設計
Isabelle： 残り時間は10〜15分ほどなので、最後のパート、すなわちエンドツーエンドのワークフロー部分を駆け足でご紹介します。こちらは少し重い処理を伴うため、皆さんがライブで一緒に追いかけることを意図したものではありません。
そもそもライブで進めにくい理由は、最初に大きめのデータダウンロードが伴うからです。エンドツーエンドのワークフローでは、まず根底となるNeuCoBenchデータセットをダウンロードしなければなりません。エンコードするためには生の画像が手元に必要だからです。たとえば一つのモダリティで約50GBの規模になります。ダウンロード用のスクリプトはここに用意してあります。
手順としては、まずsetupに戻り、ラベルをダウンロードしたときと同じ要領で、生の画像ファイルもダウンロードします。これがローカル（あるいはクラスタ）に揃ったら、これまで使ってきたTerraTorchパイプラインを用いて埋め込みを構築します。これまでの手順とほぼ同じで、唯一の違いは出力タイプの切り替えです。NeuCoBench互換の出力タイプを指定する必要があります。NeuCoBench互換とは、NeuCoBench側が期待する例のCSV形式の出力ファイルになるという意味です。
必要な変更は、出力フォーマットのフラグを切り替えることだけです。新たにNeuCSSという出力フォーマットを指定します。ここ以外は、これまで行ってきた手順と完全に同一です。上の部分では、NeuCoBenchデータセット向けにデータモジュールを設定する例を示しています。こちらも非常によく似ています。マルチモーダルなデータセットなのでマルチモーダル用データモジュールを使い、サブディレクトリ構造になっているためその扱いに対応する補助機能を利用します。HLS Burn Scarsのデータモジュールで行ったのと同じ流れで、データを読み込みます。
その上で、サンプルノートブックではmean poolingの代わりにmax poolingを行っています。つまり、空間方向に全パッチ埋め込みの平均を取る代わりに、空間方向に最大値を取る場合に、性能がどう変わるかを比較できます。出力フォーマットの切り替えだけで、TerraTorch側の埋め込み生成パイプラインがそのままNeuCoBench評価へとつながる、という統合設計の利点が、この比較実験からも見て取れます。
9.3 Earth To Coalitionコミュニティの紹介と参加方法
Isabelle： スライドに戻って、まとめに入っていきたいと思います。質問の時間も十分に確保したいので、その前にもう一点お伝えしたいことがあります。埋め込みに取り組んでいる方、あるいは関心をお持ちの方は、ぜひ会話の輪に加わっていただき、新しい手法を一緒に試していけたら大変嬉しいです。そのために私たちが立ち上げたのが、Earth To Coalitionというコミュニティです。この分野で活動しているプレーヤーをつなぐコミュニティで、月例のコミュニティミーティングを開催しています。たとえば次回は今週金曜日です。フォーカストピックはTesseraで、ここでつながっていただくのが趣旨です。
Earth Toから生まれた取り組みの中には、より大規模なコミュニティイベントもあります。たとえば「埋め込みフォーマットに関するスプリント」のように、埋め込みを扱う上でのコミュニティ全体としての標準――フォーマットや必要なメタデータなど――を議論する場を設けています。
Maria： 失礼ですが、Isabelleさん、前のスライドに戻っていただけますか。このコミュニティに参加するにあたって何が必要でしょうか。登録のみで参加可能なのか、それとも参加可否を判断するための費用が必要なのか、皆さんが確認できるようご説明いただきたいのです。
Isabelle： はい、費用は一切かからず、完全に無料です。非常にオープンで、コミュニティが形づくっていくイニシアチブです。参加方法としては、GitHubページにアクセスしていただくと、Discordへのリンクが掲載されています。Discordコミュニティに参加していただければ、そこでミーティングの招待やその他の情報を共有しています。今週金曜日のリンクもDiscordで共有されます。Teamsリンクで開催されます。Discord上で私たちとつながっていただき、もしより積極的に関わりたい場合や、イベントのアイデアがある場合、あるいはスピーカーとして登壇したい・登壇できる方をご存じの場合も、ぜひお知らせください。コミュニティイベントに関するそうしたお話はすべてDiscordで進められます。
Maria： ありがとうございます。私がこのことを伺ったのは、私たちが開催しているウェビナーには若い方々も多く参加されているからです。研究者の方、博士課程の学生、修士課程の学生など、こうしたコミュニティに触れる機会として活用していただけるのではないかと思いました。皆さんにとって、非常に興味深い経験になるはずです。
Isabelle： はい、まったくその通りです。経験のレベルや、産業界・アカデミア、あるいは余暇でこのトピックに関心を寄せている方など、誰でも歓迎されます。どんな立場の方でも参加できます。
Maria： ありがとうございます。
Isabelle： こちらこそ、ご質問ありがとうございます。
10. 質疑応答2：埋め込み空間の構造と方法論的考察
10.1 複数ROI埋め込みの統合可能性とオーバーラップ領域の取り扱い
Maria： Isabelleさん、ここで関連する質問を一つ伺ってもよろしいですか。私の博士課程の学生であるGolaniさんからの質問です。「関心領域（ROI）が1つではなく50〜60個あって、それぞれの領域について個別に埋め込みを計算し、ROIごとに別個の埋め込みが得られたとします。これらの埋め込みを、効果的に一つの統一的な表現として再構成するにはどうすればよいでしょうか」とのことです。
Isabelle： これは潜在空間の構造に関する質問だと理解しました。つまり、それらの埋め込みが共通の潜在空間を共有しているのか、たとえば同じデコーダーで再利用できるのか、ある領域で訓練したデコーダーで、世界の別の場所から得られた埋め込みも処理できるのか、という問いかと思います。
これはエンコーディング手法に完全に依存します。冒頭で見た分類体系にも関わる話です。グローバルな空間的整合性を提供しようというのは、まさに埋め込みフィールド（embedding fields）の目標の一つです。そして事前学習の設定によっては、特定のGeoFMの方が他よりもこれに向いている場合があります。たとえば、大量のデータで訓練され、マルチモーダルなアラインメントを取った高度な基盤モデルは、一般的にこの点に強い傾向があります。一方、より浅い手法では、グローバルな空間的整合性を共有しない場合があります。
Maria： わかりました。私からもう一つ、関連する質問をさせてください。隣り合った2つの関心領域があり、それぞれの周囲にバッファを設けてオーバーラップを作ったとします。そのとき、埋め込み生成において何が起きるのでしょうか。重なっている領域では、まったく同じ埋め込みが得られるのか、それとも異なるのか、そしてもし異なるのであれば、その差をどう扱えばよいのでしょうか。
Isabelle： 非常に良いポイントです。デフォルトではまったく同じ埋め込みは得られません。これは実は、予測マスクで起こることと同じ状況です。仮にオーバーラップしたパッチ上でデコーダーを訓練したとしても、同じラベル予測は得られません。予測は空間的なコンテキストにも依存するからです。埋め込みについてもまったく同じことが言えます。たとえばTransformerアーキテクチャでは、同じ埋め込みは得られません。
これをどう扱うかは、何をしたいかによります。たとえば埋め込みレイヤーを構築したいのであれば、おそらくこれを手動で平滑化する必要があります。たとえばオーバーラップ部分で平均を取るとか、別の処理方法を見つけるといった形です。一方で、本日多くの時間を割いて見てきた「画像→埋め込み→ラベル」という構成では、その問題はそれほど大きくなりません。なぜなら、その入力画像に対して得られた埋め込みをそのまま使うからです。しかし埋め込みフィールドを構築したい場合には、こうした問いに正面から向き合い、決定を下さなければなりません。
Maria： その通りですね。ありがとうございます。
Isabelle： こちらこそ。
10.2 ノイズ正規化・透明性・ハードウェア要件についての考察
Rohini： 視聴者の方から質問を一ついただきましたので、私からお伝えします。「衛星画像のノイズが存在する場合、正規化のステップで平均値（mean）ではなく中央値（median）を用いた方がよいでしょうか」というかなり具体的な質問です。
Isabelle： とても良いポイントです。正直に申し上げますと、現状ではmedianはまだ統合されていません。これは追加できる素晴らしい機能ですね。私個人としては、それほど重要ではないと考えています。なぜなら、バックボーンを通る処理の段階で、ノイズはすでにかなりうまく扱われているからです。予期しないピクセル値が何であるかを理解するレイヤーがバックボーン側にすでに存在し、ノイズが何かを識別して、それを潜在空間がうまく構造化される形で扱ってくれます。これが、私たちが既定としてmean埋め込みを多用している理由でもあります。
Rohini： 興味深いですね。ここで私からも一つ伺います。埋め込みベースのワークフローは、可能性が非常に高い一方で、人に説明したり翻訳したりするのが結構難しいテーマです。特に技術者ではない方、たとえば政策決定者や意思決定者に対して、結果がなぜこうなるのか、結果にどのような限界やギャップがあるのかを説明しなければならない場面で、不確実性をどう伝えるとよいでしょうか。それを伝える機能はモデル側に組み込まれているのでしょうか。
Isabelle： 非常に良いご指摘です。重要な点に触れていただいたと思います。すべてにおいてトレードオフがあるからです。ユースケースによっては、製品に投入されたデータが何であるかを正確に知ることをより重視する場合もあるでしょう。だからこそ、自分が完全にコントロールでき、生データも完全に把握できる埋め込みから実験を始める方が適している場合があります。一方で、私自身は、その利点は多くの場合、理解の一部が失われることを上回ると考えています。多くのユースケースでは、上に何かを簡単に積み上げられるという利点だけで、十分に魅力的だからです。あとは、性能と信頼性の指標を使って、そこから何を引き出せるのかを理解する作業の問題になります。
ですから、事前計算された埋め込みの上にタスクを構築でき、ホールドアウトデータセットでタスクをどの程度うまく解いているかを信頼性をもって判断できるのであれば、多くのタスクではそれですでに良い適合といえます。ただし、クリティカルな環境にいる場合や、透明性をより重視する場合には、内側に戻って中身を見る必要があります。「自分の埋め込みに何が入ったのか」「何ができて、もしかすると何ができないのか」を確認する、ということです。これは興味深く、また会話が必要な領域でもあると感じています。どう伝えるか、どこまで透明にできるか、ということについてです。人々が「これは単なるブラックボックスだ」と感じるのではなく、自分の用途に使えるかどうかを理解できるようにする必要があります。
Rohini： Mariaさん、何か質問はありますか。
Maria： もう一つあります。とても実務的な質問です。要約しますと、本ワークショップの対象がローカルのノートパソコンやGoogle Colabを使う参加者であることを踏まえると、高解像度のグローバルデータセットに対してTerraTorchを用いた完全なダウンストリームワークフローを実行するための最低限のハードウェア要件は何になりますか。
Isabelle： 高解像度のグローバル、というのはもちろん非常に重い処理です。これは、簡単には、あるいはローカルでは実行できないことが多いです。本日は小規模なサンプル数を扱っており、その範囲であればローカルでもうまく扱えます。視点として補足しますと、新しいワークフローでは13K程度の画像、つまり小さなエリアの時刻ステップに対するデータキューブを扱います。これは少し試してみる程度なら可能で、ローカルノートパソコンのディスク容量との兼ね合いで、もう少し時間がかかり始める境界に近づいていきます。それより規模が大きくなる場合は、クラスタやより整備されたパイプラインを使うことになると思います。
ただ、それでもグローバルなタスクは計算量・データ量の両面で非常に重いです。ですから、そうしたワークフローでは、事前計算された埋め込みを利用するのが望ましいでしょう。グローバルなマップとして持つにしてもそれ自体がかなり重いものになりますが、まずはそれを使って試してみることができます。
10.3 事前計算埋め込み対オンデマンド生成の将来需要と小規模ラベル下のファインチューニング戦略
Maria： ありがとうございます。視聴者のRobin Coleさんから次の質問をいただいています。「事前計算された埋め込みに対する需要があると思われますか。それともオンデマンドで生成される方が現実的でしょうか」とのことです。
Isabelle： 個人的には、まだ完全には決めかねています。事前計算された埋め込みには間違いなく非常に重要な居場所があると思います。多くのタスクで、現時点ですでにかなりうまく機能していることが見えており、これはさらに推し進められていくでしょう。さまざまな埋め込みプロダクトが登場し、より集約された、より軽量なものや、多くのタスクですでに見られているような10メートル解像度の提供などが続くと思います。
その一方で、「異なる時刻ステップが必要なのか」「異なる集約レベルが必要なのか」といった点については、さらなる探究が進むはずです。そしてこうした領域では、オンデマンドの方が興味深い可能性があります。時間的なドメインに目を向けると、時間方向のプロダクトに対するオンデマンドの更新、あるいは変化マップなどは、大規模なデータプロバイダー側にとっても興味深い領域となり得ます。研究や多様なワークフローにおいては、ループを完結させ、自分自身で埋め込み生成に立ち戻れることが価値となります。データを完全に理解した上で扱いたい、という特定のユースケースにおいては、これは非常に重要です。
Maria： 視聴者の中に再び、私の博士課程の学生のGolaniさんから質問が来ています。「小規模なデータの場合、空間条件付きモデルのデコーダーヘッドのみをファインチューニングするのと、バックボーンも一緒にファインチューニングするのとでは、どちらが望ましいでしょうか」とのことです。
Isabelle： 一般的には、ラベルが多くない場合、パラメータを多くチューニングしない方が学習が安定する傾向があるため、それが良い方向に働きやすいです。ただし、それが常に最良の選択であるとは限りません。直感的には、ラベルが少ないほど、上に軽量なデコーダーを載せるだけで、安定した学習が得られやすいと言えます。これは、事前計算済みの埋め込みを用いた少数ラベルでの実験で、ごく少数のラベルと、その上にただ線形プローブを置く構成を採用する理由の一つでもあります。これは安定して実行できます。
層数が多くなってくると、しばしばバックボーンをアンフリーズすることで、性能の追加的な押し上げや小幅な改善が得られます。ただし、この直感が必ずしも完全には当てはまらないケースもあります。たとえばアンフリーズしたGeoFMもラベル効率がかなり高いことがあります。なぜなら、すでに十分に初期化されたパラメータから出発するためです。
Maria： ありがとうございます。
11. クロージング
11.1 本日のまとめと今後のワークショップ案内
Maria： 他にご質問はないようですので、Isabelleさん、コミュニティに関する情報のスライドをもう一度共有していただけますでしょうか。参加にご関心のある方にとって、これは非常に重要な情報になると思います。
Isabelle： はい、こちらが該当のスライドです。コミュニティへの参加方法をもう一度ご案内します。何かしらリンクが見当たらない場合や、ご質問がある場合は、いつでもご連絡ください。私個人にもメールやLinkedInなどから連絡が可能ですし、お役に立てればと思っています。
Rohini： Isabelleさん、本当にありがとうございました。本日のウェビナーは大変素晴らしいものでした。あなたと、あなたが共に取り組んでおられるチーム全体にも感謝申し上げます。皆さんは本当にGEO AIが向かう先の最前線を切り拓いてくださっており、すぐそこに迫っている新たな地平を目にできるのは非常にエキサイティングです。これらのソリューションは、確実に多様な分野にわたって大きなインパクトをもたらすと思います。Mariaさんにも、いつものことながら大きな感謝を申し上げます。ウェビナーシリーズをキュレーションし、進行してくださっているおかげで、視聴者の皆さんからも「複雑で技術的なテーマでも、基礎を学ぶのに非常に役立った」という多くのコメントをいただいています。
最後に、参加者の皆さんへ。ご参加ありがとうございました。私自身もモデレーターというよりも一人の参加者として常に学ばせていただいていて、皆さんも本ワークショップで新たなスキルを学んでくださったことと思います。GEO AIの世界がどこへ向かおうとしているのか、深く知りたいと思っている方は、ぜひ引き続きご注目ください。Mariaさんもご紹介くださった通り、3月19日にはTerraTorchの入門ワークショップを開催します。本日のウェビナーで不明確だった点があれば、3月開催の回にぜひお越しいただき、基礎をしっかり学んでいただければと思います。すべてのワークショップ教材はニューラルネットワーク上で公開されており、もちろんYouTubeで録画もご覧いただけます。それでは、ここでAnnaにバトンをお返しします。皆さん、ありがとうございました。
Anna： 本日のAI for Goodセッションにご参加いただきありがとうございました。本日のイベントが、新たで革新的、かつ魅力的な学びの機会になったことを願っています。引き続き、ニューラルネットワーク上のライブビデオウォールで会話を続けていただけます。質問を投げかけたり、いいねやコメントをしたり、リンクを共有したり、ポールに回答したり、興味深いプロフィールの方々とつながったり、チャットやビデオ機能で一対一で会話したりすることが可能です。ロビーの探索、スマートマッチングクイズへの挑戦、バーチャル展示、ポスターボード、eShopの訪問、そしてご自身のAI for Goodプログラムのカスタマイズなど、ぜひ自由にお楽しみください。共にAI for Goodの未来を形作っていきましょう。