Salesforce開発とは？宣言的な設定とApex・LWCの線引きとリリース管理を実装目線で解説

Salesforce開発という言葉は、コードを書く作業だけを指していません。オブジェクトと項目を定義する設定作業から、Flowでの自動化、Apexによるサーバサイド処理、LWCでの画面実装までが同じ一つの土俵に載っており、どの層で作るかを決める行為そのものが設計になります。そして作ったものは、サンドボックスを経由して本番組織へ届けるまでが一連の工程です。この記事では、Summer ’26（APIバージョン67.0）時点の公式情報を基準に、四つの実装レイヤの降り方、サンドボックス種別の設計、リリース管理の三方式、開発環境の世代交代を扱います。

まとめ：どの層で作るかと本番へどう届けるかの二つで決まる

Salesforce開発の設計判断は、二つの軸に集約できます。一つ目は実装レイヤの選択です。オブジェクトと項目の設定で表現できる要件にFlowを足さない、Flowで組める自動化にApexを書かない、標準コンポーネントで並べられる画面にLWCを作らない。この順序で上から降りていき、降りられなくなった地点が実装手段になります。逆向きに「将来の拡張性」を理由としてコードを先に選ぶと、保守できる担当者の数が一気に減ります。

二つ目はリリース経路の選択です。変更セットは無料で始められますが、バージョン管理に接続できず、削除の反映もロールバックも持ちません。DevOps CenterはGitHub Cloudなどのリポジトリを前提に置いた無料の後継で、パッケージ型開発とバックプロモーションには踏み込みません。モジュール分割とCI/CDまで要るなら、ソース駆動開発とアンロック済みパッケージへ進みます。組織の規模ではなく、同時に走る変更の本数でこの三つは分かれます。

環境面では2026年に世代交代が起きました。開発者コンソールはLWCを扱えないまま残り、2026年4月14日からオープンベータのWeb Consoleが組織内での調査と小修正を引き取る位置に入っています。設定作業と受託開発の線引きに迷う段階であれば、Salesforce導入支援サービス・Apex開発で要件を切り分けるところから相談できます。

Salesforce開発が指す四つの実装レイヤと着手する順番

Salesforceのカスタマイズ手段は、抽象度の高い順に四層へ整理すると違いが明確です。上の層ほど作る速度が速く、保守できる人が多く、リリースの手間が小さくなります。下へ降りるほど自由度は上がりますが、テストコードとレビューと環境整備の負担が付いてきます。

オブジェクトと項目とバリデーションで業務の土台を組む基本設定層

最初の層はデータモデルです。カスタムオブジェクト、項目、リレーション、入力規則、レコードタイプ、ページレイアウト、権限セットまでがここに入ります。画面から設定するだけで動くため開発とは呼ばれにくいのですが、後続の層はすべてこの構造の上に載ります。

ここで手を抜くと、下の層で取り返しがつきません。参照関係にすべきところを主従関係にした、あるいは一意性を項目の一意設定ではなくApexトリガで担保した。こうした判断は、レコード件数が増えてから作り直すコストが大きくなります。データモデルの見直しは着手前に済ませ、実装が進んでからの変更は避けてください。

Flowが引き受ける業務自動化と画面フローを選べる主な守備範囲

二層目はFlowです。レコード作成後の関連レコード生成、条件分岐を伴う項目更新、承認プロセスの起動、スケジュール実行のバッチ的な処理、そして入力ウィザードとしての画面フロー。定型的な業務ロジックの大半はここで表現できます。

Flowの利点は、変更履歴が設定として残り、管理者が読める形で維持される点にあります。デバッグ機能で実行経路を追えるため、障害時の切り分けも画面上で完結します。逆に、ループ内でレコードを取得する構造や、外部システムの応答を待つ処理は苦手です。

Apexが引き受ける複雑なサーバサイドロジックの具体的な実装範囲

三層目がApexです。複雑なトランザクション制御、大量データのバッチ処理、外部システムへのコールアウト、RESTやSOAPのエンドポイント公開といった、Flowでは表現しきれない処理を担当します。本番デプロイにはテストクラスと75%のコードカバレッジが要求されるため、コードを書く決定はテストを書く決定でもあります。

APIバージョン67.0では、データベース操作の既定がユーザモードになり、sharing宣言のないクラスの既定が with sharing へ変わりました。既存資産を新しいバージョンへ上げる際は、権限を持たないユーザーでの実行が例外になっていないか確認してください。言語仕様とガバナ制限の詳細はApexとは？Salesforce専用のオブジェクト指向言語をガバナ制限と実装目線で解説で扱っています。

LWCが引き受ける独自の画面カスタマイズと具体的な実装の守備範囲

