SAP BWとは？保守期限・Datasphere／BDCへの移行ルートを解説

SAP BW（Business Warehouse）は、SAPシステムや外部システムのデータを統合し、分析・レポーティングのためのデータウェアハウス基盤を提供するSAPの製品群です。
1998年にリリースされた古典的BWから、HANA専用に再設計されたSAP BW/4HANAを経て、いまは「SAP Business Data Cloud」というクラウド統合プラットフォームの中で再定義され直している段階にあります。

BW 7.5のメインストリーム保守は2027年末で終了し、延長保守を取っても2030年が事実上のリミットです。一方でBW/4HANAは2040年まで保守が延長されており、選択肢は「継続」「Datasphere/BDCへの段階移行」「フル再構築」の三択に整理されつつあります。

本記事では、SAP BWの基本構造・保守期限・Datasphereとの違い・SAP Business Data Cloudによる最新化・移行ルートの判断軸・料金・公式事例を、2026年6月時点で体系的に解説します。

SAP BWとは？SAPデータ基盤の中核として担ってきた役割

SAP BW（Business Warehouse）は、SAPシステムや外部システムのデータを統合し、分析・レポーティングのためのデータウェアハウス基盤を提供するSAP製品群です。

1998年にリリースされた古典的BWは、長年にわたりSAPユーザー企業のデータ分析・経営レポーティングの中核を担ってきました。

2012年にSAP HANA上で動作する「SAP BW powered by SAP HANA（通称 BW on HANA）」が提供開始され、2016年にはHANA専用設計の次世代版であるSAP BW/4HANAとして全面刷新されています（年表はSAP Learningに準拠）。

現行のメインバージョンはSAP BW/4HANA 2023で、ハイブリッド構成のサポート強化、データ匿名化機能の拡張、データストアオブジェクトの再モデリング機能の改善などが2023年版で追加されました。BW/4HANAは2040年までの長期保守が確約されており、長期運用を前提に設計されています。

一方で、SAPはクラウド時代のデータ統合基盤としてSAP Datasphereと、それを含む**SAP Business Data Cloud（BDC）**を戦略製品に位置づけ、既存BWからの段階移行ツールを矢継ぎ早に投入しています。BWはもはや単独製品ではなく、SAPデータ基盤エコシステム全体の中でどう位置づけるかを問われるフェーズに入っています。

SAP 2027年問題に伴うS/4HANA Cloudへの移行を検討する企業にとっては、データ分析基盤をBW/4HANAで継続するかDatasphere／BDCへ移行するかを、ERP移行と同じテーブルで判断する必要があります。

---

SAP BW/4HANAの基本機能とアーキテクチャ

SAP BW/4HANAは、データ統合（ETL/ELT）からモデリング、レポーティング、計画策定、データライフサイクル管理までを一気通貫で扱う統合データウェアハウス基盤です。

本セクションでは、実務で押さえておくべき機能をブロック単位で整理します。

データ統合（ETL/ELT）

BW/4HANAは、SAP系・非SAP系を含む多様なデータソースからデータを統合できます。

BW/4HANAが標準で直接扱えるソースは、SAP Learningの整理に従うと次の4種類が中心です。

• SAP source system（ODP）: S/4HANA・ECC・SuccessFactors・Ariba・ConcurなどのSAPシステムからODP（Operational Data Provisioning）で接続
• SAP HANA source system: 同居または別建てのSAP HANAテナント上のテーブル・ビューを直接取り込む
• File source system: CSVなどのフラットファイルをサーバー上から取り込む
• Big Data source system: Apache Spark／Hadoop連携を経由した大規模データ取り込み

Oracle・SQL Server・MySQL・PostgreSQLなどの非SAPデータベース、SnowflakeやAWS S3・Azure Blob Storageといった外部クラウドサービスについては、BW/4HANAから直接フルマネージドに接続するというより、SAP HANAの SDI（Smart Data Integration）・SDA（Smart Data Access）アダプタ経由で取り込むか、SAP Datasphere／SAP Business Data Cloud側でデータプロダクト化してから連携する形が現実的です。

「すべての外部ソースをBW/4HANAが標準サポートする」と書くと、実装段階で前提が崩れます。

