姉妹編 PDF のプロパティに表示すべきは、他社ツールではなく自社のブランドでは、「なぜ PDF メタデータを気にすべきか」を論じました。こちらは操作マニュアルです。各フィールドは PDF 仕様で何のためのものか、誰が読むのか、よくある間違いは何か、意図した内容が本当に出荷されたかをどう検証するかを扱います。

gPdf が公開しているのは、PDF 仕様が文書レベルのメタデータとして定義する 6 つの標準フィールドで、DocumentRequest JSON の settings.metadata 配下に置きます。各フィールドは任意です。設定されていなければ、gPdf はトークンの default_metadata（Enterprise ポリシー機能）またはシステムデフォルトを使います。

{
  "settings": {
    "metadata": {
      "title":    "...",
      "language": "...",
      "author":   "...",
      "subject":  "...",
      "creator":  "...",
      "producer": "..."
    }
  }
}

以降は 1 フィールド 1 セクションです。各セクションは同じ形、つまり何のフィールドか、どこに表れるか、よくある間違い、目安で構成します。並びは「先に埋めるべきもの → … → 最後で構わないもの」の順です。

`title` —— ドキュメントは何か

PDF 仕様ではこれを「ドキュメントのタイトル」と表現しています。

どこに表れるか:

PDF ビューアのタイトルバー（Adobe Reader、Preview、Foxit、Chromium の PDF ビューアはいずれも表示します）。
インラインで開いた場合（Content-Disposition: inline）のブラウザタブ。
検索インデックス —— Spotlight、Outlook、SharePoint、Google Drive のフルテキスト索引はいずれも title を読み、重みを大きく付けます。

よくある間違い:

❌ title をファイル名にしてしまう。 invoice-20260318.pdf はファイル名です。title は人が読む文字列、たとえば Invoice INV-2026-3401 です。ファイル名とタイトルは別の関心事です。ファイル名はファイルシステム向け、タイトルはビューアと検索向けです。
❌ **title を空のままにする。**ビューアはファイル名を代わりに表示し、結果は自動生成・機械出力された見た目になります。
❌ title にブランドを混ぜ込む。Acme Logistics — Invoice INV-2026-3401 はタイトルバーを散らかします。ブランドの居場所は author であって、title ではありません。

目安: title はレンダリングされたページの H1 と一致させます。請求書テンプレートの先頭行が「Invoice INV-2026-3401」なら、それが title です。

`language` —— アクセシビリティ、検索、コンプライアンスのために

language は BCP-47 の言語タグです。en、de、zh-Hans、pt-BR、ar-SA のように書きます。すべての文書で設定してください。6 つのフィールドの中で下流への影響が最も具体的で、実装コストが最も小さいため、一番下に埋もれさせず 2 番目に置いています。

どこに表れるか:

スクリーンリーダー —— JAWS、NVDA、VoiceOver はこれを使って正しい音素セットを選びます。英語のスクリーンリーダーが language: "de" の PDF を読むとき、ドイツ語の単語を正しく発音します。タグがないと韻律が崩れます。
検索エンジンとインデクサ —— どのロケールのステミングとストップワードを当てるかが決まります。language: "zh-Hans" の請求書は中国語のセグメンテーションで索引されます。タグがないと多くは英語にデフォルトされ、インデックスは使い物になりません。
PDF/A 準拠 —— PDF/A-2a と PDF/A-3a（アクセシビリティプロファイル）は言語タグを要求します。なければ veraPDF の検証はそのまま落ちます。

よくある間違い:

❌ **設定しないままにする。**デフォルトは「受信者のロケール」であって「プラットフォームのデフォルト」ではありません。漏れのある実装の多くはこのフィールドを書かないだけ。結果はスクリーンリーダーの発音違いと、語幹処理を誤る検索インデックスです。
❌ 非 BCP-47 の文字列、たとえば "english" や "EN-US"。PDF 仕様は RFC 5646 タグを要求します。en、en-US、de、pt-BR のように書きます。
❌ 実際の内容言語に関わらずプラットフォームのデフォルト（常に "en" など）をハードコードする。ポルトガル語の請求書を "en" でタグ付けすると、タグなしより悪くなります。インデクサを積極的にミスリードするからです。

