URLマッチパターン

Last Updated 6月 2, 2026

概要

マッチパターンを使用すると、ブラウザ拡張機能を適用するURLのグループを指定できます。 各マッチパターンは、特定のURLセットに一致します。

マッチパターン構造

すべてのマッチパターンは、文字列として指定され、スキームホストパスの3つの部分で構成されます: スキームとホストは、://で区切られています。

<スキーム>://<ホスト><パス>

スキーム

スキームは、httpまたはhttpsのいずれかになります。

ホスト

ホストコンポーネントは、以下の3つの形式のいずれかを取ります:

  • * — 任意のホストにマッチします
  • *. その後にホスト名の一部が続きます。— 指定されたホストとそのサブドメインのいずれかに一致します。
  • ワイルドカードのない完全なホスト名 — 指定されたホストのみに一致します。

ホストには、ポート番号を含めてはいけません。 ワイルドカードは、先頭にのみ配置できます。

パス

パスは、/で始まる必要があります。 その後、*ワイルドカードと、URLパスまたはクエリ文字列で許可されている文字の任意の組み合わせを含めることができます。 ホストとは異なり、パスには*ワイルドカードが中央または末尾に含まれることができ、ワイルドカードは複数回表示される場合があります。

パスは、URLパスとURLクエリ文字列(クエリ文字列が存在する場合はそれらの間のを含む)に対して照合されます。

