chrome.declarativeNetRequest

説明

chrome.declarativeNetRequest API を使用してルールを宣言することで、ネットワーク リクエストをブロックまたは変更できます。これにより、拡張機能はネットワーク リクエストをインターセプトしてコンテンツを表示することなく変更できるため、プライバシーが強化されます。

declarativeNetRequest
declarativeNetRequestWithHostAccess

「declarativeNetRequest」と「declarativeNetRequestWithHostAccess」の権限は同じ機能を提供します。これらの違いは、権限がリクエストまたは付与されるタイミングです。

"declarativeNetRequest"
インストール時に権限に関する警告をトリガーしますが、allow、allowAllRequests、block のルールへの暗黙的なアクセスを提供します。ホストへの完全なアクセス権をリクエストする必要がないように、可能な限りこれを使用します。
"declarativeNetRequestFeedback"
パッケージ化されていない拡張機能のデバッグ機能を有効にします。具体的には、getMatchedRules() と onRuleMatchedDebug です。
"declarativeNetRequestWithHostAccess"
インストール時に権限の警告は表示されませんが、ホストでアクションを実行する前にホスト権限をリクエストする必要があります。これは、追加の警告を生成せずに、ホスト権限をすでに持っている拡張機能で宣言型ネット リクエスト ルールを使用する場合に適しています。

Chrome 84 以降

前述の権限に加えて、特定の種類のルールセット（特に静的ルールセット）では、"declarative_net_request" マニフェスト キーを宣言する必要があります。これは、"rule_resources" という単一のキーを含む辞書である必要があります。このキーは、次の例に示すように、Ruleset 型の辞書を含む配列です。（「Ruleset」という名前は単なる配列であるため、マニフェストの JSON には表示されません）。静的ルールセットについては、このドキュメントの後半で説明します。

{
  "name": "My extension",
  ...

  "declarative_net_request" : {
    "rule_resources" : [{
      "id": "ruleset_1",
      "enabled": true,
      "path": "rules_1.json"
    }, {
      "id": "ruleset_2",
      "enabled": false,
      "path": "rules_2.json"
    }]
  },
  "permissions": [
    "declarativeNetRequest",
    "declarativeNetRequestFeedback"
  ],
  "host_permissions": [
    "http://www.blogger.com/*",
    "http://*.google.com/*"
  ],
  ...
}

この API を使用するには、1 つ以上のルールセットを指定します。ルールセットにはルールの配列が含まれています。単一のルールは次のいずれかを行います。

  • ネットワーク リクエストをブロックします。
  • スキーマをアップグレードします（http から https）。
  • 一致するブロックルールを否定して、リクエストがブロックされないようにします。
  • ネットワーク リクエストをリダイレクトします。
  • リクエスト ヘッダーまたはレスポンス ヘッダーを変更します。

ルールセットには 3 種類あり、管理方法が若干異なります。

ダイナミック
ブラウザ セッションと拡張機能のアップグレードをまたいで保持され、拡張機能の使用中に JavaScript を使用して管理されます。
セッション
ブラウザがシャットダウンしたとき、または拡張機能の新しいバージョンがインストールされたときにクリアされます。セッション ルールは、拡張機能の使用中に JavaScript を使用して管理されます。
静的
拡張機能のインストールまたはアップグレード時にパッケージ化、インストール、更新されます。静的ルールは JSON 形式のルールファイルに保存され、マニフェスト ファイルにリストされます。

拡張機能の使用中は、JavaScript を使用して動的ルールセットとセッション ルールセットが管理されます。

  • 動的ルールは、ブラウザ セッションと拡張機能のアップグレードにまたがって保持されます。
  • セッション ルールは、ブラウザがシャットダウンしたときと、新しいバージョンの拡張機能がインストールされたときにクリアされます。

これらのルールセット タイプはそれぞれ 1 つだけです。拡張機能は、ルールの上限を超えない限り、updateDynamicRules() と updateSessionRules() を呼び出すことで、ルールを動的に追加または削除できます。ルールの上限については、ルールの上限をご覧ください。コード例でこの例を確認できます。

動的ルールやセッションルールとは異なり、静的ルールは拡張機能のインストールまたはアップグレード時にパッケージ化、インストール、更新されます。これらは JSON 形式のルールファイルに保存され、前述のとおり "declarative_net_request" キーと "rule_resources" キー、および 1 つ以上の Ruleset 辞書を使用して拡張機能に示されます。Ruleset ディクショナリには、ルールファイルへのパス、ファイルに含まれるルールセットの ID、ルールセットが有効か無効かが含まれます。最後の 2 つは、ルールセットをプログラムで有効または無効にする場合に重要です。

{
  ...
  "declarative_net_request" : {
    "rule_resources" : [{
      "id": "ruleset_1",
      "enabled": true,
      "path": "rules_1.json"
    },
    ...
    ]
  }
  ...
}

ルールファイルをテストするには、拡張機能を解凍して読み込みます。無効な静的ルールに関するエラーと警告は、パッケージ化されていない拡張機能に対してのみ表示されます。パッケージ化された拡張機能の無効な静的ルールは無視されます。

静的ルールセットの変更は、迅速な審査の対象となる場合があります。対象となる変更の迅速な審査をご覧ください。

個々の静的ルールと完全な静的ルールセットの両方を、実行時に有効または無効にできます。

有効な静的ルールとルールセットのセットは、ブラウザ セッション間で保持されます。どちらも拡張機能の更新時に保持されないため、更新後に使用できるのは、ルールファイルに残すことを選択したルールのみです。

パフォーマンス上の理由から、一度に有効にできるルールとルールセットの数にも上限があります。getAvailableStaticRuleCount() を呼び出して、有効にできる追加ルールの数を確認します。ルールの上限については、ルールの上限をご覧ください。

静的ルールを有効または無効にするには、updateStaticRules() を呼び出します。このメソッドは、有効または無効にするルールの ID の配列を含む UpdateStaticRulesOptions オブジェクトを受け取ります。ID は、Ruleset 辞書の "id" キーを使用して定義されます。無効な静的ルールの最大数は 5,000 です。

静的ルールセットを有効または無効にするには、updateEnabledRulesets() を呼び出します。このメソッドは、有効または無効にするルールセットの ID の配列を含む UpdateRulesetOptions オブジェクトを受け取ります。ID は、Ruleset 辞書の "id" キーを使用して定義されます。

