第1回 問題集（全般）

正解: A. A. ケース（インシデント）

正解の根拠・詳細解説

ケース（テーブル論理名 incident）は Customer Service の中核テーブルであり、顧客からの問い合わせ・苦情・障害報告を1件単位で記録し、起票から解決・クローズまでのライフサイクル全体を追跡するために使用される。ケースには顧客（取引先企業または取引先担当者）、件名、優先度、発生源、状態・状態理由が保持され、SLA・エンタイトルメント・キュー・ナレッジ記事・アクティビティといった Customer Service の主要機能はすべてケースを起点として連動する。リード・商談・注文は Sales アプリの販売プロセス（見込み客の獲得から受注まで）を扱うテーブルであり、サポート対応の記録には用いない。実務では「取引先担当者を顧客に設定したケース」と「取引先企業を顧客に設定したケース」で SLA やルーティングの条件式が変わるため、顧客列が両方のテーブルを参照する多態的な参照であることを理解しておくことが重要である。

正解: A. A. ビジネスルールまたは列の必須レベル設定

正解の根拠・詳細解説

入力必須化には2つの層がある。①列（フィールド）の必須レベル：テーブルの列定義で「ビジネス必須」に設定すると、その列が配置されたすべてのフォームで常に入力必須となる、②ビジネスルール：条件を評価して「列にビジネス必須を設定」アクションを実行することで、たとえば「発生源が電話のときだけ電話番号を必須にする」といった条件付き必須化を、コードを書かずに実現できる。ビジネスルールはスコープを「エンティティ」にするとサーバー側でも評価されるため、API・インポート経由の書き込みにも適用できる点が実務上の分岐点となる。ダッシュボードのウィジェット配置・レポートのスケジュール・テーマ設定はいずれも表示や配信の設定であり、保存時のデータ検証には一切関与しない。

正解: A. A. ビジネスルールやPower Automateクラウドフロー

正解の根拠・詳細解説

レコードの作成・更新を契機とした自動処理は、ビジネスルールと Power Automate クラウドフローで実装する。①ビジネスルール：フォーム上またはサーバー側で、列値の自動設定・表示非表示・必須切り替え・エラーメッセージ表示を宣言的に定義でき、単一レコード内で完結する整合性チェックに向く、②Power Automate クラウドフロー：Dataverse コネクタの「行が追加、変更、削除されたとき」トリガーを使い、他レコードの参照・更新、承認依頼、Teams やメールへの通知、外部システム連携など、レコードをまたぐ処理や外部連携を担う。使い分けの目安は、同一レコード内の単純な条件判定ならビジネスルール、複数レコードや外部サービスが絡むならクラウドフローである。Excel テンプレートや印刷プレビューは出力用の機能であり、データ更新時の自動処理には使えない。

正解: A. A. 重複検出ルール

正解の根拠・詳細解説

重複検出ルールは、対象テーブルと比較条件（完全一致・先頭 n 文字一致など）を列単位で定義し、レコードの作成・更新時、およびデータインポート時に既存レコードと突き合わせて重複候補を提示する仕組みである。ルールは作成後に「発行」しなければ有効にならず、公開済みルールを変更する場合は一度発行を取り消す必要がある点が実務での典型的な落とし穴である。また重複検出を実際に働かせるには、システム設定側で「レコードの作成または更新時に重複検出を有効にする」がオンになっている必要があり、ルールを作っただけでは警告が出ない。タイムラインコントロールは履歴表示、ナレッジ記事テンプレートは記事の雛形、キャパシティプロファイルは Unified Routing の割り当て容量の定義であり、いずれも重複判定とは無関係である。

正解: A. A. ケースのステージとビジネスプロセスフロー

正解の根拠・詳細解説

ビジネスプロセスフロー（BPF）は、ケースの起票から解決までを「ステージ」と各ステージの「ステップ（データステップ）」に分解し、画面上部のプロセスバーとして担当者に次に何をすべきかを提示する仕組みである。ステップを必須に設定すると、その列が埋まるまで次のステージへ進めないため、対応品質の標準化と手順の抜け漏れ防止に直結する。標準の Customer Service には Phone to Case プロセスが用意されており、これを複製・編集して自社の対応手順に合わせるのが一般的な実装アプローチである。なお BPF のステージはケースの状態（state）・状態理由（status reason）とは別の概念であり、両者を混同しないことが重要である。ステージ進行に合わせて状態理由を更新したい場合は、BPF と Power Automate やビジネスルールを併用する。

正解: A. A. ワークフローまたはPower Automateの条件分岐

正解の根拠・詳細解説

属性に応じた自動分類と処理分岐は、クラシックワークフローまたは Power Automate クラウドフローの条件分岐（条件・切り替えアクション）で実装する。Dataverse トリガーでケースの作成・更新を捕捉し、件名・製品・顧客の区分・発生源といった列値を条件に評価して、カテゴリ列や優先度の更新、担当キューへのルーティング、通知の送信といった後続アクションへ分岐させる。実務上は、更新トリガーで「変更対象の列」を絞り込んでおかないと、フロー自身の更新が再びトリガーを引いて無限ループになるため、フィルター列の指定が重要な設計ポイントとなる。より高度な分類が必要な場合は、Unified Routing の分類ルールや機械学習ベースのルーティングを検討する。印刷テンプレート・テーマ設定・レポートのエクスポートはいずれも表示や出力に関する設定で、自動処理の分岐には使えない。

正解: A. A. ケースの解決ダイアログ

正解の根拠・詳細解説

ケースのコマンドバーから「ケースの解決」を実行すると、標準の「ケースの解決」ダイアログが表示され、解決の種類・請求対象時間（所要時間）・解決内容のメモを入力してから確定する。この操作は単にケースを閉じるのではなく、裏側で「ケースの解決（incident resolution）」というアクティビティレコードを作成し、入力内容をそのレコードに保存したうえでケースの状態を「解決済み」に変更する。この構造を理解しておくと、解決理由の集計レポートを作る際に、ケースではなくケース解決アクティビティを対象にすればよいことが分かる。なお、エンタイトルメントが関連付けられている場合は、解決時に入力した請求対象時間が残存条件（時間ベースの場合）から差し引かれるため、時間の入力精度がそのまま契約消化量の精度に直結する。

正解: A. A. ケース解決エンティティのフォームをカスタマイズし追加列を構成する

正解の根拠・詳細解説

解決時の入力項目を増やすには、ケース本体ではなく「ケースの解決（incident resolution）」テーブルに列を追加し、そのテーブルのフォームをカスタマイズする。既定のダイアログは非推奨化が進んでおり、現在は Customer Service 管理センターでケース設定の解決ダイアログとしてカスタマイズ可能なフォームを指定する構成が推奨されている。これにより、根本原因の分類・再発防止策・顧客満足度の初期評価といった自社固有の項目を、解決操作の流れの中で入力させることができる。Power BI はデータの可視化のみを担い、入力を強制する手段にはならない。電子メールテンプレートは送信文面、セキュリティロールの削除はアクセス制御の話であり、いずれも解決時の入力項目とは無関係である。追加した列は必須レベルやビジネスルールと組み合わせることで、入力漏れを防止できる。

正解: A. A. 承認フローやビジネスプロセスフローの承認ステージを構成する

正解の根拠・詳細解説

クローズ前の上長承認は、Power Automate の承認アクション（開始して承認を待機）を用いたクラウドフロー、またはビジネスプロセスフローに承認用ステージを設けることで実装する。前者は Teams やメール上で承認・却下を受け取り、その結果に応じてケースの状態を更新するため、承認の記録と監査証跡が残る点が利点である。後者はプロセスバー上で承認ステップを可視化し、必須ステップとして未完了のまま先へ進めないよう制御できる。実務では両者を併用し、BPF で手順を示しつつ、実際の承認判定と状態更新はクラウドフローに任せる構成がよく採られる。加えて、承認前に担当者が手動でケースを閉じられないよう、セキュリティロールでケースの書き込み権限を調整するか、リアルタイムワークフローや Power Fx による検証を組み合わせて多層で担保する。

正解: A. A. セキュリティロールの権限設定

正解の根拠・詳細解説

アクセス制限はセキュリティロールで行う。ケースの解決操作は「ケースの解決（incident resolution）」アクティビティの作成と、ケース本体の書き込み権限に依存するため、これらのテーブルに対する特権（作成・読み取り・書き込み・追加・追加先）とアクセスレベル（ユーザー・ビジネスユニット・親子ビジネスユニット・組織）を調整することで、特定のチームのみが解決できるよう制御する。ダッシュボードを非表示にしたり、フォームから解決ボタンを消したりする方法は UI 上の見た目を変えるだけで、API や高度な検索経由での操作は防げないため、セキュリティ境界としては成立しない点に注意が必要である。実務では、UI 側でコマンドの表示条件を制御して誤操作を減らしつつ、実質的な強制はセキュリティロールで行うという二段構えが定石である。

正解: A. A. セキュリティロール

正解の根拠・詳細解説

セキュリティロールは Dataverse のロールベースアクセス制御の中核であり、テーブル単位で「特権（作成・読み取り・書き込み・削除・追加・追加先・割り当て・共有）」を定義し、それぞれに「アクセスレベル」を組み合わせて権限を表現する。アクセスレベルは狭い順に、なし・ユーザー（自分が所有するレコードのみ）・ビジネスユニット（自分の所属 BU）・親子ビジネスユニット（自 BU と配下の BU）・組織（全社）の段階があり、この2軸の掛け合わせによって「営業担当は自分のケースだけ編集でき、マネージャーは部門全体を閲覧できる」といった要件を表現する。ロールはユーザーまたはチームに割り当てられ、テーブル権限に加えてアプリやカスタムコネクタなどへのアクセスも制御する。ダッシュボードテーマ・BPF のステージ・キャパシティプロファイルは、いずれもアクセス制御の仕組みではない。

正解: A. A. セキュリティロールのアクセスレベルを「ビジネスユニット」に設定する

正解の根拠・詳細解説

自部門のレコードのみを参照させるには、セキュリティロールのケーステーブルの読み取り特権を「ビジネスユニット」レベルに設定する。Dataverse では各ユーザーが必ず1つのビジネスユニットに所属し、レコードには所有者を通じて所属 BU が紐づくため、BU レベルの特権は「自分と同じ BU に属するユーザーが所有するレコード」に可視範囲を限定する。全ユーザーに管理者ロールを付与するのは組織レベルの権限を全員に与えることであり、要件と正反対である。フィールドレベルセキュリティは特定の列の値を隠す機能で、レコード自体の可視性は制御できないため単独では要件を満たさない。実務上の注意点として、部門横断で個別に共有したいケースが出てくる場合は、BU レベルを維持したままレコードの共有やアクセスチームを用いるのが定石であり、権限レベルを組織に引き上げてしまうと制御が崩れる。

正解: A. A. フィールドレベルセキュリティ

正解の根拠・詳細解説

フィールドレベルセキュリティ（列レベルセキュリティ）は、レコードそのものへのアクセス権とは独立して、特定の列の値の読み取り・更新・作成を制御する仕組みである。手順は、①対象列の「列のセキュリティを有効にする」をオンにする、②列セキュリティプロファイルを作成し、その列に対する読み取り・更新・作成の可否を設定する、③プロファイルにユーザーまたはチームを割り当てる、の3段階である。プロファイルを割り当てられていないユーザーには、レコードを開けても該当列の値がマスク表示（******）される。注意点として、セキュリティロールでレコードを閲覧できることと、その列の値が見えることは別問題であり、両者を組み合わせて設計する必要がある。ビジネスプロセスフロー・重複検出ルール・キャパシティプロファイルはいずれもデータ保護の機能ではない。

正解: A. A. ユーザーに再ログイン（キャッシュ更新）してもらう

正解の根拠・詳細解説

セキュリティロールの割り当てや権限定義の変更は Dataverse 側では即座に反映されるが、クライアント側にはユーザーの権限情報がセッションキャッシュとして保持されているため、ログイン中のユーザーの画面にはすぐに反映されないことがある。そのためユーザーにサインアウトして再度サインインしてもらうか、ブラウザーを閉じて開き直してもらうのが確実な対処となる。サーバーの再起動はクラウドサービスである Dynamics 365 では管理者が実施できる操作ではなく、そもそも不要である。ライセンスの再購入は権限とは別の課金・割り当ての話であり、権限の反映とは無関係である。実務では、権限変更のテストを行う際に「反映されない」という問い合わせの大半がこのキャッシュ起因であるため、切り分けの第一歩として再サインインを案内するとよい。

正解: A. A. 最も広い権限が累積的に適用される

正解の根拠・詳細解説

Dataverse のセキュリティモデルは加算的（累積的）であり、複数のセキュリティロールが割り当てられた場合、各ロールが持つ特権の和集合が有効になる。すなわち、あるロールが読み取りをユーザーレベルでしか許可していなくても、別のロールが組織レベルの読み取りを許可していれば、そのユーザーは組織全体を読み取れる。この性質から、権限を絞りたい場合に「制限の強いロールを追加で割り当てる」という発想は誤りであり、広い権限を与えているロールの割り当て自体を外さなければ制限は効かない。チームに割り当てられたロールもユーザーに継承されるため、トラブルシューティング時はユーザー直付けのロールとチーム経由のロールの両方を確認する必要がある。なお、列レベルセキュリティは例外的に別レイヤーで働くため、この累積の原則とは分けて考える。

正解: A. A. タイムラインコントロール

正解の根拠・詳細解説

