画像を分類するモデルが欲しい。でも、学習コードは書きたくない。

AutoML を使えば、ラベル付きの画像を用意するだけで画像分類モデルを学習できます。当記事では、Google 提供のサンプル画像（損傷した車の部位の写真）を使い、Gemini Enterprise Agent Platform（旧 Vertex AI）のマネージドデータセット作成、AutoML によるトレーニング、評価、Endpoint へのデプロイ、HTTPS 経由のオンライン予測までを、自分の Google Cloud プロジェクトで実際に動かした結果とあわせて解説します。

概要

AutoMLで画像分類モデルを作るということ

画像分類モデルを自前で作る場合、モデルアーキテクチャの選定、前処理、学習ループ、ハイパーパラメータの調整、評価と、書くべきコードが多くあります。AutoML はこれらをすべて引き受けます。利用者が用意するのは、**画像と、その画像に付けるラベルの対応表（CSV）**だけです。

学習が終わったモデルは Model Registry に登録され、評価指標と混同行列がコンソールに表示されます。Endpoint にデプロイすれば、他のモデルと同じく REST API で呼び出せます。

当記事は、Google Cloud コンソールと gcloud の基本操作を前提としています。機械学習の知識はほとんど必要ありません。

構築するもの

損傷した車の写真から、損傷している部位を 5 種類に分類する単一ラベル分類モデルを構築します。

ラベル	部位
`bumper`	バンパー
`engine_compartment`	エンジンルーム
`hood`	ボンネット
`lateral`	車体側面
`windshield`	フロントガラス

Google 提供のサンプル画像（gs://car_damage_lab_images）
        │  gcloud storage cp
        ▼
gs://<bucket>/<label>/*.jpg  +  data.csv
        │  インポート（コンソール）
        ▼
マネージド データセット（画像 100 枚、ラベル 5 種類）
        │  AutoML トレーニング（コンソール、8 ノード時間）
        ▼
Model Registry  ──評価──►  PR AUC、適合率 / 再現率、混同行列
        │  gcloud ai endpoints deploy-model（自動リソース）
        ▼
Agent Platform Endpoint  ──POST :predict──►  HTTPS 経由の画像分類

Google Skills のラボとの違い

当記事の題材は、Google Skills のラボ「Identifying Damaged Car Parts with Agent Platform for AutoML Vision Users」です。ラボは一時的なプロジェクトで動作し、制限時間内にトレーニングが終わりません。そのため予測は、別プロジェクトで学習済みのモデルに Cloud Run のプロキシ経由で送る形になっています。

当記事では、自分のプロジェクトでトレーニングを最後まで実行し、ラボでは確認できない部分まで扱います。

	ラボ	当記事
実行環境	一時的なラボ用プロジェクト	自分の Google Cloud プロジェクト
トレーニング	開始のみ（ラボの時間内に終わらない）	完了まで実行
評価	なし	評価指標と混同行列を確認
予測先	Cloud Run の `automl-proxy`（認証なし）	自分の Endpoint（OAuth トークンが必要）
後片付け	「End Lab」で自動削除	リソースを順に削除

事前準備

環境

課金が有効な Google Cloud プロジェクト
Cloud Shell、または gcloud、curl、jq が使えるローカルシェル
2026年9月現在、Agent Platform の API 名は aiplatform.googleapis.com のままであり、CLI も gcloud ai のままです

gcloud services enable aiplatform.googleapis.com storage.googleapis.com

変数の設定

以降の手順ではこれらの変数を繰り返し使用します。最初に設定します。

export PROJECT_ID=$(gcloud config get-value project)
export REGION="us-central1"
export BUCKET="${PROJECT_ID}-car-damage"
export MODEL_NAME="damaged_car_parts"
export ENDPOINT_NAME="damaged_car_parts_endpoint"
export API="https://${REGION}-aiplatform.googleapis.com/v1/projects/${PROJECT_ID}/locations/${REGION}"

