CAP と Build Code：アーキテクチャと用途

JinJin48

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

May 10, 2026 · 19 min read

本記事の位置づけ#

参考資料#

1) CAP と Build Code のランドスケープ#

CAPとBuild Codeは、しばしば競合製品のように語られますが、そうではありません。CAPはフレームワークであり、Build CodeはそのフレームワークをIDEとAIコパイロットでパッケージ化したものです。

これらは代替ではありません。CAPは、どのオプションを選択しても使用されるランタイムです。BASはIDEです。JouleはAI機能です。Build Codeは商用ラッパーです。

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

CAP はサイドバイサイド拡張オプションです。サービスはBTP上で実行され、公開されたAPIを介してS/4HANAを呼び出します。S/4HANAスタック内部からではありません。Build Codeはこれを変更するものではなく、サイドバイサイドサービスの作成方法を変更するものであり、実行場所を変更するものではありません。

                 SAP BTP — Application Development (Pro Code)
   ┌──────────────────────────────────────────────────────────────────┐
   │  Authoring layer                                                 │
   │   ├─ SAP Build Code (BAS dev space + Joule for Developers)       │
   │   └─ Or: BAS standalone + CAP toolchain (no Joule)               │
   │                                                                  │
   │  Programming model                                               │
   │   └─ CAP (Node.js or Java) — CDS, generic providers, MTX         │
   │                                                                  │
   │  Runtime                                                         │
   │   ├─ Cloud Foundry (default for CAP)                             │
   │   └─ Kyma (Kubernetes-native)                                    │
   │                                                                  │
   │  Persistence                                                     │
   │   └─ SAP HANA Cloud (PostgreSQL / SQLite supported in dev)       │
   └──────────────────────────────┬───────────────────────────────────┘
                                  │ OData / REST via Destination service
                                  ▼
   ┌──────────────────────────────────────────────────────────────────┐
   │  S/4HANA Cloud (released APIs only)  ──or──  S/4HANA on-premise  │
   │                                                via Cloud Connector│
   └──────────────────────────────────────────────────────────────────┘

重要なポイント: プレーンなBASで作成するか、Build Codeで作成するかに関わらず、デプロイされたCAPサービスは同一のアーティファクトです。Build Codeはアーキテクチャ上の決定ではなく、作成方法の選択です。「Build Codeを選んだ」という事実自体は、S/4HANA統合に関するいかなる質問への回答にもなりません。

3) 成熟度マップ#

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

以下は、それぞれ独立したゲーティングセットです。要件クローズ時に未回答の項目がある場合、そのプロジェクトは設計の準備ができていません。

プログラミングモデルとチームの前提条件#

Build Code と Joule の前提条件#

デプロイメント、永続性、およびアイデンティティ#

運用とライフサイクル#

5) 意思決定基準#

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

Q1. 私たちが取り除く具体的な開発上の課題は何ですか？—— スキャフォールディングの速度、ランタイムの能力、またはその両方ですか？

もし答えが「scaffolding speed（足場構築の速さ）」のみであれば、Build Code は対象範囲内であり、プレーンな CAP は対象外です。答えに「MTX が必要」や「イベント駆動型のクロスサービス呼び出しが必要」が含まれる場合、Build Code が追加されているかどうかに関わらず、CAP が必要です。

Q2. データはどこに保存され、どのAPIがそれにアクセスするのか？

CAPの価値は、クリーンなODataまたはREST APIをモデル化できるかどうかに依存します。統合対象がリリースされたAPIのないオンプレミスのS/4HANAである場合でも、CAPはCloud ConnectorとDestinationを介して呼び出すことができますが、要件の議論にはS/4HANA側でAPIリリース計画を誰が担当するかを含める必要があります。

Q3. チームの資金は誰が提供し、AIの消費に対する請求はどのように行われますか？

Build Code は、統合された SAP Build サブスクリプション内に位置付けられるようになりました。BTPEA クレジットはあるが Build サブスクリプションがない場合、Joule は BTPEA プールの下で消費されます。どちらもない場合、調達が制約となり、技術的な制約ではありません。

プロジェクトコンテキストによるドメイン選択#

ライセンスとコスト#

6) よくある障害#

障害1: 足場となるユースケースなしでビルドコードを選択

チームは顧客が「AI開発」を求めたためBuild Codeを購入したが、Jouleでいくつかのエンティティプロンプトを使い、残りは手書きで記述している。このバンドルはチームが活用していない機能に対して支払いが発生する。スキャフォールディングのユースケースが限定的であれば、BAS上の通常のCAPに留まるべきである。

障害 2: Jouleの出力をマージ済みコードとして扱う

Joule はコンパイル可能なCDSおよびサービススタブを生成するため、チームが浅いレビューに陥りやすくなります。生成された認可アノテーション、アソシエーションのカーディナリティ、Fiori UIヒントが最も一般的な欠陥クラスです。これらはテストに合格しますが、誤ったビジネスルールをエンコードしています。Jouleの出力は、ジュニアエンジニアのプルリクエストとして扱ってください。

障害 3: CDS 認可をスキップし、XSUAA スコープのみに依存する

Teamsはカスタムハンドラにスコープチェックを組み込み、CDSモデルから@restrictと@requiresを除外します。これは、次の開発者がハンドラを完全にバイパスする汎用プロバイダ呼び出しを記述するまでは機能します。認可はモデルに属するものです。

障害 4: 1つのチーム内でNode.jsとJavaスタックを混在させる

