データレイクとは？

データレイクとは、構造化・非構造化を問わず、あらゆる形式のデータを生（Raw）データのまま格納する中央リポジトリです。リレーショナルデータベースのように事前に定義されたスキーマを必要とせず、IoTのセンサーログやWebサイトのアクセスログといった非構造化データ、JSONやXMLなどの半構造化データ、そして基幹システムの構造化データにいたるまで、すべてのデータを一元的に集約します。

データレイクの定義とデータ基盤（DWH・データマート）との3大相違点

データプラットフォーム設計においては、「データレイク（Lake） → DWH（データウェアハウス） → データマート（Mart）」という段階的なデータパイプラインを構築することが標準的なアプローチとなっています。まずデータレイクにあらゆる生データを集約し、次にDWHでデータクレンジングとスキーマ定義を行って構造化データへと変換し、最終的に特定の業務部門がBIツールなどで即座に利用できるように最適化したデータマートを切り出します。例えば、Webアプリケーションの行動ログを収集する場合、まずは Azure Data Lake Storage などの高スケーラブルなオブジェクトストレージへ生のJSONデータをそのまま格納します。その後、必要な項目のみをETL（変換）処理によって抽出し、SnowflakeやBigQueryといったDWHへロードして、最終的にマーケティング部門が参照する Salesforce Data Cloud や各種BIツール連携用のデータマートへと受け渡します。

この一連のデータパイプラインを適切に制御しない場合、データの不整合や重複が発生するだけでなく、蓄積したはずのペタバイト規模のファイル群がどこに何があるか分からなくなる「データスワンプ（データの泥沼化）」へと陥るリスクが高まります。

データの状態・構造から見る「生データ（Raw Data）」保存の優位性

生データ（Raw Data）をそのまま保存することの最大の優位性は、「スキーマ・オン・リード（Schema-on-Read）」という柔軟なデータ処理方式にあります。従来のDWHで採用されている「スキーマ・オン・ライト（Schema-on-Write）」では、データを保存する段階で厳密なテーブル定義（スキーマ）を適用しなければなりません。しかし、この方式では、将来の分析要件が未確定な状態で不要と判断されたデータ属性が切り捨てられてしまうという問題があります。

データレイクのメリットとデメリットを実務的な視点で評価すると、最大のメリットは「データの可逆性と将来の分析に対する柔軟性の確保」です。生のデータをオリジナルの状態のまま保持しているため、数年後に新しい機械学習アルゴリズムの適用や、当初は想定していなかったKPI（重要業績評価指標）での集計要件が発生した場合でも、過去に遡ってデータを再解析・再処理（リプロセス）することができます。具体的には、テキスト形式のカスタマーサポートログをそのまま残しておくことで、後からLLM（大規模言語モデル）の追加学習（ファインチューニング）用データセットとして加工・再利用することが可能になります。

一方で、デメリットはデータのガバナンスが極めて難しくなる点です。書き込み時の制約がないため、データの発生源や所有者、データの意味を記述したメタデータが適切に管理されない場合、すぐにデータスワンプ化が進行します。このリスクを回避するためには、データレイク構築の初期段階から、Apache AtlasやAWS Glue Data Catalogなどのメタデータ管理システムを導入し、厳格なデータガバナンス体制を敷くことが不可欠です。

データレイク・DWH・データマートの技術要件と用途比較

データレイクとDWHの違い、およびデータマートとの関係性を理解するためには、「データの状態」「目的」「主要ユーザー」という3つの評価軸でそれぞれの設計思想を整理する必要があります。これらは競合するシステムではなく、相互に補完し合うことでデータ基盤全体の信頼性を担保します。

評価軸	データレイク	DWH（データウェアハウス）	データマート
データの状態	生データ（未加工・非構造化・構造化混在）	構造化・クレンジング済みデータ	特定の分析目的に集計・最適化されたデータ
利用目的	未定義（機械学習、将来の探索的分析用）	定義済み（全社的な多角分析、定型レポート）	特定の意思決定・業務（マーケティング、財務等）
主要ユーザー	データサイエンティスト、データエンジニア	ビジネスアナリスト、データアナリスト	業務部門の担当者、一般ビジネスユーザー
スキーマ設計	Schema-on-Read（読み込み時にスキーマを適用）	Schema-on-Write（書き込み時にスキーマを適用）	Schema-on-Write（厳密な多次元モデル等）

