MENU

Microsoft TeamsのMicrosoft.Identity.Client 4.84.0更新とは？影響範囲と確認すべき移行ポイント

Teams

2026年5月5日に公開・更新された「Microsoft Teams documentation update: Bump Microsoft.Identity.Client from 4.46.0 to 4.84.0」は、Teams本体の画面や会議機能が変わる更新ではありません。結論から言うと、Microsoft Teamsの会議スケジュール用Webアプリサンプルで使われている認証ライブラリ「Microsoft.Identity.Client（MSAL.NET）」を、4.46.0から4.84.0へ上げる開発者向けの依存関係更新です。Teamsの一般利用者は対応不要ですが、Teams連携アプリ、Microsoft Graph、Azure Web App、Entra IDのアプリ登録を使って会議作成機能を運用している開発者・管理者は、認証処理、依存パッケージ、.NET実行環境、Graph権限を確認する必要があります。(GitHub)

ITtripTOOLS
その「面倒」、無料で解決。 ITtripがつくる、6つの道具。 無料ツール一覧へ すべて無料・追加課金なし
先頭0を守るCSV編集こわさないCSV PDFに直接書き込みかけるPDF 写真＋説明をPDFに写レポ スマホ⇄PCで共有コピペ便 · 文章・写真 みんなの日程を調整日程Fit 匿名質問・投票を集めるKOEQ
目次

今回の更新で何が変わるのか

今回の変更は、MicrosoftのGitHubリポジトリ「TeamsMeetingsWebScheduler」に対するDependabotのPull Requestです。PR #93では、TeamsMeetigSchedulerWebsite/TeamsMeetigSchedulerWebsite.csproj内のMicrosoft.Identity.Client参照が、4.46.0から4.84.0へ変更されています。差分は1ファイル、1行の追加・1行の削除で、PRは確認時点でOpenの状態です。(GitHub)

確認項目内容実務上の見方
対象TeamsMeetingsWebSchedulerTeams会議をWeb画面からスケジュールするサンプルアプリ
変更対象Microsoft.Identity.ClientMicrosoft IDプラットフォームのトークン取得に使うMSAL.NET
バージョン4.46.0 → 4.84.0メジャー4系の範囲内だが、差分は大きい
変更箇所.csprojのPackageReferenceアプリコード変更ではなくNuGet依存関係の更新
Teams利用者への影響原則なしTeamsクライアントやTeams管理センターの設定変更ではない
開発者への影響あり認証、トークンキャッシュ、Graph API呼び出しの検証が必要

TeamsMeetingsWebSchedulerは、Microsoft 365テナントのユーザーがシンプルなWeb UIからTeams会議をスケジュールできるAzure Web App向けのコードとして公開されています。READMEでは、Graph API利用のためのアプリ登録、OnlineMeetings.ReadWriteとCalendars.ReadWriteの権限付与、管理者同意などが前提として示されています。(GitHub)

まず押さえるべき結論

この更新を「Teamsの仕様変更」と捉えると誤解します。見るべきポイントは、Teamsではなく、Teams連携アプリの認証基盤です。

特に確認すべきなのは次の3点です。

優先度確認すること理由
高自社アプリがMicrosoft.Identity.Client 4.46.0を使っていないか4.46.0はNuGet上で非推奨・保守対象外と表示されています
高認証フローが4.84.0で正常に動くかサインイン、トークン取得、Graph API呼び出しに影響する可能性があります
中.NET Core 3.1のまま運用していないかサンプルの現行.csprojはnetcoreapp3.1を対象にしており、.NET Core 3.1はすでにサポート終了しています
中推移的依存関係に競合が出ないかMicrosoft.IdentityModel.AbstractionsやSystem.Text.Jsonなどの依存関係が新しくなります
中PRの状態を確認するPRがOpenの場合、まだmainブランチや本番環境に反映済みとは限りません

NuGetでは、Microsoft.Identity.Client 4.46.0は「legacy and no longer maintained」として非推奨扱いになっており、最新のMicrosoft.Identity.Clientへ移行するよう案内されています。一方、4.84.0ではサポート対象範囲として4.77.1以降が示され、古い4.46.0を使い続ける理由はかなり弱くなっています。([NuGet][3])

対応すべき人、対応不要な人

対応すべき人

次に該当する場合は、今回のMicrosoft.Identity.Client更新を確認対象に入れてください。

対象者確認すべき理由
TeamsMeetingsWebSchedulerをforkして使っている開発者依存ライブラリの更新がそのまま自社環境に影響する可能性がある
Microsoft GraphでTeams会議を作成している開発者トークン取得や権限処理にMSAL.NETを使っている可能性が高い
Azure Web App上でTeams連携アプリを運用している管理者デプロイ後の認証失敗やGraph APIエラーを事前に防ぐ必要がある
Entra IDのアプリ登録やクライアントシークレットを管理している担当者リダイレクトURI、シークレット期限、API権限の再確認が必要
古い.NET Coreアプリを保守しているチームMSAL更新だけでなく、実行基盤の更新計画も必要

