AI > データ設計の再考 on M1KE BL0G

機械学習におけるデータセットの分割の再考

Sat, 05 Sep 2026 12:00:00 +0900

背景

機械学習では、データをTrain・Validation・Testの3つに分けるのが定石とされている
Trainでモデルを学習し、ValidationでハイパーパラメータやEarly Stoppingを決め、最後にTestで未知データに対する性能を測るという構造
しかし実際にシステムを開発していると、この3分割だけでは説明できない問題にぶつかることがある
特に「Testで失敗している理由を知りたいが、Testを見て改善した瞬間、そのTestはもはやTestではなくなる」という問題がある
ここでは、Train・Val・Testという古典的な3分割に、Diagを加えたメインsplitと、Challengeのようなサブsplitを加えて整理する

メインsplitとサブsplit

splitには2つの種類があると整理できる。

メインsplit: Train・Val・Diag・Test。いずれも「何らかの分布を代表する」ことが目的で、共通のデータプールからのholdout・stratified split、または独立したソースからのサンプリングという形で作られる。スコープや汎化性能そのものを定義・推定するためのsplit
サブsplit: Challengeのように、診断・分析という前段のステップを経て、事後的に目的を絞って作るsplit。メインsplitと違い、分布を代表する必要がない

まとめると、以下のようになる。

Dataset / Split	主目的	開発者が見るか	分布の代表性	分類
Train	Parameter Learning	Yes	必要	メイン
Val	Model Selection	Yes	必要	メイン
Diag	Error Analysis	Yes	必要	メイン
Test	Final Generalization Estimate	No	必要	メイン
Challenge	Failure-mode / Capability Evaluation	Yes	不要	サブ
処方箋split	弱点の直接修正	Yes	不要	サブ
err split	エラーの回帰テスト	Yes	不要	サブ

重要なのは「データを機械的に何分割せよ」という数の話ではなく、それぞれの役割・分類を分離すること
サブsplitはChallenge以外にも2種類ある

処方箋split

Diagやエラーアナリシスで見つかった特定の弱点（hard case・OOD・クラス境界の混同など）を、直接修正するために作るデータ
機械学習におけるクラスとラベルの再考のhard case mining手法（shifted positive・adversarial negatives・Truncated Negative・Hidden Negativeなど）や、境界専用データセットの作り方がそのまま使える
作った処方箋splitはTrainに戻し、次のTrain・Val・Diagサイクルで効果を確認する

err split

エラーアナリシスで見つかった実際のエラー事例そのものを、固定化して保存しておくデータ
同じ間違いが再発していないかを継続的に確認する回帰テストとして使う
機械学習におけるデータ品質QAの再考で触れた「過去に見つかったデータバグを回帰テストとして固定化する」という考え方と同じ

Train・Valの役割

Train（学習データセット）

モデルのパラメータを学習するためのデータ。以下の式で表される、学習データ上での損失を最小化するパラメータ$\theta^*$を求めるために使う。

$$ \theta^* = \arg\min_\theta \hat{R}_{\text{train}}(\theta) $$

Validation（検証データセット）

モデルそのものではなく、学習方法を選択するためのデータ。

Learning Rate
モデルサイズ
正則化係数
Data Augmentation
Early Stopping
モデルアーキテクチャ

これらを選ぶために使う。つまりValidationも、広い意味では学習プロセスの一部といえる。

train, valの違い

train data：重み更新に使う
validation data：学習中のモデル選択、early stopping、ハイパーパラメータ調整に使う

Train分布と本番分布が違うという問題

古典的なTrain・Val・Testの説明には、以下のような暗黙の仮定がある。

$$ P_{\text{train}} \approx P_{\text{val}} \approx P_{\text{test}} \approx P_{\text{deployment}} $$

しかし、実運用ではこの仮定は頻繁に崩れる。

TrainはWeb画像だが、本番はスマートフォン画像
Trainは過去のユーザーだが、本番は将来のユーザー
Trainはある病院のデータだが、本番は別の病院
Trainはある国のデータだが、本番は別地域
Train時とDeployment時で商品の構成が変わる

WILDSベンチマークは、病院・撮影場所・時間・地域など、実世界で自然に発生するDistribution Shiftによって、In-distribution性能とOut-of-distribution性能の間に大きな差が生じることを示している。つまり、以下の不等式で表される状況は例外ではなく、実世界ではかなり普通に起きる。

$$ P_{\text{source}} \neq P_{\text{target}} $$

Diagの役割

ここで自然な解決策として、Source側だけでなくTarget側も分割するという発想が出てくる。

Source側: Train、Val
Target側: Diag、Test

という構造になる。DiagはTarget distributionを理解するためのデータで、開発者が見てよい。サンプルを直接確認し、以下のような分析をする。

Failure Mode
Slice別性能
分布差
ラベル問題
Spurious Correlation

Diagから得られた知見は、Trainへ戻して改善に使う。

Diagで特に重要なのは、意図的にOODなサンプルも含めておくこと。

Trainがカバーしようとしているスコープ内のサンプルだけでなく、そのスコープの外（OOD）にあたるサンプルもDiagに混ぜておく
こうすることで、単に「今のスコープ内でどれだけ性能が出ているか」だけでなく、「スコープの境界がどこにあり、境界を越えるとどう性能が崩れるか」を観察できる
つまりDiagは、Target distributionの理解に加えて、スコープの境界そのものに対する試験という役割も持つ

ValとDiagの違い

一見するとValとDiagは同じものに見え、実際に多くの文献ではValidation Setと開発用データセットがほぼ同義語として使われる。ここではあえて分離して考える。

Val: どのモデルを選ぶかを決めるためのデータ
Diag: なぜ本番で失敗するのかを理解するためのデータ

例えば、Val AccuracyでModel Aが91.2%、Model Bが92.1%ならModel Bを選ぶ。これがModel Selection。一方Diagでは、「Model Bは平均では良いが、夜間画像ではModel Aより悪い」といった分析をする。これがError Analysis。つまり、ValとDiagは役割が異なる。

Diagだけでも足りない理由

平均的なDiag performanceだけでは、モデルが持っている重要な弱点を発見できないことがある。

例えば自動運転モデルで、全体のAccuracyが99.5%だったとする
夜間・豪雨・逆光・工事現場・子どもの飛び出しといった状況だけで極端に性能が低ければ、実運用では重大な問題になる
しかし、これらが通常データの0.1%しか存在しなければ、平均Accuracyではほとんど見えない

そこで必要になるのがChallenge Set。

Testの役割

Target distributionから採取するが、最後までBlindにするデータ。最終的に、「Diagを見ながら作った開発プロセスが、別のTargetサンプルにもGeneralizeしたか」を確認する。つまり、Train→Val→Diag→Error Analysis→Trainという改善ループと、Model→Blind Testという最終評価を分離する構造になる。

Testを見て意思決定してはいけないという原則が重要
Testを見ながらモデルを改善すると、モデルの重みを直接学習していなくても、開発者自身がTestに適応してしまう
結果として、Testへの「開発プロセス全体の過学習」が起きる

Testのパラドックス

例えば、最終Testで性能が大きく低下したとする。Val Accuracyが94%なのに、Test Accuracyが72%だったとすると、開発者は当然「なぜ22ポイントも落ちたのか」を知りたくなる。そこでTestデータを見ると、以下のようなことが分かる。

暗い画像で失敗している
特定の端末だけ性能が低い
特定カテゴリのRecallが悪い
Trainに存在しない背景が多い

これがError Analysis。この分析結果を元に、暗所画像をTrainに追加する、Augmentationを変更する、ラベル設計を変更する、モデル構造を変更する、といった改善を行う。

しかし、この瞬間に問題が起きる。

Testから得られた情報でモデルを改善した以上、そのTestはもう完全なBlind Testではない
形式的にモデルパラメータへTestを入力していなくても、Test→人間→モデル設計という情報経路が成立している
つまりTestは、実質的に開発用データセットになってしまう

なぜ問題なのか: 条件付き確率になってしまう

この問題を、もう少し形式的に表すと分かりやすい。本来知りたいのは、モデル$f$のデプロイ分布上での汎化性能である。

$$ R_{\text{true}}(f) = \mathbb{E}_{(x,y)\sim P_{\text{deployment}}}\left[\ell(f(x), y)\right] $$

Testでの性能$\hat{R}_{\text{test}}(f)$がこの$R_{\text{true}}(f)$の妥当な推定値になるのは、$f$が$D_{\text{test}}$と独立している場合に限る。

ところが、Testを覗いて開発プロセス（モデル構造・データ・ハイパーパラメータなど）を調整すると、$f$は$D_{\text{test}}$の関数になってしまう
このとき実際に測っているのは、以下のような、その特定の$D_{\text{test}}$に条件付けられた量になる

$$ \mathbb{E}\left[\ell(f(D_{\text{test}})(x), y) \mid (x,y) \in D_{\text{test}}\right] $$

