公開データで動く3D地球OSS「God's Eye View」の仕組み

GitHub Trending で 1 位になった 3D 地球の可視化 OSS を開いてみたものの、README が数万字規模で、結局「これは何をするソフトウェアで、自分の案件に使えるのか」が読み取れないまま閉じてしまった、という経験はないでしょうか。航空機・船舶・衛星・気象・インフラがひとつの地球の上で動いている画面は魅力的ですが、採用判断に必要な情報は別のところにあります。

判断を難しくしている要因は 3 つあります。1 つはライセンスです。GitHub のリポジトリページに表示されるライセンス情報と README の記述が食い違って見えるため、商用案件に持ち込めるかどうかが読み取れません。2 つ目はデータの性質です。「リアルタイム」と書かれていても、どのレイヤーが実観測で、どれがシミュレーションや推定値なのかが分からなければ、業務判断の材料としては使えません。3 つ目は評価コストで、どこまで API キーなしで動かせるのか、どこから課金が始まるのかが見えません。

英語圏のまとめ記事は機能の列挙に寄っており、この 3 点を整理したものは見つけにくい状況です。スター数が古い値のまま掲載されている記事も混在しています。

本記事では、bilawalsidhu/gods-eye-view（公開ブランド表記は God's Eye View）について、README・LICENSE・公式ドキュメント・GitHub API の取得値という一次情報だけを使い、採用判断に必要な論点を整理します。なお本記事はドキュメントベースの調査であり、インストールや実行による動作検証は行っていません。記載する数値はすべて 2026 年 10 月 7 日時点の GitHub API 取得値および README の記述です。

公開データで動く3D地球OSS「God's Eye View」とは何か

リポジトリの基本情報

まず素性を確定させます。以下は gh api /repos/bilawalsidhu/gods-eye-view による取得値です。

アーカイブ済みでもフォークでもなく、公開リポジトリとして現役で更新されている状態です。最終 push は調査日の前日であり、作成からの経過は約 3.5 か月です。一方でバージョンは 0.2.1 で、オープン Issue は 291 件あります。立ち上がって間もない活発なプロジェクトという位置づけになります。

「スパイ衛星シミュレータ、ただしデータは本物」というコンセプト

リポジトリの description は "A spy satellite simulator in your browser, except the data is real." と書かれています。README は自己定義として "God's Eye View brings public signals into one explorable globe." と述べており、公開されているシグナルを 1 つの探索可能な地球に集約することが目的だと分かります。

由来は著者 Bilawal Sidhu 氏の YouTube シリーズ（旧称 WorldView）であり、その裏側で使われていた可視化環境をオープンソース化したものです。README には 2026 年 8 月に GitHub Trending のデイリー・ウィークリー両方で 1 位になったこと、Product Hunt で #8 Product of the Day になったことが記載されています。トピックには osint / geospatial-intelligence / cesium / satellite-tracking などが設定されています。

God's Eye View ではないもの

採用判断の前に、誤解されやすい点を先に潰しておきます。

• 機密データを扱うツールではありません。README の「The line.」節では、モデル化する対象をイベント・資産・インフラ・システムに限定し、人物名による検索・顔認識・個人追跡の機能は実装せず、その線を越える Pull Request はマージしないと明言されています
• 公式のホスト版は本記事執筆時点では提供されていません。README の「What's Next」に "hosted version is coming" と書かれており、Halfpixel で公式ホスト版を構築中である旨の予告のみです。GitHub の homepage フィールドに設定されている URL はアプリではなく著者のニュースレターで、現在は別ドメインへリダイレクトされます
• 本番サービスとしての堅牢性は自己申告されていません。README はステータスを "a fast, hackable foundation, not a hardened production service" と記載しています

つまりローカルで起動して探索・学習・プロトタイピングに使う前提のクライアントです。この前提を外して基幹システムに組み込む想定で読み進めると、後述するライセンスと免責の条項でつまずくことになります。

