MENU

Azure AI ドキュメント インテリジェンスのカスタム分類モデル消失（インシデント631764787）の原因と恒久対策｜復旧手順・冗長化・IaC・監視まで完全解説

Azure

2025年9月16〜17日に、Azure AI ドキュメント インテリジェンス（旧 Form Recognizer）の「カスタム分類モデル」がポータルから突然消え、同名の再学習も「名前の衝突」で拒否され、API 呼び出しまで失敗した——。本稿は、この一連の事象（インシデント ID: 631764787）の原因を技術的に読み解き、いますぐ実践できる復旧手順と、再発に備える恒久対策・運用指針・自動化コードまでを一気通貫で提示します。

目次

Azure AI ドキュメント インテリジェンスでカスタム分類モデルが消えた問題：全体像

2025年9月16〜17日、運用中のカスタム分類モデルがポータルから突発的に消失し、呼び出しも失敗。同名で再学習（再作成）を試みても「名前の衝突」により作成できず、のちに旧モデルが復活した一方、障害当日に暫定で作成した新モデルが逆に見えなくなるという矛盾が発生しました。ユーザー影響として、「分類 API 応答エラー」「モデル一覧の欠落」「ポータル表示と REST 結果の不一致」「モデル名重複エラーの継続」などが確認されています。

原因：インシデント ID 631764787（基盤移行に起因する一時的不整合）

公式アナウンスに相当する情報として、本件は Azure AI ドキュメント インテリジェンスが Azure AI Foundry へ基盤移行中に発生した一時的なバックエンド不整合に起因するサービス障害でした。典型的な症状は以下です。

  • モデル一覧・メタデータの一時欠落（ポータル UI とバックエンドの参照系で整合性が崩れる）
  • エンドポイント応答エラー（404/409/5xx など）、推論実行の失敗
  • 「モデル名の重複」エラー（実体は存在するが索引側が欠落し、重複と誤検知）

このため「見えない＝削除された」ではなく、「存在はしているが参照・解決が失敗」という状態が同時多発的に起きえます。復旧後に旧モデルが再び現れ、障害時に作った新モデルが見えなくなるのは、同期処理の巻き戻し・再同期の過程で発生しうる整合性の揺り戻しと整合します。

いま行うべき復旧アクション（現場向け手順）

API で事実を確認（ポータル非依存の在庫確認）

UI が不安定な場合でも、REST API でモデルの実在や状態を直接確かめられます。まずは「一覧」「単体取得」「状態確認」を機械的に実施し、UI 側の遅延・欠落と切り分けます。

# 1) アクセストークン取得（Microsoft Entra ID: client_credentials）
#   scope / resource: https://cognitiveservices.azure.com/.default
#   tenant_id / client_id / client_secret はアプリ登録で取得

# 2) モデル一覧の取得（※エンドポイントは環境に合わせて）
GET https://{endpoint}/formrecognizer/documentModels?api-version={api-version}
Authorization: Bearer {access_token}

# 3) 単一モデルの取得
GET https://{endpoint}/formrecognizer/documentModels/{modelId}?api-version={api-version}

# 4) 推論テスト（分類）
POST https://{endpoint}/formrecognizer/documentModels/{modelId}:analyze?api-version={api-version}
Content-Type: application/json
Authorization: Bearer {access_token}
{
  "urlSource": "https://{storage}/samples/invoice.pdf"
}

ポイント：環境によっては /documentintelligence/ プレフィックスを利用する場合があります。既存の API バージョン互換に留意しつつ、実環境のエンドポイントとバージョンに置き換えてください。

表示されないモデルの再同期依頼（サポートチケット）

障害影響下で索引が欠落している可能性があるため、ポータル未表示のモデルについては Azure サポートにインシデント ID（631764787）と発生時刻帯を添えて、メタデータ再同期（re-index/reconcile）を依頼します。依頼の前に API で存在が確認できたか、modelId・createdDateTime・description 等の属性を提示できると対応がスムーズです。

「名前の衝突」回避の応急処置

  • 同名での再作成は避け、明示的なバージョン接尾辞（例：invoice-classifier-v3）を付与して一時運用します。
  • アプリケーション設定におけるモデル参照は、環境変数や Key Vault で差し替え可能にし、UI 依存の手作業を排除します。
  • 障害収束後、旧モデルの整合が回復した段階で、A/B 切り替えのうえで正系に戻します。

解決策・ベストプラクティス（確実な業務継続のために）

