AIものさし

Microsoft EntraのAADSTS700016をClient ID・Tenant・Service Principalから切り分ける

Microsoft EntraのAADSTS700016を、Client ID・tenant・service principalの対応関係から切り分ける方法を説明します。

AIものさし編集部

AADSTS700016が出たときは、まずエラー全文と要求先tenantを記録し、Microsoftの最新エラーコードlookupで700016の説明を確認します。Microsoftはエラー説明・コードが変わり得るとして、最新lookupを参照するよう案内しています。表示された説明と、認証要求のApplication (client) ID・tenant設定を照合し、コードだけで原因を断定しません。

目次

まずエラーの識別情報を分けて記録する

修正前に、失敗した一回の認証要求から次を控えます。パスワード、client secret、access tokenは記録票へ貼りません。

  • AADSTS700016を含むerror codeとerror description

  • エラー画面または認証要求に表示されたapplication identifier（値そのものを共有する必要はありません）

  • 認証先authorityのhostとtenant部分（実際のtenant IDやドメインは社内の安全な記録に限定）

  • 失敗時刻、trace ID、correlation ID

  • 使用したアプリ、環境（開発・検証・本番）、MSALなどの認証ライブラリと設定元

  • 対象ユーザーのアカウント種別（個人Microsoftアカウント、組織アカウント、ゲストなど）

Microsoftの認証エラー応答には診断用のerror code、description、timestamp、trace ID、correlation IDが含まれる場合があります。Microsoftはコードや文言が変更され得ると説明しているため、実際の画面で表示された完全なコードとdescriptionを保存し、記事の例文だけで原因を決めないでください。最新の個別コード説明はMicrosoftのエラー検索でも照合します。

1. Client IDと別の識別子を取り違えていないか

Microsoft EntraのClient IDは、アプリ登録に割り当てられるApplication (client) IDです。GUID形式の値で、アプリの登録先ディレクトリにあるApplication objectを識別します。一方、Tenant IDはディレクトリを識別し、Object IDはそのディレクトリ内の特定のオブジェクトを識別します。APIのApplication ID URI（identifier URI）やSAMLのEntity IDも別の用途の識別子です。値がどれもGUIDまたはURIのように見えても、同じ欄に代入できるとは限りません。

設定画面と設定ファイルで、名前付きの値を一つずつ照合します。App registrationsのOverviewにあるApplication (client) IDを、MSALのclientId設定と比較し、Tenant IDまたはauthorityのtenant部分は同じアプリのDirectory (tenant) IDや、利用対象テナントの値と別に照合します。SAMLのIdentifier (Entity ID)、APIのApplication ID URI、Enterprise applicationsのObject IDをclientIdとして設定していないかも確認します。画面のラベルを見ずに値だけをコピーすると、別IDを誤用しやすくなります。

表は横にスクロールできます

値何を識別するか主な確認場所確認時の注意
Application (client) IDアプリ登録（application object）App registrations > OverviewMSAL設定のclientIdと照合
Directory (tenant) IDディレクトリアプリ登録やEntra tenantの概要認証先authorityと照合
Object IDtenant内の特定オブジェクトApp registrationsまたはEnterprise applicationsApplication IDと混同しない
Application ID URI / identifier URIAPIなどresourceの識別子App registrations > Expose an APIclientIdの代替値ではない
SAML Identifier (Entity ID)SAMLサービスプロバイダーの識別子Enterprise applications > Single sign-onOAuth/MSALのclientIdとは用途が異なる

最初の判断は「設定値が間違っている」と決めることではなく、「エラーに表示された識別子が、どの設定欄の何を指しているか」を確認することです。たとえば、アプリのClient IDが正しくても、authorityが想定外のtenantを指していれば、認証要求は別のディレクトリでアプリを探します。逆に、tenantが正しくてもclientIdにApplication ID URIや別環境のClient IDが入っていれば、同じエラーが起き得ます。

2. 認証要求のauthorityとtenantを照合する

