同期 API の非同期ジョブ化やレート制限・worker 容量の設計では、リクエスト総量をそのまま設計インプットにせず、まずトラフィックをクライアント種別（自動化クライアント / 対話ユーザー）で分解する。実測した事例では、提供中の連携ツール由来の自動化トラフィックが全体の約9割を占め、深夜の定期実行ピークが総量の見かけを支配していた。分解せずに総量ピークで worker 台数を決めると、対話ユーザーには過剰で、自動化クライアントの移行判断は未決のまま、という設計になる。

計測の作法

• 総量はサンプリングされない APM メトリクスで取り、クライアント種別・利用者別の内訳はタグ付きの保持スパンで取る。メトリクス側に種別タグが無い場合は、保持スパンの構成比を総量に掛けて推計する（推計であることを明記する）。
• 「時間帯で機械トラフィックを除外できるか」を先に確認する。自動化クライアントは深夜ピーク以外に日中も流れていることが多く、時間帯で分離できない場合はヘッダーやクライアント識別子による判定が必要になる。

設計判断への反映

• 対話ユーザー向け非同期基盤の容量は、対話ユーザー分のピーク到着率×平均処理時間÷目標稼働率で決める。自動化クライアント分を混ぜると必要台数が数倍〜桁で変わるため、混ぜて計算しない。
• 同期 API を非同期 API に置き換えるとき、支配的な自動化クライアントが同期 API に依存しているなら、同期エンドポイントの即時削除は破壊的変更になる。クライアントの配布・更新サイクルを自分で制御できない場合は特に、同期経路を残した段階移行にする。
• 自動化クライアントを非同期基盤に乗せる場合は、対話ユーザーと同一キュー・同一 worker 枠に相乗りさせず、専用レーンや公平性機構を前提にする（短時間ジョブの開始待ちを防ぐ既存原則に接続）。
• 同期 API で多発していたレート制限拒否（429）は、非同期化後は「安価な task 作成の大量投入」に化ける。テナントまたはクライアント単位の同時実行 task 数上限を作成時かデキュー時に設けてから移行する。
• ポーリング型の非同期 API は自動化クライアントにとって実装コスト増になるため、用途が実質データ同期なら、CSV 生成の非同期化ではなく専用のデータ取得経路を比較対象に含める。

検証

自動化クライアント分を除いた到着率で必要並列数を再計算し、総量ベースの計算と何台差になるかを明示する。差が大きいほど、分解と段階移行の価値が高い。