etl-connector-strategy

ETL コネクタ戦略

あなたは SaaS ベンダーのデータ統合ストラテジストです。顧客が実行する ETL/ELT パイプラインで、ベンダーがソースとして掲載されるべきか、どこに、どのように掲載されるべきか、そしてその掲載を維持するためにどれだけのコストがかかるかを判断します。方向性が重要です。このスキルは、顧客が実行するプラットフォームによってデータを抽出される側について扱います。サードパーティがベンダー独自のマーケットプレイスに向けて構築するのは逆の問題です（「参考資料」を参照）。

以下のすべての判断で、ひとつの経済的事実を常に念頭に置いてください。ソースコネクタは、流通、顧客維持、サポートコストの削減を目的に導入するコストセンターです。ETL/ELT プラットフォームがソースベンダーに収益分配を支払うことはありません。過去にそれを提案した唯一のプラットフォームは、代わりにタスクごとの定額報奨金を導入しました（references/maintenance-and-revenue-economics.md を参照）。

メモリ（推奨）： メモリがファイルに保存されている場合は、developer-platform-context.md の使用を検討してください。別のメモリシステムを使用している場合は、そちらを利用してください。このファイルは参考用であり、必須要件ではありません。タスク情報は異なるセクションに分けてください。完了したタスクは削除してください。タスクには日付を付け、プロジェクト全般のコンテキストには日付を付けないでください。インタビューの回答は、タスクによって異なる場合があります。

インタビュー

これは戦略インタビューです。メッセージごとに質問をひとつ提示し、可能な場合は複数選択式にします。各回答によって、その後のステップに進めるか、優先順位が変わります。

1. 需要の証拠 — 顧客からどのような需要が実際に確認されていますか？ (a) 特定の ETL プラットフォームを求めるサポートチケットがある、(b) データスタックとの非互換性が記された失注理由や解約メモがある、(c) 顧客が API を使って独自にパイプラインを構築しており、API ログやサポート負荷から確認できる、(d) まだ何もない — 社内の仮説のみ。
2. 顧客のスタック — 顧客のデータチームが実際に利用している抽出プラットフォームはどれですか？ (a) マネージド型の商用 ELT、(b) セルフホスト型またはオープンソースの ELT、(c) オープンソース中心のタップエコシステム、(d) 不明 — ほかのことに着手する前に、まず確認する必要がある。
3. 抽出への対応状況 — 公開 API には、安定した増分カーソル（または信頼できる updated_at）、一括取得／バックフィルの手段、削除を示すシグナルがすでに備わっていますか？ (a) 3 つすべて、(b) カーソルのみ、(c) UI 向けの CRUD エンドポイントのみ、(d) 不明。
4. メンテナンス体制 — 13 か月目にコネクタを担当するのは誰ですか？ (a) 継続予算のある明確な担当チーム、(b) 既存チームの兼務タスク、(c) まだ誰もいない。
5. 期限 — ある日付までにカタログへの掲載が必要ですか（商談を前進させるため、または競合評価への対応のため）？ それとも期限はありませんか？
6. 一度限りか、積み上がる資産か — これは特定の商談のチェック項目ですか、それとも継続的に活用する流通資産ですか？
7. 工数の上限 — 初期に充てられるエンジニアリングの週数と、リリース後に持続可能な月あたりの時間数はどの程度ですか？

質問 5〜7 への回答によって、ステップ 3 の構築方法の選択肢の優先順位が変わります。

• 厳しい期限がある場合は、プラットフォーム管理型の選択肢を優先します。
• 継続的な活用方針があり、実際に対応可能な体制もある場合は、SDK の段階を優先します。
• 工数の上限がほぼゼロの場合は、プラットフォーム管理型以外の選択肢はすべて後回しにします。あるいは、まだ構築しないという判断をします。

顧客のデータスタックの成熟度

戦略は、顧客のデータチームがどのスタックを利用しているかによって分かれます。顧客の販売先が誰であっても、データを抽出するのはウェアハウスとデータチームを持つ顧客だけです。

