Stirling-PDFが選ばれる理由｜PDFsam・PdfDingとの違いと選定基準

社内の機密 PDF を ilovepdf.com や Smallpdf にアップロードして加工する運用は、便利な反面、ISMS や P マーク監査で「機密ファイルを外部送信している」と指摘される代表的なポイントです。一方で、社員全員に Adobe Acrobat Pro のライセンスを配布するのは予算的に現実的でないケースも少なくありません。

そこで選択肢に上がるのが、自社サーバー内で PDF 加工を完結できる OSS です。なかでも GitHub で最も多くのスターを集めている PDF アプリケーションが「Stirling-PDF」です。Docker で 1 コマンド起動でき、編集・変換・OCR・電子署名・自動化までを 1 つのコンテナでカバーします。

ただし、業務導入の判断には「無料で本当に十分か」「組織で運用する際にどこから費用が発生するか」「PDFsam や PdfDing のような類似 OSS とどう違うか」といった疑問が残ります。これらの問いに答えないまま PoC を始めると、後で要件を満たせずに巻き戻しが発生します。

本記事では、Stirling-PDF の公式ドキュメントと GitHub リポジトリの情報をもとに、機能カテゴリ・Docker での立ち上げ手順・REST API・無料 OSS 版と有償プランの境界・類似 OSS との比較を整理し、業務導入時の選定基準を解説します。

Stirling-PDFとは｜セルフホスト型OSSのPDFプラットフォーム

Stirling-PDF は、PDF の編集・変換・OCR・電子署名・自動化を 1 つのアプリケーションで完結できる、セルフホスト型のオープンソース PDF プラットフォームです。リポジトリは Stirling-Tools/Stirling-PDF で公開されており、2026 年 6 月 30 日時点で 85,286 スター・7,407 フォークを記録しています。直近のコミット日も 2026 年 6 月 30 日で、アーカイブ・フォーク・無効化のいずれにも該当しない、メンテナンスが継続している現役プロジェクトです。

公式の位置付けは「The Open-Source PDF Platform」であり、PDF ファイルを外部サービスに送らずにブラウザ UI から編集・変換・自動化することを主眼に置いています。

プロダクトの位置付けと開発体制

• 主要言語: Java（Spring Boot ベース）
• ライセンス: GitHub 上の SPDX 識別子は NOASSERTION で、README 上は「open-core」モデルが明記されています。コア部分は OSS で提供しつつ、組織向け機能（SSO・SLA など）は有償プランで提供されます
• 公開状態: パブリックリポジトリで、archived / fork / disabled いずれも false
• 開発元: Stirling-Tools（コミュニティ + 商用プラン提供主体）

なお、SPDX 識別子が NOASSERTION となっている点は、コアコードを商用利用する際に LICENSE ファイルとリポジトリ内の表記を改めて確認する必要があることを意味します。詳細は記事末尾の注意点で改めて触れます。

提供形態の全体像

Stirling-PDF は複数の提供形態を持ち、業務要件に応じて選択できます。

• デスクトップアプリ: Windows / macOS / Linux 向けにバイナリ提供
• Docker / Kubernetes: セルフホストの主要経路。本記事ではこの経路を中心に解説します
• マネージド SaaS（stirling.com）: 公式運営の SaaS 版。サーバー運用を委ねたい場合の選択肢
• ブラウザ UI: いずれの形態でも Web ブラウザから操作可能

セルフホストで使う場合、Docker イメージ 1 コマンドで起動できるため、PoC のハードルは低めです。

Stirling-PDFが選ばれる理由｜業務利用での 3 つの強み

業務利用の文脈で Stirling-PDF が評価される理由は、大きく分けて 3 つあります。検索者が「上長に導入を説明する」場面で根拠として使える論点として整理します。

PDFを外部送信しないコンプライアンス適合性

Stirling-PDF の最大の特徴は、PDF ファイルが自社サーバーの外に出ない点です。ilovepdf.com・Smallpdf・Adobe Acrobat オンライン等の SaaS では、PDF を一旦サービス事業者のサーバーに送信する必要があります。これは利便性が高い反面、ISMS や P マーク、業界別の機密管理要件（金融・医療・法務など）に照らして問題視されることがあります。

Stirling-PDF を自社サーバー（オンプレミス、社内 VPC、エアギャップ環境など）にデプロイすれば、PDF の処理がすべて自社管理下のネットワーク内で完結します。コンプライアンス監査で「外部送信していない」事実を説明できるのは、SaaS 型 PDF ツールにはない強みです。

60 を超えるPDF操作を 1 コンテナで完結

公式は「50+ PDF tools」と表記していますが、ドキュメント上は V2 以降 60 を超える機能が搭載されています。代表的なものを挙げると次のとおりです。

