Geo Agent・Agentic GISとは
Geo Agent・Agentic GISは、利用者の目的を空間分析の手順に分解し、地理空間データやGISの道具を使って実行・検証し、地図・候補表・報告書を返す仕組みです。衛星画像の認識モデルや、都市内の人流を再現する仮想エージェントとは役割が異なります。
本記事では国内外の研究・企業・知財・政策を比較し、PLATEAU、屋根・壁面の太陽光、ペロブスカイト、公共施設、防災への応用と導入条件を整理します。研究成果、製品の提供状態、独自の提案・仮想試算を分けて記載しています。
- 技術担当者:構成要素、空間計算、MCP、検証方法を確認できます。
- 事業開発・自治体・施設管理者:用途、費用対効果、支援制度、着手順序を比較できます。
- 再エネ事業者:候補面の抽出から需要・発電・導入効果へつなぐ設計を確認できます。
調査基準日:2026年10月19日。公開情報に基づく調査・分析であり、特定製品の性能や導入成果を保証するものではありません。
この調査が示すこと
地理空間情報とAIエージェントの融合は、地図に質問できる段階から、複数のデータを集め、空間処理を組み立て、業務上の選択肢を作る段階へ移っている。ただし、その到達度は均一ではない。自然言語から地図を表示する製品、衛星画像を解釈する基盤モデル、人流を再現する仮想エージェント、許可された業務を実行するエージェントは、同じ「Geo Agent」という言葉で語られても別の技術である。
本稿の中心的な見立ては、競争の焦点が「誰でもGISを操作できること」から、どの場所について、どの根拠に基づき、何を実行すべきかを検証可能な形で届けることへ広がる、というものだ。GISの操作負担が減っても、観測の限界、制度の適用条件、物理的制約、承認権限は消えない。むしろ自動処理が大量化するほど、それらを明示できる事業者の重要性が増す。
直近の動きは速い。Googleは2026年10月に地理空間推論エージェントの研究と実験的な接続手段を公表し、Cesiumは10月12日にion MCP Serverを発表した。WherobotsとHEREの連携発表も10月14日である。一方、日本でもアジア航測がALANDIS+と生成AIを組み合わせるサービスを発表し、国際航業はGeozénを通じた空間情報・解析・業務連携の基盤を打ち出している。これらを「全面的な自律GISが完成した」と読むのは早いが、実装の部品が急速に接続されつつあることは確認できる。[11][12][25][26][35][36]
意思決定者が押さえるべき論点は五つある。第一に、汎用モデルの性能だけでなく、道具・データ・評価方法が成果を左右する。第二に、3D表示とデジタルツインの運用能力は同じではない。第三に、国内の測量・建設・地理空間企業が持つ現場知識とデータ品質は、エージェント化によって再利用しやすくなる。第四に、公的支援はGIS全般への一括補助ではなく、都市モデル整備、衛星利用、行政実装など目的別に組み立てられている。第五に、知財は「AIで地図を扱う」という広い標語ではなく、処理手順・役割分担・対象業務の具体的な組合せとして確認する必要がある。
本稿では、資料に明記された事実、企業自身による説明、論文の実験結果、本稿独自の解釈を区別する。公開資料から確認できなかった性能や導入実績を推定で補ってはいない。全世界の非公開案件や全特許を尽くすものではなく、研究から実装・投資・政策までをつなぐための広範な構造的レビューである。論文は全文を確認したものと要旨・公開説明にとどまるものを巻末に示し、数値比較には条件を付した。
01|最初に、四種類の「エージェント」を分ける
「横浜市内で太陽光の候補建物を探して」と指示したとき、建物を抽出し、地形や屋根の条件を調べ、候補表を作るのがGIS業務エージェントである。その処理の途中で、航空写真から屋根を認識するモデルが呼び出されるかもしれない。しかし画像認識モデル自体は、必ずしも計画を立てたり、エラーを修正したりするエージェントではない。この違いを曖昧にすると、画像認識精度を業務完遂率と誤認する。
| 区分 | 主な役割 | 成果物 | 混同しやすい点 |
|---|---|---|---|
| GIS業務エージェント | 目的を処理手順に分解し、GISやAPIを実行 | 分析レイヤー、候補表、地図、報告書 | 自然言語検索だけでは多段の業務遂行とはいえない |
| 地球観測・空間基盤モデル | 画像・地形・時系列などから特徴を抽出 | 埋め込み、分類、検出、予測 | 高い認識能力と業務の自律性は別の軸 |
| シミュレーション内のエージェント | 人・車・設備などの行動や相互作用を表現 | 交通量、滞在、避難、需給などのシナリオ | 仮想人物の説明は実在住民の証言ではない |
| 運用・実行エージェント | 承認済みの判断を通知・配車・設備運転等につなぐ | 業務状態や現実の運転状態の変更 | 分析が正しいことと実行権限があることは別 |
Agentic GISは通常、第一の領域を中心に、他の領域を組み合わせる設計を指す。本稿では「目的に沿って複数の空間情報処理を選び、実行結果を読み、必要に応じて修正し、成果物を返す仕組み」と定義する。チャットの見た目やモデルの呼び出し回数は定義の核心ではない。失敗した処理から復帰できるか、要求と成果物の対応を確認できるかが重要である。
エージェント型デジタルツインはさらに広い。現実の状態を表すデータ、状態変化を扱うモデル、選択肢を比較する仕組み、現場から結果を戻す経路を持ち、その一部にエージェントが介在する。3D都市モデルを表示して質問に答える機能は有用だが、観測更新もシミュレーションもないなら、都市運営の閉じた循環まで成立したとはいえない。表示の精細さと運用の成熟度を別々に評価する必要がある。
名称にも注意がいる。GeoAgentという名前は、画像から場所を特定する研究、階層型GISエージェント、オープンソースのGIS支援ライブラリ、QGISプラグイン、企業製品などに重複して使われている。たとえばOpenGeosのGeoAgentと、QGIS公式プラグイン一覧にある同名プラグインは、名前が似ていても同一製品として扱えない。検索結果を企業名・著者・リポジトリ・公開年で照合することが、調査の第一歩になる。[07][08][22][23]
02|技術の全体像は、七つの層で理解できる
地理空間エージェントの全体像を、巨大な一つのモデルとして捉えると設計を誤りやすい。実際には、データ、空間計算、認識、予測、業務計画、検証、利用者との接点が異なる速度で進化している。本稿では七つの層に整理する。これは特定製品の公式分類ではなく、企業・自治体が構成要素と責任を整理するための分析枠組みである。
最下層はデータと利用条件である。座標、時刻、観測方法、精度、識別子、利用許諾が揃って初めて、複数の情報を安全に組み合わせられる。建物の外形が最新でも、用途属性は古いかもしれない。公開画像を閲覧できても、加工成果物の再配布が自由とは限らない。データが存在することと、顧客向け成果物に使えることは区別しなければならない。
その上に、バッファ、空間結合、経路探索、ラスタ演算などの計算層がある。ここでは再現可能なアルゴリズムと型のある入出力が重要だ。LLMに面積を文章から推測させるのではなく、対象形状と座標系を指定して計算エンジンに処理させる。言語モデルは「何を計算すべきか」を解釈し、計算結果を意味づける役割を担う。
認識層は衛星・航空・地上の観測から状態を抽出する。さらに予測・シミュレーション層では、洪水、交通、発電、建物エネルギー、設備劣化などの専門モデルを使う。観測された屋根面積と、推定された設置可能面積、将来の発電量シナリオは、同じ数値列に並んでも証拠の種類が異なる。画面上でも保存形式でも、この区別を残すことが望ましい。
計画層はユーザーの目的を手順に変換する。ただし、手順が長いほど自由度を増やせばよいわけではない。定型処理には既定のワークフローを使い、対象地域やデータの違いに対応する部分だけを柔軟にする構成が現実的だ。専門家が確立した手順を機械が呼び出せる小さな技能として持つことは、プロンプトを長文化することとは異なる。
検証・権限層では、座標系、単位、欠損、出力件数、禁止操作、承認履歴を扱う。利用者との接点には地図やチャットだけでなく、比較表、根拠資料、再実行ボタン、担当者への引き継ぎが含まれる。七層を全部自社開発する必要はない。どの層を外部サービスから買い、どこに独自の業務知識を置くかが、事業戦略になる。
03|2023年から2026年へ、研究は何を積み上げたか
Autonomous GISの初期研究として、Liらの2023年の論文は、LLMを使って空間分析の手順とコードを生成する方向を示した。自己生成、自己組織化、自己検証、自己実行、自己成長という目標は、現在のエージェント議論にも通じる。ただし、少数のケーススタディは原理的可能性を示すものであり、任意の実務に対する高い成功率を証明するものではなかった。[01]
2024年には、データ取得自体をエージェント化する研究や、QGISを基盤とするGIS Copilotのような研究が現れた。分析手順だけでなく、必要な情報をどこから取得するか、既存のGIS環境にどう接続するかが対象になったのである。研究上のデモが、実務で使われるデスクトップGISや公開データ取得へ近づいた点に意味がある。[03][04]
2025年の研究アジェンダは、自律GISを単一のツールとしてではなく、機能・規模・自律性の段階を持つ研究分野として整理した。ここで重要なのは、将来像と実証済みの能力を区別することだ。大きな体系図が描かれているからといって、その全機能が実装済みであるとは限らない。概念整理の論文は、実装の不足を見つける地図として読むべきである。[02]
2026年には評価方法が具体化してきた。GeoAgentBenchは、複数領域のタスクと多数のツールを組み合わせ、実行過程や地図表現を含めて評価する。GISAgentBenchは実務者の問いに由来する課題を用い、出力の数値・属性・形状を厳しく確認する。二つは名称が似ていても、課題構成と採点法が異なる別の研究である。[09][10]
| 研究の流れ | 中心となる問い | 事業側が読むポイント |
|---|---|---|
| Autonomous GIS・LLM-Geo | 自然言語から分析を生成できるか | 成立する処理と人手の介入点 |
| データ取得エージェント | 適切なデータ源を探して取得できるか | 利用条件、更新頻度、取得失敗への対応 |
| GIS Copilot・GeoGPT系 | 既存GISの操作を支援できるか | 対象ソフト、利用できる道具、複雑タスクの制限 |
| GeoAgentBench | 多段の空間タスクをどう評価するか | 実行過程と可視化の評価設計 |
| GISAgentBench | 実務的な成果物が正確に出るか | 厳密な出力条件、見逃し、欠損、属性の整合 |
| Google地理空間推論研究 | 専門技能と計画が何を改善するか | モデル変更とシステム設計変更の寄与の切り分け |
この流れを一言でいえば、「動いた」という実演から「何が、どの条件で、どこまで正しいか」への移行である。導入側もそれに合わせ、デモの質問を少し言い換えて試すだけでなく、自社の成果物仕様を先に定義する必要がある。候補地点の一覧なら、件数、対象範囲、除外理由、根拠、再現手順を評価する。文章が滑らかであることは、そのうちの一項目にも代わらない。
04|成功率を読む。高い数字と低い数字は、そのまま競争しない
GISAgentBenchの公開本文では、349課題、128のGIS API、共通の実行枠組みと50回のツール呼び出し上限を使い、複数モデルを比較している。厳密成功率は図のとおりで、最も高い構成でも32.7%だった。これは同論文の条件での結果であり、各モデルの現在の全能力や各社製品の完成度を示すランキングではない。[10]