タイプに関係なく、ルールは次の図に示すように 4 つのフィールドで始まります。"id" キーと "priority" キーは数値を指定しますが、"action" キーと "condition" キーは複数のブロック条件とリダイレクト条件を指定できます。次のルールは、"foo.com" から送信され、"abc" を部分文字列として含む URL へのすべてのスクリプト リクエストをブロックします。

{
  "id" : 1,
  "priority": 1,
  "action" : { "type" : "block" },
  "condition" : {
    "urlFilter" : "abc",
    "initiatorDomains" : ["foo.com"],
    "resourceTypes" : ["script"]
  }
}

Declarative Net Request では、パターン マッチング構文または正規表現を使用して URL を照合できます。

ルールの "condition" キーは、指定されたドメインの URL に対してアクションを実行するための "urlFilter" キーを許可します。パターンは、パターン マッチング トークンを使用して作成します。いくつか例を挙げましょう。

urlFilter 一致 一致しない
"abc" https://abcd.com
https://example.com/abcd		 https://ab.com
"abc*d" https://abcd.com
https://example.com/abcxyzd		 https://abc.com
"||a.example.com" https://a.example.com/
https://b.a.example.com/xyz
https://a.example.company		 https://example.com/
"|https*" https://example.com http://example.com/
http://https.com
"example*^123|" https://example.com/123
http://abc.com/example?123		 https://example.com/1234
https://abc.com/example0123

条件では正規表現も使用できます。"regexFilter" キーをご覧ください。これらの条件に適用される上限については、正規表現を使用するルールをご覧ください。

ルールを作成する際は、常にドメイン全体が一致するように注意してください。そうしないと、ルールが予期しない状況で一致する可能性があります。たとえば、パターン マッチング構文を使用する場合:

  • google.com が https://example.com/?param=google.com に誤って一致する
  • ||google.com が https://google.company に誤って一致する
  • https://www.google.com が https://example.com/?param=https://www.google.com に誤って一致する

使用を検討してください。

  • ||google.com/。すべてのパスとすべてのサブドメインに一致します。
  • |https://www.google.com/。すべてのパスに一致し、サブドメインには一致しません。

同様に、^ 文字と / 文字を使用して正規表現をアンカーします。たとえば、^https:\/\/www\.google\.com\/ は https://www.google.com の任意のパスと一致します。

DNR ルールは、ネットワーク リクエストのライフサイクルのさまざまな段階でブラウザによって適用されます。

リクエストが行われる前に、拡張機能は一致するルールを使用してリクエストをブロックまたはリダイレクトできます（HTTP から HTTPS へのスキームのアップグレードを含む）。

ブラウザは、拡張機能ごとに一致するルールのリストを決定します。modifyHeaders アクションを含むルールは、後で処理されるため、ここには含まれません。また、responseHeaders 条件を含むルールは後で（レスポンス ヘッダーが利用可能になったとき）考慮されるため、含まれません。

次に、Chrome はリクエストごとに最大 1 つの候補を拡張機能ごとに選択します。Chrome は、一致するすべてのルールを優先度順に並べ替えて、一致するルールを見つけます。優先度が同じルールは、アクション（allow または allowAllRequests > block > upgradeScheme > redirect）で順序付けされます。

候補が allow ルールまたは allowAllRequests ルールである場合、またはリクエストが行われているフレームが以前にこの拡張機能の優先度が同等以上の allowAllRequests ルールと一致した場合、リクエストは「許可」され、拡張機能はリクエストに影響しません。

複数の拡張機能がこのリクエストをブロックまたはリダイレクトしようとしている場合は、実行するアクションが 1 つ選択されます。Chrome では、ルールを block > redirect または upgradeScheme > allow または allowAllRequests の順に並べ替えることで、この処理を行います。2 つのルールが同じタイプの場合、Chrome は最後にインストールされた拡張機能のルールを選択します。

Chrome がリクエスト ヘッダーをサーバーに送信する前に、一致する modifyHeaders ルールに基づいてヘッダーが更新されます。

Chrome は、単一の拡張機能内で、一致するすべての modifyHeaders ルールを見つけて、実行する変更のリストを作成します。以前と同様に、一致する allow ルールまたは allowAllRequests ルールよりも優先度の高いルールのみが含まれます。

これらのルールは、Chrome によって、最近インストールされた拡張機能のルールが古い拡張機能のルールよりも常に先に評価される順序で適用されます。また、1 つの拡張機能の優先度の高いルールは、同じ拡張機能の優先度の低いルールよりも常に先に適用されます。特に、拡張機能間でも次のようになります。

  • ルールでヘッダーに追加した場合、優先度の低いルールではそのヘッダーにのみ追加できます。設定と削除のオペレーションは許可されていません。
  • ルールでヘッダーが設定されている場合、同じ拡張機能の優先度の低いルールのみがそのヘッダーに追加できます。それ以外の変更は許可されていません。
  • ルールでヘッダーが削除された場合、優先度の低いルールでヘッダーをさらに変更することはできません。

レスポンス ヘッダーが受信されると、Chrome は responseHeaders 条件を含むルールを評価します。

これらのルールを action と priority で並べ替え、一致する allow または allowAllRequests ルールによって冗長になったルールを除外した後（これは「リクエスト前」の手順と同じように行われます）、Chrome は拡張機能の代わりにリクエストをブロックまたはリダイレクトすることがあります。

リクエストがこの段階に達した場合、リクエストはすでにサーバーに送信されており、サーバーはリクエスト本文などのデータを受信しています。レスポンス ヘッダー条件を含むブロックまたはリダイレクト ルールは実行されますが、リクエストを実際にブロックまたはリダイレクトすることはできません。

ブロックルールの場合は、リクエストを行ったページがブロックされたレスポンスを受け取り、Chrome がリクエストを早期に終了することで処理されます。リダイレクト ルールの場合、Chrome はリダイレクトされた URL に新しいリクエストを行います。これらの動作が拡張機能のプライバシーに関する期待を満たしているかどうかを検討してください。

リクエストがブロックまたはリダイレクトされない場合、Chrome は modifyHeaders ルールを適用します。レスポンス ヘッダーへの変更の適用は、「リクエスト ヘッダーが送信される前」で説明した方法と同じです。リクエストはすでに送信されているため、リクエスト ヘッダーに変更を適用しても何も起こりません。

