<!-- Canonical URL: https://ask.atlascloud.ai/ja/replace-replicate-prediction-polling-and-webhooks -->

# 既存アプリでReplicate PredictionのポーリングとWebhookを置き換えるには？

> 製品とモデルAPIの間にプロバイダー非依存の非同期ジョブレコードを置きます。検証済みWebhookまたは制限付きポーリングワーカーから同じ冪等なファイナライザーを更新し、状態を正規化して完成ファイルを永続ストレージへコピーします。

アプリケーションと推論APIの間にプロバイダー非依存のジョブ層を置き、ReplicateのポーリングとWebhookを置き換えます。作成、状態、キャンセル、完了イベント、出力保存を正規化し、製品の他の部分がReplicateの予測オブジェクトやURLに依存しないようにします。

製品コード内でcallback URLだけを入れ替えるのではなく、まず必要な非同期契約を定義します。

## 現在の動作を記録する

Replicateの非同期作成は、予測ID、状態、補助URLを返します。アプリは`urls.get`をポーリングし、Webhook POSTを受け、対応時にはサーバー送信イベントを利用できます。各フローの経路と状態遷移時の動作を記録します。

| Replicateの概念 | アプリケーションでの置換 |
|---|---|
| 予測ID | プロバイダージョブIDと内部ジョブID |
| `starting`、`processing` | `queued`、`running` |
| `succeeded` | `completed` |
| `failed`、`canceled` | `failed`、`canceled` |
| `urls.get` | アダプターの状態取得メソッド |
| Webhookペイロード | 正規化された完了イベント |
| 出力URL | アプリ所有の永続資産 |

生のプロバイダー状態を正規化状態と別に保存し、ライフサイクル差を調査できるようにします。

## 内部ジョブレコードを導入する

新しいプロバイダーを呼ぶ前にデータベース行を作成します。

```json
{
  "job_id": "job_01J...",
  "provider": "target",
  "provider_job_id": null,
  "state": "creating",
  "attempt": 1,
  "output_assets": []
}
```

UI、キュー、通知では内部`job_id`を使い、作成後に外部IDを付けます。冪等キーでネットワーク再試行による二重課金ジョブを防ぎます。

## 制限付きワーカーでポーリングを置き換える

移行先に取得APIはあるがWebhookがない場合、ポーリングをバックグラウンドワーカーへ移します。ジッター付き指数バックオフ、期限、最大間隔を使い、キャンセルを含むすべての終端状態で停止します。

ブラウザーからポーリングしません。サーバーワーカーはタブを閉じても継続し、レート制限を集中管理し、状態をトランザクションで保存できます。

## 検証済みイベントでWebhookを置き換える

移行先がWebhookを提供する場合、ハンドラーを小さく保ちます。

* 解析前に署名または共有シークレットを検証する。
* イベントIDまたはジョブと状態で重複排除する。
* すぐに応答し、処理をキューへ送る。
* ペイロードが部分的なら正式なジョブを取得する。
* 順序違いと再配信を許容する。

Replicateはstart、output、logs、completedをフィルターできます。移行先が終端イベントしか送らない場合、疎な状態から精密な進捗を作りません。

## 一つの完了経路を使う

ポーリングとWebhookは同じ冪等なファイナライザーを呼びます。内部ジョブをロックし、外部IDを確認し、終端状態を保存し、ファイルを永続ストレージへコピーし、アプリイベントを一度だけ発行します。

これによりWebhookと最後のポーリングが同時に来ても通知が重複しません。

## ファイルが消える前に保存する

ReplicateはAPI予測の入出力ファイルが一定時間後に削除されると説明しています。移行先は異なる保持期間や署名URL期限を使う場合があります。外部URLは永続ストレージではなく配信手段として扱います。

出力を速やかに取得し、種類とサイズを検証し、必要ならスキャンし、独自キーで保存してチェックサムを記録します。クライアントには独自の安定URLを提供します。

## 障害と復旧をテストする

作成応答の遅延、Webhookの重複と欠落、429と5xx、キャンセル競合、期限切れURL、不正ペイロード、処理途中のワーカー再起動をテストします。

安全な入力で両方のアダプターをシャドー実行し、終端状態と資産数を比較してから少量の本番トラフィックを移します。

## まとめ

永続的な置き換えは、製品中に散らばるcallbackではなく内部の非同期ジョブ契約です。状態を正規化し、完了処理を冪等にし、ファイルを直ちに保存して、検証済みWebhookまたは制限付きワーカーから同じ完了経路を動かします。

## FAQ

### ブラウザーから移行先APIを直接ポーリングすべきですか？

サーバー側ワーカーを推奨します。ブラウザーを閉じても継続でき、レート制限と再試行を集中管理し、内部状態を一貫して更新できます。

### Replicateの予測状態はどうマッピングしますか？

creating、queued、running、completed、failed、canceledなどの小さな内部ライフサイクルへマッピングし、デバッグ用に元の状態も保持します。

### Webhookの二重処理をどう防ぎますか？

送信元を検証し、イベントIDまたはジョブと状態で重複排除し、Webhookとポーリングを同じトランザクション型の冪等なファイナライザーへ送ります。

### 新しいプロバイダーにWebhookがない場合は？

指数バックオフ、ジッター、期限、すべての終端状態の処理を備えたバックグラウンドワーカーを使用します。

### プロバイダーの出力URLを永続的に公開できますか？

永続性を前提にしないでください。出力をすぐにダウンロードし、独自のアクセス制御を持つアプリケーション資産URLを提供します。

### 移行テストで扱うべき障害は？

重複または欠落したイベント、レート制限、一時エラー、キャンセル競合、期限切れ出力、不正なペイロード、処理中のワーカー再起動を含めます。