自由な地図の力でより良い未来を作ろう 〜OpenStreetMap関西カンファレンス2026レポート〜

はじめに

さくらのナレッジ編集部の法林です。

2026年8月9日(日)に、株式会社アジャイルウェア大阪オフィスにてOpenStreetMap関西カンファレンス2026が開催されました。本記事ではこのイベントの模様をレポートします。

イベントの開催趣旨

OpenStreetMap(OSM) は、誰でも自由に利用でき、かつ編集機能のある世界地図を作るプロジェクトです。世界各国で活動が見られますが、日本でもさかんに活動しており、それを支える組織としてOpenStreetMap Foundation Japan(OSMFJ)があります。さくらインターネットはOSMFJに対してインフラ(サーバ)の支援をしており、提供しているサーバはコミュニティのウェブサイトや地図のタイルサーバ(地図データを配信するサーバ)として利用されています。

参考記事：OpenStreetMap Foundation Japanコミュニティ向けタイルサーバの構築事例

今回のイベントは、OpenStreetMapに関心のある人たちが集まり、交流し、学び、アイデアを共有するカンファレンスとして開催されました。参加者は関西在住の方々だけでなく遠方からお越しの方も多く、約50人が参加されました。

プログラム一覧

今回のカンファレンスのプログラム一覧を掲載します。(資料を公開されている方についてはタイトルから資料にリンクしています)

発表者	タイトル
法林浩之	スポンサー講演: さくらとコミュニティとOSM
田中謙一郎	はじめてのOSMの利活用
harimawood	町内会長になってOSMが必要と感じること
hirax	VLMの空想力を地理情報で調伏する解説AIグラスを作る
Slow	PokémonGO→Wayfarer→万博マップ
Wish_F	探せる・歩ける・理解できる地図
あきぞ	2段階右折も安心！原付専用ナビアプリ「GenNavi」
松倉百代	OSMを活用した地域イベントのご紹介
スペシャルマン	オブジェクト以外を初めて編集してみた
大葉直史	水域マッピングことはじめ

この中から筆者の印象に残った発表をいくつか紹介します。

町内会長になってOSMが必要と感じること

発表者のharimawoodさんは兵庫県加古川市在住で、Code for Harimaなどで活動しています。今年の4月から町内会長に就任したところ、町内会で作成する資料に地図を載せる場面が多く、その地図の取り扱いに関する話を発表されました。

町内会の業務にはいろいろなものがありますが、その多くで地図が必要になります。例えば、地域のお祭りや講演会などの申請書類には会場を示す地図を添付します。町内のブロック分けを可視化するにも地図が必要です。それからゴミステーションや道路工事の場所を示すにも地図が必要です。

harimawoodさんが町内会長に就任する以前は、これらの地図にゼンリン住宅地図やGoogleマップ、あるいは手書きの地図が使われてきました。しかし商用地図サービスには利用規約や著作権の問題があり、公式な配布・掲示物には使いづらいです。かといってすべて手書き地図で対応するのも煩雑です。

そこでOSMの出番です。OSMは複製・加工・印刷・配布を自由に行えるので、町内会の用途にも安心して使うことができます。さらにOSMをベースマップとし、それに町内会独自の情報をレイヤーとして重ねることで、町内会として必要な地図を作成することもできます。

実際の取り組みとしては、まずOSMを直接更新するものとして、番地の記入や、建物の新築・取り壊しの反映などを行っています。加古川市では最近、公園の遊具の更新がさかんだそうで、遊具の位置もOSMに記載しています。OSMであればユーザがその気になれば商用地図サービスよりも迅速な更新ができます。

さらに、これから取り組みたいこととして、町内会員の誰がどこに住んでいるかがわかるような地図の作成、転入・転出情報の反映、用途に応じた個人情報の制御(例えば役所に提出する地図には各戸の居住者名は不要なので非表示にする)、町内会ブロックの可視化、などを挙げました。将来的には、防災・避難経路の策定、小学校近辺の危険度を表すマップの作成、白地図の塗り絵イベントなども企画したいとのことです。

