突然、Microsoft Teams 上の Copilot プラグインが全員で使えなくなり、管理者がボット側を確認すると HTTP 500。広域障害か設定不備かを切り分け、Azure 側のチャネル設定（特に Microsoft 365 チャネル）を中心に、確認手順と復旧までの実務的な進め方を解説します。
現象の整理：Teams で「Copilot プラグインが使えない」＋ボット側で HTTP 500
「昨日まで動いていたのに、ある日突然、全ユーザーで使えない」という症状は、テナント全体に影響する設定差分か、バックエンド（Azure 側）の設定・資格情報・依存サービスの問題、またはMicrosoft 側の広域障害のどれかに収束することが多いです。まずは、何がどこで失敗しているのかを言語化して、調査の順番を誤らないようにします。
| 観測できるポイント | 例 | まず疑う範囲 |
|---|---|---|
| Teams クライアント側 | プラグインが応答しない／汎用エラー表示／読み込み中のまま | Teams 側の機能制御、アプリ配布、広域障害、認可の問題 |
| 管理者のプラグイン（ボット）監視 | HTTP 500（Internal Server Error）が発生 | ボットのエンドポイント例外、チャネル設定不備、認証・秘密情報の期限切れ |
| Azure のログ（App Insights / Functions / App Service） | 例外スタックトレース、依存 API の失敗、タイムアウト | 原因の特定に直結（「500 の正体」を確定する） |
| Microsoft 365 管理センター（サービス正常性） | Teams/Copilot/連携機能のインシデント | 広域障害なら設定変更より復旧待ちが正攻法になることがある |
以降は、「全員が突然ダメ」という前提で、最短で切り分ける手順を紹介します。
最初にやるべき：サービス正常性（Service health）で広域障害を除外する
調査で最初に確認したいのは、Microsoft 365 管理センターの「サービス正常性（Service health）」です。ここで Teams／Copilot／関連機能にインシデントが出ている場合、テナント側の設定をいじっても改善しないことがあり、逆に復旧後に構成差分を増やしてしまうリスクがあります。
- 「Teams」だけでなく、Copilot や Microsoft 365 側の関連コンポーネントのインシデントも確認する
- 同時刻に他テナントでも同様の問い合わせが増えていないか、社内・運用窓口で情報を集約する
- インシデントがある場合は、設定変更は最小限にして、影響範囲の整理と回避策（代替手段）の提示を優先する
サービス正常性に明確な障害が見当たらない場合は、次に Azure 側（ボット／バックエンド）を疑います。
原因候補の筆頭：Azure 側のボットが「必要なチャネル設定」を満たしていない
Teams 上の Copilot プラグイン（ボット/拡張）が突然 500 になるケースで、現場で比較的遭遇しやすいのが、Azure にデプロイしているボットが、必要なチャネル設定を満たしていないパターンです。
特に、Teams の拡張（メッセージ拡張や Copilot 連携）を Microsoft 365 の他サーフェス（Outlook など）へ拡張する前提が含まれる構成では、Teams チャネルだけでなく「Microsoft 365 チャネル」が有効であることが要求されることがあります。未設定・無効のままだと、呼び出し経路のどこかで期待値を満たせず、結果として 500（サーバーエラー）として返ることがあります。
| パターン | 起きやすい状況 | 見え方 | 初手 |
|---|---|---|---|
| Microsoft 365 チャネルが未設定／無効 | Teams 以外の M365 連携を前提にしている／プラットフォーム側で要件が変わった | Teams で突然使えない／管理者の監視で 500 | Azure の「チャネル」設定を確認し、Microsoft 365 チャネルを有効化 |
| ボットのエンドポイント例外 | 依存 API 変更、想定外入力、例外処理不足 | 特定操作で 500 が再現／ログに例外 | App Insights で該当リクエストとスタックトレースを確認 |
| 資格情報（シークレット/証明書）期限切れ | 「ある日突然」起きやすい代表例 | 一斉に認証失敗→内部エラー化 | アプリ登録の証明書/シークレット期限、Key Vault、Managed Identity を確認 |
| スロット/環境変数差分（デプロイ事故） | 直前にデプロイ、設定反映、スロット入替 | リリース直後に全滅 | 直近変更点を棚卸しし、設定差分・ロールバックを検討 |
| 広域障害（Microsoft 側） | 同日同時刻に複数テナントで報告 | 設定変更しても改善しない | サービス正常性・サポート経由で状況確認 |
まずやること：Azure 側で「チャネル」設定を確認する手順
最短で効果が出やすいのは、Azure ポータルでボット（または関連コンポーネント）の「チャネル」設定を確認することです。ボットの種類（Azure Bot / Bot Channels Registration / App Service 直結など）によってメニュー名が多少異なりますが、基本的には「Channels（チャネル）」に集約されています。
チェック対象：どのリソースが「Teams の呼び出し口」になっているか
まず、Teams のアプリ（プラグイン）が参照しているバックエンドがどれかを確認します。
- Azure Bot（または Bot Channels Registration）リソースがあり、そこからバックエンド（Web App/Functions）に転送している
- Web App / Azure Functions が直接エンドポイントを持ち、Bot Framework と連携している
- 複数リージョン・複数環境（dev/stg/prod）があり、Teams 側が意図しない環境を参照している
「どの Azure リソースが入口か」が曖昧なままだと、チャネルを有効化しても別環境に適用してしまう事故が起きます。運用メモや IaC（Bicep/Terraform）定義がある場合は、その定義から入口リソースを確定させましょう。
チャネル設定で見るべきポイント
| 項目 | 期待値（目安） | 確認場所 | NG の場合の対処 |
|---|---|---|---|
| Teams チャネル | 有効になっている | Azure ポータル > ボットリソース > Channels | 無効なら有効化。アプリ/ボットの関連付けも再確認 |
| Microsoft 365 チャネル | 要件により有効化が必要 | Azure ポータル > Channels（追加できるチャネル一覧） | 未設定/無効なら有効化。合わせて Learn の手順を満たしているか確認 |
| メッセージング エンドポイント | 正しい URL、HTTPS、到達可能 | ボット設定（Configuration） | 誤りなら修正。WAF/Proxy/証明書の変更も確認 |
| 認証（App ID / Secret など） | 有効な資格情報、期限切れなし | Entra ID（アプリ登録）/ Key Vault | 期限更新・ローテーション。可能なら Managed Identity へ移行 |
| 環境差分 | prod を参照している | Teams アプリの manifest / 設定 | 参照先の取り違えを修正。スロット入替時の設定も確認 |
Microsoft 365 チャネル有効化の実務手順（迷いがちなポイント込み）
- Azure ポータルで対象のボットリソースを開き、「Channels（チャネル）」へ移動する
- 追加可能なチャネルの一覧から「Microsoft 365（または同等の名称のチャネル）」を探し、有効化する
- 有効化後、チャネルの設定画面がある場合は、必要な同意・設定（利用規約同意、構成の保存など）を完了する
- Teams アプリ側（manifest）で宣言しているアプリ ID / 機能が、Azure 側の App ID と一致しているかを再確認する
- 反映後に再テストし、Teams 側の同一操作で 500 が消えるか、App Insights の失敗率が下がるかを確認する
ここで「チャネルを有効化したのに改善しない」場合は、次の章の “前提設定” と “ログでの確定” に進むのが最短です。
Microsoft 365 チャネルを有効化する時の注意点
Microsoft 365 チャネルを有効化するだけで改善するケースもありますが、「有効化したのに直らない」場合は、関連する前提設定が不足している可能性があります。Microsoft Learn の「Extend Message Extension to Outlook – Teams」で案内されているような、Outlook / Microsoft 365 側へ拡張する前提の設定（スコープや機能要件、アプリの構成）に抜けがないか確認します。
- Teams アプリの機能（ボット/メッセージ拡張/コマンドなど）が、Microsoft 365 側の要件に合っているか
- アプリの manifest（機能宣言、スコープ、ID）と Azure 側の App ID が一致しているか
- 複数のアプリ登録や複数テナントで、ID の取り違えが起きていないか
最近同様の報告がある場合、製品側で調査中の事象として認識されている可能性もあります。その場合は、テナント側の設定だけでは解消しないケースがあるため、後述のログ採取とサポート依頼の準備も並行して進めるのが安全です。
「全員が突然ダメ」になりやすい落とし穴チェックリスト
チャネル設定以外にも、全ユーザー影響で突然発生しやすいポイントがあります。短時間で確認できる項目をまとめます。
| チェック項目 | なぜ突然起きる？ | 確認のコツ |
|---|---|---|
| アプリ登録のシークレット/証明書の期限切れ | 期限到来の瞬間に全認証が失敗しうる | Entra ID の「証明書とシークレット」を見て、期限と最終更新日を確認 |
| Key Vault 参照失敗 | アクセス ポリシー変更、ネットワーク制限、Identity の変更で参照できなくなる | Key Vault の監査ログ、ネットワーク設定、Managed Identity の権限を確認 |
| バックエンドの依存 API 障害 | 外部 API のダウンや仕様変更で例外が増える | 依存関係（Dependencies）失敗率、タイムアウト発生箇所を確認 |
| ルーティング/Firewall/WAF の変更 | 入口の到達性が失われると 500（または 502/503）に見えることがある | 到達確認（ヘルスチェック）、App Gateway/WAF ログ、DNS 変更履歴を確認 |
| スロット入替・設定の取り違え | 本番だけ設定が欠ける、環境変数が入替でズレる | スロットごとの設定差分、接続文字列、アプリ設定の「スロット設定」有無を確認 |
ログで「500 の正体」を掴む：Azure で確認すべきログと見方
HTTP 500 はあくまで結果で、原因は内部に隠れています。どのリクエストが 500 になっているかが分かると、設定不足か製品側事象かの判断材料になります。
| ログ/機能 | 分かること | 最初に探すべき情報 | 使いどころ |
|---|---|---|---|
| Application Insights（例外/要求） | 例外の種類、スタックトレース、失敗した要求 URL | statusCode=500、operation_Id、例外メッセージ | 最短で原因に到達しやすい |
| App Service / Functions のログ | アプリ側の詳細ログ、起動失敗、設定読み込み失敗 | 直近のデプロイ時刻周辺、エラー連鎖 | アプリ起因（例外処理不足、設定不備）を疑うとき |
| Azure Bot（チャネル）関連の診断ログ | チャネル経由の受信/送信、転送の失敗 | チャネル名、失敗理由、関連 ID | チャネル設定やプラットフォーム経路の切り分け |
| 依存関係（Dependencies） | 外部 API や DB の失敗率、遅延、タイムアウト | 失敗している依存先、平均応答時間の急増 | 「急に遅い/落ちる」系の原因特定 |
Application Insights での探し方（例）
まずは、失敗している要求を時間帯で絞り込み、500 が増えたタイミングを見つけます。KQL が使える場合は、次のようなクエリがとっかかりになります。
requests
| where timestamp > ago(24h)
| where success == false
| where resultCode == "500"
| project timestamp, name, url, resultCode, operation_Id, cloud_RoleName
| order by timestamp descoperation_Id で関連する例外を追いかけます。
exceptions
| where timestamp > ago(24h)
| project timestamp, type, outerMessage, problemId, operation_Id
| order by timestamp descここで、例外メッセージが 認証失敗（invalid_client 等）、設定値 null、依存 API タイムアウトなど、具体的な原因を指していれば、対処が一気に具体化します。逆に、ログが薄い場合は、例外ログやカスタムログの出力レベルを一時的に上げる（ただし個人情報や機密情報は出さない）ことも検討します。
実務で使える切り分けフロー（最短ルート）
「何から手を付けるか」を迷わないために、現場で使える切り分けフローを表にまとめます。
| ステップ | 確認内容 | 判断 | 次のアクション |
|---|---|---|---|
| 1 | サービス正常性で Teams/Copilot 関連の障害有無 | 障害あり | 復旧待ち＋回避策案内。ログ採取は継続 |
| 2 | 影響範囲（全員/一部、特定操作のみ） | 全員・全操作 | Azure 側設定/資格情報/チャネルを最優先で確認 |
| 3 | Azure のボット「チャネル」設定 | Microsoft 365 チャネルが無効 | 有効化し、Learn 手順に沿って不足を補う |
| 4 | App Insights で 500 の例外内容を確認 | 認証/設定/依存 API が原因 | 原因に応じて修正（シークレット更新、設定修正、依存先復旧） |
| 5 | 再現が取れない、または製品側疑い | 自力で特定不可 | Azure サポートへチケット起票（証跡付き） |
解決しない場合：Azure サポートにチケットを起票して調査依頼する
フォーラムやコミュニティでは、調査に必要な内部ツールが使えないため、原因が Azure 側・Microsoft 側のどちらにあっても、最終的にはサポートチケットが近道になることがあります。Microsoft Learn の「How to create an Azure support request」を参考に、Azure サポートへ起票して調査依頼します。
起票時に情報が揃っているほど、一次切り分けが早くなり、往復回数が減ります。最低限、次の情報を用意しておくと実務的に強いです。
| 用意する情報 | 具体例 | 目的 |
|---|---|---|
| 発生日時（UTC/JST） | 2025-12-28 09:15 JST 頃から | ログ突合・障害情報の照合 |
| 影響範囲 | 全ユーザー、全チャットで再現 | 設定差分か広域障害かの判断材料 |
| 対象リソース | Subscription / Resource Group / Bot リソース名 | 調査対象の特定 |
| エラーの証跡 | App Insights の operation_Id、例外メッセージ | 内部調査の起点 |
| 直前の変更履歴 | デプロイ、設定変更、証明書更新の有無 | 回帰の可能性を絞る |
運用目線のワンポイント：復旧後にやっておくと再発を減らせること
今回のような「突然の全滅」は、復旧できても再発しがちです。短時間でできる再発防止をいくつか紹介します。
- シークレット期限の監視：期限の 30/14/7 日前に通知が飛ぶようにし、手動更新に依存しない
- チャネル要件の棚卸し：Teams だけで完結しているのか、Microsoft 365 側の要件を含むのかを設計書に明記
- ログの「最低限」を決める：operation_Id、ユーザー操作、依存先の失敗理由が追える粒度にする（機密情報は除外）
- 変更履歴の一元化：デプロイ、設定変更、証明書更新を同じ台帳で追えるようにする
まとめ：500 は「原因」ではなく「結果」。チャネル設定とログで最短復旧へ
Teams の Copilot プラグインが突然使えず、ボット側で HTTP 500 が見えている場合、まずはサービス正常性で広域障害を除外し、そのうえで Azure 側のボット設定を確認するのが最短ルートです。特に、Teams の拡張を Microsoft 365 の他サーフェスへ広げる前提がある構成では、Microsoft 365 チャネルが未設定／無効になっていないかを最優先で見直してください。
それでも解決しない場合は、App Insights などのログから 500 の正体（例外内容）を掴み、証跡を添えて Azure サポートへ依頼することで、調査が前に進みます。運用の観点では、資格情報期限の監視と変更管理を整備するだけでも、同種トラブルの再発率を大きく下げられます。
コメント