ManPlus

AIが、あなたの「できる」を拡張する

RAGの精度は「AIが読めるデータ」で決まる。ITコンサルが教える“AIが喜ぶ”社内文書の整理術

0 views
約11分
RAG

「ChatGPTのようなAIを導入すれば、明日から社内の問い合わせ対応が自動化される」
「膨大なマニュアルをAIに読ませれば、ベテラン社員のような回答ができるようになる」

2023年以降、生成AI(Generative AI)の爆発的な普及に伴い、多くの経営層がこのような夢を抱きました。そして、トップダウンの指示を受けた総務や情報システム部門の担当者たちは、急ピッチでPoC(概念実証)や導入プロジェクトに奔走しました。

しかし今、現場で起きているのは「劇的な業務効率化」ではなく、「静かなる絶望」です。

導入したAIチャットボットは、自社の就業規則について聞いているのに他社の一般的なルールを回答したり、存在しない申請書名を自信満々に提示したりする。いわゆる「ハルシネーション(もっともらしいウソ)」の連発です。「これでは使えない」と現場から総スカンを食らい、高額な導入費用をかけたプロジェクトが塩漬けにされる――。このような事例が、日本中の企業で後を絶ちません。

なぜ、魔法の杖と思われたAIは、御社の期待を裏切るのでしょうか。 AIの性能が低いからでしょうか? プロンプト(指示出し)の技術が足りないからでしょうか?

数々の現場を見てきた立場から断言します。原因はAI側にはありません。最大の原因は、AIに「食べさせる」社内データの品質にあります。

本稿では、システム開発会社が契約前には決して語りたがらない「RAG構築の不都合な真実」と、それを乗り越えるための「泥臭いデータ整備」の極意について、技術的な裏付けと共に徹底解説します。


【第1章】LLMの本質と「RAG」というカンニングペーパー

ハルシネーションを防ぐ方法を論じる前に、そもそもなぜ大規模言語モデル(LLM)が嘘をつくのか、そのメカニズムを正しく理解しておく必要があります。

1. LLMは「意味」を理解していない

ChatGPTなどのLLMは、人間のように言葉の意味を理解して思考しているわけではありません。彼らがやっているのは、「確率計算」です。膨大なインターネット上のテキストデータを学習し、「ある単語の次に、どのような単語が来る確率が高いか」を予測してつなげているに過ぎません。

例えば、「日本の首都は」という入力に対して、「東京」という単語が続く確率が極めて高いことを知っているため、そう出力します。しかし、学習データの中に誤った情報が多かったり、未知の事象について問われたりすると、LLMは「確率的に繋がりそうな言葉」を勝手に紡ぎ出し、もっともらしい嘘(ハルシネーション)を生成します。LLMにとって重要なのは「文章としての自然さ」であり、「事実としての正確さ」ではないからです。

2. RAG(検索拡張生成)の仕組み

この「嘘をつく」という弱点を克服し、企業固有の正確な情報を答えさせる技術として登場したのが、RAG(Retrieval-Augmented Generation)です。

RAGの仕組みを平易な言葉で表現するならば、「持ち込み可の試験(オープンブックテスト)」です。 通常、LLMは自分の記憶(学習済みデータ)だけで回答しようとします。これがハルシネーションの元です。対してRAGは、ユーザーから質問があった際に、まず社内のデータベース(社内Wiki、マニュアル、規定集など)を検索します。そして、関連するドキュメントを見つけ出し、それを「参考資料」としてLLMに提示した上で、「この資料に基づいて回答しなさい」と指示を出します。

「記憶」ではなく「資料」に基づいて回答させる。これにより、ハルシネーションは劇的に抑制され、自社固有のルールに基づいた回答が可能になる――。これがRAGの理想的なシナリオです。

しかし、ここには重大な落とし穴があります。 もし、試験会場に持ち込んだ「カンニングペーパー(参考資料)」が、黒塗りで読めなかったり、ページがバラバラで文脈が繋がっていなかったりしたらどうなるでしょうか? どれほど優秀な頭脳(AI)を持っていても、参照するデータがゴミであれば、出力される回答もまたゴミになります。IT業界には古くから「Garbage In, Garbage Out(ゴミを入れればゴミが出る)」という格言がありますが、最先端の生成AIにおいても、この原則は残酷なまでに適用されるのです。


