SAP on Azureとは？構成例・メリット・オンプレ比較を徹底解説

SAP on Azureとは、SAP ERP・S/4HANA・SAP HANAといったSAPワークロードをMicrosoft Azure上で稼働させるための、認定済みインフラとAzureネイティブ運用サービスを組み合わせた統合スタックを指します。
単なる「AzureのVMでSAPを動かす構成」ではなく、SAP HANA認定Mv3 VM・Azure Center for SAP solutions・Microsoft Sentinel for SAPまでを含む、SAP専用に最適化されたレイヤー全体が対象です。

2027年のECC標準保守終了とRISE with SAP on Azure枠の倍増を背景に、いまSAP on Azureは「どの契約経路で入り、どの構成を選び、どうAI連携まで届かせるか」の判断が迫られる領域になっています。

本記事では、SAP on Azureの定義と3つの提供経路、SAPが選ばれる背景、アーキテクチャとHANA対応VMシリーズ、契約経路と判断論点、移行の進め方、料金構造、セキュリティ、導入事例、SAP Sapphire 2026の発表内容までを、2026年7月時点の最新情報で体系的に整理します。

SAP on Azureとは？SAPワークロードをMicrosoft Azureで動かす統合スタック

SAP on Azureとは、SAP ERP・SAP S/4HANA・SAP HANAといったSAPワークロードを、Microsoft Azure上で稼働させるための認定済みインフラと運用サービスを組み合わせた統合スタックです。

SAP側とMicrosoft側の両方から公式認定を受けた仮想マシン・ストレージ・ネットワーク構成を土台に、Azure Center for SAP solutions（ACSS）やMicrosoft Sentinel for SAPといったAzureネイティブサービスがSAP専用に組み込まれています。

2026年現在、SAP on Azureは「SAPをクラウドに載せ替える基盤」から、SAPとMicrosoft Fabric・Microsoft Copilot・Microsoft Entra IDを接続するAzureネイティブ統合層として再定義されつつあります。

Microsoftはこれを "SAP as a first-class workload"（SAPを最上位のワークロードにする）と位置づけ、Azure公式ドキュメントでも他のIaaS利用とは切り分けて扱っています（Microsoft Learn: 利用可能な SAP on Azure オファリング）。

SAP on Azureの現代的な役割——3つの提供経路

SAP on Azureは「1つの製品」ではなく、SAPとAzureをどこで接続するかで3つの提供経路に分かれます。

• BYOC（Bring Your Own Contract）
  自社のAzureサブスクリプションで、SAP認定VM・ストレージを組み合わせて自らSAPを構築・運用する方式。統制と拡張性を最大化できる古典型の選択肢
  
  

• RISE with SAP on Azure
  SAPが「ソフトウェア・インフラ・マネージドサービス」を1本の契約に束ねて提供する方式で、AzureはSAP側から見た標準リージョンとして選ばれる。SAP責任範囲が広く運用負荷が軽い
  
  

• SaaS（SAP S/4HANA Cloud Public Edition）
  SAPが完全マネージドで提供するS/4HANA Cloud。裏側のクラウドは意識せず、業務側の標準寄せに集中できる形

ここでのポイントは、「どこまでSAP側に任せ、どこから自社Azureで統制するか」がSAP on Azureを語るときの中心軸になった、という点です。

RISE以前は「Azure上にSAPを立てる＝BYOC」がSAP on Azureの実体でしたが、2020年代後半に入って選択肢が階層化し、契約経路そのものが最初の判断ポイントになりました。

---

SAP on Azureが選ばれる理由——2027年問題と2026年のRISE拡大

SAP on Azureは、2026年に入って「選ばれる」というより「決めざるを得ない」領域に変わってきました。

背景には、SAP側の2027年問題、SAP Sapphire 2026でのRISE with SAP on Azure拡大発表、そしてAzure側でのSAP専用サービス層の充実という3つの動きが同時に走っている状況があります。

ここでは、企業がSAP on Azureを本格検討するに至る具体的なTriggerを3つ整理します。

1.ECC 6.0 標準保守が2027年末に終了する

もっとも大きなTriggerは、SAP ERP 6.0（ECC 6.0）のメインストリーム保守が2027年末で終了することです。

SAPは2030年末までの延長メンテナンスオプションを提示しており、その先の**2031〜2033年は「SAP ERP, private edition, transition option」**という、オンプレ保守の単純延長ではなくRISE with SAPへの移行を前提とした過渡措置として案内されています（SAP Maintenance Strategy）。

これは「S/4HANAへ移すか、既存ECCで延命するか」という単一の話ではなく、「移すならどのインフラで移すか」まで含めて期限内に決める必要があるという制約になっています。

