第1回 問題集（全般）

正解: A. A. Network Planner

正解の根拠・詳細解説

Network Planner は「設計・見積もり」のためのツールです。Teams 管理センターでネットワークサイト（拠点名・所在地・利用可能な帯域幅）を登録し、そこに所属するユーザー数と、そのユーザーが使う機能（音声通話・会議・Teams ライブイベント・PSTN 通話など）のペルソナを入力すると、必要な帯域幅をレポートとして算出します。ポイントは、実測ではなく入力条件からのシミュレーションだという点です。したがって拠点開設前や大規模展開前の回線サイジング、WAN 増強の稟議資料づくりに使います。混同しやすい選択肢との違い：Network Assessment Tool は実際に対象拠点から Microsoft 365 へパケットを流して品質を測る「実測」ツール、Call Quality Dashboard は運用開始後に蓄積された通話テレメトリを分析する「事後分析」ツールです。Teams Advisor はネットワークではなく Teams 導入プロジェクトのタスク管理を支援する機能です。

正解: B. B. Microsoft Teams Network Assessment Tool

正解の根拠・詳細解説

Microsoft Teams Network Assessment Tool は、対象拠点の PC 上で実行し、Microsoft のリレーサービスに対して実際にメディアトラフィックを流して品質を測定するコマンドラインツールです。取得できるのは、パケットロス率・往復遅延（RTT）・ジッター（遅延のばらつき）といったリアルタイムメディアの品質を左右する指標で、Teams の推奨しきい値（例：パケットロスや遅延の上限）を満たしているかを判定できます。また、そもそも必要なポートやエンドポイントに到達できるかという接続性チェックも兼ねます。Network Planner が「入力条件から必要帯域を見積もる設計ツール」であるのに対し、こちらは「今のネットワークが実際に要件を満たすか」を検証する実測ツールという役割分担です。Call Quality Dashboard は運用開始後の実通話データを集計するもので、導入前の事前検証には使えません。

正解: C. C. UDP 50000〜59999

正解の根拠・詳細解説

Teams のリアルタイムメディア（音声・ビデオ・画面共有）は、遅延に強い UDP を優先して使用し、クライアント側の送信元ポートは 50,000 番台の範囲が使われます。この範囲は QoS 設計上、音声・ビデオ・画面共有で用途ごとに細分化して割り当てるのが定石で、ポート範囲ごとに異なる DSCP 値（音声は EF=46 など）をマークすることで、ネットワーク機器側が音声を最優先で転送できるようになります。UDP 3478〜3481 も Teams には必須ですが、これはクライアントが Microsoft のトランスポートリレー（STUN/TURN）へ接続するための宛先ポートであり、メディアそのもののクライアント側ポート範囲とは役割が異なります。TCP 443 は署名・シグナリングや UDP が塞がれている環境でのフォールバックに使われますが、TCP は再送と輻輳制御によって遅延が増えるため、音声品質の観点からは UDP を必ず開放しておく必要があります。

正解: B. B. エンドユーザーの端末からMicrosoft 365への接続品質を測定すること

正解の根拠・詳細解説

Microsoft 365 ネットワーク接続性テストツールは、実際のユーザー端末（またはその拠点）から Microsoft 365 サービスまでの経路を測定し、遅延・パケットロスに加えて、どこからインターネットへ抜けているか（エグレスポイント）、最寄りの Microsoft ネットワークへ入る front door が適切か、DNS 解決が地理的に正しいかなどを可視化します。これにより「本社まで全トラフィックをバックホールしてから遠隔地のプロキシで出ている」といった、Teams の品質を大きく劣化させる典型的なアンチパターンを検出できます。Microsoft の推奨するネットワーク設計は、Teams のリアルタイムメディアをプロキシや検査装置を経由させず、ユーザーに最も近い拠点からローカルブレイクアウトさせることであり、本ツールはその設計が実現できているかを裏付ける根拠データになります。ライセンス使用状況やチームの削除監視は、それぞれ管理センターのレポートや監査ログの領域で、本ツールの目的ではありません。

正解: A. A. Microsoft 365のライセンス比較ページ

正解の根拠・詳細解説

Teams のセキュリティ・コンプライアンス機能は、Teams 管理センターだけで完結せず、Microsoft Purview や Microsoft Entra ID 側の機能に依存しており、利用可否はユーザーに割り当てられたライセンスプランで決まります。そのため設計の最初の段階で、Microsoft 365 のライセンス比較（プラン別機能一覧）を参照して要件を確認するのが正しい順序です。一般的な傾向として、保持ポリシーや基本的な監査は E3 相当のプランでも利用できる一方、Teams チャットに対する DLP、情報バリア、インサイダーリスク管理、通信コンプライアンスといった高度な機能は E5 相当のプラン、または対応するコンプライアンス系アドオンが必要になります。Azure Portal の課金情報は消費コストの確認、SharePoint／Exchange 管理センターは各ワークロード個別の設定画面であり、いずれも機能の提供可否を判断する一次情報にはなりません。ライセンス不足のまま設計を進めると、ポリシーを作成できてもユーザーに適用されないという事故につながります。

正解: B. B. アラートポリシー

正解の根拠・詳細解説

アラートポリシーは、監査ログに記録されるアクティビティを条件に照らして評価し、一致した場合に指定した管理者へメール通知を送る仕組みです。Microsoft Purview／Microsoft 365 Defender ポータルで作成でき、アクティビティの種類、対象ユーザー、しきい値（一定時間内に何回発生したら通知するか）、通知先、重大度を設定します。既定でも「異常な量のファイル削除」など多数のビルトインポリシーが有効になっており、独自の条件を追加することもできます。Teams の文脈では、ゲストの追加やチームの大量削除、外部共有の急増といった不審な操作を検知するトリガーとして利用します。似た名前の他の選択肢とは目的が異なり、共有ポリシーや会議ポリシーは Teams の機能を「どう使わせるか」を定義するもの、命名ポリシーはチーム名の付け方を統制するものであって、いずれも管理者への通知機能は持ちません。

正解: B. B. Teams Administrator

正解の根拠・詳細解説

最小権限の原則に沿った運用では、業務に必要な範囲だけを持つロールを割り当てます。Teams 管理者（Teams Administrator）は、チームとチャネル、各種ポリシー、会議・通話設定、Teams 対応デバイス、電話番号など Teams サービス全般を管理できる一方、他のワークロードやディレクトリ全体を変更する権限は持たないため、グローバル管理者を配るよりはるかに安全です。さらに細分化されたロールとして、通話・会議のポリシーと電話番号に特化した Teams 通信管理者、通話品質のトラブルシュートのみを行う Teams 通信サポートエンジニア／サポートスペシャリスト（後者は自分に割り当てられた範囲でしか通話情報を見られない）、会議室デバイス管理に特化した Teams デバイス管理者があり、ヘルプデスクにはこれらを割り当てるのが定石です。Exchange 管理者や SharePoint 管理者は、Teams のバックエンドとなるメールボックスやサイトは扱えても、Teams のポリシーそのものは管理できません。

正解: B. B. 脅威ポリシー（Threat Policies）

正解の根拠・詳細解説

Teams を狙ったフィッシングへの対策は、Microsoft Defender for Office 365 の脅威ポリシーで構成します。中核となるのが安全なリンク（Safe Links）と安全な添付ファイル（Safe Attachments）で、これらを Teams に対して有効化すると、チャットやチャネルに投稿された URL がクリック時に再評価され、悪意あると判定されたリンクは警告ページでブロックされます。共有されたファイルについても、サンドボックスでの動的解析によって悪意あるものが検出され、ユーザーからアクセスできない状態にされます。加えて、ユーザーが Teams のメッセージを「セキュリティリスクとして報告」できるようにする設定と、報告先を管理する構成を組み合わせることで、検知から調査までの流れを作れます。会議カスタマイズポリシーや通話キューポリシーは Teams の体験や着信振り分けを定義するもので、脅威検知とは無関係です。

正解: A. A. 保持ポリシー

正解の根拠・詳細解説

保持ポリシーは、コンテンツを一定期間「消させない」ことと、期間経過後に「確実に消す」ことの両方を担う Microsoft Purview の機能です。Teams を対象にする場合の重要な注意点は、Teams のチャットとチャネルメッセージが Exchange や SharePoint とは別個の専用ロケーション（Teams チャット／Teams チャネル メッセージ／Teams プライベート チャネル メッセージ）として指定される点で、Exchange のメールボックスを対象にしただけでは Teams のメッセージは保護されません。また、ユーザーがメッセージを削除しても保持期間中はバックエンドの隠しフォルダーにコピーが残り、eDiscovery で検索可能な状態が維持されます。会議ポリシーや命名ポリシーは Teams の利用方法を制御するもの、アプリ設定ポリシーはアプリの表示を制御するものであり、コンテンツのライフサイクル管理は行いません。

正解: A. A. 感度ラベル（Sensitivity Labels）

正解の根拠・詳細解説

会議に対する感度ラベルは、機密度の高い会議の設定を管理者側で強制するための仕組みです。Microsoft Purview で会議をスコープに含めたラベルを作成し、ロビーのバイパス範囲、誰が発表者になれるか、録画の可否、チャットの可否、そしてエンドツーエンド暗号化の適用といった項目を定義しておくと、ユーザーがそのラベルを会議に適用した瞬間に設定が適用され、主催者が緩い設定へ変更することを防げます。ラベルは会議招待やチーム名に視覚的に表示されるため、参加者に取り扱い区分を伝える効果もあります。ポイントは、会議ポリシーが「そのユーザーが何をできるか」を一律に決めるのに対し、感度ラベルは「その会議がどの機密区分か」に応じて設定を切り替えられる点で、通常業務は標準設定のまま、役員会など一部の会議だけを厳格化する運用が可能になります。

正解: A. A. データ損失防止（DLP）ポリシー

正解の根拠・詳細解説

データ損失防止（DLP）ポリシーは、コンテンツの中身を機微情報の種類（クレジットカード番号、マイナンバー、パスポート番号など）や、キーワード・正規表現・学習済み分類子と突き合わせ、条件に一致した場合にアクションを実行します。Teams を対象にした場合、チャットおよびチャネルメッセージが送信される時点で評価され、外部ユーザーやゲストが含まれる会話では該当メッセージをブロックし、送信者と受信者に「このメッセージはブロックされました」というポリシーヒントを表示できます。ユーザーにビジネス上の理由を申告させて上書きを許可する（オーバーライド）設計や、まずは監査のみでテスト運用する段階的な展開も可能です。情報バリアも通信を止めますが、こちらは中身に関係なく「どのグループ同士は会話してはいけないか」という組織構造に基づく制御であり、機密情報の検出を目的とする本問には合致しません。

正解: A. A. 条件付きアクセス（Conditional Access）ポリシー

正解の根拠・詳細解説

Microsoft Entra の条件付きアクセスは、サインイン時のシグナル（ユーザー／グループ、アプリ、デバイスの準拠状態、IP アドレスや国などの場所、サインインリスク）を評価し、許可・ブロック・多要素認証の要求といった制御を適用します。信頼できるネットワークからのみ許可したい場合は、社内の公衆 IP アドレス範囲を名前付きの場所として登録し、そこ以外からのアクセスをブロックする条件を作成します。実運用で見落としやすいのは、Teams が SharePoint Online と Exchange Online に依存しているため、クラウドアプリとして Teams だけを対象にしても、ファイルや予定表へのアクセス経路が残ってしまう点です。意図した制御を確実にするには、これらの関連アプリも同じポリシーの対象に含める必要があります。また、締め出し事故を避けるため、まずレポート専用モードで影響を確認し、緊急アクセス用の管理者アカウントを除外しておくのが定石です。

正解: A. A. 情報バリア（IB）ポリシー

正解の根拠・詳細解説

情報バリア（Information Barriers）は、法規制や利益相反の観点から接触してはならない組織同士のコミュニケーションを、技術的に成立させないための機能です。ユーザーの属性（部署、役職、カスタム属性など）でセグメントを定義し、セグメント間を「ブロック」または「許可」するポリシーを適用すると、対象ユーザー同士はチャットの送信、通話、会議への招待、画面共有ができなくなり、そもそも相手が検索結果や候補に出てこなくなります。金融機関で調査部門とトレーディング部門を分離する、といったケースが典型例です。DLP との違いが重要で、DLP は「送られる中身」を見て判断するのに対し、情報バリアは中身によらず「誰と誰か」という関係だけで一律に遮断します。保持ポリシーはコンテンツの保存期間を扱うもので、通信の遮断機能は持ちません。

正解: A. A. インサイダーリスク管理（Insider Risk Management）

正解の根拠・詳細解説

インサイダーリスク管理は、組織内部に起因するリスクの兆候を、ユーザーのアクティビティシグナルから検出する Microsoft Purview の機能です。SharePoint や OneDrive からの大量ダウンロード、個人用クラウドストレージや USB へのコピー、機密ラベル付きファイルの外部共有、Teams での外部への持ち出しといった指標を組み合わせ、テンプレート（データ漏えい、退職予定者によるデータ持ち出し、セキュリティポリシー違反など）に沿ってアラートを生成し、調査担当者がケースとして扱えるようにします。人事システムのコネクタを構成して退職予定日を取り込むと、退職通知の前後という高リスク期間に絞った検知ができます。通信コンプライアンスも内部リスク領域の機能ですが、こちらはメッセージ本文の内容をレビューするものであり、ファイルの持ち出し行動そのものの検知とは目的が異なります。既定ではプライバシー配慮のためユーザー名が匿名化表示される点も運用上の特徴です。

正解: A. A. 通信コンプライアンス（Communication Compliance）

正解の根拠・詳細解説

通信コンプライアンスは、Teams のチャットやチャネルメッセージ、メール、および対応するサードパーティのやり取りを対象に、あらかじめ定義した条件に一致した通信をレビュー担当者のキューに提示する Microsoft Purview の機能です。条件には、攻撃的・脅迫的な表現を検出する学習済み分類子、機密情報の種類、キーワード辞書、添付ファイルの有無などを指定でき、対象ユーザーとレビュー担当者、サンプリング率を設定してポリシーを作成します。レビュー担当者はアラートを確認して「解決済み」「通知を送る」「エスカレーション」などの処置を行い、その一連の対応が記録として残るため、ハラスメント調査や規制当局への説明責任に耐える運用ができます。プライバシー保護の観点から、対象ユーザーの範囲は必要最小限にし、レビュー担当者を厳密に限定することが実務上の要点です。DLP は機密情報の外部流出防止が目的で、行為の適切性を人がレビューする仕組みではありません。

正解: A. A. Microsoft 365 E3/E5などのプラン要件

正解の根拠・詳細解説

