本文へ
ハクソク

世界を動かす技術を、日本語で。

PaperPilot – ゼロクラウド、ピュアラストのPDFエンジン（WASMおよびMCP搭載）

元記事: 原文(github.com)

概要

PaperPilot は、 Rust製のPDF・ドキュメントツールキット。 ローカル動作・ファイル非送信で プライバシー重視。 CLI、ブラウザ、デスクトップ、REST APIなど 多様な利用方法 に対応。 MCPエージェント連携 やエンジン一貫性が特徴。 OSSライセンス で、拡張・貢献も歓迎。

PaperPilot: Rust製PDFツールキットの特徴

  • Pure Rust で開発、 ファイルはローカル処理、外部送信なし。
  • MCPエージェント （Codex, Claude Code, Kimi Code, Pi, Cursor等）との連携対応。
  • CLI によるバッチ処理・スクリプト実行。
  • ブラウザ版（WASM） はインストール不要、ファイルはブラウザメモリ内処理。
  • デスクトップアプリ はTauri + Svelte製GUI、PDFビューア・マークアップ・差分表示機能。
  • ローカルREST API でPython、Node、n8n等から呼び出し可能（localhost:7823）。
  • ChromiumやC++ランタイム非依存、クラウド通信不要。

すぐ使う方法

  • MCPエージェント連携
    • paperpilot-mcpをダウンロードし、各エージェント設定ファイルにコマンドパスを登録。
    • 例: Claude Desktopで設定後「2つのPDFを結合し圧縮」などの指示が可能。
  • CLI利用例
    • PDF結合: paperpilot merge --inputs doc1.pdf doc2.pdf --output merged.pdf
    • 圧縮: paperpilot compress --input in.pdf --quality 75 --output compressed.pdf
    • ページ回転: paperpilot rotate --input in.pdf --pages 1,3-5 --angle 90 --output out.pdf
  • ブラウザ利用
    • usepaperpilot.comへアクセス、ファイルアップロードなしで安全処理。
  • ソースからビルド
    • Rust 1.75+、Node.js、pnpmが必要。
    • git clone後、cargo build --releaseやpnpm tauri devでデスクトップアプリ起動。

現在の主な機能（v0.6）

  • 整理 ：結合、分割、回転、削除、並び替え、ページ抽出、ブックレット、N-upグリッド
  • 最適化 ：圧縮
  • 抽出 ：テキスト抽出、OCR（Rust製PaddleOCR搭載）
  • セキュリティ ：ウォーターマーク、署名検証・削除、PIIスキャン、ディープサニタイズ
  • オフィスデータ変換 ：Excel→JSON、Excel→CSV

今後のロードマップ

  • v0.7: PDF ↔ Markdown / HTML / JSON変換
  • v0.8: PDF → Word / Excel / PowerPoint変換
  • v0.9: 暗号化・復号・署名・墨消し・フォーム・注釈
  • v1.0: レンダリング・フラット化・修復・比較・PDF/A・Batesナンバリング

なぜPaperPilotか

  • プライバシー重視 ：全処理がローカルまたはブラウザタブ内で完結。
  • エージェント対応 ：MCPサポートを最優先設計。
  • 一貫エンジン ：CLI、MCP、REST、WASM、デスクトップで同一Rustコア利用。
  • 軽量・依存最小 ：lopdf, pdf_oxide, rten等Rustライブラリ活用。

ベンチマーク・アーキテクチャ

  • cargo bench でベンチマーク再現可能、詳細はSYSTEM_BENCHMARK_REPORT.md。
  • アーキテクチャ ：Tauriデスクトップ、CLI、Axum REST、MCP（stdio）、WASM（ブラウザ/エッジ）
    • Rustコア：paperpilot-core, paperpilot-pdf, paperpilot-nlp, paperpilot-gateway, paperpilot-mcp, paperpilot-wasm, paperpilot-storage

サイト埋め込み・API

  • ウィジェット埋め込み例
    • <script src="https://cdn.usepaperpilot.com/embed.js" data-tools="merge,compress,ocr"></script>
    • <div id="paperpilot-widget"></div>
  • ローカルREST API例
    • paperpilot serve --port 7823
    • curl -X POST http://localhost:7823/api/v1/pdf/merge ...
    • Swaggerドキュメント: http://localhost:7823/docs

コントリビューション・ライセンス

  • バグ報告・機能要望・ドキュメント修正 など歓迎。
  • ライセンス ：Apache 2.0（CLI、MCPサーバ、RESTゲートウェイ、WASMエンジン、デスクトップアプリを含む）。
  • Enterprise Edition （SSO, RBAC, 監査ログ, DLP等）は別途開発中。

提供: ハクソク · 要約更新:

