Azure Functions や App Service 上の Azure Bot をユーザー割り当てマネージド ID（UAMI）で動かしていると、「Teams では動くのに、Azure ポータルの Web Chat（Test in Web Chat）だけ Unauthorized / Invalid AppId で落ちる」という相談が増えています。本記事では、この現象の背景と、現時点（2025 年時点）で現実的な解決策・構成パターンを、Teams / Web Chat / Direct Line それぞれの観点から整理します。
UAMI 構成の Azure Bot + Web Chat で何が起きているのか
前提となる構成例
まず、この記事で扱う典型的な構成を整理します。
- Bot アプリケーション：Azure Functions（Python / C# など）
- Bot Identity：ユーザー割り当てマネージド ID（UAMI）
- Function App のアプリ設定：
MicrosoftAppType=UserAssignedMSI MicrosoftAppId=<UAMI のクライアント ID> MicrosoftAppTenantId=<テナント ID> MicrosoftAppPassword=<未設定（空）> - Bot Framework SDK：Cloud Adapter + ConfigurationBotFrameworkAuthentication 系列
- C# の場合：
ConfigurationBotFrameworkAuthentication+CloudAdapter - Python の場合：同様に構成ファイルから設定を読むクラスを利用
- C# の場合：
- Azure Bot リソース側の設定：
- Identity Type：UserAssignedMSI
- Microsoft App ID：UAMI のクライアント ID と一致
この状態で、Azure ポータルの「Test in Web Chat」や Web Chat / Direct Line から接続すると、Bot 側のログに次のようなエラーが出る、というケースです。
401 Unauthorized. Invalid AppId passed on token.JWT を確認すると aud クレームは Bot の App ID（= UAMI のクライアント ID）と一致しており、一見正しく見えるにもかかわらず、Bot Framework SDK 側のトークン検証で弾かれてしまいます。
結論（ざっくり）：Web Chat / Direct Line は「UAMI 単独」をまだきれいにはサポートしていない
Microsoft Q&A に 2025 年の時点で、まさに同じ相談が投稿されており、Microsoft モデレーターから次のような趣旨の回答が出ています。
- テナント全体への admin consent や UAMI に対する Bot Service Contributor ロール付与は正しい方向。
- しかし、それでも UAMI のサポートは一部チャネルでは限定的。
- Teams は比較的安定して動くが、Web Chat は依然として従来の App ID + シークレット フローを前提にした部分があり、UAMI だけでは失敗することがある。
- Web Chat が必須なら、現状は アプリ登録（SingleTenant）+ シークレット／証明書方式に戻す必要がある。
つまり、今回の現象は「設定ミス」というより、Bot Identity とチャネル側の実装がまだ完全には UAMI モデルに追随しきれていないことによる制約に近いと考えるのが自然です。
Azure Bot の Identity タイプと現状のサポート状況
3 つの Bot Identity タイプ
Azure Bot には、以下 3 種類のアイデンティティ タイプがあります。
| 方式 | MicrosoftAppType | MicrosoftAppId | MicrosoftAppPassword | 主な用途・特徴 |
|---|---|---|---|---|
| ユーザー割り当てマネージド ID （User-assigned Managed Identity） | UserAssignedMSI | UAMI のクライアント ID | 不要（空欄） | 最新モデル。アプリ登録を作らず、Managed Identity だけで Bot を認証させる。 |
| シングルテナント アプリ登録 | SingleTenant | アプリ登録のアプリ ID | クライアント シークレット または証明書 | 推奨される従来方式。チャネル・ツールとの互換性が高い。 |
| マルチテナント アプリ登録 （新規作成は非推奨） | MultiTenant | アプリ登録のアプリ ID | クライアント シークレット | 2025/7/31 以降、新規作成はサポート終了予定。既存 Bot は継続動作。 |
公式ドキュメント上は、「新規 Bot は SingleTenant または UserAssignedMSI を使うこと」が案内されています。
チャネルごとの実用サポート感（2025 年末時点）
公式に「チャネル別に UAMI が完全サポート」と明示された一覧はありませんが、ドキュメントや GitHub Issues、Q&A を眺めると、おおよそ次のような傾向があります。
| チャネル / ツール | UAMI のみ | SingleTenant App 登録 | コメント |
|---|---|---|---|
| Azure ポータル「Test in Web Chat」 Web Chat / Direct Line | △〜× | ◎ | UAMI 構成で 401 / Invalid AppId が出る事例多数。公式 Q&A でも「Web Chat はまだ App ID + シークレット前提」とコメントあり。 |
| Microsoft Teams | ○ | ◎ | UAMI + Teams で動作報告多数。SSO や Token Exchange 周りで追加設定が必要なケースあり。 |
| Bot Framework Emulator | × | ◎ | Emulator は依然として MultiTenant 前提の実装が残っており、UAMI では 401 になる既知の Issue が存在。 |
| Azure Communication Services – Chat チャネル | ○ | ◎ | 公式クイックスタートで MicrosoftAppType=UserAssignedMSI のサンプルあり。 |
この表から分かるように、UAMI は「Bot 自体のアイデンティティ方式」としては正式にサポートされているものの、ツール／チャネル側の実装が追いついていない箇所が残っている、というのが実態です。
なぜ Web Chat / Direct Line だけが問題になるのか
Bot アーキテクチャの 3 つの認証フロー
2025 年公開の Azure Bot Identity の解説では、Bot ソリューションにおける認証・認可フローを以下の 3 つに分解しています。
- クライアント → チャネル（Client → Channel）認証
- Teams クライアント、Web Chat JavaScript、モバイルアプリなどがチャネルに対して認証するフェーズ。
- Direct Line や Web Chat では、「シークレット → トークン発行 API（
https://directline.botframework.comなど）→ Web Chat でトークン利用」という流れ。
- チャネル ↔ Bot アプリ（Channel ↔ Bot）認可
- チャネルが Bot のメッセージング エンドポイント（例：
/api/messages）に対して送信する HTTP 要求を、OAuth2 で保護するフェーズ。 - ここで Bot Identity タイプ（UAMI / SingleTenant / MultiTenant）が効いてくる。
- チャネルが Bot のメッセージング エンドポイント（例：
- ユーザー サインイン（User sign-in）
- Bot 内から
OAuthPromptや OAuthCard を使ってユーザー個人にサインインさせるフロー。 - Bot Identity とは独立した、別のアプリ登録を使うことも可能。
- Bot 内から
今回問題になっているのは 2 番目の チャネル ↔ Bot アプリの認可です。ここでチャネル側が発行・検証するトークンの扱いが、UAMI のトークン発行モデルと完全に噛み合っていないため、aud が合っていても SDK で失敗するケースが出ています。
BotFrameworkAdapter と CloudAdapter の差分
Azure Bot Identity のブログでは、古い BotFrameworkAdapter が 常に botframework.com テナントに対してトークンを取りに行くため、SingleTenant や UAMI の Bot では正しく動作しないことが指摘されています。
BotFrameworkAdapter：- トークン エンドポイントが
https://login.microsoftonline.com/botframework.com/oauth2/v2.0/tokenに固定。 - SingleTenant / UAMI の Bot では、ホームテナントと異なるため認証エラーの原因になる。
- トークン エンドポイントが
CloudAdapter+ConfigurationBotFrameworkAuthentication：MicrosoftAppTypeに応じて、適切なトークン エンドポイントを選択。- SingleTenant / UAMI に正式対応した新しいアダプター。
質問の前提では CloudAdapter 系列を利用しているため、この「古いアダプター問題」そのものではありませんが、チャネル／ツール側は依然として古い前提（App ID + シークレット）を持っている箇所があると考えられます。
特に Web Chat / Direct Line は、https://api.botframework.com など専用のエンドポイントを使っており、UAMI 前提のトークン発行パスとの整合性に課題が残っていると見られます。
トークンの中身は合っているのに「Invalid AppId」になる理由（推測ベース）
JWT の aud が UAMI のクライアント ID と一致しているにもかかわらず、SDK で Invalid AppId と判定されるのは、次のような要因が組み合わさった結果と考えられます。
iss（issuer）や署名鍵の取得元が UAMI モデルと合っていない- チャネル側が「App 登録が存在する」前提でトークンを構成している
- Bot SDK 側での検証ロジックが、「Managed Identity であること」を十分に考慮していないパスを通っている
Microsoft Q&A の回答でも、「Web Chat はまだ従来の App ID + シークレット フローを期待しているため、admin consent や RBAC 設定を行ってもなお失敗する場合がある」と明言されています。
したがって、現状は「トークンの一部のクレームは合っているが、全体として UAMI 構成を前提にした完全なサポートには至っていない」という状態です。
Web Chat / Direct Line を使いたい場合の解決策
現実的な選択肢：Bot Identity を SingleTenant App 登録に戻す
Web Chat（および Direct Line、Azure ポータルの Test in Web Chat）を安定して使う前提に立つなら、現時点のベストプラクティスは Bot Identity を SingleTenant のアプリ登録に戻すことです。
具体的な手順は次の通りです。
- Microsoft Entra ID でアプリ登録を作成（SingleTenant）
- サポートされるアカウント タイプ：
「この組織ディレクトリ内のアカウントのみ（シングルテナント）」 - クライアント シークレットまたは証明書を発行して控えておく。
- サポートされるアカウント タイプ：
- Azure Bot リソースの Identity Type を SingleTenant に変更
- Bot の Configuration 画面で Microsoft App ID をアプリ登録のアプリ ID に変更。
- アプリ設定の
MicrosoftAppTypeをSingleTenantに変更。
- Bot アプリ側の構成を更新
- App Service / Functions のアプリ設定：
MicrosoftAppType=SingleTenant MicrosoftAppId=<アプリ登録のアプリ ID> MicrosoftAppTenantId=<テナント ID> MicrosoftAppPassword=<クライアント シークレット> - CloudAdapter + ConfigurationBotFrameworkAuthentication の構成はそのまま利用可能。
- App Service / Functions のアプリ設定：
- Web Chat / Direct Line / Teams で疎通確認
- Azure ポータルの「Test in Web Chat」。
- 必要なら Direct Line シークレットからトークンを発行して独自 Web ページに埋め込み。
- Teams チャネルもこの構成のまま利用できます。
このアプローチを取ると、Web Chat 側は従来どおり「App ID + シークレット」を使ったフローで動作するため、UAMI 特有の「Invalid AppId」問題を回避できます。
UAMI はバックエンド用に限定して併用する
「セキュリティ的にどうしても Managed Identity を使いたい」という場合は、次のような 役割分離パターンが現実的です。
- Bot Identity：SingleTenant のアプリ登録（上記のとおり）
- バックエンド リソース アクセス：UAMI を別途 Function App / App Service に割り当て
- Key Vault・Storage・Cosmos DB・自社 API などへのアクセスは Managed Identity で実施。
- Bot Identity（App Registration）はチャネル ↔ Bot 認証専用として使う。
この構成なら、チャネル互換性は App 登録方式で確保しつつ、アプリ内部のクラウド リソース アクセスは UAMI でシークレットレスにすることができます。
Teams を主チャネルにする場合：UAMI 継続は「アリ」だがチェックポイント多め
一方、「社内 Teams ボットが主目的で、Web Chat は必須ではない」というケースでは、UAMI を継続利用する選択も十分にあり得ます。この場合に確認しておきたいチェックポイントを詳しく見ていきます。
基盤設定：Function / App Service と UAMI の紐づけ
- Function App / App Service の Identity 設定で、対象の ユーザー割り当てマネージド ID を追加しているか。
- アプリ設定が次のように揃っているか：
MicrosoftAppType=UserAssignedMSI MicrosoftAppId=<UAMI のクライアント ID> MicrosoftAppTenantId=<テナント ID> MicrosoftAppPassword=<空（設定しない）> - Python / C# / JS いずれも、CloudAdapter + ConfigurationBotFrameworkAuthentication を利用しているか。
ID の整合性：Bot リソース・Teams manifest・UAMI
Teams + UAMI でハマりやすいのが、「どの ID がどこを指しているか」の混乱です。次の 3 箇所が 同じ GUID を見ている必要があります。
| 場所 | 項目 | 期待値 |
|---|---|---|
| UAMI | クライアント ID | Bot の Microsoft App ID と一致 |
| Azure Bot リソース | Configuration → Microsoft App ID | 同上（UAMI のクライアント ID） |
| Teams アプリ manifest | bots[].botId | 同上（UAMI のクライアント ID） |
どこか 1 か所でも別の ID を参照していると、Teams 側のメッセージは届くが Bot からの応答が 401 で落ちるなど、理解しづらい症状が出ます。
テナント側の許可：Bot Framework サービス プリンシパルへの admin consent
UAMI 構成であっても、Microsoft ホストチャネル（Bot Framework Service）をテナント内で利用できるようにするための admin consent は必要になる場合があります。
- 典型的には、次のような URL でテナント管理者が同意を行います：
https://login.microsoftonline.com/<TenantID>/adminconsent?client_id=<BotAppID> - ここでの
<BotAppID>は Bot の Microsoft App ID（今回は UAMI のクライアント ID）ですが、
UAMI には App Registration が存在しないため、テナント側のポリシーによってはうまく機能しないこともある点に注意が必要です。 - また、「Bot Service Contributor」ロールは Azure RBAC における管理権限であり、トークン検証の可否そのものには関係しません。ここを混同しないことが重要です。
Teams でのみ利用する場合でも、組織のセキュリティ ポリシー上、Bot Framework サービス プリンシパルへの同意が必須なケースがあります。テナント管理者やセキュリティ チームと連携して確認しましょう。
SDK / ランタイムのバージョンとアダプター
UAMI は比較的新しい機能であり、古い Bot Framework SDK では正しく動かないケースがあります。
- Bot Framework SDK for C# / JS / Python は v4.15 以降（UAMI 対応バージョン）を利用する。
- 必ず CloudAdapter を使う（
BotFrameworkAdapterは SingleTenant / UAMI では非推奨）。 ConfigurationBotFrameworkAuthenticationを自前でラップしている場合、設定値の取り回しでミスがないか再確認。
Teams でも失敗する場合の切り分け手順
Teams でも 401 や「Application with identifier ‘xxx’ was not found in the directory ‘Bot Framework’」系のエラーが出る場合、次の順番で切り分けると整理しやすくなります。
- Bot Identity の構成ミスを疑う
- まず SingleTenant App 登録構成に切り替えてみて、Teams / Web Chat で動くか確認。
- 動くようなら、問題は UAMI 構成特有のものと切り分けられる。
- テナント / admin consent 周りを疑う
- Enterprise Applications から Bot Framework / Azure Bot Service のアプリにアクセスし、ブロックされていないか確認。
- ネットワーク・プロキシ・OpenID メタデータの上書きの有無を確認
- OpenID メタデータ URL をアプリ設定で上書きしている場合、エンドポイントが正しいか。
- プロキシやネットワーク制限で OpenID メタデータや署名鍵が取得できているか。
トラブルシューティング チェックリスト（Web Chat / Teams 共通）
ここまでの内容を、実際の確認手順としてまとめ直します。
1. 基盤設定の確認
- Function App / App Service に対象 UAMI が割り当てられているか。
- アプリ設定：
- UAMI の場合：
MicrosoftAppType=UserAssignedMSI MicrosoftAppId=<UAMI クライアント ID> MicrosoftAppTenantId=<テナント ID> MicrosoftAppPassword=<未設定> - SingleTenant App 登録の場合：
MicrosoftAppType=SingleTenant MicrosoftAppId=<アプリ登録のアプリ ID> MicrosoftAppTenantId=<テナント ID> MicrosoftAppPassword=<クライアント シークレット>
- UAMI の場合：
- Bot リソースの Configuration 画面での Microsoft App ID と、上記
MicrosoftAppIdの一致。
2. チャネル別の動作確認
| チャネル | 期待される挙動 | 実際の結果 | 考えられる原因 |
|---|---|---|---|
| Azure ポータル Test in Web Chat | UAMI 構成では失敗し得る | 成功/失敗の確認 | UAMI サポート不足、Token 検証経路の不整合 |
| Teams | UAMI でも動く可能性が高い | 成功/失敗の確認 | ID 不整合、admin consent、SDK バージョンなど |
| Emulator | UAMI では基本的に失敗 | MultiTenant 構成でのみ成功 | Emulator の仕様（MultiTenant 前提） |
「Teams は成功するが Web Chat だけ失敗」という状態であれば、今回説明した UAMI × Web Chat の制約に該当している可能性が高いと判断できます。
3. JWT の内容確認
Application Insights やログから Channel → Bot に付与されている JWT を取り出し、次の項目を確認します。
aud：- UAMI 構成なら、UAMI のクライアント ID と一致しているか。
- SingleTenant 構成なら、アプリ登録のアプリ ID と一致しているか。
iss：- エンドポイントが
botframework.comか、自テナントか。Identity タイプと矛盾していないか。
- エンドポイントが
azp/appid：- チャネル側のアプリ ID が正しく設定されているか。
これらがすべて整合していても Web Chat だけ失敗する場合は、現時点の実装上の制約として受け止め、SingleTenant への切り替えを検討するのが現実的です。
よくある勘違いポイント
- 「Bot Service Contributor ロールを UAMI に付ければ認証が通る」
- これは Azure リソース管理用の RBAC であり、チャネル ↔ Bot のトークン検証には影響しません。
- 「UAMI を使えば admin consent は不要」
- UAMI でも、Bot Framework サービスがテナント内で動作するための権限は必要になる場合があります。
- 「CloudAdapter を使っていれば何でも自動でうまくいく」
- CloudAdapter は SingleTenant / UAMI 対応の前提条件ですが、チャネル / 環境の制約までは吸収してくれません。
将来に向けた構成の考え方
Bot Framework SDK 自体は 2025 年末に向けて段階的に Microsoft 365 Agents SDK へ移行が案内されていますが、「Bot Identity とバックエンド ID を分ける」という設計思想自体は今後も有効です。
- チャネル ↔ Bot のトラスト境界：SingleTenant App 登録で安定させる。
- Bot 内部のリソース アクセス：Managed Identity（System/UAMI）で完結させる。
- ユーザー サインイン：必要に応じて別 App 登録を用意し、最小権限で構成する。
こうした役割分離をしておくと、将来的に UAMI が Web Chat などに完全対応した場合でも、構成の差し替えポイントが明確になり、移行しやすくなるメリットがあります。
今すぐ取れるアクションのまとめ
- Web Chat / Direct Line を必須とする場合
- Bot Identity を SingleTenant App 登録 + シークレット/証明書方式に切り替える。
- UAMI は Key Vault や Storage などのバックエンド用に併用する設計に見直す。
- Teams が主チャネルで、Web Chat は必須ではない場合
- UAMI 構成を継続しつつ、この記事のチェックリストで ID 整合性・admin consent・SDK バージョンを再確認する。
- それでも不安定な場合、一時的に SingleTenant 構成で疎通確認し、差分から問題点を絞り込む。
- 将来の UAMI 完全対応に備える
- Azure Bot Identity / Bot Service のリリースノートや、Microsoft Q&A の動向を定期的にウォッチする。
- 構成ファイル（
appsettings.json/.env/ Function App のアプリ設定）を Infrastructure as Code 化し、Identity タイプの切り替えをスクリプトで再現できるようにしておく。
現時点では、「Web Chat でのテスト用途だけシングルテナント App 登録に戻し、実運用の Teams では UAMI を検証し続ける」という折衷案を採るケースも多く見られます。自組織のチャネル要件とセキュリティ ポリシーを踏まえて、最適なアイデンティティ戦略を選択してください。
コメント