これは、知りたかった無条件の汎化性能$R_{\text{true}}(f)$とは別物で、その一回限りのTestサンプルに対して有利になるよう調整された、条件付きの当てはまりの良さに過ぎない
カンニングが問題なのは、倫理的な話である以上に、推定量として何を測っているかが変わってしまうという統計的な理由による

Testも多角的に評価する

Testは一度きり・Blindという性質上、1回の測定・1つの指標に全てを委ねるのはリスクが高い
単一のTestセット・単一のしきい値・単一の指標だけで「汎化した」と判断すると、そのTestセットの偏りやしきい値の選び方自体が結論を左右してしまう
そのため、Testそのものも複数の観点から評価するべき
- 複数種類のTestセットを用意する（外部データソース由来・grade別など）。機械学習におけるクラスとラベルの再考の「holdoutだけに頼らない」を参照
- 複数のしきい値・複数の指標（ROC-AUCとPR-AUCなど）で評価する。分布外データの対処方法の評価セクションを参照
ここでの「複数」は、Testを何度も覗いて調整するという意味ではない点に注意。あらかじめ複数のTest・複数の評価軸を用意しておき、それぞれ一度だけBlindに測定するという話であり、Testのパラドックスとは矛盾しない

Challengeの役割

Challenge Setは、通常のTestとは目的が違う。Testは、以下のようにdeployment分布を代表することを目指す。

$$ P_{\text{test}} \approx P_{\text{deployment}} $$

一方Challengeは、必ずしもDeployment distributionを代表しなくてよい。むしろ意図的に難しいケースを集める。目的が違うため、以下のように分布が一致していなくても構わない。

$$ P_{\text{challenge}} \neq P_{\text{deployment}} $$

Challengeの目的は、平均性能を推定することではなく、特定の能力・弱点を診断すること。

ImageNet-Aのような研究はこの発想の典型例
通常のImageNetとは異なり、既存モデルが失敗しやすい自然画像を意図的に集めることで、平均的なテストセットでは見えにくいモデルの弱点を明らかにする
Challengeは1つである必要もなく、Failure Modeごとに複数持ってもよい
- Challenge（低照度）
- Challenge（レアクラス）
- Challenge（OOD）
- Challenge（ロングテール）

ChallengeとDiagの違い

Diagは、Target distributionをなるべく代表する。一方Challengeは、意図的に分布を歪める。

例えば本番データで、通常画像98%・夜間1%・豪雨0.5%・逆光0.5%だったとする
Diagではこの比率をある程度維持する
しかしChallengeでは、夜間33%・豪雨33%・逆光34%のように歪めてもよい

なぜならChallengeはPopulation Performanceではなく、Capabilityを測っているため。

SourceとTargetによる分類

以下のような定義になる。

Train・Val:
- Source distributionからサンプリング
Diag・Test:
- Target distributionからサンプリング（Diagは見てよい、Testは見てはいけない）
Challenge:
- Target（デプロイ環境）に関連するが、意図的に分布を歪めて集める
- 「独立」というより「Target寄りだが非代表的」という位置づけ

本質はInformation Boundary

ここで一番重要なのは、Train・Val・Diag・Challenge・Testという名前ではない。

本質は、どの評価情報を開発プロセスへフィードバックしてよいのかというInformation Boundary
モデル開発は、Data->Metric->Human->Decision->Modelというループで進む
そのため、「モデルのWeight Optimizerに渡していないからTest leakageではない」とは限らない
人間がTest結果を見てArchitectureを変更すれば、それも立派な情報伝達になる
したがって評価セットは、まず開発に利用してよいデータと、開発から完全に隔離するデータに分ける必要がある
その上で開発側を、Parameter Learning・Model Selection・Error Analysisに分けると、メインsplitであるTrain・Val・Diagが生まれる
さらにCapability Analysisのように事後的に目的を絞る分析からは、サブsplitであるChallengeが生まれる
最後にBlind Testを置く、という構造になる

既存研究との関係

ここで整理したメインsplit・サブsplitという構造そのものが、機械学習の標準規格として確立されているわけではなかった
むしろ、既存研究で別々に議論されてきた問題を、1つの開発フローとして整理したものと考える方が正確

先行研究のTopics:

分布シフト（WILDS）
- Koh et al.のWILDSは、現実世界ではTraining distributionとDeploymentに近いTest distributionが異なることを明示的に扱っている
- 病院、地域、時刻、カメラなどによる実世界のDistribution Shiftをベンチマーク化しており、Source/Targetを分けて考える必要性を示している
Target performanceの推定（Mandoline）
- Chen et al.のMandolineは、SourceとTargetの分布差を、実務者が定義したSliceを利用してTarget上の性能推定に利用する
- 「Target distributionを単一のAccuracyだけではなく、その構造を見ながら評価する」という、Diag的な発想に近い
分布シフトに対するStress Test
- Subbaswamy et al.は、単一の評価分布で平均性能を見るだけでなく、分布を変化させた際のモデルのRobustness・Stabilityを評価する枠組みを提案している
- Challenge SetやStress Testingの考え方と接続する
Challenge Set（ImageNet-A）
- Hendrycks et al.のImageNet-Aは、既存モデルが失敗しやすい自然画像を意図的に集めることで、通常のTest Accuracyでは見えにくい弱点を評価した、Challenge evaluationの分かりやすい例
Testから学習してしまう問題
- Hernández-Orallo et al.は、AI evaluationを単一のAggregate Metricに潰すことの問題を指摘している
- つまり、SystemとProblemの組み合わせに対するより詳細な評価情報を利用する考え方を議論している
- タイトル自体が「Training on the Test Set」であり、評価データからどこまで情報を抽出してよいかという問題を正面から扱っている

サンプルが持つ属性（クラス・Positive/Negativeなど）をどう区分・管理するかについては、機械学習におけるクラスとラベルの再考で詳しく扱っている。

まとめ

機械学習ではTrain・Val・Testの3分割が基本とされているが、実運用では学習分布と本番分布が一致しないことが珍しくない
Testで性能が低下した理由を知るにはTarget側のデータを観察する必要があるが、Testを観察して改善に利用すると、そのTestはもはや完全なTestではなくなる
Train・Val・Diag・Testは分布を代表するメインsplitであり、Challenge・処方箋split・err splitは診断や分析を経て事後的に作るサブsplitであり、分布を代表する必要がない
- Train: モデルを学習する（メイン）
- Val: モデルを選択する（メイン）
- Diag: 本番分布での失敗を理解する診断データセット（メイン）
- Test: 最後までBlindにして最終性能を測る（メイン）
- Challenge: 重要なFailure Modeを集中的に診断する（サブ）
Source側からTrainとVal、TargetからTest、それと独立したDiagとChallenge
スコープという軸で見ると、Trainはスコープ内、Diagはスコープ内外の境界、Testはスコープを問わない未知のサンプルという整理もできる
Testを覗いて開発プロセスを調整すると、測っている量が無条件の汎化性能から、その特定のTestサンプルに条件付けられた量にすり替わってしまう
単一のTest・単一の指標に頼るとその偏りに結論が左右されるため、あらかじめ複数のTest・複数の評価軸を用意し、それぞれ一度だけBlindに測定するのがよい
これはデータ分割のテクニックというより、機械学習開発における情報の流れを設計する問題
本当に守りたいのは、モデル改善に使った情報と最終評価に使う情報を分離すること

参考文献

WILDS: A Benchmark of in-the-Wild Distribution Shifts（Koh et al., ICML 2021）
Mandoline: Model Evaluation under Distribution Shift（Chen et al., ICML 2021）
Evaluating Model Robustness and Stability to Dataset Shift（Subbaswamy et al., AISTATS 2021）
Natural Adversarial Examples（Hendrycks et al., CVPR 2021, ImageNet-A）
Training on the Test Set: Mapping the System-Problem Space in AI（Hernández-Orallo et al., AAAI 2022）
The Effect of Natural Distribution Shift on Question Answering Models（Miller et al., ICML 2020）

機械学習におけるデータとデータソースの再考

Sat, 05 Sep 2026 12:00:00 +0900

背景

機械学習におけるデータセットの分割の再考で、Train・Val・Diag・Testというメインsplitと、Challengeのようなサブsplitにデータを整理した
今回は、それぞれのsplitを担うデータを実際にどう作るか、という作成方法の観点から再整理する
特に、どれを自動生成してよく、どれを手動で作るべきか、そしてその理由を明確にする
ここではデータそのもの（データソース・収集方法・品質）を扱う。タクソノミー・クラス設計・ラベルの信頼度といった、ラベル・クラス側の設計は機械学習におけるクラスとラベルの再考で扱う

前回のおさらい: メインsplitとサブsplit

