この古いバージョンの AutoML Tables は非推奨となり、2024 年 3 月 31 日以降は Google Cloud で使用できなくなります。AutoML Tables のすべての機能と新しい機能は、Vertex AI プラットフォームで使用できます。リソースを移行する方法については、Vertex AI に移行するをご覧ください。

トレーニングデータの準備

このページでは、トレーニングデータを AutoML Tables へのインポート前に準備する方法を説明します。

はじめに

トレーニングデータの品質は作成するモデルの有効性を大きく左右し、ひいてはそのモデルから返される予測の品質にも大きく影響します。このデータはアップロードした後に変更できません。トレーニングデータをインポートした後に変更する必要がある場合は、ソースデータを更新して再インポートする必要があります。

データが AutoML Tables でどのように解釈され、使用されるかを理解することで、クリーンで有効性の高いデータをアップロードできます。

問題の把握

有効性の高いトレーニングデータを作成するには、まず、問題を明確に定義して、必要な予測結果が得られるようにする必要があります。機械学習に初めて取り組む場合は、AutoML Tables で対応する問題のタイプを検討し、作成するモデルのタイプを決定します。AutoML Tables でサポートされている問題のタイプの詳細については、問題のタイプをご覧ください。

データセットに含めるデータの決定

次に、トレーニングデータに含めるデータを決定します。ビジネスデータにすでに存在するテーブルを使用できる場合もあります。また、さまざまなソースから得たデータを組み合わせて必要に応じてデータ変換を行ったり、有効性の高いトレーニングデータを作成するために一部の列を除去したりすることが必要な場合もあります。

トレーニングデータの要件

トレーニングデータは次の要件に従う必要があります。

100 GB 以下である必要があります。
予測する値（ターゲット列）が含まれている必要があります。

データにこの列が存在しない場合、AutoML Tables ではトレーニングデータを目的の結果に関連付けることができません。この列のデータ型によってモデルのタイプも決まります。詳細
列数は 2～1,000 列である必要があります。

1 つはターゲット列で、それ以外に、モデルのトレーニングに使用できる特徴が 1 つ以上必要です。ただし、トレーニングデータには 2 列に限らず、さらに多くの列があるのが理想的です。
行数は 1,000～200,000,000 行である必要があります。

データセットに含まれる特徴の数によっては、1,000 行では高品質のモデルをトレーニングするために十分でない場合があります。詳細

トレーニングデータに基づく追加の機能

このほか、AutoML Tables の一部の機能では、特定のデータをトレーニングデータに含める必要があります。

データをトレーニング用、評価用、テスト用に分割する方法を制御する場合は、データ分割の制御についてをご覧ください。
特定の行の重み付けを他の行より重くする場合は、トレーニングデータでの重み付けの使用についてをご覧ください。

データに関する推奨事項については、トレーニングデータを作成するためのベストプラクティスをご覧ください。

インポートのソースの準備

モデルのトレーニングデータを AutoML Tables に渡す方法は 2 つあります。

BigQuery の使用
CSV（カンマ区切り値）ファイルの使用

どちらのソースを使用するかは、データの保存方法、データのサイズと複雑性によって決まります。データセットのサイズが小さく、複雑なデータ型が必要ない場合は、CSV を使用するのが簡単です。配列や構造体を含むサイズの大きいデータセットの場合は、BigQuery を使用する必要があります。

インポートするソースがどちらの場合でも、データは次の要件を満たす必要があります。

行数は 1,000～200,000,000 行。
列数は 2～1,000 列。
100 GB 以下。

BigQuery

BigQuery テーブルでは、US または EU のロケーションでマルチリージョンの BigQuery データセットを使用する必要があります。BigQuery テーブルとそのデータソースのロケーション（異なる場合があります）に応じて、次の表に示す権限の更新を行う必要があります。ホームプロジェクト（AutoML Tables が配置されているプロジェクト）や外部プロジェクトで権限の変更が必要になる場合があります。