gcloud config set ai/region "${REGION}"

MODEL_NAME は、後述するトレーニング時のモデル名と一致させる必要があります。当記事ではコンソールの既定値であるデータセット名 damaged_car_parts をそのまま使用しました。

学習データの準備

サンプル画像を取得する

ラボで使う画像と CSV は、Google が管理する 2 つのバケットにあります。

オブジェクト	内容
`gs://car_damage_lab_images/car_damage_lab_images.zip`	画像一式（約 21 MiB）
`gs://car_damage_lab_images/<label>/<label><n>.jpg`	5 ラベル × 20 枚 = 100 枚
`gs://car_damage_lab_metadata/data.csv`	インポート用 CSV（100 行）

2026年9月の執筆時点では、Google アカウントで認証していればラボ外のプロジェクトからも読み取れました。ただし匿名アクセスは拒否されます（403 AccessDenied）。公開状態は Google 側の判断で変わる可能性があるため、最初に読み取れることを確認してください。

gcloud storage ls gs://car_damage_lab_images/
gcloud storage ls gs://car_damage_lab_metadata/

作業用ディレクトリにダウンロードします。

mkdir -p ~/car-damage && cd ~/car-damage
gcloud storage cp gs://car_damage_lab_images/car_damage_lab_images.zip .
unzip -q car_damage_lab_images.zip && rm car_damage_lab_images.zip
gcloud storage cp gs://car_damage_lab_metadata/data.csv .

data.csvの形式を確認する

ここで CSV の中身を必ず確認してください。ラボの説明からは「画像のパスとラベルの 2 列」と読めますが、実際は 3 列です。

head -3 data.csv
cut -d, -f1 data.csv | sort | uniq -c

TRAIN,gs://car_damage_lab_images/bumper/bumper1.jpg,bumper
TRAIN,gs://car_damage_lab_images/bumper/bumper2.jpg,bumper
TRAIN,gs://car_damage_lab_images/bumper/bumper3.jpg,bumper

1 列目は、その画像を学習・検証・テストのどれに使うかを指定するデータ分割（ML_USE）です。

分割	枚数	用途
`TRAIN`	65	学習
`VALIDATION`	20	学習中の検証
`TEST`	15	学習後の評価（学習には使われない）

分割が CSV で固定されているため、インポート時にランダム分割（既定の 80 / 10 / 10）は行われません。TEST の 15 枚は学習に一切使われないため、後のオンライン予測で「モデルが見たことのない画像」として使えます。

詳細：公式ドキュメント（画像分類のトレーニングデータを準備する）

バケットを作成して画像をアップロードする

データセットと同じリージョンにバケットを作成し、ラベルごとのフォルダ構成のまま画像をアップロードします。

gcloud storage buckets create "gs://${BUCKET}" \
  --location="${REGION}" \
  --uniform-bucket-level-access