対応不要な人

Microsoft Teamsを通常の会議、チャット、通話で使っているだけのユーザーは、今回の更新に対して操作する必要はありません。Teamsアプリの再インストール、会議設定の変更、Teams管理センターでのポリシー変更も不要です。

また、TeamsMeetingsWebSchedulerを使っていない組織でも、似た構成の自社アプリがある場合は注意が必要です。たとえば「WebアプリからTeams会議を作成する」「Graph APIで予定表に会議を登録する」「Entra IDでユーザーをサインインさせる」といった実装では、同じMSAL.NET更新の影響を受ける可能性があります。

Microsoft.Identity.Client 4.84.0で注目すべき変更点

Microsoft.Identity.Client 4.84.0では、トークンキャッシュ、拡張API、mTLS、クライアントアサーション、エラー診断などに関する変更が含まれています。TeamsMeetingsWebSchedulerの標準実装で全機能を使っているとは限りませんが、派生アプリや独自実装では確認が必要です。(GitHub)

変更カテゴリ主な内容影響しやすいケース
トークンキャッシュ内部トークンキャッシュを無効化するためのオプションが追加独自キャッシュ、分散キャッシュ、セッション管理を実装している場合
Refresh Token取得AuthenticationResultからRefresh Tokenにアクセスする拡張メソッドが追加高度な認証制御や検証コードを持つ場合
Confidential Client拡張Attribute Tokenや追加Bodyパラメータの拡張メソッドが追加クライアント資格情報フローや独自パラメータを使う場合
mTLS PoPmTLS Proof-of-Possession関連の証明書オプションが追加証明書ベース認証や高セキュリティ構成を使う場合
Client Assertion一部APIの実験的機能ゲートが削除フェデレーション資格情報や署名付きアサーションを使う場合
JSON処理MSAL内部のNewtonsoft.Json依存が削除され、System.Text.Json中心へ移行古い依存関係やJSON関連パッケージ競合がある場合
診断STSエラーコードやCorrelation ID関連の改善障害調査、監視、ログ分析を重視する場合
バグ修正issuer検証、依存関係、例外処理などの修正認証エラーの再現性が低い環境や複数テナント対応アプリ

ここで重要なのは、「バージョン番号だけを見ると小さな更新に見えるが、4.46.0から4.84.0までは長期間の差分がある」という点です。単にNuGetパッケージを上げてビルドが通るかだけでなく、ログイン、ログアウト、トークン更新、Graph API実行まで確認してください。

影響範囲はTeams本体ではなく認証とGraph連携

TeamsMeetingsWebSchedulerは、Teams会議の作成そのものをTeamsクライアント上で行うのではなく、WebアプリからMicrosoft Graphを通じて会議や予定表を扱う構成です。そのため、今回の更新で見るべき影響範囲は次のようになります。(GitHub)

サインイン処理

OpenID Connectによるサインインが正常に完了するかを確認します。特に、リダイレクトURI、Cookie、セッション、ログアウトURLの動作は、ローカル環境と本番環境で差が出やすい部分です。

READMEでは、https://your_application_URL.TLD/signin-oidcやsignout-oidcに関する設定が示されています。実環境では、独自ドメイン、App ServiceのURL、リバースプロキシ、HTTPS強制設定が絡むため、PR反映前にステージング環境で確認してください。(GitHub)

Microsoft Graph API呼び出し

Teams会議の作成や予定表登録には、Graph APIの権限が必要です。READMEではOnlineMeetings.ReadWriteとCalendars.ReadWriteが示されています。MSAL.NETの更新後は、単にサインインできるだけでなく、実際にTeams会議を作成し、予定表に反映されるところまで確認する必要があります。(GitHub)

トークンキャッシュと再認証

MSAL.NETはアクセストークンの取得やキャッシュに関わります。4.84.0では内部トークンキャッシュ関連のオプションも追加されているため、独自のトークンキャッシュ、分散キャッシュ、ユーザーセッション連携を実装している場合は、ログイン直後だけでなく時間経過後の再取得も確認してください。(GitHub)

確認すべき具体例は次のとおりです。

テスト確認内容
初回ログインEntra IDのサインイン画面から正常に戻るか
再ログインCookieやキャッシュが残った状態で異常が出ないか
ログアウト後ログイン別ユーザーでログインして会議作成できるか
トークン期限後時間経過後にGraph API呼び出しが失敗しないか
権限不足ユーザー適切なエラー表示になり、不要な情報をログに出さないか

