Replicate AIの使い方と料金：API連携から本番運用まで

2026年11月5日にReplicateの公開中の料金ページとドキュメントで確認しました。評価は、文書化された仕様と料金の計算例に基づきます。

Replicate AIとは何ですか？

Replicateは、入力を受け取り結果を返すプログラムである「モデル」を、自社が管理するインフラ上で実行します。アプリからプロンプトやファイルなど、そのモデルが求める入力を送ると、Replicateは1回の実行を意味する**prediction（予測）**を作成し、結果、または後から状態を確認できるジョブIDを返します。カタログにはオープンソースモデルと独自ライセンスのモデルが混在しており、Replicateで使えることとオープンソースであることは同義ではありません。現在、ReplicateはCloudflareの傘下です。Replicateの2025年11月の発表ではブランドとAPIの継続が示され、Cloudflareの買収完了の発表で、2025年12月1日に正式にCloudflareの一員となったことが確認されています。ただし、傘下入りしたからといって、すべてのモデルがエッジで動作するわけではありません。利用するエンドポイントのドキュメントに記載された機能を基準に選んでください。

Replicateが向いている人・別の選択肢を検討したい人

Replicateは、ユーザー管理、ジョブ管理、ファイル処理の仕組みがある製品に、学習済みモデルを実行する「推論」を組み込みたい開発者に適しています。SaaSアプリの画像生成機能、非同期の動画エディター、独自の画像分類器などがその例です。GPUサーバーの運用は任せられますが、製品のワークフローと、どの出力を採用するかの判断は自分で担います。

候補となるサービスは、デプロイする処理によって変わります。次の比較は用途に基づく判断であり、実測速度のランキングではありません。

独自のGPUアプリケーションと実行環境をPythonで定義したい場合は、Modalがより適しています。コードで実行環境を定義する仕組みにより、アプリケーション単位で細かく制御できますが、自分で管理する配信コードも増えます。その選択に伴う費用はModalの料金で確認できます。

fal AIとReplicateはどう選びますか？

生成メディアが中心の製品では、まずfalを比較対象にするとよいでしょう。同じアプリでコミュニティモデルや自分でパッケージ化したモデルも使うなら、Replicateが有力候補です。どちらにも目的のモデルがある場合は、そのエンドポイントの入力オプション、出力単位、運用上の制御、データポリシーを比較してください。プラットフォーム全体をひとくくりにして「常に速い」「常に安い」と判断しても、購入の基準にはなりません。

すでに継続的なハードウェア容量の購入が主な論点になっているなら、モデルカタログを起点に選ぶ段階は過ぎています。次の選択はGPUクラウドプロバイダーの比較で扱っています。また、技術者ではない担当者が完成済みのサポートエージェントや動画編集アプリを求めているなら、そのアプリを購入するほうが適切です。モデルのエンドポイントだけでは、製品として実装すべき部分が多く残ります。

Replicateの使い方：モデル選定からAPI呼び出しまで

Replicateなら小さな実装で連携を始められます。ただし、アプリが何を送り、何を受け取るかは、受け付ける入力と返されるフィールドを定めたモデル固有のAPIスキーマによって決まります。

公式モデルとコミュニティモデルの違い

Replicateでは、公式モデルとコミュニティモデルを区別しています。公式モデルのドキュメントでは、常時ウォーム状態のインスタンス、安定した入出力API、継続的なメンテナンス、予測しやすい入力または出力ベースの課金を約束しています。公式モデルは、バージョン識別子を指定せずにオーナー名とモデル名で呼び出せます。

一方、コミュニティモデルのドキュメントでは別の条件が示されています。API呼び出しには特定のバージョンを指定し、課金は一般にハードウェアの稼働時間に基づきます。利用頻度が低いモデルではコールドブートが起きることもあります。バージョン固定は、パッケージの特定のリビジョンを指定するという意味であり、モデル間でライセンスや入力フィールドが共通になるわけではありません。

製品に組み込む場合は、連携コードを書く前にモデルを選びます。ライセンス、対応ファイル形式、必須パラメーター、出力形式、課金単位を確認してください。画像モデルのリクエスト例をコピーして名前だけ音声モデルに変えても、入力が異なるため十分ではありません。

Replicateの画像生成APIを使うには？

