入れ子になったアプリ認証と Outlook レガシトークンの非推奨に関する FAQ

2025-06-18

Exchange ユーザー ID トークンとコールバックトークンは非推奨となり、2025 年 6 月までに完全にオフになります。従来の Exchange トークンを使用する Outlook アドインを、入れ子になったアプリ認証に移動することをお勧めします。

一般的な FAQ

入れ子になったアプリ認証 (NAA) とは

入れ子になったアプリ認証を使用すると、Outlook などのサポートされている Microsoft アプリケーション内に入れ子になったアプリケーションのシングルサインオン (SSO) が有効になります。 NAA は、既存の完全信頼認証モデルや代理フローと比較して、セキュリティが向上し、アプリアーキテクチャの柔軟性が向上し、クライアント主導の豊富なアプリケーションを作成できます。詳細については、「入れ子になったアプリ認証を使用して Office アドインで SSO を有効にする」を参照してください。

従来の Exchange オンライントークンをシャットダウンするためのタイムラインは何ですか?

レガシ Exchange オンライントークンは、ほとんどのテナントで既にオフになっています。管理者がテナントとアドインの Exchange トークンを再び有効にするツールを提供しました(これらのアドインがまだ NAA に移行されていない場合)。詳細については、「レガシトークンを再び有効にできますか?」を参照してください。

Date	レガシトークンの状態
Now	ほとんどのテナントでレガシトークンがオフになっています。管理者は、PowerShell を使用してレガシトークンを再び適用できます。
2025 年 6 月 16 日から 2025 年 7 月	レガシトークンは、すべてのテナントでオフになります。このプロセスの完了には数週間かかります。管理者は、PowerShell を使用してレガシトークンを再び適用できなくなりました。管理者は、https://aka.ms/LegacyTokensByOctoberでMicrosoft サポートを通じて例外を要求できます (このリンクでは、テナントにサインインする必要があります)。
2025 年 10 月	すべてのテナントでレガシトークンがオフになっています。例外は許可されなくなりました。

チャネルで NAA が一般公開されるのはいつですか?

NAA の一般公開 (GA) の日付は、使用しているチャネルによって異なります。

Date	NAA 一般提供 (GA)
2024 年 10 月	NAA は現在のチャネルの GA です。
2024 年 11 月	NAA は、月次エンタープライズチャネルの GA です。
2025 年 1 月	NAA は、Semi-Annual チャネルビルド 16.0.17928.20392 の GA です。
2025 年 6 月	NAA は拡張チャネル Semi-Annual GA します。

操作方法拡張チャネルでオフになっているレガシトークン Semi-Annual 処理します。NAA はまだサポートされていませんか?

Semi-Annual 拡張チャネルは、2025 年 6 月まで NAA をサポートしません。これは、NAA をサポートするようにアドインが更新され、レガシ Exchange Online トークンを使用しなくなった場合でも、このチャネルでは機能しないことを意味します。 Semi-Annual 拡張チャネルを管理者として使用している場合は、次のことをお勧めします。

テナントが、レガシ Exchange Online トークンを必要とするアドインを使用しているかどうかを確認します。詳細については、「レガシ Exchange Online トークンを使用する Outlook アドインを検索する」を参照してください。
レガシ Exchange Online トークンを必要とするアドインをデプロイしており、organizationにアドインが必要な場合は、引き続き機能するようにトークンを有効にすることをお勧めします。トークンを有効にするには、「レガシ Exchange Online トークンのオンとオフを切り替える」を参照してください。

COM アドインは、レガシ Exchange Online トークンの廃止の影響を受けるのですか?

従来のExchange Online トークンの廃止によって COM アドインが影響を受ける可能性は非常に低いです。 Outlook Web アドインは主に、Exchange トークンに依存 Office.js API を使用できるため、影響を受ける可能性があります。詳細については、「 Outlook アドインがレガシトークンに依存しているかどうかを確認する方法」を参照してください。 Exchange トークンは、Exchange Web Services (EWS) または Outlook REST API にアクセスするために使用されます。どちらも非推奨です。 COM アドインが影響を受ける可能性がある場合は、Exchange トークンがオフになっているテナントで使用してテストできます。詳細については、「レガシ Exchange Online トークンのオンとオフを切り替える」を参照してください。

