bulk-data-sharing-design

一括データ共有の設計

あなたはデータプラットフォームのプロダクトデザイナーです。SaaS プロダクトが、顧客自身のデータを一括で提供する方法を設計してください。オブジェクトストレージ上のファイル、ネイティブなデータウェアハウスまたはレイクの共有、あるいはストリームとして提供し、顧客のデータチームが自社の他の業務データと結合できるようにします。自社 API 用のスクレイパーを構築させる必要はありません。

参考となる事例は、Stripe が Data Pipeline をリリースする前の状況です。ウェアハウスで Stripe のデータを利用したい顧客は、独自の API パイプラインを構築するか（Stripe の独自試算では、数か月の作業と数十万ドルが必要）、網羅性が不十分なサードパーティ製 ETL 同期サービスを購入する必要がありました。ベンダーが運用する一括データ提供は第 3 の選択肢です。設計上、完全な網羅性を確保でき、調査したすべてのベンダーがプレミアム機能として提供しています。

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

確認事項

設計を始める前に、以下を質問してください。回答によって後続の手順が変わります。質問はまとめて行ってください。これは戦略インタビューではなく、実務的な設計タスクです。

1. 顧客のデータウェアハウス環境：対象アカウントのうち、共有可能なウェアハウスまたはレイクハウス（Snowflake、Databricks、BigQuery）をすでに運用している割合はどのくらいですか。また、特定のプラットフォームが主流ですか？（ステップ 1 の方式を決めます）
2. どのデータを、どの程度の量と変動性で扱いますか？追記専用のイベントですか、それとも更新や削除が発生する可変レコードですか？（更新頻度と削除の扱いを決めます）
3. 実際に購入を検討している顧客が求める鮮度はどの程度ですか？1 日前のデータで十分ですか。それとも数時間前、あるいは数分前のデータが必要ですか？意欲的に聞こえる回答ではなく、実際に何と言っていましたか？
4. 適用されるコンプライアンス要件と地域：EU の個人データは対象に含まれますか？データのローカライゼーションが義務付けられている国（例：中国の PIPL、ロシア、インド）に顧客はいますか？
5. 料金設定の方針：エンタープライズプラン限定、利用量に応じた有料オプション、または既存の有料プランに同梱のどれですか？「無料機能」とする予定なら、今のうちに明確にしてください。「失敗モード」を参照してください。
6. 受け取り側のクラウド：AWS／GCP／Azure のいずれか 1 つですか、それとも複数ですか？（認証情報と暗号化の対応付けに関わります）
7. 提供開始までの上限：最初のエクスポートをいつまでに実現する必要がありますか？今回限りの大口顧客との契約成立が目的ですか、それとも継続的に拡大するプラットフォーム機能ですか？データエンジニアリングにどれだけの工数を割けますか？（以下の両方の選択肢の優先順位が変わります。厳しい期限がある場合は工数の少ない段階を優先し、継続的な拡大が目標ならテーブル形式と CDC への投資を優先します）

ハーネスに永続メモリがある場合は、設計で確定した事項を保存してください。そうすることで、後の実行（新しいデータセット、更新頻度の引き上げ、データ保管場所のレビュー）では、設計を最初から導き直さずに済みます。保存する内容：

• 選択した方式
• パーティション分割とファイルサイズの契約
• 更新頻度の段階と、その引き上げ条件
• 認証情報のモデル
• コスト負担の分担
• データ保管場所に関する方針

データスタックの成熟度

設計は、顧客のデータスタックの成熟度によって分かれます。

• ウェアハウス内で利用する顧客 - Snowflake、Databricks、BigQuery をすでに利用しています。ネイティブ共有なら、コピーもデータ転送料も不要で、ロード時のスキーマドリフトもありません。生ファイルを渡すと、本来不要だった取り込み処理を顧客に再構築させることになります。
• バケットのみ利用する顧客 - 共有可能なウェアハウスはなく、オブジェクトストレージ上で Spark、Athena、DuckDB、または ML パイプラインを実行しています。利用できる形式は、バケット内のパーティション分割された Parquet のみです。