データレイクは「安価なストレージクラスを活用してペタバイト規模の生データを永続保持すること」に最適化されています。たとえば、Azure Data Lake Storageでは、階層型名前空間（HNS）の採用により、ファイルおよびディレクトリレベルでの高度なアクセス制御（ACL）を実行しつつ、テラバイトあたり月額数十ドル程度の低コストなオブジェクトストレージと同等のコスト効率を実現しています。

これに対し、DWHは超並列処理（MPP）アーキテクチャやカラムナ（列指向）ストレージ技術を用いて、数億行のデータに対する複雑なSQLクエリを数秒で処理することに特化しているため、コンピュートコストがデータレイクよりも大幅に高価になります。したがって、データ処理のライフサイクルにおいて、すべての初期データを直接DWHに蓄積する構成はインフラコストの急増を招きます。データレイクをファーストレイヤー（一次受領層）として配置し、処理が必要なデータのみをDWHおよびデータマートへと段階的に昇格させる設計が、エンタープライズのシステム運用においてTCO（総所有コスト）を最小化するための基本要件です。

ビジネス価値を最大化するデータレイク導入のメリット・デメリットと判断基準

「すべてのデータをそのままの形で保存する」というデータレイクの技術的特徴は、企業の意思決定スピードとデータ活用の費用対効果に直接的な影響を与えます。構造化データしか扱えない従来のシステム構造とは異なり、データレイクは非構造化データも含めて格納できるため、ビジネス側が「今、どのようなデータが必要か」を定義する前に、先行して全データを蓄積し始めることが可能です。生データ（Raw Data）をそのまま保持する構造は、コスト面、リアルタイム性、そしてガバナンス体制に多大なインパクトをもたらします。

スモールスタートからペタバイト級まで拡張可能なコストパフォーマンス

コスト面での最大の特徴は、格納時にスキーマを定義するスキーマオンライトを採用するDWHに対し、読み込み時にスキーマを適用する「スキーマオンリード」のデータレイクが、データ準備段階の初期コストを大幅に引き下げる点にあります。

クラウド上のオブジェクトストレージ（例：Azure Data Lake Storageなど）をベースに構築されるデータレイクは、DWHに比べてストレージの単価が極めて低く抑えられます。たとえば、1PB（ペタバイト）のデータを蓄積・運用する場合のコストを比較します。DWH専用のストレージやコンピュート一体型の構成では、データの圧縮・インデックス作成などの処理コストやプロプライエタリなストレージライセンス料が上乗せされるため、月額数百万円規模のコストが発生することが一般的です。これに対してAzure Data Lake Storageをベースにしたデータレイク構築では、アクセス頻度の高いホットストレージ層でも1GBあたり月額約2〜3円程度、アクセス頻度の低いアーカイブ層であればさらに10分の1以下の単価で運用可能です。

これにより、PoC（概念実証）フェーズなどのスモールスタート時からペタバイト級のデータ拡張に至るまで、データの爆発的な増加に伴うコスト上昇曲線をなだらかに抑えることができます。格納時に事前の厳密なデータクレンジングやモデル定義が不要であるため、データ準備に費やすデータエンジニアの人件費も削減できます。

リアルタイム分析・機械学習（AI）への親和性とデータ鮮度

データレイクは、スキーマオンリードを前提としているため、IoTセンサーのログやSNSのストリーミングデータ、Webサイトのアクティビティログなどを変換処理（ETL）を挟まずにそのまま流し込むことが可能です。

この特徴は、データの「鮮度」が結果を左右するリアルタイム分析や、大量の非構造化データ（音声、画像、自然言語）を学習ソースとする機械学習・AIモデルの構築において極めて有利に働きます。例えば、顧客の購買行動パターンを検知して瞬時にパーソナライズされた提案を行う場合、数日前のデータをバッチ処理したDWHやデータマートの情報では追いつきません。Salesforce Data Cloudのようなデータプラットフォームとデータレイクをシームレスに連携させることで、日々アップデートされる数百万顧客の行動ログを秒単位で反映させ、機械学習モデルによる精度の高いレコメンデーションに繋げられます。

