生成AIのデータ構造化とは？精度を高める前処理7ステップと失敗例

社内文書を生成AIに読み込ませたのに、的外れな回答や古い情報が返ってくるという相談は少なくありません。原因の多くはモデルの性能ではなく、AIに渡しているデータの状態です。表が崩れたPDFや版数の異なる規程をそのまま取り込めば、高性能なモデルでも正しい答えは組み立てられません。回答の質は、プロンプトより手前にあるデータの整え方で大きく変わります。

データの構造化や前処理は、抽出・クレンジング・分割・付与といった複数の工程の組み合わせです。どこから手を付け、どの工程に人手をかけるかを決めないまま進めると、作業量だけが膨らみ精度は上がりません。特に部門ごとに文書の形式や管理ルールが異なる組織では、この点が大きな壁になります。全社の文書を一度に整えようとせず、用途を絞って工程を設計することが現実的な進め方です。

本記事では、生成AI向けのデータ構造化と前処理を7つのステップに分け、文書タイプ別の処理の勘所やよくある失敗パターンとあわせて解説します。業種別の活用事例も取り上げるため、自社で最初に着手する対象データと工程を決める際の判断材料としてお役立てください。

生成AIにおけるデータの構造化・前処理とは

生成AIに社内データを活用させる準備は、データの種類を見極めるところから始まります。構造化・半構造化・非構造化という3分類の違いを生成AIの扱いやすさから整理し、「構造化」と「前処理」がどう関係するのかを工程の全体像として示します。あわせて、多くの企業で前処理が停滞しやすい背景も押さえておきたい論点です。

構造化・半構造化・非構造化データの違い：生成AIから見た扱いやすさ

構造化データは、顧客マスタや売上明細のように行と列で定義された表形式のデータです。半構造化データはJSONやXML、HTMLのようにタグやキーで意味の区切りを持つものを指します。非構造化データはPDF、Word、スライド、音声、画像など、決まった形式を持たないデータの総称です。企業内データの8割前後は非構造化データとされ、生成AI活用の成果はこの領域の扱い方で決まります。以下の表で3分類を比較します。

生成AIから見ると、扱いやすさの順序は人間の感覚とは少し異なります。構造化データは値の正確さで優れる一方、列名が「KBN_CD」のような略号のままだと、AIが項目の意味を推測できない状態です。非構造化データは文章として読めるものの、表や図の位置関係が失われると意味が崩れるため、形式ごとに補い方を変える必要があります。半構造化データは中間的な存在で、キー名が業務用語で付いていれば比較的少ない加工で活用可能です。

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

「構造化」と「前処理」の関係：抽出・整形・分割・付与の全体像

前処理は、生データをAIが扱える状態に整える工程全体を指す言葉です。文字コードの変換からファイル形式の統一まで、対象範囲は広く及びます。構造化は、その中でも見出し・表・項目といった意味の区切りをデータに持たせる作業のことです。つまり構造化は前処理の一部であり、両者は並列の概念ではありません。実務では前処理を次の4工程に分けて考えると、担当範囲や使うツールを決めやすくなります。どの工程を誰が担うかを、次の分類に沿って確認してください。

• 抽出：PDFや画像、音声からテキストや表を取り出す
• 整形：表記ゆれの統一、重複や旧版の除外、ノイズの削除
• 分割：検索や入力に適した単位に文書を区切る
• 付与：見出し階層、文書種別、版数、閲覧権限などの情報を持たせる

このうち構造化にあたるのは、主に整形の一部と付与の工程です。抽出の段階で表の行列関係を失うと後工程では復元できないため、4工程は順番どおりに品質を確保していく必要があります。工数の目安としては、社内規程100文書程度の小規模な検証でも、抽出と整形だけで全体作業の6〜7割を占めるケースが多く見られます。モデル選定やプロンプト調整よりも、ここに時間を配分する前提で計画を立ててください。工数を見積もる際は、抽出と整形の担当者を先に確保しておくと計画が崩れにくくなります。

データプレパレーションとは？ETLとの違いから成功ポイントまで徹底解説

生成AI活用でデータ前処理がボトルネックになりやすい背景

生成AIの導入プロジェクトでは、PoCの段階で想定以上に前処理に時間を取られる例が目立つのが実情です。社内文書を検索して回答を生成するRAG（Retrieval-Augmented Generation）の仕組みは、クラウドサービスを使えば数日で動かせます。ところが実際の文書を投入すると、スキャンPDFの文字化けや部署ごとに異なるファイル命名が次々に表面化します。最新版がどれか分からない共有フォルダも、よく見つかる問題の1つです。

背景にあるのは、文書が人間に読まれる前提で作られてきたという事情です。レイアウトで意味を伝える資料や、担当者の頭の中にしかない略語は、人間には問題なくてもAIには解釈の手掛かりがありません。加えて、前処理の担当が情報システム部門と業務部門のどちらなのか曖昧なまま始まり、責任者不在で作業が止まるケースも多くあります。着手時点で前処理のオーナーを1名決め、対象文書の範囲と完了条件を文書化しておくことが停滞を防ぐ最初の手当てです。