実際の顧客構成に合わせて設計してください。先進的な顧客だけに合わせてはいけません。Stripe は両方の方式を並行して提供しています。前者にはウェアハウス共有、後者には S3／GCS／Azure Blob への生の Parquet を提供し、どちらか一方に絞っていません。

ワークフロー

1. 方式を選びます。ファイルドロップ、ネイティブ共有、または両方です。
2. ファイルレイアウトとパーティショニングの仕様を定めます。
3. 配信頻度と鮮度に関する方針を決めます。
4. セキュリティと認証情報のモデルを設計します。
5. エグレス、ストレージ、コンピューティングのコストを割り当てます。
6. スキーマ進化の仕様を作成します。
7. コンプライアンスとデータの保存場所を決定します。
8. 段階的なロールアウトを実施します。

各ステップのセクションは、以下にこの順番で記載します。

1. 方式を選ぶ

本番環境で採用されているアーキテクチャの方式は2つあり、ほかに例外的な方式が1つあります。

• 労力：ストリーミングプッシュ > Parquet のファイルドロップ > ネイティブなウェアハウス／レイク共有

• 価値：ネイティブ共有 > ファイルドロップ > ストリーミングプッシュ（ウェアハウス内のデータを利用するコンシューマーの場合。コンシューマーがバケットのみを利用する場合は、ファイルドロップ > ネイティブ共有に逆転します）

• 効率性：ネイティブ共有 > ファイルドロップ > ストリーミングプッシュ

• デフォルトの選択肢：ネイティブなウェアハウス／レイク共有 - Snowflake Secure Data Sharing、Databricks Delta Sharing、BigQuery のリンク済みデータセットです。ターゲットアカウントの相当数が1つのウェアハウスプラットフォームに集中している場合（1つのプラットフォームにおよそ30～40％以上。このしきい値は独自に設定するもので、ベンダーが公表した数値ではありません）に選びます。データをコピーしないため、エグレス料金もストレージの重複も発生せず、ロードジョブによるスキーマのずれも生じません。これは、Stripe、HubSpot、Salesforce がウェアハウス内にデータを持つ顧客向けに選んだ方式です。上記の労力の順序は、データがすでに共有対応のウェアハウスまたはレイクハウスに存在することを前提としています。そうでなければ、データをそこに移すことが実質的なコストとなり、労力の順序は逆転します。

• 汎用的な代替案：オブジェクトストレージへの Parquet ファイルドロップ - バケットに Hive パーティション形式の Parquet ファイルを置く方法で、あらゆる利用側エンジンが読み取れる形式です。ウェアハウスの利用先が集中していない場合のデフォルトであり、利用先が集中している場合でも第2の提供方式として用意します。共有では対応できない ML のバックフィルや未加工ファイルのユースケースにも対応できるためです。

• 降格ではなく削除：質問1でウェアハウス内にデータを持つアカウントが1つも見つからなかった場合のネイティブ共有。 共有には、受信側に共有対応の利用先が必要です。それがない場合、これは単に遅い選択肢ではなく、到達できない選択肢です。最下位に残しておくと、「Snowflake 共有も追加しよう」という案がロードマップのレビューのたびにスコープに再登場するため、候補から外します。再び候補に加える条件：ターゲットアカウントが、共有可能な1つのプラットフォームに集中すること。

• 優先度の低い選択肢：リアルタイムのストリーミングプッシュ - 鮮度は最高ですが、労力も最大で、効率性の比較では常に最下位です。エクスポートするデータが真にイベント形式であり、コンシューマーが1分未満の配信を求め、耐久性に関するトレードオフを受け入れる場合に限って候補に加えます。実例は Braze Currents ただ1つで、Parquet ではなく Avro を使っています。Braze Currents はイベントを再生できないことを明記しています。つまり、コンシューマー側のエンドポイントがダウンしていた場合、プロバイダーからは何も復旧できません。

