Azure Maps Creator による屋内マップは 2025 年 9 月 30 日で提供終了となります。既にタイルセットで屋内フロア図を重ねているシステムでは、「どこまで消せば安全か」「地図の基本機能に影響はないか」を早めに整理しておくことが重要です。本記事では、公式情報を踏まえつつ、実務で押さえるべき影響範囲と撤退手順・移行オプションを具体的に解説します。
Azure Maps Creator（屋内マップ）提供終了の概要
まずは「何が終わって」「何が残るのか」を整理します。
Microsoft のアナウンスでは、Azure Maps Creator の Indoor Map Service と Creator Service APIs（v2 および 2023-03-01-preview）が 2025 年 9 月 30 日にリタイアするとされています。 また、Feature State API や関連サービスも 2025 年中に順次終了予定としてライフサイクル情報に掲載されています。
さらに Azure Maps Web SDK の Indoor Module（azure-maps-indoor）も Creator と一体で提供されており、同じタイミングでサポート終了になる旨がドキュメントに記載されています。
一方で、Azure Maps 全体が終わるわけではなく、「屋内マップを扱う Creator 関連のサービスのみが終了対象」であることが、Microsoft Q&A の回答でも明確にされています。
| 対象 | 主な機能 | 2025/9/30 以降 |
|---|---|---|
| Azure Maps Creator Indoor Map Service | 屋内マップデータ取り込み・変換、タイルセット生成 | 提供終了（利用不可） |
| Creator Feature State API | 部屋の空き状況・設備状態などの動的ステータス管理 | 2025 年 3 月頃までに終了予定 |
| Azure Maps Web SDK Indoor Module | フロア切り替え UI／屋内スタイル／Creator データ連携 | 2025/9/30 で実質利用不可 |
| Creator On-Boarding Tool / QGIS プラグイン | 屋内マップ用のデータ準備・編集 | Creator と合わせて終了 |
| Azure Maps（Render/Search/Route など） | ベースマップ、検索、ルーティング、トラフィック等 | 継続提供（今回の廃止対象外） |
つまり、今回のリタイアの主役は「屋内マップ専用の Creator 関連」だけであり、通常の地図表示・マーカー描画・シンボル／ライン／ヒートマップなどの基本レイヤー機能は従来通り利用を継続できます。
Azure Maps 基本機能への影響有無
ユーザーから最も多い質問は、「屋内マップが使えなくなると、マーカーやシンボルレイヤーなども巻き添えで動かなくなるのか？」という点です。
Microsoft の回答でも明示されている通り、今回リタイア対象となるのは Creator indoor map service のみであり、Azure Maps の基本機能（ベースマップやシンボルレイヤー、ラインレイヤー、ヒートマップなど）は「非推奨・リタイアのアナウンスは出ていない」とされています。
| 機能 | Creator 依存 | 今回の影響 | 注意ポイント |
|---|---|---|---|
| ベースマップ表示（道路地図、航空写真等） | なし | 影響なし（継続利用可） | Render v1 など別のリタイア情報には注意 |
| ピン／マーカー | なし | 影響なし | 屋内フロア座標を使っていれば、表示位置の見直しは必要 |
| シンボルレイヤー | なし | 影響なし | 屋内向けアイコンの凡例 UI をどうするか検討 |
| ライン／ポリゴンレイヤー | なし | 影響なし | フロア別経路表示を Creator 上で管理していた場合は代替設計が必要 |
| ヒートマップレイヤー | なし | 影響なし | 屋内センサー値を Creator の Feature State 経由で取っている場合は別バックエンドに移行 |
| 凡例・レイヤー切り替え UI（自作） | 実装次第 | UI ロジックに Creator 固有の前提があると影響あり | 屋内レイヤーの項目は非表示・削除など UI 調整が必要 |
まとめると、Creator 由来のタイルセットや Indoor Module をきれいに外してさえおけば、Azure Maps Web SDK 自体の基本 API やレイヤー機能はそのまま動き続けます。「ベースマップ＋各種レイヤー」を使うシンプルな構成であれば、影響は限定的です。
アプリ側で必要な対応チェックリスト
ここからは、実際にアプリケーション側で何をすれば良いのかをチェックリスト形式で整理します。
Creator 依存アセットの撤去
- 屋内用タイルセット（Creator が生成したベクトル／ラスタタイル）の URL をソース定義から削除
- それらを参照しているレイヤー（フロアポリゴン、部屋ポリゴンなど）の定義を削除
- タイルセットを前提にしているスタイル設定（特定プロパティ名を前提としたフィルターなど）の整理
実務的には、次のような観点でコードを洗い出すと効率的です。
creatorやindoorを含む URL やパスの grep- 屋内マップ用レイヤー ID（例：
indoor-floor,building-outlineなど）をキーにした検索 - スタイル JSON 内で Creator 由来のソースを参照している項目の削除
削除後は、ブラウザの開発者ツールでネットワークログを確認し、Atlas（Azure Maps）のドメインに対して 404/410 のリクエストが飛んでいないかを確認しましょう。これが残っていると、将来 Creator 側が完全にクリーンアップされたタイミングで急にエラーが顕在化します。
Creator REST API 呼び出しを止める
サーバーサイドやバッチ処理で次のような API を呼び出していないか確認します。
- 屋内マップデータのインポート・変換 API
- タイルセット生成・更新 API
- Feature State API（会議室の空き状況、センサーデータの状態管理など）
- Creator 管理系 API（スペース構造の更新など）
| 処理種別 | 影響 | 推奨対応 |
|---|---|---|
| 夜間バッチで屋内タイルを再生成 | リタイア後はエラー／失敗 | ジョブ停止または処理フロー自体を削除 |
| Webhook 等から Creator に状態連携 | リタイア後は書き込み不能 | 別バックエンド（DB や他サービス）に切り替え |
| 管理画面から Creator API を叩くツール | 管理機能が破綻 | 機能撤去または代替ツールを検討 |
特に見落としがちなのが「一度作ったきりほぼ触っていないバッチジョブ」です。インフラ側のスケジューラ設定（Azure Functions Timer、Logic Apps、VM 上の cron など）も含めて棚卸ししましょう。
設定・権限・インフラ構成の棚卸し
Creator を前提に設定していた各種情報も、忘れず整理します。
- 環境変数・設定ファイル
- Creator 固有の API スコープやエンドポイント URL
- Feature State 用のテーブル名やバージョン番号
- 権限・認可
- Azure AD アプリに付与している Creator 関連ロール／スコープ
- API キーを Creator 用と汎用 Azure Maps 用で分けている場合の整理
- キャッシュ・CDN・Service Worker
- Service Worker で Creator タイルをプリキャッシュしている実装
- CDN のルールに Creator パス向けの設定が残っていないか
不要な権限や API キーを残したままだと、セキュリティ監査の観点でも「何に使われているかわからない資格情報」が増えてしまいます。Creator 関連を削ったタイミングで、API キーやロールもスリムにしておくとリスク低減につながります。
フロントエンドの防御的実装
Creator 関連レイヤーを外したあとでも、JavaScript や TypeScript のコードが以下のような前提を持っていると、実行時エラーの原因になります。
- 存在しないレイヤー ID を前提に
map.layers.getLayerById()やmap.layers.remove()を呼んでいる - 屋内フロア切り替え UI が Creator のデータ構造を前提にしている
- 「屋内レイヤーが前面にある」ことを前提にしたスタイル調整を行っている
対策としては次のような実装が有効です。
- レイヤー操作前に存在チェックを行う
- Creator 利用の有無を表すフラグ（例：
hasIndoorMap）を設け、UI の表示／非表示を分岐 - 屋内レイヤー向け凡例やトグルボタンを feature flag で簡単に ON/OFF できるようにする
こうしておくと、将来的に別の屋内マップソリューションへ乗り換える場合も、hasIndoorMap の背後の実装だけを差し替えればよくなり、アプリ全体への影響を局所化できます。
回帰テストと確認観点
Creator を外した後でも、「地図として当たり前に動く」ことを必ず確認します。特に次のようなシナリオは最低限押さえたいところです。
| テストシナリオ | 期待結果 | 確認ポイント |
|---|---|---|
| アプリ起動～地図初期表示 | エラーなくベースマップが表示される | コンソールエラーなし、ネットワークに 4xx/5xx が出ていない |
| マーカー表示・クリック | マーカーが正しい位置に表示され、ポップアップも表示 | 座標系の変換ロジックが Creator データ前提になっていないか |
| シンボル／ライン／ポリゴン描画 | ズームイン・アウトしても期待通りに描画される | レイヤーの順序が崩れていないか（屋内レイヤー削除の影響） |
| ヒートマップ表示 | ヒートマップの色分布が妥当 | データソースが Creator ではなく別バックエンドを参照していること |
| 凡例・レイヤー切り替え UI 操作 | 屋内関連の項目が残っていない／グレーアウトされている | クリック時に未定義レイヤーを参照していないか |
屋内マップ機能を残したい場合の代替案
「一旦屋内は諦める」のも選択肢ですが、ビル設備管理やオフィス可視化など、屋内マップがサービスの中核となっているケースでは代替手段を検討する必要があります。
選択肢 1: 外部の屋内マッピングサービスを採用
海外を中心に、屋内マップ SaaS や PaaS は複数存在します。ここでは製品名には踏み込まず、観点だけを挙げます。
- フロアマップ管理機能
- CAD 図面からの自動インポート対応
- フロア別のスタイル設定、ゾーニング（会議室・執務エリア等）の柔軟さ
- API・SDK
- Web SDK で Azure Maps と共存できるか（オーバーレイとして載せられるか）
- モバイル SDK（iOS/Android）があるか
- ナビゲーション機能
- 屋内ルーティング（部屋間の経路案内）に対応しているか
- 車椅子ルート、エレベータ優先などの条件指定が可能か
- 運用・管理
- 誰がマップを更新するのか（情報システム部門か、総務・ファシリティか）
- 変更ワークフロー（下書き→レビュー→公開）を持てるか
Azure Maps のベースマップと組み合わせたい場合は、「屋内マップを独自タイルや GeoJSON として出力し、Azure Maps に載せられるか」を事前に確認しておくと移行がスムーズです。（ライセンス条件や利用規約も要確認です）
選択肢 2: 自前のベクターデータ＋カスタムレイヤーで実装
要件がシンプル（「フロア図を表示できればよい」程度）であれば、Creator の代わりに以下のような構成で「ミニマムな屋内マップ」を自前実装することも可能です。
- フロア図を GeoJSON またはベクトルタイルとして用意
- CAD 図面を GIS ツール（QGIS 等）でポリゴンに変換
- 部屋ごとに
roomId,floorCode,usageTypeなどの属性を付与
- データをホスティング
- Azure Blob Storage や静的サイトホスティングで配信
- 更新頻度が高い場合は CI/CD で自動デプロイ
- Azure Maps Web SDK 側でカスタムレイヤーとして読み込み
- GeoJSON DataSource を使ってポリゴンレイヤーを描画
- フロア切り替えは
floorCodeプロパティによるフィルタで制御
こうした自前実装は、Creator のような高機能さはないものの、「見えること」が目的であれば十分実用的です。さらに、Feature State API の代わりに自前のバックエンド（テーブルストレージ、Cosmos DB 等）を用意すれば、会議室のステータスやセンサー値を屋内ポリゴンのスタイルに反映させることもできます。
選択肢 3: 屋内マップを使わない UI への刷新
より思い切った選択肢として、「屋内マップという表現をやめる」という方向性もあります。
- 会議室予約や席情報
- テーブル表示＋検索・フィルタに置き換える
- 「部屋の人気度」「利用率」をチャートで可視化
- 設備の位置情報
- フロア別リスト＋アイコンで表現
- 必要な場合だけ PDF の図面を開く方式にする
「地図で見せたいのか」「情報を分かりやすく伝えたいのか」を改めて問い直し、後者が優先なら地図に拘らない UI も選択肢として持っておくと、将来の API 変更にも強い設計になります。
よくある落とし穴と対策
Creator 撤退時に陥りがちなポイントと、その対策をまとめます。
| 落とし穴 | 症状 | 検出方法 | 対策 |
|---|---|---|---|
| 残存参照（古いタイル URL／レイヤー ID） | リリース後しばらくしてから 404 が増える、特定画面だけ描画されない | コード一括検索＋ネットワークログ監視 | Creator 関連の文字列をキーに一括削除し、CI で簡易チェックを追加 |
| 権限エラー（Creator 用スコープの残骸） | 一部 API だけ 401/403 が発生し原因が分かりにくい | 認証・認可周りのログを確認 | アプリ登録のロール・スコープを棚卸しし、不要なものは削除 |
| UI 崩れ（屋内レイヤー前提のデザイン） | フロア切り替え UI が空っぽ、凡例に意味のない項目が残る | 実機で UI を一通り操作 | 屋内関連 UI を feature flag で無効化、または代替表示に差し替え |
| Feature State 依存のロジック | 会議室空き状況などが常に「不明」になる | 状態取得 API の呼び出しログを確認 | 状態管理を自前バックエンドに移行し、描画ロジックを切り替え |
| モバイルアプリ側の取りこぼし | Web は直したが、ネイティブアプリだけ落ちる／地図が表示されない | 全クライアント種別（Web／iOS／Android）でテスト | Azure Maps Native SDK のライフサイクルも含めて整理し、実装を見直す |
最小検証シナリオの具体例
「完璧な試験計画までは作れないけれど、最低限のリスクは潰しておきたい」という状況向けに、簡易的な検証シナリオを具体化してみます。
- ステージング環境で Creator 関連のソース／レイヤーをコメントアウトまたは削除したブランチをデプロイ
- ブラウザの DevTools を開き、Azure Maps 関連リクエスト（
atlas.microsoft.comなど）に 4xx/5xx が無いか確認 - 次の操作を一通り実行
- 地図のズームイン／ズームアウト
- マーカーの表示／クリック
- シンボルレイヤー・ラインレイヤー・ヒートマップの表示切り替え
- 凡例やフィルタ UI の操作
- ログを確認し、Creator 関連の API 呼び出しやエラーが出ていないことを確認
- 主要ユースケース（検索→地図表示→詳細表示など）を業務担当者にも触ってもらい、「業務上の違和感」がないかをフィードバックしてもらう
このくらいの検証でも、「Creator を外したことによる明らかな不具合」はかなりの確度で洗い出せます。余力があれば、自動テスト（E2E テスト）に「Azure Maps Creator を使わない前提」のシナリオを追加しておくと、今後のリファクタ時にも安心です。
スケジュール感のイメージと優先度付け
提供終了日が決まっている以上、「気付いたら使えなくなっていた」を避けるには、ざっくりとしたスケジュール感を持っておくことが重要です。
| フェーズ | 主な作業 | ポイント |
|---|---|---|
| 現状把握 | Creator 利用箇所の洗い出し、影響範囲の可視化 | ソースコード検索＋アーキテクチャ図の更新 |
| 撤退方針決定 | 「屋内マップを止めるのか」「代替を入れるのか」を決める | ビジネス側と合意形成することが重要 |
| 実装・テスト | Creator 依存の削除、UI 調整、代替実装（必要に応じて）、回帰テスト | Web・モバイルなど全クライアントを対象にする |
| 本番反映と監視 | 本番環境へのデプロイ、ログ・メトリクス監視 | リリース後しばらくはネットワークエラーとユーザー問い合わせを注視 |
特に、屋内マップが「Nice to have」なのか「無いと業務が止まる」のかで優先度は大きく変わります。前者であれば、まず Creator 依存を外して安全側に振り、その後ゆっくり代替案を検討するという進め方も現実的です。
Q&A：よくある疑問への回答
Q. オーバーレイ用タイルセットを外す以外に、埋め込み側で気をつけることは？
A. 主に次の 3 点です。
- 屋内マップ前提の UI（フロア切り替え、屋内凡例）をどう扱うかを決める
- Creator 関連の REST API 呼び出しが完全に止まっていることを確認する
- Indoor Module（azure-maps-indoor）を読み込んでいる場合、そのスクリプトや初期化コードも削除する
単にタイルセット URL を削るだけだと、「UI は残っているのに何も表示されない」「内部で失敗リクエストが出続ける」といった中途半端な状態になりがちです。UI／API／設定の 3 レイヤーを意識して整理しましょう。
Q. マーカー、シンボルレイヤー、ラインレイヤー、ヒートマップ、凡例などの基本機能に影響はない？
A. 現時点の情報では、これら Azure Maps の基本機能に対して「非推奨・提供終了」のアナウンスは出ておらず、Creator のリタイアだけが対象であると明言されています。
ただし、実装としてこれらのレイヤーが Creator 由来のデータに強く依存している場合（例：フロアポリゴンの ID に紐づくシンボルレイヤーなど）は、データ構造の見直しが必要になる点に注意してください。
Q. Creator を放置するとどうなる？
A. リタイア日以降は Creator 関連エンドポイントからエラーが返るようになり、屋内マップの表示や更新ができなくなります。
最悪の場合、アプリ起動時に例外が発生して地図全体が表示されない、といった影響もあり得るため、「使っているかよく分からないから様子見」ではなく、早めに利用有無を棚卸ししておくのが安全です。
まとめ：Creator だけをきれいに外せば、地図は引き続き使える
本記事のポイントを整理します。
- 2025 年 9 月 30 日に提供終了となるのは、Azure Maps Creator の屋内マップ関連サービス（Indoor Map Service や Creator APIs）であり、Azure Maps 全体ではない
- マーカー、シンボルレイヤー、ラインレイヤー、ヒートマップ、凡例などの基本機能については、現時点で廃止アナウンスはなく、Creator を外しても継続利用できる
- ただし、Creator 由来のタイルセット／レイヤー／API／UI を中途半端に残すと、将来のエラーや UI 崩れの原因になるため、計画的な撤去が必要
- 屋内マップがビジネス上重要であれば、外部屋内マッピングサービス、自前ベクターデータ＋カスタムレイヤー、あるいは屋内マップに依存しない UI への刷新など、いくつかの代替案が考えられる
「Creator 由来の屋内マップ部分だけを段階的に撤去する」ことさえできれば、Azure Maps の基本機能はそのまま活かし続けることができます。まずは自システムで Creator をどこまで使っているかを棚卸しし、本記事のチェックリストを参考に安全な撤退・移行計画を立ててみてください。
コメント