Salesforceカスタマイズの方法比較｜フロー・Apex・LWC・API連携をどの要件で使うか解説

標準機能だけでは足りない — Salesforceカスタマイズが必要になる理由

Salesforceは世界シェアNo.1のCRMプラットフォームとして、商談管理・顧客管理・レポート作成など幅広い標準機能を備えています。しかし実際に導入した企業の多くが、運用を始めてから「標準機能だけでは自社の業務フローに合わない」と気づくケースが少なくありません。

どこまでが標準機能の範囲で、どこからがカスタマイズ領域なのかを整理しておくことで、自社に必要な開発の規模や方向性を早い段階で見極めることができます。

Salesforce標準機能でできること・できないことの境界線

標準機能が得意とするのは、「一般的な営業プロセスに沿った情報管理」です。取引先・担当者・商談・活動といったオブジェクトへのデータ入力、パイプライン管理、ダッシュボードによる進捗の可視化などは、設定だけで実現できます。

一方で、以下のような要件が出てきたとき、標準機能だけでの対応は難しくなります。

• 入力の手間が大きい：複数オブジェクトにまたがるデータを1画面で入力・更新したい場合、標準の画面レイアウトでは対応できないことがあります。
• 自動化に条件の限界がある：標準の自動化ツールでも多くのことができますが、複数オブジェクトをまたぐ複雑な条件分岐や、外部システムとのリアルタイム連携を伴う処理は、標準の設定範囲を超えます。
• 画面レイアウトが固定されている：標準UIは構造が決まっており、業務に合わせた表示項目の組み替えや、独自のウィジェット配置には限界があります。
• 外部システムとの連携が一方向または単純なものに限られる：基幹システム・ERPや社内データベースとの双方向かつリアルタイムな連携は、標準の連携機能だけでは実現が難しいケースがほとんどです。

カスタマイズが必要になる典型的な業務シーン4つ

具体的にどのような場面でカスタマイズの必要性が生じるのか、代表的なパターンを4つ挙げます。

1. 営業担当者の入力負荷が高く、Salesforceが「使われない」状態になっている：入力フォームが業務の流れと合っていないと、現場が敬遠し、データが蓄積されなくなります。UIの最適化や入力補完の自動化が求められます。
2. 承認フローや通知ルールが複雑で標準のワークフローでは設定しきれない：業種・部門・金額などによって承認経路が変わる場合、標準の承認プロセスでは分岐の数が制約になります。
3. 基幹システムとのデータ同期が必要：受注情報を基幹システムに自動連携したい、あるいは在庫情報をSalesforce上でリアルタイムに参照したいといった要件は、API連携の開発が必要になります。
4. 顧客向けポータルや社内ツールとの統合：Salesforceのデータを活用した独自の顧客対応画面や、社内管理ツールとの連携が必要な場合は、フロントエンドの開発が伴います。

自社の運用課題がこれらのパターンに該当するようであれば、カスタマイズの検討を具体的に進めるフェーズに入っています。次のステップとして、どのカスタマイズ手段がその要件に適しているかを整理することが重要です。

Salesforceカスタマイズ手段の全体マップ — 4つの層で整理する

Salesforceのカスタマイズ手段は多岐にわたりますが、大きく4つの層（レイヤー）に整理すると、自社の要件がどこに当てはまるかを判断しやすくなります。層が上位になるほど技術的な難易度と自由度が上がり、対応できる要件の範囲が広がります。

設定レイヤー：ポイント&クリックで変えられる範囲

最も基本となる層が「設定レイヤー」です。プログラミング知識がなくても、管理画面上の操作だけでカスタマイズできます。具体的には、カスタム項目の追加・ページレイアウトの変更・入力規則の設定・権限セットの管理などが該当します。いわゆるノーコード／ローコードの領域であり、Salesforce管理者が日常的に担う作業の大半はこの層で完結します。

自動化レイヤー：Flowが担うプロセス制御

設定だけでは対応できない「条件に応じた処理の自動実行」を担うのが、自動化レイヤーです。Salesforce Flow（フロー）を使えば、レコードの更新・承認申請の自動化・メール通知のトリガー設定などをビジュアルエディタで構築できます。コーディングは不要ですが、分岐条件や繰り返し処理の設計には一定の業務理解が求められます。

開発レイヤー：ApexとLWCが必要になる境界

