SAP Business Data Cloudとは？AIエージェント基盤への進化と主要構成領域を2026年最新版で解説

SAP Business Data Cloud（BDC）は、SAP Datasphere・SAP Analytics Cloud・SAP DatabricksなどをSaaSとして束ね、企業のSAP内外データをAIエージェントの推論基盤として一元化する次世代データプラットフォームです。
2025年2月の発表時は「データ統合の新基盤」という位置づけでしたが、TechEd 2025・Sapphire 2026の発表でSAP HANA CloudとSAP Master Data Governanceがコアコンポーネント化され、Joule Agent BuilderやMCP対応が加わったことで、現在は「AIエージェントが業務を動かす推論層」として再設計されています。

本記事では2026年6月時点の最新情報をもとに、主要領域の構成・AIエージェント連携・SAP BWやDatasphereとの違い・BDC Capacity Unitベースの料金体系・Tibnor社の本稼働事例まで、SAPのデータ基盤を評価・選定する際に必要な論点を整理して解説します。

SAP Business Data Cloudとは

SAP Business Data Cloud（以下BDC）は、SAP内外のデータを一つのSaaS上で統合し、AIエージェントが業務を理解して動くための推論基盤として設計された、SAPの新世代データプラットフォームです。

SAPは2025年2月にDatabricksとの戦略パートナーシップとともにBDCを発表し、同年4月に一般提供（GA）を開始しました。発表当初は「SAP DatasphereとSAP Analytics Cloudを束ね、Databricksを取り込む新しいデータ基盤」という整理でしたが、その後のTechEd 2025とSapphire 2026で構成と役割が大きく拡張されました。

現在のBDCは、SAP HANA CloudをAIデータベースとして中核に据え、SAP Master Data Governance（MDG）でガバナンス層を担い、SAP Databricksで非SAPデータと機械学習を連携させ、Data Product Studioで業務向けデータプロダクトを運用する、というSaaSスタックに進化しています。これは「データを集める基盤」というより、「SAP Jouleを含むAIエージェントが業務文脈を読み取り、業務を動かすための土台」と理解する方が現状の姿に近い、というのが本記事の立場です。

---

SAP Business Data Cloudを構成する主要領域

BDCは複数のSaaSプロダクトを束ねた「複合体」であり、構成要素を切り分けて理解しないと「Datasphereと何が違うのか」「Databricksと何が違うのか」が判別しづらくなります。
SAP公式のBDC Capacity Unit対象サービスとSapphire 2026での発表内容を踏まえると、BDCは「データモデリング層」「分析・BI層」「データレイクハウス層」「外部接続層」「データベース層」「ガバナンス層」「データプロダクト・Insight Apps層」という複数の領域でできています。固定の「N個の構成要素」と言い切れる粒度ではなく、用途に応じて領域を組み合わせて使う構造です。

以下の表で、2026年6月時点で主要な領域と代表サービス、直近の更新ポイントを一覧で示します。

領域	代表サービス	直近の主なアップデート
データベース層	SAP HANA Cloud	Sapphire 2026でBDCのコアコンポーネント化。トランザクション・分析・空間・グラフ・ベクトルを統一エンジンで処理
データモデリング層	SAP Datasphere	BDCの中央モデリング層として継続強化。BW Bridgeで既存BW資産を取り込み
分析・BI層	SAP Analytics Cloud	BDC内でBIフロントエンドの役割を担い、Jouleと連動した自然言語問い合わせが拡大
データレイクハウス層	SAP Databricks	SAP Databricksは2025年4月にAWSでGA。BDC Connect for Databricksは2025年10月に全クラウドでGA
既存DWH取り込み	SAP Business Warehouse Cloud／BW Bridge	BWの既存モデル・データをBDC側に橋渡し
外部接続層	BDC Connect、SAP Snowflake／Open Data Ecosystem	Snowflake／BigQueryは2026 H1、Microsoft Fabricは2026 Q3 GA予定
ガバナンス層	S/4HANA Cloud for MDG（SAP Master Data Governance）	Sapphire 2026でコアコンポーネント化。あわせて買収したReltioのMDM機能もBDCに加わる方針
業務向けアプリ層	Insight Apps、Data Product Studio	Data Product Studioは2026年上半期GA予定。業務領域別の「データプロダクト」運用が中心

