ZapierやMakeの自動化を新しいジオコーディングホストへ移行する
ジオコーディングのステップを含むノーコードの自動化には、独自のコードとは異なる移行方法が必要です。その切り替えの進め方を紹介します。
プロバイダーごとの一括処理対応の比較
数千件の住所が入ったスプレッドシートを一度に処理する、あるいは1回限りのクリーンアップ作業として顧客データベース全体をジオコーディングするといった一括ジオコーディングのニーズへの対応はプロバイダーによって異なり、移行を計画する際には、その違いが一見して思うよりも大きな意味を持ちます。
一部のプロバイダーは一括作業専用のWebインターフェースを提供しています。CSVをアップロードし、処理を待ち、新しい列が追加された結果をダウンロードするという形です。これは技術者ではないユーザー、たとえば住所を一度だけジオコーディングする必要があり、コードを書きたくない運用チームやマーケティングチームのメンバーに向いていますが、プログラムから使うAPIとは別の製品であり、それに依存している場合は独自の移行計画が必要です。
ほかのプロバイダーは、一括ジオコーディングをすべてプログラムから使うAPIで処理することを前提としています。個別のリクエストを多数、多くの場合はある程度並行して送り、結果は自分で組み立てます。これにより、再試行の動作、並行数の上限、大きなバッチ内での部分的な失敗の扱い方の決定など、呼び出し側のアプリケーションがより多くを制御できます。
プロバイダーがどちらの方式をとっていても、プロバイダーに依存しない教訓がいくつかあります。
- 大きなバッチ内で失敗した個々のリクエストに対する再試行ロジックを必ず組み込みましょう。1万件のうち1件の住所がエラーを返しただけでジョブ全体が失敗するバッチは、プロバイダーに関係なく脆い設計です
- APIのドキュメントに記載されているレート制限や割り当ての仕組みを守りましょう。できるだけ速くリクエストを送り続ける単純なループは、一括ジョブがスロットリングや予期しないコストに見舞われる最もよくある原因です
- バッチ単位だけでなくリクエスト単位でも十分な詳細をログに残し、失敗した一部を特定して、ジョブ全体を最初からやり直すことなく再処理できるようにしましょう
My Geocodeの一括作業に対するアプローチは、プログラムによるパターンに沿っています。リクエストはほかの検索と同じエンドポイントを通り、同じ認証方法（X-API-Keyヘッダー、Authorization: Bearer、HTTP Basic認証、またはクエリパラメータ）を使い、/docs/rate-limits/に記載されているとおり、すべてのリクエストでX-Quota-UsedやX-Quota-Free-Remainingといったレスポンスヘッダーによって同じように割り当ての状況を確認できます。大規模な1回限りの一括ジョブでは、この割り当ての可視性がジョブのペースを自動的に調整するのに非常に役立ちます。スクリプトが各レスポンスでX-Quota-Free-Remainingを確認し、安全なリクエスト速度を推測する代わりに、それに応じて自らを調整できるからです。
料金はすべてのエンドポイントで一律（1リクエストあたり€0.0001のプリペイドクレジット、または月額€50のUnlimitedキー）なので、処理が必要な住所の件数がわかれば、大規模な一括ジョブのコストは単純な掛け算で求められます。交渉したり、継続的なリクエスト単位の利用と比較したりする別の一括料金体系はありません。毎月の顧客リストのクリーンアップであれ1回限りのデータ移行プロジェクトであれ、定期的な一括ワークフローを移行するチームにとって、この一律で予測しやすいリクエスト単位のコストのおかげで、予算編成は移行全体のなかで最も簡単な部分になりがちです。