Stirling-PDFをDockerでセルフホストする：導入判断と運用の現実

PDFをクラウドサービスで処理することの何が問題か、と聞かれると「なんとなく怖い」で止まってしまうエンジニアは多いです。でも実際に規約を読むと、多くの無料PDFサービスはファイルを一定時間サーバに保持し、サービス改善目的での利用を許諾する条項が含まれています。士業事務所や医療機関が顧客の契約書・診断書をそのままアップロードしていたとしたら、規約違反や個人情報保護法上のリスクを静かに抱えていることになります。

そこで選択肢として浮上するのが、Stirling-PDFのDockerセルフホストです。ファイルは自分のサーバから外に出ない。それだけで解決できる問題の範囲は、思ったより広い。

ただし「セルフホストすれば万事OK」という話でもありません。更新管理・認証設定・OCR精度の限界など、SaaSを使い続けることと比べたトレードオフは確実に存在します。Stirling-PDFを実際に動かしながら、どの現場に勧めるか・勧めないかを自分で判断できる材料を、この記事で整理していきます。

Stirling-PDFとは何か——OSSとしての素性を確認する

Stirling-PDFは、PDFの結合・分割・圧縮・OCR・パスワード設定・透かしなど40以上の操作をWebUIとREST APIで提供するセルフホスト型のOSSです。GitHubのスター数は77,000超（2025年時点）、フォーク数は6,700超、リリース数は175を超えており、コミット数も4,900超と活発にメンテナンスされています。ライセンスはMITで、商用利用・改変・再配布に制限はありません。技術スタックはTypeScript（48%）とJava（43%）のハイブリッド構成です。

このプロジェクトが解決しようとしている問題は明快です。iLovePDFやSmallpdfのような無料SaaSは手軽ですが、ファイルを外部サーバに送信するという事実は変わりません。有料プランで「処理後に即削除」を謳うサービスもありますが、それを検証する手段はユーザ側にありません。Adobe Acrobat Proは月額約20ドルで、10人チームなら年間約2,660ドルかかり、それでもクラウド処理が前提です。

セルフホストという選択は、ファイルの行方を自分でコントロールするための手段です。ただし「無料で動く」ことと「タダで運用できる」ことは別の話で、Dockerホスト環境の維持・バージョンアップ対応・障害時の一次対応はすべて自分たちの責任になります。この非対称性を最初に認識しておくことが、導入判断を誤らないための前提です。

士業事務所や医療機関にとって、クラウドPDFサービスへのファイル送信は単なる「なんとなく怖い」ではなく、個人情報保護法上の委託先管理義務や、顧問先との守秘義務契約に抵触しうる問題です。日本ネットワークセキュリティ協会（JNSA）の整理によれば、他社から管理受託した個人情報の漏洩では委託元からの求償により中小企業でも数千万〜数億円規模になりうるとされており、「ちょっとPDFを結合したかっただけ」では済まないリスクが潜んでいます。

Stirling-PDFはそのリスクに対して、構造的な解決策を提供します。ただしそれはあくまでファイルの外部送信リスクに限った話であり、ホスト環境のセキュリティ設定を誤れば別の経路でリスクが生まれます。その点は次節の認証設定で具体的に触れます。

Docker 1コマンドで動かす——最小構成と最初に触るべき設定

まず最速で動かすなら docker run 1行で十分です。

docker run -d \
  --name stirling-pdf \
  -p 8080:8080 \
  -v ./stirling-data:/configs \
  stirlingtools/stirling-pdf:latest

これだけで http://localhost:8080 にアクセスすればWebUIが立ち上がります。-v ./stirling-data:/configs はコンフィグと設定ファイルの永続化用ボリュームで、コンテナを再起動してもカスタム設定が消えないようにするために必要です。

継続運用を前提にするなら docker compose で管理する方が扱いやすいです。最小構成の docker-compose.yml はこうなります。

services:
  stirling-pdf:
    image: stirlingtools/stirling-pdf:latest
    container_name: stirling-pdf
    ports:
      - '8080:8080'
    volumes:
      - ./stirling-data:/configs
      - ./stirling-data/pipeline:/pipeline
    restart: unless-stopped
    environment:
      - SECURITY_ENABLELOGIN=false
      - LANGS=ja

docker compose up -d で起動します。LANGS=ja を指定しておくと日本語UIで立ち上がります。

ここで必ず確認すべきなのが認証設定です。デフォルトでは SECURITY_ENABLELOGIN=false になっており、URLにアクセスできる人間は誰でも全機能を使えます。ローカル開発環境や完全に閉じた社内LANなら問題ありませんが、インターネットや社内の広いネットワークセグメントに公開する場合は認証を有効にしてください。