チームのライフサイクル管理、特に一定期間使われていないチームを自動的に失効させる有効期限ポリシーは、Teams 固有の機能ではなく、その実体である Microsoft 365 グループの機能として提供されます。この機能は Microsoft Entra ID Premium P1 以上を必要とし、P1 は Microsoft 365 E3、P2 は E5 に含まれるため、実務上は E3／E5 などのプラン要件として確認することになります。ライセンスはグループの所有者となるユーザーに必要である点に注意が必要です。有効期限ポリシーを有効にすると、期限が近づいたグループの所有者に更新通知が届き、更新されなければグループが削除されます。削除後は既定で 30 日間の復元期間があり、この間であればチーム、SharePoint サイト、会話をまとめて復元できます。所有者が不在のグループは通知先がなく放置されやすいため、所有者を常に複数人設定しておく運用ルールが重要です。Power BI Pro や Visio、Project のライセンスはこの機能とは無関係です。

正解: A. A. SharePointサイトとOneDrive for Business

正解の根拠・詳細解説

Teams はストレージを自前で持たず、Microsoft 365 の既存ワークロードをバックエンドとして利用します。チームを作成すると対応する Microsoft 365 グループと SharePoint サイトが自動的に作られ、標準チャネルのファイルはそのサイトのドキュメントライブラリ内にチャネル名のフォルダーとして格納されます。プライベートチャネルと共有チャネルは、アクセス範囲が異なるため独立した専用の SharePoint サイトを持ちます。一方、1 対 1 やグループチャットで送信した添付ファイルは、送信者の OneDrive for Business にある専用フォルダーに保存され、会話の相手に自動的に共有リンクが付与されます。この構造を理解しておくと、外部共有の可否は SharePoint／OneDrive 側の共有設定に従うこと、チームを削除すると背後のサイトも削除対象になること、ファイルに対する DLP や保持ポリシーは SharePoint／OneDrive のロケーションで適用されることが説明できます。なお、チャットのメッセージ本文自体はユーザーやグループの Exchange メールボックス内の隠しフォルダーに保管されます。

正解: A. A. 更新ポリシー（Update Policy）

正解の根拠・詳細解説

更新ポリシー（Teams の更新）は、新機能をどのタイミングでユーザーに届けるかをユーザー単位・グループ単位で制御する仕組みです。Teams 管理センターでポリシーを作成し、プレビュー段階の機能を利用可能にするかどうかや、新しい Teams クライアントの展開方針を指定して割り当てます。これにより、情報システム部門や検証部門のユーザーだけが先行して新機能を確認し、問題がないことを確かめてから一般ユーザーへ展開する、という段階的なロールアウトが可能になります。実務上の注意点は、割り当てたポリシーが反映されるまでに時間差があること、そしてクライアント本体のバージョン更新自体は原則として自動で行われ、ユーザーが手動で止めることは想定されていない点です。会議カスタマイズポリシーは会議 UI のブランディング、命名ポリシーはチーム名の統制、ライブイベントポリシーは大規模配信の可否を扱うもので、いずれもクライアント更新の制御には使えません。

正解: A. A. ポリシーパッケージ（Policy Package）

正解の根拠・詳細解説

ポリシーパッケージは、特定の職務や役割に合わせて事前定義された複数種類のポリシー（会議、メッセージング、通話、アプリ セットアップ、ライブイベントなど）を、ひとまとめにしてユーザーへ割り当てる機能です。教育機関の教員・生徒、医療機関の臨床医、フロントラインワーカー、公共安全といった用途別のパッケージが用意されており、個々のポリシーを一つずつ設計・割り当てる手間を大幅に削減できます。運用上の重要な注意点は、パッケージを割り当てるとその中の各ポリシーがユーザーに個別割り当てとして適用されるため、既にそのユーザーへ手動で割り当てていた同種のポリシーは上書きされることです。また、パッケージ内の個別ポリシー設定は組織の要件に合わせてカスタマイズでき、変更はそのパッケージが割り当てられた全ユーザーに反映されます。条件付きアクセスグループや DLP テンプレートは、それぞれ認証制御と情報保護の領域であり、Teams のポリシー束ね機能ではありません。

正解: A. A. Teams管理センターまたはPowerShellでのポリシー割り当て

正解の根拠・詳細解説

Teams のポリシーは、Teams 管理センターの GUI から個々のユーザーに割り当てるほか、Teams PowerShell モジュールのコマンドレットでも操作できます。代表的なのはポリシー種別ごとの Grant-CsTeamsMeetingPolicy、Grant-CsTeamsMessagingPolicy、Grant-CsTeamsCallingPolicy といった Grant-Cs 系コマンドレットで、-Identity にユーザーを、-PolicyName にポリシー名を指定します。大規模組織では 1 人ずつの割り当ては現実的でないため、セキュリティグループや Microsoft 365 グループに対して割り当てるグループ単位のポリシー割り当てや、多数のユーザーをまとめて処理するバッチ割り当てが用意されています。グループ割り当てには優先順位（ランク）があり、ユーザーが複数グループに属する場合はランクの高いポリシーが適用されます。優先順位は、ユーザーへの直接割り当てが最も強く、次にグループ割り当て、最後に組織全体の既定ポリシーという順に評価される点が重要です。Exchange や SharePoint の管理センター、Azure のコスト管理からは Teams のポリシーを割り当てられません。

正解: A. A. グループ作成の制限設定（Restrict group creation）

正解の根拠・詳細解説

Teams のチームは実体が Microsoft 365 グループであるため、チームの乱立を抑えたい場合は Teams 側ではなく Microsoft Entra ID のグループ設定でグループ作成を制限します。具体的には、作成を許可するユーザーを入れたセキュリティグループをあらかじめ用意し、ディレクトリ設定でグループ作成の全体許可をオフにしたうえで、そのセキュリティグループを作成許可対象として指定します。設定は PowerShell（Microsoft Graph PowerShell）で行うのが一般的です。重要な副作用として、この制限は Teams だけでなく Outlook、Planner、SharePoint、Yammer など Microsoft 365 グループを作成するすべての入り口に一律で効く点があり、業務部門から「Planner の計画が作れなくなった」といった問い合わせが出やすいため、事前告知と申請フローの整備が必須です。なお、グローバル管理者やグループ管理者などの特権ロールは制限の対象外で引き続き作成できます。命名ポリシーは名前の付け方を統制するだけで、作成そのものは止められません。

正解: A. A. 有効期限ポリシー（Expiration Policy）

正解の根拠・詳細解説

有効期限ポリシーは、放置されたチームが増え続けて検索性やガバナンスを損なう問題に対処するための Microsoft 365 グループの機能です。有効期間（例：180 日）を設定すると、期限が近づいたグループの所有者へ更新を促すメール通知が送られ、所有者が更新しなければグループが削除されます。実務上重要なのは自動更新の挙動で、Teams でのチャネル投稿や訪問、SharePoint サイトでのファイル操作、Outlook でのグループメールの閲覧といったアクティビティがあれば、所有者の操作がなくても自動的に期限が延長されるため、実際に使われているチームが誤って消える可能性は低く抑えられています。削除されても既定で 30 日間は復元可能ですが、所有者が退職などで不在のグループは通知が届かず失われやすいため、所有者を複数設定しておく運用が推奨されます。この機能の利用には Microsoft Entra ID Premium P1 相当のライセンスが必要です。

正解: A. A. 命名ポリシー（Naming Policy）のブロック単語リスト

正解の根拠・詳細解説

命名ポリシーは Microsoft 365 グループに対して適用される機能で、二つの要素から構成されます。一つはプレフィックス・サフィックスによる規則付けで、固定文字列や、部署・国といったユーザー属性を差し込んで「営業部_プロジェクトA_JP」のような統一された名前を自動生成します。もう一つが本問のブロック単語リストで、組織が指定した不適切語や、経営会議・人事などの誤用されたくない単語を含む名前でのチーム作成・名称変更を拒否します。ブロック単語は完全一致した語に対して評価される仕組みで、リストはカンマ区切りでまとめて登録します。この機能も Microsoft Entra ID Premium P1 相当のライセンスを必要とし、Teams だけでなく Outlook や Planner など、グループを作成するすべての経路に適用されます。特権ロールを持つ管理者はポリシーの対象外となる点も押さえておくとよいでしょう。DLP は名前ではなくコンテンツの中身を評価する機能であり、命名の統制には使えません。

正解: A. A. チームのアーカイブ（Archive）

正解の根拠・詳細解説

アーカイブは、活動が終了したプロジェクトのチームを「記録として残しつつ、これ以上変更させない」ための操作です。アーカイブされたチームでは、新規メッセージの投稿やファイルの編集ができなくなりますが、過去の会話・ファイル・タブの内容はそのまま参照でき、検索や eDiscovery の対象にもなります。Teams 管理センターまたはチームの管理画面から実行でき、アーカイブ時にオプションとして紐づく SharePoint サイトも読み取り専用にするかどうかを選べます。必要になればアーカイブ解除でいつでも元の状態に戻せる点が、削除との決定的な違いです。削除の場合は既定で 30 日を過ぎると完全に失われ、有効期限ポリシーは自動的に削除へ向かう仕組みであるため、いずれも「一時的に凍結する」という要件には合致しません。メンバーシップの削除は権限を外すだけで、コンテンツの改変を防ぐものではありません。

正解: A. A. Microsoft Entra管理センターでの削除済みグループの復元

正解の根拠・詳細解説

チームを削除すると、背後の Microsoft 365 グループが論理削除（ソフトデリート）状態になり、既定で 30 日間は復元可能な状態で保持されます。この期間内であれば、Microsoft Entra 管理センターの削除済みグループの一覧、または Microsoft Graph PowerShell の復元コマンドレットからグループを復元でき、これに連動してチーム、チャネル構成、SharePoint サイトとその中のファイル、グループメールボックスがまとめて元に戻ります。Teams のクライアント上でチームが再び見えるようになるまでには時間差が生じることがあります。注意点として、30 日を過ぎると完全削除となり、この手段では復旧できません。また、プライベートチャネルなど個別に削除された要素には別の保持期間が設定される場合があります。Teams 管理センターや SharePoint 管理センターで新規に作り直しても、それは名前が同じだけの別リソースであり、元のコンテンツや権限は戻りません。

正解: A. A. アクセスレビュー（Access Reviews）

正解の根拠・詳細解説

アクセスレビューは、付与されたアクセス権が今も業務上必要かどうかを定期的に棚卸しさせる Microsoft Entra ID ガバナンスの機能です。対象にチームやその実体である Microsoft 365 グループを指定し、レビュー担当者をグループ所有者、メンバー本人（セルフレビュー）、または指定した管理者から選んで、四半期ごとなど繰り返し実行するようスケジュールできます。レビュー担当者が「不要」と判断した、あるいは期限までに応答がなかった場合の既定動作として、メンバーを自動的に削除する設定にすれば、権限の棚卸しが手作業に依存しなくなります。特にゲストユーザーだけを対象にしたレビューは、プロジェクト終了後も残り続ける外部アカウントを整理する定番の使い方です。この機能の利用には Microsoft Entra ID Governance または Entra ID P2 相当のライセンスが必要である点に注意してください。DLP や情報バリアはコンテンツや通信を制御するもので、権限の定期見直しは行いません。

正解: A. A. PowerShellとMicrosoft Graph

正解の根拠・詳細解説

Teams の大規模な管理作業を自動化する手段は主に二つあります。一つは Microsoft Teams PowerShell モジュールで、New-Team や Add-TeamUser、各種 Grant-Cs 系コマンドレットによってチーム作成、メンバー追加、ポリシー割り当てを一括処理でき、CSV を読み込んで繰り返す運用スクリプトが書きやすいのが利点です。もう一つが Microsoft Graph API で、REST として呼び出せるため、Power Automate や Azure Functions、独自アプリケーションからの組み込みに向いており、チームのテンプレートを JSON で指定して一括作成することもできます。実務ではまず PowerShell で管理者が対話的に処理し、恒常的な自動化やセルフサービス申請フォームとの連携が必要になった段階で Graph API を採用する、という使い分けが一般的です。いずれも、アプリケーション権限を使う場合は必要最小限のスコープに絞り、実行アカウントの権限管理を厳格にすることが重要です。

正解: A. A. 外部共有機能はライセンスに関係なく既定で利用可能だが組織設定で制御する

正解の根拠・詳細解説

外部共有そのものは Microsoft 365 の標準機能であり、有効化のために追加ライセンスを購入する必要はありません。制御は組織レベルの設定で行い、SharePoint 管理センターの共有設定で「だれでも（Anyone、認証不要のリンク）」「新規および既存のゲスト」「既存のゲストのみ」「組織内のユーザーのみ」といった段階から選択します。OneDrive については SharePoint と同じかそれより厳しい範囲しか選べません。実務上の重要な原則は、サイト単位の設定は組織全体の設定より緩くはできないという階層関係で、組織全体を「既存のゲストのみ」にすると、個別サイトで「だれでも」を選ぶことはできなくなります。したがって、まず組織レベルで許容できる最大値を決め、そのうえで機密度の高いサイトだけを個別に厳格化する、という順序で設計します。Teams のファイルは SharePoint 上に保存されるため、この設定がそのままチームのファイル共有可否に反映されます。

正解: A. A. Teams管理センターの外部アクセス設定

正解の根拠・詳細解説

Teams 管理センターの外部アクセス（External access、フェデレーション）は、他組織の Teams ユーザーや Skype ユーザーと、チャット・通話・会議を行えるようにするための組織レベル設定です。ここで重要なのはゲストアクセスとの違いで、外部アクセスの相手は自組織のテナントにアカウントを持たず、あくまで自分の組織に所属したまま相手先ドメインの ID で通信します。そのためチームやチャネルのメンバーになることはできず、コミュニケーションはチャットや通話に限られます。一方ゲストアクセスは、外部ユーザーを自テナントにゲストアカウントとして登録し、チームのメンバーとしてチャネルやファイルへ参加させる仕組みです。「相手とチャットしたいだけ」なのか「チームに入れて共同作業させたい」のかで、どちらを構成すべきかが決まります。Exchange や SharePoint の管理センターにはこのフェデレーション設定はありません。

正解: A. A. 許可ドメインリストへの追加

正解の根拠・詳細解説

外部アクセスの制御は、Teams 管理センターの外部アクセス設定でドメイン単位のリストを作ることで行います。運用モードは大きく二通りで、特定のドメインだけを許可リストに登録すると、リストに載っていないすべてのドメインが自動的にブロックされる「原則禁止・例外許可」の動作になります。逆に、ブロックリストに登録したドメインだけを拒否し、それ以外は許可する「原則許可・例外禁止」の運用も選べます。取引先とのみ連携させたいというセキュリティ要件では前者を採用します。注意点として、この設定は組織全体に適用されるため部署ごとに変えることはできず、また相手組織側でも自分のドメインが許可されている必要があり、双方の設定が一致して初めて通信が成立します。設定変更が全ユーザーに行き渡るまでには時間がかかる場合があるため、テストは反映を待ってから行います。