また、DWHではあらかじめ定義されたテーブル構造に合わないデータは格納時に弾かれるか、スキーマの再設計が必要になります。データレイクであれば、将来的に利用価値が見出されるかもしれない「未知の生データ」もすべて格納できるため、データ分析の幅が狭まりません。

ガバナンス欠如が招くセキュリティリスクと導入可否のチェックリスト

データレイクのメリットとデメリットを評価する上で、避けて通れない最大のデメリットが、データガバナンスの欠如による「データスワンプ（データの泥沼化）」のリスクです。

データの受け入れ口が広く自由度が高い反面、どのデータがどこにあり、誰がアクセス権を持っているのかをメタデータ管理していないと、データレイク内は瞬時にゴミの山と化します。データエンジニアが目的のデータを見つけ出せず、分析すら始められない状況は珍しくありません。また、個人情報（PII）や機密データがチェックなしに生データのままデータレイクへ流出するセキュリティリスクも存在します。ガバナンス体制がない状態でデータレイク構築に乗り出すと、コンプライアンス違反による多額の制裁金やブランド失墜を招きかねません。

自社が「データレイク」「DWH」「データマート」のいずれを優先して構築すべきか、自社の現況と要件から客観的に判断するための「データレイク導入適性判定チェックリスト」を以下に示します。

評価項目	データレイクが適する状況	DWH／データマートが適する	判定の目安
扱うデータの多様性	画像・音声・JSONログなど非構造化データが50%以上	売上データなど構造化されたリレーショナルデータが中心	非構造化データの活用予定があるか
データの鮮度と更新頻度	秒〜分単位のリアルタイムまたは準リアルタイム	日次・週次バッチなどの定期処理で十分	リアルタイムの意思決定やAI連携が必要か
主なデータ利用者	データエンジニア、データサイエンティスト（自身でSQLやPythonを書く）	ビジネスマネージャー、一般社員（BIツールでの定型レポート閲覧）	ユーザーに高度なデータ加工スキルがあるか
データガバナンス体制	データカタログやアクセス制御を実装・維持できる管理体制がある	明確な定義に基づいた静的なデータ管理体制で運用可能	データスワンプ化を防ぐツールや人員を確保できるか
想定するデータ容量	テラバイト〜ペタバイト級（将来的な拡張を見込む）	数百ギガバイト〜数テラバイト程度（あらかじめスコープが限定されている）	拡張性とストレージコストのバランス

データレイクとDWHの違いを理解した上で、自社に高度なデータ分析スキルを持つデータエンジニアやデータサイエンティストが在籍し、大量の非構造化データやリアルタイムデータを扱う必要がある場合は、データレイクの導入を最優先すべきです。逆に、BIツールを用いた既存の営業レポートの可視化が主目的であり、扱うのが構造化データのみであれば、DWHや個別のデータマートを先に整備する方が最短で費用対効果を回収できます。

データの泥沼化「データスワンプ」を回避するデータガバナンス設計

データレイクはあらゆるフォーマットのデータを安価に集約できる一方、適切なデータガバナンスなしに運用を始めると、保管されているデータの意味や所在が誰にも分からなくなる「データスワンプ（データの泥沼）」へと陥ります。データレイク構築を成功させるためには、この泥沼化を未然に防ぐ論理設計と制御プロセスの確立が不可欠です。データレイクのメリットとデメリットを理解した上で、デメリットである「管理の複雑さ」を技術的に解消するアプローチを整理します。

なぜデータスワンプが発生するのか？主な3つの技術的原因

データレイクがデータスワンプ化する背景には、スキーマ（データの構造定義）を書き込み時に定義しない「スキーマ・オン・リード」の特性があります。実務においてデータスワンプを引き起こす主要な技術的原因は、以下の3点に集約されます。

• メタデータの欠如：データソースからオブジェクトストレージへデータを転送する際、データの作成日時、所有者、データの意味を定義した属性情報（メタデータ）が紐付けられないため、第三者がデータを再利用できなくなります。
• 無制限な書き込み権限：各システムのデータ連携パイプラインや開発者が、共通のネーミングルールやディレクトリ構造（プレフィックス）を無視して自由にデータを書き込むため、ストレージ内がブラックボックス化します。
• ライフサイクル管理の不在：一時的な検証データや数年前の不要になったログデータが削除・アーカイブされずに残り続け、ストレージ容量とスキャンコストを圧迫します。