タイムラインコントロールは、ケースや取引先担当者などのレコードに関連するメモ・投稿・メール・電話・タスク・予定といったアクティビティを、発生日時の新しい順に一覧表示する UI コンポーネントである。担当者はこれを見るだけで、いつ誰が顧客とどのようなやり取りをしたかという対応の全経緯を把握でき、引き継ぎや二次対応の際の状況理解を大幅に短縮できる。内部的にはアクティビティテーブル群とメモ（annotation）テーブルを横断して表示しているため、表示可否は各アクティビティテーブルのセキュリティロール権限に従う。キャパシティプロファイルは Unified Routing の割り当て容量、ダッシュボードウィジェットは集計表示、ワークストリームはルーティングの入口の定義であり、いずれも履歴表示のコントロールではない。

正解: A. A. フォームエディターでタイムラインコントロールのプロパティを構成する

正解の根拠・詳細解説

タイムラインの表示内容は、フォームエディターでタイムラインコントロールを選択し、そのプロパティで構成する。レコードの種類（メモ・メール・電話・タスク・予定・投稿など）ごとに表示のオン・オフを切り替えられるほか、既定のフィルター、並び順、各レコードで使うカードフォーム、表示件数などを指定できる。これにより、たとえばサポート担当者向けフォームではメールと電話のみを既定表示にし、ノイズとなる予定は非表示にするといった役割別の最適化ができる。注意点として、この設定は表示の絞り込みにすぎず、非表示にしたアクティビティも高度な検索や関連グリッドからは参照できるため、機密性の担保にはならない。レポートのフィルターやテーマ設定、ダッシュボードの共有設定は、いずれもタイムラインの表示内容には影響しない。

正解: A. A. 関連レコードの主要情報を一目で把握できるようにするため

正解の根拠・詳細解説

カードフォームは、タイムラインやサブグリッド、関連レコードの一覧で1レコードを小さなカード状に表示するための専用フォーム種別であり、上位・下位・本文といった限られた領域に配置した列だけを表示する。これにより担当者は、レコードを個別に開いて画面遷移することなく、件名・優先度・状態・担当者といった判断に必要な主要情報を一覧上で把握でき、対応の初動を早められる。実務では、タイムラインコントロールのプロパティでアクティビティの種類ごとに使用するカードフォームを指定できるため、メールでは差出人と件名、電話では通話の方向と要旨といったように、種類別に見せる情報を最適化するのが定石である。データのバックアップ・セキュリティロール管理・重複検出ルールはいずれも別領域の機能であり、表示の最適化とは関係がない。

正解: A. A. タイムラインの強調表示（ハイライト）ルール

正解の根拠・詳細解説

タイムラインコントロールでは、レコードの内容に応じた強調表示（ハイライト）の設定が可能で、重要度の高い項目を視覚的に区別して埋没を防げる。これは大量のアクティビティが蓄積したケースで特に有効であり、担当者が長い履歴をスクロールする中でも、注意すべきやり取りを短時間で発見できるようにする狙いがある。あわせて、タイムラインには検索とフィルターの機能が備わっており、レコードの種類・アクティビティの状態・作成者・期間などで絞り込めるため、強調表示と組み合わせることで目的の履歴に素早く到達できる。ビジネスプロセスフローの削除・セキュリティロールの再割り当て・重複検出ルールの無効化は、いずれもタイムラインの表示とは無関係な操作であり、むしろ運用に悪影響を与える。

正解: A. A. インラインでのアクティビティ作成機能

正解の根拠・詳細解説

タイムラインコントロールは履歴の閲覧だけでなく、その場でのアクティビティ作成（インライン作成）に対応している。担当者は「+」から、または直接入力欄にメモを書き込むことで、画面遷移せずにメモ・メール・電話・タスクなどを追加でき、対応中に別画面へ移動して文脈を失うことがない。これはケース対応のスループットに直結する設計で、通話しながらのメモ取りや、確認メールの即時送信といった実務の流れに沿っている。作成可能なアクティビティの種類は、フォームエディターのタイムラインプロパティで表示設定を有効にしている種類、かつユーザーのセキュリティロールで該当テーブルの作成権限がある種類に限られるため、「担当者にメールの作成ボタンが出ない」という問い合わせでは、この2点を順に確認するのが定石である。

正解: A. A. ナレッジマネジメント（ナレッジ記事）

正解の根拠・詳細解説

ナレッジマネジメントは、過去の解決策・手順書・FAQ をナレッジ記事として蓄積し、ケース対応中の担当者が検索・参照して即座に回答を提示できるようにする Customer Service の中核機能である。記事は下書き・承認済み・公開済み・期限切れといった状態を持つライフサイクルで管理され、レビューと承認を経て公開することで内容の品質を担保する。担当者はケースフォームのナレッジ検索ペインから記事を検索し、ケースに関連付けたり、リンクを顧客へのメールに挿入したりできる。関連付けの記録は記事の閲覧数や利用状況として蓄積されるため、どの記事が実際に問題解決に寄与しているかを分析し、記事の改善に還元できる。商談の予測・営業目標・製品カタログは Sales 側の機能であり、サポートのナレッジ活用とは関係がない。

正解: A. A. 内部のナレッジ検索機能（AIによる関連記事の提案を含む）

正解の根拠・詳細解説

Customer Service のナレッジ検索は、担当者がキーワードを入力して記事を探せるだけでなく、ケースの件名や説明などの内容を手がかりに関連度の高い記事を自動的に提示するサジェスト機能を備えている。これにより担当者は検索語を考える手間を省き、対応の初動を短縮できる。検索対象・表示件数・使用するフィルターは、Customer Service 管理センターのナレッジ設定やフォーム上のナレッジ検索コントロールのプロパティで構成する。実務での注意点として、提案の精度は記事のタイトル・キーワード・説明の書き方に大きく左右されるため、記事作成時に検索されやすい語彙を意識的に含めることが運用上の重要な施策となる。重複検出ルール・フィールドレベルセキュリティ・ワークストリームの優先度は、いずれも記事の検索や提案には関与しない。

正解: A. A. ナレッジ記事のテーブルとカテゴリテーブル

正解の根拠・詳細解説

ナレッジ記事はナレッジ記事テーブル（knowledgearticle）に格納され、カテゴリテーブル（category）と関連付けることで階層的に分類・整理する。カテゴリは親子構造を取れるため、「製品 > シリーズ > 機能」といった多階層の分類体系を構築でき、記事の絞り込み検索やナレッジベースの見通しの改善につながる。加えて、記事にはキーワード・説明・言語といったメタデータを設定でき、これらが検索精度とサジェストの品質を左右する。実務では分類体系を作り込みすぎると記事登録時の負荷が上がり運用が形骸化するため、階層は浅く保ち、細かい絞り込みはキーワードと全文検索に委ねる設計が現実的である。ワークストリーム・キャパシティプロファイルは Unified Routing、SLA 項目は SLA の構成要素であり、いずれも記事の分類には用いない。

正解: A. A. 翻訳されたナレッジ記事の管理機能

正解の根拠・詳細解説

Dynamics 365 Customer Service のナレッジマネジメントは多言語に対応しており、元の記事に対して言語ごとの翻訳版を関連付けて管理できる。翻訳版は元記事と紐づいた別レコードとして保持されるため、それぞれ独立して編集・レビュー・公開ができ、言語ごとに公開タイミングをずらすことも可能である。担当者や顧客は自身の言語設定に応じた版が提示されるため、多国展開する組織でも単一のナレッジベースで運用できる。実務上の注意点として、原文記事を更新した際に翻訳版が自動で同期されるわけではないため、原文の改訂を翻訳版へ反映する運用プロセスを別途定義しておかないと、言語間で内容が乖離していく。重複検出ルール・タイムラインのハイライト・キャパシティプロファイルは、いずれも多言語記事の管理とは無関係である。

正解: A. A. 外部ナレッジソースの統合（フェデレーション検索）を構成する

正解の根拠・詳細解説

組織のナレッジは Dynamics 365 の中だけに存在するとは限らず、SharePoint や外部のサポートサイトなどに散在していることが多い。フェデレーション検索（外部ナレッジソースの統合）を構成すると、担当者はケース画面のナレッジ検索から一度の操作で内部記事と外部ソースの双方を横断的に検索でき、複数のシステムを行き来する手間がなくなる。管理者は Customer Service 管理センターで検索プロバイダーを追加し、接続情報と対象範囲を設定する。実務上の要点は、外部ソースの検索結果に対するアクセス権は外部システム側の権限に従うため、Dynamics 365 側のセキュリティロールだけでは可視範囲を制御しきれない点であり、統合前に権限設計の整合を確認しておく必要がある。ビジネスプロセスフローやセキュリティロールの削除、ダッシュボードの非表示は要件と無関係である。

正解: A. A. AIの提案とCopilot主導のナレッジ記事作成機能

正解の根拠・詳細解説

Copilot によるナレッジ記事作成支援では、解決済みのケースの内容やそこに紐づく会話・メールの履歴を解析し、問題の症状・原因・解決手順を整理したナレッジ記事のドラフトを自動生成する。従来はナレッジ化の作業負荷が高く、対応知見が個人に滞留して記事が増えないという課題が一般的だったが、この機能は担当者の初稿作成の負担を大きく下げ、ナレッジベースの充実を継続させる狙いがある。重要な運用上の前提として、生成されるのはあくまで下書きであり、公開前に人がレビューして事実確認と表現の調整を行うワークフローを組み込むことが必須である。生成物をそのまま公開する運用は、誤情報の拡散と顧客への誤案内につながる。重複検出ルール・セキュリティロール・タイムラインの強調表示は、記事の生成とは無関係な機能である。

正解: A. A. Microsoft Teamsチャットの構成

正解の根拠・詳細解説

Teams チャットの埋め込み統合を構成すると、担当者はケースなどのレコードを開いたまま、画面横のチャットペインから関連部署のメンバーや有識者に相談できる。会話はレコードに接続されるため、後から同じレコードを開いた別の担当者も相談の経緯を追え、エスカレーション時の文脈引き継ぎが容易になる。管理者は Customer Service 管理センターで Teams との埋め込みチャットを有効化し、どのテーブルで利用可能にするか、チャットにレコードのコンテキストを含めるかといった設定を行う。実務では、社内相談の内容が顧客に見えるものではない点を担当者へ周知することと、Teams 側のライセンスと組織のポリシーが前提として整っているかを事前確認しておくことが重要である。重複検出ルール・列レベルセキュリティ・SLA 項目は、いずれも社内コラボレーションの手段ではない。

正解: A. A. 特定のユーザーの「Teams通話に参加」の構成

正解の根拠・詳細解説

Teams 通話への参加を構成すると、担当者はケースなどのレコード画面から、対象ユーザーへの Teams 通話をその場で開始できるようになる。チャットでは解決に時間がかかる込み入った事象について、画面を離れずに即座に音声での相談へ切り替えられるため、エスカレーションの待ち時間を短縮できる。この機能はレコードのコンテキストを保ったままコラボレーションするという Teams 統合全体の設計思想の一部であり、埋め込みチャット・連絡先の提案とあわせて構成することで効果が高まる。前提として、対象ユーザーが Teams を利用できるライセンスとポリシーを持っていること、および組織で Teams 統合が有効化されていることが必要である。重複検出ルール・SLA 設定・キャパシティプロファイルは、いずれも通話機能とは無関係である。

正解: A. A. Microsoft Teamsでの連絡先候補の構成

正解の根拠・詳細解説

Teams 統合の連絡先候補（提案された連絡先）機能では、ケースの内容や関連レコードをもとに、相談すべき相手の候補を担当者に提示する。提案にはルールベースの要素（ケースの所有者、顧客の担当営業、直近で同種のケースを解決した担当者など、レコードの関係から導ける相手）と、AI ベースの要素（過去の類似ケースの対応履歴からの推定）があり、これらを組み合わせて構成できる。これにより、組織が大きく誰が有識者か分かりにくい環境でも、担当者は適切な相談先へ短時間で到達できる。実務では、提案の質は関連レコードの整備状況に依存するため、顧客の担当者や製品との関連付けを日頃から正しく登録しておくことが前提となる。重複検出ルール・列レベルセキュリティ・SLA 項目は、この目的には使えない。

正解: A. A. Teamsのコラボレーションエクスペリエンスの構成

正解の根拠・詳細解説

Teams のコラボレーションエクスペリエンスを構成すると、Teams のチャットやチャネルに Dynamics 365 のレコードをタブやパネルとして表示でき、Teams 側にいるメンバーもケースの詳細を確認しながら議論できる。これにより、サポート担当者と Teams 中心に働く他部門のメンバーとの間で、情報の転記や画面共有に頼らない共通の作業文脈が生まれる。管理者側では Teams 統合の有効化に加え、どのアプリ・テーブルを連携対象にするかを構成する。重要な前提として、Teams 上で表示されるレコードの閲覧可否は Dataverse のセキュリティロールに従うため、Teams のチャネルに参加しているだけでは権限のないレコードは見えない。ビジネスプロセスフローの削除・セキュリティロールの全削除・重複検出ルールの無効化は、いずれも連携の構成手段ではなく、実行すれば運用を破壊する操作である。

正解: A. A. コンテンツのフィルター処理を含む質問の構成

正解の根拠・詳細解説

