Salesforce Flow Builder 最佳実践：アーキテクトが解説するスケーラブルな自動化設計

背景と適用シナリオ

Salesforce アーキテクトとして、我々は常にプラットフォームの能力を最大限に引き出し、スケーラブルで保守性の高いソリューションを設計するという課題に直面しています。Salesforce の自動化ツールスイートの中でも、Flow Builder (フロービルダー) は、今やその中心的な役割を担う存在となりました。かつてのワークフロールールやプロセスビルダーがその役目を終え、Salesforce が Flow への一本化を推進している現在、Flow を深く理解し、そのアーキテクチャを正しく設計することは、あらゆるプロジェクトの成功に不可欠です。

Flow Builder は、単なる「クリック操作によるコーディング」ツールではありません。これは、複雑なビジネスロジックを宣言的に実装し、ユーザーインタラクションをガイドし、さらには外部システムとの連携をも可能にする、極めて強力なオーケストレーションエンジンです。アーキテクトの視点から見ると、Flow Builder は以下の点で特に重要です。

開発サイクルの短縮: 多くの要件を Apex (エイペックス) コードを書かずに実現できるため、開発コストを削減し、ビジネスの要求に迅速に対応できます。
保守性の向上: ビジネスロジックが視覚的に表現されるため、担当者が変わった場合でもプロセスの理解が容易になります。ただし、これは適切な設計が行われている場合に限ります。
ビジネス部門との連携強化: 視覚的なインターフェースは、ビジネスアナリストや部門担当者が要件を定義し、レビューする際の共通言語となり得ます。

具体的な適用シナリオとしては、以下のようなものが考えられます。

複雑なデータ操作とプロセスの自動化

例えば、「新規の法人顧客が『重要顧客』として登録された際に、関連する商談を自動作成し、専任の営業担当チームを割り当て、さらにウェルカムメールの送信タスクと初回フォローアップの行動を生成する」といった一連のプロセスです。これを単一のトランザクション内で、関連オブジェクトを横断して実行する能力は Flow Builder の得意とするところです。

ガイド付きのユーザーインタラクション

Screen Flow (スクリーンフロー) を使用して、サービスセンターのエージェントが顧客からの問い合わせを処理するためのガイド付きスクリプトを作成します。これにより、エージェントは常に標準化された手順に従うことができ、データの入力ミスや確認漏れを防ぎ、サービス品質の均一化を図ることができます。アーキテクトとしては、このフローをコンソールアプリケーションのどこに配置し、どのようにコンテキスト情報（現在のレコードIDなど）を受け渡すかを設計します。

非同期処理と大量データ処理

Schedule-Triggered Flow (スケジュール起動フロー) を使用して、毎晩すべての「進行中」の商談を評価し、30日以上更新がないものに対して担当者にアラートを送信する、といったバッチ処理を実装します。これにより、同期処理のガバナ制限を回避し、システムのパフォーマンスへの影響を最小限に抑えることができます。

イベント駆動型アーキテクチャの実装

Platform Event-Triggered Flow (プラットフォームイベント起動フロー) を活用し、外部システムから特定のイベント（例：商品の発送完了通知）を受け取った際に、Salesforce 内の注文状況を自動的に更新し、顧客に通知を送信する、といった疎結合なシステム連携を実現します。

原理説明

Flow Builder のアーキテクチャを理解するためには、その主要な構成要素と実行モデルを把握する必要があります。Flow は、内部的には XML ベースのメタデータとして定義され、実行時には Salesforce のランタイムエンジンによって解釈・実行されます。

主要な構成要素

Elements (要素): フローの個々のステップを構成する部品です。
- Interaction (インタラクション): Screen (画面) や Action (アクション) など、ユーザーやシステムとの対話を行います。HTTP Callout (ベータ) もここに含まれ、外部 API との宣言的な連携を可能にします。
- Logic (ロジック): Assignment (割り当て)、Decision (決定)、Loop (ループ) など、プロセスの流れを制御します。
- Data (データ): Create Records (レコードを作成)、Update Records (レコードを更新)、Get Records (レコードを取得) など、Salesforce データベースとのやり取りを担当します。
Resources (リソース): フロー内でデータを保持・操作するための変数や定数です。Variable (変数)、Constant (定数)、Formula (数式)、Text Template (テキストテンプレート) などがあります。アーキテクトとしては、これらのリソースを適切に命名し、スコープを管理することが、フローの可読性と保守性に直結します。
Connectors (コネクタ): 要素間を結びつけ、プロセスの実行パスを定義します。特に Fault Connector (障害コネクタ) を設計に組み込むことは、堅牢なエラーハンドリングを実現するために不可欠です。

フローの実行インスタンス: Flow Interview

Flow が実行されるたびに、Flow Interview (フローインタビュー) と呼ばれる個別のインスタンスが生成されます。これは、特定のユーザーが特定のバージョンのフローを実行している状態を保持するものです。このインタビュー内で、変数の値が保持され、プロセスの進行状況が追跡されます。トランザクションの観点から言えば、一つの Flow Interview は通常、一つのトランザクション内で実行されます。したがって、ガバナ制限（後述）はこのインタビュー単位で消費されることを理解しておく必要があります。

