sql-jdbc-access-design

SQL / JDBC アクセス設計

あなたはデータプラットフォームのプロダクトデザイナーです。SaaS 製品がホストするデータを、ライブ SQL（ウェアハウス共有、読み取りエンドポイント、または BI ツールが接続する JDBC/ODBC ハンドル）を通じて顧客に公開する方法を設計します。最初の顧客が接続する前に、そのインターフェースが分離され、安定し、ガバナンスが適用され、価格が設定されている必要があります。

リスクは非対称です。API のバグは誤ったレスポンスを返しますが、ライブ SQL ハンドルの分離に関するバグは別の顧客の行を返し、顧客の暴走したクエリは自社のインフラコストを押し上げます。

需要側についての a16z の見解：アプリケーションはますますウェアハウスネイティブに再構築されており、ガバナンスが適用された SQL アクセスはニッチな機能ではなく、プロダクトカテゴリになりつつあります。これは「なぜ今なのか」を説明するアナリストの位置づけであり、以下の実装上の選択肢を裏付ける証拠ではありません。

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

確認事項

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

1. 実際に解決しようとしている課題はどれですか？「データ共有」のもとで混同されがちですが、このスキルの全範囲に当てはまるのは 1 つだけです。
   • (a) パートナー 組織 とのデータ共有。このスキルの共有メカニズムを再利用します。
   • (b) 自社製品の分析機能における、テナントごとのコンピューティング分離。これは内部アーキテクチャ上の課題です。このスキルの分離方式の選択肢は関係しますが、料金設定や BI のセクションは関係しません。
   • (c) 顧客 に、自分のデータをクエリできる SQL エンドポイントを提供すること。このスキルの全範囲に当てはまります。
2. 現在、データはどこにありますか？クラウドウェアハウス（Snowflake、Databricks、BigQuery）、OLTP データベース、セルフマネージドの OLAP クラスターのいずれですか？（どのアーキテクチャ段階がほぼ無料で実現できるかが決まります）
3. スキャン頻度の根拠：一般的な顧客は週に数回アドホッククエリを実行しますか。それとも、1 日に何度も再スキャンするダッシュボードを常時接続しますか？スキャン対象のテーブルはどれくらいの大きさですか？（これによってアーキテクチャの選択肢が絞られます。ステップ 2 を参照）
4. テナンシーについて：顧客アカウントはいくつあり、規模のばらつきはどの程度で、ストアはプール型ですか、それともテナントごとにすでに分離されていますか？
5. 顧客が実際に求めている SQL クライアントは何ですか？Tableau／Power BI／Looker、psql とノートブック、あるいはクエリを実行する埋め込みアプリやエージェントですか？（BI 接続に必要な予算に影響します）
6. 公開するスキーマについて：生の運用テーブルですか、それとも整備されたマートレイヤーですか？（生データを公開すると、内部リファクタリングのたびに顧客への互換性が壊れる変更になります。ステップ 4 を参照）
7. 料金設定の方針：無料機能、上位プラン限定、従量課金のアドオンのどれですか。また、クエリのコンピューティング費用は誰が負担すべきですか？（ステップ 8 を参照。標準的な優先順位付けの 3 項目、すなわちリリース日、単発か複利的か、工数の上限についても確認してください）

ハーネスに永続メモリがある場合は、設計で確定した決定事項（アーキテクチャ段階と次の段階へ移行する条件、分離メカニズムと ID 関数、スキーマ安定性の契約と破壊的変更の定義、認証情報の段階、ガバナンス上限、料金設定の形）を保存してください。そうすれば、後続の実行（新しいコンシューマータイプ、スキーマ変更、料金改定）で設計を最初から導き直す必要がなくなります。

利用者のタイプとスキャン頻度

2 つの区分で決まります。

• 利用者のタイプ：
  • Tableau や Power BI を使う BI アナリスト には、認定済みのドライバー、安定した列名、予測可能な型が必要です。ドキュメントを見ることはなく、利用するツールの接続ダイアログだけを目にします。
  • psql、dbt、またはノートブックを使う データエンジニア は多少の粗さを許容しますが、最も大きなクエリを実行します。
  • 組み込みアプリやエージェント は、人間が確認しない機械生成クエリを高頻度で発行します。請求額が届くまで、異常なクエリパターンに誰も気づかないため、厳格なコスト上限が最も有効です。
