OpenStreetMap開発の舞台裏を知る 〜マッパーズサミット2026レポート〜

はじめに

OpenStreetMap(OSM)は、誰でも自由に地図を使えるように、皆でオープンデータの地理情報を作るプロジェクトです。2004年に英国で始まり、日本では2008年から活動しています。

日本地域におけるOpenStreetMapの活動を支える団体としてOpenStreetMap Foundation Japan(OSMFJ)があります。さくらインターネットはOSMFJから依頼を受けて、OpenStreetMapの制作に必要なサーバの無償提供を行っています。

そのような背景のもと、2026年2月1日(日)に、さくらインターネットの大阪本社でもあるBlooming Campにおいて「マッパーズサミット2026」が開催されました。このイベントは、OpenStreetMapの地図制作に関わる人々(マッパー)のノウハウを共有し、地図制作に関する課題や解決策を話し合うことを目的とするもので、今回初の試みとして実施されました。それではイベントの様子を見てみましょう。

さくらインターネットが提供するコミュニティ向けタイルサーバについて

最初の発表者はすめるまんさんです。さくらインターネットからOSMFJに提供したサーバで運用しているタイルサーバ(地図データを配信するサーバ)について発表しました。

OSMFJのタイルサーバは2020年から稼働しており、ベクトルタイルサーバ(地図データを点・線・面などのベクターデータ形式で配信するサーバ)と、ラスタタイルサーバ(地図画像を小さな単位(ラスターデータ)に分割して配信するサーバ)を運用しています。サーバのスペックは下記の通りです。

• CPU: 20コア
• メモリ: 64GB
• ストレージ: SSD 500GB
• ネットワーク: 100Mbps

技術スタックとしては、タイル生成にTileServer GL、キャッシュにVarnish Cache、配信にNginx、モニタリングにPrometheusとGrafanaを使用しています。

タイルサーバの内部構造も図を用いて解説しました。ユーザからのアクセスはNginx経由でいったんVarnish Cacheに行き、キャッシュにないデータは10個稼働しているタイルサーバから応答します。静的ファイルはNginxから応答します。

サーバ運用における課題としては以下があります。

• ベクタタイルの生成を毎週手動で行っている。自動化したいが認証などの問題があり実装できていない。
• セキュリティアップデートも手動で実施。何も考えずに自動更新するとよくないこともあるので、必要なものを見極めて更新している。
• PrometheusとGrafanaでモニタリングしているが異常の通知は行っていない。

今後の展望としては、スタイルを充実させて多様な利用ニーズに応えることや、モニタリングを強化して異常検知や通知を行えるようにしたいと考えています。

セッションの後半では、実際にタイルサーバの画面を見せながら説明がありました。タイルサーバの画面には数多くのスタイルが並んでおり、選択するとそのスタイルで地図が表示されます。地図データはOpenMapTilesスキーマに基づいて地球全体のデータが配信されていますが、竹島や北方領土などいくつかの特定地域はその地域専用のデータで上書きして表示するという処理が入っています。タイルサーバの配信URLなどはOSMのWikiにまとめられています。サーバの設定などはGitHubにまとめられています。

Grafanaの画面からは、メモリ使用率が86%、スワップ使用率は40%程度ということがわかりました。もっともスワップについては前日にサーバの再起動をかけたばかりなので少なめで、週末は80%ぐらいまで上がるとのことでした。htopコマンドでプロセスの稼働状況も見せていただきました。メモリはVarnishによる消費が多く、CPUはタイルサーバへのアクセスによる負荷が高いことがわかりました。

それから、PMTiles形式で地図を配信するサーバの画面も見せていただきました。PMTilesは、大量の地図タイルを単一ファイルにパッケージ化し、HTTPのRange Requestsを利用して必要な部分だけを配信する仕組みです。こうすることでWebサーバ(OSMの場合はNginx)だけで地図の配信を行うことができます。ただし複数のフォントを使用するようなケースではTileServer GLのようなタイルサーバが必要になります。

参加者との質疑応答では、サーバのリソースは逼迫しているかという質問がありました。これに対しては、リソースの監視を行っていないので正確なところはわからないが、リソースを食いつぶすとサーバが自動的に再起動するのであまり気にしていないとのことでした。利用者数はどれぐらいかという質問もあり、これに対しては正確な人数は不明だが、Grafanaの画面によると同時接続数が1000を超えることがあり、多いときで5分間あたり300〜400のリクエストを処理しているという回答がありました。

多言語表記のタグ付けを考える

2番目の発表者はハヤシさんで、OpenStreetMapに掲載されている地物に対するタグ付け(名称や住所などを「キー=値」という形式で記述すること)、中でも多言語の取り扱いに関する問題について発表しました。