Microsoft 365 管理者の質問

organizationのどのアドインが影響を受けますか?

Get-AuthenticationPolicy コマンドを使用して、テナントでレガシ Exchange Online トークンを使用するすべての Outlook アドインの一覧を取得します。詳細については、「レガシ Exchange Online トークンのオンとオフを切り替える」を参照してください。アドインの一覧が表示されたら、パブリッシャーに連絡して、更新する計画の詳細を確認する必要があります。場合によっては、アドインは独自のorganizationによって開発される場合があります。 organizationの適切な開発チームに連絡する必要があります。

発行元を識別するために使用できるコマンドは何ですか?

Outlook アドインに関する追加情報を追跡するために使用できる PowerShell コマンドExchange Onlineがいくつかあります。

ユーザーのコンピューターにインストールされているアドインの一覧を見つけるには、次のコマンドを実行します。

Get-App | Select-Object -Property ProviderName, DisplayName, AppId

次のスクリーンショットは、 Get-App コマンドの実行例を示しています。

Microsoft Polls と Microsoft Send to OneNote の結果を含む PowerShell で Get-App コマンドを実行しているスクリーンショット。

ProviderName を使用すると、アドインを公開したユーザーを特定して、アドインに連絡できるようになります。 AppId を使用して、アドインに関する追加の詳細を取得できます。

注:

Get-App コマンドには、ユーザーのコンピューターにインストールされているすべてのアドインの完全な一覧は表示されません。たとえば、サイドロードされたアドインは、この一覧には表示されません。場合によっては、アドインがどこから来たのかを追跡するために、ユーザーのフォローアップが必要になる場合があります。

AppIdでアドインに関する情報を見つけるには、次のコマンドを使用します。

Get-App -Identity {identity} | Select-Object -Property ProviderName, DisplayName

次のスクリーンショットは、Bing地図の ID を使用して詳細情報を取得する例を示しています。

PowerShell で Get-App コマンドを実行して、Bing地図の ProviderName と DisplayName を取得するスクリーンショット。

アドインのマニフェストファイルに追加情報が表示される場合もあります。マニフェストには URL エンドポイントが含まれています。これは、発行元を特定して連絡するのにも役立ちます。マニフェストを取得するには、次のコマンドを使用します。

Get-App -Identity {identity} | Select-Object -Property ManifestXml

次のスクリーンショットは、ID を使用してBing地図の XML マニフェストを取得する例を示しています。

PowerShell で Get-App コマンドを実行して、Bing地図の ManifestXml を取得するスクリーンショット

注:

Microsoft AppSource から展開した Outlook アドインは、公開したリストを使用して識別できます。テストは必要ありません。詳細については、「Microsoft AppSource に発行されたアドイン操作方法識別する」を参照してください。

操作方法 Microsoft AppSource に発行されたアドインを識別する

2025 年 4 月の時点でレガシトークンを使用する Microsoft AppSource に公開されているすべての Outlook アドインの一覧を掲載しました。一覧を使用して、レガシトークンを使用する可能性がある Outlook アドインのレポートを作成する方法の詳細については、「レガシ Exchange Online トークンを使用する Outlook アドインを検索する」を参照してください。

ISV は、アドインがレガシトークンを使用しているのをどのように認識しますか?

アドインでは、レガシトークンを使用して、EWS または Outlook REST API を介して Exchange からリソースを取得できます。アドインでは、一部のユースケースでは Exchange リソースが必要な場合もあれば、他のユースケースでは必要な場合は必要な場合があるため、アドインに更新プログラムが必要かどうかを判断するのが困難な場合があります。アドインの開発者と所有者に問い合わせ、アドインコードが次の API を参照しているかどうかを確認することをお勧めします。

makeEwsRequestAsync
getUserIdentityTokenAsync
getCallbackTokenAsync