• スキャン頻度： 週に 2 回同じテーブルを読み取る場合と、40 人の閲覧者がいる朝のダッシュボードで同じテーブルを使う場合では、適切なアーキテクチャが異なります（ステップ 2）。経済性を左右するのは企業規模ではなく、頻度です。

存在する中で最も要求の厳しい利用者のタイプに合わせて設計し、組織図上の製品購入者ではなく、測定または誠実に見積もったスキャン頻度に基づいてアーキテクチャを選定してください。

ワークフロー

1. 問題を確認し、利用者を一覧にします。
2. スキャンの経済性に基づいてアーキテクチャを選定します。
3. エンジンでテナント分離を徹底します。
4. スキーマ安定性の契約を公開します。
5. BI 接続とドライバーの配布を設計します。
6. クエリガバナンスとコスト上限を設定します。
7. 認証情報を発行します。
8. 料金体系を選びます。

各ステップの説明は、以下に順番に記載されています。顧客に接続情報を渡す前に、ステップ 3 と 6 の両方の判定を通過する必要があります。それ以外は段階的に進められます。

1. 問題を確認し、利用者を一覧にする

• 質問 1 の答えを明確に確定し、記録してください。「データ共有」、「マルチテナント分離」、「顧客の SQL アクセス」は互いに重なるものの、異なるアーキテクチャを指します。誤った問題に答える設計では、誤った分離プリミティブを出荷することになります。
• 想定されるクエリの形（ダッシュボードの更新、アドホックな探索、スケジュールされた抽出、エージェントのトラフィック）とともに、具体的な利用者（質問 5）を列挙してください。このリストが、以下の各候補を評価する際の入力になります。
• 読み手に対する境界を明示してください。このインターフェースが提供するのは ライブクエリ です。利用者が実際に求めているのが定期的なファイルや、自分たちのウェアハウスへのデータ供給であれば、ここで設計を始める前に、一括配信を扱う関連スキル（「参考資料」を参照）に引き継いでください。

2. スキャンの経済性に基づいてアーキテクチャを決める

3つのアーキテクチャを順位付けします。どれが最適かを決めるのは好みではなく、スキャン頻度とデータがすでにどこにあるかです。

• 効率：ゼロコピー共有 > レプリケートされたコピーまたは読み取りエンドポイント > テナントごとのコンピューティング分離

• 労力：テナントごとのコンピューティング分離 > レプリケートされたコピーまたは読み取りエンドポイント > ゼロコピー共有

• 価値：テナントごとのコンピューティング分離 > ゼロコピー共有 > レプリケートされたコピーまたは読み取りエンドポイント

• デフォルトの選択肢：ゼロコピーのウェアハウス共有 ― データがすでに共有クラウドウェアハウスにあり、顧客のスキャン頻度が低い場合に適しています。共有はコピーではなくメタデータの付与です。構築コストが最も低く、データは常に最新で、ガバナンスもソースに一元化されたままです。注意点はコストモデルです。ライブアクセスではクエリのスキャンごとに料金が発生するため（リージョン間のデータ転送料も加算されます）、スキャン頻度が低い場合に限り採算が合います。

• スキャン頻度が増えて計算が逆転したら、レプリケートされたコピーまたは専用の読み取りエンドポイントに移行します。

  • レイクハウスの実務者であるAlex Mercedの経験則です（ベンチマークではなく、あくまで一人の実務者による目安として扱ってください）：コピーは更新ごとに一度、ライブアクセスはクエリごとに一度、料金が発生します。
  • 約200 GBのテーブルを1日あたり約20回スキャンする場合、ライブで再スキャンするデータ転送料は、レプリケートされたコピーを1年間維持する費用よりも、月あたりで高くなります。
  • 毎朝40人が読み込むダッシュボードは、この境界を超えています。1日に2回、2人のアナリストがクエリを実行する程度なら超えません。
  • この選択肢の代償は、最後の更新時点までデータが古くなることと、PIIを含むデータのコピーがもう一つ増え、そのガバナンスが必要になることです。
  • レプリカを本番の運用スキーマに直接向けないでください。手順4を参照してください。