オンプレでの再構築は工期・投資額・運用体制のどれを取っても現実的でないケースが増え、Azure・AWS・GCPといったハイパースケーラを前提としたSAP移行の議論が定着しました。

2.RISE with SAP on Azure枠が2026年に倍増した

2つ目のTriggerは、RISE with SAP on Azureに関するSAPとMicrosoftの共同プログラム拡大です。

SAP公式は2026年5月に、RISE with SAP on Microsoft Azure Initiativeの参加顧客枠を、2026年中に現状の2倍以上に拡大すると発表しました（SAP News Center）。

参加顧客はMicrosoft Cloud Accelerate Factoryへのアクセスを無償で得られ、SAPスキルを持つMicrosoft側の製品エンジニア・クラウドソリューションアーキテクト・サポート専門家が、移行と本番運用にかけて張り付く体制になります。

すでにNestlé・Migros・Samsungといった大規模ユーザーが同プログラムで動いており、2026年は「まだ枠が空いているうちに手を挙げる」フェーズになっています。

3.Azure側にSAP専用の運用スタックが揃った

3つ目は、Azure側でSAPワークロード専用の管理・監視・セキュリティスタックが揃ったことです。

以下の表で、2025〜2026年にかけてGAまたは大規模アップデートを迎えた主要サービスを整理しました。

サービス	ステータス（2026年7月時点）	役割
Azure Center for SAP solutions	GA	SAPシステムをAzureネイティブに登録・監視・ライフサイクル管理
SAP Deployment Automation Framework（SDAF）	2026 H1 大規模GA更新	インフラをコードで自動プロビジョニング
SAP Testing Automation Framework（STAF）	2026 H1 大規模GA更新	SAP変更のテスト自動化
Microsoft Sentinel for SAP	エージェントレスコネクタGA、検出カタログ拡充（一部Preview含む）	SAPログを Azure SIEM で監視
Joule × Microsoft 365 Copilot 統合・A2A連携	Sapphire 2026発表・展開中	業務ユーザーがCopilot経由でSAPデータを操作

この揃い方から見えるのは、Azureがもはや「SAPのVMを載せる場所」ではなく、SAPの運用・監視・AI連携までを一体で提供する基盤に進化したという点です。

Trigger 1（保守期限）で意思決定を迫られ、Trigger 2（RISE拡大）で移行支援体制が整い、Trigger 3（運用スタック充実）でクラウド化後の実装難易度が下がる——この3つが噛み合ったのが、いま SAP on Azure の検討が加速している構造的な理由です。

---

SAP on Azureのアーキテクチャ構成とHANA対応VMシリーズ

SAP on Azureのアーキテクチャは、単純化すると**「インフラ層・SAP実行層・Azureネイティブ運用層・統合層」の4層構造**で捉えられます。

以下の表で、各層に配置される代表サービスとその役割を整理しました。

層	代表サービス	役割
インフラ層	Azure Virtual Machines（Mv3・Mv2・M系）、Azure NetApp Files、Azure Managed Disks、ExpressRoute	SAP認定VM・共有ストレージ・オンプレ接続
SAP実行層	SAP HANA、SAP NetWeaver、SAP S/4HANA、SAP BTP	ERP本体とアプリケーション基盤
Azureネイティブ運用層	Azure Center for SAP solutions（ACSS）、Azure Monitor for SAP solutions、Azure Backup、Azure Site Recovery	SAP専用に設計された運用サービス
統合層	Microsoft Entra ID、Microsoft Fabric、Copilot Studio、Power Platform	認証・分析・AI連携でMicrosoft製品と横串

実務で選定が問われるのは主にインフラ層のVM選定とAzureネイティブ運用層の適用範囲の2つです。

SAP HANA対応の主要VMシリーズと選定基準

Azureは、SAP HANAワークロード向けにM系のVMシリーズを複数世代にわたって認定しています。2026年7月時点の主要ラインナップは以下のとおりです。

• Mbsv3 / Mbdsv3シリーズ
  第4世代Intel Xeonスケーラブル（Sapphire Rapids）ベース。16〜416 vCPU・128〜約3,800 GiBメモリ。SAPアプリケーション層と中規模HANAに適合
  
  

• Msv3-MM / Mdsv3-MM（Medium Memory）
  12〜176 vCPU・240〜3,892 GiBメモリ。前世代Mv2比で最大25%のネットワーク性能改善。中規模〜大規模HANAの主力
  
  

• Msv3-HM / Mdsv3-HM（High Memory）
  416〜832 vCPU・5,696〜15,200 GiBメモリ。単一VMで最大約16TB。大規模HANA向けのハイエンドライン
  
  

