Administrator 練習問題 Q239

解説

前提知識

Salesforce Knowledge（ナレッジ）とは

よくある質問、手順書、既知の不具合と回避策などを「記事」として蓄積し、検索して再利用できるようにする機能です。サポート担当者が同じ調査を何度も繰り返さなくて済むようにするのが目的です。 ケースとナレッジは連携するように設計されており、ケースのレコードページ上で関連する記事を提示したり、記事をケースに添付して顧客に送ったりできます。

データカテゴリとは

記事を分類するための階層構造のラベルです。管理者が「製品」「地域」「サポートレベル」といったカテゴリグループを作り、その下に階層を作ります。1つの記事に複数のカテゴリを付けられます。 データカテゴリの役割は2つあります。公式ヘルプも次のように整理しています。

1. ナレッジベースの内容を整理する（探しやすくする）
2. ナレッジベースへのアクセスを制御する（誰にどの記事を見せるか）

提案記事（Suggested Articles）とは

ケースの件名や管理者が選んだケース項目から検索語を作り、Salesforceが関連しそうな記事を提示する機能です。現行の公式説明では、まず類似ケースに紐づく記事を探し、結果が十分でなければ記事を直接検索します。データカテゴリの対応付けは、この検索で返された記事候補をケース項目に対応するカテゴリで絞り込む設定です。項目値と記事が必ず1対1で返る仕組みではありません。

設問の状況を分解する

1. サポートエージェントは、ケースを解決するための情報を探すのに時間を使っている
2. 探したいものは「ドキュメント」と「類似ケース」の両方
3. 探す場所はケースのページレイアウト上、つまり作業中の画面から離れずに探したい
4. 求められているのは「より効率的な方法」＝仕組みで解決すること ポイントは、これが個人の頑張りではなく、情報の置き場所と出し方の設計の問題だという点です。担当者に「もっと上手に検索して」と伝えても解決しません。「探しに行く」から「向こうから出てくる」に変えるのが正解の方向です。 初学者が誤解しやすいのは、「類似ケースを探したい」と書いてあるので、ケースそのものを検索する仕組みを作らなければならない、と考えてしまう点です。実際には、繰り返し発生する問い合わせの解決手順をナレッジ記事として蓄積すれば、「類似ケースを探す」という行為そのものが不要になります。これがナレッジ管理の考え方です。

---

選択肢の検討

A. 一般的なケースの解決策をキャプチャするカスタムオブジェクトを作成します。 → ✕（惜しいが不正解）

発想は正しい方向です。しかし、Salesforceには同じ目的の標準機能（ナレッジ）が最初から用意されています。カスタムオブジェクトで作ると、記事のバージョン管理、公開・非公開の状態管理、データカテゴリによる分類とアクセス制御、ケースへの添付、提案記事の表示といった機能をすべて自前で作ることになります。 Salesforceの試験では、標準機能で足りるならカスタム開発はしないが一貫した判断基準です。カスタムオブジェクトが正解になるのは、標準オブジェクトでは表現できない独自のデータ構造が必要な場合だけです。

B. インタビューフローを使用してケースの詳細をキャプチャします。 → ✕

画面フローで質問に答えさせ、ケースの情報を整理して入力させる仕組みです。これは情報を入れる側の改善であって、既存の情報を探す側の改善ではありません。設問は「リソースを見つけるのに時間がかかる」と言っているので、方向が逆です。 これが正解になるのは、「エージェントによってケースの入力内容がバラバラで、切り分けに必要な情報が埋まっていない」という設問です。

C. ユーザーをグローバル検索に誘導して同様のケースを探します。 → ✕

グローバル検索でもケースや記事を探せますが、担当者が検索語を考えて結果を選別する必要があります。設問が求める「ケースページから、ドキュメントや類似ケースに基づく解決情報を効率的に見つける」仕組みにはなりません。Knowledge の提案記事や記事検索をケース作業画面に組み込む方が、要件に直接対応します。

D. 記事とデータカテゴリを使用してナレッジを構成します。 → ⭕ 正解

解決手順を記事として蓄積し、データカテゴリで分類することで、次の3つが同時に実現します。

• 同じ問い合わせの解決手順が再利用できる（類似ケースを探す必要が減る）
• ケース項目とデータカテゴリを対応付けることで、検索された記事候補を関連カテゴリで絞り込める
• 記事をケースに添付して、そのまま顧客に共有できる 「ドキュメントを探したい」「類似ケースを探したい」という両方の要求を、1つの標準機能で満たせます。

---

管理者としての対処手順

1. ［設定］→ クイック検索に「ナレッジ設定」と入力し、Lightning Knowledge を有効化する
2. ユーザーにナレッジのライセンスと権限（記事の参照・作成・公開など）を割り当てる
3. ［データカテゴリ設定］でカテゴリグループを作成し、階層を定義する（例：製品 → シューズ → ランニング）
4. 記事レコードタイプとページレイアウトを整え、記事を作成してデータカテゴリを付与し、公開する
5. ［ナレッジ設定］で［ケースで関連記事を提案する］を有効にし、［提案記事の検索に使用するケース項目］を指定する
6. ケースのLightningレコードページに［ナレッジ］コンポーネント、または［ナレッジ］関連リストを配置する
7. データカテゴリのマッピングを設定し、ケースの項目値とデータカテゴリを対応づけて提示精度を上げる

やりたいこと	使う設定
記事を分類して探しやすくする	データカテゴリ
記事を見せる相手を制限する	データカテゴリの表示設定（カテゴリグループの表示）
ケース画面に関連記事を出す	ナレッジコンポーネント／関連リスト＋提案記事
提案の精度を上げる	データカテゴリのマッピング

---

あわせて覚えておきたいポイント

• データカテゴリは「分類」と「アクセス制御」の二役を持ちます。試験では、記事の公開範囲を絞りたい場面でもデータカテゴリが正解になります。
• 提案記事は、選択した項目とデータカテゴリが1対1で対応するわけではありません。公式も「選択したケース項目から導いた検索語で複数回の検索を行うアルゴリズム」と説明しており、選択リスト項目のように検索対象になりにくい項目を指定すると期待した記事が出ないことがあります。
• ケースコンソールで使う「ナレッジコンポーネント」と、レコードページに置く「ナレッジ関連リスト」は別物です。設問が「コンソールを使わない部門」に触れている場合は、レコードページ側の設定が答えになります。

---

出典（Salesforce公式）

• Work with Data Categories — 「Salesforce Knowledge はデータカテゴリを使用して記事を分類し、見つけやすくする」（本問の決定的根拠）
• Salesforce Knowledge Data Categories Best Practices — 「データカテゴリはシステム管理者が制御する記事の階層的な分類であり、ナレッジベースの整理と、ナレッジベースへのアクセス制御の2つの目的で使われる」
• Filter Articles with Data Category Mapping — 「ケースを解決するときに提案記事をより関連性の高いものにする。ケース項目をデータカテゴリにマッピングして、そのデータカテゴリが割り当てられた記事に絞り込む」
• Salesforce Knowledge Setting ‘Suggest Related Articles on Cases’ Not Returning Expected Results — 提案記事は選択したケース項目から生成した検索語で複数回検索するアルゴリズムであり、1対1のマッピングではないこと
• Plan Your Knowledge Base in Lightning Experience — ナレッジベースの設計時に検討する項目（同義語グループなど検索体験の最適化を含む）

Salesforce公式ドキュメント↗