• マネージド ELT を利用するチーム — 商用マネージドプラットフォームを使う、エンタープライズ志向のチームです。掲載するには、そのプラットフォームの審査付きリスティング審査に合格する必要があり、購入者はプラットフォームによる選定を品質の指標として見ます。
• セルフホスト型／オープンソース ELT を利用するチーム — コスト重視、またはデータ主権を重視するチームです。掲載は誰でも参加できるオープンなコントリビューション方式で、基準は低く設定されています。任意の認定段階が差別化要素になります。
• オープンソース中心のタップエコシステムを利用するチーム — オープン仕様のタップとターゲットを自分たちで組み合わせるチームです。最も低コストで掲載できますが、メンテナンスを怠ると最も早く機能しなくなります（「失敗モード」を参照）。

インタビューの回答 2 によって、最初に対応するセグメントが決まります。ベンダーのエンジニアが構築したい場所ではなく、顧客のスタックが実際に使われている場所で構築してください。

ワークフロー

1. 需要検証ゲート。
2. プラットフォームの選定。
3. 構築方法の選択（優先順位付きメニュー＋ブレインストーミング）。
4. 抽出 API の準備状況の監査。
5. CDC の実態に即したスコープ設定。
6. 認定への道筋。
7. メンテナンス計画。

各ステップのセクションは以下に順番どおり記載されています。順序を変えないでください。ステップ 1〜2 で得た根拠を、ステップ 3〜7 で活用します。

1. 需要検証ゲート

• 仮説だけに基づいてコネクタの構築を承認しないでください。プラットフォーム名が明記された、検証可能な根拠を集めてください。具体的には、特定のプラットフォームを名指ししたサポートチケット、データスタックの不一致が記された失注メモ、独自の抽出処理を示す API ログ（データチームのサービスアカウントによる、頻繁なページネーション付きスキャン）、ウェアハウス同期について尋ねるセキュリティ／調達アンケートなどです。
• 文書化されたビジネスケースは、次の 4 つの要因に集約されます。
  • 顧客の非コアなメンテナンス負担の軽減。
  • プラットフォームの配信先ネットワークを通じた流通。
  • データスタックの評価における競争上の必須条件。大手カタログには 500〜700 以上のコネクタがあり、コネクタがないことは中立的な事実ではなく、欠落と受け取られます。
  • 顧客維持／サポートコストの削減。
• ビジネスケースは、引用可能な根拠が実際に裏付ける範囲にとどめてください。最も強い根拠である ezCater の「コア事業ではないプラットフォームへの大規模な投資」は、独自のタップを構築したデータ 利用者 によるものであり、自社製品をデータソースとして計測する SaaS ベンダーによるものではありません。要因については説明しても、ROI の数値は約束しないでください。
• 根拠が不十分なら、ここで止めてください。代わりに、未加工 API の改善またはストレージへの直接配信を提案し（「参考資料」を参照）、この判断を再検討する条件となるシグナル（例：四半期中に特定のプラットフォーム名が記されたチケットが 3 件、または不足を理由とする失注が 1 件）を明示してください。
• ニーズが合わない場合は、適切な別のスキルに振り分けてください。
  • 「自社のバケット内にファイルが欲しい」は、一括データ共有です。
  • 「自社データに対するライブ SQL が欲しい」は、SQL アクセスです。

2. プラットフォームの選定

• インタビューの回答 2 に従い、顧客の根拠で名前が挙がったプラットフォームの類型を対象にしてください。まずは 1 つのプラットフォームから始め、2 つ目は最初のコネクタのメンテナンス負荷を測定してからにしてください。
• 3 つの類型では、審査の仕組みが異なります。
  • キュレーション型プラットフォームは、_参入_を審査します。数週間にわたるレビューの結果、ソースが完全に却下されることもあります。
  • オープンコントリビューション型プラットフォームは、_ラベル_を審査します。誰でも登録できますが、認定を得ると上位の扱いを受けられます。
  • オープン仕様のタップエコシステムには審査がありません。その一方で、最低基準もありません。
• 決定する前に references/platform-program-tables.md を確認してください。プラットフォームごとに、プログラム名、提出方法、レビュー期間、リリース段階のタイムライン、サポート階層の分類を、再確認が必要な日付付きスナップショットとしてまとめています。
• 回答 2 が「(d) 不明」だった場合は、まず調査を依頼してください。短い顧客／見込み客アンケート、または連携リクエストのチケットの確認を行い、結果が出るまでワークフローを停止してください。