フローの種類とアーキテクチャ上の位置づけ

Record-Triggered Flow (レコードトリガフロー): レコードの作成、更新、削除をトリガーとして起動します。Apex トリガーの代替として機能し、実行コンテキスト（Before-Save/After-Save）の選択がパフォーマンスに大きな影響を与えます。
- Fast Field Updates (Before-Save): トリガーとなったレコード自身の項目を更新する場合に最適です。データベースへの再保存処理が発生しないため、非常に高速に動作します。
- Actions and Related Records (After-Save): 関連レコードの操作、アクションの実行、外部システムへのコールアウトなど、トリガーレコードがデータベースに保存された後に行う処理に使用します。
Screen Flow (スクリーンフロー): ユーザーが操作する画面を持ち、対話的にプロセスを進めます。Lightning ページ、Experience Cloud サイト、ユーティリティバーなど、様々な場所に配置可能です。
Schedule-Triggered Flow (スケジュール起動フロー): 指定した日時に定期的に実行されるバッチ処理フローです。大量のレコードを処理するために設計されています。
Platform Event-Triggered Flow (プラットフォームイベント起動フロー): 特定のプラットフォームイベントメッセージを購読し、イベントが発生した際に起動します。イベント駆動型アーキテクチャの中核を担います。
Autolaunched Flow (No Trigger) (自動起動フロー（トリガなし）): 他のプロセス（Apex、REST API、別のフローなど）から呼び出されるサブフローとして機能します。プロセスの部品化、再利用性を高める上で非常に重要です。

サンプルコード (Invocable Apex)

Flow Builder は非常に強力ですが、宣言的な機能だけでは対応できない複雑な計算やデータ操作、特定の API の呼び出しが必要になる場合があります。このような場合に、Flow の能力を拡張するのが Invocable Apex (呼び出し可能な Apex) です。アーキテクトは、どこまでを Flow で実装し、どこからを Apex に委ねるかの境界線を定義する必要があります。

以下のコードは、Salesforce の公式ドキュメントで紹介されている Invocable Apex の一例です。このクラスは、取引先責任者 (Contact) のリストを受け取り、それぞれの姓 (LastName) に基づいてリード (Lead) を作成するという処理を行います。Flow 内からこの Apex アクションを呼び出すことで、複雑なロジックをカプセル化し、Flow の設計をシンプルに保つことができます。

public class CreateLeadsFromContacts {

    // InvocableMethod アノテーションにより、このメソッドが Flow や他の宣言的ツールから呼び出し可能であることを示します。
    // label: Flow Builder のアクション選択画面に表示される名前
    // description: アクションの機能を説明するテキスト
    // category: アクションを分類するためのカテゴリ名
    @InvocableMethod(label='Create Leads' description='Creates a Lead for each Contact provided.' category='Contact')
    public static void createLeads(List<Contact> contacts) {
        
        // 処理対象のリードを格納するためのリストを初期化します。
        // DML 操作はループの外で行うのがベストプラクティスです。
        List<Lead> leadsToCreate = new List<Lead>();
        
        // Flow から渡された取引先責任者のリストをループ処理します。
        // Flow は自動的に一括処理（バルク化）を考慮してくれるため、Apex 側もリストを扱えるように設計する必要があります。
        for (Contact c : contacts) {
            // 新しいリードオブジェクトを作成します。
            Lead newLead = new Lead();
            // 取引先責任者の姓をリードの姓に設定します。
            newLead.LastName = c.LastName;
            // 会社名は固定値に設定しています（実際のシナリオでは動的に設定することが多い）。
            newLead.Company = 'Salesforce';
            
            // 作成するリードのリストに追加します。
            leadsToCreate.add(newLead);
        }
        
        // リストが空でないことを確認してから DML 操作を実行します。
        // これにより、不要な DML を避けることができます。
        if (!leadsToCreate.isEmpty()) {
            insert leadsToCreate;
        }
    }
}

この Apex クラスを組織にデプロイすると、Flow Builder の「アクション」要素から「Create Leads」という名前で選択できるようになります。Flow 内で取引先責任者のレコードコレクションをこのアクションの入力として渡すだけで、一括でリードを作成する処理が実行されます。

注意事項

Flow Builder をエンタープライズレベルで活用する上で、アーキテクトが特に注意すべき点をいくつか挙げます。

ガバナ制限 (Governor Limits)

Flow も Apex と同様に、Salesforce のマルチテナント環境を保護するためのガバナ制限に従います。特に注意すべきは以下の点です。

