LWCでできること｜Salesforce標準画面の限界を超えるカスタムUI開発の全体像

標準画面では対応しきれない業務要件——なぜLWC開発が選ばれるのか

Salesforceの標準画面は、汎用性を重視した設計になっています。そのため、特定業種・特定業務の細かい要件には対応しきれないケースが少なくありません。「入力項目の並び順を変えたい」「複数オブジェクトの情報を1画面で操作したい」といった要望が現場から上がっても、標準機能の範囲内では実現が難しい場面があります。

こうした課題を解消する手段として注目されているのが、LWC（Lightning Web Components：Salesforceが提供するUIコンポーネント開発フレームワーク）を用いたカスタムUI開発です。

標準レイアウトでは限界になる3つの典型シナリオ

標準画面がボトルネックになりやすいのは、主に次の3つの場面です。

• 複雑な入力フローへの対応：たとえば、受注登録時に顧客情報・商品選択・配送条件を段階的に入力させたいケースです。標準のページレイアウトは単一画面での静的な項目配置を前提としており、条件分岐を伴うステップ形式の入力フローには対応しにくい構造になっています。
• 複数オブジェクトをまたいだ一覧操作：商談・見積・発注を1つの画面でまとめて確認・編集したい場合、標準のリストビューや関連リストでは表示できる情報に限界があります。画面をまたぐ操作が増えるほど、担当者の作業効率は下がります。
• 外部システムとのリアルタイム連携表示：在庫管理システムや基幹システムのデータをSalesforce画面上でリアルタイムに参照したいニーズは多くあります。しかし標準画面では外部APIとの動的な連携表示が難しく、手動での転記作業が残ってしまうケースがほとんどです。

いずれも「標準機能をカスタマイズして乗り切ろう」としても限界があり、業務フローそのものが標準画面に引きずられる形になりがちです。LWC開発が選ばれる理由は、こうした制約をコンポーネント単位で上書きできる柔軟性にあります。

本記事で解説する内容の全体像

本記事では、発注側の意思決定者がLWC開発の可否・範囲・判断軸を整理できるよう、以下の順で解説を進めます。

1. LWCとは何か——Salesforce開発における位置づけと基本的な考え方
2. LWCでできること——開発可能な機能・画面の全体マップ
3. LWCとVisualforceの比較——どちらを選ぶべきかの判断基準
4. LWCでできないこと・限界——設計前に把握しておくべき制約
5. 業務別の開発実例——カスタムUIの具体的な構築イメージ
6. 内製・外注・伴走開発の選び方——プロジェクト設計の判断軸

標準画面の限界を感じている段階から、開発判断を下す手前まで、必要な情報を体系的に確認できる構成になっています。

LWC（Lightning Web Components）とは何か——Salesforce開発における位置づけ

Web標準ベースのコンポーネント開発フレームワーク

LWC（Lightning Web Components）は、Salesforceが提供するフロントエンド開発フレームワークです。HTML・CSS・JavaScriptというWeb標準の技術をそのまま活用して、Salesforce上の画面やUI部品を自作できます。

特定のSalesforce独自言語を習得しなければ開発できなかった以前と比べ、Web開発の知識を持つエンジニアがそのスキルを活かしやすい構造になっています。意思決定者の観点では「既存のWeb開発リソースを流用できるフレームワーク」と捉えると、技術選定や外注先の選定において判断しやすくなります。

Aura ComponentsからLWCへ——Salesforceフロントエンドの変遷

Salesforceのカスタム画面開発は、かつてAura Components（旧称：Lightning Components）が担っていました。Aura ComponentsはSalesforce独自の記法が多く、Web標準との乖離が学習コストや開発工数の増大につながるケースが少なくありませんでした。

これに対してLWCは2019年に正式リリースされ、現在はSalesforceが推奨するフロントエンド開発の現行標準です。Aura ComponentsはLWCと共存・連携できるため、既存資産をすぐに捨てる必要はありませんが、新規開発においてはLWCを選ぶのが基本方針となっています。

LWCが動く場所——App Builder・Experience Cloud・Flow・メール連携など

LWCは、Salesforce内のさまざまな場面で機能します。主な利用場面は以下のとおりです。

• Lightning App Builder：レコード画面やホーム画面へのカスタムコンポーネント配置
• Experience Cloud：顧客向けポータルやパートナーサイトのUI構築
• Flow（フロービルダー）：業務フロー内へのカスタム入力画面の組み込み
• メール・その他連携：Lightning Out機能を使った外部サイトへの埋め込み

これらの場所でLWCを活用することで、標準画面では実現が難しい複雑な入力フォームや独自のデータ表示ロジックを、Salesforceのデータ基盤と接続しながら構築できます。