Flowの制御範囲を超えた複雑なビジネスロジックや、標準UIでは実現できない独自画面が必要な場合は、開発レイヤーに踏み込むことになります。バックエンドの処理はJavaに近い構文を持つApex（エーペックス）で記述し、フロントエンドの画面はLWC（Lightning Web Components：ライトニングウェブコンポーネント）で構築します。この層からはSalesforce専門のエンジニアが必要になるケースがほとんどです。

連携レイヤー：外部システムとのAPI・ETL連携

Salesforceを社内の基幹システムやSaaSと繋ぐ場合は、連携レイヤーが必要です。REST／SOAP APIによる直接連携、MuleSoftやETLツールを用いたデータ統合、Herokuを活用したアプリケーション拡張などが選択肢になります。この層は技術的な難易度が最も高く、連携先システムの仕様理解も同時に求められます。

以下の表は、4つの層の位置づけを概観したものです。

• 設定レイヤー：管理画面操作のみ／プログラミング不要／カスタム項目・レイアウト・権限管理
• 自動化レイヤー：Flow（ビジュアルエディタ）／ローコード／業務プロセスの自動化
• 開発レイヤー：Apex・LWC（コーディング）／プログラミング必須／複雑ロジック・独自UI
• 連携レイヤー：API・ETL・Heroku／高度な技術知識が必要／外部システム統合

要件を整理する際は、「まず設定レイヤーで対応できないか」を起点に上位層への必要性を検討する順序が、コストと工数を抑えるうえで有効です。

Salesforce Flow（フロー）— ノーコードで業務自動化できる範囲とその限界

Salesforce Flowは、プログラミングの知識がなくても業務プロセスを自動化できる、Salesforceの標準的なノーコードツールです。画面上のフロービルダーを使って処理の流れを組み立てるため、情報システム担当者やスーパーユーザーが自ら設定・運用できる点が大きな特徴です。

Flowで自動化できる代表的な業務パターン

Flowが得意とするのは、「特定の条件が満たされたときに、決まった処理を実行する」というシンプルな自動化です。代表的なユースケースは以下のとおりです。

• レコードの自動更新：商談フェーズが「クローズ済み」に変わったタイミングで、関連する取引先の項目を自動的に書き換える
• メール通知：問い合わせが登録されたとき、担当者や上長に自動でアラートメールを送信する
• 承認フロー：見積金額が一定額を超えた場合に承認申請を起動し、上位者の承認を経てから次のステップに進む
• ガイド付き画面フロー：ユーザーが画面上の質問に答えながら入力を進めると、入力内容に応じてレコードが自動作成される

これらの要件は、コードを一行も書かずに実装できます。ノーコードで対応できるため、開発コストと納期を大幅に抑えられるケースが少なくありません。

Flowでは対応しきれない要件 — Apexが必要になるサイン

一方で、要件の複雑度が上がるにつれて、Flowだけでは対処しきれない場面が出てきます。代表的な限界は次のとおりです。

• 複雑な条件分岐・演算：複数オブジェクトをまたいだ集計や、条件が何重にも絡み合うロジックはFlowでの管理が難しくなります
• 大量データの一括処理：数万件以上のレコードを一度に処理する場合、Flowはガバナ制限（処理件数の上限）に抵触するリスクがあります
• UIの高度なカスタマイズ：独自のボタン配置や動的なフォーム制御など、標準の画面フローを超えた操作性が必要な場合は別の手段が必要です
• 外部システムとのリアルタイム連携：外部APIを呼び出して返り値に応じた処理を行う場合、Flowでも基本的な連携は可能ですが、エラーハンドリングや複雑な応答処理には限界があります

「Flowで済む要件かどうか」を判断するチェックポイントとして、①処理対象のレコード数が数百件以内に収まるか、②条件分岐が3階層以内か、③UIのカスタマイズが不要か——この3点を確認することが一つの目安になります。いずれかに当てはまらない場合は、次のステップとしてApexの活用を検討する必要が出てきます。

Apex — SalesforceのバックエンドをJavaライクに制御するプログラミング言語

Apexとは何か — Salesforce専用のバックエンド言語

Apex（エイペックス）は、Salesforceが提供するサーバーサイドのプログラミング言語です。構文はJava（ジャバ）に近く、Salesforceのサーバー上で直接実行されます。「Apex 読み方」は「エイペックス」が正式で、開発者の間でも一般的にその読み方が使われています。

Salesforceの開発言語としては、フローやLWC（Lightning Web Components）と並ぶ中核的な存在ですが、Apexはとくにバックエンドの業務ロジックを担います。フローでは対応が難しい複雑な条件分岐や大量データの処理を、コードによって精緻に制御できる点が特徴です。

