地理空間データ配布形式に関する勧告AN ADVISORY ON GEOSPATIAL DISTRIBUTION FORMATS

KMLでの配布、
もうやめませんか。 It's time to stop
shipping KML.

2027年6月25日、Google Earth Pro デスクトップ版の配布が終了します。20年にわたり「開けるけれど、データとして使えない」地理データの形を定着させたツールは、以後更新されないまま現場に残ります。データを配る形式としてのKMLを、ここで引退させましょう。 On June 25, 2027, Google Earth Pro for desktop will no longer be available for download. The tool that spent two decades normalizing geodata that opens fine but can't be used as data will remain in the field, never to be updated again. Let's retire KML as a distribution format.

Google Earth Pro デスクトップ版　配布終了まで Until Google Earth Pro desktop downloads end

— 日（2027年6月25日） days (June 25, 2027)

30秒でわかる問題へThe problem in 30 seconds 今日からできることWhat you can do today

第一条ARTICLE 1

30秒でわかる、KMLの問題The problem, in 30 seconds

名簿を作るとき、「名前」「住所」「電話番号」は別々の列に分けます。

ところが、世の中に流通するKMLファイルの多くは、これを全部1つのセルに、文字色や罫線ごと貼り付けた状態になっています。

人間がクリックして読む分には問題ありません。しかし——

住所で並べ替える → できない
営業時間で絞り込む → できない
電話番号の一覧を作る → できない

これをやるには、貼り付けられたHTMLを解読する専用プログラムをファイルごとに書くことになります。地図データの価値の半分は位置情報、もう半分は属性情報です。KMLの流通慣習は、後者を事実上封印した状態でデータを世界に広めてきました。

When you build a contact list, names, addresses and phone numbers go in separate columns.

Most KML files in circulation are the equivalent of pasting all of that into one cell — colors, table borders and all.

Fine for a human clicking a pin. But —

Sort by address? No.
Filter by opening hours? No.
Extract the phone numbers? No.

Doing any of that means writing a custom HTML parser, per file. Half the value of geodata is the location; the other half is the attributes. The KML ecosystem has spent twenty years shipping data with that second half sealed shut.

第二条ARTICLE 2

実物を見てくださいSee it for yourself

自治体オープンデータの実物Real municipal open data

三重県伊勢市がオープンデータとして公式配布しているKML「観光案内所・手荷物預かり所」の実物です（2026年7月10日取得[1]）。市内6か所の案内所の住所・開所時間・電話番号という、本来3列で済む属性データが、各地点の description にHTMLの表として焼き込まれています。 This is real open data, officially published as KML by the city of Ise, Japan (retrieved July 10, 2026 [1]): six tourist information desks, each with an address, opening hours and a phone number. Three columns of data — baked into each placemark's description as an HTML table, inline color styling included.

BEFORE ─ 配布されている実物（1地点分）─ as actually published (one placemark)

<Placemark>
  <name>伊勢市駅観光案内所</name>
  <description><![CDATA[<table><tr>
    <td style="color:#0000FF;padding-right:1em;">住所</td>
    <td>伊勢市吹上1丁目1番4号</td></tr><tr>
    <td style="color:#0000FF;padding-right:1em;">開所時間</td>
    <td>午前9時から午後5時30分<br/> （年中無休）</td></tr><tr>
    <td style="color:#0000FF;padding-right:1em;">電話番号</td>
    <td>0596-65-6091</td></tr></table>]]></description>
  <styleUrl>#SYMBOL2.symbolStyle</styleUrl>
  <Point><coordinates>136.709452271461,34.4911537946984</coordinates></Point>
</Placemark>

住所・開所時間・電話番号は、機械から見れば「文字色 #0000FF 指定付きのHTML文字列」の一部でしかありません。KML仕様には属性を構造化して持つ ExtendedData が定義されていますが[6]、このファイルでは一切使われていません。 To a machine, the address, hours and phone number are just fragments of an HTML string with color:#0000FF styling. The KML spec defines ExtendedData for structured attributes [6]; this file never uses it.

QGISの属性テーブル。descriptionの列に、住所などのデータが<table><tr><td style="color:#0000FF">といったHTMLの塊のまま表示されている。idとtimestampの列はすべてNULL。 — 同じ伊勢市KMLを、専門GISソフト QGIS で読み込んだ属性テーブル。**KMLは正しく読み込めています**——地物6件が地図に表示され、位置も正確です。しかし属性テーブルを見ると、住所・開所時間・電話番号は `description` という1列に、`<table><tr><td style="color:#0000FF...">` というHTMLの塊のまま押し込まれています。`id` も `timestamp` も `NULL`。**「開ける」ことと「データとして使える」ことは、まったく別です。**住所で並べ替えることも、電話番号だけを抜き出すことも、この状態ではできません。 The same Ise City KML, loaded into QGIS, professional GIS software. **The KML loads correctly** — all six features appear on the map, positioned accurately. But look at the attribute table: address, hours and phone number are all crammed into a single `description` column as raw HTML — `<table><tr><td style="color:#0000FF...">` — while `id` and `timestamp` are `NULL`. **"It opens" and "it's usable as data" are two entirely different things.** You cannot sort by address, or pull out just the phone numbers, from this.