正解: A. A. Microsoft Entra IDの外部コラボレーション設定でゲストアクセスを有効化

正解の根拠・詳細解説

ゲストアクセスは二つのレイヤーの設定が揃って初めて機能します。土台となるのが Microsoft Entra ID の外部コラボレーション設定で、ここでゲストを招待できるかどうか、誰が招待できるか（管理者のみ、特定ロール、全メンバー）、ゲストが自分以外のディレクトリ情報をどこまで参照できるかを定義します。その上に Teams 管理センターのゲストアクセス設定があり、ゲストが Teams でチャットや通話、画面共有、会議を利用できるかを個別に許可します。土台側で招待が禁止されていると、Teams 側をいくら有効にしてもゲストは追加できません。さらに、ゲストがチームのファイルを開けるかどうかは SharePoint／OneDrive の外部共有設定にも依存するため、実務では三箇所の整合を確認する必要があります。設定変更の反映には時間差があるため、有効化直後に招待が通らなくても、しばらく待ってから再試行するのが定石です。

正解: A. A. Microsoft Purviewの機密性ラベルとMicrosoft Entra IDの設定の組み合わせ

正解の根拠・詳細解説

組織全体のゲストアクセス設定は一律にしか効かないため、チームごとに外部ユーザーの可否を変えたい場合は、Microsoft Purview の感度ラベル（グループとサイトをスコープに含めたラベル）を利用します。ラベルの設定項目には外部ユーザーのアクセス可否があり、「所有者が Microsoft 365 グループにゲストを追加できるかどうか」をラベル単位で指定できます。これを機能させるには、Microsoft Entra ID のグループ設定でラベルによる制御を有効化しておく必要があります。運用としては、「社外秘（ゲスト不可）」と「パートナー共有可（ゲスト可）」のようなラベルを用意し、チーム作成時に利用者自身が適切なラベルを選ばせる形にすると、管理者が個別に介入せずともガバナンスが効きます。ラベルはチーム名の横に表示されるため、参加者がそのチームの取り扱い区分を意識できる副次的な効果もあります。DLP や命名ポリシー単独では、この種のアクセス制御は実現できません。

正解: A. A. Microsoft Entra管理センターでのゲストユーザー削除

正解の根拠・詳細解説

ゲストユーザーは、招待された時点で自テナントの Microsoft Entra ID にゲスト種別のユーザーオブジェクトとして登録され、各チームのメンバーシップはそのオブジェクトを参照しています。したがって Microsoft Entra 管理センターでゲストユーザーアカウントを削除すれば、参加していたすべてのチーム、チャネル、および共有されていた SharePoint／OneDrive のリソースへのアクセス権が一括で失効します。チームを一つずつ開いてメンバーを外して回る必要はありません。実務では、契約終了が確定していない段階ではまずサインインをブロックして即時にアクセスを遮断し、監査要件を確認したうえで削除する、という二段構えが安全です。恒常的な運用としては、ゲストのみを対象にしたアクセスレビューを定期実行し、レビューされなかったゲストを自動削除する仕組みを組んでおくと、退職者や契約終了者のアカウントが放置される事態を防げます。削除後も一定期間は復元可能な状態で保持されます。

正解: A. A. 共有チャネル（Shared Channels）

正解の根拠・詳細解説

共有チャネルは、Microsoft Entra の B2B ダイレクトコネクトを基盤とする機能で、外部組織のユーザーを自テナントのゲストとして登録することなく、特定のチャネルだけに参加させられます。外部ユーザーは自分の所属組織の ID とクライアントのまま、テナントを切り替えずにそのチャネルへアクセスでき、見えるのは共有されたチャネルとその専用 SharePoint サイトの中身だけです。親チームの他のチャネルやファイル、組織のディレクトリ情報には一切アクセスできません。プライベートチャネルとの違いは対象範囲で、プライベートチャネルは親チームのメンバーの一部に限定して非公開にする仕組みであり、外部組織のユーザーを直接参加させる用途には使えません。実務上の注意として、B2B コラボレーションで招待した従来型のゲストアカウントは共有チャネルに追加できず、双方のテナントでクロステナントアクセス設定を構成しておく必要があります。

正解: A. A. B2B direct connectのクロステナントアクセス設定

正解の根拠・詳細解説

共有チャネルによる外部組織との接続は、Microsoft Entra ID のクロステナントアクセス設定にある B2B ダイレクトコネクトで制御します。ここでは組織ごとに受信（相手の組織のユーザーを自組織の共有チャネルに参加させる）と送信（自組織のユーザーが相手の共有チャネルに参加する）を個別に設定でき、さらに対象を特定のユーザーやグループ、特定のアプリケーションに絞り込めます。既定ではすべてブロックされているため、接続したい相手組織をテナント ID で登録し、明示的に許可する必要があります。重要なのは、この設定が双方向の合意制であることで、自社が許可していても相手組織側が許可していなければ接続は成立しません。また、信頼設定として相手組織で実施された多要素認証や、デバイスの準拠状態を自組織の条件付きアクセスで信頼するかどうかを指定でき、これを有効にしないと外部ユーザーが自組織の MFA 要求を満たせず接続に失敗するという典型的なトラブルが起きます。

正解: A. A. マルチテナント組織（MTO）

正解の根拠・詳細解説

マルチテナント組織（MTO）は、企業グループや買収後の統合期間など、複数の Microsoft 365 テナントを残したまま利用者には一つの組織のように見せたい場合に用いる Microsoft Entra ID の機能です。参加するテナント同士でクロステナント同期を構成し、相手テナントのユーザーを自テナントへ B2B のメンバー種別ユーザーとして自動的に複製することで、グローバルアドレス一覧に相手グループ会社の社員が表示され、社内同様に検索・チャット・会議への招待ができるようになります。テナントの完全な統合（マイグレーション）を伴わずに従業員体験を統一できる点が価値です。共有チャネルは「特定のチャネルだけを共有する」局所的な仕組み、B2B コラボレーションは「外部の人をゲストとして招く」仕組みであり、いずれも組織全体を一体として見せる用途には向きません。導入時はライセンス要件と、同期対象ユーザーの範囲・属性マッピングの設計を事前に確認する必要があります。

正解: A. A. Microsoft 365管理センターのライセンス割り当て画面

正解の根拠・詳細解説

Teams Phone で電話番号を付与するには、まず対象ユーザーに適切なライセンスが割り当てられている必要があり、その割り当て状況は Microsoft 365 管理センターのライセンス画面で確認・変更します。基本構成は、PSTN 接続機能の土台となる Teams Phone のライセンスに加えて、PSTN 接続方式に応じた要素を組み合わせる形です。Microsoft の通話プランを使う場合は国内・国際通話プランのライセンスを追加購入し、Microsoft から電話番号を取得します。一方、既存の電話回線や SBC を活用するダイレクトルーティング、あるいは通信事業者と契約する Operator Connect の場合は、通話プランのライセンスは不要で、番号は事業者側から供給されます。よくあるつまずきは、ライセンスを付与した直後は Teams 管理センターの電話番号割り当て画面にユーザーが表示されないことで、反映まで一定の時間を要します。SharePoint や Exchange の管理画面にライセンス情報はありません。

正解: A. A. リソースアカウント

正解の根拠・詳細解説

Teams Rooms などの会議室デバイスには、人間のユーザーではなくリソースアカウントを割り当てます。これは Exchange 上の会議室メールボックスと、Teams Rooms 用のライセンスを組み合わせたアカウントで、これにより会議室が予定表から予約可能な対象として一覧に表示され、デバイス側では自分宛ての会議招待をコンソールに表示してワンタッチで参加できるようになります。構成上の要点は、メールボックスの予定表処理を自動応答するよう設定し、会議の件名や開催者情報がコンソールに表示されるよう調整すること、そしてパスワードの有効期限が切れてデバイスがサインアウトされないよう運用ルールを決めておくことです。なお、リソースアカウントは自動応答（オートアテンダント）や通話キューにも使われますが、その場合は Microsoft Teams 電話リソースアカウントのライセンスを割り当てるという別の用途になります。汎用のサービスアカウントやゲストアカウントでは、会議室としての予約や予定表連携が成立しません。

正解: A. A. 構成プロファイル（Configuration Profiles）

正解の根拠・詳細解説

構成プロファイルは、Teams 管理センターの Teams デバイスから作成し、同種のデバイス群へ共通設定を一括適用する仕組みです。デバイスの種類（Teams 電話機、Teams Rooms、パネル、ディスプレイなど）ごとにプロファイルを作り、言語やタイムゾーン、表示・スクリーンセーバーの動作、デバイスロックの PIN、ネットワーク関連の設定などを定義したうえで、対象デバイスに割り当てます。これにより、会議室が数十・数百に及ぶ環境でも、現地に赴いて一台ずつ設定する必要がなくなり、設定の一貫性も保てます。運用上は、拠点や用途（役員会議室と一般会議室など）でプロファイルを分けておくと、要件差分を管理しやすくなります。割り当てた設定はデバイスがサービスにチェックインしたタイミングで反映されるため、即座に変わるわけではない点に注意してください。命名ポリシーやアプリ セットアップ ポリシーはユーザー向けの設定であり、デバイスには適用されません。

正解: A. A. デバイス設定とファームウェア管理

正解の根拠・詳細解説

Teams 管理センターのデバイスセクションでは、登録済みの Teams 認定デバイスを一覧で管理でき、各デバイスのファームウェアやアプリのバージョン、正常性、サインイン状態を確認できます。更新については、利用可能な新バージョンを個別のデバイスへ手動で適用するほか、更新を自動で適用するか、あるいは最新版から一定期間遅らせて段階的に展開するかといった方針を設定でき、業務時間を避けた時間帯に実行するようスケジュールすることも可能です。実務では、まず検証用の数台に先行適用して問題がないことを確認してから全社展開する、という運用が推奨されます。デバイスがオフラインだったり、必要なエンドポイントへ到達できないネットワークに置かれていると更新が適用されないため、更新が滞っているデバイスの一覧を定期的に確認することもトラブル予防につながります。保持ポリシーや会議テンプレートはデバイス管理とは無関係の設定です。

正解: A. A. デバイスタグ（Device Tags）

正解の根拠・詳細解説

デバイスタグは、Teams 管理センターに登録された Teams 認定デバイスに対して、任意のラベルを付けて論理的にグループ化する機能です。「東京本社」「3F 会議室」「営業部」といった拠点・部署・用途を表すタグを付けておくと、デバイス一覧をタグで絞り込めるようになり、その絞り込み結果に対して構成プロファイルの割り当てやファームウェア更新、再起動といった操作をまとめて実行できます。台数が増えるほど、機種名やシリアル番号だけの一覧から目的のデバイスを探すのは非現実的になるため、導入時にタグ付けの命名規則を決めておくことが運用効率を大きく左右します。レポートやアラートもタグ単位で見られるため、特定拠点だけ通話品質が悪いといった傾向の切り分けにも役立ちます。命名ポリシーはチーム名、アクセスレビューは権限の棚卸し、DLP は情報保護の機能であり、いずれもデバイスの分類には関与しません。

正解: A. A. リモートサインイン用のプロビジョニング機能

正解の根拠・詳細解説

Teams 認定デバイスのリモートサインイン（リモートプロビジョニング）は、管理者が現地に出向かず、また会議室アカウントの資格情報をデバイスの画面で直接入力させることなくサインインを完了させるための仕組みです。手順としては、デバイス側で別デバイスからのサインインを選ぶと確認コードが表示されるので、管理者が Teams 管理センターのデバイス画面でそのコードを使ってデバイスを登録し、割り当てたいアカウントを指定してリモートでサインインを実行します。これにより、複数の会議室デバイスを一箇所からまとめてセットアップでき、現場作業者にアカウントのパスワードを渡す必要もなくなるためセキュリティ上も有利です。実務上の注意として、コードには有効期限があるため、表示から時間が経ちすぎると失敗します。またデバイスがインターネットに到達できることが前提であり、ネットワーク側の許可設定を先に済ませておく必要があります。

正解: A. A. Teams向けのVDI最適化機能（メディアのオフロード等）を有効化する

正解の根拠・詳細解説

仮想デスクトップ環境では、既定のままだと音声・ビデオのメディア処理が仮想マシン側で行われ、そのうえで映像・音声が画面転送プロトコルに載って端末へ運ばれるため、遅延やエコー、サーバー側の CPU 逼迫といった品質問題が起きます。これを解消するのが Teams の VDI 最適化で、シグナリングは仮想マシン上の Teams が担いつつ、メディアストリームだけはユーザーの手元の端末と Microsoft のサービスとの間で直接やり取りさせる（ローカルへのオフロード）構成にします。実現には、利用している VDI 基盤（Azure Virtual Desktop、Citrix、VMware など）に対応した最適化コンポーネントやリダイレクト機能を端末側にインストールし、Teams を VDI 環境として動作させる設定を行う必要があります。最適化が効いているかは Teams クライアントの端末情報から確認できます。デスクトップ版と同じ設定のまま使う、あるいは Web 版で代替するといった対応では、この根本的なメディア経路の問題は解決しません。

正解: A. A. グローバル（組織全体）ポリシー設定

正解の根拠・詳細解説

Teams の各ポリシー種別には Global（組織全体の既定）という名前のポリシーが必ず存在し、個別のポリシーを割り当てられていないすべてのユーザーに自動的に適用されます。したがって、テナントの既定動作を変えたい場合はこの Global ポリシーの設定値を編集するのが最も影響範囲の広い操作となり、例外的な部署にだけカスタムポリシーを作って割り当てる、という設計が基本形になります。理解しておくべきなのが適用の優先順位で、ユーザーへの直接割り当てが最も強く、次にグループ単位の割り当て（複数該当する場合はランクの高いもの）、いずれもなければ Global が適用されます。実務でよくある誤解は、Global を厳しくすれば全員に効くはずだ、というもので、既に個別ポリシーが割り当てられているユーザーには Global の変更が反映されません。設定変更が意図通りに効いているかは、対象ユーザーの有効なポリシーを確認して検証します。

正解: A. A. Teams Roomsの使用状況レポート

正解の根拠・詳細解説

Teams 管理センターの分析とレポートには、会議室デバイスの利用状況を把握するためのレポートが用意されており、デバイスごとの会議開催数、参加者数、利用時間といった指標を期間指定で確認できます。これを集計すれば、常に埋まっている会議室と、ほとんど使われていない会議室を数値で示せるため、増設投資の根拠づけや、レイアウト変更・用途変更の判断材料として経営層に提示できます。レポートは CSV としてエクスポートできるため、他の資産情報と突き合わせた分析も可能です。より詳細な稼働率分析や、デバイスの正常性を含めた運用管理が必要な場合は、Teams Rooms Pro の管理ポータルを併用します。DLP インシデントレポートや保持ラベルレポートはコンプライアンス領域、アクセスレビューのレポートは権限棚卸しの結果であり、会議室の稼働状況を示すものではありません。