アドインに ISV を使用する場合は、できるだけ早く連絡して、従来の Exchange トークンから移行するためのプランとタイムラインがあることを確認することをお勧めします。 ISV 開発者は、Exchange レガシトークンの終了の準備ができていることを確認するために、Microsoft の連絡先に質問を直接連絡する必要があります。 organization内の開発者に依存している場合は、この FAQ と「入れ子になったアプリ認証を使用して Office アドインで SSO を有効にする」の記事を確認する必要があります。質問は、OfficeDev/office-js GitHub issue サイトで提起する必要があります。

特定できないアドインに対して何を行うのですか?

Get-AuthenticationPolicy実行した後に、所有者を識別できないカスタムアドインがいくつか存在する可能性があります。これらのアドインでは、絶叫テストを実行する必要がある場合があります。管理者は、2025 年 6 月より前に絶叫テストを実行して、6 月にレガシトークンがオフになると壊れるアドインが残っているかどうかを判断することをお勧めします。これにより、影響を受けるアドインの発行元に連絡して、6 月の期限前に重大な問題に対処する時間が得られます。

注:

Set-AuthenticationPolicy コマンドを使用してレガシ Exchange Online トークンをオンにした場合にのみ、絶叫テストを実行する必要があります。このコマンドを実行していない場合は、Exchange Onlineトークンは既定で既にオフになっているはずです。

絶叫テストを実行する前に、メールなどのユーザーに、レガシトークンをオフにするテストがあり、一部の Outlook アドインに影響を与える可能性があることを事前に知らせておく必要があります。ユーザーに次の情報を提供することを検討する必要があります。

テストの予想される期間。
既に特定した Microsoft AppSource から展開されたアドインなど、壊れる既知の Outlook アドインがある場合。
一般に、Outlook アドインは壊れるべきではありません。ただし、問題が発生した場合は、ユーザーに、名前とアドインの説明と、観察されたエラー情報を報告するように求めます。

次の手順を使用してテストを実行します。

次のコマンドを実行して、テナントのレガシ Exchange Online トークンをオフにします。このコマンドの使用方法の詳細については、「レガシ Exchange Online トークンのオンとオフを切り替える」を参照してください。

Set-AuthenticationPolicy -BlockLegacyExchangeTokens -Identity "LegacyExchangeTokens"
ユーザーがアドインに関する問題を報告するのに適した時間待ちます。コマンドがすべてのユーザーのレガシ Exchange Online トークンをオフにするには、約 24 時間かかります。ユーザーが Outlook アドインに関する問題を報告するには、1 日または 2 日かかる場合があります。
影響を受ける Outlook アドインを特定します。ユーザーが重大な問題を特定する問題を送信する場合は、影響を受ける Outlook アドインの名前と説明を必ず取得してください。また、エラーまたは動作をキャプチャして、この情報をパブリッシャーに渡すこともできます。
ビジネスクリティカルなアドインが破損している場合は、次のコマンドを使用してトークンを有効に戻します。このコマンドの使用方法の詳細については、「レガシ Exchange Online トークンのオンとオフを切り替える」を参照してください。

Set-AuthenticationPolicy -AllowLegacyExchangeTokens -Identity "LegacyExchangeTokens"

テナント上のすべてのユーザーに対してトークンが再度有効になるまでに約 24 時間かかります。
重大な問題の報告がない場合は、セキュリティのベストプラクティスとしてレガシ Exchange Online トークンをオフのままにすることをお勧めします。

レガシトークンExchange Online再度有効にできますか?

はい。任意のテナントでレガシトークンのオンとオフを切り替えるために使用できる PowerShell コマンドがあります。レガシトークンのオンとオフを切り替える方法の詳細については、「レガシ Exchange Online トークンのオンとオフを切り替える」を参照してください。

2025 年 6 月には、レガシトークンはオフになり、再度有効にすることはできません。管理者は、https://aka.ms/LegacyTokensByOctoberでMicrosoft サポートを通じて例外を要求できます (このリンクでは、テナントにサインインする必要があります)。 2025 年 10 月には、レガシトークンを有効にすることはできず、すべてのテナントで無効になります。

