Azure Active Directory B2C カスタムポリシーを使用してユーザーアカウントを作成して読み取る

2025-05-03

重要

2025 年 5 月 1 日より、Azure AD B2C は新規のお客様向けに購入できなくなります。詳細については、FAQ を参照してください。

Azure Active Directory B2C (Azure AD B2C) は Microsoft Entra ID に基づいて構築されているため、Microsoft Entra ID ストレージを使用してユーザーアカウントを格納します。 Azure AD B2C ディレクトリユーザープロファイルには、指定された名前、姓、市区町村、郵便番号、電話番号などの属性の組み込みセットが付属していますが、外部データストアを必要とせずに、独自のカスタム属性を使用してユーザープロファイルを拡張できます。

カスタムポリシーは、Microsoft Entra ID 技術プロファイルを使用してユーザー情報を格納、更新、または削除することで、 Microsoft Entra ID ストレージに接続できます。この記事では、JWT が返される前にユーザーアカウントを格納して読み取る一連の Microsoft Entra ID 技術プロファイルを構成する方法について説明します。

シナリオの概要

「Azure Active Directory B2C カスタムポリシーを使用して REST API を呼び出す」の記事では、ユーザーから情報を収集し、データを検証し、REST API と呼ばれ、最後にユーザーアカウントを格納せずに JWT を返しました。ポリシーの実行が完了した後に情報を失わないように、ユーザー情報を格納する必要があります。今回は、ユーザー情報を収集して検証したら、ユーザー情報を Azure AD B2C ストレージに格納し、JWT を返す前に読み取る必要があります。完全なプロセスを次の図に示します。

Azure AD でユーザーアカウントを作成するフローチャート。

[前提条件]

まだお持ちでない場合は、Azure サブスクリプションにリンクされている Azure AD B2C テナントを作成します。
Web アプリケーションを登録します。
コンピューターに Visual Studio Code (VS Code) がインストールされている必要があります。
「Azure Active Directory B2C カスタムポリシーを使用して REST API を呼び出す」の手順を完了します。この記事は、独自のカスタムポリシーの作成と実行のハウツーガイドシリーズの一部です。

注

この記事は、 Azure Active Directory B2C での独自のカスタムポリシーの作成と実行に関するハウツーガイドシリーズの一部です。最初の記事からこのシリーズを開始することをお勧めします。

手順 1 - 要求を宣言する

userPrincipalNameとpasswordPoliciesの 2 つの要求をさらに宣言する必要があります。

ContosoCustomPolicy.XML ファイルで ClaimsSchema 要素を見つけ、次のコードを使用してuserPrincipalName要求とpasswordPolicies要求を宣言します。

    <ClaimType Id="userPrincipalName">
        <DisplayName>UserPrincipalName</DisplayName>
        <DataType>string</DataType>
        <UserHelpText>Your user name as stored in the Azure Active Directory.</UserHelpText>
    </ClaimType>
    <ClaimType Id="passwordPolicies">
        <DisplayName>Password Policies</DisplayName>
        <DataType>string</DataType>
        <UserHelpText>Password policies used by Azure AD to determine password strength, expiry etc.</UserHelpText>
    </ClaimType>

userPrincipalNameに関する記事のpasswordPolicies要求と要求の使用方法の詳細について説明します。

手順 2 - Microsoft Entra ID 技術プロファイルを作成する

2 つの Microsoft Entra ID 技術プロファイルを構成する必要があります。 1 つの技術プロファイルはユーザーの詳細を Microsoft Entra ID ストレージに書き込み、もう 1 つは Microsoft Entra ID ストレージからユーザーアカウントを読み取ります。

ContosoCustomPolicy.XML ファイルで ClaimsProviders 要素を見つけ、次のコードを使用して新しいクレームプロバイダーを追加します。このクレームプロバイダーは、Microsoft Entra ID 技術プロファイルを保持します。
```
    <ClaimsProvider>
        <DisplayName>Azure AD Technical Profiles</DisplayName>
        <TechnicalProfiles>
            
        </TechnicalProfiles>
    </ClaimsProvider>
```