• Mdsv3-VHM（Very High Memory）
  896〜1,792 vCPU・30,400 GiBメモリ。単一VMで最大約32TB。従来はHANA Large Instanceでしか到達できなかった容量を通常VMで賄える形
  
  

• HANA Large Instance（HLI）
  専用物理サーバーによる大規模構成。スケールアウトでTDIv5認可時120TBまで対応。ただし新規はMv3への切り替えが基本方針

選定の実務基準は「HANAデータフットプリント×高可用性要件×既存ライセンス資産」の3軸で、4TB以下はMbsv3系、4〜16TBはMsv3-HM系、16TB超はMdsv3-VHMまたはHLI継続というのが2026年時点の典型解です。

各シリーズの詳細スペックはMicrosoft LearnのMファミリ VMサイズシリーズを参照してください。

Azureネイティブ運用層——ACSSとAzure Monitor for SAP

Azureネイティブ運用層で中心になるのが、Azure Center for SAP solutions（ACSS）です。

ACSSは、SAPシステムをAzureのファーストクラスワークロードとして登録し、インフラプロビジョニング・構成チェック・パフォーマンス監視・ライフサイクル管理をAzure Portal上で完結させるためのマネージドサービスです（Microsoft Learn: Azure Center for SAP solutions）。

Azure Monitor for SAP solutionsは、これに補完的な位置で、SAP固有のメトリクス（ダイアログレスポンスタイム・データベースキャッシュヒット率等）をAzure Monitorのダッシュボードに統合します。

実務で押さえるべきは、この2つがBYOC（自社管理のSAP on Azure）でのみサポートされ、RISE / ECS環境ではサポートされないという点です。

Microsoft公式は「Azure Monitor for SAP solutions と Azure Center for SAP solutions は、RISE / ECSでSAPが管理するSAPランドスケープではサポートされない」と明記しています（Microsoft Learn: Identity and security in Azure with SAP RISE）。

RISE契約では、監視と運用の大部分がSAP責任範囲に含まれるため、企業側から見た「Azureネイティブ運用層を自社で組む」領域は、周辺の非SAPシステムや連携アプリに限定されます。

---

SAP on Azureの契約経路と導入判断で迷う論点

SAP on Azureの意思決定は、インフラ選定より先に契約経路の選定で迷うケースがほとんどです。

読者が実務で最も判断に迷うのはここです。BYOC・RISE・SaaS（S/4HANA Cloud Public）のどれで入るかは、責任分界点・カスタマイズ余地・投資回収期間のすべてに影響します。

以下の表で、3経路の実務的な違いを整理しました。

論点	BYOC	RISE with SAP on Azure	SaaS（S/4HANA Cloud Public）
SAP側の責任範囲	ライセンスのみ	インフラ・OS・DB・SAP Basis運用	アプリ含む全体
Azureサブスクリプション	自社契約	SAP側テナント	意識不要
カスタムコード	フル対応	Clean Coreの範囲で対応	拡張はSAP BTPに寄せる
業務変更余地	低〜中	中	高（標準寄せ前提）
責任分界の明確さ	高い	一部曖昧	明確
初期コスト	高い	中程度	低い
契約単位	個別	サブスク（FUE）	サブスク

この整理から実務で見えてくるのは、「既存アドオン量」と「業務変更の許容度」が経路選定の主要因になる、という点です。

以降、実案件で頻繁に議論になる3つの論点を掘り下げます。

1.RISEとBYOCのどちらが自社に合うか

議論の焦点は「運用負荷とコントロールのどちらを取るか」です。

RISEはSAPが責任範囲を広く持つため、社内SAP Basisチームを縮小したい企業に向きます。一方で、Azure側の細かい統制（ネットワーク境界・Sentinel監視ルール・カスタムログ収集）は自社の意思では組みにくくなります。

BYOCは逆に、Azure環境の設計自由度が高い一方、SAP Basis・HA/DR・パッチ運用のすべてが自社責任です。社内にAzureとSAP両方のスキルセットが揃っている企業でないと運用回避が起きにくいという現実的な壁があります。

AI総研の支援経験でも、SAP Basisチームが3名以下ならRISE、10名超で自社Azure運用が安定しているならBYOCという線引きが目安になります。

2.ECCから直接S/4HANA Cloudに飛ぶか、S/4HANA on Azureを経由するか

2つ目は移行方式の話です。

ECCのカスタムコードが数百本規模ある企業では、S/4HANA Cloud Public Editionへの直接移行は業務側の再設計コストが跳ね上がります。この場合、まずS/4HANA on Azure（BYOCまたはRISE）で移行→数年運用→SaaSへ最終的に寄せるという2段構えが現実的です。

