> For the complete documentation index, see [llms.txt](https://docs.roboflow.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.roboflow.com/roboflow/roboflow-jp/deploy/batch-processing/troubleshooting.md).

# トラブルシューティング

このページでは、Batch Processing に関する既知の問題、制限事項、および回避策を一覧表示します。ここに記載されていない問題に遭遇した場合は、当社の [サポート窓口](https://github.com/roboflow/inference/issues).

## 既知の制限事項

* 環境変数とローカルストレージへのアクセスを必要とする一部の Workflow ブロック（File Sink や Environment Secret Store など）はブロックされ、実行されません。
* このサービスは、 **単一の** 入力画像パラメータを定義する Workflows でのみ動作します。

## 技術的な詳細

* データは Data Staging に、 **7日間の有効期限**.
* 各 batch processing job には複数の stage が含まれます（通常は `processing` と `export`）。各 stage は output batch を生成します。使用を推奨するのは `export` stage outputs です。効率的な転送のために圧縮されているからです。
* 実行中の job は `processing` stage で、UI と CLI の両方から中断できます。
* 中断された job や失敗した job は再起動できます。
* このサービスはデータを自動的に shard 化し、並列処理します：
  * マシン数はデータ量に応じて自動的にスケールします（特定のワークロードではスループットが 1 時間あたり 50 万〜100 万枚の画像に達することがあります）。
  * 各マシンでは複数の worker がデータの chunk を処理します。これは設定可能で、速度とコストのバランスを取るよう調整する必要があります。
* 画像 job では、1 つの shard 内で失敗する画像が多すぎる場合、その shard は中断され、job の残りは継続します。このしきい値は job ごとに設定できます（以下の [Per-Shard Image Failure Tolerance](#per-shard-image-failure-tolerance) を参照）。

## Job タイムアウト

### 問題

Batch job は、 **Processing Timeout Hours** が job のサイズや複雑さに対して低すぎると、途中で終了します。

<figure><img src="https://media.roboflow.com/inference/batch-processing/batch-processing-timeout.png" alt=""><figcaption><p>UI の Processing Timeout 設定</p></figcaption></figure>

### 詳細

タイムアウト設定（UI）または `--max-runtime-seconds` は、 **すべての並列 worker にわたるマシン実行時間の最大累計を定義します**.

* **総計算時間：** 上限が 2 時間で、job が 2 台のマシンを起動した場合、それぞれ最大 1 時間実行できます（2 台 × 1 時間 = 合計 2 時間）。
* **chunk ごとに分割：** job は並列化のために処理 chunk に分割されます。タイムアウトは chunk 間で按分されるため、chunk が多くてタイムアウトが短いと、1 chunk あたりの時間が不足する場合があります。
* **マシンタイプも重要です：** CPU で複雑な Workflows を実行すると、処理時間が大幅に増加します。適切な場合は GPU を使用してください。

### 推奨事項

* 大きなデータセットや複数 stage の Workflows では、十分に長いタイムアウト（例：4〜6 時間）から始めてください。
* 今後のタイムアウト設定の参考にするため、実際の job 実行時間を監視してください。
* 処理を高速化するために、chunk 数を減らすか、video frame sub-sampling の使用を検討してください。

## SAHI を使用する Workflow が長すぎる

### 問題

SAHI を使用する job は、特に高解像度入力や instance segmentation を伴う場合、予想よりはるかに時間がかかることがあります。

### 原因と推奨事項

**スライス数が多すぎる：** SAHI は検出のために画像をより小さなスライスに分割します。デフォルト設定で高解像度入力を使うと、画像 1 枚あたり数十回から数百回の推論になることがあります。

* Image Slicer ブロックの設定を確認してください。スライス数を減らすか、Workflow の前段で Resize Image ブロックを使って入力を縮小してください。

**SAHI の代わりに、より大きなモデル入力サイズを検討してください：** より大きな入力寸法でモデルを学習すれば、SAHI が不要になる場合があります。まずは少量のサンプルでテストしてください。

**instance segmentation のボトルネック：** SAHI を instance segmentation と組み合わせて使用すると、Detections Stitch ブロック（特に NMS あり）が大きなボトルネックになることがあります。1 フレームの stitching だけで数十秒かかる場合があります。

**SAHI を使う video jobs では：** フレームをスキップするために FPS sub-sampling を使用してください：

* UI では、 **Video FPS sub-sampling** ドロップダウンに値を指定します。
* CLI では、 `--max-video-fps` フラグを使用してください。

<figure><img src="https://media.roboflow.com/inference/batch-processing/limiting-video-fps.png" alt=""><figcaption><p>UI の FPS sub-sampling 設定</p></figcaption></figure>

## Out of Memory（OOM）エラー

### 問題

Workflow が利用可能な RAM または VRAM を超えて消費すると、OOM エラーにより job は失敗します。

### 主な原因

* **SAHI + Instance Segmentation：** この組み合わせは非常にメモリ消費が大きいです。SAHI は推論回数を増やし、instance segmentation は大きな出力（mask、score）を生成するため、クラッシュにつながることがよくあります。
* **マシンあたりの worker が多すぎる：** 軽量な Workflows では複数の worker によりコストと速度を最適化できますが、重い Workflows（複数の大きなモデル、複雑な後処理）では利用可能なメモリを超えてしまいます。

### 推奨事項

* 大きなモデル、SAHI、または高解像度入力を扱う Workflows では、マシンあたりの worker 数を少なく（例：1 または 2）してください。
* 次を下げてください： **Workers Per Machine** Advanced Options の値。
* モデルにより高いメモリ帯域が必要な場合は、CPU から GPU に切り替えてください。
* 大きなバッチを実行する前に、小さなデータセットで Workflow をテストしてください。
* 入力解像度を下げるか、不要なブロックを削除して Workflow を簡素化してください。

<figure><img src="https://media.roboflow.com/inference/batch-processing/workers-number-adjustment.png" alt=""><figcaption><p>UI の Workers per machine 設定</p></figcaption></figure>

## Per-Shard Image Failure Tolerance

### 仕組み

画像 batch jobs は、並列実行される shard に分割されます。各 shard は処理中に何枚の画像が失敗したかを追跡します。1 つの shard 内の失敗率がしきい値を超えると、その shard は中断されます。job の残りは影響を受けずに継続します。

デフォルトでは、プラットフォームは固定の失敗しきい値を適用します。 `maxImageFailureRate` を job 作成リクエスト本文で設定することで、job ごとに上書きできます。値は `0.0` と `1.0`:

* `0.0` はゼロ許容を意味します（最初の失敗で shard を中断します）。
* `1.0` は、失敗した画像の数に関係なく shard が一度も中断されないことを意味します。
* このフィールドを省略するか、 `null` に設定すると、プラットフォームのデフォルトが使用されます。

このパラメータは image jobs にのみ適用されます。video jobs ではサポートされていません。

### API 経由での設定

次を含めます `maxImageFailureRate` を job 作成 payload に：

```json
{
  "type": "simple-image-processing-v1",
  "maxImageFailureRate": 0.1,
  ...
}
```

失敗または中断された job を再起動するときに、restart parameters override に含めることで、この値も上書きできます。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.roboflow.com/roboflow/roboflow-jp/deploy/batch-processing/troubleshooting.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.