• 結合・分割・回転・並べ替え・ページ抽出
• PDF と画像／Office 文書の相互変換
• OCR（Tesseract）によるスキャン PDF の文字認識
• パスワード設定・暗号化・墨消し（redact）・電子署名
• フォーム入力・注釈・テキスト編集・2 つの PDF の比較

これらが 1 つの Docker コンテナに同梱されるため、機能ごとに別ツールを組み合わせる必要がありません。社内で扱う PDF 操作の大半をこのコンテナでカバーできます。

REST API とノーコードパイプラインで自動化できる

UI 操作だけでなく、ほぼ全ての機能が REST API として呼び出せます。社内システムから「契約書を OCR してテキスト化する」「申込書 PDF にウォーターマークを付けて配布する」といった処理を自動化できるのは、業務システムへの組み込みを検討する技術者にとって大きな利点です。

加えて、ノーコードで複数操作を連結できる「パイプライン」機能も備えています。たとえば「アップロード → OCR → 圧縮 → 透かし追加 → 結合」といった処理を画面上で定義し、定常運用に乗せられます。

Stirling-PDFの主な機能カテゴリ

公式ドキュメントを参考に、機能を 6 つのカテゴリに分けて代表的なものを整理します。すべての機能を網羅したい場合は、公式の機能一覧ドキュメントを参照してください。

ページ操作（分割・結合・回転・並び替え）

複数 PDF の結合（merge）、ページ単位またはブックマーク単位での分割（split）、回転、ページの並び替え、特定ページの抽出・削除など、PDF を構成するページ単位の操作を一通りカバーします。「契約書一式を 1 つの PDF にまとめたい」「議事録から特定ページだけ抜き出したい」といった日常業務に直接対応します。

変換（PDF と Office・画像の相互変換）

PDF と画像（PNG / JPEG 等）、PDF と Office 文書（Word / Excel / PowerPoint）の相互変換に対応します。Office 文書の変換は LibreOffice をバックエンドに呼び出す方式のため、フォント・レイアウト再現性は環境依存となります。高品質な変換が必要な場合は、後述する latest-fat イメージの利用が推奨されています。

OCR（Tesseract ベース）

OCR エンジンには Tesseract が組み込まれており、スキャン PDF からテキストを抽出して検索可能 PDF を生成できます。多言語対応で、日本語を含む追加言語ファイルは /usr/share/tessdata にマウントする運用です（後述）。契約書・申込書のテキスト化、社内ナレッジの全文検索化といったユースケースに使えます。

セキュリティ（パスワード・墨消し・署名・透かし）

• パスワード追加・除去、PDF 全体の暗号化・復号化
• 墨消し（redact）による機密箇所のマスキング
• 電子署名（証明書ベース）
• 透かし（ウォーターマーク）
• メタデータのサニタイズ（作成者・編集履歴の除去）

機密情報を含む PDF の二次配布前処理や、法的要件のある文書への署名付与に活用できます。

編集（テキスト・画像・注釈・比較）

PDF 上のテキスト編集、画像追加、フォーム記入、注釈、2 つの PDF の並列比較に対応します。Adobe Acrobat の代替として、最低限の編集ニーズは満たせる構成です。

自動化（ノーコードパイプライン + REST API）

ノーコードの「パイプライン」UI で複数操作を連結でき、定型業務をテンプレート化できます。さらにほぼ全ての機能が REST API として公開されているため、社内の業務システム（電子契約、ワークフロー、CRM 等）から呼び出して、Stirling-PDF を裏方の PDF 処理エンジンとして組み込むことも可能です。

公式の全機能一覧と各機能のパラメータ仕様は、公式ドキュメントで確認できます。

Dockerで立ち上げる手順

PoC の最初のステップは、ローカル端末や社内検証サーバーで Docker コンテナを起動し、ブラウザ UI で機能を試すことです。公式のDocker インストールガイドに沿った最小構成を解説します。

最小コマンドでの起動

公式ドキュメントが提示する最小構成の docker run コマンドは次のとおりです。

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

（出典: Stirling-PDF 公式ドキュメント Docker Install）

起動後、ブラウザで http://localhost:8080 を開くと UI にアクセスできます。設定とデータベースは ./stirling-data にマウントされ、コンテナを再作成しても永続化されます。

docker-compose で起動する場合の公式例は次のとおりです。

services:
  stirling-pdf:
    image: stirlingtools/stirling-pdf:latest
    container_name: stirling-pdf
    ports:
      - '8080:8080'
    volumes:
      - ./stirling-data:/configs
    restart: unless-stopped

（出典: Stirling-PDF 公式ドキュメント Docker Install）

3 つのイメージ（latest / latest-fat / latest-ultra-lite）の使い分け