データ統合方式には次の3つがあります。

• バッチロード
  夜間・週次など定期的にデータを抽出・変換・ロードする伝統的方式。大量データを一括処理するシーンに適しています。
  
  

• リアルタイムレプリケーション（SDI: Smart Data Integration）
  データ変更をリアルタイムにBW側へ反映する方式。在庫・需給管理など即時性が求められる用途に向きます。
  
  

• データ仮想化（SDA: Smart Data Access）
  データを物理的に移動せず、リモートテーブルとして参照する方式。データレイクや外部DWHを「動かさずに統合」できるため、データ移動コストを抑えられます。

データモデリング

BW/4HANAでは、次のオブジェクトを使ってデータモデルを構築します。

• aDSO（Advanced Data Store Object）
  データ格納の中核オブジェクトです。従来のDSO・PSAの役割を統合し、リアルタイムデータアクセスと更新を1つのオブジェクトで処理できます。
  
  

• InfoObject（マスタデータ・特性）
  顧客・製品・組織などのディメンション定義を行い、組織階層・製品カテゴリ階層といった階層構造を管理します。
  
  

• CompositeProvider
  複数のaDSOやInfoObjectを仮想的に結合し、クエリ実行時にデータを統合します。UNION・JOINを物理データ移動なしに実行できる抽象化レイヤーです。
  
  

• Open ODS View
  外部データソースを仮想的にBWオブジェクトとして扱う仕組みです。データ移動なしでクエリ可能なため、外部DWHやデータレイクをBWの分析対象に組み込めます。

従来BWでは10種類前後あったモデリングオブジェクトが、BW/4HANAではこの4つに統合されています。これにより、データ構造のシンプル化と開発・保守工数の削減が実現されています。

レポーティング・分析

BW/4HANAで作成したデータモデルは、複数の経路で分析できます。

• BW Query Designer（Eclipse BW Modeling Tools）
  BW/4HANA標準のクエリ設計ツール。ディメンション・メジャーを組み合わせた多次元分析を設計します。従来のBEx Query DesignerはBW/4HANAではサポートされていないため、Eclipseベースのモデリングツールに置き換わっています。
  
  

• SAP Analysis for Office
  Excel上でBWデータを多次元分析できるツール。ピボットテーブル感覚で操作でき、既存のExcel運用に馴染ませやすい設計です。
  
  

• SAP Analytics Cloud（SAC）
  クラウドベースのビジュアル分析・ダッシュボードツール。BW/4HANAとネイティブ連携し、近年はSAP Jouleによる自然言語分析が組み込まれています。
  
  

• 外部BIツール（Tableau・Power BI等）
  OData・ODBCなどの標準プロトコルで接続できます。既存の非SAP BI資産を活かしたい企業の選択肢です。

Planning（統合計画）

予算策定・需要計画などのPlanning機能は、**SAP BPC for BW/4HANA（embedded configuration）**として提供されます。BPC embeddedはBW/4HANAのインフラ上で動作し、ボトムアップ予算入力・トップダウン調整・シナリオ分析・ワークフロー承認といった機能を備えています。

BW/4HANA単体にはPlanning機能は含まれていないため、計画系を本格運用するにはBPC embeddedの追加ライセンスが必要です。

データライフサイクル管理

大量データを長期運用するための機能も標準で提供されています。

• データエイジング（Data Aging）
  古いデータをニアライン・ストレージへ移動し、メインメモリ上のデータ量を抑えてパフォーマンスを維持します。
  
  

• データアーカイブ
  不要データを削除またはアーカイブし、ストレージ消費を抑えます。
  
  

• パーティショニング
  大規模テーブルを分割し、クエリパフォーマンスとメンテナンス効率を最適化します。

これらの機能群は、BWを「単発のBI基盤」ではなく「10年〜20年単位で運用する全社データウェアハウス」として設計するための土台です。BDC時代になっても、構造化データを多段モデリングする中心としてのBW/4HANAの役割は当面残ると見るのが現実的です。

---

SAP BWの保守期限スケジュール

SAP BWを取り巻く最大の意思決定要因は保守期限です。「いつまで使えるのか」「何年後にどうなるのか」を本セクションで一気に整理します。

