“セキュアだから遅い”を越える。PII基盤にDatabricksを選んだ理由

参考になった

レビュー投稿日の情報になります

株式会社クイック / 德田敦志

チームリーダー / バックエンドエンジニア / 従業員規模: 1,001〜5,000名 / エンジニア組織: 51名〜100名

最終更新日2026/04/22投稿日2026/04/27

利用プラン

利用機能

ツールの利用規模

ツールの利用開始時期

事業形態

Enterprise

Unity Catalog, Auto Loader, Databricks SQL (Serverless), System Tables, IP Access Lists / Private Access Settings

51名〜100名

2025年12月

B to B

B to C

利用プラン	Enterprise
利用機能	Unity Catalog, Auto Loader, Databricks SQL (Serverless), System Tables, IP Access Lists / Private Access Settings
ツールの利用規模	51名〜100名
ツールの利用開始時期	2025年12月
事業形態	B to B B to C

アーキテクチャ

アーキテクチャの意図・工夫

PII（個人情報）を扱うため、インターネットからのアクセスを一切遮断する「Security Standard」を大前提としました。AWS PrivateLink（VPCエンドポイント）やVPC Lattice、NLBを駆使して、Databricksのコントロールプレーンおよびデータプレーンへの通信をプライベートネットワーク内に閉じ込めています。

導入の背景・解決したかった問題

導入背景

当時、私たちが必要としていたのは、単にデータを集めて分析できる基盤ではありませんでした。本当に必要だったのは、PII（個人情報）を含むデータを安全に扱いながら、分析やAI活用を継続的に前へ進められる基盤です。

特に、推薦や予測といったユースケースでは、PIIを適切に扱えることが前提になります。一方で、セキュリティ要件を厳しくするほど、データ活用や検証のスピードが落ちやすいというジレンマがありました。そのため当社では、閉域・監査・権限制御を担保しながら、分析やAI活用の速度を落とさないこと を最重要テーマとして、基盤の検討を進めました。

さらに、PoC用の一時的な環境ではなく、将来的に一部の専門職だけでなく、より多くの利用者が安全にデータを活用できる“民主化”につながる基盤であることも重視していました。

比較検討したサービス

Snowflake、BigQuery

比較した軸

比較検討で重視したのは、単なる分析機能の充実度ではありません。

当社では、PIIを含むデータを前提に、閉域・監査・権限制御を担保しながら、分析やAI活用を継続的に前へ進められるかを最重要の判断軸に置きました。

具体的には、以下の4点を見ていました。

PIIを含むデータを、安全な閉域構成の中で扱えるか
監査ログや権限制御を一元的に管理できるか
データの蓄積・加工・分析だけでなく、その先のAI活用まで分断せずにつなげられるか
高いセキュリティ要件の中でも、PoC止まりにならず実運用できる速度と運用性を持てるか

特に大きかったのは、データの実体を自社のS3に保持したまま、Unity Catalogで権限管理・監査・ガバナンスを一元化できる点でした。

選定理由

PIIを扱う以上、どこにデータを置き、誰が見られて、どこまで追跡できるかは選定の中心になります。その意味で、閉域前提の設計と統制を取りやすいことは、当社にとって非常に重要な判断材料でした。

加えて、Databricksはデータ活用とAI活用が分断しにくい構成を取りやすく、分析基盤として閉じずに、その先の推薦や予測といったユースケースまで見据えられる点も評価しました。

PoC前は、PIIをデータ基盤に載せること自体に不安がありましたが、検証を通じてPIIを扱うデータ基盤を実際に構築し、レコメンデーション機能の検証まで完了できました。

その結果、Databricksは「セキュアだから遅い」「速いけれど統制しづらい」という二択ではなく、守りながら前に進むための現実的な選択肢だと判断しました。

将来的に、一部の専門家だけでなく、より多くの利用者が安全にデータを活用できる“民主化”に向かう土台を作れることも、選定を後押しした理由の一つです。

導入の成果

Databricks導入によって、運用負荷の削減とセキュアな基盤構築という当初課題には一定の解を出せました。一方で、そこに至る過程では、当初本命だった Lakeflow Connect (LFC) から、より運用継続性を重視した構成へ舵を切る判断も必要でした。具体的には、LFC では性能ギャップ（目標1〜2分に対し実測7〜8分）や、プレビュー特有の運用上の脆さに直面しました。

どのような成果が得られたか

単なる基盤構築に留まらず、以下の3点でプラットフォームとしての実利を引き出せました。

目標性能の完遂：
DMSとAuto Loaderのスキーマ進化機能を組み合わせることで、LFCを使わずとも「スキーマ変更への自動追従」と「低遅延なデータ連携」を両立。
強固なガバナンス：
Unity Catalogを初期から組み込み、PII（個人情報）を含む機密データに対する厳格なアクセス統制と利便性を両立。
開発者体験（DevEx）の向上：
ネットワークの複雑さやコスト管理の泥臭い部分をインフラ側で吸収したことで、分析者が環境制約を意識せず、データから価値を出すことだけに集中できる環境を実現しました。