AFTER ─ 同じデータの本来の姿（GeoJSON）─ the same data as it should be (GeoJSON)

{
  "type": "Feature",
  "geometry": { "type": "Point",
    "coordinates": [136.709452271461, 34.4911537946984] },
  "properties": {
    "name":    "伊勢市駅観光案内所",
    "address": "伊勢市吹上1丁目1番4号",
    "hours":   "午前9時から午後5時30分（年中無休）",
    "phone":   "0596-65-6091"
  }
}

このAfterは、Beforeのdescription内HTMLを解析する専用パーサを書いて生成しました。逆方向（GeoJSON→KML）は既存ツールの1コマンドで済みます。この非対称性が、本サイトの主張のすべてです。 Producing this "After" required writing a custom parser for the description HTML. The reverse direction is a one-line command with standard tools. That asymmetry is this site's entire argument.

上記サンプルの出典: 「観光案内所・手荷物預かり所（MapData）」、伊勢市、CC BY 4.0（改変: 抜粋・GeoJSON変換は本サイトによる）。伊勢市オープンデータ利用規約[16]に基づく表記です。 Sample source: "Tourist Information Desks & Baggage Storage (MapData)", Ise City, CC BY 4.0 (modifications — excerpting and GeoJSON conversion — by this site), credited per the Ise City Open Data Terms of Use [16].

マイマップからエクスポートされるKMLの問題点What My Maps actually exports

「昔の話では？」という疑問に答えるため、2022年・2024年・2025年に作られた3つのGoogleマイマップから書き出したKMLを実際に解析しました[15]。3つともXMLとしては妥当です——壊れたファイルではありません。しかし「データとして使えるか」で見ると、制作年ごとにバラバラの欠陥が現れました。

属性がまるごと消える。 あるファイル（69地点）は、地点名以外の属性が一切ありませんでした。description も ExtendedData も空。マイマップ上で入力していたはずの説明やカテゴリは、この出力には残っていません。
座標がまるごと消える。 別のファイル（47地点）は、47件すべてに座標（<Point>）がありませんでした。持っているのは住所文字列だけで、このKMLを地理院地図やQGISで開いても地図上に何も表示されません。住所ピンで作った地図をエクスポートすると座標が落ちる、という落とし穴です。
同じ情報が二重に格納される。 属性が ExtendedData で構造化されているファイルでも、まったく同じ内容が description 欄にHTML（団体コード: … <br> 都道府県名: …）として重複して書き込まれていました。この二重格納は複数のファイルで共通して確認できました。
取り込み元の生データが整理されずに氾濫する。 OpenStreetMap由来のデータを取り込んだファイルでは、@id・addr:country・wikidata など約110種類のキーがそのまま流入し、地点名は過半数が空、ファイルは約6MBに膨張していました。これはマイマップのインポート上限（5MB）を超えており、そのファイルをマイマップに戻すことすらできません。

部分的な改善（構造化属性 ExtendedData の採用など）はあります。しかし「開けるが、そのままではデータとして使えない」出力が、年をまたいで形を変えながら続いています。どの年のエクスポートが安全かを利用者が事前に知る方法はありません。

To answer "isn't this old news?": we analyzed the KML exported from three different Google My Maps, made in 2022, 2024 and 2025 [15]. All three are valid XML — not broken files. But judged as usable data, each year produced a different defect.

The attributes vanish entirely. One file (69 placemarks) had no attributes beyond the place name — both description and ExtendedData were empty. Whatever notes or categories were entered in My Maps are simply gone from this export.
The coordinates vanish entirely. Another file (47 placemarks) had no geometry at all — not one <Point>. It carried only address strings, so opening this KML in GSI Maps or QGIS shows nothing on the map. Export a map built from address pins, and the coordinates fall out.
The same information is stored twice. Even in files where attributes are properly structured in ExtendedData, the identical content is duplicated into the description field as HTML (Code: … <br> Prefecture: …). This double-storage appeared across multiple files.
Imported raw data floods in unorganized. A file built from OpenStreetMap data carried roughly 110 raw keys straight through — @id, addr:country, wikidata and the like — with over half the placemarks unnamed, ballooning to about 6 MB. That exceeds My Maps' own 5 MB import limit, meaning the file cannot even be loaded back into My Maps.