先ほど作成したクレームプロバイダーで、次のコードを使用して Microsoft Entra ID 技術プロファイルを追加します。

    <TechnicalProfile Id="AAD-UserWrite">
        <DisplayName>Write user information to AAD</DisplayName>
        <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.AzureActiveDirectoryProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
        <Metadata>
            <Item Key="Operation">Write</Item>
            <Item Key="RaiseErrorIfClaimsPrincipalAlreadyExists">true</Item>
            <Item Key="UserMessageIfClaimsPrincipalAlreadyExists">The account already exists. Try to create another account</Item>
        </Metadata>
        <InputClaims>
            <InputClaim ClaimTypeReferenceId="email" PartnerClaimType="signInNames.emailAddress" Required="true" />
        </InputClaims>
        <PersistedClaims>
            <PersistedClaim ClaimTypeReferenceId="email" PartnerClaimType="signInNames.emailAddress" />        
            <PersistedClaim ClaimTypeReferenceId="displayName" />
            <PersistedClaim ClaimTypeReferenceId="givenName" />
            <PersistedClaim ClaimTypeReferenceId="surname" />
            <PersistedClaim ClaimTypeReferenceId="password"/>
            <PersistedClaim ClaimTypeReferenceId="passwordPolicies" DefaultValue="DisablePasswordExpiration,DisableStrongPassword" />
        </PersistedClaims>
        <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="objectId" />
            <OutputClaim ClaimTypeReferenceId="userPrincipalName" />
            <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="signInNames.emailAddress" />
        </OutputClaims>
    </TechnicalProfile>

新しい Microsoft Entra ID 技術プロファイル ( AAD-UserWrite) が追加されました。技術プロファイルの次の重要な部分をメモする必要があります。

操作: 操作は、実行するアクション (この場合は Write) を指定します。 Microsoft Entra ID 技術プロバイダーのその他の操作の詳細について説明します。
永続的なクレーム: PersistedClaims 要素には、Microsoft Entra ID ストレージに格納する必要があるすべての値が含まれています。
InputClaims: InputClaims 要素には要求が含まれています。これは、ディレクトリ内のアカウントを検索したり、新しいアカウントを作成したりするために使用されます。すべての Microsoft Entra ID 技術プロファイルに対して、入力要求コレクションに入力要求要素が 1 つだけ存在する必要があります。この技術プロファイルでは、ユーザーアカウントのキー識別子として 電子メール 要求が使用されます。ユーザーアカウントを一意に識別するために使用できるその他のキー識別子について説明します。

ContosoCustomPolicy.XML ファイルで、AAD-UserWrite技術プロファイルを見つけ、その後に次のコードを使用して新しい技術プロファイルを追加します。

    <TechnicalProfile Id="AAD-UserRead">
        <DisplayName>Read user from Azure AD storage</DisplayName>
        <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.AzureActiveDirectoryProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
        <Metadata>
            <Item Key="Operation">Read</Item>
            <Item Key="RaiseErrorIfClaimsPrincipalAlreadyExists">false</Item>
            <Item Key="RaiseErrorIfClaimsPrincipalDoesNotExist">false</Item>
        </Metadata>
        <InputClaims>
            <InputClaim ClaimTypeReferenceId="email" PartnerClaimType="signInNames.emailAddress" Required="true" />
        </InputClaims>
        <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="objectId" />
            <OutputClaim ClaimTypeReferenceId="userPrincipalName" />
            <OutputClaim ClaimTypeReferenceId="givenName"/>
            <OutputClaim ClaimTypeReferenceId="surname"/>
            <OutputClaim ClaimTypeReferenceId="displayName"/>
        </OutputClaims>
    </TechnicalProfile>