目安: タグは実際のコンテンツ言語に合わせます。ブラジルの顧客がポルトガル語で受け取る請求書なら "language": "pt-BR" に設定します。"en" ではありません。多言語文書なら主要言語を選び、残りはコンテンツ要素単位で Lang 属性を使います。これは文書レベルの language フィールドを超える、タグ付き PDF のアクセシビリティ機能です。

`author` —— ドキュメントは誰に帰属するか

PDF 仕様では author は「ドキュメントを作成した個人または組織の名前」です。受信者に届く業務 PDF では、答えはほぼ常に組織です —— ただし適切な形は文脈で本当に変わります。

どこに表れるか:

すべての PDF ビューアのプロパティダイアログ。「Author」と目立つラベル付き。
DMS / アーカイブのインデクサ。しばしばフィルタとして使われます。
PDF/A の XMP メタデータストリーム。長期アーカイブまで運ばれます。

よくある間違い:

❌ "author": "[email protected]" —— うっかり運用者のメールをすべての PDF に漏らし、すべての検索インデックスに入り、長期 PII の問題になります。
❌ "author": "PDF Generator Service" —— 内部ツール名。受信者には何の意味もありません。
❌ 空 —— Preview とほとんどのビューアはプロパティダイアログで露骨に「(no author)」と表示し、「誰にも帰属していない文書」のように読めてしまいます。

機能する書き方:

✅ "author": "Acme Logistics, Inc." —— ストレートな組織。
✅ "author": "Acme Logistics — Billing" —— 組織 + 部門。特定の窓口に流れる文書向け。
✅ "author": "Bridge Capital Partners — Fund III" —— 帰属が特定実体になる金融 / 法務で有用。
✅ "author": "Maria López, RICS Surveyor" —— 単著の出版（報告書、評価、法的見解）で、個人そのものが編集上の帰属である場合。

目安: author は、受信者がその文書を結びつけるべき実体です。プラットフォームが顧客の代理として PDF を生成するマルチテナント SaaS では、author はプラットフォーム名ではなく顧客の組織名であるべきです（プラットフォーム名は creator —— 下を参照）。コンサルティング / 出版 / 法務など、個人そのものがブランドになる文脈なら個人で構いません。

`subject` —— このドキュメントはどの種類か

subject は文書の短い説明です。ビューアは目立つ位置には出しません。プロパティダイアログを開かない限り、多くのユーザーは目にしません。しかし、文書管理システム、アーカイブシステム、ルールベースのメール / ファイルルーティングは使います。

どこに表れるか:

プロパティダイアログ。二次的な位置。
DMS のルーティングルール、アーカイブのバケット振り分けロジック。
XMP メタデータストリーム（PDF/A）。

よくある間違い:

❌ "subject": "Invoice for Acme on 2026-03-18 for $4,532.10" —— これは個別文書の説明であり、種類ではありません。title の領分です。
❌ 空 —— 下流システムに渡せる無料のルーティングフックを無駄にします。
❌ クラスを一貫しない形で混ぜる（"Invoice" vs "Invoice/2026-03" vs "Monthly invoice"）—— DMS のフィルタは動くターゲットでは振り分けできません。

機能する書き方:

✅ "subject": "Invoice"
✅ "subject": "Monthly account statement"
✅ "subject": "Shipping label — 4×6 thermal"
✅ "subject": "Q3 2026 board pack"

目安: 正しい粒度は文書クラスであって、個別文書ではありません。毎日数千件の PDF が流入する DMS は、一貫した語彙さえあれば subject でルーティングできます。プラットフォーム内で有限のクラス集合を決め、そこから逸脱しないようにします。プラットフォームが出すすべての請求書は、ちょうど "subject": "Invoice" であるべきです。

`creator` と `producer` —— 最も取り違えられるペア

ここで多くのチームは PDF 仕様を読むのをやめて推測に入ります。仕様は厳密で、2 つのフィールドは違うことを意味します。

creator —— 元コンテンツを生成したアプリケーション（文書に何を書くべきかを決めた上流システム）。
producer —— PDF バイトを生成したアプリケーション（そのコンテンツを PDF ファイルに変換したレンダリングエンジン）。

gPdf のような JSON から PDF への API で請求書を生成する SaaS の請求プラットフォームなら、次のようになります。

creator = バージョン付きの SaaS 請求プラットフォーム。Acme 向け 4,532.10 ドルの請求書にするべきだと決めたアプリケーションがそれ。
producer = レンダラー。デフォルトは “gPdf”。しかしレンダリング層は SaaS が選んだインフラなので、SaaS は producer を自社のプラットフォーム名に正当に設定できます。実質的な意味では、その SaaS プラットフォームが gPdf というインフラに委任して PDF バイトを生成しているからです。