There are partial improvements (the adoption of structured ExtendedData, for one). But output that "opens yet can't be used as data as-is" persists, changing shape from year to year. Users have no way to know in advance which year's export is safe.

第三条ARTICLE 3

誰がこの慣習を作ったかWho built this convention

「フォーマットに罪はない、使い方の問題だ」という反論には、時系列で答えます。 To the objection "the format is fine, usage is the problem" — a timeline.

2004

GoogleがKeyhole社を買収し、KMLはGoogleの管理下に入る。Google acquires Keyhole; KML becomes Google's format.

2008

GoogleがKML 2.2をOGC（地理空間情報の国際標準化団体）に提出し、国際標準となる[7]。この仕様には属性を構造化して持つ ExtendedData（型なしData、型付きSchema/SchemaData）が定義されている。書いたのはGoogle自身。Google submits KML 2.2 to the OGC and it becomes an international standard [7]. The spec defines ExtendedData — untyped Data pairs and typed Schema/SchemaData — for structured attributes. Written by Google.

2008–現在present

Google公式ドキュメントは現在も「Google Earthはこの型付き情報を使用しない」と明記している[6]。Google Earth・マイマップという世界最大のKML生成環境は、属性をdescriptionのHTMLとして出力する形を標準にした。Google's own documentation still states that Google Earth does not use the typed information [6]. Google Earth and My Maps — the largest KML-producing environment on the planet — standardized emitting attributes as description HTML instead.

2026.7.7

Googleがデスクトップ版の配布終了（2027年6月25日）を発表[3]。このソフトウェアが更新される可能性は公式になくなった。Google announces the end of desktop downloads (June 25, 2027) [3]. The probability of this software ever being fixed is now officially zero.

仕様に正しい方法を定義したのはGoogleであり、それを自社の主要製品で採用しなかったのもGoogleです。標準の起草者が自らの標準の構造化機構を実装しないまま20年が経過したとき、流通するファイルの品質を「利用者の運用」に帰責するのは妥当ではありません。 Google defined the correct mechanism, and Google declined to adopt it in its own flagship products. After twenty years of that, attributing the quality of circulating files to "user error" is not a serious position.

第四条ARTICLE 4

事例ファイルCase files

自治体オープンデータの標準形になっているThe default shape of municipal open data

本サイトのメインサンプル（第二条）は、伊勢市が公式に配布しているオープンデータそのものです。市はさらに、KMLの利用方法としてGoogleマイマップへのインポート手順を公式ページで案内しています[2]。これは職員の落ち度ではありません。無料で導入しやすいツールを選び、市民に説明しやすい手順を整備した——行政として合理的な判断です。しかも、この選択には制度的な裏付けがありました。2015年、政府IT総合戦略本部の電子行政オープンデータ実務者会議は、自治体オープンデータの推奨ファイル形式を整理し、地理空間情報については「.gml または .kml」としました[18]。KMLでの公開は各自治体の思いつきではなく、国の指針に沿った標準的な対応だったのです。問題は、その合理的な判断の受け皿となったツールとフォーマットが、属性データをHTMLに封印した形で出力することです。同様の構図は全国の自治体で見られます。 Our main sample in Article 2 is official open data as published. The city also officially documents Google My Maps as the recommended way to use its KML files [2]. None of this is staff error. Choosing free, accessible tools and writing citizen-friendly instructions is rational public administration. The choice even had institutional backing: in 2015, the open-data working group under the Japanese government's IT Strategic Headquarters standardized recommended file formats for municipal open data, listing ".gml or .kml" for geospatial information [18]. Publishing KML was not each municipality's improvisation — it was the nationally recommended default. The problem is that the tool and format receiving those rational decisions emit data with its attributes sealed inside HTML. The same pattern repeats across municipalities nationwide.

同じKMLなのに、開けないSame KML, won't open

Googleマイマップから書き出したKMLは、国土地理院の「地理院地図」でそのまま表示できず、変換ツール（地理院マップシート）を挟む必要がある場合があることが利用者向け解説で知られています[10]。KMLが常にどこでも同じように開けるとは限りません。同じ拡張子でも、どのツールがどう書き出したかによって挙動が変わり、ツール間の受け渡しでつまずくことがあります。 KML exported from Google My Maps is documented to sometimes need a conversion step (via the GSI "Map Sheet" tool) before it displays in GSI Maps, the service run by Japan's national mapping agency [10]. The same extension does not guarantee the same behavior: how a given tool wrote the file changes how it opens, and files can stumble when passed between tools.

2027年、修正の可能性が消える2027: the fix window closes