安全なルールは、block、allow、allowAllRequests、upgradeScheme のアクションを含むルールとして定義されます。これらのルールには、動的ルールの割り当ての増加が適用されます。

ブラウザでルールを読み込んで評価するとパフォーマンスのオーバーヘッドが発生するため、API を使用する際にはいくつかの制限が適用されます。上限は、使用するルールの種類によって異なります。

静的ルールは、マニフェスト ファイルで宣言されたルールファイルで指定されたルールです。拡張機能は、"rule_resources" マニフェスト キーの一部として最大 100 個の静的ルールセットを指定できますが、一度に有効にできるのは 50 個のみです。後者は MAX_NUMBER_OF_ENABLED_STATIC_RULESETS と呼ばれます。これらのルールセットを合わせると、少なくとも 30,000 個のルールが保証されます。これは GUARANTEED_MINIMUM_STATIC_RULES と呼ばれます。

その後利用できるルールの数は、ユーザーのブラウザにインストールされているすべての拡張機能で有効になっているルールの数によって異なります。この番号は、ランタイムに getAvailableStaticRuleCount() を呼び出すことで取得できます。コード例でこの例を確認できます。

拡張機能には最大 5,000 個のセッション ルールを設定できます。これは MAX_NUMBER_OF_SESSION_RULES として公開されます。

Chrome 120 より前は、動的ルールとセッション ルールの合計が 5, 000 個に制限されていました。

拡張機能には少なくとも 5,000 個の動的ルールを設定できます。これは MAX_NUMBER_OF_UNSAFE_DYNAMIC_RULES として公開されます。

Chrome 121 以降では、安全な動的ルールの上限が 30,000 ルールに引き上げられ、MAX_NUMBER_OF_DYNAMIC_RULES として公開されます。上限の 5,000 以内で追加された安全でないルールも、この上限にカウントされます。

Chrome 120 より前は、動的ルールとセッション ルールの合計が 5, 000 個という上限がありました。

すべての種類のルールで正規表現を使用できますが、各種類の正規表現ルールの合計数は 1, 000 を超えることはできません。これは MAX_NUMBER_OF_REGEX_RULES と呼ばれます。

また、コンパイル後の各ルールは 2 KB 未満にする必要があります。これは、ルールの複雑さとほぼ相関関係があります。この上限を超えるルールを読み込もうとすると、次のような警告が表示され、ルールは無視されます。

rules_1.json: Rule with id 1 specified a more complex regex than allowed
as part of the "regexFilter" key.

declarativeNetRequest は、ネットワーク スタックに到達するリクエストにのみ適用されます。これには HTTP キャッシュからのレスポンスが含まれますが、サービス ワーカーの onfetch ハンドラを通過するレスポンスは含まれない場合があります。declarativeNetRequest は、サービス ワーカーによって生成されたレスポンスや CacheStorage から取得されたレスポンスには影響しませんが、サービス ワーカーで行われた fetch() の呼び出しには影響します。

declarativeNetRequest ルールでは、公開リソース リクエストからウェブ アクセスできないリソースにリダイレクトすることはできません。このような操作を行うと、エラーが発生します。これは、指定されたウェブ アクセス可能なリソースがリダイレクトする拡張機能によって所有されている場合でも同様です。declarativeNetRequest のリソースを宣言するには、マニフェストの "web_accessible_resources" 配列を使用します。

追加オペレーションは、次のリクエスト ヘッダーでのみサポートされています。accept、accept-encoding、accept-language、access-control-request-headers、cache-control、connection、content-language、cookie、forwarded、if-match、if-none-match、keep-alive、range、te、trailer、transfer-encoding、upgrade、user-agent、via、want-digest、x-forwarded-for。この許可リストでは大文字と小文字が区別されます（バグ 449152902）。

リクエスト ヘッダーまたはレスポンス ヘッダーに追加する場合、ブラウザは可能な限り適切な区切り文字を使用します。

次の例は、updateDynamicRules() を呼び出す方法を示しています。updateSessionRules() の手順も同じです。

// Get arrays containing new and old rules
const newRules = await getNewRules();
const oldRules = await chrome.declarativeNetRequest.getDynamicRules();
const oldRuleIds = oldRules.map(rule => rule.id);

// Use the arrays to update the dynamic rules
await chrome.declarativeNetRequest.updateDynamicRules({
  removeRuleIds: oldRuleIds,
  addRules: newRules
});

次の例は、使用可能な静的ルールセットの数と有効な静的ルールセットの最大数を考慮して、ルールセットを有効または無効にする方法を示しています。これは、必要な静的ルールの数が許容される数を超える場合に行います。これを行うには、ルールセットの一部を無効にした状態で（マニフェスト ファイル内で "Enabled" を false に設定）、ルールセットの一部をインストールする必要があります。

async function updateStaticRules(enableRulesetIds, disableCandidateIds) {
  // Create the options structure for the call to updateEnabledRulesets()
  let options = { enableRulesetIds: enableRulesetIds }
  // Get the number of enabled static rules
  const enabledStaticCount = await chrome.declarativeNetRequest.getEnabledRulesets();
  // Compare rule counts to determine if anything needs to be disabled so that
  // new rules can be enabled
  const proposedCount = enableRulesetIds.length;
  if (enabledStaticCount + proposedCount > chrome.declarativeNetRequest.MAX_NUMBER_OF_ENABLED_STATIC_RULESETS) {
    options.disableRulesetIds = disableCandidateIds
  }
  // Update the enabled static rules
  await chrome.declarativeNetRequest.updateEnabledRulesets(options);
}

次の例は、Chrome が拡張機能のルールをどのように優先順位付けするかを示しています。確認する際は、優先順位付けルールを別のウィンドウで開くことをおすすめします。

これらの例では、*://*.example.com/* へのホスト権限が必要です。

特定の URL の優先度を判断するには、（デベロッパーが定義した）"priority" キー、"action" キー、"urlFilter" キーを確認します。これらの例は、以下のルールファイルの例を参照しています。

