Sansan「Corporate DataBridge」— SSoT を持たない情シス内製データ連携基盤の設計¶

作成日: 2026-07-23 出典 / きっかけ: Sansan Tech Blog（2026-07-22、技術本部コーポレートシステム部・湯川氏、ブログリレー第1回）。姉妹記事（権限管理基盤 2025-12-07）・業界標準パターン（HR-driven provisioning）・各 OSS の一次資料まで裏取り関連: データ基盤_メタデータとgcsで法務経理ai_整理社内mcp共通基盤_認証認可ログ_整理 cyberagent_ai活用レベル定義と数値レポート_整理（組織データが AI 活用の足場になる点で接続）palantir_foundry_ontology_ビジネスのai化基盤_整理（同じ enforced contract。こちらは書き込み=操作まで契約化した完成形）カンム_synapse_セマンティックレイヤーの育て方_整理（別軸＝enforced でない業務コンテキスト注入。契約ラダーとは分けて読む）

0. 要点（3行）¶

Sansan 情シスが内製した人・組織データの連携ハブ。核となる原則は「自らデータの正本（マスタ）を管理しない」— SSoT は各業務システム（人事マスタ等）に残し、DataBridge は収集・整形・提供（投影＝Projection）に徹する。二重管理を構造的に回避
利用側には固定エンドポイント（例: GET /approvers/{employee_id}）を約束することで、組織改編・決裁ルール変更・SaaS リプレイスの影響を DataBridge の内側に局所化。「変化に強い」の実装が API 契約の固定という形で具体的
設計部品も堅実: sqlc（型安全 SQL）、PostgreSQL トリガー＋ _history テーブル（valid_from/valid_to）での履歴管理、Step Functions での依存順序制御、Valkey でのレート制限。標準パターン（HR-driven provisioning / MDM / CQRS 読み取りモデル / DDD の ACL）の交点として読むと汎用性が高い

1. 課題背景（なぜ作ったか）¶

SaaS 連携が増えるたびに「細かい処理（取得・整形・突合）」が各所にばらばらに積み上がる — 連携の N×M 問題
組織体制の見直し（部署改編・兼務・決裁権限変更）に、人・組織データの連携が追いつかない
数値的裏付け（業界側）: SmartHR 調査（2025-06）で情シスの 63.9% が退職者・異動者の SaaS アカウントを適切に管理できていない、44.9% が人事・総務との情報連携に課題 — この記事の課題は Sansan 固有でなく業界共通
同じコーポレートシステム部は権限管理基盤の作り直し（2025-12-07 記事）も進めており、「情シスが基盤を内製する」路線の一環（ミッションは「EX をシンプルにする」）

2. 核となる設計原則 — SSoT 非保持・投影に徹する¶

[人事マスタ(Workday等)] [Okta] [GWS] [Notion] [kickflow] [Slack]
        │ SSoT      │        │       │         │        │
        └───────┴──── 収集・整形 ─┴───────┴──────┘
                        ▼
              ┌──────────────────┐
              │ Corporate DataBridge │  ← 投影(Projection)を内部保持
              │  ・正本は持たない       │     更新責任は元システムに帰属
              │  ・履歴(_history)を持つ │
              └──────────────────┘
                        ▼ 固定エンドポイント（契約）
        GET /approvers/{employee_id} など
                        ▼
        [購買申請] [IT資産管理] [ライセンス管理] [アカウント発行]

正本（マスタ）を持たない: データの更新責任は元システムに帰属。DataBridge が持つのは読み取り用の投影のみ → 二重管理・出所不明データの発生を構造で防ぐ
利用側 API を固定: 購買申請システムは「申請者の所属・兼務・決裁権限者・金額別承認ルール」を固定 API で取得。組織変更や人事システムリプレイスが起きても利用側の実装変更は不要
標準パターンとの対応（自分の整理）:

DataBridge の要素	対応する一般パターン
正本は元システム・投影のみ保持	CQRS の読み取りモデル / マテリアライズドビュー
元システムの都合を吸収して固定 API 提供	DDD の Anticorruption Layer（ACL）
人事マスタ→各 SaaS への伝播	HR-driven provisioning（Workday as Master → Okta/SCIM）の一般化。ID 連携に限らず業務データ全般へ拡張した形
`_history`（valid_from/valid_to）	SCD Type 2（「当時の組織・決裁権限」で監査・再現できる）

3. アーキテクチャ・技術スタック¶

