すべてを画像に潰さずに PDF を結合する

「この 5 つの PDF を結合して」という一言は、二つのパイプラインを指しうる。一つは既存のページオブジェクトを一つのファイルに連結する。もう一つはすべてのページをビットマップに印刷し、その画像を新しい PDF に詰め込む。どちらも添付ファイルは一つになる。テキストとベクトルを保つのは前者だけだ。

構造的な結合がしていること

PDF123 では PDF の結合 が、各ファイルのページオブジェクトを繋ぐことで二つ以上の PDF を結合する。サーバー側の経路は、空の基底に対して入力群を --pages で扱う qpdf を走らせる。ページストリームはスクリーンショットではなく、ページとして移動する。埋め込みフォント、ベクトル、既存のしおりは、そのページと一緒に運ばれる。この経路はページを画像にラスタライズしないので、ボーンデジタルの契約書は結合後も検索とコピーができる。

アップロード順が既定の出力順だ。HTTP フォームは一つのリクエストで fileInput パートを繰り返し受け取れる。バッチの大きさはアップロード上限で決まり、二ファイルという硬い上限はない。任意の sortType=byFileName は、結合前にファイル名で入力を並べ替える。各ソースのしおりは生き残りうるが、入力にアウトライン木が無かったなら、結合が完璧な目次を発明するわけではない。

単一ファイルのアップロードは、その PDF をそのまま通す。二つ以上なら、選んだ順で入力のページを連結した一つの merged.pdf になる。OpenAPI、MCP、pdfx merge が公開するのは同じ op id なので、スクリプトとブラウザのクリックが「結合」の意味で静かに食い違うことはない。

人が誤ってラスタライズしてしまうとき

「結合」と称する処理には、先に画像へ書き出したり（ファックスゲートウェイ、スキャンアプリ、画面解像度での印刷 PDF）、結合前に注釈をビットマップへ平坦化したりするものがある。ファイルサイズが跳ね上がり、OCR をもう一度かける必要が生じ、ズームすると画素の縁が見える。

元がすでにデジタルの PDF なら、ストリームの結合を選ぶ。使えるテキストの無いスキャンが入力のときだけ OCR を検討し、ここでの OCR が Markdown（text/markdown）を返すのであって、隠しテキスト層を持つ PDF を重ね直すのではないことを覚えておく。ラスタライズしてから OCR するのは、ボーンデジタルのファイルを結合するのとは別の製品経路だ。

ページの画像が必要なら、それは変換の仕事（PDF から画像）であり、結合ではない。二つの意図を混ぜると、「結合した」ファイルが文書の数メガバイトの写真アルバムになる。構造的な結合のあとでも 圧縮 でストリームを縮められるが、焼き込んだラスタの平坦化は元に戻らない。

結合が約束しないこと

結合はページサイズを正規化しないし、ファイルをまたいでフォントを統一しないし、目次を一から組み直さない。暗号化された入力を勝手に復号もしない。ソースがパスワード保護されているなら先に解除する。一部の裁判所ポータルが期待する portfolio／パッケージ形式のコンテナを置き換えることもない。出力は普通の複数ページ PDF 一つだ。

これらの限界は、ブラウザでも REST でも MCP でも pdfx でも同じだ。op は自動化にとって出力が予測可能であり続けるよう、意図的に狭くしてある。順序付きの多段処理（結合し、透かしを入れ、圧縮する）が必要なら、第二の「スマート結合」フラグを発明せず、順序付きの steps を渡す POST /api/v1/pipeline を使う。

実行方法

ブラウザなら PDF の結合、あるいは fileInput パートを繰り返して POST /api/v1/general/merge-pdfs を呼ぶ（開発者向け）。シェルからなら：

pdfx merge a.pdf b.pdf -o merged.pdf

ホスト版またはセルフホスト版の base に対してなら：

pdfx --cloud --api-base "$API_BASE" --api-key "$KEY" merge a.pdf b.pdf -o merged.pdf

公開サイトの匿名カタログ呼び出しにキーは不要だ。キーが効くのは、安定した自動化身元が必要な場合と、アクセス制限付きのセルフホストサーバーだ。curl と MCP でも同じ op を扱う方法は 同じ操作、四つのクライアント にある。