> ## Documentation Index > Fetch the complete documentation index at: https://docs-dev-feat-init-gt-translations.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # B2B の運用 > メールプロバイダー、監視、ログストリーミング、Auth0 通知を設定し、新しい顧客 Organizations と事業継続のためのセルフサービス IdP ポータルをプロビジョニングすることで、Auth0 B2B テナントを本番運用できる状態にします。 運用を実現するには、事業継続に必要な、スケーラブルで測定・定量化可能な運用を支えるインフラを構成・整備する必要があります。Auth0 では、これには補助的なサービス (メールプロバイダーなど) の設定、デプロイ向けの監視サービスの構成、異常な状況の検出、そして本番環境で問題が発生した際に迅速かつ円滑に復旧できるよう備えることが含まれます。 効果的な運用体制を確立することは、成功しているお客様がその価値を実感している取り組みであり、ワークフローを検討する際には考慮すべき点がいくつもあります。 * 障害を事前に検知するには、何をすべきですか？ * Auth0 の運用状況に関するデータをどのように取得できますか？ * Auth0 は、Auth0 サービスに予定されている変更に関する情報を提供していますか？ * Auth0 からの重要なお知らせをどのように確認できますか？ * Auth0 の限られたデータ保持期間を超えて保持し、分析できるようにするには、Auth0 のログデータをどのように扱うべきですか？ * アプリケーションのピーク負荷によってレート制限やその他のエラーが発生していないかを確認するには、Auth0 のログをどのようにスキャンできますか？ * ユーザー向けに本番環境レベルのメール配信を行うには、どのメールサービスを使用すべきですか？ 本番環境で Auth0 の標準メールプロバイダーを使用できますか？ * ファイアウォールを設定する必要はありますか？ また、Auth0 からの通信を受信する必要がある内部サービス (カスタムデータベース、Web サービス、メールサーバーなど) のために、どのファイアウォールポートを開放する必要がありますか？ * 新しい組織をどのようにプロビジョニングしますか？ * 顧客が自分の組織用 IdP を構成できるように、セルフサービスのプロビジョニングを提供する必要がありますか？ Auth0 は、Auth0 サービスの稼働を[監視](#monitoring)する機能に加え、Auth0 の[サービスステータス](#service-status)に関する情報も提供しています。さらに、Auth0 は、Auth0 サービスに予定されている変更に関する情報を、さまざまな[通知](#notifications)を通じて提供しています。Auth0 の[ログ](#logging)サービスも、レート制限や過剰な負荷による制約を含め、運用上の異常を追跡・特定するための幅広い機能を提供します。 Auth0 は標準で、統合を迅速に進められるようメール配信サービスを提供しています。ただし、これらのサービスは本番環境での大規模利用を想定したものではなく、メール配信に関する特定のサービスレベルや保証もありません。ベストプラクティスとしては、通常、お客様独自の[メールサービスプロバイダー](#email-provider-setup)を設定することを推奨しています。 また、Auth0 との統合や Auth0 の拡張機能の利用を支えるために、[インフラ](#infrastructure)構成を変更する必要がある場合もあります。たとえば、内部または外部のインフラへのコールバックを提供する必要がある場合 (例: Actions、Rules、Hooks で外部 API 呼び出しを行う必要がある場合、または既存のレガシーなアイデンティティストレージを活用するためにカスタムデータベーススクリプトを使用する場合) には、ファイアウォール設定を構成する必要があるかもしれません。 システム内で組織をどのように表現するかが決まったら、次にその組織自体をどのようにプロビジョニングするかを検討する必要があります。詳しくは、[組織のプロビジョニング](#provisioning-organizations)を参照してください。 さらに、多くのお客様は、顧客側の組織管理者が自分たちの[IdP](#self-service-idp-provisioning)を構成できるようにするため、1 つ以上のセルフサービスポータルを開発しています。

サービスステータス