https://google.com へのナビゲーション
この URL には、ID が 1 と 4 の 2 つのルールが適用されます。"block" アクションは "redirect" アクションよりも優先度が高いため、ID 1 のルールが適用されます。残りのルールは、URL が長すぎるため適用されません。
https://google.com/1234 へのナビゲーション
URL が長くなったため、ID 1 と 4 のルールに加えて、ID 2 のルールも一致するようになりました。"allow" は "block" と "redirect" よりも優先度が高いため、ID 2 のルールが適用されます。
https://google.com/12345 へのナビゲーション
4 つのルールすべてがこの URL と一致します。ID 3 のルールは、デベロッパーが定義した優先度がグループ内で最も高いため、適用されます。
[
  {
    "id": 1,
    "priority": 1,
    "action": { "type": "block" },
    "condition": {"urlFilter": "||google.com/", "resourceTypes": ["main_frame"] }
  },
  {
    "id": 2,
    "priority": 1,
    "action": { "type": "allow" },
    "condition": { "urlFilter": "||google.com/123", "resourceTypes": ["main_frame"] }
  },
  {
    "id": 3,
    "priority": 2,
    "action": { "type": "block" },
    "condition": { "urlFilter": "||google.com/12345", "resourceTypes": ["main_frame"] }
  },
  {
    "id": 4,
    "priority": 1,
    "action": { "type": "redirect", "redirect": { "url": "https://example.com" } },
    "condition": { "urlFilter": "||google.com/", "resourceTypes": ["main_frame"] }
  },
]

次の例では、*://*.example.com/* に対するホスト権限が必要です。

次の例は、example.com から拡張機能内のページにリクエストをリダイレクトする方法を示しています。拡張機能のパス /a.jpg は chrome-extension://EXTENSION_ID/a.jpg に解決されます。ここで、EXTENSION_ID は拡張機能の ID です。この機能を動作させるには、マニフェストで /a.jpg をウェブ アクセス可能なリソースとして宣言する必要があります。

{
  "id": 1,
  "priority": 1,
  "action": { "type": "redirect", "redirect": { "extensionPath": "/a.jpg" } },
  "condition": {
    "urlFilter": "||https://www.example.com/",
    "resourceTypes": ["main_frame"]
  }
}

次の例では、"transform" キーを使用して example.com のサブドメインにリダイレクトしています。ドメイン名アンカー（「||」）を使用して、example.com からのスキームを含むリクエストをインターセプトしています。"transform" の "scheme" キーは、サブドメインへのリダイレクトで常に「https」を使用することを指定しています。

{
  "id": 1,
  "priority": 1,
  "action": {
    "type": "redirect",
    "redirect": {
      "transform": { "scheme": "https", "host": "new.example.com" }
    }
  },
  "condition": {
    "urlFilter": "||example.com/",
    "resourceTypes": ["main_frame"]
  }
}

次の例では、正規表現を使用して https://www.abc.xyz.com/path から https://abc.xyz.com/path にリダイレクトします。"regexFilter" キーで、期間がエスケープされ、キャプチャ グループが「abc」または「def」を選択していることを確認します。"regexSubstitution" キーは、正規表現の最初の一致を「\1」を使用して指定します。この場合、リダイレクトされた URL から「abc」がキャプチャされ、置換に配置されます。

{
  "id": 1,
  "priority": 1,
  "action": {
    "type": "redirect",
    "redirect": {
      "regexSubstitution": "https://\\1.xyz.com/"
    }
  },
  "condition": {
    "regexFilter": "^https://www\\.(abc|def)\\.xyz\\.com/",
    "resourceTypes": [
      "main_frame"
    ]
  }
}

次の例では、メインフレームとサブフレームの両方からすべての Cookie を削除します。

{
  "id": 1,
  "priority": 1,
  "action": {
    "type": "modifyHeaders",
    "requestHeaders": [{ "header": "cookie", "operation": "remove" }]
  },
  "condition": { "resourceTypes": ["main_frame", "sub_frame"] }
}

これは、リクエストが送信元のフレームに対してファーストパーティかサードパーティかを示します。リクエストが送信されたフレームと同じドメイン（eTLD+1）を持つ場合、そのリクエストはファーストパーティ リクエストと見なされます。

「firstParty」
ネットワーク リクエストは、そのリクエストが開始されたフレームのファーストパーティです。

「thirdParty」
ネットワーク リクエストは、そのリクエストが開始されたフレームのサードパーティです。

Chrome 88 以降
  • displayActionCountAsBadgeText

    ブール値（省略可）

    ページの操作数を拡張機能のバッジテキストとして自動的に表示するかどうか。この設定はセッション間で保持されます。

  • tabUpdate

    TabActionCountUpdate 省略可

    Chrome 89 以降

    タブのアクション数を調整する方法の詳細。

Chrome 111 以降
  • rulesetId

    文字列

    静的 Ruleset に対応する ID。

Chrome 111 以降
  • ruleIds

    number[] 省略可

    指定した場合、一致する ID を持つルールのみが含まれます。

Chrome 128 以降
  • excludedValues

    string[] 省略可

    指定した場合、ヘッダーが存在し、その値にこのリストの要素が 1 つ以上含まれていると、この条件は一致しません。これは values と同じ一致パターンの構文を使用します。

  • header

    文字列

    ヘッダーの名前。この条件は、values と excludedValues の両方が指定されていない場合にのみ、名前に一致します。

  • values

    string[] 省略可

    指定した場合、ヘッダーの値がこのリスト内の少なくとも 1 つのパターンと一致すると、この条件は一致します。これにより、大文字と小文字を区別しないヘッダー値の一致と、次の構造がサポートされます。

    '*' : 任意の数の文字に一致します。

    「?」 : 0 個または 1 個の文字に一致します。

    '*' と '?' はバックスラッシュでエスケープできます（例: '\*'、'\?'）。

Chrome 86 以降

ここでは、「modifyHeaders」ルールの可能なオペレーションについて説明します。

「append」
指定されたヘッダーの新しいエントリを追加します。リクエストのヘッダーを変更する場合、このオペレーションは特定のヘッダーでのみサポートされます。

「set」
指定されたヘッダーの新しい値を設定し、同じ名前の既存のヘッダーを削除します。

「remove」
指定されたヘッダーのすべてのエントリを削除します。

Chrome 87 以降
  • isSupported

    ブール値

  • reason

    UnsupportedRegexReason 省略可

    正規表現がサポートされていない理由を指定します。isSupported が false の場合にのみ指定されます。

  • ruleId

    数値

    一致するルールの ID。

  • rulesetId

    文字列

    このルールが属する Ruleset の ID。動的ルールのセットから派生したルールの場合、これは DYNAMIC_RULESET_ID と同じになります。

  • ルール

    MatchedRule

  • tabId

    数値

    リクエストの送信元タブの tabId（タブがまだアクティブな場合）。それ以外の場合は -1。

  • timeStamp

    数値

    ルールが一致した時間。タイムスタンプは、時刻の JavaScript 規則（エポックからの経過ミリ秒数）に対応します。

  • minTimeStamp

    number 省略可

    指定した場合、指定されたタイムスタンプ以降のルールのみが一致します。

  • tabId

    number 省略可

    指定した場合、指定したタブのルールのみが一致します。-1 に設定されている場合、アクティブなタブに関連付けられていないルールに一致します。

