Microsoft Teamsの「Annotations on Teams Single Window Sharing on macOS」は、Mac版Teamsで単一のアプリケーションウィンドウだけを共有しながら、その上に参加者が直接注釈できるようにする更新です。画面全体を見せずに、資料・ブラウザー・デザインツールなど必要な内容だけを共有できるため、プレゼンの見やすさ、プライバシー保護、会議中のフィードバック効率を同時に高められます。Microsoft 365 Roadmap ID 559611では、対象サービスはMicrosoft Teams、対象プラットフォームはMac、一般提供は2026年5月、ステータスはLaunchedとされています。更新日時はUTCで2026年6月2日23:00のため、日本時間では2026年6月3日の更新として扱えます。(Microsoft)
Microsoft Teamsの「Annotations on Teams Single Window Sharing on macOS」で何が変わるのか
今回の変更点は、単なる「注釈機能の追加」ではありません。重要なのは、macOS上のTeamsで、全画面共有ではなく単一ウィンドウ共有に注釈を組み合わせられる点です。
これにより、発表者はデスクトップ全体を見せずに、共有対象のアプリケーションだけを参加者に見せられます。参加者はその共有内容の上に、ペンやハイライトなどで直接指摘できます。Microsoftの説明では、トレーニング、ワークショップ、顧客との打ち合わせなどで、より焦点の合った対話を実現する機能とされています。(Microsoft)
| 観点 | 従来ありがちだった運用 | 今回の更新後 |
|---|---|---|
| 共有範囲 | 注釈を使うために画面全体を共有しがち | 単一アプリケーションウィンドウだけを共有できる |
| プライバシー | 通知、別アプリ、デスクトップ上のファイル名が見えるリスクがある | 共有対象外の画面を見せずに済む |
| フィードバック | 「右上のボタン」「3行目の項目」など口頭説明に頼りがち | 参加者が対象箇所を直接囲む、線を引く、強調できる |
| 会議の進行 | 指摘箇所の確認に時間がかかる | 認識合わせが速くなり、議論が脱線しにくい |
| 管理面 | 共有・注釈・Whiteboard設定を別々に意識する必要がある | 既存のTeams会議ポリシーを前提に展開状況を確認する |
たとえば、顧客向けの提案会議でブラウザーの管理画面だけを共有し、顧客が気になる項目をその場でハイライトする、といった使い方ができます。社内研修でExcelの操作画面だけを共有し、受講者が分かりにくいセルやボタンを指し示す用途にも向いています。
対象範囲とリリース状況
Microsoft 365 Roadmap上の情報を整理すると、対象は次の通りです。
| 項目 | 内容 |
|---|---|
| Roadmap ID | 559611 |
| 機能名 | Microsoft Teams: Annotations on Teams Single Window Sharing on macOS |
| 対象サービス | Microsoft Teams |
| 対象プラットフォーム | Mac |
| クラウド | Worldwide Standard Multi-Tenant |
| リリースリング | Targeted Release、General Availability |
| 一般提供時期 | 2026年5月 |
| ステータス | Launched |
| 主な効果 | 単一アプリケーションウィンドウ共有中に注釈を利用可能 |
Roadmapのリリース日はあくまで予定・見込みとして扱う必要があります。Microsoft 365 Roadmap自体も、商用機能の予定日や説明は変更される可能性があり、一般提供、延期、キャンセルなどに応じて掲載内容が変わると説明しています。(Microsoft)
実務では、「RoadmapでLaunchedになっているから全ユーザーで必ず同じ日に使える」と考えるのではなく、テナント、Teamsクライアントの更新状況、会議ポリシー、Whiteboard関連設定を合わせて確認するのが安全です。
ユーザーにとってのメリット
画面全体を見せずに済むため、情報漏えいリスクを下げやすい
単一ウィンドウ共有では、共有したいアプリケーションだけを見せられます。メール通知、チャット通知、デスクトップ上のファイル名、別ブラウザータブなどを不用意に見せるリスクを抑えられます。
ただし、共有しているウィンドウ内に機密情報が表示されていれば、その内容は当然参加者に見えます。単一ウィンドウ共有は「共有範囲を絞る機能」であり、「表示中の機密情報を自動的に隠す機能」ではありません。
口頭説明よりも指摘が速くなる
画面共有中の議論では、「左側のメニューの上から3つ目」「右下の小さいリンク」など、場所の説明に時間がかかりがちです。注釈を使えば、参加者が直接丸で囲んだり、線を引いたりできるため、認識合わせが速くなります。
特に効果が出やすい場面は次の通りです。
| 活用シーン | 具体例 |
|---|---|
| 社内研修 | 操作手順の中で受講者がつまずいたボタンをその場で指摘する |
| 顧客提案 | 提案資料やWeb画面の気になる箇所を顧客が直接ハイライトする |
| UIレビュー | デザインツールやWebアプリの画面で修正箇所を囲む |
| 障害対応 | 管理画面やログビューアーの確認箇所を参加者間で共有する |
| 業務マニュアル確認 | 手順書のどの説明が分かりにくいかを画面上で示す |
発表者は注釈できる人を制御できる
Teamsの注釈機能では、発表者が「全員が注釈できる」状態にするか、「自分だけが注釈できる」状態にするかを選べます。設定はWhiteboardツールセットから切り替えられ、変更はすぐに適用されます。(マイクロソフトサポート)
顧客向け説明会や役員会議では、最初は発表者のみ注釈可能にしておき、質疑応答のタイミングで参加者の注釈を許可する運用が現実的です。全員に常時許可すると、意図しない書き込みで画面が見づらくなることがあります。
管理者が確認すべきTeams会議ポリシー
今回の機能はユーザー体験の改善ですが、管理者は既存のTeams会議ポリシーを確認しておく必要があります。Microsoft Learnでは、Teams管理センターの「Meetings > Meeting policies」からContent sharing関連の設定を管理でき、PowerShellではSet-CsTeamsMeetingPolicyの各パラメーターで制御できると説明されています。(Microsoft Learn)
特に確認したいのは、次の項目です。
| 確認項目 | 見るべき設定 | 判断基準 |
|---|---|---|
| 画面共有が許可されているか | ScreenSharingMode | Not enabledだと画面共有・アプリ共有が無効。単一アプリ共有を使うなら少なくともアプリ共有が許可されている必要がある |
| 注釈が許可されているか | AllowCollaborativeAnnotations | 無効だとユーザーは注釈を利用できない |
| Whiteboardが利用可能か | Whiteboard関連設定、AllowWhiteboard | 注釈はWhiteboardと関連するため、Whiteboard無効化ポリシーの影響を確認する |
| 対象ユーザーのポリシー | グローバルポリシー、部門別ポリシー、役職別ポリシー | 経営層、営業、研修担当、開発部門など、実際に画面共有するユーザーに割り当てられているか確認する |
| Mac版Teamsの展開状況 | Teamsクライアント更新、管理対象端末の更新リング | 機能がテナントに来ていても、古いクライアントでは期待通りに表示されない可能性がある |
ScreenSharingModeには、デスクトップ共有とアプリ共有を許可する値、アプリ共有のみを許可する値、共有自体を無効にする値があります。Microsoft Learnでは、Entire screenはデスクトップ共有とアプリ共有を許可し、Single applicationはアプリ共有を許可し、Not enabledは画面共有とアプリ共有をオフにすると説明されています。(Microsoft Learn)
PowerShellで確認する場合は、次のような観点で棚卸しするとよいでしょう。
Get-CsTeamsMeetingPolicy |
Select-Object Identity, ScreenSharingMode, AllowWhiteboard, AllowCollaborativeAnnotationsテスト用ポリシーで注釈を有効にする例は次の通りです。
Set-CsTeamsMeetingPolicy -Identity "Test-MeetingPolicy" -AllowCollaborativeAnnotations $true本番環境では、いきなりGlobalポリシーを変更するのではなく、営業、研修担当、情報システム部門など、利用頻度が高い小規模グループで確認してから展開するのが安全です。
Whiteboardと保存・コンプライアンス面の注意点
Teamsの注釈は、Microsoft Whiteboardと関連する機能です。Microsoft Supportでは、注釈はWhiteboardによって提供され、画面共有中のデザインやプレゼンテーション上で共同作業するための機能と説明されています。(マイクロソフトサポート)
また、注釈のスナップショットを保存すると、Whiteboardファイルとして後から参照できます。スナップショットには、保存時点で共有されていた画面上に注釈が重なった状態が表示されます。(マイクロソフトサポート)
このため、管理者は次の点を利用者に周知しておくべきです。
| 注意点 | 説明 |
|---|---|
| 注釈は正式な文書修正ではない | 画面上の指摘であり、元のWord、Excel、PDF、設計書が自動修正されるわけではない |
| スナップショットに情報が残る可能性がある | 機密情報が表示された画面で注釈を保存すると、その内容も残る可能性がある |
| 共有中の画面は録画やスクリーンショットに残る可能性がある | 会議録画や参加者側のキャプチャ運用を考慮する |
| Whiteboardの管理設定と整合させる必要がある | Whiteboardを制限している組織では、注釈機能の挙動も合わせて検証する |
| 顧客・外部ユーザーとの会議では事前ルールが必要 | 誰が注釈できるか、保存してよいか、会議後に削除が必要かを決める |
「画面全体を共有しないから安全」と考えるのではなく、「共有しているウィンドウ内の情報は参加者に見える」「注釈やスナップショットが残る場合がある」という前提で運用しましょう。
ヘルプデスクが把握しておきたい問い合わせパターン
リリース後に問い合わせが増えやすいのは、機能そのものよりも「自分の環境ではボタンが見えない」「参加者が書き込めない」といった差分です。ヘルプデスク向けには、次の切り分け表を用意しておくと対応が速くなります。
| 問い合わせ | 主な確認ポイント | 対応の方向性 |
|---|---|---|
| 注釈ボタンが表示されない | Mac版Teamsか、クライアントが最新か、対象テナントに展開済みか | Teams更新、再起動、展開状況の確認 |
| 単一ウィンドウ共有で注釈できない | 会議ポリシー、AllowCollaborativeAnnotations、Whiteboard設定 | 管理ポリシーを確認 |
| 参加者が注釈できない | 発表者が「Only I can annotate」にしていないか | 発表者の注釈権限設定を確認 |
| 注釈が邪魔で画面が見づらい | 全員が自由に書き込める状態になっていないか | 発表者のみ注釈、または注釈のクリアを案内 |
| 注釈を後から見返したい | スナップショット保存の有無 | Whiteboard側で保存先を確認 |
| 顧客会議で使ってよいか分からない | 機密情報、録画、保存、外部共有ルール | 社内の会議・情報管理ルールに従う |
Microsoft Supportでは、発表者は注釈をオフにでき、前回の注釈は再開時に表示される場合があり、必要に応じて注釈をクリアできると説明されています。(マイクロソフトサポート)
管理者向けの展開チェックリスト
この機能は大規模な移行作業を伴うものではありません。ただし、現場で混乱を起こさないためには、展開前後に最低限の確認をしておくべきです。
| ステップ | やること | 完了の目安 |
|---|---|---|
| RoadmapとMessage Centerを確認 | Roadmap ID 559611の状態、テナントへの展開状況を確認する | 対象テナントで利用可能時期を把握している |
| 会議ポリシーを棚卸し | ScreenSharingMode、AllowWhiteboard、AllowCollaborativeAnnotationsを確認する | Mac利用者に必要な共有・注釈設定が割り当てられている |
| Macユーザーで検証 | 実際に単一ウィンドウ共有を開始し、注釈ボタンと参加者の書き込みを確認する | 発表者・参加者の両方で動作を確認済み |
| 社内マニュアルを更新 | 「画面全体」ではなく「共有したいウィンドウのみ」を選ぶ手順を追加する | スクリーンショット付き手順が用意されている |
| 利用ルールを周知 | 顧客会議、研修、録画会議での注釈利用ルールを伝える | 保存・録画・機密情報の扱いが明確になっている |
| ヘルプデスクFAQを整備 | ボタンがない、参加者が書けない、保存先が分からない場合の回答を用意する | 初回問い合わせに一次対応できる |
特に見落としやすいのは、管理者が「注釈機能は便利だから有効でよい」と判断しても、部門別ポリシーで画面共有自体が制限されているケースです。研修部門や営業部門だけ別ポリシーを使っている組織では、Globalポリシーだけ見ても不十分です。
開発者・アプリ担当者が確認すべきポイント
この更新は、TeamsアプリのAPIやアプリマニフェスト変更を求めるものではありません。したがって、通常のTeamsアプリ開発者がコードを修正する必要は基本的にありません。
一方で、Webアプリ、SaaS管理画面、社内ツールをTeams会議でデモする機会が多い開発者やプロダクト担当者は、見せ方の標準手順を見直す価値があります。
デモ手順を「全画面共有」前提から見直す
顧客デモや社内レビューでは、全画面共有を前提にした手順書が残っていることがあります。今回の更新を活かすなら、次のように変えると実用的です。
| 旧手順 | 新手順 |
|---|---|
| デスクトップ全体を共有する | デモ対象のアプリケーションウィンドウだけを共有する |
| 口頭で修正箇所を確認する | 参加者に注釈で直接示してもらう |
| 会議後にチャットで指摘事項を集める | 重要な指摘は会議中に整理し、必要に応じてスナップショットを保存する |
| デモ用環境と普段の作業環境が混在する | デモ専用ブラウザプロファイルやテスト環境を用意する |
注釈とアプリ操作が衝突しないか確認する
Webアプリやデザインツールでは、ドラッグ操作、ホバー表示、キャンバス操作などが多く使われます。注釈モード中は画面上に描画するため、アプリ本来の操作と混同することがあります。
Microsoft Supportでは、発表者は注釈中に背景コンテンツを操作でき、ページのスクロールやスライド送りなども可能と説明されています。(マイクロソフトサポート)
ただし、実際の会議では「今は注釈する時間」「今はアプリを操作する時間」を分けたほうが進行しやすくなります。レビュー会議では、発表者が次のように宣言すると混乱を防げます。
ここから1分間は注釈で気になる箇所を示してください。その後、注釈を止めて実際の操作に戻ります。
失敗しやすいポイントと対策
全画面共有の癖が残る
機能が使えるようになっても、ユーザーが従来通り全画面共有を選んでしまうと、プライバシー面のメリットは得られません。研修資料や社内Tipsでは、「共有」ボタンを押した後に対象ウィンドウだけを選ぶことを明記しましょう。
注釈を議事録代わりにしてしまう
注釈は、その場の認識合わせには便利ですが、正式な議事録や修正依頼の代わりにはなりません。会議後に残すべき内容は、Planner、Loop、Teamsチャット、チケット管理ツール、設計書などに転記する運用が必要です。
全員に注釈を許可したまま重要会議を進める
ワークショップでは全員が書き込める状態が有効ですが、顧客説明や経営会議では画面が乱れる原因になります。発表者は、必要に応じて「自分だけが注釈できる」設定に切り替えるべきです。Teamsでは発表者が注釈できる人を選べるため、会議の性質に合わせて使い分けましょう。(マイクロソフトサポート)
Whiteboardを無効化している組織で見落とす
Microsoft Learnでは、Collaborative annotationsを有効にするにはWhiteboardを先に有効にする必要があり、WhiteboardまたはCollaborative annotationsが無効だとユーザーは注釈にアクセスできないと説明されています。(Microsoft Learn)
セキュリティやコンプライアンスの理由でWhiteboardを制限している組織では、「Teamsの新機能が来たのに使えない」と誤解されやすいため、管理者側で事前に説明しておくとよいでしょう。
現場に周知する文面例
社内向けには、機能説明を長く書くよりも「いつ、誰が、何に使えるか」を短く伝えるのが効果的です。
Mac版Microsoft Teamsで、単一のアプリケーションウィンドウを共有しながら注釈を使えるようになります。画面全体を共有せずに、資料やブラウザー画面の上へ参加者が直接ハイライトや書き込みを行えます。顧客会議や研修で利用する場合は、共有前に不要な情報が画面内に表示されていないか確認し、必要に応じて発表者のみ注釈可能に設定してください。
ヘルプデスク向けには、次のように補足しておくと実用的です。
注釈ボタンが表示されない場合は、Teamsクライアントの更新状況、Mac版Teamsであること、会議ポリシー、Whiteboard設定、対象テナントへの展開状況を確認してください。参加者が書き込めない場合は、発表者側の注釈権限設定も確認してください。
まず実施すべきこと
Microsoft Teamsの「Annotations on Teams Single Window Sharing on macOS」は、Macユーザーの画面共有をより安全で対話的にする更新です。管理者が最初に行うべきことは、機能そのものの説明よりも、対象ユーザー、会議ポリシー、Whiteboard設定、社内利用ルールの確認です。
特に、Macで顧客会議や研修を行うユーザーが多い組織では、早めに検証用会議を作成し、単一ウィンドウ共有、注釈権限、スナップショット保存、外部参加者との挙動を確認しておきましょう。問題なく使えることが分かったら、社内マニュアルの画面共有手順を「全画面共有」前提から「必要なウィンドウだけを共有する」前提へ更新するのが次の一手です。
コメント