【Microsoft Entra】昨日まで動いていたAPI連携が朝から動かない― クライアントシークレット失効を防ぐ棚卸し術

こんにちは！DXソリューション営業本部の大和矢です。

「昨日まで動いていたAPI連携が、朝からinvalid_clientで全滅」
―― その原因、クライアントシークレットの期限切れかもしれません。

Microsoft Entra IDのアプリ登録に発行するクライアントシークレットや証明書には、必ず有効期限があります。
そして期限が切れた瞬間、そのアプリを使うバッチ・API連携・自動化は、認証エラー（AADSTS7000222）で一斉に止まります。
本記事では、テナント内の資格情報の期限を読み取り専用の権限だけで棚卸しし、失効を事故にしない設計を整理します（2026年7月時点の情報です）。

本記事は、Microsoft Graphの権限棚卸しシリーズの続編です。前回はアプリに付与された「危険な権限」を棚卸ししました。

【Microsoft Entra】その自動化アプリ、特権昇格の踏み台かも ― Microsoft Graph 権限の棚卸し
こんにちは！DXソリューション営業本部の大和矢です。Microsoft Graphの「権限を配れる権限」による特権昇格リスクを4カテゴリで見極め、読み取り専用スコープで棚卸しする手順を紹介しています。
 

失効は「事故」ではなく「予定された停止」

アプリ登録に発行するクライアントシークレットには、作成時に必ず有効期限を設定します。指定できるのは最長でも2年（24か月）までで、それより長い期限は設定できません。ポータルの選択肢は180日・365日・730日などで、Microsoftは12か月未満を推奨しています（アプリケーション資格情報の追加と管理）。
証明書（keyCredentials）にも有効期限があります。
つまり、そのアプリがいつ認証できなくなるかは、作成した瞬間から決まっています。

それでも失効「事故」が繰り返されるのは、次の3つが揃っているからです。

• 通知機能はあるが、宛先が絞られている：
  Microsoft Entra recommendationsに「Renew expiring application credentials」という通知機能（プレビュー）があり、資格情報の残りが30日を切るとApplication Administratorロールの保持者にメールが届きます。ただし公式ドキュメントには、Microsoft Entra Workload IDライセンスが前提であること、そのロールの保持者がテナントにいなければメール自体が送信されないことが明記されています。
• 作った人と運用する人が違う：
  開発ベンダーや退職済みの担当者が作ったアプリは、期限の存在自体が引き継がれていないことがあります。
• 止まって初めて存在に気づく：
  シークレットは期限が切れても何も起きません。次にそのアプリがトークンを取りに行った瞬間、AADSTS7000222（The provided client secret keys are expired）で失敗し、そこで初めて「このアプリ、何だっけ」が始まります。

逆に言えば、期限を一覧で見える化してしまえば、失効は「事故」から「予定された更新作業」に変わります。
そしてこの見える化は、管理者ロールがなくてもできます。

読み取り専用スコープで期限を全件棚卸しする

テナント内のアプリ登録と、その資格情報（passwordCredentials＝シークレット／keyCredentials＝証明書）の期限は、Microsoft Graphの読み取り専用スコープ Application.Read.All だけで取得できます（List applications）。
グローバル管理者などの管理者ロールは不要です。公式のList applications APIでも、サポートされる役割の筆頭に「既定のユーザー権限を持つ非管理者メンバー（またはゲスト）」が明記されています。
ただし、Application.Read.Allは管理者の同意が必要なスコープです。テナントでこのスコープにまだ同意していない場合は、一度だけ管理者に同意してもらう必要があります（同意は一度きりで、以降は管理者ロールを持たない一般ユーザーでも実行できます）。

Graph PowerShellでの棚卸しの骨子は、次のとおりです。

# 読み取り専用スコープで接続
Connect-MgGraph -Scopes "Application.Read.All"

# 全アプリ登録の資格情報と期限を一覧化
Get-MgApplication -All -Property DisplayName, AppId, PasswordCredentials, KeyCredentials |
  ForEach-Object {
    $app = $_
    # シークレット（passwordCredentials）と証明書（keyCredentials）を、種別を付けて展開する
    $creds  = @($app.PasswordCredentials | ForEach-Object { [PSCustomObject]@{ 種別 = "シークレット"; 期限 = $_.EndDateTime } })
    $creds += @($app.KeyCredentials      | ForEach-Object { [PSCustomObject]@{ 種別 = "証明書";       期限 = $_.EndDateTime } })
    $creds | ForEach-Object {
      [PSCustomObject]@{
        アプリ名 = $app.DisplayName
        AppId    = $app.AppId
        種別     = $_.種別
        期限     = $_.期限
        残り日数 = if ($_.期限) { [int]([datetime]$_.期限 - (Get-Date)).TotalDays } else { $null }
      }
    }
  } | Sort-Object 残り日数 | Export-Csv secret_expiry.csv -NoTypeInformation -Encoding UTF8

