Skip to main content
user メッセージの content はコンテンツパートの配列にできるため、1 つのリクエストでテキストとファイルを混在させることができます。6 つの Input Type — Text、Image、Audio、Video、Document、Archive — があり、Guardian は Input Type が有効になっている各パートを検査します。

​
コンテンツパートのタイプ

Document と Archive はどちらも type: "file" を使用します。Starfort は type フィールドではなく、ファイルの実際の MIME / マジックバイトのタイプによって、それらを正しい Input Type に振り分けます。data: URI のペイロードは標準の base64（+、/、=）でエンコードしてください。URL セーフな base64（-、_）はサポートされていません。

​
ルール

  • パートは、その Input Type が Guardian で有効になっている場合にのみ検査されます。そうでない場合は、Guardian の未対応ファイルの処理設定（下記）に応じて、リクエストが拒否されるか、そのパートがスキップされます。
  • レスポンスでは、各パートが text／image／audio／video／document／archive の type を持つ独立した input_results[] エントリとして報告され、ファイルパートには identifier（ファイル名）が付与されます。

​
未対応のファイル

ファイルパートのカテゴリーまたは拡張子が Guardian で有効になっていない場合、Guardian の Unsupported File Handling 設定によって何が起こるかが決まります。v1.4 からは、この設定の適用ポイントは Guardian の単一ポイントです — ゲートウェイは未対応ファイルを自ら判定・破棄せず、設定を Guardian に引き渡し、Guardian が最上位のファイルとアーカイブ（ZIP）内部のメンバーに同一に適用します。
  • BLOCK（デフォルト） — 未対応ファイルが 1 つでもあると、リクエスト全体が拒否されます。対応しているパート（テキスト、許可されたファイル）も検査されません。分析できないコンテンツを無検査で通過させない、フェイルクローズの動作です。
  • PASS — 未対応のファイルパートのみが検査から除外され、リクエストの残りは通常どおり検査されます。アーカイブ内部も同じルールです — 未対応のメンバーだけをスキップして残りのメンバーは検査されるため、拡張子のない付属ファイルが混在する正常なアーカイブが丸ごと拒否されることはありません。
検査から除外されたファイルの原本は、外部へ送出されません。 Guardian が内容を確認できなかった入力は処理済みコンテンツ（processed_content）を作れないため null で返され、処理済みコンテンツのない入力は送出の対象になりません。
偽装されたファイルは常にブロックされます。 PASS の場合でも、拡張子は許可されているがその実際のコンテンツ（マジックバイト）が宣言されたタイプと一致しないファイルはブロックされます。チェックはファイル名ではなく実際のコンテンツに対して行われます。
バケットに保存されたファイル自体を非識別化してマスキングされたファイルとして保存する必要がある場合（例: .docx をマスキングされた .docx として再構成する）、S3 連携の非識別化バッチを使用してください。
Guardian を登録する際に、送信する予定の Input Type を有効にしてください。デフォルトの VLM-OCR プリセットは、テキストに加えて幅広い画像、ドキュメント、アーカイブ形式をサポートします。