トランザクションあたりの DML ステートメント数 (150回): ループ要素内で「レコードを作成」「レコードを更新」などのデータ要素を配置すると、ループの反復ごとに DML が実行され、容易にこの制限に達してしまいます。解決策: ループ内でレコード変数のリスト（コレクション）に新しいレコードや更新対象レコードを追加し、ループを抜けた後で一度にリストを挿入・更新します。
トランザクションあたりの SOQL クエリ数 (100回): DML と同様に、ループ内で「レコードを取得」要素を使用すると、クエリが大量に発行されます。解決策: ループに入る前に、必要なデータをすべて取得してコレクションに格納しておき、ループ内ではそのコレクションを操作します。
トランザクションあたりの合計 CPU 時間 (10秒): 非常に複雑なループや、多数の数式評価が重なると、CPU 時間の制限に達することがあります。処理が複雑すぎる場合は、ロジックを簡素化するか、前述の Invocable Apex を利用して効率的な処理を実装する、あるいはプラットフォームイベントなどを介して非同期処理に分割するなどの設計を検討します。

パフォーマンスとスケーラビリティ

アーキテクトは、フローが大量のデータや高頻度のトランザクション下でも安定して動作することを保証しなければなりません。

トリガーの起動条件: Record-Triggered Flow では、可能な限り具体的な起動条件を設定してください。「すべてのレコード更新時」に起動するような汎用的なフローは、不要な実行を招き、システム全体のパフォーマンスを低下させます。
Before-Save vs. After-Save の適切な選択: 前述の通り、トリガーとなったレコード自身の項目更新のみが目的であれば、必ず Before-Save フローを選択してください。これにより、パフォーマンスが劇的に向上します。
堅牢なエラーハンドリング: すべてのデータ操作要素（Get, Create, Update, Delete）やアクション要素には、Fault Connector を接続し、エラー発生時の処理パスを明示的に設計してください。エラー内容をカスタムオブジェクトに記録する、管理者に通知する、Screen Flow であればユーザーに分かりやすいメッセージを表示するなど、シナリオに応じた適切なエラー処理は、システムの信頼性を高める上で不可欠です。

バージョン管理とデプロイメント

Flow はバージョン管理機能を備えていますが、デプロイメント戦略には注意が必要です。

デプロイ時の非アクティブ化: 変更セットや DevOps ツールを使用して Flow をデプロイする際は、常に非アクティブな状態でデプロイし、デプロイ先の組織でテストを行った後に手動で有効化することを推奨します。これにより、不完全なフローが本番環境で意図せず実行されるリスクを防ぎます。
テストクラスの重要性: Invocable Apex を使用する場合、その Apex クラスに対する十分なテストカバレッジを持つテストクラスを作成することが必須です。また、Flow 自体の動作も、手動テストや自動テストツール（例：Selenium）を用いて十分に検証する必要があります。

まとめとベストプラクティス

Flow Builder は、Salesforce プラットフォームにおける自動化戦略の核となるツールです。アーキテクトとしてその真価を引き出すためには、単に機能を使いこなすだけでなく、スケーラビリティ、パフォーマンス、保守性といった非機能要件を常に念頭に置いた設計が求められます。

以下に、Salesforce アーキテクトとして推奨する Flow 設計のベストプラクティスをまとめます。

トリガー最適化フレームワークの導入: Apex トリガーにおける「One Trigger per Object」の考え方と同様に、オブジェクトごとに Record-Triggered Flow を整理するフレームワークを導入します。例えば、「1オブジェクトにつき、Before-Save、After-Save、Before-Delete、After-Delete の各コンテキストで1つのフローに集約する」といったルールを設けることで、実行順序の制御が容易になり、予期せぬ競合を防ぎます。
モジュール化と再利用性の追求: 複雑で巨大な単一フローを作成するのではなく、特定の機能を持つ小さな Autolaunched Flow（サブフロー）を複数作成し、メインのフローから呼び出す設計を心がけてください。これにより、各部品のテストが容易になり、他のプロセスでの再利用も可能になります。
厳格な命名規則の適用: フロー本体、変数、要素に至るまで、一貫性のある命名規則を定義し、徹底します。例えば、フロー名は `[Object]_[TriggerContext]_[BriefDescription]`、コレクション変数は `sObjectCollection_AccountsToUpdate` のように、役割とデータ型が名前から推測できるようにします。
常に一括処理を意識した設計: ループ内の DML や SOQL は絶対に避ける、という原則を徹底します。これは Flow 設計における最も基本的かつ重要なルールです。
詳細な説明の記述: フローのプロパティや、各要素、リソースの説明欄を積極的に活用してください。なぜこのロジックが必要なのか、この変数が何を表しているのか、といった「設計の意図」を文書化しておくことで、半年後、一年後の自分自身や後任の担当者を助けることになります。
宣言的機能とコードの境界線を理解する: Flow でできることは Flow で実装し、Flow の苦手なこと（複雑なデータ構造の操作、高度な例外処理、トランザクション制御など）は Invocable Apex に任せるという、適切な役割分担を見極める能力がアーキテクトには求められます。

これらの原則に従って Flow Builder を活用することで、ビジネスの要求に迅速に応えつつも、長期間にわたって安定稼働する、真に価値のある Salesforce ソリューションを構築することが可能になるでしょう。

にゃんこのSalesforce日記

このブログを検索