ポイントは、取得できるのは期限などのメタデータだけという点です。
シークレットの「値」そのものは作成時に一度表示されるだけで、後からGraphで読み出すことはできません。棚卸しで秘密情報に触れる心配はありません。

棚卸し結果の読み方 ― 直す順番のつけ方

CSVを開くと、想像より多くの行が出てくるはずです。
たとえば、次のような一覧が得られます（アプリ名・AppIdはサンプルのダミー値です。残り日数がマイナスの行は、すでに期限切れです）。

このサンプルには、対応の優先度を分ける典型的なパターンが詰まっています。
すでに期限切れの行、まもなく切れる行、同じAppIdに複数ぶら下がった行、2年近い長期シークレット――こうした違いを、4つの軸で優先順位として整理します。

ここで前回の危険権限の棚卸し結果と突き合わせると、精度が一段上がります。
「強い権限を持っている × シークレットの期限が長い」アプリは、漏洩したときの被害が最大化する組み合わせです。台帳の最上段に置いてください。

失効を事故にしない設計 ― 監視・台帳・脱シークレット

棚卸しは一度やって終わりでは意味がありません。「気づける仕組み」と「そもそも失効しない構成」の2段構えで設計します。

• 気づける仕組み（運用でカバー）：
  棚卸しスクリプトをPower AutomateやLogic Appsで定期実行し、残り90日／30日を切った資格情報をTeamsやメールに通知します。
  通知先を「アプリの所有者」に紐づけると運用が回りやすくなりますが、そのためには先ほどのスクリプトに、各アプリのオブジェクトIDと所有者（Owners）の取得を追加する必要があります（AppIdだけでは所有者を辿れません）。所有者まで取得すると、所有者が空のアプリ＝誰も管理していないアプリも同時に炙り出せます。
• そもそも失効しない構成（構造で解決）：
  シークレットの更新作業を続けるより、資格情報の形を変えるほうが根本的です。失効という事象そのものをなくせるのは、次の2つです。
  ・Azure上で動く処理 → マネージドID（資格情報の管理自体が不要）
  ・GitHub Actionsや他クラウドなどAzure外からのアクセス → フェデレーション資格情報（ワークロードIDフェデレーション）でシークレットレスに（ワークロードIDフェデレーション）
  なお、どうしても資格情報が必要な場合は、証明書に置き換えてAzure Key Vaultで一元管理すると、漏洩リスクと管理の手間を下げられます。
  ただし証明書にも有効期限はあるため、この場合は棚卸しと期限監視を続ける必要があります（＝失効そのものがなくなるわけではありません）。

よくある質問（FAQ）

まとめ：止まる日は最初から決まっている

今回は、クライアントシークレット・証明書の期限切れを事故にしないための棚卸しと設計を整理しました。
学びは3つです。

• 失効は予定された停止：
  期限はendDateTimeとして最初から記録されています。公式の通知機能はライセンスと宛先ロールの条件付きのため、見える化しない限り「ある日突然」は繰り返されます。
• 棚卸しは読み取り専用でできる：
  Application.Read.Allだけでテナント全体の期限一覧が作れます。管理者ロールがなくても、今日から始められます。
• 最終形は脱シークレット：
  マネージドID・フェデレーション資格情報へ寄せれば、失効事故そのものがなくなります。更新作業の自動化より一段上の解決策です。

まずは手元で棚卸しスクリプトを実行して、「残り日数」列を眺めてみてください。
30日を切った行が1つでもあれば、この記事を読んだ今日が、事故を防げる最後のチャンスかもしれません。

ここまでお読みいただき、ありがとうございました。
なお、本記事は Microsoft Entra ID のガバナンス・権限管理に関する内容でした。関連するテーマは、QESブログの「Microsoft Entra ID Governance」カテゴリでもまとめて発信していますので、あわせてご覧いただけますと幸いです。

Microsoft Entra ID Governance ブログ一覧 | QES ブログ
QESのエンジニアが Microsoft Entra ID Governance のアクセス制御・権限管理・ID統制の自動化ノウハウを発信中！
 

※このブログで参照されている、Microsoft、Microsoft Entra ID、Microsoft Azure、Microsoft Graph、PowerShell、Azure Key Vault、Power Automate、Azure Logic Apps、Microsoft Teams、GitHubは、米国Microsoft Corporationおよび関連会社の米国およびその他の国における商標または登録商標です。