God's Eye Viewが束ねる19レイヤーの公開データと、キーなしで動く範囲

README の「What's on the Globe」には、"Nineteen layers and map sources. Seventeen have a keyless path." と明記されています。19 のレイヤーのうち 17 はキーなしで到達できる経路があるという意味です。評価コストを判断する上では、この「キーレスで届く範囲」を先に押さえるのが近道です。

ドメイン別に見たレイヤー構成

レイヤーは大きく、移動体・カメラ・インフラ・イベント・気象・ユーティリティに整理できます。README 記載の数値を引用します。

一覧の原典は README の What's on the Globe セクション です。

認証コスト別の整理

同じレイヤー群を、必要な認証情報で並べ替えると評価計画が立てやすくなります。README は各レイヤーに 🟢 キー不要 / 🟡 無料キー / 🔴 従量課金の区分を付けています。

• キー不要（🟢）: Live Flights（匿名アクセス）、Military Flights、Satellites、Earthquakes、CCTV Mesh、Mapped ALPR Cameras、Radio、Transit、Bikeshare、Directions、Space Missions、Mapped Installations、Wind、Observed Weather、Cyclones、バンドル静的データ
• 無料キーの取得が必要（🟡）: Live Vessels（AISStream）、Active Fires（NASA FIRMS）、Traffic の実測フロー速度（TomTom）、フライトのポーリング上限を増やす場合の OpenSky、ベースマップの 3D 化に使う Cesium ion
• 従量課金が発生しうる（🔴）: Google Maps キーによる Google 直の 3D タイルと場所検索、OpenAI キーによる音声エージェント

README は「ほとんどのレイヤーはサインアップ不要で $0」としつつ、実費が発生する唯一の部分は OpenAI の音声機能だと明記しています。

ベースマップの3段階と、キーを足すと何が変わるか

ベースマップには 3 段階が用意されています。

評価段階での結論は明快です。フォトリアリスティックな 3D 表示を諦めれば、キーを 1 つも用意せずに移動体・地震・カメラ・ラジオ・打上といった主要レイヤーを確認できます。社内でまず見せたい、という段階ではこの構成で足ります。

ライブ・シミュレーション・推定を分けて扱うデータ設計

ここが採用判断で最も取り違えやすい部分です。画面上では同じように動いて見えるオブジェクトでも、データの出自は 3 種類に分かれており、README はそれを隠していません。

実観測・シミュレーション・推定の3分類

• 実観測のライブデータ: 航空機の ADS-B、船舶の AIS、地震（USGS）、公共交通の GTFS-Realtime、気象の数値予報・レーダー・衛星など。外部フィードに届いた観測・配信値を描画します
• シミュレーション: Traffic レイヤーは OpenStreetMap の道路上を走るシミュレーション車両です。TomTom のキーを併用すると実測のフロー速度が渋滞色とシミュレーションを駆動しますが、README は個々の車両位置がライブ観測ではないことを明記しています
• 推定・再構成: CCTV の位置は公開値ですが、カメラのポーズ（向き）は推定の事前値であり、利用者がギズモ操作で校正する設計です。ロケットの軌道には RECONSTRUCTED ESTIMATE のラベルが付きます。Mapped Installations はコミュニティマッピング由来で、本質的に不完全であることが UI 上でラベル表示されます

この区分を押さえずに画面を社内に持ち込むと、「シミュレーションの車列」を実測交通量として説明してしまう事故が起こり得ます。

15〜30秒間隔のフィードを滑らかに見せる補間と推測航法

動きの滑らかさについても README は仕組みを開示しています。ライブフィードが届く間隔は 15〜30 秒で、地球は実時間より 1 インターバル遅れでレンダリングし、既知のフィックス間を補間します。データが欠けた区間は推測航法（dead reckoning）で埋めます。

