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で明示的に順序制御。 |
解決手順（推奨実行順）
- Setup → Flow Debug Logs を有効化し、対象ユーザーで再現テスト。
- Flow Builderの「Debug」ボタンで実行ステップを可視化、停止箇所を特定。
- 停止箇所がDecision要素 → Entry Condition／Decision Logicの値を確認（NULL扱いに注意）。
- 停止箇所がUpdate Records／Create Records → 実行ユーザー権限とField-Level Securityを確認。
- Loop要素内にSOQL/DMLがある場合は必ずLoop外に出して Bulk 化。
- 本番反映前にChange Set または Salesforce DXでサンドボックス検証。
よくある質問
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 ダッシュボードの一例をご紹介します。数値・社名・部門名はマスキングしていますが、実際に運用されている可視化です。
CRM・営業支援
Salesforce・HubSpot・kintoneの選定から導入・カスタマイズ・定着まで一貫対応。営業生産性を高め、商談化率を改善します。