この表から見て取れるのは、BDCがSAP Datasphereという「データ統合のための1プロダクト」から、HANA Cloudを中核とした「AIデータ運用のためのSaaSスタック」へと位置づけを変えてきている、ということです。特にHANA CloudとMDGがコア化されたのはSapphire 2026での大きな転換点で、AIエージェントが推論するための「単一のデータ・ガバナンス層」を社内に持てるようになった意味は大きいと言えます。

SAP HANA Cloud：AIデータベースとしての中核

SAP HANA Cloudは2026年Sapphireで正式にBDCの中核コンポーネントに位置づけられました。

トランザクションデータ・分析データ・空間データ・グラフデータ・ベクトルデータを単一のインメモリエンジンで扱えるため、AIエージェントが「この顧客の今月の売上推移」と「同じ顧客のセグメント特性」と「過去の類似顧客の取引履歴」を1回のクエリで横断的に推論できます。

従来のように分析用ストアと運用DBを切り分けて持つと、推論のたびにデータをコピーする待ち時間が発生していましたが、HANA Cloudをコアに据えることでこの待ち時間が大幅に短縮される、というのが2026年版BDCの設計思想です。

SAP Datasphere：モデリングとデータカタログの中央層

SAP DatasphereはBDC発足以前から提供されているデータ統合ハブで、引き続きBDC内の「中央モデリング層」の役割を担います。

S/4HANAやSAP BW、外部のSnowflake・BigQueryといった多様なソースからのデータ取り込み、業務文脈に沿ったセマンティックモデリング、データカタログによる検索・ガバナンスを提供します。Datasphere単独で導入していた企業は、そのままBDC配下の中央モデリング層として継続利用できる設計です。

BARCの分析記事によると、BDCはSAP DatasphereとSAP Analytics Cloudの統合プラットフォームをベースに、データプロダクト、SAP Databricksとの連携、Joule統合を加えた構成として位置づけられています。

SAP Analytics Cloud：BIフロントエンドとプランニング

SAP Analytics Cloud（SAC）は、BIダッシュボード・データ可視化・予算計画（プランニング）を一つのSaaS上で提供するBIツールです。BDC内ではBIフロントエンドとして機能し、Datasphere・Databricks上のデータをそのまま可視化・分析できます。

直近ではJouleとの連携で「自然言語で過去四半期の地域別売上の特異点を質問する」「予算超過のドライバーを聞き返す」といった分析が拡大しており、BDCにおける「人が触る分析層」の主役を担い続ける位置づけです。

SAP Databricks：非SAPデータと機械学習の取り込み口

SAP Databricksは、AI/MLや大規模データ処理で広く使われているDatabricksのレイクハウスを、SAPのデータコンテキストとネイティブに連携させた構成のソリューションです。

SAP Databricks自体は2025年4月にAWS環境でGAとなり、続いて2025年10月にBDC Connect for Databricksが全クラウドでGAとなりました。BDC Connect for DatabricksはDelta Sharingでゼロコピーの双方向データ共有を可能にするコンポーネントで、これによりSAPが管理する業務マスタや取引データに対して、Databricks側で構築した機械学習モデルや非SAPソースのデータをそのまま組み合わせられます。

クラウドでDatabricksを利用しているチームには馴染みやすい構成で、Microsoft FabricとAzure Databricksの使い分けを整理してきた組織であれば、BDC側のSAP DatabricksとAzure側のDatabricksをそれぞれ役割で切り分けて運用しやすい構造です。

SAP Master Data Governance：マスタデータの統一ガバナンス

SAP Master Data Governance（MDG）はSapphire 2026でBDCのコアコンポーネントとして再位置づけされた、マスタデータ統制のレイヤーです。

顧客・取引先・商品・組織といったマスタデータの正規化、重複排除、ポリシー適用を一元化することで、AIエージェントが推論する際に「同じ顧客が複数のIDで分散している」「商品コードが部門ごとにバラバラ」といった状態を避けられます。

