はじめに
SAPUI5でFioriアプリを一から作ると、同じようなList画面・Detail画面・検索フォームを何度も書くことになります。これを標準化し、CDSビューのアノテーションから自動生成する仕組みが Fiori Elements です。
Fiori Elementsを使うと、UIのコードをほとんど書かずに「Fiori Design Guidelines完全準拠の画面」が出来上がります。S/4HANAの標準Fioriアプリも多くがFiori Elementsベースで作られています。
この記事ではFiori Elementsの5つのテンプレート（Floorplan）の特徴と使い分けを整理します。
アノテーション駆動開発とは
Fiori Elementsの最大の特徴は「アノテーション駆動」という思想です。
通常のUI5開発では、XML Viewに <Table> や <Input> を直接書きますが、Fiori Elementsでは画面構造を書く代わりに、CDSビューやOData EDMXに 「@UI.lineItem」「@UI.selectionField」のようなアノテーションを付与します。これを読んだFiori Elementsフレームワークが、ランタイムに自動的に画面を生成します。
詳しいアノテーションの書き方はCDSアノテーション駆動開発を参照してください。
メリット
- UIコードがほぼゼロ。メンテ負担が激減
- 全アプリが必然的にFiori Guidelinesに準拠
- CDSビューの定義変更が即時に画面に反映される
デメリット
- 自由度が低い。特殊なUIは作れない
- アノテーションの習得コストがある
- 細かいデザイン調整は難しい
5つのFloorplan
flowchart LR
Q{画面の目的は？} -->|一覧+フィルタ+詳細| LR["List Report"]
Q -->|単一オブジェクト詳細| OP["Object Page"]
Q -->|分析+絞込| ALP["Analytical
List Page"]
Q -->|タスク処理| WL["Worklist"]
Q -->|KPI概要| OVP["Overview Page"]
LR --> OP
ALP --> OP
WL --> OP1. List Report
検索・フィルタ・一覧表示・詳細遷移という、業務アプリで最も頻出する画面パターンです。上部に検索フィルタバー、下部にテーブル（または複数のビュー切り替え）という構造が標準です。
適用例：発注一覧、販売オーダー一覧、仕入先マスタ検索
2. Object Page
単一のビジネスオブジェクトの詳細を表示・編集する画面です。ヘッダ情報、複数タブのセクション、関連情報への遷移ボタンなどが標準構造です。List Reportからクリックで遷移してObject Pageに入るのが定番パターンで、この画面遷移は内部的にUI5のRouting（ルーティング）機構によってURLハッシュと紐付けられています。
適用例：発注書詳細、顧客マスタ編集、材料マスタ詳細
3. Analytical List Page（ALP）
分析用途の一覧画面です。上部に可視化チャート、下部にドリルダウン可能なテーブルを配置し、「集計して絞り込んで詳細を見る」という分析フローに最適化されています。
適用例：月次売上分析、支払期日分析、在庫回転率モニタ
4. Worklist
ユーザー固有の未処理タスク一覧を表示する画面です。List Reportと似ていますが、より「今やるべきこと」に特化した構造で、承認待ちアイテムや割り当てタスクの表示に向いています。
適用例：承認待ちアイテム、未完了タスク、マイワークリスト
5. Overview Page（OVP）
KPIカードやダッシュボード的な情報を1画面に集約するFloorplanです。複数のカード（リスト・テーブル・チャート・KPI）を配置し、ユーザーが業務全体像を把握できるようにします。
適用例：調達部門ダッシュボード、営業KPIボード、工場稼働モニタ
どのFloorplanを選ぶか
| 要件 | 推奨Floorplan |
|---|---|
| 検索してから対象を特定し詳細を編集したい | List Report + Object Page |
| 単一レコードを深堀りして編集したい | Object Page単独 |
| 数値の傾向を分析したい | ALP |
| タスク処理をしたい | Worklist |
| 業務概要を把握したい | OVP |
迷ったら List Report + Object Page が最も汎用性が高い組み合わせです。S/4HANAの標準Fioriアプリの多くがこのペアで作られています。
実装の具体手順はList Report + Object Page実装ガイド、ALP/OVPはALP/OVP実装ガイドを参照してください。
Fiori Elementsの裏側
Fiori Elementsで生成される画面は、実行時にsap.fe（Fiori Elements）ライブラリがアノテーションを読んで動的にUI5コントロールを組み立てたものです。デバッグツールで見ると、実態は通常のUI5コントロール（sap.m.Table等）で構成されていることが分かります。
つまりFiori Elementsは「画面を隠蔽するフレームワーク」ではなく、「画面構築を自動化するジェネレータ」という位置づけです。必要に応じてExtension Pointで部分的にカスタマイズもできます。SAPが標準提供するFiori Elementsアプリに顧客側で項目追加・非表示化・ボタン追加などを加える場合は、Adaptation Project（アダプテーションプロジェクト）という専用のカスタマイズ手法を使います。
よくある疑問
Q. Freestyle UI5と比べて何が良いのですか？
A. 実装工数が1/3〜1/5になります。詳細はFreestyle vs Fiori Elementsで比較しています。
Q. OData v2とv4どちらが必要ですか？
A. Fiori Elementsの新機能はOData v4前提で開発が進んでいます。新規プロジェクトはv4採用が推奨されます。
Q. カスタムアクション（ボタン）は追加できますか？
A. 可能です。manifest.jsonのFlexible Programming Modelまたは Extension Pointでカスタムアクションを差し込めます。
Q. Fiori ElementsのアプリはFiori Launchpadで動きますか？
A. もちろんです。生成されたアプリはLaunchpadのタイルから起動される通常のFioriアプリとして動作します。
まとめ
- Fiori Elementsはアノテーション駆動でFioriアプリを自動生成するフレームワーク
- List Report / Object Page / ALP / Worklist / OVP の5つのFloorplanが用意されている
- 迷ったら List Report + Object Page が万能
- 自由度と引き換えに、実装工数・一貫性・メンテ性で圧倒的に有利
- 実態は通常のUI5コントロールで構成されており、Extension Pointで部分カスタマイズ可能
次はList Report + Object Page実装ガイドで、実際の構築手順に進みましょう。
Fiori Elementsの仕組みをさらに深く学ぶなら、実際にプロジェクトを作りながら進めるハンズオン講座がおすすめです。CAPモデルの構築からUI5フロントエンドの実装、BTPデプロイまで一気通貫で体験できます。