データセットとは？ 初心者向けに解説

私たちの視点は、ごくささやかなものですが、私たちはGeonodeという企業であり、ウェブからデータを収集する人々にプロキシを販売しているため、データセットが作成されたその瞬間に多くのデータセットを目にする機会があります。ここで伝えたい重要な点は、大きなミスは収集時に発生し、それが数ヶ月後に発覚するということです。 データがいつ収集されたかを記録しない、どのフィールドが欠落している可能性があるかを記録しない、生のレスポンスを保存しない――これらはいずれも、収集当初は問題になりませんが、予期せぬ質問が投げかけられた際、データセットを完全に使い物にならなくしてしまいます。この記事で紹介する内容は、何も購入する必要はありません。良い習慣は無料で、そのほとんどは数分で実践できます。

基本的な構造

ほとんどのデータセットは、フォーマットがどうであれ、同じ構造を持っています。

レコード — 個々の項目。表の行、JSON配列内のオブジェクト、ディレクトリ内のファイルなどです。1つのレコードは、記述対象となる1つの事柄（人、取引、製品、写真など）を表します。

フィールド — 各レコードの属性。テーブルの列、オブジェクトのキー。名前、価格、日付、カテゴリなど。

値 — 特定のレコードにおいて、特定のフィールドが保持する内容。

スキーマ — どのフィールドが存在するか、それらがどのような型を保持するか、そしてどれが必須であるかを記述したもの。形式的に定められ強制される場合もあれば、非公式な了解事項である場合もあり、時には全く存在しないこともあります。後者の場合、後々トラブルの原因となります。

メタデータ — データセットそのものに関するデータ。いつ、誰によって、どこから収集されたか、どのようなライセンスの下で提供されているか、どのような既知の制限があるかといった情報。

この最後の要素こそ、初心者が見落としがちで、経験豊富な実務家が重要視するものです。メタデータのないデータセットは、単に数字の集まりに過ぎず、それが自分の疑問に答えとなるかどうかを判断する手段がありません。

構造化データ、半構造化データ、非構造化データ

これは、前処理なしに何ができるかを決定づけるため、有用な3つの分類です。

構造化データには、固定されたスキーマと一貫したデータ型があります。データベースのテーブル、ヘッダーが固定されたCSV、スプレッドシートなどがこれにあたります。 直接クエリを実行したり、フィルタリングしたり、集計したりすることができます。

半構造化データには組織化されていますが、厳格なスキーマはありません。レコードごとに異なるフィールドを持つJSON、XML、ログ行などが該当します。解析すべき構造は存在しますが、レコードごとに異なります。

非構造化データには、固有のレコード構造がありません。テキスト文書、画像、音声、動画などがこれにあたります。情報がないわけではなく、そこからフィールドを抽出するにはモデルまたは人間の介入が必要となります。

実際には、その境界は曖昧です。ファイル名、サイズ、ラベルを記載したCSVファイルを持つ画像ディレクトリは、構造化されたインデックスを持つ非構造化コンテンツと言えます。これは機械学習データセットの標準的な構成であり、一般的に優れたパターンです。

実際の作業の多くは、これら2つの形式間の変換を伴います。ウェブスクレイピングは、非構造化されたウェブページを構造化されたレコードに変換します。この変換の過程で多くのエラーが発生するため、生のソースデータを保持することが重要になります。

フォーマットとそのコスト

その選択は、見た目以上に重要です。

ほとんどの場合を決定づける3つのポイント。

CSVには正式な仕様が存在しない。 RFC 4180は、それ自体について「ほとんどの実装で従われていると思われる」と記述している。これが、誰もが遭遇したことがある区切り文字、エンコーディング、引用符の問題の根源である。一方で、CSVはコンパクトで誰にでも読みやすいという利点があり、それが現在も使われ続けている理由だ。