あわせてSapphire 2026では、SAPがMDM分野のReltioを買収しBDCに組み込む方針も示されました。MDGとReltioのMDM機能のそれぞれが具体的にどう統合されていくかは公式に詳細まで踏み込んだ説明はなく、現時点では「MDGのコア化」と「Reltio由来のマルチドメインMDM機能のBDCへの追加」を別軸として捉えるのが妥当です。エージェントが業務を動かす上で「誰の何の話か」が定まっていないと推論が崩れるため、ガバナンス層をBDCに内蔵する設計は理にかなっていると言えます。

Data Product Studio：データプロダクトの運用基盤

Data Product StudioはBDC上で「データプロダクト」を企画・公開・運用するための新しいワークベンチで、2026年上半期にGA予定とされています。

データプロダクトとは、業務領域ごとに「使う側がすぐ活用できる粒度で整備されたデータの単位」を指します。たとえば「与信判断用の顧客プロファイル」「サプライヤー評価用の取引履歴」のように、特定の業務目的に紐づけて整備されたデータをパッケージ化し、社内に公開できる仕組みです。

これまでは部門ごとにData Warehouseのテーブルやレポートを作り込む形でしたが、Data Product Studioで「業務単位のデータ製品」として運用することで、AIエージェントが特定業務向けにデータを呼び出す導線がそろう、というのがSAPの構想です。

---

AIエージェント基盤としてのSAP Business Data Cloud

BDCを2026年時点で評価するうえで最も重要なのは、「BDCがAIエージェントの推論基盤として再設計されている」という点です。本セクションでは、Joule Agent Builder・SAP Knowledge Graph・MCP対応・Agent-to-Agent（A2A）プロトコルという4つの軸で、BDCとAIエージェントの結びつきを整理します。

Joule Agent Builder：エージェントの設計・運用基盤

Joule Agent BuilderはTechEd 2025（2025年11月）で発表された、Joule Studio内に組み込まれたカスタムエージェント開発環境です。

業務担当者向けのローコードUI（ビジュアル＆自然言語）と、開発者向けのプロコードSDKの両方を備え、SAP Knowledge Graph・SAP Business Data Cloud・SAP中央IDサービスを土台にして、SAP環境で「責任あるエージェント挙動」を担保する設計になっています。LangGraph・CrewAI・Google Agent Development Kitといった既存のエージェントフレームワークにも対応しているため、社内で既にエージェント開発を進めているチームの資産を持ち込めるのも特徴です。

SAP Jouleそのものの位置づけや料金は別記事に整理していますが、BDC側から見ると「Jouleエージェントが業務文脈を読むためのデータ・コンテキストを供給する側」という関係です。

SAP Knowledge Graphによる業務意味づけ

SAP Knowledge GraphはSAPの業務オントロジー（プロセス・ロール・データ・関係性）を構造化したナレッジ層で、「この値が誰の・何の・どの業務上の意味を持つか」をAIエージェントに渡すための仕組みです。

TechEd 2025では、メタデータから自動的にナレッジグラフを生成する機能が拡張され、これまで数週間かかっていたグラフ構築が「数分単位」で済むようになると発表されました（2026年Q1にGA予定）。エージェントに「未払い金が大きい顧客を抽出して」と頼んだとき、単なる金額列挙ではなく「与信枠・契約条件・債権回収プロセス」まで踏まえた回答が返せるのは、このKnowledge Graphが業務意味を保持しているためです。

MCP（Model Context Protocol）対応：外部エージェントとの接続

TechEd 2025で「SAP HANA Cloud向けMCPサーバーが一般提供開始」と正式発表され、Cursor・Claude Code・Cline・WindsurfなどModel Context Protocol（MCP）に対応した外部エージェントから、SAP HANA Cloud上のデータに接続できるようになりました。GA対象は現時点ではHANA Cloud向けで、BDCに含まれる他のサービス（Datasphere／SAC／Databricks等）への直接接続が同じMCPサーバーで完結するわけではありません。

