なぜチームは NextPDF を選ぶのか
Spec: ISO 32000-2ISO 32000-2Spec: ETSI EN 319 142-1ETSI EN 319 142-1
PDF エンジンを選ぶことは、小さな判断でありながら、後続の多くの判断を静かに決めてしまいます。このページは NextPDF を選ぶ理由を、チームが実際に行う判断として組み立てたものです。すなわち、PHP の中にとどまるかサイドカーを動かすか、コードを所有するかブラックボックスを借りるか、本物の署名を生み出すかチェックボックスを生み出すか、本番に耐えるプロトタイプを出荷するか、それとも本番に至るために書き直さなければならないものを出荷するか、という判断です。
なぜ重要なのか
「なぜ重要なのか」という見出しのセクション生成した PDF は、たいていそこで話が終わるわけではありません。署名され、アーカイブされ、規制当局にメールで送られ、あるいはコードを書いたときその場にいなかった誰かによって何年も後に開かれます。だからこそ PDF エンジンは、単なるユーティリティ呼び出しではなく、インフラの選択になります。誤った選択は後になって、バリデータが拒否する署名、チェッカーが不合格にするアーカイブ、あるいは抜け出せないベンダー請求として現れます。なぜなら、自分たちのドキュメントがそのサービスを通してしかレンダリングされないからです。
チームがこの判断を蒸し返せる機会は、たいていありません。初週に選んだエンジンが、3 年目にクリティカルパス上にあるエンジンです。だから正直に答える価値のある問いは「これは PDF を作れるか」ではなく — ほとんど何でも作れます — 「ドキュメントが法的あるいはアーカイブ上の成果物になったとき、これは持ちこたえるか」です。
チームが NextPDF を選ぶのは、四つの別々のリスクを一度に取り除くからです。
- PHP ネイティブである。 PDF 2.0 エンジンが、アプリの傍らで運用・スケール・保護する別のランタイムではなく、あなたのプロセス内で動作します。
- 既定でオープンである。 コアは Apache-2.0 — 読めて、フォークでき、ベンダリングできます。上位エディションは機能を追加しますが、あなたのドキュメントを人質に取ることは決してありません。
- 署名が標準準拠である。 自前の署名方式ではなく、ヨーロッパのバリデータが見たこともないものでもなく、PAdES ベースラインプロファイル（Spec: ETSI EN 319 142-1, §6ETSI EN 319 142-1 §6）です。
- 同じコードでスケールする。 初日に書いたプロトタイプが、本番のコードパスです。「では本物のエンジンに移植しよう」という工程はありません。
NextPDF のアプローチ
「NextPDF のアプローチ」という見出しのセクションこれら四つの主張はそれぞれ具体的な性質に対応しており、いずれもレビュアーが信仰として受け入れるのではなく確認できるものです。
PHP ネイティブとは、第二のランタイムが不要だということです。 NextPDF は、形式の version-of-record（Spec: ISO 32000-2, §6ISO 32000-2 §6）で定義された PDF 2.0 を対象とし、しかもそれをあなたの PHP プロセスの内側から行います。生かし続けるヘッドレスブラウザも、デプロイするマイクロサービスも、横断してマーシャリングする言語境界もありません。スタックがすでに PHP のチームにとって、運用上の表面積は以前とまったく同じ広さのまま保たれます。ブラウザ品質のレンダラーが本当に適切なツールである場合には、NextPDF はそれを駆動できます — ただしそれは継承する依存ではなく、あなたが行う選択です。そのトレードオフは統合判断ガイドの主題です。
既定でオープンとは、ロックインがないということです。 コアエンジンは Apache-2.0 です。自分のバイトに触れるすべての行を読み、プライベートなミラーにベンダリングし、もしリリースがついていけない方向に進んだらフォークし、そして出荷し続けられます。コアが生成したドキュメントは、準拠するあらゆるリーダーが開ける標準の PDF であり — あるベンダーのサービスを通してしかラウンドトリップしないプロプライエタリなコンテナではありません。商用エディションは付加的です。ハードウェアバックの署名や大量処理機能といった能力を解放しますが、それらが生成するドキュメントは、あなたが完全に所有する、ありふれた標準準拠の PDF のままです。
標準準拠の署名とは、レビューに耐える署名のことです。 ここが、「十分よい」 PDF ライブラリが静かに負債へと変わる場所です。バリデータが認識しない署名は、肝心の目的にとっては署名ではありません。NextPDF は ETSI が定義する PAdES ベースラインの進行 — B-B、B-T、B-LT、B-LTA — を対象とします。これらはヨーロッパのバリデータと監査人が目にすることを期待するレベルです。境界は段階的です。Apache-2.0 のコアは、ローカルまたは供給された鍵を使い、B-B および B-T レベル向けのソフトウェア CMS/PAdES 署名者を同梱します。一方、長期検証レベル（B-LT、B-LTA）と HSM ないしクラウド KMS バックの鍵は上位エディションの機能です。PAdES は PDF 向けの ETSI 署名プロファイルです。eIDAS — EU の規則（Spec: Regulation (EU) No 910/2014 (eIDAS), Art. 25Regulation (EU) No 910/2014 (eIDAS) Art. 25） — は電子署名に法的な立場を与えるものであり、PAdES は eIDAS の義務が帰着する PDF 上の実現です。だからこそエンジンは、ほぼ一致するものではなく、このプロファイルファミリそのものを対象とします。PAdES ベースラインプロファイルのページは、その進行と、義務が実際に必要とするレベルの選び方を解説します。
- Stay in your stackA PHP-native PDF 2.0 engine runs in-process — no second runtime to deploy, scale, or secure.
- Own what you shipApache-2.0 core: readable, forkable, vendorable. The documents are standard PDFs you keep, not a proprietary container.
- Sign for realPAdES baseline profiles (ETSI EN 319 142-1), the levels a validator and an auditor recognise — not a homegrown scheme.
- Grow without a rewriteThe prototype is the production path. Fail-fast typed inputs catch mistakes in development, where they are cheap.
プロトタイプから本番へとは、書き直しがないということです。 四つ目のリスクは最も目立ちません。デモは美しくこなすのに、本稼働するには置き換えなければならないツールです。NextPDF は、最初に書いたプログラムが、そのまま運用するプログラムになるように作られています。入力は厳格に型付けされ、エッジで検証されるため、本番で目にする失敗モードは、開発ですでに目にしたものです — 呼び出し箇所で、名前を付けて、1 バイトも書き込まれる前に。その姿勢は設計思想と推測を拒む APIの主題です。ここで重要なのは、それこそが、同じコードパスで週末のスパイクから規制対象のワークロードまでチームを運べる理由だからです。
「同じコードでプロトタイプから本番へ」の形は、呼び出し箇所で最も見えやすくなります。チームがエンジンを評価するために書くプログラムは、一行一行、本番で動くプログラムそのものです — 変わるのは署名のための材料だけです。
<?php
declare(strict_types=1);
use NextPDF\Contracts\Orientation;use NextPDF\Contracts\OutputDestination;use NextPDF\Core\Document;use NextPDF\Signature\SignatureLevel;use NextPDF\ValueObjects\PageSize;
$document = Document::createStandalone();$document->setTitle('Service Agreement');
// Typed page geometry and an enum orientation — intent is explicit,// so a typo is a type error in development, not a silent default in production.$document->addPage(PageSize::a4(), Orientation::Portrait);$document->setFont('helvetica', 'B', 16);$document->cell(0, 12, 'Service Agreement', newLine: true);
// The signature level is a recognised PAdES baseline profile, named as an// enum case — never a string the engine has to interpret. B-T is a core// software-signing level; the long-term levels (B-LT, B-LTA) are an// advanced-edition capability selected the same way.$document->setSignature(certInfo: $certInfo, level: SignatureLevel::PAdES_B_T);
// The output destination is stated, not inferred from whether a filename// was passed. The same call shape serves a spike and a production endpoint.$bytes = $document->output(dest: OutputDestination::String);このプログラムには、プロトタイプとデプロイの間で変わるものは何もありません。チームはプレースホルダを本物の署名材料に差し替え、出力をバッファではなくレスポンスへ向けるだけです。エンジン、API、そして失敗モードは、どちらの場所でも同一です — それがまさに肝心な点です。
よくある誤解
「よくある誤解」という見出しのセクションよくある反論は「オープンソースのコアということは、本物の製品は有料の壁の向こうにあり、無料部分は客寄せだ」というものです。それは関係を逆に捉えています。コアは Apache-2.0 のもとにある本番用の PDF 2.0 エンジンです — ドキュメント生成、標準準拠の出力、そして B-B と B-T レベルのソフトウェア CMS/PAdES 署名であり、チームはそれを無改変で本番運用します。上位エディションは、それを必要とするチームのために、特化した能力 — 長期検証署名（B-LT、B-LTA）、HSM およびクラウド KMS バックの鍵、スケール機能 — を追加します。テストは単純で検証可能です。コアが生成するドキュメントは、準拠するあらゆるリーダーで開ける標準の PDF であり、読み返すのに NextPDF のサービスへの依存はありません。身代金を要求される人質はいません。
第二の誤解は、「PHP ネイティブ」が「ブラウザエンジンより非力」を意味するというものです。それが意味するのは 異なる ということです。そして、ブラウザ品質のレンダラーのほうが適している正直なケースは、NextPDF を使うべきでないときに — 隠されることなく — 一覧化されています。
限界と境界
「限界と境界」という見出しのセクションこのページは採用のための論拠であって、万能だという主張ではありません。NextPDF は、PHP スタックにおけるプログラマティックで標準準拠のドキュメント生成にとって、適切なツールです。ウェブブラウザのピクセルパーフェクトな再実装ではなく、あらゆるドキュメントの問題に対する答えでもありません。その境界はNextPDF を使うべきでないときに率直に述べられています。
| Edition | Availability |
|---|---|
| Core | このエディションにはありません — ソフトウェア署名のみ（B-B、B-T）。 |
| Pro | 利用可能 — HSM および適格デバイス署名。 |
| Enterprise | 利用可能 — HSM および適格デバイス署名。 |
強調に値する境界が二つあります。第一に、署名能力は段階的です。Apache-2.0 のコアは、ローカルまたは供給された鍵で B-B と B-T レベルのソフトウェア CMS/PAdES 署名を提供します。一方、長期検証レベル（B-LT、B-LTA）と、HSM、適格デバイス、あるいはクラウド KMS を通じたハードウェアバックの鍵は、上位エディションの機能です。第二に — そしてこれはあらゆるコンプライアンス主張に対する正直な限界ですが — 適合性は、生成者ではなく独立したチェッカーによって判定されます。PAdES は PDF 向けの ETSI 署名プロファイルです。PDF/A-4（Spec: ISO 19005-4, §6ISO 19005-4 §6）は、ISO 19005-4 によって定義された、別個のアーカイブ適合レベルです。NextPDF はそれぞれを対象にできますが、プロファイルを対象にすることは適合の保証ではありません。権威ある判定は、ファイルを書いたエンジンからではなく、PDF/A バリデータまたは署名バリデータから下されます。エンジンは「合格するはず」へ導くツールとして、チェッカーは「合格する」と告げるツールとして扱ってください。
関連ドキュメント
「関連ドキュメント」という見出しのセクション- 統合判断ガイド — NextPDF を選んだら、どのパッケージとレンダラーがユースケースに合うか。
- NextPDF を使うべきでないとき — この論拠に対する正直な境界。別のツールが合うドキュメントの問題。
- PAdES ベースラインプロファイル — B-B → B-LTA の進行がどう機能し、義務がどのレベルを必要とするか。
- NextPDF の背後にある会社 — チームが依存することを選ぶエンジンを、誰が保守しているのか。
- PDF 2.0 — ISO 32000-2 で規定された、PDF 形式の現行バージョン。 NextPDF はこれを version-of-record として対象とするため、その出力はベンダー方言ではなく現行の ISO 標準に照らして測定される。
- PAdES — PDF Advanced Electronic Signatures。PDF に署名するための ETSI プロファイルファミリ（EN 319 142-1）。そのベースラインレベル — B-B、B-T、B-LT、B-LTA — は、ヨーロッパのバリデータと監査人が目にすることを期待するもの。
- eIDAS — Regulation (EU) No 910/2014。電子署名と適格署名に法的な立場を与える EU の枠組み。PAdES は eIDAS の義務が帰着する PDF 上の実現である。
- PDF/A — 自己完結し長期にわたって読める状態を保たねばならないドキュメントのための、アーカイブ適合ファミリ（ここでは ISO 19005-4 のもとの PDF/A-4）。
- Apache-2.0 — NextPDF コアの寛容なオープンソースライセンス。自分のアプリケーションをオープンにする義務なしに、エンジンを使用・改変・ベンダリング・再配布できる。
- ロックインなし — エンジンが生成するドキュメントが、生成者のサービスへのいかなる依存もなしに読める、あなたが完全に所有する標準のベンダーニュートラルな成果物であるという性質。