画面共有で一部のウィンドウだけが黒く映るのは、どこで欠けているのか
2026年10月7日
画面を共有したら、相手から「そのウィンドウだけ黒いです」と言われた。自分の画面では普通に見えている。検索すると、グラフィックのアクセラレーションを切る・アプリを再起動する・ドライバを更新する、が並びます。どれも当たることはあります。ただ同じ「黒い四角」が4つの別の場所で起きているので、効く手は場所ごとに違います。この記事では Microsoft・Google・Zoom の公式の記述だけを使って、黒くなる場所を4つに分けました。読むと、自分が見ている黒がどれなのかを当てられます。
上位に並ぶのは「黒くなったあとの手当て」
検索上位の記事は、対処をひとまとめのチェックリストにしています。アクセラレーションを切る、別のGPUに寄せる、ウィンドウ単位をやめて画面全体にする、再起動する。実際にどれかで直るので、間違ってはいません。
ただ、この並べ方だとどれが効いたのか分からないまま終わります。 次に同じことが起きたとき、また上から全部やり直すことになります。公式側の記述は、もっと細かく分かれています。
ウィンドウ単位の共有は、その窓の外に出たものを落とす
Google Meet の既知の問題のページには、ウィンドウを共有したときに中身が欠けるケースが3つ並んでいます。
> When you share a window in Meet, such as a Microsoft PowerPoint or Keynote presentation, the slideshow opens blank to other viewers.
スライドショーを始めると、相手には空白が映るという記述です。原因も同じページに書かれていて、全画面のスライドショーは別の窓として開くので、元の窓を共有している共有には入ってこないという形です。対処は「スライドショーに入る前に画面全体を共有しておく」。
同じページには、もう2つ並んでいます。
> When you share a window in Meet, the drop-down menus in the shared window don't display in the meeting.
ドロップダウンメニューが相手に映らない、という記述です。アプリの中のメニューは、見た目ではその窓の一部ですが、OSから見るとその上に乗った別の窓です。だから窓1枚を指定した共有からは外れます（Known issues with Google Meet）。
ここで分かるのは、1つのアプリが1枚の窓に見えても、OSの数え方では複数の窓だということです。メニュー・ポップアップ・全画面のスライドは、それぞれ別の窓になります。自分の画面では全部つながって見えるので、欠けていることに気づけません。
アプリの側が「画面にだけ出す」と決められる
Windowsには、アプリが自分の窓について「ここにだけ出す」と宣言できる仕組みがあります。Microsoft の API リファレンスには、指定できる値が3つ載っています。そのうち2つがこうです。
> WDA_MONITOR … The window content is displayed only on a monitor. Everywhere else, the window appears with no content.
> WDA_EXCLUDEFROMCAPTURE … The window is displayed only on a monitor. Everywhere else, the window does not appear at all.
上はモニター以外では中身のない窓になる、下はモニター以外では窓そのものが出てこない。上がまさに、相手に届く黒い四角です。同じページには、この仕組みが Windows 7 から入った「window content protection」のためのもので、デスクトップの合成（DWM）が動いているときだけ働くこと、WDA_EXCLUDEFROMCAPTURE は Windows 10 Version 2004 からで、それより前では WDA_MONITOR と同じ動きになることが書かれています（SetWindowDisplayAffinity function）。
この黒は故障ではありません。 アプリが意図してそうしているので、こちらの設定を変えても戻りません。動画の配信アプリや、お金や鍵を扱うアプリでこの黒が出たときは、そこで打ち止めです。画面に出す以外の渡し方（ファイルを先に送る、数字だけ読み上げる）に切り替えるほうが早いです。
取り込む処理が、どのGPUで走っているか
3つ目は、共有の中身を取り込む処理そのものが止まっている場合です。Zoom の黒い画面のページには、原因が1行で書かれています。
> The black screen during screen sharing could be caused by a graphics card with automatic-graphics switching (such as an Nvidia card).
内蔵のGPUと外付けのGPUを自動で切り替える機械で起きる、という記述です。注目したいのは直し方の形です。Windows の設定か NVIDIA のコントロールパネルを開いて、Cpthost.exe という実行ファイルを探し、それを内蔵GPU側に寄せる手順になっています（Troubleshooting black screen during screen sharing）。
Cpthost.exe はアプリの本体とは別のプロセスです。つまり画面を描いている経路と、画面を取り込んでいる経路は別で、片方だけが転ぶことがあります。これが「自分の画面では見えているのに相手には黒い」の、いちばん素直な説明になります。
同じ Zoom には、会議アプリ自身の窓が灰色か黒の箱になるという別のページもあります。消せる設定はひとつだけだと書かれています。
> The only setting that allows the gray boxes to disappear is Advanced Share without window filtering.
共有の取り込み方（キャプチャモード）の選び方で、箱が出るか出ないかが変わります（Black/Grey boxes over screen share on Windows computer）。取り込み方の選択肢がいくつもあるということは、既定の取り込み方が全部の窓に通るわけではないということです。
取り込めていても黒くなる
4つ目は、取り込みは成功していて、その先で落ちている場合です。Zoom には、ある時期の macOS に限った記述があります。
> On macOS Big Sur, packets over a certain size may not be transmitted properly over the UDP protocol.
有線でつないでいる環境で、大きいパケットが通らずに黒い画面になるという話です（MacOS Big Sur black screen when screen sharing）。ここまでの3つを全部確かめても直らない黒が、この形でもあり得ます。見分け方は後ろに書きます。
許可の層も、これとは別にあります。Google の既知の問題のページには、macOS Sequoia では画面を共有しようとした最初の1回に確認が出て、ブラウザに許可を出す必要があると書かれています。Apple 側の設定は「画面とシステム音声の収録」という項目で、アプリごとにオンとオフを選べます（Macで画面とシステム音声の収録へのアクセスを制御する）。ただし、許可が切れているときに相手の画面に何が映るのかは Apple のページに書かれていません。 黒なのか共有が始まらないのかは区別できなかったので、ここは断定しません。
うちは送っている映像そのものを送り手に出している
ここまでの4つに共通するのは、送っている本人の画面には異常が出ないことです。自分のデスクトップは普通に見えているので、相手が言うまで分かりません。
Meetnect では、送り手の画面に出す映像を別に作っていません。ブラウザから受け取った共有の映像を1本の MediaStream として相手に送り、同じものを自分の画面にも出しています（public/room.html の1825〜1827行で共有の映像を受け取り、startExtra が同じ stream を showPresentation に渡し、1010行で presentVideo.srcObject = stream にしています）。
だから、相手に黒い四角が届いているときは、同じ黒い四角が送り手の画面にも出ます。別に用意した綺麗なプレビューを見ていて気づかない、という形にはなりません。これは意図した作りというより、送るものと見せるものを2本に分けなかった結果です。送り手が自分の画面を一度見る必要はあるので、気づけることと気づくことは別です。
資料を見せるほうの経路では、この4つの層が最初から出てきません。資料提示は画面を取り込まず、ファイルの中身を1280×720の描画面に描いてから送っています（ensurePresentCanvas と drawFitted）。窓を指定していないので、窓の数え方も窓ごとの宣言も関係しません。資料の見え方は画面共有の資料の文字サイズと資料提示の解像度に書いています。
自分の黒がどれなのかを当てる順番
1回の操作で2つ以上の層をまとめて消せる順に並べました。
- 画面全体に切り替えて、黒が消えるか。 消えたら1つ目の層です。メニューやスライドショーが別の窓になっていただけなので、設定を触る必要はありません
- 別のアプリの窓で同じことが起きるか。 そのアプリだけなら2つ目の層で、こちらでは直りません。渡し方を変えます
- 全部の窓が黒いか、1つだけか。 全部なら3つ目の層です。アクセラレーションやGPUの振り分けが効くのはここだけです
- 自分の画面に出ている共有の映像に、同じ黒があるか。 あれば取り込みの手前（1〜3）、無ければ届く途中（4）です。相手が1人だけ黒いときも4つ目で、送り手側の設定を触っても変わりません
確かめられなかったことが2つあります。ひとつ、窓の中身を画面だけに限る宣言を実際に使っているアプリの名前は、公式の記述から特定できませんでした。仕組みの説明はありますが、使っている側の一覧はありません。ふたつ、4つの層がどのくらいの頻度で起きるのかは測っていません。この順番の効果も測っていないので、根拠は冒頭に書いた考え方だけです。
Meetnect は資料を画面共有ではなくファイルとして送り、1280×720の描画面に描いてから1枚ずつ届けます。画面を取り込む経路はブラウザの機能をそのまま呼んでいるだけなので、ここに挙げた4つの層はそのまま残ります。残るからこそ、送っている映像そのものを送り手の画面にも出しています。画面共有が相手の手元で止まるときの話は別の記事に、共有した音が相手に届かないときの話はこちらに書きました。