新しい Microsoft Entra ID 技術プロファイル ( AAD-UserRead) が追加されました。この技術プロファイルは、読み取り操作を実行し、objectId セクションでuserPrincipalNameを持つユーザーアカウントが見つかった場合に、givenName、surname、displayName、email、およびInputClaim要求を返すように構成しました。

手順 3 - Microsoft Entra ID 技術プロファイルを使用する

UserInformationCollectorセルフアサート技術プロファイルを使用してユーザーの詳細を収集した後、AAD-UserWrite技術プロファイルを使用して Microsoft Entra ID ストレージにユーザーアカウントを書き込む必要があります。これを行うには、 AAD-UserWrite 技術プロファイルを、 UserInformationCollector セルフアサート技術プロファイルの検証技術プロファイルとして使用します。

ContosoCustomPolicy.XML ファイルで、UserInformationCollector技術プロファイルを見つけ、AAD-UserWrite技術プロファイルをValidationTechnicalProfilesコレクションに検証技術プロファイルとして追加します。これは、 CheckCompanyDomain 検証技術プロファイルの後に追加する必要があります。

JWT を発行する前に、ユーザー体験オーケストレーション手順の AAD-UserRead 技術プロファイルを使用して、ユーザーの詳細を読み取ります。

手順 4 - ClaimGenerator 技術プロファイルを更新する

ClaimGenerator技術プロファイルを使用して、GenerateRandomObjectIdTransformation、CreateDisplayNameTransformation、CreateMessageTransformation の 3 つの要求変換を実行します。

ContosoCustomPolicy.XML ファイルで、ClaimGenerator技術プロファイルを見つけて、次のコードに置き換えます。

    <TechnicalProfile Id="UserInputMessageClaimGenerator">
        <DisplayName>User Message Claim Generator Technical Profile</DisplayName>
        <Protocol Name="Proprietary"
            Handler="Web.TPEngine.Providers.ClaimsTransformationProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
        <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="message" />
        </OutputClaims>
        <OutputClaimsTransformations>
            <OutputClaimsTransformation ReferenceId="CreateMessageTransformation" />
        </OutputClaimsTransformations>
    </TechnicalProfile>

    <TechnicalProfile Id="UserInputDisplayNameGenerator">
        <DisplayName>Display Name Claim Generator Technical Profile</DisplayName>
        <Protocol Name="Proprietary"
            Handler="Web.TPEngine.Providers.ClaimsTransformationProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
        <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="displayName" />
        </OutputClaims>
        <OutputClaimsTransformations>
            <OutputClaimsTransformation ReferenceId="CreateDisplayNameTransformation" />
        </OutputClaimsTransformations>
    </TechnicalProfile>

技術プロファイルを 2 つの異なる技術プロファイルに分割しました。 UserInputMessageClaimGenerator 技術プロファイルは、JWT で要求として送信されたメッセージを生成します。 UserInputDisplayNameGenerator 技術プロファイルは、displayName要求を生成します。 displayName技術プロファイルがユーザーレコードを Microsoft Entra ID ストレージに書き込む前に、AAD-UserWrite要求値を使用できる必要があります。新しいコードでは、が作成され、アカウントの作成後に Microsoft Entra ID によって返されるため、objectId を削除するため、ポリシー内で自分で生成する必要はありません。

ContosoCustomPolicy.XML ファイルで、UserInformationCollectorセルフアサート技術プロファイルを見つけて、検証技術プロファイルとしてUserInputDisplayNameGenerator技術プロファイルを追加します。その後、 UserInformationCollector 技術プロファイルの ValidationTechnicalProfiles コレクションは次のコードのようになります。

    <!--<TechnicalProfile Id="UserInformationCollector">-->
        <ValidationTechnicalProfiles>
            <ValidationTechnicalProfile ReferenceId="CheckCompanyDomain">
                <Preconditions>
                    <Precondition Type="ClaimEquals" ExecuteActionsIf="false">
                        <Value>accountType</Value>
                        <Value>work</Value>
                        <Action>SkipThisValidationTechnicalProfile</Action>
                    </Precondition>
                </Preconditions>
            </ValidationTechnicalProfile>                        
            <ValidationTechnicalProfile ReferenceId="UserInputDisplayNameGenerator"/>
            <ValidationTechnicalProfile ReferenceId="AAD-UserWrite"/>
        </ValidationTechnicalProfiles>
    <!--</TechnicalProfile>-->

