SAP BDC × Microsoft Fabric連携とは？ゼロコピー共有や使い方、事例を徹底解説

SAP Business Data CloudとMicrosoft Fabricの連携は、2025年11月のIgniteと2026年5月のSapphireで公表された「SAP BDC Connect for Microsoft Fabric」を軸に、双方向ゼロコピー共有でSAPデータ基盤とMicrosoft基盤を直結する構想として動き出しています。
従来のETL複製やパートナー抽出に加え、Q3 2026 GA予定の新機能でデータをコピーせずFabric側から参照する運用が視野に入りました。

本記事では、BDC Connectの中核仕組み、現時点で使えるSAPデータ連携パターン、Fabric上のAI活用、Maersk・KONE・Tibnorの事例、コスト構造と導入判断のポイントを2026年8月時点で整理します。

SAP Business Data Cloud × Microsoft Fabric連携とは

SAP Business Data Cloud（以下BDC）とMicrosoft Fabricの連携は、SAPのSaaS型データプラットフォームであるBDCと、Microsoftのアナリティクス統合基盤であるMicrosoft Fabricを、双方向のデータ共有と共通の意味レイヤーで結び付ける取り組みを指します。

従来はETL複製やパートナー抽出でSAPデータをFabricへ片方向で流していましたが、2025〜2026年にかけて両社が公式パートナーシップを段階的に強化し、データを移動せずに直結する構想が動き出しました。

本記事の立場としては、この連携を「新機能のGAを待つ単発の話」ではなく、既にGA済みの複数機能と組み合わせて段階的に着手する話として扱います。GA予定機能はあくまで到達点で、そこに至る過渡期のパターンを整理することが、2026年時点の意思決定には必要です。

SAPデータ側とMicrosoftデータ基盤側の役割分担

SAP Business Data CloudはSAP側の業務データを「データプロダクト」として統合管理するSaaSで、Datasphere・SAC・SAP Databricksを束ねる位置づけです。

一方、Microsoft FabricはMicrosoft側のアナリティクスとAIを1つのOneLake上に統合するSaaSで、Power BI・Data Factory・Fabric Copilotなどを含みます。

両者を連携させる意義は、SAP側の意味レイヤー（顧客・契約・注文といったビジネスオブジェクト）をMicrosoft側のAI・BI機能から同じ語彙で扱えるようにする点にあります。

連携なしではFabric側でSAP由来のデータを扱う際に意味情報が抜け落ち、AIエージェントも「テーブル名の羅列」を相手にすることになってしまいます。

---

SAP × Fabric連携の全体像—4つの接続オプションで整理する

SAPデータをMicrosoft Fabricに持ち込むための選択肢は、2026年8月時点で大きく4つに整理できます。

BDC Connectだけが選択肢ではなく、実装の目的とタイムラインで使い分けが変わる点を最初に押さえておく必要があります。

4つの接続オプションと立ち位置

以下の表で、Fabric側から見たSAPデータ接続の4オプションを整理しました。GA状況・データフロー・想定用途が違うため、単純に置き換え可能な選択肢ではありません。

オプション	GA状況	データフロー	想定用途
組み込みSAPコネクタ + OPDG	GA	SAPソース → OPDG → Fabric Dataflow/Pipeline	既存BW/HANAクエリの流用、部門主導のBI
Mirroring for SAP Datasphere	2026年3月GA	SAP → SAP Datasphere → ADLS Gen2 → OneLakeミラー	継続レプリカ、SAP+非SAPの統合分析
SAP BDC Connect for Microsoft Fabric	Q3 2026 GA予定	BDC ↔ OneLake 双方向ゼロコピー共有	データを移動せず両プラットフォームから参照
パートナー製SAP抽出ソリューション	GA（製品ごとに異なる）	SAPソース → パートナー Add-on → OneLake	特殊テーブル・BAPI・CDS・ABAP拡張の抽出

