PDFShift は、HTML や URL を渡すと PDF を生成して返す API だ。請求書・レポート・証明書のように「Web ページとして作れるものを、そのまま配布可能な PDF にしたい」という要件に対して、変換処理を丸ごと肩代わりしてくれる。
ヘッドレス Chrome を自前で持たない選択
PDF 生成は内部的にヘッドレスブラウザでのレンダリングになることが多く、これを自前で運用するのは意外に重い。Chromium のバージョン管理、メモリ消費、フォント、同時実行数の制御――どれも地味に手間がかかる。PDFShift はこの面倒を API の向こうに押し込めるので、サーバー構成をシンプルに保ちたいときに効く。ヘッダー・フッターの差し込み、ページ番号、ウォーターマークといった実務で必要になる機能も揃っている。
きれいな PDF を出すコツ
入力が HTML/CSS なので、印刷向け CSS（@page、page-break-inside など）を意識して組むと、改ページや余白が安定する。日本語フォントの埋め込みや、外部リソースの読み込みタイミングは事前に確認しておきたい。Web フォントや画像が読み込まれる前にレンダリングが走ると、文字化けや画像欠落のまま PDF 化されることがあるため、変換オプションで待機の指定ができるかも見ておくとよい。
認証ページや動的コンテンツの扱い
URL 変換はログインの先にあるページには直接届かない。会員専用画面や、ユーザーごとに内容が変わるレポートを PDF にするなら、URL を渡すのではなく、サーバー側で生成済みの HTML 文字列を渡す方式の方が確実だ。社外に URL を踏ませる構成は情報漏れの懸念もあるため、HTML 入力を基本に考えたい。
料金と適用範囲
料金は無料枠が月あたりの変換回数で区切られ、有料はクレジット制になる。コストは変換回数に比例するので、生成頻度の見積もりが導入判断の軸になる。同じ内容の PDF を毎回作り直すなら、一度生成した PDF をキャッシュして変換回数を抑える設計も有効だ。なお PDFShift は「作る」専用で、既存 PDF からのテキスト抽出や解析はできない。読み取り側が必要なら OCR 系の別サービスを組み合わせる。
フォント埋め込みが日本語 PDF の分かれ目
HTML を PDF に変換するとき、日本語が豆腐（□）になったり別の書体に置き換わったりする事故は、フォントの扱いが原因であることが多い。変換環境に日本語フォントが存在しない場合、CSS で指定しても反映されない。Web フォントとして読み込ませる、あるいは変換側が対応するフォントを明示的に指定するといった対処が要る。請求書や契約書のように書式が意味を持つ文書では、実際の出力を印刷して確認するまで完了とは言えない。
画面で整って見えるレイアウトが、そのまま A4 に収まるとは限りません。改ページ位置の制御、ヘッダーとフッターの繰り返し、背景色の印刷可否は印刷用のスタイル指定で扱います。PDF 化を前提にするなら、専用のテンプレートを用意したほうが結果が安定します。
生成の重さを運用に織り込む
PDF 生成はブラウザのレンダリングを伴うため、単純な API 呼び出しより時間がかかる。リクエストの中で同期的に生成してダウンロードさせる作りは、文書が重くなると待ち時間として現れる。件数が多い、あるいは文書が複雑な場合は、生成を非同期のジョブに回して完了後に通知やダウンロードリンクを渡す構成にしたほうが、利用者の体験も安定する。