> 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/depuroi/batch-processing/troubleshooting.md).

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

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

## 既知の制限事項

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

## 技術的詳細

* Data Staging に **7日間の有効期限で保存されます**.
* 各バッチ処理ジョブには複数のステージが含まれます（通常は `processing` と `export`）。各ステージは出力バッチを作成します。使用を推奨します `export` ステージ出力。効率的な転送のために圧縮されているためです。
* 実行中のジョブは `processing` ステージは UI と CLI の両方で中止できます。
* 中止または失敗したジョブは再開できます。
* このサービスはデータを自動的にシャード分割し、並列処理します：
  * マシン数はデータ量に応じて自動的にスケールします（特定のワークロードではスループットが 1 時間あたり 50万〜100万枚の画像に達することがあります）。
  * 各マシンでは、データのチャンクを処理する複数の worker が実行されます。これは設定可能で、速度とコストのバランスを取るよう調整すべきです。
* 画像ジョブでは、1つのシャード内で失敗した画像が多すぎる場合、そのシャードは中止され、ジョブの残りは継続します。このしきい値はジョブごとに設定できます（参照 [シャードごとの画像失敗許容率](#per-shard-image-failure-tolerance) 下記）。

## ジョブがタイムアウトしました

### 問題

バッチジョブは、次の条件では途中で終了します： **Processing Timeout Hours** が、ジョブの規模や複雑さに対して低すぎる場合。

<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` （CLI）は次を定義します： **すべての並列 worker にわたるマシンの累計実行時間上限**.

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

### 推奨事項

* 大規模データセットや多段の Workflows では、余裕のあるタイムアウト（例：4〜6時間）から始めてください。
* 実際のジョブ実行時間を監視し、今後のタイムアウト設定に反映してください。
* チャンク数を減らす、または video frame sub-sampling を使用して、より高速な処理を検討してください。

## SAHI を使用する Workflow が長すぎる時間実行される

### 問題

SAHI を使用するジョブは、特に高解像度入力や instance segmentation を伴う場合、予想よりかなり長くかかることがあります。

### 原因と推奨事項

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

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

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

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

**SAHI を使用する video ジョブ：** 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>

## メモリ不足（OOM）エラー

### 問題

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

### 一般的な原因

* **SAHI + instance segmentation：** この組み合わせは非常にメモリを消費します。SAHI は推論呼び出しを増やし、instance segmentation は大きな出力（マスク、スコア）を生成するため、クラッシュにつながることがよくあります。
* **マシンあたりの worker が多すぎる：** 複数の worker は軽量な Workflows ではコストと速度を最適化しますが、重い 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>

## シャードごとの画像失敗許容率

### 仕組み

画像バッチジョブは、並列で実行されるシャードに分割されます。各シャードは、処理中に何枚の画像が失敗したかを追跡します。1つのシャード内の失敗率がしきい値を超えると、そのシャードは中止されます。ジョブの残りは影響を受けずに継続します。

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

* `0.0` ゼロ許容を意味します（最初の失敗でシャードを中止します）。
* `1.0` 画像が何枚失敗してもシャードは中止されません。
* このフィールドを省略するか、次に設定すると `null` プラットフォームのデフォルトを使用します。

このパラメータは画像ジョブにのみ適用されます。video ジョブではサポートされていません。

### API での設定

含める `maxImageFailureRate` ジョブ作成ペイロードに：

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

失敗または中止されたジョブを再開するときにも、restart parameters override に含めることでこの値を上書きできます。