Dataset / Split	主目的	開発者が見るか	分類
Train	Parameter Learning	Yes	メイン
Val	Model Selection	Yes	メイン
Diag	Error Analysis	Yes	メイン
Test	Final Generalization Estimate	No	メイン
Challenge	Failure-mode / Capability Evaluation	Yes	サブ

Train・Valの作り方

自動生成してよい

Trainは自動生成（合成データ生成など）で作ってよい
Trainは「モデルに学習させたい範囲＝スコープ」を定義するデータであり、生成プロセス自体がそのままスコープの定義になる
生成プロセスをコントロールできるからこそ、狙った分布・狙ったカバレッジのデータを効率よく用意できる

データソースの多様性

「自動生成」といっても、その元になるデータをどこから集めるかには、いくつか毛色の異なるアプローチがある。

辞書などの硬いデータソース: 辞書・法令・規格表のような、構造が明確で信頼性の高いデータソース。カバレッジや多様性には限界があるが、ラベルの正確さは高い
関連するデータソース（間接的な転用）: 本来別の目的で作られたデータが、副産物として目的のラベル・構造を含んでいることがある。本来の作成目的とは別の切り口でデータを転用する発想
ネットからのキュレーション: Web上の大量のテキスト・画像などから、パターンマッチングやフィルタリングで目的のデータを抽出する。スケールは出しやすい一方、ノイズが多く、前述のデータクレンジングが特に重要になる

これらは互いに独立したソースになりやすいという利点もある。複数のアプローチでTrainを集めておくと、データの多様性が増すだけでなく、前述の「トレイン系と診断系で元データソースを分ける」という要求にも応えやすくなる。

具体的な収集アイデアの実例は、G2Pライブラリを作る時に調査した先行文献などのメモのデータ収集のアイデアで詳しくまとめている。

収集時の実践

データを集める段階そのものにも、気をつけるべき実践がいくつかある。

PositiveだけでなくNegativeも意図して集める: Negativeの収集を疎かにすると、実運用でどんな入力が来るか分からないままモデルを評価することになる。特にhard negativeやOODになりうる入力は、Positiveと同じくらい丁寧に設計して集めるべき
- Positiveがa・b・cという特徴を持っていて本当はaだけを学習させたい場合、b・cは持つがaは持たないNegativeがないと、モデルが間違った特徴を学習してしまう（例: 音声からある単語を学習させたかったのに、Negativeが不足していたため単語ではなく話者の喋り方を学習してしまった、というケース）
中間データも保存する: 最終的に使う加工済みデータだけでなく、加工前の中間データも保存しておく。後から加工方法自体を見直したくなった時に、収集からやり直さずに済む
ダブルチェックをする: ラベル付けや収集作業は、1人だけでなく複数人でダブルチェックする。特にAIやクラウドソーシングで生成・収集したデータは、人の目でのダブルチェックが必須

ホールドアウトでTrain/Valに分ける

生成したデータプールを、ホールドアウトでTrainとValに分割する
つまりTrainとValは、どちらも同じ生成プロセスに由来する「スコープ内（in-scope）」のデータという位置づけになる
Valはモデル選択に使うため、Trainと同じ分布から取れていれば十分で、独立性の要求はDiag・Testほど厳しくない
分割の際は、元データのクラス比率（経験的な事前確率$P(Y)$）をなるべく維持したstratified splitで行う
例えば元データがA:70%, B:20%, C:10%なら、Train/Val/Testもそれぞれ概ね70/20/10になるように分割する

Diagの作り方

自動生成を避け、手動で作る

Diagは基本的に自動生成を避け、人手で作ることが望ましい
理由は、統計的な優位性（有意性）を主張するために、サンプルの独立性が必要だから
Trainと同じ生成プロセス（同じモデル・同じテンプレート・同じ乱数源など）でDiagも自動生成すると、TrainとDiagのサンプルが統計的に独立でなくなる
独立性が崩れると、Diagで良い結果が出たとしても、それが本当の汎化性能なのか、単に生成プロセスの癖への過学習を反映しているだけなのかを区別できなくなる
少ないサンプルサイズでも意味のある信頼区間を持たせるには、まずサンプル同士の独立性という前提を満たしておく必要がある

$$ \hat{p} = \frac{x}{n} $$

上記のような単純な比率推定であっても、信頼区間の妥当性は$n$個のサンプルが独立であることを前提にしている
独立性が崩れていると、見かけの$n$より実質的な情報量は少なく、信頼区間は実態より狭く（楽観的に）出てしまう

スコープ内・スコープ外・OODを含める

Diagには、in-scopeのデータだけでなく、out-of-scopeのデータ、そしてOOD（Out-of-Distribution）のデータも意図的に含める
理由は、モデルの能力の幅を測れるようにするため
in-scopeのデータだけでは「スコープ内でどれだけうまくいっているか」しか分からず、スコープの境界がどこにあり、境界を越えるとどう崩れるかが見えない
スコープ内・スコープ外・OODを横断的に含めることで、Diag1つで「境界の内側の性能」と「境界そのものの位置」の両方を診断できる

Testの作り方

外部データソースをなるべく使う

評価データセット（Test）は、基本的に外部のデータソースをなるべく利用する
理由は、自分でデータを生成すると、事前確率（prior）が変わってしまうから
自分の生成プロセスには、無意識のうちにクラス比率・パターンの偏りが入り込みやすく、その偏った事前確率のもとで測った性能は、現実の事前確率のもとでの性能とズレる
外部のデータソースを使うことで、こうした自己言及的な偏りを避け、より現実の事前確率に近い状態で評価できる
さらに一歩進めて、自前データを一切混ぜず、出来合いの公開データセットのみ100%でテストセットを作るという手もある。生成過程が完全に独立したデータで評価できるため、自前データの収集過程に共通する癖への過学習を検知しやすくなる
- これは精度を追求する本番用ではなく、あくまで評価のための物差しとして使う位置づけ
- 他人の作ったデータセットや手法を再現しようとすると、特徴量の計算方法など自分では気づかなかった変えられる点が色々見つかるため、学びや改善幅も大きい

エラーアナリシス禁止

評価データセットに対するエラーアナリシスは禁止
集計されたスコア以外の目的で、中身を見ること自体も禁止
これは前回の記事で扱った「Testを覗いた瞬間、測っている量が無条件の汎化性能から、そのTestに条件付けられた量にすり替わる」という問題への対策そのもの

データソースの分離

トレイン系と診断系は元データソースを分ける

データセットを作る際、元となる生データソース自体を、トレインデータ系（Train・Val）と診断データセット（Diag）とで必ず分ける
同じ生データプールからランダムに分割するだけでは、独立性の担保として不十分になりうる
完全に別のデータソース（別の収集経路、別の収集時期、別の生成方法など）を用意することで、より確実な独立性を担保する
Testについても同様に、Train・Valはもちろん、Diagとも別のソースであることが望ましい

データの量

サンプル数そのものが必要

seedを固定して実験がべき等に実行でき、2回同じ実験をして全く同じ結果が返ってきたとしても、サンプルサイズは別問題として必要
サンプル数が極端に少ないと、実験の比較としては再現できても、実際にはドメインシフトが起きている可能性を検知できない
評価データは結局は注ぎ足し継ぎ足しで増やしていくものなので、最終的には数そのものが重要になる
経験則として、1クラスあたりのサンプルサイズが50以下のholdoutでは、統計的に優位な数値が出ないことが多い
学習時にべき等であっても、評価時にべき等とは限らないため、評価方法自体にも注意が必要

相対的な量にも注意する

クラス間の相対的なサンプル量にも注意が必要
例えば、AクラスとBクラスがある評価データで、Bクラスのデータ（holdoutも含む）だけを増やすと、全体の指標がBクラス過多の影響を受けてしまう
ミクロ指標（全体の精度）はBクラスに引っ張られ、平等な精度の指標ではなくなる
Aクラスは相対的に量が少なくなり、学習側の注力もBクラスに大きく振られている可能性が出てくる
つまり、もともと学習できていたAクラスの特徴を、モデル容量不足のために上書きしてしまっている可能性がある
この場合、モグラたたき的にデータを直すのではなく、モデル容量の不足自体を疑うべき
データ量を増やす際は、モデルのパラメータも合わせて増やす必要がないかを検討する
精度を報告する際も、1教科で90点なのか10教科で90点なのかで意味が全く違うように、分母（サンプルサイズ・クラス数）を必ず加味する

学習曲線分析でデータ量を判断する