導入時の苦労・悩み

直面した課題	具体的な事象・トラブル
プレビュー機能（LFC）と閉域網の摩擦	PII保護のため厳格な閉域網を構築した結果、PrivateLink認証でブラックボックスなエラーに悩まされました。加えて、MySQLのホストブロックやAuroraのbinlog枯渇による停止など、泥臭いトラブル対応に追われました。
セキュリティとコスト監視のジレンマ	IP制限を厳格化した結果、Databricks管理のジョブクラスター通信まで弾かれ403エラーが連発しました。さらに、サーバーレス環境からはAWSコスト集計APIに到達できず、わざわざ集計専用に従来型クラスターを稼働させる泥臭い運用を強いられています。

導入に向けた社内への説明

上長・チームへの説明

セキュリティの懸念に対して：

「顧客のデータはDatabricks側には保持されず、すべて自社のS3に置いたままUnity Catalogでガバナンスを効かせるため、PII要件をクリアできる」と説明し納得を得ました。

Serverlessのコストブラックボックス化に対して：

インフラコスト（AWS）とソフトウェア利用料（Databricks DBU）が分かれてしまう懸念については、「両者を掛け合わせた独自のコスト監視ダッシュボードを構築し、Slackへ毎日通知する」ことで、PO（プロダクトオーナー）へのコスト説明責任を果たすと約束しました。

活用方法

インフラチームとして、データソース（Aurora等）からDatabricksのUnity Catalog上のRAW層（Bronze層）までのデータインジェスチョンパイプラインを構築・運用し、データエンジニア（DE）チームへ安全な分析環境として提供しています。

また、PO（プロダクトオーナー）への説明責任を果たすため、毎朝Databricksのジョブクラスターを起動してAWSとDatabricks両方のコストを集計し、Slackへ予算消化状況を自動通知するFinOps基盤としても日々活用しています。

よく使う機能

機能	用途・役割
Unity Catalog	メタストア、カタログ、スキーマを通じたS3データの統合的なアクセス制御・監査ログ基盤。
Auto Loader	DMSが出力したS3上のCDCデータを、`schemaEvolutionMode`を用いてスキーマ進化に自動追従しながらDelta Tableへニアリアルタイムに取り込む機能。
Databricks SQL (Serverless)	Photonエンジンによる高速なクエリ実行と、オートストップによるコスト最適化。
IP Access Lists / Private Access Settings	ワークスペースへのアクセスをVPNや社内IPのみに制限するセキュリティ設定。
System Tables (`system.billing`)	Databricksの利用料ログ。これを活用し独自のコスト監視パイプラインを運用。

ツールの良い点

強力なガバナンスと柔軟な解決力：

・Unity Catalogによる強固なガバナンス

・Auto Loaderによるスキーマ自動追従の実現

ツールの課題点

・PII（個人情報）保護のためのプライベートネットワーク要件と、Databricksの通信要件との摩擦解消に多大な工数が発生

・ネットワーク経路の複雑化に伴い、エラー発生時の「どこで止まっているか」の切り分けに高度なインフラ知識が求められる

・サーバーレスによる利便性の裏で、AWSインフラ費用とDatabricks利用料が別々に発生するため、予算管理が複雑化

ツールを検討されている方へ

最新のマネージド機能やプレビュー機能は魅力的ですが、自社の厳格なセキュリティ要件（閉域網など）に組み込んだ途端に牙を剥くことがあります。「機能を使うこと」を目的とせず、事前のPoCでネットワーク制約やエラー時の運用（トイル）を徹底的に検証することをおすすめします。

要件に合わなければ、我々がDMSへ切り替えたように、素早く別の枯れたアーキテクチャへピボットする決断力が、運用を破綻させないための勘所になります。

ネットワークやコストの複雑性は、プラットフォーム側が泥臭く引き受ける。それによって分析者が『お金とパケットの心配』をせずに、データだけに集中できる環境を実現しました。

今後の展望

・PoCから本番環境への移行推進

・FinOpsの強化と予算オーナーシップの適正化

・AI活用による自律的運用への挑戦

株式会社クイック / 德田敦志

チームリーダー / バックエンドエンジニア / 従業員規模: 1,001〜5,000名 / エンジニア組織: 51名〜100名

クラウドインフラを基盤にキャリアを築き、現在はプラットフォームエンジニアリング領域をリードしている。AWS と Databricks を中心に、PII を扱う分析基盤・データプラットフォームの設計に携わり、完全閉域網、PrivateLink、AWS WorkSpaces、アクセス制御などを組み合わせた高セキュリティなアーキテクチャ設計を得意とする。