Rivya AI ドキュメント

Rivya トラブルシューティングガイド

チャット送信、アップロード、停止した生成タスク、見つからない結果、支払い更新、クレジット、履歴、通知に関する Rivya の問題を解決します。

2026/04/28 最終レビュー

Rivya のチャット、アップロード、生成タスク、履歴、通知、クレジット、請求状態が期待どおりに動かない場合は、このトラブルシューティングガイドを使います。

Rivya が壊れているように感じるとき、最も速い対処は、実際に失敗しているレイヤーを見極めることです。

多くの問題は、次の 5 つのどれかに入ります。

  • アクセスとサインイン
  • モデルまたは入力の不一致
  • 非同期タスク状態
  • ウォレットまたは支払い状態
  • 保存済み作業の探し方

この切り分けは、すべてを一般的な「バグ」として扱うよりずっと有用です。

1. Chat が送信できない

チャットが実際に実行されない場合は、まず単純な原因を確認します。

  • まだ公開ランディングフロー上にいて、送信前にサインインが必要な可能性がある
  • 下書きメッセージが空である可能性がある
  • 保存済みセッションが正常に読み込まれていない可能性がある

問題がセッション固有である場合は、どの経路にいたかを推測するのではなく、History から会話を開き直します。

タスクが狭く繰り返し型である場合は、広い通常チャットのスレッドで続けるより、ツール入口からやり直すほうが整理しやすい場合もあります。

2. 生成が開始しない

画像、動画、音声の生成が実際に始まる前に失敗する場合、通常の原因は次です。

  • 必要なプロンプト内容が欠けている
  • 対話形式の音声フォームが未完了である
  • 選択したモデルが参照ファイルを必要としているが、提供されていない
  • アカウントのクレジットが足りない

現在、クレジット不足の場合は、上流サービスが呼び出される前に実行が失敗することがあります。そのため「何も起きなかった」ように感じても、実際には失敗記録と通知が残る場合があります。

3. アップロードが失敗する

アップロードはカテゴリではなく、モデルによって決まります。

つまり次の通りです。

  • 同じカテゴリのすべてのモデルが同じ参照種類を受け付けるわけではない
  • すべてのモデルが同じファイル数を受け付けるわけではない
  • 実際の生成リクエストの前に、サイズとタイプの制限が適用される

アップロードが失敗する場合は、次を確認します。

  • そのモデルがそのファイル種類をそもそもサポートしているか
  • 現在の参照ファイル数の上限にすでに達しているか
  • ファイルタイプまたはサイズが現在のアップロードルールに違反しているか

ワークフローが音声クリーンアップまたは分離である場合、アップロード音声の経路は、プロンプトから始める TTS や音声生成とは構造的に異なることを覚えておきます。

4. タスクが進行中のまま止まっている

Rivya の画像、動画、音声の実行は非同期タスクです。

可視状態は次の通りです。

  • WAITING
  • GENERATING
  • SUCCESS
  • FAILED

タスクが止まっているように見える場合、現在のページだけを見ないでください。

次の画面も確認します。

一部のタスクはコールバックで完了し、一部はポーリングまたは更新で完了します。そのため「まだ生成中」は、それだけで「失われた」ことを意味しません。多くの場合、タスクは最終的な上流結果の確定を待っています。

5. タスクが失敗した

Rivya では、失敗は通常隠されず、保持されます。

失敗したタスクには次が残る場合があります。

  • 失敗状態そのもの
  • エラーメッセージ
  • 予約済みクレジットを戻すべき場合の返金状態
  • 生成失敗通知

そのため、通常の次のステップは次です。

  1. 失敗状態を読む
  2. 問題がクレジット、プロンプト、入力不一致のどれだったか判断する
  3. その具体的な原因を修正してから再実行する

すべての失敗を一時的な UI 問題として扱わないでください。

6. 結果が消えたように見える

通常、結果は消えていません。違う画面にあるだけです。

問いが次の場合は History を使います。

何を作ったか、何を話したか。

問いが次の場合は Notifications Center を使います。

重要なアカウントイベントまたはワークフローイベントは何だったか。

大まかなルールは次です。

  • チャットはチャット履歴へ戻る
  • 画像、動画、音声は生成履歴へ戻る
  • 請求とクレジットのイベントは、通知で最も明確に見えることが多い

7. 支払い状態が古く見える

チェックアウトが完了したのにウォレットまたは請求状態が古く見える場合は、支払いが失われたと考える前に請求経路をたどります。

現在のプロダクトフローは次です。

  1. チェックアウトを完了する
  2. /payment 経由で戻る
  3. プロダクトに請求またはウォレット状態をポーリングして更新させる
  4. /settings/billing または /settings/credits を確認する

Notifications も請求結果を保持する場合があるため、アカウント状態が同期していないように感じるときは確認する価値があります。

8. 最初に確認する場所

この近道を使います。

  • 現在の Studio: 進行中のライブ作業
  • History: 保存済み出力と保存済み会話
  • Notifications Center: すでに起きた運用イベント
  • /settings/billing: サブスクリプション状態
  • /settings/credits: ウォレット残高、パック、有効期限、取引

多くの混乱は、最初に間違ったレイヤーを確認することから起こります。

次に読むページ

トラブルシューティング切り分けチェックリスト

同じ操作を繰り返す前に、最初に確認すべき場所を選びます。

  • Chat が送信できない: サインイン、セッション状態、モデル可用性、クレジット挙動を確認する。
  • アップロードが失敗する: ファイルタイプ、サイズ、モデルサポート、タスクに本当にファイルが必要かを確認する。
  • 生成が止まっている: タスク状態、プロバイダーコールバック、ポーリング、履歴、通知を確認する。
  • 請求が古く見える: Checkout の戻り、webhook 精算、請求設定、クレジット設定を確認する。
  • 結果が見つからないように見える: 正しい履歴種類と、タスクが実際に完了したかを確認する。

エスカレーション前に再確認する

アカウント領域、タスク ID または支払い文脈、期待した結果、実際の結果、最後に見えていた状態を言えるようになってからエスカレーションします。そうすれば、サポートは推測ではなく診断になります。

目次