NextPDF を使うべきではない場面

Spec: ISO/IEC 25010, §3.26 Spec: ISO 24495-1 Evidence: Editorial

概要

このページは、通常ベンダーが書かない種類のページです。NextPDF が適切なツールではない場面と、代わりにどのような種類のツールが適しているかを示します。適合しないケースを率直に挙げることで、エンジンを除外すべきときには素早く除外できるようにします。

これは率直な境界表明であり、機能一覧に「できない」という言葉を付け足しただけのものではありません。

なぜこれが重要か

最もコストのかかる統合は、そもそも始めるべきではなかった統合です。ツールの選定は、評価段階で正しく行えば低コストで済みます。契約が結ばれ、パイプラインが本番環境に入った後では、修正に非常に大きなコストがかかります。

優れたエンジンは、その判断を早い段階で下せるようにします。ソフトウェア品質のガイダンスはこれを適合性認識性と呼びます。製品がニーズに合うかどうかを、そのドキュメントや第一印象から判断できる能力のことです（ Spec: ISO/IEC 25010, §3.26 ）。常に「はい」としか言わないページは、そのテストに意図的に合格しません。このページは、「いいえ」が率直な答えである場面では「いいえ」と言います。

手短に言えば

次のような場合は、NextPDF 以外のものを選んでください。

任意のモダンな Web ページをピクセル単位で忠実にレンダリングする必要がある場合。つまり、完全な CSS、Web フォント、JavaScript 駆動のレイアウトなどが必要な場合です。それはブラウザの仕事です。
スキャンされた、または画像のみの PDF を OCR または再構築して構造化テキストにする必要がある場合。それは生成の問題ではなく、OCR/ドキュメント理解の問題です。
権威ある答えとしての適合性の判定（PDF/A、PDF/UA、PAdES）が必要な場合。NextPDF は適合を意図した構造を生成しますが、実際に適合したかどうかは独立したバリデーターが判断します。
PDF を生成したり検査したりするのではなく、サードパーティ製 PDF の大規模なインタラクティブ編集や墨消しを中心的なワークロードとして必要とする場合。
サポートされる PHP の下限よりも古いランタイムを使用していて、バックポートの経路を利用できない場合。

いずれの場合も問題は品質ではなく分類です。別の種類のツールこそが正しい答えになります。

NextPDF のアプローチ

NextPDF は、PDF 2.0 ドキュメントを生成し、構造的な事実について検査するための PHP エンジンです。その設計、すなわち明示的な意図、フェイルファストな入力、インプロセスかつ決定的であることは、その仕事に合わせて調整されています。率直な境界は、課題が根本的に異なる形をしている場面にあります。

この表は、適合しない各ケースについて、なぜ形が合わないのか、そしてどの分類のツールが適しているかを対応づけます。特定の製品名は挙げません。重要なのは分類です。

あなたの課題が…の場合	NextPDF の形が合わない理由	代わりに適するもの
任意のモダンな Web ページをピクセル単位で忠実にレンダリング	インプロセスの HTML/CSS エンジンは、予測可能で決定的な出力のために、定義され文書化されたサブセットを対象とするものであり、スクリプトを含む進化し続ける Web プラットフォーム全体を対象とするものではない	実ブラウザエンジン（ヘッドレスブラウザのレンダラー）。エコシステムのブラウザブリッジ経由で駆動
スキャンされた、または画像のみの PDF を構造化テキストに変換	NextPDF は OCR やドキュメント理解を行わない。生成と構造的な検査を行うものであり、ピクセルを意味として解釈することはしない	専用の OCR /ドキュメント理解パイプライン。その後 PDF を生成する必要がある場合は、その出力を NextPDF に渡す
権威ある適合性の判定	インプロセスのチェックは必要だが十分ではない。設計上、それらは構造的な事実を報告するものであり、pass/fail の判定を下すものではない	独立したバリデーター（たとえば、認知された PDF/A またはアクセシビリティチェッカー）をゲートとして利用
任意の PDF の大規模なインタラクティブ編集/墨消しを中心的な仕事とすること	このエンジンは生成と構造的な検査に最適化されており、信頼できないサードパーティ製ファイルを汎用的にラウンドトリップ編集するためのものではない	editing/redaction のワークフロー向けに作られた種類のツール。produce/inspect の部分には NextPDF を使用
サポートされる PHP の下限を下回るランタイム	このエンジンは、意図的にモダンな PHP 言語機能の上に構築されている	該当する場合は文書化されたバックポートの経路。そうでない場合は別のツールチェーン

繰り返し現れるテーマは、エンジン自身の誠実さです。インプロセスの適合性チェックは、その出力の中で同じことを述べています。つまり、それらは必要だが十分ではないのです。問題のない結果は「ISO 適合を確立するものではない」とされ、判定は「独立したバリデーターに属する」とされています。高速な PDF インスペクターも同じです。それは「高速な構造的トリアージであり、バリデーターではない…署名の検証も、コンテンツの復号も、適合性の主張も行わない。その結果は信頼の判定としてではなく、ルーティングの入力として扱うこと。」と述べています。このエンジンは、自らについて過大な主張をすることを控えます。だからこそ、誇大に売り込むことを控えるページは、エンジンと一貫しているのです。

境界の中には、固定された線ではなくエディション上の境界であるものもあります。たとえばアーカイブ用（PDF/A）の生成は、欠けている機能ではなく、上位ティアの機能です。このエンジンは、拒否ではなく、実行可能なアップグレードの経路を提示します。

PDF/A archival production — edition availability
Edition	Availability
Core	Core には含まれません。アーカイブ用の API を呼び出すと、不明瞭に失敗するのではなくそれを有効にするパッケージ名を示す、対応可能なメッセージが返ります。プレーンな PDF 2.0 出力は完全に利用できます。
Pro	利用可能です。PDF/A アーカイブ適合生成は Pro ティアの機能です。
Enterprise	利用可能です。上位ティアに含まれます。