• テナントごとのコンピューティング分離に移行します ― 各テナントに専用のクエリエンジンを割り当てます（共有ストレージ上にテナントごとのインスタンスを設け、単一のエンドポイントを前段に配置します）。これは、負担が最も大きい選択肢です。

  • 価値が最も高い選択肢です。設計上、ノイジーネイバーを排除でき、暴走したクエリの影響範囲を1つのテナントに限定し、テナントごとのコストを明確に把握できます。
  • 労力が最も大きい選択肢です。エンジン群の構築と運用が必要なため、効率を比較するすべての順位で劣ります。
  • それでもこの選択肢に進む条件は2つあります。多くのテナントにわたり、任意の顧客作成SQLがダッシュボードまたはエージェントの頻度で実行される場合、または共有クラスターで最悪ケースのクエリがすでにプロダクト自体を脅かしている場合です。
  • PostHogは両方の条件に該当しました。共有クラスターに対する制約のない顧客クエリを「基本的に維持不可能」と判断し、Postgresワイヤープロトコルのエンドポイントの背後に組織ごとのエンジンを設ける方式に再構築しました（references/vendor-case-studies.mdを参照）。

この順位付けはデフォルトであり、絶対的なルールではありません。インタビューに基づいて順位を付け直してください。

• すでにSnowflake／Databricks／BigQueryを使っている場合、ゼロコピーはほぼ無料で実現できるため、そもそもデフォルトの選択肢になっています。
• OLTPのみのスタックでウェアハウスがない場合は、ゼロコピーの選択肢を下位に移すのではなく、完全に取り除きます。
• 厳しいリリース期限がある場合は、現在のプラットフォームで実現できる選択肢に進みます。
• エージェントが利用する場合、または資産を積み上げる方針がある場合は、労力が大きくても分離の選択肢に進みます。

3. エンジンでテナント分離を強制する

分離はクエリエンジンに実装し、アプリケーションコードには実装しません。アプリケーション層の WHERE tenant_id = ? フィルターは、この用途における明確な失敗パターンです。外部 SQL ハンドルを使う場合、クエリを遮断するアプリケーション層は残っていないため、どこかで一度でもフィルターを見落とすと、別の顧客の行が漏えいします。エンジンレベルのポリシーを使えば、フィルターを省略したクエリは何も返さないようにできます。

• データウェアハウスの共有では、プライベートなベーステーブルと、エンジンが認識する呼び出し元の ID（Snowflake の current_account()、Databricks Delta Sharing の current_recipient()）でフィルタリングしたプライベートなエンタイトルメントテーブルを結合するセキュアビューまたはダイナミックビューだけを公開します。ベーステーブルとマッピングテーブルは共有に含めません。
• NULL コンテキストの落とし穴：アカウント間の共有をまたぐと、セキュアビュー内の CURRENT_ROLE() と CURRENT_USER() は NULL を返します。これらを参照するポリシーは、条件式の形によっては何も一致しないか、さらに悪い場合はすべてに一致します。共有の境界をまたいで安全に使えるのは、共有を認識する ID 関数だけです。
• 受信者プロパティの パーティションフィルタリング は、アクセス制御ではなくパフォーマンス最適化として扱います。Delta Sharing のドキュメントでは、ベストエフォートとされています。強固な分離は、ダイナミックビューの述語だけで実現します。
• Postgres 系のエンジンでは、FORCE ROW LEVEL SECURITY を設定した行レベルセキュリティを使い、検証済みトークンからテナント ID をサーバー側でセッションコンテキストに注入します。クライアント提供の入力は決して使いません。RLS には、よく知られた 4 つの失敗モード（ポリシーの再帰、WITH CHECK の欠落、許可的ポリシーの OR 合成、所有者権限によるビューのバイパス）とパフォーマンス上のルールがあります。ポリシーを作成する前に、references/rls-failure-mode-catalog.md を確認してください。
• プロバイダー側ではなくコンシューマー側から分離を検証します。別のテナント（2 つ目のテストアカウント、またはデータウェアハウスのコンシューマーをシミュレートするセッションモード）としてプローブクエリを実行し、他テナントの行が 0 件であることを必須条件とします。これはゲートです（測定を参照）。ポリシーを変更するたびに再実行してください。

