AI学習データを数千件、数万件集める計画でも、最初から全件を募集することはおすすめできません。仕様書では問題がないように見えても、実際に参加者へ依頼すると、説明が伝わらない、想定より時間がかかる、同じ箇所で不備が起きるといった問題が見つかるからです。

本収集前の小規模な試行は、単なる動作確認ではありません。募集から提出、検品、納品までを少人数で一度通し、計画全体が成立するかを確認する工程です。

仕様書だけでは参加者の行動を予測できない

「正面、左右、上下から撮影してください」と書いても、顔だけを動かす人、カメラを動かす人、身体ごと向きを変える人がいます。「静かな場所」も、参加者によって想定する環境が異なります。

説明を作った側には明確でも、初めて読む参加者には複数の解釈が生まれます。試行を行うと、質問が集中する部分や、見本を追加すべき箇所が分かります。

試行で確認する主な項目

• 対象条件に合う人を募集できるか
• 募集文と同意事項が理解されるか
• 一人当たりの所要時間は何分か
• 指定された端末や環境で実施できるか
• どのような質問や不備が発生するか
• 提出データの有効率はどの程度か
• 検品者が同じ基準で判定できるか
• 再提出にどれくらい応じてもらえるか
• 納品形式へ整理する工程に問題がないか

10人でも見つかる問題がある

試行人数に一律の正解はありません。撮影条件の確認なら10人程度でも、説明の誤解やファイル形式の問題を見つけられる場合があります。属性ごとの差を確認するなら、各区分から数人ずつ参加してもらいます。

重要なのは、試行で本番の分布を完全に再現することではなく、募集・作業・検品の各工程を実際に動かすことです。

試行データをそのまま本番へ混ぜないこともある

試行後に撮影条件や説明文を変更すると、試行データと本番データで条件が異なります。研究上同じデータとして扱えるかを確認し、必要であれば試行分を除外または別管理します。

逆に、条件変更がなく品質も満たしていれば、本番データへ含められる場合があります。試行前に、どの条件なら利用するかを決めておくと整理しやすくなります。

試行結果から人数・費用・期間を修正する

一人当たりの実作業時間、有効データ率、問い合わせ件数、再提出率が分かると、本番の費用と期間を現実的に見積もれます。

例えば有効率を95％と想定していたのに、試行では70％だった場合、募集人数を増やすだけでなく、不備が起きる原因を直します。見本を追加する、入力画面を変更する、撮影項目を減らすといった改善で有効率が上がることもあります。

研究者の確認が必要な例を集める

試行では、単純な合否だけでなく、判断に迷った例を残します。研究目的を理解する研究者が確認し、その判断を作業手順や検品基準へ反映します。

このやり取りによって、研究者が持つ暗黙の基準を、複数の参加者や検品者が再現できる形へ変えていきます。

本番前の試行は遠回りではない

納期が短いと、試行を省略してすぐ募集したくなります。しかし、大量収集後に仕様の問題が判明すると、全件の再確認や再収集が必要になります。

少量で失敗する時間を確保することが、大量のやり直しを防ぎます。試行は本番を遅らせる工程ではなく、本番を予定どおり完了させるための工程です。