コンピューティング基盤部の三吉（sankichi92）です。

アークエッジ・スペースでは、衛星リモートセンシング¹による地球観測データ（以下、「衛星データ」）を活用したソリューションを提供する Web GIS² アプリの開発をはじめました。この記事では、プロジェクトの最初期にあたり、プロダクトのさまざまな可能性を高速に検証するために行った技術的な取り組みを紹介します。

Web GIS アプリをつくる背景

アークエッジ・スペースは超小型衛星の開発に強みをもつスタートアップです。衛星開発の会社が、なぜ Web GIS アプリを開発するのでしょうか。

昨年、当社は経済産業省が公募した中小企業イノベーション創出推進事業のうち、「衛星リモートセンシングビジネス高度化実証」に代表スタートアップの1社として採択されました。本事業では、リモートセンシング衛星の開発に加えて、タイトルにも含まれるとおり「ビジネス高度化実証」まで含めて実施する計画です。衛星リモートセンシングでは、衛星から取得した衛星データはそのままの状態では単なる写真に過ぎず、そこから価値を引き出すためには高度な加工・分析の処理が必要になります。そこで、衛星の開発と並行して、既存の衛星データやオープンな地理空間データを利用して、衛星データを加工・分析することでどのようなビジネスが可能かの検討を開始しました。

プロトタイプで検証するもの

ビジネス検討における最初の方針は以下のようなものでした:

農業や環境管理に従事するようなエンドユーザをターゲットにする
思いつくソリューションをとにかく高速に試せるようにする
使用するデータや、データ解析の手法にはこだわらない

この時点で、「エンドユーザ」へのソリューション提供にフォーカスすることは決まっていました。近年、衛星データは容易に入手できるようになり、民間での活用が進んできています。しかし、衛星データを利用するには、衛星・センサの特徴や、提供されるデータフォーマット、解析手法といった専門知識が必要です。私たちは、こうした知識なしに、エンドユーザが自身の必要とするインサイトを得られるようにすることを目指しています。

そのために必要なのは、直観的なデータ可視化とユーザインタフェースです。プロダクトの初期段階では、高速に価値検証のサイクルを回す必要があり、検証したい価値にフォーカスを絞らなければなりません。エンドユーザの体験に価値を置くため、Web アプリのフロントエンドに注力し、データ解析の自動化やユーザ別のコンテンツ出しわけ等のバックエンドを妥協することにしました。

スモールスタートのための技術選定

Web GIS アプリのフロントエンドに注力するため、主要な要素技術として以下を採用しました:

SPA (Single Page Application)
PMTiles
GitHub Pages

それぞれの選定理由を説明します。

SPA

フロントエンドに注力するにあたり、社内の技術スタックを踏まえ、TypeScript + React を使用することは前提でした。とはいえ、現代ではそのうえで Next.js や Remix といったルーティングや SSR (Server Side Rendering) の機能をもったフレームワークの選択肢があります。今回のプロトタイピングではいずれも採用せず、シンプルな SPA の形を取ることにしました³。

SPA にした理由は、Web GIS アプリの主役は地図だからです。シンプルな地図アプリにおいては、ページ遷移は基本的に不要で、1ページで完結します。さらに、Web 地図自体は CSR (Client Side Rendering) となるため、フレームワークが提供するほとんどの機能が必要ありません。シンプルな Web GIS アプリは、SPA との相性が非常によいです。ビルドやデプロイも単純でハマりどころも少なく、機能開発に集中できます。

SPA で開発をはじめるにあたり、同僚である KOBA789 の itzmono-vite というテンプレートリポジトリを使用しました。これに伴い、ビルドには Vite、CSS フレームワークに Tailwind CSS、コンポーネントライブラリに Blueprint を採用しています。

地図ライブラリとしては、ユーザ体験に注力するにあたりベクタータイルの利用は必須だったため、MapLibre GL JS を採用しました。 React から利用するため、react-map-gl も合わせて採用しています。

PMTiles

アプリで使用する一定サイズ以上の GIS データのファイルフォーマットは、PMTiles に統一することにしました。 PMTiles は地図タイル化⁴した GIS データをシングルファイルにできるデータフォーマットです。 Cloud Optimized を謳っており、CDN 等クラウドから静的配信することを前提に設計されています。

PMTiles を採用したのは、タイル化によるユーザ体験の向上と、データの取り回しの簡易化のためです。衛星データのファイルサイズは基本的にとても大きく、Web アプリでスムーズに表示するにはタイル化は必須でした。近年は動的にタイル配信するための OSS もありますが、プロトタイピングにあたっては手元で解析・画像化したデータをそのままアプリ上で表示したいため、静的にタイル配信することにしました。静的タイル配信となれば、データフォーマットとして PMTiles はその筆頭であり、シングルファイルでオリジナルデータとの対応関係わかりやすく、衛星データのようなラスタータイルだけでなくベクタータイルも同じ PMTiles として扱えるという利点もあります。

GitHub Pages

SPA および PMTiles の最初のデプロイ先は GitHub Pages にしました。その理由は以下の通りです:

社内にアクセスを制限できる
- 全社的に GitHub Enterprise Cloud を利用しており、公開を避けつつビジネスサイドのメンバーにも触ってもらえる
- 一時的に公開の必要が生じた場合も、ボタンひとつで対応できる
GitHub のプラットフォームですべて完結できる
- デプロイも容易で、インフラを気にせず機能開発に集中できる