| モデル(論文表記) | 厳密成功率 |
|---|---|
| Gemini-3.1-Pro | 32.7% |
| Claude-4.6-Opus | 29.5% |
| DeepSeek-V4-Pro | 27.5% |
| GPT-5.4 | 22.9% |
| Qwen3.6-27B | 17.8% |
| GPT-OSS-120B | 12.3% |
349課題、128のGIS API、50回のツール呼出し上限で評価した論文v1の結果です。現在の製品全般の性能を示す数値ではありません。 出典:GISAgentBench v1 表5(2026年8月3日公開)。数値照合:2026年10月20日。
この結果から「GISの自動化は役に立たない」と結論づけるのも、「新モデルならすべて解決する」と期待するのも適切ではない。厳密な最終出力と途中までの有用性は異なる。また、自社業務を定型化し、利用データと計算手順を限定したシステムは、自由度の高い研究評価とは条件が違う。研究の低い成功率は、専門的な検証が不要になっていないことを示す材料として読むべきだ。
地図がもっともらしく見えることは、検証を難しくする。対象の一部が欠落していても、色や凡例が整っていれば気づきにくい。隣接自治体まで含めて抽出していても、縮尺によっては違和感がない。数値が小数点以下まで表示されると正確そうに見えるが、入力の観測誤差が消えるわけではない。見た目の品質と空間的・属性的な正しさを別の工程で確認する必要がある。
同論文には、座標系、境界、形状、欠損値、単位など、課題に含まれる落とし穴の分類もある。図にしたのはその出現数であり、実行時の失敗回数ではない。複数の落とし穴が一つの課題に同居するため、合計を課題数に一致させる円グラフにはしていない。こうした読み方自体が、AI関連の比較資料に必要な注意である。[10]
| 課題に付与されたタグ | 該当課題数 |
|---|---|
| 座標参照系(CRS) | 244課題 |
| 境界条件 | 180課題 |
| 形状・トポロジー | 113課題 |
| NoData | 90課題 |
| 単位 | 47課題 |
349課題に付与されたタグです。1課題に複数タグが付くため合計は課題数と一致せず、失敗件数や失敗率を示しません。 出典:GISAgentBench v1 表3(2026年8月3日公開)。数値照合:2026年10月20日。
自社評価では、正答率に加えて「誤った確信を伴う回答率」「確認すべき不明点を正しく保留した率」「人間が修正する時間」を測りたい。最終承認に一時間かかる自動分析より、十分な根拠付きで十分に絞り込まれ、十分でない案件を明示する分析の方が実務価値は高いことがある。完全自律の比率だけを目標にすると、保留すべき判断まで自動で確定する方向へ誘導しかねない。
05|Google Earth AIと、地球観測基盤モデルの役割
GoogleのGeospatial Reasoning Agent研究は、地理空間の専門技能、道具、計画を組み合わせて複雑な問いを処理する構成を示している。2026年10月11日公開の論文では、専門家による問いと参照ワークフローを使う評価と、確定的な参照出力を用いる評価を設け、道具や技能、計画の有無を比較している。単に強い言語モデルを使うだけでなく、専門処理を適切に提供する設計の効果を検討している点が重要だ。[11]
10月14日のGoogleの公式発表は、Earth AIの早期アクセスを広げ、地理空間推論の技能を独自ワークフローへ組み込む実験的なagent-to-agent APIにも言及した。ここで「実験的」「早期アクセス」という状態を落とさないことが大切である。公開発表は接続方向を示すが、誰もが同じ条件で利用できる正式な商用サービスや、あらゆる国の業務に適合した保証を意味しない。[12]
AlphaEarth Foundationsのようなモデルは、さまざまな地球観測情報を、後続の分析で使いやすい表現へ変換する。専門家が一から大量の特徴量を作る負担を減らし、土地被覆や環境などの分類・分析を支える可能性がある。だが、埋め込みを得られることと、個々の建物の設備導入判断が完成することは別である。空間解像度、観測期間、用途適合性を確認して使う必要がある。[13][14]
NASAとIBMなどによるPrithvi系の研究は、地球観測基盤モデルを、洪水・火災・農業等の解析へ適用する流れに位置づけられる。基盤モデルの出力を業務へ届けるには、対象地域のデータ処理、モデルの調整、精度評価、推論パイプラインが必要だ。モデル公開を、そのまま完成サービスの提供と読み替えてはならない。[15][16]
RingMo-Agent、EarthAgent、TerraScopeなどの研究も、それぞれ画像・時系列・空間的な根拠をどう推論に組み込むかを探っている。本調査ではこれらは主に論文要旨と公開説明を確認した。モデル名の多さを市場成熟の証拠にするのではなく、「対象は画像理解か、道具の選択か、複数段階の業務か」「成果物は文章か、ピクセルか、再現可能な解析結果か」で比較する方が有用である。[17][18][19]
本稿の見立てでは、基盤モデルの普及は、独自の画像分類器だけを持つ事業の差別化を難しくする一方、地域データを整え、観測と現地調査をつなぎ、顧客の判断に必要な誤差を管理する事業の価値を高める。将来、認識処理が安くなっても、対象が新築・改修された事実をいつ反映したか、どの資料で裏づけたかという問いは残る。そこはデータ運用と業務設計の領域である。
06|海外企業の競争地図。全員が同じ市場を狙っているわけではない
海外の動きを理解するには、自然言語インターフェースの似た画面を並べるだけでは足りない。GISの既存顧客基盤を持つ企業、クラウド上の空間計算を得意とする企業、地球観測データを保有する企業、3D都市・建設の基盤を持つ企業では、エージェントに接続する資産が異なる。何を自社の中心に残し、どこを外部のAIへ開くかに注目すると戦略が見える。
Esriは公式のArcNewsで、AIの道具とモデル、アシスタント、エージェント型の仕組みを整理している。ArcGISの中にAIを組み込む方向と、外部エージェントからGIS機能を利用する方向があるが、提供状態は機能ごとに異なる。発表には将来計画やベータも含まれるため、製品群全体を一括して「エージェント対応済み」と扱わないことが重要である。[24]
CARTO for Agentsは、CLI、Agent Skills、MCPを通じて空間分析機能をエージェントから利用する方向を打ち出した。注目点は、会話そのものより、企業のデータ基盤上の処理や既存ワークフローを呼び出せることにある。エージェントがデータを勝手に外へ持ち出して分析する設計ではなく、管理されたデータと計算の近くで作業を実行できるかが、企業導入の論点になる。[20]
Cesium ion MCP Serverの初期機能は、アセット情報やタイル化状態の確認、BIM・CAD由来の要素情報の照会など、ionのAPIを自然言語で利用する接点に位置づけられる。これを汎用GIS解析の完全自動化と同一視するべきではない。ただし、3Dアセットの取得・準備・確認という前工程が他のエージェントと接続しやすくなる意味は大きい。BentleyによるCesium買収も踏まえると、建設・インフラと地理空間をつなぐ基盤競争として読める。[25][27]
| 企業・製品群 | 主な接続資産 | 公開情報から確認できる方向 | 導入前に詰める点 |
|---|---|---|---|
| Esri / ArcGIS | GIS業務、データ、組織権限 | AI支援とエージェント連携を拡張 | 対象製品・機能ごとの提供状態 |
| CARTO for Agents | クラウドの空間分析とワークフロー | CLI・技能・MCPによる利用 | 実行権限、既存データ環境、課金単位 |
| Cesium / Bentley | 3Dアセット、BIM、インフラ情報 | ionの操作と情報照会のエージェント接続 | 対応API、書込み操作、3Dデータ更新 |
| Wherobots / HERE | 大規模空間計算と位置・経路情報 | Location Reasoningとの連携 | 規模別の費用、推論と計算の責任分界 |
| Planet | 継続的な地球観測 | 画像の問いから複合的な分析へ | 利用資格、観測条件、解析根拠 |
| NV5 GeoAgent | 地理空間の専門ワークフロー | 記録可能な業務自動化 | 公開デモと契約可能な範囲の差 |
| Mapbox | 地図、検索、経路、位置サービス | MCPとLocation AI | 対象地域、経路条件、利用上限 |
WherobotsとHEREの連携は、大規模な空間演算と位置に関する文脈を接続する動きである。地物を大量に重ね合わせる処理と、現実の移動・道路・周辺条件を理解する処理は補完関係にある。物流や施設配置では、座標だけでなく「そこへ行けるか」「どの条件なら運用できるか」が結果を左右する。会社発表の性能表現は独立した検証結果と区別しつつ、連携の方向を追う価値がある。[26]
PlanetはQueryable Earthなどを通じたエージェント型の地球観測分析を紹介している。NV5もGeoAgentとして専門処理の自動化や追跡可能性を打ち出す。いずれも既存の観測・解析資産を会話の先へつなぐ点で重要だが、公開ページだけではすべての機能の一般提供、納期、費用、業務完遂率までは確定できない。検討対象に入れることと、導入効果を計上することの間には、実データによる評価が必要である。[30][31]
07|スタートアップとオープンソースは、接続の隙間を埋める
新興企業の機会は、大企業と同じ総合GISを作ることだけではない。多次元データの扱いやすさ、処理の軽量化、共同作業、特定業務への接続など、大きな基盤の間に残る摩擦を減らす方向がある。資金調達額や企業評価額の順位は、ここでは採用しない。非公開情報や時点差が大きく、利用者にとっての機能適合性を説明しないからである。
EarthmoverはArraylakeを中心に、気候・海洋などの多次元データを扱う基盤を提供し、2026年5月にはArraylake MCPを発表している。表形式だけでは扱いにくい時空間配列を、リポジトリやスキーマを確認しながらエージェントが利用できる方向だ。気象と設備運用を組み合わせるような業務では、地図描画の前段にある多次元データ管理が重要になる。[28]
FusedはPythonの処理を地図上の表現へ素早くつなぐ仕組みを展開している。FeltとWherobotsの連携は、共同で扱いやすいGISと大規模計算を接続する例である。この二つを「自律エージェントが完成している」と分類する必要はない。エージェントが呼び出す処理や、人間が結果を確認する場を整えることも、エコシステムにとって重要な役割である。[29][32]
OpenGeosのGeoAgentは、既存の地理空間Pythonツールやデータ取得との連携を志向するオープンソースの取り組みである。研究・試作の入口として魅力がある一方、コードが公開されていることは運用保証ではない。実務では依存ライブラリ、認証情報の扱い、実行環境、テスト済みの処理範囲を確認する。特に任意コードを生成・実行する仕組みは、読み取り専用の既定ツールを呼ぶ仕組みと同じ条件で比較できない。[22]
| 事業の入り口 | 顧客の困りごと | 差別化しやすい資産 |
|---|---|---|
| データ接続 | 必要な観測や台帳にたどり着けない | 更新情報、利用権、データの意味の整理 |
| 計算接続 | 空間処理が遅い・環境が複雑 | 実行効率、再利用可能な処理、エラー復旧 |
| 共同作業 | 専門家と現場の往復が多い | 注釈、承認、比較、担当者への引き継ぎ |
| 業務特化 | 分析結果が案件化や行動に届かない | 業界条件、成果物仕様、顧客の業務データ |
| 品質保証 | 出力を信じてよいか判断できない | 参照データ、検証基準、監査履歴 |
本稿の仮説では、参入余地が大きいのは「既存の強い計算基盤を使い、顧客に必要な最後の判断資料を作る」領域である。土地の候補一覧、設備投資の優先順位、災害後の確認対象、保全作業の指示書など、成果物を狭く定義すれば検証できる。地理空間の万能チャットを最初から目指すより、顧客が毎週繰り返している具体的な判断を完了させる方が、価値と品質の両方を測りやすい。
08|日本の測量・GIS企業は、既存の強みをどう接続しているか
国際航業のGeozénに関する公開説明では、航空・衛星・3D・ハザード・統計などの情報を活用する基盤と、APIを通じた連携、開発・運用の仕組みが紹介されている。KKC Satellite Analystについても、自然言語での解析や報告を支援する方向が示される。ここで価値を持つのは、画面上のAI機能だけでなく、専門的な空間情報を業務へ供給する基盤と運用知識である。[35]
アジア航測は2026年5月18日、ALANDIS+と生成AIを組み合わせたサービスを発表した。GISの検索・集計・分析・報告に加え、マニュアル、過去の記録、法令などを参照する業務支援を組み合わせる構想が示されている。発表上は2026年10月以降の提供予定であり、本調査では実際の全面提供開始まで確認できていない。予定日が到来したことだけで、提供済みと記載しない。[36]
パスコのDXや自治体向けGISの公開情報からは、空間情報、行政業務、クラウド等の基盤が確認できる。ただし、それだけを根拠に「自律エージェントが行政業務を一貫遂行している」とは言えない。同様に、各社の既存GIS、AIによる画像解析、将来のエージェント構想は別々に評価する。既存の顧客基盤があることは有利だが、必要な製品機能の実装確認に代わるものではない。[37]
LociAIは、PLATEAU関連の公開資料でもAgentic GISに関わる取り組みが紹介される国内の注目対象である。大手のデータ資産に対して、新興企業が対話や計画、ワークフロー設計で接続する構図を考える上で参考になる。ただし、イベント登壇や紹介資料から、稼働顧客数や商用性能までは推定できない。技術の方向と商用実績は別欄で管理するべきだ。[38]
日本の測量企業が持つ強みは、単に地図データが多いことではない。測量仕様を理解し、観測条件による品質差を知り、自治体や施設管理者の業務に合わせて成果物を納めてきた経験がある。エージェント化すると、これまで担当者の判断に埋まっていた確認事項を、再利用可能なチェックや処理へ変換できる。これは人の専門性を無価値にする話ではなく、専門性を組織の資産として蓄積する話である。
逆に弱点になり得るのは、案件ごとにデータの意味や作業手順が異なり、再利用が難しいことだ。個別受託の成果物をそのまま大量に学習させれば解決するとは限らない。顧客ごとの利用権、守秘、測量条件、成果品仕様を切り分け、共通化できる部分だけを道具にする必要がある。良いエージェント基盤は、例外を無理に標準化せず、例外を専門家へ戻す経路を持つ。
09|IT大手、シンクタンク、コンサルティング会社の位置
NTTデータはデジタルツインとAIエージェントのサービスをそれぞれ展開している。公開ポートフォリオに両者があることと、特定の地理空間業務で一体化した製品が稼働していることは異なる。導入側は、共通ブランドよりも、対象データ、接続する業務、どこまで自動実行するかを案件単位で確認する必要がある。[39][77]
富士通の空間世界モデルは、現実空間の情報を構造化し、人やロボットを含む状況理解や計画につなぐ研究開発の方向を示す。日立は、AIとデジタルツインを使う安全支援などを公表している。NECのHuman Digital Twin研究も、人の状態や行動をモデル化する文脈にある。これらは地理空間エージェントと隣接するが、自治体全域のGIS業務を自律実行する製品と一括りにはできない。[40][41][42]
NVIDIA Earth-2は気象・気候のモデルと計算基盤を提供する方向にあり、Omniverse等を含む物理世界のデジタル化とも関連する。気象予測モデルは、言語モデルが自由に想像した天候を返す仕組みではない。エージェントが専門モデルを選び、その予測を設備や都市のシナリオ分析へつなぐ際の一部として理解したい。[34]
三菱総合研究所や野村総合研究所の発信は、都市デジタルツイン、物流、AIエージェントが事業や行政にどう影響するかを考える材料になる。PwCのAIを組み込むインフラ論やDeloitteのエージェント関連サービスも、組織・業務・運用への展開を重視している。ここから確認できるのは論点や支援領域であって、特定の地理空間エージェントの精度ではない。[43][44][45][46]
この市場でコンサルティング会社に求められるのは、構想図を描くだけではなく、業務ごとの価値と責任を定義することになる。たとえば「避難所の配置を最適化する」という依頼には、移動手段、時間帯、要配慮者、収容能力、道路の通行可能性、住民合意など複数の目的がある。単一の最適値にまとめる前に、何を優先し、どの不確実性を許容するかを関係者と決めなければならない。
したがって、IT大手・測量企業・自治体業務の専門家・モデル開発者が協業する場合も、役割を「AI担当」「GIS担当」と分けるだけでは不足する。データの正しさ、モデルの適用範囲、意思決定の根拠、実行の承認、運用後の効果測定を誰が受け持つかまで定める必要がある。接続できる技術が増えるほど、この分担が実装の速度と信頼性を左右する。
Trimbleの2026年8月のArc Agent発表は、サプライチェーンの手作業を安全に自動化する方向を示している。測量・建設のブランドとして知られる企業でも、エージェントの最初の対象が必ずしも地図処理とは限らない。物流や業務システムの自動化が進み、その後に位置情報と結びつく経路もある。企業の業種から機能を推測するのではなく、発表された具体的な業務を読む必要がある。[74]
10|デジタルツインの進化は、観測と行動の往復にある
デジタルツインには、対象を可視化する段階、状態を更新する段階、将来を比較する段階、運用に反映する段階がある。必ずしもすべての案件で最終段階を目指す必要はない。たとえば年に一度の施設投資計画では、常時更新より、判断に使った時点のデータを固定して再現できることが重要な場合もある。更新頻度は流行語からではなく、意思決定の周期から決める。
PLATEAUのマルチエージェントシミュレーションに関する事例は、3D都市モデルの視覚情報やLLMを用い、設定と行動・結果分析を支援する方向を示している。熊本市と豊橋市を対象とした取り組みでは、経路選択などを扱い、エージェントの行動理由を対話で確認する仕組みも説明されている。ここでのエージェントは、GISの道具を代行操作するだけでなく、シミュレーション内で行動する主体でもある。[48]
このアプローチの利点は、専門的なパラメータ設定を対話で助け、施策の違いを理解しやすくすることだ。一方、本稿の分析では、仮想の人が語る理由を、現実の住民の心理を発見した証拠として扱わないことが重要になる。もっともらしい説明を生成できても、実際の行動分布と一致しているとは限らない。観測された人流や調査データとの照合が必要である。
シンガポールURAの公開情報には、交通とエネルギーのデータを使う計画支援、EV充電に関する検討、Punggolのデジタルツインなどが紹介される。EUのDestination Earthも、大規模な地球システムのデータ・計算・シミュレーションの基盤である。これらはエージェントを載せ得る重要な土台だが、すべてがLLM主体の自律運用であると表現するのは不正確だ。[58][61]
将来の有力な姿は、観測更新をきっかけに必要な再計算だけを行い、影響の大きい変更を担当者へ届ける仕組みである。道路工事で配送経路が変わる、建物改修で屋根の候補性が変わる、降雨予測で点検優先順位が変わる。そのたびに全分析を最初からやり直すのではなく、影響する判断と根拠を追跡できることが、継続利用の価値になる。
11|MCPと標準化。接続できることと、正しく使えること
MCPの普及は、エージェントから地理空間の機能へ到達する方法を揃える上で重要である。従来はサービスごとに個別実装が必要だった接点を、共通した道具の呼び出し方で整理しやすくする。ただし、接続方式が揃っても、データの意味、計算条件、業務権限までは自動的に一致しない。MCP対応という表示だけで、業務互換性や精度保証を読み取ってはいけない。
PLATEAUのMCPドキュメントは、データのカタログや仕様、属性情報などをエージェントから参照する入口として注目される。一方、公開ドキュメントは実験的な位置づけを明示し、本番利用に適した保証を示していない。自治体や企業の重要業務に組み込むなら、実験用の接続先へ全面依存せず、利用条件を確認したデータを安定した自社処理へ取り込む構成を検討すべきである。[50]
JAXA Earth APIにもMCP Appsに関する公開チュートリアルがある。これは地球観測情報を対話型の利用へ接続する方法を学ぶ材料になるが、チュートリアルの存在と、保証付きの完成したエージェントサービスの存在は同じではない。使える観測データ、対象期間、解像度、アクセス条件を確認し、必要な品質管理を自分のシステム側で定義することが必要だ。[57][75]
STACは地理空間アセットの発見やカタログ化に使う共通構造を提供し、CityGMLは都市の地物や意味を扱うモデルを提供する。どちらも、エージェントにとって情報の発見と解釈を助ける重要な土台である。しかしSTACに登録されているから画像の品質が同じになるわけではなく、CityGMLで表現されているからすべての都市モデルが同じ詳細度になるわけでもない。標準は差を隠すものではなく、差を扱いやすくするものだ。[63][64]
OGCはDGGSとエージェント型AIを組み合わせた検証可能な意思決定について発信し、AIで利用しやすい地理空間データに関する技術文書も公開している。ここでは、技術解説・実証報告と正式な標準規格を区別して読む必要がある。将来の方向を示す文書を、すでにすべての製品が準拠すべき規範として扱ってはいけない。[62][72]
実装では、道具の説明に「何ができるか」だけでなく、「何を入力として受け付けるか」「どの座標系で返すか」「欠損時にどう応答するか」「どこまでの計算量を許すか」を含めたい。対象地域が空だったとき、ゼロ件と取得失敗を同じ結果で返すと、エージェントは誤って「該当なし」と説明してしまう。正しく失敗する設計は、うまく答える設計と同じくらい重要である。
12|日本の政策と支援策を、応募できる単位に分解する
2026年7月17日の国土交通省のPLATEAUに関する発表は、2025年度末までに329都市へ3D都市モデル整備が広がったことを示している。今後の重点には整備・更新の効率化、サービス展開、海外への展開などがある。ただし都市数は、そのまま全国すべての建物で最新かつ同じ詳細度の屋根情報が使えるという意味ではない。対象自治体と年度、データ項目を個別に確認する必要がある。[49]
PLATEAU関連補助は、一般的なAI開発費を無条件で支援する制度ではない。3D都市モデルの整備・活用等に対して区分ごとの条件が設定されている。公式案内の率と上限を、用途とともに整理すると次のようになる。ここで示すのは制度概要であり、個別事業の適格性、対象経費、受付状況まで確認した採択見込みではない。[51]
| 制度・区分 | 公式案内上の率・上限等 | 調査日時点の扱い | Geo Agent事業との接点 |
|---|---|---|---|
| PLATEAU通常型 | 補助率1/2、上限額なしの案内 | 自治体・事業要件と募集手続きを別途確認 | 都市モデル整備と活用の基盤 |
| PLATEAU早期実装タイプ・単独型 | 事業計画初年度10/10、上限1,000万円 | 対象条件の確認が必要 | 未整備地域の初期基盤 |
| PLATEAU早期実装タイプ・連携型 | 10/10、整備・更新する自治体数×1,000万円 | 連携要件等の確認が必要 | 複数自治体での共通利用 |
| PLATEAU事前復興タイプ | 10/10、上限2,000万円 | 2026年度の新設区分 | 復興計画と都市情報の活用 |
| PLATEAU民間サービス実装タイプ | 1/2以内、上限5,000万円 | 受付中とは断定しない | 都市モデルを使うサービス開発 |
| JAXA衛星データ利用システム実装加速化・追加公募 | 今回は技術開発項目Aの開発・実証が対象 | 2026年11月26日正午締切の公募中 | 衛星利用を核とする業務実装 |
| NEDO衛星データ活用コンテスト | 都市・インフラ関連、賞金総額最大8,000万円 | 応募は2026年8月31日で終了 | 参加者・成果・連携先の探索 |
JAXA宇宙戦略基金の追加公募は、2026年9月4日開始、11月26日正午締切と掲載されており、調査基準日には応募可能な期間にある。提出はe-Radで受け付ける。前回公募の情報も同じページに掲載されているため、今回対象の技術開発項目Aと、参考として掲載される別項目を取り違えないことが重要だ。金額や補助率は提案類型と要領を確認して確定する必要がある。[52]
これに対してNEDOのコンテストは、開発期間や審査が今後に続いていても応募期間は終了している。現在の事業機会は、新規応募だけでなく、採択・参加企業の動向や技術成果、共同実証先を調べることにある。「開催中」「開発期間中」「募集中」は同じ意味ではない。政策情報を営業や投資判断に使うなら、日付と状態を必ず一緒に管理したい。[53]
内閣官房の地理空間情報活用推進に関する2026年6月の資料には、次期基本計画に向けた骨子案が含まれる。骨子案を決定済みの計画と記載するべきではない。デジタル庁の地域データ連携基盤や生成AIの利活用に関する文書も、行政導入の設計条件を理解する材料になるが、それ自体が個別のGeo Agentサービスへの導入予算を保証するものではない。[54][55][56]
本稿が提案する制度の読み方は、「使えそうな補助金」を先に探すのではなく、対象業務、成果物、実証する地域、データ利用者、実装後の費用負担者を定めてから、制度の目的に照合する方法だ。補助期間の終了と同時に更新が止まるデジタルツインは、継続的な価値を持ちにくい。申請の前に、更新するデータとその費用、業務へ戻る成果物を明確にした方がよい。
13|海外政策から見える、公共データ基盤と市場形成
EUのDestination Earthは、地球システムをデジタルに表現し、気候・災害等のシナリオを扱う基盤である。ECMWF、ESA、EUMETSATが役割を分担する構成は、大規模な公共基盤が一つのAIモデルでは成立しないことを示している。データ、計算、モデル、利用者向けの接点を分けて整備する考え方は、日本の都市・国土デジタルツインにも参考になる。[58]
Horizon Europeの2026–2027年のデジタル・産業・宇宙分野の作業計画には、AIを使う高度なLocal Digital Twinsと早期警戒・備えに関する課題が掲載されている。ここから読み取れるのは、デジタルツインを危機への対応力につなぐ研究開発需要である。ただし、作業計画に項目があることと、調査時点で応募が開いていることは異なる。本稿では募集状態を未確認として扱う。[59]
英国のNational Underground Asset Registerは、地下埋設物情報を扱う公共基盤として重要である。エージェントそのものではないが、工事やインフラ管理で必要な情報を集める負担を減らす基盤が整えば、その上の業務支援を設計しやすくなる。日本の市場でも、目立つAI機能の前に、異なる管理者の情報へ適切にアクセスできるかが大きな制約になる。[60]
シンガポールの都市計画関連の取り組みは、都市情報を交通、エネルギー、建物運用へ結びつける方向を示す。都市がデータを持っているだけでなく、どの計画上の問いに使うかを具体化している点が参考になる。国土全体の制度や権限が異なるため、そのまま日本の自治体に移せるわけではないが、データ整備と意思決定の接続を同時に設計する考え方は共有できる。[61]
海外展開を考える日本企業にとっては、技術の輸出だけでなく、どのデータが取得可能で、誰が最終成果物を受け入れるかを確認することが先になる。日本で使える建物台帳や地形データが、他国で同じ粒度で得られるとは限らない。逆に、日本で蓄積した測量・防災・設備管理の手順を、現地データに合わせた検証可能な業務として提供する余地はある。
政策は市場を一度に完成させるものではない。公開データを増やす政策、実証を支える助成、継続的な調達、標準化は、それぞれ別の役割を持つ。事業者は「政府が注力している」という大きな説明で終わらせず、自社の費用構造のどこを支援が補い、どこから民間または公共の継続支出が必要になるかまで分解したい。
14|知財・特許。広い概念より、具体的な処理の組合せを見る
今回の探索では、自然言語から地理空間処理を組み立てる出願、候補地を評価する出願、複数エージェントでGIS処理を分担する中国特許、工場や電力設備のデジタルツインにエージェントを使う特許などが見つかった。以下は公開公報と書誌表示に基づく注目文献であり、全世界の特許ランドスケープを件数で網羅した結果ではない。権利の有効性や実施可能性の最終判断を行ったものでもない。
| 公開・登録番号 | 出願人等の表示 | 優先日/主な公表日 | 対象となる技術の方向 | 読み方 |
|---|---|---|---|---|
| WO2025049321A1 | X Development LLC | 優先2023-08-28/公開2025-03-06 | 目標から地理空間データと処理を組み立てる | 国際公開。各国移行を別に追う |
| US20240394296A1 | Palantir Technologies | 優先2023-05-23/公開2024-11-28 | 候補地探索、条件・容量等の評価 | 関連B2の登録表示あり。A1と登録請求項を区別 |
| CN121390817B | 浙江農林大学曁陽学院の英訳表示 | 優先2025-12-24/B公表2026-04-28 | 計画・実行・レビュー役によるGISエージェント | 中国登録文献。機械翻訳の解釈に留意 |
| JP7864275B1 | 三菱電機 | 優先2024-12-19/公表2026-05-22 | 管理エージェントと設備別ツインの連携 | 工場・設備領域に近い登録文献 |
| US20250371225A1 | Maia Water/EAOSへの名称変更表示 | 優先2024-04-22/公開2025-12-04 | 環境インフラの予測とエージェント型制御 | 公開出願。登録済みとして扱わない |
| CN119442853A | 清華大学等 | 優先2024-10-16/公開2025-02-14 | LLMと多主体による電力系統ツイン生成 | 関連B公報の登録表示を別に確認 |
出典は公報本文とGoogle Patentsの表示である。国際出願ページの状態表示が終了を示していても、国内移行したすべての権利まで消滅したことを意味しない。また、出願公開された説明の広さと、最終的に登録された請求項の範囲は一致しないことがある。番号の末尾のA1、B1、B2等を落として一覧化すると、この違いを見失う。[65][66][67][68][69][70]
独自製品を設計するときは、三つの粒度で読むとよい。一つ目は業務の目的で、候補地選定、環境予測、設備管理など何を解こうとしているか。二つ目は処理の構成で、データ選択、計画生成、実行、評価、修正がどう組み合わされるか。三つ目は請求項の要件で、具体的な実装がどこまでその要件に対応するかである。要約の類似性だけで侵害・非侵害を判断することはできない。
たとえば「計画役、実行役、レビュー役を置く」という構造は、一般的な設計論にも現れる。だからといって特定の請求項を調べずに自由実施を断定することも、その三役を置くだけですべて権利対象になると考えることも適切ではない。対象法域、優先日、登録状態、請求項、先行技術を合わせて確認する必要がある。
自社の知財戦略では、広い標語を囲い込もうとするより、現場で価値を出す具体的な改善を記録することが有益だ。観測の不確実性を業務判断へ伝える方法、更新が影響する候補だけを再評価する方法、判断保留を適切な追加調査へつなぐ方法などには、実務上の工夫が入り得る。ただし、出願可能性や権利化の見込みは本稿では評価していない。
15|最新動向を一枚で読むための時間軸
2026年の動きを並べると、研究評価、製品接続、日本の行政実装、基盤整備が同時進行していることが分かる。単一の画期的モデルが市場を突然完成させたというより、別々に成熟してきた部品をつなぐ経路が増えている。発表日と提供開始日、論文の公開日と査読状況を混ぜずに追うことが重要である。
| 時期 | 確認した動き | 意味と留保 |
|---|---|---|
| 2026年4月 | GeoAgentBenchの公開 | 評価枠組みの研究。商用品の一律保証ではない |
| 2026年5月 | CARTO for Agents、Arraylake MCP、アジア航測の発表 | 既存データ・処理への接続と業務展開 |
| 2026年7月 | PLATEAUの次の展開に関する発表 | 整備数の拡大と更新・活用への重点 |
| 2026年8月 | GISAgentBench、国内の衛星・災害情報連携等 | 厳密評価と複合観測の進展 |
| 2026年9月 | JAXA追加公募開始 | 利用システム実装への政策支援 |
| 2026年10月11日 | Googleの地理空間推論エージェント論文 | 専門技能・道具・計画の寄与を検討 |
| 2026年10月12日 | Cesium ion MCP Server発表 | 3Dアセットを外部エージェントへ接続 |
| 2026年10月14日 | Googleの実験的API、HEREとWherobotsの連携発表 | 基盤間の組合せが具体化 |
この時間軸からの独自の示唆は、製品選定を一回限りの決定にしない方がよいということだ。急速な変化に対して、すべてのモデルやAPIを追い続けるのは非効率である。データ形式、成果物仕様、評価用ケースを自社で持ち、構成要素を入れ替えたときに同じ条件で評価できる状態を作る。それが、新しい発表に振り回されず、改善を取り込む方法になる。
16|太陽光・蓄電池。地図上の候補を、投資判断へ変える
ここからは公開動向を踏まえた本稿独自の事業設計である。既存企業がすでに同じ機能を提供しているという記述ではない。最も分かりやすい例は、屋根上太陽光と蓄電池の候補探索だ。「大きな屋根を探す」処理は入口にすぎず、顧客が欲しいのは、誰に、どの条件で、どの設備を、どの順序で提案するかという判断資料である。
最初に建物を抽出し、形状や周辺の遮蔽物、用途などの利用可能な情報を確認する。次に、設置可能面積を推定する場合は、設備や離隔などの仮定を明示する。航空写真や都市モデルだけで、耐荷重、防水の状態、所有者の意向、実際の電力契約を確定できるとは限らない。これらは「AIの推論で埋める欄」ではなく、追加確認の必要性を管理する欄である。
三段階に分けると設計しやすい。第一段階は広域の粗い探索で、明らかな対象外を除き、情報が足りないものを保留する。第二段階は候補の絞り込みで、需要実績、契約条件、設備条件を取得する。第三段階は個別提案で、現地調査と専門的な計算に基づいて比較する。初期段階の推定値を、最終提案の確定値と同じ表示にしないことが大切だ。
| 判断項目 | 地理空間情報で支援できること | 別途必要になる情報 | 成果物での扱い |
|---|---|---|---|
| 屋根・敷地の候補性 | 外形、周辺環境、地形、日影の計算 | 耐荷重、改修予定、実際の使用状況 | 候補/対象外/要確認 |
| 発電の見込み | 方位・傾斜・日射・遮蔽の条件整理 | 採用設備、損失条件、設計条件 | 条件付きの予測値 |
| 自家消費の見込み | 用途や施設条件による初期分類 | 需要時系列、休日・操業、契約情報 | 実測と推定を区別 |
| 蓄電池の効果 | 立地や災害リスク等の文脈 | 負荷、制御、料金、必要な停電対策 | 複数シナリオで比較 |
| 事業性 | 候補の優先順位を組み立てる | 見積、費用、契約期間、制度適用 | 感度分析と未確定条件 |
| 実行可能性 | 関係する地域・施設を特定する | 所有、承認、工事条件、系統等 | 確認者と期限を記録 |
この業務でエージェントが担う価値は、計算式を自由に書き換えることではなく、必要な入力を集め、形式を整え、確立した計算処理へ渡し、結果を比較可能にすることにある。需要データに欠損がある、契約の期間が合わない、建物と電力使用場所の対応が曖昧である、といった前処理上の問題を早く見つけるほど、後工程のやり直しを減らせる。
国際航業の空間情報基盤と、エネがえるのような経済効果試算の業務を接続する構想は、この文脈で検討価値がある。ここで提案するのは、地理空間の探索結果を、条件が明示された試算と提案作成へ引き継ぐ設計である。本調査では両者を結ぶ特定のAPI仕様や既成の自律ワークフローの存在までは確認していないため、実装前に入力・出力・利用条件を確認する必要がある。
成功指標は、抽出した屋根の数だけではない。有望候補一件あたりの確認時間、現地調査後に対象外となった理由、提案の再作成率、顧客が次の判断をできるまでの日数を測るべきだ。大量の候補を出して営業担当者に判断を丸投げする仕組みより、少数でも根拠と不足情報が揃った候補を出す仕組みの方が、案件化を進める場合がある。
ペロブスカイトとPLATEAUを組み合わせる場合
ペロブスカイトの検討では、候補面の探索、製品ごとの発電条件、施工・構造・権利、需要と経済性を分けて扱います。Geo Agentはデータ取得や条件整理、計算の呼び出しを支援できますが、材料名だけから個別製品の性能を確定したり、画像だけから施工適合を決めたりする設計にはしません。
全体の構成はペロブスカイト・PLATEAU連携シミュレーションの開発構成、製品条件の整理はペロブスカイトの製品仕様に基づく発電量・導入効果の推計で確認できます。既存APIの標準機能と個別開発・検証が必要な部分を区別して、接続範囲を決めます。
17|公共施設とEV拠点。複数の目的を同じ地図に押し込まない
公共施設の設備更新では、単純な投資回収だけでは順位が決まらない。電力費の削減、停電時の機能維持、老朽化対応、利用者への影響、工事時期などが関係する。ここでエージェントに「最適な施設を選んで」とだけ指示すると、何を最適化したのかが曖昧なランキングを返しかねない。目的ごとの比較表と、共通して優先される候補を分けて示す方が判断しやすい。
たとえば自治体の施設群を対象にするなら、建物台帳、修繕計画、電力使用実績、避難所機能、災害想定、年度予算をつなぐ。空間情報は、災害リスクや利用圏域を理解するのに役立つ。だが、避難所として指定されていることだけで、必要な非常用電源容量が決まるわけではない。維持すべき機器、時間、運用方法を別に定義しなければならない。
この業務の成果物は、施設ごとの一枚資料と、全体の比較表がよい。各施設には、利用データの日付、主要条件、効果の範囲、未確認事項、次の担当者を載せる。全体表には、費用だけでなく工事実施の制約や、既存修繕との同時実施の可能性を載せる。エージェントはそれらを更新し、予算や計画が変わったときに比較をやり直す役割を持てる。
EV充電拠点では、交通量だけで候補を選ぶと不十分である。滞在時間、車種、到着時刻、事業者の運行計画、充電設備、受電設備、土地利用条件が関わる。幹線道路に近いことと、事業として有効な充電需要があることは同じではない。特に車両基地や配送拠点では、一般の通行量より帰庫時刻や翌日の運行条件の方が重要になることがある。
| 対象業務 | エージェントがまとめる判断材料 | 確定させる担当 | 避けたい短絡 |
|---|---|---|---|
| 公共施設の更新 | 費用、機能維持、修繕予定、立地リスク | 施設・財政・防災等の関係部署 | 回収年数だけで順位を決める |
| 避難拠点の電源 | 重要負荷、時間、燃料や設備の条件 | 施設運営者と設備専門家 | 指定避難所なら同じ仕様でよいとする |
| 物流拠点の充電 | 運行、滞在、充電、受電の制約 | 運行管理者と設備管理者 | 交通量をそのまま需要とみなす |
| 一般向け充電 | 利用圏、競合、滞在、施設特性 | 事業責任者と土地・設備関係者 | 地図上の空白を需要不足と同一視する |
ここでの独自の示唆は、最適化の前に「同時に成立しなければならない条件」と「比較して選ぶ条件」を分けることだ。安全や権限に関わる必須条件を、収益性の高さで相殺するランキングは適切でない。一方、費用と利便性のように比較できる条件は、重みを変えた複数案として見せる。エージェントが判断を一つに押しつけるのではなく、関係者が合意できる材料を作る設計が有効である。
18|防災・インフラ。最も早く分かる情報と、最も確かな情報
災害時には、衛星、現地センサー、道路情報、住民等の投稿、施設台帳など、到着時刻も信頼性も異なる情報が集まる。SpecteeとSynspectiveの公開発表は、SARの情報とSNS由来の情報を組み合わせ、浸水状況の把握を高度化する方向を示している。これは観測を補完する重要な動きだが、発表された連携だけを根拠に、避難や復旧の指示まで自律化済みとは言えない。[47]
エージェントを使う場合、最初に必要なのは「何が起きたか」の断言ではなく、どの情報が、いつ、どの範囲について届いたかの整理である。観測できなかった場所を被害なしと扱ってはいけない。古い画像と新しい投稿が食い違う場合は、取得時刻と対象地点を確認する。信頼性の異なる情報を、一つの地図の同じ色で示すと判断を誤らせる。
望ましい成果物は、確度の高い被害情報、未確認の兆候、未観測の範囲を分けた状況図と、追加確認の優先リストである。道路が通れない可能性のある場所について、確認依頼の文面や必要な資料を準備することは自動化しやすい。一方、住民への避難指示や設備停止などの重要な行為には、担当組織の判断と承認を接続する必要がある。
インフラの平時管理でも同じ考え方が使える。橋梁、道路、斜面、河川施設などについて、点検結果、変化検出、周辺災害、交通影響を組み合わせ、確認順を提案する。異常らしい変化を検出したことと、構造的な危険を確定したことは別である。専門点検の前段として、どの資料を追加で見れば判断が変わるかを示せれば、専門家の時間を有効に使える。
| 情報の状態 | 地図上の表現例 | 業務上の次の動き |
|---|---|---|
| 直接観測し、条件が明確 | 観測日時と対象範囲を明記 | 既定の判定・対応手順へ |
| 複数情報から推定 | 推定である表示と根拠のリンク | 追加照合、現地確認の検討 |
| 情報が食い違う | 相違点と時刻を並記 | 原因を確認して判断を保留 |
| 未観測・取得失敗 | 空白の理由を表示 | 追加取得または代替手段へ |
| 将来シナリオ | 前提条件と予測期間を表示 | 備えや選択肢の比較へ |
防災業務での評価は、単に処理時間が短いことでは足りない。重大な見逃し、誤報による確認負担、情報が古いまま残る時間、担当者が根拠へ到達する時間を測る必要がある。平時に過去事例で検証し、通信やデータ取得が失敗した場合の動作を確認しておくことも重要だ。非常時だけ使う特別なAIより、平時の点検とデータ更新に使い慣れた仕組みの方が、運用に定着しやすいというのが本稿の見立てである。
19|物流・不動産・自然資本。空間情報を業務の制約へ翻訳する
物流では、最短距離が最良の経路とは限らない。時間帯、車種、積載、配送順、荷受け条件、道路規制、休憩などが影響する。地図サービスの経路結果をそのまま業務指示へ渡すのではなく、運行上の制約を確かめる必要がある。HEREやMapboxのような位置サービスと、空間計算基盤や業務エージェントを接続する意義は、この制約を扱うところにある。[26][33]
エージェントの有効な役割は、条件が変わった案件を見つけ、再計算し、変更理由と影響を示すことである。「この配送が遅れそう」という通知だけでなく、どの条件が変わり、どの顧客への到着に影響するかを示す。実行前の比較案が残れば、担当者が別の選択をした場合も理由を記録できる。運行結果を戻すことで、見積もりと実績のずれも改善材料になる。
不動産や事業用地の選定では、地形、交通、災害、用途、周辺施設などの空間条件と、所有・契約・規制・事業計画を合わせる。衛星画像から広い空き地が見えることと、取得可能な土地であることは違う。候補探索の自動化は有望だが、法的な適合性や権利関係を画像から確定する設計にはしない。確認が必要な資料と担当を明示することが、次の交渉を進める。
自然資本や環境分野では、土地被覆や植生の変化を追う基盤モデルと、調査計画を作るエージェントの組合せが考えられる。GeoNatureAgentなどの研究もこの方向に関係する。ただし本調査ではその公開要旨を中心に確認しており、独自の性能検証はしていない。緑が増えたことを生物多様性の改善や炭素価値の確定と直結させず、評価方法と現地データの必要性を残すべきだ。[21]
農林業では、観測周期、雲、地形、作物や樹種、施業の違いが結果に影響する。エージェントは、対象地域で利用できる観測を探し、時系列の欠損を示し、現地確認の対象を整理する役割を持てる。高頻度に処理できるからといって、すべての変化に意味があるわけではない。季節性や観測条件の違いを、異常として大量通知しない設計が必要である。
これらの用途に共通するのは、空間情報を「場所の説明」から「業務上の制約」へ翻訳することだ。道路に近い、標高が高い、屋根が大きいという情報だけでは行動が決まらない。その特徴が、対象の事業にとってどの判断条件に対応するのかを明示する。ここに業界知識が入り、単なる地図検索との差が生まれる。
20|品質設計。エージェントに渡すべきものは、長い説明だけではない
地理空間エージェントの品質を上げるには、モデルへ詳しい指示を出すだけでは不十分である。最初に、成果物の契約を決める必要がある。対象範囲、出力の列、単位、識別子、欠損の表し方、必須の出典、許容誤差を定める。文章として「正確に分析して」と指示するより、何を満たせば正しいかを機械と人が確認できる形にする方が有効である。
たとえば候補施設の表では、一つの施設が重複して数えられないこと、対象期間に存在する施設であること、境界上の施設の扱いが決まっていることを検証する。面積では、どの座標系で計算したか、建物外形と敷地のどちらかを確認する。道路距離では直線距離と経路距離を混同しない。単純に見える確認項目を省略すると、もっともらしい結果が大量に生まれる。
データは最低限、観測、推定、シナリオの三種類に分けたい。観測は何らかの方法で捉えた状態であり、それでも誤差と時点を持つ。推定は観測等から導いた判断で、モデルや条件に依存する。シナリオは仮定を変えた将来像であり、起きることが確定した未来ではない。これらを同じ色、同じ精度表示、同じ断定表現で並べないことが、利用者の理解を助ける。
出典の管理もURLを一つ付けるだけでは足りない。対象データの版、取得日、対象期間、処理条件、計算コードや道具の版を残す。更新されたときに、過去の結論がどの入力に依存していたかが分かることが重要だ。結果だけをPDFで残しても、なぜそうなったかを再現できなければ、継続運用では同じ調査を何度もやり直すことになる。
| 品質の層 | 確認すること | 記録するもの |
|---|---|---|
| 入力 | 範囲、期間、利用権、欠損、座標系 | 取得元、版、観測時点、前処理 |
| 処理 | 単位、条件、再試行、計算上限 | 道具、引数、実行結果、エラー |
| 成果物 | 件数、形状、属性、根拠、保留 | 検証結果と修正履歴 |
| 判断 | 目的に合うか、未確認事項が残るか | 承認者、理由、適用範囲 |
| 運用 | 更新、実績との差、問い合わせ | 再計算条件、効果、例外の対応 |
エージェントが参照する資料には、内容としての文章と、実行すべき命令を混ぜない設計も必要になる。外部資料に書かれた指示をそのまま業務上の命令として受け入れず、実行可能な道具と権限をシステム側で限定する。これは地理空間特有の問題ではないが、データ取得から外部への通知までを一つのエージェントが扱う場合に特に重要になる。
最後に、品質管理は例外をすべて人へ返すだけでは成立しない。どの条件なら自動で進み、どの条件なら再取得し、どの条件なら専門家へ渡すかを決める。保留理由が構造化されていれば、足りないデータの購入、現地調査、処理改善のどれに費用を使うべきかも見える。品質の記録は、運用負担であると同時に、製品を改善するための情報になる。
21|経済性は、処理単価より「人の確認時間」で変わる
エージェント導入の費用対効果を、モデルの利用料金だけで説明するのは不十分である。データの取得・整備、空間計算、外部API、品質確認、運用対応、成果物の修正が費用になる。一方、効果には作業時間の削減だけでなく、提案の早期化、調査対象の絞り込み、判断のやり直しの減少がある。どれを金額化し、どれを運用指標として追うかを分ける必要がある。
以下は市場価格や実績を示すものではなく、計算の構造を明らかにするための仮想例である。毎月100件の調査があり、従来は一件2時間、人の時間価値を4,000円と仮定する。導入後の案件別作業が一件30分になり、それとは別に月20時間の横断的な品質確認を行うとする。システム・データ等の運用費は月20万円、初期費用は96万円と置く。
この条件なら、案件別作業の削減は月150時間で60万円相当となる。そこから横断的な品質確認の8万円と月額運用費20万円を引くと、月32万円相当の効果になる。初期費用の回収は単純計算で3か月である。ただし、人の時間が空いたことは、そのまま現金支出が減ることではない。余力を追加案件へ使えるか、残業や外注を減らせるかで、実際の経済効果は異なる。

