FivetranがDelightedコネクターの提供を終了

Fivetranは、Delighted APIの廃止に伴いDelightedコネクターの提供を終了しました。

要点

• 新しいDelightedコネクターは作成できません。
• 既存の同期先、下流モデル、報告処理への影響確認が必要です。
• 代替取得方法では項目、履歴、更新頻度の同等性を検証します。

今回の更新で変わること

提供元APIの廃止により、Fivetran側でコネクターを継続できなくなりました。新規作成だけでなく、既存接続がいつまで動くか、停止後に履歴データがどこへ残るかを確認する必要があります。Delightedのデータを参照する変換モデル、ダッシュボード、顧客満足度の定期報告を一覧化し、最終同期時刻を監視してください。

代替手段へ移る場合は、列名や型だけでなく、回答の更新・削除、ページング、タイムゾーン、増分取得の基準を比較します。過去データを再取得できない可能性に備え、既存の保存先を保全し、新旧経路を重ねて件数と主要指標を照合する期間を設けるのが安全です。

影響調査では、コネクター名を参照する設定だけでなく、出力スキーマの表名、顧客識別子、満足度指標を使う下流処理を確認します。同期停止が失敗として通知されるのか、更新がない正常状態に見えるのかも重要です。最終取得日時を監視指標に加え、一定時間更新されなければ担当者へ通知することで、静かな停止を見逃しにくくなります。

代替経路の採用後は、過去の修正や削除が反映されるか、同じ回答が重複しないかを検証します。取得規約やAPI利用条件が変わる場合は、費用と保守責任も再評価してください。経営報告に使う指標では、移行日を注記し、新旧経路の差が時系列の変化として誤解されないようにする必要があります。

移行完了後も旧テーブルを直ちに削除せず、監査と再計算に必要な期間だけ読み取り専用で保持し、削除予定日を明記します。 停止した接続の資格情報と不要な権限も、保全確認後に整理してください。 また、利用部門へ停止日と代替経路を共有し、移行期間中の数値差を障害と誤認しないよう問い合わせ窓口を決めます。外部API終了が原因であること、Fivetran側の再有効化では復旧できないことも運用記録に残してください。

関係しそうなチーム

Fivetran管理者、Delightedデータを利用する分析担当、顧客体験の報告を運用する部門に関係します。

実務で確認したいポイント

1. 既存コネクターと下流依存を特定します。
2. 最終同期と履歴保全の条件を確認します。
3. 代替経路を並行稼働して差分を検証します。

結局、この更新をどう読むべきか

設定変更では吸収できない提供終了です。データが止まってから気付くのではなく、履歴を保全し、下流の報告まで含めて移行してください。