独立系ソフトウェアベンダー (ISV) は、Entra ID トークンと Microsoft Graph スコープを使用するようにアドインを更新しています。アドインがアクセストークンを要求する場合は、管理者またはユーザーの同意が必要です。管理者が同意した場合、テナント上のすべてのユーザーは、アドインで必要なスコープにアドインを使用できます。それ以外の場合、ユーザーの同意が有効になっている場合は、各エンドユーザーに同意を求められます。ユーザーにプロンプトが表示されないため、エクスペリエンスを向上するには、管理者の同意を完了します。

同意のオプションの 1 つは、ISV が管理者の同意 URI を提供することです。

アドイン開発者は、管理者の同意 URI を提供します。これが提供するドキュメントに記載されていない場合は、詳細についてはお問い合わせください。
管理者は、管理者の同意 URI を参照します。
管理者はサインインを求め、アドインに必要なスコープの一覧に同意するように求められます。
完了すると、ブラウザーは ISV から Web ページにリダイレクトされます。これは、同意が成功したことを示すはずです。

別の方法として、ISV は、中央展開の一部として管理者の同意を求める更新されたアプリマニフェストを提供する場合があります。このシナリオでは、更新されたアプリマニフェストをデプロイすると、デプロイを完了する前に同意するように求められます。管理者の同意 URI は必要ありません。

最後に、アドインが Microsoft 365 ストアで公開されている場合、更新プログラムは自動的に展開され、管理者はスコープへの同意を求められます。管理者が同意しない場合、ユーザーは更新されたアドインを使用できません。

機能を無効にしたり、アドインに必要なアクセス許可を取り消したりしないようにします。例については、「メールボックスポリシーのプロパティの変更」を参照してください。アドインは委任されたアクセス許可を使用するため、サインインしているユーザーと同じリソースにアクセスできます。ただし、ポリシーまたは設定によって特定のリソースまたはアクションからユーザーがブロックされた場合、アドインもブロックされます。

ISV からアドイン更新プログラムをデプロイ操作方法。

従来の Exchange トークンを使用するアドインがある場合は、NAA を使用するようにアドインを移行するためのタイムラインに関する情報を ISV に問い合わせてください。 ISV がアドインを移行すると、ほとんどの場合、管理者の同意 URL が提供されます。詳細については、「管理者の同意フローのしくみ」を参照してください。

ISV では、一元化されたデプロイを通じてデプロイするための更新されたアプリマニフェストも提供される場合があります。一元展開中に、アドインで必要な Microsoft Graph スコープに同意するように求められる場合があります。このシナリオでは、管理者の同意 URI を使用する必要はありません。

アドインが Microsoft AppSource から展開されている場合は、ISV がアドインの更新プログラムをロールアウトするときに、Microsoft Graph スコープへの同意を求めるメッセージが表示される可能性があります。同意するまで、テナントのユーザーは NAA で新しいバージョンのアドインを使用できません。

管理者またはユーザーが同意すると、Microsoft Entra 管理センターに一覧表示されます。アプリの登録は、次の手順を使用して見つけることができます。

