Salesforce認定 Agentforce Sales コンサルタント の過去問対策 無料模擬試験です。実際の試験問題ではなく、公式試験ガイド（日本語版）のセクション別出題比率にそのまま準拠して書き起こしたオリジナル問題を、本番と同じ 60問収録しました。全問に解説が付いています。この記事は最後まで無料で読めます。
Salesforce資格の試験対策には、知識を読むだけでなく、問題を解き、間違えた理由を全問解説で確認する勉強法をおすすめします。解いて採点すれば、いまの自分がどのくらいの位置にいるか、どの分野を落としているかが数字で分かります。
Salesforce認定資格 過去問 模擬問 研究所（note.com/sfcertlab）
受験予定の資格が違う方は、こちらから探せます。当研究所では他のSalesforce認定資格の模擬問題集も公開しています。
この無料模試を試験対策に活かす勉強法
公式受験ガイド（日本語版）に記載されている条件に合わせています。
- 問題数：60問（本番は多肢選択方式の 60 問と採点対象外の最大 5 問）
- 制限時間：105分（本番と同じ）
- 合格ライン：73%＝44問正解（本番の合格点と同じです）
この無料模試の先に、全500問版があります。
まずは本記事で現在地を確認してください。試験対策の演習量を先に確保したい方は、同じ密度の全問解説が付いた全500問・全問解説付き問題集へ進めます。
※本記事の60問は、全500問版にも含まれています。
先に60問を解き切ってください。 解答と解説はこの記事の後半にまとめてあります。1問ごとに答えを見てしまうと、本番と同じ条件で現在地を測れません。紙かメモアプリに「問1 A」のように書き出しながら進めるのがおすすめです。
問題編（全60問）
1. セールスライフサイクル
問1. ［難易度：基礎］
インサイドセールスチームで、受け取ったリードをいつ取引開始すべきかの判断が分かれている。予算・決裁者・ニーズ・時期の確認が済んだ案件と、資料請求だけで連絡先しか分かっていない案件が同じ一覧に並んでいる。
リードの取引開始のタイミングに関する説明のうち、正しいものはどれか。
A. リードは作成された時点で直ちに取引開始し、不要になった取引先責任者や商談は後から削除する。
B. リードスコアが一定値を超えると自動的に取引開始されるため担当者の判断は要らない。
C. 取引開始は詳細画面から取り消せるため、迷った場合はまず取引開始して様子を見る。
D. 商談として追跡する価値があると適格性評価で確認できた段階で取引開始し、それまではリードのまま育成する。
問2. ［難易度：基礎］
営業担当から、リードを取引開始したときにどのレコードができ、リードに入力した情報がどこまで引き継がれるのかを確認したいという質問が出た。
リードの取引開始に関する説明として正しいものはどれか。
A. 取引先・取引先責任者・商談・ケースの4つが必ず作成され、リードの標準項目もカスタム項目もすべてそのまま複製されて残る。
B. リードの標準項目もカスタム項目も同名の項目へ自動で引き継がれるため、管理者が対応付けを設定しておく作業は要らない。
C. 取引先・取引先責任者と、選択に応じて商談が作成され、カスタム項目は管理者が対応付けを設定して初めて転記される。
D. 作成されるのは取引先責任者のみで、取引先と商談は後から手作業で作成する必要がある。
問3. ［難易度：シナリオ応用］
Cloud Kicks社は自社サイトの問い合わせフォームから届く見込み客への初回連絡が翌営業日以降になっており、失注が増えている。フォームの送信は1日あたり100件前後で、地域別に担当チームが分かれている。
初回応答を早めるための構成として最も適切なものはどれか。
A. Web-to-リードで送信内容を取り込み、地域を条件にした割り当てルールで担当チームのキューへ渡して通知する。
B. フォームの送信内容をメールで受け取り、担当者が内容を確認してリードを一件ずつ手作業で作成してから割り当てルールを適用する。
C. フォームの送信内容をいったん1名のリード管理者にすべて集め、内容を確認したうえで地域の担当チームへ手作業で振り分ける。
D. フォームの送信内容を取引先責任者として直接取り込み、地域別の共有ルールで担当チームに参照の権限を渡して連絡させる。
問4. ［難易度：基礎］
直販とパートナー経由でリードの進め方が異なり、それぞれで使う「リードの状況」の値も違っている。同じリードオブジェクトは使い続けたい。
管理者はどのように設定すればよいか。
A. リードの状況の選択リストに両チャネルの値をすべて追加し、他チャネルの値は入力規則で保存できないようにして使い分ける。
B. チャネルを識別するカスタムの選択リスト項目をリードに追加し、レポートではその項目で絞り込んでチャネルごとに別々に集計する。
C. パートナー用の状況の値を標準の項目とは別のカスタム選択リスト項目に切り出し、チャネルごとのページレイアウトで使い分ける。
D. チャネルごとにリードプロセスを作って使う値を選び、それぞれをレコードタイプに割り当ててユーザーに付与する。
問5. ［難易度：基礎］
割り当てルールのどの条件にも当てはまらないリードが、作成者の所有のまま誰にも触られずに残っている。担当が決まらないリードを確実に誰かの目に触れさせたい。
管理者が行うべき設定として最も適切なものはどれか。
A. 割り当てルールの最後にすべてのリードが一致する条件のエントリを追加し、特定の1名の担当者を所有者として指定する。
B. リードを作成できるユーザーをあらかじめ限定し、割り当てルールの条件に合わないリードは作成そのものを禁止する運用にする。
C. インサイドセールスのキューを作成し、割り当てルールの最後のエントリで未一致のリードをそのキューへ渡す。
D. 所有者が決まっていないリードを一覧表示するレポートを作り、週次でメール配信して担当者に取得させる運用にする。
問6. ［難易度：基礎］
立ち上げたばかりの新規事業で、リードの優先順位を付けたい。過去の取引開始の実績はほとんどなく、営業経験者は業種と従業員規模で有望さを判断できると言っている。
当面はどのように進めるのが妥当か。
A. Einsteinリードスコアリングを有効化し、取引開始の実績が少なくても自社データによるスコアを優先して並べ替えに使う。
B. リードの状況の選択リストに優先度の値を追加し、担当者が主観で選んだ値で並べ替える。
C. 業種と従業員規模を条件にした数式項目やレポートでランクを付け、実績が蓄積してから自動スコアの導入を検討する。
D. スコアが算出できるまで優先順位付けはせず、届いた順に対応を続ける。
問7. ［難易度：シナリオ応用］
マーケティング部門が、どの施策から受注につながったかを知りたいと考えている。現在のリードソースは「Web」「イベント」「紹介」の3つだけで、Webには検索広告・メール配信・自社ブログが含まれる。施策単位の費用対効果を見たい。
設計として最も適切なものはどれか。
A. リードソースの選択リスト値を施策の実施回ごとに増やし、施策を実施するたびに新しい選択肢を追加して費用対効果を見る。
B. リードソースは経路の分類として保ち、個別の施策はキャンペーンレコードで管理してリードや商談に関連付ける。
C. リードソースを自由入力のテキスト項目に変更し、担当者が施策名を直接入力する。
D. 受注した商談の説明欄へ施策名を記録し、レポートで抽出する。
問8. ［難易度：難問］
Cloud Kicks社では、展示会を親キャンペーン、会場での個別セミナーや後日のフォローメールを子キャンペーンとして登録している。マーケティングマネージャーは、親キャンペーンのレコードを開いただけで施策全体の予算と反応の合計を把握したいと考えている。マネージャーは一部の子キャンペーンについて参照権限を持っていない。
この仕組みについて管理者が説明する内容として正しいものはどれか。
A. 階層統計項目は配下のすべての子孫の値を合算し、参照権限のないキャンペーンの数値も合計に含めて表示する。
B. キャンペーンインフルエンスを有効にすると、親キャンペーンの実績項目へ子キャンペーンの数値が自動で加算される。
C. 親キャンペーンに積み上げ集計項目を新規作成することで、子キャンペーンのレスポンス数を階層をまたいで集計できる。
D. 階層は最大5レベルまでのため、6階層目以降の子キャンペーンの数値は親の統計項目に反映されない。
問9. ［難易度：シナリオ応用］
ウェビナー施策では、参加者を「登録済み」「出席」「商談化」の3段階で管理したい。マーケティング部門は、出席以降まで進んだ人数を反応した人数として扱い、キャンペーンの標準の反応率で効果を測りたいと考えている。
管理者はどの設定を行うべきか。
A. 「出席」をそのキャンペーンのメンバー状況の既定値に設定し、既定値であることをもって反応した人数に数える。
B. キャンペーンの ［レスポンス数］ 項目を数式に変更し、出席以降のメンバーだけを数える条件式を記述する。
C. キャンペーンのメンバー状況に3つの値を登録し、「出席」と「商談化」の双方でレスポンス済みを有効にする。
D. キャンペーンメンバーにカスタム選択リストを追加して段階を管理し、レポート側で出席以降を絞り込む。
問10. ［難易度：シナリオ応用］
Universal Containers社では、1件の商談が成立するまでに展示会、ウェビナー、メール施策など複数のキャンペーンが顧客に接触している。マーケティング部門は最初の接触だけでなく、途中で貢献した施策にも成立金額を割り振って評価したい。
管理者が採用すべき設定はどれか。
A. 商談の ［主要キャンペーンソース］ を接触のたびに上書きし、最後に残った値で施策を評価する。
B. キャンペーン階層を組んで各施策を子キャンペーンにまとめ、階層の統計項目が商談金額を自動的に配分する。
C. カスタマイズ可能なキャンペーンインフルエンスを有効にし、複数の施策へ影響度を割り振るモデルを追加する。
D. 商談へ「影響キャンペーン」のカスタム選択リストを追加し、レポートで施策ごとに集計する。
問11. ［難易度：難問］
Northern Trail Outfitters社は販売店向けの案内施策を計画しており、対象を法人単位で管理したいと考えている。これまでのキャンペーンではリードと取引先責任者だけをメンバーにしてきた。個人の消費者は個人取引先として登録されている。
管理者が伝える内容として正しいものはどれか。
A. 取引先そのものをキャンペーンメンバーとして追加でき、個人取引先も同様にメンバーにできる。
B. 取引先はメンバーにできないため、代表となる取引先責任者を1名選んで追加する運用に変える必要がある。
C. メンバーにできるのはリードと取引先責任者だけで、法人単位の管理はキャンペーン階層で代替するしかない。
D. 取引先をメンバーにするには、いったん取引先をリードへ変換し、そのリードをキャンペーンへ追加する必要がある。
問12. ［難易度：シナリオ応用］
AW Computing社では、マーケティングが渡したリードを営業が放置しているという不満と、渡されるリードの質が低いという不満が双方から出ている。マーケティングは獲得件数を、営業は成約に至る確度を成果として見ている。
最初に定めるべきこととして最も適切なものはどれか。
A. 営業が着手すべきリードの条件と、引き渡しから最初の接触までに要する時間を両部門で明文化する。
B. リードの割り当てルールを見直し、未対応のまま一定時間が過ぎたリードを他の担当者へ渡す。
C. リードスコアのしきい値を引き上げ、営業へ引き渡すリードの件数そのものを減らす。
D. マーケティングが作成したリードを営業マネージャーが毎朝手作業で選別してから配布する。
2. コンサルティングおよび実装戦略
問13. ［難易度：難問］
Ursa Major Solar社の導入プロジェクトで、来週ディスカバリーワークショップを開く。前回は役員だけが出席し、決まった業務フローが現場の実態と合わずに手戻りが発生した。今回は限られた時間で現場の実態と経営側の狙いの両方を引き出したい。
コンサルタントはどのような準備を行うべきか。
A. 参加者を現場の営業担当だけに絞り込み、日々の作業手順を細部まで洗い出すことに時間を充てる。
B. 事前アンケートで論点を集め、当日は結論の出た項目だけを読み上げて合意を取る。
C. 部門ごとに別日程で開催し、食い違った箇所は管理者が後から裁定する。
D. 各部門の実務担当と意思決定者の双方を招き、論点と進行手順を事前に共有したうえで当日の合意事項を記録する。
問14. ［難易度：基礎］
導入プロジェクトの初期段階で、営業部門の見積承認の流れが担当者ごとに異なっていることが分かった。どこで待ち時間が生じ、誰が判断しているのかを、関係者全員が同じ理解で確認できる資料を作りたい。
この段階で用いる手法として最も適切なものはどれか。
A. 現行業務のプロセスマップを作成し、作業と判断と担当者間の受け渡しを図で可視化して関係者で確認する。
B. 将来の理想像だけを描いたプロセスマップを作り、現行の手順は稼働後に改めて整理することにして今回の議論では扱わない。
C. 挙がった要件をユーザーストーリーの一覧にまとめ、粒度をそろえてから対応の優先順位を付けて並べ替える。
D. 想定の画面遷移をモックアップで作り、操作したときの感触を関係者に確認してもらう。
問15. ［難易度：シナリオ応用］
Cloud Kicks社の営業部長から「商談の一覧画面に色分けのボタンを付けてほしい」という要望が挙がった。ヒアリングに使える時間は30分しかなく、他部門からの要望も控えている。
コンサルタントはどのように進めるべきか。
A. 要望どおりの色分けボタンを先に試作して見せ、動くものを実際に触ってもらってから細部の調整点を挙げてもらう進め方にする。
B. 実現の可否を標準機能の範囲で先に判断し、対応できない部分については開発の見積もりを金額と期間つきで提示する。
C. 他部門の要望を集め終えてから、複数の部門に共通する画面の要望をまとめて設計する。
D. 色分けで何を判断したいのか、その判断が遅れると何が起きるのかを順に尋ね、解決したい業務課題を特定する。
問16. ［難易度：難問］
Northern Trail Outfitters社は7年前からSalesforceを使っており、歴代の担当者が作った自動化や項目が多数残っている。今回は営業プロセスの刷新を依頼された。関係者は新しい要件の議論をすぐ始めたがっている。
コンサルタントが最初に行うべきことは何か。
A. 既存の項目・自動化・レコードタイプ・権限の使用状況を棚卸しし、現行設定の制約を把握したうえで要件の議論に入る。
B. 関係者の希望どおり新しい要件を先にすべて確定させ、既存の設定との衝突が判明した箇所は設計の段階で個別に調整していく。
C. 新しい設定を入れるSandboxを用意し、本番組織には触れずに理想の構成を作って関係者に比較してもらってから要件を決める。
D. 使われていない項目と自動化をまず削除して組織全体を整理し、設定が身軽になった段階で新しい要件の議論を始めることにする。
問17. ［難易度：難問］
Cloud Kicks社のディスカバリーで、「見積作成に時間がかかる」「レポートが見づらい」「引き継ぎの情報が足りない」という3つの困りごとが挙がった。予算の都合で今回対応できるのは1つか2つに絞られる。
コンサルタントが次に行うべきことは何か。
A. ワークショップで挙がった困りごとを発言の多かった順に並べ替え、最も多くの参加者が挙げたものから順に着手していく。
B. 各項目について発生頻度・1件あたりの所要時間・関係する人数を聞き取り、年間の損失時間に換算して比較する。
C. 実装の難易度を先に見積もり、短期間で対応できるものから順に着手して、限られた予算で対応できる件数をできるだけ稼ぐ。
D. 3つすべてを今回の対象にしたうえで、予算に収まるように各項目の要件を削って浅く実装していく方針に切り替える。
問18. ［難易度：基礎］
要件の一覧に「四半期ごとの受注率を経営会議で確認したい」「レポートを画面に3秒以内で表示したい」「商談の完了時に上長へ通知する」という3つが並んでいる。分類を整理して漏れを防ぎたい。
3つはそれぞれどの分類にあたるか。
A. 受注率の確認はビジネス要件、通知はシステムの振る舞いを表す機能要件、表示速度は品質を表す非機能要件にあたる。
B. 3つとも実現すべき機能の内容がすでに決まっているため、分類は行わずいずれも機能要件としてまとめて扱っておけばよい。
C. レポートの表示速度はビジネス要件、四半期ごとの受注率の確認は非機能要件、商談完了時の上長への通知は機能要件にあたる。
D. 経営会議で参照するものはすべて非機能要件、担当者が日常業務で使うものはすべて機能要件として、利用者の立場で区別していく。
問19. ［難易度：シナリオ応用］
Northern Trail Outfitters社のプロジェクトで、「商談の一覧を改善する」という粒度の項目がバックログに並んでいる。開発担当からは何をもって完了とするか分からないという声が出ている。
コンサルタントはバックログの項目をどう書き直すべきか。
A. 画面の項目名と配置順、配色の指定まで含めた詳細な設計書として書き直し、そのまま開発担当に渡して実装を進めさせる。
B. 現在の記述を親の項目として残したうえで、その下に必要な技術的な作業タスクを細かく列挙して一覧に整理し直す。
C. 開発担当との見積もりの工数を先に決めてしまい、その範囲内で実現できる内容を後から改めて定義し直すことにする。
D. 誰が何をしたいのか、なぜ必要なのかを一文で表し、完了とみなせる条件を検証可能な受け入れ基準として添える。
問20. ［難易度：シナリオ応用］
Ursa Major Solar社では、初回リリースまで3か月しかないのに要件が60件挙がっている。関係者はいずれも必須だと主張しており、リリース時期は動かせない。
コンサルタントが取るべき進め方はどれか。
A. 挙がった60件すべてを初回の対象に含めたうえで、期間内に終わらない分はテストや品質の基準を下げて期日に間に合わせる。
B. 挙がった要件を部門ごとに均等に割り当て、どの部門にも同じ数の要件が初回に入るように調整して関係者の合意を取る。
C. 業務が回るために欠かせない要件を関係者と合意して初回の範囲に絞り、残りは次回以降の候補として一覧に残す。
D. 実装が容易な要件から順に着手していき、期間の終わりに残った分を関係者へまとめて報告して最終的な判断を仰ぐ。
問21. ［難易度：シナリオ応用］
AW Computing社の受け入れテストで、初期のヒアリングで挙がっていた要件のいくつかが実装されていないことが判明した。設計書もテスト仕様書も個別には作られていた。
再発を防ぐためにコンサルタントが導入すべきものは何か。
A. 受け入れテストの回数を増やし、テスト担当者を交代させて確認する目を増やす。
B. 要件ごとに設計・実装・テストケースの対応を一覧で追跡できる表を作り、対応先が空欄の要件を定期的に点検する。
C. ヒアリングの終了後は要件の変更をすべて凍結し、新しい要件を一切受け付けない運用へ切り替えることで対象範囲を固定する。
D. 要件の一覧を毎週配布し、抜けに気付いた人が申告する仕組みを作る。
問22. ［難易度：シナリオ応用］
Universal Containers社の実装が中盤に差しかかり、週次の定例のたびに「ついでにこれも」という依頼が積み上がって、当初の完了予定日に間に合わない見通しになった。依頼はいずれも小さく、個別には数時間で終わる内容である。
コンサルタントが取るべき対応はどれか。
A. 小さな依頼はその場で引き受け、遅延が確定してから完了予定日の延期を申し入れる。
B. 以降は追加の依頼を一切受け付けないと定例の場で宣言し、範囲の議論は行わず進捗と課題の報告だけに時間を使う。
C. 追加の依頼を変更管理の対象として記録し、工数と期日への影響を示して次回以降に回すか初期の範囲と入れ替えるかを判断してもらう。
D. 追加分を吸収するためにチームの残業と休日作業で作業時間を延ばし、工数の増加は共有せず当初の完了予定日を守ることを最優先にする。
問23. ［難易度：シナリオ応用］
Universal Containers社の要件一覧を標準機能と突き合わせた結果、いくつかの要件が標準機能だけでは実現できないと判明した。プロジェクトの期間は短く、カスタム開発に充てられる予算枠も限られている。
コンサルタントは次にどのような手順で進めるべきか。
A. 実現できなかった要件をすべて開発対象として見積もり、予算を超えた分を次フェーズへ先送りする。
B. 各差分を業務上の重要度と代替手段の有無で分類し、業務手順の見直しで吸収できるものを切り分けてから開発対象を決める。
C. 実現できなかった要件を一覧から取り下げ、標準機能の範囲だけで設計へ進む。
D. AppExchangeのパッケージをすべての差分に一律に適用し、業務手順の見直しは行わず標準機能との開きを購入によって埋める。
問24. ［難易度：基礎］
営業部門を横断する導入プロジェクトで、部門ごとに優先したい機能が食い違い、対象範囲の決定が滞っている。プロジェクトには役員がエグゼクティブスポンサーとして任命されている。
このスポンサーにはどの役割を期待すべきか。
A. 各部門の要件を項目単位まで自ら読み込み、設計上の実現可否や実装方式をプロジェクトチームに代わって判断する。
B. 対立する優先順位に経営の視点で判断を下し、決定した内容を全社に向けて発信して推進を後押しする。
C. 週次の進捗会議に出席して遅延しているタスクを洗い出し、担当者への割り当てを直接調整する。
D. 受け入れテストのシナリオを作成し、結果の合否を1件ずつ承認する。
問25. ［難易度：基礎］
要件定義の会議で、営業部門は入力項目を減らしてほしいと主張し、経営管理部門は分析のために項目を増やしてほしいと主張している。議論は平行線のまま次の工程の開始日が近づいてきた。
コンサルタントはこの状況でどう進めるべきか。
A. 両部門の担当者を集めて多数決を取り、投票の結果をそのまま設計へ反映する。
B. それぞれの主張が達成したい業務成果まで掘り下げ、共通の判断基準を作ったうえで意思決定者へ選択肢を示す。
C. いったん双方の要件をすべて実装したうえで稼働させ、使われていない項目を後から順に削っていく。
D. 議論を打ち切って設計へ進み、開発の途中で実現できないと分かった要件から順に取り下げる。
問26. ［難易度：難問］
Universal Containers社の導入プロジェクトでは、設計内容が誰の判断で確定するのかが曖昧で、いったん承認された設計が後から覆る事態が繰り返されている。関係する部門は6つに及ぶ。
コンサルタントの対応として妥当なのはどれか。
A. 関係する6部門の代表者全員を承認者に設定した承認プロセスを作成し、全員の承認で確定させる。
B. 成果物ごとに実行者・説明責任者・相談先・報告先を一覧に割り当て、説明責任者は各成果物に1名だけ置く。
C. 会議の議事録に決定事項を記載し、次の会議までに異議が出なければ確定とみなす運用にする。
D. 変更が生じるたびに課題管理表へ登録し、優先度を付けて上から順に処理していく。
問27. ［難易度：シナリオ応用］
Ursa Major Solar社の導入プロジェクトは、営業企画部門と情報システム部門のメンバーだけで要件を固めてきた。稼働の2か月前になって、現場の営業担当から実際の商談の進め方と画面が噛み合わないという指摘が出始めた。
今後はどのように進めるべきか。
A. 稼働日を数か月延期し、営業企画部門が現場の担当者への個別のヒアリングを最初からやり直す。
B. 現場からの指摘はいったん稼働後の改善要望として一覧にまとめておき、次のフェーズで優先度を付けて一括対応する。
C. 画面の使い方を説明する研修を追加で実施し、設計には手を入れずに現場の商談の進め方を新しい流れへ合わせてもらう。
D. 各営業チームから代表者を選んで設計レビューとテストに参加させ、実際の手順との差分を稼働前に洗い出す。
3. Agentforce Sales に関する専門知識の実践的な応用
問28. ［難易度：難問］
Cloud Kicks社では卸売部門と直販部門で商談の進め方が異なり、卸売部門だけが「与信審査」という段階を通る。両部門とも同じ商談オブジェクトを使い、パイプラインのレポートは全社で合算したい。直販部門のユーザーには与信審査を選ばせたくない。
コンサルタントが設計すべき構成として最も適切なものはどれか。
A. 卸売部門専用のカスタムオブジェクトを作成し、その選択リストにだけ与信審査を追加する。
B. 商談フェーズに与信審査を追加し、部門ごとのセールスプロセスで使う値を分けてレコードタイプに割り当てる。
C. 与信審査をチェックボックス項目として追加し、直販部門のプロファイルでは項目レベルセキュリティで隠す。
D. 入力規則で直販部門のユーザーが与信審査を保存できないようにし、一覧は全部門で共通にする。
問29. ［難易度：難問］
Northern Trail Outfitters社では、商談が提案の段階へ進むときに競合名と提案金額を必ず記録させたい。営業担当にはどの項目を埋めるべきかを画面上で示しつつ、未入力のまま次のフェーズへ進めることは確実に防ぎたい。
コンサルタントの提案として最も適切なものはどれか。
A. パスの主要項目に両方の項目を配置して入力を促し、フェーズの進行を止める判定は入力規則で担保する。
B. パスの主要項目に設定すれば入力が済むまで保存できなくなるので追加の設定は不要。
C. 両方の項目をオブジェクトの項目定義で必須項目にし、パスにはガイダンスだけを表示する。
D. ページレイアウトでフェーズごとに項目を必須にし、レイアウト割り当てで営業担当に適用する。
問30. ［難易度：難問］
AW Computing社のマネージャーから、商談のフェーズを進めても確度が想定どおりに変わらないレコードがあるという指摘があった。調べると、一部の営業担当が確度を自分で書き換えたあとにフェーズを更新していた。
確度項目の挙動について正しい説明はどれか。
A. 確度はフェーズから算出される読み取り専用の項目で、営業担当は書き換えられない。
B. フェーズを変更するとそのフェーズに定義された既定の確度が入るが、その後の手動編集で上書きできる。
C. 一度手動で編集した確度は以後のフェーズ変更でも更新されず、レコードを作り直す以外に戻す方法はない。
D. 確度は売上予測分類から算出される項目であるため、フェーズではなく売上予測分類の設定を見直す必要がある。
問31. ［難易度：基礎］
値引き率に応じて承認者を変えたいという要望が出ている。10%までは営業マネージャーが承認し、それを超える場合は営業マネージャーの承認後に事業部長の承認も必要とする運用にしたい。
この要件を満たす承認プロセスの設計はどれか。
A. 1つの承認プロセスに承認ステップを2段設け、2段目にはそのステップを開始する条件として値引き率の判定を指定する。
B. 承認プロセスを値引き率ごとに2つ作成して両方を有効化し、申請時にユーザーがどちらのプロセスを使うかを画面上で選べるようにする。
C. 承認ステップは1段だけ作り、承認者を決める項目を数式で切り替えて営業マネージャーと事業部長の両方を同時に指定する。
D. 入力規則で10%を超える値引きを保存できないようにし、例外は所有者の変更で個別に対応する。
問32. ［難易度：基礎］
申請者が金額を誤ったまま承認申請を出してしまい、承認者が処理する前に自分で取り下げたいと相談があった。現状では申請者の画面に取り消しの操作が現れない。
管理者はどの設定を確認すべきか。
A. 最終承認時のアクションに、レコードのロックを解除する設定を追加する。
B. 承認プロセスの設定で、提出者による承認申請の取り消しを許可しているかどうかを確認する。
C. 承認者のプロファイルに「すべてのデータの編集」を付与し、申請者の代わりに却下の操作をしてもらう。
D. 申請者に「承認プロセスの管理」権限を付与し、設定画面から申請中のレコードのロックを解除させる。
問33. ［難易度：シナリオ応用］
リードに追加した「導入予定時期」というカスタム項目の値が、取引開始後に作られる商談へ引き継がれていないという報告が上がった。商談側にも同じデータ型のカスタム項目が用意されている。
管理者が行うべき対応として最も適切なものはどれか。
A. 商談側のカスタム項目のAPI参照名をリード側とそろえ、名前の一致で転記されるようにする。
B. 保存後のレコードトリガーフローを商談に作り、取引開始のたびに元のリードを検索して値を転記する。
C. リードのページレイアウトに項目を追加し、取引開始時に使うレイアウトにも同じ項目を表示させる。
D. リードの項目の対応付け画面で、この項目の転記先として商談側のカスタム項目を指定する。
問34. ［難易度：シナリオ応用］
地域ごとに担当者を分けてリードを自動で振り分けたい。振り分け先の担当者には割り当てられたことを知らせるメールを届け、担当が決まらないリードが放置される事態も避けたい。
管理者の設定として最も適切なものはどれか。
A. 地域ごとのルールエントリを1つの割り当てルールに並べて通知テンプレートを指定し、未一致分はデフォルトのリード所有者に渡す。
B. 割り当てルールを地域の数だけ作成してすべて有効化し、どの条件にも一致しなかったリードには最初に作成したルールが適用されるようにする。
C. 保存後のレコードトリガーフローで地域に応じて所有者を書き換え、割り当ての通知は所有者が変更されたときの標準のメールに任せる。
D. すべてのリードを一つの共通のキューに入れ、各担当者が自分の地域の分を一覧から探して取得する運用にする。
問35. ［難易度：シナリオ応用］
商談の金額が一定額を超える場合、担当部門の項目が空欄のままでは保存させたくない。あわせて、保存できたレコードについては関連する取引先の最終取引日を更新したい。
これら2つの要件は、どのように実装するのが妥当か。
A. どちらも保存前のレコードトリガーフローで実装し、条件に合わない場合は画面にメッセージを表示する。
B. 保存の可否も関連レコードの更新も入力規則で扱い、エラーに更新内容を含める。
C. 保存の可否は入力規則で判定し、関連する取引先の更新は保存後のレコードトリガーフローで行う。
D. どちらも保存後のレコードトリガーフローに集約し、条件を満たさない場合は保存済みのレコードを削除して戻す。
問36. ［難易度：シナリオ応用］
Ursa Major Solar社では、商談を保存するときに割引後の金額を計算して同じレコードの項目へ入れている。処理件数が多く、実行時間の短縮が課題になっている。あわせて、成立した商談から納品準備のレコードを作る自動化も必要になった。
この2つの処理はどのように実装すべきか。
A. 両方の処理を一つの保存後のレコードトリガーフローにまとめ、決定要素で処理内容を分岐させる。
B. 両方の処理を保存前のレコードトリガーフローに置き、納品準備のレコードは「レコードを作成」要素で作成して処理をまとめる。
C. 割引後の金額の計算を数式項目に置き換え、納品準備のレコードの作成はスケジュール済みパスで日次にまとめて実行する。
D. 金額の計算は追加の更新処理が発生しない保存前のフローで行い、納品準備のレコード作成は保存後のフローで実装する。
問37. ［難易度：シナリオ応用］
Universal Containers社では、失注した商談に失注理由と競合先を記録させたい。営業担当は入力の順序を迷いやすく、理由によって追加で聞くべき内容も変わる。入力の抜けをなくしつつ、迷わず終えられるようにしたい。
コンサルタントはどのような提案を行うべきか。
A. 商談のページレイアウトに失注に関連する項目をすべて配置し、各項目のヘルプテキストで入力すべき順序と追加で聞く内容を案内する。
B. 失注理由と競合先の項目それぞれに入力規則を作り、入力の抜けがあればエラーメッセージで次に入力すべき項目の名前を順番に示す。
C. 画面フローを作り、選ばれた理由に応じて次に表示する質問を切り替え、レコードページのアクションから起動できるようにする。
D. 失注理由ごとに商談のレコードタイプを作り、それぞれのページレイアウトに必要な項目だけを配置する。
問38. ［難易度：シナリオ応用］
Universal Containers社では、商談の完了予定日の3日前に所有者へ通知を送り、その時点でまだ完了していない商談だけを対象にしたい。完了予定日は商談ごとに異なる。
どの実装方法が要件に合致するか。
A. スケジュールトリガーフローを毎日実行し、すべての商談を取得して完了予定日との差を1件ずつ計算したうえで所有者に通知する。
B. 保存後のレコードトリガーフローにスケジュール済みパスを設け、完了予定日の3日前を基準にして通知のアクションを置く。
C. 保存前のレコードトリガーフローにスケジュール済みパスを設定し、レコードの保存と同時に3日前の通知を予約しておく構成にする。
D. 完了予定日から今日までの残りの日数を返す数式項目を商談に作り、その値が3になった時点で所有者へ通知を自動で送る仕組みにする。
問39. ［難易度：シナリオ応用］
Universal Containers社では、取引先の画面に進行中の商談の合計金額を表示したい。商談と取引先は標準の参照関係で結ばれている。開発者を確保する余裕はない。
実装方針として最も適切なものはどれか。
A. 取引先に積み上げ集計項目を作成し、進行中のフェーズだけを絞り込み条件に指定して、関連する商談の金額の合計を表示する。
B. 取引先に数式項目を作成し、関連する商談の金額を参照して進行中の商談の合計を算出する。
C. 商談の保存後のレコードトリガーフローで進行中の商談の合計を計算し、取引先のカスタム通貨項目へ書き戻す自動化を作り込む。
D. 商談側に数式項目を作って取引先の合計金額を参照させ、取引先の関連リストとして画面に配置する。
問40. ［難易度：シナリオ応用］
Cloud Kicks社では、新規リードの作成時にフローで初回架電のToDoを作っている。今回インサイドセールスにケイデンスを導入したところ、同じリードに同じ趣旨のToDoが2件並ぶようになった。担当者はどちらを消化すべきか迷っている。
コンサルタントの提案として最も適切なものはどれか。
A. フローで作るToDoの件名を変更し、担当者が見分けられるようにしたうえで両方を残す。
B. ケイデンスの対象をリードから取引先責任者に変更し、リードにはフローのToDoだけを残す。
C. 重複ルールをToDoに設定し、同じ日付のToDoが2件作られないようにする。
D. 初回接触の管理はケイデンスに一本化し、リードの作成時にToDoを作るフローは停止する。
問41. ［難易度：基礎］
夜間に動く自動化が失敗していたことに、翌日ユーザーから指摘を受けて初めて気付いた。そのフローを作成したユーザーはすでに退職している。
管理者はどのような設定を行うべきか。
A. フローのすべての要素に障害パスを追加して管理者へChatterで投稿する処理だけを付け、エラーメールの送信先は変更しない。
B. フローを無効化し、同じ処理を手作業の手順書に置き換えて運用でカバーする。
C. Apex例外メールの受信者に現任の管理者を登録してエラーメールの送信先をそちらへ切り替え、障害パスで失敗を記録する。
D. 毎朝、設定変更履歴を確認して前日のフローの失敗が記録されていないか点検する。
4. データ管理
問42. ［難易度：シナリオ応用］
Universal Containers社は10年分の営業データを持つ既存システムからSalesforceへ移行する。データの半分以上は5年以上前に完了した案件で、営業部門は日常業務で参照していないが、監査目的での保管義務がある。移行期間とストレージ費用はできるだけ抑えたい。
コンサルタントはどのような方針を提案すべきか。
A. 業務で参照するデータのみを移行対象とし、参照頻度の低い古い案件は外部のアーカイブに保持して必要時に取り出せるようにする。
B. すべてのレコードをそのまま移行したうえで、5年以上前の案件には入力規則を設定して参照を止める。
C. 古い案件を専用のカスタムオブジェクトへ移行し、レコードタイプで新旧を分けて一覧から除外する。
D. 移行対象を絞らずに全件を一括で取り込み、後から一括削除ツールで不要分を除いて整理する。
問43. ［難易度：基礎］
取引先、取引先責任者、商談、商談の取引先責任者の役割を含むデータを、新しい組織へ順に投入する計画を立てている。関連付けの欠落は避けたい。
オブジェクトの投入順序の考え方として最も適切なものはどれか。
A. 件数の少ないオブジェクトから順に投入し、最後に最も件数の多いものをまとめて取り込む。
B. 参照先のIDは取り込み時に自動で解決されるので、投入の順序を問わず並列に投入してよい。
C. 子レコードを先に投入し、親の作成が終わってから一括更新でリレーションを埋める。
D. 親となる取引先から先に投入し、そのIDを参照する取引先責任者・商談・役割の順で後続を取り込む。
問44. ［難易度：基礎］
移行元システムの取引先コードを保持したまま、取引先責任者を正しい取引先にひも付けたい。移行の時点ではSalesforce側の取引先IDがまだ手元にない。
外部IDをどのように使えばよいか。
A. 移行元の取引先コードを取引先の名前項目の末尾に連結し、取引先名の完全一致で関連付ける。
B. 取引先責任者側にだけ外部ID項目を作成し、取引先の作成後に参照項目を手作業で埋めていく。
C. 取引先に外部ID項目を作り、取引先責任者の取り込み時に参照項目をその外部IDの値で指定してアップサートする。
D. 取引先コードを取引先責任者のテキスト項目へ転記し、移行後にレポートで突き合わせて確認する。
問45. ［難易度：シナリオ応用］
Northern Trail Outfitters社は基幹システムから取引先を移行する。移行後もしばらくは基幹システムが稼働し、双方のレコードを突き合わせて差分を確認する必要がある。基幹システム側の番号は一意で変更されない。
移行設計として最も適切なものはどれか。
A. 基幹システムの番号を取引先名の先頭に付けて保存し、名前の並べ替えで双方を突き合わせる。
B. 基幹システムの番号を格納する外部ID項目を取引先に作り、一意の設定を有効にしたうえで移行時に値を入れる。
C. 移行後にSalesforce側で採番されたレコードIDを基幹システムへ書き戻し、以後はそれを突合の鍵にする。
D. 移行ファイルの行番号をカスタムテキスト項目に保持しておき、移行時に出力したログと照合して双方の差分を追跡する。
問46. ［難易度：シナリオ応用］
AW Computing社の管理者が、8万件の取引先責任者を一度に取り込む作業と、営業アシスタントが月次で数百件のリードを追加する作業の両方を担当している。後者は毎月同じ形式のファイルを使う。
管理者はどのようにツールを選択すべきか。
A. どちらもデータインポートウィザードで実施し、8万件の取り込みは重複ルールを使いながら複数回に分割して順に進める。
B. 8万件の取り込みはデータローダで行い、月次の数百件は重複を検出できるデータインポートウィザードに任せる。
C. どちらもデータローダで実施し、営業アシスタントにはシステム管理者プロファイルを割り当てる。
D. 8万件はデータインポートウィザードを複数回に分けて実行し、月次分はデータローダのコマンドラインで自動化する。
問47. ［難易度：難問］
Ursa Major Solar社は300万件の取引先責任者を投入する。テスト実行では、同じ取引先にひも付く行が別々のまとまりに分かれたときに行ロックのエラーが多発した。取り込みにかかる時間はできるだけ短く抑えたい。
コンサルタントの提案として妥当なのはどれか。
A. 行の件数が多いほど競合が増えるため、Bulk API 2.0の利用をやめ、同期のAPIを使って1件ずつ順番に投入していく。
B. 取引先のIDで並べ替えて同じ親のレコードをまとめ、なお競合が残る場合はBulk APIの逐次モードを検討する。
C. 取り込みの最初からBulk APIの逐次モードを選んだうえで、1回のまとまりに含める件数を上限まで増やして処理量を稼ぐ。
D. 行ロックで失敗した行は取り込みの処理の中で自動的に再試行される仕組みのため、エラーファイルを確認せずに完了を待てばよい。
問48. ［難易度：難問］
AW Computing社の本番移行では、取引先と商談を夜間に一括で投入する。組織には商談の保存後に走るフロー、金額を集計する積み上げ集計項目、日付の前後関係を確かめる入力規則がある。移行データは移行元で検証済みで、投入後には集計値も正しく必要である。
移行当日の扱いとして最も適切なものはどれか。
A. 金額を集計する積み上げ集計項目を移行の当日に一時的に削除しておき、投入がすべて終わってから作り直して再計算させる手順にする。
B. フローも入力規則もすべて有効のままにして夜間に一括投入し、処理時間が延びた分は毎回の投入の開始時刻を前倒しして吸収することにする。
C. 日付の前後関係を確かめる入力規則だけを一時的に無効化しておき、保存後のフローと積み上げ集計項目は有効のまま投入を進める。
D. 検証済みのデータに再度適用する必要のない入力規則とフローを一時的に無効化し、積み上げ集計項目は自動での再計算に任せる。
問49. ［難易度：基礎］
移行元システムに記録されている作成日と作成者を、Salesforceのレコードにもそのまま残したいという要望がある。移行はデータローダで行う予定である。
この要件を実現する方法はどれか。
A. 移行元の作成日と作成者は別のカスタム項目として作るしかなく、標準の監査項目は移行を実行した日付と実行したユーザーのままになる。
B. 移行が終わった後にデータローダの更新処理で作成日と作成者を書き換え、必要に応じて何度でも修正できるようにしておく運用にする。
C. 設定の［ユーザーインターフェース］で監査項目の設定を有効にし、権限を付与したうえでAPIによる作成時に値を渡す。
D. 設定変更履歴に移行元の作成日と作成者をまとめて登録しておき、レコードの詳細画面からいつでも参照できるようにする運用にする。
問50. ［難易度：シナリオ応用］
本番移行の前に、手順と所要時間を確かめておきたい。移行対象は複数のオブジェクトにまたがり、当日の作業時間には限りがある。
リハーサルの進め方として最も適切なものはどれか。
A. 本番相当の件数をSandboxに投入して所要時間と失敗行を記録し、件数と金額の合計を移行元と突き合わせる。
B. 各オブジェクト100件ずつをSandboxに投入して手順の正しさだけを確認し、所要時間の把握は当日の実測に委ねる。
C. リハーサルを省いて本番組織に直接投入してから結果を確認し、問題が見つかればごみ箱から復元して最初から再実行する。
D. 移行ファイルの列の形式を表計算ソフトで点検し、実際の投入は本番当日に1回だけ行って作業の時間を節約することにする。
問51. ［難易度：基礎］
取引先の一括投入で一部の行が失敗した。成功した行はすでに登録されている。原因を調べ、正しい状態に戻したうえで再実行したい。
対応として最も適切なものはどれか。
A. 成功ファイルの内容は確認せず、修正していない同じ入力ファイルをもう一度そのまま再実行することで、登録されなかった行だけを補う。
B. 失敗した行だけを画面から手作業で登録し、エラーファイルは確認せずに破棄する。
C. ごみ箱から削除済みレコードを復元し、登録された行も含めて取り込み直す。
D. エラーファイルで失敗の理由を特定して入力を修正し、成功ファイルのIDを使って登録済み分を取り消すか更新して整合を取る。
問52. ［難易度：シナリオ応用］
Ursa Major Solar社の移行元データには、表記の揺れた取引先名、重複した取引先責任者、廃止済みの選択リスト値が混在している。移行の期限は決まっており、稼働後の並行稼働期間は設けない。
クレンジングの進め方として最も適切なものはどれか。
A. すべて移行後にSalesforce上で行い、重複ルールと一致ルールによる検出に任せる。
B. 移行を2回に分け、1回目で全件をそのまま投入して品質を確認し、2回目で修正済みのデータを上書きすることで仕上げる。
C. クレンジングは移行の対象外とし、業務担当者が日々の運用の中で少しずつ直す。
D. 表記の揺れと重複は移行前に移行元で整理し、選択リスト値は新旧の対応を変換規則として定義して投入時に適用する。
5. 予測 AI と生成 AI
問53. ［難易度：基礎］
営業企画の担当者が、来期のパイプライン管理を改善するためにAIの活用方法を検討している。候補に挙がっているのは「過去の取引実績をもとに受注しやすい案件を数値で順位付けする」用途と、「顧客への提案メールの下書きを自動で作る」用途の2つである。
この2つの用途は、それぞれどの種別のAIに対応するか。
A. 順位付けもメールの下書きも大規模言語モデルが担うため、いずれも生成AIに分類される。
B. 順位付けが生成AI、メールの下書きが予測AIにあたり、学習に使うデータ量は前者のほうが多い。
C. 順位付けは過去データからスコアを導く予測AI、メールの下書きは新しい文章を作る生成AIが担う。
D. どちらも同じ分類モデルで実現でき、出力形式を設定で切り替えるだけで両方に対応できる。
問54. ［難易度：基礎］
Enterprise Editionを利用している組織で、営業部門向けの予測AI機能の導入可否を確認している。追加費用が発生するのか、利用者ごとの割り当てが要るのかを整理したい。
Sales Cloud Einsteinを利用するための前提条件はどれか。
A. 現在のEditionでは利用できず、Unlimited Editionへのアップグレードが唯一の選択肢になる。
B. 有料オプションとして提供されるため追加購入が必要で、利用するユーザーにアドオンライセンスを割り当てる。
C. 標準機能として全エディションに含まれており、設定画面で有効にするだけで全ユーザーが利用できる。
D. Sales Cloudのライセンスとは別に、Data 360のライセンスを購入することが必須条件になる。
問55. ［難易度：シナリオ応用］
Universal Containers社はEinstein商談スコアリングの利用を検討している。Salesforceの利用開始から4か月で、完了した商談は成立・不成立を合わせて80件ほどしかない。営業からは自社の傾向を反映したスコアを早く見たいという声が出ている。
コンサルタントの説明として最も適切なものはどれか。
A. 完了した商談が1件でもあれば自社データだけでモデルが作られるため、有効化した翌日から自社の傾向がスコアに反映される。
B. スコアリングは完了商談の件数ではなく活動データの量で決まるため、活動の記録を増やせば自社のデータによるモデルに切り替わる。
C. 自社モデルには過去24か月で成立・不成立が各200件以上必要で、それまではグローバルモデルのスコアが表示される。
D. 必要な件数に達するまでスコアは一切表示されないため、件数がそろうまで有効化を見送るべきである。
問56. ［難易度：基礎］
営業マネージャーから、Einstein商談スコアリングの数値がどの範囲で示され、どこで確認できるのかを知りたいという質問があった。
説明として最も適切なものはどれか。
A. 商談ごとに1から99までのスコアが付き、レコードのほかリストビューやレポート、売上予測の画面でも確認できる。
B. スコアは0から100までの百分率で示され、その値がそのまま売上予測の金額の見込みに反映される仕組みになっている。
C. スコアは高・中・低の3段階で示され、確認できる場所は商談のレコードページに置かれた専用の項目だけに限られる仕様である。
D. スコアはレポートの実行時にその場で計算されるため、レコードページの詳細には表示されず、リストビューでの並べ替えにも使えない。
問57. ［難易度：基礎］
導入して間もない組織でEinstein商談スコアリングを有効にしたところ、自社の商談の傾向とは異なるスコアが付いているように見えるという指摘が出た。
グローバルモデルについての説明として正しいものはどれか。
A. グローバルモデルは組織の設定で選ぶ方式で、自社モデルへの切り替えには手動での申請が必要になる。
B. 自社モデルを作れるだけの商談データがそろうまでは、複数の顧客の匿名データを集約したグローバルモデルでスコアが付く。
C. グローバルモデルは同じ業種にある他社の商談レコードを直接参照して計算する仕組みのため、自社の商談データは一切使われない。
D. グローバルモデルの間はスコアが表示されず、自社モデルの完成後に一括で反映される。
問58. ［難易度：基礎］
リードには社内管理用の連番や担当者のメモといった、スコアの根拠にしたくない項目がある。これらがモデルに影響することを避けたい。
除外の設定について正しい説明はどれか。
A. リード区分ごとにスコアリングで無視する項目を指定でき、指定した項目はモデルの作成時に使われない。
B. 除外したい項目は項目レベルセキュリティで参照を無効にすれば、モデルの対象からも自動的に外れる。
C. 使用する項目はSalesforceが自動で決めるため、管理者が対象を調整することはできない。
D. 除外の指定は1組織につき1つしか持てず、リード区分ごとに内容を変えることはできない。
問59. ［難易度：シナリオ応用］
Northern Trail Outfitters社はEinsteinリードスコアリングの導入を希望している。直近200日に作成されたリードは3,000件あるが、取引先と取引先責任者に変換されたのは40件にとどまる。営業は変換したリードをすぐ削除する運用を続けてきた。
コンサルタントはどのように説明すべきか。
A. 変換された実績が必要な件数に届かないため、まず変換済みリードを残す運用へ改め、実績が積み上がってから有効化する。
B. リードの作成件数が1,000件を超えているため、変換の件数にかかわらず自社データでモデルを作成できる。
C. 変換の実績が不足していてもリードの項目情報だけからモデルが作られるため、有効化すればその日から自社のスコアが付く。
D. 変換済みリードを削除していても履歴から実績を再構成できるため運用は変えなくてよい。
問60. ［難易度：シナリオ応用］
Ursa Major Solar社でEinsteinリードスコアリングを有効にしたが、スコアが一部の帯に偏っていて優先順位付けの役に立たないという声が営業から出ている。この組織では直近200日に作成されたリードのうち、取引の開始まで進んだものが数十件しかない。
管理者が最初に確認すべきことはどれか。
A. リードのページレイアウトにスコアの項目が配置され、すべてのプロファイルから参照できるか。
B. リードの割り当てルールが最新の内容で、スコアの高いリードが適切なキューへ渡っているか。
C. 取引の開始まで進んだリードの件数が、モデルの学習に必要とされる水準に達しているか。
D. スコアの項目に担当者が手入力した値が混ざっていないかを、入力規則を作成して検証できるか。
解答一覧
ここから答え合わせです。まだ解き終えていない方は戻ってください。
問1 D / 問2 C / 問3 A / 問4 D / 問5 C / 問6 C / 問7 B / 問8 A / 問9 C / 問10 C
問11 A / 問12 A / 問13 D / 問14 A / 問15 D / 問16 A / 問17 B / 問18 A / 問19 D / 問20 C
問21 B / 問22 C / 問23 B / 問24 B / 問25 B / 問26 B / 問27 D / 問28 B / 問29 A / 問30 B
問31 A / 問32 B / 問33 D / 問34 A / 問35 C / 問36 D / 問37 C / 問38 B / 問39 A / 問40 D
問41 C / 問42 A / 問43 D / 問44 C / 問45 B / 問46 B / 問47 B / 問48 D / 問49 C / 問50 A
問51 D / 問52 D / 問53 C / 問54 B / 問55 C / 問56 A / 問57 B / 問58 A / 問59 A / 問60 C
採点と判定
結果はいかがでしたか。正解数から、いまの状況を把握しましょう。
44問以上（73%以上）
合格ラインに乗っています。ただし本番は初見の問題ばかりですし、この模試より緊張もするはずです。ここからはシナリオ問題と難問層をどれだけ潰せるかが差になります。
38〜43問
あと一歩です。取りこぼしている分野がはっきりしているはずなので、次の「セクション別の正答率シート」で弱点を特定してください。この層は演習量を積めば最も伸びます。シナリオ問題で時間を使いすぎていないかも振り返ってみてください。
37問以下
基礎領域に抜けがあります。いま受験しても厳しい結果になる可能性が高いので、分野ごとに演習量を積むことを先にしてください。
どの結果でも共通して言えること
当研究所が実際に受験してきた範囲では、シナリオ形式の問題が多く出ます。状況設定を読み解いたうえで最適な設定を選ばせてくるので、用語を覚えているだけでは手が止まりますし、思っている以上に頭と時間を使います。ここに慣れているかどうかが、同じ知識量でも結果を分けます。
本記事では60問中28問（47%）をシナリオ形式にしました。形式ごとの内訳は公式試験ガイドに公表されていないため、これは当研究所の判断による配分です。実際に受験してきた経験から、これくらいは身構えて臨んだほうがよいと考えています。
解き直すときは正解を確かめるだけでなく、問題文のどこを手がかりに絞り込んだのかを言葉にしてみてください。それが本番で効きます。
セクション別の正答率シート
問番号はセクション順に並んでいます。分野ごとに正解数を数えると、どこを重点的にやり直すべきかが分かります。
- セールスライフサイクル：問1〜問12（12問） 正解した数 ＿＿ / 12
- コンサルティングおよび実装戦略：問13〜問27（15問） 正解した数 ＿＿ / 15
- Agentforce Sales に関する専門知識の実践的な応用：問28〜問41（14問） 正解した数 ＿＿ / 14
- データ管理：問42〜問52（11問） 正解した数 ＿＿ / 11
- 予測 AI と生成 AI：問53〜問60（8問） 正解した数 ＿＿ / 8
落とした分野をどう埋めるか
セクション別の正答率が出たら、次にやることは決まっています。落とした分野の演習量を積むことです。
まずはこのあとの全問解説で、60問ぶんの取りこぼしを潰してください。そのうえで演習量が足りないと感じたら、同じ密度の解説が付いた全500問の問題集があります。本記事の60問もこの中に含まれています。
全問解説（全60問）
正解の理由だけでなく、誤りの選択肢がなぜ誤りなのかまで書いています。間違えた問題はもちろん、迷って正解した問題も読んでおくと取りこぼしが減ります。
1. セールスライフサイクル
問1. 正解：D
適格性の確認が済み、商談として追跡する価値が固まった時点で取引開始するのがDのとおり適切で、それまでは育成の対象としてリードに置く。Aは未評価のレコードまで取引先・取引先責任者・商談を量産し、後から削除しても重複や不要な関連レコードが残る。BはEinsteinリードスコアリングが優先順位を示すだけで、取引開始という操作までは実行しないという機能の誤解である。Cは取引開始したリードを元の状態へ戻す標準機能がない点を見落としている。
問2. 正解：C
取引開始では取引先と取引先責任者が作られ、商談は作成するかどうかを選べる。標準項目は既定の対応付けで引き継がれる一方、カスタム項目はCのとおり管理者が対応付けを指定して初めて転記されるためCが正しい。Aはケースが作成対象に含まれない点と、全項目が複製されるという点の二重の誤りである。Bは項目名が同じでも自動では対応付かないという実装を取り違えている。Dは取引先と商談が作られないという説明が事実に反する。
問3. 正解：A
Web-to-リードは受け取った送信内容をリードとして自動生成し、割り当てルールで地域ごとのキューへ渡してメール通知まで行えるため、人手を介さずに初回応答までの時間を縮められるAが適切で、送信数も1日500件という上限の範囲に収まる。Bは手作業でのレコード作成が待ち時間の原因そのものを残す。Cは1名の確認を経る構造で、その人の稼働時間に応答速度が縛られる。Dは見込みの段階の情報を取引先責任者として取り込むため適格性評価の流れから外れ、共有ルールも通知を伴わない。
問4. 正解：D
リードプロセスはリードの状況の選択リスト値から使う組み合わせを定義する仕組みで、レコードタイプへ割り当てることでチャネルごとに表示する値を分けられるため、Dが正しい設定になる。Aは選択リストに全値が並んだままで、保存時のエラーでしか誤りを防げず操作性も悪い。Bはカスタム項目でチャネルを識別できても、状況の選択肢そのものは分けられない。Cは標準のリードの状況が二重管理になり、取引開始の判定や標準のレポートが正しく機能しなくなる。
問5. 正解：C
割り当てルールのエントリは上から順に評価されるため、最後にすべてのリードが一致するエントリを置けば未対応分の受け皿になる。宛先をインサイドセールスのキューにすればチーム全員が同じ一覧を見て取得でき、担当者不在でも滞留しないためCが最も確実。Aは受け皿にはなるが所有者が1名に固定され、その人が不在のときに滞留が再発する。Bはリードの発生自体を止める発想で、Webや取り込み経由の見込み客を取り逃がす。Dは可視化にとどまり、所有者が変わらないため対応の責任が曖昧なまま残る。
問6. 正解：C
学習に使える取引開始の実績がない段階では、営業経験者が説明できる業種と従業員規模の条件でランクを付けるCの方式が現実的で、実績が積み上がってから自動スコアへ移行する筋道も立つ。Aは自社データが不足する状況でグローバルモデルに頼ることになり、新規事業に固有の傾向を反映できない。Bは基準が担当者ごとに揺れるため、優先度の値が比較可能な指標にならない。Dは優先順位付けを放棄する案で、限られた営業リソースの配分という課題が解消しない。
問7. 正解：B
キャンペーンは施策ごとに費用や期間を保持し、リードや商談との関連を通じて投資対効果を集計できる標準の仕組みであるため、リードソースを経路の分類として保つBの設計が要件に合う。Aは選択リストの値が実施のたびに増え続け、経路単位の集計も費用の管理もできなくなる。Cは自由入力にすると表記が揺れ、集計の単位が定まらない。Dは説明欄が構造化されていない項目で、抽出も費用との突き合わせも安定しない。
問8. 正解：A
階層統計項目は親配下の子孫すべてを合算する集計で、閲覧者のレコードへのアクセス権とは切り離して算出されるため、権限のない子キャンペーンの数値も合計に含まれる点が要件の鍵になる。Bのキャンペーンインフルエンスは商談の収益をキャンペーンへ配分する機能であり、親子キャンペーン間の数値の合算は行わない。Cの積み上げ集計項目はキャンペーンメンバーを対象にした集計であれば作成できるものの、子キャンペーンのレスポンス数を階層をまたいで合算する用途には使えない。Dは階層の上限が5レベルであり、6階層目のキャンペーンを作成できない以上、合計から漏れる状況が起きない。
問9. 正解：C
メンバー状況ごとに用意されたレスポンス済みの指定が、キャンペーンのレスポンス数と反応率の分子を決めるため、出席と商談化の両方に指定を付けることで要件どおりの集計になる。Aの既定値は新規メンバーに初期設定される値を決めるだけの設定で、反応したかどうかの判定とは無関係である。Bの ［レスポンス数］ はSalesforceが自動的に更新する読み取り専用の集計項目で、数式項目へ作り替えることはできない。Dはカスタム項目とレポートで代替する案だが、キャンペーン標準の反応率には一切反映されず、要件である標準指標での測定を満たさない。
問10. 正解：C
カスタマイズ可能なキャンペーンインフルエンスでは1つの商談に複数のインフルエンスレコードを持たせ、モデルごとに配分の割合を定義できるため、複数施策への按分という要件に合致する。Aの主要キャンペーンソースは1件しか保持できず、上書きを重ねれば途中の接触の記録が消えてしまう。Bの階層統計項目はキャンペーン側の予算やレスポンスを合算する集計で、商談の金額を施策間に配分する機能ではない。Dの選択リストは1レコードにつき1つの値しか持てないため、複数の施策と配分比率を同時に表現できない。
問11. 正解：A
キャンペーンメンバーにはリード、取引先責任者、個人取引先に加えて取引先そのものを追加でき、法人を単位とした施策の管理を実現できる。なお取引先をメンバーにするには、あらかじめキャンペーンメンバーとしての取引先を有効化しておく必要がある。Bは取引先をメンバーにできないという古い前提に立った運用で、代表者へ置き換える必要は生じない。Cは個人取引先を見落としているうえ、キャンペーン階層は施策どうしの親子関係を整理して集計する機能である。Dはリードから取引先へ進む取引の開始が一方向の処理であり、取引先をリードへ戻す機能は存在しない。
問12. 正解：A
何をもって営業が着手すべきリードとするか、引き渡し後どれだけの時間で接触するかを両部門が同じ言葉で定義しない限り、件数と確度という別々の物差しでの言い合いは終わらない。Bの再割り当ては基準が決まった後に実装する仕組みで、渡す条件の合意がないまま導入しても質の不一致はそのまま残る。Cのしきい値の引き上げは件数の調整にすぎず、どういうリードなら着手するかが共有されていなければ営業の納得は得られない。Dの手作業の選別はマネージャーの判断に依存して基準が属人化し、件数が増えれば選別待ちの滞留を生む。
2. コンサルティングおよび実装戦略
問13. 正解：D
ディスカバリーでは実態を知る実務担当と方針を決められる立場の双方が同席し、論点と進め方を先に共有しておくことで、限られた時間を合意形成に使えるためDが適切。Aは現場だけでは経営側の狙いが取り込めず、前回と逆方向に偏った結論になる。Bは事前アンケート自体は有効だが、対話の場を報告に変えてしまい未知の論点を掘り起こせない。Cは部門を分ける進め方が部門間の依存関係を可視化できず、後追いの裁定は現場の納得を得にくい。
問14. 正解：A
現行のプロセスマップは作業・判断・担当者間の受け渡しを一つの図に置くため、待ち時間の所在や判断者のばらつきを関係者が同じ理解で指摘できるようになり、Aが目的に合う。Bは理想像だけを描くと現行の非効率が記録されず、何を解消したのかを後から説明できない。Cのユーザーストーリーは実装単位の要件を表す形式で、業務の流れや滞留の場所を示す構造を持たない。Dのモックアップは画面設計の妥当性を確かめる道具であり、承認が誰の手元で滞っているかを明らかにする用途には向かない。
問15. 正解：D
要望は解決手段の形で語られることが多く、Dのように判断の目的とそれが遅れたときの影響を順に尋ねると、色分け以外の選択肢も含めて評価できる業務課題が浮かび上がる。Aは手段を固定したまま作り込むため、真の課題が別にあった場合の手戻りが大きい。Bは実現可否の判断が先に立ち、そもそも作るべきかという問いを飛ばしてしまう。Cは要望の収集を優先するあまり、限られたヒアリング時間に深掘りの機会を失い、表面的な要望の一覧しか残らない。
問16. 正解：A
長く使われた組織では既存の自動化や項目が新しい要件の実現可否と工数を左右するため、Aのように棚卸しを先に行って制約を把握してから議論に入ると、実現できない案に時間を費やさずに済む。Bは要件を確定させたあとで衝突が判明する順序になり、手戻りと再合意の負担が大きい。CはSandboxでの試作が有効な場面もあるが、現行設定の理解を飛ばすため既存業務への影響が見えない。Dは調査の前に削除を進める点が危険で、まだ参照されている項目や自動化を壊す恐れがある。
問17. 正解：B
困りごとは語り口の強さと業務への影響が一致しないため、Bのように頻度・所要時間・関係人数を聞き取って共通の尺度に換算すると、限られた予算の配分を関係者と同じ根拠で議論できる。Aは声の大きさが影響度を表すとは限らず、発言の少ない部門の重い課題を取りこぼす。Cは実装の容易さだけを基準にすると、効果の小さい施策が並んで業務は変わらない。Dは3つを浅く実装する妥協で、どの課題も解消しきれず投資の効果を説明できなくなる。
問18. 正解：A
ビジネス要件は組織が達成したい成果を、機能要件はシステムが行う振る舞いを、非機能要件は応答時間などの品質特性を表すため、Aの割り当てが定義に沿う。Bは分類そのものを放棄しており、品質の目標が実装の裏に隠れて検証もされなくなる。Cはビジネス要件と非機能要件を取り違えており、表示速度は成果ではなく品質の指標である。Dは利用者の役職で分ける独自の基準で、要件の性質とは無関係な切り口になっている。
問19. 正解：D
ユーザーストーリーは利用者・実現したいこと・目的を一文で示し、完了の判断を検証可能な受け入れ基準に落とすことで開発担当と発注側の理解をそろえられるため、Dが適切になる。Aは設計の詳細を先に固定するため、目的を満たす別の実現手段を検討する余地を奪う。Bは作業の分解にとどまり、利用者にとっての価値と完了条件が依然として書かれていない。Cは工数から内容を決める順序で、必要な要件が予算に合わせて恣意的に切られてしまう。
問20. 正解：C
期間が動かせない前提では、業務が成立する最小限の範囲を関係者との合意のうえで切り出し、外した要件を次回の候補として残すCの進め方が納得を得やすく、後続の計画にもつながる。Aは品質を犠牲にする方針で、稼働後の不具合対応がかえって時間を奪う。Bは部門間の公平さを判断軸にしており、業務上の必要性という本来の基準とずれる。Dは着手順を難易度で決めるため、欠かせない要件が最後まで残る危険がある。
問21. 正解：B
実装漏れは要件と成果物の対応が誰にも見えていないときに起きるため、Bのように要件ごとに設計・実装・テストケースのひも付きを一覧化し、空欄を定期的に点検する仕組みが直接の対策になる。Aはテストの実行を増やすだけで、テストケースが作られていない要件は何度試しても見つからない。Cは変更を止める措置で、今回の原因である追跡の欠如には効かない。Dは気付いた人の申告に依存する受動的な運用で、誰も気付かない要件はそのまま残る。
問22. 正解：C
小さな依頼の積み重ねが期日を侵食している状態では、Cのように変更管理の手順に乗せて影響を数値で示し、後回しにするか既存の範囲と入れ替えるかを依頼側に選ばせるのが、合意を保ったまま計画を守る方法になる。Aは影響が見えないまま受け入れ続けるため、遅延の申し入れが唐突になり信頼を損なう。Bは要望の窓口を閉じる対応で、本当に必要な変更まで取り込めなくなる。Dは稼働時間の延長で埋める案で、品質の低下と要員の疲弊を招き再現性もない。
問23. 正解：B
差分を一律に扱わず、業務上どれだけ重要か、業務手順の変更や別の標準機能で代えられるかで仕分けたうえで開発の対象を絞る手順が、限られた予算と期間の下で最も損失が少ない。Aは重要度を問わずすべてを開発へ倒す判断で、業務側の見直しで消えたはずの要件まで保守コストの高い作り込みに変えてしまう。Cは関係者の合意なくスコープを削る対応で、業務上欠かせない要件を落としたまま設計が進む危険がある。Dはパッケージが適合する場合の選択肢にすぎず、全差分に当てはまる保証はないうえ、ライセンス費と追加の保守責任が新たに生じる。
問24. 正解：B
部門間で利害が割れたときに、経営として何を優先するかを決めて社内に示せるのはスポンサーだけであり、資源配分と優先順位の決定こそがこの役割の中核になる。Aの実現可否の判断はコンサルタントやアーキテクトが担う技術領域で、スポンサーが踏み込むと本来の意思決定が滞る。Cの日々のタスク管理はプロジェクトマネージャーの責務であり、ここに時間を使うとスポンサーに上げるべき論点が埋もれてしまう。Dのテストシナリオの作成と判定は業務を熟知した現場側の担当者が担うもので、スポンサーは結果の報告を受けて稼働可否を判断する立場にある。
問25. 正解：B
表明された要求の背後にある業務成果まで戻して共通の物差しを作れば、どちらを優先するかを意思決定者が根拠を持って選べるようになり、決定の蒸し返しも起こりにくくなる。Aの多数決は参加人数の多い部門の主張が通るだけで、業務上の重要度も投資対効果も反映されない。Cの両論併記は入力の負担を最大化したうえに、稼働後の項目削除がデータの欠損と再教育を伴うため代償が大きい。Dの先送りは手戻りの発生時期を開発工程まで遅らせるだけで、判断の基準も記録も残らない。
問26. 正解：B
成果物ごとに誰が作り、誰が最終的に説明責任を負い、誰に相談し誰へ報告するのかを明示し、説明責任者を1名に限ることで、決定の主体が特定されて覆りにくくなる。Aの全員承認は1人でも保留すれば止まるうえ、責任が全員に分散するため覆されやすさは何も変わらない。Cの議事録は決定の記録であって権限の定義ではなく、誰の権限で決まったのかが残らない限り蒸し返しは続く。Dの課題管理表は起きてしまった事象を追跡する道具で、決定権限が定まっていないという原因そのものには手が届かない。
問27. 正解：D
業務を日々こなしている担当者の代表を設計レビューとテストに参加させれば、机上では見えない手順の差分が稼働前に表面化し、同時にその代表者が現場への橋渡し役として定着を後押しする。Aの個別の聞き取りのやり直しは工数が膨らむうえ、意見を集約して代弁する役が現場にいないため同じ食い違いが繰り返される。Bの先送りは稼働直後の利用率を落とし、使えない仕組みという評価が固まってから修正することになる。Cの研修だけでは業務手順と画面のずれ自体が残り、入力漏れや台帳を別に持つといった回避運用の温床になる。
3. Agentforce Sales に関する専門知識の実践的な応用
問28. 正解：B
セールスプロセスは商談フェーズの選択リスト値から使う組み合わせを定義するもので、レコードタイプへ割り当てれば部門ごとに表示するフェーズを分けられるため、Bが要件に合う。Aはオブジェクトを分けると同じレポートで合算できなくなり、売上予測も分断される。Cはチェックボックスにするとフェーズの進行として扱われず、パスや売上予測分類に反映されない。Dは入力規則が保存時のエラーにとどまり、直販部門の選択リストには与信審査が並んだままになる。
問29. 正解：A
パスの主要項目は入力してほしい項目を目立たせる案内の仕組みで保存を止める力はなく、フェーズの遷移を条件にした入力規則と組み合わせるAの構成が要件を満たす。Bはパスの主要項目に必須の強制力があるという誤解である。Cは項目定義で必須にすると初期の段階でも入力が求められ、提案前のレコードを作成できなくなる。Dはページレイアウト上の必須設定がフェーズの値では切り替わらず、レイアウトはレコードタイプとプロファイルの組み合わせで割り当てられるためフェーズ単位の制御には使えない。
問30. 正解：B
商談フェーズにはそれぞれ既定の確度が定義されており、フェーズを変更すると確度がその値で更新される一方、項目自体は編集可能でBのとおり手動で上書きできる。上書きした値も次にフェーズを変えた時点で既定値に戻るため、指摘された食い違いは操作の順序が原因である。Aは確度が読み取り専用だという誤りである。Cはフェーズ変更のたびに既定値が再設定される挙動を見落としている。Dは売上予測分類がフェーズに対応付けて設定される別の項目で、確度の算出元ではない。
問31. 正解：A
承認プロセスは複数の承認ステップを持ち、各ステップにそのステップを開始する条件を設定できるため、Aのように2段目だけを高い値引き率のときに実行する設計が要件に合う。Bは複数の承認プロセスを有効にしても、申請時には評価順で最初に条件を満たした1つだけが適用され、ユーザーが選ぶ仕組みにはならない。Cは1つのステップに複数の承認者を置いても段階的な承認にはならず、順序の要件を満たせない。Dは承認そのものを行わない代替案で、判断の記録も残らない。
問32. 正解：B
承認申請を提出者自身が取り消せるかどうかは承認プロセス側の設定で決まり、これを許可していないと承認履歴に取り消しの操作が現れないため、Bの確認が先になる。Aの最終承認時のアクションは承認が完了したあとに実行される設定で、申請中のレコードには関係しない。Cは却下という別の結末になり、申請者自身が取り下げるという要望を満たさないうえ過剰な権限付与になる。Dの「承認プロセスの管理」は設定を作成・変更するための管理権限で、個々の申請を取り消す操作の代わりにはならない。
問33. 正解：D
リードのカスタム項目は既定では引き継がれず、リードの項目の対応付け画面で転記先を明示して初めて取引開始時に値が移るため、Dが正しい対応になる。AはAPI参照名をそろえても対応付けが自動生成されるわけではなく、既存の参照や数式を壊す副作用もある。Bはフローでも実現できなくはないが、標準の設定で足りる要件に自動化を足す過剰な設計で保守対象が増える。Cはページレイアウトが表示の制御にとどまり、レコード間のデータ転記には関与しない。
問34. 正解：A
有効にできる割り当てルールは1つで、その中に条件の異なるルールエントリを順に並べる構造になっており、エントリごとに通知用のメールテンプレートも指定できるためAが要件を満たす。どのエントリにも一致しないリードはデフォルトのリード所有者へ渡るので滞留も防げる。Bは複数の割り当てルールを同時に有効化できないという制約に反する。Cは自動化で所有者を変えても割り当て通知のテンプレートを使えず、設定の見通しも悪くなる。Dは担当者の自主的な取得に依存し、自動で振り分けるという要件から外れる。
問35. 正解：C
入力規則は保存時に条件を評価してエラーを返す仕組みで必須入力の担保に向き、別レコードの更新は保存後のレコードトリガーフローが担うため、Cの役割分担が適切になる。Aの保存前フローはトリガーとなったレコード自身の項目しか更新できず、関連する取引先には手が届かない。Bは入力規則がレコードを書き換える機能を持たない点を見落としている。Dは保存後に削除する構成で、監査上の記録が残らず利用者にも理由が伝わらない。
問36. 正解：D
同じレコードの項目を書き換える処理は保存前のレコードトリガーフローで行うと再度の更新処理が発生せず高速になり、別レコードの作成は保存後のフローでしか実行できないため、Dの組み合わせが正しい。Aは金額の計算まで保存後に置くので追加の更新処理が走り、実行時間の課題が残る。Bは保存前のフローが「レコードを作成」要素を扱えないという制約に反する。Cは数式項目にすると値を手動で調整できなくなり、日次にまとめると成立から納品準備の着手までに遅れが生じる。
問37. 正解：C
画面フローは前の画面で選ばれた値に応じて次に表示する質問を切り替えられ、レコードページのアクションから起動して一連の入力を最後まで導けるためCが要件に合う。Aは全項目を並べる方式で、条件によっては不要な項目まで目に入り迷いが増す。Bは入力規則が保存時にエラーを返すだけで、入力の順序を導く仕組みを持たない。Dはレコードタイプが理由の選択後に切り替わるわけではなく、理由を選ぶ前にレコードタイプを決めさせる不自然な運用になる。
問38. 正解：B
保存後のレコードトリガーフローにはレコードの日付項目を基準にしたスケジュール済みパスを設定でき、Bのように3日前を指定すれば商談ごとに異なる日時で通知を実行できる。Aは毎日全件を取得する方式で、対象が少ない日でも処理量が変わらず無駄が大きい。Cは保存前のフローがスケジュール済みパスに対応していないという制約に反する。Dは数式項目の値が変わっても自動化の実行契機にはならないため、通知そのものが起動しない。
問39. 正解：A
取引先と商談は参照関係だが、取引先は関連する商談の値で積み上げ集計項目を作成できる標準の組み合わせにあたる。積み上げ集計の検索条件で進行中のフェーズだけを対象にできるため、Aが設定だけで実現できる。Cはフローでの作り込みが不要な保守負担を生み、標準機能で足りる場面に自動化を持ち込んでいる。Bは数式項目が子レコードの集合を合計する機能を持たない点を見落としている。Dは商談側に数式を置いても取引先に合計は生まれず、関連リストは個別のレコードを並べるだけで合計の表示にはならない。
問40. 正解：D
同じ目的の活動を2つの仕組みが別々に生み出している状態なので、Dのように初回接触の管理をケイデンスへ寄せてフローを止めるのが根本の解決になり、進捗の集計先も一つに定まる。Aは件名を分けても作業が二重に残り、担当者の迷いと消化漏れは解消しない。Bは対象を取引先責任者に変えると、まだ取引開始していないリードへの初回接触が管理の対象から外れてしまう。Cは重複ルールが取引先・取引先責任者・リードなどのレコードを対象とする機能で、ToDoの生成を抑止する用途には使えない。
問41. 正解：C
フローのエラーメールは既定でフローを最後に変更したユーザーへ送られ、送信先として選べるのはそのユーザーかApex例外メールの受信者の2つである。退職者宛のままでは気付けないため、Cのように現任の管理者をApex例外メールの受信者に登録して切り替え、あわせて障害パスで失敗を記録するのが適切。Aは全要素に障害パスを付ける設計が保守しづらく、送信先を変えないためエラーメールは退職者に届いたままになる。Bは自動化を諦める案で、件数が増えれば運用が破綻する。Dの設定変更履歴は設定の変更を記録する場所で、フローの実行結果は残らない。
4. データ管理
問42. 正解：A
移行のスコープは業務での参照頻度で決め、保管義務だけがあるデータはSalesforceの外に置いて必要時に取り出す設計が、期間と費用の両面で合理的なのでAが適切。Bは入力規則が保存時の値を検証する仕組みで参照そのものを止められず、ストレージも消費し続ける。Cはカスタムオブジェクトへ移してもストレージは組織内で消費され、対応付けと検証の工数はむしろ増える。Dは取り込み後の一括削除がごみ箱と再インデックスの負荷を生み、移行期間の短縮につながらない。
問43. 正解：D
リレーションは子レコードが親のIDを保持する形で成立するため、Dのとおり取引先を先に作り、そのIDを参照する下位のオブジェクトを順に投入する必要がある。Aの件数は依存関係と無関係で、少ない順に並べても親が後回しになれば参照を解決できない。Bは投入時に親レコードが自動生成されるわけではないという前提を取り違えている。Cは子を先に入れると必須の参照項目でエラーになり、後追いの更新も全件分の再処理を招くため速くならない。
問44. 正解：C
外部ID項目を親側に用意しておくと、子レコードの取り込み時にSalesforceのIDを知らなくても参照項目を外部IDの値で指定でき、アップサートによる再実行でも重複を作らないためCが正しい。Aは名前の表記ゆれや同名の取引先で誤った関連付けを生む。Bは外部IDを子側だけに置いても親を特定する手掛かりにならず、手作業が残ったままになる。Dは突き合わせを人手に委ねる方式で、件数が増えるほど破綻し、再実行時の一意性も担保できない。
問45. 正解：B
変更されない一意の番号は外部ID項目として保持するのが定石で、Bのように一意の設定を有効にしておけばアップサートによる再実行でも重複を作らず、双方向の突き合わせにも使えるためBが適切。Aは名前への埋め込みが検索や重複ルール、帳票の表示を乱し、桁ぞろえの運用も破綻しやすい。Cは基幹システム側の改修が前提になるうえ、Salesforce側には相手の番号が残らないため差分確認が片方向にとどまる。Dの行番号は移行ファイルごとに変わる値で、レコードを一意に指す鍵にならない。
問46. 正解：B
データインポートウィザードは一度に取り込めるレコードが5万件までという上限を持つため8万件を扱えず、大量件数はデータローダの担当になる。一方で月次の少量取り込みは重複の検出を備え設定画面から操作できるウィザードが向くので、Bの割り当てが適切。Aは上限を超える件数をウィザードに任せている点で成立しない。Cは業務量に見合わない強い権限を一般ユーザーへ渡すことになり、最小権限の原則に反する。Dは件数の多い側を分割実行に、少ない側を自動化に割り当てており、手間と件数の関係が逆になっている。
問47. 正解：B
行ロックの競合は同じ親を参照する行が別々のまとまりで並列に処理されるときに起きるため、Bのように親のIDで並べ替えて同じ親を一つのまとまりに集約するのが最初の対処になる。Bulk API 2.0は並列処理のみで、逐次処理を選ぶにはBulk APIの逐次モードを使う必要があり、処理時間と引き換えの手段になる。Aは同期のAPIが1回あたりの件数上限で300万件に耐えられず、所要時間も現実的でない。Cは最初から逐次モードにすると並列処理の利点を捨て、短縮という要件に反する。Dは失敗した行が自動では取り込まれず、エラーファイルの確認と再投入が必要になる点を誤っている。
問48. 正解：D
移行元で検証済みのデータに入力規則を再適用しても得るものがなく、保存後のフローも投入のたびに追加の処理を発生させるためDのように一時的に止めるのが定石で、積み上げ集計項目は親子の投入に伴って再計算されるので残してよい。Aは項目を削除すると参照するレポートや数式が壊れ、影響範囲が広がる。Bは処理時間の増加を開始時刻の前倒しだけで吸収できる保証がなく、失敗時の余裕もなくなる。Cはフローを残すため投入ごとの負荷が下がらず、短縮の効果が限定的になる。
問49. 正解：C
監査項目は、設定の［ユーザーインターフェース］で機能が有効になっており、かつ監査項目を設定する権限を持つユーザーがAPI経由でレコードを作成する場合にだけ値を渡せるため、Cが正しい手順になる。Aは標準項目へ値を入れる手段があるのに諦めており、実現可能な要件を切り捨てている。Bは作成時にしか書き込めず、あとからの更新はできないという制約に反する。Dの設定変更履歴は設定の変更を記録する場所で、個々のレコードの作成日を保持する用途には使えない。
問50. 正解：A
リハーサルの目的は手順の正しさに加えて所要時間と失敗の傾向をつかむことにあり、Aのように本番相当の件数を投入して件数や金額の合計を移行元と突き合わせれば、当日の時間配分と検証の観点を同時に確定できる。Bは少件数では処理時間も上限に起因する失敗も再現せず、当日の見積もりに使えない。Cは本番組織を試行の場にする点で危険で、ごみ箱からの復元も保持期間と件数の制約を受ける。Dはファイル形式の点検だけでは参照関係の解決や自動化との相互作用を検出できない。
問51. 正解：D
一括投入の結果は成功と失敗のファイルに分かれて出力されるため、Dのように失敗の理由を特定して入力を直し、成功ファイルに記録されたIDで登録済みのレコードを削除または更新すれば、重複を作らずに整合した状態へ戻せる。Aは同じファイルの再実行が成功済みの行を重複登録する。Bは手作業が件数に耐えられず、失敗の理由が記録から失われて再発も防げない。Cはごみ箱が今回の投入で作られたレコードを保持しておらず、復元という手順自体が成り立たない。
問52. 正解：D
表記の揺れと重複を投入前に直しておかないと、Salesforce側で参照関係ごと誤って結び付いてしまうため、Dのように移行元で整理し、廃止済みの値は新旧の対応表を変換規則として持たせて投入時に置き換えるのが確実になる。Aは重複ルールが取り込み時の検出にとどまり、すでに誤って結び付いた関連レコードまでは直せない。Bは全件の投入を2回行う分だけ期限内の作業時間を圧迫し、1回目のデータを片付ける手間も生じる。Cは並行稼働期間がない前提で、稼働直後から誤ったデータで業務が回ってしまう。
5. 予測 AI と生成 AI
問53. 正解：C
予測AIは蓄積された過去データからパターンを学び、確度やスコアといった数値を出力する。生成AIは学習した内容をもとに文章など新しいコンテンツを作り出すため、Cの対応付けが正しい。Aは大規模言語モデルをAI全般の基盤とみなす誤りで、スコアリングは統計的な予測モデルが担う。Bは2つの用途を入れ替えており、学習データ量の多寡は種別を分ける基準にならない。Dは分類モデルが数値やラベルしか返さない点を見落としており、設定の切り替えで文章生成に転用することはできない。
問54. 正解：B
Sales Cloud EinsteinはPerformance・Unlimited Editionでは標準で利用でき、Enterprise Editionでは有料オプションとして追加購入が必要になる。この組織はEnterpriseのため、Bのとおり追加購入したうえで利用者にアドオンライセンスを割り当てる。AはEnterpriseが対象外だという誤りで、追加購入すれば同じEditionのまま利用できる。Cは全エディションに標準で含まれるとみなす点が誤りである。DはData 360が別製品であり、前提条件には含まれない。
問55. 正解：C
Einstein商談スコアリングは過去24か月で存続期間が2日以上の成立商談と不成立商談がそれぞれ200件以上ないと自社データによるモデルを作れず、その間はCのとおり複数の顧客の匿名データを集約したグローバルモデルでスコアが付く。Aは必要件数の前提を無視している。Bは活動データが特徴量の一部にすぎず、完了商談の件数要件を置き換えられない。Dはデータが不足していてもスコア自体は表示されるという挙動を取り違えており、有効化を遅らせる理由にならない。
問56. 正解：A
Einstein商談スコアリングは1から99の範囲でスコアを付け、Aのとおり商談レコードのほかリストビューやレポート、売上予測の画面でも参照でき、並べ替えや絞り込みにも使える。Bは範囲が誤っているうえ、スコアが売上予測の金額を自動で書き換えるわけでもない。Cは確認できる場所を商談のレコードページだけに限定している点が誤りで、リストビューやレポート、売上予測ページでも参照できる。Dはスコアが項目として保持され定期的に更新される仕組みを取り違えている。
問57. 正解：B
自社の商談データが要件を満たすまでの間は、Bのとおり複数の顧客から集めた匿名データを基にしたグローバルモデルでスコアが算出され、データがそろった時点で自社データによるモデルへ自動的に切り替わる。Aは切り替えが自動で行われる点を取り違えており、申請という手続きは存在しない。Cは他社のレコードそのものを参照するという説明で、匿名化して集約したデータを使う仕組みと異なる。Dはグローバルモデルの利用中もスコアが表示されるという実際の挙動に反する。
問58. 正解：A
Einsteinリードスコアリングの設定ではリード区分ごとに無視する項目を指定でき、Aのとおり指定した項目はモデルの作成時に参照されないため、社内管理用の値を根拠から外せる。Bは項目レベルセキュリティが利用者の参照権限を制御する仕組みで、モデルが使う項目の選定とは別の設定である。Cは管理者が対象項目を調整できるという実際の設定を否定している。Dは区分ごとに項目の一覧を持てる仕様に反する。
問59. 正解：A
Einsteinリードスコアリングは過去200日に作成されたリードが1,000件以上あり、そのうち120件以上が取引先と取引先責任者に変換されていることを前提とするため、変換実績が40件のこの組織ではAのとおり運用の見直しが先になる。Bは作成件数だけを条件とみなす誤りで、変換の件数も要件に含まれる。Cは変換の結果を学習の手掛かりとする仕組みを取り違えている。Dは削除されたリードの実績を再構成する手段がなく、事実に反する。
問60. 正解：C
Einsteinリードスコアリングは一定期間内に作成されたリード件数と、そのうち取引が開始された件数の双方が要件を満たして初めて安定したモデルを作れるため、変換件数の不足はスコアが偏る典型的な原因になる。Aの項目の配置はスコアが画面に見えるかどうかの話にすぎず、算出結果の分布には影響しない。Bの割り当てルールは算出済みのリードをどこへ配るかを決める処理で、スコアの精度とは無関係である。DはスコアがEinsteinによって算出される読み取り専用の項目で、ユーザーが値を書き込むこと自体ができないため確認する意味がない。
この先の演習量を確保するために
ここまでの60問と同じ密度の解説が、全500問すべてに付いた問題集を販売しています。本記事の60問も、この500問の中に含まれています（残りの440問は本記事には入っていません）。
免責事項
- 非公式のオリジナル教材です：本記事の模擬問題・解説はすべて当研究所が独自に作成したものであり、実際の試験問題の複製・転載・流用ではありません。Salesforce, Inc.が提供・監修・承認したものではなく、同社と提携・協賛等の関係もありません。Salesforce、Trailhead等の名称・ロゴはSalesforce, Inc.の商標または登録商標です。
- 公式情報との相違の可能性：実際の試験の出題内容・出題形式・出題比率・難易度・合格ライン・受験料等は、Salesforce社の判断により予告なく変更されることがあります。当研究所は適宜、内容の点検を行っていますが、本記事が常に最新の公式試験ガイドと完全に一致することを保証するものではありません。受験前に必ず公式試験ガイド（Trailhead／Salesforce公式サイト）で最新情報をご確認ください。
- 対応バージョンについて：本記事の問題は作成時点の公式情報を参照しており、公式試験ガイド（日本語版）に明記された対応バージョンと差異がある場合があります。
- 合格・成果の保証はありません：本記事は学習の補助を目的としたものであり、内容を利用したことによる資格試験の合格・特定のスコア取得その他の成果を保証するものではありません。
- 正確性についての留意：内容の正確性については作成時点および見直し時点で可能な限りの確認を行っていますが、誤字脱字・解説内容の誤り等が皆無であることを保証するものではありません。お気づきの点はコメント欄にてお知らせください。確認のうえ無料で修正します。
- 損害についての免責：本記事の内容を利用したことにより生じたいかなる損害（学習時間の損失、受験結果に関するものを含みますがこれに限りません）についても、当研究所は責任を負いかねます。あらかじめご了承のうえご利用ください。
- 著作権・利用範囲：本記事の全文の著作権は当研究所に帰属します。読者ご本人が学習目的でご利用いただく範囲を超えて、内容の複製・転載・再配布・第三者への共有・譲渡・転売等を行うことは禁止します。