正解: A. A. グループに対するアプリセットアップポリシーの個別割り当て

正解の根拠・詳細解説

Teams のアプリ関連ポリシーは、テナント全体の既定に加えて、ユーザー個別またはセキュリティグループ単位で割り当てられます。そのため「特定部署だけ制限したい」という要件には、対象部署のグループに専用のポリシーを作成して割り当て、それ以外は既定のままにする、という設計で対応します。アプリ セットアップ ポリシーでは、カスタムアプリ（組織が独自に開発・アップロードするアプリ）のアップロードやインストールを許可するか、どのアプリをアプリバーにピン留めするか、ユーザー自身がピン留めを変更できるかを制御します。個々のアプリ単位で利用可否を許可・ブロックする制御はアプリのアクセス許可（アプリ管理）側の設定で行うため、実務では両者を組み合わせて設計します。グループ割り当てを使う際は、ユーザーへの直接割り当てのほうが優先されること、複数グループに所属する場合はランクの高い割り当てが勝つことを踏まえて優先順位を設計してください。

正解: A. A. 最小権限の原則に基づきリスクを分散するため

正解の根拠・詳細解説

管理者ロールを分散する目的は、権限の集中に起因するリスクを下げることにあります。グローバル管理者はテナント内のあらゆる設定を変更でき、そのアカウントが侵害されれば攻撃者は全ワークロードを自由に操作できてしまいます。そこで、Teams の運用担当には Teams 管理者、通話やポリシーだけを扱う担当には Teams 通信管理者、通話品質の調査だけを行うヘルプデスクには Teams 通信サポートエンジニアやサポートスペシャリスト、会議室機器の担当には Teams デバイス管理者、というように業務範囲に対応したロールを割り当てます。これにより、侵害時の被害範囲が限定されるだけでなく、操作ミスによる広範な設定変更事故も防げます。さらに実務では、特権ロールに対して多要素認証と条件付きアクセスを必須にし、必要なときだけ昇格させる Privileged Identity Management を併用するのが定石です。管理コストやライセンス消費を増やすことは目的ではありません。

正解: A. A. 法的ホールド（Litigation Hold）または保持ポリシー

正解の根拠・詳細解説

退職予定者のように、特定の個人のデータを確実に残す必要がある場合は、そのユーザーを対象としたホールドを適用します。Teams のチャットメッセージは実体としてユーザーの Exchange メールボックス内の隠しフォルダーに保管されるため、メールボックスに訴訟ホールド（Litigation Hold）を適用すれば、本人が削除操作をしてもコンテンツは回復可能な状態で保持され続けます。より限定的に、特定の調査案件に関係する範囲だけを対象にしたい場合は、eDiscovery のケースに紐づくホールドを使います。組織的・恒常的な要件であれば、Microsoft Purview の保持ポリシーで Teams チャットとチャネルメッセージのロケーションを指定して一括適用するほうが管理しやすくなります。運用上の重要な注意点として、ホールドが適用されたユーザーのライセンスを外してアカウントを削除しても、メールボックスは非アクティブメールボックスとして残り、後から検索できます。ホールド解除の判断は法務部門と合わせて行います。

正解: A. A. Microsoft Purviewの監査ログまたはレポート機能の活用

正解の根拠・詳細解説

チームの作成・削除といった管理イベントを体系的に追跡するには、Microsoft Purview の監査ログを利用します。Teams のアクティビティは監査ログに記録されており、アクティビティの種類（チームの作成、チームの削除、メンバーの追加、設定変更など）、実行ユーザー、対象、日時を条件に検索でき、結果を CSV としてエクスポートして定期レポート化できます。Microsoft Graph の監査 API を使えば、SIEM への取り込みや自動集計も可能です。あわせて Teams 管理センターの利用状況レポートを見れば、チーム数やアクティブなチームの推移といった全体傾向を把握できます。実務上の注意点として、監査ログの保持期間はライセンスによって異なり、標準では一定期間を過ぎたログは検索できなくなるため、長期保存が必要なら定期的にエクスポートするか、より長い保持を提供するプランやログ基盤への転送を検討します。手動記録やヒアリングでは網羅性と正確性を担保できません。

正解: A. A. 業務上の必要性を評価し最小限の範囲で外部アクセスを許可する

正解の根拠・詳細解説

外部コラボレーションの設定は、全面禁止と全面許可のどちらにも問題があります。全面禁止は取引先とのやり取りを個人メールや無償のチャットサービスへ追いやり、かえって統制の効かない経路を生みます。逆に全面許可は、なりすましやフィッシング、情報漏えいのリスクを不必要に広げます。推奨されるのは、まず「どの部門が、どの相手と、何をする必要があるのか」という業務要件を洗い出し、それを満たす最小限の構成を選ぶアプローチです。具体的には、チャットや通話だけで足りるなら外部アクセス（フェデレーション）を許可ドメインリスト方式で特定の取引先だけに絞り、チームへの参加が必要ならゲストアクセスを有効にしたうえで招待できる人を限定し、特定チャネルだけの共有で済むなら共有チャネルとクロステナントアクセス設定を使います。あわせて条件付きアクセス、DLP、ゲスト向けのアクセスレビューを組み合わせ、許可した範囲を継続的に監視・棚卸しすることが重要です。既定値のまま放置するのは、意図せぬ設定を許容していることと同じで適切ではありません。

正解: A. A. Advisor for Teams

正解の根拠・詳細解説

Advisor for Teams は、Teams の展開そのものを設定するツールではなく、導入プロジェクトを進めるためのガイドとして機能します。チャットとチーム、会議、Teams Phone といった導入したいワークロードを選ぶと、それに応じた推奨タスクの一覧が提示され、Planner ベースの計画としてタスクが自動生成されるため、誰がいつまでに何をやるかを追跡できます。あわせて、テナントの現在の構成が前提条件を満たしているか（必要なライセンスや、Exchange・SharePoint の構成など）を自動で評価し、不足があれば警告してくれます。役割の違いを整理すると、Network Planner は帯域の見積もり、Call Quality Dashboard は運用開始後の品質分析、デバイスタグはデバイス管理のための分類であり、いずれも導入計画そのものの進行管理を担うものではありません。展開フェーズごとの抜け漏れ防止という観点で位置づけを覚えておくとよいでしょう。

正解: A. A. New-Team

正解の根拠・詳細解説

Teams PowerShell モジュールの New-Team コマンドレットは、チームとその実体である Microsoft 365 グループをまとめて新規作成します。-DisplayName でチーム名、-Description で説明、-Visibility で Public か Private かを指定し、-Owner で所有者を、-Template で使用するテンプレートを指定できます。作成後は Add-TeamUser でメンバーや所有者を追加し、New-TeamChannel でチャネルを作成する、という流れで一括構築します。CSV に部署名やプロジェクト名を並べて繰り返し処理すれば、数十・数百のチームを短時間で標準化された構成のまま作成できるため、新年度の一斉展開などで威力を発揮します。他の選択肢はいずれも別領域のコマンドレットで、New-CsTeamsPolicy のような Cs 系はポリシー操作、New-MailContact と New-DistributionGroup は Exchange のメール宛先を扱うものであり、チームは作成されません。実行にはあらかじめ Connect-MicrosoftTeams で接続しておく必要があります。

正解: A. A. 既存のファイル・権限構造をそのまま引き継げる

正解の根拠・詳細解説

SharePoint のチームサイトで既に資料や運用が回っている場合、新しくチームを作って中身を移行するのは手間もリスクも大きくなります。既存サイトからチームを作成（サイトに Teams を追加）すると、そのサイトがチームのバックエンドとしてそのまま使われるため、既存のドキュメントライブラリやフォルダー構成、リンクの URL、設定済みの権限をそのまま引き継いだ状態で会話機能を追加できます。利用者から見れば「今まで通りのファイル置き場に、チャットとチャネルが増えた」という自然な移行になります。注意点として、この操作が使えるのは Microsoft 365 グループに接続できるチームサイトであり、コミュニケーションサイトなど一部のサイト種別は対象外です。また、サイト固有に細かく設定した権限とチームのメンバーシップは概念が異なるため、追加後に権限の整合を確認しておく必要があります。ライセンス不要になる、チャネル数が無制限になる、といった効果はありません。

正解: A. A. チームテンプレートを使用する

正解の根拠・詳細解説

チームテンプレートは、チャネル構成、各チャネルに配置するタブやアプリ、チームの設定を定義済みのひな型としてまとめたもので、テンプレートを選んでチームを作成すると、その構成が最初から出来上がった状態になります。Microsoft が提供する既定のテンプレート（プロジェクト管理、従業員のオンボーディング、小売店舗、病院の病棟など、業種・用途別）に加えて、組織独自のカスタムテンプレートを作成することもできます。テンプレートを標準化しておくと、部署ごとにチャネルの切り方や使うアプリがばらばらになるのを防げ、利用者は毎回ゼロから設計する必要がなくなります。理解しておくべき点として、テンプレートに含まれるのは構造であり、メンバーやファイルなどの中身はコピーされません。既存のチームを丸ごと複製したい場合は、そのチームをテンプレート化してから使うか、別途コピー手段を検討します。チャネルを一つずつ手作業で作る方法は、標準化にも速度にも劣ります。

正解: A. A. テンプレートポリシー（Template Policy）

正解の根拠・詳細解説

組織独自に作成したカスタムのチームテンプレートは、既定ではテンプレート一覧に並んで誰でも選べる状態になります。特定の部署にだけ使わせたい、あるいは不要なテンプレートを見せたくないという場合に使うのが、Teams 管理センターのテンプレート ポリシーです。ポリシーごとに、非表示にするテンプレートを指定して作成し、対象のユーザーやグループへ割り当てると、そのユーザーがチームを作成する際のテンプレート選択肢が絞り込まれます。たとえば店舗運営用のテンプレートは小売部門だけに見せ、本社スタッフには表示しない、といった制御ができます。他のポリシーと同様に組織全体の既定ポリシーが存在し、個別割り当てがなければそれが適用されます。テンプレート ポリシーはあくまで表示の制御であり、テンプレートの中身（チャネルやアプリの構成）そのものはテンプレート側で定義する、という役割分担を押さえておきましょう。

正解: A. A. Teams管理センターまたはTeamsクライアントのメンバー管理画面

正解の根拠・詳細解説

チームのメンバーシップと役割の管理は、Teams 管理センターの各チームの詳細画面、または Teams クライアント上でチームの「メンバーを管理」から行います。役割は所有者、メンバー、ゲストの三種類で、所有者はメンバーの追加・削除、チャネル管理、チーム設定の変更、チームの削除といった管理操作ができ、メンバーは所有者が許可した範囲で操作します。運用上きわめて重要なのが所有者の欠員対策で、所有者が退職して不在になった「孤立チーム」は、メンバー追加や設定変更ができなくなり、有効期限ポリシーの更新通知も届きません。そのため、チームごとに所有者を二名以上設定するというルールを定め、定期的に所有者不在のチームを洗い出して補充する運用が推奨されます。管理者は Teams 管理センターや PowerShell から所有者を強制的に追加できます。SharePoint や Exchange の管理センターからは背後のサイトやメールボックスは扱えても、チームの役割管理はできません。

正解: A. A. チーム単位の環境設定（Team Settings）

正解の根拠・詳細解説

Teams 管理センターで個別のチームを開くと、そのチームだけに適用される設定を構成できます。代表的な項目として、メンバーがチャネルを作成・更新・削除できるか、タブやアプリ、コネクタを追加できるか、メッセージを削除・編集できるか、ゲストにチャネルの作成や削除を許可するか、チーム全体へのメンションを許可するか、といったものがあります。ここが重要なのは、Teams のポリシーがユーザー単位で「その人が何をできるか」を決めるのに対し、チーム設定はチーム単位で「このチームの中ではどう振る舞うか」を決める点で、両者は別の軸だということです。実際には両方が評価され、より制限的な結果になります。運用としては、全社的な基準はポリシーで揃えつつ、機密性の高いチームや外部を含むチームだけをチーム設定で追加的に締める、という組み合わせが扱いやすい設計です。デバイスタグや DLP はまったく別領域の機能です。

正解: A. A. プライバシーとセンシティビティの設定

正解の根拠・詳細解説

チームのアクセス範囲は、まず作成時のプライバシー設定で決まります。パブリックは組織内の誰でも自分で参加でき、プライベートは所有者が承認・追加した人だけが参加できます。組織全体（Org-wide）チームは全社員が自動的にメンバーになる特別な種類で、作成できるのは全体管理者に限られます。したがって、特定の役職者だけに会話やファイルを見せたい場合はプライベートチームとして作成し、メンバーを厳密に管理するのが基本です。これに加えて感度ラベルを適用すると、外部ユーザーの追加可否や、ラベルで許可されたプライバシー設定への強制、非管理デバイスからのアクセス制御といった保護をチーム単位で効かせられます。さらに、既存チーム内の一部メンバーだけに閉じた議論をしたい場合はプライベートチャネルを使う、という選択肢もあります。会議カスタマイズポリシーや通話キューポリシーは、チームのアクセス制御とは無関係です。

正解: A. A. フロントラインワーカー向けチーム（Frontline Teams）

正解の根拠・詳細解説

フロントラインワーカー向けの機能群は、PC を常時使わない店舗スタッフや工場の作業者、医療・物流の現場担当者に向けて、Teams をモバイル中心の業務アプリとして使えるようにするものです。中心となるのはシフト（勤務表の作成・公開、交代申請、打刻）、タスク（本社から各店舗へタスクリストを配信し進捗を集約する）、承認（申請と承認の記録を残す）、ウォーキートーキー（対応デバイスでプッシュツートークの音声連絡を行う）といったアプリで、これらをアプリ セットアップ ポリシーでピン留めし、フロントライン向けのポリシー パッケージを割り当てることで、現場に必要な機能だけが並んだシンプルな画面を提供できます。多数の店舗を一括で展開するための仕組みも用意されており、拠点情報から標準構成のチームをまとめて作成できます。共有チャネルや B2B ダイレクトコネクトは外部組織との連携機能であり、現場向けの体験構築とは目的が異なります。

正解: A. A. 関連チーム（Related Teams）

正解の根拠・詳細解説

多数の拠点チームを抱える組織では、チーム同士に親子関係を持たせた階層（チーム ターゲティング階層）を定義できます。本社・地域統括・各店舗といった構造を CSV で記述してアップロードすると、上位のチームから下位のチームへ対象を指定した配信ができるようになり、代表的な用途がタスクの発行です。本社が作成したタスクリストを、階層と属性（地域や店舗形態など）で絞り込んだ対象チームへ一斉に配信し、各店舗での完了状況を集約して確認できます。階層は組織に一つだけ設定でき、組織変更に合わせて CSV を更新して再アップロードすることで維持します。共有チャネルやプライベートチャネルは、あくまでチャネル単位でアクセス範囲を絞る仕組みであり、チーム間の上下関係を表現するものではありません。通話キューは着信の振り分け機能で、まったく別の領域です。