例えば、パスがfoo.barで終わる任意のドメインのURLを一致させるには、['*:*/*foo.bar', '*:*/*foo.bar?*']のようなマッチパターンの配列を使用します。 ?*は、URLパスではなくクエリ文字列に終了*をアンカーします。

  • URLフラグメント識別子と、それらに先行する#は、パスの一部とはみなされません。
  • パスパターン文字列には、ポート番号を含めるべきではありません。 ポートの追加(例:http:localhost:1234/*)は、マッチパターンが無視される原因となります。 ただし、http:localhost:1234http:localhost/*に一致します。

パターン 一致する例 一致しない例

https://*/path

パスが「パス」であるホストのHTTPS URLを一致させます。

https://mozilla.org/path

https://a.mozilla.org/path

https://something.com/path

http://mozilla.org/path
(マッチしないスキーム)https://mozilla.org/path/
(マッチしないパス)https://mozilla.org/a
(一致しないパス)https:mozilla.org/
(一致しないパス)https:mozilla.org/path?foo = 1
(URLクエリ文字列によりマッチしないパス)

https://*/path/

パスが「パス/」であり、URLクエリ文字列がないホストのHTTPS URLを一致させます。

https://mozilla.org/path/

https://a.mozilla.org/path/

https://something.com/path/

http://mozilla.org/path/
(一致しないスキーム)https://mozilla.org/path
(マッチしないパス)https://mozilla.org/a
(一致しないパス)https:mozilla.org/
(一致しないパス)https:mozilla.org/path/?foo = 1
(URLクエリ文字列によりマッチしないパス)

https://mozilla.org/*

URLパスとURLクエリ文字列のある「mozilla.org」でのみ、HTTPS URLを一致させます。

https://mozilla.org/

https://mozilla.org/path

https://mozilla.org/another

https://mozilla.org/path/to/doc

https://mozilla.org/path/to/doc?foo=1

http://mozilla.org/path
(マッチしないスキーム)https://mozilla.com/path
(マッチしないホスト)

https://mozilla.org/a/b/c/

このURL、またはURLフラグメントのあるこのURLのみを一致させます。

https://mozilla.org/a/b/c/

https://mozilla.org/a/b/c/#section1

その他。

https://mozilla.org/*/b/*/

パスが、真ん中のどこかにコンポーネント「b」を含む、「mozilla.org」でホストされているHTTPS URLを一致させます。 文字列が/で終わる場合、クエリ文字列を持つURLと一致します。

https://mozilla.org/a/b/c/

https://mozilla.org/d/b/f/

https://mozilla.org/a/b/c/d/

https://mozilla.org/a/b/c/d/#section1

https://mozilla.org/a/b/c/d/?foo=/

https://mozilla.org/a?foo=21314&bar=/b/&extra=c/

https://mozilla.org/b/*/
(一致しないパス)https://mozilla.org/a/b/
(一致しないパス)https://mozilla.org/a/a/b/c/d/?foo=bar
(URLクエリ文字列により一致しないパス)

無効なマッチパターン

  • resource:path/ — サポートされていないスキーム。
  • https:mozilla.org — パスなし。
  • https://mozilla.*.org/*は、ホストの開始時に記入する必要があります。
  • https://*zilla.org/ — ホストの*は、唯一の文字であるか、その後に.が続く必要があります。
  • http*:mozilla.org/ — スキーム内の*は、唯一の文字である必要があります。
  • https:mozilla.org:80/ — ホストには番号を含めることはできません。
  • https:* — 空のパス:これはhttps:*/*にする必要があります。

URLマッチパターンとRegex

WalkMeでは、URLマッチパターンまたはRegexを使用して拡張機能を設定できます。 比較方法はこちらです。

URLマッチパターン

URLマッチパターンは、ブラウザ拡張機能向けに特別に構築されます。 ワイルドカード文字を含むシンプルな構文を使用して、コンテンツスクリプトやバックグラウンドスクリプトなど、拡張機能が適用されるURLを定義します。

Regex

Regex(正規表現)は、文字列内でパターンをマッチングするための強力な汎用ツールです。 文字とメタ文字を組み合わせてテキストを検索、抽出、置換できます。 テキスト処理、データ検証、プログラミングで広く使用されています。

比較

URLマッチパターンは、ブラウザ拡張機能が適用されるURLを定義するために、ウェブブラウザ用に作成および最適化されています。
Regexは、文字とメタ文字を組み合わせて文字列でパターンマッチングを行う強力なツールです。

URLマッチパターンは、ブラウザ拡張機能がどのウェブページで動作するかを指定するために使用されます。
Regexは、テキスト処理、データ検証、検索と置換操作など、幅広いアプリケーションで使用できます。

構文URLマッチパターンでは、*などのワイルドカード文字を使用して、URLパターンを指定します。 Regexは、.(任意の文字)、*(ゼロ以上の発生)、 + (1つ以上の発生)などのメタキャラクタを使用します。

URLマッチパターンの例:https://example.com/*は、https://example.com/で始まる任意のURLにマッチします。 Regex:^(http|https)://example\.com(?:/[^/?#]+)*$は、example.comに属するURLにマッチします。

長所と短所

URLマッチパターン — メリット

  • URLマッチングにおいてシンプルかつ直感的
  • 複雑なregexよりも読みやすく
  • ブラウザ拡張機能の推奨標準

URLマッチパターン — デメリット

  • URLマッチングのみに限定されます。
  • 汎用パターンマッチングには適していません。
  • ブラウザの拡張機能向けに特別に調整されました。

Regex — プロ

  • 幅広いパターンマッチングタスクに汎用性が高い
  • 非常に正確なマッチングのための豊富な構文
  • URL構造を超えた複雑なパターンを扱うことができます。

Regex — cons

  • 複雑な表現は、困難であり、エラーが発生しやすい場合があります。
  • 非常に複雑なパターンでは、パフォーマンスの問題を引き起こす可能性があります。
  • 読み取りと維持が困難

WalkMe推奨事項

WalkMeは、可能な限り拡張機能設定にURLマッチパターンを使用することをお勧めします。 エッジケースの場合、Regexは最後の手段となります。 URLマッチパターンにより、シームレスな拡張機能が保証され、裏側のルール検証が最小限に抑えられ、全体的により良いエクスペリエンスが提供されます。

URLマッチパターンは、管理拡張機能設定の新しいシステム設定のデフォルトです。

この記事は役に立ちましたか?

ご意見ありがとうございます!

Be part of something bigger.

Engage with peers, ask questions, share ideas

Ask the Community
×