生成AIガイド：最新技術からビジネス活用、成功事例まで

データを構造化すると生成AIの何が改善するのか

前処理に工数をかける判断を社内で通すには、得られる効果を具体的に説明できなければなりません。回答精度、検索性と根拠提示、コスト、運用の4つの観点から、構造化によって何がどう変わるのかを整理します。PoCの評価項目を決める際の観点としても使える内容です。

回答精度の向上とハルシネーションの抑制

生成AIがもっともらしい誤りを出力する現象はハルシネーションと呼ばれます。社内データ活用の場面では、参照すべき情報が検索で取り出せなかったときに、モデルが一般知識で空白を埋めることで発生しやすくなります。たとえば表が崩れた料金表を参照した結果、別プランの金額を答えてしまうといった誤りです。これはモデルの問題に見えて、実際には入力データの欠損が原因になっています。モデルを高性能なものに替えても、入力が欠けていれば誤りは解消しないのが実際のところです。

構造化によって表の行と列の対応や見出しと本文の関係が保たれると、検索で取り出される情報の正確さが上がります。規程検索の検証では、PDFをそのまま取り込むと正答率が6割前後にとどまるケースが典型です。見出し単位の分割と表のMarkdown化を施すと、8割台まで届くことも珍しくありません。プロンプトで「分からない場合は答えない」と指示するより、正しい情報を確実に渡せる状態を作るほうが誤回答の抑制効果は大きくなります。

検索性の向上と回答根拠の提示しやすさ

RAGでは、質問に近い文書の断片を検索し、その断片をもとに回答を生成します。検索の精度は、断片にどれだけ文脈情報が含まれているかで決まります。断片に「就業規則 第5章 休暇」のような見出しの情報が含まれていれば、検索エンジンは質問との関連を判断しやすくなるのが利点です。見出しがなく本文だけが切り出された断片は、同じような表現が並ぶ規程の中で埋もれてしまい、検索の上位に来ません。検索で見つからない情報は、どれほど優れたモデルでも回答に反映できません。

回答の根拠を示しやすくなる点も、業務利用では見逃せない効果です。構造化の際に文書名、版数、ページ番号、見出しを付けておけば、回答の末尾に「出典：経費精算規程 第3版 4.2節」と表示できます。利用者は原文をすぐ確認できるため、AIの回答を鵜呑みにするリスクが下がる仕組みです。出典表示は、誤回答が見つかった際に原因の文書を特定する手掛かりにもなります。社内展開で利用率が伸び悩むプロジェクトの多くは、回答の正誤を利用者が確かめられないことが不信感の原因になっています。

トークン消費と処理時間の削減

生成AIのAPI利用料は、入力と出力のトークン数に応じて課金されます。PDFから抽出したテキストには、ヘッダーやフッター、ページ番号、目次の繰り返しといった回答に不要な文字列が大量に含まれているのが普通です。これらを除去せずに検索対象とすると、1回の質問でモデルに渡す文字量が膨らみ、コストと応答時間の両方が増える結果になります。特にスキャンPDFのOCR結果には、罫線や透かしの誤認識による意味のない文字列も混ざります。

目安として、社内マニュアルのPDFからヘッダー類と重複段落を除くと、テキスト量は15〜30%程度減ることが多いです。1日1,000件の問い合わせに対応するチャットボットであれば、この削減は月額のAPI費用に直結します。月間3万件規模になると、入力トークンの削減幅がそのまま月数万円単位の差として表れるのが実態です。不要な文字列が減ると検索時に無関係な断片が上位に来にくくなり、コスト削減と精度向上を同時に得られます。

データ更新時のメンテナンス性の向上

社内規程や製品マニュアルは、年に数回の改訂が前提の文書です。改訂箇所は全体の数%にとどまるケースが大半です。構造化されていないデータを使っていると、1つの条文が変わっただけでも文書全体を取り込み直す必要があり、どの回答に影響するかも追えません。文書を見出し単位で分割し、それぞれに文書IDと版数を持たせておけば、変更された箇所だけを差し替えられます。改訂のたびに全文書を入れ替える運用では、担当者の負担が年々積み上がる構造です。

差分更新ができる状態にしておくと、更新作業の工数は大きく変わります。全件再取り込みでは1回あたり数時間から半日かかっていた作業が、差分のみなら数分から30分程度で済むケースが一般的です。更新履歴を残しておけば、誤回答が見つかった際にどの版のデータが原因かも特定できます。差し替えの対象を特定できれば、再処理にかかるAPI費用も最小限に抑えられます。更新のたびに担当者の手が止まる仕組みは長続きしないため、構造化の設計段階から差分更新を前提にしておくことが運用定着の条件です。

生成AI向けデータ前処理の進め方7ステップ

