単なる「アドオンの器」から「拡張・統合・AI活用の基盤」へ

• SAP BTPは、突然登場した概念ではありません。その源流は、2012年のSAP NetWeaver Cloudに遡ります。
  2013年には「SAP HANA Cloud Platform（HCP）」へ名称を変えました。当時は、SAP HANAをクラウド上で活用し、ERPの外側でアプリケーション開発や機能拡張を行うための基盤として位置づけられていました。
  その後、クラウド利用の広がりや周辺ソリューションとの連携ニーズの高まりを受けて、「SAP Cloud Platform（SCP）」へ名称を変え、2021年以降は現在の「SAP Business Technology Platform（SAP BTP）」として整理されていきました。
  SAP BTPは、かつて「ERPを拡張するための技術基盤」として語られることが多かった基盤です。しかし現在は、拡張開発だけでなく、データ、統合、開発、AIを業務プロセスにつなぐための基盤として、その役割を広げています。

  なお、2026年5月のSAP Sapphireでは、この流れをさらに一歩進める発表がありました。
  SAP BTP、SAP Business Data Cloud、SAP Business AIの3つを統合し、「SAP Business AI Platform」という一つの基盤として整理する方針が示されたのです。これは、SAP BTPという名称や役割が消えるという意味ではありません。
  むしろ、これまでSAP BTPが担ってきた拡張・統合・データ活用の基盤としての役割が、AI活用を支える企業システム基盤の一部として、より重要になっていくことを示していると捉えるべきでしょう。

SAP BTPで問われる「役割」と「責任」の再整理

• SAP社は近年、「Clean core（クリーンコア）」という考え方を打ち出しています。
  ERPの中核はできるだけ標準に近い状態で維持し、必要な拡張は公開APIや拡張ポイントを活用しながら、ERP本体への影響を抑える形で実現する。これは、単にアドオンを減らすための考え方ではありません。
  将来のバージョンアップ、拡張、運用変更に対して、企業が自ら選択できる余地、すなわち「管理の自由」を確保するための考え方でもあります。

  しかし、ここで見落とされがちな変化があります。
  それは、構造をどのように分けるかという設計判断を、より明示的に持つ必要が出てきたことです。
  かつてのSAPシステム導入では、個別要件をERP内部に積み上げるアドオン開発が主流でした。設計判断は暗黙的に行われるケースも少なくなく、「とりあえずERPに入れる」という選択が現場レベルで積み重なっていました。
  しかし現在は、「ERPに残すのか、SAP BTPに切り出すのか、他のシステムと連携させるのか」という判断を、明示的に整理することが求められます。言い換えれば、暗黙の前提に依存した設計が成立しにくくなっています。
  さらに近年は、業務プロセスにAIを組み込む動きも加速しています。例えば、

• といった活用を考える場合、AI単体では完結しません。
  ERPに蓄積された業務データ、外部システムとの連携、権限管理、利用ログ、業務プロセスへの組み込みをあわせて設計する必要があります。
  この接続点を整理するうえでも、SAP BTPの位置づけは重要になります。

なぜSAP BTPは「使いどころ」が見えにくいのか

• SAP BTPがしばしば捉えにくいと言われる理由は、機能の多さや複雑さだけではありません。
  SAP S/4HANAのように「会計」「販売」といった明確なモジュールを持つ製品と異なり、SAP BTPは開発・統合・データ・AIという複数の要素が揃った「道具箱」です。「何ができるか」ではなく、「どのように使うかをどう設計するか」によって価値が変わります。
  この自由度の高さが、期待と戸惑いの両方を生んでいます。

  SAP BTPは「導入すれば何かが変わる製品」ではなく、「自社の未来のアーキテクチャ（構造）をどう描くか」という方針を持ってこそ、真価を発揮する基盤です。

SAP BTPを使いこなす企業が、技術の前に「ルール」を決めている理由

• NHSが複数プロジェクトを通じて確認してきた傾向として、SAP BTPを活用できている企業には共通する特徴が3つあります。
  その違いは、単に高度な技術を保有しているかどうかではありません。