一方、アドオンが50本未満・業務標準寄せに積極的な企業では、SAP S/4HANA Cloud Publicへ直接移行する選択が投資対効果で有利になります。

この判断は「アドオン棚卸し」を最初にやらないと成立しません。SAPのSignavioやSAP Cloud ALMを使うと、既存カスタムコードのClean Core適合状況を可視化できます。

論点3: カスタムコードとアドオンをどこまで残すか

3つ目は、既存のABAPコード・アドオンの扱いです。

SAPはClean Core戦略で「業務ロジックをSAP BTPやSAP Build Codeに寄せ、ERPコアを標準に保つ」方針を打ち出しています。RISE on AzureでもSaaSでも、この方針から外れたカスタムは保守負担がSAPと自社の両方で増える結果になります。

「残す」判断をするなら、そのコードが業務差別化に本当に効いているかを1件ずつ点検する工程が要ります。競合他社も同じERPを使っている以上、標準機能で置き換えられる差別化は差別化ではありません。

AI総研の実務観察では、アドオン100本のうち業務差別化に直結するのはせいぜい20〜30本というのが実感で、残りは標準寄せ・BTP移設・単純廃止のどれかに寄せるのが2027年問題を乗り切る現実解です。

---

SAP on Azureへの移行の進め方——アセスメントから本番切替まで

SAP on Azureの移行は、「アセスメント→パイロット→段階移行→本番切替」の4フェーズで組むのが標準です。

一気に本番切替を狙う「ビッグバン移行」は、SAP案件では規模的にほぼ選ばれません。RISE契約であってもBYOCであっても、段階を踏んで検証しながら進めるのが基本形です。

以下、各フェーズの実務ポイントを整理します。

フェーズ1: アセスメント（2〜4か月）

現行SAP環境の棚卸しと、Azure側の適合性検証を並行して行います。

• SAP側
  アドオン一覧・データ量・インターフェース連携先・SAP Notes適用状況・HA/DR要件の可視化
  
  

• Azure側
  SAP Migrate Toolkit・Azure Migrateを使ったサイジング推定、対象VMシリーズと必要ストレージ性能の絞り込み

この段階の成果物は「移行方式（Rehost / Replatform / Refactor）・目標構成・必要リソース見積もり・スケジュール」の4点セットで、この整理が甘いままパイロットに入ると必ず手戻ります。

フェーズ2: パイロット移行（2〜3か月）

対象を1システム（開発機、または小規模非本番機）に絞り、Azure上に構築して動作検証を行います。

パイロットではSAP Deployment Automation Framework（SDAF）を活用し、Bicep/TerraformベースでインフラをコードとしてプロビジョニングするのがAzure Well-Architected準拠の進め方です。

2026年上半期のSDAF大規模GA更新では、GitHub Actionsがファーストクラスのデプロイパスとしてサポートされ、Azure DevOpsと並列で選べるようになりました（Microsoft Tech Community: SAP on Azure Sapphire 2026 announcements）。

フェーズ3: 段階移行（3〜9か月）

品質保証機（QAS）、次に本番機の順で移していきます。

段階移行の要点は、業務停止時間（カットオーバーウィンドウ）の設計です。Nestléは1PBを超えるデータ移行を「ビジネス中断ほぼゼロ」で実行しており、停止時間を最小化する並行運用設計がその実現の中核にあります。

SAPの標準ツールSUM DMOに加え、Azure側ではAzure Storage Moverによる大容量データ転送、Azure ExpressRouteによる高速専用線で、この設計難度を下げられます。

フェーズ4: 本番切替と切替後運用

本番切替は数時間〜数日単位のカットオーバーウィンドウで実施します。切替後は、BYOC構成であればAzure Center for SAP solutionsとAzure Monitor for SAP solutionsによる継続的な監視、SAP Testing Automation Framework（STAF）による回帰テストの自動化が肝になります。RISE構成では監視の中核をSAP側が担うため、企業側の運用対象は連携アプリ・周辺インフラ側にシフトします。

2026年上半期のSTAF大規模GA更新では、スケールアウトHANAのHSR構成テスト対応やAzure Backupのバリデーション機能が追加され、切替後の回帰テストの自動化範囲が広がりました。

ここまで4フェーズを通しで見ると、「SDAF・STAF・ACSS」の3ツールが移行と運用のバックボーンになっているのが2026年時点の実務像です。

---

SAP on Azureの料金・コスト構造