Copilot が担当者に提示する回答や提案は、参照するコンテンツの範囲とフィルター条件を管理者が構成できる。ナレッジソースの指定に加え、記事の状態・言語・カテゴリといった条件でフィルターを設定することで、公開済みかつ対象言語の記事だけを参照させる、社内限定情報を顧客向け回答の生成対象から外す、といった制御が可能になる。これは Copilot の出力品質と情報統制の両方に直結する設定であり、実務では「古い記事や下書きが回答の根拠に使われてしまう」という事故を防ぐための必須の作り込みとなる。あわせて、Copilot の参照範囲は担当者のセキュリティ権限にも従うため、フィルター設定と権限設計を整合させておく必要がある。キャパシティプロファイル・重複検出ルールは、いずれも Copilot の出力制御とは関係のない機能である。

正解: A. A. ケース、タイムライン、会話の要約機能

正解の根拠・詳細解説

Copilot の要約機能は、ケースのフィールド情報、タイムラインに蓄積されたメール・メモ・電話などのアクティビティ、そしてオムニチャネルの会話記録を横断して解析し、これまでの経緯・顧客の要望・実施済みの対応・未解決の論点を短い要約として提示する。これにより、担当者は長大な履歴を読み込むことなく状況を把握でき、特にエスカレーションやシフト交代でケースを引き継ぐ場面で立ち上がりの時間を大幅に短縮できる。会話の要約は、チャネル間で転送する際に次の担当者へ文脈を渡す用途でも機能する。実務上の留意点として、要約はあくまで支援情報であり、解決の判断や顧客への回答は担当者が原文を確認したうえで行うべきである。重複検出ルール・BPF の承認ステージ・列レベルセキュリティは、要約とは無関係な機能である。

正解: A. A. 下書きの応答（ドラフト回答）の構成

正解の根拠・詳細解説

Copilot の下書き応答（ドラフト回答）機能は、ケースの内容・これまでの会話履歴・構成済みのナレッジソースを根拠に、顧客への返信文のドラフトを自動生成する。担当者は生成された文面をそのまま送るのではなく、内容の正確性と顧客に合わせた表現を確認・編集したうえで送信するのが正しい使い方であり、この人によるレビュー工程が品質担保の要である。参照するナレッジソースとフィルター条件は管理者が構成するため、公開済み記事のみを根拠にするといった制御が可能である。実務では、回答の品質が低いという相談の多くは Copilot 側ではなくナレッジ記事の内容や整備状況に起因するため、まず参照元のナレッジを見直すのが定石である。重複検出ルール・セキュリティロール・ワークストリームの優先度は、文面生成とは無関係である。

正解: A. A. ケース管理エージェントの構成

正解の根拠・詳細解説

ケース管理エージェントは、あらかじめ定義した条件に基づいてケースの処理を自律的に進める AI エージェントであり、Copilot Studio を用いて構成する。定型的で判断の幅が狭い問い合わせについて、内容の分類、適切なキューや担当への振り分け、ナレッジに基づく一次回答の提示、必要な情報の顧客への確認といった処理を人手を介さずに実行し、担当者は判断を要するケースに集中できるようになる。設計上の要点は、エージェントが扱う範囲と、人間へエスカレーションする条件（信頼度が低い場合、顧客が人間の担当者を求めた場合など）を明確に定義しておくことであり、これを曖昧にすると顧客体験を損なう。タイムラインの強調表示・列レベルセキュリティ・重複検出ルールは、いずれも自律的な処理を行う仕組みではない。

正解: A. A. プラグインやナレッジソースとのエージェント統合の構成

正解の根拠・詳細解説

Copilot Studio でエージェントを構成する際は、参照するナレッジソース（Dynamics 365 内のナレッジ記事に加え、SharePoint や公開 Web サイトなど）と、外部の処理を呼び出すためのプラグイン・アクションを追加することで、エージェントが扱える情報と実行できる操作の範囲を拡張できる。これにより、社内記事だけでは答えられない質問に外部の情報源で応答したり、基幹システムへの照会といった実処理を伴う対応まで自動化したりできる。実務上の要点は、追加するソースごとにアクセス権と情報の鮮度・正確性を確認することであり、統制の取れていないソースを追加すると誤った回答の根拠になりかねない。あわせて、どのソースを根拠に回答したかを追跡できるようにしておくと、品質改善のサイクルを回しやすい。重複検出ルールや BPF・セキュリティロールの削除は、この目的とは無関係である。

正解: A. A. サービスレベルアグリーメント（SLA）

正解の根拠・詳細解説

SLA（サービスレベルアグリーメント）は、顧客との契約や社内基準で定めた対応時間の約束を Dynamics 365 上で自動的に計測・管理する仕組みである。SLA はケースの条件（優先度、顧客区分、製品など）ごとに適用され、初回応答や解決の期限を自動計算し、期限が近づいた時点での警告と、期限超過時の失敗としての記録を行う。期限の計算には営業時間（勤務時間レコードの休日・稼働時間帯）を反映できるため、24時間換算ではなく実際の営業日ベースで正しく判定できる点が重要である。また、ケースが保留状態のときに計時を一時停止する設定も可能で、顧客からの回答待ちの時間を自社の責任時間に含めない運用が実現できる。ダッシュボードテーマ・重複検出ルール・タイムラインの強調表示は、期限の管理には一切関与しない。

正解: A. A. SLA項目（KPI）

正解の根拠・詳細解説

SLA 項目（SLA KPI）は、SLA の中で計測する個々の指標を定義する単位であり、初回応答時間や解決時間といった KPI ごとに、適用条件・計測の開始と終了の判定・目標時間・営業時間の適用有無を設定する。1つの SLA に複数の SLA 項目を含められるため、たとえば「初回応答は1時間以内、解決は8時間以内」といった複合的な約束を1つの SLA として表現できる。各項目には後述の警告アクション・成功アクション・失敗アクションを紐づけ、期限に応じた自動処理を実行させる。実務での典型的な設計ミスは、適用条件を優先度で分けずに単一の目標時間を全ケースに適用してしまうことで、緊急案件と通常案件を同じ基準で測ると SLA の統計が実態を反映しなくなる。ワークストリーム・キャパシティプロファイル・重複検出ルールは SLA の構成要素ではない。

正解: A. A. Power Automateを使用したアクションの実装

正解の根拠・詳細解説

SLA 項目には、期限が近づいたときに実行される警告アクションと、達成時・未達成時に実行される成功・失敗アクションを設定でき、これらのアクションの実体を Power Automate のクラウドフローとして実装する。フローの中で担当者やマネージャーへのメール送信、Teams への通知、フォローアップタスクの作成、ケースの優先度やエスカレーション先の更新といった処理を自由に組み立てられるため、単に期限を記録するだけでなく、超過を未然に防ぐ運用へつなげられる。実務では、警告のタイミングを目標時間ぎりぎりに設定すると担当者が動く余地がないため、対応に必要な時間を逆算して余裕を持たせるのが定石である。印刷テンプレート・ダッシュボードの共有設定・重複検出ルールの無効化は、いずれも通知やタスク作成の手段にはならない。

正解: A. A. SLAを有効化し、該当する条件のケースに自動的に適用されるよう構成する

正解の根拠・詳細解説

SLA は作成しただけでは機能せず、有効化（アクティブ化）して初めてケースへ適用される。適用の方式は2通りあり、①既定の SLA として設定する：条件に合致するケースに自動的に適用される、②ケースの SLA 列で明示的に指定する、またはエンタイトルメント経由で適用する、という形である。エンタイトルメントに SLA を関連付けた場合は、そのエンタイトルメントが適用されたケースに対して該当 SLA が優先して適用されるため、契約ごとに異なる応答基準を表現できる。実務上の注意点として、有効化済みの SLA は直接編集できず、変更するには一度無効化するかレコードを複製して新しい版を作る必要があるため、本番稼働中の SLA 変更は適用中のケースへの影響を確認したうえで計画的に行う。ダッシュボードの削除やテーマ変更は SLA とは無関係である。

正解: A. A. 成功アクションと失敗（警告）アクション

正解の根拠・詳細解説

SLA 項目では、期限に対する状況ごとに異なる自動処理を定義できる。①警告アクション：目標時間に達する前の指定タイミングで実行され、担当者への注意喚起やマネージャーへの事前通知に用いる、②成功アクション：目標時間内に完了条件が満たされたときに実行され、達成の記録や関連レコードの更新に用いる、③失敗アクション：目標時間を過ぎても条件が満たされなかったときに実行され、エスカレーション、優先度の引き上げ、上位者への通知などに用いる。これらのアクションは Power Automate のフローとして実装するため、処理内容は業務要件に応じて自由に設計できる。実務では、失敗アクションだけを作り込み警告アクションを省略する構成をよく見かけるが、それでは超過してからしか動けないため、予防的な警告の設計こそが SLA 運用の要となる。

正解: A. A. SLAの適用性（適用条件）

正解の根拠・詳細解説

SLA の「適用性（適用条件）」は、そのSLA をどのケースに適用するかを決める条件式であり、優先度・顧客の区分・製品・発生源といったケースの列値を組み合わせて定義する。これにより、プレミアム契約の顧客には短い応答目標、一般顧客には標準の目標、というように、同一組織内で複数の SLA を条件に応じて使い分けられる。実務上の重要な設計原則は、複数の SLA が同時に該当しないよう条件を排他的に組むことであり、条件が重なると意図しない SLA が適用されて計測結果がぶれる。契約単位で異なる基準を持たせたい場合は、SLA をエンタイトルメントに関連付ける方式のほうが管理しやすく、適用性条件は組織全体の一般ルールを表現する用途に向く。重複検出ルール・タイムラインコントロール・セキュリティロールは、いずれも適用範囲の絞り込みには使えない。

正解: A. A. フォーム上のタイマーコントロール

正解の根拠・詳細解説

タイマーコントロールは、フォーム上に配置して指定した日時列までの残り時間をカウントダウン表示する UI コントロールであり、SLA の期限列と組み合わせることで、担当者に「あと何分で初回応答の期限を迎えるか」を常時可視化できる。期限を過ぎると経過時間の表示に切り替わるため、超過の事実も一目で分かる。設定では、基準となる日時列に加え、計測を停止・中断する条件となる列と値（たとえばケースが解決済みや保留になったら停止する）を指定できるため、実態に即した表示が可能である。実務では、SLA の警告アクションによる通知と、このタイマーによる視覚的な可視化を併用することで、担当者が期限を意識して優先順位を判断できるようになる。ダッシュボードウィジェットは集計向けであり、個々のケース画面での残り時間表示には適さない。

正解: A. A. SLA KPI（主要業績評価指標）

正解の根拠・詳細解説

SLA の運用結果は、SLA KPI インスタンスとしてケースごと・KPI ごとに記録される。このレコードには、適用された SLA 項目、期限日時、実際の完了日時、状態（進行中・達成・失敗・一時停止など）が保持されるため、これを集計することで KPI 別・期間別・チーム別の達成率を算出し、レポートやダッシュボードで可視化できる。分析対象がケースそのものではなく SLA KPI インスタンスである点が重要で、1件のケースに複数の KPI（初回応答と解決）が紐づくため、ケース単位で集計すると達成率が正しく出ない。実務では、この達成率の推移を見ながら SLA の目標時間が現実的かを見直し、必要に応じて人員配置やルーティングの調整につなげるという改善サイクルを回す。ワークストリームや BPF のステージは、SLA の実績データとは無関係である。

正解: A. A. キャパシティプロファイル

正解の根拠・詳細解説

キャパシティプロファイルは Unified Routing における担当者の作業容量の定義であり、担当者が同時に扱える作業項目の数や、作業種別ごとの消費量を単位ベースで管理する。ルーティングエンジンは割り当て時に各担当者の残容量を評価し、容量を超える割り当てを行わないため、特定の担当者に作業が集中して品質が落ちる事態を防げる。プロファイルは担当者に割り当て、ワークストリームの作業分類ごとに消費する容量を設定するため、「チャットは1件で1単位、ケースは1件で3単位」といった負荷の重み付けが表現できる。実務では、単純な件数上限だけで設計すると重い案件と軽い案件が同一視されるため、実際の対応工数に応じた重み付けを行うことが精度の鍵となる。重複検出ルール・ナレッジ記事カテゴリ・タイムラインコントロールは、負荷管理の機能ではない。

正解: A. A. ワークストリーム

正解の根拠・詳細解説

ワークストリームは Unified Routing における作業の流れの定義単位であり、どのチャネルや作業種別（ライブチャット、メール、音声、ケースなどのレコード）から入ってきた項目を、どのようなルールで分類し、どのキューへ振り分け、どう担当者に割り当てるかを一括して構成する。ワークストリームには、作業の分類ルール、ルーティングルール、割り当て方法（最も空いている担当者・ラウンドロビンなど）、既定のキュー、作業の配分モード（プッシュ配信かピックアップか）といった設定が含まれる。実務上の要点は、ワークストリームが「ルーティングの設計単位」であり、チャネルやサポート対象の業務区分ごとに分けて作ることで、それぞれ異なる割り当てポリシーを適用できる点である。SLA 項目・ナレッジ記事カテゴリ・タイムラインのハイライトは、ルーティングの単位ではない。

正解: A. A. ユーザー設定（プレゼンス・チャネル容量の構成）

正解の根拠・詳細解説

