anydocを試してみたーーRAGの前処理に使えそうか検証

気になるニュースがありました。

Firecrawl⁠⁠、オフィス文書やPDFをMarkdownへ変換する「anydoc」をオープンソースで公開
https://gihyo.jp/article/2026/08/anydoc

社内の文書をRAGで生成AIから参照できるようにしたい。そう考えたとき、最初に検討すべきがファイル形式です。
Word、Excel、PowerPoint、PDFなど、形式もレイアウトも異なる文書を、検索や分割のしやすいテキストへ揃える必要があります。

早速、Firecrawl anydocを試してみましたので検証内容と評価を共有します。
結論から言と、anydocは万能な文書解析ツールではありません。しかし、対象文書の種類を見極め、変換後の整形処理と組み合わせれば、RAG（検索拡張生成）の前処理をシンプルにする選択肢になりそうです。

anydocが何かについてはここでは語りません。上記ニュース記事やGithubのリポジトリを参照してください。

検証方法

今回の検証ではanydoc バージョン0.1.9をDockerイメージで実行できるようにしました。入力ディレクトリを読み取り専用、出力ディレクトリだけを書き込み可能にし、コンテナ実行時のネットワーク接続も無効化しています。機密情報を含む社内文書を外部APIへ送らず、ローカルで変換できる構成です。

実行コマンド例です。

docker compose build
docker compose run --rm anydoc sample.csv -o /output/sample.md

ファイルをinput/へ置き、出力先を指定して実行すると、変換結果がoutput/へ保存されます。
なお、今回の検証で対象とするPDFはテキストを含むものです。画像だけで構成されたスキャンPDFには、別途OCR処理が必要です。

検証に使用した文書

単に変換できるかだけでなく、変換後のMarkdownを人が読めるか、そしてRAGへ投入しやすいかを確認するため、次のような文書を用意しました。

シンプルな文書のテキスト抽出は悪くない

CSVは、期待どおりMarkdownの表へ変換されました。

Excelの価格表も、セル結合のない単純な一枚表であれば、列名と各行の値を保ったままMarkdownへ変換できました。RAGで製品名、型番、価格などを検索したいケースでは十分に使えそうな印象です。

Wordの長文も、段落の順序や本文はおおむね維持されました。元文書の見出しはMarkdownの見出しとして出力され、章単位で内容を確認できます。文字中心で読み順が素直な文書については、手作業でコピーするよりも安定した変換方法であると思われます。

Markdown化できても、構造が常に正しいとは限らない

Markdownへ変換されることと、文書構造を正しく理解できることは別の話です。

文章中心のPDFでは、タイトルや節が#、##、###などの見出しとして出力され、ある程度は構造化されました。一方で、見出しではない文章が見出しになったり、見出し相当の文字が通常の本文や太字になったりする箇所もあります。PowerPointでも、スライドタイトルがMarkdown見出しではなく太字として出るケースが見られました。

この状態でも人間は前後関係から内容を読めますが、見出しを境界として機械的にチャンク分割すると、意図しない位置で文章が分かれる可能性があります。
RAGの前処理に使う場合は、「Markdownになったから構造化も完了」と考えず、見出しの妥当性を確認する工程が必要になります。

2カラムや複雑な表は厳しい

今回もっとも明確に限界が出たのは、2カラムのページでした。

2カラムで左右に配置された文章を変換すると、左カラムの文章を最後まで読んでから右カラムへ移るのではなく、同じ高さにあるテキストが左右交互に混ざって出力されました。テキストは抽出できていても文としてのつながりが崩れるため、そのままでは読める内容になりません。

複雑な表を含むPDFでも同様です。単純な表はMarkdownの表になりますが、ページをまたぐ表やセル配置が複雑な表では、列数が途中で変わったり、本文が表のセルへ入り込んだりしました。
ここでは「テキストが取れたか」だけでなく、「元の意味関係を保てたか」を評価する必要があります。

つまり、anydocが得意なのは論理的な読み順と見た目の配置が近い文書であると考えられます。段組みや自由配置が意味を持つ文書は、レイアウトを認識できる別のパーサーを使うといった工夫が必要でしょう。

PowerPointは重複テキストへの対処が必要

PowerPointからも本文は抽出できます。ただし、各スライドに共通するサイトURLやコピーライトなどのヘッダー・フッターが、スライドの枚数分だけ繰り返し登場しました。画像に由来するpreencoded.pngのような文字列も出力へ混ざります。

繰り返し出現する文言がノイズとなり、RAGの検索精度に影響する可能性はあると考えられます。変換後に出現回数を数え、一定以上繰り返す短い行を除外するなど、PowerPoint向けのクリーニング処理を追加するといった工夫が必要かもしれません。

一方で、すべての重複を機械的に消せばよいわけではありません。製品名や重要な注意書きが意図的に繰り返される資料もあります。文書単位で頻出行を検出したうえで、URL、ページ番号、コピーライト、画像ファイル名といった除外対象をルール化するのが現実的です。

ページ数などのメタデータは別に管理したい

今回のCLI出力は、基本的に変換後の本文でした。元ファイルのページ数、スライド数、作成者といったメタデータを、本文と一緒に取得する用途には向いていなさそうです。また、出力から元ページとの対応を安定してたどることも困難でした。

RAGで回答の根拠をページ番号まで示したい要望は多いと思います。
ファイル名、拡張子、更新日時、ページ数などは別の処理で取得し、チャンクのメタデータとして保持する必要があります。ページ単位の引用が必須なら、ページ境界を保持できる変換手段を選ぶべきでしょう。

RAGの前処理に使えるか

条件付きで使えるという評価になります。

文字だけのシンプルなレイアウトのPDF、見出しと本文を中心に構成されたWord、セル結合のないExcelなどは、埋め込み前の共通形式へ変換する用途に向いています。ファイル形式ごとに別々のライブラリを直接扱わず、まずMarkdownへ揃えられるメリットは小さくありません。

一方で、実運用ではanydocの出力をそのまま使うのではなく、例えば次のようなパイプラインにするのがよさそうです。

1. 拡張子や文書特性に応じて変換方法を選ぶ
2. anydocでMarkdownへ変換する
3. ヘッダー・フッター、画像ファイル名、過剰な空白を除去する
4. 見出し構造や表が破綻していないかを検査する
5. 元ファイル名などのメタデータを付与する
6. 見出し単位、または一定のトークン数でチャンクへ分割する
7. 埋め込みを生成する。

変換品質を完全に目視確認するのは現実的ではありません。見出しがひとつもない、表の列数が途中で変わる、同じ短文が何度も現れる、といった特徴を自動検出できれば、要確認の文書だけを人へ回せます。
段組みPDFなど既知の苦手パターンを別ルートへ送る仕組みも必要です。

まとめ

anydocは、文書を共通形式へ変換するパイプラインの一部に位置づけるのが良さそうです。 対象をシンプルな文書に絞れば、少ない構成で試せる実用的な選択肢です。複雑なレイアウトや厳密な出典管理が必要な文書については、品質検査や別の解析手段と組み合わせる。この割り切りができれば、社内文書をRAGへ取り込む最初の一歩を軽くできるかもしれません。

検証コード

検証に使用したコードはこちらのリポジトリに格納しています。
https://github.com/raisex-t-ishibashi/anydoc-study