SAP Datasphere入門｜ビジネスデータファブリックで実現する次世代データ基盤

はじめに：データ基盤に求められる新しい答え

S/4HANAをはじめとするSAPシステムには、企業活動の根幹となるデータが日々蓄積されています。しかしそれを意思決定に活かそうとすると、必ず「データを取り出してどこに集めるか」という問題に突き当たります。従来はBW/4HANAなどのデータウェアハウスに集約するアプローチが主流でしたが、近年はSnowflakeやDatabricks、Google BigQueryなど非SAP系のクラウドDWHを既に導入している企業も増え、SAPと非SAPのデータをどう統合するかが新しい課題になっています。

なぜこの課題が深刻なのか（why so）。データを物理的に1か所にコピーしようとすると、ETL設計・データ重複・コスト増・ガバナンス低下が同時に発生するからです。さらにSAP独自のセマンティクス（販売組織、原価要素、利益センタなど）はテーブルだけ抜き出してもビジネス文脈が失われ、レポート側で再解釈が必要になります。

ではどうすべきか（so what）。SAPデータの「意味」を保ったまま、物理的にコピーせず仮想的に統合するのが現代の答えです。これを実現するためにSAPが提供しているのがSAP Datasphereであり、その中核思想が「ビジネスデータファブリック」です。本記事ではDatasphereの全体像と主要機能、競合との連携、そして導入時の勘所を入門者向けに整理します。

SAP Datasphereの全体像

SAP DatasphereはSAP BTP上で提供されるクラウドネイティブなデータ管理基盤です。前身のSAP Data Warehouse Cloud（DWC）を発展させた製品で、2023年に名称変更とともに「ビジネスデータファブリック」というコンセプトを前面に打ち出しました。SAP BTP全体の位置づけはSAP BTP入門で解説しています。

主要機能は次のとおりです。

なぜこれだけの機能が1製品に収まっているか。データ統合・モデリング・ガバナンス・配信を別ツールでつなぐと、各ツール間でメタデータがバラバラになり、結局「どのデータが正しいか分からない」状態に戻ってしまうからです。Datasphereはこれらを統合メタデータレイヤで一元管理することを設計思想にしています。

ビジネスデータファブリックという考え方

「ビジネスデータファブリック」はSAPのマーケティング用語に見えますが、技術的には明確な意味があります。物理的にデータを1か所にコピーする「データレイク／DWH中心型」とも、各システムを直接つなぐ「ポイント・トゥ・ポイント型」とも違い、ビジネスの意味（セマンティクス）を保持したメタデータレイヤを通じて、物理的な所在を抽象化してアクセスできるようにするアプローチです。

flowchart LR
  subgraph Sources[データソース]
    S4[S/4HANA]
    BW[BW/4HANA]
    SF[SuccessFactors]
    NS[Snowflake/Databricks]
  end
  subgraph Datasphere[SAP Datasphere]
    INT[データ統合層]
    MOD[モデリング層]
    BIZ[ビジネスレイヤ]
  end
  subgraph Consumers[消費側]
    SAC[SAP Analytics Cloud]
    ML[AI/ML]
    BI[他社BI]
  end
  S4 --> INT
  BW --> INT
  SF --> INT
  NS -.仮想接続.-> INT
  INT --> MOD --> BIZ
  BIZ --> SAC
  BIZ --> ML
  BIZ --> BI

ポイントは、SnowflakeやDatabricksとの接続が「データを取り込む」だけでなく「相互に仮想参照する」設計になっていることです。実際SAPはSnowflake・Databricks・Google・Collibraと戦略提携しており、ファブリック構想の中核に組み込まれています。

主要機能を少し掘り下げる

データ統合：レプリケーションとフェデレーション

Datasphereは2種類のデータ取り込み方式を持ちます。レプリケーションは定期的にデータをコピーする方式で、大量データの集計に向きます。フェデレーションは仮想接続で、クエリ実行時に元システムにアクセスする方式です。リアルタイム性が必要・コピーコストを抑えたい場合に使います。

なぜ両方あるか。すべてをフェデレーションにすると元システムの負荷が高まり、すべてをレプリケーションにするとコストとデータ鮮度が問題になるからです。「鮮度・性能・コスト」のバランスで方式を使い分けるのがDatasphere設計の基本になります。

モデリングとビジネスレイヤ

DatasphereのモデリングはBW/4HANAのインフォプロバイダのようにグラフィカルに行えます。さらに「ビジネスレイヤ」では業務用語・KPI・階層を定義でき、技術的なテーブル名ではなく業務担当者が理解できる言葉でデータを公開できます。これにより、レポート開発者と業務担当者の間の翻訳コストが大幅に下がります。

Spaces

Spacesは部門やチームごとに分離された作業領域です。Space単位でユーザー権限・ストレージ枠・接続を管理でき、クロスSpace共有は明示的な公開操作でのみ行えます。これにより「経理データに購買部門が誤ってアクセスする」といった事故を構造的に防げます。

BW/4HANA・SACとの関係

DatasphereはBW/4HANAを「置き換える」製品ではなく「共存する」製品です。BW/4HANA on HANA Cloudのモデルを直接Datasphereに公開したり、Datasphere側で軽量モデリングを行ったうえでBW/4HANAの大規模データに接続したりできます。

