Microsoftは2026年6月22日の週のIntune更新情報で、Multi Admin Approval（MAA、複数管理者承認）の適用範囲をMicrosoft Graph APIのアプリのみトークンによる呼び出しに広げたと告知した[5]。サービスプリンシパルやサードパーティ製ツールがPOST・PATCH・PUT・DELETEで保護対象のリソースを変更しようとすると、MAAがその呼び出しに割り込む[1]。影響を受けるのは、MAAのアクセスポリシーを設定したテナントだけだ[1]。承認用のヘッダーに対応していない自動化はHTTP 400でその場で失敗し、承認要求も作られない。対応済みの自動化はHTTP 412を受け取り、別の管理者の承認を待つ[1][3]。どちらの場合も、夜間に無人で回している構成配布やアプリ展開は予定どおりには終わらない。止めないための手段は、承認フローをコードに組み込むか、アプリをアクセスポリシーの除外に入れるかの2つだ[1][4]。
予備知識
- Intune: 社用デバイスの構成配布やアプリ配布をクラウドから一元管理するMicrosoftのサービス。
- Multi Admin Approval（MAA、複数管理者承認）: 1人の管理者が加えた変更を、別の管理者が承認するまで反映させない仕組み。
- Microsoft Graph API: Microsoft 365やIntuneの機能をプログラムから呼び出すための共通API。
- サービスプリンシパル／アプリのみトークン: 人手を介さずAPIを呼び出すためのアプリ用アカウントと、その認証に使う一時的な資格情報。ユーザーのサインインを伴わない。
- 委任認証: 管理者がサインインし、その管理者の権限でAPIを呼び出す方式。Intune管理センターでの操作や、サインインしてから実行するスクリプトが該当する。
Intuneのアクセス制御やロール設計を含む運用管理を体系的に押さえたい情シス担当者向け
何が変わったか——MAAの適用範囲がアプリのみトークンの呼び出しに拡大
MAAは、保護対象のリソースへの変更を、別の管理者が承認するまで適用しない仕組みだ[4]。これまで承認フローの対象は、対話的（委任）認証による管理操作に限られていた[1][2]。アプリのみトークンの呼び出しは、承認なしで保護対象リソースを変更できた[2]。
2026年6月22日の週の変更で、サービスプリンシパルやサードパーティ製ツールがアプリのみトークンでGraph APIを呼び出す場合も、対象リソースがアクセスポリシーで保護されていればMAAが割り込むようになった[1][5]。
保護対象になり得るリソースは、アプリ配布、コンプライアンスポリシー、構成ポリシー（設定カタログ）、デバイスのワイプ・リタイア・削除、ロールベースアクセス制御（RBAC）、Windowsへのスクリプト配布、テナント構成（デバイスカテゴリ）の7種類だ[1][4]。MAAはワークロードごとのオプトインで、アクセスポリシーを設定していないテナントやワークロードには今回の変更は影響しない[1]。
割り込みの対象は書き込み系の操作に限られる。POST・PATCH・PUT・DELETEはMAAの判定を経るが、GETによる読み取りは対象外だ[1][2][3]。監視ツールが状態を取得するだけの処理は、今回の変更で止まらない。
除外設定など統制上の例外運用を稟議・監査説明にどう落とし込むか判断したい担当者向け
実際に何が起きるか——ヘッダーの有無でHTTP 400と412に分かれる
保護対象のリソースにアプリのみトークンで書き込むと、応答は承認申請用のx-msft-approval-justificationヘッダー（申請理由をBase64でエンコードした値）を付けたかどうかで分かれる[1]。
ヘッダーを付けていない呼び出しは、HTTP 400で失敗する。応答本文には、この操作にMAAの承認が必要で、x-msft-approval-justificationヘッダーが要ることが示される[1][3]。ヘッダーを付けても値がBase64でなければ、同じく400で返る[3]。この段階では承認要求は作られない。Microsoft Learnは、HTTP 412とx-msft-approval-codeヘッダーがそろった応答を、承認要求が作られた合図として扱うよう説明している[1]。改修していない既存の自動化は、承認待ちで止まるのではなく、その場で失敗する。
正しくエンコードしたヘッダーを付けて送ると、応答はHTTP 412（Precondition Failed）になり、x-msft-approval-codeヘッダーに承認要求のIDが入る[1][3]。外側のGraphエラーコードはBadRequestで、承認が必要である旨はエラーメッセージの中に入れ子で返る[1]。権限不足ではなく、承認待ちに入ったことを示す想定内の応答だ[1]。
ステータスコードの記載は、Microsoftの文書の間でもそろっていない。Intuneの更新情報は、承認ヘッダーを含まない呼び出しがHTTP 403を返すと書いている[5]。手順を解説したLearnの記事と、実際にリクエストを送って確かめた検証記事は、どちらもHTTP 400としている[1][3]。自動化のエラー処理は、ステータスコードや外側のエラーコードだけで分岐させず、x-msft-approval-codeヘッダーの有無と応答本文で判定するほうが確実だ。
アプリケーションはMAAの要求を承認も却下もできない。承認できるのは、承認者グループに属する別の管理者アカウントだけだ[1]。その管理者がIntune管理センターで承認した後、元のリクエストをx-msft-approval-codeヘッダー付きで再送信して初めて処理が完了する[1]。承認の状態は、operationApprovalRequestsをGETで照会すれば確認できる[1]。
承認フローを組み込むなら、Intune側の仕様で運用に効く点が3つある。Intuneは要求の作成や状態の変化を通知しないため、承認者への連絡手段は別に用意する必要がある[4]。3日以内に処理が進まない要求は失効し、出し直しになる[4]。同じオブジェクトに承認待ちの要求が残っている間は、新しい要求を出せない[4]。
SIer（システムインテグレーター）やMSP（マネージドサービスプロバイダー）にMicrosoft 365・Entra ID環境の運用を委託している企業は多い。数千人規模のテナントで、日々の設定変更や障害対応を委託先が代行している場合、「[…]
承認フロー対応と除外設定——2つの選択肢の比較
自動化を止めない選択肢は2つある。スクリプトやツールに承認フローを実装するか、当該アプリケーションをアクセスポリシーの除外リストに加えてMAAの対象から外すかだ[1][4]。
除外はアクセスポリシーのExclusionsタブで追加する。追加・変更・削除には別の管理者の承認が必要で、1つのアクセスポリシーに登録できるのは最大50アプリケーションだ[4]。除外は設定したアクセスポリシーにだけ効き、他のポリシーやワークロードには影響しない[4]。対象はアプリ認証の呼び出しだけで、同じアプリケーションでも委任認証の呼び出しは引き続きMAAの対象になる[1][4]。
| 観点 | 承認フロー対応 | 除外設定 |
|---|---|---|
| 対応内容 | ヘッダー送信・承認待ち・再送信をコードに実装 | 対象アプリをアクセスポリシーの除外リストに追加 |
| 承認の要否 | 変更のたびに別管理者の承認が必要 | 除外の追加・変更・削除のときだけ承認が必要 |
| 統制への影響 | MAAの保護をそのまま維持 | 除外したポリシーの範囲で保護が外れる |
| 向いている場面 | 変更頻度が低く承認を待てる自動化 | 高頻度・無人実行が前提の、信頼できる自動化 |
| 運用上の注意 | 3日以内に処理が進まない要求は失効し再申請が必要。Intuneは承認者に通知しない[4] | 除外リストの定期的な見直し[4]。除外したアプリ登録の資格情報を特権アカウント並みに保護[2] |
除外はMAAの保護を迂回する設定で、除外したアプリケーションが侵害されれば承認フローの穴として悪用されうる[4]。Microsoftは、必要な場合に限って除外し、除外リストを定期的に見直して不要な登録を消すよう求めている[4]。一方で、人の承認を待てない無人の自動化については、外部の解説は信頼できるものに限って除外を勧めている[2][3]。Recastは、パッケージングのパイプラインのように信頼できる無人の自動化には除外を使い、除外リストを小さく保ったうえで、除外したアプリ登録を特権アカウント並みに保護するよう書いている[2]。
どちらを選ぶかの基準は2つある。1つ目は、変更のたびに人の承認を待てるかどうかだ。待てるなら、承認フロー対応でMAAの保護をそのまま保てる。2つ目は、除外したときに保護が外れるリソースの重要度だ。除外はアクセスポリシー単位で効くため、アプリ配布のポリシーでは除外し、スクリプト配布やRBACのポリシーでは除外しない、という分け方ができる[4]。Rozemullerは、2人目の確認が特に意味を持つのはスクリプトやRBACのような機微なワークロードだとしている[3]。高頻度・無人の自動化でも、重要度の高いリソースに書き込むものは承認フロー対応に寄せ、除外は影響を許容できるポリシーに限るのが妥当だ。
複合機のスキャン送信連携や会議室予約システムなど、Exchange Web Services（EWS、旧来のメール連携API）経由でメール機能を呼び出す社内システムを何年も運用してきた、数千人規模の企業の情報システム部門にとって、2026[…]
日本語で確認・決裁するときの注意点
Microsoft Learnには、Graph API編と更新情報の日本語版もある[6][7]。記載内容は英語版に沿っているが、読み比べると次の点で扱いに注意が要る。
| 確認点 | 日本語版の記載 | 実務での扱い |
|---|---|---|
| 機能名 | 同じページの中で「複数管理承認」「マルチ管理承認」「マルチ管理者の承認」などが混在する[6] | 社内手順書や検索では英語名Multi Admin Approvalと略称MAAを併記する |
| 認証方式の訳 | delegatedが「委任」と「代理認証」の両方で訳されている[6] | どちらもユーザーがサインインして呼び出す委任認証を指す |
| FAQの回答 | 「アプリケーションは独自の MAA 要求を承認できますか。」への回答が「その必要はありません。」[6] | 英語版の回答はNo。アプリは自分の要求を承認できない[1] |
| ヘッダーなしの応答 | 更新情報はHTTP 403[7]、Graph API編はHTTP 400[6] | 英語版と同じ食い違い。応答ヘッダーと本文で判定する |
除外を暫定策として社内決裁にかける場合、除外の追加そのものにも別の管理者の承認が要り、追加・削除・変更の操作はIntuneの監査ログに残る[4]。決裁で除外を認めるなら、対象のアクセスポリシーと見直し期限を同じ稟議に載せておくと、Microsoftが求める除外リストの定期的な見直し[4]を社内の手続きに組み込める。コード改修の見積もりと決裁を待つ間に除外で自動化を動かす場合も、期限を先に決めておけば、暫定のはずの除外がそのまま残り続けることを防げる。
まとめ
2026年6月22日の週から、MAAはアプリのみトークンによるGraph API呼び出しにも適用されている[5]。影響を受けるのは、MAAのアクセスポリシーを設定したテナントで、保護対象リソースに書き込む自動化だ[1]。承認ヘッダーに未対応の自動化はHTTP 400でその場で失敗し、承認要求も作られない。対応済みの自動化はHTTP 412で承認待ちに入り、3日以内に処理が進まなければ要求が失効する[1][4]。
最初の作業は、どの自動化が保護対象リソースに書き込んでいるかを洗い出すことだ。MAAの承認・ブロック・通過や除外の追加・削除は、Intuneの監査ログに記録される[1]。監査ログからサービスプリンシパルによる変更を抜き出し、Entraのサインインログでアプリのみトークンを使っているアプリと突き合わせれば、改修か除外かを決める対象の一覧になる[3]。その一覧をアクセスポリシーごとに並べ、承認を待てるか、保護が外れるリソースの重要度はどうかで振り分ける。
よくある質問（FAQ）
Q1. 監視ツールがIntuneの状態を取得しているだけでも影響を受けますか。
A. GETは対象外のため、状態取得だけの処理は影響を受けない[1]。
Q2. 自動化がHTTP 400で失敗しています。Intune管理センターに承認要求は届いていますか。
A. 届いていない。承認要求が作られるのは、Base64でエンコードしたx-msft-approval-justificationヘッダーを付けて送り、HTTP 412とx-msft-approval-codeヘッダーが返った場合だ[1][3]。
Q3. 除外設定をすれば元どおりに自動化を動かせますか。
A. 動くようになるが、除外したアクセスポリシーの範囲でMAAの保護が外れる。Microsoftは除外を必要な場合に限り、除外リストを定期的に見直すよう求めている[4]。
Q4. Intune管理センターで管理者が手動で操作する場合は関係ありませんか。
A. 対話的（委任）な操作は以前から承認の対象で、今回加わったのはアプリのみトークンによる呼び出しだ[1][4]。
出典
[1] Use Multi Admin Approval with the Microsoft Graph API（Microsoft Learn）[2] Intune Multi Admin Approval Now Enforced on Graph API Calls（Recast Software, 2026-07-22）
[3] Don’t Let Multi Admin Approval Break Your Intune Automation（Sander Rozemuller, 2026-06-26）
[4] Use access policies to require multi admin approval（Microsoft Learn）
[5] What’s new in Microsoft Intune: Week of June 22, 2026（Microsoft Learn）
[6] Microsoft Graph API で複数管理承認を使用する（Microsoft Learn 日本語版）
[7] Microsoft Intune の新機能: 2026 年 6 月 22 日の週（Microsoft Learn 日本語版）
