📅 2026年10月10日 ⏱️ 14分で読めます

Cross-Origin Isolationの導入確認｜COOP・COEPと埋め込み互換性を点検

執筆ファネルAi編集部編集ファネルAi編集部監修ファネルAi監修チーム最終更新2026年10月10日

COOPとCOEPで分離されたページから、許可条件を確認した公開資源と埋め込み先へ安全に接続する概念図

SharedArrayBufferなど、ブラウザーが分離環境でのみ提供する機能を使うページでは、Cross-Origin Isolation（クロスオリジン分離）の導入が必要です。設定の中心はHTTPレスポンスヘッダーのCOOPとCOEPですが、ヘッダーを足すだけでは完了しません。外部画像・スクリプト・iframe、OAuthや決済のポップアップが実際に読み込めて、業務導線が維持されるかを確かめます。

先に結論を示すと、機能を必要とするページに対象を絞り、HTTPS上でCOOPをsame-origin、COEPをrequire-corpまたは対象ブラウザーが対応するcredentiallessに設定します。Permissions-Policyがcross-origin-isolatedを拒否していないことを確認し、実ページでself.crossOriginIsolatedがtrueになったうえで、埋め込みや認証・決済まで試験します。2026年10月10日時点の仕様と資料に照らすと、Report-Onlyは影響を観測する準備に使えますが、分離を有効にはしません。

必要機能を確認し、外部資源を棚卸しし、応答を設定して実画面を検証し、段階的に適用する5段階のCross-Origin Isolation導入フロー — 必要機能を確認 → 外部資源を棚卸し → 応答を設定 → 実画面を検証 → 段階的に適用する順に、分離状態と業務導線を一緒に確かめます。

本記事のポイント

SharedArrayBufferなどの機能が必要なページに限り、HTTPS上でCOOPとCOEPを組み合わせ、crossOriginIsolatedがtrueになることを確認します。
require-corpでは外部資源のCORSまたはCORP許可が必要で、credentiallessはクロスオリジンのno-cors通信から認証情報を除いて読み込みます。
COOP same-originはOAuthや決済のポップアップ参照を切る場合があるため、分離状態だけでなくログイン・決済・埋め込みを実画面で確認します。

分離が必要な機能とページを先に決める

Cross-Origin Isolationは、異なるオリジンの文書や資源が同じブラウザー環境に不用意に混在しないよう、読み込み側と提供側の明示的な協力を求める仕組みです。SharedArrayBufferの利用、より細かい時間計測など、機能によってはこの分離状態がブラウザー上の前提になります。一方で、COOPやCOEPを設定すればサイト全体の安全性が一律に上がる、という意味ではありません。利用する機能と画面がないのに導入すると、外部サービスの読み込みやポップアップ連携だけが壊れる可能性があります。

最初に、対象機能を使う画面、利用者、対応ブラウザーを記録します。アプリの特定ルートだけが機能を使うなら、そのページのレスポンスから適用を始めます。トップページ、記事、採用ページなど、要件のないページへ一括適用する必要はありません。ページの範囲を決める際は、ウェブサイト構築の比較とCMS・配信方式の検討も参考になります。共有ヘッダーや共通配信設定が対象外の画面にまで影響しないかも、実装前に確認してください。

次に、対象画面が読み込む資源を、HTML上の記述だけでなくブラウザーの通信記録から集めます。画像、フォント、スタイルシート、JavaScript、Web Worker、API、動画、チャット、計測タグ、フォーム、各社のiframeを含め、接続先、オーナー、必要な通信モード、ログイン状態に依存するかを一覧にします。タグ管理ツールやCMSの設定から後付けされる資源も漏れやすいため、コード検索だけで終わらせないことが大切です。実装元・目的・送信データ・停止方法を合わせて整理する手順は、企業サイトの外部スクリプト棚卸しで確認できます。