LWCでできること——開発可能な機能・画面の全体マップ

LWCを活用すると、Salesforce上に構築できる画面・機能の幅は大きく広がります。以下では、代表的な実装対象を業務シーンと紐づけながら整理します。

カスタムフォーム・入力画面——複雑な条件分岐や動的項目制御

標準の入力フォームでは対応が難しい「入力値によって表示項目が変わる」「特定条件下でのみ必須化される」といった動的な制御を実装できます。見積入力や申請フォームなど、業務ルールが複雑な画面に適しています。

一覧・検索画面——独自フィルタリングと表示ロジックの実装

標準のリストビューでは実現できない複合条件の絞り込みや、列の色分け・アイコン表示といった視覚的な強調表示が可能です。営業担当者が案件の優先度を一目で判断できる画面などに活用されています。

ウィザード型UIと多ステップフロー——営業・承認プロセスの可視化

複数ステップにわたる入力を順番に案内するウィザード形式のUIを構築できます。商談の進捗登録や稟議申請など、手順が決まっているプロセスをUI上で誘導することで、入力漏れや手順ミスを減らせます。

ダッシュボードウィジェット——独自集計・外部データとの統合表示

Salesforce内のデータだけでなく、外部APIから取得したデータをリアルタイムで表示するウィジェットを開発できます。基幹システムの在庫情報や外部MAツールのスコアを、Salesforceの画面上に統合表示するケースがあります。

Experience Cloud（旧Community）での顧客向けポータル画面

LWCはExperience Cloud上でも動作するため、取引先企業や顧客が利用するポータルサイトの画面構築にも使用できます。注文状況の確認画面や問い合わせフォームなど、社外ユーザー向けのUIを標準機能の制約なく設計できます。

モバイル対応——Salesforce Mobile Appでの動作

LWCはSalesforce Mobile Appに対応しており、外出先での利用を前提とした画面設計が可能です。営業担当者が訪問先でタブレットから入力する報告フォームや、現場作業員向けのチェックリスト画面などが実装対象として挙げられます。

LWCとVisualforceの比較——どちらを選ぶべきか

技術スタック・パフォーマンス・保守性の違い

LWC（Lightning Web Components）とVisualforceは、どちらもSalesforce上でカスタムUIを構築するための仕組みですが、設計思想も技術的な特性も大きく異なります。

• 技術スタック：LWCはHTML・CSS・JavaScriptという現代的なWeb標準をベースに動作します。一方、VisualforceはSalesforce独自のマークアップ言語（Apexと密に連携）で記述するため、汎用的なWeb開発スキルが活かしにくい構造です。
• パフォーマンス：LWCはコンポーネント単位で描画が制御されるため、画面全体を再読み込みしなくても部分更新が可能です。Visualforceはサーバーサイドレンダリングが主体で、操作のたびにページ全体が再描画されるケースが少なくなく、ユーザー体験の面で差が生じやすいです。
• 保守性：LWCはコンポーネント単位で機能を分割・再利用できるため、修正範囲が局所化しやすいです。Visualforceは画面ごとにロジックが記述されることが多く、変更が他の箇所に波及するリスクがあります。

Salesforceのロードマップ上の位置づけ——どちらが将来安全か

Salesforceは公式にLWCを推奨フレームワークとして位置づけており、新機能・新APIのサポートはLWCを前提に設計されています。Visualforceについては既存資産としての継続利用は認められていますが、新規機能の追加はほぼ行われていない状況です。

将来的なSalesforceバージョンアップへの追従や、新機能との統合を視野に入れるなら、LWCでの開発が安全な選択肢といえます。新規のカスタム開発においてVisualforceを選ぶ積極的な理由は、現時点では見当たりません。

既存Visualforce資産がある場合の移行判断

すでにVisualforceで構築された画面が業務に組み込まれている場合、一律に移行を急ぐ必要はありません。判断軸としては以下が参考になります。

• 改修頻度が高い画面：変更コストが積み上がりやすいため、LWCへの移行を優先する候補になります。
• 新機能との連携が必要な画面：Salesforceの新しいAPIや機能を活用したい場合、LWCへの書き換えが現実的です。
• 安定稼働しており改修予定がない画面：移行コストに対して得られるメリットが小さいため、現状維持が合理的なケースが多いです。

既存のVisualforce資産を活かしながら、新規開発部分からLWCを採用するという段階的な移行アプローチが、実務上は現実的な判断といえます。

LWCでできないこと・限界——設計前に把握しておくべき制約

