Q1.デバッグログに書き込まれるときのxの値は何ですか。
A. 0
B. 1
C. 2
D. 3
回答
- C.2
-
do-while文は条件判定の前に必ず1回は処理が実行される構文です。
最初にxは0で初期化されますが、ループ内でx = 1が実行され、その後x++によりxは2になります。
その後、while (x < 1) の条件が評価されますが、xはすでに2のため条件はfalseとなりループは終了します。
したがってSystem.debugで出力される値は2です。
この問題はwhile文との違い、特に初回実行の有無を理解しているかを問う基本問題です。
デューフループ
Q2.LightningコンポーネントからApexメソッドおよびプロパティへのアクセスを可能にするアノテーションはどれですか。
A. @RestResource
B. @AuraEnabled
C. @RemoteAction
D. @HttpInvocable
回答
- B. @AuraEnabled
-
Lightningコンポーネント（AuraおよびLWC）からApexを呼び出すには、Apexメソッドやプロパティに@AuraEnabledを付与する必要があります。
これによりクライアントサイドからサーバサイド処理へアクセス可能になります。
@RestResourceはREST API公開用、@RemoteActionはVisualforce向けの旧方式、@HttpInvocableは外部サービス連携用であり用途が異なります。
したがって、LightningコンポーネントとApexの連携に使用する正しいアノテーションは@AuraEnabledです。
AuraEnabled 注釈
Q3.非同期Apexを実行して、ガバナ制限と実行制限が緩和されるものはどれですか。
3つ選びなさい。
A. ヒープの合計サイズ
B. Salesforceサーバの最大CPU時間
C. Apexトランザクションごとの最大実行時間
D. SOQLクエリによって取得されるレコードの合計数
E. SOQLクエリ発行総数
回答
- A. ヒープの合計サイズ
B. Salesforceサーバの最大CPU時間
D. SOQLクエリ発行総数 -
非同期Apex（Future、Queueable、Batchなど）では、同期処理よりもガバナ制限が緩和される項目が存在します。具体的にはヒープサイズやCPU時間、SOQLクエリ数の上限が拡張されます。一方で、SOQLで取得できるレコード数やトランザクションの最大実行時間などは基本的に変わりません。したがって、非同期処理ではリソース消費の大きい処理を安全に実行できるよう一部制限が引き上げられる点が重要です。
執行の総督と制限
Q4.現在取引先が100個ある場合に、開発者コンソールを使用して次のコードを実行します。
このコードの実行後、組織にはいくつの取引先がありますか。
A. 101
B. 100
C. 102
D. 252
回答
- B. 100
-
このコードではループ内でinsertが2回実行されますが、1トランザクション内のDML文の上限（150回）を超えると例外が発生します。
try-catchで囲まれているのは最初のinsertのみであり、後続のinsertは例外処理されません。
そのためガバナ制限に達した時点で未処理例外となり、トランザクション全体がロールバックされてすべてのレコード追加が取り消されます。
結果として、元の100件のまま変化しません。
執行の総督と制限
Q5.トリガーの実行順序で、beforeトリガーが実行された後、およびafterトリガーが実行される前に、どのステップが発生しますか。
正確な順序を答えなさい。
1 システム検証ステップが再度実行され、ユーザー定義の入力規則がチェックされます。
2 beforeトリガー
3 afterトリガー
4 レコードはデータベースに保存されますが、まだコミットされていません。
5 重複ルールを実行します。
A. 1→2→5→3→4
B. 2→3→4→1→5
C. 2→1→5→4→3
D. 2→1→5→3→4
回答
- C. 2→1→5→4→3
-
Salesforceのトリガー実行順序では、まずbeforeトリガーが実行され、その後にシステム検証および入力規則の再チェックが行われます。
続いて重複ルールが適用され、問題なければレコードはデータベースに保存（まだ未コミット）されます。その後にafterトリガーが実行されます。
したがって、beforeトリガーの後に検証→重複チェック→保存→afterトリガーの順序になる点が重要です。
トリガーと実行順序
Q6.レコードセット内のレコード数が不明な場合、開発者は.size()または.length()メソッド呼び出しを実行せずに、レコードセット内のすべてのレコードに対して実行するコードセットを実装するためにどの制御ステートメントを使用する必要がありますか。
A. For(init_stmt, exit_condition; increment_stmt) { }
B. Do { } While(Condition)
C. For(variable : list_or_set) { }
D. While(Condition) { … }
回答
- C. For(variable : list_or_set) { }
-
レコード数が不明なコレクション（ListやSet）を処理する場合は、拡張for文（for-each構文）を使用するのが最適です。
この構文では.size()などで件数を取得する必要がなく、コレクション内の全要素を安全かつ簡潔に処理できます。
他のfor文やwhile文は件数管理や条件制御が必要となり冗長になります。
したがって、コレクション処理ではfor(variable :list_or_set)構文を使うのがベストプラクティスです。
ループのために
Q7.共有に関する正確な説明はどれですか。2つ選びなさい。
A. 内部クラスまたは外部クラスのいずれかを共有と同様に宣言できますが、両方は宣言できません。
B. 内部クラスは外部クラスから共有設定を継承しません。
C. 内部クラスと外部クラスの両方を共有と同様に宣言できます。
D. 内部クラスは外部クラスから共有設定を継承します。
回答
- B. 内部クラスは外部クラスから共有設定を継承しません。
C. 内部クラスと外部クラスの両方を共有と同様に宣言できます。 -
Apexではwith sharingやwithout sharingにより共有ルールの適用を制御しますが、内部クラスは外部クラスの共有設定を自動的には継承しません。
そのため、それぞれのクラスで明示的に指定する必要があります。
また、内部クラスと外部クラスは独立して宣言できるため、両方のクラスに対して個別にsharing設定を定義することが可能です。
この仕様はセキュリティ制御の明確化のために重要です。
共有付き、共有なし、そして継承共有キーワードを使います
Q8.開発者には、コードブロックを共有ありまたはなしで実行するかどうかを示す「with sharing」および「without sharing」を省略したコードブロックがあります。Salesforce組織でコードを実行するユーザーの組織全体のデフォルトおよび共有設定に自動的に従うものは次のうちどれですか。
A. Apexトリガー
B. HTTPコールアウト
C. カスタムコントローラ
D. 匿名ブロック
回答
- D. 匿名ブロック
-
with sharingやwithout sharingを指定しない場合の挙動は実行コンテキストに依存します。匿名ブロックは実行ユーザーの権限で動作するため、組織の共有設定やユーザーのアクセス権に従ってデータアクセスが制御されます。
一方、トリガーは常にシステムコンテキストで実行され、共有ルールを無視します。
カスタムコントローラは宣言に依存します。
したがって、明示指定なしでユーザーの共有設定に従うのは匿名ブロックです。
共有付き、共有なし、そして継承共有キーワードを使います
Q9.SalesforceDXを使用する場合、スクラッチ組織を作成・管理するために開発者は何を有効にする必要がありますか。
A. Production
B. Dev Hub
C. 環境ハブ
D. Sandbox
回答
- B. Dev Hub
-
Salesforce DXでスクラッチ組織を作成・管理するには、Dev Hubを有効化する必要があります。
Dev Hubはスクラッチ組織の作成元となる機能であり、組織の中央管理ポイントとして機能します。
ProductionやSandboxは直接スクラッチ組織管理には使用されず、環境ハブも別用途の機能です。
したがって、Salesforce DXの利用において必須となるのはDev Hubである点が重要です。
Dev Hub Orgを選択して有効化する
Q10.開発者は、取引先を操作するApexメソッドに十分なテストカバレッジがあることを確認する必要があります。
開発者はテストデータを作成する必要があります。
このテストデータをSalesforceに読み込むための好ましい方法は何ですか。2つ選びなさい。
A. CSVファイルを使用する
B. HttpCalloutMocksを使用する
C. WebServiceTestsを使用する
D. 静的リソースを使用する
回答
- CSVファイルを使用する
静的リソースを使用する -
Apexテストでは外部データに依存せず、テストデータを用意することが重要です。
CSVファイルを用いることでテストデータを効率的に管理・読み込みできます。
また、静的リソースとしてCSVを格納しテスト内で利用する方法も推奨されています。
HttpCalloutMocksやWebServiceTestsは外部通信のモック用であり、データ投入用途ではありません。
したがって、テストデータの読み込みにはCSVと静的リソースの組み合わせがベストプラクティスです。
ユニット内の組織データからのテストデータの分離 テスト