分離対象ページで資源ごとに確認する項目
確認対象	記録する内容	判断の例
画像・フォント・公開スクリプト	接続先、CORS利用の有無、提供側の応答ヘッダー	公開配布物か、認証に依存する配布物かを分ける
API・会員向け資源	送信モード、Cookie等の必要性、許可するオリジン	公開資源向けの許可を利用者別データへ広げない
iframe・ポップアップ	埋め込み先と遷移先、postMessage、戻り値の利用	ログイン、決済、フォーム送信を最初から試験対象にする

この棚卸しでは「読み込めるか」だけでなく、通信に認証情報が必要か、別の文書やウィンドウとの参照を使うかも確認します。同じCDNの画像でも、一般公開画像と利用者ごとの請求書では許可の判断が違います。画像やスクリプトを提供する外部事業者に、必要な応答ヘッダーを設定できるか問い合わせる時間も見込んでおきます。

COOP・COEPと外部資源の許可を組み合わせる

通常の有効化では、トップレベル文書のレスポンスに次の組み合わせを設定します。COOP（Cross-Origin-Opener-Policy）が開いたウィンドウとの閲覧コンテキストグループを制御し、COEP（Cross-Origin-Embedder-Policy）がページに読み込むクロスオリジン資源に、提供側の明示的な許可を求めます。

Cross-Origin-Opener-Policy: same-origin
        Cross-Origin-Embedder-Policy: require-corp

COEPにはcredentiallessという選択肢もあります。いずれもCross-Origin Isolationと互換性のある設定ですが、実際に採用できるかは対象ブラウザーのバージョン、配信する資源、認証方式で異なります。HTTPSなどのセキュアコンテキストであることも前提です。HTTPでヘッダーだけを返しても、ブラウザーがポリシーを有効に扱わない場合があります。Permissions-Policyでcross-origin-isolated機能が拒否されていないことも確認してください。親のページに埋め込まれる場合は、親側のポリシーも影響します。

require-corpでは、クロスオリジン資源を読み込むとき、資源提供側からCORSまたはCross-Origin-Resource-Policy（CORP）による許可を得る必要があります。画像タグなどにcrossorigin属性を付けるとCORSモードで取得できますが、属性を付けるだけでは許可になりません。サーバーが適切なAccess-Control-Allow-Originを返す必要があります。認証付きCORSでは、許可するオリジンを具体的に指定し、認証情報を許可する設定も整合させます。

no-corsモードの取得では、資源側のCORPヘッダーが選択肢になります。Cross-Origin-Resource-Policy: cross-originは、誰でも取得してよい公開画像や公開配布物など、内容を広く公開している資源に限って検討します。社内資料、会員向けデータ、利用者ごとの応答に一律で付けるヘッダーではありません。CORSを設定できるなら、誰がどの資源を取得できるかを提供側で具体的に制御できます。

credentiallessは、クロスオリジンのno-corsリクエストでCookieなどの認証情報を送らない代わりに、資源側のCORPヘッダーがなくても読み込みを認める方式です。対象はその通信条件に限られ、同一オリジンのリクエストやCORSモードのリクエストから認証情報を一律に取り除く設定ではありません。ログイン状態を前提にした外部画像や埋め込みは、credentiallessにすると表示されなくなる可能性があります。ブラウザー対応を確認し、認証情報がない状態でも安全に読める資源に限って試します。COEPを設定すればどのiframeも通る、という抜け道でもありません。

なお、Content Security Policy（CSP）は別の制御です。CSPが接続先やスクリプトを拒否していれば、COEP向けのCORSやCORPが整っていても読み込みはできません。コンソールやNetworkパネルで、どのポリシーが拒否したかを分けて調べてください。

Report-Onlyから本番確認まで段階的に進める

いきなり強制ポリシーを全対象へ適用せず、まずReport-Onlyヘッダーを使って影響の候補を観測します。Cross-Origin-Opener-Policy-Report-OnlyとCross-Origin-Embedder-Policy-Report-Onlyは、報告先を準備したうえで、ポップアップの分離や資源読み込みで問題になりそうな箇所を把握するための仕組みです。ただしReport-Onlyは違反を報告するだけで、読み込みを制限せず、Cross-Origin Isolationも有効にしません。レポートが届かないことだけを安全の証明にせず、Networkパネルと実画面の確認も合わせて行います。