さらに詳しく知りたい方は発表資料をご覧ください。

2段階右折も安心！原付専用ナビアプリ「GenNavi」

発表者のあきぞさんが開発している原付ライダー向けのナビアプリ「GenNavi」の話です。

あきぞさんは原付に乗るようになってから、原付での利用に適したナビアプリがないことに気がつきました。自動車用のカーナビを使うと、原付では入れないような自動車専用道路を案内されてしまいます。一方で自転車用のナビもまた、原付では入れないような歩道や押し歩き区間を案内してきます。それから原付で交差点を曲がるときには2段階右折(一度直進して渡った後に向きを変えて再度直進)をしなければならないケースがありますが、これも案内してくれません。これらのことが開発のきっかけになりました。

GenNaviは「原付ライダーが困る点をカバーする」という観点で機能が開発されています。ここでは以下の4つが紹介されました。

• トラックの横を走りたくない
  → 道路をOSMの道路クラス(幹線・主要地方道・県道・生活道路)に応じて重み付けし、それをもとにルートを検出し色分けして表示。こうすることでトラックの多い幹線を避けて走ることが可能。
• 交差点で2段階右折の有無を判断するのが難しい
  → OSMのデータでlanes>=3なら3車線以上あるので2段階右折するように案内。lanes=2の場合は交差点だけ3車線になるケースがあるので、2段階右折の可能性があるから要確認の旨を表示。
• 一時停止を見落としやすい
  → JARTIC(日本道路交通情報センター)が提供しているオープンデータとOSMのノード情報をもとに一時停止の有無を案内。
• 長距離を走ると疲れる
  → 100kmを超えるようなルートは区間分割し、途中で道の駅やコンビニなどで休憩を入れるように案内。

これらの、原付の安全面に関わる機能はすべて無料で提供しています。OSMやJARTICのような無償で使えるデータがあったからできたことです。商用APIの利用も検討しましたが、規約の関係で独自のデータやルールを持ち込めないことがネックとなって採用せず、結局はすべてオープンな技術を使って開発しました。使用した技術スタックを下表に掲げます。

ナビに必要なもの	使ったもの
道路データ(線形・接続・車線数・信号)	OpenStreetMap
規制標識(二段階右折・一時停止・通行禁止)	JARTIC交通規制オープンデータ
経路探索	Valhalla(端末内で動作)
地図描画	MapLibre Native ＋ PMTiles
地点・POI検索	端末内SQLite ＋ 国土地理院API
現在地・センサー	iOS標準

このうちValhalla(ルート検索エンジン)については少し詳しい解説がありました。GenVaviではValhallaを端末の中で動かしています。OSMのデータをそのまま扱えること、ルールやプロファイルを自分で書いて制御できることに加えて、端末内で動作するので山間部やトンネル内など通信が切れる区間でもナビを継続できる点が良いとのことです。

また、OSMを使って良かった点の1つに、原付の走行可否をサポートするようなタグがすでに入っており、これを使って道を案内できる点を挙げました。例を下表に掲げます。

タグ	意味
highway=motorway	自動車専用道路
motorroad=yes	自動車専用道路指定
motorcycle=no	二輪車通行禁止
motor_vehicle=no	車両通行止め

GenNaviで使う地図データは、当初はAppleのMapKitを使っていましたが、交通規制やルート表現を自由に重ねられることを重視してMapLibre Native＋PMTilesという構成に変えました。検索やジオコーディングもMapKitからスタートしましたが幾度かの作り直しを経て最終的には端末内SQLite＋国土地理院APIという構成に落ち着きました。データの作成と配信にはGitHub Actionsを利用しており、作成したデータは静的ファイルという形でCloudflare R2(分散型オブジェクトストレージ)に設置しています。端末ではmanifest.jsonを見て差分を取得し、あとはオフラインで動作します。このため通信量が少なくて済み、月額90円程度の費用で運用できているとのことです。