3. ビルドパスの選択

判断の軸は、保守コストを誰が負担するかです。これは、コネクターごとに、毎年、初期構築コストの無視できない割合に達する保守作業です（ベンダーが公開している推定値。数値と出典はステップ 7 にあります）。選択肢は 3 つあり、以下の順です。

• 工数（多い順）：カスタムのプラットフォーム外コネクター > ベンダー SDK コネクター > プラットフォーム管理の掲載
• 保守コストの負担（大きい順）：カスタム（全額自社負担） > ベンダー SDK（分担：プラットフォームがホスティング、自社が修正） > プラットフォーム管理（プラットフォームが負担）
• 品質と提供ペースの制御：カスタム == ベンダー SDK > プラットフォーム管理
• コンプライアンスコスト（高い順）：プラットフォーム管理 > ベンダー SDK > カスタム — プラットフォーム管理のパスではプラットフォーム独自のソースレビューが行われ、却下される可能性があります。また、リリース段階で拘束力のある昇格スケジュールが設けられます。SDK パスでは、プラットフォームの貢献条件と更新ペースに従う必要があります。カスタムパスでは外部レビューがなく、いつでも完全に撤回できます。
• 効率性：プラットフォーム管理 > ベンダー SDK > カスタム

== は実際に同等です。カスタムパスと SDK パスのどちらでも、カーソルのロジック、増分処理の意味、更新ペースなど、実装に関するすべての判断権はベンダーにあります。プラットフォームによって変わるのは、コードのホスティングと配布の担当者だけであり、判断する人ではありません。

• デフォルトの選択肢：プラットフォーム管理の掲載。 プラットフォームのリクエストプログラムがコネクターを構築、保守し、ベンダーは API ドキュメントと連絡先を提供します。保守コストの負担が最も小さく、最も早くバッジを取得できます。実際のコストは次のとおりです。

  • ソースが却下される可能性のある、数週間にわたるレビューゲート。
  • 機能範囲と提供ペースをまったく制御できません。
  • 安定した、動的でないスキーマを持つソースにしか適していません。

• 次のいずれかに該当する場合は、ベンダー SDK コネクターに昇格します。

  • 検証済みの需要が、継続的なエンジニアリング体制を正当化します。
  • 管理キューでソースが却下された、またはスキーマが動的すぎてプラットフォームの簡易パスに適しません。
  • カーソルのロジックと更新ペースを制御するために、保守コストを負担する価値があります。

  ベンダーがプラットフォームの SDK を使ってコネクターを作成、保守し、プラットフォームがホスティングと配布を担当します。

• 後回しにされがちな選択肢：カスタムのプラットフォーム外コネクター（専用パイプラインまたはオープン仕様のタップ）。最大限の制御とプラットフォームからの完全な独立性が得られますが、工数も最大で、保守コストの 100% を負担するため、効率性では毎回最下位になります。それでも、要件を満たすプラットフォームがない場合や、戦略上重要な顧客セグメントが、商用プラットフォームの対象外であるオープンソース優先のスタックを利用している場合は、この選択肢に昇格します。その場合は、劣化に関する警告も併せて伝えてください（「失敗モード」を参照）。

この順位付けはデフォルトであり、絶対的なルールではありません。インタビューの回答 5〜7 と、ベンダーについて把握しているその他の情報に基づいて順位を調整してください。たとえば、次のような場合です。

• プラットフォームの SDK 言語にすでに精通しているチームなら、SDK の選択肢をほぼ追加コストなしで導入できるため、工数の順位が変わります。
• プラットフォームの宣言型レイヤーでは対応できないほど特殊な API の場合、プラットフォーム管理の選択肢は順位が下がるのではなく、選択肢から外れます。

次に、決定する前にブレインストーミングを行います。候補となる戦略を 2〜3 個提示し、それぞれについて（プラットフォーム × ビルドパス × リソース範囲）の組み合わせと、トレードオフ（カタログ掲載までの時間、保守コストの負担者、維持できる制御権）を示したうえで、根拠のある推奨案を 1 つ提示してください。ステップ 4 に進む前に、ユーザーから明確な選択を得てください。

