Salesforce Headless Experience Layerとは？「画面とロジックの分離」とCustom Lightning Typesを解説

投稿日： 2026.08.26
更新日： 2026.08.25

#Salesforce #Headless Experience Layer #Custom Lightning Types

はじめに

Salesforceは2026年4月にHeadless 360の発表の中で、AIエージェントの業務内容と表示方法を分離する新しいUIレイヤーを示しました。
Headless Experience Layerが目指すのは、Salesforce内に蓄積されたデータ、権限、ビジネスロジックを活用しながら、利用者が普段使っているSlack、Teams、モバイルなどに、そのチャネルに合った操作体験を届けることです。

呼称について

Salesforceの公式情報では、このレイヤーについて「Agentforce Experience Layer」と「Headless Experience Layer（HXL）」の両方の呼称が使われています。2026年4月のHeadless 360発表記事は、英語版・日本語版ともに「Agentforce Experience Layer」と表記しています。一方、Headless 360の製品ページや開発者向け記事では「Headless Experience Layer（HXL）」が使われています。本稿では、現在の製品ページと開発者向け情報に合わせ、「Headless Experience Layer（HXL）」に統一します。

 

Headless Experience Layer（HXL）とは

 

同じ業務の「中身」と「見せ方」を分ける

たとえばケース登録には、入力内容を確認し、権限を判定し、Salesforceにレコードを保存するという共通の処理があります。従来、この業務をSalesforce画面、Slack、Webアプリなどで提供する場合、それぞれのチャネル向けに画面と処理のつなぎ込みを個別に用意する必要がありました。
HXLでは、ケース登録のような業務の「中身」はSalesforce側で共通して持ち、利用者が操作する「見せ方」だけを各チャネルに合わせて提供します。これが、よく使われる「業務ロジックとUIを分離する」という表現の意味です。

つまり、「何をするか」は一つにまとめ、「どのように見せるか」は利用場所に合わせます。すべてのチャネルでまったく同じ見た目にするのではなく、共通の業務処理やUI定義を活用しながらSlackではカード、Webではフォームというように、それぞれに合う操作体験として届けることがポイントです。

HXLとMCPの役割の違い

Headless 360では、MCPとHXLがあわせて紹介されることがありますが、両者の役割は異なります。
簡単に整理すると、次の違いです。

• MCP：AIやシステム同士で、データや機能を呼び出す
• HXL：呼び出した業務を、利用者が見て操作できるUIとして届ける

両者は競合するものではなく、組み合わせて利用することも可能です。

項目	MCP	HXL
主な役割	AIやシステム間でデータ・機能を接続する	業務体験を各チャネル向けUIとして届ける
扱うもの	ツール、データ、プロンプト、業務処理	カード、フォーム、承認、候補一覧などのUI
例	Agentforceから外部システムを操作する／外部AIからSalesforceを操作する	検索結果をSlackやWeb上のカードで表示する

 

Agentforceの入出力UIをカスタマイズするCustom Lightning Types

前章では、HXLを「一度作成した画面や操作体験を、複数のUIチャネルで活用しやすくする考え方」として整理しました。では、現在のSalesforceでは、Agentforceが利用者に見せる入力画面や結果画面を、どのようにカスタマイズできるのでしょうか。

 
その具体的な仕組みとしてSalesforceが公式サンプルを公開しているのが、Custom Lightning Typesです。Custom Lightning Typesを利用すると、Apexクラスを入出力に利用するAgentforceアクションなどで、標準表示される入力UIや出力UIを独自のLWCに置き換えられます。
例えば、標準では項目値が縦に並ぶだけの検索結果をカード形式の一覧へ変更したり、複数の入力項目を業務上のまとまりごとに整理したフォームへ変更したりできます。

つまり、Custom Lightning Typesは、Agentforceの会話の中に単なるテキストではなく、利用者が見やすく操作しやすいUIを組み込むための仕組みです。

Custom Lightning TypesとHXLの関係

ここで注意したいのは、Custom Lightning Typesを利用すること自体が、HXL全体の実装を意味するわけではないという点です。
Custom Lightning Typesの公式サンプルから確認できるのは、Agentforceの対応チャネル上で、アクションの入力UIや出力UIを独自LWCへ置き換える仕組みです。一方、HXLが示しているのは、作成した操作体験をSlack、Teams、モバイル、AIクライアントなど、複数の利用場所へ届ける、より広い構想です。

 

入力UIと出力UIを個別に変更できる

Custom Lightning Typesでは、アクション実行前の入力UIと、実行後の出力UIを別々にカスタマイズできます。必要な側だけを変更することも、両方を変更することも可能です。