公式は用途別に 3 種類の Docker イメージを提供しています。選定軸は「必要な機能の範囲」と「サーバーリソースの余裕」です。

業務 PDF（日本語フォントを含む Office 文書変換）を扱う場合は latest-fat を選んでおくと、フォント不足によるレイアウト崩れを避けやすくなります。

推奨ボリュームと環境変数

公式ドキュメントで推奨されている主要ボリュームと環境変数は次のとおりです。

複数ユーザーで運用する場合は SECURITY_ENABLELOGIN=true を設定し、認証 ON にした上でアクセス制御を構成します。なお、後述のとおり OAuth2 や SAML2 による SSO 連携は有償プラン側の機能です。

REST API と自動化パイプライン

Stirling-PDF の業務価値は UI 操作だけでなく、社内システムへの組み込みにあります。

ほぼ全ての PDF 操作機能は REST API として公開されています。API リファレンスは Scalar 上で公開されており、Stirling-PDF Processing API リファレンスからエンドポイント・リクエスト形式・レスポンスを確認できます。

実務での典型的な組み込みパターンは次のとおりです。

• 契約書バッチ OCR: 社内ストレージに溜まった契約書 PDF を夜間バッチで OCR し、テキスト化したものを検索エンジンに投入する
• 申込書 PDF 化パイプライン: Web フォームの入力内容を PDF テンプレートにマージし、透かし・署名を付けて配信する
• 送付前サニタイズ: 取引先に送る前の PDF に対して、メタデータ除去・墨消しを自動適用する

UI 上のノーコードパイプライン機能は、これらの一連処理を画面で定義しテンプレート化できる機能です。一度パイプラインを作成すれば、UI からのドラッグ&ドロップでも、API 経由のトリガーでも同じ処理を再利用できます。

社内に Java / Spring Boot の運用ノウハウがない場合でも、API クライアントは HTTP リクエストを送れる言語であれば実装できるため、既存システム側の言語選択に縛られにくいのも利点です。

類似OSSとの違い｜PDFsam・PdfDing・BentoPDFとの比較

「セルフホストで PDF を扱う OSS」は他にも存在します。Stirling-PDF を選定する際は、他の候補との違いを把握しておくと上長への説明材料になります。ここでは代表的な 3 つの類似 OSS との比較を整理します。

比較マトリクス

PDFsam が向くケース

PDFsam はデスクトップ専用のオープンソースアプリで、PDF のページ単位操作（分割・結合・混合・回転・抽出）に特化しています。Web UI や API・Docker 提供はなく、OCR・変換・電子署名・墨消し・自動化パイプラインは持ちません。

「個人作業用の PC にインストールして、たまに発生する PDF の結合・分割を手軽に行いたい」用途には軽量で適しています。一方、社内サーバーにデプロイして複数人で使いたい、API から呼びたい、といったユースケースには合いません。

PdfDing が向くケース

PdfDing は Python（Django）で書かれたセルフホスト型 PDF マネージャです。複数デバイス間で読書位置を同期したり、注釈・ハイライト・共有リンクを管理したり、OIDC で SSO 連携したりと、「PDF をライブラリとして管理し、閲覧する」用途に最適化されています。

Raspberry Pi のような小型ハードウェアでも動作する軽量さが特徴です。一方、PDF を加工・変換する機能は限定的で、業務 PDF の自動処理基盤としては Stirling-PDF とは目的が異なります。

BentoPDF が向くケース

BentoPDF はブラウザ上で完全クライアントサイドに動作する PDF ツールキットで、サーバーに PDF を送らないこと（プライバシー特化）を訴求しています。WebAssembly を活用することで、個人ユーザーのプライバシー要件には強い解になります。

ただし、OCR や Office 変換のような重い処理、業務システムからの API 呼び出し、組織内の集中処理を求める用途では、サーバーサイドで処理を担う Stirling-PDF の方が向いています。

Stirling-PDF が向くケース

ここまでの比較を踏まえると、Stirling-PDF の独自性は「セルフホスト × フル機能 PDF 加工 × REST API × ノーコード自動化」を 1 つの Docker コンテナで完結できる点に集約されます。同等のカバレッジを持つ OSS は事実上見当たりません。

組織で複数人がブラウザから利用する、業務システムから API で呼び出す、Adobe Acrobat の置き換え候補として評価したい、といった文脈では、Stirling-PDF が第一候補になります。

無料で使える範囲と有償プランの境界

「無料 OSS」を強調する記事は多いですが、業務導入では「どこから費用が発生するか」を理解しておくことが予算稟議に不可欠です。Stirling-PDF は open-core モデルを採用しており、コアの PDF 操作機能は無料で利用できますが、組織導入で必要になりがちな機能の一部は有償プランに含まれます。

公式の有償プランドキュメントに基づき、無料／有償の境界を整理します。

