GitLab のデータ基盤 — 80近い SaaS・社内ソースをどう取り込み、どう権限で守るか¶
作成日: 2026-09-27 出典: GitLab Handbook（Enterprise Data Team）の Data Team Platform / Data Pipelines / Snowflake Guide（2026年7〜8月更新版） 関連: 社内saasデータ統合基盤_ai活用_事例比較_整理 / 国内データ基盤_saas取り込み定番構成_整理 / メルカリ_arca_ai時代の高速プロトタイピング基盤_整理（8-5 PoC 用データ基盤）
0. 要点（3行）¶
- 一言で: 「取り込み方はソースごとに3択で決め、権限は4層のロールで組み、マスクする列はソースのオーナーが決める」。運用方針がハンドブックに丸ごと公開されている、SaaS データ統合の教科書的な事例。
- 取り込み対象は Salesforce・Zendesk・Workday・NetSuite・Zuora・Marketo など79ソース（公開表の行数）。手段は Snowflake Share / ETL ベンダー（主に Fivetran）/ 自作（Airflow 上の Python） の3択で、各ソースに鮮度の目標（RF / SLO）・重要度（Tier 1〜3）・未公表の重要情報（MNPI）を含むかが明記されている。
- 権限は「ユーザー → ユーザーロール → 職能ロール → オブジェクトロール」の階層。列のマスクはソースのオーナーが決め、dbt の schema.yml で付ける。基本の2ロール（Analyst / Analyst SAFE）は Lumos で申請し、Okta SCIM で自動付与。それ以外のロールは Permifrost で管理する。
1. 全体像¶
flowchart LR
subgraph Sources[ソース 79]
SaaS[SaaS<br>Salesforce・Zendesk・Workday<br>NetSuite・Zuora・Marketo ほか]
Internal[社内 DB<br>GitLab.com・CustomersDot]
Events[イベント<br>Snowplow]
end
subgraph Extract[取り込み 3択]
Share[Snowflake Share]
Vendor[ETL ベンダー<br>Fivetran ほか]
Custom[自作<br>Airflow 上の Python]
end
subgraph Snowflake[Snowflake]
Raw[(RAW<br>ソースそのまま)]
Prep[(PREP<br>ソースモデル)]
Prod[(PROD<br>業務向け)]
end
SaaS --> Vendor
SaaS --> Share
Internal --> Custom
Events -->|Snowpipe| Raw
Vendor --> Raw
Share --> Raw
Custom --> Raw
Raw -->|dbt| Prep
Prep -->|dbt| Prod
Prod --> Tableau[Tableau]
Prod --> Jupyter[Jupyter]| 段階 | ツール |
|---|---|
| 取り込み（Extract / Load） | Stitch、Fivetran、Tableau Prep、自作コード |
| オーケストレーション | Airflow、Tableau Prep |
| DWH | Snowflake Enterprise Edition |
| 変換 | dbt と Python スクリプト |
| 可視化 | Tableau |
| 高度な分析 | Jupyter |
| データ鮮度の監視 | Monte Carlo（自動モニター） |
- ELT 型: 取り込みではできるだけ変換せず、ソースと同じ形で入れる。変換はすべて dbt で下流で行う。ソースとの一致は実装時とその後の自動テストで確認する
- 運用は GitLab 自身の上で行う。「すべては Issue から始まり、変更はマージリクエストで入れる」（パイプライン・変換・分析の一部まで）
- Stitch と Fivetran は自分でスケジュールを持つので、Airflow はそれらの実行管理に関わらない
2. 取り込み方の3択¶
2-1. 比較¶
| 観点 | Snowflake Share | ETL ベンダー（Fivetran） | 自作 |
|---|---|---|---|
| 手軽さ | ✅ | ✅ | ❔ |
| 柔軟性 | ❌ | ❌ | ✅ |
| プライバシー | ✅ | ❌ | ✅ |
| セキュリティ | ✅ | ✅ | ✅ |
| 保守性 | ❔ | ❌ | ✅ |
| コスト効率 | ❔ | ❔ | ❔ |
| 誰でも参加できるか | ❌ | ❔ | ✅ |
| データ検証 | ❌ | ❔ | ✅ |
（ハンドブックの表をそのまま日本語化）
2-2. 選び方¶
flowchart TD
New[新しいソースの依頼] --> Tpl[New Data Source Issue テンプレートで調査・検証]
Tpl --> Red{"顧客データ<br>Red data を含む?"}
Red -->|含む| Approved[承認済みの外部委託先<br>経由の手段に限定]
Red -->|含まない| ShareQ{"Snowflake Share があり<br>今後の要件も満たす?"}
Approved --> ShareQ
ShareQ -->|はい| UseShare[Snowflake Share]
ShareQ -->|いいえ| Crit{"重要度が未確定 or<br>早く立ち上げたい?"}
Crit -->|はい| UseVendor[ETL ベンダー]
Crit -->|いいえ| Complex{"オブジェクト・属性が多く<br>UI 管理が危険?"}
Complex -->|はい| UseCustom[自作パイプライン]
Complex -->|いいえ| UseVendor
Files{"GCS などのファイル?"} -->|常に| UseCustom分岐図はハンドブックの文章から起こしたもので、GitLab が公式にこのフローチャートを出しているわけではない。
- Snowflake Share: 使えるなら第一候補。ただし柔軟性がゼロ。要件がはみ出すと選択肢がなくなり、下流のモデルができた後の移行は初期実装より高くつくことがある
- ETL ベンダー: 早く動かしたいとき、重要度がまだ分からないときに向く。ただし契約コストが増える。複雑なパイプラインをベンダーの UI で管理するのは面倒で危険で、承認やテストを通せないため変更管理で苦労した
- 自作: 柔軟性・プライバシー・セキュリティ・保守性で最良。弱点は実装が遅いこと。業務アプリは入れ替わるので、毎回自作する価値はない
- 判断材料: データ区分（顧客データ＝Red data は、リストに載った承認済みの外部委託先経由でしか処理できない）、スキーマの複雑さ、データ量、業務上の重要度、鮮度の要件、連携手段（DB / API / ファイル）。GCS のようなファイルは常に自作が最も簡単で安い
2-3. 自作パイプラインの規約¶
| 規約 | 中身 |
|---|---|
| 使いやすさ | 設定は YAML で抽象化。ドキュメントはテンプレートに従う。ブランチ名を開発・テスト用の格納先名の頭に付け、本番データを汚さない |
| テスト | 最低限 pytest。全パイプラインに CI ジョブ |
| セキュリティ | パイプラインごとにソース側・ターゲット側の権限を個別に付け、secure vault に保管。Snowflake 認証は key-pair。CI ではシークレットをマスク。サービスアカウントは種別を付け、ネットワークポリシーで制限 |
| 性能 | 接続をプールし、インデックスを使い、SELECT * を避ける。可能なら Parquet などで圧縮して転送 |
| 鮮度 | 低遅延ほど処理コストが増える。多くは日次バッチで足りる。API のクォータで頻度が決まることも多い |
| 自己修復 | 冪等に書き、Airflow で自動リトライ。接続エラーは指数バックオフ。連鎖障害にはサーキットブレーカー。バックフィルの手順は初版から文書化 |
3. データソース表 — 各ソースに付けている属性¶
公開表には79行あり、各行に以下が付いている。
| 列 | 意味 |
|---|---|
| Pipeline | 使っている取り込み手段 |
| Raw / Prep Schema | RAW・PREP データベース内のスキーマ名 |
| Audience | 主な利用者（Sales、Finance、People…） |
| RF / SLO | 取り込み頻度 / 上流で入力されてから PROD 層（dbt 変換済み）で使えるまでの目標時間 |
| MNPI | 未公表の重要情報（インサイダー情報）を含むか |
| Tier | 業務上の重要度（1〜3） |
集計（公開表を文字列集計した概算）: Tier 1 が12、Tier 2 が33、Tier 3 が34。MNPI を含むのは16ソース。取り込み手段は Fivetran が最も多く、次が Airflow の自作。
主な SaaS の抜粋:
| ソース | 手段 | 利用者 | RF / SLO | MNPI | Tier |
|---|---|---|---|---|---|
| Salesforce | Fivetran | Sales | 6h / 24h | Yes | 1 |
| Zuora（課金） | Fivetran | Finance | 6h / 24h | Yes | 1 |
| NetSuite | Fivetran | Finance | 6h / 24h | Yes | 2 |
| Workday | Fivetran | People | 6h / 24h | No | 2 |
| Marketo | Fivetran | Marketing | 24h / 24h | No | 2 |
| Zendesk | Meltano | Support | 24h / 48h | No | 2 |
| Greenhouse | Sheetload | People | 24h / 48h | No | 2 |
| Zuora Revenue | Snowflake Share | Finance | — | Yes | — |
| Google Analytics 4 | BigQuery Exporter | Marketing | 24h / — | No | 2 |
| GitLab.com（自社 DB） | pgp（自作の Postgres パイプライン） | Product, Engineering | 12h / 55h | No | 1 |
| Snowplow（イベント） | Snowpipe | Product | 15m / 24h | No | 1 |
ハンドブックの最終更新（2026-07-08）で Meltano の記述を削除するコミットが入っており、Zendesk 等の Meltano 行は移行中の可能性がある（要確認）。ロードマップには「FY26-Q4〜FY27-Q1 に ETL ベンダーを決めて全面移行」とある。
4. 権限設計¶
4-1. ロールの階層¶
flowchart LR
User([ユーザー]) -->|所属| UserRole[ユーザーロール]
UserRole -->|所属| Func[職能ロール<br>例 analyst_core]
Func -->|所属| ObjW[オブジェクトロール<br>workday]
Func -->|所属| ObjN[オブジェクトロール<br>netsuite]
Func -->|所属| ObjZ[オブジェクトロール<br>zuora]
Func -->|所属| ObjD[オブジェクトロール<br>dbt_analytics]
Priv{{権限<br>analytics_sensitive}} -->|付与| Func
Mask[マスキングロール<br>例 people_data_masking] -.->|メンバーにすると<br>マスク解除で見える| Func（ハンドブックにある Data Analyst, Core の例を日本語化）
- オブジェクトロール: ソース（workday、zuora など）単位の閲覧権限。職能ロールに持たせる
- 職能ロール:
analyst_core、analyst_marketingなど職務単位 - マスキングロール: 列単位のマスク。どの列をマスクするかはソースシステムのオーナーが決め、dbt でオブジェクトを作るときに
schema.ymlで列に付ける。マスク前のデータが必要な人には、職能ロールをマスキングロールのメンバーにする（例:people_data_maskingをlocality列に付け、analyst_peopleをメンバーにする）。1列に付けられるマスキングポリシーは1つ
4-2. アクセスの申請と付与¶
sequenceDiagram
participant Us as 社員
participant Lm as Lumos
participant Mg as 上長
participant Dt as データチーム
participant Ok as Okta SCIM
participant Pf as Permifrost
participant Sf as Snowflake
Us->>Lm: アクセス申請 Analyst / Analyst SAFE / Customer User
Lm->>Mg: 承認依頼
Mg->>Lm: 承認
alt Analyst または Analyst SAFE
Lm->>Ok: プロビジョニング
Ok->>Sf: ユーザー作成とラッパーロール付与
else それ以外のロール
Lm->>Dt: 申請を回付
Dt->>Pf: 権限定義を変更
Pf->>Sf: ロール・権限を反映
end- 基本は Analyst と Analyst SAFE の2段階。SAFE 側のアクセスには SAFE ガイドに沿った追加承認が要る
- SAFE は GitLab の情報共有の枠組みで、Sensitive（機微情報。社員データ・顧客情報・MNPI）/ Accurate（正確さ）/ Financial（財務情報は CFO 承認）/ Effect（会社への影響）の頭文字。Analyst SAFE はこの種の機微データに触れられるロール
- 基本2ロールは Okta SCIM が
SNOWFLAKE_ANALYST_OKTA/SNOWFLAKE_ANALYST_SAFE_OKTAというラッパーロールで自動付与 - チーム固有・職能・開発 DB などそれ以外は Permifrost（Snowflake の権限をコードで管理するツール）が正本。Lumos と Permifrost は別の層で、自動では同期しない
- ログインは Okta 経由の SSO
4-3. コスト・運用のガード¶
ABORT_DETACHED_QUERYをアカウント単位で有効化。接続が切れたクエリを5分の猶予後に止め、無駄にウェアハウスを動かさない- ウェアハウスは開発では XS から。XS より大きいサイズで30秒未満で終わるなら無駄遣いのサイン。
explainで走査パーティション数を見てサイズを決める - Snowflake の AI 関数（Cortex）のクレジット消費を監視する仕組みもある（本ノートでは未読）
5. PoC・AI 活用の観点で借りられること¶
| GitLab の仕組み | PoC / エージェントに当てはめると |
|---|---|
| ソースごとに MNPI・Tier・データ区分を明記 | エージェントに見せてよいソースを表で機械的に判定できる |
| 顧客データは承認済み委託先経由のみ | 外部 LLM や SaaS 型 ETL にどのデータを流せるかを事前に決めておく |
| マスク列はソースのオーナーが決め、dbt で付ける | PoC 用ビューで列を落とす判断を、データチームではなくオーナーに寄せる |
| 基本ロールは SCIM で自動、例外はコード管理 | PoC 用ロール（例: analyst_poc）を基本ロール扱いにして申請を自動化 |
| 取り込みは変換せずソースのまま | エージェント向けの整形は dbt 側で。取り込みを直すと全体が壊れる |
6. まとめ¶
一言で: 「手段は3択、区分は表に、権限はコードで」。
| 状況 | GitLab から借りるアイデア |
|---|---|
| どの ETL ツールにするか毎回揉める | Share / ETL ベンダー / 自作の比較表と判断材料を固定する |
| ETL ベンダーの UI 管理が辛い | 複雑なソースは自作に寄せ、テストと MR の承認を通す |
| どのデータが機微か分からない | ソース表に MNPI・Tier・利用者・鮮度目標を必ず書く |
| マスクの判断が属人化 | ソースのオーナーが決め、dbt の schema.yml で宣言的に付ける |
| 権限申請が手作業で遅い | 基本ロールは申請ツール＋SCIM で自動化、例外だけコード管理 |
参考リンク¶
- Data Team Platform: https://handbook.gitlab.com/handbook/enterprise-data/platform/
- Data Pipelines: https://handbook.gitlab.com/handbook/enterprise-data/platform/pipelines/
- Snowflake Guide: https://handbook.gitlab.com/handbook/enterprise-data/platform/snowflake/
- dbt Guide: https://handbook.gitlab.com/handbook/enterprise-data/platform/dbt-guide/
- Permifrost: https://gitlab.com/gitlab-data/permifrost
作成: 2026-09-27 ／ 最終更新: 2026-09-27