まず、例として神奈川県綾瀬市にある「虚空蔵橋際」という交差点に対するタグ付けの過程を説明し、タグ付けに関する問題として以下を挙げました。

• 国土交通省の表記と現地での呼び名が異なる場合がある(この例では国土交通省の表記は「こくぞうばし」、現地での呼び名は「ごくぞうばし」)
• 2026年度以降にローマ字表記のルールが改定されるので、それに伴うタグの変更が発生する
• 各言語ごとのタグがないときのためのフォールバックとしてname:en(英語の名称)を設定することについて是非の議論がある
• OSMには「現地に存在しない情報は入れるべきではない」という原則があるが、例えばゴールデン・ゲート・ブリッジは日本人の間で通称「金門橋」と呼ばれているのにname:ja=金門橋というタグ付けをするのもダメなのか

これらの問題に対しては、wikidataタグを付ける解決策が提唱されています。実際のタグ付け過程としては、Mapillaryを利用してnameやint_nameを記載し、wikidataがあればそれもタグ付けします。あとは現地に行って調べてタグを追加します。

ただ、最近増えているバーチャル店舗(ネット上で実店舗名と異なる名称を名乗っている店舗)はどのようにタグ付けすべきかという課題があります。これについても、ネット上の情報はwikidataに記述し、OSMには現地にあるデータのみを記述するのがよいという考えを示しました。

日常に溶け込むマッピング

3番目の発表者は北村由衣さんで、日常のマッピング作業におけるノウハウを披露しました。

マッピング作業は大きく以下の3段階に分けられます。

1. 建物と道路の位置決め
2. 現地を歩く
3. iD(OpenStreetMapのWebブラウザ用エディタ)でセルフレビュー

1はPC上での作業で、航空写真を見て建物や道路をマッピングします。2は文字通り現地作業で、店舗情報などをプロットしていきます。先に航空写真で事前マッピングしておくと、現地調査で建物が増減していた場合や、橋梁の架け替えなどで経路が変わっていた場合などにも対応しやすくなります。3については実際にiDを使って作業している動画を流し、頻繁に使うショートカットキーも紹介しました。

現地調査でのデータ入力に重宝しているツールがEveryDoorです。日本の住所構造に対応していないという難点はありますが、タグの直接入力もできて便利です。それから現地で撮った写真はMapillaryに載せます。これは特に森の中の道など、航空写真では見えない情報の補強に役立ちます。この他に、テキスト編集にLevel0、データ抽出にoverpass turboを使っています。

マッピング作業における心がけとして、中途半端な編集状態で公開することは避けており、公開する際は「ベストでなくてもベターの入力」を心がけています。特に住所の入力においては、類似の値が候補として出てくることで不正確な入力になるケースが多く、それよりはaddr:fullタグを用いて住所の全文を記述した方がよいという意見を出されました。またすべての記述を自分で行う必要はなく、ある程度完結した状態で公開しておけば、後で他の人が補正・追記してくれることが期待できるとしました。

北村さんの発表資料は本人のウェブサイトにありますのでご覧ください。

AIと共に編集する、自宅にある惑星「地球」

4番目の発表者はゆいせきさんで、OSMの地物データを元にした地図表示のカスタマイズやGISアプリ開発にAIを活用するという内容でした。具体的に取り組んだものを以下に掲げます。

• Planet.osm(OSMの全体データ)を自分のマシンにダウンロードし、Planetilerを使ってベクトルタイル形式の地図を作成。さらにAIを使ってカスタムスキーマを作成。
• ダウンロードしたPlanet.osmをもとに、Nominatim API、TagInfo API、Overpass API、Valhalla APIといったOSMが提供するAPIをセルフホスト。これによりAIエージェントがリクエスト数などの制限を気にせずにOSMデータを活用できる。
• AIエージェント向けに、上記のAPIを呼び出せるCLIユーティリティを開発。
• セルフホストしたNominatim APIやollama APIを組み合わせて、自然言語テキストから地名とbbox(OSM上の矩形領域)を抽出できるサービスを開発。

開発したものの実演もありました。いくつか紹介します。

https://trident.yuiseki.net/planetiler は、PlanetilerとTileServer GLを使って作成した鉄道網や水路網などのマップを並べたものです。マウスでマップを動かすと他のマップも連動して動きます。

osmableは、OSM関係のAPIを呼び出せるCLIユーティリティです。コマンドを入力すると、指定した地物の住所や位置情報が出力されます。応用としてAIエージェントが調べ物の道具としてosmableを使う方法も紹介しました。

Locitoriumは、画面左側のTextエリアにテキストを入力し「Resolve Locations」ボタンを押すと、テキストの文面から場所を推測して地図上に表示します。

これらのサービスはゆいせきさんの個人マシンで動いています。スペックを以下に示します。

