AIに社内文書を読ませても、正確な集計ができるとは限らない理由──AI検索と構造化データの使い分け

ChatGPTをはじめとするAIが、当たり前のようにビジネスの現場へ組み込まれるようになりました。

現在では過去の業務に関するドキュメントなどをAIで活用する方法として、RAGを利用している企業も少なくないはずです。

特にMicrosoft Copilotなどのサービスでは、利用者が意識しなくても、質問に関連するファイルや情報をSharepointやOneDriveから該当箇所を検索し、AIがそのファイルの内容を参照して回答する仕組みが組み込まれています。そのため、現在では「RAGを利用している」という認識すら持たずに、AIで事例などの検索をしているケースも多いでしょう。

※RAGとは、WordやPDFなどの文書をAIが参照可能な情報として登録し、質問に関連する文章を検索したうえで、その内容をAIに渡して回答を生成する仕組みです。

例えば、製造業やメーカーなどにおいて過去の不具合報告書をAIが参照できるようにしておけば、次のような質問ができます。

• 過去に似た不具合は発生しているか
• 同様の事例では、どのような対応を行ったか
• この症状から考えられる原因は何か
• 複数の報告書に共通する傾向を整理してほしい

これまで担当者が一件ずつ文書を開いて探していた情報を、自然な文章で検索できるようになるため、AIによる検索手段はかなりの検索コストの削減となっているはずです。

一方で、ファイルをAIに読み込ませるだけでは、すべての質問に正確に答えられるわけではありません。特に、件数の集計や、条件に一致する文書の全件抽出といった、結果が一意に決まる決定論的な処理です。

「似た事例」は探せても、「全部で何件」は分からない

例えば、製造業を営んでいる会社に、過去の不具合報告書がWordやPDFで数百件保存されているとします。これらの報告書をAIから検索できるようにすると、次のような質問には比較的答えやすくなります。

部品Aの破損と似た不具合事例を教えてください。

AIは、質問と意味の近い文章を検索し、関連性が高いと判断した報告書を提示します。文書内に「部品Aの破損」という表現がそのまま書かれていなくても、次のような記述を関連事例として見つけられる可能性があります。

• 接合部分に亀裂が発生した
• 対象部品の強度が不足していた
• 固定箇所に過度な負荷がかかった
• 連結部分から破損が進行した

表現が異なっていても、文章の意味をもとに似た情報を探せることは、AIによる文書検索の大きな強みです。しかし、次の質問では事情が変わります。

過去3年間に、部品Aが原因となった不具合は何件ありましたか。

一見すると、先ほどの検索とそれほど違わないように見えます。

しかし、この質問に正確に答えるには、対象となるすべての報告書を確認し、条件に該当する事例を漏れなく抽出したうえで、件数を数える必要があります。

一般的なAIの検索では、質問の意図に近しい文章の一部を取得し、その内容をベースに回答します。すべての文書を、毎回端から端まで確認しているとは限りません。仮に条件に該当する報告書が100件存在していても、AIに渡された検索結果が上位10件だけであれば、AIはその10件をもとに回答することになります。そのため、AIが「10件です」と回答しても、それが全件を確認した結果である保証はなく、AIが出力してきた情報をそのまま信用してしまうと大きな認識の齟齬をもったまま業務を進めてしまう可能性があります。

プロンプトを工夫しても解決できないことがある

正確な回答が得られない場合、まずプロンプトを改善しようとする人は多いはずです。

例えば、次のように指示を詳しくします。

保存されているすべての報告書を確認し、部品Aに関する不具合を漏れなく抽出してください。

しかし、プロンプトで「すべて確認してください」と指示しても、AIが拾う情報が一部であれば、全件を確認することは当然できません。これは、AIの性能やプロンプトの書き方だけの問題ではないのです。文書の中から近い情報を探すことと、条件に一致するデータを抽出する処理が、根底的に異なるものだからです。

非構造化データと構造化データの違い