ただし、HANA CloudはBDCのコアデータベースに位置づけられているため、HANA Cloud側にデータが置かれている範囲では「非SAP製の外部エージェントからSAPのデータに安全にアクセスする」という従来困難だった構造が一気に現実的になります。BDC上の他のサービスについても、SAP Build側のMCP対応拡張が今後進む方針が示されています。

Agent-to-Agent（A2A）プロトコルによるエージェント協調

Agent-to-Agent（A2A）プロトコルは複数のエージェント同士が連携して仕事を分担するための共通仕様で、SAPはAWS・Google・Microsoft・ServiceNowと共同でA2A対応を進めています。SAP側でA2Aを担うのは主にJouleおよびSAP BTP上のエージェントで、Joule Agent Builderで作ったエージェントが他社プラットフォーム上のエージェントと連携することを想定した発表が中心です。

たとえば「Joule Agent Builderで作ったエージェントが見積を作成」→「ServiceNow上の承認ワークフローエージェントが上司の判断を取り付け」→「Salesforce側の営業エージェントが顧客通知を発出」といったクロスベンダーのエージェント連鎖が、システム間で人を経由せずにつながる構造を目指せます。A2A対応の主役はあくまでJoule／BTP側のエージェントで、BDCはそれらエージェントに業務データ・業務文脈を供給する側として組み合わさる位置づけです。

ここまで踏まえると、2026年のBDCは「データを集める基盤」というより「AIエージェント群がクロス組織で業務を動かすための土台」として設計されていることが見えてきます。

---

SAP BWやSAP Datasphereとの違いと移行パス

BDCを検討する企業の多くは、すでにSAP BWやSAP Datasphereを使っていて、「次の手はBDCなのか、Datasphere継続なのか」を判断する必要があります。本セクションでは関係性と移行パスを整理します。

以下の表で、SAP BW・SAP Datasphere・SAP Business Data Cloudの位置づけと移行のしやすさを並べます。

区分	主な役割	提供形態	BDCとの関係
SAP BW（オンプレ/BW/4HANA）	従来型のSAP向けDWH	オンプレ／プライベートクラウド	BW Bridge経由でDatasphere／BDCに資産を取り込み可能
SAP Datasphere	クラウド型のデータファブリック・モデリング層	パブリッククラウドSaaS	BDC内の中央モデリング層として継続。Datasphere単体導入は2025年以降も継続可能
SAP Business Data Cloud	Datasphere＋SAC＋Databricks＋HANA Cloud＋MDG＋Data Product Studioを束ねた統合SaaS	パブリッククラウドSaaS	Datasphereの上位概念として位置付け

この整理から見えるのは、BDCはSAP Datasphereを置き換える「別物」ではなく、Datasphereを中央モデリング層として内包したうえで、AIデータ運用に必要な周辺コンポーネント（HANA Cloud／Databricks／MDG／Data Product Studio）を加えた上位パッケージである、という点です。Datasphere単独利用も2025年以降継続可能で、いきなり全面切り替えを迫られるわけではありません。

SAP BWからの移行：BW Bridgeで段階的に

SAP BWの既存ユーザーがBDCに進む場合、BW Bridgeを使ってSAP Datasphereに既存のモデル・データを取り込みつつ、Datasphere上で新規のモデリングを進めるのが現実的な経路です。

BW Bridgeはオンプレ／プライベートクラウドのBWからクラウド側にデータを橋渡しする仕組みで、BWの資産を捨てずにクラウド型データ基盤に移行できる設計になっています。BWのSAP 2027年問題を控える企業にとって、BW→Datasphere→BDCという段階移行は現実的な選択肢です。

Datasphere既存ユーザーの選択肢

Datasphereをすでに使っている企業は、BDCへ移行することで以下の機能が追加されます。

• SAP Databricks
  非SAPデータ統合と機械学習・生成AIの基盤として活用できる
  
  

• SAP HANA Cloud
  コアとなるAIデータベースとして、推論時のデータコピーを削減できる
  
  

• SAP Master Data Governance
  マスタデータの正規化と統制を効かせ、エージェント推論の前提を整えられる
  
  

• Data Product Studio
  業務向けデータプロダクトを企画から運用まで一元化できる
  
  

