Salesforce Flow の種類と選び方:自動化の設計の入り口
このページには広告リンクを含みます。
この分野の記事(7本)

もっとカスタマイズしたい:エンジニア向けに開発の入口をたどるストーリー
Salesforceをもっとカスタマイズしたいエンジニア向けに、学ぶ順番をストーリーで案内します。無料の開発環境、SOQL、Salesforce CLI、フローの制限、実行順序、外部連携、資格、キャリアへ進みます。

【図解】Salesforce CLI の始め方:インストール、組織への認証、sf コマンド、生成 AI との安全な組み合わせ
Salesforce CLI のインストールから組織への認証、SOQL の実行、メタデータの取得とデプロイまでを実務の順で解説します。sfdx から sf への移行、Claude Code など生成 AI と組み合わせるときの線引きも図解します。

【図解】Salesforce Developer Edition の始め方|無料の開発環境の作り方、制限、作った後に試すこと
Salesforce Developer Edition は無料の開発環境です。2026年10月時点の作り方、45日で消える条件、データ容量などの制限、Agentforce の扱い、Trailhead Playground や Sandbox との違い、作った後に試す順番を図解します。

Salesforce と外部システムの連携パターン図解:同期・非同期・バッチの選び方
Salesforce の外部システム連携は向きとタイミングで選びます。REST API、Bulk API 2.0、プラットフォームイベント、Salesforce Connect の使い分けを公式の連携パターンから整理しました。

【図解】Salesforce フローのループ内で更新してはいけない理由とコレクション変数の使い方
Salesforce フローのループ内にレコード更新を置くと、DML 150回の上限で止まります。コレクション変数に集めてループの外で1回更新する直し方、SOQL 101エラーの原因、限界までを図解します。

Salesforce レコード保存時の実行順序(Order of Execution)図解
Salesforce の保存時の実行順序を20の手順で図解します。保存前フロー、before トリガー、入力規則、after トリガー、保存後フロー、積み上げ集計、コミットの順番と、設計で起きるつまずきが分かります。

【図解】SOQL の書き方入門|SQL との違い、親子のリレーション、日付リテラル、101エラーまで
SOQL の書き方を SQL との違いから図解します。SELECT * の代わりの項目指定、JOIN の代わりのリレーションクエリ、WHERE と日付リテラル、実行する場所、101 エラーの直し方まで1本で分かります。
自動化の仕事で最初に迷うのは、作り方より「どの種類で作るか」です。ここで選び違えると、あとから直すのが大変になります。このページでは選ぶ順番を先に示し、深い話は個別の記事へ案内します。
Salesforce フローの種類と使い分け
Flow Builder で作る主なフローは5種類です。違いは動くきっかけです。

| 種類 | 動くきっかけ | 向いている仕事 | 向かない仕事 |
|---|---|---|---|
| 画面フロー(Screen Flow) | 人の操作。クイックアクションや Lightning ページなどから起動 | 入力を案内する手続き | 人が関わらない処理 |
| レコードトリガーフロー(Record-Triggered Flow) | レコードの作成・更新・削除 | 項目の自動入力、関連レコードの更新、通知 | 複雑で大量の処理 |
| スケジュールトリガーフロー(Schedule-Triggered Flow) | 決まった日時。1回、毎日、毎週 | 定期的な棚卸しや一括の見直し | 変更の直後に動かしたい処理 |
| プラットフォームイベントトリガーフロー(Platform Event-Triggered Flow) | プラットフォームイベントのメッセージを受信 | 外部からの知らせを受けて動く処理 | レコード変更に素直に反応すれば済む処理 |
| 自動起動フロー(Autolaunched Flow、トリガーなし) | 別のフロー、Apex、REST API などからの呼び出し | 共通の部品として使う処理 | 単独で自動的に動かしたい処理 |
迷いやすいのは「日時」のケースです。毎週月曜に全件を見直すような仕事はスケジュールトリガーフローです。「商談の完了予定日の3日前」のようにレコードごとに時期が違うなら、レコードトリガーフローのスケジュール済みパスが候補になります。レコードの値が変わると、Salesforce が予定を取り消して組み直すためです。
レコードトリガーフロー入門:3つのタイミング
自動化の多くはレコードトリガーフローで作ります。入門でつかむべきことは、保存のどの時点で動くかです。