gcloud storage cp -r car_damage_lab_images/* "gs://${BUCKET}/"

CSVのバケット名を書き換える

CSV 内のパスは Google 側のバケットを指しています。これを自分のバケットに置き換えてからアップロードします。

sed -i.bak -e "s/car_damage_lab_images/${BUCKET}/g" ./data.csv && rm data.csv.bak
head -3 data.csv
gcloud storage cp data.csv "gs://${BUCKET}/"

ラボの手順は sed -i -e ですが、これは GNU sed（Cloud Shell）の書き方で、macOS の sed では失敗します。-i.bak はどちらでも動作します。

画像はバケットのルートにラベルごとのフォルダとしてアップロードしたため、置換後の gs://<bucket>/bumper/… は実際の配置と一致します。

図1 Cloud Storage のバケット詳細。ラベルごとの 5 フォルダ（bumper/、engine_compartment/、hood/、lateral/、windshield/）と data.csv が同じ階層に並ぶ。赤枠：アップロードしたフォルダと CSV

マネージドデータセットの作成

データセットの作成は、gcloud にコマンドが用意されていないため、コンソールで行います。

データセットを作成する

コンソールで Agent Platform → データセット → 作成と進み、以下のとおり設定します。

データセット名：damaged_car_parts
データタイプ：画像タブ → 単一ラベル分類
リージョン：us-central1

図2 「データセットを作成」画面。画像タブで目的を選び、リージョンを指定する。赤枠：単一ラベル分類（1 枚の画像に 1 つのラベルを付ける目的）

CSVをインポートする

作成後に表示されるインポート画面で、インポートファイルを Cloud Storage から選択を選び、アップロードした data.csv を指定します。

データ分割はデフォルトのままにしてください。CSV の 1 列目で分割が指定されているため、デフォルトの設定でその指定が使われます。

図3 インポート画面。インポートファイルを Cloud Storage から選択し、data.csv を指定する。データ分割はデフォルトのまま。赤枠：パスの左に緑のチェックが付けば、ファイルが正しく選択されている

インポートには数分から十数分かかり、完了するとメールが届きます。

詳細：公式ドキュメント（画像分類用のデータセットを作成する）

インポートした画像を確認する

参照タブで、ラベルごとの枚数と、データ分割ごとの枚数を確認します。すべて 100 枚、ラベル付き 100 枚、トレーニング 65 / 検証 20 / テスト 15 と、CSV の内容どおりにインポートされていることがわかります。

図4 参照タブ。左上に全体の枚数（100）とデータ分割ごとの枚数（トレーニング 65 / 検証 20 / テスト 15）、左下にラベルごとの枚数が表示される。赤枠：フィルタで選択した bumper（20 枚）。右側にはそのラベルの画像だけが表示される

分析タブでは、ラベルごとの画像数が棒グラフで表示されます。

図5 分析タブ。上部には「少なくとも 100 個の画像を各ラベルに割り当てることをおすすめします」という警告が表示される。赤枠：ラベルごとの画像数。5 ラベルとも 20 枚で、推奨値の 5 分の 1

この画面の上部には、「最適な結果を得るには、少なくとも 100 個の画像を各ラベルに割り当てることをおすすめします」という警告が表示されます。当記事のデータは各ラベル 20 枚であり、推奨値の 5 分の 1 です。この点は評価結果にそのまま表れます。

AutoMLによるトレーニング

トレーニングを開始する

データセット画面の 新しいモデルのトレーニングから、以下のとおり進めます。

画面	設定
トレーニング方法	AutoML を選択。モデルを使用する場所は Cloud
モデルの詳細	新しいモデル。モデル名の既定値はデータセット名（`damaged_car_parts`）
トレーニングオプション	デフォルト
コンピューティングと料金	予算 8 ノード時間

Cloud を選択する点に注意してください。Edge はオンデバイス向けにエクスポートするモデルであり、当記事のように Endpoint にデプロイしてオンライン予測を行う用途には使えません。

図6 「Train new model」のトレーニング方法。データセットと目的（画像分類（単一ラベル））は自動で入力される。赤枠：AutoML。モデルを使用する場所は、Endpoint にデプロイするため Cloud を選択する

予算の画面には「8 node hours のみトレーニングできます」と表示され、このモデルタイプでは 8 以外の値は指定できませんでした。

図7 コンピューティングと料金。「8 node hours のみトレーニングできます」と表示され、完了予定は 1 時間。赤枠：予算（最大ノード時間）の 8

詳細：公式ドキュメント（AutoML 画像分類モデルをトレーニングする）

トレーニングの所要時間

画面の完了予定は 1 時間でしたが、実際には 1 時間 48 分かかりました。画像 100 枚という小さなデータでもこの程度かかるため、作業の予定は余裕を持って組んでください。トレーニングが完了するとメールが届きます。

図8 トレーニングパイプラインの一覧。作成日 3:08:40、終了日時 4:57:42。赤枠：ステータスの「完了」と、Duration の 1 時間 48 分（画面の完了予定 1 時間より長い）

以降の手順で使うモデル ID を取得します。

export MODEL_ID=$(gcloud ai models list \
  --region="${REGION}" \
  --filter="displayName=${MODEL_NAME}" \
  --format="value(name.basename())")
echo "${MODEL_ID}"

出力が空の場合は、MODEL_NAME がトレーニング時のモデル名と一致しているかを確認してください。

モデルの評価

Model Registry → damaged_car_parts → バージョン 1 → 評価タブを開くと、評価結果の一覧が表示されます。評価には、学習に使われていない TEST の 15 枚が使われます。

図9 モデルの評価タブ（ポイントワイズ評価の一覧）。評価には TEST の 15 枚が使われる。赤枠：PR AUC 0.946、ログ損失 0.139、しきい値 0.5 での適合率 90%・再現率 90%

指標	値
PR AUC	0.946
ログ損失	0.139
適合率（しきい値 0.5）	90%
再現率（しきい値 0.5）	90%

評価名（untitled_…）をクリックすると、ラベルごとの結果と混同行列が表示されます。

図10 評価の詳細。左にラベルごとの PR AUC（hood のみ 0.833、他は 1）、右に信頼度のしきい値 0.5 での混同行列が表示される。赤枠：正解 hood に対して bumper と予測された割合 50%。他のラベルはすべて対角線上（100%）

lateral、bumper、engine_compartment、windshield の 4 ラベルは PR AUC が 1 で、すべて正しく分類されています。一方、hood（ボンネット）は PR AUC 0.833 で、一部が bumper と予測されています。ボンネットとバンパーはどちらも車の前部にあり、写真の構図が似ます。各ラベル 20 枚という少ないデータでは、この 2 つを区別しきれていないと考えられます。

なお、テストデータは 15 枚、1 ラベルあたり 3 枚しかありません。1 枚の誤りで数値が大きく動くため、90% という値はモデルの実力を示す確かな数値ではなく、傾向を見るための目安として扱ってください。

詳細：公式ドキュメント（AutoML 画像分類モデルを評価する）

Endpointへのデプロイ

コンソールからのデプロイは失敗した

モデルの デプロイとテストタブから エンドポイントへのデプロイを選び、以下のとおり設定しました。

新しいエンドポイントを作成：damaged_car_parts_endpoint
アクセス：標準（REST API で利用。IAM による認証は必要）
専用 DNS：無効
トラフィック分割：100
レプリカの最小数・最大数：1
マシンタイプ：n1-standard-2（既定値）

図11 エンドポイントへのデプロイの「モデル設定」。マシンタイプは既定の n1-standard-2、アクセラレータなし。赤枠：レプリカの最小数・最大数をどちらも 1 にして、課金をノード 1 台分に抑える

ところが、デプロイは以下のエラーで失敗しました。

図12 コンソールからのデプロイ時に表示されたエラー。コンソールは専用リソース（マシンタイプ指定）でデプロイしようとするため、このプロジェクトでは失敗した。赤枠：エラーメッセージ「Deploying AutoML Vision models with dedicated resources is not enabled for this project.」

Deploying AutoML Vision models with dedicated resources is not enabled for this project.

コンソールはマシンタイプを指定した **専用リソース（dedicated resources）**でデプロイしようとしますが、このプロジェクトでは AutoML Vision モデルを専用リソースでデプロイすることが許可されていませんでした。モデルが対応するデプロイ方式は、以下のコマンドで確認できます。

gcloud ai models describe "${MODEL_ID}" --region="${REGION}" \
  --format="yaml(supportedDeploymentResourcesTypes)"

supportedDeploymentResourcesTypes:
- AUTOMATIC_RESOURCES
- DEDICATED_RESOURCES

このモデルは **自動リソース（automatic resources）**にも対応しているため、そちらでデプロイします。

注意点として、デプロイに失敗しても Endpoint 自体は作成されます。再試行するたびに、同じ名前の空の Endpoint が増えていきます。空の Endpoint に費用は発生しませんが、名前で ID を取得するコマンドが複数の ID を返すようになるため、不要なものは削除してください。

gcloud ai endpoints list --region="${REGION}" \
  --filter="displayName=${ENDPOINT_NAME}" \
  --format="table(name.basename(),deployedModels[].id)"

CLIで自動リソースを指定してデプロイする

Endpoint が 1 つだけ残っている状態で ID を取得し、gcloud ai endpoints deploy-model でデプロイします。--machine-type を指定しないことで、自動リソースが使われます。

export ENDPOINT_ID=$(gcloud ai endpoints list \
  --region="${REGION}" \
  --filter="displayName=${ENDPOINT_NAME}" \
  --format="value(name.basename())")

gcloud ai endpoints deploy-model "${ENDPOINT_ID}" \
  --region="${REGION}" \
  --model="${MODEL_ID}" \
  --display-name="${MODEL_NAME}" \
  --min-replica-count=1 \
  --max-replica-count=1 \
  --traffic-split=0=100

Endpoint がまだない場合は、先に gcloud ai endpoints create --region="${REGION}" --display-name="${ENDPOINT_NAME}" で作成してください。

コマンドはデプロイの完了まで待機します。完了後、デプロイ済みモデルの設定を確認します。

gcloud ai endpoints describe "${ENDPOINT_ID}" --region="${REGION}" \
  --format=json | jq '.deployedModels[] | {id, automaticResources, dedicatedResources}'

automaticResources に minReplicaCount: 1、maxReplicaCount: 1 が設定され、dedicatedResources が null であれば成功です。

図13 CLI（自動リソース）でデプロイした後の「デプロイとテスト」タブ。モニタリングは無効。赤枠：エンドポイントのステータス「アクティブ」と、デプロイ済みモデル数 1

この時点から、ノード 1 台分の課金が時間単位で継続します。予測の確認が終わったら、後述のクリーンアップで必ず undeploy してください。

詳細：公式ドキュメント（モデルをエンドポイントにデプロイする）

オンライン予測の実行

コンソールでテストする

デプロイとテストタブの 画像のアップロードから、画像を 1 枚アップロードすると、その場で予測結果が表示されます。バンパーの画像を送ったところ、bumper を信頼度 0.955 で予測しました。他のラベルはいずれも 0.03 以下です。

図14 「デプロイとテスト」タブのモデルのテスト。アップロードしたバンパーの画像に対し、右側にラベルごとの信頼度が表示される。赤枠：bumper 0.955（他のラベルはいずれも 0.03 以下）

REST APIで呼び出す

アプリケーションから呼び出す場合は、画像を Base64 に変換し、instances[].content に入れて送ります。ラボでは Cloud Run のプロキシに認証なしで送っていましたが、自分の Endpoint を直接呼び出す場合は OAuth のアクセストークンが必要です。

IMG="car_damage_lab_images/$(grep '^TEST,' data.csv | grep '/hood/' | head -1 | cut -d, -f2 | sed "s#gs://${BUCKET}/##")"

jq -n --arg c "$(base64 -w0 "${IMG}")" \
  '{instances: [{content: $c}], parameters: {confidenceThreshold: 0.0, maxPredictions: 5}}' \
  > payload.json

curl -s -X POST \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  "${API}/endpoints/${ENDPOINT_ID}:predict" \
  -d @payload.json | jq .

base64 -w0 は Cloud Shell（GNU coreutils）の書き方です。macOS では base64 -i "${IMG}" | tr -d '\n' を使用してください。

{
  "predictions": [
    {
      "ids": ["xxxxxxxxxxxxxxxxxxx", "..."],
      "displayNames": ["hood", "lateral", "engine_compartment", "bumper", "windshield"],
      "confidences": [0.53, 0.0, 0.0, 0.0, 0.0]
    }
  ],
  "deployedModelId": "xxxxxxxxxxxxxxxxxxx",
  "model": "projects/xxxxxxxxxxxx/locations/us-central1/models/xxxxxxxxxxxxxxxxxxx",
  "modelDisplayName": "damaged_car_parts",
  "modelVersionId": "1"
}

displayNames と confidences は位置で対応します。予測されたラベルは、confidences が最大の位置にある displayNames です。

詳細：公式ドキュメント（AutoML 画像分類モデルから予測を取得する）

テスト画像15枚をまとめて予測する

TEST の 15 枚すべてを送り、正解ラベルと予測ラベルを並べます。

grep '^TEST,' data.csv | tr -d '\r' | while IFS=, read -r split uri label; do
  f="car_damage_lab_images/${uri#gs://${BUCKET}/}"
  jq -n --arg c "$(base64 -w0 "${f}")" \
    '{instances: [{content: $c}], parameters: {confidenceThreshold: 0.0, maxPredictions: 5}}' > payload.json
  pred=$(curl -s -X POST \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json" \
    "${API}/endpoints/${ENDPOINT_ID}:predict" -d @payload.json \
    | jq -r '.predictions[0] | [.displayNames, .confidences] | transpose | max_by(.[1]) | "\(.[0]) \(.[1])"')
  echo "${label} ${f##*/} ${pred}"