データレイクとDWHの違いを明確に理解していない場合、DWHと同じ感覚で「データを貯めれば誰かが使うだろう」と運用しがちですが、両者はデータ構造の厳格さが根本的に異なります。以下の表は、データレイク、DWH、そして特定の目的に特化したデータマートにおけるガバナンス特性と設計思想の違いをまとめたものです。

管理項目	データレイク	DWH	データマート
スキーマ定義	スキーマ・オン・リード	スキーマ・オン・ライト	スキーマ・オン・ライト
データの主種類	構造化・半構造化・非構造化	構造化データ	集計済みの構造化データ
スワンプ化リスク	極めて高い	低い	ほぼなし
アクセス制御範囲	ファイル・オブジェクト単位	テーブル・カラム単位	ビュー・行・列単位

この違いを放置すると、データレイクにデータを格納しても「どこに何があるか分からず、誰も使えない」という事態を招きます。例えば、月間10テラバイト以上の新規データを蓄積するログ解析基盤において、ネーミングルールとパーティショニング設計（日付やシステム名によるフォルダ分割）を定義せずに構築した結果、1回のクエリ実行によるフルスキャンコストが想定の10倍以上に膨れ上がり、クエリ自体がタイムアウトする失敗パターンが報告されています。このような事態を防ぐため、物理的なストレージ設計の前に論理的なガバナンス設計を実装する必要があります。

メタデータ管理とカタログ化によるデータ検出性の確保

データスワンプ化を防ぐための最も効果的な対策は、メタデータの自動収集とデータカタログによる「データ検出性（Discoverability）」の確保です。データカタログとは、データレイク内にある全てのファイルの位置情報、スキーマ情報、更新頻度などを一元管理する「データの図書館」の役割を果たすシステムです。

データカタログを導入することで、データエンジニアやビジネスマネージャーは、複雑なオブジェクトストレージの階層を直接探索することなく、Web GUI上から必要なデータを即座に検索できるようになります。具体的には、クラウドネイティブなメタデータ管理サービスである「AWS Glue Data Catalog」や「Microsoft Purview」、オープンソースの「Apache Atlas」といった製品を活用して、メタデータ収集を自動化します。

実務におけるデータカタログの運用フローは、データレイクへのデータ書き込み（インジェスト）と同時にトリガーされる自動クローリング（スキーマ検出）から始まります。自動クローラーが新規ファイルを検知すると、ファイル形式（Parquet、JSON、CSVなど）を解析してスキーマ情報を自動抽出し、データカタログのメタデータストアを更新します。データマネジメントの国際標準フレームワーク「DAMA-DMBOK」においても、メタデータ管理はデータガバナンスの中心的領域として定義されており、適切なカタログ化によってデータ発見プロセスにかかる時間を大幅に削減できるという定量的な実証データが示されています。

ロールベースアクセス制御（RBAC）とデータ系統（リネージ）の管理手法

セキュリティと信頼性を担保するためには、「誰がデータにアクセスできるか（RBAC）」と「データがどのように加工されてきたか（データ系統/リネージ）」の2点を厳格に管理する仕組みを論理設計に組み込む必要があります。

ロールベースアクセス制御（RBAC）の実装においては、企業の人事マスターやIDプロバイダ（Microsoft Entra IDなど）と連携し、ユーザーの職務権限（ロール）に基づいた最小特権の原則を適用します。データレイク内の階層を「Raw（生データエリア）」「Clean（クレンジング済みエリア）」「Curated（分析用エリア）」のようにゾーン分けし、一般のデータサイエンティストやビジネスマネージャーには「Curated」への読み取り権限のみを付与し、「Raw」へのアクセスはデータエンジニアや自動システムプロセスのみに制限します。これにより、機密性の高い個人情報（PII）の漏洩を防ぐとともに、ユーザーによるデータの誤削除や上書きといったヒューマンエラーを防止できます。

また、データの信頼性を保証するためには、データがデータレイクからDWH、そしてデータマートへと加工されていく全行程を記録する「データリネージ」の可視化が必要です。これを怠ると、BIツールに表示されている売上数値の算出ロジックが不明確になり、経営層が意思決定にデータを使用できないというビジネスリスクが生じます。

