LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

AIの学習データ整備・前処理とは、収集からラベル品質管理までの一連の工程

AIの学習データ整備・前処理とは、収集した生データを、モデルが学習に利用できる形式へ整える一連の作業を指します。具体的には、クレンジング・正規化・ラベル品質管理などの工程を経て仕上げる進み方です。scikit-learnの公式ドキュメントは、標準化(平均0・分散1に統一する処理)を、学習アルゴリズムの前提となる前処理の一つに位置づけています^*1。

前処理の工程は、データ収集・クレンジング・正規化・ラベル品質の確認・バージョン管理という順序で進むのが一般的です。各工程を単独で済ませるのではなく、後工程で問題が見つかった場合に前の工程へ戻れる状態を保つことが、パイプライン全体の安定運用につながります。

この工程の質は、モデルの精度だけでなく再現性にも直結します。同じデータから同じ手順で学習しても結果が揺れる場合、前処理の手順が明文化されていないことが原因になりやすいでしょう。次章からは、各工程で判断が割れやすい論点を順に整理します。

欠損・外れ値・重複——クレンジングで判断が割れる3つの論点

クレンジングとは、収集したデータに含まれる欠損値・外れ値・重複レコードといったノイズを取り除き、分析や学習に使える状態へ整える処理です。pandasの公式ガイドでは、欠損値の検出にisna・notnaメソッドを使う方法が示されています^*2。

欠損値の処理方法は一つではありません。公式ドキュメントには、欠損を含む行や列を削除するdropnaと、値を埋めるfillnaが整理されています^*2。fillnaには固定値のほか、前方補完・後方補完も指定できます^*2。

ほかに、数値を補間するinterpolateも用意されています^*2。どの方法を選ぶかは、欠損の発生理由と、削除によってデータ量が減る影響のバランスで決まります。

外れ値の扱いは、欠損値よりも判断が難しくなります。値そのものが誤りなのか、実際に発生した極端な事象なのかを見分けないまま除去すると、モデルが学習すべき本来のばらつきまで失われるおそれがあります。統計的な閾値だけで機械的に判定せず、業務知識を持つ担当者が確認する工程を挟むことが実務上有効です。

重複レコードの除去も見落とされやすい論点です。AWSのSageMaker Data Wranglerは、データを取り込んだ直後に品質を自動で検証し、異常を検出する機能を提供しています^*3。取り込み時点で重複や異常値を検出できれば、後工程での手戻りを抑えられます。近い文字列を同一対象として扱うかどうかの基準を先に決めておくと、判定のばらつきを抑えやすくなります。

正規化・標準化・名寄せ——スケールと表記のばらつきを統一する

正規化・標準化とは、特徴量間のスケール(数値の範囲や単位)のばらつきをそろえる処理です。scikit-learnは、標準化・スケーリング・正規化それぞれに対応するクラスを公式ドキュメントで公開しています^*1。代表的な手法を整理すると、次の表の通りです。

どの手法を選ぶかは、データの分布や後続で使うアルゴリズムの特性によって変わってきます。外れ値が残っている場合はロバストスケーリングが向いていますが、事前のクレンジング工程で明らかな異常値を取り除いておくことが前提になります^*1。

名寄せ(表記や識別子が異なる同一の対象を、同じレコードとして統合する処理)も、正規化と並んで欠かせない工程です。企業名の全角・半角表記や、旧システムと新システムで異なるIDが混在していると、同一顧客のデータが別レコードとして扱われ、学習データの精度を損ないます。名寄せのルールをあらかじめ定義し、処理を自動化できる仕組みを整えておくことが望まれます。

ラベル品質とデータ拡張——モデル精度を左右する仕上げ工程

教師あり学習では、データにアノテーション(正解ラベルを付与する作業)を挟む工程があります。ラベルの付け方が担当者によってばらつくと、モデルは矛盾した基準を学習してしまいます。ラベル品質の管理は、前処理全体の中でも精度への影響が大きい工程です。

ラベリング自体の設計・運用は専門性の高い独立した論点であり、本稿では前処理全体の一部として位置づけて扱います。ラベルの基準書を作成し、複数人でラベル付けした結果の一致率を確認する工程を設けると、基準のばらつきを早期に発見しやすくなります。

ラベルの粒度(分類するクラスの数や境界の定義)も、精度を左右する論点です。カテゴリの定義があいまいなまま作業を始めると、担当者ごとにラベル付けの結果が割れやすくなります。着手前に定義を固め、判断が難しい事例集をあらかじめ整理しておくと、後工程での手戻りを抑えられます。

データ拡張(既存データに変換を加えて学習データを増やす手法)は、収集できるデータ量が限られる場合に検討される手法です。ただし拡張によって生成したデータが、実際の業務データの分布から外れてしまうと、モデルが実運用で想定と異なる挙動を示す原因になります。拡張の要否は、データ不足の程度と業務要件を踏まえて判断する必要があります。

リーク防止・個人情報・権利——前処理段階で潰すべき3つのリスク

データリークとは、本来モデルが学習時点で知り得ない情報が、前処理の段階で紛れ込んでしまう状態です。学習用データと評価用データを分割する前に、全体を対象にスケーリングの基準値を計算すると、評価用データの情報が学習側に漏れてしまいます。その結果、精度を実際より高く見誤る原因になりかねません。分割してから前処理の基準を計算する順序を徹底する必要があるでしょう。