生成AI向けのデータ前処理は、着手から評価までを7つのステップに分けると進めやすくなります。ステップ1と2で対象を絞り込み、3〜6でデータを整え、7で効果を検証するという流れです。各ステップの間には手戻りが起きやすいため、後工程で見つかった問題を前工程のルールへ反映する前提で進めてください。

STEP1 用途の定義：社内Q&A・要約・Text-to-SQLで求める構造は変わる

最初に決めるべきは、生成AIに何をさせるかという用途です。同じ社内データでも、社内Q&Aに使うのか、長文の要約に使うのか、自然言語からSQLを生成するText-to-SQLに使うのかで、必要な構造が異なります。用途を曖昧にしたまま前処理を始めると、すべての文書に過剰な加工を施すか、逆に必要な情報を落とすかのどちらかに陥ります。Text-to-SQLであれば表の定義情報、要約であれば話者や議題の区切りが加工の中心です。

判断基準としては、回答に正確な数値が求められるならText-to-SQL、文書の記述を根拠に答えるなら社内Q&A型を選ぶのが基本です。「今月の部門別売上は？」のような質問を文書検索で答えさせようとすると、集計済みの資料がない限り正しい数値は返りません。用途を1つに絞り、その用途で想定する質問を20〜30件書き出してから前処理の設計に入ると、加工の過不足を防げます。書き出した質問は、STEP7で精度を測る際の土台にもなる資産です。

STEP2 対象データの棚卸し：鮮度・利用頻度・機密度で優先順位を付ける

用途が決まったら、候補となるデータを洗い出します。共有フォルダやSharePoint、Boxなどのストレージから、ファイル名、形式、最終更新日、保管部署、件数を一覧化するのが最初の作業です。SharePointではライブラリの一覧をExcelにエクスポートする機能が使えます。Googleドライブでも検索の詳細条件で更新日や形式を絞り込めるため、1〜2週間あれば全体像の把握は可能です。件数が1万件を超える場合は、部署単位に分けて進めてください。

洗い出した文書には、鮮度・利用頻度・機密度の3軸で優先順位を付けます。最終更新から3年以上経過し、問い合わせでも参照されない文書は初期対象から外して問題ありません。最初の対象は、更新が年1回以上あり、問い合わせ件数が多く、機密度が社内公開レベルの文書群に絞るのが最も失敗の少ない選び方です。機密度が高い文書は、権限設計が固まった第2段階で追加する方が安全です。件数の目安は100〜300文書程度で、この規模なら前処理の手順を固めつつ効果も測定できます。3軸それぞれで確認したい観点は次のとおりです。

• 鮮度：最終更新日、改訂予定の有無、最新版の所在が明確か
• 利用頻度：問い合わせ件数、閲覧数、関係する部署の数
• 機密度：個人情報や取引先情報の有無、閲覧権限の範囲

STEP3 テキスト抽出：OCR・文字起こし・マルチモーダルLLMの使い分け

テキスト抽出の方法は、元データの形式によって選びます。テキスト情報を持つPDFやWordであれば、Pythonのpdfplumberやpython-docxといったライブラリで直接取り出せます。スキャンPDFや紙の帳票画像にはOCR、会議や通話の音声には文字起こしが必要です。図や複雑な表を含む資料には、画像ごと読み取れるマルチモーダルLLMを使う選択肢もあります。Azure AI Document IntelligenceやAmazon Textractは、OCRと表構造の認識を1つのAPIで行えます。

使い分けの判断基準は、抽出後に人が確認できる量かどうかです。ページ数が多く定型的な帳票はOCR、ページ数は少ないが図の解釈が重要なスライドはマルチモーダルLLMというように、文書群ごとに手法を割り当てます。現場でよくあるつまずきは、全文書を1つの手法で処理しようとして、得意でない形式の品質が極端に落ちることです。最初に各形式から5〜10ファイルを抜き出して試験抽出し、結果を目視比較してから本処理に進んでください。

STEP4 クレンジングと正規化：表記ゆれを揃えてから旧版・重複文書を除外する

抽出したテキストには、全角と半角の混在、「（株）」と「株式会社」のような表記ゆれ、改行位置のずれといったノイズが含まれます。これを揃える作業が正規化で、Pythonであればunicodedataモジュールのnormalize関数で全角英数字を一括で統一できます。社名や製品名の表記ゆれは、正式名称と別表記の対応表を作ってから置換するのが確実です。対応表はExcelで管理し、業務部門に表記の妥当性を確認してもらうと抜け漏れが減ります。

順序で注意したいのは、正規化を先に行い、その後で旧版や重複文書を除外する点です。表記がばらばらなままだと、同じ内容の文書でも別物と判定され、重複として検出されません。正規化で表記を揃えてから旧版と重複を洗い出すと、除外漏れを大幅に減らせます。類似度はテキストをベクトル化して比べ、コサイン類似度0.95以上を重複候補とする基準が使いやすい方法です。最終的な除外判断は、文書の所管部署が行う運用にしてください。

データクレンジングとは？意味と代表手法を解説！