| 導入後の案件別作業時間 | 案件別の時間削減価値/月 | 追加品質確認+運用費/月 | 差引の効果/月 |
|---|---|---|---|
| 30分/件 | 60万円 | 28万円 | 32万円 |
| 45分/件 | 50万円 | 28万円 | 22万円 |
| 60分/件 | 40万円 | 28万円 | 12万円 |
| 90分/件 | 20万円 | 28万円 | −8万円 |
この例が示すのは、推論料金が多少下がることより、人間が結果を確認・修正する時間が減る方が経済性に大きく効く場合があるということだ。説明や出典のない出力を高速に大量生成しても、人が一件ずつ検証し直すなら利益は残らない。逆に、必要な根拠と保留理由が揃っていれば、処理自体に数分余計にかかっても、全体の価値が高くなることがある。
広域探索では、すべての候補に高価な解析をかける設計も避けたい。粗い条件で一次整理し、有望または不確実な対象にだけ詳細データや専門計算を使う。追加情報の費用に対して、その情報で意思決定がどれほど変わるかを考える。これは単純に低コストなデータを選ぶ話ではなく、必要な精度を必要な段階で得る設計である。
価格設計も成果物に合わせる。利用者席数、処理回数、対象面積、監視する施設数、完成した調査件数など、複数の課金単位が考えられる。顧客が欲しいものが毎月の候補地レポートなら、チャットの回数に対する価格は理解されにくい。更新を含む継続サービスなら、対象資産と更新頻度、確認の責任範囲を明確にした方が価値を説明しやすい。
22|誰が利益を得るか。産業構造を五つの役割で読む
市場を「AI企業対GIS企業」という二者対立で見ると、重要な役割を見落とす。観測や台帳を供給する主体、計算基盤を提供する主体、業務の処理を組み立てる主体、品質を確認する主体、顧客に成果物を届けて運用する主体がいる。一社が複数を担うことも、別会社が連携することもある。利益の所在は、顧客の判断をどこが支配するかによって変わる。
| 役割 | 提供する価値 | 蓄積される資産 | 競争上の課題 |
|---|---|---|---|
| 観測・データ提供 | 現実の状態を信頼できる形で供給 | 時系列、精度管理、取得権、地域網羅性 | 一般データとの差、更新費用 |
| 計算・基盤提供 | 大量処理と安定した接続 | 性能、互換性、運用、組織権限 | 代替可能性、利用費の透明性 |
| 業務設計 | 目的を再現可能な処理へ変換 | 専門手順、例外処理、入出力仕様 | 個別対応の増大、再利用性 |
| 検証・保証 | 判断に必要な品質を確かめる | 参照データ、検証規則、修正履歴 | 責任範囲、確認コスト |
| 成果物・運用提供 | 顧客が次の行動を取れる状態にする | 業務接点、継続更新、実績フィードバック | 顧客ごとの差、継続収益 |
本稿の仮説では、一般的な「地図への質問」だけでは差別化が続きにくくなる。基盤側が自然言語インターフェースを広げるほど、同様の機能を小規模に再実装する価値は低下するからだ。一方、顧客の台帳や契約情報、現場の確認方法、意思決定の手順へ深くつながる業務は、単にモデルを入れ替えても完成しない。そこに専門企業の機会がある。
ただし、データを持つだけで優位が保証されるわけでもない。データが古い、意味が説明されていない、利用許諾が複雑、更新が属人的、といった状態ではエージェントから使いにくい。データ資産を競争力に変えるには、機械が取得でき、人が根拠を追え、変更時の影響が分かる形に整える必要がある。データカタログの整備は、裏方の仕事であると同時に商品開発になる。
測量・コンサルティング企業にとって、受託業務から継続型サービスへ進む際の鍵は、成果物の繰り返し更新である。初回に地域の候補を抽出し、その後は建物、道路、災害、制度、料金等の変化に応じて再評価する。更新イベントが顧客の行動とつながるなら、単発の地図作成とは異なる価値になる。ただし、何でも監視するのではなく、判断を変える可能性のある変化に絞るべきだ。
スタートアップと大企業の協業では、営業網を借りるだけでなく、検証用の実案件と専門家の修正を共有できるかが重要になる。基盤企業が道具を提供し、専門企業が業務仕様を持ち、新興企業が接続と利用体験を作る構成も考えられる。契約上は、改善に使えるデータの範囲、成果物の権利、顧客への説明責任、運用停止時の引き継ぎを事前に整理したい。
23|90日で検証する。小さな実装を、事業の判断材料にする
以下の90日計画は、本稿の提案であり、各社の標準導入期間ではない。狙いは万能なエージェントを完成させることではなく、特定の業務で品質と経済性が成立するかを判断できる状態にすることだ。最初の案件は、成果物が明確で、既存の人手の結果と比較でき、失敗した場合に戻せる業務を選ぶとよい。
最初の二週間では、対象業務と完了条件を定義する。候補施設の一次調査なら、最終出力の列、必要な根拠、保留条件、確認者を決める。過去案件から例題を集め、正解が一つでない場合は許容範囲と評価基準を定める。担当者が普段どの資料を見て、どこで迷い、何分使っているかを記録する。ここを省くと、導入後に何が改善したか分からない。
第三週から第四週では、データ取得と既定の空間処理を整える。まずはエージェントの自由度を抑え、再現できる道具を用意する。座標系や単位、欠損の扱いをそろえ、対象外のデータを処理しようとした場合は理由付きで停止する。ここで必要なデータが得られないと分かれば、モデルを高度化する前に業務範囲を変更する。
第五週から第六週では、エージェントに計画と道具の選択を担わせ、既存の成果物と並べて比較する。たとえば30件の過去案件を使うことは一つの開始案になるが、十分な統計的保証を与える件数ではない。代表的な正常例だけでなく、境界上の対象、欠損、古いデータ、対象が存在しない例を含める。失敗を見つけるための評価であることを関係者と共有する。
第七週から第八週では、実際の担当者が結果を確認し、修正時間を測る。エージェントが返した説明が、担当者の判断を本当に助けるかを見る。情報が多すぎる、根拠へ移動しにくい、保留理由が曖昧、といった問題はモデル精度以外にある。出力形式を変えるだけで確認時間が減ることもあるため、画面や資料を品質評価の対象に含める。
第九週から第十二週では、限定した実案件で並行運用する。従来の手順を参照しながら、更新、エラー、担当者交代に耐えられるか確認する。正式運用へ進む条件は、成功率だけでなく、重大な誤り、保留の妥当性、確認時間、費用、業務責任の明確さで決める。条件を満たさないなら、対象業務を絞る、データを改善する、エージェントを使わない固定処理へ戻すという選択も合理的である。
| 段階 | 残すべき成果物 | 次へ進む判断 |
|---|---|---|
| 業務定義 | 成果物仕様、現状の所要時間、代表ケース | 比較できる基準があるか |
| データ・道具整備 | データ一覧、既定処理、失敗時の応答 | 再現可能に処理できるか |
| 試作評価 | ケース別の結果と誤り分類 | 誤りの原因を説明できるか |
| 担当者評価 | 確認・修正時間、保留の扱い | 現場の負担が減るか |
| 並行運用 | 費用、更新、障害、責任分担の記録 | 継続提供が成立するか |
この計画で重要なのは、成功例の動画より、失敗を分類した表が資産になることだ。取得できない、条件を誤解した、処理が失敗した、出力仕様を満たさない、説明が不十分という分類があれば、改善すべき層が分かる。原因がデータ不足なのにモデルを交換し続けると、時間と費用を浪費する。七層の構成図を評価の分類にも使うと、議論が具体的になる。
24|調達・提携・投資で、確認すべき十の問い
第一の問いは、何をもって完了とするかである。「自然言語で分析できます」という説明では、地図が出るのか、正しい表が出るのか、顧客への提出物まで完成するのかが分からない。実際の成果物を一つ見せてもらい、その根拠と再実行手順を確認する。対象業務に必要な列や条件が欠けていれば、対話が滑らかでも完成とはいえない。
第二は、データの時点と権利である。どの版を使い、いつ更新し、派生成果物を誰に提供できるかを確認する。第三は、計算と生成の分担である。面積、距離、需要、費用などを何が計算し、LLMがどこで関与するのかを聞く。第四は、失敗時の挙動である。データがない、APIが停止した、条件が矛盾する場合の実際の応答を確認する。
第五は、評価の条件である。成功率の分母、課題の選び方、許容誤差、再試行、専門家の介入を確認する。第六は、人の確認時間である。自動処理時間だけではなく、担当者が最終的に使える状態にするまでを測る。第七は、権限と承認である。閲覧、作成、更新、外部送信、設備操作を区別し、どの操作が誰の責任で実行されるかを見る。
第八は、運用の持続性である。基盤モデル、外部API、データ提供者が変わった場合に、同じ評価を繰り返せるかを聞く。第九は、成果物と履歴の持ち出しやすさである。契約を終了しても、判断に使った根拠と結果を保持できるか確認する。第十は、改善の仕組みである。専門家の修正を次回へ反映するとき、誤った修正や顧客間の情報混入をどう防ぐかを確認する。
これらは製品に欠点を探すためだけの質問ではない。提携相手の強みを見つけ、役割を分担するための質問でもある。優れた計算基盤に、自社の専門手順を接続する方が早い場合がある。逆に、業務の出力がまだ定義できない段階で大型の基盤契約をしても、価値が出るとは限らない。調達の順序も、業務の不確実性に合わせて決めたい。
製品の成熟度は、次の五つに分けると混乱が減る。概念・将来計画、研究試作、限定公開・ベータ、商用の特定機能、運用実績が確認できる業務全体である。この順序は企業の優劣ではない。同じ企業の中でも機能ごとに段階が違う。商用契約が可能な機能でも、自社の業務全体を完遂できるかは別途検証する必要がある。
本調査で未確定として残した事項には、各製品の個別契約価格、利用制限の詳細、顧客環境での実測性能、一般提供の正確な開始状況、非公開の導入実績、特許の各国での最終的な権利状態がある。これらを推定で埋めず、次の調達・提携調査の質問へ変える。広い探索の価値は、すべてを知ったように見せることではなく、次に何を確認すれば意思決定できるかを明確にすることにある。
25|2027年以降を考える。三つのシナリオと、日本の勝ち筋
将来を一つの予測にまとめるより、条件の異なる三つのシナリオを考える方が行動に役立つ。第一は、既存GISやクラウド基盤にエージェント機能が広く内蔵されるシナリオである。この場合、一般的な地図検索や単純処理の会話化は標準機能へ近づく。独立した事業者は、固有のデータ、業界の判断条件、成果物の品質へ差別化を移す必要がある。
第二は、接続は増えるが、業務の品質確認と責任がボトルネックとして残るシナリオである。この場合、専門家が確認した成果物を継続的に届けるサービスや、評価・監査・データ整備を担う事業が重要になる。人を介さないことを最優先にせず、人の確認が必要な部分を絞る設計が価値を持つ。測量、建設、防災、エネルギーの専門知識を持つ企業に機会がある。
第三は、都市・設備・交通などのデジタルツインが運用と深く結びつき、状態変化から再計算、承認、実行までの循環が普及するシナリオである。その場合は、一度の回答より、継続的な更新と実績の比較が価値になる。ただし、これはデータ連携、モデルの妥当性、現場権限、運用費用がそろうことを条件とする。3D表示やエージェントAPIの増加だけで自然に実現するわけではない。
三つのシナリオに共通して有効なのは、データの意味と時点を整え、専門手順を再利用可能にし、成果物を検証できる状態にすることだ。モデルが変わっても残る資産を先に作る。特定のモデル名や流行の用語を商品価値の中心に据えるより、どの判断をどれだけ早く、確かに、継続して支援できるかを説明する方が長期的に強い。
日本の地理空間企業には、都市モデル、測量、災害対応、施設管理、行政の業務仕様など、現実に結びつく知識がある。課題は、それを案件ごとの個別作業から、接続・再利用・更新できる業務へ変換することだ。新興企業が持つ柔軟な開発、基盤企業の計算、専門企業の検証を組み合わせれば、単独で万能なシステムを作る必要はない。
その中でも、再生可能エネルギー、公共施設、インフラ保全、防災のように、場所と経済性・物理制約・制度が交わる領域は重要である。ここでは地図だけでも、一般的な対話AIだけでも、判断に届かない。必要な情報を集め、不明点を残し、専門計算を通し、関係者が次の行動を選べる形で返す。その一連の仕事を商品として定義できるかが問われる。
Geo Agentの進歩を測る基準は、会話の自然さや呼び出せるツールの数だけではない。ある場所についての問いが、根拠のある比較に変わり、確認すべき点が明らかになり、実行後の結果まで学び直せるか。空間情報の産業が提供する価値は、その判断の質と速度を高めるところまで広がっている。
調査方法と、この記事の使い方
調査では、Geo Agent、Agentic GIS、Autonomous GIS、geospatial reasoning、agentic digital twin等を起点に、英語・日本語の研究論文、企業公式発表、開発者文書、官公庁資料、公開特許へ探索を広げた。中国の関連特許は英語表示を含む公開公報で確認した。研究、サービス、データ基盤、政策、知財を別々に集めた後、業務の入出力と検証の観点で比較した。
情報の基準日は2026年10月19日日本時間である。論文の版、製品の提供状態、制度の受付状況は変化する。本文では、とくに発表と一般提供、応募期間と事業期間、公開出願と登録を区別した。原資料で確認できる数値だけを事実として扱い、経済性の試算や90日計画は本稿の仮定・提案として明示した。異なる研究の成功率を一つのランキングに混ぜていない。
巻末は参照資料への入口であり、原文を大量転載するものではない。確認範囲は、本文の関連箇所まで確認した資料、要旨・公式概要を確認した資料、関連する追加資料に分けている。収集したすべてのウェブページが同じ深さで読めたわけではない。本文の主張を超える詳細仕様や採択要件を確定するときは、該当する原資料へ戻る必要がある。
最初の実務は、対象業務を一つ選び、現在の成果物と所要時間、必要なデータ、不明点を一枚にまとめることです。その一枚があれば、技術の選定と提携の議論を具体化できます。
Geo Agent・Agentic GISを理解するためのQ&A
Geo AgentとGeoAIはどう違いますか?
GeoAIは地理空間情報にAIを適用する広い領域です。Geo Agentは、その中でも目的に応じて道具を選び、複数の処理を実行し、結果を確認する仕組みを指します。画像分類モデルだけを、業務全体を遂行するエージェントと同じ能力だとは扱いません。
Agentic GISはGIS担当者の確認を不要にしますか?
対象業務と構成によります。座標系、単位、対象範囲、欠損、属性の不整合が成果物に影響するため、完了条件と検証方法を決めます。成功率だけでなく、担当者の確認・修正時間と、適切に判断を保留できるかを測ることが重要です。
PLATEAUから太陽光の導入可否を自動確定できますか?
3D都市モデルは候補面や周辺条件の解析を支援しますが、耐荷重、防水状態、所有者の意向、需要実績などをすべて確定するものではありません。候補、対象外、追加確認が必要な対象を分け、現地調査と専門計算へ引き継ぎます。
ペロブスカイトの試算は標準APIだけで完結しますか?
製品固有の性能、設置条件、供給段階、入力・計算の境界を確認する必要があります。PLATEAU解析やペロブスカイト専用モデルが標準APIに自動的に含まれるとは扱わず、既存APIと個別開発・検証の範囲を案件ごとに整理します。
参照資料・追加探索資料
本文の出典番号から各資料へ移動できます。確認範囲は資料ごとに明記しました。企業の効果説明は独立検証と区別し、特許の法的状態は各国の公式原簿での最終確認を別途要します。
確認範囲:要旨
確認範囲:要旨・本文関連箇所
確認範囲:要旨
確認範囲:要旨
確認範囲:書誌・概要
確認範囲:書誌・概要
確認範囲:要旨
確認範囲:書誌・概要
確認範囲:要旨・評価概要
確認範囲:本文・実験条件・表5等
Google Geospatial Reasoning Agent
確認範囲:要旨・評価概要
確認範囲:本文のEarth AI関連箇所
確認範囲:要旨
確認範囲:公式概要・利用条件の案内
確認範囲:要旨
NASA Prithvi Geospatial Model Applications
確認範囲:公式概要
確認範囲:要旨
確認範囲:要旨・公開プロジェクト案内
確認範囲:要旨
確認範囲:本文関連箇所
確認範囲:要旨のみ
確認範囲:リポジトリ公開説明・実行未検証
確認範囲:公式登録情報
Esri:The Next Era of AI and ArcGIS
確認範囲:本文関連箇所
確認範囲:本文・初期機能と権限
確認範囲:本文関連箇所
確認範囲:公式概要
確認範囲:本文・概要
確認範囲:公式概要
確認範囲:公式概要
確認範囲:本文関連箇所
確認範囲:公式概要
確認範囲:公式概要
確認範囲:公式概要
確認範囲:本文関連箇所
確認範囲:本文・提供予定の記載
確認範囲:公式概要
確認範囲:公開記事概要
確認範囲:サービス概要
確認範囲:公式概要
確認範囲:公式概要
確認範囲:研究紹介概要
確認範囲:公開記事概要
確認範囲:公開記事概要
確認範囲:公式概要
確認範囲:サービス概要
確認範囲:公式概要
確認範囲:本文・構成・対象地域
確認範囲:本文・整備都市数
確認範囲:本文・実験的提供の条件
確認範囲:本文・率と上限。個別要領は未審査
確認範囲:本文・対象区分・締切
確認範囲:本文・賞金と応募日程
確認範囲:公式資料概要・骨子案の位置づけ
確認範囲:公式概要
確認範囲:公式概要
確認範囲:公式概要。MCP教材は資料75
確認範囲:政策概要
Horizon Europe:Digital, Industry and Space作業計画
確認範囲:対象課題の索引・概要。受付状況未確認
National Underground Asset Register
確認範囲:公式概要
確認範囲:本文・公式概要
確認範囲:本文関連箇所。技術論考
確認範囲:公式概要
確認範囲:公式規格概要
WO2025049321A1 — X Development
確認範囲:公報本文・書誌表示
確認範囲:公報本文・書誌・関連B2表示
CN121390817B — GIS multi-agent
確認範囲:公報本文・書誌表示・英訳
確認範囲:公報本文・請求項・書誌表示
US20250371225A1 — Environmental infrastructure
確認範囲:公報概要・書誌表示
確認範囲:公報概要・書誌・関連B表示
Earth AI:Foundation Models and Cross-Modal Reasoning
確認範囲:要旨・補足探索資料
OGC AI-ready geospatial data技術文書
確認範囲:技術文書概要・正式標準とは区別
Custom Satellite Embeddings powered by AlphaEarth
確認範囲:公式概要・限定提供の案内
確認範囲:公式概要
JAXA Earth API MCP Appsチュートリアル
確認範囲:公開教材概要・実行未検証
確認範囲:公開資料概要・補足探索資料
確認範囲:サービス概要
NASA Prithvi operational-readiness関連資料
確認範囲:公開要旨・補足探索資料













コメント