メインコンテンツへスキップ
すべてのタスクにはクレジット単位の料金があります。料金は送信時に確保され、タスクが完了すると請求され、失敗すると解放されます。同時に待機中または実行中にできるタスク数はプランで決まります。 エンジンと料金の最新の一覧は、公開のcapabilitiesエンドポイントで取得できます。APIキーは不要です。
?taskType=GEMINI を付けると1つのエンジンを読み取れます。GOOGLE_AIO などのエイリアスも受け付けます。capabilitiesの取得を参照してください。

タスクごとのクレジット

料金はプランによって変わりません。変わるのは1クレジットあたりの金額です。クレジットは 1.25 のように小数点以下2桁まで持てます。

Citation Analysisの従量課金

CITATION_ANALYSIS タスクは、送信時に 20 + 12 × citations + 80 × ⌈answer characters ÷ 1,000⌉ クレジットを確保します。完了時には 1 + ⌈input tokens ÷ 500⌉ + ⌈output tokens ÷ 100⌉ + 2 × source fetches が請求され、確保額を超えることはありません。確保額の残りは解放されます。Citation Analysisを参照してください。

確保、請求、解放

1

送信: 確保

タスクの料金(WEB_CRAWL、GEO_SCORE、CITATION_ANALYSIS は最大額)が、利用可能な残高から確保分に移ります。残高で賄えない場合、送信は 402 INSUFFICIENT_CREDITS を返します。送信のレスポンスの credits は 0 です。
2

完了: 請求

確保分から請求されます。終了後のポーリングとWebhookでは creditsCharged に表示されます。
3

失敗: 解放

確保分は残高に戻ります。失敗したタスクの料金は 0 です。
新しいアカウントには登録時に500クレジットが付与されます。

残高を確認する

GET /v1/credits はアカウントのクレジットを返します。取得にクレジットはかからないため、バッチを送る前に毎回確認できます。クレジット残高を参照してください。
  • remaining は今使えるクレジットです。送信済みのタスクの料金は reserved に確保されているので、改めて差し引かないでください。
  • perCycle はプランがサイクルごとに付与するクレジット、cycleResetsAt は現在のサイクルが終わる日時です。有効なプランがない場合はどちらも null です。
  • topUpBalance は remaining に含まれる追加クレジットと、そのうち次に失効する日時と量を示します。追加クレジットがない場合は null です。追加クレジットは購入から3か月有効で、更新後も繰り越され、プランのクレジットを使い切ってから使われます。
サブアカウントはあなたのクレジットを使うため、サブアカウントのキーには 403 SUB_ACCOUNT_FORBIDDEN が返ります。サブアカウントを参照してください。

使用量を確認する

GET /v1/usage は、UTCの日付範囲でアカウントに請求されたクレジットを、日・エンジン・APIキー別に分けて返します。取得にクレジットはかかりません。クレジット使用量を参照してください。
  • from と to はUTCの日付で、両方の日を含みます。既定値は今月(UTC)の初日と今日で、範囲は最大366日です。
  • groupBy は day、engine、key をカンマ区切りで受け付け、既定値は day,engine です。行には選んだ分け方のフィールドが入り、請求のない組み合わせの行はありません。先頭の credits と tasks は全行の合計です。
  • groupBy=key はクレジットを使った主体を示します。APIキーで送ったタスクは "source": "api" で、キーの id、keyPrefix、name、subAccountId を持つ apiKey が付きます。APIキーを使わない消費は source が monitor(モニターの実行)、playground、dashboard のいずれかで、apiKey は null です。
  • 使用量はタスクに請求されたクレジットの合計で、失敗したタスクは 0 です。モニターの競合読み取りはタスクなしで請求されるため、残高は減りますが使用量には現れません。
  • サブアカウントのタスクもあなたの使用量に含まれ、apiKey.subAccountId がキーを持つサブアカウントを示します。サブアカウント1つは GET /v1/sub-accounts/{id}/usage で読みます。サブアカウントのキーには 403 SUB_ACCOUNT_FORBIDDEN が返ります。

キューを確認する

GET /v1/async/status は、待機中と実行中のタスクを、それらが数えられる同時実行数の上限とあわせて返します。取得にクレジットはかかりません。キューの状態を参照してください。
  • concurrency.used は queuedTasks と processingTasks の合計で、プランの同時実行数の上限が合わせて数える2つの値です。max がその上限なので、max - used が新しいタスクを入れられる余裕です。
  • priorityBreakdown は、待機中のタスクを送信時の priority ごとに、値の大きい順に並べます。
  • 件数には、上限を共有するサブアカウントのタスクも含まれます。サブアカウントのキーには 403 SUB_ACCOUNT_FORBIDDEN が返り、自分のタスク件数は GET /stats で読みます。

プラン

プランの比較は料金ページをご覧ください。

プランの同時実行数

同時実行の上限は、アカウントの QUEUED と PROCESSING のタスクを合わせて数えます。送信の速さを制限するものではありません。上限を超える送信は、details.limit、details.active、Retry-After 付きの 429 PLAN_CONCURRENCY_LIMIT を返します。契約によってアカウントに別の上限を設定でき、親アカウントはサブアカウントに上限を設定できます。

キーとサブアカウントの上限

キーの1日の上限はタスクに必要な確保額で数えるため、used + price が上限を超える場合にタスクは拒否されます。

リクエストレートとバックプレッシャー

エッジの 429 はAPIより手前で返るため、JSONのエラーエンベロープも Retry-After も付きません。受け取ったら指数的に間隔を空けてください。タスク送信エンドポイントからの 429 と 503 には、秒単位の Retry-After ヘッダーが付きます。コードと再試行の方針はエラーに記載しています。

大量の送信のペース配分

1

ループせずバッチにする

500項目の POST /v1/async/task/batch 1回は、エッジの上限に対して1リクエストです。同時実行の上限を超える量には POST /v1/batches を使ってください。サーバーが空きができ次第項目を投入します。バッチとグリッドを参照してください。
2

Retry-After に従う

拒否されたタスクを再送信する前に、Retry-After の秒数だけ待ってください。同じ idempotencyKey を再利用すれば、再試行で重複が作られることはありません。
3

依存する処理を順に送る

実行順序は保証されません。結果に依存する処理は、タスクが完了するのを待ってから送信してください。
4

件数を監視する

GET /v1/async/status は待機中と実行中のタスクをプランの上限とあわせて返すため、上限内に収めるのに使えます。GET /stats は過去24時間に終了したタスク数を加えて返します。