Chrome 86 以降
  • header

    文字列

    変更するヘッダーの名前。

  • オペレーション

    HeaderOperation

    ヘッダーに対して実行するオペレーション。

  • 値

    文字列 省略可

    ヘッダーの新しい値。append オペレーションと set オペレーションで指定する必要があります。

  • key

    文字列

  • replaceOnly

    ブール値（省略可）

    Chrome 94 以降

    true の場合、クエリキーがすでに存在する場合にのみ置き換えられます。それ以外の場合は、キーがない場合に追加されます。デフォルトは false です。

  • 値

    文字列

  • addOrReplaceParams

    QueryKeyValue[] 省略可

    追加または置換するクエリ Key-Value ペアのリスト。

  • removeParams

    string[] 省略可

    削除するクエリキーのリスト。

  • extensionPath

    文字列 省略可

    拡張機能ディレクトリからの相対パス。「/」で始める必要があります。

  • regexSubstitution

    文字列 省略可

    regexFilter を指定するルールの置換パターン。URL 内の regexFilter の最初の一致がこのパターンに置き換えられます。regexSubstitution 内では、バックスラッシュでエスケープされた数字（\1 ～\9）を使用して、対応するキャプチャ グループを挿入できます。\0 は、一致するテキスト全体を指します。

  • 変換

    URLTransform 省略可

    実行する URL 変換。

  • URL

    文字列 省略可

    リダイレクト URL。JavaScript URL へのリダイレクトは許可されていません。

Chrome 87 以降
  • isCaseSensitive

    ブール値（省略可）

    指定された regex で大文字と小文字が区別されるかどうか。デフォルトは true です。

  • regex

    文字列

    チェックする正規表現。

  • requireCapturing

    ブール値（省略可）

    指定された regex にキャプチャが必要かどうか。キャプチャが必要なのは、regexSubstition アクションを指定するリダイレクト ルールのみです。デフォルトは false です。

  • documentId

    文字列 省略可

    Chrome 106 以降

    このリクエストがフレームに対するものである場合、フレームのドキュメントの一意の識別子。

  • documentLifecycle

    DocumentLifecycle 省略可

    Chrome 106 以降

    このリクエストがフレームに対するものである場合、フレームのドキュメントのライフサイクル。

  • frameId

    数値

    値 0 は、リクエストがメインフレームで発生したことを示します。正の値は、リクエストが発生したサブフレームの ID を示します。（サブ）フレームのドキュメントが読み込まれた場合（type が main_frame または sub_frame の場合）、frameId は外側のフレームの ID ではなく、このフレームの ID を示します。フレーム ID はタブ内で一意です。

  • frameType

    FrameType 省略可

    Chrome 106 以降

    このリクエストがフレームに対するものである場合のフレームのタイプ。

  • イニシエータ

    文字列 省略可

    リクエストが開始されたオリジン。これはリダイレクトによって変更されません。これが不透明なオリジンである場合は、文字列「null」が使用されます。

  • method

    文字列

    標準の HTTP メソッド。

  • parentDocumentId

    文字列 省略可

    Chrome 106 以降

    このリクエストがフレームに対するもので、親がある場合、フレームの親ドキュメントの固有識別子。

  • parentFrameId

    数値

    リクエストを送信したフレームをラップするフレームの ID。親フレームが存在しない場合は -1 に設定します。

  • requestId

    文字列

    リクエストの ID。リクエスト ID はブラウザ セッション内で一意です。

  • tabId

    数値

    リクエストが行われるタブの ID。リクエストがタブに関連付けられていない場合は -1 に設定します。

  • リクエストのリソースタイプ。

  • URL

    文字列

    リクエストの URL。

Chrome 91 以降

ネットワーク リクエストの HTTP リクエスト メソッドを表します。

"connect"

"delete"

"get"

"head"

"options"

"patch"

"post"

"put"

"other"

これは、ネットワーク リクエストのリソースタイプを表します。

"main_frame"

"sub_frame"

"stylesheet"

"script"

"image"

「font」

"object"

"xmlhttprequest"

"ping"

"csp_report"

"media"

"websocket"

"webtransport"

"webbundle"

"other"

  • アクション

    RuleAction

    このルールが一致した場合に実行するアクション。

  • 状態

    RuleCondition

    このルールがトリガーされる条件。

  • id

    数値

    ルールを一意に識別する ID。必須で、1 以上にする必要があります。

  • priority

    number 省略可

    ルールの優先順位。デフォルトは 1 です。指定する場合は、1 以上にする必要があります。

  • リダイレクト

    Redirect 省略可

    リダイレクトの実行方法を記述します。リダイレクト ルールでのみ有効です。

  • requestHeaders

    ModifyHeaderInfo[] 省略可

    Chrome 86 以降

    リクエストで変更するリクエスト ヘッダー。RuleActionType が "modifyHeaders" の場合にのみ有効です。

  • responseHeaders

    ModifyHeaderInfo[] 省略可

    Chrome 86 以降

    リクエストで変更するレスポンス ヘッダー。RuleActionType が "modifyHeaders" の場合にのみ有効です。

  • 実行するアクションのタイプ。

特定の RuleCondition が一致した場合に実行するアクションの種類を記述します。

「block」
ネットワーク リクエストをブロックします。

「redirect」
ネットワーク リクエストをリダイレクトします。

「allow」
ネットワーク リクエストを許可します。リクエストに一致する許可ルールがある場合、リクエストはインターセプトされません。

「upgradeScheme」
リクエストが http または ftp の場合、ネットワーク リクエスト URL のスキームを https にアップグレードします。

「modifyHeaders」
ネットワーク リクエストからリクエスト/レスポンス ヘッダーを変更します。