この順位付けはデフォルトであり、絶対的なルールではありません。質問1への回答や、ユーザーについて把握しているほかの情報に照らして順位を付け直してください。データがすでに Databricks にあるプロバイダーなら、Delta Sharing はほぼ追加コストなしで実現できます。ウェアハウスを持たない ML チームが顧客層の大半を占めるなら、重要な選択肢はファイルドロップだけです。ストリーミングを前提とするコンシューマーが利用するイベント分析製品なら、優先度の低い選択肢が適した唯一の状況です。

Delta Sharing が事前署名付き URL をどのように提供することで、共有サーバーがバイト列をプロキシする必要をなくすのか、また、テナントごとにコピーを作成せずに、テナントでパーティション分割した1つのテーブルをすべての受信者の共有にどのように利用するのかといったプロトコルレベルの詳細は、references/vendor-case-studies.md に記載されています。

2. ファイルレイアウトとパーティショニングの契約を定める

ファイルへの出力方式では、レイアウトが契約です。明文化し、エクスポートジョブの偶発的な出力を顧客が依存するものにしないでください。

• パーティションキーは、内部スキーマの構成ではなく、利用者がフィルタリングに使う項目に基づいて選びます。イベントデータなら日付にテナントのスコープを加えます。Hive 形式のパス（year=2026/month=08/day=30/）を使い、カーディナリティの低いキーは2～3階層までに制限します。ユーザー ID のようなカーディナリティの高いキーではパーティションを作成しないでください。
• 契約でファイルと行グループの目標サイズ（ファイルはおよそ256～512 MB）を明記し、コンパクションを実行します。小さなファイルが大量にできる問題は理論上の話ではなく、実際に測定されています（AWS のベンチマークでは、コンパクションによりクエリ時間が40秒から10秒未満に短縮されました）。
• CSV/JSON より Parquet を標準とします。AWS 自身の数値によると、Parquet はテキストよりアンロードが最大2倍速く、サイズは最大6分の1です。
• 利用者がファイルからスキーマを推測する状態にせず、カタログ（Glue、Iceberg REST、Hive Metastore）にスキーマを登録します。
• アトミックな複数ファイルのコミット、タイムトラベル、またはインプレースのスキーマ進化がエクスポートで必要になった場合にのみ、パーティション分割した生の Parquet からテーブル形式（Iceberg、Delta、Hudi）に移行します。それまでは移行しません。こうした保証が必要ない場合、生の Parquet のほうが運用コストを抑えられます。

具体的な数値、コンパクションの実行条件、形式ごとのトレードオフについては、references/file-layout-and-access-control.mdを参照してください。

3. 配信頻度と鮮度の方針を定める

頻度の段階を上がるほど構築の複雑さは単調に増加し、大規模運用時のコストは低下します。

• 構築の労力：streaming push > log-based CDC > micro-batch incremental > scheduled full-dump

• 大規模運用時のコスト：scheduled full-dump > micro-batch incremental > log-based CDC

• 鮮度：streaming push > log-based CDC > micro-batch incremental > scheduled full-dump

• 効率：scheduled full-dump > micro-batch incremental > log-based CDC > streaming push

• 標準の段階：スケジュールされた全件ダンプです。 冪等な上書きができ、削除の追跡は不要で、最も運用が簡単です。具体的な頻度の参考例は、Stripe の3時間ごとの全件ロードです。その代償として、変更がわずかでも、各サイクルでデータセット全体を再転送します。

• 全件ダンプの帯域幅やコンピューティングの費用が CDC の構築コストを上回る場合、または顧客が求める鮮度をダンプ間隔では実現できない場合は、上位の段階へ移行します。 CDC を採用すると、主キーによるアップサートの重複排除、明示的な削除トゥームストーン、定期的な全件スキャンによる照合ジョブが設計上必要になります。削除の見落としは CDC でよく知られた落とし穴です。変更イベントが一度も発行されない削除は、下流から見えないためです。

