社内の色々な SaaS のデータを使える基盤 — 国内外の事例比較¶
作成日: 2026-09-27 出典 / きっかけ: メルカリ Arca（PoC 基盤）を読んで「PoC 環境から社内 SaaS・データ基盤をどう触らせるか」を検討する流れで、国内外の構築事例を調査 関連: メルカリ_arca_ai時代の高速プロトタイピング基盤_整理 / sansan_corporate_databridge_情シス内製データ連携基盤_整理 / エアークローゼット_agentic_graph_rag_と社内mcp基盤_整理 / 社内mcp共通基盤_認証認可ログ_整理 / 社内aiエージェント基盤_company_brain_比較_整理 / layerx_ai_agent基盤_bedrock_litellm_durable_temporal_整理 / メルカリ_socrates_データ基盤とマルチエージェント_整理
0. 要点（3行）¶
- 一言で: SaaS のデータを使えるようにする道は2本ある。「DWH に集めてから使う（ELT 型）」と「エージェントがツール経由で SaaS を直接叩く（ツール層型＝社内 MCP）」。前者は集計・分析に強く、後者は最新状態の参照・操作に強い。先行企業は両方を持ち、用途で使い分けている。
- ELT 型の勘所は「取り込み手段を3択で決める」（GitLab: ベンダー提供の共有 / Fivetran 等の ETL SaaS / 自作）と「データ区分で経路を縛る」（顧客データは承認済み委託先経由のみ）。国内は trocco / Fivetran → BigQuery / Snowflake → dbt が定番構成。
- ツール層型の勘所は「1つの共通ツール層に集約し、エージェントごとに小さく切り出して渡す」（Stripe Toolshed: 約500ツール、Minions には意図的に小さいサブセット）と「資格情報をエージェントに持たせない」（Shopify Aquifer の credentials proxy、Arca の出口プロキシ、Cloudflare OS の Gatekeeper）。
1. 2つの型¶
【ELT 型】 SaaS ──(Fivetran/trocco/自作)──> DWH raw ──dbt──> mart ──> ビュー ──> 人・エージェント（SQL）
強み: 横断集計・履歴・重いクエリ / 弱み: 鮮度（日次〜時間）、書き込み操作はできない
【ツール層型】 エージェント ──> 社内 MCP / ツール層（認証・認可・監査を集約）──> 各 SaaS API
強み: 最新状態・操作（起票・更新）/ 弱み: 横断集計が苦手、API レート制限、権限設計が SaaS ごと
| 観点 | ELT 型 | ツール層型（社内 MCP） |
|---|---|---|
| 向く問い | 「先月の商談化率を部署別に」「問い合わせカテゴリの推移」 | 「この顧客の最新チケットは？」「Linear に起票して」 |
| 鮮度 | バッチ（日次〜時間） | リアルタイム |
| 権限の効かせ方 | DWH のロール・ビュー・列/行制御で一元管理 | SaaS ごとの権限＋ツール層の認可 |
| 失敗の典型 | 生テーブルを直接見せて PII 漏れ・誤集計 | 全ツールを渡して誤操作・過剰権限 |
| 代表事例 | GitLab、LayerX コーポレート、M&Aクラウド、メルカリ Socrates | Stripe Toolshed、エアークローゼット MCP 群、Shopify Aquifer |
2. 事例¶
2-1. GitLab — 取り込み手段を「3択」で決める（ELT 型・海外）¶
公開ハンドブックでデータ基盤の運用方針を丸ごと公開している。DWH は Snowflake、変換は dbt。
抽出手段は3カテゴリのどれかに収める:
| 手段 | 使いどころ | 弱点 |
|---|---|---|
| Snowflake Share（ベンダー提供の共有） | 提供されていて要件を満たすなら最有力 | 柔軟性ゼロ。要件がはみ出すと移行コストが大きい |
| ETL ベンダー（Fivetran） | 速く立ち上げたい・重要度が未確定のソース | 契約コスト。複雑なパイプラインを UI で管理すると変更管理（承認・テスト）が効かない |
| 自作パイプライン | 柔軟性・プライバシー・保守性で最良 | 実装が遅い。SaaS は入れ替わるので毎回自作する価値はない |
- 判断軸: データ区分（顧客データ＝Red data は承認済みの第三者委託先経由でしか処理できない）、スキーマの複雑さ、データ量、業務重要度、鮮度要件、連携手段（DB/API/ファイル）
- 新規ソースは New Data Source Issue テンプレートで調査・検証を終えてから実装をスケジュールする
- セキュリティ: パイプラインごとにソース側・ターゲット側の権限を個別に付与し Vault に保管、Snowflake 認証は key-pair、CI ではシークレットをマスク、サービスアカウントはネットワークポリシーで制限、Snowflake Object Tagging でデータ区分を管理
- 自作パイプラインは YAML 設定・pytest・ブランチ名を開発用の格納先に付けて本番汚染を防ぐ、などの規約付き
示唆: 「全部 trocco」「全部自作」ではなく、ソースごとに3択を決める判断表と、データ区分による経路制限をまず作る。
- 詳細（79ソースの一覧・4層ロール・マスキング・SCIM 連携）: gitlab_データ基盤_saas取り込み戦略と権限設計_整理
2-2. LayerX コーポレートエンジニアリング室 — 人事 SaaS を起点に全社 SaaS を束ねる（国内）¶
- SmartHR の組織・属性情報（所属部署・役職・契約形態・主担当職種の4項目）を起点に、あるべきメンバーを割り出して Entra ID のグループと差分同期する仕組みを内製（擬似的な属性ベースアクセス制御）。Entra ID から SCIM で Google Workspace・Slack・Notion・AWS・1Password 等へユーザー・グループを同期
- ワークフロー自動化に Dify と n8n（Slack の bot・スレッド応答は n8n）
- 会計・人事などコーポレートデータを Snowflake に集約する方針。まず会計データを API 経由・Snowpark で取り込み、事業部に提供するところから開始（2025年末時点）
- ABAC の設定ファイル生成は Claude ベースのエージェントに任せている
- → 「どの SaaS のデータを誰が見てよいか」の権限の源泉を人事 SaaS に一本化している点が要。データ基盤の権限設計もここに乗せられる
- 詳細（ABAC Generator の設計・Terraform 生成・エージェント化の変遷）: layerx_コーポレートエンジニアリング_smarthr起点abacとn8n_整理
- 関連: LayerX 全社 AI 基盤（LiteLLM 予算ゲート等）は layerx_ai_agent基盤_bedrock_litellm_durable_temporal_整理
2-3. Sansan Corporate DataBridge — 正本を持たない連携ハブ（国内・既存ノートより）¶
- 人・組織データの連携ハブ。自らは正本（マスタ）を持たず、各業務 SaaS に SSoT を残して「収集・整形・提供」に徹する
- 利用側に固定エンドポイント（例:
GET /approvers/{employee_id}）を約束し、組織改編や SaaS リプレイスの影響をハブの内側に閉じ込める - → エージェントに SaaS の生 API を直接叩かせるより、安定した業務 API をハブで出す方が、SaaS 入れ替え時に壊れない
- 詳細: sansan_corporate_databridge_情シス内製データ連携基盤_整理
2-4. 国内の ELT 定番構成（Findy Tools「39社のデータ基盤アーキテクチャ特集」より）¶
| 企業 | SaaS ソース | 転送 | DWH |
|---|---|---|---|
| M&Aクラウド | Salesforce（＋MySQL。MySQL→Salesforce の逆方向連携にも利用） | trocco | BigQuery |
| ドクターメイト | kintone | trocco | BigQuery |
| アソビュー | Google Analytics | trocco | BigQuery |
| タイミー | （記載なし） | Fivetran, Embulk | （記載なし） |
| レバレジーズ | 複数の RDB・SaaS | Fivetran | BigQuery |
- 国内は「trocco または Fivetran → BigQuery / Snowflake → dbt」がほぼ定番。取り込み自体はもはや差別化要素ではなく、その先のマート設計と権限設計が本題
- 出典は 2024 年時点の情報。詳細（trocco / Fivetran / Datastream の使い分け、Fivetran の注意点）: 国内データ基盤_saas取り込み定番構成_整理
2-5. Stripe — 社内 MCP「Toolshed」と PoC ツール「Harbor」（ツール層型・海外）¶
Toolshed（社内共通のツール層） - 社内システムと Stripe が使う SaaS 向けに約500の MCP ツールを持つ中央集約型の MCP サーバー - ツールを1つ足すと、数百ある社内エージェント全部がすぐ使えるようになる（共有の能力層） - ただし全部は渡さない。タスクに関係するサブセットだけを要求させる。コーディングエージェント Minions には意図的に小さいサブセットを既定で渡し、個人が「テーマ別ツール群」を追加できる - 破壊的操作は社内のセキュリティ統制フレームワークで禁止。Minions の devbox は QA 環境で動き、本番データ・本番サービス・任意の外部通信にアクセスできない
Harbor（Arca と同じ課題への Stripe の答え） - デザイナー・財務・リスク分析・営業・PdM が使う、ブラウザ内で動く AI プロトタイピングツール。公開 URL でコメント・リミックス可能 - 2026年5月以降、3,000人超が12,000のプロトタイプを作成、社員の25%が1つ以上作成 - ただし社内データ・SaaS への接続は「プロトタイプ単位のデータベース」などが今後の検討事項として書かれているだけで、現状の接続方法は記事に記載なし
示唆: 社内 MCP は「集約は1か所、配布は小さく」。ツールを渡しすぎるとエージェントの精度も安全性も落ちる。
2-6. Shopify — River / Aquifer（ツール層型・海外）¶
- River は社内 Slack に常駐するエージェント。コードを読み、テストを回し、PR を出し、データウェアハウスにクエリし、本番トレースを見る
- 公開チャンネル限定（DM 不可）。全会話が社内に公開された記録になり、それを分析してスキル・プロンプトに還元する
- 直近30日で 59,918 セッション / 5,170 チャンネル / 7,000人超が関与 / River 共著の PR 3,536件。マージされる PR の8本に1本が River 共著。セッション中央値 19分・ツール呼び出し中央値 50回
- 下支えの基盤 Aquifer の構成要素: session / harness / sandbox / gateway / 永続イベントログ（Postgres）/ credentials proxy / observability
- credentials proxy の具体的な仕組み（プレースホルダのトークンを出口で本物に差し替える、等）は二次情報では語られているが、一次資料（公式ブログ）には構成要素として名前が出るだけで詳細は未記載
- 詳細: shopify_river_aquifer_社内エージェント基盤_整理
2-7. エアークローゼット — 3ヶ月で 17 個の社内 MCP（国内・既存ノートより）¶
- TypeScript + Pulumi + Google OAuth の統一構成で社内 MCP サーバーを 17 個構築。5層セキュリティ、退職＝Google Workspace 無効化で全 MCP が自動失効
- ツールの description に「次に呼ぶべきツール・引数」を埋め込む Runbook パターン
- 詳細: エアークローゼット_agentic_graph_rag_と社内mcp基盤_整理、共通化の設計は 社内mcp共通基盤_認証認可ログ_整理
2-8. SaaS 側が MCP を出し始めている（国内ベンダー動向）¶
- freee: 2026-03-02 に MCP サーバー「freee-mcp」を公式 OSS として公開、2026-03-27 にリモート版を提供開始。会計・人事労務・請求書・工数管理・販売など約270本の API を MCP ツール化（公式プレスリリースで確認）
- マネーフォワード クラウド会計: 2025年10月に β、2026年3月にリモート MCP サーバーを全プランで提供開始（公式プレスリリース）
- Slack / Salesforce: 2026-07-16（日本）に Slackbot と Salesforce・Data 360・Tableau をつなぐ MCP サーバー群を発表。更新操作は必ずユーザー認証を求める設計。Slack 公式 MCP サーバーの GA 時期（2026年2月）は二次情報のみで未確認
- 詳細: 国内saas_mcp対応動向_freee_moneyforward_slack_整理
- → 「各 SaaS のコネクタを自作する」必要は減る。一方で各 SaaS の MCP をエージェントに直接つなぐと、認証・認可・監査が SaaS の数だけ散らばる。社内ゲートウェイで束ねるかが次の設計論点
3. 横断比較¶
| 事例 | 型 | 対象 SaaS / データ | 集約点 | 権限・資格情報の扱い | 規模・数値 |
|---|---|---|---|---|---|
| GitLab | ELT | Salesforce, Zendesk, Marketo ほか | Snowflake + dbt | パイプラインごとに個別権限を Vault 保管、データ区分で経路制限 | — |
| LayerX CorpEng | ELT＋自動化 | SmartHR, Entra ID, Slack, Notion, 会計 | Snowflake（Snowpark で取り込み）/ n8n・Dify | 人事 SaaS 起点の ABAC | 管理グループ 161個 |
| Sansan DataBridge | 連携ハブ API | 人事マスタ等 | 内製ハブ（PostgreSQL） | 正本を持たず投影のみ | — |
| M&Aクラウド等 | ELT | Salesforce, kintone, GA | BigQuery | （記載なし） | — |
| Stripe Toolshed | ツール層 | 社内システム＋SaaS | 中央 MCP サーバー | サブセット配布、破壊的操作は統制、QA 環境 | 約500ツール・数百エージェント |
| Shopify Aquifer | ツール層＋DWH | コード・DWH・本番トレース | Aquifer（gateway / credentials proxy） | credentials proxy（詳細未公開） | 59,918 セッション/30日 |
| エアークローゼット | ツール層 | 社内各種 | MCP 17個（統一構成） | Google OAuth・退職で自動失効 | 3ヶ月で17個 |
| メルカリ Arca | PoC 実行基盤 | GitHub, Linear, LiteLLM, GCP | 出口 HTTP プロキシ | キーはプロキシで後付け、マシンごとに SA | 631台・作成者346名 |
4. 当てはめ例 — PoC 環境を社員 PC（WSL 等）に配り、GCP にデータ基盤を置く構成の場合¶
仮定のケーススタディ。集中基盤（Arca 型）ではなく PC 配布型を選んだ場合に、各事例をどう組み合わせるかの一般論。
┌──────── 人事 SaaS（権限の源泉：LayerX 型）────────┐
▼ ▼
【分析系】 SaaS ──trocco/Fivetran──> BigQuery raw ──dbt──> mart ──> PoC 公開ビュー ──┐
├─> WSL 上のエージェント / n8n
【操作系】 SaaS 公式 MCP / API ──> 社内 MCP ゲートウェイ（認証・認可・監査・キー保持）──┘
└ エージェントごとにツールのサブセットだけ公開（Stripe 型）
- 分析系は ELT 型に寄せる。ソースごとに GitLab の3択（共有 / ETL SaaS / 自作）で取り込み方を決め、顧客データなど区分の高いものは経路を限定。PoC には公開用ビューだけ見せる（メルカリ_arca_ai時代の高速プロトタイピング基盤_整理 8-5）
- 操作系は社内 MCP ゲートウェイに集約。SaaS 公式 MCP を個人 PC から直接つながせず、ゲートウェイがキーを持つ（Arca・Aquifer・Cloudflare OS と同じ「資格情報をエージェントに渡さない」）。WSL は出口制御が弱いので、キーを PC に置かないこと自体が最大の防御になる
- 権限の源泉を1つにする。人事 SaaS → IdP のグループ → DWH ロール / MCP 認可、まで同じグループで回す（LayerX の ABAC、エアークローゼットの「退職で全 MCP 失効」）
- SaaS 入れ替えに備えて安定 API を挟む。業務で頻繁に使う問い合わせ（承認者・担当者・顧客の最新状態）は Sansan 型の固定エンドポイントにしておくと、エージェント側のスキルが壊れない
上記は各事例から組み立てた設計例で、未検証。
5. まとめ — 一言で / いつどちらを使うか¶
一言で: 「集計は DWH に集めて見せる、操作はゲートウェイ越しに小さく渡す。どちらもキーと権限の源泉は基盤が握る」。
| 状況 | 推奨 | 参考事例 |
|---|---|---|
| 複数 SaaS を横断して集計・ダッシュボード化したい | ELT 型（trocco/Fivetran → DWH → dbt） | GitLab、M&Aクラウド、LayerX |
| どの取り込み手段にするか迷う | ソースごとに「共有 / ETL SaaS / 自作」の3択を判断表で決める | GitLab |
| エージェントに SaaS を操作させたい | 社内 MCP ゲートウェイに集約し、サブセットだけ渡す | Stripe Toolshed、エアークローゼット |
| エージェントにキーを持たせたくない | 出口プロキシ / credentials proxy でキーを後付け | メルカリ Arca、Shopify Aquifer、Cloudflare OS |
| 誰が何を見られるかを楽に保ちたい | 人事 SaaS → IdP グループを権限の源泉にする | LayerX、エアークローゼット |
| SaaS を入れ替えても壊れないようにしたい | 正本を持たない連携ハブで固定 API を出す | Sansan DataBridge |
参考リンク¶
- GitLab Handbook — Data Pipelines: https://handbook.gitlab.com/handbook/enterprise-data/platform/pipelines/
- GitLab Handbook — Data Team Platform: https://handbook.gitlab.com/handbook/enterprise-data/platform/
- Stripe — Minions Part 2（Toolshed）: https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents-part-2
- Stripe — Harbor: https://stripe.dev/blog/harbor-stripes-ai-assisted-prototyping-tool
- Shopify Engineering — Under the River: https://shopify.engineering/under-the-river
- LayerX — 2025 年のコーポレートエンジニアリング室におけるプラットフォーム的進化を振り返る: https://tech.layerx.co.jp/entry/corporate-engineering-platform-evolution-2025
- LayerX — SmartHR 上の属性情報を元に擬似的な ABAC システムを構築した話: https://tech.layerx.co.jp/entry/psuedo-abac-system-using-smarthr
- Findy Tools — 39社のデータ基盤アーキテクチャ特集: https://findy-tools.io/articles/data-review/28
- レバレジーズ — Fivetran で ELT: https://analytics.leverages.jp/entry/2024/08/20/180000
- Sansan — Corporate DataBridge: https://buildersbox.corp-sansan.com/entry/2026/07/22/130000
- エアークローゼット — Sandbox MCP: https://zenn.dev/aircloset/articles/65efe9614f8e73
- 日本の SaaS 100社の MCP・API 対応状況（2026年4月版）: https://zenn.dev/kanseilink/articles/a316f473d8d506
- マネーフォワード クラウド会計 リモート MCP 全プラン提供（2026-03-26）: https://corp.moneyforward.com/news/release/service/20260326-mf-press-1/
- Salesforce — Slack を AI OS 基盤とする新 MCP サーバー（2026-07-16）: https://www.salesforce.com/jp/news/press-releases/2026/07/16/new-mcp-servers-ai-data-in-slack/
作成: 2026-09-27 ／ 最終更新: 2026-09-27