Entra ID（旧Azure AD）のアプリで突然ログインできなくなり、AADSTS7000222 の「クライアント シークレット期限切れ」が出たのに、Azure ポータルでクライアント ID を検索してもアプリが見つからない――そんなときは「見ているディレクトリ（テナント）が違う」可能性が高いです。原因の切り分けから復旧までを手順化して解説します。
症状：クライアント シークレット期限切れと「アプリが見つからない」が同時に起きる理由
AADSTS7000222 は、OAuth 2.0 / OpenID Connect のトークン発行（token endpoint）でクライアント シークレットが期限切れのときに返る代表的なエラーです。Web アプリやサーバーサイドで Microsoft でログイン（サインイン）を実装している場合、ユーザーがサインイン画面を通過しても、アプリ側が「認可コードをトークンに交換する処理」で失敗し、結果としてログイン完了まで到達できません。
ここで混乱しやすいのが、「ならポータルでアプリを開いてシークレットを作り直せばよい」と思っても、クライアント ID（アプリケーション ID）で検索しても表示されず、更新できないケースがあることです。これは多くの場合、次のいずれかが原因です。
| よくある原因 | なぜ「検索しても出ない」ように見えるか | 最短の確認ポイント |
|---|---|---|
| 別ディレクトリ（別テナント）にアプリ登録がある | 今開いているテナントの「アプリ登録」一覧には存在しないため | ポータルのディレクトリ切り替え（テナント切替）を試す |
| 「アプリ登録」ではなく「エンタープライズ アプリケーション」だけを見ている | 定義（アプリ登録）と実体（サービス プリンシパル）が別物で、表示場所が違うため | Entra ID の「アプリ登録」と「エンタープライズ アプリ」を両方検索 |
| アクセス権限が不足している | 権限がないと一覧に出ない、または詳細が開けない | アプリの所有者/管理者に権限付与を依頼 |
| アプリ登録が削除済み（復元期間内/外） | 通常の一覧から消える。復元期間外なら復旧不可 | 「削除済みアプリケーション」を確認 |
まず押さえる：アプリ登録とエンタープライズ アプリケーションの違い
「クライアント ID で検索しても出ない」を早く解決するために、Entra ID のアプリ周りを最小限だけ整理します。アプリ登録（Application）はアプリの定義、エンタープライズ アプリケーション（Service Principal）は各テナント上での実体です。
| 項目 | アプリ登録（Application） | エンタープライズ アプリ（Service Principal） |
|---|---|---|
| 役割 | 「アプリそのもの」の定義（リダイレクト URI、証明書/シークレット、API 権限など） | テナント上での「利用実体」。ユーザー割り当て、条件付きアクセス、同意（Consent）など |
| 主な操作 | クライアント シークレット作成、証明書追加、リダイレクト URI 変更 | サインイン制御、ユーザー/グループ割り当て、SSO 設定、同意の管理 |
| 「見つからない」時の意味 | そもそもそのテナントに定義がない可能性 | 利用したテナントには実体だけが作られている可能性 |
今回のように「シークレット期限切れ」で困っている場合、更新作業は基本的にアプリ登録側で行います。つまり、検索で出てこないなら「見ているテナントが違う」疑いが最優先になります。
原因の本命：アプリ登録が別のディレクトリ（別テナント）にある
複数テナントを扱う組織や、個人の開発用テナントを持っている場合、Azure ポータル右上のアカウント表示は同じでも、現在選択中のディレクトリが違うだけでアプリ登録が丸ごと見えなくなります。特に次のパターンが多いです。
- 開発時は個人テナント（例：xxxx.onmicrosoft.com）でアプリ登録を作成し、運用時は会社テナントで探している
- ゲストとして参加している別テナントにディレクトリが切り替わったままになっている
- 同じメールアドレスで複数テナントに所属しており、直近の作業テナントが選択されている
「検索しても出ない」現象は、アプリが消えたのではなく探している場所が違うだけ、ということが少なくありません。
テナント（ディレクトリ）を特定する方法
正しいテナントに切り替えるためには、「そのクライアント ID がどのテナントで作られたのか」を当てにいくのが近道です。状況に応じて使い分けられるように、現場で効く手段を並べます。
サインイン ログから特定する（管理者権限がある場合）
Entra ID の監査・サインイン ログにアクセスできるなら、もっとも確実です。AADSTS7000222 が発生したタイミングのサインイン ログを開き、アプリケーション ID やテナント ID（Directory ID）を確認します。
- フィルターに「アプリケーション ID（クライアント ID）」を入れて絞り込む
- イベント詳細で「テナント ID」や「リソース テナント」を確認する
- エラー詳細の Correlation ID が分かる場合、ログ側で突合しやすい
自分にログ閲覧権限がない場合は、エラー画面に出る Correlation ID / Timestamp を添えてテナント管理者に確認を依頼するとスムーズです。
認証エンドポイント（Authority）から推測する
アプリの設定ファイルやソースコードに、次のような URL が残っていることが多いです。
https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize
https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token{tenant} の部分が common / organizations / consumers の場合は「どのテナントでもサインインできる可能性」を残している設定です。一方で、GUID 形式（例：11111111-2222-3333-4444-555555555555）や独自ドメイン（例：contoso.com）が入っていれば、ほぼそのテナントがホームです。
既存の設定値（環境変数、Key Vault、シークレット管理）から辿る
運用でよくあるのが「アプリ登録は見つからないが、実行環境には ClientId/Secret が設定されている」状態です。この場合、まずは設定値の配置場所を棚卸しします。
| 配置場所 | 探し方 | 見つかることが多い情報 |
|---|---|---|
| アプリ設定ファイル（appsettings.json / .env など） | リポジトリ内で login.microsoftonline.com / tenant / authority を検索 | tenantId、リダイレクト URI、スコープ |
| クラウドの構成（App Service / Functions のアプリ設定） | 環境変数一覧で AZURE_TENANT_ID や TENANT_ID を探す | tenantId、ClientId の出どころ |
| Key Vault / Secret Manager | シークレット名の命名規則（例：entra-{env}-client-secret）から検索 | 更新履歴、ローテーション担当の痕跡 |
手元にトークンが残っているなら「tid」で確定する
過去に発行された ID トークンやアクセス トークンがログやキャッシュに残っている場合、JWT のクレームにある tid（Tenant ID）でテナントを確定できます。JWT をデコードして tid を探してください（署名検証は別途必要ですが、特定目的ならペイロードの参照だけでも役立ちます）。
// 例：JWTのペイロードに出てくる代表的な項目
{
"iss": "https://login.microsoftonline.com/<tenant-id>/v2.0",
"tid": "<tenant-id>",
"aud": "<client-id>",
"preferred_username": "[email protected]"
}シークレット期限切れで新規トークンが取れない状態でも、過去ログの 1 件が残っているだけで状況が一気に進みます。
コマンドで横断検索する（テナント候補が多い場合）
「テナントが多すぎてポータルで切り替えながら探すのがつらい」場合は、コマンドで機械的に当たる方法もあります。ここでは考え方だけ示します（実行には権限が必要で、権限がないテナントでは結果が返りません）。
| 手段 | できること | 向いている人 |
|---|---|---|
| Azure CLI | 指定テナントにログインして、クライアント ID でアプリ定義を取得 | Azure 運用に慣れている、ターミナルでの確認が早い |
| Microsoft Graph PowerShell | Graph で appId をフィルターして検索 | 監査/棚卸しも含めてスクリプト化したい |
例：Azure CLI の発想（テナントを切り替えながら、アプリを 1 件照会）
# 1) テナントを指定してサインイン（すでにサインイン済みならスキップ）
az login --tenant <tenant-id>
# 2) クライアント ID（appId）でアプリ登録を照会
az ad app show --id 例：Microsoft Graph PowerShell の発想（アプリ登録を appId で検索）
# 事前に Microsoft Graph PowerShell のインストールが必要です
Connect-MgGraph -TenantId <tenant-id> -Scopes "Application.Read.All"
# appId（=クライアントID）で一致検索
Get-MgApplication -Filter "appId eq ''"結果が返らない場合でも「そのテナントに存在しない」のか「権限がなくて見えない」のかは切り分けが必要です。とはいえ、候補テナントを機械的に潰していく用途には強力です。
ディレクトリを切り替えてアプリを見つける（ポータル手順）
テナントの候補が絞れたら、ポータルでディレクトリを切り替えて検索します。UI は更新で表記が変わることがありますが、流れは同じです。
ディレクトリ切り替えのポイント
- 「Azure ポータル」と「Microsoft Entra 管理センター」は見え方が違うことがあるため、両方で試す
- 右上のアカウントメニューから「ディレクトリの切り替え（テナントの切り替え）」を実行する
- 候補テナントが複数ある場合、まずは開発時に使っていたテナント（個人/検証）を優先して探す
検索する場所を間違えない
クライアント シークレット更新が目的なら、まずはアプリ登録を探します。次の表の順に当たると迷いにくいです。
| 探す場所 | 探し方 | 見つかったら次にやること |
|---|---|---|
| アプリ登録（すべてのアプリケーション） | 検索窓に「アプリケーション ID（クライアント ID）」を貼り付ける | 証明書とシークレットで新しいシークレットを追加 |
| エンタープライズ アプリケーション | 同じくクライアント ID で検索し、サービス プリンシパルの有無を確認 | 利用テナントだけに実体があるかどうかを判断 |
| 削除済みアプリケーション | 削除済み一覧からクライアント ID / 表示名で探す | 復元可能なら復元し、シークレット更新へ |
検索時は、一覧が「自分が所有するアプリ」などに絞られていないかも要注意です。フィルターが残っていると、存在していても見えないことがあります。
クライアント シークレットを更新して復旧する手順
正しいテナントで該当アプリ登録が見つかったら、あとは更新作業です。運用で事故が起きにくい順序を、あえて細かく書きます。
更新の基本手順
- アプリ登録の「証明書とシークレット（Certificates & secrets）」を開く
- 「新しいクライアント シークレット」を追加し、用途が分かる説明と有効期限を設定する
- 作成直後に表示されるシークレット値（Value）を安全な場所に保管する（この画面を閉じると二度と表示されません）
- アプリ側（サーバー、CI/CD、Key Vault、シークレット管理）に新しい値を反映する
- デプロイ/再起動して、実際にログインが通ることを確認する
- 問題なければ古いシークレットを削除する（重複期間を設けると安全）
更新時のチェックリスト
| チェック項目 | よくあるミス | 防ぎ方 |
|---|---|---|
| 値（Value）を控えたか | 「シークレット ID」だけをコピーしてしまう | 更新直後に Value を安全に保管し、貼り付け先を明確化 |
| 反映先が 1 か所とは限らない | 本番とステージングで別の設定なのに片方しか更新しない | 環境ごとの設定表を作り、更新対象を列挙してから作業 |
| リダイレクト URI など他設定が変わっていないか | 「ついでに触った」設定が原因で別エラーになる | 更新は最小変更、差分を残す（スクショ/メモ/PR） |
| 古いシークレットの削除タイミング | 先に古い方を消して復旧不能になる | 新旧併存期間を作り、疎通確認後に削除 |
シークレットを更新したのに直らないときの確認ポイント
アプリ登録を見つけてシークレットを追加したのに、まだ AADSTS7000222 が出ることがあります。多くは「アプリ側が古いシークレットを使い続けている」か「別アプリ（別クライアント ID）を参照している」パターンです。
| 状況 | 原因の例 | 確認・対処 |
|---|---|---|
| 新しいシークレットを作ったのに同じエラー | 設定反映漏れ（環境変数/Key Vault/CI の変数が古いまま） | 反映先を棚卸しし、実際の実行環境で参照している値を確認 |
| 開発環境だけ直った／本番だけ直らない | 環境ごとに別のアプリ登録を使っている、または別テナント | 各環境の ClientId と authority を突合し、同じアプリを見ているか確認 |
| 一部ユーザーだけ失敗する | マルチテナントで利用テナントごとに条件付きアクセスや同意が違う | 失敗ユーザーのサインイン ログを確認し、利用テナント側の設定も点検 |
| シークレットを複数作っていてどれが正しいか不明 | 説明（Description）が曖昧で、用途が追跡できない | 説明に「環境」「用途」「ローテーション日」を含め、不要なものを整理 |
特に「新旧併存」をしている期間は、どの環境がどのシークレットを参照しているかが混ざりやすいので、更新のたびに台帳を更新しておくと、次回の調査時間が激減します。
「テナントを切り替えたら見つかった」以外の分岐も押さえる
今回の本命は「別テナントにあった」ですが、現場では複合要因も起こります。短時間で切り分けられるよう、追加の分岐をまとめます。
ゲストとして別テナントに切り替わっていた
ブラウザで Azure/Entra を触っていると、最後に作業したテナントが維持されます。ゲスト参加しているテナントに切り替わっていると、ホーム テナントのアプリが見えません。ディレクトリ切り替えで「ホーム」側に戻してから再検索します。
アプリ登録が削除されていた
削除済みアプリケーションの一覧に残っていれば復元できますが、復元期間を過ぎていると作り直しが必要です。作り直しになるとクライアント ID が変わるため、実装や設定の差し替え工数が増えます。削除の可能性がある場合は、まず復元期間内かを確認してください。
権限不足で見えていない
特に「アプリ登録を作った人が退職した」「外部委託が作った」ケースでは、所有者が不在になりがちです。アプリ登録には所有者（Owners）を複数設定し、運用チームのグループ/共有メールを入れておくと、こうした詰まりを減らせます。
再発防止：クライアント シークレット運用を“仕組み化”する
クライアント シークレットは「いつか必ず切れる」ものなので、根性で避けるより仕組みで避けるのが現実的です。特に効果が大きい対策を、運用コストが低い順に並べます。
期限を台帳化し、更新を予定として管理する
最低限、次の 5 項目を 1 行で管理できる台帳（スプレッドシートでも構いません）を用意すると、次回の復旧スピードが上がります。
| 項目 | 例 |
|---|---|
| アプリ名（表示名） | SignIn-Prod-Web |
| クライアント ID | xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx |
| テナント（Directory ID / ドメイン） | contoso.onmicrosoft.com |
| シークレットの期限 | 2026-03-31 |
| 反映先（Key Vault/環境名/設定キー） | kv-prod / SignInClientSecret |
ローテーションは「新旧併存」を前提にする
本番で無停止に近い形で更新するなら、新しいシークレットを作成して反映し、疎通確認後に古いシークレットを削除する流れが安全です。更新当日に慌てないよう、期限の 1～2 か月前にローテーションする運用にしておくと安心です。
可能なら証明書資格情報へ移行する
クライアント シークレットよりも、証明書（公開鍵/秘密鍵）を使う方式のほうが運用が安定しやすいことが多いです。理由は、秘密鍵を HSM や Key Vault で保護しやすく、ローテーション設計もしやすいからです。アプリの種類（Web アプリ、デーモン、API など）や運用環境に応じて検討してください。
Azure 上で動くなら Managed Identity を第一候補にする
もしアプリが Azure 上（App Service、Functions、VM、Container Apps など）で動いていて、アクセス先が Azure リソース（Key Vault、Storage、SQL など）中心なら、シークレットそのものを持たない Managed Identity（マネージド ID）に寄せると、期限切れトラブルを大幅に減らせます。
「どのテナントにあるか」を迷わない命名・所有者設計
今回の事故は「別テナントにあった」が原因でした。再発を防ぐなら、表示名や説明にテナント用途が分かる情報を埋め込むのが効きます。
- 表示名に環境と用途を入れる（例：
SignIn-Prod/SignIn-Dev） - 説明（Notes）に「運用担当」「反映先」「連絡先」を残す
- Owners に運用グループを必ず追加し、個人依存を避ける
/common エンドポイントと「対応アカウント種別」が絡むと、テナント特定が難しくなる
補足として、実装が /common を使っている場合や、アプリの「対応アカウント種別（Supported account types）」が複雑な場合、どのテナントに紐づくのかが見えにくくなります。ここを理解しておくと、次に同じ混乱をしにくくなります。
エンドポイントの考え方
| 指定 | 意味 | 向いているケース | 注意点 |
|---|---|---|---|
/<tenantId> または /<tenantDomain> | 特定テナント固定 | 社内向け（シングルテナント）SaaS、社内業務アプリ | 他テナントのユーザーはサインインできない |
/organizations | 任意の組織アカウント | マルチテナント（組織アカウントのみ） | 個人 Microsoft アカウント（MSA）は対象外 |
/consumers | 個人 Microsoft アカウント | B2C 寄りの一般ユーザー向け | 組織アカウントは対象外 |
/common | 組織アカウント + 個人アカウントの両方を受ける入口 | 両対応が必要な SaaS | トークンの発行元テナントを意識しないと、運用時に迷いやすい |
「社内アプリなのに /common を使っていた」「想定していないテナントでもログインできる設定になっていた」などがあると、アプリ登録の所在が分からなくなりがちです。シングルテナント運用なら、基本はテナント固定の authority を選ぶほうが運用事故が減ります。
Supported account types とズレると別エラーも出る
アプリ登録の対応アカウント種別（例：この組織ディレクトリのみ / すべての組織ディレクトリ / 個人アカウントも含む）と、実装側の authority（/common など）がズレると、AADSTS700016（アプリが見つからない）など別のエラーに変わることもあります。今回の主因はシークレット期限切れでも、ついでに設定を見直すなら、次を確認しておくと安全です。
- 想定するユーザー種別（社内のみか、他社テナントも含むか、個人アカウントも必要か）
- テナント固定が可能なら
/<tenantId>を使って曖昧さを減らす - マルチテナントの場合は、同意（Admin consent）や利用テナント側のエンタープライズ アプリ設定も確認する
実務で役立つ「最短復旧」フロー
時間がないときは、次の順で動くと復旧までが短くなりやすいです。
- エラーが
AADSTS7000222であることを確認（シークレット期限切れ） - コード/設定から authority を確認し、テナント候補を絞る（固定なら即確定）
- ポータルでディレクトリを切り替え、アプリ登録をクライアント ID で検索
- 見つかったら新しいシークレットを作成し、実行環境へ反映
- ログイン疎通を確認し、古いシークレットを削除（または計画的に撤去）
- 台帳に「テナント」「期限」「反映先」を記録し、次回更新を予定化
よくある質問
クライアント ID を貼っても 0 件です。本当に存在しますか？
まずディレクトリ（テナント）が正しいかを疑ってください。次に、検索対象が「すべてのアプリケーション」になっているか、フィルターが残っていないかを確認します。それでも出ない場合は、削除済みの可能性、または権限不足の可能性があります。
シークレットの値を失いました。表示し直せますか？
いいえ。クライアント シークレットの値（Value）は作成直後に一度だけ表示される仕組みです。紛失した場合は新しいシークレットを作成して差し替えてください。
別テナントにアプリがありました。今後はどう管理すべきですか？
「どのテナントに何があるか」を一度決め、台帳化するのが効果的です。開発用テナントと運用用テナントを分ける場合は、表示名・説明・Owners で誰が運用しているかを残し、ローテーション期限も合わせて管理すると、今回のような探索コストを下げられます。
コメント