AAD-UserWriteの前に検証技術プロファイルを追加する必要があります。これは、displayName技術プロファイルがユーザーレコードをMicrosoft Entra IDストレージに書き込む前に、AAD-UserWriteの要求値が利用可能である必要があるためです。

手順 5 - ユーザー体験オーケストレーションの手順を更新する

ユーザージャーニーを見つけて、すべてのオーケストレーションステップを次のコードに置き換えてください。

    <!--<OrchestrationSteps>-->
        <OrchestrationStep Order="1" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="AccountTypeInputCollectorClaimsExchange" TechnicalProfileReferenceId="AccountTypeInputCollector"/>
            </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="2" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="GetAccessCodeClaimsExchange" TechnicalProfileReferenceId="AccessCodeInputCollector" />
            </ClaimsExchanges>
            </OrchestrationStep>
        <OrchestrationStep Order="3" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="GetUserInformationClaimsExchange" TechnicalProfileReferenceId="UserInformationCollector"/>
            </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="4" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="AADUserReaderExchange" TechnicalProfileReferenceId="AAD-UserRead"/>
            </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="5" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="GetMessageClaimsExchange" TechnicalProfileReferenceId="UserInputMessageClaimGenerator"/>
            </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="6" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer"/>
    <!--</OrchestrationSteps>-->

オーケストレーション手順 4では、 AAD-UserRead 技術プロファイルを実行して、作成されたユーザーアカウントからユーザーの詳細 (JWT に含まれる) を読み取ります。

message要求は格納されないため、オーケストレーション手順5では、JWT に含めるためのUserInputMessageClaimGenerator要求を生成するmessageを実行します。

手順 6 - ポリシーをアップロードする

「カスタムポリシーファイルをアップロードする」の手順に従って、ポリシーファイルをアップロードします。ポータルに既に存在するファイルと同じ名前のファイルをアップロードする場合は、[ カスタムポリシーが既に存在する場合は上書きする] を選択してください。

手順 7 - ポリシーをテストする

カスタムポリシーのテストに関する記事の手順に従って、カスタムポリシーをテストします。

ポリシーの実行が完了し、ID トークンを受け取ったら、ユーザーレコードが作成されていることを確認します。

Azure portal にサインインします。
複数のテナントにアクセスできる場合、上部のメニューの [設定] アイコンを選択し、[ディレクトリとサブスクリプション] メニューからお使いの Azure AD B2C テナントに切り替えます。
Azure サービスで、Azure AD B2C を選択します。または、検索ボックスを使用して Azure AD B2C を検索して選択します。
管理で、ユーザー を選択します。
先ほど作成したユーザーアカウントを見つけて選択します。アカウントプロファイルは、次のスクリーンショットのようになります。

Microsoft Entra ID 技術プロファイル AAD-UserWrite では、ユーザーが既に存在する場合は、エラーメッセージを生成することを指定します。

同じ メールアドレスを使用して、カスタムポリシーをもう一度テストします。 ID トークンを発行するために完了するポリシーの代わりに、次のスクリーンショットのようなエラーメッセージが表示されます。

アカウントが既に存在する場合のエラーのスクリーンショット。

注

パスワード要求の値は非常に重要な情報であるため、カスタムポリシーでの処理方法には十分注意してください。同様の理由から、Azure AD B2C はパスワード要求値を特別な値として扱います。セルフアサート技術プロファイルでパスワード要求値を収集する場合、その値は、同じ技術プロファイル内、または同じセルフアサート技術プロファイルによって参照される検証技術プロファイル内でのみ使用できます。そのセルフアサート技術プロファイルの実行が完了し、別の技術プロファイルに移動すると、値は失われます。