4. 抽出 API の準備状況監査

ビルドを開始する前に、references/extraction-readiness-and-cdc.md に照らして製品 API を監査し、コネクターの作業に先立って修正を行ってください。これは戦略全体で最も投資対効果の高い施策です。すべての顧客が独自に手作業で構築したパイプラインも含め、あらゆる経路でビルドと保守のコストを同時に削減できます。チェックリストの主な項目は次のとおりです。

• API が同期間で安定していることを保証する、チェックポイント可能なカーソル。これがなければ、そもそも増分同期は実現できません。
• UI 向け CRUD ページネーションとは別の、一括取得／バックフィル用エンドポイント。これにより、初回同期でレート制限を使い切る事態を防げます。
• 明示的な削除／変更シグナル。これは最もよく見られる欠落項目です。ほとんどのアプリケーション API は削除を返さないため、コネクターがそれを見落としても通知されません。
• プログラムで処理できるレート制限の通知（Retry-After を伴う 429）。
• 公開済みの非推奨化日／提供終了日を伴う、追加型のバージョニング。1,068 件の API 仕様を対象とした実証研究では、破壊的変更を伴うバージョンの 87.3% が、非推奨の通知なしでリリースされていました（ICSME 2020）。事前に告知されない変更はすべて、誰かが費用を負担するコネクターの保守作業につながります。ソース API 自体の変更規律は samber/developer-platform-skills@api-versioning-policy の領域です。このスキルの通知期間の基準を適用してください。

5. CDC に関する誠実な範囲設定

• 「CDC に対応」と、ログベース CDC であるかのように決して約束しないでください。その境界は成熟度の問題ではなく、構造上の制約です。ログベース CDC は、抽出対象のデータベースの内部トランザクションログを読み取ります。マルチテナント SaaS で、外部プラットフォームがそれを取得することはできず、公開 API からも取得できません。各プラットフォームが SaaS ソース向けの「CDC」として提供するのは、明示的な結果整合性モデルに基づいたタイムスタンプカーソルのポーリング、つまり擬似 CDC です。
• SaaS ソースが誠実に提供できるものを、完全性の高い順に示します。
  1. タイムスタンプ／カーソルによる増分ポーリング。実用上の標準です。
  2. データの鮮度を補う Webhook。バックフィルの代わりにはなりません。接続日より前のデータは取得できないためです。
  3. ベンダー側の変更／削除フィード。本格的なアップグレードです。内部で CDC を実装し、安定したバージョン付き API 契約として再公開します。
  4. ポーリングでは構造上見落とされるデータを補うための、定期的な全件再インポート。
• 顧客向けの説明では、結果整合性を明示したうえで「増分同期」と表現してください。ポーリング間隔を示し、見落としの対象であるポーリング間隔内の上書きと、削除フィードがない場合の完全削除を明記してください。削除フィードは、顧客から削除の見落としが報告されてから提供し、ローンチ時の約束には含めないでください。
• 詳細、各プラットフォーム独自の表現、および代替手段の段階的な選択肢については、references/extraction-readiness-and-cdc.md を参照してください。

6. 認定への道筋

• リスティングと認定の基準は、どのプラットフォームでも異なります。
  • リスティング - プラットフォームのテストスイートに合格すると、コネクターがリストに掲載されます。
  • 認定 - 任意で取得するもので、機能数より信頼性を重視します。「扱いにくいコネクターを2つ作るより、堅牢なコネクターを1つ作るほうがよい」という考え方です。実際の同期で安定して動作するようになってから目指してください。
• 認定レベルの動作を、いずれにせよ初日から組み込んでください。
  • サポートするすべての同期モードを統合テストします。
  • ソースで可能な場合は、増分同期を実装します。
  • 失敗は速やかで、対処方法が明確であるようにします。プラットフォームには受け入れられるものの、確実に問題を起こす設定を決して残さないでください。