「データを増やすべきか、それともモデルを変えるべきか」を判断する古典的な手法として、学習曲線分析（Learning Curve Analysis）がある
横軸に訓練データのサンプル数、縦軸にTrain誤差とVal誤差を取り、サンプル数を段階的に増やしながらそれぞれを記録してプロットする
曲線の形から、次の2パターンを見分けられる
- Train誤差・Val誤差がどちらも高く、両者が近い値に収束している場合: High Bias（underfitting）。データを増やしても誤差はほとんど下がらないため、データ収集よりモデルの表現力を上げる方が効く
- Train誤差は低いがVal誤差が高く、両者に大きな差がある場合: High Variance（overfitting）。この場合はデータを増やす、または正則化を強めることで差が縮まりやすい
つまり、データを追加する前に、まず小規模なサンプルサイズでこの学習曲線を描き、追加データが本当に効くパターンかどうかを確認しておくと、無駄なデータ収集を避けられる
これは前述の「相対的な量にも注意する」で触れた、モデル容量の不足を疑うべきケース（High Bias側）と、単純にデータが足りないケース（High Variance側）を、事前に切り分けるための手法とも言える

データ品質QA

ここまでの役割分担・独立性の設計を正しく行っても、データそのものにバグがあれば意味がない。何よりも大切なのは、データの品質QAである。最小構成でのミニテスト、バグの発見方法、パイプラインのテスト、重複除去などは、機械学習におけるデータ品質QAの再考で独立して扱う。

まとめ

Train・Valは自動生成でよく、同じ生成プロセスからstratified splitでホールドアウトして分割する、スコープ内のデータ
データソースには、辞書などの硬いデータソース・関連するデータソースの転用・ネットからのキュレーションという毛色の異なるアプローチがあり、複数使うことで多様性とソース分離の両方に貢献する
Diagは自動生成を避け、独立性を保つために手動で作る。さらにin-scope・out-of-scope・OODを横断的に含めることで、能力の境界そのものを診断できるようにする
Testはなるべく外部データソースを使い、事前確率のズレを避ける。エラーアナリシスや中身の閲覧は禁止
元データソース自体を、トレイン系と診断系で分けておくことが、統計的な独立性を担保する土台になる
サンプル数は絶対量（1クラスあたり最低限の目安）と相対量（クラス間バランス）の両方に注意し、精度を報告する際は分母を必ず加味する
データを増やす前に、小規模サンプルで学習曲線分析（Train/Val誤差 vs サンプル数）を描き、High Bias（モデルを変えるべき）かHigh Variance（データを増やすべき）かを切り分けるとよい
役割分担・独立性を正しく設計しても、データ自体にバグがあれば意味が無い。品質QAの具体的な方法は機械学習におけるデータ品質QAの再考で扱う
タクソノミー・クラス設計・Grade・ラベルの信頼度（Gold/Silver）といった、ラベル・クラス側の設計は機械学習におけるクラスとラベルの再考で扱う

参考文献

機械学習におけるデータ品質QAの再考

Sat, 05 Sep 2026 12:00:00 +0900

背景

機械学習におけるデータとデータソースの再考でTrain・Val・Diag・Testの役割分担や独立性の設計を扱ったが、その設計を正しく行っても、データそのものにバグがあれば意味がない
データ品質QAはそれ単体で1つのテーマとして扱うだけの重みがあるため、この記事として独立させる

データ品質の6つの次元

DMBOK2（データマネジメント知識体系第2版）では、データ品質を以下の6つの独立した次元で評価する。

次元	英語	定義	チェック例
正確性	Accuracy	データが現実の実体や事実を正しく表しているか	住所が実際の郵便番号・都道府県と一致しているか
完全性	Completeness	必要なデータが欠損なく揃っているか	顧客レコードの必須項目（氏名・メール・電話）が空欄でないか
一貫性	Consistency	複数のデータソース間・同一テーブル内で矛盾がないか	CRMと基幹システムで同一顧客の名称表記が一致しているか
適時性	Timeliness	データが必要なタイミングで最新の状態にあるか	在庫数が当日の出荷・入荷を反映しているか
有効性	Validity	データが定義されたドメイン・フォーマット・ルールに従っているか	メールアドレスが「@」を含む正規形式であるか
一意性	Uniqueness	重複したレコードが存在しないか	同一顧客が2件登録されていないか

正確性と有効性は紛らわしいが、問うている対象が違う。正確性は「現実との一致」、有効性は「定義（フォーマット・ルール）との一致」を問う
例えば、存在しない郵便番号を入力した場合、フォーマットとしては正しい（有効性はOK）が、現実の郵便番号ではない（正確性はNG）、という食い違いが起こりうる

品質管理の4フェーズ

品質問題への対応は、プロファイリング→検出・分類→修正→検証という4つのフェーズで回す。

フェーズ1: プロファイリング

現状把握として、データの統計分析を行う
列プロファイリング（データ型・NULL率の確認）、パターン分析、関係プロファイリング、重複分析などを行い、データ品質の現状レポートを作る
本記事のデータビュアーを作る・そもそもデータセットの確認を先にするが、このフェーズに相当する

フェーズ2: 検出・分類

プロファイリング結果をもとに、品質問題を上記の6次元で分類する
各問題の影響度（ビジネス・モデル性能への影響）と件数を掛け合わせて、対応の優先度を決定する

品質問題の種類	対応する次元	例
欠損値・NULL	完全性	必須の電話番号が空欄
形式エラー	有効性	「2026/13/01」のような不正日付
範囲逸脱	有効性・正確性	年齢が「-5」や「200」
重複レコード	一意性	同一顧客が2件登録されている
システム間の不整合	一貫性	CRMと請求システムで住所が異なる
更新遅延	適時性	退職者情報がシステムに残存
現実との乖離	正確性	引越し後も旧住所のまま

本記事のデータのバグを発見するためのコード・既知パターンはフィルター、未知パターンはランダムサンプリングが、このフェーズに相当する
内部矛盾スキャン（find_label_conflicts）は一貫性、重複除去は一意性、スキーマ検証は有効性の検出に対応する

フェーズ3: 修正

欠損値補完、形式標準化、重複レコードの名寄せ、参照データとの照合、削除などを行う
修正前のバックアップ取得は必須。一括訂正は効率が良い一方、本来正しかったケースまで巻き込んで壊すリスクがあるため、修正範囲は慎重に見極める

フェーズ4: 検証

修正後、品質基準を達成しているかを再チェックする
一度きりの検証で終わらせず、継続的なモニタリングパイプラインを構築するのが理想
本記事のデータパイプラインのテストコードの回帰テスト・盲検サンプリングとWilson信頼区間による定期監視が、このフェーズに相当する

品質チェックの基本動作

最小構成でのミニテスト

数百万パターンにもなるような大きな予測対象を扱う場合、いきなり全件で学習・評価するのではなく、まず1件だけを使ってデータ生成・学習・テストを一通り試すのも有効
パイプライン全体（データ生成→学習→推論）を最小構成で一度通してみて、勘所を掴むのが目的
1件だけの学習すら成功しない（lossが下がりきらない）なら、パターン数を増やす前にやり方自体を疑うべき
逆に1件で学習できるなら、そのまま件数を横展開していけばよい
機械学習分野では一般に「overfit a single batch」と呼ばれる、学習パイプラインのsanity checkの定番手法

データビュアーを作る

seedデータのデータビュアーは作っておくとよい
大量データの品質チェックを高速化するのが目的で、データが多くなるほどチェックの負担が大きくなるため、ビュアーの有無で作業効率が大きく変わる

そもそもデータセットの確認を先にする

ゴミを入れたらゴミが出るだけなので、モデル改善の前にまずデータそのものをチェックするべき
Trainデータが一部間違っていた結果、精度が出ていないだけという初歩的なミスもある
そもそも分母のデータは正常か、評価のサンプルサイズは足りているか、エラーの例は妥当かをチェックしたうえで、モデルのパラメータを増やすなどの改善フローに入るべき
特にAIによって生成されたデータは、確実にチェックが必要
可視化した結果、現実的に高精度な分類が厳しいと分かることもある。その場合は、モデルを大きくする以外に、前提の制約自体を変えて境界線がはっきり出るように要件とデータセットを見直すという選択肢もある

バグの発見方法

データのバグを発見するためのコード

内部矛盾スキャン: 同じ入力に対して異なるラベルが記録されているケースを機械的に全件抽出し、その組だけをレビューする。ランダムサンプリングよりずっと高い効率で誤りを見つけられる

1
2
3
4
5
6
7
8
9


def find_label_conflicts(dataset):
 seen = {}
 conflicts = []
 for sample in dataset:
 key = sample["input"]
 if key in seen and seen[key] != sample["label"]:
 conflicts.append((key, seen[key], sample["label"]))
 seen[key] = sample["label"]
 return conflicts

スキーマ検証: 必須フィールドの欠落・型の不一致・値域の逸脱などを機械的にチェックする
統計的な外れ値検出: 文字数・トークン数・クラス比率などの分布を可視化し、極端な外れ値を確認する

既知パターンはフィルター、未知パターンはランダムサンプリング

問題を発見する方法は、大きく2つに分かれる

1
2


既知パターン（過去に見つかったバグの型など） → フィルター・シグネチャスキャンで全件検出
未知パターン（まだ気づいていない種類の問題） → ランダムサンプリングで無作為に見つける

