Confluent Cloud、Salesforce Source V2 Connector のドキュメント更新を確認

Confluent Cloud のドキュメントで、Salesforce Source V2 コネクター が 2026年6月3日のリリース候補として検出されました。Salesforce のデータを Confluent Cloud に取り込み、Kafka トピックとして利用するチームは、移行、初期スナップショット、ストリーミング切り替え、エラー処理の設計を確認したい更新です。

要点

• Salesforce Source V2 コネクター は、Salesforce から Confluent Cloud へデータを取り込むマネージドコネクタ
• 初期スナップショットからストリーミングへの引き継ぎ、重複回避、GAPイベントの回復などが重要な論点
• Salesforce Bulk API 2.0 Source や CDC Source からの移行項目も確認対象
• エラー処理設定は、ソースコネクタではデータ欠落につながる可能性があるため慎重に扱う必要がある
• 本番利用では、トピック設計、スキーマ、権限、再処理、監視を合わせて確認したい

今回のリリース候補で語られていること

このドキュメントは、Salesforce Source V2 コネクター を Confluent Cloud で使うためのクイックスタートと設定項目をまとめています。Salesforce は営業、顧客管理、商談、サポートなどの業務データの中心になることが多く、その変更をストリーミング基盤へ取り込めると、顧客360、リアルタイム分析、イベント駆動の業務連携に使いやすくなります。一方で、Salesforce の取り込みは、単にコネクタを追加するだけでは終わりません。初回に大量データを取り込むスナップショットと、その後の継続的な変更取得をどうつなぐかが重要です。

ドキュメントでは、初期スナップショットからストリーミング処理へ移る際のハンドオフ、開始時のイベント欠落回避、重複イベントの扱い、GAPイベント回復、カスタムオフセット管理などが見出しとして並んでいます。これは、SalesforceデータをKafkaへ入れる際に起こりやすい実務上の問題です。初期ロードと差分同期の境界が曖昧だと、同じレコードを重複処理したり、逆に更新を取り逃がしたりします。 downstream の分析や業務システムがそのイベントに依存している場合、データ品質問題として表面化します。

また、エラー処理設定にも注意が必要です。ソースコネクタで errant records の扱いを緩めると、コネクタは止まらずに進みますが、欠落や後追い調査の難しさが増す可能性があります。SinkコネクタのDLQとは性質が違うため、運用チームは「止まるほうが安全なケース」と「ログに残して継続するケース」を分ける必要があります。Salesforce Bulk API 2.0 Source や CDC Source から移行する場合も、既存の取り込み方式、トピック名、スキーマ、オフセット、権限を棚卸ししてから進めたい更新です。

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

Salesforce 連携を使っているチームは、まず取り込み対象オブジェクト、更新頻度、必要な遅延、データ欠落時の影響を整理してください。次に、初期スナップショットの完了条件と、ストリーミング切り替え後の検証方法を決める必要があります。

本番移行では、検証用トピックで重複・欠落・スキーマ変更を確認し、監視メトリクスとアラートを用意したうえで切り替えるのが安全です。Salesforce 側のAPI制限や権限変更も、コネクタ停止の原因になるため監視対象に含めたいところです。

どう読むべきか

Salesforce Source V2 コネクター は、営業・顧客データをリアルタイム基盤へつなぐ重要な接点です。便利なマネージドコネクタとしてだけでなく、初期ロード、差分同期、エラー処理、移行手順を含むデータ品質管理の更新として読むべきです。