タグアーカイブ htaccess

埋め込みチャットでNS_ERROR_DOM_COEP_FAILEDエラーが出た時の直し方

サイトに埋め込んだ Teams やその他のチャットウィジェットをクリックした時に NS_ERROR_DOM_COEP_FAILED と表示されて開けない場合、サーバーが返している COEP（Cross-Origin Embedder Policy）ヘッダーが原因だ。htaccess で Cross-Origin-Embedder-Policy を credentialless に変更するか、不要なヘッダーであれば削除することで解決する。

NS_ERROR_DOM_COEP_FAILEDとは何か

COEP は「Cross-Origin Embedder Policy」の略で、ページが他オリジン（別ドメイン）のリソースを読み込む際のセキュリティルールを定める HTTP レスポンスヘッダーだ。このヘッダーが require-corp に設定されていると、埋め込む側のリソースすべてに CORP（Cross-Origin Resource Policy）ヘッダーが付与されていることをブラウザが要求する。

Teams のチャットウィジェットをはじめ、多くのサードパーティ製ウィジェットは自社の配信サーバーから JavaScript や画像を読み込むが、それらのリソースに CORP ヘッダーが付与されていないことが多い。結果としてブラウザが読み込みをブロックし、NS_ERROR_DOM_COEP_FAILED というエラーをコンソールに出力する。

このエラーは Firefox や Chrome などのモダンブラウザで発生し、ウィジェットのボタンは表示されるがクリックしてもチャット画面が開かない、または読み込み中のまま固まるといった症状が出る。

この図のとおり、自サイトのサーバー設定と外部ウィジェットの配信仕様が噛み合わず、ブラウザが安全側に倒して読み込みを拒否するのが根本的な原因だ。

自サイトにCOEPヘッダーが設定されているか確認する手順

まずは自サイトが実際に COEP ヘッダーを返しているかどうかを確認する。ブラウザの開発者ツールを使えば数分で特定できる。

Chrome や Firefox の開発者ツールでレスポンスヘッダーを確認する

サイトの任意のページを開き、F12 キーで開発者ツールを起動する。NetWork タブを開いてページを再読み込みし、先頭のドキュメントリクエスト（多くの場合はページURLそのもの）をクリックする。Response Headers セクションに Cross-Origin-Embedder-Policy という項目があれば、その値が現在の設定だ。

値が require-corp になっている場合、厳格な制限がかかっている状態で、これがエラーの直接原因になる。値が credentialless であればクロスオリジンの埋め込みは許可されているため、別の要因を探す必要がある。ヘッダー自体が存在しない場合は、COEP 以外の原因（CORS 設定やウィジェット側のスクリプトエラーなど）を疑う。

セキュリティプラグインやCDNが自動付与しているケース

WordPress サイトの場合、セキュリティ系プラグインが HTTP レスポンスヘッダーを自動で追加していることがある。また Cloudflare などの CDN サービスを経由していると、CDN 側のセキュリティ設定で COEP ヘッダーが付与されるケースもある。

該当しそうなプラグインを一つずつ無効化してヘッダーの変化を確認するか、CDN の管理画面で「ヘッダー設定」や「セキュリティヘッダー」といった項目をチェックすると原因を絞り込める。

htaccessでCOEPヘッダーを修正してエラーを解決する

原因が COEP ヘッダーの require-corp 設定にあると特定できたら、htaccess ファイルを編集して修正する。Apache サーバーを使っている国内レンタルサーバーの大半は htaccess による上書きが可能だ。

上記 STEP 3 で追記するコードは以下のとおりだ。htaccess の末尾にこのブロックを追加する。

<IfModule mod_headers.c>
Header set Cross-Origin-Embedder-Policy "credentialless"
</IfModule>

この設定により、COEP ヘッダーが credentialless モードに切り替わる。credentialless はクロスオリジンのリソース読み込みを許可しつつ、認証情報（Cookie や HTTP 認証）を送信しないモードだ。Teams のチャットウィジェットは認証に Cookie を使わず独自のトークンで認証するため、credentialless モードでも問題なく動作する。

COEPヘッダーを完全に削除する方法

セキュリティ上の要件が特にないサイトであれば、COEP ヘッダー自体を削除する選択肢もある。以下のコードを htaccess に追記すればヘッダーが除去される。

<IfModule mod_headers.c>
Header unset Cross-Origin-Embedder-Policy
</IfModule>

どちらの方法を選ぶかはサイトのセキュリティポリシー次第だ。COEP ヘッダーが元々セキュリティプラグインや CDN の自動設定で付与されていたのであれば、credentialless への変更が無難だ。手動で require-corp を指定していた場合は、その意図を再確認した上で削除または変更を判断する。