この比較から分かるのは、BDC ConnectのGA前後で選択肢の重心が変わるということです。GA前はMirroring for SAP Datasphereと組み込みコネクタの併用が現実解で、GA後はBDC Connectが「BDCを既に持っている企業」の第一候補になります。

データ層とAI層の関係

Fabric側で扱う話は「データ層」と「AI層」の2つに分けて考えると混乱しません。

データ層はSAPデータをFabricに載せる話、AI層は載ったデータをFabric CopilotやFabric Data Agentで使う話です。

本記事はこの後、まずデータ層をSAP BDC Connectとその他のFabric側統合パターンの2つに分けて扱い、続けてAI層（Fabric CopilotとFabric Data Agent）に進みます。SAP側からSAPエージェントを直接呼び出す話（Joule Agent BuilderやSAP Business AI）は別記事で扱う整理としています。

---

本命の中核—SAP BDC Connect for Microsoft Fabric

BDC Connect for Microsoft Fabricは、2025年11月のMicrosoft IgniteでSAPのMuhammad Alam氏（SAP Executive Board）とMicrosoftのScott Guthrie氏（Cloud and AI EVP）が共同発表した機能です。

SAPとMicrosoftのプラットフォームを、データ複製なしで直結する狙いがあります。

双方向ゼロコピー共有の意味

BDC Connectで最も重要な仕様は、SAP BDCとMicrosoft OneLake間でデータを物理的にコピーせずに双方向共有できる点です。

従来のETLパイプラインではSAPデータをFabric側にコピーして保持する必要がありましたが、BDC Connectでは共有側と参照側の双方が同じデータプロダクトを見に行く形になります。

この方式のメリットは、データの重複コストとレプリケーション遅延がゼロになることです。

SAPデータプロダクトが持つ意味情報やメタデータを伴って共有できる設計となっていますが、Fabric側での権限制御やマスキング適用は別途設計・検証が必要です。

公式資料のSAPのプレスリリースでは「semantically rich SAP data products」という表現が使われており、単にテーブルを共有するのではなく、BDC上で構築したデータプロダクト単位で共有できる点が強調されています。

従来のETL/複製方式との違い

以下のリストで、BDC Connectと従来方式の実務的な差分を整理しました。

• データ保持コスト
  従来方式はFabric側にコピーを持つためストレージが二重に発生。BDC Connectは共有のみで二重保持なし
  
  

• 鮮度
  従来方式は日次バッチや数分間隔レプリカが基本。BDC Connectは共有側が更新した瞬間から参照可能
  
  

• メタデータの伴走
  従来方式はコピー時点でSAP側の意味情報やメタデータが切れがち。BDC Connectはデータプロダクト単位で意味情報を伴って共有可能（権限・マスキングはFabric側で別途設計）
  
  

• 双方向性
  従来方式は基本SAP→Fabricの単方向。BDC ConnectはFabric側のデータセットもBDCへ共有可能
  
  

これらの違いは、単なる性能改善というより「SAPとFabricを別個のサイロとして運用するか、単一の論理データ空間として扱うか」という設計思想の切り替えを意味しています。

GA予定と現時点で取れる代替アプローチ

BDC Connectの一般提供（GA）はSAP・Microsoft両社とも「2026年第3四半期」と公表しています。現時点（2026年8月）ではGA前のためプレビュー段階で、本番運用のリスクを負える企業は限定的です。

GAまでの代替として現実的なのが、後述のMirroring for SAP DatasphereとOneLakeショートカットの組み合わせです。

BDC Connect GA後に「双方向ゼロコピー」に置き換える前提で、Mirroring運用で先行実装しておく選択肢は多くの企業で検討価値があります。

SAP側のBDC全体像はSAP Business Data Cloudで詳しく解説していますが、BDC Connectは既にBDCを契約している企業が対象です。BDC本体を導入していない企業が「BDC Connectを使うためだけにBDCを契約する」判断は、BDC自体のROIから逆算する必要があります。