Unified Routing では、担当者ごとのユーザー設定で、対応可能なチャネル（チャット・メール・音声など）とそれぞれの同時対応上限、およびスキル、キューへの所属、プレゼンス（応対可能・取り込み中・退席中など）を構成する。ルーティングエンジンはこれらの情報を評価して割り当て先を決めるため、この設定の精度がそのまま割り当ての妥当性を左右する。プレゼンスは担当者自身の操作や、現在の作業負荷に基づく自動遷移で変化し、応対不可の状態にある担当者には新規の作業が割り当てられない。実務での典型的な問題は、担当者にスキルやキャパシティが未設定のまま運用を始め、割り当てが偏る、あるいは誰にも割り当たらないという事象であり、稼働前に全担当者の設定を棚卸ししておくことが重要である。SLA 項目や重複検出ルールは割り当てには関与しない。

正解: A. A. スキルベースのルーティングとスキルファインダーモデル

正解の根拠・詳細解説

スキルベースのルーティングでは、担当者にスキル（製品知識、言語、資格など）とその習熟レベルを登録し、作業項目側にも分類ルールで必要なスキルを付与したうえで、両者を照合して条件を満たす担当者へ割り当てる。照合の方式は「完全一致」と「近い一致」を選択でき、完全一致では要求スキルをすべて満たす担当者のみが候補になる。この照合ロジックがスキルファインダーであり、スキル条件で候補を絞ったうえで、キャパシティやプレゼンスによる評価、さらに割り当て方法の評価を経て最終的な担当者が決まるという多段の流れになっている。実務での注意点は、完全一致を厳しく設定しすぎると条件を満たす担当者が不在で作業が滞留することであり、フォールバックとして近い一致や既定キューへの退避を設計しておく必要がある。

正解: A. A. 基本的なルーティングルールセット

正解の根拠・詳細解説

基本的なルーティングルールセット（クラシックのルーティングルールセット）は、ケースなどのレコードに対して条件を順に評価し、最初に合致したルール項目に従って所有者・キュー・チームへ振り分ける、最も基礎的なルーティングの仕組みである。ルール項目は上から順に評価されるため、条件の並び順が結果を左右する点が設計上の要点となる。Unified Routing のスキルベースルーティングやキャパシティを考慮した高度な割り当てと比べると、担当者の負荷や保有スキル、プレゼンスといった動的な状況は考慮されず、静的な条件分岐のみを扱う。したがって、単純な部門振り分けだけで足りる場合はこちらで十分だが、チャネル横断でリアルタイムに最適な担当者を選びたい場合は Unified Routing を採用するのが適切である。キャパシティプロファイル・SLA KPI は振り分けルール自体ではない。

正解: A. A. キュー

正解の根拠・詳細解説

キューは、未処理のケース・アクティビティ・メールなどを部署やチーム、業務区分ごとに集約する受け皿であり、レコードはキュー アイテムとしてキューに保持される。担当者はキューの一覧から自分で作業を選んで取得（ピック）するか、ルーティングによって自動で割り当てられるかのいずれかで作業を受け取る。キューには、レコードを取得中であることを示す「作業中」の概念があり、複数人が同じ案件に同時着手する重複対応を防ぐ仕組みになっている。キューにはプライベートキュー（メンバーのみが参照可能）とパブリックキューがあり、この区別によって業務範囲外のキューが担当者に見えないよう整理できる。実務では、キューの粒度が細かすぎると滞留の監視が煩雑になるため、監視できる単位で設計することが重要である。

正解: A. A. レコードのルーティング

正解の根拠・詳細解説

レコードのルーティングは、あらかじめ定義した条件やルールに基づいて、ケースをはじめとするレコードを適切なキュー・チーム・担当者へ自動的に割り当てる仕組みの総称である。実装としては、クラシックのルーティングルールセットによる静的な条件振り分けと、Unified Routing による高度な割り当て（分類ルールによる属性付与、スキル照合、キャパシティとプレゼンスの評価、割り当て方法の適用）の2系統がある。いずれの方式でも、手作業の振り分けを排して初動を早め、担当者の適合度に応じた割り当てによって解決率と対応品質を高めることが目的である。実務では、ルーティングの条件が業務区分の実態と乖離すると誤配が増えるため、キューやチームの設計とルーティング条件をセットで見直すことが重要となる。列レベルセキュリティやナレッジ記事の翻訳管理は、割り当てとは無関係の機能である。

正解: A. A. スラグ（クイック返信用のショートコード）

正解の根拠・詳細解説

スラグは、担当者が短いショートコードを入力するだけで定型文を呼び出せるようにする生産性機能であり、クイック返信やメールテンプレートの中で使われる。単に固定の文字列を挿入するだけでなく、スラグにはケースの番号や顧客名、担当者名といったレコードやユーザーのデータを動的に差し込むためのプレースホルダーとしての役割があり、送信時に実際の値へ置き換えられる。これにより、定型的でありながら個別の文脈に合った文面を短時間で作成でき、応対時間の短縮と表現の統一の両方が得られる。実務では、クイック返信をチーム共有で整備し、よく使う回答をスラグ付きでテンプレート化しておくと、新任担当者の立ち上がりが早くなる。重複検出ルール・SLA 項目・キャパシティプロファイルは、いずれも文面入力を支援する機能ではない。

正解: A. A. マクロ

正解の根拠・詳細解説

マクロは、複数の操作手順を1つのまとまりとして定義し、担当者がワンクリックで一連の処理を実行できるようにする生産性機能である。ケースのレコードを作成する、特定のフィールドを更新する、アプリケーションタブを開く、ナレッジ検索を実行するといったステップを順に構成でき、対応中の反復作業を大幅に短縮できる。マクロは単独で使うほか、エージェントスクリプト（担当者に手順を提示するステップのリスト）のステップとして組み込むことで、「この手順ではこのマクロを実行する」という形で対応の標準化と自動化を同時に実現できる。実務での要点は、マクロが担当者の代わりに実行する処理であるため、権限のない操作は失敗する点であり、対象テーブルへの権限を含めて動作確認をしておく必要がある。ワークストリームや SLA KPI は操作の自動実行の仕組みではない。

正解: A. A. Copilot Service workspace

正解の根拠・詳細解説

Copilot Service workspace（従来の Customer Service workspace の後継にあたる作業領域）は、担当者がマルチセッションで複数のケースや会話を並行処理しながら、Copilot による要約・回答の提案・下書き応答・ナレッジ検索といった AI 支援を同一画面で利用できる統合的な作業環境である。画面は、セッション一覧、対応中のレコードを開くアプリケーションタブ、そして Copilot や生産性ツールを表示する生産性ペインという構成を取り、担当者は文脈を失わずに作業を切り替えられる。この作業領域の構成は、セッションテンプレート・アプリケーションタブテンプレート・通知テンプレート・エクスペリエンスプロファイルによって管理者が定義する。ダッシュボードテーマ・セキュリティロール・重複検出ルールは、いずれも作業領域そのものを指す用語ではない。

正解: A. A. セッションテンプレート

正解の根拠・詳細解説

セッションテンプレートは、マルチセッション環境で新しいセッションが開始されたときに、どのレコードやページをアンカータブ（そのセッションの主対象を表す固定タブ）として開き、どのアプリケーションタブを併せて開くかを定義するテンプレートである。これにより、担当者がケースを開くたびに毎回同じ関連情報（顧客の詳細、過去のケース履歴、ナレッジ検索など）が自動的に配置され、手作業でタブを開く操作が不要になる。セッションテンプレートは、開く対象のタブをアプリケーションタブテンプレートとして参照する構造になっており、両者を組み合わせて画面構成を設計する。実務では、担当業務ごとに必要な情報が異なるため、エクスペリエンスプロファイルを通じてロール別に異なるセッションテンプレートを割り当てるのが定石である。SLA 項目や重複検出ルールは画面構成の定義には関与しない。

正解: A. A. エクスペリエンスプロファイル

正解の根拠・詳細解説

エクスペリエンスプロファイル（エージェント エクスペリエンス プロファイル）は、担当者の役割ごとに作業環境の構成をまとめて定義し、ユーザーやチームに割り当てる仕組みである。プロファイルには、利用可能なチャネル、セッションテンプレート、通知テンプレート、生産性ペインに表示するツール（ナレッジ検索、エージェントスクリプト、スマートアシスト、Copilot など）が含まれ、これを切り替えるだけで役割別に最適化された画面を提供できる。たとえば一次受付の担当者にはナレッジ検索とスクリプトを中心に、シニア担当者にはより多くのチャネルと分析ツールを、といった差別化が可能である。実務での要点は、プロファイルはセキュリティロールとは別の仕組みであり、画面に何が出るかは制御できてもデータへのアクセス権は制御しない点で、両者を組み合わせて設計する必要がある。

正解: A. A. 受信トレイ（カスタムビューを含む）

正解の根拠・詳細解説

受信トレイは、担当者が対応すべき会話・ケース・アクティビティなどの作業項目を一箇所にリアルタイムで集約して表示する画面領域であり、複数のチャネルやレコード種別にまたがる作業を横断的に把握できる。担当者は受信トレイから項目を選択するだけでセッションを開始でき、どこから手を付けるべきかの判断と着手の操作が一続きになる。表示内容はカスタムビューとして構成でき、未対応のみ、期限が迫っているもの、特定のキューのものといった条件で絞り込んだ独自のビューを用意して切り替えられる。受信トレイの有効化と利用可能なビューは、エクスペリエンスプロファイル側で構成する。SLA 項目・ナレッジ記事カテゴリ・重複検出ルールは、いずれも作業項目の一覧表示を担う機能ではない。

正解: A. A. アプリケーションタブテンプレート

正解の根拠・詳細解説

アプリケーションタブテンプレートは、セッション内で開くタブ1つ分の定義（何のページを、どのパラメーターで開き、どのようなタブ名で表示するか）をテンプレート化する仕組みである。エンティティのレコードやビュー、ダッシュボード、Web リソース、外部の URL などをタブの対象として指定でき、作成したテンプレートはセッションテンプレートから参照される。この分離により、「顧客詳細タブ」「過去ケース一覧タブ」といった部品を一度作れば複数のセッションテンプレートで再利用でき、画面構成の変更も一箇所の修正で全体へ反映できる。実務では、担当者が対応中によく手動で開くページを洗い出してテンプレート化することが、応対時間の短縮に直結する典型的な改善施策となる。SLA KPI・ワークストリーム・重複検出ルールは、画面タブの定義とは無関係である。

正解: A. A. Dynamics 365 Customer Voice

正解の根拠・詳細解説

Dynamics 365 Customer Voice は、アンケート（調査）を作成・配布し、回答結果を Dataverse に蓄積して分析するためのアプリであり、Customer Service と組み合わせることで、ケース解決後の顧客満足度調査や NPS の収集を実現する。調査プロジェクト単位でアンケートを管理し、メールや埋め込みリンクによる配布、回答状況のリアルタイム集計、しきい値を下回る回答に対するアラートといった機能を備える。回答はケースや取引先担当者と関連付けて記録できるため、どの対応がどのような評価につながったかを追跡できる。Power BI はデータの可視化ツールであり、アンケートの作成・配布自体は行わない。Sales Insights は Sales 向けの AI 分析機能であり、顧客の声の収集を担うものではない。

正解: A. A. アンケートの配布トリガー

正解の根拠・詳細解説

ケース解決を契機とした自動配信は、Customer Voice のアンケート配布を Power Automate のクラウドフローと組み合わせて構成する。Dataverse のトリガーでケースが解決済みになったことを検知し、Customer Voice のコネクタで対象の調査を該当顧客のメールアドレス宛に送信するという流れであり、フロー内で顧客名やケース番号といった変数をアンケートに渡すことで、回答をケースへ紐づけて記録できる。実務での要点は、送信対象の条件を絞ることであり、すべての解決ケースに無条件で送るとアンケート疲れを招いて回答率が下がるため、一定期間内の重複送信を抑止する条件や、対象とするケース種別の絞り込みを設計に入れておくべきである。SLA KPI・重複検出ルール・タイムラインのハイライトは、いずれも配信のトリガーにはならない。

正解: A. A. 調査の個人設定（パーソナライズ）

正解の根拠・詳細解説

Customer Voice の調査では、回答者ごとに内容を最適化するパーソナライズが可能である。①変数（パーソナライズ変数）：顧客名・ケース番号・担当者名などを送信時に差し込み、設問文や導入文へ反映する、②多言語対応：調査に複数の言語を追加し、回答者の言語に応じた版を表示する、③分岐（スキップロジック）：直前の回答内容に応じて後続の設問を出し分け、関係のない設問を省略する、という3つの手段を組み合わせる。これにより回答者の負担が減り、回答率と回答の質が向上する。実務では、Power Automate から調査を送る際にこれらの変数へ値を渡す構成にしておくことで、ケースの文脈に沿ったアンケートを自動送信できる。SLA 項目・重複検出ルール・キャパシティプロファイルは、アンケートの表示内容には関与しない。

正解: A. A. サポート案件と会話に基づくアンケート結果の事前設定

正解の根拠・詳細解説

Customer Voice のアンケートは、送信時に外部から値を渡して回答項目や表示内容をあらかじめ設定しておくことができる。Power Automate のフローからアンケートを配信する際に、対象のケース番号・製品・対応チャネル・担当者名といった情報を変数として引き渡すことで、顧客が自分で入力しなくてもよい項目を埋めた状態で提示でき、回答の手間を減らして回答率を高められる。同時に、この引き渡した値は回答レコードに保持されるため、回答結果をケースや会話と紐づけて分析でき、どの案件のどの対応に対する評価かを後から特定できる。実務では、この紐づけを設計せずにアンケートだけを送ってしまうと、低評価が出ても原因となった案件を特定できず改善につながらないため、配信フローの設計段階で関連付けを組み込むことが重要である。

