wkhtmltopdfの次どうするか問題2026

2026/09/17 に開催されたRailsTokyo#6 での発表資料です

https://railstokyo.connpass.com/event/400709/

Transcript

1. wkhtmltopdfの次どうするか問 題2026 Shinichi Maeshima(@willnet) RailsTokyo#6 2026/09/17
2. wkhtmltopdfの次どうするか問 題2026
3. wkhtmltopdf知ってる人🖐
4. wkhtmltopdfとは • HTMLからPDFを生成するツール • Qt Webkitというブラウザエンジンを利用してHTMLを描画し、その結果を PDFとして出力する • Qt(デスクトップアプリや組み込みアプリを作るためのフレームワーク)の中 のプロジェクトの一つがQt Webkit • 主にユーザに「今見ている画面のPDF版」をダウンロードさせたいときに使 われる • Rubyからだと主にwicked̲pdfやpdfkitなどのgem経由で使われる
5. wicked̲pdfを利用したときのコード例
6. wkhtmltopdfはPDFをレンダリ ングするときの第一候補だった が…
8. This repository was archived by the owner • Qt webkit自体がメンテナンス終了してしまったことにより、Qt webkitに依 存しているwkhtmltopdfもメンテナンスが終了した • QtはQtWebEngineというchromiumベースのプロジェクトに移行している • wkhtmltopdfが依存しているのはQt4系であり、2012年のブラウザエンジン である
9. 2012年のブラウザエンジン
10. wkhtmltopdfを利用したときに使えないjsの記法や機能 • アロー関数 • let, const • async, await
11. wkhtmltopdfを利用したときに使えないcssの記法や機能 • FlexBox • Grid • CSS変数
12. セキュリティの問題 • CVE-2022-35583 • 最新のwkhtmltopdf(0.12.6)に見つかったSSRFの脆弱性 • iframeなどのsrcを外部入力できると任意のURLの情報をPDFの形で得るこ とができてしまう • 外部からの入力をエスケープしない、というのが条件なので一般的なRails アプリケーションでは成立しづらいとは思います
13. wkhtmltopdfから他の何かに移 行したい!!!!
14. 次どうします？ • というのを以前(3年半前)ブログに書いた • 要約: ferrumやgrover、Thinreportsなんかがいいんですかね？
15. 続編も書いた • 要約: ferrumを利用してPDF変換するferrum̲pdfが便利で良さそう
16. 2026年現在 • まだまだwkhtmltopdfを使い続けているプロジェクトは残っている印象
17. なぜなのか • 工数が足りない • 情報が足りない • その他(もし知ってたら後で教えて!)
18. 工数が足りない • 僕にはどうにもできないので頑張ってください＞＜
19. 情報が足りない • どの選択肢を選ぶといいのかがわからない、知見が足りていないのでは？と いう仮説 • 例1: wkhtmltopdfから(任意のツール)に移行するとどのくらい負荷がかかり ますか？ • 例2: 候補となるツールの比較
20. 選択肢とそれに関する知見を話し ていきます
21. 選択肢1: 運用でカバーする
22. 運用でカバーする • ユーザに対して、macなら⌘+p、pcならctrl-pを押してもらい自分でwebペー ジをPDFに保存してもらう • 自社の社員が触る管理画面である、という前提なら割と現実的かつ楽な選択 肢じゃないかと思います
23. 選択肢2: 一からPDFを生成する
24. 一からPDFを生成する • 「HTMLをPDF変換」ではなく、Thinreportsなどのツールを使って一から PDFを生成する • HTMLをPDF化する必要がないなら考えることが減って楽
25. 選択肢3: chromiumをアプリケ ーションサーバ内で使う
26. chromiumをアプリケーションサーバ内で使う • groverとferrum̲pdfが候補 • groverはpuppeteer経由でchromiumを動かす • ferrum̲pdfはRubyから直接chromiumを動かす
27. puppeteer経由だと何がどれくらい違うんですか？ • puppeteerを使うにはアプリケーションサーバにnodeが必要、というのはあ るけど、それ以外で具体的にどう違うんですかね • メモリ消費量など変わったりするんですか？？？
28. 具体的に知るためにベンチマークをとった • willnet/html-to-pdf-benchmark (https://github.com/willnet/html-to-pdf-benchmark) • dockerがあればお手元でも試すことができるようにしています • 利用マシン: M1 Max MBP • wkhtmltopdf、Grover, Ferrum(ferrum̲pdf)で次の環境を用意して32のPDF化リクエストを 割り振り、その時のCPU、メモリ、スループットを見た • 1スレッド1プロセス • 4スレッド1プロセス • 1スレッド4プロセス • 4スレッド4プロセス
31. なぜこのような違いがあるのか • ferrumはプロセスごとに1つのchromiumブラウザインスタンスを使い回す • (ただしPDFへの変換はロックを用いて1スレッドのみ実行できるようにし ている) • groverはPDF生成を1回実行するごとに新しいchromiumブラウザインスタン スを起動してPDF生成後に終了する • なので単純なベンチマークだとferrumの方が優れているように見える
32. 運用も考えるとgroverの方が安定していそう • 毎回chromiumブラウザインスタンスを作成→終了する方がメモリリークやメ モリの断片化の影響を受けにくい • chromiumがクラッシュしても影響はその時1回だけに限定される
33. groverとferrumの比較をしたものの • そもそもの話としてchromiumで500MB以上のメモリ消費量がアプリケーシ ョンに上乗せされるのってどうなんですかね • アプリケーションサーバの台数を増やす必要が出てくる • アプリケーションサーバの依存ライブラリも増える
34. 選択肢4: 別のアプリケーション サーバでchromiumを動かすも のを作る
35. HTML→PDFの専用アプリケーションを作る • 「HTMLを投げたらPDFを返すアプリケーション」があるとアプリケーショ ンサーバのメモリ問題等をある程度緩和できる • SaaSは検索すると色々出てくるけど、大体においてPDF化したいHTMLは帳 票などの外に出したくない情報なので自前で持ちたい
36. 自社で作っている例1: ANDPAD社 • PDF 生成との終わらない戦い、あるいはデータ量の見積もりミスの話 ANDPAD Tech Blog (https://tech.andpad.co.jp/entry/ 2026/06/30/100000) • 専用アプリケーション内でgroverを使ってHTML→PDF化 • 運用中に起きた問題点を共有してくれてありがたい🙏
37. 自社で作っている例2: Gusto社 • Building Virtuous PDF: How Gusto Replaced a Deprecated Library with a Modern PDF Microservice (https://engineering.gusto.com/ building-virtuous-pdf-how-gusto-replaced-a-deprecated-library-with-amodern-pdf-microservice-b37c481eaa03) • wicked̲pdfに対するvirtuous̲pdfを作った • 専用アプリケーションでferrumを利用している
38. 自社で作るという選択肢 • 素朴な実装であればサッと作ることはできそう • ただし長期にわたって運用するのであれば巨人の肩に乗れると楽では
39. 選択肢5: 別のアプリケーション サーバでchromiumを動かすも のを使う
40. Gotenberg • Dockerベースのgo言語製PDF生成ツール • HTMLを受け取りPDFを返すHTTPアプリケーションサーバ • 内部ではchromiumを利用 • PDF生成ツールとしてはだいぶ有名
41. gotenbergのRubyクライアント • sanzstez/gotenberg-ruby • しかし個人的に書き味が好みではない
42. gotenberg-rubyの書き味
43. 自分好みにしたくて自作してみた • willnet/gotenberg-rails
44. gotenberg-rails • 諸々準備しておけば↓だけでpdfを返せる
45. ここまでのまとめ • wkhtmltopdfの代替方法としていくつかの手法を紹介しました • 運用でカバーする • 一からPDFを生成する • アプリケーションサーバ内で変換する • PDF変換用アプリケーションサーバを作る • PDF変換用アプリケーションサーバを使う
46. おしまい？ • 応募時点ではそのつもりだったのですが… • sghtmltopdfという超新星が8月に現れてしまった
48. sghtmltopdfとは • rust製 • chromiumを使わず、servo(OSS webレンダリングエンジン)内の各ツールを利用 してHTMLをレンダリングし、それをPDFに変換している • wkhtmltopdfとメモリ容量がほぼ同等で速い( https://waka.github.io/ sghtmltopdf/ ) • wkhtmltopdf(wicked̲pdf)からの移行ドキュメントがある • アプリケーションサーバから使う、もできるしgotenbergのような形でも使える • ストリーミングモード(PDFを作りつつクライアントにレスポンスを返す)ができる
49. sghtmltopdfを使うときに考慮すること • 現時点でJavaScriptは使えない • <script>タグは無視される • CSSもchromeと同等ではなく、使えないものがある • 他にもいくつか制限あり( https://waka.github.io/sghtmltopdf/appendix/ limitations.html ) • ただしwkhtmltopdfからの移行、という前提ならおおよそ問題ないはず？
50. まとめ • wkhtmltopdfからの移行であればsghtmltopdfをまず検証してみましょう • どうしてもchromiumが欲しい時にはgotenbergかferrum̲pdfがいいんじゃ ないでしょうか • アプリケーションサーバでPDF生成する、と外部サービスとしてPDF生成 機能を外出しするかを検討しましょう • 自分たちでコントロールしたいぞ、というのであれば自作も選択肢として良さ そうです
51. Shinichi Maeshima Willnet Inc. @netwillnet @willnet https://blog.willnet.in
52. 2027/01/23(土) ぎんざRuby会議02やります
53. Kaigi on Rails 2026で 設定の話をします
54. 技術顧問業をしています
55. 顧問先は週1程度 空きあります