done

このコマンドには 2 つの工夫があります。理由は落とし穴の節で説明します。

tr -d '\r' で改行コードの \r を除去している
maxPredictions: 5 で全ラベルのスコアを受け取り、jq で最大値を選んでいる

結果は以下のとおりです。

正解ラベル	結果	信頼度
`bumper`	3 / 3 正解	0.82〜0.94
`engine_compartment`	3 / 3 正解	0.77〜0.90
`hood`	3 / 3 正解	0.43〜0.53
`lateral`	3 / 3 正解	0.69〜0.99
`windshield`	3 / 3 正解	0.97〜0.98

最も信頼度が高いラベルを予測とみなせば、15 枚すべて正解です。ただし hood の信頼度は 0.43〜0.53 と低く、3 枚中 2 枚は 0.5 を下回っています。評価画面の混同行列で hood だけに誤りがあったことと一致します。しきい値 0.5 で「確信のある予測」だけを採用する運用であれば、hood の画像の多くは判定保留になります。

トークンなしでは呼び出せない

アクセストークンを付けずに同じリクエストを送ると、401 が返ります。

curl -s -o /dev/null -w "%{http_code}\n" -X POST \
  -H "Content-Type: application/json" \
  "${API}/endpoints/${ENDPOINT_ID}:predict" -d @payload.json