あきぞさんは主にセキュリティ分野のエンジニアで開発が主業務ではないため、開発はAIに9割ぐらいやってもらったそうです。しかしAIではできなかったこととして、JARTICの標識(緯度経度)とOSMの道路エッジの対応付けという問題がありました。これらは個別に作られたデータであり、座標が正確には一致しないので、どこまでを同じ地点とみなすかは開発者自身で考える必要がありました。結局これは自分で原付を走らせて交差点に行き、しきい値を調整することで対応したそうです。

GenNaviは原付ドライバーの安全を守るために開発したものですが、オープンデータやオープンな技術がなければ作れなかっただろうとのことで、OSMコミュニティへの感謝の意を表しました。

さらに詳しく知りたい方は発表資料をご覧ください。

水域マッピングことはじめ

発表者の大葉さんが代表を務める新光運輸株式会社は、大阪市内の河川で船を使って資材を運ぶ事業を行っています。船舶の位置を把握するためにboatmark™というシステムを開発しており、船舶に搭載したスマートフォンを使って船舶の位置を確認することができます。boatmark™の地図にもOSMが使われています。ここで課題となるのが「水域のマッピングはどうすればよいか」という話で、これが今回の発表テーマです。

まず、水域には住所に相当するものがありません。地上であれば住所がありますし、構造物にもタグが定義されています。船舶に関係する構造物も橋・防波堤・ダムなど、さらに海域における構造物でも埠頭・灯台・ブイなどにタグが定義されています。しかし、川や海の水面には住所がありません。もっとも船舶関係者の間では水域を指定するときに必要になるので、例えば最寄りの橋を基準に「堂島川 田蓑橋 下流左岸」というような名称で水域を指し示しています。

ここから水域マッピングの具体例として、橋のマッピングに関する説明がありました。詳細はOpenStreet Map WikiのJA:Tag:man_made=bridgeに記載されていますが、ここでは大阪市内の堂島川にかかる水晶橋を例に解説されました。

• 橋の周囲の水域をnatural=waterで示し、水域の種類をwater=riverとする
• 川の流れを示すためにwaterway=riverというタグを使用し、流れに沿って線を引く
• 橋の輪郭部分にmanmade=bridgeというタグを適用
• 橋の道路部分を示すためにhighway=footway(歩道の場合) bridge=yesといった形でタグ付け
• 橋の輪郭部分と道路部分のレイヤーを合わせるために両者にlayer=1というタグを設定

また、船舶が橋の下を通れるかどうかを判断する重要な情報が桁下高です。大葉さんの社内では多くの橋の桁下高データを持っていますが、これをOSMに取り込んでよいのかという疑問を提示されました。というのは、桁下高は潮位によって変化するので、いつの潮位を基準にするか、桁下がアーチ状の場合はどこを測るか、そしていつ誰が測定したかわからないなど、「OSMのデータは検証可能であること」というグッドプラクティスに反するため、安易にOSMに取り込むわけにはいきません。

この課題については大葉さん自身で考えてきた案を提示されました。それは、桁下高データを事業者コミュニティで検証し、確からしいデータであると合意できればオープンデータにすることができるのではないか、ひいてはそれをOSMのデータとしても使えるのではないかというものです。このような事業者由来のデータであっても公共性の高いものはOSMに取り込むことで、今まで以上にOSMの情報が豊かなものになることを期待したいと思います。

さらに詳しく知りたい方は発表資料をご覧ください。

パネルディスカッション

イベントの最後にパネルディスカッションが行われました。登壇者は置かず、モデレーターであり本イベントの運営者でもある坂ノ下勝幸さんが参加者にマイクを向けて話題を引き出し、それに他の参加者が自由にコメントする形式で進行しました。パネルディスカッションの主題は「OpenStreetMapがより一層活用されるためには」となっていましたが、実際には活用以外の話題も多く、多岐にわたって議論がなされました。その中からいくつかの話題を拾ってご紹介します。

もっと知られることが必要

