制限値（ダウンロード件数上限など）の限界を見極めたいとき、本番の固定定数をいきなり書き換えて恒久的に上げるのではなく、環境変数で上限を一時的に可変化して preview / staging で段階的に負荷計測する。本番の恒久変更と実測を分離するのが事故を防ぐコツ。

進め方:

• 最初の変更は小さくする（上限の env 化と計測ログ追加だけ。ページサイズなど他のパラメータは初回は触らず、上限だけを変えてボトルネックを1つずつ見る）。
• 合否は単発成功でなく多面的に定義する。例: 同時複数実行でも成功、サーバーのメモリ使用率が危険域（例70%）未満、検索エンジンなど依存ミドルウェアのCPU・JVM圧が危険域に入らない、クライアント（ブラウザ）が固まらない、全体処理がN分以内、など。
• 計測結果で「現行方式のままで良いか、別方式（非同期化など）に切り替えるか」の閾値を判断する。

ポイント: 閾値を勘や単発テストでなく、本番に近い環境での多次元な実測で決めること。最初にボトルネック仮説を絞らず、一度に一つの変数だけ動かしてどこが先に限界になるかを見ると判断しやすい。