フィルターは、既に分かっている不具合の型に一致するものを漏れなく拾うのが得意だが、そもそも想定していないパターンの不具合は検出できない
ランダムサンプリングは、未知のパターンに気づける可能性がある一方、件数を絞ると見逃しも多く、網羅性では劣る
どちらか一方では不十分で、両方を役割分担として使い分ける必要がある。詳しくはフリガナデータをクレンジングする時に直した項目のメモでも扱っている
ランダムサンプリングで見つかった未知パターンは、原因を特定した時点で「既知パターン」に変わる。そうなれば、次はフィルターの側に組み込み、以降は全件検出できるようにする
つまり、ランダムサンプリングで見つけた不具合を、フィルターとして恒久化し、さらに後述のパイプラインの修正・回帰テストへ反映するというサイクルが、データ品質QAの基本的な回し方になる

層化監査抽出（Stratified Audit Sampling）

会計・監査分野で使われる統計手法で、母集団を層（strata）に分け、層ごとに個別のサンプル抽出・信頼区間の推定を行う
これは、データ品質QAにも同じ考え方を適用できる
例えば、Filter v1のような分類関数群でデータをGold/Silverに層化し、さらにSilverの内側をサブ区分に層化する、という階層的な層分けを行う
構成比の集計: 全体のうちGoldが何%、Silverが何%か、さらにSilverの内側で、サブ区分Aが何%、Bが何%か、という階層的な比率を集計する
層ごとの信頼度の推定: 全体で1つの信頼区間を出すのではなく、各層から独立にサンプリングし、その層の分類自体がどれくらい正しいかを、層ごとに別々の信頼区間として推定する

$$ \hat{p}_{\text{層}} = \frac{x_{\text{層}}}{n_{\text{層}}} $$

層ごとに精度が大きく違う場合（例えばGoldは99%正しいが、Silverのサブ区分Bは70%しか正しくない、など）、全体を混ぜた1つの信頼区間ではこの差が見えなくなる。前述の「既知パターンはフィルター、未知パターンはランダムサンプリング」で触れた通り、量の多い層に埋もれて、量の少ない層の汚染を見落とすのと同じ構造
層ごとに分けることで、どの層（どのフィルターのルール）が実際には信頼できないかを特定でき、改善の優先順位（影響度×件数）をつけやすくなる

修正とその反映

データパイプラインのテストコード

データを生成・変換するパイプライン自体にもバグが入り込むため、通常のソフトウェアと同様にテストが必要
過去に見つかったデータバグは、回帰テストとして固定化しておく

1
2
3
4


def test_known_bug_regression():
 # 過去に発見された特定の変換バグの再発を防ぐ
 result = normalize(raw_input)
 assert result == expected_output

盲検サンプリングとWilson信頼区間を使い、パイプライン適用後のデータのエラー率を定期的に監視する

$$ \hat{p} = \frac{x}{n}, \qquad \text{95\%CIはサンプル数}n\text{が小さいほど広くなる} $$

重複除去（Dedupe）

データセットは基本的に複数のデータソースから集めることが多く、その過程で同じサンプルが重複して混入する可能性がある
重複データは単なる水増しになるだけでなく、見かけ上のサンプルサイズを実態以上に大きく見せ、独立性の前提も崩してしまう
重複チェックには、少なくとも以下の軸がある
- 元データ・データソース間の重複: 複数の生データソースをマージする際、同じサンプルが重複して入り込むのを防ぐ
- 単一データセット内の重複: 同じサンプルがTrainなどの中で複数回カウントされていないか
- データセット間の重複: 元データソースを分ける設計をしていても、実際にTrain・Val・Diag・Test間で重複が混入していないかを機械的に確認する

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


def find_duplicates(dataset):
 seen = {}
 duplicates = []
 for sample in dataset:
 key = hash(sample["input"])
 if key in seen:
 duplicates.append((seen[key], sample["id"]))
 else:
 seen[key] = sample["id"]
 return duplicates

完全一致だけでなく、表記ゆれなどによる「ほぼ重複」も見逃しやすいため、正規化してから比較する、あるいは類似度ベースの重複検出も併用するとよい

データクレンジング

実際に遭遇したデータクレンジングの具体的な問題・方法論は、別記事フリガナデータをクレンジングする時に直した項目のメモで詳しくまとめている
大きく分けると、文字・表記レベル、読み表記レベル、意味・文脈レベル、分割・アライメントレベル、ソース・アノテーション品質レベル、分布・統計レベル、実装・インフラレベルという複数のレベルで問題が起こりうる
個別のバグ分類以上に汎用性が高いのは、盲検サンプリング・独立クロスチェック・ノイズフロアの計測といった、データを直す際の方法論そのもの

まとめ

データ品質は、正確性・完全性・一貫性・適時性・有効性・一意性という6つの独立した次元で評価できる。正確性（現実との一致）と有効性（定義との一致）は特に混同しやすい
品質問題への対応は、プロファイリング（現状把握）→検出・分類（6次元への分類と優先度づけ）→修正（補完・標準化・名寄せ）→検証（再チェックと継続的モニタリング）という4フェーズのサイクルで回す
役割分担・独立性を正しく設計しても、データ自体にバグがあれば意味がない。最小構成でのミニテストやデータビュアーなど、品質チェックの基本動作から始め、まずデータそのものを確認する
問題を発見する方法は、既知パターンに対するフィルター・シグネチャスキャンと、未知パターンに対するランダムサンプリングという役割分担で使い分ける
ランダムサンプリングで見つけた不具合は、原因が分かればフィルターとして恒久化し、パイプラインの回帰テストへ反映するというサイクルが、品質QAの基本的な回し方
層化監査抽出を使うと、Gold/Silverやそのサブ区分といった層ごとに、構成比と分類自体の信頼度を別々の信頼区間として推定でき、全体を混ぜた1つの指標では見えない層ごとの汚染を検出できる
複数のデータソースから集める以上、重複データの混入は避けられないため、データセット内・データセット間の両方で重複チェックが必要

参考文献

機械学習におけるクラスとラベルの再考

Sat, 05 Sep 2026 12:00:00 +0900

背景

分布外データの対処方法や機械学習におけるデータとデータソースの再考では、データそのものの収集・分割・品質管理という観点を扱った
分類タスクには、それとは別に「クラス・ラベルそのものをどう設計・管理するか」という固有の問題がある
クラスの境界をどこに引くか、似ているクラス同士をどう切り分けるか、負例をどう定義するか、ラベルの信頼度をどう管理するかによって、同じデータ量でも学習・評価の質が大きく変わる
今回は、このクラス・ラベル設計という観点から再整理する

クラス設計の原則

完全性と無矛盾性

データセットが間違っていれば、モデルも間違える。では、不完全性のない完璧なデータセットは作れるのか。

完全性: 不可能。入力空間は無限であり、網羅はできない。現実的なユースケースを定義し、目標とするスコープを絞るしかない
無矛盾性: 可能。タクソノミーを定義し、運用でカバーすることで、無矛盾なデータセットを作ることはできる

これはゲーデルの不完全性定理に近い構図で、完全性と無矛盾性の両方を同時に満たすことはできないが、無矛盾性だけであれば設計次第で達成できるという整理になる。ただし、ソリテスパラドックスのように、境界の定義自体には曖昧さが残ることには注意する。

seedとタクソノミーというデータ仮説

seedとは、データを収録・生成・収集する上で基本となるデータの設計書
Data-Centric AIの観点では、seedがデータの分解能の基本であり、実験における最も重要な仮説になる
人間が対象世界をどの粒度・軸・関係性で分解するかという「データ仮説」を設計することが、知識空間（Knowledge Space）からデータ空間（Data Space）への射影規則を決めることに相当する
この仮説を先に言語化したものがタクソノミーであり、タクソノミーを先に定義してからデータを集めることで、無矛盾性を担保しやすくなる
タクソノミーに漏れがあると、学習・評価どちらでもカバーできない領域が生まれ、それがOODの一因にもなる
ただし、実験計画法の要因実験のように、軸・粒度をすべてマニュアルで組み合わせて定義しようとすると、組み合わせ爆発でパターン数が破綻しやすい
そのため、全パターンを人手で列挙するのではなく、実データから頻出パターンを抽出してタクソノミーを組み立てる方が現実的
例
- 文字レベルで扱う場合は、先にタクソノミーを定義してから分類する
- 音声データの場合は、音声学（Phonetics）のIPA（国際音声記号）をベースにデータの定義を行う
- 難しい課題では、失敗を見越してgrade（難易度）の定義をあらかじめ行う
- クラスが二値分類でも、あえてnegativeを多クラス化し、エラーパターンごとに学習させる
- 難しいクラスにはsubclassを定義してMECEに列挙する
- 精度が上がらないサブクラスには、対となるDyadのpairを作って対照学習する
これが仮説となり、人によるデータレベルのinductive biasになる

タクソノミーとサブデータセットによる分割統治