主要バージョンの保守期限

以下の表で、現役の主要バージョンと保守期限を整理しました。

バージョン	メインストリーム保守終了	延長保守
SAP BW 7.5（NetWeaver BW）	2027年12月31日	2030年12月31日まで（+2%の保守プレミアム）
SAP BW/4HANA 2021	2027年12月31日	アップグレード推奨
SAP BW/4HANA 2023	2030年12月31日	SAP Business Suite／S/4HANAと整合し2040年までの長期延長対象

注目すべきは、BW 7.5とBW/4HANA 2021が同じ2027年末でメインストリーム保守が切れる点です。SAPは2016年以降、機能投資をBW/4HANAに集中させており、BW 7.5は事実上「保守だけ提供される凍結プロダクト」になっています。

延長保守は通常の保守費に2%を上乗せする契約形態で、無償ではない点に注意が必要です。延長を選んだとしても2030年が事実上の決断期限であり、BW 7.5を運用している企業はそれまでに何らかの移行先を確定させなければなりません。

参考:

• SAPコミュニティの保守戦略アナウンス
• IBSolutionの解説

2040年保守延長の意味

BW/4HANAは2020年のSAP公式アナウンスで、SAP Business Suite／S/4HANAと整合する形で2040年までの保守延長が確約されました。これは「BW/4HANAをすぐに捨ててDatasphere／BDCに移れ」というメッセージではなく、既存資産を長期運用する道もきちんと残されているという意思表示です。

ただしBARCの分析が指摘するように、SAPの新機能投資はBDC側に明確にシフトしています。2040年の保守は「長く使える」ことを保証しますが、「新しい機能が同じ速度で追加される」ことは保証しません。AI連携・データレイクハウス統合・Joule活用といった2025〜2026年の主要イノベーションは、BDC側に集中して投入されている状況です。

いま動かないリスク

保守期限が先だからといって意思決定を先送りすると、3つのリスクが累積します。

1. 2027年末でBW 7.5のメインストリーム保守が終了する。延長保守（既存保守ベース+2%）を契約しない場合、セキュリティ修正・互換性アップデートも止まる。契約しても2030年末で完全に切れる
2. SAPパートナー・社内技術者のBWスキルが急速に枯渇する。新規案件がBDC寄りに移るほど、BW運用人材は希少化する
3. BDC側の新機能（Data Product Generator・BDC Connect・Joule統合等）が前提とする運用モデルから取り残される。後から追いつく改修コストは年々大きくなる

BW 7.5を使い続けている企業は、まず2027年末を「BW/4HANA 2023へのアップグレード」or「Datasphere／BDCへの段階移行」のどちらかを確定させる期限として、社内で合意形成を始めるのが現実的です。

---

SAP DatasphereとBW/4HANAの役割の違い

SAP Datasphereは、BW/4HANAと並ぶSAPのデータ統合基盤です。両者は競合製品ではなく、設計思想と適用領域が明確に異なるため、まず役割の違いを整理しておきます。

比較表で見るBW/4HANAとDatasphere

SAPパートナーであるグランバレイ社の整理も参考にしつつ、両者の違いを次の表にまとめました。

観点	SAP BW/4HANA	SAP Datasphere
提供形態	オンプレミス／IaaS（顧客管理）	SaaS（フルマネージド）
アーキテクチャ	物理的なデータ集約（ETL中心）	データファブリック（仮想化中心）
主な用途	大規模データウェアハウス・複雑な構造化データのモデリング	SAP/非SAPデータ統合・データオーケストレーション
インフラ管理	顧客またはパートナーが担当	SAPが管理（自動アップデート）
拡張可能なエコシステム	SAC・外部BI・BPC embedded	Databricks／Snowflake／Google BigQuery／Microsoft Fabric等とBDC Connectで連携
SAP公式の標準推奨度	既存資産の継続運用	新規構築・クラウド移行の推奨ソリューション

この比較から見えるのは、**BW/4HANAは「構造化データの金庫」、Datasphereは「全データを束ねるハブ」**という役割分担です。両者は競合関係というよりも、適用領域が異なる役割分担と捉えるのが実態に近い見方です。

アーキテクチャ思想の違い

