「画像1,000件、品質確認済み」だけでは、誰からどの条件で集め、何を除外し、どの基準でラベルを付けたのか分かりません。データセットカードを書くための材料は公開直前に集めるのではなく、制作中の台帳や作業記録として残します。
三つの文書化手法を区別し、必要な記録を決める
GebruらのDatasheets for Datasetsは、目的、構成、収集、前処理・ラベル付け、利用、配布、維持管理について制作段階に沿って答える質問群を提案しています。Google ResearchのData Cardsは、データの由来、収集・注釈の判断、用途などを関係者が読める構造化された要約として提案しています。Hugging FaceのDataset Cardは、リポジトリのREADME.mdをデータセットのページに表示する仕組みです。これらは同一の規格ではありません。以下は、各提案の必須項目を統合した一覧ではなく、納品や公開に備えるための実務上の記録設計です。
公開直前ではなく、募集と収集の時点から書く
案件開始時に、目的と想定用途、募集対象と除外条件、地域・言語・年代などの割付、一人当たりの実施数、提示する質問・刺激・台本、回答形式を仕様書に記します。募集時の説明文と同意の版、収集期間、機器・アプリと環境、撮影・回答指示の版、再提出条件も保存します。「スマートフォンで撮影」とだけ書くより、再収集や分析で差が出る設定を特定できます。
収集中は、参加者ID・セッションID・原本IDを対応付け、例外の質問と回答、再撮影、除外の理由、計画件数からの変更、確認者を記録します。参加者名や担当者の個人情報は内部でアクセスを管理し、公開用カードには必要な集計と成立条件だけを移します。
カードの記載事項を、制作記録から引けるようにする
| 項目 | カードへ記す内容 | 制作中の情報源 |
|---|---|---|
| 目的・想定用途 | 対象課題、適する利用と対象外 | 企画書・要件定義 |
| データの構成 | 単位、形式、件数、ラベル内訳 | ファイル台帳・件数集計 |
| 収集対象・参加者条件 | 募集条件、割付、対象から外した条件 | 募集仕様・参加者台帳 |
| 募集・同意 | 募集方法、説明と同意の取得方法 | 募集文・同意文書の版と実施記録 |
| 収集環境・使用機器 | 分析に影響する環境、端末、設定 | 機器表・収録ログ |
| 収集時の作業指示 | 提示内容、実施手順、収集期間 | 台本・刺激一覧・指示書の版 |
| アノテーション項目と定義 | ラベルの意味、境界、保留の扱い | 注釈ガイド・例題 |
| 評価者・作業者の条件 | 募集、選抜、研修、判定人数 | 募集条件・研修記録・割当表 |
| 検品方法 | 検査対象、抽出率または全件、合格条件 | 検品仕様・検査ログ |
| 除外・再取得の条件 | 理由別件数、採否と再取得基準 | 差し戻し・除外台帳 |
| 前処理・変換・匿名化 | 原本から公開版への主な処理 | 原本対応表・処理ログ |
| データ分割 | train・validation・testの件数と分割単位 | 分割表・生成設定 |
| 既知の偏りや欠損 | 偏った収集条件、欠損の種類と範囲 | 構成集計・欠損台帳 |
| 利用可能な範囲 | 許可した利用、配布条件、制約 | 同意条件・利用条件・公開判断 |
| バージョンと変更履歴 | 公開版、変更点、過去版との関係 | 版管理表・承認記録 |
| 問い合わせ先 | 維持管理の窓口 | 運用体制表 |
件数は「総数1,000件」だけにせず、参加者、セッション、ファイル、発話・画像・回答のうち何を一件と数えるかを定義します。収集総数、除外数、納品・公開数を同じ単位でつなぎ、ラベル・必要な属性・欠損の内訳と、train・validation・testの各件数を示します。一人の参加者から複数ファイルを得た場合、ファイル数を参加者数として表示しません。
ラベルの確定方法と、検品の基準を説明する
注釈ガイドには、ラベルの定義、含める例と除外する例、複数ラベルの可否、該当なし・判断不能・保留の区別を残します。何人が一項目を判定したか、評価者の募集・選抜・研修条件、不一致の確認方法、多数決・裁定・専門家確認の使い分けも記録します。例えば三人の多数決なら、同票や全員不一致、判断材料がない場合の処理まで定めます。仕様変更後に再判定した範囲とガイドの版が分からなければ、同じラベル名でも意味が異なるおそれがあります。
検品も「済み」の一語で済ませず、全件か抜き取りか、単位はファイルか注釈か、重複・破損・欠損を自動でどう検出し、音声・画像・回答・ラベルを人が何で合否判定したかを残します。再提出・再収集条件、除外理由別の前後件数、作業者と検品者を分けたか、修正後の再検査も記録します。カードには方法と集計を載せ、各項目の判定者・差し戻し履歴は内部記録で追えるようにします。
カード、制作記録、項目ごとの履歴を分ける
第一層のデータセットカードには、利用者が構成と成立条件を理解するための説明を書きます。第二層の制作記録には、募集、作業指示、質問対応、例外判断、検品の詳細を置きます。第三層の項目単位の履歴には、各原本ID、加工後ID、元のラベルと確定ラベル、差し戻し、除外理由を結び付けます。カードに全記録を貼る必要はありませんが、カードの件数や処理説明を下層の記録から照合できる設計にします。
既存のデータで旧版の仕様書や除外件数が残っていない場合は、推測で補いません。「記録なし」「確認できない」「一部期間のみ記録あり」「旧版仕様書なし」「当時と現在で集計単位が異なる」と、分かる範囲を明示します。Datasheetsの原論文も、作成者が確認できなかった回答を不明として記した例を示しています。
追加収集や修正では、過去版との対応を残す
追加、誤り修正、ラベル変更、ファイル削除では、カードの旧版を黙って書き換えず、データ本体・カード・注釈ガイド・検品記録の対応を記録します。変更台帳には「版、公開日・適用日、追加・修正・削除の別、対象IDまたは範囲、理由、変更したガイドとラベル定義、件数の増減、再判定・再検品の有無、旧版との互換性、承認者または確認者」を設けます。旧版と新版を比較できるようにし、変更の影響を受けた注釈だけ再確認したのか、全体を再判定したのかを書きます。
制作記録をHugging Faceのカードへ移す前に確認する
Hugging FaceではREADME.mdがカードとして表示され、冒頭のYAMLメタデータに言語、ライセンス、サイズに関する分類、タスクの種類などを指定できます。公式の作成ガイドを参照しつつ、収集台帳から参加者条件・期間、ファイル一覧から構成・件数、指示書から収集・注釈方法、質問と変更の記録から判断基準と例外、検品ログから除外数、加工履歴から公開版の作り方を移します。記載できない欄は確認状況を明示します。
| 公開前の確認 | 照合するもの |
|---|---|
| 公開件数・分割数が合うか | 公開ファイル一覧と除外後の集計 |
| 収集・注釈の説明が実態と合うか | 実施ログと適用した指示書・ガイドの版 |
| 加工、欠損、利用範囲を説明できるか | 原本対応表、欠損台帳、同意・配布条件 |
| 過去版との差を追えるか | データ・カード・ガイド・検品記録の版対応表 |
カードの記述は品質保証の代わりではありません。制作中の記録と公開版を照合し、確認できた条件、残る欠損、更新された範囲を利用者へ伝えるための文書として運用します。
RESEARCH DATA SUPPORT
データセット制作記録と公開用文書の整備をご相談いただけます
株式会社イングクラウドでは、募集・収集条件の記録、アノテーション仕様と作業履歴の管理、検品・除外記録の整備、納品・公開用のデータセット文書に必要な情報整理をご相談いただけます。