<!-- Canonical URL: https://ask.atlascloud.ai/ja/migrate-together-ai-batch-job-without-losing-request-ids -->

# リクエストIDを失わずにTogether AIのバッチジョブを移行するには？

> アプリケーションが所有するcustom_idは変更せず、Togetherと移行先のファイルID、バッチID、レスポンスIDを別々に保存します。送信前にID集合を検証し、成功とエラーをIDで照合し、業務キーを変えずに試行回数を記録します。

Together AIのバッチジョブを移行する際は、移行元の各`custom_id`を変更不能なアプリケーションデータとして扱います。そのまま移行先リクエストへコピーし、移行先のバッチIDやレスポンスIDは別項目に保存し、ファイル順ではなく`custom_id`で結果を照合します。

重要なのは、アプリケーションが所有する識別子とプロバイダーが発行する識別子を分けることです。前者を維持し、後者を対応付けます。

## すべての識別子を棚卸しする

Togetherのバッチ入力はJSONLです。各行に一意の`custom_id`とリクエスト本文が含まれます。バッチ、入力ファイル、出力ファイル、生成レスポンスには別々のIDがあります。

| 識別子 | 所有者 | 移行ルール |
|---|---|---|
| `custom_id` | アプリケーション | 完全に維持する |
| 移行元バッチID | Together | 移行元メタデータとして保存 |
| 移行先バッチID | 移行先プロバイダー | 別に保存 |
| 入出力ファイルID | 各プロバイダー | 業務キーにしない |
| レスポンスID | モデルAPI | サポートと課金用に保存 |

行番号が既存の永続キーでない限り、`custom_id`を行番号へ置き換えてはいけません。出力順が変わったり、失敗が別ファイルに入ったりします。

## 移行台帳を作成する

移行先へ送る前に、論理リクエストごとにレコードを作ります。

```json
{
  "custom_id": "invoice-2026-00421",
  "source_batch_id": "batch_source",
  "target_batch_id": null,
  "payload_sha256": "...",
  "state": "prepared"
}
```

集合内で`custom_id`を一意にし、正規化した本文のハッシュを追加します。ハッシュは、機密プロンプトをもう一つ保存せずに変更を検出できます。

## IDではなくエンベロープを変換する

プロバイダーごとにバッチのエンベロープは異なります。Togetherの例では`custom_id`と`body`が並び、別のOpenAI互換APIでは`method`と`url`も必要な場合があります。

```json
{"custom_id":"invoice-2026-00421","method":"POST","url":"/v1/chat/completions","body":{"model":"target-model","messages":[{"role":"user","content":"Classify this record"}]}}
```

変換層でエンドポイント、モデル、非対応パラメーターを変更します。元の`custom_id`は不透明な文字列として渡し、切り詰め、大小文字変換、翻訳、再生成をしません。

## 送信前に検証する

生成したJSONLで次を確認します。

* 各行を単独で解析できる。
* すべての`custom_id`が存在し一意である。
* ID集合が移行元マニフェストと一致する。
* 各本文が移行先schemaを満たす。

最終ファイルのハッシュと行数を記録し、その成果物だけをアップロードして、返されたファイルIDとバッチIDを台帳に追加します。

## 出力とエラーをまとめて照合する

バッチ完了後、出力とエラーの両方を取得します。各行を`custom_id`で索引化し、その和集合を送信済み集合と比較します。

各IDを成功、失敗、欠落、重複に分類します。バッチが完了していても照合済みとは限りません。すべてのIDに一つの終端結果があるまで移行を完了しません。

## IDを変えずに再試行する

失敗または欠落したリクエストだけで新しいバッチを作ります。同じ`custom_id`を維持し、業務キーを変更する代わりに台帳の`attempt`を増やします。

移行先がバッチ間でのID再利用を禁止する場合は、元の値をアプリケーション項目に残し、可逆な対応を持つ転送IDを生成します。

## 安全に切り替える

小さく代表的なバッチから始め、成功率、遅延、トークン、出力、エラー、コストを比較します。照合が決定論的になるまで移行元と移行先の結果を並べて保持します。

不明IDがない、終端結果の重複がない、欠落IDがない、という三つのアサーションを自動化します。

## まとめ

アプリケーション所有の`custom_id`を維持し、プロバイダーのエンベロープだけを変換します。成功とエラーをIDで照合し、再試行を回数として記録し、すべてのリクエストに終端結果がある場合だけ切り替えます。

## FAQ

### Togetherのバッチ移行で維持すべきIDはどれですか？

アプリケーションが割り当てたcustom_idを維持します。各プロバイダーのバッチID、ファイルID、レスポンスIDは業務キーではなく、個別のメタデータとして保存します。

### 行番号でバッチ結果を照合できますか？

できません。出力順は入力順と異なる場合があり、失敗したリクエストは別ファイルに入ることがあります。custom_idで成功とエラーの和集合を照合します。

### 移行台帳には何を保存しますか？

custom_id、正規化したペイロードのハッシュ、移行元と移行先のバッチおよびファイルID、試行回数、時刻、各リクエストの一意な終端状態を保存します。

### 再試行には新しいcustom_idが必要ですか？

通常は不要です。業務識別子を維持し、attemptを増やします。転送IDを一意にする必要がある場合は、元のcustom_idへの可逆な対応を保存します。

### 失われたリクエストはどう検出しますか？

送信済みID集合と、成功IDおよびエラーIDの和集合を比較します。照合完了前に欠落、不明、重複したIDを検出します。

### Togetherの入力ファイルをそのまま再利用できますか？

移行先が同じエンベロープ、エンドポイント、モデルID、パラメーターを受け付ける場合だけです。通常はcustom_idを変えない変換処理が必要です。