JSON Linesは十分に活用されていませんが、通常はデータ収集に適しています。 1行につき1つのJSONドキュメント：一定のメモリでストリーム処理が可能で、安全に追加でき、ファイルが切り詰められていても完全なレコードをすべて取得できます。JSON配列ではこれらの利点は得られず、収集ジョブがクラッシュすると解析不可能なファイルが残ってしまいます。

Parquetは、大規模で分析を目的とするあらゆるデータに適した保存形式です。 列指向ストレージにより、40列のうち3列にアクセスするクエリではその3列のみが読み込まれます。また、類似した値が隣接して格納されるため、テキスト形式よりもはるかに優れた圧縮率を実現し、型情報も正確に保持されます。人間が直接読み取れない点が、そのトレードオフです。

合理的なパイプラインでは、中断に耐えられるJSON Lines形式に収集し、分析のためにバッチ処理でParquet形式に変換します。テキスト形式の詳細な比較については、JSON vs CSVを参照してください。

データセットの有用性を決める要素：FAIR

科学界はこの概念を体系化しましたが、この枠組みは研究分野をはるかに超えて広く適用されています。

2016年に公表されたFAIR原則では、4つの特性が定められています。

検索可能（Findable） F1では「（メタ）データには、グローバルに一意かつ永続的な識別子が割り当てられていること」が求められ、F2では「データは豊富なメタデータによって記述されていること」、F3ではメタデータが「記述対象のデータの識別子を明確かつ明示的に含んでいること」、そしてF4では「検索可能なリソースに登録またはインデックス化されていること」が求められています。

アクセス可能。 A1では、「標準化された通信プロトコルを用いて、その識別子によってデータを取得できること」が求められます。A2は、多くの人を驚かせるものであり、おそらく最も価値のある要件です。「データが利用できなくなった場合でも、メタデータにはアクセスできること」。 データセットの記述は、データセットそのものよりも長く存続すべきであり、そうすることで、数年後に論文を読む人が、どのようなデータが使用されたかを把握できるようになる。

相互運用性。 I1は、「知識表現のための、形式的で、アクセス可能で、共有され、広く適用可能な言語」を求めている； I2は、それ自体がFAIRに準拠した語彙を求めている；I3は「他の（メタ）データへの修飾付き参照」を求めている。

再利用可能。 R1は、データが「正確かつ関連性の高い複数の属性によって詳細に記述されている」ことを要求している。

これを一般的なプロジェクトの実務に当てはめると、データセットに安定した識別子を割り当て、その内容と出所を明記し、標準的なフィールド名や単位が存在する場合はそれらを使用し、ライセンスを明示し、データを削除した後もドキュメントを保存しておくということです。

データセットのドキュメント作成

FAIR原則では、ドキュメントが重要であるとされています。「Datasheets for Datasets」では、どのような内容を記載すべきかが示されています。

その2018年の提案は、すべての部品にデータシートが添付される電子産業の手法を取り入れています。 同提案では、「データセットの作成者と利用者の間のコミュニケーションを円滑にし、機械学習コミュニティが透明性と説明責任を優先するよう促す」ために、各データセットには「その目的、構成、収集プロセス、推奨される用途など」を網羅したドキュメントを添付すべきであると主張しています。

そこから導き出される実用的なチェックリストは以下の通りです：

なぜこれが存在するのか？ どのような疑問に答えるために収集されたのか。これにより、それがあなたの疑問に答えるものかどうかが判断できます。

何が含まれているか？ レコード、フィールド、型、単位、および「欠損」とみなされるもの。

どのように収集されたか？ 方法、日付、情報源、サンプリング。1週間で1つのサイトからスクレイピングされたデータセットは、1年かけて集計されたものとは異なるものです。

何が含まれていないか？ 既知の欠落、バイアス、除外された対象集団、欠落している期間。これが最も価値のある項目であるにもかかわらず、最も頻繁に欠落している部分だ。

どのように使用すべきか、またどのように使用すべきでないか？ 意図された用途と、不適切であることが分かっている用途。