【第2章】なぜAIは御社のデータを「読めない」のか

「うちはデータなら山ほどある。過去20年分の業務マニュアルや日報がファイルサーバーに入っている」 そう仰る担当者の方は多いですが、残念ながらそのデータの9割は、今のままではAIにとって「無意味なノイズの塊」です。

人間にとって「見やすいデータ」と、AIにとって「理解しやすいデータ(構造化データ)」は、全くの別物です。日本のオフィスワークが生み出してきた「職人芸のようなドキュメント」が、皮肉にもAI活用を阻む最大の障壁となっています。具体的に何が問題なのか、3つの代表例を挙げます。

1. 「神エクセル」という名のデジタル公害

日本企業、特に行政や伝統的な大企業で愛用される「神エクセル」。印刷した時の見栄えを重視し、セルの結合を多用し、方眼紙のようにExcelを使う手法です。 人間が見れば、結合されたセルの見出しが、その下の行すべてにかかっていることを視覚的に理解できます。しかし、AI(およびコンピュータ)にとって、セル結合は「データの破壊」でしかありません。

例えば、請求書データにおいて「会社名」のセルが縦に3行結合され、その横に「商品A」「商品B」「商品C」が並んでいるとします。これをプログラムで読み込むと、商品Aの行には会社名が存在しますが、商品Bと商品Cの行における会社名は「空白(Null)」として認識されます。 このデータをRAGに食わせても、AIは「商品Bを購入した会社」を特定できません。結果、「データが見つかりません」と答えるか、別の会社の情報を確率的に捏造して回答することになります。レイアウトへの過剰なこだわりが、データの論理構造を破壊しているのです。

2. 「画像」として死蔵されるPDF

紙の書類を複合機でスキャンし、PDFとして保存して「ペーパーレス化完了」としていませんか? OCR(文字認識)処理が施されていないスキャンPDFは、AIにとっては単なる「画像」です。風景写真と同じであり、そこに文字情報は存在しません。当然、検索キーワードにも引っかからず、RAGの参照元として機能しません。

また、仮にOCRをかけたとしても、精度が低ければ悲劇が起きます。「10,000円」が「70,000円」と誤認識されたり、「氏名」が「氏各」と誤変換されたりしたテキストデータ。これを参照してAIが回答を作成すれば、企業の信頼に関わる重大な誤情報を生成することになります。

3. 文脈を分断する「凝ったWord」と「パワポ資料」

WordやPowerPointで作られたマニュアルも、AIにとっては難敵です。 人間は、ページを跨いで文章が続いていても、無意識に脳内でつなぎ合わせます。また、図解やテキストボックスが本文の横に配置されていても、視線の移動で文脈を補完します。

しかし、RAGのシステムがドキュメントを読み込む際、基本的にはテキストを上から順に抽出します。段組みやテキストボックスが多用された凝ったレイアウトの文書は、抽出の過程で文章の順序が入れ替わったり、図解の中の単語が本文に唐突に紛れ込んだりします。 結果として、AIには「主語と述語が支離滅裂な文章」として認識されます。これを「チャンク(情報の塊)」としてベクトルデータベースに保存しても、検索精度が上がらないのは当然です。


【第3章】システムベンダーが語らない「責任分界点」の罠

ここで一つの疑問が浮かぶはずです。「なぜ、AI導入を提案してきたベンダーは、そのことを最初に教えてくれなかったのか?」と。

答えはシンプルです。「データの整理」は、システム開発会社にとって最も利益率が低く、かつリスクが高い泥臭い作業だからです。

多くのAI開発ベンダーやSIerの見積書には、小さな文字で「前提条件」が書かれています。 『学習用データは、お客様にてテキスト形式でご用意いただくものとします』 『データクレンジング費用は含みません』

彼らは「最新のAIモデルの実装」や「チャットUIの開発」といった、華やかで技術的な領域に特化したいと考えています。企業のファイルサーバーの奥底にある、ファイル名も不統一で、パスワードがかかったり壊れたりしている数万点のファイルを一つひとつ開き、中身を確認して整理するような作業は、彼らのビジネスモデルには馴染まないのです。

その結果、プロジェクトが始まってから「データが汚すぎてAIが回答しない」という事実が発覚します。ベンダーは「御社のデータ不備です」と言い、発注側の担当者は「どう整理すればいいかわからない」と頭を抱える。これが、多くのRAGプロジェクトが失敗する典型的なパターンです。

