Skip to main content
Guardian は、AI リクエストの経路上に配置される解析エンジンです。コンテンツを受け取り、それに割り当てられた Guard Policy に照らして評価し、その判断の根拠となる検出項目とともにアクション — PASS、MASK、または BLOCK — を返します。 v1.4 からは、Guardian は Starfort のモジュールの 1 つとして位置づけられます — Guardian がテキスト入力を管轄し、ファイルは（使用する場合）Stratum が管轄します。2 つのモジュールは 1 つの Project 内で対等な Module Instance として共存します。Stratum のない Project では、従来どおり Guardian がテキストとファイルの両方を処理します。

​
System Guardian と Project Guardian

System Guardian

プラットフォームに登録されたマスター定義です（例: VLM-OCR プリセット）。Guardian がサポートする機能 — Input Type、ポリシー種別、process type、運用上限、モデル構成 — を宣言します。

Project Guardian

Project 内に作成するコピーです。運用設定（どの Guard Policy が割り当てられているか、モデル構成のオーバーライド、有効なカテゴリ、独自のライフサイクル）を保持します。API キーや Desktop Agent が呼び出すのはこちらです。
Account Admin がプロジェクトで Guardian を登録する際には、System Guardian プリセットを選択します。すると、プロジェクトには設定可能な独自の Project Guardian が作成されます。1 つの Project は複数の Project Guardian を実行できます — 例えばサービスごとに 1 つ、あるいはポリシーバンドルごとに 1 つというように — そして、それぞれが独立した Kill Switch の切り替え単位となります。

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

「なぜ変更が反映されないのか？」という混乱の大半は、2 つのルールで説明できます。
  • System Guardian の仕様は、登録後は不変です。 いったん登録されると、変更できるのは名前、説明、Endpoint URL、可視性（スコープ＋Enabled）のみです。機能仕様 — サポートされる Input Type、ポリシー種別、process type、上限、モデル構成キー — は凍結されます。
  • Project Guardian は作成時にその仕様をコピーし、独立して保持します。 後から System Guardian を編集しても、その変更はさかのぼって伝播しません。参照され続けるのはライブの Endpoint URL のみです。互換性のある ポリシー種別 の集合（検査できる対象）は 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 は、互換性のある ポリシー種別 を宣言します。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 は実効的なモデル構成を持ちます。これは、エンジンのデフォルトに、プロジェクトレベルのオーバーライド（例: confidence_threshold）をマージしたものです。管理者は Guardian の詳細ページでこれらを確認し、オーバーライドできます。
Guardian は、ポリシーが割り当てられており、かつそれらのポリシーバージョンが適用されている場合にのみ動作します。ポリシー更新のバージョン管理と適用を参照してください。