allowAllRequests
フレーム リクエスト自体を含む、フレーム階層内のすべてのリクエストを許可します。

  • domainType

    DomainType 省略可

    ネットワーク リクエストが、そのリクエストの送信元ドメインに対してファーストパーティかサードパーティかを指定します。省略した場合、すべてのリクエストが承認されます。

  • ドメイン

    string[] 省略可

    Chrome 101 以降で非推奨

    代わりに initiatorDomains を使用する

    このルールは、domains のリストから発信されたネットワーク リクエストにのみ一致します。

  • excludedDomains

    string[] 省略可

    Chrome 101 以降で非推奨

    代わりに excludedInitiatorDomains を使用する

    このルールは、excludedDomains のリストから送信されたネットワーク リクエストには一致しません。

  • excludedInitiatorDomains

    string[] 省略可

    Chrome 101 以降

    このルールは、excludedInitiatorDomains のリストから送信されたネットワーク リクエストには一致しません。リストが空の場合や省略されている場合は、除外されるドメインはありません。これは initiatorDomains よりも優先されます。

    注:

    • 「a.example.com」などのサブドメインも使用できます。
    • エントリは ASCII 文字のみで構成されている必要があります。
    • 国際化ドメイン名には Punycode エンコードを使用します。
    • これは、リクエスト URL ではなく、リクエスト イニシエータと照合されます。
    • リストに記載されているドメインのサブドメインも除外されます。
  • excludedRequestDomains

    string[] 省略可

    Chrome 101 以降

    ドメインが excludedRequestDomains のリストのいずれかに一致する場合、ルールはネットワーク リクエストと一致しません。リストが空の場合や省略されている場合は、除外されるドメインはありません。これは requestDomains よりも優先されます。

    注:

    • 「a.example.com」などのサブドメインも使用できます。
    • エントリは ASCII 文字のみで構成されている必要があります。
    • 国際化ドメイン名には Punycode エンコードを使用します。
    • リストに記載されているドメインのサブドメインも除外されます。
  • excludedRequestMethods

    RequestMethod[] 省略可

    Chrome 91 以降

    ルールが一致しないリクエスト メソッドのリスト。requestMethods と excludedRequestMethods のどちらか 1 つのみを指定します。どちらも指定されていない場合、すべてのリクエスト メソッドが一致します。

  • excludedResourceTypes

    ResourceType[] 省略可

    ルールが一致しないリソースタイプのリスト。resourceTypes と excludedResourceTypes のどちらか 1 つのみを指定します。どちらも指定されていない場合は、「main_frame」を除くすべてのリソースタイプがブロックされます。

  • excludedResponseHeaders

    HeaderInfo[] 省略可

    Chrome 128 以降

    リクエストがこのリストのレスポンス ヘッダー条件のいずれかに一致する場合、ルールは一致しません（指定されている場合）。excludedResponseHeaders と responseHeaders の両方が指定されている場合は、excludedResponseHeaders プロパティが優先されます。

  • excludedTabIds

    number[] 省略可

    Chrome 92 以降

    ルールが一致しない tabs.Tab.id のリスト。tabs.TAB_ID_NONE の ID は、タブから発生していないリクエストを除外します。セッション スコープのルールでのみサポートされます。

  • initiatorDomains

    string[] 省略可

    Chrome 101 以降

    このルールは、initiatorDomains のリストから発信されたネットワーク リクエストにのみ一致します。リストを省略すると、すべてのドメインからのリクエストにルールが適用されます。空のリストは使用できません。

    注:

    • 「a.example.com」などのサブドメインも使用できます。
    • エントリは ASCII 文字のみで構成されている必要があります。
    • 国際化ドメイン名には Punycode エンコードを使用します。
    • これは、リクエスト URL ではなく、リクエスト イニシエータと照合されます。
    • リストに登録されているドメインのサブドメインも一致します。
  • isUrlFilterCaseSensitive

    ブール値（省略可）

    urlFilter または regexFilter（指定された方）で大文字と小文字が区別されるかどうか。デフォルトは false です。

  • regexFilter

    文字列 省略可

    ネットワーク リクエストの URL と照合する正規表現。これは RE2 構文に従います。

    注: 指定できるのは urlFilter または regexFilter のいずれか 1 つのみです。

    注: regexFilter は ASCII 文字のみで構成する必要があります。これは、ホストが punycode 形式でエンコードされ（国際化ドメインの場合）、他の ASCII 以外の文字が utf-8 で URL エンコードされている URL と照合されます。

  • requestDomains

    string[] 省略可

    Chrome 101 以降

    このルールは、ドメインが requestDomains のリストのいずれかと一致する場合にのみ、ネットワーク リクエストと一致します。リストを省略すると、すべてのドメインからのリクエストにルールが適用されます。空のリストは使用できません。

    注:

    • 「a.example.com」などのサブドメインも使用できます。
    • エントリは ASCII 文字のみで構成されている必要があります。
    • 国際化ドメイン名には Punycode エンコードを使用します。
    • リストに登録されているドメインのサブドメインも一致します。
  • requestMethods

    RequestMethod[] 省略可

    Chrome 91 以降

    ルールが照合できる HTTP リクエスト メソッドのリスト。空のリストは使用できません。

    注: requestMethods ルール条件を指定すると、HTTP(s) 以外のリクエストも除外されますが、excludedRequestMethods を指定しても除外されません。

  • resourceTypes

    ResourceType[] 省略可

    ルールが一致するリソースタイプのリスト。空のリストは使用できません。

    注: これは allowAllRequests ルールで指定する必要があり、sub_frame リソースタイプと main_frame リソースタイプのみを含めることができます。

  • responseHeaders

    HeaderInfo[] 省略可

    Chrome 128 以降

    リクエストがこのリストのレスポンス ヘッダー条件のいずれかに一致する場合、ルールが一致します（指定されている場合）。

  • tabIds

    number[] 省略可

    Chrome 92 以降

    ルールが一致する必要がある tabs.Tab.id のリスト。tabs.TAB_ID_NONE の ID は、タブから発生していないリクエストと一致します。空のリストは使用できません。セッション スコープのルールでのみサポートされます。

  • urlFilter

    文字列 省略可

    ネットワーク リクエストの URL と照合されるパターン。サポートされているコンストラクト:

    「*」 : ワイルドカード: 任意の数の文字に一致します。

    '|' : 左/右アンカー: パターンのいずれかの端で使用すると、それぞれ URL の先頭/末尾を指定します。

    '||' : ドメイン名アンカー: パターンの先頭で使用すると、URL の（サブ）ドメインの開始を指定します。

    '^': 区切り文字: 文字、数字、_、-、.、% 以外のものに一致します。これは URL の末尾にも一致します。

    したがって、urlFilter は、（左/ドメイン名アンカー（省略可））+ パターン +（右アンカー（省略可））で構成されます。

    省略すると、すべての URL が照合されます。空の文字列は使用できません。

    ||* で始まるパターンは許可されていません。代わりに * を使用してください。

    注: 指定できるのは urlFilter または regexFilter のいずれか 1 つのみです。

    注: urlFilter は ASCII 文字のみで構成する必要があります。これは、ホストが punycode 形式でエンコードされ（国際化ドメインの場合）、他の ASCII 以外の文字が utf-8 で URL エンコードされている URL と照合されます。たとえば、リクエスト URL が http://abc.рф?q=ф の場合、urlFilter は URL http://abc.xn--p1ai/?q=%D1%84 と照合されます。

  • 有効

    ブール値

    ルールセットがデフォルトで有効かどうか。

  • id

    文字列

    ルールセットを一意に識別する空でない文字列。「_」で始まる ID は内部使用のために予約されています。

  • パス

    文字列

    拡張機能ディレクトリを基準とする JSON ルールセットのパス。

  • rulesMatchedInfo

    MatchedRuleInfo[]

    指定されたフィルタに一致するルール。