BW/4HANAは、データを物理的にBW側に集約して構造化する設計です。ETL（Extract / Transform / Load）を前提とし、複雑な変換ロジックや業界固有の集計ルールを精密に表現できる強みがあります。

Datasphereは、SAPが提唱する「Business Data Fabric」の中核として、データを物理的に動かさず仮想的に統合します。必要なときだけレプリケーションやキャッシュを行い、SaaS・外部ベンダー・非構造化データを含む現代的なデータランドスケープを横断的に扱えます。

つまりBW/4HANAは「精密だが重い」設計、Datasphereは「軽量で柔軟」な設計です。どちらが優れているかではなく、扱うデータの種類と運用モデルによって選ぶ製品が変わります。

並行運用（ハイブリッド構成）という現実解

既存BW資産をいきなり捨てる必要はありません。SAPパートナーの提案でも多いのが、BW/4HANAは既存の構造化データ分析を担い、Datasphereは新規の非SAPデータ統合を担うという並行運用です。両者はSAP BW bridgeで接続でき、既存BWのデータモデル・ロジックを再利用しながら段階的にDatasphere側へ重心を移せます。

「全面移行か、現状維持か」の二択ではなく、ハイブリッド構成こそが最も現実的な第一歩である企業が大半というのが、AI総合研究所の支援現場でも繰り返し出てくる結論です。

---

SAP Business Data Cloud（BDC）によるBWのモダン化

2025年2月13日、SAPはデータ＆アナリティクス領域のポートフォリオを「SAP Business Data Cloud（BDC）」として再構築すると公式発表しました。BDCはDatasphere・SAP Analytics Cloud・データプロダクト・Intelligent Applications・SAP Databricksなどを統合的に提供する、SAPの新しいデータ基盤戦略の中核です。

BWユーザー企業にとってBDCがなぜ重要かといえば、SAPがBW資産をBDC上の「データプロダクト」として再利用するための公式ルートを整え始めているからです。本セクションでは、BDC関連の主要動向を整理します。

BDCの位置づけ——「最新化の道筋」としてのBDC

SAP公式のBW移行ページでは、BDCを「数十年にわたるSAP BWオブジェクトを、ビジネスデータファブリックに関連付けられた意味的に豊富なデータプロダクトに変換する」ためのプラットフォームと位置づけています。つまり、BWを単に「移行先に置き換える」ではなく、BW資産をデータプロダクトとして再利用しながら新しい基盤に育て直すというメッセージです。

旧来の「BW → Datasphere移行」が「データの引っ越し」だとすれば、「BW → BDC最新化」は「BW資産をAI・データプロダクト時代に適応させるアップグレード」と捉えるのが近い理解です。

Data Product GeneratorとStudio

BDCの中で、BW資産の移行を支える中心ツールがBW Data Product Generatorです。2025年初から提供されており、既存BWのInfoObject・InfoCube・ADSO・MultiProvider・CompositeProvider・Queryといったオブジェクトを、BDC環境のデータプロダクトに変換できます。

これに加えて、2026年上半期にGA予定なのがData Product Studioです。BDC上でデータプロダクトをビジュアル／SQLで作成・モデリング・管理する統合ワークスペースで、SAPと非SAPデータを混在させながらガバナンス付きの再利用可能な資産として扱えるようになります。

BW Data Product Generatorで既存資産を変換し、Data Product Studioで新規モデルを設計するという二段構えで、BWから一気に作り直す代わりに既存資産を保護しながら新しい基盤へ移れる経路が用意されているわけです。

BDC Connectが広げる外部連携

BDCのもう一つの中心が、外部データプラットフォームとのゼロコピー双方向データ共有です。データを物理的にコピーすることなく、メタデータ・スキーマ・セマンティクスを保ったまま外部基盤と双方向にデータを共有できます。

連携先	BDC Connect提供時期	用途
BDC Connect for Databricks	GA（AWS／GCP／Azure）	外部Databricks環境とBDCのゼロコピー双方向共有
BDC Connect for Snowflake	2026年上半期予定※	外部Snowflake環境との双方向共有（SAP Snowflakeとは別概念）
BDC Connect for Google BigQuery	2026年上半期予定※	外部BigQuery環境との連携
BDC Connect for Microsoft Fabric	2026年Q3予定※	外部Microsoft Fabric環境との連携

