Feltを調べてみた ― Cloud Native GISはどこまで身近になったのか
はじめに
Web GIS を作ろうとすると、思った以上にやることが多いです。絶賛作成中なのですが。
QGIS でデータを整え、PostGIS に入れ、GeoServer から配信し、OpenLayers や MapLibre で画面を作る。
この構成は自由度が高く、今でも十分に現役です。
一方で、目的が「地図を見せる」「関係者と共有する」「ダッシュボードにする」まで広がると、認証、権限管理、タイル配信、API、フロントエンドなど、GIS そのもの以外の仕事も増えてきます。
そんな中で気になったのが Felt です。
最初は「ブラウザで地図を作るサービス」くらいの印象でした。
ところが調べてみると、QGIS や ArcGIS Pro との連携、PostGIS、GeoParquet、COG、STAC、API、さらに AI や MCP まで取り込んでいます。
単なるオンライン GIS というより、かなり本気で Cloud Native GIS の基盤を目指しているサービスに見えます。
この記事では、Felt が何をするサービスなのか、従来の Web GIS と何が違うのか、そして弊社の業務である水理水文・河川・防災系の GIS でどこに使えそうかを整理します。
この記事で扱うのは GIS プラットフォームの Felt です。
Python の GUI フレームワーク Flet とは別物です。
Feltとは
Felt は、ブラウザ上で地理空間データを扱う GIS プラットフォームです。
基本的な使い方だけを見ると、かなりシンプルです。
ただ、現在の Felt はここで終わりません。
Shapefile や GeoJSON をアップロードするだけでなく、PostGIS やクラウドストレージ側にあるデータを利用し、そのまま Web GIS やダッシュボードへつなげられます。
このあたりが、従来の「オンライン地図作成サービス」と少し違うところです。
まず、従来のWeb GISを振り返る
自前で Web GIS を作る場合、よくある構成は次のようになります。
現在最新版を作成中です。
この構成の良いところは、何といっても自由度です。
投影法、配信方式、タイル構成、API、画面設計まで、自分たちで決められます。
ただし、その代わりに管理対象も増えます。
PostGIS、GeoServer、Web サーバー、認証、タイル、API、JavaScript のフロントエンド。
公開先が増えれば、権限管理や運用も必要になります。
Felt は、この中でも特に **「利用者へ届けるところ」**をまとめてくれるサービス、と考えると分かりやすいです。
つまり、
QGIS や PostGIS を捨てて Felt に置き換える
というより、
QGIS や PostGIS の先に Felt を置く
というイメージです。
Feltを「Cloud Native GIS」として見る
Feltを見ていて面白いのは、最近の地理空間データ基盤でよく出てくる技術が、一通り同じ方向を向いていることです。
代表的なものを並べると、
| 用途 | 技術 |
|---|---|
| ベクター | GeoParquet |
| ラスター | COG |
| カタログ | STAC |
| ストレージ | S3 / GCS / Azure |
| データベース | PostGIS |
| 分析基盤 | BigQuery / Snowflake / Databricks など |
| デスクトップGIS | QGIS |
| Web公開 | Felt |
| 自動化 | REST API / SDK |
| AI連携 | Felt AI / MCP |
という構成になります。
従来は、GIS サーバーの中にデータを集めて配信する考え方が中心でした。
Cloud Native GIS では少し違います。
データを1か所へ集める
のではなく、
クラウド上にある正式な元データへ必要なときに接続する
という考え方が強くなります。
この構成なら、Felt は「GIS データの保管庫」そのものではなく、データを利用するための窓口になります。
GeoParquetとの相性
GeoParquet は、Parquet に地理空間情報を持たせた形式です。
大量のベクターデータを扱うようになると、Shapefile や巨大な GeoJSON より扱いやすい場面が増えてきます。
例えば国土数値情報を加工して利用する場合、こんな流れが考えられます。
ここで無理に Felt の中ですべてを処理する必要はありません。
データの正規化や品質チェックは Python や DuckDB、QGIS で行い、できあがった GeoParquet を公開側へ渡す。
この分け方の方が、個人的には扱いやすいと思います。
ラスターはCOGで扱う
DEM、航空写真、衛星画像、浸水深などのラスターデータでは、COG が重要になります。
COG は Cloud Optimized GeoTIFF の略です。
普通の GeoTIFF と同じように見えますが、クラウド上から必要な範囲だけ読みやすいように内部構造が工夫されています。
巨大なラスターを毎回丸ごとダウンロードするのではなく、
表示している範囲だけ読む
という使い方がしやすくなります。
Felt は、外部ストレージに置いた COG をストリーミングして表示する構成を持っています。
DEM や解析結果を大量に持つ場合は、この仕組みの方がかなり自然です。
STACも使える
COG が増えてくると、次に問題になるのが、
どのファイルが、いつの、どの範囲の、何のデータなのか
です。
そこで出てくるのが STAC です。
STAC は、衛星画像や DEM などの地理空間アセットを検索できるようにするカタログ仕様です。
例えば、
2026年9月
神奈川県周辺
浸水解析結果
といった条件から対象データを探し、その先にある COG を利用する構成が作れます。
STAC
↓
どのデータを使うか探す
↓
COG
↓
必要な部分を読む
↓
Feltで表示
Cloud Native GIS を考えるとき、
GeoParquet + COG + STAC + Object Storage
という組み合わせは、かなり重要になってきそうです。
QGIS や ArcGIS ProとFeltは競合というより役割分担
個人的に一番気になったのが QGIS との関係です。
Felt には QGIS プラグインがあります。
このため、
QGISで作る
↓
QGISで確認する
↓
Feltへ送る
↓
ブラウザで共有する
という流れが作れます。
これはかなり実務向きです。
QGIS は細かな編集や解析が得意です。
Felt は Web で見せたり、人と共有したりする部分が得意です。
無理に片方へ寄せるより、
作るところは QGIS、見せるところは Felt
と分けた方が自然です。
PostGISもそのまま活かせる
PostGIS をすでに使っている場合も、Felt に全部移し替える必要はありません。
PostGIS 側を元データの管理先にして、必要なデータを SQL で取り出して地図へ出す構成が取れます。
例えば、浸水深 50 cm 以上だけを対象にしたいなら、
SELECT *
FROM flood_depth
WHERE depth_m >= 0.5;
のようにデータベース側で絞り込み、その結果を地図に出す考え方です。
データ量が大きくなるほど、
ブラウザへ全部持ってくる前に、データベース側で絞る
という考え方が重要になります。
ダッシュボードもFeltの強み
Felt は「地図を表示する」だけでなく、地図とグラフや統計値を組み合わせたダッシュボードも作れます。
水理水文・河川や防災なら、例えばこんな画面です。
独自 Web GIS でも当然作れます。
ただ、そのためには画面、API、グラフ、フィルタ処理などを自分で実装しなければなりません。
「解析結果はすでにあるので、関係者に見せるところを早く作りたい」という用途なら、Felt の強みが出やすい部分です。
REST APIとSDK
Felt は画面から操作するだけではありません。
REST API があり、Map、Layer、Source、Project などをプログラムから扱えます。
そのため、
のように、解析後の地図作成まで自動化できます。
Python 用には felt-python、Web 側には JavaScript SDK も用意されています。
独自の Web アプリへ Felt の地図を組み込みたい場合は、
という構成も可能です。
そしてFelt AI
ここからが最近の Felt らしいところです。
Felt には AI 機能が入り、自然言語から SQL や GIS 操作へつなげる方向へ進んでいます。
例えば、
浸水深50cm以上の区域にある施設を抽出したい
という指示から、
という流れを作る考え方です。
これまでは GIS 技術者が SQL や空間処理を書いていました。
今後は、
人が目的を言葉で伝え、AI が GIS 操作へ変換する
という使い方が増えていきそうです。
MCPまで入ってきた
Felt を調べていて、特に面白かったのが MCP です。
2026年4月、Felt は公式 MCP Server を発表しました。
MCP は Model Context Protocol の略で、AI エージェントと外部ツールを接続するための仕組みです。
Felt の公式発表では、MCP Server は 1 endpoint / 30 tools で提供されています。
イメージすると、こうなります。
例えば、
この浸水区域と避難所を重ねる
↓
浸水区域内の避難所を抽出
↓
危険度で色分け
↓
地図にする
↓
共有する
という一連の処理を AI 側から実行する方向です。
ここで面白いのは、最終結果が単なる JSON ではなく、人が開いて確認できる地図として残ることです。
AI が GIS を操作し、人が結果を地図で確認する。
この形は、GIS と AI エージェントを組み合わせるときの一つの分かりやすい完成形だと思います。
水理水文・河川・防災GISなら、どこに置くか
水理水文・河川・浸水解析で Felt を使うなら、計算エンジンとして使うものではありません。
例えば、
- 1D 河道計算
- 2D 浅水流
- 土石流・泥流・火砕流・溶岩流
- DEM 前処理
- 降雨流出計算
- TELEMAC
- HEC-RAS
- 独自 Fortran Solver
- Rust Solver
などは、従来どおり専用環境で処理します。
Felt は、その先に置くのが自然です。
この分け方なら、
計算する仕組み
と
結果を見せる仕組み
を切り離せます。
解析ソルバーを作り直す必要はありません。
EPSG:6676のような平面直角座標系はどうするか
河川や測量データでは、JGD2011 の平面直角座標系を使うことがよくあります。
例えば、
EPSG:6676
JGD2011 / Japan Plane Rectangular CS VIII
です。
このようなデータでも、元データ側に CRS 情報をきちんと保持しておくことが重要です。
ただし、距離、面積、水理計算などの正式な元データは、Felt 側へ寄せすぎない方がよいと思います。
とする方が役割が明確です。
Feltに全部やらせる必要はない
Felt が便利でも、すべてを Felt へ移す必要はありません。
例えば、次のような仕事は専用ツールの方が向いています。
- DEM の前処理
- GeoParquet の大量 ETL
- DuckDB Spatial による集計
- QGIS Processing
- PMTiles の細かな生成
- 数値シミュレーション
- Fortran / Rust の Solver
- 独自フォーマット変換
- 厳密な座標処理
全体としては、こんな分担がしっくりきます。
Felt の強みは、計算そのものより **「GIS を使う人へ届けるところ」**にあります。
自前Web GISと比べてみる
ざっくり比較すると、次のようになります。
| 項目 | 自前構築 | Felt |
|---|---|---|
| 高度なGIS編集 | ◎ | ○ |
| 数値解析 | ◎ | △ |
| Web公開 | 実装が必要 | ◎ |
| サーバー運用 | 必要 | 基本不要 |
| PostGIS | ◎ | 接続可能 |
| GeoParquet | ◎ | 対応 |
| COG | ◎ | 対応 |
| STAC | 自前構築可能 | 対応 |
| ダッシュボード | 自作 | ◎ |
| 共同編集 | 別途実装 | ◎ |
| QGIS連携 | ― | Pluginあり |
| REST API | 自作 | あり |
| JavaScript連携 | OpenLayers等 | SDKあり |
| AI | 自作 | Felt AI |
| MCP | 自作 | 公式MCPあり |
| 自由度 | ◎ | ○ |
| 導入の速さ | △ | ◎ |
どちらが上という話ではありません。
自前 Web GIS は、必要なものを細かく作り込めます。
Felt は、
すでに GIS データはある。
それを早く Web で見せたい。
という場合に強そうです。
料金は事前に確認した方がよい
2026年9月12日時点で、Felt の Professional / Enterprise は、公式料金ページ上で固定料金が明示されていない構成です。
本格的に使う場合は、利用人数や必要な機能に応じて確認する必要があります。
特に、
- PostGIS などの Cloud Source
- S3 連携
- REST API
- JavaScript SDK
- MCP
- SSO
- 高度な管理機能
などを利用する場合は、Enterprise の対象になる機能があります。
PoC の段階で、
何人で使うか
何GB扱うか
APIが必要か
DBへ直接つなぐか
MCPを使うか
を先に整理しておくと、費用比較がしやすくなります。
気を付けたいところ
Felt に限った話ではありませんが、SaaS 型 GIS を導入するときは何点か確認しておいた方がよいです。
データの保存場所
行政、防災、インフラのデータでは、データ所在地や契約条件を確認する必要があります。
公開データだけなら問題にならなくても、非公開情報や重要インフラ情報を扱う場合は別です。
SaaSへの依存
自前システムと違い、機能や料金体系はサービス側の変更を受けます。
正式な元データまで SaaS 側だけに置くかどうかは、事前に決めておいた方がよいと思います。
高度な解析は別環境
Felt は便利ですが、数値解析ソルバーの代わりではありません。
解析と公開を分けて考えた方が設計しやすくなります。
Feltを見ていて感じたこと
Felt を調べる前は、
QGIS の Web 版に近いものかな
と思っていました。
実際に見ていくと、少し違いました。
Felt が面白いのは、
GeoParquet
COG
STAC
Object Storage
PostGIS
QGIS
API
AI
MCP
を、それぞれ別の技術として置いておくのではなく、一つの GIS 利用環境につなごうとしているところです。
特に MCP が入ったことで、見え方がかなり変わります。
これまでは、
人
↓
QGIS
↓
GIS処理
でした。
これからは、
人
↓
AI Agent
↓
MCP
↓
GIS処理
↓
Map
↓
人が確認
という流れも現実的になってきます。
AI が GIS を全部自動化する、という話ではありません。
最終的には、地図を見て「この結果でよいか」を人が判断する必要があります。
その意味でも、AI の出力先が「人が確認できる地図」になっている Felt の方向は、かなり面白いと思います。
まとめ
Felt は、単なるオンライン地図作成サービスではありません。
現在の Felt を一言でまとめるなら、
Cloud Native GIS のデータと、人・Webアプリ・AIをつなぐためのGISプラットフォーム
という表現が近そうです。
個人的に、特に気になったのは次の5点です。
- QGIS と無理なく共存できる
- GeoParquet / COG / STAC と相性がよい
- PostGIS を元データの管理先にする
- Web GIS と Dashboard を早く作れる
- AI / MCP が GIS 操作へ入ってきている
水理水文・河川・防災系で考えるなら、
くらいの役割分担が、まず試しやすそうです。
自前 Web GIS を全部置き換える必要はありません。
むしろ、
計算やデータ管理は自分たちで持ち、公開・共有・AI連携を Felt に任せる
という使い方から試すのがよさそうです。
Cloud Native GIS や GIS MCP を考えているなら、一度触っておいて損はないサービスだと思います。
参考リンク
Felt
-
Felt
https://felt.com/ -
Cloud Sources
https://felt.com/platform/cloud-sources -
Raster Platform
https://felt.com/platform/raster -
Pricing
https://felt.com/pricing
QGIS連携
- Getting Started for QGIS Users
https://help.felt.com/Getting-Started-For-QGIS-Users-c3147f78cbdd49b493261e17bc30536c
Developer
-
Felt REST API
https://developers.felt.com/rest-api/getting-started -
Felt JavaScript SDK
https://developers.felt.com/js-sdk/getting-started
MCP
- Introducing Felt MCP Server
https://felt.com/blog/introducing-felt-mcp-server