はじめに：なぜ今「SAP Build」なのか
SAP Buildは、SAP BTP（Business Technology Platform）上で提供されるローコード/ノーコード開発プラットフォームです。業務ユーザーと開発者の双方が、画面付き業務アプリ・プロセス自動化・業務ポータルをコードをほとんど書かずに作れるのが特徴です。
なぜ今これが注目されているのか（why so）。S/4HANAへの移行を進める企業の多くが、「標準機能だけでは現場の運用に足りない」「でも従来のようにコアを改修するとアップグレードで苦しむ」というジレンマを抱えています。この構造的な問題に対する回答がClean Core戦略であり、その中で「コア外で拡張する手段」として中心に据えられているのがSAP Buildです。
つまり（so what）、SAP Buildを理解しないままS/4HANAの拡張設計を進めると、気づかないうちにコアを汚してしまい、将来のアップグレードコストを自ら膨らませることになります。逆に言えば、SAP Buildを正しく使えば、現場要件を素早く満たしつつClean Coreを守れるということです。
SAP Buildの3製品｜何ができるのか
SAP Buildは単一の製品ではなく、目的別に3つの製品群で構成されています。まずは全体像を表で押さえます。
| 製品名 | 主な用途 | 作れるもの | 主なターゲット |
|---|---|---|---|
| SAP Build Apps | 画面付きの業務アプリ開発 | 在庫照会アプリ、申請画面、モバイル点検アプリ | 業務部門＋開発者 |
| SAP Build Process Automation | 業務プロセスの自動化・ワークフロー | 承認フロー、RPA、書類OCR処理 | 業務部門＋BPR担当 |
| SAP Build Work Zone | 業務ポータル・統合UX | 従業員ポータル、アプリランチャー | IT部門・人事 |
それぞれを順に見ていきます。
SAP Build Apps｜画面付き業務アプリをドラッグ＆ドロップで
Build Appsは、UIコンポーネントをドラッグ＆ドロップで配置し、データソース（S/4HANAのOData、BTPのサービス、外部API）と接続するだけで業務アプリを作れるツールです。従来であればSAPUI5/Fioriで数週間かかっていた画面開発が、数時間〜数日に短縮されるケースもあります。
なぜこれが重要か。現場で「ちょっとした照会画面が欲しい」「倉庫でiPadから入庫登録したい」という要望は日常的に発生しますが、従来はすべてIT部門に集約され、順番待ちになりがちでした。Build Appsを使えば、業務に近い人が自分で作って検証できるため、要件と実装のズレが激減します。
SAP Build Process Automation｜承認フローとRPAを1つに
Build Process Automationは、ワークフロー（承認フロー）、業務ルール、RPA（画面操作の自動化）、ドキュメント情報抽出（AI-OCR）を1つのキャンバス上で組み合わせられるツールです。
たとえば「請求書PDFが届く → OCRで金額・取引先を抽出 → ルールで承認者を判定 → 承認後にSAPへ伝票登録」といった一連の流れを、ノーコードで設計できます。従来はワークフローエンジンとRPAツールとOCRサービスが別々で、連携部分が最大の難所でしたが、それが1つに統合されたことで連携コードを書く作業自体が消えるのが大きな価値です。
SAP Build Work Zone｜散らばったアプリを1つの入口に
Build Work Zoneは、Fioriアプリ・Build Appsで作った自作アプリ・外部SaaSなどを、1つのポータルに統合する製品です。従業員から見ると「業務に関するすべての入口」になります。
so what：アプリが増えれば増えるほど「どこから入ればいいか分からない」という問題が生じます。Work Zoneがないと、せっかく作ったBuild Appsも使われないまま放置されるリスクがあります。
アーキテクチャ｜SAP Buildはどこで動くのか
SAP Buildの各製品は、BTPの上で動作し、S/4HANAや外部システムとAPI経由で接続します。これが「Clean Core」の肝です。
flowchart LR
subgraph User[利用者]
U[業務ユーザー/開発者]
end
subgraph BTP[SAP BTP]
WZ[Build Work Zone
ポータル]
BA[Build Apps
画面アプリ]
PA[Build Process Automation
自動化/RPA]
J((Joule
AIコパイロット))
end
subgraph Core[S/4HANA コア]
API[公開API/OData]
end
U --> WZ
WZ --> BA
WZ --> PA
BA --> API
PA --> API
J -.-> BA
J -.-> PAポイントは、Build製品がすべてBTP側にあり、S/4HANAコアには公開APIからしか触らない点です。これによってコアは素のまま保たれ、アップグレード時に拡張が壊れるリスクが大幅に下がります。
従来のABAP拡張との比較｜何が決定的に違うのか
既存のSAP開発者にとって、最も気になるのは「ABAPによる拡張とどう違うのか」でしょう。整理すると次の通りです。
| 観点 | 従来のABAP拡張（オンプレ型） | SAP Build（Clean Core型） |
|---|---|---|
| 実行場所 | S/4HANAコア内 | BTP上（コア外） |
| 開発者 | ABAP開発者のみ | 業務ユーザー＋開発者 |
| 開発速度 | 遅い（数週間〜） | 速い（数日〜） |
| アップグレード影響 | 大きい（修正必要） | 小さい（API互換性のみ） |
| AI連携 | 限定的 | Joule・BTP AIと標準連携 |
| ガバナンス | IT部門が一元管理 | シャドーIT化リスクあり |
注意したいのは、ABAP拡張が悪でBuildが善、という単純な話ではないことです。大量データを高速処理する業務ロジック（例：MRP補助、在庫評価ロジック）はコアに近い場所で書くべきで、これは引き続きABAP（特にSteampunk＝ABAP Cloud）の出番です。一方、画面・ワークフロー・部門固有のちょっとした自動化は、Buildで作った方が早く、壊れにくいのです。
この役割分担を誤ると、「重い処理をBuildで作ってしまって性能が出ない」「軽い画面をABAPで作ってしまってコアが肥大化する」という典型的な失敗が起きます。
ユースケース3例｜現場で何が変わるか
ユースケース1：購買申請の承認フロー自動化
紙とExcelで回っていた購買申請を、Build Process Automationで電子化します。申請者がフォーム入力 → 金額に応じて承認者を自動判定 → 承認後にSAPの購買依頼（ME51N相当）を自動登録、という流れです。承認リードタイムが数日から数時間に短縮される例が一般的です。
ユースケース2：倉庫現場のモバイル在庫照会アプリ
倉庫担当者がiPadから品目コードをスキャンして在庫数と保管場所を確認するアプリを、Build Appsで作成します。データソースはS/4HANAのOData。現場は「PCに戻って確認する」作業がなくなり、棚卸時間が半減するケースもあります。
ユースケース3：請求書OCR＋自動仕訳提案
受領した請求書PDFをBuild Process AutomationのAI-OCRで読み取り、金額・取引先・勘定コードを抽出 → 過去データから仕訳を提案 → 経理担当が承認するだけ、という流れです。経理の単純入力作業が劇的に減ります。
Jouleとの連携｜AIコパイロットが開発を加速する
SAP BuildはAIコパイロット「Joule」と密に連携しています。自然言語で「従業員の残業申請アプリを作って」と依頼すると、画面レイアウト・データモデル・APIバインディングの初期案をJouleが生成してくれます。
この流れはJoule 開発者とコンサルの役割分担にも大きな影響を与えています。さらにS/4HANA 2602 AI機能ではJouleがコア業務側にも深く入り込んでおり、「コア側のJoule」と「Build側のJoule」が連動することで、業務ユーザーが自然言語で業務システムを拡張できる時代が現実になりつつあります。
so what：開発者に求められるスキルは「ゼロからコードを書く力」から、「Jouleが出した案をレビューし、ガバナンスと性能を担保する力」へシフトしています。
はじめ方｜最初の一歩
- BTPトライアルアカウントを取得する（無料枠あり）
- Build Lobbyにアクセスし、どの製品から始めるかを選ぶ
- チュートリアル「Hello World アプリ」をBuild Appsで作る
- S/4HANAのサンプルODataに接続して一覧画面を作る
- Process AutomationでシンプルなSlack通知フローを作る
重要なのは、いきなり本番業務に適用せず、小さな社内ツールから試すことです。ローコードは「作れること」と「保守できること」が別物なので、最初の成功体験を小さく作るのがコツです。
ガバナンスの注意点｜「作れすぎる」がリスクになる
SAP Buildの最大のリスクは、誰でも作れてしまうがゆえにアプリが乱立することです。これは一般にシャドーIT問題と呼ばれます。
対策として押さえるべき観点は次の通りです。
- 命名規則・環境分離（Dev/Test/Prod）を最初にルール化する
- 作ったアプリを棚卸する台帳を用意する（誰が・何を・どのAPIを叩くか）
- APIアクセス権限はBTPのRole Collectionで厳格管理する
- 「作ったら終わり」ではなく、半年ごとの棚卸・廃止判断プロセスを決める
これを怠ると、「誰が作ったか分からない承認フロー」「退職者が作ったまま動き続けるアプリ」が増殖し、結局IT部門が後始末するという従来以上に厄介な技術的負債を生みます。ローコードだからこそガバナンスが効く、と理解すべきです。
よくある疑問（FAQ）
Q1. ABAPエンジニアの仕事はなくなりますか？
いいえ。役割が変わるだけです。画面・ワークフロー系はBuildに移る一方、コアロジック・性能要求の高い処理・データ移行・API設計は引き続きABAP（ABAP Cloud）の領域です。むしろ「BuildとABAPをどう使い分けるか」を設計できる人材が希少になります。
Q2. Build AppsとFiori Elementsはどう違いますか？
Fiori Elementsはメタデータ駆動で標準的な業務画面を素早く作るもの、Build Appsは自由度の高い画面（モバイル含む）をドラッグ＆ドロップで作るものです。標準に近い業務画面はFiori Elements、現場特化や社外向けはBuild Appsという住み分けが現実的です。
Q3. オンプレS/4HANAでもSAP Buildは使えますか？
使えます。BTP側にBuildを置き、S/4HANA（オンプレ）のAPIを公開する構成にすればOKです。むしろオンプレ環境こそClean Core化の効果が大きいので、拡張をBuild側に寄せる価値があります。
Q4. ライセンスはどうなっていますか？
BTPのサブスクリプションモデルで提供され、Build製品は「SAP Build Code」「Build Apps」「Build Process Automation」などのユニット単位で課金されます。最新の条件はパートナーまたはSAP営業に確認してください。
Q5. 既存のRPA（UiPathなど）から移行すべきですか？
すぐに全面移行する必要はありません。ただし、SAP業務に閉じた自動化はBuild Process Automationに寄せた方が連携コストが下がります。SAP外を含む全社RPAは既存ツールを残す、というハイブリッドが現実解です。
まとめ
- SAP Buildは「Build Apps・Build Process Automation・Build Work Zone」の3製品で構成されるローコードプラットフォーム
- BTP上で動き、S/4HANAコアはAPI経由で触るためClean Core戦略と親和性が高い
- 従来のABAP拡張と役割分担すべきで、画面・ワークフローはBuild、コアロジックはABAP Cloudが基本
- Jouleとの連携により、自然言語からの開発が現実化しつつある
- 最大のリスクは「作れすぎる」こと。ガバナンス設計を最初に決めることが成功の条件
SAP Buildは単なる開発ツールではなく、「コアを守りながら現場の要件を素早く満たす」ための戦略的な基盤です。S/4HANAへの移行・運用を見据えるなら、早い段階で小さく触り始めることを強くお勧めします。
SAP BuildはBTP上で動くローコード基盤です。BTPの全体構成を理解しておくと、Build以外のサービスとの連携も見通しが良くなります。