「AI導入」とは、単にソフトウェアを買うことではありません。過去数十年にわたって蓄積してきた「アナログな業務の負債」を返済し、データをあるべき姿に戻す「業務改革(BPR)」そのものなのです。この視点が欠けたままツールだけを導入しても、絶対に成功しません。


【第4章】ManPlus流・「AIが喜ぶ」データ整理術

では、どうすればよいのでしょうか。 社内の総務担当者が、膨大な業務の合間を縫って、数万件のExcelファイルのセル結合を解除し続けるべきでしょうか? それは現実的ではありませんし、モチベーションも続かないでしょう。

ここで必要となるのが、「テクノロジーを使った泥臭いデータ整備」「外部の専門家の知見」です。私たちManPlusは、単なるAI開発会社ではありません。様々な現場で「業務プロセスの可視化・効率化」に従事してきた経験を持つプロフェッショナル集団です。

私たちは、AI開発の前段階である「データ整備(前処理)」にこそ、プロジェクトの資源を集中させるべきだと考えています。具体的には、以下のようなアプローチで「AIが読めるデータ」を構築します。

1. 高精度OCRと人間による補正のハイブリッド

請求書らくらく読取」などの自社プロダクト開発で培ったOCR技術をフル活用します。単に文字にするだけでなく、文書のレイアウト解析を行い、見出しと本文の関係性を維持したままテキスト化します。さらに、AIが誤読しやすい箇所(数字や固有名詞)については、必ず人の目によるチェック工程を挟むプロセスを設計します。「99%の精度」では業務には使えません。残り1%のノイズをどう除去するかが、実用化の鍵です。

2. ドキュメントの「構造化」と「標準化」

「神エクセル」や「凝ったWord」を、AIが理解しやすいMarkdown形式やJSON形式といった「構造化データ」へ変換します。 しかし、過去のデータを直すだけでは不十分です。「今後作られるデータ」が再び汚れてしまっては意味がありません。 「今後はExcelでマニュアルを作らない」「Wordの見出しスタイルを統一する」「ファイル名の命名規則を徹底する」といった、業務運用のルール作り(ガバナンス策定)まで踏み込んで支援します。ここまでやらなければ、RAGは半年後にまたゴミ溜めを参照することになります。

3. AIに「文脈」を与えるチャンキング戦略

長い文章をAIに読み込ませる際、一定の長さで区切る処理を「チャンキング」と呼びます。機械的に「500文字で切る」といった単純な処理では、重要な文脈が分断されてしまいます。 私たちは、文書の章立てや意味のまとまり(セマンティック)を解析し、AIが検索しやすい最適な単位で情報を分割・タグ付けします。「マニュアルの第3章と第5章に関連性がある」といったメタ情報を付与することで、AIの回答精度を飛躍的に向上させます。


【結論】RAG構築は「システム開発」ではなく「経営判断」である

ここまで読み進めていただいた方には、RAG構築が決して「魔法のツール導入」ではなく、地道で堅実な「業務とデータの再構築」であることがお分かりいただけたかと思います。

AIは、御社の現状を映す鏡です。 データが整理されていれば、AIは優秀なアシスタントになります。 データが混沌としていれば、AIは混乱した嘘つきになります。

「RAGを導入したい」と考えたとき、安易に安価なパッケージツールに飛びつかないでください。「データ整理は御社でお願いします」というベンダーに任せないでください。その先に待っているのは、利用されないシステムと、徒労感だけです。

ManPlusは、「AI開発」と「データ整備・業務コンサルティング」を分断しません。 「汚いデータの山」を前にして途方に暮れているなら、まずはそのままの状態でご相談ください。 「どのデータが使えて、どのデータが使えないか」の診断から、「どうすれば最小の工数でデジタル化できるか」の戦略立案、そして「実業務で使えるAIアプリの実装」まで、ワンストップで伴走します。

AI時代において、真の競争力となるのは「AIモデルの性能」ではなく、「自社独自の整理されたデータ資産」です。 その資産を磨き上げる最初の一歩を、私たちと共に踏み出しませんか?

Share / Subscribe
Facebook Likes
Posts
Hatena Bookmarks
Pinterest
Pocket
Evernote
Feedly
Send to LINE
052-684-5907
お問合せはこちら
お問合せはこちら