テーブルタイプ	テーブルのロケーション	データソースのロケーション	追加が必要な役割
ネイティブの BigQuery テーブル	ホームプロジェクト	なし	なし
ネイティブの BigQuery テーブル	外部プロジェクト	なし	外部プロジェクトの `BigQuery Data Viewer`。詳細
BigQuery ビュー	同じプロジェクト	なし	なし
BigQuery ビュー	別のプロジェクト	該当なし	外部プロジェクトの `BigQuery Data Viewer`。詳細
Bigtable でサポートされる外部 BigQuery データソース	ホームプロジェクト	ホームプロジェクト	ホームプロジェクトの `Bigtable Reader`。詳細
Bigtable でサポートされる外部 BigQuery データソース	ホームプロジェクト	外部プロジェクト	外部プロジェクトの `Bigtable Reader`。詳細
Bigtable でサポートされる外部 BigQuery データソース	外部プロジェクト	外部プロジェクト	外部プロジェクトの `BigQuery Reader` と `Bigtable Reader`。詳細
Cloud Storage でサポートされる外部 BigQuery データソース	ホームプロジェクト	ホームプロジェクト	なし
Cloud Storage でサポートされる外部 BigQuery データソース	ホームプロジェクト	外部プロジェクト	外部プロジェクトの `Storage Object Viewer`。詳細
Cloud Storage でサポートされる外部 BigQuery データソース	外部プロジェクト	外部プロジェクト	外部プロジェクトの `Storage Object Viewer` と `BigQuery Data Viewer`。詳細
Google スプレッドシートでサポートされる外部 BigQuery データソース	ホームプロジェクト	該当なし	スプレッドシートファイルを AutoML サービスアカウントと共有します。詳細
Google スプレッドシートでサポートされる外部 BigQuery データソース	外部プロジェクト	該当なし	外部プロジェクトの `BigQuery Reader`。スプレッドシートファイルを AutoML サービスアカウントと共有します。

BigQuery テーブルにはスキーマを指定する必要はありません。データをインポートすると、AutoML Tables によって自動的にそのテーブルのスキーマが推測されます。

BigQuery の URI（トレーニングデータのロケーションを指定する）は、次の形式に従っている必要があります。

bq://<project_id>.<dataset_id>.<table_id>

URI には他の特殊文字を含めることはできません。

BigQuery のデータ型と、そのデータ型の AutoML Tables へのマッピング方法については、BigQuery テーブルをご覧ください。BigQuery 外部データソースの使用の詳細については、外部データソースの概要をご覧ください。

CSV ファイル

CSV ファイルの要件

CSV ファイルは Cloud Storage またはローカルコンピュータにあります。次の要件を満たす必要があります。

最初のファイルの 1 行目は、列の名前を含むヘッダーである必要があります。後続のファイルの 1 行目がこのヘッダーと同じ場合はヘッダーとして扱われ、それ以外の場合はデータとして扱われます。
列名には、あらゆる英数字やアンダースコア（_）を使用できます。列名の先頭をアンダースコアにすることはできません。
区切り文字はカンマ（,）でなければなりません。
各ファイルのサイズは 10 GB を超えてはなりません。

最大サイズの 100 GB に達するまで、複数のファイルを含められます。

CSV データのスキーマは指定する必要はありません。AutoML Tables によって、データのインポート時に自動的にそのテーブルのスキーマが推測され、列名にヘッダー行が使用されます。

CSV ファイルのファイル形式とデータ型の詳細については、CSV ファイルをご覧ください。

Cloud Storage バケットの要件

Cloud Storage からデータをインポートする場合、そのデータは次の要件を満たすバケット内にある必要があります。

Cloud Storage バケットの要件に準拠しています。
バケットが AutoML Tables と同じプロジェクト内にない場合、そのプロジェクトの AutoML Tables に Storage > Storage Object Viewer 役割を付与する必要があります。詳細

