web会議の通知音が相手に聞こえる｜鳴る機器は会議とは別に決まる

2026年10月8日

商談中に「ポン」と鳴って、相手から「いま何か鳴りました？」と言われる。画面は共有していないので、通知が映ったわけではありません。音だけが届いています。

検索すると出てくるのは「集中モードをオンにする」「通知を切る」という手順です。それは正しいのですが、手順を入れたのに鳴る、という状態の説明が見つかりませんでした。MicrosoftとAppleの公式の記述を当たると、理由は3つに分かれていました。バナーと音のスイッチが別にあること、音が鳴る機器が会議で使う機器とは別に決まること、音を下げる仕組みが消音ではないことです。この記事はその3つを公式の文面で並べた記録です。出典は本文に置いています。

上位は「通知を切る」で終わっている

この語で検索して上位9件を読むと、書いてあることはほぼ同じでした。Windowsの集中モードを入れる。会議に入る前に通知を切る。メールやチャットのアプリの通知をオフにする。防音の話が混ざっているページもありました。

操作としては全部正しいです。ただしどれも「通知という1つのスイッチ」を前提に書かれています。 実際には通知の表示と通知の音は別のスイッチで、しかも音が出る機器は別の設定で決まります。切ったつもりで鳴るのはそこです。

もう1つ、画面共有の話と混ざっているページもありました。共有していると通知の中身まで読まれる、という話はそれ自体は正しく、画面共有で通知を見られない対策に書きました。この記事は共有していないときの話です。経路がマイクなので、共有の設定をどう変えても関係ありません。

バナーを止めるスイッチと、音を鳴らすスイッチは別にある

Windowsの通知設定には、アプリごとの項目が並んでいます。Microsoftの公式ページを読むと、Windows 11では「通知バナーを表示する」と「サウンドを再生する」が別の項目として並んでいます（Windows で通知の設定を変更する）。Windows 10でも同じで、「通知バナーを表示する」とは別に「通知が届いたときにサウンドを再生する」があります。

項目が分かれているということは、片方だけ切れるということです。 画面に出さない設定にしても、音のスイッチはそのまま残ります。逆もあります。

「応答不可」（Do not disturb）のほうも、同じページの書き方に気をつける必要があります。公式はこう書いています。

> With do not disturb on, you will only receive banners for alarms, reminders, and apps of your choice.

受け取らなくなるのはバナーだと書かれています。音がどうなるかは、この一文には書かれていません。同じページには応答不可中でも通すものを選べる設定（通話とリマインダーのチェック、通す対象のアプリの指定）があるとも書かれていて、通す対象に入れたアプリは応答不可の外にいます。

商談の前に打つ手として実際に効くのは、応答不可を入れたうえで、通す対象に何が入っているかを一度見ることです。入れた覚えのないアプリが入っていることがあります。

ヘッドセットにしても、通知音はスピーカーから鳴ることがある

ここがいちばん効いている場所でした。ヘッドセットを着けているのに、通知音だけが机のスピーカーから鳴る。だからヘッドセットのマイクがそれを拾って、相手に届きます。

MicrosoftはWindowsの音の機器に「役割」を割り当てる仕組みを公式に書いています（Using a Communication Device）。通話に向いていると判断した機器には eCommunications という役割が付き、それとは別に音楽などを鳴らす機器があります。例として挙がっているのが、まさにこの形です。

> For example, if the user has a headset and a speaker connected to the computer, the system assigns the eConsole role to the speaker and the eCommunications role to the headset.

ヘッドセットとスピーカーが両方つながっていれば、スピーカーに eConsole、ヘッドセットに eCommunications を割り当てるとMicrosoft自身が書いています。通話はヘッドセット、それ以外はスピーカー、という分け方が最初から仕組みとして用意されているわけです。通知音は通話ではないので、スピーカー側に出ます。

同じページには、割り当ての手が足りないことも書かれています。

> The system performs automatic role detection but does not set a particular device to be used for communications. This must be done by the user.

