表示モード
画像位置
文字位置
理解度の自動記録
Q1Salesforce Pldevex
Q1. ある企業の業務システムでは、ユーザーが指定した選択リスト値の組み合わせに応じてレコードを絞り込み表示する Apex コントローラーと Visualforce ページを運用しています。
一部の条件では表示までに時間がかかり、別の条件では「最大ビュー状態サイズの制限を超えました」という例外が発生してしまいます。
この状況を改善するために、開発者はどの対応を行うべきですか。
解答を見る
正解：C. 一度に表示するレコード件数を抑えるため、Apex コントローラーで StandardSetController または SOQL の LIMIT を利用する。
この設問の要点は、対象レコードを一度に大量保持することでビュー状態が肥大化する点と、取得件数の多さにより表示処理そのものが遅くなる点にあります。Visualforce にはビュー状態サイズの上限が定められており、一覧表示では StandardSetController を用いたレコードセット管理が有効です。
そのため、SOQL の LIMIT や StandardSetController により一度に扱う件数を減らすのが適切な対応です。
選択肢Bは逆効果で、transient はビュー状態に保持しない指定のため、削除するとむしろ悪化要因になり得ます。
選択肢AやDはこの設問の直接的な解決策としては不十分です。
StandardSetController クラス
ビジュアルフォースの制限
Q2Salesforce Pldevex
Q2. ある企業は翻訳ワークベンチを有効化し、選択リスト値の翻訳を行っています。
Account オブジェクトには、取引先が導入済みの自社製品を営業担当者が記録するための、複数選択の選択リスト項目 Product__c があります。
開発者は、この Product__c を含む Account レコードを取得する Apex メソッドを作成する必要があります。
Product__c の値を実行ユーザーの言語で取得するには、開発者はどうすべきですか。
解答を見る
正解：A. SOQL クエリの取得項目リストで toLabel(Product__c) を使用する。
この設問は、翻訳ワークベンチが有効な環境で選択リスト値を実行ユーザーの言語で取得する方法を問うものです。SOQL では toLabel() 関数を用いることで、選択リストや参照項目の表示ラベルをユーザーの言語に応じて取得できます。
つまりAPI 値ではなく翻訳済みラベルを返す仕組みが toLabel() です。
これにより、多言語環境でも適切な表示が可能になります。
選択肢BやCのように取得後に変換する仕組みは存在せず、選択肢Dのような Locale 句も SOQL には用意されていません。
したがってSOQL 実行時に変換する toLabel() の利用が正解です。
toLabel()
Q3Salesforce Pldevex
Q3. ある企業の Salesforce 管理者は、米国内の郵便番号ごとに、その郵便番号が属する自社の営業地域を管理するため、Region__c というカスタムオブジェクトを作成しました。
この企業では、リードの郵便番号に応じて Region を自動設定するために、Lead に対するトリガーの実装を必要としています。
この要件を最も効率的に満たすコードセグメントはどれですか（下図参照）。
解答を見る
正解：D. Option D
この設問では、トリガー処理が一括処理（バルク化）に対応しているかがポイントです。最も効率的なのは選択肢Dです。まず Trigger.new から郵便番号を Set に集約し、続けて 1 回の SOQL で該当する Region__c をまとめて取得し、最後に Map を使って各 Lead の PostalCode から Region を引き当てています。
これによりSOQL をループ内で実行しないため、ガバナ制限に強い実装になります。
選択肢Bはクエリ回数こそ抑えていますが二重ループとなるため、件数が増えると非効率です。
選択肢Cは典型的な「ループ内 SOQL」であり不適切です。
したがって1 回の取得結果を Map に載せて各 Lead へ割り当てる選択肢Dが最も効率的です。
バルクトリガー
トリガーおよびバルクリクエストのベストプラクティス
Q4Salesforce Pldevex
Q4. CreateOneAccount という Apex クラスが Queueable インターフェースを実装しており、実行すると 1 件の Account を作成するとします。
このコードを正しく検証するテストの構文はどれですか（下図参照）。
解答を見る
正解：B. Option B
Queueable Apex は非同期処理であるため、テストでは Test.startTest() と Test.stopTest() を使って処理を強制的に実行させる必要があります。特にTest.stopTest() のタイミングで非同期処理が実際に実行される点が重要です。
そのため、enqueueJob は startTest() の後に呼び出し、stopTest() の後に結果を検証する必要があります。
また非同期処理の結果は stopTest() の後に SOQL で再取得して検証するのが正しい手順です。
選択肢AやDは非同期処理が完了する前に検証してしまうため不正確であり、選択肢Cのような手法は一般的な検証方法ではありません。
limits、startTest 、および stopTest を用いる
キュー可能な頂点
Q5Salesforce Pldevex
Q5. ある企業の開発者は、頻繁に変更される設定値を保存するためにカスタム設定（Custom Settings）を利用していました。
ところが、最近リフレッシュしたいくつかのサンドボックスで、テストが失敗するようになってしまいました。
今後この問題を防ぐために、開発者はどのような対応を行うべきですか。
解答を見る
正解：D. カスタム設定をカスタムメタデータへ置き換える。
この設問のポイントは、環境間でのデータの一貫性とテスト実行時の可用性です。カスタム設定はデータとして扱われるため、サンドボックスをリフレッシュすると内容が変わったり欠落したりする可能性があります。
一方でカスタムメタデータはメタデータとして管理されるためデプロイでき、テスト実行時にも常に参照できます。
つまり環境間で同一のデータを保証できる点がカスタムメタデータの大きな利点です。
またテスト時にデータ作成が不要で参照できる点も安定性の向上に寄与します。
したがって、将来的な安定運用の観点からカスタムメタデータへの移行が最適な対応です。
Apex 開発者ガイド
ユニット内の組織データからのテストデータの分離 テスト
Q6Salesforce Pldevex
Q6. ある開発者が、リード情報を入力させるために lightning-record-edit-form を用いた Lightning Web コンポーネントを作成しました。
ところが、リードレコードの保存時に入力エラーが発生すると、エラーメッセージが一度に1件しか表示されないという声が利用者から寄せられています。
複数項目に対する検証を行い、最小限の JavaScript で複数のエラーメッセージを同時に表示するための推奨アプローチはどれですか。
解答を見る
正解：C. 検証ルール（Validation Rules）を使用する。
この設問のポイントは「最小限の JavaScript」で複数のエラーを同時に表示することです。Salesforce では検証ルールを利用することで、複数項目に対する条件チェックを宣言的に実装できます。
特に検証ルールは複数の条件を定義でき、複数のエラーメッセージを同時に返せます。
またlightning-record-edit-form は検証ルールによるエラー表示に標準で対応しており、追加の JavaScript 実装が不要です。
選択肢AやBは不必要に複雑であり、選択肢Dはサーバー側の処理であるためリアルタイムな画面表示には適しません。
したがって最適な対応は検証ルールです。
オーラコンポーネントの紹介
このクイックリファレンスについて
Q7Salesforce Pldevex
Q7. 次の条件を考慮してください。
・Account レコードが 200,000 件以上存在する
・これらのレコードにはソフト削除済み（ごみ箱内）のものも含まれる
・Account には External ID として設定された項目が2つある（Customer_Number__c と ERR_Key__c）
大規模データボリュームに対して最適化されているクエリを2つ選択してください。
解答を見る
正解：B、D
大規模データを扱う際は「選択性（セレクティビティ）」とインデックスの利用が重要です。External ID として設定された項目は自動的にインデックス化されるため、これを条件に含むクエリは高速化されます。
したがってCustomer_Number__c（External ID）を条件に含む選択肢Bはインデックスが利用され最適です。
また選択肢Dは IsDeleted = false により対象を絞り込み、不要な削除済みデータを除外することで効率が向上します。
選択肢Aはインデックスを利用できず非効率であり、選択肢Cはリストのサイズに依存するため選択性が保証されません。
よってインデックス利用とデータ絞り込みの観点から選択肢Bと選択肢Dが適切です。
Apex 開発者ガイド
非常に大きなSOQLクエリの扱い
Q8Salesforce Pldevex
Q8. ある開発者が「Maximum Trigger Depth Exceeded」というエラーに遭遇しました。
このエラーが発生する原因として考えられるものはどれですか。
解答を見る
正解：A. トリガーが16回以上、再帰的に呼び出されている。
このエラーは、トリガーの再帰呼び出しが上限を超えた場合に発生します。Salesforce では無限ループを防止するため、トリガーのネスト（再帰）回数に上限が設けられており、最大16回までとされています。
そのため同一トリガーや関連するトリガーが更新処理を繰り返し呼び出すと、この制限に達します。
典型的には after update で別オブジェクトを更新し、それが元のオブジェクトの更新を再度呼び出すといった循環構造が原因です。
したがって再帰防止フラグの実装や設計の見直しにより、トリガーの再実行を制御することが重要です。
選択肢BやCは別のガバナ制限エラーであり、本エラーの直接の原因にはなりません。
トリガーと実行順序
トリガー
Q9Salesforce Pldevex
Q9. ある開発者が、Salesforce からデータを取得し、そのデータを record プロパティへ割り当てる Lightning Web コンポーネントを作成しています。
このコンポーネントで Salesforce からデータを取得するには、何を実装する必要がありますか（下図参照）。
解答を見る
正解：A. Option A
Lightning Web コンポーネントでは、データ取得に wire サービスを使用します。getRecord を利用する場合、recordId と取得対象の項目の両方を指定する必要があります。
そのため@wire(getRecord, { recordId: ‘$recordId’, fields: ‘$fields’ }) のように fields を含めて指定することが必須です。
これにより、指定したレコードの必要な項目データが取得されます。
また@wire はリアクティブに動作し、recordId や fields が変化すると自動的に再取得される点も重要です。
選択肢Bは構文が誤っており、選択肢Cは fields の指定がないため不完全です。
ワイヤーサービスの理解
getRecord
Q10Salesforce Pldevex
Q10. ある企業の Apex トリガーは、営業担当者が商談（Opportunity）を受注に更新すると、毎回 Order__c レコードを作成する仕組みになっています。
最近、このトリガーが1件の商談に対して2件の注文を作成してしまう事象が発生しています。
この問題をトラブルシューティングするために、2人の開発者が取るべき最適な手法はどれですか。
解答を見る
正解：D. コードに System.debug() を追加し、Developer Console のログを使って処理を追跡する。
この設問は、トリガーが複数回実行されている、あるいは他の自動化（フローやワークフロー）と干渉している可能性を調査する必要がある事例です。そのためには、ログを用いた詳細なトレースが最も有効です。
特にSystem.debug() を使って処理の実行順序や回数を可視化することが重要です。
またDeveloper Console のログを確認することで、トリガーの再実行や他の自動化の影響を特定できます。
選択肢Aは切り分け手段として有効な場合もありますが非効率であり、選択肢Bは今回の問題解決に直接関係せず、選択肢Cは対象範囲が広すぎて原因の特定が困難です。
したがって最適な対応は選択肢Dです。
Apexのデバッグ
Apex 開発者ガイド