レイヤ	採用	補足
言語/FW	Go + Gin	実行は AWS Lambda
DB	Aurora PostgreSQL（pgx / golang-migrate / sqlc）	sqlc: SQL から型安全な Go コードを生成。カラム名誤り・型不整合を生成時に検出
キャッシュ	Valkey（go-redis）	Linux Foundation による Redis 7.2.4 フォーク（2024-03、BSD-3）。レート制限（ログイン失敗回数・ロック状態を TTL 管理）に使用
バッチ	AWS Step Functions	部署の親子関係→従業員参照のような依存順序・再試行・エラーハンドリングを宣言的に管理
認証/運用	golang-jwt / zerolog / swaggo	構造化ログ・Swagger 自動生成

4つの設計の読みどころ¶

sqlc — 生 SQL の可読性と型安全の両取り。ORM を避けつつ手書きマッピングも避ける中道
PostgreSQL トリガーによる履歴管理 — API 経由でもバッチ経由でも、更新経路を問わず _history に自動記録される点が肝。アプリ層に履歴書き込みを任せると経路追加時に漏れる（構造で守る発想。自分の data-modeling ルール「制約は DB に守らせる」と同型）
Step Functions バッチ — 依存の明示・リトライを自前実装しない（「時間差で多分終わってる」スケジュール並べを排除）
Valkey レート制限 — TTL による自動リセットでロック解除の運用レス化

4. 考察（ここは自分の解釈）¶

一言でいうと「情シス版 Anticorruption Layer」。MDM 製品を買って正本を集約するのでも、iPaaS で N×M 連携を張るのでもなく、「正本は現場に残し、読み取り契約だけ中央が握る」— 統制と現場自律のバランス点として筋が良い
変化への強さの正体は API 契約の固定。今日の自分の言葉で言えば「利用側との contract を凍結し、変化を投影層で吸収する」— テスト設計の「振る舞い/契約を固定する」と同じ思想が組織データ連携に現れている
リスク・未回答の論点（記事には書かれていない、自分の批判的読み）:
中央ボトルネック化: 連携が増えるほど DataBridge チームが Conway 的な詰まり所になる。固定 API の設計・変更ガバナンス（バージョニング方針）が長期の勝負所
鮮度と整合性: 投影は本質的に結果整合。承認者情報のような「今この瞬間の正しさ」が要るデータの鮮度 SLA をどう約束するかは不明
書き込みの逆流禁止: 投影に対する書き込み要求（「DataBridge で直したい」）が必ず出る。正本非保持の原則をどう守り続けるかは運用規律の問題
データ品質は依然として元システム（SSoT）の責任 — ブリッジは品質を作れない（garbage in, garbage out）
自分の docs との整合: valid_from/valid_to は data-modeling.md の SCD Type 2、Step Functions の依存明示は data-engineering.md の「依存は明示的に張る」、履歴のトリガー化は「制約は DB に守らせる」— 先週書いたルール群の実地例として最良クラス。人・組織データは AI エージェント時代の権限・承認の足場（CA の paved paths、Buzz のエージェント識別と同じ文脈）でもあり、「超重要」という直感に同意

5. まとめ — 転用できる型¶

状況	型
SaaS 連携が増えて突合コードが散らばる	収集・整形・提供を1箇所（ブリッジ）に集約。ただし正本は持たない
組織改編のたびに連携が壊れる	利用側 API（契約）を固定し、変化を投影層で吸収
「当時の組織で」の監査要求	`_history` + valid_from/valid_to（SCD Type 2）を DB トリガーで経路非依存に
ID 連携だけ整っていて業務データ連携が野良	HR-driven provisioning の考え方を業務データ全般へ一般化（本記事の型）

参考リンク¶

出典記事: https://buildersbox.corp-sansan.com/entry/2026/07/22/130000
姉妹記事「AWS / Google Cloud / SaaS の横断的な権限管理基盤を作り直している話」（2025-12-07）: https://buildersbox.corp-sansan.com/entry/2025/12/07/100000
Okta「HR-Driven IT Provisioning」: https://www.okta.com/solutions/hr-driven-it-provisioning/
SmartHR 情シス調査（2025-06、63.9%）: https://smarthr.jp/release/20250609_research/
sqlc: https://docs.sqlc.dev/ / 誕生記事: https://conroy.org/introducing-sqlc
Valkey（Linux Foundation・2024-03 発足）: https://www.linuxfoundation.org/press/linux-foundation-launches-open-source-valkey-community

作成: 2026-07-23 ／最終更新: 2026-07-23