最も起こりやすい間違いは、Rivya API と Rivya Studio を競合する経路として扱うことです。

この2つは、同じプロダクトの2つの段階として理解するほうが適切です。Studio は、人が視覚的に探索し、選び、レビューし、作業を続ける場所です。API は、安定したワークフローが別のプロダクト、スクリプト、バックエンド処理の一部になる場所です。

まだ API の範囲を学んでいる段階なら、Rivya API とは？から始めてください。このページはもっと狭く、特定のタスクが Studio に属するのか API に属するのかを判断するためのものです。

1つの表で判断する

質問	Studio を使うとき	API を使うとき
出力はまだ探索的か？	はい	いいえ、ワークフローはすでに反復可能
人が結果を比較する必要があるか？	はい	アプリが結果を受け取った後だけ
モデル選択は安定しているか？	まだ	はい、または API モデルリストから選ばれる
タスクに参照メディアが必要か？	人がまだ準備している	アプリが Files API でアップロードできる
結果は別システムを更新する必要があるか？	まだ	はい、polling または Webhooks で
クレジット使用量は見える必要があるか？	はい、テスト中は特に	はい、ただしアカウントレベルの API コントロールで

これはどちらの作業面がより高度かという話ではありません。タスクを自動化する準備ができているかの話です。

作業がまだ変わっている間は Studio を使う

人の判断がまだ主な作業であるとき、Studio が正しい場所です。

含まれるもの：

画像、動画、音声、chat モデルの間で選ぶ
プロンプト方向を残す価値があるかテストする
視覚結果を並べて比較する
参照メディアが役に立っているか邪魔しているかを判断する
保存済み履歴を使って以前の結果から続ける

これは特にクリエイティブ作業で当てはまります。ブリーフが安定していないなら、リクエストを自動化しても混乱は小さくならず、速くなるだけです。

ワークフローが反復可能なら API を使う

入力と次のステップが十分に予測できるようになると、API のほうがよい経路になります。

よいサイン：

プロダクトが必要なモデルまたはモデルカテゴリをすでに知っている
ユーザー入力を安定したリクエスト本文へマッピングできる
バックエンドジョブが、人が画面を見続けなくても状態を polling できる
タスク完了時に Webhook が正しいレコードを更新できる
アプリがクレジット使用量をチームまたはアカウント所有者へ説明できる

その時点では、毎回 Studio を使うほうが遅い経路になります。API は、あなたのプロダクトから直接タスクを開始できます。

実用的な境界：発見と統合

発見には Studio を使います。

統合には API を使います。

発見とは次です。

「どのモデルを使うべきか？」
「どんなプロンプト形状が機能するか？」
「参照メディアはこのタスクを改善するか？」
「この用途に出力品質は十分か？」

統合とは次です。

「このユーザー操作は1つの生成ジョブを作るべきだ。」
「このジョブは冪等に再試行されるべきだ。」
「このファイルはアップロードされ、モデルリクエストに添付されるべきだ。」
「完了したタスクは自社プロダクトのレコードを更新すべきだ。」

この境界により、API が隠れた実験面になるのを防げます。

クレジットが判断にどう影響するか

Studio と API の使用は、どちらも同じ Rivya アカウントのクレジットから引かれます。

つまりクレジット挙動は後付けではなく、プロダクト設計の一部であるべきです。

チームがまだコスト形状を学ぶ必要があるなら、まず Studio を使います。タスクが安定し、いつクレジットが予約または消費される可能性があるかをプロダクトが説明できるなら、API を使います。

現在の公開ルールは API Credits を読んでください。アカウント所有者へ説明するには高すぎるワークフローなら、まだ API 自動化の準備はできていません。

ファイルが選択を変える場所

参照メディアは、統合がより本格的になる場所であることがよくあります。

Studio では、人がアップロードし、確認し、再試行し、ファイルが十分によいかを判断できます。API では、あなたのプロダクトが Files API を通じてファイル経路を意図的に扱う必要があります。

Studio を使うとき：

参照画像、動画、音声にまだ人のクリーンアップが必要
どの参照がモデルを導くべきかチームがまだ分からない
ファイルルールがまだユーザーに明確ではない

API を使うとき：

アプリがファイルを安全に収集できる
モデルの参照要件が分かっている
生成または chat リクエストの前にファイルをアップロードできる
起きたことを隠さず、自社プロダクトでエラーを表示できる

Files API は有用な橋ですが、ファイル体験を設計する必要性を取り除くものではありません。

Chat が選択を変える場所

Chat はどちら側にも属することがあります。

人が探索、執筆、レビュー、判断をしているなら、Rivya Chat を直接使います。

chat turn を自社プロダクトまたはサーバーワークフロー内に置く必要があるなら、Chat API を使います。これには非ストリーミング turn、任意の SSE streaming、API 作成セッション、サポートされるファイル添付が含まれます。

重要な問いは、会話がどこに存在すべきかです。会話が Rivya 作業の一部なら Rivya を使います。会話が自社プロダクト体験の一部なら API を使います。

Webhooks がシグナルになるとき

ワークフローに API Webhooks が必要なら、おそらく手動の Studio 段階は過ぎています。

Webhooks は、別システムが完了した生成タスクに反応する必要があるときに役立ちます。

アセットを準備完了としてマークする
ユーザーへ通知する
レビュー手順を前に進める
失敗タスクをサポートまたは再試行ロジックへ移す

これは統合作業です。Studio はモデル経路のテストにはまだ役立ちますが、本番ループは API に属します。

安全な移行パターン

ワークフロー全体を一度に API へ移さないでください。

この順序を使います。

Studio でタスクを手動テストする
安定したモデル、プロンプト形状、入力ファイル、期待結果を書き出す
API Models とモデル参照を読む
API Quickstart から1つの生成を送信する
モデルが参照メディアを必要とする場合だけ Files API を追加する
polling が動いてから Webhooks を追加する
プロダクトが Studio の外で chat turn を必要とする場合だけ Chat API を追加する

各ステップは、ワークフローを単に自動化するのではなく、運用しやすくするべきです。

Studio に留まるべきとき

タスクにまだ次が必要なら、Studio に留まります。

主観的レビュー
プロンプト整形
視覚比較
モデル探索
保存済みのクリエイティブ履歴
次のステップが画像、動画、音声、chat のどれかを人が判断すること

これは弱点ではありません。Studio はその段階のために設計されています。

API へ移るべきとき

API へ移るのは次の場合です。

同じタスクがよく繰り返される
入力を構造化できる
モデルが分かっている
アプリが自分の UI からタスクを作成する必要がある
状態、エラー、クレジットを明確に扱える
polling または Webhooks がプロダクトのバックエンドに合う

API が最も強いのは、すでに理解済みの Rivya ワークフローを、信頼できるプロダクトアクションへ変えるときです。

Rivya での次のステップ

Developers を使って API の範囲を確認します。
本番コードを書く前に、Rivya API Quickstart を読んでください。
API key を保存する前に、API Authentication を読んでください。
次の問いがモデル、ファイル、chat、Webhooks の接続方法なら、Rivya API でマルチモーダル AI ワークフローを構築する方法を読んでください。
プロジェクトがまだ人主導の Studio 作業に属するなら、Rivya の Chat、Image、Video、Audio をどう行き来するかを使ってください。

Studio ではなく Rivya API を使うべきとき