Build Apps: アーキテクチャと使用方法

JinJin48

SAP Consultant | BTP · S/4HANA · US Global Rollout

May 10, 2026 · 17 min read

本記事の位置づけ#

参考資料#

1) ローコードアプリビルダーの状況#

Build Apps は単独で存在するわけではありません。重複しながらも異なるツール群からなるポートフォリオの一部です。コンサルタントがこれらを代替品として扱うと失敗します。そうではないのです。

これらは代替品ではありません。

2) S/4HANA への接続方法#

Build Apps は S/4HANA と直接通信しません。BTP を介して通信します。

+----------------------+         +------------------------+
|  Build Apps client   |  HTTPS  |  BTP Destination       |
|  (PWA / iOS / And.)  +-------->+  Service / Connectivity|
+----------+-----------+         +------------+-----------+
           |                                  |
           |  flow functions                  |  OData / REST
           |  formula bindings                |  (with auth)
           v                                  v
+----------------------+         +------------------------+
|  Visual Cloud        |         |  S/4HANA Cloud /       |
|  Functions (BTP K8s) |<------->|  S/4HANA Private /     |
|  (entities + funcs)  |         |  SuccessFactors / etc. |
+----------------------+         +------------------------+

VCFは、そうでなければクライアント側に漏れてしまうサーバーサイドロジック（変換、ルール評価、スケジュールタスク、広範なODataサービスに対する絞り込まれた読み取り専用エンドポイント）を配置する場所です。認証と資格情報管理はアプリ内ではなくBTP上に残ります。

重要ポイント: S/4との接続はBTPの宛先に存在し、Build Apps内にはありません。アプリを統合レイヤーとして扱うと、出荷するすべてのBuild Appでその統合を再構築することになります。

3) 成熟度マップ#

4) 要件チェックリスト#

これは、要件ドキュメントで通常見落とされる部分です。各テーブルは1つの機能領域をカバーし、行は実装手順ではなく要件段階の項目です。

UIとフロントエンドの要件#

データ統合の要件#

ロジックと計算要件#

モバイル配送要件#

ガバナンス、ライセンス、および運用要件#

5) 意思決定基準#

最初に問うべき3つの質問#

Q1. Build Apps によって除去可能な、数値で示せる非効率性はありますか？

「今日、この作業は1ケースあたりN分かかり、1日あたりMケースある」と表現できないのであれば、それはまだBuild Appsの要件ではありません。それは「願望」です。構築の話から離れ、ディスカバリーに戻ってください。Build Appsのスピード面での優位性は、圧縮すべき具体的なものがある場合にのみ発揮されます。

Q2. データはどこに保存され、誰が読み取りや書き込みを許可されているのか？

Build Apps は BTP の宛先を通じて S/4、SuccessFactors、サードパーティ API、または VCF に接続します。UI のスコープを定義する前に、データの保存場所、認証パス、および各側でスキーマを変更できるユーザーのルールを書き留めてください。多くの「Build Apps プロジェクト」は、アプリが依存する OData サービスの所有者が決まっていないために、3 週目で停滞します。

Q3. 内部スポンサーは誰で、ランタイム費用は誰が負担しますか？

Build Apps は、BTPEA/PayGo では従量課金、サブスクリプションでは定額制です。スポンサーは、ライセンスコストとランタイムコスト（Visual Cloud Functions、モバイルビルド時間、Joule プロモーション期間終了後の AI 使用量）の両方を理解する必要があります。スポンサーが「月間のランタイム予算はいくらですか？」と答えられない場合、プロジェクトはまだ規模が確定していません。

プロジェクトコンテキストの選択#

ライセンスとコスト#

6) よくある障害#

障害1：「ノーコードだから誰でも構築できる」

これは、技術的な問題よりも多くのBuild Appsプロジェクトを頓挫させます。シチズンデベロッパーは確かに実際の価値を提供できますが、アプリが本番データ（宛先、認証、ガバナンス）に触れた瞬間に、プロフェッショナル側の対応が必要になります。最初のインシデントが発生してからではなく、初日からフュージョンチームを計画してください。

障害 2: アプリを統合レイヤーとして扱う

よくあるアンチパターンとして、Build Appを複数のバックエンドに直接接続し、フロー関数でデータを結合することがあります。これは最初は高速ですが、3か月後にはメンテナンスが困難になります。統合処理はBTPの宛先とVisual Cloud Functionsに押し出し、アプリはプレゼンテーション層として扱ってください。

障害 3: オフライン会話の欠落

ステークホルダーは「モバイル対応」と言い、オフラインを前提とします。Build AppsはオフラインのOData同期をサポートしていません。要件定義の段階でオフラインに関する議論が行われないと、UAT（ユーザー受入テスト）で問題が顕在化し、再構築はBuild AppsではなくMDKで行うことになります。初日からオフラインの質問をし、その回答を文書化してください。

障害 4: Visual Cloud Functions スキーマに対するガバナンスの欠如

VCFエンティティはデータベースのように動作します。シチズンデベロッパーは気軽にフィールドを追加したりプロパティをリネームしたりしますが、下流のコンシューマーは静かに壊れていきます。最初のリグレッションが発生した後ではなく、プロジェクトキックオフ時にスキーマ変更プロセスを定義してください。

