はじめに
AI エージェントや LLM パイプラインに Web の本文を供給するコンテンツエンジン「PageSift」の 1.0 を公開しました。Rust 製の単一バイナリで、URL・PDF・Office ファイルをクリーンな Markdown と構造化データに変換します。Firecrawl 互換 API、Jina Reader 互換エンドポイント（/s/ 含む）、MCP サーバー、Python / Node.js SDK を備えます。
GitHub: https://github.com/YOLOW92/pagesift （AGPL-3.0）
10 月 20 日に 0.20 として公開してから 15 日、25 バージョンを経ての 1.0 です。0.9 でアーキテクチャ（性能と適応性）を、1.0 で機能の完成を担いました。この記事では技術的な要点を 3 つ紹介します。
1. 固定値をやめて、統計的推定に
従来のバージョンには、手で調整したタイムアウト・しきい値・同時実行数が数百個ありました。0.9 以降、これらを統計カーネル（pagesift-stat）が実行時の観測から推定します。
- タイムアウト：Kaplan–Meier 生存分析
- 全体同時実行数：Universal Scalability Law のフィット
- レンダリング要否などの判断：「事後期待値 − シャドウ価格 × コスト」（シャドウ価格は M/M/1 近似 λ ≈ W/(1−ρ)）
- 全体で残るメタパラメータは δ = 0.05 のみ
観測がなければ旧来の固定値と同じ挙動になり、推定値は統計的に有意な差がある場合にだけ採用されます。各定数のコメントには導出の出典と実測の根拠を残しています。
CPU 実行も「ハードウェアに逆らわない」方針で、コアごとの常駐ワーカー（ブロッキングスレッドプールの廃止）、NUMA ノード集合へのピン留め（コア単位の固定は 0.70 時点の実測で −33.9% だったため不採用）など、判断の多くが実測由来です。
2. OCR と推論ランタイムを自作した
スキャン PDF は長く弱点でした（0.9 の設計では OCR は非目標）。1.0 では OCR パイプライン（テキスト検出・認識・数式認識・レイアウト解析）を自作し、推論ランタイムも ONNX Runtime を使わず safetensors を直接実行する自前実装にしました。GPU 層も CUDA バインディングを自作しています。モデルはオープンウェイトを初回利用時にダウンロード、デフォルトは無効です。olmOCR-bench のスキャン系スコアは 0.543（Docling・GPU の 0.410 を上回る結果）でした。
3. 「失敗を成功と報告しない」設計
0.91 はこの一点のためのリリースでした。結果を保存できない、待機系に複製できない、webhook を配送できないジョブが、ログだけ残して completed になっていた問題を全面修正し、失敗として終了させ、エラー取得エンドポイントを付けました。1.0 では API 表面にも広げ、実現できないオプションは黙って無視せず拒否します（MCP の未知引数はエラー、実装できない Jina ヘッダーは UNSUPPORTED_OPTION)。リリースノートには Known limits の節があり、未検証の点やセキュリティ上の注意も明記しています。
性能（2026-11-04 再計測）
- PDF → Markdown：2.4 ms/ページ（olmOCR-bench 1,269 ページ、単一スレッド）
- 本文抽出：p50 1.0 ms/ページ（Firecrawl 597 ページ）
- 広域クロール：3,500–4,400 ページ/秒、ピークメモリ 280–316 MB（200 サイト × 100 ページ）
対照ツールの数値は 10 月下旬の記録で今回再実行していないこと、PageSift が負けるワークロードも含め、方法と生データはリポジトリの docs/benchmarks.md に公開しています。
おわりに
PageSift は、自分のリサーチプラットフォーム AiSeek の収集基盤として既存ツールに限界を感じたことがきっかけで作り始めた個人プロジェクトです。すでに海外チームの本番環境への導入実績があり、そこで見つかった glibc 基線の問題は 0.81.5 で修正し、再発防止のリリースゲートまで入れました。
試用・Issue・ベンチマークでの対決、いずれも歓迎します。