社内の共有ドライブに10年分の提案書とマニュアルが眠っている。これをAIに読ませて、質問に答えられるようにしたい——という相談は、いま最も件数が多い部類に入ります。
ところが試作してみると、期待した答えが返ってこない。「A社向けの見積もり構成は」と聞いても「該当する資料は見つかりません」。中身を確認すると、資料そのものは取り込まれています。壊れているのは、文書をテキストに変換した段階です。
PowerPointの箇条書きが1行に潰れている。Excelの結合セルが崩れて、どの数字がどの項目のものか分からない。2003年に作られた .doc は文字化けし、PDFは段組みが混ざって文章の順番が入れ替わっている。この状態のテキストをどれだけ高性能なモデルに渡しても、答えは出ません。
前処理の品質がそのまま回答の品質になる
社内文書をAIに読ませる仕組みは、おおまかに「文書を取り込む → テキストに変換する → 検索できる形にする → モデルに渡す」という流れになります。手を入れやすいのは後半ですが、精度に効くのは前半です。
変換の段階で表の構造が失われれば、後段でどれだけ工夫しても復元できません。にもかかわらず、この工程は「とりあえずライブラリを入れて動いた」で済まされがちです。理由もはっきりしていて、形式ごとに別のライブラリを使うからです。PDFはこれ、Wordはこれ、PowerPointはこれ、と積み上げていくうちに、同じ見出しが形式ごとに違うMarkdownになる。検索の対象としては最悪の状態です。
anydoc が揃えるのは「品質」ではなく「出力の一貫性」
Firecrawlが2026年8月5日にオープンソースで公開したanydocは、この工程を1本にまとめるRust製のライブラリです（gihyo.jpの記事）。MITライセンスで、Node.jsとPythonのバインディングが用意されています。
対応するのは、Word（.doc / .docx）、OpenDocument、RTF、EPUB、PDF、プレゼンテーション、表計算、CSVなど14形式です。特徴は形式の多さそのものより、すべての形式が同じ内部のドキュメントモデルを経由して、同じMarkdownシリアライザから出力されるという構造にあります。
これが効くのは、次のような場面です。
- 2003年の
.docと昨日作った.pptxから、同じ形の見出しとリストが出てくる - 表の結合セルや脚注が、形式をまたいで同じ表現に落ちる
- 変換結果の差分を見たときに、文書の変更なのか変換の揺れなのかを切り分けられる
3つめは地味ですが、運用に入ると効いてきます。定期的に再取り込みする仕組みを作ると、変換ライブラリのバージョン差で全ドキュメントに差分が出るという事故が起きます。1本に揃っていれば、その原因を疑う手間が減ります。
速度は、テストされた14形式すべてで中央値5ミリ秒未満とされています。数千件を一括で取り込む初回処理と、日次で差分だけを回す運用の両方で、変換が待ち時間の主因にならない水準です。
anydoc では解決しない3つのこと
導入を検討する前に、残る課題を先に見ておくほうが後の落胆が少なくて済みます。
1つめは、スキャンされたPDFです。紙をスキャンしただけのPDFには文字情報がありません。ここはOCRの領域で、変換ライブラリの守備範囲外です。契約書や請求書のように紙で回ってきた文書が多い会社ほど、こちらの比重が大きくなります。OCRと言語モデルを組み合わせる場合の勘所はOCRとLLMのハイブリッド構成で扱っています。
2つめは、レイアウトに意味を持たせた文書です。位置関係で情報を伝えている設計図面や、セルの色で状態を表しているExcelは、Markdownに落とした時点で意味が抜けます。これは変換ツールの優劣ではなく、Markdownという形式が持てる情報の限界です。
3つめは、権限です。共有ドライブの文書には、部署限定・役員限定のものが混ざっています。全部をまとめてテキスト化して1つの検索対象に入れると、権限のない人が中身を引ける状態が簡単に出来上がります。変換は権限を持ち越しません。ここは設計で分けるしかない部分です。
検索の精度が出ないときに疑う順番
前処理を整えても答えが出ない場合があります。そのときに疑う順番を決めておくと、無駄な作業が減ります。
- 変換結果を目で見る。1件でよいので、変換後のMarkdownをそのまま読みます。人が読んで意味が通らないものは、モデルにも通りません
- 検索が該当文書を拾えているかを見る。回答の前段で、そもそも正しい文書が候補に入っているかを確認します
- モデルへの渡し方を見る。候補は正しいのに答えがずれる場合が、ここに該当します
1で止まっているのに3をいじるのが、いちばんよくある遠回りです。検索側の調整で改善できる範囲はRAGの精度を上げる実装パターンに、そもそも言語モデル単体で解くべきでない業務の切り分けは業務AIは言語モデルだけでは成立しないにまとめています。
自社で仕組みを作らずに済ませたい場合、Google Workspace側の機能で足りることもあります。判断材料はNotebookLMとWorkspace Studioで社内ナレッジを扱うを参照してください。
次にやること
過去の提案書を10本選んで、いまの仕組みで変換した結果を読んでみてください。表が読める形で残っているか、見出しの階層が保たれているか。この2点が崩れているなら、モデルやプロンプトをいじる前に変換工程を直すほうが、投じた時間に対する見返りが大きくなります。
社内文書の活用基盤を設計から相談したい場合は、グリームハブの開発・AI・自動化のご相談で承っています。文書の量・形式・権限の構成によって適切な設計は変わるため、個別にお見積りします。お問い合わせからご相談ください。