Editor Override：入力UIを変更する
アクションを実行する前に利用者が入力する画面を、独自のLWCに置き換えます。例えば、価格と割引率を別々の入力欄として並べるのではなく、「価格・割引条件」という一つのまとまりとして表示し、入力範囲や補足説明を加えることができます。
入力漏れを防ぎたい場合や、必須項目、選択肢、範囲指定、項目間の関係を画面上で分かりやすく示したい場合に有効です。
Renderer Override：出力UIを変更する
アクションの実行結果を表示する画面を、独自のLWCに置き換えます。例えば、ホテル検索結果の値を縦に並べるのではなく、ホテルごとのカードとして整理し、名称、価格、空室数などを見やすく表示できます。
検索結果、候補一覧、登録完了など、処理結果を読みやすくしたい場合に有効です。入力UIは標準のまま、出力UIだけを変更する構成も選べます。

標準UIと組み合わせて利用できる

公式サンプルの重要なポイントは、標準のLightning TypesとCustom Lightning Typesを組み合わせられることです。フライト検索の例では、出発地、目的地、旅行日には標準UIを利用し、価格と割引率をまとめた複合条件だけを、Editor Overrideによる独自の入力UIへ置き換えています。
つまりすべての画面を独自LWCで作る必要はありません。標準UIで十分な項目はそのまま利用し、読みづらい検索結果だけをRendererで改善する、入力ミスが起こりやすい部分だけをEditorへ変更する、といった段階的な採用ができます。

公式サンプルを構成する主なファイル

• schema.json：Custom Lightning Typeが扱うデータ構造を定義する
• renderer.json：出力データをどのLWCで表示するかを定義する
• editor.json：入力データをどのLWCで編集・収集するかを定義する
• 出力LWC：lightning__AgentforceOutputをターゲットとして、結果表示を担当する
• 入力LWC：lightning__AgentforceInputをターゲットとして、フォーム入力を担当する
• Apexクラス：アクションの入出力となる複雑なデータ構造と業務処理を定義する

今回比較する3つの方式

本稿では、Salesforce公式のホテル検索・フライト検索サンプルをもとに、Custom Lightning Typesの使い方を3つの方式に整理して比較します。ケース登録への当てはめは、同じ設計パターンを業務ユースケースに置き換えたものです。

なお、Editor Overrideだけを適用し、出力は標準UIのままとする構成も可能です。本稿では、今回参照する2つの公式サンプルに合わせて、以下の3方式を比較します。

方式A：標準UI（UIの追加開発なし）

入力・出力とも標準のLightning Typesに任せます。LWCを追加せず、最小構成で始められます。

方式B：Renderer Override（出力だけ変更）

入力は標準UIのまま、出力だけを独自LWCでカードや一覧として表示します。複雑な検索結果を見やすくしたい場合に有効です。

方式C：Editor + Renderer Override（入力と出力を変更）

入力をEditor Overrideによる独自フォームへ変更し、出力もRenderer Overrideで見やすく整理します。入力ルールや確認を伴う業務に向いています。

方式A：標準UIを利用する場合

例：航空券検索

航空券検索で、出発都市、到着都市、出発日を入力することで該当する航空券を検索することを想定します。入力項目が少なく、入力前に複雑な確認を必要としない場合、標準UIでも十分に成立します。
• 出発都市：選択リストまたはテキスト
• 到着都市：選択リストまたはテキスト
• 出発日：日付

入力画面

航空券を検索する画面の例として、標準UIでは、出発都市、到着都市、出発日などの項目が一般的な入力欄として表示されます。
必要に応じて割引率や金額のフィルター項目を追加することもできますが、標準UIのためデザインはシンプルです。

メリット

• LWC、schema.json、editor.json、renderer.jsonを追加せずに始められる
• PoCや初期検証を短期間で進めやすい
• 入力項目の追加・変更時に、カスタムUI側の追随が不要
• 自然言語から項目値を抽出するAgentforceの強みをそのまま活かせる

デメリット

• 項目の並び、ラベル、強調表示などを業務に合わせて細かく調整しにくい
• 複雑なオブジェクトやコレクション出力では、値が縦に並び、意味を把握しづらくなる場合がある
• 登録結果をカード化したり、関連リンクや次のアクションを分かりやすく配置したりできない
• 入力漏れを防ぐための補足説明や項目間の連動を、専用フォームほど厳密に制御できない

 

方式B：Renderer Overrideで出力UIを変更する

例：ホテル検索

Salesforce公式の「Top-Level Collection Renderer Override」では、ホテル検索アクションの出力を例にしています。入力にはチェックイン日、チェックアウト日、都市などの標準Lightning Typesを使い、ホテル一覧の出力だけをCustom Lightning TypeとLWCで置き換えます。
標準表示では、ホテル名、所在地、部屋タイプ、価格、空室数、ペット可否などの値が連続して表示され、どの値がどのホテルに属するか把握しづらい状態です。Renderer Override後は、ホテルごとにカード化され、ホテル名、所在地、部屋タイプなどが視覚的に整理されます。