htaccess編集後に変更が反映されない場合の確認ポイント

ファイルをアップロードしてもヘッダーが変わらない場合、mod_headers モジュールがサーバーで有効になっていない可能性がある。また、CDN を経由しているサイトでは CDN のキャッシュをパージしないと変更がすぐに反映されない。WordPress のキャッシュプラグインを使っている場合も、プラグインの設定画面からキャッシュを全削除する。

変更後は必ず開発者ツールの NetWork タブでレスポンスヘッダーを再確認し、Cross-Origin-Embedder-Policy の値が credentialless に変わっているか、ヘッダー自体が消えているかを検証する。

htaccessが使えないサーバー環境での対処法

Nginx を使っている VPS やクラウド環境では htaccess が使えない。また一部の共用サーバーでは mod_headers が無効化されている場合もある。そうしたケースでの対処法をまとめる。

Nginxの場合

Nginx の設定ファイル（nginx.conf またはサイト単位の conf ファイル）の server ブロック内に以下の行を追加する。

add_header Cross-Origin-Embedder-Policy "credentialless";

記述後は nginx -t で設定ファイルの文法チェックを行い、問題がなければ nginx -s reload で設定を再読み込みする。sudo 権限が必要な操作のため、レンタルサーバーではサポートに依頼する必要がある。

CDNやWAFでヘッダーを操作する

Cloudflare を使っている場合、ダッシュボードの「ルール」から「HTTP レスポンスヘッダーを変更」ルールを作成し、Cross-Origin-Embedder-Policy を credentialless に上書きできる。サーバー側の設定を一切触らずに済むため、htaccess 編集に不安がある場合の現実的な代替手段になる。

PHPでヘッダーを直接出力する

WordPress のテーマの functions.php に以下のコードを追加する方法もある。テーマ更新時に消えないよう、必ず子テーマを使う。

function my_set_coep_header() {
    header('Cross-Origin-Embedder-Policy: credentialless');
}
add_action('send_headers', 'my_set_coep_header');

この方法はサーバー設定に依存せず、WordPress の仕組みだけでヘッダーを制御できる。ただし、テーマの functions.php を編集するため、誤った記述があるとサイトが表示できなくなるリスクを伴う。編集前に必ず functions.php のバックアップを取る。

よくある質問

COEPエラーは特定のブラウザだけに出るのか

Firefox と Chrome 系ブラウザ（Chrome、Edge、Brave など）で発生する。Safari は COEP への対応が遅れていたが、Safari 17.2 以降はサポートしている。ブラウザによってエラーメッセージの文言は異なるが、根本原因は同じ COEP ヘッダーだ。

WordPressのセキュリティプラグインが原因になることはあるか

ある。HTTP セキュリティヘッダーを自動付与する機能を持つプラグイン（セキュリティ全般を扱うプラグインやヘッダー専用プラグイン）が、COEP を含むヘッダーを一括で設定しているケースは多い。プラグインの設定画面で「セキュリティヘッダー」や「HTTP ヘッダー」項目を探し、COEP の値を変更または無効化する。

credentiallessとrequire-corpの違いは何か

require-corp は埋め込み先の全リソースに CORP ヘッダーを必須とする厳格モードだ。一方 credentialless は CORP ヘッダーなしでもクロスオリジン読み込みを許可するが、認証情報（Cookie など）は送信しない。Teams チャットのような独自認証を使うウィジェットでは credentialless で十分動作する。

埋め込みウィジェット側の設定で回避できるか

原則として難しい。COEP エラーは「読み込む側（自サイト）」の制限によって発生するため、ウィジェット提供元（Teams など）の設定で回避する手段はない。ウィジェット提供元が自社の全配信リソースに CORP ヘッダーを付与すれば解決するが、それを個別の利用者が依頼して実現するのは現実的ではない。

htaccess編集に自信がない場合はどうすればよいか

サーバーの管理画面からファイルマネージャーで操作する場合は、編集前に必ず htaccess をコピーしてローカルに保存する。ミスでサイトが表示できなくなったら、そのバックアップをアップロードし直せば元に戻る。どうしても不安な場合は、CDN のヘッダー変更機能や PHP の functions.php で対応する方法を検討する。

この記事のポイント

• NS_ERROR_DOM_COEP_FAILED はサーバーの COEP ヘッダーが require-corp の時に発生する
• Teams など多くの外部ウィジェットは CORP ヘッダーを返さないためブロックされる
• htaccess で COEP を credentialless に変更するかヘッダーを削除すれば解決する
• Nginx 環境や CDN 経由の場合は別の設定手順が必要になる
• 修正後は必ず開発者ツールでレスポンスヘッダーが変わったか確認する

佐々木 太陽

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている