> For the complete documentation index, see [llms.txt](https://docs.keeper.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.keeper.io/keeperpam/jp/endpoint-privilege-manager/policies/policy-reference/wildcards.md).

# ワイルドカード

<figure><img src="/files/ESz57QoSoAPMsTl5Hrnd" alt=""><figcaption></figcaption></figure>

**対象:** IT管理者。アプリやパスを1件ずつ書かずに、ポリシーフィルターでまとめて指定するときの参考にしてください。

***

## ワイルドカード <a href="#wildcards-overview" id="wildcards-overview"></a>

ワイルドカードは、1つのパターンで複数の名前やパスに一致させるための記法です。挙動はフィルターの種類によって異なり、設定するポリシータイプよりも、どのフィルターで使うかの区別が重要です。

### アプリケーションフィルター <a href="#application-filters" id="application-filters"></a>

アプリケーションフィルターでは、パス内にワイルドカードを使えます。`*` は任意の文字列に一致します (正規表現の `.*` に相当)。まずパス変数が解決され、そのあとパターンが照合されます。Windowsでは大文字と小文字を区別しません。Linux/macOSでは区別します。アプリケーションフィルターは、実行ファイルを対象とするポリシータイプすべてで使われます。対象には、特権昇格、ファイルアクセス、コマンドライン、最小権限、カスタムに加え、エージェンティックAI、エージェンティックアクセス、エージェンティック特権昇格などのエージェンティックAI系ポリシーも含まれます。そのため、`{programfiles}\*\*.exe` のようなパターンは、ポリシーの種類にかかわらず同じルールで評価されます。

### フォルダフィルター <a href="#folder-filters" id="folder-filters"></a>

フォルダフィルター (`Extension.Folders` フィールド。主にファイルアクセスポリシーで使用) ではパス変数を使えますが、一致判定は前方一致のみです。フォルダの値を解決したうえで、評価対象のフルパスがそのフォルダで始まるかどうかを確認します。フォルダパス内のワイルドカードは使えません。`{downloads}\*` と書いても `*` はワイルドカードではなく、文字の `*` として扱われます。前方一致のため、ワイルドカードを付けなくても、そのフォルダとすべてのサブフォルダが対象になります。

### コマンドライン引数フィルター <a href="#command-line-argumentfilters" id="command-line-argumentfilters"></a>

**コマンドライン引数フィルター** (コマンドラインポリシー、およびコマンドラインのスコープ指定を行う特権昇格ポリシーで使用) では、コマンドおよび引数のパターンにワイルドカードを使えます。

### 重要な注意点 <a href="#one-important-caveat" id="one-important-caveat"></a>

Windowsでワイルドカードを使ったファイルアクセス **DENY**ポリシーの場合、`{systemroot}`、`{system32}`、`{programfiles}`、`{programfilesx86}` などの保護パス上の実行ファイルは、広範なワイルドカードが重要なOSバイナリを誤ってブロックしないよう、一致対象から自動的に除外されます。この除外は評価時に適用され、ワイルドカードによる拒否にのみ有効です。パスを明示した拒否は、これまでどおり一致します。

## アプリケーションフィルターのワイルドカード <a href="#application-filter-wildcards" id="application-filter-wildcards"></a>

**サポート対象:**

* **パス内のワイルドカード:** `{programfiles}\*\*.exe` は、Program Files以下の任意のサブフォルダにある任意の `.exe` に一致
* **パス変数:** `{userprofile}\Documents\*.exe`、`{downloads}\*.pdf` など
* **併用:** `{userprofile}\*\*.exe` は、ユーザープロファイル以下の任意のサブフォルダにある任意の `.exe` に一致

**動作:** パス内の `*` は「任意の文字列」として扱われます。パスは正規化され、変数が解決されたあとにパターンが照合されます。Windowsでは大文字と小文字を区別せず、Linux/macOSでは区別します。

**例:**

* `*.exe` は、フィルターが評価される範囲で、名前が `.exe` で終わるファイルすべてに一致
* `{desktop}\*.exe` は、そのユーザーのデスクトップ上の `.exe` すべてに一致 (`{desktop}` はユーザーごとに解決)
* `{programfiles}\*\*.exe` は、Program Files以下の任意のサブフォルダにある `.exe` すべてに一致

## 変数とワイルドカードの組み合わせ例 <a href="#combined-variable-wildcard-examples" id="combined-variable-wildcard-examples"></a>

パス変数と `*` を1つ以上**組み合わせる**と、1本のパターンでたくさんのパス (アプリのバージョン違いやインストール先の違いなど) にまとめて一致させられます。先に変数が解決され、各 `*` はその位置のパス要素に対する任意の文字列に一致します。

| パターン                                                                        | 一致するパス                                                                                             |
| --------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- |
| `{userprofile}\AppData\Local\GitHubDesktop\*\resources\app\git\cmd\git.exe` | ユーザーのローカルAppData下の、バージョン用フォルダ名が可変なGitHub Desktopに同梱されているGit (例: `app-3.2.1`、`app-3.3.0` などのフォルダ配下) |
| `{localappdata}\*\*\*.exe`                                                  | ユーザーのローカルAppDataから見て3階層下にある任意の `.exe` (アプリごとのフォルダやバージョン付きフォルダをまとめてカバー)                             |
| `{programfiles}\*\*\*.exe`                                                  | Program Files配下の任意のサブフォルダ内の任意の `.exe` (例: `C:\Program Files\Vendor\Product\bin\app.exe`)           |
| `{userprofile}\Documents\*\*.pdf`                                           | ユーザーのドキュメント直下の、さらに1つ下のフォルダにある任意のPDF                                                                |
| `{appdata}\*\*.exe`                                                         | ローミングAppData直下の、さらに1つ下のフォルダにある任意の `.exe`                                                           |

**組み合わせる理由:** インストール先にはバージョン名やビルド用のフォルダ (例: `GitHubDesktop\app-3.2.1\...`) が入ることがよくあります。その部分を `*` にすると、アプリを更新してフォルダ名が変わってもルールを書き換えずに、1つのポリシーですべてのバージョンに合わせられます。パターンに使える変数の一覧は、[パス変数と保護パス](/keeperpam/jp/endpoint-privilege-manager/policies/policy-reference/path-variables.md)をご参照ください。

## フォルダフィルター (Extension.Folders) — 前方一致のみ <a href="#folder-filter-extensionfolders-prefix-matching-only" id="folder-filter-extensionfolders-prefix-matching-only"></a>

ポリシーで**Extension.Folders** (またはフォルダ形式のフィルター) を使う場合、製品は**前方一致**だけでマッチを判定します。

* フォルダの値には**パス変数** (例: `{downloads}`、`{userprofile}`) を使えます。
* 評価対象ファイルの**フルパス**が、解決後のフォルダパスで**始まるか**だけを確認します。
* 始まれば一致とみなし、そのフォルダ以下のサブフォルダ内のファイルもすべて含みます。
* **フォルダパス内のワイルドカードは使えません。** 例えば `{downloads}\*` は「Downloadsの下の任意のサブフォルダ」という意味にはなりません。`*` はワイルドカードではなく、普通の文字として扱われます。

#### 例

* フォルダ `{downloads}` → `C:\Users\Jane\Downloads\file.exe` と `C:\Users\Jane\Downloads\subdir\file.exe` の両方に一致
* フォルダ `{userprofile}` → そのユーザーのプロファイル配下のファイルすべてに一致
* フォルダ `{downloads}\*` → **誤り**。Downloadsとその下のフォルダをまとめて含めたいときは `{downloads}` だけを指定します

## ApplicationCheckとExtension.Foldersの併用 <a href="#combining-applicationcheck-and-extensionfolders" id="combining-applicationcheck-and-extensionfolders"></a>

{% hint style="info" icon="comment-question" %}

#### macOS保護パスとワイルドカードのスコープ

[macOS: 保護パスの設計意図](/keeperpam/jp/endpoint-privilege-manager/deployment/deploy-with-macos/protected-path-design-intent.md)については、[macOSでのデプロイ](/keeperpam/jp/endpoint-privilege-manager/deployment/deploy-with-macos.md)をご参照ください。
{% endhint %}

**ApplicationCheck**に**ファイル名のパターンだけ** (例: `*.exe`) を書き、**Extension.Folders**も設定している場合、前処理の段階で以下のように結び付けられます。

* 結果として、`{desktop}\*.exe` や `{downloads}\*.pdf` のような「フォルダ＋ファイル名」の完全なパスパターンになります。
* そのうえで、通常のアプリ/パス照合 (パス内のワイルドカード込み) が行われます。

このため、「デスクトップにある実行ファイルすべて」は、ApplicationCheckに `*.exe` (または同種のパターン) を、Extension.Foldersに `{desktop}` を指定すれば表現できます。パスを1本ずつ列挙する必要はありません。

## Linux/macOS: 拡張子のない実行ファイル <a href="#linuxmacos-executables-without-extensions" id="linuxmacos-executables-without-extensions"></a>

LinuxやmacOSでは、拡張子のない実行ファイルが多くあります。以下のような書き方が使えます。

* フォルダ内の任意のファイルに合わせる (例: `*` と Extension.Foldersを組み合わせる)、または
* ApplicationCheckでよくある拡張子を列挙する (Linuxの例: `.sh`、`.bin`、`.run`、macOSの例: `.app`、`.command`) とともにExtension.Foldersを使う。

フォルダ側のルールはあくまで前方一致のみです。アプリケーション側のパターンでは、引き続きパス中の `*` が使えます。

{% hint style="info" icon="comment-question" %}

#### macOS保護パスとワイルドカードのスコープ

[macOS: 保護パスの設計意図](/keeperpam/jp/endpoint-privilege-manager/deployment/deploy-with-macos/protected-path-design-intent.md)については、[macOSでのデプロイ](/keeperpam/jp/endpoint-privilege-manager/deployment/deploy-with-macos.md)をご参照ください。
{% endhint %}

## 避けるべきこと <a href="#what-to-avoid" id="what-to-avoid"></a>

* **フォルダパスに `*` をそのまま入れる:** 例として `Extension.Folders: ["{downloads}\\*"]` があります。ここでの `*` はワイルドカードではなく文字として扱われます。Downloads以下すべてを含めたいときは `{downloads}` だけを指定します。
* **フォルダ文字列でワイルドカードが効くと思わないこと:** 解決後のフォルダパスに対しては、前方一致しか行われません。
* **Linux/macOSでの大文字と小文字:** パターンは大文字と小文字を区別します。実際のパス・拡張子の表記と揃えてください。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.keeper.io/keeperpam/jp/endpoint-privilege-manager/policies/policy-reference/wildcards.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