アクセスを標準にした Endpoint は、インターネットから到達可能ですが、IAM の認証を通らないリクエストは拒否されます。ラボのプロキシは学習用に認証なしで公開されていましたが、本番環境で同じ構成にすると、誰でもモデルを呼び出せ、その費用を負担することになります。

落とし穴

サンプル画像は匿名では読めない

ラボ用のバケットは、執筆時点では Google アカウントで認証していれば読み取れましたが、匿名アクセスは 403 になります。ブラウザや認証なしの curl で確認すると「アクセスできない」と誤解しやすい点に注意してください。

data.csvは3列で、改行コードはCRLF

data.csv は ML_USE,画像パス,ラベル の 3 列です。さらに改行コードが CRLF（\r\n）で、最終行には改行がありません。インポートには影響しませんが、シェルで 1 行ずつ読むとラベルの末尾に \r が残ります。echo で表示すると \r によってカーソルが行頭に戻り、ラベルが上書きされて空欄に見えます。tr -d '\r' で除去してください。

maxPredictions: 1 は最も確からしいラベルを返すとは限らない

parameters.maxPredictions を 1 にすると、最も信頼度の高いラベルが 1 つ返ると期待するかもしれません。筆者の環境では、15 枚すべてが hood と低い信頼度で返りました。上位 1 件ではなく、ラベルの並び順で先頭の 1 件が返っていたと考えられます。予測ラベルを取り出す場合は、maxPredictions をラベル数以上（当記事では 5）にして全スコアを受け取り、クライアント側で最大値を選んでください。

