はじめに
S/4HANAが提供する標準Fioriアプリを、プロジェクト要件に合わせて少しだけ改修したい、という要望はどのプロジェクトでも出てきます。
従来のABAPスタイルで「標準コードを直接いじる」のはS/4HANA Cloud時代のClean Core戦略（詳細はClean Core戦略）では禁じ手です。標準に触らずにFioriアプリをカスタマイズする仕組みがAdaptation Projectで、これを使えば標準機能の継続アップデートを受けながら自社独自の要件も実現できます。
Adaptation Projectとは
Adaptation Projectは、既存のFioriアプリ（SAP標準またはFreestyle）に対して、上書き型の変更を差分ファイルとして管理する仕組みです。元のアプリのコードには一切触らず、「変更の指示書」だけをプロジェクトとして作成・管理します。
技術的にはSAPUI5の Flexibility Services が基盤で、以下のような変更が可能です：
- 項目の非表示・順序変更
- ラベル変更
- 新しい項目の追加
- カスタムセクションの挿入
- カスタムフラグメントの埋め込み
- カスタムロジックの注入
2つのレベル
Key User Adaptation（UI Adaptation at Runtime）
エンドユーザー（キーユーザー）がブラウザ上でUIの変更を行うレベル。項目の非表示、順序変更、ラベル変更など簡単な変更はユーザー権限で可能です。
- 操作：FioriアプリからMe Area → Adapt UI
- 保存先：BTP Launchpad ServiceのFlexibility Serviceまたはバックエンドの変更管理DB
- 技術知識：不要
Developer Adaptation Project
開発者がBusiness Application Studio（BAS入門）で行う拡張レベル。カスタムフラグメントの追加、拡張ロジックの挿入、複雑な構造変更など本格的な改修が可能です。
- 操作：BASでAdaptation Projectを作成
- 保存先：UI5の Component.js 拡張ファイル
- 技術知識：UI5開発の基本知識
Adaptation Projectの構造
flowchart LR OR["オリジナル
Fioriアプリ"] --> EP["Extension Points"] AP["Adaptation
Project"] --> CH["Change Files
manifest.appdescr変更"] CH --> EP EP --> RUN["ランタイム
マージ結果"] OR --> RUN
オリジナルアプリのmanifest.jsonは変更せず、Adaptation Project側がmanifest.appdescr_variantファイルに変更指示を持ちます。ランタイムで両者がマージされ、最終的な画面が組み立てられます。
BASでの作り方
- BASのFiori Dev Spaceを起動
- コマンドパレットから「Create Adaptation Project」を選択
- 拡張対象のFioriアプリ（SAP標準アプリ）を指定
- 拡張内容を選択（Add Custom Section、Change Property、Add Fragmentなど）
- 変更をプレビューで確認
- プロジェクトをBTPにデプロイ
変更は /webapp/changes/ フォルダにJSON形式で保存されます。Gitで管理できるため、チーム開発やCI/CDとの連携が可能です。
よくある変更例
例1：項目のラベル変更
「Quantity」を「発注数量」に変更したい場合、Change Propertyで Label プロパティを上書きします。
例2：カスタムセクション追加
Object Pageに独自の追加情報セクションを追加したい場合、Add Custom Sectionを選び、XML Fragmentを作成して差し込みます。
例3：新しいカスタムアクション
「承認取り消し」ボタンを追加したい場合、Add Custom Actionを使ってボタンとそのハンドラを定義します。ハンドラは自作のControllerに書きます。
例4：項目の表示/非表示
特定項目を自社では使わないので消したい、というケースはHide Fieldだけで対応可能です。キーユーザーでも実行できます。
Clean Core戦略との関係
Adaptation ProjectはClean Core戦略の中核ツールの1つです。Clean Coreの原則は「標準コードを変更せず、拡張は専用の拡張ポイントで行う」であり、Adaptation Projectはまさにこの原則に沿っています。
- 標準アプリのバージョンアップ時に拡張が壊れにくい
- 拡張内容がJSONファイルとしてGit管理可能
- 本番切り戻しも容易（Change Fileを外すだけ）
従来のABAP Modification（標準コード直接変更）と比べて、メンテナンスコストが大幅に下がります。
制限事項
Adaptation Projectは万能ではありません：
- Fiori Elementsアプリ限定の機能も多い（Freestyleでは使えない変更がある）
- 大規模な構造変更（全く別の画面にする）には向かない
- 変更ファイルが増えすぎると管理が複雑化する
「標準の95%で済むが、残り5%を変えたい」というケースに最適化されています。大規模改修ならFreestyleでの再実装も検討します。
よくある疑問
Q. Adaptation ProjectはS/4HANA On-Premiseでも使えますか？
A. 使えます。ただしBAS + BTP Launchpad Service構成が前提です。S/4HANAのFrontend Server上のLaunchpadでも一部機能が利用可能です。
Q. ABAPの拡張と何が違いますか？
A. ABAPのBAdI / User Exitはサーバーサイド処理の拡張、Adaptation ProjectはUI層の拡張です。両方を組み合わせて使うこともあります。
Q. 一度作ったAdaptation Projectは移行できますか？
A. Git経由で別システムに持っていけます。Transport管理との連携も可能です。
Q. Key User AdaptationとDeveloper Adaptationは併用できますか？
A. はい。同じアプリに対して、キーユーザーがUI項目を非表示にしつつ、開発者側でカスタムセクションを追加する、という併用が可能です。
まとめ
- Adaptation Projectは標準Fioriアプリを壊さずに拡張する仕組み
- Key User Adaptation（UI簡易変更）とDeveloper Adaptation（本格拡張）の2レベル
- 変更はmanifest.appdescr_variant等のJSONファイルに差分として保存される
- Clean Core戦略の中核ツールで、標準アップデート時に壊れにくい
- 95%標準+5%独自のケースに最適
次はFiori for Mobileで、モバイル向けFioriアプリの世界を見ていきます。
Adaptation Projectの仕組みを理解した次は、拡張元となるFioriアプリ自体を作れるようになると視野が広がります。UI5とCAPを使ったアプリ構築からBTPデプロイまでを一貫して体験できるハンズオン講座です。