◉CLAUDE LABEN
●2.1.301 — vim の % モーション、VS Code パネルでの LaTeX 数式表示、使用量上限待ちのリトライ監視の上限が入りました(10/15)●2.1.299 — 200K トークン超で約54分放置した会話はアイドル圧縮。MCP の許可ルールは名指ししたサーバーだけに一致します●SONNET 4.5 — Claude API での提供終了は 11/30、残り45日。移行先は Sonnet 5.5●WINDOWS — 日本語の環境でだけフックが黙って壊れる報告があり、文字コードの確認が呼びかけられています●FAST MODE — Opus 5.5 の Fast mode がリサーチプレビューを終え、ベータヘッダーが不要になりました(10/15)●NEW — Cowork に渡したフォルダの先頭に、十行の約束ファイルを置いてみました●2.1.301 — vim の % モーション、VS Code パネルでの LaTeX 数式表示、使用量上限待ちのリトライ監視の上限が入りました(10/15)●2.1.299 — 200K トークン超で約54分放置した会話はアイドル圧縮。MCP の許可ルールは名指ししたサーバーだけに一致します●SONNET 4.5 — Claude API での提供終了は 11/30、残り45日。移行先は Sonnet 5.5●WINDOWS — 日本語の環境でだけフックが黙って壊れる報告があり、文字コードの確認が呼びかけられています●FAST MODE — Opus 5.5 の Fast mode がリサーチプレビューを終え、ベータヘッダーが不要になりました(10/15)●NEW — Cowork に渡したフォルダの先頭に、十行の約束ファイルを置いてみました
記事一覧/API & SDK
⬡ API & SDK/2026-07-03上級

同時リクエスト数はいくつまで持つのか — Little の法則と実測メモリで決める Claude API 本番デプロイのインフラ要件

同時リクエスト数・待ち行列長・メモリはいくつに設定すべきか。Claude API 本番デプロイのインフラ要件を Little の法則と実測ハーネスで数字から導く手順を、夜間バッチで OOM を踏んだ経験をもとに整理しました。

claude-api83deployment4infrastructure4capacity-planningstreaming16production87

✦ プレミアム記事

6月の最後の週、4サイト分の記事生成やリンク監査といった夜間バッチをひとつのプロセスに束ねる改修をしていたときのことです。処理を早く終わらせたくて Claude API 呼び出しの並列度を 8 から 24 に上げた途端、コンテナが落ちました。原因は 429 でもタイムアウトでもなく、メモリでした。レート制限の予算は何度も検算していたのに、ストリーミング接続 1 本がプロセス内でどれだけの資源を占有するかは、一度も測っていなかったのです。

Claude API の本番デプロイで「インフラ要件」を検討するとき、多くの方が最初にサーバースペックから考え始めます。けれどもモデルを動かすのは Anthropic 側(あるいは Bedrock / Vertex AI / Microsoft Foundry)であって、私たちのインフラではありません。私たちがサイジングすべきなのは「応答を待ち続ける側の資源」です。今回は、個人開発の夜間バッチと小規模な公開サービスの両方で使っている、同時実行数・待ち行列長・メモリを数字から導く手順を整理します。

サイジングするのは「モデルを動かす資源」ではなく「待ち続ける資源」

Claude を使うアプリケーションの統合レイヤーが本番で消費する資源は、突き詰めると次の 4 つに集約されます。

資源決める数字根拠になる入力
同時実行数同時に開いておく API 接続の上限到着率 λ と平均ストリーム時間 W(Little の法則)
レート制限予算RPM / 入力 TPM / 出力 TPM の消費見込み実効到着率 × 平均トークン量
メモリ接続 1 本あたりの RSS 増分 × 同時実行数実測(後述のハーネス)
待ち行列長受け付けてから処理開始まで待たせる件数の上限許容待ち時間 × 実効到着率

CPU はほとんど問題になりません。ストリーミングの受信処理は I/O 待ちが支配的で、私の環境では 24 本並列でも CPU 使用率は 1 コアの 15% 前後でした。倒れるとしたら、レート制限か、メモリか、待ち行列の設計不備のどれかです。

なお、トラフィック規模・SLA・データレジデンシーといった上流の判断軸はClaude API を本番投入する前に決めておくインフラ要件で整理しています。今回はその次の段階、決めた規模を具体的な設定値に落とす部分に絞ります。