正解: A. A. プライベートチャネル

正解の根拠・詳細解説

プライベートチャネルは、親チームのメンバーのうち、そのチャネルに明示的に追加された人だけが会話とファイルにアクセスできるチャネルです。技術的な要点は、標準チャネルが親チームの SharePoint サイト内のフォルダーを使うのに対し、プライベートチャネルは独立した専用の SharePoint サイトを持ち、アクセス権もチャネルのメンバーだけに限定される点にあります。これにより、チームを新しく作らずに、契約交渉や人事案件といった一部メンバー限定の議論を同じチームの中で完結させられます。制約として、プライベートチャネルに追加できるのは親チームのメンバーに限られ、一つのチームに作成できるプライベートチャネル数やメンバー数には上限があります。また、チーム全体の所有者であっても、自分がメンバーでないプライベートチャネルの中身は見られません（監査や eDiscovery による調査は可能です）。外部組織のユーザーを直接参加させたい場合は共有チャネルを使います。

正解: A. A. 共有チャネル

正解の根拠・詳細解説

共有チャネルは、チャネルを所有するチームの外にいる人を、そのチャネルだけに招き入れられる仕組みです。招かれた側は自分の所属チームを離れる必要も、親チームのメンバーになる必要もなく、自分の Teams クライアントの一覧にそのチャネルが表示されます。個人単位で追加するほか、チャネル自体を別のチームと共有することもできるため、複数の部門やプロジェクトチームが同じトピックについて一箇所で議論する用途に最適です。さらに Microsoft Entra のクロステナントアクセス設定（B2B ダイレクトコネクト）を構成すれば、他社のユーザーをゲスト登録なしで参加させられます。プライベートチャネルは親チームのメンバー内でしか使えないため横断利用に向かず、標準チャネルは親チームのメンバー全員に開かれる代わりに外部のチームを引き込めません。共有チャネルは専用の SharePoint サイトを持ち、共有相手には親チームの他のコンテンツは一切見えない点も設計上の利点です。

正解: A. A. チャネル管理権限の制限とメンバー権限設定

正解の根拠・詳細解説

チャネルの誤削除を防ぐ最も直接的な方法は、そもそも削除できる人を絞ることです。Teams 管理センターまたはチームの設定にあるメンバー権限で、メンバーによるチャネルの作成・更新・削除を許可するかどうかを個別に切り替えられるため、削除に相当する権限をオフにすれば、一般メンバーは誤って操作しても削除できず、所有者だけが実行できるようになります。ゲストについても同様に、チャネルの作成・削除の可否を別途設定できます。運用上の補足として、削除されたチャネルは一定期間内であれば所有者が復元できますが、期限を過ぎると会話履歴を含めて失われるため、事後の復旧に頼らず予防的に権限を絞る設計が推奨されます。特に全社的な情報共有チャネルや、監査対象の記録が蓄積されるチャネルを持つチームでは必須の設定です。命名ポリシーは名前の統制、デバイスタグは機器の分類であり、削除権限とは関係ありません。

正解: A. A. チャネル作成・共有に関するTeamsポリシー

正解の根拠・詳細解説

プライベートチャネルや共有チャネルを誰が作れるかは、Teams 管理センターの Teams ポリシー（Teams policies）で制御します。このポリシーにはプライベートチャネルの作成可否、共有チャネルの作成可否、共有チャネルへ外部の相手を招待できるか、他組織が所有する共有チャネルに参加できるか、といった項目があり、ユーザーまたはグループ単位で割り当てられます。したがって、一般社員にはチャネルの乱立や意図しない外部共有を防ぐために作成を禁止し、情報システム部門やプロジェクト管理者にだけ許可する、といった設計ができます。混同しやすいのは、チーム内のチャネル作成権限（チーム設定のメンバー権限）との違いで、あちらは特定のチームの中での話、こちらはユーザーがそもそもその種類のチャネルを作れるかというテナント側の統制です。DLP、保持ポリシーはコンテンツを対象とする機能であり、チャネル作成の可否は制御できません。

正解: A. A. プライベートチャネルの所有者

正解の根拠・詳細解説

プライベートチャネルは、親チームとは独立したメンバーシップを持ちます。チャネルを作成した人がそのチャネルの所有者となり、以降のメンバー追加・削除や、チャネル内での権限設定はチャネル所有者が行います。チーム全体の所有者であっても、自分がそのプライベートチャネルのメンバーでなければ中身を見ることも、メンバーを直接管理することもできません。この独立性が機密性を担保している一方、運用上のリスクにもなります。チャネル所有者が退職すると管理者不在のチャネルが残るため、所有者を複数設定しておくべきです。なお、追加できるのは親チームのメンバーに限られるため、外部の人を入れたい場合はまず親チームに参加させるか、共有チャネルを使う必要があります。管理者はコンプライアンス目的で eDiscovery や監査ログを通じて内容を調査できますが、それは通常の閲覧権限とは別の仕組みです。

正解: A. A. メッセージングポリシーの不適切な言葉のフィルタリング

正解の根拠・詳細解説

Teams のチャット体験に関する設定はメッセージング ポリシーに集約されており、不適切なコンテンツへの対処もここで構成します。具体的には、ユーザーが受け取ったメッセージを不適切なコンテンツやセキュリティ上の懸念として報告できる機能の有効・無効を、ユーザーやグループ単位で指定できます。報告されたメッセージは Microsoft Purview の通信コンプライアンス側に用意した専用ポリシーに送られ、レビュー担当者が確認・対処する流れになります。自動的な検出まで行いたい場合は、通信コンプライアンスのポリシーで攻撃的・脅迫的な表現を判定する学習済み分類子を条件に設定し、該当したメッセージをレビューキューに上げる構成にします。DLP はクレジットカード番号などの機密情報の外部流出を防ぐ機能であり、言葉遣いの適切さを評価するものではないため、この用途には合致しません。

正解: A. A. メッセージングポリシー（Messaging Policy）

正解の根拠・詳細解説

メッセージング ポリシーは、ユーザーが Teams のチャットとチャネル投稿で何をできるかを定義するユーザー単位のポリシーです。その中に、送信済みメッセージの編集を許可するか、自分が送ったメッセージの削除を許可するか、所有者がチャネル内のメッセージを削除できるか、といった項目があるため、これらをオフにしたポリシーを作成して対象グループに割り当てれば、編集・削除を禁止できます。金融や医療のように、やり取りの原本性が求められる部門でよく使われる構成です。ポリシーにはこのほか、チャットそのものの可否、既読通知、Giphy やステッカーの利用、緊急通知、翻訳といった設定も含まれます。ただし、編集・削除を禁止してもコンプライアンス上の保証にはならないため、記録を確実に残す要件がある場合は、Microsoft Purview の保持ポリシーを併用して、削除されてもコピーが保持される状態を作るのが正しい設計です。

正解: A. A. 組織全体のアプリ設定（Org-wide app settings）

正解の根拠・詳細解説

組織全体のアプリ設定（Teams 管理センターのアプリの管理にある組織全体のアプリ設定）は、テナント全体でどの種類のアプリを利用可能にするかを一括で決める最上位の統制です。Microsoft 製アプリ、サードパーティ製アプリ、組織が独自に開発したカスタムアプリのそれぞれについて、利用を許可するかどうか、また新しく公開されたアプリを自動的に許可するかどうかを設定できます。理解しておくべき重要な性質は優先順位で、ここでブロックしたアプリは、下位のアプリ ポリシーで許可されていても利用できません。つまり、まず組織全体で許容範囲の枠を決め、その枠の内側でポリシーによりユーザーやグループごとの差分を作る、という二段構えで設計します。個別のアプリを一つずつ許可・ブロックする操作は、アプリの管理画面のアプリ一覧から行います。命名ポリシーや会議テンプレート、デバイスタグは、いずれもアプリの利用可否とは無関係の機能です。

正解: A. A. アプリ許可ポリシーとアプリセットアップポリシー

正解の根拠・詳細解説

部署ごとにアプリの利用範囲を変える場合は、二種類のポリシーを役割分担させて組み合わせます。アプリのアクセス許可（アプリ許可）ポリシーは「どのアプリの利用を許可するか」を定義するもので、すべて許可・すべてブロック・特定のアプリのみ許可といった形で、Microsoft 製・サードパーティ製・カスタムアプリの区分ごとに指定します。一方アプリ セットアップ ポリシーは「許可されたアプリをどう見せるか」を定義するもので、既定でインストールするアプリ、アプリバーにピン留めする順序、ユーザー自身がピン留めを変更できるかを設定します。したがって、対象部署のグループに専用のアクセス許可ポリシーでカスタム業務アプリを許可し、セットアップ ポリシーでそのアプリをピン留めして目立たせる、という組み合わせが定石です。前提として、組織全体のアプリ設定でカスタムアプリがブロックされていると、ポリシー側で許可しても利用できない点に注意してください。

正解: A. A. アプリの権限と同意（Permissions and Consent）の管理

正解の根拠・詳細解説

Teams アプリの多くは、動作のためにユーザーや組織のデータへアクセスする権限（Microsoft Graph のアクセス許可）を必要とします。ユーザー個人が同意できない管理者同意が必要な権限を要求された場合、そのままではアプリを使えないため、Microsoft Entra ID の管理者同意ワークフローを構成しておくと、ユーザーからの同意リクエストが管理者のレビュー待ちとして集約され、内容を確認したうえでまとめて承認または拒否できます。Teams 管理センターのアプリ詳細画面からも、そのアプリが要求している権限を確認し、組織を代表して同意を与えることができます。この仕組みが重要なのは、ユーザーの自己判断による同意を野放しにすると、悪意あるアプリに広範なデータアクセスを許してしまう「不正な同意付与」攻撃の入り口になるためです。実務では、ユーザー同意を制限したうえでリクエスト方式に切り替え、承認したアプリと権限を定期的に棚卸しするのが推奨されます。

正解: A. A. コネクタ／ワークフロー（Connectors / Workflows）

正解の根拠・詳細解説

コネクタとその後継であるワークフロー（Power Automate をベースにした Workflows アプリ）は、外部サービスで発生したイベントを、チャネルへ自動的にメッセージとして投稿する仕組みです。障害監視ツールのアラート、リポジトリへのコミット、フォームの回答、承認依頼といった情報が、担当者が各システムを見に行かなくてもチャネルに集約されます。単純な用途では、チャネルに受信 Webhook を作成し、その URL に対して外部システムから JSON を POST するだけで投稿できます。実務上の重要な変化として、従来の Office 365 コネクタは段階的に廃止され、Power Automate のワークフローへの移行が進められているため、新規構築では Workflows を選ぶのが妥当です。他の選択肢と役割が異なり、タブは画面の埋め込み、メッセージング拡張機能は検索バーや入力欄からのコマンド実行、ボットは対話的な応答を担当します。

正解: A. A. タブ（Tabs）

正解の根拠・詳細解説

タブは、チャネルやチャットの上部に固定表示され、その中に別のコンテンツやアプリの画面を埋め込んで表示する拡張機能です。SharePoint のドキュメントライブラリやファイル、OneNote、Planner の計画、Power BI レポート、Web サイト、そしてサードパーティ製アプリの画面などをチャネルに貼り付けておけば、メンバーは Teams から離れずに必要な情報へ到達できます。会話が行われる場所と参照すべき資料が同じ画面に揃うことで、リンクを探す手間や共有漏れが減るのが利点です。設計上の注意として、タブを追加できるかどうかはチーム設定のメンバー権限やアプリ ポリシーに従うこと、そして埋め込んだ先のコンテンツにはそれぞれ固有のアクセス権があるため、チャネルのメンバー全員が中身を見られるとは限らないことが挙げられます。ボットは対話応答、ワークフローは自動投稿、メッセージング拡張機能はコマンド実行と、それぞれ担う役割が異なります。

正解: A. A. メッセージング拡張機能（Messaging Extensions）

正解の根拠・詳細解説

メッセージング拡張機能は、Teams の検索バー（コマンドボックス）やメッセージ入力欄の下にあるアイコンから呼び出し、アプリ側の機能を実行する仕組みです。大きく二種類あり、検索型は外部システムのレコードやチケット、ファイルを検索してその結果をカードとして会話に挿入でき、アクション型は入力フォームを開いて、会話から離れずに課題の起票や申請の作成といった処理を実行できます。既存メッセージを起点にして、その内容を外部システムへ登録するといった連携も可能です。利点は、ユーザーが別のアプリケーションへ切り替えることなく、会話の流れの中で情報の参照と登録を完結できる点にあります。タブが画面を常設して閲覧するための仕組み、ボットが対話でやり取りする仕組みであるのに対し、メッセージング拡張機能は「必要なときに呼び出して結果を差し込む」用途に最適化されています。

正解: A. A. Teamsアプリストアでの購入管理

正解の根拠・詳細解説

サードパーティ製の有償アプリは、Teams 管理センターのアプリの管理から対象アプリを開き、提供されているプランと価格を確認して購入手続きへ進むことができます。購入したライセンスは Microsoft 365 管理センターのライセンス管理と同様に、利用するユーザーへ割り当てて管理します。この経路を使う利点は、個々のユーザーが勝手にサブスクリプションを契約する状態（いわゆるシャドー IT）を避け、組織として契約・費用・割り当て状況を一元的に把握できることです。実務では、購入の前にそのアプリが要求するデータアクセス権限とベンダーの取り扱い方針を確認し、アプリのアクセス許可ポリシーで利用対象を必要な部署に限定してから展開する流れが安全です。Power Automate、Exchange、SharePoint の各管理センターは、それぞれ別のワークロードを扱うものであり、Teams アプリのライセンス購入窓口ではありません。

正解: A. A. アプリストアのカスタマイズ（Customize the app store）

正解の根拠・詳細解説

Teams 管理センターでは、ユーザーに表示されるアプリストアの見た目を組織向けにカスタマイズできます。組織のロゴやカスタム背景、テキストの色といったブランディング要素を設定できるほか、業務で使ってほしいアプリを「注目のアプリ」として先頭に並べることで、社内標準のアプリへ利用者を誘導できます。多数のアプリが並ぶ既定のストアでは、どれを使うべきか利用者が判断できず、結果として似た機能のアプリが乱立しがちですが、ストアを整えることでこの問題を緩和できます。あわせて、アプリのアクセス許可ポリシーで不要なアプリを非表示にし、アプリ セットアップ ポリシーで主要アプリをピン留めしておくと、利用者の導線が明確になります。命名ポリシー、会議テンプレート、通話キューポリシーは、いずれもアプリストアの表示とは無関係の設定です。

