| トリガー分類/種別 | 軽減 |
|---|---|
| 人 | ポリシー |
| プロセス | プレイブック、継続性計画 |
| テクノロジー | 重複 |
| トリガー | 軽減 | 基本 | 中級 | 成熟 |
|---|---|---|---|---|
| 新規または退職する従業員のユーザーアクセス権の変更 | ユーザーをプロビジョニングまたはプロビジョニング解除するためのサービスレベル契約 (SLA) と要件 | 手動変更の SLA に従って、ユーザーを手動でプロビジョニングおよびプロビジョニング解除します。 | スケジュール済み変更の SLA に従って、スケジュール済みジョブでユーザーの変更を処理します。 | SSO/IDM ソリューションを使用して、ユーザーのプロビジョニングとプロビジョニング解除を自動化します。 |
| パターン | アンチパターン | |
|---|---|---|
| リスク管理 | ビジネス:
確立されたリスク評価フレームワークが使用されている。 リスクは、人、プロセス、テクノロジーの領域に分類されます。 |
ビジネス:
- Salesforce のリスク評価フレームワークはアドホックです。 リスクが明確ではない。 |
| ドキュメント:
- リスクの重要度は、顧客への影響に基づいて分類および評価されます。 - リスク軽減および対応計画に優先順位を付けます。 |
ドキュメント:
- リスクの重要度やカテゴリを評価するときに、顧客の視点は考慮されません。 - リスク軽減および対応計画は、考えられるすべてのリスクを把握しようとします。 |
|
| 障害の軽減 | 組織内：
- 障害点トリガーとそれに対応する緩和計画は、人、プロセス、テクノロジー別に分類されます。 - 緩和コントロールがすぐに導入され、経時的に成熟し、できるだけ早く自動化が組み込まれます。 - 最適な拡張性を確保するために、変更が本番にリリースされる前に包括的なテストと最適化を完了します。 - ビジネスクリティカルなイベントの前に、SLA に従ってスケールテストと最適化が実行されます。 |
組織内：
- 失敗点トリガーは分類されません。緩和方法が存在しないか、その場しのぎでのみ使用されます。 - 緩和措置が再検討または改善されていない。 - 軽減措置では自動化は使用されません。 |
| 監視とオブザーバビリティ | 組織内：
-チェックと異常検出では、Proactive Monitoring が有効になっています。 -継続的な可視性のために、Proactive MonitoringアラートはScale Centerと統合されています。 |
組織内：
- 状態チェックは手動でのみ実行され、継続的な監視は行われません。 |
| パターン | アンチパターン | |
|---|---|---|
| スループット | 設計基準では、次のようになります。
- プラットフォームキャッシュの使用方法に関するガイダンスは、プラットフォームキャッシュベストプラクティスに準拠しています。 |
設計基準では、次のようになります。
- プラットフォームキャッシュの利用状況に関する指針がある場合、明確ではない、またはベストプラクティスに準拠していない。 |
| 組織内：
- 一括処理は、データとシステム操作に使用されます。 - DML またはデータベースメソッドは、常に Apex のコレクションに対して動作します。 - DML 中にデータベースで経過時間が短くなるために使用する項目が制限されます。 - SOSL ではすべてのワイルドカード条件が使用されます。 - SOQL ステートメントは選択的です。 -- LIKE 比較や部分テキスト比較は使用しません。 -- 比較演算子では、主ロジックまたは唯一のロジックとして肯定的なロジック (つまり INCLUDES または IN) が使用されます。 --= NULL と != NULL が使用されるのは、常に肯定的な比較演算子の後にある場合のみです。 – データ負荷を最小限に抑えてパフォーマンスを最大化するために、SOQL クエリで必要な項目のみが取得されます。 -- LIMIT 1 ステートメントは使用されません。 -- ALL ROWS キーワードは使用されません。 - 可能な場合は非同期処理が優先されます。 プラットフォームキャッシュパーティションが設定されている。 |
組織内：
- DML ステートメントは一括処理されません。 - Apex の 1 つのレコードに対して DML またはデータベースメソッドが動作します。 - SOSL がワイルドカード選択条件で使用されることはほとんどありません。 - SOQL ステートメントは非選択的です。 -- LIKE およびワイルドカード検索条件が含まれます。 -- !=、NOT、または NOT IN 条件を使用した比較は、主または唯一の比較演算子として使用されます。 -- = NULL 条件と != NULL 条件を主または唯一の比較演算子として使用します。 -- LIMIT 1 ステートメントが使用されます。 -- ALL ROWS キーワードが使用されます。 - SOQL がループ内に表示されます。 - 同期プロセスが好まれます。 |
|
| 遅延 | 組織内：
- レポートは 1 つの特定の目的を果たし、意思決定に必要な最小限の行数と列数が含まれます。 -検索条件で「次の文字列と一致する」と「次の文字列と一致しない」が使用されている。 - 検索条件に数式項目が含まれていない。 ・共有モデルは可能な限り簡略化。 カスタムUIコンポーネントでは、LWC(Lightning Webコンポーネント)を使用します。 - LWC はデータ操作に Lightning Data Service を使用します。 - リストデータの並び替えと絞り込みは、JavaScript でクライアント側で処理されます。 - Salesforce Edge が有効になっている。 |
組織内：
- レポートには複数の目的がある場合や、意思決定に不要な行や列が含まれている場合があります。 -検索条件で「含む」と「含まない」が使用されている。 - 検索条件には数式項目が含まれます。 共有モデルは複雑です。 -カスタムUIコンポーネントではフレームワークが使用されているため、LWCよりもレンダリング効率が低い場合があります(AuraやVisualforceなど)。 - LWC はデータ操作に Apex を使用します。 - リストデータの並び替えと絞り込みは、Apex を使用してサーバー側で処理されます。 - Salesforce Edge が有効になっていない。 |
| パターン | アンチパターン | |
|---|---|---|
| データモデリング | 設計基準では、次のようになります。
- カスタムオブジェクトが存在することをビジネス上の正当性が保証する基準と指針。 |
設計基準では、次のようになります。
- カスタムオブジェクトを作成するための標準はありません。 |
| データモデルの場合:
可能な場合は標準オブジェクトが使用されます。 - ApexGuru によるアンチパターンチェックにより、SOQL クエリが選択され、スキーマの非効率的な使用が回避されることを確認します。 - テーブルはスケールに対して非正規化されます。 |
データモデルの場合:
- 複製された標準オブジェクトがある。 - テーブルは冗長性を避けるために正規化されます。 |
|
| ビジネス内：
- ローコードビルダーは、Salesforce でサポートされるさまざまなデータ型を理解し、レポートと暗号化の要件を評価してから、データ型を選択します。 - オブジェクト間の主従関係を確立する前に、その関係の共有とデータスキューの影響を評価します。 |
ビジネス内：
- ローコードビルダーは、下流のレポートと暗号化の要件を評価することなくデータ型を選択します。 - オブジェクト間の主従関係を確立することを決定する前に、その関係の共有とデータスキューの影響を評価しません。 |
|
| データ量 | データ内：
10,000 件を超える子レコードを持つ親レコードはありません。 - 10,000 件を超える同じオブジェクト種別のレコードにユーザーが割り当てられていない。 - 同じレコードを参照する参照項目を持つ 10,000 件を超えるレコードが含まれるインスタンスはありません。 - 一括データ読み込みは、ParentId 項目値に従ってバッチに並び替えられます。 -バッチ戦略が同時実行で破綻しないように、スケールテストを使用して本番規模で一括読み込みパターンを検証します。 - 本番へのデータの一括読み込みは、ピーク営業時間中に行われません。 - 一括データ読み込みには、ビジネス上の意思決定に必要な最小限のデータのみが含まれます。 |
データ内：
10,000 件を超える子レコードが存在する。 - ユーザーが同じ種別の 10,000 件を超えるレコードに割り当てられている。 10,000 件を超えるレコードに同じレコードを参照する参照項目があるインスタンスが存在する。 - 一括データ読み込みは、ParentId 項目値に従ってバッチに並び替えられません。 - 本番環境へのデータの一括読み込みは、営業時間のピーク時に行われます。 - 一括データの読み込みは、ビジネス上の意思決定に必要な最小限のデータに制限されません。 |
| フローおよび Apex の場合 ―
- データの歪みが問題になるシナリオで、子レコードの数を複数の親レコードに分散するロジックが存在します。 -インテグレーションを使用してレコードをインポートまたは複製すると、ロジックによって適切なユーザーに割り当てられます。 - Apex コレクション (リストやセットなど) の場合、クエリを最小限に抑えてデータ処理を最適化するために複数のレコードを処理するロジックが存在します。 - 拡張性の高いコードの標準とベスト プラクティスに準拠する効率的なApexコードが記述され、リリースされます。 |
フローおよび Apex の場合 ―
- 子レコードは、すでに割り当てられている子レコードの数に関係なく、親レコードに任意に割り当てられます。 データ読み込みまたはインテグレーションで作成されたレコードは、一般的な「インテグレーションユーザー」に割り当てられます。 - 同じオブジェクトからの複数の再帰的な SOQL クエリが同期トランザクションにあり、ヒープ使用量が多い。 -開発者がApexコードを作成すると、非効率性とパフォーマンスのアンチパターンが発生します。 |
|
| ビジネス内：
- データのアーカイブおよび消去戦略を文書化して実装している |
ビジネス内：
-データアーカイブおよび消去戦略がないか、戦略が文書化されているが実装されていない |
| ツール | 説明 | 可用性 | Performance | 拡張性 |
|---|---|---|---|---|
| Big Object | プラットフォームで大量のデータを保存および管理します。 | X | ||
| コードスキャナー | Apex コードをスキャンしてパフォーマンスの問題がないか確認します。 | X | ||
| カスタムインデックス | カスタムインデックスを使用してクエリのパフォーマンスを向上させます。 | X | ||
| データの削除 | 不要なデータを削除してパフォーマンスを向上させます。 | X | X | |
| ディビジョン | データをパーティション分割して、クエリとレポートのレコード数を制限します。 | X | ||
| スケールテスト | システムのパフォーマンスをテストし、結果を解釈します。本番にリリースする前に、拡張性とパフォーマンスを検証するために、Playwright または JMeter スクリプトを使用して大規模な UI および API ワークロードをシミュレーションします。 | X | X | |
| Scale Center | システムパフォーマンスに関するセルフサービスとリアルタイムのインサイトを取得します。実行時間の長いトランザクション、例外のホットスポット、スループットのボトルネックを見つけます。開発サイクルの早い段階で拡張性の問題を診断します。 | X | X | |
| ApexGuru | Scale CenterのこのGenAIベースの機能を使用して、実行時にApex、SOQL、テスト クラスのアンチパターンを検出します。ApexGuru と Salesforce Code Analyzer のインテグレーションにより、開発ワークフローで AI を駆使したおすすめとインライン修正を利用できます。これらの推奨事項と修正を使用して、ホットスポットを解決し、クエリの選択性、一括処理、キャッシュ使用量、テスト品質を向上させます。 | X | X | |
| Salesforce Code Analyzer | IDE、CLI、または CI/CD を使用してコードをスキャンし、ベストプラクティスに準拠していることを確認します。Salesforce Code Analyzer と ApexGuru の統合により、開発者ワークフローでパフォーマンスのアンチパターンに関するインサイトを直接取得できます。 | X | ||
| Salesforce Edge ネットワーク | Salesforce Edgeネットワークを介して[私のドメイン]をルーティングすることで、ダウンロード時間とユーザーエクスペリエンスを改善します。 | X | ||
| スキニーテーブル | 頻繁に使用する項目があるテーブルでの結合は避けてください。 | X | ||
| プロアクティブな監視 | レコードの増加、所有権のスキュー、パフォーマンスの低下の異常を継続的に監視します。重大になる前に、規模に関するアラートを表示します。 | X | X |
| リソース | 説明 | 可用性 | Performance | 拡張性 |
|---|---|---|---|---|
| 拡張性の課題 - ビジネスを将来にわたって維持する方法 | 拡張性の実装が、持続可能な成長と長期的な成功にどのようにつながるかを説明します。 | X | X | |
| Scale Center を使用したスケーラブルなアプリケーションの構築とリリース | Salesforce 実装のパフォーマンスの問題を積極的に評価して解決する方法について説明します。 | |||
| 複雑なSalesforceアプリケーションでのパフォーマンスの分析とホットスポットの拡張 | 組織のパフォーマンスと拡張性の問題に対処します。 | X | X | |
| ラッシュ時のトラフィックでアプリケーションがパニックになるべきではない - 準備方法 | スケールテストを成功させるための 4 つの主要なステップについて説明します。 | |||
| ApexGuru AIエンジンの説明 | ApexGuru がカスタムトレーニングされたモデル、実際の組織のテレメトリ、インテリジェントなフィルタリングを使用して、正確でコンテキストに沿ったアクション可能なインサイトを提供する方法について説明します。 | X | X | |
| ApexGuruを使用したアプリケーションおよびAgentforce向けApexの最適化 | SOQL、DML、デバッグ、非効率性のテストなど、ApexGuruが開発者のパフォーマンス アンチパターンの検出と修正にどのように役立つかについて説明します。また、ApexGuruを、アプリケーションの拡張性の高い開発とAgentforceの実装のためのAI搭載コーチとして使用します。 | X | X | |
| ApexGuru Antipatterns | Salesforce のメジャーリリースのたびに更新される ApexGuru で検出されたアンチパターンの公式ライブラリについて説明します。 | X | X | |
| 大量のデータを使用するリリースのベストプラクティス | 大量のデータのプロセスへの影響を理解します。 | X | ||
| Salesforce Edge ネットワークに関する考慮事項 | Salesforce Edge ネットワークを使用するために組織を準備する方法を確認します。 | X | ||
| 設計標準テンプレート | 組織の設計標準を作成します。 | X | X | X |
| データモデル設計に関する考慮事項 | 拡張性とメンテナンスのためにデータモデルを最適化します。 | X | X | |
| 企業の規模に応じたレコードアクセス権の作成 | 設定によってアクセス制御のパフォーマンスを最適化します。 | X | ||
| 大量のデータを処理するシステムのインフラストラクチャ | 大量のデータを使用するリリースのシステムパフォーマンスをサポートする機能について説明します。 | X | ||
| 一括管理の学習リソース | 一括管理について説明します。 | X | X | |
| Lightning Experience パフォーマンスの最適化 | 組織のLightning Experienceを改善して、ユーザーの作業時間を短縮します。 | X | ||
| Salesforce でのルックアップスキューの管理によるレコードロック例外の回避 | ルックアップスキューの影響を最小限に抑える方法を理解します。 | X | X | |
| SOQL および SOSL のベストプラクティス | 大量のデータを使用するリリースの場合は、SOQL および SOSL のベストプラクティスに従ってください。 | X | X | |
| 大規模な再配置のためのツール | 再配置を効果的に計画および実行します。 | X | ||
| マッシュアップの使用 | 大きなデータセットを別のアプリケーションで管理します。 | X | X |