Little の法則で必要同時実行数を出す

必要な同時実行数は、待ち行列理論の Little の法則でそのまま計算できます。

同時実行数 L = 到着率 λ(リクエスト/秒)× 平均滞在時間 W(秒)

ここで重要なのは、W が「最初の 1 文字が返るまでの時間(TTFB)」ではなく「ストリームを開いてから閉じるまでの全時間」だという点です。長文生成では、TTFB が 1 秒でもストリーム全体は 40 秒以上開きっぱなしになります。接続はその間ずっと占有されます。

私が運用している 2 つのワークロードで実際に計算してみます。

ワークロード到着率 λ平均ストリーム時間 W必要同時実行数 Lヘッドルーム込み(×1.5)
夜間バッチ(90 タスクを 30 分で消化)0.05 /秒42 秒(長文生成)2.1 本4 本
チャット UI(ピーク時)2.5 /秒12 秒30 本49 本
プッシュ通知直後のスパイク8 /秒(3 分間)12 秒96 本145 本

夜間バッチの答えが「4 本で足りる」なのは意外に感じられるかもしれません。私自身、束ね改修の前は「タスクが 90 個あるから並列度も高いほど速い」と思い込んで 24 本に上げ、冒頭の OOM を踏みました。到着率が低ければ、並列度を上げても待ち時間はほとんど縮まず、メモリ消費だけが増えます。逆にチャット UI は、RPM で見るとささやかでも同時接続では 49 本を要求します。この「RPM は小さいのに同時実行は大きい」という乖離が、次の節の主題です。

平均ストリーム時間 W を縮める打ち手(リージョン選定・接続プーリング・プロンプトキャッシュ)はClaude API のレイテンシを下げる4つのインフラ施策にまとめています。W が半分になれば、必要同時実行数もそのまま半分になります。

✦

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること
✦同時実行数を勘で決めていた人が、自分のログの到着率と平均ストリーム時間から Little の法則で必要値を導けるようになる
✦ストリーミング接続1本あたりの実測メモリを測るハーネスを手に入れ、429 より先に OOM で倒れる構成を本番前に見つけられる
✦レート制限・再試行増幅・待ち行列長を1つの計算機に統合し、インフラ要件を数字で説明して負荷テストで検証できるようになる
Stripe による安全な決済 · いつでもキャンセル可能
✦

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または
メンバーシップなら全記事が読み放題 →
シェア

お読みいただきありがとうございます

Claude Lab は広告なしで運営しており、サーバー費用などの運営コストはメンバーシップのご支援で賄っています。実装コード・ベンチマーク・本番設計パターンなど、実務でお役立ていただける記事を毎日更新しています。もし読んでよかったと感じていただけましたら、ぜひご覧ください。

  • ✦コピー&ペーストで使える実装コード付き
  • ✦毎日新しい上級ガイドを追加
  • ✦¥580/月 または ¥1,480 の永久アクセス
メンバーシップを見る →

関連記事

⬡ API & SDK2026-04-29
Claude API を本番投入する前に決めておくインフラ要件 — 規模・SLA・コンプライアンスから逆算する設計判断
プロトタイプは動いたが本番投入の判断基準が曖昧——そんな状態から、トラフィック規模の3段階見積もり、SLAから逆算する可用性設計、データレジデンシーとコンプライアンス、レート制限429の扱いまで、Claude APIのインフラ要件を実数値とチェックリストで決めていく手順を整理しました。
⬡ API & SDK2026-04-28
Claude API のレイテンシを下げる4つのインフラ施策 — モデルを変える前に試したい打ち手
Claude API の応答が遅いと感じたとき、モデル変更の前に効くインフラ施策があります。リージョン選定・HTTP接続再利用・プロンプトキャッシュ・ストリーミングの4点を、実装と計測の観点で整理しました。
⬡ API & SDK2026-05-26
Claude API の構造化レスポンスを本番で安定させる — tool_use と JSON Schema、多層検証の実装メモ
Claude API の応答を JSON で受け取る実装は数行で書けますが、本番運用では「形は正しいが意味が壊れている」レスポンスにどう備えるかが分かれ目になります。tool_use・JSON Schema・ドメイン検証を組み合わせた多層パイプラインを、壁紙アプリの分類処理での実体験を交えて整理しました。