LLMが企業文書を消化できないなら、直すべきはモデルの手前だ

先月、ナレッジマネジメントを担当する知人から愚痴を聞いた。会社はそれなりの金をかけて社内QAシステムを導入し、PDFやWord、スキャン文書数万件をベクトルデータベースに流し込み、「質問すれば答えが返る」の日を待ち続けていた。ところが現実はこうだ。スキャン文書はかすれたまま入り、検索で返ってくる段落は質問と何の関係もない。経理部では誰かが顧客情報入りの契約書を公衆網のチャットツールにそのまま貼り付けていた。プロジェクトチームがたどり着いた結論には、少しの皮肉が滲んでいた——モデルの問題ではない。モデルに与えるものの質が問題なのだ。

この手の話は珍しくない。一つの会社の中で、従業員は1日に35種類ものアプリを行き来する。集中力に関する研究は別の数字も残している。タスクが中断されると、元の集中状態に戻るまで平均23分かかる。答えを探すコストはもともと高い。そこへ社内QAが的外れな答えを返してくれば、人々は結局フォルダを漁りに戻るか、文書を外部のAIツールに貼り付けるかのどちらかを選ぶ。新しいリスクを足す形になる。

今日取り上げたいのはモデルの善し悪しではなく、その手前にある区間——文書をどうやってモデルが本当に「消化」できるデータに変えるか、だ。UglyPear Dataがこの工程向けに用意しているのが「RAGデータエンジニアリング基盤」。位置づけは「高性能文書圧縮 × RAGデータエンジニアリング」で、全プライベート展開によりデータは内ネットワークから出ない。

文書をそのままモデルに与えると、何が欠けるか

RAGとは「文書を切り分けてベクトルを算出し、ライブラリに保存するだけ」と思われがちだ。実際に動かしてみると、企業文書は想像のようなきれいなテキストではないことがわかる。

格式の層。PDFにはスキャン文書が混ざり、版式文書にはOFDという中国特有のフォーマットがあり、表は画像の中に隠れ、印影が肝心な情報の上に重なっている。これらを処理せずに切り分ければ、モデルが読めない断片が生まれ、検索は当然ふらつく。

冗長の層。同じ契約書にバージョンが5つあり、会議議事録は8回コピーされ、スライドの半分はテンプレートのページだ。こうした重複がベクトルデータベースに入り込むと、容量を食うだけでなく検索結果を濁す。一つの質問に対してほぼ同じ文面が5つ返り、本当の答えは後ろへ追いやられる。

機微情報の層。契約書の身分証番号、財務表の銀行口座、履歴書の住所。こうしたフィールドが文書と一緒に検索の経路に入ると、問うた人がそのまま見えてしまう。公衆網のツールで質問すれば、顧客データをそのまま社外へ送り出すことと同じだ。

三つの層が重なるからこそ、大半の「文書QAプロジェクト」が三か月で誰にも使われなくなる理由が説明できる。

シャドーAI：避けて通れないリスク

公衆網ツールの話をもう少しだけ。IBMの「2025年版データ漏えいコスト報告」にはこうある。従業員が私的にAIツールを使ったことが原因——業界では「シャドーAI」と呼ぶ——でデータ漏えいを経験した企業は5社に1社。こうした企業の平均漏えいコストは他社より67万米ドル高い。さらに考えさせられるのが別の数字だ。漏えいを経験した組織のうち63%は、まだ成文化したAIガバナンス方針を持っていない。

要するに、封じるより整えるほうが効く。従業員がAIを使うのは秘密を漏らしたいからではなく、正規の社内チャンネルが使いものになる答えを出せないからだ。禁令に頼るより、社内のデータパイプラインを先に修繕するほうが早い。文書をローカルでクレンジング・マスキング・圧縮してから検索ライブラリへ入れる。社内システムでまともな答えにたどり着けるなら、契約書を外のチャット窓に貼る理由は自然と消える。

「では市販のSaaSナレッジベースを買えば？」という声もあり得る。悪くない選択だが、一点だけ確認してほしい。文書をアップロードした時点で、データは他人のサーバーに置かれる。一般的な業種なら許容できるかもしれないが、金融、医療、法律、行政の現場では、契約書・カルテ・訴訟資料は触れてはいけない一線だ。プライベート展開の意味は技術の先進性ではなく、データの行き先を決める権限を自分の手に残すことにある。UglyPear Dataは「データは内ネットワークから出ない」を前提線に置き、RAGデータエンジニアリング基盤を全プライベート展開で提供し、13種類のAI機微情報を自動検出・マスキングする。一連の処理はすべて企業自身の環境の中で完結する。13種類の守備範囲は、身分証番号・銀行カード・電話番号といった定番のフィールドに加え、金融・医療・法律の現場特有の機微構造も含む。もっとも、マスキング規則が自社の業務に合致するかどうかは、実際の文書で試してから判断してほしい。