4. スキーマ安定性の契約を公開する

顧客のダッシュボードがテーブルにクエリを実行した時点で、スキーマは API になります。列はフィールド、テーブルはエンドポイント、ダッシュボードはクライアントです。API のバージョニングとの違いは、スキーマ変更がしばしば 意図せず 発生することです。ソースシステムの更新や、読みやすさのための名前変更が、非推奨を知らせるヘッダーもなく下流に波及します。

• 稼働中の運用スキーマは決して公開しません。正本システムから複製した、厳選されたマート層を提供し、内部スキーマの変化が顧客のダッシュボードに反映されず、複製の境界で止まるようにします。

• 追加のみのルールを採用します。列やテーブルは自由に追加できますが、その場で名前変更、型変更、削除をしてはいけません。拡張／縮小の手順で進化させます。

  1. 新しい列を追加します。
  2. ドキュメントで古い列を非推奨にします。
  3. コンシューマーを移行します。
  4. 依存するものがなくなった場合に限り、削除します。

  Amplitude のイベントスキーマは、実運用されている実例です。新しいイベントタイプの追加に伴ってテーブルと列を追加するだけで、設計上、後方互換性を保っています。

• 慣例ではなく、CI で契約を強制します。ドキュメントに書かれているだけの契約は、単なる期待にすぎません。

  • dbt モデル契約（1.5 以降）は、列の破壊的変更があると実行を失敗させます。
  • オープンソースの datacontract CLI は、マージ前に PR に対して契約を検証します。

• BI ダッシュボード、dbt ジョブ、組み込みアプリでは依存する部分がそれぞれ異なるため、契約は次の 4 つの要素で記述します。

  • スキーマ：列、型、NULL 許容性。
  • 品質：完全性のしきい値。
  • 鮮度：更新 SLA。
  • 可用性：稼働率／レイテンシ。

• 破壊的変更が本当に避けられない場合は、通知期間を設けた非推奨化の仕組みを通じて変更します。バージョニングに関する関連スキルがその仕組みを定め、この契約では何を破壊的変更とみなすかを定義します。

5. BI 接続とドライバーの配布を設計する

BI ツールへの対応は、一度限りの統合ではなく、認定のための継続的なコストです。継続的なエンジニアリング作業として予算を確保し、どこまで対応するかは質問 5 に基づいて決めてください。

• 最もコストを抑えられる選択肢は、エンジンが対応している場合、既存のワイヤープロトコルを使うことです。Postgres ワイヤープロトコルのエンドポイントなら、すべての BI ツール、psql、すべての ORM をすぐに利用できます。どれも Postgres ドライバーを同梱しているためです。PostHog がテナントごとのエンジンの前段にこれを配置したのは、まさにこのためです。その代わり、方言の互換性には制約があり、Postgres 方言のみをサポートすることになります。

• カスタム方言は、この選択肢で避けるべきアンチパターンです。PostHog は、独自の HogQL を、直接公開が最初から選択肢にならなかった理由として挙げています。「広くサポートされている既存の言語ではない」ということは、BI ツールとの統合をすべてゼロから始めることを意味します。

• 独自のドライバーを提供するには、次の対応が必要です。

  • 仕様に準拠した Type-4 JDBC ドライバーと、正確な SQLSTATE を実装します（Tableau は、不正な認証情報に対して SQLSTATE 28000 ではなく汎用エラーを返すと、コネクターの動作に問題が生じると警告しています）。
  • 証明書の有効期限が切れたら更新しなければならない、ツールごとの署名付きコネクターパッケージを用意します。
  • ツールごとの認定プログラムに参加します。各プログラムのポリシーにより、接続に関する一次サポートの窓口は BI ベンダーではなく、あなたになります。

  詳細とツールごとの認定要件については、references/bi-connectivity-and-credentials.md を参照してください。