SAP on Azureの料金は、「Azureインフラ費用・ストレージ費用・ネットワーク費用・SAP側ライセンス費用」の4層構造で捉えるのが実務の基本です。

以下の表で、それぞれの層とコスト最適化の主要オプションを整理しました。

費用層	主要コスト要素	コスト最適化オプション
Azureインフラ	Mv3・Msv2・M系VMの時間課金、ACSS・Azure Monitor for SAP	Reserved Instance（1年・3年）、Savings Plan、Azure Hybrid Benefit
ストレージ	Premium SSD v2、Azure NetApp Files、Managed Disks	ストレージ階層設計、スナップショット保持期間の見直し
ネットワーク	ExpressRoute、Virtual Network、外部下り通信	ExpressRouteポート集約、Azure Firewallのルール最適化
SAP側ライセンス	SAPシステムライセンス、RISEサブスクリプション（FUE）	Clean Core適合によるアドオン削減、FUE換算最適化

この4層で最も削減余地が大きいのはAzureインフラ層で、Reserved Instanceの3年コミットメントを使うと通常のPay-As-You-Goに対して最大約72%の割引が公式に提示されています（Azure予約とは）。

Azure Hybrid Benefitは、既存のWindows Server・SQL Server・SUSE・RHELライセンスをAzureに持ち込むオプションで、OSライセンス費用を大幅に節約できます。SAPワークロードで使うRHEL for SAP Business Applicationsも対象です。

料金試算の基本手順

SAP on Azureの初期試算は以下の3ステップで進めるのが実務標準です。

• サイジング推定
  現行SAP環境のCPU・メモリ・IOPS・ネットワーク帯域を計測し、SAP Quick SizerまたはAzure Migrateで対応VMシリーズを推定
  
  

• VM料金の計算
  Azure料金計算ツールで該当VMを選択、Japan Eastリージョン価格・Reserved Instance適用時価格・Pay-As-You-Go価格を比較
  
  

• ストレージ・ネットワーク加算
  Premium SSD v2の容量・IOPS・スループット、Azure NetApp Filesの容量、ExpressRoute帯域を積み上げ、月次総額を算出

この試算はあくまでインフラ層のみで、SAP側のライセンス費用は別途SAPまたはパートナー経由での見積もりが必要です。

RISE契約の場合、Azureインフラ費用はSAP側の契約に包含されるため、企業側から見た総額は**「RISEサブスクリプション費用＋自社Azure環境（周辺システム）の費用」**という構造になります。

---

SAP on Azureのセキュリティとガバナンス

SAPは基幹業務データそのものが対象で、セキュリティとガバナンスの設計はインフラ選定と同じ優先度で扱う必要があります。

Azureは2025〜2026年にかけて、SAPワークロード専用のセキュリティ・ガバナンス機能を集中的に整えました。以下、2026年7月時点の中核サービスを整理します。

Microsoft Sentinel for SAP——SAP専用SIEM

Microsoft Sentinel for SAPは、SAPシステムのセキュリティイベントをAzure Sentinelのクラウドネイティブ SIEM に取り込む専用ソリューションです。

静的セキュリティパラメータの継続監視（公式カタログで50件超が定義され、GA/Previewが混在）や、疑わしい変更を検知したときのインシデント生成が主機能です。Sapphire 2026では、Integration Suite等の高プロファイル対象への拡張、SAP LogServ / ASIM統合の対応、SAP ETD相関の強化などがロードマップとして公表されました。

2026年に入ってエージェントレス版データコネクタがGAとなり、旧来のコンテナ版データコネクタは公式に2026年9月14日で恒久的に無効化予定・9月30日でサポート終了と案内されています（Microsoft Sentinel: What's new、SAP deployment overview）。

既存のコンテナ版利用企業は、9月14日を移行完了の実質期限として、それまでにエージェントレス版へ切り替える必要があります。

Microsoft Entra ID Governance——SAPロールの一元管理

Microsoft Entra ID Governanceは、SAPビジネスロールをEntra Entitlement Catalogに公開して、アクセス権のライフサイクルをEntra側で一元管理する機能です。

SAP Identity Access Governance（IAG）との統合が2026年5月時点でPublic Preview、SCIコネクタはGA、SCIM 2.0対応・OAuth 2.0ベース認証・Account Discovery機能がリリースされました。

SAPユーザーの棚卸し・SoD（職務分掌）チェック・アクセスレビューをEntra側でまとめてやりたい企業にとって、この統合はセキュリティ運用の一体化を大きく前進させます。

SAPとMicrosoftサービスのOAuth 2.0ベース統合