STEP5 構造の付与：見出し階層・表・QAペアへの変換

抽出・整形したテキストに意味の区切りを持たせるのが、このステップの役割です。人が見れば分かる区切りを、機械が読める印に置き換える作業と捉えると分かりやすいです。具体的には、見出しを「#」「##」で表すMarkdown形式に変換し、表はMarkdownの表記法かHTMLのtableタグで行と列の関係を保持します。WordやPDFのスタイル情報が残っていれば、見出しは自動で判定できます。ただしフォントサイズだけで判定すると、本文中の強調を見出しと誤認する点に注意が必要です。

規程やFAQのように「質問と答え」の形に整理できる文書は、QAペアに変換すると検索精度が上がる傾向にあります。LLMに条文を渡して「この条文から想定される質問と回答を3組作成してください」と指示すれば、下書きを短時間で作れるのが利点です。判断基準として、問い合わせの型が決まっている業務ならQAペア化、自由な質問が多い業務なら見出し構造の保持を優先します。QAペアは作成と保守の工数がかかるため、問い合わせ上位20%程度の論点に限定するのが費用対効果の高いやり方です。

STEP6 チャンク分割とメタデータ付与：文書種別・版数・閲覧権限を持たせる

RAGで検索する単位として文書を区切った断片をチャンクと呼びます。分割方法には、一定の文字数で機械的に区切る固定長分割と、見出しや段落の境界で区切る構造ベースの分割があります。目安としては1チャンク300〜800文字程度、前後のチャンクと50〜100文字を重複させる設定から試すのが一般的です。LangChainにはRecursiveCharacterTextSplitterやMarkdownHeaderTextSplitterが用意されています。これらを使えば、どちらの方式も数行のPythonコードで実装可能です。

チャンクには、本文と一緒にメタデータを付与します。メタデータとは、文書名や版数のように本文の内容を補足する属性情報のことです。チャンク単体では、その文章がどの文書のどの版に書かれたものかを判別できません。版の区別がないと、旧版の条文を最新の規程として答える誤りにつながります。現場でよくあるつまずきは、分割後に付与しようとして元文書との対応が分からなくなることです。分割処理と同時に元文書の属性を引き継ぐ実装にし、最低限次の6項目を持たせてください。

• 文書名：回答の出典として表示する
• 文書種別：規程、マニュアル、FAQなどで検索対象を切り替える
• 版数：旧版を検索から除外する
• 施行日：時点を指定した質問に対応する
• 見出しパス：「第3章＞3.2 出張旅費」のように文書内の位置を示す
• 閲覧権限：部署や役職に応じて表示を制御する

版数と施行日があれば最新版だけを検索対象に絞り込めて、閲覧権限があれば利用者の所属に応じて見せる情報を制御できます。Azure AI SearchやAmazon Bedrock Knowledge Basesは、メタデータを検索時のフィルタ条件に指定できる仕様です。ここでの設計は、そのまま検索機能の挙動に反映されます。項目名と値の形式は後から変えずに済むよう、最初にデータ定義書として固めておいてください。

メタデータとは？具体例を用いてわかりやすく意味を解説

STEP7 評価と改善：評価用質問セットで回答精度を検証する

前処理の効果は、感覚ではなく数値で確かめます。担当者の印象で「良くなった」と判断すると、改善の方向を誤ります。そのために用意するのが、想定質問と正解、正解の根拠となる文書箇所を組にした評価用質問セットです。件数の目安は50〜100問で、業務部門の担当者に実際の問い合わせ履歴から作成してもらうと、現実の質問分布に近いセットになります。易しい質問だけに偏らないよう、複数文書をまたぐ質問や表の数値を問う質問を2〜3割含めてください。

評価では、検索と回答を分けて測ると原因を切り分けやすくなります。検索の段階では、正解の根拠となるチャンクが上位5件に含まれる割合を確認します。回答の段階では、正答・部分正答・誤答の3段階で人が採点するのが最も確実な方法です。検索の上位5件に正解が含まれているのに誤答するならプロンプトやモデル、含まれていないなら前処理に原因があると判断できます。RagasのようなRAG評価用ライブラリを使えば、回答の忠実性などを自動で採点することも可能です。自動採点の結果は、人の採点と数十問で突き合わせて傾向を確かめてから使ってください。

データ品質とは？品質評価項目や品質を向上させるための実務的対策を解説

文書タイプ別に見るデータ構造化の実務ノウハウ

7つのステップは共通の流れですが、実際の作業では文書の種類ごとに固有の難しさがあります。企業で生成AIの参照対象になりやすい4つの文書タイプを取り上げ、それぞれで崩れやすい情報と、その補い方を具体的に示します。自社の対象文書に近いものから確認してください。

表を含むPDF：セル結合や複数ページにまたがる表の扱い

