デスクトップアプリを作らない理由

ファイルがプライベートネットワークの外に出られないとき、次に来る要望は Windows や macOS のインストーラーであることが多い。私たちはその形を意図的に断った。デスクトップ GUI は第二の UI コードベースになる。それらの木が分かれた瞬間、「アプリ」と /api/v1/ の間の機能のずれはほぼ避けられない。

制約は境界であり、外装ではない

「バイトがここに留まる」は、自分で動かす pdfx-server で満たされる。WinForms や Electron である必要はない。Compose と pdfx（ローカル、または自分の base URL に対する --cloud）が、ブラウザ、REST、MCP、CLI の背後に一つの操作カタログを保つ。

そのスタックの立て方は セルフホスト に文書化されている。Compose は task docker:build／task docker:up（API は :8080、ポータルは :3000）、ローカル作業はポータルの隣でのネイティブな task pdfx:dev だ。固定のゲートが必要なときは SECURITY_CUSTOMGLOBALAPIKEY を設定する。本記事が扱うのは、そのスタックをデスクトップ製品として包まない理由だけだ。

--cloud を付けないローカルの pdfx は、ファイルのあるマシン上で pdf-core を走らせる。GUI を一度も必要としなかったオフラインのバッチ作業は、それですでに足りている。クラウドモードは、同じ CLI が curl と同じ multipart の契約で、セルフホストまたはホスト版の API base を叩くためのものだ。

デスクトップ版を作ると何がかかるか

コンシューマ向けのスイートは、キャンバス編集、視覚的な比較、ストア向けのインストーラーに最適化されている。その面を維持するとは、エージェントがすでに呼んでいる OpenAPI の契約ではない GUI に、新しい op（結合のフラグ、OCR のモード、sanitize の既定値）をその都度複製することを意味する。

プラグインとストアのチャネルはサポートを増やすが、MCP や Idempotency-Key の挙動は改善しない。ストアの審査サイクルや OS の権限プロンプトに費やす時間は、/v1/openapi.json には落ちない。デスクトップの木が API に無い結合オプションを出せば（あるいはその逆なら）、自動化とデモが静かに食い違う。

OCR は重複が痛む具体例だ。現在のサーバー側の経路は Markdown（text/markdown）を返し、Auto と Force（Force は ocrType=force-ocr）のモードがある。「隠し層付きの検索可能 PDF」を今も約束するデスクトップ UI は、別のパイプラインについて嘘をつくことになる。op の定義を一つに保てば、この分裂は避けられる。

一つのカタログ、四つのクライアント、第二の UI はゼロ

製品にはすでに同じ op への四つの取っ手がある。ポータルのフォーム、/api/v1/… への curl、/mcp の MCP、ローカルまたはクラウドの pdfx だ。結合 が具体例になる。Process をクリックしても fileInput パートを POST しても、ページを画像にラスタライズせず、アップロード順で PDF を結合する。

デスクトップ版は、別のリリース列車を持つ第五の取っ手になる。私たちが気にする失敗モードは「トレイアイコンが無い」ことではない。「デモページは動き続けるのに、同じ op に依存したスクリプトが静かに退行する」ことだ。

主張していないこと

デスクトップを省いても、ブラウザに Acrobat 級の対話的な編集が生まれるわけではない。フォームツールと HTTP のジョブが製品のままだ。オンラインの編集キャンバス、視覚的な比較、コンシューマ向けの署名 UI は意図的に範囲外としている。プライベートな配備が必要なら compose up して、クライアントを自分の API base に向ける。画素単位のエディタが必要なら、そのために作られたスイートを使う。PDF123 の .exe を待ってはいけない。

ホスト版 PDF123 は速い匿名の経路のままだ。セルフホストはファイアウォールの内側にある同じツールキットである。どちらも第三の、ずれていくデスクトップ版ではない。ブラウザ専用コンバータとの対比は PDF ツールキットをセルフホストする理由。買えるものと運用するものは セルフホストが実際にもたらすもの。デスクトップ以外の四つのクライアントがどう揃うかは 同じ操作、四つのクライアント にある。