SAPシステムとExchange Online・Microsoft Graph等のMicrosoftサービス間の認証は、Basic Authenticationの廃止を受けてOAuth 2.0ベースの構成が利用可能・推奨に切り替わっています（Microsoft Learn: Exchange Online Integration for Email-Outbound from SAP ABAP Platform）。

SMTP OAuth 2.0によるSAP→Exchange Online間のパスワードレス送信、SuccessFactors OData APIのOAuth対応などが具体パスとして案内されており、SAPシステムのパスワード漏洩リスクを構造的に減らす選択肢が揃ってきています。

Azure Key Vault・Defender for Cloud

このほか、Azure Key VaultによるSAP暗号化キー・DB接続文字列の一元管理、Microsoft Defender for CloudによるSAPワークロード固有の脅威検出・コンプライアンス評価が、標準の構成要素になっています。

これらを組み合わせると、SAPシステムのセキュリティ運用は**「SAP側だけで完結せず、AzureのSIEM・ID管理・鍵管理と横串でつながる形」**が2026年時点の到達点です。

---

SAP on Azureの導入事例

SAP on Azureの実導入は、グローバル大企業から日本国内の製造業まで規模と業種を問わず広がっています。

以下では、公式に事例として公表されている代表的な企業を4社整理します。

企業	業界	導入内容	主な成果
Nestlé	食品	RISE with SAP on Azure、S/4HANAを185か国で運用、1PB超データ移行	稼働率99.97%、重大インシデント80%削減、問題解決時間40%短縮
Microsoft社内	ソフトウェア	自社ERPをSAP S/4HANA Cloud private editionへ、Azure上のRISEで運用	SAPの本番ワークロードを自社Azure基盤で運用するdogfooding事例
横河電機	計測制御	ECC 6.0基幹システムをAzure移行、業務影響ゼロで実現	大規模基幹移行で無停止運用を達成
日本発条（NHK Spring）	自動車部品	SAP ERPフルモジュールをAzureへ移行、FUJITSU Hybrid IT Service経由	TCO30%削減、DR構成で事業継続を確保

この4事例に共通するのは、「段階移行・停止時間の最小化・パートナー支援の組み合わせで、大規模移行のリスクを抑えている」という点です。

使うツールは案件ごとに異なりますが、SDAF/STAF・SUM DMO・Azure Migrate等の自動化スタックが候補として揃っています。

Nestléの1PB移行——RISE with SAP on Azureの旗艦事例

Nestléは、6つのオンプレデータセンターに分散していたSAP環境をAzureのRISE with SAPで統合しました（Microsoft Customer Story: Nestlé Azure）。

• 移行規模: 1,200TB超のデータ、200以上のSAPインスタンス、10,000台以上のサーバー、185か国での運用
• 成果: 稼働率99.97%、重大プラットフォームインシデント80%削減、問題解決時間40%短縮、停止時間を6時間から数分に削減
• AI活用: 予測分析による障害予測、機械学習による自動化タスクの補助（生成AI連携の具体構成はNestlé側では公表されていない）

Nestléは1PB規模のSAP環境をほぼビジネス中断ゼロで移行した事例として、RISE with SAP on Azureが「本当に大規模SAPを支えられるインフラなのか」への回答になっています。

Microsoft社内——RISE on Azureのdogfooding

Microsoftは自社のSAP ERP環境をSAP S/4HANA Cloud private editionへ移行するプロジェクトを推進し、その基盤としてAzure上のRISE with SAPを採用しました（EnterpriseZine報道）。

自社製品を自社で使うdogfooding事例として、Microsoft自身が「RISE on Azureの現場適用可能性」を示している位置付けになります。

横河電機・日本発条——日本国内の代表事例

国内でも大企業のSAP on Azure事例が積み上がっています。

横河電機はSAP ERP（ECC 6.0）をベースに構築した基幹システムのAzure移行を、業務影響ゼロで完了させたとJBS導入事例で公表しています。

日本発条は富士通のFUJITSU Hybrid IT Service for Microsoft Azure経由でSAP ERPフルモジュールをAzureに移行し、TCO30%削減とDR構成による事業継続を実現しました（JSUG 日本発条事例）。

富士通は日本マイクロソフト主催のパートナー表彰で「SAP on Azureアワード」を3期連続受賞（2019〜2021）、2024年には「SAP RISE on Microsoft Cloud」部門で受賞するなど、日本国内でのSAP移行パートナー実績を積み上げています。

---

SAP on Azureの2026年最新動向——SAP Sapphire 2026発表まとめ

SAP on Azureの現在地を把握するうえで、2026年5月に開催されたSAP Sapphire 2026での共同発表は外せません。