LWCはSalesforceのカスタムUI開発において強力な選択肢ですが、「LWCがあれば何でも実現できる」と考えると、プロジェクト後半で想定外の壁にぶつかるリスクがあります。設計フェーズに入る前に、LWCの構造的な制約を把握しておくことが重要です。

LWC単体では完結しないロジック——Apexが必要になるケース

LWCはあくまでもUI層の技術です。データの取得・更新・演算といったサーバーサイドの処理は、LWCだけでは完結しません。Salesforceのバックエンドロジックを担うApex（Javaに近い構文を持つSalesforce専用言語）との連携が必要になります。

具体的には、以下のような処理でApexが不可欠になります。

• 複数オブジェクトをまたいだ複雑なSOQL（データベースクエリ）の実行
• 外部システムへのHTTPコールアウト（API呼び出し）
• トランザクション処理や一括データ更新のロジック
• 条件分岐が多い業務ルールの実装

LWCとApexはセットで設計する必要があるため、「LWCのUI部分だけ内製して、ロジックは後回し」という進め方は機能しません。開発スコープを定義する段階でApexの要否を整理しておくことが、スケジュール管理のうえでも重要です。

Salesforceガバナ制限がUIに与える影響

Salesforceはマルチテナント型のクラウドプラットフォームであるため、特定のテナントがリソースを占有しないよう「ガバナ制限」と呼ばれる上限値が設定されています。この制限はLWCの動作にも直接影響します。

たとえば、1回のトランザクションで取得できるSOQLクエリは最大100回、取得レコード数は最大50,000件という上限があります。大量データを扱うリスト画面やダッシュボード型UIを構築しようとすると、この制限に引っかかるケースが少なくありません。

回避策としてはページネーション設計やデータ分割処理が有効ですが、設計段階でガバナ制限を考慮していないと、開発後半で大規模なリファクタリングが発生します。UIの要件を定義する際には、裏側で動くデータ量の見積もりも同時に行う必要があります。

外部APIとのリアルタイム統合における注意点

LWCから外部システムとリアルタイムに連携する場合、いくつかの制約が重なります。まず、LWCから直接外部APIを呼び出すことはできません。必ずApexを経由する必要があり、さらにApexのコールアウトには非同期処理の制約がかかります。

たとえば、画面操作のたびに外部の在庫管理システムやERPへ問い合わせるようなリアルタイム性の高いUI設計は、レイテンシ（応答遅延）やタイムアウトリスクを考慮しなければなりません。Apexのコールアウトには1回あたり10秒のタイムアウト上限があるため、外部システムの応答速度によっては、画面上でエラーが発生する可能性があります。

こうした統合要件がある場合は、中間キャッシュの設計やイベント駆動型の非同期アーキテクチャの採用が現実的な対応策になります。ただしそれ自体が設計コストとなるため、要件定義の段階でリアルタイム性が本当に必要かを業務側と丁寧に確認することが、プロジェクト全体のリスク低減につながります。

LWC開発の実例——業務別カスタムUI構築の具体像

LWCでできることの全体像を把握したうえで、実際の業務にどう当てはまるかをイメージするのは簡単ではありません。ここでは業種・業務ごとの典型的な課題と、LWCによるカスタムUI構築の実装内容、その効果を具体的に示します。

営業支援——商談入力を一画面に集約したカスタムフォーム

営業担当者が商談後に行う入力作業は、標準画面では複数オブジェクトをまたいで操作する必要があり、入力漏れや記録の遅延が起きやすい状況です。商談・活動・提案内容・次回アクションを別々の画面に入力するフローは、現場の負荷が大きく定着しないケースが少なくありません。

CLANEが手がけた営業支援案件では、これらの入力項目を一画面に集約したカスタムフォームをLWCで構築しました。必須項目の動的制御や、入力内容に応じた関連レコードの自動生成も組み込んでいます。結果として入力時間が短縮されただけでなく、商談データの記録率が向上し、マネージャーによるパイプライン管理の精度も改善されました。

カスタマーサポート——問い合わせ対応状況を可視化するウィジェット

サポートチームでは、対応中のケース件数・担当者ごとの負荷・エスカレーション状況をリアルタイムに把握したいというニーズが共通して存在します。標準のリストビューでは条件絞り込みに手間がかかり、チーム全体の状況を俯瞰しにくいという課題があります。

LWCを使うことで、対応ステータスを色分け表示するウィジェットや、担当者別の件数を視覚的に示すダッシュボードコンポーネントを作成できます。Salesforceのケースオブジェクトとリアルタイムで連携するため、別ツールを用意せずに対応状況を一元管理できます。

製造・建設業——工程・案件ステータスを独自UIで管理するケース

