地図UIの実装を考えはじめると、最初の壁はたいていGoogle Maps APIの設定です。
小さなプロトタイプを試したいだけなのに、請求アカウントを作って、キーを発行して、使いすぎを監視しながら開発する。
その手間が地味に重い。
gods-eye-viewはその壁をまるごと取り除いたOSSプロジェクトです。
ブラウザだけでフォトリアルな3Dグローブが動き、フライト・船舶・衛星の軌跡がリアルタイムで重なって見える。
GitHubのスター数は47,000超、フォークも9,700超という数字は、「映えるデモ」として眺めるだけでなく実際にコードを読もうとした人が多いことを物語っています。
仕組みと限界を技術的に確認しながら、「自分のプロジェクトに持ち込む価値があるか」を見極めていきます。
APIキーも登録も不要な3Dグローブ、gods-eye-viewとは
gods-eye-viewの作者であるbilawal.ai氏の言葉を借りると「スパイ衛星シミュレーター。ただしデータは本物」というプロジェクトです。
リポジトリ に記載されているこの説明文が、そのままツールの本質を言い表しています。
技術スタックはReact + CesiumJSです。
CesiumJSは2012年からApache 2.0ライセンスで開発が続いているJavaScriptライブラリで、航空・スマートシティ・ドローンなどの産業分野で実績があります。
GitHubのスター数は15,800超、フォークは3,900超と、地理空間ビジュアライゼーション領域では信頼のある基盤ライブラリです。
gods-eye-viewはそのCesiumJSをReactから扱いやすく包んで、フライト・船舶・衛星などのライブデータレイヤーを乗せた構成になっています。
「おもちゃではないか」という疑問は自然です。
答えは「エンジンは本物、ラッパーは個人OSSとして評価する」です。
CesiumJS自体は実務に耐えるものですが、gods-eye-viewはあくまで個人プロジェクトであり、本番採用にはそれなりの判断が必要です。
その点は後半で正直に整理します。
APIキーが不要な理由はシンプルです。
CesiumJSはデフォルトでCesium ionというホスティングサービスのアクセストークンを要求しますが、gods-eye-viewはそこをオープンアクセスのタイルプロバイダーに差し替えることでトークン依存をなくしています。
衛星画像にはNASA BlueMarbleやArcGIS World Imageryといった公開タイルを参照し、地形データも無償公開されているものを組み合わせています。
アカウント登録も課金設定も不要なのは、意図的な設計の結果です。
cloneして3分で動く──セットアップと最初の画面
実際に手元で動かすまでの手順はシンプルです。
git clone https://github.com/bilawalsidhu/gods-eye-view.git
cd gods-eye-view
npm install
npm run dev
これだけでローカルサーバーが起動し、ブラウザでフォトリアルな3Dグローブが表示されます。
依存パッケージのインストールに数分かかりますが、それ以外に設定ファイルを触る必要はありません。
初回起動時の画面は「おっ」となるくらいの迫力があります。
衛星画像で覆われたリアルな地球が画面に浮かび、フライトレイヤーを有効にすると世界中の航空機がリアルタイムで動きます。
船舶レイヤーも同様で、AIS由来と思われる動きが海上に広がります。
衛星軌道のレイヤーも美しく、低軌道衛星群が地球を取り巻く様子が一目でわかります。
つまずきやすい点をまとめておきます。
- Node.jsは比較的新しいバージョンが必要です。v18以上が無難で、古い環境ではビルドエラーになることがあります。
- WebGL対応環境 が前提です。仮想環境やリモートデスクトップ経由では描画が落ちるか動かないことがあります。
- ファイアウォール環境では外部タイルの取得がブロックされ、グローブが真っ黒になる場合があります。タイルのオリジンを確認してください。
npm installの時点でCesiumJSのパッケージも一緒に落ちてくるため、初回は少し待つ必要があります。
一度インストールが済めば、以後の開発サーバー起動は数秒です。
Cesium ionなしで動く理由──タイルプロバイダーとデータレイヤーの構造
gods-eye-viewがAPIキー不要で動く核心は、CesiumJSのImageryProviderを差し替えている点にあります。
通常のCesiumJSはデフォルトでBing MapsのタイルをCesium ion経由で取得するため、アクセストークンがないと動きません。
ここをOpenStreetMapやArcGIS World Imageryなどのオープンアクセスプロバイダーに切り替えることで、トークンなしでも動作します。
概念として示すと、次のような構成です。
// Cesium ionトークンなしでオープンタイルを使う例（概念コード）
import { Viewer, OpenStreetMapImageryProvider } from "cesium";
// Cesium ionのデフォルトトークン要求を空にして回避
Cesium.Ion.defaultAccessToken = "";
const viewer = new Viewer("cesiumContainer", {
imageryProvider: new OpenStreetMapImageryProvider({
url: "https://tile.openstreetmap.org/",
}),
terrainProvider: undefined, // フラットグローブにする場合
});
gods-eye-viewはこれをReactコンポーネントとして包んでいます。
CesiumのViewerインスタンスをuseRefで保持し、useEffectで初期化するパターンが典型で、コンポーネントのアンマウント時にviewerをdestroyする作りになっています。
フライトや船舶のデータレイヤーは、公開されているリアルタイムデータを定期ポーリングまたはWebSocket経由で受け取り、CesiumのEntityとして追加していく構造と考えられます。
自分のデータを差し込む場合も基本は同じです。
// 位置エンティティをグローブ上に追加する例（概念コード）
import { Cartesian3, Color } from "cesium";
viewer.entities.add({
position: Cartesian3.fromDegrees(longitude, latitude, altitude),
point: {
pixelSize: 8,
color: Color.YELLOW,
},
label: {
text: callsign,
font: "12px sans-serif",
},
});
fromDegreesに緯度・経度・高度を渡すだけで3Dグローブ上にプロットできます。
物流の配送車両・施設の設備・防災センサーの観測点など、座標を持つデータであれば何でも乗せられます。
ここを理解すると「gods-eye-viewを足がかりに、自分のデータを3Dグローブで見せる」イメージが一気に具体的になります。
タイルプロバイダーを差し替えた場合の注意点も押さえておく必要があります。
OpenStreetMapのタイルは非商用・低トラフィック向けの利用規約です。
本番の高アクセスサービスにそのまま使うのは規約違反になるため、自前のタイルサーバーを立てるか、MapTilerやStadia Mapsなど商用利用可能なプロバイダーの有料プランに切り替える必要があります。
実務で使えるか──ユースケースと正直な制約
プロトタイプとしての用途は明確にあります。
物流の配送車両をリアルタイムで地球上に表示したい、施設の点検箇所を3Dマップで可視化したい、防災センサーの観測点と地形を重ねて見たい——こういったニーズで「まず動くものを見せてステークホルダーに判断してもらいたい」フェーズには、かなり強い武器です。
開発者が一人でも1日以内に「動く画面」を作れるのは、意思決定を早める上で大きなアドバンテージになります。
向いているユースケースを整理します。
- 世界規模・広域の位置情報を3Dグローブ上で見せたい（地球儀感が刺さるプレゼン用途にも有効）
- 時系列で動く軌跡や経路を表示したい（CesiumJSのサンプリングポジション機能が使える）
- 社内デモ・POCとしてAPIキーなしで素早く形を作りたい
- CesiumJSの構造を理解するための参照実装として学習したい
逆に、向いていないユースケースも正直に書いておきます。
- 住所検索・ルート案内・ジオコーディングが必要（それはGoogle MapsやMapboxの領域です）
- 2Dの平面地図で十分なユースケース（LeafletやMapLibreのほうが圧倒的に軽くて扱いやすい）
- 本番サービスとして高トラフィックに耐える必要がある（タイルプロバイダーの商用契約が必要になる）
- データの精度・リアルタイム性の保証が業務上必要（以下の免責事項が直撃する）
リポジトリのREADMEには「データは遅延・不完全・推定・誤りの可能性がある」と明記されています。
フライトや海上航行、緊急対応、医療・投資判断などのセーフティクリティカルな用途には使わないことも明確に書かれています。
可視化の参照データがそもそも推定込みであることを前提に使う必要があります。
メンテナンス体制についても現実的に見ておく必要があります。
スター数とフォーク数は多いですが、メンテナーは実質的に一人のプロジェクトです。
依存パッケージのアップデートやCesiumJSのバージョン追従が止まるリスクを、本番採用の検討時には頭に置いておいてください。
プロトタイプから本番に進む段階で、CesiumJS部分を自前で管理する構成に移行するのが現実的な路線です。
Google Maps・Leaflet・生のCesium.jsとどう使い分けるか
一番最初の分岐点は「グローブが必要か、マップで十分か」です。
地球規模の航路・衛星軌道・時系列の移動データを扱うなら、3Dグローブ（CesiumJS系）が本領を発揮します。
一方、国内の施設マップ・ルート案内・店舗検索のような用途には、フラットな2Dマップで十分です。
LeafletはOSSで軽量、モバイルフレンドリーな定番ライブラリです。
MapLibreはベクタータイルで高品質な2D地図を描けます。
「建物を3Dっぽく見せたい」程度の要件なら、MapLibreのextrusion機能で大半は解決します。
本格的な3D地形・フォトリアルなグローブが必要になってはじめて、CesiumJS系の出番です。
gods-eye-viewを選ぶ一番の理由は「CesiumJSを素で触る前にプロトタイプを見せたい」という文脈に収まります。
生のCesiumJSは学習コストがそれなりにあります。
座標系やEllipsoidの扱い、Camera操作のAPIは独特で、初見で手こずる部分が多い。
gods-eye-viewはその学習コストを一時的に吸収してくれるラッパーです。
「3Dグローブを使ったUIを見せること」に集中できます。
生のCesiumJSに移行すべきタイミングは比較的明確です。
UIのカスタマイズが深くなってきた、Cesium ionのフォトリアル3Dタイルを活用したい、本番品質のパフォーマンスチューニングが必要になった——このどれかに当てはまった段階が切り替えどきです。
Reactで続けるなら resium ライブラリが橋渡しになります。
Google Maps APIとの比較は「住所や経路が必要かどうか」で決まります。
3Dグローブが不要で、日本語住所検索・ルーティング・ストリートビューが必要なら、課金を受け入れてでもGoogle Maps APIを使う価値があります。
gods-eye-viewやCesiumJSはジオコーディングもルーティングも持っていません。
「見せる地図」には強く、「探す・案内する」はGoogle MapsやMapboxの担当領域です。
判断の流れをまとめると、まず「2Dで十分か」を問う。
十分ならLeafletかMapLibre。
次に「グローブが必要か」を問う。
必要ならCesiumJS系。
その上で「プロトタイプ段階か本番か」を問う。
プロトタイプならgods-eye-viewからはじめて、本番に向けて生のCesiumJSに切り替えるルートが現実的な選択肢です。
株式会社ホコサキは山口県宇部を拠点に、Web制作・業務システム開発・AI活用支援・DX推進に取り組んでいます。
地図UIの技術選定や業務向けの位置情報可視化の実装など、開発相談もお気軽にどうぞ。
お問い合わせ からご連絡ください。