※印はSAPの公式ロードマップ資料に基づく見通しで、いずれも変更可能性のある「予定」です。実プロジェクトのスケジュールに直結する場合は、必ず最新のSAPロードマップ・パートナー経由の公表情報で時期を確認してください。

ここで混同しやすいのが、「SAP Databricks」と「BDC Connect for Databricks」は別物だという点です。前者はBDC内に組み込まれたfirst-party のデータサービスで、BDC Capacity Unitsで支払うフルマネージド形態。後者は顧客が外部に保有しているDatabricks環境とBDCをゼロコピーでつなぐコネクタです。「自社にすでにDatabricksを持っているか」「これからBDC側で動かすか」で選ぶレイヤーが変わるため、社内検討時には混ぜずに整理してください。

2025年11月のSAP TechEd BerlinでSAP SnowflakeとBDC Connect for Snowflakeが発表され、Snowflake側からも公式ブログで連携が公表されています。BDC Connect系はすべてゼロコピー双方向を前提としているため、データの所在地を変えずに「BDC＋外部レイクハウス」の組み合わせで分析・AI基盤を構築できます。

特にMicrosoft Fabricとの連携は、Azure・M365を既に標準採用している日本企業にとって、BWからの移行ルートとして現実味の高い選択肢になります。

Joule AgentsとSAP HANA Cloudの強化

BDCは単なるデータ統合基盤ではなく、SAPのAIアシスタントJouleを中心としたエージェント基盤としても設計されています。2025年11月のTechEdでは、SAP HANA Cloudに対するKnowledge Graph・MCP（Model Context Protocol）・Tabular AIの各機能拡張が発表されました。

• Knowledge Graph
  SAP HANA Cloudのメタデータから自動でナレッジグラフを生成し、Joule Agentsの推論精度を高める基盤
  
  

• MCP対応
  Joule AgentsがSAP HANA Cloudのマルチモデル（構造化・空間・グラフ・ベクトル）データに統一的にアクセス可能
  
  

• Tabular AI（SAP-RPT-1）
  SAP AI Coreと統合された予測・異常検知用基盤モデル。SAP HANA Cloud上の業務データに対してSQLからAIワークロードを実行できる

BWで蓄積してきた基幹データは、こうしたAI機能のグラウンディング元として直接活用できる射程に入ります。**BWの未来像は、もはや「より速いDWH」ではなく、「AIエージェントが基幹データに対して正しく推論するためのコンテキスト供給源」**にシフトしているのが実態です。

---

BW利用企業が選ぶべき移行ルートの判断軸

ここまで整理した「保守期限・Datasphere・BDC」を踏まえて、本セクションではBW利用企業が実際にどのルートを選ぶかの判断軸を整理します。AI総合研究所の支援現場で繰り返し見てきたパターンを元に、ケース別の推奨を示します。

3つの主要ルート

BW利用企業が選び得る現実的なルートは、おおむね次の3つに集約されます。

ルート	概要	向いている企業
①BW/4HANA継続運用	既存BW/4HANA環境を2040年保守の範囲で運用継続	大規模・複雑なBW環境、オンプレ／IaaS継続前提、移行投資余力が小さい企業
②BW Bridge経由のDatasphere／BDC段階移行	BW Bridgeでメタデータ・データを移しながら徐々にBDC側へ重心移行	BW資産を保護しつつクラウド移行を進めたい、ハイブリッド運用を許容できる企業
③フル再構築（BDCネイティブ）	BDC上でゼロから再設計、Data Product Studioで新モデル構築	BW環境が小〜中規模、クラウド戦略を全面採用、AI・非SAPデータ統合を最優先する企業

この3択は排他的ではなく、データ領域ごとに②と③を組み合わせる例も多くあります。重要なのは、「いつ」「どのデータ領域から」始めるかを、自社のBW環境の特性に合わせて決めることです。

①継続運用が向くケース

BW/4HANA継続が合理的なのは、以下の条件に当てはまる企業です。