MSALやアプリ設定に書かれたauthorityは、認証要求をどのMicrosoft identity platformのtenant contextへ送るかを決めます。固定のtenant ID、ドメイン名、common、organizationsなどのauthority選択は、アプリが許可するアカウント種別や想定するログイン体験と一致している必要があります。アプリ登録のSupported account typesがsingle-tenantなのに、任意の組織tenantで使う前提のauthorityを設定している、または別のtenantにあるアプリ登録を現在のtenant内で探している場合は、設定とアプリの範囲が合っているか確認します。

次の順で、値の出所と一致を点検します。

  1. 起動した環境で読み込まれたclientId、authority、redirect URIの設定元を特定する。環境変数、設定ファイル、デプロイ設定、ビルド時設定で異なる値がないかを確認する。

  2. そのclientIdが属するApp registrationを、登録したhome tenantで確認する。開発用・本番用の複数アプリがある場合は、環境名だけで選ばず、Client IDを照合する。

  3. 認証要求のauthority tenantと、利用者がログインしようとしているtenantを分けて確認する。ログインしたアカウントが存在するtenantと、アプリ登録が置かれているhome tenantは同じとは限らない。

  4. アプリのSupported account typesと、実際にサインインするアカウント（組織／個人／外部ユーザー）を照合する。

  5. 認証要求を再実行する前に、変更候補・元の値・変更理由・戻し方を記録する。複数の設定を同時に変更しない。

単一テナントアプリは登録した組織ディレクトリを対象にし、マルチテナントアプリは他のMicrosoft Entra tenantのアカウントも利用可能にする構成です。ただし「multitenantに変更すれば必ず直る」という意味ではありません。アプリの実際の提供範囲、登録時のSupported account types、組織の同意ポリシー、API permission、認証フローを確認せずにアカウント種別を広げると、意図しない利用者へサインイン範囲を広げることがあります。

3. Enterprise application / Service principalとconsentを確認する

Application objectはアプリの登録元tenantにあり、service principalは各tenant内でそのアプリを表すローカルのインスタンスです。マルチテナントアプリを別の組織tenantで利用する場合、そのtenant側にservice principal（Enterprise application）が作られているかが重要になります。Microsoftの資料では、別tenantのユーザーがアプリへ同意した際に、対象tenant内のservice principalとconsent情報が作成される流れを説明しています。tenantのポリシーによってユーザー同意が許可されない場合や管理者同意が必要な場合は、同意手順を管理者が判断します。

確認するのは次の項目です。

  • 対象tenantのEnterprise applications一覧に、該当Client IDのアプリが存在するか。名前だけで検索せず、Client IDまたはアプリの識別情報を照合する。

  • 対象アプリのSupported account typesが、外部tenantの利用を許可する想定か。

  • そのtenantで利用者同意が許可されるか、管理者同意が必要か。必要な場合、同意するpermissionと依頼先の管理者を確認する。

  • すでにservice principalがある場合、無効化、ユーザー割当必須、サインイン制限などのtenant側設定がないか。

  • 同じ表示名のアプリが複数存在しないか。不要なservice principalを削除して整理する前に、利用者・所有者・サインインログを確認する。

Service principalが見つからない場合は、アプリが対象tenantで利用可能な設計かを先に確認します。アプリがsingle-tenantなら、対象tenantにそのアプリを追加するだけでクロステナント利用できるとは限りません。multitenantなら、利用者または管理者によるconsentで対象tenantにアプリのservice principalが作られる場合があります。どのpermissionを誰が承認すべきかはアプリが要求するアクセス範囲とtenantポリシーによって異なります。エラー解決だけを理由に、広い権限を付与したり、組織の同意ポリシーを回避したりしないでください。

4. SAMLの識別子を使っている場合は別経路で診断する

SAML構成を含む環境でAADSTS700016が表示された場合も、エラーが発生した要求のプロトコルを確認します。Microsoftのエラーコード説明だけではSAML側の原因までは特定できないため、OAuth/OIDCのClient ID・tenant設定とSAML設定を混同せず、実際の要求形式に沿って調べます。SAMLのEntity ID／Identifierはサービスプロバイダーを識別する値であり、App registrationのApplication (client) IDとは別のフィールドです。SAMLの設定画面にある識別子をMSALのclientIdに転記した、または逆にOAuthのClient IDをSAMLのEntity IDとして設定した、といった混同がないかを切り分けます。