AIによる日本語要約です。内容は原文とあわせてご確認ください。

Hacker Newsの議論を読む

Hackerたちの意見

このPDFエンジンは、MuPDFのソースコードを読んで作られたバイブコードですか？（CからRustに移植された）特定の場所でMuPDFへの軽い言及が見られます。もしそうなら、開示すべきだし、ライセンスはApacheではなくAGPLv3にすべきです。

└

ライセンスなんてもう古いよ。/s でも、真面目な話、いくつか例を挙げてもらえる？

└

Rustでhayroを使ってるよ。

└

ぜんぜん違うよ！PaperPilotにはMuPDFのコード、FFI、トランスパイルは一切ないから。PDFのパースとAST操作のコアは、純粋なRustライブラリに基づいているんだ：lopdf (0.45)、pdf-writer、hayro、image。これらはすべてApache 2.0またはMITライセンスだよ。ドキュメントや計画ノートにMuPDFの言及があったのは、既存のPython/C抽出パイプライン（PyMuPDFと純粋なRustの比較）についてのアーキテクチャ的なトレードオフ分析の一部だったんだ。paperpilot-pdfのクレートスタックは100% Apache 2.0 / MITクリーンだよ。

知っているパスワードの削除機能と署名追加のサポートがあると便利だね。

└

実際、両方ともすでにサポートされてるよ！pdf_decrypt（パスワードを使ってパスワード保護されたPDFを解除する）と、暗号署名を適用するためのpdf_sign、証明書を検証するためのpdf_validate_signaturesがあるんだ。

今日、PDF生成には主にtypstを使ってる。いろんなフロントエンドやコネクタを書いて、すべてをtypファイルやテンプレートに変換してる。Sphinxをバックエンドとして使うこともあるよ。

└

i18nやテーマ、テンプレートをどう使ってるの？これらをtypstの外で定義して、（例えば）typstコンパイラにシャドウファイルを追加してるの？最近似たようなことをやってるから聞いてるんだけど、私のtypstファイルはテンプレートだから、同じ入力でも異なる結果になることがあって、異なる翻訳が必要になることもある。だから、typstで小さなi18nライブラリを書いたんだけど、特定のtypstファイルに対して翻訳のセットが必要だってこともできると思う。

ホスティングを簡単にするために、こういうものをブラウザ拡張として作り始めたんだ。

なんで人々はすでにRustに存在するPDFエンジンを再構築しようとするの？このプロジェクトが基づいているhttps://github.com/yfedoseev/pdf_oxideは、何年もかけてたくさんの修正が加えられたhttps://github.com/fschutt/printpdfを完全に無視してる。MITライセンスで、WASM上で動作するデモもあるし、https://fschutt.github.io/printpdf/で見られるよ。「rust pdf library」でググると（ああ、私古いな、今は誰も「ググる」なんて言わないけど）、これが出てくる。なのに、今の人たちは「自分たちの」半端なHTML→PDFレンダラーのコピーを持つために、何度も何度も同じことをやり直してる。で、以前に修正された同じエッジケースにぶつかるんだよね。特にタイポグラフィにはたくさんのエッジケースがあって、最近1732年の本のスキャンをOCRして整理してたら、たくさんの修正が必要だった。レイアウトに関しても多くのエッジケースがあって、特にカラム、脚注、サイドバーの扱いや、「ヘブライ語のRTLテキストが変に折れると消えちゃう」とか「1ビット画像圧縮」とか、いろいろあった。AIには何の文句もないし、私もたくさん使ってるけど、既存のプロジェクトの何年もの努力を完全に無視するのがイライラする。フォークする代わりに、同じ作業を再トークン化するだけなんだよね。たぶん、著者は「これってすでに存在するの？」って調べなかったんだろうけど、それがイライラさせる。そうすると、似たようなプロジェクトが100個も生まれて、また同じことを繰り返すことになる。時には新しいアプローチを早く探るのに役立つこともあるけど、ほとんどの場合はそうじゃなくて、以前に解決されたエッジケースを見逃してしまうんだよね。

└

これは人々が何年もかけて築いてきたものを無視しているのか、それとも彼らが使っているAIのせいなのか？人々はPDFエンジン開発の歴史を読んで消化してない、それが彼らの言い訳だけど、AIはどうなんだろう？

└

一回Googleで検索すれば（ああ、私は年寄りだから、すみません、もう誰も「ググらない」よね）それが答えかも。検索がひどくてLLMがすごすぎて、再実装する方が再利用するより早くて簡単なんだ。新しいパラダイムを遅くしているのは、出力をHNに投稿して他の人に見つけてもらう必要があるという明らかな要件だね。その皮肉は私にもわかるよ。

Hacker Newsで議論の続きを見る

同じ出典の記事