• BW/4HANAで複雑な配賦ロジック・業界固有計算ルールを大量に実装している
• 全社で数百〜数千のレポート・データモデルが稼働しており、移行プロジェクトの工数見積もりだけで億単位になる
• 当面はオンプレ／IaaS運用を継続する経営方針が確定している
• BW運用人材を社内またはパートナー側で確保できている

このケースでは、まずBW/4HANA 2023へのアップグレードを最優先で済ませてください。BW/4HANA 2021以前を使っている場合、2027年末でメインストリーム保守が切れます。2023版に上げれば2030年末（さらに延長で2040年まで）保守が継続するため、Datasphere／BDCへの移行を判断するための時間的余裕を作れます。

②BW Bridge経由の段階移行が向くケース

BW Bridgeは、Datasphere上でBWランタイムを動作させるアドオン機能です。既存BWのオブジェクトをDatasphere／BDCへ移しながら、徐々にネイティブ機能に切り替えていく経路を提供します。変換方式は次の2つです。

• Shell Conversion
  メタデータのみをBW Bridgeへ移行し、データソースは別途接続し直す方式
  
  

• Remote Conversion
  データとデータフローまで含めて移行・同期する方式

2026年2月にはBW Bridge 2602がリリースされ、段階移行の信頼性とツール群がさらに整備されました。BW BridgeはODP互換のデータソースに限定されるため、自社BW環境のソースがODPで吸収できるかを最初に確認する必要があります。

向くのは、既存BW資産が中規模で、かつ「現行レポートは止められないが、新規領域はクラウド側で動かしたい」という企業です。

③フル再構築（BDCネイティブ）が向くケース

最後にフル再構築が現実的なのは、次のような条件のときです。

• BW環境が比較的小規模（モデル数十、ユーザー数百規模）でドキュメント化されている
• 既存BWの設計に長年の負債が蓄積しており、移行よりも作り直しのほうが結果的に安い
• AI・非SAPデータ統合・データレイクハウス連携を最優先したい
• BDCサブスクリプションを取得済み、もしくは取得予定で、Data Product Studioでの再設計に投資できる

フル再構築はリスクと工数が大きい一方、BW時代の制約から解放されてゼロベースで構造化できる利点があります。ハイブリッド運用がうまく回らず「半端な並行運用が長引く」ことのほうがリスクであれば、思い切って③を選ぶ判断も正解になり得ます。

詰まりやすい3つの判断ポイント

ルート選びの実務で、AI総合研究所の支援先からよく相談される論点が3つあります。

1. 「いつ移行を始めるか」の判断シグナルが見えない
   2027年末の保守切れ・S/4HANA移行プロジェクト・経営層からのクラウド戦略指示——いずれか1つが具体化したら、3〜6か月以内に意思決定の場を組むのが目安です
2. BW Bridge対応範囲の検証コストが見積もれない
   ODP互換性チェックを自社で実施するか、SAPパートナーに依頼するかで初期コストが大きく変動します。検証フェーズを独立したPoCとして切り出すと予算化しやすくなります
3. 既存レポートの「使われていない資産」が棚卸しできない
   何百本ものクエリのうち、実際に月次で参照されているものは数十本ということも珍しくありません。移行対象を絞るには、まず利用ログから現役レポートを特定する作業が前提になります

判断軸の整理ができたら、次は現行BW環境の棚卸しから始めるのがおすすめです。データモデル数・カスタムロジック数・ユーザー数・直近12か月の参照ログを揃えれば、SAPパートナーへの見積もり依頼が筋の通った形で進められます。

---

SAP BWの料金とコスト構造

SAP BW／BW/4HANAの料金はSAPが定価を公開していないため、正確な費用はSAPまたはSAPパートナーからの個別見積もりが必要です。本セクションでは、公開情報から確認できるコスト構造の輪郭と、移行判断で考慮すべきTCOの観点を整理します。

ライセンスを構成する4要素

BW/4HANAの費用に影響する主な要素は次の4つです。

• ユーザーライセンス
  名前付きユーザー（Named User）単位の課金が一般的です。分析ユーザー・開発者ユーザーなど種類により単価が異なります。
  
  

• SAP HANAデータベースライセンス
  BW/4HANAはSAP HANA上でのみ動作するため、HANAライセンスが必須です。メモリ容量（GB単位）に応じた課金が基本で、ハードウェアのスペックと密接にリンクします。
  
  

