Microsoft Teamsの「Microsoft Teams: Screen & Window Sharing on Mac via macOS native experience」は、Mac版Teamsで画面全体または特定ウィンドウを共有するときに、macOS標準の共有体験を使えるようにする機能です。結論から言うと、対象はMacのみ、ユーザーが自分で有効化するオプトイン方式で、GAは2025年12月、2026年6月時点のロードマップ上の状態は「Launched」です。管理者は、Teamsの会議ポリシーだけでなく、macOSの画面収録権限、リモート制御の扱い、社内手順書の更新まで確認しておく必要があります。(Microsoft)
この変更は「画面共有ボタンの見た目が少し変わる」だけではありません。Mac利用者にとっては共有対象を選びやすくなる一方、ネイティブmacOS共有ではGive control / Take controlがサポートされないため、ヘルプデスク対応、研修、ペア作業でTeamsのリモート操作を使っている組織は事前確認が必要です。(Microsoft サポート)
Microsoft TeamsのMac向け画面共有で変わること
今回の変更により、MacユーザーはTeams会議中に画面全体または特定のウィンドウを共有する際、macOSに組み込まれたネイティブの共有ピッカーを使えるようになります。Microsoftのロードマップでは、対象サービスはMicrosoft Teams、対象プラットフォームはMac、クラウドはWorldwide、GCC、GCC High、DoDとされています。(Microsoft)
従来のTeams画面共有は、Teams側の共有トレイから画面やウィンドウを選ぶ体験が中心でした。新しい方式では、Macの標準的な共有UIに寄せることで、macOSに慣れているユーザーにとって操作の一貫性が高まります。
| 比較項目 | 従来のTeams共有 | macOSネイティブ共有 |
|---|---|---|
| 共有対象の選択 | Teams側の共有UIで選択 | macOS標準の共有体験で選択 |
| 対象端末 | Teamsクライアントの仕様に依存 | このロードマップ項目ではMacのみ |
| 有効化方法 | 通常の共有操作 | ユーザーがTeams設定で有効化 |
| 再起動 | 状況により必要な場合あり | 設定変更後、Teamsの再起動は不要と案内 |
| リモート制御 | ポリシーと環境により利用可能 | Give control / Take controlは非対応 |
| 主な確認点 | Teams会議ポリシー | Teams会議ポリシー、macOS権限、ユーザー教育 |
特に重要なのは、この機能が「Macのみ」「ユーザーオプトイン」である点です。管理者がテナント全体に一括で体験を強制するというより、MacユーザーがTeamsの設定から選択して使う機能として理解すると整理しやすくなります。(Microsoft)
公式ロードマップ上の対象範囲と提供状況
Microsoft 365 Roadmap ID 502523の情報を整理すると、次のようになります。なお、Microsoft 365 Roadmapの情報は変更される可能性があるため、実際の展開前には管理センターやメッセージセンターでも確認するのが安全です。(Microsoft)
| 項目 | 内容 |
|---|---|
| 機能名 | Microsoft Teams: Screen & Window Sharing on Mac via macOS native experience |
| Roadmap ID | 502523 |
| 対象サービス | Microsoft Teams |
| 対象プラットフォーム | Mac |
| 対象クラウド | Worldwide、GCC、GCC High、DoD |
| リリース | General Availability、Targeted Release |
| GA | 2025年12月 |
| ステータス | Launched |
| 初回公開 | 2025年9月8日 |
| 更新日 | API上のmodifiedは2026-06-02T23:00:40Z。日本時間では2026年6月3日相当 |
GAが2025年12月で、2026年6月時点ではLaunchedとされているため、今後の準備というより「Macユーザーの運用にすでに入ってくる前提」で確認すべき段階です。ただし、Microsoft 365の機能展開はテナント、リリースリング、クライアント更新状況によって見え方がずれることがあります。
ユーザー側の有効化手順
Mac版TeamsでネイティブmacOS共有を使うには、ユーザーがTeamsの設定から有効化します。Microsoftのサポート情報では、Teamsの「Settings and more」から「Settings」を開き、「General」内の「Screen sharing」で「Use macOS content sharing」を選択すると案内されています。変更はすぐ反映され、Teamsの再起動は不要です。(Microsoft サポート)
実際の案内文に落とし込むなら、社内向けには次のように書くと分かりやすくなります。
| 手順 | 操作 |
|---|---|
| 1 | MacでMicrosoft Teamsを開く |
| 2 | 右上の「…」または「Settings and more」を開く |
| 3 | 「Settings」を選択 |
| 4 | 「General」を開く |
| 5 | 「Screen sharing」で「Use macOS content sharing」を選択 |
| 6 | 会議中に「Share」を押し、共有する画面またはウィンドウを選ぶ |
注意したいのは、Teams側の設定だけで完了しない場合があることです。Macでは画面や音声を記録・共有できるアプリをユーザーが許可する仕組みがあり、Appleの設定画面では「Privacy & Security」から「Screen & System Audio Recording」を開き、アプリごとに許可をオン・オフできます。(Appleサポート)
管理者が確認すべきTeams側の設定
この機能はユーザーオプトインですが、Teamsの会議ポリシーを無視して画面共有できるようになるわけではありません。Microsoft Learnでは、画面共有モードはユーザー単位のポリシーであり、デスクトップやウィンドウを共有できるかを制御すると説明されています。(Microsoft Learn)
| 確認項目 | 見る場所 | 判断基準 |
|---|---|---|
| Screen sharing mode | Teams管理センター > Meetings > Meeting policies > Content sharing | 画面全体・アプリ共有を許可するか、単一アプリのみにするか、無効にするか |
| Participants can give or request control | 同じくContent sharing | 参加者同士のリモート制御を許可するか |
| External participants can give or request control | 同じくContent sharing | 外部参加者の制御要求を許可するか |
| 対象ユーザーのポリシー割り当て | Teams管理センターまたはPowerShell | Macユーザー、役員、営業、サポート担当などに意図したポリシーが当たっているか |
| ヘルプデスク向け検証アカウント | 対象リリースまたは検証用ポリシー | 問い合わせ対応前に同じ体験を再現できるか |
Teams管理センターの表示では「Entire screen」「Single application」「Not enabled」のように整理されます。一方、PowerShellのSet-CsTeamsMeetingPolicyでは、ScreenSharingModeにEntireScreen、SingleApplication、Disabledを指定します。管理センター上の「Not enabled」とPowerShell上の「Disabled」を混同しないようにしましょう。(Microsoft Learn)
設定確認の例は次のとおりです。本番のGlobalポリシーを直接変更する前に、検証用ポリシーで動作を確認することをおすすめします。
Get-CsTeamsMeetingPolicy -Identity "Global" |
Select-Object Identity, ScreenSharingMode, AllowParticipantGiveRequestControl, AllowExternalParticipantGiveRequestControl画面全体の共有を許可する例です。
Set-CsTeamsMeetingPolicy -Identity "PolicyName" -ScreenSharingMode EntireScreen参加者のGive control / Request controlを許可する例です。
Set-CsTeamsMeetingPolicy -Identity "PolicyName" -AllowParticipantGiveRequestControl $trueただし、ここで注意が必要です。Teamsポリシー上でGive control / Request controlを許可していても、macOSネイティブ共有体験では、提示されたコンテンツに対するGive control / Take controlがサポートされません。(Microsoft サポート)
移行・展開で失敗しやすいポイント
リモート操作が必要な業務では既定手順を分ける
一番つまずきやすいのは、画面共有とリモート制御を同じものとして扱ってしまうことです。
たとえば、次のような業務ではGive control / Take controlを使っている可能性があります。
| 業務シーン | 影響 | 対応 |
|---|---|---|
| ヘルプデスクがユーザーの画面を操作して設定を直す | ネイティブmacOS共有では操作を引き継げない | 必要に応じて従来のTeams共有方式や別のリモートサポート手段を案内 |
| 社内研修で講師が受講者の操作を補助する | 画面は見えても直接操作できない | 演習前に共有方式を指定する |
| 開発レビューで相手のIDEやブラウザーを操作する | ペア作業の流れが止まる | 操作担当者が自分の画面を共有する運用に切り替える |
| 外部ベンダーとのトラブルシュート | 外部参加者の制御ポリシーとネイティブ共有制限の両方が関係 | 会議前に制御が必要か確認する |
Macユーザー全員に「新しい共有方式のほうが便利」とだけ案内すると、リモート制御が必要な場面で混乱します。社内FAQには「画面を見せるだけならmacOSコンテンツ共有」「相手に操作してもらう可能性がある場合は従来方式を検討」という判断基準を入れておくと実務で役立ちます。
macOSの権限プロンプトを録画機能と誤解されやすい
Macの画面共有では、OS側で「Screen & System Audio Recording」権限が関係します。ユーザーから見ると「録画」と表示されるため、「会議が録画されるのではないか」と誤解されることがあります。
社内通知では、次のように説明すると問い合わせを減らせます。
| ユーザーの疑問 | 回答例 |
|---|---|
| 画面収録を許可すると会議が録画される？ | いいえ。Macが画面共有に必要な権限を確認している表示です。Teams会議の録画開始とは別です。 |
| Teamsを許可しても共有できない | Teamsを完全に終了して開き直す、macOSを最新状態にする、不要なアプリを閉じるなどを試します。 |
| Teams on the webの場合は？ | Teamsアプリではなく、利用中のブラウザーにも画面収録権限が必要です。 |
| 管理対象Macで設定できない | 端末管理ポリシーの制約があるため、IT管理者に連絡します。 |
Microsoftのサポート情報でも、Macで画面共有する前にTeamsへ画面収録権限を付与する必要があり、Teams on the webではブラウザーにも権限が必要と案内されています。(Microsoft サポート)
MDMやIntuneで権限を完全に吸収できるとは限らない
MacをIntune、Jamf、Addigyなどで管理している組織では、PPPCペイロードを使ってプライバシー設定を管理していることがあります。Appleのドキュメントでは、PPPCペイロードによりMacの「Security & Privacy」内のプライバシー設定を管理できると説明されていますが、デバイス管理サービスごとに実装が異なるため、詳細は利用中のMDMの仕様確認が必要です。(Appleサポート)
運用上は、次の観点で検証しましょう。
| 確認項目 | 見落とすと起きること |
|---|---|
| 標準ユーザーが画面収録権限を許可できるか | 管理者権限がないため会議直前に共有できない |
| Teamsのアプリ識別子やパスが正しいか | PPPC設定を配ってもTeamsに適用されない |
| Teams更新後も権限が維持されるか | アプリ更新後に再許可が必要と誤認される |
| ブラウザー版Teamsを許可対象に含めるか | Safari、Chrome、Edge利用時だけ共有できない |
| 社内DLPやEDRとの相性 | 画面共有中に警告やブロックが出る |
特に、営業や役員など「会議中にすぐ共有できないと業務影響が大きい」ユーザーには、展開前に実機で共有テストを済ませておくべきです。
DisplayLinkやドッキングステーション利用者を先に検証する
Microsoftのサポート情報では、macOS 14以降でDisplayLinkまたは一部のドッキングステーションを使う場合、共有インジケーターやコントロールパネルに影響する既知の問題があると案内されています。(Microsoft サポート)
MacBook単体では問題がなくても、実際の業務環境では外部モニター、USB-Cドック、DisplayLinkアダプターを併用しているケースが少なくありません。次の環境は優先的にテストしましょう。
| テスト環境 | 理由 |
|---|---|
| 外部モニター2枚以上 | 共有対象の画面選択ミスが起きやすい |
| DisplayLinkドック | 既知の表示・操作系の問題に該当する可能性がある |
| クラムシェルモード | 内蔵画面と外部画面の扱いが変わる |
| 会議室据え置きMac | 利用者が毎回異なり、権限トラブルが発見されにくい |
| 高解像度モニター | 共有中の表示遅延や見切れを確認したい |
セキュリティと情報漏えい対策の見直しポイント
macOSネイティブ共有により共有体験は分かりやすくなりますが、画面全体の共有は引き続き情報漏えいリスクがあります。Microsoft Learnでも、画面全体の共有は便利な一方、メールや開いている文書など不適切な情報を誤って共有する可能性が高まるため、機密情報を扱う部門では単一アプリ共有への制限を検討するよう説明されています。(Microsoft Learn)
部門別には、次のような考え方が現実的です。
| 部門・ユーザー | 推奨設定の考え方 |
|---|---|
| 経理・人事・法務 | 原則として単一アプリ共有を優先。画面全体共有は限定的に許可 |
| 営業・カスタマーサクセス | 顧客デモで画面全体が必要な場合があるため、事前チェックリストを整備 |
| 開発・情シス | 複数ウィンドウを使うため画面全体共有が便利。ただしチャット、メール、認証画面の映り込みに注意 |
| 役員・管理職 | 機密文書を開いたまま共有しやすいため、事前に通知とデスクトップ整理を徹底 |
| 教育・研修担当 | 共有方式とリモート制御の可否を研修前に固定 |
「Macの共有UIになるから安全」と単純に考えるのではなく、何を共有できるポリシーにするか、誰が制御を要求できるか、外部参加者をどう扱うかをセットで見直すことが重要です。
開発者・社内ツール担当が確認すべきこと
このロードマップ項目は、少なくとも公開情報上はTeamsアプリ開発者向けAPIやGraph APIの変更として案内されているものではなく、Mac版Teamsの画面・ウィンドウ共有体験の変更として整理されています。(Microsoft)
ただし、開発者や社内ツール担当に影響がないわけではありません。特に、ユーザーがTeams会議で自社アプリや業務システムを共有する場面が多い場合は、次を確認しておくと安全です。
| 確認対象 | 検証内容 |
|---|---|
| Webアプリ | ブラウザーのウィンドウ共有でモーダル、ポップアップ、別タブ遷移が問題なく見えるか |
| デスクトップアプリ | 共有対象としてアプリウィンドウが正しく表示されるか |
| 認証画面 | 共有中にワンタイムパスコード、個人情報、管理画面が映り込まないか |
| 研修用デモ環境 | 講師が操作を引き継げない前提で進行できるか |
| サポート手順書 | スクリーンショットが従来のTeams共有UIのままになっていないか |
開発チームの実務では、機能そのものより「画面共有される前提のUI」が問題になります。たとえば、デモ中に通知トーストで個人名が出る、管理画面の左メニューに顧客名が出る、別ウィンドウの認証ダイアログが共有されないといった細かい挙動は、会議本番で初めて気づくと対応が難しくなります。
展開前に用意したい社内向けチェックリスト
Macユーザーが多い組織では、次の順番で確認すると抜け漏れを減らせます。
| 順番 | 実施内容 | 完了基準 |
|---|---|---|
| 1 | Mac利用者の多い部門を洗い出す | 営業、開発、役員、サポートなど優先対象が分かっている |
| 2 | Teams会議ポリシーを確認する | ScreenSharingModeと制御系ポリシーの意図が明確 |
| 3 | 検証用Macで有効化する | 「Use macOS content sharing」が表示され、共有できる |
| 4 | macOS権限を確認する | Screen & System Audio RecordingでTeamsを許可できる |
| 5 | 外部モニター環境で試す | ドック、DisplayLink、複数画面で共有対象を誤らない |
| 6 | Give/Take controlの代替手順を決める | ヘルプデスクが案内できる |
| 7 | 社内FAQを更新する | ユーザーが自力で設定場所と注意点を確認できる |
| 8 | 問い合わせ窓口に共有する | 「共有できない」「制御できない」への一次回答が揃っている |
対象リリースを使って事前検証する場合は、Microsoft 365管理センターで選択したユーザーに早期アクセスを付与できます。Microsoftのドキュメントでは、対象リリースを使うことで、全ユーザー展開前のテスト、ユーザー通知やドキュメントの準備、社内ヘルプデスクの準備、セキュリティレビューなどに役立つと説明されています。(Microsoft Learn)
また、TeamsのPublic Previewはユーザー単位で有効になり、管理者ポリシーで制御されます。検証対象者を絞る場合は、Teams管理センターの更新ポリシーでプレビュー機能の表示を管理する流れも確認しておきましょう。(Microsoft Learn)
ユーザーに伝えるべき短い案内文
社内告知では、長い仕様説明よりも「何をすればよいか」を先に伝える方が効果的です。以下の文面をベースにすると、問い合わせを減らしやすくなります。
Mac版Microsoft Teamsでは、画面共有時にmacOS標準の共有画面を使えるようになりました。利用する場合は、Teamsの「Settings」>「General」>「Screen sharing」から「Use macOS content sharing」を選択してください。初回共有時にMacの「Screen & System Audio Recording」権限を求められた場合は、Microsoft Teamsを許可してください。なお、この共有方式では相手に画面操作を渡すGive control / Take controlは利用できません。リモート操作が必要な会議では、事前にIT部門の手順を確認してください。
この案内に加えて、スクリーンショット付きの1ページ手順を社内ポータルに置いておくと、会議直前の問い合わせを減らせます。
まとめ：Macユーザーには便利だが、管理者はリモート制御と権限を必ず確認する
Microsoft TeamsのMac向けネイティブ画面共有は、Macユーザーにとって共有対象を選びやすくする実用的な改善です。対象はMacのみで、ユーザーが自分で有効化するオプトイン方式です。GAは2025年12月、ロードマップ上ではLaunchedとなっています。(Microsoft)
一方で、展開時に見るべきポイントは明確です。Teams会議ポリシーで画面共有の範囲を確認し、macOSの画面収録権限をユーザーが許可できる状態にし、Give control / Take controlが使えない前提でサポートや研修の手順を見直しましょう。
次に取るべき行動は、Mac利用者の多い部門を選び、実機で「共有できるか」「外部モニターで問題ないか」「リモート制御が必要な業務に支障がないか」を確認することです。その結果をもとに、Teams会議ポリシー、MDM設定、社内FAQを更新すれば、利用者の混乱を抑えながら新しい共有体験へ移行できます。
コメント