---

現時点で使えるFabric側のSAPデータ統合パターン

BDC Connect GAまでの間、実運用で選ばれているのがMirroring for SAP Datasphere・組み込みコネクタ+OPDG・パートナー製ソリューションの3系統です。

それぞれ得意領域が異なり、多くの企業では複数を並行で使う形になります。

Mirroring for SAP Datasphere（2026年3月GA）

Mirroring for SAP Datasphereは、SAP Datasphereのレプリケーションフローを利用してSAPデータをFabric OneLakeに継続同期する機能です。2026年3月にGAし、Microsoft Fabric公式ドキュメントで仕様が確定しています。

処理は2段階で構成されます。まずSAP Datasphereのreplication flowがSAPソースから初期スナップショットと差分を抽出し、Azure Data Lake Storage（ADLS）Gen2コンテナに配置します。次にFabricのmirroring replication engineがそのコンテナに接続し、OneLake上のmirrored databaseに継続マージしていく仕組みです。

対応するSAPソースは、SAP Datasphereが接続できる全ソース—SAP S/4HANA・SAP ECC・SAP BW/4HANA・SAP BW・SAP Datasphere自体—が対象になります。SAP側の運用系システムの多くをカバーできる点が強みです。

Fabric側の課金は、Mirroringのレプリケーション用コンピュートが無料、レプリカストレージもSKU別の上限まで無料で、上限を超えた分はOneLakeストレージとして課金されます。

ただしSAP Datasphere側のPremium Outbound Integrationは別途課金される点に注意が必要です。詳しくは後述のコストセクションで整理します。

組み込みSAPコネクタ + OPDG（On-premises data gateway）

Fabricは組み込みでSAP BW（Application Server/Message Server）・SAP HANA・SAP HANA Cloud・SAP Datasphere・SAP S/4HANAへの接続機能を持ちます。

SAP HANA・BW・ODBCなどの接続はOn-premises data gateway（OPDG）経由で動作するため、SAPシステムがオンプレでもクラウドでも同じアーキテクチャで扱えます。ODataコネクタは接続先に応じてゲートウェイなし・OPDG・VNet gatewayから選べます。

代表的な使い方は、SAP BWコネクタでBWクエリやS/4HANAのCDSビューを叩き、Dataflow Gen2でOneLakeに取り込んでPower BIで可視化するパターンです。既にBWで組んだKPIやセキュリティ定義をそのまま流用できるため、部門主導のセルフサービスBI用途では第一候補になります。

SAP HANA/HANA CloudやSAP Datasphere接続では、Calculation ViewやSQL objectsへのアクセスがDataflow Gen2とFabric Pipelineの両方で使えます。
ODBCコネクタも代替として提供されており、SAP DatasphereがSQL中心の場合はODBC経由の方が扱いやすいケースもあります。

コネクタ設定の詳細はMicrosoft FabricのデータエンジニアリングやFabric Data Factoryの解説と併読すると全体像が掴みやすくなります。

パートナー製SAP抽出ソリューション

SAP認定を取得しているパートナー製品は、組み込みコネクタでカバーしきれない領域（プールテーブル・クラスタテーブル・SAP独自のCDC・BAPI呼び出し・ABAP Add-on経由の抽出等）に対応する選択肢として使われます。

2026年8月時点でMicrosoft Fabric OneLake対応が公表されている主要な製品は以下です。

パートナー製品	対応SAPソース	特徴
Theobald Xtract Universal	ECC / S/4HANA / BW / BW/4HANA	SAP認定、CDSビュー・BW Object・Table抽出
SNP Glue	ECC / S/4HANA / BW	ABAP Add-on経由、CDCサポート、ODP不使用
AecorSoft Data Integrator	ECC / S/4HANA / BW / HANA	ABAP Turbo Framework、バッチ+CDC
DAB Nexus	S/4HANA / ECC / CRM / SRM / SCM / EWM	O2C・G/L等のプリセットパッケージ
Simplement Roundhouse	ECC / CRM / CFIN / S/4HANA	プールテーブル・クラスタテーブルもCDC対応
ASAPIO Fabric connector	ECC / S/4HANA（RISE含む）	Business Object EventsベースのNear-real-time