フェーズ具体的な対処補足
① 現在の復旧サービスは復旧済み（インシデント収束）。 未表示モデルはサポートへ再同期依頼（インシデント ID と期間を明記）。 REST API GET /documentModels で現況を裏取り、UI 側遅延と切り分け。API で存在が確認できるなら、アプリ側の参照先をその modelId に固定して復旧を早める。
② 冗長化モデルコピーで別リージョンへ複製（例：EU North／EU West／Japan East ↔ Japan West）。 アプリは複数エンドポイントを事前登録。優先度・重み付きフェイルオーバーを実装。 Azure Front Door またはアプリ側リトライ＋サーキットブレーカーで自動切り替え。ARM/Bicep／Terraform または POST /documentModels/{modelId}:copyTo → …:copyFrom をジョブ化。
③ 運用ガイドライン商用は S0/S01 レベル以上を使用。 認証は Microsoft Entra ID（アプリ登録＋クライアント資格情報）。 「即同名再作成」を避け、整合性が落ち着くまでバージョン番号を追加して運用。 Azure Service Health／Activity Log アラートを有効化。障害兆候を即時検知。スループット要件に応じてアカウント分割・キュー連携でスパイクを平準化。
④ 再発防止モデル構成をIaC化（ARM/Bicep/Terraform）し Git にバックアップ。 毎日 GET /documentModels の結果をストレージへスナップショット保存（差分検出）。 「モデル一覧」「推論応答」「スロットリング」の合成監視を導入。UI 依存を排し、API ベースの検知・切替・復旧を自動化する。

二重化・多リージョン構成の実装パターン

アプリ内フェイルオーバー（軽量・高速）

SDK/HTTP クライアントに、優先リスト（Primary → Secondary）と健全性プローブを実装します。

# 疑似コード（HTTPベース）
endpoints = [
  { name: "primary",   url: "https://<primary>.cognitiveservices.azure.com" , priority: 1 },
  { name: "secondary", url: "https://<secondary>.cognitiveservices.azure.com", priority: 2 }
]

def analyze_with_failover(model_id, input_url):
for ep in sorted(endpoints, key=lambda e: e["priority"]):
try:
resp = call_analyze(ep["url"], model_id, input_url)
if resp.status in [200, 202]:
return resp
if resp.status in [404, 409, 429, 500, 502, 503]:
# 即時再試行せず指数バックオフ＋サーキットブレーク
record_failure(ep["name"], resp.status)
continue
except Exception as ex:
record_exception(ep["name"], ex)
continue
raise Exception("All endpoints failed")

Azure Front Door による経路制御（運用簡素化）

  • Front Door Standard/Premium の「優先度ベース」ルーティングで、Primary 停止時に Secondary へ自動フェイルオーバー。
  • ヘルスプローブは /formrecognizer/documentModels（ヘッダーに認証不要の疎通用 API か、アプリ側で軽量ヘルスチェック エンドポイントを用意）。
  • アプリ側には単一の FQDN を埋め込み、切替は Front Door 側で完結。

モデルのコピー（クロスリージョン）

モデルは「Authorize → CopyTo → CopyFrom」の順で相互認証しつつ複製します。

# 1) ターゲット側でコピー認可情報を取得（copyAuthorization）
POST https://{targetEndpoint}/formrecognizer/documentModels:authorizeCopy?api-version={api-version}
Authorization: Bearer {access_token}
{
  "modelId": "invoice-classifier-v3"
}

# 2) ソース側からターゲットへコピーを開始

POST https://{sourceEndpoint}/formrecognizer/documentModels/{sourceModelId}:copyTo?api-version={api-version}
Authorization: Bearer {access_token}
{
"targetResourceId": "{copyAuthorization.resourceId}",
"targetModelLocation": "{copyAuthorization.modelLocation}",
"targetModelId": "invoice-classifier-v3",
"accessToken": "{copyAuthorization.accessToken}",
"expirationDateTime": "{copyAuthorization.expirationDateTime}"
}

# 3) ターゲット側で作成の完了確認（operationId をポーリング）

GET https://{targetEndpoint}/formrecognizer/operations/{operationId}?api-version={api-version}

運用ガイドラインの詳細（本番・セキュリティ・命名）

本番レベルのアカウントと認証

  • SKU は S0/S01 以上を選択し、性能・スロットリングヘッドルームを確保。
  • 認証は Microsoft Entra ID（クライアント資格情報フロー）。スコープは https://cognitiveservices.azure.com/.default。
  • 資格情報は Azure Key Vault に保管し、アプリはマネージド ID で Key Vault へアクセス。

モデル命名規約・再展開ポリシー

  • ベース名 + セマンティック版数（例：invoice-classifier-v3.2.1）。
  • 「同名再作成」は避け、既存との競合回避のため新しい ID を必ず割り当てる。
  • ロールバック容易性のため、Production/Staging などの環境別接尾辞を付与。

削除・再作成の禁止期間

