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 を「真ん中にある何か」と曖昧に呼ぶことではなく、何を制御し、どの責務を受け持つ基盤なのか を最初に定義することです。