Apexが必要になる要件：複雑ロジック・バッチ・トリガー

次のような要件が出てきた場合、Apexの採用を検討する必要があります。

• 複雑な業務ロジック：複数オブジェクトをまたぐ条件分岐や、フローでは表現しきれない多段階の処理
• バッチ処理：数万〜数百万件のレコードを定期的に一括更新・集計する処理
• トリガー：レコードの作成・更新・削除などの操作を契機に、自動で後続処理を走らせる仕組み
• 外部API呼び出し：SalesforceからHTTPリクエストを送り、外部システムとリアルタイムにデータを連携する処理

フローで対応できる範囲を超えたとき、Apexが現実的な選択肢になります。

Apexを使う際に発注側が押さえておくべきポイント

Apexを活用するには、Salesforceの認定資格（Platform Developer）を持つエンジニアが必要です。一般的なJava経験者でも一定の学習コストがかかるため、開発リソースの確保は早めに検討しておくことをお勧めします。

また、Salesforceにはガバナ制限と呼ばれる処理上限が設けられています。1回のトランザクションで実行できるSOQL（データ取得クエリ）の回数や、処理できるレコード件数に上限があり、制限を超えると処理がエラーになります。この制限を意識した設計が不可欠であるため、要件定義の段階でエンジニアを交えた検討を行うことが重要です。

LWC（Lightning Web Components）— UIカスタマイズに使うフロントエンド技術

LWCとは何か — Salesforceの標準UIを超えるフロントエンド開発

LWC（Lightning Web Components）は、Salesforceが提供する公式のフロントエンドコンポーネントフレームワークです。JavaScriptとHTMLをベースに構築されており、Web標準の仕様に準拠しているため、一般的なフロントエンド開発の知識をそのまま活用できる点が特徴です。

Salesforceの画面はデフォルトで標準レイアウトが提供されますが、LWCを使うことで、その標準UIに縛られない独自の画面を構築できます。「Salesforceの操作画面が自社の業務フローに合っていない」と感じる場面の多くは、LWCによる対応が選択肢になります。

LWCが必要になる典型要件：入力UX改善・カスタム画面・モバイル対応

標準画面では実現が難しく、LWCの活用が検討されやすい要件には、以下のようなものがあります。

• 入力フォームのUX最適化：標準の入力フォームでは項目の表示順や条件分岐に限界があるため、担当者の入力ミスが減らないケースがあります。LWCを使うことで、入力状況に応じて表示項目を動的に切り替えるフォームを実装できます。
• 独自ダッシュボードや一覧画面の構築：複数オブジェクトの情報を1画面に集約した操作画面など、標準レポートでは表現できないレイアウトが必要な場合に使われます。
• モバイル最適化：営業担当者がスマートフォンからSalesforceを操作するケースでは、標準画面がモバイルで使いにくいと感じることがあります。LWCでモバイル向けに最適化した画面を別途用意することが可能です。

ApexとLWCを組み合わせるアーキテクチャの基本

LWCは画面の描画と操作を担い、Apexはデータの取得・加工・保存といったバックエンド処理を担います。この2つを組み合わせることで、「画面からユーザーが入力 → LWCがApexを呼び出す → ApexがSalesforceのデータを処理して結果を返す → LWCが結果を画面に反映する」という一連のフローが実現します。

LWC単体ではデータの複雑な操作は行えず、Apexだけでは画面の表現に限界があります。両者を組み合わせることで初めて、業務要件に即したカスタム画面が完成します。意思決定の観点では、「標準UIでは操作性に問題がある」と感じた時点で、LWCとApexの両方を含む開発スコープを想定しておくことが重要です。

外部API・システム連携 — Salesforceを既存システムと繋ぐ手段の選び方

Salesforceは単体で使うよりも、基幹システムや既存のSaaS・データ基盤と連携させることで本来の価値を発揮します。ただし、連携手段は複数あり、要件によって適切な選択肢が異なります。手段の選び方を誤ると、開発コストの増大や保守性の低下につながるため、発注前に整理しておくことが重要です。

Salesforceが持つ標準APIの種類と使いどころ

Salesforceが標準提供するAPIは、主に以下の3種類です。

