統合データ プラットフォームは、一貫したインジェスト、変換、発行の標準に依存するため、リーダーは分析と AI のためにデータを信頼できます。 推薦: OneLake に入るデータ、チームがそのデータを調整する方法、および管理されたデータ製品がコンシューマーに到達する方法を制御する組織全体の標準を確立します (図 1 を参照)。 この推奨事項を適用するには、この記事をチェックリストとして使用します。
1. データ インジェスト標準を設定する
OneLake は、Microsoft Fabric の分析と AI の中心的なデータ レイクとして機能するため、リーダーは入力内容を制御する必要があります。 推薦: 定義されたビジネス成果をサポートするデータのみを取り込むよう、明確な境界を設定します。 この推奨事項を適用するには、次のチェックリストを使用します。
どのようなデータを統合しますか? OneLake でのデータの統合とは、測定可能なビジネス成果に関連付けられたデータ製品をサポートするデータを選択することを意味します。 ベスト プラクティス: データ製品をサポートし、ビジネス価値を追加する場合にのみ、OneLake にデータを取り込みます。 データ インジェストは、技術的な既定値ではなく、製品の決定として扱います。 決定ガイダンス: リーダーが追跡するビジネス プロセスまたは結果を説明または測定するときに、データを取り込みます。アクティブなユース ケースが存在しない場合は、運用システムまたは部門別ストレージにデータを残すことを選択します。 この選択により、ストレージ コストとガバナンスのオーバーヘッドが削減されます。
Microsoft 365 でコラボレーションとナレッジ コンテンツを保持します。 Microsoft 365 データは、Microsoft 365 Copilot エージェントをサポートしています。 これらのエージェントは、既存のアクセス許可を受け入れながら、ドキュメント、電子メール、コラボレーション成果物を取得します。 Microsoft 365 Copilot アーキテクチャを参照してください。 ベスト プラクティス: Microsoft 365 は、コラボレーション、参照、または知識の取得を主な目的とするコンテンツの記録システムとして使用します。 Microsoft 365 導入ガイドを使用して、このデータを準備します。
サポートされているパターンを使用して運用データベースを統合します。 運用データベースは多くの場合、分析と AI のシナリオを提供しますが、直接アクセスするとリスクと不安定さが生じます。 ベスト プラクティス: 仮想アクセスの ショートカット やレプリケートされたアクセスのミラーリングなど、Microsoft Fabric でサポートされているパターン を 使用します。 Azure データベースでは、多くの場合、信頼性の高い統合のためにミラーリングが必要です。 決定ガイダンス: 仮想アクセスがパフォーマンスのニーズを満たす場合は、ショートカットを選択します。 分析のパフォーマンス、分離、またはダウンストリームの再利用で OneLake の物理コピーが必要な場合は、ミラーリングを選択します。
既存のデータ レイクを統合する。 多くの組織では、Azure Data Lake Storage (ADLS)、Google Cloud Storage、Amazon S3 などのデータ レイクを既に運用しています。 ベスト プラクティス: 即時移行を強制するのではなく、既存の湖を統合データ資産の一部として扱います。 ショートカットまたはミラーリングを使用します。 決定ガイダンス: 準備とリスクに基づいて決定します。 重複を回避するには、ショートカットを選択します。 整合性、パフォーマンス、またはコンプライアンスが重複コストを上回る場合は、ミラーリングを選択します。
OneLake で Azure Databricks の出力を表示します。 Azure Databricks では、多くの場合、キュレーションされた分析データが既に生成されています。 ベスト プラクティス: Databricks パイプラインを所定の位置に保持し、OneLake で最終的な Gold 出力を表示します。 決定ガイダンス: レプリケーションを回避し、リモート アクセスがニーズを満たす場合は 、ショートカット を選択します。 ガバナンスまたは消費パターンでローカル データが必要な場合は、 ミラーリング を選択します。
内部データと外部データの取り込みを分離します。 内部分析データと外部接続データには、さまざまな制御が必要です。 ベスト プラクティス: 外部データ製品用に個別のワークスペースまたはレイク領域を作成します。 承認された外部データセットのみをそれらの場所に格納します。 決定ガイダンス: データが内部の決定または外部共有をサポートするかどうかを早期に決定します。 物理的な分離を選択して、偶発的な露出を減らし、セキュリティ ポリシーの適用を簡略化します。
2. データ変換標準を設定する
OneLake へのデータの取得は、最初の手順にすぎません。 実際の価値は、生データを高品質ですぐに使用できるデータ製品に変換することによって生まれます。 リーダーはパイプラインを設計しませんが、断片化を防ぐプラットフォームとアーキテクチャ標準を定義します。 推薦: 変換プラットフォームを標準化し、一貫した絞り込みアーキテクチャを適用します。 この推奨事項を適用するには、次のチェックリストを使用します。
2.1. 適切なデータ プラットフォームを使用する
プラットフォームの選択により、Microsoft および Azure 環境のデータ製品の運用要件が設定されます。 推薦: データ製品ごとに、シンプルさと統合と、特殊なエンジニアリング機能の必要性のバランスを取る。 この推奨事項を適用するには、次のチェックリストを使用します。
Fabric (既定値)。 Fabric は、OneLake で直接動作する統合データ エンジニアリング、分析、および BI エンジンを提供します。これは、組織の統一された管理されたデータ資産として機能します。 ベスト プラクティス: 標準の分析、レポート、およびデータの準備には Fabric を使用します。 アクセス制御、系列、コスト管理を簡素化するために、Dataflows Gen2、Spark、SQL などのネイティブ Fabric エンジンを優先します。 OneLake を単一のストレージ レイヤーとして使用します。 決定ガイダンス: 要件が組み込みの機能に適合し、リーダーシップが統一されたガバナンスと課金を評価する場合は、Fabric を選択します。 運用上のオーバーヘッドが少ない場合と引き換えに、限られたカスタマイズを受け入れます。
Azure Databricks。 多くのユーザーが Azure Databricks を好みます。 大規模な処理と高度な機械学習シナリオがサポートされています。 ベスト プラクティス: 専門知識やスケールが既に存在する Databricks を引き続き使用します。 出力を OneLake に格納するか、OneLake ショートカットを使用して接続する必要があるため、ガバナンス、セキュリティ、検出は一元化されたままになります。 決定ガイダンス: Fabric が現在の要件を満たしていない場合は、Databricks を選択します。 トレードオフとして、より高い統合とスキルのオーバーヘッドを受け入れます。
プラットフォームの所有権の境界を適用します。 プラットフォームの境界を明確にすると、システム間でコストの重複や一貫性のないロジックが防止されます。 ベスト プラクティス: ワークロードの各クラスの責任を 1 つのプラットフォームに割り当てます。 クロスプラットフォーム処理を承認する前にアーキテクチャ レビューが必要です。 決定ガイダンス: インジェスト、変換、分析の結果を所有するプラットフォームを決定します。 同じビジネス結果を提供する重複する変換と重複するパイプラインを防ぎます。
2.2. メダリオン アーキテクチャを適用する
medallion アーキテクチャは、生データからビジネスに対応した出力への明確な進行を定義することで、すべてのデータ製品の信頼、一貫性、ガバナンスを確立します。 推薦: OneLake のすべてのデータ製品をブロンズ、シルバー、ゴールドの構造に従うことを要求し、これらのレイヤーをバイパスするショートカットを禁止します。 この推奨事項を適用するには、次のチェックリストを使用します。
レコードのシステムとしてブロンズ レイヤーを要求する (生のインジェスト): ブロンズ レイヤーは、OneLake に到着したとおりにデータをキャプチャし、元のソースの忠実性を維持します。 ベスト プラクティス: データを追加専用および不変として格納します。 この段階で修正やエンリッチメントを禁止します。 すべてのインバウンドデータセットをまず「ブロンズ」レイヤーに配置する必要があります。 決定ガイダンス: ソース システムからの真理を維持するためにのみブロンズが存在することを決定します。 監査可能性と追跡可能性と引き換えに、より低速な使いやすさを受け入れます。
信頼できるビューとしてシルバー レイヤーを確立します。 シルバー レイヤーには、チームが一貫した分析に依存する検証済み、標準化された、クレンジングされたデータが保持されます。 ベスト プラクティス: データ品質ルール、書式の調整、および基本的なビジネス検証を適用します。 Silver データセットを明確に文書化し、ガバナンス プロセスを通じて変更を管理します。 決定ガイダンス: 権限のあるクレンジング レイヤーとしてシルバーを選択します。 チームが生データを独立して再クリーンアップすることを禁止すると、競合する解釈が作成されます。
Gold (ビジネス コンテキスト、データ製品): ゴールド データセットをビジネス データ製品として認定します。 ゴールド レイヤーは、リーダーが意思決定、パフォーマンス追跡、レポートに使用する管理データ製品を提供します。 ベスト プラクティス: 承認されたビジネス定義とメトリックにゴールド データを配置します。 使用する構造体を最適化します。 すべてのゴールド データセットを Microsoft Purview のデータ製品として所有権、目的、更新の詳細に登録します。 決定ガイダンス: チーム間または意思決定に使用されるデータセットがゴールドで存在する必要があることを決定します。 ガバナンスをバイパスする非管理対象または未認定のデータセットを拒否します。
外部で使用するためにサニタイズされた製品を作成します。 外部共有では、内部運用データから意図的に分離する必要があります。 ベスト プラクティス: 機密フィールドを削除またはマスクし、必要に応じて詳細を減らす精選されたデータセットを生成します。 所有権を割り当て、パブリックや外部の使用など、明確なラベルを適用します。 これらのデータセットを承認済みの場所に格納します。 決定ガイダンス: 外部データセットを独立した製品として扱うことを選択します。 追加のガバナンス手順を受け入れて、法的およびセキュリティ上のリスクを軽減します。
Fabric は、変換を自動的に管理できる 具体化されたレイク ビュー を通じてこのモデルをサポートします。 ファブリックの Medallion Lakehouse アーキテクチャを参照してください。 分析アーキテクチャについては、 Microsoft Fabric を使用したエンドツーエンドの分析に関するページを参照してください。
テーブル。 メダリオンアーキテクチャの例。 Gold レイヤーは、2 つのデータセットのデータを結合します。
| Dataset | レイヤー | データの例 | どうされました |
|---|---|---|---|
| 販売トランザクション | 青銅 | OrderID=984321 ·StoreID=17 ·Amount="1,200" ·TxnDate="2026-01-05T14:32:09Z" | このレコードは、送信されたとおりに販売システムから到着しました。 量は文字列です。 タイムスタンプはシステム形式に従います。 意味は適用されません。 |
| 銀 | OrderID=984321 ·StoreID=17 ·Amount=1200.00 ·TxnDate=2026-01-05 | トランザクションは標準化され、検証されます。 金額は数値です。 日付はエンタープライズ ルールに従います。 データが信頼できるようになりました。 | |
| ストア参照 | 青銅 | StoreID="17" ·RegionName="EAST" | このレコードは、ロケーション システムから到着しました。 書式設定はソースを反映します。 |
| 銀 | StoreID=17 ·Region=East | ストア識別子は売上データと一致します。 リージョンの値はクリーニングされ、一貫性があります。 | |
| リージョン別の日次収益 | 金 | Region=East ·Date=2026-01-05 ·TotalRevenue=425000 | この値は、Silver の販売トランザクションと Silver ストアの参照データを組み合わせた値です。 ビジネス上の質問に回答するために、個々のレコードが集計されます。 |
2.3. アダプティブ ゴールド レイヤーを検討する
アダプティブ ゴールドは、将来を見据える考慮事項としてここに含まれています。 AI エージェントを使用してゴールド レイヤーを作成するという考え方です。 エージェントは、あなたが観察できないパターンを見つけることができます。 ユーザーが "1 か月あたりのリージョン別の顧客の上位の問題" を頻繁に要求する場合、AI エージェントはそのデータセットを具体化できます。 現在、この機能は Microsoft Fabric では提供されていません。 Fabric と Power BI テレメトリを操作するカスタム AI エージェントを構築する必要があります。
3. データ製品の公開基準を設定する
公開標準では、組織が Microsoft Fabric OneLake と Microsoft Purview を通じて信頼できるデータ製品を公開する方法を定義します。 目標は、再利用をスケーリングし、ガバナンスを適用し、分析と AI ワークロード全体のリスクを軽減することです。 推薦: 広範に使用する前に、すべての承認されたデータ製品を、定義された対象ユーザー向けに検出、管理、および明確に意図する単一の公開標準を確立します。 この推奨事項を適用するには、次のチェックリストを使用します。
OneLake カタログを使用してパブリケーションを標準化します。 OneLake Catalog は、Fabric と Databricks などの外部処理プラットフォーム全体のデータ製品に対して統合されたアクセスサーフェイスを提供します。 ベスト プラクティス: 承認されたすべてのデータ製品の既定の実行レイヤーおよび消費レイヤーとして OneLake を使用します。 Microsoft Purview は、ガバナンスとビジネス定義の記録システムとして扱います。 この配置により、Power BI、Fabric データ エージェント、Azure AI Search でデータを一貫して使用しながら、一元的なガバナンスの可視性を実現できます。
検出可能性を確保します。 検出可能性により、意思決定者とコンシューマーは、非公式の知識に頼ることなく、信頼できるデータ製品を見つけることができます。 ベスト プラクティス: 関連する対象ユーザーがアイテムを検出できるように、Fabric ワークスペースの可視性を構成します。 アクセス権は必要ありません。アクセスを要求する機能だけです。 ユーザーがカタログから直接アクセス許可を要求できるように、 Purview アクセス要求ワークフロー を有効にします。 決定ガイダンス: 目標がドメイン間で再利用される場合は、広範な検出可能性を選択します。 規制または機密性の制約が適用される場合は、限定的な検出可能性を選択します。 資産を非表示にするのではなく、可視性とアクセス制御のバランスを取ります。
公開時にメタデータ エンリッチメントを要求する。 メタデータは、リーダーがデータ製品の適合性、信頼、再利用を評価できるようにするコンテキストを提供します。 ベスト プラクティス: 公開時に説明メタデータが必要です。 Fabric のタグを使用して、ビジネス ドメインまたはイニシアティブ別に製品を分類します。 説明で目的とデータスコープが説明されていることを確認します。 この方法では、カタログ検索がサポートされ、再利用の信頼性が向上します。 決定ガイダンス: メタデータ要件を最小限に抑えるか、標準スキーマを適用するかを決定します。 組織が複数のドメインを運用し、一貫性が必要な場合は、標準スキーマを選択します。 成熟期の初期段階では、より軽いアプローチを選択します。
必要に応じて、保証と認定を行います。 保証と認定基準を定義します。 保証は、信頼レベルとガバナンスの成熟度を組織に通知します。 ベストプラクティス: 製品がドメインの推奨であることを示すために「Promoted」を使用してください。 正式なガバナンス レビューに合格した製品を示すには、Certified を使用します。 エグゼクティブ レポートまたは重要な分析をサポートする Gold データセットに認定を適用します。 Fabric 承認ガイダンスについては エンドースメントを参照してください。 決定ガイダンス: 認定が必要な製品を決定します。 エグゼクティブまたは規制に関するワークロードに対する必須の認証を選択します。 速度と実験が優先される場合は、オプションの認定を選択します。 信頼を高めるトレードオフとして、より低速なオンボーディングを受け入れます。
Purview でデータ製品として発行します。 Purview データ製品は、資産を管理された製品ライフサイクルにグループ化する、より高いレベルのビューを提供します。 ベスト プラクティス: 発行されたデータ製品ごとに Purview データ製品エントリを作成します。 製品名、説明、所有者、品質状態、および関連する資産 (テーブル、モデル、レポートなど) を含めます。 統合カタログ内のデータ製品を参照。 決定ガイダンス: Purview データ製品が公開されているすべての資産に必要か、戦略的な製品に対してのみ必要かを決定します。 ポートフォリオの可視性が重要な場合は、フルカバレッジを選択します。 ガバナンス容量が制限されている場合は、選択的カバレッジを選択します。
対象ユーザーと使用者を宣言します。 明確な意図は誤用を防ぎ、分析と AI シナリオ全体のコンプライアンスをサポートします。 ベスト プラクティス: 各データ製品に、対象ユーザーとサポートされているワークロードの種類を示す必要があります。 内部、パートナー、またはパブリックの使用を指定します。 AI、分析、BI、またはパブリック Web シナリオを特定します。 Purview メタデータ、 用語集の用語、 秘密度ラベル を一緒に使用して、この意図を一貫して表現します。 決定ガイダンス: 外部またはエージェントの使用に追加の承認が必要かどうかを決定します。 データが組織の境界を越えたときに、より厳密な承認を選択します。 リスクを軽減するためのトレードオフとして、より低速な公開を受け入れます。