「六つの工程と八つの能力」という整理も、聞こえはマーケティング風だが、分解すれば素朴だ。工程は文書の取り込みからライブラリ登録までの各処理段階を指し、能力は圧縮・マスキング・構造化といった複数の段階で再利用できる基本技能を指す。各工程の具体的な設計は、公式資料を取り寄せて自社の文書フローと突き合わせてみるのが、何より確実だ。

圧縮を先に、投入はそのあと——削れるのは実費

データ工程の反対側にはコストがつながっている。企業文書で体積を取るのはたいていスキャン文書と画像で、数百ページのスキャン契約書は元ファイルだけで数百メガバイトに及ぶこともある。そのまま投入すれば、ストレージもベクトル化も安くつかない。

ここで圧縮の番だ。SmartSlimの圧縮エンジンはPDF・画像・動画・音声・Office・OFD・スキャン文書など8系統のフォーマットをカバーし、体積は60%〜80%削れる。処理はすべてローカルで完結する。大規模モデル利用向けの最適化はさらに重要で、画像系コンテンツはGPT-4o比でトークンコストを85.9%削減した実測がある。文書が小さく、きれいになれば、埋め込み・検索・質疑応答のどの段階でも呼び出し量が下がる。公式が公表した極端な例では、443ページのOFD文書をエンドツーエンドで124秒処理し、印影も版式も保たれた。

「圧縮は内容を傷めないか」という疑問にはこう答えておきたい。高品質（保真）モードは版式構造の下層に触れず、冗長データだけを最適化するため、テキスト内容自体は影響を受けない。それでも、投入前に数ページ抜き出して拡大確認する習慣は、持っておいて損がない。

三つのルートの選び方

ここまでを一つの表にまとめると、企業文書を大規模モデルにつなぐ道はおおむね三つだ。

この表は選定の視点を並べた枠組みであって、製品の評価表ではない。企業ごとに文書の構成は違うし、重み付けも自分で決めるべきだ。医療ならマスキングを最上位に置くだろうし、EC事業ならコストのほうに重きを置くかもしれない。

政策が背後を押している

外部変数も一つ押さえておきたい。中国の財政部をはじめとする9部門は2025年5月、「電子証憑会計データ標準の普及・応用に関する通知」（財会〔2025〕9号）を発布し、各機関の会計ソフトを2027年12月31日までに電子証憑会計データ標準へ適合させるよう求めた。平たく言えば、企業文書の全面構造化・機械可読化は政策が引いた時刻表であり、選択肢ではない。

全面デジタル化された電子発票（数電発票）はすでに全国に広がり、普及率は八割を超える。コンプライアンス上の精算・保存フォーマットは、デジタル署名付きのXML構造化ファイルだ。今後数年、企業の文書データ工程は「やるかどうか」ではなく「どのテンポでやるか」の議論になる。クレンジング、マスキング、構造化、投入というパイプラインを先に組み上げてしまえば、政策対応もモデル接続も監査対応も後に自然に続く。遅れた側は、その場しのぎの慌ただしさを味わうことになる。

RAGデータエンジニアリング基盤の製品ページはこちら。圧縮側の能力を確認したいならSmartSlimの製品ページへ。両者の連携の仕方については、UglyPear Dataの技術ブログでより細かく分解している。

今すぐ試す

• RAGデータエンジニアリング基盤（プライベート展開、13種類の機微情報マスキング、六つの工程＋八つの能力）：https://www.uglypear.com/ja/
• SmartSlim製品ページ（圧縮エンジン、デスクトップ版、SDKとAPI）：https://www.uglypear.com/ja/products/
• UglyPear Data技術ブログ（圧縮とデータ工程の実践を継続更新）：https://www.uglypear.com/ja/blog/

よくある質問

Q: RAGプロジェクトの精度が上がらないとき、モデルを変えるべきか、データを先に治すべきか。
A: データが先だ。「答えが的外れ」の根は多くの場合、文書の質にある——スキャンがかすれている、バージョンが重複している、構造が乱れている。クレンジング、マスキング、圧縮の一連の工程を通してから評価すれば、問題の一部は自然に消える。順序を逆にしてデータをそのままにモデルだけ替えても、どれを選んでも結果は似たようなものだ。

Q: 13種類の機微情報検出はすべてローカルで完結するのか。
A: する。検出もマスキングも企業のプライベート環境の中で動き、データは内ネットワークから出ない。規則は業種や場面に応じて調整できる。

Q: 圧縮した文書を大規模モデルに与えると、回答の質は下がるか。
A: 高品質（保真）モードは版式構造の下層に触れず、冗長データだけを最適化するため、テキスト内容自体は影響を受けない。画像系はGPT-4o比でトークンコスト85.9%削減の実測がある。投入前に主要ページを抽出して確認しておくと安心だ。

Q: すでに自前のベクトルDBがあるが、基盤は併用できるか。
A: できる。基盤が担うのは投入前の区間——クレンジング、マスキング、圧縮、構造化——で、その出力を既存のベクトルDBに接続すればよい。作り直す必要はない。

Q: プライベート展開には高いハードウェア要件がいるか。
A: 文書量と同時実行数による。実際の文書を使って小規模に検証し、実測値に基づいてリソースを計画するほうが、机上の見積もりより確実だ。