四層目がLightning Web Components（LWC）です。標準のコンポーネントでは表現できない画面表示、複数オブジェクトを横断する入力UI、外部データを取り込んだ描画などを担当します。JavaScriptとHTMLで書き、Lightning Experienceへ埋め込みます。

Summer ’26ではState ManagersがGAになり、データ取得のロジックをコンポーネント本体から切り出して再利用とテストがしやすい形へ寄せられるようになりました。画面層に業務ロジックが染み出す従来の書き方から、状態管理を独立させる書き方へ移す設計判断が取りやすくなっています。

画面まわりの実装手段を三つの選択肢から要件別に選び分ける判断基準

画面の要件は、Lightning App Builderでの組み立て、画面フロー、LWCの三択に落ちます。ここでの選択を誤ると、設定で済んだ画面に保守コストの高いコンポーネントを抱えることになります。

標準コンポーネントの並べ替えだけで要件を満たせる画面の見分け方

レコードページに関連リストとハイライトパネルとカスタムタブを配置するだけなら、Lightning App Builderの範囲です。条件付き表示にも対応しているため、ユーザーのプロファイルやレコードの状態で表示を切り替える程度であれば、ここで完結します。

境目は「1画面の中で複数オブジェクトへ書き込むか」です。参照と単一オブジェクトの編集だけならビルダー、書き込み先が二つ以上に分岐するなら次の層へ進みます。

画面フローで組む入力ウィザードが業務要件として実際に成立する条件

複数ステップの入力を順に進め、途中で分岐し、最後にまとめて保存する。この形は画面フローの得意分野です。管理者が後から項目を足せるため、要件が固まりきっていない業務との相性も良好です。

成立しなくなる条件は二つあります。画面の見た目に細かい要求がある場合と、入力中に外部APIを呼んで結果を即座に反映したい場合です。前者は標準の画面部品の範囲を超え、後者はフローの実行モデルと噛み合いません。

LWCへ降りる判断とState Managersが変えた前提

LWCを選ぶのは、描画の要件が標準部品を超えるか、画面上のデータ操作が状態を持つ場合です。一覧の絞り込みと並べ替えを即座に反映する、キャンバスに図を描く、外部サービスの検索結果を逐次表示する。こうした要件はコンポーネント化が前提になります。

設計面では、データ取得をコンポーネント内に書かず、State Managersや共通モジュールへ切り出す方針を先に決めてください。同じデータを複数のコンポーネントが個別に取りに行く構造は、画面が増えるほど再現しにくい不具合を生みます。外部システムからのデータ取得を伴う場合は、Salesforceのシステム連携とは？API方式の選定とコール上限の設計を実装目線で解説で扱っているコール上限の見積もりを先に済ませます。

本番組織を壊さずに開発するサンドボックス四種の容量と更新間隔

Salesforceの開発は、本番組織のコピーであるサンドボックス上で行います。種別によって容量・更新間隔・複製されるデータが異なり、この違いがそのまま開発プロセスの制約になります。

サンドボックスの種別ごとの容量と更新間隔とデータ複製範囲の早見表

2026年8月時点の主な仕様は次のとおりです。更新間隔は、一度更新してから次に更新できるまでの待機日数を指します。

設定情報（メタデータ）はどの種別でも複製されます。差が出るのはレコードの方で、DeveloperとDeveloper Proはゼロ件から始まります。Partial Copyはサンドボックステンプレートで対象オブジェクトを指定し、オブジェクトあたり概ね10,000件を抽出する仕組みです。

開発用と検証用の役割を分けるサンドボックス環境構成の組み合わせの型

実務でよく取る構成は、担当者ごとのDeveloperサンドボックスを開発用に割り当て、結合検証をDeveloper ProかPartial Copyで行い、リリース前の最終確認をFullで通す三段構えです。担当者が1〜2名で改修が月数件なら、Developer一つと本番の二段でも回ります。

Fullを持たない契約では、性能試験と大量データを伴う移行リハーサルができません。データ移行を含む案件では、Full相当の環境を確保できるかを見積もり段階で確認してください。29日の更新間隔があるため、リリース直前に取り直す運用も組めません。

サンドボックス更新のたびに消えるものと設定を引き継ぐための手当て

サンドボックスを更新すると、その環境で行った未反映の変更は失われます。開発途中のメタデータをサンドボックスにだけ置いている状態は、更新の一手で消える構造です。ソース管理へコミットする運用を先に整えておけば、この事故は起きません。

また、更新直後はメールの送信先や外部連携の接続先が本番を向いている場合があります。テスト用の宛先へ差し替える手順を、更新作業のチェックリストへ組み込んでおいてください。