この比較から分かるのは、パートナー製品は「組み込みコネクタで無理な領域」と「NetWeaverベースのAdd-on実装を許容できる環境」を前提にした選択肢だという点です。

RISE with SAP環境で使えるかどうかは製品ごとに違うため、公式のSAP Certified Solution Directoryで確認する必要があります。

OneLakeショートカットの活用

もう1つ実務でよく使うのが、OneLakeショートカットです。既にADLS Gen2やAmazon S3上にSAPデータを抽出済みの企業は、物理コピーを作らずにOneLakeから参照できます。

例えば、Azure Data FactoryやSynapseで既に構築したSAPデータ抽出パイプラインの成果物を、OneLakeショートカットで公開するだけでFabricのlakehouseやSpark notebook、Power BIから利用可能になります。既存資産を活かしたまま段階的にFabricへ寄せていく移行パスとして有効です。

---

Fabric上でSAPデータをAI活用する方法

SAPデータをOneLakeに載せた後、それをどう業務のAI活用に繋げるかが本節のテーマです。Fabric側にはSAPデータ専用のAI機能があるわけではなく、Fabric全体のAI機能をSAPデータにも適用する形になります。

Fabric Copilot（Power BI Copilot／Data Agent向け）

Fabric Copilotは、Fabricの主要ワークロード（Power BI・Data Factory・Data Engineering・Data Warehouse・Real-Time Intelligence等）に組み込まれた生成AIアシスタント機能です。SAPデータがOneLakeに載っていれば、他のデータと同じ土俵で自然言語問い合わせや自動レポート生成の対象になります。

代表的な使い方は、Power BI Copilotでダッシュボードを自然言語作成し、SAP由来の売上や在庫データに対して分析を回すパターンです。
詳しくはCopilot for Power BIで解説しています。

Fabric Data Agentでの業務問い合わせ

Fabric Data Agentは、特定のデータソース（Warehouse・Lakehouse・Semantic Model等）に対して自然言語で問い合わせできるエージェント基盤です。SAPデータをsemantic modelに整理しておくと、業務ユーザーは「先月の販売実績を製品カテゴリ別に見せて」といった質問をSAP側の業務用語のまま投げられます。

BDC ConnectがGAした後は、BDC上のデータプロダクトが持つ意味レイヤーをそのままFabric Data Agentから参照できる想定です。

SAP側で定義した「顧客」「契約」「注文」といったビジネスオブジェクトを、Fabricのagentが同じ語彙で扱える状態が実現します。

Foundry連携（Fabric経由でSAPデータをagentに渡す）

Microsoft Foundry側のエージェントからSAPデータを扱う場合、Foundry × SAP公式ドキュメントでは3パターンが紹介されています。

1. Direct API consumption（SAP OData/RESTを直接呼ぶ）
2. Data lake and semantic model（Fabric経由でsemantic modelを参照）
3. MCP tools（MCPサーバー経由でSAP API呼び出し）

このうち本記事のテーマに直結するのが2番目のパターンで、Fabric上のsemantic modelをFoundryのagentがretrieveする構成です。Direct API・MCPパターンは別記事で詳述するため、本節ではFabric経由の連携に絞ります。

Fabric上のsemantic model + Foundry agentの組み合わせは、SAPデータで裏付けられた「業務判断エージェント」を構築する典型パターンとして紹介されています。

具体的にはSpend Analysis・Trial Balance・O2C Pipeline等の分析軸で使われます。

Microsoft 365 Copilot / Copilot Studioとの補完関係

