Rivya タスクライフサイクルガイド
Rivya のタスク状態、クレジット予約、プロバイダー送信、コールバック、ポーリング、履歴、通知、失敗、クレジットを理解します。
2026/04/28 最終レビュー
Rivya で画像、動画、音声の生成タスクを送信した後に何が起こるかを理解する必要がある場合は、このガイドを使います。
タスク状態、クレジット予約、プロバイダー完了、履歴、通知、失敗タスクの処理を 1 か所で説明します。
実際のタスク状態
現在の非同期生成ライフサイクルでは、4 つの可視状態を使います。
WAITINGGENERATINGSUCCESSFAILED
これらの状態は ai_task に保存され、Studio、履歴、ダッシュボード、通知フローで再利用されます。
送信時に起こること
1. Rivya がリクエストを検証する
プロバイダーに届く前に、Rivya は次を確認します。
- モデルが存在する
- そのモデルで直接生成が有効になっている
- ランタイムが非同期タスクベースである
- プロンプト長が有効である
- フォームパラメーターが正規化されている
- 参照ファイルがモデルの受け付ける内容と一致している
一部のモデルには追加ルールがあります。たとえば音声分離では、アップロード音声ファイルと長さの検証が必要です。
2. Rivya がタスク記録を作成する
Rivya は最初に ai_task エントリーを作成し、状態を WAITING にします。
その記録には、モデル、カテゴリ、プロンプト、params、予約済みクレジット、請求タイプ、その後の結果または失敗状態が保存されます。
3. プロバイダー送信前にクレジットが消費される
これは重要です。非同期生成では、Rivya はジョブを上流へ送る前にタスククレジットを消費します。
クレジットが不足している場合:
- タスクは失敗としてマークされます
- 上流サービスは呼び出されません
- クレジット不足の通知が作成される場合があります
4. プロバイダージョブが作成される
クレジットが利用可能な場合、Rivya は対応する上流サービスへタスクを送信し、上流タスク ID を保存します。
この時点で状態は GENERATING に移ります。
Rivya が結果を知る方法
Rivya は 2 つの完了経路をサポートしています。
- コールバック対応環境でのプロバイダーコールバック
- コールバック完了が使えない場合の状態更新とポーリング
コールバック経路では、タスクを確定する前に webhook 署名も検証します。
プロバイダー結果が完全に準備できる前にコールバックが届いた場合、Rivya は処理を延期し、上流状態を確認して再試行できます。
成功パス
成功時に Rivya は次を行います。
- 結果 URL を保存する
- 状態を
SUCCESSに設定する - タスクを精算する
- 出力を生成履歴で利用可能にする
- 生成成功通知を作成する
そのため、完成した画像や動画は、ページを離れた後も表示され続けます。
失敗パス
失敗時に Rivya は次を行います。
- エラーメッセージを保存する
- 状態を
FAILEDに設定する - 予約後に失敗し、取り消すべき場合はクレジットを返金する
- 後で確認できる生成失敗通知を作成する
これは一時的なトーストとは異なります。失敗はアカウントの記録の一部になります。
タスク状態が表示される場所
同じタスクはいくつかの場所に表示されます。
- 実行中のアクティブな Studio
- 精算後の History
- 主要な結果を知らせる Notifications Center
- 最近の生成として
/dashboard
その共有状態があるため、プロダクトは使い捨てではなく一貫したものに感じられます。
Chat との違い
Chat も請求対象ですが、同じ非同期タスク記録は使いません。Chat のターンは次として保存されます。
- チャットセッション
- チャットメッセージ
トークンベースのチャットモデルでは、Rivya は先にクレジットを予約し、使用量が返ってきた後に最終額を精算できます。最終額が少ない場合、差額は返金されます。
そのため、大まかなルールは次です。
- 画像、動画、音声生成は
ai_taskを使う - チャットは保存済みセッションとメッセージ単位の精算を使う
次に読むページ
- Rivya の画像ワークフロー
- Rivya の動画ワークフロー
- Rivya の音声ワークフロー
- クレジットと請求
- Rivya のトラブルシューティング
- Notifications Center
- History
タスク状態チェックリスト
生成が分かりにくい、遅い、失敗した、または見つからない場合は、次を確認します。
- まずタスクタイプを特定する: チャット精算、画像、動画、音声、またはツール連携チャット。
- クレジットがプロバイダー送信前に予約されたのか、使用量の後で精算されたのかを確認する。
- 結果が失われたと考える前に、プロバイダーコールバック、ポーリング結果、履歴項目、通知を探す。
- ユーザーが修正できる失敗と、プロバイダーまたはインフラの失敗を分ける。
- 同じプロンプトを再実行する前に、失敗タスクのクレジットを戻すべきか確認する。
再実行前に確認する
同じプロンプトが失敗し続ける、タスクが長時間進行中のままになる、出力なしにクレジットが消費されたように見える、またはより重い重複実行を送信しようとしている場合は、再確認します。