• CPU: 16コア
• メモリ: 96GB
• GPU: NVIDIA GeForce RTX 3060 ×2 (VRAM: 12GB x2)
• ストレージ
  • NVMe SSD: 2TB + 4TB
  • SATA SSD: 2TB ×2, RAID 0 = 4TB
  • HDD: 4TB

Planet.osmをダウンロードして各種形式に変換しているので、特にストレージが多く必要になっています。

最後にゆいせきさんから、AIが地図データを扱ったり編集したりする世界において、OSMのタグ付けをどのように変えるべきか、あるいは変えるべきではないかという話題が提起されました。これについては発表後に議論があり、参加者の多くはタグ付けが変わるだろうと考えているようです。ただその中で、AIによる分析の際に日本の住所体系がネックになる可能性があり、郵便番号やwikidataのようなIDと組み合わせる方がよいかもしれないという意見もありました。

使いたくなる地図を目指したマッピングを考える

続いてはWish_Fさんによる発表です。Wish_Fさんは、OSMのデータを使って近所の案内地図を作成したり、OSMのデータを3Dモデリングデータに変換して3Dプリンタで出力するといったことをやっています。そして、これらの活動から感じた課題として、OSMは「使うための情報」が不足していると指摘しました。建物の形状や精度の不十分さ、情報量の少なさなどが、地図として使っていく上での体験を阻害している可能性があるということです。地図を利用する目的(ナビゲーション、検索、分析、3D表現など)によって必要な情報は異なるため、それぞれに応じた情報を提供していくべきだという意見を述べました。

目的に応じた情報が提供されているかどうかという観点での問題提起として、学校のプールの例を挙げました。学校のプールをマルチポリゴンにしてbuilding=yesというタグを付けている例が多いが、プールは建物ではないのではないかという疑問を呈しました。また自転車の走行ルールが2026年4月から厳格化されますが、OSM上で利用者がルールを正しく理解できるようなタグ付けはどうすればよいかという問題も提起しました。

このセッションは議論の時間が長く取られ、多くの意見が交わされました。学校のプールについては、プールは人工物なので建築物である(building=yesである)ととらえる考えがある一方で、建物として扱うと3Dレンダリング時に穴が開いてしまうという問題が指摘されました。locationタグやheightタグを活用してより正確な記述を目指す提案もありました。

自転車の走行ルールについては、日本では自転車が歩道を走ってもよい場合がありますが、これをbicycle=yesとするのは適切か、歩行者優先というルールをどう表現するか、などの課題があります。日本における自転車の走行ルールは世界的に見ると特殊なところがあるようで、日本の道路事情に合わせたタグ付けを考えていく必要がありそうです。

地図のスクショってどう取り扱ったらいいの？先達の知恵を拝借…

最後の発表者はalt9800さんで、地図のスクリーンショットに関するお悩み相談をしました。

Googleマップなどの地図は著作権があるので、地図のスクリーンショットを撮ってSNSに投稿するのは違反になります。しかし実際にはスマートフォンで地図のスクリーンショットが簡単に撮れることもあって投稿が後を絶ちません。それは「地図を共有したい」という願望があるからです。これに応えるための仕組みとして、Googleマップでは共有用のURLを生成できたり、LINEも位置情報共有の際にGoogleMapsPlatform NativeSDKのAPIを使ってサムネイルを生成しているようです。OSMの場合はスクリーンショットに「©OpenStreetMap Contributers」を記載すれば共有可能です。他の地図サービスについてもスクリーンショット利用の可否やライセンスを自動的に表示する仕組みを調べていますが、サービスによって内部実装やライセンスが異なることや、さらにクライアント側で地図の改変を行う場合はどうなるのかなど、悩みは尽きないようです。

この件についても参加者の間で活発な議論が行われました。Googleマップのスクリーンショットについては、FAQでスクリーンショットの禁止を定めていたページが見つからなくなっていることや、日本の著作権法の見直しでスクリーンショットが違法にならない方向性の議論もあったので、今後はスクリーンショットが必ずしも違法ではなくなる可能性もあるようです。また、スクリーンショットはオフライン利用を可能にするという利点があり、OSMはライセンス面でもそれを可能とする考え方に立っているというコメントもありました。alt9800さんは「地図を共有したいという需要は確実にあるので、ライセンスなどの点で問題のない形で地図を共有するサービスが作れたら課題を解決できるのではないか」と話していました。

おわりに

OSMFJにサーバを提供して数年になります。以前にもさくナレに寄稿いただいたことがありますが、実際にOSMの地図制作に関わる皆さんがどのようにしてデータを作り、どのような課題を感じているかは、今回のイベントで初めて知ることができました。当社がコミュニティに貢献している実感を得ることができてとても有意義な機会でした。これからも良い形で貢献できればと思います。

それではまた次回のイベントでお会いしましょう！