Azure Custom Vision のオブジェクト検出で、学習ジョブが「開始されたまま完了しない・失敗にもならない」という状態にハマると、プロジェクト側で工夫しても抜け出せないことが多くあります。ここでは、2025年9月以降に観測されている「オブジェクト検出だけがハングする」ケースを例に、原因の見立てと、実務的に取るべきアクションを整理します。
Azure Custom Vision の学習が完了しない現象の整理
発生状況の概要
まず、今回整理する事象を、できるだけ客観的にまとめておきます。
| 観点 | 状況 |
|---|---|
| 対象機能 | オブジェクト検出のみ（画像分類は正常に学習完了） |
| 学習モード | クイックトレーニング／高度なトレーニングの両方でハング |
| リソース階層 | S0 (Standard) で発生（Free に限定された問題ではない） |
| リージョン | South Central US / Japan East で再現（他リージョンの報告もあり） |
| 発生タイミング | 2025年9月8日ごろから継続 |
| ステータス表示 | ポータル上では「Training」などのステータスから完了にも失敗にも遷移しない |
| 他のワークロード | 同一リソースでの画像分類の学習は完了 → リソース全体の障害ではない可能性が高い |
| ユーザーからの対処 | プロジェクト複製／新規作成／過去の成功 Iteration への巻き戻しを行っても解消せず |
| 再現性 | 複数ユーザー・複数テナント・複数リージョンで報告 → 広域的なサービス側事象の可能性が高い |
ポイントは、「画像分類は普通に学習完了しているのに、オブジェクト検出だけがずっと終わらない」という点です。この時点で、単純な課金・クォータ・リソース死活問題よりも、オブジェクト検出の学習パイプライン固有の問題を疑うのが自然です。
ユーザーから見える挙動の典型例
- ポータルで「トレーニング」ボタンを押すと、数秒〜数十秒で「Training…」状態になる。
- 通常は数分〜十数分で「完了」となり、メトリクス（Precision/Recall/mAP等）が表示されるはずが、数時間〜十数時間たってもまったく変化しない。
- Iteration 一覧に「トレーニング時間」が記録されない。
- 停止・削除などの操作がグレーアウトしており、ユーザー側からジョブをキャンセルできない。
こうした症状は、「学習が遅い」のではなく、バックエンド上でジョブがハング／キューに詰まったまま進んでいないときに発生しがちなパターンです。
なぜ「サービス側事象」が最有力なのか
「学習が終わらない」と聞くと、まず思い浮かぶのは次のような要因です。
- 画像点数が極端に多い／解像度が高すぎる
- クラス数・バウンディングボックス数が多すぎる
- 料金プランやクォータ制限に引っかかっている
- 特定のアノテーションミス（0サイズのボックスなど）がある
しかし、今回のように複数リージョン・複数テナントで同時期に再現しており、かつ同じリソースで画像分類は成功している場合、これら「プロジェクト個別の要因」だけで説明するのは無理があります。
観点別の整理
| 観点 | 今回の状況 | 示唆されること |
|---|---|---|
| 学習タスク種別 | オブジェクト検出のみハング、分類は正常 | 共通基盤よりも、オブジェクト検出用パイプライン側の不具合が疑わしい |
| リージョン | South Central US / Japan East など複数 | 単一クラスタ故障ではなく、デプロイされたバージョンの回帰など広域的な原因の可能性 |
| テナント／サブスクリプション | 異なるテナント・サブスクリプションで再現 | 特定の契約・課金の問題ではなく、サービス実装側の問題寄り |
| ユーザー側操作 | プロジェクト複製・新規作成・過去 Iteration への巻き戻しでも改善せず | アノテーションやデータセット由来の問題ではなく、ジョブ実行基盤側のハングを示唆 |
このため、原因の最有力候補としては:
- サービス側の不具合（回帰バグ）
- オブジェクト検出の学習パイプラインにおけるプラットフォームレベルの障害
といった、ユーザー側からは制御できない要因が挙がります。
未公開の学習制限やタイムアウト設定が強化された可能性もゼロではありませんが、それであれば通常はエラー表示・失敗ステータス・クォータ超過メッセージなどが返されるはずです。「成功にも失敗にもならないまま止まり続ける」という挙動は、制限仕様というより純粋な不具合に近いシグナルです。
最優先で行うべきこと：公式サポートへのエスカレーション
結論から言うと、この種の問題はユーザー側で決定打を打つことはできません。バックエンドでハングしているジョブを強制終了したり、当該リージョンのパイプラインをロールバックできるのは Azure サービス側のみです。
したがって、最短ルートはAzure サポートにチケットを挙げ、事象を集約・可視化してもらうことです。
Azure ポータルからのサポートチケット作成手順
- Azure ポータルにサインインする。
- 画面右上または左下のメニューから 「ヘルプとサポート」 を開く。
- 「新しいサポート要求」 を選択する。
- 次のように項目を選択／入力する。
- 問題の種類: Technical
- サービス: Custom Vision（Azure AI Services / Vision 配下の該当サービス）
- サブスクリプション・リソース: 該当の Custom Vision トレーニングリソースを選択
チケットに必ず含めたい情報
サポートの調査速度と精度は、こちらがどれだけ具体的な情報を渡せるかに大きく左右されます。特に、同種事象が世界中で同時多発しているケースでは、「ただの個別トラブル」なのか「サービス障害」なのかを判断する材料をサポート側に提供することが重要です。
| 項目 | 具体的な内容 |
|---|---|
| 発生日・期間 | 例: 2025-09-08 以降、常に再現 |
| 影響リージョン | 例: South Central US / Japan East（他リージョンで試した場合はその結果も） |
| リソース階層 | S0 (Standard)（Free かどうかも明記） |
| プロジェクト情報 | プロジェクト名・プロジェクトID（Custom Vision ポータルから控える） |
| 影響した Iteration | Iteration 名／ID、トレーニング開始時刻、ステータス（Training のまま等） |
| 学習モード | クイックトレーニング／高度なトレーニング の両方で再現するかどうか |
| 他タスクの状況 | 同じリソースで実施した 画像分類プロジェクトは正常に完了している ことを明記 |
| 再現手順 | 最小限の画像セットで新規プロジェクトを作り、同じようにハングするかどうかを簡潔に記述 |
| 関連スレッド | 同様事象が議論されている Q&A / フォーラム / Issue などの URL があれば添付 |
サポートチケットの記述サンプル
日本語で問い合わせる場合のテンプレート例です（必要に応じて英訳して併記すると、海外チームへエスカレーションされた際にスムーズです）。
【概要】
Azure Custom Vision のオブジェクト検出で学習ジョブが完了せず、
ステータスが「Training」のまま数時間以上変化しない事象が発生しています。
【発生日】
2025-09-08 頃から継続的に再現
【影響範囲】
・リソース階層: S0 (Standard)
・リージョン: South Central US / Japan East
・対象: オブジェクト検出のみ（同一リソース上の画像分類は正常に学習完了）
【症状】
・ポータルからクイックトレーニング／高度なトレーニングを実行すると、
Iteration のステータスが「Training」から変化せず、完了にも失敗にもなりません。
・トレーニング時間がメトリクスに記録されません。
・Iteration の停止／削除操作がグレーアウトしており、キャンセルできません。
【再現手順】
1. 新規にオブジェクト検出プロジェクトを作成
2. 10枚・1クラス程度の最小データセットをアップロード
3. クイックトレーニングを実行
→ 上記のように「Training」のまま数時間変化しない
【補足】
・同一リソースで画像分類プロジェクトを作成し、同程度のデータで学習した場合は、
数分で正常に完了します。
・複数ユーザー／複数テナントで同様の報告があり、サービス側事象の可能性を疑っています。
調査および対処方針のご教示をお願いいたします。
このレベルまで整理した上でチケットを挙げると、単なる「遅い学習」ではなくサービス障害の疑いがある案件として扱われやすくなります。
調査を加速するためのエビデンス収集
サポートにチケットを投げる前後で、次のような情報を追加で採取しておくと、調査がかなりスムーズになります。
RequestId / CorrelationId の取得
Custom Vision のトレーニング開始リクエストには、内部的に RequestId / CorrelationId が振られています。これが分かると、Azure 側でログをトレースしやすくなります。
- ポータルで操作している場合
- ブラウザの開発者ツール（F12）→「Network」タブを開く。
- トレーニング開始ボタンを押したタイミングの
train等のリクエストを探す。 - レスポンスヘッダーやボディ内に
request-idやx-ms-correlation-request-idなどが含まれていれば、その値を控える。
- API／SDK 経由で学習を開始している場合
- HTTP レスポンスのヘッダーをロギングするようコードを修正し、学習開始時の RequestId を保存しておく。
サポートチケットに「○月○日 10:23(JST) ごろ、RequestId=xxxxx でトレーニング開始」と書いておくと、Azure 側のログ検索が一気に楽になります。
影響 Iteration の一覧を整理する
「いつ・どの Iteration で・どのくらい待っても完了しないのか」を表形式でまとめておくと、サポート側も状況を把握しやすくなります。
| プロジェクト名 | Iteration 名 / ID | 学習開始日時 | 学習モード | 経過時間 | 最終ステータス |
|---|---|---|---|---|---|
| Sample-ObjectDetection | Iteration 15 | 2025-09-08 10:23 | クイック | 6時間以上 | Training のまま |
| Sample-ObjectDetection | Iteration 16 | 2025-09-09 09:02 | 高度 | 3時間以上 | Training のまま |
| Sample-ObjectDetection-Min | Iteration 1 | 2025-09-09 11:15 | クイック | 2時間以上 | Training のまま |
また、「この日時より前の Iteration は正常完了していた」 という境界が分かれば、それも必ず共有しましょう。例えば「Iteration 12 までは10分以内に完了していたが、Iteration 13 以降すべてハング」という情報は、サービス側のデプロイタイミングと突き合わせるうえで非常に有用です。
最小データセットでの再現確認
「データ依存の問題」かどうかを切り分けるため、次のような 最小プロジェクト で再現を確認しておくと良いです。
- 画像枚数: 10〜20 枚程度
- クラス数: 1 クラス
- バウンディングボックス: 各画像 1〜3 個程度
- 解像度: 一般的な HD（1280×720）程度
この条件でもハングするのであれば、「データが重すぎるから時間がかかっている」説はかなり薄くなるため、「サービス側事象」だと判断しやすくなります。
運用影響を抑えるための暫定回避策
サポートからの回答やサービス側の修正には、どうしても一定の時間がかかります。そのあいだ本番運用を止めないために、現実的に取りうる暫定回避策を整理します。
1. 既存の成功モデルで推論だけ継続する
もっとも確実で影響が小さいのは、直近で学習に成功している Iteration をそのまま本番運用し続けることです。
- Custom Vision のモデルは、過去の Iteration を指定して発行・呼び出すことができます。
- 「新しいデータで再学習できない」だけであれば、推論 API は引き続き利用可能です。
- 性能改善がしばらく止まるというデメリットはありますが、サービス停止よりははるかにマシです。
監視面では、「一定期間以上、新しい Iteration が出ていない」ことをアラート条件に含めておくと、今回のような事象にも気付きやすくなります。
2. 要件が許せば「画像分類」で代替する
オブジェクト検出の要件を分解すると、次の2つのニーズに分かれます。
- 画像内に特定の物体が「存在するかどうか」を知りたい（分類）
- その物体が「どこにあるか（座標）」を知りたい（検出）
後者（座標）が必須でない、あるいは「画像単位での判定でも実務上は許容できる」場合は、一時的に画像分類プロジェクトへ設計を切り替えるという選択肢があります。
- 例: 「不良が写っている画像かどうかだけ判定できればよい」場合
- オブジェクト検出 → 「良品 / 不良品」の二値画像分類
- オブジェクト検出 → 「製品A / 製品B / 製品C」の多クラス分類
もちろん、位置情報が必要なユースケース（ピッキングロボット、トラッキングなど）ではこの代替は難しいですが、「最低限、ラベルだけでも出せれば業務が回る」シナリオでは非常に有効です。
3. 別リージョンでのスポット検証
恒久回避策にはなりませんが、サポートへの補助情報として、別リージョンで同じプロジェクトを試してみることは有用です。
- 例: South Central US / Japan East でハング → East US / East Asia に新しいリソースを作成して再現するか確認。
- もし「Aリージョンではハングするが、Bリージョンでは正常完了」と判明した場合、リージョン依存の障害であることがより明確になります。
ただし、本番運用の切り替え先として雑にリージョンを増やすと、後から管理が複雑化します。スポット検証と、限定的な一時運用にとどめ、サービス側の修正完了後は構成を整理する計画を立てておくことをおすすめします。
やっても効果が薄い／不要な施策
すでに多くのユーザーが試して「改善しなかった」と報告している対処もあります。これらは時間を消耗するだけになりがちなので、「一度だけ試す」程度にとどめ、執着しすぎないことが重要です。
| 施策 | 結果／評価 |
|---|---|
| プロジェクトの複製 | 同じデータをそのままコピーしても、オブジェクト検出のパイプラインが同一であればハングは再現する可能性が高い。 |
| 新規プロジェクトの作成 | データを一式アップロードし直しても、サービス側のバグであれば解消しない。 |
| アノテーション差し替え | 過去に成功していたアノテーション（例: Iteration 12）へ巻き戻しても改善しない事例が多い。 |
| 学習モードの変更（クイック⇔高度） | そもそも両方でハングするケースがあるため、決定打にはなりにくい。 |
| 同一階層でのリソース再作成 | 画像分類は正常完了しているため、リソース自体の健全性は高い。同じリージョン・階層で作り直しても再発する可能性大。 |
これらの施策は、あくまでも「ユーザー側に問題がないか最低限確認する」目的で一度だけ試す程度にとどめ、何度も同じ作業を繰り返さないようにしましょう。本質的な解決は、サービス側の修正を待つか、回避構成を大きく変える（別サービスに移行するなど）しかありません。
ジョブ監視とタイムアウト設計のすすめ
今回のような「ハングしているのに UI 上は『進行中』に見える」トラブルは、監視設計やアプリケーション実装の課題をあぶり出すきっかけにもなります。Custom Vision を継続利用するのであれば、「学習ジョブのヘルスチェック」をシステム設計に組み込むことを強くおすすめします。
明示的なタイムアウトとリトライ上限
トレーニング API をポーリングしている場合は、次のようなルールを実装しておくとよいでしょう。
- 「最大待ち時間」を決める（例: 90 分）。
- それを超えてもステータスが Training のままなら、アプリケーション側では強制的に「失敗」扱いにする。
- 失敗扱いになったジョブは、監視／通知の対象に乗るようにする（Slack / Teams / メールなど）。
- 自動リトライの回数上限も決め（例: 3 回）、超えたら人間の確認を必須とする。
| ルール | 例 |
|---|---|
| 最大待ち時間 | 90 分以上 Training が続けば「異常」とみなす |
| ステータス監視 | 5 分間隔で Iteration ステータスを確認（API または SDK） |
| リトライ上限 | 自動再試行は 3 回まで。以降は人が判断して再実行。 |
| 通知 | 上限超過時に Teams / Slack / メールでアラートを送信 |
こうしたロジックを入れておけば、サービス側の障害を「システム全体のフリーズ」に直結させずに済むようになります。
Azure Service Health / ステータスの監視
Custom Vision を本番サービスに組み込んでいる場合は、Azure Service Health のアラート設定も必須です。
- 対象サービス: Azure AI Services / Custom Vision 関連
- 対象リージョン: 実際にリソースを置いているリージョン（South Central US, Japan East など）
- 通知先: 運用チームのメール、Teams チャネルなど
Service Health に障害情報が出た時点で、ユーザー側での切り分けを深追いせず、ただちに暫定運用モードへ切り替える運用ルールを決めておくと、心理的な迷いが減ります。
「別サービスへ移すべきか？」という判断軸
オブジェクト検出が長期間にわたってハングし続ける場合、「Custom Vision を使い続けて良いのか？」という不安も出てきます。この点については、次のような観点で判断するとよいでしょう。
- 要求される SLA / SLO のレベル
- 「数日間学習できなくても構わない」程度なら、Custom Vision 継続でも十分現実的。
- 「毎日新しいデータで再学習しないと精度が維持できない」システムなら、より制御可能な仕組み（Azure ML + AutoML など）への移行も検討価値あり。
- 学習パイプラインを自前で管理できるか
- コンテナベース／Kubernetes ベースの ML パイプラインを運用する体制があれば、Custom Vision に依存しない構成も視野に入る。
- そうでなければ、マネージドサービスの利便性とトレードオフを理解したうえで使い続けるのが現実的。
- 既存システムとの結合度
- 既に多くのシステムが Custom Vision のエンドポイント前提で組まれているなら、短期での全面移行はリスクが高い。
短期的には、Custom Vision を使い続ける前提で「障害時の回避策と監視」を厚くするのが現実解になりやすいです。中長期的には、要件次第で「学習フローだけ別基盤に切り出す」などのハイブリッド構成も検討できます。
まとめ：ユーザー側でできること・できないこと
最後に、今回のような「オブジェクト検出の学習が完了しない」事象に対して、ユーザー側でできること・できないことを整理します。
ユーザー側でできること
- 事象を正確に整理し、サポートにエスカレーションする
- 発生日・リージョン・Iteration 情報・RequestId などを揃えてチケットを作成。
- 「複数ユーザー・複数リージョンで再現している」旨も伝える。
- 調査を助けるためのエビデンスを集める
- 最小データセットでの再現確認。
- 過去の正常 Iteration との比較。
- 運用上の暫定回避策をとる
- 直近の成功モデルで推論運用を継続。
- 要件が許せば画像分類で代替。
- 別リージョンでのスポット検証。
- 今後のために監視と設計を見直す
- ジョブごとのタイムアウト・リトライ上限の導入。
- Service Health／ステータス監視の整備。
ユーザー側ではできないこと
- ハングしているトレーニングジョブの強制停止（バックエンド上での kill）。
- 特定リージョンの Custom Vision 学習パイプラインをロールバック・再デプロイすること。
- サービス内部のタイムアウトやキューイングロジックを変更すること。
つまり、要するに:
- ユーザー側で打てる決定打はなく、公式サポートへの集約・エスカレーションが最短ルートである。
- そのうえで、既存モデルによる推論継続・画像分類での代替・明示的なジョブ監視とタイムアウトといった運用的工夫を組み合わせるのが、現時点での実務的な最善策である。
本記事の内容をもとに、自身の環境で「どこまでが自分でコントロールできる領域か」を整理しつつ、サポートチケットと暫定運用を進めていただければ、障害の影響を最小限にとどめつつ、サービス側の修正を待つことができるはずです。
コメント