問題

ベテランの判断が価値を生んでいる現場は多い。工場の異音検知、建設の地盤判断、インフラ点検の劣化予測、農業の灌水判断、窓口業務の書類審査。共通するのは3点。

判断が成果を左右している
その判断はドキュメント化されていない
判断できる人が減っている

そこで「引退する前にデータ化してAIに学習させよう」となる。ここで最初に決めるべきことが「何を集めるか」だが、ほとんどの現場がこれを設計せずに集め始める。

典型的な進行はこうなる。

センサー設置 → 1年分蓄積 → 学習 → 精度が出ない → 「何を取ればよかったのか?」

この時点で1年が消えている。データ設計は取り始める前にしかできない。取ってから直せない。

多くの現場が「成功例」を集める

「ベテランのデータを取る」と言うとき、集められるのは基本的に成功例だ。

良品の製造ログ
高品質な収穫の栽培記録
うまくいったプロジェクトの議事録

一見合理的だが、成功例だけのデータセットには決定的な欠落がある。

判断の境界が入っていない。

「温度180度で成功」というレコードを100件集めても、分かるのは「180度は安全」だけだ。170度は? 190度は? データに存在しないので学習できない。

現場で必要なのは「正解」ではなく「どこまでが正解か」である。ベテランの価値は正解を出せることではなく、許容範囲を知っていることにある。そして許容範囲の情報は、成功例の側には存在しない。

失敗と「選ばなかった選択肢」に情報がある

事例：失敗データで学習したモデルが人間を上回った

Raccuglia et al., Nature 533, 73–76 (2016)。

化学の実験は大半が失敗し、失敗は論文に載らない。研究チームは研究室のノートに眠っていた失敗した合成実験（dark reactions）を掘り起こし、それを学習データにした。

結果、未知の有機分子について反応条件を予測させたところ成功率89%。熟練研究者の直感を上回った。論文は、科学文献が失敗に対して構造的なバイアスを持っていると指摘している。

境界を学習するには、境界の両側が必要だという単純な話だ。

データ	学習できること
成功例のみ	その条件が安全であること
成功例＋失敗例	安全と危険の境界がどこか

問題1：熟練者からは失敗データが取れない

熟練者は失敗しない。したがって熟練者を観察しても失敗データは集まらない。異常検知で「正常データばかりで異常サンプルが足りない」と呼ばれる問題と同型である。

ベテランは水をやりすぎない。よって「水をやりすぎた場合」のデータは、そのベテランの圃場からは原理的に取得できない。

問題2：選ばなかった選択肢が記録に残らない

より深刻なのはこちらだ。ベテランの行動記録は、こうなる。

状況	行動	結果
葉が黄変・強風	灌水せず	良好
葉が黄変・強風	灌水せず	良好
（以下100件同じ）

同じ状況で毎回同じ判断をするため、対抗選択肢の結果が一度も観測されない。因果推論で positivity（重なり）条件の破れと呼ばれる状態で、この状態では「なぜ灌水しなかったのが正しかったのか」は原理的に推定できない。

学習できるのは行動の模倣だけであり、判断の根拠は学習されない。したがって訓練データの分布外（例：未経験の気象条件）で、モデルは根拠なく同じ行動を繰り返す。

問題3：本人が言語化できない

「では本人に聞けばよい」は、1970年代に既に検討され、壁にぶつかっている。

Feigenbaum が指摘した「知識獲得のボトルネック」。当時のエキスパートシステム開発では、

知識抽出工程が開発時間の 70〜80% を占めた
専門家は自分の知識を、利用可能な形で言語化できないことが多かった
プロジェクトの 約60% がこの工程で失敗した

半世紀経っても、この壁は解けていない。生成AIも例外ではない。入力に存在しない情報は出力できないので、「書かれていない知識」は学習データにならない。

問題4：データ品質の劣化は下流で顕在化する

Sambasivan et al., CHI 2021。高リスク領域のAI実務者53名へのインタビュー調査。論文が定義した Data Cascades は、上流のデータ品質問題が下流で複合的に増幅する現象を指す。

上流（収集時）ではセンサー位置のずれ、ラベル定義の揺れ、記録タイミングの不統一はいずれも「許容範囲」に見える。下流（精度が出ない時点）では、原因の切り分けがほぼ不可能になっている。

論文タイトルが実態を要約している。「みんなモデルの仕事をやりたがる。データの仕事はやりたがらない」。

収集設計のチェックリスト

設計フェーズ（収集開始前）

何を集めるかを、集める前に決める。 データ中心のAI（Data-centric AI）の基本。モデルを固定してデータを設計するほうが、その逆より効率がよい。そして設計は事後にできない。
「失敗」の定義を先に確定する。 定義が曖昧だと失敗データも曖昧になる。
現場担当者とデータ担当者が同席する。 「データを送ってくれればAI化します」は失敗する。送られてくるのは「取りやすかったデータ」であって「判断を左右していたデータ」ではない。

収集項目

取るもの	理由
失敗の記録	境界を決めるのは失敗側
過去の失敗（掘り起こし）	「あのときひどい目にあった」は最も情報量が多い
選ばなかった選択肢	判断根拠の同定に必須
判断（結果ではなく）	何を見て・何を考え・何を決めたか
文脈メタデータ	測定位置・時刻・測定者・機器。後から復元不能

「灌水せず」ではなく、こう記録する。

判断: 灌水を見送り
対抗案: 灌水する
非選択理由: 翌日降雨予報。葉の黄変が水不足由来ではなく日照由来と判断
反転条件: 水不足由来と判断していれば灌水していた

データセットの文書化

Datasheets for Datasets（Gebru et al.）に準じ、最低限これを添付する。

収集の動機
データセットの構成
収集プロセス
前処理の内容
保守責任者

3年後にそのデータを使う人（多くの場合、自分自身）が正しく使えるかどうかは、これで決まる。

最初に打つ手

センサー設置やシステム構築より先に、ベテランへの以下2つのヒアリングを推奨する。

「これまでで一番ひどい失敗は何ですか」 → 許容範囲の境界が出る
「今日、やろうか迷ってやめたことはありますか」 → 選ばれなかった選択肢が出る

いずれも作業日報には記載されない。そして、聞ける期間には限りがある。

まとめ

成功例のみのデータセットは、判断の境界を含まない
熟練者からは失敗データが構造的に取得できない
熟練者の行動記録には対抗選択肢が存在せず、判断根拠を推定できない
熟練者は自分の判断基準を言語化できない（半世紀前から既知の問題）
データ品質の問題は、収集時ではなく学習後に顕在化する

したがって、収集を始める前に「失敗」「対抗選択肢」「判断根拠」を取る設計を入れる。急ぐ必要はあるが、設計を省略すると集めた分がそのまま無駄になる。

参考文献

Raccuglia, P. et al. "Machine-learning-assisted materials discovery using failed experiments." Nature 533, 73–76 (2016). https://www.nature.com/articles/nature17439
Sambasivan, N. et al. "'Everyone wants to do the model work, not the data work': Data Cascades in High-Stakes AI." CHI 2021. https://doi.org/10.1145/3411764.3445518
Gebru, T. et al. "Datasheets for Datasets" (2018)
Jarrahi, M. H. et al. "The Principles of Data-Centric AI." CACM (2023). https://cacm.acm.org/research/the-principles-of-data-centric-ai/
Feigenbaum bottleneck（知識獲得のボトルネック）に関する一連の議論