
Salesforce認定 Platformアプリケーションビルダー 模擬試験100問【2025年最新版】
各問題は試験の主要トピックごとに整理されています。この問題を解き、内容を理解すれば、Platformアプリケーションビルダーの資格を取得できるでしょう。
データモデリング
問題1.
ユニバーサルコンテナーズ社では、新たに「請求書」(Invoice)オブジェクトを作成し、請求書と取引先(Accounts)を関連付けたいと考えています。請求書レコードが取引先レコードと常に関連し、取引先が削除された際には関連する請求書も自動的に削除されるようにしたい場合、どのようなリレーションシップを選択すべきでしょうか。
A. 取引先を親、請求書を子とする参照関係 (ルックアップ)
B. 請求書を取引先の子とする階層関係
C. 取引先と請求書の間に両方向の参照関係を設定する
D. 取引先を親、請求書を子とする主従関係
正解: D
解説: 主従関係にすると取引先が親、請求書が従オブジェクトとなり、親取引先が削除されれば関連する従レコード(請求書)も自動削除されます。また従オブジェクト(請求書)は必ず親を持ち、取引先なしでは存在できません。一方、参照関係 (ルックアップ) では親が削除されても子レコードは削除されず孤立してしまいます。階層関係はユーザオブジェクト専用の特殊な参照関係で、本ケースには適用できません。両方向の参照関係という設定はなく、参照関係は一方向ずつ定義するものです。
問題2.
ユニバーサルコンテナーズ社では、カスタムオブジェクト「プロジェクト」と「従業員」があり、1つのプロジェクトに複数の従業員、1人の従業員が複数のプロジェクトに参加する可能性があります。この多対多の関係を実現するために、App Builderはどのようにデータモデルを設計すべきでしょうか。
A. 従業員オブジェクトからプロジェクトオブジェクトへの参照関係フィールドを複数作成する
B. プロジェクトと従業員の中間にジョンクションオブジェクトを作成し、それぞれに対して主従関係フィールドを持たせる
C. プロジェクトオブジェクトに従業員を列挙するマルチセレクトピックリスト項目を追加する
D. 従業員オブジェクトを親、プロジェクトを子とする主従関係を1つ作成する
正解: C
解説: 多対多関係を実現するには、第3のカスタムオブジェクト(ジョンクションオブジェクト)を用意し、2つの主従関係でそれぞれプロジェクトと従業員に関連付けます。これにより、ジョンクションオブジェクトのレコード1件が1人の従業員と1つのプロジェクトの組み合わせを表し、結果として多対多を表現できます。選択肢Aのように1つの従業員から複数のプロジェクト参照項目を作る方法では拡張性がなく不適切です。選択肢Cのマルチセレクトピックリストで従業員を複数選択する方法は、各従業員レコードとの個別の関連付けができず不適切です(また報告や集計が困難になります)。選択肢Dの単一の主従関係では一対多にしかならず、多対多には対応できません。
問題3.
ユニバーサルコンテナーズ社では、取引先(親)とその関連する請求書(子)との間で、親取引先のフィールドに関連するすべての請求書の合計金額を表示したいと考えています。請求書オブジェクトは取引先オブジェクトと主従関係で関連付けられています。この要件を満たすために、どの機能を使用すると最も簡単に実現できますか。
A. 親取引先オブジェクト上に積み上げ集計項目を作成する
B. 請求書オブジェクト上に数式項目を作成し、親の合計を参照する
C. ワークフロールールを使用して親レコードの金額を更新する
D. Apexトリガを作成して請求書の金額を親に集計する
正解: A
解説: 主従関係が設定されている場合、親オブジェクト(取引先)の項目に従オブジェクト(請求書)のレコードを集計する積み上げ集計項目を作成できます。積み上げ集計項目では子レコードの合計、件数、最小/最大値などを自動計算し、親レコードに表示できます。選択肢Bの数式項目では、親から子への集計はできず(数式項目は関連レコードの「上位」(親)のフィールドしか参照できません)、逆方向の集計はできません。選択肢Cのワークフロールールによる更新でも可能ですが、積み上げ集計の方が設定のみで自動計算されるため簡潔です。また、選択肢DのApexトリガでも実現できますが、コードを書く必要があり、ポイント&クリックで実装可能な積み上げ集計の方が適切です。
問題4.
ユニバーサルコンテナーズ社の営業チームは、商談と関連付けられた取引先責任者(Contact)の役割を管理したいと考えています。1つの商談に複数の取引先責任者が関与し、それぞれに「意思決定者」「法務担当」などの役割を指定できるようにする必要があります。この要件を満たすために、どのSalesforce機能を使用すべきでしょうか。
A. 商談と取引先責任者の間に主従関係を設定し、子オブジェクトで役割を選択できるようにする
B. 商談と取引先責任者の関係を表す取引先責任者ロール(商談の関連リスト)機能を利用する
C. 商談オブジェクトに取引先責任者を列挙するマルチセレクトピックリストを追加する
D. 取引先責任者レコード上に商談を参照する参照関係を追加し、役割項目を持たせる
正解: B
解説: 商談に関連する複数の取引先責任者とそれぞれの役割を管理するには、Salesforce標準機能の商談の取引先責任者ロールを使用するのが適切です連リストで複数の取引先責任者をリンクし、各責任者に役割を指定できます。選択肢Aのように主従関係を用いる必要はありません(標準機能で十分です)。選択肢Cのマルチセレクトピックリストでは、複数の責任者の管理や役割の紐付けは困難です。選択肢Dのように参照関係を用いたカスタム実装も可能ですが、標準の「取引先責任者ロール」機能を使う方が簡単で推奨されます。
問題5.
ユニバーサルコンテナーズ社では、カスタムオブジェクト「応募者」と「求人」を使用して採用管理を行っています。1件の求人に対し複数の応募者を関連付けたいものの、応募者が必ずしも求人に関連付かない場合もあります。さらに、求人レコード上で関連する応募者の平均評価を自動計算したいという要件があります。これらの要件を満たすリレーションシップの設定はどれが適切でしょうか。
A. 参照関係: 応募者を子(詳細)オブジェクト、求人を親として参照関係を設定する
B. 主従関係: 応募者を子(詳細)オブジェクト、求人を親として主従関係を設定する
C. 主従関係: 求人を子(詳細)オブジェクト、応募者を親として主従関係を設定する
D. 多対多の関係: 応募者と求人の間にジョンクションオブジェクトを作成して双方と主従関係を結ぶ
正解: A
解説: 応募者が求人に関連付かない場合もあるため、参照関係が適切です。参照関係であれば、応募者レコードに求人が関連付かなくても(ルックアップ項目が空でも)保存できます。さらに、参照関係でも求人が親の場合、関連する応募者の数式項目を利用して求人側に平均評価を表示できます(応募者から求人への参照があれば、数式で親求人の項目や、逆にロールアップは不可ですが、評価平均はレポートなどで算出可能です)。主従関係では親(求人)の関連が必須で、応募者が単独で存在できないため要件「応募者が求人に関連付かない場合もある」を満たしません。選択肢Cは関係が逆で不適切です。選択肢Dのジョンクションオブジェクトは多対多用であり、本シナリオは一対多関係のため不要です。
問題6.
ユニバーサルコンテナーズ社のマーケティング部門では、取引先責任者(Customers)に対して複数の興味分野を記録したいと考えています。興味分野はあらかじめ定義されたカテゴリの中から複数選択可能ですが、将来的に新しいカテゴリが追加される可能性もあります。この要件を満たすデータモデル設計として最適なものはどれでしょうか。
A. 取引先責任者オブジェクトにマルチセレクトピックリスト項目を作成し、興味分野を選択できるようにする
B. 商談など他の標準オブジェクトを転用して興味分野を管理する
C. 興味分野用のカスタムオブジェクトを作成し、取引先責任者との間に多対多の関係を構築する
D. 取引先責任者にテキスト項目を追加し、興味分野をカンマ区切りで入力する
正解: B
解説: 興味分野のように将来的にカテゴリーが増える可能性があり、かつ各取引先責任者に複数紐付けたい場合、カスタムオブジェクト「興味分野」を作成し、取引先責任者との間で子(興味分野)から親(取引先責任者)への参照関係を構築する方法がスケーラブルです。各興味分野レコードにカテゴリを持たせ、取引先責任者1件に対して複数の興味分野レコードを関連付けられます。選択肢Aのマルチセレクトピックリストは一見簡便ですが、値の追加が都度必要で運用負荷が高く、レポートで個々の選択肢ごとに集計・フィルタすることが困難です。標準オブジェクトの転用(選択肢B)は不適切で、選択肢Dのテキスト項目にカンマ区切り入力もデータの一貫性や集計が担保できないため適しません。
問題7.
ユニバーサルコンテナーズ社では、商談とケース(問い合わせ)という2つのオブジェクトを使用しています。営業担当は、取引先ページ上でその取引先に関連する商談とケースの両方を一覧表示したいと考えています。App Builderは、この要件を満たすためにどの機能を使うべきでしょうか。
A. 取引先を親、商談とケースを子とする主従関係を設定し直す
B. 取引先ページレイアウトに関連リストとして商談とケースを追加する
C. 取引先詳細ページにレポートチャートを埋め込み、商談・ケースを表示する
D. カスタムのVisualforceページを作成し、商談とケースの一覧を統合表示する
正解: A
解説: 取引先と商談、取引先とケースはいずれも標準で参照関係(実質的な親子関係)が構成されており、取引先のページレイアウトにそれぞれ「関連リスト」として表示できます。したがって、App Builderは取引先のページレイアウト編集画面で商談とケースの関連リストを追加すれば、取引先レコード上で関連する商談一覧、ケース一覧が表示されます。選択肢Aのデータモデル自体を変更する必要はありません(既に適切な関係が構築されています)。選択肢Cのレポートチャート埋め込みは、主に集計グラフを表示する用途であり一覧表示には適しません。選択肢DのVisualforceページの作成は、標準機能で実現可能なため不要です。
問題8.
ユニバーサルコンテナーズ社では、商品(Product)と注文(Order)オブジェクトがあります。注文明細(Order Item)を管理するために、1件の注文に複数の商品を関連付ける必要があります。標準オブジェクトを使用してこのデータモデルを実現するにはどうすればよいでしょうか。
A. 商品と注文の間に多対多のカスタムリレーションを作成する
B. Price Book(価格表)オブジェクトをカスタマイズして注文明細を表現する
C. Salesforceの標準オブジェクトである「注文製品 (Order Product)」を使用する
D. 注文オブジェクトに商品を列挙する複数選択の選択リストを追加する
正解: C
解説: Salesforceには**注文製品(Order Product)**という標準のジョンクションオブジェクトがあり、商品(製品)と注文を関連付ける多対多関係(注文明細)を管理できます。これを使用すれば1つの注文に複数の商品を紐付け、それぞれ数量や価格などを管理可能です。選択肢Aのように新たに多対多用のカスタムオブジェクトを作成する必要はなく、標準オブジェクトを活用できます。選択肢Bの価格表オブジェクトは製品の価格設定用途であり、注文明細自体の管理には直接関係しません。選択肢Dのマルチセレクトピックリストでは、注文に複数の製品名を持たせるだけになり、数量や個別価格の管理ができないため不適切です。
問題9.
ユニバーサルコンテナーズ社は、Salesforceと外部在庫管理システムを連携し、外部システム上の在庫データをSalesforceのカスタムオブジェクト「在庫レコード」にリアルタイム参照で表示したいと考えています。大量の在庫データを定期的にインポートせず、Salesforce上では読み取り専用でよい場合、どの機能を使うのが適切でしょうか。
A. Salesforce Connectを使用して外部オブジェクトを作成し、外部システムのデータをリアルタイム参照する
B. 外部システムのデータを夜間バッチでCSVエクスポートし、データローダでSalesforceにロードする
C. Big Objectsを使用して大量データをSalesforceに格納し参照する
D. 外部システムからREST APIで都度Salesforceにデータを書き込むカスタム連携を構築する
正解: C
解説: 外部システムのデータをリアルタイムに参照し、Salesforce側に大量データを保存しないのであれば、Salesforce Connectを使用して外部オブジェクトを作成する方法が適しています。Salesforce Connectでは外部データソースを設定し、Salesforce上に外部オブジェクトとして定義することで、データを保存せず参照・検索が可能です。これによりリアルタイムに外部システムの在庫データを閲覧できます。選択肢Bのバッチインポートはデータを取り込む必要がありリアルタイム性に欠けます。選択肢CのBig Objectsは大量データのアーカイブ向け機能で、本ケースのリアルタイム外部参照には向きません。選択肢DのカスタムAPI連携は可能ですが、Salesforce Connectを使えばノンコーディングで実現できるため、より簡便です。
問題10.
ユニバーサルコンテナーズ社では、顧客のレコードを外部システムからインポートする必要があります。インポート対象のレコード数は約10万件で、各レコードには外部システムで使用していた一意の顧客IDが含まれています。Salesforceで重複を避けつつこのデータを取り込むために、最も適切な方法は次のうちどれでしょうか。
A. データインポートウィザードを使用し、一度に50,000件ずつ分割してインポートする
B. データローダを使用し、外部システムの一意IDを外部ID項目としてマッピングしてアップサートする
C. アナリティクススナップショットを使用して、外部データを定期的に反映する
D. 重複ルールを一時的に無効化し、CSVを直接インポートする
正解: A
解説: 約10万件のデータインポートには、データローダの使用が適しています。データローダは最大500万件までのレコードを扱えるため、10万件のインポートでも問題ありません。また、外部システムの一意の顧客IDをSalesforce側の外部ID項目として設定し、データローダでアップサート操作を行うことで、既存レコードの更新と新規レコードの挿入を一度に行えます。データインポートウィザード(選択肢A)は50,000件までの制限があるため10万件を一度には処理できません。アナリティクススナップショット(選択肢C)はレポートデータの保存機能で、本ケースの大量インポートには不向きです。選択肢Dの重複ルール無効化は、重複回避策として妥当ではなく(むしろ外部IDや重複ルールを活用すべき)、データ品質を損なう可能性があります。
ここから先は
¥ 1,000
この記事が気に入ったらチップで応援してみませんか?