Fabric上のsemantic modelはMicrosoft Copilot Studioで構築したエージェントからも参照可能です。「Fabric内の営業ダッシュボードをTeamsから直接呼び出せる」型の使い方で、業務ユーザーが日常ツール上でSAPデータを扱う体験を作れます。

ただし、Fabric Data AgentをMicrosoft 365 CopilotまたはCopilot Studioから利用する連携は、2026年8月時点でいずれもPreviewです。

別の統合ラインとして押さえておきたいのが、SAPのJouleとMicrosoft 365 CopilotのA2A（Agent-to-Agent）連携で、本記事のFabric連携とは独立して動きます。この2つを混同しないことが、社内資料での役割整理でも重要です。

---

業務プロセス別のSAP × Fabric活用ユースケース

SAP × Fabric連携が実際にどう業務に効くかを、Microsoftの「Business Process Solutions（BPS）」と公式のSAP AIシナリオに沿って整理します。BPSのプリセットはFinance・Procurement・Salesが中心で、HRはFoundry側のSAP AIシナリオとして別枠で提供されています。

Finance—Record to Report

財務会計プロセス（R2R：Record to Report）は、SAP × Fabricで最も早く活用が進んでいる領域です。Microsoft公式のBPSでは、試算表・年次財務諸表・収益性分析・買掛金/売掛金エイジングといった代表的な分析軸が事前構築されて提供されています。

具体的には、S/4HANAやECCの財務データをFabricのsemantic modelに載せ、Power BIダッシュボードで可視化しつつ、Copilot経由で「今月の未処理仕訳を教えて」といった自然言語問い合わせを可能にする使い方が公表されています。

Procurement—Procure to Pay

購買・調達プロセス（P2P）では、SAP AribaやS/4HANAの購買データをFabricで統合し、サプライヤー別・カテゴリ別・地域別のspend analysisを回す使い方が中心です。

BPSでは360度ビュー・トレンド・カテゴリ分析・テールスペンド分析といった標準テンプレートが提供されており、AribaとS/4HANAの購買データをFabricで結合するだけで初期分析が立ち上がります。BDC ConnectのGA後は、BDC側のsemantically rich data productsを直接参照する形に置き換えられていく見通しです。

HR—Hire to Retire

人事プロセス（H2R）では、SAP SuccessFactorsのEmployee Central・給与・タレントデータをFabricに取り込み、部門横断の分析やCopilot Chatでの休暇残高照会などに活用します。Microsoft 365 CopilotのEmployee Self-Service agentはSuccessFactorsとOData経由で直接連携する設計で、Fabric経由は必須ではありません。

Sales—Order to Cash

販売・売上プロセス（O2C）では、S/4HANAのSD（販売管理）データをFabricに取り込み、pipeline health・opportunity overview・revenue insightsといった営業分析を回します。Sales CloudのAI機能とFabric側の分析を組み合わせるパターンも公式アーキテクチャで紹介されています。

BPSに含まれない領域—製造・サプライチェーンは今後対応

Microsoft側の公表では、Manufacturing・Supply Chain領域のBPSは2026年8月時点で「planning stage」とされており、プリセットのテンプレートは未提供です。

これらの領域を扱う場合は、Fabric Data Engineeringで自前にsemantic modelを組む前提で計画する必要があります。

---

SAP × Fabric連携の判断で見落とされやすい5つの論点

導入の検討段階で見落とされやすく、後から追加調達や設計変更につながる論点を5つ整理します。単純な機能比較では見えにくく、契約・アーキテクチャ設計の初期に見ておくべき項目です。

ライセンスと契約の前提条件

BDC Connectを使うにはSAP側でSAP Business Data Cloudの契約が前提になります。BDCはCapacity Unit（CU）ベースの月額課金で、3〜36カ月契約が基本です。Fabric側もCapacityの契約が必要で、両方が揃わないと連携が成立しません。