Auth0 の[ステータスダッシュボード](https://status.auth0.com/)と Auth0 の[稼働状況ダッシュボード](http://uptime.auth0.com/)では、Auth0 サービスの現在および過去のステータスを、人が見てわかりやすい形式で確認できます。監視アラートが発報された場合は、トラブルシューティングの最初の手順として、現在障害が発生していないかを運用担当者がステータスダッシュボードで確認する必要があります。パブリッククラウドのステータスページでは障害通知を購読することもできるため、Social Providers など、依存しているサードパーティの[外部サービス](/docs/ja-jp/deploy-monitor/monitor/check-external-services-status)のステータスも確認することを推奨します。こうした情報をすぐに確認できる状態にしておくと、問題のトラブルシューティング時に考えられる原因をすばやく切り分けるのに役立ち、開発者とヘルプデスク担当者の双方にとって、トラブルシューティングチェックリストの最優先項目とすべきです。 Auth0 および依存するサービス (Social Providers など) のステータス確認方法に関する情報は、開発者とヘルプデスク担当者の双方にとって、トラブルシューティングチェックリストの最優先項目とすべきです。また、ステータス更新の通知を受け取れるよう、Auth0 のステータスページから購読設定を行うことを推奨します。 パブリッククラウドサービスで障害が発生した場合、Auth0 は Root Cause Analysis (RCA) を実施し、その結果を Auth0 のステータスページで公開します。Auth0 は障害発生後に、根本原因の特定に加え、寄与要因の分析や再発防止策の検討を含む徹底的な調査を行うため、RCA 文書が公開されるまでに数週間かかることがあります。

メールプロバイダーの設定

Auth0 は、登録時のウェルカムメール、メールアドレスの確認、漏えいしたパスワード、パスワードのリセットなどのイベントに応じて、ユーザーに[メール](/docs/ja-jp/customize/email)を送信します。イベントの種類ごとにメールテンプレートをカスタマイズできるほか、メール処理を高度にカスタマイズすることも可能です。Auth0 には、基本的なテスト向けに送信容量が制限されたテスト用メールプロバイダーが用意されていますが、本番環境で利用するには独自のメールプロバイダーを設定する必要があります。また、独自のプロバイダーを設定するまでは、メールテンプレートのカスタマイズは機能しません。 デフォルトの Auth0 メールプロバイダーは、本番環境で必要な量のメール送信やメールテンプレートのカスタマイズに対応していません。そのため、本番環境にデプロイする前に独自のメールプロバイダーを設定することをおすすめします。

インフラ

ファイアウォール

Auth0 で実行されるカスタムコード (Action、Rule、Hook、カスタムデータベーススクリプトなど) からネットワーク内のサービスを呼び出す場合や、Auth0 でオンプレミスの SMTP プロバイダーを設定する場合は、[Auth0 からのインバウンドトラフィック](/docs/ja-jp/secure/security-guidance/data-security/allowlist) を許可するようにファイアウォールを設定する必要がある場合があります。ファイアウォールで許可する IP アドレスはリージョンごとに異なり、Auth0 Dashboard の Rules、Hooks、カスタムデータベーススクリプト、メールプロバイダーの設定画面に一覧表示されています。

ログ

Auth0 には、イベントのログ記録や、イベントの異常を特定するためのログのスキャンに関する充実した機能があります (詳細は[ログのドキュメント](/docs/ja-jp/deploy-monitor/logs)を参照してください) 。Auth0 のログの標準保持期間はサブスクリプションレベルによって決まり、最短で 2 日、最長でも 30 日です。外部ログサービスとの統合に対する Auth0 のサポートを活用すれば、この期間を超えてログを保持できるようになるほか、組織全体のログを集約することも可能になります。 ログデータを外部のログ分析サービスに送信するには、ログストリーミングソリューションのいずれかを活用することをおすすめします。これにより、データをより長期間保持できるほか、ログデータに対する高度な分析も利用できます。 サブスクリプションレベルに応じたログデータの[保持期間](/docs/ja-jp/deploy-monitor/logs/log-data-retention)を確認し、ログデータを外部のログ分析サービスに送信するためのログデータエクスポート拡張機能を実装することをおすすめします。Auth0 Marketplace では、[ログストリーミングソリューション](https://marketplace.auth0.com/features/log-streaming)のいずれかを利用できます。 開発チームは、QA テストでは見つけにくい断続的なエラーのトラブルシューティングや検出のためにログファイルを活用できます。セキュリティチームも、フォレンジックデータが必要になった場合に備えて、ログデータを必要とするでしょう。包括的な分析機能を提供するサービスにログファイルをエクスポートすると、利用傾向やattack protectionのトリガーといったパターンの把握に役立ちます。

レート制限とその他のエラー

Auth0 では、[レート制限を超過した場合](/docs/ja-jp/troubleshoot/customer-support/operational-policies/rate-limit-policy)に報告されるエラーに対して、固有のエラーコードを提供しています。レート制限エラーを確認できるようにログの自動スキャンを設定しておくことで、ユーザーに大きな問題が生じる前に、レート制限に達するアクティビティへ先回りして対処できます。Auth0 は他の種類のエラーに対するエラーコードも公開しているため、[認証エラー](/docs/ja-jp/libraries/common-auth0-library-authentication-errors)に加えて、Auth0 の Management API 呼び出しによるエラーについてもログをスキャンすると役立ちます (Management API のエラーコードは、[Management API Explorer](https://auth0.com/docs/api/management/v2) で各呼び出しの下に表示されます) 。 Rule 内からユーザープロファイル情報を取得するために Management API を呼び出すことは、レート制限エラーのよくある原因です。これは、そのような API 呼び出しがログインのたびに実行される可能性があるうえ、定期的なセッションチェックでも実行されるためです。

監視

サポートチームや運用チームがサービス停止に先回りして対応するために必要な情報を適時受け取れるよう、[Auth0 の実装を監視する仕組み](/docs/ja-jp/deploy-monitor/monitor)を整備する必要があります。Auth0 では、監視基盤に組み込める監視用エンドポイントを提供しています。これらのエンドポイントは、監視サービスで利用しやすい応答を返すよう設計されています。なお、これらが提供するのは Auth0 に関するデータのみです。ユーザーがログインできるかどうかを確認するうえで不可欠な、完全なエンドツーエンド監視を行うには、合成トランザクション監視を設定することを推奨します。これにより監視の粒度が高まり、Auth0 とは無関係な障害やパフォーマンス低下も検出できるようになるため、より迅速に先回りして対応できます。 認証のエンドツーエンド監視を行うために、合成ログイントランザクションを送信できるようにしておく必要があります。これは、権限を持たないテストユーザーと組み合わせて [Resource Owner Password Grant](/docs/ja-jp/get-started/authentication-and-authorization-flow/resource-owner-password-flow/call-your-api-using-resource-owner-password-flow) を使用するシンプルなアプリケーションで実現できます。また、[Auth0 のレート制限ポリシー](/docs/ja-jp/troubleshoot/customer-support/operational-policies/rate-limit-policy)も忘れずに考慮してください。

通知

Auth0 からは複数種類の通知が送られます。テナントやプロジェクトに影響する可能性のある重要な情報が含まれているため、見逃さないよう注意してください。 事前対応が必要なセキュリティ通知やその他の運用に関するお知らせは、Auth0 からダッシュボード管理者に送信されます。こうしたメッセージを受け取る必要がある人がダッシュボード管理者になっていることを確認してください。

Dashboard の通知

Auth0 は随時、お客様の テナント に関する重要なお知らせを送信することがあります。こうしたサービスに関するお知らせは Auth0 Dashboard に表示され、内容の重要度に応じて、登録済みの Auth0 Dashboard 管理者にメールでも送信されます。定期的にダッシュボードにログインし、上部のベルアイコンを確認して、重要なお知らせが届いていないか確認するようにしてください。あわせて、Auth0 からのメールにも変更内容や必要な対応に関する重要な情報が含まれている場合があるため、速やかに確認してください。

変更履歴

Auth0 は、サービスの変更に関する情報を Auth0 の[変更履歴](https://auth0.com/changelog)で提供しています。変更内容を把握できるよう、Auth0 の変更履歴を定期的に確認する習慣をつけることをおすすめします。問題を調査するサポートチームにとっては、最近の変更が関係している可能性がないかを判断するうえで、変更履歴の確認が役立つ場合があります。特に、それが[破壊的変更](/docs/ja-jp/troubleshoot/product-lifecycle/deprecations-and-migrations)である場合は重要です。また、開発チームも、有益な新機能を見つけるために変更履歴を確認するとよいでしょう。

組織のプロビジョニング

組織をプロビジョニングする際に必要な作業は、組織がシステム内でどのように表現されているかによって異なります。ここでは少し立ち止まって、それらの組織のユーザーがアプリケーションとどのように関わるのかを検討することが重要です。IAM システムで組織をどのように設定すべきかを判断するには、[複数組織アーキテクチャ](https://cdn2.auth0.com/docs/1.14516.0/media/articles/architecture-scenarios/planning/Multiple-Organization-Architecture-Multitenancy-Overview.pdf) を参照してください。 組織をプロビジョニングする際は、次の点を考慮する必要があります。 * 自身のアプリケーション設定やデータベースに、その組織を追加する必要があります * Auth0 の設定を変更する必要があります。これには、以下の一部またはすべてが含まれます。 * 一意のテナントを作成する * データベース接続を追加する (組織ごとにユーザーを分離している場合) * この組織向けのエンタープライズ接続を追加する * これには、その組織と連携して既存の設定を更新するか、レガシー組織でない場合は Auth0 テナント向けの設定を追加する作業が含まれます。 * その組織の管理者をプロビジョニングする * ミスを避けるため、新しい組織を簡単にプロビジョニングできるように、[組織管理者ポータル](#organization-admin-portal) を作成するとよいでしょう。

組織管理者ポータル

組織管理者ポータルとは、管理者が組織の作成、変更、削除を行えるようにするためのポータルです。必要な作業は、自社システムと Auth0 テナントの両方で複数発生します。このポータルは、データストアや設定にアクセスできるよう、通常は自社システム内に用意する必要があります。一方で、Auth0 には [Auth0 Management API](https://auth0.com/docs/api/management/v2) が用意されているため、自社システムで変更を行うのと同時に、Auth0 テナントにも変更を反映できます。 新しい組織を作成する方法には、大きく 2 つのアプローチがあります。どちらを選ぶかは、新しい組織をデプロイするまでにどれくらい時間がかかっても許容できるかに大きく左右されます。 * **Auth0 テナントへのライブ更新**: 新しい組織をリアルタイムで作成できるようにしたい場合は、Auth0 Management API を使って Auth0 テナントに直接変更を加える方法が適しています。これにより、変更をリアルタイムで反映でき、新しい組織の追加もすぐに有効になります。 ライブ更新を行う場合は、いくつか注意点があります。問題を避けるために、直列で実行しなければならない操作があります。たとえば、接続でクライアントを有効にする操作や、Application にコールバック URL を追加する操作です。Management API で、リスト全体を取得し、新しい値を追加したうえでリスト全体を再送信する必要がある操作は、並列に実行すると片方の値が上書きされるおそれがあるため、直列で実行する必要があります。 * **リポジトリを変更して再デプロイする**: [CI/CD pipeline](/docs/ja-jp/get-started/architecture-scenarios/business-to-business/deployment) の一部として Deploy CLI (またはカスタム CLI) を活用している場合は、変更をリポジトリに直接プッシュしてから、新しいデプロイを開始する方法のほうが適しているかもしれません。こちらは少し時間がかかる場合がありますが、バージョン履歴を管理しやすく、以前のバージョンを再デプロイして変更を戻せるという利点があります。 組織ごとに必要な項目専用のリポジトリを別に用意しておくと、他の共通コンポーネントを再デプロイする必要がなくなり、誤って変更を加えてしまうリスクも抑えられます。

セルフサービスによるIdPプロビジョニング

Auth0の[connections](/docs/ja-jp/authenticate/identity-providers)を使うとIdPの設定は簡単になりますが、特に新しい顧客組織への販売を定期的に行っている場合や、既存の組織でIdPの要件が変化する場合には、顧客組織のIdPのオンボーディングに時間がかかることがあります。そのため、多くのお客様は、顧客側の組織管理者が自分たちでIdPを設定できるセルフサービスポータルを構築することに価値を見いだしています。これにより、IT部門の負担を軽減できます。[Auth0 Management API](https://auth0.com/docs/api/management/v2)は、これを実現するために必要な[接続管理機能](https://auth0.com/docs/api/management/v2#!/Connections/get_connections)をすべて提供しています。

プロジェクト計画ガイド

推奨する戦略の詳細を確認できるよう、ダウンロードして参照できるPDF形式の計画ガイドを提供しています。 [B2B IAM プロジェクト計画ガイド](https://assets.ctfassets.net/cdy7uua7fh8z/63F0WOPJdVzsPMxV1Xvp8x/7a329487c5e890d8e820f6a48983b46a/B2B_Project_Planning.pdf)

複数組織アーキテクチャ (マルチテナンシー)

多くのB2Bプラットフォームでは、顧客組織ごとに何らかの分離やブランディングを行っており、そのためIdentity and Access Management (IAM) システムは複雑になりがちです。これに当てはまる場合は、このような環境に向けたガイダンスやベストプラクティスをぜひご確認ください。 [複数組織アーキテクチャ](/docs/ja-jp/get-started/architecture-scenarios/multiple-organization-architecture)