表を含むPDFは、生成AI向けの前処理で最もつまずきやすい文書です。単純なテキスト抽出では、セルの値が左上から右下へ1列に並んでしまい、どの値がどの行・列に属するかが失われます。特にセル結合を多用した料金表や、1つの表が2ページ以上にまたがる仕様一覧は、ツール任せでは高い確率で崩れます。Camelotやpdfplumberの表抽出機能を使う場合も、罫線のない表は認識されにくいという前提で臨むのが安全です。

結合セルの扱いは、結合を解除して同じ値を各セルに埋める「値の展開」が基本です。複数ページにまたがる表は、2ページ目以降でヘッダー行が省略されていることが多いため、1ページ目のヘッダーを付け直してから連結します。変換後の表は、元の表から無作為に5行程度を選び、値を突き合わせて確認してください。表の数が多い場合は、OCRサービスが出力する信頼度スコアを使い、スコアの低い表だけを人が確認する運用にすると工数を抑えられます。

スライド資料：図・矢印・注釈の関係をテキストで補う

PowerPointで作られた提案書や業務フロー図は、情報の多くを図形の配置と矢印で表現する資料です。python-pptxでテキストを抽出すると、図形内の文字は取り出せても、「申請→承認→支払」のような順序や吹き出しの指す先は失われます。スライド下部の注釈に重要な条件が書かれているのに、本文と結び付かないという問題もよく起こります。結果として抽出後のテキストは単語の羅列となり、AIが業務の流れを説明できない状態です。

対策としては、スライドを画像化してマルチモーダルLLMに読ませ、「この図の処理の流れを箇条書きで説明してください」と指示してテキスト化する方法が有効です。図の説明文をスライド本文とセットで保存しておけば、フローの順序や分岐条件も検索対象にできます。判断基準として、図の比率が高いスライドはLLMでの説明文生成、文字中心のスライドは通常の抽出で十分です。100枚規模の資料であれば、説明文の生成と目視確認をあわせて2〜3人日が目安になります。

議事録・通話記録：話者・決定事項・ToDoに分解する

議事録や通話記録は、時系列に発言が並ぶだけの形式では生成AIが扱いにくいデータです。「A案で進める」という発言があっても、誰の発言か、最終的に決まったのか、途中で覆ったのかが文脈に埋もれてしまいます。「先月の定例で決まった予算は？」という質問に正しく答えるには、会議単位で決定事項を取り出せる状態が前提です。通話記録も同様で、顧客の要望と担当者の回答が区別されていないと、問い合わせ傾向の分析に使えません。

構造化の手順は、話者分離、要約、項目抽出の順で進めるのが基本です。文字起こしの段階でAmazon TranscribeやGoogle Cloud Speech-to-Textの話者分離機能を有効にし、話者ラベルを社員名に置き換えます。その上でLLMに「決定事項」「ToDo（担当者・期限）」「保留事項」の3項目をJSON形式で出力させると、会議をまたいだ検索や集計が可能になります。期限が「来週中」のように曖昧な表現は、会議日付を基準に具体的な日付へ変換しておくのが実務上のコツです。

業務データベース・Excel：カラム定義と項目説明を整備する

業務データベースやExcel台帳は構造化データですが、そのままでは生成AIが正しく使えないことが多くあります。原因は、カラム名が「CUST_KBN」「F_DEL」のような略号で、値も「1」「2」といったコードで入っている点です。人間は業務知識で補えても、AIは「CUST_KBN＝2が法人顧客を意味する」ことを知りません。Text-to-SQLで誤ったSQLが生成される原因の多くは、この定義情報の欠落です。

整備すべきは、テーブルごとのカラム定義書です。カラム名、日本語名、データ型、取りうる値とその意味、関連テーブルを1行1カラムでまとめ、LLMへの入力に含めます。特に「売上」のように部署によって定義が異なる項目は、「税抜・返品控除後・計上日基準」など計算条件まで明記すると集計結果のずれを防げます。Excel台帳では、1シートに複数の表が混在していたり、合計行が途中に挟まっていたりする例が典型です。1シート1表の形に整えてから読み込ませてください。

生成AIのデータ前処理を成功させるポイント

手順を正しく踏んでも、進め方の設計を誤ると前処理は途中で止まります。体制・権限・運用の観点から、前処理を成果につなげるための4つのポイントを取り上げます。いずれも、PoCから本番運用へ移る段階で問題になりやすい論点です。

出力イメージを先に決めてから構造化ルールを設計する

構造化のルールは、データ側からではなく、利用者に返したい回答の形から逆算して決めるのが鉄則です。たとえば「回答の最後に規程名と条番号を表示したい」なら、条番号をメタデータとして持たせる必要があります。「部署別の件数を表で返したい」なら、部署名を正規化した上で集計できる形が必要です。出力イメージが決まらないまま構造化を始めると、後から項目の追加が発生し、全文書の再処理につながります。再処理は数百文書規模でも数日単位の手戻りになるため、最初の設計で避けたい事態です。

