パートナーテナントに多要素認証 (MFA) を義務付ける

[アーティクル]
06/11/2024

適切なロール: 管理エージェント |販売エージェント |ヘルプデスクエージェント |課金管理者 |セキュリティ管理者

セキュリティの強化と継続的なセキュリティとプライバシー保護は、Microsoft の最優先事項の 1 つであり、パートナーが顧客とテナントを保護できるように支援し続けています。

パートナーがビジネスや顧客を ID の盗難や不正アクセスから保護できるように、パートナーテナントのセキュリティ保護を強化しました。これらのセーフガードでは、MFA が義務付けおよび検証されます。 MFA の管理は、パートナーが資格情報の侵害から顧客リソースへのアクセスをセキュリティで保護するのに役立ちます。

この記事では、パートナーセンターでの多要素認証 (MFA) の管理に関する詳細な例とガイダンスを示します。

クラウドソリューションプロバイダー (CSP) プログラム、コントロールパネルベンダー (CPV)、アドバイザーに参加しているパートナーは、準拠を維持するために、Partner セキュリティ要件を実装する必要があります。

パートナーは、パートナーテナント内のすべてのユーザーアカウント (ゲストユーザーを含む) に対して MFA を強制する必要があります。ユーザーは、次の領域の MFA 検証を完了する必要があります。

パートナーセンター
パートナーセンター API
パートナー代理管理

パートナーセンター

パートナーセンターの一部のページは MFA で保護されています。次に例を示します。

