ドメイン全体のスクリプトを制限し、ブラウザから専用リソースをリクエストする新しい HTTP レスポンス ヘッダー。
Origin-Agent-Cluster: 同一サイトのクロスオリジン ページ間での同期スクリプト アクセスを防ぐようブラウザに指示する、新しい HTTP レスポンス ヘッダーです。ブラウザは、オリジンが専用のプロセスなど、独自の個別のリソースを取得する必要があるというヒントとして Origin-Agent-Cluster を使用することもあります。
ブラウザの互換性
現在、Origin-Agent-Cluster ヘッダーは Chrome 88 以降でのみ実装されています。このプロトタイプは、Mozilla Firefox の担当者と緊密に連携して設計されました。Mozilla Firefox の担当者は、このプロトタイプをプロトタイピングに値すると評価しています。また、Safari で使用されているブラウザ エンジンである WebKit の担当者からは前向きな評価を受けています。
ただし、現時点ですべてのユーザーに対して Origin-Agent-Cluster ヘッダーをデプロイしても問題はありません。認識できないブラウザは無視するだけです。また、オリジンキー エージェント クラスタ内のページは、サイトキー（デフォルト）のページよりも実際にできることが少ないため、相互運用性の問題を心配する必要はありません。
ブラウザが同じサイトのオリジンを自動的に分離できない理由
ウェブは同一オリジン ポリシーに基づいて構築されています。これは、ドキュメントやスクリプトが別のオリジンのリソースとやり取りする方法を制限するセキュリティ機能です。たとえば、https://a.example でホストされているページは、https://b.example または https://sub.a.example のオリジンとは異なるオリジンにあります。
ブラウザは、オリジンが提供する分離をさまざまな方法で使用します。以前は、個別のオリジンが互いのデータにアクセスできない場合でも、オペレーティング システムのスレッド、プロセス、メモリ割り当てなどのリソースを共有していました。つまり、1 つのタブが遅いと、他のすべてのタブも遅くなります。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 を使用していることも確認する必要があります。
ただし、これらはあくまでガイドラインです。オリジンキー エージェント クラスタがサイトに役立つかどうかは、最終的には測定によって判断するのが最善です。特に、ウェブ バイタルズとメモリ使用量を測定して、オリジン キー設定の影響を確認することをおすすめします。（特にメモリ使用量は懸念される可能性があります。実行中のプロセス数が増えると、プロセスあたりのメモリ オーバーヘッドが増加する可能性があります）。オリジンキーを導入して成功を願うだけでは不十分です。
これはクロスオリジン分離とどのように関係していますか？
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 では、コンソールに警告が表示されます。
この整合性は、ブラウジング コンテキスト グループに限定されます。ブラウジング コンテキスト グループとは、window.opener、frames[0]、window.parent などのメカニズムを通じて相互にアクセスできるタブ、ウィンドウ、iframe のグループです。つまり、オリジンまたはサイトキーが確定したら（ブラウザがヘッダーを表示するか非表示にするかにかかわらず）、これを変更するには古いタブに一切接続せずに、まったく新しいタブを開く必要があります。
これらの詳細は、Origin-Agent-Cluster ヘッダーのテストに重要です。サイトに初めて追加する場合、ページを再読み込みしても機能しません。タブを閉じて新しいタブを開く必要があります。
Origin-Agent-Cluster ヘッダーが適用されているかどうかを確認するには、JavaScript の window.originAgentCluster プロパティを使用します。これは、ヘッダー（またはクロスオリジン分離などの他のメカニズム）がオリジン キーイングを引き起こした場合は true、引き起こさなかった場合は false、Origin-Agent-Cluster ヘッダーを実装していないブラウザでは undefined になります。このデータを分析プラットフォームにロギングすると、サーバーが正しく設定されていることを確認できます。
最後に、Origin-Agent-Cluster ヘッダーは安全なコンテキスト（HTTPS ページまたは http://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 Standard GitHub リポジトリで問題を報告してください。Chrome の実装で問題が発生した場合は、new.crbug.com でバグを報告してください。その際、[Components] フィールドを Internals>Sandbox>SiteIsolation に設定してください。
その他の情報
送信元キーによるエージェント クラスタについて詳しくは、次のリンクをご覧ください。