障害・メンテ直後は索引再構築が走ります。最低でも数時間は同名での再作成を避けるルールを運用に組み込み、意図せぬ二重登録や欠落の再発を防止します。

再発防止の技術施策（IaC・スナップショット・監視）

IaC（Infrastructure as Code）で構成の再現性を担保

モデルのコピー・参照設定・アラートを Bicep/Terraform でコード化し、任意のサブスクリプション／リージョンに即時復旧可能な状態を作ります。

// Bicep（概念例）: Cognitive Services アカウント雛形
param location string = 'japaneast'
param accountName string
param skuName string = 'S0'

resource ai 'Microsoft.CognitiveServices/accounts@2023-05-01' = {
  name: accountName
  location: location
  kind: 'FormRecognizer'
  sku: {
    name: skuName
  }
  properties: {
    publicNetworkAccess: 'Enabled'
  }
}

output endpoint string = ai.properties.endpoint

モデル一覧のデイリースナップショット

毎日定刻に GET /documentModels の結果を Blob/Files に保存し、前日との差分を検出します。欠落・重複・属性変更を早期に察知できます。

# Python サンプル（概念）
import os, json, datetime, requests

endpoint = os.environ["DI_ENDPOINT"]
token = os.environ["AZURE_TOKEN"]  # マネージドID or ワークロードIDで取得
api_version = os.environ.get("DI_API_VERSION","{api-version}")

headers = {"Authorization": f"Bearer {token}"}
r = requests.get(f"{endpoint}/formrecognizer/documentModels?api-version={api_version}", headers=headers)
models = r.json()

stamp = datetime.datetime.utcnow().strftime("%Y%m%d")
with open(f"/mnt/snapshots/models_{stamp}.json","w") as f:
    json.dump(models, f, ensure_ascii=False, indent=2)

# 直近スナップショットと比較し、消失・新規・属性変更をレポート化

合成監視（一覧×推論×遅延）

  • 5分ごとに「一覧 API」「ヘルスチェック推論（ごく小さなテスト文書）」を監視。
  • 429/5xx をシグナルに、リトライ指数バックオフと「サーキットブレーカー開放」を自動化。
  • 遅延がしきい値超過で Front Door / アプリ内フェイルオーバーをトリガー。

サポート・アラートの作り込み（通知の即時性）

Service Health／Activity Log アラート

サブスクリプション単位のサービス正常性変化を即通知します（メール/SMS/Teams Webhook）。

# Azure CLI（概念）
# 1) アクショングループの作成
az monitor action-group create \
  --resource-group RG-OPS \
  --name ag-di-alerts \
  --short-name diAG \
  --email-receiver admin [email protected]

# 2) Service Health アラート（重大度：Sev0/Sev1）

az monitor activity-log alert create 
--name "AzureAI-DI-ServiceHealth" 
--resource-group RG-OPS 
--scopes /subscriptions/ 
--condition category=ServiceHealth and level=Warning 
--action-group ag-di-alerts

よくある落とし穴と回避策

  • 落とし穴：ポータル表示だけを根拠に「モデルは消えた」と判断。
    回避：REST API の一覧取得・単体取得で存在を先に確定する。
  • 落とし穴：同名再作成で「衝突」を連発し、アプリ側参照が迷子になる。
    回避：常に新しい modelId を払い出し、参照は環境変数で即切替。
  • 落とし穴：単一リージョン依存。
    回避：クロスリージョン複製＋自動フェイルオーバーをデフォルト設計に。
  • 落とし穴：監視は「死活」だけ。
    回避：一覧・推論・遅延の三点監視で実効性を担保。

インシデント再現の技術的メカニズム（考察）

本件は、バックエンドのメタデータ索引・モデル実体ストア・推論ルーターの間で一時的に整合が失われ、「索引から消える／重複扱いになる／推論先が解決できない」といった症状が連鎖的に噴出した事例です。分散システムでは、管理プレーン（一覧・作成・削除）とデータプレーン（推論実行）の収束タイミングがズレることがあり、基盤移行やロールアウト直後に顕在化しやすくなります。

したがって、UI を真実のソースにしない、API を一次情報源にする、別リージョンに温かい待機（ウォームスタンバイ）を持つ、の3点がクラウド運用の本質的な対策となります。

現場で使えるチェックリスト

項目確認内容実施状況
API での存在確認GET /documentModels と GET /documentModels/{id} の結果を保存[ ]
モデル二重化Primary/Secondary に同一バージョンを配置[ ]
参照の抽象化モデル ID は環境変数/Key Vault で切替可能[ ]
合成監視一覧×推論×遅延を 5 分間隔で監視[ ]
アラート設計Service Health / Activity Log の重大度ルール化[ ]
スナップショット毎日のモデル一覧 JSON を保存・差分出力[ ]
IaCBicep/Terraform に構成を反映し Git で版管理[ ]
運用ルール障害/削除直後は同名再作成を禁止[ ]