ユーザーの電子メールアドレスを確認する

ユーザーアカウントの作成に使用する前に、ユーザーの電子メールを確認することをお勧めします。メールアドレスを確認するときは、アカウントが実際のユーザーによって作成されていることを確認します。また、ユーザーが正しいメールアドレスを使用してアカウントを作成していることを確認することもできます。

Azure AD B2C のカスタムポリシーは、検証表示制御を使用して電子メールアドレスを検証する方法を提供します。確認コードを電子メールに送信します。コードが送信されると、ユーザーはメッセージを読み取り、表示コントロールによって提供されるコントロールに確認コードを入力し、[ コードの確認 ] ボタンを選択します。

表示コントロールは、特別な機能を備え、Azure Active Directory B2C (Azure AD B2C) バックエンドサービスと対話するユーザーインターフェイス要素です。これにより、ユーザーはバックエンドで検証技術プロファイルを呼び出すアクションをページで実行できます。ページに表示される表示コントロールは、自己宣言型技術プロファイルによって参照されます。

表示コントロールを使用して電子メール検証を追加するには、次の手順に従います。

要求を宣言する

検証コードを保持するために使用する要求を宣言する必要があります。

要求を宣言するには、 ContosoCustomPolicy.XML ファイルで ClaimsSchema 要素を見つけ、次のコードを使用して verificationCode 要求を宣言します。

    <!--<ClaimsSchema>-->
        ...
        <ClaimType Id="verificationCode">
            <DisplayName>Verification Code</DisplayName>
            <DataType>string</DataType>
            <UserHelpText>Enter your verification code</UserHelpText>
            <UserInputType>TextBox</UserInputType>
        </ClaimType>
    <!--</ClaimsSchema>-->

コードの送信と検証の技術プロファイルを構成する

Azure AD B2C は、Microsoft Entra ID SSPR 技術プロファイルを使用して電子メールアドレスを確認します。この技術プロファイルでは、電子メールアドレスにコードを生成して送信したり、構成方法に応じてコードを検証したりできます。

ContosoCustomPolicy.XML ファイルで、ClaimsProviders要素を見つけ、次のコードを使用してクレームプロバイダーを追加します。

    <ClaimsProvider>
        <DisplayName>Azure AD self-service password reset (SSPR)</DisplayName>
        <TechnicalProfiles>
            <TechnicalProfile Id="AadSspr-SendCode">
            <DisplayName>Send Code</DisplayName>
            <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.AadSsprProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
            <Metadata>
                <Item Key="Operation">SendCode</Item>
            </Metadata>
            <InputClaims>
                <InputClaim ClaimTypeReferenceId="email" PartnerClaimType="emailAddress" />
            </InputClaims>
            </TechnicalProfile>
            <TechnicalProfile Id="AadSspr-VerifyCode">
            <DisplayName>Verify Code</DisplayName>
            <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.AadSsprProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
            <Metadata>
                <Item Key="Operation">VerifyCode</Item>
            </Metadata>
            <InputClaims>
                <InputClaim ClaimTypeReferenceId="verificationCode" />
                <InputClaim ClaimTypeReferenceId="email" PartnerClaimType="emailAddress" />
            </InputClaims>
            </TechnicalProfile>
        </TechnicalProfiles>
    </ClaimsProvider>

AadSspr-SendCodeとAadSspr-VerifyCodeの 2 つの技術プロファイルを構成しました。 AadSspr-SendCode は、 InputClaims セクションで指定された電子メールアドレスにコードを生成して送信しますが、 AadSspr-VerifyCode はコードを検証します。技術プロファイルのメタデータで実行するアクションを指定します。

表示コントロールを構成する

ユーザーの電子メールを検証できるように、電子メール検証表示コントロールを構成する必要があります。構成する電子メール検証表示コントロールは、ユーザーからの電子メールの収集に使用する電子メール表示要求を置き換えます。

表示コントロールを構成するには、次の手順に従います。

ContosoCustomPolicy.XML ファイルで、BuildingBlocks セクションを見つけ、次のコードを使用して表示コントロールを子要素として追加します。

    <!--<BuildingBlocks>-->
        ....
        <DisplayControls>
            <DisplayControl Id="emailVerificationControl" UserInterfaceControlType="VerificationControl">
              <DisplayClaims>
                <DisplayClaim ClaimTypeReferenceId="email" Required="true" />
                <DisplayClaim ClaimTypeReferenceId="verificationCode" ControlClaimType="VerificationCode" Required="true" />
              </DisplayClaims>
              <OutputClaims></OutputClaims>
              <Actions>
                <Action Id="SendCode">
                  <ValidationClaimsExchange>
                    <ValidationClaimsExchangeTechnicalProfile TechnicalProfileReferenceId="AadSspr-SendCode" />
                  </ValidationClaimsExchange>
                </Action>
                <Action Id="VerifyCode">
                  <ValidationClaimsExchange>
                    <ValidationClaimsExchangeTechnicalProfile TechnicalProfileReferenceId="AadSspr-VerifyCode" />
                  </ValidationClaimsExchange>
                </Action>
              </Actions>
            </DisplayControl>
        </DisplayControls> 
    <!--</BuildingBlocks>-->

emailVerificationControl表示コントロールを宣言しました。次の重要な部分に注意してください。

DisplayClaims - セルフアサート技術プロファイルと同様に、このセクションでは、表示コントロール内のユーザーから収集されるクレームのコレクションを指定します。
アクション - 表示コントロールによって実行されるアクションの順序を指定します。各アクションは、アクションの実行を担当する技術プロファイルを参照します。たとえば、 SendCode は AadSspr-SendCode 技術プロファイルを参照し、コードを生成して電子メールアドレスに送信します。

ContosoCustomPolicy.XML ファイルで、UserInformationCollector セルフアサートされたテクニカルプロファイルを見つけ、電子メールの表示クレームをemailVerificationControlの表示コントロールに置き換えます。

変更前:
```
    <DisplayClaim ClaimTypeReferenceId="email" Required="true"/>
```
宛先：
```
    <DisplayClaim DisplayControlReferenceId="emailVerificationControl" />
```
手順 6 と手順 7 の手順を使用してポリシーファイルをアップロードし、テストします。今回は、ユーザーアカウントを作成する前に、メールアドレスを確認する必要があります。

Microsoft Entra ID 技術プロファイルを使用してユーザーアカウントを更新する

新しいアカウントを作成するのではなく、ユーザーアカウントを更新するように Microsoft Entra ID 技術プロファイルを構成できます。これを行うには、次のコードを使用して、指定したユーザーアカウントがまだメタデータコレクションに存在しない場合にエラーをスローするように Microsoft Entra ID 技術プロファイルを設定します。また、 Key="UserMessageIfClaimsPrincipalAlreadyExists メタデータエントリを削除します。操作を書き込みに設定する必要があります。

    <Item Key="Operation">Write</Item>
    <Item Key="RaiseErrorIfClaimsPrincipalDoesNotExist">false</Item>

カスタム属性を使用する

この記事では、組み込みのユーザープロファイル属性を使用してユーザーの詳細を格納する方法について説明しました。ただし、多くの場合、特定のシナリオを管理するために独自のカスタム属性を作成する必要があります。これを行うには、 Azure Active Directory B2C でのカスタム属性の定義に関する記事の手順に従います。

Azure Active Directory B2C カスタムポリシーを使用してローカルアカウントのサインアップとサインインフローを設定する方法について説明します。
カスタムポリシーでカスタム属性を定義する方法について説明します。
カスタムポリシーにパスワードの有効期限を追加する方法について説明します。
Microsoft Entra ID 技術プロファイルの詳細を確認します。