MicrosoftとSAPは、2025年からの「autonomous enterprise」構想を具体化するかたちで、AI/Data・Infrastructure・Management・Security・Migrationの5カテゴリで新機能・GA・ロードマップを一斉発表しました（Microsoft Tech Community: SAP on Azure Product Announcements Summary – SAP Sapphire 2026）。

SAP Business AI PlatformとMicrosoft IQをA2A・Zero-Copy Data Sharing・Foundationで接続する統合像（出典：Microsoft Azure Blog）

Microsoft Azure Blogが示すこの2列構造が、Sapphire 2026発表の全体像です。左側はSAP Business AI Platform——SAP Joule Studio・SAP AI Agent Hub・SAP Business Data Cloud・SAP Knowledge Graph・SAP Integration Suite・SAP Identity (IAS)の6要素。

右側はMicrosoft IQ——Copilot Studio・Microsoft Foundry・Agent 365・Microsoft Fabric・Azure Databricks・Microsoft Teams・Microsoft Entra IDの7要素。両者は上段「A2A（Agent-to-Agent）」でエージェント間連携、中段「Zero-Copy Data Sharing」でデータ層連携、下段「Foundation」でID・基盤層連携という三段の接続レイヤーで結ばれる、というのがMicrosoftとSAPの共同アーキテクチャです。

以下、5カテゴリの発表内容を整理します。

AI/Data——SAP Business Data Cloud Connect for Fabric

最大の発表は、SAP Business Data Cloud（BDC）Connect for Microsoft Fabricです。

• 提供時期: 2026年下半期
• 機能: SAPデータをFabricに双方向・ゼロコピー・デルタ共有する統合方式
• リージョン: 2026年5月末までにBDCが日本Azureリージョンで提供開始、6月にドイツ追加、2026年末までにAzure 13リージョンへ拡大

これによりSAPの業務データをFabric側で扱う際の、従来のETL・データパイプライン構築コストが大きく圧縮されます。

加えて、SAP JouleとMicrosoft 365 Copilotの統合、およびエージェント間連携（Agent-to-Agent, A2A）がSAP Sapphire 2026で発表されました（Microsoft Azure Blog: SAP Sapphire 2026 announcements）。

ODataやMCPといった標準インターフェースを、Copilot Studio + SAP構成としてSAP BTP／SAP Integration Suite（MCP Gateway含む）やAzure API Managementなどの構成で扱う実装パターンも整理されつつあり、Copilot Studio・M365 Copilot側からSAPを扱う経路が具体化してきているフェーズです（GAスコープと利用可能プランは製品ごとに時期・条件が異なるため個別確認が必要）。

Infrastructure——SDAF/STAF大規模GA更新

SAP Deployment Automation Framework（SDAF）とSAP Testing Automation Framework（STAF）の両方で、2026年上半期は同フレームワーク発足以来最大のリリースサイクルとなりました。

• SDAF: GitHub Actionsがファーストクラスのデプロイパスに（Azure DevOpsと並列）、Azure App Configuration統合、HANA scale-out with Pacemaker/HSR対応、RHEL 10・OracleLinux 9・新SLES対応
• STAF: スケールアウトHANAのHSRテスト対応、Azure Backupバリデーション機能、Configuration Checks統合

これによりSAP on Azureのインフラ管理は、Azure DevOps派とGitHub Actions派のどちらのCI/CD文化にも自然に組み込める形になりました。

Management——Entra ID Governance × SAP IAG

Microsoft Entra ID GovernanceとSAP Identity Access Governance（IAG）の統合がPublic Previewに、SCIコネクタがGAに移行しました。

• SAPビジネスロールをEntra Entitlement Catalogに公開
• SCIM 2.0対応、OAuth 2.0ベース認証
• Account Discovery機能によるSAP ID可視化

Observability Dashboardの強化として、セキュリティ・ネットワーク・インフラのダッシュボード統合、VNetピアリング状況表示、Azure Files設定可視化も追加されました。

Security——Sentinel for SAP機能拡張

Microsoft Sentinel for SAPは、エージェントレスデータコネクタのGAと検出カタログの拡充（一部Previewを含む）、Integration Suite等の高プロファイル対象への拡張が発表されました。

認証面では、SAP ABAP PlatformからExchange Onlineへの送信でOAuth 2.0が利用可能になり、Basic Authentication廃止に伴ってOAuth 2.0ベース統合が推奨されるようになりました。

SuccessFactors OData APIのOAuth対応も同じ流れで、SAPシステムのパスワードレス送信・パスワードレス連携の構成が現実解として提示されています。

Migration——RISE on Azure枠倍増とCloud Accelerate Factory