Chrome 89 以降
  • インクリメント

    数値

    タブのアクション数を増やす量。負の値はカウントを減らします。

  • tabId

    数値

    アクション数を更新するタブ。

Chrome 103 以降
  • matchedRules

    MatchedRule[]

    仮説リクエストに一致するルール（存在する場合）。

Chrome 103 以降
  • イニシエータ

    文字列 省略可

    仮想リクエストのイニシエータ URL（存在する場合）。

  • method

    RequestMethod 省略可

    仮説リクエストの標準 HTTP メソッド。HTTP リクエストのデフォルトは「get」で、HTTP 以外のリクエストでは無視されます。

  • responseHeaders

    オブジェクト 省略可

    Chrome 129 以降

    リクエストが送信される前にブロックまたはリダイレクトされない場合に、仮説的なレスポンスによって提供されるヘッダー。ヘッダー名を文字列値のリストにマッピングするオブジェクトとして表されます。指定されていない場合、仮説レスポンスは空のレスポンス ヘッダーを返します。これは、ヘッダーが存在しない場合に一致するルールと一致する可能性があります。例: {"content-type": ["text/html; charset=utf-8", "multipart/form-data"]}

  • tabId

    number 省略可

    仮説リクエストが行われるタブの ID。実際のタブ ID に対応している必要はありません。デフォルトは -1 で、リクエストがタブに関連付けられていないことを意味します。

  • 仮説リクエストのリソースタイプ。

  • URL

    文字列

    仮説リクエストの URL。

Chrome 87 以降

特定の正規表現がサポートされていない理由を説明します。

"syntaxError"
正規表現の構文が正しくないか、RE2 構文で使用できない機能が使用されています。

"memoryLimitExceeded"
正規表現がメモリの上限を超えています。

Chrome 87 以降
  • addRules

    Rule[] 省略可

    追加するルール。

  • removeRuleIds

    number[] 省略可

    削除するルールの ID。無効な ID は無視されます。

Chrome 87 以降
  • disableRulesetIds

    string[] 省略可

    無効にする必要がある静的 Ruleset に対応する ID のセット。

  • enableRulesetIds

    string[] 省略可

    有効にする必要がある静的 Ruleset に対応する ID のセット。

Chrome 111 以降
  • disableRuleIds

    number[] 省略可

    無効にする Ruleset のルールに対応する ID のセット。

  • enableRuleIds

    number[] 省略可

    有効にする Ruleset のルールに対応する ID のセット。

  • rulesetId

    文字列

    静的 Ruleset に対応する ID。

  • fragment

    文字列 省略可

    リクエストの新しいフラグメント。空にするか、'#' で始める必要があります。空にした場合は、既存のフラグメントがクリアされます。

  • ホスト

    文字列 省略可

    リクエストの新しいホスト。

  • パスワード

    文字列 省略可

    リクエストの新しいパスワード。

  • パス

    文字列 省略可

    リクエストの新しいパス。空の場合、既存のパスはクリアされます。

  • ポート

    文字列 省略可

    リクエストの新しいポート。空の場合、既存のポートはクリアされます。

  • クエリ

    文字列 省略可

    リクエストの新しいクエリ。空にするか、「?」で始める必要があります。空にした場合は、既存のクエリがクリアされます。

  • queryTransform

    QueryTransform （省略可）

    クエリの Key-Value ペアを追加、削除、または置換します。

  • スキーム

    文字列 省略可

    リクエストの新しいスキーム。使用できる値は、「http」、「https」、「ftp」、「chrome-extension」です。

  • ユーザー名

    文字列 省略可

    リクエストの新しいユーザー名。

拡張機能によって追加された動的ルールのルールセット ID。

"_dynamic"

MAX_GETMATCHEDRULES_CALLS_PER_INTERVAL getMatchedRules 呼び出しを行うことができる時間間隔（分単位）。追加の呼び出しはすぐに失敗し、runtime.lastError を設定します。注: ユーザー操作に関連付けられた getMatchedRules 呼び出しは割り当ての対象外です。

10

Chrome 89 以降

有効な静的ルールセット全体で拡張機能に保証される静的ルールの最小数。この上限を超えるルールは、グローバル静的ルールの上限にカウントされます。

30000

GETMATCHEDRULES_QUOTA_INTERVAL の期間内に getMatchedRules を呼び出すことができる回数。

20

拡張機能が追加できる動的ルールの最大数。

30000

Chrome 94 以降

拡張機能が一度に有効にできる静的 Rulesets の最大数。

50

拡張機能が追加できる正規表現ルールの最大数。この上限は、動的ルールのセットとルール リソース ファイルで指定されたルールのセットに対して個別に評価されます。

1000

Chrome 120 以降

拡張機能が追加できるセッション スコープ ルールの最大数。

5000

拡張機能が "rule_resources" マニフェスト キーの一部として指定できる静的 Rulesets の最大数。

100

Chrome 120 以降

拡張機能が追加できる「安全でない」動的ルールの最大数。

5000

Chrome 120 以降

拡張機能が追加できる「安全でない」セッション スコープ ルールの最大数。

5000

Chrome 90 以降

