サイレントデータ事故 — AI導入前に洗い出すべき「静かな不良データ」の見つけ方

こんにちは。フライウィールの吉野です。今回は、私たちが製造業のお客様のデータを構造化する中で繰り返し遭遇する「サイレントデータ事故」——音もなく起きて、症状も出ず、誰にも気づかれないまま何年も生き続ける不良データ——について、その代表的なパターンと、AI導入前に洗い出すための手順をお届けします。

先にお断りしておくと、これは「データ管理がずさんな会社の話」ではありません。後述する事故のほとんどは、エクスポート処理や書式の仕様といったシステムの継ぎ目で機械的に発生するもので、現場の誰かの落ち度ではないのです。そして、きちんと運用されている会社のデータにも、ほぼ例外なく眠っています。

ある事故の顛末

まず、実際にあった事例からご紹介します。

※本稿は、特定の顧客事例ではなく、私たちが複数のデータ構造化プロジェクトで繰り返し遭遇した同種の事象を一般化・抽象化して記述したものです。

製造業のお客様のトラブル記録(基幹システムからエクスポートされたCSV)を処理していたところ、私たちのシステムがある行から先のデータに次々とフラグを立て始めました。確認すると、「原因」欄に日付が並んでいます。その行から先は、処置欄に原因が、対策欄に処置が——すべての列が一つずつ横にズレていました。

原因は、エクスポート元のある行にヘッダー名のない空列が紛れ込み、変換処理がそれを詰めてしまっていたこと。それだけです。しかしこのズレは、私たちが検出するまで、誰にも気づかれた形跡がありませんでした。

なぜ気づかれないのか。ズレた値が「もっともらしい」からです。原因欄に「!!ERROR!!」と書いてあれば誰でも気づきます。しかし日付は、実在する正しい日付です。ただ座席を一つ間違えているだけ。そして現場の方々は普段、見やすい元の帳票を見て仕事をしており、エクスポートされたCSVは「記録として保存しておくもの」——つまり、誰も読まないデータの中では、事故は何年でも静かに生き続けられます。

問題は、AI導入がまさにこの「誰も読まなかったデータ」を全部読むところから始まる、という点です。過去10年分の記録を検索AIに食わせた瞬間、眠っていた事故は一斉に起き出します。AIは律儀なので、原因欄にあるものを原因として学び、もっともらしく答えてしまいます。

サイレントデータ事故・代表的な5パターン

列ズレは氷山の一角です。私たちが実データで繰り返し遭遇する事故を、代表的な5つに整理します。

1. 列ズレ

名無しの空列、途中で増減した列、区切り文字の混入などにより、ある行から先の値がすべて隣の列に移る。値そのものは正常に見えるため、最も発見が遅れやすい事故です。

2. 文字化け・化け文字

文字コードの変換ミスや、PDF内のフォント参照切れにより、文字が別の記号や似た別の文字に置き換わる。厄介なのは、全文が壊れるのではなく一部の文字だけが静かに別の文字になるケースで、見た目は読めてしまうことすらあります。

3. テキスト層の欠落

「CADで作った図面PDFだからテキストが取れる」と思われていたファイルが、実際にはテキスト層ゼロの完全な画像だった、というパターン。ファイルは開けるし人間は読めるので、AIが読めないことは処理して初めて発覚します。

4. 表記ゆれの静かな増殖

同じ設備が「1号機」「#1」「一号ライン」と記録され、同じ不良が担当者ごとに違う言葉で分類されている。個々の記録は正しいのに、集計と検索が壊れているという意味で、これも立派な事故です。

5. 構造の崩壊

Excelのマージセル、色だけで意味を持たせたセル、欄外の手書きメモ。人間の目には整った帳票が、機械には構造の壊れた表として見えている状態です。

共通点は一つで、どれも人間が普段の業務で読む分には支障がないこと。だから症状が出ず、健診も受けず、AIが読む日まで発見されません。

洗い出しの手順 — 派手な推論の前に、地味な検査

ではAI導入前に、これらをどう洗い出すか。私たちが実務で使っている考え方を、手順として簡略化してご紹介します。

Step 1: 「誰も読んでいないデータ」を特定する

人が日常的に目を通しているデータは、実は比較的安全です。危険なのは、システム間連携やエクスポートで機械的に生成され、保存されるだけのデータ。AI導入で読ませる予定のデータのうち、「最後に人間が通読したのはいつか」を問うてみてください。答えが「分からない」なら、そこが検査対象です。

Step 2: 型と値域の機械検査をかける

各列に「入るはずの値の種類」を定義し、機械的に照合します。日付列に日付以外が入っていないか、逆に文章列に日付が連続していないか。選択式のはずの分類列に、定義外の値が何種類あるか。この検査は賢いAIを必要としません。表計算ソフトのフィルタでも最初の一歩は踏み出せます。

Step 3: 「読めるはず」を実際に読んで確かめる

PDFはテキスト層の有無を機械的に判定し、抽出したテキストに文字化けの兆候(不自然な記号、部首だけの文字など)がないかを確認します。ポイントは、ファイルが開けることと機械が読めることは別問題だ、と認識を改めることです。

Step 4: 検出した事故を「直す前に、数える」

見つけた事故はすぐ直したくなりますが、まず件数と分布を記録してください。どのデータソースの、どの期間に、どの種類の事故が集中しているか。この分布が、AI導入計画の優先順位と、修復にかかる工数見積もりの根拠になります。修復そのものは、AIに読ませる範囲から段階的に進めれば十分です。

まとめ: 「うちのデータは大丈夫」の根拠はあるか

この記事の教訓を一つだけ挙げるなら、「うちのデータは大丈夫」の根拠を持っている会社はほとんどない、ということに尽きます。大丈夫かどうかは、誰かが読んで初めて分かります。そして読むのは、現場の信頼を賭けた本番のAIである必要はありません。導入前の、静かな検査で十分なのです。

フライウィールでは、貴社の実データ(トラブル票・図面・マニュアル)に眠るサイレントデータ事故を機械検査で洗い出し、種類別の件数・分布と「今のAIがどこまで正しく読めるか」までを数値化する AI-Ready化トライアル（クイック診断） をご提供しています。列ズレは、探せば見つかります。

本記事に関連する情報や、AI活用・データ利活用に役立つ最新トピックはメールマガジンでも配信しています。
[メルマガ登録はこちら]