Azure Custom Vision で「オブジェクト検出のトレーニングが終わらない」「ポータルから停止できない」という相談が相次いでいます。本記事では実際の現象と影響、即時に取るべき行動、API からのキャンセル手順、コストの見え方、復旧までの代替策、そして再発防止のベストプラクティスを、現場でそのまま使える運用手順として整理しました。
Azure Custom Vision のトレーニングが停止したまま完了しない問題の全体像
以下は確認されている代表的な症状と条件です。いずれもユーザー操作のみでの即時復旧が困難であるため、適切なエスカレーションと影響抑制が重要です。
症状
- 6 時間の予定で開始したトレーニングが 15 時間以上経過しても終了しない。
- Azure ポータルの Custom Vision プロジェクト画面で「停止」「再起動」操作が効かない、または UI が固まったまま。
影響範囲
- 複数のリージョン（例：West Europe、Central India、Japan East、South Central US など）で発生。
- オブジェクト検出（Object Detection）のトレーニングに偏って発生し、画像分類（Image Classification）は正常動作という報告が多い。
よくある懸念
- 作業（実験・評価）がブロックされるため、プロジェクト全体のスケジュールが遅延。
- ジョブが走り続けているように見えるが、課金（トレーニング時間課金）が継続しているのか不明でコスト増が心配。
要点（先に結論）
- 本事象はサービス側のインシデント（Custom Vision のバックエンドで広範な障害や輻輳が生じている状態）に起因している可能性が高い。
- ユーザー側でできるのは影響を見える化し、Azure サポートへ適切な情報で迅速にエスカレーションし、復旧までの間はコストや代替フローを管理すること。
なぜ「オブジェクト検出」で詰まりやすいのか（技術的背景）
Custom Vision のオブジェクト検出は、画像分類よりも計算負荷が高く、学習パイプラインも複雑です。高解像度画像、アノテーション数、データ水増し（augmentation）、バックボーン切替、マルチスケール学習、評価時の NMS（非極大抑制）など、トレーニングと評価の両方で GPU リソースを長時間占有しやすい設計です。そのため、以下の条件が重なるとキュー輻輳や実行ノードの枯渇によりジョブが開始できない／完了判定に到達できないといった事象が起きやすくなります。
- 同一リージョンでピーク時間帯にジョブが集中する（他テナントの影響含む）。
- 1 回のイテレーションで大量の画像・ラベルを投入し、トレーニング時間が極端に長い。
- 同時に複数イテレーションを走らせ、内部スロットを使い切っている。
- バックエンドで障害（ノード不調、ストレージ／キューの異常、スケジューラ不具合）が発生。
結果として、ポータル UI 側の状態更新が止まる（実際のジョブ状態と UI 表示が乖離する）、「停止」操作が反映されない、といった体感になります。
まずやるべき即時アクション（優先度順）
次の表は、障害時に「いま」取るべき行動と、併せて確認すべきポイントをまとめたものです。運用 Runbook としてそのままお使いください。
| 優先 | 対処内容 | 補足 |
|---|---|---|
| ★ | Azure サポート チケットを発行 | 自身のサブスクリプションから「ヘルプ + サポート」→「新しいサポート要求」。 チケット本文に以下を必ず記載： ・リソース名 / Project ID / サブスクリプション ID ・リージョン（例：Japan East） ・トレーニング種別：Object Detection ・開始時刻（UTC 併記）と現在の経過時間 ・Iteration ID（わかれば）/ 学習画像枚数 / アノテーション数 ・ポータル操作（停止・再開）が不可能な旨、発生回数 ・ビジネス影響（期限、影響ユーザー数、代替不可度合い） 情報が揃っているとエスカレーションと進捗報告が早くなります。 |
| ★ | Service Health を継続監視 | Azure ポータル → 「Service Health」→「アクティブなイベント」→ Cognitive Services / Custom Vision を確認。 影響リージョン、影響期間、暫定対応、解消見込み時刻の有無を追跡。 アラートを「プッシュ通知（メール/SMS/Teams）」で受ける設定を推奨。 |
| ☆ | コスト監視（Cost Analysis） | 課金は原則「トレーニング時間」単位。 進行中ジョブが課金計上されているか、Cost Management + Billing → Cost analysisで サービス名（Cognitive Services / Custom Vision）、リソース単位で絞り込み。 異常計上が疑われる場合はチケットでクレジット（払い戻し）相談も可能です。 |
| ☆ | API からのキャンセル（イテレーション削除）を試行 | ポータル UI が効かなくても、Training API の DELETE /iterations/{iterationId} で未完了のイテレーションを削除できる場合があります（後述の手順参照）。 |
| △ | 一時的に「画像分類」で代替検証 | 画像分類は正常という報告が多いため、要件が許す範囲で分類モデルに切替え、 ラベル設計やデータ品質の検証だけでも先行することを推奨。 |
| △ | オフライン学習（Azure ML / YOLOv8 / Detectron2 等）へ切替検討 | クリティカルな PoC 期限が迫る場合、データをエクスポートして一時的に他ツールで学習。 後日 Custom Vision に戻すハイブリッド運用も現実的です。 |
サポートチケット用テンプレート（コピペ推奨）
[影響]
・オブジェクト検出のトレーニングが 15 時間以上完了せず、ポータルから停止不可
・実験/納期に影響（期日：YYYY-MM-DD）、代替不可/限定的
[環境]
・サブスクリプション ID：xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
・リソースグループ：rg-xxx
・Custom Vision Project ID：xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
・リージョン：Japan East
・トレーニング種別：Object Detection
[事象詳細]
・開始時刻（UTC）：2025-11-10T01:00:00Z
・経過時間：15h+
・学習画像：4,200 枚 / アノテーション：18,300
・Iteration ID（不明なら「不明」と記載可）
・ポータル操作（停止/再開）：反応なし
・同時実行：2 ジョブ
[期待]
・インシデントの有無、復旧見込み
・ジョブの強制キャンセル/クリーンアップ
・課金影響の確認と必要時のクレジット API からキャンセル／状態確認を行う（UI が固まっている場合のワークアラウンド）
Custom Vision の Training API は OAuth ベアラーではなく、Training-Key ヘッダーで認証します。以下の手順でイテレーション（進行中の学習）を確認し、必要に応じて削除（実質的なキャンセル）を試みます。
前提情報
- エンドポイント：
https://<region>.api.cognitive.microsoft.com/customvision/v3.3/training - Training Key（ポータルの「Keys and Endpoint」で確認）
- Project ID / Iteration ID
1) イテレーション一覧を取得
# 例: 直近イテレーションの状態を見て、"Training" などのステータスで固まっていないか確認
curl -X GET \
"https://<region>.api.cognitive.microsoft.com/customvision/v3.3/training/projects/<projectId>/iterations" \
-H "Training-Key: <your-training-key>"
レスポンスには各イテレーションの status（例：Training, Completed, Failed）と id が含まれます。
2) 問題のイテレーションを削除（キャンセル相当）
# 注意：DELETE はイテレーション自体を削除します。必要なら事前にエクスポートやメタ情報の控えを。
curl -X DELETE \
"https://<region>.api.cognitive.microsoft.com/customvision/v3.3/training/projects/<projectId>/iterations/<iterationId>" \
-H "Training-Key: <your-training-key>"
削除が成功すると、そのイテレーションはポータルにも表示されなくなります。UI が固まっているだけでバックエンドは生きている場合、この操作で「停止できない」状態から抜け出せることがあります。
3) 個別イテレーションの状態を再確認
curl -X GET \
"https://<region>.api.cognitive.microsoft.com/customvision/v3.3/training/projects/<projectId>/iterations/<iterationId>" \
-H "Training-Key: <your-training-key>"
PowerShell 例
$endpoint = "https://<region>.api.cognitive.microsoft.com/customvision/v3.3/training"
$projectId = "<projectId>"
$iterationId = "<iterationId>"
$trainingKey = "<your-training-key>"
$headers = @{ "Training-Key" = $trainingKey }
# 状態確認
Invoke-RestMethod -Method GET -Uri "$endpoint/projects/$projectId/iterations" -Headers $headers
# キャンセル（イテレーション削除）
Invoke-RestMethod -Method DELETE -Uri "$endpoint/projects/$projectId/iterations/$iterationId" -Headers $headers Python 例
import requests
endpoint = "https://.api.cognitive.microsoft.com/customvision/v3.3/training"
project_id = ""
iteration_id = ""
key = ""
headers = {"Training-Key": key}
# 状態確認
r = requests.get(f"{endpoint}/projects/{project_id}/iterations", headers=headers)
r.raise_for_status()
print(r.json())
# キャンセル（イテレーション削除）
d = requests.delete(f"{endpoint}/projects/{project_id}/iterations/{iteration_id}", headers=headers)
print(d.status_code) 注意点
- DELETE は不可逆です。結果やメトリクスを後から参照したい場合は、削除前にスクリーンショットや情報の控えを残す運用を。
- API レベルでも削除できない場合はバックエンド障害の可能性が高いため、サポートに Request-Id / Correlation-Id（応答ヘッダに出る場合）も添えて報告すると調査が進みやすくなります。
コスト（課金）影響の把握と抑制
Custom Vision の課金は基本的に「トレーニング時間」と「推論（予測）トランザクション」に基づきます。障害時の「止まらないジョブ」が実際に時間計上されるかはケースにより異なるため、次の手順で可視化してください。
コストの可視化手順
- Azure ポータル → Cost Management + Billing → Cost analysis。
- 「スコープ」を問題のサブスクリプション／リソースグループに合わせる。
- フィルターで「サービス = Cognitive Services」または「メーター/メーターカテゴリー」に Custom Vision 関連が含まれるものを選択。
- 期間は「過去 7 日」「過去 30 日」など、障害期間をカバーするよう設定。
- 異常にスパイクしている日付があれば、その日付のブレイクダウン（リソース、メーター）を確認。
抑制のテクニック
- 同時実行イテレーション数を 1～2 に制限し、長大ジョブは分割。
- 「クイックトレーニング」で効果検証 → 設定を確定後にロングランを回す。
- 障害発生中は「画像分類」に切替えて検証だけ先行（要求が許せば）。
- サポートチケットで請求影響の有無とクレジット可否を必ず確認。
よくある誤解
- UI が固まっているだけで課金は止まっているとは限りません。必ず Cost analysis で裏取りする。
- 「停止」ボタンが効かないからといってブラウザを閉じてもバックエンドジョブは止まりません。API でイテレーション削除を試すか、サポートへ強制停止を依頼します。
復旧までの代替フロー（作業を止めないために）
分類モデルでの暫定検証
要件が「検出」必須でない工程（ラベル設計の妥当性、データ水増しの有効性、クラス間分離の可否など）は、画像分類で代替できます。精度指標（Precision/Recall/Confusion）を先に詰め、復旧後に検出へ移行するとスムーズです。
オフライン学習（Azure ML など）への一時退避
- データセットをエクスポート（画像・アノテーション）。
- Azure Machine Learning 上で YOLOv8/Detectron2/SSD などを実行。
- 学習済みモデルを一時的に別ホスティング（AML Online Endpoint、AKS、ローカル）で提供。
- サービス復旧後、Custom Vision に戻して再評価・MLOps パイプラインへ収斂。
データエクスポートのヒント
Custom Vision から API で学習画像をページング取得します（例）。
# タグ付き画像をページングで取得（必要に応じて skip/take を調整）
curl -X GET \
"https://<region>.api.cognitive.microsoft.com/customvision/v3.3/training/projects/<projectId>/images/tagged?take=256&skip=0" \
-H "Training-Key: <your-training-key>"
アノテーション（バウンディングボックス）は画像メタに含まれるため、YOLO/COCO 等の形式に変換する小スクリプトを用意しておくと移行が容易です。
再発防止のためのベストプラクティス
ジョブ設計
- クイックトレーニング → 段階的に拡張：1～2 時間で終わる設定から始め、設定が固まってからロングランに移行。
- イテレーション分割：データ増分ごとにイテレーションを切る。巨大データを一度に投げない。
- 同時実行の抑制：1 プロジェクトあたりの並列ジョブを抑えて輻輳を回避。
- リージョン分散：日本東と東南アジアなど、地理的に近い代替リージョンを用意して切替可能に。
監視とアラート
- Azure Monitor でアクティビティログ（イテレーション作成、削除、失敗）にアラート。
- Service Health アラート：Cognitive Services / Custom Vision に対してイベント通知を設定。
- 長時間実行の検知：Logic Apps / Functions で「開始から N 時間超」を検知して通知。
データ品質
- 極端に大きい画像は事前にリサイズ。アスペクト比を揃え、学習時間を短縮。
- アノテーションの一貫性をレビュー（重複/誤ラベル/過密ラベルを除去）。
- クラスバランスを整え、過学習や学習不安定による無駄なリトライを抑制。
運用 Runbook：障害検知から収束まで
| フェーズ | アクション | 成果物/判定 |
|---|---|---|
| 検知 | Service Health で Custom Vision のイベント検知。Cost analysis アラートも参照。 | 障害発生の有無、影響リージョン、開始時刻 |
| 初動 | チケット起票、事実情報を収集（Project/Iteration/開始時刻/画像枚数）。 | サポートのケース番号、SLA/見込み取得 |
| 緩和 | API からイテレーション削除を試行。分類モデルやオフライン学習に切替。 | ジョブ停止の成否、代替フローの可動化 |
| 監視 | Service Health 更新を追跡、影響の収束を確認。 | 復旧宣言の確認、再発警戒期間の設定 |
| 事後 | コスト精査、クレジット相談、原因と再発防止をレトロスペクティブに文書化。 | ポストモーテム、SOP 更新、アラート強化 |
トラブルシューティングのチェックリスト
- 開始時刻（UTC 併記）と経過時間を記録したか。
- Project ID / Iteration ID を控えたか。
- 影響リージョンを特定したか（複数リージョンなら列挙）。
- 学習画像枚数・アノテーション数・同時実行数を把握したか。
- Service Health で関連イベントを確認したか。
- Cost analysis で当該期間のコストを抽出したか。
- API でイテレーション削除を試したか（結果・応答コードを記録）。
- 代替フロー（分類/オフライン）を起動したか。
- サポートチケットに事実情報をすべて記載したか。
FAQ（よくある質問）
Q. UI の「停止」ボタンが効かないのですが、待てば止まりますか？
A. 期待できません。UI とバックエンドの状態が乖離している可能性が高いので、API によるイテレーション削除を試すか、サポートに強制停止を依頼してください。
Q. 課金は続いていますか？
A. ケースによります。Cost analysis で実データを確認し、異常があればチケットで調整を依頼してください。
Q. なぜ画像分類は動くのに、検出だけ止まるのですか？
A. 検出は分類より計算負荷とパイプライン工程が多く、GPU スロットの枯渇・キュー滞留・評価工程の長期化で詰まりやすい設計的特性があります。
Q. 別リージョンに移せば解決しますか？
A. リージョン固有の障害なら有効です。ただしデータ移行やコンプライアンス、遅延を考慮し、恒久的な切替か一時退避かを判断してください。
Q. DELETE でキャンセルできませんでした
A. バックエンド障害で削除も失敗する場合があります。日時・応答コード・Request-Id を添えてチケットにエスカレーションし、サービス側のクリーンアップを依頼してください。
ケーススタディ：影響最小化の実践例
ある PoC チームでは、Japan East の検出トレーニングが 12 時間停止。以下の手順で 1 営業日以内に影響を局所化しました。
- 開始 2 時間で異常を検知（独自アラート）。Service Health を確認。
- 即時にチケット起票。Project/Iteration/画像枚数/同時実行/影響度を詳細に記載。
- API から該当イテレーションを削除。UI でも消えることを確認。
- 分類モデルでデータ品質検証を先行。オフラインで YOLOv8 を回し暫定モデルを提供。
- Cost analysis のスパイクを抽出し、チケットに添付。後日クレジット調整。
- 復旧後、ロングランはイテレーションを 3 分割し、夜間に分散実行。アラートを強化。
ポイントは早期の事実収集・エスカレーション・並行代替フローです。待ち続けるより総工期を短縮できます。
セキュリティと運用ガバナンス上の注意
- Training Key の取り扱いは厳重に。ローテーション手順書を整備し、CI/CD のシークレットに保管。
- Activity Log で誰がいつイテレーションを作成・削除したかを追跡できるよう権限と監査を整える。
- 権限は最小特権（Least Privilege）。運用アカウントは必要な操作だけ許可。
障害時に役立つメトリクスと記録フォーマット
| 項目 | 例 | 備考 |
|---|---|---|
| プロジェクト | cv-od-retail-2025 | 命名規則で領域/用途を識別 |
| Iteration ID | xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | API/ポータルで取得 |
| 開始時刻 | 2025-11-10T01:00:00Z | UTC とローカルの両方で記録 |
| 経過時間 | 15h 20m | 閾値超過で通知 |
| 画像数/アノテーション | 4,200 / 18,300 | 増分管理に活用 |
| 同時実行数 | 2 | 輻輳の判断材料 |
| コスト | 当日 $XX（推定） | Cost analysis の数値 |
| Service Health | 影響リージョン: Japan East | イベント ID/更新時刻も記録 |
まとめ：いま取るべきこと、明日から変えること
いま：チケットを切る → Service Health 監視 → Cost analysis で裏取り → API でイテレーション削除を試行 → 代替フローを可動化。
明日から：クイックトレーニング→段階拡張、イテレーション分割、同時実行抑制、リージョン分散、アラート強化、データ品質改善。
本事象はユーザー操作だけでは解決できないサービス側のインシデントである可能性が高く、「早期のエスカレーション」と「影響最小化の運用」が成否を分けます。この記事の手順とテンプレートをそのまま Runbook 化し、次の障害で秒単位に動ける体制を整備してください。
付録：ポータル操作のナビゲーション（リンク不要版）
Service Health の確認
- Azure ポータルにサインイン。
- 左メニューで「Service Health」。
- 「アクティブなイベント」→「サービス」から「Cognitive Services / Custom Vision」を選択。
- 影響リージョン・影響開始時刻・最新更新時刻・回避策の有無・解消見込みを確認。
Cost analysis の絞り込み
- Azure ポータル → 「Cost Management + Billing」。
- 「Cost analysis」→ スコープを該当サブスクリプションに設定。
- 「フィルター」で「サービス」「リソース」「メーター」などを順にドリルダウン。
- 日付範囲を障害期間に合わせ、日次グラフのスパイクを特定。
付録：チーム内連絡テンプレート（Slack / Teams）
[通知] Custom Vision（Object Detection）トレーニング停止
・プロジェクト：cv-od-retail-2025（Japan East）
・開始：2025-11-10 10:00 JST（= 01:00 UTC）
・経過：15h
・影響：学習停止、評価進捗遅延（期限 11/12）
・対応：チケット起票、Service Health 監視、Cost analysis、API でイテレーション削除試行
・代替：分類モデルで検証継続、YOLOv8 でオフライン学習着手
・次更新：11:30 JST
付録：ポストモーテム（事後レポート）雛形
- 概要：発生日、影響範囲、ビジネス影響、最終解消時刻。
- タイムライン：検知 → 初動 → エスカレーション → 暫定対応 → 復旧。
- 技術的要因：キュー輻輳、GPU スロット枯渇、バックエンド障害など。
- 再発防止：イテレーション分割、同時実行制限、リージョン分散、アラート強化。
- コスト影響：実績とクレジット対応。
- 改善タスク：オーナー／期限／測定可能な成果指標（KPI）。
参考：この記事の要点（実務チェック用ミニサマリ）
- 原因像：サービス側インシデントや輻輳。ユーザー操作のみでの復旧は困難。
- 最優先：チケット起票＋Service Health 監視＋コスト裏取り。
- ワークアラウンド：API でイテレーション削除／分類で検証／オフライン学習。
- 再発防止：段階的学習、分割、同時実行抑制、リージョン分散、監視強化。
原文要約（記事内要素の再掲）
現象：6 時間予定のトレーニングが 15 時間以上終わらず、ポータルから停止も再起動もできない。
影響範囲：複数リージョンに跨り発生。特にオブジェクト検出で顕著、画像分類は正常。
懸念：実験停止／コスト増が不安。
結論：Microsoft 側で広範な障害が発生している前提で対処。ユーザーだけでの根本解決は不可。
推奨アクション：
・サポートチケットを即時起票（詳細情報つき）。
・Service Health の継続監視。
・Cost analysis で課金影響を確認、必要時はクレジット相談。
・API でイテレーション削除（キャンセル相当）。
・暫定的に分類モデル／オフライン学習で評価継続。
再発防止：クイックトレーニング → 分割、同時実行抑制、リージョン分散、アラート整備。
コメント