困難は分割せよ、ではないが、サブデータセットを作って対処するのも有効
サブデータセットは「grade（難易度）× クラス数」のように定義し、それぞれにタクソノミーとdefinitionを与える
大量の矛盾するデータよりも、少量の無矛盾なデータを作るイメージ
特に、意味の近いクラス同士を分類するinner-class classificationのようなケースで有効
実務上は、gradeでフォルダを切り、クラスでフォルダを切り、その中でさらにタクソノミーを分析してseedを生成するという流れになる

小さな範囲での学習可能性テスト

データセットが無矛盾かつ完全であれば、gradeの低いものは学習できるはずである
最初に作ったseedデータをベースに、データ生成やaugmentationをする前に、素の状態でまずテストするとよい
小さく試して、どのgradeまで学習できるかを確認してから拡張する方が安全
精度が上がらない原因はモデルの容量や学習データの量ではなく、学習データそのものが矛盾していることも多い
ただし、小さく多様性のない範囲での実験になるため、そのまま汎化性能を保証するとは言えない
基本を確認してから応用を学習させるという考え方

Gradeによる難易度設計

なぜGradeが有効か: 最小条件での分離可能性の検査

Gradeを設計する最大の利点は、「最小の条件でタスクが本当に解けるか」を検査できること
直感的には、grade1（最も易しい設定）は当然解けるはず、と思い込みやすい
しかし、論理的に最低かつ最小の条件（それ以上削れない、必要最小限の情報だけを残した条件）では、実はクラスの分離が難しいことがある
理由は、grade2以降で加わる文脈・特徴量が、実は意図せずクラスの分離を助けていた可能性があるから
例えば「太郎」という単語の検出タスクで、grade1を「音声的な文脈を一切含まない、最短の音素列だけ」と定義したとする
- この最小条件では、「太郎」の音素列が、別の単語の一部分（例えば別の名前の頭部分）と酷似しており、論理的に区別できない場合がある
- grade3・grade4で加える文脈情報（前後の音・イントネーションなど）があって初めて分離できていたのだとすれば、grade1で解けないのは当然であり、モデルの性能不足ではない
つまりgrade1が解けないという結果は、モデルの問題ではなく、タスクの定義・クラス設計そのものに問題があることを示すシグナルになる
これは小さな範囲での学習可能性テストで触れた「精度が上がらない原因は、学習データそのものが矛盾していることも多い」という話と直結し、grade1の失敗を「タクソノミー自体を見直すべきサイン」として使える

評価用データをgrade別に用意する

Diag・Challengeのような評価用データは、難易度別に複数用意するとよい
たとえTrainにデータを追加しても、それが基礎能力に悪影響を及ぼしている可能性もある
そのため、学校の学年のように6段階程度でgrade別のholdoutデータセットを用意し、評価するとよい
「grade1は通っているから、その使い方に限定する」といった逃げ道を作れるようにする意味もある
例えば、paraphraseやreasonを付けたもの、否定形を混ぜたものはgradeを1段上げる、といった基準を決めておく
- paraphraseの例: 同義語への置き換え、受動態と能動態の変換、品詞の変更、文の統合・分割

グレード別のラダー表を作る

gradeの基準を頭の中だけで管理せず、ラダー表（各gradeで何が加わるかを1段ずつ積み上げた表）として明文化しておくとよい
例えば、「明日の天気を教えて」という問い合わせを起点にすると、以下のようなラダー表になる

Grade	加わる変換	例
Grade1	なし（素のケース）	明日の天気を教えて
Grade2	同義語への置き換え	明日の気象を教えて
Grade3	受動態・能動態の変換や語順の変化	明日の天気について教えてほしい
Grade4	否定形の混入	明日雨が降らないか教えて
Grade5	文の統合・分割、複数意図の混在	明日の天気と、傘が必要か教えて
Grade6	上記の複合	雨が降らなければ、明日の予定はどうなる？

各gradeは前段のgradeに対して「1段だけ変換を加える」ように設計し、どこで精度が崩れたかを1段単位で特定できるようにする
このラダー表があると、「Grade3までは安定して動く」のように、開発者以外にもスコープの限界を説明しやすくなる
gradeによる精度の精緻化で触れた「GradeXまでは80%で解ける」という報告も、このラダー表があって初めて意味を持つ

holdoutだけに頼らない

holdout・heldoutだけでは、学習ができたこと以外の証明にならない
そのため、difficultケースや、生成プロセスから全く別に作ったデータをベースにした評価も併用するべき
つまり、複数種類のDiag・Testを用意しておくのがよい

gradeによる精度の精緻化

仮にグレードを作っていないと、学習がうまくイカない場合は、低スコアになってしまう
その場合は使えないモデルを作ったということで、採用されなくなる
他方、グレードを作った場合は、GradeXまでは80%で解けるのようにスコアがよく見える
これは仮にうまくいかなかった時に、逃げ道としてどこまでは行けるかを明示する事ができる
gradeXで80%までは行けるなら、次のグレードからアンサンブルにしようなどのような考え方も可能
すなわち、Gradeやスコープは有用ということ

スコープの選び方: バギーとリライアブル

Gradeを積む・積まないという選択は、結局「スコープをどこまで広げるか」という選択に帰着する。ここには2つの極がある。

アプローチ	意味	特徴
なんでもできる（バギー）	スコープを最初から広げ、全gradeを一気に狙う	対応範囲は理想的だが、Edge Caseが爆発的に増え、完全性・無矛盾性を確保できず不安定になりやすい
少しはできる（リライアブル）	スコープを絞り、狭いgradeだけを確実に狙う	対応範囲は狭いが、無矛盾性を保ちやすく、安定して動く

「なんでもできる」は理想的な最終形ではあるが、そこへ直接到達しようとするのは修羅の道になりやすい
スコープが広いほど、クラス設計の原則で触れた無矛盾性の担保が難しくなり、バグや矛盾したデータが混入する余地も増える
そのため、まずは狭いスコープ（低いgrade）でリライアブルに動くものを確立し、小さな範囲での学習可能性テストのように段階的にgradeを上げてスコープを広げていく方が、結果的に「なんでもできる」に近づく近道になる

クラスの幾何学的デザイン（Geometric Class Design）

クラスの定義を絞る

精度が低いクラスに対して、データ量を増やして曖昧な境界を学習させるのではなく、クラス自体の範囲を狭める方法も有効
クラスの判定対象を狭め、クラス間の境界が太くなるようにモデルを設計する
国土を広げて（データを増やして）国境線の太さ（クラスの境界の太さ）を確保するより、国土自体を小さくして境界を太くするという考え方
もちろん、モデルの性能自体が原因の場合もある

コアとサーフェス

分類する空間は、大きく2種類に分けて考えられる。

コア: 意味軸。人間が定義したseedで作成するか、実データをサンプリングして得る
サーフェス: 表現軸。AIによってseedからaugmentationする（パラフレーズの生成など）

例えば文字ベースの分類では、あるクラスを決定する特徴的な属性を属性1、次点で優位な属性を属性2とし、これらの軸を掛け合わせてタクソノミーを作り、データをsubcat（サブカテゴリー）で分類する。クラス内の特徴を抽出してサンプルを生成するレシピを網羅することで、クラスの幾何学的な領域を設計できるようになる。

inner-classとinter-classでの一貫性

意味の近いクラスを分類する場合は、ラベルの矛盾が発生しやすい
AというクラスとBというクラスのそれぞれのサンプルの中で、教師信号が一貫していないケースがある
そのため、クラス間で矛盾がないかのチェックが必要
そうでないと、モデルが安易な結論に陥りやすくなる

中間クラスの必要性

クラスAとクラスBの境界を狭め、境界専用データセットを用意するのは有効な対処法だが、それでも解決しないケースがある
例えば、NoneクラスとReadクラス（知識を要すると判断した場合に割り当てるクラス）があるとする。多くのサンプルは迷わず振り分けられるが、一定数、両者を継続的に取り違えるサンプルが残ることがある
こうした取り違えは、アノテーションのミスや境界の甘さではなく、AとBの設計そのものに原因があることがある
AとBは本来「どちらか一方（OR）」という排他的な関係として設計されているはずだが、実際にはAとBの性質を両方あわせ持つ、ANDの領域のサンプルが存在している、ということ
これは2×2の中に潜む部分と全体の構造で触れた、非排他的な領域を無理に排他的な区分に押し込めようとする問題と同じ構造
AND領域のサンプルを無理にAかBかに押し込めようとすると、どちらのクラスの境界も歪み、inner-class・inter-classの一貫性が崩れ続ける
対処法は、無理に既存のクラスへ押し込めるのではなく、そのAND領域専用の中間クラスを新設すること
例えるなら、どちらの国にも属さない集団を無理にどちらかの国籍に割り当てるのではなく、独立した居場所を用意して保護するようなもの
中間クラスを作ることで、AとBそれぞれの境界は再びクリーンなOR（排他的）の関係に戻り、無矛盾性を回復できる
中間クラス自体も、Noneクラスと同様に1つのメタクラスとして扱い、必要であればさらにサブクラス化できないかを検討する

