ABAP環境：アーキテクチャと利用

JinJin48

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

May 10, 2026 · 17 min read

本記事の位置づけ#

参考資料#

1) ABAP環境のランドスケープ#

ABAP が 2026 年に動作する場所は 3 つあり、それらは互換性がありません。

3つはすべて同じABAPプラットフォームのコードラインと同一のABAPカーネルに基づいています。違いは、使用が許可される言語バージョン、API、およびUIテクノロジーにあります。これらは互換性のある代替品ではありません。

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

                +--------------------------+
                | SAP S/4HANA (any flavor) |
                |  ┌────────────────────┐  |
                |  │ Released APIs (C0) │◀─┼──── consumed by ABAP Cloud
                |  └────────────────────┘  |
                |  ┌────────────────────┐  |
                |  │ Embedded Steampunk │  |  ← on-stack, only Public/Private
                |  │  (ABAP Cloud only) │  |
                |  └────────────────────┘  |
                +─────────────▲────────────+
                              │ Communication
                              │ Arrangements
                              │ (OAuth / mTLS)
                              │
                +─────────────┴────────────+
                |  SAP BTP ABAP Environment |  ← side-by-side
                |  (subaccount / CF runtime)|
                |   - own DB (HANA)        |
                |   - own ABAP runtime     |
                +───────────────────────────+

BTP ABAP環境は独立したシステムです。S/4HANAのテーブルにはアクセスできず、リリース済みでC0安定版のAPIを対象とするコミュニケーション設定を通じてS/4を利用します。Embedded SteampunkはS/4HANA Cloud内部に存在し、ローカルのSADL/CDSアクセスを使用しますが、リリース済みAPIという同じルールに従います。

重要ポイント: ランタイムは、開発者の好みではなく、データの所有者と拡張機能の結合度によって選択する。

3) 成熟度マップ#

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

テナントおよび契約の前提条件#

開発と言語の制約#

統合と接続性#

運用、ライフサイクル、およびライセンス#

5) 意思決定基準#

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

Q1. この拡張機能によって解消される測定可能な非効率性は何か、また、その非効率性をビジネスとして明確に認識しているか？

プロジェクトが課題を定量化できない場合（「ポータルが欲しい」「モダナイズしたい」など）、正しい判断は、ユースケースが明確になるまでBTP ABAP環境の導入を延期することです。ABAP Cloudはリファクタリングツールではなく、ACU単位でコストが発生するランタイムです。測定可能な目標がなければ、更新時にROIを正当化することはできません。

Q2. この拡張機能が処理するデータは法的にどこに存在し、そのライフサイクルを所有するのは誰ですか？

拡張機能が主にS/4のマスタ/トランザクションデータを読み書きする場合、組み込み型Steampunkは通常、レイテンシ、トランザクション整合性、運用のシンプルさにおいて優れています。データがサードパーティシステムまたはBTPアプリケーション自体に所有されている場合は、サイドバイサイド型BTP ABAPの方が適しています。この質問に対する誤った回答は、本ガイド全体で最も高くつくミスとなります。

Q3. ACU消費とABAP Cloudスキルを持つチームの両方に対して予算権限を持つ内部スポンサーはいますか？

ACU コストは運用コストであり、ABAP Cloud スキルは不足しています。両方に責任を持つ指名されたスポンサーがいなければ、プロジェクトは技術的には成功しても、商業的には停滞します。

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

ライセンスとコスト#

6) よくある障害#

障害 1: ABAP Cloud を構文移行として扱うこと

Teamsは「移植」のための予算を組んでいるが、ビルド時に参照の30～60%が未リリースオブジェクト、GUI、または低レベルDBへのものであることが判明する。この作業は移植ではなく再設計である。スプリント4ではなく、要件段階でそれに応じて見積もること。

障害 2: チームがABAPを好むという理由でBTP ABAP環境を選択する

Side-by-sideは、ワークロードが本当にS/4の外部に属する場合に適切な選択肢です。リクエストのたびにS/4のデータを読み書きするワークロードであれば、組み込み型Steampunkの方が高速で低コスト、かつ構成要素も少なくなります。ランタイムは開発者ではなく、データに従うべきです。

障害 3: プライベート / オンプレミスでのATC適用のスキップ

Private Cloudおよびオンプレミス環境では、ABAP CloudとクラシックABAPが共存します。クラウドフラグ付きパッケージで非クラウド構造をブロックするATCバリアントがない場合、チームは静かにクラシックABAPを記述して完了とします。クリーンコアの負債は静かに蓄積され、次のアップグレード時に顕在化します。

障害4：バッチピーク時のACUサイジングの過小評価

ACUは持続的なメモリ使用量に合わせてサイジングされますが、月末や年末のバッチ処理で急増する可能性があります。3か月時点で実際のテレメトリデータを用いたサイジングレビューを計画してください。アーキテクトの推測で数値を決め、その後見直さないということは避けてください。

障害 5: トランスポートとライフサイクルの無視