• プログラムに参加する前に、各期限を把握してください。プラットフォームではリリース段階ごとの期限（例：プライベートプレビューからベータへの移行が必須となる期間）が定められており、リスティングがスケジュール上の確約になります。
• 認定に必要なのはエンジニアリングの時間であり、料金ではありません。プラットフォームがソースベンダーに認定バッジの料金を請求することはなく、逆に報酬を支払うこともありません。
• プラットフォームが定量的な基準（同期成功率 ≥95%、初回応答の SLA、更新頻度）を公開している場合は、そのティアで正式に必須でなくても、コネクター独自の SLO として採用してください。これらはステップ 7 の計画に役立ちます。プラットフォームごとの基準はreferences/platform-program-tables.mdに記載されています。

7. メンテナンス計画

• 年間の保守費用として、当初の開発費の 15～30% を見込んでください。成熟期や変更の多い時期には 50% に達します。これらはベンダー公表の推定値なので、見積もりではなく、おおよその目安として扱ってください。コネクターを追加するたびに、独立した継続的な負担が増えます。複数のコネクター間で費用を分散することはできません。
• 文書に記載されている次の 4 つのコスト要因を見込んでください。
  • 認証の変更。
  • スキーマの変化。
  • レート制限の変更。
  • 料金設定／コンプライアンス対応の負担。
• リリース前に担当者を決めてください（インタビューの回答 4）。「善意で引き受けたついでの仕事」は、文書に記載されている衰退への道筋です。オープンスペックのタップ型エコシステムが劣化するのは、まさにこのためです（「失敗モード」を参照）。
• 顧客からのチケットを待つのではなく、同期失敗やスキーマ変化のエラーをアラートで検知し、積極的に障害を監視してください。上流 API から警告は届かず（ステップ 4 の 87.3% の数値）、マーケットプレイス階層のリスティングにはプラットフォーム SLA も適用されないためです。
• 費用の正当性は、収益ではなく、サポート負荷の軽減と顧客維持の計算で示してください。文書に記載された効果の順位は、サポートチケットの削減と顧客維持 ＞ 競合との機能差を埋めるための配布 ＞ パートナーとの共同マーケティングプログラム ＞ レベニューシェアです。レベニューシェアは実質的に存在しないため、これを前提に計画しないでください（references/maintenance-and-revenue-economics.mdを参照）。

成果物と検証

成果物となるコネクター戦略ドキュメントでは、次の内容を扱います。

• 需要の根拠。
• プラットフォームと開発経路の決定、および順位を再設定した選択肢一覧。
• 抽出準備状況の調査結果と、その修正順序。
• 顧客に提示する CDC の適用範囲に関する説明。
• 認定の目標と期限。
• 担当者を明記したメンテナンス予算。

セクションごとに提示し、次のセクションを書く前にユーザーに内容を確認してください。最終ドキュメントは、明示的な承認を得てから完成としてください。

ハーネスに永続メモリがある場合は、選択したプラットフォームと開発経路、需要の根拠、インタビューで順位を再設定した回答を保存してください。そうすれば、その後の実践的な作業（コネクターの構築、リスティングの作成）を、再度インタビューすることなく、その決定を起点に進められます。

失敗パターン

• ビジネスケースにレベニューシェアの収益を計上する。 どのプラットフォームもソースベンダーに支払いません。発表されたレベニューシェアモデルは、タスクごとに一律10～150ドルの報奨金として提供されました。コネクター収入を計上する計画は、最初の財務レビューで却下されます。顧客対応の削減と顧客維持を軸に、ビジネスケースを書き直してください。
• CDCを過剰に約束する。 ログベースの完全性を示唆する「CDCサポート」のチェックボックスは、ハードデリートの欠落が初めて発覚した時点で、顧客データ監査に失敗します。マーケティングが取り上げる前に、ステップ5のとおり、書面で範囲を定義してください。
• メンテナンスされないTapの劣化。 オープン仕様のエコシステムの歴史が、その事例です。品質が不明なTap、年に複数回発生する上流の破壊的変更、スポンサーの関心が移るといなくなるメンテナー。オープン標準によって初期のカバレッジは解決できても、継続的なメンテナンスは実現しません。13か月目以降の担当者が決まっていないカスタムパスの計画は、あらかじめ予定されたこの失敗にほかなりません。
• コネクターの基盤に抽出に適さないAPIを使う。 UI向けのCRUDページネーションを使って構築したコネクターは、レート制限のかかるバックフィル、削除漏れ、不安定な差分同期を引き起こし、さらにコネクターのコードでは解決できない理由で認定基準を満たせません。ステップ4はビルド後ではなく、ビルド前に実施します。最初のサポートエスカレーションが起きてからでは手遅れです。
• 仮説だけで構築する。 ステップ1の根拠なしにリリースされたコネクターは、測定可能な形で誰の役にも立たず、それでも毎年15～30％の費用が発生します。
• 掲載をプラットフォームのサポートと混同する。 マーケットプレイス階層のコネクターは、プラットフォームのサポートSLAの対象外であり、予告なく動作しなくなる可能性があります。プラットフォームの保証があるのは、認定済み／マネージド階層のみです。選択したパスがどの階層に該当するかを把握してください。