離散ラベルかマルチラベルか

AND領域を持つサンプルへの対処は、中間クラスを新設する以外にも、そもそものラベルの表現方法を変えるという選択肢がある
離散値（single-label）: 各サンプルに1つだけラベルを割り当てる方式。モデル側はsoftmax・多クラス分類として学習し、クラス同士が真に排他的（OR関係）である前提に立つ
マルチラベル（logit形式）: クラスごとに独立した0/1の値を持たせ、複数のクラスが同時に成立してよいとする方式。モデル側はクラスごとに独立したsigmoid出力・二値分類として学習する
AND領域のサンプルがある場合、中間クラスを新設する（クラスの数を増やして排他性を保つ）代わりに、そのサンプルにAとBの両方のラベルを立てる（そもそも排他性を前提にしない）という対処もできる
どちらを選ぶかは、AとBの共起が意味的に自然かどうかによる
- 共起が例外的・境界的なものであれば、中間クラスとして明示的に切り出す方が、タクソノミーの見通しが良くなる
- 共起が本質的に珍しくない（多くのサンプルがAとBを両方持ちうる）なら、最初からマルチラベルとして設計する方が自然
中間的な手法として、0/1の代わりに確率値（0.7、0.3など）を持たせるソフトラベル・ラベルスムージングもある。ラベルの信頼度: GoldとSilverで触れたラベルの確信度を、ラベル自体の値に埋め込む手段としても使える

境界専用データセットを作る

クラスの範囲を狭めて境界を太くしても、間違いは起こりうる
特に、物理的に意味が近い複数のクラスがある場合、その境界は間違いやすい
そのため、クラスの際（きわ）専用のデータセットを作るのが有効
例えば12クラス分類の場合、2つを選ぶ組み合わせは

$$ \binom{12}{2} = 66 $$

通りあり、境界の両側にそれぞれデータを用意する必要があるため

$$ 66 \times 2 = 132 $$

通りが、原理的には必要な境界クラス用データの数になる

境界データセットのためのクラスの選び方

66通りすべてを対象にするのは大変なので、ターゲットを絞った方がよい
混同行列から誤爆ランキングを出し、優先度の高い境界を判断する方法がある
他の指標との相関を見て判断する方法も考えられるが、同じデータを使った相関係数はトートロジーになるため注意が必要

Hard Caseの作り方

注意点

特徴の変化のかけ方によって、有益にも有害にもなるため注意が必要
例えば画像系では、特徴の一部を0でマスクして消す手法がよく使われる
同じ手法を音のデータに適用すると、うまくいかないことが多い
理由は、音の場合はマスクによる不自然さそのものを学習してしまうから
そのため、単調なマスクだけでなく、ノイズによるマスクなど複数の手法を試す必要がある

shifted positive

例えば「太郎」を対象にする場合、最低でも「〜太郎」「〜太郎〜」「太郎〜」の3パターンを作れる
時系列的なずらしによってpositiveケースを増やす例で、データのかさ増しにも使える

adversarial negatives

いわゆるhard negativeの一種
例えば「太郎」に対して、音的に似ている「tara」や「soro」のような、一部を変更した特徴量をnegativeとして用意する
意図的に似た音のケースを増やす例

Truncated Negative

Positiveケースの一部を含むデータを、あえてNegativeとして用意する手法
例えば「太郎」という名前を分類したい場合、前半の「〜太」と後半の「郎〜」を、それぞれTruncated Negativeとして用意できる
全体を学習させたいが、部分だけで安易に分類させたくない場合に有効
部分切り出しによってデータ自体も増えるため、かさ増しにも有効

Hidden Negative

画像のFine-grained Classificationなどでは、特徴をマスクで隠して学習させる手法が有効とされている
Hard NegativeをPositiveケースの一部を隠して作る手法
特徴的な部分をベースに学習が進んでしまうのを避け、あえて大局的な特徴を隠すことで、局所特徴を学習させる
こちらもデータのかさ増しに有効

組み合わせ数を数える

上記のpositive/negativeのパターンは、特徴量の要素ごとにさらに増やせる
例えば「たろう」を対象にHidden Negativeを適用する場合、3文字なので3要素（A・B・C）とすると、正解はABCのみになる
計算すると、Hidden Negativeだけでも次のパターンが考えられる

$$ \binom{3}{2} + \binom{3}{1} + \binom{3}{0} = 3 + 3 + 1 = 7 $$

2つ選ぶ: AB・AC・BC（3通り）
1つ選ぶ: A・B・C（3通り）
0個選ぶ: 選ばない（1通り）
つまり、順番と要素が固定であれば、7パターンのHidden Negativeを作れる

メタクラス

メタクラスとは、個々の意味クラス（何であるかを表すクラス）とは異なる階層で、データセット全体の構造上の役割を担うクラスのこと
代表的なものに、None（負例メタクラス）・OOD（分布外であることを示すクラス）・Impossible（そもそも分類が不可能であることを示すクラス）の3種類がある
OODについては分布外データの対処方法で扱っているため、ここではNoneとImpossibleを、メタクラスという共通の観点から整理する

Noneメタクラス

Noneは、既知のどの意味クラスにも当てはまらないサンプルを受け止める、負例用のメタクラス
個々の意味クラスと同じ階層に並べるのではなく、全体を覆うメタクラスとして位置づけることで、Noneの1-Recallが実質的なFPRに対応するなど、通常のクラスとは異なる評価軸を持つことが明確になる
具体的な設計・評価方法は、次のNoneクラス（負例クラス）を追加するで詳しく扱う
このNoneメタクラスの設計は、哲学のtruthmaker理論における否定的事実の問題と同じ構造を持つ。詳しくはTruthmaker理論と機械学習におけるNoneクラス設計で扱っている

Impossibleクラス

与えられた入力そのものから、原理的に分類が不可能であることを示すためのメタクラス
Noneが「既知のどのクラスにも当てはまらない」という分類結果を表すのに対し、Impossibleは「そもそも判断材料が足りない・入力が壊れている」という入力の状態についての判断であり、役割が異なる
- None: 意味のある入力に対して、既知のpositiveクラスのいずれでもないと判定した結果
- Impossible: 音声が途中で切れている、画像が全面ノイズで判別不能、テキストが文字化けしているなど、そもそも人間が見ても判断できない入力
NoneとImpossibleを混同すると、Noneクラスの中に「本来は分類不能なだけのサンプル」が紛れ込み、Noneクラスの一貫性が崩れる
Impossibleを明示的なメタクラスとして切り出しておくことで、モデルの性能低下の原因が「クラス設計の問題」なのか「そもそも判断不能な壊れた入力が混ざっているだけ」なのかを切り分けられる
特に評価データにImpossibleサンプルが混ざっていると、モデル本来の性能を過小評価してしまうため、事前にImpossibleクラスとして分離しておく価値がある
Impossibleかどうかの判定自体の難しさに注意する。「判断できないことを判断する」タスクになるため、人手でのダブルチェックが必要になりやすい

Noneクラス・Negationクラスの設計

Noneクラス（負例クラス）を追加する

低い確信度を単純に棄却するだけでなく、明示的なNoneまたはOtherクラスを追加する
これにより、モデルは既知のpositiveクラスだけでなく、学習時に与えた負例をNoneとして識別できるようになる
ただし、Noneクラスを追加しても、あらゆる未知入力を識別できるわけではない
学習に使用した負例や、それに近いOODには有効だが、まったく異なる未知入力に対して誤って高い確信度を出す可能性は残る
Noneは全体の負例クラス用のメタクラスであるため、実質的にはNoneの1-Recallこそが本来のFPRになる
Noneクラスのrecall（Noneを見逃さなかった割合）は、そのまま通常クラスのprecisionに対応する
つまり、見逃さずに正確に処理できた通常クラスの評価につながる
Noneクラスの性能が下がれば、当然通常クラスの性能にも影響が出る

既知の弱点をあらかじめ加味する

例えばNLPでは、否定表現において精度が下がりやすいという既知の弱点がある
特徴が似ているにもかかわらず、クラス領域が外れてしまうことが原因
こうした既知の弱点については、あらかじめデータセットのバランスを調整して対処できる

Negationの明確化

特にnegationが絡む場合に有効な手法
例えば、Moveクラスの反対がDon’t MoveなのかStopクラスなのか、AIが迷うケースがある
その場合は、意味を明確化するために、MoveクラスのスロットにNegationを持たせ、Move(negated=True)のように表現する
すると、メタクラスであるNone以外の否定表現は、Negationスロットで対応できるようになる
結果として「動かない」と「Stop」が同一視されなくなり、精度が上がる
これはデータセットの無矛盾性とも関連する

ラベルの信頼度: GoldとSilver

