機械学習の精度は“データの質”に大きく依存します。
そのため、自分の目的に最適化されたデータセットを自作できれば、モデルの力を最大限引き出せるようになります
しかし、データ作りは単なる作業の積み重ねではなく、「目的設計 → データ設計 → 収集 → ラベリング → 前処理 → 分割 → ドキュメント化」という、ひとつのプロジェクトとして捉えるべきものです。
ここでは、Webマーケの業務とも親和性の高い「問い合わせテキストを感情別に分類するタスク」 を例にしながら、データセットをゼロから作り上げる方法を体系的に解説していきます。
スタート地点は“目的の明確化”──何を予測させたいのか？
最も重要なのは、モデルが何を判断すれば成功と言えるのかを先に定義することです。
これが曖昧だと、データの項目設計もラベルもブレてしまい、後になって作り直す羽目になります。
タスクの種類を決める
機械学習のタスクにはさまざまありますが、代表例は下記の通りです。
- 分類：問い合わせの感情を「ポジ・ネガ・怒り」などに分類
- 回帰：翌日のCV数やLTVなどの数値予測
- ランキング：購入確率の高いユーザー順に並べる
- 生成：問い合わせメールの返答案を生成する など
本記事ではテキスト分類を例に進めます。
モデル利用シーンの想定
利用場面によって必要なデータが変わります。
- リアルタイム判定か？（チャットサポート等）
- 日次バッチか？（前日の問い合わせを集計）
- 個別判断か？ 全体傾向を掴むためか？
目的がクリアになるほど、必要データの粒度や期間が正確に決まっていきます。
データ構造とラベル定義を設計する
ここでの設計が甘いと、後のアノテーションで破綻します。
1レコードの構造を決める
例：問い合わせ分類用
| 項目 | 内容例 |
|---|---|
| id | 一意なID |
| text | 問い合わせ本文 |
| created_at | 受信日時 |
| channel | 取得チャネル |
| user_type | 新規/既存など |
| label | 後で付ける感情ラベル |
特徴量になり得る項目は、最初にできるだけ入れておくほうが後々便利です。
ラベル定義は最も重要
例：感情分類ラベルの案
positiveneutralnegativeangryother（スパム等）
ポイントは以下の通り。
- ラベル同士は排他的に
- 誰が読んでも同じ判断をするレベルまで定義を書く
- 曖昧さを減らすための優先ルールを作る
- 最初に少量で試し貼りし、定義をフィードバックする
データ収集──どこから集め、どう安全に扱うか？
自社データを使う場合
マーケ現場では、次のデータがもっとも扱いやすいです。
- 問い合わせフォームやチャットのログ
- メール対応履歴
- SNSのメンションやDM
- レビューコメントやアンケート自由入力欄
ただし、必ず個人情報を除去・マスクし、会社のプライバシーポリシーで「二次利用」が許可されているかの確認は必須です。
外部データの取得
- スクレイピングは規約・著作権に注意
- 可能ならライセンスが明示されたオープンデータを利用
今回は「自作」が目的なので、まずは自社データが最適です。
アノテーション（ラベリング）──人が判断する工程を制度化する
誰がラベルを付けるか
- 自分
- チームメンバー
- 外注（クラウドソーシング）
人数が増えるほど、ルールの文字化が不可欠です。
ラベリングガイドラインを用意する
最低限書いておくべきこと
- タスクの目的
- ラベル一覧・定義・例文・カウンター例
- 曖昧なケースの判断指針
- よく出る質問のFAQ
ルールが曖昧なまま始めると、後でラベルの揺れが大量発生して修正が大変になります。
実務的なラベリングフロー
- CSV/シートで
textと空欄のlabelを用意 - ラベラーに渡す
- 回収後に取り込む
大規模に行う場合はWebUIツールを使うと効率的です。
品質管理
- ダブルラベリングで一致率を計測
- ランダムサンプリングで管理者チェック
- 明らかにブレが多いラベラーのデータは見直し
クレンジングと前処理──学習しやすい形に整える
ノイズ・重複の除去
- 同じ文が大量にある場合は除去
- 極端に短い文は学習に不向き
- スパムは
otherラベルへ分離 or 除外
個人情報のマスク
例
- 氏名 →
[NAME] - メール →
[EMAIL] - 電話 →
[TEL] - 住所 →
[ADDR]
プライバシー保護は必ず徹底します。
テキスト前処理
最新モデルは前処理に神経質になる必要はありませんが、
- ゴミ文字の削除
- 絵文字の扱い
- 半角・全角の統一
などは早めにルール化すると安定します。
データ分割──train / validation / test の設計
一般的な分割比率
- train：70〜80%
- validation：10〜15%
- test：10〜15%
分割時の注意点
- 同じユーザーのデータがtrainとtestの両方に入らない
- 時系列タスクでは過去→未来の順を守る
- ラベル分布が偏らないよう層化サンプリングを使う
データセットのドキュメント化──後で見て迷わないために
自作データセットこそ「仕様書」を残す価値があります。
書くべき内容
- データセットの目的
- 収集元・期間・チャネル
- 前処理ルール（マスキング等）
- ラベル定義と例
- 全体件数・ラベルごとの件数
- 想定されるバイアス
- 利用上の注意点や制限事項
これらを残すことで長期的な運用がスムーズになります。
自作データセットで起きがちな失敗とその回避策
ラベルを細かくしすぎる
→ データ不足・偏りが発生してモデルが安定しない
対策：最初は3〜5クラスに絞る
アノテーションルールが曖昧で人によって判断が違う
→ モデル精度が伸びない
対策：例文とNG例を大量に用意、少量で試し貼り
学習データと本番環境の分布が違う
→ 本番で急に精度が落ちる
対策：実際に利用するチャネルのデータを必ず含める
プライバシー対策を後回しにする
→ 途中で作り直しになる
対策：最初の段階でマスクルールを決定
マーケ実務での具体例
例1：問い合わせの感情分類データセット
- 目的：怒り・ネガを早期検知し、有人対応にエスカレーション
- スキーマ設計
- 過去6ヶ月のログを収集
- 個人情報をマスク
- ラベル定義
- CSメンバーで1,000件×3人程度ラベル付け
- クレンジングと分割
- ドキュメント化
例2：広告クリエイティブの成果ランク付け
- 過去配信データを収集
- CTR/CVRからランク（A〜D）を自動ラベル化
- 「テキスト＋メタ情報 → ランク」を学習させるデータセットを構築
最初の一歩としておすすめの進め方
完璧を目指す必要はありません。
最初は小さく始めるのが成功のコツです。
- タスクを1つに絞る（例：ネガ検知の2クラス分類）
- 100〜300件だけ手動でラベル付けしてみる
- そのデータで簡易モデルを試して課題を洗い出す
- 気づいた点をルール・スキーマに反映し、本格構築へ進む
以上、機械学習のデータセットの自作方法についてでした。
最後までお読みいただき、ありがとうございました。