• Joule Agent Builder
  SAP Knowledge Graph・BDCを土台にしたエージェント開発・運用が可能になる
  
  

ただし、上記の機能を全部使う必要がない場合はDatasphere単体で運用継続するのも合理的な選択です。BDCはサブスクリプション単位で提供されるため、「データ統合だけならDatasphere」「AIエージェント運用までやるならBDC」というラインで判断するのが実務的です。

BW・Datasphere・BDCの併用シナリオ

実務ではBWを完全撤去するのではなく、「基幹業務の老朽化していないレポート系はBWに残す」「新規のAI活用領域はBDC上で構築する」という併用構成が多くなります。

ハイブリッド構成では、BW BridgeでBWのモデルをDatasphere/BDCに必要な分だけ持ち込みつつ、SAP Databricks経由で外部データソースとつなぐといった設計が現実的です。一気にBWを撤去すると業務影響が大きくなりがちなので、段階的な移行を前提とした評価が重要です。

---

SAP Business Data Cloudの料金とライセンス体系

BDCの料金は「サブスクリプション制で公開単価が限定的」というのが基本構造で、契約規模・コンポーネント構成・利用量によって個別見積もりになります。本セクションでは2026年6月時点で公開されている範囲の情報を整理します。

BDC Capacity Unitを単位とした料金体系

SAPのBDC公式pricingページでは、BDCの料金は「BDC Capacity Unit／月」を単位とした契約として示されており、契約期間は3〜36カ月の範囲で選べる体系になっています。具体的な単価は掲載されておらず、SAPまたはSAPパートナーへの問い合わせベースで個別に見積もる前提です。

BDC Capacity Unitの対象には、SAP Datasphere、SAP Analytics Cloud、SAP Business Warehouse Cloud、SAP Databricks、BDC Connect、SAP HANA Cloud、S/4HANA Cloud for MDG などが含まれており、これらを横断して消費できる枠としてCapacity Unitを購入する形になります。料金は概ね以下の軸で決まります。

• 対象サービスの利用構成
  Datasphere／SAC／SAP Business Warehouse Cloud／SAP Databricks／BDC Connect／HANA Cloud／S/4HANA Cloud for MDGなどのうち、どこまでをCapacity Unitで動かすか
  
  

• Capacity Unitの月間消費量
  HANA Cloudの容量、Databricks側のコンピュート、Datasphereのモデル数などが利用量に応じてCapacity Unitを消費
  
  

• 契約期間
  3カ月〜36カ月の範囲で選択。具体的な単価条件はSAPまたはパートナー経由の個別見積もりで確認
  
  

• 既存契約の置換適用
  既存のDatasphere／SAC／HANA Cloud契約をBDCに繰り入れる場合は、Capacity Unit側に再計算される
  
  

SAP Databricksの割引キャンペーン（2026年4月末で終了）

SAPはBDC顧客・パートナーアップデートとして、SAP DatabricksをAWS環境で一般提供するとともに、2026年4月30日までの期間限定で新規顧客向け割引キャンペーンを提供していました。記事執筆時点（2026年6月）ではこの割引期間は終了しています。

この割引は新規にSAP Databricksを契約する顧客を対象としたもので、ベータ期間のフィードバックを活かして「Databricks併用構成の早期立ち上げを後押しする」位置づけでした。後継のキャンペーンや、リージョン別の特別条件が追加される可能性はあるため、評価段階では必ずSAPまたはパートナーに最新条件を確認することを推奨します。

既存ユーザーからの移行時の費用観点

既存でSAP DatasphereやSAP HANA Cloud、SAP Analytics Cloudを単独契約している企業がBDCに移行する場合、既存サブスクリプションがBDC側に組み込まれる形で再計算されます。

二重課金にならないよう設計されているものの、コンポーネント単位の単価とBDCパッケージ単価の差分は契約条件によって変動します。BDCに移行することで「DatabricksやMDGの追加料金が発生する代わりに、運用工数が下がる」という総コストの見方をする必要があり、単純に既存料金と比較するだけでは判断を誤ります。

---

SAP Business Data Cloudの導入事例と業務適用シーン