データセットのラベルは、どうやって付与されたかによって信頼度が異なる。この信頼度をGold・Silverという段階で区別して管理しておくことも重要。

Gold（ゴールド）ラベル

人の手で検証・確認されたラベル
品質は高いが、作成コストが高く量を確保しにくい

Silver（シルバー）ラベル

モデルやルールベース処理などで自動生成されたラベル
量は確保しやすいが、ゴールドに比べてノイズが混ざりやすい

段階的なティア管理

単純な二値の区分だけでは不十分なことも多く、信頼度をさらに細かい段階に分けて管理すると扱いやすい
例: 読みが一意で人手検証済み（gold_verified）、人手検証済みだが本質的に複数の正解がありうる（gold_free_variation）、まだ判断がついていない自動生成ラベル（silver_ambiguous）
ティアごとに、機械的なクロスチェックを先に流し、意見が割れたものを優先的に人手レビュー（Silver→Goldへの昇格）に回す、という段階的な運用と組み合わせるとよい
詳しくはフリガナデータをクレンジングする時に直した項目のメモや分布外データの対処方法でも扱っている

用途による使い分け

Trainには、SilverをGoldと混ぜて量を確保しつつ使うことが多い。多少のラベルノイズは学習の過程である程度吸収されやすい
Diag・Testのような、性能を正しく測定するためのデータには、なるべくGoldを使うべき
ラベル自体にノイズがあると、性能の低さがモデルの問題なのかラベルのノイズなのかを区別できなくなり、機械学習におけるデータ品質QAの再考の意味が薄れてしまう

ラベル・属性の管理方法

データセット、特にTrainデータセットを作る際には、サンプルが持つ属性をどう区分・管理するかという問題もある。属性の性質によって、適した管理方法が異なる。

直交する属性: フォルダ管理

クラス・サブクラス・カテゴリー・ID/OOD・Positive/Negative・Easy/Hardのような属性は、互いに直交する（1サンプルにつき各軸で1つの値だけを持ち、軸同士も独立している）
こうした属性は、フォルダ階層でそのまま表現できる

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


class_A/
 id/
 positive/
 easy/
 hard/
 negative/
 easy/
 hard/
 ood/
 positive/
 easy/
 hard/
 negative/
 easy/
 hard/

ディレクトリ構造自体がそのままデータの分類を表すため、追加のマスターファイルが無くても直感的に管理できる
特にID（In-Distribution）とOOD（Out-of-Distribution）は、機械学習におけるデータとデータソースの再考のDiagで扱う「スコープの境界」を直接反映する軸でもあり、他の軸と同様にきちんと分けて管理しておくことが重要
他にも、以下のような軸がフォルダ管理に向いている
- spec/seed（データを生成・収集する前提となる設計書やtaxonomy）
- self/others（自分で作ったデータか、他所のデータか）
- real/generated・third_party（データの出自）
- sampling_weight（学習時のサンプリング重み別）
- case（特定のケース別）
- calibration（確信度キャリブレーション用）
- generalization dataset（いわゆるOOD dataset。汎化性能を客観的に測るために別途用意しておく必要がある）

直交しない属性: Tag.jsonでの管理

UseCase・FailurePatternのような属性は、クラスのように均等に分布せず、1サンプルが複数の値を同時に持つこともある多対多の関係になる
こうした属性をフォルダで表現しようとすると、同じサンプルを複数の場所に置く必要が出てきて破綻する
代わりに、Tag.jsonのようなマスターファイルで、サンプルIDとタグの対応表として管理する方がよい

1
2
3
4


{
 "sample_001": ["use_case:login", "failure:timeout"],
 "sample_002": ["use_case:login", "use_case:logout"]
}

対称的な属性: Pair.jsonでの管理

Dyad（対）になるような、表現がわずかに違うだけの対応関係を持つサンプルもある
この対応関係自体が情報を持つため、pair_idを振り、Pair.jsonのようなマスターファイルでどのサンプル同士が対になっているかを管理する

1
2
3
4


{
 "pair_001": ["sample_010", "sample_011"],
 "pair_002": ["sample_023", "sample_024"]
}

まとめると

属性の性質	例	管理方法
直交する	クラス・カテゴリー・Positive/Negative・Easy/Hard	フォルダ階層
直交しない	UseCase・FailurePattern	Tag.json（多対多のマスター管理）
対称的	Dyad・minimal pair	Pair.json（pair_idによる対応管理）

具体的なデータセット定義例

多クラス分類の例

まずdataについて、種となるデータ（seeds）と生成されたデータ（generated）を分ける
data/{seeds, generated}のような形にする
さらにdata/seeds/grade1/class_name/{positive,negative}/subclass_name/{def.md, seed.csv}のように切る
gradeは難易度を表し、grade1からgrade6程度まで定義する
gradeを定義する理由は、うまくいかなかった時に、どこまでうまくいっているのかを測れるようにするため
それぞれの$\text{grade} \times \text{class} \times \text{subclass}$について、分割統治法のように解いていくイメージ

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


 seed1/
 grade1/
 class1/
 positive/
 subclass1/
 subclass2/
 negative/
 subclass1/
 subclass2/
 class2/
 positive/
 subclass1/
 subclass2/
 negative/
 subclass1/
 subclass2/
 grade2/
 class2/
 positive/
 subclass1/
 subclass2/
 negative/
 subclass1/
 subclass2/

二値分類の例

以下は、ある名前を対象にした二値分類のクラス設計の実例。

グレードをトップで分けるのではなく、まずreal/syntheticというsourceの軸で分ける
その後にgrade分け（難易度分け）をクラスに落とし込み、クラス単位で難易度を教える
この例では単純な二値分類ではなく、negativeの内訳を細分化して5クラス分類にしている
対象クラスのフォルダ以外はすべてnegativeケースになる
最後に、サブクラス単位でさらに分割している

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


 synthetic/
 target_voice/
 easy_simple/
 hard_negative_voice/
 wrong_name_with_prefix/
 arbitrary_prefix/
 bare_other_name/
 real_word_fragment/
 invented_syllable/
 no_voice/
 synthetic_noise/
 real/
 target_voice/
 easy_simple/
 negative_voice/
 corpus_a/ corpus_b/ corpus_c/
 no_voice/
 silence_clips/ ambient_noise/ musan_noise/

まとめ

分類クラスの設計には、完全性は目指さず無矛盾性を目指すという原則があり、seedとタクソノミーというデータ仮説、サブデータセットによる分割統治で実現しやすくなる
評価用データはgrade別に難易度設計しておくと、基礎能力への悪影響やholdout過信を避けられる
Gradeの本質的な価値は、最小条件でタスクが本当に解けるかを検査できること。grade1が解けない場合、モデルの問題ではなくタスク定義・クラス設計自体を見直すべきシグナルになる
スコープは「なんでもできる（バギー）」か「少しはできる（リライアブル）」かの選択で、理想は前者だが直接狙うと修羅の道になりやすく、狭いgradeから段階的に広げる方が近道になる
grade別のラダー表を作っておくと、各gradeで何が加わるかを1段単位で明文化でき、スコープの限界を開発者以外にも説明しやすくなる
クラスの範囲を絞り境界を太くするGeometric Class Designや、コア（意味軸）とサーフェス（表現軸）の分離によって、クラスの幾何学的な領域を設計できる
2つのクラスを継続的に取り違えるサンプルがある場合、それはANDの領域が存在するサインであり、無理に既存クラスへ押し込めず、専用の中間クラスを新設することで無矛盾性を回復できる
AND領域への対処は、中間クラスの新設以外にも、離散ラベル（排他性を前提にしたsingle-label）かマルチラベル（クラスごとに独立したlogit形式）かというラベル表現自体の選択でも解決できる
特に意味の近いクラス同士は、inner-class・inter-classでの一貫性チェックと、境界専用データセットが有効
shifted positive・adversarial negatives・Truncated Negative・Hidden Negativeなど、hard caseの作り方には複数の手法があり、組み合わせ数を数えることでデータのかさ増し効果も見積もれる
NoneクラスやNegationスロットの設計によって、明示的な負例の識別や否定表現の混同を防げる
メタクラスという観点では、None（負例）・OOD（分布外）・Impossible（分類不能な入力）の3種類があり、特にImpossibleを切り出しておくと、性能低下の原因がクラス設計の問題か壊れた入力かを切り分けられる
ラベルにはGold（人手検証済み、高品質・高コスト）とSilver（自動生成、大量・ノイズあり）の信頼度差があり、Trainは混ぜて量を確保、Diag・Testはなるべく Goldを使うという使い分けが重要
クラス・属性の管理は、直交する（フォルダ管理）・直交しない（Tag.json）・対称的（Pair.json）という性質ごとに、適した方法を使い分ける
実際のフォルダ構成例として、grade×class×subclassの多クラス分類と、source軸を起点にした二値分類の2パターンを示した