つまり画面上で滑らかに進む航空機の位置は、常に観測値そのものではなく、観測値の間を埋めた推定を含む表示です。描画の滑らかさを精度の高さと読み替えないことが重要です。音声エージェント側も、フィードの陳腐化やフォールバックが起きた場合はそれを申告する設計になっています。

公式が明示する利用禁止領域

README には重要事項のブロックとして免責が置かれています。公開・第三者データの探索的な可視化であり、データは遅延・不完全・モデル化・推定・誤りを含む可能性があるため、航空および海上のナビゲーション、緊急対応、医療・健康上の判断、投資判断、その他の安全上重要な用途や運用目的での利用は対象外とされています。重要な情報は authoritative source で検証することが求められています。

この一文は、業務システムへの組み込みを検討する際の実質的な上限です。可視化の素材としては使えますが、意思決定の根拠として単独で使う設計は公式の想定外になります。

CesiumJSとバニラJavaScriptで組まれたGod's Eye Viewの内部構造

フレームワークを使わない選択と src の構成

技術スタックは Vanilla JavaScript + CesiumJS + Vite です。加えて Google Photorealistic 3D Tiles と OpenAI Realtime API を利用します。README はフレームワークを採用しない理由を "Fast to read, fast to hack on" と説明しています。読みやすさと改造しやすさを優先した選択です。

ディレクトリ構成は README に次のように記載されています。

src/
├── main.js                 # Bootstrap: Google 3D tiles, layer registration
├── ui.js                   # Runtime UI — panels, HUD, styles, control facade
├── hud.js                  # Intelligence HUD + AI scene summary
├── keySetup.js             # POWER UP panel — in-app provider keys (dev server only)
├── mapStackController.js   # Basemap switching — Google 3D / Esri / OSM / ion stacks
├── voice/                  # OpenAI Realtime session + 29 voice tools
├── layers/                 # Layer components — weather, wind, cyclones, transit, ALPR, …
├── data/                   # One module per layer + orchestration + context store
│   ├── iconOrientation.js  # Screen-projected headings + horizon cull
│   └── local_data/         # Bundled datasets (per-folder provenance)
└── scenes/                 # Cinematic scene director

出典: https://github.com/bilawalsidhu/gods-eye-view#-under-the-ho…

レイヤーごとに data/ 配下のモジュールが 1 つ対応し、描画側のコンポーネントが layers/ に分かれる構造です。レイヤーを追加・削除する改造を前提とした分割になっており、特定のレイヤーだけを自社用途に差し替える改造は見通しが立てやすい構成といえます。なお README は、ランタイムの正式なリファレンスとして docs/CURRENT-STATE.md を指定しています。実装の細部を追う場合はそちらが起点になります。

ライブデータを「正しく見せる」ための実装

README の Under the Hood セクションには、可視化の正確性を保つための実装が列挙されています。自社プロダクトに転用しやすい論点として、次の 4 つが挙げられます。

• World-stable icons: 航空機や船舶のアイコンが、カメラ角度に関係なく実世界の真方位を向きます。フレーム単位でスクリーン空間へコースを投影する実装で、ビューを回しても機首方向が破綻しません
• Honest satellites: SGP4 による軌道伝播と GMST の再整合を行い、軌道リングを衛星に固定します。README はドリフトや毎秒のフリッカーが起きないことを設計上の達成点として挙げています
• 地形への接地: エンティティの高度を Google 3D タイルに合わせることで、航空機がエプロンに接地し、カメラ位置が街角に立ちます
• Caching and request budgets: OpenSky のクレジットガバナ、TomTom の日次タイル予算、TLE のディスクキャッシュが実装されています。ただし README は、これらがプロバイダ側のクォータや課金制御を置き換えるものではないと明記しています

鍵をブラウザに出さないサーバサイドプロキシ

