Simon WillisonがLlamaIndexのOSSである「LiteParse」をブラウザで動かした話を読んで、自分の中でいくつか刺さるポイントがあった。
LiteParseはPDFからテキストを抽出するNode.js CLIツールだ。面白いのは、AIモデルを一切使っていないこと。PDF.jsとTesseract.jsという枯れたライブラリの組み合わせで、マルチカラムレイアウトのような複雑な構造も「Spatial Text Parsing」という独自のヒューリスティックで正しい順序に並べ直してくれる。
「CLIしかない」は「誰も作ってないだけ」だった
SimonがClaudeに「これブラウザで動く？」と聞いたところ、技術的には問題ないという回答が返ってきた。PDF.jsもTesseract.jsも両方ブラウザで動くライブラリだから、CLIにしかなかった理由は「まだ誰も作っていなかった」というだけだったらしい。これは刺さった。
READMEに「CLI専用」と書いてあると、なんとなく「そういうものか」と受け入れてしまいがちだ。でも実装の依存関係をちゃんと追いかけると、制約がなかったりする。自分もライブラリ選定のときに「ブラウザ非対応」という一言で諦めたことが何度かあったなと思い返した。
SimonはiPhoneのClaudeアプリでLiteParseを試し始め、その会話をnotes.mdに貼り付けてからClaude Codeに渡している。
npm i -g @llamaindex/liteparse
lit parse document.pdfこのCLIをブラウザアプリに変換するにあたって、まずplan.mdを書かせて、自分でレビューして、build itの一言で実装に入るという流れが紹介されていた。「スクリーンショット生成はv2に先送り」とClaude Codeが判断したのに対して、Simonが即座に「先送りしない」と修正指示を出しているのも参考になる。計画フェーズで詰める箇所と、実装に任せる箇所の切り分けがうまい。
RAGのパイプラインに組み込む前に読んでおきたかった
自分がいま触っているプロダクトでもPDF解析が必要な場面がある。今は外部APIに投げているんだけど、コストと遅延が地味に気になっていた。LiteParseが紹介している「Visual Citations with Bounding Boxes」というパターンも面白くて、回答とともにPDFの該当箇所を切り抜いた画像を添付するという設計だ。RAGの回答精度への信頼を上げるアプローチとして、自分が今後試したい実装の一つになった。
ブラウザで完結するということは、PDFをサーバーに送信しなくていい。プライバシー要件が厳しいドキュメントを扱うプロダクトだと、これは選択肢の幅が一気に広がる。
https://simonw.github.io/liteparse/ でデモが公開されているので、まず手元のPDFを数枚放り込んでどんな出力になるか確認してみてほしい。そのうえで自分のパイプラインに組み込む価値があるか判断するのが早いと思う。