製造業や建設業では、案件が複数の工程を経て進行するため、ステータス管理が複雑になりがちです。標準の商談管理では工程の粒度や進捗表現が業務実態と合わず、ExcelやホワイトボードとSalesforceを併用しているケースが多く見られます。

LWCによるSalesforce独自UI構築では、工程をカード形式で横並びに表示するカンバンビューや、条件付きで入力項目を切り替えるステータス管理画面を実装できます。CLANEが関与した製造業の案件では、工程ごとの承認フローとLWCの画面遷移を連動させることで、現場担当者と管理者が同一システム上で進捗を共有できる体制を整えました。

LWC開発を成功させる設計判断——内製・外注・伴走開発の選び方

Salesforceの独自UI構築やLWC開発を進める際、技術的な実現可能性と同じくらい重要なのが「誰が・どこまで・どう開発するか」という体制設計です。この判断を誤ると、開発途中で頓挫するか、完成しても業務に合わないシステムが出来上がるリスクがあります。

内製開発に必要なスキルセットと現実的なハードル

LWC開発を内製化するには、JavaScript（ES6以降）・HTML・CSSの基礎に加え、Salesforceのデータモデルやセキュリティモデルへの理解が必要です。さらに、Apexによるサーバーサイド処理、Lightning Data Serviceの活用、デプロイ管理まで担える人材が求められます。

一般的な情報システム部門でこれらを網羅できるエンジニアを確保することは、難しいケースがほとんどです。特にApexとLWCを組み合わせた複雑な画面制御は、Salesforce専門の開発経験がないと設計品質にばらつきが生じやすくなります。

要件定義なき開発が失敗する理由——業務設計と技術実装の分離リスク

SIerへの丸投げで起きやすい問題が、業務設計と技術実装の分断です。開発会社が「言われた通りの画面」を作っても、現場の業務フローや例外処理が反映されていなければ、リリース後すぐに使われなくなります。

LWC開発でできることの範囲は広い一方、何を作るべきかの判断は業務理解なしには導けません。要件定義の段階で業務担当者・情報システム・開発者が同じ認識を持てていない場合、仕様変更が繰り返され、コストと期間が膨らむ構造になります。

伴走開発という選択——仕様変更・運用フェーズまでを見据えた体制設計

こうした課題に対して有効なのが、業務設計から実装・運用改善までを一貫して支援する伴走型の開発体制です。初期リリースで終わらず、現場からのフィードバックをもとに画面や処理を継続的に調整できる関係が、Salesforceカスタム開発では特に重要です。

CLANEは、ApexとLWCを組み合わせた技術実装と、業務要件の整理・設計を両面で担う体制を持っています。情報システム担当者が技術仕様を詳細に定義できない段階からでも、業務課題を起点に開発範囲を整理することが可能です。これにより、「作ったが使われない」「運用に入ってから要件が変わる」といった典型的な失敗を回避しやすくなります。

まとめ——LWCの活用可否を判断するためのチェックリスト

LWC（Lightning Web Components）開発の概要から設計判断の軸まで、ここまで整理してきました。最後に、自社へのLWC適用を検討する際に問うべき確認項目をまとめます。導入可否の判断材料として、以下のチェックリストをご活用ください。

業務要件の観点

• 標準のLightning画面やアプリケーションビルダーで、現在の業務フローを再現できているか——できていない操作手順や画面遷移がある場合、LWC開発の検討対象になります。
• 複数オブジェクトをまたぐ入力・参照・更新を、一画面で完結させる必要があるか——標準画面では対応が難しい要件であり、Salesforceでの独自UI構築が有効な典型例です。
• 外部システムとのリアルタイム連携や、条件分岐の多い動的な画面制御が求められるか——要件が複雑なほど、LWC開発によるカスタム実装の優位性が高まります。

開発・保守体制の観点

• JavaScript・HTML・Apex（ApexはSalesforceのサーバーサイド言語）を扱える開発リソースが社内または外部に確保できるか——VisualforceやフローによるノーコードとLWC開発では、必要なスキルセットが大きく異なります。
• Salesforceのバージョンアップへの追従や、リリース後の改修を担う担い手がいるか——LWC開発は初期構築後の保守コストも見越した体制設計が必要です。
• 内製・外注・伴走のどの形態が自社の開発文化・予算・スピード感に合っているか——体制の選択を誤ると、要件定義段階での手戻りやリリース遅延につながるケースが少なくありません。

LWCでできることは広範囲に及びますが、すべての要件にLWC開発が最適解とは限りません。標準機能で対応できる範囲を正確に把握したうえで、それを超える業務要件に絞ってLWC開発を活用するという判断が、導入後の費用対効果を高める基本的な考え方です。