秘密鍵に触れる API（OpenAI、AISStream、OpenSky の OAuth、カメラフレーム）はすべてサーバサイドプロキシ経由で呼ばれ、SSRF 保護・レスポンスサイズ上限・サニタイズ済みエラーが実装されています。ブラウザに渡るキーは Google Maps と Cesium ion の 2 つだけで、この 2 つはプロバイダ側で制限をかけることが前提とされています。

外部 API キーを扱う SPA を設計する場合、この「ブラウザに出すキーと出さないキーを明確に分け、出すキーはプロバイダ側で制限する」という切り分けはそのまま参考にできる設計です。

依存関係とNodeバージョン要件から読める前提

package.json からは実装範囲の広さが読み取れます。cesium ^1.124.0 に加え、軌道計算の satellite.js ^6.0.2、GRIB デコードの @meri-imperiumi/eccodes-wasm、座標系関連の mgrs と egm96-universal、ライブ映像の hls.js、ソフトウェア無線の @jtarrio/webrtlsdr などが並びます。気象データのデコードから軍事用グリッド座標系の変換まで、ブラウザ側で処理する設計です。

実行要件は engines.node が >=24.14.0 <25 || >=26 <27 で、Node.js 24.x（24.14.0 以降）または 26.x が対象です。Node 25 は EOL のため npm run doctor が警告する旨が README に記載されています。CI は GitHub Actions で main ブランチを対象に動作しています。

起動性能について README は、M5 と Chrome の組み合わせによる一点計測でコールドスタートの中央値が 1.86 秒だったと記載しています。ただし同時に、これは比較用のベースラインであり、個々のマシンや回線に対する保証ではないと明記されています。計測条件は docs/PERFORMANCE.md にまとまっています。

29ツールの音声エージェントとMCPサーバー、そしてコスト上限の設計

OpenAI Realtime API による音声操作は、見た目の派手さよりも、LLM エージェントの設計事例として読む価値があります。

29ツールを4つのジョブに割り当てた設計

README は音声ツールを 29 個用意し、4 つのジョブに整理しています。カメラを動かす操作（Direct it）、実世界への注記（Annotate it）、ライブレイヤーに対するアナリストクエリ（Interrogate it）、コンソール操作（Operate it）です。境界を描く指示では円で代用せず実際の囲みポリゴンを描く設計になっており、マイクを使わない場合も手動の描画機能で同じ操作ができます。

ハルシネーションと鍵漏れを避けるための制約

エージェントに課されている制約が README に列挙されています。

• 回答の前に、座標・街路名・有効なレイヤー・ビュースケールといったライブのシーン文脈を取得する
• 航空機・船舶・データセンターなどを選択した状態での質問には、そのオブジェクトのライブテレメトリに基づいて答える
• 街路レベルではビューポートのスクリーンショットを読み取って判読可能な看板や建物名を識別するが、ラベルを絶対にハルシネートしないよう指示されている
• 成功したアクションのみを確認する（失敗した操作を成功として報告しない）
• OPENAI_API_KEY はブラウザに渡らず、クライアントは短命のセッショントークンのみを受け取る

「シーン文脈を先に取得してから答える」「視覚情報からの推測を禁止する」「成功のみ確認する」という 3 点は、業務アプリに LLM を組み込む際の制約設計としてそのまま検討対象になります。

支出を止める仕組み

音声機能は実費が発生する唯一の部分であり、README はコストガードを具体的に記載しています。マイクの横にセッションの支出額を表示し、標準モデルと mini モデルを切り替えるトグルを備え、$2 で警告を出し $5 のハードキャップでセッションを終了します。音声のコンテキストウィンドウも意図的に短く保たれています。Realtime のオーディオはアクティブな 1 分あたり数セント、重い利用の一晩で 1 桁ドル規模という目安が示されています。

従量課金の LLM 機能をプロダクトに載せる場合、警告・ハードキャップ・モデル切り替えの 3 点セットは実装パターンとして転用しやすい部分です。