SAML利用時は、Enterprise applicationsのSingle sign-on設定、アプリ側metadata、受信した認証要求のissuer、reply URL、対象tenantを同じ環境の値で照合します。アプリ側とEntra側でEntity IDやreply URLが一致するかは、該当アプリのSAML設定に基づいて確認します。OAuth/MSAL利用時のauthorityやclientIdの変更を、SAML構成へそのまま適用しないでください。プロトコルが不明なら、サインインを開始したアプリの認証ライブラリ、authorize endpoint、SAML requestの有無をアプリ担当者に確認してから修正候補を選びます。

原因別に次の確認を選ぶ

以下の表は原因を断定する診断結果ではなく、証拠に応じて次の確認を選ぶための分岐です。1回に1か所だけ修正し、設定変更後は同じユーザー・同じ環境・同じ認証フローで再現するかを確認します。

表は横にスクロールできます

観察された不一致まず確認するもの安全な次の手順
clientIdがApp registrationのApplication (client) IDと異なる設定値の出所、dev/prod設定アプリ所有者に正しい環境値を確認し、該当設定だけを修正
authorityのtenantと利用対象tenantが異なるauthority、テナント選択、アカウント種別アプリの設計に沿うtenant authorityを選ぶ。任意tenantへ無断で広げない
single-tenant登録を他組織tenantから使おうとしているSupported account types、アプリの提供範囲登録所有者に設計を確認。必要なら正式なマルチテナント対応判断へ進む
multitenantだが対象tenantにアプリが見当たらない対象tenantのEnterprise applications、consent policytenant adminへ、アプリと要求permissionを添えてconsent要否を確認
Application ID URI、Object ID、SAML Entity IDをclientId欄に設定設定項目のラベルとプロトコルClient ID欄にはApplication (client) IDを使う設計か確認し、SAMLはSAML設定を別確認
どの設定値も一致し、error descriptionが別の条件を示すtrace/correlation ID、サインインログ、アプリ固有設定エラーの最新説明とtenant sign-in logsを管理者・アプリ担当者と照合

変更前後で安全に確かめる

アプリ設定を変更する権限がない場合、または本番認証へ影響する場合は、原因候補を絞った記録を作り、アプリ管理者へ引き継ぎます。依頼には、エラーコード、発生時刻、trace/correlation ID、対象環境、authorityのtenant識別（共有可能な範囲）、利用アカウント種別、Client IDの照合結果、アプリがsingle/multitenantのどちらとして登録されているか、対象tenantにservice principalが見えるかを含めます。token、secret、ユーザーの個人情報は添付しません。

変更後の確認も、単にサインイン画面が閉じたかだけでは不十分です。予定したtenantへ遷移したか、想定したアカウント種別でログインしたか、アプリが必要な最小permissionで動いたか、既存ユーザーや別環境に影響していないかを確認します。consentを追加した場合は、承認されたアプリ・permission・tenant・承認者を記録し、不要な権限が残っていないか管理者と点検します。

変更を止めて管理者へ渡す条件

次のどれかに当てはまる場合、試行的な設定変更を続けず、アプリ所有者またはtenant adminへ確認します。

  • Client IDの所有者・用途・環境を特定できない。

  • 認証要求がどのtenantへ送られたか分からない。

  • single-tenantをmultitenantへ変更する必要があるか判断できない。

  • user consentとadmin consentのどちらが必要か、要求permissionを含めて確認できない。

  • 同名のEnterprise applicationが複数あり、どれが対象か分からない。

  • 本番アプリ、既存のSSO、テナント全体の同意ポリシーへ影響する。

  • エラーコードは同じでも、最新のerror descriptionやsign-in logsが別の原因を示す。

AADSTS700016の初動では、まず「どのアプリ識別子を、どのtenantへ送った要求か」を分けて照合します。Application (client) IDとTenant ID、Object ID、Application ID URI、SAML Entity IDを混同せず、アプリ登録のSupported account typesと認証先authorityが一致するか確認します。外部tenantで使うmultitenant appなら、対象tenantのEnterprise application/service principalとconsent条件を管理者と照合します。設定の所有者・tenant・permissionを特定できないときは変更を止め、診断情報をそろえて管理者へ引き継ぐのが安全です。

参考資料

確認日：2026-10-15