第二条の補助サンプルが示す通り、2026年時点のマイマップ出力にも構造上の問題が残っています。そしてGoogle Earth Proデスクトップ版は2027年6月25日に配布を終え、以後更新されません[3]。Web版には最大25万頂点というデータ読み込み制限があり、業務用途の代替として不十分だという利用者の指摘が公開の場で多数なされています[4]。出力側の修正が見込めない以上、改善の余地があるのは配布する側の選択だけです。 As the secondary sample in Article 2 shows, structural problems persist in My Maps output as of 2026. Google Earth Pro for desktop stops being distributed on June 25, 2027, and will receive no further updates [3]; the web version caps dataset imports at 250,000 vertices, which professional users have publicly described as inadequate [4]. With no fix coming on the output side, the only variable left is what publishers choose to ship.

第五条ARTICLE 5

世界共通の問題ですA worldwide problem

KMLのdescription問題は、日本に固有の話ではありません。アメリカ国家安全保障局（NSA）はGitHubで、KMLのdescription欄に詰め込まれたHTMLを解析して属性テーブルに展開するQGISプラグイン「KML Tools」を公開しています[8]。そのドキュメントには次の記述があります。 The description problem is not local to Japan. The U.S. National Security Agency publishes "KML Tools," an open-source QGIS plugin whose job includes parsing the HTML stuffed into KML description fields back into attribute tables [8]. Its documentation states:

「descriptionエントリに追加情報を含める標準的な方法が存在しないため、すべてのケースを展開できる方法を考案するのは困難である」 "Because there is no standard way of including additional information in the KML description entry, it is difficult to come up with a way to expand all cases."
NSA「KML Tools」ドキュメントより（当サイト訳）— NSA, "KML Tools" documentation

同プラグインが対応するのは、現場で観測された3つの方言——2列HTMLテーブル、tag=value、tag: value——です。伊勢市のサンプルは、このうち1番目の方言に該当します。国家機関が地図ファイル内のHTML方言のパーサを開発・公開しているという事実が、この問題の広がりを示しています。 The plugin handles the three dialects observed in the wild — two-column HTML tables, tag=value, and tag: value. Our Ise sample is dialect number one. When a national agency maintains parsers for HTML dialects inside map files, the scale of the problem speaks for itself.

第六条ARTICLE 6

選べる時代になったYou have better options now

KMLが広まった2005年頃、「非エンジニアが地理データを作って共有できる形式」に実質的な選択肢はありませんでした。現在は、用途ごとに明確に優れた形式が揃っています。 Around 2005, when KML spread, there was no real alternative for non-engineers creating and sharing geodata. Today there is a clearly better format for every job.

用途Job	形式Format	KMLに対する優位点Advantage over KML
データ配布（〜数十MB）Distribution (up to tens of MB)	GeoJSON RFC 7946	属性が最初から構造化。主要な地図ライブラリ・GISツール・データベースがネイティブ対応。テキストなので差分管理も可能Structured attributes by design; native support across mapping libraries, GIS tools, databases; diffable text
大規模データの配布Large datasets	FlatGeobuf	空間インデックス内蔵。HTTP Range Requestで必要範囲のみ取得でき、専用サーバ不要Built-in spatial index; range-request streaming over plain HTTP, no server required
分析基盤Analytics	GeoParquet	列指向＋圧縮。DuckDBやBigQueryから直接クエリ可能Columnar and compressed; direct queries from DuckDB or BigQuery
タイル配信Tiles	PMTiles	タイルセット全体を単一ファイルで保持し、静的ホスティングで配信可能A full tileset in one file on static hosting
表計算文化圏への配布Spreadsheet users	CSV 緯度経度列付きwith lat/lon	Excelで開ける。Googleマイマップにもそのままインポート可能Opens in Excel; imports directly into Google My Maps

共通点は2つ。属性が構造化されていること、表示スタイルとデータが分離されていること。KMLは「特定ビューアでどう見えるか」を中心にデータ・HTML・装飾を一体化する2005年の設計を保ったまま流通し続けている、事実上唯一の現役フォーマットです。かつてKMLを配布形式に選ぶ最後の理由は「Google Earthで直接開ける」ことでしたが、Web版Google Earthは今やGeoJSONもShapefileも直接読み込めます[17]。その最後の理由すら、もう成り立ちません。 They share two properties: structured attributes and separation of styling from data. KML is effectively the last format in active circulation designed around a 2005 question — "how will this render in one particular viewer?" — fusing data, HTML and decoration into one lump. The last reason to ship KML used to be "it opens directly in Google Earth" — but Google Earth on the web now imports GeoJSON and Shapefile directly too [17]. Even that last reason no longer holds.

第七条ARTICLE 7