• サポートするクライアントごとに、接続設定のページを公開します。接続文字列が文書化されていないと、顧客ごとにサポートチケットが発生します。記載する内容は次のとおりです。

  • URL のテンプレート。
  • ドライバーのクラスまたはダウンロード先。
  • クライアントのデフォルト設定に任せず、TLS の要件を明記します。
  • 認証方式。

6. クエリガバナンスとコスト上限を設定する

データウェアハウスのコスト管理機能は、どれもデフォルトで有効になっていません。GA 前に、外部データウェアハウスまたはエンジンごとに設定する必要があります。適用の仕組みは API のレート制限とは異なります。ゲートウェイでリクエスト数を数えるのではなく、長時間稼働するエンジンのコンピューティング秒数と支出額に上限を設けるためです。ここで設計し、接続数やエンドポイントでの毎分クエリ数など、リクエスト単位の制限は、API に関する関連スキルのポリシーと整合させてください。

• クエリごとのサーキットブレーカー：暴走したクエリを一晩中実行させずに終了させるステートメントタイムアウトと、クエリが実行枠をいつまでも待たないようにするキュー内ステートメントのタイムアウトを設定します。
• テナントまたはワークロードごとに同時実行数の上限を設け、ある顧客の並列ダッシュボード更新が共有エンジンを占有しないようにします。
• タイムアウトとは別に支出額の上限を設定します。リソースモニター（またはエンジンに相当する予算アラーム）を使い、クレジット予算に達したらデータウェアハウスを停止します。タイムアウトは個々のクエリに上限を設け、モニターは月間の支出に上限を設けます。
• リーダーアカウントの落とし穴：コンピューティング料金をあなたが負担するコンシューマーアカウント（Snowflake リーダーアカウントや、ステップ 8 のようにプロバイダーが支払いを負担する形態）をプロビジョニングする場合、デフォルトでは、そのアカウントのデータウェアハウスがあなたのアカウントに請求されるクレジットを無制限に消費する可能性があります。そうしたアカウントすべてにリソースモニターを設定することは、このシステムのコスト管理で最も重要な手順であり、任意の強化策ではありません。
• エスカレーションの判断基準：他のテナントを常にキューで待たせたり、モニターを作動させたりするテナントは、分離された、またはより大きなコンピューティング環境に移します。1 つのテナントに合わせて全員の共有上限を引き上げてはいけません。

7. 認証情報を発行する

業界では静的なデータベースパスワードの廃止が進んでいます。Snowflake は段階的な廃止スケジュールを通じてこれを徹底し、すべてのサービスユーザーを鍵ペア、OAuth、PAT、またはワークロード ID に移行させています。そのため、パスワードを例外として残すのではなく、この流れに沿って認証情報の発行を設計してください。

優先順位は、短命トークン ＞ マネージドシークレット ＞ 静的パスワードです。接続文字列に認証情報を直接埋め込むのはアンチパターンであり、ドキュメントに記載する手順では示さないでください。

• サービスアカウントと自動化：鍵ペア認証で短命 JWT に署名することで、パスワードがネットワークを介して送信されることはありません。パスワードへのフォールバックを防ぐため、マシン ID をサービスタイプとして設定してください。
• BI ツール：OAuth（デスクトップツールでは PKCE を使用した認可コードフロー）を使うことで、BI ツールにデータベースパスワードを保存させずに済みます。ただし、トークン更新のサポート状況はクライアントによって異なります。更新可能なトークンを保持できない BI ツールでは、鍵ペアまたは PAT を使用するサービスアカウントに切り替える必要があります。そのため、どこでも OAuth が使えると想定せず、優先順位を柔軟に切り替えられるようにしてください。
• ステップ 3 の権限マッピングに基づき、すべての認証情報がテナント固有のデータだけにアクセスできるよう、設計段階からスコープを制限してください。TLS を必須要件として明記し、顧客が自分で認証情報を失効できるようにします。鍵の形式、ローテーションの UX、シークレットの適切な管理については、認証情報を扱う関連スキルに従ってください。このインターフェース固有の詳細は、references/bi-connectivity-and-credentials.md に記載されています。