ライセンスは？ および連絡先。

どのように維持管理されているか？ 更新されるかどうか、およびバージョンの識別方法。

データセットが新しいうちならこれを書くのに1時間ほどで済みますが、1年半も経って収集担当者が退職してしまった後では、ほぼ不可能です。

品質の評価

6つの評価軸があり、それぞれについて実際に実行できるチェック項目があります。

完全性。 欠落はどの程度あり、その欠落はランダムなものか？ フィールドごとのNULL値を数えてみてください。40％が空欄になっているフィールドは、何かを示唆しています――データ収集の失敗か、あるいは文書化すべき正当な「任意項目」かのどちらかです。

正確性。 値は現実を反映していますか？ 一般的に検証するのは困難ですが、具体的なケースでは対応可能です。ランダムに抽出したサンプルを、手作業でソースと照合してみてください。20件のレコードなら15分で済み、体系的な誤りのほとんどを発見できます。

一貫性。 同じ事象が同じ形で表現されているか？ 日付の形式が混在していたり、国名が「UK」と「United Kingdom」の両方で記載されていたり、価格に通貨記号がある場合とない場合が混在していたりしないか。カテゴリ型フィールドごとの異なる値の数を数えてみよう――300もの異なる「国」が存在するフィールドには、標準化の問題がある。

適時性。 データはいつ収集されたのか、そしてそれはあなたの調査課題にとって重要か？ 前四半期の価格は、データというよりは過去の記録に過ぎない。

代表性。 サンプルは、あなたが注目している母集団と一致しているか？ レビューのデータセットは、レビューを書く人々のデータセットに過ぎない。

出所。 各レコードの出典を特定できますか？ これにより、データの再導出、監査、修正が可能になります。また、これが、解析済みのレコードとともに生の回答データを保存しておく価値がある理由でもあります。

これらの確認は、分析の後ではなく、分析の前に行ってください。グラフで正規化の問題を発見するよりも、値の集計段階で発見する方が、はるかにコストがかかりません。

機械学習のためのデータの分割

データセットがモデルの学習用である場合、データの分割方法はデータそのものと同じくらい重要です。

学習セット — モデルが学習するデータ。通常、データセットの大部分を占めます。 検証セット — モデルの微調整や、複数のモデルの中から最適なものを選択するために使用されます。 テストセット — 完全に別々に保持され、実環境での性能を推定するために一度だけ使用されます。

これに関して、よくある3つの失敗例があります。

情報の漏れ。 テストセットからの情報が学習に影響を与えます。分割前にデータセット全体から算出した統計量を用いてスケーリングや補完を行うのが典型的な例であり、これにより結果が知らぬ間に過大評価されてしまいます。

分割間のレコード重複。 トレーニングセットとテストセットの両方にほぼ同一の項目が存在する場合、モデルは正解を知ってしまったことになります。同じコンテンツが複数のURLに表示されるため、ウェブから収集したデータは特にこの問題を起こしやすいです。

時間的リーク。 時系列データの場合、ランダムな分割を行うと、モデルが将来の情報から学習してしまうことになります。代わりに、日付ごとに分割してください。

一般的な原則：テストセットは、実際に直面する状況に似ているべきです。今日から明日を予測する場合は、時間軸で分割します。新規ユーザーを扱う場合は、ユーザーごとに分割します。

ライセンス：何ができるかを決める要素

法的に利用できないデータセットは、手元にあるデータセットとは言えません。ライセンスの確認は、本来あるべき頻度よりもはるかに少ないのが実情です。その理由は、通常、ライセンスが「唯一重要な要素」となるその瞬間まで、退屈な作業だと考えられているからです。

