PDF生成ベンチマーク
Re:port Flow の PDF 生成 API（同期・非同期）が、実際にどれくらいの時間で帳票を返すかを実測した結果です。 測定に使ったスクリプト・入力 JSON・測定仕様をすべて公開しているので、同じ条件をご自身のワークスペースで追試できます。
測定条件・測定スクリプト・入力 JSON は公開済みで、下記の手順でどなたでも計測できます。 実測が終わり次第、結果と測定環境をこのページに掲載します。数値を推定値で埋めることはしません。
測定条件
測定対象は API 利用者のクライアントから観測できる所要時間です。サーバー内部の描画時間だけを取り出した値ではなく、 ネットワーク往復・CloudFront / ALB の転送・レイアウト計算・PDF 描画・S3 へのアップロード・応答本文の転送を含みます。
| エンドポイント | POST /file/sync/single / /file/sync/multiple /
/file/async/single / /file/async/multiple |
|---|---|
| 測る値 |
同期：リクエスト送信 → 応答本文（PDF / ZIP）の受信完了 非同期：リクエスト送信 → 全ファイルがダウンロード可能になるまで（あわせて 202 受信までも計測）
|
| 動かす条件 | 明細行数（入力）と件数（1 リクエストあたりのファイル数）。ページ数は結果として観測する値で、 1 ページに収まる行数はテンプレートのレイアウトで決まるため入力にはしていません |
| 試行回数 | 20 回（複数生成の条件は 10 回・50 件生成は 5 回）。 P95 は最近傍順位法のため、20 回未満では最大値と一致してしまい意味を持ちません |
| ウォームアップ | 2 回を先に実行して破棄します（統計にも失敗件数にも含めません）。 コールドスタート（タスク起動・フォントキャッシュ・TLS 接続確立）を統計から外すためです |
| 同時実行数 | 1（逐次）。レイテンシの測定であって、スループット測定・負荷試験ではありません |
| リクエスト間隔 | レート上限（同期 30 / 非同期 100 リクエスト毎分）の 80% を上限に間隔を空けます。 この待機時間は計測に含めません |
| 統計 |
中央値：標本数が偶数なら中央 2 値の平均／P95：最近傍順位法（ceil(0.95n) 番目、補間なし）
|
条件の完全な定義は 測定仕様（method.md） にあります。 本ページと食い違う場合は測定仕様が優先します。
測定環境・検証日
実測が未実施のため、測定環境として掲載できる情報はありません。
サーバー側の構成（タスク数・インスタンスサイズ）は非公開のため掲載していません。 データの保管地が AWS 東京リージョンであることはサービス事実表に記載しています。
測定結果
実測が未実施のため掲載できる数値はありません。追試の手順のスクリプトで、 同じ条件をご自身の環境で計測できます。
失敗・例外
実測が未実施のため、失敗件数はありません。
失敗として数える条件は、2xx 以外の応答・クライアント側タイムアウト・ネットワークエラー・応答内容の不正
（PDF や ZIP でない、202 のファイル件数が要求と違う）・非同期の完了期限切れ・
レート上限（429）の再送上限到達です。生成の失敗は自動リトライしていません
（成功するまで叩き直すと、実際の失敗率が結果から消えるため）。429 だけはリクエストが受理されず PDF も
生成されていないので、Retry-After に従って待ち直し、その回数を別に記録しています。
この測定で分からないこと
数値を正しく読むために、測れていないことを明示します。
- スループットではありません。同時実行数 1 の逐次測定なので、「1 分あたり何件さばけるか」は分かりません。
- 1 テンプレートの結果です。画像点数・フォント種類・図形数・グラフの有無で生成時間は変わります。
- 測定元の所在地・回線に依存します。測定値にはインターネット区間が含まれます。
- 他ワークスペースの負荷は制御できません。本番環境は共有基盤で、測定時点の全体負荷は観測できません。
- 1 リクエストあたり 6 件以上のバッチは測定していません。 本番環境は共有基盤であり、測定のために大きなバッチを繰り返し投げることが他の利用者に影響しうるためです。 掲載しているのは 1 件と 5 件の結果だけで、それ以上の件数の所要時間はこのページからは分かりません。
- 非同期の完了時間にはポーリング間隔の分解能があります。実際の完了より最大でポーリング間隔（1,000 ミリ秒）だけ遅く観測されます。
- ページ数は推定値です。PDF の構造から判定できない場合は「未計測」と表示し、推測では埋めません。複数生成は応答が ZIP のためページ数を測っていません。
- SLA ではありません。測定日時点の実測値であり、将来の性能を保証するものではありません。稼働率・性能の契約上の扱いは利用規約によります。
追試の手順
測定スクリプト・入力 JSON・測定仕様は MIT ライセンスで公開しています。ご自身のワークスペースで同じ条件を計測できます。
- テンプレートギャラリーから 請求書テンプレートをワークスペースへ複製する
- reportflow-examples を clone し、
.envに API キーと複製したデザイン ID を設定する -
node benchmarks/run.mjs --dry-runで、生成される PDF の件数を確認する （実行すると実際に PDF が生成され、プランの作成回数・従量課金の対象になります） node benchmarks/run.mjsを実行する。結果は JSON で出力されます
| 測定仕様 | benchmarks/method.md |
|---|---|
| 実行手順 | benchmarks/README.md |
| 測定スクリプト | benchmarks/run.mjs |
| 入力 JSON（サンプル） | benchmarks/payloads/invoice.json |
| 結果 JSON（生データ） | benchmarks/results/ |
| API の制限値 | 開発者ドキュメント（制限事項） |
よくある質問
同期と非同期のどちらを使うべき？
画面操作に対してその場で PDF を返したい場合は同期エンドポイントを使います。同期は 120 秒でタイムアウトするため、
大量生成や時間のかかる帳票では非同期を使ってください。非同期はリクエスト直後に requestId が返るので、
呼び出し側はブロックされません。完了は Webhook で受け取れます。
この数値は性能保証？
いいえ。測定日時点の実測値であり、SLA や性能保証ではありません。測定値にはクライアントからのインターネット区間が含まれ、 テンプレートの内容・測定元の所在地・本番環境の全体負荷によって変わります。
自分で同じ測定を再現できる？
できます。追試の手順のとおり、測定スクリプト・入力 JSON・測定仕様を公開しています。 測定条件を変えた場合は、その差分を結果と一緒に示してください。
1 件ずつ送るのと、まとめて送るのはどちらが速い？
1 リクエスト内のファイルはまとめて並行処理されるため、まとめて送るほうが 1 件あたりは速くなります。 測定結果の「複数生成」の表にある「1 件あたり」（中央値 ÷ 件数）の列と、 「単一生成」の中央値を見比べてください。
なお、6 件以上のバッチは今回測定していません（理由はこの測定で分からないこと）。 大量生成の設計をする場合は、まず小さい件数で試して、ご自身の要件に合う分割単位を確かめてください。
制定日：2026年8月6日
最終更新日：2026年8月6日