> ## 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は、Guardianが適用するルールのセットです。StarfortにはPIIとTopicの2つのポリシータイプがあります。

**Guard Policy**は、[Guardian](/ja/v1.2/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`** — 明示的に許可します（例: テストデータを許可リストに登録）。これにより、より広範なルールに捕捉されないようにします。

<Note>
  Starfortに標準で付属するPIIポリシーは、韓国の電話番号、住民登録番号、パスポート/運転免許/通関ID、銀行口座、カード、メール、車両ナンバープレートを対象としており、加えて一般的なテストパターン向けの`PASSING`ルールも含まれています。[カスタマイズしたPIIポリシーの追加](/ja/v1.2/admin/how-to/add-pii-policy)を参照してください。
</Note>

## Topicポリシー

定義された**トピック**に照らしてコンテンツを分類し、その分類結果に基づいて処理します。各トピックは`safe`、`controversial`、`unsafe`のコンテンツを定義し、その分類は直接アクションにマッピングされます。

* **`safe` → PASS** — そのまま通過します。
* **`controversial` → CHECK** — レビューが必要としてフラグ付けされます。Desktop AgentおよびProxy Serverでは、**CHECKはPASSとして適用されます**（コンテンツはブロックもマスクもされずに通過し、トレースに記録されるのみ）。API呼び出し元には`CHECK`がそのまま返されます。
* **`unsafe` → BLOCK** — リクエストが停止されます。

したがってTopicポリシーは、PIIのPASS / MASK / BLOCKとは異なり、**PASS / CHECK / BLOCK**のアクションセットを使用します。デフォルトのTopicポリシーに含まれるトピックの例として、武器、違法行為、ジェイルブレイク/テストモード、自傷、システムプロンプトの露出などがあります。[カスタマイズしたTopicポリシーの追加](/ja/v1.2/admin/how-to/add-topic-policy)を参照してください。

## ポリシーがGuardianに渡される仕組み

ポリシーは、**Policy Type → 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.2/admin/how-to/version-and-apply-policy)を参照してください。

## 関連項目

<CardGroup cols={2}>
  <Card title="アクション: PASS / MASK / BLOCK" icon="traffic-light" href="/ja/v1.2/concepts/actions-pass-mask-block" />

  <Card title="Guard Policyの作成" icon="pen-to-square" href="/ja/v1.2/admin/author-guard-policy" />
</CardGroup>