個人情報の扱いも前処理段階で詰めておくべき論点です。個人情報保護委員会の「個人情報の保護に関する法律についてのガイドラインに関するQ&A」Q1-8は、学習済みパラメーター(重み係数)の扱いを示しています^*4。複数人の個人情報を学習用データセットに用いて生成したパラメーターであっても、特定の個人との対応関係が排斥されている場合があります^*4。

その場合に限り、「個人に関する情報」には該当しないとされています^*4。裏を返せば、対応関係が残ったままのデータセットや中間生成物は、個人情報として扱う前提で管理する必要があります。

権利面では、収集したデータの利用許諾や著作権の扱いも論点になります。データの出所によって利用条件は異なるため、前処理に着手する前に、データの調達元・利用範囲・保持期間を法務部門と確認しておくことが望まれます。

データバージョン管理と再現性——パイプラインをやり直せる状態にする

前処理をやり直せる状態に保つには、データそのものの版管理が欠かせません。DVC(Data Version Control。Gitと同じ発想でデータの版を管理するオープンソースツール)は、データの実体をリモートストレージに置き、その参照情報だけをGitで追跡する仕組みを採用しています^*5。

この仕組みにより、特定時点のデータ版を後から正確に復元できます^*5。前処理のコードだけでなく、入力データの版も一緒に記録しておかないと、数か月後に同じ結果を再現できなくなるおそれがあります。

Azure Machine Learningでは、データアセットという仕組みで長いストレージパスを覚える代わりに、分かりやすい名前でデータを参照できます^*6。データアセットの作成時にはメタデータのコピーも保持されるため、参照元のデータが移動・変更されても、その時点の状態を追跡しやすくなります^*6。

クラウドサービスのツールを使うか自前のGit運用で済ませるかは、チームの規模や既存のインフラ次第です。データ量が少なく担当者も限られる段階では、簡易な運用で足りる場合もあります。一方でデータ量が増え、複数人・複数チームで前処理を継続する段階になると、版管理の仕組みを最初から組み込んでおく必要があるでしょう。後から手順を整えようとすると、負荷が大きくなりがちです。いずれの方法でも、前処理の手順とデータの版をセットで管理する発想は共通しています。

内製と外注の分かれ目——データ整備の工数と体制で判断する

学習データ整備・前処理を内製で担うには、複数領域の知識が要ります。データ操作の実装スキル(pandasやSQLでのクレンジング・集計)や、統計的な外れ値判定の考え方が必要です。個人情報保護法に関する知識も欠かせません。加えて、前処理パイプラインを継続運用するための基盤運用の経験が求められます。

これらを一人の担当者だけで担おうとすると、データ量が増えた際に処理が追いつかなくなりやすくなります。前処理の手順が個人の暗黙知に依存したまま運用が続くと、担当者が異動・退職した際に再現できなくなるリスクも生じます。

専門パートナーに委託する場合と内製で対応する場合の違いは、パイプラインの継続運用体制にあります。外部委託では、データ品質の監視・版管理・個人情報の取り扱いルールまでを含めて一括で依頼できるかどうかが選定の分かれ目になります。内製では、これらを社内の既存体制と並行して整備する必要があり、立ち上げまでの負荷が大きくなりがちです。

。対象データの種類・量・個人情報の有無によって、必要な体制は変わってきます。現状のデータ整備状況を診断したうえで、内製・外注の切り分けを検討することが実務的です。

まとめ：AI学習データ整備・前処理で押さえる3つの判断軸

本稿ではAIの学習データ整備・前処理について、収集からバージョン管理までの流れを公式情報をもとに整理しました。要点は3つに集約できます。第一に、クレンジング・正規化・ラベル品質の管理は、それぞれ判断が割れやすい論点を持ち、手順を明文化しておく必要があります^*1*2。第二に、データリークと個人情報の扱いは、前処理段階で仕組みとして防ぐべきリスクです^*4。第三に、データとコードの版を一体で管理できる体制があるかどうかが、内製と外注を判断する材料になります^*5*6。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：scikit-learn developers「6.3. Preprocessing data」（scikit-learn User Guide）（https://scikit-learn.org/stable/modules/preprocessing.html）
2. *2　出典：pandas「Working with missing data」（pandas User Guide）（https://pandas.pydata.org/docs/user_guide/missing_data.html）
3. *3　出典：AWS「Prepare ML Data with Amazon SageMaker Data Wrangler」（Amazon SageMaker Developer Guide）（https://docs.aws.amazon.com/sagemaker/latest/dg/data-wrangler.html）
4. *4　出典：個人情報保護委員会「『個人情報の保護に関する法律についてのガイドライン』に関するQ&A」（Q1-8）（https://www.ppc.go.jp/personalinfo/faq/APPI_QA/）
5. *5　出典：DVC「Get Started」（DVC Documentation）（https://dvc.org/doc/start）
6. *6　出典：Microsoft「Data concepts in Azure Machine Learning」（Microsoft Learn）（https://learn.microsoft.com/en-us/azure/machine-learning/concept-data）

Tweet