エンタープライズ環境では、マルチクラウドや多様なSaaSとの連携を前提としたデータレイク構築が進んでいます。例えば、「Azure Data Lake Storage（ADLS）」を中央のデータレイクとして機能させつつ、顧客フロントエンドのデータプラットフォームである「Salesforce Data Cloud」とリアルタイムにデータ連携を行うアーキテクチャでは、双方のシステム間をデータがどのように移動し、どのタイミングでデータ変換が行われたかを追跡できなければなりません。この課題に対しては、データビルドツール「dbt」を用いたデータパイプラインのコード化（Analytics Engineering）や、オープンソースの「OpenLineage」を適用することで、データの依存関係マップをDAG（有向非巡回グラフ）として自動生成し、データが加工される履歴を1アクティビティ単位で追跡・可視化する体制を構築します。これにより、上流のデータソースに変更（カラムの追加やデータ型の変更など）が発生した際、下流のどのダッシュボードや分析モデルに影響が及ぶかを瞬時に特定でき、システム障害の発生を未然に防ぐことが可能になります。

クラウド環境におけるデータレイク構築の実践的なアーキテクチャ

Azure Data Lake Storage（ADLS）を核としたモダンデータスタックの設計

クラウド環境でデータスワンプを防ぎ、実用的なデータレイク構築を実現するためには、物理的なストレージ階層とアクセス制御の設計が不可欠です。Azure Data Lake Storage（ADLS Gen2）を中核に据える場合、まず「階層型名前空間（HNS）」を有効化します。HNSを有効にすることで、オブジェクトストレージでありながらファイルシステム同様のディレクトリ構造を定義でき、データのガバナンス管理が容易になります。

データスワンプ化の防止には、ディレクトリ構造を「Raw（生データ領域）」「Cleaned（クレンジング済み領域）」「Curated（分析・サービス提供領域）」の3層に分離するプラクティスを適用します。これにより、未整理のデータが分析環境に混入するリスクを排除します。アクセス制御には、Azure Active Directory（現在のMicrosoft Entra ID）のロールベースのアクセス制御（RBAC）と、POSIX準拠のアクセス制御リスト（ACL）を組み合わせます。

• Raw層（メタデータ付与・読み取り制限）: データエンジニアとデータインジェスト（取り込み）パイプライン（Azure Data Factoryなど）にのみ書き込み権限を付与し、他ユーザーはアクセス禁止。
• Cleaned層（データ変換・匿名化）: 個人情報（PII）のマスキング処理を施したデータを格納。データサイエンティスト向けに読み取り権限（ACL）を付与。
• Curated層（ビジネス利用）: BIツールや業務部門のユーザーが直接参照する領域。Azure Synapse AnalyticsなどのDWHへのロードや、直接クエリを許可。

この3層分離により、データガバナンスを効かせた運用が可能です。例えば、毎秒1万件のトランザクションログを吸い上げるストリーミング処理において、スキーマ定義が崩れた異常値ファイルをRaw層の検疫ディレクトリ（Quarantine）へ自動隔離するパイプラインを構築することで、下流のDWHに不適切なデータが混入するのを防ぎます。

Salesforce Data CloudやSaaS連携による顧客データ（CX）の統合基盤

顧客接点データの統合において、Salesforce Data Cloudとデータレイクのシームレスな双方向連携は、リアルタイムな顧客体験（CX）価値の向上に直結します。Salesforce Data Cloudは、それ自体がデータレイクとしての性質を持ちますが、企業全体の非構造化データを含む統合データレイク（ADLS Gen2など）とゼロコピー（Zero Copy）でデータ連携を行うことで、ETLパイプラインの構築コストとデータ重複のデメリットを抑えることが可能です。

以下は、ADLS Gen2に蓄積された製品利用ログと、Salesforce内の商談・サポート履歴をセキュアに統合する、ハイブリッドデータパイプラインのステップバイステップの手順です。

ステップ	処理フェーズ	適用テクノロジー	処理内容とガバナンス制御
1	ログデータの蓄積	ADLS Gen2 (Raw)	IoT製品から出力される生ログを、マネージドIDを用いてセキュアにADLSへ収集。
2	クレンジングとスキーマ変換	Azure Databricks	PySparkジョブにより、RawデータをParquet形式に変換しCleaned層に保存。データガバナンスに基づき不整合レコードを排除。
3	メタデータ共有とゼロコピー連携	Apache Iceberg / Delta Lake	Salesforce Data Cloudの「BYOLD（Bring Your Own Lakehouse）」機能を使い、ADLS上のParquet/Deltaファイルを物理コピーなしで直接マッピング。
4	顧客データ（ID）の統合	Salesforce Data Cloud	商談情報（CRM）と製品利用ログ（ADLS経由）を、顧客メールアドレスや企業コードをキーに名寄せ（Identity Resolution）して顧客プロファイルを一元化。