出力画面の比較

標準出力 検索にヒットする2つのホテルがテキスト情報で表示される。値が連続して表示され、項目とレコードの対応関係を追いにくい。

カスタマイズされた出力 検索にヒットする2つのホテルがホテル単位のカードとして、名称・空室数・ペット可否・金額などを整理されている

図1：公式ホテル検索サンプルの標準出力とRenderer Override後の比較（公式サンプルを開く）

メリット

• 入力UIは標準のまま利用できるため、入力側の開発・変更範囲を抑えやすい
• 複雑なリストや複合データの可読性を大きく改善できる
• 業務上重要な値を強調し、次のアクションを明確にできる
• 入力UIもカスタマイズする場合と比べて、実装・テスト・保守の範囲を抑えられる

デメリット

• 入力項目の不足や入力ミスは改善できない
• 出力データ構造が変わると、schema.jsonとLWCの追随が必要になる
• チャネルごとの設定フォルダーや表示差異を考慮する必要がある
• ボタンや次処理を追加する場合は、単なる表示以上の状態管理・イベント設計が必要になる

方式C：Editor＋Renderer Overrideで入出力UIを変更する

例：航空券検索

Salesforce公式の「Top-Level Editor and Top-Level Renderer Overrides」では、フライト検索を例に、入力と出力の双方をカスタマイズしています。出発地、目的地、旅行日は標準Lightning Typesを使い、価格と割引率をまとめた複合フィルター部分にはEditor Overrideによる独自の入力UIを使用します。出力では、複数のフライトをカード形式で表示します。
この例が示しているのは、すべての入力を独自UIへ置き換える必要はないということです。標準型で十分な項目はそのまま使い、範囲、補足説明、複数項目のまとまりなど、業務上の意味を持つ部分だけをEditorで置き換えられます。

入力画面と出力画面の比較

標準の入力画面 ・価格・割引率が一般的な入力欄として並び、入力条件や範囲が分かりにくい。 ・各項目の入力条件などの制御も実現範囲が限られる。

カスタマイズされた入力画面 ・「価格と割引率」というまとまりで、範囲や入力意図を分かりやすく提示。 ・LWCをさらにカスタマイズすることでリッチな入力画面にすることも可能。

図2：公式フライト検索サンプルの標準入力とEditor Override後の比較（公式サンプルを開く）

標準の出力画面 ・検索結果の各値が標準形式で連続して表示される ・複数の航空券を比較する際に、価格、便名、時間などの対応関係を追いにくい

カスタマイズされた出力画面 ・航空券ごとにカード化し、出発・到着時刻、価格、割引率などを整理して表示できる ・比較に必要な情報を強調し、候補選択などの次の操作につなげやすい

 

メリット

• 必須項目、入力範囲、選択肢、項目間の関係をUIとして表現できる
• 質問を一つずつ往復するより、複数項目をまとめて入力しやすい
• 入力意図を説明文やレイアウトで伝えられ、データ品質を高めやすい
• 入力から出力まで、業務に合った一貫した操作体験を提供できる

デメリット

• 入力LWCと出力LWCの双方を開発・保守するため、対象範囲が広い
• 入力値の状態管理、バリデーション、アクセシビリティ、エラー表示の設計が必要になる
• 入力LWCではvaluechangeイベントを使って親コンポーネントへ値を通知する必要がある
• 公式サンプルでは、LLMがテキスト入力を要求する場合があるため、UIフォームを選択するようサブエージェントの指示も調整するよう案内されている
• 項目追加や業務ルール変更時に、Apex、型定義、LWC、エージェント指示の整合性を確認する必要がある

 

3方式の比較

観点	標準UI	Renderer Override	Editor + Renderer Override
入力UI	標準表示／会話で収集	標準表示／会話で収集	独自フォームで制御
出力UI	標準表示	独自カード・一覧	独自カード・一覧
主なファイル	追加なし	schema.json renderer.json 出力LWC	入力側：schema.json／editor.json／入力LWC 出力側：schema.json／renderer.json／出力LWC
実装・保守量	小	中	大
得意な業務	検索、要約、単純な登録	検索結果、候補一覧、登録完了カード	申請、承認、複雑な登録、条件指定
入力の確実性	AI解釈や標準型に依存	AI解釈や標準型に依存	必須・範囲・選択肢をUIで制御しやすい
結果の可読性	複雑な構造やリストでは低下しやすい	高い	高い
ケース登録への適性	項目が少なければ十分	最初の有力候補	入力品質を厳密にしたい場合に有効

 
比較すると、標準UIからEditor + Rendererまでを一直線の成熟度として捉えるより、業務ごとに必要な部分だけ置き換える選択肢として捉える方が適切です。Rendererだけを採用しても不完全ということではなく、入力に問題がなければ最も合理的な構成になり得ます。