ここまでで構成と料金を見てきましたが、実際に何ができるかは導入事例を見ると掴みやすくなります。本セクションでは公式に公開されている事例と典型的な業務適用シーンを整理します。

Tibnor（スウェーデン鉄鋼流通）：初の本稼働事例

SAPの公式アップデートで紹介されたように、スウェーデンの鉄鋼流通企業Tibnorは、SAP Business Data Cloudの最初の本稼働（live customer）として2025年に運用を開始しました。

同社シニアIT顧問のDag Åselius氏は「SAP Business Data Cloudは、外部データを迅速に統合する新しい機会を開いた」とコメントしており、SAPデータと非SAPソースを統合して変化する市況に素早く対応する基盤として位置づけられていると、公式発表では説明されています。具体的にどの外部データソースを統合し、どの業務シナリオで使われているか、定量効果がどうだったかまでは現時点で公開されていません。鉄鋼流通は市況変動への対応速度が利益率を左右する業界であるため、外部データとSAP上の業務データを横断して見られる基盤を初期に採用した事例として参考になります。

ベータコミュニティの定量フィードバック

SAPの発表によると、BDCのベータコミュニティでは「データモデルが20〜50%向上した」というフィードバックが報告されています。具体的にどの指標がどの基準と比較して20〜50%向上したのか、参加した企業数や業種、計測手順といった詳細な算出条件は公開されていません。

公式発表で言及されている範囲では、業務単位で定義されたデータプロダクトやSAP Knowledge Graphによる業務意味づけが、データの再利用やモデリング工数の改善に寄与している、というのが大まかな趣旨です。導入評価時にこの数値をそのまま自社プロジェクトの想定効果として置くと過大評価になりやすいので、参考値として扱う方が安全です。

典型的な業務適用シーン

公式事例に加え、SAPおよびパートナーが共通して挙げている適用シーンは以下のような領域です。

• 需要予測と生産計画の連動
  SAP S/4HANAの販売実績・在庫データに、SAP Databricks経由で外部の市場データや天候データを組み合わせ、需要予測モデルを構築する用途
  
  

• キャンペーン・価格最適化
  SAPの取引データに、CRMや外部のマーケティングデータを連携させ、SAP Analytics Cloud上でセグメント別の効果を分析する用途
  
  

• サプライヤー評価とリスク管理
  購買データ・品質データ・外部のサプライヤー信用情報を結合し、Data Product Studioで「サプライヤー評価データプロダクト」として運用する用途
  
  

• 財務・人事の統合分析
  SAP FIなどの基幹業務データに人事系データを結合し、コスト構造や生産性指標をJouleで質問応答可能にする用途
  
  

これらのシーンに共通するのは「SAPの基幹データ単独では難しかった分析を、外部データやAI/MLと組み合わせて業務に届ける」という構図で、BDCが「データ統合基盤」と「AI推論基盤」の両方を兼ねる構造によって実現しやすくなっています。

---

BDC評価で見落としやすい3つの観点

BDCを評価する企業から実際に相談を受けていると、機能の比較だけで判断して後から戻り工数が発生するケースが少なくありません。本セクションでは、AI総研がSAPユーザー向けのデータ基盤・AIエージェント支援で繰り返し見てきた「評価段階で見落としやすい論点」を3つに整理します。

BDCを「データ基盤」だけで評価しない

BDCを「Datasphereの拡張版」と捉えてしまうと、HANA Cloud・MDG・Joule Agent Builder・MCP対応といった「AIエージェント基盤としての価値」が比較項目から抜け落ちます。

評価軸を「データ統合の効率」だけに置くと、SnowflakeやDatabricks単独構成と比較した時に「割高で乗り換えメリットが薄い」と見えがちですが、実際にはAIエージェントが業務文脈付きでデータにアクセスできる構造を含めて比較すべきです。「3年後に社内エージェント運用がどうなっているか」を前提に置いて評価すると、BDCの優先順位は変わってきます。

Datasphere継続・BDC移行・Databricks単独の判断軸

実際の比較は、Datasphere継続・BDC移行・Databricks単独構成の三つ巴になることが多く、それぞれに向く状況は分かれます。