最初に出た議論は「OSMがまだ多くの人に知られていないので、もっと存在をアピールした方がよいのでは」というものでした。例えばGenNaviを開発したあきぞさんも、2週間ぐらいAIと対話する中でようやくOSMの存在を知ったそうです。高校生の参加者からも「自分の高校でも5人ぐらいしか知らない」というコメントがありました。

では知ってもらうためにはどうすればよいかという観点で挙がったのが「OSMには公式のスマホアプリがない」という話題です。CoMapsなどOSMを利用した地図アプリはあるのですが、Googleマップに比べると動作が遅く使い勝手が良くないようです。それでもアプリがある方がユーザは増えるので登場が望まれる一方で、マネタイズが課題になりそうという意見もありました。

また、OSMはGoogleマップの競合と思われているかもしれないが、Googleマップは商業優先であるのに対してOSMは自由であることに第一の価値があるというように本質的に別の方向性を目指しているので、そこを忘れないようにしてほしいという意見もありました。

実現したいことのためにOSMは使えるか

OSMは自由に使えることに大きな価値がありますが、ではOSMは本当に各自が実現したいことのために使えているのかという議論もありました。例えばGenNaviは、商用の地図サービスを使っていたらおそらく実現できなかったであろうことがOSMだから実現できたと言えます。企業は売れないもの(＝需要の少ないもの)に多大なリソースをかけることはできませんが、OSMであれば需要の多寡に関係なく利用できます。

セッションの中で参加者から挙がった「実現したいこと」の例として、1つは自治体でのOSM利用の話題がありました。自治体は前例重視の傾向があるので、結局はどこかの自治体が先陣を切ってOSMを採用し、それが活用事例として広く認知されれば他に広がっていくという図式になりそうです。自治体での利用例として、滋賀県草津市による公開型GIS「くさつマップ」が紹介されました。

もう1つの「実現したいこと」の例はビジネスでの利用です。これに関しては、企業や自治体での採用を検討する際に品質の担保を求められることがありますが、OSMは品質を保証するものではないので、これがネックになりやすいという話がありました。OSMにレビューの仕組みがあれば品質が良くなる可能性はありますが、自由さが失われたり、レビューが煩雑だとデータの更新が鈍る可能性もありそうです。また、自社で地図データを持っている会社で働いている参加者からは、自社で持っていないデータがOSMにあり、それが使いたいものであれば使うので、品質の保証よりもデータを充実させることが重要ではないかという意見がありました。

コミュニティへの相談のしかた

もう一点、議論になったのがOSMコミュニティへの相談のしかたです。OSMFJではDiscordサーバーを運用しており、そこでさまざまな相談がもちかけられるのですが、反応がないとか鈍いことがときどきあり、相談した側が判断に困るという声がありました。これについてはコミュニティの運営側の立場にいる人から「コミュニティに提案して1週間程度様子を見て何もなければ進めるのがよい」という回答がありました。付け加えて、コミュニティは許可や承認を求める場ではなく対話をする場であるというコメントもありました。相談はお上にお伺いを立てるようなものではなく、お互いにコミュニティの一員として対等に話し合う場であると考えた方がよさそうです。また、OSM関連の作業をするにあたってドキュメントを参照することがありますが、ドキュメントの論調が厳しいので初学者に優しくないとか、コミュニティに相談しにくいという意見もありました。

それからコミュニティに関連して、OSMがコミュニティで維持されていることの意義についての話もありました。OSMは誰でもデータの更新ができますが、それを品質が落ちてしまうかもしれないリスクと考えてしまうと、OSMが持つ本来の良さが失われてしまいます。一番問題なのはデータが更新されないまま放置されることであり、あくまでも実在する地物に忠実なデータを載せていくことを前提に、これからもコミュニティでOSMを発展させていきましょうというコメントがありました。

おわりに

OpenStreetMapが事業者ではなく市井の人々の手によってメンテナンスされていることは知っていましたが、今回のカンファレンスに参加して、今まで以上にOSMに携わる皆さんの熱量を感じ取ることができました。こういったプロジェクトを支援できていることをとてもうれしく思いました。これからもOSMがより良いものになり、多くの場面で活用されるものになることを祈念しています。

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