Salesforce Apex Quality Guardrails

記述または確認するすべての Apex クラス、トリガー、およびテストファイルにこれらのチェックを適用します。

Step 1 — Governor Limit Safety Check

Apex ファイルを許容可能と宣言する前に、以下のパターンをスキャンしてください。

SOQL と DML のループ内使用 — 自動不可

// ❌ NEVER — causes LimitException at scale
for (Account a : accounts) {
    List<Contact> contacts = [SELECT Id FROM Contact WHERE AccountId = :a.Id]; // SOQL in loop
    update a; // DML in loop
}

// ✅ ALWAYS — collect, then query/update once
Set<Id> accountIds = new Map<Id, Account>(accounts).keySet();
Map<Id, List<Contact>> contactsByAccount = new Map<Id, List<Contact>>();
for (Contact c : [SELECT Id, AccountId FROM Contact WHERE AccountId IN :accountIds]) {
    if (!contactsByAccount.containsKey(c.AccountId)) {
        contactsByAccount.put(c.AccountId, new List<Contact>());
    }
    contactsByAccount.get(c.AccountId).add(c);
}
update accounts; // DML once, outside the loop

ルール: [SELECT または Database.query、insert、update、delete、upsert、merge が for ループ本体内に見つかった場合は、処理を進める前にリファクタリングしてください。

Step 2 — Sharing Model Verification

すべてのクラスは、その sharing intent を明示的に宣言する必要があります。宣言されていない sharing は呼び出し元から継承されます。これは予測不可能な動作につながります。

宣言	使用時期
public with sharing class Foo	すべてのサービス、ハンドラー、セレクター、およびコントローラークラスのデフォルト
public without sharing class Foo	クラスが昇格された権限で実行される必要がある場合のみ(例: システムレベルのロギング、トリガーのバイパス)。理由を説明するコードコメントが必須
public inherited sharing class Foo	呼び出し元の sharing コンテキストを尊重すべきフレームワークのエントリーポイント

クラスがこれら 3 つのいずれかの宣言を持たない場合は、他の処理を進める前に追加してください。

Step 3 — CRUD / FLS Enforcement

ユーザーに代わってレコードを読み取りまたは書き込む Apex コードは、オブジェクトおよびフィールドアクセスを検証する必要があります。プラットフォームは Apex で FLS または CRUD を自動的には適用しません。

// Check before querying a field
if (!Schema.sObjectType.Contact.fields.Email.isAccessible()) {
    throw new System.NoAccessException();
}

// Or use WITH USER_MODE in SOQL (API 56.0+)
List<Contact> contacts = [SELECT Id, Email FROM Contact WHERE AccountId = :accId WITH USER_MODE];

// Or use Database.query with AccessLevel
List<Contact> contacts = Database.query('SELECT Id, Email FROM Contact', AccessLevel.USER_MODE);

ルール: UI コンポーネント、REST エンドポイント、または @InvocableMethod から呼び出し可能な Apex メソッドは、必ず CRUD/FLS を適用する必要があります。信頼されたコンテキストからのみ呼び出される内部サービスメソッドは、with sharing を代わりに使用できます。

Step 4 — SOQL Injection Prevention

// ❌ NEVER — concatenates user input into SOQL string
String soql = 'SELECT Id FROM Account WHERE Name = \'' + userInput + '\'';

// ✅ ALWAYS — bind variable
String soql = [SELECT Id FROM Account WHERE Name = :userInput];

// ✅ For dynamic SOQL with user-controlled field names — validate against a whitelist
Set<String> allowedFields = new Set<String>{'Name', 'Industry', 'AnnualRevenue'};
if (!allowedFields.contains(userInput)) {
    throw new IllegalArgumentException('Field not permitted: ' + userInput);
}

Step 5 — Modern Apex Idioms

現在の言語機能(API 62.0 / Winter '25 以降)を優先的に使用します:

古いパターン	最新の置き換え
if (obj != null) { x = obj.Field__c; }	x = obj?.Field__c;
x = (y != null) ? y : defaultVal;	x = y ?? defaultVal;
System.assertEquals(expected, actual)	Assert.areEqual(expected, actual)
System.assert(condition)	Assert.isTrue(condition)
[SELECT ... WHERE ...] with no sharing context	[SELECT ... WHERE ... WITH USER_MODE]

Step 6 — PNB Test Coverage Checklist

すべての機能は 3 つのパス全体でテストする必要があります。いずれか 1 つが不足している場合は品質不良です:

Positive Path

• 期待された入力 → 期待された出力。
• 例外がスローされたことだけではなく、正確なフィールド値、レコード数、または戻り値をアサート してください。

Negative Path

• 無効な入力、null 値、空のコレクション、およびエラー条件。
• 例外が正しい型とメッセージでスロー されることをアサートしてください。
• 操作がクリーンに失敗するべきときに、レコードが変更されなかったことをアサートしてください。

Bulk Path

• 1 つのテストトランザクションで 200–251 レコードを insert/update/delete してください。
• すべてのレコードが正しく処理されたことをアサートしてください。governor limit による部分的な失敗はありません。
• 非同期作業の governor limit カウンターを分離するために Test.startTest() / Test.stopTest() を使用してください。

Test Class Rules

@isTest(SeeAllData=false)   // Required — no exceptions without a documented reason
private class AccountServiceTest {

    @TestSetup
    static void makeData() {
        // Create all test data here — use a factory if one exists in the project
    }

    @isTest
    static void givenValidInput_whenProcessAccounts_thenFieldsUpdated() {
        // Positive path
        List<Account> accounts = [SELECT Id FROM Account LIMIT 10];
        Test.startTest();
        AccountService.processAccounts(accounts);
        Test.stopTest();
        // Assert meaningful outcomes — not just no exception
        List<Account> updated = [SELECT Status__c FROM Account WHERE Id IN :accounts];
        Assert.areEqual('Processed', updated[0].Status__c, 'Status should be Processed');
    }
}

Step 7 — Trigger Architecture Checklist

• オブジェクトごとに 1 つのトリガー。2 番目のトリガーが存在する場合は、ハンドラーに統合してください。
• トリガー本体には、コンテキストチェック、ハンドラー呼び出し、およびルーティングロジックのみが含まれます。
• ビジネスロジック、SOQL、または DML がトリガー本体に直接含まれていません。
• トリガーフレームワーク(Trigger Actions Framework、ff-apex-common、カスタムベースクラス)が既に使用中の場合は、それを拡張してください。並行パターンを作成しないでください。
• ハンドラークラスは with sharing です。トリガーが昇格されたアクセスを必要としない限り。

Quick Reference — Hardcoded Anti-Patterns Summary

パターン	アクション
for ループ内の SOQL	リファクタリング: ループの前にクエリ、コレクションで操作
for ループ内の DML	リファクタリング: 変更を収集、ループ後に DML を 1 度
sharing 宣言がないクラス	with sharing を追加(または without sharing の理由を記載)
ユーザーデータの escape="false"(VF)	削除 — 自動エスケープが XSS 防止を適用
空の catch ブロック	ロギングを追加し、適切に再スロー またはエラーハンドリング
ユーザー入力との文字列連結 SOQL	バインド変数またはホワイトリスト検証で置き換え
アサートなしのテスト	有意な Assert.* 呼び出しを追加
System.assert / System.assertEquals スタイル	Assert.isTrue / Assert.areEqual にアップグレード
ハードコーディングされたレコード ID ('001...')	クエリされたまたは挿入されたテストレコード ID で置き換え