自動で見分けはするが、通話に使う機器を決めるのは人の仕事だ、と書かれています。つまりつないだだけでは決まっていないことがあります。設定の画面（再生タブと録音タブ）で、通話用の機器をそれぞれ選ぶ形になっています。

macOSにも、同じ向きの設定があります。Appleのサウンド設定の説明には出力の機器を選ぶ項目とは別に、効果音の項目があり、「Play sound effects through」はこう説明されています。

> Choose a sound output device to play sound effects.

効果音を鳴らす機器を選ぶ、という項目が出力の機器とは別に立っています（Change Sound settings on Mac）。同じページの「Alert volume」は The alert volume is relative to the output volume of your Mac, so if you lower your Mac volume, alert sounds also play more quietly. と書かれていて、警告音の大きさはMac全体の音量にぶら下がっています。

WindowsもmacOSも、通話の音と知らせの音を別の機器に出せる作りになっているということです。便利な仕組みですが、商談では「ヘッドセットにしたから安心」が成り立たない理由になります。会議室に複数の機器があるときにエコーが残る話はマイクを切っても止まらないハウリングに書きました。原因の形は似ていて、音を出している機械と、音を拾っている機械が別です。

音を下げる仕組みは、消音ではない

Windowsには、通話中に他の音を下げる仕組みがあります。ダッキング（stream attenuation）と呼ばれていて、Microsoftの公式ページが既定の挙動を書いています（Default Ducking Experience）。

> On the Communications tab, the user can choose an attenuation level (default value is 80%), mute all non-communication streams, or disable the default stream attenuation experience.

選べるのは3つで、既定は「80%下げる」です。 「すべて消音する」は別の選択肢として用意されています。つまり既定のままなら、通知音は小さくなるだけで鳴っています。小さくなった音をマイクが拾わないかどうかは、音量と机の作り次第です。

同じページには、もう1つ引っかかる一文があります。

> The system allows new non-communication streams (except for new system sounds) to be opened during the communication session but the new streams are not automatically attenuated.

通話が始まったあとに開いた音の流れは、自動では下げられないと書かれています。通知音はまさに、通話が始まったあとに鳴る音です。ただし括弧の except for new system sounds が何を除いているのかは、この文面から決められませんでした。システム音だけは例外的に下げられる、とも読めます。読み切れなかったので、ここは断定しません。

もう1つ、この仕組みが働く条件も確かめておく必要があります。前に挙げたページは、通話の音の流れをこう定義しています。

> The operating system considers the stream opened on a communication device to be a communication stream.

通話用の機器の上で開かれた流れを、通話の流れと見なす。そう書かれています。裏返すと、通話用の機器が決まっていなければ、下げる仕組みが始まる合図も立ちません。 ブラウザから入る会議がこの合図を立てているかは、こちらでは確かめられませんでした。

ノイズ抑制が消してくれる保証は、公式には書かれていない

「ノイズ抑制が入っているから通知音も消えるのでは」という期待があります。公式の書き方を見ると、消える前提にはできませんでした。

Microsoftのノイズ抑制の説明は、3段階を次のように定義しています（Reduce background noise in Microsoft Teams meetings）。High は suppresses all background sound that isn't speech、Low は suppresses low levels of persistent background noise, such as a computer fan or air conditioner、そして Auto が既定で The Teams app optimizes for some level of noise suppression and is best for most situations です。

通知音は声ではないので、Highなら対象の側に入ります。ただし既定はAutoで、Autoがどこまで消すかは「状況に合わせて最適化する」としか書かれていません。 同じページが挙げている例も、紙をめくる音、ドアが閉まる音、犬が吠える音で、短い電子音は出てきません。

ノイズ抑制が通した音が記録にも残る話はweb会議の音声が聞き取りにくい原因に、会話以外の音が削られる向きに働く話は共有した動画の音がブツブツ切れるに書きました。この記事で足したいのは、消える側に入る保証を公式から取れなかったという一点だけです。

