ドメイン全体のスクリプト作成を制限し、ブラウザから専用リソースをリクエストするための新しい HTTP レスポンス ヘッダー。
Origin-Agent-Cluster: 同一サイトのクロスオリジン ページ間での同期スクリプト アクセスを防ぐようブラウザに指示する、新しい HTTP レスポンス ヘッダーです。ブラウザは、送信元が専用プロセスなどの独自の個別のリソースを取得する必要があることを示すヒントとして、Origin-Agent-Cluster を使用する場合もあります。
ブラウザの互換性
現在、Origin-Agent-Cluster ヘッダーは Chrome 88 以降でのみ実装されています。これは、プロトタイピングする価値があると Mozilla Firefox の代表者と緊密に連携して設計されており、Safari のブラウザ エンジンである WebKit の代表者からも暫定的な評価を受けています。
ただし、現時点ですべてのユーザーに対して Origin-Agent-Cluster ヘッダーをデプロイしても問題はありません。ブラウザを理解できないと、ブラウザは無視されます。また、オリジンキー エージェント クラスタ内のページで実行できる処理は、サイトキー エージェント クラスタ内のページのほうが少ないため（デフォルト）、相互運用性の問題について心配する必要はありません。
ブラウザが同じサイトのオリジンを自動的に分離できない理由
ウェブは同一オリジン ポリシーに基づいています。これは、ドキュメントやスクリプトが別のオリジンのリソースとやり取りする方法を制限するセキュリティ機能です。たとえば、https://a.example でホストされているページは、https://b.example または https://sub.a.example のオリジンとは異なるオリジンにあります。
ブラウザはバックグラウンドで、さまざまな方法でオリジンの分離を使用しています。以前は、別々のオリジンが互いのデータにアクセスできなくても、オペレーティング システムのスレッド、プロセス、メモリ割り当てなどのリソースを共有していました。つまり、1 つのタブの動作が遅くなると、他のすべてのタブの動作も遅くなります。1 つのタブでメモリを使いすぎると ブラウザ全体がクラッシュします
最近のブラウザはより洗練されており、異なるオリジンを異なるプロセスに分割しようとします。実際の動作はブラウザによって異なります。ほとんどのブラウザではタブがある程度分離されていますが、単一のタブ内の異なる iframe でプロセスが共有される場合があります。また、プロセスにはメモリのオーバーヘッドが生じるため、ヒューリスティックを使用して過剰な生成を回避します。たとえば、Firefox にはユーザーが構成可能なプロセスの上限があり、Chrome ではメモリが多いパソコンとモバイルで動作が異なります。
こうしたヒューリスティックは完璧ではありません。また、重要な制限もあります。https://sub.a.example や https://a.example のようなサブドメインの相互通信を許可する同一オリジン ポリシーには例外があるため、ブラウザでサブドメインを自動的に分離することはできません。
このデフォルトの動作は「サイトキー エージェント クラスタ」と呼ばれます。つまり、ブラウザはサイトに基づいてページをグループ化します。新しい Origin-Agent-Cluster ヘッダーは、特定のページのデフォルトの動作を変更するようブラウザに指示し、オリジンキー エージェント クラスタに配置して、まったく同じオリジンを持つ他のページとのみグループ化されるようにします。特に、同一サイトのクロスオリジン ページはエージェント クラスタから除外されます。
このオプトインによる分離により、ブラウザからこれらの新しいオリジンキー エージェント クラスタに、他のオリジンのものと結合されない独自の専用リソースが提供されます。たとえば、このようなページは独自のプロセスを取得することも、別のスレッドでスケジュールすることもできます。ページに Origin-Agent-Cluster ヘッダーを追加することで、ページが専用リソースを利用するメリットをブラウザに示すことができます。
ただし、分離を行ってこれらのメリットを得るには、ブラウザで以前の機能の一部を無効にする必要があります。
オリジンキー ページでできないこと
ページがオリジンキー エージェント クラスタ内にある場合、これまで利用可能だった同一サイトのクロスオリジン ページと通信する機能が一部放棄されます。具体的には、次のとおりです。
document.domainは設定できなくなりました。これは、通常、同一サイトのクロスオリジン ページから互いの DOM に同期的にアクセスできる従来の機能ですが、オリジンキー エージェント クラスタでは無効になっています。postMessage()から他の同一サイトのクロスオリジン ページにWebAssembly.Moduleオブジェクトを送信できなくなりました。（Chrome のみ）他の同一サイトのクロスオリジン ページに
SharedArrayBufferオブジェクトまたはWebAssembly.Memoryオブジェクトを送信できなくなりました。
オリジンキー エージェント クラスタを使用する場合
Origin-Agent-Cluster ヘッダーによるメリットが最も大きいオリジンは次のとおりです。
可能であれば、独自の専用リソースで最高のパフォーマンスを発揮します。たとえば、高いパフォーマンスが要求されるゲーム、ビデオ会議サイト、マルチメディア作成アプリなどです。
オリジンが異なるが、同じサイトのリソースを大量に消費する iframe が含まれます。たとえば、
https://mail.example.comにhttps://chat.example.comiframe が埋め込まれている場合、オリジンキーhttps://mail.example.com/を使用すると、チャットチームが記述したコードが誤ってメールチームによって記述されたコードに干渉することがなくなります。また、ブラウザに対して、個別にスケジュールを設定してパフォーマンスへの影響を軽減するための個別のプロセスを提供できます。オリジンが異なる同一サイトのページに埋め込まれているが、大量のリソースを消費していることを認識している。たとえば、
https://customerservicewidget.example.comでビデオチャット用に大量のリソースが使用され、https://*.example.comを通してさまざまなオリジンに埋め込まれる場合、そのウィジェットを管理するチームは、Origin-Agent-Clusterヘッダーを使用して埋め込み者のパフォーマンスへの影響を減らすことができます。
また、前述のあまり使用されないクロスオリジン通信機能を無効にしても問題ないかどうか、サイトで HTTPS が使用されていることも確認する必要があります。
ただし、これらはあくまでガイドラインです。オリジンキー エージェント クラスタがサイトに役立つかどうかは、最終的に測定によって最適に決定されます。特に、Web Vitals を測定し、場合によってはメモリ使用量も測定して、オリジンキーがどのような影響を及ぼすかを確認する必要があります。（実行中のプロセス数を増やすとプロセスごとのメモリ オーバーヘッドが増加するため、特にメモリ使用量が懸念されます）。オリジンキーを導入して成功を願うだけでは不十分です。
これはクロスオリジン分離とどのような関係ですか？
Origin-Agent-Cluster ヘッダーによるエージェント クラスタのオリジンキーは、Cross-Origin-Opener-Policy ヘッダーと Cross-Origin-Embedder-Policy ヘッダーによるクロスオリジン分離に関連していますが、これとは異なります。
クロスオリジン分離を行うサイトでは、Origin-Agent-Cluster ヘッダーを使用する場合と同じ同一サイトのクロスオリジン通信機能も無効になります。ただし、Origin-Agent-Cluster ヘッダーは、ブラウザがリソース割り当てのヒューリスティックを変更するための追加のヒントとして、クロスオリジン分離に加えても有用です。そのため、すでにクロスオリジン分離されているページであっても、Origin-Agent-Cluster ヘッダーを適用して結果を測定することを検討してください。
Origin-Agent-Cluster ヘッダーの使用方法
Origin-Agent-Cluster ヘッダーを使用するには、次の HTTP レスポンス ヘッダーを送信するようにウェブサーバーを構成します。
Origin-Agent-Cluster: ?1
?1 の値は、ブール値 true 値の構造化ヘッダー構文です。
このヘッダーは、一部のページだけでなく、配信元からのすべてのレスポンスで送信することが重要です。そうしないと、一貫性のない結果になる可能性があります。ブラウザがオリジンキー リクエストを「記憶」し、そのため、リクエストしていないページでもオリジンキー リクエストが「記憶」されます。逆に、ユーザーが最初にアクセスしたページにヘッダーがない場合、ブラウザはオリジンをオリジンキーにしたくないことを記憶し、後続のページのヘッダーを無視します。
この「メモリ」があるのは、オリジンのキー設定の整合性を保つためです。オリジンに、オリジンキーがあるページとそうでないページがある場合、同じオリジンの 2 つのページが別々のエージェント クラスタに配置され、相互に通信できない可能性があります。これは、ウェブ デベロッパーにとってもブラウザ内部にとっても、非常に奇妙です。そのため、代わりに Origin-Agent-Cluster の指定では、特定のオリジンで以前表示されたものと一致しない場合、ヘッダーは無視されます。これにより、Chrome ではコンソールの警告が表示されます。
この一貫性は、ブラウジング コンテキスト グループに限定されます。ブラウジング コンテキスト グループとは、タブ、ウィンドウ、iframe のグループであり、window.opener、frames[0]、window.parent などのメカニズムを介してすべて相互にアクセスできます。つまり、オリジンまたはサイトキーが確定したら（ブラウザがヘッダーを表示するか非表示にするかにかかわらず）、これを変更するには古いタブに一切接続せずに、まったく新しいタブを開く必要があります。
これらの詳細は、Origin-Agent-Cluster ヘッダーのテストで重要となる場合があります。初めてサイトにタグを追加するときは、ページを再読み込みしても機能しません。タブを閉じて、新しいタブを開く必要があります。
Origin-Agent-Cluster ヘッダーが適用されているかどうかを確認するには、JavaScript の window.originAgentCluster プロパティを使用します。ヘッダー（またはクロスオリジン分離などの他のメカニズム）によってオリジンキーが行われた場合は true、そうでない場合は false、Origin-Agent-Cluster ヘッダーを実装していないブラウザでは undefined になります。このデータを分析プラットフォームに記録することで、サーバーが正しく構成されていることを確認できます。
なお、Origin-Agent-Cluster ヘッダーは安全なコンテキスト（HTTPS ページや http://localhost）でのみ機能します。localhost 以外の HTTP ページでは、オリジンキー エージェント クラスタはサポートされていません。
オリジンキーはセキュリティ機能ではない
オリジンキー エージェント クラスタを使用すると、オリジンは同一サイトのクロスオリジン ページからの同期アクセスから分離されますが、Cross-Origin-Resource-Policy や Cross-Origin-Opener-Policy などのセキュリティ関連のヘッダーは保護されません。特に、Spectre などのサイドチャネル攻撃に対して信頼できる保護手段ではありません。
オリジンキーにより、送信元が独自のプロセスを取得することがあり、個別のプロセスはサイドチャネル攻撃に対する重要な防御であるため、これは少し意外かもしれません。ただし、Origin-Agent-Cluster ヘッダーはその点に関するヒントにすぎません。ブラウザには、配信元に別のプロセスを提供する義務はありません。また、さまざまな理由により、提供しない場合があります。
ブラウザが、そのためのテクノロジーを実装していない場合があります。たとえば、現在の Safari と Firefox では、別々のタブをそれぞれのプロセスに配置できますが、iframe についてはまだできません。
ブラウザは、独立したプロセスのオーバーヘッドに値しないと判断する場合があります。たとえば、メモリの少ない Android デバイスや Android WebView の場合、Chrome が使用するプロセスの数をできる限り少なくします。
ブラウザは、
Origin-Agent-Clusterヘッダーが示すリクエストを尊重しますが、プロセスとは異なる分離テクノロジーを使用して尊重できます。たとえば、Chrome では、このようなパフォーマンスの分離のために、プロセスではなくスレッドを使用して探索しています。ユーザーまたは別のサイトで実行されているコードが、すでにオリジンのサイトキー ページに移動したため、整合性の保証が有効になり、
Origin-Agent-Clusterヘッダーが完全に無視されます。
このような理由から、オリジンキー エージェント クラスタをセキュリティ機能として捉えないことが重要です。それよりも、オリジンで専用リソースを利用できると（そして、その代わりに特定の機能をあきらめるという意思を示すことで、ブラウザがリソースの割り当てを優先できるようにする方法です。
フィードバック
Origin-Agent-Cluster ヘッダーを使用している、または使用を検討している方は、Chrome チームまでご連絡ください。公共の利益とサポートは、Google が機能の優先度を判断し、その重要度を他のブラウザ ベンダーに伝えるうえで役立ちます。@ChromiumDev にツイートして、Chrome DevRel に感想や経験を伝えてください。
この仕様や機能の詳細について不明な点がある場合は、HTML 標準 GitHub リポジトリに問題を投稿してください。また、Chrome の実装で問題が発生した場合は、new.crbug.com で [Components] フィールドを Internals>Sandbox>SiteIsolation に設定してバグを報告してください。
さらに詳しく
オリジンキー エージェント クラスタの詳細については、次のリンクをご覧ください。