オープンデータライセンス。 クリエイティブ・コモンズ（Creative Commons）は代表的なライセンス群です。CC0は、法律が許す限り作品をパブリックドメインに置き、いかなる条件も課しません。CC BYは帰属表示を義務付けます。CC BY-SAには「同一条件での共有」という条件が追加されており、派生作品にも同じライセンスを適用しなければなりません。これは商用製品とは相容れない場合があります。 CC BY-NCは商用利用を禁止しており、「非商用」の定義は曖昧なため、利用目的が不明確な場合には真のリスクとなり得ます。政府のポータルサイトでは、実際には寛容な独自のオープンライセンスが使用されていることが多いため、勝手に推測するのではなく、一度は内容をよく読んでおくべきです。

データベース権は著作権とは別物です。 EUおよび英国では、sui generis（独自の）権利により、個々の記録が著作権の対象となるかどうかにかかわらず、データベースの内容の取得、検証、または提示に投じられた実質的な投資が保護されています。単なる事実の集まりであるデータセットであっても、データベースとして保護される可能性があり、これはまさにデータ集約プロジェクトが直面する状況そのものです。

利用規約は契約上のものです。 自動アクセスを禁止する利用規約を持つサイトから収集されたデータセットは、個々のレコードの内容にかかわらず、その問題を抱えています。これは著作権とは別の問題であり、事実そのものが保護対象でない場合でも適用されます。

個人データには独自の規制が適用されます。 レコードが（直接的または組み合わせによって）個人を特定する場合、データ保護法は、単にデータの収集だけでなく、その保有および処理にも適用されます。つまり、合法的な根拠、保存期間の制限、およびデータ主体があなたに対して行使できる権利が必要となります。 「一般に公開されていた」という事実だけでは、それ自体が適法な根拠とはなりません。

また、派生データセットには制約が引き継がれます。 シェア・アライク（Share-Alike）のデータセットを用いてモデルを学習させたり、異なるライセンスを持つ複数のソースを集約したりすると、入力データのうち最も許容範囲が広いものではなく、すべての入力の制約を合わせた義務が生じます。

実務上は、収集時にデータセットのドキュメントにライセンスを記載し、その時点での利用規約へのリンクを併記するのが一般的です。ライセンスは変更され、利用規約のページも書き換えられるため、収集時にどのような内容に同意したかを提示できることは、単に記憶しているよりもはるかに重要です。

データセットの入手先

5つの情報源を、必要な作業量の多い順に紹介します。

公開されているオープンデータセット。 政府のポータルサイト、研究リポジトリ、機関アーカイブなど。無料で、ドキュメントも整備されており、多くの場合、十分な品質を備えています。まずはこちらを確認しましょう。すでに公開されているデータを再収集する必要があるケースは少なくありません。

API。 構造化され、承認済みで、安定している。提供元がAPIを公開している場合、ほぼ常にそれが最適な手段となる。

商用データプロバイダー。 ライセンス供与され、サポート体制が整っており、それに応じた価格設定がされている。エンジニアリングにかかる時間を考慮すると、同等のものを自社で構築するよりも安価な場合が多い。

自社システム。 ログ、トランザクション、テレメトリ。通常、組織が利用できるデータの中で最も価値が高い一方で、最も見過ごされがちなものです。

Webからの収集。 当社が販売対象としているものです。 データが一般に公開されており、承認された入手経路が存在しない場合に適しています。ただし、これには義務が伴います：robots.txt、利用規約、著作権、データベース権、そして個人データが関与する場合はデータ保護法などです。また、これは最も文書化が必要な情報源でもあります。なぜなら、いつ、どこから取得したかの記録がないスクレイピングされたデータセットは、その正当性を主張したり再現したりすることが非常に困難だからです。

よくある質問

データセットとは、簡単に言うと何ですか？

関連するデータの集合で、1つの単位として扱えるよう整理されたものです。通常、フィールド（属性）を持つレコード（項目）と、各フィールドの意味を説明する記述で構成されます。スプレッドシート、データベースのテーブル、ラベル付きの画像が収められたフォルダなどは、すべてデータセットです。