Mirroring for SAP Datasphereを使う場合は、SAP Datasphere契約とその上のPremium Outbound Integrationライセンスが必要です。Fabric側はCapacity内で無料枠がありますが、SAP側の課金は別途発生します。

認証統合—Entra ID × SAP Cloud Identity Services

SAPとMicrosoft両プラットフォームでIDガバナンスを一元化する場合、SAP Identity Access Governance（IAG）とMicrosoft Entra IDのend-to-end連携が現在Previewで提供されており、SAP業務ロールをEntraのaccess packageから配布できる設計になっています。

SAP Cloud Identity Services（SCI）の統合は当該Preview利用時の前提で、シングルサインオン（SSO）の構成は任意です。

BDC ConnectやMirroringを先行導入する場合、認証統合を後回しにするとユーザー管理と権限監査が二重化して運用負担が増える構造になります。ガバナンス一元化を狙うなら、データ連携より先に整理しておく方が結果的に短距離です。

リアルタイム性 vs バッチの分岐点

「SAPデータをFabricで使う」と一口に言っても、必要な鮮度は業務によって大きく違います。月次会計レポートなら1日1回のバッチで十分ですが、営業ダッシュボードや在庫アラートは分単位が必要になるケースがあります。

Mirroring for SAP Datasphereは継続レプリカで「ほぼリアルタイム」に近い鮮度を出せますが、SAP DatasphereのReplication Flow設定と、Fabric Capacityの余裕がボトルネックになる場合があります。BDC Connectの双方向ゼロコピーは共有側の更新に対してより即時性が高い設計ですが、GA前の段階では実運用検証データが限られています。

OPDGとネットワーク設計の要件

SAP HANA・BW・ODBCなどの組み込みコネクタを使う場合、On-premises data gateway（OPDG）が必要です。Azure上に立てても構いませんが、SAPソースの近くにネットワーク的に近接して配置する必要があります。OPDGはSAP側のライセンス制約でMicrosoft側が再配布できないSAPドライバを扱うためのコンポーネントで、これらのコネクタではAzure上のSAPシステムであってもOPDG経由が前提になります。

複数のSAPシステムを持つ場合はOPDGクラスタの冗長化や、複数リージョンをまたぐ場合の配置設計が必要になり、想定より工数が膨らむケースが出やすい箇所です。

BDC Connect GA前後のロードマップ判断

現時点でSAP × Fabric連携を新規に始める場合、「BDC Connect GAを待つか」「Mirroring/組み込みコネクタで先行するか」の判断が最初の分岐です。

BDCを既に導入している企業は、GA前後で構成が変わる前提でMirroring/ショートカットの一時運用を選ぶ選択が現実的です。

BDCをまだ導入していない企業は、BDC本体の投資判断（Datasphere・SAC・SAP Databricksを束ねる意義があるか）から評価する必要があり、Fabric連携だけを目的にBDCを追加契約する構造にはなりません。

---

導入事例—Maersk・KONE・Tibnorから見る実装パターン

SAP × Microsoft連携の代表事例を3社取り上げ、それぞれどの層の連携が中心になったかを整理します。

Maersk—500 SAPサーバー+ペタバイトを6か月でAzure移行

海運大手のMaerskは、500台のSAPサーバーとペタバイト規模のデータを6か月でAzureに移行し、near 100% uptime・zero post-migration incidents（移行後のインシデントゼロ）を達成しました。移行完了後はAzure OpenAI ServiceとSAPを組み合わせ、業務チームが請求書・出荷データを自然言語で問い合わせできる環境を運用しています。

同社のSAP Technology Platform責任者は「これは単なる移行ではなくマインドセットの転換だった。インフラを管理する側から、エンジニアリングの革新を主導する側へ移る必要があった」と発言しており、SAP資産のAzure移行が単なるインフラ更新ではなくAI活用の下地作りとして位置付けられている点が読み取れます。

