Salesforce Flowが実行されない/エラーで止まる時のデバッグ:起動条件/権限/ループ制限の3大原因と対処

この記事をシェア:
目次 クリックで開く

Salesforce Flowが意図したとおりに動かない時の原因は、「起動条件(Trigger Order / Entry Conditions)」「実行権限(Run As)」「ガバナ制限(Loop / SOQL)」の3つでほぼ決まります。本記事ではFlow Debug LogとFlow Builderのデバッガを使った最短診断と、頻出パターンの解決策を実務視点で解説します。

最短診断:原因の見極めチェックリスト

原因カテゴリ 確認ポイント
起動条件の取りこぼし Trigger OrderのRecord-Triggered Flowで、Before Save/After Save/Async の優先度を誤ると意図したフローが起動しない。
実行ユーザー権限 Run As設定が「Triggering User」のとき、参照権限のないオブジェクトを更新できずエラー。System Administratorで実行する必要がある。
ガバナ制限超過 Loop内でSOQL/DMLを実行するアンチパターン。Loop外でCollectionに集約してBulk DML。
Validation Rule との競合 Flow更新後に Validation Rule で弾かれてロールバック。Validation Rule側のBypass設定が必要。
Apex Trigger との競合 ApexトリガとFlowが同じレコードを更新するとUNABLE_TO_LOCK_ROW が発生。Trigger Orderで明示的に順序制御。

解決手順(推奨実行順)

  1. Setup → Flow Debug Logs を有効化し、対象ユーザーで再現テスト。
  2. Flow Builderの「Debug」ボタンで実行ステップを可視化、停止箇所を特定。
  3. 停止箇所がDecision要素 → Entry Condition/Decision Logicの値を確認(NULL扱いに注意)。
  4. 停止箇所がUpdate Records/Create Records → 実行ユーザー権限とField-Level Securityを確認。
  5. Loop要素内にSOQL/DMLがある場合は必ずLoop外に出して Bulk 化。
  6. 本番反映前にChange Set または Salesforce DXでサンドボックス検証。

Salesforce Flow エラー種別 × 根本原因 × 修正手順 × 再発防止設計 早見表

前のセクションで解決手順の推奨実行順を説明しましたが、Salesforce Flowのエラーはその種類によって根本原因と修正アプローチが大きく異なります。「何度修正してもまた同じエラーが出る」という状況の多くは、表面的な症状への対処ではなく根本原因の設計上の問題を解消できていないことが原因です。以下の表はFlowの主要エラー種別ごとの診断と修正指針をまとめたものです。

エラー種別 典型的なエラーメッセージ・症状 根本原因 修正手順 再発防止設計
ガバナ制限エラー
(CPU時間・DML・SOQL上限)
「Too many SOQL queries: 101」「Apex CPU time limit exceeded」「Too many DML statements: 151」。大量レコードを処理するバルク操作時や複雑な条件分岐Flowで発生しやすい FlowのDMLやSOQLがループ内で繰り返し実行されている「ループ内クエリ問題」。または関連するトリガー・Apexとの合計で制限を超過している「複合制限超過」。1件処理のFlow設計をそのままバルク処理に使い回したことが原因の場合が多い ①デバッグログでどのFlowアクションが制限超過しているか特定する。②ループ内のDML/SOQLをループ外のコレクション操作に変更する(Get Records→Collection Filter)。③大量レコード処理は「Scheduled Flow(バッチ処理)」に変更して1回の実行件数を制限する Flow設計レビューの際に「ループ内にDMLまたはSOQLがないか」を必ず確認するチェック項目を設けるー。10件以上のレコードを扱うFlowは本番リリース前にデータロードツールでバルクテストを実施する
Null値エラー
(NullPointerException系)
「NullPointerException」「Variable has null value」「The flow tried to reference a variable but it has no value」。条件分岐またはApexアクション呼び出し時に頻発する 参照しているレコード・変数がNull(空)のままFlow処理が進んでいる。例えば「取引先の親取引先のメールアドレス」を参照しようとしたが、親取引先が未設定のレコードでFlowが実行された場合。Null値チェックなしの設計が原因 ①エラーが発生した変数がNull になり得る条件を特定する。②Decision要素で「変数がNullかどうか」の条件分岐を追加してNull時の処理ルートを設ける。③Apex呼び出しの場合はApex側でNull チェックを追加する 外部システムのデータを参照するFlowや、オプション項目(任意入力)を参照するFlowには必ずNull値チェックのDecision要素を追加する設計習慣を付ける。Flowテスト時はNull値データも含むテストケースを作成する
レコードロックエラー
(Record Lock / Deadlock)
「UNABLE_TO_LOCK_ROW」「deadlock detected while waiting for resource」。商談ステータス更新・承認処理・外部からのAPIと同タイミングで実行されるFlowで発生 同一レコードに対して複数のFlowまたはApexが同時に更新しようとして競合が発生している「レコード競合状態」。または前のトランザクションがコミットされる前に次のトランザクションが同じレコードを更新しようとしている ①エラーログで競合しているトランザクションを特定する。②同一レコードを更新する複数のFlowを統合して1つのFlowに集約する。③承認プロセスとFlowが同じ項目を更新している場合は実行タイミングを分離する(承認完了後にFlowをトリガーする設計に変更) 同一オブジェクトへの更新を行うFlowは可能な限り統合して1つのFlowにまとめる「Flow統合原則」を設計ガイドラインに定める。外部APIからのレコード更新が多い組織ではOptimistic LockingまたはPlatform Event経由の非同期処理への移行を検討する
項目値エラー
(Field Validation / Formula Error)
「FIELD_CUSTOM_VALIDATION_EXCEPTION」「invalid value for field」「Required fields are missing: [Email]」。レコード保存時またはFlowのUpdate Records要素実行時に発生 Flowが設定しようとしている項目値が入力規則(Validation Rule)またはフィールドの制約(必須項目・選択リスト値・参照制約)に違反している。Flow設計時に入力規則の存在を考慮していなかった設計ミス ①エラーメッセージの項目名から違反している入力規則を特定する(設定→オブジェクトマネージャーで確認)。②Flowが設定している値が入力規則の条件を満たすかチェックする。③入力規則を一時的に無効化して原因を特定してから修正する 新しいFlowを設計する際は対象オブジェクトの入力規則一覧を事前確認するチェック項目をリリースプロセスに含める。「Flowによる更新が発火するタイミングで適用されるValidation Ruleは何か」を設計ドキュメントに記載する