一方で、GitHub Pages には 1 GB の上限があります。これに関して、まずは市区町村レベルの狭い範囲のみを対象にし、使用するデータの地理的範囲を限定することを合意していました。最初に想定していたユースケースは市区町村レベルで十分であり、価値検証への影響もありませんでした。

開発をはじめてからの改善

前節のような形で最初の技術選定しましたが、実際に開発を進めていくと当初の想定から外れた事象が起こります。以下では、開発をはじめてから行なった改善を紹介します。

React Router 導入

素の React アプリとして開発をスタートしましたが、地図アプリは、表示する場所、ズームレベル、重ねているレイヤ等のさまざまな状態を持ちます。プロトタイプの段階でも、特定の状態の画面を共有したいというユースケースが想定されました。これに対応するため、React Router を導入し、地図の状態を動的に URL に反映することにしました。

React Router の選定や導入は、副業でフロントエンド開発に入ってくれている kaorun343 が最初のタスクとしてサクッとやってくれました。アプリの状態を URL に押し込めることで、状態管理もシンプルになりました。

S3 + CloudFront 導入

最初に検討したユースケースでは GitHub Pages で問題ありませんでしたが、次の検討で早々に GitHub Pages の限界に達しました。衛星データの強みは、定期的に同じ場所を観測することで時系列比較が可能な点にありますが、時系列比較はデータサイズが大きくなりがちです。思ったより早かったですが、想定の範囲内ではあったので、すぐに PMTiles の置き場を S3 + CloudFront に移行しました。

Amazon Location Service 導入

はじめ、ベースマップは Protomaps Basemap から対象地域に限定して部分ダウンロードしたものをセルフホストしていました。しかし、南アメリカ大陸全域を対象にしつつある程度の詳細も表示できるようなユースケースを検討するにあたって、セルフホストの手間が大きくなったため、Amazon Location Service の Map をベースマップにすることにしました。はじめて利用したのですが、導入も簡単で、Maxar 衛星画像も利用できるのが想像以上に便利だったので、もっと早く導入すればよかったと感じています。

プロトタイピングの結果

以上のようにして、開発から2ヶ月程度で、対象の地域や提供するソリューションの内容を変え、複数のパターンのプロトタイプを作成しました。現在は、このプロトタイプをベースに、事業として Web GIS アプリの開発を進めていくことが決まっています。もちろん、まだスタートラインに立ったに過ぎないのですが、事業の影も形もなかったところから、プロトタイプの開発により一定の方向性を定めることができました。

今後の課題と展望

現在のアプリはプロトタイプであると割り切っていたため、多くの点を妥協していました。今後は、プロダクトとしてより洗練させていく必要があります。実利用に耐えるユーザ基盤やプロダクション環境の整備はもちろん、次のようなバックエンドシステムを検討しています。

データ基盤、ジョブ管理基盤

現時点ではエンジニアが手元でデータ解析し、その結果を S3 にアップロードしていますが、これではスケールしません。特に、衛星データは日々新しいものが増えていくため、データの処理を自動化するワークフローの整備が不可欠です。プロトタイピングを進める中で、定型的なデータ処理のパターンも見えてきました。そうした処理の自動化を実現するデータ基盤・ジョブ管理基盤を構築します。

動的タイル生成への対応

静的なタイル配信には、事前に全タイルを生成しておかなければならない、また、それゆえ頻繁なデータ更新が難しいという課題があります。特に、全球を対象にするような場合には、可視化のパターンごとに衛星データのタイルを事前生成しておき、アルゴリズム更新のたびにそれらをすべて再生成するのは現実的ではありません。これは衛星データのようなラスターデータに限らず、ベクターデータも同様です。静的タイル配信には適さないデータを配信するための、動的タイル生成基盤が必要になります。

解析の高度化

これらの基盤と合わせて、提供するソリューションの高度化・大規模化を図ります。現在は、エンジニアの手元の開発環境でできる比較的単純なデータ解析しか実施できていません。エンドユーザにより大きな価値を提供するため、機械学習や画像処理による多様な解析手法を取り入れていきたいと考えています。

Web GIS エンジニア、機械学習エンジニアを募集中

今回紹介した Web GIS アプリは、3人のチームで開発してきました。 3人といっても前述のとおり1人は副業、プロダクトオーナー兼データ解析を担当する meltingrabbit や私も他の業務との兼任で、専任はいません。これから開発を加速させていくために、以下の3つの職種で採用を開始しました:

スタートアップならではのスピード感で、衛星を通じた社会課題の解決にともに挑戦する仲間を募集しています！

人工衛星に搭載したセンサで宇宙から地球のさまざまなものを観測する技術。詳しくは https://www.restec.or.jp/knowledge/sensing/sensing-1.html など。↩
Geographic Information System（地理情報システム）の略。地図上にデータを可視化するソフトウェア。詳しくは https://www.mlit.go.jp/tochi_fudousan_kensetsugyo/chirikukannjoho/tochi_fudousan_kensetsugyo_tk1_000041.html など。↩
最近、社内の別のプロジェクトでは Remix を採用した事例もあります。↩
Web 地図での表示に最適化するため、GIS データをタイル状にすること。詳しくは https://www.esrij.com/gis-guide/web-gis/map-tile/ など。↩