連携方法の比較
runwareとAPIの比較は、プラットフォームとAPIのどちらを選ぶかという話ではありません。RunwareもAPIアクセスを提供しています。比較すべきなのは、Runwareを経由して連携する方法と、各モデルプロバイダーのAPIに直接接続する方法です。最適な方法は、必要なモデルと、どこまで連携作業を自分たちで担いたいかによって決まります。
runwareとAPIのどちらを選ぶか判断する際は、アプリケーションに必要なモデル、エンドポイント、利用条件を比較してください。どちらかがすべての項目で優れているわけではありません。今は接続が簡単でも、必要なモデルが変われば別の作業が必要になる場合があります。
連携する対象
Runware経由
Runwareのドキュメントに記載されたAPIと、Runwareで利用できるモデル。
プロバイダーのAPIに直接接続
選択したプロバイダーのAPI。そのプロバイダーのドキュメントと仕様に従って利用します。
モデルの選択
Runware経由
必要な各モデルがRunwareで利用でき、必要な操作に対応しているか確認します。
プロバイダーのAPIを直接利用
プロバイダーのカタログを直接確認します。通常、2つ目のプロバイダーを追加するには別の連携が必要です。
リクエストの設計
Runware経由
アプリケーションの入力をRunwareがサポートするパラメーターに対応付け、レスポンスを処理します。
プロバイダーのAPIを直接利用
入力をプロバイダー固有のパラメーターに対応付けます。他では提供されていない機能を利用できる場合があります。
プロバイダー固有の機能
Runware経由
本番環境で利用する前に、その機能が提供されていることを確認します。
プロバイダーのAPIを直接利用
その機能が利用可能であれば、プロバイダーが公開するインターフェースを使用します。
運用上の責任範囲
Runware経由
アプリケーションの検証、エラー処理、監視、ユーザー向けの動作については、引き続き自社で責任を負います。
プロバイダーのAPIを直接利用
これらの作業に加え、個別に連携したプロバイダー間で必要な調整も自社で担います。
後からの切り替え
Runware経由
プラットフォームアダプターを使えば、Runware固有のリクエストとレスポンスの詳細を分離できます。
プロバイダーのAPIを直接利用
プロバイダーアダプターを使えば、そのAPI固有の詳細を分離できますが、他のプロバイダーにはそれぞれ個別の対応付けが必要です。
判断前の確認事項
Runware経由
実際の利用状況を反映したテストで、モデルの対応範囲、利用可能な制御項目、利用条件、実際の出力を確認します。
プロバイダーのAPIに直接接続
同じ要件をプロバイダーのAPIでも確認し、アプリケーション全体の動作フローをテストします。
APIという言葉はインターフェースを指し、競合する製品カテゴリーを指すものではありません。この比較でRunwareを一方の選択肢とするのは、もう一方がモデルプロバイダーへの直接接続を意味する場合に限られます。
利用可能なモデルと制御機能が、アプリケーションで行う処理に合っている場合は、この方法を検討してください。
特定のプロバイダー固有の機能が製品の中核となる場合は、この方法を検討してください。
一方のAPIが優れているという一般論ではなく、具体的なワークロードに基づいて選んでください。実装を比較する前に、必要なモデル、制御機能、障害時の動作を書き出しましょう。
次の場合に選択
まずRunware経由で試してください。
小規模なアダプターを構築し、実際に必要なモデルで代表的なプロンプトを実行します。モデルが利用可能というだけで適合すると判断せず、出力品質、パラメーターのサポート、エラー処理を確認してください。
次の場合に選択
そのプロバイダーのAPIを直接テストしてください。
その機能を使う実際のリクエストから始め、ドキュメントに記載された制限とレスポンスの動作を確認してください。直接連携すれば、別のインターフェースが同じ制御機能を公開しているかどうかに依存せずに済みます。
次の場合に選択
切り替える前に、現在の接続を維持したまま内部アダプターを導入してください。
アプリケーションの入出力を、プロバイダー固有のフィールドから分離してください。そうすれば、すべての呼び出し元を一度に移行させることなく、同じテストケースで実装を比較できます。
連携を変更する前に、Runwareが何かを確認し、モデルに関する疑問を調べ、実装ガイドを確認してください。以下の関連ページは判断の参考になりますが、最終的には独自のテストで選択を決めてください。
実際のアプリケーションタスクを1つ選び、プロバイダーに依存しないリクエストを定義します。次に、現在のAPIと評価したい経路それぞれにアダプターを構築します。同じ入力を使って、出力、利用可能な制御機能、エラー、運用要件を比較してください。選択肢を検討する中で別のAIプラットフォームも調べたい場合は、パートナーリンクをご覧ください。採用する前に、そのモデル、ドキュメント、利用規約を独自に確認してください。
AIモデルを探すRunwareはAPIアクセスを提供しているため、この2つは相反するものではありません。この比較でいう代替手段は、個々のモデルプロバイダーのAPIに直接接続することです。アプリケーションに必要な具体的なエンドポイントと機能を比較してください。
必要なモデルと制御機能がRunwareのインターフェースで利用でき、その連携方法がアプリケーションに適している場合は、Runwareを検討してください。決める前に実際のリクエストをテストしましょう。そのプロバイダー固有の機能が不可欠な場合は、プロバイダーのネイティブAPIの方が適している可能性があります。
そうとは限りません。2つのルートで同じモデルを利用できても、リクエストのフィールド、対応する設定、レスポンス、エラーは異なる場合があります。内部アダプターを使えば、アプリケーションの共通の入力を各ルートのドキュメントに記載された形式に変換できます。
アプリケーションの代表的なタスクを選び、必要な出力を定義します。同じ入力を使って各ルートの小規模なテストを実装し、結果、対応するパラメーター、エラー処理を確認してください。評価の際には、最新のドキュメントと利用規約も確認してください。
いいえ。アプリケーションでは引き続き、入力の検証、失敗したレスポンスの処理、ユーザーへのエラーの通知が必要です。どちらのルートを選ぶ場合も、最初のレスポンスだけで連携全体を判断せず、生成の成功と併せてこれらの動作もテストしてください。