.NET Core 3.1環境ではMSAL更新だけで終わらせない

このPRの対象ファイルを見ると、現行のプロジェクトはnetcoreapp3.1をターゲットにしています。NuGet上のMicrosoft.Identity.Client 4.84.0は.NET Standard 2.0を含むため、互換性上は利用できる可能性がありますが、アプリ本体を.NET Core 3.1のまま運用し続けることは別問題です。(GitHub)

Microsoftの公式サポートポリシーでは、.NET Core 3.1は2022年12月13日にサポート終了しています。つまり、MSAL.NETだけを新しくしても、アプリ基盤そのものの保守リスクは残ります。(Microsoft)

実務では、次のように分けて判断すると失敗しにくくなります。

判断軸短期対応中長期対応
MSAL.NET4.84.0へ更新して認証テスト定期的に最新minorへ追随
.NET実行環境既存環境でビルド・動作確認サポート中の.NETへ移行計画を作る
Microsoft Graph既存権限で会議作成を検証Graph SDKやAPI仕様の更新も確認
セキュリティ古いMSAL利用を解消シークレット、証明書、監査ログを見直す

特に本番で使っている場合、「依存関係更新」と「アプリ基盤の刷新」を同じリリースで一気に行うと、障害時の原因切り分けが難しくなります。まずMSAL.NET更新をステージングで検証し、その後に.NET移行を別プロジェクトとして計画するのが現実的です。

移行前に確認するチェックリスト

Microsoft.Identity.Clientを4.84.0へ上げる前に、次の項目を確認してください。

チェック項目確認方法問題があった場合の対応
現在のMSALバージョンdotnet list packageで確認4.46.0以前なら更新候補に入れる
直接参照か推移的参照か.csprojやDirectory.Packages.propsを見る直接参照なら明示的に更新、推移的参照なら親パッケージも確認
ターゲットフレームワーク.csprojのTargetFrameworkを確認netcoreapp3.1なら将来の.NET移行も検討
Graph権限Entra IDのアプリ登録で確認OnlineMeetings.ReadWrite、Calendars.ReadWriteの同意状況を確認
クライアントシークレット有効期限を確認期限切れ前にローテーション
リダイレクトURIローカル・本番URLを確認signin-oidcやsignout-oidcの不一致を修正
トークンキャッシュ独自実装の有無を確認期限切れ後・別ユーザー切替時の動作をテスト
ログ出力認証エラー時のログを確認トークンや個人情報を出さないようにする

更新作業の進め方

ローカルまたはステージング環境で、まず依存関係の状態を確認します。

dotnet list package
dotnet list package --outdated

対象プロジェクトでMicrosoft.Identity.Clientを4.84.0へ更新します。

dotnet add TeamsMeetigSchedulerWebsite/TeamsMeetigSchedulerWebsite.csproj package Microsoft.Identity.Client --version 4.84.0
dotnet restore
dotnet build

ビルドが通ったら、すぐに本番反映するのではなく、次の順でテストします。

順序テスト内容合格基準
1ローカル起動アプリが起動し、認証画面へ遷移できる
2サインインEntra ID認証後、アプリに戻れる
3Teams会議作成Graph API経由でTeams会議が作成される
4予定表反映予定表に会議情報が登録される
5ログアウトセッションが切れ、再ログインできる
6権限不足テスト権限不足時に適切なエラーになる
7ステージングデプロイ本番相当のURL・シークレット・権限で動く

テストで特に見落としやすいのは「初回ログインは成功するが、2回目以降や別ユーザー切替で失敗する」ケースです。これはCookie、トークンキャッシュ、アカウント選択、同意済み権限の組み合わせで起きやすいため、複数ユーザーで確認してください。

依存関係の競合にも注意する

Microsoft.Identity.Client 4.84.0では、NuGet上でMicrosoft.IdentityModel.Abstractions、System.Diagnostics.DiagnosticSource、System.Formats.Asn1、System.Text.Jsonなどの依存関係が表示されています。古いASP.NET Core、古いGraph SDK、独自に固定したパッケージがある場合、復元時や実行時にバージョン競合が起きることがあります。([NuGet][7])

競合が出た場合は、エラー文だけで判断せず、次の順に切り分けます。

症状よくある原因対応
dotnet restoreで失敗依存パッケージのバージョン固定固定バージョンを確認し、必要なら更新
ビルドは通るが起動で失敗実行環境の古いランタイムApp Serviceやサーバーのランタイムを確認
サインイン後に失敗リダイレクトURIやCookie設定の不一致本番URLとアプリ登録を照合
Graph APIが403になるAPI権限または管理者同意不足Entra IDで権限と同意状態を確認
ログに詳細が出ない例外処理やログ設定不足Correlation IDを含めて記録する