• インフラ費用
  オンプレミスの場合はサーバー・ストレージの調達・運用費用が別途発生します。IaaS（AWS・Azure・GCP）で動かす場合は、クラウドインフラの利用料が積み上がります。
  
  

• 年間保守料
  SAPの保守料率はEnterprise SupportやStandard Supportなどのサポートプランと契約条件で決まり、SAPは公開価格を提示していません。公開情報で明確に確認できるのは、SAP公式が示すBW 7.5の延長保守について「既存保守ベースに2 percentage points上乗せ」という1点のみです。それ以外の数値はパートナー経由の個別見積もりが前提になります。

つまりTCO試算の出発点として固定で組み込めるのは「BW 7.5延長保守の+2ポイント」だけで、ユーザーライセンス・HANA DB・インフラ・保守料率は契約条件と環境規模で大きく変動します。必ず自社環境ベースで見積もりを取り直してください。

BDCのCapacity Unitsモデル

SAP Business Data Cloudでは、**Capacity Units（CU）**をベースにしたサブスクリプションが新しい課金モデルとして採用されています。CUは「コンピュート・ストレージ・分析量」をまとめて表す単位で、契約に基づき消費量に応じて課金されます。

既存のSAP Datasphere・SAP Analytics Cloudの契約者は継続利用が可能で、将来的にBDCへ移行する選択肢が用意されている、というのがSAP公式の説明です。「既存のBTPEA／CPEA／PAYG契約がいつ・どの条件でBDCサブスクリプションに巻き取られるか」は公開一次ソースの粒度を超えるため、自社の契約状況に対する具体的な扱いはSAPまたは契約しているSAPパートナーに直接確認してください。CUの単価・組織別の標準枠も契約条件側で示されます。

TCO比較で見るべき観点

BW/4HANA継続（オンプレ／IaaS）とBDC移行（SaaS）のコストを比較する際は、ライセンス単価だけでなく次の観点を含めて評価する必要があります。

費用項目	BW/4HANA（オンプレ／IaaS）	BDC（SaaS）
インフラ	サーバー・ストレージを自社で調達／運用	サブスクリプションに含まれる
DB保守	HANAライセンス＋年間保守料（契約・サポートプランに依存）	BDC CUに含まれる
運用人件費	Basis管理者・インフラチームが必要	フルマネージドで削減
バージョンアップ	自社で計画・実施（数か月単位の工数）	自動アップデート
AI・データレイクハウス連携	追加実装が必要	BDC Connectで標準提供

短期的にはBW/4HANA継続のほうが安く見えるケースもありますが、インフラ更新サイクル（5年ごと）・HANA DBの保守費・運用人件費・アップグレード工数まで含めた5年以上のTCOで比較すると、クラウド移行が有利に転ぶ例が増えています。

ただし大規模・複雑なBW環境では移行プロジェクト自体のコストも億単位に膨らみ得るため、一概に判断できません。料金単体ではなく、「移行プロジェクトを含めた5年TCO」と「BDC側で得られるAI・データレイクハウス価値」の両面で評価するのがTCO判断の王道です。

---

SAP BWの活用事例

SAPは公式のBW最新化ページで、BW／BW/4HANAの資産をDatasphere／BDCに繋いだ代表的なグローバル事例を公開しています。本セクションでは、公式に紹介されている4社の事例を整理します。

Meliá Hotels International

スペインの大手ホテルチェーンMeliá Hotels Internationalは、SAP DatasphereとSAP Analytics Cloudを用いて、オンプレミスシステムのデータとサードパーティ製のクラウドSaaSデータを統合し、計画・レポート作成を一元化しました。BW資産を保ちながら、新しい外部データソースを段階的にDatasphere側で扱う典型例です。

The Hershey Company

米国の食品メーカーThe Hershey Companyは、モダン化アプローチで20年分のデータを統合しました。長期蓄積された基幹データをDatasphere／BDC側に移しつつ、Analytics Cloudで一貫した分析が可能になっています。

長期データを抱えるBW運用企業にとって、「過去資産を捨てずに最新基盤へ持ち込む」典型ルートを示す事例です。

Kemira Oyj