Node.js と Java CAP の両方のサービスを保守するチームは、1つのスタックに絞ったチームと比較して、スプリントごとの出荷量が約半分になります。CAP 自体は両方で一貫していますが、運用ツールチェーンは一貫していません。デバッグ、プロファイリング、依存関係管理、IDE のセットアップがすべて倍になります。

障害5：初期プロトタイピングにおけるSAP HANA Cloudのコスト過小評価

SQLite を使った CAP 開発は低コストです。共有 HANA Cloud への最初の移行で予算の驚きが始まります。特に、シングルユーザーのプロトタイプに本番用のインスタンスをプロビジョニングした場合です。HANA Cloud は実際の非本番負荷に合わせてサイジングし、「本番がどうなるか」に合わせないでください。

障害 6: MTX は初日から決定すべき事項であることを忘れる

CAPはマルチテナンシーを適切にサポートしていますが、それは最初からモデル化されている場合に限ります。シングルテナントリリース後にMTXを後付けすると、永続化、認証、CIフローを書き直すことになります。顧客がアプリケーションを再販したり、法人間で共有する可能性がある場合、MTXは最初のスプリントに含めるべきです。

障害 7: Build Code を CDS スキルの代替として扱うこと

Build CodeはCDSを抽象化するのではなく、CDSの生成を高速化します。CDSに精通したメンバーがいないチームは、スプリントごとにより多くのコードを生成し、より多くのバグをリリースすることになります。Jouleの有無にかかわらず、プロジェクトごとに少なくとも1名のシニアCAPエンジニアを計画してください。

FAQ#

Q: CAPはオンプレミスのSAPシステムで実行できますか、それともクラウドのみですか？

CAPがサポートするデプロイ先は、SAP BTP Cloud FoundryとKymaです。オンプレミスのS/4HANAに接続するために、CAPサービスはDestinationサービスとSAP Cloud Connectorを使用し、リリースされたAPI（OData、REST、または許可されている場合はリモート対応ファンクションモジュール）を呼び出します。CAPサービス自体はオンプレミスでは動作しません。

Q: Build Code は Joule for Developers を利用する上で必須ですか？

Joule for Developersは、Build Code内で提供されるAIコパイロットです。一部のJoule機能はVS Code（Joule Studioコードエディター）やABAP開発ツールから利用可能ですが、多くのコンサルタントが「Joule」と呼ぶCAPスキャフォールディング体験は、Build Codeのエクスペリエンスを指します。要件にJouleが含まれている場合は、Build Code（または統合SAP Build）の調達を計画してください。

Q: 顧客から要求があった場合でも、プロジェクトからBuild Codeを除外すべきなのはどのような場合ですか？

チームが四半期あたり2件未満のスキャフォールディングユースケースしかない場合、またはチームが十分に小規模で、1人のシニアCDSエンジニアが手作業でスキャフォールディングする方がJouleの出力をレビューするよりも速い場合は、導入を見送る。Build Codeの価値は多数のスキャフォールディングイベントにわたって償却されるものであり、単発のプロジェクトではその価値を回収することはほとんどない。

Q: Build Code を既に BTPEA を保有している顧客でライセンスするにはどうすればよいですか？

Build Code は統合 SAP Build パッケージの一部であり、BTPEA および PayG でも利用可能です。既存の BTPEA 契約を持つお客様は、そのプールに対して Build Code を消費できます。統合 Build SKU と BTPEA ライン消費では価格が異なるため、正確な単価については SAP の担当営業担当者にご確認ください。

Q: CAP要件をどのように文書化すれば、設計チームがそれに基づいて行動できるようになりますか？

最低限、以下を記録すること：(1) リリース済みAPIにマッピングされたエンティティと新規永続化、(2) Node.jsまたはJavaの判断、(3) デプロイメントランタイム（CFまたはKyma）、(4) 認証プロバイダー（XSUAAまたはIAS）とロールコレクションのマッピング、(5) マルチテナンシーの姿勢、(6) 宛先リスト、(7) Jouleがツールチェーンに含まれているか、およびどのフローを担当するか。これら7項目がない場合、設計チームは契約に合致しないデフォルト値を設定することになる。

Q: Build Code を使用することで、長期的に SAP にロックインされるのでしょうか？

CAP コードはポータブルです。Node.js または Java サービスと CDS ソースは Build Code の外部でも再構築可能であり、CDS ツールチェーンはオープンです。Build Code は生産性向上のためのラッパーであり、ランタイムのロックインではありません。より強い結合は、アプリケーションが使用する BTP サービス（XSUAA、Destination、HANA Cloud）から生じます。Build Code ではなく、それらこそが真のロックインの議論の対象です。

Q: Build Apps を使用するローコードチームは、Build Code で構築された CAP サービスを利用できますか？

はい。CAPはODataを公開し、Build AppsはDestinationサービスを介してODataを利用できます。これはBTPにおける標準的な「プロコードサービス、ローコードUI」のパターンです。

概要#

CAPはプログラミングモデルです。オープンで成熟しており、Node.jsとJavaでサポートされ、SAP S/4HANAの本格的なサイドバイサイド拡張における適切なデフォルト選択肢です。SAP Build Codeは、Business Application Studioの開発スペースと、CDS、サービス、FioriアノテーションをスキャフォールディングするAIコパイロット「Joule for Developers」（2025年のマルチエージェントモードを含む）でCAPをラップした商用バンドルです。選択すべきはどちらを使うかではなく、プロジェクトにBuild Codeの商用オーバーヘッドを償却するのに十分なスキャフォールディング作業があるかどうかです。迷った場合は、BAS上でプレーンなCAPから始め、スキャフォールディングのユースケースが具体的かつ反復的になった時点でBuild Codeを追加してください。

次に読むべきもの#