{
  "creator":  "Acme Billing Platform v7.2",
  "producer": "Acme Billing Platform"
}

どこに表れるか:

プロパティダイアログ、両方ラベル付き。
pdfinfo の出力、横並びで。
PDF/A の XMP ストリーム(PDF/A では両フィールドとも非空であることが要求されます)。

よくある間違い:

❌ **creator に Chromium / Mozilla の User-Agent 文字列が入る。**ヘッドレスブラウザの PDF 生成基盤が User-Agent を自動で creator に渡してしまう場合に起きます。それはブラウザのバージョンであって、文書内容を決めた上流システムではありません。上書きしてください。
❌ **producer をデフォルトのレンダラ名のままにする。**多くのチームはここを上書きしないので、すべての PDF が「Skia/PDF m120」や「wkhtmltopdf」と書かれる —— なぜこれが B2B で問題なのかはホワイトラベル編を参照。
❌ **両方に同じ値を入れる。**許容ではあるが無駄 —— 2 フィールドあるのはまさにビューアが「ソースアプリ」と「描画エンジン」を区別できるようにするためです。活用しましょう。

目安:creator はアプリ名 + バージョン(例:"Acme Billing Platform v7.2");producer はアプリのブランド / プラットフォーム名 バージョンなし(例:"Acme Billing Platform")。どちらも受信者が認識できる値であるべきです。

空フィールド、トークン別デフォルト、下流での想定外

出荷前に知っておきたい実装の細部が 3 つあります。

空文字列や空白のみの文字列は「未提供」と同じ扱い。"title": "" を送るのと title を省くのは同等 —— 空文字列を PDF に書くのではなく、既定値の連鎖（トークンデフォルト → システムデフォルト）を辿ります。「設定したのに反映されない」型の報告で一番多い原因がこれです。
**トークンポリシーでメタデータフィールドを除去 / デフォルト化できる。**gPdf を使うマルチテナント SaaS は各 API トークンに default_metadata を設定でき、そのトークンが生成するすべての PDF は顧客の author と producer を、各リクエストで開発者が設定することに頼らずに自動で付帯できます。「Acme のすべての PDF は Acme と書く」のような強制の正しいレイヤーがトークンレベルのデフォルトです。
**下流の処理経路がメタデータを書き換えることがある。**gPdf 返却後に PDF を後処理するツール —— 明示的にメタデータ保持フラグを付けない Ghostscript、一部の企業 DRM ツール、一部の「PDF オプティマイザ」—— は Producer を自分の名前で上書きして、設定したブランディングを台無しにします。生の gPdf レスポンスだけでなく、実際の本番処理経路に対して検証してください。

メタデータを検証する

上の変更を実装したあと、PDF が意図した内容を本当に出荷したかを素早く確認する方法を 3 つ。

コマンドライン(macOS / Linux、poppler-utils が必要):

$ pdfinfo your-output.pdf | head -10
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

Acrobat / Adobe Reader:ファイル → プロパティ → 概要タブ。6 フィールドすべてが表示され、Title はビューア上部のタイトルバーにも出ます。

macOS Preview:⌘+I(情報を見る)。「PDF」インスペクタペインに同じフィールドが並びます。

いずれかが空、ブランク、または設定していないツール名で表示されるなら、リクエスト本体を遡ってください —— 最多の原因は ""（空文字列）の送信で、API はこれを「未提供」と扱い、既定値の連鎖を辿ってデフォルト値に到達します。次に多いのは下流処理経路（Ghostscript、DRM、オプティマイザ）が gPdf 返却後にフィールドを上書きするケース。生のレンダリングレスポンスだけでなく本番に対してテストしてください。

PDF/A アーカイブにおけるメタデータ

長期アーカイブのために settings.profile: "pdfa-2b"（あるいは -2a、-3a、-3b）でレンダリングする場合、メタデータは任意項目ではなく、中核的な要件になります。

PDF/A 準拠ファイルでは producer フィールドは空にできません —— 最低でもシステムデフォルトが書かれます。
アクセシビリティプロファイル(PDF/A-2a、PDF/A-3a)は language を必須にします。なければ veraPDF 検証はそのまま不合格。
PDF/A が要求する XMP メタデータストリームは上記 6 フィールドから自動生成されます。自分で組み立てる必要はありません。
title、author、subject、creator、producer、language すべてが XMP ストリームに乗るので、下流アーカイブのメタデータインデクサ(Preservica、Archivematica)は本文を再パースせずにカタログを構築できます。