実務では、想定質問ごとに理想の回答例を1件ずつ書き、それを業務部門と合意してから構造化ルールに落とし込みます。回答例は10〜20件あれば十分で、作成にかかるのは1〜2日程度です。この回答例が、構造化で持たせるべき項目の一覧であり、STEP7で使う評価基準の土台にもなります。合意の場には、実際にAIを使う現場の担当者を必ず入れてください。情報システム部門だけで回答例を作ると、現場で求められる粒度とずれることが多いためです。

人による確認は影響の大きいデータに絞って組み込む

LLMやOCRによる自動処理の結果を、すべて人が確認するのは現実的ではありません。1,000文書を1件10分で確認すると約170時間、担当者1人で1か月以上かかる計算です。一方で確認をまったく入れなければ、誤った数値や条件がそのまま回答に使われます。確認の範囲を、誤回答が起きたときの影響の大きさで決めることが現実解です。費用や法令、安全に関わる情報で誤回答が起きると、業務上の損失や信頼低下に直結します。

確認対象の優先度は、情報の種類と自動処理の信頼度の2軸で決めるのが効率的です。金額・日付・法令条文・安全基準を含むチャンクと、OCRの信頼度スコアが低いチャンクを優先的に確認し、それ以外は抜き取り検査にとどめます。抜き取りの割合は全体の5〜10%を目安とし、誤りが一定率を超えた文書群だけ全件確認に切り替えるのが実務的な運用です。確認用のシートには「元テキスト」「変換結果」「判定」「修正内容」の列を設け、担当者間で基準を揃えます。

機密情報のマスキングと閲覧権限の引き継ぎを前処理段階で行う

社内文書には、個人名や電話番号、取引条件、人事評価など、閲覧範囲を限定すべき情報が含まれています。これらを外部のLLMサービスに送る前に、個人情報を記号に置き換えるマスキングを施すのが基本です。Microsoft Presidioのような検出ライブラリや、Azure AI Languageの個人情報検出機能を使えば、氏名や電話番号の多くは自動で検出できます。ただし社員番号や独自の顧客IDは標準の検出対象外のため、正規表現のルールを追加してください。

見落とされやすいのが、元のファイルに設定されていた閲覧権限の引き継ぎです。共有フォルダでは人事部だけが見られた文書も、RAGの検索対象に入れた途端、全社員が質問経由で内容を引き出せる状態になります。前処理の段階でファイルのアクセス権限をメタデータとして取り込み、検索時に利用者の権限でフィルタする設計にしておくことで、この事故を防げます。権限情報を取り込めない文書は、初期の対象から外すという判断も現実的です。

パーソナルデータと個人情報の違いとは？取り扱いの注意点をわかりやすく解説

一度きりで終わらせず更新を前提とした仕組みにする

前処理を手作業の1回限りのプロジェクトとして進めると、半年後には検索対象が古い情報だらけになります。半年で数十件の文書が改訂されるのは、規模の大きな組織では珍しくない状況です。規程の改訂、製品の追加、組織変更は日常的に起こり、そのたびに生成AIの回答はずれていきます。PoCでは高い正答率が出たのに、本番運用から半年で問い合わせ対応に使われなくなる例の多くはこのパターンです。前処理は、データが更新され続ける限り続く運用業務として位置付けるべきものです。

仕組みとしては、ストレージ上のファイル更新を検知して、該当文書だけを再処理するパイプラインを組みます。SharePointであれば、Power Automateのファイル変更トリガーが使えます。AWSではS3のイベント通知とLambdaの組み合わせが定番です。更新検知から検索インデックスへの反映までを自動化し、人の作業は変換結果の確認だけに絞ることが、運用を続けるための現実的な線引きです。あわせて月1回程度、評価用質問セットで正答率を再測定し、低下があれば原因を調べる運用も組み込みます。再処理の対象が1日数件程度であれば、処理コストは月数千円に収まることが多いです。

データ構造化・前処理でよくある失敗パターン

生成AI向けの前処理には、多くの企業が同じようにつまずく典型的な失敗があります。5つの失敗パターンについて、起きる症状、原因、回避策をあわせて解説します。自社のプロジェクトで同じ兆候が出ていないかを点検する観点として活用してください。

PDFをそのまま取り込み表の構造が崩れる

最も多い失敗が、PDFをRAGサービスの標準機能でそのまま取り込み、表の構造が崩れたまま検索対象にしてしまうケースです。症状としては、料金や条件を問う質問に対して、隣の列や別の行の数値を答える誤りが頻発します。文章中心の質問には正しく答えられるため、PoCの初期段階では問題に気付かないまま進んでしまう点が厄介です。表の比率が高い文書ほど影響は大きく、規程集の別表や価格表では誤答率が5割を超えることもあります。PoCで使う質問が文章中心に偏っていると、この問題は本番稼働後まで表面化しません。

回避策は、取り込み前に対象文書を「表を含むか」で振り分けることです。表を含む文書は表抽出に強いツールで個別に処理し、変換後の表をMarkdown形式で保存してから取り込む流れに切り替えます。振り分けは、pdfplumberで各ページの表検出数を数えるスクリプトを書けば、数百ファイル規模でも数分で終わります。評価用質問セットには、表の数値を問う質問を必ず含めておいてください。表の抽出はツールごとに得意な形式が異なるため、試験抽出で比べてから選ぶのが確実です。