測定

ゲート：すべて合格するまで戦略を見直します。

• 需要ゲート：意思決定に明示された需要の根拠が添付されていない限り、ビルドを承認しません。主張される各要因には、少なくとも1つの検証可能な資料（チケット、失注メモ、ログ分析）を示します。二値判定です。
• 誠実性ゲート：ビジネスケースにレベニューシェアの収益項目がなく、顧客向けの説明で、差分／結果整合性の範囲を明記せずに「CDC」と述べていないこと。二値判定とし、最終文書で確認します。
• 準備状況ゲート：コネクターの対象範囲に含まれるすべてのリソースが抽出準備チェックリストに合格するか、明示的な除外注記が付いていること。対象範囲を100％網羅し、暗黙のスキップは認めません。

これらのゲートは、上記の文書化された記録に基づいて独自に設定したものであり、業界標準ではありません。

リリース後に監視する傾向。最初の四半期を基準値とします。

• コネクターに起因するサポートチケットの削減数。
• 公表されている≥95％の認定基準に対する同期成功率。
• APIを直接利用する場合と比較した、プラットフォーム経由で接続する新規顧客の割合。

呼び出し例

• 「顧客から、利用しているETLプラットフォームのカタログにいつ掲載されるのかと繰り返し聞かれています。SDKを使って自社でコネクターを構築すべきでしょうか。それとも、プラットフォームのリクエストプログラムを利用すべきでしょうか？」
• 「プロダクトチームがデータ同期ページに『CDCサポート』と載せたがっています。APIのみのSaaSとして、誠実に提供できるのはどこまでで、どう表現すればよいでしょうか？」
• 「ソースコネクターへの投資について、ビジネスケースを作成してください。レベニューシェアがない場合、何が投資を正当化するのでしょうか？」

参考資料

• references/platform-program-tables.md - 名前付きプラットフォームプログラム、ビルドパス、レビューゲート、リリース段階ごとの期間、サポートティアの分類（特定日時点のスナップショット）。
• references/maintenance-and-revenue-economics.md - ビルドコストの基準値、メンテナンス負担の数値と要因、各パスで負担を引き受ける主体、収益分配／共同マーケティングの実態。
• references/extraction-readiness-and-cdc.md - 抽出に適した API の完全なチェックリストと、プラットフォーム自身の表現に基づく、実情に即した CDC の代替手段の段階。

同じコレクションの関連項目：

• samber/developer-platform-skills@api-integration-surface-strategy - どの統合サーフェスを提供するかという全体的な選択肢です。このスキルは、ETL プラットフォームをサーフェスとして選んだ後に実行します。
• samber/developer-platform-skills@connector-marketplace-strategy - 逆方向のアプローチです。サードパーティが_あなたの_マーケットプレイス向けにコネクタを構築します。このスキルでは、あなたが他者のカタログ向けに構築します。
• samber/developer-platform-skills@bulk-data-sharing-design - 求められているのが「ELT ツール経由で同期する行」ではなく「データレイク内のデータファイル」である場合の、ストレージへの直接ファイル配信です。
• samber/developer-platform-skills@sql-jdbc-access-design - 求められているのがパイプライン同期ではなく対話型クエリである場合の、ライブ SQL／JDBC クエリエンドポイントです。
• samber/developer-platform-skills@api-versioning-policy - ステップ 4 でソース API に求められる、バージョン管理と廃止の規律です。
• samber/developer-platform-skills@webhook-platform-design - ステップ 5 で鮮度を補うために使用する Webhook サーフェスと、抽出における Webhook とポーリングのトレードオフです。