[ https://entra.microsoft.com/#home ] に移動し、テナントの管理者としてサインインします。
左側のナビゲーションウィンドウで、[ アプリケーション>Enterprise アプリケーション] を選択します。
[ エンタープライズアプリケーション ] ページの [ 管理 ] セクションで、[ すべてのアプリケーション] を選択します。
アドインを選択します。概要ページが開きます。 [概要] ページで、[ アクセス許可] を選択します。アクセス許可には 2 つのビューがあります。管理同意、およびユーザーの同意。 [ユーザーの同意] を選択して、個々の同意を確認します。

アドインを更新した発行元の一覧はありますか?

一部の広く使用されている Outlook アドインの発行元は、次に示すようにアドインを既に更新しています。

発行元がマニフェストを更新し、アドインが Microsoft ストア経由で展開されている場合は、管理者として更新プログラムをアップグレードして展開するように求められます。発行元がマニフェストを更新し、アドインが中央展開を通じてデプロイされる場合は、新しいマニフェストを管理者としてデプロイする必要があります。場合によっては、パブリッシャーがアドインの新しいスコープに同意するために使用する必要がある管理者の同意 URI を持っている場合があります。アドインの更新に関する詳細情報が必要な場合は、発行元に問い合わせてください。

一部のアドインは壊れている。 Exchange トークンがオフになっているかどうかを確認できますか?

アドインに問題があり、Exchange トークンの影響を受けている可能性がある場合は、次のアクションを実行してください。

既知のアドインの一覧を確認する

2024 年 10 月の時点で従来の Exchange トークンを使用していることがわかっているアドインの一覧を掲載しました。アドインがこの一覧にある場合は、発行元に連絡して、利用可能な更新プログラムがあるかどうかを確認する必要があります。詳細については、「レガシ Exchange Online トークンを使用する Outlook アドインを検索する」を参照してください。

Script Labを使用してトークンがオフになっているかどうかを確認する

Script Lab アドインを使用して、ユーザーのレガシ Exchange Online トークンがオフになっているかどうかを確認します。

Outlook 用のScript Labをインストールします。
影響を受けるユーザーアカウントまたはメールボックスを使用して Outlook にサインインします。交換トークンは 1 人のユーザーに対してオフにできますが、ロールアウトが完了するまで別のユーザーに対してはオフにすることはできません。
既存または新しいメールから、[アプリ] メニューからScript Labを開き、Script Lab メニューから [コード] を選択します。
[Script Lab] 作業ウィンドウで、backstage アイコン (3 行) を選択します。
[ サンプル ] を選択し、[ ユーザー ID トークンの取得 ] サンプルを検索します。このサンプルを選択して、コードエディターで開きます。
サンプルのコードが読み込まれた後、このウィンドウで[実行>Run] を選択します。
コードの実行後、[ トークンの取得] を選択します。

レガシ Exchange Online トークンがオンの場合は、Base64 でエンコードされた文字列としてコンソールにトークンが表示されます。

コンソールウィンドウに表示されるトークンのスクリーンショット。

レガシ Exchange Online トークンがオフの場合は、次に示すようにコンソールにエラーが表示されます。

コンソールウィンドウのエラーのスクリーンショット。

実際のエラーとコードは異なる場合がありますが、多くの場合、エラーコード 9017 または 9018 と次のエラーの説明が表示されます。

GenericTokenError: An internal error has occurred.
InternalServerError: The Exchange server returned an error. Please look at the diagnostics object for more information.

アドインが Exchange トークンの影響を受ける場合は、再度有効にすることができます。詳細については、「レガシトークンExchange Online再度有効にできますか?」を参照してください。

Outlook アドインの移行に関する FAQ

Microsoft が Outlook アドインを移行するのはなぜですか?

Entra ID トークンを使用して Microsoft Graph に切り替えることは、Outlook および Exchange のお客様のセキュリティの大きな向上です。 Entra ID (旧称 Azure Active Directory) は、クラウドベースの主要な ID およびアクセス管理サービスです。お客様は、条件付きアクセス、MFA 要件、継続的なトークン監視、リアルタイムの安全性ヒューリスティックなど、従来の Exchange トークンでは使用できないゼロトラスト機能を利用できます。お客様は Exchange に格納されている重要なビジネスデータを格納するため、このデータが確実に保護されていることが重要です。 Microsoft Graph でEntra ID トークンを使用するように Outlook エコシステム全体を移行すると、顧客データのセキュリティが大幅に向上します。

Outlook アドインを NAA に移行する必要がありますか?

いいえ。 Outlook アドインでは NAA を使用する必要はありませんが、NAA ではユーザーに最適な認証エクスペリエンスと組織に最適なセキュリティ体制が提供されます。アドインが従来の Exchange トークンを使用していない場合、Exchange トークンの非推奨の影響を受けることはありません。 Entra IDに依存する MSAL.js またはその他の SSO メソッドを使用するアドインは引き続き機能します。

Outlook アドインがレガシトークンに依存しているかどうかを確認操作方法。

アドインで従来の Exchange ユーザー ID トークンとコールバックトークンを使用しているかどうかを確認するには、コードで次の API の呼び出しを検索します。

makeEwsRequestAsync
getUserIdentityTokenAsync
getCallbackTokenAsync

アドインでこれらの API のいずれかを呼び出す場合は、NAA を採用し、代わりに Entra ID トークンを使用して Microsoft Graph にアクセスするように移行する必要があります。

スコープ内の Outlook アドインはどれですか?

多くの主要なアドインがスコープ内にあります。アドインが EWS または Outlook REST を使用してExchange Onlineリソースにアクセスする場合は、ほぼ確実に従来の Outlook トークンから NAA に移行する必要があります。アドインが Exchange オンプレミス専用 (Exchange 2019 など) の場合、この変更の影響を受けません。

NAA に移行しない場合、Outlook アドインはどうなりますか?

Outlook アドインを NAA に移行しないと、Exchange Onlineで期待どおりに動作しなくなります。 Exchange トークンがオフの場合、Exchange Onlineはレガシトークンの発行をブロックします。従来のトークンを使用するアドインは、Exchange オンラインリソースにアクセスできません。アドインが、 getUserIdentityTokenAsyncなどの Exchange トークンを要求する API を呼び出すと、9017 や 9018 などのエラーコードで次のような一般的なエラーが発生します。

"GenericTokenError: 内部エラーが発生しました。
"InternalServerError: Exchange サーバーからエラーが返されました。詳細については、診断オブジェクトを参照してください。

アドインがオンプレミスでのみ機能する場合、またはアドインが非推奨パスにある場合は、更新する必要がない場合があります。ただし、EWS または Outlook REST を介して Exchange リソースにアクセスするほとんどのアドインは、期待どおりに機能し続けるために移行する必要があります。

Outlook アドイン操作方法 NAA に移行しますか?

Outlook アドインで NAA をサポートするには、次のドキュメントとサンプルを参照してください。

操作方法最新のガイダンスに追いつくのですか?

新しい情報が利用可能になると、この FAQ が更新されます。 Office アドインコミュニティコールと M365 開発者ブログで、今後の追加のガイダンスについて説明します。最後に、OfficeDev/office-js GitHub issue サイトで NAA とレガシ Exchange Online トークンの非推奨に関する質問をすることができます。問題をグループ化して優先順位を付けることができるように、タイトルに "NAA" を配置してください。

問題を送信する場合は、次の情報を含めてください。

Outlook クライアントのバージョン。
Outlook リリースチャネルの対象ユーザー (クライアント用)。
問題のスクリーンキャプチャ。
問題が発生するプラットフォーム (Windows、Outlook (新規)、Mac、iOS、Android)。
問題が発生したセッション ID。
使用されているアカウントの種類。
msal-browser のバージョン。
msal-browser からのログ。

開発者の質問

MSAL と NAA からより多くのデバッグ情報を取得操作方法

入れ子になったパブリッククライアントアプリケーションを初期化するときに、msalConfig でデバッグ情報を有効にするには、次のコードを使用します。これにより、コンソールに追加の詳細が記録されます。

const msalConfig = {
  auth: {...},
  system: {
    loggerOptions: {
      logLevel: LogLevel.Verbose,
      loggerCallback: (level, message, containsPii) => {
        switch (level) {
          case LogLevel.Error:
            console.error(message);
            return;
          case LogLevel.Info:
            console.info(message);
            return;
          case LogLevel.Verbose:
            console.debug(message);
            return;
          case LogLevel.Warning:
            console.warn(message);
            return;
        }
      },
    }
  }
};

更新されたアドインをテストする

NAA を使用するようにアドインを更新したら、Mac、モバイル、Web、Outlook on Windows など、サポートするすべてのプラットフォームでテストする必要があります。

Exchange トークンがオフになっていることをテストする

Exchange トークンがオフになっているときにアドインが正しく動作することをテストするには、トークンがオフになっているテナントにアドインを展開してテストします。トークンをオフにするには、「レガシ Exchange Online トークンのオンとオフを切り替える」を参照してください。

コードで Exchange トークンを使用するパターンを実装したが、使用できない場合はフォールバックする場合は、正しいエラーを確認していることを確認してください。 Exchange トークンを取得するための呼び出しが失敗した場合は、asyncResult.診断をチェックします。次のいずれかのエラーが返された場合は、NAA に切り替えます。

GenericTokenError: An internal error has occurred.
InternalServerError: The Exchange server returned an error. Please look at the diagnostics object for more information.

Trident+ Webview のフォールバックコードをテストする

Outlook アドインが Windows でOutlook 2016または Outlook 2019 をサポートしている場合は、Trident+ (インターネットエクスプローラー 11) Webview が使用されている場合に正しく動作することをテストします。 Trident+ Webview を使用する場合、ダイアログを開いてユーザーにサインインするには、コードを MSAL v2 にフォールバックする必要があります。フォールバックパターンを実装する方法の詳細については、「インターネットエクスプローラーフォールバックを含む入れ子になったアプリ認証を使用した SSO を使用した Outlook アドイン」を参照してください。

注:

Outlook 2016と Outlook 2019 のサポートは、2025 年 10 月に終了します。詳細については、「 Office 2016 および Office 2019 のサポート終了」を参照してください。

Trident+ と WebView2 でのテスト

Outlook 2016と Windows 上の Outlook 2019 では、さまざまな OS 条件に基づいて Trident+ または WebView2 が使用されます。

Trident+ または Webview2 を使用する場合の詳細については、「 Office アドインで使用されるブラウザーと Webview コントロール」を参照してください。
実行されている Web ビューを特定する方法の詳細については、「古い Microsoft Webview と Office バージョンをサポートする」を参照してください。

注:

MSAL はどのようなトークンを返し、要求する最小スコープはありますか?

MSAL を使用してトークンを要求すると、常に 3 つのトークンが返されます。

トークン	用途	Scopes	`AuthencationResult` 財産
ID トークン	ユーザーに関する情報をクライアント (作業ウィンドウ) に提供します。	`profile` と `openid`	`authResult.idToken`
refreshtoken	有効期限が切れたときに ID とアクセストークンを更新します。	`offline_access`	注意事項なし。
アクセストークン	Microsoft Graph などのリソースに対する特定のスコープに対してユーザーを認証します。	`user.read`などのリソーススコープ。	`authResult.accessToken`

MSAL は常にこれら 3 つのトークンを返します。トークン要求に含まれていない場合でも、既定のスコープとして profile、 openid、 offline_access が要求されます。これにより、ID と更新トークンが確実に要求されます。ただし、アクセストークンを取得するには、 user.read などのリソーススコープを少なくとも 1 つ含める必要があります。そうでない場合、要求は失敗する可能性があります。

MSAL から ID トークンを検証する必要がありますか?

いいえ。これは、独自のリソースへのアクセスを承認するために Exchange トークンで使用されたレガシ認証パターンです。ネットワーク呼び出しを介して ID トークンを渡して、サービスへのアクセスを有効または承認することは、セキュリティ対策パターンです。 ID トークンはクライアント (作業ウィンドウ) のみを対象としており、サービスがトークンを確実に使用して、ユーザーがアクセスを承認したことを確認する方法はありません。 ID トークン要求の詳細については、「 ID トークン要求リファレンス」を参照してください。

常に独自のサービスへのアクセストークンを要求することが非常に重要です。アクセストークンには同じ ID 要求も含まれているため、ID トークンを渡す必要はありません。代わりに、サービスのカスタムスコープを作成します。独自のサービスのアプリ登録設定の詳細については、「保護された Web API: アプリの登録」を参照してください。サービスがアクセストークンを受け取ると、そのトークンを検証し、アクセストークン内から ID 要求を使用できます。

条件付きアクセスポリシーからエラーが発生する理由

承認されたクライアントアプリの条件付きアクセス許可は非推奨となり、2026 年 3 月に廃止されます。 MSAL NAA はこのポリシーをサポートしていないため、エラーが返されます (アドインにこのポリシーに例外を付与した場合でも)。このポリシーから移行するには、「条件付きアクセスで承認済みクライアントアプリをアプリケーション保護ポリシーに移行する」を参照してください。

一部の条件付きアクセスポリシーでは、クライアントに必要な内容に応じて、MSAL NAA を使用するアドインに問題が発生します。多くの場合、これらはデバイス管理ポリシーに関連しています。詳細については、「アプリ保護ポリシーを作成して割り当てる方法」の「デバイス管理の種類」を参照してください。

場合によっては、ポリシーに基づいて要求の課題を処理する必要があります。アドインで要求チャレンジを処理する方法の詳細については、「要求のチャレンジ、要求要求、およびクライアント機能」を参照してください。

ID トークンが更新されないのはなぜですか?

MSAL の有効期限が切れた後に ID トークンが更新されないという既知の問題があります。 ID トークンは、名前や電子メールなどの基本的なユーザー ID 情報を取得するために作業ウィンドウでのみ使用するため、アドインに問題は発生しません。 ID トークンを検証したり、有効期限要求をチェックしたりする理由はありません。ユーザーを独自のリソースに対して認証する必要がある場合は、ユーザー ID 情報も含むアクセストークンを使用します。 ID トークンを受け取ったクライアントコードの外部に渡してはなりません。

ユーザーがオンラインアカウントかオンプレミスアカウントかを判断操作方法

サインインしているユーザーが、Office.UserProfile.accountType プロパティを使用して、Exchange Online アカウントまたはオンプレミスの Exchange アカウントを持っているかどうかを判断できます。アカウントの種類のプロパティ値が エンタープライズの場合、メールボックスはオンプレミスの Exchange サーバー上にあります。ボリュームライセンスの永続的なOutlook 2016では、accountType プロパティはサポートされません。これを回避するには、Exchange オンプレミスサーバーの Exchange Web Service (EWS) で ResolveNames 操作を呼び出して、受信者の種類を取得します。

注:

アドイン操作方法 Microsoft AppSource にデプロイする

Microsoft AppSource に新しいアドインを発行する場合は、認定プロセスを経る必要があります。詳細については、「 Office アドインを Microsoft AppSource に発行する」を参照してください。 Microsoft AppSource に既に発行されているアドインのマニフェストを更新する場合は、認定プロセスをもう一度実行する必要があります。 Web サーバー上のアドインのソースコードは、認定プロセスを経ることなくいつでも更新できます。

アドインで NAA 経由の SSO を使用する場合、アドインは次の公開ガイドラインに準拠している必要があります。

管理者の同意を適切に処理してください。「Microsoft Graph スコープの管理者の同意が必要なアドインを発行する」を参照してください

展開の詳細については、「 Microsoft AppSource と Office 内でソリューションを使用できるようにする」を参照してください。アドインを更新 (マニフェストを変更) する場合は、認定プロセスをもう一度実行する必要があります。 Web サーバーコードは、レビューを必要とせずにいつでも更新できます。

サインイン時にユーザーが原因不明のエラーを受け取る

アドインがトークンを要求すると、次のいずれかのエラーを示すサインインポップアップダイアログがユーザーに表示される場合があります。

問題が発生しました。 [エラーコード]
ここからはアクセスできません

管理者が、モバイルの場所やプラットフォームの種類など、特定のクライアント制限を適用する条件付きアクセスポリシーが適用されているかどうかを確認します。また、 承認されたクライアントアプリの条件付きアクセス許可 は非推奨となり、NAA トークン要求でこれらのエラーが発生します。管理者は、このポリシーを完全に削除し、NAA が機能するための新しい アプリケーション保護ポリシー許可 に切り替える必要があります。詳細については、「条件付きアクセスで承認済みのクライアントアプリをアプリケーション保護ポリシーに移行する」を参照してください。