三つの方式から選ぶリリース管理と適用できる開発規模の判断境界

作ったものを本番へ届ける経路は、変更セット、DevOps Center、ソース駆動開発の三つです。どれを選ぶかで、同時に走らせられる改修の本数と、切り戻しの手数が決まります。

変更セットでリリースを回せる開発規模と頭打ちになる三つの理由

変更セットは追加費用なしで使える組織間のデプロイ機能です。送信側でコンポーネントを選び、受信側で検証してから反映します。改修が月に数件で担当者が一人なら、これで十分に回ります。

頭打ちになる理由は三つあります。バージョン管理へコミットできないため変更履歴が残らないこと、削除の反映とロールバックを持たないこと、環境をまたぐたびにセットを手作業で組み直すこと。改修が並行し始めた時点で、どの変更がどの環境に入っているかを人が記憶で管理する状態になります。

DevOps Centerがリリース管理で埋める範囲と踏み込まない範囲

DevOps Centerは変更セットの後継に位置づけられた無料の機能です。Professional・Enterprise・Performance・Unlimited・Developerの各エディションのLightningで使え、本番組織へ導入します。2026年4月時点で、プラットフォームのネイティブ機能として提供される形へ移りました。

特徴は、GitHub CloudやBitbucket Cloud（ベータ）といったリポジトリを前提に置き、画面操作での変更もコミットとして記録される点です。一方で、パッケージ型開発、バックプロモーション、標準でのCI/CD自動化には踏み込みません。リポジトリはクラウド版が対象で、自社ホスティングのGitは対象外です。

ソース駆動開発とアンロック済みパッケージによる管理が必要になる条件

組織のメタデータを一つの塊として扱うのをやめ、機能単位のパッケージに分割する方式がアンロック済みパッケージです。Salesforce CLIとスクラッチ組織を組み合わせ、リポジトリを真実の所在としてビルドとテストを自動で回します。

この方式が要るのは、複数チームが同じ組織を並行して改修する場合、依存関係を明示して段階的にリリースしたい場合、そして品質ゲートをパイプラインへ組み込みたい場合です。逆に、担当者が数名で改修が逐次的に進む組織では、パッケージ分割の設計コストが便益を上回ります。

開発環境の世代交代と開発者コンソールから次の環境へ移行する判断基準

2026年は、Salesforceの開発環境の選択肢が入れ替わった年でした。従来の二択だった開発者コンソールとVS Codeの間に、新しい選択肢が入っています。

開発者コンソールに現在も残っている用途と継続開発では越えられない限界

開発者コンソールは組織に標準で備わるブラウザ内のツールで、Apexクラスの編集、匿名実行、SOQLクエリの実行、デバッグログの参照ができます。ログインしてすぐ触れる手軽さから、小さな確認作業では今も使われています。

限界は明確です。LWCを扱えず、バージョン管理にも接続できません。エディタとしての支援機能も現代のIDEとは比較になりません。恒常的な開発をここで行う運用は、成果物がどこにも残らない構造を抱えることになります。

Web Consoleのオープンベータで変わる組織内の調査と小規模修正

Web Consoleは2026年4月14日からオープンベータで公開された、組織に組み込まれたブラウザベースの軽量IDEです。管理者のオプトイン制で、既定では無効になっています。開発者コンソールが扱えなかったLWCの参照と編集に対応した点が最大の変更です。

位置づけは、開発者コンソールと本格的なIDEの中間を埋めるものとされています。障害が起きたときに組織内でコードを読み、クエリを流し、その場で小さく直す。この頻度の高い調査作業を引き取る設計です。ベータ段階であり機能等価の置換ではないため、既存の開発フローを丸ごと移す判断はまだ早い段階にあります。

VS Code拡張とCLIを開発の前提にするチーム規模の線引きの目安

チームで開発し、リポジトリで履歴を管理し、テストを自動で回すなら、VS Code拡張とSalesforce CLIが前提になります。Summer ’26ではLWCの編集内容を即座に確認できるLive Preview拡張と、メタデータのXMLを図として読めるMetadata Visualizerが加わりました。CLIは資格情報を既定で伏せる挙動に変わっており、トークンの取得には明示的なコマンドが要ります。

線引きの目安は担当者の人数です。二人以上が同じ組織を触るなら、ローカルにソースを持ってリポジトリで統合する構成へ移した方が、後戻りの手間が小さくなります。内製で抱えるか受託に出すかの判断軸はApexとはの該当章で詳しく扱っています。

Salesforceの上に作らない判断と内製と外注を分ける境目

ここまでは作る前提で書いてきましたが、Salesforce上に実装しない方が総額の安い要件も確実に存在します。採用条件と見送り条件を先に言い切ります。