コンソールからのデプロイは専用リソースになる

コンソールのデプロイ画面はマシンタイプを指定する専用リソースでデプロイします。プロジェクトによっては、AutoML Vision モデルの専用リソースでのデプロイが許可されておらず、Deploying AutoML Vision models with dedicated resources is not enabled for this project. で失敗します。gcloud ai endpoints deploy-model で --machine-type を指定せずに実行すると、自動リソースでデプロイできます。

モデル名の既定値はデータセット名

トレーニング時のモデル名は、既定でデータセット名が入力されています。ラボの手順どおりに damaged_car_parts_model と入力したつもりでも、既定値のまま進めると damaged_car_parts になります。名前でモデル ID を取得するスクリプトは、ここで空の結果を返します。

トレーニング時間は見積もりより長い

完了予定 1 時間に対し、実際は 1 時間 48 分でした。予算の 8 ノード時間は上限であり、所要時間の見積もりではありません。

テストデータ15枚の評価は粗い

1 ラベルあたりのテスト画像は 3 枚です。1 枚の誤りで、そのラベルの正解率は約 33 ポイント動きます。評価指標は傾向の把握に使い、実運用に向けては、コンソールの警告どおりラベルあたり 100 枚以上を目安にデータを増やしてください。

デプロイ済みモデルは課金され続ける