Maersk事例が示すのは、Fabric連携の前段として「SAPをAzure上に置く」という選択肢の効果が大きいということです。SAP on Azure構成についてはSAP on Azureで詳しく解説しています。

KONE—Power Platform + Copilot Studioで年5.4万件超の契約処理時間を33%削減

昇降機大手のKONEは、Power Platform上に構築したAI駆動契約ワークフローで、SAPレコードとドキュメントを照合しSAP側に契約を自動生成する仕組みを運用しています。Microsoftの事例によると、年間54,000件超の契約を処理し、handling timeを33%削減しました。

さらに社内3,000名超のcitizen developerを支援するため、Microsoft Copilot Studioでガイドエージェントを構築し、プロンプト生成や既存アプリの重複回避を自動化しています。

SAPデータをFabricに集約したうえで、Copilot Studioエージェントがそこを参照する構成に将来的に発展させやすい設計です。

Tibnor—BDCの初本稼働事例

スウェーデンの鉄鋼流通企業Tibnorは、SAP Business Data Cloudの初の本稼働顧客として公表されています。
別途、SAPはベータ参加顧客からデータモデルが20〜50%改善したとのフィードバックがあったと報告しており、SAP側のデータプラットフォームとしてBDCを選ぶ実例が動き始めた状況です。

Tibnorの取り組みはまだBDC本体の稼働段階で、Fabric側との連携までは公表情報が及んでいません。BDC Connect GA後に、Tibnor同様のBDC先行導入企業がFabric側とどう繋いでいくかが、今後の実装パターンを規定していく見通しです。

事例詳細はSAP Business Data Cloudで扱っています。

事例から読み取れる3つの実装パターン

3社の事例からは、SAP × Microsoft連携の実装パターンが3つの層に整理できます。

• インフラ層（Maersk型）
  SAPをAzureに載せ、Azure OpenAI等のAI基盤と組み合わせる。Fabric連携は次段階の拡張
  
  

• アプリ層（KONE型）
  Power Platform + Copilot Studioで業務アプリを構築し、SAPと双方向連携。Fabricは分析基盤として補完
  
  

• データ層（Tibnor型）
  SAP側でBDCを整え、そこからFabric・Databricks・Snowflake等に段階的に接続範囲を広げる
  
  

自社がどの層から着手するかは、SAP資産の現状（オンプレ/Azure/RISE）と、業務側の要件（自動化重視/分析重視）で決まります。

---

SAP × Fabric連携のコスト構造と前提条件

SAP × Fabric連携のコストは、単一の課金軸で見えるものではありません。SAP側・Microsoft側の複数の課金要素を横串で並べる必要があります。

4つの課金軸の全体像

以下の表で、SAP × Fabric連携で発生する主要な課金要素を整理しました。連携パターンごとに必要な組み合わせが変わります。

課金要素	課金元	発生条件	補足
Fabric Capacity（F SKU）	Microsoft	Fabric利用時に必須	F SKUの従量課金または予約から選択。既存P SKUは新規販売終了で契約終了時にF SKUへ移行
SAP Datasphere Premium Outbound Integration	SAP	Mirroring for SAP Datasphereで発生	Datasphere契約とは別ライセンス
Capacity Unit（CU）	SAP	SAP BDC本体の利用	3〜36カ月契約、価格は問い合わせ
Microsoft 365 Copilotライセンス／Office 365 commercial subscription	Microsoft	M365 CopilotからFabric Data Agent利用時	Fabric Data Agent利用者ごとのライセンスが必要
Foundry consumption pricing	Microsoft	Foundry agent構築時	使用したモデル・トークンで従量課金
パートナー製抽出製品ライセンス	各パートナー	Theobald/SNP Glue等の利用時	製品ごとに個別見積もり

この表が示すのは、SAP × Fabric連携のコストは「Fabric側」「SAP側」「Microsoft AI側」「パートナー側」の4方向に分散するということです。稟議書や見積もり作成時は、これらを別チームが担当しているケースが多いため、初期段階で横串で並べておく必要があります。