• REST API：軽量なデータ取得・更新に適しています。モバイルアプリやWebサービスとのリアルタイム連携に多く使われます。
• SOAP API：エンタープライズ系の基幹システムや、厳密なスキーマ定義が必要な連携に向いています。レガシーシステムとの接続実績が豊富です。
• Salesforce Connect（外部オブジェクト）：外部データベースのデータをSalesforce内に仮想的に表示する仕組みです。データをSalesforceに移行せずに参照・操作できるため、二重管理を避けたい場面で有効です。

Salesforce CMSのコンテンツをHeadless構成で外部サイトに配信する場合も、REST APIを介してコンテンツを取得するアーキテクチャが一般的です。

ETLツール・iPaaS・Herokuとの使い分け基準

API直接連携だけでは対応が難しい要件では、以下の手段を検討します。

• ETLツール（例：Talend、DataSpiderなど）：バッチ処理によるデータ同期に向いています。夜間に基幹システムの売上データをSalesforceに取り込むといった用途が典型例です。
• iPaaS（例：MuleSoft、Zapier、Make）：複数システムを横断するイベント駆動の連携に適しています。MuleSoftはSalesforceの公式製品であり、複雑なAPI管理や大規模連携には最も親和性が高い選択肢です。
• Heroku：Salesforceとの連携を前提としたアプリケーション実行基盤です。Apexでは実現しにくい長時間処理や外部ライブラリを使った処理をHeroku上で動かし、Salesforceと連携する構成が取れます。
• Terraform：Salesforceそのものの連携ツールではありませんが、Salesforce環境のインフラをコードで管理（IaC）する用途で活用されるケースがあります。複数Org（組織）の設定を一元管理したい場合に検討対象になります。

連携要件別の手段選択の目安は以下の通りです。

連携手段の選定は、リアルタイム性・データ量・既存システムの種類・運用体制の4点を起点に整理すると判断しやすくなります。

要件別の選択マトリクス — どの手段を使うべきか判断する

各手段の特徴を把握したうえで、次に必要になるのは「自社の要件にどの手段が合うか」を判断する視点です。ここでは4軸の比較表と、ビジネス要件からの逆引きチャートを示します。発注側がベンダーと要件を議論する際の参照資料としてご活用ください。

技術手段の4軸比較表：Flow・Apex・LWC・API連携

以下の表では、「要件の複雑度」「開発コスト」「内製／外注の難易度」「保守性」の4軸で各手段を比較しています。

内製を前提とする場合はFlowが最も現実的な選択肢です。一方、複雑な業務ロジックやUI改善が必要になる場合は、外注を前提にApexやLWCを検討する流れになります。

ビジネス要件から逆引きする選択チャート

以下は、典型的なビジネス要件ごとの推奨手段です。要件定義の段階でベンダーに相談する際の叩き台として使用できます。

• 承認フローの自動化：Flow（承認プロセス）が第一選択。複数条件の分岐が多い場合はApexを併用します。
• 入力画面の改善・独自UI：LWCが適しています。既存レイアウトの変更だけであればFlowの画面フローで対応できるケースもあります。
• 基幹システムとのデータ連携：API連携が基本です。リアルタイム同期が不要であればMuleSoftや外部ETLツールの活用も選択肢に入ります。
• 大量データの一括処理：ApexのBatch処理が適しています。Flowは大量レコードの処理でガバナ制限（処理上限）に抵触するリスクがあります。
• メール・通知の自動送信：Flowで対応できます。送信条件が単純であれば標準のワークフロールールでも十分なケースがあります。

要件の複雑度と社内体制の両面から判断することで、開発コストと保守負荷のバランスを取りやすくなります。「まずFlowで対応できるか確認し、限界を超える部分にApexやLWCを組み合わせる」という優先順位が、費用対効果の観点からも有効なアプローチです。

Salesforceカスタマイズの費用感 — 手段別の工数・コストの目安

手段別の費用目安と工数イメージ

Salesforceカスタマイズの費用は、選択する手段によって大きく異なります。発注側が予算感を持てるよう、手段ごとの工数・コストの目安を整理します。

• Flow設定：標準機能の範囲で完結するため、内製対応が可能なケースが多くあります。外注する場合でも、シンプルな業務自動化であれば1〜3人日（にんにち：1人が1日で行う作業量）程度が目安です。人工単価（にんくたんか：1人1日あたりの作業費用）を5〜8万円とすると、5〜25万円前後で収まることが少なくありません。
• Apex開発：バックエンドのロジック実装を伴うため、エンジニアの人工単価は8〜15万円程度が相場です。中規模の開発では5〜20人日の工数が発生するケースが多く、50〜200万円前後を想定しておくと現実的です。
• LWC開発：フロントエンドの設計・実装が加わるため、Apex単体よりも工数が増える傾向があります。UI要件が複雑になるほど、20〜40人日規模になることもあります。
• API連携：設計・実装に加え、保守・監視の継続コストが発生します。初期構築だけでなく、連携先システムの仕様変更への対応費用も見込む必要があります。