Salesforce上に業務機能を載せると割高になる三つの判断条件

見送りを検討すべきは三つの場合です。第一に、顧客や商談といったCRMの中核データと関係しない業務を、ライセンス保有者以外も使う前提で作る場合。ユーザー数ぶんのライセンス費が固定費として乗り続けます。

第二に、秒間数百件規模の書き込みや大量の帳票生成といった、プラットフォームの実行制約と正面から衝突する処理を中心に据える場合。第三に、画面の見た目と操作感が要件の中心で、標準UIとの統合に価値がない場合です。この三つに当てはまるなら、外部で作ってAPIで接続する構成を先に比較してください。製品選定そのものを見直す段階であればERP/CRM導入とは？Salesforce・SAP・Dynamicsの選定軸と進め方を解説が参考になります。

Salesforce開発を内製で抱えられる範囲を人数と改修頻度から見積もる

設定層とFlow層までであれば、管理者資格を持つ担当者が一人いれば内製で回せます。ApexとLWCが常時発生する状態になると、テストコードとレビューとリリース管理が付随するため、実質的に二名以上の体制が要ります。

判断の目安は、月あたりのコード改修が三件を超えるかどうかです。超えるなら内製の体制構築を、下回るなら受託に出して社内は設定層に専念する分担が、総コストで有利になりやすい形です。

Salesforce開発を外注する際に成果物の定義へ書いておくべき四項目

Salesforce開発の外注で揉めやすいのは、成果物の所在が組織の中にあるためです。契約と要件定義には、次の四つを明記してください。ソースコードとメタデータをリポジトリで受領すること。テストクラスとカバレッジの水準。サンドボックスの提供範囲と更新の責任者。そしてリリース手順書と切り戻し手順です。

この四項目が空白のまま進むと、開発ベンダーを切り替える段階で組織の中身を読み解く作業から始めることになります。制作物の受領条件は、着手前に決めておく性質のものです。

よくある質問

Salesforce開発にプログラミング経験は必要ですか？

設定層とFlow層だけなら不要です。オブジェクト設計と権限の理解があれば、画面操作で業務要件の相当部分を実現できます。ApexとLWCへ降りる段階でJavaScriptやオブジェクト指向言語の経験が要りますが、そこは分業できる箇所でもあります。まず設定層で作り、降りられなくなった部分だけを開発者へ渡す進め方が現実的です。

開発者コンソールはもう使わない方がよいですか？

小さな確認作業に使う分には差し支えありません。匿名実行でスクリプトを一度流す、デバッグログを読む、といった用途は今も現役です。ただしLWCを扱えず履歴も残らないため、継続的な開発の主戦場にはなりません。2026年4月からオープンベータのWeb Consoleを有効にできる組織なら、調査と小修正はそちらへ寄せる価値があります。

Salesforce開発の学習は書籍と公式教材のどちらから始めるべきですか？

設定層とFlow層は公式の学習コンテンツが手厚く、実際の組織を触りながら進められるため、こちらが先です。書籍が効くのは、Apexの設計パターンやリリース管理の考え方といった、画面操作では身につかない領域になります。版の更新が年3回あるため、書籍の記述と現行の仕様が食い違う前提で読んでください。

変更セットからDevOps Centerへ移行するタイミングはいつですか？

並行して走る改修が二本を超えた時点が目安です。一本ずつ順番に本番へ入れている間は変更セットで足りますが、二本が同じ環境で混ざり始めると、どちらの変更が入っているかを人が管理できなくなります。DevOps Centerは追加費用なしで導入できるため、体制が固まる前に慣らしておく判断も取れます。

サンドボックスはどの種別から契約すればよいですか？

Developerサンドボックスは各エディションに一定数が含まれるため、まずはそこから始めます。追加が要るのは、本番データを使った検証が必要になった段階です。移行リハーサルや性能試験を伴う案件ではFullを、機能検証で少量の実データがあれば足りる案件ではPartial Copyを検討してください。

関連記事

• Apexとは？Salesforce専用のオブジェクト指向言語をガバナ制限と実装目線で解説：コード層へ降りたあとの言語仕様と実行制約を扱っています。
• Salesforceのシステム連携とは？API方式の選定とコール上限の設計を実装目線で解説：外部システムとつなぐ際の方式選定と容量設計です。
• Salesforceとは？CRMの機能・料金・認定資格から導入判断まで解説：開発の前提になる製品全体の機能と料金体系を確認できます。
• ERP/CRM導入とは？Salesforce・SAP・Dynamicsの選定軸と進め方を解説：そもそもどの製品を選ぶかの判断軸を整理しています。