固定長のチャンク分割で文脈が分断される

500文字ごとのような固定長で機械的に分割すると、条文の途中や表の途中でチャンクが切れる事態が起こります。たとえば「ただし、次の各号に該当する場合は支給しない」という例外規定が次のチャンクに回ると、検索では原則部分だけが取り出されます。その結果、AIが例外を無視した誤った回答を自信を持って返すのが典型的な症状です。規程やマニュアルのように例外条件が後段に書かれる文書ほど、この問題が深刻化しやすくなります。

回避策は、見出しや条文番号の境界で区切る構造ベースの分割に切り替えることです。1つの条文がチャンクの上限を超える場合は、条文の見出しを各チャンクの先頭に付け直してから分割します。チャンクの先頭に「第12条（出張手当）」のような見出しパスを付けるだけでも、断片の意味が失われにくくなり、検索精度が改善します。分割結果は、ランダムに20チャンク程度を抜き出し、単独で読んで意味が通るかを確認してください。

旧版と最新版が混在し矛盾した回答が返る

共有フォルダには「規程_v3_最終.docx」「規程_v3_最終_修正.docx」のように、どれが最新か分からないファイルが並んでいるのが実態です。これらをすべて検索対象に入れると、同じ質問でも旧版の内容と新版の内容が交互に返り、利用者の信頼を一気に失います。特に手当額や申請期限のように改訂で数値が変わる項目は、実害が出やすい部分です。問い合わせ窓口に「AIの回答と規程が違う」という指摘が届いて初めて発覚することも珍しくありません。

回避策は、取り込みの前に文書の所管部署へ最新版を確認し、版数と施行日をメタデータとして持たせることです。旧版を削除するのではなく「失効」のフラグを付けて検索対象から外しておけば、過去時点の規程を問う質問にも対応できます。ファイル名で版を判別する運用は崩れやすいため、文書管理システムの版管理機能か、最新版だけを置く専用フォルダを用意してください。ファイル名に依存しない版の管理方法を決めておくと、更新時の差し替えも機械的に行えます。

LLMによる構造化結果を検証せず誤抽出が混入する

LLMに文書を渡して項目抽出やQAペアの作成をさせる方法は効率的ですが、出力には一定の割合で誤りが含まれます。数値の桁を読み違える、存在しない条件を補ってしまう、複数の項目を1つにまとめてしまうといった誤りが典型です。特にOCR結果を入力に使うと、読み取り誤りとLLMの補完が重なり、誤りに気付きにくくなるのが実情です。こうした誤りは文章として自然なため、目視でざっと眺めただけでは見逃されます。検証せずに取り込むと、誤ったデータがAIの回答の根拠として使われ続けることになります。

回避策は、LLMの出力を機械的なルールで検証する工程を挟むことです。人の目に頼る確認は、件数が増えると必ず精度が落ちます。抽出した数値が元テキストに文字列として存在するかを照合するだけでも、存在しない数値の混入は大半を検出できます。JSON形式で出力させる場合は、項目の型や必須項目をスキーマで定義し、形式違反を自動で弾く仕組みも有効です。それでも残る誤りは、STEP7の評価用質問セットで検出し、該当する文書の処理ルールを見直してください。

評価指標を決めないまま改善が止まる

前処理の改善が止まるプロジェクトに共通するのは、精度を測る物差しがないことです。「前より良くなった気がする」という感覚で判断していると、チャンクサイズを変えた効果も、表の変換方法を変えた効果も比較できません。関係者の印象がばらばらなまま議論が続き、改善策を決められずに数か月が過ぎるケースも少なくない状況です。予算を承認する経営層に対しても、投資効果を説明する材料がなくなります。目標値がないため、どこまで改善すれば本番に移行してよいかも判断できません。

回避策は、プロジェクトの開始時点で評価指標と目標値を決めておくことです。社内Q&A用途なら正答率80%以上、検索の上位5件に根拠が含まれる割合90%以上を本番移行の条件にする例が一般的です。前処理の設定を1つ変えるたびに同じ質問セットで再測定し、結果を表に記録していけば、どの変更が効いたのかを後から説明できます。測定結果は、改善施策の優先順位を決める根拠にもなります。記録用の表には、変更内容、変更日、正答率、検索上位5件の的中率を並べるだけで十分です。

生成AI向けデータ構造化の活用事例

生成AI向けのデータ構造化の取り組み例を、業種・アプローチ・成果の形で3つ紹介します。特定の企業名は伏せ、成果の数値は同種の取り組みで見られる代表的な範囲で示したものです。前処理のどの工程に重点を置いたかという観点で読むと、自社への応用を検討しやすくなります。

製造業：技術文書と図面注記の構造化で設計ナレッジ検索を効率化

