JavaのPDFライブラリ、結局どれを使えばいいのか問題
JavaでPDFを生成しようとしたとき、まず直面するのが「ライブラリ多すぎ問題」だ。PDFBox、iText、OpenPDF、FlyingSaucer……似たような名前が並び、どれを選べばいいか迷うエンジニアは多い。株式報酬SaaSを開発するNstockが、実運用から得た知見をZennに公開している。税務署・証券会社向けの帳票・契約書・帳簿という「本物の業務PDF」を日常的に生成してきた同社の選定ロジックは、実践的で参考になる。
帳票PDFの3パターンを整理する
Nstockでは、PDF生成のユースケースを以下の3種類に分類している。
- 申込書型：税務署・証券会社への提出書類。座標固定のテンプレートに値を流し込む形式。レイアウトが完全固定なので、「この座標にこの値」というマッピングを定義すれば機械的に処理できる
- 契約書型：割当契約書・放棄同意書など数ページの文書。氏名・住所が文章中に埋め込まれるため、文字数によって後続テキストの位置が変わる。固定座標では対応不可
- 帳簿型：電子帳簿保存法対応のタイムスタンプ付きPDF。データ量に応じて行数が増減し、ページまたぎ・ヘッダー繰り返しを動的に処理する必要がある
この3分類は「レイアウトの自由度」と「動的データへの対応度」で整理すると理解しやすい。申込書＜契約書＜帳簿の順に複雑度が上がる。
Javaライブラリの2層構造を理解する
JavaのPDFライブラリは基盤ライブラリとラッパーライブラリの2層で構成されている。
基盤ライブラリ（低レイヤー）
| ライブラリ | 特徴 | ライセンス |
|---|---|---|
| Apache PDFBox | Apache財団のOSS。実績豊富 | Apache License 2.0 |
| iText Core | 高機能な商用ライブラリ | AGPL（商用は有償） |
| OpenPDF | iText 4系からフォーク | LGPL 2.1 / MPL 2.0 |
ラッパーライブラリ（高レイヤー）
| ライブラリ | 基盤 |
|---|---|
| OpenHTMLtoPDF | PDFBox |
| pdfHTML（iTextアドオン） | iText |
| FlyingSaucer | OpenPDF |
ラッパーがないと、表一つ描くにも罫線から手書きしなければならない。HTML/CSSをPDFに変換するラッパーを使えば、Webエンジニアの既存スキルがそのまま活きる。
Nstockの選定とユースケース別の実装方針
Nstockは以下の基準でライブラリを選定した。
- OSSで実績があること：フォントや座標計算でハマったとき、GitHubのIssueやStack Overflowで先行事例を探せる環境が重要
- 基盤ライブラリを統一すること：複数の基盤が混在するとコードの一貫性が崩れ、AI生成コードにも揺れが出る。またAWS Lambdaへのデプロイを考慮したjarサイズ削減の観点からも1つに絞る
- コストを抑えること：一般ケースはOSSで対応し、困難なケースのみ有償サービスを検討
この基準から選ばれたのがApache PDFBox（基盤）＋OpenHTMLtoPDF（HTML変換）＋Aspose（docx→PDF変換、有償）の組み合わせだ。
各ユースケースの実装方針はこうなる。
- 申込書型：PDFBoxでテンプレートPDFを読み込み、X/Y座標を指定してテキスト描画。座標特定にはFigmaにPDFを読み込んで視覚的に把握する運用上の工夫も紹介されている
- 契約書型：docxテンプレートをApache POIで読み込み・差し替え → Asposeでdocx→PDF変換。PDF内の文章への後挿入が困難なため、docxを中間フォーマットとして活用する構成
- 帳簿型：ThymeleafでHTMLテンプレートにデータを埋め込み → OpenHTMLtoPDFでPDF変換。Webバックグラウンドのエンジニアが多いNstockらしい判断で、専用ラッパーより保守性が高い
ハマりポイント：座標とフォントの壁
実運用でぶつかった2つの課題も率直に共有されている。
座標指定の煩雑さ：テンプレートの仕様変更のたびにX/Y座標を1ポイント単位で見直す作業が発生する。Figmaを使って座標を一覧把握できるようにすることで工数を削減している。
環境依存文字の文字化け：JIS第三・第四水準の漢字を含む氏名をApache POIでdocxに差し込んだ後、Asposeで変換すると豆腐（□）表示になるケースがある。対処としてWordで手動編集したテンプレートを用意してプログラム上での差し込みを回避している。根本解決ではないが、発生頻度が低いケースは運用でカバーするという現実的な判断だ。
まとめ：「ユースケースで選ぶ」が正解
JavaのPDFライブラリ選定は「どれが優れているか」ではなく、帳票の種類ごとに何が必要かを先に整理することが出発点になる。固定座標で済む申込書型ならPDFBox単体で十分。テキストが流れる文書ならdocx経由が現実的。表組みが複雑ならHTML/CSS変換が保守しやすい。Nstockの事例は、その判断軸を実運用ベースで整理してくれた貴重な一本だ。帳票PDF実装を控えているJavaエンジニアは、元記事のライブラリ分類表と選定基準の節だけでも一読する価値がある。