• 1ERPの内と外を、方針として決めている

  　標準機能で対応できるものはERPに残す。拡張・統合・データ活用はSAP BTP側で設計する。
  　この分け方を、プロジェクトの都度判断するのではなく、組織のルールとして維持しています。

  2「誰が決めるか」が明確になっている

  　アーキテクチャに関わる判断を、プロジェクト単位ではなく、IT部門あるいは経営レベルの方針として持っています。
  　個別案件ごとに都度議論する構造ではなく、判断の軸があらかじめ定まっています。

  3「まず動かして判断する」プロセスを持っている

  　設計方針を固めてから動くのではなく、実現性を小さく検証しながら判断を積み重ねる進め方をとっています。
  　サンプル実装や接続検証を通じて、「できるかどうか分からない」状態を早期に解消しています。

• 技術の問題を先に解こうとしている企業より、設計の判断を先に整理している企業の方が、結果的にSAP BTP活用は早く進む傾向があります。

  ここで多くの企業がつまずくのが、設計判断そのものの難しさです。
  ERPの内と外を分けるという判断は、業務責任の再定義を伴います。
  カスタマイズを見直すということは、過去の意思決定を問い直すことです。全体設計を決めるということは、組織横断の合意形成を必要とします。

  加えて、こうした設計判断は、技術的な知識だけあっても進みません。
  自社の業務実態・データの現状・拡張の経緯を踏まえながら、将来の運用まで見据えた構造を描く必要があります。
  「分かってはいるが、決められない」「方針は出たが、実装レベルに落とせない」という状況が続くのは、業務・データ・アーキテクチャ・運用を横断して見る視点と、実装レベルに落とし込む経験が求められるためです。

実践例：小さく動かし、判断材料を具体化する

• 電力・化学・製造業を含む複数の顧客プロジェクトや独自開発を通じて、NHSではSAP BTPに関する実装経験を積み重ねています。

・設計方針策定（電力業）
SAP S/4HANA再構築案件において、SAP BTPをワークフロー基盤および拡張開発の場として活用する方針を策定。
SAP S/4HANAとSAP BTP双方のアーキテクチャ策定を支援し、サンプル機能の開発も担っています。
「何をBTP上に置くか」という設計判断そのものに、上流から関与しています。

・導入前の実現性評価と検証（化学業）
SAP BTPでのアドオン開発着手に先立ち、実現性評価・接続検証・処理パターンごとのサンプル実装を実施。
ローコード開発ツールを活用し、SAP BTP実行環境への展開まで検証しています。

・SAP BTP上でのアプリケーション開発（製造業）
エンドユーザが実際に操作する業務アプリケーションを、SAP BTP上にSAP Cloud Application Programming Model（CAP）を用いて開発しています。
ERPの外側に業務アプリケーションを構築するという設計を、実装レベルで実現しています。

・独自ソリューションの開発・検証
SAP BTPの通知・連携機能を活用したワークフロー拡張機能を開発し、顧客案件への適用を見据えた技術蓄積として継続的に検証を進めています。

NHSが支援できること

• SAP BTP支援において重要なのは、単にSAP BTP上でアプリケーションを開発することだけではありません。
  まず必要なのは、現行のSAPシステムがどのような設計判断の積み重ねで構成されているのかを整理することです。そのうえで、将来の運用や変更を見据えながら、設計方針を具体的な実装判断に落とし込んでいきます。

  SAP BTPは、構想だけを描いても前に進みません。一方で、技術検証だけを積み重ねても、全体方針がなければ個別最適に陥ります。
  構想（思想）と実装（技術）は、車の両輪です。そのためNHSでは、上位方針や理想論だけで終わらせるのではなく、「実際に動くものを小さく作り、触りながら判断材料を具体化していく」という現場主義のプロセスを重視しています。

「SAP BTPを使って何ができますか？」

• この問いに答えるには、SAP BTPの機能を並べるだけでは不十分です。
  先に必要なのは、自社のSAPシステムにおいて、何をERPの中に残し、何を外側に切り出し、どの判断を誰が担うのかを明らかにすることです。
  SAP BTP活用を検討する際には、まず次の3点を確認することが出発点になります。

• NHSでは、現行SAPシステムの構造やアドオンの状況を踏まえながら、ERPの内と外をどう分けるかという判断軸づくりから支援します。