アーカイブ文書では、ブランド化されたメタデータは単なるブランドの仕上げではなく、成果物の耐久性の一部です。10 年後にあなたの PDF を開くドイツの税関、ブラジルの税務当局、あるいは任意の長期アーカイブは、レンダリングした日にそれらフィールドに入っていた内容をそのまま見ます。レンダリング時に意識的に設定することが、あなたに与えられた唯一の機会です。

gPdf が(まだ)公開していないもの

現在の API 境界について正直に言うと、PDF 仕様は Keywords（自由形式の検索語）と任意のカスタムキーバリュー対応の XMP メタデータストリームも定義しています。現行 API では gPdf はどちらも公開していません。

PDF 内に任意のビジネスデータ(注文 UUID、倉庫コード、テンプレートバージョン)を仕込みたい場合、現状の回避策は:

subject を下流システムがパースする構造化された短い文字列にする。
ビジネスデータはファイル名やコンテンツハッシュをキーに、自社データベースに保持する。
待つ —— XMP カスタムフィールドはロードマップにあり、出荷後は隠れた機械可読の業務処理コンテキストを入れる正解になります。

「ブランド化メタデータ」(今ある 6 つの標準フィールド)と「カスタムビジネスメタデータ」(将来の XMP カスタムフィールド)を混同するのが、今日できることを最も簡単に過大宣伝してしまう道です。自分の計画でも分けて扱う価値があります。

完全な例

SaaS の請求プラットフォーム(Acme Billing Platform)がドイツの顧客(Müller Versand GmbH)向けに請求書を生成し、PDF/A としてアーカイブする準備をする例:

{
  "settings": {
    "profile": "pdfa-3b",
    "metadata": {
      "title":    "Rechnung RE-2026-0412",
      "language": "de",
      "author":   "Müller Versand GmbH",
      "subject":  "Monatsrechnung — März 2026",
      "creator":  "Acme Billing Platform v7.2",
      "producer": "Acme Billing Platform"
    }
  }
}

生成された PDF に対して pdfinfo:

$ pdfinfo invoice-2026-0412.pdf | head -10
Title:           Rechnung RE-2026-0412
Subject:         Monatsrechnung — März 2026
Author:          Müller Versand GmbH
Creator:         Acme Billing Platform v7.2
Producer:        Acme Billing Platform
Language:        de

タイトルはドイツ語、author は Müller Versand(顧客の GmbH 法人、ドキュメントの受信者)、creator は Acme Billing Platform(ページに何を書くかを決めた編集システム)、producer は Acme Billing Platform のブランド、language はドイツ語スクリーンリーダーと、後で Müller の DMS で拾われるドイツ語フルテキストインデクサのために正しくタグ付けされています。PDF/A-3b プロファイルなので、このメタデータセットは長期アーカイブのために XMP ストリームにもシリアライズされます。

ファイルのプロパティのどこにも、gPdf、Chromium、顧客が選んでいないツールの名前は出てきません。まさにそこが要点です。

最小限のアップグレード

すでに /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 を埋めれば十分です。

このトピックの落ち場所

§4.14.2 メタデータ —— これらフィールドの API リファレンス。
PDF ホワイトラベル化(姉妹編) —— なぜそうするか、と B2B SaaS のケース。
エンジニアのための PDF/A と Factur-X 徹底解説 —— メタデータの話に長期アーカイブが絡むなら関連します。

title —— ドキュメントは何か

language —— アクセシビリティ、検索、コンプライアンスのために

author —— ドキュメントは誰に帰属するか

subject —— このドキュメントはどの種類か

creator と producer —— 最も取り違えられるペア

空フィールド、トークン別デフォルト、下流での想定外

メタデータを検証する

PDF/A アーカイブにおけるメタデータ

gPdf が(まだ)公開していないもの

完全な例

最小限のアップグレード

このトピックの落ち場所

`title` —— ドキュメントは何か

`language` —— アクセシビリティ、検索、コンプライアンスのために

`author` —— ドキュメントは誰に帰属するか

`subject` —— このドキュメントはどの種類か

`creator` と `producer` —— 最も取り違えられるペア