見積もりをとる前に確認しておくべき要件整理のポイント

費用の精度を高めるには、要件定義の質が直接影響します。「何を自動化したいか」だけでなく、「例外処理の有無」「既存データとの整合性」「承認フローの複雑さ」まで整理しておくことで、見積もりの乖離を抑えられます。

追加費用が発生しやすいパターンとして、要件定義後の仕様変更・テスト工数の過小評価・本番環境への移行作業の見落としが挙げられます。初期見積もりの段階で、これらの項目が含まれているかどうかを確認することが重要です。

内製と外注の判断基準 — Salesforceカスタマイズを誰が担うか

カスタマイズ手段が決まった後に直面するのが、「誰が実装するか」という判断です。内製と外注のどちらが適切かは、技術の難易度・社内リソース・スピード要件の3軸で整理すると判断しやすくなります。

内製で対応できる範囲・外注が必要になる境界線

内製が現実的なのは、FlowやValidation Rule、カスタム項目の追加など、ノーコード・ローコードの範囲に留まる場合です。社内にSalesforce認定管理者（Salesforce Administrator）の資格保有者や、設定変更の経験者がいる組織であれば、こうした変更を継続的に内部で回していくことができます。

一方で、次のいずれかに該当する場合は外注を検討する方が現実的です。

• ApexやLWCによるプログラム開発が必要なケース
• 外部システムとのAPI連携や、複数オブジェクトにまたがる複雑なデータ設計が求められるケース
• 社内エンジニアのリソースが不足しており、開発スピードを確保できないケース

特にApex開発はSalesforceのガバナ制限（Governor Limits：1回の処理で使用できるリソース上限）を意識した設計が必要です。コードを書けるだけでは不十分で、Salesforce特有の実行環境に精通した人材が求められます。

外注先を選ぶ際に確認すべき3つの観点

外注先の選定では、以下の3点を確認することが重要です。

• 技術力：Apex・LWC・API連携の実績があるか。Salesforce認定資格（Platform Developer、Application Architectなど）の保有状況も目安になります。
• 業務理解：自社の商流・承認フロー・データ構造を踏まえた要件定義ができるか。技術だけでなく、業務文脈を読み解く力があるかどうかが、開発品質に直結します。
• 伴走体制：初期開発で終わらず、運用後の変更依頼や追加要件に継続的に対応できるか。Salesforceは定期的なバージョンアップがあるため、リリース後も関係が続く体制が望ましいです。

CLANEは、Salesforceのカスタマイズ開発において要件定義から実装・運用保守までを一貫して担う伴走開発サービスを提供しています。業務フローの整理段階から関与するケースも多く、発注側が判断に迷う局面でも技術と業務の両面から選択肢を整理する支援を行っています。

まとめ — カスタマイズ手段の選択は「要件定義」から始まる

Salesforceのカスタマイズ方法を選ぶ際、技術的な選定より先に取り組むべきことがあります。それは「何を実現したいか」を言語化する要件整理です。手段ありきで進めると、オーバースペックな開発コストが発生したり、逆に標準機能で済む範囲に外注費をかけてしまったりするケースが少なくありません。

手段の選択には、難易度とコストに応じた段階があります。まず検討すべきはFlowによるノーコード自動化です。承認フローや項目の自動更新など、多くの業務要件はここで対応できます。Flowで対応しきれない複雑なロジックや大量データ処理にはApexを、画面レイアウトや操作性の改善にはLWC（Lightning Web Components）を選択します。既存の社内システムとの連携が必要な場合は、外部APIやミドルウェアを介した連携手段を検討する段階に進みます。

この順序で検討することが、Salesforce標準機能の限界を正確に見極め、カスタマイズのコストと範囲を適切にコントロールするうえで重要です。

発注側の次のステップとして、まず社内の業務課題と「標準機能では何が足りないか」を整理することをお勧めします。その整理があってはじめて、ベンダーや開発パートナーとの相談が具体的かつ生産的なものになります。要件が曖昧なままでは、見積もりの精度も提案の質も下がります。カスタマイズの成否は、技術選定よりも要件定義の質に左右されると言っても過言ではありません。