GISの入口を、ふさいでいるIt blocks the on-ramp to GIS

ここまでの話は、専門家だけの問題ではありません。むしろ影響を最も強く受けるのは、これから地理空間データに触れようとする一般の人々です。

非エンジニアが地図データに出会うとき、その入口はたいていGoogleのサービスです。Googleマップ、マイマップ、そしてGoogle Earth——世界で最も広く使われ、最も敷居が低いツール群。そこからデータを持ち出そうとすると、出てくるのはKMLです。そしてそのKMLは、これまで見てきた通り可搬性が低い。

初心者の体験は、こうたどります。

Google Earth Proやマイマップで地理データを作り、KMLでエクスポートする（ここまでは簡単）
ツールによっては、そのまま開けないことがある。マイマップ出力のKMLは、たとえば地理院地図で表示するのに変換のひと手間を要する場合が知られています[10]
うまく表示できても、いざデータとして扱おうとすると、属性がdescriptionのHTMLに埋まっていて取り出せない。これは伊勢市の例（第二条）のように、正しく地図に表示されるKMLでも同じです
取り出すには変換ツールと、場合によっては専用パーサが必要になる（第二条）

プログラミングやGISの素養がある人なら、この壁は「面倒」で済みます。しかし初学者にとって、この一連の障害はしばしば入口そのものになります。「地図データは難しい」「自分には手に負えない」という最初の印象を、可搬性の低いフォーマットが作り出してしまう。

最も敷居の低いツールが、最も可搬性の低い形式を出力する——この組み合わせが、地理空間データを誰もが扱える時代への移行を、入口のところで押しとどめています。本来なら、地理データを作成できた本人は、他のツールでもそれをそのまま活用できるはずなのです。その間にデータ変換の壁を置いているのは、フォーマットの設計です。

None of this is a problem for experts only. The people hit hardest are the ones just beginning to touch geospatial data.

For a non-engineer, the on-ramp to map data is almost always a Google service — Google Maps, My Maps, Google Earth: the most widely used, lowest-barrier tools in the world. Try to take your data out, and what you get is KML. And that KML, as we've seen, travels poorly.

The beginner's path runs like this:

Create geographic data in Google Earth Pro or My Maps, export as KML — easy so far
Depending on the tool, it may not open as-is: My Maps KML is documented, for instance, to need a conversion step before it displays in GSI Maps [10]
Even when it does display, the moment you try to treat it as data the attributes are buried in description HTML, unreachable — true even of KML that renders perfectly, like the Ise example (Article 2)
Getting them out needs a conversion tool and sometimes a custom parser (Article 2)

For someone with programming or GIS background, this wall is merely "annoying." But for a beginner, this chain of obstacles is often the on-ramp itself. A low-portability format manufactures the first impression that "map data is hard" and "this is beyond me."

The lowest-barrier tools emit the lowest-portability format — and that combination stalls, right at the entrance, the move toward an era where anyone can work with geospatial data. In principle, anyone who creates geographic data should be able to utilize it in other tools as-is. What stands between the two is a wall of conversion, put there by the format's design.

第八条ARTICLE 8

今日からできることWhat you can do today

データを公開する立場の方へ（自治体・企業・研究機関）If you publish data

GeoJSON（またはCSV）を正のデータとして公開してください。KMLが必要な利用者には、正データから変換したものを併記すれば足ります。逆方向は本ページで示した通り、専用パーサの開発を意味します。 Make GeoJSON (or CSV) the canonical dataset. For users who need KML, generate it from the canonical data. The reverse direction, as demonstrated above, means writing a custom parser.

ogr2ogr out.kml in.geojson   # 正データ→KML併記はこの1行canonical → courtesy KML, one line

あわせて、Google Earth Proを新たに導入しない・使いつづけないことも重要です。デスクトップ版は2027年6月25日に配布終了となり、以後更新されません[3]。更新されないソフトウェアを使って地理データを作成しつづけることは、KML中心のワークフローを温存することにつながります。 Equally important: don't adopt — or keep relying on — Google Earth Pro. The desktop app's distribution ends on June 25, 2027, and it will not be updated afterwards [3]. Authoring geodata in unmaintained software is exactly what keeps KML-centric workflows alive.

KMLを受け取ってしまった方へIf you've been handed KML

コマンドライン: ogr2ogr output.geojson input.kml（KMZも直接読み込み可能[11]）CLI: ogr2ogr output.geojson input.kml (reads KMZ directly [11])
ブラウザ / JavaScript: @tmcw/togeojson[12]Browser / JS: @tmcw/togeojson [12]
QGIS: 「KML Tools」プラグイン[9]。description内の2列HTMLテーブルや tag: value を属性テーブルに展開できますQGIS: the KML Tools plugin [9] expands two-column HTML tables and tag: value pairs from descriptions into attribute tables