構成	向くケース	注意点
Datasphere単独継続	データ統合のみで十分／AIエージェント連携は当面不要	数年後にBDC移行を検討する場合の費用差分を見ておく
BDC（フル構成）	SAP基幹データを軸にAIエージェント業務を進めたい／MDG統制を効かせたい	コンポーネント数が増える分、運用役割の整理が必要
Databricks単独	SAPデータが主軸でない／既にDatabricks上で大規模なML資産がある	SAPとの双方向連携をどう設計するかが追加検討事項

この三択を「価格だけ」で比較すると判断を誤りやすく、「AI Agentを業務に組み込んだ3年後の運用像」を仮置きしたうえで、その実現に必要な機能・統制要件・運用工数まで含めて見るのが現実的です。AI総研の支援経験では、SAP基幹データが業務の中核を担う企業はBDC方向に向けて段階的に集約していくケースが多く、SAPがサブ業務の企業ではDatabricks単独構成が合理的になる、というのが概ねの傾向です。

業務コンテンツのカスタマイズ要件を早めに見極める

BDCは「業界・業務領域別のすぐ使える業務コンテンツ」を提供していますが、自社固有の業務プロセスやKPIにそのまま当てはまることは稀です。

データプロダクトのカスタマイズや業務コンテンツの追加開発を、誰が・どの頻度で行うのか、Data Product Studio上の運用担当をどう配置するのか、といった「運用人材」の議論を後回しにすると、「導入したが社内で誰も使いこなせていない」という典型的なつまずきに陥ります。データ基盤の評価段階で、業務側オーナーと開発側オーナーの役割分担を仮置きしておくと、後の運用設計がスムーズになります。

---

SAP BDCを業務に効かせるための次の一歩

SAP Business Data Cloudは「データを集めて整える基盤」から、「AIエージェントが業務を動かすための推論層」へと2025〜2026年で大きく性格を変えました。次の一歩として求められるのは、「整えたデータをどう業務オペレーションに落とすか」、つまりAIエージェント側の設計と運用です。

社内のSAPデータをBDC上に集約しても、それを起点に動くエージェントを設計・運用するチームが育っていなければ、データ基盤への投資が業務価値に変換されません。AI Agent Hubは、BDCのようなデータ基盤と業務オペレーションをつなぐAIエージェント開発・運用を、業務部門と継続的に取り組める形で支援します。

---

まとめ

最後に本記事の要点をまとめます。

• BDCの定義
  SAP Datasphere・SAC・SAP Business Warehouse Cloud・SAP Databricks・BDC Connect・HANA Cloud・S/4HANA Cloud for MDGなどを束ねたSaaS型のデータ・AI基盤
  
  

• 2026年の進化
  Sapphire 2026でHANA CloudとMDGがコア化し、AIエージェントの推論基盤としての性格が強まった
  
  

• AIエージェント連携
  MCPはSAP HANA Cloud向けでGA、A2AはJoule／BTP側のエージェント連携が中心、Joule Agent Builder・SAP Knowledge Graphも組み合わさる構造
  
  

• 既存ユーザーの移行
  BW BridgeでBW資産を段階移行、Datasphere単独継続も可能、フル機能を活かすならBDC移行を検討
  
  

• 料金
  「BDC Capacity Unit／月」を単位とした契約（期間3〜36カ月、価格は問い合わせ）。SAP Databricks割引は2026年4月末で終了済み
  
  

• 事例
  スウェーデンTibnor社が初の本稼働、ベータでデータモデル20〜50%改善との報告（詳細な算出条件は非公開）
  
  

• 評価の見落とし
  「データ基盤」評価だけでなく「AIエージェント基盤」として評価し、運用人材まで含めて判断する
  
  

SAP基幹データを中核に据えてAIエージェントの業務適用を進めたい企業にとって、BDCは「データ統合」と「AI推論基盤」を1つのSaaSで担える有力な選択肢です。一方で、必要なコンポーネントの範囲と運用人材の配置をはじめに整理しておかないと、機能の多さが運用負荷に転じます。本記事の整理を、自社のBDC評価とAIエージェント運用構想の出発点にしていただければ幸いです。