ZapierやMakeの自動化を新しいジオコーディングホストへ移行する
ジオコーディングのステップを含むノーコードの自動化には、独自のコードとは異なる移行方法が必要です。その切り替えの進め方を紹介します。
TomTom Searchからの移行
TomTom Searchは、自動車、フリート管理、ナビゲーションのソフトウェアで広く使われています。これらの業界では、ルート沿いのジオコーディング精度が単純な住所の一致と同じくらい重要です。APIキーはクエリパラメータとして送信し、ジオコーディングのレスポンスはresults配列として返され、positionオブジェクトと、freeformAddressやmunicipalityなどのフィールドを含むaddressブロックを持ちます。
この分野のソフトウェアは、TomTomを軽い気持ちで選んだわけではないチームによって作られていることが多いものです。その判断は通常、すでに他の選択肢との比較評価を経ています。そのため、後の移行はデータそのものへの不満ではなく、コスト、冗長化の計画、あるいはより広いベンダー統合の取り組みがきっかけになる傾向があります。この背景は移行の範囲の決め方に影響します。急を要することはまれで、たいていは適切にテストする時間があります。
My GeocodeのTomTom互換ホストは、results配列、positionオブジェクト、addressフィールドをTomTomが返すとおりに正確に再現しており、違いは著作権、利用規約、プライバシーに関する文言だけです。フィールドのリファレンスは/compatibility/tomtom/にあります。results[0].position.latやresults[0].address.freeformAddressを前提に作られたコードは、ホストとキーを変更すればそのまま動作するはずです。
特にフリートや自動車向けのソフトウェアでは、切り替えを本番に反映する前に、いくつかの点を再確認しておく価値があります。
- スケジュールに沿って実行されるバッチのジオコーディングジョブ。顧客向けのリアルタイムの呼び出しに手を付けずに新しいホストをテストするための、最初の対象として適しています
- TomTom特有の応答時間に合わせて調整したリトライとタイムアウトの処理。これらの値はドキュメントに基づくのではなく経験的に設定されていることが多く、再調整が必要になる場合があります
- TomTom固有の信頼度や一致品質のフィールドを読み取るコード。互換ホストのドキュメントに記載された同等のフィールドと並べて比較する価値があります
認証はX-API-Keyヘッダー、Authorization: Bearerヘッダー、HTTP Basic認証、クエリパラメータに対応しており、既存のTomTomクライアントが現在どの方式でキーを送っていてもカバーできます。
コスト面では、この体系により通常の企業向けの交渉の手順がなくなります。キーなしで1日あたり2,500リクエストが無料で、各キーにはさらにネットワーク単位でカウントされる1日あたり2,500リクエストの無料枠が加わります。その割り当てを超えると、1リクエストあたり€0.0001のプリペイドクレジット、または月額€50のUnlimitedキーとなり、この互換ホストを含むすべてのエンドポイントが同じ料金です。相当な量のジオコーディングを実行するフリート運用にとって、段階的な企業向け契約ではなく1つの一律料金であることは、コストの予測をかなり簡単にします。
TomTomの利用にジオコーディングだけでなくルーティングや交通データも含まれている場合、その部分はジオコーディングのみの移行の対象外であり、住所検索の呼び出しを独立して移す間もTomTomに残しておけます。このように機能の明確な境界に沿って移行を分けるほうが、すべてを1回のリリースで移そうとするよりもリスクを減らせる傾向があります。