トークンバケット計算機
容量10、残り5、毎秒2補充のバケットは、1.5秒後に8トークン使えるため、3トークンのバーストは通り、5が残ります。数値を入れると許可か拒否かと待ち時間が分かります。ブラウザで無料で使えます。
- 無料
- ブラウザで動作
- 登録不要
- データは端末の外に出ません
無料で実行
計算例
- 容量
- 10
- 補充レート
- 2
- トークン
- 5
- 経過時間
- 1.5
- リクエスト数
- 3
- 利用可能なトークン
- 8
- 残りのトークン
- 5
- 消費したトークン
- 3
- 不足分
- 0
容量でハードクランプしながら補充し、許可または拒否を決め、判定後の残トークンを返し、拒否時は十分に溜まるまでの待ち時間を計算します。容量超過や補充率ゼロで将来も満たせない場合はその旨を示します。
バケットが許可を判断する仕組み
トークンバケットは、決まった容量を超えないトークンの残高を持ちます。時間とともに一定の補充レートでトークンが増え、バーストが来るたびにその分のトークンを使います。判断の前にまず補充を行い、現在の残高に経過秒数×補充レートを足して、容量で上限をかけます。これが今すぐ使える量です。必要な量を満たせばバーストは許可され、その分が差し引かれます。例では、5トークンに1.5秒×毎秒2を足して8になり、3のバーストが通って5が残ります。経過時間は自分で入力するため、同じ値なら常に同じ答えになります。
役立つ場面とよくある間違い
ゲートウェイの割り当てや自作のレート制限を基準と照らし合わせたり、設計レビューで動きを説明したり、負荷シミュレーションを準備したりするときに使えます。特に、手書きの制限処理が間違えやすい境界の場面、つまり満杯のバケット、途中までの補充、上限より大きいバーストで役立ちます。よくある間違いは上限をかけ忘れることで、長い休止のあとに残高が際限なく増え、想定よりはるかに大きなバーストを許してしまいます。容量より大きいバーストを待てば通ると考えるのも誤りで、いくら待っても通らないことをこの計算ではっきり示します。
よくある質問
一定時間後に使えるトークンはいくつですか？
現在のトークンに経過秒数×補充レートを足し、容量で上限をかけます。5トークン、毎秒2、1.5秒経過なら、容量が足りる限り8トークンになります。
バーストが拒否されたらどれだけ待てばよいですか？
不足しているトークン数を補充レートで割った秒数を表示します。その時間がたてば、バーストに必要なトークンがバケットにそろいます。
どんな場合にバーストは決して許可されませんか？
必要なトークンが容量を超えるとき、または補充レートが0ですでに足りないときです。どちらの場合も、待ち時間ではなく、満たせないことをはっきり示します。
容量と補充レートは実際に何を表しますか？
容量は一度に許すバーストの最大量、つまり上限です。補充レートは毎秒のトークン数で、そのバーストを使い切ったあとに長く続けられる一定のペースを表します。
関連ツール
開発者向け — APIアクセス
このページの機能はすべてAPIからも利用できます。自社システムに組み込みたいチーム向けのセクションです。それ以外の方は上のツールをそのままお使いください。
エンドポイント
Bearerトークンで認証し、POST1回でタスクをキューに登録します。結果はWebhookまたは署名付きリンクで受け取れます。
お使いのスタックから呼び出す
curl -X POST https://api.kit.forhosting.com/dev/token-bucket \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"capacity":10,"refill_rate":2,"tokens":5,"elapsed":1.5,"request_count":3}'const res = await fetch("https://api.kit.forhosting.com/dev/token-bucket", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"capacity": 10,
"refill_rate": 2,
"tokens": 5,
"elapsed": 1.5,
"request_count": 3
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/dev/token-bucket",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"capacity": 10,
"refill_rate": 2,
"tokens": 5,
"elapsed": 1.5,
"request_count": 3
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev/token-bucket", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"capacity":10,"refill_rate":2,"tokens":5,"elapsed":1.5,"request_count":3}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"capacity":10,"refill_rate":2,"tokens":5,"elapsed":1.5,"request_count":3}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev/token-bucket", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)リクエスト例
{
"capacity": 10,
"refill_rate": 2,
"tokens": 5,
"elapsed": 1.5,
"request_count": 3
}レスポンス例
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.token_bucket",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}非同期APIです。task_idは即時に返ります。ポーリングは1秒あたり1リクエストまでです。
料金
単価はすべて公開しています。トークン換算や独自クレジットはありません。失敗したタスクは課金されません。
エラー
| HTTP | コード | 意味 |
|---|---|---|
401 | unauthorized | APIキーが無効か、指定されていません。Authorizationヘッダーを確認してください。 |
402 | insufficient_balance | 残高が不足しています。チャージ後に再度お試しください。 |
404 | unknown_type | 指定されたタスクタイプは存在しません。タイプ名を確認してください。 |
429 | rate_limited | リクエストが多すぎます。しばらく待ってから再度お試しください。 |
技術的な注記
トークンバケット方式のレート制限は、API のスロットリング、ゲートウェイのクォータ、クライアント側バックプレッシャーの標準モデルです。固定容量までトークンを保持し、一定速度で補充し、リクエストやバーストが来るとトークンを消費します。このトークンバケット レート制限計算機は、容量、毎秒の補充率、現在のトークン数、前回更新からの経過秒数、次のバーストに必要なトークン数を受け取ります。同じ純粋で決定的なモジュールが無料ブラウザツールと API 経路の両方を動かすため、設計レビュー、負荷試験スクリプト、本番シミュレータが、満杯のバケット、部分補充、バースト上限を超える要求といった境界条件で食い違うことはありません。
トークンバケットが許可／拒否を決める仕組み
トークンバケットは、容量を超えない非負のトークン残高を保持します。容量はバースト余裕です。検査のあいだ、トークンは elapsed 秒間に毎秒 refill_rate 個ずつ増え、その後 min(capacity, tokens + elapsed × refill_rate) でクランプされます。この値が tokens_available、つまりいま使える量です。request_count 個を要するバーストは、tokens_available が request_count 以上のとき許可されます。許可時は tokens_remaining が tokens_available から request_count を引いた値になり、tokens_consumed は request_count と等しくなります。拒否時はトークンを消費せず、tokens_remaining は tokens_available のまま、tokens_consumed は 0、deficit は request_count から tokens_available を引いた値です。補充が正で要求が容量以下なら待ち時間は deficit / refill_rate、それ以外は後からも満たせません（can_satisfy は false）。これはバースト上限を超えるコストと、補充ゼロで凍ったバケットの両方を表します。補充が遅くても満杯の 10 なら 10 トークンの一発は通るため、ゲートウェイはピークに capacity、平均に refill_rate を選びます。
入力契約、応答フィールド、検証エラー
capacity は 0 より大きく、補充後に保持できる最大トークン数です。0 なら空になったあと回復しません。elapsed は前回更新からの秒数で非負。有限な数値を 5 つ必須とする JSON 本文を POST します。refill_rate は 0 以上で、単位は毎秒のトークン数。tokens は今回の elapsed を適用する前の残高で非負。capacity 超の値も受け付け、補充後の tokens_available 計算時にクランプします。request_count はこのバーストが必要とするトークン数で 0 より大きくなければなりません。欠落、非数値文字列、NaN、Infinity、範囲外の符号は invalid_input でフィールド名付きで失敗し、課金されません。成功時は 5 入力をエコーし、補充後の tokens_available、真偽の allowed、消費判定後の tokens_remaining、tokens_consumed、deficit、wait_seconds（許可時または永久不可時は 0）、can_satisfy、更新規則を短く記した formula を返します。例：capacity 10、refill_rate 毎秒 2、tokens 5、elapsed 1.5、request_count 3 なら tokens_available は 8（5 に補充 3、容量未満）、allowed true、tokens_remaining 5、wait_seconds 0。同じ available 8 で 9 を要求する 2 回目は deficit 1、毎秒 2 なので wait_seconds は 0.5 で拒否されます。
トークンバケット計算機が役立つ場面
エッジ／ゲートウェイ実装者は Redis やインメモリのバケットを書くとき、この計算機をオラクルとして同じ入力での閉形式結果と比較します。教育や SRE 面接では、トークンバケットが純粋なリーキーバケットと違い、容量までバーストを許し、その後なだらかな補充で余力を戻すことを示せます。検証失敗は残高を消費しません。API プロダクトチームはクォータ公開前に capacity と補充を寸法決めし、候補値とサンプル バーストで正当なスパイクが通り、乱用の洪水が待つかを確認します。負荷試験ハーネスやカオススクリプトは同じ純粋エンドポイントを呼び、wait_seconds に従う合成クライアントが文書化された上限を超えて消費しないことを断言します。実装は純粋な parse ティア A のため、成功した呼び出しは公開の基本価格 $0.002 のみで、モデル トークンも外向きネットワークも使いません。リクエストを小さく保ち、丸め済み数値をテストに固定すれば、本格的なレート制限サービスを立てずに設計資料・SDK 例・本番ドライラン向けの再現可能な許可と待ち時間を得られます。
連携の活用例
API クォータとバースト寸法決め
現実的な request_count バーストに対して capacity と refill_rate を調整し、正当なスパイクを許しつつ持続トラフィックを抑えます。
負荷試験とクライアント バックオフのオラクル
返却された wait_seconds で合成クライアントを駆動し、並行シナリオでも文書化されたトークンバケット契約を超えないことを確認します。
ゲートウェイ実装の突き合わせ
Redis やプロセス内バケットの状態機械を、同じ capacity・補充・tokens・elapsed・コスト入力でこの決定的計算機と比較します。
技術的な質問
トークンバケット レート制限計算機の動作は？
tokens_available = min(capacity, tokens + elapsed × refill_rate) を求め、その値が request_count 以上ならバーストを許可して減算し、そうでなければ deficit と、補充がコストを賄える場合の wait_seconds = deficit / refill_rate を返します。
refill_rate と elapsed の単位は何を使えばよいですか？
両方とも同じ時間単位にしてください。refill_rate は毎秒のトークン数、elapsed は秒です。ミリ秒に揃える場合も一貫性が必要で、API は単位変換を行いません。
request_count が capacity より大きいとどうなりますか？
can_satisfy false と wait_seconds 0 で拒否されます。バケットが保持できる量を超える単一要求は、満杯に補充しても通りません。
入力の tokens は capacity より大きくできますか？
できます。非負で capacity を超える tokens を受け付け、elapsed 補充の適用後にだけクランプします。次の更新まで未クランプのカウンタを持つ実装と揃えています。
トークンバケット計算機の料金は？
ブラウザツールは無料です。API リクエストは成功呼び出しごとに前払い KIT 残高から $0.002、無効入力は課金されません。