問題を解消したら、対象ページだけに強制ヘッダーを適用し、利用者が使う本番相当のHTTPS環境で確認します。最初にページのコンソールで状態を読みます。ブラウザーコンソールでは次の式を実行します。

console.log(self.crossOriginIsolated);

trueであれば、そのページの実行環境が分離状態として認識されています。falseの場合は、トップレベル文書の実際のレスポンスヘッダー、HTTPS、Permissions-Policy、リダイレクトやCDNで重複・変形したヘッダー、ページが別のiframe内にあるかを確認します。COEPに拒否された資源はNetworkパネルの応答ヘッダーとコンソールを突き合わせ、提供者側のCORSまたはCORP設定が必要かを判断します。拡張機能やキャッシュがある場合は、別プロファイルやキャッシュを消した状態でも再現を確かめると、環境固有の結果を切り分けやすくなります。

分離状態を確認した後は、目的の機能自体も動作させます。SharedArrayBufferなどが取得できるだけでなく、処理結果、Workerとのメッセージ、画面表示、パフォーマンス計測が期待どおりかを確認してください。対象ブラウザーのすべてで機能が使えるとは限らないため、falseの場合の代替処理やエラーメッセージも用意します。ブラウザーごとに正常系と非対応時の双方を記録すれば、設定変更後の問い合わせにも根拠を持って対応できます。

Report-Onlyで見つかった問題は、資源の置き換え、CORS設定、公開資源に限ったCORP付与、外部機能の無効化などで解消してから強制に進みます。許可を広げるだけで済ませず、読者や利用者ごとに返るデータでないかを資源オーナーと確認してください。最後に、適用したURL・レスポンスヘッダー・確認したブラウザー・例外と再確認日を記録します。人の操作を含む導線は、開発者ツールの数値だけで合格にせず、担当者が実際に画面を操作して照合します。

iframe・OAuth・決済の互換性を実画面で試す

COOPのsame-originは、ポリシーやオリジンの組み合わせが一致しないポップアップとの閲覧コンテキストグループを分け、openerとの参照を切ることがあります。これにより、window.openerを読む処理、window.open()が返した参照を使う処理、postMessageで認証結果を返すOAuthや決済の連携が影響を受ける可能性があります。ログイン画面を開けたことだけで完了とせず、本人確認、キャンセル、エラー、決済完了後の元画面への復帰まで試します。

same-origin-allow-popupsは、same-originとは別のCOOP値です。信頼した外部ポップアップとの参照を保ちたい要件があるからといって、同じ分離条件を満たす置き換えとして扱わないでください。必要機能の要件がsame-originを求める場合、ポップアップの依存をなくす設計、通常ページを経由するフロー、別オリジンへ認証導線を分離する方法などを、認証事業者と相談します。どの値でも既存OAuthが維持されると決めつけず、対象のプロバイダーで検証してください。

iframeでは、親ページがCOEPを有効にすると、埋め込むクロスオリジン文書やその子資源にも提供側の協力が必要になります。地図、動画、フォーム、チャットなどの提供者が必要なヘッダーを出せるかを先に確かめます。埋め込み先の中でSharedArrayBuffer等を使う場合は、子ページ自身の分離対応に加え、親がiframeのallow属性でcross-origin-isolated機能を許可することや、祖先を含むPermissions-Policyの条件も関係します。入れ子のiframeやWorkerがあるなら、その先も含めて再帰的に確認します。

フレーム内でカメラやマイクを使う場合は、Permissions-Policyやallow属性に加えて、HTTPSと利用者の許可も必要です。ただし、利用者の許可はCross-Origin Isolation自体の成立条件ではありません。COEP、機能の委譲、ブラウザー対応を別々に確認し、どの層が拒否したかを許可・拒否の両方のケースで試します。