このゼロコピー連携により、データレイクにおける「データの物理コピーによる同期遅延」と「ストレージ二重課金」というデメリットを克服できます。Salesforce Data Cloudで統合された顧客プロファイルは、マーケティングオートメーション（Marketing Cloud）やカスタマーサポート（Service Cloud）にリアルタイムでフィードバックされ、能動的なアップセルや解約防止のアクションへ即座に繋げられます。

オブジェクトストレージと分析エンジン（DWH）を組み合わせたハイブリッド連携

エンタープライズのデータ分析基盤では、柔軟なオブジェクトストレージ（データレイク）と、高速なクエリ性能を持つデータウェアハウス（DWH）やデータマートを組み合わせた「ハイブリッド構成」が標準となっています。ここで重要となるのは、データレイクとDWHの違いを正しく理解し、データの特性と用途に応じて適切に役割分担させる設計です。

データレイクは「安価なストレージコストで、あらゆる形式のデータをそのまま保管できる」メリットがありますが、アドホックな集計クエリに対する応答性能はDWHに劣ります。一方、DWHは構造化データの高速集計に優れていますが、スケーラビリティに伴うコンピューティングコストが高価になる傾向があります。さらに、部門固有の分析要件に特化したデータマートを配置することで、業務ユーザーの利便性を最大化します。

この役割分担を物理実装した、ADLS Gen2、Snowflake（DWH）、およびDr.Sum（高速集計エンジン/データマート）を組み合わせたデータフローを以下に示します。

• コールドデータの維持（ADLS Gen2）: 過去数年分に及ぶ数億レコードの履歴データ、および画像や音声などの非構造化データは、データレイクにParquet形式で低コストで長期保管します。
• ホットデータの高速分析（Snowflake / DWH）: 直近1年分の構造化データ、KPI算出に必要な集計対象データは、Snowflakeにロード。仮想ウェアハウスのコンピュート資源を活用して大規模な多次元分析を実行します。
• 現場向けリアルタイムレポーティング（Dr.Sum / データマート）: 営業部門や現場の店舗スタッフが、Excelや専用BIから数秒で数百万件のデータをインタラクティブにドリルダウンできるよう、Snowflakeで集計した特定の集計済みデータをDr.Sumに差分同期し、インメモリ高速データマートとして提供します。

このようなハイブリッド構造にすることで、月間のクラウドインフラ費用を大幅に削減しつつ、レポート描画時間をミリ秒単位にまで短縮可能です。データの鮮度やユースケースの緊急度に合わせて、格納先を使い分けることが、持続可能なデータレイク構築の要諦となります。

自社に最適なデータレイクを導入・運用するためのアクションプラン

現状の保有データアセットと課題の棚卸しフロー

データレイク構築の初期フェーズにおいて、多くの企業が直面するのがデータスワンプ化の課題です。データレイクは、DWHやデータマートとは異なり、未加工のローデータをそのまま保持できる点が最大の特徴です。しかし、事前の計画なしにあらゆるデータを流し込むと、どこにどのようなデータが存在するのかが不透明になり、活用不能なデータの墓場と化してしまいます。これを防ぐためには、自社が保有するデータアセットと課題を正確に把握する棚卸しが必須です。具体的には、以下の5つのプロセスに沿って棚卸しを実行します。

• 1. データソースの網羅的な特定とカタログ化
  社内に点在するオンプレミスのファイルサーバ、ERPやCRMなどの基幹システム（RDB）、Webサイトやアプリケーションから出力されるアクセスログなど、全てのデータソースを洗い出します。「データレイクとDWHの違い」の一つとして、データレイクは画像、音声、PDFといった非構造化データも格納できるため、これまで統合対象から外れていたファイル群もここでリストアップします。