ここでのモデルは従来のSAPトランスポートではありません。STMSの習慣を維持しようとするチームは行き詰まります。gCTS / abapGitには、最初のデプロイ前にCI計画、ブランチポリシー、および訓練されたオペレーターが必要です。

障害 6: 「組み込み型 Steampunk」が独立した製品ではないことを忘れる

調達部門が「Embedded Steampunk」をSKUとしてSAPに見積もり依頼することがあります。これはS/4HANA Cloud内の開発モデルであり、ラインアイテムではありません。議論の枠組みとしては「既存のS/4ライセンス上でABAP Cloudを使用する」とし、そのまま進めてください。

失敗 7: オンプレミスGUIとの同等性を約束すること

ステークホルダーが「まだABAPがある」と聞いて、SAP GUI画面がそのまま使えると誤解することがあります。しかし、それはできません — UIはFioriでなければなりません。この期待値はデモではなく、要件定義書で明確に設定してください。

FAQ#

Q: SAP GUIトランザクションはそのまま維持し、それ以外をABAP Cloudに移行することは可能ですか？

同じコールスタック上にはありません。ABAP Cloud は SAP GUI / Dynpro 画面を呼び出すことはできません。GUI トランザクションは Private / on-prem 上の Classic ABAP に残し、ABAP Cloud で新しいフローを構築することは可能ですが、これら2つを1つのトランザクションユニット内で混在させることはできません。両者間の通信は、リリースされた API を経由する必要があります。

Q: BTP ABAP Environment と Embedded Steampunk では、ライセンスはどのように異なりますか？

BTP ABAP Environmentは独立したBTPサブスクリプションであり、ACU（ABAPランタイムメモリ16GB単位、最小0.5 ACU）とHANAコンピュートに基づいて課金されます。Embedded Steampunkは既存のS/4HANA Cloudライセンス内で動作するため、別途ランタイム料金は発生しませんが、S/4契約におけるテナントごとの開発者/シート制約の対象となります。

Q: プロジェクトからABAP Cloudをスコープ外とするのはどのような場合ですか？

ユースケースがローコードパス（Build Apps、BTP-B05）やポリグロットなCAP/Build Codeサービス（BTP-B03）で十分に実現でき、かつABAPに留まるドメイン上の理由がない場合。ABAP Cloudが最も正当化されるのは、ABAPスキルが深く、ワークロードがトランザクション型であり、クリーンコア拡張が明確な目標である場合です。それ以外の場合は、対応するスキルやコンプライアンス上のメリットがないまま、ランタイムコストが発生するだけです。

Q: ABAP Cloud は S/4HANA オンプレミスにも適用されますか？

はい、ただし開発の選択肢として、かつリリース2022以降に限ります。クラシックABAPは引き続きサポートされます。戦略的な課題は、クラシックABAPでの新規開発が許可されるかどうかであり、運用上の課題は、その決定を強制するようにATCが設定されているかどうかです。

Q: ABAP環境の要件を適切に文書化するにはどうすればよいですか？

3つの成果物：(1) 測定可能な目標を伴うユースケース記述（上記Q1）、(2) サイドバイサイド方式とオンスタック方式のどちらを選択するかを正当化するデータ所有権記述（上記Q2）、(3) 公開済みオブジェクトの利用状況と必要な通信設定を明記したAPIおよび統合リスト。これら3つがなければ、アーキテクトは作業の規模や価格を信頼性をもって見積もることはできません。

Q: 必要なリリース済みAPIが存在しない場合はどうすればよいですか？

これはよくあることで、通常は実際のブロッカーとなります。選択肢：SAP Influenceリクエストを提出する、別のリリース済みAPIパスを使用してラッパーを設計する、またはこの拡張機能が当面はClassicのままであることを受け入れる。ロードマップの文書化されたコミットメントなしに「まもなくリリースされる」と想定しないでください。

Q: JouleはABAP環境での作業にどのように組み込まれますか？

SAPはJouleをABAP Cloud向けの開発者アシスタントとして位置づけています。コード生成、ビジネスオブジェクトのスキャフォールディング、ドキュメント作成などが可能です。生産性向上には役立ちますが、アーキテクチャ上の判断を変えるものではありません。Jouleは、誤った場所に配置された拡張機能を正しい場所に移動させることはできません。

概要#

SAP BTP ABAP環境は、成熟したサポート対象のクラウドネイティブABAPランタイムです。しかし、その成功はコーディングスキルではなく、要件段階での意思決定に依存します。ランタイムの選択（サイドバイサイドのBTP ABAP vs. オンスタックのEmbedded Steampunk vs. レガシークラシック）は、開発者の好みではなく、データの所有権と結合度に従うべきです。ABAP Cloudの制約は現実的かつ既知のものです。リリース済みAPIのみ、RAPのみ、Fioriのみ、低レベルDBは不可。移植ではなく、再設計を計画してください。最初のスプリント前に、サイジング、ATC適用、トランスポートツール、ライセンスポジションを確認すれば、プロジェクトの残りは通常、自動的に進みます。

次に読むべきもの#