MapConductorなぜ MapConductor か
地図機能を持つアプリのコードは、たいてい特定の地図 SDK に深く結びついています。乗り換えたくなったときに書き直すのは地図まわりだけでは済まず、画面のロジックにまで及びます。MapConductor は、その結びつきを 1 枚の共通 API に置き換えます。
01 · 何が問題なのか
料金と契約が変わる
地図 API の課金体系は変わります。乗り換えたいのに、アプリのコードがそれを許さない、という状況が起こります。
同じ機能を 3 回書く
Android・iOS・Web でそれぞれ別の地図 SDK を使うと、マーカーの扱いもカメラの意味も揃いません。仕様の議論が 3 回必要になります。
数値が一致しない
ズーム 14 が指す縮尺も、2 点間の距離も、SDK のユーティリティ任せにすると環境ごとにずれます。QA で「どちらが正しいのか」を毎回決めることになります。
件数が増えると破綻する
マーカーが数千を超えると、素朴な実装ではカメラ操作が重くなります。対策はプロバイダごとに違い、そのたびに書き直しになります。
02 · MapConductor の答え
アプリは統一 API にだけ依存します。プロバイダごとの差はドライバーが吸収し、切り替えは依存モジュールとビューの型を差し替えるだけになります。
座標も状態も共通
GeoPoint・MarkerState・MapCameraPosition は 3 プラットフォームで同じ名前・同じ意味です。プロバイダごとの型は出てきません。
ズームも距離も一致する
ズームは共通の尺度に正規化され、距離・方位・面積は SDK 自前の実装で計算されます。同じ入力なら、どのプロバイダでも同じ値が返ります。
状態を渡すだけ
「今あるべき状態の配列」を渡すと、Core が前回との差分を求めて必要な分だけ地図へ反映します。追加・更新・削除を自分で管理する必要はありません。
件数の問題は SDK 側で解く
マーカーが 2,000 個を超えると、内部のレンダリングエンジンが描き方をラスタータイルへ自動で切り替えます。数万件でもカメラ操作は滑らかなままで、アプリ側のコードは 1 行も変わりません。基準値は地図ビューのオプションで変更できます。
03 · 薄いラッパーではない
各 SDK のメソッドを呼び分けるだけのラッパーなら、できることは「一番機能の少ない SDK」に揃ってしまいます。MapConductor は足りない機能を自分で描いて埋めるため、プロバイダを変えても見た目と挙動が揃います。
04 · チームに効いてくること
共通 API を 1 枚挟むと、書けるコードの性質が変わります。地図 SDK の名前が出てこないコードは、プロバイダを変えても、別のプラットフォームへ移しても、そのまま残ります。
覚える API は 1 つ
地図 SDK はベンダーごとに概念も命名も違うため、プロバイダを変えるたび、プラットフォームを移るたびに覚え直しが発生します。MapConductor で覚えるのは 1 つの API だけで、Android・iOS・React のどこでも同じ名前・同じ意味のまま使えます。あるプラットフォームで得た知見はそのまま別のプラットフォームで通用し、チームに人が入るときに読む対象がプロバイダの数だけ増えることもありません。
地図 SDK に依存しないコード
GeoPoint や MarkerState は、どの地図 SDK にも属さない型です。経路を組み立てる、範囲に入るかを判定する、何を表示するかを決める ── こうしたロジックを地図 SDK の型から切り離して書けるため、プロバイダを変えても書き直しになりません。地図まわりの共通部品を、プロバイダごとに作り分けずにライブラリとして切り出すこともできます。
05 · データを配る側から見ると
ここまでは地図を組み込む側の話です。MapConductor が目指しているのはベンダーロックインからの解放だけではなく、どのベンダーに寄るかを地図 SDK の選択とは切り離して決められるようにすることでもあります。
商用 SDK を使うことになる
完全にオープンな地図を使う場合を除けば、実運用ではどこかの商用地図 SDK を使うことになります。契約や調達の都合で、その選択肢が最初から 1 つしかないこともあります。MapConductor が効くのは、そうした状況でも手持ちのリソースを捨てずに済むことです。
地図 SDK とデータを切り離す
地図データ・ジオコーディング・タイルといったリソースは、それを提供するベンダーの地図 SDK とセットで使うのが前提でした。両者を分けられれば、たとえば ArcGIS に蓄積したコンテンツを別の地図 SDK の画面の上で使う、といったことが成り立ちます。
ジオコーディングだけ、データだけ
ジオコーディングだけ、特定分野のデータだけを持つ提供者は、自前の地図 SDK を持たないために使われる場面が限られてきました。表示側と切り離せれば、どの地図の上でも使ってもらえるようになります。
06 · 地図 SDK プロバイダから見ると
共通レイヤーは、地図 SDK を提供する側にとって自分の存在を薄めるものに見えるかもしれません。MapConductor はそう設計していません。共通化するのはどのプロバイダにもある部分だけで、各社の強みはそのまま外に出しています。
外から来る顧客
複数のプロバイダが同じ書き方で扱えるようになると、他社の SDK で作られたアプリからも候補として見てもらえるようになります。乗り換えの敷居が下がることは既存顧客を引き止める力を弱める方向にも働きますが、その分、選ばれる理由が「乗り換えられないから」ではなく、価格・カバレッジ・描画品質そのものになります。
強みは隠さない
共通化しているのは、どのプロバイダにも存在する基本的な機能だけです。状態オブジェクトの getMapViewHolder() を呼べばネイティブの地図ビューと地図インスタンスがそのまま取り出せるので、そのプロバイダにしかない機能は各社の API で直接書けます。完全に覆い隠すラッパーであれば差別化要因が消えますが、そうはしていません。
共通の土台の上で競う
ブラウザが HTML5 で実装を揃えたあと、各ブラウザは互換性を保つこと自体ではなく、速度や機能そのもので競うようになりました。地図 SDK も同じで、共通のインタフェースが定まれば、その上でどれだけ速く・正確に・広い地域を描けるかが問われるようになります。共通化は個々の SDK の進化を止めるものではなく、進化の向きを揃えるものだと考えています。
07 · 向いている場合・いない場合
- 複数プラットフォームで同じ地図体験を出したい
- 将来プロバイダを変える可能性を残しておきたい
- マーカー・図形・カメラといった標準的な地図表現が中心
- 数千〜数万のマーカーを扱う
- 距離や面積の表示に一貫性が求められる
- 特定プロバイダ固有の高度な表現が主役（独自シェーダー、ベンダー専用レイヤー）
- ターンバイターンのナビゲーションなど、SDK の専用機能そのものが目的
- 1 プラットフォーム・1 プロバイダで完結し、今後も変える予定がない
ただし部分的な併用はできます。ネイティブの地図インスタンスには常に手が届くので、特殊な部分だけプロバイダ固有のコードで書く構成が可能です。