8. 料金体系を選ぶ

SQL アクセスは有料プランまたはアドオンとして提供し、無料機能にはしないでください。すでに提供されている事例（Stripe Sigma、Heap Connect、Mixpanel Data Pipelines）は、顧客がまさにこの機能に対価を支払うことを示しています。また、料金を設定すること自体が、過剰なサービス提供にコストがかかる領域に対するガバナンス管理となります。料金体系は3種類あり、次の順に推奨されます。

• 効率性：固定アドオンまたはプランによる制限 > 従量課金／ボリューム別料金 > プロバイダー負担のコンピューティング費用のパススルー

• 労力：従量課金／ボリューム別料金 > プロバイダー負担のコンピューティング費用のパススルー > 固定アドオンまたはプランによる制限

• 価値：従量課金／ボリューム別料金 > プロバイダー負担のコンピューティング費用のパススルー > 固定アドオンまたはプランによる制限

• 基本の選択肢：固定アドオンまたはプランによる制限（Heap Connect、Mixpanelの方式） - SQL アクセスは上位プラン、または固定価格のアドオンで利用可能になります。請求関連のエンジニアリングはほぼ不要で、利用制限そのものが気軽な不正利用を抑制します。リスクは、コンピューティングコストが固定料金を上回るほど大量に利用するユーザーです。手順6の上限を設けている場合に限り、許容できます。

• 自社のコスト負担が従量ベースの場合、または顧客のデータ量に桁違いの幅がある場合は、従量課金／ボリューム別料金に移行します。 この選択肢は、あまり採用されていません。

  • 価値が最も高い選択肢です。収益がコストに連動するため、気づかないうちに不採算となる顧客が生じません。
  • 労力が最も大きい選択肢です。使用量の計測、料金テーブル、超過料金のロジックが必要になるため、上記2つの条件のいずれかに該当するまでは、効率性の評価で劣ります。
  • 購入者がすでに理解している事業指標を基準に計測してください（Stripe Sigmaでは、クエリは無制限で、月間請求額に応じて料金が決まります）。技術に詳しくない購入者が予測できないウェアハウスクレジットを基準にしてはいけません。
  • Sigmaは、料金指標を後から見直せることも示しています。提供開始後に、自社の料金モデルを変更しました。

• プロバイダー負担のコンピューティング費用のパススルーは、自由に選ぶ料金体系というより、リーダーアカウントやマーケットプレイスへの掲載に伴って採用される料金設定です。コンピューティング費用を負担した後、原価に利益を上乗せして請求します。各アカウントにリソースモニターを設定している場合（手順6）に限り採用してください。また、同じ選択肢の中に、利用者がコンピューティング費用を負担する方式もあります。HubSpot の Snowflake 共有では、顧客自身のアカウントにコンピューティング費用を請求し、最上位プランに利用を制限しています。

この順位は基本方針であり、絶対的な決まりではありません。質問7と3つのインタビューを踏まえて、順位を見直してください。

• 複利的に価値が積み上がる資産を目指す場合は、従量課金を早期に採用します。固定料金での提供開始後に計測機能を追加すると、顧客向けの料金改定となるためです。
• リリース期限が厳しい場合は、固定プラン制限を維持します。請求関連のエンジニアリングが不要なのは、この選択肢だけです。

料金事例と特定時点での料金額については、references/vendor-case-studies.md を参照してください。顧客に料金を提示する前に、必ず最新の料金を確認してください。

失敗パターン

避けるべきパターンのチェックリストです。どれも監査で直接指摘される事項です。