トラブルシューティング・コード断片（再掲）

PowerShell：モデル在庫の即時棚卸し

# 環境変数: $env:ENDPOINT, $env:TOKEN, $env:API_VERSION
$headers = @{
  "Authorization" = "Bearer $($env:TOKEN)"
}
$uri = "$($env:ENDPOINT)/formrecognizer/documentModels?api-version=$($env:API_VERSION)"
$res = Invoke-RestMethod -Uri $uri -Headers $headers -Method GET
$res.value | ForEach-Object {
  "{0} | created: {1} | desc: {2}" -f $_.modelId, $_.createdDateTime, $_.description
}

cURL：同名回避で新モデルを生成（説明のみ）

# 学習ジョブはバージョン付きIDで作成（例：invoice-classifier-v4）
curl -X POST \
  -H "Authorization: Bearer &lt;TOKEN&gt;" \
  -H "Content-Type: application/json" \
  "https://&lt;endpoint&gt;/formrecognizer/documentModels:build?api-version={api-version}" \
  -d '{
    "modelId": "invoice-classifier-v4",
    "buildMode": "template",
    "azureBlobSource": {
      "containerUrl": "https://&lt;storage&gt;.blob.core.windows.net/&lt;container&gt;?sastoken"
    },
    "description": "Emergency build with explicit version suffix"
  }'

アプリ側のレジリエンス（HTTP 429/5xx を吸収）

# 擬似コード：指数バックオフ＋ジャitter＋回数上限
def call_with_backoff(do_request, max_attempts=5, base_delay=0.5):
    import random, time
    for i in range(max_attempts):
        try:
            resp = do_request()
            if resp.status_code in [200, 202]:
                return resp
            if resp.status_code in [429, 500, 502, 503, 504]:
                delay = base_delay * (2 ** i) + random.random() * 0.2
                time.sleep(delay)
                continue
            resp.raise_for_status()
        except Exception:
            time.sleep(base_delay * (2 ** i))
    raise Exception("Request failed after retries")

ケーススタディ：実運用ワークフローの標準化

以下は、今回のようなインシデントに直面した場合の標準オペレーション例です。

  1. 障害検知：Service Health 通知 or 合成監視の失敗率上昇で検知。
  2. 初動対応：アプリをセカンダリへ自動フェイルオーバー（Front Door or アプリ内）。
  3. 事実確認：REST API でモデル存在と推論可否を確認、結果を運用ノートに記録。
  4. 暫定運用：同名回避の新バージョン ID で緊急展開（必要な場合のみ）。
  5. サポート：インシデント ID と時刻を添えてメタデータ再同期を依頼。
  6. 復旧判定：旧モデルの整合が回復したら、A/B で品質確認のうえ正系に復帰。
  7. 事後策定：スナップショット・IaC・監視の不足分を補完し、手順書に反映。

セキュリティとコンプライアンスの観点

  • 認可の最小化：学習用ストレージ SAS の有効期限を短くする。コピー操作の認可トークンも同様。
  • 監査証跡：モデルの作成・コピー・削除・推論エラーはログに残し、変更管理台帳に自動転記。
  • 分離：本番・検証・開発でアカウントを分離し、RBAC ロールも最小限に限定。

FAQ（現場からの質問に即答）

Q：ポータルに見えないモデルへ API で推論できますか？
A：管理プレーンの索引が欠落しているだけでデータプレーンが生きていれば可能です。まずは API で単体取得・推論を試してください。

Q：同名再作成はいつ再開していい？
A：インシデント収束後もしばらくは整合性回復の余波があります。少なくとも業務時間外に、既存 ID の再利用ではなく新 ID での再展開を推奨します。

Q：リージョン冗長の最低構成は？
A：Primary/Secondary の二拠点（同一大陸内）が実務的な起点です。Front Door またはアプリ内フェイルオーバーを併用します。

まとめ

今回のモデル消失は、Azure AI ドキュメント インテリジェンスの基盤移行に伴うサービス側の一時的不整合（インシデント ID: 631764787）が原因でした。復旧済みであるものの、再発に備える構えは不可欠です。すなわち、多リージョン冗長化、IaC と日次スナップショット、Service Health／合成監視の三本柱を整備し、ポータルが不安定でも API で確証を取り、即時に切り替えられる体制を作る。これこそが、クラウド時代の業務継続性（BCP）に直結する「実務的な最適解」です。

Azure
監視 冗長化 BCP Azure AI Document Intelligence フォーム認識

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次