• 2. データフォーマットおよび更新頻度の可視化
  収集対象となるデータの形式（CSV、JSON、Parquet、PDF、バイナリ等）と、データが更新されるタイミング（日次バッチ、ニアリアルタイム、リアルタイムストリーミング）を明確にします。例えば、秒間数万件のストリーミングログを処理する必要があるシステムと、月次で更新される販売実績データとでは、インフラ設計（Azure Data Lake Storageの選定やSalesforce Data Cloudの活用など）が大きく異なるためです。
• 3. データ品質とデータガバナンス of 現状評価
  データソース内の重複、データの欠損（ヌル値）、個人情報（PII）の有無を確認します。「データレイク導入におけるメリット・デメリット」として、大容量データを一元管理できるメリットの裏には、適切なアクセス制限や暗号化を行わなければセキュリティ事故に直結するというデメリットが存在します。そのため、データのガバナンス状態を初期段階で評価します。
• 4. ビジネス利用シナリオおよびアクセス権限の整理
  「どのデータを、誰が、何の目的で利用するのか」を明確にします。BIツールによる分析レポート作成であれば加工済みのデータマートやDWHの領域ですが、AIの学習モデルや予測分析に用いる場合は、加工前の生のローデータへアクセスする必要があります。職種や役割に応じた詳細なアクセス権限（認可制御）の要件を整理します。
• 5. データライフサイクルと統合フローの図式化
  データの発生源から、データレイク、DWH、そして最終的な分析層にいたる一連のライフサイクルとデータ連携経路を可視化します。これにより、データパイプラインのボトルネック（ETL処理の遅延など）が発生している箇所を特定し、データレイクをどの配置（ハブ）として組み込むべきかを定義します。

開発ベンダーや構築パートナーを選定するための要件定義シート

現状の棚卸しを終えたら、次は開発ベンダーや構築パートナーへのRFP（提案依頼書）に盛り込む技術的な要件定義を作成します。データレイクの構築においては、単にファイルを格納する領域を確保するだけでなく、将来のデータ拡張やセキュリティ、そして他システムとの円滑な接続性を保証しなければなりません。

特に、月間数千万件のトランザクションを処理するECプラットフォームや、全社横断の顧客データ基盤（CDP）を構築するプロジェクトでは、データの取り込み速度とスケーラビリティが運用の成否を分けます。ベンダー選定のミスマッチを防ぐため、以下の4つの重要項目を定義した要件定義チェックシートを活用してください。

要件区分	必須要件定義項目	ベンダー評価基準	重要度
スケーラビリティ	・データ量の増加に自動対応できるペタバイト規模の拡張性 ・クエリ処理を行うコンピュートリソースとストレージ容量が独立して拡張可能なこと	・Azure Data Lake Storageや主要パブリッククラウドにおける、サーバーレス型ストレージの設計実績があるか ・データ増加に伴うクエリ速度劣化を防ぐチューニング手法（パーティショニング等）を提示できるか	高
セキュリティとデータガバナンス	・転送中および保管中データの暗号化 ・メタデータ管理システムとの連携による、データレイク内の格納データの自動カタログ化とデータガバナンスの維持	・Apache Ranger、Microsoft Purview等を用いたセキュリティおよびカタログ製品の実装スキルがあるか ・行レベル、列レベルでのきめ細かなアクセス制限設定の実績があるか	極めて高
既存システムとの連携性	・既存のDWHやデータマートとの間で、タイムラグなく双方向にデータ連携可能なコネクタ群の提供 ・SaaS等、異種データソースからのノンプログラミングまたは容易な接続性	・Salesforce Data Cloud等の主要な顧客・業務SaaSとのコネクタ接続、ETL/ELTデータパイプラインの構築実績があるか ・APIを用いた自社開発システムとのスムーズなデータ連携設計ができるか	高
運用監視とメタデータ管理	・データ取り込み時のファイル破損や処理エラーの自動検知とアラート通知 ・データの中身や品質を担保するための、メタデータ定義およびスキーマドリフト（スキーマ変動）への自動対応	・DatadogやAzure Monitorなどを活用したデータパイプラインの死活監視・性能監視環境の構築実績があるか ・運用開始後に現場で「データスワンプ」化させない運用保守ドキュメント・教育プランがあるか	中

このチェックシートをRFPに反映させることで、自社の業務に適合した最適なパートナーを客観的に選定することが可能になり、データレイク構築後の運用フェーズにおける破綻リスクを最小限に抑えられます。

よくある質問（FAQ）