SAP BTP は中間層ではない｜AI Agent 時代に先に定義すべきアーキテクチャ上の役割

SAP BTP を説明するとき、いまだに「接続ハブ」「中間層」「連携のための平台」といった言い方で片づけるケースがあります。

もちろん、その見方が完全に間違っているわけではありません。BTP に統合や拡張の役割があるのは事実です。ただし、AI Agent、業務自動化、企業知識の検索、権限制御まで含めて考えると、この理解だけでは明らかに足りません。

いま問題になるのは、BTP が単にシステム間をつなぐ場所なのか、それとも 企業プロセス・権限・統制・実行をつなぐ制御面 として置くべきなのか、という点です。

この記事では、AI Agent 時代の SAP BTP を「中間層」という古い言い方から引きはがし、どのアーキテクチャ層として考えるべきかを整理します。

先に結論

結論から言うと、SAP BTP は単なる中間層ではありません。

むしろ現在の位置づけは、次の 4 つの境界にまたがる基盤です。

SAP コア業務の外側で拡張責務を受け持つ層
複数システムを統合し、業務フローを編成する層
AI / automation を業務権限と監査の文脈に落とす層
企業全体のデータとプロセスを安全に接続する制御層

つまり、

単なる配線の場所ではない
単なるアプリ実行環境でもない
業務と技術の境界を整える制御面として見るべき

というのが実態に近いです。

なぜ「中間層」という説明では足りないのか

従来のシステム説明では、BTP は「SAP と外部システムをつなぐ場所」として理解されがちでした。

たしかに、Integration Suite、API 管理、拡張アプリという観点では、それで説明できる部分もあります。

ですが、AI Agent や業務自動化の文脈が入ると、問題は単なる接続では終わりません。

重要になるのは、

どのデータを参照してよいのか
どの業務文脈で解釈するのか
どこまで自動実行してよいのか
どのログを残し、誰が責任を持つのか

といった統制の論点です。

このとき BTP は、ただデータを渡す中間層ではなく、業務文脈と技術実行をつなぐ制御層 として振る舞います。

BTP が担う 4 つの役割

1. 拡張責務をコアの外で受ける層

Clean Core を前提にすると、S/4HANA の中へ何でも押し込む設計は長続きしません。

そのため、業務に近いがコア本体へ持ち込みたくない責務を、BTP 側で受ける必要が出てきます。

例えば、

周辺アプリ
承認フローの補助
外部 SaaS との連携
イベント駆動の拡張処理

のような機能です。

この役割だけを見ると BTP は「外部拡張層」に見えますが、実際にはここからさらに統合や統制の役割へ踏み込みます。

2. 統合と業務編成の層

BTP は API やイベントをつなぐだけでなく、複数システムをまたぐ業務フローを組み立てる場所でもあります。

例えば、

S/4HANA
SuccessFactors
Concur
外部 CRM
DWH / 分析基盤

をまたぐとき、必要なのは単なる接続ではなく、どのイベントをどの順番で、どの業務責任のもとに流すかという設計です。

この意味で BTP は「中間」ではなく、プロセス編成の層 と見た方が正確です。

3. AI を業務文脈へ落とす層

AI Agent 時代に最も重要なのはここです。

企業 AI の難しさは、モデルを呼ぶことではありません。

難しいのは、

誰の権限で SAP データに触れるのか
どの業務文脈を前提に回答させるのか
提案止まりなのか、実行まで許すのか
監査と説明可能性をどう残すのか

を設計することです。

この責務を考えると、BTP は AI 機能を後付けする場所ではなく、AI と業務統制を接続する実行制御面 だと言えます。

Joule や AI Core、外部 LLM を使うにしても、業務権限とプロセス責任の文脈へ落とす層がなければ、本番では止まります。

4. 企業全体の制御層

BTP は SAP だけを見ていればよい基盤ではありません。

hyperscaler の原生サービス、SaaS、内製アプリと並走する中で、

どこで認証・認可を受けるか
どこで API を公開・制限するか
どこでイベントを仲介するか
どこで監査ログの責任を持つか

を整理する必要があります。

この観点では、BTP は「SAP のための中間層」ではなく、SAP を含む企業システム全体の制御境界 の一部です。

AI Agent 時代に特に誤解されやすい点

誤解 1: BTP はモデル実行基盤そのものだ

BTP は重要ですが、AI の価値はそれだけでは決まりません。

モデル実行そのものは AI Core や hyperscaler 側の基盤が担うこともあります。重要なのは、モデルがどこで動くかではなく、その出力を どの業務責任のもとで扱うか です。

誤解 2: BTP は単なる接続基盤だ

AI Agent が複数システムのデータを読むようになると、単なる接続だけでは足りません。

接続した先のデータを、どの権限で、どの文脈で、どこまで使うかを制御しなければいけません。

誤解 3: SAP の外側は全部 hyperscaler に出せばよい

これも雑です。

汎用データ基盤や AI 基盤は hyperscaler に寄せる合理性がありますが、SAP 業務文脈、拡張責務、監査境界まで全部外へ出すと、誰が責任を持つかが曖昧になりやすいです。

どう設計すると壊れにくいか

実務では、次の考え方が比較的安定します。

SAP コアに残す責務 を先に決める
BTP へ出す拡張責務 を整理する
hyperscaler / SaaS へ出す汎用責務 を切り分ける
AI の参照範囲・権限・監査経路 を BTP 側で定義する
障害時の責任境界 を運用設計まで落とす

この順番なら、BTP を「何でもできる箱」として扱わずに済みます。

まとめ

SAP BTP は、もはや単なる中間層ではありません。

拡張を受ける層
統合と業務編成の層
AI を業務文脈へ落とす層
企業全体の制御境界の一部

として理解する方が現実に近いです。

AI Agent 時代に BTP をどう置くかを間違えると、接続はできても、責任・権限・監査の設計が崩れます。

重要なのは、BTP を「真ん中にある何か」と曖昧に呼ぶことではなく、何を制御し、どの責務を受け持つ基盤なのか を最初に定義することです。