environment:
  - SECURITY_ENABLELOGIN=true
  - SECURITY_CUSTOMGLOBALAPIKEY=your-secret-api-key-here
  - LANGS=ja

SECURITY_ENABLELOGIN=true にするとログイン画面が有効になり、初回アクセス時に管理者アカウントのセットアップを求められます。SECURITY_CUSTOMGLOBALAPIKEY はAPI経由でのリクエストに使うグローバルキーで、CI/CDや自動化スクリプトから呼ぶ際に X-API-KEY ヘッダに付与します。

OCRを使う場合は追加の言語パックが必要です。デフォルトイメージには英語・ドイツ語・フランス語・ポルトガル語・中国語（簡体字）が含まれていますが、日本語（jpn）は含まれていません。日本語OCRが必要な場合は、Tesseractの日本語パックを追加インストールするか、言語パック入りのカスタムイメージをビルドする必要があります。これは最小構成の「次の一手」として覚えておいてください。

主要機能の実務評価——使える・惜しい・注意が要る

40以上の機能をすべて評価しても実務の役に立たないので、使用頻度が高い6機能に絞って率直に評価します。

機能	評価	コメント
PDF結合	✅ 使える	ページ順の並び替えもUIで直感的に操作できる。複数ファイルのドラッグ&ドロップに対応
PDF分割	✅ 使える	ページ範囲指定・奇数偶数分割など柔軟。バッチ処理もAPI経由で可能
圧縮	⚠️ 惜しい	圧縮率の選択肢はあるが、Adobe Acrobatの最適化と比べると品質劣化が出やすい
パスワード設定	✅ 使える	閲覧・編集・印刷の権限を個別に設定可能。実務で十分なレベル
透かし	✅ 使える	テキスト透かしはUIから手軽に設定できる。画像透かしも対応
OCR（Tesseract）	🔴 注意が要る	活字の横書き文書なら実用的。手書き・縦書き・複雑なレイアウトは精度が落ちる

表の「惜しい」「注意が要る」には、それぞれ実際に使って引っかかりやすいポイントがあるので、もう少し掘り下げます。

圧縮は、スキャン画像が多いPDFや印刷用の高解像度PDFを扱う場面で問題が出やすいです。圧縮率を上げると画像の劣化が目立ち、「メール添付サイズに収めたいけど読めなくなった」という状況になりがちです。Adobe Acrobatの「PDFを最適化」と比べると、同じ圧縮率でも仕上がりの差が出ます。用途が「社内共有用の軽量化」程度であれば十分ですが、印刷物や顧客への正式提出物に使う場合は事前に品質を確認してください。

OCRについては特に注意が必要です。StirlingのOCRエンジンはTesseractベースで、スキャンした活字文書の横書きテキスト抽出には一定の精度が出ます。しかし手書き文書・縦書きレイアウト・表が混在する複雑な帳票では精度が大きく落ちます。

医療の診断書や行政の申請書類のように、レイアウトが複雑な日本語文書をOCRにかける場合は、本番投入前に代表的なサンプルで精度を確認してください。「動くには動くが、後から修正コストがかかる」という状況は、OCRに限らずTesseractベースのツール全般に共通する落とし穴です。

もう一点、フロントエンド専用機能の存在も把握しておく必要があります。「ビジュアル署名」や「PDFビューア」などの操作はWebUI上でのみ動作し、REST APIからは呼び出せません。自動化パイプラインを設計する際に「この操作もAPIで叩けるはず」と思い込んで設計すると、後から詰まります。

API連携と自動化——curlからCI/CDまでの現実

Stirling-PDFはREST APIを標準で提供しており、Swagger UIが /swagger-ui.html で確認できます。ほぼすべての操作がAPIエンドポイントを持っており、curlやHTTPクライアントから直接呼び出せます。

たとえばOCRエンドポイントへのリクエストはこうなります。

curl -X POST http://localhost:8080/api/v1/misc/ocr-pdf \
  -H 'X-API-KEY: your-secret-api-key-here' \
  -F 'fileInput=@./document.pdf;type=application/pdf' \
  -F 'languages=jpn' \
  -F 'ocrType=skip-text' \
  -F 'deskew=true' \
  -F 'clean=true' \
  -o searchable.pdf

multipart/form-data でPDFファイルを送り、処理済みのPDFをレスポンスとして受け取る形式です。languages=jpn で日本語パックを指定し、deskew=true で傾き補正、clean=true でノイズ除去を有効にしています。

