【新着】Parsewise (YC W25): 非構造化データから真の知見を引き出す最強のAPI

こんにちは！Parsewise創業者のGregとMaxです（https://www.parsewise.ai/api ）。Parsewiseは、バラバラな非構造化データをスキーマ準拠のデータへ変換し、文書をまたいだ値の整合性と根拠（リネージ）を完全に保持する画期的なプラットフォームです。例えばClaudeに大量のファイルを渡してCSVやJSONを出力させようとすると、ファイル数やコスト、精度の検証といった壁にぶつかりますよね。私たちはその課題を解決します。技術チームのETL作業を簡素化し、ビジネスの専門家が定義や検証を即座に行える環境を提供します。活用事例の動画はこちらです：https://www.youtube.com/watch?v=dbRllnnh47w 。ユーザーからは「保険証券のPDFや通話記録、メールなどから、単なる抽出ではなく、文書全体を横断して推論できる『エージェント的』なデータ抽出がしたい」という声を多くいただいています。PalantirでETLとAIワークフローを牽引してきたGregと、Bainで複雑な金融データ分析を極めてきたMaxの経験がParsewiseの礎です。Parsewiseは数千規模のPDFやExcelを読み込み、すべての値がどの文書のどこから来たかを単語レベルで追跡できる形で出力します。コアとなるのは自己改善型のエージェント定義で、データのソースや論理的な解決ルール、曖昧な箇所の提示までを自動化します。技術的にはモデルやクラウドを選ばず、プライベートネットワークへのデプロイも可能です。現時点ではGeminiモデルが視覚的推論でSOTA（Databricks OfficeQAでClaude Fableを上回る結果）を出しています。私たちが特に注力したのは「人間による検証の容易さ」です。結果を信頼するために必要なクリック数や時間を極限まで減らしました。RAGとは異なり、サンプリングをせず網羅的に関連値を検索し、矛盾があればユーザーに警告します。この「網羅性と明示的な根拠付け」こそがParsewiseの真骨頂です。複雑なドキュメント処理に悩んでいるエンジニアの皆さん、ぜひ一度試してみてください！フィードバックもお待ちしています。

最近、似たようなことをする社内ツールを作ったよ。基本的にはMistral OCRをGeminiに繋いで、ドキュメントから構造化データを抽出する仕組み。そのあと自動でDiffを取るようにもしてる。

「Intelligent Document Processing（インテリジェント・ドキュメント・プロセッシング）」市場は競争が激しすぎてやばいよね。例えばParseurとか。創業者もよくHNにいるし。

以下の競合と比較して、何が強みだと思う？

1. Mistral document AI: モデルにもよるけど、君のところより圧倒的に安い。OCRモデルの価格は1ページあたり0.001〜0.004ユーロだし、必要ならOCR APIに構造化出力も組み込まれてる（そのままLLMに投げられる）。それにEUベースでGDPR対応済みだし。
2. Parseur / Rossum / Docsumo / Nanonets (YC 2017) あたり。

愛を込めて言うけど、デモの「Vibecoded（雰囲気重視の）」なUIデザイン、いかにも「AI臭い」仕上がりだね。

プロダクトそのものを批判するつもりはないよ。ただ、ベージュオレンジのテーマカラー、ピル型のコンポーネント、左側のボーダーハイライトを見ると、ダッシュ記号や「XではなくY」みたいな言い回しが散りばめられた文章を読んだときのような生理的嫌悪感を覚えてしまう。それだけで少し信頼度が下がっちゃうんだ。

デモ自体はクールだと思うけど。

エージェントの定義ってどれくらいポータブルなの？例えば保険書類用に一つ作ったとして、それを法律契約書やヘルスケアみたいな全く別のドメインに適応させるには、どれくらいの作業が必要になる？

デジタル人文学、特にアーカイブ関連の作業には最高そうだね。ぜひ試してみたい。

おっ、これって大規模ドキュメントコーパスに対する構造化出力みたいなものかな？

昔、Struktur (https://struktur.sh) っていう似たようなツールを作ったことがあるよ。

あっちの方が範囲はかなり限定的だけど、完全にオープンソースでカスタマイズ性が高い。実際、みんなが自分独自のパイプラインを構築できるように、信頼性の高い基盤を提供することを目指して作ったんだ。

開発中に痛感したんだけど、エージェントやLLMベースのデータ抽出を真の意味で汎用化するのはかなり難しいね。特にタスク固有の指示なしで無限に入力タイプがある場合（同種のファイルが大量にある、単一の巨大ファイル、混在タイプ、低品質なファイル、docx/pdf/png……などなど）。ユーザーは残念ながらこれら全てをアップロードしたがるし、開発者は「万能な（one size fits all）」ソリューションを求めたがる。

君のソリューションでこれにどう対応しているのか興味があるよ。僕は戦略ベースのアプローチを採用して、必要に応じて全てのタスクをカスタマイズできるようにしたんだけど、この無限に多様な入力と抽出タスクの組み合わせをどう処理しているのか、技術的な解説記事が読めたら嬉しいな！

ドキュメント解析については最近ずっと考えてる。私たちが関わっている領域では、ドキュメントをAPIと同じようにクエリできないことがボトルネックになりつつあるからね。

ドキュメントもParquetの構造化データと同じように表現できれば一番分かりやすいんじゃないかと思ってる。Parquetなら範囲ベースのクエリが簡単だし、Arrow周りのツールも充実してるし。

ただ、ドキュメントに関しては適切な抽象化とは何なのか、ずっと壁にぶつかっている状態。Parquetならフィルタリング可能なメタデータがあるけど、ドキュメントにそんなメタデータなんて存在するんだろうか。それにチャンキングやベクトル化の恣意性という問題もあるし。

もし全ての処理対象ドキュメントをParquetのようなデータフォーマットで表現する2段階のプロセスが構築できれば、少なくとも解決策の兆しは見えてくる気がする。

面白いプロダクトだね！e-ディスカバリー（電子情報開示）でも使えると思う？メールや契約書など約120GBのデータがあって、特定の表現がどこで参照されているか検索する必要があるんだけど。

クライアントがこういうツールをガッツリ使っているのをよく見るよ（これそのものじゃないけど）。それと同時に、僕が「ビジネスに対する理解（business awareness）」と呼んでいるものが低下している気もする。

「With experience and support from」という表現、ランディングページのトリックとしてうまいね！

ところで、単純な埋め込みモデルを使った類似度マッチングではなく、理解力を必要とするドキュメント内の事実を、どうやって抽出して関連付けているの？