src_s3_url）と結果保存アドレス（tgt_s3_url）を渡すだけで、Starfort がバケットから原本を直接読み取り、個人情報（PII）と機微なトピック（Topic）を検出し、非識別化（マスキング）されたファイルを指定の場所に保存します。
データ受け渡しの主体は Starfort です。 Starfort が S3 標準オペレーション（GetObject / PutObject）で src を読み、tgt に書き込みます。呼び出し元がすべきことは 3 つだけです — ファイルをバケットに置き、アクセス権限を付与し、結果を tgt から回収すること。転送ロジックを自前で実装する必要はありません。
インライン Guard API との関係
バッチは、既存の Guard API の横に追加される経路です。既存の同期 API はそのまま維持され、既存の呼び出し元への影響はありません。
検査そのものは変わりません — バッチもインラインと同じ Guardian エンジンが、同じポリシー・判定ルールで検査します。検査ポリシーはリクエストではなくサーバー（プロジェクト設定）が決定し、バッチ専用のポリシー体系はありません。
事前準備
1
プロジェクトと Guardian の準備
コンソールでプロジェクトと、どのポリシーで検査するかを定義した Guardian を用意します。
2
Storage Connection の登録
Starfort がバケットにアクセスするための連携設定をプロジェクトに登録します — 接続情報、アクセス認証情報、許可対象（読み取り／書き込みの範囲）。Storage Connection を参照してください。
3
API Key の発行
プロジェクトの API Keys メニューで発行します。API キーの管理を参照してください。
inbox/）と結果の出力フォルダ（例: deidentified/）を分けて決めておくことを推奨します。
認証
既存の Guard API と同一の API Key 体系です。sf_ で始まるキーを X-Starfort-Guard-Api-Key ヘッダーで送信し、ジョブはそのキーが指す Project Guardian のスコープに帰属します。認証を参照してください。
ジョブの状態
バッチジョブの状態は 4 種です:PENDING → PROCESSING の後、COMPLETED または FAILED に確定し、確定した状態が最終です。
- ジョブは受付順に処理されます（先入れ先出し）。 別途の優先度階層はありません。
- 完了確認は定期照会（ポーリング）です。 ジョブ照会 API で状態を確認してください。
BLOCK は失敗ではありません
BLOCK は検査が正常に完了してブロック判定が出たものであるため、COMPLETED + action: "BLOCK" として表現されます。FAILED は検査を完了できなかった場合であり、結果ファイルを保存せず、失敗が「検出なし」として処理されることはありません — インライン API のフェイルクローズ原則と同じ系譜です。
Kill Switch の発動中は、ジョブの作成と照会がどちらも拒否され、待機中・進行中だったジョブは成果物なしで失敗として確定します。すでに
tgt に書き込まれた成果物が遡及して回収されることはありません。次のステップ
- ジョブの作成・照会 API — エンドポイント、リクエスト／レスポンスのフィールド、ポーリングパターン
- Storage Connection — S3 連携の設定と許可範囲
- 成果物ルールと制限 — 判定ごとの
tgt成果物、サポート形式、制限 - バッチのエラー — 受付時点の HTTP エラーと処理時点の失敗コード