ケース登録に当てはめるならどれを選ぶか

公式サンプルでは航空券やホテルの検索が題材でした。これをSalesforceの代表的な業務である「ケース（問い合わせ）登録」に当てはめると、業務の性質や求めるデータ品質によって適切な方式は変わります。実務上の判断基準を3つのパターンに分けて整理します。

パターンA：標準UIが向くケース

想定業務：社内ヘルプデスク、シンプルな質問受付
運用イメージ：利用者が「PCが起動しない」「パスワードを忘れた」などと自然言語で入力し、Agentforceが対話を通じて発生日時やエラーメッセージなどを収集します。
選定理由： 開発コストをかけず、Agentforceの「自然言語から情報を抽出する」強みを最も活かせるため、初期検証（PoC）に最適です。

パターンB：Renderer Overrideが向くケース　★最初の有力候補

想定業務：B2Bのカスタマーサポート、問い合わせの一次受付
運用イメージ：要件の聞き取りは対話と標準UIに任せ、登録後の画面だけをカスタマイズします。ケース番号、優先度、回答予定日時（SLA）、担当部署などをカード形式で整理して表示します。
選定理由： 入力側の開発コストを抑えつつ、利用者の「正しく受付されたか？」という不安を解消できるため、実務で最もバランスが良い第一選択肢となります。

パターンC：Editor＋Renderer Overrideが向くケース

想定業務：製品の故障・修理依頼、厳密な業務ルールを伴う申請
運用イメージ：対象製品カテゴリ、12桁のシリアル番号、保証書の有無などを独自フォームで入力させ、必須・文字数・形式・項目間の条件を画面上で制御します。登録後は、受付内容や次の対応をカードで確認できるようにします。
選定理由： 会話の往復だけでは入力ミスが起きやすい複雑な条件がある場合、専用フォームでガードをかけることで、後続処理（部品手配など）のデータ品質を担保しやすくなります。

すべてをフォーム化しないことがポイント

Custom Lightning Typesを活用する際は、すべての入力を独自フォームへ置き換えるのではなく、自然な会話で収集できる項目は標準UIに任せることが重要です。
結果を分かりやすく提示したい部分はRenderer Override、厳密な入力制御が必要な部分だけはEditor Overrideで補います。
Agentforceの対話能力を活かしながら、必要な部分だけをLWCで補うことが、実装量と利用者体験のバランスを取る設計となります。

現時点で確認できる範囲と注意点

ここまで見てきた公式サンプルからは、Agentforceの入出力UIをLWCでカスタマイズできることが確認できます。一方で、同じUIを複数の外部チャネルへどこまで共通展開できるかについては、公式サンプルだけでは判断できない点もあります。

公式サンプルから言えること	公式サンプルだけでは言えないこと
・Agentforceアクションの入出力を独自LWCで表示できる	・同じLWCがSlack、Teams、ChatGPTなどで自動的にネイティブ表示されること
・出力だけ、入力だけ、双方という段階的な構成が可能	・HXLの全機能がすべての顧客組織で一般提供されていること
・標準Lightning TypesとCustom Lightning Typesを併用できる	・チャネル差を意識せず、一つのUI定義だけで完全に共通化できること
・複雑なリストやフォームを、業務に合うUIへ変えられる	・Custom Lightning Typesを使うだけでHXL全体を実装したと言えること

 

 

まとめ

 
項目が少なく入力ルールも単純な業務であれば、まず標準UIで十分です。
登録結果の見やすさや次の操作が課題になった段階でRenderer Overrideを追加する構成は、実装量と効果のバランスが取りやすいでしょう。入力漏れや複雑な条件指定を厳密に制御する必要がある場合は、必要な入力部分にEditor Overrideを適用します。
HXLが目指すのは、単なるチャット回答ではなく、Salesforceの業務ロジックを利用者が普段いる場所へ、操作可能な体験として届けることです。Custom Lightning Typesの公式サンプルは、その将来像を具体的に理解するための有力な材料です。ただし、現時点で確認できるAgentforce内のUIオーバーライドと、複数の外部サーフェスへ共通体験を展開するHXLの完成形は、分けて捉える必要があります。

＜Salesforce＞
弊社ではSalesforceをはじめとするさまざまな無料オンラインセミナーを実施しています！
＞＞セミナー一覧はこちら

また、弊社ではSalesforceの導入支援のサポートも行っています。ぜひお気軽にお問い合わせください。
＞＞Salesforceについての詳細はこちら
＞＞Salesforceの導入支援実績はこちらからご覧いただけます！

医療業界に特化した営業支援、顧客管理(SFA/CRM)のコンサルティングも提供しております。こちらもぜひお気軽にお問い合わせください。
＞＞顧客管理(SFA/CRM)のコンサルティングの詳細はこちら