正解: A. A. ナレッジ記事の状態（有効期限・公開状態）の管理

正解の根拠・詳細解説

ナレッジ記事は状態（下書き・承認済み・公開済み・期限切れなど）を持つライフサイクルで管理され、公開日と有効期限を設定できる。有効期限を過ぎた記事は期限切れの状態へ移り、公開済みの記事を対象とする検索やサジェストの結果には表示されなくなるため、古い手順が誤って顧客に案内される事故を防げる。担当者から「記事が見つからない」という問い合わせを受けた場合は、記事が削除されたのではなく期限切れや下書きに戻っている可能性をまず確認するのが定石である。実務上の要点は、有効期限の設定を運用ルールとして定着させることであり、期限管理をしないまま記事が蓄積すると、内容の鮮度が担保されずナレッジベース全体の信頼性が下がる。重複検出ルール・SLA 項目・タイムラインコントロールは、記事の可視性とは無関係である。

正解: A. A. 製品やケースの種類ごとに異なるSLA項目とSLAを作成し適用性で振り分ける

正解の根拠・詳細解説

製品ラインごとに異なる応答基準を実現するには、目標時間の異なる SLA 項目を用意し、それらを含む複数の SLA を作成したうえで、適用性の条件（製品、ケースの種類、顧客区分など）で振り分ける。単一の SLA を全製品で使い回すと、要求水準の異なる製品を同じ基準で測ることになり、達成率の統計が実態を反映せず、改善の判断材料にならない。ビジネスプロセスフローは手順の可視化と進行制御を担うが、時間を計測して期限超過を検知する機能は持たないため、SLA の代替にはならない。ダッシュボードは結果の可視化にすぎず、基準の定義や計測は行わない。実務では、契約ごとに基準が異なる場合は SLA をエンタイトルメントに関連付ける方式が管理しやすく、適用性条件は組織共通のルールを表現する用途に使い分けるとよい。

正解: A. A. ナレッジ記事の承認ワークフロー（状態遷移の管理）

正解の根拠・詳細解説

ナレッジ記事は下書き・承認済み・公開済み・期限切れといった状態を遷移しながら管理され、この状態遷移に承認の工程を組み込むことで、公開前のレビューを必須化できる。承認プロセスは、記事の作成者がレビュー依頼を出し、指定されたレビュー担当者が内容の正確性と表現を確認したうえで承認し、承認後に公開へ進むという流れになり、Power Automate の承認アクションを組み合わせて通知と記録を自動化するのが一般的である。実務での要点は、レビュー担当者に対して記事の承認に必要な権限を付与しておくことと、レビューが滞留してナレッジの公開が遅れないよう期限やエスカレーションを設計しておくことである。重複検出ルール・タイムラインコントロール・列レベルセキュリティは、いずれも記事の品質管理プロセスを構成する機能ではない。

正解: A. A. ケースの種類（カテゴリ）列を構成し、ビジネスプロセスフローやルーティングルールで分岐させる

正解の根拠・詳細解説

ケースの分類は、まずケーステーブル上の「ケースの種類」や件名といった選択肢列で表現します。値を持たせておけば、その値を条件にして後続の処理を分岐できるからです。分岐先としては、ルーティングルールやユニファイドルーティングのワークストリームで種類ごとに異なるキューへ割り当てる、ビジネスプロセスフローを種類ごとに用意して担当者が進めるステージを変える、といった構成が代表的です。さらに、自動レコード作成ルールで受信メールから種類を判定してケースを起票したり、種類に応じて異なるSLAや解決期限を適用したりすることもできます。すべてを単一のフォームだけで管理すると、この分岐の起点となる構造化された値が存在しないため、種類ごとの自動化が成立しません。設計時は、後から分類を追加できるよう選択肢の値と対応するルールの管理方針を決めておくと運用が安定します。

正解: A. A. ワークストリーム

正解の根拠・詳細解説

ワークストリームは Unified Routing における作業取り込みとルーティングの起点であり、ライブチャット、メール、音声、SNS などのチャネル、およびケースなどのレコードから入ってくる作業項目を統一的に扱う単位である。ワークストリームには、作業項目に属性を付与する分類ルール、振り分け先を決めるルーティングルール、割り当て方法、既定のキュー、作業の配分モードといった設定が集約されており、チャネルが異なっても同一の枠組みで割り当てを制御できる点が特徴である。これにより、チャネルごとにバラバラの仕組みを持つのではなく、担当者の容量とスキルを横断的に評価した一貫した配分が可能になる。SLA KPI は時間の計測、ナレッジ記事カテゴリは記事の分類、タイムラインのハイライトは表示の強調であり、いずれもルーティングの起点ではない。

正解: A. A. 対象チャネルの種類（メール・チャット等）とルーティング先キュー

正解の根拠・詳細解説

ワークストリームを新規作成する際は、まず基本情報として、扱う作業の種類とチャネル（ライブチャット、メール、音声、レコードなど）、作業の配分モード（担当者へ自動的に配信するプッシュか、担当者が自ら取得するピックアップか）、既定のフォールバックキュー、そして割り当て方法を指定する。チャネルの選択はその後に設定できるルーティングの選択肢を規定するため、最初に決めるべき重要項目である。作成後は、作業項目に属性を付与する分類ルールと、振り分け先を決めるルーティングルールを追加して振り分けロジックを組み立てる。実務での注意点は、どのルールにも合致しなかった作業項目の行き先となる既定キューを必ず用意しておくことであり、これを省くと条件漏れの案件が誰にも届かず滞留する。印刷テンプレートやテーマは無関係である。

正解: A. A. ユーザー設定（プレゼンスとチャネルキャパシティ）

正解の根拠・詳細解説

ユーザー設定では、担当者ごとにプレゼンス（応対可能・取り込み中・退席中・応対不可など）と、チャネル別の同時対応可能数を構成する。チャットのようにリアルタイム性が高く同時並行が可能なチャネルと、メールのように1件あたりの処理が重いチャネルでは適切な同時件数が異なるため、チャネル単位で上限を分けて設定できることが実運用上の要点となる。ルーティングエンジンは割り当て時にプレゼンスと現在の割り当て状況を評価し、上限に達している担当者や応対不可の担当者には新規の作業を配分しない。より柔軟な重み付けが必要な場合は、キャパシティプロファイルを併用して作業種別ごとの消費単位を定義する。SLA 項目・重複検出ルール・ナレッジ記事カテゴリは、いずれも同時対応数の制御には関与しない。

正解: A. A. キャパシティプロファイルを複数作成し、担当者グループごとに割り当てる

正解の根拠・詳細解説

作業負荷の管理は、全担当者に一律の上限を課すのではなく、役割・経験レベル・担当業務の性質ごとにキャパシティプロファイルを分けて作成し、それぞれのグループに適した上限を割り当てるのが基本設計である。新任担当者には少ない同時件数を設定して品質と教育に配慮し、熟練担当者にはより高い上限を設定するといった運用ができ、結果として全体のスループットと品質のバランスが取れる。全員に無制限のプロファイルを割り当てると、割り当ての抑制が働かず特定の担当者に作業が集中し、対応遅延と品質低下を招くため要件と正反対である。SLA は期限の計測を行うものであり、割り当て量の制御はしない。重複検出ルールはデータ品質の機能で負荷制御とは無関係である。プロファイルは運用開始後も実績を見て上限を調整していくことが重要である。

正解: A. A. 作業の分類と割り当て（ルーティングルールの構成）

正解の根拠・詳細解説

作業の分類と割り当ての構成とは、Unified Routing において、入ってきた作業項目に対して分類ルールで属性（優先度、必要スキル、対象キューの判断材料となる区分など）を付与し、続くルーティングルールで条件を評価して振り分け先のキューやチームを決定する一連の設計作業を指す。分類とルーティングを分けている点が重要で、分類段階で作業項目に必要な情報を付けておくことで、後続のルールやスキル照合が精度良く働く。振り分け後は、キャパシティ・プレゼンス・スキルを評価して個々の担当者への割り当てが行われるという多段構成になっている。実務では、ルールの条件が業務区分の実態と乖離すると誤配が増えるため、キュー設計とルール条件をセットで見直すことが重要である。ナレッジ記事の翻訳管理・列レベルセキュリティ・SLA KPI は振り分けの構成要素ではない。

正解: A. A. 基本的なルーティングルールセット

正解の根拠・詳細解説

基本的なルーティングルールセットは、条件と振り分け先を組にしたルール項目を並べ、上から順に評価して最初に合致した項目の指定先（キュー・チーム・ユーザー）へレコードを割り当てる、単純な IF-THEN 形式の仕組みである。条件は優先度・製品・顧客区分といったレコードの列値で表現するため、静的で分かりやすく、構成の手間も小さい。一方で、担当者の現在の負荷・保有スキル・応対可否といった動的な状況は一切考慮しないため、リアルタイムに最適な担当者を選びたい場合には不十分である。そうした要件にはスキルベースルーティングを含む Unified Routing が適する。キャパシティプロファイルは容量の定義、SLA 適用性条件はどの SLA を適用するかの条件であり、いずれもレコードの振り分け先を決める仕組みではない。ルール項目の並び順が結果を左右する点が設計上の注意点である。

正解: A. A. スキルベースのルーティング（スキルファインダーモデル）

正解の根拠・詳細解説

スキルベースのルーティングは、担当者に登録したスキル（言語、製品知識、資格など）と習熟度を、作業項目側に付与された必要スキルと照合し、条件を満たす担当者だけを割り当て候補に絞り込む仕組みである。この照合を担うのがスキルファインダーで、照合の厳しさは「完全一致」と「近い一致」から選択でき、完全一致では必要スキルをすべて満たす担当者のみが候補となる。スキルで絞った候補に対して、さらにキャパシティとプレゼンスによる評価、割り当て方法による最終選定が行われるため、単純な条件振り分けよりも解決率と一次解決率の向上が期待できる。基本的なルーティングルールセットは静的な条件のみを扱い、スキルの照合機能は持たない。実務では、条件を厳しくしすぎて候補者が不在にならないよう、フォールバックの設計が必須である。

正解: A. A. 担当者ごとのスキルと習熟度

正解の根拠・詳細解説

スキルベースルーティングを機能させる前提は、スキルのマスターを整備したうえで、各担当者にどのスキルをどの習熟度で保有しているかを登録しておくことである。この登録がなければ、作業項目に必要スキルが付与されても照合できる候補が存在せず、割り当てが行われないまま滞留する。あわせて、作業項目側に必要スキルを付与する分類ルールも構成する必要があり、担当者側と作業項目側の両方が揃って初めてマッチングが成立するという対称性を理解しておくことが重要である。給与情報・勤務地・趣味といった情報は、ルーティングの判断材料としてシステムが評価する対象ではない。実務での注意点として、スキル体系を細かく作りすぎると登録と維持の負荷が高くなり実態と乖離するため、割り当てに実際に影響する粒度に絞って設計するのが現実的である。

正解: A. A. キュー

正解の根拠・詳細解説

キューは、未処理のケースやアクティビティをチーム・部門・業務区分ごとに集約する受け皿であり、レコードはキュー アイテムとして保持される。担当者はキューの一覧から自分で作業を取得することも、ルーティングによって自動的に割り当てられることもでき、いずれの運用にも対応する。キューには「作業中」としてレコードを確保する仕組みがあり、複数の担当者が同じ案件に同時着手して二重対応になる事態を防げる。また、プライベートキューとパブリックキューを使い分けることで、担当外の業務のレコードが見えないよう可視範囲を整理できる。実務では、キューの粒度が細かすぎると滞留の監視が煩雑になり、粗すぎると誤配が増えるため、監視と運用ができる単位で設計することが重要である。ワークストリームはルーティングの定義単位であり、レコードの集約先そのものではない。

正解: A. A. レコードのルーティング（優先度に基づく自動割り当て）

正解の根拠・詳細解説

キュー内のレコードを条件に応じて担当者へ自動割り当てするには、レコードのルーティングを構成する。Unified Routing では、ワークストリームに設定した分類ルールとルーティングルールでレコードの優先度や区分を評価し、割り当て段階では担当者のキャパシティ・プレゼンス・スキルを考慮して配分先を決める。優先度の高い作業を先に処理させたい場合は、優先度に基づく評価をルーティングの構成に反映させることで、緊急案件が滞留せずに担当者へ届くようにできる。実務での要点は、優先度の付与そのものを自動化しておくことであり、担当者の手入力に依存すると優先度が正しく設定されず、いくらルーティングを作り込んでも意図した順序で処理されない。重複検出ルール・列レベルセキュリティ・ナレッジ記事の翻訳管理は、割り当てとは無関係の機能である。

正解: A. A. Power Automateのトリガーを使った通知フロー

正解の根拠・詳細解説

キューへの追加を契機とした通知は、Power Automate のクラウドフローで実装する。Dataverse コネクタでキュー アイテムの作成をトリガーとするフローを作り、対象のキューかどうかを条件で判定したうえで、担当チームへのメール送信、Teams チャネルへの投稿、モバイル通知といったアクションを実行する。フローの中でケースの優先度や顧客区分を評価して通知先や文面を変えることもでき、緊急案件だけ即時に別ルートで知らせるといった運用も構成できる。実務での注意点は通知の量であり、すべての追加を無条件で通知すると担当者が通知を無視するようになるため、対象条件を絞ることが実効性の鍵である。Unified Routing を利用している場合は、通知テンプレートによる担当者への割り当て通知も併用できる。重複検出ルールや SLA 適用性条件は通知の仕組みではない。

