Compliance and archival

アーカイブとコンプライアンス向け PDF/A API

PDF/A API: ブラウザレンダリングなしでアーカイブ、コンプライアンス、検証向けの PDF/A プロファイルを生成する。gPdf の描画責任と自社の業務データ責任を明確に分けます。

主 API JSON Render
ENDPOINT /api/v1/pdf/render
対象システム コンプライアンスバックエンド / アーカイブサービス / ERP エクスポートサービス / 文書自動化サービス
解決する業務課題

アーカイブ、コンプライアンス、検証向けの PDF/A プロファイルを生成する。自社システムが業務データとルールを持ち、gPdf はそれを PDF として再現性高く出力します。

この API が合う場合

  • 自社システムが PDF/A 文書 に必要なデータをすでに持っており、PDF レスポンスが必要です。
  • ブラウザベースの HTML to PDF ではなく、/api/v1/pdf/render の JSON Render を使いたい場合。
  • レイアウト、バーコード、テキスト、メタデータを構造化データから再現可能に生成したい場合。
  • 本番投入前に Playground や CI でペイロードを再現検証したい場合。

置き換えないもの

  • Chromium を使った任意 HTML to PDF 変換が必要な場合。
  • 生データから業務上・法的な意味を gPdf に推定させたい場合。
  • 毎回レイアウトを送るより公開済み template_id 契約のほうが適している場合。

呼び出す endpoint

主経路

/api/v1/pdf/render

JSON Render がこのワークフローの標準パスです。

補助経路 1

/api/v1/e-invoice/render

関連 API パス、テンプレート契約、または機能確認が必要な場合に使います。

最小リクエスト

/api/v1/pdf/render - PDF/A 文書 の最小リクエスト。

{
  "settings": {
    "profile": "pdfa-2b"
  },
  "pages": [
    {
      "size": "a4",
      "elements": [
        {
          "type": "text",
          "x": 20,
          "y": 24,
          "content": "Archive-ready document",
          "style": { "font_size": 16, "font_family": "NotoSans-Regular" }
        }
      ]
    }
  ]
}

gPdf が担当すること

  • 構造化リクエストから PDF/A 文書 をレンダリングします。
  • 必要に応じて PDF ページ、テキスト、表、線、図形、画像、ベクターバーコードを描画します。
  • 公開 API 契約に沿って PDF/A 関連のメタデータ、プロファイル、検証境界を扱います。
  • 失敗時は API-XXX コードと req_id を含む共通エラー形式を返します。

自社システムが担当すること

  • 業務データ、フィールドマッピング、文書の意味付け。
  • レスポンス後の検証、冪等性、ファイル名、保存、追跡。
  • レンダリング前の税務、コンプライアンス、顧客、プラットフォーム固有ルール。

本番前チェックリスト

  1. 本番呼び出しには request ID と timeout を設定します。
  2. OpenAPI、ドキュメント、Golden PDF テストでペイロードを検証します。
  3. API ベース URL と bearer token は設定化し、ソースコードに埋め込みません。
  4. 重要レイアウトは実データと境界ケースでテストします。
  5. 検証証跡と再出力に必要な情報を自社システム側に保持します。

対応範囲の境界

  • gPdf は PDF/A 文書 をレンダリングしますが、業務上の正しさは自社システムの責任です。
  • このページは適切な gPdf API パスを示すもので、追加のワークフロー専用 endpoint ではありません。
  • 外部認証、受け入れ判定、現場の運用承認はレンダラーの範囲外です。

このワークフローと gPdf の関係

PDF/A API は、公開 gPdf API を使う本番向けワークフローです。リクエストでは、データ、レイアウト、settings、PDF に描画する要素を明示します。gPdf が担当するのはレンダリングであり、データの業務判断ではありません。

API パスと責任境界

多くの場合、/api/v1/pdf/render の JSON Render が出発点になります。マスターデータ、検証、保存、業務ルールは自社システム側に残ります。つまり、gPdf は PDF を生成し、アプリケーションが意味とプロセスを制御します。

本番化の確認

PDF/A 文書 は、ワークフローに応じて実データ、プリンター、スキャナー、検証エンジン、受信側システムで確認してください。サポート、監査、再出力に使えるよう request ID と検証証跡を保存します。

FAQ

PDF/A API は専用 endpoint ですか?
いいえ。このページは /api/v1/pdf/render と関連する gPdf API をこのワークフローでどう使うかを説明します。
自社システムは何を用意しますか?
業務データ、フィールドマッピング、検証、本番ルールは自社システムが用意します。gPdf は PDF 生成を担当します。
Template Render はいつ使いますか?
レイアウトが固定され、呼び出し側が template_id と data[] だけを送ればよい段階で Template Render を使います。
本番前に何を確認しますか?
実データ、境界ケース、検証、PDF を読む・印刷する・保管する後続システムで確認します。