SAP BTP と hyperscaler 原生サービス、先に決めるべきは機能差ではなく責任境界
SAP BTP を使ったエンタープライズアーキテクチャの議論では、よく「BTP に寄せるべきか」「AWS / Azure / GCP のネイティブサービスを使うべきか」という二択に落ちがちです。
ただ、この問いの立て方自体が少し雑です。実際に難しいのは、どちらが強いかを決めることではありません。どこまでを BTP の責務として持ち、どこからを hyperscaler 側に任せると長期運用で破綻しにくいか を設計することです。
この記事では、SAP BTP と hyperscaler 原生サービスの役割分担を、機能比較ではなく 責務・統制・運用境界 という観点で整理します。
先に結論
結論から言うと、基本の考え方は次の通りです。
- SAP 業務プロセスに近い拡張、統合、権限文脈 は BTP 側に寄せる
- 汎用的なデータ基盤、AI 基盤、分析基盤、インフラ運用 は hyperscaler 原生サービスを使う余地が大きい
- ただし重要なのは「どちらを多く使うか」ではなく、誰が責任を持つ境界をどこで切るか を先に決めること
つまり、
- SAP 文脈を守る層は BTP
- 汎用技術を伸ばす層は hyperscaler
- その間の境界に統制ルールを置く
の���自然です。
なぜこのテーマはすぐ雑になるのか
BTP と hyperscaler を比較するとき、多くの記事はサービス一覧を並べて終わります。
- BTP には Integration Suite がある
- AWS には Lambda や EventBridge がある
- Azure には Logic Apps や Entra ID がある
- GCP には BigQuery や Vertex AI がある
もちろん機能比較は必要です。ただし、実務で本当に困るのは「似たサービスがある」ことではありません。
困るのは、
- 権限が二重管理になる
- イベントや API の責任境界が曖昧になる
- データコピーが増えて説明責任が崩れる
- 障害時に誰がどこまで調べるのか決まっていない
という運用設計の曖昧さです。
BTP を主軸に置くべき領域
まず、BTP を主軸に置いた方がよい領域があります。
1. SAP 業務文脈を保った拡張
S/4HANA や SAP 系の業務プロセスに近い拡張では、データの意味と責任範囲を壊さないことが重要です。
例えば、
- 受注・購買・会計に近い拡張
- SAP 標準イベントを起点にした業務連携
- ユーザー権限や業務ロールを前提にした UI / ワークフロー
のような領域では、BTP の方が自然に扱えます。
理由は単純で、ここでは「技術的に動くか」よりも SAP の業務責務を保てるか が重要だからです。
2. SAP 向け統合と API ガバナンス
Integration Suite や API 管理の価値は、単に接続を増やすことではありません。SAP 側のイベント、データモデル、業務フローと矛盾しない形で統合を設計しやすい点にあります。
この領域を外に出しすぎると、接続はできても、後から見たときに「誰がどの前提で変換したのか」が見えにくくなります。
3. 権限・監査の業務側境界
特に AI や自動化が絡むと、誰の権限で、どの業務文脈のデータに触れたのかが重要になります。
この境界は、単なる IAM 設定では片づきません。SAP 側の業務ロール、承認、職務分掌と結びついているため、BTP 側で責務を持たせた方が説明しやすいケースが多いです。
hyperscaler 原生サービスを積極的に使うべき領域
一方で、何でも BTP に寄せればよいわけではありません。
1. 汎用データ基盤
大量データの蓄積、分析、ストリーム処理、データレイク運用のような領域では、hyperscaler の原生サービスが強い場面が多いです。
例えば、
- AWS の S3 / Glue / Athena / Redshift
- Azure の Data Lake / Synapse
- GCP の BigQuery / Dataflow
のような基盤は、SAP 専用というより企業全体のデータ活用基盤として設計しやすいです。
SAP データもここへ持ち込めますが、注意すべきなのは「持ち込むこと」ではなく、どの粒度で、どの責任で複製するか です。
2. AI / ML 基盤
企業 AI を考えるとき、モデル実行基盤や推論基盤は hyperscaler 原生サービスの方が柔軟なことがあります。
例えば、
- SageMaker
- Vertex AI
- Azure OpenAI / Azure ML
のような基盤は、モデル選択肢、周辺ツール、MLOps、推論スケーリングで優位なことがあります。
ただしここでも重要なのは、AI の実行場所 と 業務責任の場所 は同じでなくてよいという点です。
モデルが外にあっても、業務文脈と権限境界は BTP 側で持つ、��いう設計は十分あり得ます。
3. 基盤運用と共通インフラ
監視、ログ収集、IaC、ネットワーク制御、コンテナ運用など、企業全体で横断的に標準化したい領域では、hyperscaler 側へ寄せた方が運用が整理しやすいことがあります。
ここを BTP 単体で閉じようとすると、SAP 文脈では自然でも、企業全体の運用標準から浮くことがあります。
境界を引くときに見るべき 4 つの軸
1. 業務責務はどちらにあるか
その機能が失敗したとき、誰が説明責任を持つのかを考えるべきです。
- SAP 業務オーナーが責任を持つなら BTP 寄り
- 共通データ基盤チームやクラウド基盤チームが責任を持つなら hyperscaler 寄り
この視点がないと、機能は動いても責任が宙に浮きます。
2. 権限モデルをどこで閉じるか
BTP と hyperscaler を併用すると、最も壊れやすいのは権限境界です。
- SAP ロール
- BTP 側の認可
- hyperscaler 側 IAM
が別々に増えていくと、後から「誰が見てよいデータだったのか」が説明しづらくなります。
そのため、業務権限の起点はできるだけ 1 つに寄せるべきです。
3. データの��本はどこか
SAP データを他基盤に持ち出すときは、必ず正本と複製の関係を明確にすべきです。
ここを曖昧にすると、
- どちらが最新か分からない
- 監査時に根拠が追えない
- AI や分析結果の説明が難しい
という問題が起きます。
4. 障害時の切り分けができるか
BTP と hyperscaler をまたぐ構成では、障害時に責任の押し付け合いが起きやすいです。
そのため、
- ログはどこで集約するか
- イベントの追跡はどこまでできるか
- API 失敗時にどちらのチームが一次対応するか
を先に決めておく必要があります。
典型的なアンチパターン
アンチパターン 1: 何でも BTP に寄せる
SAP に近いからという理由で、分析基盤や AI 基盤まで全部 BTP で閉じようとすると、自由度と運用効率で無理が出やすくなります。
アンチパターン 2: 何でも hyperscaler に逃がす
逆に、SAP 業務文脈に近い責務まで全部外へ出すと、権限・監査・説明可能性が崩れやすくなります。
アンチパターン 3: 境界を決めずに両方使う
一番危ないのはこれです。BTP と hyperscaler の両方を使っているのに、
- 誰が責任を持つか
- どこが正本か
- どこで認可するか
が決まっていない状態です。
この構成は、最初は柔軟に見えて、後から必ず運用で重くなります。
まとめ
SAP BTP と hyperscaler 原生サービスの関係は、優劣の話ではありません。
- SAP 業務文脈、統合、権限、監査に近い責務は BTP
- 汎用データ基盤、AI 基盤、共通インフラは hyperscaler
- その境界に統制ルールを置く
この整理が基本になります。
重要なのは、「どちらを選ぶか」よりも どこで責任境界を切るか を決めることです。
BTP だけでも、hyperscaler だけでも、大企業の現実は回り��せん。だからこそ必要なのは、併用そのものではなく、併用しても壊れない境界設計です。