Salesforceで作るとき、標準機能・フロー・Apexをどう選ぶか

3 つの作り方を比べる

公式のガイドでは、フローと Apex はどちらもレコードの取得、条件の分岐、作成・更新・削除ができるとしています。そのうえで、できるかどうかではなく、どう作るか、後で性能や保守にどう響くかで選ぶよう勧めています。[7]

• 作り方 1標準機能項目、数式、入力規則、ページの配置などを、画面の操作だけで設定します。1 行もコードを書かずに組織を広げられます[1][2][3]
• 作り方 2フローFlow Builder で処理の流れを図のように組み立てます。コードをほとんど使わずに、自動化や入力画面を作れます[5][7]
• 作り方 3ApexSalesforce の上で動くプログラミング言語です。複雑な処理や細かな制御が要るときに使い、作る・テストする・保守するには技能のある開発者が要るとされています[7][9]

まず標準機能でできるかを確かめる

値の計算は、数式項目で作れます。数式は、ほかの項目の値をもとに、項目の値を自動で計算します。[2]

保存の前の入力チェックは、入力規則で作れます。保存の前に値が条件に合うかを確かめ、合わなければエラーを出して保存させません。入力規則は、画面に項目が無い場合や API からの保存にも働きます。[3]

1 つのオブジェクトの入力画面なら、公式のガイドは Lightning ページと動的フォームを勧めていて、最も手軽な方法としています。動的フォームでは、表示ルールで項目やセクションの出し分けができます。[8][4]

レコードの変更で動かすならフローから

レコードの作成や更新をきっかけに動く自動化では、公式のガイドはレコードトリガーフローと Apex トリガーの 2 つを柱としています。自動化が少ないオブジェクトでは、レコードトリガーフローを第一の選択としています。[7]

動いたレコード自身の項目を更新するだけなら、保存前に更新するフローが勧められています。ヘルプでは、レコード変更プロセスより 10 倍速く更新できるとしています。[6]

フローには、まとめて処理するための調整や、自動の再試行といった仕組みが組み込まれています。メールの通知や、「完了予定日の 3 日前に動かす」といった日付に合わせた処理（スケジュール済みパス）も、フローに向く用途とされています。[7]

Apex を選ぶ場面

開発者ガイドと公式のガイドでは、次のような場面で Apex を使うとしています。[9][7]

• Web サービスやメールサービスを作るとき。[9]
• 複数のオブジェクトにまたがる、複雑な入力チェックをするとき。[9]
• Flow Builder で対応できない、複雑な業務の処理を作るとき。[9]
• 数千件のレコードを速く処理するときや、Map・Set といったデータ構造を使うとき。[7]
• 保存点やロールバックで、1 回の処理のまとまりを細かく制御するとき。[7]

Apex を本番に出すには、単体テストがコードの 75% 以上を通り、そのテストが成功している必要があります（2026年10月時点）。作る前に、テストを書く手間も見込んでおきます。[10]

規模で選ぶ：自動化の密度

公式のガイドは、1 つのオブジェクトにかかる負荷を「自動化の密度」と呼びます。見るのは、1 回の保存で動く自動化の数、1 回の処理で扱うレコードの数、1 つの更新から連なって起きる別の更新の深さの 3 つです。目安は次のとおりです（2026年10月時点）。[7]

• 密度が低いオブジェクト（自動化が 15 未満、1 回に 200 件程度まで、連なる更新は 0〜1 回）では、レコードトリガーフローを使います。[7]
• 密度が中くらいのオブジェクト（自動化が 15〜30、連なる更新が 2〜4 回）では、フローから呼び出せる Apex（Invocable Apex）を組み合わせます。[7]
• 密度が高いオブジェクト（自動化が 30 を超える、大量のデータを扱う、連なる更新が 5 回以上）では、Apex トリガーを使います。[7]

もう 1 つの原則は、1 つのオブジェクトの自動化の入口を 1 つにそろえることです。同じオブジェクトで、フローと Apex トリガーを入口として混ぜないよう勧めています。今の数だけでなく、先々増える分も見込んで選びます。[7]

どの作り方でも、フローの説明欄やコードのコメントに、何のための処理かを書いておくよう案内されています。[7]