• ストリーミングプッシュは、ステップ1で述べた再生不能とのトレードオフを伴う最上位の段階です。

この順序もあくまで標準です。チームがすでに持っている経験に照らして順位を見直してください。ログベース CDC（Debezium とスナップショットからログへの引き継ぎ）を運用したことのある社内チームがいれば、想定よりはるかに低いコストで CDC の段階を導入できるため、コスト曲線上の想定より早い段階で採用できます。

導入段階とは別に、次の3つのうちどれに該当するかを明示した、鮮度の方針を公開します。

1. 固定頻度 - Stripe：無条件で3時間ごとに全件ロードします。
2. ベストエフォートの目標 - Amplitude：「1時間あたり500万イベントのエクスポートを目指す」と明記しており、共有負荷の状況によって変動します。
3. 契約上の SLA - Fivetran：稼働率99.9％を保証し、未達時にはペナルティが適用されます。

「ベストエフォートで毎時」と「SLA 99.9％」は料金ページ上では似て見えますが、サポートへのエスカレーションや法的な影響はまったく異なります、どの方針を採るかを明記しないサービスは、顧客にはベストエフォートの約束をしたと思わせる一方、自らは何も約束していないという立場を取ることになります。

4. セキュリティと認証情報のモデルを設計する

• バイト列を自社サーバー経由で転送してはいけません。本番環境のあらゆる共有方式（Delta Sharing、Snowflake、BigQuery）では、有効期間の短い署名付き URL またはスコープを限定した一時認証情報を発行するため、受信者はオブジェクトストレージから直接読み取れます。自社サービスは認可と URL 署名を担い、スループットはストレージ層に応じてスケールします。
• 受信者ごとに認証情報を発行し、共有キーや静的キーは決して使わないでください。AWS では外部 ID を指定したアカウント間ロール、Azure では SAS トークンを使い、受信者ごとに KMS グラントを 1 つずつ作成します。こうすれば、1 社のアクセスを取り消しても、ほかの顧客には影響しません。
• テナント数の増加に応じて段階を上げる形で、成熟度の段階に沿って受信者を分離します。テナントごとの専用バケット > プレフィックス分離を用いた共有バケット > 受信者ごとのアクセスポイント > ブローカーが発行する短期認証情報。
• 顧客が管理できるキー（CMEK/SSE-KMS）で暗号化します。キーのローテーション時に過去のデータを再暗号化する必要がないようにしてください。異なる信頼レベルの受信者が 1 つのバケットを利用する場合は、ファイル単位の暗号化がより細かな選択肢です。
• アクセスレビューの周期は認証情報の TTL に合わせてください。適用を担うのは有効期限であり、リクエストごとの ACL チェックではありません。

クラウドごとの仕組み、AWS の分離段階、トークンのライフサイクルの詳細は、references/file-layout-and-access-control.md に記載されています。

5. エグレス、ストレージ、コンピューティングのコストを割り当てる

コストは 3 つの層に分かれます。ローンチ前に、誰がどの費用を負担するかを文書で明確にします。

1. インフラコストの割り当ては方式によって決まります。
   • ファイルドロップ：すべて顧客が負担します。顧客自身のバケットと、再処理用のコンピューティングが対象です。Segment のモデルでは、顧客が AWS を直接所有して料金を支払い、Segment が顧客自身のアカウント内で実行する変換クラスターも含まれます。
   • ウェアハウス共有：データをコピーしないため、ストレージの重複分は誰も負担せず、コンシューマーが負担するのはクエリのコンピューティングコストのみです。これは Snowflake のモデルです。HubSpot は、共有データの読み取りで発生する Snowflake の費用をすべて顧客が負担することを明示しています。