したがって「NextPDF はアーカイブができない」というのは、Core における誤った読み方です。適切なエディションでは可能であり、推測させたり黙って失敗したりするのではなく、その旨を明示的に伝えます。本当の境界は、依然として前述のものです。すなわち適合性の判定は、どのエディションでも常に独立したバリデーターに属します。

エビデンスが示すこと

このページは Evidence: Editorial です。これは論拠に基づく境界判断であって、コードやベンチマークに基づく主張ではありません。その旨が率直にラベル付けされています。これを単なる意見にとどめない要素が 2 つあります。

エンジン自身の成果物も、自らの言葉で同じことを認めています。適合性の経路は自らを「必要だが十分ではない」と宣言し、判定を独立したバリデーターに委ねます。高速なインスペクターは自らを「構造的トリアージであり、バリデーターではない」と宣言します。ここでの境界表明は、エンジンが自らを説明する仕方と一貫しており、それより誇張されたものではありません。
境界を明示するという規律は、 Spec: ISO/IEC 25010, §3.26 （適合性認識性 — ドキュメントから適合性を判断すること）と Spec: ISO 24495-1, §5 （読者が必要とするものと注意事項を先に提示すること）に根ざしています。

境界が実際にはコードレベルの挙動である場合 — たとえばインプロセスの適合性チェックが権威を持たないこと、あるいはアーカイブがエディションの機能であること — その挙動は Evidence: Code-backed エビデンス付きで、その挙動を扱うページ上に示されます。このページの役割は率直な見取り図を示すことであり、個々の論点を証明することではありません。

実践的な例

率直に読めば、これは短いチェックリストです。いずれかの行が当てはまる場合、NextPDF はその仕事には適さないツールである可能性が高いです。それでも、同じシステムの別の部分を担うことはあり得ます。

Decision check — is NextPDF the wrong shape here?

[ ] You must render arbitrary modern web pages pixel-for-pixel,
    including JavaScript-driven layout.            → use a browser renderer
[ ] Your input is scanned/image-only PDFs you must
    turn into structured, searchable text.         → use an OCR pipeline
[ ] You need a binding PDF/A or PDF/UA pass/fail
    as the authoritative answer.                   → use an independent validator
[ ] The core workload is editing/redacting
    untrusted third-party PDFs.                    → use an editing/redaction tool
[ ] Your runtime is below the supported PHP floor
    and the backport path does not apply.          → use a different toolchain

None of the above ticked?
    → NextPDF is plausibly a good fit. Confirm against
      the design philosophy and the integration decision guide.

非対称性に注目してください。チェックが入るのは、NextPDF をその仕事から除外するという意味であって、システム全体から除外するという意味ではありません。パイプラインでは、あるツールで OCR を実行し、NextPDF で最終的な PDF を生成し、3 つ目のツールで適合性を検証することがよくあります。適切なツールを、適切な段階で使うということです。

よくある誤解

よくある誤読は、「使うべきでない場面」のページを弱さの告白だと捉えることです。むしろ逆です。自らの境界を引けるほど自信のあるエンジンこそ、計画を立てやすいものです。リスクは、明示された制約にあるのではありません。リスクは、誰も書き留めなかったために本番環境で初めて気づく制約にあります。

2 つ目の誤読は、これらをシステム全体に対する恒久的な判定として扱うことです。そうではありません。「任意の Web ページのレンダリングには適さないツール」だからといって、「たまたまチャートを含む請求サービスには適さないツール」という意味にはなりません。それは、レンダリングを委譲し、生成は手元に残すという意味です。境界はプロジェクト単位ではなく、仕事単位です。

制限と境界

このページ自体にも境界があります。ここでは適合しない分類を述べているのであって、名前を挙げた代替案の順位付きリストを示しているのではありません。特定の製品名を挙げて比較することは、方針上ここでは対象外です。適切な具体的選択は、あなたの制約条件によって決まります。関連する統合判断ガイドは、そうした比較を行わずに、ユースケースをエコシステム自身のコンポーネントに対応づけます。

これはまた、このレビュー時点における一時点の判断でもあります。機能の境界、とりわけエディションの境界は、エンジンの進化とともに変わり得ます。これに対して適合性の判定の境界は構造的なものであり、変わることは想定されていません。生成機能がどれほど高機能になっても、適合性は独立したバリデーターが判断します。

最後に、「editorial（編集上）」は率直なエビデンスレベルです。このページは論理的に説明します。ベンチマークを行ったり、コードを引用したりはしません。境界が本当にコードの挙動である場合、その証拠はそれを扱うページ上に、そのページのエビデンスレベルとともに置かれています。

用語集

Editorial（エビデンスレベル） — 意図的で論拠に基づく判断を述べたページ。測定したりコードから引用したりするのではなく、論証によって示すもの。
必要だが十分ではない — インプロセスのチェックに対する意図的な表現。実際の手がかりではありますが、適合性の判定ではありません。権威ある判定は独立したバリデーターに属します。
適合性とサポートの違い — 適合性は出力されたドキュメントの二値的な性質（指定されたプロファイルを満たすか満たさないか）です。サポートはエンジンの性質（ある機能を宣言された度合いで実装していること）です。バリデーターは前者を測定し、エンジンは後者を提供します。
PDF/A — 長期アーカイブ用 PDF のための ISO 19005 系のプロファイル群です。その生成はエディションの機能であり、適合性の判定は常に独立したバリデーターのものです。
OCR — 光学文字認識（Optical Character Recognition）。ページ画像をテキストに変換すること。PDF 生成とは別の問題の分類。初出のためここで省略せずに記載。