Fabric Capacityの見積もり方

Fabric CapacityはF SKUで契約し、従量課金または予約から選びます。

既存のP SKUは新規販売を終了しており、契約終了時にF SKUへ移行する扱いです。MirroringのcomputeとOneLakeストレージは容量枠内では無料ですが、SQL Analytics EndpointやPower BI・Sparkでのクエリ実行は通常課金対象です。

Microsoft Fabric公式pricingページで最新の単価を確認し、Capacity Estimatorで必要容量を算定しましょう。

SAP側のライセンス構造

SAP Datasphere Premium Outbound Integrationは、Datasphere契約に加えて別ライセンスとして提供されます。契約単位はSAP側の営業経由での見積もりになり、公開価格はありません。

BDC本体のCU（Capacity Unit）ベース課金も価格は非公開で、3〜36カ月契約の中でSAP営業と個別に交渉する形になります。BDC Connectを使うにはBDCが前提のため、BDC自体のROIから逆算する必要がある点は先述のとおりです。

想定コストレンジの目安

Fabric Capacityの単価はリージョン・SKU・予約条件で変わるため、公式pricingページで最新値を確認してください。SAP側のBDC・Datasphere Premium Outbound Integrationは要問い合わせのため、初期見積もり時にはSAPパートナーやSAP直販への確認が必須です。

パートナー製抽出製品は、製品構成・接続数・CDC要件に応じた個別見積もりが基本で、公開単価はほぼありません。

---

SAP × Fabric連携で詰まった論点を、実装事例から逆算して整理する

SAP × Fabric連携を検討する現場では、BDC Connect GAを待つかMirroring・組み込みコネクタで先行するかの分岐、4接続オプション（BDC Connect・Mirroring for SAP Datasphere・組み込みコネクタ+OPDG・パートナー製抽出）のどれを起点にするかの選定、Fabric Capacity・SAP Datasphere Premium Outbound Integration・BDCのCUをどう並行見積もりするか、Maersk型（インフラ層）・KONE型（アプリ層）・Tibnor型（データ層）のどの実装パターンから着手するかといった、公式ドキュメントだけでは決めきれない論点が並びます。

Entra ID × SAP IAG連携やFabric Data Agent・Foundryエージェントの業務組み込みまで含めてSAP × Fabric連携の実装可能性を棚卸ししたいなら、単体機能の解説記事ではなく、実装事例と組み合わせて話せる相手と一度整理するのが早道です。

AI Agent Hubは、SAPデータと連携する業務エージェントを含めた業務プロセスへのAI組み込みを支援するエンタープライズAI基盤で、BDC Connect・Mirroring・組み込みコネクタ・パートナー製抽出のいずれの入口からでも、実装から逆算した論点整理をご相談いただけます。

---

まとめ

• SAP BDC Connect for Microsoft Fabricは双方向ゼロコピー共有でBDCとOneLakeを直結する新機能、Q3 2026 GA予定

• 現時点で使える連携はMirroring for SAP Datasphere（2026年3月GA）・組み込みコネクタ+OPDG・パートナー製品の3系統で、多くの企業では並行運用が現実解

• 判断で見落としやすいのはFabric Capacity・Datasphere Premium Outbound Integration・CUの3課金軸を並行見積もりする必要がある点と、IDガバナンス一元化を狙う場合はEntra ID×SAP IAG連携（Preview）を先に整えるべき点

SAP × Microsoft Fabric連携は2026年後半に大きな節目を迎えますが、BDC Connect GAを待つだけでなく、Mirroringや組み込みコネクタで段階的に着手できる状態にあります。自社のSAP資産の現状と業務要件からどの層で連携を始めるかを整理し、後戻り工数の少ないアーキテクチャに落とし込むことが2026年時点の意思決定の焦点になります。