Replicateでは、モデルごとのエンドポイントを通じて画像を生成します。たとえばBlack Forest Labs FLUX Schnellはテキストプロンプトを受け取り、生成画像を返します。コンセプト画像の生成機能を追加するなら、まずブラウザー画面で入力を選び、同じスキーマをバックエンドから利用できます。

アカウントでAPIトークンを作成し、バックエンドの環境変数REPLICATE_API_TOKENに設定します。トークンのドキュメントでは、トークンをパスワードとして扱うよう求めています。ブラウザーに配信するコードには含めず、環境ごとに別のトークンを使ってください。

環境変数を設定すれば、次のHTTPリクエストを実行できます。実行には自分のReplicateアカウントが使われ、モデルの利用料金が発生する場合があります。

curl --fail-with-body --silent --show-error \
  https://api.replicate.com/v1/models/black-forest-labs/flux-schnell/predictions \
  --request POST \
  --header "Authorization: Bearer $REPLICATE_API_TOKEN" \
  --header "Content-Type: application/json" \
  --header "Prefer: wait" \
  --data '{"input":{"prompt":"A matte ceramic teapot on a wooden kitchen table","num_outputs":1}}' \
  > prediction.json

レスポンスはpredictionオブジェクトです。HTTPリクエストが成功しただけで生成完了と判断せず、status、output、errorを確認します。prediction作成のドキュメントでは、Prefer: waitを指定した場合のデフォルトの待機時間は60秒とされています。これはリクエストの待機設定であり、処理時間の保証ではありません。まだ完了していなければ、startingまたはprocessing状態のpredictionと、後から確認するためのurls.getアドレスが返ります。

Prefer: waitを外すと、デフォルトの非同期動作になります。完了を待たずにジョブIDが返されます。公式モデル、コミュニティモデル、デプロイでは作成用のルートが異なり、HTTP APIリファレンスに記載されています。選んだモデルやデプロイ用に生成されたサンプルを使ってください。

動画・音声・テキストをバックグラウンドで処理する

時間のかかるジョブでは、アプリ側にジョブの記録を残し、送信後に結果を回収する構成が適しています。サーバーへのHTTP通知であるwebhookを使えば、リクエストを開いたままユーザーを待たせずに、完了に応じて処理を進められます。

顧客が承認した台本を、イラスト付きの短い動画にする製品を考えてみます。メディアを生成し、顧客のジョブにprediction IDをひも付け、完成したファイルを回収してから成果物を組み立てます。webhookのドキュメントでは、predictionデータの保存や、あるモデルの出力を別のモデルへ渡す使い方が明示されています。処理全体の制御と、顧客に示す最終的なジョブ状態は、アプリ側の責任です。

動画では、まずテキストから動画を生成するモデルのコレクションを確認し、選んだモデルのAPIを調べます。テキストから動画を作るモデルと、画像から動画を作るモデルでは、最初に必要な素材が異なります。失敗や期待に届かなかった結果を後から調べられるよう、使用したモデルと入力をジョブとともに保存してください。

Replicateで音声を生成するには？

Replicateのテキスト読み上げコレクションには、文章を音声に変換するモデルがあります。製品の操作説明にナレーションを付けるなら、台本に合う言語と音声の制御機能を備えたモデルを選び、音声を生成してジョブのほかのファイルと一緒に保存します。音声モデルがあるというだけで、対話型の電話通話にも適しているとは判断できません。実際のアプリで、選んだエンドポイントの応答動作を評価する必要があります。

Replicateは、テキストを生成・解釈する大規模言語モデルも提供しており、言語モデルのコレクションから探せます。ナレーションの下書きや受信した依頼の分類に使い、出力を検証してから次の工程へ渡します。途中の不適切な出力がそのまま顧客向けの完成品にならないよう、台本のレビューと最終的な組み立てはアプリのワークフローに残してください。

Cogで独自モデルをデプロイする

公開カタログに必要な処理がない場合、Replicateで自分の学習済みモデルを配信できます。Cogは、コード、依存関係、モデルの重みを、再現可能なソフトウェア実行環境であるコンテナにまとめるオープンソースのツールです。

たとえば、既存の商品画像分類器を持つ小売企業なら、それをパッケージ化してプライベートAPIとして公開できます。これは、すでにあるモデルをデプロイするための手順です。フォルダーをアップロードするだけで、役立つ分類器が学習されるわけではありません。

