Microsoft Entra IDでクライアントシークレットを作り直したのに認証できない場合、最初に確認すべきなのは、実行環境へ設定した値です。
アプリが資格情報として使用するのは、クライアントシークレットの「Value」です。「Secret ID」ではありません。
また、Microsoft Entra IDで新しいシークレットを発行しただけでは、稼働中のアプリが使用する値は切り替わりません。アプリの環境変数、シークレットストア、サービス接続などに保存されている旧Valueを新しいValueへ差し替え、必要に応じて再起動や再デプロイを行う必要があります。
Valueは作成直後にしか表示されません。保存し忘れた場合、既存のValueを後から確認することはできないため、新しいクライアントシークレットをもう一度作成します。([Microsoft Learn][1])
実行環境へ設定するのはSecret IDではなくValue
Microsoft Entra IDの「Client secrets」一覧には、ValueとSecret IDという似た項目が表示されます。しかし、用途は異なります。
| 項目 | 役割 | 実行環境への設定 |
|---|---|---|
| Value | アプリが認証時に送信する秘密情報 | 必要 |
| Secret ID | 作成したシークレット項目を識別するためのID | 不要 |
| Application (client) ID | アプリ自体を識別するID | 通常は必要 |
| Directory (tenant) ID | Microsoft Entraテナントを識別するID | 認証方式によって必要 |
OAuth 2.0の設定画面や環境変数で「Client Secret」「Client Secret Value」「client_secret」などを求められた場合、設定するのはValue欄に表示された文字列です。
設定関係を簡略化すると、次のようになります。
CLIENT_ID=<Application (client) ID>
TENANT_ID=<Directory (tenant) ID>
CLIENT_SECRET=<Client secretのValue>上記の変数名は説明用の例です。実際の変数名は、利用しているアプリ、ライブラリ、ホスティングサービスによって異なります。
重要なのは、次の組み合わせを崩さないことです。
Application (client) ID
＋
同じアプリ登録で発行したClient secretのValue
＋
対象テナントのDirectory (tenant) ID別のアプリ登録で発行したValueを設定しても認証できません。クライアントIDとシークレットは、同じアプリ登録に属する組み合わせで使用します。
シークレットを作り直しただけでは認証は直らない
クライアントシークレットの更新は、Microsoft Entra ID側の作業と、アプリ側の作業に分かれます。
Microsoft Entra IDで新しいValueを発行
↓
実行環境のシークレットを新しいValueへ差し替え
↓
アプリを再起動・再デプロイ・再読込
↓
新しいValueで認証を確認
↓
不要になった旧シークレットを削除よくある失敗は、Microsoft Entra IDで新しいシークレットを追加した時点で、アプリ側も自動的に切り替わると思ってしまうことです。
Microsoft Entra IDは新しい資格情報を発行しますが、App Service、コンテナ、サーバー、CI/CDサービスなどに保存された旧Valueまでは変更しません。実行環境が引き続き旧Valueを送信していれば、認証エラーは解消されません。
クライアントシークレットのValueを新しく発行する手順
対象のアプリ登録を開く
Microsoft Entra管理センターで、次の順に開きます。
App registrations- 対象のアプリ
Certificates & secretsClient secretsNew client secret
「Enterprise applications」ではなく、シークレットを登録しているApp registrations側の対象アプリを開きます。([Microsoft Learn][1])
複数のアプリ登録がある場合は、実行環境に設定されているApplication（client）IDと、開いているアプリのIDが一致することを確認してください。
説明と有効期限を設定する
Descriptionには、後から用途が分かる名称を入力します。
例：production-web-2026-09
例：batch-server-rotation-2026
例：github-actions-deploy「secret1」「test」だけでは、どの環境で使用しているシークレットなのか分からなくなります。環境名、システム名、発行時期などを含めると管理しやすくなります。
有効期限も設定します。無期限で使い続ける前提にはせず、期限前に更新できる運用を用意してください。現行のMicrosoft公式ドキュメントでは、クライアントシークレットの有効期間は24か月以内に制限され、12か月未満の設定が推奨されています。仕様や画面上の選択肢は変更される可能性があるため、作成時の表示も確認してください。([Microsoft Learn][1])
Addを押した直後にValueを保存する
シークレットを追加したら、一覧に表示されたValueを直ちにコピーします。
Valueは作成直後の画面を離れると再表示されません。後からSecret IDをコピーしても、認証用の秘密情報としては使用できません。Valueを保存し忘れた場合は、そのシークレットを使おうとせず、新しいシークレットを作り直します。([Microsoft Learn][1])
保存先には、次のような秘密情報を扱える場所を使用します。
- クラウドサービスのシークレット設定
- Azure Key Vaultなどのシークレット管理サービス
- CI/CDサービスのSecret機能
- OSやコンテナの安全な環境変数
- 開発環境向けのユーザーシークレット機能
ソースコード、Gitリポジトリ、Wiki、チャット、チケット、手順書、記事本文には記載しません。スクリーンショットを撮る場合も、Valueが写り込まない状態にします。
実行環境の旧Valueを新しいValueへ差し替える
新しいValueを発行したら、アプリが実際に参照している保存先を特定します。
| 実行環境 | 主な確認先 |
|---|---|
| ローカル開発環境 | .env、ユーザーシークレット、OSの環境変数、ローカル設定ファイル |
| Azure App Service／Functions | アプリの構成、環境変数、Key Vault参照 |
| 仮想マシン | OSの環境変数、サービス設定、シークレット管理ツール |
| Docker／コンテナ環境 | コンテナの環境変数、シークレット、デプロイ定義 |
| Kubernetes | Secret、外部シークレット管理、デプロイ設定 |
| GitHub Actions | Repository secrets、Environment secrets |
| Azure DevOps Pipeline | サービス接続、シークレット変数、Variable Group、Key Vault連携 |
| オンプレミスのWebアプリ | Webサーバー設定、サービス設定、秘密情報ストア |
アプリがどの設定名を参照しているか分からない場合は、最初にソースコードやデプロイ定義で次のような文字列を検索します。
ClientSecret
client_secret
CLIENT_SECRET
AZURE_CLIENT_SECRET
MicrosoftEntra
AzureAdただし、検索で見つかった設定が実際に本番環境で使われているとは限りません。環境変数、設定ファイル、シークレットストア、デプロイスロットなど、複数の設定元があると優先順位によって別の値が使われることがあります。
クライアントIDやテナントIDまで変更しない
同じアプリ登録のシークレットを更新しただけであれば、通常は次の値を変更する必要はありません。
- Application（client）ID
- Directory（tenant）ID
- リダイレクトURI
- APIのアクセス許可
- Azure RBACのロール割り当て
差し替えるのは、原則としてClient Secretとして保存されている旧Valueだけです。
クライアントIDまで変更すると、別のアプリとして扱われ、アクセス許可やロール割り当てまで再設定が必要になる場合があります。
Valueを加工せずに保存する
コピーしたValueは、前後に空白や改行を追加せず、そのまま保存します。
特に次の点に注意してください。
- 引用符をValueの一部として保存しない
- コピー時に末尾へ改行を含めない
- Secret IDを貼り付けない
- URLエンコード済みの文字列へ勝手に変換しない
- パスワード管理画面で自動生成された別の値に置き換えない
設定ファイル上の引用符は、ファイル形式の構文として必要な場合があります。しかし、アプリへ渡される実際の値に引用符が含まれないようにします。
差し替え後は再起動・再デプロイ・再読込を行う
秘密情報を更新しても、実行中のプロセスが古い値をメモリ上に保持している場合があります。
環境に応じて、次のいずれかを実施します。
- アプリケーションの再起動
- Webアプリの再起動
- コンテナの再作成
- Kubernetes Podの再起動
- 新しい設定での再デプロイ
- CI/CDジョブの再実行
- サービス接続の保存・再認証
- シークレット参照の再読込
単にブラウザを再読み込みするだけでは、サーバー側プロセスの設定は更新されないことがあります。
複数台構成の場合は、一部のインスタンスだけが旧Valueを保持していないかも確認してください。認証できる時とできない時が交互に発生する場合、更新済みインスタンスと未更新インスタンスが混在している可能性があります。
更新後も認証できない場合の確認順序
原因を効率よく切り分けるには、次の順に確認します。
Secret IDではなくValueを設定したか
最初に確認する項目です。
Client secrets一覧でコピーした値がSecret IDだった場合は認証できません。Valueを保存していない場合は、既存のシークレットから復元しようとせず、新しいシークレットを発行します。
Valueを発行したアプリとClient IDが一致しているか
実行環境のApplication（client）IDを確認し、そのIDを持つアプリ登録からValueを発行したか確認します。
開発用、検証用、本番用でアプリ登録を分けている場合、別環境のシークレットを設定しやすいため注意が必要です。
実際に使われる設定元を変更したか
設定ファイルを変更しても、環境変数が優先されていれば、アプリは環境変数の旧Valueを使用します。
反対に、クラウド側の環境変数を変更しても、アプリが独自のシークレットストアを参照していれば反映されません。
次の設定元を確認してください。
- 本番用と検証用の環境変数
- デプロイスロットごとの設定
- Variable Group
- リポジトリとEnvironmentで重複しているSecret
- Key Vaultのシークレット名とバージョン
- Docker Composeやデプロイマニフェスト
.envとOS環境変数の競合- .NETのユーザーシークレットなど、開発環境固有の上書き設定
設定画面を更新したという事実ではなく、実行中のアプリが最終的にどの値を読み込んでいるかを確認する必要があります。
ただし、確認のためにValueそのものをログへ出力してはいけません。シークレットの更新日時、バージョン、参照先、デプロイ番号などで確認します。
再起動や再デプロイを行ったか
環境変数は、プロセス起動時に読み込まれることがあります。
設定変更後も同じエラーが続く場合は、アプリの再起動だけでなく、コンテナや実行ジョブが新しい設定で作り直されているか確認します。
有効期限が切れていないか
新しいシークレットではなく、期限切れの旧シークレットを参照している場合があります。
Azure DevOpsの公式ドキュメントでは、シークレット関連の代表的なエラーとして、次のようなメッセージが挙げられています。([Microsoft Learn][2])
AADSTS7000215: Invalid client secret is provided
AADSTS7000222: The provided client secret keys for app are expired
Invalid client id or client secretAADSTS7000215が表示された場合は、Secret IDの誤使用、コピー間違い、旧Valueの残存、異なるアプリのValueといった可能性を確認します。
AADSTS7000222の場合は、実行環境が期限切れのシークレットを使用していないかを優先して確認します。
認証エラーと権限エラーを分ける
新しいValueでアクセストークンを取得できているのに、APIやAzureリソースへのアクセスが拒否される場合は、クライアントシークレットではなく権限の問題である可能性があります。
たとえば、次のような設定が関係します。
- Microsoft GraphなどのAPIアクセス許可
- 管理者の同意
- Azure RBACのロール割り当て
- 対象リソース側のアクセス制御
- トークンのscopeやaudience
クライアントシークレットはアプリ自身を認証するための資格情報です。認証後に何へアクセスできるかは、別の権限設定で決まります。
Azure DevOpsが作成したサービス接続はAzure DevOps側で更新する
Azure DevOpsのAzure Resource Managerサービス接続が、自動的にサービスプリンシパルを作成した構成では、Microsoft Entra ID側だけでクライアントシークレットを追加しないようにします。
Microsoft公式ドキュメントでは、この構成のシークレットはAzure DevOpsポータル側から更新するよう案内されています。([Microsoft Learn][1])
基本的な確認先は次のとおりです。
- Azure DevOpsの対象プロジェクトを開く
Project settingsService connections- 対象のAzure Resource Managerサービス接続を選択
Rotate secretを実行する
環境や接続の状態によっては、サービス接続を編集して保存することで更新する方法も公式ドキュメントに記載されています。操作にはAzureサブスクリプションとMicrosoft Entra IDの適切な権限が必要です。([Microsoft Learn][2])
Microsoft Entra ID側で新しいValueを作成しても、Azure DevOpsのサービス接続が保持する資格情報は自動的には差し替わりません。Azure DevOpsが管理している接続は、Azure DevOps側の更新経路を使用することが重要です。
旧シークレットは切替確認後に削除する
安全に更新するには、新旧のシークレットを一時的に併存させます。
推奨する切替手順
- 新しいシークレットを作成する
- 新しいValueを秘密情報の保存先へ登録する
- アプリを再起動または再デプロイする
- ログイン、API呼び出し、バッチ処理などを確認する
- 全インスタンスが新しいValueへ切り替わったことを確認する
- 不要になった旧シークレットを削除する
新しいValueの反映前に旧シークレットを削除すると、アプリが認証できない時間が発生します。
Webアプリだけでなく、定期実行バッチ、夜間ジョブ、バックアップ処理、別リージョンのインスタンスなども同じシークレットを利用していないか確認してください。
毎日実行される処理だけを確認し、月次処理が旧Valueのまま残ると、後日になって突然失敗することがあります。
期限切れを防ぐために更新通知を設計する
クライアントシークレットは、発行時だけでなく期限管理まで含めて運用します。
最低限、次の情報を記録しておきます。
| 管理項目 | 記録例 |
|---|---|
| 対象アプリ | 社内ポータル本番 |
| Application ID | 管理台帳に記録 |
| 利用環境 | App Service本番環境 |
| 保存先 | Key Vaultのシークレット名 |
| 管理担当 | システム担当者、担当部署 |
| 発行日 | 2026年9月 |
| 有効期限 | 管理画面で確認した日付 |
| 更新予定日 | 有効期限の1～2か月前 |
| 旧シークレット削除日 | 切替確認後に記録 |
更新通知は、有効期限当日ではなく余裕を持って設定します。
担当者個人の予定表だけに登録すると、異動や退職で引き継がれない可能性があります。共有カレンダー、監視サービス、チケット管理、構成管理台帳など、組織として確認できる場所にも登録しておくと安全です。
本番用途では証明書やフェデレーションも検討する
クライアントシークレットは設定しやすい一方、保存、配布、更新、漏えい対策が必要です。
Microsoftは、クライアントシークレットよりも証明書やフェデレーション資格情報を安全性の高い方式として案内しています。公式ドキュメントでは、本番環境へ移行する前に証明書を使用することが推奨され、クライアントシークレットは証明書やフェデレーション資格情報より安全性が低いと説明されています。([Microsoft Learn][1])
特に次の環境では、シークレットを持たない認証方式を検討する価値があります。
- GitHub Actions
- Azure DevOps Pipeline
- Kubernetes
- Azure上で動作するアプリ
- 外部クラウドやオンプレミスからAzureへ接続するワークロード
ワークロードIDフェデレーションでは、外部のIDプロバイダーとの信頼関係を利用してアクセストークンを取得できるため、長期間有効なシークレットを保存して定期更新する負担を減らせます。Microsoft Entraでは、GitHub ActionsやKubernetesなどが対応シナリオとして案内されています。([Microsoft Learn][3])
Azure DevOpsのAzure Resource Managerサービス接続についても、MicrosoftはワークロードIDフェデレーションを推奨しており、新規接続ではシークレット方式より優先して検討できます。([Microsoft Learn][4])
既存システムを直ちに変更できない場合は、まずValueの正しい差し替えと期限管理を確実に行い、次回の認証構成見直し時に移行を検討すると現実的です。
最後に確認するチェックリスト
クライアントシークレットを更新したのに認証できない場合は、次の項目を順番に確認してください。
- 実行環境へ設定したのはSecret IDではなくValueか
- Valueを作成直後に保存したか
- Client IDとValueは同じアプリ登録の組み合わせか
- 本番環境が実際に参照する秘密情報を更新したか
- 環境変数や別の設定元に旧Valueが残っていないか
- アプリを再起動、再デプロイ、再実行したか
- 複数インスタンスや定期ジョブも更新済みか
- Azure DevOps管理のサービス接続をEntra側だけで変更していないか
- 新しいValueでの動作確認後に旧シークレットを削除したか
- 有効期限前の更新通知を登録したか
最優先で確認する答えは明確です。Client Secretとして実行環境へ設定するのは、Microsoft Entra IDで作成直後に表示されるValueです。Secret IDではありません。
Valueを保存していない場合は、新しいシークレットを作成し、そのValueを実行環境へ設定してから、再起動または再デプロイを行ってください。
[1]: https://learn.microsoft.com/en-us/entra/identity-platform/how-to-add-credentials “Add and manage app credentials in Microsoft Entra ID – Microsoft identity platform | Microsoft Learn”
[2]: https://learn.microsoft.com/en-us/azure/devops/pipelines/release/azure-rm-endpoint “Troubleshoot Azure Resource Manager service connections – Azure Pipelines | Microsoft Learn”
[3]: https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation “Workload Identity Federation – Microsoft Entra Workload ID | Microsoft Learn”
[4]: https://learn.microsoft.com/en-us/azure/devops/pipelines/library/connect-to-azure “Use an Azure Resource Manager service connection – Azure Pipelines | Microsoft Learn”
コメント