Migrationカテゴリの目玉は、既に述べたRISE with SAP on Microsoft Azure Initiativeの参加枠倍増と、Microsoft Cloud Accelerate Factoryの無償提供です。

顧客事例として、Maerskは500 SAPサーバー・1PBデータ移行を6か月・稼働率ほぼ100%で完了させ、移行後はAzure OpenAI連携によるSAPデータへの自然言語クエリまで展開したと公表されています（Microsoft Customer Story: Maersk）。

2026年7月時点でSAP on Azureの発表項目は、GA済み・Public Preview・ロードマップ予定が混在するフェーズにあります。

整理すると、SDAF/STAF大規模GAとSentinel for SAPのエージェントレスコネクタGAは本番運用に載っている段階（Sentinelの検出カタログは一部Preview含む）、SAPとMicrosoftサービス間のOAuth 2.0連携は利用可能・推奨として案内、Entra ID Governance × SAP IAG統合はPublic Preview、BDC Connect for Microsoft Fabricは2026年後半（Q3）予定、BDCのAzureリージョン拡大は2026年末までに13リージョン予定、というのが公式提示の時間軸です。

移行計画はこの状態差を織り込んで組む必要があります。

---

SAP on Azureの基幹データを業務Agent運用まで届けるなら

SAP on Azureで基幹インフラを整えた次の課題は、経費精算・請求書処理・購買承認を日常の業務アクションまで届かせることです。Sapphire 2026の「Save the bAIkery」デモは、Microsoft 365 Copilot・Azure OpenAI・SAP S/4HANA・SAP Jouleを跨いで発注実行までを1画面で扱う構図を示しました。

Microsoft 365 Copilot・Azure OpenAI・SAP S/4HANA・SAP Jouleを跨いだエージェント業務シナリオデモ（出典：Microsoft Azure Blog）

こうしたSAP × Copilot × Jouleの構図を自社Azureテナント内で組み立てる選択肢の1つが、AI総合研究所のAI Agent Hubです。

• SAP Concur/SAP HANA連携で業務Agentが直接参照 — 経費申請・請求書受領・自動入力AgentがTeamsから承認まで完結する構成
• 9種の業務Agentが経費精算・請求書処理・購買承認をカバー — 経費申請/経費仕分け/請求書受領/AI-OCR/自動入力が実在Agentとして対応
• 自社Azureテナント内で完結・SAP監査要件と同じ境界 — Azure Managed Applicationsとして実行ログで監査対応まで統制

AI総合研究所の専任チームが、SAP on Azure基盤と業務Agent運用の設計から運用まで伴走支援します。AI Agent Hubのサービスページで詳細をご確認ください。

---

まとめ

SAP on Azureは、2027年問題・RISE拡大・Azureネイティブスタックの充実が同時に走る2026年、意思決定の期日が明確なテーマになりました。

本記事の要点を、判断軸に沿って再掲します。

• SAP on Azureは3経路（BYOC・RISE・SaaS）に階層化されており、契約経路の選定がインフラ選定より先に来る
• Trigger は2027年問題・RISE on Azure枠倍増・Azure側のSAP専用スタック（ACSS/Sentinel/SDAF/STAF）の3点セット
• インフラ層はMv3 HM/VHMまで揃い、単一VMで32TBメモリまで到達。HANA Large Instanceの新規採用はMv3への切り替えが基本
• 契約経路の判断はアドオン量・業務変更許容度・SAP Basisチーム規模の3軸で決める
• 移行は「アセスメント→パイロット→段階移行→本番切替」の4フェーズ、SDAF/STAFで自動化範囲を最大化する
• 料金はAzureインフラ・ストレージ・ネットワーク・SAP側ライセンスの4層で捉え、Reserved・Savings Plan・Hybrid Benefitで最大72%削減余地
• セキュリティはSentinel for SAP・Entra ID Governance・OAuth 2.0連携・Key Vaultで、SAPと横串の管理体制が段階的に整いつつある
• Sapphire 2026発表はGA/Public Preview/ロードマップが混在。SDAF/STAFはGA、Sentinelはエージェントレスコネクタと検出カタログの一部がGA（他はPreview含む）、BDC Connect for Fabricは2026年後半予定、Joule×Copilot/A2A連携は展開中——状態差を織り込んで計画を組む

「SAP on Azureを選ぶかどうか」ではなく、**「どの経路で入り、どのVMシリーズで組み、いつAI連携まで届かせるか」**が2026年時点の実務の焦点です。

自社の状況に合った経路と構成の判断は、Azureの公式ドキュメント・Microsoft Cloud Accelerate FactoryやSAPパートナーの支援も活用しながら、期日から逆算して進めてください。