業務上重要な PDF —— 請求書、出荷ラベル、月次明細 —— を何でも開いて、文書のプロパティを表示してみてください（macOS Preview なら Cmd+D、Adobe Reader なら Ctrl+D、ほとんどのデスクトップビューアでは「ファイル → プロパティ」）。そして Producer フィールドを見てください。
その PDF がヘッドレスブラウザを使う SaaS プラットフォームで生成されていれば、次のような表示によく出くわすはずです。
$ pdfinfo invoice.pdf
Title: invoice-20260318.pdf
Subject:
Author:
Creator: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (...) Chrome/120.0.0.0
Producer: Skia/PDF m120
Language:ページは SaaS ベンダーのブランドに見えます。なのにファイルのプロパティには、そのベンダーとも、そのベンダーが代わりに発行している顧客とも無関係なブラウザエンジンの名前が並んでいます。
本記事は、この食い違いについての話です。
ページはブランド化されているのに、ファイルはそうではない
ホワイトラベルの PDF 生成は、B2B SaaS では当然の要件です。ベンダーは顧客にロゴをアップロードさせ、ブランドカラーを選ばせ、テンプレートを構成させる。出力される PDF はベンダーではなく顧客のブランドに見える。
ほとんどのプラットフォームはそこで止まります。目に見えるレイヤーだけ解決して、ファイルプロパティのレイヤーは放置です。結果として、すべてのページに「Acme Logistics」と書かれているのに、右クリック → プロパティを開いた瞬間、ファイルは自らを「Skia/PDF m120」と名乗ります。
単発の B2C ダウンロード —— 個人の領収書、映画のチケット —— ならファイルプロパティはほぼ装飾にすぎません。しかし B2B 文書、あるいは規制対象の B2C 出力（医療レポート、財務諸表、法的開示、規制保険書類）では、ファイルプロパティは文書の一部です。これらは次の場所に現れます。
- Adobe Reader、Preview、Foxit、そしてあらゆるデスクトップ PDF ビューア
- ドキュメント管理システム(SharePoint、M-Files、NetSuite Files)
- メールサーバの PDF プレビューア
- 検索インデックス(Spotlight、Outlook、社内 DMS 検索)
- アーカイブシステム(PDF/A の長期保存)
- 処理経路で
pdfinfoやpdftk dump_dataを呼び出すあらゆる処理
ページには「Acme」と書かれ、Producer フィールドには「Chromium」と書かれているドキュメントは、これらのシステムにとっては「Chromium が Acme という名前の誰かのためにレンダリングしたもの」と読めます ——「Acme がレンダリングしたもの」ではなく。企業の調達やコンプライアンスの視点では、この違いは確実に響きます。
なぜこれが直接ユーザーよりも SaaS ベンダーにとって悪いのか
自分のために自分で PDF を生成しているなら、Producer フィールドの「Chromium」はあなただけの問題です。
SaaS ベンダーで、顧客がプラットフォームを通して PDF を生成しているなら、関係する相手は増えます。
- あなたが PDF 生成基盤を選んだ。
- あなたの顧客がその PDF を自分の顧客に送る。
- 最終的な受信者 —— 調達チーム、運送会社、税務署、経理部門 —— が目にする Producer フィールドには、あなたの名前も顧客の名前もなく、あなたがたまたま使っている上流のレンダラー名が入っている。
ページには顧客のブランド、ファイルには見覚えのないツール名。受信者の視点では、なんとなく言葉にしづらい違和感が残ります。顧客の視点では、ホワイトラベルの約束が最後まで届いていない。
ここはほとんどのプラットフォームが投資不足になりがちな箇所です。修正の成果はホームページからは見えませんから。しかし、自社の「ホワイトラベル PDF」機能の出力に対して顧客が pdfinfo を一度走らせれば、必ず気付きます。
これが実際に痛みになる場面
Producer フィールドが仮定ではなく実際の運用課題として出てきた状況は、こういうものです。
- **ベンダーセキュリティ質問票。**企業の調達がベンダーリスクレビューを行い、「あなた方から当社に届く文書出力に現れる第三者ツールをすべて列挙してください」と尋ねる。顧客の IT 部門がサンプル文書に対して
pdfinfoを走らせ、見覚えのないレンダラ名を見つける。誰も怒っているわけではない —— しかしその名前はサブプロセッサ一覧に追加され、その結果ベンダー管理レビューと別系統のコンプライアンスチェックが発動する。 - **DMS / アーカイブ検索。**顧客の文書管理システムは
authorで PDF をインデックスします。あなたのプラットフォーム発の PDF の Author フィールドが空だと、数か月後に顧客のコンプライアンスチームは「このベンダーからの文書」を簡単には絞り込めず、手作業でタグを追加せざるを得ません。本来やらなくてよい仕事です。 - **長期アーカイブの検証。**PDF/A アーカイブシステムは、Producer が想定ベンダーリストに一致しない文書をフラグ立てします。コンプライアンスチームは「Skia/PDF m120」や「wkhtmltopdf」を既知の許可レンダラとして手動で許可リストに入れざるを得ない —— 小さいが継続的な運用負担です。
- **ブランド一貫性の監査。**一部の企業マーケティングチームは、ブランドガバナンスの一環としてアウトバウンド文書の帰属を監査します。ブランドチームが聞いたこともないツールに帰属している文書は、指摘事項になる。
どれも重大インシデントではありません。それでも、企業向けセールス、顧客オンボーディング、運用に小さな摩擦を加えます。月数千件の文書では、それが積み重なります。
ファイルのプロパティは実際に何を表示しているのか
PDF 仕様は、ほぼすべてのビューアが表面化する 6 つの標準メタデータフィールドを定めています。
| フィールド | 何のためか | 情報が漏れやすい生成基盤がよく表示する内容 |
|---|---|---|
Title |
ドキュメントのタイトル | 自動生成されたファイル名、または空 |
Author |
ドキュメントを作成した個人または組織 | 空、または開発者本人の名前 |
Subject |
ドキュメントの短い説明 | 空 |
Creator |
元コンテンツを生成したアプリケーション | “Chromium”、“Mozilla/5.0…”、または SaaS ベンダーの内部ツール名 |
Producer |
PDF バイトを生成したアプリケーション | “Skia/PDF m120”、“wkhtmltopdf 0.12.x”、“iText 7.x.x” |
Language |
BCP-47 言語タグ | 空、あるいは違うロケール |
どれも短い文字列 1 本です。技術的に埋めるのが難しいフィールドは 1 つもありません。デフォルトで漏れる理由は、レンダリングライブラリが自分の名前を Producer に書き込み（正しい —— このフィールドはそのためのものです）、そしてほとんどのアプリケーションコードが残り 5 つを設定しないからです。
修正は、毎回のレンダリングで、ドキュメントが何のためのものか分かっているアプリケーションから意識的に埋めることです。
実際の「ブランド化メタデータ」はどう見えるか
同じメタデータブロックを gPdf で出した場合がこちらです。6 フィールドすべて呼び出し側でオーバーライド可能。
{
"settings": {
"metadata": {
"title": "Invoice INV-2026-3401",
"language": "en",
"author": "Acme Logistics, Inc.",
"subject": "Monthly invoice — 2026-03",
"creator": "Acme Billing Platform v7.2",
"producer": "Acme Billing Platform"
}
}
}生成された PDF に対して同じ pdfinfo を実行すると:
$ pdfinfo invoice.pdf
Title: Invoice INV-2026-3401
Subject: Monthly invoice — 2026-03
Author: Acme Logistics, Inc.
Creator: Acme Billing Platform v7.2
Producer: Acme Billing Platform
Language: enページは「Acme Logistics」として描画され、ファイルのプロパティにも「Acme Logistics」と書かれています。右クリック → プロパティを開けば、Acme にきちんと帰属する文書として見えます。バイトを生成したのはエッジの gPdf で約 4 ms だった、という事実は受信者の目に触れるどこにも出てきません。
「あなたが gPdf を使っていると顧客は知りたがるのでは?」
これは何度も聞かれる質問なので、正面から答えておく価値があります。
はい —— あなたの顧客は当然、あなたが gPdf 上に構築していることを知って構いません。それはあなたと顧客の間の話で、通常はエンジニアリングブログ、変更履歴、セキュリティアーキテクチャ文書、あるいはサブプロセッサ一覧(DPA に関連する場合 gPdf もそこに載ります)に書く話です。
Producer フィールドはその関係を扱うものではありません。扱うのは、顧客のドキュメントの最終受信者 —— 調達担当者、運送ディスパッチャ、税務署のフォーム処理係 —— です。彼らはあなたのレンダラ選択と何の関係もなく、気にする理由もありません。彼らにとって、プロパティダイアログの「Skia/PDF m120」はノイズで、「Acme Billing Platform」はシグナルです。
それに不誠実な点も特にありません。PDF 仕様は Producer を「元 PDF を生成したアプリケーションの名前」と定義しています。gPdf の上に PDF サービスを構築しているなら、gPdf をインフラとして呼び出し、PDF バイトを生み出したのはあなたのアプリケーションです。Producer にそう書くのは正確です。誠実なバージョンはこうです。
- gPdf はレンダリングインフラ。
- あなたのプラットフォームが producer。
- あなたの顧客が author。
PDF 仕様が意図した通り、各レイヤーにクレジットが行きます。
下流処理経路に関する注記
出力 PDF が受信者に届くまでに後処理段を通る場合 —— 明示的にメタデータ保持フラグを付けていない Ghostscript、企業向け DRM / 透かしツール、「PDF オプティマイザ」など —— その一部は静かに Producer を自分の名前に書き換え、せっかく設定したブランド化メタデータを台無しにします。生の gPdf レスポンスだけでなく、実際の処理経路に対してテストしてください。
ここに含まれていないものについて
正確を期すなら、上に挙げた 6 つの標準フィールドが今日 gPdf が公開している全てです。ドキュメントプロパティをホワイトラベル化する —— ブランド・アイデンティティの話 —— にはそれで十分です。
しかし、PDF 内に任意の業務コンテキスト（注文 UUID、倉庫コード、テンプレートバージョン）を仕込んで下流システムに読ませるには不十分です。これは別の補完的能力 —— XMP カスタムメタデータ + 任意のキーバリュー —— であり、PDF 仕様自体はサポートしていて、ロードマップ項目として追跡しています。今日必要なら、この種の ID 系データは PDF の中よりも、ファイル名やハッシュをキーにして自社プラットフォームのデータベースに置く方が確実です。メタデータは文書のアイデンティティのためのものであり、構造化された業務データを PDF に載せて運ぶためのものではありません。
ブランド化メタデータ（今日）≠ 隠れた業務データの流れ（別の話）。自分の計画でも分けて考える価値があります。
最小限のアップグレード
すでに /api/v1/pdf/render に POST していて、現在のリクエストに settings.metadata がない場合、最小の改善はすでに送っている JSON に 3 行追加するだけです。
{
"pages": [...],
"settings": {
+ "metadata": {
+ "author": "Your customer's organisation",
+ "producer": "Your platform"
+ }
}
}2 フィールド、新しいキー 1 つ。数秒で pdfinfo で検証できます。これが入ったら、時間があるときに title、language、subject、creator を埋めていけば十分です。
これが gPdf API のどこに落ちるか
settings.metadata 内の 6 行です。トークンごとのポリシーでこれらのフィールドを除去 / デフォルト化できるので、マルチテナント SaaS は「顧客が生成するすべての PDF が正しく帰属表示される」ことを、各 API 呼び出し側に頼ることなく強制できます。
- §4.14.2 メタデータ(API リファレンス) —— フィールド単位のリファレンス。
- フィールド単位の詳細解説 —— title / language / author / subject / creator / producer がいつ重要になるか、読み手は実際に何をするか、出荷したものをどう検証するか。
可視のページはブランドの半分。ファイルのプロパティが残り半分です。プラットフォームが顧客の代わりに PDF を出荷するなら、両方にその名前があるべきです。