web会議で相手に許可のダイアログが出てこない｜問いが出ない4つの理由
2026年10月6日
商談を始めようとして、相手に「カメラの許可を押してください」と伝えます。返ってくるのは「何も出ていません」。こちらの画面は相手を待っている状態のまま、何分でも止まります。
このとき困るのは、押し間違いではありません。そもそも問いが出ていないことです。問いが出ない理由は少なくとも4つあって、どれなのかを待っている側から見分ける手段がありません。この記事では、ブラウザが許可を聞かない条件を Mozilla と Google の公式記述で確かめ、こちらから確かめられる範囲がどこまでかを書きます。出典は本文に置きます。
上位は「出たダイアログにどう答えるか」で埋まっている
この言葉で検索すると、出てくるのは2種類です。1つはブラウザごとの解除手順で、アドレスバーの左のアイコンを押して「カメラ」を「許可」に変える、という案内です。もう1つは営業向けの記事で、顔を出してもらうための声のかけ方が書かれています。
どちらも、ダイアログが出た後の話です。2つの言い方で検索して上位を見ましたが、出ていない状態を原因別に分けたページはありませんでした。解除手順のページも、相手が「設定」を開ける前提で書かれています。
商談で詰まるのはその手前です。相手は画面を見ていて、何も出ていないと言う。こちらは「出るはずです」としか言えません。
理由1：ページがそもそも問いを出せない
いちばん手前にあるのは、相手の操作とは関係のない層です。
カメラとマイクを使う getUserMedia という仕組みには、前提が2つあります。Mozilla の資料にはこう書かれています。
> If a document isn't loaded in a secure context, the navigator.mediaDevices property is undefined, making access to getUserMedia() impossible.
（安全な文脈で読み込まれていない文書では navigator.mediaDevices が存在しなくなり、getUserMedia() を使えない）。安全な文脈とは、HTTPS で読み込まれたページのことです（MDN）。HTTP で開かれたページでは、ダイアログは出ません。 出ないのではなく、聞く機能自体が無い状態です。
もう1つは、会議の画面が他のページの中に埋め込まれている場合です。Permissions-Policy の camera という決まりの説明にはこうあります。
> The default allowlist for camera is self.
（既定で許されているのは自分自身のページだけ）。そして「Where a defined policy blocks use of this feature, MediaDevices.getUserMedia() calls will return a Promise that rejects with a NotAllowedError」（方針で止められている場合、呼び出しは NotAllowedError で失敗する）とあります（MDN）。
埋め込んだ側が allow="camera; microphone" を書いていなければ、問いは出ないまま失敗します。 書くのは埋め込んだページを作った人で、相手でもこちらでもありません。社内ポータルの中に会議の画面が貼られている、という作りのときに起きます。
理由2：ブラウザが「もう聞かない」と決めている
2つ目は、ブラウザが過去の反応を覚えている層です。
Mozilla の同じ資料には、NotAllowedError が出る場面として、本人が拒否した場合に加えて「the user has denied access for the current session, or the user has denied all access to user media devices globally」（現在のセッションで拒否した、またはすべてのアクセスを全体的に拒否した）が並んでいます。
ここで効くのが、押さなかった場合の扱いです。Chrome は許可の問いを小さな部品で出していて、公式の説明にこうあります。
> Permissions that have been temporarily blocked—through a user ignoring the request or dismissing the prompt—can request the permission again within the same session.
（要求を無視した、または閉じたことで一時的に止められた権限は、同じセッション内で再度要求できる）。そして無反応だったときの見え方も書かれています。
> the request chip will automatically collapse to just a blocked icon (to indicate the permission being temporarily blocked), before being dismissed entirely.
（反応がないと、部品は止められたことを示すアイコンだけに縮み、やがて完全に消える）（Chrome for Developers）。
相手は嘘をついていません。 一度縮んで消えた後の画面を見ているので、本当に何も出ていません。Chrome のヘルプにも、止めたときの結果が1行で書かれています。「Some sites won't work if you don't allow them. For example, you won't be able to join a video call.」（許可しないと動かないサイトがある。たとえばビデオ通話に参加できない）（Chrome ヘルプ）。
理由3：前に許可したものが、もう残っていない
3つ目は、前に一度うまくいった場合です。「この前はできたのに」と言われる状態がここに入ります。
Chrome には1回だけ許可する選択肢があり、その有効範囲が公式に書かれています。
> When users select Allow this time, the granted permission is temporary, also referred to as *one-time permission*. Its duration is limited to the current ongoing interaction with a web application.
（「今回だけ許可」を選ぶと権限は一時的なもので、有効なのは今そのアプリを使っている間だけ）。消える条件として並んでいるのは、「The page has been closed, was navigated away from, or was discarded」（ページを閉じた、別のページへ移った、破棄された）、「16 hours have passed since granting permission」（許可から16時間が過ぎた）、「The page has been in the background for at least 5 minutes」（5分以上背面にあった）です。
背面の5分については、カメラとマイクに例外が書かれています。「Others, like camera and microphone, are allowed to run in a background tab.」（カメラやマイクのように背面のタブで動いてよいものもある）。この場合は「Chrome shows a tab strip indicator and doesn't start the 5-minute timer until the page stops using the capability. Note that the 16-hour timer is still running.」（使い終わるまで5分の計測は始まらないが、16時間の計測は進み続ける）とあります（Chrome for Developers）。
前の商談で「今回だけ」を選ばれていると、今回はまた問いから始まります。 条件に「別のページへ移った」が入っているので、招待メールのリンクを踏み直しただけでも消えている場合があります。
理由4：答えが返ってこないまま、終わらない
4つ目が、待っている側にいちばん効きます。問いが出ているのに、相手が何も押さない場合です。
Mozilla の資料に、そのときの挙動が書かれています。
> It's possible for the returned promise to *neither* resolve nor reject, as the user is not required to make a choice at all and may ignore the request.
（返される約束は、成功も失敗もしないことがある。利用者は選ぶ義務がなく、要求を無視してよいため）。
成功も失敗もしないので、こちらの画面は「待っています」のまま止まります。 相手が無視しているのか、ダイアログが出ていないのか、ブラウザに止められたのかは、同じ見え方になります。
Chrome は、状態を読み取る仕組みについても注意を出しています。「Do not use the prompt state as a signal that a user is a first-time user.」（まだ聞かれていないという状態を、初めて来た人の印として使ってはいけない）。読み取れる状態の名前と、相手の画面で実際に起きていることは、一致しません。
相手が退出したのか回線で切れたのかを見分けられない話は参加者が退出したのか切れたのかに書きました。構図は同じで、こちら側に届いていない情報を、こちら側の画面から当てることはできません。
商談でどう組むか
4つのうち、こちらで動かせるものはありません。確かめる手段が無い前提で組むほうが早いです。
- 「出ていますか」ではなく「画面に何が見えていますか」と聞く。 出ているかどうかを尋ねると「出ていません」で止まります。見えているものを言ってもらえば、縮んだアイコンが残っているかどうかまで分かります
- 2分待ったら、音声だけで始める。 理由1と理由2なら、商談中には動きません。カメラを待つ時間がそのまま商談の時間を削ります
- リンクを踏み直してもらう前に、一度だけ試す。 理由3なら読み込み直しで問いが戻ります。それで出ないなら、別の理由です
- 解除の手順を自分の言葉で説明しない。 相手のブラウザと、こちらのブラウザで押す場所が違います。ボタンの名前と位置が人によって違う話は操作を口で伝えられない理由に書きました
答えた後に誰が直せるのか、管理者の層まで含めた切り分けは教えても直らないものを先に分けるに書きました。入った瞬間のカメラとマイクの状態を決めている層は参加時の既定は本人が決めていない、自分の声が届いているかの確かめ方はマイクテストのバーは何を測るかのほうです。
確かめられなかったこと
Firefox の「新しい要求をブロックする」設定は、公式ページを読めませんでした。 Firefox には、どのサイトからもカメラの要求を受け付けなくする設定があるとされています。原文を確かめようとしましたが、Mozilla のヘルプページは執筆時に読み込みエラーを返し、本文を取れませんでした。そういう設定が「ある」と断定せずに、確かめられなかったことだけを残します。
アプリの中で開いたブラウザについては、裏を取れませんでした。 メールやメッセージのアプリからリンクを踏むと、そのアプリの中の画面でページが開きます。この状態で許可の問いがどう扱われるかは、作ったアプリ側の実装によります。Apple と Google が公開している開発者向けの資料に当たりましたが、どちらも画面が読み込まれず原文を取れていません。
他社の環境を用意して再現していません。 ここに書いたのは Mozilla と Google の公式記述だけです。
Meetnect の場合
Meetnect はブラウザのタブだけで動くオンライン商談ツールです。商談の画面（public/room.html）は他のページに埋め込まない単体のページで、iframe という語は画面側もサーバー側（src/worker.js）も1件も出てきません（理由1の後半が起きない形です）。状態を読み取る navigator.permissions も、画面4本とサーバーのすべてで0件で、読み取れる状態と相手の画面が一致しないと Chrome 自身が書いている以上、推測を画面に出すことはしていません。ブラウザが返したエラーの名前をそのまま出す作りについては、上の記事に書いたとおりです。