大量の ID 配列を JSON request body で受ける API では、OpenAPI やバリデーションの maxItems だけを上げても不十分。実際に通るかは、アプリの body parser limit、proxy / gateway / WAF の body 処理、保存先 payload のサイズ上限、非同期キューへ載せるメッセージサイズのすべてで決まる。

判断基準

• まず代表的な ID 長と最大件数で JSON.stringify 後の byte size を見積もる。数 MB に収まるなら通常の request body として扱いやすいが、既定の 1MB 制限では落ちることが多い。
• body parser limit は、想定 payload サイズに更新値やメタデータ分の余裕を足して設定する。上限だけを大きくしすぎると全 API のメモリ使用量と DoS 面が広がるため、可能なら対象 endpoint の性質に合わせて限定する。
• WAF が body を検査する構成では、巨大 JSON や自由入力値が body ルールに触れる可能性を確認する。ファイルや HTML でなくても、長文・URL・記号を含む更新値を受ける endpoint は誤検知緩和対象になり得る。
• 非同期処理に渡す場合、キューには巨大な ID 配列を直接載せず、task ID や payload 参照だけを送る。キューの message size 上限と再試行コストを避けられる。

検証

最大件数の payload を実際に生成して byte size を測り、body parser の limit 未満であることを確認する。境界テストでは最大件数ちょうどが通り、最大件数 + 1 がバリデーションで落ちることを確認する。WAF 配下では、自由入力値を含む最大級 payload がアプリまで届くかも疎通確認する。