正解: A. A. アプリパッケージのアップロード（カスタムアプリのアップロード）

正解の根拠・詳細解説

自社開発した Teams アプリは、アプリの定義を記述した manifest ファイルとアイコン画像をまとめた ZIP 形式のアプリパッケージとして用意し、これを組織へ取り込むところから展開が始まります。取り込みは Teams 管理センターのアプリの管理から新しいアプリをアップロードする方法と、開発者ポータルから公開する方法があります。取り込み後は、組織のアプリとしてアプリ一覧に現れるので、アプリのアクセス許可ポリシーで利用できるユーザーを指定し、アプリ セットアップ ポリシーで対象者にピン留め・自動インストールする、という流れで実際の利用者に届けます。前提条件として、組織全体のアプリ設定でカスタムアプリが許可されている必要があり、開発中の検証だけであれば、開発者に個別にアップロードを許可する構成もあります。命名ポリシーや会議テンプレート、デバイスタグは、アプリ展開とは無関係の機能です。

正解: A. A. アプリセットアップポリシー

正解の根拠・詳細解説

アプリ セットアップ ポリシーは、Teams クライアントのアプリバー（左側のバー）にどのアプリをどの順序で表示するか、どのアプリを既定でインストールしておくか、そしてユーザー自身がピン留めを変更できるかを定義します。これにより、対象者が Teams を開いた瞬間から、業務に必要なアプリが最初から並んだ状態を作れます。実務上の重要な注意点として、このポリシーの割り当て単位はユーザーまたはグループであり、チームそのものに割り当てるわけではありません。したがって「あるチームのメンバー全員に適用したい」場合は、そのチームの実体である Microsoft 365 グループやメンバーを含むセキュリティグループに対してポリシーを割り当てる形になります。あわせて、ここでピン留めしたアプリがアプリのアクセス許可ポリシーや組織全体のアプリ設定でブロックされていると表示されないため、上位の設定との整合を確認してください。

正解: A. A. Virtual Appointments（仮想予定）

正解の根拠・詳細解説

Virtual Appointments（仮想予定）は、社外の顧客や取引先と、予約制の 1 対 1 または少人数の面談をオンラインで行うことに特化した仕組みです。Microsoft Bookings と連携し、公開した予約ページから相手が空き枠を選ぶと会議が自動的に設定され、参加者には確認と参加用リンクが通知されます。相手側は Teams アカウントもアプリのインストールも必要なく、ブラウザーからリンクを開くだけで参加できるため、金融機関の窓口相談、医療機関のオンライン診療、小売のパーソナルショッピングといった顧客接点で使われます。担当者側は待合スペースで待機者を確認し、順に呼び出す運用ができます。SMS 通知や待合室のブランディング、詳細な分析レポートといった高度な機能は Teams Premium など追加のライセンスを前提とする点に注意が必要です。数百人規模で一方向に配信する用途にはウェビナーやタウンホールを使います。

正解: A. A. Webinar

正解の根拠・詳細解説

ウェビナー（Webinar）は、参加者に事前登録を求めたうえで開催する、講演形式のオンラインイベント向けの会議種別です。主催者は登録ページを作成し、質問項目を設定して参加者情報を収集でき、登録の承認制や定員の設定も可能です。開催後は登録者と実際の出席者を突き合わせたレポートを取得できるため、マーケティング施策としての効果測定や、フォローアップの対象抽出に使えます。役割として発表者と出席者が明確に分かれており、出席者は既定でマイクやカメラを使えないため、進行が乱されにくい構成になっています。ウェビナーを誰が開催できるかは会議ポリシーで制御し、登録機能の可否も同様にポリシーで管理します。より大人数へ一方向に配信し、社内向けの全社集会として運用する場合はタウンホールが適しており、少人数の予約制面談には Virtual Appointments を使う、という使い分けになります。

正解: A. A. Teams town hall

正解の根拠・詳細解説

タウンホール（Teams town hall）は、経営層から全社員へのメッセージ配信のように、少数の発表者から非常に多くの視聴者へ一方向に届けることを想定した会議形式で、従来の Teams ライブイベントを置き換えるものとして提供されています。視聴者は音声・映像を発信せず視聴に専念し、質問は Q&A 機能を通じて投稿し、モデレーターが選んで回答・公開するため、大規模でも進行が破綻しません。発表者は事前に役割を割り当てられ、開始前の準備（グリーンルーム）で映像や共有資料を確認してから本番に入れます。同時視聴可能な人数の上限や、外部配信ソフトからの取り込みといった高度な機能の可否は、ライセンス（Teams Premium の有無）によって異なるため、開催規模が大きい場合は事前に確認が必要です。少人数の予約制面談は Virtual Appointments、登録と効果測定を伴う社外向けセミナーはウェビナーが適します。

正解: A. A. 会議ポリシーのCopilot関連設定

正解の根拠・詳細解説

Teams の会議における Copilot の利用可否は、Teams 管理センターの会議ポリシーで制御します。この設定は単純なオン・オフではなく、会議の文字起こしをどう扱うかと連動している点が重要です。会議中だけ Copilot を使えるようにして終了後は記録を残さない構成にすると、その場では要約や質問応答を利用できますが、会議後に振り返ることはできません。会議中と会議後の両方で使えるようにする構成では、文字起こしが保存されることが前提となり、終了後も議事メモや決定事項の抽出が可能になります。したがって、議事録を自動生成して後から参照したいという要件であれば、文字起こしを保持する構成を選ぶ必要があります。前提として、対象ユーザーに Microsoft 365 Copilot のライセンスが割り当てられていること、文字起こし自体が会議ポリシーで許可されていることを確認してください。記録が残ることについては、参加者への周知と、記録の保持期間に関する社内ルールの整備も欠かせません。

正解: A. A. 会議ポリシーのグループ単位割り当て

正解の根拠・詳細解説

会議ポリシーは、録画の可否、文字起こしとライブキャプション、ロビーの既定動作、画面共有の範囲、匿名参加の可否、会議の開催そのものの可否といった項目をユーザー単位で定義するポリシーです。部署ごとに要件が異なる場合は、全社の既定を Global ポリシーで定めたうえで、要件の異なる部署向けにカスタムポリシーを作成し、その部署のセキュリティグループや Microsoft 365 グループへ割り当てます。グループ単位の割り当てを使えば、人事異動でグループのメンバーが変われば適用も自動的に追随するため、個別割り当てを一人ずつ運用するより保守性が高くなります。適用の優先順位には注意が必要で、ユーザーへの直接割り当てが最も強く、次にグループ割り当て（複数該当時はランクの高いもの）、最後に Global の順に評価されます。DLP は情報保護、アプリ セットアップ ポリシーはアプリの表示、命名ポリシーはグループ名の統制であり、いずれも会議機能の制御はできません。

正解: A. A. 会議カスタマイズポリシー（Meeting Customization Policy）

正解の根拠・詳細解説

会議のカスタマイズ（会議のブランディング）に関するポリシーは、会議の見た目を組織として統一するための機能です。組織のロゴ、会議の待機画面や背景に使う画像、テーマカラーといった要素をあらかじめ定義しておくと、対象ユーザーが主催する会議に自動的に適用され、社外の参加者にも一貫したブランド体験を提供できます。あわせて、利用者が選べる背景画像を組織が用意したものに限定するといった制御も可能です。実務上の重要な前提として、この種の高度なカスタマイズは Teams Premium のライセンスを必要とするため、導入前にライセンス要件を確認してください。役割の違いも押さえておきましょう。会議ポリシーは「その人が何をできるか」という機能の可否、会議テンプレートは「特定の目的の会議でどの設定を既定にし、主催者に変更させないか」を定義するもので、見た目のブランディングとは対象が異なります。

正解: A. A. 会議テンプレート（Meeting Templates）

正解の根拠・詳細解説

会議テンプレートは、特定の用途に合わせた会議設定の組み合わせをひな型として登録し、主催者が会議作成時に選ぶだけでその設定が適用されるようにする機能です。ロビーのバイパス範囲、誰が発表者になれるか、録画や文字起こしの自動開始、チャットの可否、参加者のマイク・カメラの既定状態といった項目を事前に構成できます。最大の価値は、管理者が個々の設定項目を「ロック」できる点にあり、ロックした項目は主催者が会議オプションから変更できなくなるため、採用面接や機密性の高い打ち合わせで必要な統制を確実に効かせられます。会議ポリシーが全社的・部署単位の一律の制限であるのに対し、テンプレートは会議の目的ごとに設定を切り替えられるのが違いです。テンプレートの作成と利用には Teams Premium のライセンスが必要になるため、導入検討時にはライセンス要件をあわせて確認してください。

正解: A. A. イベント設定とポリシー（Event settings and policies）

正解の根拠・詳細解説

ウェビナーやタウンホールといったイベント形式の会議については、通常の会議ポリシーとは別に、イベントに関するポリシーと設定が用意されています。管理者はイベント ポリシーで、そのユーザーがウェビナーやタウンホールを開催できるか、参加者に登録を求める機能を使えるか、社外の誰でも登録できる公開イベントを許可するか、といった枠組みを制御します。この枠内で、登録フォームに表示する項目（氏名やメールアドレスなどの標準項目に加えた、所属や参加動機といったカスタム質問）や、必須回答とするかどうかは、イベントを作成する主催者が登録ページの構成画面で設定します。つまり管理者は「できる範囲」を決め、主催者が「実際の質問内容」を決める、という役割分担です。設計時の注意として、登録フォームで個人情報を収集する場合は、収集項目の妥当性と保管・削除のルールをプライバシーポリシーと整合させておく必要があります。

正解: A. A. Webinarの管理・レポートポリシー設定

正解の根拠・詳細解説

ウェビナーで収集した登録者情報や出席レポートは個人情報を含むため、誰がアクセスできるかを把握しておくことが重要です。基本的に、登録者の一覧や出席状況のレポートを取得できるのは、そのイベントの主催者および共同主催者に限られ、参加者や無関係な社員が自由に閲覧できるものではありません。管理者側の統制としては、Teams 管理センターのイベント関連ポリシーで、そもそも誰がウェビナーを開催できるか、登録機能を利用できるか、社外に公開したイベントを作成できるかを制御し、これによって組織として登録情報を収集できる範囲を限定します。また、出席レポートの提供可否や、参加者情報をレポートに含めるかどうかを会議ポリシー側で制御できるため、プライバシー配慮が必要な組織ではこの設定を見直します。DLP や保持ポリシーはコンテンツの保護と保存期間を扱う機能であり、レポートの取得権限そのものを制御するものではありません。

正解: A. A. Teams town hall

正解の根拠・詳細解説

タウンホールは、全社員に向けた一方向のライブ配信に最適化された会議形式です。発表者だけが映像・音声と画面共有を行い、視聴者は視聴に専念する構造のため、参加者が非常に多くてもノイズや誤操作で進行が乱れることがありません。質問は Q&A 機能で受け付け、モデレーターが内容を確認したうえで公開・回答できるので、全社集会でありがちな不適切な発言の混入も抑えられます。開始前にはグリーンルームで発表者だけが集まり、映像や共有資料の最終確認ができます。従来の Teams ライブイベントを置き換える機能として提供されており、同時視聴人数の上限や外部エンコーダーからの配信取り込みといった高度な機能の可否は、ライセンス（Teams Premium の有無）によって変わるため、開催規模が大きい場合は事前確認が必要です。Virtual Appointments は少人数の予約制面談、プライベートチャネルや共有チャネルはコラボレーションの仕組みであり、ライブ配信の用途ではありません。

正解: A. A. 電話番号のプロビジョニング（Provision phone numbers）

正解の根拠・詳細解説

Teams Phone で通話を行うには、まずユーザーやリソースアカウントに電話番号を割り当てる必要があり、この操作を Teams 管理センターの音声（電話番号）から行います。前提として、対象ユーザーに Teams Phone のライセンスが割り当てられていること、そして PSTN 接続方式に応じた番号が用意されていることが必要です。Microsoft の通話プランを利用する場合は管理センターから番号を取得（または既存番号をポート）し、ダイレクトルーティングや Operator Connect では通信事業者から供給された番号を扱います。番号はユーザーだけでなく、自動応答や通話キューが使うリソースアカウント、会議ブリッジ（電話会議のダイヤルイン番号）にも割り当てられます。実務上の重要な注意点として、通話プランの番号を割り当てる際には緊急通報用の場所情報の登録が求められるため、拠点住所の整備を先に済ませておくと手戻りがありません。

正解: A. A. 既存ユーザーから電話番号を削除し、新しいユーザーに割り当て直す

正解の根拠・詳細解説

電話番号は有限で費用のかかるリソースであるため、退職者が使っていた番号は廃止せず、割り当てを解除して未割り当てのプールに戻し、必要に応じて別のユーザーやリソースアカウントへ再割り当てするのが基本的な運用です。Teams 管理センターの電話番号一覧から解除・割り当てができるほか、PowerShell のコマンドレットを使えば多数の番号をまとめて処理できます。番号を完全に廃止（返却）してしまうと、同じ番号を取り戻せる保証はなく、名刺や取引先の登録に残っている番号が不通になるという業務影響も生じます。実務上の注意点として、退職直後の番号をすぐ別の人に割り当てると、前任者宛ての電話が新任者に着信して混乱を招くため、一定の据え置き期間を設けたり、代表番号や後任者へ転送する期間を挟んだりする運用が推奨されます。番号ポータビリティは、他の通信事業者から番号を移す際の手続きであり、社内での付け替えとは別の話です。

正解: A. A. 音声ルーティングポリシー

正解の根拠・詳細解説

発信できる宛先の制御は、音声ルーティングの仕組みで実現します。ダイレクトルーティング環境では、宛先番号のパターン（正規表現）で一致を判定する音声ルートと、それを束ねる PSTN 使用法を定義し、それらを含むオンライン音声ルーティングポリシーをユーザーへ割り当てます。国際番号に一致するルートを含まないポリシーを割り当てれば、そのユーザーは国内宛てしか発信できません。役員や海外部門にだけ国際発信を許可するポリシーを別途用意して割り当てる、という設計が典型です。Microsoft の通話プランを利用している場合は、そもそも国際通話プランのライセンスを付与するかどうかが第一の制御軸となり、加えてダイヤルプランの正規化ルールや発信制限の設定を組み合わせます。コスト管理と不正利用（国際プレミアム番号への発信詐欺）の防止という観点から、必要な人にだけ許可する最小権限の考え方が重要です。会議やアプリ、命名に関するポリシーは通話の宛先制御には関与しません。

正解: A. A. ボイスメールポリシー（Voicemail Policy）

正解の根拠・詳細解説