--min-replica-count=1 は、ノードが常時 1 台稼働することを意味します。リクエストの有無にかかわらず、ノード時間単位で課金されます。これがこのワークフロー全体で継続的に発生する唯一の費用です。トレーニングは完了した時点で課金が止まり、100 枚程度の画像の保存費用は無視できる水準です。

詳細：公式ドキュメント（Vertex AI の料金）

クリーンアップ

継続的な費用が発生するのはデプロイ済みモデルだけですが、依存関係によるエラーを避けるため、順序に沿って削除します。

DEPLOYED_ID=$(gcloud ai endpoints describe "${ENDPOINT_ID}" --region="${REGION}" \
  --format="value(deployedModels[0].id)")

gcloud ai endpoints undeploy-model "${ENDPOINT_ID}" \
  --region="${REGION}" --deployed-model-id="${DEPLOYED_ID}"

gcloud ai endpoints delete "${ENDPOINT_ID}" --region="${REGION}" --quiet
gcloud ai models delete "${MODEL_ID}" --region="${REGION}" --quiet

課金が止まるのは undeploy-model の時点です。デプロイ済みモデルを持たない Endpoint には費用が発生しません。作業を中断して後日再開する場合は、undeploy だけ実行して残りは保持しておくとよいです。再開時は deploy-model を 1 回実行するだけで済み、トレーニングをやり直す必要はありません。

マネージドデータセットには gcloud の削除コマンドがないため、REST API で削除します。

DATASET_ID=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  "${API}/datasets" \
  | jq -r '.datasets[] | select(.displayName=="damaged_car_parts") | .name | split("/") | last')

curl -s -X DELETE \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  "${API}/datasets/${DATASET_ID}"

最後にバケットを削除します。

gcloud storage rm -r "gs://${BUCKET}"

インポート時、Agent Platform は画像を cloud-ai-platform- で始まる名前のバケットにもコピーします。インポート画面の「インポートファイル内で参照された画像は、処理されて新しい Cloud Storage バケットに保存されます」という表示がこれです。他の用途で使っていなければ、このバケットも削除してください。

gcloud storage ls | grep cloud-ai-platform-

画像とラベルの対応表さえあれば、学習コードなしで画像分類モデルを作り、HTTPS で呼び出せる。 一方で、モデルの品質を決めるのは最終的にデータの量と質です。評価画面と混同行列を必ず確認し、弱いラベルがどこにあるかを把握した上で運用に進んでください。