すぐマージしてよいケース、慎重に進めるケース

今回の更新は、古いMSAL.NETを使い続けるリスクを下げる意味では前向きな変更です。ただし、すべての環境で即時マージしてよいとは限りません。

判断状況
すぐ進めやすいサンプルに近い構成で、独自のトークンキャッシュやClient Assertionを使っていない
すぐ進めやすいステージング環境があり、ログインからTeams会議作成まで自動または手動テストできる
慎重に進めるnetcoreapp3.1のまま本番運用している
慎重に進める独自の分散トークンキャッシュ、証明書認証、mTLS、Managed Identityを使っている
慎重に進めるGraph SDKやASP.NET Core関連パッケージも古く、依存関係が複雑
いったん保留も検討本番相当の検証環境がなく、認証障害時の影響が大きい

重要なのは、「4.84.0へ上げるかどうか」だけでなく、「上げたあとにTeams会議作成まで確実に確認できるか」です。認証ライブラリの更新は、画面上は小さく見えても、障害が出るとユーザーが会議を作成できなくなる可能性があります。

よくある失敗と回避策

PRがOpenなのに反映済みだと思い込む

GitHubのDependabot PRは、作成された時点ではまだ本番やmainブランチに反映されていない場合があります。今回のPRも確認時点ではOpenで、mainへ1コミットをマージしようとしている状態です。(GitHub)

運用中の環境で確認する場合は、GitHubのPRだけでなく、自社リポジトリのブランチ、デプロイ履歴、実際のビルド成果物に含まれるパッケージバージョンを確認してください。

ビルド成功だけで完了にする

MSAL.NETの更新で最も危険なのは、ビルド成功をもって完了扱いにすることです。認証ライブラリは、ビルド時よりも実行時のサインイン、トークン更新、Graph API呼び出しで問題が出やすい領域です。

最低でも、次の実動作を確認してください。

  • 新規サインイン
  • 既存ユーザーの再サインイン
  • 別ユーザーへの切り替え
  • Teams会議の作成
  • 予定表への反映
  • ログアウト後の再ログイン
  • 権限不足時のエラー表示

.NET Core 3.1のリスクを見落とす

サンプルの現行プロジェクトはnetcoreapp3.1を対象にしていますが、.NET Core 3.1はすでにサポート終了済みです。MSAL.NETを更新しても、ランタイムやASP.NET Core基盤の古さは解消されません。(GitHub)

短期的にはMSAL更新で依存関係のリスクを下げつつ、中長期ではサポート中の.NETへ移行する計画を作るべきです。

Newtonsoft.Jsonの扱いを誤解する

4.84.0ではMSAL内部のNewtonsoft.Json依存が削除され、System.Text.Json中心へ移行しています。ただし、TeamsMeetingsWebSchedulerの現行.csprojにはNewtonsoft.Json 13.0.1の参照もあります。つまり、MSAL側の変更によってアプリ側のNewtonsoft.Json利用が自動的に消えるわけではありません。(GitHub)

アプリコードでNewtonsoft.Jsonを使っている場合は、その用途を別途確認してください。

最後にやるべきこと

今回のMicrosoft Teams documentation update: Bump Microsoft.Identity.Client from 4.46.0 to 4.84.0で、Teams一般ユーザーが操作することはありません。一方で、Teams会議作成アプリやGraph連携アプリを運用している開発者は、古いMSAL.NETを使い続けないための重要な更新として扱うべきです。

次に取るべき行動は明確です。

順番行動
1自社リポジトリでMicrosoft.Identity.Clientのバージョンを確認する
24.46.0など古いバージョンなら、4.84.0への更新を検討する
3ステージング環境でサインイン、Teams会議作成、予定表反映を確認する
4依存関係と.NET実行環境の古さを確認する
5問題がなければ本番反映し、認証エラーとGraph APIエラーを監視する

特に、netcoreapp3.1のまま運用している場合は、今回のMSAL.NET更新をきっかけに、.NET基盤そのものの更新計画も立ててください。依存関係の更新は単なる保守作業ではなく、Teams連携アプリを安全に動かし続けるための土台作りです。

[3]: https://www.nuget.org/packages/Microsoft.Identity.Client/4.46.0 “
NuGet Gallery
| Microsoft.Identity.Client 4.46.0
“
[7]: https://www.nuget.org/packages/Microsoft.Identity.Client/4.84.0 “
NuGet Gallery
| Microsoft.Identity.Client 4.84.0
“

Teams
Microsoft Teams NuGet Microsoft Graph MSAL.NET Microsoft.Identity.Client

この記事を書いた人

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

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

関連記事

コメント

コメントする

目次