応答できなかった通話を受け止め、あらかじめ用意した案内メッセージを再生してメッセージを預かるのがボイスメール（応答メッセージ）です。Teams のボイスメール ポリシーでは、文字起こしの有効化やその表示、システムが読み上げるプロンプトの言語、最大録音時間、ユーザーが自分の通話応答ルールを編集できるかどうかといった項目を制御します。ユーザー側では、通常のあいさつとは別に不在時（時間外）用のあいさつを録音でき、Outlook の自動応答や勤務時間と連動させて自動的に切り替える設定が可能です。実務上あわせて理解しておきたいのは、代表番号にかかってきた通話を営業時間で分岐させ、時間外は専用のアナウンスを流したい場合、本来は自動応答（オートアテンダント）の営業時間・休日設定を使うのが適切だという点です。個人宛ての不在応答はボイスメール、代表番号の時間外対応は自動応答、と使い分け、両者を組み合わせるのが一般的な設計になります。

正解: A. A. コールキュー（Call Queue）

正解の根拠・詳細解説

通話キュー（コールキュー）は、代表番号などに着信した通話をいったん待機列に入れ、応対可能なエージェントへ自動的に振り分ける仕組みです。構成要素として、あいさつメッセージ、保留中に流す音楽、エージェントの一覧（個別ユーザー、チームのチャネル、配布リストなどで指定）、振り分け方法（先頭から順に鳴らすシリアル、全員を同時に呼び出すアテンダント、順番に回すラウンドロビン、最も長く待機しているエージェントを優先する方式など）を設定します。加えて、待機件数が上限を超えたときのオーバーフロー処理や、一定時間応答がない場合のタイムアウト処理として、ボイスメールや別の番号への転送を指定できます。通話キューには電話番号を直接割り当てるためのリソースアカウントが必要で、外部から直接着信させる場合はそのアカウントに番号を割り当てます。発信者に選択を促す音声メニューは自動応答が担当する機能で、両者を組み合わせて使うのが一般的です。

正解: A. A. 自動応答（Auto Attendant）

正解の根拠・詳細解説

自動応答（オートアテンダント）は、着信した発信者にあいさつを再生し、ダイヤルキーの操作や音声認識によって行き先を選ばせる音声メニュー機能です。「営業部は 1 を、サポートは 2 を」といったメニューを構成し、それぞれの選択肢の転送先として、通話キュー、特定のユーザー、別の自動応答、ボイスメール、外部の電話番号などを指定できます。営業時間、時間外、休日という時間帯ごとに別々のメニューとメッセージを構成できるため、時間外は専用の案内を流してボイスメールへ誘導する、といった運用が可能です。さらに、名前や内線番号によるディレクトリ検索を有効にして、担当者へ直接つなぐこともできます。自動応答も通話キューと同様にリソースアカウントを必要とし、外部から直接かかってくる番号はそのアカウントに割り当てます。設計としては、自動応答で振り分け、その先の各部署の待ち行列を通話キューが受ける、という組み合わせが定石です。

正解: A. A. 発信通話の転送ポリシー（Calling Policy）

正解の根拠・詳細解説

通話ポリシー（コーリング ポリシー）は、ユーザーが Teams Phone の各機能をどこまで使えるかを定義するユーザー単位のポリシーです。設定項目には、通話の発信可否、通話の転送や同時呼び出しを許可するか（さらにその宛先を組織内に限るか外部番号も認めるか）、他の人に自分の通話を代理応答させる委任、グループ通話ピックアップ、着信のボイスメールへの転送、話し中の際の挙動、保留音の利用などがあります。したがって、転送や委任に関する権限を役職者のグループだけに許可したポリシーを作成して割り当てれば、要件を満たせます。特に外部番号への転送や同時呼び出しは、通話料金の負担や情報の外部持ち出しにつながるため、既定では組織内に限定し、必要な人にだけ緩和するのが安全な設計です。会議のカスタマイズ、命名、アプリに関するポリシーは、通話機能の可否とは無関係の設定です。

正解: A. A. 大規模会議向けの会議ポリシー設定（参加者数上限の確認等）の見直し

正解の根拠・詳細解説

参加者数が非常に多い会議では、まず会議ポリシーで設定できる項目と、会議形式そのものの適合性を見直すのが正しい進め方です。標準の Teams 会議は、全員が発言・カメラ・画面共有を行える対話型の形式であり、同時参加できる人数には上限があります。参加者の大半が視聴するだけであれば、双方向性を抑えたウェビナーやタウンホールへ切り替えることで、より大規模でも安定した配信ができます。あわせて、大人数の会議で品質を保つには、参加者のマイクを既定でミュートにして不要な音声ストリームを減らす、発表者を限定する、必要のないビデオをオフにする、といった運用上の工夫が効果を発揮します。ネットワーク面では、拠点の帯域を Network Planner で見積もり、QoS で音声を優先させる設計が前提となります。ビデオを強制的にオンにする、録画を必ず有効にする、ロビーを無効にするといった対応は、いずれも音声品質の改善にはつながりません。

正解: A. A. Call Quality Dashboard（CQD）

正解の根拠・詳細解説

Call Quality Dashboard（CQD）は、テナント内で行われた通話・会議のテレメトリを集約し、パケットロス、ジッター、ラウンドトリップ時間、音声の劣化指標などを傾向として分析するためのツールです。品質の悪い拠点を特定するうえで決定的に重要なのが、建物・サブネット情報を記述したビルディングデータファイルをアップロードして、IP アドレスやサブネットを拠点名・ネットワーク種別（有線／無線、社内／VPN）にマッピングしておく作業です。これを行っていないと、レポート上は IP アドレスの羅列にしかならず、「どの拠点が悪いのか」を読み取れません。理解しておくべき役割の違いとして、CQD は組織全体の傾向を見る集計型のツールであり、特定ユーザーの個別の通話を一件ずつ調べたい場合は、Teams 管理センターのユーザー画面から見る通話分析（Call Analytics）を使います。Network Planner は導入前の帯域見積もり、Advisor for Teams は導入計画の支援であり、品質監視の用途ではありません。

正解: A. A. 部署のニーズに応じたカスタムポリシーを作成し個別に割り当てる

正解の根拠・詳細解説

会議に関する要件は部署によって大きく異なります。たとえば、開発部門は録画と文字起こしを積極的に使いたい一方、人事や法務は録画を禁止したい、営業は社外の匿名参加者を受け入れる必要がある、といった具合です。こうした差分に対応する正しいアプローチは、全社共通の基準を Global（組織全体の既定）ポリシーで定めたうえで、要件の異なる部署ごとにカスタムの会議ポリシーを作成し、その部署のセキュリティグループや Microsoft 365 グループへ割り当てることです。グループ単位で割り当てておけば、異動や新入社員の追加に自動的に追随し、運用負荷が増えません。すべてを Global 一つで賄おうとすると、最も厳しい部署に合わせて全社が不便になるか、最も緩い部署に合わせて統制が効かなくなるかのどちらかに陥ります。ポリシーを作らず個別に設定する運用は再現性がなく監査にも耐えられず、ポリシーの削除は既定へ戻すだけで解決になりません。

正解: A. A. 緊急通報用の場所情報（Emergency Calling / Location Information Service）

正解の根拠・詳細解説

Teams Phone から緊急通報を行う際、通報先に正しい所在地が伝わらなければ救助が遅れるため、位置情報の構成は必須の設計項目です。基本となるのが、ユーザーやサイトに紐づけて登録する緊急対応先住所です。さらに、ノート PC のように場所が変わる利用形態に対応するため、位置情報サービス（LIS）にネットワーク識別子（サブネット、無線アクセスポイントの識別子、スイッチのシャーシやポートなど）と場所の対応表を登録しておくと、クライアントが接続しているネットワークから現在地を動的に判定し、フロアや部屋レベルまで含めた住所を通報時に付与できます。あわせて緊急通報ポリシーを構成すると、緊急通報が発生した際に警備部門や総務へ通知（会議への同時参加を含む）を行い、社内での初動対応につなげられます。テレワーク時のように登録外の場所から発信する場合はユーザー自身が住所を確認・入力する必要があるため、その周知も運用上の要点です。

正解: A. A. 不審な外部参加者によるスパムや不適切発言を防止するため

正解の根拠・詳細解説

匿名参加者とは、会議リンクから名前だけを入力して参加した、認証されていない外部ユーザーを指します。認証を経ていないため名乗った名前と実在の人物が一致する保証がなく、悪意ある第三者がリンクを入手して紛れ込む余地があります。この状態で自由にチャットへ投稿できると、スパムやフィッシングリンクの投稿、なりすましによる誤情報の拡散、不適切な発言といったリスクが生じるため、匿名参加者のチャットや会議中の権限を制限します。関連する統制として、会議ポリシーで匿名ユーザーの参加そのものを許可するかを決め、会議オプションでロビーのバイパス範囲を設定して、匿名参加者は必ず主催者の承認を経てから入室させる構成にします。さらに、発表者になれる人を限定すれば、画面共有の乗っ取りも防げます。録画品質や通話品質、電話番号の管理は、これらの設定とは無関係です。

正解: A. A. Call Quality Dashboard（CQD）

正解の根拠・詳細解説

Call Quality Dashboard（CQD）は、テナント全体の通話・会議から収集されたメディア品質のテレメトリを集約し、ジッター、パケットロス率、ラウンドトリップ時間、音声の劣化度合いといった指標を、期間・拠点・ネットワーク種別・クライアント種別・デバイスなどの切り口で分析できるレポート基盤です。個別の障害対応というより、「無線ネットワークの通話だけ品質が悪い」「特定拠点の VPN 経由の会議に問題が集中している」といった傾向を見つけ、ネットワーク改善の投資判断につなげるために使います。有効活用の鍵はビルディングデータファイルの登録で、サブネットと拠点・ネットワーク種別を対応づけておかないと、レポートを拠点別に読み解けません。使用状況レポートは会議数やアクティブユーザー数といった利用量を示すもので品質指標ではなく、アクセスレビューや保持ラベルのレポートは、それぞれ権限とコンプライアンスの領域に属します。

正解: A. A. アラートルール（Alert Rules）

正解の根拠・詳細解説

レポートを人が定期的に見に行く運用は見落としが避けられないため、あらかじめ条件を定義しておき、条件に一致したときにシステム側から管理者へ知らせる仕組みを組みます。Teams 管理センターの通知とアラートでは、ルールを作成して通知対象と通知先を指定でき、代表例として Teams 認定デバイスの正常性（オフラインになった、サインアウトされた、更新に失敗したなど）を監視するルールが用意されています。セキュリティやコンプライアンスに関する事象については、Microsoft Purview のアラート ポリシーで、監査ログ上のアクティビティ、対象ユーザー、発生回数のしきい値、重大度を定義し、一致したときに指定した管理者へメール通知を送ります。いずれも、しきい値を厳しくしすぎると通知が大量に届いて誰も見なくなるため、対応手順が定義されている事象だけをアラート化し、それ以外はレポートで定期確認する、という切り分けが実務上の要点です。

正解: A. A. Teams使用状況レポート（Usage Reports）

正解の根拠・詳細解説

Teams 管理センターの分析とレポートにある使用状況レポートは、組織における Teams の使われ方を量的に把握するためのものです。アクティブユーザー数の推移、チャットやチャネル投稿のメッセージ数、通話や会議への参加回数、利用されているプラットフォーム（デスクトップ、Web、モバイル）といった指標を、ユーザー単位・チーム単位で確認でき、CSV としてエクスポートすれば部門別に集計して比較できます。導入効果の測定や、活用が進んでいない部署への追加トレーニングの判断材料になります。実務上の注意点として、Microsoft 365 管理センターにはレポート内のユーザー名や組織情報を匿名化する設定があり、これが有効だと個人が特定できない表示になるため、部門別分析を行いたい場合はプライバシー方針と照らして扱いを決める必要があります。CQD は品質、アクセスレビューは権限、保持ラベルのレポートはコンプライアンスの領域で、利用量の分析には使いません。

正解: A. A. 会議ごとの品質メトリクス（per-meeting metrics）

正解の根拠・詳細解説

個々の会議で何が起きたのかを詳細に追う場合は、Teams 管理センターの通話分析（Call Analytics）から、対象ユーザーの会議・通話履歴を開いて会議単位のセッション情報を確認します。ここでは参加者の一覧、それぞれの参加・退出時刻や滞在時間に加えて、セッションごとのパケットロス、ジッター、往復遅延、使用したデバイス（マイク・スピーカー・カメラ）、クライアントのバージョン、接続の種類（有線、無線、VPN）といった技術的な詳細まで参照できます。これにより、「特定の 1 名だけ音声が途切れていた」といった事象について、原因が本人の無線環境なのか、使用デバイスなのかを切り分けられます。ここが CQD との役割分担で、CQD は組織全体の傾向を集計して見るもの、通話分析は特定の会議・特定のユーザーを深掘りするものです。ストレージ使用状況やゲストアクセスのレポートは、まったく別の情報を扱います。

正解: A. A. ストレージ使用状況レポート（Storage Usage Report）

正解の根拠・詳細解説

Teams のファイルは実体として SharePoint と OneDrive に保存されるため、Teams の利用が広がると、その増加はストレージ使用状況のレポートに現れます。SharePoint 管理センターのサイト一覧や、Microsoft 365 管理センターの利用状況レポートで、サイトごとの使用容量とテナント全体の推移を確認でき、容量を大きく消費しているチームを特定できます。増加要因として見落とされやすいのが会議の録画とその文字起こしで、これらは主催者の OneDrive またはチャネルの SharePoint サイトに保存されるため、録画を多用する組織では急速に容量を消費します。対策としては、録画に自動的な有効期限を設定して一定期間後に削除する、Microsoft Purview の保持ポリシーで不要なコンテンツのライフサイクルを定める、使われていないチームを有効期限ポリシーで整理する、といった手段を組み合わせます。CQD やアクセスレビューは容量の情報を持ちません。

正解: A. A. チームの作成・削除に関する監査ログ

正解の根拠・詳細解説

チームが短期間に急増している場合、まず事実関係を時系列で押さえる必要があり、そのための一次情報が Microsoft Purview の監査ログです。チームの作成・削除といったアクティビティを日付範囲と操作種別で絞り込んで検索すれば、いつ、誰が、どのチームを作成したかが一覧でき、CSV に出力して日別の件数推移や作成者ごとの集計を取れます。これにより、特定の部署でテンプレート的に大量作成が行われているのか、スクリプトや連携アプリによる自動作成なのか、といった原因の切り分けができます。恒常的な対策としては、Microsoft Entra ID のグループ設定で作成できるユーザーを限定する、命名ポリシーで用途が分かる名前を強制する、有効期限ポリシーで使われないチームを自動的に整理する、という三点セットが定石です。CQD は通話品質、ボイスメールポリシーと通話キューは電話機能の領域であり、チームの増加傾向は分かりません。

正解: A. A. ゲストアクセスレポート

