> ## Documentation Index
> Fetch the complete documentation index at: https://docs.starfort.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Guard Policy
> Guard Policy は Starfort Guardian が各リクエストに適用するルール群です。PII と Topic の 2 種類があり、バージョニングとプリセットを持ちます (Starfort v1.4 版)
**Guard Policy** は、[Guardian](/ja/v1.4/concepts/guardian) が適用するルールのセットです。ポリシーはプロジェクト内で作成され、**バージョン管理**され、process type（`input` / `output`）ごとに Guardian へ**割り当て**られます。
Starfort の **Guard Policy Type Catalog** は固定の集合 — `PII` と `TOPIC` — です。System Guardian は評価できるサブセットを宣言し、Project Guardian はそのサブセットを継承します。各ポリシーは **Policy Name** を持ち、これは**プロジェクト内で一意**です。この名前は Guardian の出力や Opticon のトレースタグで使われる識別子であるため、ポリシーの名前を変更することは履歴を書き換えるのではなく、新たなアイデンティティを開始することを意味します。
## PII ポリシー
個人データや機微なデータを検出し、各一致に対する処理を決定します。PII ポリシーは 3 種類のルールで構成されます。
| ルールの種類 | 一致方法 | 一般的な用途 |
| ----------- | ---------------------- | ------------------------------ |
| **NER** | 学習済みエンティティモデル（氏名、住所、…） | 自然言語のエンティティ |
| **Regex** | 正規表現 | 構造化された ID（電話番号、住民登録番号、カード、メール） |
| **Keyword** | 完全一致する単語/フレーズ | 拒否リストに登録された用語 |
各ルールには、そのアクションを設定する **policy\_type** が付与されます。
* **`MASKING`** — 一致箇所をマスクワードトークンに置き換えます（例: `PHONE_NUMBER` → `[PHONE_NUMBER_1]`）。
* **`BLOCKING`** — 一致した場合、リクエスト全体をブロックします。
* **`PASSING`** — 明示的に許可します（例: テストデータを許可リストに登録）。これにより、より広範なルールに捕捉されないようにします。
Starfort に標準で付属する PII ポリシーは、韓国の電話番号、住民登録番号、パスポート/運転免許/通関 ID、銀行口座、カード、メール、車両ナンバープレートを対象としており、加えて一般的なテストパターン向けの `PASSING` ルールも含まれています。[カスタマイズした PII ポリシーの追加](/ja/v1.4/admin/how-to/add-pii-policy)を参照してください。
## Topic ポリシー
定義された**トピック**に照らしてコンテンツを分類し、その分類結果に基づいて処理します。各トピックは `safe` と `unsafe` のコンテンツを定義し、その分類は直接アクションにマッピングされます。
* **`safe` → PASS** — そのまま通過します。
* **`unsafe` → BLOCK** — リクエストが停止されます。
したがって Topic の判定は **2-state**（PASS / BLOCK）であり、PII の PASS / MASK / BLOCK とは異なります（トピックがマスクされることはなく、許可されるか停止されるかのいずれかです）。デフォルトの Topic ポリシーに含まれるトピックの例として、武器、違法行為、ジェイルブレイク/テストモード、自傷、システムプロンプトの露出などがあります。[カスタマイズした Topic ポリシーの追加](/ja/v1.4/admin/how-to/add-topic-policy)を参照してください。
## ポリシーが Guardian に渡される仕組み
ポリシーは、**ポリシー種別 → Policy Name** という 2 階層の構造で Guardian に渡されます。同じタイプの複数のポリシーは名前によって区別されたまま保持されます（そのまま渡され、決してマージされません）。そのため、1 つの `input` スロットは、例えば 2 つの異なる PII ポリシーと 1 つの Topic ポリシーを同時に保持でき、それぞれが独立して評価されます。
## バージョン管理と割り当て
Guard Policy は**セマンティックバージョニング**を使用し、Project Guardian は特定のバージョンを \*\*Pin（固定）\*\*します。
* ポリシーのルールを編集すると、**新しいバージョンが作成されます**（例: `v0.1.0` → `v0.1.1`）。
* Project Guardian は、明示的に再 Pin するまで、**Pin** されたバージョンを使い続けます — **保存 ≠ 適用**。新しいバージョンを公開しても、Pin が自動的に変わることはありません。
* 1 つの process type スロットには、複数のポリシーを保持できます（例: `input` に PII ポリシー**と** Topic ポリシーの両方）。
これは「変更が反映されない」という問題の最も一般的な原因です。必ずバージョンを再適用（再 Pin）してください。[ポリシー更新のバージョン管理と適用](/ja/v1.4/admin/how-to/version-and-apply-policy)を参照してください。
## ポリシーアーティファクト — モジュールごとのプロジェクトポリシー
v1.4 からは、プロジェクトレベルのポリシーのデプロイ単位を総称して**ポリシーアーティファクト**と呼びます。Guardian のポリシーアーティファクトが **Guard Policy** であり、[Stratum](/ja/v1.4/concepts/stratum) のポリシーアーティファクトが **Rule Package** です。両者は対等なプロジェクトポリシーであり、バージョン管理（セマンティックバージョニング）、保存 ≠ 適用、Module Instance 単位の Pin という同一の管理規律に従います。2 つのモジュールのポリシーが互いに共有されることはなく、Guard Policy は v1.4 でも従来のままです。Rule Package と Taxonomy の管理については、[Taxonomy と Rule Package の管理](/ja/v1.4/admin/stratum-policy)を参照してください。
## 関連項目