CI/CDへの組み込みも現実的です。「契約書PDFをリポジトリにコミットしたら自動でパスワードを設定してストレージに保存する」「フォームから受け取ったPDFを圧縮してメール添付サイズに収める」といったパイプラインは、GitHub ActionsやJenkinsのステップとして素直に書けます。HTTPリクエストを投げてファイルを受け取るだけなので、言語やフレームワークを選びません。

ただし前述の通り、フロントエンド専用機能はAPIから呼べません。パイプライン機能（複数操作の連結）も、API非対応の操作を含む場合は組み合わせられない制約があります。自動化設計の前にSwagger UIで対象操作のエンドポイントが存在するかを確認するのが、無駄な実装を避ける近道です。

本番運用でAPIを使う場合は SECURITY_CUSTOMGLOBALAPIKEY を必ず設定してください。認証なしでAPIが公開されていると、ネットワーク内の誰でもPDFを処理・取得できる状態になります。キーはコンテナの環境変数として渡し、ソースコードやdocker-compose.ymlに直書きせず .env ファイルで管理してください。

どの現場に勧めるか——SaaSとの使い分けと運用コストの現実

まず比較の軸を整理します。

	Stirling-PDF	iLovePDF	Adobe Acrobat Pro	PDF24
コスト	ホスト費用のみ	無料〜年約60ドル	月約20ドル/人	無料（広告あり）
ファイルの扱い	自サーバ完結	外部サーバに送信	外部サーバに送信	外部サーバに送信
API	あり（REST）	あり（有料プラン）	あり（有料）	なし
OCR精度	Tesseract（中程度）	高め	高め	中程度
編集機能	基本操作中心	中程度	高機能	基本操作中心
運用管理	自己管理	不要	不要	不要

Stirling-PDFが明確に優位な場面は、ファイルを外部に出せない制約がある現場です。

税理士・社労士・弁護士事務所（顧問先の財務資料・契約書・従業員情報を扱う）
医療機関・調剤薬局（患者情報・診断書・処方箋の電子化処理）
行政・自治体の内部システム（住民情報を含む帳票処理）
社内の自動化パイプラインに組み込みたいエンジニアチーム

これらの現場に共通するのは、「ファイルがどこに行ったか分からない」という状況を制度上・契約上・組織の説明責任として許容できないという点です。Stirling-PDFのセルフホストは、その問いに対して「自分のサーバの中にある」と明確に答えられる構造を作ります。

逆に、Stirling-PDFを無理に使わなくていい場面もあります。機密情報を含まないPDFを個人や小規模チームで処理するだけなら、PDF24やiLovePDFで十分です。PDFのフォームフィールド作成やAcrobat固有の高度な編集が必要な場合は、Stirling-PDFでは代替できません。また、Dockerホスト環境を新たに用意するコストや、障害時に対応できる担当者がいない環境では、SaaSの「管理不要」という価値の方が上回ります。導入を検討する際は、「何を解決したいか」よりも「誰が運用するか」を先に決めた方が判断が早いです。

運用コストについては正直に言うと、「無料で動く」は本当ですが「タダで運用できる」は幻想です。バージョンアップは自動では行われないため、セキュリティパッチが出た際には手動でイメージを更新する必要があります。restart: unless-stopped を設定していても、ホストOSの再起動後にコンテナが上がらないといったトラブルは起きます。ストレージの肥大化（処理済みファイルの残留）やログの管理も、SaaSなら気にしなくていいことが全部自分の仕事になります。

それでも、機密ファイルを扱う現場でのセルフホストの価値は運用コストを上回ります。士業事務所や医療機関にとっては、クラウドサービスへのファイル送信を構造的に排除できることが、コンプライアンス上の説明責任を果たす手段になります。エンジニアチームにとっては、APIで自動化できるPDF処理基盤を社内に持てることが、繰り返し作業の削減につながります。

導入を検討するなら、まずローカルで docker compose up -d を実行して実際に触ってみてください。UIの使い勝手とAPIの動作を確認した上で、自分のチームの運用体制と照らし合わせて判断するのが現実的です。Stirling-PDFは「とりあえず動かす」ハードルが低いので、評価コストは低く抑えられます。

株式会社ホコサキは山口県宇部を拠点に、Web制作・業務システム開発・AI活用支援・DX推進を手がけています。Stirling-PDFのような社内インフラの選定・導入支援から、PDF処理を含む業務自動化の設計まで対応しています。導入の相談はお問い合わせページからどうぞ。