これらを踏まえ、候補ページごとに「必要機能が使える」「必須の外部資源が表示される」「ログインや決済が完了する」「非対応時の代替が動く」を確認項目にします。どれか一つでも業務上の必須条件を満たせない場合は、ヘッダーの適用範囲をさらに絞るか、外部連携の実装を見直してから再評価します。分離状態と業務導線の両方が成立したページだけを適用対象にします。

よくある質問

Cross-Origin Isolationを有効にするヘッダーは何ですか？

トップレベル文書にCOOP: same-originを設定し、COEPにはrequire-corpまたは対象ブラウザーが対応するcredentiallessを設定します。HTTPSなどのセキュアコンテキストであり、Permissions-Policyがcross-origin-isolated機能を拒否していないことも必要です。最後にページ上でself.crossOriginIsolatedがtrueか確認します。

Report-OnlyヘッダーだけでSharedArrayBufferは使えますか？

使える状態にはなりません。Report-Onlyはポリシーを強制せず、影響を報告するための設定です。実際に機能を使うには、問題を解消したうえで強制COOPとCOEPを適用し、分離状態と機能の両方を確認します。

same-origin-allow-popupsをsame-originの代わりに設定できますか？

代わりにはなりません。ポップアップとの関係を保つためのsame-origin-allow-popupsは、COOP same-originとは異なる値です。Cross-Origin Isolationを必要とするページでは、仕様上の条件に合ったCOOPを維持しながら、OAuthや決済のポップアップ依存を個別に検証・設計します。

credentiallessなら、クロスオリジンのすべての資源を読み込めますか？

いいえ。認証情報を省略するのはクロスオリジンのno-corsリクエストです。同一オリジンやCORSモードのリクエスト全般から認証情報を取り除く設定ではなく、CSPなど別の制御にも従います。対象ブラウザーの対応と、認証情報なしで安全に提供できる資源かを確認してください。

外部の画像やスクリプトには必ずCORPを付けますか？

すべてに同じヘッダーを付ける必要はありません。CORSモードで取得できるなら提供側のCORS許可を使い、require-corpでno-cors資源を使う場合は資源側のCORPも選択肢になります。cross-originを付けるのは、誰でも取得してよい公開資源に限り、会員向け情報や個別データに許可を広げないでください。

コーポレートサイト全体にCOOPとCOEPを設定すべきですか？

必要機能を使うページと、そのページが依存する資源に範囲を絞って判断します。全体に適用すると、対象外のページまで外部埋め込みやポップアップに影響する場合があります。まず対象ブラウザーと業務導線を定め、限定ページで検証してから適用範囲を決めます。

iframe内で分離が必要な機能を使う場合は何を見ますか？

親のCOEPで埋め込みが読み込めるかに加え、子ページ自身の分離対応、iframeのallow属性、祖先を含むPermissions-Policy、埋め込み先のブラウザー対応を確認します。カメラやマイクなど、別途ユーザーの許可を必要とする機能を使う場合は、その機能の許可も切り分けます。入れ子のフレームやWorkerを含め、対象機能が必要な画面を実際に操作してください。

参考情報

WHATWG HTML Standard §7.1.3 Cross-origin opener policies — COOPの値と閲覧コンテキストグループの扱い。
WHATWG HTML Standard §7.1.4 Cross-origin embedder policies — COEPのrequire-corp・credentiallessと資源の許可条件。
WHATWG Fetch Standard「Cross-Origin-Embedder-Policy allows credentials」 — credentiallessで認証情報を許可するリクエスト条件。
MDN「Cross-Origin-Embedder-Policy (COEP) header」 — COEPの設定例とブラウザー互換性。
MDN「Cross-Origin-Opener-Policy (COOP) header」 — ポップアップとopener参照への影響。
web.dev「A guide to enable cross-origin isolation」 — 2021年公開の段階導入ガイド。Report-Onlyや影響調査の参考として読み、ブラウザー対応に関する記述は現行仕様・互換性情報と区別します。