背景と適用シナリオ
Salesforce のユーザーインターフェース (UI) は、Classic から Lightning Experience へと大きく進化しました。この進化の中核をなすのが、Lightning App Builder (Lightning アプリケーションビルダー) です。これは、Salesforce のデスクトップおよびモバイルアプリケーション向けのカスタムページを、コードを記述することなく、直感的なドラッグアンドドロップ操作で作成できる強力な宣言的ツールです。
かつての Classic UI では、ページレイアウト (ページレイアウト) を使用してレコード詳細ページの項目や関連リストの配置を制御していましたが、カスタマイズの自由度には限界がありました。Lightning App Builder はこの点を根本的に変革し、単なるデータ表示だけでなく、ビジネスプロセスやユーザーの役割に最適化された、豊かでインタラクティブなユーザーエクスペリエンス (UX) の構築を可能にします。
主な適用シナリオ:
- カスタムレコードページ: 特定のオブジェクト(取引先、商談など)に対して、標準のレコードページを上書きし、業務に特化したコンポーネント配置や情報表示を実現します。例えば、営業担当者向けの商談ページには売上予測グラフを、サポート担当者向けのケースページにはナレッジ記事コンポーネントを大きく配置するなど、役割に応じたUIを提供できます。
- カスタムホームページ: ユーザーがログイン後に最初に目にするホームページを、プロファイルごとに最適化します。マネージャーにはチームのパフォーマンスダッシュボードを、一般ユーザーには今日のToDoリストや最近参照したレコードを表示させることができます。
- アプリケーションページ: 特定のオブジェクトに依存しない、独立した単一目的のページを作成します。例えば、複数のオブジェクトから情報を集約したカスタムダッシュボードや、特定の業務フローをガイドするウィザード形式のページなどが該当します。
技術アーキテクトの視点では、Lightning App Builder は、ビジネス要件を迅速にUIに反映させるための主要なツールであり、プログラマティックな開発(コード開発)と宣言的な開発(クリック操作による設定)のバランスを取る上で極めて重要な役割を担います。
原理の説明
Lightning App Builder の中心的な概念は「コンポーネントベースアーキテクチャ」です。ページは、再利用可能な個々の機能単位である「コンポーネント」を組み合わせることで構築されます。このページ全体の定義は、FlexiPage というメタデータ型として保存されます。
FlexiPage とコンポーネント
FlexiPage は、ページのテンプレート(ヘッダーとサイドバーの有無など)、コンポーネントの種類、配置、および各コンポーネントのプロパティ設定を定義した XML ベースのメタデータです。SFDX (Salesforce DX) を用いてソースコードとして管理・デプロイすることも可能です。
ページに配置できるコンポーネントは、主に3つのカテゴリに分類されます。
- Standard Components (標準コンポーネント): Salesforce が標準で提供するコンポーネントです。「詳細」「関連リスト」「Chatter」「レポートグラフ」など、すぐに利用できる多種多様なコンポーネントが含まれます。
- Custom Components (カスタムコンポーネント): 開発者が作成した独自のコンポーネントです。Lightning Web Components (LWC) または旧世代の Aura Components を使用して開発します。これにより、標準機能だけでは実現不可能な、極めて柔軟なカスタムUIを構築できます。
- AppExchange Components: Salesforce の公式マーケットプレイスである AppExchange からインストールしたサードパーティ製のコンポーネントです。特定の業界や業務に特化した便利なコンポーネントを簡単に追加できます。
動的なページの実現
Lightning App Builder の真価は、静的なページレイアウトを超える「動的な」表示制御機能にあります。これにより、単一のページで多様なユースケースに対応でき、メンテナンス性が大幅に向上します。
Dynamic Forms (動的フォーム)
従来はページレイアウトで制御していた項目の表示を、Lightning App Builder 上で直接制御できる機能です。これにより、特定の条件(例:商談のフェーズが「完了」の場合のみ特定の項目を表示する)に基づいて、項目や項目セクションの表示/非表示を動的に切り替えることができます。これは、複数のページレイアウトを作成・管理する手間を大幅に削減します。
Dynamic Actions (動的アクション)
ページの強調表示パネルに表示されるアクション(ボタン)を、レコードの項目値などの条件に基づいて動的に制御する機能です。「承認申請」ボタンを特定のプロファイルのユーザーにのみ表示したり、レコードの状況に応じて表示するアクションを変更したりすることが可能です。
コンポーネントの表示ルールの設定
ページ上の任意のコンポーネントに対して、表示/非表示を制御するルールを設定できます。ユーザーのプロファイル、デバイスの種類(デスクトップ/モバイル)、レコードの項目値など、さまざまな条件を組み合わせて、コンポーネントレベルでのきめ細やかな表示制御が可能です。
これらの動的機能により、アーキテクトはユーザーコンテキストに応じて最適な情報とアクションを提供し、ユーザーの生産性を最大化するUIを設計することができます。
示例代码
Lightning App Builder 自体は宣言的なツールですが、その能力を最大限に引き出すには、カスタムの Lightning Web Components (LWC) を開発し、ビルダー上で設定可能にすることが不可欠です。ここでは、App Builder でプロパティを公開し、管理者が設定できるようにする LWC の作成方法を示します。
この例では、挨拶メッセージとタイトルを表示するシンプルなコンポーネントを作成します。これらの文言は、App Builder のプロパティエディタから管理者が自由に変更できるようにします。
1. LWC の HTML ファイル (helloWorld.html)
<!-- developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.get_started_introduction --> <template> <lightning-card title={heading} icon-name="custom:custom14"> <div class="slds-m-around_medium"> <p>Hello, {greeting}!</p> <lightning-input label="Name" value={greeting} onchange={handleGreetingChange}></lightning-input> </div> </lightning-card> </template>
解説: {heading}
と {greeting}
は、JavaScript ファイルで定義されるプロパティにバインドされます。これにより、動的なコンテンツ表示が可能になります。
2. LWC の JavaScript ファイル (helloWorld.js)
// developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.reference_configuration_tags import { LightningElement, api } from 'lwc'; export default class HelloWorld extends LightningElement { /** * @api デコレータは、プロパティを public にし、 * Lightning App Builder で設定可能にするために使用されます。 */ @api heading; @api greeting = 'World'; // デフォルト値を設定 /** * input の値が変更されたときに呼び出されるハンドラ関数。 * この変更はコンポーネント内でのみ有効です。 */ handleGreetingChange(event) { this.greeting = event.target.value; } }
解説: @api
デコレータがキーとなります。これにより、heading
と greeting
プロパティが public API として公開され、コンポーネントの外部(この場合は App Builder)からアクセスおよび設定できるようになります。
3. LWC の設定ファイル (helloWorld.js-meta.xml)
<?xml version="1.0" encoding="UTF-8"?> <!-- developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.reference_configuration_tags --> <LightningComponentBundle xmlns="http://soap.sforce.com/2006/04/metadata"> <apiVersion>58.0</apiVersion> <!-- このコンポーネントを App Builder で利用可能にするには isExposed を true に設定します --> <isExposed>true</isExposed> <!-- コンポーネントを配置できるページの種類を定義します --> <targets> <target>lightning__AppPage</target> <target>lightning__RecordPage</target> <target>lightning__HomePage</target> </targets> <!-- App Builder のプロパティエディタで設定可能な項目を定義します --> <targetConfigs> <targetConfig targets="lightning__AppPage,lightning__HomePage,lightning__RecordPage"> <!-- heading プロパティの設定 --> <property name="heading" type="String" label="Card Heading" description="Enter the heading for the component's card." default="Welcome!"/> <!-- greeting プロパティの設定 --> <property name="greeting" type="String" label="Greeting Message" description="Enter the greeting message." default="World"/> </targetConfig> </targetConfigs> </LightningComponentBundle>
解説: このメタデータファイルが、LWC と Lightning App Builder をつなぐ最も重要な部分です。
<isExposed>true</isExposed>
: このコンポーネントを App Builder のコンポーネントパレットに表示させます。<targets>
: コンポーネントを配置できるページのタイプ(アプリケーションページ、レコードページ、ホームページ)を指定します。<targetConfigs>
: App Builder 上で設定可能なプロパティを定義します。<property>
タグのname
属性は、JavaScript ファイル内の@api
で修飾されたプロパティ名と一致している必要があります。label
やdescription
は、App Builder 上での表示ラベルやヘルプテキストになります。
この LWC を組織にデプロイすると、Lightning App Builder でページを編集する際に、この「helloWorld」コンポーネントが選択可能になり、右側のプロパティパネルで「Card Heading」と「Greeting Message」を自由に変更できるようになります。
注意事項
Lightning App Builder を活用する上で、アーキテクトが考慮すべきいくつかの重要な点があります。
権限 (Permissions)
Lightning App Builder を使用してページを作成・編集するには、ユーザーに「アプリケーションのカスタマイズ」権限が必要です。また、作成したページをエンドユーザーに表示させるには、適切なプロファイルまたは権限セットに対してページを有効化(割り当て)する必要があります。割り当ては、組織のデフォルト、アプリケーションのデフォルト、またはプロファイルとアプリケーションの組み合わせで細かく制御できます。
パフォーマンス (Performance)
ページの表示速度はユーザーエクスペリエンスに直結します。1つのページに多数のコンポーネント、特にデータ量の多いレポートグラフや複雑な処理を行うカスタムコンポーネントを配置しすぎると、ページの読み込み時間が長くなる可能性があります。
- ページ分析ツール: App Builder 内には「分析」ボタンがあり、ページの予測読み込み時間を評価し、パフォーマンス改善のための推奨事項を提示してくれます。設計段階でこのツールを積極的に利用することが重要です。
- コンポーネントの最適化: カスタム LWC を開発する際は、Apex コントローラーへのサーバーコールを最小限に抑える、データを効率的にキャッシュする、といったパフォーマンスのベストプラクティスに従う必要があります。
ガバナ制限 (Governor Limits)
Lightning App Builder 自体は宣言的ツールですが、ページに配置されたカスタムコンポーネントが Apex を呼び出す場合、その Apex 処理は Salesforce の標準的なガバナ制限(SOQL クエリの発行回数、CPU 時間など)に従います。1つのページに複数の Apex を呼び出すコンポーネントが配置されていると、それらの処理が1つのトランザクションとして扱われ、意図せず制限に達する可能性があります。コンポーネント間の依存関係とリソース消費を考慮した設計が求められます。
デプロイとバージョン管理 (Deployment and Versioning)
作成された Lightning ページ (FlexiPage) はメタデータの一部です。そのため、変更セットや SFDX などのメタデータ API を通じて、Sandbox から本番環境へとデプロイする必要があります。カスタムコンポーネントと、それを使用する FlexiPage は必ずセットでデプロイするように管理してください。ソース管理システム (Gitなど) を用いて、FlexiPage メタデータのバージョン管理を行うことを強く推奨します。
まとめとベストプラクティス
Lightning App Builder は、現代の Salesforce アプリケーション開発において不可欠なツールです。宣言的なアプローチにより、開発サイクルを大幅に短縮し、ビジネス部門の要求に迅速に対応することを可能にします。しかし、その真価を最大限に引き出すためには、その背後にあるアーキテクチャと原則を深く理解することが重要です。
ベストプラクティス:
- 標準機能を優先する (Standard First): カスタムコンポーネントを開発する前に、必ず標準コンポーネントで要件を満たせないか検討します。標準コンポーネントは Salesforce によってメンテナンスされ、パフォーマンスも最適化されています。
- 動的機能を積極的に活用する (Embrace Dynamics): 動的フォーム、動的アクション、コンポーネント表示ルールを駆使して、ページレイアウトやレコードタイプの乱立を防ぎます。これにより、単一のページでより多くのコンテキストに対応でき、管理コストが大幅に削減されます。
- 再利用可能なカスタムコンポーネントを設計する (Design for Reusability): カスタム LWC を開発する際は、特定のページやオブジェクトに密結合させず、汎用的で再利用可能な単位で設計します。
@api
を通じてプロパティを公開し、App Builder 上で柔軟に設定できるようにすることで、コンポーネントの価値は飛躍的に高まります。 - ユーザー中心の設計を心掛ける (User-Centric Design): 誰が、どのような状況で、何を達成するためにそのページを使うのかを常に意識します。最も重要な情報を最も目立つ場所に配置し、不要な情報はコンポーネント表示ルールで非表示にするなど、UX を最適化します。
- パフォーマンスを常に測定する (Measure Performance): 開発の初期段階から継続的にページ分析ツールを使用し、パフォーマンスのボトルネックを特定・解消します。ユーザーにとって快適な操作性を維持することは、システムの採用と成功に直結します。
結論として、Salesforce 技術アーキテクトは、Lightning App Builder を単なるページ作成ツールとしてではなく、ビジネス要件、ユーザーエクスペリエンス、システムパフォーマンス、そして将来のメンテナンス性といった多角的な視点から、最適なソリューションを構築するための戦略的プラットフォームとして捉える必要があります。
コメント
コメントを投稿