2. エグレスが決定的な費目となります。 リージョン間およびクラウド間の転送は、データ転送コスト全体の最大 70％を占める場合があります（Snowflake が公開した数値です。ベンダーによる数値であり、自社が販売するオプティマイザーに都合のよい内容です）。同一リージョン内の転送は通常無料です。
   • 共有のどちら側が負担するのかを把握してください。リージョン間のネイティブ共有では、コンシューマーのクエリ量に応じてエグレス料金が増加し、プロバイダーが負担することがあります（競合他社の情報源が指摘する注意点です。その重みは考慮しつつも、コスト上の実態は存在します）。
   • Snowflake が Egress Cost Optimizer（GA 2025-04-15）をリリースしたのは、まさにこの問題に対処するためです。一度レプリケートすれば、その後は追加分のエグレス料金だけを支払います。最大 96％の節約という数値はベンダーの主張ですが、顧客の 1 社である RavenPack はコストが 14 分の 1 に減少したと報告しています。
3. 課金額は、インフラ費用の負担者とは別に決めます。 調査対象のすべてのベンダーが、一括エクスポートをエンタープライズプランの機能または従量課金のアドオンとして価格設定しています。この機能クラスで無料プランを提供した前例は確認されていません。
   • Stripe は、トランザクション数に基づくサブスクリプション料金を請求します。
   • Braze は、エンタープライズ契約の対象としています。
   • HubSpot は、最上位プランの機能としています。

6. スキーマ進化の契約を定める

エクスポートのスキーマは API 契約です。破壊的変更が事前の通知なくリリースされると、ソースシステムでの名称変更が非推奨を示すヘッダーもなく顧客のダッシュボードに反映されてしまいます。API のバージョニングと同じ規律で扱ってください。

• 追加のみを原則とします。新しい nullable 列は末尾に追加し、既存の列の名前変更、削除、型変更は行いません。Parquet の利用側では列名が識別子であるため、名前を変更すると完全に互換性が失われます。正しい方法は、新しい列を追加し、古い列を非推奨にすることです。
• すべてのバッチで列の順序と型を一貫させます。エンジンの述語プッシュダウンと列名による照合は、どちらもこれに依存しています。
• スキーマの各バージョンをカタログに登録し、配信を成功とみなす前に、書き込まれたスキーマが文書化された契約に適合することを検証します。これにより、スキーマのドリフトを顧客からの問い合わせではなくアラートで検知できます。
• BI ダッシュボード、ML パイプライン、dbt ジョブはそれぞれ異なる部分に依存するため、完全なコミットメントを 4 部構成のデータ契約として定義します。
  • スキーマ：列、型、NULL 許容性。
  • 品質：完全性のしきい値。
  • 最新性：ステップ 3 の方針。
  • 可用性。
• 破壊的変更がどうしても避けられない場合は、API の非推奨化と同様に進めます。事前告知期間を設け、旧列または旧パスと新列または新パスを並行して提供し、削除日を定めます。通知期間の仕組みは、同系列の samber/developer-platform-skills@api-versioning-policy が担当します。この契約では、ファイルやテーブルにおいて何が破壊的変更にあたるかを定義します。

7. コンプライアンスとデータ所在地を確定する

個人データの越境移転には重大な影響があります。Schrems II により、標準契約条項に加えて移転影響評価が必須となりました。また、Meta に対する 12 億ユーロの罰金（2023 年）は、越境移転の不備が理由でした。リモートアクセスも移転に該当します。EEA 域外のオフィスにいるサポートエンジニアが EEA の顧客のエクスポートをクエリすることは、ファイルをコピーすることと同じ規制対象の事象です。

書類上の対応よりもアーキテクチャによる解決を優先し、次の順に検討してください。

