--- schema_version: "1" id: 6e4b0ce18c8ffea39f0c1aa5e8ee6fc0dfc5a5faab07461713f521549041ace1 title: Operational Excellence - 自動化パターン collection: architect version: current locale: ja-jp portal_url: https://docs.salesforce.com/architect/current/ja-jp/well-architected/guides/operational-excellence-automation-patterns.md canonical_url: https://architect.salesforce.com/docs/architect/ja-jp/well-architected/guide/operational-excellence-automation-patterns.html source_site: architect.salesforce.com content_type: documentation content_hash: b04f2b7ee5c00441a4a153a1e38f721d4a03d21f7d166d22885a7f074fa6890a products: - 適切に設計されたフレームワーク - Architect Site Content Repo --- # Operational Excellence - 自動化パターン
Well-Architected [Operational Excellence](/docs/architect/ja-jp/well-architected/guide/operational-excellence.html)の詳細 → [Automation and Efficiency](/docs/architect/ja-jp/well-architected/guide/operational-excellence.html#automation-and-efficiency) ## KPI と評価指標 **パターン** | 参照すべき場所 | 外観 | | --- | --- | | プラットフォーム \| ダッシュボード | ✅ KPI に関連するすべての総計値が 1 つ以上のダッシュボードに含まれている | | プラットフォーム \| ドキュメント | ✅ すべてのオートメーションの出力は測定可能で期限付き | | プラットフォーム \| ドキュメント | ✅ KPI ごとに説明責任のある関係者がリストされている | **アンチパターン** | 参照すべき場所 | どんな悪い感じか | | --- | --- | | プラットフォーム \| ダッシュボード | ⚠️ KPI レポートが存在しないか、一部の KPI に関連する評価指標がダッシュボードにない | | プラットフォーム \| ドキュメント | ⚠️ KPI は説明責任のある関係者がいなくても存在する | | プラットフォーム \| ドキュメント | ⚠️ 自動化の KPI が存在しないか、測定の期間が明確でない | ## 宣言型自動化 **パターン** | 参照すべき場所 | 外観 | | --- | --- | | プラットフォーム \| フロー | ✅ Flow Builder はレコードトリガー自動化に使用されます (プロセスビルダーとワークフロールールの置き換え) | | プラットフォーム \| フロー | ✅ 保存前実行を含むレコードトリガーフローは、レコード作成前の項目入力に使用されます。 | | プラットフォーム \| フロー | ✅ フローで決定ロジック、ループ、API コールアウト、DML 操作、複雑な複数ステップのオーケストレーションを処理 | | プラットフォーム \| フロー | ✅ 必要に応じてフロートランザクション制御を使用して中間変更を確定 | | プラットフォーム \| フロー | ✅ フローの正常なエラー回復のために障害処理を実装 | | プラットフォーム \| フロー | ✅ 反応型の画面フローで動的なユーザーエクスペリエンスを提供 | | プラットフォーム \| フロー | ✅ 宣言型自動化は、ビジネスユーザーまたは管理者が開発者の関与なしでロジックを変更する必要がある場合に選択します。 | | プラットフォーム \| フロー | ✅ 変数はハードコードされた値を参照しません (レコードタイプ、ユーザーなど)。 | | プラットフォーム \| フロー | ✅ 大量のデータのコンテキストでは、フローがロジックをApexに渡す | | プラットフォーム \| フロー | ✅ サブフローは、ビジネス全体で再利用する必要があるプロセスのセクションで使用されます。 | | プラットフォーム \| フロー | ✅ すべての自動起動フローでは、決定要素や一時停止要素を使用してエントリ条件を評価し、大量のデータに対する無限ループや実行を防止します。 | | プラットフォーム \| フロー | ✅ 既存のシステムデータが使用できない場合にのみデータの提供が求められます | | プラットフォーム \| フロー | ✅ フローは、メインフローとサポートサブフローで構成される階層構造で整理されます。 | | プラットフォーム \| フロー | ✅ すべてのユーザー入力にフロー内の明確な目的がある | | プラットフォーム \| フロー | ✅ 各フローは 1 つの特定の目的を果たす | | プラットフォーム \| フロー | ✅ 各ステップで特定の詳細なタスクを実行 | | プラットフォーム \| フロー | ✅ ユーザーコンテキストで起動されたすべてのフローは、システムコンテキストトランザクションをサブフローに抽象化し、\[一時停止] 要素の後に一貫して配置して新しいトランザクションを作成します。 | | プラットフォーム \| フロー | ✅ すべてのレコードトリガーフローにトリガー順序値が入力されている | | プラットフォーム \| フロー | ✅ 外部システムコールアウトや実行時間の長いプロセスが含まれるフローでは、非同期パスが使用されます。 | | プラットフォーム \| フロー | ✅ Orchestrator で関連データ操作の複雑なシーケンスを作成 (モノリシックフロー内で複数のサブフローを呼び出すのではなく) | | プラットフォーム \| 検証 | ✅ 入力規則、重複ルール、必須項目を使用して、プラットフォームレベルでデータの整合性を適用 | | プラットフォーム \| 検証 | ✅ 入力規則により、保存前に無効なデータ入力を防止 (トリガー入力規則よりも効率的) | | プラットフォーム \| 承認プロセス | ✅ 複数ステップの承認ルーティングで代理承認者との並列および順次承認パスを処理 | | プラットフォーム \| 承認プロセス | ✅ 承認アーキテクチャは例外シナリオ (休暇中のすべての承認者、通常の承認をスキップする緊急のビジネス要件) を考慮します。 | **アンチパターン** | 参照すべき場所 | どんな悪い感じか | | --- | --- | | プラットフォーム \| フロー | ⚠️ 新しい自動化で使用されるプロセスビルダーとワークフロールール (Flow Builder が戦略的方向性) | | プラットフォーム \| フロー | ⚠️ ビジネスユーザーまたは管理者が開発者の関与なしでロジックを変更する必要がある場合に使用されるプログラムによる自動化 | | プラットフォーム \| フロー | ⚠️ フローに障害処理がないため、エラー回復率が低い | | プラットフォーム \| フロー | ⚠️ 変数の値はハードコードされています | | プラットフォーム \| フロー | ⚠️ 一括データ読み込みの前にフローを手動で無効化する必要がある | | プラットフォーム \| フロー | ⚠️ サブフローを使用するのではなく、フローの一部がフロー全体で繰り返される | | プラットフォーム \| フロー | ⚠️ フローで「未対応の例外」通知がトリガーされる | | プラットフォーム \| フロー | ⚠️ 単純なフローでもガバナ制限に関連するエラーが頻繁に発生する | | プラットフォーム \| フロー | ⚠️ フローでは、コンテキストを提供するために追加の入力が必要です。 | | プラットフォーム \| フロー | ⚠️ フローは複数の目的を果たす | | プラットフォーム \| フロー | ⚠️ 関連ステップのグループには、他のフローのステップのグループと重複する機能が含まれています。 | | プラットフォーム \| フロー | ⚠️ フローは、保存されているデータを代わりに使用できる場合にユーザーの入力を求める | | プラットフォーム \| フロー | ⚠️ フローには、データが使用されていない入力が必要です | | プラットフォーム \| フロー | ⚠️ 画面コンポーネントから出力されたコレクションを使用した DML の実行 (画面コンポーネントからコレクションが出力されたときに作成、更新、削除要素の \[レコードまたはレコードコレクションの ID とすべての項目値を使用] 設定を活用) | | プラットフォーム \| フロー | ⚠️ レコードトリガーフローでトリガー順序属性がまったく使用されていない、またはトリガー順序値が一貫して使用されていない | | プラットフォーム \| フロー | ⚠️ 非同期パスが一貫して使用されていない、またはまったく使用されていない | | プラットフォーム \| フロー | ⚠️ 大規模なモノリシックフローでは、関連するデータ操作の複雑なシーケンスを調整します (サブフローの有無は問いません)。 | | プラットフォーム \| 承認プロセス | ⚠️ 承認アーキテクチャは例外シナリオ (休暇中のすべての承認者、緊急のビジネス要件) を考慮しません。 | | プラットフォーム \| 検証 | ⚠️ 入力規則ではなくトリガーでのみデータの整合性が適用される (トリガー入力規則の効率が低く複雑) | ## プログラムによる自動化 **パターン** | 参照すべき場所 | 外観 | | --- | --- | | プラットフォーム \| Apex | ✅ トリガーハンドラーフレームワークにより、オブジェクトごとのシングルトリガー、一括処理、懸念の分離、再帰的な実行防止を適用 | | プラットフォーム \| Apex | ✅ トリガーハンドラーがビジネスロジックのサービスクラスに委任し、懸念を明確に分離 | | プラットフォーム \| Apex | ✅ トリガーで静的フラグまたは専用の再帰制御クラスを使用した再帰保護を使用する | | プラットフォーム \| Apex | ✅今後のApexは、コールアウトまたはシステム オブジェクトDMLに慎重に使用される | | プラットフォーム \| Apex | ✅非同期Apex呼び出しでは、キューを使用してトランザクション間で複雑なDMLを「チェーニング」 | | プラットフォーム \| Apex | ✅ バッチApexは、大量のデータに使用されます(チャンクあたりの専用ガバナ制限を使用して大量のデータを処理します)。 | | プラットフォーム \| Apex | ✅ 一括処理ジョブには、一括実行全体を停止せずに失敗したレコードを記録するエラー処理があります。 | | プラットフォーム \| Apex | ✅ Bulk API は大量のデータを処理する必要がある場合にのみ使用されます (ネイティブ SOAP および REST API は少量のデータで使用されます)。 | | プラットフォーム \| Apex | ✅キュー可能Apexは、複雑なワークフロー オーケストレーション、再試行ロジックを使用した外部コールアウト、非同期制限によるメリットを得られる処理に使用されます。 | | プラットフォーム \| Apex | ✅ スケジュール済みApexは、夜間のメンテナンス、日次レポート、定期的なインテグレーション同期、時間ベースのビジネスルールの処理に固定されたスケジュールで実行します。 | | プラットフォーム \| 設計標準 | ✅ 自動化内の同期操作と非同期操作の使用事例が設計標準の一部として明確に示されている | | プラットフォーム \| ドキュメント | ✅ 自動化の計画済み実行パスと潜在的な実行パスが明確になっている | **アンチパターン** | 参照すべき場所 | どんな悪い感じか | | --- | --- | | プラットフォーム \| Apex | ⚠️ 実行順序が予測できず、ロジックが重複する 1 つのオブジェクトに対する複数のトリガー | | プラットフォーム \| Apex | ⚠️ トリガーファイルに直接埋め込まれたビジネスロジックでテストが困難 | | プラットフォーム \| Apex | ⚠️ トリガーハンドラーフレームワークがないか、オブジェクト間でトリガーパターンが一貫していない | | プラットフォーム \| Apex | ⚠️ Apex一括処理ジョブの範囲サイズは非常に小さい（たとえば、範囲サイズ＝ 1） | | プラットフォーム \| Apex | ⚠️ 外部コールアウトに使用される一括処理 Apex (一括処理 Apex を使用して外部システムに大量の Salesforce データが転送される) | | プラットフォーム \| Apex | ⚠️ 任意で使用される非同期 Apex 機能 (Future Method および Queueable Apex が一貫性なく使用されているか、交換可能) | | プラットフォーム \| Apex | ⚠️ ほとんど使用されない非同期 Apex | | プラットフォーム \| Apex | ⚠️ データベース操作に、必要に応じて実行を一括処理 Apex に渡すための明確で一貫したロジックがない | | プラットフォーム \| 設計標準 | ⚠️ 同期操作と非同期操作の使用事例には対応していません | | プラットフォーム \| ドキュメント | ⚠️ オートメーションの呼び出しが文書化されていない | ## プラットフォームイベント **パターン** | 参照すべき場所 | 外観 | | --- | --- | | プラットフォーム \| プラットフォームイベント | ✅ プラットフォームイベントは、パブリッシャーと登録者を分離するイベント駆動型の自動化に使用されます。 | | プラットフォーム \| プラットフォームイベント | ✅ パブリッシャーは購読者に気付かず、Fire-and-Forget を公開します。 | | プラットフォーム \| プラットフォームイベント | ✅ 複数の登録者がプラットフォーム イベント トリガー フロー、Apexトリガー、外部インテグレーションを介してイベントに独立して反応 | | プラットフォーム \| プラットフォームイベント | ✅ リプレイ ID は、72 時間の保持期間の任意の時点から失敗したイベントをリプレイするために使用されます。 | | プラットフォーム \| プラットフォームイベント | ✅ プラットフォームイベントにより、組織間コミュニケーション、外部システム通知、内部ワークフローオーケストレーションが可能 | **アンチパターン** | 参照すべき場所 | どんな悪い感じか | | --- | --- | | プラットフォーム \| プラットフォームイベント | ⚠️ パブリッシャーと登録者間の直接結合により、作成可能な自動化を防止 | | プラットフォーム \| プラットフォームイベント | ⚠️ Account Tier Upgrade (取引先ランクアップグレード) は、商談の更新、取引先チームの通知、データウェアハウスの同期を 1 つのトランザクションで直接コールします (密結合では、新しい下流処理が必要になるたびに取引先ロジックを変更する必要があります)。 | | プラットフォーム \| Apex | ⚠️ すぐに公開 アドホックで使用されるプラットフォームイベント (公開順序の要件やレコードロックリスクに関係なく、\[Publish After Commit (コミット後に公開)] の代わりに使用されるリアルタイムイベント) | ## Apex 開発標準 **パターン** | 参照すべき場所 | 外観 | | --- | --- | | プラットフォーム \| Apex | ✅ SOQLステートメントでは、主ロジックまたは唯一のロジックとして正のロジック比較演算子(`INCLUDES`、`IN`)を使用します。 | | プラットフォーム \| Apex | ✅ SOQL は`= NULL`、`!= NULL`を避けるか、肯定的な比較演算子の後に慎重に使用します。 | | プラットフォーム \| Apex | ✅ SOQL は `LIMIT 1` ステートメントを使用しない | | プラットフォーム \| Apex | ✅ SOQL で `ALL ROWS` キーワードが使用されていない | | プラットフォーム \| Apex | ✅ SOQL がループ内に表示されない | | プラットフォーム \| Apex | ✅ SOSL にワイルドカード条件が表示される (SOQL ではない) | | プラットフォーム \| Apex | ✅ SOQL ステートメントで`LIKE`の比較や部分的なテキストの比較を回避 | | プラットフォーム \| Apex | ✅ SOQL が`try-catch`ブロックでラップされている | | プラットフォーム \| Apex | ✅ 変数はハードコードされた値を参照しません (レコードタイプ、ユーザーなど)。 | | プラットフォーム \| Apex | ✅ 各クラスは 1 つの特定の目的を果たす | | プラットフォーム \| Apex | ✅ 各方法で特定の詳細なタスクを実行 | | プラットフォーム \| Apex | ✅ すべての入力変数にクラス内で明確な目的がある | | プラットフォーム \| Apex | ✅ 最小限のリソースでコードを実行 | **アンチパターン** | 参照すべき場所 | どんな悪い感じか | | --- | --- | | プラットフォーム \| Apex | ⚠️ SOQL ステートメントでは、主比較演算子として`NOT`、`NOT IN`条件、または唯一の比較演算子 (非選択) を使用します。 | | プラットフォーム \| Apex | ⚠️ SOQL ステートメントで `ALL ROWS` キーワードを使用 (非選択) | | プラットフォーム \| Apex | ⚠️ SOQL ステートメントでは、主比較演算子として`= NULL`、`!= NULL`条件、または唯一の比較演算子 (非選択) を使用します。 | | プラットフォーム \| Apex | ⚠️ 変数の値はハードコードされています | | プラットフォーム \| Apex | ⚠️ ループ内に SOQL が表示される | | プラットフォーム \| Apex | ⚠️ SOQL ステートメントでは、`LIKE` とワイルドカード検索条件が頻繁に使用されます (非選択)。 | | プラットフォーム \| Apex | ⚠️ `try-catch` ブロックでラップされていない SOQL | | プラットフォーム \| Apex | ⚠️ SOQL ステートメントで`LIMIT 1`を使用 (非選択) | | プラットフォーム \| Apex | ⚠️ SOSL がワイルドカード選択基準でほとんど使用されない、または一貫して使用されない | | プラットフォーム \| Apex | ⚠️ クラスは複数の目的を果たす | | プラットフォーム \| Apex | ⚠️ メソッドが複数の ToDo を実行する、またはメソッドが属するクラスの明確な目的と一致しない ToDo を実行する | | プラットフォーム \| Apex | ⚠️ 入力変数は実際にはメソッドで使用されません | | プラットフォーム \| Apex | ⚠️ 不必要にデータベースや外部システムからデータを取得するメソッド | ## エラーハンドリング **パターン** | 参照すべき場所 | 外観 | | --- | --- | | プラットフォーム \| Apex | ✅ カスタム例外を使用して高度なエラーメッセージとロジックを作成 | | プラットフォーム \| Apex | ✅ コードは、すべての DML、SOQL、コールアウト、その他の重要なプロセスステップを`try-catch`ブロックでラップします。 | | プラットフォーム \| Apex | ✅ データベースクラスのメソッドは、すべてのデータ操作に排他的に使用できます (DML の代わりに)。 | | プラットフォーム \| Apex | ✅ 非同期および一括コンテキストでは、DML の代わりに Database クラスのメソッドが使用される | | プラットフォーム \| Aura | ✅ JavaScriptですべてのデータ操作と重要なプロセスステップを`try-catch`ブロックでラップ | | プラットフォーム \| Aura | ✅ `try-catch` ブロック内では、ネイティブの JavaScript `Error`が throw ステートメントで使用されます (`$A.error()` は使用されません)。 | | プラットフォーム \| Aura | ✅ リカバリ可能なすべてのエラーロジックが`catch`ステートメント内に表示され、明確なユーザーメッセージが提供されます。 | | プラットフォーム \| フロー | ✅ データ操作、コールアウト、その他の重要な処理ロジックを含むフローには、すべての主要なアクションの障害パスがあります。 | | プラットフォーム \| フロー | ✅ 画面フローでは一貫して障害コネクタを使用してユーザーにエラーを表示 | | プラットフォーム \| フロー | ✅ 画面に表示されるエラーに対してカスタムエラーメッセージを設定 | | プラットフォーム \| LWC(Lightning Webコンポーネント) | ✅ JavaScriptですべてのデータ操作と重要なプロセス ステップを`if ()`/`else if ()`ブロックでラップ | | プラットフォーム \| LWC(Lightning Webコンポーネント) | ✅ すべての`@wire`関数は、API で提供される`data`および`error`プロパティを使用します。 | | プラットフォーム \| LWC(Lightning Webコンポーネント) | ✅ すべての`if (error)`/`else if (error)`ステートメントには、エラーを処理して情報メッセージを提供するロジックが含まれています。 | **アンチパターン** | 参照すべき場所 | どんな悪い感じか | | --- | --- | | プラットフォーム \| Apex | ⚠️ DML、SOQL、コールアウト、または一貫して try-catch ブロックでラップされていない他の重要なプロセスステップ | | プラットフォーム \| Apex | ⚠️ Database クラスのメソッドが使用されていない | | プラットフォーム \| Apex | ⚠️ DML のみで実行されるデータ操作 | | プラットフォーム \| Apex | ⚠️ `System.debug`ステートメントは本番コードに表示されます (コメントアウトされません)。 | | プラットフォーム \| Aura | ⚠️ JavaScript では、データ操作と重要なプロセスステップが一貫して`try-catch`ブロックでラップされない | | プラットフォーム \| Aura | ⚠️ コンポーネントは`$A.error()`を使用 | | プラットフォーム \| Aura | ⚠️ リカバリ可能なエラーロジックが `catch` ステートメント内に一貫して表示されず、ユーザーへのエラーメッセージが明確でない | | プラットフォーム \| フロー | ⚠️ フローで障害パスが一貫して使用されていない、またはまったく使用されていない | | プラットフォーム \| フロー | ⚠️ カスタムエラーメッセージが使用されないため、ユーザーにはデフォルトの「このフローで未対応の障害が発生しました」メッセージが表示されます。 | | プラットフォーム \| LWC(Lightning Webコンポーネント) | ⚠️ `@wire` 関数は、API で提供される`data`および`error`プロパティを使用しない (または一貫して使用しない) | | プラットフォーム \| LWC(Lightning Webコンポーネント) | ⚠️ まったく使用しない場合、`if (error)`/`else if (error)` ステートメントにはエラーを処理して有益なエラーメッセージを提供するロジックは実際には含まれていません。 | | プラットフォーム \| LWC(Lightning Webコンポーネント) | ⚠️ JavaScript は、データ操作や重要なプロセスステップで一貫して `if ()`/`else if ()` ブロックを使用しない |