正解の根拠・詳細解説

ゲストの参加状況を点検するには、複数の情報源を組み合わせます。Teams 管理センターのチーム一覧や使用状況レポートでは、各チームのメンバー数と併せてゲスト数を確認でき、想定外にゲストが多いチームを特定できます。より網羅的には、Microsoft Entra 管理センターでユーザー種別がゲストのアカウントを一覧し、招待日や最終サインイン日時から、使われていないアカウントを洗い出します。加えて Microsoft Purview の監査ログでゲストの追加イベントを追えば、誰がいつ招待したのかという経緯まで確認できます。恒常的な運用としては、ゲストのみを対象としたアクセスレビューを定期実行し、所有者が継続の要否を判断して不要なゲストを自動削除する仕組みを組むのが最も確実です。あわせて、そもそも誰がゲストを招待できるかを Entra ID の外部コラボレーション設定で絞っておくと、想定外の増加自体を抑えられます。

正解: A. A. Microsoft 365 network connectivity test toolの定期実行結果の確認

正解の根拠・詳細解説

拠点ごとのネットワーク接続性は一度測って終わりではなく、回線の増強、プロキシの構成変更、拠点の移転や在宅勤務の増加といった変化のたびに状況が変わります。そのため Microsoft 365 ネットワーク接続性テストツールを各拠点で定期的に実行し、結果を蓄積して傾向を追うことが有効です。このツールは遅延やパケットロスに加えて、実際にどこからインターネットへ抜けているか、最寄りの Microsoft ネットワーク接続点が使われているか、DNS が地理的に適切に解決されているかまで評価するため、「本社へバックホールして遠方で出ている」といった構成上の問題を検出できます。テスト結果は Microsoft 365 管理センター側で拠点ごとに集約して確認でき、改善施策の前後比較にも使えます。CQD の品質指標だけでは、実際の経路やエグレスの問題までは特定しにくく、ストレージやゲストのレポートはネットワークとは無関係です。

正解: A. A. フィードバックポリシー（Feedback Policy）

正解の根拠・詳細解説

フィードバック ポリシーは、Teams クライアントからユーザーが Microsoft へ意見や不具合報告を送る機能の可否を制御するポリシーです。フィードバックの送信自体を許可するか、アンケートの表示対象に含めるか、送信時にログやスクリーンショットといった診断情報を添付できるかといった項目を、ユーザーやグループ単位で構成できます。金融機関や公共機関のように、社外へ情報が出ることを厳密に管理したい組織では、この機能を無効化して、要望は社内の窓口に集約する運用を取ります。逆に導入初期は有効にしておき、利用者の生の声を製品側と社内改善の双方に活かす、という判断もあり得ます。設定は主に PowerShell から行うことが多いため、ポリシーの作成と割り当ての手順を押さえておきましょう。DLP、命名ポリシー、保持ポリシーはいずれも情報保護やガバナンスの機能で、フィードバック送信の可否とは関係ありません。

正解: A. A. クライアントサイドログ（Client-side logs）

正解の根拠・詳細解説

クライアント固有の不具合、たとえば起動しない、サインインが完了しない、会議に接続できない、音声デバイスが認識されないといった事象は、サーバー側の設定を見ても原因が分かりません。この場合はまず、その端末で発生した事象を記録しているクライアント側のログを取得します。Teams クライアントは、アプリの動作や接続処理を記録する診断ログと、通話・会議のメディア処理に関するログを出力でき、所定の操作でファイルとして書き出してサポートへ提出できます。ログには、失敗した処理のエラーコード、接続先エンドポイント、時刻が記録されているため、条件付きアクセスによるブロック、プロキシでの遮断、証明書の問題といった原因の切り分けが可能になります。取得の際は、事象が再現した直後に採取すること、発生時刻を控えておくことが重要です。ストレージ使用状況やアクセスレビュー、通話キューのレポートには、個々の端末の技術情報は含まれません。

正解: A. A. Teamsクライアントのキャッシュをクリアする

正解の根拠・詳細解説

Teams クライアントは、表示を高速化するために画面の構成情報やユーザーデータをローカルにキャッシュしています。このキャッシュが古い状態や壊れた状態のまま残ると、チームやチャネルが表示されない、プロフィール画像が更新されない、割り当てたはずのポリシーが反映されない、画面のレイアウトが崩れる、といった症状につながります。そこで、Teams を完全に終了させたうえでキャッシュのフォルダーを削除し、再起動して再構築させるという手順が、多くの不具合に対する最初の対処法になります。作業自体が数分で済み、メッセージやファイルは常にクラウド側に保管されているためデータ消失のリスクもないことから、費用対効果の高い切り分け手段です。これで解決しない場合に、初めて再インストールやログ採取といった重い手段へ進みます。PC の初期化や管理者ロールの変更は、問題の切り分けとして過剰、あるいは無関係な対応です。

正解: A. A. 自己診断ツール（Self-help diagnostics）

正解の根拠・詳細解説

問い合わせの多くは、ネットワーク接続、サインイン状態、権限やライセンス、デバイス設定といった定型的な原因に起因します。そこで、ユーザー自身がクライアント上から接続状況やアプリの状態を確認し、簡単な修復まで実行できる自己診断の仕組みが用意されています。Teams のヘルプ機能から診断を実行して問題箇所の指摘を受けたり、Microsoft のサポート／回復アシスタントのようなツールでサインインや接続の問題を自動チェックし、推奨される対処を提示させたりできます。管理者側でも、Microsoft 365 管理センターの診断機能から特定ユーザーの構成上の問題を確認できます。こうした自己解決の導線を用意しておくと、ヘルプデスクへの一次問い合わせが減り、担当者は本当に調査が必要な事象に集中できます。CQD や使用状況レポート、アクセスレビューはいずれも管理者向けの分析・棚卸し機能で、ユーザーが自分の環境を診断する用途のものではありません。

正解: A. A. 更新ポリシー（Update Policy）の構成内容

正解の根拠・詳細解説

複数のユーザーで同じように更新エラーが起きている場合、個々の端末固有の問題ではなく、組織側の構成を疑うのが定石です。まず確認すべきは、対象ユーザーに割り当てられている更新ポリシーの内容で、プレビュー機能の提供範囲や新しいクライアントの展開方針が意図通りかを見ます。想定と異なるポリシーが割り当てられていると、期待したバージョンに更新されない、あるいは切り替えが進まないといった事象になります。あわせて確認したいのが配布経路とネットワークで、Intune などの管理ツールで配布している場合はその展開状態、更新に必要な Microsoft のエンドポイントへプロキシやファイアウォールが到達を許可しているか、端末の権限で更新を書き込めるか、といった点が典型的な原因になります。ポリシーの変更は反映に時間を要するため、修正後は一定時間おいて再確認してください。会議カスタマイズ、命名、保持の各ポリシーはクライアントの更新とは無関係です。

正解: A. A. Teams管理センターのクライアントの健全性ダッシュボード

正解の根拠・詳細解説

個別の端末を一台ずつ調べるのではなく、組織全体を俯瞰して不健全な状態のクライアントを見つけるための管理者向け画面が用意されています。Teams 管理センターでは、ユーザーが使用しているクライアントのバージョンやプラットフォーム、接続の状況を一覧で把握でき、著しく古いバージョンに留まっている利用者を洗い出して、更新の展開状況を検証できます。会議室に設置した Teams 認定デバイスについては、デバイスの画面で正常性、サインイン状態、ファームウェアのバージョンをまとめて確認でき、オフラインの機器を即座に特定できます。古いクライアントは、既知の不具合が解消されていない、新機能が使えない、セキュリティ更新が適用されていないといった問題を抱えるため、定期的な棚卸しが重要です。CQD は通話品質、ストレージレポートは容量、アクセスレビューは権限を扱うもので、クライアントの稼働状態は分かりません。

正解: A. A. アカウントのライセンス割り当てと条件付きアクセスポリシーの状態

正解の根拠・詳細解説

サインインできないという事象は原因の候補が多いものの、確率の高い順に確認すると効率的に切り分けられます。最初に見るべきは、対象ユーザーに Teams を含むライセンスが正しく割り当てられているか（割り当て直後で反映待ちでないか、割り当てが外れていないか）と、条件付きアクセスによってブロックされていないかです。条件付きアクセスは、場所、デバイスの準拠状態、多要素認証の完了、リスク評価などの条件でアクセスを拒否するため、社外からの接続や新しい端末では意図せず弾かれることがあります。実際の原因を確定するには、Microsoft Entra 管理センターのサインイン ログでそのユーザーの試行を確認し、失敗理由のコードとどのポリシーが適用されたかを見るのが確実です。これで原因が特定できなければ、クライアントのキャッシュ削除や資格情報の再入力へ進みます。ストレージ使用量、通話キュー、会議テンプレートはサインインとは無関係です。

正解: A. A. Copilotの利用ログとプロンプト内容の確認

正解の根拠・詳細解説

Copilot の応答が不適切だったという報告に対しては、まず何が入力され、何を根拠に生成されたのかという事実確認から始めます。ユーザーがどのようなプロンプトを入力したかを確認し、あわせて Copilot が参照できたデータ（会議の文字起こしが存在したか、参照対象のチャットやファイルにそのユーザーがアクセス権を持っていたか）を点検します。Copilot はユーザーの権限の範囲でしかデータを参照しないため、必要な情報にアクセスできていなければ、当然ながら不完全な回答になります。会議の要約に関する事象であれば、文字起こしが有効だったか、認識言語の設定が話されている言語と一致していたか、といった点が典型的な原因です。あわせて、対象ユーザーに Copilot のライセンスが割り当てられているか、会議ポリシーで Copilot がどの構成になっているかを確認します。通話キューや命名ポリシー、会議テンプレートは Copilot の動作と関係ありません。

正解: A. A. 対象ユーザーに割り当てられている会議ポリシー

正解の根拠・詳細解説

会議に参加できない、録画やライブキャプションのボタンが出てこない、といった問い合わせの多くは、障害ではなくポリシーによる制限が原因です。そのため、まず対象ユーザーに割り当てられている会議ポリシーを確認します。Teams 管理センターでユーザーを開くと、そのユーザーに現在適用されている各種ポリシーが表示されるため、録画、文字起こし、画面共有、匿名参加、会議の開催可否といった該当項目の値を確認し、期待する設定になっているかを照合します。あわせて押さえておきたい実務上の要点として、ポリシーの変更や割り当ては即座に反映されるとは限らず、反映までに時間を要すること、そしてクライアントを再起動しないと表示が更新されない場合があることが挙げられます。特定の会議だけで機能が使えない場合は、その会議に適用された会議テンプレートや会議オプションの設定も確認します。アプリストアの設定やストレージ、CQD のレポートは、この切り分けには使いません。

正解: A. A. その拠点に関するCQDの品質指標とNetwork Assessment Toolの結果

正解の根拠・詳細解説

症状が特定の拠点に集中しているという情報は、原因がクライアント個別ではなくネットワーク側にあることを強く示唆します。そこでまず CQD で該当拠点の指標を確認し、パケットロス、ジッター、往復遅延のどれが悪化しているのか、有線と無線のどちらで発生しているのか、時間帯による偏りがあるのかを把握します。この分析を成立させるには、サブネットと拠点を対応づけたビルディングデータファイルをあらかじめ登録しておく必要があります。傾向をつかんだうえで、Microsoft Teams Network Assessment Tool を現地で実行し、実際に測定した遅延・パケットロス・ジッターが推奨値を満たしているかを検証します。あわせて確認すべき典型的な原因は、リアルタイムメディアに必要な UDP が塞がれていて TCP にフォールバックしている、プロキシや検査装置をメディアが経由している、QoS が設定されておらず混雑時に音声が他のトラフィックに埋もれている、無線アクセスポイントの収容過多、といったものです。

正解: A. A. デバイスのファームウェアバージョンとネットワーク接続状態

正解の根拠・詳細解説

会議室デバイスが繰り返しオフラインになる場合、原因はデバイス自体の状態かネットワークのいずれかにあることがほとんどです。まず Teams 管理センターのデバイス画面で、そのデバイスのファームウェアやアプリのバージョンが最新か、既知の不具合が修正されたバージョンに追いついているかを確認し、必要なら更新を適用します。次にネットワーク側として、有線・無線の物理的な接続状態、IP アドレスの取得（DHCP のリース切れや重複）、Teams が必要とするエンドポイントへの到達がファイアウォールやプロキシで妨げられていないか、無線であれば電波強度とアクセスポイントの収容状況を確認します。あわせて、デバイスに割り当てたリソースアカウントの資格情報が失効してサインアウトしていないか、パスワードの有効期限やアカウントの条件付きアクセスの影響がないかも典型的な原因です。デバイスタグで拠点ごとに絞り込むと、単独の障害か拠点全体の問題かを切り分けやすくなります。

正解: A. A. Microsoft Purview監査ログの統合的な確認

正解の根拠・詳細解説

根本原因分析では、点在する情報をつなぎ合わせて時系列を再構成することが不可欠です。Microsoft Purview の監査ログは、Teams のチーム作成・削除、メンバーやゲストの追加、チャネルの操作、ポリシーや管理設定の変更、ファイルへのアクセスや共有といった多様なイベントを、統合されたログとして日時・実行者・対象で検索できるため、「いつ設定が変わり、その直後から何が起き始めたのか」を追跡できます。結果は CSV に出力でき、Microsoft Graph の監査 API を使えば SIEM へ取り込んで他のログと相関分析することも可能です。運用上の注意点として、監査ログの保持期間はライセンスによって異なるため、長期の遡及調査が必要な組織では定期的なエクスポートやログ基盤への転送を検討します。CQD は通話品質、ストレージレポートは容量、会議テンプレートは会議設定と、いずれも単独では特定の側面しか示さず、横断的な因果関係の追跡には向きません。

正解: A. A. 使用状況・品質レポートを定期的にレビューし、ポリシーや構成を見直す

正解の根拠・詳細解説

Teamsの利用品質は、ネットワーク構成の変更、クライアントの更新、在宅勤務の増減といった環境変化によって常に揺れ動くため、導入時の設定を固定したままでは劣化に気付けない。そこでTeams管理センターの使用状況レポートで機能ごとの利用状況や定着度を確認し、通話品質ダッシュボードでジッター、パケット損失、ラウンドトリップ時間といった指標を継続的に監視する。そこから品質の悪い拠点やサブネット、特定の機種やドライバーに問題が偏っていないかを特定し、ネットワークやQoSの見直し、会議ポリシー・通話ポリシーの調整につなげるという改善サイクルを回すことが管理者の役割になる。Bのように初期設定を変えない運用は環境変化に追随できず、Cのように問い合わせを記録しなければ再発防止に必要な傾向分析ができない。Dの目視確認だけでは客観的な数値の裏付けがなく、対策を打った後の効果測定もできない。