データとデータセットの違いは何ですか？

データは「原材料」であり、データセットは特定の目的のためにまとめられた、範囲が定められ、整理されたデータの集合体です。その整理と範囲の定義によって、データセットは実用的なものとなります。データセットのレコード数を数えたり、フィールドを説明したり、その出所を特定したりすることができます。

構造化データと非構造化データとは何ですか？

構造化データには、データベースのテーブルのように、固定されたスキーマと一貫したデータ型があります。非構造化データには固有のレコード構造がなく、テキスト、画像、音声などがこれにあたります。半構造化データは、JSONやログファイルのように、組織化されているものの形状が可変であるため、その中間に位置します。

データセットにはどの形式を使うべきか？

スプレッドシートやデータベースローダーに取り込む平坦なテーブルにはCSV。段階的に収集されるデータにはJSON Linesが適しています。これはストリーム処理が可能で、切り捨てされてもデータが保持されるためです。大規模な分析用データにはParquetが適しています。列指向のストレージと型付けにより、クエリの実行コストが大幅に削減されるためです。

質の高いデータセットとは？

完全性、正確性、内部の一貫性、適時性、対象集団の代表性、そして追跡可能な出所です。それぞれについて具体的な検証方法があります。例えば、NULL値の件数、手作業によるサンプル検証、カテゴリ型フィールドごとの一意な値の件数などです。

データセットはどのように文書化すべきか？

そのデータセットが存在する理由、内容、収集方法と時期、既知の欠落やバイアス、適切な使用方法と不適切な使用方法、ライセンス、および維持管理方法を記録します。「Datasheets for Datasets」提案が、この分野における標準的な参考資料です。

FAIR原則とは何ですか？

Findable（発見可能）、Accessible（アクセス可能）、Interoperable（相互運用可能）、Reusable（再利用可能）—— 2016年に公表されたデータ管理のためのフレームワークです。 最も過小評価されがちな要件は、「データが利用できなくなった場合でも」メタデータへのアクセスが維持されるべきであるという点であり、つまり、記述情報はデータセットそのものよりも長く存続するのです。

機械学習のためにデータセットをどのように分割すればよいですか？

トレーニングセット、検証セット、およびテストセットに分割し、テストセットは1回のみ使用します。変換処理はトレーニングセットのみに対して行い、分割間でほぼ重複するデータを削除し、時系列データの場合はランダムではなく時間順に分割します。これら3つはすべて、結果が知らず知らずのうちに過大評価される一般的な原因です。

まとめ

データセットとは、レコード、フィールド、値、そしてそれらに意味を与える説明から成るものです。この説明こそが、6か月後にも、あなたを含め誰もがそのデータセットを利用できるかどうかを左右する要素なのです。

フォーマットそのものよりも、習慣の方が重要です。適している場合はCSV、中断されたジョブでもデータが失われないため段階的に収集する場合はJSON Lines、データ量が膨大で分析的なクエリを行う場合はParquet。これらどれでも問題ありません。失敗の原因となるのは、長時間実行される収集にJSON配列を選択し、クラッシュ後に解析不能なファイルが残ってしまうようなケースです。

最も労力を費やす価値があるのは、データセットが新鮮なうちに作成するドキュメントです。 そのデータセットが存在する理由、収集方法と時期、欠落している情報、そしてどのような用途には使用すべきでないか。FAIR原則はこれを形式的に定めており、「Datasheets for Datasets」提案はチェックリストを提供していますが、どちらも同じ方向を指し示しています。すなわち、メタデータはデータそのものよりも長く存続すべきだということです。

また、分析を行う前に品質を確認してください。フィールドごとのNULL件数、カテゴリ型フィールドごとの固有値、そしてソースデータと照合して手作業で検証した20件のレコードを確認するだけで、1時間以内に体系的な問題のほとんどを発見できます。これは、分析結果から問題を発見するよりもはるかにコストが抑えられます。