プラン別の主な違い

※ 料金は公式サイト・公式ドキュメントの記載に基づきます。最新の料金は公式有償プランページで確認してください。

業務導入時のチェックポイント

• 複数人利用時のユーザー上限: 無料 OSS 版は最大 5 ユーザーまでという制限があります（公式 Paid-Offerings ドキュメント記載）。社内で 6 名以上が利用する想定であれば、Server Plan 以上が必要になる前提で予算を組んでください
• シングルサインオン要件: 社内 SSO（Okta / Azure AD / Google Workspace 等）と連携したい場合、OAuth2 は Server Plan、SAML2 は Enterprise が必要です。無料 OSS 版の認証はローカルログインのみと考えておくと安全です
• 外部 DB / クラウドストレージ連携: ユーザー設定や処理履歴を外部 DB（PostgreSQL 等）で集中管理したい場合は Server Plan の範囲です
• 監視・SLA: Prometheus 監視エンドポイントや SLA を必要とするミッションクリティカル運用は Enterprise が前提となります
• SaaS との使い分け: 「PoC は無料 OSS 版で、本番運用は SaaS に寄せる」「日常運用はセルフホスト、ピーク時のスパイクは SaaS でオフロード」といったハイブリッド構成も検討候補になります

無料 OSS 版で評価を始め、組織導入の段階で「6 名以上で使う・SSO が必要」と分かれば Server Plan、「監査・監視・SLA が必要」と分かれば Enterprise に段階的に移行する、という想定がしやすい価格体系です。

導入前に確認すべき注意点

PoC を進めて本番運用に向かう際、事前に確認しておくべき点を整理します。

ライセンスの確認（NOASSERTION の意味）

GitHub API 上のライセンス SPDX 識別子は NOASSERTION となっており、自動判定可能な単一ライセンスとしては認識されていません。これは README に open-core モデルが明記されている一方で、コア部分のライセンスファイルを直接確認する必要があることを意味します。商用利用前に公式リポジトリの LICENSE ファイル、および公式ドキュメントの利用規約を法務担当と共有して確認してください。

サーバーリソース要件

OCR（Tesseract）や Office 変換（LibreOffice）は CPU・メモリを比較的多く使用します。latest-ultra-lite イメージは軽量ですが、OCR や Office 変換を行わない前提です。日常運用で OCR・変換の負荷が想定される場合は、latest または latest-fat を選び、CPU コア数・メモリ・ディスク I/O に余裕を持たせた構成が必要です。

認証は無料版では基本機能のみ

繰り返しになりますが、無料 OSS 版の認証はローカルログインに留まります。社内 SSO 統合（OAuth2 / SAML2）を必須要件とする組織では、Server Plan または Enterprise の費用を前提とした稟議にしておく必要があります。

アップデート頻度と運用負荷

直近のコミット日（2026 年 6 月 30 日）が示すとおり、開発は活発に継続しています。これはセキュリティ修正・機能追加の恩恵がある一方で、本番運用ではバージョン固定（タグ指定）と検証環境での事前確認をルール化しておくことが望ましい運用です。stirlingtools/stirling-pdf:latest をそのまま本番に当てると、想定外の挙動変更を引き込むリスクがあります。

まとめ｜Stirling-PDFを選ぶべきケース

Stirling-PDF が適するケースと、別の選択肢を検討すべきケースを整理します。

Stirling-PDF が適するケース

• PDF を外部 SaaS に送信できない（ISMS・P マーク・業界要件などのコンプライアンス制約）
• 組織内で複数人がブラウザから PDF 編集を行う運用にしたい
• 社内システムから API 経由で PDF 処理を呼び出したい
• Adobe Acrobat のライセンス費用を圧縮しつつ、基本的な編集ニーズはカバーしたい

別の選択肢を検討すべきケース

• 個人 PC で軽量に PDF 分割／結合だけ行いたい → PDFsam
• PDF のライブラリ管理・閲覧・読書同期が主目的 → PdfDing
• サーバーを一切置かずブラウザ内で完結したい → BentoPDF

次のアクションとしては、まず社内検証環境で docker run 1 行で Stirling-PDF を起動し、自社の業務 PDF（契約書・申込書・提案書など）をいくつか流して機能カバレッジを確認するのが最短ルートです。その後、SSO や監視の要件が顕在化した段階で、Server Plan / Enterprise の費用を含めた本番構成を検討する、という順序が予算稟議にも乗せやすい流れになります。

なお、本記事は対象リポジトリ（Stirling-Tools/Stirling-PDF）の README・公式ドキュメント・公式サイト、および類似 OSS の公式情報をもとに整理したものです。実環境への導入時は、最新の公式ドキュメントと有償プランページを参照のうえ、自社の要件と照合してください。