ZapierやMakeの自動化を新しいジオコーディングホストへ移行する
ジオコーディングのステップを含むノーコードの自動化には、独自のコードとは異なる移行方法が必要です。その切り替えの進め方を紹介します。
移行中のレスポンススキーマの違いへの対処
どれほど慎重に合わせた代替プロバイダーでも、元のプロバイダーとは少なくともいくつかの小さな点で異なります。そうした違いを本番環境で表面化する前に見つけることは、顧客から何かがおかしいと報告されてから気づくこととは、意味のある形でまったく異なる作業です。スキーマ比較に体系的に取り組めば、こうした違いの大半を、早い段階で、低コストに、騒ぎを起こすことなく見つけられます。
出発点として役立つのは、違いを3つのカテゴリーに分けることです。カテゴリーごとに必要な対応が異なるからです。
フィールドの有無の違い。コードが読み取るフィールドが、あるプロバイダーのレスポンスには存在し、別のプロバイダーのレスポンスには存在しない、あるいは条件付きでしか存在しないことがあります。これは静的な比較で最も見つけやすいカテゴリーです。同じ入力に対する各プロバイダーのレスポンスのサンプルを取り、フィールドの一覧を直接比較してください。
フィールドの型や形式の違い。概念的には同じ値が、異なる形で表現されることがあります。座標が2つの別々の数値フィールドなのか、1つにまとめた文字列なのか、信頼度スコアが0から1の間の数値なのか、カテゴリー(「high」「medium」「low」)なのか、あるいはタイムスタンプがまったく別の形式なのか、といった違いです。これを見つけるには、フィールド名だけでなく、実際の値を読む必要があります。
フィールド名が同じでも意味が異なる違い。これは最も難しいカテゴリーで、2つのプロバイダーがまったく同じフィールド名を使いながら、その意味が微妙に異なるものです。たとえば「accuracy」フィールドを、あるプロバイダーは住所の構成要素の一致度に基づいて評価し、別のプロバイダーはまったく異なる独自の手法に基づいて評価している、といったケースです。フィールド名に基づく比較だけではこれは見つけられません。それぞれのシステムで値が実際に何を表しているかを理解する必要があり、通常は、同じ名前だから同じ意味だと決めつけず、両方のプロバイダーのドキュメントを注意深く読むことになります。
実践的な手順は次のとおりです。実際の過去のリクエストから代表的なサンプルを取り出し(理想的には、少なくとも最もよくあるリクエストのパターンと、既知の厄介なエッジケースを網羅するもの)、それを旧プロバイダーと新プロバイダーの両方に対して実行し、いくつかの例を目で見て確かめるのではなく、体系的に結果を比較します。ごく小規模な連携でない限り、この比較を自動化することは、たとえ構造上の違いや大きな値の違いにフラグを立てるだけの簡単なスクリプトであっても、準備にかける時間に見合う価値があります。
My Geocodeの互換ホストは、それぞれが再現するプロバイダーについて、最初の2つのカテゴリーの違いを最小限に抑えるよう特別に作られています。著作権、利用規約、プライバシーに関する文言を除き、フィールドの有無と形式を完全に一致させており、その内容はホストごとに/docs/compatibility/で説明しています。そのため、互換ホストを使う場合でも、直接テストすべき主な対象は3つ目のカテゴリー、つまり同じフィールド名の下での意味の違いになります。形式が一致していても、その背後にある手法の一致が完全に保証されるわけではないからです。
よくある住所をいくつかテストして成功しただけで十分とせず、移行を完了とみなす前にこの比較作業のための時間をきちんと確保することは、気づくまでに何週間もかかり、実際の原因を突き止めるまでにさらに時間がかかるような、微妙なデータ品質の問題を避けるための、より確実な方法の1つです。