独自モデルのデプロイガイドとCogのプッシュガイドでは、次の流れが示されています。

実務上の壁は、パッケージの管理責任が自分に残ることです。GPUクラスターの運用は不要になっても、動作する推論コード、互換性のある依存関係、適切なハードウェア、有用な結果を返すモデルは必要です。モデルが選択したマシン以上のメモリを必要とするなら、APIで包んでもその要件はなくなりません。

デプロイで処理容量を管理する

Replicateのデプロイでは、専用エンドポイントを使い、ハードウェアとスケーリングを制御できます。モデルが製品に不可欠になり、共有キューでは運用要件を満たせなくなったときに意味を持ちます。

デプロイのドキュメントでは、インスタンス数の最小値と最大値、ゼロへのスケールダウン、監視、バージョンのローリング更新が説明されています。インスタンスとは、モデルを実行する1つのコピーです。最小値を1にすると利用可能なコピーを維持し、0にすると未使用の処理容量を停止できます。1つをウォーム状態に保つだけで、どれだけ大きなアクセス急増にも追加容量なしで対応できるわけではありません。

顧客向けの画像分類器なら、応答性の要件に合わせて最小値を決め、支払える容量に合わせて最大値を決めます。エラーとリクエストの遅延に加え、稼働中、アイドル、起動中のインスタンスを監視します。1日の大半をアイドル状態で過ごすなら、容量設定を費用見直しの対象にしてください。繰り返し最大値に達するなら、APIのリトライを増やしても、設定済みの処理容量は増えません。

Replicateの料金はどう決まりますか？

Replicateは従量課金で、課金単位はモデルごとに決まります。公開中の料金ページによると、ハードウェアと時間で課金するモデルもあれば、入力と出力で課金するモデルもあります。プラットフォーム全体を表す一律のリクエスト単価はありません。

以下は公表されている料金例です。これらが最新モデルである、あるいは対象の用途に最適であるという意味ではありません。

小規模な開発では、必要な出力と課金単位に合った公開モデルから始めるのが合理的です。時間課金の公開モデルでは、リクエストを処理した時間に料金がかかり、セットアップとアイドル時間は無料です。**デプロイと大半のプライベートモデルでは境界が変わり、セットアップ、稼働中、アイドルのインスタンス時間が課金されます。**プライベートモデルの例外として文書化されているのは、高速起動のファインチューニングモデルとして表示されたもので、実際の処理時間だけが課金対象になります。

請求のドキュメントでは、前払いアカウントと後払いアカウントも区別されています。前払いでは利用額がクレジットから差し引かれ、後払いでは月初に前月の利用分が請求されます。

計算例を見ると、この違いが分かります。記載の出力単価なら、FLUX Schnellで月に10,000枚を出力すると$30です。ほかのサービスの費用や追加で生成した画像は含みません。一方、T4を1台、30日間の月に常時稼働させると$583.20になります。720時間に$0.81を掛けた金額で、スケールアウトした追加インスタンスは含みません。この2つは購入の仕組みが異なる例であり、T4で画像サービスと同じ出力や処理量を再現できると示すベンチマークではありません。

原則として、失敗した実行には課金されません。ただし請求ドキュメントでは、稼働中のプライベートモデルとデプロイのインスタンス、時間課金モデルのキャンセル前に消費した時間、公式モデルで発生し得るキャンセル料金は課金対象として残ります。ほかのモデルを呼び出すモデルでは、全体の実行が失敗しても、呼び出し先の料金が発生する場合があります。実際に動かすワークフロー全体で費用を見積もってください。

本番導入の判断を左右する制約

Replicateを使えば、最初の連携でGPUを運用する必要はありません。それでも、ドキュメントにはアプリ側で対応すべき具体的な制約が示されています。

コールドスタートと共有の処理容量

Replicateは、コールドスタートをコールドブートと呼んでいます。リクエストを処理する前に、モデルの環境と重みを読み込む必要がある状態です。プラットフォームの仕組みの説明によると、人気のある公開モデルは継続的な利用によってウォーム状態に保たれることが多く、利用が少ないモデルほどコールドブートに遭遇しやすくなります。公式モデルには、前述の常時ウォームという別の約束があります。