組織内でKMLが標準になっている方へIf KML is entrenched at your organization

「正データをGeoJSONに、KMLは自動生成の派生物に」という構成なら、既存のKML利用者を切り捨てずに移行でき、変更は「廃止」ではなく「追加」として提案できます。このページ（日英）を添付資料としてご利用ください。 "Canonical data in GeoJSON; KML as an auto-generated derivative" migrates without breaking anyone's workflow — an addition, not a removal. Feel free to attach this page (available in English and Japanese).

第九条ARTICLE 9

よくある反論と回答Objections, answered

Q1. フォーマットに罪はない。悪いのは運用では？Q1. "Blame the users, not the format."

半分は正しい指摘です。KML 2.2仕様には ExtendedData という構造化属性の仕組みが確かにあります。しかしその仕様を書いてOGCに提出したのはGoogle自身であり、Googleの公式ドキュメントは「Google Earthはこの型付き情報を使用しない」と明記し、Google製ツールは属性をdescriptionのHTMLとして出力する形を20年間の事実上の標準にしました。本サイトが示した2026年取得の実データ2点（自治体配布KML・マイマップ出力）が、その帰結です。標準の起草者が自らの標準の正しい使い方を実装しないとき、流通するファイルの品質を利用者の責任と呼ぶのは妥当ではありません。フォーマットの価値は仕様書ではなく、実際に流通するファイルで決まります。 Half right. The KML 2.2 spec does define ExtendedData for structured attributes. But that spec was written and submitted to the OGC by Google — whose own documentation states that Google Earth does not use the typed information, and whose tools made description-HTML the de-facto standard output for twenty years. The two real files on this page, both retrieved in 2026 — one published by a city government, one exported from My Maps — are the result. When the author of a standard declines to implement its own standard correctly, attributing the quality of circulating files to users is not a serious position. A format's worth is determined by the files that actually circulate, not by its spec.

Q2. ExtendedDataを正しく使ったKMLならいいのでは？Q2. What about well-made KML?

理論上は大幅に改善します。しかし2つの現実があります。第一に、受け手側ツールがExtendedDataを一貫して扱う保証がありません（起草者のGoogle Earth自身が型情報を無視することが象徴的です）。第二に、ExtendedDataを正しく書ける制作者はGeoJSONも書けます。そしてGeoJSONでは「正しく構造化できているか」という問い自体が発生しません——構造化以外の書き方が存在しないからです。間違えようのない形式が普及している以上、間違えやすい形式を配布用に選ぶ理由はありません。 In theory, a big improvement. Two realities intervene. First, there is no guarantee the receiving toolchain handles ExtendedData consistently — the spec's own author, Google Earth, ignoring the typed information is emblematic. Second, anyone capable of writing correct ExtendedData is capable of writing GeoJSON, where the question "did I structure this correctly?" cannot arise, because unstructured is not an option. With a format you can't get wrong widely available, there is no case for shipping one you easily can.

Q3. KMLはOGCの国際標準ですよね？Q3. But KML is an OGC standard.

GMLも国際標準です。標準であることと、データ交換に適していることは別の性質です。実務におけるWeb地図のデファクト交換形式はGeoJSON（IETF RFC 7946）であり、主要な地図ライブラリ・GISツール・データベースがネイティブ対応しています。「標準だから」という主張は、その標準のファイルが実際にどう流通しているかを確認してはじめて意味を持ちます。 So is GML. Being a standard and being a good interchange format are different properties. The de-facto interchange format of practical web mapping is GeoJSON (IETF RFC 7946), natively supported across mapping libraries, GIS tools and databases. "It's a standard" only means something after you look at how files of that standard actually circulate.

Q4. Google Earthで見るにはKMLが必要では？Q4. I need KML to view things in Google Earth.

その前提は、すでに古くなっています。Web版・モバイル版のGoogle Earthは、KML/KMZに加えてGeoJSONとShapefile（.zip）を直接インポートできます[17]。つまり、GeoJSONで配布すればGoogle Earthのユーザーも変換なしでそのまま開けます。「Google Earthで見るためにKMLが要る」という理由は、もう成り立ちません。むしろデスクトップ版が配布終了に向かう一方で、Web版が構造化フォーマットを読めるようになった——時代はKMLから離れる方向に進んでいます。なお、どうしてもKMLファイルが必要な場面でも、GeoJSONからKMLへは1コマンドで変換できます。逆に、descriptionにHTMLが焼き込まれたKMLの構造を復元するには、本ページで実演した通り専用パーサが必要です。この非対称性が、配布形式の選択に対する答えです。 That premise is already out of date. Google Earth for web and mobile can import GeoJSON and Shapefile (.zip) directly, alongside KML/KMZ [17]. So if you distribute GeoJSON, Google Earth users open it as-is, no conversion. "I need KML to view it in Google Earth" no longer holds. If anything, the trend runs the other way: the desktop app heads for sunset while the web app learns to read structured formats. And on the rare occasion you truly need a KML file, GeoJSON converts to KML in one command — whereas recovering structure from HTML-stuffed KML, as this page demonstrates, requires a custom parser. That asymmetry answers the question of what belongs on the download page.

