Guardian

Guardianは、AIリクエストの経路上に配置される解析エンジンです。コンテンツを受け取り、それに割り当てられたGuard Policyに照らして評価し、その判断の根拠となる検出項目とともにアクション — PASS、MASK、またはBLOCK — を返します。

​

System GuardianとProject Guardian

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

​

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

「なぜ変更が反映されないのか？」という混乱の大半は、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ごとにそのサブセットを有効化します。 カテゴリのサポートは3段階のライフサイクルに従います。System Guardianが扱えるカテゴリを宣言し、Project Guardianがそのサブセットを有効化し、ランタイムにBastionが有効な集合に照らして受信コンテンツを検証します。（Desktop Agentプロジェクトではコンテンツタイプはパースルールによって決定され、APIプロジェクトでは宣言されたcontent-partタイプから取得されます。）タイプが有効化されていないコンテンツは拒否されます（ファイルの場合は未検査で通過します — Unsupported File Handlingを参照）。これらがAPIリクエストにどのようにマッピングされるかについては、マルチモーダル入力を参照してください。

​

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の詳細ページでこれらを確認し、オーバーライドできます。