つまり、利用頻度の低いコミュニティモデルを対話的な機能に使うなら、待機中の状態を用意するか、デプロイで処理容量を維持する必要があります。バックグラウンドのバッチ処理と、結果をその場で待つユーザーとでは、起動待ちの許容度が異なります。対象モデルと処理内容の評価を、全モデル共通の遅延数値で代用することはできません。

クレジット残高が減るとレート制限が厳しくなる

レート制限のドキュメントでは、prediction作成は毎分600リクエスト、その他のエンドポイントは毎分3,000リクエストと定められています。短時間ならデフォルト値を超えるバーストが可能です。制限時にはHTTP 429が返り、上限の引き上げにはReplicateへの連絡が必要です。これはAPIリクエストの上限であり、毎分それだけのジョブが完了する保証ではありません。

見落としやすいのがアカウント残高による制約です。Replicateはクレジットが減るとレート制限を厳しくし、自動チャージによって残高を**$20より多く**保つことを推奨しています。付与されたクレジットを使い、支払い方法を登録していないアカウントには、毎秒1リクエスト、かつ毎分6リクエストまでという別の制限があります。

そのため、開発チームがデプロイ設定を変えていなくても、請求状態が原因でキューの進行が遅くなることがあります。リクエストエラーと一緒にクレジット残高を監視し、制限時にはバックオフ付きの回数を限定したリトライを使ってください。過度なポーリングで、その他のエンドポイントの枠を消費しないことも大切です。

APIとブラウザーではデータの保存期間が異なる

データ保持のドキュメントによると、APIのpredictionの入力パラメーター、出力値、出力ファイル、ログは、デフォルトで1時間後に削除されます。必要なデータは、削除される前にアプリ側で保存しなければなりません。返されたファイルURLは、恒久的なアセット保存先ではありません。

ブラウザーで作成したpredictionのデータは、無期限に保持されます。ウェブサイトのDelete操作で、predictionとそれに関連する出力データおよびファイルを削除できます。ブラウザーでの試用とAPI連携では保持の動作が異なるため、一方の挙動からもう一方を推測しないでください。

本番のワークフローでは、完成したメディアを自分で管理するストレージに保存し、サポートに必要なモデル、入力、ジョブ状態を保持します。モデルの公開範囲は別の問題です。独自モデルを非公開にするとアクセスできる相手を制御できますが、それだけで別の保持条件が適用されるわけではありません。また、保持期間のページだけでは、学習利用、データの保存地域、契約上のあらゆるデータ取り扱い要件について包括的に断言する根拠にはなりません。

モデルの選定はアプリ側の責任です

Replicateのカタログは、モデルを配布・実行するための層です。商用利用の許可は選んだモデルのライセンスに依存し、コミュニティモデルのスキーマもそれぞれ異なります。モデルの変更はアプリの変更として扱い、本番トラフィックを切り替える前に、入力検証、出力ファイル、利用許諾、費用を確認してください。共通のプラットフォーム上にあるからといって、どのモデルもそのまま交換できるわけではありません。

評価：公開モデルから始め、理由が明確になったら専用容量へ

モデルの周辺に構築する機能こそが製品の価値であり、GPU運用を省くことで早く提供できるなら、Replicateは有力な選択肢です。まずは用途に合った公開エンドポイントから始めましょう。公式モデルの可用性、安定したインターフェース、課金単位が要件に合うなら、それを優先するのがよいでしょう。

デプロイへ移るのは、独自の推論コード、ハードウェアの制御、専用の処理容量、顧客向け機能のためのウォームインスタンスなど、理由を具体的に挙げられるときです。その判断には、セットアップとアイドル時間の料金も織り込みます。中心となる要件がメディア専用のカタログ、言語モデルの配信、Hubベースのデプロイ、より広範なPython計算アプリケーションなら、前述の代替サービスから候補を絞ってください。

最初の実装で目指すのは、ジョブを最後まで完結させることです。送信し、完了を検知し、出力を保存し、費用を把握します。その後で初めて、公開エンドポイントと専用デプロイのどちらを本番に採用するかを判断します。

Replicateについてよくある質問

機能の導入を決める前に、AI業務ワークフローの監査チェックリストで、モデルの周辺に必要な作業を整理してください。