Q5. GeoJSONにも欠点があるのでは？Q5. GeoJSON has flaws too.

あります。巨大データには不向きで、座標系はWGS 84に固定されています。だから本サイトは「GeoJSONが万能」とは主張しません。配布はGeoJSON、大規模はFlatGeobufやGeoParquet、タイルはPMTiles、表計算文化圏にはCSV——第六条の通り用途別に選べます。共通するのは属性が構造化されていることです。KMLの問題は欠点の存在ではなく、データの最も価値ある半分（属性）を封印する慣習とセットで流通してきたことにあります。 It does. It's poor for very large data and pins you to WGS 84. That's why this site doesn't claim GeoJSON is perfect — GeoJSON for distribution, FlatGeobuf or GeoParquet for scale, PMTiles for tiles, CSV for spreadsheet users, per Article 6. What they share is structured attributes. KML's problem was never having flaws; it's circulating bundled with a convention that seals away the most valuable half of the data.

Q6. Shapefileはいいんですか？Q6. And Shapefile gets a pass?

いいえ。Shapefileには別の問題群（属性名10文字制限、複数ファイル構成、文字コードの混乱など）があり、GISコミュニティには先行する啓発サイト switchfromshapefile.org が存在します。本サイトはそのKML版に相当します。前世紀に設計されたフォーマットは、それぞれの理由で引退の時期を迎えています。 No. Shapefile has its own catalog of problems (10-character field names, multi-file fragility, encoding chaos), and the GIS community already built switchfromshapefile.org for it. Consider this site its KML counterpart. The formats designed last century are each reaching retirement age, for their own reasons.

Q7. 組織の方針でKMLと決まっていますQ7. Our org mandates KML.

方針の原文を確認することをお勧めします。現行のオープンデータ政策が求めているのは一般に機械判読性であって、KMLの指定ではありません。実務的な移行案は「正データをGeoJSONまたはCSVで公開し、KMLは正データから自動生成して併記する」構成です。既存のKML利用者の作業は何も変わらず、組織内の手続き上も「廃止」ではなく「追加」として提案できます。 Check what the mandate actually says — most open-data policies require machine readability, not KML specifically. The pragmatic migration: publish GeoJSON or CSV as canonical, auto-generate KML from it as a courtesy copy. Nobody's workflow breaks, and internally it's an addition, not a removal.

Q8. マイマップしか使えない環境ですQ8. My Maps is all we have.

問題ありません。マイマップは緯度経度（または住所）列を持つCSVを直接インポートできます。したがって「配布はCSV/GeoJSONを正とし、マイマップにはCSVを読ませる」構成で、現在の作業手順は維持できます。変わるのは、配布したデータが受け取った側でも「データ」であり続けることだけです。 You're covered. My Maps imports CSV with lat/lon (or address) columns directly. Distribute CSV/GeoJSON as canonical, feed the CSV to My Maps — your workflow doesn't change. The only difference is that what you hand out remains data on arrival.

Q9. 手元に大量のKML資産がありますQ9. We're sitting on years of KML.

過去のデータは救済できます。ogr2ogr output.geojson input.kml（KMZ直接対応）、ブラウザなら @tmcw/togeojson、descriptionにHTMLが入ったファイルにはQGISの「KML Tools」プラグイン（2列テーブル・tag=value・tag: value の3方言に対応）が使えます。すべては救えないかもしれませんが、多くは救えます。本サイトの提案は過去の清算ではなく、新規の発生を止めることです。 Legacy data is recoverable. ogr2ogr output.geojson input.kml (reads KMZ directly); in the browser, @tmcw/togeojson; for HTML-stuffed descriptions, the QGIS KML Tools plugin handles the three known dialects. You may not save everything, but you'll save most of it. The proposal here isn't about the past — it's to stop minting new cases.

Q10. Google Earth Proは2027年に使えなくなるのですか？Q10. So Google Earth Pro dies in 2027?