正解: A. A. ワークストリーム内で定義した優先順位（適用順）に従って評価される

正解の根拠・詳細解説

ワークストリームに複数のルーティングルールセット（および分類ルールセット）を設定した場合、それらには適用順（優先順位）が設定でき、上位のものから順に条件が評価される。最初に条件へ合致したルールの振り分け先が採用されるため、ルールの並び順が実際の振り分け結果を直接左右する。したがって、より限定的で特殊な条件を上位に、汎用的で広い条件を下位に配置するのが設計の原則であり、広い条件を上に置くと下位の特殊ルールが永遠に評価されない、いわゆる到達不能ルールが生まれる。作成順やアルファベット順、ランダムで評価されるわけではないため、ルールを追加した際は必ず順序を確認する必要がある。実務では、ルールが増えるほど順序の把握が難しくなるため、命名規則で意図を表現し、条件の重なりを定期的に棚卸しすることが有効である。

正解: A. A. チャネルごとに個別のワークストリームを作成し、それぞれにルーティングルールを構成する

正解の根拠・詳細解説

チャネルごとに異なるルーティングロジックが必要な場合は、チャネル単位でワークストリームを分けて作成し、それぞれに適した分類ルール・ルーティングルール・割り当て方法・キャパシティの扱いを構成するのが基本設計である。チャットはリアルタイム性が高く即時のプッシュ配信と短い応答が求められる一方、メールは非同期で1件あたりの処理が重いため、同じ割り当てポリシーでは適切に機能しない。ワークストリームを分けることで、配分モードや消費するキャパシティの重み、既定キューをチャネルの特性に合わせて独立して設計できる。単一のワークストリームに全チャネルを詰め込むと、条件分岐が複雑化して保守が困難になり、チャネル固有の要件も表現しきれない。SLA は期限の管理であってルーティングの代替にはならず、キューを介さない直接割り当ては負荷分散と滞留監視の仕組みを失う。

正解: A. A. プレゼンス状態を考慮したユーザー設定とルーティングルール

正解の根拠・詳細解説

離席中の担当者への割り当て抑止は、プレゼンスとルーティングの連携によって実現される。担当者のプレゼンス（応対可能・取り込み中・退席中・応対不可など）は、本人の手動設定、現在の作業負荷に基づく自動遷移、システムの非アクティブ検知などによって変化し、Unified Routing の割り当てロジックはこの状態を評価して、応対可能な状態にない担当者を候補から除外する。管理者はワークストリームやユーザー設定側で、どのプレゼンス状態を割り当て可能とみなすかを構成できる。実務での要点は、担当者に休憩や離席の際のプレゼンス変更を運用ルールとして徹底させることであり、これが守られないと不在の担当者に作業が配分されて応答遅延を招く。重複検出ルール・ナレッジ記事の翻訳設定・SLA KPI は、割り当ての抑止とは無関係である。

正解: A. A. スラグの共有範囲（公開設定）

正解の根拠・詳細解説

クイック返信とスラグを登録する際は、その定型文を個人専用として自分だけが使うか、組織全体で共有して他の担当者も利用できるようにするかという共有範囲を設定できる。組織で共有する定型文は、表現の統一と品質の底上げに直結し、特に新任担当者が適切な言い回しをすぐ使えるようになる効果が大きい一方、内容の正確性に対する責任も組織側に生じるため、公開前のレビューを運用に組み込むことが望ましい。個人専用の定型文は、担当者が自分の対応スタイルに合わせて自由に整備できる領域として使い分ける。実務では、個人の定型文の中から利用頻度が高く汎用性のあるものを定期的に共有側へ昇格させる運用にすると、現場の知見が自然に組織のベストプラクティスとして蓄積されていく。SLA 適用性や重複検出ルールは共有範囲の設定とは無関係である。

正解: A. A. 繰り返し作業の効率化と対応の標準化

正解の根拠・詳細解説

マクロの目的は、担当者が対応中に繰り返し行う定型的な操作手順をひとまとめにし、ワンクリックで実行できるようにすることで、作業時間の短縮と手順の標準化を同時に達成することにある。レコードの作成、フィールドの更新、アプリケーションタブを開く、ナレッジ検索を実行するといったステップを順に構成でき、担当者ごとに操作の抜けや差が出ることを防げる。さらに、エージェントスクリプトのステップとしてマクロを組み込むと、担当者に対して「次に何をするか」を提示しつつ、その操作自体を自動実行させられるため、教育コストの削減にもつながる。実務での注意点は、マクロが担当者の権限で実行される点であり、対象テーブルへの権限が不足していると実行時に失敗するため、権限設計とあわせた動作確認が必要である。バックアップやセキュリティ管理の機能ではない。

正解: A. A. AI支援パネル（提案・要約・下書き応答などの表示領域）

正解の根拠・詳細解説

Copilot Service workspace の画面は、対応中のレコードを表示する領域とは別に、AI 支援を担う生産性ペイン（Copilot ペイン）を備えている。ここには、ケースや会話の要約、顧客の質問に対する回答の提案、ナレッジ記事を根拠としたメールやチャットの下書き応答、参照元へのリンクといった情報が表示され、担当者は提示内容を確認して必要な部分を採用・編集しながら対応を進められる。重要な設計思想は、AI が自動で送信するのではなく担当者が最終判断を行う点であり、根拠となった記事が併記されることで内容の妥当性を確認できるようになっている。この領域に何を表示するかはエクスペリエンスプロファイルで構成する。印刷プレビュー・レポートエクスポート・ダッシュボード共有設定は、いずれも AI 支援の表示領域ではない。

正解: A. A. マルチセッション環境とセッションテンプレートの構成

正解の根拠・詳細解説

マルチセッション環境は、Copilot Service workspace や Customer Service workspace のようなマルチセッション対応アプリで提供される機能であり、担当者は複数のケースや会話をそれぞれ独立したセッションとして開き、タブを切り替えながら並行処理できる。各セッションは自身のアンカータブと関連するアプリケーションタブの集合を保持するため、セッションを切り替えても作業の文脈が失われない。どのレコードをアンカータブとして開き、どの関連タブを併せて開くかはセッションテンプレートで定義し、タブ1つ分の定義はアプリケーションタブテンプレートが担う。実務では、セッション数が増えすぎると担当者の認知負荷が上がるため、キャパシティ設定による同時対応数の制御とあわせて設計することが重要である。重複検出ルール・SLA KPI は画面構成とは無関係である。

正解: A. A. エクスペリエンスプロファイルをロール別に作成し割り当てる

正解の根拠・詳細解説

画面構成を役割別に最適化するには、エクスペリエンスプロファイル（エージェント エクスペリエンス プロファイル）をロールや経験レベルごとに複数作成し、該当するユーザーやチームへ割り当てる。プロファイルには、利用可能なチャネル、セッションテンプレート、通知テンプレート、生産性ペインに表示するツール（ナレッジ検索、エージェントスクリプト、スマートアシスト、Copilot など）が含まれるため、新人にはガイド性の高いシンプルな構成、熟練者には多くのチャネルと分析情報を含む構成、という差別化ができる。全員に同一のセッションテンプレートを割り当てる方式では、この出し分けが実現できず要件を満たさない。セキュリティロールの削除は権限の破壊であり、画面の最適化とは全く別の話である。プロファイルは画面の構成を制御するが、データへのアクセス権は制御しない点に注意する。

正解: A. A. 受信トレイのカスタムビュー

正解の根拠・詳細解説

受信トレイのカスタムビューを作成すると、担当者が対応すべき作業項目を業務に合った条件で絞り込んで表示できる。自分が所有するケースのみ、優先度が高いもののみ、特定のキューのもののみ、といった条件のビューを用意して切り替えることで、大量の項目の中から着手すべきものを短時間で判断できる。受信トレイの有効化と、どのビューを担当者に提供するかはエクスペリエンスプロファイル側で構成するため、ロールごとに異なるビューの組み合わせを提供することも可能である。実務での要点は、ビューを増やしすぎると選択自体が手間になるため、実際の作業の入り口として使う数個に絞ることであり、その上で並び順を優先度や期限に基づいて設定すると効果が高い。SLA KPI・ナレッジ記事の翻訳管理・重複検出ルールは、一覧の絞り込みとは無関係である。

正解: A. A. アプリケーションタブテンプレート

正解の根拠・詳細解説

アプリケーションタブテンプレートは、セッション内で開くタブ1つ分の定義を再利用可能な形で管理する仕組みであり、対象とするページの種類（レコード、ビュー、ダッシュボード、Web リソース、URL など）、パラメーター、タブ名などを指定する。作成したテンプレートはセッションテンプレートから参照され、そこでどのタブをどの順序で開くかを構成するため、組み合わせによって画面全体のレイアウトを組織全体で統一できる。この分離構造の利点は、共通で使うタブ定義を一箇所で管理でき、変更が全セッションテンプレートへ波及する点にある。実務では、担当者が対応中に手動でよく開くページを洗い出してテンプレート化することが、応対時間短縮の典型的な改善施策となる。ワークストリームの優先順位・SLA 適用性・重複検出ルールは、タブの管理とは無関係である。

正解: A. A. 該当ユーザーのプレゼンス状態やキャパシティを更新し、ルーティングルールで一時的に除外する

正解の根拠・詳細解説

休暇中の担当者への割り当てを止めるには、そのユーザーのプレゼンス状態を応対不可に設定するか、キャパシティの設定を調整して新規の作業が配分されないようにする。Unified Routing の割り当てロジックはプレゼンスと残容量を評価するため、応対可能な状態にない担当者は候補から除外され、結果として作業は他の担当者や既定のキューへ回る。あわせて、その担当者を特定のキューやスキル条件から一時的に外す運用も併用できる。セキュリティロールの削除は権限そのものを奪う操作で、業務復帰時の復旧も煩雑になるうえ、既存の担当案件へのアクセスまで失われるため不適切である。SLA の無効化は期限管理を止めるだけで割り当てには影響せず、むしろ管理が破綻する。重複検出ルールの削除はデータ品質の低下を招くだけで、要件とは全く関係がない。

正解: A. A. AND/OR条件を組み合わせた条件分岐ロジック

正解の根拠・詳細解説

ルーティングルールセットの各ルール項目では、条件を AND と OR で組み合わせた条件式を構成でき、優先度・製品・言語・顧客区分といった複数の属性を同時に評価して振り分け先を決定できる。これにより、「優先度が高く、かつ製品が特定シリーズで、かつ言語が日本語」といった複合条件を1つのルールとして表現でき、単一条件だけでは表せない実際の業務要件に対応できる。ルール項目は上から順に評価され、最初に合致したものが適用されるため、条件の重なりと並び順の設計が結果を左右する。実務では、条件が複雑になるほど到達不能なルールや意図しない合致が生まれやすいため、限定的な条件を上位に、汎用的な条件を下位に置く原則を守り、変更時には必ず全体の評価順を確認することが重要である。ランダム抽選や固定の振り分け先指定のみでは、複合的な要件を表現できない。

正解: A. A. 担当者の現在の作業負荷（キャパシティの空き状況）

正解の根拠・詳細解説

スキル条件を満たす担当者が複数存在する場合、Unified Routing はさらに担当者の現在の作業負荷、すなわちキャパシティの空き状況とプレゼンスを評価して割り当て先を絞り込む。この評価により、スキル的には同等でも既に多くの案件を抱えている担当者は避けられ、余力のある担当者へ作業が配分されるため、チーム内での負荷の偏りを防ぎ、結果として応答時間と対応品質の安定につながる。最終的な選定は、ワークストリームで指定した割り当て方法（最も空いている担当者を選ぶ、ラウンドロビンで順に配分するなど）によって決まる。入社年月日・氏名のアルファベット順・使用言語の文字数といった要素は、いずれも作業配分の合理的な判断材料ではなく、システムが評価する対象でもない。実務では、割り当て方法の選択がチームの働き方に合っているかを稼働後に検証することが重要である。

正解: A. A. 対応品質の標準化と新人担当者の立ち上げ期間の短縮

正解の根拠・詳細解説

マクロやクイック返信（スラグを含む定型文）をチーム間で共有・標準化する運用上の最大のメリットは、担当者ごとの対応のばらつきを抑えて品質を一定に保てること、そして新人担当者が経験者と同等の応対をすぐに再現できるようになり、立ち上げ期間を短縮できることである。優れた対応手順や言い回しが個人の中に留まらず組織の資産として共有されるため、退職や異動によるノウハウの喪失も防げる。あわせて、標準化された定型文は文言の修正を一箇所で行えるため、案内内容の変更時にも展開が速い。実務では、共有する内容を定期的に見直して古い案内が残らないようにするレビュー運用が伴わないと、かえって誤った情報を広く配布してしまう点に注意が必要である。データベース容量の削減やセキュリティロールの自動生成といった効果は生じない。

正解: A. A. 設定変更後の新しいルーティング条件は新規レコードに適用され、既存レコードの挙動は管理者の追加対応に依存する

正解の根拠・詳細解説

ワークストリームやキューの設定変更は、基本的に変更後に新しく発生・到着するレコードに対して適用される。既にキューに入って未処理のまま滞留しているレコードは、過去のルールに基づいて配置されたものであり、設定変更によって自動的に再評価・再配置されるわけではない。したがって、既存の未処理分をどう扱うかは管理者が別途判断し、手動でのキュー移動、一括更新、あるいは再ルーティングを促す処理を行う必要がある。既存レコードが自動的に削除されたり、最優先で再割り当てされたりすることはなく、また変更が全く反映されず固定されるわけでもない。実務では、ルーティング構成を変更する際に、切り替えのタイミングと既存滞留分の扱いを事前に計画しておかないと、一部の案件が旧ルールの想定のまま放置され、対応漏れにつながる点が重要な注意事項である。