Customers タブのすべてのページ (つまり、https://partner.microsoft.com/commerce/*で始まる URL を持つすべてのページ)
Support>Customer 要求 タブのすべてのページ (たとえば、https://partner.microsoft.com/dashboard/v2/support/customers/*で始まる URL でアクセスされたすべてのページ)
[ビリング]タブのすべてのページ

Overview ページや Service Health Status チェックページなど、パートナーセンターのその他のページでは MFA は必要ありません。

次の表は、これらの MFA で保護されたページにアクセスする権限を持つユーザーの種類を示しています (この機能の影響を受けます)。

MFA 保護対象のページ	管理エージェント	販売エージェント	ヘルプデスクエージェント	セキュリティ管理者	課金管理者
Customers タブのすべてのページ	x	x	x
Support > Customer requests タブのすべてのページ	x		x
課金ページ	x			x	x
セキュリティワークスペース	x			x

これらのページにアクセスするには、まず MFA 検証を完了する必要があります。

サポートされている MFA オプション

Microsoft を使用するパートナーは、Microsoft Entra 多要素認証をサポートしました。詳細については、「 Microsoft Entra 多要素認証を有効にする複数の方法 (MFA がサポートされています) を参照してください。
統合 MFA フェデレーション認証を実装したパートナー。これらのパートナーユーザーは、パートナーセンターにアクセスし、GDAP を使用して顧客を管理できます。 AD FS で使用可能な MFA オファリングを備えた統合 MFA プロバイダー: AD FS の構成方法を参照してください。

重要

パートナーは、Microsoft Entra ID の統合 MFA 要求と互換性のある認証プロバイダーを使用する必要があります。統合要求は、認証時に提供される実際の資格情報の種類を示します。パートナーは、GDAP を使用して顧客テナントを管理するために、統合 MFA を使用する必要があります。

パートナーセンターおよび API

次のパートナーセンター API では、App+User アクセスと Microsoft Entra ID サポート MFA が必要です。

検出 (価格、カタログ、プロモーション)
トランザクションと管理
請求と調整
委任されたアクセスまたは AOBO を使って顧客を管理する
ユーザーとライセンスの割り当て (DAP のみ)
ユーザーとライセンスの割り当て (GDAP あり)
詳細な管理者リレーションシップ要求とアクセスの割り当て

パートナーは次のオプションを使用できます。

MFA 要件を満たすために、Microsoft 組み込みの認証方法を使用します。
フェデレーション ID プロバイダーを使用している場合フェデレーションがフェデレーション MFA を受け入れるように構成されていることを確認。
ADFS を使用して外部の第 2 要素を構成する場合は、AD FS で使用可能な MFA オファリングを持つサードパーティプロバイダーを参照してください: AD FS の認証方法構成する
MFA の実装: セキュリティの既定値のガイダンスに従って、セキュリティの既定値または条件付きアクセスを使用してすぐに MFA を有効にします。

検証の例

パートナーセンターでの検証のしくみを説明するには、次の例を検討してください。

例 1: パートナーが Microsoft Entra 多要素認証を実装している

Alejandra は Contoso という CSP で動作します。 Contoso は、Microsoft Entra 多要素認証を使用して、Contoso パートナーテナントのすべてのユーザーに対して MFA を実装しました。
Alejandra は新しいブラウザーセッションを開始し、パートナーセンターの概要ページ (MFA で保護されていません) に移動します。パートナーセンターは、サインインするために Alejandra を Microsoft Entra ID にリダイレクトします。
Contoso による既存の Microsoft Entra 多要素認証のセットアップにより、MFA 検証を完了するには Alejandra が必要です。サインインと MFA の検証が成功すると、Alejandra はパートナーセンターの概要ページにリダイレクトされます。
Alejandra は、パートナーセンターで MFA で保護されたページのいずれかにアクセスしようとします。以前にサインイン中に Alejandra が MFA 検証を完了したため、Alejandra は MFA で保護されたページにアクセスできます。MFA 検証を再度実行する必要はありません。

例 2: パートナーが ID フェデレーションを使用して Microsoft 以外の MFA を実装している

Prashob は Wingtip という CSP に勤めています。 Wingtip は、Microsoft 以外の MFA を使用して Wingtip パートナーテナントのすべてのユーザーに対して MFA を実装しました。これは、ID フェデレーションを介して Microsoft Entra ID と統合されています。
Prashob は新しいブラウザーセッションを開始し、パートナーセンターの概要ページ (MFA で保護されていません) に移動します。パートナーセンターは、サインインするために Prashob を Microsoft Entra ID にリダイレクトします。
Wingtip には ID フェデレーションが設定されているため、Microsoft Entra ID は Prashob をフェデレーション ID プロバイダーにリダイレクトして、サインインと MFA の検証を完了します。サインインと MFA の検証が成功すると、Prashob は Microsoft Entra ID にリダイレクトされ、パートナーセンターの概要ページにリダイレクトされます。
Prashob は、パートナーセンターの MFA で保護されたページのいずれかにアクセスしようとします。 Prashob は以前のサインイン時に MFA 検証を既に完了しているため、MFA 検証を再度実行する必要なく、MFA で保護されたページにアクセスできます。
その後、Prashob はサービス管理ページに移動し、Contoso の Microsoft Entra ID にユーザーを追加します。 Prashob は強力な認証で Entra と互換性のある認証プロバイダーを使用しているため、問題なく顧客テナントにアクセスできます。

この例の Prashob の推奨事項は、Microsoft Entra 多要素認証ソリューションまたは Entra 互換認証プロバイダーを使用して、顧客のテナントを正常に管理できるようにすることです。

例 3: パートナーが MFA を実装していない

Fabrikam という CSP パートナーは、まだ MFA を実装していません。 Microsoft では、Microsoft Entra ID でサポートされる MFA ソリューションを実装することをお勧めします。
John は Fabrikam に勤めています。 Fabrikam は、Fabrikam パートナーテナントの下のユーザーに対して MFA を実装していません。
John は新しいブラウザーセッションを開始し、パートナーセンターの概要ページに移動します (MFA で保護されていません)。パートナーセンターは、サインインするために John を Microsoft Entra ID にリダイレクトします。
サインインに成功すると、John は MFA 検証を完了していないため、パートナーセンターの概要ページにリダイレクトされます。
John は、パートナーセンターの MFA で保護されたページのいずれかにアクセスしようとします。 John は MFA 検証を完了していないため、パートナーセンターは John を Microsoft Entra ID にリダイレクトして MFA 検証を完了します。 John が MFA を完了する必要があるのはこれが初めてであるため、John は MFA の登録要求されます。 MFA 登録と MFA 検証が成功すると、John は MFA で保護されたページにアクセスできます。
別の日に、Fabrikam が任意のユーザーの MFA を実装する前に、John は新しいブラウザーセッションを開始し、パートナーセンターの概要ページ (MFA で保護されていない) に移動します。パートナーセンターは、MFA プロンプトなしでサインインするために John を Microsoft Entra ID にリダイレクトします。
John は、パートナーセンターの MFA で保護されたページのいずれかにアクセスしようとします。 John は MFA 検証を完了していないため、パートナーセンターは John を Microsoft Entra ID にリダイレクトして MFA 検証を完了します。 John は MFA を登録しているため、今回は MFA 検証の完了のみを求められます。

例 4: パートナーが Microsoft Entra と互換性のない Microsoft 以外の MFA を実装している

Trent は Wingtip という CSP に勤めています。 Wingtip は、条件付きアクセスを使用するクラウド環境で Microsoft 以外の MFA を使用して、Wingtip パートナーテナントのすべてのユーザーに対して MFA を実装しました。
Trent は新しいブラウザーセッションを開始し、パートナーセンターの概要ページ (MFA で保護されていません) に移動します。パートナーセンターは、サインインするために Trent を Microsoft Entra ID にリダイレクトします。
Wingtip では、Microsoft Entra ID と互換性のない、強力な認証を持たない Microsoft 以外の MFA 統合が使用されているため、Trent はパートナーセンター内のすべての MFA で保護されたページと API へのアクセスをブロックされます。

Trent は MFA で保護されたページにアクセスするため、MFA で保護されたページにアクセスするには、強力な認証を MFA に提示する必要があります。

パートナーは、認証時に提供される実際の資格情報の種類を反映して、アクセストークン要求参照の資格情報メソッド要求 ("amr 要求" - Microsoft ID プラットフォーム) をサポートする Microsoft Entra ID と互換性のある認証プロバイダーを使用する必要があります。

MICROSOFT Entra ID と互換性のある MFA をすぐに実装して、テナントのセキュリティベースラインを上げることを CSP パートナーに強くお勧めします。

パートナーセンター API

パートナーセンター API では、アプリのみの認証とアプリケーションとユーザー (アプリ + ユーザー) 認証の両方がサポートされます。

アプリ + ユーザー認証を使用する場合、パートナーセンターでは MFA 検証が必要です。具体的には、パートナーアプリケーションがパートナーセンターに API 要求を送信するときに、要求の承認ヘッダーにアクセストークンを含める必要があります。

Note

セキュアアプリケーションモデルフレームワークは、パートナーセンター API を呼び出す際に Microsoft Azure MFA アーキテクチャを介して CSP パートナーおよび CPV を認証するためのスケーラブルなフレームワークです。サービス自動化で MFA を使用する場合は、このフレームワークを実装する必要があります。

パートナーセンターが App+User 認証を使用して取得したアクセストークンを含む API 要求を受信すると、パートナーセンター API は、Authentication Method Reference (AMR)要求に MFA 値が存在するか確認します。 JWT デコーダーを使用すると、アクセストークンに、予測される認証方法参照 (AMR) 値が含まれているかどうかを検証できます。

{
  "aud": "https://api.partnercenter.microsoft.com",
  "iss": "https://sts.windows.net/df845f1a-7b35-40a2-ba78-6481de91f8ae/",
  "iat": 1549088552,
  "nbf": 1549088552,
  "exp": 1549092452,
  "acr": "1",
  "amr": [
    "pwd",
    "mfa"
  ],
  "appid": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "appidacr": "0",
  "family_name": "Adminagent",
  "given_name": "CSP",
  "ipaddr": "127.0.0.1",
  "name": "Adminagent CSP",
  "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "scp": "user_impersonation",
  "tenant_region_scope": "NA",
  "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee",
  "unique_name": "Adminagent.csp@testtestpartner.onmicrosoft.com",
  "upn": "Adminagent.csp@testtestpartner.onmicrosoft.com",
  "ver": "1.0"
}

この値が存在する場合、パートナーセンターは MFA 検証が完了していると判断し、API 要求を処理します。

値が存在しない場合、パートナーセンター API は次の応答で要求を拒否します。

HTTP/1.1 401 Unauthorized - MFA required
Transfer-Encoding: chunked
Request-Context: appId=cid-v1:11112222-bbbb-3333-cccc-4444dddd5555
WWW-Authenticate: Bearer error="invalid_token"
Date: Thu, 14 Feb 2019 21:54:58 GMT

パートナーセンター API を呼び出す場合、アプリ専用アクセストークンは、顧客テナントでの GDAP ロールの割り当てを必要としない操作でのみサポートされます。

ベストプラクティスの詳細については、「 API の認証と承認 - 概要」を参照してください。

パートナー代理管理

パートナーテナントは、きめ細かい委任された管理者特権 (GDAP) を使用して、Microsoft Online Services ポータル (portal.azure.com または admin.microsoft.com)、コマンドラインインターフェイス (CLI)、API (App+ User 認証を使用) を使用して顧客リソースを管理する必要があります。詳細については、サポートされている MFA オプションを参照してください。

サービスポータルの使用

CSP パートナーは、 Partner Center ポータルからサービス管理インターフェイスを使用して顧客を管理できます。パートナーは顧客に移動し、[サービス管理] を選択して、顧客の特定のサービスを管理できます。パートナーは、 GDAP ロールガイダンスに従って顧客を管理するための適切な最小特権 GDAP ロールを取得する必要があります。

パートナー委任管理者特権 (Admin-On-Behalf-Of) を使用して Microsoft Online Services ポータルにアクセスして顧客リソースを管理する場合、これらのポータルの多くは、顧客の Microsoft Entra テナントを認証コンテキストとして設定して、パートナーアカウントを対話形式で認証する必要があります。顧客テナントにサインインするには、パートナーアカウントが必要です。

Microsoft Entra ID 認証では、MFA を必要とするポリシーがある場合、ユーザーは MFA 検証を完了する必要があります。パートナーアカウントがマネージド ID またはフェデレーション ID のどちらであるかに応じて、次の 2 つのユーザーエクスペリエンスが考えられます。

パートナーアカウントが管理 ID の場合、Microsoft Entra ID はユーザーに MFA 検証の完了を直接求めます。パートナーアカウントが以前に Microsoft Entra ID で MFA に登録されていない場合、ユーザーは最初に MFA 登録完了するように求められます。
パートナーアカウントが federated ID の場合、エクスペリエンスは、パートナー管理者が Microsoft Entra ID でフェデレーションを構成した方法によって異なります。 Microsoft Entra ID でフェデレーションを設定する場合、パートナー管理者は、フェデレーション ID プロバイダーが MFA をサポートしているかどうかを Microsoft Entra ID に指定できます。
- その場合、Microsoft Entra ID はユーザーをフェデレーション ID プロバイダーにリダイレクトして MFA 検証を完了します。
- そうでない場合、Microsoft Entra ID はユーザーに MFA 検証の完了を直接求めます。パートナーアカウントが以前に Microsoft Entra ID で MFA に登録されていない場合、ユーザーは最初に MFA 登録完了するように求められます。

全体的なエクスペリエンスは、エンドカスタマーテナントが管理者に MFA を実装したシナリオに似ています。たとえば、顧客テナントで Microsoft Entra セキュリティの既定値が有効になっている場合、管理者エージェントやヘルプデスクエージェントなど、MFA 検証を使用して顧客テナントにサインインするには管理者権限を持つすべてのアカウントが必要です。

テスト目的で、パートナーは顧客テナントで Microsoft Entra セキュリティの既定値を有効にしてから、パートナーの詳細な委任された管理特権 (GDAP) を使用して顧客テナントにアクセスしてみてください。

Note

一部の Microsoft Online Service ポータルでは、GDAP を使用して顧客リソースにアクセスするときにパートナーアカウントが顧客テナントにサインインする必要はありません。代わりに、パートナーアカウントのみがパートナーテナントにサインインする必要があります。 1 つの例は Exchange 管理センターです。時間の経過と同時に、これらのポータルでは、GDAP を使用するときにパートナーアカウントが顧客テナントにサインインする必要があります。

MFA 登録エクスペリエンス

MFA 検証中に、パートナーアカウントが MFA に登録されていない場合、Microsoft Entra ID はユーザーに最初に MFA 登録を完了するように求めます。

Microsoft Authenticator メソッドの詳細を確認します。

MFA 登録の最初の手順のスクリーンショット。

ユーザーが Next を選択すると、確認方法の一覧から選択するように求められます。

MFA 登録の 2 番目の手順のスクリーンショット。

登録が成功した後、ユーザーは選択した検証方法を使用して MFA 検証を完了する必要があります。

一般的な問題

要求が有効かどうかを理解するには、他のパートナーによって報告された一般的な問題の一覧を確認します。

問題 1: パートナーエージェントに MFA を実装する時間がパートナーに増える必要がある

あるパートナーが、顧客リソースを管理するためにパートナー代理管理特権を使用した Microsoft Online Services ポータルへのアクセスを必要としているパートナーエージェントに対する MFA の実装をまだ開始していないか、またはその最中です。このパートナーには、MFA 実装を完了するためのさらに多くの時間が必要です。これは、技術的な例外の有効な理由ですか?

回答 : いいえ。パートナーは、中断を回避するために、ユーザーに MFA を実装する計画を立てる必要があります。

Note

パートナーがパートナーエージェントの MFA を実装していない場合でも、パートナーエージェントは、顧客テナントへのサインイン時にプロンプトが表示されたときに MFA 登録と MFA 検証を完了できる場合、パートナー代理管理特権を使用して Microsoft Online Services ポータルに引き続きアクセスできます。 MFA 登録を完了しても、そのユーザーに対して MFA が自動的に有効になるわけではありません。

問題 2: パートナーは顧客を管理するためにアクセスする必要がないため、MFA を実装していません

パートナーには、パートナー代理管理特権を使用して顧客リソースを管理するために Microsoft Online Services ポータルにアクセスする必要がないユーザーがパートナーテナントにいます。このパートナーは、これらのユーザーに対して MFA を実装している最中であり、完了にはさらに時間が必要です。これは、技術的な例外の有効な理由ですか?

回答 : いいえ。これらのユーザーアカウントは、顧客リソースを管理するためにパートナー委任管理特権を使用していないため、顧客テナントにサインインする必要はありません。顧客テナントへのサインイン時に MFA 検証を必要とする Microsoft Entra ID の影響を受けることはありません。顧客リソースを管理するには、すべてのユーザーがパートナーセンターまたは顧客ワークロードにアクセスする MFA を持っている必要があります。

問題 3: パートナーがユーザーサービスアカウントに MFA を実装していない

あるパートナーのパートナーテナントに、サービスアカウントとしてデバイスに使用されているいくつかのユーザーアカウントが存在します。これらの低い特権アカウントでは、パートナー代理管理特権を使用して顧客リソースを管理するために、パートナーセンターや Microsoft Online Services ポータルにアクセスする必要はありません。これは技術的な例外の正当な理由ですか?

回答 : いいえ。これらのユーザーアカウントは、顧客リソースを管理するためにパートナー委任管理特権を使用していないため、顧客テナントにサインインする必要はありません。顧客テナントへのサインイン時に MFA 検証を必要とする Microsoft Entra ID の影響を受けることはありません。 API またはポータルでアプリとユーザーの認証が必要な場合、すべてのユーザーが認証に MFA を使用する必要があります。

問題 4: パートナーが Microsoft Authenticator アプリを使用して MFA を実装できない

パートナーには "クリーンデスク" ポリシーがあり、従業員が個人のモバイルデバイスを職場に持ち込むことは許可されていません。個人のモバイルデバイスにアクセスしないと、従業員は Microsoft Authenticator アプリをインストールできません。これは、Microsoft Entra セキュリティの既定値でサポートされている唯一の MFA 検証です。これは、技術的な例外の有効な理由ですか?

回答 : いいえ。パートナーセンターにアクセスするときに従業員が MFA 検証を完了できるように、パートナーは次の代替手段を検討する必要があります。

パートナーは、Microsoft Entra ID P1 または P2 にサインアップすることも、Microsoft Entra ID と互換性のある Microsoft 以外の MFA ソリューションを使用して、より多くの検証方法を提供することもできます。詳細については、 Authentication メソッドのサポートを参照してください。

問題 5: レガシ認証プロトコルの使用により、パートナーが MFA を実装できない

あるパートナーの一部のパートナーエージェントが、MFA と互換性のないレガシ認証プロトコルを引き続き使用しています。たとえば、ユーザーが、レガシ認証プロトコルに基づく Outlook 2010 を引き続き使用しています。これらのパートナーエージェントに対して MFA を有効にすると、レガシ認証プロトコルの使用が中断されます。これは、技術的な例外の有効な理由ですか?

回答 : いいえ。パートナーは、これらのプロトコルを MFA 検証で保護することはできないため、セキュリティへの影響が考えられるため、レガシ認証プロトコルの使用から離れ、資格情報の侵害の影響を受けやすくすることをお勧めします。レガシ認証を非推奨にし、セキュリティの既定値または条件付きアクセスを使用することをお勧めします。レガシ認証から移行する準備をするには、レガシ認証ブックを使用してサインインを確認しレガシ認証をブロックする方法ガイダンスを確認。

Outlook のレガシ認証をサポートするための最新の計画を理解するには、Basic 認証と Exchange Online に関する投稿を読み Exchange チームのブログに従って今後のニュースを入手してください。

問題 6: パートナーが Microsoft Entra ID で認識されない Microsoft 以外の MFA を実装しました

パートナーは、Microsoft 以外の MFA ソリューションを使用してユーザーに MFA を実装しました。ただし、パートナーは、ユーザー認証中に MFA 検証が完了したことを Microsoft Entra ID にリレーするように Microsoft 以外の MFA ソリューションを正しく構成できません。これは、技術的な例外の有効な理由ですか?

回答: いいえ。パートナーは、認証時に提供される実際の資格情報の種類を反映して、資格情報メソッド要求 ("AMR")、Access トークン要求参照 ( Microsoft ID プラットフォーム) をサポートする Microsoft Entra ID と互換性のある認証プロバイダーを使用する必要があります。

Microsoft Entra ID と互換性のある MFA をすぐに実装して、テナントのセキュリティベースラインを上げることを強くお勧めします。

パートナーのセキュリティ要件の状態

次の方法で共有

パートナーテナントに多要素認証 (MFA) を義務付ける

パートナーセンター

サポートされている MFA オプション

パートナーセンターおよび API

検証の例

例 1: パートナーが Microsoft Entra 多要素認証を実装している

例 2: パートナーが ID フェデレーションを使用して Microsoft 以外の MFA を実装している

例 3: パートナーが MFA を実装していない

例 4: パートナーが Microsoft Entra と互換性のない Microsoft 以外の MFA を実装している

パートナーセンター API

パートナー代理管理

サービスポータルの使用

MFA 登録エクスペリエンス

一般的な問題

問題 1: パートナーエージェントに MFA を実装する時間がパートナーに増える必要がある

問題 2: パートナーは顧客を管理するためにアクセスする必要がないため、MFA を実装していません

問題 3: パートナーがユーザーサービスアカウントに MFA を実装していない

問題 4: パートナーが Microsoft Authenticator アプリを使用して MFA を実装できない

問題 5: レガシ認証プロトコルの使用により、パートナーが MFA を実装できない

問題 6: パートナーが Microsoft Entra ID で認識されない Microsoft 以外の MFA を実装しました

フィードバック

その他のリソース

次の方法で共有

パートナー テナントに多要素認証 (MFA) を義務付ける

パートナー センター

サポートされている MFA オプション

パートナー センターおよび API

検証の例

例 1: パートナーが Microsoft Entra 多要素認証を実装している

例 2: パートナーが ID フェデレーションを使用して Microsoft 以外の MFA を実装している

例 3: パートナーが MFA を実装していない

例 4: パートナーが Microsoft Entra と互換性のない Microsoft 以外の MFA を実装している

パートナー センター API

パートナー代理管理

サービス ポータルの使用

MFA 登録エクスペリエンス

一般的な問題

問題 1: パートナーエージェントに MFA を実装する時間がパートナーに増える必要がある

問題 2: パートナーは顧客を管理するためにアクセスする必要がないため、MFA を実装していません

問題 3: パートナーがユーザー サービス アカウントに MFA を実装していない

問題 4: パートナーが Microsoft Authenticator アプリを使用して MFA を実装できない

問題 5: レガシ認証プロトコルの使用により、パートナーが MFA を実装できない

問題 6: パートナーが Microsoft Entra ID で認識されない Microsoft 以外の MFA を実装しました

関連するコンテンツ

フィードバック

その他のリソース

パートナーテナントに多要素認証 (MFA) を義務付ける

パートナーセンター

パートナーセンターおよび API

パートナーセンター API

サービスポータルの使用

問題 3: パートナーがユーザーサービスアカウントに MFA を実装していない