Salesforce 認定 Platform デベロッパー 上級 1-10

この問題の本質は、対象レコードを一度に持ちすぎることで ビュー状態が肥大化する点 と、取得件数が多いため 表示処理そのものが遅くなる点 にあります。
Salesforce 公式では Visualforce のビュー状態サイズ上限が定められており、一覧表示では StandardSetController を使ったレコードセット管理が可能です。
そのため、SOQL の LIMIT や StandardSetController により一度に扱う件数を減らすのが適切です。
B は逆で、transient はビュー状態に保持しないため、削除すると改善ではなく悪化要因になり得ます。
A や D はこの設問の直接解決策としては不十分です。
なお、Apex、Visualforce、StandardSetController は現行の Salesforce 用語です。

StandardSetController クラス
ビジュアルフォースの制限

この問題は、翻訳ワークベンチが有効な環境で選択リスト値をユーザー言語で取得する方法を問うものです。
SOQL では toLabel() 関数を使用することで、選択リストや参照項目の表示ラベルをユーザーの言語に応じて取得できます。
つまり API 値ではなく翻訳済みラベルを返す仕組みが toLabel() です。
これにより、多言語環境でも適切な表示が可能になります。B や C のように取得後に変換する仕組みは存在せず、D のような Locale 句も SOQL にはありません。
したがって SOQL 実行時に変換する toLabel() の利用が正解です。

toLabel()

この設問では、トリガー処理を一括対応（Bulkification）できているかが重要です。最も効率的なのは D です。
まず Trigger.new から郵便番号を Set に集め、次に 1 回の SOQL で該当する Region__c を取得し、最後に Map で Lead の PostalCode から Region を引けるようにしています。
これにより SOQL をループ内で実行しないため、ガバナ制限に強い実装になります。
また、B はクエリ回数は抑えていますが二重ループのため件数増加時に非効率です。
C は典型的な SOQL in loop で不適切です。
したがって 1 回の取得結果を Map に載せて各 Lead に割り当てる D が最も効率的です。
なお、Lead、Apex Trigger、SOQL はいずれも現行の Salesforce 用語です。

バルクトリガー
トリガーおよびバルクリクエストのベストプラクティス

Queueable Apex は非同期処理であるため、テストでは Test.startTest() と Test.stopTest() を使用して強制的に実行させる必要があります。
特に Test.stopTest() のタイミングで非同期処理が実行される点が重要です。
そのため、enqueueJob は startTest() の後に呼び出し、stopTest() の後に結果を検証する必要があります。
また 非同期処理の結果は stopTest() 後に SOQL で再取得して検証するのが正しい手順です。
A や D は非同期処理の完了前に検証してしまうため不正確であり、C のような方法は一般的な検証手法ではありません。

limits、startTest 、および stopTest を用いる
キュー可能な頂点

この問題は、環境間でのデータの一貫性とテスト実行時の可用性がポイントです。
カスタム設定はデータとして扱われるため、サンドボックスリフレッシュ時に内容が変わったり欠落する可能性があります。
一方でカスタムメタデータはメタデータとして管理され、デプロイ可能でありテストでも常に参照できます。
つまり 環境間で同一データを保証できる点がカスタムメタデータの大きな利点です。
また テスト時にデータ作成不要で参照可能な点も安定性向上に寄与します。
そのため、将来的な安定運用の観点からカスタムメタデータへの移行が最適解です。

Apex 開発者ガイド
ユニット内の組織データからのテストデータの分離 テスト

この問題のポイントは「最小限の JavaScript」で複数エラーを同時表示することです。
Salesforce では検証ルールを使用することで、複数フィールドに対する条件チェックを宣言的に実装できます。
特に 検証ルールは複数条件を定義でき、複数エラーメッセージを同時に返すことが可能です。
また lightning-record-edit-form は標準で検証ルールのエラー表示に対応しているため、追加の JavaScript 実装が不要です。
A や B は不要に複雑であり、D はサーバー側処理でリアルタイムなUIエラー表示には適しません。したがって最適解は検証ルールです。

オーラコンポーネントの紹介
このクイックリファレンスについて

大規模データでは「選択性（selectivity）」とインデックス利用が重要です。
External ID 項目は自動的にインデックス化されるため、これを条件に含むクエリは高速化されます。
したがって Customer_Number__c（External ID）を条件に含む B はインデックスが利用され最適です。
また D は IsDeleted = false により対象を絞り込み、不要な削除済みデータを除外することで効率が向上します。
A はインデックスを使わず非効率であり、C はリストサイズに依存し選択性が保証されません。
よって インデックス利用とデータ絞り込みの観点で B と D が適切です。

Apex 開発者ガイド
非常に大きなSOQLクエリの扱い

このエラーはトリガーの再帰呼び出しが制限を超えた場合に発生します。
Salesforce では無限ループ防止のため、トリガーのネスト（再帰）回数に上限があり、最大16回までと定められています。
そのため 同一トリガーまたは関連トリガーが更新処理を繰り返し呼び出すと、この制限に達します。
典型的には after update で別オブジェクト更新→元オブジェクト更新のような循環構造が原因です。
したがって 再帰防止フラグや設計見直しでトリガーの再実行を制御することが重要です。
B や C は別のガバナ制限エラーとなり、本エラーの直接原因ではありません。

トリガーと実行順序
トリガー

Lightning Web コンポーネントでは、データ取得に wire サービスを使用します。
getRecord を利用する場合、recordId と取得対象フィールドの両方を指定する必要があります。
そのため @wire(getRecord, { recordId: ‘$recordId’, fields: ‘$fields’ }) のように fields を含めて指定することが必須です。
これにより指定レコードの必要な項目データが取得されます。
また @wire はリアクティブに動作し、recordId や fields が変更されると自動的に再取得される点も重要です。
B は構文誤りであり、C は fields 指定がないため不完全です。

ワイヤーサービスの理解
getRecord

この問題は、トリガーが複数回実行されている、または他の自動化（フローやワークフロー）と干渉している可能性を調査する必要があります。
そのためにはログベースの詳細なトレースが最も有効です。
特に System.debug() を使って処理の実行順序や回数を可視化することが重要です。
また Developer Console のログを確認することで、トリガーの再実行や他の自動化の影響を特定できます。
A は切り分けとして有効な場合もありますが非効率であり、B は問題解決に直接関係せず、C は範囲が広すぎて特定が困難です。したがって最適解は D です。

Apexのデバッグ
Apex 開発者ガイド