1. 初日からリージョンを固定する - EU のデータを EU のバケットや共有領域に置けば、移転の問題を発生源で解消できます。Segment は米国リージョン設計に後からコンプライアンスを追加するのではなく、EU Data Lakes 製品を終了しました。この理由から、主要なプラットフォームではどれもリージョンの選択を初日の設定としています。後から対応することについて、Segment の事例が示しているとおり、製品を終了するほうが安く済む場合もあります。
2. リージョンごとの CMEK - リージョン外に出ないキーを使うことで、「暗号文は移動したが、読み取れない」という、規制当局が認めない抜け穴を塞げます。
3. 仮名化したレプリカ - ホームリージョン外にコピーする前に、識別情報を含むフィールドを削除するかトークン化します。
4. データローカライゼーションの義務は書類上の手続きではなく、絶対的な障壁です - 中国の PIPL などの法律は移転を全面的に禁じることがあります。Stripe はデータローカライゼーションを理由に、インドでは Data Pipeline を提供していません。「リージョン X では提供しない」という判断は、正当で前例のある設計上の結論です。

法的な仕組みの優先順位（十分性認定 → SCC／BCR ＋ TIA → 例外）とパターンの詳細については、references/compliance-and-residency.md を参照してください。

8. 段階的にロールアウトする

一度にローンチするのではなく、段階的な計画として設計を提示します（ここでのしきい値は独自に設定したもので、ベンダーが公表した数値ではありません）。

1. 質問1で集中が確認された場合は、主要なデータウェアハウスプラットフォームのネイティブ共有を採用します。
2. 万能なフォールバックとして、オブジェクトストレージ上の Parquet ファイルドロップを用意します。パーティション分割、カタログ化、受信者ごとの認証情報を備えます。
3. 増分／CDC への更新は、フルダンプのコストが問題になる場合、または顧客の鮮度要件によって必要になる場合に限ります。
4. プレミアム利用の条件と、公表する鮮度方針を定めます。初日からエンタープライズティアまたはアドオンとして価格設定します。
5. 自社開発かパートナー利用かを判断します。標準的な配信経路（データウェアハウス独自の共有プリミティブ、実績のあるデータ移動ベンダー）は購入またはパートナー利用とし、どのベンダーも対応していない部分に限って社内で開発します。Fivetran は、動作するプロトタイプを手元に持ちながら、リバース ETL を社内で開発するのではなく Census を買収しました（2025年5月）。読み取りパスと書き込みパスのデータ移動は、異なるエンジニアリング上の課題であるためです。ベンダーの従量課金が、データエンジニア1〜2人の総人件費を超えたら、この選択を見直します。

リージョンの固定（ステップ7）は横断的な要件です。ステップ1〜2に組み込み、ステップ4で後付けしてはいけません。

失敗モード

アンチパターンのチェックリストです。それぞれ、実際にレビューで指摘された問題です。

• 通知されないスキーマの変更：文書化されたデータ契約に照らしてバッチを検証する仕組みがないため、列名の変更や型の変更がエクスポートに反映されます。この領域で最もコストのかかる失敗です。問題が発生するのは自社のログではなく、顧客のダッシュボードです。
• 想定外のエグレス料金：クロスリージョン共有で、1バイトあたりのエグレス料金をどちらが負担するか把握しないままローンチし、転送コストの70％に相当する初回請求で初めて発覚します。
• 国境を越えたデータ移転の違反：エンジニアリングを簡素化するためにグローバルバケットを1つ使い、すべての EU 顧客について SCC/TIA の書類作成が必要になること、あるいは Meta 規模の認定を受けることを、知らないうちに自ら招きます。
• 無料ティアでの無償提供：あらゆるベンダーがプレミアムティア限定としている機能クラスであるにもかかわらず、一括エクスポートを無料でバンドルします。失った利益率は、ティアの価格を改定しても簡単には取り戻せません。
• プロキシ経由のデータ転送：エクスポートのダウンロードを自社の API サーバー経由にすることで、自社のサーバー群がスループットの上限とエグレス料金の負担者を同時に引き受けます。
• 小さなファイルの増加による性能劣化：コンパクションを行わず、何千もの小さなファイルが生まれ、コンシューマーのクエリが極端に遅くなります。実測では4倍の性能低下が確認されています。
• 削除の整合処理を伴わない CDC：イベントを出さない削除が、すべての顧客のコピーにファントム行として蓄積します。
• 静的な共有認証情報：すべての受信者に同じキーを使うため、1件の漏えいや利用停止のたびに全員のキーをローテーションすることになります。
• リプレイに関する警告のないストリーミング：障害後の復旧時に初めて、イベントを見逃すと失われることをコンシューマーが知ります。リプレイできないストリームを提供するなら、その旨を Braze と同じくらい明確に契約に記載する必要があります。

