ブラウザでPDFテキストを抽出する「LiteParse for the web」

LlamaIndexには、PDFからテキストを抽出するためのNode.js CLIツール（Command Line Interface Tool）を提供する非常に優れたオープンソースプロジェクト[LiteParse](https://github.com/run-llama/liteparse)があります。私は、Node.jsで動作させるためにLiteParseが使用するほぼ同じライブラリを使用して、ブラウザ上で完全に動作するLiteParseのバージョンを作成しました。 ## 空間テキスト解析（Spatial Text Parsing） Refreshingly、LiteParseは自身の機能にAIモデル（Artificial Intelligence Models）を使用していません。それは古くからある伝統的なPDF解析（PDF Parsing）であり、テキストそのものではなくテキストの画像を含むPDFに対しては、Tesseract OCR（または他のプラグイン可能なOCRエンジン（Pluggable OCR Engines））にフォールバックします。 LiteParseが解決する難しい問題は、PDFレイアウトの苛立たしいばらつきにもかかわらず、意味のある順序でテキストを抽出することです。彼らはこれを「空間テキスト解析（Spatial Text Parsing）」と呼んでおり、マルチカラムレイアウト（Multi-column Layouts）などの検出に非常に巧妙なヒューリスティック（Heuristics）を使用し、意味のある線形フロー（Linear Flow）でテキストをグループ化して返します。 LiteParseのドキュメントでは、[Bounding Boxesを用いたビジュアル引用（Visual Citations with Bounding Boxes）](https://developers.llamaindex.ai/liteparse/guides/visual-citations/)の実装パターンが説明されています。このアイデアは非常に気に入っています：PDFから質問に回答し、その回答に切り抜いて強調表示された画像を添えることができるのは、RAGスタイルのQ&A（Retrieval-Augmented Generation Question & Answer）からの回答の信頼性を高める素晴らしい方法のように感じられます。 LiteParseはエージェント（Agents）が使用するように設計された純粋なCLIツール（Command Line Interface Tool）として提供されています。実行方法は以下の通りです： ``` npm i -g @llamaindex/liteparse lit parse document.pdf ``` 私はClaudeを使ってその機能を[探求](https://claude.ai/share/44a5ed86-e5b5-4e14-90be-1eba1e0acd13)し、CLIアプリ（Command Line Interface Application）であり続けることに実質的な理由がないことをすぐに突き止めました。これはPDF.jsとTesseract.jsという2つのライブラリの上に構築されており、これらは過去にブラウザで類似のことを行うために私が使用したものです[過去の投稿](https://simonwillison.net/2024/Mar/30/ocr-pdfs-images/). LiteParseに純粋なブラウザ版が存在しなかった唯一の理由は、誰もまだそれを作っていなかっただけのことです…… ## Web向けLiteParseの紹介（Introducing LiteParse for the web） [https://simonw.github.io/liteparse/](https://simonw.github.io/liteparse/)にアクセスして、ブラウザ上で完全に動作するLiteParseを任意のPDFファイルで試してみてください。以下がその外観です： ![image](https://static.simonwillison.net/static/2026/liteparse-web.jpg) このツールはOCR（Optical Character Recognition）の実行有無に関わらず動作し、オプションでPDFの各ページの画像をページ下部に表示することもできます。 ## Claude CodeとOpus 4.7を用いた構築（Building it with Claude Code and Opus 4.7） この構築プロセスは、iPhoneの通常のClaudeアプリで始まりました。私はLiteParseを自分で試したかったので、まずスマートフォンにたまたま保存していたランダムなPDFと、以下のプロンプトをアップロードすることから始めました： `https://github.com/run-llama/liteparse`をクローンして、このファイルで試してみてください 最近の通常のClaudeチャットではGitHubから直接クローン可能であり、デフォルトではコンテナ内からインターネットの大部分にアクセスできませんが、PyPI（Python Package Index）やnpm（Node Package Manager）からのパッケージインストールも可能です。 私はスマートフォンで新しいオープンソースソフトウェア（open source software）を試す際、よくこれを使います。ノートパソコンの前に座らなくても、さっと何かを実行・確認できる手軽な方法だからです。 会話の全貌は[こちらの共有Claudeトランスクリプト](https://claude.ai/share/44a5ed86-e5b5-4e14-90be-1eba1e0acd13)で追うことができます。動作についていくつかのフォローアップ質問をした後、私はこう尋ねました： このライブラリ（library）はブラウザ（browser）上で動作しますか？ 動作可能でしょうか？ 返ってきた回答は十分詳細で、実際に動作させる価値があると感じました。そこでノートパソコンを開き、Claude Codeに切り替えました。 GitHub上で元のリポジトリ（repo）をフォークし、ローカルにクローンしました。新しいwebブランチ（web branch）を作成し、Claudeからの最後の回答を[notes.md](https://github.com/simonw/liteparse/blob/web/notes.md)という新しいファイルに貼り付けました。その後、Claude Codeにこう指示しました： これをWebアプリとして動作させてください。index.htmlを読み込んだ際、ユーザーがブラウザ（browser）でPDFを開き、OCRモード（OCR mode）または非OCRモードを選択して実行できるアプリをレンダリングする必要があります。この問題に関する初期調査はnotes.mdを読んでください。その後、詳細な実装計画をplan.mdとして出力してください このようなプロジェクトでは、常に計画から始めるのが好きです。時にはClaudeの「プランニングモード（planning mode）」を使いますが、今回はリポジトリ内に計画書をアーティファクト（artifact）として残したかったので、plan.mdを直接作成するよう指示しました。 これにより、Claudeと計画を反復（イテレーション）で改善できるのも利点です。ClaudeはPDF内の画像のスクリーンショット生成については先送りし、「canvas-encode swap（canvas-encode swap）」をv2に延期することを提案していたことに気づきました。私は以下のようにプロンプトしてそれを修正しました： 計画を更新し、スクリーンショットの機能が動作するように「canvas-encode swap（canvas-encode swap）」を必ず行うと明記してください いくつかの短いフォローアッププロンプトを経て、以下は実装に十分な強度があると判断した[plan.md](https://github.com/simonw/liteparse/blob/web/plan.md)です。 私はこうプロンプトしました： 構築してください。 その後は主にClaude Codeに任せておき、他のプロジェクトをいじったり、Duolingoで復習したりしながら、時々進捗を確認しました。 作業中にいくつかのプロンプトをキュー（queue）に追加しました。これらはまだエクスポートされたトランスクリプトには表示されませんが、関連する `~/.claude/projects/` フォルダで `rg queue-operation --no-filename | grep enqueue | jq -r '.content'` を実行すると抽出できることがわかりました。 主要なフォローアッププロンプトと補足メモは以下の通りです： - これを実装する際は、Playwright（ブラウザ自動化フレームワーク）とred/green TDD（テスト駆動開発の手法）を使用し、その計画も立ててください - red/green TDDについてはこちらで詳しく書いています。 let's use PDF.js's own renderer (it was messing around with pdfium) → PDF.js（PDF表示ライブラリ）の独自レンダラーを使用しましょう（pdfiumとの互換性調整で手間取っていたため） The final UI should include both the text and the pretty-printed JSON output, both of those in textareas and both with copy-to-clipboard buttons - it should also be mobile friendly - I had a new idea for how the UI should work → 最終的なUI（ユーザーインターフェース）には、テキストと整形済みJSON（JavaScript Object Notation）出力の両方を含める必要があります。どちらもtextarea要素で表示し、クリップボードへのコピーボタンも付けます - モバイルフレンドリー（モバイル対応）であることも必須です - UIの動作について新しいアイデアが浮かびました small commits along the way - see below → 作業の過程で小さなコミットを積み重ねてください - 以下参照 Make sure the index.html page includes a link back to https://github.com/run-llama/liteparse near the top of the page - it's important to credit your dependencies in a project like this! → index.htmlページ上部に https://github.com/run-llama/liteparse へのリンクを必ず含めてください - このようなプロジェクトでは依存関係のクレジット表記が重要です！ View on GitHub → is bad copy because that's not the repo with this web app in, it's the web app for the underlying LiteParse library → 「View on GitHub →」というコピーは不適切です。このWebアプリが含まれているリポジトリではなく、基盤となるLiteParseライブラリのWebアプリ用だからです Run OCR should be unchecked by default → 「Run OCR」チェックボックスはデフォルトでオフにしてください When I try to parse a PDF in my browser I see 'Parse failed: undefined is not a function (near '...value of readableStream...') - it was testing with Playwright in Chrome, turned out there was a bug in Safari → ブラウザでPDFの解析を試みると、「Parse failed: undefined is not a function (near '...value of readableStream...')」というエラーが表示されます - ChromeでPlaywrightを使用してテストしていましたが、Safariにバグがあることが判明しました ... oh that is in safari but it works in chrome → …ああ、それはSafariでの話ですが、Chromeでは正常に動作します When "Copy" is clicked the text should change to "Copied!" for 1.5s → 「Copy」ボタンがクリックされたら、テキストが1.5秒間「Copied!」に変更される必要があります [Image #1] Style the file input so that long filenames don't break things on Firefox like this - in fact add one of those drag-drop zone UIs which you can also click to select a file - dropping screenshots in of small UI glitches works surprisingly well → [Image #1] ファイル入力フィールドをスタイル調整し、Firefoxで長いファイル名がレイアウトを崩さないようにしてください - さらに、クリックしてファイルを選択できるドラッグ＆ドロップゾーンUI（ユーザーインターフェース）も追加してください - 小さなUIの不具合スクリーンショットを貼り付けて確認する手法は、予想以上に効果的です Tweak the drop zone such that the text is vertically centered, right now it is a bit closer to the top → ドロップゾーンのテキストが垂直方向で中央に来るように微調整してください。現在は少し上部に寄っています it breaks in Safari on macOS, works in both Chrome and Firefox. On Safari I see "Parse failed: undefined is not a function (near '...value of readableStream...')" after I click the Parse button, when OCR is not checked - it still wasn't working in Safari... → macOS版Safariでは動作が崩れますが、ChromeとFirefoxでは正常に動作します。Safariで「Parse」ボタンをクリックし、OCRチェックがオフの状態で「Parse failed: undefined is not a function (near '...value of readableStream...')」というエラーが表示されます - Safariではまだ動作していませんでした… works in safari now - but it fixed it pretty quickly once I pointed that out and it got Playwright working with that browser → 現在はSafariでも動作するようになりました - ただし、その点を指摘してPlaywrightをそのブラウザで動作させられるようにしたところ、かなり早く修正されました I've started habitually asking for "small commits along the way" because it makes for code that's easier to understand or review later on, and I have an unproven hunch that it helps the agent work more effectively too - it's yet another encouragement towards planning and taking on one problem at a time. → 作業の過程で小さなコミットを積むよう習慣的に依頼し始めたのは、後から理解やレビューがしやすいコードになるためです。また、エージェントの作業効率を高めるという確証はないものの直感的にそう思っています - これは計画性を高め、一度に一つの課題に取り組むよう促すもう一つの手段です。 While it was working I decided it would be nice to be able to interact with an in-progress version. I asked a separate Claude Code session against the same directory for tips on how to run it, and it told me to use npx vite. Running that started a development server with live-reloading, which meant I could instantly see the effect of each change it made on disk - and prompt with further requests for tweaks and fixes. → 動作している間、進行中のバージョンと対話できるのは良いだろうと考えました。同じディレクトリを対象に別のClaude Codeセッションを立ち上げ、実行方法のヒントを尋ねたところ、「npx vite」を使用するよう指示されました。それを実行するとライブリロード機能付きの開発サーバーが起動し、ディスク上での各変更の効果を即座に確認できました - さらに微調整や修正の依頼をプロンプトとして送ることも可能です。 Towards the end I decided it was going to be good enough to publish. I started a fresh Claude Code instance and told it: → 作業の終盤、公開しても問題ないレベルだと判断しました。新しいClaude Codeインスタンスを立ち上げ、以下のように指示しました： `web/`フォルダを確認し、このリポジトリに対してGitHub Actions（CI/CD自動化ツール）を設定する。すべてのpush（コミットプッシュ）でテストを実行し、テストが成功すれば、ビルドされたVite（フロントエンドビルドツール）アプリをGitHub Pages（静的サイトホスティングサービス）にデプロイする。デプロイされるアプリケーションのindex.html（インデックスファイル）が`web/index.html`ページになるようにし、GitHub Pages上で正しく動作するようにする。 少しの反復作業を経て、[Viteを使用してアプリをビルドし、結果をhttps://simonw.github.io/liteparse/にデプロイするGitHub Actionsのワークフロー](https://github.com/simonw/liteparse/blob/web/.github/workflows/deploy-web.yml)が完成した。 このような用途にGitHub Pages（静的サイトホスティングサービス）が気に入っているのは、（今回の場合Claudeによって）迅速に設定でき、ゼロコストで必要なビルドステップ（ビルド工程）があれば任意のリポジトリをデプロイ済みのWebアプリに変換できるからだ。秘密のURLのみをセキュリティ対策とすれば、プライベートリポジトリに対しても機能する。 このようなプロジェクトでは、モデル（AIモデル）が「手抜き」をする重大なリスクが常に存在する。主要な機能にTODO（作業予定マーク）とマークして偽装したり、初期要件を無視した近道（ショートカット）を取ったりする可能性がある。 これを防ぐ責任ある方法はすべてのコードをレビューすることだが、このプロジェクトはそういう意図で作ったものではない。そのため代わりに、GPT-5.5（大規模言語モデル）を搭載したOpenAI Codex（コード生成モデル）を起動し（プレビューアクセスを持っていた）、以下のように指示した。 `node.js`のCLIツール（コマンドラインインターフェースツール）と`web/`バージョンの実行方法の違いを説明してください 返ってきた回答は、Claude Code（AIプログラミングアシスタント）がプロジェクトを脅かすような近道を取っていないという確信を得るのに十分だった。 ……それでほぼ完了だ。Claude Codeでの「ビルド」ステップにかかった総時間は59分だった。私は[claude-code-transcripts](https://github.com/simonw/claude-code-transcripts)（会話記録エクスポートツール）を使用して、完全なトランスクリプトの読みやすいバージョンをエクスポートした。これらは[こちらで閲覧可能](https://gisthost.github.io/?d64889bfc1b897fea3867adfec62ed89/index.html)だ（追加のキュー待ちプロンプトは含まれていないが、それらを修正するための[イシュー](https://github.com/simonw/claude-code-transcripts/issues/98)はこちらにある）。 ## これでもうvibe coding（ノリコーディング）と呼べるのか？ 私は[vibe coding（ノリコーディング）の元の定義](https://simonwillison.net/2025/Mar/19/vibe-coding/)に関しては非常に厳格な主義者だ。vibe codingとは、AIを使ってコードを書く支援を受けるすべての状況を指すのではなく、書かれたコードを一切レビューしたり気にしたりせずにAIを使うことを意味する。 私自身の定義によれば、このLiteParse for the webプロジェクトは、これ以上ないほど純粋なvibe codingだ！私はこのプロジェクトのために書かれたHTML（ハイパーテキストマークアップ言語）とTypeScript（JavaScriptのスーパーセット）のコードを*一行も*確認していない。実際、この文を書いている最中に、JavaScriptかTypeScriptのどちらを使っているのか確認しに行ったほどだ。 しかし不思議なことに、他の多くのvibe codingプロジェクトと比べて、これは私にはそれほど「ノリで書かれた」感じはしない： - GitHub Pages でホストされるブラウザ内静的ウェブアプリケーションとして、バグが発生した場合の影響範囲（ブラスト半径）はほぼゼロです：あなたのPDFで動作するか、しないかのどちらかです。 プライベートなデータは一切外部に送信されません。すべての処理はブラウザ内で行われるため、セキュリティ監査（security audit）は不要です。実行中にネットワークパネル（network panel）を一度確認しましたが、PDFの解析中は追加のリクエストは一切行われていません。 それでも、このようにモデルを使用するには、多くのエンジニアリングの経験と知識が必要でした。LiteParse をブラウザ内で直接実行できるようにポート（移植）することが、プロジェクトの残りの部分にとって重要であるという認識が不可欠でした。 最も重要なのは、私はこのプロジェクトに私の評判を賭けて他の人に試すことをお勧めできることです。私のバイブコーディング（vibe coding）ツールとは異なり、これに大幅な追加のエンジニアリング時間を費やすことが、意味のあるほど優れた初期リリースにつながるとは思えません。今のままで十分です！ 私は [元リポジトリ](https://github.com/run-llama/liteparse) に対して PR（プルリクエスト）をオープンしていません。LiteParse チームとまだ議論していないためです。私は [イシューの作成](https://github.com/run-llama/liteparse/issues/147) を行いましたが、彼らが私のバイブコーディング実装をより公式なプロジェクトの起点として使用したい場合は、自由に利用してください。 タグ: [javascript](https://simonwillison.net/tags/javascript), [ocr（光学文字認識）](https://simonwillison.net/tags/ocr), [pdf](https://simonwillison.net/tags/pdf), [projects](https://simonwillison.net/tags/projects), [ai（人工知能）](https://simonwillison.net/tags/ai), [generative-ai（生成AI）](https://simonwillison.net/tags/generative-ai), [llms（大規模言語モデル）](https://simonwillison.net/tags/llms), [vibe-coding（バイブコーディング）](https://simonwillison.net/tags/vibe-coding), [coding-agents（コーディングエージェント）](https://simonwillison.net/tags/coding-agents), [claude-code](https://simonwillison.net/tags/claude-code), [agentic-engineering（エージェント型エンジニアリング）](https://simonwillison.net/tags/agentic-engineering)

ブラウザでPDFテキストを抽出する「LiteParse for the web」

背景や根拠まで確認しますか？

このニュースを、実務の判断につなげる

関連記事

調べる

選ぶ

サイト