正解: A. A. アプリケーションタブテンプレートとコンテキストデータの構成

正解の根拠・詳細解説

会話画面に顧客の文脈情報を自動表示するには、アプリケーションタブテンプレートで表示対象のページを定義し、セッションテンプレートからそれを開くよう構成する。タブテンプレートにはパラメーターとしてコンテキストのデータを渡せるため、対応中の顧客レコードに紐づく購入履歴や過去のケース一覧といった関連情報を、担当者が手動で検索することなくセッション開始時点で提示できる。オムニチャネルの会話では、事前アンケートやチャットウィジェットから取得した情報がコンテキスト変数として保持され、これを画面表示やルーティング条件に活用できる。実務での効果は初動の短縮にあり、担当者が顧客に既知の情報を尋ね直す必要がなくなることで顧客体験も向上する。SLA KPI・重複検出ルール・ナレッジ記事カテゴリは、コンテキスト表示とは無関係である。

正解: A. A. チームやセキュリティロールに基づいてキャパシティプロファイルを一括適用する

正解の根拠・詳細解説

キャパシティプロファイルは個々のユーザーに1人ずつ手作業で設定するのではなく、プロファイル側に対象となるユーザーの集合を割り当てる形で一括適用でき、チーム単位での運用にも対応する。これにより、同じ役割・経験レベルの担当者グループに共通の上限を効率的に展開でき、人員の増減があっても割り当ての管理が煩雑にならない。1つのプロファイルを複数の担当者へ割り当てられるため、「1人にしか割り当てられない」という選択肢は誤りであり、また個別の手動設定しか手段がないというのも誤りである。SLA は対応期限の計測を行う機能であり、作業容量の設定手段ではないため代替にはならない。実務では、プロファイルの設計と割り当てを組織図や役割定義と対応づけておくと、人事異動の際の更新作業が単純になり、設定漏れによる割り当ての偏りを防げる。

正解: A. A. 意図しないキューへの振り分けや担当者への過剰割り当てが発生する可能性がある

正解の根拠・詳細解説

ルーティングルールを十分に検証せずに本番へ適用すると、条件式の記述ミスやルールの並び順の誤りによって、案件が意図しないキューへ流れて対応が遅延したり、条件が広すぎるルールが上位にあるために特定の担当者やチームへ案件が集中して過負荷になったりする。逆に、どのルールにも合致せず既定キューが未設定の場合は、案件がどこにも届かず滞留する事態も起こり得る。いずれも顧客への応答遅延と SLA 違反に直結するため、影響は運用面で大きい。実務では、まず限定的な条件で対象を絞って適用し、割り当ての結果を監視しながら段階的に範囲を広げるという展開方法を取るのが安全である。ルーティングの誤りでセキュリティロールが強化されたり、SLA が自動的に無効化されたり、ナレッジ記事が削除されたりすることはなく、これらの選択肢は仕組みとして成立しない。

正解: A. A. 担当者のスキルに対応言語を登録し、スキルベースルーティングで照合する

正解の根拠・詳細解説

多言語対応のコールセンターでは、対応言語をスキルとして定義し、各担当者のスキルに保有言語と習熟度を登録したうえで、作業項目側にも分類ルールで必要な言語スキルを付与する。スキルベースルーティングのスキルファインダーが両者を照合するため、日本語の問い合わせは日本語対応可能な担当者へ、英語の問い合わせは英語対応可能な担当者へと自動的に振り分けられる。照合方式は完全一致と近い一致から選択でき、言語のように必須要件となるスキルは完全一致で扱うのが妥当である。実務での注意点は、特定言語の担当者が少ない時間帯に案件が滞留しないよう、フォールバック先のキューや対応時間帯の設計を併せて行うことである。言語を無視したランダム割り当てや、SLA による言語判定は仕組みとして成立せず、要件を満たさない。

正解: A. A. ワークストリームを公開（アクティブ化）する

正解の根拠・詳細解説

ワークストリームやそれに紐づくルールの設定は、編集しただけでは実際のルーティング処理には反映されず、公開（アクティブ化）の操作を行って初めて有効になる。分類ルールセットやルーティングルールセットも同様に公開が必要で、この手順を忘れると「ルールを作ったのに振り分けが変わらない」というトラブルの典型的な原因になるため、変更後は必ず公開状態を確認する習慣が重要である。Dynamics 365 はクラウドサービスであるためサーバーの再起動という概念は管理者の操作対象ではなく、ライセンスの再購入やパスワードの変更も設定反映とは全く関係がない。実務では、本番環境のルーティング変更は、公開のタイミングを業務時間外に合わせ、公開直後の割り当て結果を一定時間監視して意図どおりに動作しているか確認する運用が望ましい。

正解: A. A. チャネルの特性に応じた適切な作業負荷の分散

正解の根拠・詳細解説

チャネル別にキャパシティを分けて設定する目的は、チャネルごとに異なる対応の性質を作業負荷の計算に反映させることにある。チャットは顧客が即時の応答を期待するリアルタイムなやり取りであり、同時に多数を抱えると応答が遅れて顧客体験が損なわれるため同時件数を抑える必要がある一方、メールは非同期で担当者が処理のタイミングを選べるため、より多くを並行して保持できる。この違いを無視して単一の上限を適用すると、チャットが過剰に割り当てられて応答が遅延するか、逆にメールの処理能力を活かしきれないという偏りが生じる。より細かな重み付けが必要な場合は、キャパシティプロファイルで作業種別ごとの消費単位を定義する方式を用いる。ナレッジ記事の自動生成や SLA の短縮といった効果は、キャパシティ設定からは生じない。

正解: A. A. 要求スキルとの一致度や習熟度を加味してスコアリングし、最適な担当者を選択する

正解の根拠・詳細解説

スキルベースルーティングでは、作業項目に付与された必要スキルと、担当者が保有するスキルおよびその習熟度を照合し、要件を満たす担当者を候補として抽出する。照合方式には、必要スキルをすべて満たす担当者のみを対象とする完全一致と、条件を緩めて候補を広げる近い一致があり、後者では適合の度合いに応じて候補が評価される。スキルで絞られた候補に対して、さらにキャパシティの空き状況とプレゼンスによる評価が行われ、最後にワークストリームで指定した割り当て方法によって最終的な1人が決まるという多段の構成になっている。したがって、最初に登録されたスキルだけで判定したり、スキルの数が多い担当者を無条件に優先したり、スキルを無視してランダムに割り当てたりすることはない。実務では、候補が不在になる事態を避けるフォールバック設計が重要である。

正解: A. A. システム管理者またはCustomer Service機能管理者

正解の根拠・詳細解説

キューやワークストリーム、ルーティングルールはアプリケーションの構成情報であり、その編集にはCustomer Service管理センターへのアクセスと、システム管理者やカスタマーサービスマネージャーといった構成変更の権限を持つセキュリティロールが必要です。一般の担当者ロールにはこれらの設定テーブルへの書き込み権限が与えられていないため、日常業務のユーザーが自分で直すことはできません。組織変更で部署名が変わった場合は、キューの名称を変えるだけでは不十分です。そのキューを参照しているルーティングルール、ワークストリームの割り当て先、SLA、自動レコード作成ルールの条件なども併せて棚卸しし、参照が古い名称や無効な対象を指していないか確認します。なお、既存のキューを削除して新規に作り直すと過去のケースからの参照や履歴が失われるため、名称変更で対応するほうが安全です。

正解: A. A. 対象テーブルのフォームに列を追加・構成する

正解の根拠・詳細解説

新しい業務要件に応じた入力項目を追加する手順は、まず対象テーブル（ケースなど）に列を追加してデータの器を定義し、次にフォームエディターでその列をフォーム上の適切なタブ・セクションに配置して、担当者が入力できるようにするという流れになる。列の追加だけではフォームに自動で表示されないため、両方の作業が必要である点が実務での基本である。あわせて、列の必須レベル、既定値、ビューへの追加、検索対象に含めるかどうかも要件に応じて構成する。ダッシュボードのテーマは見た目の設定にすぎず、データの入力項目とは無関係である。SLA 項目は対応期限の指標を定義するものであり、入力欄を追加する手段ではない。重複検出ルールの無効化はデータ品質を下げるだけで、新項目の追加とは関係がない。

正解: A. A. フォームのタブ・セクションを条件付き表示ルールで構成する

正解の根拠・詳細解説

条件に応じたセクションの出し分けは、フォームエディターでタブやセクションを構成したうえで、ビジネスルールの「表示・非表示」アクションによって制御するのが標準的な方法である。ビジネスルールなら条件と表示制御をコードなしで定義でき、保守性が高い。より複雑な条件や動的な処理が必要な場合は、JavaScript の Web リソースとフォームのイベントハンドラーで制御する方法もあるが、保守コストが上がるためビジネスルールで実現できる範囲はそちらを優先するのが定石である。重要な注意点として、フォーム上で非表示にしただけでは列の値そのものは保持されており、高度な検索や API 経由では参照できるため、機密性を担保する目的には使えない。その場合は列レベルセキュリティを併用する必要がある。SLA KPI・重複検出ルール・セキュリティロールの削除は、表示制御の手段ではない。

正解: A. A. 業務上よく使う条件での絞り込み・並び替え表示を再利用可能にするため

正解の根拠・詳細解説

ビュー（保存されたビュー）は、テーブルのレコード一覧に対する絞り込み条件、表示する列、並び順をあらかじめ定義して名前を付けて保存する仕組みであり、業務でよく使う切り口を再利用可能にする。「未解決かつ優先度が高いケース」「自分が所有する期限間近のケース」といったビューを用意しておくことで、担当者は毎回条件を組み立てる手間なく、必要な一覧へ即座にアクセスできる。ビューにはシステムビュー（管理者が定義し全ユーザーへ提供、セキュリティロールで可視性を制御）と個人ビュー（ユーザーが自分用に作成し、必要に応じて共有）があり、この使い分けが運用設計の要点となる。なお、ビューはあくまで表示の絞り込みであり、レコードへのアクセス権はセキュリティロールが決めるため、ビューで見えない範囲を制御できるわけではない。

正解: A. A. アプリのサイトマップ（コンポーネント構成）

正解の根拠・詳細解説

モデル駆動型アプリの左側ナビゲーションは、アプリのサイトマップ（ナビゲーション構成）によって定義される。サイトマップは、エリア（最上位の区分）、グループ（エリア内の見出し単位）、サブエリア（実際のリンク項目）という3階層で構成され、サブエリアの種類としてテーブル、ダッシュボード、Web リソース、URL などを指定できる。したがって、カスタムテーブルをナビゲーションに出すには、アプリデザイナーでそのテーブルをアプリのコンポーネントに含めたうえで、サイトマップのサブエリアとして追加し、アプリを発行する必要がある。実務での典型的なつまずきは、テーブルをアプリに追加しただけでナビゲーションに現れないケースと、発行を忘れて変更が反映されないケースであり、いずれも手順の抜けが原因である。SLA 項目・重複検出ルール・列レベルセキュリティは、ナビゲーションの構成とは無関係である。

正解: A. A. 日付のみ、または日付と時刻型の列

正解の根拠・詳細解説

日付情報を扱う列には、「日付のみ」または「日付と時刻」のデータ型を選択する。適切な型を使うことで、カレンダーによる入力支援、日付としての妥当性検証、期間での絞り込み、正しい時系列の並び替えが可能になり、日付関数を用いた計算列やフローの条件判定にも利用できる。テキスト型で日付を保持すると、文字列としての比較しかできず、並び替えが暦の順にならない、期間検索ができないといった問題が生じるため避けるべきである。実務で重要なのが動作の設定であり、「ユーザーのローカル」ではタイムゾーンに応じて表示が変換されるのに対し、「タイムゾーン非依存」や「日付のみ」では変換されない。契約更新日や誕生日のように暦の日付そのものが意味を持つ項目では、タイムゾーン変換によって日付が1日ずれる事故を防ぐため、後者の動作を選ぶのが定石である。

正解: A. A. アプリ内通知（フラッシュ通知）をトリガーするPower Automateフローを構成する

正解の根拠・詳細解説

アプリ内通知は、モデル駆動型アプリの画面上に表示される通知の仕組みであり、Power Automate のクラウドフローから通知レコードを作成することで送信できる。構成としては、Dataverse トリガーでケースの優先度列の更新を検知し、値が緊急に変わったことを条件で判定したうえで、通知の宛先ユーザー・タイトル・本文・関連レコードへのリンクを指定して通知を作成する、という流れになる。メールと違い受信箱を確認する必要がなく、担当者が作業中の画面上で即座に気付ける点が緊急案件のエスカレーションに適している。実務での注意点として、アプリ内通知は組織設定で機能を有効化しておく必要があること、また更新トリガーではフィルター列を指定しないと無関係な更新でも発火してしまうことが挙げられる。列レベルセキュリティや重複検出ルールは通知の手段ではない。

正解: A. A. Power Apps（メーカーポータル）でテーブルを新規作成し、列とリレーションシップを定義する

正解の根拠・詳細解説