そして送り手には、どちらにしても見えません。自分のマイクが拾った音は自分のスピーカーから出ないので、鳴ったかどうかを自分の耳では確かめられません。マイクの音量バーが動いていても相手に届いている証拠にはならない話はマイクテストのバーは何を測るかに書きました。

うちは音で知らせる口を作っていない

私たちが作っているMeetnectには、音で知らせる仕組みが1つもありません。チャットが届いたとき、相手がつながったとき、何かが保存できたとき、どれも音は鳴りません。

コードで確かめられる形で書くと、public/room.html に new Audio( が0件、<audio> の要素が0件、ブラウザの通知を出す Notification( も0件です。チャットが届いたときにやっているのは、未読の数を増やしてバッジに出すことだけです（2021行の unread++ と chatBadge）。音を鳴らす経路そのものを持っていないので、うちのツールが出した音がマイクに入ることはありません。

自分の映像を映す場所も、3か所すべて muted を付けています（285行の待機画面、343行の商談中の自分のタイル、480行の設定パネルのプレビュー）。自分の声を自分のスピーカーから出さないので、そこから輪ができることもありません。ブラウザのエコー除去が何を打ち消せるかは別の記事に書いたとおりで、打ち消す相手は自分の端末のスピーカーから出た音です。

設定パネルのマイクのメーターも、入力を見せるだけでテスト音を出しません（1799〜1810行）。AudioContext を作ってマイクの波を読み、spMicLevel の幅にしているだけで、スピーカーに向けて何も送っていません。テスト音を出す作りにすると、その音がそのままマイクに入るからです。

正直に書くと、できていないこともあります。 音の出口の機器を選ぶ口を作っていません（setSinkId が0件、機器の一覧も videoinput と audioinput だけ）。会議の音と効果音の出口がずれていても、うちの画面からは直せません。ブラウザの既定に任せている形で、この判断の理由はイヤホンを挿しても相手に声が届かないに書いたものと同じです。マイク側の3つの処理（エコー除去・ノイズ抑制・自動音量調整）を常に有効にしている話も、別の記事に書いたとおりで、切る分岐はありません。

商談で打てる手

確かめる手段が無い以上、確かめなくても成り立つ形に寄せるほうが早いです。4つあります。

音の出口を1つにする。 ヘッドセットを使うなら、通話用の機器と通常の出力を同じヘッドセットにそろえる。Windowsなら再生タブで両方、macOSなら出力と「効果音を鳴らす機器」の両方を見ます。役割が分かれていること自体が原因なので、ここを1つにすると通知音はヘッドセットの中で鳴ります。

応答不可と、音のスイッチを別々に見る。 片方では足りません。通す対象に入っているアプリも一度見ます。

鳴ってしまう前提で、机の上を決める。 下げる仕組みは既定で80%低減です。消えるとは書かれていません。音が出る機械をマイクから離すほうが確実です。

商談の前に、短い確認を1回挟む。 開始直後に「音は大丈夫ですか」と1回聞く。商談の最後に聞くと、鳴っていた時間がまるごと過ぎています。

この4つの効果は測っていません。順番の根拠は、あとから取り消せないこと（相手に聞こえてしまった音）から潰す、という考え方だけです。

分からなかったこと

3つ、確かめられませんでした。ひとつ、Windowsの except for new system sounds という括弧が何を除いているのか、この文面からは決められませんでした。ふたつ、ブラウザから入る会議が、Windowsの言う「通話の流れ」として扱われているかは分かりませんでした。みっつ、通知音がどの音量でマイクに入るかは、こちらで測っていません。この記事の記述は、MicrosoftとAppleの公式の文面と、うちのコードの中身だけです。

Meetnectの場合

Meetnectは音で知らせる仕組みを持たず、チャットも相手の参加も画面の表示だけで伝えます。自分の映像を映す3か所すべてに muted を付けていて、自分の声が自分のスピーカーから出ることはありません。音の出口の機器を選ぶ口は作っていないので、通話と知らせの出口がずれているときは機器の設定のほうで直してもらう形になります。この記事で挙げた進め方の効果は測っていません。