拡張機能によって追加されたセッション スコープのルールのルールセット ID。

"_session"

Chrome 89 以降 
chrome.declarativeNetRequest.getAvailableStaticRuleCount(): Promise<number>

拡張機能が有効にできる静的ルールの数（グローバル静的ルールの上限に達するまで）を返します。

  • Promise<number>

    Chrome 91 以降
Chrome 111 以降 
chrome.declarativeNetRequest.getDisabledRuleIds(
  options: GetDisabledRuleIdsOptions,
): Promise<number[]>

指定された Ruleset で現在無効になっている静的ルールのリストを返します。

  • Promise<number[]>

chrome.declarativeNetRequest.getDynamicRules(
  filter?: GetRulesFilter,
): Promise<Rule[]>

拡張機能の現在の動的ルールのセットを返します。発信者は、filter を指定して、取得したルールのリストをフィルタできます。

  • フィルタ

    GetRulesFilter 省略可

    Chrome 111 以降

    取得したルールのリストをフィルタするオブジェクト。

  • Promise<Rule[]>

    Chrome 91 以降 
chrome.declarativeNetRequest.getEnabledRulesets(): Promise<string[]>

現在有効になっている静的ルールセットの ID を返します。

  • Promise<string[]>

    Chrome 91 以降 
chrome.declarativeNetRequest.getMatchedRules(
  filter?: MatchedRulesFilter,
): Promise<RulesMatchedDetails>

拡張機能に一致するすべてのルールを返します。呼び出し元は、必要に応じて filter を指定して、一致するルールのリストをフィルタできます。このメソッドは、"declarativeNetRequestFeedback" 権限を持つ拡張機能、または filter で指定された tabId に対して "activeTab" 権限が付与されている拡張機能でのみ使用できます。注: 5 分以上前に一致した、アクティブなドキュメントに関連付けられていないルールは返されません。

  • フィルタ

    MatchedRulesFilter 省略可

    一致するルールのリストをフィルタするオブジェクト。

Chrome 90 以降 
chrome.declarativeNetRequest.getSessionRules(
  filter?: GetRulesFilter,
): Promise<Rule[]>

拡張機能の現在のセッション スコープ ルールのセットを返します。発信者は、filter を指定して、取得したルールのリストをフィルタできます。

  • フィルタ

    GetRulesFilter 省略可

    Chrome 111 以降

    取得したルールのリストをフィルタするオブジェクト。

  • Promise<Rule[]>

    Chrome 91 以降
Chrome 87 以降 
chrome.declarativeNetRequest.isRegexSupported(
  regexOptions: RegexOptions,
): Promise<IsRegexSupportedResult>

指定された正規表現が regexFilter ルール条件としてサポートされるかどうかを確認します。

  • regexOptions

    RegexOptions

    チェックする正規表現。

Chrome 88 以降 
chrome.declarativeNetRequest.setExtensionActionOptions(
  options: ExtensionActionOptions,
): Promise<void>

タブのアクション数を拡張機能アクションのバッジ テキストとして表示するかどうかを設定し、アクション数を増やす方法を提供します。

  • Promise<void>

    Chrome 91 以降
Chrome 103 以降 
chrome.declarativeNetRequest.testMatchOutcome(
  request: TestMatchRequestDetails,
): Promise<TestMatchOutcomeResult>

拡張機能の declarativeNetRequest ルールのいずれかが仮説リクエストと一致するかどうかを確認します。注: この機能は、拡張機能の開発時にのみ使用することを想定しているため、パッケージ化されていない拡張機能でのみ使用できます。

chrome.declarativeNetRequest.updateDynamicRules(
  options: UpdateRuleOptions,
): Promise<void>

拡張機能の現在の動的ルールのセットを変更します。最初に options.removeRuleIds にリストされている ID のルールが削除され、次に options.addRules で指定されたルールが追加されます。注:

  • この更新は単一のアトミック オペレーションとして行われます。指定されたすべてのルールが追加および削除されるか、エラーが返されます。
  • これらのルールは、ブラウザ セッションと拡張機能のアップデートにわたって保持されます。
  • 拡張機能パッケージの一部として指定された静的ルールは、この関数を使用して削除できません。
  • MAX_NUMBER_OF_DYNAMIC_RULES は、拡張機能が追加できる動的ルールの最大数です。安全でないルールの数は MAX_NUMBER_OF_UNSAFE_DYNAMIC_RULES を超えてはなりません。

  • Promise<void>

    Chrome 91 以降 
chrome.declarativeNetRequest.updateEnabledRulesets(
  options: UpdateRulesetOptions,
): Promise<void>

拡張機能で有効になっている静的ルールセットのセットを更新します。最初に options.disableRulesetIds にリストされている ID のルールセットが削除され、次に options.enableRulesetIds にリストされているルールセットが追加されます。有効な静的ルールセットのセットはセッション間で保持されますが、拡張機能のアップデート間では保持されません。つまり、rule_resources マニフェスト キーによって、各拡張機能のアップデートで有効な静的ルールセットのセットが決まります。

  • Promise<void>

    Chrome 91 以降
Chrome 90 以降 
chrome.declarativeNetRequest.updateSessionRules(
  options: UpdateRuleOptions,
): Promise<void>

拡張機能の現在のセッション スコープ ルールのセットを変更します。最初に options.removeRuleIds にリストされている ID のルールが削除され、次に options.addRules で指定されたルールが追加されます。注:

  • この更新は単一のアトミック オペレーションとして行われます。指定されたすべてのルールが追加および削除されるか、エラーが返されます。
  • これらのルールはセッション間で保持されず、メモリにバックアップされます。
  • MAX_NUMBER_OF_SESSION_RULES は、拡張機能が追加できるセッション ルールの最大数です。

  • Promise<void>

    Chrome 91 以降
Chrome 111 以降 
chrome.declarativeNetRequest.updateStaticRules(
  options: UpdateStaticRulesOptions,
): Promise<void>

Ruleset 内の個々の静的ルールを無効または有効にします。無効になっている Ruleset に属するルールの変更は、次回有効になったときに反映されます。

  • Promise<void>

chrome.declarativeNetRequest.onRuleMatchedDebug.addListener(
  callback: function,
)

ルールがリクエストと一致したときに呼び出されます。これはデバッグ目的でのみ使用されることを想定しているため、"declarativeNetRequestFeedback" 権限を持つパッケージ化されていない拡張機能でのみ使用できます。