この表で最も頻繁に発生して対処に時間がかかるのが「ガバナ制限エラー(ループ内クエリ問題)」です。「1件処理なら動く、100件だと止まる」という症状はほぼ全てループ内クエリが原因です。修正の核心は「ループの外でGet RecordsしてCollectionで保持し、ループ内はCollectionを参照するだけにする」設計変換です。この設計パターンを身につけるだけで、Flowの本番障害の大半を予防できます。

Salesforce Flow のトリガー設定やループ制限の調整を Claude Code で自動化・補助する場合、どのオブジェクトを読み書きできるか、どの条件で実行を許可するかというアクセススコープと実行ログの設計が先決になります。Flow デバッグ環境への AI の組み込み方や権限設計は Claude Code 導入支援 でご相談いただけます。

Salesforce Flowがエラーで止まるなら、運用設計の見直しという手がありますAurant の営業DX支援は、SFAの運用設計・入力定着からKPIの可視化、kintone・会計システムとの連携までを一貫して支援します。✓ SFA運用・入力定着の設計✓ KPI・パイプラインの可視化✓ kintone・会計との連携営業DX支援を見る →入れたのに使われないSFAを動かすSalesforce運用設計商談データ入力定着・KPI可視化・連携

よくある質問

Process BuilderからFlowへの移行は必須?

Salesforceは2026年12月にProcess Builder廃止予定(公式アナウンス)。Flow への移行は必須です。Flow Migration Toolが提供されています。

Apex Trigger と Flow どちらを優先すべき?

原則 Flow ファースト。複雑なバルクロジック・コールアウト・複雑な条件分岐がある場合のみApex。

Flow のテスト自動化はできる?

Flow Test機能(2024年GA)でカバーできます。Apex Test ほどの粒度はないですが、シンプルなFlowなら十分です。

Async Flow と Subflow の違いは?

Async Flowは非同期実行、Subflowは別Flowを呼び出す再利用パターン。同期SLAが厳しいユースケースは Async が安全です。

Validation Rule との競合を回避するには?

「Skip Validation」カスタム設定を使い、Flow実行時にbypassする運用が標準です。Salesforce公式の Bypass Pattern を確認してください。







参考:Aurant Technologies 実プロジェクトのLooker Studio実装

本記事のテーマを実装段階まで進める際の参考として、Aurant Technologies が支援した複数の実案件で構築した Looker Studio ダッシュボードの一例をご紹介します。数値・社名・部門名はマスキングしていますが、実際に運用されている可視化です。

Aurant Technologies 実プロジェクトの経理DXダッシュボード(勘定科目別×部門別資金分析・Looker Studio実装、数値マスキング済)
Aurant Technologies 実プロジェクトの経理DXダッシュボード(勘定科目別×部門別資金分析・Looker Studio実装、数値マスキング済)

Salesforce活用・営業DXとデータ連携のご相談

Salesforceの定着支援や営業プロセスの可視化、基幹・会計システムとのデータ連携までをまとめて支援します。現在の設定や連携方式が最適かを確認したい、という導入前後のセカンドオピニオンにも対応しています。

営業DX支援を見る → Salesforce連携プラグインを見る →

CRM・営業支援

Salesforce・HubSpot・kintoneの選定から導入・カスタマイズ・定着まで一貫対応。営業生産性を高め、商談化率を改善します。

AT
aurant technologies 編集

上場企業からスタートアップまで、数多くのデータ分析基盤構築・AI導入プロジェクトを主導。単なる技術提供にとどまらず、MA/CRM(Salesforce, Hubspot, kintone, LINE)導入によるマーケティング最適化やバックオフィス業務の自動化など、常に「事業数値(売上・利益)」に直結する改善実績多数。

この記事が役に立ったらシェア: