<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <author>
    <name>Azure Identity Support Japan</name>
  </author>
  <generator uri="https://hexo.io/">Hexo</generator>
  <id>https://jpazureid.github.io/blog/</id>
  <link href="https://jpazureid.github.io/blog/" rel="alternate"/>
  <link href="https://jpazureid.github.io/blog/atom.xml" rel="self"/>
  <rights>All rights reserved 2026, Azure Identity Support Japan</rights>
  <subtitle>日本マイクロソフトの Azure Active Directory と AD FS に関するサポート情報のブログです。</subtitle>
  <title>Japan Azure Identity Support Blog</title>
  <updated>2026-08-12T00:07:05.130Z</updated>
  <entry>
    <author>
      <name>Azure Identity Support Japan</name>
    </author>
    <category term="Microsoft Entra" scheme="https://jpazureid.github.io/blog/tags/Microsoft-Entra/"/>
    <category term="MFA" scheme="https://jpazureid.github.io/blog/tags/MFA/"/>
    <category term="Passkey" scheme="https://jpazureid.github.io/blog/tags/Passkey/"/>
    <content>
      <![CDATA[<p>こんにちは、Azure &amp; Identity サポート チームの長谷川です。<br><a href="https://learn.microsoft.com/entra/identity/authentication/concept-sms-voice-retirement">既定で提供されている SMS&#x2F;音声通話の廃止が案内されました</a>。それに伴い 2026 年 9 月 1 日以降に順次パスキーと登録キャンペーンの自動有効化が順次展開されていく見込みです。</p><p>一方で、組織によってはこの自動有効化を延期したい要望もあり、この要望に対応するための <a href="https://learn.microsoft.com/entra/identity/authentication/concept-sms-voice-retirement#temporarily-opt-out-of-the-automatic-passkey-enablement">自動パスキー有効化を一時的にオプトアウトする</a>設定が公開されました。<br>しかしながら、公開されたオプトアウト設定 (optOutSettings) 手順は、慣れた人でないと設定が難しいとのご意見をいただいております。そのため、Windows 11 上でオプトアウト設定作業を実施する際のステップ バイ ステップの手順を紹介します。<br>なお、上述の公開情報では、Microsoft Graph API の Web リクエストを手動で作成して設定する手順になっておりますが、今回紹介する手順では、より簡易に実施するために Microsoft Graph PowerShell モジュールを利用します(実施する設定内容は同じです)。</p><h2 id="Microsoft-Graph-PowerShell-モジュールを利用してオプトアウトする手順"><a href="#Microsoft-Graph-PowerShell-モジュールを利用してオプトアウトする手順" class="headerlink" title="Microsoft Graph PowerShell モジュールを利用してオプトアウトする手順"></a>Microsoft Graph PowerShell モジュールを利用してオプトアウトする手順</h2><ol><li><p>PowerShell を管理者権限で起動します。</p></li><li><p>以下のコマンドを実行し、Microsoft Graph PowerShell モジュールをインストールします。(既にモジュールがインストールされている場合はスキップしてください)</p> <figure class="highlight powershell"><table><tr><td class="code"><pre><span class="line"><span class="built_in">Install-Module</span> Microsoft.Graph <span class="literal">-Force</span></span><br></pre></td></tr></table></figure></li><li><p>以下のコマンドを実行し、対象テナントのグローバル管理者でサインインします。<br>([要求されているアクセス許可] という画面が表示された場合は、[承諾] を押下します)<br>(「このデバイスのすべてのアプリ、Web サイト、サービスにサインインしますか?」が表示された場合は「いいえ、このアプリのみです」を選択してください)<br>※ グローバル管理者を利用しない場合は、実行するユーザーに 2 つのロール (クラウド アプリケーション管理者と認証ポリシー管理者) が付与されていれば実行可能です。</p> <figure class="highlight powershell"><table><tr><td class="code"><pre><span class="line"><span class="built_in">Set-ExecutionPolicy</span> RemoteSigned <span class="literal">-Scope</span> <span class="keyword">Process</span></span><br><span class="line"><span class="built_in">Connect-MgGraph</span> <span class="literal">-Scopes</span> <span class="string">&quot;Policy.ReadWrite.AuthenticationMethod&quot;</span></span><br></pre></td></tr></table></figure></li><li><p>以下のコマンドを実行し、現在の optOutSettings の設定を確認します。オプトアウトを設定していない場合は、何も出力されません。</p> <figure class="highlight powershell"><table><tr><td class="code"><pre><span class="line">(<span class="built_in">Invoke-MgGraphRequest</span> <span class="literal">-Method</span> GET <span class="literal">-Uri</span> <span class="string">&quot;/beta/policies/authenticationmethodspolicy&quot;</span>).optOutSettings</span><br></pre></td></tr></table></figure></li><li><p>以下のコマンドを実行して optOutSettings を true に変更してオプトアウトします。</p> <figure class="highlight powershell"><table><tr><td class="code"><pre><span class="line"><span class="variable">$params</span> = <span class="selector-tag">@</span>&#123;</span><br><span class="line">  optOutSettings = <span class="selector-tag">@</span>&#123;</span><br><span class="line">    passkeyDynamicMigration = <span class="variable">$true</span></span><br><span class="line">  &#125;</span><br><span class="line">&#125;</span><br><span class="line"></span><br><span class="line"><span class="built_in">Invoke-MgGraphRequest</span> <span class="literal">-Method</span> PATCH <span class="literal">-Uri</span> <span class="string">&quot;/beta/policies/authenticationmethodspolicy&quot;</span> <span class="literal">-Body</span> <span class="variable">$params</span></span><br></pre></td></tr></table></figure></li><li><p>以下のコマンドを実行して optOutSettings の設定が変更されたことを確認します。</p> <figure class="highlight powershell"><table><tr><td class="code"><pre><span class="line">(<span class="built_in">Invoke-MgGraphRequest</span> <span class="literal">-Method</span> GET <span class="literal">-Uri</span> <span class="string">&quot;/beta/policies/authenticationmethodspolicy&quot;</span>).optOutSettings</span><br></pre></td></tr></table></figure></li><li><p>作業完了後、以下のコマンドでセッションを切断し作業を終了します。</p> <figure class="highlight powershell"><table><tr><td class="code"><pre><span class="line"><span class="built_in">Disconnect-MgGraph</span></span><br></pre></td></tr></table></figure></li></ol><p>上記コマンド実行時の PowerShell 画面イメージは以下の通りです。</p><p><img src="/blog/azure-active-directory/optoutsettings-passkeydynamicmigration-true/optoutsettings-passkeydynamicmigration-true.png"></p><h2 id="免責事項"><a href="#免責事項" class="headerlink" title="免責事項"></a>免責事項</h2><p>本サンプル コードは、あくまでも説明のためのサンプルとして提供されるものであり、製品の実運用環境で使用されることを前提に提供されるものではありません。<br>本サンプル コードおよびそれに関連するあらゆる情報は、「現状のまま」で提供されるものであり、商品性や特定の目的への適合性に関する黙示の保証も含め、明示・黙示を問わずいかなる保証も付されるものではありません。<br>マイクロソフトは、お客様に対し、本サンプル コードを使用および改変するための非排他的かつ無償の権利ならびに本サンプル コードをオブジェクト コードの形式で複製および頒布するための非排他的かつ無償の権利を許諾します。<br>但し、お客様は以下の 3 点に同意するものとします。</p><p>(1) 本サンプル コードが組み込まれたお客様のソフトウェア製品のマーケティングのためにマイクロソフトの会社名、ロゴまたは商標を用いないこと<br>(2) 本サンプル コードが組み込まれたお客様のソフトウェア製品に有効な著作権表示をすること<br>(3) 本サンプル コードの使用または頒布から生じるあらゆる損害（弁護士費用を含む）に関する請求または訴訟について、マイクロソフトおよびマイクロソフトの取引業者に対し補償し、損害を与えないこと</p><h2 id="おわりに"><a href="#おわりに" class="headerlink" title="おわりに"></a>おわりに</h2><p>本記事では自動パスキー有効化を一時的にオプトアウトする手順を具体的に紹介しました。製品動作に関する正式な見解や回答については、お客様環境などを十分に把握したうえでサポート部門より提供しますので、ぜひ弊社サポート サービスをご利用ください。</p>]]>
    </content>
    <id>https://jpazureid.github.io/blog/azure-active-directory/optoutsettings-passkeydynamicmigration-true/</id>
    <link href="https://jpazureid.github.io/blog/azure-active-directory/optoutsettings-passkeydynamicmigration-true/"/>
    <published>2026-08-06T00:00:00.000Z</published>
    <summary>
      <![CDATA[<p>こんにちは、Azure &amp; Identity サポート チームの長谷川です。<br><a href="https://learn.microsoft.com/entra/identity/authentication/concept-sms-voice-retire]]>
    </summary>
    <title>自動パスキー有効化を一時的にオプトアウトする手順</title>
    <updated>2026-08-12T00:07:05.130Z</updated>
  </entry>
  <entry>
    <author>
      <name>Azure Identity Support Japan</name>
    </author>
    <category term="Microsoft Entra ID" scheme="https://jpazureid.github.io/blog/tags/Microsoft-Entra-ID/"/>
    <category term="Passkey" scheme="https://jpazureid.github.io/blog/tags/Passkey/"/>
    <category term="Registration campaign" scheme="https://jpazureid.github.io/blog/tags/Registration-campaign/"/>
    <content>
      <![CDATA[<p>こんにちは、Azure Identity サポート チームの長谷川です。</p><p>この記事では、MFA の認証方法を SMS や音声通話からパスキーへ移行する際に、組織内のユーザーへのパスキー展開を効率的に進めるために役立つ<a href="https://learn.microsoft.com/entra/identity/authentication/how-to-mfa-registration-campaign">登録キャンペーン</a> を利用したセットアップ方法をご紹介します。</p><p>現在、多くの組織で MFA (多要素認証) が広く利用されていますが、その認証方法として SMS や音声通話を利用しているユーザーも数多く存在します。すでに公開されているとおり、<a href="https://learn.microsoft.com/entra/identity/authentication/concept-sms-voice-retirement">Microsoft Entra ID が既定で提供している SMS や音声通話といった電話網ベースの認証方法は廃止に向けた移行が進められています</a>。そのため、パスキーの導入や展開を検討されているお客様も多いのではないでしょうか。</p><p>登録キャンペーンを利用することで、組織内へのパスキー展開を効率的に進めることができます。前述の公開情報でも設定方法が紹介されていますが、テキスト中心の説明のため、具体的なイメージを持ちにくい場合があります。本記事では、各手順をスクリーン ショット付きでわかりやすく解説していますので、パスキー展開時の参考としてぜひご活用ください。</p><h2 id="1-想定シナリオ"><a href="#1-想定シナリオ" class="headerlink" title="1. 想定シナリオ"></a>1. 想定シナリオ</h2><ul><li>この記事では、すでに電話 (SMS) を MFA の認証方法として利用しているユーザーが、セキュリティ キーを利用したパスキーをセットアップする手順を紹介します。</li><li>セキュリティ キーの機種によっては、利用を開始する前に、暗証番号 (PIN) の設定など、セキュリティ キー自体の初期設定が必要な場合があります。必要な事前準備については、ご利用のセキュリティ キーのベンダーにご確認ください。</li><li>この記事では、事前設定が完了した YubiKey 5Ci を使用して手順を作成しています。</li><li>また、この記事の手順では Microsoft Edge を使用しています。他のブラウザーを利用する場合、一部の画面やポップアップの表示が異なることがあります。</li></ul><h2 id="2-事前準備"><a href="#2-事前準備" class="headerlink" title="2. 事前準備"></a>2. 事前準備</h2><p>パスキーを利用するには、<a href="https://learn.microsoft.com/entra/identity/authentication/how-to-authentication-methods-manage#authentication-methods-policy">認証方法ポリシー</a>でパスキー (FIDO2) が有効化されており、対象ユーザーを含むグループがターゲットとして設定されている必要があります。<br>管理者にて [Microsoft Entra 管理センター (entra.microsoft.com)] &gt; [認証方法] &gt; <a href="https://entra.microsoft.com/#view/Microsoft_AAD_IAM/AuthenticationMethodsMenuBlade/~/AdminAuthMethods/fromNav/">ポリシー</a> &gt; [パスキー(FIDO2)] で有効化し、対象のユーザーを含むグループがターゲットに追加されていることを確認してください (下図のようにグループではなくすべてのユーザーを指定することもできます)。<br>なお、[パスキー (FIDO2)] の [構成] タブにある [セルフサービス設定を許可] は、既定で有効に設定されています。意図的に無効化している場合は、本手順を実施する前に有効化してください (チェックが入っている場合は有効です)。</p><p><img src="/blog/azure-active-directory/how-to-set-up-a-passkey-via-registration-campaign/registration-campaign01.png"></p><h2 id="3-登録キャンペーンの有効化"><a href="#3-登録キャンペーンの有効化" class="headerlink" title="3. 登録キャンペーンの有効化"></a>3. 登録キャンペーンの有効化</h2><p>3-1. [Microsoft Entra 管理センター (entra.microsoft.com)] &gt; [認証方法] &gt; <a href="https://entra.microsoft.com/#view/Microsoft_AAD_IAM/AuthenticationMethodsMenuBlade/~/RegistrationCampaign/fromNav/">登録キャンペーン</a> にアクセスします。</p><p>3-2. 次のように設定し [保存] します。</p><table><thead><tr><th>設定項目</th><th>設定値</th></tr></thead><tbody><tr><td>状態</td><td>有効</td></tr><tr><td>認証方法</td><td>パスキー (FIDO2)</td></tr><tr><td>再通知できる日数</td><td>任意に設定します。登録キャンペーンによる登録画面が表示される間隔を指定します。</td></tr><tr><td>再通知の回数が制限されています</td><td>任意に設定します。有効になっている場合は、ユーザーは登録キャンペーンによる登録画面を 3 回スキップできますが、4 回目以降は登録が強制されます。</td></tr><tr><td>含む</td><td>登録キャンペーンの対象にするユーザーのグループを指定します。</td></tr><tr><td>除外</td><td>登録キャンペーンから除外したいユーザーを明示的に指定します。</td></tr></tbody></table><p><img src="/blog/azure-active-directory/how-to-set-up-a-passkey-via-registration-campaign/registration-campaign02.png"></p><div class="alert is-info"><p class="alert-title">Note</p><p>登録キャンペーンを有効化後、実際に登録キャンペーンによって認証方法の登録が要求されるようになるまで少し時間がかかる場合があります (検証環境では 1 時間程度かかった事例があります)。</p></div><h2 id="4-登録キャンペーンでパスキーの登録-セットアップ-を完了させるまでの流れ"><a href="#4-登録キャンペーンでパスキーの登録-セットアップ-を完了させるまでの流れ" class="headerlink" title="4. 登録キャンペーンでパスキーの登録 (セットアップ) を完了させるまでの流れ"></a>4. 登録キャンペーンでパスキーの登録 (セットアップ) を完了させるまでの流れ</h2><p>登録キャンペーンは MFA が完了したタイミングで動作します。この動作をスクリーンショット付きで紹介します。</p><p>4-1. MFA を完了させます。<br><img src="./registration-campaign04.png" width="50%"></p><p>4-2. 「アカウントをセキュリティ保護しましょう」という認証方法の登録を誘導する画面が表示されますので [次へ] 進みます。<br><img src="./registration-campaign05.png" width="50%"></p><div class="alert is-success"><p class="alert-title">ヒント</p><p>なお、この「アカウントをセキュリティ保護しましょう」の画面で [今はしない] を選択すると認証方法の登録をスキップすることができます。</p><p><img src="./registration-campaign06.png" width="30%"></p></div><p>4-3. 以下のパスキーの登録が始まる画面が表示されます。セキュリティ キーが作業端末に接続されていることを確認してから [次へ] 進みます。<br><img src="./registration-campaign07.png" width="50%"></p><p>4-4. パスキーの登録が開始されます。自動で次の画面に遷移します。<br><img src="./registration-campaign08.png" width="50%"></p><p>4-5. パスキーの保存先を指定します。既定では下図のように Windows に保存する選択肢になっている場合があります。この場合は [変更] を選択します。<br><img src="./registration-campaign09.png" width="50%"></p><p>4-6. パスキーの保存先選択画面が表示されるのでセキュリティ キーを選択します。<br><img src="./registration-campaign10.png" width="50%"></p><p>4-7. セキュリティ キーのモデルによっては事前に設定した暗証番号 (PIN) の入力が要求されるので入力してから [OK] を選択します。<br><img src="./registration-campaign11.png" width="50%"></p><p>4-8. セキュリティ キーのモデルによってはキーへの物理的な接触が要求されますので、キーに触れます。<br><img src="./registration-campaign12.png" width="50%"></p><p>4-9. 後でセキュリティ情報ページで識別できるよう、パスキーに任意の名前を付けて [次へ] を選択します。<br><img src="./registration-campaign13.png" width="50%"></p><p>4-10. [完了] を選択してパスキーの登録 (セットアップ) を終了します。<br><img src="./registration-campaign14.png" width="50%"></p><div class="alert is-success"><p class="alert-title">ヒント</p><p>登録したパスキーは各自の<a href="https://aka.ms/mysecurityinfo">セキュリティ情報</a>のページから確認することができます。</p><p><img src="/blog/azure-active-directory/how-to-set-up-a-passkey-via-registration-campaign/registration-campaign15.png"></p></div><h2 id="5-おわりに"><a href="#5-おわりに" class="headerlink" title="5. おわりに"></a>5. おわりに</h2><p>以上、登録キャンペーンを利用して認証方法にパスキー (セキュリティ キー) をセットアップする手順を紹介しました。<br>パスキーはフィッシング耐性を備えた認証方法であり、今後、認証方法の中心となることが期待されています。<br>SMS や音声通話を利用した認証方法の廃止に備え、本記事を参考に登録キャンペーンを活用したパスキー展開をご検討ください。<br>製品動作に関する正式な見解や回答については、お客様環境などを十分に把握したうえでサポート部門より提供しますので、ぜひ弊社サポート サービスをご利用ください。</p>]]>
    </content>
    <id>https://jpazureid.github.io/blog/azure-active-directory/how-to-set-up-a-passkey-via-registration-campaign/</id>
    <link href="https://jpazureid.github.io/blog/azure-active-directory/how-to-set-up-a-passkey-via-registration-campaign/"/>
    <published>2026-08-01T00:00:00.000Z</published>
    <summary>
      <![CDATA[<p>こんにちは、Azure Identity サポート チームの長谷川です。</p>
<p>この記事では、MFA の認証方法を SMS や音声通話からパスキーへ移行する際に、組織内のユーザーへのパスキー展開を効率的に進めるために役立つ<a href="https://learn]]>
    </summary>
    <title>登録キャンペーンを利用して認証方法にパスキー (セキュリティ キーを利用) をセットアップする手順</title>
    <updated>2026-08-12T00:07:04.695Z</updated>
  </entry>
  <entry>
    <author>
      <name>Azure Identity Support Japan</name>
    </author>
    <category term="Microsoft Entra ID" scheme="https://jpazureid.github.io/blog/tags/Microsoft-Entra-ID/"/>
    <category term="Passkey" scheme="https://jpazureid.github.io/blog/tags/Passkey/"/>
    <content>
      <![CDATA[<p>こんにちは、Azure Identity サポート チームの長谷川です。</p><p>Microsoft Entra ID の認証方法にパスキーを利用する方が増え始めていると思います。パスキーは従来の電話網を利用した認証方法 (SMS や音声通話) などよりもセキュリティ レベルの高い認証方法になるため、多くのお客様にご利用いただきたい認証方法です。しかしながら、ユーザーにパスキーを展開するにあたり、セットアップ手順に不安があるとの声をいただいています。<br>このため、この記事では、セキュリティ キーを利用したパスキーをセットアップする手順を紹介します。ステップごとにスクリーン ショットを使ったセットアップ手順になっていますので、パスキー展開にご活用いただければと思います。</p><h2 id="想定シナリオ"><a href="#想定シナリオ" class="headerlink" title="想定シナリオ"></a>想定シナリオ</h2><p>この記事では、MFA に利用できる認証方法が何もセットアップされていないユーザーにおいて、PC でセキュリティ キーを利用したパスキーをセットアップするシナリオを想定して記載いたします(このために一時アクセス パスを利用する手順になっています)。<br>もし MFA に利用できる認証方法 (たとえば Microsoft Authenticator アプリのプッシュ通知) をすでにセットアップ済みのユーザーの場合は、後述の「1. サインインしてセキュリティ情報ページへアクセス」の手順をスキップして「2. セットアップ手順」から実施してください。<br>なお、セキュリティ キーのモデルによっては、利用前にそのセキュリティ キー自体を利用するための事前作業 (暗証番号 (PIN) の設定など) が必要な場合があります。必要な事前準備などについてはご利用のセキュリティ キーのベンダーへご確認ください。この記事はセキュリティ キーに事前作業済みの YubiKey 5Ci を利用して作成しています。<br>なお、本手順内ではブラウザーに Microsoft Edge を利用して作成しています。他のブラウザーを利用した場合は一部ポップアップなどの表示が異なる可能性があります。</p><h2 id="1-サインインしてセキュリティ情報ページへアクセス"><a href="#1-サインインしてセキュリティ情報ページへアクセス" class="headerlink" title="1. サインインしてセキュリティ情報ページへアクセス"></a>1. サインインしてセキュリティ情報ページへアクセス</h2><p>1-1. 管理者にて対象ユーザーに <a href="https://learn.microsoft.com/ja-jp/entra/identity/authentication/howto-authentication-temporary-access-pass">一時アクセス パスを発行</a> して提供します。</p><p>1-2. 対象ユーザーにて PC で <a href="https://aka.ms/mysecurityinfo">https://aka.ms/mysecurityinfo</a> にアクセスし、一時アクセス パスを使用してサインインします。<br><img src="./security-key-setup01.png" width="50%"></p><h2 id="2-セットアップ手順"><a href="#2-セットアップ手順" class="headerlink" title="2. セットアップ手順"></a>2. セットアップ手順</h2><p>2-1. セキュリティ キーを PC に接続しておきます。セキュリティ キーのモデルによっては利用前に事前準備が必要な場合があります。必要な事前準備などについてはご利用のセキュリティ キーのベンダーへご確認ください。</p><p>2-2. [サインイン方法の追加] を選択します。<br><img src="/blog/azure-active-directory/how-to-set-up-a-passkey-using-a-security-key/security-key-setup02.png"></p><p>2-3. [パスキー] を選択します。<br><img src="/blog/azure-active-directory/how-to-set-up-a-passkey-using-a-security-key/security-key-setup03.png"></p><p>2-4. [次へ] を選択します。<br><img src="./security-key-setup04.png" width="50%"></p><p>2-5. ブラウザーに Microsoft Edge を利用している場合、以下のように Microsoft パスワード マネージャーにパスキーを保存するかの確認ポップアップが表示される可能性があります。[別の方法で保存する] を選択します。<br><img src="./security-key-setup05.png" width="50%"></p><p>2-6. [Windows Hello または外部のセキュリティ キー] を選択します。<br><img src="./security-key-setup06.png" width="50%"></p><p>2-7. 赤枠に表示されている文言を確認します。下図のように [これはセキュリティ キー に保存されます] と表示されている場合は [これはセキュリティ キー に保存されます] をクリックします。<br><img src="./security-key-setup07-1.png" width="50%"><br>下図のように [これはセキュリティ キー に保存されます] <strong>以外</strong> が表示されている場合は [変更] を選択し、次の画面で [セキュリティ キー] を選択します。<br><img src="./security-key-setup07-2.png" width="50%"></p><p>2-8. セキュリティ キーの暗証番号 (PIN) の入力を求められた場合は入力して [OK] を選択します。<br><img src="./security-key-setup08.png" width="50%"></p><p>2-9. セキュリティ キーへの接触を求められた場合はタッチします。<br><img src="./security-key-setup09.png" width="50%"></p><p>2-10. 登録したパスキー (セキュリティ キー) をセキュリティ情報のページ上で識別できるように任意の名前を付けて [次へ] を選択します。<br><img src="/blog/azure-active-directory/how-to-set-up-a-passkey-using-a-security-key/security-key-setup10.png"></p><p>2-11. 「パスキーが作成されました」と表示されたら [完了] を選択します。<br><img src="./security-key-setup11.png" width="50%"></p><p>2-12. セキュリティ情報のページ上でもパスキーが追加されたことを確認できればセットアップ完了です。<br><img src="/blog/azure-active-directory/how-to-set-up-a-passkey-using-a-security-key/security-key-setup12.png"></p><h2 id="3-セットアップしたセキュリティ-キーのパスキーを利用したサインイン手順-パスワードレス"><a href="#3-セットアップしたセキュリティ-キーのパスキーを利用したサインイン手順-パスワードレス" class="headerlink" title="3. セットアップしたセキュリティ キーのパスキーを利用したサインイン手順 (パスワードレス)"></a>3. セットアップしたセキュリティ キーのパスキーを利用したサインイン手順 (パスワードレス)</h2><p>3-1. パスキーをセットアップしたセキュリティ キーを PC に接続しておきます。</p><p>3-2. サインインが発生したら Entra アカウントの UPN を入力して [次へ] を選択します。</p><p>3-3. パスワードの入力画面が表示された場合はパスワードを入力せずに [代わりに顔、指紋、PIN、またはセキュリティキーを使用する] を選択します。<br><img src="./security-key-setup13.png" width="50%"></p><p>3-4. パスキーの選択画面が表示されるので [セキュリティ キー] を選択します。<br><img src="./security-key-setup14.png" width="50%"></p><p>3-5. セキュリティ キーの暗証番号 (PIN) の入力を求められた場合は入力して [OK] を選択します。<br><img src="./security-key-setup15.png" width="50%"></p><p>3-6. セキュリティ キーへの接触を求められた場合はタッチします。<br><img src="./security-key-setup16.png" width="50%"></p><p>3-7. サインインが完了します。</p><h2 id="おわりに"><a href="#おわりに" class="headerlink" title="おわりに"></a>おわりに</h2><p>以上、認証方法にパスキー (セキュリティ キーを利用) をセットアップする手順を紹介しました。パスキーはフィッシング攻撃に耐性があり、今後 MFA の認証方法の中心となると想定される認証方法です。これまで中心となっていた Microsoft Authenticator アプリのプッシュ通知はスマートフォンを用意する必要があったため、特に BYOD を利用しない組織ではコスト面で負担が大きいものでした。一方でセキュリティ キーはスマートフォンよりもコスト少なく導入できるため、様々な組織で取り入れやすい仕組みと考えられています。本記事を活用して多くの方にパスキーをご利用いただき組織のセキュリティ向上の一役を担えれば嬉しく思います。<br>製品動作に関する正式な見解や回答については、お客様環境などを十分に把握したうえでサポート部門より提供しますので、ぜひ弊社サポート サービスをご利用ください。</p>]]>
    </content>
    <id>https://jpazureid.github.io/blog/azure-active-directory/how-to-set-up-a-passkey-using-a-security-key/</id>
    <link href="https://jpazureid.github.io/blog/azure-active-directory/how-to-set-up-a-passkey-using-a-security-key/"/>
    <published>2026-07-21T00:00:00.000Z</published>
    <summary>
      <![CDATA[<p>こんにちは、Azure Identity サポート チームの長谷川です。</p>
<p>Microsoft Entra ID の認証方法にパスキーを利用する方が増え始めていると思います。パスキーは従来の電話網を利用した認証方法 (SMS や音声通話) などよりもセキュリティ]]>
    </summary>
    <title>認証方法にパスキー (セキュリティ キーを利用) をセットアップする手順</title>
    <updated>2026-08-12T00:07:04.683Z</updated>
  </entry>
  <entry>
    <author>
      <name>Azure Identity Support Japan</name>
    </author>
    <category term="Microsoft Entra ID" scheme="https://jpazureid.github.io/blog/tags/Microsoft-Entra-ID/"/>
    <category term="MFA" scheme="https://jpazureid.github.io/blog/tags/MFA/"/>
    <category term="Passkey" scheme="https://jpazureid.github.io/blog/tags/Passkey/"/>
    <category term="Microsoft Security Blog" scheme="https://jpazureid.github.io/blog/tags/Microsoft-Security-Blog/"/>
    <category term="Passwordless" scheme="https://jpazureid.github.io/blog/tags/Passwordless/"/>
    <content>
      <![CDATA[<p>こんにちは、Azure &amp; Identity サポート チームの 田辺 です。<br>本記事は、2026 年 7 月 13 日に米国の Microsoft Security Blog で公開された <a href="https://www.microsoft.com/en-us/security/blog/2026/07/13/microsoft-entra-id-security-updates-passkeys-are-the-default-authentication-method-in-entra-id/">Microsoft Entra ID security updates: Passkeys are the default authentication method in Entra ID</a> を意訳したものになります。ご不明点はサポート チームまでお問い合わせください。</p><span id="more"></span><hr><h2 id="はじめに"><a href="#はじめに" class="headerlink" title="はじめに"></a>はじめに</h2><p>AI 時代を迎え、ID を狙う攻撃はますます巧妙になっています。こうした状況では、フィッシングや資格情報の窃取、ソーシャル エンジニアリングからユーザーを守る、より強固な認証方法が組織に求められます。この進化する脅威に対応するため、<a href="https://www.microsoft.com/ja-jp/security/business/identity-access/microsoft-entra-id">Microsoft Entra ID</a> は認証エクスペリエンスを見直し、フィッシングに強い認証方法であるパスキーを既定とすることで、SMS や音声通話といったフィッシング可能な方法への依存を減らせるようにします。</p><p>2026 年 9 月 1 日より、Microsoft は Microsoft Entra ID における既定の認証エクスペリエンスとしてパスキーの段階的な展開を開始します。各組織に展開が適用されると、SMS または音声通話による認証が有効になっているユーザーは自動的にパスキーが有効化され、次回の多要素認証 (MFA) の際にパスキーの登録を促されるようになります。</p><p>この移行に続き、2027 年 2 月 1 日には、Microsoft が提供する SMS および音声通話認証向けの通信サービスを廃止し、SMS と音声通話を <a href="https://www.microsoft.com/ja-jp/security/business/microsoft-entra">Microsoft Entra</a> のネイティブ機能としては提供しなくなります。引き続き SMS や音声通話による認証が必要な組織は、Microsoft Security Store を通じて通信事業者パートナーのいずれかを選択することができます。その際、通信事業者パートナーから請求される通信関連の費用はお客様のご負担となります。</p><p>できるだけ早い段階で、ユーザーの MFA の認証方法を、SMS や音声通話などフィッシングに弱い方法から、パスキーなどフィッシングに強い認証方法へ移行させることを強くおすすめします。</p><h2 id="AI-時代になぜより強固な認証が重要なのか"><a href="#AI-時代になぜより強固な認証が重要なのか" class="headerlink" title="AI 時代になぜより強固な認証が重要なのか"></a>AI 時代になぜより強固な認証が重要なのか</h2><p>SMS や音声通話による認証は、共有シークレットや通信経路に依存しています。攻撃者は、これらを傍受したり、フィッシングでだまし取ったり、不正に操作したりする手口を年々増やしています。<a href="https://www.microsoft.com/ja-jp/security/business/security-101/what-is-passkey">パスキー</a> は共有シークレットではなく公開鍵暗号方式を利用するため、設計上フィッシングに強い特性を備えています。加えて、ユーザーにとってより高速でシンプルなサインイン体験を提供します。</p><p>SMS や音声通話から脱却すべき理由は、もはや攻撃者がこれらを傍受したりソーシャル エンジニアリングで悪用したりするという点だけにとどまりません。脅威を取り巻く環境は、速度、規模、巧妙さの面で変化しています。Microsoft Threat Intelligence は、AI を活用したフィッシング攻撃活動でクリック率が最大 54% に達する事例を観測しており、これは従来型の攻撃活動のおよそ 12% と比べて大幅に高い値です ※1。その結果、盗まれたパスワードや、フィッシングで突破できてしまう 2 つ目 (MFA) の認証要素が、差し迫ったリスクとなっています。同時に、SIM スワップや MFA バイパスといった手口も、以前より容易かつ再現しやすいものになっています。</p><p>AI を活用したサイバー攻撃では、侵害された ID を用いて、探索、権限昇格、横方向の移動といった一連の動作を、人間の攻撃者が手作業で行うよりもはるかに高速に自動化できます。だからこそ、フィッシングに強い認証方法が非常に重要になります。</p><p>パスキーを既定の認証エクスペリエンスとすることで、組織はフィッシング可能な認証方法への依存を減らし、資格情報の窃取やフィッシングに対する防御を強化できます。</p><h2 id="SMS-や音声通話が引き続き必要な場合は-Microsoft-Security-Store-で通信事業者を選択"><a href="#SMS-や音声通話が引き続き必要な場合は-Microsoft-Security-Store-で通信事業者を選択" class="headerlink" title="SMS や音声通話が引き続き必要な場合は Microsoft Security Store で通信事業者を選択"></a>SMS や音声通話が引き続き必要な場合は Microsoft Security Store で通信事業者を選択</h2><p>現在、SMS および音声通話認証の背後にある通信サービスは、Microsoft が Entra ID 内でネイティブに提供しています。今回の移行の一環として、Microsoft はこのネイティブな通信サービスの提供から一歩引くことで、フィッシングに強い認証方法をすべての人にとっての標準とすることを後押しします。</p><p>多くの組織にとって、推奨される移行方法はシンプルです。追加費用なしでユーザーをパスキーへ移行するというものです。</p><p>規制、技術、業務上の理由で SMS や音声通話を維持する必要がある場合は、Microsoft Security Store を通じてサードパーティの通信事業者を選択、構成、管理できるようになります。Microsoft Security Store は、対応する通信事業者と直接契約できるパートナー マーケットプレースです。</p><p>2026 年 9 月 18 日には、対応する事業者に関する情報、展開ガイダンス、技術ドキュメントを公開する予定です。料金や取引条件は Microsoft Security Store を通じて確認できるようになります。</p><h2 id="移行の準備"><a href="#移行の準備" class="headerlink" title="移行の準備"></a>移行の準備</h2><p>サインイン体験の変更に向けてユーザーが備えられるよう、また組織に最適な展開方法を選択できるよう、今のうちから移行の計画を始めましょう。</p><ol><li><strong>SMS や音声通話を今も利用しているユーザーを特定する。</strong> 認証方法ポリシーを確認し、SMS または音声通話認証が有効になっているユーザーやグループを洗い出します。</li><li><strong>パスキーの展開を計画する。</strong> <a href="https://learn.microsoft.com/ja-jp/entra/identity/authentication/concept-authentication-passkeys-fido2">パスキー</a> を有効化し、ユーザーのデバイスや業務に合った種類を選択します。Microsoft Entra ID は以下をサポートしています。<ul><li>同期されたパスキー (iCloud キーチェーンや Google パスワード マネージャーなど、プラットフォームの資格情報マネージャーに保存されるパスキー)</li><li>デバイスにバインドされたパスキー (Microsoft Authenticator のパスキー、Windows 上の Entra パスキー、FIDO2 セキュリティ キーなど)</li></ul></li><li><strong><a href="https://learn.microsoft.com/ja-jp/entra/identity/authentication/how-to-mfa-registration-campaign">登録キャンペーン</a> を活用して導入を促進する。</strong> Microsoft Entra ID は、多要素認証によるサインイン時にパスキーの登録を促すことで、組織が大規模にユーザーを移行させる手助けをします。</li><li><strong>ユーザーへの案内を準備する。</strong> 何が変わるのか、いつパスキー登録のプロンプトが表示されるのか、デバイスでどのように登録を完了するのかを、対象ユーザーに伝えます。</li></ol><p>パスキーの計画、展開、管理に関する手順の詳細は、Microsoft Learn のドキュメントおよびパスキー展開ガイドをご覧ください。</p><ul><li><a href="https://aka.ms/passkeybydefault">既定でのパスキーと、Microsoft が提供する SMS および音声認証の廃止</a></li><li><a href="https://learn.microsoft.com/ja-jp/entra/identity/authentication/how-to-plan-prerequisites-phishing-resistant-passwordless-authentication">Microsoft Entra ID でフィッシングに強いパスワードレス認証の展開を始める</a></li></ul><p>規制、技術、運用上のシナリオで引き続き SMS や音声通話が必要な場合は、次のように進めます。</p><ol><li>影響を受けるユーザー セグメントを特定し、記録します。</li><li>2026 年 10 月 30 日以降、Microsoft Security Store を通じて対応する通信事業者を選択、構成します。</li><li>本格展開の前に、パイロット グループで構成をテストします。</li></ol><h2 id="タイムライン"><a href="#タイムライン" class="headerlink" title="タイムライン"></a>タイムライン</h2><table><thead><tr><th>日付</th><th>内容</th></tr></thead><tbody><tr><td>2026 年 9 月 1 日</td><td>SMS または音声通話が有効なすべてのユーザーにパスキーの利用が自動的に有効化され、多要素認証によるサインイン時にパスキー登録を促されます。パスキー展開ガイドを利用して、パスキー利用に向けた環境を準備してください。対象ユーザーに今後の変更を通知してください。すべてのユーザーが、パスキー、Windows 上の Entra パスキー、FIDO2 セキュリティ キーなど、フィッシングに強い認証方法を備えていることを確認してください。</td></tr><tr><td>2026 年 9 月 18 日</td><td>料金、取引条件、対応する通信事業者の一覧が公開されます。SMS や音声通話認証の継続利用を予定している場合は、利用可能な事業者の選択肢を確認し、影響を受けるユーザーを特定してください。</td></tr><tr><td>2026 年 10 月 30 日</td><td>管理者は Microsoft Security Store を通じて対応する通信事業者を選択、構成できるようになります。</td></tr><tr><td>2027 年 2 月 1 日</td><td>Microsoft が提供する SMS および音声通話認証が終了します。特定のユーザーに引き続き SMS や音声通話が必要な場合は、この日までに対応する通信事業者を構成してください。</td></tr><tr><td>2027 年 2 月 1 日以降</td><td>SMS または音声通話を多要素認証に利用しているユーザーは、サインイン前にパスキーの登録が必須となります。パスキー登録を促す自動プロンプトが、すべてのテナントのすべてのユーザーに対して強制されます。オプトアウトの選択肢はありません。</td></tr></tbody></table><p>注: 本記事に記載した日付は、パブリック クラウドの Microsoft Entra ID にのみ適用されます (日本の大部分のお客様はこちらに該当します)。その他のクラウド環境 (米国政府向けの Azure Government など) への対応は別のタイムラインで行われ、追加のガイダンスと日付は事前に案内されます。</p><p>SMS や音声通話はこれまで十分にその役割を果たし、そうでなければ多要素認証を利用できなかったであろう何十億もの人々に MFA を届けてきました。しかし、脅威を取り巻く環境はこれらの能力を超えて進化しており、私たちもそれに合わせて進化する必要があります。</p><p>Microsoft がパスキーを Entra ID の既定とするのは、パスキーがユーザーにとってはより良く、サイバー攻撃者にとってはより不都合だからです。この移行では、何がいつ起きるかを見通せるよう、明確な日付を示し、移行期間中はフォールバックの手段を用意し、フィッシング可能な資格情報に頼らない <a href="https://learn.microsoft.com/ja-jp/entra/identity/authentication/concept-account-recovery-overview">アカウント回復</a> を提供します。</p><p>詳細は <a href="https://aka.ms/passkeybydefault">既定でのパスキーと、Microsoft が提供する SMS および音声認証の廃止</a> をご覧ください。</p><p><a href="https://www.microsoft.com/ja-jp/security/business/microsoft-entra">Microsoft Entra の ID およびアクセス ソリューションの詳細はこちら</a></p><p>Microsoft セキュリティ ソリューションの詳細については、当社の <a href="https://www.microsoft.com/ja-jp/security">Web サイト</a> をご覧ください。<br>セキュリティに関する専門的な解説を継続的に入手するために、<a href="https://www.microsoft.com/en-us/security/blog/">Security ブログ</a> をブックマークすることをおすすめします。<br>また、サイバー セキュリティに関する最新情報やアップデートについては、LinkedIn (<a href="https://www.linkedin.com/showcase/microsoft-security/">Microsoft Security</a>) および X (<a href="https://x.com/MSFTSecurity">@MSFTSecurity</a>) でもご確認いただけます。</p><hr><p>※1 <a href="https://aka.ms/mddr">Microsoft Digital Defense Report 2025</a>.</p>]]>
    </content>
    <id>https://jpazureid.github.io/blog/azure-active-directory/passkeys-default-authentication-method-in-entra-id/</id>
    <link href="https://jpazureid.github.io/blog/azure-active-directory/passkeys-default-authentication-method-in-entra-id/"/>
    <published>2026-07-14T15:00:00.000Z</published>
    <summary>
      <![CDATA[<p>こんにちは、Azure &amp; Identity サポート チームの 田辺 です。<br>本記事は、2026 年 7 月 13 日に米国の Microsoft Security Blog で公開された <a href="https://www.microsoft.com/en-us/security/blog/2026/07/13/microsoft-entra-id-security-updates-passkeys-are-the-default-authentication-method-in-entra-id/">Microsoft Entra ID security updates: Passkeys are the default authentication method in Entra ID</a> を意訳したものになります。ご不明点はサポート チームまでお問い合わせください。</p>]]>
    </summary>
    <title>MFA の既定の認証方法がパスキーに移行 (SMS / 音声通話の既定での提供が終了)</title>
    <updated>2026-08-12T00:07:05.132Z</updated>
  </entry>
  <entry>
    <author>
      <name>Azure Identity Support Japan</name>
    </author>
    <category term="Microsoft Graph" scheme="https://jpazureid.github.io/blog/tags/Microsoft-Graph/"/>
    <content>
      <![CDATA[<p>こんにちは、 Azure Identity サポート チームの三輪です。</p><p>Entra ID テナントやユーザーなどのオブジェクトを管理する方法には、各管理センター (Microsoft Entra 管理センターなど) の画面上で操作する以外にも、Microsoft Graph API を使う方法があります。<br>Microsoft Graph API は PowerShell コマンドとして呼び出せる Microsoft Graph PowerShell SDK も提供しております。<br>API やコマンドは、一括処理のためのスクリプトなどで活用するシナリオが一般的ですが、Microsoft Graph API を手軽に実行できるツールとして、Graph Explorer というツールがあります。<br>本記事では、Graph Explorer を初めて使用される方向けに使用方法について順を追ってご紹介します。</p><h2 id="GET-リクエストの実行"><a href="#GET-リクエストの実行" class="headerlink" title="[GET] リクエストの実行"></a>[GET] リクエストの実行</h2><p>まずは、[GET] リクエストを行う例をご紹介します。GET リクエストは、テナントやユーザーの情報を「取得」するために利用します。</p><p>題材として『contoso.com がどのテナントに紐づいているか』を確認する以下の Graph API を使用します。</p><figure class="highlight plaintext"><table><tr><td class="code"><pre><span class="line">https://graph.microsoft.com/v1.0/tenantRelationships/findTenantInformationByDomainName(domainName=&#x27;contoso.com&#x27;)</span><br></pre></td></tr></table></figure><p>特定のドメインが紐づいているテナントを確認する Graph API の公開情報は以下が該当します。<br>  <a href="https://learn.microsoft.com/ja-jp/graph/api/tenantrelationship-findtenantinformationbydomainname?view=graph-rest-1.0&tabs=http">tenantRelationship: findTenantInformationByDomainName - Microsoft Graph v1.0 | Microsoft Learn</a></p><h3 id="操作手順例"><a href="#操作手順例" class="headerlink" title="操作手順例"></a>操作手順例</h3><p>1. Graph Explorer ( <a href="https://developer.microsoft.com/en-us/graph/graph-explorer">https://developer.microsoft.com/en-us/graph/graph-explorer</a> ) を開きます。<br>2. 右上の人型アイコンをクリックし、サインインします。<br>自身で管理者の同意が必要なアクセス許可に同意する必要がある場合には、管理者（グローバル管理者、クラウドアプリケーション管理者、特権ロール管理者 等）のロール権限のあるユーザーにてサインインします。<br>（※予めアクセス許可を付与しておきたい場合にはこちら(<a href="https://jpazureid.github.io/blog/azure-active-directory/microsoft-graph-powershell-grant-permissions/">Microsoft Graph PowerShell アクセス許可の付与 | Japan Azure Identity Support Blog</a>)の記事をご参照ください）<br><img src="/blog/azure-active-directory/how-to-use-graph-explorer/1-1.png"><br>※サインイン時に [要求されているアクセス許可] のポップアップが表示された場合には承諾をクリックします。<br>※[組織の代理として同意する] はオフのままで問題ございません。<br>アイコンとテナント名が自身のものに変更されたことを確認します。<br><img src="/blog/azure-active-directory/how-to-use-graph-explorer/1-2.png"></p><p>3. 以下のクエリを入力し、[Run query] をクリックします。</p><figure class="highlight plaintext"><table><tr><td class="code"><pre><span class="line">https://graph.microsoft.com/v1.0/tenantRelationships/findTenantInformationByDomainName(domainName=&#x27;contoso.com&#x27;)  </span><br></pre></td></tr></table></figure><p>※ contoso.com を検索する際のクエリです。<br><img src="/blog/azure-active-directory/how-to-use-graph-explorer/1-3.png"></p><p>4. 以下のエラーは、必要な権限が足りていない場合に表示されるエラーです。<br>クエリの実行に必要なロール権限を持つユーザーで操作を実行してこのエラーとなる場合には、必要なアクセス許可が不足していることが疑われますので、5-1. 以降の対応をします。<br>エラーが発生しなかった場合は 7. を参照します。<br><img src="/blog/azure-active-directory/how-to-use-graph-explorer/1-4.png"></p><p>5-1. [Modify Permissions] をクリックし、必要なアクセス許可の候補が表示された場合には、必要なアクセス許可（今回の場合は、必要なアクセス許可は CrossTenantInformation.ReadBasic.All）の [Consent] をクリックしてアクセス許可を承諾します。<br>※『 要求されているアクセス許可 』のポップアップが表示された場合には承諾をクリックします。<br>※『組織の代理として同意する』のチェックボックスがある場合、こちらにチェックを入れる必要はありません。<br><img src="/blog/azure-active-directory/how-to-use-graph-explorer/1-5.png"><br><img src="/blog/azure-active-directory/how-to-use-graph-explorer/1-6.png"></p><p>5-2. [Modify Permissions] にて必要なアクセス許可が表示されなかった場合で、 [Open the permissions panel] のリンクが表示されている場合には、このリンクをクリックします。<br><img src="/blog/azure-active-directory/how-to-use-graph-explorer/1-7.png"></p><p>その他、(ユーザー アイコンのクリック) &gt; [Consent to permissions] からも Permissions panel を開くことができます。<br><img src="/blog/azure-active-directory/how-to-use-graph-explorer/1-8.png"></p><p>必要なアクセス許可（今回は CrossTenantInformation.ReadBasic.All ）を検索し、[Consent] をクリックしてアクセス許可を承諾します。<br>※『 要求されているアクセス許可 』のポップアップが表示された場合には承諾をクリックします。<br>※『組織の代理として同意する』のチェックボックスがある場合、こちらにチェックを入れる必要はありません。</p><p>6. 再度 [ Run query ] をクリックします。<br><br>7. 表示された結果から確認可能です。<br>本例では、contoso.com が contoso18839.onmicrosoft.com というイニシャル ドメインを保有するテナント上にカスタムドメインとして登録済みであることが確認できます。<br><img src="/blog/azure-active-directory/how-to-use-graph-explorer/1-9.png"></p><h2 id="PATCH-リクエストの実行"><a href="#PATCH-リクエストの実行" class="headerlink" title="[PATCH] リクエストの実行"></a>[PATCH] リクエストの実行</h2><p>次に [PATCH] リクエストを行う例をご紹介します。PATCH リクエストは、テナントやユーザーの情報を部分的に「更新」するために利用します。</p><p>題材として『特定のユーザーの携帯電話と拡張属性を更新する』こととします。<br>ユーザー情報の更新についての公開情報は以下が該当いたします。<br><a href="https://learn.microsoft.com/ja-jp/graph/api/user-update?view=graph-rest-1.0&tabs=http#example-3-update-the-passwordprofile-of-a-user-and-reset-their-password">ユーザーを更新する - Microsoft Graph v1.0 | Microsoft Learn</a>  </p><p>※ユーザーの携帯電話の更新は機密性の高いアクションにあたり、対象ユーザーがロール権限を持つ場合や Microsoft Entra ロール割り当て可能なグループのメンバーまたは所有者である場合には、操作者により強いロール権限が必要となります。詳しくは以下公開情報をご参照ください。<br><a href="https://learn.microsoft.com/ja-jp/graph/api/resources/users?view=graph-rest-1.0#sensitive-actions">Microsoft Graph でのユーザーの操作 - Microsoft Graph v1.0 | Microsoft Learn</a></p><h3 id="操作手順例-1"><a href="#操作手順例-1" class="headerlink" title="操作手順例"></a>操作手順例</h3><p>1. Graph Explorer ( <a href="https://developer.microsoft.com/en-us/graph/graph-explorer">https://developer.microsoft.com/en-us/graph/graph-explorer</a> ) を開きます。<br>2. 右上の人型アイコンをクリックし、サインインします。<br>グローバル管理者などの対象ユーザーのユーザー情報を更新する権限のある管理者かつ、必要なアクセス許可のある（もしくは自身でアクセス許可に同意できる管理者）ユーザーでサインインします。<br>（※予めアクセス許可を付与しておきたい場合にはこちら(<a href="https://jpazureid.github.io/blog/azure-active-directory/microsoft-graph-powershell-grant-permissions/">Microsoft Graph PowerShell アクセス許可の付与 | Japan Azure Identity Support Blog</a>)の記事をご参照ください）<br><img src="/blog/azure-active-directory/how-to-use-graph-explorer/2-1.png"><br>※サインイン時に [要求されているアクセス許可] のポップアップが表示された場合には承諾をクリックします。<br>※[組織の代理として同意する] はオフのままで問題ございません。<br>アイコンとテナント名が自身のものに変更されたことを確認します。<br><img src="/blog/azure-active-directory/how-to-use-graph-explorer/2-2.png"></p><p>3. 以下のクエリを入力します。</p><figure class="highlight plaintext"><table><tr><td class="code"><pre><span class="line">https://graph.microsoft.com/v1.0/users/&lt;対象ユーザーのオブジェクト ID または UPN&gt;</span><br></pre></td></tr></table></figure><p>4. プルダウンから PATCH を選択します。<br><img src="/blog/azure-active-directory/how-to-use-graph-explorer/2-3.png"></p><p>5. Request Body に更新したい内容を JSON 形式で記載します。<br><img src="/blog/azure-active-directory/how-to-use-graph-explorer/2-4.png"></p><p>例: </p><figure class="highlight plaintext"><table><tr><td class="code"><pre><span class="line">&#123;</span><br><span class="line">  &quot;mobilePhone&quot;: &quot;+81 3-9999-9999&quot;,</span><br><span class="line">  &quot;onPremisesExtensionAttributes&quot;: &#123;</span><br><span class="line">   &quot;extensionAttribute1&quot;: &quot;value1&quot;</span><br><span class="line">   &#125;</span><br><span class="line">&#125;</span><br></pre></td></tr></table></figure><p>6. Request Headers に Key として Content-Type 、Value として application&#x2F;json を入力し、[Add] します。<br><img src="/blog/azure-active-directory/how-to-use-graph-explorer/2-5.png"></p><p>7. [Run query] をクリックします。<br>8. 対象ユーザーの属性を変更する Microsoft Entra ロール権限を持つユーザーで操作しているにも関わらず、403 の権限が足りないことを示すエラーとなる場合には、アクセス許可が不足していることが疑われます。<br><img src="/blog/azure-active-directory/how-to-use-graph-explorer/2-6.png"></p><p>9-1. [Modify Permissions] をクリックし、必要なアクセス許可の候補が表示された場合には、必要なアクセス許可（今回の場合は、必要なアクセス許可は User.ReadWrite.All ）の [Consent] をクリックしてアクセス許可を承諾します。<br> ※『 要求されているアクセス許可 』のポップアップが表示された場合には承諾をクリックします。<br> ※『組織の代理として同意する』のチェックボックスがある場合、こちらにチェックを入れる必要はありません。<br><img src="/blog/azure-active-directory/how-to-use-graph-explorer/2-7.png"></p><p>9-2. アクセス許可の承諾については、(ユーザー アイコンのクリック) &gt; [Consent to permissions] から Permissions panel を開き、必要なアクセス許可を検索して付与しても構いません。<br>ユーザーの mobilePhone だけ更新する場合には User-Phone.ReadWrite.All が最小のアクセス許可となりますので、以下では、User-Phone.ReadWrite.All を例に操作した画面をご紹介します。<br><img src="/blog/azure-active-directory/how-to-use-graph-explorer/2-8.png"><br><img src="/blog/azure-active-directory/how-to-use-graph-explorer/2-9.png">  </p><p>10. 再び [Run query] を実行し、クエリの実行に成功するかを確認します。<br>クエリの実行に成功した例:<br><img src="/blog/azure-active-directory/how-to-use-graph-explorer/2-10.png">  </p><h2 id="実行するクエリとアクセス許可について"><a href="#実行するクエリとアクセス許可について" class="headerlink" title="実行するクエリとアクセス許可について"></a>実行するクエリとアクセス許可について</h2><p>どのようなクエリを実行すればよいか、どのようなアクセス許可が必要かについては、まずは対象とするオブジェクトおよび操作の Graph API の公開情報を確認します。<br>Graph API の公開情報の例: <a href="https://learn.microsoft.com/ja-jp/graph/api/user-get?view=graph-rest-1.0&tabs=http">ユーザーを取得する - Microsoft Graph v1.0 | Microsoft Learn</a><br><img src="/blog/azure-active-directory/how-to-use-graph-explorer/3-1.png">  </p><p>必要なアクセス許可は例えば以下のような形で記述があります。<br><img src="/blog/azure-active-directory/how-to-use-graph-explorer/3-2.png">  </p><p>クエリの記述例は以下のような形で例示してあります。<br><img src="/blog/azure-active-directory/how-to-use-graph-explorer/3-3.png"><br><img src="/blog/azure-active-directory/how-to-use-graph-explorer/3-4.png">  </p><p>その他、具体的なクエリ パラメーターの使用方法・フィルターの使い方等については、以下公開情報を参考にしてください。<br><a href="https://learn.microsoft.com/ja-jp/graph/query-parameters?tabs=http">クエリ パラメーターを使用して Microsoft Graph 応答をカスタマイズする - Microsoft Graph | Microsoft Learn</a><br><a href="https://learn.microsoft.com/ja-jp/graph/filter-query-parameter?tabs=http">$filter クエリ パラメーターを使用してオブジェクトのコレクションをフィルター処理する - Microsoft Graph | Microsoft Learn</a><br><a href="https://learn.microsoft.com/ja-jp/graph/search-query-parameter?tabs=http">Microsoft Graph API でクエリ パラメーター$search使用する - Microsoft Graph | Microsoft Learn</a><br><a href="https://learn.microsoft.com/ja-jp/graph/aad-advanced-queries?tabs=http">Microsoft Entra ID オブジェクトの高度なクエリ機能 - Microsoft Graph | Microsoft Learn</a></p><h2 id="自身が外部ゲストとして登録されているテナントにサインインする方法"><a href="#自身が外部ゲストとして登録されているテナントにサインインする方法" class="headerlink" title="自身が外部ゲストとして登録されているテナントにサインインする方法"></a>自身が外部ゲストとして登録されているテナントにサインインする方法</h2><p>自身が外部ゲストとして登録されているテナントにサインインする必要がある場合には Graph Explorer を開く際に以下のようにテナントのドメインもしくはテナント ID を指定します。</p><figure class="highlight plaintext"><table><tr><td class="code"><pre><span class="line">https://developer.microsoft.com/en-us/graph/graph-explorer?tenant=&lt;サインインしたいテナントのテナント ID もしくは ドメイン名&gt;</span><br></pre></td></tr></table></figure><figure class="highlight plaintext"><table><tr><td class="code"><pre><span class="line">例: https://developer.microsoft.com/en-us/graph/graph-explorer?tenant=contoso.com</span><br></pre></td></tr></table></figure><p>ユーザー アイコンをクリックして、ゲスト ユーザーにてサインインします。<br>サインインしたいテナントと異なるテナントが表示されている場合、サインインしなおして、以下のようにサインインしたいテナントが表示されることを確認します。<br><img src="/blog/azure-active-directory/how-to-use-graph-explorer/3-5.png">  </p>]]>
    </content>
    <id>https://jpazureid.github.io/blog/azure-active-directory/how-to-use-graph-explorer/</id>
    <link href="https://jpazureid.github.io/blog/azure-active-directory/how-to-use-graph-explorer/"/>
    <published>2026-06-30T00:00:00.000Z</published>
    <summary>
      <![CDATA[<p>こんにちは、 Azure Identity サポート チームの三輪です。</p>
<p>Entra ID テナントやユーザーなどのオブジェクトを管理する方法には、各管理センター (Microsoft Entra 管理センターなど) の画面上で操作する以外にも、Microso]]>
    </summary>
    <title>Graph Explorer の使用法</title>
    <updated>2026-08-12T00:07:04.705Z</updated>
  </entry>
  <entry>
    <author>
      <name>Azure Identity Support Japan</name>
    </author>
    <category term="Conditional Access" scheme="https://jpazureid.github.io/blog/tags/Conditional-Access/"/>
    <category term="Microsoft Entra ID" scheme="https://jpazureid.github.io/blog/tags/Microsoft-Entra-ID/"/>
    <category term="Compliant" scheme="https://jpazureid.github.io/blog/tags/Compliant/"/>
    <content>
      <![CDATA[<div class="alert is-info"><p class="alert-title">Note</p><p>本記事は 2021 年 2 月に公開した内容を、2026 年 6 月時点の最新情報に基づきリニューアルしたものです。リニューアル前の記事は <a href="https://jpazureid.github.io/blog/azure-active-directory/conditional-access-compliant-ios-android/">条件付きアクセスで 「準拠済み」 でブロックされる場合の対処法 (iOS &#x2F; Android 編)</a> をご参照ください。</p></div><p>こんにちは、Azure &amp; Identity サポート チームの上出です。</p><p>条件付きアクセスで「デバイスは準拠しているとしてマーク済みである必要があります」の許可を設定しているにもかかわらず、Intune に MDM 登録済み、且つコンプライアンス準拠済みの端末からのアクセスがブロックされてしまうことがあります。今回は、iOS &#x2F; Android でこの事象が発生した場合の原因と対処方法をご紹介します。</p><p>&lt;エラー コード例&gt;</p><blockquote><p>“errorCode”: 53000, “failureReason”: “Device is not in required device state: {state}. Conditional Access policy requires a compliant device, and the device is not compliant. The user must enroll their device with an approved MDM provider like Intune.”, “additionalDetails”: “Your administrator might have configured a conditional access policy that allows access to your organization’s resources only from compliant devices. To be compliant, your device must be either joined to your on-premises Active Directory or joined to your Azure Active Directory. More details available at <a href="https://support.microsoft.com/account-billing/troubleshooting-compliance-error-messages-for-a-work-or-school-account-479a9c42-d9d1-4e44-9e90-24bbad96c251">https://support.microsoft.com/account-billing/troubleshooting-compliance-error-messages-for-a-work-or-school-account-479a9c42-d9d1-4e44-9e90-24bbad96c251</a></p></blockquote><blockquote><p>“errorCode”: 530003, “failureReason”: “Your device is required to be managed to access this resource.”<br>“additionalDetails”: “The requested resource can only be accessed using a compliant device. The user is either using a device not managed by a Mobile-Device-Management (MDM) agent like Intune, or it’s using an application that doesn’t support device authentication. The user could enroll their devices with an approved MDM provider, or use a different app to sign in, or find the app vendor and ask them to update their app. More details available at <a href="https://support.microsoft.com/account-billing/troubleshooting-compliance-error-messages-for-a-work-or-school-account-479a9c42-d9d1-4e44-9e90-24bbad96c251">https://support.microsoft.com/account-billing/troubleshooting-compliance-error-messages-for-a-work-or-school-account-479a9c42-d9d1-4e44-9e90-24bbad96c251</a></p></blockquote><br><h2 id=""><a href="#" class="headerlink" title="&lt;なぜブロックされるのか？&gt;"></a>&lt;なぜブロックされるのか？&gt;</h2><p>条件付きアクセスの「準拠済み」の設定でブロックされる原因は、大きく以下の 2 つに分けられます。</p><ol><li><strong>そもそも端末が準拠済みになっていない</strong></li><li><strong>端末は準拠済みだが、サインイン時にデバイス情報を Microsoft Entra ID に提示できていない</strong></li></ol><p>1 のケースはアクセスがブロックされるのが期待される動作ですが、2 のケースについてのお問い合わせも多くいただいております。以下では、まずユーザー認証時にデバイス情報の提示がなぜ必要なのかを説明します。</p><p>条件付きアクセスの「準拠済み」の設定は、デバイス ベースのアクセス制御となるため、”どの端末からのアクセスか？” を Microsoft Entra ID が判断する必要があります。この判断のために、ご利用のデバイスは Microsoft Entra ID に対して “デバイス情報” を提示する必要があります。</p><p>ご利用の端末がデバイス情報を Microsoft Entra ID に提示できない場合、Microsoft Entra ID は対応するデバイス レコードを見つけることができず、”どの端末からのアクセスか？” を判断することができません。つまり「準拠済み」であるかどうかも判断できず、アクセス制御設定に沿ってブロックされます。<br>ブロックされたアクセスをサインイン ログで確認すると、以下のようにデバイス ID の情報が表示されていないことがわかります。</p><p><img src="/blog/azure-active-directory/conditional-access-compliant-ios-android-2026/deviceid-not-displayed.png"></p><br><p>このように、端末が準拠済みであっても、デバイス情報を提示できていなければブロックされてしまいます。そのため、切り分けの際は、まず “デバイス情報を提示できているかどうか” に着目すると整理しやすくなります。</p><ul><li>デバイス情報は提示できているのにブロックされる場合は、そもそも端末が準拠済みになっていない可能性があるため、「A. 準拠済み？」を確認する必要があります。</li><li>デバイス情報を提示できていない場合は、なぜ提示できていないのかを切り分けるため、「B」以降を確認することが有効です。</li></ul><br><h2 id="-1"><a href="#-1" class="headerlink" title="&lt;対処方法&gt;"></a>&lt;対処方法&gt;</h2><p>前述の切り分けの考え方に沿って、以下の観点で確認を行います。まず確認ポイント A で端末が準拠済みかどうかを確認し (原因 1)、準拠済みの場合はデバイス情報を提示できない原因 (原因 2) として B 以降を確認していきます。<br>それぞれの項目ごとに解説します。</p><table><thead><tr><th>No.</th><th>確認ポイント</th></tr></thead><tbody><tr><td>A</td><td>準拠済み？</td></tr><tr><td>B</td><td>サポートされたブラウザーを使用している？</td></tr><tr><td>C</td><td>Microsoft Edge を使用している場合、ブラウザーにサインインできている？</td></tr><tr><td>D</td><td>証明書を提示できていない</td></tr><tr><td>E</td><td>Microsoft Authenticator をインストールしていない</td></tr><tr><td>F</td><td>アプリの実装によりデバイス情報を提示できないこともある</td></tr><tr><td>G</td><td>その他</td></tr></tbody></table><br><h2 id="A-準拠済み？"><a href="#A-準拠済み？" class="headerlink" title="A. 準拠済み？"></a>A. 準拠済み？</h2><p>利用している端末が準拠済みとなっているかを確認します。<br>Microsoft Entra 管理センターのデバイス一覧で、対象の端末の「準拠している」の列が「はい」にセットされていれば OK です。</p><p><img src="/blog/azure-active-directory/conditional-access-compliant-ios-android-2026/compliant-set.png"></p><p>対象の端末が準拠していない場合は、Microsoft Intune の観点で、なぜ準拠済みとならないのかを調査する必要があります。</p><br><h2 id="B-サポートされたブラウザーを使用している？"><a href="#B-サポートされたブラウザーを使用している？" class="headerlink" title="B. サポートされたブラウザーを使用している？"></a>B. サポートされたブラウザーを使用している？</h2><p>OS によってサポートされるブラウザーは異なるため、以下の公開情報を元にご利用のブラウザーがサポートされているかご確認をお願いします。</p><p><a href="https://learn.microsoft.com/ja-jp/entra/identity/conditional-access/concept-conditional-access-conditions#supported-browsers">条件付きアクセス: 条件 - サポートされているブラウザー | Microsoft Learn</a></p><br><h2 id="C-Microsoft-Edge-を使用している場合、ブラウザーにサインインしている？"><a href="#C-Microsoft-Edge-を使用している場合、ブラウザーにサインインしている？" class="headerlink" title="C. Microsoft Edge を使用している場合、ブラウザーにサインインしている？"></a>C. Microsoft Edge を使用している場合、ブラウザーにサインインしている？</h2><p>Microsoft Edge を利用してデバイス情報を提示するためには、ブラウザーにサインインしている必要があります。</p><p><a href="https://learn.microsoft.com/ja-jp/deployedge/ms-edge-security-conditional-access">Microsoft Edge と条件付きアクセス | Microsoft Learn</a></p><blockquote><p>Microsoft Entra ID (旧称 Azure Active Directory) 資格情報を使用して Edge プロファイルにサインインすると、条件付きアクセスを使用して保護されたエンタープライズ クラウド リソースへのシームレスなアクセスが Microsoft Edge によって許可されます。</p></blockquote><br><h2 id="D-証明書を提示できていない"><a href="#D-証明書を提示できていない" class="headerlink" title="D. 証明書を提示できていない"></a>D. 証明書を提示できていない</h2><p>iOS &#x2F; Android がデバイス情報を提示する仕組みは、ブラウザー アクセスの場合と、クライアント アプリの場合で異なります。</p><p>ブラウザー アクセスの場合は、iOS も Android も Microsoft Entra ID に証明書を提示することでデバイス情報を渡します。ただし、証明書のインストールや格納の仕組みは iOS と Android で異なるため、以下では OS ごとに分けて説明します。</p><h3 id="Android-の場合"><a href="#Android-の場合" class="headerlink" title="Android の場合"></a>Android の場合</h3><p>Android の場合、以下のように端末内に保持している証明書一覧が表示されて、どの証明書を使用するのか促されます。(既に使用する証明書が決まっていると判断されれば促されない場合もあります)<br>ここで適切な証明書を選択すれば、証明書の中に保存されているデバイス情報を提示し、Microsoft Entra ID でデバイス ベースの条件付きアクセスの制御が可能となります。</p><p><img src="/blog/azure-active-directory/conditional-access-compliant-ios-android-2026/device-cert.png"></p><p>なお、ここで使用する証明書 (上記画面の証明書) は、Intune ポータル サイトからインストール可能です。以下の公開情報をご参照の上、記載された画面と同様のメッセージが表示されている状況であれば、本公開情報の「ブラウザー アクセスを有効にする」手順をお試しください。</p><p><a href="https://learn.microsoft.com/ja-jp/intune/user-help/compliance/update-settings-android#missing-certificate">Android のデバイス設定の要件 - 証明書がありません | Microsoft Learn</a></p><h3 id="iOS-の場合"><a href="#iOS-の場合" class="headerlink" title="iOS の場合"></a>iOS の場合</h3><p>iOS の場合、Intune によるプロファイル設定が行われる際に証明書もあわせてインストールされることが想定されます。</p><div class="alert is-info"><p class="alert-title">Note</p><p>iOS (Apple デバイス) では、Entra ID へのデバイス登録に紐づくデバイス ID の格納先がキーチェーンから Secure Enclave に変更されています。この変更により、非 MSAL 対応アプリやブラウザー (Safari など) でデバイス情報を提示できなくなる場合があります。詳細および対処方法については、以下のブログ記事をご参照ください。</p><p><a href="https://jpazureid.github.io/blog/azure-active-directory/Keychain-to-SecureEnclave-for-Apple-device/">Apple デバイスでキーチェーンから Secure Enclave 利用へ</a></p></div><p>一方で、モバイル アプリ (クライアント アプリ) の場合は、Microsoft Authenticator を使用して PRT を Microsoft Entra ID に提示する必要があります。詳細は 「E. Microsoft Authenticator をインストールしていない」で説明します。</p><br><h2 id="E-Microsoft-Authenticator-をインストールしていない"><a href="#E-Microsoft-Authenticator-をインストールしていない" class="headerlink" title="E. Microsoft Authenticator をインストールしていない"></a>E. Microsoft Authenticator をインストールしていない</h2><p>iOS &#x2F; Android を使用してモバイル アプリ (ネイティブ アプリ) にアクセスする際は、基本的に Microsoft Authenticator を使用して PRT を Microsoft Entra ID に提示する必要があります。アプリの実装によっては、ブラウザーを経由してデバイス情報を提示する場合もあるため、その場合は Microsoft Authenticator を用いずにデバイス情報を提示可能です。</p><p>以下は iPad を使用した動作サンプルとなりますが、こちらを見ていただくと Microsoft Authenticator を使用してデバイス情報を提示するシナリオのイメージが湧くかと思います。</p><p>Microsoft Teams のモバイル アプリにサインインするために資格情報を入力すると、パスワード入力画面に遷移しています。画面左上に Teams の表示があることから、これは Microsoft Teams 自体が表示している画面ではなく、別のアプリが呼び出した画面であることがわかります。(Microsoft Teams 自体の画面であれば、左上に呼び出し元の Teams へ戻る表示は出ません)</p><p><img src="/blog/azure-active-directory/conditional-access-compliant-ios-android-2026/authenticator-screen1.png"></p><p>実際に、起動アプリを確認すると Microsoft Authenticator がパスワード入力画面を呼び出していることが確認できます。</p><p><img src="/blog/azure-active-directory/conditional-access-compliant-ios-android-2026/authenticator-screen2.png"></p><p>このことから、Microsoft Teams から Microsoft Authenticator にリダイレクトされ、この動作でパスワード入力、および PRT を Microsoft Entra ID に渡していることがわかります。</p><p>※ なお、Android の場合は、このような画面遷移が行われていることを明示的に確認できませんが、同様の動作が行われているとお考えください。</p><br><h2 id="F-アプリの実装によりデバイス情報を提示できないこともある"><a href="#F-アプリの実装によりデバイス情報を提示できないこともある" class="headerlink" title="F. アプリの実装によりデバイス情報を提示できないこともある"></a>F. アプリの実装によりデバイス情報を提示できないこともある</h2><p>3rd Party 製のアプリケーションの場合、デバイス情報を直接 Microsoft Entra ID に提示できるような実装か、Microsoft Authenticator 経由で提示できるように実装されている必要があります。具体的には、アプリケーションが Microsoft Authentication Library (MSAL) を使用して開発されていれば、MSAL にブローカー (Microsoft Authenticator) 連携の仕組みが組み込まれているため、自動的に Microsoft Authenticator 経由でデバイス情報を提示できます。3rd Party 製のアプリケーションが MSAL を使用しているかどうかは、アプリケーション ベンダーに直接ご確認いただく必要があります。</p><p>基本的に、Microsoft 製のアプリケーションは MSAL を使用しており、Microsoft Authenticator をブローカーとしてデバイス情報を提示するとお考え下さい。(Outlook などは Microsoft Authenticator を使用しなくてもデバイス情報を提示できるシナリオがあることを確認していますが、基本的には Microsoft Authenticator が使用されるとお考えください)</p><p>なお、モバイル デバイスに Microsoft Authenticator をインストールするだけでは不十分で、アプリケーション側が MSAL を使用し、Microsoft Authenticator をブローカーとして利用するように実装されている必要があります。上記の動作については、以下のアプリケーション開発者用の公開情報に記載がありますのでご参照ください。</p><p><a href="https://learn.microsoft.com/ja-jp/entra/identity-platform/scenario-mobile-app-configuration#configure-the-application-to-use-the-broker">ブローカーを使用するようにアプリケーションを構成する | Microsoft Learn</a></p><div class="alert is-info"><p class="alert-title">Note</p><p>iOS &#x2F; iPadOS (Apple デバイス) では、MDM 経由で <a href="https://learn.microsoft.com/ja-jp/entra/identity-platform/apple-sso-plugin">Microsoft Enterprise SSO プラグイン</a> を有効化することで、MSAL に対応していないアプリケーションでもデバイス情報の提示が可能になります。Enterprise SSO プラグインは Microsoft Authenticator アプリに組み込まれており、MDM で構成することで非 MSAL アプリにも SSO とデバイスベースの条件付きアクセスを拡張できます。構成方法の詳細は <a href="https://learn.microsoft.com/ja-jp/mem/intune/configuration/use-enterprise-sso-plug-in-ios-ipados-with-intune">iOS&#x2F;iPadOS デバイスで Microsoft Enterprise SSO プラグインを使用する | Microsoft Learn</a> をご参照ください。</p></div><br><h2 id="G-その他"><a href="#G-その他" class="headerlink" title="G. その他"></a>G. その他</h2><p>その他サポート チームで確認できている事象や仕様についてです。</p><p>・ 3rd Party 製品によってデバイス情報が提示できない</p><p>クライアント端末から Microsoft Entra ID にデバイス情報を提示する経路上に、プロキシなど一部 3rd Party 製品の動作 (仕様) によって、デバイス情報が提示できない場合があることを確認しております。<br>もし切り分けの結果、ご利用の 3rd Party 製品を経由する場合のみ事象が発生するということであれば、該当のベンダーに確認のお問い合わせをいただければと思います。</p><br><h2 id="関連ブログ"><a href="#関連ブログ" class="headerlink" title="関連ブログ"></a>関連ブログ</h2><p><a href="https://jpazureid.github.io/blog/azure-active-directory/conditional-access-compliant-windows">Japan Azure Identity Support Blog: 条件付きアクセスで 「準拠済み」 や 「Hybrid Azure AD 参加が必要」 でブロックされる場合の対処法 (Windows 編)</a><br><a href="https://jpazureid.github.io/blog/azure-active-directory/Keychain-to-SecureEnclave-for-Apple-device/">Japan Azure Identity Support Blog: Apple デバイスでキーチェーンから Secure Enclave 利用へ</a></p><p>上記内容が少しでも参考となれば幸いです。製品動作に関する正式な見解や回答については、お客様環境などを十分に把握したうえでサポート部門より提供させていただきますので、ぜひサポートサービスまでお問い合わせください。</p>]]>
    </content>
    <id>https://jpazureid.github.io/blog/azure-active-directory/conditional-access-compliant-ios-android-2026/</id>
    <link href="https://jpazureid.github.io/blog/azure-active-directory/conditional-access-compliant-ios-android-2026/"/>
    <published>2026-06-25T15:00:00.000Z</published>
    <summary>
      <![CDATA[<div class="alert is-info"><p class="alert-title">Note</p><p>本記事は 2021 年 2 月に公開した内容を、2026 年 6 月時点の最新情報に基づきリニューアルしたものです。リニューアル前の記事は <a href="]]>
    </summary>
    <title>[2026 年度版] 条件付きアクセスで 「準拠済み」 でブロックされる場合の対処法 (iOS / Android 編)</title>
    <updated>2026-08-12T00:07:04.500Z</updated>
  </entry>
  <entry>
    <author>
      <name>Azure Identity Support Japan</name>
    </author>
    <category term="Microsoft Entra ID" scheme="https://jpazureid.github.io/blog/tags/Microsoft-Entra-ID/"/>
    <category term="Passkey" scheme="https://jpazureid.github.io/blog/tags/Passkey/"/>
    <category term="Microsoft Security Blog" scheme="https://jpazureid.github.io/blog/tags/Microsoft-Security-Blog/"/>
    <category term="Passwordless" scheme="https://jpazureid.github.io/blog/tags/Passwordless/"/>
    <content>
      <![CDATA[<p>こんにちは、Azure &amp; Identity サポート チームの長谷川です。<br>本記事は、2026 年 5 月 7 日に米国の Microsoft Security Blog で公開された <a href="https://www.microsoft.com/en-us/security/blog/2026/05/07/world-passkey-day-advancing-passwordless-authentication/">World Passkey Day: Advancing passwordless authentication</a> を意訳したものになります。ご不明点はサポート チームまでお問い合わせください。</p><span id="more"></span><hr><h2 id="はじめに"><a href="#はじめに" class="headerlink" title="はじめに"></a>はじめに</h2><p>World Passkey Day は、共通の目標に向けた進捗を振り返る機会です。その目標とは、パスキーの導入を加速させることで、パスワードやその他のフィッシング可能な認証手段への依存を減らすことです。サイバー攻撃がより自動化され、AI を活用するようになる中で、各アカウントの安全性は最も弱い認証情報に依存します。真の進展を実現するには、単により強力なサインイン手段を追加するだけでは不十分であり、フィッシング可能な認証情報を排除し、回復フローのような一般的な攻撃経路を強化する必要があります。Microsoft は FIDO アライアンスと連携し、継続的な標準化活動やワーキンググループへの積極的な参加、その他の取り組みを通じて、<a href="https://www.microsoft.com/ja-jp/security/business/security-101/what-is-fido2?msockid=274c96843e2863a22cb381cf3ff662e6">パスキーの普及とパスワードレスの未来の実現を推進していきます。</a></p><p><a href="https://www.microsoft.com/ja-jp/security/business/microsoft-entra">Microsoft Entra が提供する ID およびアクセスのためのソリューションを確認する</a></p><p>パスワードは依然として大きなリスク要因であり、管理が難しく、盗まれやすいという問題があります。さらに、認証強度の低い多要素認証と同様に、パスワードはフィッシング攻撃にも非常に脆弱です。AI を活用した攻撃活動では、クリック率が最大で 54% ※1 に達することもあります。これに対応するため、Microsoft はエコシステム全体でパスキーの導入を拡大しています。従来の認証方式への依存を減らすとともに、アカウント回復機能を強化することで、それがサイバー攻撃者にとっての抜け道 (バックドア) とならないようにしています。</p><blockquote><p>パスキーは、脆弱なシークレット (秘密情報) や識別され得る個人情報の代わりに、ユーザーのデバイス上に安全に保存された秘密鍵 (プライベート キー) を使用します。パスキーは、その鍵が作成された特定のウェブサイトやアプリでのみ機能し、かつユーザー自身が生体認証や PIN (暗証番号) を使ってロックを解除した場合にのみ使用可能です。そのため、パスキーを利用するユーザーは、悪意のある偽サイトに騙されてサインインしてしまうことがなく、またユーザー本人がその場にいて同意しない限り、パスキーは使用されません。これらの特性により、パスキーは「フィッシング耐性 (phishing-resistant)」を備えた認証方式とされています。<br><a href="https://www.hmcplus.de/wp-content/uploads/Microsoft-Digital-Defense-Report-2024-klein.pdf">Microsoft Digital Defense Report</a> より抜粋</p></blockquote><h2 id="パスキーの導入は業界全体で拡大し続けている"><a href="#パスキーの導入は業界全体で拡大し続けている" class="headerlink" title="パスキーの導入は業界全体で拡大し続けている"></a>パスキーの導入は業界全体で拡大し続けている</h2><p>パスキーの導入は急速に進んでいます。FIDO アライアンスの推定によると、世界中で既に 50 億のパスキーが利用されています。※2 また、OneDrive、Xbox、Copilot などの Microsoft のコンシューマー向けサービス全体で、毎日数億人のユーザーがパスキーを使用してサインインしています。<br>パスワードではなくパスキーを標準的な認証方法として選ぶ理由は数多くあります。パスキーによるサインインの成功率はパスワードよりも大幅に高く、認証情報に基づく攻撃のリスクも大幅に低くなります。※3 組織も個人ユーザーも、パスキーが提供するよりシンプルで安全なサインイン体験を支持しています。※4<br>Microsoft 社内では認証強度の低い認証方法の利用を廃止しました。そして、フィッシング耐性のある認証方法を導入し、社内環境のユーザーとデバイスの 99.6% をカバーしています。※5 その結果、サインインの体験は大幅にシンプルになりました。コードを入力する必要も、追加のプロンプトを管理する必要もなく、誰にとっても直感的で分かりやすい操作で利用できるようになっています。</p><h2 id="サインインおよびアカウント回復に関する製品アップデート"><a href="#サインインおよびアカウント回復に関する製品アップデート" class="headerlink" title="サインインおよびアカウント回復に関する製品アップデート"></a>サインインおよびアカウント回復に関する製品アップデート</h2><p>Microsoft では、コンシューマー向けアカウントから <a href="https://www.microsoft.com/ja-jp/security/business/microsoft-entra">Microsoft Entra</a> によるエンタープライズアクセスまで、また <a href="https://www.microsoft.com/ja-jp/windows/tips/windows-hello">Windows Hello</a> のようなデバイス ベースの認証から <a href="https://www.microsoft.com/ja-jp/edge/features/passkeys?msockid=252e42d5df4363d20f115453de43621a&form=MT0160">Microsoft パスワード マネージャー</a> に至るまで、ID 利用体験のあらゆる層においてパスキーのサポートを推し進めてきました。この取り組みにより、ユーザーはサインインするあらゆる場所でパスキーを作成・利用でき、デバイス、アプリ、環境を問わず、一貫したフィッシング耐性のある認証体験を得られるようになります。</p><p>パスキーをより利用しやすくするため、次の様に利用可能な場所や利用方法を拡大しています：</p><ul><li><p>Microsoft Entra ID における <a href="https://learn.microsoft.com/ja-jp/entra/identity/authentication/how-to-authentication-passkeys-fido2">同期されたパスキー</a> と <a href="https://learn.microsoft.com/ja-jp/entra/identity/authentication/how-to-authentication-passkeys-fido2">パスキー プロファイル</a> により、多様な環境全体でパスワードレス サインインを容易に展開・拡張できるようになります。当社は、より大規模で複雑なポリシーへの対応など、クラウドでのパスキー管理の柔軟性を高めるとともに、テナントを統合型パスキー プロファイル モデルへと移行させています。</p></li><li><p><a href="https://learn.microsoft.com/ja-jp/entra/identity/authentication/how-to-authentication-entra-passkeys-on-windows">Windows 上の Entra パスキー</a> 機能により、ユーザーは Windows Hello を使用して、個人用または未管理の Windows デバイス上でデバイスに紐付いたパスキーを直接作成・利用できるようになります。本機能は 2026 年 5 月下旬に一般提供が開始される予定です。</p></li><li><p><a href="https://www.microsoft.com/ja-jp/security/business/identity-access/microsoft-entra-external-id">Microsoft Entra 外部 ID</a> 向けのパスキー機能も 2026 年 5 月下旬に一般提供が開始されるため、顧客向けアプリケーションにおいて、よりシームレスで一般消費者向けサービスにふさわしいサインイン体験を提供できるようになります。</p></li><li><p><a href="https://www.microsoft.com/ja-jp/security/business/identity-access/microsoft-entra-id">Microsoft Entra ID</a> のパスキー優先認証 (プレビュー) では、登録済みの認証方法を検出し、最も強力な方法を優先的に提示します。パスキーが登録されていれば、ユーザーは即座にそのパスキーによる認証を利用できます。</p></li><li><p>コンシューマー向け機能としては、Microsoft パスワード マネージャーを利用することで、Microsoft アカウント (個人アカウント) でサインインしたデバイス間で <a href="https://blogs.windows.com/msedgedev/2026/04/22/engineering-secure-passkey-sync-in-microsoft-password-manager/">パスキーを保存・同期</a> できるようになりました。Microsoft Edge を通じた iOS および Android への対応もまもなく開始される予定です (Entra アカウントはコンシューマー向け機能ではないためこの機能の対象外です)。</p></li></ul><p>アカウント回復は、アイデンティティ システムの整合性を維持するうえでも非常に重要な役割を担っています。従来、アカウント回復プロセスはサイバー攻撃者に狙われやすく、例えば正規のユーザーになりすまして回復プロセスを乗っ取り新しい資格情報の発行を要求するといった手口が見られてきました。</p><p>一般提供 (GA) となっている <a href="https://learn.microsoft.com/ja-jp/entra/identity/authentication/concept-account-recovery-overview">Microsoft Entra ID のアカウント回復</a> は、強固な本人確認プロセスを通じてユーザーがアカウントへのアクセスを回復できるようにすることで、回復フローのセキュリティを強化します。<br>ユーザーは、すべての認証方法を失った場合でも、政府発行の身分証明書や顔認証 (バイオメトリクス) を使用してアクセスを回復することができます。また、一般提供にあたり、既存の Au10tix、IDEMIA、TrueCredential に加え、新たに 1Kosmos と CLEAR1 の 2 社が参加し、当社の <a href="https://learn.microsoft.com/ja-jp/entra/verified-id/idv-partners">本人確認 (identity verification) のエコシステム</a> が拡張されています。</p><h2 id="ユーザー-アカウントからフィッシング可能な資格情報を削除する"><a href="#ユーザー-アカウントからフィッシング可能な資格情報を削除する" class="headerlink" title="ユーザー アカウントからフィッシング可能な資格情報を削除する"></a>ユーザー アカウントからフィッシング可能な資格情報を削除する</h2><p>認証の強化は重要ですが、リスクを低減するためには、フィッシング可能な資格情報そのものを完全に排除することが必要です。Microsoft は従来のレガシーな認証方式の段階的な廃止を進め、ユーザーをフィッシング耐性のある認証方式へ移行させています。セキュリティの質問 (秘密の質問) は推測やソーシャル エンジニア リング攻撃に脆弱であることから、2027 年 1 月から Microsoft Entra ID において <a href="https://learn.microsoft.com/ja-jp/entra/identity/authentication/concept-authentication-security-questions">セキュリティの質問 (秘密の質問) はパスワード リセットのオプションから削除されます</a>。<br>その理由は単純明快です。優れた手法を強化しつつ脆弱な手法を排除することで、攻撃対象領域が縮小するからです。これは、AI エージェントがユーザーに代わって操作を行うようになっている現在、ますます緊急性を増しています。もし ID が侵害された場合、サイバー攻撃者はそれらのエージェントを利用してシステムへアクセスし、ワークフローを実行し、既存の権限の範囲内で活動することが可能になります。そのため、組織はこのリスクに迅速に対処する必要があります。</p><h2 id="より安全で使いやすい未来にむけて"><a href="#より安全で使いやすい未来にむけて" class="headerlink" title="より安全で使いやすい未来にむけて"></a>より安全で使いやすい未来にむけて</h2><p>昨年、Microsoft は数十の組織とともに「パスキーの誓約 (Passkey Pledge)」に参加し、フィッシング耐性のある認証の導入を加速し、パスワードに依存しない世界へ移行することを約束しました。それ以来、着実な進展が見られており、数億規模のコンシューマー アカウントがより強固に保護されるようになったほか、Microsoft 自身を含む組織でも大規模な展開が進んでいます。<br>これまで長期的な変化と思われていたものが、ようやく現実的な勢いを伴って進み始めています。認証はよりシンプルで安全、かつパスワードレスなものへと変わりつつあります。<br>サイバー攻撃者がフォールバック手法やアカウント復旧プロセスを悪用して認証を回避しようとする手口や、その対策について詳しく知りたい場合は、<a href="https://techcommunity.microsoft.com/blog/microsoft-entra-blog/passkeys-aren%E2%80%99t-the-finish-line-eliminating-fallbacks-and-fixing-recovery/3627345">こちらの関連記事をご覧ください</a>。</p><h2 id="さあ、はじめよう"><a href="#さあ、はじめよう" class="headerlink" title="さあ、はじめよう"></a>さあ、はじめよう</h2><p>組織がアイデンティティ セキュリティ体制を強化するには、ユーザー向けにパスキーを有効化し、サインイン時だけでなく回復（リカバリー）シナリオにもポリシー保護を拡張することが重要です。<br>Microsoft Entra ID におけるフィッシング耐性のあるパスワードレス認証の導入は、フィッシング耐性のあるパスワードレス認証の前提条件を計画することから始めましょう。<br>また、個人はよりセキュリティと利便性を高めるために、個人アカウントの <a href="https://support.microsoft.com/ja-jp/account-billing/create-and-save-a-passkey-e92cd3e0-11fa-4630-a5ea-3ccc0396b3d9">パスキーを作成・使用</a>できます。<br><a href="https://www.microsoft.com/ja-jp/security/business/microsoft-entra">Microsoft Entra の詳細はこちら</a></p><p>Microsoft セキュリティ ソリューションの詳細については、当社の <a href="https://www.microsoft.com/ja-jp/security">Web サイト</a> をご覧ください。<br>セキュリティに関する専門的な解説を継続的に入手するために、<a href="https://www.microsoft.com/en-us/security/blog/">Security ブログ</a> をブックマークすることをおすすめします。<br>また、サイバー セキュリティに関する最新情報やアップデートについては、LinkedIn (<a href="https://www.linkedin.com/showcase/microsoft-security/">Microsoft Security</a>)および X (<a href="https://x.com/MSFTSecurity">@MSFTSecurity</a>) でもご確認いただけます。</p><hr><p>※1 <a href="https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/microsoft/msc/documents/presentations/CSR/Microsoft-Digital-Defense-Report-2025.pdf#page=1">Microsoft Digital Defense Report 2025</a>.<br>※2 <a href="https://fidoalliance.org/fido-alliance-reports-accelerating-global-passkey-adoption-on-world-passkey-day-2026/">FIDO Alliance reports mainstream global usage on World Passkey Day</a>. FIDO Alliance, 2026.<br>※3 <a href="https://techcommunity.microsoft.com/blog/microsoft-entra-blog/synced-passkeys-and-high-assurance-account-recovery/3627343">Synced passkeys and high assurance account recovery</a>, Microsoft Entra blog. December 16, 2025.<br>※4 <a href="https://fidoalliance.org/fido-alliance-champions-widespread-passkey-adoption-and-a-passwordless-future-on-world-passkey-day-2025/?utm_source=chatgpt.com">FIDO Alliance Champions Widespread Passkey Adoption and a Passwordless Future on World Passkey Day 2025</a>, FIDO News Center. May 1, 2025.<br>※5 <a href="https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/microsoft/bade/documents/products-and-services/en-us/security/sfi-nov-2025-progress-report.pdf">Microsoft Security and Future Initiative (SFI) Progress Report—November 2025</a>.</p>]]>
    </content>
    <id>https://jpazureid.github.io/blog/azure-active-directory/world-passkey-day-advancing-passwordless-authentication/</id>
    <link href="https://jpazureid.github.io/blog/azure-active-directory/world-passkey-day-advancing-passwordless-authentication/"/>
    <published>2026-06-25T15:00:00.000Z</published>
    <summary>
      <![CDATA[<p>こんにちは、Azure &amp; Identity サポート チームの長谷川です。<br>本記事は、2026 年 5 月 7 日に米国の Microsoft Security Blog で公開された <a href="https://www.microsoft.com/en-us/security/blog/2026/05/07/world-passkey-day-advancing-passwordless-authentication/">World Passkey Day: Advancing passwordless authentication</a> を意訳したものになります。ご不明点はサポート チームまでお問い合わせください。</p>]]>
    </summary>
    <title>パスキーを利用したパスワードレスの導入を検討しよう</title>
    <updated>2026-08-12T00:07:05.386Z</updated>
  </entry>
  <entry>
    <author>
      <name>Azure Identity Support Japan</name>
    </author>
    <category term="Microsoft Entra" scheme="https://jpazureid.github.io/blog/tags/Microsoft-Entra/"/>
    <category term="Starter series" scheme="https://jpazureid.github.io/blog/tags/Starter-series/"/>
    <category term="GSA" scheme="https://jpazureid.github.io/blog/tags/GSA/"/>
    <category term="Private Access" scheme="https://jpazureid.github.io/blog/tags/Private-Access/"/>
    <content>
      <![CDATA[<p>こんにちは、Azure Identity サポート チームの 夏木 です。Microsoft Entra サポート チームより、最近 Entra の利用を始めたお客様を対象に、初学者向けのブログ シリーズを作成しております。本記事はその Entra ID 初学者向けシリーズの「Microsoft Entra Private Access 入門」です。</p><h2 id="本記事の対象者"><a href="#本記事の対象者" class="headerlink" title="本記事の対象者"></a>本記事の対象者</h2><ul><li>Microsoft Entra Private Access の基本を理解したい方</li><li>Microsoft Entra Private Access をこれから導入する方</li><li>ゼロ トラストに関心がある情報システム部門やソリューション アーキテクトの方</li></ul><h2 id="記事概要"><a href="#記事概要" class="headerlink" title="記事概要"></a>記事概要</h2><p>本記事では、Microsoft Entra Private Access を中心に、基本的な仕組みから構成方法、よくあるお問い合わせの事例を通じて実践的な知識をお伝えします。IT 管理者の方々にとって日々の運用に役立ちましたら嬉しいです！</p><hr><h2 id="Global-Secure-Access-の全体像"><a href="#Global-Secure-Access-の全体像" class="headerlink" title="Global Secure Access の全体像"></a>Global Secure Access の全体像</h2><h3 id="Global-Secure-Access-とは"><a href="#Global-Secure-Access-とは" class="headerlink" title="Global Secure Access とは"></a>Global Secure Access とは</h3><p>従来のネットワーク セキュリティは、オフィスの境界にファイアウォールを設置し、社内ネットワークを信頼するという「境界型セキュリティ」の考え方に基づいていました。一方で、「最小特権の原則」「明示的な検証」「侵害を前提とする」という 3 つの原則に基づく<strong>ゼロトラスト</strong>が注目されるようになっています。</p><p>Global Secure Access (GSA) は、この<strong>ゼロ トラスト</strong>に基づいて設計している、Microsoft Entra の管理センターに統合されたネットワーク セキュリティ ソリューションです。「誰が・どのデバイスから・どのような状態でアクセスしているか」という ID 情報をもとに、クラウド上でアクセス制御を行います。</p><p>GSA は、社内のオンプレミス リソースへのセキュアなアクセスを提供する <strong>Microsoft Entra Private Access</strong> と、インターネットや SaaS アプリへのアクセスを制御・保護する <strong>Microsoft Entra Internet Access</strong> の 2 つのサービスの総称です。</p><p>本記事では、VPN の代替としても注目されている <strong>Microsoft Entra Private Access</strong> にフォーカスして解説します。</p><blockquote><p>参考: <a href="https://learn.microsoft.com/ja-jp/entra/global-secure-access/overview-what-is-global-secure-access">Global Secure Access とは | Microsoft Learn</a></p></blockquote><hr><h2 id="Microsoft-Entra-Private-Access-の基本"><a href="#Microsoft-Entra-Private-Access-の基本" class="headerlink" title="Microsoft Entra Private Access の基本"></a>Microsoft Entra Private Access の基本</h2><h3 id="Microsoft-Entra-Private-Access-とは"><a href="#Microsoft-Entra-Private-Access-とは" class="headerlink" title="Microsoft Entra Private Access とは"></a>Microsoft Entra Private Access とは</h3><p>VPN を使用している環境でのセキュリティ インシデントについて、耳にしたこともあるのではないでしょうか。オンプレミスの VPN ゲートウェイを利用する VPN は、その VPN ゲートウェイに含まれる管理者がまだ修正できていない脆弱性に対してのゼロデイ攻撃などのリスクが指摘されています。また、VPN はネットワーク境界の防御となっており、一度侵入されると社内ネットワークでの横断 (ラテラル ムーブメント) が容易などのリスクがあるため、VPN に代わるセキュアなアクセス手段が求められています。Global Secure Access は、Microsoft が提供する Security Service Edge (SSE) ソリューションであり、そのうちの Microsoft Entra Private Access (以降 Private Access ) は、ゼロ トラストの原則に基づいた、社内リソースへのセキュアなネットワーク アクセス制御を実現するサービスです。<br>従来の VPN では、主に IP アドレス ベースでのアクセス制御となっておりましたが、Private Access ではアプリケーション単位でアクセスを制御でき、ゼロ トラストの原則に基づいたきめ細かなアクセス管理を実現します。</p><h4 id="VPN-を使用している場合の社内リソースへのアクセス例"><a href="#VPN-を使用している場合の社内リソースへのアクセス例" class="headerlink" title="VPN を使用している場合の社内リソースへのアクセス例"></a>VPN を使用している場合の社内リソースへのアクセス例</h4><p><img src="/blog/azure-active-directory/starter-series-private-access/gsa-starter-vpn-architecture.png" alt="VPN を使用している場合の構成例"></p><p>従来の VPN 構成では、DMZ 上に VPN ゲートウェイを設置し、外部からの接続を受け入れるためにファイアウォールにて外部から VPN ゲートウェイへのインバウンド ポートを開放する必要があります。このインバウンド ポートは攻撃者にとっても入口となるため、VPN サーバーの脆弱性を突いた不正アクセスの攻撃対象面 (Attack Surface) となります。</p><p>従来の VPN に対して、Private Access の主な特長は以下のとおりです。</p><ul><li><strong>ゼロ トラスト ネットワーク アクセス (ZTNA)</strong>: ユーザー ID、デバイスの状態など様々なシグナルに基づいてアクセスを制御</li><li><strong>アプリケーション単位のアクセス制御</strong>: 社内ネットワーク全体ではなく、特定のリソースだけにアクセスを許可</li><li><strong>インバウンド ポート不要</strong>: コネクタはアウトバウンド接続のみで動作するため、ファイアウォールのインバウンド ポートを開放する必要がない</li><li><strong>条件付きアクセスとの統合</strong>: Entra ID の条件付きアクセスをそのまま社内アプリにも適用可能</li></ul><p>これらの特長により、リモート ユーザーは従来の VPN を使わずに社内リソースへセキュアにアクセスできるようになります。</p><h3 id="Microsoft-Entra-Private-Access-の仕組み"><a href="#Microsoft-Entra-Private-Access-の仕組み" class="headerlink" title="Microsoft Entra Private Access の仕組み"></a>Microsoft Entra Private Access の仕組み</h3><p>Private Access のアーキテクチャは、以下のコンポーネントで構成されます。</p><p><img src="/blog/azure-active-directory/starter-series-private-access/gsa-starter-private-access-architecture.png" alt="Microsoft Entra Private Access の仕組み"></p><p><strong>通信の流れ:</strong></p><ol><li>ユーザーのクライアント PC やモバイル端末 ( Windows 端末の場合 Microsoft Entra joined &#x2F; Microsoft Entra hybrid joined &#x2F; Microsoft Entra registered、Windows 端末以外の場合 Microsoft Entra registered ) に <strong>GSA クライアント</strong>がインストールされています</li><li>ユーザーが社内リソースにアクセスすると、GSA クライアントがトラフィックをキャプチャし、<strong>Microsoft の SSE (Security Service Edge)</strong> にトンネリングします</li><li>SSE で認証・認可 (条件付きアクセス ポリシーの評価を含む) が行われます</li><li>認可されたトラフィックは、企業ネットワーク内に設置された<strong>コネクタ サーバー</strong> (Private Network Connector) を経由して社内リソースに到達します</li><li>コネクタ サーバーは<strong>アウトバウンド (ポート 80, 443)</strong> のみで Microsoft のクラウド サービスと通信するため、<strong>インバウンド ポートの開放は不要</strong>です</li></ol><h3 id="Private-Access-の構成の詳細"><a href="#Private-Access-の構成の詳細" class="headerlink" title="Private Access の構成の詳細"></a>Private Access の構成の詳細</h3><h4 id="Quick-Access-と-Global-Secure-Access-アプリの使い分け"><a href="#Quick-Access-と-Global-Secure-Access-アプリの使い分け" class="headerlink" title="Quick Access と Global Secure Access アプリの使い分け"></a>Quick Access と Global Secure Access アプリの使い分け</h4><p><img src="/blog/azure-active-directory/starter-series-private-access/gsa-starter-quick-access-vs-gsa-app.png" alt="Quick Access と Global Secure Access アプリの使い分け"></p><p>Private Access では、社内リソースへのアクセスを構成する方法として 2 つのアプローチがあります。</p><p><strong>a. Quick Access (クイック アクセス)</strong></p><p>Quick Access は、Private Access を素早く導入するためのシンプルな構成方法です。保護対象となる FQDN、IP アドレス、IP 範囲をまとめて 1 つのアプリケーションとして登録します。</p><ul><li><strong>用途</strong>: VPN の置き換えとして、まず広く社内リソースへのアクセスを提供したい場合</li><li><strong>特徴</strong>: 1 つのエンタープライズ アプリとして管理され、すべてのリソースに対して同じアクセス ポリシーが適用</li><li><strong>推奨場面</strong>: PoC (概念実証) や初期導入段階</li></ul><p><strong>b. Global Secure Access アプリ (エンタープライズ アプリ)</strong></p><p>Global Secure Access アプリは、リソースごとに個別のエンタープライズ アプリケーションを作成し、より<strong>きめ細かなアクセス制御</strong>を実現します。</p><ul><li><strong>用途</strong>: リソースごとに異なるアクセス ポリシーを適用したい場合</li><li><strong>特徴</strong>: リソースごとに異なる条件付きアクセス ポリシーを構成可能</li><li><strong>推奨場面</strong>: 本番環境への段階的な展開、異なるセキュリティ要件を持つアプリの管理</li></ul><blockquote><p>参考: <a href="https://learn.microsoft.com/ja-jp/entra/global-secure-access/concept-private-access">Microsoft Entra Private Access について | Microsoft Learn</a></p></blockquote><h4 id="Private-Network-Connector-コネクタ-について"><a href="#Private-Network-Connector-コネクタ-について" class="headerlink" title="Private Network Connector (コネクタ) について"></a>Private Network Connector (コネクタ) について</h4><p>Private Access を利用するには、企業ネットワーク内に<strong>コネクタ サーバー</strong>を設置し、<strong>Private Network Connector</strong> ソフトウェアをインストールする必要があります。コネクタは Microsoft のクラウド サービスとの間のアウトバウンド接続を確立し、社内リソースへの通信を中継します。</p><p><strong>コネクタ グループの概念:</strong></p><p>コネクタは<strong>コネクタ グループ</strong>にまとめて管理します。コネクタ グループを使用することで、以下のような構成が可能です。</p><ul><li>環境ごとにコネクタを分離 (開発環境 &#x2F; 本番環境)</li><li>地理的に近いコネクタを通じてリソースにアクセスさせ、パフォーマンスを最適化</li><li>高可用性のために複数のコネクタ サーバーを同じグループに配置</li></ul><p>コネクタは Microsoft Entra 管理センターからダウンロードし、インストールします。<br>詳細は後述の構成手順をご参照ください。</p><blockquote><p>参考: <a href="https://learn.microsoft.com/ja-jp/entra/global-secure-access/how-to-configure-connectors">プライベート ネットワーク コネクタの構成方法 | Microsoft Learn</a></p></blockquote><hr><h2 id="Private-Access-の構成手順"><a href="#Private-Access-の構成手順" class="headerlink" title="Private Access の構成手順"></a>Private Access の構成手順</h2><p>Private Access を構成するための大まかな手順は以下のとおりです。</p><h3 id="ライセンス要件"><a href="#ライセンス要件" class="headerlink" title="ライセンス要件"></a>ライセンス要件</h3><p>Microsoft Entra Private Access を利用するには、以下のライセンスが必要です。</p><ul><li><strong>Microsoft Entra Private Access</strong> 単体ライセンス、または <strong>Microsoft Entra Suite</strong> ライセンス</li><li>上記に加えて、ユーザーに <strong>Microsoft Entra ID P1</strong> または <strong>P2</strong> ライセンスが必要です</li></ul><p>詳細は <a href="https://learn.microsoft.com/ja-jp/entra/global-secure-access/overview-what-is-global-secure-access#licensing-overview">Global Secure Access とは - ライセンスの概要 | Microsoft Learn</a> をご確認ください。</p><h3 id="必要なロール"><a href="#必要なロール" class="headerlink" title="必要なロール"></a>必要なロール</h3><p>Private Access の構成・運用には、実施するタスクに応じて以下のロールが必要です。最小特権の原則に従い、必要なロールのみを割り当てることが推奨されています。</p><table><thead><tr><th>タスク</th><th>必要なロール (最小権限)</th></tr></thead><tbody><tr><td>Private Access の構成 (Quick Access、コネクタ、アプリ セグメント)</td><td><strong>アプリケーション管理者</strong></td></tr><tr><td>トラフィック転送プロファイルの管理</td><td><strong>Global Secure Access 管理者</strong></td></tr><tr><td>ユーザーとグループの割り当て</td><td><strong>アプリケーション管理者</strong></td></tr><tr><td>条件付きアクセス ポリシーの作成・管理</td><td><strong>条件付きアクセス管理者</strong></td></tr><tr><td>トラフィック ログの確認 (読み取り専用)</td><td><strong>Global Secure Access ログ リーダー</strong></td></tr></tbody></table><p>なお、Global Secure Access 管理者ロールだけでは Private Access の構成やユーザー割り当てはできません。Private Access を構成するにはアプリケーション管理者ロールが必要です。</p><blockquote><p>参考: <a href="https://learn.microsoft.com/ja-jp/entra/global-secure-access/reference-role-based-permissions">Global Secure Access の組み込みロール | Microsoft Learn</a></p></blockquote><h3 id="手順-1-Private-Network-Connector-の設置"><a href="#手順-1-Private-Network-Connector-の設置" class="headerlink" title="手順 1: Private Network Connector の設置"></a>手順 1: Private Network Connector の設置</h3><ol><li>企業ネットワーク内にコネクタ用の Windows Server を準備します</li><li>Microsoft Entra 管理センター &gt; <strong>Global Secure Access</strong> &gt; <strong>接続</strong> &gt; <strong>コネクタ</strong> からコネクタ ソフトウェアをダウンロードします</li><li>コネクタ サーバー上でインストーラーを実行し、テナントの資格情報で登録します</li><li>管理センター上でコネクタが <strong>Active</strong> ステータスで表示されることを確認します</li></ol><h3 id="手順-2-Private-Access-トラフィック転送プロファイルの有効化"><a href="#手順-2-Private-Access-トラフィック転送プロファイルの有効化" class="headerlink" title="手順 2: Private Access トラフィック転送プロファイルの有効化"></a>手順 2: Private Access トラフィック転送プロファイルの有効化</h3><ol><li>Microsoft Entra 管理センター &gt; <strong>Global Secure Access</strong> &gt; <strong>接続</strong> &gt; <strong>トラフィック転送</strong> に移動します</li><li><strong>Private Access プロファイル</strong> のチェックボックスを選択して有効化します</li><li>ユーザーとグループの割り当てを行います</li></ol><h3 id="手順-3-Quick-Access-またはアプリケーション-セグメントの構成"><a href="#手順-3-Quick-Access-またはアプリケーション-セグメントの構成" class="headerlink" title="手順 3: Quick Access またはアプリケーション セグメントの構成"></a>手順 3: Quick Access またはアプリケーション セグメントの構成</h3><p>Quick Access や Global Secure Access アプリに登録する FQDN &#x2F; IP &#x2F; ポートは、アクセスしたい<strong>社内リソース側の情報</strong>です。</p><table><thead><tr><th>設定項目</th><th>設定する値</th></tr></thead><tbody><tr><td><strong>FQDN</strong></td><td>アクセスしたい社内サーバーのホスト名</td></tr><tr><td><strong>IP アドレス</strong></td><td>アクセスしたい社内サーバーの IP (範囲指定も可)</td></tr><tr><td><strong>ポート</strong></td><td>そのリソースが使用するプロトコルのポート番号 (445, 80, 3389 など)</td></tr></tbody></table><p><strong>Quick Access の場合:</strong></p><ol><li>Microsoft Entra 管理センター &gt; <strong>Global Secure Access</strong> &gt; <strong>アプリケーション</strong> &gt; <strong>Quick Access</strong> に移動します</li><li>社内リソースの FQDN、IP アドレス、または IP 範囲を追加します</li><li>コネクタ グループを割り当てます</li><li>ユーザーとグループを割り当てます</li></ol><p><strong>Global Secure Access アプリの場合:</strong></p><ol><li>Microsoft Entra 管理センター &gt; <strong>Global Secure Access</strong> &gt; <strong>アプリケーション</strong> &gt; <strong>エンタープライズ アプリケーション</strong> で新しいアプリを作成します</li><li>アプリケーション セグメント (FQDN、IP、ポート) を追加します</li><li>コネクタ グループを割り当てます</li><li>ユーザーとグループを割り当てます</li><li>必要に応じて条件付きアクセス ポリシーを構成します</li></ol><h3 id="手順-4-GSA-クライアントのインストール"><a href="#手順-4-GSA-クライアントのインストール" class="headerlink" title="手順 4: GSA クライアントのインストール"></a>手順 4: GSA クライアントのインストール</h3><ol><li>クライアント端末に GSA クライアントをインストールします。インストール手順の詳細は以下の公開情報をご参照ください。   <ul><li>GSA クライアントのダウンロード先は<a href="https://entra.microsoft.com/#view/Microsoft_Azure_Network_Access/Clients.ReactView">こちら</a>です</li><li><a href="https://learn.microsoft.com/ja-jp/entra/global-secure-access/how-to-install-windows-client">Windows 用 Global Secure Access クライアント | Microsoft Learn</a></li></ul></li><li>インストール後、タスク トレイの GSA クライアント アイコンが「接続済み」と表示されることを確認します</li></ol><h3 id="手順-5-動作確認"><a href="#手順-5-動作確認" class="headerlink" title="手順 5: 動作確認"></a>手順 5: 動作確認</h3><ol><li>クライアント端末にて GSA クライアントのアイコンを右クリック &gt; <strong>詳細な診断</strong> &gt; <strong>転送プロファイル</strong> を開きます</li><li>Private Access のルールが表示されていることを確認します</li><li>社内リソースにアクセスできることをテストします</li></ol><blockquote><p>参考: <a href="https://learn.microsoft.com/ja-jp/entra/global-secure-access/tutorial-private-access-enable-traffic-forwarding">チュートリアル: Private Access トラフィック転送を有効にする | Microsoft Learn</a><br>参考: <a href="https://learn.microsoft.com/ja-jp/entra/global-secure-access/tutorial-private-access-connector-setup">チュートリアル: Private Network Connector のセットアップ | Microsoft Learn</a></p></blockquote><hr><h2 id="よくあるお問い合わせの例"><a href="#よくあるお問い合わせの例" class="headerlink" title="よくあるお問い合わせの例"></a>よくあるお問い合わせの例</h2><p>これまでの説明をもとに、GSA (特に Private Access) に関するよくあるお問い合わせ例をご紹介します。</p><h3 id="Q1-アプリケーション-プロキシと-Private-Access-の違い"><a href="#Q1-アプリケーション-プロキシと-Private-Access-の違い" class="headerlink" title="Q1: アプリケーション プロキシと Private Access の違い"></a>Q1: アプリケーション プロキシと Private Access の違い</h3><blockquote><p>既に Microsoft Entra アプリケーション プロキシを使用していますが、Private Access との違いは何ですか？</p></blockquote><p>アプリケーション プロキシと Private Access は、どちらも <strong>Private Network Connector</strong> を使用して社内リソースへのアクセスを提供しますが、対応するプロトコルやアクセス方法に違いがあります。</p><table><thead><tr><th>比較項目</th><th>アプリケーション プロキシ</th><th>Private Access</th></tr></thead><tbody><tr><td><strong>主な用途</strong></td><td>Web アプリの外部公開 (B2B ゲスト アクセス含む)</td><td>社内リソースへの ZTNA アクセス</td></tr><tr><td><strong>アクセス方法</strong></td><td>外部 URL 経由でアクセス</td><td>社内の FQDN &#x2F; IP をそのまま使用</td></tr><tr><td><strong>クライアント PC で準備するもの</strong></td><td>不要 (ブラウザーのみで利用可能)</td><td>GSA クライアントが必要</td></tr><tr><td><strong>使用するコネクタ</strong></td><td>Private Network Connector</td><td>Private Network Connector</td></tr><tr><td><strong>対応プロトコル</strong></td><td>HTTP &#x2F; HTTPS (Web アプリのみ)</td><td>すべての TCP &#x2F; UDP</td></tr></tbody></table><h3 id="Q2-Private-Access-を導入したいが、既存の-VPN-と共存できるか"><a href="#Q2-Private-Access-を導入したいが、既存の-VPN-と共存できるか" class="headerlink" title="Q2: Private Access を導入したいが、既存の VPN と共存できるか"></a>Q2: Private Access を導入したいが、既存の VPN と共存できるか</h3><blockquote><p>Private Access を段階的に導入したいのですが、既存の VPN と GSA クライアントは同じ端末で共存できますか？</p></blockquote><p><strong>はい、共存可能です。</strong> GSA クライアントは、VPN 接続とは異なり、<strong>LWF (Lightweight Filter) ドライバー</strong> を使用してトラフィックをキャプチャします。このため、VPN クライアントと GSA クライアントを同じ端末上で共存させることができます。</p><p>段階的な導入として、以下のような進め方が可能です。</p><ol><li>まず GSA クライアントをパイロット ユーザーの端末にインストール</li><li>Private Access で一部のアプリのみを構成</li><li>VPN 経由でアクセスしていたアプリを徐々に Private Access に移行</li><li>すべてのアプリの移行が完了したら VPN を廃止</li></ol><blockquote><p>参考: <a href="https://learn.microsoft.com/ja-jp/entra/global-secure-access/tutorial-private-access-vpn-replacement">チュートリアル: クイック アクセスによる VPN の置き換え | Microsoft Learn</a></p></blockquote><h3 id="Q3-コネクタ-サーバーは何台必要か"><a href="#Q3-コネクタ-サーバーは何台必要か" class="headerlink" title="Q3: コネクタ サーバーは何台必要か"></a>Q3: コネクタ サーバーは何台必要か</h3><blockquote><p>Private Access を本番環境で利用する場合、コネクタ サーバーは最低何台必要ですか？</p></blockquote><p>機能上は <strong>1 台</strong>のコネクタ サーバーで動作しますが、本番環境では<strong>高可用性</strong>のため、同一のコネクタ グループに <strong>2 台以上</strong>のコネクタ サーバーを配置することを強く推奨します。</p><p>コネクタ サーバーの台数を検討する際のポイントは以下のとおりです。</p><ul><li><strong>高可用性</strong>: 1 台のサーバーが停止した場合でもアクセスを維持するため、最低 2 台を推奨</li><li><strong>パフォーマンス</strong>: 同時接続ユーザー数やトラフィック量に応じて台数を増やす</li><li><strong>地理的分散</strong>: 拠点が分散している場合、各拠点にコネクタを配置しコネクタ グループで管理</li></ul><h3 id="Q4-Private-Access-を構成したがアクセスできない"><a href="#Q4-Private-Access-を構成したがアクセスできない" class="headerlink" title="Q4: Private Access を構成したがアクセスできない"></a>Q4: Private Access を構成したがアクセスできない</h3><blockquote><p>Private Access を構成しましたが、クライアント端末から社内リソースにアクセスできません。</p></blockquote><p>この場合、以下のポイントを順に切り分け確認してください。</p><ol><li><strong>コネクタの状態</strong>: Microsoft Entra 管理センターでコネクタが <strong>Active</strong> になっているか</li><li><strong>コネクタからリソースへの接続</strong>: コネクタ サーバーから対象の社内リソースに直接アクセスできるか (DNS 解決を含む)</li><li><strong>ユーザーの割り当て</strong>: Private Access のトラフィック転送プロファイルと Quick Access アプリの両方にユーザーが割り当てられているか</li><li><strong>GSA クライアントの状態</strong>: タスク トレイの GSA アイコンが「接続済み」になっているか</li><li><strong>転送プロファイルの反映</strong>: GSA クライアントの詳細な診断で Private Access ルールが表示されているか (反映に最大 5 分程度かかることがあります)</li></ol><h3 id="Q5-条件付きアクセスで-Private-Access-アプリのアクセスを制御したい"><a href="#Q5-条件付きアクセスで-Private-Access-アプリのアクセスを制御したい" class="headerlink" title="Q5: 条件付きアクセスで Private Access アプリのアクセスを制御したい"></a>Q5: 条件付きアクセスで Private Access アプリのアクセスを制御したい</h3><blockquote><p>特定の社内アプリには MFA を要求し、それ以外の社内アプリにはデバイスの準拠を要求したい。</p></blockquote><p>この場合は <strong>Global Secure Access アプリ</strong>を使用し、リソースごとに別々のエンタープライズ アプリケーションを作成してください。Quick Access では、すべてのリソースに対して同一のポリシーしか適用できません。</p><p>構成例:</p><figure class="highlight text"><table><tr><td class="code"><pre><span class="line">[MFA を要求するアプリ]</span><br><span class="line">  └── エンタープライズ アプリ A: 社内人事システム (FQDN: hr.corp.contoso.com)</span><br><span class="line">      └── 条件付きアクセス ポリシー: すべてのユーザーに MFA を要求</span><br><span class="line"></span><br><span class="line">[デバイスの準拠を要求するアプリ]</span><br><span class="line">  └── エンタープライズ アプリ B: 社内ファイル サーバー (IP: 10.0.1.0/24)</span><br><span class="line">      └── 条件付きアクセス ポリシー: 準拠済みデバイスを要求</span><br></pre></td></tr></table></figure><p>Global Secure Access アプリを使用することで、条件付きアクセスの柔軟な制御が可能になります。</p><blockquote><p>参考: <a href="https://learn.microsoft.com/ja-jp/entra/global-secure-access/how-to-configure-per-app-access">Global Secure Access アプリケーションを使用したアプリごとのアクセスの構成方法 | Microsoft Learn</a></p></blockquote><hr><h2 id="トラフィック-ログを見るときのポイント"><a href="#トラフィック-ログを見るときのポイント" class="headerlink" title="トラフィック ログを見るときのポイント"></a>トラフィック ログを見るときのポイント</h2><p>GSA を通過したトラフィックは、<strong>トラフィック ログ</strong>で確認できます。アクセスの問題をトラブルシューティングする際に非常に役立ちます。</p><h3 id="トラフィック-ログの確認手順"><a href="#トラフィック-ログの確認手順" class="headerlink" title="トラフィック ログの確認手順"></a>トラフィック ログの確認手順</h3><ol><li>Microsoft Entra 管理センター (<a href="https://entra.microsoft.com/">https://entra.microsoft.com</a>) にサインインします</li><li><strong>Global Secure Access</strong> &gt; <strong>監視</strong> &gt; <strong>トラフィック ログ</strong> に移動します</li><li>フィルターを使用して、特定のユーザー、宛先、アクションなどで絞り込みます</li></ol><h3 id="トラフィック-ログで確認すべき項目"><a href="#トラフィック-ログで確認すべき項目" class="headerlink" title="トラフィック ログで確認すべき項目"></a>トラフィック ログで確認すべき項目</h3><table><thead><tr><th>項目</th><th>説明</th></tr></thead><tbody><tr><td><strong>ユーザー プリンシパル名</strong></td><td>トラフィックを発生させたユーザー</td></tr><tr><td><strong>ソース IP</strong></td><td>クライアントの IP アドレス</td></tr><tr><td><strong>宛先 FQDN &#x2F; IP</strong></td><td>アクセス先のリソース</td></tr><tr><td><strong>アクション</strong></td><td>許可 (Allowed) またはブロック (Blocked)</td></tr><tr><td><strong>トランスポート プロトコル</strong></td><td>TCP &#x2F; UDP</td></tr><tr><td><strong>受信バイト &#x2F; 送信バイト</strong></td><td>通信量</td></tr></tbody></table><h3 id="GSA-クライアント側の診断"><a href="#GSA-クライアント側の診断" class="headerlink" title="GSA クライアント側の診断"></a>GSA クライアント側の診断</h3><p>クライアント端末側でも、GSA クライアントの<strong>詳細な診断</strong>機能を使用して問題を調査できます。</p><ol><li>タスク トレイの GSA アイコンを右クリック &gt; <strong>詳細な診断</strong> を選択します</li><li><strong>転送プロファイル</strong> タブ: 現在適用されているルールの一覧を確認します</li><li><strong>正常性チェック</strong> タブ: クライアントの接続状態やプロファイルの最終チェック日時を確認します</li></ol><hr><h2 id="まとめ"><a href="#まとめ" class="headerlink" title="まとめ"></a>まとめ</h2><p>今回の初学者向けシリーズでは、Global Secure Access (GSA) について、特に Microsoft Entra Private Access を中心に解説しました。特にご注目いただきたい点をまとめると以下のとおりです。</p><ul><li><strong>Global Secure Access は Microsoft の SSE ソリューション</strong>であり、Private Access (社内リソース向け) と Internet Access (インターネット向け) の 2 つのサービスで構成される</li><li><strong>Private Access は VPN に代わるリモート アクセス手段として使用でき</strong>、ゼロ トラスト ネットワーク アクセス (ZTNA) の考え方に基づいて、アプリ単位のアクセス制御を実現する</li><li><strong>Private Network Connector</strong> を企業ネットワーク内に設置し、アウトバウンド接続のみでクラウド サービスと通信するため、インバウンド ポートの開放が不要</li><li><strong>Quick Access</strong> は導入初期のシンプルな構成に、<strong>Global Secure Access アプリ</strong>は本番環境できめ細かなアクセス制御に適している</li><li><strong>条件付きアクセスとの統合</strong>により、デバイスの準拠状態、MFA の要求など、ID ベースの高度なアクセス制御を社内アプリにも適用可能</li></ul><hr><p>※ 本情報の内容 (リンク先などを含む) は、作成日時点でのものであり、予告なく変更される場合があります。</p>]]>
    </content>
    <id>https://jpazureid.github.io/blog/azure-active-directory/starter-series-private-access/</id>
    <link href="https://jpazureid.github.io/blog/azure-active-directory/starter-series-private-access/"/>
    <published>2026-06-05T06:00:00.000Z</published>
    <summary>
      <![CDATA[<p>こんにちは、Azure Identity サポート チームの 夏木 です。Microsoft Entra サポート チームより、最近 Entra の利用を始めたお客様を対象に、初学者向けのブログ シリーズを作成しております。本記事はその Entra ID 初学者向けシリーズ]]>
    </summary>
    <title>Entra ID 初学者向けシリーズ第 5 弾 - Microsoft Entra Private Access 入門</title>
    <updated>2026-08-12T00:07:05.288Z</updated>
  </entry>
  <entry>
    <author>
      <name>Azure Identity Support Japan</name>
    </author>
    <category term="Conditional Access" scheme="https://jpazureid.github.io/blog/tags/Conditional-Access/"/>
    <category term="Microsoft Entra ID" scheme="https://jpazureid.github.io/blog/tags/Microsoft-Entra-ID/"/>
    <content>
      <![CDATA[<div class="alert is-info"><p class="alert-title">Note</p><p>2026 年 5 月 7 日更新: カスタム アプリケーション作成時の [サポートされているアカウントの種類] を更新しました</p><p>2026 年 5 月 26 日更新: カスタム アプリケーション作成時の [サポートされているアカウントの種類] を改めて更新しました</p><p>2026 年 8 月 4 日更新: 変更の影響を受けた場合の一時的な回避策を追記しました</p></div><p>こんにちは、Azure Identity サポート チームの 成田 です。<br>本記事では、<strong>2026 年 5 月 13 日</strong> より展開が予定されている、条件付きアクセス (CA) ポリシーの「ベースライン スコープ」に関する動作変更について解説いたします。</p><div class="alert is-warning"><p class="alert-title">警告</p><p>この変更は <strong>2026 年 5 月 13 日</strong> から段階的に展開される予定です。「すべてのリソースを対象」かつ「特定のリソースを対象外」とする条件付きアクセス ポリシーをお持ちの組織では、展開開始日までに影響の確認と必要な対処を完了いただくことをお勧めします。</p></div><p>公開情報:</p><ul><li><a href="https://learn.microsoft.com/ja-jp/entra/identity/conditional-access/concept-enforcement-resource-exclusions">リソースの除外による条件付きアクセス ポリシーの適用の強化 - Microsoft Entra ID | Microsoft Learn</a></li><li><a href="https://jpazureid.github.io/blog/azure-active-directory/upcoming-conditional-access-change-improved-enforcement-for-policies-with-resour/">今後の条件付きアクセスの変更 リソース除外を含むポリシーの適用強化 - Japan Azure Identity Support Blog</a></li></ul><h2 id="1-この変更は何か"><a href="#1-この変更は何か" class="headerlink" title="1. この変更は何か"></a>1. この変更は何か</h2><h3 id="概要"><a href="#概要" class="headerlink" title="概要"></a>概要</h3><p>条件付きアクセス ポリシーを <strong>「対象: すべてのリソース」</strong> かつ <strong>「対象外: 特定のリソース」</strong> の構成で運用しているテナントにおいて、以前は「ベースライン スコープ」のみを要求する認証リクエストが自動的にポリシーの適用対象から除外されていました。<br>今回の変更により、<strong>この自動除外が廃止</strong> され、ベースライン スコープのみを要求するリクエストにも条件付きアクセス ポリシーが適用されるようになります。</p><h3 id="ベースライン-スコープとは"><a href="#ベースライン-スコープとは" class="headerlink" title="ベースライン スコープとは"></a>ベースライン スコープとは</h3><p>ベースライン スコープとは、以下の低い特権スコープの総称です。</p><table><thead><tr><th>種類</th><th>スコープ</th></tr></thead><tbody><tr><td>OpenID Connect (OIDC) スコープ</td><td><code>email</code>, <code>offline_access</code>, <code>openid</code>, <code>profile</code></td></tr><tr><td>ベースライン ディレクトリ スコープ</td><td><code>User.Read</code>, <code>User.Read.All</code>, <code>User.ReadBasic.All</code>, <code>People.Read</code>, <code>People.Read.All</code>, <code>GroupMember.Read.All</code>, <code>Member.Read.Hidden</code></td></tr></tbody></table><p>これらのスコープは、サインイン時にユーザーの基本的なプロフィール情報やグループ メンバーシップを取得するために多くのアプリケーションが要求するものです。<br>このスコープと、特定のリソースの関係性については後述する「3. 新しい動作の仕組み」にて「条件付きアクセスのリソース評価の仕組み」の項にてご説明します。</p><h2 id="2-なぜこの変更が行われたのか"><a href="#2-なぜこの変更が行われたのか" class="headerlink" title="2. なぜこの変更が行われたのか"></a>2. なぜこの変更が行われたのか</h2><p>従来は、「対象: すべてのリソース &#x2F; 対象外: 特定のリソース」構成のポリシーにおいて、アプリケーションがベースライン スコープのみを要求した場合、そのリクエストは <strong>CA ポリシーの適用対象外</strong> として扱われていました。<br>これは、多くのアプリケーションがサインイン処理の一部としてこれらのスコープを要求するため、意図しないアクセス ブロックを防ぐための配慮でした。<br>今回の変更により、この配慮した動作が廃止されます。結果として、セキュリティがより高まる方向に動作変更されます。</p><h2 id="3-新しい動作の仕組み"><a href="#3-新しい動作の仕組み" class="headerlink" title="3. 新しい動作の仕組み"></a>3. 新しい動作の仕組み</h2><p>変更後の動作を理解するために、まず技術的な背景を整理します。</p><h3 id="条件付きアクセスのリソース評価の仕組み"><a href="#条件付きアクセスのリソース評価の仕組み" class="headerlink" title="条件付きアクセスのリソース評価の仕組み"></a>条件付きアクセスのリソース評価の仕組み</h3><p>条件付きアクセスは、認証リクエストにおいてアクセス先の <strong>「リソース (Audience)」</strong> に基づいてポリシーの適用を判断します。たとえば、アプリケーションが <code>Mail.Read</code> スコープを要求した場合、リソースは Exchange Online として評価され、Exchange Online を対象とする CA ポリシーが適用されます。<br>ベースライン スコープ (<code>User.Read</code> や <code>openid</code> など) は、<strong>Windows Azure Active Directory</strong> (アプリ ID: 00000002-0000-0000-c000-000000000000) をリソースとして評価されます。ここで重要なのは、Windows Azure Active Directory というリソースにはベースライン スコープだけでなく、<code>Directory.ReadWrite.All</code> や <code>Application.ReadWrite.All</code> のような <strong>高い特権を持つスコープも含まれている</strong> という点です。つまり、同じ「Windows Azure Active Directory」というリソースの中に、低特権のスコープと高特権のスコープが混在しています。</p><h3 id="新しい動作のポイント"><a href="#新しい動作のポイント" class="headerlink" title="新しい動作のポイント"></a>新しい動作のポイント</h3><p>変更後は、ベースライン スコープのみを要求する認証リクエストも、リソースとして <strong>Windows Azure Active Directory</strong> にマップされ、CA ポリシーの適用対象として評価されるようになりました。</p><div class="alert is-important"><p class="alert-title">重要</p><p><strong>影響の具体例:</strong></p><p>「すべてのリソースを対象 &#x2F; Exchange Online を対象外 &#x2F; MFA 必須」という CA ポリシーがある場合:</p><p><strong>従来</strong>: <code>openid</code> + <code>profile</code> のみを要求する VS Code へのサインイン → MFA <strong>不要</strong> (暗黙的に対象外になる)</p><p><strong>変更後</strong>: 同じサインイン → MFA が <strong>要求される</strong> (対象外にならない)</p></div><h2 id="4-影響を受ける条件"><a href="#4-影響を受ける条件" class="headerlink" title="4. 影響を受ける条件"></a>4. 影響を受ける条件</h2><p>以下の <strong>すべて</strong> に該当する場合に影響を受けます。</p><ol><li><strong>すべてのリソース</strong> を対象とする条件付きアクセス ポリシーが 1 つ以上ある</li><li>それらのポリシーに 1 つ以上の <strong>リソース除外</strong> が設定されている</li><li>テナント内のユーザーが <strong>ベースライン スコープのみ</strong> を要求するアプリケーションを使用してサインインする</li></ol><div class="alert is-info"><p class="alert-title">Note</p><p><strong>影響を受けないケース:</strong></p><p>・「すべてのリソースを対象」でリソース除外が <strong>ない</strong> ポリシーのみ運用している場合</p><p>・アプリケーションがベースライン スコープに加えて他のスコープ (<code>Mail.Read</code> など) も要求している場合 (これらは既に CA の適用対象)</p></div><h2 id="5-従来の動作を維持したい場合の対処手順"><a href="#5-従来の動作を維持したい場合の対処手順" class="headerlink" title="5. 従来の動作を維持したい場合の対処手順"></a>5. 従来の動作を維持したい場合の対処手順</h2><p>以前 (2026 年 2 月) の記事公開後、お客様より多くのフィードバックをいただき、Entra ID 側の設定変更で従来の動作を維持する方法を提供する運びとなりました。</p><p>ただし、本変更は <a href="https://www.microsoft.com/ja-jp/trust-center/security/secure-future-initiative">Microsoft セキュア フューチャー イニシアティブ</a> に基づくプロアクティブなセキュリティ対策であるため、従来の動作を維持し続けることを積極的にお勧めするものではありません。<br>影響の確認やアプリケーションの動作検証、さらにはアプリケーション側の改修といったお客様側の対応にも一定の時間を要することから、暫定的な猶予期間として、あるいはどうしても対応が難しいアプリケーション向けの措置としてご活用いただくことを想定しています。</p><p>新しい適用モデルへの移行が推奨されますが、既存のアプリケーションの動作を維持する必要がある場合は、<strong>「ベースライン スコープ設定」</strong> を使用して従来の動作を保持できます。<br>仕組みとしては、テナント内にカスタム アプリケーションを登録し、それをベースライン スコープのターゲット リソースとして設定します。ベースライン スコープのみを要求する認証リクエストは、Windows Azure Active Directory の代わりに <strong>このカスタム アプリケーションをリソースとして評価</strong> されるようになります。そのうえで、CA ポリシーの対象外にこのカスタム アプリケーションを追加することで、従来と同じ除外動作を実現します。</p><h3 id="考え方のイメージ"><a href="#考え方のイメージ" class="headerlink" title="考え方のイメージ"></a>考え方のイメージ</h3><figure class="highlight plaintext"><table><tr><td class="code"><pre><span class="line">【従来の動作】</span><br><span class="line">アプリが openid + profile を要求</span><br><span class="line">  → リソース: Windows Azure Active Directory</span><br><span class="line">  → 自動的に CA ポリシーの適用対象外 (ベースライン スコープのため)</span><br><span class="line"></span><br><span class="line">【変更後の動作 (対処なし)】</span><br><span class="line">アプリが openid + profile を要求</span><br><span class="line">  → リソース: Windows Azure Active Directory</span><br><span class="line">  → CA ポリシーの適用対象 ← MFA 等が要求される</span><br><span class="line"></span><br><span class="line">【変更後の動作 (カスタム ターゲット リソースで対処)】</span><br><span class="line">アプリが openid + profile を要求</span><br><span class="line">  → リソース: カスタム アプリ (例: CA_BaselineScopes_TargetResource)</span><br><span class="line">  → CA ポリシーの対象外に追加済み → 除外される ※従来と同等</span><br></pre></td></tr></table></figure><div class="alert is-info"><p class="alert-title">Note</p><p><strong>なぜ Windows Azure Active Directory を直接除外しないのか?</strong></p><p>Windows Azure Active Directory をリソースとして CA ポリシーの対象外に追加した場合、ベースライン スコープだけでなく <code>Directory.ReadWrite.All</code> などの <strong>高い特権スコープも含めて除外</strong> されてしまいます。</p><p>これはセキュリティ上好ましくありません。 カスタム アプリケーションを「身代わり」のターゲット リソースとして設定することで、<strong>ベースライン スコープのリクエストのみを選択的に除外</strong> しつつ、高い特権スコープの要求には引き続き CA ポリシーを適用できます。</p></div><h2 id="6-具体的な設定手順"><a href="#6-具体的な設定手順" class="headerlink" title="6. 具体的な設定手順"></a>6. 具体的な設定手順</h2><p>以下の 3 つのステップで設定を行います。</p><h3 id="ステップ-1-カスタム-アプリケーションの登録"><a href="#ステップ-1-カスタム-アプリケーションの登録" class="headerlink" title="ステップ 1: カスタム アプリケーションの登録"></a>ステップ 1: カスタム アプリケーションの登録</h3><ol><li>Azure portal (<a href="https://portal.azure.com/">https://portal.azure.com</a>) もしくは Microsoft Entra 管理センター (<a href="https://entra.microsoft.com/">https://entra.microsoft.com</a>) に、アプリケーションを登録可能な管理者アカウントでサインインします。</li><li>[Microsoft Entra ID] &gt; [アプリの登録] に遷移し、[+ 新規登録] をクリックします。</li><li>以下の設定でアプリケーションを登録します。<ul><li><strong>名前</strong>: 任意の分かりやすい名前 (例: <code>CA_BaselineScopes_TargetResource</code>)<br>※ ベースライン スコープ設定で利用する組織にとって重要なアプリケーションになりますため、用途が明確に分かる名前をお勧めします。</li><li><strong>サポートされているアカウントの種類</strong>: 「この組織ディレクトリのみに含まれるアカウント (シングル テナント)」を選択します</li><li><strong>リダイレクト URI</strong>: 設定は必須ではありません。設定する場合は、プラットフォームに “Web” を選択し、URL 欄に任意の URL を入力してください (ダミーで構いません)。</li></ul></li><li>[登録] をクリックし、アプリケーションを作成します。</li></ol><div class="alert is-info"><p class="alert-title">Note</p><p>以前、この手順 3 においてサポートされているアカウントの種類は「複数の Entra ID テナント」を選択する必要がありました。</p><p>これは一部アプリケーションで限定的に発生することが確認されていた問題に対する回避策でした。</p><p>現在は問題が解消していますので、新しく構成する場合には「この組織ディレクトリのみに含まれるアカウント (シングル テナント)」を選択してください。</p><p>もし、既に「複数の Entra ID テナント」を選択して構成していた場合、以下の手順で「この組織ディレクトリのみに含まれるアカウント」に変更することをご検討ください。</p><ol><li>Azure ポータルもしくは Microsoft Entra 管理センターにアプリケーションを更新可能な管理者アカウント (所有者、アプリケーション管理者など) でサインインします</li><li>[Microsoft Entra ID] &gt; [アプリの登録] に遷移します。</li><li>作成済みの [アプリの登録] を開きます。</li><li>Authentication (Preview) を開きます。</li><li>Supported accounts を選択して、「サポートされているアカウントの種類:」を「シングル テナントのみ - テナント名」を選択します</li></ol><p>この変更によりベースライン スコープや条件付きアクセス ポリシーの動作に変更はありません。</p><p>マルチ テナントであっても動作上の違いはないのですが、作成するアプリの目的はシングル テナントにのみ影響を与える用途であるため、「シングル テナントのみ」であることが妥当であると考えられます。</p></div><h3 id="ステップ-2-条件付きアクセス-ポリシーの対象外に追加"><a href="#ステップ-2-条件付きアクセス-ポリシーの対象外に追加" class="headerlink" title="ステップ 2: 条件付きアクセス ポリシーの対象外に追加"></a>ステップ 2: 条件付きアクセス ポリシーの対象外に追加</h3><ol><li>条件付きアクセス管理者以上の権限を持つアカウントで [Microsoft Entra ID] &gt; [セキュリティ] &gt; [条件付きアクセス] に遷移します。</li><li>「すべてのリソースを対象 &#x2F; 特定のリソースを対象外」の構成となっている条件付きアクセス ポリシーを選択します。</li><li>[ターゲット リソース] &gt; [対象外] タブを開き、ステップ 1 で作成したカスタム アプリケーションを追加します。</li><li>[保存] をクリックします。</li></ol><div class="alert is-important"><p class="alert-title">重要</p><p>対象のポリシーが複数ある場合は、すべてのポリシーに対してこの手順を実施してください。</p></div><h3 id="ステップ-3-ベースライン-スコープ設定でカスタム-ターゲット-リソースを構成"><a href="#ステップ-3-ベースライン-スコープ設定でカスタム-ターゲット-リソースを構成" class="headerlink" title="ステップ 3: ベースライン スコープ設定でカスタム ターゲット リソースを構成"></a>ステップ 3: ベースライン スコープ設定でカスタム ターゲット リソースを構成</h3><ol><li>以下の URL にアクセスし、条件付きアクセスのベースライン スコープ設定画面を開きます。現在はこの URL からのみアクセスが可能です。<br><a href="https://aka.ms/BaselineScopesSettingsUX">https://aka.ms/BaselineScopesSettingsUX</a></li><li>条件付きアクセス管理者以上の権限を持つアカウントでサインインします。</li><li>[カスタム ターゲット リソース: カスタム ターゲット リソースを選択する (Custom target resource: Select a custom target resource)] を選択し、ステップ 1 で作成したカスタム アプリケーションを選択します。</li><li>[保存 (Save)] をクリックして設定を保存します。</li></ol><div class="alert is-info"><p class="alert-title">Note</p><p>この設定により、ベースライン スコープのみを要求する認証リクエストにおいて、条件付きアクセスのリソース評価で Windows Azure Active Directory の代わりに指定したカスタム アプリケーションが使用されるようになります。</p><p>ステップ 2 でこのカスタム アプリケーションを CA ポリシーの対象外に設定済みのため、結果として従来と同等の除外動作が実現されます。 なお、発行されるトークンの audience (aud クレーム) 自体は Windows Azure Active Directory や Microsoft Graph のままであり、アプリケーションの動作に影響はありません。</p></div><div class="alert is-important"><p class="alert-title">重要</p><p><strong>カスタム ターゲット リソースによるオプトアウトはあくまで暫定措置です</strong></p><p>上記の手順で特定したアプリケーションについては、カスタム ターゲット リソースによる除外で従来の動作を維持している間に、アプリケーション側の改修をご検討ください。</p><p>新しい既定の動作では、ベースライン スコープのみを要求するサインインにも CA ポリシーが適用されます。そのため、アプリケーションが条件付きアクセス チャレンジ (MFA やデバイス コンプライアンスなど) を適切にハンドルできるよう改修することが、中長期的には推奨されます。</p><p>具体的には、アプリケーションが CA チャレンジを受けた際に、ユーザーに対して正しくリダイレクトや再認証のフローを提示できるようにする必要があります。</p><p>実装方法の詳細については、以下の公開情報をご参照ください。</p><p><a href="https://learn.microsoft.com/ja-jp/entra/identity-platform/v2-conditional-access-dev-guide">条件付きアクセス開発者向けガイダンス - Microsoft identity platform | Microsoft Learn</a></p></div><h2 id="7-もし準備をする前に影響を受けてしまったら"><a href="#7-もし準備をする前に影響を受けてしまったら" class="headerlink" title="7. もし準備をする前に影響を受けてしまったら"></a>7. もし準備をする前に影響を受けてしまったら</h2><p>変更の展開前に準備が間に合わず、すでに影響を受けてしまった場合には、今まで適用されていなかった条件付きアクセス ポリシーによってアクセスがブロックされてしまう場合があります。<br>その場合、まずは変更の影響を受ける以前の動作に戻し、その後に対処を進めることをご検討ください。<br>継続的に無効にすることは推奨していないため、一時的な問題の回避として、6 章でご案内した確認・対処を進めるための時間を確保する目的で、変更の影響を受ける以前の動作に戻すことが有効です。</p><h3 id="以前の動作に戻す方法"><a href="#以前の動作に戻す方法" class="headerlink" title="以前の動作に戻す方法"></a>以前の動作に戻す方法</h3><ol><li>以下の URL にアクセスし、条件付きアクセスのベースライン スコープ設定画面を開きます。現在はこの URL からのみアクセスが可能です。<br><a href="https://aka.ms/BaselineScopesSettingsUX">https://aka.ms/BaselineScopesSettingsUX</a></li><li>条件付きアクセス管理者以上の権限を持つアカウントでサインインします。</li><li>画面上に表示されるベースライン スコープ設定画面で以下の選択肢を選択します。<ul><li>[適用を無効にする (Disable enforcement)]</li></ul></li><li>保存して設定を反映します。</li><li>通常は数分間以内に以前の動作に戻る想定です。改めてアプリケーションへのサインインを試します。</li></ol><div class="alert is-info"><p class="alert-title">Note</p><p>このオプションは、継続的に無効にすることを推奨するものではありません。あくまで一時的な問題の回避として、1 章から 6 章でご案内した確認・対処を進めるための時間を確保するためにご利用ください。</p></div><h2 id="8-まとめ"><a href="#8-まとめ" class="headerlink" title="8. まとめ"></a>8. まとめ</h2><table><thead><tr><th>項目</th><th>内容</th></tr></thead><tbody><tr><td>変更内容</td><td>「すべてのリソース &#x2F; 対象外あり」の CA ポリシーにおいて、ベースライン スコープのみの認証リクエストが自動除外されなくなった</td></tr><tr><td>影響</td><td>ベースライン スコープのみを要求するアプリへのサインイン時に、MFA やデバイス コンプライアンスなどの CA チャレンジが発生する可能性がある</td></tr><tr><td>推奨対応</td><td>新しい適用モデルに合わせることが推奨。やむを得ない場合はカスタム ターゲット リソースで従来の動作を維持</td></tr><tr><td>必要な手順 (従来の動作を維持する場合)</td><td>1. カスタム アプリケーションの登録 &#x2F; 2. CA ポリシーの対象外に追加 &#x2F; 3. ベースライン スコープ設定にカスタム ターゲット リソースを構成</td></tr></tbody></table><h2 id="参考情報"><a href="#参考情報" class="headerlink" title="参考情報"></a>参考情報</h2><ul><li><a href="https://learn.microsoft.com/ja-jp/entra/identity/conditional-access/concept-enforcement-resource-exclusions">リソースの除外による条件付きアクセス ポリシーの適用の強化 - Microsoft Entra ID | Microsoft Learn</a></li><li><a href="https://learn.microsoft.com/ja-jp/entra/identity/conditional-access/concept-conditional-access-cloud-apps">条件付きアクセス: ターゲット リソース - Microsoft Entra ID | Microsoft Learn</a></li><li><a href="https://aka.ms/BaselineScopesSettingsUX">ベースライン スコープ設定画面</a></li></ul><p>上記内容が少しでも参考となりますと幸いです。製品動作に関する正式な見解や回答については、お客様環境などを把握したうえでサポート部門より提供させていただきますので、ぜひ弊社サポート サービスをご利用ください。</p>]]>
    </content>
    <id>https://jpazureid.github.io/blog/azure-active-directory/baseline-scopes-enforcement/</id>
    <link href="https://jpazureid.github.io/blog/azure-active-directory/baseline-scopes-enforcement/"/>
    <published>2026-04-20T15:00:00.000Z</published>
    <summary>
      <![CDATA[<div class="alert is-info"><p class="alert-title">Note</p><p>2026 年 5 月 7 日更新: カスタム アプリケーション作成時の [サポートされているアカウントの種類] を更新しました</p><p>2026 年 5]]>
    </summary>
    <title>条件付きアクセス ポリシーの「ベースライン スコープ」に関する動作変更の解説</title>
    <updated>2026-08-12T00:07:04.447Z</updated>
  </entry>
  <entry>
    <author>
      <name>Azure Identity Support Japan</name>
    </author>
    <category term="Microsoft Entra ID" scheme="https://jpazureid.github.io/blog/tags/Microsoft-Entra-ID/"/>
    <category term="Enterprise SSO" scheme="https://jpazureid.github.io/blog/tags/Enterprise-SSO/"/>
    <content>
      <![CDATA[<div class="alert is-info"><p class="alert-title">Note</p><p>2026 年 4 月 30 日更新: 影響範囲について、iOS と Mac デバイスの違いを追記しました。</p></div><p>こんにちは、Azure &amp; Identity サポートの金森です。</p><p>今回は Apple デバイス (iPhone、iPad、Mac) の [Microsoft Entra ID (以下 Entra ID) へのデバイス登録に紐づく、デバイス ID &#x2F; キーの情報が保持される仕組み] が変更されたことについて、どのような変更であるかの説明や、この変更による影響、対処方法などについてお知らせします。</p><p>弊社公開情報では、 <a href="https://learn.microsoft.com/ja-jp/entra/identity-platform/apple-sso-plugin">Apple デバイス用の Microsoft Enterprise SSO プラグイン</a> 内の <a href="https://learn.microsoft.com/ja-jp/entra/identity-platform/apple-sso-plugin#device-identity-key-storage">デバイス ID キー ストレージ</a> の説明が該当します。</p><h2 id="どのような実装変更であるか"><a href="#どのような実装変更であるか" class="headerlink" title="どのような実装変更であるか"></a>どのような実装変更であるか</h2><p><a href="https://learn.microsoft.com/ja-jp/entra/identity-platform/apple-sso-plugin#device-identity-key-storage">前述の公開情報</a> の説明のポイントをサマライズします。</p><ul><li>Apple デバイスは、Intune への MDM 登録を行うと、併せて Entra ID へのデバイス登録も行っている</li><li>つまり、Apple デバイス上には以下の 2 つのデバイス登録情報がそれぞれ別のものとして保持されていることになる<ul><li>Intune への MDM 登録情報</li><li>Entra ID へのデバイス登録情報 (以降デバイス ID と呼称します)</li></ul></li><li>デバイス ID は、PRT (Primary Refresh Token) を用いた SSO やデバイス ベースのアクセス制御を適切に受けるための判定情報であるデバイス固有の ID 値を提供する</li><li>これまで、Entra ID に対してデバイスの新規登録をおこなう際、デバイス ID は OS 内の “キーチェーン” に格納されていた</li><li>この新規登録の際のデバイス ID の格納先が、キーチェーンから Secure Enclave に変わる実装がロールアウトされた</li><li>このロールアウトにより、デバイスに格納されているデバイス認証に利用される鍵などの情報の保護が強化された</li><li>このロールアウトは 2025 年 8 月以降順次、各テナントにロールアウトされていき、特に 2026 年 3 月に広くロールアウトされた</li></ul><p>つまり、ロールアウトが適用される以前に Intune MDM 登録 + Entra ID へのデバイス登録を行った Apple デバイスと、2025 年 8 月以降にロールアウトが適用された Apple デバイスでは [デバイス ID の格納先が異なる] ことになります。</p><ul><li>ロールアウトが適用される以前のセットアップ : キーチェーンにデバイス ID が格納されている</li><li>ロールアウトが適用された以降のセットアップ : Secure Enclave にデバイス ID が格納されている</li></ul><h3 id="補足"><a href="#補足" class="headerlink" title="補足"></a>補足</h3><p>キーチェーンや Secure Enclave は、Apple デバイスの [機密性の高いデータ (アカウントの資格情報やトークンのキャッシュなど) を格納する領域] です。<br>以下は Apple の技術情報ですが、参考として紹介します。</p><p><a href="https://support.apple.com/ja-jp/guide/security/secb0694df1a/1/web/1">キーチェーンのデータ保護 - Apple サポート (日本)</a><br><a href="https://support.apple.com/ja-jp/guide/security/sec59b0b31ff/web">Secure Enclave - Apple サポート (日本)</a></p><div class="alert is-info"><p class="alert-title">Note</p><p>Secure Enclave は、Windows における TPM のように [OS から直接アクセスできない、ディスク以外のハードウェアに確保されたセキュアなデータの格納領域] です。</p></div><h2 id="キーチェーンと-Secure-Enclave-のどちらに格納されているかの見分け方"><a href="#キーチェーンと-Secure-Enclave-のどちらに格納されているかの見分け方" class="headerlink" title="キーチェーンと Secure Enclave のどちらに格納されているかの見分け方"></a>キーチェーンと Secure Enclave のどちらに格納されているかの見分け方</h2><p>お手元の Intune MDM 登録 + Entra ID へのデバイス登録済みの Apple デバイスがどちらのシナリオで構成されたものであるかを見分ける場合、特徴的な差異として [SCEP デバイス ID 証明書が視認できるかどうか] という見方があります。<br>以下は iOS デバイスの例ですが [設定] - [一般] - [VPN とデバイス管理] から、Intune 登録時にインポートされている Management Profile の詳細を確認する流れです。</p><table><thead><tr><th>Management Profile をタップ</th><th>詳細をタップ</th></tr></thead><tbody><tr><td><img src="/blog/azure-active-directory/Keychain-to-SecureEnclave-for-Apple-device/1-ManagenentProfile.jpg"></td><td><img src="/blog/azure-active-directory/Keychain-to-SecureEnclave-for-Apple-device/2-Shosai.jpg"></td></tr></tbody></table><table><thead><tr><th>SCEP デバイス ID 証明書あり &#x3D; キーチェーン利用</th><th>SCEP デバイス ID 証明書なし &#x3D; Secure Enclave 利用</th></tr></thead><tbody><tr><td><img src="/blog/azure-active-directory/Keychain-to-SecureEnclave-for-Apple-device/3-SCEP-device-Cert-KeyChain.jpg"></td><td><img src="/blog/azure-active-directory/Keychain-to-SecureEnclave-for-Apple-device/4-SCEP-device-Cert-SecureEnclave.jpg"></td></tr></tbody></table><h2 id="この実装変更が展開されるとどのような影響が発生するか"><a href="#この実装変更が展開されるとどのような影響が発生するか" class="headerlink" title="この実装変更が展開されるとどのような影響が発生するか"></a>この実装変更が展開されるとどのような影響が発生するか</h2><p>この実装変更がロールアウトされた後に Intune MDM 登録 + Entra ID へのデバイス登録をしたデバイスの一部のアプリにおいてデバイス ID を提示できなくなります。<br>その結果、条件付きアクセスでデバイス ID の提示を必要とするポリシーを構成している場合に一部アプリでのサインインがブロックされます。</p><h2 id="どのような環境のどのようなアプリが影響を受けるのか"><a href="#どのような環境のどのようなアプリが影響を受けるのか" class="headerlink" title="どのような環境のどのようなアプリが影響を受けるのか"></a>どのような環境のどのようなアプリが影響を受けるのか</h2><p>次のような条件付きアクセス ポリシーを構成している環境で影響が発生する恐れがあります。</p><ul><li><p><a href="https://learn.microsoft.com/ja-jp/entra/identity/conditional-access/concept-condition-filters-for-devices">条件付きアクセス: デバイスのフィルター</a> で紹介しているデバイスのフィルターを判定条件に利用している。</p></li><li><p><a href="https://learn.microsoft.com/ja-jp/entra/identity/conditional-access/concept-conditional-access-grant">条件付きアクセス:Grant</a> で紹介している、デバイスは準拠としてマーク済みである必要がある、承認済みクライアント アプリを必須にする (2026 年 3 月に廃止)、アプリの保護ポリシーを必須にする、といったアクセス制御を利用している。</p></li></ul><p>上記の判定条件やアクセス制御はいずれも <strong>クライアント アプリ&#x2F;ブラウザからの認証要求時に、デバイス ID が Entra ID に提示される</strong> ことで適切に判定を受けることが可能な機能です。<br>つまり、クライアント アプリ&#x2F;ブラウザが認証時にデバイス ID を提示できないと、Entra ID は [どのデバイスからの認証要求であるか] を判定する情報が得られず、未登録デバイスと判定することになります。</p><p>上述の条件付きアクセス ポリシーを構成している環境において、それぞれの OS ごとで動作するアプリケーションへの影響を以下の表にまとめました。</p><h3 id="iOS-の場合"><a href="#iOS-の場合" class="headerlink" title="iOS の場合"></a>iOS の場合</h3><table><thead><tr><th>区分</th><th>説明</th></tr></thead><tbody><tr><td>MSAL 対応アプリ／ブラウザ</td><td>特に対応は不要です。なお、Microsoft の 1st party アプリや Edge ブラウザは MSAL に対応しています。3rd party アプリが MSAL に対応しているかどうかは、アプリ提供元への確認が必要です。</td></tr><tr><td>非 MSAL 対応アプリ／ブラウザ</td><td>Enterprise SSO プラグイン機能を有効にすることで、Secure Enclave に格納されたデバイス ID の取得と認証時の提示が行えるようになります。</td></tr></tbody></table><h3 id="macOS-の場合"><a href="#macOS-の場合" class="headerlink" title="macOS の場合"></a>macOS の場合</h3><table><thead><tr><th>区分</th><th>説明</th></tr></thead><tbody><tr><td>MSAL 対応アプリ／ブラウザ</td><td>Enterprise SSO プラグイン機能を有効にすることで、Secure Enclave に格納されたデバイス ID の取得と認証時の提示が行えるようになります。</td></tr><tr><td>非 MSAL 対応アプリ／ブラウザ</td><td>Enterprise SSO プラグイン機能を有効にすることで、Secure Enclave に格納されたデバイス ID の取得と認証時の提示が行えるようになります。</td></tr></tbody></table><p>※ Platform SSO では Enterprise SSO を利用しているため Secure Enclave に対応しています。</p><h2 id="影響を受けた場合の具体的な例"><a href="#影響を受けた場合の具体的な例" class="headerlink" title="影響を受けた場合の具体的な例"></a>影響を受けた場合の具体的な例</h2><p>ここまでの内容を踏まえて、影響を受けた場合の具体的な例を紹介します。</p><ul><li><p>前提</p><ul><li>ロールアウトが適用された以降に Intune MDM 登録 + Entra ID へのデバイス登録をした iOS デバイス</li><li>Enterprise SSO を有効にする設定を配布していない</li><li>デバイス ID を元にアクセス制御を行う条件付きアクセスのポリシーを構成している</li><li>Safari や 3rd party 製アプリなど MSAL に対応していないアプリ利用時</li></ul></li><li><p>発生しうる事象</p><ul><li>認証時にクライアント側からデバイス ID が提示されず、条件付きアクセスのポリシーに抵触してサインインがブロックされる。</li><li>Edge ブラウザ や 1st party (Microsoft) 製アプリを使用した場合は同様の事象は発生しない。</li><li>ロールアウトが適用される以前にセットアップしたデバイスでは同様の事象は発生しない。</li></ul></li><li><p>事象が発生した際のクライアント上でのエラー表示例<br>以下の例では Safari ブラウザからのアクセス シナリオですが、サインイン時に以下のように 530003 のエラー コードで失敗しています。このエラー コード 530003 は “Your device is required to be managed to access this resource.” を意味しており、つまり MDM 管理されたデバイスからのアクセスではないため “デバイスは準拠としてマーク済みである必要がある” のアクセス制御に抵触したことを示しています。<br>また、”デバイスの識別子” の項目が “使用できません” となっていることもデバイス ID が提示されなかったことを示唆しています。</p></li></ul><p><img src="/blog/azure-active-directory/Keychain-to-SecureEnclave-for-Apple-device/5-Sample-Sign-ins.jpg"></p><p>上記のサインインに呼応する Entra ID のサインイン ログの詳細を参照すると以下のようにデバイス ID の項目がブランクとなっており、この点からもクライアントからデバイス ID が提示されていないことを確認可能です。</p><p><img src="/blog/azure-active-directory/Keychain-to-SecureEnclave-for-Apple-device/6-NoDevice-Sign-ins-EntraID.jpg"></p><p>上記は <a href="https://learn.microsoft.com/ja-jp/entra/identity-platform/apple-sso-plugin">Apple デバイス用の Microsoft Enterprise SSO プラグイン</a> 内の <a href="https://learn.microsoft.com/ja-jp/entra/identity-platform/apple-sso-plugin#troubleshooting-secure-enclave-based-device-identity">セキュリティで保護されたエンクレーブ ベースのデバイス ID のトラブルシューティング</a> の説明が該当します。</p><h2 id="対処方法"><a href="#対処方法" class="headerlink" title="対処方法"></a>対処方法</h2><p>Enterprise SSO プラグインを有効化することで、非 MSAL 対応アプリ&#x2F;ブラウザを利用する際のユーザー認証時にデバイス ID を提示できるようになります。<br>Enterprise SSO 機能を有効化するには、 <a href="https://learn.microsoft.com/ja-jp/intune/intune-service/configuration/use-enterprise-sso-plug-in-ios-ipados-with-intune?tabs=prereq-intune,create-profile-intune">MDM を使用して iOS&#x2F;iPadOS Enterprise SSO アプリ拡張機能を構成する</a> 内の <a href="https://learn.microsoft.com/ja-jp/intune/intune-service/configuration/use-enterprise-sso-plug-in-ios-ipados-with-intune?tabs=prereq-intune,create-profile-intune#create-a-single-sign-on-app-extension-configuration-policy">シングル サインオン アプリ拡張機能構成ポリシーを作成する</a> の手順に沿って Intune にてデバイス構成ポリシーを用いて設定を配布します。</p><p>Safari ブラウザもしくは [認証ブローカーとして Safari WebView を使用する] 3rd party アプリの場合、以下のように Enterprise SSO を有効化することで、デバイス ID を提示できるようになります。<br>[SSO アプリ拡張機能の種類] の設定を “Microsoft Entra ID” にしているのみの設定です。</p><p><img src="/blog/azure-active-directory/Keychain-to-SecureEnclave-for-Apple-device/7-SSO-app-extension-Intune.jpg"></p><p>なお、3rd party アプリが [認証ブローカーとして Safari WebView] を使用しているかどうかは、各アプリの実装に依存するためアプリ提供元までご確認ください。<br>もし MSAL も Safari WebView も認証処理に使用していない 3rd party アプリの場合、該当アプリの [アプリ バンドル ID] を指定することで対応できる可能性はありますが、該当アプリの実装に依存するため Microsoft として確証を持ったご案内ができない点、あらかじめご了承ください。</p><h2 id="よくあるご質問とその回答-FAQ"><a href="#よくあるご質問とその回答-FAQ" class="headerlink" title="よくあるご質問とその回答 (FAQ)"></a>よくあるご質問とその回答 (FAQ)</h2><h3 id="FAQ1"><a href="#FAQ1" class="headerlink" title="FAQ1"></a>FAQ1</h3><p>Q:<br>3rd party アプリの [アプリ バンドル ID] はどのように確認することができますか？</p><p>A:<br>アプリ バンドル ID の正確な情報はアプリのご提供元ベンダー様へご確認ください。<br><a href="https://learn.microsoft.com/ja-jp/entra/identity-platform/apple-sso-plugin#find-app-bundle-identifiers-on-ios-devices">iOS デバイスでのアプリ バンドル ID の確認</a> にも該当のご案内があります。</p><p>その他の簡易的なアプリ バンドル ID の確認方法としては、2026 年 4 月現在では、App Store のアプリ ID を元に、アプリ バンドル ID を確認することが可能であるという情報を確認しています。<br>その手順は次の通りです。</p><p>まずは確認したいアプリの App Store サイトを開きます。例として MSN アプリとします。</p><p>App Store の MSN アプリのサイト<br><a href="https://apps.apple.com/jp/app/msn/id945416273">https://apps.apple.com/jp/app/msn/id945416273</a><br>-&gt;この URL よりアプリ ID が 945416273 であることがわかります。</p><p>続けて、Apple の iTunes の lookup サイトでアプリ ID の数字 945416273 を id&#x3D; で指定した URL を開きます。<br><a href="https://itunes.apple.com/lookup?id=945416273">https://itunes.apple.com/lookup?id=945416273</a></p><p>1.txt というテキストのダウンロードが行われるため、テキストファイルより bundleid 値を検索します。<br>今回の例では [“bundleId”:”com.microsoft.axp-ios.BingNews”] という値であるため、com.microsoft.axp-ios.BingNews が MSN アプリのアプリ バンドル ID であることがわかります。</p><hr><h3 id="FAQ2"><a href="#FAQ2" class="headerlink" title="FAQ2"></a>FAQ2</h3><p>Q:<br>認証ブローカーとは何でしょうか。</p><p>A:<br>認証ブローカーとは、アプリに代わって認証の処理を行うコンポーネントを指します。<br>OS 上で起動するアプリは、認証に関わるやり取りをアプリ自身のプロセス上で実行せず、別のプロセスに委任する (認証に関する処理を任せる) 作りが広く一般的です。<br>これは OS の種類にかかわらず、以下のように言えます。</p><ul><li><p>Windows の場合、Outlook や Teams などの Office (1st party) アプリでは WAM (Web Account Manager) と呼ばれる OS の認証ブローカーに認証の処理を任せる<br>　3rd party アプリの場合、アプリの作りによって WAM に任せる作りのアプリもあれば、Edge WebView に任せる作りのアプリ、自分自身のプロセスで対応する (他プロセスに委任しない) アプリもある</p></li><li><p>iOS の場合、Office (1st party) アプリは、Microsoft Authenticator に認証の処理を任せる<br>　3rd party アプリの場合、アプリの作りによって認証ブローカーである Microsoft Authenticator に任せる作りのアプリもあれば、Safari WebView に任せる作りのアプリ、自分自身のプロセスで対応する (他プロセスに委任しない) アプリもある</p></li><li><p>Android の場合、Office (1st party) アプリは、Intune Company ポータル アプリに認証の処理を任せる<br>　3rd party アプリの場合、アプリの作りによって認証ブローカーである Intune Company ポータル アプリに任せる作りのアプリもあれば、Chrome WebView に任せる作りのアプリ、自分自身のプロセスで対応する (他プロセスに委任しない) アプリもある</p></li></ul><p>上記の Microsoft の認証ブローカーに認証処理を委任できるアプリは、1st &#x2F; 3rd party 製であるかどうかにかかわらず [MSAL (先進認証のライブラリ) に対応したアプリ] という言い方も可能です。</p><hr><h3 id="FAQ3"><a href="#FAQ3" class="headerlink" title="FAQ3"></a>FAQ3</h3><p>Q:<br>Enterprise SSO を有効にすることによる影響はありますか。</p><p>A:<br>Apple の OS に対して Enterprise SSO を有効化することで、Safari の認証処理がアドイン&#x2F;強化される (ブラウザ単位ではなく、デバイスとして保持する認証情報を利用できるようになる) ことになります。<br>そのため、Safari もしくは [Safari WebView を認証ブローカーとする作りのアプリ] がその恩恵を受けることになります。</p><p>そのため [Safari ブラウザ、もしくは認証ブローカーとして Safari WebView を使用する 3rd party アプリの利用時、これまでは対話的な認証画面が表示されて認証操作を行っていたが、Intune に MDM 登録を行っているユーザーとして SSO が行えるようになり、かつ認証時にデバイス ID 情報も提示できるようになる] という影響&#x2F;効果が生じることが期待値となります。</p><p>なお、前述のとおり MSAL も Safari WebView も認証処理に使用していない 3rd party アプリの場合、該当アプリの [アプリ バンドル ID] を指定することで、同様の影響&#x2F;効果を得られる可能性もあります。<br>繰り返しになりますが該当アプリの実装に依存するため Microsoft として Enterprise SSO の効果が得られるかどうかに関して確証を持ったご案内ができない点、あらかじめご了承ください。</p><hr><p>上記内容が皆様の参考となりますと幸いです。どちら様も素敵な Entra ID ライフをお過ごしください。</p>]]>
    </content>
    <id>https://jpazureid.github.io/blog/azure-active-directory/Keychain-to-SecureEnclave-for-Apple-device/</id>
    <link href="https://jpazureid.github.io/blog/azure-active-directory/Keychain-to-SecureEnclave-for-Apple-device/"/>
    <published>2026-04-17T15:00:00.000Z</published>
    <summary>
      <![CDATA[<div class="alert is-info"><p class="alert-title">Note</p><p>2026 年 4 月 30 日更新: 影響範囲について、iOS と Mac デバイスの違いを追記しました。</p></div>
<p>こんにちは、Azure]]>
    </summary>
    <title>Apple デバイスでキーチェーンから Secure Enclave 利用へ</title>
    <updated>2026-08-12T00:07:04.280Z</updated>
  </entry>
  <entry>
    <author>
      <name>Azure Identity Support Japan</name>
    </author>
    <category term="Conditional Access" scheme="https://jpazureid.github.io/blog/tags/Conditional-Access/"/>
    <category term="Microsoft Entra ID" scheme="https://jpazureid.github.io/blog/tags/Microsoft-Entra-ID/"/>
    <category term="Audit Logs" scheme="https://jpazureid.github.io/blog/tags/Audit-Logs/"/>
    <content>
      <![CDATA[<h2 id="はじめに"><a href="#はじめに" class="headerlink" title="はじめに"></a>はじめに</h2><p>こんにちは、Azure Identity サポート チーム Lynn です。<br>条件付きアクセス ポリシーに対して変更を行ったときに記録されるデータ量が多くなる場合、更新操作は 1 回のみであるにもかかわらず、監査ログ上では「Update policy」という同一のアクティビティが、複数件連続して記録されることがあります。<br>この事象が発生すると、Microsoft Entra 管理センター上で個々の監査ログを確認しても、実際にポリシーのどの設定がどのように変更されたのかを判別しにくい状態になります。<br>本記事では、この事象の内容と対処方法について解説します。</p><h2 id="観測される挙動"><a href="#観測される挙動" class="headerlink" title="観測される挙動"></a>観測される挙動</h2><p>例として指定するターゲット リソースが多い条件付きアクセス ポリシーに対して変更を行うと、1 回の更新操作に対して「Update policy」の監査ログが複数件、生成される場合があります。<br>参考までに弊社検証環境における動作として、条件付きアクセスの対象ターゲット リソースを約 480 個指定したうえでターゲット リソースの更新を行ったところ、1 回の更新操作に対して「Update policy」の監査ログが 5 件生成される挙動を確認しました。<br>これらのログは、同一の日時、同一のターゲット、同一の開始者 (アクター) で連続して記録されており、見た目上は「複数回更新が行われた」ように見える点が特徴です。</p><p><img src="/blog/azure-active-directory/long-audit-log-split-behavior/audit-log-screenshot.png"></p><p>しかしながら、これらのログを 1 つずつ確認すると、複数回の更新が行われたのではなく 1 回の更新が複数の監査ログ レコードに分割されて記録されていることに気づきます。<br>このとき、通常は変更内容が表示される「変更されたプロパティ」タブが空で表示されますが、これは変更が行われていないことを示すものではありません。分割された監査ログ レコードを総合して変更内容を確認する必要があります。</p><h2 id="なぜ監査ログが分割されるのか"><a href="#なぜ監査ログが分割されるのか" class="headerlink" title="なぜ監査ログが分割されるのか"></a>なぜ監査ログが分割されるのか</h2><p>通常、条件付きアクセス ポリシーに設定されているターゲット リソースの数が比較的少ない場合には、ポリシー更新時の変更内容は 1 件の監査ログ レコードに記録されます。<br>一方で、条件付きアクセス ポリシーに対して数百件規模のターゲット リソースを指定している場合、更新時に記録されるデータ量 (アプリケーション GUID などを含む JSON データ) が非常に大きくなります。<br>その結果、1 件の監査ログ レコードに記録可能なサイズ上限を超過するため、データが欠落しないよう、システム側で監査ログが自動的に複数件に分割されて記録されます。<br>この挙動は想定された動作であり、また、監査ログの内容そのものが失われているわけではありません。</p><h2 id="分割された監査ログの構造と読み方"><a href="#分割された監査ログの構造と読み方" class="headerlink" title="分割された監査ログの構造と読み方"></a>分割された監査ログの構造と読み方</h2><p>通常、変更内容が比較的少ない場合には、JSON の監査ログ レコードの <code>targetResources</code> 内の <code>modifiedProperties</code> に変更前・変更後の値が直接表示されます。<br>しかし、ターゲット リソースに指定したアプリケーション数が多いなど JSON のデータ量が大きくなる場合、変更内容が <code>modifiedProperties</code> に収まりきらないため、分割されたデータとして <code>additionalDetails</code> 側に記録される挙動に自動で切り替わります。</p><p>分割された監査ログでは、Microsoft Graph API の監査ログ (Audit Logs) における <code>additionalDetails</code> セクションに、以下のような管理用のキーが含まれます。</p><table><thead><tr><th>キー</th><th>意味</th><th>役割</th></tr></thead><tbody><tr><td>id</td><td>相関 ID (Correlation ID)</td><td>分割された複数のログが、同一の操作に属することを示します</td></tr><tr><td>seq</td><td>シーケンス番号</td><td>分割されたデータの何番目の断片かを示します (例：1, 2, 3…)</td></tr><tr><td>b</td><td>データ本体</td><td>分割された JSON データの一部です</td></tr><tr><td>c</td><td>総数</td><td>データが何件に分割されているかを示します</td></tr></tbody></table><p>同一の <code>id</code> を持つログを <code>seq</code> の順番に並べ、それぞれの <code>b</code> の値を順に結合することで、本来 1 回の操作として記録されるべき変更内容を論理的に復元することが可能です。</p><p>以下は、実際に API から取得できる「分割されたログの 1 レコード例」です。</p><div class="alert is-info"><p class="alert-title">Note</p><p>以下の例では説明のために JSON 内にコメントを付与していますが、実際の API レスポンスにコメントは含まれません。</p></div><figure class="highlight json"><table><tr><td class="code"><pre><span class="line"><span class="punctuation">&#123;</span></span><br><span class="line">  <span class="attr">&quot;id&quot;</span><span class="punctuation">:</span> <span class="string">&quot;Directory_xxx_0001&quot;</span><span class="punctuation">,</span></span><br><span class="line">  <span class="attr">&quot;category&quot;</span><span class="punctuation">:</span> <span class="string">&quot;Policy&quot;</span><span class="punctuation">,</span></span><br><span class="line">  <span class="attr">&quot;activityDisplayName&quot;</span><span class="punctuation">:</span> <span class="string">&quot;Update policy&quot;</span><span class="punctuation">,</span></span><br><span class="line">  <span class="attr">&quot;correlationId&quot;</span><span class="punctuation">:</span> <span class="string">&quot;00000000-0000-1234-5678-0000000090ab&quot;</span><span class="punctuation">,</span></span><br><span class="line">  <span class="attr">&quot;activityDateTime&quot;</span><span class="punctuation">:</span> <span class="string">&quot;2026-03-06T06:02:10Z&quot;</span><span class="punctuation">,</span></span><br><span class="line">  <span class="attr">&quot;result&quot;</span><span class="punctuation">:</span> <span class="string">&quot;success&quot;</span><span class="punctuation">,</span></span><br><span class="line"></span><br><span class="line">  <span class="attr">&quot;targetResources&quot;</span><span class="punctuation">:</span> <span class="punctuation">[</span></span><br><span class="line">    <span class="punctuation">&#123;</span></span><br><span class="line">      <span class="attr">&quot;id&quot;</span><span class="punctuation">:</span> <span class="string">&quot;&lt;対象ポリシーの GUID&gt;&quot;</span><span class="punctuation">,</span></span><br><span class="line">      <span class="attr">&quot;displayName&quot;</span><span class="punctuation">:</span> <span class="string">&quot;ExampleConditionalAccessPolicy&quot;</span><span class="punctuation">,</span></span><br><span class="line">      <span class="attr">&quot;type&quot;</span><span class="punctuation">:</span> <span class="string">&quot;Policy&quot;</span><span class="punctuation">,</span></span><br><span class="line">      <span class="attr">&quot;modifiedProperties&quot;</span><span class="punctuation">:</span> <span class="punctuation">[</span><span class="punctuation">]</span></span><br><span class="line">      <span class="comment">// データが大きいため modifiedProperties は空になる</span></span><br><span class="line">    <span class="punctuation">&#125;</span></span><br><span class="line">  <span class="punctuation">]</span><span class="punctuation">,</span></span><br><span class="line"></span><br><span class="line">  <span class="attr">&quot;additionalDetails&quot;</span><span class="punctuation">:</span> <span class="punctuation">[</span></span><br><span class="line">    <span class="punctuation">&#123;</span></span><br><span class="line">      <span class="attr">&quot;key&quot;</span><span class="punctuation">:</span> <span class="string">&quot;id&quot;</span><span class="punctuation">,</span></span><br><span class="line">      <span class="attr">&quot;value&quot;</span><span class="punctuation">:</span> <span class="string">&quot;policy-id-123&quot;</span></span><br><span class="line">      <span class="comment">// 分割された複数のログが、同一の操作に属することを示します</span></span><br><span class="line">    <span class="punctuation">&#125;</span><span class="punctuation">,</span></span><br><span class="line">    <span class="punctuation">&#123;</span></span><br><span class="line">      <span class="attr">&quot;key&quot;</span><span class="punctuation">:</span> <span class="string">&quot;seq&quot;</span><span class="punctuation">,</span></span><br><span class="line">      <span class="attr">&quot;value&quot;</span><span class="punctuation">:</span> <span class="string">&quot;1&quot;</span></span><br><span class="line">      <span class="comment">// 分割ログの順序番号 (同一 &quot;id&quot; 内での位置)</span></span><br><span class="line">    <span class="punctuation">&#125;</span><span class="punctuation">,</span></span><br><span class="line">    <span class="punctuation">&#123;</span></span><br><span class="line">      <span class="attr">&quot;key&quot;</span><span class="punctuation">:</span> <span class="string">&quot;b&quot;</span><span class="punctuation">,</span></span><br><span class="line">      <span class="attr">&quot;value&quot;</span><span class="punctuation">:</span> <span class="string">&quot;&#123; \&quot;Users\&quot;: &#123; \&quot;Include\&quot;: [ &#123; \&quot;Groups\&quot;: [ \&quot;group-id-1\&quot; ] &#125; ],&quot;</span></span><br><span class="line">      <span class="comment">// 実際のポリシー設定 JSON の断片 (文字列) </span></span><br><span class="line">      <span class="comment">// seq 順にすべて結合して初めて意味を持つ</span></span><br><span class="line">    <span class="punctuation">&#125;</span><span class="punctuation">,</span></span><br><span class="line">    <span class="punctuation">&#123;</span></span><br><span class="line">      <span class="attr">&quot;key&quot;</span><span class="punctuation">:</span> <span class="string">&quot;c&quot;</span><span class="punctuation">,</span></span><br><span class="line">      <span class="attr">&quot;value&quot;</span><span class="punctuation">:</span> <span class="string">&quot;5&quot;</span></span><br><span class="line">      <span class="comment">// 重要</span></span><br><span class="line">      <span class="comment">// この操作 (correlationId) で生成された分割ログの総数</span></span><br><span class="line">      <span class="comment">// seq=1 ～ seq=5 が存在することを示す</span></span><br><span class="line">    <span class="punctuation">&#125;</span></span><br><span class="line">  <span class="punctuation">]</span></span><br><span class="line"><span class="punctuation">&#125;</span></span><br></pre></td></tr></table></figure><h2 id="分割された監査ログの確認方法-手動"><a href="#分割された監査ログの確認方法-手動" class="headerlink" title="分割された監査ログの確認方法 (手動)"></a>分割された監査ログの確認方法 (手動)</h2><p>分割された監査ログの内容を確認する一例として、テキスト エディターを用いてデータを結合する方法をご紹介します。</p><ol><li>[Microsoft Entra 管理センター] &gt; [監視と正常性] &gt; [監査ログ] を表示します</li><li>同一の日時、同一のターゲット、同一の開始者 (アクター) で連続して記録されている複数の「Update policy」ログを確認します</li><li>各ログの <code>additionalDetails</code> 内にある <code>b</code> の値を、<code>seq</code> の順にコピーします</li><li>空白や改行を入れずに連結し、1 つの文字列として復元します</li><li>復元したデータを確認し、どのような変更が行われたかを確認します</li></ol><p>この方法により、分割されて記録された変更内容を確認することが可能です。</p><h2 id="分割された監査ログの確認方法-自動化"><a href="#分割された監査ログの確認方法-自動化" class="headerlink" title="分割された監査ログの確認方法 (自動化)"></a>分割された監査ログの確認方法 (自動化)</h2><p>上述した手動での結合作業は、分割数が多い場合には煩雑になるため、調査を補助する目的でスクリプトを用いた自動化についてもご案内いたします。</p><p>分割された監査ログを Microsoft Graph API 経由で自動的に取得・結合し、変更前後の差分を確認する PowerShell スクリプトを以下の GitHub リポジトリにて公開しています。事前準備や実行手順の詳細についてもリポジトリの README に記載しておりますので、併せてご参照ください。</p><div class="alert is-info"><p class="alert-title">Note</p><p>なお、以下のスクリプトでは、条件付きアクセスのターゲットリソースが多い場合の変更に特化した処理を実装しています。</p></div><ul><li><a href="https://github.com/jpazureid/long-audit-log-recovery">Recover split audit logs for Conditional Access policy changes</a></li></ul><h3 id="免責事項"><a href="#免責事項" class="headerlink" title="免責事項"></a>免責事項</h3><p>本サンプル コードは、あくまでも説明のためのサンプルとして提供されるものであり、製品の実運用環境で使用されることを前提に提供されるものではありません。本サンプル コードおよびそれに関連するあらゆる情報は、「現状のまま」で提供されるものであり、商品性や特定の目的への適合性に関する黙示の保証も含め、明示・黙示を問わずいかなる保証も付されるものではありません。マイクロソフトは、お客様に対し、本サンプル コードを使用および改変するための非排他的かつ無償の権利ならびに本サンプル コードをオブジェクト コードの形式で複製および頒布するための非排他的かつ無償の権利を許諾します。但し、お客様は以下の 3 点に同意するものとします。</p><ol><li>本サンプル コードが組み込まれたお客様のソフトウェア製品のマーケティングのためにマイクロソフトの会社名、ロゴまたは商標を用いないこと</li><li>本サンプル コードが組み込まれたお客様のソフトウェア製品に有効な著作権表示をすること</li><li>本サンプル コードの使用または頒布から生じるあらゆる損害 (弁護士費用を含む) に関する請求または訴訟について、マイクロソフトおよびマイクロソフトの取引業者に対し補償し、損害を与えないこと</li></ol><h2 id="まとめ"><a href="#まとめ" class="headerlink" title="まとめ"></a>まとめ</h2><ul><li>条件付きアクセス ポリシー更新時に監査ログが分割されて記録される場合があります</li><li>本挙動は、データ量が大きい場合に発生する想定された動作です</li><li>分割されたログでは、<code>additionalDetails</code> 内の情報を基に内容を確認する必要があります</li><li>単一ログや「変更されたプロパティ」だけで判断しない点にご注意ください</li></ul><p>もしも上記の内容について不明点などある場合には、お客様環境などを十分に把握したうえでサポート部門より提供しますので、ぜひ弊社サポート サービスをご利用ください。</p>]]>
    </content>
    <id>https://jpazureid.github.io/blog/azure-active-directory/long-audit-log-split-behavior/</id>
    <link href="https://jpazureid.github.io/blog/azure-active-directory/long-audit-log-split-behavior/"/>
    <published>2026-04-16T00:00:00.000Z</published>
    <summary>
      <![CDATA[<h2 id="はじめに"><a href="#はじめに" class="headerlink" title="はじめに"></a>はじめに</h2><p>こんにちは、Azure Identity サポート チーム Lynn です。<br>条件付きアクセス ポリシーに対して変更を]]>
    </summary>
    <title>条件付きアクセス ポリシー更新時に「Update policy」の監査ログが分割されて記録される挙動について</title>
    <updated>2026-08-12T00:07:04.801Z</updated>
  </entry>
  <entry>
    <author>
      <name>Azure Identity Support Japan</name>
    </author>
    <category term="Microsoft Entra Connect" scheme="https://jpazureid.github.io/blog/tags/Microsoft-Entra-Connect/"/>
    <content>
      <![CDATA[<p>こんにちは、 Azure Identity サポート チームの新倉です。</p><p>公開情報「Microsoft Entra のリリースとお知らせ」および MC1263280 にて、セキュリティ強化のため 2026 年 7 月からMicrosoft Entra Connect (以下 MEC) のハードマッチの動作が変更されることが通知されました。</p><p>公開情報　<br><a href="https://learn.microsoft.com/ja-jp/entra/fundamentals/whats-new#general-availability---microsoft-entra-connect-security-hardening-to-prevent-user-account-takeover">Microsoft Entra のリリースとお知らせ - 一般提供 - ユーザー アカウントの引き継ぎを防ぐための Microsoft Entra Connect セキュリティ強化</a></p><p>本ブログ記事では、動作の変更点と、変更後のハードマッチの手順をご紹介し、お問い合わせの多いご質問 (FAQ) について Q&amp;A 形式で回答いたします。<br>今後、ハードマッチについてお問い合わせの多いご質問は適宜内容を追記していき、また公開情報では記載されていない点についても補足してまいります。</p><h2 id="1-Microsoft-Entra-Connect-のハードマッチの変更点について"><a href="#1-Microsoft-Entra-Connect-のハードマッチの変更点について" class="headerlink" title="1. Microsoft Entra Connect のハードマッチの変更点について"></a>1. Microsoft Entra Connect のハードマッチの変更点について</h2><h3 id="1-1-2026-年-7-月-1-日以降に変更される点"><a href="#1-1-2026-年-7-月-1-日以降に変更される点" class="headerlink" title="1-1. 2026 年 7 月 1 日以降に変更される点"></a>1-1. 2026 年 7 月 1 日以降に変更される点</h3><p>MEC のハードマッチは、オンプレミス AD から新しいオブジェクトを同期する際、 Microsoft Entra ID 上のアカウントと同期しようとしたオンプレミス AD のアカウントが一致するかを判断する属性として、 sourceAnchor を基に評価する方法を指します。</p><p>今回、2026 年  7 月 1 日以降に予定されている変更では、セキュリティ強化のため、オンプレミス AD から新しいオブジェクトを同期する際に sourceAnchor の属性だけではなく OnPremisesObjectIdentifier 属性の検証が追加され、以下のすべての条件が成り立つ場合にのみハードマッチが成功するように動作が変わります。</p><ul><li>a. Microsoft Entra ID アカウントの ImmutableId と、同期しようとするオンプレミス AD の sourceAnchor が一致する</li><li>b. テナントのプロパティ BlockCloudObjectTakeoverThroughHardMatch が Falseである</li><li><strong>c. 対象の Entra ID アカウントの OnPremisesObjectIdentifier 属性が空である (New)</strong></li></ul><p><strong>これまでは a. b. の条件を満たせばハードマッチが行われていましたが、今回の動作変更によって c. の条件が追加されます。</strong></p><p>一度でもオンプレミス AD からユーザー同期を行うと、 OnPremisesObjectIdentifier 属性には同期元ユーザーの object ID の値が設定されます。オンプレミス AD から新しいオブジェクトを同期する際に今回の動作変更が適用されますので、OnPremisesObjectIdentifier 属性が空である場合にハードマッチが行われます。</p><h3 id="1-2-ハードマッチの動作が変更された後のハードマッチ手順について"><a href="#1-2-ハードマッチの動作が変更された後のハードマッチ手順について" class="headerlink" title="1-2. ハードマッチの動作が変更された後のハードマッチ手順について"></a>1-2. ハードマッチの動作が変更された後のハードマッチ手順について</h3><p>動作変更後もハードマッチを実施するには、 OnPremisesObjectIdentifier 属性が空である必要があるため、管理者が事前に Microsoft Graph API を用いて同期済みユーザーの OnPremisesObjectIdentifier をクリアする必要があります。<br>ハードマッチを利用する際の シナリオをもとに、以下でご説明いたします。</p><p>補足: 本手順では sourceAnchor は MEC で mS-DS-ConsistencyGuid 属性を指定した環境での手順をご案内しております。 mS-DS-ConsistencyGuid 以外の属性を sourceAnchor としている場合は、 sourceAnchor に指定した属性に置き換えてお読みください。</p><h4 id="シナリオ-オンプレミス-AD-の非同期ユーザーと、既存の-Entra-ID-ユーザーを紐づける場合"><a href="#シナリオ-オンプレミス-AD-の非同期ユーザーと、既存の-Entra-ID-ユーザーを紐づける場合" class="headerlink" title="シナリオ: オンプレミス AD の非同期ユーザーと、既存の Entra ID ユーザーを紐づける場合"></a>シナリオ: オンプレミス AD の非同期ユーザーと、既存の Entra ID ユーザーを紐づける場合</h4><p>オンプレミス AD フォレストの移行や出向などの理由により、既存の Entra ID ユーザーに紐づく同期元のオンプレミスユーザーを変更する場合がございます。<br>このシナリオでは、Entra ID にある既存のユーザー A’ について、同期元となっているオンプレミスユーザーをドメイン X にいるユーザー A からドメイン Y にいるユーザー B に交換します。</p><p>変更前:<br>ドメイン X On-prem user A -&gt; Entra ID user A’<br>ドメイン Y On-prem user B</p><p>変更後:<br>ドメイン X On-prem user A<br>ドメイン Y On-prem user B -&gt; Entra ID user A’</p><p>ハードマッチ手順：</p><ol><li>意図しない同期を防ぐため  Entra Connect の <a href="https://learn.microsoft.com/ja-jp/entra/identity/hybrid/connect/how-to-connect-sync-feature-scheduler#disable-the-scheduler">定期同期を無効</a> にします。</li></ol><p>実行する PowerShell :</p><figure class="highlight powershell"><table><tr><td class="code"><pre><span class="line"><span class="built_in">Set-ADSyncScheduler</span> <span class="literal">-SyncCycleEnabled</span> <span class="variable">$false</span></span><br></pre></td></tr></table></figure><ol start="2"><li>Entra ID ユーザー A’ について、ハードマッチを実施できるよう Microsoft Graph API を使って onPremisesObjectIdentifier を null に設定します</li></ol><div class="alert is-info"><p class="alert-title">Note</p><p>onPremisesObjectIdentifier を null に設定する Graph API は Beta バージョンの API でのリリースが先行されます。</p><p>v1.0 の API でのリリース時期は現時点で未定です。</p><p>ユーザー A’ のように同期済みのユーザーでも、SOA を変更することなく onPremisesObjectIdentifier を null にすることができます</p></div><p>必要なアクセス許可:<br>User-OnPremisesSyncBehavior.ReadWrite.All と User.ReadWrite.All</p><p>実行する Graph API :</p><figure class="highlight http"><table><tr><td class="code"><pre><span class="line">PATCH https://graph.microsoft.com/beta/users/&lt;UserId&gt;</span><br><span class="line">&#123; onPremisesObjectIdentifier: null &#125;</span><br></pre></td></tr></table></figure><p>Microsoft Graph PowerShell の場合の例 :</p><figure class="highlight powershell"><table><tr><td class="code"><pre><span class="line"><span class="built_in">Connect-MgGraph</span>  <span class="literal">-Scopes</span> <span class="string">&#x27;User-OnPremisesSyncBehavior.ReadWrite.All&#x27;</span>,<span class="string">&#x27;User.ReadWrite.All&#x27;</span> <span class="literal">-TenantId</span>  contoso.onmicrosoft.com</span><br><span class="line"><span class="built_in">Invoke-MgGraphRequest</span> <span class="literal">-Method</span> GET <span class="literal">-Uri</span> <span class="string">&quot;https://graph.microsoft.com/beta/users/12345678-2468-adcd-dcba-1234567890ab&quot;</span></span><br><span class="line"><span class="built_in">Invoke-MgGraphRequest</span> <span class="literal">-Method</span> PATCH <span class="literal">-Uri</span> <span class="string">&quot;https://graph.microsoft.com/beta/users/12345678-2468-abcd-dcba-1234567890ab&quot;</span> <span class="literal">-Body</span> <span class="string">&#x27;&#123;&quot;onPremisesObjectIdentifier&quot;: null &#125;&#x27;</span></span><br></pre></td></tr></table></figure><ol start="3"><li>オンプレミスユーザー B を同期対象外の OU に配置し、mS-DS-ConsistencyGuid 属性を、オンプレミスユーザー A の mS-DS-ConsistencyGuid 属性と同じ値になるよう設定します</li></ol><p>なお、同期対象外の OU は、MEC の構成ウィザードの <a href="https://learn.microsoft.com/ja-jp/entra/identity/hybrid/connect/how-to-connect-install-custom#domain-and-ou-filtering">ドメインと OU のフィルター処理</a> であらかじめ用意しておきます。</p><ol start="4"><li><p>オンプレミスユーザー A を同期対象外 OU に移動します。</p></li><li><p><a href="https://learn.microsoft.com/ja-jp/entra/identity/hybrid/connect/how-to-connect-sync-feature-scheduler#delta-sync-cycle">差分同期</a> を 2 回実行し、 MEC 並びに Entra ID ユーザー A’ を Entra ID 上から削除します。 Entra ID ユーザー A’ は「削除済みユーザー」となります</p></li></ol><p>実行する PowerShell :</p><figure class="highlight powershell"><table><tr><td class="code"><pre><span class="line"><span class="built_in">Start-ADSyncSyncCycle</span> delta</span><br></pre></td></tr></table></figure><ol start="6"><li><p>オンプレミスユーザー B を同期対象の OU に移動します</p></li><li><p>差分同期を実行し、Entra ID ユーザー A’ にオンプレミスユーザー B の情報を同期します</p></li></ol><p>実行する PowerShell :</p><figure class="highlight powershell"><table><tr><td class="code"><pre><span class="line"><span class="built_in">Start-ADSyncSyncCycle</span> delta</span><br></pre></td></tr></table></figure><ol start="8"><li><p>ハードマッチが行われ、Entra ID ユーザー A’ とオンプレミスユーザー B が紐づき、以後はオンプレミスユーザー B の変更内容が Entra ID ユーザー A’ に同期されるようになります</p></li><li><p>Entra Connect の定期同期を有効に戻します。</p></li></ol><p>実行する PowerShell :</p><figure class="highlight powershell"><table><tr><td class="code"><pre><span class="line"><span class="built_in">Set-ADSyncScheduler</span> <span class="literal">-SyncCycleEnabled</span> <span class="variable">$true</span></span><br></pre></td></tr></table></figure><h2 id="2-ハードマッチの動作の変更点についてのよくあるご質問とその回答-FAQ"><a href="#2-ハードマッチの動作の変更点についてのよくあるご質問とその回答-FAQ" class="headerlink" title="2.ハードマッチの動作の変更点についてのよくあるご質問とその回答 (FAQ)"></a>2.ハードマッチの動作の変更点についてのよくあるご質問とその回答 (FAQ)</h2><p>今回のハードマッチの動作変更について、以下によくあるご質問をおまとめしております。</p><hr><h3 id="Q-この変更は特定のバージョンの-MEC-でのみ有効になりますか？それとも古いバージョンにも適用されますか？"><a href="#Q-この変更は特定のバージョンの-MEC-でのみ有効になりますか？それとも古いバージョンにも適用されますか？" class="headerlink" title="Q: この変更は特定のバージョンの MEC でのみ有効になりますか？それとも古いバージョンにも適用されますか？"></a><span style="color: blue; ">Q:</span> この変更は特定のバージョンの MEC でのみ有効になりますか？それとも古いバージョンにも適用されますか？</h3><p><span style="color: red; ">A:</span><br>今回の変更は Microsoft Entra ID のサービス側で行われる変更となり、OnPremisesObjectIdentifier 属性の検証はハードマッチ操作時にサービス側で実施されるため、MEC のバージョンには依存しません。<br>特に MEC のアップグレードは必要なく、2026 年  7 月 1 日以降、全てのサポートされている MEC バージョンに適用されます。</p><hr><h3 id="Q-OnPremisesObjectIdentifier-属性が空であるかを検証してハードマッチする新しい動作を停止することはできますか？"><a href="#Q-OnPremisesObjectIdentifier-属性が空であるかを検証してハードマッチする新しい動作を停止することはできますか？" class="headerlink" title="Q: OnPremisesObjectIdentifier 属性が空であるかを検証してハードマッチする新しい動作を停止することはできますか？"></a><span style="color: blue; ">Q:</span> OnPremisesObjectIdentifier 属性が空であるかを検証してハードマッチする新しい動作を停止することはできますか？</h3><p><span style="color: red; ">A:</span><br>いいえ、ハードマッチを検証する新しい動作を停止することはできません。</p><hr><h3 id="Q-この変更はいつから各テナントに適用されますか？"><a href="#Q-この変更はいつから各テナントに適用されますか？" class="headerlink" title="Q: この変更はいつから各テナントに適用されますか？"></a><span style="color: blue; ">Q:</span> この変更はいつから各テナントに適用されますか？</h3><p><span style="color: red; ">A:</span><br>2026 年 7 月 1 日から段階的に各テナントに適用されます。各テナントでの具体的な日程については公開されておりません。</p><hr><h3 id="Q-以下の公開情報で、ハード-マッチの引き継ぎを無効にするための推奨フラグとありますが、フラグとは何ですか？"><a href="#Q-以下の公開情報で、ハード-マッチの引き継ぎを無効にするための推奨フラグとありますが、フラグとは何ですか？" class="headerlink" title="Q: 以下の公開情報で、ハード マッチの引き継ぎを無効にするための推奨フラグとありますが、フラグとは何ですか？"></a><span style="color: blue; ">Q:</span> 以下の公開情報で、ハード マッチの引き継ぎを無効にするための推奨フラグとありますが、フラグとは何ですか？</h3><p><a href="https://learn.microsoft.com/ja-jp/entra/fundamentals/whats-new#general-availability---microsoft-entra-connect-security-hardening-to-prevent-user-account-takeover">一般提供 - ユーザー アカウントの引き継ぎを防ぐための Microsoft Entra Connect セキュリティ強化</a></p><p><span style="color: red; ">A:</span><br>テナントのプロパティ BlockCloudObjectTakeoverThroughHardMatch を指します。<br>これはハードマッチを無効化するフラグで、以前から存在する設定であり、既定で ハードマッチを許可する設定 (False) となっています。<br>今後はセキュリティ強化のため、通常時はハードマッチをブロックする設定 (True) に変更しておくことが推奨されます。<br>ただし、新しいユーザーとハードマッチで同期する際は、このフラグを False にする必要があります。</p><hr><h3 id="Q-BlockCloudObjectTakeoverThroughHardMatch-の現在の設定を確認する方法を教えてください。"><a href="#Q-BlockCloudObjectTakeoverThroughHardMatch-の現在の設定を確認する方法を教えてください。" class="headerlink" title="Q: BlockCloudObjectTakeoverThroughHardMatch の現在の設定を確認する方法を教えてください。"></a><span style="color: blue; ">Q:</span> BlockCloudObjectTakeoverThroughHardMatch の現在の設定を確認する方法を教えてください。</h3><p><span style="color: red; ">A:</span><br>以下のコマンドで確認が可能です。</p><figure class="highlight powershell"><table><tr><td class="code"><pre><span class="line"><span class="built_in">Connect-MgGraph</span> <span class="literal">-Scopes</span> <span class="string">&quot;OnPremDirectorySynchronization.Read.All&quot;</span></span><br><span class="line">(<span class="built_in">Get-MgBetaDirectoryOnPremiseSynchronization</span>).Features |<span class="built_in">select</span> BlockCloudObjectTakeoverThroughHardMatchEnabled</span><br></pre></td></tr></table></figure><p>なお、BlockCloudObjectTakeoverThroughHardMatch の設定を変更する際には以下のようなコマンドで変更することが可能です。(以下の例では BlockCloudObjectTakeoverThroughHardMatch を false に設定しています)</p><figure class="highlight powershell"><table><tr><td class="code"><pre><span class="line"><span class="built_in">Connect-MgGraph</span> <span class="literal">-Scopes</span> <span class="string">&quot;OnPremDirectorySynchronization.ReadWrite.All&quot;</span></span><br><span class="line"><span class="variable">$sync</span> = <span class="built_in">Get-MgBetaDirectoryOnPremiseSynchronization</span> | <span class="built_in">Select-Object</span> <span class="literal">-First</span> <span class="number">1</span></span><br><span class="line"><span class="built_in">Update-MgBetaDirectoryOnPremiseSynchronization</span> <span class="literal">-OnPremisesDirectorySynchronizationId</span> <span class="variable">$sync</span>.Id <span class="literal">-BodyParameter</span> <span class="selector-tag">@</span>&#123;features=<span class="selector-tag">@</span>&#123;blockCloudObjectTakeoverThroughHardMatchEnabled=<span class="variable">$false</span>&#125;&#125;</span><br></pre></td></tr></table></figure><p>参考：<br><a href="https://learn.microsoft.com/ja-jp/graph/api/onpremisesdirectorysynchronization-get?view=graph-rest-1.0&tabs=powershell">Get onPremisesDirectorySynchronization - Microsoft Graph v1.0 | Microsoft Learn</a></p><p><a href="https://learn.microsoft.com/en-us/powershell/module/microsoft.entra.directorymanagement/get-entradirsyncfeature?view=entra-powershell">Get-EntraDirSyncFeature (Microsoft.Entra.DirectoryManagement) | Microsoft Learn</a></p><hr><h3 id="Q-OnPremisesObjectIdentifier-属性が同期されていないユーザーには今回の変更は影響ありませんか？"><a href="#Q-OnPremisesObjectIdentifier-属性が同期されていないユーザーには今回の変更は影響ありませんか？" class="headerlink" title="Q: OnPremisesObjectIdentifier 属性が同期されていないユーザーには今回の変更は影響ありませんか？"></a><span style="color: blue; ">Q:</span> OnPremisesObjectIdentifier 属性が同期されていないユーザーには今回の変更は影響ありませんか？</h3><p><span style="color: red; ">A:</span><br>はい、OnPremisesObjectIdentifier 属性が同期されていないユーザーに影響はありません。</p><hr><h3 id="Q-以前にハードマッチで同期されていたユーザーについて、今回の動作変更の影響はありますか？"><a href="#Q-以前にハードマッチで同期されていたユーザーについて、今回の動作変更の影響はありますか？" class="headerlink" title="Q: 以前にハードマッチで同期されていたユーザーについて、今回の動作変更の影響はありますか？"></a><span style="color: blue; ">Q:</span> 以前にハードマッチで同期されていたユーザーについて、今回の動作変更の影響はありますか？</h3><p><span style="color: red; ">A:</span><br>この変更はハードマッチの実行時に評価されるため、既にハードマッチで同期済みのユーザーには影響はありません。</p><hr><h3 id="Q-2026-年-7-月以降のロールアウト後も、BlockCloudObjectTakeoverThroughHardMatch-を-True-に設定することは可能ですか？"><a href="#Q-2026-年-7-月以降のロールアウト後も、BlockCloudObjectTakeoverThroughHardMatch-を-True-に設定することは可能ですか？" class="headerlink" title="Q: 2026 年 7 月以降のロールアウト後も、BlockCloudObjectTakeoverThroughHardMatch を True に設定することは可能ですか？"></a><span style="color: blue; ">Q:</span> 2026 年 7 月以降のロールアウト後も、BlockCloudObjectTakeoverThroughHardMatch を True に設定することは可能ですか？</h3><p><span style="color: red; ">A:</span><br>はい、可能です。</p><hr><h3 id="Q-サポートブログ-ハードマッチによる同期ユーザーの切り替え方法-AD-フォレスト移行-編-Japan-Azure-Identity-Support-Blog-の手順は変更されますか？"><a href="#Q-サポートブログ-ハードマッチによる同期ユーザーの切り替え方法-AD-フォレスト移行-編-Japan-Azure-Identity-Support-Blog-の手順は変更されますか？" class="headerlink" title="Q: サポートブログ ハードマッチによる同期ユーザーの切り替え方法 (AD フォレスト移行 編) | Japan Azure Identity Support Blog の手順は変更されますか？"></a><span style="color: blue; ">Q:</span> サポートブログ <a href="https://jpazureid.github.io/blog/azure-active-directory-connect/aadc_hardmatch/">ハードマッチによる同期ユーザーの切り替え方法 (AD フォレスト移行 編) | Japan Azure Identity Support Blog</a> の手順は変更されますか？</h3><p><span style="color: red; ">A:</span><br>はい、この手順も同様に OnPremisesObjectIdentifier 属性を空にする必要がありますので、その点を追記する予定です。</p><hr><h3 id="Q-ハードマッチによって同期元が切り替わったユーザーを確認する方法はありますか？"><a href="#Q-ハードマッチによって同期元が切り替わったユーザーを確認する方法はありますか？" class="headerlink" title="Q: ハードマッチによって同期元が切り替わったユーザーを確認する方法はありますか？"></a><span style="color: blue; ">Q:</span> ハードマッチによって同期元が切り替わったユーザーを確認する方法はありますか？</h3><p><span style="color: red; ">A:</span><br>いいえ、確認することはできません。</p><p>ただしハードマッチによって同期元が変わったかを判断する一助となる方法として、 sourceAnchor を mS-DS-ConsistencyGUID としている場合に限定されますが、クラウドに同期されたユーザーの sourceAnchor と onPremisesObjectIdentifier を確認する方法が挙げられます。</p><p>mS-DS-ConsistencyGUID を sourceAnchor としている場合、 mS-DS-ConsistencyGUID が Null の状態で同期を行うとオンプレミスの Object Guid を基に sourceAnchor が生成され、生成された sourceAnchor が mS-DS-ConsistencyGUID にライトバックされます。</p><p>そのため、 mS-DS-ConsistencyGUID に意図的に別の値を入力した状態で同期しない限りは mS-DS-ConsistencyGUID と onPremisesObjectIdentifier は一致します。一致しない場合は、ハードマッチを用いた可能性があると判断可能です。</p><hr><h3 id="Q-以下のような-MC-が通知されました。本ブログでは管理者ユーザーのハードマッチについて言及がありませんが、この-MC1262584-は本ブログと関連がありますか？"><a href="#Q-以下のような-MC-が通知されました。本ブログでは管理者ユーザーのハードマッチについて言及がありませんが、この-MC1262584-は本ブログと関連がありますか？" class="headerlink" title="Q: 以下のような MC が通知されました。本ブログでは管理者ユーザーのハードマッチについて言及がありませんが、この MC1262584 は本ブログと関連がありますか？"></a><span style="color: blue; ">Q:</span> 以下のような MC が通知されました。本ブログでは管理者ユーザーのハードマッチについて言及がありませんが、この MC1262584 は本ブログと関連がありますか？</h3><p>MC1262584<br>Upcoming change – Microsoft Entra Connect security update to block hard match for users with Microsoft Entra roles</p><p><span style="color: red; ">A:</span><br>MC1262584 は、管理者ロールを持つクラウドユーザーを標的としたハードマッチの試みをブロックするというもので、本ブログの内容とは別の通知となります。</p><hr><h2 id="3-参考資料"><a href="#3-参考資料" class="headerlink" title="3.参考資料"></a>3.参考資料</h2><p><a href="https://learn.microsoft.com/ja-jp/entra/fundamentals/whats-new#general-availability---microsoft-entra-connect-security-hardening-to-prevent-user-account-takeover">一般提供 - ユーザー アカウントの引き継ぎを防ぐための Microsoft Entra Connect セキュリティ強化</a></p><p><a href="https://learn.microsoft.com/ja-jp/entra/identity/hybrid/connect/how-to-connect-install-existing-tenant">マッチングおよびハードマッチについて - Microsoft Entra Connect: 既存のテナントがある場合</a></p><p><a href="https://jpazureid.github.io/blog/azure-active-directory-connect/upn-hard-match/">ハードマッチによる Azure AD (Office 365) 上のユーザーをオンプレミス Active Directory ユーザーと紐付ける方法</a></p><p><a href="https://jpazureid.github.io/blog/azure-active-directory-connect/aadc_hardmatch/">ハードマッチによる同期ユーザーの切り替え方法 (AD フォレスト移行 編) | Japan Azure Identity Support Blog</a></p><p><a href="https://learn.microsoft.com/ja-jp/graph/api/onpremisesdirectorysynchronization-get?view=graph-rest-1.0&tabs=powershell">Get onPremisesDirectorySynchronization - Microsoft Graph v1.0 | Microsoft Learn</a></p><p><a href="https://learn.microsoft.com/en-us/powershell/module/microsoft.entra.directorymanagement/get-entradirsyncfeature?view=entra-powershell">Get-EntraDirSyncFeature (Microsoft.Entra.DirectoryManagement) | Microsoft Learn</a></p>]]>
    </content>
    <id>https://jpazureid.github.io/blog/azure-active-directory-connect/hardmatch-security-hardening/</id>
    <link href="https://jpazureid.github.io/blog/azure-active-directory-connect/hardmatch-security-hardening/"/>
    <published>2026-03-30T03:00:00.000Z</published>
    <summary>
      <![CDATA[<p>こんにちは、 Azure Identity サポート チームの新倉です。</p>
<p>公開情報「Microsoft Entra のリリースとお知らせ」および MC1263280 にて、セキュリティ強化のため 2026 年 7 月からMicrosoft Entra Conn]]>
    </summary>
    <title>Microsoft Entra Connect のハードマッチの動作変更について</title>
    <updated>2026-08-12T00:07:04.153Z</updated>
  </entry>
  <entry>
    <author>
      <name>Azure Identity Support Japan</name>
    </author>
    <category term="Conditional Access" scheme="https://jpazureid.github.io/blog/tags/Conditional-Access/"/>
    <category term="Microsoft Entra ID" scheme="https://jpazureid.github.io/blog/tags/Microsoft-Entra-ID/"/>
    <category term="US Identity Blog" scheme="https://jpazureid.github.io/blog/tags/US-Identity-Blog/"/>
    <content>
      <![CDATA[<p>こんにちは、Azure &amp; Identity サポート チームの長谷川です。本記事は、2026 年 1 月 28 日に米国の Microsoft Entra Blog で公開された <a href="https://techcommunity.microsoft.com/blog/microsoft-entra-blog/upcoming-conditional-access-change-improved-enforcement-for-policies-with-resour/4488925">Upcoming Conditional Access change: Improved enforcement for policies with resource exclusions</a> を意訳したものになります。ご不明点はサポート チームまでお問い合わせください。</p><div class="alert is-info"><p class="alert-title">Note</p><p>2026&#x2F;03&#x2F;18 更新: 原文が更新された点を反映しました。展開開始日が 2026 年 3 月 27 日から 2026 年 5 月 13 日に変更されました。</p><p>2026&#x2F;05&#x2F;19 更新: 原文が更新された点を反映しました。展開開始日が 2026 年 5 月 13 日から 2026 年 6 月 15 日に変更されました。</p></div><hr><h2 id="Microsoft-Entra-条件付きアクセスが適用される認証フローを限定的に強化し、セキュリティ態勢の向上を図ります。"><a href="#Microsoft-Entra-条件付きアクセスが適用される認証フローを限定的に強化し、セキュリティ態勢の向上を図ります。" class="headerlink" title="Microsoft Entra 条件付きアクセスが適用される認証フローを限定的に強化し、セキュリティ態勢の向上を図ります。"></a>Microsoft Entra 条件付きアクセスが適用される認証フローを限定的に強化し、セキュリティ態勢の向上を図ります。</h2><p><a href="https://www.microsoft.com/ja-jp/trust-center/security/secure-future-initiative?msockid=22346ecb805f631739b27a6e81726266">Microsoft セキュア フューチャー イニシアティブ</a> に基づき、多層防御のための以下のプロアクティブなセキュリティ対策を実施します。変更内容を確認し、必要な準備を実施ください。</p><h2 id="何が変更されるのか"><a href="#何が変更されるのか" class="headerlink" title="何が変更されるのか"></a>何が変更されるのか</h2><ul><li><strong>現在</strong>、クライアント アプリケーションが <a href="https://learn.microsoft.com/ja-jp/entra/identity-platform/scopes-oidc#openid-connect-scopes">OIDC スコープ</a> または <a href="https://learn.microsoft.com/ja-jp/entra/identity/conditional-access/concept-conditional-access-cloud-apps?tabs=powershell#legacy-conditional-access-behavior-when-an-all-resources-policy-has-a-resource-exclusion">限定的なディレクトリ スコープ</a> <strong>のみ</strong> を要求してユーザーがサインインした場合、<strong>ポリシーに 1 つ以上の除外となるリソースが含まれていると</strong>、「すべてのリソース」を対象とする条件付きアクセス ポリシーは、そのサインインに対して適用されません。</li><li>この変更後は、リソースの除外が設定されている場合でも、これらのサインインに対して「すべてのリソース」を対象とする条件付きアクセスポリシーが適用されます。これにより、アプリケーションによって要求されたスコープに関係なく、ポリシーが一貫して適用されるようになります。<a href="https://learn.microsoft.com/ja-jp/entra/identity/conditional-access/concept-conditional-access-cloud-apps?tabs=usage-and-insights-report#new-conditional-access-behavior-when-an-all-resources-policy-has-a-resource-exclusion">この変更の詳細についてはこちらをご覧ください</a>。</li></ul><h2 id="この変更はいつ反映されるか"><a href="#この変更はいつ反映されるか" class="headerlink" title="この変更はいつ反映されるか"></a>この変更はいつ反映されるか</h2><p>展開スケジュールが調整され、展開は 2026 年 6 月 15 日から開始されます。円滑な移行を支援するため、<strong>Microsoft 365 メッセージセンター</strong>のメッセージを通じて追加情報やガイダンスが提供されます。</p><h2 id="この変更の影響を受けるのは誰か"><a href="#この変更の影響を受けるのは誰か" class="headerlink" title="この変更の影響を受けるのは誰か"></a>この変更の影響を受けるのは誰か</h2><p>この変更は、<a href="https://learn.microsoft.com/ja-jp/entra/identity/conditional-access/concept-conditional-access-cloud-apps?tabs=powershell#legacy-conditional-access-behavior-when-an-all-resources-policy-has-a-resource-exclusion">「すべてのリソース」を対象とし、かつ 1 つ以上のリソース除外を含む</a> 条件付きアクセス ポリシーを設定しているテナントにのみ影響します。これらのテナントには、<a href="https://learn.microsoft.com/ja-jp/microsoft-365/admin/manage/message-center?view=o365-worldwide">M365 メッセージセンター</a> を通じて通知が行われます。この構成のポリシーを持たないテナントには影響はありません。</p><h2 id="この変更はお客様の組織にどのような影響を与えるか"><a href="#この変更はお客様の組織にどのような影響を与えるか" class="headerlink" title="この変更はお客様の組織にどのような影響を与えるか"></a>この変更はお客様の組織にどのような影響を与えるか</h2><p>ユーザーが上記のスコープのみを要求するクライアント アプリケーションを通じてサインインする場合、これまでは適用されずにアクセスできていた状況でも、今回の変更により条件付きアクセスのチャレンジ（MFA やデバイス準拠など）が求められる可能性があります。具体的にどのような制御が要求されるかは、「すべてのリソース」を対象とするポリシー、またはリソースとして Azure AD Graph を明示的に対象とするポリシーに設定されているアクセス制御の内容に依存します。</p><h2 id="何を準備する必要があるか"><a href="#何を準備する必要があるか" class="headerlink" title="何を準備する必要があるか"></a>何を準備する必要があるか</h2><h4 id="ほとんどのお客様-特に対応は不要です"><a href="#ほとんどのお客様-特に対応は不要です" class="headerlink" title="ほとんどのお客様: 特に対応は不要です"></a>ほとんどのお客様: 特に対応は不要です</h4><p>ほとんどのアプリケーションは、上記のスコープ以外に追加のスコープを要求しており、すでに条件付きアクセスの適用対象となっています。このような場合、動作に変更はありません。また、アプリケーションが条件付きアクセスの要求を適切に処理できるようにするため、更新が必要となる可能性がある主要なソフトウェア ベンダーと協力して対応を進めています。</p><h4 id="テナントに登録されていて、これらのスコープのみを要求するアプリ-確認を推奨"><a href="#テナントに登録されていて、これらのスコープのみを要求するアプリ-確認を推奨" class="headerlink" title="テナントに登録されていて、これらのスコープのみを要求するアプリ: 確認を推奨"></a>テナントに登録されていて、これらのスコープのみを要求するアプリ: 確認を推奨</h4><p>上記のスコープ <strong>のみ</strong> を要求するよう意図的に設計されたカスタム アプリケーションがある場合、それらのアプリが MFA やデバイス準拠などの条件付きアクセスの制御に対応できるかどうかを評価ください。<strong>すでに条件付きアクセスの制御に対応している場合</strong> は特に変更は不要です。<strong>対応していない場合は</strong> 更新が必要になる可能性があります。アプリケーションを適切に更新する方法については、<a href="https://learn.microsoft.com/ja-jp/entra/identity-platform/v2-conditional-access-dev-guide">Microsoft Entra 条件付きアクセスの開発者向けガイダンス</a> を参照ください。</p><p>-Swaroop Krishnamurthy</p><h2 id="補足リソース"><a href="#補足リソース" class="headerlink" title="補足リソース"></a>補足リソース</h2><ul><li><a href="https://learn.microsoft.com/ja-jp/entra/identity/conditional-access/concept-conditional-access-cloud-apps">条件付きアクセス: ターゲット リソース</a> </li><li><a href="https://learn.microsoft.com/ja-jp/entra/identity-platform/v2-conditional-access-dev-guide">Microsoft Entra 条件付きアクセスの開発者向けガイダンス</a></li><li><a href="https://learn.microsoft.com/ja-jp/entra/identity-platform/scopes-oidc">Microsoft ID プラットフォームでのスコープとアクセス許可</a></li><li><a href="https://learn.microsoft.com/ja-jp/entra/identity/conditional-access/troubleshoot-conditional-access#audience-reporting">条件付きアクセスでのサインインに関する問題のトラブルシューティング</a></li><li></li></ul>]]>
    </content>
    <id>https://jpazureid.github.io/blog/azure-active-directory/upcoming-conditional-access-change-improved-enforcement-for-policies-with-resour/</id>
    <link href="https://jpazureid.github.io/blog/azure-active-directory/upcoming-conditional-access-change-improved-enforcement-for-policies-with-resour/"/>
    <published>2026-02-19T00:00:00.000Z</published>
    <summary>
      <![CDATA[<p>こんにちは、Azure &amp; Identity サポート チームの長谷川です。本記事は、2026 年 1 月 28 日に米国の Microsoft Entra Blog で公開された <a href="https://techcommunity.microsoft.c]]>
    </summary>
    <title>今後の条件付きアクセスの変更 リソース除外を含むポリシーの適用強化</title>
    <updated>2026-08-12T00:07:05.340Z</updated>
  </entry>
  <entry>
    <author>
      <name>Azure Identity Support Japan</name>
    </author>
    <category term="Microsoft Entra ID" scheme="https://jpazureid.github.io/blog/tags/Microsoft-Entra-ID/"/>
    <category term="Windows Hello for Business" scheme="https://jpazureid.github.io/blog/tags/Windows-Hello-for-Business/"/>
    <content>
      <![CDATA[<p>こんにちは、Azure &amp; Identity サポート チームの長谷川です。今回は certutil -deletehellocontainer コマンド実行時の注意点について説明します。</p><h2 id="説明"><a href="#説明" class="headerlink" title="説明"></a>説明</h2><p>最新の Windows 11 では certutil -deletehellocontainer コマンドを実行すると Windows Hello for Business だけでなくその Windows 上に保存されたパスキーもクリアされます。<br>このため、その Windows 11 上に Windows Hello for Business 以外のパスキーを保存している場合は、certutil -deletehellocontainer コマンド実行前に他のデバイスでパスキーをセットアップしておくなどして、その Windows 上でパスキーがクリアされた後もそのアカウントでサインインできるように準備してください。</p><p>certutil -deletehellocontainer コマンドはこれまで、 <a href="/blog/azure-active-directory/how-to-disable-whfb/">既にプロビジョニングされた Windows Hello for Business をリセットする方法</a> として利用されていました。<br>certutil -deletehellocontainer コマンドは Windows Hello for Business のプロビジョニングによって作成されたキー情報が保存されるコンテナ空間をクリアするコマンドです。<br>最新の Windows 11 ではこのコンテナ空間にパスキーも保存されるようになりました。<br>このため certutil -deletehellocontainer コマンドでこのコンテナ空間をクリアすると、Windows Hello for Business だけでなくその Windows 11 上に保存されたパスキーもクリアされることになるという仕組みです。<br>よって certutil -deletehellocontainer コマンドを実行する際には事前準備が必要という流れになります。</p><h2 id="補足"><a href="#補足" class="headerlink" title="補足"></a>補足</h2><p>その Windows 11 上に保存されているパスキーは「スタート」 &gt; 「設定」 &gt; 「アカウント」 &gt; 「パスキー」で確認することができます。<br>(下図では一番上にリストされている ***.onmicrosoft.com が Windows Hello for Business の情報で、残りの 2 つが他のサイトで作成したパスキーです。)<br><img src="/blog/azure-active-directory/certutil-deletehellocontainer/certutil-deletehellocontainer1.jpg" alt="Windows 上に保存されたパスキーの確認画面"></p><h2 id="おわりに"><a href="#おわりに" class="headerlink" title="おわりに"></a>おわりに</h2><p>certutil -deletehellocontainer コマンドはトラブル解消のためなどに利用されるコマンドです。このコマンドが更なるトラブルを起こさないよう上記を参考にしてください。<br>製品動作に関する正式な見解や回答については、お客様環境などを十分に把握したうえでサポート部門より提供しますので、ぜひ弊社サポート サービスをご利用ください。</p>]]>
    </content>
    <id>https://jpazureid.github.io/blog/azure-active-directory/certutil-deletehellocontainer/</id>
    <link href="https://jpazureid.github.io/blog/azure-active-directory/certutil-deletehellocontainer/"/>
    <published>2026-02-18T00:00:00.000Z</published>
    <summary>
      <![CDATA[<p>こんにちは、Azure &amp; Identity サポート チームの長谷川です。今回は certutil -deletehellocontainer コマンド実行時の注意点について説明します。</p>
<h2 id="説明"><a href="#説明" class="h]]>
    </summary>
    <title>certutil -deletehellocontainer コマンド実行時の注意点</title>
    <updated>2026-08-12T00:07:04.461Z</updated>
  </entry>
  <entry>
    <author>
      <name>Azure Identity Support Japan</name>
    </author>
    <category term="Microsoft Entra" scheme="https://jpazureid.github.io/blog/tags/Microsoft-Entra/"/>
    <category term="Device" scheme="https://jpazureid.github.io/blog/tags/Device/"/>
    <category term="Windows LAPS" scheme="https://jpazureid.github.io/blog/tags/Windows-LAPS/"/>
    <content>
      <![CDATA[<p>こんにちは、Azure &amp; Identity サポート チームの長谷川です。今回は Microsoft Entra ID にローカル管理者パスワードがバックアップされているデバイス一覧を取得する方法のサンプルを紹介します。</p><p>Windows LAPS の機能を利用すると、Microsoft Entra 参加済みデバイスと Microsoft Entra ハイブリッド参加済みデバイスのローカル管理者アカウントとそのパスワード情報を Entra ID 上に保存することができます。この Entra ID 上に保存したローカル管理者アカウントの情報は、管理者が Entra 管理センター上でデバイスごとに確認することができます。しかしながら、Entra 管理センター上では一覧としてダウンロードする機能は実装されておりません。そこで、Microsoft Graph PowerShell モジュールのコマンドを使用して Microsoft Entra ID にローカル管理者パスワードがバックアップされているデバイス一覧を CSV に出力する方法のサンプルを紹介します。</p><p>サンプルでは、CSV にローカル管理者アカウントとパスワードを含めた出力方法と含めない出力方法の二種類を紹介します。</p><h2 id="CSV-にローカル管理者アカウントとパスワードを含めた出力方法サンプル"><a href="#CSV-にローカル管理者アカウントとパスワードを含めた出力方法サンプル" class="headerlink" title="CSV にローカル管理者アカウントとパスワードを含めた出力方法サンプル"></a>CSV にローカル管理者アカウントとパスワードを含めた出力方法サンプル</h2><ol><li><p>PowerShell を管理者権限で起動します。</p></li><li><p>以下のコマンドを実行し、Microsoft Graph PowerShell モジュールをインストールします。(既にモジュールがインストールされている場合はスキップしてください)</p> <figure class="highlight powershell"><table><tr><td class="code"><pre><span class="line"><span class="built_in">Install-Module</span> Microsoft.Graph <span class="literal">-Force</span></span><br></pre></td></tr></table></figure></li><li><p>以下のコマンドを実行し、グローバル管理者でサインインします。([要求されているアクセス許可] という画面が表示された場合は、[承諾] を押下します)<br>※もしグローバル管理者を利用しない場合は、実行するユーザーに二つのロール (クラウド アプリケーション管理者とクラウド デバイス管理者) が付与されていれば実行可能です。</p> <figure class="highlight powershell"><table><tr><td class="code"><pre><span class="line"><span class="built_in">Connect-MgGraph</span> <span class="literal">-Scopes</span> <span class="string">&quot;DeviceLocalCredential.Read.All&quot;</span>, <span class="string">&quot;Directory.Read.All&quot;</span> </span><br></pre></td></tr></table></figure></li><li><p>以下のコマンドを順に実行して、ローカル管理者アカウントのパスワードがバックアップされているデバイスの一覧をパスワード関連の情報を含んだ形で CSV ファイルとしてデスクトップに出力します。</p> <figure class="highlight powershell"><table><tr><td class="code"><pre><span class="line"><span class="variable">$outfile</span> = <span class="string">&quot;<span class="variable">$env:USERPROFILE</span>\Desktop\DevicelistWithLapsIncludingPassword.csv&quot;</span></span><br><span class="line"><span class="variable">$data</span> = <span class="selector-tag">@</span>()</span><br><span class="line"><span class="variable">$targetDevices</span> = <span class="built_in">Get-MgDirectoryDeviceLocalCredential</span> <span class="literal">-All</span></span><br><span class="line"><span class="keyword">foreach</span> (<span class="variable">$targetDevice</span> <span class="keyword">in</span> <span class="variable">$targetDevices</span>) &#123;</span><br><span class="line">    <span class="variable">$data</span> += <span class="built_in">Get-LapsAADPassword</span> <span class="literal">-DeviceIds</span> <span class="variable">$targetDevice</span>.Id <span class="literal">-IncludePasswords</span> <span class="literal">-AsPlainText</span> | <span class="built_in">select</span> <span class="selector-tag">@</span>&#123;Name=<span class="string">&quot;Id&quot;</span>; Expression=&#123;<span class="variable">$_</span>.DeviceId&#125;&#125;, DeviceName, PasswordUpdateTime, PasswordExpirationTime, Account, Password</span><br><span class="line">&#125;</span><br><span class="line"><span class="variable">$data</span> | <span class="built_in">Export-Csv</span> <span class="variable">$outfile</span> <span class="literal">-encoding</span> <span class="string">&quot;utf8&quot;</span> <span class="literal">-NoTypeInformation</span></span><br></pre></td></tr></table></figure></li><li><p>作業完了後、以下のコマンドでセッションを切断し作業を終了します。</p> <figure class="highlight powershell"><table><tr><td class="code"><pre><span class="line"><span class="built_in">Disconnect-MgGraph</span></span><br></pre></td></tr></table></figure></li></ol><p>上記コマンド実行時の PowerShell 画面イメージは以下のとおりです。</p><p><img src="/blog/azure-active-directory/get-laps-password/get-laps-password1-1.jpg"></p><h2 id="CSV-にローカル管理者アカウントとパスワードを含めた出力方法-CSV-のサンプル"><a href="#CSV-にローカル管理者アカウントとパスワードを含めた出力方法-CSV-のサンプル" class="headerlink" title="CSV にローカル管理者アカウントとパスワードを含めた出力方法 CSV のサンプル"></a>CSV にローカル管理者アカウントとパスワードを含めた出力方法 CSV のサンプル</h2><p>CSV にローカル管理者アカウントとパスワードを含めて出力した CSV のサンプルは以下の通りです。</p><p><img src="/blog/azure-active-directory/get-laps-password/get-laps-password1-2_DevicelistWithLapsIncludingPassword.jpg"></p><h2 id="ローカル管理者パスワードがバックアップされているデバイス一覧のみを-CSV-に出力する方法のサンプル"><a href="#ローカル管理者パスワードがバックアップされているデバイス一覧のみを-CSV-に出力する方法のサンプル" class="headerlink" title="ローカル管理者パスワードがバックアップされているデバイス一覧のみを CSV に出力する方法のサンプル"></a>ローカル管理者パスワードがバックアップされているデバイス一覧のみを CSV に出力する方法のサンプル</h2><ol><li><p>PowerShell を管理者権限で起動します。</p></li><li><p>以下のコマンドを実行し、Microsoft Graph PowerShell モジュールをインストールします。(既にモジュールがインストールされている場合はスキップしてください)</p> <figure class="highlight powershell"><table><tr><td class="code"><pre><span class="line"><span class="built_in">Install-Module</span> Microsoft.Graph <span class="literal">-Force</span></span><br></pre></td></tr></table></figure></li><li><p>以下のコマンドを実行し、グローバル管理者でサインインします。([要求されているアクセス許可] という画面が表示された場合は、[承諾] を押下します)<br>※もしグローバル管理者を利用しない場合は、実行するユーザーに二つのロール (クラウド アプリケーション管理者とクラウド デバイス管理者) が付与されていれば実行可能です。</p> <figure class="highlight powershell"><table><tr><td class="code"><pre><span class="line"><span class="built_in">Connect-MgGraph</span> <span class="literal">-Scopes</span> <span class="string">&quot;DeviceLocalCredential.Read.All&quot;</span>, <span class="string">&quot;Directory.Read.All&quot;</span> </span><br></pre></td></tr></table></figure></li><li><p>以下のコマンドを順に実行して、ローカル管理者アカウントのパスワードがバックアップされているデバイスの一覧をパスワード関連の情報を含んだ形で CSV ファイルとしてデスクトップに出力します。</p> <figure class="highlight powershell"><table><tr><td class="code"><pre><span class="line"><span class="variable">$outfile</span> = <span class="string">&quot;<span class="variable">$env:USERPROFILE</span>\Desktop\DevicelistWithLaps.csv&quot;</span></span><br><span class="line"><span class="variable">$data</span> = <span class="selector-tag">@</span>()</span><br><span class="line"><span class="variable">$data</span> = <span class="built_in">Get-MgDirectoryDeviceLocalCredential</span> <span class="literal">-All</span> | <span class="built_in">select</span> Id, DeviceName, <span class="selector-tag">@</span>&#123;Name=<span class="string">&quot;PasswordUpdateTime&quot;</span>; Expression=&#123;<span class="variable">$_</span>.LastBackupDateTime.AddHours(<span class="number">9</span>)&#125;&#125;, <span class="selector-tag">@</span>&#123;Name=<span class="string">&quot;PasswordExpirationTime&quot;</span>; Expression=&#123;<span class="variable">$_</span>.RefreshDateTime.AddHours(<span class="number">9</span>)&#125;&#125;</span><br><span class="line"><span class="variable">$data</span> | <span class="built_in">Export-Csv</span> <span class="variable">$outfile</span> <span class="literal">-encoding</span> <span class="string">&quot;utf8&quot;</span> <span class="literal">-NoTypeInformation</span></span><br></pre></td></tr></table></figure></li><li><p>作業完了後、以下のコマンドでセッションを切断し作業を終了します。</p> <figure class="highlight powershell"><table><tr><td class="code"><pre><span class="line"><span class="built_in">Disconnect-MgGraph</span></span><br></pre></td></tr></table></figure></li></ol><p>上記コマンド実行時の PowerShell 画面イメージは以下のとおりです。</p><p><img src="/blog/azure-active-directory/get-laps-password/get-laps-password2-1.jpg"></p><h2 id="ローカル管理者パスワードがバックアップされているデバイス一覧のみを出力した際の-CSV-のサンプル"><a href="#ローカル管理者パスワードがバックアップされているデバイス一覧のみを出力した際の-CSV-のサンプル" class="headerlink" title="ローカル管理者パスワードがバックアップされているデバイス一覧のみを出力した際の CSV のサンプル"></a>ローカル管理者パスワードがバックアップされているデバイス一覧のみを出力した際の CSV のサンプル</h2><p>CSV にローカル管理者パスワードがバックアップされているデバイス一覧のみを出力した CSV のサンプルは以下のとおりです。</p><p><img src="/blog/azure-active-directory/get-laps-password/get-laps-password2-2_DevicelistWithLaps.jpg"></p><h2 id="免責事項"><a href="#免責事項" class="headerlink" title="免責事項"></a>免責事項</h2><p>本サンプル コードは、あくまでも説明のためのサンプルとして提供されるものであり、製品の実運用環境で使用されることを前提に提供されるものではありません。本サンプル コードおよびそれに関連するあらゆる情報は、「現状のまま」で提供されるものであり、商品性や特定の目的への適合性に関する黙示の保証も含め、明示・黙示を問わずいかなる保証も付されるものではありません。マイクロソフトは、お客様に対し、本サンプル コードを使用および改変するための非排他的かつ無償の権利ならびに本サンプル コードをオブジェクト コードの形式で複製および頒布するための非排他的かつ無償の権利を許諾します。但し、お客様は以下の 3 点に同意するものとします。</p><ol><li>本サンプル コードが組み込まれたお客様のソフトウェア製品のマーケティングのためにマイクロソフトの会社名、ロゴまたは商標を用いないこと</li><li>本サンプル コードが組み込まれたお客様のソフトウェア製品に有効な著作権表示をすること</li><li>本サンプル コードの使用または頒布から生じるあらゆる損害（弁護士費用を含む）に関する請求または訴訟について、マイクロソフトおよびマイクロソフトの取引業者に対し補償し、損害を与えないこと</li></ol><h2 id="おわりに"><a href="#おわりに" class="headerlink" title="おわりに"></a>おわりに</h2><p>本記事では Microsoft Entra ID にローカル管理者パスワードがバックアップされているデバイス一覧の取得方法を紹介しました。製品動作に関する正式な見解や回答については、お客様環境などを十分に把握したうえでサポート部門より提供しますので、ぜひ弊社サポート サービスをご利用ください。</p>]]>
    </content>
    <id>https://jpazureid.github.io/blog/azure-active-directory/get-laps-password/</id>
    <link href="https://jpazureid.github.io/blog/azure-active-directory/get-laps-password/"/>
    <published>2026-01-30T00:00:00.000Z</published>
    <summary>
      <![CDATA[<p>こんにちは、Azure &amp; Identity サポート チームの長谷川です。今回は Microsoft Entra ID にローカル管理者パスワードがバックアップされているデバイス一覧を取得する方法のサンプルを紹介します。</p>
<p>Windows LAPS の]]>
    </summary>
    <title>ローカル管理者パスワードがバックアップされているデバイスを一覧で取得する</title>
    <updated>2026-08-12T00:07:04.604Z</updated>
  </entry>
  <entry>
    <author>
      <name>Azure Identity Support Japan</name>
    </author>
    <category term="Microsoft Entra ID" scheme="https://jpazureid.github.io/blog/tags/Microsoft-Entra-ID/"/>
    <category term="WorkPlace Join" scheme="https://jpazureid.github.io/blog/tags/WorkPlace-Join/"/>
    <category term="Microsoft Entra Registered" scheme="https://jpazureid.github.io/blog/tags/Microsoft-Entra-Registered/"/>
    <content>
      <![CDATA[<div class="alert is-info"><p class="alert-title">Note</p><p>本記事は 2025 年 5 月に公開した <a href="/blog/azure-active-directory/WorkPlaceJoin2/">このデバイス上のすべてのデスクトップ アプリと Web サイトに自動的にサインインしますか?</a> を 2025 年 12 月時点での最新の情報で再作成した記事です。</p></div><p>こんにちは、Azure &amp; Identity サポート チームの長谷川です。</p><p>Windows 10 以降のデバイスで Office のライセンス認証時やサインインが求められる際に表示される下記「このデバイスのすべてのアプリ、Web サイト、サービスにサインインしますか?」の画面について、お問い合わせを多くいただいています。この画面の動作および制御方法について、本記事ではお纏めいたしました。  </p><p>  </p><h2 id="なぜ表示されるのか？"><a href="#なぜ表示されるのか？" class="headerlink" title="なぜ表示されるのか？"></a>なぜ表示されるのか？</h2><p>Windows 10 の 1703 (Build 15063.138) 以後のバージョンにて Office のバージョン 16.0.7967 以後のバージョンを利用する場合、Office は Web Account Manager (WAM) と呼ばれる認証フレームワークを利用します。  </p><p>「このデバイスのすべてのアプリ、Web サイト、サービスにサインインしますか?」のダイアログ メッセージは、認証に WAM が使用された際、資格情報 (ID&#x2F;Password) を入力してユーザー認証が終了した後、続けて Microsoft Entra ID にデバイスを登録するかどうかを確認する動作により表示されています (Microsoft Entra ID にデバイス登録するとシングル サインオンが利用でき利便性が向上します)。</p><h2 id="各選択肢の意味は？"><a href="#各選択肢の意味は？" class="headerlink" title="各選択肢の意味は？"></a>各選択肢の意味は？</h2><p>「このデバイスのすべてのアプリ、Web サイト、サービスにサインインしますか?」 の画面に表示される選択肢の意味はそれぞれ以下のとおりです。</p><ul><li>[はい]: Microsoft Entra ID に [Microsoft Entra 登録] の方式でデバイスを登録 (Registered) します。</li><li>[いいえ、このアプリのみです]: Microsoft Entra ID &#x2F; Intune 関わらずクラウドへのデバイス登録を行いません。</li></ul><p><img src="/blog/azure-active-directory/WorkPlaceJoin3/WorkPlaceJoin3-1.jpeg" alt="このデバイスのすべてのアプリ、Web サイト、サービスにサインインしますか?の画面"></p><p>上記画面で [はい] を選択した後、サインインしたユーザーが Intune 自動登録の対象の場合は次の 「所属する組織によるデバイスの管理を許可しますか?」 の画面が表示されます。<br>この画面の選択肢の意味はそれぞれ以下のとおりです。希望される状態によって選択肢を変更ください。</p><ul><li>[はい]: Microsoft Entra ID に [Microsoft Entra 登録] の方式でデバイスを登録 (Registered) し、かつ、Intune にも登録します。</li><li>[いいえ]: Microsoft Entra ID に [Microsoft Entra 登録] の方式でデバイスを登録 (Registered) しますが、Intune には登録しません。</li></ul><p><img src="/blog/azure-active-directory/WorkPlaceJoin3/WorkPlaceJoin3-2.jpeg" alt="所属する組織によるデバイスの管理を許可しますか?の画面"></p><div class="alert is-info"><p class="alert-title">Note</p><p>Intune ライセンスを保持していないユーザーで 「所属する組織によるデバイスの管理を許可しますか?」 の画面で [はい] を選択した場合に、次の 「問題が発生しました。」 の画面が表示されることがあります。この画面では Error Code: -895156188 かつ Message: Error response came from MDM terms of use page. と表示されており、Intune 登録と Microsoft Entra 登録の両方が失敗します (作業前の状態に切り戻ります)。このユーザーで Microsoft Entra 登録だけを実施したい場合は、「所属する組織によるデバイスの管理を許可しますか?」 の画面で [いいえ] を選択してください。</p><p>Intune 登録したい場合は、対象ユーザーへの Intune を利用できるライセンスの適用など、Intune 利用条件を満たすように手配ください。</p></div><p><img src="/blog/azure-active-directory/WorkPlaceJoin3/WorkPlaceJoin3-3.jpeg" alt="問題が発生しました。の画面"></p><h2 id="「このデバイスのすべてのアプリ、Web-サイト、サービスにサインインしますか-」の画面を表示させたくない場合"><a href="#「このデバイスのすべてのアプリ、Web-サイト、サービスにサインインしますか-」の画面を表示させたくない場合" class="headerlink" title="「このデバイスのすべてのアプリ、Web サイト、サービスにサインインしますか?」の画面を表示させたくない場合"></a>「このデバイスのすべてのアプリ、Web サイト、サービスにサインインしますか?」の画面を表示させたくない場合</h2><p>Windows 10 1803 以降であれば次の BlockAADWorkplaceJoin のレジストリを追加することで 「このデバイスのすべてのアプリ、Web サイト、サービスにサインインしますか?」 の画面が表示されなくなります。</p><h3 id="BlockAADWorkplaceJoin-のレジストリ"><a href="#BlockAADWorkplaceJoin-のレジストリ" class="headerlink" title="BlockAADWorkplaceJoin のレジストリ"></a>BlockAADWorkplaceJoin のレジストリ</h3><pre><code>レジストリ キーパス: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoinレジストリ名: BlockAADWorkplaceJoin形式: DWORD値: 00000001</code></pre><h3 id="BlockAADWorkplaceJoin-のレジストリを追加した場合の他の影響"><a href="#BlockAADWorkplaceJoin-のレジストリを追加した場合の他の影響" class="headerlink" title="BlockAADWorkplaceJoin のレジストリを追加した場合の他の影響"></a>BlockAADWorkplaceJoin のレジストリを追加した場合の他の影響</h3><p>この BlockAADWorkplaceJoin のレジストリを追加しても Microsoft Entra 参加および Microsoft Entra ハイブリッド参加の構成には影響ありません。<br>また、この BlockAADWorkplaceJoin のレジストリを追加した場合、「このデバイスのすべてのアプリ、Web サイト、サービスにサインインしますか?」の画面を表示させないだけではなく、[スタート] - [設定] (歯車のマーク) - [アカウント] - [職場または学校にアクセスする] の画面からの Microsoft Entra 登録の構成もブロックすることができます。<br>このレジストリの効果で Microsoft Entra 登録の構成がブロックされた場合は、以下の Error Code: -895155967 かつ Message: Add account operation is blocked by policy on the device. と記載された 「サインインできませんでした」 の画面が表示されます。<br>    <img src="/blog/azure-active-directory/WorkPlaceJoin3/WorkPlaceJoin3-4.jpeg" alt="サインインできませんでしたの画面"> </p><h3 id="BlockAADWorkplaceJoin-のレジストリをグループ-ポリシーで配布する方法"><a href="#BlockAADWorkplaceJoin-のレジストリをグループ-ポリシーで配布する方法" class="headerlink" title="BlockAADWorkplaceJoin のレジストリをグループ ポリシーで配布する方法"></a>BlockAADWorkplaceJoin のレジストリをグループ ポリシーで配布する方法</h3><p>上述の BlockAADWorkplaceJoin レジストリ値を 0x1 として設定するグループポリシーに関して、下記の手順をご紹介いたします。</p><ol><li><p>グループ ポリシーの管理画面より対象クライアント コンピューターに適用させる前提の GPO の編集画面を表示します。</p></li><li><p>以下のポリシーを展開します。</p><p> –コンピューターの構成<br> —-基本設定<br> ——Windows の設定<br> ——–レジストリ</p></li><li><p>上記 [レジストリ] を右クリックし [新規作成] - [レジストリ項目] を選択します。</p></li><li><p>下記のように設定を追加します。</p><p> アクション: 更新<br> ハイブ: HKEY_LOCAL_MACHINE<br> キーのパス: SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoin<br> 値の名前: BlockAADWorkplaceJoin<br> 値の種類: REG_DWORD<br> 値のデータ: 00000001</p></li></ol><p>上記の設定をポリシーで配布することでクライアントに目的のレジストリ値が反映するかご確認ください。</p><h3 id="Windows-10-1803-で-BlockAADWorkplaceJoin-のレジストリを利用する際の注意事項"><a href="#Windows-10-1803-で-BlockAADWorkplaceJoin-のレジストリを利用する際の注意事項" class="headerlink" title="Windows 10 1803 で BlockAADWorkplaceJoin のレジストリを利用する際の注意事項"></a>Windows 10 1803 で BlockAADWorkplaceJoin のレジストリを利用する際の注意事項</h3><p>Windows 10 1803 で上述の BlockAADWorkplaceJoin のレジストリを利用する場合、下記の更新プログラムの適用が必要です。既に KB4489894 以降の更新プログラムを適用している場合、レジストリの設定、および再起動のみでご要望を満たすことが可能です。</p><p>March 19, 2019 - KB4489894 (OS Build 17134.677)<br><a href="https://support.microsoft.com/en-us/help/4489894/windows-10-update-kb4489894">https://support.microsoft.com/en-us/help/4489894/windows-10-update-kb4489894</a> </p><h2 id="Microsoft-Entra-登録を切断する方法"><a href="#Microsoft-Entra-登録を切断する方法" class="headerlink" title="Microsoft Entra 登録を切断する方法"></a>Microsoft Entra 登録を切断する方法</h2><p>構成された Microsoft Entra 登録を切断したい場合は次の手順で切断できます。<br>「このデバイスのすべてのアプリ、Web サイト、サービスにサインインしますか?」の画面で [はい] を選択したために意図せず Microsoft Entra 登録が構成されてしまった場合もこちらの手順で切断できます。</p><ol><li><p>通常クライアント PC を利用するユーザーで Windows にログオンします。  </p></li><li><p>[スタート] - [設定] (歯車のマーク) - [アカウント] - [職場または学校にアクセスする] を開きます。  </p></li><li><p>以下のように、[職場または学校アカウント] のエントリが存在する場合、エントリを選択し、[切断] をクリックします。</p><p> <img src="/blog/azure-active-directory/WorkPlaceJoin3/WorkPlaceJoin3-5.jpeg" alt="切断手順 1">  </p></li><li><p>「このアカウントを削除しますか?～」 といったポップアップが表示されますので、[はい] をクリックします。 </p><p> <img src="/blog/azure-active-directory/WorkPlaceJoin3/WorkPlaceJoin3-6.jpeg" alt="切断手順 2">  </p></li><li><p>[職場または学校にアクセスする] の画面で “職場または学校アカウント” のエントリが消えれば、切断が完了します。</p><p> <img src="/blog/azure-active-directory/WorkPlaceJoin3/WorkPlaceJoin3-7.jpeg" alt="切断手順 3"></p></li></ol><h2 id="よくご質問いただく内容"><a href="#よくご質問いただく内容" class="headerlink" title="よくご質問いただく内容"></a>よくご質問いただく内容</h2><p><strong>Q. 登録済みのデバイスを Azure ポータルから管理者の操作のみで切断可能か？</strong>  </p><p><strong>A.</strong> Microsoft Entra ID 上からデバイスの削除を行うことは可能ですが、対象のデバイスで上述の切断方法を実施しない場合には下記の問題が発生します。そのため、デバイス側で手動で切断を実施するようにしてください。</p><p>エラーコード 700003 の対処策について<br><a href="https://jpazureid.github.io/blog/azure-active-directory/what-to-do-errorcode-700003/">https://jpazureid.github.io/blog/azure-active-directory/what-to-do-errorcode-700003/</a>  </p><p><strong>Q. Microsoft Entra ID にデバイスが登録されたまま放置しても問題ないか？</strong> </p><p><strong>A.</strong> デバイスの管理方法の変更が組織で行われない限り、特別問題が生じることはありません。組織にてデバイスの管理を Microsoft Entra ハイブリッド参加構成に変更を行った場合に、その事前に Microsoft Entra 登録を構成していた場合、Microsoft Entra 登録 と Microsoft Entra ハイブリッド参加の状態の 2 つのデバイスが Microsoft Entra ID に重複登録されてしまう可能性があります。構成変更をする場合には、予め下記をご参照ください。  </p><p>Microsoft Entra 登録済み状態のデバイスの処理<br><a href="https://learn.microsoft.com/ja-jp/azure/active-directory/devices/hybrid-azuread-join-plan#handling-devices-with-azure-ad-registered-state">https://learn.microsoft.com/ja-jp/azure/active-directory/devices/hybrid-azuread-join-plan#handling-devices-with-azure-ad-registered-state</a></p><p><strong>Q. 「このデバイスのすべてのアプリ、Web サイト、サービスにサインインしますか?」のメッセージはどのタイミングで表示されるのか？</strong>  </p><p><strong>A.</strong> 上述させていただきましたとおり、Office 365 インストール時や Teams 、Outlook などの Office 製品での認証時に表示されます。その他には Edge ブラウザーへサインインする際や、Azure Virtual Desktop に接続する際に利用される Windows 用リモート デスクトップ クライアントでのサインイン時にも表示されます。つまり、WAM を認証ブローカーとして使用するアプリで (WAM を用いた) サインインを行った際に表示されます。</p><p><strong>Q. 「このデバイスのすべてのアプリ、Web サイト、サービスにサインインしますか?」のメッセージを非表示にするように制御した場合の影響は?</strong>  </p><p><strong>A.</strong> WAM による Microsoft Entra ID へのデバイス登録が行われなくなるだけで、Windows 10 以降のデバイス、Office 製品、Microsoft Entra ID の利用上に制限や問題となるような影響は特にありません。</p><p><strong>Q. Microsoft Entra ID でのデバイス管理方法について</strong>  </p><p><strong>A.</strong> 本記事のメッセージを契機に Microsoft Entra ID でのデバイス管理方法についてご質問を多くいただきます。弊社製品開発チームにて開催させていただいている Webinar にてご紹介させていただいておりますので、参考にしていただければ幸いです。</p><p><a href="https://github.com/yusukekodama/PMActivities/blob/master/Webinar/Schedule.md">https://github.com/yusukekodama/PMActivities/blob/master/Webinar/Schedule.md</a></p><p>関連する回としては下記となります。  </p><ul><li>COVID-19 でリモート対応に成功した企業と失敗した企業の違いとは？  </li><li>Azure AD の新しいデバイス管理パターンを理解しよう  </li><li>Intune によるモバイルデバイスとアプリのセキュアな管理とは</li></ul>]]>
    </content>
    <id>https://jpazureid.github.io/blog/azure-active-directory/WorkPlaceJoin3/</id>
    <link href="https://jpazureid.github.io/blog/azure-active-directory/WorkPlaceJoin3/"/>
    <published>2025-12-17T00:00:00.000Z</published>
    <summary>
      <![CDATA[<div class="alert is-info"><p class="alert-title">Note</p><p>本記事は 2025 年 5 月に公開した <a href="/blog/azure-active-directory/WorkPlaceJoin2/">このデ]]>
    </summary>
    <title>このデバイスのすべてのアプリ、Web サイト、サービスにサインインしますか?</title>
    <updated>2026-08-12T00:07:04.292Z</updated>
  </entry>
  <entry>
    <author>
      <name>Azure Identity Support Japan</name>
    </author>
    <category term="Microsoft Entra" scheme="https://jpazureid.github.io/blog/tags/Microsoft-Entra/"/>
    <content>
      <![CDATA[<p>こんにちは、Azure Identity サポート チームの 五十嵐 です。</p><p>2025 年 12 月 9 日 に Microsoft 365 管理センターのメッセージ センターで MC1193408 の通知が行われ、2026 年 1 月 7 日より、Microsoft Entra が DigiCert のルート証明書を G1 から G2 に移行する旨が発表されました。この通知に関する内容について既に多くのお問い合わせをいただいており、今回のブログではその概要と必要な対応、よくあるご質問について Q&amp;A 形式でおまとめして紹介します。</p><p>まずは、メッセージ センターで通知した MC1193408 の内容について抄訳したものを以下に記載いたします。</p><h2 id="MC1193408-の抄訳"><a href="#MC1193408-の抄訳" class="headerlink" title="MC1193408 の抄訳"></a>MC1193408 の抄訳</h2><blockquote><p>アクションが必要です: Microsoft Entra の新しい DigiCert 証明機関 (CA) を信頼してください</p><p>2026 年 1 月 7 日より、Microsoft Entra は DigiCert 証明書を G1 ルート CA から G2 ルート CA に移行します。<br>DigiCert G1 ルートをピン留めしている、または DigiCert G2 ルートを信頼していないクライアントでは、認証エラーが発生する可能性があります。</p><p>G1 &#x2F; G2 のルート CA とは？<br>証明機関 (CA) は、安全な通信のための信頼を確立するデジタル証明書を発行する機関です。ルート CA は信頼チェーンの最上位にある証明書です。<br>現在、Microsoft Entra サービスでは DigiCert Global Root G1 が使用されていますが、Microsoft はセキュリティとコンプライアンス向上のため、DigiCert Global Root G2 へ移行します。<br>システムが G2 ルートを信頼していない場合、Microsoft Entra への認証や安全な接続が失敗します。</p><p>実施時期: 2026 年 1 月 7 日</p><p>本通知の変更が組織に与える影響: Microsoft Entra ID サービスを利用している組織は、DigiCert G2 の証明書が信頼されていない場合、Microsoft Entra へのアクセス時に認証エラーが発生するようになります。</p><p>影響を受けるドメインの例:</p><ul><li>login.live.com</li><li>login.windows.net</li><li>autologon.microsoftazuread-sso.com</li><li>graph.windows.net</li></ul><div class="alert is-info"><p class="alert-title">Note</p><p>2025&#x2F;12&#x2F;17 更新: login.microsoftonline.com ドメインは 2025 年 2 月に DigiCert G2 ルートに既に移行されているため、今回影響を受けるドメインの例には含まれません。</p></div><p>準備のためにできること:</p><ul><li>Azure 証明機関の詳細 ドキュメントに記載されている すべてのルートおよび下位 CA を信頼してください。</li><li>「DigiCert Global Root G2」ルートおよびその下位証明機関 (2025 年 9 月以降ドキュメント化) を信頼する設定になっていることを確認してください。</li><li>クライアント側の DigiCert Global Root CA へのピン留め設定がある場合はすべて削除してください。</li><li>サービス中断を回避するため、今すぐ設定を更新してください。</li></ul><p>ヘルプとサポート:</p><ul><li>DigiCert 証明書に関する詳細は DigiCert のドキュメント をご参照ください。</li><li>証明書のピン留めに関するガイダンスは Azure ドキュメント をご確認ください。</li><li>Microsoft Q&amp;A のコミュニティで専門家に質問できます。</li><li>サポート契約をお持ちで技術支援が必要な場合は、サポート リクエスト を作成してください。</li></ul></blockquote><p>続いて、本通知に関する補足情報を Q&amp;A 形式で記載いたします。</p><h2 id="よくあるご質問"><a href="#よくあるご質問" class="headerlink" title="よくあるご質問"></a>よくあるご質問</h2><h3 id="Q-通知が行われた環境ではすべて対応が必要になりますか？"><a href="#Q-通知が行われた環境ではすべて対応が必要になりますか？" class="headerlink" title="Q. 通知が行われた環境ではすべて対応が必要になりますか？"></a>Q. 通知が行われた環境ではすべて対応が必要になりますか？</h3><p>A. お客様の環境で特殊な制御を実施していない場合は、今回の対応は不要です。今回の通知は、現在利用されている証明書のみを明示的に信頼するように構成している (ピン留めを設定している) 環境やアプリケーションにのみ影響があります。これは環境側の構成であるため、弊社側ではお客様の環境でピン留めを設定しているか否かの判別ができないことから、すべてのお客様に通知を実施しております。</p><p>なお、Windows OS では既定で「ルート証明書更新プログラム」という機能が有効になっており、これにより既に必要なルート証明書がインストール済みであることが想定されます。この仕組みについては、以下の Windows サポートによる技術ブログに詳細があります。たとえば、この動作を無効にするポリシーやレジストリを設定していないかどうかの確認手順についても記載がありますため、参考となりましたら幸いです。</p><p><a href="https://jpwinsup.github.io/blog/2021/12/14/PublicKeyInfrastructure/CertificateManagement/about-windows-root-certificate-program/">ルート証明書更新プログラムの仕組みについて | Microsoft Japan Windows Technology Support Blog</a></p><blockquote><p>Windows OS では、端末にルート証明書を自動できる仕組みとして「ルート証明書更新プログラム」という機能があります。この機能は既定で有効になっており、必要に応じてルート証明書をダウンロードして [信頼されたルート証明機関] のストアに自動でインストールしております。</p></blockquote><div class="alert is-info"><p class="alert-title">Note</p><p>2021 年 8 月以降のルート証明書更新プログラムには DigiCert Global Root G2 ルート証明書が含まれております。そのため、2021 年 8 月以降に一度でもルート証明書更新プログラムが動作していましたら、既に信頼する証明機関として DigiCert Global Root G2 が含まれていることが想定されます。</p></div><h3 id="Q-どのように対応すればよいですか？"><a href="#Q-どのように対応すればよいですか？" class="headerlink" title="Q. どのように対応すればよいですか？"></a>Q. どのように対応すればよいですか？</h3><p>A. 以下の公開情報に記載のルート証明機関、およびその下位証明機関をすべて信頼するように設定ください。</p><p><a href="https://learn.microsoft.com/ja-jp/azure/security/fundamentals/azure-ca-details?tabs=root-and-subordinate-cas-list">Azure 証明機関の詳細</a></p><h3 id="Q-対応しなかった場合どうなりますか？"><a href="#Q-対応しなかった場合どうなりますか？" class="headerlink" title="Q. 対応しなかった場合どうなりますか？"></a>Q. 対応しなかった場合どうなりますか？</h3><p>A. 2026 年 1 月 7 日以降、DigiCert Global Root G2 を信頼していない環境や G1 をピン留めしている環境では、Microsoft Entra ID へのサインインや関連サービスで認証が失敗するようになります。</p><h3 id="Q-クライアントが証明書のピン留めを使用しているかどうか確認する方法はありますか？"><a href="#Q-クライアントが証明書のピン留めを使用しているかどうか確認する方法はありますか？" class="headerlink" title="Q. クライアントが証明書のピン留めを使用しているかどうか確認する方法はありますか？"></a>Q. クライアントが証明書のピン留めを使用しているかどうか確認する方法はありますか？</h3><p>A. Microsoft Entra ID 側では証明書のピン留めを使用しているクライアントの情報を取得することはできません。また、証明書のピン留めの実施方法には統一された Web 標準がないため、その使用を検出するための直接的な方法は提供できません。</p><h3 id="Q-影響がないかどうか事前にテストする方法はありますか？"><a href="#Q-影響がないかどうか事前にテストする方法はありますか？" class="headerlink" title="Q. 影響がないかどうか事前にテストする方法はありますか？"></a>Q. 影響がないかどうか事前にテストする方法はありますか？</h3><p>A. DigiCert 社が公開している以下のデモサイトは、次に Entra ID が利用するサーバー証明書と同じルート証明書が利用されています。</p><p>DigiCert Global Root G2<br><a href="https://global-root-g2.chain-demos.digicert.com/">https://global-root-g2.chain-demos.digicert.com/</a></p><p>そのため、現時点で上記の Web サイトを証明書のエラーが発生することなく閲覧できる環境であれば、影響を受ける可能性は極めて低いと判断いただけます。</p><h3 id="Q-login-microsoftonline-com-にアクセスすると-DigiCert-Global-Root-G1-にチェーンする証明書が返されることもありますがどういうことですか？"><a href="#Q-login-microsoftonline-com-にアクセスすると-DigiCert-Global-Root-G1-にチェーンする証明書が返されることもありますがどういうことですか？" class="headerlink" title="Q. login.microsoftonline.com にアクセスすると DigiCert Global Root G1 にチェーンする証明書が返されることもありますがどういうことですか？"></a>Q. login.microsoftonline.com にアクセスすると DigiCert Global Root G1 にチェーンする証明書が返されることもありますがどういうことですか？</h3><p>A. login.microsoftonline.com では、DigiCert のルート証明書の G1 と G2 が両方使用されており、実際のアクセスを受け取るインスタンスに応じて、G1 と G2 のどちらかが応答される状況となっています。このため、タイミングによって G1 が返される場合や、G2 が返される場合があります。 MC が更新され、login.microsoftonline.com ドメインは DigiCert G2 ルートに既に移行されていると追記されたのは、この動作を反映したものです。現在 login.microsoftonline.com ドメインに正常にアクセスできているクライアントはすでに DigiCert G2 ルートを利用できていると想定されるため、今回影響を受けることはないと判断いただけます。</p><h3 id="Q-2026-年-1-月-7-日以降になると即座に移行されるのでしょうか？"><a href="#Q-2026-年-1-月-7-日以降になると即座に移行されるのでしょうか？" class="headerlink" title="Q. 2026 年 1 月 7 日以降になると即座に移行されるのでしょうか？"></a>Q. 2026 年 1 月 7 日以降になると即座に移行されるのでしょうか？</h3><p>A. いいえ、2026 年 1 月 7 日以降に徐々に移行を実施する予定です。影響を受けるドメインはグローバルなエンドポイントであるため、特定のお客様やテナントに対して具体的にいつ移行が行われるかを予測したり弊社から案内したりすることはできません。</p>]]>
    </content>
    <id>https://jpazureid.github.io/blog/azure-active-directory/mc1193408-action-required-trust-digicert-global-root-g2-certificate-authority/</id>
    <link href="https://jpazureid.github.io/blog/azure-active-directory/mc1193408-action-required-trust-digicert-global-root-g2-certificate-authority/"/>
    <published>2025-12-12T01:00:00.000Z</published>
    <summary>
      <![CDATA[<p>こんにちは、Azure Identity サポート チームの 五十嵐 です。</p>
<p>2025 年 12 月 9 日 に Microsoft 365 管理センターのメッセージ センターで MC1193408 の通知が行われ、2026 年 1 月 7 日より、Micro]]>
    </summary>
    <title>MC1193408 - 要対応: 2026 年 1 月 7 日までに DigiCert Global Root G2 証明機関を信頼してください</title>
    <updated>2026-08-12T00:07:04.809Z</updated>
  </entry>
  <entry>
    <author>
      <name>Azure Identity Support Japan</name>
    </author>
    <category term="Microsoft Entra" scheme="https://jpazureid.github.io/blog/tags/Microsoft-Entra/"/>
    <category term="US Identity Blog" scheme="https://jpazureid.github.io/blog/tags/US-Identity-Blog/"/>
    <content>
      <![CDATA[<p>こんにちは、Azure Identity サポート チームの 五十嵐 です。</p><p>本記事は、2025 年 11 月 11 日に米国の Microsoft Entra (Azure AD) Blog で公開された <a href="https://techcommunity.microsoft.com/blog/microsoft-entra-blog/riding-the-ai-wave-how-microsoft-entra-is-evolving-for-the-agentic-era/4460536">Riding the AI Wave: How Microsoft Entra is Evolving for the Agentic Era</a> の抄訳です。ご不明点等ございましたらサポート チームまでお問い合わせください。</p><hr><p>このブログは、2025 年 10 月に開催された <a href="https://www.quest.com/the-experts-conference/">The Experts Conference</a> での私の基調講演をもとにしています。</p><p>私は Microsoft に入社して 34 年目になります。入社当時は飲酒できないほど若く、白髪もなかったことを思うと、信じられません。約 15 年前、私の電話が鳴った日のことを今でも覚えています。当時は、誰からの着信かを表示する小さな液晶画面付きの固定電話を実際に手に取って応答していました。ディスプレイにはこう表示されました: “Satya N.” ―― なんと！</p><p>「やあ、Alex」と彼は言いました。「ID を担当するチームのディレクターという新しいロールがあるんだけど、君がぴったりだと思うんだ。」</p><p>まず、Satya Nadella が直接電話してきたことに驚きました。次に思ったのは、「本当に？僕に ID の仕事を？」ということです。しかし、その後 2 時間、彼は ID が Microsoft のエンタープライズ戦略の基盤であり、クラウドへの移行を推進するために助けが必要なんだと説明してくれました。</p><p>3 週間後、私はこれまでで最高といえる仕事を始めることになりました。オンプレミスの Active Directory をクラウドに移行し、Azure Active Directory として進化させ、さらに Microsoft Entra という完全な ID およびアクセス管理ソリューションへと発展させる仕事です。その旅は本当に素晴らしいものでしたが、ID の仕組み自体は根本的には変わっていません。</p><p>そして今、はるかに大きなイノベーションの波が始まっています。</p><h2 id="AI-という大波"><a href="#AI-という大波" class="headerlink" title="AI という大波"></a>AI という大波</h2><p>1 年前、上司の <a href="https://www.linkedin.com/in/joy-chik/">Joy Chik</a> にこう言われました。「AI に注力して、来たるべき未来に備える方法を考えてほしい」と。</p><p>それ以来、私は AI ツールを試し、自分のエージェントを作り、戦略をまとめ、世界中の顧客、業界アナリスト、AI 専門家と話をしてきました。だからこそ、次の波は、人間の働き方や経済の仕組みを、産業革命、電気革命、インターネット革命、モバイル革命と同じように根本から変えると確信しています。</p><p>約 1 万 2 千年前、人類は植物や動物を家畜化し、狩猟採集から農耕へと移行しました。その次の大きな波では、複雑な社会を築き、政府を作りました。産業革命と石炭、蒸気、そして最終的には電気による力で、大規模な工場や都市を建設できるようになりました。電気による革命の前は、ほとんどの人が暗くなると眠りについていました。今では皆、夜遅くまでテレビを見ながらデバイスを上に下にとスワイプしています。</p><p>現在、私たちはインターネットとモバイル革命の真っただ中にいます。これは大きな変化でしたが、AI はそれをはるかに超えるイノベーションの波となろうとしています。</p><h2 id="AI-エージェント導入の現実"><a href="#AI-エージェント導入の現実" class="headerlink" title="AI エージェント導入の現実"></a>AI エージェント導入の現実</h2><p>多くのお客様も同じように感じているようです。<a href="https://view.ceros.com/kpmg-design/kpmg-genai-study/p/1">KPMG の調査</a> によると、大企業の 42 ％ が現在、AI エージェントを実際に活用しており、これはわずか 6 か月前の 11 ％ から急増しています (※)。まだ始まったばかりです。</p><p>※ KPMG AI Quarterly Pulse Survey | Q3 2025. September 2025. n&#x3D; 130 U.S.-based C-suite and business leaders representing organizations with annual revenue of $1 billion or more.</p><p><a href="https://adoption.microsoft.com/ja-jp/ai-agents/agents-in-microsoft-365/">Microsoft 365</a> や <a href="https://learn.microsoft.com/ja-jp/copilot/security/agents-overview">Security Copilot</a> プラットフォーム、さらに <a href="https://www.workday.com/ja-jp/artificial-intelligence/ai-agents.html">Workday</a> や <a href="https://www.servicenow.com/jp/products/ai-agents.html">ServiceNow</a> といったパートナーを通じて、ビジネスに役立つ優れたエージェントがすでに利用可能です。</p><p>IDC の予測では、2028 年までに先進国の大企業で 13 億もの AI エージェントが稼働する見込みです (※)。実際の例として、Microsoft ではすでに開発、セキュリティ、リサーチ、分析の分野でエージェントを活用しています。私の見立てでは、人間の従業員よりもエージェントの数が多くなるのは時間の問題です。私の予想では 2 年以内に、Microsoft テナントで 100 万以上の AI エージェントが稼働しているでしょう。</p><p>しかも、エージェントは大量に存在するだけでなく、短命です。数週間稼働した後に停止されるため、大規模なスケールでエージェントの生成と消滅に対応できる仕組みが必要です。</p><p>※ IDC Info Snapshot, 1.3 Billion AI Agents by 2028, May 2025</p><h2 id="エージェントとは具体的に何か？"><a href="#エージェントとは具体的に何か？" class="headerlink" title="エージェントとは具体的に何か？"></a>エージェントとは具体的に何か？</h2><p>ここで少し立ち止まり、Microsoft で「エージェント」をどう捉えているかを説明します。</p><p><img src="/blog/azure-active-directory/riding-the-ai-wave-how-microsoft-entra-is-evolving-for-the-agentic-era/riding-the-ai-wave-how-microsoft-entra-is-evolving-for-the-agentic-era1.png" alt="AI エージェントとは、ドメイン知識、アクションの実行能力、そしてガードレール (逸脱の防止機能) を備えた LLM (大規模言語モデル) のことです。"></p><p>エージェントとは、役割を指示する一連の指示を持つ <a href="https://learn.microsoft.com/ja-jp/training/modules/introduction-large-language-models/">LLM (大規模言語モデル)</a> であり、それを支えるコードによってさまざまな組み換えやガードレール (逸脱の防止機能) が提供され、結果の検証も行われます。しかし、エージェントを特別な存在にするのは次の 2 つの要素です。</p><ol><li><strong>ドメイン知識</strong>: ビジネスや特定のプロセス、技術分野について理解しており、理想的には学習と改善を可能にする記憶機能を備えています。</li><li><strong>アクションの実行能力</strong>: MS Graph や Azure リソース、その他のシステムへの API 呼び出しを行い、アクションを実行し、その入力やデータを呼び出し元に返すことができます。</li></ol><p>そして、実行能力があるからこそ、エージェントには適切なアクセス制御が必要です。私の主張は、すべてのエージェントに ID が必要だということです。</p><p>こう考えてみてください。自動車メーカーが VIN (車体番号) 番号なしで車を出荷することはありません。Microsoft が提供するすべてのエージェントには、組み込みのエージェント ID が付与され、追跡、アクセス制御、ライフサイクル管理が可能になります。</p><h2 id="条件付きアクセス-ポリシーを最適化するエージェント"><a href="#条件付きアクセス-ポリシーを最適化するエージェント" class="headerlink" title="条件付きアクセス ポリシーを最適化するエージェント"></a>条件付きアクセス ポリシーを最適化するエージェント</h2><p>私が特に注目しているエージェントのひとつが、Microsoft Entra の <a href="https://learn.microsoft.com/ja-jp/entra/security-copilot/conditional-access-agent-optimization">条件付きアクセスの最適化エージェント</a> です。このエージェントは、条件付きアクセス ポリシーを精査し、その内容やセキュリティ上の抜け穴を把握できるよう支援し、さらにポリシーを最新の状態に保ちます。</p><p>このエージェントを活用することで、お客様は平均して月に 26 件ものポリシーの抜け穴を発見しています。これらは見過ごされるか、悪意ある攻撃に悪用される可能性があるものです。また、このエージェントを利用している顧客の 73 ％ が、その推奨事項に基づいてセキュリティ体制を大幅に改善しています (※)。</p><p>※ James Bono, Beibe Cheng, and Joaquin Lozano, Randomized Controlled Trials for Conditional Access Optimization Agent, October 2025, Microsoft Corporation.</p><p><img src="/blog/azure-active-directory/riding-the-ai-wave-how-microsoft-entra-is-evolving-for-the-agentic-era/riding-the-ai-wave-how-microsoft-entra-is-evolving-for-the-agentic-era2.png" alt="Microsoft Teams のアラートにより、条件付きアクセスの最適化エージェントの提案にチームが迅速に対応できるようになります。"></p><p>これは単に ChatGPT を API に接続したものではありません。私のチームやお客様対応チームが、効果的な条件付きアクセス ポリシーを構築する中で得た知識とノウハウを詰め込んだ、目的特化型のエージェントです。このエージェントは、テナントとすべての条件付きアクセス ポリシーを継続的に分析し、ポリシーの重複を検出し、保護されていないユーザーやアプリケーションを見つけ、ワンクリックでギャップを修正するのを支援します。また、除外設定されていないブレークグラス アカウントや、除外が多すぎるポリシーなど、リスクのある構成も特定できます。</p><p>さらに、このエージェントは提案されたポリシー更新のために ServiceNow にチケットを作成し、変更管理の要件に準拠するように動作することも可能です。段階的なロールアウト計画を設計し、ユーザーへの影響を最小限に抑えながらポリシーを徐々に有効化することも可能です。パイロット モードでは新しいポリシーを展開することもできます。そして継続的に新しいユーザーやアプリをチェックし、ポリシーで適切に保護されていることを確認します。</p><p>🎯 Alex の 2025 年 10 月 14 日の投稿を参照ください: <a href="https://techcommunity.microsoft.com/blog/microsoft-entra-blog/the-conditional-access-optimization-agent-keeps-getting-better%E2%80%94and-making-your-l/4460535">The Conditional Access Optimization Agent keeps getting better—and making your life easier</a></p><p>条件付きアクセスの最適化エージェントを、ゼロ トラストのコンサルタント兼アドバイザーへと進化させるような存在だとお考えください。<a href="https://tei.forrester.com/go/Microsoft/EntraSuite/?lang=en-us">セキュリティ体制を強化しながら、時間とコストを節約できるのです</a>。今後、Microsoft や業界全体から、より深い専門知識と分析を迅速かつ便利に提供するエージェントがさらに登場するでしょう。</p><p>Joy Chik は、11 月 18 日火曜日の Microsoft Ignite の <a href="https://ignite.microsoft.com/en-US/sessions/BRK243">Microsoft Entra: What’s New in Secure Access on the AI Frontier</a> セッションで、Microsoft Entra におけるエージェントの新機能を発表します。</p><h2 id="スケーラビリティのある管理体制-ペットではなく家畜の群れ"><a href="#スケーラビリティのある管理体制-ペットではなく家畜の群れ" class="headerlink" title="スケーラビリティのある管理体制: ペットではなく家畜の群れ"></a>スケーラビリティのある管理体制: ペットではなく家畜の群れ</h2><p>アクセス権のモデルに加えて、もう一つの大きな課題は、エージェントを大規模に管理することです。ここで、これまで使っていた「船と波」の比喩は一旦やめて、より現実的な陸上のたとえ話で考えてみましょう。<strong>AI エージェントはペットではなく家畜のようなものと言えます</strong>。ペットの世話をしたりご飯をあげたりするには時間がかかると思いますが、エージェントの世界ではそのような時間はありません。大量のエージェントが次々と生成され、消えていく中では、広大な “牧場” に広がる多様な群れを統制するように、ライフサイクルを自動化して大規模に管理する必要があります。</p><p><img src="/blog/azure-active-directory/riding-the-ai-wave-how-microsoft-entra-is-evolving-for-the-agentic-era/riding-the-ai-wave-how-microsoft-entra-is-evolving-for-the-agentic-era3.png" alt="エージェントの大規模な導入・更新・削除に対応し、リスクを低減するためには、自動化された ID のライフサイクル管理が不可欠になります。"></p><p>次のような戦略が必要になります:</p><ul><li>エージェントの展開および追跡する方法</li><li>誰がその責任を持つのかを把握する方法</li><li>エージェントのアクセス権をプロビジョニングし承認する方法</li><li>継続的なアクセス レビューの実施</li><li>権限を自動的に取り消す仕組み</li><li>実行中のエージェントのバージョンを証明する方法</li><li>不要になったエージェントをデプロビジョニングする方法</li></ul><p>ガバナンスやライフサイクル管理に穴があると、特にアクセス レビューで全員が圧倒されることになります。そこで、私たちはこの課題に取り組み、エージェントの ID ガバナンス戦略のためのフレームワークを構築しています。</p><h2 id="エージェントのセキュア-アクセス-Microsoft-Entra-Agent-ID"><a href="#エージェントのセキュア-アクセス-Microsoft-Entra-Agent-ID" class="headerlink" title="エージェントのセキュア アクセス: Microsoft Entra Agent ID"></a>エージェントのセキュア アクセス: Microsoft Entra Agent ID</h2><p>まもなく、エージェントをエンタープライズ レベルの ID として管理、保護、ガバナンスできるようになります。</p><p>Microsoft BUILD で、<a href="https://jpazureid.github.io/blog/azure-active-directory/announcing-microsoft-entra-agent-id-secure-and-manage-your-ai-agents/">AI エージェントを Microsoft Entra に統合すること</a> を発表しました。私たちの目標はシンプルです。従業員 ID に適用している保護と制御を、AI エージェントにも提供することです。Microsoft Entra では、エージェントを新しい ID タイプとして追加し、アクセス管理、セキュリティ、ID ガバナンスの機能を開発しています。これらのエージェント ID は、Foundry、Copilot Studio、Security Copilot、そしてサードパーティ プラットフォームなど、エージェント作成に使うツールにあらかじめ構成されます。</p><p>詳細は、Ignite のセッション <a href="https://ignite.microsoft.com/en-US/sessions/BRK265">Secure access for AI agents with Microsoft Entra</a> で紹介しますので、ぜひご参加ください。</p><h2 id="エージェント時代に向けた標準の進化"><a href="#エージェント時代に向けた標準の進化" class="headerlink" title="エージェント時代に向けた標準の進化"></a>エージェント時代に向けた標準の進化</h2><p>Microsoft Entra は、幅広いパートナーやアプリケーションのエコシステムを支えています。私たちは業界全体で協力し、すべてのエージェント型 ID システムとの統合を可能にし、セキュリティ リスクを低減し、専門家、学術機関、標準化団体で合意したベスト プラクティスに沿った共通標準を採用できるよう取り組んでいます。</p><p>そのために、OAuth 2.0 標準グループで次の重要な変更に取り組んでいます:</p><ul><li>エージェントを一流のアクターとして表現する (クライアントでもユーザーでもなく、新しい概念)</li><li>エージェントが独立した権限を持てるようにする</li><li>エージェントの行動を追跡可能にする (ログに “Alex の代理として動作するエージェント” ではなく “エージェントが動作” と表示)</li><li>エージェントに対するきめ細かな権限、検出、委任を可能にする</li></ul><p>これらの <a href="https://jpazureid.github.io/blog/azure-active-directory/the-future-of-ai-agents%E2%80%94and-why-oauth-must-evolve/">OAuth への提案</a> により、エージェントが自分自身の代理として、ユーザーの代理として、または別のエージェントの代理として動作していることを識別できるようになります。</p><p>さらに、全体的な連鎖についても考えています。下流のエージェントが必要な権限をどのように発見し要求するのか、これらの機能は MCP に組み込まれ、エージェント間プロトコルを実現します。</p><p>また、エージェントに広範なクラウド全体ではなく、特定のフォルダーなどのリソースへのきめ細かなアクセスを付与する方法にも取り組んでいます。エージェントに必要なアクセス権だけを与えるというゼロ トラストの原則を守ることは、リスクを減らす優れた方法です。</p><h2 id="SCIM-標準の拡張-エージェントのライフサイクル管理"><a href="#SCIM-標準の拡張-エージェントのライフサイクル管理" class="headerlink" title="SCIM 標準の拡張: エージェントのライフサイクル管理"></a>SCIM 標準の拡張: エージェントのライフサイクル管理</h2><p>OAuth の取り組みに加えて、エージェント対応を可能にするため、<a href="https://techcommunity.microsoft.com/blog/microsoft-entra-blog/beyond-oauth-why-scim-must-evolve-for-the-ai-agent-revolution/4433036">オープンな SCIM 標準への一連の変更</a> を提案しています。</p><p>現在の SCIM の仕組みでは、HR システムからユーザーを Entra に登録し、Entra でユーザーのレコードを作成し、その後ガバナンス システムを通じて他のアプリにユーザーがプロビジョニングされます。</p><p>エージェントにも同じ仕組みが必要です。あらゆるエージェント ビルダー (エージェントを作成する仕組み) は、SCIM を使ってエージェントのレコードを Entra に登録できる必要があります。そして Entra は、そのエージェント レコードを取得し、すべての SaaS アプリに対して正しく構成できるようにするという流れです。</p><p><img src="/blog/azure-active-directory/riding-the-ai-wave-how-microsoft-entra-is-evolving-for-the-agentic-era/riding-the-ai-wave-how-microsoft-entra-is-evolving-for-the-agentic-era4.png" alt="オープン標準へのスキーマ拡張を標準化することで、アプリケーションが必要とする豊富なコンテキストを持つエージェントのプロビジョニングが可能になります。"></p><p>これこそが、エージェントに関する優れたガバナンスと自動化を実現する正しい方法だと考えています。エージェントを登録するのは簡単ですが、継続的に管理するのははるかに難しい。そのため、SCIM の更新が必要なのです。</p><h2 id="今すぐやるべきこと"><a href="#今すぐやるべきこと" class="headerlink" title="今すぐやるべきこと"></a>今すぐやるべきこと</h2><p>まず、AI エージェントを使って色々と実験してみることをお勧めします。そして、自社にとってどのように役立つかを確認ください。<a href="https://learn.microsoft.com/ja-jp/entra/security-copilot/entra-agents">Microsoft Entra エージェント</a> を試すか、<a href="https://learn.microsoft.com/ja-jp/microsoft-copilot-studio/">Copilot Studio</a> で独自のエージェントを構築してみましょう。様々なことができてきっと驚くはずです。私のプロダクト管理チームでは、以前は 3 ～ 4 週間かかっていた作業が、エージェントを使うことで 2 ～ 3 日で完了するようになりました。まずはパイロット導入の <a href="https://www.microsoft.com/en-us/microsoft-copilot/blog/copilot-studio/how-to-deploy-transformational-enterprise-wide-agents-microsoft-as-customer-zero/">計画を立てることをお勧めします</a>。</p><p>次に、エージェントの分類 (タクソノミー) を検討ください。先ほど説明した 3 種類のエージェントから始めるのがお勧めです。どんなエージェントを構築するか？どのようなデータが必要か？アクセスをどうガバナンスし、高い権限が必要なデータを信頼できるエージェントだけが扱えるようにするか？など、構築、管理、ガバナンスを検討する際に <a href="https://adoption.microsoft.com/ja-jp/ai-agents/copilot-studio/">役立つリソース</a> が Copilot Studio チームから提供されています。</p><p>最後に、Ignite のライブ配信を視聴ください。11 月 18 日の Microsoft Ignite 2025 で開催される <a href="https://ignite.microsoft.com/en-US/sessions/BRK265">Secure Access for AI Agents with Microsoft Entra</a> セッションに参加ください。ここで仕組みについて詳しく解説する予定です。</p><p>弊社は、皆さんのため、そして皆さんと共に、この難しい課題に取り組んでいます。Microsoft Entra の AI エージェント対応は、企業で AI エージェントを安全に活用するための優れたツールを提供します。Satya が BUILD で言ったとおりです: 私たちの目標はシンプルです ―― 従業員 ID に適用している保護と制御を、AI エージェントにも提供することなのです。</p><p>エージェントの波が押し寄せています。波に乗るか、波にのまれるか ―― 選ぶのは私たちです。</p><p><strong>さぁ、波に乗っていきましょう！</strong></p><p>Alex</p>]]>
    </content>
    <id>https://jpazureid.github.io/blog/azure-active-directory/riding-the-ai-wave-how-microsoft-entra-is-evolving-for-the-agentic-era/</id>
    <link href="https://jpazureid.github.io/blog/azure-active-directory/riding-the-ai-wave-how-microsoft-entra-is-evolving-for-the-agentic-era/"/>
    <published>2025-12-12T00:00:00.000Z</published>
    <summary>
      <![CDATA[<p>こんにちは、Azure Identity サポート チームの 五十嵐 です。</p>
<p>本記事は、2025 年 11 月 11 日に米国の Microsoft Entra (Azure AD) Blog で公開された <a href="https://techcommu]]>
    </summary>
    <title>AI の大波に乗る: エージェント時代に向けた Microsoft Entra の進化</title>
    <updated>2026-08-12T00:07:05.190Z</updated>
  </entry>
  <entry>
    <author>
      <name>Azure Identity Support Japan</name>
    </author>
    <category term="Microsoft Entra" scheme="https://jpazureid.github.io/blog/tags/Microsoft-Entra/"/>
    <category term="US Identity Blog" scheme="https://jpazureid.github.io/blog/tags/US-Identity-Blog/"/>
    <content>
      <![CDATA[<p>こんにちは、Azure Identity サポート チームの三輪です。</p><p>本記事は、2025 年 11 月 5 日に米国の Microsoft Entra (Azure AD) Blog で公開された <a href="https://techcommunity.microsoft.com/blog/microsoft-entra-blog/driving-cloud-first-identity-user-soa-is-now-public-preview-and-group-soa-is-gen/4462425">Driving cloud-first identity: User SOA is now Public Preview and Group SOA is Generally Available</a> の抄訳です。ご不明点等ございましたらサポート チームまでお問い合わせください。</p><hr><h2 id="ユーザーやグループをクラウドでの管理に移行することで、ハイブリッド管理の複雑さを省きセキュリティ体制を強化しましょう。"><a href="#ユーザーやグループをクラウドでの管理に移行することで、ハイブリッド管理の複雑さを省きセキュリティ体制を強化しましょう。" class="headerlink" title="ユーザーやグループをクラウドでの管理に移行することで、ハイブリッド管理の複雑さを省きセキュリティ体制を強化しましょう。"></a>ユーザーやグループをクラウドでの管理に移行することで、ハイブリッド管理の複雑さを省きセキュリティ体制を強化しましょう。</h2><p>8 月に、グループの Source of Authority（SOA）変換の機能を使用することで、組織がクラウド上でレガシー グループを管理できるようになりました。この機能により、オンプレミス環境をより簡素化でき、Active Directory（AD）に依存するアプリにもガバナンスを拡張できることを紹介しました。本日、ハイブリッド環境のセキュリティ体制の強化に役立つ以下の 2 つの重要なアップデートを発表いたします。</p><ul><li>グループの SOA 変換が一般公開されました。</li><li>ユーザーの SOA 変換がパブリック プレビューとなりました。</li></ul><h2 id="このアップデートが重要な理由"><a href="#このアップデートが重要な理由" class="headerlink" title="このアップデートが重要な理由"></a>このアップデートが重要な理由</h2><p>Active Directory (AD) とクラウドの両方で ID を管理する煩雑さは長年の悩みの種でした。以下の新しい機能により、その煩わしさが解消されます。</p><ul><li><a href="https://learn.microsoft.com/ja-jp/entra/identity/hybrid/user-source-of-authority-overview">ユーザーの Source of Authority (SOA)</a> 変換を利用すると、AD から同期されたユーザーをクラウド上で編集可能なオブジェクトに変換することができます。この機能により、組織の運用上の負荷が軽減され、クラウド上でのユーザー管理、条件付きアクセス、MFA、パスワードレス認証などの高度な ID の機能が利用できるようになります。</li><li><a href="https://learn.microsoft.com/ja-jp/entra/identity/hybrid/concept-source-of-authority-overview">グループの Source of Authority (SOA)</a> 変換を利用すると、AD から同期されたセキュリティ グループを Microsoft Entra ID で編集可能なクラウド オブジェクトに変換することができます。またこの機能を利用しながらも、オプションとしてクラウド同期のライトバックの機能を追加で設定することで、オンプレミスのアプリとの互換性を維持することも可能です。グループの SOA では、メールが有効なセキュリティ グループや配布リストをクラウド上の Exchange で管理されるグループに変換することもでき、不要になったグループを AD から削除するのにも役立ちます。</li></ul><p>これらの機能を組み合わせて利用することで、組織は AD への投資を最小限に抑えるとともに、ライフサイクル管理がよりシンプルになり、ゼロトラストのセキュリティ体制を強化することができます。</p><h2 id="シナリオ-ユーザーの-SOA-とグループの-SOA-を用いたハイブリッド-ID-のセキュリティ強化"><a href="#シナリオ-ユーザーの-SOA-とグループの-SOA-を用いたハイブリッド-ID-のセキュリティ強化" class="headerlink" title="シナリオ - ユーザーの SOA とグループの SOA を用いたハイブリッド ID のセキュリティ強化"></a>シナリオ - ユーザーの SOA とグループの SOA を用いたハイブリッド ID のセキュリティ強化</h2><p>とある組織がクラウド ファーストの ID のモデルへ移行しようとしているとしましょう。しかしその組織は依然として重要なオンプレミスのアプリケーションに依存しています。この組織の ID 担当チームは、クラウドへの完全移行を待つ代わりに、まずリスクの高いユーザーの一部をユーザーの SOA 変換を使ってクラウドで編集可能なユーザー ID に変換することにしました。同時に、それらオンプレミスのアプリケーションに関連する AD 上のセキュリティ グループをグループの SOA 変換を利用してクラウドへ移行し、Microsoft Entra ID 上で完全に管理できるようにすることで、セキュリティとガバナンス機能を強化することが可能となりました。</p><p>このユーザーの SOA とグループの SOA を組み合わせたアプローチは、組織に対して即時に利益をもたらします。IT 管理者は Microsoft Entra 管理センターや Microsoft Graph API を用いて、ユーザー ID、グループ、アクセス ポリシーを一元管理でき、運用をシンプルにして複雑さを軽減できます。これまで手動のプロセスによって行われていたガバナンスは、エンタイトルメント管理、アクセス レビュー、ライフサイクル ワークフローによって自動化され、これにより重要なアプリケーションのコンプライアンスがより強化されます。</p><p>セキュリティは劇的に向上します。従業員はクラウドとオンプレミスの両方のアプリに対して、Microsoft Entra ID の資格情報 (パスワードレス オプションを含む) でサインインできるようになります。リスクベースの条件付きアクセス ポリシーがシームレスに適用されることで、パスワード疲労攻撃や資格情報の乱立を減らし、ゼロトラストの原則が強化されます。</p><p>移行は柔軟に進めることができます。一部のユーザーとグループから変換を開始することで、業務が中断されることなく、既存の同期フローも維持できます。時間をかけて独自のペースで Microsoft Graph API や Microsoft Entra 管理センターを使用しながらクラウドへの変換対象を拡大していくことが可能です。</p><p>その結果、お客様はレガシーなアプリを意図せず停止させたり、完全な移行を待ったりすることなく、クラウドでの一元管理および自動化されたガバナンス、そしてより強力なセキュリティを手に入れることができるのです。</p><p>以下の動画では、詳細な仕組みや実際の動作をご紹介しています。</p><p><a href="https://www.youtube.com/watch?v=otxp_KIqU4Y"><img src="https://img.youtube.com/vi/otxp_KIqU4Y/0.jpg" alt="YouTube"></a></p><p>これらの新機能は、追加の料金なく無料でご利用いただけます。Microsoft Entra Free ライセンスで利用可能です。ぜひご自身の環境でお試しいただき、その効果を直接体験してみてください。</p><ul><li>詳細はこちら: <a href="https://aka.ms/usersoadocs">https://aka.ms/usersoadocs</a> | <a href="https://aka.ms/groupsoadocs">https://aka.ms/groupsoadocs</a></li><li>解説動画を見る: <a href="https://www.youtube.com/watch?v=otxp_KIqU4Y">Source of Authority</a> | <a href="https://www.youtube.com/watch?v=AcBMPgpIsw4">Get to cloud-first model with Group Source of Authority: Deep Dive</a></li><li>IT アーキテクトへのガイダンス: <a href="https://aka.ms/SOAITArchitectsGuidance">https://aka.ms/SOAITArchitectsGuidance</a></li></ul><p>また、Micorosft Ignite に直接参加するかオンラインで参加いただき、ディープダイブやデモ、ディスカッションなど Microsoft Entra ID に関わる全てについて是非エキスパートとつながりをお持ちください。</p><p>Joe Dadzie – VP Product Management</p>]]>
    </content>
    <id>https://jpazureid.github.io/blog/azure-active-directory-connect/driving-cloud-first-identity-user-soa-is-now-public-preview-and-group-soa-is-gen/</id>
    <link href="https://jpazureid.github.io/blog/azure-active-directory-connect/driving-cloud-first-identity-user-soa-is-now-public-preview-and-group-soa-is-gen/"/>
    <published>2025-12-10T06:00:00.000Z</published>
    <summary>
      <![CDATA[<p>こんにちは、Azure Identity サポート チームの三輪です。</p>
<p>本記事は、2025 年 11 月 5 日に米国の Microsoft Entra (Azure AD) Blog で公開された <a href="https://techcommunity]]>
    </summary>
    <title>クラウド ファーストの ID 管理 - ユーザー SOA がパブリック プレビューかつグループ SOA も一般公開に</title>
    <updated>2026-08-12T00:07:04.150Z</updated>
  </entry>
  <entry>
    <author>
      <name>Azure Identity Support Japan</name>
    </author>
    <category term="Microsoft Entra" scheme="https://jpazureid.github.io/blog/tags/Microsoft-Entra/"/>
    <category term="US Identity Blog" scheme="https://jpazureid.github.io/blog/tags/US-Identity-Blog/"/>
    <content>
      <![CDATA[<p>こんにちは、Azure Identity サポート チームの 高田 です。</p><p>本記事は、2025 年 10 月 17 日に米国の Microsoft Entra Blog で公開された <a href="https://techcommunity.microsoft.com/blog/microsoft-entra-blog/what%E2%80%99s-new-in-microsoft-entra-%E2%80%93-september-2025/4352576">What’s new in Microsoft Entra – September 2025</a> の抄訳です。ご不明点等ございましたらサポート チームまでお問い合わせください。</p><hr><h2 id="Microsoft-Entra-の最新機能や変更発表についてお知らせします"><a href="#Microsoft-Entra-の最新機能や変更発表についてお知らせします" class="headerlink" title="Microsoft Entra の最新機能や変更発表についてお知らせします"></a>Microsoft Entra の最新機能や変更発表についてお知らせします</h2><p>マイクロソフトは Microsoft Entra に高度な AI 駆動のセキュリティ機能を導入し、インテリジェントな自動化を通じて ID 保護を強化しています。Microsoft Entra の Security Copilot は、アクセスのガバナンスを改善するために AI に基づく知見と推奨事項を組織に提供し、加えて条件付きアクセスの最適化エージェントは、新たな脅威に効果的に対応するとともに、対応プロセスをより効率化するために継続的にポリシーを分析します。これらのソリューションにより、セキュリティ運用の中核に AI が統合され、より効率的な意思決定、強固な防御、そして ID 管理におけるより高い保証レベルの実現を支援します。</p><p>ここでは、2025 年 7 月から 2025 年 9 月までの Microsoft Entra における最新のセキュリティ改善と革新を、製品別に整理してご紹介いたします。</p><h2 id="Microsoft-Entra-–-セキュリティを高める-AI"><a href="#Microsoft-Entra-–-セキュリティを高める-AI" class="headerlink" title="Microsoft Entra – セキュリティを高める AI"></a>Microsoft Entra – セキュリティを高める AI</h2><h3 id="新機能のリリース"><a href="#新機能のリリース" class="headerlink" title="新機能のリリース"></a>新機能のリリース</h3><ul><li><a href="https://learn.microsoft.com/ja-jp/entra/security-copilot/security-copilot-in-entra">Microsoft Entra における Security Copilot</a></li><li><a href="https://learn.microsoft.com/ja-jp/entra/identity/conditional-access/agent-optimization">Microsoft Entra の条件付きアクセスの最適化エージェント</a></li><li><a href="https://learn.microsoft.com/ja-jp/entra/identity/conditional-access/agent-optimization#agent-capabilities">条件付きアクセス エージェントがエージェントによるレポート専用ポリシーの作成を無効化する機能をサポート</a></li></ul><h2 id="Microsoft-Entra-ID"><a href="#Microsoft-Entra-ID" class="headerlink" title="Microsoft Entra ID"></a>Microsoft Entra ID</h2><h3 id="新機能のリリース-1"><a href="#新機能のリリース-1" class="headerlink" title="新機能のリリース"></a>新機能のリリース</h3><ul><li><a href="https://learn.microsoft.com/ja-jp/entra/identity/devices/macos-psso">Microsoft Entra ID を用いた macOS 向けのプラットフォーム SSO</a></li><li><a href="https://learn.microsoft.com/ja-jp/entra/identity/authentication/how-to-authentication-qr-code">フロントラインワーカー向けの QR + PIN のシンプルな認証方法</a></li><li><a href="https://learn.microsoft.com/ja-jp/graph/templates/bicep/overview-bicep-templates-for-graph">Microsoft Graph リソース用の Bicep テンプレート</a></li><li><a href="https://learn.microsoft.com/ja-jp/entra/fundamentals/whats-new#general-availability---conditional-access-what-if-api">条件付きアクセスの What If API</a></li><li><a href="https://learn.microsoft.com/ja-jp/entra/fundamentals/whats-new#general-availability---enterprise-app-sso-via-pre-integrated-gallery-app-or-customer-saml-apps">事前統合されたギャラリー アプリやカスタムの SAML アプリを使ったエンタープライズ アプリの SSO</a></li><li><a href="https://learn.microsoft.com/ja-jp/entra/identity/role-based-access-control/admin-units-restricted-management">制限付きの管理単位</a></li></ul><h3 id="変更のお知らせ"><a href="#変更のお知らせ" class="headerlink" title="変更のお知らせ"></a>変更のお知らせ</h3><h4 id="2026-年-9-月-30-日までに最新バージョンの-Microsoft-Entra-Connect-へアップグレードが必要"><a href="#2026-年-9-月-30-日までに最新バージョンの-Microsoft-Entra-Connect-へアップグレードが必要" class="headerlink" title="2026 年 9 月 30 日までに最新バージョンの Microsoft Entra Connect へアップグレードが必要"></a>2026 年 9 月 30 日までに最新バージョンの Microsoft Entra Connect へアップグレードが必要</h4><p>[お客様によっては対応が必要です]</p><p>Microsoft は、Active Directory と Microsoft Entra ID 間の安全な同期をサポートするために、ファーストパーティーのサービス プリンシパルである Microsoft Entra AD Synchronization Service (アプリ ID: 6bf85cfa-ac8a-4be5-b5de-425a0d0dc016) を導入しました。このアプリケーションは、Microsoft Entra Connect を経由したオンプレミスから Entra ID への同期に不可欠であり、管理センターのエンタープライズ アプリケーションの個所から管理可能です。</p><p>Microsoft Entra Connect は現在、このファーストパーティ アプリケーションを使って Active Directory と Microsoft Entra ID 間の同期を行っています。お客様は <strong>2026 年 9 月</strong> までにバージョン <strong>2.5.79.0</strong> 以降へのアップグレードが必要です。</p><p>今後のリリースのタイムラインについては <a href="https://entra.microsoft.com/#view/Microsoft_AAD_IAM/ChangeManagementHubList.ReactView">ロードマップ</a> をご確認いただき、アップグレード計画をお立てください。サポートされている場合は、弊社からお客様環境を自動アップグレードする予定です。自動アップグレードを希望するお客様は、自動アップグレードの設定を必ず実施ください。</p><p>サービス変更による最低要件および予想される影響の一覧については、<a href="https://aka.ms/aws1stpartyapp">この記事</a> をご参照ください。アップグレードに関するアドバイスについては、<a href="https://learn.microsoft.com/entra/identity/hybrid/connect/how-to-upgrade-previous-version">当社のドキュメント</a> をご覧ください。</p><h4 id="すべての-Android-ユーザーに対してブラウザー-アクセスが既定で有効化"><a href="#すべての-Android-ユーザーに対してブラウザー-アクセスが既定で有効化" class="headerlink" title="すべての Android ユーザーに対してブラウザー アクセスが既定で有効化"></a>すべての Android ユーザーに対してブラウザー アクセスが既定で有効化</h4><p>[お客様によっては対応が必要です]</p><p><a href="https://jpazureid.github.io/blog/azure-active-directory/whats-new-in-microsoft-entra-in-202409/">2024 年 9 月</a> に発表されたとおり、継続的なセキュリティ強化の一環として、Android 向けの Authenticator および Company Portal アプリにおける Enable Browser Access (EBA) ユーザー インターフェースを廃止します。したがって、2026 年 3 月からすべての Android ユーザーに対して既定でブラウザー アクセスが有効になります。この変更は自動的に行われるため、管理者や Android ユーザーの対応は不要です。</p><p>お客様が Android モバイル デバイス管理 (MDM) の提供事業者である場合は、デバイス登録時にブラウザー アクセスを有効にするための <a href="https://aka.ms/MDMBrowserAccessGuidance">ドキュメント</a> をご確認ください。</p><h4 id="ADAL-から-MSAL-への移行に関する推奨事項-API-の廃止"><a href="#ADAL-から-MSAL-への移行に関する推奨事項-API-の廃止" class="headerlink" title="ADAL から MSAL への移行に関する推奨事項 API の廃止"></a>ADAL から MSAL への移行に関する推奨事項 API の廃止</h4><p>[お客様によっては対応が必要です]</p><p>ADAL から MSAL への移行に関する推奨事項の API は <strong>2025 年 12 月 15 日</strong> に廃止されます。この日以降、管理者は Microsoft Entra Recommendations の機能において「ADAL から MSAL への移行」の推奨事象を確認できなくなり、API 経由でも取得できなくなります。</p><p>代わりに、<strong>サインイン ログを Microsoft Graph API 経由で直接照会する</strong> ことをお勧めします。管理者は Entra のサインイン ログで、特に <strong>Azure AD App Authentication Library</strong> フィールドの配下にある authenticationProcessingDetails フィールドを参照することで、各リクエストに使用されている認証ライブラリを特定いただけます。</p><p>以下の対応を実施ください:</p><ul><li>API を無効化するためにお客様側での対応は不要であり、自動的に廃止されます。</li><li>ユーザーに通知し、ドキュメントを更新するとともに、認証ライブラリを追跡を行う際は Microsoft Graph API によるクエリに移行します。</li></ul><h4 id="廃止-Microsoft-Entra-管理センターにおけるアプリのサインイン-フィールドの自動取得"><a href="#廃止-Microsoft-Entra-管理センターにおけるアプリのサインイン-フィールドの自動取得" class="headerlink" title="廃止 - Microsoft Entra 管理センターにおけるアプリのサインイン フィールドの自動取得"></a>廃止 - Microsoft Entra 管理センターにおけるアプリのサインイン フィールドの自動取得</h4><p>[お客様によっては対応が必要です]</p><p>Microsoft Entra 管理センターにおける、アプリのサインイン フィールドを自動的に取得する機能が廃止されました。すでにこの機能を用いて設定されている既存のアプリは引き続き動作しますが、新規での設定においてはこの機能は利用できません。今後は、[サインイン フィールドの取り込み] をご利用ください。これには Microsoft Edge と Chrome で利用可能な MyApps Secure Sign-In の拡張機能が必要です。</p><p>詳細は <a href="https://learn.microsoft.com/ja-jp/entra/identity/enterprise-apps/troubleshoot-password-based-sso#capture-sign-in-fields-for-an-app">アプリのサインイン フィールドをキャプチャする</a> をご覧ください。</p><h4 id="リクエストの送信者が-My-Access-で自身のアクセス-パッケージの承認者が誰かを確認可能に"><a href="#リクエストの送信者が-My-Access-で自身のアクセス-パッケージの承認者が誰かを確認可能に" class="headerlink" title="リクエストの送信者が My Access で自身のアクセス パッケージの承認者が誰かを確認可能に"></a>リクエストの送信者が My Access で自身のアクセス パッケージの承認者が誰かを確認可能に</h4><p>[お客様によっては対応が必要です]</p><p><a href="https://learn.microsoft.com/ja-jp/entra/fundamentals/whats-new#plan-for-change---new-end-user-homepage-in-my-account">以前にお知らせした</a> とおり、リクエストの送信者が My Access ポータルで、保留中のアクセス パッケージの承認者の名前と E メール アドレスを直接確認できるようになります。この機能は、透明性を高め、依頼者と承認者間のコミュニケーションを効率化することを目的としています。既定では、ゲストを除くすべてのメンバーはテナント レベルで承認者を確認でき、この設定は Microsoft Entra 管理センターのエンタイトルメント管理にて変更することも可能です。アクセス パッケージのレベルでは、管理者や所有者が詳細設定を使用することで、承認者の見える&#x2F;見えないを変更したり、テナント設定を上書きしたりが可能です。 </p><h4 id="My-Account-の新しいエンド-ユーザー向けホームページ"><a href="#My-Account-の新しいエンド-ユーザー向けホームページ" class="headerlink" title="My Account の新しいエンド ユーザー向けホームページ"></a>My Account の新しいエンド ユーザー向けホームページ</h4><p>[お客様によっては対応が必要です]</p><p><a href="https://learn.microsoft.com/ja-jp/entra/fundamentals/whats-new#plan-for-change---new-end-user-homepage-in-my-account">以前にお知らせした</a> とおり、<a href="https://myaccount.microsoft.com/">https://myaccount.microsoft.com</a> のホームページはよりタスクに特化したユーザー体験を提供するために更新される予定です。ユーザーは、期限切れのグループの更新や、アクセス パッケージの承認、MFA の設定など、保留中のアクションをホームページ上で直接確認できるようになります。アプリ、グループ、アクセス パッケージ、サインイン情報へ素早くアクセスできるリンクがより見つけやすく、使いやすくなります。この変更によりアカウント管理が効率化し、ユーザーがアクセスやセキュリティに関するタスクを常に把握できるようになります。</p><h4 id="ライセンスの使用状況ブレードの-UI-および-Entra-のライセンス指標に対する更新"><a href="#ライセンスの使用状況ブレードの-UI-および-Entra-のライセンス指標に対する更新" class="headerlink" title="ライセンスの使用状況ブレードの UI および Entra のライセンス指標に対する更新"></a>ライセンスの使用状況ブレードの UI および Entra のライセンス指標に対する更新</h4><p>[お客様による対応は不要です]</p><p>ライセンスの使用状況のブレードを更新し、UI を改善するとともに、上部のウィジェットに Entra 全体の新しいライセンス指標を導入します。これによりすべてのライセンスにわたり機能の使用状況を表示します。これにより管理者やマネージャーは製品の採用状況と利用状況を包括的に把握できるようになります。お客様側での対応は必要ありません。</p><h4 id="Microsoft-Entra-ID-無料サブスクリプションの展開"><a href="#Microsoft-Entra-ID-無料サブスクリプションの展開" class="headerlink" title="Microsoft Entra ID 無料サブスクリプションの展開"></a>Microsoft Entra ID 無料サブスクリプションの展開</h4><p>Microsoft は、Microsoft Entra テナントの所有権の追跡を目的として、請求に使用されているアカウント情報を活用し、無料の Microsoft Entra ID Free サブスクリプションを今後各テナントに展開します。10 月から Microsoft 365 および Azure ポータルにこのサブスクリプションが登場しますが、お客様側の対応は不要で、請求や機能にも影響を与えません。これはテナントの所有権を安全に管理するためのものです。</p><h4 id="Microsoft-Entra-認証情報の登録と管理の-UX-を刷新"><a href="#Microsoft-Entra-認証情報の登録と管理の-UX-を刷新" class="headerlink" title="Microsoft Entra: 認証情報の登録と管理の UX を刷新"></a>Microsoft Entra: 認証情報の登録と管理の UX を刷新</h4><p>[お客様による対応は不要です]</p><p>Microsoft Entra は 2025 年 11 月に認証情報の登録および管理インターフェースを更新し、使いやすさとアクセシビリティを向上させます。お客様側での対応は特に必要ありませんが、スムーズな移行のため、事前にヘルプデスクに情報を共有しておくことをお勧めします。本変更に関してコンプライアンス上の懸念はございません。</p><h2 id="Microsoft-Entra-ID-Protection"><a href="#Microsoft-Entra-ID-Protection" class="headerlink" title="Microsoft Entra ID Protection"></a>Microsoft Entra ID Protection</h2><h3 id="新機能のリリース-2"><a href="#新機能のリリース-2" class="headerlink" title="新機能のリリース"></a>新機能のリリース</h3><ul><li><a href="https://learn.microsoft.com/ja-jp/entra/fundamentals/whats-new#general-availability---microsoft-entra-id-protection-improved-detection-quality">Microsoft Entra ID Protection: 検出品質の向上</a></li></ul><h2 id="Microsoft-Entra-ID-ガバナンス"><a href="#Microsoft-Entra-ID-ガバナンス" class="headerlink" title="Microsoft Entra ID ガバナンス"></a>Microsoft Entra ID ガバナンス</h2><h3 id="新機能のリリース-3"><a href="#新機能のリリース-3" class="headerlink" title="新機能のリリース"></a>新機能のリリース</h3><ul><li><a href="https://learn.microsoft.com/ja-jp/entra/identity/multi-tenant-organizations/cross-tenant-synchronization-configure">テナント間同期 (クラウド間)</a></li><li><a href="https://learn.microsoft.com/ja-jp/entra/fundamentals/whats-new#general-availability---application-based-authentication-on-microsoft-entra-connect-sync">Microsoft Entra Connect Sync におけるアプリケーションベースの認証</a></li><li><a href="https://learn.microsoft.com/ja-jp/entra/id-governance/lifecycle-workflow-tasks#revoke-all-refresh-tokens-for-user">リフレッシュ トークンを取り消す新しいライフサイクル ワークフロー タスク</a></li><li><a href="https://learn.microsoft.com/ja-jp/entra/fundamentals/whats-new#general-availability---audit-administrator-events-in-microsoft-entra-connect-sync">Microsoft Entra Connect Sync における管理者イベントの監査</a></li></ul><h2 id="Microsoft-Entra-External-ID"><a href="#Microsoft-Entra-External-ID" class="headerlink" title="Microsoft Entra External ID"></a>Microsoft Entra External ID</h2><h3 id="新機能のリリース-4"><a href="#新機能のリリース-4" class="headerlink" title="新機能のリリース"></a>新機能のリリース</h3><ul><li><a href="https://learn.microsoft.com/ja-jp/entra/identity-platform/quickstart-native-authentication-single-page-app-sdk-sign-in?tabs=react">Microsoft Entra External ID におけるサインイン、サインアップ、サインアウト体験を実現するネイティブ認証 JavaScript SDK の有効化</a></li><li><a href="https://learn.microsoft.com/ja-jp/entra/identity-platform/custom-extension-email-otp-get-started?tabs=azure-communication-services,azure-portal">Microsoft Entra External ID: カスタム サードパーティ E メール OTP プロバイダー</a></li></ul><p>よろしくお願いいたします</p><p>Shobhit Sahay</p>]]>
    </content>
    <id>https://jpazureid.github.io/blog/azure-active-directory/whats-new-in-microsoft-entra-september-2025/</id>
    <link href="https://jpazureid.github.io/blog/azure-active-directory/whats-new-in-microsoft-entra-september-2025/"/>
    <published>2025-12-07T00:00:00.000Z</published>
    <summary>
      <![CDATA[<p>こんにちは、Azure Identity サポート チームの 高田 です。</p>
<p>本記事は、2025 年 10 月 17 日に米国の Microsoft Entra Blog で公開された <a href="https://techcommunity.microso]]>
    </summary>
    <title>Microsoft Entra の新情報 – 2025 年 9 月</title>
    <updated>2026-08-12T00:07:05.382Z</updated>
  </entry>
</feed>