失敗 5: ライセンスに関する会話の範囲を過小評価すること

2025年のパッケージングによりBuild Appsはより安価でシンプルになりましたが、ランタイムのライン項目（VCF実行、モバイルビルド、プロモーション期間後のJoule）は依然として顧客を驚かせています。要件ドキュメント内の各従量課金アイテムをリストアップし、それぞれに仮のコストを設定してください。

障害6: 設計のギャップをJouleが埋めると仮定すること

Joule for Developersは、ボイラープレート、数式の説明、スターターコンポーネントに役立ちます。情報アーキテクトやUXレビュアーの代わりにはなりません。AIの提案はドラフトとして扱い、人間がページコレクション、データモデル、ナビゲーションをレビューしてください。

障害 7: Fiori に埋め込むための Build Apps の選択

Build Apps のスタンドアロン利用は優れています。しかし、Build Apps を Fiori ランチパッドに埋め込んで UI5 のように使うと、一貫して使い勝手が悪くなります。テーマがずれたり、ナビゲーションモデルが競合したり、アクセシビリティの認証が難しくなったりします。埋め込み型の拡張には、Fiori Elements または UI5 / Build Code をデフォルトとして使用してください。

FAQ#

Q: SAP Build Apps はオンプレミスの S/4HANA でも動作しますか、それとも S/4HANA Cloud のみですか？

両方です。オンプレミスシステムへの接続は、BTP Destination ServiceとCloud Connectorを介して行われます。Build Appの観点からは呼び出しは同一ですが、顧客の観点からは前提条件が異なります — Cloud Connectorのデプロイ、オンプレミスODataサービスの有効化、およびネットワークルールです。

Q: SAP Build Apps のライセンスは2026年にどのように提供されますか？

2025年、SAPはBuildファミリーを統合し、統一されたSAP Buildライセンスとしました。お客様はサブスクリプション、BTPEAクラウドクレジット、またはPayGoを通じてこれを利用できます。Build Apps、Build Code、Build Process Automation、Build Work Zoneは統一された権利を共有し、ランタイム使用量（Visual Cloud Functions、モバイルビルド時間、プロモーション期間を超えたJoule）は従量課金されます。

Q: プロジェクトはいつBuild Appsの対象範囲を縮小し、プロコードに切り替えるべきですか？

具体的なシグナル：オフライン同期が必要、パフォーマンス予算が約2秒のファーストペイントより厳しい、アプリをFiori内に埋め込む必要がある、カスタムUI動作がマーケットプレイスを超える、ロジックキャンバスが1ページあたり約30ノードを超える、または監査/ソース管理の要件に完全なGitワークフローが必要。これらのうち1つでも該当すれば検討が必要となり、2つ以上該当すれば通常は判断が確定する。

Q: プロジェクトを超えて活用できるように、Build Appsの要件をどのように文書化すればよいですか？

各ページについて：ペルソナ、データソース（宛先名を含む）、ルール（ルール所有者を含む）、障害モード、および受入基準。各Visual Cloud Functionについて：入力スキーマ、出力スキーマ、副作用、およびルール所有者。要件ドキュメントは、別のチームが仕様からアプリをゼロから再構築できるようにする必要があります。このテストにより、ほとんどの「暗黙知」の失敗が明らかになります。

Q: Build Apps は内部ユーザー向けの Fiori を置き換えることができますか？

場合によっては — スタンドアロンで範囲が限定されたアプリ向けです。S/4 ローンチパッド内の組み込み拡張機能や、非常に大規模なリスト/編集操作には適していません。正直な答えは、「新しい限定アプリには Build Apps を、S/4 組み込み UX のロングテールには Fiori Elements / UI5 を」です。

Q: Build Apps にオフラインサポートは追加されますか？

SAPは、Build AppsにおけるオフラインOData同期について、公にコミットしていません。今後も提供されないものとして計画してください。オフライン対応が必須要件である場合、現時点ではMDKがサポートされているパスです。

Q: Joule for Developers は、Build Apps の日常業務において具体的にどのように役立つのでしょうか？

Q1/2026では、コード/数式の生成、既存のフロー機能の説明、およびスターターテンプレートの提案をカバーします。これは、フュージョンチームのプロフェッショナル側にとって生産性向上レイヤーとして最も有用です。シチズンデベロッパーも恩恵を受けますが、安全性のレビューには依然として人間が必要です。

概要#

SAP Build Appsは、BTP接続システムと連携するオンラインアプリには成熟しており、オフラインモバイルや組み込みFiori拡張には弱く、AI駆動型UXはアーリーアダプター段階です。これをフュージョンチームのフロントエンドとして扱い、他の本番システムと同様にガバナンスを適用してください。サーバーサイドロジックにはVisual Cloud Functionsを活用してください。「このアプリはどの数値を動かすのか？」という問いに答えられないプロジェクトからは撤退してください。Build Appsのスピードが発揮されるのは、圧縮すべき具体的なものがある場合のみです。ローコードとプロコードの境界線は技術的な議論ではなく、要件定義時に行うスコープ決定です。

次に読むべきもの#