> ## 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 判定と検知アイテムを返す Starfort のコアエンジンです (Starfort v1.4 版)

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

v1.4 からは、Guardian は Starfort の**モジュールの 1 つ**として位置づけられます — Guardian がテキスト入力を管轄し、ファイルは（使用する場合）[Stratum](/ja/v1.4/concepts/stratum) が管轄します。2 つのモジュールは 1 つの Project 内で対等な [Module Instance](/ja/v1.4/concepts/module-instances) として共存します。Stratum のない Project では、従来どおり Guardian がテキストとファイルの両方を処理します。

## System Guardian と Project Guardian

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

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

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

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

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

* **System Guardian の仕様は、登録後は不変です。** いったん登録されると、変更できるのは名前、説明、Endpoint URL、可視性（スコープ＋Enabled）のみです。機能仕様 — サポートされる Input Type、ポリシー種別、process type、上限、モデル構成キー — は凍結されます。
* **Project Guardian は作成時にその仕様をコピーし、独立して保持します。** 後から System Guardian を編集しても、その変更はさかのぼって**伝播しません**。参照され続けるのはライブの Endpoint URL のみです。互換性のある ポリシー種別 の集合（*検査できる*対象）は 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.4/api/multimodal)を参照してください。

## process type: input と output

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

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

各 process 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 になることは決してありません。

### 3 つの障害軸、3 つのポリシー

Guardian Fail-Closed は、プラットフォームにある 3 つの独立した fail 方向ポリシーの 1 つです — それぞれが異なる種類の障害に対応します:

| 障害                               | ポリシー                                                   | 適用単位                                                                                     |
| -------------------------------- | ------------------------------------------------------ | ---------------------------------------------------------------------------------------- |
| Guardian が解析を完了できない              | **Guardian Fail-Closed** — 常にエラー、静かな PASS はなし（このセクション） | 組み込み動作、設定不可                                                                              |
| Desktop Agent が Starfort に接続できない | **Network Fail-Safe** — fail-open または fail-closed      | [Company 設定](/ja/v1.4/admin/desktop-agent-settings)                                      |
| 判定は下されたが、Opticon トレースの記録に失敗した    | **Opticon フェイルセーフ** — Fail-Open（デフォルト）または Fail-Closed  | [Project 設定](/ja/v1.4/admin/monitoring-opticon#opticon-fail-safe-fail-open--fail-closed) |

## モデル構成

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

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