Azure Document Intelligence（旧 Form Recognizer）を業務システムに組み込むと、帳票の自動処理が止まることはそのままビジネス停止につながります。「毎朝 6 時頃になると特定リソースだけ応答しなくなる」「先週も同じような障害が起きた」といった、じわじわと再発するトラブルをどう切り分け、どう設計し直せばよいのかを、具体的な手順と設定例を交えて解説します。
Azure Document Intelligence リソースが応答しない典型シナリオ
今回のケースでは、Azure Document Intelligence のリソース medzy‑faxclassification が、東部標準時（EST）で 6 時頃から突然応答しなくなり、先週水曜日にも約 3 時間ほど同様の障害が再発している状況を想定します。
このような「特定の時間帯にだけ応答が止まる」「同じような現象が何度も起きる」場合、考えられる主な原因は次のように整理できます。
| 想定される原因 | 特徴的な症状 | まず確認すべきポイント |
|---|---|---|
| Azure 側のサービス障害（リージョン障害・インシデント） | 複数システム・複数リソースで同時に失敗。Portal からのテスト呼び出しも失敗。 | サービス正常性、リソース正常性のステータス、正常性履歴 |
| スロットリング（TPS 超過）・クォータ超過 | 429 や 503 が増える。ピーク時間帯にだけエラー率が上がる。 | メトリック（Total Calls / Errors）、アプリのログ（HTTP ステータスとリトライ状況） |
| アプリ側の不具合・接続設定の問題 | Document Intelligence 以外のサービスにも影響がある、または一部機能だけ失敗。 | 最近のデプロイ状況、ネットワーク設定、Firewall・Private Endpoint 設定 |
| 設計上のボトルネック（シングルリージョン・単一リソース依存） | 一つのリソースが落ちると全ジョブが止まる。フェールオーバー先がない。 | アーキテクチャ構成図、冗長化・バックアップ構成の有無 |
以下では、Azure Portal での具体的な確認ポイントから、アプリ側の対処、再発防止のアーキテクチャまで、順番に解説していきます。
Azure サービス正常性で「Azure 側の問題」を切り分ける
まず最初に行うべきは、「これは Azure プラットフォーム側の障害なのか」「それとも自分たちのリソース・アプリの問題なのか」を明確に切り分けることです。そのために使うのが サービス正常性 (Service Health) です。
Service Health で確認するポイント
Azure Portal での基本的な確認手順は次のとおりです。
- Azure Portal にサインイン
- メニューから 「サービス正常性 (Service Health）」 を開く
- サービスで 「Azure AI Services」または「Document Intelligence」 を選択
- リージョンに、medzy‑faxclassification を配置しているリージョンを指定
ここで確認すべき主な項目を整理すると、次のようになります。
| 項目 | 見るべき内容 | 判断のポイント |
|---|---|---|
| インシデント | Document Intelligence / Azure AI Services に「利用不可」「パフォーマンス低下」などのインシデントが出ていないか | 同じ時間帯にインシデントが出ていれば、Azure 側障害の可能性が高い |
| アドバイザリ | 負荷増大や一時的制限などのアドバイザリがないか | 一部機能・一部リージョンのみ影響を受けるケースもあるため要確認 |
| 正常性履歴 | 先週水曜日の障害時間帯を含む期間の履歴 | 過去の障害と同じインシデント ID であれば、再発・継続の可能性あり |
もしここで明らかなインシデントが出ている場合は、アプリケーション側の調査に時間をかけても解決しません。後述の「サポートへの情報提供」の準備をしつつ、フェールオーバー先のリージョンやリソースへ切り替える設計ができているかを確認しましょう。
リソース正常性とメトリックで「自分のリソース」の状態を確認
Service Health で「リージョン全体の問題ではなさそうだ」と判断したら、次は当該リソース medzy‑faxclassification の状態を詳しく見ていきます。
Resource Health でステータスを確認
Azure Portal で対象の Document Intelligence リソースを開き、メニューから 「リソース正常性 (Resource Health)」 を選択します。
ここでチェックすべきポイントは次の通りです。
- ステータスが 「利用可能」 以外になっていないか（例：「利用不可」「デプロイ中」「停止」など）
- 障害発生日（例：2025-09-16 06:00 EST）前後でステータスに変化がないか
- 先週水曜日の障害時間帯にも同様のステータス変化が記録されていないか
Resource Health に「利用不可」や「障害」の履歴が残っていれば、Azure 側のリソースレベルの問題が強く疑われます。その場合、後述の内容を添えて Microsoft サポートへエスカレーションすることで、詳細な原因調査を依頼できます。
メトリックで「どのように止まっているか」を可視化
次に、同じリソースで 「メトリック」 を開き、Document Intelligence 固有のメトリックを確認します。特に重要なのは次の項目です。
| メトリック名 | 概要 | 見るべきポイント |
|---|---|---|
| Processed Pages | 処理されたページ数 | 障害時間帯以降、値が完全に 0 になっていないか（処理がまったく進んでいない） |
| Total Calls | API 呼び出し回数 | アプリからリクエストは送られているか。急にフラットになっていれば「そもそも呼んでいない」可能性もある。 |
| Errors | エラーになった呼び出し回数 | 429 / 5xx が急増していないか。エラー率が一定以上になっていないか。 |
これらを同じグラフ上に重ねて表示すると、次のようなパターンが見えてきます。
- Total Calls は増えているが、Processed Pages が伸びず Errors が急増… Azure 側またはクォータ・スロットリングの影響で処理できていない可能性
- Total Calls 自体が 0 に近い… アプリ側がそもそも Document Intelligence を呼べていない（ネットワーク／アプリ障害）
- Total Calls も Processed Pages もフラットだが Resource Health は利用可能… バッチ処理などのジョブが動いていない、スケジューラ側の問題
ここまで確認すると、「Azure 側のインシデント・リソース障害なのか」「リソースは正常だが呼び出し方に問題があるのか」をかなりの精度で切り分けることができます。
スロットリング／クォータ超過を疑うべきサイン
Document Intelligence を無料層や低価格層の SKU で運用している場合、特に注意すべきなのが TPS（毎秒リクエスト数）上限 や 月間クォータ の超過です。
このような場合に現れやすい症状は次の通りです。
- 特定の時間帯（今回で言えば毎朝 6 時前後）だけエラー率が急上昇する
- HTTP ステータス 429（Too Many Requests）、503（Service Unavailable）が多発する
- メトリックの Total Calls と Errors が同じ形で伸びている
代表的な HTTP ステータスと意味
| ステータスコード | 意味 | 考えられる原因 | 推奨アクション |
|---|---|---|---|
| 400 | Bad Request | リクエスト形式誤り、パラメータ不備 | リクエスト内容を修正。再試行しても改善しない場合が多い。 |
| 401 / 403 | Unauthorized / Forbidden | キーの誤り、ローテーション後の未更新、権限問題 | キー・資格情報の見直し、Key Vault 連携の確認。 |
| 404 | Not Found | URL ミス、対象モデルが存在しない | エンドポイント・バージョンを確認。誤ったパスを修正。 |
| 429 | Too Many Requests | TPS 制限に引っかかっている | 指数バックオフ付きリトライ、TPS の抑制、SKU スケールアップ。 |
| 500 | Internal Server Error | Azure 側の一時的な内部エラー | 短時間のリトライで復旧することが多い。頻発する場合はサポートへ。 |
| 502 / 503 | Bad Gateway / Service Unavailable | バックエンドの負荷・一時的な利用不可 | 429 同様にリトライ。特定時間帯に集中する場合は負荷分散を検討。 |
特に 429 や 503 が時間帯によって集中している場合、アプリケーション側でのリトライ戦略と、クォータ設計を見直す必要があります。
アプリ側での指数バックオフ付きリトライ実装例（C#）
クライアントアプリケーションでは、429 / 5xx が返ってきた際に 指数バックオフ を用いたリトライを実装することで、一時的な負荷集中や短時間のサービス不安定性を吸収できます。
private static async Task<HttpResponseMessage> CallDocumentIntelligenceAsync(HttpClient client, HttpRequestMessage request)
{
const int maxRetries = 5;
var delay = TimeSpan.FromSeconds(1);
for (int retry = 0; retry <= maxRetries; retry++)
{
var response = await client.SendAsync(request);
if ((int)response.StatusCode < 500 && response.StatusCode != (HttpStatusCode)429)
{
// 400 番台（429 を除く）はリトライしても意味がないケースが多い
return response;
}
if (retry == maxRetries)
{
return response;
}
await Task.Delay(delay);
// 指数関数的に待機時間を増やす（上限を決めておくこと）
delay = TimeSpan.FromSeconds(Math.Min(delay.TotalSeconds * 2, 30));
}
throw new InvalidOperationException("Unexpected state");
}
アプリ側での指数バックオフ付きリトライ実装例（Python）
import time
import requests
def call_document_intelligence(url, headers, payload, max_retries=5):
delay = 1.0
for retry in range(max_retries + 1):
response = requests.post(url, headers=headers, data=payload)
if response.status_code not in (429, 500, 502, 503, 504):
return response
if retry == max_retries:
return response
time.sleep(delay)
delay = min(delay * 2, 30.0)
このような実装を入れておくだけでも、「一時的なスパイクで Document Intelligence が応答しないように見える」ケースを大幅に減らすことができます。
具体的な切り分け手順：何から調べるべきか
ここまでの内容を踏まえ、medzy‑faxclassification が再び応答しなくなった場合に、現場で迷わず動けるよう、具体的な切り分け手順を整理しておきます。
- サービス正常性の確認
Azure Portal の Service Health で、Document Intelligence / Azure AI Services にインシデントが出ていないか確認する。 - リソース正常性の確認
該当リソースの Resource Health を確認し、「利用不可」「停止」などのステータスがないかを見る。 - メトリックの確認
Processed Pages / Total Calls / Errors を 1 分〜5 分粒度で表示し、障害発生時刻前後でどのような変化があるかを見る。 - アプリケーションログの確認
Application Insights やログ基盤で、Document Intelligence への呼び出しログを検索し、HTTP ステータス・エラーコード・レスポンス時間・Correlation ID を確認する。 - 他リソース・他リージョンへのテスト呼び出し
同一リージョンに別リソースを作成してテストする、または別リージョンの Document Intelligence リソースへテスト呼び出しを行い、再現性を確認する。
この 5 ステップで、「Azure 全体の問題」「特定リソースの問題」「アプリ側の実装・負荷問題」を切り分けられます。
Microsoft サポートへチケットを発行する際に準備すべき情報
今回のように、先週も似たような障害が起きている 場合は、早めに Microsoft サポートへチケットを発行し、継続した調査を依頼することを強くおすすめします。その際に準備しておくと話が早い情報をまとめます。
| カテゴリ | 具体例 |
|---|---|
| リソース情報 | リソース名：medzy‑faxclassification サブスクリプション ID リソースグループ名 リージョン（例：East US など） |
| 障害のタイムライン | 今回の障害発生日時（例：2025-09-16 06:00 EST〜） 先週水曜日の障害発生日時と復旧日時 どの程度の頻度で発生しているか |
| 技術的なログ情報 | 失敗した API 呼び出しの Correlation ID / Trace ID HTTP ステータスコードとレスポンスボディ（※個人情報はマスク） エラー発生時のリクエスト種別（モデル名、エンドポイント種類など） |
| 影響範囲 | 1 日あたりの処理件数・影響を受けた処理件数 業務影響（FAX 受付の遅延、SLA など） 代替手段の有無（手作業対応など） |
特に Correlation ID / Trace ID は、Microsoft 側でバックエンドログを追跡するために極めて重要です。アプリケーションログや Application Insights に必ず記録しておくようにしましょう。
再発防止のための推奨設定とアーキテクチャ
単発の障害であれば「その場しのぎの対応」でも乗り切れますが、今回のように 何度も似たような停止が起きている 場合は、システム全体の設計と運用を見直すタイミングです。ここからは、再発防止・影響最小化のための具体的な対策を紹介します。
サービス正常性アラートの設定
まずは「障害をいち早く知る」ための仕組みを整えましょう。
- サービス正常性で、Document Intelligence / Azure AI Services に対してアラートルールを作成
- 対象リージョンに、medzy‑faxclassification が存在するリージョンを指定
- 通知先として、メール・Teams・Webhook などを設定
これにより、Azure 側でインシデントやメンテナンスが発生した瞬間に、運用チームへ自動通知が飛ぶようになります。
Application Insights による依存サービス監視
アプリケーション側には Application Insights を導入し、Document Intelligence への依存関係を明確に監視することをおすすめします。
- Document Intelligence への呼び出しを Dependency としてトラッキング
- 成功率（Success Rate）、失敗率、平均応答時間、最大応答時間をダッシュボード化
- 「成功率が 95％ を下回ったらアラート」などのルールを設定
さらに、アプリケーションログと組み合わせて「どの API 呼び出しが、どの FAX 種別で、どのモデルに対して失敗しているのか」を Kusto クエリで素早く分析できるようにしておくと、障害の再発時に調査時間を大幅に短縮できます。
マルチリージョン冗長やフェールオーバー戦略
Document Intelligence を 単一リージョン・単一リソース に集約していると、そのリソースが落ちた瞬間に処理が全て止まってしまいます。重要な業務であれば、次のような冗長構成を検討しましょう。
- 同じモデル・設定を持つ セカンダリリソース を別リージョンに用意
- アプリケーション側で プライマリ → セカンダリ のフェールオーバーロジックを実装
- ルーティング制御に、Feature Flag や構成ファイル（App Configuration）を使用
簡易的なフェールオーバー実装イメージは次のようになります。
string primaryEndpoint = config["DocIntel:PrimaryEndpoint"];
string secondaryEndpoint = config["DocIntel:SecondaryEndpoint"];
async Task<HttpResponseMessage> AnalyzeFaxAsync(HttpRequestMessage request)
{
// まずプライマリへ送信
var response = await _client.PostAsync(primaryEndpoint, request.Content);
if (IsRetryableError(response.StatusCode))
{
// プライマリがダメな場合はセカンダリへフェールオーバー
response = await _client.PostAsync(secondaryEndpoint, request.Content);
}
return response;
}
ここでのポイントは、「プライマリが 1 回でも失敗したらすぐセカンダリへ切り替える」のではなく、「一定回数失敗した場合」「一定時間以上連続で失敗した場合」などの条件を設け、過剰なフェールオーバーを避けることです。
キューを使った非同期処理でピーク負荷を吸収
FAX の自動分類など、ある程度の遅延が許容されるバッチ的な処理であれば、クライアントから直接 Document Intelligence を呼ぶのではなく、次のような非同期パターンが有効です。
- クライアントは、FAX 受信情報とファイルパスをキュー（Azure Storage Queue / Service Bus Queue）に投入
- バックエンドのワーカー（Function / WebJob など）がキューを監視し、一定のスループットを保ちながら Document Intelligence を呼び出す
- 429 や 503 が返ってきた場合は、メッセージをキューに戻し、遅延をつけて再処理する
これにより、クライアント側の急激なリクエスト集中を平準化し、TPS 制限や一時的なサービス不安定性の影響を最小限に抑えることができます。
運用チェックリスト（再発防止用）
最後に、今回のような「特定 Document Intelligence リソースが恒常的に止まる」問題を防ぐためのチェックリストをまとめます。定期的なレビューの際に活用してください。
| チェック項目 | 状態 | 補足 |
|---|---|---|
| Service Health のアラートが設定されている | 済 / 未 | 対象リージョンと Azure AI Services / Document Intelligence を指定 |
| Resource Health を定期的に確認している | 済 / 未 | 過去 30 日〜90 日の履歴をレビュー |
| Application Insights で依存サービスの監視ができている | 済 / 未 | 成功率・エラー率・応答時間のダッシュボードを作成 |
| 429 / 5xx に対する指数バックオフ付きリトライ処理が実装済み | 済 / 未 | 最大リトライ回数・待機時間の上限も設計 |
| クォータ・TPS 上限と実際のピーク負荷を把握している | 済 / 未 | 負荷テスト結果をドキュメント化 |
| マルチリージョン冗長・フェールオーバー構成がある | 済 / 未 | 定期的なフェールオーバーテストを実施 |
| サポート用に Correlation ID / Trace ID を必ずログ出力している | 済 / 未 | 個人情報を含まない形で残すルールを策定 |
| 障害対応手順書を整備し、関係者に共有している | 済 / 未 | 今回紹介した切り分け手順をベースに手順書化 |
まとめ：原因を特定し、止まっても「大事故」にならない設計へ
Azure Document Intelligence のような AI ベースのマネージドサービスは、非常に高い可用性を提供している一方で、クラウドサービスである以上、完全に障害ゼロを約束することはできません。そのため、今回のように medzy‑faxclassification が特定の時間帯に応答しなくなる問題に対しては、次の 3 つの観点で対策を講じることが重要です。
- 可視化と切り分け
Service Health / Resource Health / メトリック / Application Insights によるログとメトリックの整備。 - アプリケーションレベルの耐障害性
指数バックオフ付きリトライ、キューを用いた非同期処理、フェールオーバー先の用意。 - 運用とプロセス
アラート設計、サポートチケット発行時の情報整理、定期的なレビューと負荷テスト。
これらを順に整えていくことで、「なぜ恒常的に止まるのか」を論理的に絞り込みながら、たとえ同様の障害が再度発生したとしても、業務への影響を最小限に抑える堅牢な運用が実現できます。まずは、この記事で紹介したチェックポイントをもとに、自社環境の現状を棚卸ししてみてください。
コメント