ローカルコンピュータからデータをインポートする場合は、次の要件を満たす Cloud Storage バケットが必要です。

Cloud Storage バケットの要件に準拠しています。
バケットが AutoML Tables と同じプロジェクト内にない場合、そのプロジェクトの AutoML Tables に Storage > Storage Object Creator 役割を付与する必要があります。詳細

AutoML Tables では、データをインポートする前にこのバケットをステージング領域として使用します。

ローカル PC から CSV ファイルをインポートするには、Google Cloud コンソールを使用する必要があります。

データ分割の用途

データセットを使用してモデルをトレーニングする場合、そのデータはトレーニングセット、検証セット、テストセットの 3 つに分割されます。

トレーニングセットと検証セットは、前処理、アーキテクチャ、ハイパーパラメータのオプションの組み合わせの数が膨大にある場合に、それらの組み合わせを試すのに使用されます。こうした試行を経てトレーニング済みモデルが得られます。このモデルはその後、検証セットに基づいて品質が評価され、さらに別のオプションの組み合わせの探索につながります。

さらに試行を重ねてもそれ以上品質は改善しないという段階までくると、そのバージョンのモデルは最終的な最高品質のトレーニング済みモデルと見なされます。次に、AutoML Tables では、並列調整フェーズで決定されたパラメータとアーキテクチャを使用して、さらに 2 つのモデルがトレーニングされます。

トレーニングセットと検証セットを使用してトレーニングされたモデル。

AutoML Tables は、テストセットを使用してこのモデルでモデル評価指標を生成します。このプロセスでテストセットが使用されるのはこれが初めてです。この方法により、最終的なトレーニング済みモデルが本番環境でどの程度的確な結果を出せるかを、最終的な評価指標が偏りなく反映しているかが確認されます。
トレーニングセット、検証セット、テストセットを使用してトレーニングされたモデル。

このモデルは、予測をリクエストするために使用するモデルです。

データ分割の制御について

デフォルトでは、AutoML Tables はデータ行の 80% をトレーニング用、10% を検証用、10% をテスト用としてランダムに選択します。データセットが、時間とともに変化しない、相対的にバランスがとれている、本番環境で予測に使用されるデータの分布を反映している場合、通常はランダム選択アルゴリズムで十分です。最も重要な目標は、テストセットが、モデルを適用する本番環境のデータを正確に表しているかを確認することです。この目標が達成されると、評価指標は、モデルが実際の環境でどのような結果を出せるかを正確に示すようになります。

分割されたそれぞれのデータでどの行を使用するかを自分で選択する必要があるのは、次のような場合です。

データが時間に依存している。

この場合、時間列または手動分割を使用します。これにより、最新のデータがテストセットとして使用されます。
テストデータに、本番環境を代表していない集団のデータが含まれている。

たとえば、多数の店舗の購入データでモデルをトレーニングするとします。しかし、そのモデルは本来、トレーニングデータに含まれない店舗についての予測を行うために使用されます。モデルがデータにない店舗にも対応する汎用性を持つようにするには、データセットを店舗ごとに分離する必要があります。つまり、テストセットには評価セットとは異なる店舗だけを含め、評価セットにはトレーニングセットとは異なる店舗だけを含める必要があります。
クラスの数が不均衡である。

トレーニングデータで特定のクラスの数が別のクラスの数より多い場合、テストデータに少数派のほうのクラスのサンプルを手動で増やす必要があります。AutoML Tables では層化サンプリングは行われないため、テストセットに含まれている少数派のクラスのサンプル数がわずか数個、場合によってゼロということもあります。

どの分割に対してどの行を選択するかを制御するには、次の 2 つの方法のいずれかを使用します。

データ分割列
時間列

データ分割列と時間列の両方を指定する場合は、データ分割列のみがデータの分割に使用されます。

データ分割列