MCPサーバーとしての利用

npm run mcp で MCP サーバーとして動作し、Claude Desktop や Codex、ChatGPT desktop から場所を指定するとライブの地球が会話の中で開きます。設定手順は docs/MCP_SETUP.md に記載されています。LLM に空間的な文脈を渡す実装例を探している場合は、この経路が参考になります。

なお OpenAI キーがない場合でもアプリ全体は動作し、マイクが音声機能を利用できない旨を報告するだけです。音声を使わない評価は問題なく行えます。

導入前に確認したいライセンス: MITのコードと非商用データの線引き

実務上もっとも重要なセクションです。ここを読み飛ばすと商用案件で事故につながります。

なぜGitHubの表示が NOASSERTION なのか

GitHub API の license.spdx_id は NOASSERTION、license.key は other です。一方 README の「Responsible & Open」節には "Released under the MIT License" と書かれています。一見矛盾しますが、これはライセンスが設定されていないという意味ではありません。

LICENSE ファイルは、冒頭に MIT License の全文（Copyright (c) 2026 Bilawal Sidhu）を置き、その後にサードパーティデータとアセットに関する例外条項を続ける構成になっています。この例外条項があるため標準的な SPDX 識別子に当てはまらず、API 側では NOASSERTION と判定されます。

LICENSE 内の該当節は NOTE ON THIRD-PARTY DATA AND ASSETS — THE MIT LICENSE ABOVE COVERS THE SOURCE CODE ONLY. という見出しで始まります。MIT が及ぶのはソースコードだけであることが明示されています。

コードはMIT、データはそれぞれ別

LICENSE が列挙している対象別のライセンスを整理します。

LICENSE 原文は "In short: the MIT grant does not extend to any third-party data." と述べ、各ソースのライセンスと帰属の全一覧を DATA_SOURCES.md に委ねたうえで、自分の用途に条件が合わないデータセットは削除するよう促しています。

さらにランタイムで取得するソース側にも制約があります。Cesium ion の Community プランは適格な個人・非商用利用向け、Google Maps は課金を有効化した従量課金、OpenSky などは商用利用に制限があり自前の資格情報が必要です。

商用利用を検討するときの確認手順

以上を踏まえると、商用案件での検討は次の順序になります。

1. DATA_SOURCES.md でバンドルデータと取得先ソースを棚卸しし、各ソースのライセンスを一覧化する
2. 非商用限定のデータ（海底ケーブル、Bhote Koshi 関連）を削除した構成で要件が満たせるかを確認する。ソースコードに埋め込まれた座標データも対象に含める
3. ODbL 対象のデータ（Datacenters / Dams）を使う場合は、帰属表示と share-alike 義務を自社の配布形態と照合する
4. ベースマップを 3D にする場合は、Cesium ion の適格条件か Google Maps の従量課金のどちらを選ぶかを決め、プロバイダ側で利用上限を設定する

「MIT だから自由に使える」という読み方だけで進めないことが、このリポジトリを扱う際の最大の注意点です。

プロジェクトが引いている倫理上の線

README は扱う対象をイベント・資産・インフラ・システムに限定し、"People are not a query type here." と明言しています。人物名による検索・顔認識・個人追跡の機能は実装せず、その線を越える Pull Request はマージしないという方針です。OSINT 的な用途で評価する場合、この線引きは機能上の制約として理解しておく必要があります。

類似OSSとの違いから見えるGod's Eye Viewの選定判断軸

類似OSSの比較表

比較対象として 4 件のリポジトリを取り上げます。スター数・ライセンス・最終 push はいずれも GitHub API での実測値です。

性質の違いを軸で並べると次のようになります。

比較の実質は「完成アプリかエンジンか」「公開APIか自前受信機か」

ここで押さえておきたいのは、God's Eye View が CesiumJS の競合ではなく利用者であることです。package.json の依存に cesium ^1.124.0 が含まれており、3D 地球のレンダリングは CesiumJS が担っています。したがって両者を「どちらを選ぶか」で並べるのは筋が通りません。

