# 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 だけでも、大企業の現実は回りません。だからこそ必要なのは、併用そのものではなく、併用しても壊れない境界設計です。