データ分割列を使用すると、トレーニング、検証、テストのそれぞれに使用する行を選択できます。トレーニングデータを作成する場合、列を追加して、そこに次のいずれかの値（大文字小文字の区別あり）を含めることができます。

TRAIN
VALIDATE
TEST
UNASSIGNED

この列の値は、次の 2 つの組み合わせのいずれかにする必要があります。

TRAIN、VALIDATE、TEST のすべて
TEST と UNASSIGNED のみ

すべての行にはこの列の値が必要です。空の文字列にすることはできません。

たとえば、すべてのセットが指定されている場合:

"TRAIN","John","Doe","555-55-5555"
"TEST","Jane","Doe","444-44-4444"
"TRAIN","Roger","Rogers","123-45-6789"
"VALIDATE","Sarah","Smith","333-33-3333"

テストセットのみが指定されている場合:

"UNASSIGNED","John","Doe","555-55-5555"
"TEST","Jane","Doe","444-44-4444"
"UNASSIGNED","Roger","Rogers","123-45-6789"
"UNASSIGNED","Sarah","Smith","333-33-3333"

データ分割列には、任意の有効な列名を指定できます。

データ分割列の値が UNASSIGNED の場合、AutoML Tables では自動的にその行がトレーニングセットまたは検証セットに割り当てられます。

データをインポートしたら、手動データ分割を選択し、この列をデータ分割列として指定します（mlUseColumnSpecId フィールドを使用することもできます）。

時間列

時間列を使用すると、そのデータでは時間が重要であり、時間の経過とともにランダムに配分されないことが AutoML Tables に示されます。時間列を指定すると、AutoML Tables では最も時間の古い 80% の行がトレーニング用に、その後の 10% が検証用に、最も時間の新しい 10% がテスト用に使用されます。

AutoML Tables では、各行は独立した同一の分散型トレーニングのサンプルとして扱われます。時間列を設定してもこれは変わりません。時間列はデータセットの分割にのみ使用されます。

時間列の値はデータセット内のすべての行に含める必要があります。評価セットとテストセットが空にならないように、時間列に十分な数の固有の値があることを確認してください。通常は、少なくとも 20 個の固有の値があれば十分です。

時間列のデータ型は Timestamp である必要があります。

スキーマの確認中に、この列を時間列として選択します（API では、timeColumnSpecId フィールドを使用します）。この選択は、データ分割列が指定されていない場合にのみ有効です。

データの分割に使用しない時間関連の列がある場合は、その列のデータ型を Timestamp に設定します。時間列として設定しないでください。

トレーニングデータでの重み付けの使用について

デフォルトの場合、AutoML Tables ではトレーニングデータの各行に均等に重み付けします。トレーニングでは、他の行より重要と見なされる行は存在しません。

場合によっては、トレーニングで一部の行を他の行より重要と見なすことがあります。たとえば、支出のデータを使用している場合、支出の多い項目に関連するデータがモデルに与える影響を、他より大きくなるよう設定できます。特定の結果が欠けることを特に避けたい場合、その結果を含む行の重み付けをより重く設定できます。

データセットに重み列を追加すると、行に相対的な重みを設定できます。重み列は数値型の列でなければなりません。重み列を使用して 0～10000 までの値を指定します。この値が高い場合、モデルのトレーニング時におけるその行の重要度もそれに応じて高くなることが AutoML Tables に示されます。重み 0 の行は無視されます。重み列を含める場合は、各行の値を含める必要があります。

後でスキーマを確認するときに、この列を重み列として指定します（weightColumnSpecId フィールドを使用することもできます）。

カスタマイズした重み付けスキーマは、モデルのトレーニングのみに使用され、モデルの評価には影響しません。

ターゲット列の要件

ターゲット列は次の要件を満たす必要があります。

カテゴリまたは数値のいずれかである必要があります。
カテゴリの場合、2～500 個の固有の値が必要です。
nullable にすることはできません。