• テナント分離をエンジンのポリシーではなく、アプリケーション層の WHERE 句で実装する。
• 共有ビューのポリシーに共有対応の ID 関数ではなく CURRENT_ROLE()／CURRENT_USER()（共有では NULL）を使用する。
• パーティションのフィルタリングをアクセス制御として信頼する。
• 顧客の SQL クエリを共有本番クラスターで実行させる ― PostHog が「耐え難い」としたシナリオです。
• 運用中のスキーマをそのまま公開し、内部のリファクタリングで顧客のダッシュボードが壊れる。
• 変更を拡張／縮小の手順を踏まずにそのままリリースし、検出する CI コントラクトも用意しない。
• リソースモニターを設定せずにリーダーアカウント（またはプロバイダーがコンピューティング費用を負担する方式）を利用する。
• 標準のワイヤープロトコルがあるのに、独自のクエリ方言を採用する。
• 分離を目的にテナントごとのスキーマを選び、テナント数が数百を超えた段階で、コネクションプーリングや DDL マイグレーションへの対応が破綻する。
• プロバイダー側からしか分離を検証せず、利用者側として検証しない。
• RLS 固有の落とし穴（再帰、WITH CHECK の欠落、OR の合成、ビューによるバイパス）：対処方法を含む一覧は references/rls-failure-mode-catalog.md にあります。

測定

• 分離ゲート：別のテナントとして実行したプローブクエリ（シミュレートしたコンシューマーセッションまたは2つ目のテストアカウント）は、すべての共有ビューとポリシーにおいて、他テナントの行を1件も返しません。これはバイナリ判定で、GA前およびポリシーやスキーマを変更するたびに確認します。
• スキーマゲート：CIのコントラクトチェックを通過した後に、顧客向けスキーマへ破壊的変更が到達することはありません。顧客が気づかなかった場合でも、破壊的変更がリリースされたらゲート失敗です。
• コストゲート：外部コンピューティングの各ハンドルには、最初の顧客が接続する前に、ステートメントタイムアウト、同時実行数の上限、支出上限が設定されている必要があります。チェックリストで監査し、ハンドルごとに合否を判定します。
• 初月からベースラインとして追跡するトレンド（閾値ではありません）：新規接続あたりの接続サポートチケット数、テナントごとのクエリコストと支払価格の比較、鮮度SLAの遵守状況。顧客向けのデータ提供面には、社内ダッシュボードより明らかに高い信頼性基準が求められます。ここでの障害はサポートチケットや解約リスクにつながるため、トレンドの悪化はプロダクトインシデントと同様にトリアージします。

3つのゲートがすべて合格するまで反復します。これらは目標ではなく、通過必須のゲートです。その後、トレンドを参考に価格設定やアーキテクチャを再検討します。

呼び出し例

• 「顧客から、自社プロダクトのデータにTableauを接続したいという要望が続いています。Snowflakeを使っているので、SQLアクセス面を設計してください。」
• 「エンタープライズ向けアドオンとして、SQLへの直接アクセスを販売したいと考えています。大半の顧客がダッシュボードの接続先にする場合、どのようなアーキテクチャと価格設定が適切でしょうか？」
• 「本番Postgresの読み取りレプリカを顧客に公開する計画をレビューしてください。どんな問題が起きますか？」

参考資料

• samber/developer-platform-skills@etl-connector-strategy - 他社のETLプラットフォーム上でソースコネクターになる方法を扱います。このスキルでは、顧客があなたに直接クエリするケースを扱います。
• samber/developer-platform-skills@api-integration-surface-strategy - 他の統合手段も含め、SQLアクセスを提供するかどうかを包括的に判断します。
• samber/developer-platform-skills@api-auth-key-management - API認証情報のキー形式、ローテーションのUX、シークレットの衛生管理を扱います。ステップ7では、同じ規律をデータベースハンドルに適用します。
• samber/developer-platform-skills@api-versioning-policy - 非推奨化の仕組みと通知期間を扱います。ステップ4のコントラクトでは、スキーマにおいて何が破壊的変更に当たるかを定義し、このスキルでは破壊的変更の告知と廃止の方法を定めます。
• samber/developer-platform-skills@api-rate-limit-policy - APIゲートウェイでのリクエスト数による制限を扱います。一方、ステップ6ではクエリエンジンのコンピューティングと支出に上限を設けます。公開する2つのポリシーに矛盾があってはなりません。