比較の実質は次の 2 軸に還元できます。

1. 完成アプリを採るか、エンジンから自作するか: 19 レイヤーが同梱された状態から始めるのが God's Eye View、白紙から自社データで組み上げるのが CesiumJS や OpenGlobus です
2. 公開 API の集約で済ますか、自前のデータ基盤を前提にするか: God's Eye View は公開 API とフィードの集約で成立しますが、tar1090 は readsb や dump1090-fa といった自前の SDR 受信機が前提です

それぞれが向く状況

• 航空機だけを自前受信機で高精度に追いたい: tar1090。受信環境の構築が前提になるぶん、自分の観測データで完結します
• 軌道力学や追跡センサーの扱いに深さが必要: KeepTrack.space。ただし AGPL-3.0 であり、ネットワーク越しに提供する場合は派生物のソース開示義務を先に確認する必要があります
• 自社データで独自の 3D 地図アプリを作る: CesiumJS または OpenGlobus。いずれも Apache-2.0 でライセンス面の制約が小さく、設計の自由度を取れます
• 公開データの横断的な可視化をすぐ立ち上げたい: God's Eye View。ただしバンドルデータのライセンス棚卸しが前提になります

動かすまでの最短ルートと、運用で詰まりやすい点

2つの導入経路

README の「Quick Start」には 2 つの経路が示されています。どちらでもアカウントや API キーなしで開始でき、Esri の衛星画像とキーレス地形で同じアプリが開きます。

1 つ目はターミナルを使わない経路で、Pinokio を 8.2 以降にインストール・更新したうえで、Pinokio 上の God's Eye View のページから Install と Start を実行します。Windows / macOS / Linux に対応し、ランチャーがロック済みの依存をインストールして空きポートを探してアプリを開きます。README には、Pinokio 8.2 未満ではインストールが失敗する既知の問題があり、メンテナが修正を告知している旨が記載されています。

2 つ目はターミナルからの経路です。README には次のコマンドが記載されています。

git clone https://github.com/bilawalsidhu/gods-eye-view.git
cd gods-eye-view
npm ci
npm run doctor
npm run dev

出典: https://github.com/bilawalsidhu/gods-eye-view#-quick-start

その後 http://localhost:4173 を開き、初回パネルで表示内容の方向性（Live Contacts / Space Missions / Environmental / Explore Manually）を選びます。

キーはファイルではなくアプリ内で渡す

API キーの投入は、環境ファイルを手で編集するのではなく、画面右下の POWER UP チップから Provider Settings を開いて行う設計です。保存するとアプリが自己再起動します。保存先は Pinokio 経由なら pinokio/ENVIRONMENT、クローンした場合はリポジトリルートの .env で、いずれも秘密情報を書き込む前に所有者のみアクセス可能な権限へ変更され、Git からも除外されます。シェルや macOS Keychain に由来する値は、パネル上で外部設定済みとして読み取り専用になります。

一方で注意点として、README は Pinokio 8.0.40 のネイティブな Configure パネルに資格情報を入力しないよう警告しています。ネストしたアプリのファイルを正しく保存せず、送信された値をログに残すためです。8.2 の告知はインストールの問題を修正するものであり、この Configure パネルの問題が解消されたことを示すものではないと記載されています。

更新しないと一部レイヤーが空になる

運用上もっとも引っかかりやすいのが、バージョンの古さに起因する挙動です。README には、旧バージョンが公開の OpenStreetMap Overpass サーバへ問い合わせる実装になっているが、現在そのリクエストが拒否されるため、更新するまで Traffic / Mapped Installations / ALPR が空のままになると記載されています。レイヤーが表示されない場合、設定ミスではなくバージョンが原因である可能性を先に疑う必要があります。

