大量行のCSV・ファイルを同期のHTTPレスポンスで直接ダウンロードさせる方式は、件数が伸びると複数の経路で同時に限界に当たる。

同期方式の限界:

• ブラウザがレスポンス全体をメモリ上に保持する（受信完了まで blob 化して保持するので、数百MB規模でタブのメモリ圧迫・UIのフリーズ・失敗が現実化）。
• 利用者が画面を閉じる・リロードする・認証やネットワークが切れると中断される。
• ロードバランサ・プロキシの idle timeout（例: 600秒）に長時間処理が引っかかる。
• APIサーバー側も、同時に複数の大きな出力が走ると CPU・GC・検索エンジン・ネットワークが詰まる。

非同期パターン（既存の非同期インポート等と同じ流れに寄せる）:

• POST でエクスポートタスクを作成し taskId を返す → GET でステータス（PENDING/PROCESSING/COMPLETED/FAILED）をポーリング → COMPLETED で結果取得APIがオブジェクトストレージの署名付きURLを返す（URL期限切れは同APIで再発行）。
• 本体の生成は worker や専用タスクがストレージへ出力し、APIサーバーは大容量本体を stream せず署名URLだけ返す。
• ファイル名はストレージ側の Content-Disposition で制御する（署名URLの download 属性は効かないことがあるため）。
• 通常ユーザーの体験はポーリングを画面側で隠蔽し「準備中→完了で自動ダウンロード」で現行に近づける。同じタスクAPIを外部連携から直叩きでも使えるようにすれば基盤を共有できる。

却下した代替案: APIを直叩きして stream 接続を長時間繋いだまま使う案は、ブラウザ依存と長時間HTTP接続の脆さで退けた。

適用の目安: 同期での実測限界（10万〜20万行程度）で済むなら同期継続でよく、それを超える上限なしの用途を狙うなら非同期タスク化へ寄せる。