既存テーブルでは表現できない新しい情報を管理する場合は、Power Apps のメーカーポータル（あるいはソリューションエクスプローラー）でソリューション内にテーブルを新規作成し、必要な列を定義したうえで、既存テーブルとのリレーションシップを構成するのが基本手順である。この段階で、主キーとなる主要な名前列、各列のデータ型と必須レベル、そしてケースなど関連テーブルとの参照関係を設計しておくことが、後々のフォーム・ビュー・レポート設計の土台になる。加えて、テーブルの所有形態（ユーザーまたはチーム所有か、組織所有か）は作成後に変更できないため、セキュリティ要件に応じて最初に正しく選択する必要がある。実務では、必ず未管理ソリューション内で作業し、既定のソリューションに直接作らないことが、環境間の移送を可能にするうえで重要である。

正解: A. A. 既存データとの互換性やビジネスロジックへの影響を事前に確認する必要がある

正解の根拠・詳細解説

列のデータ型や桁数の変更は、まったく自由に行えるわけでも、一切不可能なわけでもなく、変更可能な範囲に制約があり、かつ既存の資産へ影響を及ぼす。たとえば最大文字数を縮めると既存データが収まらない可能性があり、データ型そのものの変更は許容される組み合わせが限られる。加えて、その列を参照しているフォーム、ビュー、ビジネスルール、Power Automate のフロー、レポート、連携している外部システムのすべてが影響範囲となるため、変更前に依存関係を洗い出す必要がある。実務での安全な進め方は、開発環境で変更を試して影響を確認し、ソリューションとして本番へ移送する手順を踏むことである。なお、変更しても旧データが自動的に削除されるわけではないが、意図しない切り捨てや変換が起きる可能性はあるため、事前のバックアップと検証が欠かせない。

正解: A. A. 1対多のリレーションシップ

正解の根拠・詳細解説

1件のケースに対して複数の関連レコードを紐づけたい場合は、ケースを「1」側、サービス契約詳細を「多」側とする1対多のリレーションシップを構成する。この構成では、「多」側のテーブルに「1」側を指す参照（ルックアップ）列が自動的に作成され、その列を通じて親子の関係が表現される。ケースのフォームにはサブグリッドを配置することで、関連する契約詳細を一覧表示・追加できるようになる。設計上の重要な選択が動作の設定（カスケード）であり、親のケースを削除したときに子を連鎖削除するか、参照を外すだけにするか、所有者の変更や共有を子へ伝播させるかを定義する。実務では、この設定を既定のまま進めて意図しない連鎖削除が起きる事故が起こり得るため、業務上の意味に照らして明示的に選択することが重要である。

正解: A. A. 多対多のリレーションシップ

正解の根拠・詳細解説

複数のレコードが互いに複数の相手と関連し合う関係は、多対多のリレーションシップで表現する。Dataverse では、多対多を構成するとシステムが内部的に中間テーブル（交差テーブル）を自動生成して関連付けを保持するため、作成者が中間テーブルを自分で設計・管理する必要がない点が利点である。一方で、この自動生成される中間テーブルには追加の列を持たせられないため、関連そのものに属性（適用開始日、関連の強さ、備考など）を持たせたい要件がある場合は、多対多を使わず、中間となるカスタムテーブルを自分で作成し、両側のテーブルへの1対多を2本張る手動の設計に切り替える必要がある。この使い分けは実務で頻出する判断であり、要件を満たせずに作り直しになる典型的な設計ミスの原因でもある。1対1や階層のみでは、相互に複数の関連を表現できない。

正解: A. A. Dataverseの検索（クイック検索またはDataverse検索）の対象テーブル設定

正解の根拠・詳細解説

複数テーブルを横断したキーワード検索を提供するのが Dataverse 検索であり、対象とするテーブルと、そのテーブル内で検索対象とする列を管理者が構成する。Dataverse 検索は外部の検索インデックスを利用するため、インデックスへの反映には多少の時間差があるが、関連度順の結果表示、あいまい一致、ファセットによる絞り込みといった高度な検索体験を提供できる。一方、クイック検索は個々のテーブルのクイック検索ビューに定義した検索列に対する検索であり、リアルタイム性は高いが横断検索には向かない。実務では、対象テーブルと列を広げすぎるとノイズが増えるため、担当者が実際に探す項目に絞って構成することが精度を保つ鍵である。なお、検索結果はユーザーのセキュリティ権限でフィルターされるため、権限のないレコードが表示されることはない。

正解: A. A. 該当テーブルを検索対象から除外するよう設定する

正解の根拠・詳細解説

機密性の高いテーブルを検索結果に出したくない場合は、Dataverse 検索の設定でそのテーブルを検索対象から除外する。ただしこれはあくまで検索という経路での露出を減らす措置であり、セキュリティ境界そのものではない点を正しく理解しておく必要がある。レコードへのアクセス可否を決めるのはセキュリティロールであり、検索対象から外しても権限を持つユーザーはビューや高度な検索、API 経由でそのデータへ到達できる。したがって、機密データの保護は、セキュリティロールによるテーブル権限の設定と、必要に応じた列レベルセキュリティによる列単位の制御を主たる手段とし、検索対象からの除外はそれを補完する運用上の配慮として位置づけるのが正しい。セキュリティロールの全削除は業務そのものを停止させる操作であり、SLA の無効化や重複検出ルールの変更は情報保護とは無関係である。

正解: A. A. メールテンプレート（動的差し込みフィールドを含む）

正解の根拠・詳細解説

定型文に顧客名やケース番号を差し込んだメールを送るには、メールテンプレートを作成し、その本文に差し込みフィールド（動的なプレースホルダー）を組み込む。差し込みフィールドは送信時に対象レコードの実際の値へ置き換えられるため、宛先ごとに個別化された文面を自動生成できる。テンプレートは、対象とするテーブルの種類ごとに作成する必要があり、ケース用のテンプレートにはケースおよび関連する顧客の列を差し込める。ステータス変更を契機とした自動送信は、Power Automate のフローからこのテンプレートを指定してメールを送信する構成で実現する。実務での注意点は、差し込み対象の列が空だった場合の表示であり、値が入らないまま送信されると不自然な文面になるため、フロー側で値の有無を確認するか既定値を用意しておく配慮が必要である。

正解: A. A. メールテンプレートのスコープ（個人・組織・特定ビジネスユニット）を適切に設定する

正解の根拠・詳細解説

メールテンプレートには適用範囲を示すスコープがあり、作成者個人のみが使う個人用、組織全体で共有される組織用、といった区分で管理できる。これにより、全社共通の案内文は組織スコープで一元管理して表現を統一し、部署固有の文面は限定された範囲で管理するという整理が可能になる。すべてを1つのテンプレートに集約する方式では、部署ごとに異なる文面や署名を表現できず、結局担当者が毎回手直しすることになって標準化の効果が失われる。テンプレート機能を使わず手入力で対応する方式は、対応時間が延びるうえに表現がばらつき、誤った案内のリスクも高まる。SLA は対応期限を管理する仕組みであり、文面の管理手段にはならない。実務では、テンプレートが乱立して古い文面が使われ続けないよう、定期的な棚卸しの運用を定めておくことが重要である。

正解: A. A. 対象のビューやフォームを編集し、新しい列を明示的に追加する

正解の根拠・詳細解説

テーブルに列を追加しても、既存のフォームやビューへ自動的に配置されることはない。列の追加はデータの器を定義する操作であり、それを画面上のどこに、どの順序で表示するかは別の設計判断だからである。したがって、フォームエディターで対象のフォームに列を配置し、ビューエディターで対象のビューに列を追加したうえで、それぞれを発行する必要がある。ビューやフォームを一から作り直す必要はなく、既存のものを編集すれば足りる。実務での典型的な問い合わせが「列を作ったのに画面に出ない」というもので、原因のほとんどはこの配置作業か発行の忘れである。あわせて、複数のフォーム（メイン、クイック作成、クイック表示）やアプリごとのビューが存在する場合は、どこに追加すべきかを整理しておかないと、一部の画面だけ項目が欠ける状態になりやすい。

正解: A. A. Dynamics 365 Customer Voice

正解の根拠・詳細解説

設問ごとの評価尺度の設定は Dynamics 365 Customer Voice が担う。Customer Voice では、評価（星や数値のスケール）、リッカート形式、選択肢、テキスト、NPS といった設問タイプを選択でき、評価尺度を用いることで回答が数値として蓄積されるため、平均値や分布としての集計・比較が容易になる。自由記述だけで構成すると定量的な傾向把握ができないため、尺度型の設問と自由記述を組み合わせるのが実務上の定石である。回答は Dataverse に保存され、ケースや取引先担当者と関連付けて分析できる。Dynamics 365 Sales は営業プロセスを扱うアプリ、Power Virtual Agents（現在の Copilot Studio）は会話型ボットの構築ツールであり、いずれもアンケートの設問設計と集計を担う製品ではない。

正解: A. A. Power Automateの遅延（待機）アクションを含むアンケート配布フロー

正解の根拠・詳細解説

配信のタイミングを制御するには、Power Automate のクラウドフローに待機系のアクション（指定した時間だけ待つ、または指定した日時まで待つ）を組み込み、その後に Customer Voice の調査送信アクションを配置する。ケースの解決を検知した時点でフローが起動し、指定時間の経過を待ってからアンケートを送るという流れになるため、対応直後の慌ただしいタイミングを避け、顧客が落ち着いて評価できるタイミングで届けられる。実務では、待機中にケースが再オープンされた場合の扱いを考慮し、送信前に対象ケースの状態を再確認して条件に合わなければ送信を中止する分岐を入れておくと、不適切なアンケート送信を防げる。SLA 項目は対応期限の計測を行う機能であり、遅延実行の手段にはならない。重複検出ルールや列レベルセキュリティも、配信タイミングの制御とは無関係である。

正解: A. A. 調査の個人設定（パーソナライズ）に基づく言語設定の継承

正解の根拠・詳細解説

Customer Voice では、調査の送信時に外部から変数を渡してアンケートの表示内容を個別最適化できる。言語についても、対象の顧客レコードに保持している言語の情報を配信フローから渡すことで、その顧客に適した言語版のアンケートを表示させることができ、結果として回答のしやすさと回答率が向上する。前提として、調査に複数の言語を追加して多言語化しておく必要がある。実装上の要点は、顧客の言語という情報を Dataverse 側の取引先担当者などに正しく保持し、配信の都度その値を参照する設計にしておくことであり、この整備がないと過去の設定を引き継ぐ動きは実現できない。重複検出ルール・SLA KPI・タイムラインのハイライトルールは、いずれもアンケートの表示内容には一切関与しない。

正解: A. A. アンケート結果とケースのリレーションシップを構成し、Power BIなどで可視化する

正解の根拠・詳細解説

満足度の傾向を担当者別・ケース種別別に分析するには、まずアンケートの回答をケースと関連付けて記録できるようにする。Customer Voice の配信フローからケースの識別情報を変数として渡し、回答レコードに保持させることで、回答とケースを結びつけられる。回答結果は Dataverse に格納されるため、そこから Power BI で回答データとケースデータを結合し、担当者・ケース種別・期間といった切り口で満足度を集計・可視化できる。印刷して手作業で集計する方法は、件数が増えると現実的でなく、継続的な傾向把握にも耐えない。SLA 項目は対応時間の達成状況を示すだけで顧客の主観的な評価は測れず、ナレッジ記事も分析の材料にはならない。実務では、この分析結果を担当者の育成やナレッジの改善へつなげる運用サイクルを設計することが本来の目的である。

正解: A. A. テーブルがモデル駆動型アプリのモバイル対応設定に含まれているか

正解の根拠・詳細解説

カスタムテーブルをモバイルで利用するには、そのテーブルが対象のモデル駆動型アプリのコンポーネントに含まれ、モバイルでの利用が有効になっていることを確認する必要がある。テーブル側にはモバイル向けの有効化設定があり、加えてモバイルで表示するフォームやビューが適切に構成されていること、そしてアプリが発行済みであることが前提となる。オフラインでも利用したい場合は、さらにモバイルオフラインプロファイルを構成し、どのテーブルのどの範囲のデータを端末へ同期するかを定義する必要があり、この設定がないとオフライン時にレコードを参照できない。実務では、オフライン対象を広げすぎると同期に時間がかかり端末の負荷も上がるため、現場が実際に必要とするデータに絞ることが重要である。SLA 項目・重複検出ルール・ナレッジ記事カテゴリは、モバイル対応の可否とは無関係である。

正解: A. A. 既存の標準テーブルで要件を満たせないかを確認した上で、必要な場合のみ新規作成する

正解の根拠・詳細解説

Dynamics 365 Customer ServiceはDataverse上に構築されており、ケースやナレッジ記事、取引先企業・取引先担当者といった標準テーブルには、SLAの計測、自動ルーティング、ケース解決処理、標準レポートなど既製のロジックがあらかじめ紐づいている。標準テーブルに列を追加する形で拡張すれば、これらの機能や将来のプラットフォーム更新の恩恵をそのまま受けられる。一方、要件を精査せずにカスタムテーブルを新設すると、SLAやルーティングに相当する仕組みを自前で作り込む必要が生じ、同じ顧客情報が複数の場所に分散して二重管理やレポートの不整合を招きやすい。したがってまず標準テーブルと標準機能で要件を満たせるかを整理し、どうしても表現できない業務エンティティがある場合に限ってカスタムテーブルを作成するのが定石である。Bのように常に新規作成する方針は保守コストを押し上げる。Cについては標準テーブルはシステム側の構成要素であり削除できない。Dのライセンス再購入もテーブル設計とは無関係である。