測定

4つの二値ゲートを設け、すべて通過するまで設計を反復します。

1. 契約の完全性：すべてのエクスポート面に、スキーマ（列、型、NULL 許容性）と明示的な鮮度方針（固定頻度、ベストエフォート、または SLA と明記）を含む、文書化されたデータ契約が存在すること。スキーマが暗黙的、または鮮度方針が明記されていないエクスポート面は不合格です。
2. コスト負担者の明記：提供する配信モデルごとに、ストレージ、コンピューティング、エグレスの費用を誰が負担するかを、クロスリージョンの場合も含めて文書化していること。負担者が明記されていないエグレス経路があれば不合格です。
3. データレジデンシーの対応範囲：顧客基盤に含まれるすべての規制対象リージョンについて、リージョン固定、法的メカニズムの文書化、または明示的な提供対象外のいずれかの方針が文書化されていること。リージョン固定も SCC/TIA の文書化もないグローバルバケットを EU の顧客に使う場合は不合格です。
4. プレミアム利用の条件：一括エクスポートを有料ティアまたはアドオンの対象とするか、業界全体の慣例を破るという明示的かつ根拠のある決定を設計に記録していること。

ローンチ後に監視する傾向であり、合否のしきい値ではありません。

• 明示された鮮度方針を満たした配信の割合。
• コンシューマーから報告されたスキーマ変更による障害の件数（目標：ゼロ）。
• 受信者1件あたりの月間エグレスコスト。

呼び出し例

• 「法人顧客から、データをSnowflakeに取り込みたいという要望が相次いでいます。一括エクスポートの提供方法を設計し、ファイルの配信とネイティブ共有のどちらを構築すべきか教えてください。」
• 「S3データエクスポートのParquetレイアウトとスキーマ進化のルールを設計してください。列を変更しても顧客のダッシュボードが壊れないようにしたいです。」
• 「データエクスポートのアドオンを販売したいと考えています。どの頻度を約束できるか、データ転送料は誰が負担するか、EUの顧客にはどう対応すべきか教えてください。」

参考資料

• references/vendor-case-studies.md - ベンダー比較表（Stripe、Segment、Amplitude、Braze、HubSpot、Fivetran）と共有プラットフォームの全体像（Snowflake、Delta Sharing、BigQuery、Iceberg REST Catalog、Salesforce Zero Copy、AWS Data Exchange）。Delta Sharingプロトコルの仕組みと、自社構築かパートナー利用かを判断するための根拠も記載されています。
• references/file-layout-and-access-control.md - パーティショニングとコンパクションの数値、テーブル形式への移行条件、マルチテナントの分離レベル、各クラウドの認証情報および暗号化の仕組みが記載されています。
• references/compliance-and-residency.md - GDPRのデータ移転の仕組み、Schrems II/TIA、アーキテクチャパターンの優先順位、データローカライゼーション義務の事例が記載されています。

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

• samber/developer-platform-skills@api-integration-surface-strategy - 一括ファイル配信や共有を提供方法として採用するかを決定する上位の判断を扱います。このスキルでは、選択した提供方法の設計を行います。
• samber/developer-platform-skills@etl-connector-strategy - 他社のETLプラットフォーム（Fivetran、Airbyte）でソースコネクタになる方法を扱います。このスキルでは、データを自社から直接提供します。
• samber/developer-platform-skills@api-auth-key-management - API認証情報の発行とローテーションを扱います。ここでの受信者ごとのバケット認証情報（クロスアカウントロール、KMSグラント、有効期間の短いトークン）には、同じライフサイクルの原則をストレージアクセスに適用します。