フィンランドの化学メーカーKemira Oyjは、SAP S/4HANA・SAP Datasphere・SAP Analytics Cloud・SAP Integration Suiteを組み合わせて、老朽化したハードウェア更新をクラウド変革の契機として再構成しました。

「インフラのリプレース・タイミングをデータ基盤刷新と組み合わせる」という、TCO最適化の観点でも示唆深い事例です。

Snam

イタリアの大手エネルギー企業Snamは、SAP DatasphereとSAP Analytics Cloudでデータモデリング・接続性・仮想化・アクセスを高度化し、全社規模のアナリティクスと計画機能を強化しました。

業界固有の複雑なデータ構造を持つ企業がDatasphereへ段階移行する事例として参考になります。

これら4社は規模・業種が異なる一方、共通するのは「BW資産を一気に置き換えるのではなく、Datasphere／BDC側で外部データやAI機能と組み合わせる方向に重心を移している」点です。日本企業がBW移行を検討する際にも、参考にしやすいパターンと言えます。

---

SAPデータ基盤の先にあるAI業務自動化

ここまで整理してきたBW／BW/4HANA／Datasphere／BDCは、いずれも「整備されたデータを誰が、どう次のアクションへ繋ぐか」が最終的な勝負どころになります。

BDC上で整ったデータプロダクトも、ダッシュボードを見て人が判断・実行するフローのままでは、データ統合に投じたコストの回収速度は限定的です。AI総合研究所の支援現場でも、BW／BDCで整えたデータをAIエージェントが直接アクションに変換する運用が、2026年に入って急速に増えています。

AI Agent Hubは、Microsoft Fabric OneLakeでSAPや外部システムのデータを仮想統合し、AIエージェントが経費精算・請求書処理・承認フローなどの業務を自動実行するエンタープライズAI基盤です。Teamsから呼び出すだけで完結し、すべて自社Azureテナント内で動作します。BWで整備してきた構造化データ資産を、分析から業務アクションへ変換する次の一手として活用できます。

---

まとめ

SAP BWは、1998年にデータウェアハウス基盤としてリリースされ、SAP BW/4HANAへの再設計を経て、いまはSAP Business Data Cloudというクラウド統合プラットフォームの中で再定義されつつあります。本記事の要点を整理します。

• BW 7.5メインストリーム保守は2027年末、延長を取っても2030年が事実上のリミット。 BW/4HANAは2040年まで保守延長済みで、長期運用の道は確保されている
  
  

• BW/4HANAの中身はaDSO・InfoObject・CompositeProvider・Open ODS Viewの4オブジェクトに整理されている。 旧BWの複雑な多層構造はBW/4HANAで大幅にシンプル化されている
  
  

• SAP DatasphereとBW/4HANAは競合ではなく役割分担。 BW/4HANAは構造化データの金庫、Datasphereはデータオーケストレーションのハブ。並行運用（ハイブリッド構成）が現実解になる場面が多い
  
  

• SAP Business Data Cloud（BDC）はBW資産をデータプロダクト化し、Databricks／Snowflake／Microsoft Fabric等とゼロコピー双方向共有する基盤として設計されている。 Data Product Generator・Data Product Studio・Joule Agentsまで含めた最新化の道筋が公式に整っている
  
  

• 移行ルートは「BW/4HANA継続」「BW Bridge経由の段階移行」「フル再構築」の三択。 自社BW環境の規模・複雑さ・クラウド戦略・運用体制で選び分ける
  
  

• 料金はライセンス公開なし。 公開情報で明確に確認できるのは「BW 7.5延長保守は既存保守ベースに+2ポイント」の一点のみ。保守料率・ユーザー単価は契約条件次第のため、移行可否はライセンス単価ではなく5年TCOで比較するのが現実的

BW利用企業がいま着手すべき第一歩は、現行環境のデータモデル数・カスタムロジック数・ユーザー数・直近12か月の参照ログを棚卸しすることです。棚卸し結果をもとにSAPパートナーへ見積もり依頼すれば、継続・段階移行・フル再構築のいずれが最適か、根拠ある判断材料が揃います。RISE with SAPによるS/4HANA移行と合わせて、データ基盤の将来像を整理してください。