ここで関係するのが、非構造化データと構造化データの違いです。WordやPDFで作成された報告書の多くは、非構造化データとして扱われます。非構造化データとは文字通り、構造になってない、端的に言えばExcelのような表の形式になってないデータを指します。

例えば、報告書に次のような文章が書かれていたとします。

2026年4月10日、製品Xの接続部で破損が確認された。調査の結果、A社から仕入れている部品Aの強度不足が原因と判断した。重大度は高く、対象製品の出荷を一時停止した。

この文章には、次のような情報が含まれています。

• 発生日
• 製品名
• 部品名
• 仕入先
• 不具合内容
• 原因
• 重大度
• 対応内容

人間やAIが文章を読めば、これらの情報を理解できます。

しかし、それぞれの情報が文章として埋め込まれているため、Excelのフィルターのように「部品Aだけを抽出する」「重大度が高い事例だけを数える」といった処理には向いていません。

一方、同じ情報を項目ごとに整理すると、構造化データになります。文字通り構造化データとは表のように構造化されたデータです。表データだけでなく、広く言えばJSONなどのデータも含まれます。

このように情報が項目ごとに分かれていれば、Excelのフィルターやピボットテーブルだけでも、次のような処理ができます。

• 部品Aに関する事例を全件抽出する
• 仕入先別の不具合件数を集計する
• 月ごとの発生件数を確認する
• 重大度が高い未対応案件を一覧にする
• 同じ原因による不具合の再発状況を調べる

つまり、情報が表として整理されていることで、条件に基づく検索や集計を決定的に処理できるようになります。

更に発展させたケースで言えば、例えば内部で使うシステムなどに抽出可能なデータとして利用することもできます。これは構造化されてないデータではできません。内製化してデータ基盤をもつ、専用のアプリケーションを開発すると言った際にもデータが構造化されているということは効いてくるのです。

AIによる文書検索と構造化データは別の役割を持つ

重要なのは、すべての文書を構造化すればよいということでも、AIによる文書検索が役に立たないということでもありません。

両者は、得意とする処理が異なります。

AIによる文書検索が得意なこと

• 過去の類似事例を探す
• 不具合が発生した経緯を確認する
• 原因や対応内容を要約する
• 複数の報告書から共通点を整理する
• 表現の異なる関連情報を探す

構造化データが得意なこと

• 条件に一致する事例を漏れなく抽出する
• 正確な件数を集計する
• 期間や製品、仕入先で絞り込む
• 分類別の傾向を比較する
• 件数や割合の推移を確認する

例えば、次のような質問を考えてみます。

過去3年間に部品Aで発生した重大度の高い不具合をすべて抽出し、それぞれの原因と対策を要約してください。

この質問に答えるには、まず構造化データを用意して、「過去3年間」「部品A」「重大度が高い」という条件に一致する報告書を抽出する必要があります。そのうえで、抽出された報告書の本文をAIに読み込ませ、原因や対策を要約させることができます。条件に基づく抽出は構造化データに任せ、文章の理解や要約はAIに任せることで、それぞれの強みを生かすことができるのです。

AIは文章を読めても、文章が自動的にデータベースになるわけではない

AIは、WordやPDFに書かれた文章を読み、内容を理解し、関連する情報を探すことができます。しかし、文章の中に含まれている日付、製品名、分類、重要度などが、自動的に正確なデータベースとして利用できるようになるわけではありません。似た情報を探したいのか、条件に一致する情報を漏れなく取り出したいのか。内容を要約したいのか、正確な件数を集計したいのか。実現したい業務によって、必要なデータの形や処理方法は異なってきます。

最初から大規模なデータベースを構築する必要はありません。WordやPDFから、日付、対象、分類、重要度など、集計に必要な項目だけを取り出し、ExcelやCSVとして整理するだけでも、利用できる選択肢は大きく広がります。

AIに資料を読み込ませた後にプロンプトの調整を繰り返すだけでなく、そもそも情報をどのような形で持つべきか、設計されている業務を元に考えることが必要です。AIを活用するうえでは、モデルやプロンプトだけではなく、データの持ち方を設計することも重要です。