あわせて Node.js のバージョン要件（24.14.0 以降の 24.x または 26.x、25.x は EOL のため不可）も、起動しない場合の確認ポイントになります。

社内で共有する前に設定すべきもの

既定ではサーバは localhost にバインドされ、他者からは到達できません。Provider Settings も自マシンからのリクエストにのみ応答します。LAN への公開は明示的なオプトインですが、ここにリスクがあります。

SECURITY.md と README は、LAN から見えるサーバは到達できる誰に対しても設定済みの API キーを仲介してしまうと警告しています。コストが発生するエンドポイントには IP 単位のスロットルが既定で有効ですが、README は「アプリレベルのスロットルは課金上限ではなく、予算アラートだけでは支出は止まらない」と明記し、まずプロバイダ側でクォータ・利用上限・課金アラートを設定するよう求めています。

加えて、Pinokio の LAN 共有および Cloudflare 共有はこのランチャーでは無効化されており、リモートアクセスが必要な場合は別途レビュー済みの認証プロキシを用意する必要があります。ライブ映像の配信についても、同時 2 セッション・各セッション最大 12 セグメント / 24 MiB といった上限や、リダイレクト・オリジン外参照・暗号化プレイリストの拒否といった制約が実装されています。

社内デモのために安易に --host 0.0.0.0 を付けて共有すると、キーの仲介と課金の双方でリスクを負うことになります。共有前にプロバイダ側の上限設定を終えておくことが前提条件です。

まとめ: God's Eye Viewを採用すべきチーム・見送るべきチーム

ここまでの内容を意思決定の形に畳みます。

向くケース

• 公開地理空間データの可視化プロトタイプを短期間で立ち上げたい: 19 レイヤーのうち 17 にキーレスの経路があり、評価の初期コストが低く済みます
• CesiumJS ベースの実装パターンを参考にしたい: 真方位を保つアイコン投影、SGP4 による軌道固定、サーバサイドでの鍵仲介、LLM のコストガードは、いずれも自社プロダクトへ転用を検討できる具体例です
• 社内の学習・デモ素材として非商用で使いたい: ライセンス上の制約が最も緩い使い方です
• MCP 経由で LLM に空間的な文脈を渡す事例を見たい: npm run mcp と 29 ツールの設計が参考になります

見送る・条件付きになるケース

• 商用プロダクトに組み込む: バンドルデータの非商用条項（CC BY-NC-SA 3.0 / CC BY-NC 4.0）と ODbL の share-alike を先に解消する必要があります。ソースコードに埋め込まれた座標データも対象です
• 安全上重要な運用で使う: 航空・海上ナビゲーション、緊急対応、医療・健康判断、投資判断での利用は README が明確に対象外としています
• 長期的な API 安定性を前提にした基盤に据える: バージョンは 0.2.1、オープン Issue は 291 件で、README 自身が "not a hardened production service" と自己申告しています

まず何をするか

判断材料を揃える手順としては、次の 3 ステップが現実的です。

1. キーを用意しない状態でローカル起動し、キーレスで到達できるレイヤーの範囲と表示品質を確認する
2. DATA_SOURCES.md でバンドルデータと取得先ソースのライセンスを棚卸しし、自社の用途と照合する
3. 商用利用の可能性がある場合は、非商用限定データを除いた構成で要件が満たせるかを検討し、あわせてプロバイダ側の利用上限を設定する

リポジトリは本記事執筆時点でアーカイブもフォークもされておらず、最終 push は 2026 年 10 月 6 日です。メンテナンスの観点では現役として扱えますが、プロジェクトの自己申告どおり「探索と学習のための、速く改造しやすい土台」という位置づけから外れない範囲で採用を検討するのが妥当な判断になります。

関連情報

地理空間データの可視化や外部 API 連携を含む開発のご相談を検討中の方は、お問い合わせフォーム からご相談ください。要件の整理段階からご相談いただけます。