| 選択肢 | 動く時点 | できること | 判断の目安 |
|---|---|---|---|
| 高速項目更新(Fast Field Updates) | 保存の前 | トリガーレコードの項目更新、カスタムエラーの表示 | 自分の項目を変えるだけならこれ |
| アクションと関連レコード(Actions and Related Records) | 保存の後 | 他のレコードの作成・更新・削除、サブフロー、メールなどのアクション | 他のレコードや通知が必要なとき |
| 非同期パス(Run Asynchronously) | 保存のコミットの後 | 外部システムへの要求など時間のかかる処理 | 元の保存を遅らせたくないとき |
高速項目更新で使える要素として、ヘルプは割り当て(Assignment)、決定(Decision)、レコードを取得(Get Records)、ループ(Loop)を挙げています。サブフローやアクションは呼べません。逆に言えば、これらで足りるなら高速項目更新を選びます。
理由は再保存です。保存の後に同じレコードを更新すると、2回目の DML が走り、レコードがまた保存の手順を通ります。保存前に値を入れれば、この2回目の保存がありません。Salesforce Architects の判断ガイドも、トリガーレコードの項目だけを変える自動化は保存前で行うよう勧めています。
一点、よく見かける「高速項目更新は10倍速い」という話には注意が必要です。Trailhead とヘルプにある10倍の比較相手は Process Builder のレコード変更プロセスで、高速項目更新とアクションと関連レコードを比べた数字ではありません。選ぶ基準は速さの倍率ではなく、他のレコードに触る必要があるかどうかです。
エントリー条件では、$Record と $RecordPrior を比べて、特定の項目が変わったときだけ動くようにします。判断ガイドは、この絞り込みと保存前の更新を性能に効く手段として挙げています。保存後フローの再帰もこの方法で防げます。
フローのガバナ制限の考え方
Salesforce は複数の組織で基盤を共有しているため、1トランザクションで使える量に上限があります。フローの主な上限は次の通りです。
| 項目 | 1トランザクションの上限 | フローで消費する主な要素 |
|---|---|---|
| SOQL の回数 | 100回 | レコードを取得、絞り込み条件つきのレコードを更新・削除 |
| 取得できる行 | 50,000行 | レコードを取得 |
| DML の回数 | 150回 | レコードを作成・更新・削除 |
| DML の対象行 | 10,000行 | レコードを作成・更新・削除 |
| CPU 時間 | 10秒 | 計算、ループ、数式など |
考え方は3つです。
- 枠は共有する。Apex などから呼ばれたフローは、呼び出し元と同じ枠を使います。Trailhead の例では、9秒かかる Apex クラスに2秒のフローが続くと、合計で10秒を超えて両方失敗します。
- ループの中が危ない。ループ内の要素は1件ごとに実行されるため、取得や更新の要素を置くと回数がそのまま増えます。直し方はループ内DMLの記事で図解しています。
- 画面と待機はトランザクションを分ける。画面要素や待機要素で一度止まると、再開時に新しいトランザクションが始まります。
なお、かつてあった「1回の実行で2,000要素まで」という上限は、API バージョン 57.0 で廃止されました。ヘルプによると、56.0 以前では2,000要素までです。古いブログを読むときは注意してください。
上限を超えると、障害パスを用意していてもトランザクション全体がロールバックされます。障害パスは個々の要素の失敗に備えるもので、ガバナ制限の超過からは救えません。
フローと Apex の分かれ目
すべてをフローで作る必要はありません。判断ガイドは、1オブジェクトあたりの自動化の数や処理件数で目安を示しています。
| 密度 | 自動化の数 | 処理の規模 | 下流の DML | 向く手段 |
|---|---|---|---|---|
| 低 | 15未満 | 1〜200件 | 0〜1 | レコードトリガーフロー |
| 中 | 15〜30 | 標準のバッチで慎重なバルク化が要る | 2〜4 | フロー+呼び出し可能な Apex |
| 高 | 30超 | 2,000〜10,000件以上 | 5以上 | Apex トリガーのフレームワーク |
フローには Map や Set がなく、保存点やロールバックも自分では制御できません。データの突き合わせが複雑なとき、途中で取り消す制御が要るときは、Apex を検討します。同じオブジェクトでフローと Apex トリガーを混ぜすぎないことも、判断ガイドが挙げる注意点です。動く順番は保存時の実行順序の記事で確かめられます。
Workflow Rule と Process Builder の扱い
Workflow Rule と Process Builder のサポートは2025年12月31日に終わりました。既存の設定は動き続け、編集や有効化もできますが、不具合の修正やカスタマーサポートは提供されません。新しい自動化はフローで作り、既存の分は Migrate to Flow ツールを使って計画的に移します。
このカテゴリの記事
- ループの中でDMLを使ってはいけない理由とコレクション変数:
Too many SOQL queries: 101などのエラーを直す - 保存時の実行順序を図解:保存前フロー、入力規則、Apex、保存後フローの順番
- 外部システムとの連携パターン:REST API、Bulk API 2.0、プラットフォームイベントの選び方
フローの権限の設計を合わせて考えるならプロファイルと権限セットの記事、資格の学習につなげるならPlatform App Builder の勉強法や資格の一覧が次の読み物です。
よくある質問
- Salesforce フローの種類はどう選べばよいですか?
- Salesforce フローの種類は、動くきっかけで選びます。人の操作なら画面フロー、レコードの作成・更新・削除ならレコードトリガーフロー、決まった日時ならスケジュールトリガーフロー、イベントの受信ならプラットフォームイベントトリガーフロー、別の処理からの呼び出しなら自動起動フローです。
- 高速項目更新とアクションと関連レコードの違いは何ですか?
- 高速項目更新は保存の前に動き、トリガーになったレコード自身の項目更新とエラー表示だけができます。アクションと関連レコードは保存の後に動き、他のレコードの操作、サブフロー、メール送信などのアクションができます。
- Workflow Rule や Process Builder はもう使えませんか?
- Workflow Rule と Process Builder のサポートは2025年12月31日に終わりましたが、既存の設定は動き続け、編集や有効化もできます。ただし修正は提供されないため、新しい自動化はフローで作り、既存の分は Migrate to Flow ツールで移行を計画します。
- フローのガバナ制限はいくつですか?
- フローのガバナ制限は1トランザクションあたり SOQL 100回、取得50,000行、DML 150回、DML の対象10,000行、CPU 10秒です。他の自動化から呼ばれたフローは、呼び出し元と同じ枠を分け合います。