> ## 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.

# バッチ概要

> Starfort S3 非個人化バッチの全体像。src と tgt バケット参照で駆動される非同期処理を、ジョブ送信・ポーリング・成果物収集の流れで解説します (Starfort v1.4 版)

**S3 連携の非識別化バッチ**は、バケットにすでに保存されているファイルを、その場所を指定するだけで非識別化する**非同期**の処理経路です。原本アドレス（`src_s3_url`）と結果保存アドレス（`tgt_s3_url`）を渡すだけで、Starfort がバケットから原本を直接読み取り、個人情報（PII）と機微なトピック（Topic）を検出し、非識別化（マスキング）されたファイルを指定の場所に保存します。

**データ受け渡しの主体は Starfort です。** Starfort が S3 標準オペレーション（GetObject / PutObject）で `src` を読み、`tgt` に書き込みます。呼び出し元がすべきことは 3 つだけです — ファイルをバケットに置き、アクセス権限を付与し、結果を `tgt` から回収すること。転送ロジックを自前で実装する必要はありません。

## インライン Guard API との関係

バッチは、既存の [Guard API](/ja/v1.4/api/quickstart) の**横に追加される**経路です。既存の同期 API はそのまま維持され、既存の呼び出し元への影響はありません。

| 軸         | インライン Guard API      | S3 連携の非識別化バッチ                                                            |
| --------- | -------------------- | ------------------------------------------------------------------------ |
| ファイルの受け渡し | リクエストボディに base64 で同梱 | **バケット参照** — `src` アドレスのみを渡す                                             |
| 処理モデル     | 同期 1 ターン（レスポンス = 完了） | **非同期ジョブ（job）** — 受付と完了が分離                                               |
| 結果の受け渡し   | レスポンスボディで返却          | **`tgt` に直接書き込み** — 判定ごとの[成果物ルール](/ja/v1.4/api/batch/outputs-and-limits) |
| リクエストサイズ  | 入力受信上限と base64 膨張の制約 | ボディにファイルがないため**リクエストサイズの制約なし**                                           |

検査そのものは変わりません — バッチもインラインと同じ Guardian エンジンが、同じポリシー・判定ルールで検査します。検査ポリシーはリクエストではなく**サーバー（プロジェクト設定）が決定**し、バッチ専用のポリシー体系はありません。

## 事前準備

<Steps>
  <Step title="プロジェクトと Guardian の準備">コンソールでプロジェクトと、どのポリシーで検査するかを定義した Guardian を用意します。</Step>
  <Step title="Storage Connection の登録">Starfort がバケットにアクセスするための連携設定をプロジェクトに登録します — 接続情報、アクセス認証情報、許可対象（読み取り／書き込みの範囲）。[Storage Connection](/ja/v1.4/api/batch/storage-connection) を参照してください。</Step>
  <Step title="API Key の発行">プロジェクトの API Keys メニューで発行します。[API キーの管理](/ja/v1.4/admin/api-keys)を参照してください。</Step>
</Steps>

原本の入力フォルダ（例: `inbox/`）と結果の出力フォルダ（例: `deidentified/`）を分けて決めておくことを推奨します。

## 認証

既存の Guard API と**同一の API Key 体系**です。`sf_` で始まるキーを `X-Starfort-Guard-Api-Key` ヘッダーで送信し、ジョブはそのキーが指す Project Guardian のスコープに帰属します。[認証](/ja/v1.4/api/authentication)を参照してください。

## ジョブの状態

バッチジョブの状態は 4 種です:

| 状態           | 意味                                                  |
| ------------ | --------------------------------------------------- |
| `PENDING`    | 受け付けられ、待機中です。                                       |
| `PROCESSING` | 処理中です。内部リトライは公開されず、処理中のまま維持されます。                    |
| `COMPLETED`  | 検査を完了しました — 判定（`PASS` / `MASK` / `BLOCK`）が併せて確定します。 |
| `FAILED`     | 検査を完了できませんでした — 失敗理由（`error`）が併せて確定します。             |

`PENDING → PROCESSING` の後、`COMPLETED` または `FAILED` に確定し、確定した状態が最終です。

* **ジョブは受付順に処理されます（先入れ先出し）。** 別途の優先度階層はありません。
* **完了確認は定期照会（ポーリング）です。** [ジョブ照会 API](/ja/v1.4/api/batch/jobs) で状態を確認してください。

## BLOCK は失敗ではありません

**BLOCK** は検査が正常に完了してブロック判定が出たものであるため、`COMPLETED` + `action: "BLOCK"` として表現されます。`FAILED` は検査を完了できなかった場合であり、結果ファイルを保存せず、失敗が「検出なし」として処理されることはありません — インライン API の[フェイルクローズ原則](/ja/v1.4/api/errors)と同じ系譜です。

<Note>
  [Kill Switch](/ja/v1.4/admin/kill-switch) の発動中は、ジョブの作成と照会がどちらも拒否され、待機中・進行中だったジョブは成果物なしで失敗として確定します。すでに `tgt` に書き込まれた成果物が遡及して回収されることはありません。
</Note>

## 次のステップ

* [ジョブの作成・照会 API](/ja/v1.4/api/batch/jobs) — エンドポイント、リクエスト／レスポンスのフィールド、ポーリングパターン
* [Storage Connection](/ja/v1.4/api/batch/storage-connection) — S3 連携の設定と許可範囲
* [成果物ルールと制限](/ja/v1.4/api/batch/outputs-and-limits) — 判定ごとの `tgt` 成果物、サポート形式、制限
* [バッチのエラー](/ja/v1.4/api/batch/errors) — 受付時点の HTTP エラーと処理時点の失敗コード