> ## 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.

# Guardian

> Guardianは、コンテンツをGuard Policyに照らして検査し、PASS、MASK、またはBLOCKの判断を返すエンジンです。

**Guardian**は、AIリクエストの経路上に配置される解析エンジンです。コンテンツを受け取り、それに割り当てられた**Guard Policy**に照らして評価し、その判断の根拠となる検出項目とともに[アクション](/ja/v1.2/concepts/actions-pass-mask-block) — `PASS`、`MASK`、または`BLOCK` — を返します。

## System GuardianとProject Guardian

<CardGroup cols={2}>
  <Card title="System Guardian" icon="server">
    プラットフォームに登録されたマスター定義です（例: `VLM-OCR`プリセット）。Guardianがサポートする機能 — Input Type、Policy Type、process type、運用上限、モデル構成 — を宣言します。
  </Card>

  <Card title="Project Guardian" icon="cube">
    **Project**内に作成するコピーです。運用設定（どのGuard Policyが割り当てられているか、モデル構成のオーバーライド、有効なカテゴリ、独自のライフサイクル）を保持します。API キーやDesktop Agentが呼び出すのはこちらです。
  </Card>
</CardGroup>

Account Adminがプロジェクトで[Guardianを登録](/ja/v1.2/admin/register-guardian)する際には、System Guardianプリセットを選択します。すると、プロジェクトには設定可能な独自のProject Guardianが作成されます。1つのProjectは**複数のProject Guardian**を実行できます — 例えばサービスごとに1つ、あるいはポリシーバンドルごとに1つというように — そして、それぞれが独立した[Kill Switch](/ja/v1.2/concepts/organization-hierarchy)の切り替え単位となります。

### 仕様は凍結され、設定はお客様のもの

「なぜ変更が反映されないのか？」という混乱の大半は、2つのルールで説明できます。

* **System Guardianの仕様は、登録後は不変です。** いったん登録されると、変更できるのは名前、説明、Endpoint URL、可視性（スコープ＋Enabled）のみです。機能仕様 — サポートされるInput Type、Policy Type、process type、上限、モデル構成キー — は凍結されます。
* **Project Guardianは作成時にその仕様をコピーし、独立して保持します。** 後からSystem Guardianを編集しても、その変更はさかのぼって**伝播しません**。参照され続けるのはライブのEndpoint URLのみです。互換性のあるPolicy Typeの集合（*検査できる*対象）はSystem Guardianによって固定されたままですが、その範囲内の運用値（割り当てられたGuard Policy、テキスト／ファイルの上限、有効なカテゴリ、モデル構成）はお客様が自由にチューニングできます。

## Input Type

Guardianは、検査できるコンテンツの種類を宣言します。Guardianごとにそのサブセットを有効化します。

| Input Type | 例                            |
| ---------- | ---------------------------- |
| Text       | プロンプト、メッセージ                  |
| Image      | PNG、JPG、WebP、GIF、…           |
| Audio      | WAV、MP3                      |
| Video      | MP4                          |
| Document   | PDF、DOCX、XLSX、PPTX、TXT、CSV、… |
| Archive    | ZIP                          |

カテゴリのサポートは3段階のライフサイクルに従います。System Guardianが扱えるカテゴリを**宣言**し、Project Guardianがそのサブセットを**有効化**し、ランタイムにBastionが有効な集合に照らして受信コンテンツを**検証**します。（Desktop Agentプロジェクトではコンテンツタイプはパースルールによって決定され、APIプロジェクトでは宣言されたcontent-partタイプから取得されます。）タイプが有効化されていないコンテンツは拒否されます（ファイルの場合は未検査で通過します — Unsupported File Handlingを参照）。これらがAPIリクエストにどのようにマッピングされるかについては、[マルチモーダル入力](/ja/v1.2/api/multimodal)を参照してください。

## process type: inputとoutput

Guardianは**process type**ごとにコンテンツを評価します。process typeとは、Guardianが定義する自由形式のラベルです（一般的には`input`と`output`）。

* **`input`** — モデルへ*送られる*コンテンツ（ユーザーのプロンプト）。
* **`output`** — モデルから*返ってくる*コンテンツ（応答）。

各process typeは、**互換性のあるPolicy Type**を宣言します。Guard Policyはprocess typeごとに割り当てられるため、入力時にはPIIをマスクし、出力時には例えば許可されていないトピックをブロックするといった構成が可能です。互換集合が空のprocess typeは**Policy-not-required**（ポリシー不要）であり、そのためのポリシースロットは表示されず、呼び出し時に`policies`も送信されません（追加入力のみで動作します）。

## Guardianのコントラクト

いずれのGuardian実装も、プラットフォームが駆動できるよう、小さなベースラインのコントラクトを満たす必要があります。

* **ステートレス** — すべてのリクエストは独立して処理されます。ユーザー管理、認証、トレースログはBastionの役割であり、Guardianの役割ではありません。
* **正規化されたフォーマット** — Guardian Input Formatを受け取り、Guardian Output Formatで応答します。
* **3つのベースラインエンドポイント** — `/guardian`（解析）、`/info`（自己記述）、`/health`（生存確認のみ）。これに加えて、任意でモデルごとの診断があります。

`/info`は**シード（種）であり、信頼できる情報源（source of truth）ではありません**。登録時にそのレスポンスがフォームを事前入力し、System Adminが保存した結果がシステムの信頼できる情報源となります。

### Guardian Fail-Closed

Guardianは、**完全に解析できたリクエストに対してのみ**成功レスポンスを返します。解析を完了できない場合 — モデルがダウンしている、ファイルを抽出できない、あるいは複数のモデル呼び出しのうち1つでも失敗した場合（部分的失敗）— は、**HTTPエラー**を返し、検出ゼロの「成功」を返すことは決してありません。これにより、「検出なし」は常に*解析した上で何も見つからなかった*ことを意味し、障害が知らないうちにPASSになることは決してありません。

## モデル構成

各Guardianは実効的なモデル構成を持ちます。これは、エンジンのデフォルトに、プロジェクトレベルのオーバーライド（例: `confidence_threshold`）をマージしたものです。管理者はGuardianの詳細ページでこれらを確認し、オーバーライドできます。

<Note>
  Guardianは、ポリシーが割り当てられており、**かつ**それらのポリシーバージョンが適用されている場合にのみ動作します。[ポリシー更新のバージョン管理と適用](/ja/v1.2/admin/how-to/version-and-apply-policy)を参照してください。
</Note>