一方SAP Analytics Cloud（SAC）はDatasphereの最も自然な可視化フロントエンドです。Datasphereのビジネスレイヤで定義したKPIをSACが直接読み込むことで、ダッシュボードと裏側のモデルが常に一致した状態を保てます。

なぜこの組み合わせが推奨されるか。BIツールは「絵を描く道具」であり、データの意味付けは本来データ層でやるべきだからです。SAC側でロジックを書き始めると、ダッシュボードごとに定義が分岐して「どの数字が正しいか」が分からなくなります。Datasphere＋SACの組み合わせは、その典型的な失敗を防ぐ構成です。

Snowflake／Databricksとの連携

DatasphereはSnowflake・Databricksとの双方向接続を公式サポートしています。すでに非SAPデータを大規模にSnowflakeに集めている企業でも、SAP側のセマンティクス（製品階層・利益センタなど）を保ったまま結合分析が可能になります。

Snowflake側で持っているマーケティングデータと、SAP側で持っている販売・原価データをDatasphere上で結合し、SACで「キャンペーン別の利益貢献」を可視化する、というユースケースは典型的です。なぜわざわざDatasphereを挟むのか。SAPの「製品階層」「販売組織」「会計期間」といった概念を生のテーブルから再構築するのは現実的でなく、Datasphereのビジネスレイヤがそのままセマンティクスのブリッジになるからです。

ユースケース3例

ユースケース1：S/4HANA移行に伴うレポート再構築

ECCからS/4HANAへ移行する企業は、過去BWで作ってきたレポート資産をどう扱うかで悩みます。Datasphereを移行先に選べば、BWの既存モデルを段階的にDatasphereに移しつつ、S/4HANAの新しいCDSビューを取り込み、最終的にSACで統合ダッシュボードに仕上げる、という移行ストーリーが描けます。

ユースケース2：グループ会社データ統合

子会社ごとに別のERPを使っている企業では、グループ連結のたびに手作業でデータを集める苦労がつきものです。Datasphereで各子会社のERP・SaaSを仮想接続し、勘定科目・部門コードのマッピングをビジネスレイヤで定義しておけば、毎月の統合作業が大幅に省力化されます。

ユースケース3：AI/ML向けの特徴量基盤

機械学習プロジェクトでは「学習データの作成」が全体工数の大半を占めます。Datasphereで顧客・商品・取引のセマンティック層を整備しておくと、データサイエンティストはSQLや特徴量定義を再発明する必要がなくなり、モデル開発に集中できます。

導入時に押さえたいポイント

• 最初から全社統合を狙わない。1〜2のユースケース（例：販売分析）で価値を示してから広げる
• Spacesの設計を最初に決める。後から再編すると依存関係の張り直しが発生する
• レプリケーションとフェデレーションの使い分けポリシーを文書化する
• カタログ機能でデータオーナーを必ず登録する。オーナー不在のデータ資産はガバナンス崩壊の温床
• BW/4HANAやSnowflakeなど既存資産は無理に置き換えず、共存設計を前提にする

なぜここまで「最初から全部やらない」を強調するか。データ基盤は規模を広げるほど整合性維持のコストが指数関数的に増えるためです。小さく始めて成功体験を積み重ねるのが、データ基盤プロジェクトを失敗させない最大の鉄則です。

よくある疑問（FAQ）

Q. BW/4HANAはもう不要になりますか？ A. いいえ。BW/4HANAは大規模・複雑な業務モデルに依然として強みがあります。Datasphereはより軽量・俊敏なモデリングと外部データ統合に向いており、両者は補完関係です。

Q. SACはDatasphereとセットで契約する必要がありますか？ A. 必須ではありません。Datasphereのデータは他社BI（Tableau、Power BIなど）からも参照可能です。ただしSACとの組み合わせがメタデータの一貫性という点で最も滑らかです。

Q. オンプレERPとも接続できますか？ A. できます。Cloud Connectorを経由してオンプレSAPに安全接続できるため、ECCユーザーでもDatasphereを試せます。

Q. データ量が大きい場合の性能は？ A. 仮想接続だけに頼ると元システム負荷が問題になります。大規模ファクトはレプリケーション、マスタは仮想接続、といった使い分けが定石です。

Q. SAPライセンスにDatasphereは含まれますか？ A. 含まれません。BTP上の独立サブスクリプションで、容量（Capacity Units）ベースの課金です。

まとめ

• SAP DatasphereはBTP上で提供されるクラウドデータ管理基盤で、BW/4HANAの後継ではなく次世代の統合層
• 「ビジネスデータファブリック」はメタデータを中心にデータの意味を保ったまま物理所在を抽象化する考え方
• レプリケーションとフェデレーションの使い分けが性能・コスト・鮮度のバランスを決める
• Snowflake／DatabricksとはSAP公式提携で双方向連携が可能。SAPセマンティクスを保ったまま結合分析できる
• BW/4HANA・SACとは置換ではなく共存が基本。既存資産を生かしつつ段階導入する
• 導入は小さく始める。Spaces設計とデータオーナー登録を最初にやる

データの統合は、もはや「一か所に集める」発想では追いつきません。意味を保ったまま、必要なときに必要な場所へ届けるファブリックの考え方が、これからのSAPデータ戦略の中心になります。

DatasphereはBTPの「Data and Analytics」柱の中核サービスです。BTP全体の構成やサービス間の関係を把握しておくと、Datasphereの位置づけがよりクリアになります。