?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 です。残高を確認する
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時間に終了したタスク数を加えて返します。