ある機械メーカーでは、過去の設計検討書や不具合報告書、図面の注記に散らばった設計ノウハウを、若手設計者が探し出せないことが課題でした。対象となる文書は、およそ2万件にのぼります。文書の多くはスキャンPDFで、図面の注記は画像の中にしか存在しない状態です。ベテラン設計者への問い合わせが集中し、類似不具合の調査1件に平均で半日から1日を要していました。定年退職による知見の散逸も迫り、経営層からも早期の対策が求められていた状況です。

アプローチとしては、不具合報告書を「現象」「原因」「対策」「対象部品」の項目に分解し、部品番号を正規化して図面と紐付けました。図面の注記はOCRで抽出した上で、マルチモーダルLLMで注記と部位の対応を説明文にする方式です。全文書を一度に対象とせず、問い合わせの多かった2製品群の約3,000文書に絞って始めたことが、3か月での本番稼働につながりました。稼働後の類似不具合の調査時間は、1件あたり1〜2時間程度です。ベテランへの問い合わせ件数も半減しました。

製造業のデータ分析はなぜ必要？解決できる課題やメリットなどを解説

金融・保険業：規程・約款のQAペア化で問い合わせ対応を標準化

ある保険会社のコールセンターでは、商品ごとの約款や事務規程が数百種類に及び、オペレーターが回答根拠を探すのに1件あたり数分かかっていました。繁忙期には保留中の通話が積み上がり、応答率の低下にもつながっていました。担当者によって参照する資料や解釈がばらつき、回答品質の均一化も課題です。約款は改訂が多く、販売時期によって適用される版が異なる点も、検索を難しくしていました。誤った説明は苦情や行政指導にもつながるため、正確さと根拠の提示が強く求められる領域です。

取り組みでは、約款を条項単位で分割し、商品名・版数・適用期間をメタデータとして付与しました。問い合わせ履歴の上位300件の論点についてはQAペアを作成し、各回答に根拠条項を紐付ける形です。回答画面に条項番号と版数を必ず表示する設計にしたことで、オペレーターが根拠を確認してから顧客に伝える運用が定着しました。結果として根拠検索にかかる時間は3割程度短縮され、新人の独り立ちまでの期間短縮にも効果が出ている状況です。

コールセンター：通話記録の要約・分類からFAQを自動生成

ある通信サービス企業のコールセンターでは、月に数万件の通話がありながら、FAQの更新は担当者の手作業に頼っていました。FAQは数百項目ありましたが、更新日が1年以上前の項目が半数を占めていたのが実態です。新しい問い合わせが増えてもFAQへの反映に数か月かかり、自己解決率が伸びない状態です。通話記録は文字起こしされていたものの、話者の区別がなく、要件ごとの分類もされていませんでした。オペレーターが入力する対応履歴も記述の粒度がばらばらで、そのままでは集計に使えないデータでした。

取り組みでは、話者分離を有効にして文字起こしをやり直しました。そのうえでLLMを使い、各通話を「問い合わせ要件」「原因」「解決方法」「解決可否」の項目に構造化しています。要件をカテゴリに分類して件数を集計し、件数が多いのにFAQに載っていない論点を自動で抽出する仕組みです。抽出された論点についてはLLMが回答案を作り、担当者は確認して公開するだけの役割分担にしています。この結果、FAQの更新周期は数か月から2週間程度に縮まり、自己解決率の改善にもつながりました。

まとめ：生成AIの成果はデータ構造化と前処理の設計で決まる

生成AIの回答精度は、モデルの性能以上に、渡すデータがどれだけ整っているかで決まります。構造化は前処理の一部で、抽出・整形・分割・付与の4工程を順に品質管理する作業です。これにより、誤回答の抑制、根拠提示、コスト削減、更新のしやすさという効果が得られます。進め方は、用途の定義と対象の絞り込みから始め、評価用質問セットでの検証までを1つのサイクルとして回すのが基本です。

失敗パターンの多くは、表の崩れ、文脈の分断、版の混在、誤抽出の見逃し、評価指標の不在に集約されます。いずれも前処理の設計段階で手当てできるものであり、PoCの前に対策を織り込んでおけば大半は回避可能です。着手にあたっては、次の5点を確認するところから始めてください。

• 生成AIに任せる用途を1つに絞り、想定質問を20〜30件書き出したか
• 対象文書を鮮度・利用頻度・機密度で評価し、100〜300文書に絞ったか
• 表を含む文書と含まない文書を振り分ける手順を決めたか
• 版数・施行日・閲覧権限をメタデータとして持たせる設計になっているか
• 50〜100問の評価用質問セットと本番移行の目標値を決めたか

「生成AIに向けてデータの構造化や前処理に取り組みたいけれど、何から手をつけたらいいかわからない」「生成AIとデータ整備の専門家の知見を取り入れたい」という方は、データ領域の実績豊富な弊社、データビズラボにお気軽にご相談ください。

貴社の課題や状況に合わせて、データの取り組みをご提案させていただきます。

データビズラボの実績無料相談・お見積り