Salesforceの導入サポート、開発・連携を行う(株)FDCのエンジニアチームが、Salesforce LWC開発(Lightning Web Components)の基礎知識から実践的な活用方法まで、わかりやすく解説します。
「LWCって何?」「Auraと何が違うの?」と疑問をお持ちの方でも安心して読み進められる内容です。Salesforceのカスタム画面開発やUI改善をご検討の方は、ぜひ最後までご覧ください。

LWCとは?Salesforce開発の新たなUI標準フレームワーク
LWC(Lightning Web Components)とは、Salesforceプラットフォーム上でWebやモバイルアプリケーションのカスタムUIを構築するためのフレームワークです。W3C(World Wide Web Consortium)が定めるWeb標準規格をベースに設計されており、HTML・JavaScript・CSSという馴染みのある技術を使って開発できるのが大きな特徴です。
Salesforceが公式に提供する開発者ガイドでは、LWCについて次のように説明しています。
「Lightning Web コンポーネント (LWC) は、Salesforce プラットフォーム上で Web、モバイルアプリケーション、デジタルエクスペリエンスの最新のユーザインターフェースを作成するためのフレームワークです。」
LWCはブラウザでネイティブに実行されるコードを基盤としているため、軽量かつ高パフォーマンスなのも大きなメリットです。また、SalesforceはW3CおよびEcma International TC39のメンバーとして、オープンなWeb標準の策定にも貢献しており、LWC自体もオープンソースとして公開されています。
LWCとAuraコンポーネント、どちらを選ぶべきか?
Salesforceには従来から「Auraコンポーネント」という別のUIフレームワークも存在します。LWCとAuraは同一ページ上で共存・相互運用できますが、Salesforce公式では「新規開発にはLWCを選択すること」を推奨しています。
以下の表でLWCとAuraコンポーネントの主な違いを整理します。
| 比較項目 | LWC(Lightning Web Components) | Auraコンポーネント |
|---|---|---|
| 技術基盤 | W3C Web標準(モダンWeb) | Salesforce独自フレームワーク |
| パフォーマンス | 高い(ブラウザネイティブ実行) | LWCに比べてオーバーヘッドあり |
| 学習コスト | Web開発経験者には馴染みやすい | Salesforce固有の構文が多い |
| 今後の方向性 | Salesforceが推奨する標準 | 既存資産としての維持・保守 |
| 相互運用 | Auraコンポーネント内にLWCをネストして使用可能 | LWC内にAuraをネストすることは不可 |
(出典:Salesforce Developer – Lightning Web コンポーネントの使用開始)
相互運用の行がポイントです。AuraからLWCへは一方通行の関係のため、既存のAuraアプリケーションにLWCコンポーネントを段階的に組み込むことはできますが、その逆はできません。既存Aura資産がある組織では、新規パーツだけLWCで開発する「段階的マイグレーション」が現実的な移行戦略です。
LWCコンポーネントのファイル構成と基本的な仕組み
LWCの開発を始める前に、コンポーネントがどのようなファイル構成になっているかを把握しておくことが大切です。基本的にはHTML・JavaScript・XML(メタデータ)の3ファイルで1つのコンポーネントが構成され、必要に応じてCSSファイルも追加されます。
LWCの基本ファイル構造
| ファイル | 役割 | 具体的な内容 |
|---|---|---|
| コンポーネント名.html | テンプレート(画面の構成) | <template>タグ内にUIのマークアップを記述 |
| コンポーネント名.js | ロジック(動作の制御) | クラスベースのJavaScriptでプロパティやメソッドを定義 |
| コンポーネント名.js-meta.xml | メタデータ(設定情報) | コンポーネントの対象API・配置場所などを指定 |
| コンポーネント名.css(任意) | スタイル(見た目の装飾) | コンポーネントスコープのCSSを記述 |
HTMLファイルはかならず<template>タグでラップする必要があります。JavaScriptファイルではESモジュールのimport構文を使い、LightningElementクラスを継承したクラスを定義します。たとえば次のような構成が基本となります。
【HTMLファイル】
<template>
<p>{greeting}</p>
</template>
【JavaScriptファイル】
import { LightningElement } from 'lwc';
export default class HelloWorld extends LightningElement {
greeting = 'こんにちは、Salesforce!';
}
このように、JavaScriptクラスのプロパティをHTMLテンプレート内で{プロパティ名}という形式で参照するデータバインディングがLWCの基本となります。(出典:Salesforce Trailhead – Learn Lightning Web Components for Salesforce)
LWCのライフサイクルフックを理解しよう
LWCコンポーネントには、DOMへの挿入・表示・削除といった各タイミングで自動的に呼び出される「ライフサイクルフック」が用意されています。ライフサイクルフックを適切に使うことで、データ取得の初期化やリソースの解放などを効率よく実装できます。
| ライフサイクルフック | 呼び出しタイミング | 主な用途 |
|---|---|---|
| constructor() | コンポーネントのインスタンス生成時 | 基本的な初期化処理 |
| connectedCallback() | コンポーネントがDOMに挿入されたとき | データ取得・イベントリスナー登録・外部との通信確立 |
| renderedCallback() | コンポーネントが描画(再描画)されるたび | DOM要素への直接操作(無限ループに注意) |
| disconnectedCallback() | コンポーネントがDOMから削除されたとき | イベントリスナーの削除・キャッシュのクリア |
| errorCallback(error, stack) | 子コンポーネントでエラーが発生したとき | エラーハンドリング・エラー画面の表示 |
特にconnectedCallback()はデータ取得やメッセージチャネルの登録など、初期化処理に幅広く活用されます。またdisconnectedCallback()ではconnectedCallback()で登録したリソースをクリーンアップするのが定石です。この2つはペアで設計する習慣をつけておくと、メモリリークやイベントリスナーの二重登録といったバグを防げます。
なお、renderedCallback()は再描画のたびに呼び出されるため、内部でプロパティを変更するとさらに再描画がトリガーされ、無限ループに陥る可能性があります。フラグ変数を使って初回のみ実行する、といったガード処理を必ず入れましょう。(出典:Salesforce Developer – connectedCallback() および disconnectedCallback())
データ連携の要!Wire ServiceとApex連携
LWCでSalesforceのデータを扱う場合、主に「Wire Service(ワイヤサービス)」と「Apex連携」の2つの方法があります。どちらを使うかは操作の種類によって使い分けるのが基本です。
@wireデコレータを使ったデータ取得
ワイヤサービスは、コンポーネントに不変のデータストリームをリアクティブに提供する仕組みです。@wireデコレータを使ってプロパティや関数をデコレートすることで、Salesforceのデータを自動的に取得・更新できます。
- データがキャッシュに存在する場合、ネットワークリクエストなしで取得できる
- リアクティブ変数(
$プレフィックス)の値が変わると自動でデータが再取得される - 読み取り操作(SELECT系)に最適で、作成・更新・削除には不向き
- 取得データは不変オブジェクトのため、変更する場合は浅いコピーが必要
(出典:Salesforce Developer – ワイヤサービスについて)
Apexメソッドを命令的に呼び出す方法
データの作成・更新・削除など、書き込み系の操作にはApexメソッドを命令的に呼び出す方法が適しています。ApexクラスのメソッドにSalesforceの@AuraEnabledアノテーションを付与し、LWC側でインポートして使用します。
- Apexクラスのメソッドに
@AuraEnabled(読み取りキャッシュ可の場合はcacheable=true)を付与 - LWC側でApexメソッドを
importしてPromise形式で非同期呼び出し - 成功時は
.then()、エラー時は.catch()でハンドリング - データ変更(INSERT/UPDATE/DELETE)はcacheable=trueを付けないこと
Wire Serviceは宣言的・自動的なデータ取得に、Apex連携は柔軟なビジネスロジック実装に使い分けるのがSalesforce開発のベストプラクティスです。なお、Spring ’26からはGraphQLミューテーション(executeMutation)も正式サポートされたため、レコードの作成・更新・削除をApexを経由せずLWCから直接実行する選択肢も加わりました。
LWC開発環境のセットアップ手順
LWCを開発するためには、適切な開発環境の準備が必要です。Salesforceが推奨する標準的なセットアップは以下の通りです。
必要なツールと準備
- Salesforce CLI(SF CLI)のインストール:Salesforceの組織との接続・デプロイ・プロジェクト管理を行うコマンドラインツール。すべての開発作業の起点となるため、最初に確実に設定する
- Visual Studio Code(VS Code)のインストール:Salesforceが公式に推奨するコードエディタ
- Salesforce Extension Pack(VS Code拡張機能)の導入:コードの補完・Lint・組織との連携機能を提供。LWCコンポーネントのひな形作成やデプロイがGUI操作でも行えるようになる
- Salesforce Developer Edition組織の取得:無料で利用可能なSalesforce開発専用環境
- Dev HubおよびScratch組織の活用:複数の開発・検証組織を使い分けたい場合に有効。チーム開発では事実上必須
初心者の方にはとくにVS CodeとSalesforce CLIの組み合わせから始めることを強くおすすめします。Spring ’26以降はTypeScriptサポートも正式対応しているため、@salesforce/lightning-typesパッケージを導入すれば型安全な開発環境を最初から整えることも可能です。(出典:Salesforce Developer – Lightning Web コンポーネントの使用開始)
LWC開発で押さえておきたい実践的ポイント
基本的な仕組みを理解したうえで、実際の開発現場でよく使われるポイントを整理しておきましょう。
デコレータ(@api・@track・@wire)の使い分け
LWCのJavaScriptでは、プロパティに「デコレータ」を付与することで動作を制御します。
| デコレータ | 用途 | 主な特徴 |
|---|---|---|
| @api | パブリックプロパティの公開 | 親コンポーネントから値を受け取れる。リアクティブ(値が変わると再描画) |
| @track | オブジェクト・配列の深いネスト変更追跡 | Spring ’20以降、プリミティブ型やオブジェクトの直接再代入は自動追跡されるため、深くネストされたプロパティの変更を検知したい場合にのみ使用する |
| @wire | Salesforceデータのリアクティブ取得 | Wire ServiceやApexメソッドと連携してデータを自動プロビジョニング |
実務上最も使用頻度が高いのは@apiと@wireです。@trackは現在のLWCではほとんどのケースで不要になっていますが、配列内のオブジェクトのプロパティを直接書き換えるようなパターン(例:テーブル行の個別編集)では依然として必要になる場合があります。
コンポーネント間のイベント通信
LWCではコンポーネント間でデータをやり取りする際に「カスタムイベント」を使用します。通信パターンはコンポーネントの親子関係によって異なります。
- 子→親へのデータ送信:
CustomEventをthis.dispatchEvent()で発火し、親側でoneventnameハンドラで受け取る - 親→子へのデータ送信:
@apiデコレータを使ってプロパティまたはメソッドを公開し、親から値を渡す - 関係のないコンポーネント間の通信:Lightning Message Service(LMS)を使ったメッセージチャネル経由で通信する。ページ内の離れた場所にあるコンポーネント同士を連携させたい場合に有効
親子間のイベント通信は比較的シンプルですが、LMSを使った通信はメッセージチャネルの定義(XMLファイル)が別途必要になるため、設計段階でどのコンポーネント間にデータの受け渡しが発生するかを整理しておくことが重要です。
Lightning Data Service(LDS)の活用
Lightning Data Service(LDS)を活用することで、Apexコードを書かなくても標準オブジェクトのレコード取得・作成・更新・削除が可能です。lightning-record-formやlightning-record-view-formなどの基本コンポーネントもLDSをベースに動作しています。
LDSの大きなメリットは、複数のコンポーネントが同じレコードを参照している場合にキャッシュを共有し、一方で更新が行われると他方にも自動的に反映される点です。シンプルなCRUD処理はLDSを優先し、複雑なビジネスロジックや複数オブジェクトを横断する処理はApexで対応する、という使い分けが効率的です。
LWC実践事例:よくある活用シーンと実装パターン
LWCはSalesforce上のカスタムUI開発に幅広く活用されています。以下は現場でよく見られる実装事例です。
カスタム入力フォームの作成
標準フォームでは対応できない複雑なバリデーションや条件分岐ロジックをLWCで実装します。たとえば「商品カテゴリの選択に応じて入力項目が動的に切り替わるフォーム」は、@apiプロパティで選択値を子コンポーネントに渡し、条件付きレンダリング(if:true/if:false)で表示を制御する構成が一般的です。標準のlightning-record-edit-formをベースに、カスタムバリデーションだけをJavaScriptで追加するハイブリッドなアプローチも実用的です。
ダッシュボード・データビジュアライゼーション
Apexで集計したデータをLWCでグラフや表として表示し、標準レポートを補完します。Chart.jsなどの外部JavaScriptライブラリを静的リソースとしてアップロードし、renderedCallback()で初期化するパターンが定番です。
Screen Flowとの統合
LWCをフローのカスタム画面コンポーネントとして組み込むことで、業務プロセスの自動化と視覚的なUIを両立できます。.js-meta.xmlで<target>lightning__FlowScreen</target>を指定し、@apiプロパティでフロー変数との入出力を定義します。
Experience Cloud(旧Community)への適用
外部ユーザー向けポータルサイトのカスタムコンポーネントとしてLWCを活用できます。.js-meta.xmlでlightningCommunity__Pageをターゲットに追加することで、Experience Builderからドラッグ&ドロップで配置可能になります。
モバイル対応UI
SalesforceモバイルアプリやField Service Lightning向けにレスポンシブなUIを構築します。SLDS(Salesforce Lightning Design System)のグリッドシステムを活用することで、デスクトップ・タブレット・スマートフォンに対応したレイアウトを効率的に実装できます。
(参考:Salesforce Developer – Lightning Web Components 開発者ガイド)
2026年最新|Spring ’26で追加されたLWC関連の新機能
2026年2月より順次展開されているSpring ’26リリースでは、LWC開発に直結する重要なアップデートが含まれています。
- 動的イベントリスナー(lwc:on ディレクティブ):HTMLテンプレートに手を加えずに、JavaScriptオブジェクトでイベントリスナーを動的にアタッチできるようになった。動的に要素を生成するコンポーネントでの実装が大幅にシンプルになる
- GraphQLミューテーションの完全サポート:
lightning/graphqlのexecuteMutationメソッドにより、LWCからレコードの作成・更新・削除をApexを経由せず直接実行できるようになった - Lightning基本コンポーネントのTypeScriptサポート:
@salesforce/lightning-typesパッケージの導入により、デプロイ前にコードの型エラーを検出できるようになった。大規模プロジェクトでの保守性向上に貢献する - 複雑なテンプレート式(ベータ):HTMLテンプレート内で三項演算子・オプショナルチェーン・配列メソッドなどをインラインで記述できるようになった。これまでJavaScript側にゲッターを定義していた簡単な条件分岐がテンプレートだけで完結する
特にTypeScriptサポートとGraphQLミューテーションは、開発品質と開発速度の両面で大きな恩恵をもたらします。新規コンポーネントから段階的に導入してみることをおすすめします。
まとめ:LWC開発の始め方と学習ロードマップ
LWCはモダンなWeb技術をベースにしているため、HTML・JavaScript・CSSの経験がある方であれば比較的スムーズに学習を進められます。最初のステップとしては、Trailheadの「Lightning Web コンポーネントのクイックスタート」で実際にコンポーネントを作成し、デプロイまでの一連の流れを体験するのがおすすめです。
一方で、Salesforce固有の仕組み(Wire Service・LDS・ライフサイクルフック・ガバナ制限など)を正しく理解しないと、意図しないパフォーマンス低下やデータ不整合が発生することもあります。基本のHello Worldが動いたら、次は@wireによるデータ取得、その次はApexとの命令的連携、と段階的にステップアップしていくのが効率的な学習ルートです。

Salesforce LWC開発でお困りなら「SFsolution」にご相談ください
ここまでSalesforce LWC開発の基礎と実践事例について解説してきましたが、実際に開発を進めようとすると「社内にエンジニアがいないので外部に依頼したい」「既存のAuraコンポーネントをLWCへ移行したい」といったお悩みが出てくることも少なくありません。
そんな方におすすめなのが、弊社(株)エフ・ディー・シーが提供するSalesforce導入・活用のトータルサポートサービス「SFsolution」です。LWCによるカスタムUI開発はもちろん、ApexやAPIを活用した外部システムとの連携、既存コンポーネントの保守・改修まで包括的に対応しています。「まずは技術的な課題を相談したい」という段階でも大歓迎ですので、お問い合わせまたは資料ダウンロードからお気軽にご連絡ください。