正確には「2027年6月25日以降、新規ダウンロードの提供が終了」です。インストール済みの環境では動作し続けますが、更新は提供されません。つまり、現在のKML出力の形を定着させたソフトウェアが、修正される可能性のないまま現場に残り続けます。配布形式の見直しを「今」提案する理由はここにあります。 Precisely: downloads end June 25, 2027. Installed copies keep running but receive no updates. The software that entrenched today's KML output will remain in the field with no possibility of a fix. That is why the time to reconsider distribution formats is now.

Q11. このサイトは誰が運営していますか？Googleと関係は？Q11. Who runs this? Affiliated with Google?

独立したGIS/Webエンジニアによる非営利の啓発プロジェクトです。Google LLC、OGC、引用した各組織とは一切関係ありません。KML、Google Earth、Googleマイマップは各権利者の商標であり、本サイトでは批評・解説の目的でのみ言及しています。事実誤認のご指摘は歓迎します。掲載内容はすべて一次資料へのリンクとともに提示しています。 An independent, non-commercial awareness project by a GIS/web engineer. Not affiliated with Google LLC, the OGC, or any cited organization. KML, Google Earth and Google My Maps are trademarks of their respective owners, referenced solely for commentary and criticism. Corrections are welcome; every claim on this site links to a primary source.

附則APPENDIX

出典Sources

伊勢市オープンデータ「観光案内所・手荷物預かり所」（MapData/KML）配布ページ（2026年7月10日取得）Ise City Open Data: Tourist Information Desks (MapData/KML), retrieved July 10, 2026 — city.ise.mie.jp
伊勢市「MapData（KMLファイル）の利用方法」（マイマップへのインポート手順の公式案内）Ise City: official instructions for loading MapData KML into Google My Maps — city.ise.mie.jp
Google Earth Versions（配布終了告知）Google Earth Versions (end-of-download notice) — google.com/earth
Google Earth Pro配布終了の報道（既存インストール継続の確認、Web版25万頂点制限への批判。2026年7月8日〜）Press coverage of the desktop sunset (installed copies keep working; criticism of the web version's 250k-vertex cap), July 2026 — Android Authority / PCWorld
KML Reference（Google）KML Reference (Google) — developers.google.com
Adding Custom Data（Google。「Google Earth does not use this typed information」の記載）Adding Custom Data (Google; "Google Earth does not use this typed information") — developers.google.com
OGC KML標準OGC KML standard — ogc.org
NationalSecurityAgency/qgis-kmltools-plugin（README該当箇所）NationalSecurityAgency/qgis-kmltools-plugin (README) — github.com
KML Tools（QGIS公式プラグインリポジトリ）KML Tools (QGIS plugin repository) — plugins.qgis.org
防災リテラシー研究所「マイマップを地理院地図に表示」Bosai Literacy Institute: displaying My Maps KML in GSI Maps — bosailiteracy.org
GDAL LIBKMLドライバ（KMZ直接対応）GDAL LIBKML driver (reads KMZ directly) — gdal.org
@tmcw/togeojson — npmjs.com
GeoJSON（IETF RFC 7946）/ FlatGeobuf / GeoParquet / PMTiles 各公式サイトGeoJSON (IETF RFC 7946) / FlatGeobuf / GeoParquet / PMTiles official sites — RFC 7946 / flatgeobuf.org / geoparquet.org / pmtiles
switchfromshapefile.org（先行事例）switchfromshapefile.org (precedent) — switchfromshapefile.org
Googleマイマップから書き出したKML実サンプル3点の解析（2022年・2024年・2025年作成の各マップ。2026年7月に当サイトが解析・保管。主題を伏せて技術的事実のみを引用）Analysis of three real KML exports from Google My Maps (maps created in 2022, 2024, 2025; analyzed and archived by this site in July 2026; cited for technical facts only, topics withheld)
*1（2022）　 *2（2024）　 *3（2025）
伊勢市オープンデータ利用規約（平成28年12月12日制定、令和3年4月1日改正。CC BY 4.0・改変利用時のクレジット書式の定め）Ise City Open Data Terms of Use (CC BY 4.0; prescribed credit format for adapted works) — city.ise.mie.jp
Import data into Google Earth（Google。Web版・モバイル版がKML/KMZ・GeoJSON・Shapefileを直接インポート対応と明記）Import data into Google Earth (Google; web and mobile support direct import of KML/KMZ, GeoJSON and Shapefile) — developers.google.com
日経BP「自治体向けのオープンデータ支援策が明らかに」（2015年5月28日。電子行政オープンデータ実務者会議による推奨ファイル形式の整理——地理空間情報は「.gml」または「.kml」——を報道）Nikkei BP: "Government support measures for municipal open data revealed" (May 28, 2015; reporting the recommended file formats — ".gml or .kml" for geospatial information) — project.nikkeibp.co.jp

KMLでの配布、もうやめませんか。 It's time to stopshipping KML.